Communication protocol that supports structured collection procedures used in diabetes care

A computer-implemented diabetes management system is provided for configuring a structured collection procedure implemented on a collection device having a meter that measures the concentration of glucose in blood. The system includes: a collection application that executes 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 the parameters of the structured collection procedure using a set of action commands, where the set of action commands are defined in compliance with the communication protocol; and a collection interface that receives an action command from the configuration application, executes the received action command and issues a response command in response thereto, where the response command is defined in compliance with the communication protocol.

FIELD

The present disclosure relates to communication protocol for medical devices used for diabetes care and, more particularly, to a communication protocol that supports a structured collection procedure implemented by the medical devices.

BACKGROUND

Diabetes mellitus, often referred to as diabetes, is a chronic condition in which a person has elevated blood glucose levels that result from defects in the body's ability to produce and/or use insulin. There are three main types of diabetes. Type 1 diabetes usually strikes children and young adults, and may be autoimmune, genetic, and/or environmental. Type 2 diabetes accounts for 90-95% of diabetes cases and is linked to obesity and physical inactivity. Gestational diabetes is a form of glucose intolerance diagnosed during pregnancy and usually resolves spontaneously after delivery.

In 2009, according to the World Health Organization, at least 220 million people worldwide suffer from diabetes. In 2005, an estimated 1.1 million people died from diabetes. Its incidence is increasing rapidly, and it is estimated that between 2005 and 2030, the number of deaths from diabetes will double. In the United States, nearly 24 million Americans have diabetes with an estimated 25 percent of seniors age 60 and older being affected. The Centers for Disease Control and Prevention forecast that 1 in 3 Americans born after 2000 will develop diabetes during their lifetime. The National Diabetes Information Clearinghouse estimates that diabetes costs $132 billion in the United States alone every year. Without treatment, diabetes can lead to severe complications such as heart disease, stroke, blindness, kidney failure, amputations, and death related to pneumonia and flu.

Management of diabetes is complex as the level of blood glucose entering the bloodstream is dynamic. Variation of insulin in the bloodstream that controls the transport of glucose out of the bloodstream also complicates diabetes management. Blood glucose levels are sensitive to diet and exercise, but also can be affected by sleep, stress, smoking, travel, illness, menses, and other psychological and lifestyle factors unique to individual patients. The dynamic nature of blood glucose and insulin, and all other factors affecting blood glucose, often require a person with diabetes to forecast blood glucose levels. Therefore, therapy in the form of insulin or oral medications, or both, can be timed to maintain blood glucose levels in an appropriate range.

Management of diabetes is often highly intrusive because of the need to consistently obtain reliable diagnostic information, follow prescribed therapy, and manage lifestyle on a daily basis. Daily diagnostic information, such as blood glucose concentration, is typically obtained from a capillary blood sample with a lancing device and is then measured with a handheld blood glucose meter. Interstitial glucose levels may be obtained from a continuous glucose sensor worn on the body. Prescribed therapies may include insulin, oral medications, or both. Insulin can be delivered with a syringe, an ambulatory infusion pump, or a combination of both. With insulin therapy, determining the amount of insulin to be injected can require forecasting meal composition of fat, carbohydrates and proteins along with effects of exercise or other physiologic states. The management of lifestyle factors such as body weight, diet, and exercise can significantly influence the type and effectiveness of a therapy.

Management of diabetes involves large amounts of diagnostic data and prescriptive data that are acquired from medical devices, personal healthcare devices, patient recorded information, healthcare professional tests results, prescribed medications and recorded information. Clinicians generally treat diabetic patients according to published therapeutic guidelines such as, for example, Joslin Diabetes Center & Joslin Clinic,Clinical Guideline for Pharmacological Management of Type2Diabetes(2007) and Joslin Diabetes Center & Joslin Clinic,Clinical Guideline for Adults with Diabetes(2008). The guidelines may specify a desired biomarker value, e.g., a fasting blood glucose value of less than 100 mg/dl, or the clinician can specify a desired biomarker value based on the clinician's training and experience in treating patients with diabetes. However, such guidelines do not specify biomarker collection procedures for parameter adjustments to support specific therapies used in optimizing a diabetic patient's therapy. Subsequently, diabetic patients often must measure their glucose levels with little structure for collection and with little regard to lifestyle factors. Such unstructured collection of glucose levels can result in some biomarker measurements lacking interpretative context, thereby reducing the value of such measurements to clinicians and other health care providers. Thus, there is a need to provide structured collection procedures for diagnostic or therapy support of a patient with diabetes or other chronic diseases.

