HK1193965A - User-defined structured testing for use in diabetes care - Google Patents

Description

User-defined structured testing for use in diabetes care

Technical Field

The present disclosure relates to structured testing methods for diagnosis and treatment support of patients with chronic diseases such as diabetes.

Background

For people with diabetes, successful management requires monitoring the impact that lifestyle changes can have over both short and long periods of time. Regular testing of their blood glucose levels can be an important part of diabetes management as a way to track changes throughout the day. For example, portable handheld medical diagnostic devices are commonly used to measure the concentration of biologically important components of body fluids, such as, for example, the concentration of glucose in blood. To test glucose with a glucose meter, a small sample of blood may be placed on a disposable test strip. The portable handheld glucose meter may include a strip port (strip port) that receives a disposable test strip. The test strip may be coated with a chemical that binds to glucose in the blood (glucose oxidase, dehydrogenase, or hexokinase), which allows it to measure the glucose concentration in the blood sample. The portable handheld glucose meter then displays the glucose concentration as a number (or glucose measurement). As a result, the portable handheld medical diagnostic device and its accessories can work together to measure the amount of glucose in the blood and be used to monitor glucose levels in an individual's home, healthcare facility or other location, for example, by a person with diabetes or by a healthcare professional.

Patients and healthcare professionals can thus track and analyze glucose measurements over a period of time to assess changes in the patient during the course of a day, week, or other desired time period. For example, some health care professionals may instruct patients to obtain glucose measurements seven or more times per day during the course of consecutive days so that patients can observe changes in the progress of their measurements. However, the importance of changing lifestyle factors (such as meal size or physical activity) may not be understood by the patient. Thus, it may be desirable to provide methods and apparatus that enable a patient to better understand which factors may affect glucose measurements. This section provides background information related to the present disclosure, which is not necessarily prior art.

Disclosure of Invention

In one aspect of the present disclosure, a method for measuring glucose levels is provided that enables a patient to better understand which factors may affect blood glucose measurements. The method comprises the following steps: receiving a target for a structured test from a patient; selecting a test template corresponding to the target from a plurality of predefined test templates; presenting to the patient a plurality of contextual criteria (contextual criteria) associated with the selected test template; receiving a selection of one or more contextual criteria made from a plurality of contextual criteria; constructing a structured test comprising the selected contextual criterion; and administering a structured test to the patient, wherein the structured test comprises prompting the patient to enter a blood sample into a glucose meter.

In another aspect of the present disclosure, a method for constructing a structured test with a user-defined adherence criterion (adherence criterion) is provided. The method comprises the following steps: presenting a plurality of contextual criteria for the structured test to the patient; receiving a selection of one or more contextual criteria made from a plurality of contextual criteria; and constructing a structured test comprising contextual criteria selected by the patient. Each contextual criterion selected by the patient is evaluated during the implementation of the structured test. Sample data acquired during the structured test is reported as compliant (compliant) when each contextual criterion selected by the patient is satisfied during the implementation of the structured test, and is marked as non-compliant when at least one contextual criterion is not satisfied during the implementation of the structured test.

In yet another aspect of the present disclosure, a method for constructing structured tests is extended to tests in paired-type tests. The method comprises the following steps: prompting the patient to enter a blood sample into the glucose meter before and after a given event within a time window that encapsulates the given event; determining a blood glucose measurement from the blood sample input to the glucose meter; presenting to the patient a query for contextual data about another event occurring outside the time window; receiving a response to the query from the patient; and associating the reply with a blood glucose measurement.

The method may include presenting a plurality of goals for conducting the structured test to the patient such that each goal is associated with one of a plurality of test templates. The method may include presenting to the patient a set of contextual criteria for the selected test template such that the contextual criteria associated with the given test template is different from the contextual criteria associated with another test template among the plurality of predefined test templates. Implementing the structured test further may include presenting a query for each contextual criterion to the patient, receiving a reply to the query from the patient, and associating the reply with data collected during the structured test. Performing the structured test on the patient may further include prompting the patient to enter a blood sample into the glucose meter and presenting a query to the patient for contextual data about another event different from the given event before and after the given event within a time window that encapsulates the given event. The method may comprise presenting to the patient a query for contextual data relating to another event occurring outside the time window. The method may include prompting the patient to enter a blood sample into the glucose meter at a time that occurs outside of the time window. The method may include defining adherence criteria for the structured test and reporting data collected during the structured test when the adherence criteria for the structured test are satisfied. The method may include defining an adherence criterion based on the selected contextual criterion.

The method may comprise reporting sample data acquired during the structured test as compliant when given contextual criteria selected by the patient are met during the implementation of the structured test.

The method may include presenting to the patient a plurality of contextual criteria relating to a structured test conducted on the patient; receiving a selection of one or more contextual criteria by the patient from a plurality of contextual criteria; and presenting the patient with a query for each contextual criterion. The method may further include constructing a structured test that includes contextual criteria selected by the patient, conducting the structured test on the patient, evaluating whether given contextual criteria selected by the patient have been met during the conducting of the structured test, and marking sample data acquired during the structured test as non-compliant when the given contextual criteria are not met during the conducting of the structured test.

The method may include analyzing sample instances taken during a series of structured tests and presenting results from the analysis to a patient. The method may include prompting the patient to classify a sample instance for the given structural test and ignoring the sample instance for the given structural test in subsequent analyses when the sample instance is classified as atypical by the patient. The method may include presenting a query for at least one contextual criterion to a patient during implementation of a given structural test, receiving a response to the query from the patient, prompting the patient to classify a sample instance for the given structural test, and ignoring the sample instance for the given structural test in subsequent analysis when the sample instance is classified as atypical by the patient. The method may further comprise instructing the patient through a first series of structured tests constructed using contextual criteria selected by the patient; the method includes deriving a baseline blood glucose measurement from sample instances acquired during a first series of structured tests, prompting the patient to change variables associated with the first series of structured tests, instructing the patient through a second series of structured tests, wherein the second series of structured tests have different variable values than the first series of structured tests but are otherwise constructed using contextual criteria selected by the patient, and deriving the changed blood glucose measurement from sample instances acquired during the second series of structured tests. The method may include presenting results from the first and second series of structured tests to the patient, the results including a comparison of the baseline blood glucose measurement and the altered blood glucose measurement. The method may include analyzing sample instances taken during the first and second series of structured tests and presenting results from the analysis to the patient.

