HK1182190B

HK1182190B - Status reporting of a structured collection procedure

Info

Publication number: HK1182190B
Application number: HK13109266.3A
Authority: HK
Inventors: Abhishek S. Soni; Paul J. Galley; Alan Greenburg; Steven Bousamra; Stefan Weinert; Eric R. Diebold
Original assignee: F. Hoffmann-La Roche Ag
Priority date: 2010-06-18
Filing date: 2011-06-08
Publication date: 2018-01-19

Description

Status reporting for structured collection procedures

Cross Reference to Related Applications

This application is a continuation-in-part application of U.S. patent application serial No. 12/643,415 filed on 21/12/2009, which claims priority to U.S. provisional application serial No. 61/140,270 filed on 23/12/2008, both of which are incorporated herein by reference in their entirety.

Technical Field

Embodiments of the present invention relate generally to devices that collect physiological information, and more particularly to a system and method for managing the implementation, execution, data collection, and data analysis of a structured collection procedure running on a portable, handheld collection device and the status reporting of the structured collection procedure.

Background

Diseases that last long or are frequently heavily attacked are generally defined as chronic diseases. Known chronic diseases include, inter alia, depression, obsessive-compulsive delusions, alcoholism, asthma, autoimmune diseases (e.g. ulcerative colitis, lupus erythematosus), osteoporosis, cancer and diabetes. Such chronic diseases require long-term care management in order to have effective long-term treatment. One of the functions of long-term care management after initial diagnosis is then to optimize the therapy of the patient's chronic disease.

In the case of diabetes, which is characterized by hyperglycemia due to inadequate insulin secretion, insulin function, or both, it is known that diabetes behaves differently in every human body due to the unique physiology of each individual interacting with different health and lifestyle factors, such as eating habits, weight, stress, illness, sleep, exercise, and medication. Biomarkers are biologically derived indicators of a patient that indicate a biological or pathogenic process, pharmacological response, event (event), or condition (e.g., aging, disease or illness risk, presence or progression, etc.). For example, a biomarker may be an objective measure of a variable associated with a disease, which may be used as an indicator or predictor of the disease. In the case of diabetes, such biomarkers include values measured for glucose, lipids, triglycerides, and the like. A biomarker may also be a set of parameters from which the presence or risk of a disease can be inferred, rather than a measured value of the disease itself. When properly collected and assessed, biomarkers can provide useful information about medical issues with respect to a patient, and can be used as part of medical assessment, as medical control, and/or for medical optimization.

For Diabetes, clinicians typically treat diabetic patients according to published treatment guidelines, such as Clinical guidelines for pharmaceutical Management of Type 2 Diabetes (2007) by Joslin Diabetes Center & Joslin Clinical and Clinical guidelines for additives with Diabetes (2008) by Joslin Diabetes Center & Joslin Clinical. The guidelines may specify desired biomarker values, such as fasting blood glucose values of less than 100mg/dl, or a clinician may specify desired biomarker values based on the clinician's training and experience in treating a diabetic patient. Such guidelines do not specify biomarker collection procedures that are adjusted for parameters in order to support a particular therapy for optimizing therapy for a diabetic patient. Subsequently, diabetics often must measure their glucose levels with little collection structure and little consideration of lifestyle factors. Such unstructured collection of glucose levels may result in a lack of interpretative context for some biomarker measurements, thereby reducing the value of such measurements to clinicians and other such healthcare providers that help patients manage their disease.

Different clinicians may require a certain number of collections of patients with chronic disease at various times in order to diagnose the chronic disease or optimize therapy. But these requirements for performing such collections according to the schedule may overlap, repeat, run in reverse of each other, and/or burden the patient such that the patient may avoid any further attempts to diagnose their chronic disease or optimize therapy.

Furthermore, if the requesting clinician does not properly evaluate the patient in order to know whether the requested collection schedule is possible and/or whether the parameters corresponding to the collection are appropriate and/or acceptable for the patient, it is not possible to obtain useful results through such collection. In addition, such a requirement may waste clinician and patient time and effort and consumables used to perform the collection if sufficient appropriate data is not collected to complete the collection required so that the collected data helps address the clinician's medical problems and/or interests. Likewise, such failures can be discouraging to the patient in seeking further therapy advice.

Furthermore, prior art collection devices used to facilitate collection schedules provide limited guidance (if provided) and simple reminders regarding collection events. Such prior art devices typically require manual programming by a clinician or patient in order to manage the collection schedule. Such limited guidance and functionality provided by prior art collection devices may also further discourage patients from seeking any further optimization of their therapy, as the administration of another collection procedure in this manner may be viewed by the patient as cumbersome, thereby simply turning such optimization into guesswork.

Disclosure of Invention

In view of the foregoing background, embodiments of the present invention present a system and method for managing the implementation, execution, data collection, and data analysis of an intended structured collection procedure running on a portable, handheld collection device and the status reporting of the structured collection procedure. Embodiments of the invention may be implemented on a variety of collection devices, such as blood glucose measurement devices (meters) capable of accepting and running thereon one or more collection procedures and associated meter executable scripts in accordance with the invention. In one embodiment, these collection procedures may be generated on a computer or on any device capable of generating collection procedures. The status report of this structured collection procedure running on the device may be in printed and/or electronic format and may be provided to both the patient and the clinician for different purposes, such as for example, diagnosis of a condition, stimulation, determination of a health status, etc. for the patient, and for example, for the clinician's need to know the patient's needs in order to identify a debilitating patient, determine a health status, etc.

In one embodiment, a collection device that performs a structured collection procedure is disclosed. The apparatus comprises: a display, a memory, a processor coupled to the memory and the display, and program instructions. The program instructions, when executed by a processor, cause the processor to: the schedule of events for the structured collection procedure is initiated when one or more entry criteria are met, collecting patient data for the structured collection procedure when entered in response to a request according to an event provided in the schedule of events after startup, automatically storing the collected patient data in a memory, automatically evaluating whether patient data collected in response to the request satisfies one or more adherence (adherence) and/or acceptance criteria, if the one or more adherence and/or acceptance criteria are met automatically associating the stored collected patient data with the unique identifier in memory, automatically providing a status report when the one or more adherence and/or acceptance criteria are not met during the structured collection procedure, and automatically ending the structured collection procedure when the one or more exit criteria are met.

In another embodiment, a collection device that performs a structured collection procedure is disclosed. The apparatus comprises: a display; a memory; a processor connected to the memory and display; and program instructions that, when executed by a processor, cause the processor to: the method includes initiating a schedule of events for the structured collection procedure when one or more entry criteria are met, collecting patient data for the structured collection procedure when entered in response to a request according to an event provided in the schedule of events after initiation, automatically storing the collected patient data in a memory, automatically evaluating whether the patient data collected in response to the request meets one or more adherence and/or acceptance criteria, automatically associating the stored collected patient data with a unique identifier in the memory if the one or more adherence and/or acceptance criteria are met, automatically ending the structured collection procedure when one or more exit criteria are met, and automatically providing a status report when the one or more exit criteria are met.

In yet another embodiment, a method of managing a structured collection procedure is disclosed and includes: a collection device having a structured collection procedure and program instructions is provided, and the program instructions are executed on the collection device. The program instructions cause the processor of the collection device to: the schedule of events for the structured collection procedure is initiated when one or more entry criteria are met, collecting patient data for the structured collection procedure when entered in response to a request according to an event provided in the schedule of events after startup, automatically storing the collected patient data in a memory, automatically assessing whether patient data collected in response to the request meets one or more adherence and/or acceptance criteria, if the one or more adherence and/or acceptance criteria are met automatically associating the stored collected patient data with the unique identifier in memory, automatically providing a status report when the one or more adherence and/or acceptance criteria are not met during the structured collection procedure, and automatically ending the structured collection procedure when the one or more exit criteria are met.

These and other advantages and features of the various embodiments of the invention disclosed herein will become apparent from the following description, the accompanying drawings, and the claims.

Drawings

The following detailed description of embodiments of the present invention can be best understood when read in conjunction with the following drawings, where like structure is indicated with like reference numerals.

FIG. 1 is a schematic diagram illustrating a long term care management system for diabetics and clinicians and others interested in long term care management of patients according to one embodiment of the present invention.

Fig. 2 and 2A are schematic diagrams illustrating an embodiment of a system suitable for implementing a structured testing method according to one embodiment of the present invention.

Fig. 3 shows a block diagram of an embodiment of the collecting device according to the invention.

FIG. 4 shows a depiction of one embodiment of a data record in tabular form generated on the collection device of FIG. 3 using a structured testing method in accordance with the present invention.

FIG. 5A depicts a method of generating a structured collection procedure for medical use cases and/or questions according to one embodiment of the present invention.

Fig. 5B and 5C illustrate, respectively, parameters defining a structured collection procedure and factors that may be considered to optimize therapy for a patient using the structured collection procedure, according to one or more embodiments of the invention.

Fig. 6A, 6B, 6C, 6D, and 6E illustrate various structured collection procedure embodiments defined in accordance with the present invention.

Figure 7A depicts a structured testing method for diagnosis or therapy support for a patient with a chronic disease according to one embodiment of the present invention.

Figure 7B conceptually illustrates one example of a predefined structured collection procedure and a method for customizing the predefined structured collection procedure, in accordance with one embodiment of the present invention.

FIG. 8A illustrates a method for performing a structured collection procedure according to one embodiment of the invention.

Fig. 8B and 8C illustrate a method of implementing a structured collection procedure via a graphical user interface provided on a collection device according to one embodiment of the present invention.

FIG. 9 illustrates a method for performing a structured collection procedure to obtain contextualized biomarker data from a patient, according to another embodiment of the present invention.

FIG. 10A depicts non-contextualized and contextualized data.

FIG. 10B depicts an exemplary collection procedure according to one embodiment of the invention.

FIG. 11 depicts a schematic diagram of acceptable contextualized data being blended with unacceptable contextualized data, according to one embodiment of the invention.

FIG. 12 depicts elements of software according to one embodiment of the invention.

Fig. 13 and 14 depict a collection procedure execution method according to one embodiment of the invention.

FIG. 15 illustrates a method of providing diabetes diagnosis and therapy support according to one use example embodiment of the invention.

16, 17, and 18 depict different screen shots of a graphical user interface according to one embodiment of the invention.

19A-19G depict different screen shots of a graphical user interface according to various embodiments of the invention.

FIG. 20 illustrates a method for performing a structured collection procedure according to another embodiment of the invention.

Figure 21 conceptually illustrates another example of a predefined structured collection procedure and a method for customizing the predefined structured collection procedure, in accordance with one embodiment of the present invention.

Detailed Description

The invention will be described with respect to various illustrative embodiments. Those skilled in the art will recognize that the present invention may be implemented in many different applications and embodiments and is not particularly limited in its application to the specific embodiments depicted herein. In particular, the invention will be discussed below in connection with diabetes management by sampling blood, but one of ordinary skill in the art will recognize that the invention can be modified for use with other types of fluids or analytes besides glucose and/or can be used to manage other chronic diseases besides diabetes.

As used herein with respect to the various illustrative embodiments described below, the following terms include (but are not limited to) the following meanings.

The term "biomarker" may mean a physiological variable measured to provide data related to a patient, such as a blood glucose value, a interstitial glucose value, an HbA1c value, a heart rate measurement, a blood pressure measurement, lipids, triglycerides, cholesterol, and the like.

The term "contextualizing" may mean documenting and interrelating conditions that already exist or are about to occur around the collection of a particular biomarker measurement. Preferably, data about documented and cross-correlated conditions that already exist or are about to occur around the collection of a particular biomarker may be stored together with and linked to the collected biomarker data. In particular, further evaluation of the collected biomarker data takes into account data on documenting and interrelating conditions, so that not only such data is assessed, but also the links between the data it is contextualized. The data about the documented and interrelated conditions may for example comprise information about the time, food and/or exercise that occurred around and/or simultaneously with the collection of specific biomarker measurements. For example, during a basal titration optimization (focused) test protocol, the context of a structured collection protocol according to an embodiment of the present invention may be documented by utilizing entry criteria that verify a fasting state of a diabetic person prior to accepting biomarker values.

The term "contextualized biomarker data" may mean information about a cross-correlation condition in which specific biomarker measurements are collected in combination with measured values for the specific biomarker. In particular, the biomarker data is stored together with and linked to information about the cross-correlation condition in which the particular biomarker measurement was collected.

The term "criteria" may mean one or more criteria, and may be at least one or more of guideline(s), rule(s), characteristic(s), and dimension(s) used to determine whether one or more conditions are met or met in order to begin, accept, and/or end one or more procedure steps, actions, and/or values.

The term "adherence" can mean that a person follows the structured collection procedure to properly perform the required procedure steps. For example, biomarker data should be measured under the prescribed conditions of the structured collection procedure. The adherence is then defined as appropriate if the prescribed conditions are given for the biomarker measurements. For example, the specified condition is a time-related condition and/or may illustratively include eating a meal, taking a fasting sample, eating a meal of a certain type within a desired time window, taking a fasting sample at a desired time, taking a minimum amount of sleep, and/or the like. The adherence can be defined as appropriate or inappropriate for a structured collection procedure of contextualized (biomarker) data, a set of sampling instances, or a single data point. Preferably, the adherence can be defined as appropriate or inappropriate by a range of prescribed condition(s) or by selectively determined prescribed condition(s). Furthermore, the adherence can be calculated as an adherence ratio describing how much the adherence is given for a structured collection procedure or a single data point, in particular of contextualized biomarker data.

The term "adherence event" may mean that the person performing the structured collection procedure is not able to perform the procedure steps. For example, if a person does not collect data when required by the collection device, the adherence is determined to be inappropriate, resulting in an adherence event. In another example, the adherence criterion can be a first criterion for a patient fasting for 6 hours and a second criterion for collecting fasting bG values at a desired time. In this example, if the patient provided a bG sample at the requested time but only fasted for 3 hours before providing the bG sample, the first adherence criterion was not met although the second adherence criterion was met, and thus an adherence event to the first criterion would occur.

The term "violation event" is a form of an adherence event in which the person performing the structured collection (test) procedure (protocol) does not take the therapeutic at the recommended time, does not take the recommended amount, or both.

The term "adherence criterion" may include adherence and may mean the basis for comparing (e.g., evaluating) a value/information related to a measured value and/or a calculated value to a defined value/information or a defined range of values, wherein data may be accepted with a grant or positive reception based on the comparison. Adherence criteria may be applied to the contextualized biomarker data such that the biomarker data may be accepted based on a comparison of the contextualized data with respect to documentation and related conditions that exist or occur during collection of the particular biomarker. The adherence criteria may be similar to a sanity check for a given piece or group of information. Preferably, the adherence criterion may be applied to the data set(s) or information and rejected if the adherence criterion is not met. In particular, such rejected data will not be subsequently used for further calculations that provide therapy recommendations. The rejected data may primarily only be used to assess compliance and/or automatically trigger at least one other action. Such a triggered action may prompt the user to follow a structured collection procedure or a single required action, for example, so that the adherence criteria may be met. Further, the overall adherence criteria can be derived from averaging each adherence criteria of the structured collection procedure or a particular subset of adherence criteria of the structured collection procedure to produce an average that can then be used to determine the overall adherence (e.g., adherence, non-adherence) or the level (e.g., percentage, degree, etc.) of the overall adherence by the person performing the structured collection procedure to the structured collection procedure.

The adherence criteria may also be applied to a single data point/information such that, for example, biomarker data may be accepted according to a comparison of contextualized data regarding documentation and related conditions that exist or occur during the collection of a particular biomarker. The adherence criterion may be interpreted as an "acceptance criterion" if it is applied to only a single data point.

Thus, the term "acceptance criteria" may include adherence criteria that are applied to a single data point, but may also include other criteria that may be applied to a single data point. A single data point/information may then be accepted depending on the contextualized data and, furthermore, depending on the measured condition and/or result of that particular biomarker. For example, if a measurement error is detected, the biomarker reading may be rejected because the acceptance criteria are not fulfilled, e.g., due to under-dose detection or other measurement errors, which may occur and may be detected by the system. Further, other criteria defining a particular range in which measurement data may be located may be defined as acceptance criteria for a single data point/information. The acceptance criteria may be applied to the contextualized biomarker data such that a single data point/information may be accepted as a function of contextualized data regarding documentation and related conditions that exist or occur during the collection of a particular biomarker and a comparison (e.g., evaluation) of such data to a defined value/information or defined range(s) of values for the contextualized data.

Furthermore, the acceptance criteria may comprise additional criteria related to measurement errors and/or a defined range of measurement values as described above. As used herein, a biomarker or event value may be "acceptable" if the user follows the appropriate and recommended steps (i.e., adherence), and in a preferred embodiment, the resulting data is within a predicted range. For example, before a sample is taken, an acceptance criterion may be established whether the steps leading to the taking of the sample are completed. For example, the processor displays a question in response to a request, "do you fast within the last 8 hours? "wherein a yes response received by the processor via the user interface satisfies the acceptance criteria for the step. In another example, after taking the samples, the processor may use other acceptance criterion(s) to evaluate the received data for rationality. For example, based on previous data, a fasting bG sample should be between 120 mg/dl-180 mg/dl, but the received value is 340mg/dl, and thus such acceptance criteria are not met because it is outside of the predefined range for acceptable values. In such an example, the processor may prompt for additional samples. If the resampling also fails (i.e., does not fall between 120 mg/dl-180 mg/dl), the assessment provided by the processor may be that the patient is not fasting, and thus the processor (as indicated by the acceptance criteria when the resampling fails) may automatically continue with events in the schedule of events accordingly. In this particular example, the acceptance criterion may be based on an adherence criterion for a single data point (to be fasting), which is the first acceptance criterion combined with a predefined range of blood glucose values that may be expected under the condition. The acceptance criterion may be met in total only if both criteria are fulfilled.

Further, the acceptance criteria for a single data point/information may be derived from criteria generated based on other data points/information. For example, a single data point cannot be accepted if the adherence criterion of the entire collection procedure or adjacent numerical adherence criteria, for which the single data point is measured during the entire collection procedure, is below a predefined threshold. In other words, the acceptance criteria for a single data point include not only the measured adherence criteria for a particular biomarker reading but also the adherence criteria for other biomarker readings or the entire collection procedure. Further, other criteria based on adjacent or related values of a particular single data point/information may be determined. For example, if pattern recognition is applied to biomarker readings having similar contextualized data (such as relating to a single data point/information), the single data point/information may not be acceptable given the reduced reliability based on the pattern recognition. For example, if a fasting blood glucose reading is detected as being too high for a particular person in a condition of contextualized data (as compared to a biomarker reading in a similar condition), it may be assumed that the data was recorded incorrectly, even if, for example, a measurement error and/or an adherence event cannot be detected by the system itself. Thus, the acceptance criterion may be defined by a predetermined criterion, e.g. by a predetermined numerical value, but may also be defined automatically based on data generated during the collection procedure, so that a specific criterion (in particular a numerical value) may be derived therefrom. Thus, the acceptance criterion may be used to prove the reliability of the individual data points/information, so that only those values that are important and/or have high reliability may be used for further calculations. Thus, the acceptance criterion may ensure that the calculation of the insulin adjustment parameter may be based only on these values reaching a predefined condition that is necessary for a correct insulin bolus calculation and that is accepted as a value with high reliability.

The term "data event requirement" may mean a query for data collection at a single point in space-time defined by a special set of cases, e.g., defined by events that are time-dependent or not time-dependent.

The term "medical use case or problem" may mean at least one or more of a procedure, situation, condition, and/or problem that provides uncertainty about the presence or authenticity of some medical fact, and is combined with a concept that has not yet been verified, but that if true will explain a particular fact or phenomenon. Medical use cases or questions may be preloaded into the system so that the diabetic person may select between different medical use cases or questions. Alternatively, the medical use case or question may be defined by the diabetic person himself.

The terms "software" and "program" are used interchangeably herein.

FIG. 1 illustrates a long-term care management system 10 for a diabetic patient(s) 12 and a clinician(s) 14 and others 16 who are interested in the long-term care management of the patient 12. Patients 12 with writing difficulties may include those with metabolic syndrome, pre-diabetes, type 1 diabetes, type 2 diabetes, and gestational diabetes. Others 16 interested in the care of the patient may include family members, friends, support groups, and religious organizations, all of which may affect patient compliance with the therapy. The patient 12 may have access to a patient computer 18, such as a home computer, which may be connected to a public network 50 (wired or wireless), such as the internet, cellular network, etc., and coupled to the dongle, docking station, or device reader 22 for communication with an external portable device, such as a portable collection device 24. An example of a Device Reader is shown in the handbook "Accu-Chek. Smart Pix Device Reader User's Manual" (2008) available from Roche Diagnostics.

The collection device 24 may be essentially any portable electronic device that can be used as an acquisition mechanism to digitally determine and store biomarker value(s) according to a structured collection procedure, and which can be used to run the structured collection procedure and method of the present invention. More details regarding various illustrative embodiments of the structured collection procedure are provided in later sections below. In a preferred embodiment, the collection device 24 may be a self-monitoring blood glucose meter 26 or a continuous glucose monitor 28. One example of a Blood Glucose Meter is an Accu-Chek Active Meter and an Accu-Chek Aviva Meter described in the brochure "Accu-Chek Aviva Blood Glucose Meter Owner's Booklet (2007)", some portions of which are disclosed in U.S. Pat. No. 6,645,368B 1 entitled "method and method of using the Meter for determining the concentration of the acyl of a fluid", assigned to Roche Diagnostics operations, Inc., which is incorporated herein by reference. An example of a continuous glucose monitor is shown in U.S. Pat. No. 7,389,133 entitled "Method and device for connecting the monitoring of the communication of the analysis," 2008/6/17, assigned to Roche Diagnostics operations, Inc., which is incorporated herein by reference.

In addition to the collection device 24, the patient 12 may use a variety of products to manage his or her diabetes, including: a test strip 30 carried in a vial 32 for use in the collection device 24; software 34 operable on the patient computer 18, the collection device 24, a handheld computing device 36 (such as a laptop computer, personal digital assistant, and/or mobile phone); and a paper tool 38. The software 34 may be preloaded or provided via computer-readable media 40 or provided via public network 50 and loaded for operation on patient computer 18, collection device 24, clinician computer/office workstation 25, and handheld computing device 36 as needed. In other embodiments, the software 34 may also be integrated into a device reader 22 coupled to a computer (e.g., computer 18 or 25) for operation thereon, or may be accessed remotely, e.g., from a server 52, over a public network 50.

Additional therapy devices 42 and other devices 44 may also be used by the patient 12 for a particular diabetes therapy. In addition, therapy device 42 may include devices such as an ambulatory infusion pump 46, an insulin pen 48, and a lancing device 51. An example of an ambulatory infusion Pump 46 includes, but is not limited to, Accu-Chek Spirit pumps described in the handbook "Accu-Chek Spirit insert Pump System Lamp User Guide" (2007) available from Disetronic medical System AG. Other devices 44 may be medical devices that provide patient data such as blood pressure, health devices that provide patient data such as exercise information, and geriatric care devices that provide notifications to caregivers. The other devices 44 may be configured to communicate with each other according to the standards promulgated by Continua Health Alliance.

Clinicians 14 for diabetes are of a wide variety and may include, for example, nurses, nurse practitioners, physicians, endocrinologists, and other such health care providers. The clinician 14 typically has access to a clinician computer 25, such as a clinician office computer, which may also be provided with software 34. Also available on the computers 18, 25 by the patient 12 and clinician 14 are, for example, Microsoft ® health valult^TMAnd Google^TMHealth care record system 27, such as Health, to exchange information over public network 50 or over other network means (LAN, WAN, VPN, etc.) and store information, such as collected data from collection device 24, into the patient's electronic medical record, such as EMR 53 (fig. 2A) that may be provided to computers 18, 25 and/or server 52 and from computers 18, 25 and/or server 52.

Most patients 12 and clinicians 14 can interact with each other and with others having computers/servers 52 through a public network 50. Such other persons may include the patient's employer 54, third party payers 56 (such as insurance companies that pay some or all of the patient's healthcare costs), pharmacies 58 that dispense certain diabetes consumables, hospitals 60, government agencies 62 (which may also be payers), and companies 64 that provide healthcare products and services for detecting, preventing, diagnosing, and treating diseases. The patient 12 may also permit others (such as an employer 54, a payer 54, a pharmacy 58, a hospital 60, and a government agency 62) to access the patient's electronic health record through a health care recording system 27, which health care recording system 27 may reside on the clinician computer 25 and/or one or more servers 52. Reference will also be made to fig. 2 hereinafter.