Patients with diabetes and their healthcare professionals interact with a variety of medical devices and systems to help manage the disease, including performing structured collection procedures. For each of these differing types of medical devices, there is a need to aggregate, manipulate, manage, present, and communicate diagnostic data and prescriptive data from multiple data sources in an efficient manner to improve the care and health of a person with diabetes, so the person with diabetes can lead a full life and reduce the risk of complications from diabetes. There is also a need to aggregate, manipulate, manage, present, and communicate such diagnostic data and prescriptive data amongst the different types of medical devices using a standard communication protocol. IEEE 11073 is an exemplary communication standard that addresses interoperability and communication amongst medical devices such as blood pressure monitors, blood glucose monitors and the like. Within the context of such communication protocol, there is a further need to support the structured collection procedures implemented by the medical devices.

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

SUMMARY

A computer-implemented diabetes management system is provided for configuring a structured collection procedure implemented on a collection device having a meter that measures the concentration of glucose in blood. The system includes: a collection application that executes 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 the parameters of the structured collection procedure using a set of action commands, where the set of action commands are defined in compliance with the communication protocol; and a collection interface that receives an action command from the configuration application, executes the received action command and issues a response command in response thereto, where the response command is defined in compliance with the communication protocol.

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

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.

DETAILED DESCRIPTION

Referring toFIG. 1, a person100with diabetes and a healthcare professional102are shown in a clinical environment. Persons with diabetes include persons with metabolic syndrome, pre-diabetes, type 1 diabetics, type 2 diabetics, and gestational diabetics and are collectively referred to as a patient. Healthcare providers for diabetes are diverse and include nurses, nurse practitioners, physicians, and endocrinologists and are collectively referred to as a clinician.

During a healthcare consultation, the patient100typically shares with the clinician102a variety of patient data including blood glucose measurements, continuous glucose monitor data, amounts of insulin infused, amounts of food and beverages consumed, exercise schedules, and other lifestyle information. The clinician102may obtain additional patient data that includes measurements of HbA1C, cholesterol levels, triglycerides, blood pressure, and weight of the patient100. The patient data can be recorded manually or electronically on a handheld diabetes management device104, a diabetes analysis software executed on a personal computer (PC)106, and/or a web-based diabetes analysis site (not shown). The clinician102can analyze the patient data manually or electronically using the diabetes analysis software and/or the web-based diabetes analysis site. After analyzing the patient data and reviewing adherence of the patient100to previously prescribed therapy, the clinician102can decide whether to modify the therapy for the patient100.

Referring toFIG. 2, the patient100can use a continuous glucose monitor (CGM)200, an ambulatory non-durable insulin infusion pump202or an ambulatory durable insulin infusion pump204(hereinafter insulin pump202or204), and the handheld diabetes management device104(hereinafter the diabetes manager104). The CGM200uses a subcutaneous sensor to sense and monitor the amount of glucose in the blood of the patient100and communicates corresponding readings to the diabetes manager104.

The diabetes manager104performs various tasks including measuring and recording blood glucose levels, determining an amount of insulin to be administered to the patient100via the insulin pump202or204, receiving patient data via a user interface, archiving the patient data, etc. The diabetes manager104periodically receives readings from the CGM200indicating insulin level in the blood of the patient100. The diabetes manager104transmits instructions to the insulin pump202or204, which delivers insulin to the patient100. Insulin can be delivered in a scheduled manner in the form of a basal dose, which maintains a predetermined insulin level in the blood of the patient100. Additionally, insulin can be delivered in the form of a bolus dose, which raises the amount of insulin in the blood of the patient100by a predetermined amount.

Referring toFIG. 3, a diabetes management system300used by the patient100and the clinician102includes one or more of the following devices: the diabetes manager104, the continuous glucose monitor (CGM)200, the insulin pump202or204, a mobile device302, the PC106with the diabetes analysis software, and other healthcare devices304. The diabetes manager104is configured as a system hub and communicates with the devices of the diabetes management system300. Alternatively, the insulin pump204or the mobile device302can serve as the system hub. Communication between the devices in the diabetes management system300can be performed using wireless interfaces (e.g., Bluetooth) and/or wireline interfaces (e.g., USB). Communication protocols used by these devices can include protocols compliant with the IEEE 11073 standard as extended using guidelines provided by Continua® Health Alliance Design Guidelines. Further, healthcare records systems such as Microsoft® HealthVault™ and Google™ Health can be used by the patient100and clinician102to exchange information.