The diabetes management device may include a blood glucose measurement module that selectively measures blood glucose in a blood sample. The test configuration module may present a plurality of targets for structured testing to a user such that each target is associated with one of a plurality of predefined test templates. The test configuration module may present the user with a set of contextual criteria for the selected test template such that the contextual criteria associated with the given test template is different from the contextual criteria associated with another test template among the plurality of predefined test templates. The test enforcement module may present a query to the user for each contextual criterion, may receive a reply to the query from the user, and may associate the reply with data collected during the structured test. The test implementation module may evaluate whether given contextual criteria selected by the patient have been met during implementation of the structured test, and may report the sample data acquired during the structured test as compliant when the given contextual criteria selected by the patient are met during implementation of the structured test. When the given contextual criterion is not satisfied during the implementation of the structured test, the test implementation module may mark sample data acquired during the structured test as non-compliant.

This section provides a general summary of the disclosure, and is not a comprehensive disclosure of its full scope or all of its features. Further areas of applicability will become apparent from the description provided herein. The description and specific examples in this summary are intended for purposes of illustration only and are not intended to limit the scope of the present disclosure.

Drawings

FIG. 1 is a diagram depicting a patient and a treating clinician;

FIG. 2 is a diagram illustrating a patient with a Continuous Glucose Monitor (CGM), a portable durable insulin infusion pump, a portable non-durable insulin infusion pump, and a diabetes manager;

FIG. 3 is a diagram illustrating an exemplary diabetes management system used by patients and clinicians to manage diabetes;

FIG. 4 is a functional block diagram of an exemplary diabetes manager;

FIGS. 5A, 5B are flow charts illustrating exemplary methods by which a patient can construct a structured test;

FIG. 6 is a flow chart depicting a method for implementing structured testing; and

FIG. 7 is a diagram depicting an exemplary use case for reporting test results.

The drawings described herein are for illustrative purposes only of selected embodiments and not all possible implementations, and are not intended to limit the scope of the present disclosure. Corresponding reference characters indicate corresponding parts throughout the several views of the drawings.

Detailed Description

Referring to fig. 1, a person 100 with diabetes and a healthcare professional 102 are shown in a clinical environment. People with diabetes include people with metabolic syndrome, pre-diabetes, type 1 diabetes, type 2 diabetes, and gestational diabetes, and are collectively referred to as patients. Healthcare providers for diabetes are diverse and include nurses, nurse practitioners, physicians, and endocrinologists, and are commonly referred to as clinicians. Although the present disclosure makes reference to diabetes care, it should be readily understood that concepts related to structured testing disclosed herein can be applied to other types of chronic diseases. Likewise, the present disclosure makes reference to blood glucose measurements, while the concepts may be extended to other types of patient biomarkers including, but not limited to, interstitial glucose values, HbA1c values, heart rate measurements, blood pressure measurements, lipids, triglycerides, cholesterol, and the like.

During a healthcare consultation, the patient 100 typically shares a variety of patient data with the clinician 102, including blood glucose measurements, continuous glucose monitoring data, amounts of insulin infused, amounts of food and beverages consumed, exercise schedules, and other lifestyle information. Clinician 102 may obtain additional patient data including measurements of HbA1C, cholesterol levels, triglycerides, blood pressure, and body weight of patient 100. The patient data may be recorded manually or electronically on the handheld diabetes management device 104, diabetes analysis software running on a Personal Computer (PC) 106, and/or a web-based diabetes analysis site (not shown). The clinician 102 may analyze the patient data manually or electronically using diabetes analysis software and/or a web-based diabetes analysis site. After analyzing the patient data and checking the patient 100 for compliance with the previously prescribed therapy, the clinician 102 may decide whether to modify the therapy for the patient 100.

Referring to fig. 2, the patient 100 may use a Continuous Glucose Monitor (CGM) 200, a portable non-durable insulin infusion pump 202 or a portable durable insulin infusion pump 204 (hereinafter insulin pump 202 or 204), and a handheld diabetes management device 104 (hereinafter diabetes manager 104). The CGM 200 uses a subcutaneous sensor to sense and monitor the amount of glucose in the blood of the patient 100 and transmits a corresponding reading to the diabetes manager 104.

The diabetes manager 104 performs various tasks including measuring and recording blood glucose levels, determining the amount of insulin to be administered to the patient 100 via the insulin pump 202 or 204, receiving patient data via a user interface, archiving patient data, and the like. The diabetes manager 104 periodically receives a reading from the CGM 200 indicative of the insulin level in the blood of the patient 100. The diabetes manager 104 transmits instructions to the insulin pump 202 or 204, and the insulin pump 202 or 204 delivers insulin to the patient 100. Insulin may be delivered in a scheduled manner in the form of a basal dose, which maintains a predetermined insulin level in the blood of the patient 100. Additionally, insulin may be delivered in a single dose, which increases the amount of insulin in the blood of the patient 100 by a predetermined amount.

Referring to fig. 3, the diabetes management system 300 used by the patient 100 and the clinician 102 includes one or more of the following devices: a diabetes manager 104, a Continuous Glucose Monitor (CGM) 200, an insulin pump 202 or 204, a mobile device 302, a PC 106 with diabetes analysis software, and other healthcare devices 304. The diabetes manager 104 is configured as a system hub and communicates with the devices of the diabetes management system 300. Alternatively, the insulin pump 204 or the mobile device 302 may act as a system hub. Communication between devices in the diabetes management system 300 can be performed using a wireless interface (e.g., bluetooth) and/or a wired interface (e.g., USB). The communication protocols used by these devices may include protocols conforming to the IEEE 11073 standard as extended using the Guidelines provided by Continua Health Alliance Design Guidelines. In addition, the patient 100 and clinician 102 may exchange information using a Health record system (such as Microsoft ® Health valve and Google @) systems.

The diabetes manager 104 can receive blood glucose readings from one or more sources (e.g., from the CGM 200). The CGM 200 continuously measures the blood glucose level of the patient 100. The CGM 200 periodically communicates the blood glucose level to the diabetes manager 104. The diabetes manager 104 and the CGM 200 communicate wirelessly, for example, using a proprietary Gazell wireless protocol developed by Nordic Semiconductor, Inc.

Additionally, the diabetes manager 104 includes a Blood Glucose Meter (BGM) and a port (not shown) in communication with the BGM. The port may receive a blood glucose measurement strip 306. The patient 100 places a blood sample or other bodily fluid on the blood glucose measurement strip 306. BGM analyzes a sample and measures blood glucose levels in the sample. The blood glucose level measured from the sample and/or the blood glucose level read by the CGM 200 may be used to determine the amount of insulin to be administered to the patient 100. To create repeatable objective credentials that can be used to make medical assessments or optimizations, the diabetes manager 104 can perform one or more structured testing or collection processes, as described further below.

The diabetes manager 104 communicates with the insulin pump 202 or 204. The insulin pump 202 or 204 can be configured to receive instructions from the diabetes manager 104 to deliver a predetermined amount of insulin to the patient 100. Additionally, the insulin pump 202 or 204 may receive other information, including meal and/or exercise schedules of the patient 100. The insulin pump 202 or 204 can recommend the amount of insulin to be administered based on the additional information.

