HK1183719B - Communication protocol that supports structured collection procedures used in diabetes care - Google Patents

Description

Communication protocol supporting structured collection procedures used in diabetes care

Cross Reference to Related Applications

This application claims benefit of U.S. provisional application No. 61/393536 filed on 15/10/2010. The entire disclosure of the above application is incorporated herein by reference.

Technical Field

The present disclosure relates to a communication protocol of a medical device for diabetes care, and more particularly, to a communication protocol supporting a structured collection procedure (structured collection procedure) implemented by the medical device.

Background

A diabetic condition (often referred to as diabetes) is a chronic condition in which a person has elevated blood glucose levels caused by a deficiency in the body's ability to produce and/or use insulin. There are three main types of diabetes. Type 1 diabetes usually affects children and young adults and can be autoimmune, genetic, and/or environmental. Type 2 diabetes accounts for 90-95% of the diabetic condition and is associated with obesity and physical inactivity. Gestational diabetes is a form of glucose intolerance diagnosed during pregnancy and usually heals naturally after delivery.

In 2009, at least 2 million people worldwide had diabetes according to the world health organization. In 2005, it was estimated that 110 million people died from diabetes. The incidence of diabetes is rapidly increasing and it is estimated that the number of deaths from diabetes doubles between 2005 and 2030. In the united states, nearly 2 thousand 4 million americans have diabetes, with an estimated 25% of the elderly aged 60 and older having diabetes. Central prediction of disease control and prevention: after 2000, 1 out of every 3 americans born will develop diabetes in their lifetime. The national diabetes Information exchange center (national diabetes Information Clearinghouse) estimates that: diabetes costs in the united states alone at 1320 billion dollars per year. Without treatment, diabetes may lead to serious complications, such as heart disease, stroke, blindness, kidney failure, amputation, and death associated with pneumonia and influenza.

Management of diabetes is complicated by the fact that the level of blood glucose entering the bloodstream is dynamic. Changes in insulin in the bloodstream that control the transport of glucose out of the bloodstream also complicate diabetes management. Blood glucose levels are sensitive to diet and exercise, but may also be affected by sleep, stress, smoking, travel, illness, menses, and other psychological and lifestyle factors unique to each individual patient. The dynamic nature of blood glucose and insulin, as well as all other factors affecting blood glucose, often require that people with diabetes predict blood glucose levels. Thus, treatment in the form of insulin or oral medication, or both, may be timed to maintain blood glucose levels within an appropriate range.

Management of diabetes is often highly invasive due to the need to consistently obtain reliable diagnostic information, follow prescribed therapy, and manage lifestyle on a daily basis. Typically, daily diagnostic information, such as blood glucose concentration, is obtained from a capillary blood sample with a lancing device (lancing device) and then measured with a handheld blood glucose meter. Interstitial glucose levels can be obtained from a continuous glucose sensor worn on the body. The prescribed therapy may include insulin, oral medication, or both. Insulin may be delivered using a syringe, an ambulatory infusion pump, or a combination of the two. In the case of insulin therapy, determining the amount of insulin to be injected may require predicting the effect of dietary composition of fat, carbohydrates and proteins, as well as exercise or other physiological states. Management of lifestyle factors such as weight, diet, and exercise can significantly affect the type and effectiveness of treatment.

Management of diabetes involves a large amount of diagnostic data and descriptive data (descriptive data) obtained from: medical equipment, personal healthcare equipment, patient recorded information, healthcare professional test results, prescription medications, and recorded information. Clinicians typically follow published treatment guidelines (such as, for example, the Joslindiabetes Center)&Joslin clinical's "Clinical Guideline for Pharmacological Management of Type 2 Diabetes”(2007) and Joslin Diabetes Center&JoslinClinic "Clinical Guideline for Adults with Diabetes”(2008)) to treat diabetic patients. The guidelines may specify desired biomarker values (e.g., fasting blood glucose values of less than 100 mg/dl), or the clinician may specify desired biomarker values based on the clinician's training and experience in treating patients with diabetes. However, these guidelines do not specify a biomarker collection process that is tailored to parameters used to support a particular therapy used in optimizing the therapy for a diabetic patient. Subsequently, diabetics often must make little use of the structure for collection and measure their glucose levels with little regard to lifestyle factors. Such unstructured collection of glucose levels may result in some biomarker measurements lacking explanatory context (interpretive context), thereby reducing the value of such measurements to clinicians and other healthcare providers. Thus, there is a need for a structured collection procedure for diagnostic or therapeutic support of patients with diabetes or other chronic diseases.