The diabetes manager104can receive blood glucose readings from one or more sources (e.g., from the CGM200). The CGM200continuously measures the blood glucose level of the patient100. The CGM200periodically communicates the blood glucose level to the diabetes manager104. The diabetes manager104and the CGM200communicate wirelessly using a proprietary Gazell wireless protocol developed by Nordic Semiconductor, Inc.

Additionally, the diabetes manager104includes a blood glucose meter (BGM) and a port that communicates with the BGM (not shown). The port can receive a blood glucose measurement strip306. The patient100deposits a sample of blood or other bodily fluid on the blood glucose measurement strip306. The BGM analyzes the sample and measures the blood glucose level in the sample. The blood glucose level measured from the sample and/or the blood glucose level read by the CGM200can be used to determine the amount of insulin to be administered to the patient100. To facilitate collection of blood glucose measures, the diabetes manager104may executes one or more structured collection procedures as further described below.

The diabetes manager104communicates with the insulin pump202or204. The insulin pump202or204can be configured to receive instructions from the diabetes manager104to deliver a predetermined amount of insulin to the patient100. Additionally, the insulin pump202or204can receive other information including meal and/or exercise schedules of the patient100. The insulin pump202or204can determine the amount of insulin to administer based on the additional information.

The insulin pump202or204can also communicate data to the diabetes manager104. The data can include amounts of insulin delivered to the patient100, corresponding times of delivery, and pump status. The diabetes manager104and the insulin pump202or204can communicate using a wireless communication protocol such as Bluetooth. Other wireless or wireline communication protocols can also be used.

In addition, the diabetes manager104can communicate with the other healthcare devices304. For example, the other healthcare devices304can include a blood pressure meter, a weight scale, a pedometer, a fingertip pulse oximeter, a thermometer, etc. The other healthcare devices304obtain and communicate personal health information of the patient100to the diabetes manager104through wireless, USB, or other interfaces. The other healthcare devices304may use communication protocols compliant with ISO/IEEE 11073. The diabetes manager104can communicate with the other healthcare devices304using interfaces including Bluetooth, USB, etc. Further, the devices of the diabetes management system300can communicate with each other via the diabetes manager104.

The diabetes manager104can communicate with the PC106using Bluetooth, USB, or other interfaces. A diabetes management software running on the PC106includes an analyzer-configurator that stores configuration information of the devices of the diabetes management system300. The configurator has a database to store configuration information of the diabetes manager104and the other devices. The configurator can communicate with users through standard web or computer screens in non-web applications. The configurator transmits user-approved configurations to the devices of the diabetes management system300. The analyzer retrieves data from the diabetes manager104, stores the data in a database, and outputs analysis results through standard web pages or computer screens in non-web based applications.

The diabetes manager104can communicate with the mobile device302using Bluetooth. The mobile device302may include a cellular phone, a pager, or a personal digital assistant (PDA). The diabetes manager104can send messages to an external network through the mobile device302. The mobile device302can transmit messages to the external network upon receiving requests from the diabetes manager104.

An exemplary diabetes manager104is further described in relation toFIG. 4. The diabetes manager104comprises a blood glucose measuring (BGM) module400, a communication module402, a user interface module404, user interfaces406, a processing module408, memory410, and a power module412. The user interface module404and the processing module408can be implemented by an application processing module409. The BGM module400includes a blood glucose measuring engine that analyzes samples provided by the patient100on the blood glucose measurement strip306and that measures the amount of blood glucose in the samples. The communication module402includes multiple radios that communicate with different devices of the diabetes management system300. The user interface module404interfaces the diabetes manager104to various user interfaces406that the patient100can use to interact with the diabetes manager104. For example, the user interfaces406can include keys, switches, a display, a speaker, a microphone, a secure digital (SD) card port, a USB port, etc. (not shown).

The processing module408processes data received from the BGM module400, the communication module402, and the user interface module404. The processing module408uses memory410for processing and storing data. The memory410can include volatile and nonvolatile memory. The processing module408outputs data to and receives data from the user interfaces406via the user interface module404. The processing module408outputs data to and receives data from the devices of the diabetes management system300via the communication module402. The power module412supplies power to the components of the diabetes manager104. The power module412includes a rechargeable battery. The battery can be recharged using an adapter that plugs into a wall outlet. The battery can also be charged via the USB port of the diabetes manager104.

For purposes of this disclosure, the diabetes manager104serves as a collection device. However, the collection device can be any portable electronic device that can provide an acquisition mechanism for determining and storing physiological measures of a person. For example, self-monitoring blood glucose meters and continuous glucose monitor devices are examples of collection devices used in diabetes care. While this disclosure makes reference to diabetes care, it is readily understood that the concepts disclosed herein can be applied to other types of chronic diseases and/or collection devices.