Fig. 2 illustrates one system embodiment suitable for implementing a structured testing method according to one embodiment of the present invention, which in another embodiment may be part of the chronic care management system 10, and communicates with such components via conventional wired or wireless communication means. The system 41 may include a clinician computer 25 in communication with the server 52 and the collection device 24. Communication between the clinician computer 25 and the server 52 may be facilitated by a communication link to the public network 50, to the private network 66, or to a combination of both. The private network 66 may be a local or wide area network (wired or wireless) connected to the public network 50 through network devices 68 such as (network) servers, routers, modems, hubs, and the like.

In one embodiment, the server 52 may be a central repository for a plurality of structured collection procedures (or protocols) 70a, 70b, 70c, 70d, with several details of exemplary structured collection procedures being provided in later sections. The server 52 and the network device 68 may also act as a data aggregator for several of the completed structured collection procedures 70a, 70b, 70c, 70 d. Accordingly, in such an embodiment, data from the collection device(s) of the patient 12 that has completed the collection procedure may then be provided from the server 52 and/or network device 68 to the clinician computer 25 when required in response to the acquisition of patient data.

In one embodiment, one or more of the plurality of structured collection procedures 70a, 70b, 70c, 70d on the server 52 may be provided over the public network 50, such as through a secure network interface 55 implemented on the patient computer 18, the clinician computer 25, and/or the collection device 24 (FIG. 2A, showing another embodiment of the system 41). In another embodiment, the clinician computer 25 may act as an interface (wired or wireless) 72 between the server 52 and the collection device 24. In another embodiment, the structured collection procedures 70a, 70b, 70c, 70d and software 34 may be provided on the computer readable medium 40 and loaded directly onto the patient computer 18, the clinician computer 25 and/or the collection device 24. In another embodiment, the structured collection procedure 70a, 70b, 70c, 70d may be provided pre-loaded (embedded) in the memory of the collection device 24. In other embodiments, the new/updated/modified structured collection procedures 70a, 70b, 70c, 70d may be sent between the patient computer 18, the clinician computer 25, the server 52, and/or the collection device 24 over the public network 50, the private network 66, over a direct device connection (wired or wireless) 74, or a combination thereof. Accordingly, in one embodiment, external devices, such as computers 18 and 25, may be used to establish communication links 72, 74 between the collection device 24 and other electronic devices, such as other remote Personal Computers (PCs) and/or servers, such as over the public network 50, such as the internet, and/or other communication networks, such as the private network 66 (e.g., LAN, WAN, VPN, etc.).

As a conventional personal computer/workstation, the clinician computer 25 may include a processor 76 that executes programs, such as the software 34, as well as programs, such as from memory 78 and/or the computer readable medium 40. The memory 78 may include system memory (RAM, ROM, EEPROM, etc.) and storage memory, such as a hard drive and/or flash memory (internal or external). The clinician computer 25 may also include a display driver 80 to interface a display 82 with the processor 76, an input/output connection 84 for connecting user interface devices 86, such as a keyboard and mouse (wired or wireless), and a computer readable drive 88 for portable memory and disks, such as the computer readable medium 40. The clinician computer 25 may also include a communication interface 90 for connecting to the public network 50 and other devices, such as the collection device 24 (wired or wireless), and a bus interface 92 for connecting the aforementioned electronic components to the processor 76. Reference will now be made to fig. 3 in the following.

Fig. 3 is a block diagram conceptually illustrating the portable collection device 24 depicted in fig. 2. In the illustrated embodiment, the collection device 24 may include one or more microprocessors, such as processor 102, which may be a central processing unit including at least one more single or multiple cores and a cache memory, which may be connected to a bus 104, which may include data, memory, control, and/or address buses. The collection device 24 may include software 34 that provides instruction code that causes the processor 102 of the device to implement the methods of the present invention, which will be discussed in later sections. The collection device 24 may include a display interface 106 that provides graphics, text, and other data from the bus 104 (or from a frame buffer not shown) for display on a display 108. The display interface 106 may be a display driver of an integrated graphics solution that utilizes a portion of the main memory 110 of the harvesting device 24, such as Random Access Memory (RAM), and processes from the processor 102, or may be a dedicated graphics processing unit. In another embodiment, the display interface 106 and the display 108 may additionally provide a touch screen interface to provide data to the collection device 24 in a well known manner.

The main memory 110 may be Random Access Memory (RAM) in one embodiment, and may include other memory such as ROM, PROM, EPROM or EEPROM, and combinations thereof, in other embodiments. In one embodiment, collection device 24 may include secondary memory 112, which may include, for example, a hard disk drive 114 and/or a computer-readable media drive 116 for computer-readable media 40, representing, for example, at least one of a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory connector (e.g., a USB connector, a firewire connector, a PC card slot), and so forth. The drive 116 reads from and/or writes to the computer-readable media 40 in a well-known manner. Computer-readable medium 40 represents a floppy disk, magnetic tape, compact disk (CD or DVD), flash drive, PC card, or the like, which is read by and written to by drive 116. It should be appreciated that the computer-readable medium 40 may have stored therein the software 34 and/or the structured collection procedures 70a, 70b, 70c, and 70d and data resulting from completed collections performed according to one or more of the collection procedures 70a, 70b, 70c, and 70 d.

In alternative embodiments, the secondary memory 112 may include other means for allowing the software 34, collection procedures 70a, 70b, 70c, 70d, other computer programs, or other instructions to be loaded into the collection device 24. Such means may include, for example, a removable storage unit 120 and an interface connector 122. Examples of such removable storage units/interfaces may include a program cartridge and cartridge interface, a removable memory chip (e.g., ROM, PROM, EPROM, EEPROM, etc.) and associated socket, and other removable storage units 120 (e.g., hard disk drive) and interface connector 122 that allow software and data to be transferred from the removable storage unit 120 to collection device 24.

In one embodiment, the collection device 24 may include a communication module 124. The communication module 124 allows software (e.g., software 34, collection procedures 70a, 70b, 70c, and 70 d) and data (e.g., data resulting from completed collections performed according to one or more of the collection procedures 70a, 70b, 70c, and 70 d) to be transferred between the collection device 24 and the external device(s) 126. Examples of communication module 124 may include one or more of the following: a modem, a network interface (such as an ethernet card), a communications port (e.g., USB, firewire, serial, parallel, etc.), a PC or PCMCIA slot and card, a wireless transceiver, and combinations thereof. The external device(s) 126 may be a patient computer 18, a clinician computer 25, a handheld computing device 36 such as a laptop computer, a Personal Digital Assistant (PDA), a mobile (cellular) phone, and/or a dongle, a docking station, or a device reader 22. In such an embodiment, the external device 126 may provide and/or connect to one or more of a modem, a network interface (such as an Ethernet card), a communications port (e.g., USB, firewire, serial, parallel, etc.), a PCMCIA slot and card, a wireless transceiver, and combinations thereof, to provide communications, such as with the clinician computer 25 or server 52, over the public network 50 or private network 66. Software and data transferred through the communication module 124 may be in the form of wired or wireless signals 128, which may be electronic, electromagnetic, optical, or other signals capable of being sent and received by the communication module 124. For example, it is known that signals 128 can be transmitted between communication module 124 and external device(s) 126 using wire or cable, fiber optics, a phone line, a cellular phone link, an RF link, an infrared link, other communication channels, and combinations thereof. Specific techniques for connecting electronic devices via wired and/or wireless connections (e.g., via USB and bluetooth, respectively) are known in the art.

In another embodiment, the collection device 24 may be used with an external device 132, such as provided as a handheld computer or mobile phone, to perform actions such as prompting the patient to take an action, collecting a data event, and performing a calculation on information. One example of a collection device provided as a handheld computer in combination with such an external device 126 is disclosed in U.S. patent application No. 11/424,757 entitled "System and method for collecting information from floors therapeutics by means of a specified" filed on 16.6.2006, assigned to Roche Diagnostics Operations limited and incorporated herein by reference. Another example of a handheld computer is shown in the User Guide entitled "Accu-Chek @ Pocket Assembly software with Bolus calcium User Guide" (2007), available from Roche Diagnostics.

In the illustrated embodiment, the collection device 24 may provide a measurement engine 138 for reading a biosensor 140. The biosensor 140, which in one embodiment is a disposable test strip 30 (fig. 1), is used with the collection device 24 to receive a sample, e.g., capillary blood, which is exposed to an enzymatic reaction and measured by the measurement engine 138 by electrochemical techniques, optical techniques, or both, in order to measure and provide a biomarker value, e.g., blood glucose level. One example of a disposable test strip and measurement engine is disclosed in U.S. patent publication No. 2005/0016844 a1 "Reagent strips for test strips" (1/27/2005), which is assigned to Roche Diagnostics Operations limited and incorporated herein by reference. In other embodiments, the measurement engine 138 and biosensor 140 may be of a type used to provide biomarker values for other types of sampled fluids or analytes besides glucose, heart rate, blood pressure measurements, and combinations thereof. Such an alternative embodiment may be used for embodiments in which values from more than one biomarker type are required by the structured collection procedure according to the present invention. In another embodiment, biosensor 140 may be a sensor with indwelling catheter(s) or a subcutaneous tissue fluid sampling device(s), such as when collection device 24 is implemented as a Continuous Glucose Monitor (CGM) in communication with an infusion device, such as pump 46 (fig. 1). In other embodiments, collection device 24 may be a controller that implements software 34 and communicates between the infusion device (e.g., ambulatory infusion pump 46 and electronic insulin pen 48) and biosensor 140.

Data, including at least information collected by the biosensor 140, is provided to the processor 102 by the measurement engine 138, and the processor 102 may execute computer programs stored in the memory 110 to perform various calculations and processes using the data. By way Of example, such a Computer Program is described in U.S. patent application No. 12/492,667 entitled "Method, System, and Computer Program Product for Providing book Of Estimated True Mean Blood Glucose Value and Estimated Glucose (HbA1C) Value for structured distances Measurements Of Blood Glucose", filed on 26.6.2009, assigned to Roche Diagnostics Operations, Inc. and incorporated herein by reference. The data from measurement engine 138 and the results of the calculations and processing performed by processor 102 using the data are referred to herein as self-monitored data. The self-monitoring data may include, but is not limited to, values of glucose values, insulin dosage values, insulin types, and parameters used by processor 102 to calculate future glucose values, supplemental insulin dosages, and carbohydrate supplement amounts for patient 12, as well as such values, dosages, and amounts. Such data is stored in the data file 145 of the memory 110 and/or 112 along with a date time stamp 169 for each measured glucose value and administered insulin dosage value. The internal clock 144 of the collection device 24 may provide the current date and time to the processor 102 for such use.

The collection device 24 may also provide a user interface 146, such as buttons, keys, trackballs, trackpads, touch screens, and the like, for data entry, program control and navigation of options, selections and data, making information requests, and the like. In one embodiment, the user interface 146 may include one or more buttons 147, 149 for providing input and navigation of data in the memory 110 and/or 112. In one embodiment, the user may use one or more buttons 147, 149 to enter (document) contextualized information, such as data related to the daily lifestyle of the patient 12, and confirm completion of prescribed tasks. Such lifestyle data can relate to food intake, drug use, energy levels, exercise, sleep, general health, and overall well-being of the patient 12 (e.g., happy, sad, calm, stressed, tired, etc.). Such lifestyle data may be recorded into the memory 110 and/or 112 of the collection device 24 as part of the self-monitored data by navigating through a menu of options displayed on the display 108 using the buttons 147, 149 and/or through a touch screen user interface provided by the display 108. It should be appreciated that the user interface 146 may also be used to display self-monitored data or a portion thereof on the display 108, such as used by the processor 102 to display measured glucose levels and any entered data.

In one embodiment, the collection device 24 may be turned on by pressing any one or any combination of the buttons 147, 149. In another embodiment, the biosensor 140 is a test strip, and the collection device 24 may be automatically turned on when the test strip is inserted into the collection device 24 for measurement of the glucose level of a blood sample placed on the test strip by the measurement engine 138. In one embodiment, the collection device 24 may be turned off by holding down one of the buttons 147, 149 for a predefined period of time, or in another embodiment, the collection device 24 may be automatically turned off after not using the user interface 146 for the predefined period of time.

An indicator 148 may also be connected to the processor 102 and may operate under the control of the processor 102 to issue audible, tactile (vibration), and/or visual alerts/reminders to the patient regarding the daily times of bG measurements and events, such as meals, possible future hypoglycemia, and the like. The collection device 24 is also provided with a suitable power source 150, as is known, to make the device portable with power.

As previously described, the collection device 24 may be pre-loaded with the software 34 or provided via the computer-readable medium 40 and receive the signal 128 directly via the communication module 124 or indirectly via the external device 132 and/or the network 50. When provided in the latter manner, the software 34 is stored in the main memory 110 (as shown) and/or the secondary memory 112 as it is received by the processor 102 of the collection device 24. The software 34 contains instructions that, when executed by the processor 102, enable the processor to perform the features/functions of the present invention, as discussed in later sections herein. In another embodiment, the software 34 may be stored in the computer-readable medium 40 and loaded into cache memory by the processor 102, thereby causing the processor 102 to perform the features/functions of the present invention as described herein. In another embodiment, the software 34 is implemented primarily in hardware logic, e.g., using hardware components such as Application Specific Integrated Circuits (ASICs). Implementing a hardware state machine to perform the various features/functions described herein will occur to those skilled in the relevant art(s). In another embodiment, the invention is implemented using a combination of both hardware and software.

In an example software embodiment of the present invention, the methods described below may be implemented using the C + + programming language, but may be implemented with other programs, such as (but not limited to) Visual Basic, C, C #, Java, or other programs available to those skilled in the art. In other embodiments, program 34 may be implemented using a scripting language or other proprietary interpretable language used in conjunction with an interpreter. Reference will also be made to fig. 4 below.

Fig. 4 graphically depicts a data file 145 containing data records 152 of self-monitoring data 154 resulting from a structured collection procedure according to one embodiment of the invention. The data records 152 (e.g., rows) along with the self-monitored data 154 (e.g., columns in some columns) may also provide context information 156 (e.g., other columns in some columns and by row and column header information) associated therewith. Such contextual information 156 may be collected automatically during the structured collection procedure, such as by input received automatically from any of the measurement engines, biosensors, and/or other devices, or may be collected by manual input received from a user interface made by the patient in response to collection requirements (e.g., requirements displayed by the processor 102 on the display 108). Accordingly, since such contextual information 156 may be provided with each data record 152 in the preferred embodiment, such information may be readily available to the physician, and no further collection of such information is necessary after completion of the structured collection procedure, and thus need not be provided again by the patient, either manually or orally. In another embodiment, if such contextual information 156 and/or additional contextual information is collected after completion of a structured collection procedure according to the present invention, such information may be provided in the associated data file and/or record 145, 152 at a later time, such as by one of the computers 18, 25. Such information may then be associated with the self-monitoring data in the data file 145 and thus will not need to be provided again, either orally or manually. The processing in the latter embodiment may be required in the following cases: the structured collection procedure is implemented, or partially implemented, as a paper tool 38 for use with a collection device that is not capable of running the software 34 that implements the structured collection procedure.

It should be appreciated that the data file 145 (or a portion thereof, such as the self-monitored data 154 alone) may be transmitted/downloaded (wired or wireless) from the collection device 24 to another electronic device, such as the external device 132 (PC, PDA, or cell phone), or transmitted/downloaded to the clinician computer 25 via the network 50 via the communication module 124. The clinician may use the diabetes software provided on the clinician computer 25 to assess the received self-monitored data 154 of the patient 12 as well as the contextual information 156 to obtain a therapy result. One example of some of the functions that may be incorporated into diabetes software and configured FOR a personal computer is Accu-Chek 360 diabetes management System available from Roche Diagnostics, which is disclosed in U.S. patent application No. 11/999,968 entitled "METHOD AND SYSTEM FOR SETTING TIME BLOCK", filed 12, 7, 2007 and assigned to Roche Diagnostics Operations, Inc. and incorporated herein by reference.

In a preferred embodiment, the collection device 24 may be provided as a portable blood glucose meter that is used by the patient 12 to record self-monitoring data including insulin dose readings and field measured glucose levels. Examples of such bG meters mentioned previously include, but are not limited to, both Accu-Chek Active meters and Accu-Chek Aviva systems, both of which are provided by Roche Diagnostics, Inc. and both of which are resistant to Accu-Chek 360 ® Tovae systems ^。The diabetes management software is compatible for downloading test results to a personal computer,or with Accu-Chek pod Compass Software for downloading and communicating with the PDA. Accordingly, it should be appreciated that the collection device 24 may include the software and hardware necessary to process, analyze and interpret the self-monitored data and generate an appropriate data interpretation output according to a predefined flow sequence (as described in detail below). In one embodiment, the results of the data analysis and interpretation performed by the collection device 24 on the stored patient data may be displayed in the form of reports, trend monitoring graphs, and charts to assist the patient in managing their physiological condition and to support patient-physician communication. In other embodiments, the bG data from the collection device 24 can be used to generate reports (in hard copy or electronic form) by the external device 132 and/or the patient computer 18 and/or the clinician computer 25.

The collection device 24 may also provide the user and/or his or her clinician with at least one or more of the following things that may occur: a) editing data descriptions, such as titles and descriptions of records; b) storing the record at a specified location, in particular in a user-definable directory as described above; c) retrieving the record for display; d) searching for records according to different criteria (date, time, title, description, etc.); e) categorizing the records according to different criteria (values of bG levels, dates, times, durations, titles, descriptions, etc.); f) deleting the record; g) exporting the record; and/or h) performing data comparisons, modifying records, and excluding records as is known.

Lifestyle, as used herein, may be generally described as a pattern of personal habits, such as dining, exercise, and work schedules. The individual may additionally be taking medication, such as insulin therapy or oral medication that they are required to take on a regular basis. The present invention implicitly takes into account the effect of this action on glucose.

It should be appreciated that the processor 102 of the collection device 24 may implement one or more structured collection procedures 70 provided in memory 110 and/or 112. In one embodiment, each structured collection procedure 70 may be stand-alone software, providing the necessary program instructions that, when executed by the processor 102, cause the processor to perform the structured collection procedure 70 as well as other prescribed functions. In other embodiments, each structured collection procedure 70 may be part of the software 34, and may then be selectively executed by the processor 102, in one embodiment by receiving a selection from the user interface 146 from a menu list provided in the display 108, or in another embodiment by activation of a particular user interface, such as a structured collection procedure run mode button (not shown) provided to the collection device 24. It should be appreciated that the software 34 likewise provides the necessary program instructions that, when executed by the processor 102, cause the processor to perform the structured collection procedure 70 as well as the other prescribed functions of the software 34 discussed herein. A suitable example of An alternative structured collection procedure With An alternative schema provided as a collection instrument is disclosed in U.S. patent application No. 12/491,523 entitled "independent Blood Glucose Monitoring System With An alternative Interface And Methods Thereof," filed on 25.6.2009, assigned to Roche Diagnostics Operations, Inc. And incorporated herein by reference.

In another embodiment, command instructions may be sent from the clinician computer 25 and received by the processor 102 through the communication module 124 that place the collection device 24 in a collection mode that automatically runs the structured collection procedure 70. Such command instructions may specify which of the one or more structured collection procedures is to be run and/or provide the structured collection procedure to be run. In another embodiment, a list of defined medical use cases or medical issues may be presented by the processor 102 on the display 108, and a particular structured collection procedure 70 may be automatically selected by the processor 102 from among a plurality of structured collection procedures (e.g., procedures 70a, 70b, 70c, and 70 d) depending on the selection of a defined medical use case or medical issue received by the processor 102 through the user interface 146.

In another embodiment, after selection, the structured collection procedure(s) 70 may be provided via a computer readable medium (e.g., 40) and loaded by collection device 24, downloaded from computer 18 or 25, other device(s) 132, or server 52. The server 52 may be, for example, a healthcare provider or company that provides such a predefined structured collection procedure 70 for download in accordance with selected defined medical use cases or issues. It should be appreciated that the structured collection procedure(s) 70 may be developed by a healthcare company (e.g., company 64) and implemented via a web page over the public network 50 and/or made available for download on the server 52, such as shown in fig. 2. In other embodiments, the notification that a new structured collection procedure 70 is available for the collection device 24 to help resolve a particular use case/medical issue that a user (e.g., healthcare provider and patient) may have may be provided in any standard manner, such as by postal letters/cards, email, text message, guest, etc.

In some embodiments, as previously mentioned, the paper tool 38 may perform some of the functions provided by the diabetes software 34. One example of some of the functionality that may be incorporated into the diabetes software 34 and configured as paper tools 38 is Accu-Chek 360 View Blood glucose analysis System (Accu-Chek 360 View Blood glucose analysis System) paper available from Roche Diagnostics, also disclosed in U.S. patent application No. 12/040,458 entitled "Device and method for assembling Blood glucose control", filed on 29.2.2007, assigned to Roche Diagnostic Operations, Inc. and incorporated herein by reference.

In another embodiment, software 34 may be implemented on continuous glucose monitor 28 (FIG. 1). In this manner, continuous glucose monitor 28 may be used to obtain time resolved data. Such time resolved data can be used to identify fluctuations and trends that might not otherwise be noticed for on-site monitoring of blood glucose levels and standard HbA1c testing. For example, nighttime low glucose levels, high blood glucose levels between meals, early morning spikes in blood glucose levels, and how eating habits and physical activity can affect blood glucose and the effect of therapy changes.

In addition to the collection device 24 and software 34, the clinician 14 may prescribe other diabetes therapy devices for the patient 12, such as an ambulatory insulin pump 46 and an electronically-based insulin pen 48 (FIG. 1). The Insulin pump 46 typically comprises configuration Software such as disclosed in the handbook "Accu-Chek @ Insulin PumpConconfiguration Software", also available from Disetronic Medical Systems AG. The insulin pump 46, as well as the electronically-based insulin pen 48, can record and provide insulin dosage and other information to the computer, and thus can be used as another means of providing the biomarker data required by the structured collection procedure 70 (fig. 2) according to the present invention.

It should be recognized and as previously mentioned that one or more of the method steps discussed below may be configured as paper tool 38 (fig. 1), but preferably all of the method steps are carried out electronically on system 41 (fig. 2) or any electronic device/computer, such as collection device 24, having a processor and memory, and having program(s) resident in the memory. It is known that when a computer executes a program, the instruction codes of said program cause the processor of the computer to carry out the method steps associated therewith. In other embodiments, some or all of the method steps discussed below may be configured on a computer readable medium 40 storing instruction code for a program that, when executed by a computer, may cause the processor of the computer to perform the method steps associated therewith. These method steps will be discussed in more detail below with reference to fig. 5A and 5B.

A structured collection procedure is created.

Fig. 5A depicts a method 200 of creating the structured collection procedure 70 shown in fig. 5B for a medical use case or question, which may be implemented in any of the previously described devices 18, 24, 25, 26, 28, 36, 52 as standalone software, as part of the diabetes software 34, or as part of the paper tool 38. In step 202, a medical use case or issue, generally referred to hereinafter as use case(s), is selected and/or may be defined. It should be appreciated that the use case may be, for example, one selected from among the following medical use cases or questions: it is desirable to know the effect of eating a particular food; it is desirable to know the optimal time to take the drug before and/or after a meal; and hopefully the effect of exercise on bG levels. Other use cases may be issues involving: find a diagnosis, how best to initialize therapy for a patient, find a determination of the state of disease progression for a patient, find the best way to optimize patient therapy, etc. Other examples may provide a structured collection procedure 70 that may be used to help address medical issues with respect to fasting blood glucose, pre-meal glucose values, post-meal glucose values, and the like. Other medical issues may be to control the biomarkers within predefined contexts to optimize the biomarkers within predefined contexts, with therapy initiation, therapy type, oral monotherapy, oral combination therapy, insulin therapy, lifestyle therapy, adherence to therapy, therapy efficacy, insulin infusion or inhalation, insulin type, split insulin into basal and bolus (bolus), and the like. For example, medical problems with oral monotherapy and oral combination therapy may include problems involving: sulfonylureas, biguanides, thiazolidinediones, alpha-glucosidase inhibitors, meglitinide, dipeptidyl peptidase IV inhibitors, GLP-1 analogs, taslutamide, PPAR bis alpha/gamma agonists, and aleglitazar. The selected use case may be assigned to the medical use case parameter 220 depicted in fig. 5B.

In step 204, a situation or problem surrounding the selected use case may be defined. This can be done by looking at all factors that may affect the change in the use case. For example, in a use case where it is desirable to know how to best optimize patient therapy, some factors to be viewed may include stress, menstrual cycle, pre-dawn effects, background insulin, exercise, bolus timing with meals, basal rate, insulin sensitivity, postprandial behavior, and so forth, as shown in fig. 5C.

