FLUID ANALYZERS

BACKGROUND OF THE INVENTION

Personal glucose monitors enjoy widespread commercial use. Because the data generated by such products is both limited in scope (i.e. glucose data), and subject to relatively straightforward management by monitor users (diabetics typically have a pretty good understanding of how and what to do with glucose level data), there has been little need to develop new methods and systems to handle such data.

Similarly, episodic blood testing as currently practiced (e.g. a SMAC or sequential multiple analysis comprehensive blood test) yields limited episodic data that is readily interpreted without the need for advanced methods and systems to handle such data. The data is usually generated in a lab and sent as a lab report to the physician. The volume of data is manageable by the Caregiver.

However, there it is possible that we will ultimately see the commercialization of bodily fluid analyzers that are used at frequent intervals (and potentially nearly constant real-time data) and measure a potentially broad spectrum of analytes. Many companies are working to develop such devices, like BioDirection, Theranos, academics (e.g. a team of scientists at Ecole Polytechnique Federate de Lausanne in Switzerland have developed a small medical implant to monitor critical chemicals in the blood designed to tell your smartphone when you are about to have a heart attack; see,

http://www.extremetech.com/computing/ 151 134-worlds-smallest-blood-monitoring- implant-talks-to-a-smartphone-but-whose), venture capitalists like the Mike Lazardis' new Quantum Valley Fund and more established companies like Roche and purported new companies like Biozoom in Germany and California..

Similarly, breath-based diagnostics, which potentially enables data sampling without virtually no invasive sampling activity, has the potential to proliferate and provide increasing data streams. Breath is a body fluid.

The present inventors previously addressed only the programming and setting of bodily fluid analyzer alert levels in US 7,824,612 ("Bodily fluid analyzer, and system including same and method for programming same"), the contents of which are hereby incorporated by reference as though fully set forth herein. They have also filed a patent relating to breath-based diagnostics (US Patent Application Serial No. 13/423,527) the contents of which are hereby incorporated by reference as though fully set forth herein.

Constructively engaging the large amounts of data that will emanate from such devices will be challenging. How such large amounts of data can be constructively engaged by medical practitioners remains an unanswered question. Moreover, the testing of analytes is unlikely to be without direct costs, particularly where reagents are employed as well as various devices. Thus, there will be optimal ranges of testing frequency, balancing marginal cost of test with marginal benefit, all dependent on the ability of the caregiver to make meaningful decisions based on the data at his or her disposal. Thus, management of data from such devices desirably interplays with the management of the devices themselves (in terms of analytes tested, testing frequency, clinical relevance, etc).

SUMMARY OF THE INVENTION

The present invention relates to a method for electronically delivering to a caregiver analytical alert data concerning a breach or non breach of an alert limit for an analyte. The method includes providing a medical analyzer with at least one threshold value for the at least one analyte to be sensed by the medical analyzer, sensing the analyte level; and, if the sensed analyte level is beyond the threshold value, electronically sending data to the caregiver, the data comprising an indication of the analyte and the limits set by the caregiver, a breach of the threshold value, the degree of the breach on the basis of an amount over or under the threshold value, a time interval between breaches whether fixed or rolling, a total number of breaches in a given time cycle, and the total number of tests in the time period.

The present invention also relates to a system for electronically delivering to a caregiver analytical alert data concerning a breach of an alert limit for an analyte. The system includes a medical analyzer with at least one threshold value for the at least one analyte to be sensed by the medical analyzer and a processor programmed to provide, if the sensed analyte level is beyond the threshold value, data comprising an indication of a breach of the threshold value, the degree of the breach on the basis of an amount over or under the threshold value, a time interval between breaches, a number of total breaches in a given time cycle, and the total number of tests in the time period. A communication module is provided for electronically sending the data to the caregiver, and a

communication receiver is provided for receiving the data.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a view showing the system of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention provides a method of presenting data from a medical analysis device, such as a bodily fluid analyzer or device that measures biomarkers without reference to bodily fluids per se such as a device for measuring cardiac function, to a user. This invention provides a system for managing data and alerts to a caregiver based upon data from a medical analysis device, e.g. and without limitation, a bodily fluid analyzer.

Metadata is "data about data". Metadata comprises various types. The metadata application is many fold covering a large variety of fields of application there are nothing but specialised and well accepted models to specify types of metadata. Bretheron & Singley (1994) distinguish between two distinct classes: structural/control metadata and guide metadata. Structural metadata are used to describe the structure of database objects such as tables, columns, keys and indexes. Guide metadata are used to help humans find specific items and are usually expressed as a set of keywords in a natural language. According to Ralph Kimball metadata can be divided into 2 similar categories: technical metadata and business metadata. Technical metadata correspond to internal

metadata, business metadata - to external metadata. Kimball adds a third category named process metadata. On the other hand, NISO distinguishes among three types of metadata: descriptive, structural and administrative. Descriptive metadata are the information used to search and locate an object such as title, author, subjects, keywords, publisher; structural metadata give a description of how the components of the object are organised; and administrative metadata refer to the technical information including file type. Two sub-types of administrative metadata are rights management metadata and preservation metadata.

This intention may involve all metadata but principally without limitation employs Descriptive Metadata and Structural Metadata. This invention enables the use of extracted metadata to integrate and manage the raw data from a medical analysis device that would otherwise be overwhelming to the medical practitioner (e.g. physician). One of the aims of the present invention is to avoid overloading the medical practitioner with more data than she can readily digest. It is important to note that if data from a medical analysis device is difficult to employ, it may effectively never be used by a medical practitioner, or alternatively, be reviewed at such distant time intervals so as to vitiate the potential benefit of periodic, near real time or actual real time testing. The salient function of metadata is the extraction and/or computation of salient or relevant data or indices from the raw data generated by the medical analysis device.

It is expressly contemplated that in the primary embodiment, the medical practitioner will not be receiving raw data, or otherwise a complete set data from the medical analysis device. For example, the current inventors believe that a raw graphic data output provided by Medtronic Minimed®, as shown in US 2007/0016449A1 at figure 7A (hereby incorporated by reference in its entirety), is burdensome for the routine, effective use of data in medical practice and fails in that it really does not extract and hence is not metadata. Accordingly, a primary embodiment of the present invention is the presentation of metadata in the absence of the underlying raw or complete data generated by the analyzer device or devices. It is expressly contemplated that the present invention may be used with data from multiple devices that are employed

contemporaneously or serially by the patient or user.

Presenting data from a bodily fluid analyzer to a user

As noted, the commercial deployment of bodily fluid analyzers in the home or workplace will lead to massive amounts of data which must be presented in a manner which is novel when compared to the typical SMAC readout. Unlike the data involved in the use of these analyzers for drug trials, in which the important factors will be and are directed to a determination and amalgamation of data from many patients and many analyzers to determine factors like the therapeutic index (essentially determining the dosage range between harming and helping), in this invention we are concerned with the presentation format of data to the caregiver on a given patient with real time, possibly daily (or other interval based) reports, of analyte data. This is akin to receiving SMAC data every day on each patient and calls for a novel way of presenting data so as not to incapacitate the care giver with a data overload.

The generation of alerts when a measurement exceeds (or falls below) a threshold level is understood (see e.g. Say US 2004/0106859A1 and Fuisz US 7,824,612, each of which is incorporated by reference). Similarly as noted above, glucose measurements are sufficiently well-spaced, easily understood and typically taken in a single analyte context (i.e. a personal glucose monitor that only measures glucose levels), that the data output of such devices has not required but could include the present inventive step. For example, the data output of Bayer's Glucofacts system is described in Bayer's

GLUCOFACTS® DELUXE Software User Guide, Rev. 1/10, © 2009 Bayer HealthCare LLC (see, http://www.bayercontour.com/resources/pdf/User-Guides/Glucof acts-Deluxe- User-Guide?ext=.pdf )(see particularly pp 8-1 1), which is incorporated by reference in its entirety.

Frequency of testing

The invention expressly contemplates that a physician, drug company or other authority may program an analyzer for frequency of testing through the use of a data storage unit, as that term is described in incorporated US 7,824,612 (e.g. once per day, many times per day, every second day, every third day, etc or every week, etc. or every month, etc and so on, and including any other frequency or cycle combined with and varying relative to the chosen analyte). Other methods of programming an analyzer that do not employ a data storage unit and corresponding data reader (as described in

7,824,612) may also be used. In the beginning, this frequency of analysis will be somewhat of a trial and error effort as there is no real evidence, outside of pharmaceutical company new drug therapeutic index measurement, that demonstrates how frequent an interval will be used or useful for measurement of a given analyte. Cost factors for reagents will also be a consideration for frequency as well as the cost factors for such things as multi array or other type cartridges.. For our purposes it is best to assume very frequent testing as that involves a real challenge to the analyzer/patient/data/caregiver relationship. Intellisent Alerts

Intelligent Alerts in this invention include at least four of the following non-limiting factors:

a. The name of the analyte(s) or biomarker(s)

b. The limits set by, e.g., the caregiver

c. The breaches of an alert limit, whether a default or custom set by the caregiver. d. The degree of the breach, e.g... up to 5%, over 5 tol0%, over 10% above the threshold (in the case of a maximum threshold) or below (in the case of a minimum threshold) (other numerical ranges or codes such as color may be used) e. The total number of breaches in a given time cycle (best viewed on a rolling basis)

f. The time interval between the breaches (if more than one breach)

g. A normalized number of breaches - an index of breaches based on the number of tests from the device during a given interval (to account for real time versus the frequency of episodic testing) for biomarkers or analytes that are measured frequently or even constantly. For example, if one is constantly monitoring blood pressure as a bio-marker, a patient's blood pressure may exceed the target for ten minutes. In that ten minutes, a virtually unlimited number of measurements may be taken. For the purpose of reporting the results to the caregiver, the number of breaches reported is not "unlimited." The concept of normalized means the method and system might treat the episode as an individual breach.

h. The total number of tests in that time period for that analyte or biomarker, which number may be normalized (see g above) to account for testing frequency for a particular test.

i. The Billing code for this patient or some other patient identifier

In a preferred aspect of the invention, the Intelligent Alerts also include a mathematical relationship between at least the total number of breaches and the number of tests in the time cycle, and, more preferably, a mathematical relationship among the total number of breaches, the number of tests in the time cycle, and time interval between the breaches. For example, a near-real time system could measure 100 breaches during a period that a once-a-day test might measure just two or three. Data can be collected and transmitted on a fixed time period basis or on a rolling time period basis. Whether on fixed or rolling basis, data may be collected on an hourly, daily, weekly, monthly or annual basis. An indication of whether the data that has been collected and transmitted is on a fixed time period basis or on a rolling time period basis can be provided with the Intelligent Alerts to the caregiver, e.g., by providing the designation "f ' for fixed or "r" for rolling.

The awareness of the breaches from the standpoint of trend formation is an interpretive decision which must be made by the caregiver upon close examination of the data presented in a clear manner.

For example, if potassium is measured every second day, and an alert of category one magnitude (e.g. a breach of 3% over the threshold value) occurs with an interval of fifteen days in between this is less concerning and would not necessarily constitute a trend. There would be many non-breach tests in between. A test done less frequently, say a hematocrit each fifteenth day, would thus form a worrisome trend even at a category 1 breach (up to 5% over the threshold value). It is a parameter not expected to change often, which is why the longer interval between tests is appropriate.

A category 2 breach would be over 5% to 10% breach and it thus more concerning regardless of factors.

Those schooled in the cart will understand that any/other numeric/percentage breach categories may also be designated and used (i.e. different from the numerical ranges presented above).

While many of these breaches would call up for an instant alert to the care giver from the analyzer as in the US 7,824,612, this patent is insufficient for the use of the caregiver, we are here looking at the overall interval data as presented to the caregiver so that the caregiver can grasp significant breaches and possible trends. This is not the only or limited way of presenting this data; however, the presence or influence of a) through h or I) is a necessity in order to put the large amounts of anticipated data in a perspective that it can be used in healthcare. There may be a tendency to look at analyte data in a manner similar to Oracle consumer data; however, this is dynamic data and the physician can never relinquish his judgment to an algorithmic analysis of this data in which a clinical judgment is made for him. Even with the nonlimiting Intelligent Fuisz Index described below, it still behooves the caregiver to look at the presentation of the data. That is the core of the novelty here: by elucidating in an easy to read manner a) through h or I) or some admixture thereof, the Caregiver has an efficient comprehension of the potentially vast data generated and the overall effect meaning of the testing must allow the caregiver to judge the importance and not an algorithm.