The insulin pump 202 or 204 can also transmit data to the diabetes manager 104. The data may include the amount of insulin delivered to the patient 100, the corresponding delivery time, and the pump status. The diabetes manager 104 and the insulin pump 202 or 204 can communicate using a wireless communication protocol, such as bluetooth. Other wireless or wired communication protocols may also be used.

Additionally, the diabetes manager 104 can communicate with other healthcare devices 304. For example, other healthcare devices 304 may include a sphygmomanometer, a weight scale, a pedometer, a fingertip pulse oximeter, a thermometer, and the like. The other healthcare device 304 acquires the personal health information of the patient 100 and transmits the personal health information of the patient 100 to the diabetes manager 104 via a wireless, USB, or other interface. The other healthcare devices 304 may use a communication protocol compliant with ISO/IEEE 11073. The diabetes manager 104 can communicate with other healthcare devices 304 using interfaces including bluetooth, USB, and the like. Further, the devices of the diabetes management system 300 can communicate with each other via the diabetes manager 104.

The diabetes manager 104 can communicate with the PC 106 using a Bluetooth, USB, or other interface. The diabetes management software running on the PC 106 includes an analyzer-configurator that stores configuration information for the devices of the diabetes management system 300. The configurator has a database for storing configuration information for the diabetes manager 104 and other devices. The configurator may communicate with the user through a computer screen in a standard web or non-web application. The configurator transmits the user-approved configuration to the devices of the diabetes management system 300. The analyzer obtains data from the diabetes manager 104, stores the data in a database, and outputs the analysis results through a computer screen in a standard web page or non-web based application. Accu-Chek 360^®The diabetes management system is an example of a commercially available diabetes management software product, although other products are also within the scope of the present disclosure.

The diabetes manager 104 can use bluetooth to communicate with the mobile device 302. The mobile device 302 may include a cellular telephone, pager, or Personal Digital Assistant (PDA). The diabetes manager 104 can send the message to an external network through the mobile device 302. The mobile device 302 can transmit the message to an external network upon receiving a request from the diabetes manager 104.

An exemplary diabetes manager 104 is further described with reference to fig. 4. The diabetes manager 104 includes a Blood Glucose Measurement (BGM) module 400, a communication module 402, a user interface module 404, a user interface 406, a processing module 408, a memory 410, and a power module 412. The user interface module 404 and the processing module 408 may be implemented by an application processing module 409. The BGM module 400 includes a blood glucose measurement engine that analyzes samples provided by the patient 100 on the blood glucose measurement strip 306 and measures the amount of blood glucose in the samples. The communication module 402 includes a plurality of radios that communicate with different devices of the diabetes management system 300. The user interface module 404 interfaces the diabetes manager 104 to various user interfaces 406 that the patient 100 can use to interact with the diabetes manager 104. For example, the user interface 406 may include keys, switches, a display, a speaker, a microphone, a Secure Digital (SD) card port, a USB port, etc. (not shown).

The processing module 408 processes data received from the BGM module 400, the communication module 402, and the user interface module 404. The processing module 408 uses memory 410 to process and store data. The memory 410 may include volatile and non-volatile memory. The processing module 408 outputs data to the user interface 406 and receives data from the user interface 406 via the user interface module 404. The processing module 408 outputs data to and receives data from the devices of the diabetes management system 300 via the communication module 402. The power module 412 supplies power to the components of the diabetes manager 104. The power module 412 includes a rechargeable battery. The battery may be recharged using an adapter that plugs into a wall outlet. The battery may also be charged via the USB port of the diabetes manager 104.

For purposes of this disclosure, the diabetes manager 104 acts as a collection device. However, the collection device may be any portable electronic device capable of providing an acquisition mechanism for determining and storing physiological measurements of a person. For example, self-monitoring blood glucose meters and continuous glucose monitor devices are examples of collection devices used to measure blood glucose in diabetes care. In these examples, a diabetes manager (which may reside, for example, in a cellular telephone) cooperates with a physically separate collection device to implement the structured tests and record data associated with the tests being implemented. That is, the diabetes manager can prompt the person to enter a blood sample into the glucose meter or otherwise interact with the person according to the structured test; however, glucose meters analyze a blood sample and store glucose measurements from the blood sample. The glucose measurements may then be transmitted to the diabetes manager for further processing.

Fig. 5A and 5B depict an exemplary method by which a patient can construct a structured test that enables the patient to better understand factors that may affect blood glucose measurements. In an exemplary embodiment, the method for constructing and implementing structured tests is implemented in software executed by a processor of the diabetes manager 104. It is contemplated that the structured test may be constructed by the patient (or physician) on another device (e.g., a desktop PC) and then downloaded for execution by the diabetes manager 104.

Referring to fig. 5A, a patient may begin by selecting a particular type of blood glucose measurement of interest to the patient. For example, a patient may be interested in what factors affect fasting blood glucose measurements, pre-meal glucose measurements, or post-meal glucose measurements. In another example, a patient may be interested in factors affecting a series of paired glucose tests used to help understand specific issues related to behavior or treatment. Each paired glucose test involves taking paired bG measurements before and after a particular event. For example, an individual may obtain a bG value before a particular meal (e.g., before lunch) and another bG value within a specified time after lunch. The "before" and "after" bG values form related "pairs" of bG values and are commonly referred to as "paired test" (TIP) tests. Other types of measurements are also contemplated by the present disclosure.

In an exemplary embodiment, a plurality of different measurement types are stored in the diabetes manager and presented (at 51) on a display for selection by the patient. The patient then selects a particular type of measurement to be captured (at 52) by the diabetes manager. For example, the patient may select a morning fasting measurement. For this type of measurement, the patient is not able to eat for a period of time before a blood glucose measurement is taken. However, the patient may not understand what factors affect the measurement. Thus, the patient is presented (at 56) with a suggested test template for that particular type of measurement.

Each type of measurement is mapped to a proposed test template. In operation, the diabetes manager obtains a suggested test template corresponding to the measurement selection. The proposed test template consists of a series of events to be performed by the patient, including prompting the patient to provide a blood sample to a glucose meter. The proposed test template will further comprise contextual criteria that may affect the measurements. A suggested test template for morning fasting measurement may include the following events:

test template for morning fasting:

prompting patients to make baseline bG measurements prior to a meal

Prompting a patient to enter information regarding meals

Prompting patients to take insulin at night

Confirming the amount of insulin administered to the patient

Prompting a patient to enter information regarding an exercise

Prompting the patient to input the amount of sleep

Confirm that the patient is empty