In step 206, a determination may be made as to what kind of analysis can be used to resolve or clearly visualize the situation or problem. Such an analysis may for example be selected from among: assessing changes in fasting glucose (FPG) values during the course of the collection procedure 701, monitoring one or more specific values for the duration of the collection procedure 70, determining insulin to carbohydrate (I: C) ratio, determining insulin sensitivity, determining optimal timing of dosing with respect to another variable such as meal(s), and the like. In step 208, a sample set determination may be made as to which information must be collected, such as what biomarker(s) and context(s) in which the biomarkers should be collected, and when this information needs to be collected to conduct the analysis. For example, the sample group may be defined as a string of data objects, wherein each data object comprises: target types, such as time-based types, which may use a target time (e.g., used for alarm features), time window lower bounds, time window upper bounds, etc., or data-based types, which define data types (individual, aggregate, or formula), conditions under which data is accepted (e.g., unconditional, below a certain value, above a certain value, a certain formula, etc.), collection types (e.g., user input, sensors, data, etc.), and any reminder screen text collected for each item (e.g., static and/or dynamic in terms of both formatting and value insertion). The result of this process is a schedule of collection events 222 (FIG. 5B). Next in step 210, the manner in which each or a set of collection schedule events 222 are to be implemented is then determined so as to be available to address the situation or problem of the selected use case. This may result in one or more compliance criteria 224. Additionally and/or alternatively to the manner in which collection is performed, the adherence criteria 224 can also be based on one or more biomarker values falling within a predefined range or being equal to a particular predefined value. In other embodiments, the adherence criterion(s) can be formula(s) that use biomarker data or such data sets to determine whether the resulting value falls within a predefined range or is equal to a particular predefined value.

For example, the adherence criteria 224 can describe parameters surrounding an event 237 that the patient 12 needs to perform, such as a test within a particular window, fasting for a given amount of time, sleeping for a given amount of time, exercising, low pressure, not in menstruation, and so forth. Thus, the adherence criteria 224 may establish the context of the information to be provided. The adherence criteria 224 may also be used in another context as previously mentioned to provide an assessment as to whether the data is acceptable, and may be referred to as "acceptance" criteria when used in such a context. For example, prior to taking a sample, the adherence criteria 224 can establish whether the steps that resulted in taking the sample were accomplished. For example, processor 102 displays a question in response to request 240, "do you empty in the last 8 hours? "where a" yes "response received by the processor through the user interface 146 meets the adherence criteria 224 for this step. In another example, after taking the sample, the processor 102 may utilize other adherence (acceptance) criteria to assess the reasonableness of the received data. For example, based on previous data, a fasting bG sample should be between 120mg/dl-180mg/dl, but the received value is 340mg/dl, and thus such adherence (acceptance) criteria are not met because they fall outside of a predefined range for acceptable values. In such an example, an adherence event 242 occurs, wherein the processor 102 may give a prompt for additional samples. In this case, if the resampling also fails (i.e., does not fall between 120mg/dl-180 mg/dl), then the assessment provided by the processor 102 is that the patient 12 is not fasting, and thus after the resampling fails, the processor 102 automatically extends the events 237 in the event schedule 222 accordingly as indicated by the adherence criteria.

Next in step 212, the condition(s) and context(s) under which the schedule of events 222 should begin and end may be determined. This results in one or more entry criteria 226 and exit criteria 228 being provided for the schedule of events 222, and possibly for a set of other schedules of events to which the schedule of events 222 belongs, in the case of providing a blanket structured collection procedure (e.g., procedures 70a, 70b, 70c, and 70 d) that may be run simultaneously and/or sequentially one after another.

For example, the one or more entry criteria 226 may be used to determine whether the patient satisfies the conditions for use of the collection procedure by the processor 102, where the patient 12 is checked for satisfaction of the entry criteria 226 based on, for example, the current age being within a range, the HbA1c being within a range, the patient 12 is checked for satisfaction of the entry criteria 226, the patient is checked for having a particular disease, having had the disease for a minimum period of time, having a Body Mass Index (BMI) within a range, having Fasting Plasma Glucose (FPG) within a range, having a particular drug sensitivity, being taking a particular drug dose, satisfying one or more prerequisites of another structured collection procedure, having completed one or more other structured collection procedures, not having one or more particular prerequisites (e.g., pregnancy, non-fasting, or contraindications, such as paresthesia, a disfigurement, a disease, fever, vomiting, etc.), and combinations thereof. The entry criteria 226 may also initiate the schedule of events 222 by starting events such as time of day, time of week, meal at time offset, exercise, and exercise at time offset, use of therapy medication at time offset, physiological condition, biomarker range, and biomarkers within a predetermined range calculated as an offset from a previous biomarker value. An example of a physiological condition may be when a predetermined number of physiological events (e.g., hyperglycemia, hypoglycemia, a particular temperature at a particular time of day, etc.) occur within a predefined amount of time (e.g., hours, days, weeks, etc.) then the entry criteria is met to begin the structured collection procedure. Accordingly, the entry criteria may be used to support the need for usage to meet prerequisites, an indication of usage, and/or contraindications for usage. For example, the entry criteria 226 may define a prerequisite where, in order for the structured collection procedure 70 to run an insulin sensitivity optimization, the processor 102 must first verify that the structured collection procedure for the basal titration is completed and/or has the desired result, and/or that another structured collection procedure for the insulin to carbohydrate ratio is also completed and/or has the desired result. In another example, the entry criteria 226 may be defined as a need to meet a particular use indication, where a particular structured collection procedure may provide for separate use for type 1 versus type 2 diabetics as well as various types of structured collection procedures that may be used to titrate a particular drug. In another example, the entry criteria 226 may be defined in terms of a need to satisfy a particular use contraindication, wherein a particular structured collection procedure 70 will not be run, for example, if the patient 12 is pregnant, ill, etc.

Examples of one or more exit criteria 228 may be based on a determination by the processor 102 that a particular value is reached, that an average of sample values is within a certain range, that a particular event(s) and/or condition(s) has or has not occurred, and combinations thereof. Other conditions under which the protocol may stop may include negative events, such as hypoglycemic events, the patient suffering from a disease, the patient undergoing a change in therapy, and so forth. Additional details may also be provided by the processor 102 to the patient 12 on the display 108 based on what specific exit criteria are met. For example, in one example, if patient 12 measures a glucose value indicating hypoglycemia, after exiting the protocol, processor 102 automatically executes another alternative protocol that instructs patient 12 to ingest carbohydrates and measure his blood glucose value every half hour until blood glucose exceeds 120 mg/dL. For this alternative procedure, the processor 102 may also ask the patient 12 to document his meals, activities, stress, and other relevant details in order to ensure that conditions leading to hypoglycemia are recorded. The patient 12 may also be instructed by the processor 102 to contact the clinician 14 in that situation and in other such special situations as deemed appropriate. Exit criteria may also include, for example, criteria for an end, such as exiting after a successful completion, or exiting after an indeterminate completion, such as a predetermined timeout period expiring (logistics end), e.g., no results after n days, where n =1 to 365 days, or exiting by a termination, e.g., exiting due to an unsuccessful termination by a fail-safe device. It should be appreciated that the structured collection procedure 70 may also be defined to automatically end not only based on the satisfaction of the exit criteria 228, but also when the patient 12 fails to comply with a requirement for an acceptable level of compliance and/or when the physiological state of the patient has changed such that the patient should not implement the schedule of events 222 (and thus the adherence criteria 224 is not satisfied), wherein the adherence event 242 is about to end the structured collection procedure.

In step 214, guidance 230 for the user during collection and any options 232 for customizing the collection may be determined. For example, for guidance 230, the clinician 14 may use a default list of messages or adjust messages to guide the patient 12 during execution of the collection procedure 70. As an example, a message may be provided upon a successful data acquisition (i.e., meeting adherence criteria 224) that will read "thank you. Your next scheduled measurement is at 12: 30 pm. "an alert, such as provided by the indicator 148, may also be associated with the collection procedure 70, which alerts the patient 12 to take a measurement, and may include a time delay (snooze) function if the patient 12 requires additional time to perform the measurement. The delay function and other device features will be discussed further in later sections.

The result of step 208-. In one embodiment, in generating the collection procedure 70, the clinician 14 also generates printed material that explains to the patient (at least) the following: the purpose of the collection procedure 70 and the desired result to be expected, i.e., setting a target for the collection procedure 70; collection protocol 70 design and number of measurements required; entry criteria 226 that the patient 12 must meet before initiating the collection procedure 70 and before taking each reading; and exit criteria 228 such that the patient 12 should stop continuing the collection procedure 70. Such printed material, along with guidance 230 that may be provided during execution of the collection procedure 70, ensures that the patient is fully aware of what the data collection procedure is being performed for.

Examples of structured collection procedures 70 may be, for example, structured collection procedures for determining insulin to carbohydrate ratios, for determining bolus timing with respect to meal initiation, and for determining exercise equivalent to ingested carbohydrate. In step 218, the structured collection procedure 70 is then made available for implementation and use in the system 41, for example, in the manner discussed above with respect to any of fig. 1, 2, and 3. The structured collection procedure 70 may accordingly be provided through a previous process, such as by a medical facility or healthcare company 64, to assist the clinician 14 in resolving and/or studying defined medical use cases or issues.

FIG. 5B illustrates the interaction of the parameters 222, 224, 226 and 228 of the structured collection procedure 70 for obtaining contextualized biomarker data from a diabetic patient in order to address an example of medical use that underlies the structured collection procedure. As previously described, a use case parameter 220 may be provided to identify the medical use case or problem that parameters 222, 224, 226, and 228 address. For example, the processor 76 of the clinician computer 25, the processor 102 of the collection device 24, and/or the server 52 may read medical use case parameters 220 (fig. 2) from a plurality of structured collection procedures 70a, 70b, 70c, 70d, such as provided on these devices and/or within the system 41, and provide a list of available structured collection procedures, such as on the display 82 of the clinician computer 25 or the display 108 of the collection device 24. Further, the clinician computer 25, patient computer 18, and/or server 52 may use the medical use case parameters 220 to locate/categorize/filter such structured collection procedures according to the medical use case(s).

As previously described, the entry criteria 226 establish requirements for initiating the structured collection procedure 70 in order to obtain patient data including biomarker data collected particularly in a predefined context. In one example, the processor 102 of the collection device 24 may use the entry criteria 226 to determine when the associated structured collection procedure 70 is appropriate for the physiological context of the patient and to ensure that all necessary inputs for the associated structured collection procedure have been established. It should therefore be appreciated that the start date and/or time of the structured collection procedure may be dynamically changed automatically by the processor 102 of the collection device 24 if the predefined condition(s) of the entry criteria 226 are not met. Accordingly, until the entry criteria 226 are satisfied, the start date and/or time of the associated structured collection procedure 70 may be some unknown time in the future.

For example, in one embodiment, the structured collection procedure 70 may be automatically selected by the processor 102 from among multiple structured collection procedures 70a, 70b, 70c, 70d, such as provided in the memory 110 of the collection device 24, provided in the memory of the computers 18, 25, and/or from the server 52, based on the condition(s) satisfying the defined entry criteria 226 for the associated structured collection procedure. For example, in one embodiment, a first structured collection procedure, such as procedure 70d, may be used to display a trend in blood glucose levels ("bG level trend"). Thus, the entry criteria 226 for the first structured collection procedure 70d can be that the patient's bG level mean rises above a certain predefined rate over a defined period of time (e.g., the past days, weeks, and months from the current date). For a second structured collection procedure, such as procedure 70a, its entry criteria 226 may require that a certain number of bG measurements measured for a pre-breakfast within a defined time period (e.g., the past days, weeks, and months from the current date) be below a predefined bG value. In such an example, at startup in one embodiment, upon being commanded (such as by input received via a user interface in another embodiment), or at scheduled time programmed by the software 34 in another embodiment, the processor 102 may run a traversal of the various entry criteria 226 provided by the various structured collection procedures 70a and 70d (which are provided, for example, in the memory 110 of the collection device 24) and determine whether the declared condition(s) for the entry criteria 226 of a particular procedure 70 are satisfied. In this example, the processor 102 determines that historical data from past measurements in the memory 110 indicates that the bG level mean of the patient has risen and that the entry criteria 226 for the first collection procedure 70d have been met, but that the entry criteria for the second collection procedure 70a have not been met. In this example, the processor 102 then automatically selects and initiates the first structured collection procedure 70d based on the foregoing analysis.

It should also be appreciated that the use of the entry criteria 226 may help reduce the improper allocation of medical overhead by ensuring that the instructions for use of the structured collection procedure 70 are satisfied before beginning the collection event schedule 222. Entry criteria 226 may also help ensure that any requirements for performing multiple structured collection procedures do not overlap if incompatible, do not unnecessarily repeat with each other, and do not place a significant burden on the patient. Thus, by using the entry criteria 226, the processor 102 of the collection device 24 can simultaneously solve and automatically avoid many of the noted problems, wherein the patient can avoid any further attempts to diagnose their chronic disease or optimize therapy.

As shown in fig. 5B, entry criteria 226 may include context-specific entry criteria 234, procedure-specific entry criteria 236, and combinations thereof. Examples of context-specific entry criteria 234 may include one or more variables to identify meals, hypoglycemic events, insulin types and doses, stress, and so forth. In another example, the context-specific entry criteria 234 may be defined, for example, in the form of a specific question(s) for which the processor 102 requires a specific answer to be received from the patient via input from the user interface 146. For example, the processor 102, when executing the entry criteria 226, may display on the display 108 questions regarding whether the patient is willing and able to perform the structured collection procedure 70 within a required period of time. If the patient gives a positive answer via the user interface 146, the entry criteria 226 are met and the processor 102 continues to automatically administer the collection event 237 according to its associated timing as defined in the structured collection procedure 70. If the patient answers the displayed question in the negative, the processor 102 will not continue the structured collection procedure 70 and may reschedule the question to a future time, for example, if the option parameter indicates.

Examples of protocol-specific entry criteria 236 may include one or more variables to identify disease states, disease conditions, selected therapies, parameter preconditions, insulin to carbohydrate ratios prior to testing for insulin sensitivity, incompatible collection protocols, and the like. The procedure-specific entry criteria 236 may be defined such that the processor 102 will automatically continue the structured collection procedure 70 for one of three initiators, for example, the patient 12, the clinician 14, or the data if the condition(s) of the entry criteria 226 are satisfied. For example, if the clinician 14 specifies a structured collection procedure 70, such as by an authorized user entering a valid password via the user interface 146 in one embodiment in order to unlock the particular structured collection procedure for use, the procedure-specific entry criteria 236 may be satisfied. In another embodiment, the clinician 14 may send a password or authorization code from the clinician computer 25 and/or server 52 to the collection device 24, the collection device 24 specifying (authorizing) the use of the collection procedure 70 by the patient 12 on the collection device 24. It should be appreciated that one or more structured collection procedures 70 may be provided in the memory 110 of the collection device 24 that is not usable by the patient 12, or may be hidden from view on the display 108 (e.g., in a selection list) by the patient until authorized by the clinician 14.

The procedure-specific entry criteria 236 may be satisfied, for example, by the user by selecting a particular structured collection procedure 70 from among the list of structured collection procedures 70a, 70b, 70c, 70d provided on the display 108. One example of a data-initiated procedure for criteria 236 would be that the biomarker measurement(s) provided to processor 102 indicate a positive occurrence or the existence of a condition such that entry criteria 226 for a particular structured collection procedure are satisfied. Such a condition may be, for example, the occurrence of a single event, such as a severe hypoglycemic event, or the occurrence of a series of events, such as hypoglycemic events within a given predetermined time range, such as within 24 hours from a start time, within a week from a start time, etc., a calendar date time, etc.

Accordingly, the entry criteria 226 may be a single criterion or multiple criteria that establish the context and/or condition of the patient's physiology in relation to the medical use case addressed by the structured collection procedure 70. In another embodiment, the entry criteria 226 may be evaluated after the patient data is collected, such as with respect to historical patient data.

The schedule of events 222 specifies one or more events 237, each of which includes at least one or more variables defining an administration time 238, instructions 230 for administering the event, requirements 240 for patient actions, which may include requirements for information from the patient and/or requirements for collecting at least one type of biomarker data from the patient, and combinations thereof. For the delivery times 238, the schedule of events 222 may specify the timing of each event 237, such as biomarker sampling at a particular time of three consecutive weekdays, or one sample taken at wake-up, one sample taken thirty minutes later and another sample taken one hour later.

The guidance 230 for each event 237 and for any criteria 224, 226, 228 may include, for example, providing an electronic reminder (acoustic, visual) for: start, end, and/or wake up at specific times, perform bG collections at specific times, ingest specific meal or food(s) at specific times, perform specific exercise(s) at specific times, take medications at specific times, and so forth. The guidance 230 may also include information, questions, and requirements for recording specific information about physiology, health, well-being, etc. at a particular time, recommendations for improving compliance with the collection procedure, encouragement, and positive/negative feedback.

It should be appreciated that the event 237 defines all steps that need to be performed before and after biomarker sampling according to the requirements 240, thereby creating a reproducible set of conditions, i.e., context before and/or after sampling, in the biomarker data for the biomarker sampling. In the context of diabetes, examples of such biomarker data include fasting blood glucose values, preprandial glucose values, postprandial glucose values, and the like. An example of a set of circumstances can include data associated with biomarker values that identify collected information in patient data about meals, exercise, therapy administration, sleep, hydration, and the like.

Each event 237 in the schedule of events 222 can be time-based, event-based, or both. Event 237 may also be a meal start, a wake time, an exercise start, a therapy administration time, a relative offset used with previous glucose values, or a time indicating movement above or below a predetermined biomarker value threshold. The events 237 may also include any desired patient actions that must be performed before and during biomarker sampling, thereby creating a reproducible condition at the time of biomarker sampling. This aspect may include one or more of meals, exercise, therapy administration, sleep, hydration, and the like. In addition, the events 237 in the schedule of events 222 can be adjusted (number, type, timing, etc.) to accommodate the work schedule of the patient 12, stress factors, and so forth.

As previously described, the adherence criteria 224 are used to qualitatively assess whether an event 237 administered according to the schedule of events 222 provides data that is acceptable in addressing the medical use case underlying the structured collection procedure 70. In particular, the adherence criteria 224 can provide variables and/or values that are used to validate data from the performed events 237. For example, the adherence criteria 224 may be a check performed by the processor 102 of the collection device 24 of whether the value collected in response to the event 237 is within a desired range or is above, below, or at a desired value, where the value may be time, quantity, type, and so forth. In one embodiment, the same or different adherence criteria 224 may be associated with each event 237 within the schedule of events 222 and with the entry criteria 226, and in another embodiment as the exit criteria 228, such as shown in FIG. 6D (i.e., "stop exercise when bG comes back within target range," which defines both adherence and exit criteria). In one embodiment, one or more events 237 in the schedule of events 222 can be modified (e.g., added, deleted, delayed, etc.) if one or more particular events do not meet the adherence criteria 224 for the one or more particular events. In one embodiment, failure of the adherence criteria 224 may trigger an adherence event 242. In one embodiment, upon occurrence of an adherence event 242 because the associated adherence criteria 224 for the event 237 was not met or satisfied, one or more additional actions may be required by the processor 102 as a result. For example, processor 102 may prompt the patient for additional information on display 108 and/or a question to determine whether patient 12 is ill, stressed, or unable to perform a request, such as a meal or exercise. If the patient answers "yes," e.g., via the user interface 146, the processor 102 may provide a delay (i.e., pause) to the schedule of events as part of the adherence event 242. In one embodiment, the delay may continue until the patient indicates that his or her condition is better in response to another question prompted by the processor 102, such as on the next day or after a predefined amount of time and also as part of the adherence event. For example, the processor 102 prompts the patient 12 to take a medication, but the patient is not at home, and his/her insulin is, for example, at home. The patient 12 may select a delay via the user interface 146 where the processor 102 again alerts the patient after a predetermined amount of time. The delay may also have an upper limit where the fabric collection procedure 70 may end as it is if the schedule of events 222 has not restarted within a certain amount of time. In another embodiment, another form of adherence event 242 is a violation event that results when the person performing the structure collection procedure 70 is not able to make the recommended changes in response to the request. For example, the request may be to have the patient adjust the medication dose from 10U to 20U, wherein the patient answers a negative question displayed on the display 108 asking whether the patient is about to or has complied with the change. In response to such violation events, the processor 102 may also send messages and/or provide delays, as discussed above with respect to the adherence event.

In another example and in one embodiment, the bG measurements must be collected once before each meal in order for the structured collection procedure 70 to provide data that can be used to solve the medical use case or problem for which it is designed (such as identified by the use case parameters 220). In this example, if the patient is not able to take bG measurements for lunch in response to the requirements 240 for the collection according to the schedule of events 222, and thus the adherence criteria 224 for that event 237 fails to be met, the processor 102, in response to the associated adherence event 242, may be programmed according to instructions in the collection procedure 70 to cancel all remaining events 237 for that day in the schedule of events 222, mark the morning bG measurements stored in a data file (such as the data file 145 in fig. 4) as invalid, and reschedule the schedule of events 222 for the next day. Other examples of further actions that may be taken by the processor 102 in response to the adherence event 242 may be: dynamically changing the structured collection procedure by switching to a schedule of secondary events that may make it easier for the patient to perform, providing additional events to the measurements to make up for missing data, changing the exit criteria from the primary exit criteria to the secondary exit criteria to provide modified criteria(s), changing the adherence criteria from the primary adherence criteria to the secondary adherence criteria, populating the missing data for a failed event with historical data (in an estimation format), performing specific calculations to see if the structured collection procedure 70 can still be successfully performed, sending a message to specific personnel (such as a clinician) regarding the failed event, providing specific indications in the associated data records 152 to ignore or estimate missing data points, and so forth. In other embodiments, the adherence criteria 224 may be dynamically evaluated, for example, based on one or more biomarker values and/or input received from a user interface in response to one or more questions, by an algorithm that determines whether the collected data provides a value that may be used to address the medical use case or example. In this example, if the calculated adherence value is not useful, e.g., does not fall within the desired range or does not meet a particular predefined value, then further processing as defined by the resulting adherence event will occur later, such as any one or more of the processes discussed above.

As previously described, the exit criteria 228 establish requirements for exiting or completing the structured collection procedure 70 such that the structured collection procedure 70 has sufficient contextual data to answer the medical question addressed by the structured collection procedure 70. The exit criteria 228 may help increase the efficiency of the structured collection procedure 70 by minimizing the number of samples required to address a medical use case. "resolve" means that sufficient patient data must be collected so that the clinician 14 can give an assessment of the medical use case. In other embodiments, the evaluation may be represented by a given confidence interval. Confidence intervals are a set of discrete or continuous values that are statistically assigned to a parameter. The confidence interval typically includes the true value of the parameter over a predetermined portion of time.

As with entry criteria 226, exit criteria 228 may include one or more of context-specific exit criteria 244, procedure-specific entry criteria 246, and combinations thereof. Examples of context-specific exit criteria 244 may include one or more variables to identify mood, desired glycemic event (i.e., blood glucose level), to indicate stress, illness, contraindications (such as hyperglycemia, hypoglycemia, vomiting, fever, etc.). Examples of protocol-specific entry criteria 246 may include one or more variables to identify a number of events that satisfy the adherence criteria, a biomarker value within a desired predetermined range and/or at a desired predetermined value, a desired disease state, a desired disease condition, no change in the biomarker after a predetermined period of time, no apparent progression to the desired biomarker value within a predetermined period of time, and so forth. It should be appreciated that in one embodiment, the exit criteria 228 may establish the condition(s) that need to be met for the entry criteria 226 of the second structured collection procedure 70. For example, after determining the appropriate insulin to carbohydrate ratio (I: C) for a first collection procedure (e.g., the structured collection procedure 70B in fig. 6B), a structured test for determining the optimal time to administer perfusion for meal initiation is run, such as the structured collection procedure 70C (fig. 6C) requiring the current I: C ratio, which may be adjusted so that the processor 102 may automatically implement the schedule of events for the second structured collection procedure 70C after the exit criteria for the first structured collection procedure 70B are met at some unknown time. In other embodiments, the exit criteria 228 of the first structured collection procedure 70 and the entry criteria 226 of the second structured collection procedure 70, e.g., being run by the processor 102 according to the schedule of events 222, may both be based on, e.g., the same one or more of the contraindications mentioned above. In such an embodiment, the processor 102 will automatically start the schedule of events for the second structured collection procedure 70 after occurrence of a contraindication (which in this example satisfies the exit criteria 228 of the first structured collection procedure 70) provided to the processor 102 and/or detected by the processor 102, for example via the user interface 146 and/or the biosensor 140, respectively, because the entry criteria 226 of the second structured collection procedure 70 have also been satisfied. An example of the second structured collection procedure 70 that may be initiated by exiting the first structured collection procedure may be one having a schedule of events 222 that requires biomarker samples to be taken at routine intervals, such as every 30 minutes, hour, specific time of day, etc., until the contraindication(s) are cleared (e.g., the biomarker value(s) reach a desired range or value, the patient 12 indicates to the processor 102 via the user interface 146 that there are no more contraindications(s), a predefined period of time expires, etc.). Such an embodiment is useful if it is desired to record the context and value of the event following the occurrence of the contraindication(s) and the first collection procedure should be exited upon the occurrence of the contraindication(s).