The above is quite different from the basic metabolic panel that is provided by standard one time testing on blood from a physician visit. The example below shows the data tested and presented in a sample basic metabolic panel.

As noted below, testing frequency may also be impacted by cost of testing.

Additional factors need be employed by the rxclinician, including the (j) existence of a meaningful upward or downward trend with respect to a given analyte and/or biomarker or set thereof.

Thus the invention provides a method and system for automatically and electronically providing a caregiver with analytical alert data including the name of the analyte or biomarker, the alert limits, the breaches of an alert limit, whether a default or custom set by the caregiver, the degree of the breach, the time interval between the breaches, the number of total breaches in a given time cycle, and the total number of tests in the time period. The Intelligent Fuisz alert feature may, but does not necessarily, employ an index, which we will identify as the Intelligent Fuisz Index.

One example, of the Intelligent Fuisz Index equals the total number of tests * the temporal span between the first and last breached tests divided by the number of outliers (breaches). Therefore, if two outliers in one month of daily testing occur, such outliers occurring ten days apart, the temporal index would be (30 * 10) 12 = 150.

If four outliers in one month of daily testing, occurring during a span of four days, the temporal index would be (30 * 4)/4 = 30.

If eight outliers in one month of daily testing, occurring during a span of three days, the temporal index would be( 30 *3)/8 = 1 1.12. The lower the Intelligent Fuisz Index, the more disturbing the result is relative to the individual patient. In the case of a very infrequently performed test, let us say once per month or more in an essentially healthy patient, there is no need to apply and formula as the data con easily be judged by the caregiver in the traditional manner.

