Patent Application
20080214919
The present disclosure relates to an integrated system and method for implementing glycemic control protocols (e.g., continuous and/or episodic infusion treatment, oral hypoglycemic therapy, intensive insulin therapy, or any such glycemic control therapy); more specifically, the present disclosure may further relate to semi-closed or closed loop systems and methods for the automated implementation of such protocols.
Hyperglycemia brought on by stress of illness, insulin resistance, and/or insulin deficiency during critical illness may directly or indirectly confer a predisposition to complications such as severe infection, polyneuropathy, multiple organ failure, and even death. Normalization of blood glucose levels with intensive therapy (e.g., administration of insulin or other agent) reduces mortality and morbidity among critically ill patients. For example, in diabetic patients with acute myocardial infarction, therapy to maintain blood glucose at a level below about 215 mg per deciliter (about 11.9 mmol per liter) improves the patient's long-term outcome. In nondiabetic patients with protracted critical illnesses, high serum levels of insulin-like growth factor-binding protein 1, which reflects an impaired response of hepatocytes to insulin, can increase the risk of death. (See Van den Berghe et al, Intensive Insulin Therapy in Critically Ill Patients, N Engl J. Med 2001; 345:1359-67). In cardiac surgery, intensive insulin therapy can reduce in-hospital mortality, infectious complications, and/or the length of the hospital stay. (See Fumary, A. P., Wu, Y. X.: Clinical Effects of Hyperglycemia in the Cardiac Surgery Population The Portland Diabetic Project, Endo Pract. July-August 2006; 12 Suppl 3:22-26).
Present day methodologies for glycemic control most commonly rely on manually transferring blood glucose data obtained from a Food and Drug Administration (“FDA”)-approved glucose measuring device to a paper or electronic medical form. The progression and dynamic response of that particular patient's glucose level is assessed by the medical clinician (e.g., a nurse or a physician) caring for the patient, who then integrates that information with a paper-based algorithm, or “protocol” to determine the next insulin-based, or other glucose manipulating intervention to be applied to that particular patient. In the most common scenario, the interaction between the measuring device, the clinician, the protocol, and the insulin action is subject to the interpretive capabilities of the involved clinician.
Less commonly, data from the glucometer is manually entered into computerized algorithm-based devices that are separate systems capable of interfacing with patient information. Such manual transfer of data may lead to significant user error and work-flow inefficiency. In addition, such systems are unable to efficiently account for the large number of variables that must be considered in properly implementing a glycemic control protocol (e.g., time since last glucose measurement, meal information, diabetic or non-diabetic status, cardiac issues, type/amount of medication already being administered, prior test results, current test results, operator/nurse competencies, etc.). Furthermore, the present day methodologies are not able to efficiently account for patient logistics (e.g., patients being admitted to the hospital, patients being transferred from one hospital location to another, and/or patients being discharged and/or re-admitted) when properly implementing a glycemic control protocol.
Thus, there is a need for an integrated system and method capable of implementing any type of glycemic control protocol.
Various embodiments of a system and a method of implementing a glycemic control protocol are provided herein. As described below, the presently disclosed embodiments enable a medical professional to determine and store a patient's current blood glucose level at a particular time point. In view of this test result, the system can provide one or any number of treatment steps. For example, the treatment steps can include adjustments to the patient's treatment (e.g., a change in medication, diet, etc.) or the treatment steps can include any of a number of actions (e.g., scheduling a future test, providing various qualitative and/or quantitative patient status indicators, etc.). Further, the system can compare a patient's current test result at a current time point with at least one prior test result taken at a prior time point in order to provide a current treatment step. Additionally, the system can also consider any or all prior treatment steps in determining the current treatment step. In short, the presently disclosed embodiments provide a robust and versatile system and method configured to utilize and manage a wide range of information in order to enhance patient care and treatment outcome.
Various aspects of a system for implementing a glycemic control protocol are provided herein. In one such aspect, the system includes a glucose measuring device (e.g., a hand-help device) configured to determine a patient's current blood glucose level at a current time point. Additionally, the system includes a storage means (e.g., a database, etc.) associated with the glucose measuring device wherein the storage means can be configured to store the patient's current blood glucose level and the current time point. The system can also include processor associated with the glucose measuring device wherein the processor can be configured to implement at least one glycemic control protocol which is configured to provide a treatment step which is at least partially dependent upon the current blood glucose level and the current time point.
As will be described below, the treatment step can be virtually any step suggested or implemented by the system. Also, the system can provide a single treatment step or the system can provide a plurality of such treatment steps. For example, the treatment step can be an adjustment or the treatment step can be an action. Examples of an adjustment include a change medication or a meal adjustment. Regarding the medication adjustment, the adjustment can include a change in a type of medication being administered to the patient or the medication change is an increase or a decrease in an amount or a dosage of the medication being administered to the patient. As will be appreciated by those skilled in the art, the medication can be any medication capable of manipulating the patient's blood glucose level. Also, the adjustment can be suggestion. Examples of an action can include scheduling a future time for a test and/or providing various qualitative and/or quantitative patent status identifiers (which can be provided on a user interface associated with the system).
As indicated, the system can be configured to provide a plurality of treatment steps wherein the treatment steps are at least partially dependent upon the current blood glucose level and the current time point. For example, the plurality of treatment steps can include a first treatment step and a second treatment step. In such an embodiment, the first treatment step can being an adjustment and the second treatment step being an action wherein the action can be at least partially based upon the adjustment. Additionally, the action can be performed automatically in a semi-closed or closed loop manner.
In providing a treatment step, the system can consider factors in addition to the current test result and a corresponding time point. For example, in one embodiment, the storage means can further stores at least one previous patient blood glucose level and a previous time point associated with the at least one previous patient blood glucose level. Additionally, the storage means can be further configured to store a previous treatment step associated with the previous patient blood glucose level and the previous time point associated with the previous blood glucose level. In this embodiment, the system can include a comparison means (e.g., any commonly known comparison means) associated with the glucose measuring device. In use, the comparison means can be configured to compare the patient's current blood glucose level and current time point with the at least one previous patient blood glucose level and the previous time point to provide a glucose rate of change (e.g., an absolute difference, a rate, or a percent) wherein the treatment step is at least partially dependent upon the glucose rate of change.
Adding to the versatility of the system, the glucose measuring device can be configured to distinguish between a plurality of patients such that each patient can be correlated with a corresponding glycemic control protocol. For example, in one embodiment, the glucose measuring device can be configured to communicate with a patient-specific database located on a patient-specific tag (e.g., an RFID tag). Adding to the versatility of the system, the storage system (e.g., database) and/or processor can be located within the glucose measuring device.
In another aspect, a system for implementing a user-definable glycemic control protocol is provided which includes a glucose measuring device configured to determine a patient's blood glucose level at a current time point. Additionally, the system includes a memory system having a storage means wherein the memory system can be configured to communicate with the glucose measuring device and the storage means can be configured to store the patient's current blood glucose level and the current time point. Additionally, the system can include a processor configured to communicate with the glucose measuring device. The processor can be further configured to implement a user-definable protocol wherein the user-definable protocol can be configured to determine a treatment step based at least partially on the patient's current blood glucose level and the current time point. Similar to above, the memory system and/or the processor can be located within the glucose measuring device.
As indicated, the system can allow an authorized operator (e.g., a protocol administrator) to modify the protocol as desired. For example, in one embodiment, the system can include an editor in communication with the processor wherein the editor can be configured to modify the glycemic control protocol in response to instructions from a protocol administrator.
In some embodiments, the system can be configured to ensure that authorized operators are utilizing the system (e.g., performing tests and/or modifying the protocol.) For example, the glucose measuring device can be configured to receive an operator identifier (e.g., an identification number) prior to use wherein the storage means can be configured to associate the operator identifier with the current blood glucose level and the current time point. Also, the system can further require a second operator identifier (e.g., the second operator identifier being distinct from the first operator identifier) associated with a second operator prior to use. In some embodiment, the system can require the second operator identifier prior to the incorporation of any adjustments and/or actions into the glycemic control protocol.
Various aspects of a method of implementing a glycemic control protocol are also provided herein. In one such aspect, the method includes loading a glycemic control protocol onto a glucose measuring device wherein (similar to above) the glycemic control protocol can be configured to provide at least one treatment step (e.g., an adjustment and/or an action) based at least partially on a patient's blood glucose level measured at a specific time point. Next, the method can include measuring a patient's current blood glucose level with the glucose measuring device, and associating the patient's current blood glucose level with a current time point. The method also can include providing an treatment step which is at least partially determined by the glycemic control protocol. Additionally, the method can further include storing the patient's current blood glucose level, the associated time point, and the treatment step in a database in communication with the glucose measuring device.
In some embodiments, the method can also include comparing the patient's current blood glucose level and current time point with at least one prior blood glucose level determined at a prior time point so as to provide a glucose rate of change, and providing a treatment step which is based at least partially dependent upon the glucose rate of change. In such an embodiment, the treatment step can determined by the glycemic control protocol's interpretation of the rate of change and a prior action. Optionally, the method can also include a step for determining if the patient's current blood glucose level is a valid test result.
In yet another aspect, a method for implementing a glycemic control protocol is provided which includes providing a glucose measuring device and also providing a memory system having a storage means containing a plurality of glycemic control protocols. Additionally, the method can include providing at least one patient, and associating the at least one patient with a patient-specific glycemic control protocol wherein the patient-specific glycemic control protocol can be selected from the plurality of glycemic control protocols contained within the storage means. The method can further include measuring the patient's current blood glucose level, associating the patient's current blood glucose level with a current time point, and providing a treatment step which is determined by the patient-specific glycemic control protocol. Optionally, the method can also include loading the patient-specific glycemic control protocol onto the glucose measuring device.
The method can also include providing a plurality of patients, and further associating each patient of the plurality of patients with a patient-identification tag wherein the patient identification tag includes a storage means configured to store a plurality of patient-specific information. In such an embodiment, the glucose measuring device can be configured to communicate with the patient's patient-identification tag. Also, the method can further include (e.g., following the associating step) modifying the patient-specific protocol thereby providing a user-definable protocol.
The present disclosure will be more fully understood from the following detailed description taken in conjunction with the accompanying drawings, in which:
Certain exemplary embodiments will now be described to provide an overall understanding of the principles of the structure, function, manufacture, and use of the devices, systems, and methods disclosed herein. One or more examples of these embodiments are illustrated in the accompanying drawings. Those skilled in the art will understand that the devices, systems, and methods specifically described herein and illustrated in the accompanying drawings are non-limiting exemplary embodiments and that the scope of the present disclosure is defined solely by the claims. The features illustrated or described in connection with one exemplary embodiment may be combined with the features of other embodiments. Such modifications and variations are intended to be included within the scope of the present disclosure.
Various embodiments of a system for implementing a wide-range of glycemic control protocols in an automated, semi-closed or closed loop manner thereby eliminating common sources of system and/or interpretive error are provided herein. More specifically, the presently disclosed embodiments provide a blood glucose measuring device in communication with a wide-range of databases and/or interfaces thereby allowing for typically independent steps such as patient testing, result determination, protocol adjustment (suggestions as well as actual calculations of new dosages), meal information, scheduling of future testing in light of test results, and administration of medicine to be performed manually or automatically in a semi-closed or closed loop manner. Furthermore, the system provides for ultimate flexibility by allowing a protocol administrator to continuously add, subtract, and/or modify various steps of protocol while maintaining the integrity and safety of the system. Thus, the system can implement a user-definable protocol as opposed to being limited to a single (or a predetermined) protocol. In short, the presently disclosed system and method can be utilized to provide hospitals, various medical facilities, and/or patients themselves with a powerful technology capable of best optimizing resources (i.e., time and money) as well as providing improved patient care by real-time interpretation of glucose testing, real-time comparison and/or interpretation of such results in relation to previous result and/or previous courses of action, and by the elimination of common errors (e.g., incorrect data input and/or interpretation).
As will be appreciated by those skilled in the art, any glycemic control protocol can be implemented with the presently disclosed system. As will be described, the system can also implement any of a plurality of protocols as opposed to being limited to a single pre-determined protocol. Additionally, the system can allow for a protocol administrator to modify the protocol thereby allowing for a user-definable protocol. In an exemplary embodiment, the glycemic control protocol is a Tight Glycemic Control (“TGC”) protocol. While various examples below describe TGC protocols, those skilled in the art will appreciate that any other such glycemic control protocol is within the spirit and scope of the present disclosure. Similarly, in some embodiments, the system can control the amount and type of medication being delivered (e.g., intraveneously, orally, trans-dermally, trans-bronchially, inhalation, absorbed trans-mucosal, transnasally, subcutaneously, etc.) to a patient in order to move (or maintain) a patient's blood glucose level to within a target range. Those skilled in the art will also appreciate that any medication capable of manipulating blood glucose levels can be utilized by the presently disclosed system. In an exemplary embodiment, the medication is insulin. In other embodiments, the medication can include glucose, an insulin analogue, glucagon, any insulin sensitizing agent, a sulfonourea, thiazolidinedione, an amylin or amylin mimetic agent, a glucagons suppressor, an insulin secretagogue, an incretin or incretin mimetic, a biguanide, a GLP-1 analogue, a DPP inhibitor, a DPP inhibitor, or any combination thereof. Thus, the presently disclosed system can implement any glucose control protocol capable of utilizing any of a wide variety of medication capable of manipulating a patient's blood glucose levels thereby maintain the level within a target range.
Referring now to
As shown in
Looking at the glucose measuring device 12, the device 12 can be any device capable of storing and/or implementing a glycemic control protocol in order to accurately determine a patient's current blood glucose (“BG”) level (an accurate test being within about +/−15% or better relative to a reference glucose measuring system). Furthermore, the glucose measuring device 12 can be configured so as to store various types of patient and/or protocol information (e.g., previous test data, meal information, etc.). Furthermore, the glucose measuring device 12 can be configured to perform various comparisons and establish various trends between current and prior test data, suggest changes to current protocols (e.g., changes is medication and/or diet) based on test data and or previous treatments, calculate changes to protocol based on suggested changes, and/or schedule future testing in light of the above information. In an exemplary embodiment, the glucose measuring device 12 is a OneTouch®) Flexx™ with TGC meter available from LifeScan, a Johnson & Johnson company. The various functions of the glucose measuring device 12 and system 10 will be described in detail below.
The glucose measuring device 12 can include a user interface capable of displaying certain data and/or information to the user (e.g., healthcare professional, patient, etc.). In addition, the glucose measuring device 12 can include various buttons and/or links allowing the user to input information as well as navigate from one screen to the next in order to view different types of information. Such devices are commonly used and therefore various embodiments of such devices would be readily apparent to those skilled in the art.
As will be apparent from the discussion below, the implemented glycemic control protocols can be as simple or as complex as desired by a protocol administrator. While the system can utilize virtually any glycemic control protocol,
Once the protocol is loaded, the system can proceed to a patient test (Step 52). The test can be any test capable of accurately determining a patient's current BG level. Typically, the test includes obtaining a patient sample (e.g., a blood sample) and delivering the sample to a glucose measuring device 12 thereby determining the current BG level at a current time point. As will be shown in detail below, the glucose measuring device 12 can be configured so as to allow for the current test result and current time point to be directly utilized by the system 10 thereby eliminating any need for the information to be manually transferred by a user to a distinct, second system as this manual transfer step can be a significant source of error.
Next, the system 10 can allow for a series of results to be produced from the patient test (Step 54). The results can include a determination of the current BG level, a comparison of the current BG level to the desired target range, and/or a comparison of a previous patient result at a previous time point compared to the current BG level at the current time point. Additionally, the system 10 can determine how dramatically the BG level is increasing/decreasing (i.e., rate of change). In addition, the results may include a qualitative status identifiers such as “High” (current BG level above target range), “Low” (current BG level below target range), “Rising” (current BG level higher than previous BG level), etc. As will be apparent to those skilled in the art, the system 10 can be configured to provide various types of quantitative and/or qualitative results as desired by the protocol administrator.
Next, the presently disclosed system can suggest changes or modifications to the current treatment in order to allow a patient's BG level to return and/or remain within the desired BG range (Step 56). For example, in light of the testing results mentioned above, the system 10 can suggest a change in medication (e.g., from insulin to glucose or vice versa), the additional administration of a medicine, or a change in dosage of medication (e.g., increase administration of insulin by X amount/percent for Y hours, or addition of an alternative glucose controlling medication other than insulin). Alternatively, the system 10 can suggest no change in therapy or the system 10 may stop the administration of medication until a patient's BG level has increased by a certain amount (as in the case of a hypoglycemic patient). In these cases, the system can automatically implement a “Restart State” which is capable of being configured to a patient's being mildly or, alternatively, severely hypoglycemic. Once the appropriate changes are determined, the system 10 can perform the necessary calculation to modify the current treatment to the new treatment. For example, if the protocol programmed into the system suggests a 20% increase in medication (e.g., insulin), the system can calculate and inform the user of the new amount of such medication to be administered. Once again, the semi-closed or closed loop re-calculation step substantially eliminates user error from this step (e.g., an incorrect user calculation or an error resulting from configuration of IV Pump for insulin infusion).
Finally, the system 10 can provide an action such as suggesting a date and time for the next patient test (Step 58). The date and time can be determined in light of the currents results, in light of any suggested adjustments to protocol discussed above, in light of a comparison between current test results at current time and previous test results at a previous time, etc. For example, if a patient's BG level is above or below the desired range or if significant adjustments have been implemented in a patient's therapy (e.g., increase/decrease in medication), the next test can be scheduled sooner as opposed to a patient who is stable or where no adjustments in dosage and/or therapy are suggested. Therefore, the system can be configured to efficiently utilize hospital time and technology. As will now be shown, each of the steps discussed above may be broken down into numerous sub-steps in order to provide the protocol administer with a robust system 10 capable of implementing any desired protocol for any type of patient (i.e., diabetic, non-diabetic, cardiac, etc.).
In general, as represented in
In general, the Pre-Testing Stage (100) can be considered to include all steps from powering on the glucose measuring device (Step 102) up to the beginning of the Patient Testing Stage (200). As shown in the exemplary embodiment of
In addition to such basic information, the Meter Status screen (Step 104) can also be configured to inform a user of any corruption associated with the protocol and/or the glucose measuring device 12. For example, prior to performing any additional step(s), a cyclical redundancy check (“CRC”) for the implemented TGC protocol and any TGC patient information coupled to the glucose measuring device 12 can be checked for corruption. If any corruption is detected, an appropriate error message (e.g., “Last Data Transfer Failed”, “QC Failed”, or “TGC Protocol Corrupted”, etc.) can be displayed and the glucose measuring device 12 disabled from patient testing. Updating the glycemic control protocol (as will be discussed below) shall then be required using, for example, the TGC Protocol Editor and Transfer tool, to fix the corruption. If any glycemic control patient information record is corrupted, then updating the glycemic control protocol shall also clear the corrupted patient information record.
Returning to
In general, the TGC Dashboard (Step 108) can include any type of patient information the protocol administrator may feel would be necessary and/or helpful to the user treating the patient. For example, the TGC Dashboard (Step 108) can be configured to identify any patient who has been tested with the glucose measuring device 12 in the last hour, the last 5 hours, the last 12 hours, the last day, the last 2, 3, 4, 5, 10 days, etc. Alternatively, the system 10 may be configured to identify the last 10, 20, 30, 40, 50, 100, etc. patients who have been tested by the glucose measuring device 12. Further, the TGC Dashboard (Step 108) can be configured to link various types of patient data to each patient identification number. For example, the TGC Dashboard (Step 108) may include a patient identification number, the time and date of the next scheduled test, and the time-date-result of a prior test, etc. Also, the Dashboard (Step 108) may include time and date of patient's last meal as well as any comment(s)/note(s) regarding the patient, the previous test, the treatment protocol, treatment suggested and/or the actual treatment performed, etc.
Additionally, the TGC Dashboard (Step 108) can include a link to “TGC Information” (Step 110) and a link to “Meal Information” (Steps 112, 114, 116). As will be seen below, TGC Information (Step 110) can include any additional information regarding the patient and/or TGC protocol as deemed necessary and/or desirable by the protocol administrator. As such, the feature provides added flexibility to the system 10. Regarding the “Meal Information” link, selecting the “Meal” link can prompt a user to input an operator and patient ID (Step 112). This step will be discussed in detail below as related to similar steps associated with patent testing (See Steps 202 and 204). In short, the identification step (Step 112) allows for the protocol administrator to ensure that authorized and trained personal are operating the glucose measuring devices (and thus performing the testing). In addition, the patient ID link serves to link any patient testing to any stored information relating to the patient but also ensures proper patient identification. Once the identification numbers are provided (Step 112), a user can be directed to a Meal Action Guidelines step (Step 114)). The Meal Action Guidelines step (Step 114) can provide a user with all meal information related to a specific patient. For example, such meal information can include time-date-content (i.e., amount of carbohydrates) of a prior meal, time-date-content of a next meal, etc. Furthermore, a user can select to continue to a TGC Meal Retest step (Step 116) wherein the user can schedule a retest time based on meal consumed and/or record when meals are consumed. Therefore, these steps (Steps 112, 114, 116) allow for a user to monitor and link a patient's dietary habits to any other testing and/or patient data/information.
Following a review of any/all patient information provided by the TGC Dashboard (Step 108), the system 10 can be configured to direct a user to a Main Menu screen (Step 118). In general, the Main Menu screen (Step 118) can be configured by the protocol administrator to include any number and/or type of action items as desired. For example, the action items may include “Perform QC Test”, “Review Patient Results”, etc. In the exemplary embodiment of
At this stage (200), the system 10 can perform a patient test in order to accurately determine a patient's current blood glucose (“BG”) level via episodic and/or continuous blood glucose testing. As stated above, the test can include any glucose measuring device 12 configured to accurately determine the patient's current BG level at a current time point. In an exemplary embodiment, the device 12 is the OneTouch®Flexx™ glucose measuring device. In addition to performing the test (Step 218), the stage (200) can also include any other steps as desired by the protocol administrator.
Upon entering the Patient Testing Stage (200), a user can be prompted to input an operator identification number (Step 202). As briefly mentioned above, requiring input of an operator identification number (Step 202) can allow the protocol administrator to ensure the glucose measuring device 12 is being used by an authorized/trained user. In addition, the authorization step (Step 202) can produce a record of which operator is performing which test and treatment to which patient. In one embodiment, the protocol can be configured to require multiple operator identification numbers thereby requiring a confirmation check for the user (as described in detail below in relation to
Following input of user/patient identification numbers, the system 10 can include a confirmation step (Step 216) wherein the system can determine if the patient identification number is recognized. If not found, the system 10 can inform the user that the patient's identification number is not recognized (Step 206) by the system 10. This can result for several reasons. First, the patient may have been recently transferred and the information was not successfully transferred to the system 10 and/or glucose measuring device 12. Also, the system 10 may determine that the previous test is too old for use in the current protocol. In these cases, the protocol may direct a user to a Patient Information Menu (Step 208) which allows for the user to input some information regarding the patient (e.g., Insulin Dependent, Non-Insulin Dependent, non-TGC patient, Patient Transfer, etc.) in order to build a preliminary patient record. If Patient Transfer (Step 210) is selected, the user may be allowed to manually enter (Step 212) a prior BG level from the patient's records into the system 10. In cases where data is being manually entered (Step 212), the protocol can require confirmation of the data entry by a second user.
If the patient identification number is recognized, the system 10 can include a check step (Step 217) wherein the system 10 can determine if there is any reason not to continue testing. For example, the system can include a safety precaution wherein the system 10 may prompt the user that a minimum time period has not been achieved since the last test (Step 214) and/or treatment was performed. This feature is meant to prevent cases where a first user performs a test/treatment and a second user, not realizing the test/treatment has already been performed, attempts to perform a second test/treatment. In this case, the protocol administrator can allow for the user to override the error message if desired (which may once again require confirmation from a second user).
Once the operator and patient identification numbers have been successfully entered and confirmed (if necessary), the user may be delivered to the patient testing step (Step 218). As stated above, the system 10 can include any steps capable of accurately measuring the patient's current blood glucose level as well as allowing for a user to verify if last test result was valid (last test result allows for future comparison to current test result). Typically, the protocol can include delivering a patient sample (i.e., blood) to the glucose measuring device 12 via a delivery device (such as a test strip, direct contact with blood from a sterile tubing attached to the patient, an implanted sensor, etc.). After the test, a current BG level for the patient can be determined and automatically utilized by the system 10 to determine various patient results (e.g., actions and/or adjustments) which can be displayed at the Patient Result screen (Step 222).
In determining the patient results (Step 220) and subsequent steps (scheduling a subsequent test, adjusting medication and/or diet, etc.), the system 10 can be configured to perform any type and/or number of comparisons as required by the implemented protocol. Further, the system 10 can be configured to identify any trends in testing (Step 220). For example, the current BG level at the current time point can be compared to the desired range in order to determine if the current level is high, low or within range. Also, the current level may be compared to critical levels (a level above or below a normal range) to determine if the current level is critically high or low and provide user instructions and/or guidelines (providing such instruction may be important is these critical cases). Further, the protocol can be configured so as to allow for the current BG level at the current time to be compared with the patient's prior (one or more) BG levels taken at a prior time so as to determine if the levels are rising, falling or remaining stable. In addition to performing the desired comparisons, the protocol may be configured so as to provide qualitative information (i.e. status identifiers) such as “High”, “Low”, “Critically High”, “Critically Low”, “Levels Rising (fast/slow)”; “Levels Falling (fast/slow)”, “Stable”, “Call Doctor!”, etc. or any other non-worded symbols representing these informative status identifiers. Additionally, based on any combination of these variables, the system can provide various steps which can include any number of actions (e.g., scheduling a time point for a subsequent test, calling for an intervention, etc.) and/or the steps can include various suggested adjustments to the treatment protocol (e.g., adjustments in medication, diet, etc.). For example, the results can include instructions to perform a retest (a “Restart Mode”) if an error was recognized or if a patient's level is far from the desired level. In one embodiment, the patient may be identified as hypoglycemic and prevented from obtaining any further medication (e.g., insulin) until the test result rises to a specified level. In this case, the results display interface (Step 222) may be configured to specifically address this specific condition (e.g., utilizing a qualitative message such as “Level too low; No insulin!”) These identifiers along with the actual test data can be displayed to the user at the Patient Results Display Screen (Step 222). Following a review of the data, the system 10 can be configured to direct the user to the Post-Testing Stage (300).
Entering the Post-Testing Stage (300), the system 10 can be configured to deliver a user to a Results Summary interface (Step 302) which allows a user to review various types of patient-related information such as date-time-result of the current test, date-time-result of any prior test, any meal information, and/or any comment(s)/note(s) related to the patient (e.g., status identifiers, previous treatments performed, etc). Additionally, the Result Summary interface (Step 302) can include a link to the TGC Information page (Step 110). As discussed above, the TGC Information page (Step 110) can provide any additional patient and/or protocol information as desired by the protocol administrator. After reviewing the information provided at the Results Summary interface (Step 302), the system 10 can direct the user to the TGC Result Action Guidelines step (Step 304).
The TGC Result Action Guidelines step (Step 304) can be configured to suggest various changes to the treatment (“adjustments”) in light of the various test data determined above. Typically, the changes are suggested/required in order to return the patient's BG level to within the desired range and/or to maintain the level within the desired target range. For example, the protocol may suggest changing medication (e.g., from insulin to glucose or vice versa) or adding/subtracting medications to/from a patient's therapy. Furthermore, the system 10 can be configured to suggest increasing/decreasing the medication being administered to the patient (for example, increase insulin administration by X amount/percent for Y hours or decrease insulin by Z units/h). Furthermore, the suggestion may be meal adjustments (i.e., decrease portion size, amount of carbohydrates, etc.). It will be apparent to those skilled in the ant that any of a wide range of other such adjustments are within the spirit and scope of the present disclosure.
If changes in dosage are suggested, the system 10 can be configured to include a TGC Calculator (Step 306) configured to perform the actual calculation required to modify the treatment protocol to the new, suggested/required treatment. In a further embodiment (not shown on flow chart), the system can be configured to trigger the actual administration of the medication after making the suggested/required change (e.g., the system 10 being in communication with an IV pump). These steps can substantially eliminate any calculation errors resulting from a user's attempts to determine the required increase/decrease in dosage.
Following a review of any suggestions provided at the TGC Result Action Guideline (Step 304) and implementing any desired suggestions by means of the TGC Calculator (Step 306), the system 10 can proceed to the step of Scheduling Future Tests (Step 308). At this step (Step 308), the system 10 can be configured to evaluate any patient/testing information such as the patient's current BG level, the relationship of the current level to the target range (e.g., is the current BG level above, below, or within the target range), any implemented changes in the protocol, etc. and, in light of this information, determine an appropriate future test time. Stated another way, the system 10 can be configured to classify a patient as high priority or low priority so as to optimize hospital resources. For example, a patient having a high or low current BG level or a patient who recently changed dosages (e.g., increase insulin by 20%) may need to be tested sooner as compared to a patient having a current BG level within the desired range and having no adjustment in dosage. As discussed throughout, the protocol administrator can configure the system 10 to provide for a user override and further scheduling a subsequent test at the user's suggested time. Following this step (Step 308), the system can proceed to a Documentation step (Step 310) wherein the user can document patient status and/or treatment provided. Next, the user may End TGC testing (Step 320).
As indicated above, various steps of the above-described system can be added or removed as desired by the protocol administrator thereby allowing for a user-definable glycemic control protocol. For example,
Referring to Step 356, the system 10 can be configured to always require confirmation or may be configured to require confirmation only in certain circumstances such as being dependent upon a patient state (e.g., restart state), based on adjustment parameters (e.g., only when IV insulin is increased or decreased when change is greater than or equal to a set percentage value or set units/h value, or when total a amount of an IV insulin or a bolus exceeds a set units/h value), or based on operator state (e.g., operator flagged as NVO and/or NCO). If the system 10 requires such confirmation, the system 10 can be configured to display adjustment/confirmation information (e.g., prompting a user to acknowledge such adjustments). Next, the system 10 can be configured for entry of a second operator identifier. If not so configured, the system 10 can once again move to Step 368 and exit the confirmation stage (350). If the system 10 is configured to require a second operator identifier, the system 10 can ask for the second identification number (Step 362). Next, like Step 354 above, the system 10 can determine if the second identifier is valid (Step 364). If no, the system 10 can reject the second entry (or once again flag the second operator). If accepted, the system 10 can check to see if the first operator identifier is different from the first confirmation identifier (Step 366). If no, the system can reject the entry. If yes (identifiers are different), the system 10 can end this stage (350) (Step 368).
The following examples and corresponding FIGS. provide a detailed flow chart as well as example user displays screen associated with the various stages. Like above, these are merely provided as examples of the presently disclosed system and are not intended to limit the scope of the present disclosure in any way.
As shown, the system 10 can be activated by powering on the glucose measuring device (Step 102; see
From the TGC Dashboard (Step 108), the user may be directed to the Main Menu (Step 118; see
The OneTouch® Flexx™ TGC Meter utilizes a strip test wherein a patient's sample (e.g., blood) is added to a test strip and delivered to the glucose measuring device 12. As such, in this exemplary embodiment, the system 10 may be configured to request a strip lot number (Step 217; see
Following this flow, the protocol may include another check to verify that TGC is Enabled and Protocol Triggered (Step 225) before transferring the results to a TGC Result Summary Step (Step 302, see
Returning to Step 221, if the system is TGC Enabled then all data is transferred and displayed along with any desired qualitative status identifiers in a Patient Results Step (Step 222; various examples of possible results are shown at
Following a review of the various information associated with the TGC Result Action Guidelines (Step 304), the user may select to continue to the TGC Result Retest Guidelines (Step 308, see
Various aspects of a method of implementing a glycemic control protocol are also provided herein. In one such aspect, the method includes loading a glycemic control protocol onto a glucose measuring device wherein (similar to above) the glycemic control protocol can be configured to provide at least one treatment step (e.g., an adjustment and/or an action) based at least partially on a patient's blood glucose level measured at a specific time point. Next, the method can include measuring a patient's current blood glucose level with the glucose measuring device, and associating the patient's current blood glucose level with a current time point. The method also can include providing an treatment step which is at least partially determined by the glycemic control protocol. Additionally, the method can further include storing the patient's current blood glucose level, the associated time point, and the treatment step in a database in communication with the glucose measuring device.
In some embodiments, the method can also include comparing the patient's current blood glucose level and current time point with at least one prior blood glucose level determined at a prior time point so as to provide a glucose rate of change, and providing a treatment step which is based at least partially dependent upon the glucose rate of change. In such an embodiment, the treatment step can determined by the glycemic control protocol's interpretation of the rate of change and a prior action. Optionally, the method can also include a step for determining if the patient's current blood glucose level is a valid test result.
In yet another aspect, a method for implementing a glycemic control protocol is provided which includes providing a glucose measuring device and also providing a memory system having a storage means containing a plurality of glycemic control protocols. Additionally, the method can include providing at least one patient, and associating the at least one patient with a patient-specific glycemic control protocol wherein the patient-specific glycemic control protocol can be selected from the plurality of glycemic control protocols contained within the storage means. The method can further include measuring the patient's current blood glucose level, associating the patient's current blood glucose level with a current time point, and providing a treatment step which is determined by the patient-specific glycemic control protocol. Optionally, the method can also include loading the patient-specific glycemic control protocol onto the glucose measuring device.
The method can also include providing a plurality of patients, and further associating each patient of the plurality of patients with a patient-identification tag wherein the patient identification tag includes a storage means configured to store a plurality of patient-specific information. In such an embodiment, the glucose measuring device can be configured to communicate with the patient's patient-identification tag. Also, the method can further include (e.g., following the associating step) modifying the patient-specific protocol thereby providing a user-definable protocol.
One skilled in the art will appreciate further features and advantages of the present disclosure based on the above-described embodiments. Accordingly, the present disclosure is not to be limited by what has been particularly shown and described, except as indicated by the appended claims. All publications and references cited herein are expressly incorporated herein by reference in their entirety.
This application claims priority under 35 U.S.C. §119(e) to U.S. provisional patent application Ser. No. 60/871,856, filed Dec. 26, 2006, the entirety of which is hereby incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60871856 | Dec 2006 | US |