The exit criteria 228 may be a single criterion or multiple criteria that establish conditions for exiting the structured collection procedure 70. The conditions are provided in a preferred embodiment to ensure that sufficient contextualized biomarker data has been obtained to answer the medical question addressed by the collection method. For example, such that a predetermined number of valid samples are acquired, or such that variability in the samples is below a predetermined threshold. It should therefore be appreciated that the end date and/or time of the collection procedure 70 may be dynamic and may be automatically changed by the processor 102 if the predefined condition(s) of the exit criteria 228 are not met. Likewise, the conditions for exiting the criteria 228 may be dynamic and may be automatically changed by the processor 102, for example, with or without the particular adherence criteria 224 being met. For example, in one embodiment, if the adherence criteria 224 for a particular collection event 237 is satisfied, the processor 102 is instructed to use a first exit criterion, and if not, the processor 102 is instructed to use a second exit criterion different from the first exit criterion. Accordingly, until the exit criteria 228 are met, the end date and/or time of the structured collection procedure 70 may be some unknown time in the future. In another embodiment, the exit criteria 228 may be evaluated after the patient data is collected, for example, with respect to historical patient data.

It will be appreciated that the entry and exit criteria 226, 228 in conjunction with the adherence criteria 224 may help to shorten the time to perform the structured collection procedure 70 and reduce the overhead associated with the collection by defining one or more of acceptable conditions, values, structures, and contexts required to perform the schedule of events 222 so as to count each collection event 237 and/or reduce the test strips 30 consumed in terms of unwanted collections that do not help address medical use instances or issues. Reference will be made to fig. 6A-6E hereinafter.

Structured collection procedure example.

6A-6E illustrate examples of some structured collection procedures 70a, 70b, 70c, and 70d depicting functions that may be readily converted by one of ordinary skill in the relevant art into instruction code that may be implemented on any of the devices 18, 24, 25, 26, 28, 36, 52 described above. Accordingly, a discussion of the pseudo-code or actual code for the functions shown is not provided for the sake of brevity.

FIG. 6A illustrates by way of illustration one embodiment of a structured collection procedure 70a that is used to obtain contextual biomarker data from a diabetic patient. The horizontal axis shows the performance time 238 of various events 237 and the vertical axis shows the adherence criteria 224 without numerical values. In the illustrated embodiment, the events 237 may include recording information about meal 248 and sleep 250 to provide context 252 for five biomarker samples 254, and the events 237 are also part of the schedule of events 222. In this example, the adherence criterion 224 for the meal 248 may be a value, which must be higher than a minimum value, for example for a certain amount of carbohydrates. The entry criteria 226 may include, for example, that the biomarker value is above a particular value, such as the particular value needed to satisfy the contextualization requirements for starting the structured collection procedure 70 a. The exit criteria 228 may also include that the biomarker value is below a particular value, such as the particular value needed to satisfy the contextualized requirement for the end structured collection procedure 70 a. Such a structured collection procedure 70 may be used to help address several instances of medical use.

GLP 1 structured collection procedure.

For example, several epidemiological studies have demonstrated that elevated postprandial glucose (PPG) levels are an important predictor of cardiovascular mortality and morbidity with respect to type 2 diabetes (T2D). To this end, there is a series of human glucagon-like peptide-1 (GLP 1) drugs that act over an extended period of time once a week and that can be prescribed to T2D patients who exhibit elevated postprandial bG values. These GLP 1 drugs resemble the natural hormone GLP-1, which plays an important role in blood glucose regulation by stimulating insulin secretion and inhibiting glucagon secretion. Thus, in one embodiment, a structured collection procedure 70 can be provided that proposes making a large number of measurements of bG values over time during a time after one or more meals, thereby allowing for the efficacy of therapy to be demonstrated through the observed reduced postprandial bG values. Based on such observed values, it may be determined whether a dose recommendation for the GLP 1 drug and/or a particular GLP 1 drug is the completely correct drug for the patient.

For example, when a patient is prescribed a particular medication (e.g., a GLP 1 medication), the structured collection procedure 70 may be provided on the collection device 24. In the case of a GLP 1 drug, where it is desired to determine drug efficacy, the entry criteria 226 for such a structured collection procedure may then be that the patient must confirm that the processor 102 performed the structured collection procedure 70 for a period of time (e.g., for the next 4 to 24 weeks) in response to a question displayed on the display 108, and/or that the processor 102 determined that the patient's average PPG level was high (e.g., above 141 mg/dl) from previous postprandial bG values over a period of time (e.g., weeks, months, etc.). Other factors may also be used as entry criteria 226, such as fasting glucose being above a certain value (e.g., 126 mg/dl) or below a certain value (e.g., 240 mg/dl).

The schedule of events 222 is then automatically run by the processor 102 after the conditions of the entry criteria 226 are satisfied and verified by the processor 102. The schedule of events 222 will indicate the desired collection events 237, where the processor 102 will automatically prompt the patient to enter a post-meal bG value after breakfast, lunch, and dinner (i.e., perform a bG measurement on a sample provided to a test strip that is read by the measurement engine and provided to the processor for storage in the data record and display). The schedule of events 222, by being customized by the prescribing physician, can also define a collection event 237 having an administration time 238 where the patient must take the medication and provide a dose reminder when the medication has been taken and a requirement 240 for confirmation from the patient. For example, the processor 102, when executing the schedule of events 222, will automatically prompt the patient to take a dose, for example 10mg of Taspoglutide, on a particular day of the week at the time specified by the collection event 237 in the schedule of events 222, and then take a second dose according to a second interval (e.g., after 4 weeks) after a certain period of time, followed by 20mg also on a particular day of the week. A collection event 237 may also be defined in the schedule of events 222 where the processor 102 presents a request for information on the display 108, such as whether the patient feels good, to provide an indication of energy level, to provide an indication of the number of meals eaten, and so forth.

The condition(s) of adherence for each entered post-meal bG value can be provided by using adherence criteria 224, where before or after a certain amount of time of the prompt (e.g., before or after the prompt)Measurement for 30 minutesTest window) that will not be accepted by the processor 102 as a valid measurement for the schedule of events 222. In one embodiment, the processor 102 may automatically take further action based on the adherence criteria 224 assessment automatically performed by the processor 102. For example, if the bG measurement is taken before the measurement specified by the collection event in the event schedule 222 and falls outside of a defined test window, e.g., -30 minutes before the collection event time, the processor 102 in this case will automatically notify the patient that the measurement still needs to be taken at the specified time because the previous measurement was not accepted because it falls outside of the test window. Likewise, if after the test window, for example, the collection event time +30 minutes, the processor 102 may automatically notify the patient that the previous measurement was not accepted as falling outside the test window and provide an incentive on the display 108 to cause the patient to struggle to take measurements within the test window.

The exit criteria 228 for such a GLP 1 structured collection procedure 70 can be an indication that the bG mean has reached a desired value using a minimum amount of time (e.g., days, weeks, months, etc.), a minimum number of acceptable measurements, or both. Likewise, the exit criteria 228 can be an indication that the bG mean has not reached a desired value after a maximum amount of time (e.g., days, weeks, months, etc.), a maximum number of acceptable measurements, or both. Further, the exit criteria 228 may be other factors that indicate that the medication or dose is completely inappropriate for the patient, such as nausea and/or vomiting for each of the minimum number of days in response to a collection event prompted by the processor 102 on the display 108 for such information. Other factors may also be used as exit criteria 228, such as fasting glucose being below a particular value (e.g., 126 mg/dl) or above a particular value (e.g., 240 mg/dl). The data collected from such a drug-based structured collection procedure 70 can then be used by a physician to make dose recommendations for GLP 1 drugs and/or to determine whether a particular GLP 1 drug is the correct drug for a patient.

Another example is illustrated in FIG. 6B, which shows a structured collection procedure 70B with defined medical use case parameters 220 that indicate that the procedure may be helpful in determining the appropriateness of insulin to carbohydrate (I: C) ratio. As shown, the entry criteria 226 are defined as the patient simply confirming instructions 230 on selecting a fast-acting meal, which should note that the insulin dose is calculated for the current I: C ratio, and agrees not to exercise and not to ingest additional food or insulin during the test period. For example, the processor 102 may present such guidance 230 on the display 108 that the user may confirm after reading by entering "yes" or "no" for the desired entry selection using the user interface 146. If the user enters "yes," the entry criteria 226 are met and the processor 102 automatically begins the schedule of events 222 defined in the structured collection procedure 70 b. In another embodiment, the entry criteria 226 may be or include meeting a requirement 237 for selection of a fast-acting meal. The request 237 for a selection may be, for example, the processor 102 displaying a menu of selections on the display 108 that provide a list of quick-acting meals that require entry of such selections through the user interface 146. For example, the selection of a quick-acting meal may be made by pressing one of the buttons 147, 149 or through a touch screen interface (if provided by the display 108). Such selections may then be stored in the memory 110 of the collection device 24 as settings data 163 (FIG. 4), which may be part of the data file 145 (FIG. 4) for the structured collection procedure 70 b. In an alternative embodiment, a specific fast-acting meal may be recommended by the structured collection procedure 70 b.

As shown, the schedule of events 222 may include one or more events, such as the plurality of events 237a-k shown, and each of which has an associated delivery time 238a-k and an action requirement 240 a-k. As shown, the action requirements 240a-c and 240f-k are for the userA requirement for bG level measurement is taken that 240d is for ingestion of a dose of insulin and 240e is for eating the fast-acting meal. It is further shown that the events 238f-k each have an adherence criterion 224, which adherence criterion 224 must be met if the data for the event 238f-k is to be recorded in the data file 145. In this example, the adherence criteria 224 require that at their respective delivery times 238f-kActions 240f-k are completed within 20 minutes to cause the data records 152 that record the value(s) received for the respective event 237f-k to be counted for completion of the collection procedure 70 b. In one embodiment, the processor 102 will place each of the requirements 240a-k at its associated delivery time 238a-k to obtain a resulting data value, such as data values 256a-k (FIG. 4), for example, at the time the requirement is delivered.

For example, the processor 102 may utilize the requirement 240a to prompt the patient 12 to take a bG level (biomarker) measurement at the delivery time 238 a. Upon receipt of the resulting measurements by the processor 102, such as automatically from the measurement engine 138 after reading the test strip (biosensor) 140 for the desired biomarker, the measurements are automatically recorded by the processor 102 in the data file 145 as corresponding data values 256a for the associated event 237 a. With respect to actions 240d and 240e, the processor 102 may automatically prompt the patient 12 at a desired time to take a prescribed action at the desired time, and then again automatically prompt the patient to confirm that the desired action has been taken, or that a predefined condition has been reached. Date timestamp 169 may also be automatically provided in date record 152 by processor 102 in the following cases: upon triggering the claim 240a-k, upon acknowledging the claim 240a-k, upon completing the event 237a-k, upon receiving the data value 256a-k for the event 237a-k, and combinations thereof. Moreover, in another embodiment, the patient 12 can record the data values 256a-k for one or more events 237a-k by inputting the data directly into the device 24 via the user interface 146, wherein the processor 102 stores the input data values/information in the associated data record 152 for the event 237a-k, or in other embodiments can record a voice message with the information for later transcription into digital data. In other embodiments, the patient 12 may be instructed by the collection device 24 to record data for the events 237a-k using the paper tool 38.

As previously described, each event 237 may be a record of a biomarker value, or a requirement for a required patient action (such as eating, exercise, therapy administration, etc.) necessary to generate a context for the biomarker value. In the illustrated embodiment, the scenario 252 for completion events 237a-c is to establish a pre-meal baseline and trending-free condition, and for events 237f-k is to establish post-meal drift and tail. The context 252 for these events may also be associated with the respective data record 152 for each event as context information 156 (FIG. 4). Such information is useful later when reconstructing the data and/or when it is desired to know the context for generating the data records.

It should be appreciated that any patient actions taken in addition to the required requirements for the patient actions 240a-k may also be recorded by the processor 102, but will not be considered by the processor 102 as part of the collection procedure 70 b. The expected data 256a-k for the events 237a-k may be identified based on event type, event time, event trigger, and combinations thereof. Each delivery time 238a-k may be fixed or variable based on previous data. In other embodiments, some of the events 237a-k may also be past, current, or future events, such as meals, workouts, etc., or data values for hypoglycemic events, hyperglycemic events, for example, or data of particular values of interest. In some embodiments, the events 237a-k may be identified by a protocol-based paper tool 38.

Further, as shown, if the conditions of the exit criteria 228 are met, the structured collection procedure 70b will end. In this example, the exit criteria 228 are satisfied if at least three of the actions 240f-k satisfy the adherence criteria 224. For example, if desired, the processor 102 may provide a unique identifier (e.g., one or more numbers, letters, and/or characters, such as an incremented count, indicator, etc.) 167 (FIG. 4) in the data file 145 for each event 237a-k performed and satisfying the adherence criteria 224 that will occur only once in the data file to identify the data associated therewith. In the illustrated embodiment of FIG. 4, each of the events 237a-c and 237e-k receives a unique identifier, but event 237d does not (e.g., < NULL >) because it does not satisfy the associated adherence criteria (not shown). Further, in one embodiment, the analysis logic 258 and resulting recommendations 260 may also be provided in the structured collection procedure 70b, which the processor 102 may automatically apply to the collected data when the exit criteria 228 are met.

Similar features are also provided in the examples shown in fig. 6C and 6D, where fig. 6C depicts a structured collection procedure 70C with defined medical use case parameters 220 that indicate that the procedure is useful for determining the appropriateness of a bolus for meal initiation. Likewise, fig. 6D depicts a structured collection procedure 70D with defined medical use case parameters 220 that indicate that the procedure is useful for determining the appropriateness of exercise equivalent to carbohydrate intake. In addition to the foregoing examples, other such structured collection procedures may be designed to address other various medical use cases, such as the following: determining the effect of eating a particular food on the patient's biomarker levels; determining an optimal time to take the drug before and/or after a meal; and determining the effect of a particular drug on the patient's biomarker levels. Other structured collection procedures may also be provided that may be used to address issues related to: how to optimally initialize a therapy for a patient, find a determination of the state of disease progression for a patient, find the best way to optimize a patient's therapy, etc. For example, the clinician 14 may define and/or use a pre-defined structured collection procedure 70 that looks at various factors that may have an effect on the patient's therapy. Such factors may include, for example, stress, menstrual cycle, premenstrual effects, background insulin, exercise, bolus timing with meals, basal rate, insulin sensitivity, postprandial behavior, and the like.

Fig. 6E shows a diagram of a structured collection procedure 70 that includes one or more multi-sample packets 262, where each packet includes a schedule of events 222 that provide recurrence between entry criteria 226 and exit criteria 228. In this example, the schedule of events 222 includes one or more events 237 that occur each day during a consistent time of day. Since the structured collection procedure 70 may span many days, even weeks, and/or months in obtaining the contextualized biomarker data from the diabetic patient 12 before the exit criteria 228 are met, one or more checks 264 (such as for parameter adjustments) and/or an assessment of whether to rerun the sampling package 262 may also be provided in one embodiment between the entry and exit criteria 226, 228. The duration between such checks 264 can be used for physiological system equalization, assessing treatment efficacy, or convenience. For example, analysis of the check 264 may be performed by the processor 102, either between each sample packet 262 or after a predetermined number of such sample packets 262 (as shown), in order to determine whether any parameters in the collection procedure 70 need to be adjusted.

Such analysis may be for parameter optimization or efficacy assessment, for example. For parameter optimization, the processor 102 may use information from previous optimizations, parameters set by a clinician, and collection or therapy strategies to run calculations on samples provided in the previous schedule of events 222 or sample groupings 262, recommending new parameter values. For efficacy assessment, the processor 102 may assess data not utilized by the optimization analysis. It should further be appreciated that after taking a set of samples (i.e., sample set 262), the processor 102 may also assess data from the sample set 262, such as whether such data is needed to alter/optimize the individual's therapy. The adherence criteria 224 may be applied to perform this assessment on the data of the sample set 262. For example, the processor 102 may use the first adherence criteria 224 to evaluate whether the sample set 262 provides a minimum amount of data and, if not, a change/optimization to the patient's therapy, for example, will not occur. Another adherence criterion 224 may allow the processor 102 to evaluate whether the data is acceptable to allow for the adjustments required by the check 264, such as to see if the spread of the data, variability (noise) is too high, and to use other data attributes of the data. In this example, if such adherence criteria are met, the processor 102 makes the following evaluation: adjusting the parameters of the protocol may easily result in a minimal risk of a serious event, such as a hyperglycemic or hypoglycemic event. Finally, the processor may use the adherence criteria to evaluate the exit criteria 228 based on the data of the sample group, e.g., the exit criteria is met when the data from the sample group 262 meets the adherence criteria, e.g., as discussed above for the sample group.

It should be recognized that collection or therapy strategies can be categorized as either scale-based (sliding or fixed) evaluations or formula-based evaluations. As input to the collection or therapy strategy, in one embodiment, the processor 102 may utilize data collected from a predetermined number of previous sample grouping(s) 262. This data can be used as individual points (formula-based collection or therapy strategies only), or combined with filtering for scale-based evaluation. In another embodiment, the results of the check 264, e.g., performed by the processor 102, may also result in a status or recommendation being automatically provided by the processor 102. Such a state or recommendation may be, for example, a state to continue with a current parameter value, a recommendation to change a particular parameter, a recommendation to change an adherence and/or exit criteria, a state to switch to a secondary adherence and/or exit criteria based on an analysis performed on data from a previous schedule of events or a previous sample packet, or a recommendation to terminate a collection procedure, etc. A discussion of performing a structured testing method using a structured collection procedure according to one embodiment of the present invention will be provided below with reference to fig. 7A.

Structured testing method.

Fig. 7A depicts a structured testing method 300 for diagnostic or therapy support for a patient with a chronic disease. The method 300 may be implemented as instruction code of a program running on a computer having a processor and memory, such as preferably the clinician computer 25 (FIG. 2) as stand-alone software, as part of the software 34, or as software provided as a service by the server 52 over a secure network implementation over the public network 50. When the processor 76 executes the program from the memory 78 of the clinician computer 25, as one of the functions, the processor 76, upon receiving a query for medical use cases and/or questions, searches the memory 78, the computer-readable medium 40, and/or the server 52 for all structured collection procedures 70a-d that match the query submitted in step 302. For example, in one embodiment, the processor 76 may read the medical use case parameters 220 for each available structured collection procedure 70a-d and provide selection options on the display 82 for those structured collection procedures that match the query using conventional search algorithms (e.g., lists, trees, heuristics, etc.) in step 304.

In one embodiment, the displayed list may reflect, for example, structured collection procedures 70a, 70b, 70c, and 70d that may be obtained from the server 52 for use. In another embodiment, the displayed list of selection options may be dynamically created based on the type of medical use case that the clinician 14 wants to study. For example, prior to step 302, a list of selectable medical use instances may be displayed on the display 82 by the processor 76. In such an embodiment, using the user interface device(s) 86, the clinician 14 may select, for example, a "determine the effect of meals on patient therapy" medical use case from among the various medical use cases displayed. After the clinician makes such a selection, the processor 76 receives the selection from the user interface device(s) 86 as input, and after using the decision logic provided by the software 34 (e.g., if …), the processor 76 will then display in step 304, for example, structured collection procedures 70b (e.g., structured collection procedures to determine a more accurate insulin to carbohydrate ratio) and 70c (e.g., structured collection procedures to determine bolus timing for meal start), instead of structured collection procedures 70a and 70d, which are structured collection procedures unrelated to the medical use case. Likewise, "displaying all structured collection procedures" may also be an option among the displayed medical use cases, where a complete list of available structured collection procedures will then be displayed in step 304. In another embodiment, step 302 may be skipped and the processor 76 may simply provide a display of the structured collection procedure 70a-d available in the memory 78 of the clinician computer 25 in step 304.

In step 306, a clinician using the user interface device 86 may select the structured collection procedure 70 on the computer 25 for diagnosis or therapy support. For example, the selection process may include selecting from the list displayed in step 304 that provides one or more structured collection procedures. After the clinician makes such a selection in step 306, the processor 78 receives the selection from the user interface device(s) 62 as input, and the processor 76 of the computer 25 automatically retrieves the selected structured collection procedure 70 from the electronic component (e.g., the computer memory 78, the server 52, or the computer readable medium 40) and displays it on the display 82 for viewing.

It should be appreciated that each structured collection procedure 70a, 70b, 70c, and 70d is based on a medical use case and has parameters defining entry criteria 226, schedule of events 222, adherence criteria 224, and exit criteria 228. As previously described, the entry criteria 226 establish the conditions that need to be met before biomarker data is obtained from the patient. Each event 237 of the schedule of events 222 includes an administration time, patient instructions for administering the event, a patient action, a requirement for information from the patient, a requirement for collecting at least one type of biomarker data from the patient, and combinations thereof. The adherence criteria 224 are used to qualitatively assess whether an event 237 administered according to the schedule of events 222 provides data that is acceptable to address the medical use case underlying the structured collection procedure 70. Further, as previously described, the exit criteria 228 establish the conditions that need to be met before exiting the structured collection procedure 70.

In step 310, after the processor 76 displays the selected structured collection procedure 70, the clinician 14 may adjust any of the parameters 222, 224, 226, and 228 also displayed on the display 82 in order to meet the needs of the patient 12 and/or the clinician's interests. Security safeguards may be implemented to ensure that only the clinician 14 can modify such parameters and/or run the software 34, such as by password protection. The processor 76 receives as input any of the changes to the parameters 222, 224, 226 and 228 through the user interface device 86 and saves the revised structured collection procedure 70 in the memory 78. Next, in step 312, the selected structured collection procedure 70 is prescribed by the clinician 14 to the patient 12 on the computer 25, wherein the processor 76 of the computer 25 provides the selected structured collection procedure 70 as output to the patient 12 for execution thereof. For example, in step 314, the prescribed structured collection procedure 70 is implemented electronically as part of the software 34 on a processor-based device, such as the collection device 24 or any of the other aforementioned devices 18, 28, and 36 (FIG. 1), or in other embodiments, as part of the paper tool 38.

In one embodiment, the prescribed structured collection procedure 70 may be implemented from the clinician computer 25 (FIG. 2) to the collection device 24 via the communication link 72, via a web page through the public network 50, and/or by making it available for download onto the server 52. In other embodiments, the specified structured collection procedure 70 may be provided by the computer readable medium 40 and loaded by one of the devices 18, 24, 28, and 36, downloaded from another of the devices 18, 24, 25, 26, 28, and 36, or downloaded from the server 52 via a cellular or telephone connection. It should be noted that the new/updated/specified structured collection procedures 70 available on the devices 18, 24, 25, 26, 28 and 36 may be provided in any standard manner, such as by postal letters/cards, e-mail, text messages, pushers, and the like.

The structured collection procedure is customized.

Figure 7B conceptually illustrates one example of a predefined structured collection procedure 70 having defined medical use case parameters 220 that indicate that the procedure facilitates medical use cases or questions that require knowledge of the patient's blood glucose (bG) level and/or relationship between blood glucose values and time of day, meal size, and energy levels. As previously described, the use case parameter 220 may be used as an identity tag, where the processor 102 may locate the associated structured collection procedure 70 in response to, for example, a search query for an entered use case or question. For example, a search query may be input into collection device 24 via user interface 146 and/or may be received from clinician computer 25. Such search queries may be due to a desire to know which use cases can be resolved by the structured collection procedure 70 currently available on the collection device 24, or due to a desire to know which structured collection procedure 70 will be available to resolve a particular use case or problem. Thus, in one embodiment, the use case parameter 220 allows for automatic selection by the processor 102 of a structured collection procedure 70 from a plurality of structured collection procedures 70a-d (provided, for example, in the memory 110, the memory 78, the computer readable medium 40, and/or the server 52) based on a selection from a displayed list provided on the display 108 from the processor 102 or based on a selection received from the processor 102 from a user interface defining a medical question. In other embodiments, the use case parameter 220 may also indicate that the structured collection procedure 70 may also be used to exhibit a relationship between bG level values and time of day, number of meals, and/or energy levels.