Prompting a patient to perform a morning bG measurement

By presenting the patient with a list of events, the patient begins to know what factors may affect a particular measurement. To construct the structured test, the patient can select which events are applicable to the patient. In a simplified embodiment, the selected event is directly related to the contextual criteria used to construct the test. Some events may be required for each sample instance (e.g., confirming the amount of insulin taken or confirming fasting); however, other events may be optional (e.g., information about overnight meals or exercise).

In addition, the patient is presented with a prioritized list of contextual criteria. When constructing the structured test, the patient can select which contextual criteria (or contextual inputs) are applicable to the patient. For example, a patient who normally enjoys a night snack may choose to study the effect of their night snack on morning fasting values. The system may then present the user with a prioritized list of contextual criteria, including the amount of their insulin delivery, whether they are drinking alcohol, the amount of their meals served, etc. The user may then select from the list the contextual criteria they wish to evaluate and deselect from the list those they do not wish. Collectively or individually, the contextual criteria may be considered "variables under test". In other examples, the patient may select contextual criteria that pertain to exercise (such as the duration of the exercise) rather than to a meal, or to both a meal and exercise. The contextual criteria selected by the patient are captured (at 57) by the diabetes manager and then used to construct (at 58) a structured test for the patient in a manner described further below. It is readily understood that different types of measurements may be associated with different test templates and that different test templates may be composed of different event and/or contextual criteria. In other words, the selection of contextual criteria presented to the user may be a subset of contextual criteria filtered or pre-selected from a large set of criteria based on the type of measurement.

In another example, the patient may select a TIP test for a given event, such as morning exercise regimen. For this type of measurement, the patient is requested to take blood glucose measurements before and after a given event. Depending on the selected event type, a suggested test template for the selected event type is presented to the patient. For TIP tests associated with morning exercise regimens, suggested test templates may include the following events:

test templates for morning exercise regimen:

prompting a patient to enter information regarding nighttime meals

Confirming the amount of insulin a patient takes before going to bed

Prompting the patient to input the amount of sleep

Prompting the patient to enter information regarding breakfast

Confirming the amount of insulin a patient takes after breakfast

Prompting a patient to perform a bG measurement prior to exercising

Prompting a patient to perform a bG measurement after exercise

Prompting a patient to enter information regarding the type of exercise and the amount of exercise

Patients typically need to take bG measurements of the TIP test within a time window that encapsulates a given event (e.g., within one hour before and after exercise). To construct the structured test, the patient selects contextual criteria that can be applied to the patient. It should be noted that some contextual criteria may relate to different events that can occur outside of the window in which the bG measurement is taken (such as sleep or breakfast).

Alternatively, it may be more intuitive for the patient to begin by selecting a target for the structured test, as shown in fig. 5B. For example, a patient may desire to understand the effect of eating a snack or exercise on a particular measurement. In one embodiment, a plurality of different test goals may be presented (at 53) to the patient. The patient may then select a goal from a list of different test goals, which is captured by the diabetes manager (at 54). The patient may also specify a particular measurement type. The diabetes manager determines a suggested test template, as indicated at 55, taking into account the test objectives and/or measurement types entered by the patient. In an exemplary embodiment, each combination of test objectives and measurement types is mapped to a suggested test template stored on the diabetes manager.

Two examples further illustrate how selected test targets can be correlated to a proposed test template. In a first example, a patient may desire to understand the effect of consuming a night snack on a morning fasting measurement. To understand the impact of a meal, each sample instance of a proposed test template may include the following events:

test template A

Prompting patients to make baseline bG measurements prior to a meal

Prompting a patient to enter information regarding meals

Prompting the patient to take night insulin

Confirming the amount of insulin administered to the patient

Prompting the patient to input the amount of sleep

Confirm that the patient is empty

Prompting a patient to perform a morning bG measurement

The prioritized list of contextual criteria relating to the snack may further be presented to the patient in view of the test goals, as described above.

In a second example, the patient may desire to understand the effect of exercise on morning fasting measurements. In this case, the test targets are associated with different test templates. Each sample instance of the proposed test template may include the following events:

test template B

Prompting patients to make baseline bG measurements prior to exercise

Prompting a patient to enter information regarding an exercise

Prompting the patient to take night insulin

Confirming the amount of insulin administered to the patient

Prompting the patient to input the amount of sleep

Confirm that the patient is empty

Prompting a patient to perform a morning bG measurement

In this manner, the proposed test template is related to the test object selected by the patient. Likewise, the patient may be presented with a prioritized list of contextual criteria relating to the exercise. When constructing the structured test, the patient may select which of the contextual criteria and/or events associated with the suggested test template are applicable to the patient. Contextual criteria selected by the patient are received (at 57) and then used to construct 58 a structured test for the patient, as described further below. It is contemplated that the selection of contextual criteria presented to the user may be a filtered or pre-selected subset of contextual criteria from a large set of criteria that take into account the identified goals.

In view of the set of contextual criteria selected by the patient, the system may further prompt the patient to enter additional information related to the contextual criteria. For example, if the patient selects contextual criteria for eating an additional meal, the system may prompt the patient to enter a time or time window in which the patient consumes the additional meal. The specified time is then used to schedule the appropriate reminder for the patient. For example, if the patient indicates between 8pm and 9pm where their nighttime meals are commonly taken, the system may prompt the patient to enter information about the meal at 9:15 pm. In another example, the patient may indicate their time to dinner overnight while they sleep at 11 pm. In this case, the system may prompt the patient to enter information regarding the meal just prior to 11 pm. If the patient fails to provide the requested information, the system may prompt the patient to enter information at a later time (e.g., prior to or at the time of the bG measurement the next morning). It is readily understood that this scheduling method may be extended to other types of contextual criteria. Alternatively, the patient may choose a less intuitive method whereby context information is collected from the patient at the time of the bG measurement. In any case, the system enables the patient to configure when and how to prompt the patient to enter contextual information related to the bG measurement.

The structured test is constructed from a proposed test template that includes various contextual criteria and associated information specified by the patient. First, the structured test may include various mandatory events as specified by the proposed test. Continuing with the morning fasting measurement described above, the structured test for morning fasting may include a query prompting the patient to take nighttime insulin, a query confirming the amount of insulin the user is taking, a query confirming that the patient has fasted, and a query prompting the patient to take a morning bG measurement. Each of these events may have an associated schedule.

In a simplified embodiment, the structured test may further include selectable events selected by the patient. Each event may be associated with a predefined list of contextual criteria. Each criterion then corresponds to or is translated into one or more queries presented to the patient for the purpose of collecting contextual data associated with the bG measurement. In another embodiment, the prioritized list of contextual criteria is presented to the patient. Each contextual criterion selected by the patient from the list is then translated into one or more queries that are presented to the patient. In either embodiment, the corresponding query becomes an event in the structured test. The replies to the queries are captured by the system and stored with the corresponding bG measurements. Each event and/or criterion may have a default arrangement for the associated query.