Patients with diabetes and their health care professionals interact with a variety of medical devices and systems to help manage the disease, including performing structured collection procedures. For each of these different types of medical devices, there is a need to aggregate, manipulate, manage, present, and transmit diagnostic and explanatory data from multiple data sources in an efficient manner to improve the care and health of people with diabetes, and thus, people with diabetes can live an overabundance of life and reduce the risk of complications from diabetes. There is also a need to aggregate, manipulate, manage, present and communicate such diagnostic and explanatory data between different types of medical devices using standard communication protocols. IEEE11073 is an exemplary communication standard that addresses interoperability and communication between medical devices, such as blood pressure monitors, blood glucose monitors, and the like. Within the context of such communication protocols, there is a further need to support a structured collection procedure implemented by a medical device.

The background description provided herein is for the purpose of generally presenting the context of the disclosure.

Disclosure of Invention

A computer-implemented diabetes management system is provided for configuring a structured collection process implemented on a collection device (collection device) having a meter (meter) that measures the concentration of glucose in blood. The system comprises: a collection application that implements a structured collection procedure for obtaining measurement data from the meter and provides access to the measurement data via a communication protocol defined in accordance with IEEE standard 11073-20601; a configuration application that accesses and manipulates parameters of the structured collection process by using a set of action commands, wherein the set of action commands is defined in compliance with the communication protocol; and a collection interface that receives an action command from the configuration application, implements the received action command, and issues a response command in response thereto, wherein the response command is defined in compliance with the communication protocol.

In one aspect of the disclosure, the parameters of the structured collection procedure are further defined as reminders of one or more collection events associated with the structured collection procedure such that the configuration application uses the set of action commands to perform at least one of: reading a reminder for a collection event; or set a reminder for a collection event.

Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description and specific examples are intended for purposes of illustration only and are not intended to limit the scope of the disclosure.

Drawings

FIG. 1 is a diagram showing a patient and a treating clinician (treating clinician);

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

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

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

FIG. 5 is a diagram conceptually illustrating an exemplary structured collection process;

FIG. 6 is a block diagram depicting how Applicant's private extension (private extension) relates to a standardized communication protocol;

FIG. 7 is a diagram depicting an exemplary system of remote configuration that supports such a structure collection process;

FIG. 8 is a diagram depicting another exemplary system of remote configuration that supports such a structure collection process; and

FIG. 9 is a class diagram of a personal health device as defined in accordance with ISO/IEEE 11073-20601.

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

Detailed Description

Referring to fig. 1, a person 100 with diabetes and a healthcare professional 102 are shown in a clinical environment. People with diabetes include people with metabolic syndrome, pre-diabetes, type 1 diabetics, type 2 diabetics, and gestational diabetes, and are collectively referred to as patients. Healthcare providers for diabetes are diverse and include nurses, nurses (nurses practioners), physicians, and endocrinologists, and are collectively referred to as clinicians.

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

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

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

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

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

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

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

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

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

The diabetes manager 104 can communicate with the PC106 using a Bluetooth, USB, or other interface. The diabetes management software running on the PC106 includes an analyzer-configurator that stores configuration information for the devices of the diabetes management system 300. The configurator has a database for storing configuration information for the diabetes manager 104 and other devices. The configurator may communicate with the user through a computer screen in a standard web or non-web application. The configurator communicates the user-approved configuration to the devices of the diabetes management system 300. The analyzer retrieves data from the diabetes manager 104, stores the data in a database, and outputs the analysis results through a computer screen in a standard web page or non-web based application.

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

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

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

For purposes of this disclosure, the diabetes manager 104 acts as a collection device. However, the collecting device may be any portable electronic device that may provide an acquisition mechanism (acquisition mechanism) for determining and storing physiological indicators of a person. For example, self-monitoring blood glucose meters and continuous glucose monitor devices are examples of collection devices used in diabetes care. Although the present disclosure makes reference to diabetes care, it is readily understood that the concepts disclosed herein may be applied to other types of chronic conditions and/or collection devices.

