WO2004036336A2

WO2004036336A2 - Non-invasive health monitoring system and method

Info

Publication number: WO2004036336A2
Application number: PCT/IB2003/005532
Authority: WO
Inventors: Radu Leca
Original assignee: Biosign, Inc.
Priority date: 2002-10-15
Filing date: 2003-10-15
Publication date: 2004-04-29
Also published as: WO2004036336A3; AU2003300662A8; AU2003300662A1

Abstract

A health monitoring system including a clien, a non-invasive monitoring device, and a memory unit. The client is coupled with a computer network. The non-invasive monitoring device is coupled eith the client. The device measures health levels of a person and sends data to and receives data from the client. The memory unit is coupled with the computer network. The client controls the device for taking measuements of a persons health levels and stores the measurments in said memory unit.

Description

TITLE OF THE INVENTION:

[0001] NON-INVASIVE HEALTH MONITORING SYSTEM AND METHOD

CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority from United States provisional application Serial Number 60/328,425, filed October 12, 2001 , the contents of which are hereby incorporated by reference.

BACKGROUND OF THE INVENTION:

Field of the Invention:

[0003] This invention relates to systems and methods for non-invasive health monitoring. In particular, the present invention is directed to systems and methods for monitoring such health levels as heart rate, blood pressure, and mean arterial pulse (MAP), through a single, non-invasive, real-time measurement.

Description of the Related Art:

[0004] Traditional methods of health monitoring often involve drawing blood taking a health measurement with a specialized device. Drawing blood is painful.

Also, patients often require the assistance of a health professional, technician, etc. in order to obtain accurate measurements. Therefore, a patient must visit the doctor's office frequently in order to obtain timely and reliable results over a period of time.

Moreover, patients do not have easy access to their test results or historical records, which may be kept in paper files at their doctor's office.

[0005] Thus, there is a need for new and improved systems and methods for monitoring health levels. SUMMARY OF THE INVENTION:

[0006] The present invention provides a secure mechanism for storing and accessing medical data. The present invention provides a platform for doing large- scale clinical trails with approximately 5,000 to 10,000 customers. The present invention provides can restrict access by moving all analysis code a restricted access server. The present invention provides a brand for both the web site and product as a whole including: look and feel, cuff design, logos, language/communication, etc.

[0007] According to an embodiment of the present invention, a scaleable architecture is developed which can provide a set of medical services to thousands of customers. Code may be implemented in Java and Matlab. The windows client may be implemented in C++ using Microsoft Foundation Classes. An XML messaging layer to may be defined to provide an encapsulated interface to both the Windows client and the Web client. A uniform way to handle errors may be defined. A uniform way to perform logging may be defined. Ways of monitoring the system may be developed. Including e-mail alerts and administration tools. [0008] According to an embodiment of the present invention, a device is provided which non-invasively measures a persons health levels. This device may be a UFiT device. The device may be coupled to a computer processor through an input/output device, for downloading real time measurements. The computer processor may include a memory unit and may be coupled to a network, such as the Internet. Historical health data may be stored locally or remotely, over the network. A web page may be provided for coordinating measurement functions, data storage and retrieval, security and other patient functions. [0009] Transfer of data over the network may be accomplished in a number of techniques, such as via XML.

BRIEF DESCRIPTION OF THE DRAWINGS:

[0010] The objects and features of the invention will be more readily understood with reference to the following description and the attached drawings, wherein:

[0011] Figs. 1 and 1B show an example of a non-invasive health monitoring system according to the present invention;

[0012] Figs. 2A and 2B show exemplary web page display screens that can be presented to the user to display results to the user;

[0013] Fig. 3 shows an exemplary embodiment of the PC client architecture;

[0014] Fig. 4 shows an exemplary pipe line model;

[0015] Fig. 5 shows an exemplary request broker;

[0016] Fig. 6 shows an exemplary database design for core data to be stored in the memory unit of the present invention;

[0017] Fig. 7 is an block diagram of an exemplary system architecture, including security zones, according to the present invention;

[0018] Figs. 8A-8E are screen shots of some preferred informational web pages that can be provided in preferred embodiments;

[0019] Fig. 9 shows a preferred dynamic web page including an on-line form for the user to enter information and register for service that can be provided in preferred embodiments;