Continuing with the morning fasting measurement, the patient may have selected an event related to nighttime meals and not to exercise. In this case, the structured test may include one or more queries of the patient about his nighttime snack (e.g., what type of food was consumed, what food serving was, how much carbohydrates were consumed, etc.). Further, the queries may have an associated default schedule (e.g., immediately prior to prompting the patient for a morning bG measurement). In view of this exemplary scenario, a user-specified structural test may be defined as follows:

morning fasting structure test

Event scheduling

Prompting the patient to take insulin at night for 3 months and 6 days at 10:00pm

Inquiry of insulin amount for 3 months and 6 days 10:00pm

Confirmation of fasting at 3 months, 7 days, 8:00am

Prompting the patient to perform a bG measurement for 3 months, 7 days, 8:00am

Ask patient about 3 months and 7 days 8:00am with food at night

In this scenario, the patient specifies that the morning fasting measurement occurs on day 3/7. In the case of selecting an event for eating a night snack, the patient may have further indicated their night snack and/or time to sleep so that the event is scheduled accordingly. It is contemplated that the timing of the events that make up the structured test may also be configured directly by the patient or automatically scheduled by the system based on information previously known from the patient. The user-defined structured tests are stored by the diabetes manager for subsequent execution by the patient. Once a test has been defined by the patient, it can be selected and rerun multiple times at the request of the patient.

In a more robust embodiment, the contextual criteria selected by the patient serve as adherence criteria for the structured test. The adherence criteria describe the conditions under which the structured test is performed on the patient. For morning fasting measurements, an exemplary adherence criterion is whether the patient has fasted for at least 8 hours before the bG measurement. Prior to making the bG measurement, the system can prompt the patient to confirm that they are fasting. In the case of a positive response from the patient, the adherence criterion is satisfied. Confirming fasting may be a desired criterion for morning fasting measurement. When constructing the structured test, the patient may have also selected contextual criteria from the suggested test templates. Likewise, the system will query the patient for contextual information associated with the selected criteria. The selected criteria may serve as adherence criteria for the structured test. That is, sample data acquired under a given structured test will only be considered acceptable if all adherence criteria for the given structured test are met. In the context of a morning fasting measurement, the patient may have selected contextual criteria related to nighttime meals. Thus, sample data from a given sample instance of a user-defined structured test would be considered acceptable when a patient confirms fasting and provides information about their nighttime meals. If the patient fails to provide information about their nighttime meals, sample data from the sample instance is marked as unacceptable or discarded by the system.

Further, the value associated with the selected contextual criterion may also serve as a second layer adherence criterion. For example, confirming that insulin is being administered may be a first level of adherence criteria for a given test. The user may be prompted to enter a specific amount of insulin to be administered before or when the test is first administered. In response, the user may specify that 30 units of insulin be taken. In this example, the input value of 30 may serve as a secondary adherence criterion for the test. The user will be asked to confirm the amount of insulin taken or asked to enter the amount of insulin taken each time the test is continued to be conducted. If the user fails to confirm that 30 units of insulin were taken or an amount different from 30 was entered, then the sample data from the sample instance is marked as unacceptable because the secondary adherence criteria is not met due to a change in context between the two sample instances. Although both sample examples are valid, they should not be directly compared to each other without highlighting the difference. It is contemplated that the contextual criteria may be specified in advance by the system designer as adherence criteria for the structured test or by the patient as adherence criteria for the structured test while defining the structured test. It is also contemplated that other types of test criteria (such as entry criteria or exit criteria) may be associated with the structured test. Further details regarding different types of test criteria and how such criteria may be implemented may be found in U.S. patent publications 2010/0212675 and 2010/0218132, which are incorporated herein by reference.

FIG. 6 depicts an exemplary method for a diabetes manager to conduct a structured test on a patient. A plurality of different structured tests, including those constructed by the patient in the manner described above, may be stored in the diabetes manager. A list of available structured tests may be presented on the display for selection by the patient. With a given structured test selected, the patient may specify (at 61) a time for running the test. For example, a morning fasting measurement occurs in the tomorrow morning. Based on the specified time for the test, each event associated with the structured test is scheduled by the diabetes manager, at 62. During running the test, the event is then run according to the event schedule, at 63. For each event that is run, the diabetes manager collects and records data associated with the event. For the purpose of subsequent reporting, data collected during the structured testing is uniquely identified by the test and/or event.

After the test event has been run, adherence criteria for the structured test are evaluated, at 64. More particularly, each adherence criterion is evaluated by the diabetes manager. When all adherence criteria for the structured test are satisfied, the sample data (including the bG measurements) acquired under the structured test is deemed acceptable. In this case, the sample data is retained for subsequent analysis and reported to the patient or their health care provider. If one or more adherence criteria are not met, the sample data may be discarded or otherwise marked as not meeting the test requirements. In other instances, the testing process may be interrupted when the adherence criteria are not satisfied. For example, in the morning on an empty stomach, the patient may not be prompted to provide a blood sample if they do not empty for a sufficient amount of time. When the structured test consists of a single sample instance (i.e., one glucose test or one TIP test), then the structured test is complete. It is worth noting that once a structured test has been constructed by the patient, the test can be repeated without modification to its user-specified parameters. That is, the contextual criteria selected by the patient are advanced as the test is performed in the future. It should be understood that the diabetes manager may support patient modifications to a given structured test, such as adding or deleting contextual criteria. It should also be understood that only the relevant steps of the methodology are discussed with respect to fig. 6, but that other software implemented instructions may be required to control and manage the system run configuration test.

Structured tests have been presented so far as consisting of a single sample instance. Typically, a test template suggests or requires the acquisition of multiple sample instances over a period of time. For example, a test template may require sample instances over several days, weeks, or months to fully understand the effect of consuming an addicted meal on a morning fasting measurement. These sample instances are commonly referred to as sample sets. For these types of structured tests, adherence criteria defined for the sample instance is advanced to each sample in the test. Adherence criteria may also be defined for a sample set and/or for all tests.

Further, when defining a test, the user may specify a reoccurrence frequency of the test. For example, the user may specify that a given test occur daily, weekly, or at other reoccurring intervals. The user-defined contextual criteria will be pushed to each sample instance of such reoccurring tests. In this manner, multiple glucose measurements taken under similar circumstances can be acquired, analyzed, and reported to a user.