In the field of diabetes care, structured testing or structured collection procedures are a particular type of treatment plan. Figure 5 conceptually illustrates an exemplary structured collection process 500, the structured collection process 500 including a plurality of parameters that define the process. The structured collection process primarily includes a series of planned actions or collection events 510 for obtaining measurement data through the use of a collection device. Each collection event is a request for a physiological metric obtained by using the collection device or other input into the collection device by the patient. In the illustrated process, these requests are for bG measurements. A given collection event may require additional input such as an indication of food consumption or an indication of the energy level of the patient.

In addition to a series of collection events, the structured collection process 500 may include other types of parameters, such as medical usage 512, entry (entry) criteria 514, adherence criteria 516, and exit criteria 518. The medical use case 512 provides an indication of when a particular procedure may be applicable. In this case, the collection process helps to determine trends in the patient's blood glucose (bG) level and/or relationships between blood glucose and other parameters, such as time of day, food intake, energy levels, etc. The entry criteria 514 establish conditions that need to be met before a physiological index is obtained from the patient. The adherence criteria 516 are used to qualitatively assess whether a given collection event was performed. The exit criteria 518 establishes the conditions that need to be met before exiting the structured collection process. It will be readily appreciated that other types of parameters may be used to define the structured collection process. Additional information regarding the structure gathering process may be found in U.S. patent application No. 12/643,338 (WinPat 25378), entitled "Structured Testing Method for Diagnostic or therapy Support of a patent with a bacterial diseases and Devices theory," which is incorporated herein by reference.

A structured collection process is typically implemented on a collection device, such as the diabetes manager 104. Fig. 7 depicts an exemplary system 700 that supports remote configuration of such a structure collection process by a configuration application 701. In an exemplary embodiment, the application processing module 409 of the diabetes manager 104 is further defined to support the configuration. The application processing module 409 comprises a configuration application 701, a collection application 702 and a collection interface 704; each of these components may be implemented as computer-executable instructions in the data store of the collection device. One or more structured collection processes may also reside in a data store 706 that is accessible to the collection application 702.

During operation, the collection application 702 performs a structured collection procedure to obtain measurement data from a patient. In a simplified example, the collection application 702 may interact with the user interface 406 to prompt the patient to take a glucose measurement. The patient may be prompted at a particular time of day as specified by the structured collection process. The collection application 702 interfaces with the BGM module 400 to receive blood glucose measurements obtained from a patient and store such measurements in a data store resident on a collection device. The collection application 702 may also interact with the user interface 406 to obtain other input from the patient according to a structured collection process.

The collection interface 704 in turn provides access to blood glucose measurements and other relevant measurement data. In an exemplary embodiment, the measurement data is accessed via the collection interface 704 using a communication protocol defined in accordance with IEEE standard 11073 and 20601. In the case of blood glucose measurements, the collection interface 704 may implement a device-specific communication protocol as defined by IEEE Standard 11073 plus 10417. For other types of measurements, it should be understood that collection interface 704 may implement an applicable proprietary communication protocol.

Over time, parameters associated with the structured collection process residing on the collection device may need to be configured or otherwise modified by the care provider. The configuration application 701 provides the following mechanisms: through this mechanism, the healthcare provider can access and manipulate the parameters of the structured collection process. For example, the configuration application 701 interacting with a suitable user interface enables a healthcare provider to select a structured collection process associated with a given patient. The parameters associated with the selection collection process are then displayed to the healthcare provider. The healthcare provider may modify and save one or more of the parameters associated with the selected collection process. In an exemplary embodiment, the configuration application 701 may reside on a collection device. In this embodiment, the configuration application 701 interacts with a user interface 406 residing on the collection device, as shown in FIG. 7.

In another exemplary embodiment, the configuration application 701 may reside on a device 810 that is distinct and remote from the collection device, as shown in FIG. 8. For example, the device 810 may be a personal computer that resides with a healthcare provider. In this embodiment, the configuration application 701 interacts with a user interface 812 residing on the device 810 to access and manipulate the structured collection process, where the structured collection process is stored in a data store on the device 810. Once the healthcare provider has locally updated a given structured collection process, the configuration application 701 will interact with the collection interface to update the corresponding structured collection process on the collection device.