In the diabetes care domain, a structured test or structure collection procedure is a particular type of treatment plan.FIG. 5conceptually illustrates an exemplary structured collection procedure500comprised of a plurality of parameters that define the procedure. A structured collection procedure is primarily comprised of a series of planned actions or collection events510for obtaining measurement data using the collection device. Each collection event is a request for a physiological measure obtained using the collection device or other input by the patient into the collection device. In the illustrated procedure, the requests are for a bG measurement. A given collection event may require additional input such as an indication of meal size or an indication of the patient's energy level.

In addition to a series of collection events, the structured collection procedure500may include other types of parameters such as a medical use case512, an entry criterion514, an adherence criterion516and an exit criterion518. Medical use case512provides an indication of when the particular procedure may be applicable. In this case, the collection procedure is helpful for determining trends in blood glucose (bG) levels of a patient and/or relationships between blood glucose and other parameters, such as time of day, meal size, energy level, etc. Entry criterion514establishes the conditions needed to be met prior to obtaining a physiological measure from the patient. Adherence criterion516is used to assess qualitatively whether a given collection event was performed. Exit criterion518establishes the conditions needed to be met prior to exiting the structured collection procedure. It is readily understood that other types of parameters may be used to define a structured collection procedure. Further information regarding structure collection procedures may be found in U.S. patent application Ser. No. 12/643,338 (WinPat 25378) entitled “Structured Testing Method for Diagnostic or Therapy Support of a Patient with a Chronic Disease and Devices Thereof” which is incorporated by reference herein.

Structured collection procedures are typically implemented on a collection device, such as diabetes manager104.FIG. 7depicts an exemplary system700that supports remote configuration of such structure collection procedures by a configuration application701. In an exemplary embodiment, the application processing module409of the diabetes manager104is further defined to support configuration. The application processing module409includes a configuration application701, a collection application702and a collection interface704; each of these components may be implemented as computer executable instructions in a data store of the collection device. One or more structured collection procedures may also reside in a data store706accessible to the collection application702.

During operation, the collection application702executes a structured collection procedure to obtain measurement data from the patient. In a simplified example, the collection application702may interact with a user interface406to prompt a patient to take a glucose measure. The patient may be prompted at a particular time of day as specified by the structured collection procedure. The collection application702is interfaced with the BGM module400to receive blood glucose measures obtained from the patient and store such measures in a data store residing on the collection device. The collection application702may also interact with the user interface406to obtain other input from the patient in accordance with the structured collection procedure.

The collection interface704in turn provides access to the blood glucose measures and other related measurement data. In the exemplary embodiment, measurement data is accessed via the collection interface704using a communication protocol defined in accordance with IEEE standard 11073-20601. In the case of blood glucose measures, the collection interface704may implement a device specialized communication protocol as defined by IEEE standard 11073-10417. For other types of measures, it is understood that the collection interface704may implement the applicable specialized communication protocol.

Over time, the parameters associated with a structured collection procedure residing on the collection device may need to be configured or otherwise modified by a tending healthcare provider. The configuration application701provides the mechanism by which the parameters of a structured collection procedure may be accessed and manipulated by the healthcare provider. For example, the configuration application701, interacting with suitable user interfaces, enables the healthcare provider to select a structured collection procedure associated with a given patient. Parameters associated with the select collection procedure 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 procedure. In one exemplary embodiment, the configuration application701may reside on the collection device. In this embodiment, the configuration application701interacts with the user interfaces406residing on the collection device as shown inFIG. 7.

In another exemplary embodiment, the configuration application701may reside on a device810distinct and remote from the collection device as shown inFIG. 8. For example, the device810may be a personal computer that resides with the healthcare provider. In this embodiment, the configuration application701interacts with user interfaces812residing on the device810to access and manipulate the structured collection procedure, where the structured collection procedures are stored in a data store on the device810. Once healthcare provider has updated a given structure collection procedure locally, the configuration application701will then interact with the collection interface to update the corresponding structured collection procedure on the collection device.

To do so, the configuration application701interfaces with the collection interface704using a set of action commands to update parameters of a structured collection procedure residing at the collection device. Of note, the set of action commands are defined in compliance with the communication protocol used to access the measurement data. In the exemplary embodiment, the collection interface704accesses the blood glucose measures using the IEEE standard 11073-10417. Thus, the set of action commands used to access and manipulate the parameters of a structured collection procedure are defined as a private extension of the IEEE standard 11073-10417 as will be further described below.