[0020] Figs. 10A-10H show exemplary processes according to the present invention ; [0021] Figs. 11A-11C show exemplary database security tables according to the present invention; and

[0022] Fig. 12 is an exemplary web site map according to the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS: [0023] Figs. 1A and 1B show an example of a non-invasive health monitoring system according to the present invention. Certain details of an exemplary non- invasive health monitoring system are described in the co-owned, provisional patent application number 60/302,649, filed on July 5, 2001 , entitled "Non-Invasive Health Monitoring System," the contents of which are hereby incorporated by reference. [0024] The initiate operation, a web page 102 is presented via a computer network, such as the Internet, to a client computer 100 executing browser software. [0025] In preferred embodiments, the present invention may include a test instrument 104, a connection to the Internet, and offsite (remote) analysis software, which may reside on a remote application server (e.g., central computer 108), for example. The test instrument 104 is preferably a simple wrist-mounted inflatable cuff that does not penetrate the skin by any means - e.g. whether chemically, biologically and/or physically (e.g., including electric, magnetic or light penetration). The test instrument 104 is connected to the client computer 100 via an I/O port, such as a serial port, and which may include a separate data capture device 106, and data and commands may be transmitted between the test instrument 104 and the client computer 100.

[0026] In preferred embodiments, the cuff 104 inflates around the wrist of the user, much like a digital blood pressure device. As the cuff deflates, a highly sensitive instrument in the cuff gathers data about the patient's pulse, blood pressure, and blood flow attributes. This data is communicated over the Internet to secure servers where physiological analysis is carried out. With patient consent, health care professionals can access this information for home health care assessment.

[0027] Figs. 2A and 2B show exemplary web page display screens that can be presented to the user to display results to the user. In preferred embodiments, results are transmitted back to the user over the Internet in a simple form. The technology would provide the patient in a single reading, with a measurement of a blood glucose levels, blood pressure and heart rate.

[0028] The PC client running on the client computer 100 may be written in a conventional language, such as C++. The PC client can be configured to handle logging into the system, uploading/downloading data securely over the Internet, such as with encryption. The PC client may also be configured to store and retrieve data from memory, analyze the data and display results to a user.

[0029] The PC client may be configured to control the measurement device and perform measurement functions. For example, an inflatable cuff UFiT device may be inflated, calibrated, or initiated to take a particular measurement.

[0030] The measurement device may be coupled with a computer processor running the PC client via an I/O port, such as an RS-232 connection. The PC client is preferred to be a thin client, and small enough to be downloaded so that it can run constantly in the Windows system tray with minimal memory footprint.

[0031] An exemplary web site map is shown in Fig. 12, which outlines the many functional web pages that may be included.

[0032] An exemplary embodiment of the PC client architecture is shown in Fig. 3. [0033] When a pipeline is executed, an XML response is generated and sent back to the client. The XML response contains the resulting data output from the pipeline and although the schema is fixed, the data and its semantic meaning is arbitrary, e.g. a reading pipeline might send back two ints while a login pipeline might send back a true or false. Data types should be provided to support strong typing