To do so, the configuration application 701 interacts with the collection interface 704 by using a set of action commands to update parameters of a structured collection process residing at the collection device. It is noted that the set of action commands is defined in conformity with a communication protocol for accessing measurement data. In the exemplary embodiment, collection interface 704 accesses blood glucose measurements using IEEE Standard 11073 plus 10417. Thus, the set of action commands for accessing and manipulating the parameters of the structured collection process is defined as a private extension of IEEE Standard 11073 plus 10417, as will be described further below.

The ISO/IEEE11073 standard enables communication between medical devices and other computer systems. By way of background, the ISO/IEEE11073 standard is based on an object-oriented system management paradigm. The overall system model is divided into three main components: a Domain Information Model (DIM), a service model, and a communication model. These three components work together to represent data, define data access and command methods, and transfer data from the agent to the manager. Although each modeling construct is briefly described below, ISO/IEEE 11073-20601 may be referenced for a detailed description of the modeling construct.

The domain information model is a hierarchical model that describes the agents as a collection of objects. These objects and their attributes represent elements that control behavior and reporting on the state of the agents and data that the agents can communicate to the manager. Referring to FIG. 9, a class diagram of a personal health device is defined according to ISO/IEEE 11073-20601. The medical device system class 902 is the root class of devices and contains attributes that define the devices themselves. Exemplary attributes include the type of device (i.e., glucose meter or insulin pump), manufacturer and model information, and registered certificate information. All other object classes are derived from the MDS class. For example, the numeric class represents numeric measurements such as bG, carbohydrate, single amount, and the like; while enumerated classes represent state information and/or annotation information. For the sake of brevity, descriptions are not provided for all of the classes shown in the figures.

The communication between the agent and the manager is defined by the application protocol in ISO/IEEE 11073-20601. The service model defines the conceptual mechanisms for data exchange services. Object access classes, such as Get (Get), Set (Set), Action (Action), and Event Reports (Event Reports), are mapped to messages exchanged between the agents and the manager. Protocol messages within the ISO/IEEE 11072 standard family are defined in asn.1. The messages defined in ISO/IEEE 11073-20601 may coexist with messages defined in other standard application profiles defined in the ISO/IEEE 11072 family of standards.

Generally, the communication model supports the topology of one or more agents communicating with a single manager over logical point-to-point connections. More precisely, the communication model defines the construction of Application Protocol Data Units (APDUs). The ADPU is a data packet exchanged between the agent and the manager. For each logical point-to-point connection, the dynamic system behavior is defined by the connection state machine as specified in ISO/IEEE 11073-20601.