In another aspect of the disclosure, the patient may further specify the type of test. More particularly, the patient may be requested to classify the type of test at the time the test is constructed or conducted. Exemplary test types may include, but are not limited to, "typical," "atypical," or "delta" types of tests. Each of these types will be described further below.

Given the scenario in which patients attempt to better understand the effect of dining on their morning fasting measurements, the system enables patients to further classify and thereby compare sample data acquired in a given structured test or across similar structured tests. For example, assume that a patient typically consumes two spoons of ice cream each night. During execution of the sample instance, the patient is prompted to further classify the sample instance as typical or atypical. The sample data acquired during testing can then be marked accordingly. Given a sufficient number of sample instances, the system can provide the patient with information regarding the effect of such a typical snack on their morning fasting measurements (e.g., as compared to a baseline measurement where the patient does not eat a nighttime snack). In the event that the patient does not establish baseline measurements for morning fasting without eating a nighttime snack, sample data for a typical snack is stored until a sufficient number of sample instances have been obtained to establish baseline measurements. The system can then retrospectively analyze and report information about the effect of typical snacks on morning fasting measurements.

Patients may occasionally change their typical snack. The change may include, but is not limited to, the type of food, the amount of food, or the time at which the food is consumed. In this case, the patient may designate the sample instance as "atypical" when prompted to classify the sample instance. The patient may be further prompted to annotate or describe the type of change. The sample data acquired during the sample instance will be labeled accordingly. When analyzing and reporting information about the effect of a typical snack on morning fasting measurements, the system may ignore sample data that is marked as "atypical". Alternatively, sample data marked as "atypical" may be compared to other atypical instances of similar construction. If a sufficient number of sample instances are obtained for a particular change (e.g., ten instances when the patient eats pizza instead of ice cream or three spoons instead of two spoons of ice cream), the system may provide the patient with information regarding the effect of that particular atypical snack on their morning fasting measurements.

In the "delta" test, patients want to understand the effect of changes in their meals on their morning fasting measurements. Thus, the system may guide the patient through multiple sample instances taken in a first (or previous) context. After establishing the baseline measurements, the system may prompt the patient to change a variable in the test, such as his night snack. The system may then guide the patient through a series of additional sample instances taken in the changed (or subsequent) context. Based on the collected sample data, the system may provide information to the patient regarding the impact of the change on their blood glucose measurements.

Additional scenarios are set forth in which it is illustrated how these concepts are combined to provide a robust interface that enables patients to better understand factors that affect blood glucose testing. In a first scenario, a user wants to know the impact of eating a large number of snacks before going to sleep on their fasting. The user typically consumes a small amount of snack food. To do so, the user selects the test target (i.e., the variable under test) as the "morning fasting measure" in conjunction with the meal. The user may further specify the test type as a "delta" test type. To facilitate test setup, the system prompts the user for various inputs. For example, the system prompts the user for input when fasting should be measured. The system prompts the user to input when meal intake will occur, by default the previous night. The system may optionally prompt the user to enter the amount of carbohydrates (range) that a small meal will define and the amount of carbohydrates (range) that a large snack will define. The user then sets a start date for the test (default to immediate) and identifies when it should be run (e.g., weekday, weekend, continuous, on-demand).

At the specified meal time, the system alerts the user to consume a small amount of the snack. Since the system understands that this is a meal instance, the system requests the user to enter the amount of carbohydrates. If the user has not previously specified an expected range, the system uses the first value entered by the user to establish a possible range (e.g., set to the input value ± a fixed amount of carbohydrate). The system may prompt the user for their treatment (such as insulin or an oral hypoglycemic agent) and confirm the delivery. The next morning, the system asks the user if they have fasted since their night snack. In the event that a fasting is confirmed, the system prompts the user to provide a blood sample and thereby obtain a bG value. The system repeats this process at specified time intervals until the variability associated with the action is established. Once variability has been established, the system will request a new serving size and repeat the process until the variability associated with the new serving size is established. Upon completion, the system generates a report and outputs the report to the user. In this way, users are able to better understand the effect of their meal size on their blood glucose measurements.

In a second scenario, a type 1 diabetic user wants to know the effect of changing time on their acting insulin dose on fasting before meals. The user thinks that their measurements 2 hours after meal are too high. The user does not want the system to evaluate the change, but wants to evaluate the change by himself. Thus, the user defines tests to assess such scenarios. In this case, the user selects the test target as "pre-post meal mean" and selects the test type as "atypical" test. The system understands that the user is in insulin basal-bolus treatment. The system prompts the user to identify which variables they modify (such as bolus amount, bolus time, basal amount, meal size, pre-meal workout). The user may select the bolus time and the system requests the offset to be used by the user. This becomes a tracking method for future inspections. If the user utilizes a conventional TIP method, the data becomes useless after it is presented (i.e., the user does not attribute the type of test to any type and therefore is not valuable). In turn, the system presented in this disclosure will support comparison of historical checks and similar tests.

During testing, the system first prompts the user to obtain their bG measurements. The system then prompts the user to administer his insulin and confirms the amount of insulin. The system may prompt the user to enter a meal size and prompt the user to begin eating. After eating, the system prompts the user to obtain the next bG value. If the user wants to compare results from two different sample sets, the system allows the user to select two stored sample sets with the same test parameters for review and comparison.

In a related scenario, a user may want to assess the range of preprandial times for a drug administration, ranging from 20 minutes before a meal to 10 minutes after a meal in 5 minute increments. In this case, the user would specify the test type as "variable". The user sets the start date (by default immediate) and identifies when it should run (weekday, weekend, continuous, on-demand) and to which meal the test applies (breakfast, lunch, dinner, snack, all). The system then ranks the users from 0 to an extreme value.

FIG. 7 illustrates an exemplary use case for reporting test results. Report use cases are described in the context of TIP testing and do not extend to other types of structural testing. It should be noted that the contextual criterion is necessary for understanding the measurements and is performed by the system in the manner described above; however, an attribute is information that a user considers useful and is provided by the user's decision. It is readily understood that the system may be configured to support such reporting use cases.

Reports may be provided to compare events. For example, the system may provide or report a comparison of similar events. Events may be considered similar when one or more contextual criteria for the obtained sample instance are the same. Other methods for assessing the similarity of events or contexts under which sample instances are obtained are contemplated by the present disclosure. Reports of similar events may include highlighting similarities and/or differences in test context.

In other scenarios, the expected events are different. This occurs when the TIP instance reruns in an atypical mode. In this case, the system highlights the differences in context and shows the net effect (net effect) on the change in the resulting bG measurements. For example, users want to specifically assess the impact of eating breakfast on their pre-lunch bG. They usually skip breakfast. The user created a test in which they added the criteria for breakfast meal size to lunch. The system shows two lunch. The breakfast amount of one is 0 compared to the meal amount if 35 carbohydrates. These values, and the resulting bG values, are highlighted compared to other attributes/contexts established in other similar TIP instances.