One must also keep in mind the notification of alerts that are inherent in the US 7,824,612 that has been incorporated here. Those alerts may in some cases result in an alteration of the alert levels set by the caregiver. This novel approach need be thought of as the next step of US 7,824,612, and the incorporation of same into a new and broader application, the handling of the data for the Physician. This responsibility can never be abdicated to a third party algorithm. If that were the case then the algorithm would become the physician. The exception, under certain circumstances, to this is the pharma company determining the Therapeutic Index( dosage that harms vs. dosage that helps) for a new chemical entity (NCE).

The term bodily fluid analyzer is used in this specification. The present invention is not limited to analyzers that measure bodily fluid, but may include all measurements of metabolic and physiologic indicia or other analytes.

The Figure shows a non-limitative embodiment of the system of the present invention. The system allows for electronically delivering to a caregiver analytical alert data concerning a breach of an alert limit for an analyte. The system includes a medical analyzer 1 with at least one threshold value for the at least one analyte to be sensed by the medical analyzer. The analyzer 1 is connected to a processor 2 programmed to provide, if the sensed analyte level is beyond the threshold value, data comprising an indication of a breach of the threshold value, the degree of the breach on the basis of an amount over or under the threshold value, a time interval between breaches, a number of total breaches in a given time cycle, and the total number of tests in the time period. The processor 2 may be resident on the analyzer (and may be the same processor as or a separate processor from the processor performing the analyzer functions) or may be provided separately therefrom. If provided separately, the processor 2 may be connected to the analyzer in any way that allows transfer of data from the analyzer to the processor, and the connection can be a wired connection, a wireless connection, a LAN connection, the Internet, etc. A communication module 3 is for electronically sending the data to the communication receiver 4 of the caregiver. The communication module 3 may be part of the analyzer 1 or the processor 2 and can take any form that would be known to those skilled in the art. The communication module can transmit the data to the