ISO/IEEE 11073 standard enables communication amongst medical devices and other computer systems. By way of background, ISO/IEEE 11073 standard is based on an object oriented systems management paradigm. The overall system model is divided into three principal components: the domain information model (DIM), the service model, and the communication model. These three components work together to represent data, define data access and command methodologies and communicate the data from an agent to a manager. ISO/IEEE 11073-20601 may be referenced for a detailed description of the modeling constructs although each is described briefly below.

The domain information model is a hierarchical model that describes an agent as a set of objects. These objects and their attributes represent the elements that control behavior and report on the status of the agent and the data that an agent can communicate to a manager. With reference toFIG. 9, a class diagram for a personal health device is defined in accordance with ISO/IEEE 11073-20601. The Medical Device System class902is the root class of the device and contains attributes defining the device itself. Exemplary attributes include the type of device, i.e., glucose meter or insulin pump, manufacturer and model information and registered certification information. All other object classes are derived from the MDS class. For example, the Numeric class represents numeric measurements such as bG, carbohydrates, bolus amount, etc; whereas, the enumeration class represents status information and/or annotation information. For brevity purposes, a description is not provided for all of the classes shown in the figure.

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 the data exchange services. Object access services, such as Get, Set, Action and Event Reports, are mapped to messages that are exchanged between the agent and the manager. Protocol messages within the ISO/IEEE 11072 series of standards are defined in ASN.1. The messages defined in ISO/IEEE 11073-20601 can coexist with messages defined in other standard application profiles defined in the ISO/IEEE 11072 series of standards.

In general, the communication model supports the topology of one or more agents communicating over logical point-to-point connections to a single manager. More specifically, the communication model defines the construct of an application protocol data unit (APDU). ADPUs are data packets exchanged between agents and managers. For each logical point-to-point connection, the dynamic system behavior is defined by a connection state machine as specified in ISO/IEEE 11073-20601.

Two styles of configuration are defined in ISO/IEEE 11073-20601: standard and extended. Standard configurations are defined in the ISO/IEEE 11073-104zz specializations (such as the ISO/IEEE 11073-10417 Glucose Device specialization) and are assigned a well-known identifier (Dev-Configuration-Id). The usage of a standard configuration is negotiated at association time between the agent and the manager. If the manager acknowledges that it understands and wants to operate using the configuration, then the agent can begin sending measurements immediately. If the manager does not understand the configuration, the agent provides the configuration prior to transmitting measurement information.

In extended configurations, the agent's configuration is not predefined in a standard. The agent determines which objects, attributes, and values will be used in a configuration and assigns a configuration identifier. When the agent associates with a manager, it negotiates an acceptable configuration. Typically, the manager does not recognize the agent's configuration on the first connection, so the manager responds that the agent needs to send the configuration information as a configuration event report. If, however, the manager already understands the configuration, either because it was preloaded in some way or the agent had previously associated with the manager, then the manager responds that the configuration is known and no further configuration information needs to be sent.

With reference toFIG. 6, this disclosure defines an extension602to these configurations, i.e., applicant's private extension, which is not published in any of the ISO/IEEE 11073-104xx device specializations604. Applicant's private extension602relationship to the standardized communication protocols is shown inFIG. 6. Generally speaking, implementation of this private extension602defines the attributes and services to support the transfer and execution of specific commands and data. A basic framework for the private extension is first described below. Within this framework, a set of action commands that support structured collection procedures are then presented by this disclosure. The set of action commands are used by the configuration application701and the collection interface704to access and manipulate the parameters of structured collection procedures. It is readily understood that other types of commands sets can also fall within the framework for the private extension.

In an exemplary embodiment of applicant's private extension, each agent device has one MDS object. This top-level MDS object is instantiated from the MDS class. The MDS object represents the identification and status of the agent through its attributes. Beyond the class definition provided by the IEEE standards, additional standardized classes may be supported by the agents and managers in accordance with applicant's private extension. The additional standardized classes are referred to herein as RPC classes. RPC private nomenclature codes are assigned from the manufacturer-specific range of private term codes (0xF000-OxFBFF) within the object oriented partition category (MDC_PART-OBJ). The partition number for object oriented classes and objects is 1.

The attributes for each RPC class are defined in tables that specify the name of the attribute, its value and its qualifier. The qualifiers mean M—attribute is mandatory, C—attribute is conditional and depends on the condition stated in the remark or value column, R—attribute is recommended, NR—attribute is not recommended, and O—attribute is optional. Mandatory attributes shall be implemented by an agent. Conditional attributes shall be implemented if the condition applies and may be implemented otherwise. Recommended attributes should be implemented by the agent. Not recommend attributes should not be implemented by the agent. Optional attributes may be implemented on an agent.