In another example, the user regularly eats breakfast, each time with a slightly different carbohydrate consumption. The user has taken several TIP examples. The system shows different similar TIP instances and highlights different meal sizes and resulting bG values. Alternatively, the user regularly eats breakfast, each time with a slightly different carbohydrate consumption. The user has taken different amounts of basal insulin in several different TIP instances. The user wants to know the difference in the resulting bG measurements. The system shows the user similar tests and highlights the difference in basal insulin amount and meal amount for the resulting bG measurements.

Reports may be provided for event variability. In this case, the user wants to evaluate the variability on the bGs based on similar events performed. The user does this so they can know how much basic variability they have (or they regularly eat the same meal). In this case, the system would perform the meal size consumed (second level of adherence) and take multiple instances of TIP for the purpose of evaluating variability as a statistical measure. For example, a user regularly eats roast chicken at lunch time and wants to know the variability of their postprandial values. Every lunch, the system prompts the user to obtain a TIP value and implements a second level of compliance. In this case, the system does not report on the context, but rather on the variability, including the average bG measure, the range, and possibly other statistical measures (such as median, maximum, minimum, and standard deviation). Using this example, the user would be "self-introduced" into the meal pairing-the effect of breakfast on the output of lunch. When applied to similar events or sample sets, the reporting of variability may also be extended and applied to multiple sample sets. The sample groups are first rated for similarity and, if similar, further rated for variability between similar sample groups. Variability between sample sets may then be reported to the user.

Given the variability of a given sample set, the system can support additional functionality related to implementing the associated structured test. For example, when the variability is low (e.g., the standard deviation is less than a predefined threshold), the user may be permitted to modify the event and/or context criteria (e.g., change the amount of carbohydrates consumed in the meal) because any change in bG would be attributed to the modification rather than the variability in the sample group. When variability is high, the system may not allow the user to modify the event, as any changes may not be distinguishable from the sample instance and thus are not necessarily due to modification of the event. The system may further evaluate the amount of sample instances that make up the sample group and inform the user that more sample instances are needed to support accurate reporting. Other ways to reconfigure the protocol based on variability are also contemplated by the present disclosure.

Reports may also be provided for event changes. In this case, the user has regular events and intends to change the events. The user wants to know the impact of the change. For example, a user runs 4 miles regularly each day. The user wants to increase his miles to 5 miles per day and wants to know the effect on the bG measurement after running. For a particular evaluation, the user may compare only two TIP instances. However, if the user wants their rating to be more accurate, they can view the variability. In this example, the system compares a number of previous runs in 4 miles (retrospectively (as they exist), or globally, by asking the user to run a predetermined number of times in 4 miles). The system then prompts for an increase in the number of miles entered. The resulting report shows a statistical comparison of two different runs, including changes in mean/median, whether the changes are real (t-test or equivalent), etc. It will be readily appreciated that other reporting use cases may be developed and supported by the present system.

As used herein, the term "module" may refer to, be part of, or include the following: an Application Specific Integrated Circuit (ASIC); an electronic circuit; a combinational logic circuit; a Field Programmable Gate Array (FPGA); a processor (shared, dedicated, or group) that executes code; other suitable components that provide the described functionality; or a combination of some or all of the above, such as in a system on a chip. The term module may include memory (shared, dedicated, or group) that stores code executed by the processor.

As used above, the term code may include software, firmware, and/or microcode, and may refer to programs, routines, functions, classes, and/or objects. As used above, the term "shared" means that some or all code from multiple modules may be executed using a single (shared) processor. Additionally, some or all code from multiple modules may be stored by a single (shared) memory. As used above, the term "group" means that some or all code from a single module may be executed using a group of processors. Additionally, a set of memories may be used to store some or all code from a single module.

The apparatus and methods described herein may be implemented by one or more computer programs executed by one or more processors. The computer program includes processor-executable instructions stored on a non-transitory tangible computer-readable medium. The computer program may also include stored data. Non-limiting examples of the non-transitory tangible computer readable medium are nonvolatile memory, magnetic storage, and optical storage.

The foregoing description of the embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure. Individual elements or features of a particular embodiment are generally not limited to that particular embodiment, but, where applicable, are interchangeable and can be used in a selected embodiment, even if not specifically shown or described. The same embodiment can also be varied in many ways. Such variations are not to be regarded as a departure from the disclosure, and all such modifications are intended to be included within the scope of the disclosure.

Claims (36)

1. A method for measuring a glucose level of a patient, comprising:

receiving a target for a structured test from a patient;

identifying a test template corresponding to the target from a plurality of predefined test templates;

presenting a plurality of contextual criteria for the identified test template to the patient;

receiving a selection of one or more contextual criteria by the patient from a plurality of contextual criteria;

constructing a structured test comprising the patient-selected contextual criteria and in accordance with the identified test template; and

the structured test is performed on a patient, including prompting the patient to provide a blood sample to a glucose meter such that the steps of the method are carried out by a computer processor of the device.

2. The method of claim 1, further comprising presenting a plurality of goals for conducting the structured test to the patient such that each goal is associated with one of the plurality of test templates.

3. The method of claim 1 or 2, further comprising presenting the patient with a set of contextual criteria for the selected test template such that the contextual criteria associated with the given test template is different from the contextual criteria associated with another test template among the plurality of predefined test templates.

4. The method of any of the preceding claims, wherein conducting a structured test further comprises presenting a query to the patient for each contextual criterion, receiving a reply to the query from the patient, and associating the reply with data collected during the structured test.

5. The method of any of the preceding claims, wherein performing the structured test on the patient further comprises prompting the patient to enter a blood sample into the glucose meter before and after the given event within a time window that encapsulates the given event and presenting the patient with a query for contextual data about another event different from the given event.

6. The method of claim 5, further comprising presenting to the patient a query for contextual data about another event occurring outside of the time window.

7. The method of claim 5 or 6, further comprising prompting the patient to enter a blood sample into the glucose meter at a time that occurs outside of the time window.

8. The method of any of the preceding claims, further comprising defining adherence criteria for the structured test and reporting data collected during the structured test when the adherence criteria for the structured test are satisfied.

9. The method of claim 8, further comprising defining an adherence criterion based on the selected contextual criterion.

10. A method for collecting biomarkers from a patient, comprising:

presenting a plurality of contextual criteria for the structured test to the patient;

receiving a selection of one or more contextual criteria by the patient from a plurality of contextual criteria;

constructing a structured test comprising contextual criteria selected by the patient;

performing a structured test on a patient, including collecting biomarker data from the patient using a collection device;