Two types of configurations are defined in ISO/IEEE 11073-20601: standard and extended. Standard configurations are defined in ISO/IEEE11073-104zz specifications (such as ISO/IEEE 11073-. The use of standard configurations is negotiated at association time between the agent and the manager. If the manager confirms its understanding and wants to operate by using the configuration, the agent can immediately start sending measurement results. If the manager does not understand the configuration, the agent provides the configuration before transmitting the measurement information.

In the extended configuration, the configuration of the agent is not predefined in the standard. The agent determines which objects, attributes and values are to be used in the configuration and assigns a configuration identifier. When an agent associates with a manager, the agent negotiates acceptable configurations. Typically, the manager does not recognize the configuration of the agent on the first connection, and therefore, the manager responds to: the agent needs to send the configuration information as a configuration event report. However, if the manager already understands the configuration because the manager is preloaded in some way or the agent has been previously associated with the manager, the manager responds: the configuration is known and no further configuration information needs to be sent.

Referring to FIG. 6, the present disclosure defines extensions 602 to these configurations, i.e., Applicant's private extensions, that are not disclosed in any of ISO/IEEE 11073-. The relationship of applicants' private extension 602 to the standardized communication protocol is shown in FIG. 6. Generally, embodiments of the private extension 602 define attributes and services for supporting the transmission and execution of specific commands and data. The basic framework for private extensions is first described below. Then, within this framework, a set of action commands that support the structured collection process are presented through the present disclosure. The set of action commands is used by the configuration application 701 and the collection interface 704 to access and manipulate parameters of the structured collection process. It will be readily appreciated that other types of command sets may fall within the framework for private extensions. In an exemplary embodiment of applicants' private extension, each proxy device has one MDS object. The top level MDS object is instantiated from the MDS class. MDS objects represent the identity and state of an agent by their attributes. In addition to the class definitions provided by the IEEE standards, additional standardized classes may be supported by agents and managers in accordance with applicant's private extensions. The additional standardized class is referred to herein as the RPC class. The RPC private naming code is assigned from the manufacturer specific scope of the private item code (0 xF 000-OxFBFF) within the object-oriented partition class (MDC _ PART-OBJ). The partition number of the object-oriented class and the object is 1.

The attributes of each RPC class are defined in a table that specifies the name of the attribute, its value, and its modifier (qualifier). The modifier means: the M-attribute is mandatory, the C-attribute is conditional and depends on the condition stated in the remarks or value column, the R-attribute is recommended, the NR-attribute is not recommended, and the O-attribute is optional. Mandatory properties should be enforced by the proxy. The conditional attribute should be implemented if the condition applies, and may be implemented in other ways. The recommendation attribute should be enforced by the agent. Attributes that are not recommended should not be enforced by the agent. The optional attributes may be implemented on the proxy.

RPC classes are created that instantiate digital type objects because they exist in the device. These digital type objects represent additional result data that may be obtained from the device in the same manner as additional result data is obtained from device specialization (device specialization). These objects should be added to the device attribute value mappings of the authenticated managers. The attributes that are common across all RPC digital objects are set forth in appendix a. Furthermore, applicants' private extensions have defined several RPC digital objects available to system designers. Likewise, the definition of these common RPC digital objects is set forth in appendix A. Applicants' private extensions also define several RPC enumeration objects as set forth in appendix B.

Applicants' private extensions further define the application protocol data unit as set forth below. The APDU represents the top level message frame of the personal health device protocol. Extended APDUs are added as extensions to the standard list of APDUs defined in the ISO/IEEE 11073-20601 specification.

The presentation APDU as defined in ISO/IEEE 11073-20601 is only an octet string. Applicants' extended APDU adds a 16-bit CRC to ensure data integrity outside the ISO/IEEE 11073-20601 concept of the horizontal and reliable data channel provided by the transmission. With this CRC, the application can detect corrupted data. This CRC covers the entire "RPC" portion of the command call and command response APDU.

The applicants' extended APDU should encapsulate an unacknowledged Action alignment (Action Argument) and an acknowledged Event Report Data (Event Report Data) APDU defined by the ISO/IEEE 11073-20601 standard as follows:

the method for invoking the applicants 'defined command is to extend the MDS object method with the applicants' defined action. ISO/IEEE 11073-20601 unacknowledged action service uses what was previously discussed in this disclosureActionArgumentSimpleAnd (5) structure.

For purposes of this specification, these fields will have the following values:

to invoke the command defined by the applicant, the manager populates the action-type and action-info-arts of the ActionArgumentSimple object as follows:

the data object action-info-args for command invocation is defined as follows:

the coding of ANY DEFINED BY is defined in ISO/IEEE 11073-20601 as follows: the ANY DEFINED BY type (ASN.11988/90) or instance-of type (ASN.11994) is encoded with a header of the length field to specify the number of octets in the encoding of the next selected value. The length element should be expressed as the number of bytes (octets) contained in the value element. An EMPTY argument (EMPTY argument) should be indicated using a TYPE element set to RPC _ ARG _ TYPE _ EMPTY, a length element set to 2, and a value element set to 0 as INT-U16. An RpcCommand Targetmeters structure containing a cmd-subcmd value that does not require an argument will include a single RpcDataArgments element that indicates a null argument.

The method for returning data due to applicants 'defined command calls is to extend the MDS event report with applicants' defined events. Notification service confirmed by ISO/IEEE 11073-20601 uses that previously discussed in this disclosureEventReportArgumentSimpleAnd (5) structure. For purposes of this specification, these fields will have the following values:

in response to the command defined by the applicant, the agent will populate the event-type and event-info of the EventReportArgumentSimple object as follows:

the RpcDataArguments object is the same as defined for the applicant's defined actions.

The methods (acts) that are available for MDS subjects are defined in the table below. These methods are invoked by using the ACTION service. In this table, the "method/action" column defines the name of the method. The "mode" column defines whether the method is invoked as an unacknowledged action (i.e., roiv-clip-action) or an acknowledged action (i.e., roiv-clip-acknowledged-action). The Action-type column defines the named ID to be used in the Action-type field of Action requests and responses. The action-info-args column defines the associated data structure to be used in the action message of the requested action-info-args field. The resulting action-info-args column defines the structure to be used in the responding action-info-args.

Method/acts	Mode(s)	Action-type	Action-info-args	The resulting action-info-args
					RPC-Command-Call	Not confirmed	MDC_ACT_RPC_COMMAND_INVOKE	RpcCommandArguments	n/a

The method allows the manager to invoke system commands defined by the applicant.

The potential events sent by the RPC object are defined in the table below. The manager should support all the methods defined in the table.

For command response events, the proxy will process the command, subcommands, and parameter objects after execution of the command defined by the applicant has been requested via the ACTION service. If there is no command parameter error, the result will be an agent-initiated event report reflecting the result of successful command processing. In the event that the command is successful, the event report will contain a command-specific result data string as defined by this specification.

For error response events, the proxy will process the command, subcommands, and parameter objects after execution of the command defined by the applicant has been requested via the ACTION service. If there is a parameter error, the result will be an agent-initiated event report specifying the parameter error. If the manager receives an RPC _ ERR _ HARDWARE or RPC _ ERR _ APPLICATION response, the manager should invoke an RPC read and clear status command to retrieve further error information available from the device.

Within this framework, the set of action commands that support the structured collection process is described further below. For example, the structured collection process can be read using the read ST configuration command in conjunction with the subcommands listed in this section. The command for reading the ST CONFIGURATION is RPC _ CMD _ READ _ ST _ CONFIGURATION and has a value of 0x 8000. It must be ored with one of the read ST configuration sub-command values to form a complete command-sub-command value. Six exemplary subcommands are set forth below.

First, reading a 3-day alert is a command to return an array of ST alert structures, the number of ST alert structures returned being device dependent. The ID value of the returned structure should be one of before breakfast, before lunch, before dinner or before bedtime. Exemplary commands are defined as follows.

RPC command call:

RPC command response:

second, read 3-day status is that the command should return an unsigned integer value indicating whether the activation status is enabled or disabled. Exemplary commands are defined as follows.

RPC command call:

RPC command response:

third, the read 3-day protocol is a command that returns: the starting date value of the protocol as the RPC date structure; a pre-meal target range value of the protocol as an RPC target range structure; a postprandial target range value of the protocol as an RPC target range structure; bedtime target range values for the protocol as an RPC target range structure. Exemplary commands are defined as follows.

RPC command call:

RPC command response:

fourth, read BIT alerts are commands that should return an array of ST alert structures. The number of ST alert structures returned is device dependent. The ID value of the returned structure should be one of taken or acquired. Exemplary commands are defined as follows.

RPC command call:

RPC command response:

fifth, read BIT status is a command that returns: an unsigned integer value indicating whether the activation state is enabled or disabled; and an exit cause value as a 16-bit enumeration. Exemplary commands are defined as follows.

RPC command call:

RPC command response:

sixth, the read BIT protocol is a command to return an array of RpcStParameter structures. The parameters contained in the array may include: the starting date value of the protocol as the RPC date structure; a starting dose value (IU) of the protocol as an 8-bit unsigned integer; a maximum dose value (IU) of the protocol as an 8-bit unsigned integer; a minimum fasting time value (number of hours) as an 8-bit unsigned integer; maximum usage time value (number of days) as an 8-bit unsigned integer; completion threshold value (mg/dL) for the protocol as a 16-bit unsigned integer; a severe hypoglycemia (Hypo) threshold limit (mg/dL) for the protocol as a 16-bit unsigned integer; a hypoglycemic threshold limit (mg/dL) for the protocol as a 16-bit unsigned integer; a maximum severe hypoglycemic event value for the protocol as an 8-bit unsigned integer; a maximum hypoglycemic event value for the protocol as an 8-bit unsigned integer; a maximum violation (resolution) event value of the protocol as an 8-bit unsigned integer; a maximum adherence event value for the protocol as an 8-bit unsigned integer; a physician telephone number value for the protocol as an even length octet string; a Daylight savings Time (Daylight Saving Time) state value of the protocol as a 16-bit enumeration value; a minimum period length value (days) for the protocol as an 8-bit unsigned integer; and the number of dominant samples as 8-bit unsigned integers. Exemplary commands are defined as follows.

RPC command call:

RPC command response:

the parameters of the structure collection process may be changed by using the set ST configuration command in conjunction with the subcommands listed in this section. The command for setting the ST CONFIGURATION is RPC _ CMD _ SET _ ST _ CONFIGURATION and has a value of 0x 8100. It must be ored with the change set sub-command value to form a complete command-sub-command value. The following parameters six exemplary subcommands.

First, the set 3-day reminder command should set the 3-day time reminder value for the device to the specified value. The input parameter is an array of structured trial time alert structures. The proxy device should ignore any structures it does not have a corresponding ID. The ID value of these structures should be one of before breakfast, before lunch, before dinner or before bedtime. The command returns an error code indicating success (RPC _ ERR _ NO _ error) or failure. Exemplary commands are defined as follows.

RPC command call:

RPC command response:

second, the set 3 day status command should set the 3 day activation status value of the device to the specified value. The input parameter is a 16 bit OperationalState value. The command returns an error code indicating success (RPC _ ERR _ NO _ error) or failure. Exemplary commands are defined as follows.

RPC command call:

RPC command response:

third, the set 3 day protocol command should set the following protocol values for the device to the specified values:

1. the starting date value of the protocol as an RPC date structure.

2. The pre-meal target range value of the protocol as an RPC target range structure.

3. Postprandial target range values of the protocol as an RPC target range structure.

4. Bedtime target range values for the protocol as an RPC target range structure.

Exemplary commands are defined as follows.

RPC command call:

RPC command response:

fourth, the set BIT alert command should set the BIT time alert value for the device to the specified value. The input parameter is an array of structured trial time alert structures. The proxy device should ignore any structures it does not have a corresponding ID. The ID values of these structures should be one of administered or acquired. The command returns an error code indicating success (RPC _ ERR _ NO _ error) or failure. Exemplary commands are defined as follows.

RPC command call:

RPC command response:

fifth, the set BIT status command should set the following BIT status values of the device: as an activation state value of 16-bit OperationalState; and an exit cause value as a 16-bit enumeration. The command returns an error code indicating success (RPC _ ERR _ NO _ error) or failure. Exemplary commands are defined as follows.

RPC command call:

RPC command response:

sixth, the set BIT protocol command should set the BIT protocol value of the device to the specified value. The input parameter is an array of structured test parameter structures. The proxy device should ignore any structures it does not have a corresponding parameter ID. The command returns an error code indicating success (PRC _ ERR _ NO _ error) or failure. Exemplary commands are defined as follows.

RPC command call:

RPC command response:

the following description is merely illustrative in nature and is in no way intended to limit the disclosure, its application, or uses. For purposes of clarity, the same reference numbers will be used in the drawings to identify similar elements. As used herein, at least one of the phrases A, B and C should be understood to mean the use of a non-exclusive logical or of logic (a or B or C). It should be understood that the steps within a method may be performed in a different order without altering the principles of the present disclosure.

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

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

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

Appendix A

Public RPC digital object Attribute

Attribute name	Value of	Decoration symbol
				The Handle attribute indicates the reference ID of the object. Each object should have a unique ID assigned by the proxy.	M
	Is defined in each of the digital objects.	M
					M
	Is defined in each of the digital objects	O
				Is defined in each of the digital objects	M
	Absolute time as defined in ISO/IEEE 11073-20601	M
				This attribute defines the digital Observed Value of the object, without any further embedded state information, but with a smaller numerical representation than Simple-Nu-underlying-Value. One and only one of Simple-Nu-underlying-Value, Basic-Nu-underlying-Value or Nu-underlying-Value should be present.	C
	This attribute defines the digital observations of the object without any further embedded state information as found in the Nu-underlying-Value. One and only one of Simple-Nu-underlying-Value, Basic-Nu-underlying-Value or Nu-underlying-Value should be present.	C
				The attribute defines and associates a digital observation of the object withThe measurement status and the cell information are combined. This property is used when the state/cell is dynamic and is always provided with the value. One and only one of Simple-Nu-underlying-Value, Basic-Nu-underlying-Value or Nu-underlying-Value should be present.

Pen/injector insulin ID

Pen/syringe insulin single dose (Bolus Amount)

Insulin single recommendation

Pumping insulin bolus

Pump temporary base rate

Pump temporary base duration

Temporary basal duration BCD number (hhmm) 0x 0000-0 x9959 for insulin pumps

Number of pump waves

Duration of pump wave

Wave duration BCD number (hhmm) 0x 0000-0 x9959 for insulin pumps

Appendix B

Common RPC enumerates object attributes

Time block (diet segment)

Type of structured test

Structured test time events

Structured test protocol events

Structured test configuration changes

Claims (8)

1. A computer-implemented diabetes management system for configuring a structured collection process implemented on a collection device, the computer-implemented diabetes management system comprising:

-a meter housed by the collection device, the meter measuring the concentration of glucose in the blood;

-a collection application implemented as computer executable instructions in a data storage of the collection device, the collection application executing a structured collection procedure for obtaining measurement data from the meter and providing access to the measurement data in accordance with a communication protocol defined in accordance with IEEE standard 11073-;

-a configuration application accessing and manipulating parameters of the structured collection procedure by using a set of action commands, wherein the set of action commands is defined in conformity with the communication protocol; and

-a collection interface implemented as computer executable instructions in a data storage of the collection device, the collection interface receiving an action command from the configuration application, executing the received action command and issuing a response command in response thereto, wherein the response command is defined in conformity with the communication protocol;

wherein the action command set is defined as a private extension of IEEE Standard 11073-20601;

wherein the parameters of the structured collection procedure are further defined as reminders of one or more collection events associated with the structured collection procedure such that the configuration application uses the set of action commands to perform at least one of: reading a reminder for a collection event; or setting a reminder for a collection event;

wherein the parameters of the structured collection procedure are further defined as an operational state of the structured collection procedure such that the configuration application uses the set of action commands to perform at least one of: reading the operating state; or setting the operating state for a collection event;

wherein the parameters of the structured collection process are selected from the group consisting of: the start date of the collection process; a pre-meal target range of measurement data from the meter; a postprandial target range of measurement data from the meter; and a bedtime target range for the measurement data from the meter.

2. The system as recited in claim 1, wherein the collection application comprises an instance of an object with respect to the meter and defined in accordance with IEEE standard 11073 and 10417.

3. The system of claim 1 or 2 wherein the set of action commands is performed using the use action and event reporting service defined in 11073-20601.

4. The system of claim 1 or 2, wherein the configuration application resides on a computing device different from the collection device and communicates with the collection device via a wireless communication link.

5. A computer-implemented system for configuring a structured collection process implemented on a collection device, the computer-implemented system comprising:

-a meter that measures a physiological variable of a person;

-a collection application implemented as computer executable instructions in a data storage of the collection device, the collection application in operation performing a structured collection procedure for obtaining a physiological variable from a patient and providing access to the physiological variable in accordance with a communication protocol defined in accordance with IEEE standard 11073-;

-a configuration application implemented as computer executable instructions for accessing and manipulating parameters of the structured collection process by using a set of action commands, wherein the set of action commands is defined in conformity with the communication protocol; and

-a collection interface implemented as computer executable instructions in a data storage of the collection device, the collection interface receiving an action command from the configuration application, executing the received action command and issuing a response command in response thereto;

wherein the action command set is defined as a private extension of IEEE Standard 11073-20601;

wherein the parameters of the structured collection procedure are further defined as reminders of one or more collection events associated with the structured collection procedure such that the configuration application uses the set of action commands to perform at least one of: reading a reminder for a collection event; or setting a reminder for a collection event;

wherein the parameters of the structured collection procedure are further defined as an operational state of the structured collection procedure such that the configuration application uses the set of action commands to perform at least one of: reading the operating state; or setting the operating state for a collection event;

wherein the parameters of the structured collection process are selected from the group consisting of: the start date of the collection process; a pre-meal target range of measurement data from the meter; a postprandial target range of measurement data from the meter; and a bedtime target range for the measurement data from the meter.

6. The system as recited in claim 5, wherein the collection application comprises an instance of an object with respect to the meter and defined in accordance with IEEE standard 11073 and 10417.

7. The system of claim 5 or 6 wherein the set of action commands is performed using the use action and event reporting service defined in 11073-20601.

8. The system of claim 5 or 6, wherein the configuration application resides on a computing device different from the collection device and communicates with the collection device via a wireless communication link.