In one embodiment, various predefined parameters of the structured collection procedure 70 may be displayed for modification/customization by an authorized user on the display 108 via the processor 102 of the collection device 24 and/or on the display 82 via the processor 76 of the clinician computer 25. Such authorized users may be identified on the collection device 24 and/or clinician computer 25, for example, by passwords entered via the user interfaces 146, 86, respectively. In such an embodiment, various pre-defined parameters of the structured collection procedure 70 may be displayed on the displays 108, 82, wherein the customizable parameters may provide editable or selectable variables in the following manner: drop-down boxes with various selection options, radio buttons, checkboxes, formatted fields (month-day-year, numbers, letters, etc.) that require a particular type of information, text boxes for entering messages to be displayed, and so forth. In one embodiment, the structured collection procedure 70 may be displayed for editing in a tabular format (as shown) or, in another embodiment, may be displayed sequentially by listing the parameters one at a time in a scrolling manner. In another embodiment, a structured collection procedure may be provided that cannot be modified.

As shown in fig. 7B, the structured collection procedure 70 may also include parameters defining one or more criteria that set conditions that need to be met by the patient 12 in order for the structured collection procedure to begin (i.e., enter criteria 226), end (i.e., exit criteria 228), and combinations thereof. In one embodiment, the processor 102 of the collection device 24 automatically begins, assesses, and ends the structured collection procedure 70 using the one or more criteria if the condition(s) defined by the structured collection procedure 70 are satisfied. In another embodiment, the structured collection procedure 70 may also provide adherence criteria 224, which are conditions that need to be met in order to accept the collected one or more items of data.

As also shown in fig. 7B, the structured collection procedure 70 also includes parameters defining one or more (collection) events 237, which together make up the schedule of events 222. Where each event 237 includes one or more requirements 240, such as measurements from the measurement engine 138 of biomarker values for the sample provided to the biosensor 140 and/or information entered by the patient through the user interface 146, for example in response to questions presented by the processor 102 on the display 108. In the illustrated embodiment, the requirements 240 are for a bG measurement, a meal number indication (S, M or L), and an energy level indication (1, 2, 3, 4, 5), where 1 is the lowest and 5 is the highest. Other such requirements 240 may include indicating whether the patient has performed exercise, indicating that a particular food has been eaten, indicating which medication was taken, indicating the dosage of medication taken, etc., and may also be provided in other structured collection procedures 70. In the illustrated embodiment, the collection event may be customized by a yes/no selection box selecting the requirement 240 that the processor 102 should perform.

The structured collection procedure 70 may also include guidelines 230 and timing or administration times 238 associated with each collection event 237 and each of the entry, exit and adherence criteria 226, 228 and 224. Such guidance 230 is provided by the processor 102 to the display 108 upon the occurrence of an associated collection event 237 or other parameter. For example, the collection event 237 for a pre-breakfast bG measurement may also have a requirement 240 for an indication of the patient's energy level. Thus, in this example, an associated guide 230 is provided by the processor 102 on the display 108 stating "please indicate the energy level". It should be appreciated that the directions 230 are text boxes, fields, areas that allow information to be provided to the patient to assist the patient in performing the structured collection procedure 70. In this example, numbers from 1 to 5 may be selected as data input for the requirement 237 by pressing one of the buttons 147, 149 or by a touch screen interface (if provided by the display 108), which is then stored by the processor 102 in the memory 110 of the collection device 24 as part of the data file 145 (FIG. 4) for the structured collection procedure 70.

The timing parameters 238 of the structured collection procedure 70 are used to indicate a particular date and/or time (month-day-year, hour: minute) for any of the associated collection event 237, entry, exit and adherence criteria 226, 228, 224, or to indicate a period of time (n) after a previous collection event in which the associated collection event was administered. Time period n for each collection event 237 in the illustrated embodiment₁、n₂、n₃Hours are indicated, but in other embodiments may be indicated in minutes or seconds. In another embodiment, the timing or performance time parameter 238 for an associated collection event 237 and for entry, exit and adherence criteria 226, 228, 224 may be modified by another collection event and/or by the criteria.

For example, in the illustrated embodiment, entry criteria 226 is modified by adherence criteria 224 by incrementing by one day if guidance 230 provided in the form of the question "you want to test for more than 3 consecutive days" is not confirmed by patient 12 (such as by providing a "no" selection on collection device 24). In the example shown, the "confirmation guidance" may be a drop-down selection provided in a combo box of adherence criteria 224 for customizing the associated collection event 237, which when selected causes the processor 102 to wait for accepted/not accepted input (e.g., via buttons 147, 149) before executing the remaining logic of adherence criteria 224 ("if not increasing timing by one day"). Also in this example, processor 102 may set a timing or performance time parameter 238 for exit criteria 228 to a date 3 days (month-day-year) after completion of entry criteria 226, according to logic provided in compliance criteria 224 associated with exit criteria 228. It should be appreciated that in one embodiment, various possible combinations of logical statements that may be performed by the structured collection procedure 70 may be predefined and selected for customization through a drop-down box, and/or in another embodiment, logical statements may be established.

The structured collection procedure 70 may also include option parameters 232 associated with each collection event 237 and with each of the entry, exit, and adherence criteria 226, 228, 224. The option parameter 232 may have a customizable value(s) to govern whether the data and/or results of the associated collection event 237 or any other parameter (e.g., entry, exit and adherence criteria 226, 228, 224) in the structured collection procedure 70 meets a particular condition, so that further processing may be performed by the processor 102 if such condition(s) are met. For example, such an option may be for the processor 102 to automatically send a message to the physician indicating that the patient has started the structured collection procedure 70 by meeting the entry criteria 226, or to provide a message to the patient and/or physician in the event that the patient fails the collection event 237 because the adherence criteria were not met, or to provide a message to the physician when the patient completes the structured collection procedure 70 because the exit criteria 228 were met, or a combination thereof. For example, such an option parameter 232 may have a global list of such actions that are selected on the display 108, for example, by a selected value from a range of values associated with each option. For example, the options for each parameter may be customized by selecting from a drop-down box with option selections (e.g., 1, 2, 3, 4, 5, …, A, B, C, etc.), and where option 1 is shown, for example, being selected for the pre-breakfast collection event 237, which is to have the processor 102 provide a message to the physician if the patient causes the collection event 237 to fail (e.g., due to the adherence criteria not being met). One example in the context of a patient 12 who is diabetic is provided below to further illustrate the features provided on a collection device 24 according to the present invention.

A typical patient with type 2 diabetes may measure his/her blood glucose once a day after waking up in the morning. When routinely visiting a physician, the patient was found to have an elevated HbA1C result. The physician recommends that the person perform a three day rigorous glucose monitoring and selects a structured collection procedure that is useful for this purpose. Then in accordance with that previously discussedThe structured collection procedure 70 is custom-made such that the collection event 237 is defined with a certain number of bG measurement requests 240 during the three days so that it can be before breakfast and after two hours (e.g., n₁= 2), before lunch and after two hours (n)₂= 2), before dinner and after two hours (n)₃= 2) and measuring his/her blood glucose while sleeping. Furthermore, the patient 12 may be asked to provide an assessment of the relative number of meals ingested at the appropriate time, and an indication of how he/she feels about energy levels, by other associated requirements 240 for each collection event 237. In the illustrated embodiment of fig. 7B, the processor 102 may require an indication of the energy level for each collection event 237 and an assessment of the relative quantity of meals ingested for every other collection event 237 (i.e., after meal). In addition, the physician provides a condition by adherence criteria 224, wherein the adherence criteria 224 is of the collection event 237 that must be associated The meal assessment is performed over a period of 30 minutes (n) so that such information is available for assessment. Such information may be used to contextualize the collected data, and may be used in the analysis performed on the collected data.

In addition, the physician will want to be notified when the patient is not able to complete the "pre-breakfast" collection event 237. Thus, to facilitate the notification options, the physician customizes the structured collection procedure 70 by setting the option parameters 232 associated with the "before breakfast" collection event by a drop-down box for "send message to physician in case of failure to comply with the standard". The associated option parameter 232 of all other collection events 237 by default indicates that the processor 102 will not take any additional action with respect to the option parameter. It should be appreciated that the features and settings previously described in the illustrated embodiment of FIG. 7B provide a simple and convenient interface and method for customizing a structured collection procedure, such as for parameter adjustment as implemented in step 310 of the method 300 previously discussed with reference to FIG. 7A.

A structured collection procedure is implemented and enforced.

FIG. 8A illustrates a flow diagram of a method for implementing and performing a structured collection procedure 70 for obtaining contextualized biomarker data from the patient 12, according to one embodiment of the present invention. It should be appreciated that the plurality of structured collection procedures 70a-d (FIG. 2) specified in step 312 and implemented in step 314 (FIG. 7A) may be stored in the memory 110 (FIG. 3) of the device 24 and executed at any desired timing. For example, after pressing a particular combination of buttons 147, 149, the patient may select the desired structured collection procedure 70a-c and the date on which structured collection was initiated (i.e., set mode function). For example, the range of dates from which selection may be made may be from tomorrow and end 90 days from the present day, which processor 102 may also record in data file 145 (FIG. 4) as part of settings data 163. In such an implementation, the processor 102 reads the setup data 163 for the selected structured collection procedure 70 as instructed by the software 34 and indicates on the display 108 that the device 24 is in the structured test mode, for example, starting the day before the selected test start date and until the structured collection procedure ends.

It should be appreciated that multiple structured collection procedures 70a-d may be performed sequentially or simultaneously at any given time. In one embodiment, however, the software 34 only allows the user to schedule another structured collection procedure 70 with a start date that is later than the end date of the structured collection procedure 70 currently being executed. The software 34 also allows the user to revoke the scheduled date for the structured collection procedure 70. If the structured collection procedure 70 is scheduled and the user enters the set mode function again, the software 34 causes the processor 102 to display the scheduled date as a default date on the display 108; if the user exits the set mode without modifying the date, the previously scheduled date remains valid. If the structured collection procedure 70 has started, the software 34 allows the user to enter the setup mode and causes the processor 102 to cancel the current structured collection procedure 70. In one embodiment, after cancellation, software 34 causes processor 102 to de-tag data records 152 in data file 145 for the data collected for the cancelled structured collection procedure 70 (e.g., invalidating unique identifier 167).

Upon reaching the start of the procedure in step 316 (fig. 8 a), the processor 102 assesses in step 318 whether the entry criteria 226 are met to begin the structured collection procedure 70 selected to obtain biomarker data in order to solve a predefined use case or problem (e.g., use case parameters 220). In step 320, the processor 102 specifies the requirements 240 for each event 237 in the schedule of events 222 of the structured collection procedure 70 according to its associated timing 238. It should be appreciated that the schedule of events 222 provides a sampling plan for biomarker data collection that is executed by the processor 102 to obtain the biomarker data in a predefined context. Upon execution of the schedule of events 222 in step 320, the software 34 causes the processor 102 to assign a unique identifier (e.g., an incremental count) 167 in the data record 152 that corresponds to each event 237 in the structured collection procedure 70. Optionally, a date-time stamp 169 may also be provided for each criterion 226, 228, 224, if desired, to indicate when the criterion was met.

The adherence criteria 224 are then applied to the input (e.g., biomarker data or information) received in response to the requirements 240 in order to determine whether the received input satisfies the adherence criteria 224. When the structured collection procedure 70 has started, then in step 324, all data collected in the structured collection procedure 70 according to the requirements 240 and meeting the adherence criteria 224 (if required in step 322) are assigned (tagged) with a unique identifier 167 in the data file 145. It should be appreciated that the unique identifier also serves to associate the collected data (e.g., data value 256) with its event 237, claim 240 and date timestamp 169 to indicate when the collection in response to the claim 240 was received by the processor 102. While performing the structured collection procedure 70, in one embodiment, the software 34 allows the user to perform measurements on the device 24 at any time without interfering with the onset of the illness.

In one embodiment, for non-critical measurements, the software 34 allows the reminder to "delay" the biomarker measurement for a certain period of time (such as 15 minutes) and up to a number of times as previously described. In another embodiment, biomarker measurements or data entries performed in sufficiently close temporal proximity to the claim 240 in step 320 are designed by the software 34 as valid measurements or data entries for the claim 240. Thus, the processor 102 will tag the associated data record 152 for the event 237 accordingly, using the unique identifier 167 for the biomarker measurement or data entry. In the example of biomarker measurement, if the measurement is accepted as valid for the requirement 240, the software 34 causes the processor 102 to prompt the user to enter additional information if required by the structured collection procedure 70 in order to provide a context 252 for the data resulting from the requirement 240. Such additional inputs may include, for example: an energy level rating from 1 to 5, where 1 is low and 5 is high; a meal size from 1 to 5, with 1 being low and 5 being high; and exercises of either 1 (which means more than 30 minutes) and no or 2 (which means less than 30 minutes). Such additional information or contextual information 156 is stored by the processor 102 in the data file 145 associated with the unique identifier 167 for the data event requirement 240 when entered through the user interface 146, wherein the data event requirement 240 also requires additional information in step 324.

In one embodiment, biomarker measurements determined by the processor 102 to be not close enough in time to the data event requirements 240 defined by the structured collection procedure 70 will not be tagged by the processor 102 with the unique identifier 167 in the data file 145. This is illustrated in the data file 145 shown by the absence of the requirement 240d and data value 256d (which is, for example, < null >) associated with the unique identifier 167. One example of a definition indicated by the structured collection procedure 70 and/or software 34 as "sufficiently close in time to the collection procedure" to enable the processor 102 to make such a determination may be defined with respect to a pre-scheduled time or a delayed time. For example, for pre-meal measurements, up to 15 minutes are expected to be acceptable; for postprandial measurements, up to 10 minutes is expected to be acceptable; and for sleeping measurements up to 15 minutes is expected to be acceptable. Other definitions may be provided in other structured collection procedures 70 and/or software 34.

In step 326, the processor 102 then assesses whether the exit criteria 228 for the selected structured collection procedure 70 are met. If not, the processor 102 continues to execute the schedule of events 222 until the exit criteria 228 are met. After the exit criteria 228 are met, the collection procedure 70 ends in step 328. In one embodiment, if the entry criteria 226 are also not satisfied in step 318, the structured collection procedure 70 may also end.

In some embodiments, the structured collection procedure 70 may be configured to be performed as: a paper tool 38; diabetes software 34 integrated into the collection device 24, such as the blood glucose meter 26; diabetes software 34 integrated into a computing device 36, such as a personal digital assistant, handheld computer, or mobile phone, 26; diabetes software 34 integrated into the device reader 22 coupled to the computer; diabetes software 34 operating on a computer 18, 25 such as a personal computer; and diabetes software 34 accessed remotely via the internet, such as from a server 52. When the diabetes software 34 is integrated into the collection device 24 or the computing device 36, the diabetes software 34 may prompt the patient to record diary information such as meal characteristics, exercise, and energy levels. The diabetes software 34 may also prompt the patient to obtain biomarker values such as blood glucose values.

A GUI interface providing an optional structured collection procedure.

Fig. 8B illustrates a method of implementing a structured collection procedure by providing a graphical user interface on the collection device 24 that, when executed on the collection device, causes the processor 102 to perform the following steps. After pressing a particular combination of buttons 147, 149, the patient 12 can scroll in step 330 to a structured collection procedure 70 available for selection from a list 329 provided by the processor 102 on the display 108 of the collection device 24. If it is desired to begin the structured collection procedure, the patient 12 selects the desired structured collection procedure 70, for example, by pressing the ok button 151 in step 332. In this example, the entry criteria 226 (FIG. 6) of the structured collection procedure 70 provides information for display by the processor 102 to the user on the display 108 in step 334. After reading the displayed information, the user presses any button in step 336, wherein the next procedure into criteria 226 is performed by processor 102. In the example shown, as part of the entry criteria 226, a question is then asked by the processor 102 in step 338. If the patient 12 still wishes to begin the structured collection procedure, the patient 12 selects the confirmation button 151 in step 340; otherwise, any further pressing of the buttons 147, 149 will cause the processor to revert to the list 329, thereby stopping the setup procedure for the structured collection procedure 70.

After the patient 12 presses the confirmation button 151, the processor 102 will provide an alarm clock 343 on the display 108 in step 342 in order to set the time at which the selected structured collection procedure 70 will be started. It should be appreciated that all required events 237 for biomarker sampling, patient information, etc. are automatically scheduled by the processor 102 according to the schedule of events 222 for the structured collection procedure 70, wherein timing, values, questions, etc. may have been adjusted by the clinician 14 as previously discussed with reference to fig. 7A and 7B. Thus, no other parameter adjustments in the structured collection procedure 70 are required (or, in one embodiment, are not permitted) by the patient 12 other than the start time allowed by the input entry criteria 226.

In the illustrated embodiment, the patient may adjust the start time of the structured collection procedure for the next day (e.g., day 1) via buttons 147, 149 in step 344. After the start time is verified in step 346 by pressing the ok button 151, the start time is recorded by the processor 102 in the memory 110 as part of the setup data 163 in the data file 145 (fig. 4) for the structured collection procedure 70. The processor 102 then displays the selection list 329 on the display 108 in step 348, completing the setup procedure that satisfies the entry criteria 226 and indicates on the display 108 that the collection device 24 is in the structured test mode 349.

It should be appreciated that in one embodiment, multiple structured collection procedures may be performed sequentially or simultaneously at any given time, and thus in one embodiment, the pattern 349 provided on the display 108 will indicate which structured test is being performed. In a preferred embodiment, however, the software 34 does not allow the user to schedule another structured collection procedure unless the start date is later than the end date of the current structured collection procedure being performed via the user interface 146. It should be appreciated that the processor 102 may automatically reschedule the next structured collection procedure if the current structured collection procedure is still running because the exit criteria 228 are not met. In another embodiment, the software 34 may also allow the user to undo the scheduled date for the structured collection procedure. If the structured collection procedure is scheduled and the user again enters the set mode function, the software 34 causes the processor 102 to display the scheduled date as the default date on the display 108; if the user exits the set mode without modifying the date, the previously scheduled date remains valid. If the structured collection procedure has started, the software 34 allows the user to enter a setup mode and causes the processor 102 to cancel the current structured collection procedure if desired.

In step 350, an alarm condition 351 may be provided by the processor 102 on the previous day (represented by the notation "start") by the next day (represented by the notation "day 1") set in the aforementioned protocol. After the user selects any of the buttons 147, 149, 151 at step 352, the processor 102 provides the first scheduled event 237 as indicated by the schedule of events 222, i.e., displays information 353 on the display 108 at step 354, which the patient 12 confirms by pressing any of the buttons 147, 149, 151 at step 356. Next, in step 358, the processor 102 executes a second scheduled event as indicated by the schedule of events 222, i.e., displays the question 359 for the patient on the display 108, which the patient 12 confirms by pressing any of the buttons 147, 149, 151 in step 360. In the illustrated embodiment, the patient indicates the start time for breakfast in step 362, which is indicated by the number of minutes from the wake up alert 351 previously acknowledged in step 352. After confirming the meal start time to processor 102 by pressing confirmation button 151 in step 364, the meal start time is recorded in memory 110. For example, the meal start time is recorded by the processor 102 in an associated data record 152 in the data file 145 as data for the event 237. Further, in step 366, the processor 102 displays information to the patient 12 regarding the timing of the next scheduled event as a reminder. In step 368, upon reaching the next scheduled event indicated by the schedule of events 222, the processor 102 provides a request 240 on the display 108 to ask the patient to take a measurement (e.g., a blood glucose measurement). Further, in step 370, the processor 102 also makes a request 240 for information regarding the number of meals to be ingested on request of the schedule of events 222 to provide contextual information 156 for the measured values.

As previously described, for each event, the software 34 causes the processor 102 to assign a unique identifier (e.g., an incremental count) 167 (FIG. 4) to the data provided in the schedule of events 222 for each requirement 240 that satisfies the adherence criteria 224 in the associated date record 152 for the event 237. Thus, while performing the structured collection procedure, the software 34 allows the user to perform measurements on the collection device 24 at any time outside of the schedule of events 222. Such measurements, as they are not performed according to the requirements 240, will not be rated against the adherence criteria 224 and will therefore not be provided with the unique identifier 167 in the date file, but only with the date time stamp and its measurement value. Such data is still recorded in the data file 145 because such data may still be available for another analysis.

In another embodiment, the software 34 also allows for reminders for biomarker measurements, such as provided in step 238. For example, in one embodiment, the processor 102 provides an alarm and/or alert message via the indicator 148 and/or on the display 108, respectively, to alert the provision of the measurement. For example, at time 238 for a particular requirement 240 to take a biomarker measurement (or reading), the processor 102 prompts the patient 12 by displaying a message "it is now time for you to take a reading" on at least the display. In another embodiment, an audible alarm and/or a tactile alarm (vibration) may be provided by the processor 102 through the indicator 148. For example, in one embodiment, the collection device 24 will provide such a prompt even when already powered on, such as by the patient 12 implementing an unscheduled event for another reason, for example, when within a time window in which the required measurements/readings will be taken, or will provide a reminder via the prompt by waking up even when powered off (such as in a standby mode). In another embodiment, the provided reminder or prompt may be "delayed" as previously described for a predefined period of time still falling within the time window in which the required (critical) measurements/readings are to be taken, such as 15 minutes or any other such suitable time falling within the time window. It should be appreciated that if the latency feature is for measurements/readings deemed critical to the structured collection procedure 70, such as those needed to help address a medical use case or problem, those needed to meet the adherence criteria 224, and/or those needed for some determination in a subsequent analysis, etc., the latency feature will not extend the requirements 240 beyond the time window provided by the collection procedure 70, such as by the adherence criteria 224 for the requirements 240. For example, in one embodiment, one or more events 237 within the schedule of events 222 may be predefined as critical through the use of the option parameters 232 (FIG. 7B) provided in the structured collection procedure 70. For example, an event 237 designated as critical is an event that cannot be missed, but if missed can be replaced by another sample already present in the data file 145. In another embodiment, the delay may be up to several times for non-critical measurements. For example, a particular event 237 in the structured collection procedure 70 may be specified as having a non-critical requirement 240 that may be delayed, such as by selecting such an option provided as one of the option parameters 232 (fig. 7B). In this embodiment, the option parameter 232 may provide, for example, a delay option and a selectable time interval (e.g., 1-60 minutes, etc.) and a selectable number of times (e.g., 1-5 times, etc.) that the user is allowed to delay the request 240. In another embodiment, the collection device 24 allows the alarm to be turned off, that is the indicator 148 may provide the reminder (audible, vibratory) for the entire time window to be closed via the user interface 146, but wherein the processor 102 still accepts the measurement/reading as long as it is taken within the time window. In another embodiment, the collection device 24 provides a skip reading option, which is also received by the processor 102 through selection entered by the user interface 146, for example, from a list of selectable options provided on the display 108 (such as delay, alarm off, skip reading), wherein again no reminder/reminder will be provided because the patient 12 has indicated to the processor 102 that he/she does not want to take the particular measurement/reading requested. It will be appreciated that selecting the skip reading selection option may result in adherence to event 242, and thus further processing, if adherence criteria 224 has been associated with event 237 prompting requirements 240, as already discussed in the preceding section.

In another embodiment, the adherence criteria 224 may require that the biomarker measurements be performed within a time sufficiently close to the data event requirements 240. Thus, if such biomarker measurements are taken within a time period specified by the adherence criteria 224, the processor 102 may indicate that the measurement or data entry for the event is acceptable and tag (i.e., assign a unique identifier 167) the value of the biomarker measurement or data entry in the data file 145 accordingly. In the example of a biomarker measurement, if the measurement is accepted as valid for the data event requirement 240 (i.e., the adherence criteria 224 is met), the schedule of events 222 may cause the processor 102 to prompt the user to enter additional information (if required by the structured collection procedure 70), such as the provision of contextual information 156 (i.e., context) for the measurement received in response to the requirement 240 as previously mentioned with respect to step 370.

Upon entry of such contextual information 156 through the user interface 146, it may be stored by the processor 102 in the data file 145 associated with the unique identifier 167 for the data event requirement 240 that requires the additional information. Biomarker measurements determined by the processor 102 to be not close enough in time to the data event requirements 240 defined by the adherence criteria 224 will not be tagged by the processor 102 in the data file 145. This is illustrated in the illustrated data file 145 (FIG. 4) by the absence of a data event requirement 240d and a data value 256d associated with the unique identifier 167. One example of a definition indicated by the adherence criteria 224 to be "close enough in time to the collection procedure" to cause the processor 102 to make such a determination may be defined relative to a pre-scheduled time or a time delayed. For example, for pre-meal measurements, up to 15 minutes are expected to be acceptable; for postprandial measurements, up to 10 minutes is expected to be acceptable; and for sleeping measurements up to 15 minutes is expected to be acceptable. Other definitions may be provided in other adherence criteria 224 to other events in the schedule of events 222 and in other structured collection procedures.