RPC classes that instantiate numeric type objects are created as they exist in the device. These numeric type objects represent additional result data that can be obtained from the device in the same manner they are obtained from the device specialization. These objects shall be added to the device attribute value map for authenticated managers. Attributes common across all of the RPC numeric objects are set forth in Appendix A. Furthermore, applicant's private extension has defined a few RPC numeric objects available to system designers Likewise, definitions for these common RPC numeric objects are set forth in Appendix A. Applicant's private extension also defines a few RPC enumeration objects as set forth in Appendix B.

Applicant's private extension further defines an application protocol data unit as set forth below. An APDU represents the top-level message frame of the personal health device protocol. The extended APDU is added as an extension to the standard list of APDUs defined in the ISO/IEEE 11073-20601 specification.

A presentation APDU as defined in ISO/IEEE 11073-20601 is simply an octet string. Applicant's extended APDU adds a 16-bit CRC in order to ensure data integrity beyond the level provided by the transport and the ISO/IEEE 11073-20601 concept of reliable data channels. With this CRC, corrupted data can be detected by the application. This CRC covers the entire “RPC” part of the command invoke and command response APDUs.

PrrpApdup ::= SEQUENCE {dataOCTET STRING, (ENCODED VERSION OF DataApdu)crcINT-U16 (checksum over the entire data field)}
Applicant's extended APDU shall encapsulate unconfirmed Action Argument and confirmed Event Report Data APDUs defined by the ISO/IEEE 11073-20601 standard as follows:

The approach used to invoke applicant's defined commands is to extend the MDS object methods with applicant defined actions. The ISO/IEEE 11073-20601 unconfirmed action service uses the ActionArgumentSimple structure previously discussed in this disclosure.

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

handle0 (for the MDS object)action-typemanufacturer specific code for applicantdefined actionsaction-info-argsmanufacturer specific structure for eachapplicant defined action

In order to invoke an applicant defined command, a manager would populate the action-type and action-info-arts of the ActionArgumentSimple object as follows:

The data objects used for command invocation action-info-args are defined as follows:

The approach used to return data as a result of an applicant defined command invocation is to extend the MDS event reports with applicant defined events. The ISO/IEEE 11073-20601 confirmed notification service uses the EventReportArgumentSimple structure previously discussed in this disclosure. For the purposes of the specification, the fields would have the following values:

Handle0 (for the MDS object)event-time0 (event time is not used for applicant actions)event-typemanufacturer specific code for applicant definedcommand responses. -event-infomanufacturer specific structure for eachapplicant defined response.

In order to respond to an applicant defined command, an agent would populate the event-type and event-info of the EventReportArgumentSimple object as follows:

Event-typeMDC_NOTI_RPC_COMMAND_RESPONSEevent-infoRpcDataArguments [ ]
The RpcDataArguments object is the same as is defined for applicant defined actions.

Methods (actions) available for the MDS object are defined in the table below. These methods are invoked using the ACTION service. In the table, the Method/Action column defines the name of the method. The Mode column defines whether the method is invoked as an unconfirmed action (i.e., roiv-cmip-action) or a confirmed action (i.e., roiv-cmip-confirmed-action). The Action-type column defines the nomenclature ID to use in the action-type field of an action request and response. The action-info-args column defines the associated data structure to use in the action message for the action-info-args field of the request. The Resulting action-info-args column define the structure to use in the action-info-args of the response.

This method allows the manager to invoke an applicant defined system command.

Potential events sent by the RPC object are defined in the table below. A manager shall support all methods defined in the table.

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

For the error response event, after the execution of an applicant defined command has been requested via the ACTION service, the agent will process the command, sub-command and parameter objects. If there are parameter errors, the result will be an agent-initiated event report specifying the parameter error. If a manager receives an RPC_ERR_HARDWARE or RPC_ERR_APPLICATION response, the manager should invoke the RPC Read and Clear Status command to retrieve further error information available from the device.

Within this framework, a set of action commands that support structured collection procedures is further described below. For example, a structured collection procedure is readable by using a Read ST Configuration command in conjunction with the subcommands listed in this section. The command for reading ST configuration is RPC_CMD_READ_ST_CONFIGURATION and has a value of 0x8000. It must be “OR-ed” with one of the read ST configuration subcommand values to form a complete command-subcommand value. Six exemplary subcommands are set forth below.