evaluating whether a given contextual criterion selected by the patient has been met during the performance of the structured test; and

when the given contextual criterion is not satisfied during the implementation of the structured test, sample data acquired by the collection device during the structured test is marked as non-compliant.

11. The method of claim 10, further comprising reporting sample data acquired during the structured test as compliant when given contextual criteria selected by the patient are met during the conducting of the structured test.

12. The method of claim 10 or 11, wherein conducting a structured test further comprises presenting a query for each contextual input to the patient, receiving a reply to the query from the patient, and associating the reply with data collected during the structured test.

13. The method of any one of claims 10 to 12, wherein conducting a structured test on the patient further comprises prompting the patient to provide a blood sample into the glucose meter before and after a given event within a time window that encapsulates the given event and presenting the patient with a query for contextual data about another event different from the given event.

14. The method of claim 13, further comprising presenting the patient with a query for contextual data about another event occurring outside of the time window.

15. The method of claim 13 or 14, further comprising prompting the patient to enter a blood sample into the glucose meter at a time that occurs outside of the time window.

16. A method for measuring a glucose level of a patient, comprising:

prompting the patient to provide a blood sample to the glucose meter before and after the given event within the time window that encapsulates the given event;

determining a blood glucose measurement from the blood sample input to the glucose meter;

presenting to the patient a query for contextual data about another event occurring outside the time window;

receiving a reply to the query from the patient; and

associating the reply with a blood glucose measurement, wherein the steps of prompting, presenting, and associating are implemented by a computer processor of the device.

17. The method of claim 16, further comprising presenting to the patient a plurality of contextual criteria relating to the structured test administered to the patient; receiving a selection of one or more contextual criteria by the patient from a plurality of contextual criteria; and presenting the patient with a query for each contextual criterion.

18. The method of claim 16 or 17, further comprising:

constructing a structured test comprising contextual criteria selected by the patient;

performing a structured test on the patient;

evaluating whether a given contextual criterion selected by the patient has been met during the performance of the structured test; and

when a given contextual criterion is not satisfied during the implementation of the structured test, sample data acquired during the structured test is marked as non-compliant.

19. The method of any one of claims 16 to 18, further comprising prompting the patient to enter a blood sample into the glucose meter at a time that occurs outside of the time window.

20. A diabetes management device comprising:

a test configuration module configured to receive a target for the structured test from a user of the device and operable to identify a test template corresponding to the target from a plurality of predefined test templates, the test configuration module in data communication with a display of the device to present a plurality of contextual criteria for the identified test template and operable to receive a selection by the user of one or more contextual criteria from the plurality of contextual criteria;

a test construction module configured to receive contextual criteria selected by a user and construct a structured test comprising the contextual criteria selected by the user and according to the identified test template; and

a test administration module operable to administer a structural test to a patient,

wherein the test configuration module, the test construction module and the test implementation module are implemented as computer executable instructions by a computer processor of the device.

21. The diabetes management apparatus of claim 20, further comprising a blood glucose measurement module that selectively measures blood glucose in a blood sample.

22. The diabetes management apparatus of claim 20 or 21, wherein the test configuration module presents a plurality of targets for structured testing to a user such that each target is associated with one of a plurality of predefined test templates.

23. The diabetes management apparatus of any of claims 20 to 22, wherein the test configuration module presents to the user a set of contextual criteria for the selected test template such that the contextual criteria associated with a given test template is different from the contextual criteria associated with another test template of the plurality of predefined test templates.

24. The diabetes management device of any of claims 20 to 23, wherein the test enforcement module presents queries to the user for each contextual criterion, receives responses to the queries from the user and associates the responses with data collected during the structured test.

25. The diabetes management apparatus of any of claims 20 to 24, wherein the test implementation module evaluates whether a given contextual criterion selected by the patient has been met during implementation of the structured test; and reporting the sample data acquired during the structured test as compliant when given contextual criteria selected by the patient are met during the implementation of the structured test.

26. The diabetes management apparatus of any of claims 20 to 25, wherein the test implementation module marks sample data acquired during the structured test as non-compliant when given contextual criteria are not met during implementation of the structured test.

27. A method for collecting blood glucose measurements from a patient, comprising:

presenting a plurality of contextual criteria to a patient for a structured test, wherein the structured test comprises prompting the patient to provide a blood sample to a glucose meter before and after a given event;

receiving a selection of one or more contextual criteria by the patient from a plurality of contextual criteria;

constructing a structured test comprising contextual criteria selected by the patient;

performing a structured test on a patient multiple times over a period of time, thereby obtaining a sample instance of blood glucose measurements for each structured test in a series of structured tests performed;

evaluating whether a given contextual criterion selected by the patient has been met during the performance of a given structured test; and

when a given contextual criterion is not satisfied during the implementation of a given structured test, sample data acquired during the given structured test is marked as non-compliant or discarded.

28. The method of claim 27, further comprising reporting sample data acquired during the structured test as compliant when a given contextual criterion selected by the patient is met during implementation of a given structured test.

29. The method of claim 27 or 28, further comprising presenting to the patient a query for one or more contextual criteria during the conducting of the structured test, receiving a response from the patient to the query and associating the response with data collected during the structured test.

30. The method of any of claims 27 to 29, further comprising presenting to the patient a query for contextual data about another event occurring outside the time window.

31. The method of any one of claims 27 to 30, further comprising analyzing sample instances obtained during the series of structured tests and presenting results from the analysis to a patient.

32. The method of claim 31, further comprising prompting the patient to classify a sample instance for a given structural test and ignoring the sample instance for the given structural test in subsequent analyses when the patient classifies the sample instance as atypical.

33. The method of claim 31, further comprising presenting a query for at least one contextual criterion to the patient during implementation of a given structural test, receiving a reply to the query from the patient, prompting the patient to classify a sample instance for the given structural test, and ignoring the sample instance for the given structural test in subsequent analyses when the patient classifies the sample instance as atypical.

34. The method of any of claims 27 to 33, further comprising:

a first series of structured tests that guide the patient through construction using contextual criteria selected by the patient;

deriving a baseline blood glucose measurement from sample instances acquired during the first series of structured tests;

prompting the patient to change a variable associated with the first series of structured tests;

guiding the patient through a second series of structured tests, wherein the second series of structured tests have values of variables that are otherwise constructed using the patient-selected contextual criteria, different from the first series of structured tests; and

the altered blood glucose measurement is derived from the sample instances taken during the second series of structured tests.

35. The method of claim 34, further comprising presenting results from the first and second series of structured tests to the patient including a comparison of the baseline blood glucose measurement and the altered blood glucose measurement.

36. The method of claim 34 or 35, further comprising analyzing sample instances obtained during the first and second series of structured tests and presenting results from the analysis to the patient.