In the illustrated embodiment, the user scrolls to a selection using the buttons 147, 149, which is entered by the processor in the data record 152 for the associated demand 240 by pressing the confirmation button 151 in step 372. In one embodiment, the number of meals may be represented by a range of numbers, for example from 1 to 5, with 1 being small and 5 being large. In the illustrated embodiment, additional input is required in step 374 regarding the contextual information 156 of the energy level rating from 1 to 5, where 1 is low and 5 is high, which is input in step 376 in the data file 145 as previously described by receiving input by the processor 102 to the requirement 240 made with the user interface 146. In other embodiments, other contextual information 156 may include information indicating whether the patient has exercised and/or for how long. For example, the user interface 146 may be used, where a yes or 1 means more than 30 minutes, and a no or 2 means less than 30 minutes. In the illustrated embodiment, since the exit criteria 228 are now satisfied by the successful performance of the steps 368-376, the structured collection procedure 70 ends in a step 378 where the processor 102 again displays the list 329 so that the patient 12 can perform other tasks on the collection device 24 as desired. Reference will now be made to fig. 9.

A method of contextualizing biomarker data.

Fig. 9 depicts a method 388 for contextualizing biomarker data for diabetes diagnosis and therapy support in accordance with an embodiment of the present invention. It should be appreciated that in the embodiments discussed above with reference to fig. 8A and 8B, the contextual information 156 is automatically required by the processor during the structured collection procedure 70 and recorded along with the associated biomarker values. In embodiments where such automation is not provided on the collection device 24 and the patient is using the paper tool 38, however, the collected data may be associated with its contextual information 156 at a later time (e.g., after the structured collection procedure 70 is performed to generate at least the data event values 256 in step 390). If not already done by the collection device 24 (such as in the example of a device with limited memory and processing power or when recorded on the paper tool 38), the data may be provided to another device 18, 25, 36 that is running the software 34 and has the capability to associate at least the data event value 256 (FIG. 4) with its corresponding data event requirement 240. This association of at least the data event value 256 with its corresponding data event request 240, date time stamp 169, and context information 156 results in contextualized (self-monitored) data 170 in step 392.

It should be appreciated that the data used in the structured testing according to the present invention should correspond to the expected collection of contextualized data. Considering fig. 10A, in this example the inherent advantages of context become apparent when considering the utility of a subway map with no context on the left hand side and a subway map with context on the right hand side, which makes it possible to easily navigate the system and travel from one location to another. In a similar manner, contextualization can play an important role in diabetes. The context associated with the data may be, for example, due to therapy, events (such as meals, exercises, events 237, requirements 240, etc.), and required times (e.g., timing 238) for the data collection itself. Thus, any data collected by a patient having measured values may be contextualized by being associated with one or more of the aforementioned factors, such as therapy, event, and time, each of which is discussed further below.

Therapy may be defined, for example, as an ongoing treatment intended to alleviate impaired glucose control in a patient. The treatment usually involves antidiabetic agents such as insulin, oral medications, and diet and exercise. Due to the different mechanisms of action, one treatment (or combination of treatments) has a specific pharmacodynamic effect on the blood glucose of a patient. A change in the dose(s) of the therapy(s) or a change in the therapy(s) itself will result in a change in the glucose control of the patient. Thus, the bG data collected has a strong correlation to the underlying therapy and dose, and this information is used to contextualize the data. Variations in dosage or treatment will lead to different situations. It should be appreciated that the therapy context may be set by the clinician 14 by consulting the patient when designing the collection procedure 70, such as discussed above with respect to fig. 5A.

In one embodiment, the events 237 in the collection procedure 70 may include specific conditions surrounding the bG measurement points that play a role in altering the normal glucose levels of the patient. As previously described, the event 237 may be meal or exercise based and relevant to data contextualization. In this context, the underlying assumption is that the patient operates more or less under a well-defined schedule. In creating the collection procedure 70, the patient 12 may discuss lifestyle events with the clinician 14 so that the collection procedure 70 may be adjusted according to the needs of the patient 12. As an example and referring to FIG. 10B, consider a typical collection procedure 70 in which the patient 12 does not exercise regularly, so most events are meal-based events, including breakfast, lunch, and dinner. Such lifestyle of the patient 12 results in six candidate bG measurement points (pre-and post-meal for each meal) for the schedule of events 222 in the collection procedure 70. During the process of creating/customizing (fig. 5A and/or fig. 7B) the collection procedure 70, the clinician 14 may designate the patient to collect one or more or all of these points according to the schedule of events 222 of the collection procedure 70. Any data collected other than these points (i.e., outside the requirements of the collection procedure 70) may be classified by the processor 102 as a non-collection procedure reading. In a similar manner, for type 1 diabetic patients who exercise regularly, the clinician 14 may adjust/customize the collection procedure 70 to include additional measurements around the exercise event. The event information is then used in this example to contextualize the data in an appropriate manner depending on the event 237.

The time represents the actual time at which the measurement was taken and has an absolute term, such as a date-time stamp 169 (fig. 4). Furthermore, time, i.e. an offset from a particular event, may also be represented by an offset. As an example, a post-meal reading is taken at a particular time after a meal, and that time may be different for different days. This occurs because the patient may not be able to take event-based readings at the same time each day. Thus, there are time distributions in which the same measurement is made on different days. Knowledge of this distribution may be used to analyze the timing and parameter timing 238 in the collection procedure 70.

Further, using contextualized data 170, the physiological state of patient 12 at the time of measurement can be described. The patient's physiological state may affect the biomarker values, and thus knowledge of the patient's physiological state is helpful in understanding the biomarker values. The biomarker data may be contextualized because the biomarker data is collected in the context of a predetermined event, such as the duration of a meal, meal type, meal distribution, exercise information, sleep quality, sleep duration, wake-up time, and stressful factors such as illness, and so forth. The time-resolved data allows the biomarker data to be interpreted in context with other information, such as compliance with the structured collection procedure 70 and patient lifestyle events.

Referring again to FIG. 9, the contextualized data 170 is assessed using the adherence criteria 224 in step 394 to generate accepted contextualized data 395 that meets the adherence criteria 224. Because the adherence criteria 224 may provide a basis for comparing the data event values 256 to the criteria, which may be accepted and used or rejected and not used, in one embodiment, the adherence criteria 224 may be used to filter the data. In another embodiment, step 394 may precede step 392.

FIG. 11, for example, shows a graphical representation of accepted contextualized data 395 blended with unacceptable contextualized data 397. The vertical axis of the figure shows a biomarker value 256, which includes context 252 in the form of a biomarker set point, a biomarker upper limit, and a biomarker lower limit. The horizontal axis of the graph shows delivery times 238 of measurement requests 240 and sleep period events 237 where actual sleep exceeds the recommended minimum amount of sleep shown in dashed lines. The accepted contextualized data 395 is data that satisfies the adherence criteria 224. The unacceptable contextualized biomarker data 397 either is not within the structured collection procedure 70 or does not meet the adherence criteria 224. Accepted contextualized biomarker data 395 may help improve decision making by excluding unacceptable contextualized biomarker data 397. Statistical techniques can be used to view the accepted contextualized biomarker data 395 in a form that conveys additional information to the clinician 14. Examples of statistical techniques include regression methods, analysis of variance, and the like. Additional details regarding the preferred embodiment of the software 34 will be provided below.

And (3) software.

As mentioned in the preceding section, the software 34 may operate on the patient computer 18, the collection device 24, a handheld computing device 36 (such as a laptop computer, personal digital assistant, and/or mobile phone), and a paper tool 38. The software 34 may be preloaded or provided via computer-readable media 40 or provided via public network 50 and loaded for operation on patient computer 18, collection device 24, clinician computer/office workstation 25, and handheld computing device 36 as desired. In other embodiments, the software 34 may also be integrated into a device reader 22 coupled to a computer (e.g., computer 18 or 25) for operation thereon, or may be accessed remotely over the public network 50, for example, from a server 52. Further, the one or more collection procedures 70 may be provided as part of the software 34, as updates to the software 34, or as individual files that may be operated on and used by the software 34.

In the embodiment discussed below, the software 34 runs on the collection device 24 and provides three basic elements: one or more structured collection procedures 70, a data file 145, and one or more scripts. Since the features of the structured collection procedure 70 and the data file 145 are the same as previously discussed, further details will not be provided. The one or more scripts are small, independent programs that reside on the collection device 24 and that each can perform a particular set of tasks. Such scripts may include, for example, protocol scripts 401, parsing scripts 403, and analysis scripts 405 depicted by FIG. 12, each of which will be discussed in detail in the following paragraphs.

A protocol script.

The protocol script is a script that actually implements the execution of the collection procedure 70 by the processor 102 on the collection device 45. Upon initiation of the collection procedure 70, the protocol script, in one embodiment, causes the processor 102 to create a data structure that summarizes the expected amount of data summarized by the collection procedure 70. In another embodiment, the data structure may be of variable size or of fixed size but with a buffer (e.g., an array in the data structure) if additional data is to be collected during the collection procedure 70. By having a buffer in this way it is possible to take into account when the structured collection procedure 70 can be extended to, for example, the maximum memory size that can be allocated for the data structure, for example in the memory 110 of the collection device 24, if it is desired or required to be extended because the desired condition is not met (e.g. the patient biomarker values do not reach the desired values). The data structure, such as data file 145, stores at least the start time of the collection procedure 70, the actual measurement of the biomarker (such as data event value 256) and the time of measurement (such as date time stamp 169), and optionally all other information used for additional contextualization, such as contextual information 156 and requirements 240 such as meals, workouts, etc. As an alternative embodiment, the data structure may also be considered a calendar, which is generated by the clinician 14 and may include details regarding the date and time of day at which measurements need to be taken. The calendar also features a feature that allows the patient to easily see when he or she must take the next measurement. The protocol script also causes the processor 102 to perform all of the functions necessary for the collection procedure 70 to be performed by the processor 102. Once the appropriate data is collected (e.g., the collection procedure 70 is successfully run), the protocol script causes the processor 102 to mark the data structure with the done flag 257 in one embodiment, or in another embodiment provides it as a status condition for the software 34 and passes control of the processor 102 provided in the software 34 to a parse script. In the previous embodiment, the completion flag 257 may also be used to provide information about the reason for the end/termination, to identify the type of completion (end, logistics (timeout), adherence termination, etc.). For the latter embodiment, since one or more procedures 70 may be loaded onto the collection device 24 at the factory as previously mentioned, by providing status conditions in the software 34 for each collection procedure 70 helps support the requirement that the procedure be available only after authorization by the clinician 14. In one embodiment, the state conditions for each collection procedure 70 may be tracked by software 34 and may include one or more of a "sleep" state, an "authorized" state, a "pending" state, an "active" state, and a "completed" state. The dormant state is useful when shipping a collection device 24 having one or more embedded collection procedures 70, but until authorized for use (such as described above), it cannot be used (or seen) by the patient 12 on the collection device 24. In this case, the collection procedure 70 is said to be dormant. The authorized state is the state when the collection procedure 70 becomes available after the clinician 14 authorizes its use on the collection device 24. During this state, the collection procedure 70 may be configured (e.g., by a clinician) and initiated to begin as well as configured, for example, by selection of the clinician, the patient 12, or by a start date. The pending state is a state when the start date is set but before execution, for example in which the collection procedure 70 waits for some unknown time before executing the schedule of events 222 until the entry criteria 226 are met. In one embodiment, once the collection procedure 70 begins at or after the start date by meeting the entry criteria 226, the collection procedure is said to be in an active state with at least the schedule of events 222 being implemented by the processor 102. When the collection procedure 70 ends as previously described, the completed status functions in a similar manner as the done flag 257.

And analyzing the script.

Parsing scripts are scripts that cause the processor 102 to parse contextualized data, such as contextualized data 395 (FIG. 11), once data collection of the collection procedure 70 is complete. The parse script causes the processor 102 to attempt to resolve any anomalies that may occur while the collection procedure 70 is being executed (e.g., in real-time, i.e., while the procedure 70 is being executed), such as, in one embodiment, only critical data events 237 in the collection procedure 70 (e.g., mandatory data collection for biomarker values). If at the end of execution of the parse script, there is still an exception to at least the mandatory data required by the collection procedure 70, the parse script will cause the processor 102 to indicate that the appropriate data has not been collected. Thus, the collection procedure 70 is marked as incomplete by the processor 102 not providing a complete flag 257 in the data file 145. If there is no exception at the end of parsing the script, e.g., at least for a critical event in one embodiment and/or for all events in another embodiment, the collection procedure 70 is marked as complete by providing a complete flag 257 by the processor 102 in the data file 145 containing the collected and contextualized data. The role of the parsing script will be explained later in another embodiment illustrating the execution phase.

The script is analyzed.

The analysis script causes the processor 102 to analyze the completed collection procedure 70 with its own associated data set (e.g., data file 145). The analysis performed by the processor 102 according to the analysis script may be simple (glucose mean, glucose variability, etc.) or may be more complex (insulin sensitivity, noise assessment, etc.). In one embodiment, the collection device 24 may perform the actual analysis by itself, or the analysis may be implemented on a computer such as computers 18, 25. In one embodiment, the results from the analysis script may then be displayed by processor 102 on display 108 of collection device 24 or on a display of a peripheral device. Program instructions and scripts of the software 34 are discussed below with reference to fig. 13 and 14 and fig. 2 and 5B.

The collection procedure is performed.

Fig. 13 and 14 depict a collection procedure execution method 400 performed by the processor during the collection procedure 70 using the aforementioned script in accordance with the program instructions of the software 34. The dotted lines mark the boundaries between different domains of different scripts and are the boundaries where control exchanges occur. It should be appreciated that the below disclosed embodiments of the present invention may be implemented on a blood glucose measuring device (such as a meter) capable of accepting one or more structured collection procedures 70 and the associated meter executable script discussed above.

Referring first to FIG. 13, once the collection procedure 70 is initiated by the processor 102 using the protocol script 401 on the collection device 24 in step 402 (such as in any of the manners discussed above in the preceding section), after the entry criteria 226 are met (if provided in the collection procedure 70), data event instances (e.g., events 237) occur in accordance with the schedule of events 222 in step 404. For event 237, in this example, the processor 102 prompts by a request 240 to take readings for the patient 12 around a lunch event as forced by the collection procedure 70. For example, the prompt for the claim 240 may be an alert provided by the processor 102 via the sounded indicator 148, wherein the patient 12 is asked by the processor 102 to take a reading on the display 108. In one embodiment, the software 34 provides a delay feature and a skip reading feature, wherein the patient 12 can use the user interface 146 to effect delaying or skipping data collection. For example, by selecting the delay feature previously discussed in the preceding section, the processor 102 may be caused to prompt the patient 12 again for the event 237 after a predefined amount of time to effect a delay for data collection. For example, in one embodiment, such a feature may be used in the event that the patient 12 is unable to take a reading at the prompted time, such as at the beginning of a time window in which the measurement/reading is provided. Likewise, the skip feature will be selected if the patient believes he/she cannot perform the measurements/readings within the time window. FIG. 10B shows an example of a time window or a particular time window surrounding an event ("allowable window").

In one embodiment, the processor 102 then uses the adherence criteria 224 to determine whether data collection for the event 237 was successful due to the conditions meeting the adherence criteria 224 according to the protocol script 401 in step 406. For example, if the patient 12 successfully collects data within the specified time window, a successful data collection will occur. In another embodiment, the same process may be applied to one or more sample groups 262. The data successfully collected for the events in the schedule of events 222 and/or sample packets 262 is then contextualized by the processor 102 in step 410 according to the protocol script 401, for example, by associating the collected data (e.g., data 256) with the current time (e.g., date-time stamp 169 (fig. 4)), the event 239 and/or the claim 240 and, for example, context information 156 available regarding the patient therapy and the unique identifier 167 (if needed) in the data file 145, as also previously discussed in the preceding section.

In the previous example, if the patient 12 is not able to collect data within the specified time window, the processor 102 scans the contextualized data residing on the collection device 24 according to the protocol script 401 in step 412 to determine if there are available similar data points that meet the requirements of the missed data point. The data point will only be selected by the processor 102 in step 414 according to the protocol script 401 if all requirements of the data point intended to be collected are met.

As an example, if the collection procedure 70 requires paired measurements, i.e., pre-meal and post-meal measurements, it is important that both measurements be taken around the same event. In this case, it is not allowed to replace any one value from the previous value; if this happens, an exception is flagged for the event under consideration. In this case, the relevant element in the data structure is not completed at that location, where processor 102 would declare an exception in step 416, such as providing a < null > value to unique identifier 167 in the particular data record 152 for the event 237 that caused the exception. If no such constraints exist, data points from the data residing on the collection device 24 may be selected by the processor 102 in step 414 and added to the contextualized collected data in step 410. The replacement data points will have the same context information, event context and were collected within the specified time window of the original collection time period, if so required. In step 418, the processor 102 will check whether data collection is complete for all events 237 in the schedule of events 222 of the collection procedure according to the protocol script 401. The processor 102 also checks if the exit criteria 228 are met if the collection procedure 70 provides the exit criteria 228. If not, the processor 102 continues with the next event in the schedule of events 222 by returning to step 404, wherein data collection is then continued for the remainder of the collection procedure 70 in a similar manner. It should be appreciated that the frequently occurring messages that are part of the guidance 230 of the collection procedure 70 may be displayed to the patient 12 by the processor 102 on the display 108 to provide guidance to the patient throughout the data collection process. It should be appreciated that as part of the protocol script, the processor 102 may end the collection procedure 70 in one embodiment, or in another embodiment give the patient the option of selecting to end the collection procedure 70 on the display 108, whenever any specified exit criteria are met. Once data collection is complete in step 418, the protocol script 401 then hands over control of the processor 102 to the parsing script 403 in step 420.

Referring to FIG. 14, which highlights the role played by the parsing script 403 in passing control after the collection procedure 70 is completed, the parsing script 403 checks whether the contextualized data 170 in the data file 145 is not completed. To accomplish this, processor 102 reads contextualized data 170 from memory 110 in step 422 and looks for any exceptions (e.g., < null > values for any unique identifier 167) provided in data file 145 as an exception check in step 424 according to parsing script 403. When possible, the processor 102 utilizes the data available on the collection device 24 in step 426 to attempt to resolve any of these exceptions. As one example, applicable data may be obtained from non-collection procedure events or from data collected as part of another collection procedure 70. If the exception cannot be resolved from the existing data, the collection procedure 70 is marked as incomplete in step 428. At this point, the done flag 257 for the collection procedure 70 is set to incomplete (e.g., unset, < empty >, a predefined value, etc.). Otherwise, if there are no exceptions and/or all exceptions are resolved in step 426, the processor 102 sets the completion flag 257 to completed and may then display the results of the collection procedure 70 in step 430. Processor 102 then collects all data associated with collection procedure 70 (i.e., data file 145) according to parsing script 403, and hands control over to analysis script 405 in step 432.

In step 434, if the done flag 257 is marked as completed in the data file 145, the analysis script will cause the processor 102 to perform all necessary analysis on the data collected in step 432, such as the analysis 258 detailed in the collection procedure 70 (FIG. 6B). In one embodiment, simple analysis routine calculations may be performed on the collection device 24, while the analysis may be performed on a computer, such as computer 18 or 25, for more complex collection procedures 70.

When a collection device 24 containing one or more collection procedures 70 is connected to a device reader 22, such as a Smart-Pix device, connected to the computer 18 or clinician computer 25, the software 32 causes the associated processor to automatically display a list of completed collection procedures 70 and their associated data files 145.

In one embodiment, the software 34 may interact with a device reader 22 for visualizing the results, such as provided as a SmartPix device, or any other device (including computers 18, 25, etc.) capable of displaying the results of the analysis of the data from the collection procedure 70. At this point, if on the clinician computer 25, the clinician 14 may decide to view the results of the completed and analyzed collection procedure 70 or to conduct an analysis on the completed collection procedure 70. The clinician 14 may also review any collection procedures 70 that have not been completed and attempt to assess abnormalities present in the collection procedures 70. This interaction gives the clinician 14 the opportunity to give feedback to the patient regarding his data and/or assess why the existing collection procedure(s) 70 could not be completed.

Example of use.

Referring to FIG. 15, an example of use is provided in which the sequence of actions performed by the clinician 14 and the patient 12 are highlighted. The sequence contains an overview of clinician 14-patient 12 interactions from the formulation of medical questions to the completion of the collection procedure 70. The dotted line marks the boundary between the clinician 14 domain and the patient 12 domain, and this is also the boundary where information exchange occurs. The discussion regarding the completed collection procedure 70 may also be used to encourage the patient and give the clinician 14 the opportunity to provide feedback regarding patient performance and progress.

In step 440, the patient visits the clinician 14, and in step 442, the clinician identifies a problem, resulting in the selection of a medical use case (medical problem) in step 444. After selecting a medical question, for example, on the computer 25, the clinician uses the computer to select and define/customize the structured collection procedure 70 in step 446 using the methods 200 and/or 300 (fig. 5A and 7A). After the structured collection procedure 70 is specified, the computer 25 provides the structured collection procedure 70 to the collection device 24, which is received in step 448. After the entry criteria 226 provided in the procedure 70 are met in step 450, the patient 12 begins data collection according to the structured collection procedure 70 using the collection device 24. During data collection in step 452, individual events 237 are automatically scheduled by the collection device 24 according to the schedule of events 222 contained in the structured collection procedure 70. The adherence criteria 224 are applied at least to all biomarker measurements that are automatically assessed and recorded by the collection device 24 to meet the adherence criteria. In step 454, once the exit criteria 228 are met, the structured collection procedure 70 is completed. Next in step 456, the patient 12 may perform any available collection device-based analysis 258, if desired. A report, such as the data report mentioned in step 434 (fig. 14), may also be generated next in step 458. In step 460, data (e.g., completed data file 145) from the collection device 24 or from the patient computer 18 is preferably sent to the clinician computer 25. The collected data is received in step 460 and then analyzed in step 462. Next, a report may be generated in step 464, which may be used to facilitate discussion with the patient 12 regarding any additional outcomes in step 466. The documentation is next printed in step 468, which may be provided to the patient 12 in step 470, and may be recorded (stored) in the electronic medical record of the patient 12 in step 472. Various embodiments regarding status reporting are discussed in later sections.

Generation, modification and transmission of collection procedures.

Embodiments of the present invention also enable the generation, modification, and transmission of collection procedures 70 to/from structured test enabled devices, such as collection device 24. Since the collection procedure 70 originates from, and is intended to address, a particular medical use case or issue, the transfer of the resulting information (e.g., data file 145) from one device to another is conducted in a secure manner. Further, a method is provided in which all collection procedures relating to information (e.g., data files 145) for a patient or a group of patients may be managed in a safe and efficient manner.

It should be appreciated that the discussion provided below includes various aspects of interaction between the clinician 14 and the patient 12 discussed above with respect to FIG. 15. In particular, the following disclosure provides details regarding the infrastructure required to manage the generation, transmission, and analysis of the collection procedure 70. Reference is also made below to the system 41 of fig. 2 because various aspects are provided relating to the transfer of devices and information (data, reports, etc.) to and from the devices 18, 25 and 52.

In one illustrated embodiment, system 41 may include: a server 52, which is a web server of software 34 residing on the clinician computer 25, acting as a repository for a plurality of collection procedures 70a, 70b, 70c, and 70 d; and a collection device 24 provided, for example, as a blood glucose meter. Accordingly, these components will be referred to as "servers", "software", and "meters", respectively. Further, the computer 25 on which the software 34 resides is referred to as a "client".

In one embodiment, the server 52 may act as a central repository for a plurality of collection procedures 70a, 70b, 70c, and 70d for solving a particular medical problem. Accordingly, one or more collection procedures 70 may be downloaded from the server 52 to the clinician computer 25. In such an embodiment, all communications between the server 52 and the client computer 25 are in a secure and network-based format. Furthermore, in another embodiment, there is not a full two-way data transfer between the computer 25 and the server 52, so that it is not possible to transfer patient data to the server 52. Furthermore, in other embodiments, the requirements for the collection procedure from the server 52 can only be set forth with a valid identifier. Such an embodiment ensures that only authorized clients are allowed to access the server 52 to download the required collection procedure(s) 70.

In one embodiment, each collection procedure 70 downloaded from the server 52 can only be used once (e.g., if the completed flag or status is set, the procedure 70 cannot be run again until re-authorized by the clinician 14). Access is required from an authorized client user with a valid ID 71 (fig. 2) for each successive download of the collection procedure 70. The server 52 also provides updates to the client computer 25 to ensure that the software is up-to-date. There are also limitations on the communication from the client computer 25 to the server 52. The server 52 has access only to information relating to the installed version of the software 34. It is not possible for the server 52 to access any data residing in the client database (e.g., memory 78). In addition, the data on the client computer 25 is access controlled so that it cannot be used and accessed without the necessary permission.