First, the Read 3-Day Reminders is a command that return an array of ST Reminder structures, the number of ST Reminder structures returned is device dependent. The ID values for the returned structures shall be one of Before Breakfast, Before Lunch, Before Dinner or Before Bedtime. An exemplary command definition is as follows.

Second, the Read 3-Day Status is a command shall return an unsigned integer value which indicates whether the activation status is enabled or disabled. An exemplary command definition is as follows.

Third, the Read 3-Day Protocol is a command that returns: the Start Date value of the protocol as an RPC Date structure; the Pre-Meal Target Range value of the protocol as an RPC Target Range structure; the Post-Meal Target Range value of the protocol as an RPC Target Range structure; the Bedtime Target Range value of the protocol as an RPC Target Range structure. An exemplary command definition is as follows.

Fourth, the Read BIT Reminders is a command that shall return an array of ST Reminder structures. The number of ST Reminder structures returned is device dependent. The ID values for the returned structures shall be one of Administration or Acquisition. An exemplary command definition is as follows.

Fifth, the Read BIT Status is a command that returns an unsigned integer value which indicates whether the activation status is enabled or disabled; and the Exit Reason value as a 16 bit enumeration. An exemplary command definition is as follows.

Sixth, the Read BIT Protocol is a command that returns an array of RpcStParameter structures. Parameters contained in the array may include: the Start Date value of the protocol as an RPC Date structure; the Start Dosage value (IU) of the protocol as an 8 bit unsigned integer; the Maximum Dosage value (IU) of the protocol as an 8 bit unsigned integer; the Minimum Fasting Time value (number of hours) as an 8 bit unsigned integer; the Maximum Use Time value (number of days) as an 8 bit unsigned integer; the Completion Threshold value (mg/dL) of the protocol as a 16 bit unsigned integer; the Severe Hypo Threshold value (mg/dL) of the protocol as a 16 bit unsigned integer; the Hypo Threshold value (mg/dL) of the protocol as a 16 bit unsigned integer; the Maximum Severe Hypo Events value of the protocol as an 8 bit unsigned integer; the Maximum Hypo Events value of the protocol as an 8 bit unsigned integer; the Maximum Violation Events value of the protocol as an 8 bit unsigned integer; the Maximum Adherence Events value of the protocol as an 8 bit unsigned integer; the Doctor Phone Number value of the protocol as an Octet String of even length; the Daylight Saving Time status value of the protocol as a 16 bit enumeration value; the Minimum Period Length value (days) of the protocol as an 8 bit unsigned integer; and the Number of Primary Samples as an 8 bit unsigned integer. An exemplary command definition is as follows.

The parameters of a structure collection procedure can be changed by using the Set ST Configuration command in conjunction with the subcommands listed in this section. The command for setting ST configuration is RPC_CMD_SET_ST_CONFIGURATION and has a value of 0x8100. It must be “OR-ed” with one of the change setup subcommand values to form a complete command-subcommand value. Six exemplary subcommands are set forth below.

First, the Set 3-Day Reminders command shall set 3-Day time reminder values of the device to the values specified. The input parameter is an array of Structured Test time reminder structures. An agent device shall ignore any structures for which it has no corresponding ID. The ID values for the structures shall be one of Before Breakfast, Before Lunch, Before Dinner or Before Bedtime. The command returns an error code indicating success (RPC_ERR_NO_ERRORS) or failure. An exemplary command definition is as follows.

Second, the Set 3-Day Status command shall set the 3-Day Activation status value of the device to the value specified. The input parameters is a 16 bit OperationalState value. The command returns an error code indicating success (RPC_ERR_NO_ERRORS) or failure. An exemplary command definition is as follows.

Third, the Set 3-Day Protocol command shall set the following protocol values of the device to the values specified:

1. The Start 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. The Post-Meal Target Range value of the protocol as an RPC Target Range structure.

4. The Bedtime Target Range value of the protocol as an RPC Target Range structure.

An exemplary command definition is as follows.

Fourth, the Set BIT Reminders command shall set BIT time reminder values of the device to the values specified. The input parameter is an array of Structured Test time reminder structures. An agent device shall ignore any structures for which it has no corresponding ID. The ID values for the structures shall be one of Administration or Acquisition. The command returns an error code indicating success (RPC_ERR_NO_ERRORS) or failure. An exemplary command definition is as follows.