(something which XML doesn't provide).

[0034] Pre-Conditions: A successful pipeline execution

[0035] Post-Conditions: Client must parse XML

[0036] Normal Flow: Result is sent back immediately after a pipeline is executed.

If the pipeline fails, the same response XML file is sent back but with error information.

[0037] Alternate Flow: None

[0038] A pipeline is a set of steps of a logical process. By incorporating them into one pipeline, a client can request a process without having to know individual steps, and the pipeline is left to assemble the pieces of code and execute them in series.

For example, the command "reading" could mean the steps "run generic stats" +

"filter for noise" + "look for glucose", etc.

[0039] The client needs to be able to request a version of a particular pipeline to support multiple versions of clients still being active, e.g. version 2.5 of the client might use reading version 1 while version 2.6 of the client might use reading version

2.

[0040] Execution of pipelines should be transactional, e.g. if one step in the pipeline fails, the whole pipeline fails. Pipelines are considered to be atomic entities. [0041] Pre-Conditions: A request must be valid and the pipeline requested must exist.

[0042] Post-Conditions: The resulting data is passed to Get Result to format the data into XML.

[0043] Normal Flow:

[0044] 1. Parameter data is validated to make sure data is right type and no data is missing

[0045] 2. Pipeline is loaded from a database

[0046] 3. Pipeline is executed and then the resulting data is passed to Get

Result/Get Errors

[0047] Alternate Flow: None

[0048] A client sends a request in XML format including any parameter data. A client has a pre-defined contract with a particular pipeline that specifies the data types and valid ranges for each type.

[0049] Pre-Conditions: None

[0050] Post-Conditions: The XML request is parsed and sent to Execute Pipeline.

[0051] Alternate Flow: None

[0052] All errors should be logged at the server in a central location. For errors that are critical, an email should be sent to a central live bugs email address to be forwarded to the appropriate site operations staff.

[0053] Pre-Conditions: An error occurs

[0054] Post-Conditions: the error is sent to Get Errors to be sent back to the client

- it is possible that the error is being caused by the client.

[0055] Alternate Flow: None [0056] When a pipeline is requested, a Request Broker will check to make sure that the user is authorized to execute that pipeline.

[0057] Pre-conditions: A pipeline is requested to be executed

[0058] Post-conditions: A pipeline is now allowed to be executed

[0059] Alternate Flow: None

[0060] An authorized administrator can edit, add and delete pipelines. A pipeline is a list of classes to be executed, so an administrator can effectively take out features, add new features, etc., in a particular pipeline by taking or adding in components in the pipeline.

[0061] An exemplary pipe line model is shown in Fig. 4.

[0062] The pipeline architecture includes two main beans and their respective interfaces (Home and Remote).

[0063] PipelineSQL is an entity bean which is fully implemented to support addition, deletion, editing and reading of pipeline:. Pipelines can be found by either primary key (find ByPrimaryKey) or by a combination of pipeline name and version number (find ByNameVersion).

[0064] Pipeline is a session bean, which loads the request pipeline through

PipelineSQL, checks to see if the pipeline is authorized and then executes the pipeline.

[0065] A pipeline in the database is a series of names of classes that support the

(Pipeline interface. The PipelineSQL bean supplies an ordered list of classes to execute. Using Java reflection, the Pipeline bean creates (Pipeline object by supplying the name of the class to create. It then calls the Pipeline method execute. [0066] The classname supplied must reference a class which supports the

(Pipeline interface, otherwise the pipeline will fail.

[0067] A PipelineDataCollection is supplied to the Pipeline session bean. The

PDC is simply a hashtable containing input and output values as the pipeline is executed. Any initial input parameters should be added to the PDC before execution of the pipeline is called.

[0068] Pipeline components exist within a single transaction - if one component fails then the entire pipeline is rolled back.

[0069] The PDC is passed from component to component - each component in the pipeline has access to any data placed in the PDC by previous pipelines.

Pipeline components can also remove data from the PDC if it is no longer needed, although this should be done with care in case components further down the chain require the data.

[0070] Any data left in the PIC after the pipeline has executed is passed to the

XML Writer specified by the Request Broker (see infra for more details on Request

Broker). The XML writer is responsible for generating an appropriate XML response as a string.

[0071] An exemplary Request Broker is shown in Fig. 5.

[0072] A request should be sent as a post to the servlet RBServlet. The post should have one variable XML which equals the full text of the XML file. XML data does not need to be HTML encoded since it will be passed through the HTTP header and not the URL. [0073] When a request is received, it is parsed into a DOM object which is parsed to obtain the pipeline requested and the input parameters supplied. A Pipeline bean is created and executePipeline is called.

[0074] The request will fail if any of the parameters declared cannot be created, e.g. <int>dog</int> or <byte> 1202</byte> will fail the entire request.

[0075] The resulting XML response is written back to the HttpSelvletResponse object.

[0076] Keep in mind that all numeric values in Java are signed - if an unsigned value, it should be cast to the next size primitive (byte to int, int to long, float to double, etc.) and then passed in.

[0077] The pipeline components are responsible for validating values based on specific business logic for the domain. The request broker simply checks to make sure that the object of the type requested can be created.

[0078] An exemplary database design for core data to be stored in the memory unit of the present invention, is illustrated in Fig. 6.

[0079] This table stores reading data. Each record in this table represents a complete raw reading from the UFIT device, and data can be analyzed/studied in the future. Each reading can have zero or more analysis records in the Analysis table.

Each reading must link to one medical profile record in the MedicaiProfile table. This is done through the MEDICAL PROFILE ID foreign key.

[0080] In the Medical Profile table, each reading is associated with one Medical

Profile record, which has a userlD. This is the way to link a reading to any particular user. [0081] Over the time, a user might have multiple Medical Profile records, as his/her medical information (weight, height, age...) changes. New Medical Profile records shall be generated when user information (weight, height, age...) changes in the user database.

[0082] In the Analysis Table, each Analysis record is linked to the Reading table through the READING ID foreign key. Same reading data can be analyzed by different algorithms and/or at different times. The actual analysis results are stored in the ANALYSIS DATA table.

[0083] The Analysis Data table stores the actual analysis results. Each record has fields to indicate what type of result it is - e.g. heart rate, glucose, etc. - and its value. This allows new analysis types to be added into the system without modifying the database schema. Analysis result records are linked to the Analysis table through the ANALYSISJD foreign key.

[0084] The Ref Analysis Type Code table is for different types of analysis results.

[0085] Java Beans for the Medical Database may be used.

[0086] A ReadingSQL EJB is used to manage the Reading table. All fields are read-only.

[0087] MedicalProfileSQL is an EJB to manage the Medicalhrofile table, all fields are read-only.

[0088] AnalysisSQL is an EJB to manage the Analysis and Analysis Data records. All fields are read-only.

[0089] AnalysisTypeSQL is an EJB to manage the Ref _Analysis Type Code table. All fields can be read, and the description field can be set as well. This bean most likely will be used in an admin tool. [0090] An exemplary security model is shown in Fig. 7. Security is intended to protect a number of things including patient information and computer system information and uses confidentiality, authentication, integrity principals and access control.

[0091] Patient information is meant to include a broad range of data, such as personal information, medical history data, health measurement data, both raw and processed, and system data, such as cuff data, calibration data, firmware data, etc. [0092] The security model may include zones of protection for the various regions of the architecture. For example, separate security zones may be effected for the cuff, between the cuff and the PC client, the PC client, between the PC client and the DMZ, the DMZ, between the DMZ (proxy servers) and the servers (application, database and backup), and the servers.

[0093] Security zones may utilize a number of techniques as appropriate, such as, firewalls, SSL with server authentication, encryption, private keys, and VPNs. [0094] Figs. 8A-8E some preferred informational web pages that can be provided in preferred embodiments having a server created web site for customer on-line access over the Internet or other network via personal computers. [0095] The screen shots that can be provided in preferred embodiments having a server created web site for customer on-line access over the Internet, for example, via personal computers. These screen shots can be provided via the Internet, for example, to facilitate system usage. As shown, a first screen shot provides instructions for taking a reading using the data capture (UFIT™) device. Another screen shot informs the user of the system testing of the UFIT device. Another screen shot informs the user of the system testing of the UFIT device. Another screen shot shows an illustrative usemame and password form for user authentication. Another screen shot shows illustrative instructions for user attachment of a cuff for taking a reading. Another screen shot informs the user to remain still while reading. Another screen shot instructs the user to press finish to see results. Another screen shot shows results as presented to the user in an illustrative embodiment.

[0096] Figs. 11 A-11 C show exemplary database security tables according to the present invention.

[0097] Fig. 9 shows a preferred dynamic web page including an on-line form for the user to enter information and register for service that can be provided in preferred embodiments having a server created web site for customer on-line access over the Internet, for example, via personal computer.

[0098] A preferred non-invasive health monitoring system includes: a) a pressure inflatable cuff that surrounds a user's wrist; b) an electronic-data-capture device coupled to the cuff that measures acoustic parameters from the arterial pulse (e.g., within one's wrist); c) a computer linked to the data capture device that receives and analyzes the captured data. The system extracts clinical information from a patient's acoustic pulse signal using mechanical parameters.

[0099] In some preferred embodiments, the system can, for example, perform biochemical analysis (e.g., related to blood constituents such as glucose, sodium and the like), hematological analyses (e.g., related to blood features such as white blood cells, red blood cells, platelets and the like) and/or hemodynamic analysis

(e.g., related to the dynamics of blood circulation such as, for example, fluid flow patterns, pressure gradients, regurgitant characteristics, stroke volume, recovery, variability and the like).

[00100] Figs. 10A-1 OH show exemplary processes according to the present invention.

[00101] In operation, when the device is turned on, the cuff inflates automatically and then deflates during a period of time (e.g., possibly a minute or less). During this time, an acoustic signal based on sounds from the arterial pulse is created. The signal is analyzed using algorithms, computational models and logic sequences that detect, differentiate and measure specific noise patterns inherent within the blood stream. These noise patterns can be used to represent blood constituents and features such as glucose, cholesterol, triglyceride, potassium, sodium, platelets and more. Thus, the system can detect multiple physiological parameters through a single measurement of the radial arterial pulse.

[00102] In one exemplary embodiment, the device extracts clinical information related to blood glucose (e.g., as an aid to diabetics and/or others). Preferably, the system provides simultaneous monitoring of a) blood pressure, b) heart rate and c) glucose level based on an approximately 30-second reading.

