Patent Application
20140324463
The present disclosure relates to patient and/or health care provider diabetes data management systems and methods.
Persons with diabetes often have difficulty regulating blood glucose levels in their bodies. As a consequence, many of these persons carry specialized electronic meters, called blood glucose meters, which allow them to periodically measure their glucose levels and take appropriate action, such as administering insulin. After a blood glucose measurement or series of measurements is taken, a diabetic patient may find it useful to communicate these measurements to his or her healthcare professional for further review and analysis. In this regard, the patient's blood glucose meter may be capable of storing the blood glucose measurements for later review and analysis by the patient or the healthcare professional, who may then record the measurements manually or electronically.
The process of measuring, storing, recording and analyzing blood glucose levels can be a very time consuming process for both the patient and the patient's healthcare professional. Often, the exchange and review of data requires a meeting between the patient and the healthcare professional. People with diabetes are often searching for better and more efficient ways to manage their health. In addition, healthcare professionals need new tools to motivate people with diabetes to communicate more effectively. Technology can provide a viable platform for software applications for a wide variety of consumer demands. Moreover, many people with diabetes use personal computers and/or mobile devices in their daily lives.
To improve the effectiveness and efficiency of storing, communicating and analyzing blood glucose measurements, it may be desirable for the patient and the patient's healthcare professional to send data, including blood glucose measurements, to a centralized electronic data repository for later retrieval and analysis. It may also be desirable for the patient and the patient's healthcare professional to have these data transmission capabilities at various times and from various locations.
This section provides background information related to the present disclosure, which is not necessarily prior art.
A method of managing diabetes management data includes: receiving, at a computing device, account creation information input by a user; transmitting the account creation information from the computing device to a diabetes management server; using the diabetes management server, creating an account based on the account creation information; receiving, at the computing device, diabetes management data from a diabetes management device that is connected to the computing device wirelessly or by wire, wherein the diabetes management data does not include a blood glucose (bG) measurement; using the computing device, transmitting an indicator of the account and the diabetes management data to the diabetes management server. The method further includes, using the diabetes management server, in response to receipt of the diabetes management data: creating a bG measurement entry for the account in a database, leaving empty a field of the bG measurement entry for a bG measurement in the bG measurement entry based on the diabetes management data not including a bG measurement; and storing the diabetes management data in one or more respective fields of the bG measurement entry. The method further includes: using the diabetes management server, generating a user interface for displaying data stored in the bG measurement entry and at least one other bG measurement entry that is associated with the account; and, using the computing device, accessing data stored in the database in association with the account and displaying the user interface including displaying the data stored in the bG measurement entry and the at least one other bG measurement entry that is associated with the account.
In further features, the method further includes: using the diabetes management server, generating a second user interface based on a type of diabetes management therapy associated with the account, wherein the account information input by the user includes the type of diabetes management therapy; and using the computing device, displaying the second user interface.
In further features, the second user interface includes a bG measurement graph set based on the type of diabetes management therapy associated with the account.
In further features, the second user interface includes a date range set based on the type of diabetes management therapy associated with the account.
In further features, the second user interface includes a calorie intake graph set based on the type of diabetes management therapy associated with the account.
In further features, the second user interface includes an exercise graph set based on the type of diabetes management therapy associated with the account.
In further features, the second user interface includes an insulin intake graph set based on the type of diabetes management therapy associated with the account.
In further features, the second user interface includes a statistical analysis of an average bG value versus a target bG value set based on the type of diabetes management therapy associated with the account.
In further features, the diabetes management data includes an amount of insulin administered via a syringe and does not include a bG measurement.
In further features, the diabetes management data includes an amount of insulin administered via an insulin pump and does not include a bG measurement.
In further features, the diabetes management data includes a carbohydrate intake and does not include a bG measurement.
In further features, the diabetes management data includes a calorie intake and does not include a bG measurement.
In further features, the diabetes management data includes advice given and does not include a bG measurement.
In further features, the method further includes: receiving, at the computing device, information for a health care professional's account; and using the diabetes management server, selectively enabling one or more users of the health care professional's account to access diabetes management data stored in the database in association with the account.
In further features, the method further includes, using the diabetes management server, identifying the health care professional's account based on the information for the health care professional's account.
In further features, the method further includes: displaying, using the computing device, a request for consent to enable the health care professional's account to access the diabetes management data stored in the database in association with the account; and using the diabetes management server, enabling the one or more users of the health care professional's account to access the diabetes management data in response to receipt of the consent by the diabetes management server.
In further features, the method further includes, using the diabetes management server, updating the field for the bG measurement of the bG measurement entry with a bG measurement input by a user to the computing device.
In further features, the method further includes, using the diabetes management server, storing an indicator with the bG measurement, the indicator indicating that the bG measurement was edited by the user.
In further features, the method further includes, using the computing device, transferring the diabetes management data from the diabetes management device to the diabetes management server without ever storing the diabetes management device anywhere within the computing device.
A diabetes management system is also disclosed. A computing device receives account creation information input by a user to the computing device. A diabetes management server: receives the account creation information from the computing device; and creates an account in a database based on the account creation information. A diabetes management device: is connected to the computing device wirelessly or by wire; and transmits diabetes management data stored in the diabetes management device to the computing device, wherein the diabetes management data does not include a blood glucose (bG) measurement. The computing device further transmits an indicator of the account and the diabetes management data to the diabetes management server. In response to receipt of the diabetes management data, the diabetes management server further: creates a bG measurement entry for the account in the database, leaves empty a field of the bG measurement entry for a bG measurement in the bG measurement entry based on the diabetes management data not including a bG measurement; and stores the diabetes management data in one or more respective fields of the bG measurement entry. The diabetes management server further generates a user interface for displaying data stored in the bG measurement entry and at least one other bG measurement entry that is associated with the account. The computing device further: accesses data stored in the database in association with the account; and displays the user interface including displaying the data stored in the bG measurement entry and the at least one other bG measurement entry that is associated with the account.
Further areas of applicability of the present disclosure will become apparent from the detailed description, the claims and the drawings. The detailed description and specific examples are intended for purposes of illustration only and are not intended to limit the scope of the disclosure.
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 numerals indicate corresponding parts throughout the several views of the drawings.
The DMS 10 may include generally a patient data system 12, a healthcare professional data system 14, a network 16, and at least one server computer 18. As will be explained in more detail below, the DMS 10 may be configured such that data and information is electronically sent to and received from the patient data system 12, the healthcare professional data system 14, and the server computer 18 via the network 16.
The diabetes management devices 28 are operable to send stored diabetes management data to at least one of the patient computing device 20 and the healthcare professional computing device 24. The diabetes management devices 28 may transmit stored diabetes management data to an external computing device by wire (e.g., Universal Serial Bus (USB)) via an I/O port or wirelessly, such as via by Bluetooth®, infrared (IR), or another suitable type of wireless communication.
Each diabetes management device 28 may be associated with a unique identifier or security code that attaches to any data transmitted by the diabetes management device. Accordingly, in this method of data transmission, the patient or other user may not be required to enter a username, password, or other security code prior to transmitting data via the network 16.
The patient data system 12 may include at least one patient computing device 20 operably connected to, and in communication with, the network 16 through a wired or wireless connection. By way of example, the patient computing device 20 may be a personal computing device or a mobile electronic device such as a tablet or a smartphone.
The patient computing device 20 may include at least one data input device, at least one processor, at least one storage device, and at least one output device. The data input devices may include a touchscreen, a keyboard, a mouse, a microphone, a hard-wired data port such as a USB port, and/or a wireless data transceiver such as a Bluetooth® transceiver. The processor is connected to the data input device(s), the storage device(s), and the output device(s). The storage device(s) may include memory, one or more hard drives, one or more disk drives, and/or one or more other suitable types of storage devices. The output devices include a display, a speaker, and/or other suitable output devices.
With reference to
The healthcare professional data system 14 includes at least one healthcare professional computing device 24 operably connected to, and in communication with, the network 16 through a wired or wireless connection. A health care professional (e.g., a physician, nurse, or other health care professional with access to the healthcare professional computing device 24) may utilize the network 16 to download, upload, and view diabetes management data stored by the server computer 18.
By way of example, the healthcare professional computing device 24 may be a personal computing device or a mobile electronic device such as a tablet or a smartphone. The healthcare professional computing device 24 may include at least one data input device, at least one processor, at least one storage device, and at least one output device. The data input devices may include a touchscreen, a keyboard, a mouse, a microphone, a hard-wired data port such as a USB port, and/or a wireless data transceiver such as a Bluetooth® transceiver. The processor is connected to the data input device(s), the storage device(s), and the output device(s). The storage device(s) may include memory, one or more hard drives, one or more disk drives, and/or one or more other suitable types of storage devices. The output devices include a display, a speaker, and/or other suitable output devices.
The server computer 18 may include at least one data input device, at least one processor, at least one storage device including a database 26, and at least one output device. The processor is connected to the storage device(s), the input device, and the output device.
The server computer 18 and the database 26 are operably connected to, and in communication with, the network 16 through a wired or wireless connection. The server computer 18 sends and receives diabetes management data to and from the patient data system 12 via the network 16. The server computer 18 stores diabetes management data received from the patient data system 12 in the database 26. The server computer 18 also processes diabetes management data stored in the database 26 and can transmit diabetes management data to the patient data system 12. As will be discussed below, data sent via the network 16 may be assigned to a unique patient account prior to being stored in the database 26.
The diabetes management device 28, such as a bG meter, transmits diabetes management data to a connected computing device (e.g., the patient computing device 20 or the health care professional computing device 24) wirelessly or by wire. The diabetes management device 28 may transmit diabetes management data to the connected computing device, for example, at regular user programmable intervals or in response to user input prompting transmission of the diabetes management data. Additionally or alternatively, the diabetes management device 28 may transmit diabetes management data to the connected computing device in real time as diabetes management data is received by the diabetes management device 28 (e.g., as bG measurements are taken or as insulin is administered), or when diabetes management data (e.g., bG measurements) reaches certain threshold levels. The threshold levels may be set by the patient and/or the healthcare professional.
With reference to
The system 30 may include a device transfer component 32. The device transfer component 32 may be stored on the server computer 18 for transmission through the network 16 and execution by the processors of the patient computing device 20 and the healthcare professional computing device 24. Installation of the device transfer component 32 onto the patient computing device 20 or the healthcare professional computing device 24 will allow that computing device to send and receive diabetes management data to and from a health management application 33 installed on the server computer 18. The device transfer component 32 may also be referred to as an application. A user of a computing device can download the device transfer component 32 from the server computer 18, for example, via a web browser 31.
When the diabetes management device 28 sends diabetes management data to the patient computing device 20 or the healthcare professional computing device 24, the device transfer component 32 passes the received data to the server computer 18 via the network 16. The device transfer component 32 does not store the received data in the device transfer component 32 or the computing device executing the device transfer component 32.
A medical device application 34 may be installed on the diabetes management device 28 to facilitate the receipt of diabetes management data by the diabetes management device 28 and the exchange of diabetes management data with the device transfer component 32. Diabetes management data sent via the device transfer component 32 may include an identifier code that is unique to the patient and/or diabetes management device 28 from which it was received.
Prior to transferring diabetes management data to or from the server computer 18, a user may be required to link or associate the diabetes management device 28 with a unique patient account created on the server computer 18. The device transfer component 32 may perform authentication with the diabetes management device 28. Once the device transfer component 32 authenticates the diabetes management device 28, the diabetes management device 28 may be assigned an authentication token. While an example including an authentication token will be discussed, another unique identifier may be used.
A user of a computing device can create a unique account with the server computer 18 via the device transfer component 32. Account creation is discussed further below. After downloading and executing the device transfer component 32, and allowing the diabetes management device 28 to communicate with the patient computing device 20, the diabetes management device's authentication token can be associated with the appropriate patient account. Once the diabetes management device's 28 authentication token has been assigned to the patient account, data and information can be transferred through the device transfer component 32 and assigned to the appropriate patient account in the database 26.
In an alternative embodiment, the device transfer component 32 may be assigned a unique identification code. Prior to transferring data and information from the diabetes management device 28 through the network 16, the user may be required to associate the device transfer component's 32 unique identification code with the patient's account. Data and information from the diabetes management device 28 can be linked to the device transfer component's 32 unique identification code prior to transmission through the network 16, and thus assigned to the appropriate patient account in the database 26.
After data has been transferred from the diabetes management device 28 to the patient account located on the server computer 18, the system 30 may allow such data to be further transferred from the patient account to authorized healthcare professional computing devices 24 and patient computing devices 20 via the device transfer component 32. Transfer of data from the patient account to a healthcare professional's computing device 24 may require linking the patient account with the device transfer component 32 installed on the healthcare professional computing device 24.
The system 30 may also allow a patient, healthcare professional, or other user to create customized reports related to stored diabetes management data and perform research with respect to diabetes management data stored within or outside of the system 30. In addition, the system 30 may be operable to provide data backup and restoration services with respect to data that may have been lost from the patient data system 12 or the healthcare professional data system 14.
With reference to
Prior to transferring data through the network 16 to the server computer 18, the user may be required to create a unique patient account and security credentials, such as a username and password, to ensure that the patient's diabetes management data is stored in a unique and secured storage location in the database 26. The user may also be required to associate, or link, the diabetes management device 28 authentication token with the patient account. Once the user has created the patient account and linked the diabetes management device 28 authentication code to the patient account, the user may be permitted to transfer data and information to and from the server computer 18 without otherwise logging into the patient account.
In one aspect of the DMS, access to the server computer 18 via the web browser 31 may allow a user to transmit data such as bG measurements, patient weight, meal information, and similar information, to the patient account in the database 26. In another aspect of the DMS, access to the server computer 18 via the web browser 31 may allow the user to create and view reports, graphs, and other information based at least in part on data transmitted from the user.
Communication between the patient data system 12, the healthcare professional data system 14, and the server computer 18 may utilize hypertext transfer protocol (HTTP) basic authentication in combination with a secure sockets layer (SSL) security protocol. Other communication and security protocols known in the art are also contemplated. Another example DMS is shown in
With reference to
In a second step, indicated by II, the user may utilize a web browser 31 to access the server computer 18 to download the device transfer component 32 onto the patient computing device 20.
In a third step, indicated by III, a user may register the diabetes management device 28 with at least one of the device transfer component 32 and the patient account. Registration of at least one diabetes management device 28 (or an application installed on a mobile computing device) with the device transfer component 32 and the patient account may be accomplished by first allowing the at least one diabetes management device 28 to communicate with the patient computing device 20. Each diabetes management device 28 may be assigned a unique identification code or authentication token that can be associated with the patient account, thus ensuring that data and information sent from the diabetes management device 28 is stored only in association with the patient account. Registration of the diabetes management device 28 with the device transfer component 32 and the patient account may also be accomplished by the user by directly entering the diabetes management device's identification code or authentication token directly into device transfer component 32 or a web browser 31.
In a fourth step, indicated at IV, a user may send diabetes management data from the diabetes management device 28 to the device transfer component 32. Data and information received from the diabetes management device 28 will include the identification code or authentication token assigned to the particular diabetes management. In this way, the DMS 10 can ensure the integrity of data and information sent to the patient account.
In a fifth step, indicated by V, the device transfer component 32 may send diabetes management data received from the diabetes management data device 28 to the server computer 18. The device transfer component 32 may not store or otherwise record the diabetes management data received from the diabetes management device 28. Rather, the device transfer component 32 may function as an intermediary between the diabetes management device 28 and the server computer 18, in facilitating the transfer of data and information therebetween. Data and information transferred from device transfer component 32 may be authenticated and stored in association with the patient account through the associated identification code or authentication token received from the diabetes management device 28.
In a sixth step, indicated at VI, data and information associated with the patient account in the database 26 may be transferred to at least one of the patient computing device 20 and the healthcare professional computing device 24 via the network 16. The transfer of diabetes management data associated with the patient account to the healthcare professional computing device 24 requires that the patient account first be linked with an account of the health care professional.
In various aspects, the present technology includes the creation and management of one or more web accounts integrated with the DMS 10. As used herein, the term “web account” or “web online account” includes an account, architecture, or collection of data that is controlled by or connected to another computer, server, or network, for example, through the internet.
A healthcare professional may create a web account through the DMS 10. For example, this may be accomplished using software or a link in the medical device application 34 installed on the diabetes management device 28. In other aspects, the healthcare provider can directly create an account using a web browser. When created via the web browser, the healthcare provider can import, load, or register multiple patients, as well as manage patients from the healthcare provider's account. Thus, a healthcare provider can manage many patients, and optionally other healthcare providers, within an account.
Additionally, a patient can create an account using a web browser and import the patient's records from the diabetes management system. In this regard, business rules may be used when importing the data to perform certain conversions, and to reduce errors. It should be understood that various end user license agreements (EULAs), voluntary consents, or the like may be incorporated or configured as part of the account.
The account can be configured with a data synchronization type. The data synchronization type can be, for example, to both send and receive diabetes management data from the database 26 or to only receive diabetes management data from the database 26. A connection is established with a server and database as shown in the GUI illustrated in
As shown in
Certain fields may be pre-selected, such as the country previously selected. User names are unique, passwords may have certain rules, and minimum age adjustments may be adjusted dynamically based on country selections.
When a user is authenticated, the system may display a unique screen title for each screen page, display a common header area, and display a common navigation area. Certain of the GUIs referenced herein and shown in the figures may be high resolution or low resolution, depending on the computer device being used.
As mentioned above, it may be beneficial to provide an end user license agreement for use of the diabetes management system and/or voluntary consents for the use or release of their data.
Once a user has created an account, the user may be asked whether the user would like to transmit data to upload diabetes management data to the database 26 in association with that account.
The GUIs of
The selected file may include, for example, personal information (e.g., name, birthdate, etc.), contact information (e.g., phone number, email, etc.), demographic data and therapy type, and measurements and records. For each patient having diabetes management data stored in the selected file, the user can select what types of diabetes management data should be uploaded.
Users can verify the correct file has been selected by checking the list of patients or patient data sets displayed in a window. If a user cancels the operation at this time, the dialog window may be closed without the data being processed, and may reveal a home screen.
Once data has been successfully imported, the user may be prompted to enter patient data.
As shown in
Files uploaded to the server computer 18 are written by diabetes management devices using a common data format (CDF). CDF is a diabetes care patient centric extensible markup language (XML) based data format defined for the DMS. The server computer 18 determines whether files uploaded to the server computer 18 comply with rules for uploaded files.
The server computer 18 also formats uploaded diabetes management data for use in a logbook. Discussion of the logbook is discussed further below. Regarding formatting uploaded diabetes management data for use in the logbook, the server computer 18 identifies different types of diabetes management data uploaded to the server computer 18 for storage in association with an account. One type of data includes bG measurements. A plurality of other types of data can be provided for each bG measurement taken and may help explain trends or other relevant bG measurement changes.
For example, other types of data include basal insulin dosage and insulin total daily dose (TDD), blood pressure (systolic and diastolic), hbA1c measurement, pulse, body temperature, weight, medication, bolus insulin advice given to the patient, whether that advice was accepted or not, amount of meal bolus insulin, and amount of correction bolus insulin. The other types of data can also include carbohydrate intake advice, whether that advice was accepted or not, corresponding insulin bolus, carbohydrates and calories, bG control data, energy level of the patient, emotional state of the patient, health state of the patient, event before and after data, events (e.g., exercise), one or more notes, and/or other data. Even one or more pieces of the data was not included in the uploaded file, the user can add and/or edit stored data.
For various different types of data identified in uploaded diabetes management data that are not bG measurements (e.g., insulin administered, carbohydrate intake, calorie intake, etc.), the server computer 18 creates bG measurement entries. The server computer 18 leaves fields for those bG measurements entries empty and stores the uploaded diabetes management data in association with the entries. When the account is later accessed, the user can therefore enter bG measurements that are left empty.
When accessing the account, the server computer 18 generates information to be displayed to the user via a computing device based on the bG measurement entries. For example, based on the bG measurement entries, the server computer 18 may generate one or more statistical values for display to the user.
At 158, the server computer 18 selects a piece of the diabetes management data and determines whether that piece of diabetes management data includes a bG measurement. Example types of diabetes management data that may or may not include a related bG measurement include, for example, an amount of insulin administered (e.g., by syringe or pump), a carbohydrate intake, a calorie intake, advice given (e.g., insulin, carbohydrate or calorie), and other types of diabetes management data. If 158 is true, the server computer 18 may continue with 162. If 158 is false, the server computer 18 may continue with 166.
At 162, the server computer 18 creates a new bG measurement entry for the account in the database 26. The server computer 18 also stores the bG measurement in a field for the bG measurement in the new bG measurement entry. The server computer 18 also stores other different types of related data to the bG measurement entry in fields for those types of data in the new bG measurement entry.
At 166, when the piece of diabetes management data does not include a bG measurement, the server computer 18 creates a new bG measurement entry for the account in the database 26. The server computer 18, however, leaves the field for a bG measurement in the new bG measurement entry blank. In this manner, a user of the account can later add a bG measurement into that bG measurement entry. The server computer 18 also stores other different types of related data to the bG measurement entry in fields for those types of data in the new bG measurement entry. As described further below, the server computer 18 generates user interfaces for displaying data for the account based on bG measurement entries. While the example of
Further description of rules that are applied by the server computer 18 will now be described. For example, the server computer 18 may not discard an entire uploaded file including diabetes management data if the uploaded file includes one or more elements that are not addressed under one or more rules. Before validating diabetes management data uploaded to it, the server computer 18 executes each transformation rule described below. However, the server computer 18 validates uploaded data as received unless a transformation is to be performed.
When the server computer 18 receives data that applies to one or more validation rules, the server computer 18 stores all data as received unless a transformation is to be performed. When the server computer 18 creates data, the server computer 18 stores logbook data so that the validation rules apply. When the server computer 18 receives data to be stored in the database 26, the server computer 18 validates that the following types of data are within predefined ranges and rejects data that falls outside of the predefined ranges: bG measurements and insulin pump bolus amounts; text fields; and dates.
When the server computer 18 receives data via an association with a personal (patient) account and the patient element of a piece of diabetes management data does not have an identifier (ID), the server computer 18 sets the IDs of the patient element to the IDs associated with the association that was used to send the diabetes management data. When the server computer 18 receives result data that does not include an ID, the server computer 18 creates a new data entry instance ID and assigns that new ID to the result. When the server computer 18 receives a patient event that does not have an ID, the server computer 18 creates a new data entry instance ID and assigns that new ID to the patient event. When the server computer 18 receives result comment data that does not include an ID, the server computer 18 creates a new data entry instance ID and assigns that new ID to the result comment. When the server computer 18 receives a diabetes management device flag that does not have an ID, the server computer 18 creates a new data entry instance ID and assigns that new ID to the device flag.
When the server computer 18 receives result data that is sent directly from a diabetes management device 28, the server computer 18 sets the ID of the patient element to the index ID patient from the account associated with the association that was used to send the result data. The server computer 18 moves device flags received in an uploaded file to a device flags portion associated with the account.
When the server computer 18 receives top level results with one of the following result types containing related results (i) syringe insulin, (ii) insulin pump bolus (e.g., standard, extended, or multiwave), (iii) carbohydrates or calories, (iv) advice (e.g., total bolus advice, carbohydrate advice), the server computer 18 moves any related results as related results under a new empty top level bG measurement and combines them on the same level as the original top level result. When the server computer 18 moves top level results under a new top level bG measurement and the original top level results contains one or more results qualifiers, the server computer 18 moves any results qualifiers that do not belong to that result type from the original top level result to the new empty top level bG measurement. When the server computer 18 moves top level results under a new top level bG measurement and the original top level results contains one or more patient events, the server computer 18 moves any patient events that are related to the original top level result to the new top level bG measurement. When the server computer 18 moves top level results under a new top level bG measurement and the original top level result contains a comment, the server computer 18 moves any result comment that is related to the original top level result to the new top level bG measurement. Top level bG measurements correspond to logbook entries. Diabetes management data stored under a top level bG measurement corresponds to one logbook entry.
When the server computer 18 moves top level results under an empty top level bG measurement, the server computer 18 stops processing an uploaded file if any other rules are violated.
When the server computer 18 receives syringe insulin data as a top level result, the server computer 18 moves the syringe insulin data to a new top level bG measurement. When the server computer 18 receives insulin pump bolus data of standard or extended type as a top level result, the server computer 18 moves that data to a new top level bG measurement.
When the server computer 18 receives multiwave insulin pump bolus results as a top level result, the server computer 18 moves an insulin pump bolus of type multiwave (standard part) and insulin pump bolus of type multiwave (extended part) that fulfill predetermined conditions, as related results under the same top level bG result. The predetermined conditions include being sent one after the other as top level results, both having the same result date, and having predetermined results qualifiers. When the server computer 18 receives multiwave insulin pump bolus results as a top-level result, the server computer 18 moves an insulin pump bolus of type multiwave (standard part) for which no corresponding extended part result has been received as related results under a new top level bG result and creates an additional related result for the missing extended part.
When the server computer 18 receives multiwave insulin pump bolus results as a top level result, the server computer 18 moves an insulin pump bolus of type multiwave (extended part) for which no corresponding standard part result has been received as related results under a new top level bG result and creates an additional related result for the missing standard part. When the server computer 18 receives multiwave insulin pump bolus results as a top level result, the server computer 18 will accept an insulin pump bolus of type multiwave (extended part) as a top level result and not move it as a related result under a new empty top level bG result. When the server computer 18 receives an insulin pump bolus as a top level result including additional result qualifiers, the server computer 18 moves any result qualifier included in a pump bolus other than predetermined types of qualifiers up to the empty top level (parent) bG result.
When the server computer 18 receives carbohydrate data as a top level result, the server computer 18 moves the carbohydrate data as a related result under a new top level bG result. When the server computer 18 receives calories data as a top level result, the server computer 18 moves the calories data as a related result under a new top level bG result. When the server computer 18 receives carbohydrate or calories data as a top level result including additional result qualifiers, the server computer 18 moves any included result qualifiers up to the empty top level (parent) bG result.
The server computer 18 may receive from a diabetes management device 28 total bolus advice data and/or carbohydrate advice data as top level results. In conjunction with sending total bolus advice data as a top level result, the server computer 18 may receive from a diabetes management device 28 related results including bG correction bolus data and/or meal correction bolus data.
When the server computer 18 receives total bolus advice data as a top level result, the server computer 18 moves the total advice data as a related result under a new top level bG result. When the server computer 18 receives total bolus advice data as a top level result and the total bolus advice data includes additional result qualifiers, the server computer 18 moves the included result qualifiers under the new top level bG result with the total bolus advice data.
When the server computer 18 receives total bolus advice data as a top level result along with a related bG correction bolus, the server computer 18 moves the total bolus advice data and the bG correction bolus as related results under the same top level bG result. When the server computer 18 receives total bolus advice data as a top level result along with a related meal correction bolus, the server computer 18 moves both the total bolus advice data and the meal correction bolus under the same top level bG result.
When the server computer 18 receives advised carbohydrate data as a top level result without any related results, the server computer 18 moves the advised carbohydrate data as a related result under a new top level bG result. When the server computer 18 receives advised carbohydrate data as a top level result along with one or more result qualifiers, the server computer 18 moves results qualifiers up to the (parent) top level bG result.
When a bG result is received, the server computer 18 removes flags included with the bG result that indicate that timing of the bG result was before or after a snack event.
When the server computer 18 receives a bG measurement flagged with an asterisk on a diabetes management device and the bG measurement does not already include a meal event flag, the server computer 18 replaces the meal event flag with the meal event that is assigned to the flag in the patient settings of the associated account. When the server computer 18 receives a bG measurement flagged with an asterisk on a diabetes management device and the bG measurement does include a meal event flag, the server computer 18 removes data from the bG measurement and continues. When the server computer 18 receives a bG measurement with any additional result qualifiers of a predetermined type, the server computer 18 removes predetermined data from the bG measurement and continues.
When the server computer 18 receives a global unique identifier (GUID) for a meal event flag from a diabetes management device and the bG measurement does not already include a meal event flag, the server computer 18 replaces the GUID based on the following table.
When the server computer 18 receives a GUID for a meal event flag from a diabetes management device 28 and the bG measurement does already include a meal event flag, the server computer 18 stores the meal event flag as is. When the server computer 18 receives a GUID for a meal event flag from a diabetes management device 28 and the GUID is for either for before or after a snack, the server computer 18 removes the meal event flag and continues. When the server computer 18 receives GUID for a meal event flag from a diabetes management device 28 and the meal event flag is set for fasting, the server computer 18 replaces the GUID with a meal event flag for fasting if the bG measurement does not include another meal event flag to be used for the replacement.
When the server computer 18 receives a GUID for energy level from a diabetes management device 28 and a bG measurement does not already include an energy level, the server computer 18 replaces the GUID for the energy level based on the table below.
When the server computer 18 receives a GUID for energy level from a diabetes management device 28 and a bG measurement already includes an energy level, the server computer 18 removes the GUID for the energy level and continues.
When the server computer 18 receives a GUID for meal size from a diabetes management device 28 and a bG measurement does not already include a meal size, the server computer 18 replaces the replaces the GUID for the meal size based on the table below.
When the server computer 18 receives a GUID for meal size from a diabetes management device 28 and a bG measurement does already include a meal size, the server computer 18 removes the GUID for the meal size and continues.
When the server computer 18 receives logbook assignment data with a reference to a non-bG result or a patient event that does not include a type attribute, the server computer 18 sets a missing reference type to a predetermined type, such as local. When the server computer 18 receives logbook assignment data with more than one medication, the server computer 18 keeps the first medication of the logbook assignment data and deletes the additional medication references from that logbook assignment, but keeps the medication references as independent entries.
When the server returns a CDF file as a reply to a service interface request, the server computer 18 includes data origin information in the CDF document including a URL, a name, and an identity. The data origin information may include an identifier of a last record loaded to the device to a device data client in a predetermined location in the CDF file. The data origin information may also include a date that the last record was loaded from the device to the device data client in a predetermined location in the CDF file. When the server computer 18 receives a CDF file from a diabetes management device or a device transfer component, the server computer 18 only accepts CDF files that have a device type, a model identifier, a model name, and a serial number.
When the server computer 18 receives a CDF file from a diabetes management device 28 or a device transfer component 32 via a device interface request, the server computer 18 only accepts data origin information that is consistent with the device associated with the association that is used to send the CDF file. The server computer 18 only accepts data from a device transfer component 32 if the device information in CDF file is identical with the device information of the association used to send the data. The serial number of a device should comply with predetermined rules.
A device type included in a CDF file of a bG meter should indicate bG meter. A device type included in a CDF file of an insulin pump should indicate insulin pump. A device type included in a CDF file of a device transfer component should indicate device transfer component.
When the server computer 18 receives a CDF file in the context of a data synchronization function or a data import/upload function, the server computer 18 only accepts data origin information in a predetermined format. Data entered manually into a diabetes management device 28 and included in a CDF file should include an indicator that the data was entered manually. Data that was generated by a diabetes management device 28, such as advice information, should include an indicator that the data was generated by the device.
The server computer 18 accepts data definitions in CDF files for predefined emotional states, predefined and custom health states, predefined and custom exercise types, predefined and custom medications, predefined and custom insulin types, and predefined device warnings. The server computer 18 also accepts data definitions in CDF files for basal profiles.
The server computer 18 does not accept user-defined (custom) data definitions for energy levels, meals, control, bolus type, basal flag, basal temperature flags, statistics, advice, and timing. The server computer 18 does not accept definitions for event qualifier types including severity, intensity, and body regulation.
The server computer 18 does not accept definitions for result qualifiers that include custom names that are longer than a predetermined length, such as longer than 128 characters. The server computer 18 does not accept definitions for event qualifiers that include custom names that are longer than a predetermined length, such as longer than 128 characters. The server computer 18 does not accept definitions for medications that include custom names that are longer than a predetermined length, such as longer than 30 characters. The server computer 18 does not accept data definitions for custom health care professionals, custom ethnicity types, custom data types, and custom device parameter types.
For the purpose of data identify and synchronization of changes in data records, CDF-based data messages include root and extension attributes on elements that represent globally unique identification. For example, a patient, a result, a result comment, a patient event, or a device flag may have an object identifier in the following attributes: root—typically object identifier (OID) assigned for system or database instance; and extension—typically a unique ID of the record in the system or database instance.
When the originating system has the capacity to create and maintain universally unique identifiers for data records, the system that creates data items should assign root and extension attributes. Each participating system may remember the root and extension received for records from other participating systems. Each participating system may use the original root and extension when communicating data elements with any other participating system. The server computer 18 does not accept elements under a data definition portion of a CDF file that includes root or extension attributes.
When a user accesses their account via the server computer 18 and manually enters data, the server computer 18 assigns a new unique identifier to the manually entered data. OIDs may be assigned based on a manufacturer of the product. The server computer 18 only accepts root and extension attributes if they are correctly formatted, such as using a sequence of integer values separated by dots. Correct formatting may be defined by, for example, a HL7 OID convention. The server computer 18 may expect that transmitting devices convert for proper formatting.
The server computer 18 accepts results and patient events that include valid date and time information. When the server computer 18 receives data without date and time information, the server computer 18 may store the data in the database 26, but may mark that data as either having an invalid date and/or time or mark the data for deletion.
The server computer 18 may accept results and patent events including date and time information having a predetermined format, such as a time and date standard of the international organization for standardization (ISO). For example, the predetermined format may be YYYY-MM-DDThh:mm:ss, where Y indicates year, M indicates month, D indicates date, h indicates hour, m indicates minute, and s indicates second. The predetermined format may also include an optional time zone designator. In various implementations, the time and date information may be in separate data elements. If provided in separate data elements, the server computer 18 may store data missing one or more of the pieces of date and time information, but mark that data with an invalid date and/or time. The server computer 18 may reject data that includes multiple pieces of date and time in one element but separate pieces of date and time information in separate elements (e.g., YYYY-MM-DD in one data element and hh, mm, and ss in separate data elements or YYYY, MM, and DD in separate data elements while hh-mm-ss are in one data element).
Every result or patient event has data elements including an “is edited” element, an “is annotated” element, and may include a change attribute. The root, extension, and change attributes can be used to given an element a unique name to be able to identify that element afterwards and to indicate if an already existing element has been changed or deleted.
For example, when the server computer 18 receives data, a patient, result, result comment, patient event, or device flag may have a change attribute to create, update, or delete data objects. New may indicate a request to create a new data object. Updated may indicate a request to update an already existing data object. Deleted may indicate a request to delete an already existing data object. Change may indicate a request to update an already existing data object (e.g., change down for the result if the related result command should be updated). The server computer 18 may only accept data objects with a change attribute if the data object also includes valid identifier in the root and extension attributes. The server computer 18 ignores change attributes for data definition elements.
For new data objects to be stored in the database 26, the sending system sets the change attribute to new. For data objects already stored in the database 26 that need to be updated, the sending system sets the change attribute to updated. For data objects already stored in the database 26 that need to be deleted, the sending system sets the change attribute to delete. For data objects already stored in the database 26 for which one or more related objects need to be updated, the sending system sets the change attribute to change down.
The server computer 18 rejects objects with the change element set to undeleted. The server computer 18 does not return an error to a sending system of a data object is ignored by the server computer 18 because a request by the sending system is a duplicate or violates a rule. The server computer 18 only accepts a request to delete a bG result that is part of a structure test if the structure test is also deleted.
When the server computer 18 receives data via an association with a personal (patient) account and the patient element does not have an identifier, the server computer 18 only accepts the patient data if the change attribute is set to change down.
For new data to be stored in the database 26, the sending system sets the “is edited” and “is annotated” flags/elements for that data to “No.” This is regardless of the data source, regardless of whether it was created manually or downloaded from a diabetes management device, and regardless of whether it is a top level result or a related result. When the data value of data stored in the database 26 is changed, the server computer 18 changes that data's “is edited” element to “Yes” to indicate that it has changed. The server computer 18 may leave the “is edited” element of a parent bG result set to “No” when only a related result is updated.
For exercise data, the server computer 18 may set the “is edited” element to “Yes” if the exercise type, duration, or intensity has been changed. The server computer 18 may leave the “is edited” element of exercise data set to “No” if only a related exercise element is changed.
Regarding the “is annotated” element, changes in relates results of an event affect the “is annotated” element, while the “is edited” element will remain unchanged. For example, when an already existing bG result is stored, the server computer 18 changes the “is annotated” element from “No” to “Yes” when one or more related results are added for that bG result, such as insulin bolus, carbohydrates, and/or calories. The server computer 18 changes the “is annotated” element from “Yes” to “No” when all related results are removed from a bG result.
When an already existing bG result is stored, the server computer 18 changes the “is annotated” element from “No” to “Yes” when one or more result qualifiers are added, updated, or removed for that bG result. When an already existing bG result is stored, the server computer 18 changes the “is annotated” element from “No” to “Yes” when one or more comments are added, updated, or removed for that bG result. For existing results other than bG results, the server computer 18 may maintain the “is annotated” element for those results at “No” when one or more comments are added, updated, or removed for that result.
The server computer 18 does not accept any data when a client uses a device results option to send data to the server computer 18 under a results element and under a patient element of the same CDF file. The server computer 18 does not accept any data of a CDF file if the CDF file includes any of the following elements: patient medical data, patient personal data, blocks of time, groups, work week, external patient identifiers, patient identify, primary health care professional, health care professional, devices, or therapies. When a client sends health data to a personal account using a patient option, the server computer 18 only accepts data if the patient ID provided in the root, extension, and global ID elements matches the ID of the patient associated with the personal account that was returned to the client during the create associations process.
The server computer 18 accepts only the following results as top level results: bG results, basal insulin from an insulin pump, vital signs and lab analytics, and total daily dose. The server computer 18 may accept the extended part of a multiwave bolus as a top level result if it includes a stop qualifier.
The server computer 18 only accepts medication events as top level patient events. The server computer 18 may accept related results for a top level result when the top level result is either a bG result or a blood pressure result. The server computer 18 does not accept results or patient events that include a visitation note, and does not accept results that include an add on value.
The server computer 18 expects that bG results will include the following data elements and values: an indicator that it is a measurement; an indicator that the measurement is of bG; the bG value; a date and time that the value was measured; an indicator of the device that measured the bG; a “has value” element; and the “is edited” and “is annotated” element. The server computer 18 rejects bG results that includes a duration, a slot ID, or an indicator of administered medication.
bG results may include result qualifiers for: bG control indicator; a high or low bG indicator; an out of sequence indicator; a flagged with an asterisk on the device indicator; a results flag from the device; a predefined meal event indicator; a predefined emotional state indicator; a predefined or custom health state indicator; a predefined energy level indicator; and a predefined or custom device warning indicator. The server computer 18 may reject bG results that include a results qualifier other than those listed above. The server computer 18 may also reject an empty bG result that serves as a grouping element and has no bG value but does have one or more related results. The server computer 18 may accept related results to a bG result including carbohydrates related results, calories related results, insulin bolus related results, and advice (bolus and carbohydrate) related results.
A bG result may include exactly one meal time event as a result qualifier. The meal time event may be before a meal, after a meal, before breakfast, after breakfast, before lunch, after lunch, before tea time, after tea time, before dinner, after dinner, bedtime, midsleep, fasting, or other.
When a bG result has been downloaded from a diabetes management device 28, a bG result may include one or more results flags from the device. The server computer 18 may ignore a bG result and skip it and all related results when the bG results includes a deleted or not set result flag.
A control bG result includes a control indicator, and may include one of the following control levels: control level 1, control level 2, or control level 3. The server computer 18 rejects results other than bG results that include a control indicator.
A bG result with a HI indicator also includes a result qualifier indicating that the bG value of that bG result is above a predetermined range. The server computer 18 rejects bG results that include both a HI and a LO indicator. The server computer 18 rejects results other than bG results that include HI or LO indicators. A bG result with a LO indicator also includes a result qualifier indicating that the bG value of that bG result is below the predetermined range. The server computer 18 also rejects results other than bG results that include an out of sequence indicator.
bG results may also include one or more additional results flags from the diabetes management device 28 stored as result qualifiers, such as used drum, expired strips, invalid result, or other's result. The server computer 18 rejects results other than bG results that include one of these additional results flags.
A bG result may include information about the emotional state of the patient in the form of a result qualifier, such as happy, sad, confused, guided, scared, calm, supported, frustrated, worried, or positive. The server computer 18 rejects bG results including more than one emotional state.
A bG result may include a predefined health state, such as illness, stress, or premenstrual. A bG result may include a user defined health state using a custom result qualifier. The server computer 18 rejects bG results having improperly defined health states.
A bG result may include a predefined energy level, such as low, medium-low, medium, medium-high, or high. The server computer 18 rejects bG results having an energy level that is not one of the predetermined energy levels or that has multiple energy levels.
A bG result may include an additional comment. The server computer 18 may reject comments that are longer than a predetermined length, such as 300 characters.
The server computer 18 accepts insulin bolus results having one of the following types: syringe insulin bolus 1, syringe insulin bolus 2, syringe insulin bolus 3, or insulin pump bolus. The server computer 18 only accepts insulin bolus as related results of a bG result. The server computer 18 accepts insulin bolus results that are related to empty bG results.
Insulin bolus results may include a predetermined type of insulin, such as 10/90, 20/80, 25/75, 30/70, 40/60, 50/50, 60/40, 70/30, 75/25, 80/20, 90/10, Apidra, Glargine, Humalog, Humalog Mix 25, Humalog mix 50, Lantus, Lente, Levemir, NPH, Novamix 30, Novolog, NovoRapid, regular, Ultralente, Generic Bolus, or Generic Basal. Insulin bolus results may alternatively include a user defined insulin type.
Syringe insulin bolus 1 results include the following elements and values: an indicator that the value is a measurement; an indicator that the data is an insulin dosage; the amount of the dosage; a slot ID (slot 1); a date and time of the insulin intake; a type of device that measured the insulin; a “has value” element, and “is edited” and “is annotated” data elements. Syringe insulin bolus 2 results include the following elements and values: an indicator that the value is a measurement; an indicator that the data is an insulin dosage; the amount of the dosage; a slot ID (slot 2); a date and time of the insulin intake; a type of device that measured the insulin; a “has value” element, and “is edited” and “is annotated” data elements. Syringe insulin bolus 3 results include the following elements and values: an indicator that the value is a measurement; an indicator that the data is an insulin dosage; the amount of the dosage; a slot ID (slot 3); a date and time of the insulin intake; a type of device that measured the insulin; a “has value” element, and “is edited” and “is annotated” data elements. The server computer 18 may reject syringe insulin bolus results that include a duration, results qualifiers, or patient events.
The server computer 18 accepts the following types of pump bolus results: standard bolus, extended bolus, and multiwave bolus. The server computer 18 rejects pump bolus that include both a start and a stop qualifier. A pump bolus may include a result qualifier indicating a meter command indicating that a remote controller (remote to the pump) initiated the bolus on the insulin pump.
A standard insulin bolus result includes the following elements and values: an indicator of a standard bolus insulin injection; the amount of the dosage; a slot ID; a date and time of the insulin intake; a type of device that measured the insulin; a “has value” element; and “is edited” and “is annotated” data elements. The server computer 18 rejects standard bolus insulin results that include a duration, a slot ID, or patient events.
An extended insulin bolus result includes the following elements and values: an indicator of an extended bolus insulin injection; the amount of the dosage; a slot ID; a date and time of the insulin intake; a type of device that measured the insulin; a “has value” element; and “is edited” and “is annotated” data elements. An extended bolus result also includes a start qualifier or a stop qualifier. The server computer 18 rejects extended bolus insulin results that include a slot ID or patient events.
A multiwave bolus result includes both a standard part (result) and an extended part (result). A multiwave bolus standard part includes the following elements and values: an indicator of multiwave insulin injection; the amount of the dosage; a slot ID; a date and time of the insulin intake; a type of device that measured the insulin; a “has value” element; and “is edited” and “is annotated” data elements. A multiwave bolus extended part includes the following elements and values: an indicator of multiwave insulin injection; the amount of the dosage; a slot ID; a date and time of the insulin intake; a type of device that measured the insulin; a “has value” element; and “is edited” and “is annotated” data elements. The server computer 18 rejects multiwave bolus results that include different types of insulin administered. The server computer 18 rejects multiwave bolus standard results that include a duration, a slot ID, or patient events. The server computer 18 rejects multiwave bolus extended results that include a slot ID or patient events.
The server computer 18 accepts only the following basal insulin information: basal rate; and temporary basal (start or stop event). The server computer 18 only accepts basal rates and temporary basal information sent as top level results. The server computer 18 rejects basal insulin profile names that are longer than a predetermined length, such as 128 characters.
A basal rate includes the following elements and values: an indicator of basal injection; the rate of the dosage; a duration of the dosage; a date and time of the insulin intake; a type of device that measured the insulin; a “has value” element; and “is edited” and “is annotated” data elements. A basal rate may also include profile information. The server computer 18 may reject basal rate information that includes a slot ID, administered medication, or patient events.
The server computer 18 accepts the following types of temporary basal information: temporary basal start events; and temporary basal stop events. A temporary basal start event includes the following elements and values: an indicator of temporary basal event; a temporary factor for increasing or decreasing the basal rate; a duration of the temporary increase or decrease; a date and time of the temporary change; a type of device that the temporary data came from; a “has value” element; and “is edited” and “is annotated” data elements. A temporary basal stop event includes the following elements and values: an indicator of a temporary basal event; a temporary factor for increasing or decreasing the basal rate; a duration of the temporary increase or decrease; a date and time of the temporary change; a type of device that the temporary data came from; a “has value” element; and “is edited” and “is annotated” data elements. Temporary basal information may include profile data.
The server computer 18 rejects temporary basal information that includes a slot ID, administered medication, or patient events. Additionally, the state date and time of the temporary basal state event plus the duration of the temporary event should be consistent with the stop date and time of the temporary basal event. Insulin results from pumps may include a result qualifier from the pump indicating that the pump was affected by a pause. The server computer 18 rejects other types of data including an indicator that the device was affected by a pause.
A total daily dose result sent by an insulin pump includes the following elements and values: an indicator that the data is a total daily dose; the amount of the total daily dose as calculated by the insulin pump; the end of the day the TDD was calculated for; the type of pump that the TDD came from; a “has value” element; and “is edited” and “is annotated” data elements. The server computer 18 rejects total daily dose results that include a slot ID, a duration, result qualifiers, administered medication, or patient events.
The server computer 18 accepts only the following advice types: bolus advice, including total advised bolus advice, bG correction bolus advice, and meal correction bolus advice; and advised carbohydrates. The server computer 18 rejects advice information that includes one or more different types of bolus advice and advised carbohydrates advice. The server computer 18 accepts advice information only as related results to a bG result.
A total advised bolus result includes the following elements and values: an indicator of advice regarding total bolus dosage; amount of insulin advised; a type of device that the advice came from; a “has value” element; and “is edited” and “is annotated” data elements. A total advised bolus result may include an indicator of whether the advice was accepted or changed. A total advised bolus result may include an indicator of whether the bolus type was standard, extended, multiwave, or another suitable type. The server computer 18 only accepts bolus advice that includes a bolus type if the bolus type is the same for all related bolus advice results. The server computer 18 rejects bolus advice that includes a duration, a slot ID, administered medication, patient events, or one or more predetermined types of result qualifiers. A total advised bolus result may include information about a type of bolus.
A bG correction bolus result includes the following elements and values: an indicator of advice regarding for a bG correction bolus; amount of insulin advised; a type of device that the advice came from; a “has value” element; and “is edited” and “is annotated” data elements. A bG correction bolus result may include an indicator of whether the advice was accepted or changed. A bG correction bolus result may include an indicator of whether the bolus type was standard, extended, multiwave, or another suitable type. The server computer 18 rejects bG correction bolus results that include a duration, a slot ID, administered medication, patient events, or one or more predetermined types of result qualifiers. A bG correction bolus result may include information about a type of bolus.
A meal correction bolus result includes the following elements and values: an indicator of advice regarding for a meal correction bolus; amount of insulin advised; a type of device that the advice came from; a “has value” element; and “is edited” and “is annotated” data elements. A meal correction bolus result may include an indicator of whether the advice was accepted or changed. A meal correction bolus result may include an indicator of whether the bolus type was standard, extended, multiwave, or another suitable type. The server computer 18 rejects meal correction bolus results that include a duration, a slot ID, administered medication, patient events, or one or more predetermined types of result qualifiers. A meal correction bolus result may include information about a type of bolus.
An advised carbohydrates result includes the following elements and values: an indicator of advice regarding for carbohydrate intake; amount of carbohydrates advised; a type of device that the advice came from; a “has value” element; and “is edited” and “is annotated” data elements. An advised carbohydrates result may include an indicator of whether the advice was accepted or changed. The server computer 18 rejects advised carbohydrates results that include a duration, a slot ID, administered medication, patient events, or one or more predetermined types of result qualifiers.
The server only accepts one of the following meal information elements related to the same bG result: carbohydrates; meal size; and calories. The server computer 18 accepts carbohydrate and calories results that are related to an empty bG result. For an empty bG result, the bG value is set to zero.
A carbohydrates result includes the following elements and values: an indicator of carbohydrate intake; amount of carbohydrates; a date and time of the carbohydrate intake; a type of device that the result came from; a “has value” element; and “is edited” and “is annotated” data elements. The server computer 18 rejects carbohydrates results that include a duration, a slot ID, administered medication, patient events, or one or more predetermined types of result qualifiers.
A meal size result may include a predefined meal size, such as none, small, medium, or large.
A calories result includes the following elements and values: an indicator of calorie intake; amount of calories taken; a date and time of the calorie intake; a type of device that the result came from; a “has value” element; and “is edited” and “is annotated” data elements. The server computer 18 rejects calories results that include a duration, a slot ID, administered medication, patient events, or one or more predetermined types of result qualifiers.
The server computer 18 accepts only exercise results that are patient events of bG results. An exercise result may include one of the following predetermined types of exercise results: walking; running; swimming; bicycling; and weight lifting. An exercise result may alternatively include a user customized exercise type. An exercise result includes the following elements and values; time and date of the exercise; and type of device that the result came from. The server computer 18 rejects exercise results that include event attributes, recurrence, or prescribed medication. An exercise result may include a duration and/or an intensity level. The server computer 18 rejects exercise results with more than one intensity level. The server computer 18 rejects exercise results including more than one exercise type.
The server computer 18 rejects patient events that include one of the following event types: education; office visit; and complication. The server computer 18 only accepts medication results if the patient event was sent as a top level patient event and not part of a result. A medication event includes the following elements and values: a date and time that the medication was taken; the type of device that the result came from; a GUID for the pharmaceutical; a recurrence/interval indicator; a recurrence start date; an indicator of a medication result; a “has value” element; and “is edited” and “is annotated” data elements.
A medication event may also include a recurrence end date. The server computer 18 rejects medication events that include a duration or event qualifiers. A medication event may also include a medication dosage and/or a comment related to the medication. The pharmaceutical may be customized. The server computer 18 rejects medication events that include more than one pharmaceutical.
When exchanging data, the server computer 18 only accepts the following vital signs and lab results: weight; temperature; heart rate; blood pressure; and A1C. The server computer 18 only accepts a weight if the weight result is sent as a top level result.
A weight result includes the following elements and values: an indicator of a weight measurement; the weight; a date and time of the measurement; a type of device that the result came from; a “has value” element; and “is edited” and “is annotated” data elements. The server computer 18 rejects a weight result that includes a duration, a slot ID, results qualifiers, administered medication, or patient events.
The server computer 18 only accepts temperature results sent as top level results. A temperature result includes the following elements and values: an indicator of a temperature measurement; the temperature; a date and time of the measurement; a type of device that the result came from; a “has value” element; and “is edited” and “is annotated” data elements. The server computer 18 rejects a temperature result that includes a duration, a slot ID, results qualifiers, administered medication, or patient events.
The server computer 18 only accepts heart rate results sent as top level results. A heart rate result includes the following elements and values: an indicator of a heart rate measurement; the heart rate; a date and time of the measurement; a type of device that the result came from; a “has value” element; and “is edited” and “is annotated” data elements. The server computer 18 rejects a heart rate result that includes a duration, a slot ID, results qualifiers, administered medication, or patient events.
The server computer 18 only accepts systolic blood pressure results sent as top level results. The server computer 18 only accepts diastolic blood pressure results as related results to a systolic blood pressure result. A systolic blood pressure result includes the following elements and values: an indicator of a systolic blood pressure measurement; the systolic blood pressure; a date and time of the measurement; a type of device that the result came from; a “has value” element; and “is edited” and “is annotated” data elements. A diastolic blood pressure result includes the following elements and values: an indicator of a diastolic blood pressure measurement; the diastolic blood pressure; a date and time of the measurement; a type of device that the result came from; a “has value” element; and “is edited” and “is annotated” data elements. The server computer 18 rejects systolic blood pressure results that do not include a related diastolic blood pressure result. The server computer 18 rejects a blood pressure result that includes a duration, a slot ID, results qualifiers, administered medication, or patient events.
The server computer 18 only accepts A1C results sent as top level results. An A1C result includes the following elements and values: an indicator of an A1C measurement; the A1C; a date and time of the measurement; a type of device that the result came from; a “has value” element; and “is edited” and “is annotated” data elements. The server computer 18 rejects an A1C result that includes a duration, a slot ID, results qualifiers, administered medication, or patient events.
The application of the above rules by the server computer 18 ensures that data can be presented to a user based on the data stored in association with their account in an orderly fashion. Also, the user can access their account and edit, add, remove, or update data stored in association with their account.
In various aspects, the present technology provides that a patient can share data, or electronic medical records, with a healthcare professional. The term electronic medical record may refer to records of health related information on an individual or patient that is created, gathered, managed, and consulted by licensed clinicians and staff from a single organization who are involved in the individual's health and care. Electronic medical records may also be referred to or known as computer-based patient records or electronic health records.
The particular data that is shared according to the present technology may include logbook records and device settings. Electronic medical record data that is shared may include any valid electronic medical data such as blood glucose, hemoglobin A1C, and other typical lab tests, etc., such as described above.
For example, the server computer 18 can send an email inviting the patient to send an invitation to a healthcare provider. Thereafter, the patient can send an invitation to the healthcare provider to receive the patient's stored data. The server computer 18 can accept an invitation in certain aspects. In other aspects, the server computer 18 can add patients during an invitation mapping process.
The server computer 18 may search for health care professionals based on the name input by the patient. If the office name does not exist, an error message may inform the user that the office name does not exist. If a personal account is already shared with a health care professional's account associated with the office name, an error message may also be provided indicating the same.
If there are no validation errors, selecting an “OK” button may open a separate page asking the user to confirm the request for sharing. Leaving the field empty may prompt the user to provide the requested confirmation. Selecting the “cancel” button will end the process and close any pop-up box that may have been introduced.
The user has the ability to delete a healthcare professional from the list, for example, by selecting the “X” at the end of each row as shown in
The tables on the left side of
A user can sort by the first or last name, or they can search by first or last name. Below the table, more details may be provided regarding a patient that is selected. The table on the right may indicate all patients that already exist in the healthcare provider account. Based on a matching algorithm, best matches (to the patient selected on the left) are first listed. A user has to select the patient that has to be linked to the patient on the left side. The columns in the table may be formatted as desired. Boxes presented below the table may provide additional details regarding the selected patient. If the primary information in both tables is not sufficient to identify the correct patient, the information in the boxes may be of assistance.
Selecting “link data” option button may open a confirmation GUI as shown in
If there are no further patients to link, the user may be guided to a “Manage Connections” interface as shown in
By selecting the “delete this device” option, a GUI is opened asking a user to confirm that all associations to this device should be removed. Notably, this does not delete the data, but rather the link. When a user deletes the last existing link to a device, the panel for this device may be removed from the page as well. A separate download link may be provided for every available and installable client class in the system. If no download file is available, the panel may not be displayed.
The server computer 18 also provides an electronic “logbook” feature, where the healthcare provider and/or patient may use a logbook to visualize diabetes management data using user defined lists, filtering (e.g., date range, bG level, insulin, and advice) along with the ability to add and modify entries. The logbook may display images coordinated with other related DMSs. Various trend and other statistical reports may be generated that provide a visual representation of data over a selected time period and can be configured by date range, all data/flagged data, connected/averages along with the capability for drilling down into the data.
A standard full day report may provide selected data over a 24 hour period that can be dynamically viewed by scatter/aligned and flagged/unflagged as a graph, statistics, and drill down. As opposed to a traditional 24 hour period beginning at 12:01 and ending at 12:00, the 24 hour period of a standard day may be user configurable. In this manner, individuals having different schedules (e.g., working night shift) can have data displayed in similar formats despite their different daily schedules.
A standard week report may provide selected data over a number of standard days (e.g., up to seven) that can be dynamically viewed as scatter/aligned and flagged/unflagged data as represented in a graph, statistics, and a drill down format. A three-day profile type report may be used for structured testing or for viewing with the days (either in an overlaid or sequential format) as a graph, statistics, or a drill down format.
The logbook may include features such as the creation of trend reports. Trend reports may include the ability to graph statistics and provide other views, in addition to drilling down to additional data. The trend reports may provide a view of selected data over a specified time period. The trend reports may be configurable to include Date Ranges, All Data/Flagged Data, Data that includes bG, Carbs, Insulin, Weight, etc., and Connected/Average data. The ability to print the reports in specific formats, such as Adobe PDF, may also be provided.
In a graph view, the dot or bar is still highlighted to give the user a visual clue as to which value was selected before. Selecting a different dot keeps the drill down displayed, but updates the contents to the selected value. When selecting a content module, the graph/table view is also updated. In a table view, the selected value is still highlighted. As shown by reference number (2) of
The logbook may include features such as the creation of standard day reports. Standard day reports may include the ability to graph statistics and provide other views, in addition to drilling down to additional data. The standard day reports may provide a view of selected data over a 24 hour time period. As described above, the times defining the 24 hour period may be user set. The standard day reports may be scattered or aligned, configurable to include Date Ranges, All Data/Flagged Data, Days of the week. Data may include bG, carbs, insulin, etc. The ability to print the reports in specific formats, such as Adobe PDF, may also be provided.
The logbook may further include features such as the creation of standard week reports. Standard week reports may include the ability to graph statistics and provide other views, in addition to drilling down to additional data. The standard week reports may provide a view of selected data up to a 7 day time period. The standard week reports may be scattered or aligned, configurable to include Date Ranges, All Data/Flagged Data, Days of the week. Data may include bG, carbs, insulin, etc. The ability to print the reports in specific formats, such as Adobe PDF, may also be provided.
The logbook may further include features such as the creation of 3-day profile reports with a 3-day structured test. These reports may include the ability to graph statistics and provide other views, in addition to drilling down to additional data. The 3-day profile reports may provide a view of selected data up to a 72 hour (x-axis) time period and a 24 hour (x-axis) overlay. The 3-day profile reports may be scattered or aligned, configurable to include Day selections (Day 1, 2, 3, and all). Data may include bG, carbs, insulin, etc. The ability to print the reports in specific formats, such as Adobe® PDF, may also be provided.
The logbook may further include features such as the creation of patient summary reports. Patient summary reports may provide a quick overview of a patient's diabetes management data. The patient summary reports may provide a view of selected diabetes management data configurable for a date range, option for device settings, advice statistics, and pump statistics. The patient summary reports may include trend graphs, statistical analysis, advice statistics, pump statistics, and device settings. The ability to print the reports in specific formats, such as Adobe® PDF, may also be provided.
The logbook may further include features such as the creation of 15 day side-by-side reports, and settings reports. The ability to print these reports in specific formats, such as Adobe® PDF, may also be provided.
The server computer 18 also provides dynamic home page setting for both health care professional and patient accounts. For example, the server computer 18 provides a health care professional “home page” that includes dynamic information set based upon current account information including getting started areas, patients list, pending invitations, pending device associations/links, system messages, product messages, and statistical analysis. The server computer 18 provides also provides a patient “home page” that includes dynamic information set based upon patient's diabetes related settings (diabetes type, therapy type, amount of diabetes management data uploaded, types of diabetes management data uploaded, etc.) and includes getting started, graphs (trend and standard day), analysis, and Life Stream. For both the healthcare provider and patient accounts, the server computer 18 provides contextual navigation from the home page to reports.
The server computer 18 sets the home page displayed for an account based on the following tables.
In various aspects, the user may be guided to start using their device by downloading a software plug-in for use with a Windows®, Mac®, or other operating system. The user may also be guided to start managing their patients. Selecting this option leads the user to the patient management page. The user may then be guided to manage their account and additional users via a user management page.
One user's goal may be to quickly get to patient information. As shown in
Reference number (4) illustrates a representative of a list of patients, which may be sorted by most recent update/when they were created (if there has never been an update from data sharing or devices). Reference number (6) indicates that the user can change how many entries per page are shown in the table. This area also shows how many total patients are in the account. Reference number (7) indicates how many total open invitations are in the account, and the user can also change how many entries are shown in this table. Reference number (8) indicates a list of open (not yet accepted or declined) invitations, sorted by date. A user can initiate a search of entries in the table by entering a query at the top row. For example, reference number (9) illustrates a search aspect for the names of patients. Various marketing messages can be provided at the bottom of the page, for example, at reference number (10).
As shown in
With specific reference to
Reference number (3) provides what may be referred to as a “user encouragement zone.” The user may be guided to start using their device by downloading a plug-in application for their operating system, such as Windows®, Mac®, or other operating system. Selecting a picture icon may open a user interface showing a typical example of an “active Life Stream.”
Reference number (4) indicates an “Analyze your Data” feature. Simplified text may be provided, explaining which content is displayed in this section after uploading data, and also mentioning the advantages of this action. Selecting the picture expands the view, showing a typical example of an analyzing section.
Reference number (5) indicates a “View your Data” feature. Simplified text may be provided, explaining which content (blood glucose values) is displayed in this section after uploading data, and also mentioning the advantages of this action. In the background, time blocks may already be displayed.
Reference number (6) indicates an example marketing message, and reference number (7) indicates a hyperlink that may be linked to the Digital Distribution Portal.
Reference number (2) illustrates an indicator showing the number or device associations that were added. Upon selecting the menu, the “Devices” page is displayed and the indicator may be removed. Reference number (3) illustrates an update within a patient profile box. The patient profile box may display the last visit (date/time) and last uploaded data (date/time). The patient profile box may also include a message for the user to share their diabetes management data. By selecting the “Share data” hyperlink, the user gets to the section Profile >“Share my data” where he can start the process. After selecting the “X,” this link is deactivated and not displayed any longer.
Reference number (5) illustrates the displaying of various data. After uploading data, a “Life Stream” shows tracked/measured values for the time range (that depends on the selected therapy type(s)). The “Life Stream” is always showing the latest data on the right; navigating to the left, older values are displayed. The “analyze” section of the user interface is active. The bG values are typically illustrated as dots. Characteristics of the graph displayed are dependent on the selected therapy type(s), as discussed above.
Home pages for patient accounts may further include features such as the creation of patient summary reports. Patient summary reports may provide a quick overview of a patient's information. The patient summary reports may provide a view of selected data configurable for a date range, option for device settings, advice statistics, and pump statistics. The patient summary reports may include trend graphs, statistical analysis, advice statistics, pump statistics, and device settings. The ability to print the reports in specific formats, such as Adobe PDF, may also be provided.
The foregoing description of the embodiments has been provided 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 may 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.
This application claims the benefit of U.S. Provisional Application No. 61/816,517, filed on Apr. 26, 2013, U.S. Provisional Application No. 61/816,601, filed on Apr. 26, 2013, U.S. Provisional Application No. 61/816,674, filed on Apr. 26, 2013, and U.S. Provisional Application No. 61/816,676, filed on Apr. 26, 2013. The entire disclosures of the applications referenced above are incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 61816517 | Apr 2013 | US | |
| 61816601 | Apr 2013 | US | |
| 61816674 | Apr 2013 | US | |
| 61816676 | Apr 2013 | US |