The software 34 residing on the client computer 25 acts as an interface between the server 52 and the meter 24. The software 34 at the front end includes a user-friendly interface that provides the clinician 14 with prepared information relating to the general clinic. This information may include details about all assigned patients, details about patients that the clinician 14 is scheduled to visit on a given day, and details about patients that require additional attention. The software 34 also interfaces with a database that includes pertinent patient data set by individual patient IDs, such as used by and provided in the healthcare record system 27. The software interface also allows the clinician 14 to access details of the patient 12 using the patient identifier. In this manner, the software 34 provides the clinician 14 with information regarding the collection procedure(s) 70 that the patient 12 has completed (i.e., those collection procedures for which the completion flag 257 is set to completed), the associated results, and the collection procedure(s) 70 that the patient 12 is currently performing. All data residing on the client computer 25 is secure and access controlled. The server 52 cannot access the data. The clinician 14 may access data from all patients in the clinic. In addition, an individual patient 12 may access his data (e.g., from a clinician's server) in a secure web-based format using his patient identifier. This data is downloaded from the meter 24 to a database on the computer 25 and associated with the patient 12 using the patient identifier.

Software 34 also performs an analysis on the data as it is downloaded from meter 24 to ensure that data integrity is maintained and that no data corruption occurs while transferring. The client computer 25, by means of the software 34, may also send emails to the individual patients, and these emails may contain information about the upcoming appointment, reminders as to what the patient should do after the appointment, and reports on the results of the completed collection procedure 70. When the clinician 14 downloads the collection procedure 70 for a particular patient from the server 52, the collection procedure 70 is associated with the patient identifier. This makes it possible to grasp which collection procedures 70 are currently in progress for their patients.

The downloaded collection procedure 70 may be modified by the clinician 14 using the software 34 to tailor the collection procedure 70 to the needs of individual patients as discussed in the previous section (fig. 7B). In modifying the collection procedure 70, the clinician 14 also has the option of altering the analysis that will be conducted on the modified collection procedure 70. Further, even for standard collection procedures 70 that have not been modified, the clinician 14 has the option of adding additional options for analysis.

In addition, the clinician 14 may decide and set guidelines as to when the procedure 70 must be terminated. For example, the clinician 14 may decide and set how many compliance violations are allowed, i.e., how many measurements the patient may miss, e.g., by using the option parameters 232 in the collection procedure 70.

Once the collection procedure 70 is introduced into the meter 24 by the clinician 14 (details are discussed in the next chapter), the collection procedure 70 cannot be altered by the patient 12 (i.e., only by authorized users with editing rights, which are typically only the clinician 14). In addition, the collection procedure 70 is associated with both the clinician 14 (prescriber) and the patient identifier in order to ensure that the collection procedure 70 and associated data (e.g., data file 145) are mastered.

The software 34 also allows the clinician 14 to select the type of report that will be generated once the completed collection procedure 70 has been analyzed. The report is adjusted for the device on which it is to be viewed. The report may be for example for a mobile device such as a telephone, palm device or meter, or for a computer, or for a printed format. The software 34 also has the capability to interface with an electronic medical record system to add patient data to the medical record as well as the results of the analysis performed on the data from the collection procedure 70.

The meter 24 serves as a mechanism by which prospective and contextualized data is collected by the patient 12 as recommended by the collection procedure 70. The meter 24 may be owned by the patient, or it may be owned by the clinician 14 and lent to the patient 12 during data collection associated with the collection procedure 70. The clinician 14 may introduce the collection procedure 70 into the meter 24 by several mechanisms. For example, in one embodiment, the collection procedure 70 may be downloaded from the server 52 and added to the meter 24 via a connection cable linking the client computer 25 to the meter 24. In another embodiment, the collection procedure 70 may also be obtained on a chip (e.g., the computer readable medium 40) that may be inserted into the meter 24. The collection procedure 70 is then loaded into the firmware of the meter 24, where it may be initiated by the patient 12. In another embodiment, the collection procedure 70 may also be introduced using an RFID tagged chip (e.g., a computer readable medium).

Along with the downloaded collection procedure 70, the meter 24 also has the ability to display instructions to the patient 12 to provide guidance to the patient at the time of data collection. Further, as discussed previously, the collection procedure 70 may incorporate both a patient identifier as well as a clinician identifier into the meter 24. Similarly, the data collected from the meter 24 may be associated with a patient identifier and a clinician identifier, such as part of the setup data 163 (FIG. 4) in the data file 145. In addition, the setup data 163 in the data file 145 may also include information about the meter 24 (i.e., measurement noise, calibration data) as well as the strip lot number and other information about the strip used for any data collection event 237. Such information may be helpful in data analysis.

Upon completion of the collection procedure 70, the meter 24 may be connected to the software 34. At this point, data, such as data file 145, is securely transferred and stored by processor 76 of client computer 25 in accordance with software 34 running thereon. After the analysis performed on the data from the collection procedure is completed by the software 34 on the client computer 25, the meter 25 also has the ability to store the results of the analysis for reference by the patient. Reference will now be made to fig. 16-18.

Software GUI.

In one embodiment, a typical workflow is presented highlighting further features of the software 34 that may be used through a graphical user interface (GUI 500) provided on a computer, such as the computer 25 and/or the server 52. Considered in this example is the typical situation when the clinician 14 opens an instance file for a particular patient. As shown in FIG. 16, the clinician 14 may readily visualize important details about the displayed patient file 502 using the GUI 500 of the software 34 running on the client computer 25. On a top pane 502 of the GUI 500, the clinician 14 can see and use various administrative tasks 504, such as changing a displayed patient file, creating an email containing information from a patient file, creating a fax containing information from a patient file, saving a patient file, bookmarking data in a patient file, selecting an existing bookmark, printing information/charts from a patient file, and so forth.

On the left pane 506 of the GUI 500, the clinician 14 has additional options 508, such as an option to download patient data, such as data files 145, when the meter 24 is connected to the computer 25 or 18 (either by wired or wireless means). Other options 508 may also include viewing details about patient profiles, logs and additional records, charts based on calculated data, and so forth. As shown in fig. 16, a summary option is selected, which shows its contents in the main pane 510.

Main pane 510 designates all typical steps in the workflow for therapy management of patient 12. These steps may include the following: disease state 512, therapy selection 514, therapy initialization 516, therapy optimization 518, and therapy monitoring 520. Each step provided as an icon on GUI 500 is discussed later.

Disease state 512 is a determination of the disease state, e.g., whether the patient is a type 1 or type 2 diabetic. Generally, the disease state determination is performed when the patient 12 visits the clinician 14 for the first time or when the clinician 14 suspects that a particular patient may be at risk. Once the disease state is determined, a therapy selection 514 follows, and the clinician 14 needs to select an appropriate therapy that takes into account the patient's disease state. Since therapy selection 514 may include the processing of methods 200 and 300 shown in fig. 5A and 7A, respectively, further discussion will not be provided. Therapy initialization 516 is a therapy initialization process that involves establishing initial details by which a therapy is administered to the patient 12. This aspect may include details regarding the initial dosage of the therapy, the time at which the therapy is administered, etc. Further details regarding therapy initialization 516 are provided later with reference to fig. 17. Therapy optimization 518 involves determining the optimal effective dose for the patient so that it does not cause side effects. An example OF a METHOD FOR therapeutic optimization is disclosed in U.S. patent application No. 12/643,338, "stuttered STRUCTURED METHOD FOR two DIAGNOSTIC OR therapeutic SUPPORT OF A PATIENTWITH A chloronic DISEASE AND DEVICES thermal", filed on 21.12.2009 and assigned to Roche Diagnostics Operations, inc. Finally, therapy monitoring 520 involves routinely monitoring the patient 12 to detect therapy obsolescence after the selected therapy is optimized. Thus, the GUI 500 provides the clinician 14 with all of the useful information in a user-friendly format.

Fig. 17 represents the situation when the clinician 14 has determined a disease state by disease state 512 and therapy selection 514 and has selected a therapy and is at the step of therapy initialization 516. As shown, the software 34 obscures completed steps in the GUI 500, with only the currently in-progress step (e.g., therapy initialization 516) highlighted. Furthermore, in one embodiment, the software 34 does not allow the clinician 14 to proceed to the next step without completing all required actions in the current step (in other words, all previous steps have been completed). However, the software 34 also provides the clinician 14 with the option of returning to and modifying the previous step by selecting a particular icon for the step in the GUI 500.

In this example, the patient 12 is a diabetic patient, and the clinician 14 needs to initialize long-term-action insulin therapy for type 1 diabetic patients currently for therapy initialization 516. As shown, all available initialization options 522 for initializing the therapy are presented to the clinician 14 for this step on the GUI 500. For example and as shown, the clinician 14 may select a certain type of medication 524 (such as basal insulin, which is shown to be long acting) and select protocol selection icons 526 associated with the medication 524, and each of which is associated with a collection protocol 70 that may be used to address therapy issue(s) with respect to a particular medication (e.g., time of arrival (Lantus), insulin detemir) listed (and available) in association with the type of medication 524. The software 34, via the GUI 500, also allows the clinician 14 to decide whether additional therapy related parameters 528, such as insulin sensitivity, insulin to carbohydrate ratio, etc., should be retrieved when needed. Further details for therapy initialization can also be viewed by selecting icon 530 for general information.

When the clinician selects one of the protocol selection icons 526, the software 34 provides a snapshot 532 of the set of conditions in the associated collection protocol 70, as shown in FIG. 18. Typical initial conditions provided in snapshot 532 may include: dose frequency (dose modulation), (default) start dose, target level, schedule of events (e.g., measure fasting glucose for 3 days), recommendations for calculations (e.g., modify drug dose based on 3 day median, measure remaining days to assess effect), and so forth. If multiple details about the selected collection procedure 70 are desired (such as relevant medical literature), example studies and the like that may form the basis for the structured collection procedure may be viewed through multiple detail icons 534. The clinician 14 may also choose to accept the provided collection procedure 70 via the accept icon 536 or propose a modification to the collection procedure 70 via the modification protocol 538. A screen representation of all parameters for making a modification in procedure 70 may be opened, for example, on GUI 500 by selecting modification protocol 538, such as depicted in fig. 7B, and no further discussion is provided since it has been previously discussed in the preceding section. Once the collection procedure 70 has been modified, the clinician 14 may review and accept the changes. After accepting the collection procedure 70 by selecting the accept icon 536 on the GUI 500, the software 34 causes a processor (e.g., the processor 76) to send the completed collection procedure 70 to the meter 24, as previously discussed in the previous section. Specific advantages of the foregoing embodiments of the invention will be mentioned below.

Although not limited thereto, embodiments of the present method provide the advantages mentioned below. Particular embodiments enable contextualization of the collected data by taking into account factors such as meals and existing medications. All data analysis can be performed on the expected data, that is to say contextualized data collection taking into account the medical problem that needs to be solved. Each of the individual collection protocols 70 is directed towards collecting bG data in order to address specific medical problems, such as controlling postprandial glucose excursions, adjusting fasting glucose values, characterizing a patient's insulin sensitivity, monitoring a patient's therapy response, and so forth. Using such a collection procedure allows the task of collecting BG values to have a target orientation because the patient knows why he or she is conducting the test. It is believed that knowing the cause for conducting the test results in improved compliance.

Moreover, particular embodiments provide the infrastructure necessary to manage multiple collection procedures 70 run simultaneously by different patients 12 on different collection devices 24, while ensuring secure network-based communications for receiving and transmitting the collection procedures 70 and the results obtained through analysis of these collection procedures 70. For example, certain embodiments provide assistance to the clinician 14 by: making it easier for the clinician 14 to influence all phases of patient therapy from disease state determination to periodic monitoring under on-the-fly periodic therapy; the various stages that make it possible for the clinician 14 to administer the collection procedure 70 execution for a set of patients in a secure and web-based format; flexibility is given to the clinician 14 by providing options for selecting a collection procedure 70 from a predetermined list or modifying a collection procedure 70 based on patient needs; the interaction between the clinician 14 and the patient 12 is made more efficient as the communication is completely data-centric and guided by, for example, upcoming medical problems.

And (6) reporting the status.

Status reports may be provided in many forms. For example, in certain structured collection procedure embodiments, information may be provided indicating at what stage of protocol execution the patient is. For example, as depicted by fig. 19A, the display 106 of the device 24 may provide information that this event 237n (where n is a, B, c, …) (fig. 6B) has been successfully completed and the next event is event 237n + 1 with respect to the collection procedure 70, such as in the form of a displayed electronic message 590, for example. Additionally, the results at the end of execution of the collection procedure 70 may be provided to the patient (as part of a status reporting results message 592, such as recommendation 260 (fig. 6B) in other embodiments), as depicted by fig. 19B. In other embodiments, many different reports may be electronically displayed (such as via the display 106 of the device 24) as a report list 594, e.g., report a, report B, report C, etc., from which the patient may select a desired report (from the list at the conclusion of the structured collection procedure 70 as depicted by fig. 19C) via the user interface 146. In such embodiments, for example, one report may be a table or graphical representation of the results of the collection procedure (e.g., recommendations 260), another report may be a table or graphical representation of how well the collection procedure was followed, and yet another report may be a table or graphical representation of the performance of different aspects of the collection procedure used as a guide for selecting additional collection procedures or identifying areas that require additional user support. Other types of reports may include: providing a number of compliance elements; providing average glucose readings over the fasting and postprandial periods; and providing differences in bG in weekday and weekend periods. In other embodiments, the functionality to save and print 596, 598 the selected report may also be provided by the device 24 onto the display 106 and communicated to the designated healthcare provider (e.g., clinician 14) via a send function 599, as also depicted in fig. 19C. In such embodiments, a health care provider to which the selected report is to be sent, e.g., over the network 50, may be designated in the memory 110 of the device 24, such as by an email address and/or an IP address of a server, computer, and/or computing device, such as the health care provider. In other embodiments, the patient 12 will be exposed to a "partial" report of ongoing results that are expected to the report they will receive at the completion of the structured collection procedure. Such features may also be implemented via the report list 594. In other embodiments, such status reports may be displayed on many different devices, such as device reader 22, or with any other device including computers 18, 25, etc. (which may display such status reports for collection procedure 70).

In other structured collection procedure embodiments, at each aspect of running the collection procedure 70, from initialization until the end of execution, some sort of status report may be provided in a manner that assists the patient in executing and completing the structured collection procedure. The types of status reports that may be provided at each of the various performing aspects of the structured collection procedure 70 are discussed later with reference to fig. 20, which depicts a method for performing a structured collection procedure according to another embodiment of the present invention. It will be appreciated that similarly numbered process steps shown in fig. 20 with process steps discussed in proceeding sections have similar functionality, and thus, other discussions are not provided for the sake of brevity.

Start of structured collection procedure.

The start information 600 may be provided prior to the patient 12 initiating the structured collection procedure 70 in one embodiment, or as part of the procedure started in process step 316 in another embodiment. In one embodiment, the start information 600 communicates to the patient 12 the reason(s) why the structured collection procedure should be performed and also what results are expected upon successful completion of the collection procedure 70. In other embodiments, the start information 600 may include information about the entry criteria 226 that need to be met in order to start the collection procedure 70 in process step 318. In addition, general recommendations regarding the requirements for adherence criteria 224 are provided in other embodiments of start information 600, such as explaining what constitutes a measure that cannot be used (e.g., not fasting, time necessary before fasting readings, etc.) and encouragement (e.g., better adherence results better, and the entire task will be completed faster). In other embodiments, specific information for the clinician 14 may also be included in the start information 600, such as the expected group of users of the collection procedure 70, the responsibility of the collection procedure 70, and so forth. It will be appreciated that such start information 600 may be given as a printed report, may be made available over a network in a secure manner so that it can be viewed and/or displayed on a computer, such as computers 18, 25 (fig. 1), on display 106 of device 24, or on the display of any other suitable handheld device. In other embodiments, the start information 600 is included as part of the guidance 230 provided by the structured collection procedure 70 at startup (fig. 21) and/or may be predefined in the collection procedure 70 and customized by the clinician 14 as needed.

In other embodiments, the start information 600 may provide the total amount of time expected and the number of measurements desired to complete the collection procedure. An example of such information for total time and measurements provided by the start information 600 may be a message stating that the "expected amount of time is about 4 weeks in order to complete the collection procedure requiring 30 fasting pre-breakfast measurements". It is to be appreciated that the start information 600 may be delivered in many different ways in addition to the measures described above. For example, a calendar (i.e., electronic calendar 602) may be provided, as depicted by FIG. 19D, either printed, electronically provided to the computer 18 (via the network) and/or on the device 24, which contains the date and time at which the measurements were taken in order to execute the associated collection procedure 70.

During the execution of the collection procedure.

When the structured collection procedure 70 is executed, for example, on the device 24, there are a number of indicators that may be provided to the patient 12 as status updates. These indicators help the patient 12 know how he/she performed in the performance of the collection procedure 70, and are also advantageous for providing guidance in particular or adverse conditions that the patient 12 may encounter. Such status indicators include, but are not limited to, the following examples.

Initially, and as set forth in the preceding section above, if the entry criteria 226 have not been met in step 318, the structured collection procedure 70 may end. If the entry criteria 226 are not met in step 226, in this alternative embodiment, a message 601 may be provided informing the patient 12 of such fact and requesting in step 607 whether to restart the procedure by again providing the start information 600. Additionally, during execution of the collection procedure, the display 106 of the device 24 may provide a status indicator 604 (fig. 19E) indicating how far the patient 12 has advanced and how far he/she must advance in completing the collection procedure 70 running on the device. In one embodiment, such a status indicator 604 may be provided as a pointer 603 in the gas gauge 604A, as depicted by fig. 19E, where empty (empty) represents the start of the collection procedure 70 and full represents the end of the collection procedure 70. In another embodiment, status indicator 604 is provided as progress bar 604B depicted by fig. 19F, where bar 605 progresses from 0% completion on one side of the indicator toward 100% completion on the other side of the indicator. In one embodiment, the numerical value indicated by the pointer 603 of the gas gauge 604A or the bar 605 of the progress bar 604B may be based on the number of measurements successfully collected (i.e., collected according to the scheduled event 237 and which meet the adherence criteria 224 in step 322) divided by the total number of such successfully collected measurements required (i.e., meeting the exit criteria 228) and displayed as a fraction (fig. 19E) or percentage (fig. 19F). In particular, the processor 102 may illustrate this progression of the structured collection procedure 70 by counting the number of unique identifiers associated with the collected patients stored in the memory 110 (i.e., the data file 145) and counting the number of events 237 in the schedule of events 222 with the assigned adherence criteria 224 multiplied by any number of days requirements provided by the exit criteria 228 (e.g., for 3 days of the collection procedure depicted by fig. 21). Other examples of what values the progression measures in the progression based on/based on may include, but are not limited to, obtaining a specified bG value when a value crosses a threshold, and additional criteria. In other embodiments, the target may be indicated by a percentage (%) of the target reached (such as a drug titration until a diagnostic measurement range is reached); by showing a comparison with the total number of such patient titrations; and measuring progress via a characteristic "drug rate of change" to "remaining duration" function prediction for the remaining duration of the current user. It will be appreciated that this progression showing how long it takes to complete the collection procedure 70 may differ based on whether the collection procedure is a fixed schedule evaluation or a variable schedule evaluation/optimization (which may take an unknown amount of time to complete). For example, a collection procedure (such as progress) that provides a fixed schedule assessment may be measured by the amount of time remaining or by the amount of events remaining. For example, such progress may be shown by a simple countdown, such as, for example, a graphical display message "you have x days and y measurements until completion" provided on the display 106 or as part of the information displayed in the electronic calendar 602 (fig. 19D). For collection procedures that provide variable schedule evaluation/optimization, for example, measurements for completion may be started by default numbers based on clinical data provided by the clinician 14, clinician computer 25, and/or server 52 (such as of manufacturer 64). In such an embodiment, the completed trajectory of the patient 12 toward the collection procedure 70 will initially be assumed to coincide with a predicted trajectory, which may be based on a median or average of individuals (similar individuals or all individuals from one group source) who have completed the same procedure. As data from the patient is collected by the device 24, the patient's trajectory may be overlaid on a predicted trajectory by the processor 102 (e.g., provided as part of the setup data 163 for the collection procedure 70). The predicted duration remains the same as long as the patient's trajectories overlap within the model based on the predetermined variation. However, if the actual trajectory changes by more than a predetermined value (e.g., cubic spline function, etc.) (e.g., also provided as part of the setup data 163 of the collection procedure 70), it may be used to infer a newly estimated end point, and thus the microprocessor of the device 24 may dynamically adjust the planned completion of the collection procedure for the patient 12 and display accordingly. It will be appreciated that for each type of collection procedure, there may be a different predicted trajectory. In other embodiments, the incentive encouragement messages 606 may also be provided with each status indicator 604, such as, for example, a suggested change in adherence that may increase the rate of progress of completing the running collection procedure 70. For example, if the processor 102 notes in the data that the patient 12 has stopped at a stage of the optimization-based collection procedure 70 because the patient is not in the required fasting state at a certain measurement time (via, for example, either the entry criteria 226 in step 318 or the adherence criteria 224 in step 322 not being met), the device 24 may encourage them to complete the important step and provide guidance to do so, such as providing a message that requires the patient to start within 60 minutes to drink only water until the time of the fasting measurement. This gives an alert for the last opportunity to eat and an alert sufficiently in advance that the user can act on it.

In other embodiments, the patient 12 may be given feedback on the degree of his or her adherence to the collection procedure 70. As illustrated by fig. 20, in this alternative embodiment, if the adherence criteria 224 is not met after the process step 322, then in this process step 610 the device 24 checks to see if a violation has occurred (i.e., the patient failed to perform the particular event 237). Examples of violations for a particular event 237 may be, for example, a failure to make a requested measurement within a requested test window, a failure to eat a particular meal type and/or quantity, no fasting, no input of requested data, no performance of a requested action, and so forth. For each event 237, the check for violations may be programmed into the collection procedure 70 (e.g., predefined and customizable by the clinician), such as by indicating yes or no in each violation parameter 609 of the collection procedure 70, as depicted by fig. 21.

In the illustrated embodiment, the selection of "Y" in violation parameter 609 indicates to processor 102 that a condition(s) that failed the associated adherence criteria 224 will contribute to the violation during process step 610. If no such pre-defined violation has occurred (i.e., violation parameter 609 is set to no "N"), then the process continues with evaluating exit criteria 228 in process step 326 (fig. 20), as disclosed above in the previous section with reference to fig. 8A. However, if the violation parameter 609 is set to "Y," then the processor will automatically send a violation message 640 to indicate that a compliance violation has occurred in step 610. In one embodiment, the device 24 will automatically send a violation message 640 to the clinician via the communication interface 124. Such a violation message 640 can be a simple notification to the clinician that the patient has violated, and/or in another embodiment, a requirement that the patient be contacted instead due to a compliance violation. In another embodiment, a violation message 640 may be provided by the processor 102 on a display to notify the patient 12 that a violation has occurred. In another embodiment, violation message 640 may be a prediction of what may happen if patient 12 does not continue to meet the adherence criteria, such as, for example, "your weight is increasing"; "your treatment will not be as effective" and so on. It will further be appreciated that when a violation occurs, the processor 102 may also record the violation occurrence in a violation field 611 (in an embodiment of the data file 145) for the associated event 237, as depicted in FIG. 4.

As also depicted by fig. 4, type code 613 may be provided by the processor 102 in the violation section 611 to indicate what caused the violation to occur (e.g., "a" measures before the window, "B" measures after the window, "C" skips the measurement, "D" takes an incorrect amount of the requested medication, "E" does not take the requested medication, "F" takes the medication at an incorrect time (e.g., an incorrect pre-meal or post-meal time), etc.) to provide a context for the violation. For example, an event 237d that does not receive the unique identifier 167 because it fails to comply with 224 is a measurement that would result in a violation (i.e., the violation parameter 609 is set to "Y" in the collection procedure 70 for the associated event 237), and thus cause a violation to be skipped. Thus, the processor 102 records the "C" type code 613 in the violation section 611. Such a context is information that a clinician may use in assessing how to adjust the collection procedure 70 to better suit the patient 12 in the future.

Referring back to fig. 20, next in one embodiment, in step 612, the violation counter is incremented in process step 612, and in process step 614, the number of violations (i.e., the violation counter) is checked to see if it exceeds the maximum number of violations allowed (i.e., the Violation Number (VN)) before automatic termination of the collection procedure 70 occurs because an adherence violation is exceeded. The violation number(s) (vn (s)) 615 may be preset in the collection procedure 70 (as depicted by fig. 21) and adjusted as needed by the clinician. In other embodiments, a plurality of violation counts 615 may also be provided in the collection procedure 70, where each violation count may be set for each of the type codes 613, such that if the violation counter for each type code 613 exceeds the associated violation count, the collection procedure 70 will terminate for that particular type of violation. In other embodiments, the number of violations 615 will represent the number of violations in a predefined time period rather than the absolute number since the beginning of the collection procedure 70. For example, the predefined time period may be specified and adjusted in the collection procedure by the time parameter (t) 619. For example, in one embodiment, the processor 102 will also check to see if the violation counter exceeds the violation count 615 within the associated predefined period (t) 619 in step 612, or in another embodiment exceeds any of the violation counts associated with each type of code 613 within their associated predefined period (t) 619. In the illustrated embodiment of fig. 20, if the Violation Number (VN) 615 is exceeded in process step 614 (i.e., the violation counter's "violation" is greater than the Violation Number (VN)), then a failure message 617 is provided in process step 616 and the procedure ends in process step 328, as previously discussed in the preceding section, above. The failure message 617 may be predefined in the collection procedure 70 (as depicted by fig. 21) and customized as needed by the clinician 14. The failure message 617 may be provided on the display 106 of the device 24 and/or provided to the clinician 14 via the communication interface 124.

In one embodiment, the patient 12 may be told how many other compliance violations he/she may have before he/she may be forced to exit the structured collection procedure 70, such as part of a message 606 provided in a calendar embodiment (FIG. 19D). For example, the message may be "you have { VN-violating counter } minor violations of { VN } minor violations," or "you have remaining { VN-violating counter } minor violations," where { } indicates the current parameter value. In other embodiments, similar status indicators such as gas gauge 604A and bar indicator 604B may convey such information graphically. For example, fig. 19G shows a barometer 604C indicating the number of compliance violations (e.g., violation counter 2) and the maximum number of compliance violations allowed (i.e., violation counter (VN) 3) confirmed before the automatic termination of the collection procedure 70 that occurred because the compliance violation was exceeded (i.e., violation of violation counter is greater than Violation Number (VN) in process step 614). In other embodiments, such information may be provided graphically by icons and/or images that change to show changes in the remaining violations, such as in a video game showing the number of lives remaining, for example.

In other embodiments, after each violation that cannot result in a termination (e.g., violation count < VN in process step 614), or after a set number of such violations without a termination (e.g., violation count ═ s, where s < VN), device 24 may check to see if the user should be queried, such as in process step 618. In other embodiments, process steps 612, 614, and 616 may be made optional and therefore not provided, and in other embodiments, process steps 610, 612, 614, and 616 may be made optional and therefore not provided, where in such embodiments, after compliance criteria 224 is not met in process step 322, device 24 then checks to see if the user should be queried in process step 618. If in the various embodiments above the result of process step 618 is no, such as in the case where the query message(s) 621 (fig. 21) were not defined in the structured collection procedure 70 or the set number(s) of such non-terminated violations 623 (e.g., violation count < > s) have not been reached, then the process continues to process step 326. If the result of process step 618 is yes, then in process step 620 an inquiry message 621 is provided to the patient 12 on the display 106 of the device 24. The query message 621 and the set number(s) 623 may be predefined in the collection procedure 70 (as depicted by fig. 21) and customized as needed by the clinician 14.

For example, in one embodiment, the query message 621 may be a question to the user asking if he/she understands the structured collection procedure 70, which is asked after the second violation (i.e., s-2). In other embodiments, other values for the set number 623 may be used such that the query message 621 is asked after a certain number of violations have occurred, which may be set to the "all" value of the query message after each violation, or the query message 621 will not be asked so that the processor 102 continues with a < null > value at process step 326.

In the illustrated embodiment depicted by fig. 20, the user may answer the query message 621 via selecting "yes" or "no," e.g., via the user interface 146 (fig. 3). If "yes," the collection procedure 70 will continue, for example at process step 326 (FIG. 20). If "no," the device 24 provides help information 625 in process step 622. Such help information 625 may include re-display of start information 600 relating to the purpose of the collection procedure 70 and requirements on how the collection procedure needs to be conducted. If after such information is displayed to the user (e.g., on display 106), device 24 may in other embodiments further query the user in process step 624 by presenting another query message 621'. The query message 621' may be, for example, a request to see if the patient requires feedback from the clinician 14 to better understand why the violation occurred, to which the patient answers yes or no via the user interface 146. If "no," the collection procedure 70 will continue, such as at step 326, and if "yes," the device 24 will send a message 627 (e.g., via the communication interface 124) to the clinician 14 in a process step 626 to contact the patient instead for the compliance violation. The query message 621', help information 625, and clinician message 627 may also be predefined in the collection procedure 70 (as depicted by FIG. 21) and customized as needed by the clinician 14.

In other embodiments, in process step 618, the processor 102 presents the question and answer on the display 108, such as presenting a question with a yes or no answer, by which to determine why the adherence criteria have not been met. If, in process step 618, the patient's 12 use of the question and answer (i.e., entering the answer via using the user interface 146) fails to provide a determination as to why the adherence criteria have not been met, the processor 102 displays a message on the display to contact the clinician 14.

It will be appreciated that the type of question and/or the representation of the question and answer in one embodiment may assist the patient 12 in returning to the collection procedure 70 with less misunderstanding. In other embodiments, the adherence violation in process step 628 results in a classification (triage) message 629 being automatically sent to the clinician 14 (e.g., from the device 24 to the clinician computer 25 via the network 50) to help the clinician 14 identify which patients 12 are at risk of not completing the structured collection procedure 70. Such messaging prompts the clinician 14 to contact the patient 12 to provide information and other incentives.

In other embodiments, the collection procedure 70 may provide a possible way to reduce the number of compliance violations that are accumulated by closer compliance. For example, the clinician 14 may reset the violation counter and/or change the violation count 615 at some point during the collection procedure 70. In other embodiments, the device 24 may provide a way for the patient 12 to obtain adherence credits based on adherence periods where successful completions would eliminate successful completions of cumulative violations, and/or to obtain reductions in pending violations by selecting protocol forms that provide more guidance on aspects of the protocol that are the source of the violations. In other embodiments, the device 24 may allow a patient with test issues at the correct time to select a version of the protocol 70 that provides more hints for an upcoming test, such as a reminder at the time of the test and at another time shortly before the end of the grace period for the test if the measurement has not been performed. In other embodiments, the number of accumulated compliance violations may be reduced by providing reminders at meal times when postprandial measurements were taken, by indicating time/details at the measurement times for the next measurement, and by providing encouragement during protocol execution.

In other embodiments, when a compliance violation occurs in a particular portion of the collection procedure 70, the device 24 may recommend that the user seek assistance, such as contacting the clinician 14 for possible understanding or motivation, and/or may provide particular information regarding where to seek such assistance. For example, the clinician may specify through the option parameter 232 that such information be provided if a violation occurs for that particular event 237. For such embodiments, the processor 102 then checks to see if such designation has been completed in the collection procedure 70 via the help flag "", which was provided in the option parameter 232 for the event 237 (e.g., for the "N1 hours after breakfast" event depicted by fig. 21), which in this case caused a violation, in a process step 630. If such a help flag ". sup." is provided, then the help message 631 is in a process step 632. For example, the information provided in the help message 631 may be included in the help information 625 and may include (but is not limited to) the network address of the online help content and the name and number of social support networks. In other embodiments, such information for the patient 12 may also include advice on how to treat the condition(s) in which the compliance violation has occurred. For example, suggestions may be provided as to what to do when the value of the physiological measurement collected in response to the collection event is outside of an expected range. Such suggestions may be provided as a list of Frequently Asked Questions (FAQs) and answers. Still other recommendations may require the patient 12 to make an assessment as to whether the violation is a recurring pattern, or a singular (singular) data point that is due to a particular acute problem (such as, for example, the patient is on vacation and therefore interpretable) or a chronic problem that has not changed anything, thus possibly indicating that something has changed physiologically or medically, and therefore needs to be changed before continuing.

As discussed in the previous section provided above, when the patient 12 encounters a severe hypoglycemic event, the recommendation provided by the device 24 will be to contact the clinician 14. However, in other embodiments, additional guidance may be provided in order to ensure that such adverse events do not persist, e.g., eating some carbohydrates, measuring again after a certain time, etc.

In one embodiment, after processor 102 evaluates that exit criteria 228 are satisfied in process step 326, processor 102 may automatically provide a status report, such as result message 640, in process step 638. The result message 640 may be provided by the processor 102 on the display 108 in one embodiment or communicated to the external device 132 via the communication interface 124, for example, to provide the result message 640 to the clinician 14. In another embodiment, in process step 638, the processor 102 automatically calculates adherence based on the patient data stored in the memory 110 (i.e., the data records 152 stored in the data file 145) and automatically provides a status report based on the calculated adherence. In such embodiments, the results message 640 provided by the processor 102 may indicate to the patient 12 and/or clinician 14 the results of the structured collection procedure 70, predictions as to what would be expected as a result of executing the structured collection procedure, and/or predictions based on calculated overall compliance, e.g., "compliance perfectly, treatment would be very effective," etc. In other embodiments, the processor 102 automatically runs a second structured collection procedure (e.g., one or more additional structured collection procedures 70a, 70b, 70c, and/or 70d as previously discussed above) after the exit criteria of the previous structured collection procedure are met, and then provides a result message 640 when the exit criteria of the second (or last) structured collection procedure are met. Again, the result message 640 may be the result of the structured collection procedure 70, a prediction of what would be expected as a result of executing one or more structured collection procedures, and/or a prediction based on the calculated overall adherence (i.e., based on patient data resulting from completion of the one or more structured collection procedures), such as to predict a health status, weight status, etc. after completion of the last of one or more additional structured collection procedures, and which may be displayed on the display 108 and/or communicated to the external device 132 by the processor 102. In another embodiment, a result message 640 is automatically sent to the clinician 14 via the communication interface 124 to indicate that the patient 12 has completed the structured collection procedure 70. In other embodiments, after the processor 102 evaluates that the exit criteria 228 are not met in process step 326 (fig. 20), the processor 102 then checks to see if the defined deviation(s) 635 from the expected behavior occurs in the execution of the collection procedure 70 in process step 634, and if so, the device 24 may suggest that the patient 12 contact the clinician 14 via the display contact message 633 in process step 636. In one embodiment, the exposure message 633 may be the same message as the failure message 617, or in another embodiment it possesses messages defined and customizable in the collection procedure 70. Also, an example when the patient's behavior deviates greatly from what is expected is as follows. When the patient 12 is undergoing the titration structured collection procedure 70, if the processor 102 notices that the data values 256 for the measurement of blood glucose in the data file 145 (fig. 21) do not show any decrease in fasting bG values over a predefined period of time (despite the increasing dose of insulin), a contact message 633 will be sent. Other such examples of deviation may be predefined via logical operations (e.g., boolean and conditional logic) provided in the deviation parameters 635 (fig. 21), provided in the option of the collection procedure 70, and which may be customized as needed by the clinician 14.

In other embodiments, the clinician 14 uses the clinician computer 25 to view a number of quality metrics (such as adherence, acceptance, hypoglycemia, severe hypoglycemia, hyperglycemia, and average blood glucose before and after completion of the collection procedure 70) after receiving the data file 145 (e.g., during a regular patient visit, regular data collection from the device 24 to the clinician computer 25, upon completion of the collection procedure 70, etc.).

The clinician 14 may also use the data provided in the data file 145 (e.g., collected as part of a regular data collection requirement from the clinician computer to the device 24 or as part of a scheduled data transmission by the device 24) to perform a comparison of the progress of their patients with respect to a patient population, such as others within their medical facility, or for a general population on the clinician computer, such as a manufacturer-maintained data store. In one embodiment, such a comparison may include the quality metrics described above, a time measurement-a calibration of changes relative to others in the population, or a cost measurement. Such comparisons provide the clinician 14 with a simple indication of whether the patient 12 is well-aligned with others, or whether the patient 12 requires intervention (intervention) in the form of skill training, goal training, or procedure exclusion. Based on the collected data file 145, if the collection procedure 70 has not yet been completed, a report may be run on the clinician computer 25 that provides a prediction of the patient's estimated time of completion of the collection procedure 70. Such an estimation may be based on a determination of how well the patient is progressing in adherence to the collection procedure based on the number of violations that have occurred. For example, for one collection procedure, the patient is asked to provide several days of fasting sampling, the last three of which are used by the algorithm to make the recommended dose change. If the patient fails to provide the last three (critical) samples, in such an example, the device will not make a recommendation, but will automatically extend the collection procedure by missing a week. In such an example, the estimation will be made in another week. In another example, if the collection procedure requires a clinician to mediate whenever a particular collection value exceeds a target value, the clinician computer 25 will run a predictive algorithm based on data updates automatically received from the device 24 regarding when the patient will exceed the target value. Based on such estimates/predictions, the clinician computer 25 may automatically identify the "best" next opportunity for clinician access. Additionally, the clinician computer 25 may automatically present a context-dependent question or discussion point for clinician access based on time, quality, or cost measurements. For example, if the patient data shows that a basic titration is running slower than a population of similar individuals (e.g., deviating from a population-based trajectory) when visiting the physician at the clinic, and the patient is not given a high number of violations, the clinician computer 25 will advise the clinician 14 to discuss meal quantity, type, and timing with the patient. The clinician computer 25 may also suggest to the clinician 14 what means fasting? And advising clinicians to assess the effectiveness of the patient's sampling method.

Additional aspects that may be considered are: automatic adjustment of progress indicators out of predictions based on provided data; prompting encouragement in combination with a positive term seen by the system (you do very well in getting your fasting data!hold good work!) or a negative term seen by the system (you have missed multiple insulin injections, let us see if you can do better); training tips-if the user does not understand what they are doing, we can detect this and ask questions targeted to assess their training needs.

Results at the end of the structured collection procedure.

There are many different results that may be provided to the patient 12 at the end of the structured collection procedure 70. Examples are: displaying the analysis results, such as recommendations 260 (FIG. 6A); providing a list of numbers, e.g., violation counters and/or which adherence violations occurred for what events 237 during the structured collection procedure 70 613; provide a change in results (when compared to previous results), such as recommendations 260; providing status regarding the patient's long term health status by comparing the data in the data file 145 to known guidelines; providing a comparison of the long term health status of the patient relative to the population; providing a comparison of the current results or results of previous executions of the structured collection procedure 70 with other types of structured collection procedures; and provides a metric showing the number of successfully delivered messages divided by the total number of messages, e.g., expressed as a percentage. In other embodiments, other reports may include: cost accounting (less covered by insurance) is provided as an absolute (i.e., cost/benefit-based analysis) performance of the structured collection procedure experienced by the patient 12, as compared to others running the same structured collection procedure within the population of clinicians 14, or for a general population, such as a manufacturer-maintained data store.

In other embodiments, other reports may include: reporting the time it takes to run the structured collection procedure; comparing the time spent running the structured collection procedure 70 against others within a clinician population, or against a general population (such as a manufacturer-maintained data store); identifying why the structured collection procedure took the time it took to go (in case the structured collection procedure took longer than preferred), e.g. a list of compliance violations (number and type); providing pre-defined questions to establish rationality (ratio) for delays to help interpret results, if not optimal, to train the patient 12 by triggering a recall to invoke a training opportunity; and/or initiate a coach based session between the clinician 14 and the patient 12.

It will be appreciated that the manner in which the results are communicated may also depend on the analysis. For simpler structured collection procedures, the results may be displayed directly on the device 24. However, for complex analysis routines, there are several options: the data file 145 is downloaded to the clinician computer 25 and the analysis is done on the clinician computer 25, where the results are discussed by person and stored in an electronic medical record of the patient 12; the analysis is done using the patient computer 18 including the analysis software; or the analysis is processed and then made available via a secure web server. For analysis purposes, portions on the data file 145 may also be made available to the developer, for example, to determine the percentage of completion/withdrawal at various stages of the structured collection procedure 70, to help identify possible completion strategies for patients and providers and to identify locations for future improvements.

Although not limited thereto, various status reporting embodiments of the present invention provide the following advantages. Various ones of the status reporting embodiments ensure that the patient 12 has an opinion as to his/her status during the performance of the collection procedure. Providing this information may result in increased adherence and compliance to the structured collection procedure 70 (i.e., facilitating progress reporting and helping to ensure that minimum collection requirements are met). Various ones of the status reporting embodiments ensure that the patient 12 knows how to address situations where his or her bG values are heavily uncontrolled, e.g., a status report may be provided on the device 24 that alerts the patient 12 in the event of a severe hypoglycemic event. Other such exception handling type reports may also be provided. In other embodiments, the customized form of the status report also ensures that the clinician 14 readily knows relevant information about the patient's glycemic state during and at the end of the structured collection procedure 70. Various ones of the status reporting embodiments also allow the structured collection procedure 70 to report comparisons with previous executions of the same structured collection procedure 70.

Although not limited thereto, the various status reporting embodiments of the present invention provide the following additional advantages. Various ones of the status reporting embodiments may be used as a means of encouraging more focused and positive conversation between the clinician 14 and the patient 12 regarding the disease state of the patient 12. Various ones of the status reporting embodiments may help ensure that the initial experience of using the collection procedure 70 (e.g., disease status determination) is a positive one, and thus increase the chances that the patient will again perform the same and/or other such structured collection procedures on the device 24.

Thus, by the foregoing disclosed embodiments, various systems and methods are disclosed for managing the execution of collection procedures, data collection, data analysis, and status reporting while running on a meter. Those skilled in the art will appreciate that the teachings can be practiced with embodiments other than those disclosed. The disclosed embodiments are presented for purposes of illustration and not limitation, and the present invention is limited only by the claims that follow.

Claims

1. A collection device to address medical issues and improve adherence to structured collection protocols, the device comprising:

a display;

a memory;

a processor connected to the memory and display; and

program instructions that, when executed by the processor, cause the processor to:

initiating a schedule of events for the structured collection procedure when one or more entry criteria are met,

collecting patient data for the structured collection procedure when entered in response to a request according to an event provided in an event schedule after startup,

automatically storing the collected patient data in a memory,

automatically evaluating whether the patient data collected in response to the request meets one or more adherence and/or acceptance criteria, wherein the one or more adherence and/or acceptance criteria are criteria different from the entry criteria, wherein the one or more adherence and/or acceptance criteria comprise a defined range of values, and if the patient data does not fall within the range, the processor is configured to give a prompt for additional patient data, and if the evaluation provided by the processor is such that the step resulting in the patient data being taken is not completed, automatically extending the events in the schedule of events,

If the one or more adherence and/or acceptance criteria are met automatically associating the stored collected patient data with the unique identifier in memory,

automatically providing a status report when the one or more adherence and/or acceptance criteria are not met during the structured collection procedure, an

Automatically ending the structured collection procedure when one or more exit criteria are met, wherein an exit criteria establishes requirements that need to be met to exit or complete the structured collection procedure such that sufficient contextual data is collected to answer a medical question addressed by the structured collection procedure, and wherein scheduling of events of the structured collection procedure continues to a next event in which additional patient data is collected until the requirements of an exit criteria are met,

wherein the program instructions, when executed by the processor, further cause the processor to: checking whether patient data collected in response to the request that does not meet the one or more adherence and/or acceptance criteria results in an adherence violation, counting a number of adherence violations, and automatically ending the structured collection procedure when the number of adherence violations exceeds an acceptable number of adherence violations for a particular type of violation, wherein the type of violation is indicated by a processor configured to provide a type code that results in a violation, and the processor is configured to provide the following type code: a measurement taken before the window, a measurement taken after the window, a measurement skipped, an incorrect quantity of medication taken, a medication not taken, and a medication taken at the wrong time, and wherein the processor sets a number of adherence violations for each type code to automatically end the procedure for solving the medical problem and improving adherence to the structured collection procedure.

2. The collection device of claim 1, further comprising a communication interface, and wherein the program instructions, when executed by the processor, further cause the processor to: sending a message to a clinician via the communication interface if the adherence and/or acceptance criteria are not met.

3. The collection device of claim 1, wherein when the one or more adherence and/or acceptance criteria are not met during the structured collection procedure, the program instructions further cause the processor to present a question and an answer on a display to determine why the adherence and/or acceptance criteria are not met.

4. The collection device of claim 1, wherein the program instructions, when executed by the processor, further cause the processor to display a message on the display contacting a clinician if the adherence criteria is met rather than an acceptance criteria.

5. The collection device of claim 1, wherein when one or more adherence criteria are not met during the structured collection procedure, the program instructions further cause the processor to give a prediction on a display of what may happen if the patient continues to not meet the one or more adherence criteria.

6. The collection device of claim 1, wherein the processor provides a status indicator on a display showing progress in completing the structured collection procedure.

7. The collection device of claim 6, wherein the progression of the status indicator is based in part on a number of unique identifiers associated with the stored collected patient data.

8. The collection device of claim 6, wherein the progress of the status indicator is based in part on a number of unique identifiers associated with the stored collected patient data and a total number of requests in the schedule of events that need to satisfy the one or more adherence criteria such that the one or more exit criteria are satisfied at some unknown time.

9. The collection device according to claim 6, wherein the progress of the status indicator is based on the number of unique identifiers associated with the stored collected patient data divided by the total number of requests in the schedule of events that need to meet the one or more adherence criteria such that the one or more exit criteria are met at some unknown time and provided as a score or as a percentage on the display.

10. The collection device of claim 6, wherein the status indicator represents one of a gas gauge and a progress bar.

11. The collection device of claim 1, wherein the program instructions, when executed by the processor, further cause the processor to provide a failure message on a display.

12. The collection device of claim 1, wherein the program instructions, when executed by the processor, further cause the processor to provide a classification message indicating a risk of not completing the structured collection procedure if the number of adherence violations has not exceeded an acceptable number of adherence violations.

13. The collection device of claim 1, wherein the program instructions, when executed by the processor, further cause the processor to provide a help message on the display if the number of adherence violations has not exceeded an acceptable number of adherence violations, and provide a help message for the event if the specification has been completed in the structured collection procedure.

14. The collection device of claim 1, wherein the program instructions, when executed by the processor, further cause the processor to provide on the display a query message specified in the structured collection procedure if the number of adherence violations has not exceeded an acceptable number of adherence violations, and provide a query message for the event if the specification has been completed in the structured collection procedure.

15. A collection device according to claim 14 wherein the program instructions, when executed by the processor, further cause the processor to provide help information specified in the structured collection procedure on a display if the answer to the inquiry message received by the processor is a request for help information.

16. The collection device of claim 15, wherein the program instructions, when executed by the processor, further cause the processor to provide a second query message specified in the structured collection procedure on the display after providing the help information.

17. The collection device of claim 16, wherein the program instructions, when executed by the processor, further cause the processor to send a message to a clinician if the reply to the second query message received by the processor is to send the message to the clinician.

18. The collection device of claim 1, wherein the program instructions, when executed by the processor, further cause the processor to check whether the collected patient data in memory deviates from expected behavior.

19. The collection device of claim 18, wherein the program instructions, when executed by the processor, further cause the processor to provide a contact message specified in the structured collection procedure on the display if the collected patient data in memory deviates from an expected behavior.

20. The collection device of claim 1, wherein the program instructions, when executed by the processor, further cause the processor to provide start information on a display before the one or more entry criteria are met at an unknown time, wherein the start information provides at least a purpose of the structured collection procedure and conditions required to meet the one or more entry criteria.

21. The collection device of claim 1, wherein the program instructions, when executed by the processor, further cause the processor to provide a selectable report on a display, the selectable report, when selected, displaying current status information of the structured collection procedure.

22. A collection device according to claim 21, wherein the current state information comprises one or more of the following pieces of information about the structured collection procedure: progress of completion, results of the collection procedure, number of violations, type of violations, events completed, events left to complete, cost-based analysis and comparison of previous executions of the structured collection procedure with current results or results of other types of structured collection procedures.

23. The collection device of claim 1, wherein a status report is provided by the processor if a violation is specified in the collection procedure by an optional violation parameter provided in the structured collection procedure for an event during the structured collection procedure in which the one or more adherence criteria are not satisfied.

24. A method of performing a structured collection procedure, comprising:

providing a collecting device according to claim 1; and

initiating the structured collection procedure on the collection device.

25. A method of managing a structured collection procedure, comprising:

providing a collection device having the structured collection procedure and program instructions, wherein the collection device addresses a medical problem and improves adherence to the structured collection procedure; and

executing the program instructions on the collection device causes a processor of the collection device to:

Automatically storing the collected patient data in a memory,

The method further comprises the following steps:

checking whether patient data collected in response to the request that does not meet the one or more adherence and/or acceptance criteria results in an adherence violation, counting a number of adherence violations, and automatically ending the structured collection procedure when the number of adherence violations exceeds an acceptable number of adherence violations for a particular type of violation, wherein the type of violation is indicated by a processor configured to provide a type code that results in a violation, and the processor is configured to provide the following type code: a measurement taken before the window, a measurement taken after the window, a measurement skipped, an incorrect quantity of medication taken, a medication not taken, and a medication taken at the wrong time, and wherein the processor sets a number of adherence violations for each type code to automatically end the procedure for solving the medical problem and improving adherence to the structured collection procedure.