[00103] In preferred embodiments, the data-capture device is connected to a user's personal computer, which in turn transmits raw data (e.g., via the Internet) to a central computer (e.g., at a central server) that analyzes the data. Preferably, the result of the analysis is returned to the user's personal computer via a simple alphanumeric display. The entire process is preferably under about 1 minute.

Preferably, the central computer stores the information for future use and/or analyses. [00104] The preferred embodiments of the present invention classify the acoustic signals based on scientific principles, rather than merely based upon the feeding of empirical or experimental data, such as in some neural network or fuzzy logic systems. The preferred embodiments provide a logical mathematical system enabling: very high speed of computing; avoidance of calibration requirements (e.g., discovery and/or learning); avoidance of substantial storage requirements; etc. [00105] Generally parallel to spectral analyses with light, preferred embodiments of the present invention can evaluate characteristics by determining interference spectra carrying information about its constituents. As with light, sound has specific characteristics and obeys certain principles. The preferred embodiments use sound to classify substances dissolved into fluid (i.e., blood) based on their sonic spectrum. The preferred embodiment uses a logical system with a 5-pole model in which the acoustic signals are classified into 1 of 5 special categories creating a logical spectrum for the acoustic signals. [00106] In some illustrative embodiments, the device can operate generally as follows. The data capture UFIT device can preferably be activated by the operator clicking on a "start" button on the screen of the user's personal computer. Once activated, the cuff of the data capture device preferably inflates automatically and deflates during a period of preferably about less than a minute (e.g., about 40 seconds or so). During the activation phase, the arterial pulse is preferably displayed to the user on the user's personal computer so as to provide a generally real time display of the raw data signal to the user. This latter display can be provided by the personal computer directly from the UFIT data capture device in substantially real time. Preferably, the raw data is sent to a central processing system (e.g., via a network such as the Internet, wide area network or the like) and results are returned to the user's personal computer within a short period of time