cmd-subcmdRPC_CMD_SET_ST_CONFIGURATION |RPC_SUBCMD_SET_BIT_REMINDERSRpcDataArguments[0].typeRPC_ARG_TYPE_ST_REMINDERRpcDataArguments[0].lengthLength of RpcStReminder structure in bytesRpcDataArguments[0].valueRpcStReminder structureooooooRpcDataArguments[n].typeRPC_ARG_TYPE_ST_REMINDERRpcDataArguments[n].lengthLength of RpcStReminder structure in bytesRpcDataArguments[0].valueRpcStReminder structure
RPC Command Response:

Fifth, the Set BIT Status command shall set the following BIT status values of the device: the Activation Status value as a 16 bit OperationalState; and the Exit Reason value as a 16 bit enumeration. The command returns an error code indicating success (RPC_ERR_NO_ERRORS) or failure. An exemplary command definition is as follows.

Sixth, the Set BIT Protocol command shall set BIT protocol values of the device to the values specified. The input parameter is an array of Structured Test parameter structures. An agent device shall ignore any structures for which it has no corresponding parameter ID. The command returns an error code indicating success (PRC_ERR_NO_ERRORS) or failure. An exemplary command definition is as follows.

APPENDIX A

Common RPC Numeric Object Attributes

Attribute NameValueQualifierHandleThe Handle attribute represents a referenceMID for this object. Each object shall have aunique ID assigned by the agent.TypeDefined in each of the numeric objects.MMetric-Spec-Smallmss-avail-intermittent | mss-avail-stored-Mdata | mss-upd-aperiodic | mss-msmt-aperiodic | mssacc-agent-initiated | mss-cat-manual.Unit-CodeDefined in each of the numeric objects.OAttribute-Value-MapDefined in each of the numeric objectsMAbsolute-Time-StampAbsoluteTime as defined in ISO/IEEEM11073-20601Basic-Nu-Observed-ValueThis attribute defines the numericalCobserved value of the object, without anyfurther embedded status information, butwith a smaller numerical representationcompared to Simple-Nu-Observed-Value.One and only one of Simple-Nu-Observed-Value, Basic-Nu-Observed-Value or Nu-Observed-Value shall be present.Simple-Nu-Observed-ValueThis attribute defines the numericalCobserved value of the object, without anyfurther embedded status information asfound in Nu-Observed-Value. One andonly one of Simple-Nu-Observed-Value,Basic-Nu-Observed-Value, or Nu-Observed-Value shall be present.Nu-Observed-ValueThis attribute defines the numericalobserved value of the object and combinesit with measurement status and unitinformation. It is used when status/unit aredynamic and are always provided togetherwith the value. One and only one ofSimple-Nu-Observed-Value, Basic-Nu-Observed-Value or Nu-Observed-Valueshall be present.
Pen/Syringe Insulin ID

Attribute NameValueQualifierTypeMDC_PART_OBJMMDC_CTXT_RPC_PENSYR_BOLUS_AMTUnit-CodeMDC_DIM_X_INTL_UNITMAttribute-Value-MapMDC_ATTR_NU_VAL_OBS_BASIC, thenMMDC_ATTR_TIME_STAMP_ABSAbsolute-Time-StampAbsoluteTime as defined in ISO/IEEE 11073-20601MBasic-Nu-Observed-ValueSee ISO/IEEE 11073-20601 - This indicates aMpen/syringe insulin dose in International Units(IU), ranging from 0.0 to 999.9
Insulin Bolus Recommendation

APPENDIX B

Common RPC Enumeration Object Attributes

Attribute NameValueQualifierHandleThe Handle attribute represents a reference IDMfor this object. Each object shall have a uniqueID assignment by the agent.TypeDefined in each of the enumeration objects.MMetric-Spec-Smallmss-avail-intermittent | mss-avail-stored-data |Mmss-upd-aperiodic | mssacc-agent-initiated |mss-cat-manual.Attribute-Value-MapDefined in each of the enumeration objects.MAbsolute-Time-StampAbsoluteTime as defined in ISO/IEEE 11072-20601MEnum-Observed-Value-The value is reported as a nomenclature code.CSimple-OIDOne and only one of Enum-Observed-Value-Simple-OID, Enum-Observed-Value-Basic-Bit-Str shall be presentEnum-Observed-Value-The value is reported as a bit string of 32-bits.CBasic-Bit-StrOne and only one of Enum-Observed-Value-Simple-OID, Enum-Observed-Value-Basic-Bit-Str, Enum-Observed-Value-Simple-Strshall be present.Enum-Observed-Value-The value is reported as an ASCII printableCSimple-Strstring. One and only one of Enum-Observed-Value-Simple-OID, Enum-Observed-Value-Basic-Bit-Str, Enum-Observed-Value-Simple-Str shall be present
Timeblock (Meal Segment)