communication receiver 4 of the caregiver through network 5, e.g., the Internet.

Non-limitative examples of the present invention is described below.

Example

Metabolic Panel, Basic

Comments from physician's office

Component Results

An Intelligent Fuisz alert presentation sample schema:

K (the analye measured and the limits set by Carefiver) 1 (interval between testing in days-thus every day here) 30 (interval of measurement in days, fixed(F) or rolling(R)) 4 (number of breaches of alert levels set by caregiver) 6.0 (1 st day), 5.8(3 ^rd day), 5.9(4* day).5.8 (6 ^th day) (breach amounts followed by testing day of occurrence. Trend potential. Judged by caregiver here.

To the physician monitoring this patient on a home analyzer with limits set by that caregiver, an example of this information would appear as follows: K(4.0 to 4.8) 1 30(F Or R) 4 breaches 5.0 (1 ^st day), 4.9(3 ^rd day) 4.9(4 ^m day) 4.9(6 ^m day) Thus a Caregiver could use this Fuisz Alert to quickly ascertain if he saw a trend evolving or if he saw the fall back to normal and make a judgment it was not a trend. Perhaps he might use the system taught in US 7,824,612 to, at the next visit to add a creatinine test to the analyzer to ascertain renal function status.

If the Intelligent Fuisz Index were applied here the result would be:

30 X 6/4 =180/4= 45 Forty five would be a low enough index to arouse suspicion.

Let us take the same patient and say they breached twice with a 12 day span between breaches:

30 X 12/2= 360/2 = 180 there is less concern here of a trend.

Now let us take a test which would be, in most cases more infrequently performed by a home analysis, e.g., the hematocrit, if the analyzer has this accurate ability. Let us say it is done on a rolling every 30 day basis and that it dropped from 40 to 38. This result would not require in index reading since there is only one test performed per month and one breach.

Those schooled in the art will understand that the Fuisz Intellgent Index is not limited to the above described embodiment. In fact, the inventors expressly contemplate additional embodiments. Various mathematical models can be used; multiple analytes and biomarkers may be employed and a variety of the factors discussed in a-j above may be employed to make the index that is communicated to medical personnel. However the parameters measured in this application are critical and always necessary to allow the care giver to make a logical assessment of the vast data generated.

It is important to note that this invention provides data to a caregiver that is provided in addition to alerts sent from an analyzer, e.g., in accordance and expansion of the method and system described in and Fuisz US 7,824,612. That is, the data provided by the present invention does not supplant the alerts as called for in and Fuisz US 7,824,612, but rather is cumulative data that is a concise and effective data summary that should be supplied to the Caregiver in addition to the alerts of and Fuisz US 7,824,612.

In another aspect of the invention, the overall day-to-day data assigned by the physician or pharma company to a specific drug will be accrued on a Hippa complaint registration basis. If this data is then used to the benefit of any other entity other than the patient, this data will be used to make a micro payment to the patient for their data usage. The amount of the micro payment would be broadly, but not limited, related to the total data volume used divided by the individual's data inclusion. The metadata should have a registration of patient. The patient's medical data should not be profiteered by selling it without that sale having substantive monies returned to the data source, the patient.

The index may be provided to a user and medical professional on a regular periodic basis, or, triggered off some specific basis that can include the index rising above or below a given threshold or the existence of underlying breaches of a set analyte(s) or biomarker(s) threshold(s).

An alert function may be set that is individualized to a given patient by a physician or drug company, in view of inter alia the patient's health, age, medical condition, and course of treatment or therapy or other individualized circumstances deemed relevant by the physician or drug company.

It is expressly contemplated that the index of the present invention may be generated by the medical analyzer itself in which case the medical analyzer is programmed to generate metadata-based index and resulting alerts. The medical analyzer may be programmed by use of a data storage unit, and a data reader

corresponding to the medical analyzer.

The medical analyzer may comminute alerts based on the index to the physician or health care provider using wifi, cellular networks or other connectivity. The alert may similarly be issued to the user or patient and may be displayed on a screen of the medical analyzer or on another device of the user, like a smartphone.

It is expressly contemplated that the medical analyzer may generate the index or alert.

Alternatively, the index may be generated off the medical analyzer, wherein a separate device - for example a server, another medical analyzer, a smartphone - computes the index and communicates the alert. It is also contemplated that one processor (and device) may generate the index and a separate processor (and device) may generate the alert.