(e.g., less than one minute).

[00107] While preferred embodiments of the invention have been described, the present invention is not limited to these preferred embodiments, but includes all alterations and modifications as would be apparent to those in the art based on this disclosure.

[00108] The PC Client preferably performs the following functions. Take a reading from UFIT. Log into the system with usemame and password. Upload reading data securely over the Internet. Receive analysis data and display results to the user.

[00109] The PC client is preferably written in C++ using Microsoft Foundation

Classes in order to provide a robust client that will take readings, send them securely from client to server and then display to the user the analysis results.

[00110] The PC client is to be as small as possible so that it can run constantly in the Windows system tray with minimal memory footprint. Preferably, the client will be downloaded from the web site so a small file size is necessary for users with slow modems.

[00111] Specifications for the client should run on 800 x 600 24-bit resolution screen or higher. Must support Windows 95, 98, ME, XP, NT 4.0, 2000 platforms.

Results will be sent via HTTPS using 128 bit encryption SSL.

[00112] Thus, the present invention has been fully described with reference to the drawing figures. Although the invention has been described based upon these preferred embodiments, it would be apparent to those of skilled in the art that certain modifications, variations, and alternative constructions would be apparent, while remaining within the spirit and scope of the invention. In order to determine the metes and bounds of the invention, therefore, reference should be made to the appended claims.

Claims

We claim:

1. A health monitoring system comprising: a client coupled with a computer network; a non-invasive monitoring device coupled with said client, said device sending data to and receiving data from said client; and a memory unit coupled with said computer network; wherein said client controls said device for taking measurements of a persons health levels and stores said measurements in said memory unit.