Introduction to IEEE

Communication Standards

Health informatics—Personal health device communication

Part 10425: Device Specialization— Continuous Glucose Monitor

Health informatics—Personal health device communication

Part 10419: Device Specialization— Insulin Pump

D-Data Exchange

November 20, 2014

Melanie Yeung, BASc., MHSc.

Centre for Global eHealth Innovation

Overview Background

Optimized Exchange Protocol Standard (ISO/IEEE Std

11073-20601)

Device Specialization Tutorial

Continuous Glucose Monitor (IEEE 11073-10425)

Insulin Pump (IEEE 11073-10419)

Standards Workshops and Toolkits

IEEE 11073

Personal Health Device Standards

3

-00103 Overview

Serial IrDA Bluetooth USB ZigBee Layers

1-4

Layers

5-7

OSI

Communication Protocols

NFC

-20601 Optimized Exchange Protocol

-10404Pulse

Oximeter

-10407Blood

Pressure

-10408Thermo-meter

-10415Weighing

Scale

-10417Glucose

-10419

Insulin

Pump

-10425CGM

-10471ActivityData

…

Device Specializations

IEEE Terminology

Agent

Other terms:

• Service Component

• PAN Device

• Device

• Source

• Sensor

Manager

Other terms:

• Client Component

• Application Host Device

• Host

• Sink

• Compute Engine

Transport

Other terms:

l PAN Interface

l USB

l Bluetooth

l Zigbee

BGM

CGM

Insulin Pump

Smartphone

Computer

Properties

Agents

Limited capabilities (RAM, ROM, CPU)

Connection to a single Manager

Limited power resource (small battery)

Low cost (consumer device)

Fixed configurations (data type and format does not change)

Intermittent connections (disconnect when inactive)

Manager

Richer capabilities (RAM, ROM,

CPU)

Connections to multiple Agents

Wall power or larger batteries

Exchange ProtocolISO/IEEE 11073-20601 defines the communication (PAN Interface) between the agent

and the manager.

Places more burden on Managers than Agents

Supports multiple data types (episodic, streaming, store and forward)

Designed to be transport portable (Bluetooth, USB, Zigbee, etc.)

Optimizes data exchange

Enables efficient reconnections

Targets personal health in home and mobile environments

Object-oriented systems management paradigm. The overall system model is

divided into three principal components:

1) Domain information model (DIM),

2) Service model, and

3) Communication model.

Does NOT state what manager does with the data.

CGM Receiver Agent• Takes measurements (has the sensor)

• Simple (minimal hardware requirements)

• Highly specialized (does just one thing)

• Server device

CGM Sensor/Transmitter Agent• May periodically send the results

• Exchange may take place after a

“session”

• Manager may request stored results of

a dedicated time period.

Domain Information Model Describes an agent as a set of objects.

Objects and their attributes represent:

elements that control behavior and report on the status of the

agent

data that an agent can communicate to a manager

DIM:

Object 4Object 1 Object 2 Object 3

Agent DIM

attribute 1attribute 1 attribute 1 attribute 1

attribute 2

attribute 3

attribute 2

attribute 3

attribute 4

attribute 2 attribute 2

attribute 3

attribute 4

Services

ActionsServices

Actions

Services

Actions

Services

Actions

Eventing

Eventing

Eventing

Types of ’Objects’

Sensor

PM-Store object n:Agent’s hard disk

*optional*

MDS ObjectAgent’s bureaucratic and

system information,

*must have*

Metric object kDescribes a measurement,

status, waveform

*optional*

Scanner object m(eventing formatter and organizer)

*optional*

Agent has “Objects” to describe its features

Continuous Glucose Monitor DIM

12

Agent Configurations

Configurations are assigned IDs

Configurations can be memorized by a Manager

Standard configurations

Extended configurations

An agent may have several configurations

Different kinds of configurations:

CGM Standard Configuration

Dev-Configuration-Id = 0x09C4

One Numeric Object: Glucose (interstitial fluid, subcutaneous tissue)

14

Numeric

Glucose

Handle = 1

Type = MDC_CONC_GLU_ISF

Supplemental Type = MDC_CTXT_GLU_SAMPLELOCATION_SUBCUTANEOUS

Metric-Spec-Small = 0xC042 (available intermediate, available stored, agent

initiated, calculation)

Unit-Code = MDC_DIM_MILLI_G_PER_DL

Attribute-Value-Map = {MDC_ATTR_NU_VAL_OBS_BASIC, then

MDC_ATTR_TIME_STAMP_BO

Basic-Nu-Observed-Value = 104 mg/dL

Base-Offset-Timestamp = (date and time of the glucose measurement)

CGM Standard Configuration

CGM Extended Configuration Must include the Glucose object and may include one or more of the optional numeric

and enumeration objects.

Numeric Objects

Glucose (mandatory)

Sensor Calibration (periodic calibration of the sensor is required for most CGMs)

Sensor run-time (embedded sensors only last for a period of days)

Glucose sampling interval (time between glucose samples)

Compound Numeric Objects

Patient high/low thresholds (indicates patient glucose goals)

Device hypo/hyper thresholds (indicates hypoglycemia hyperglycemia levels)

Glucose rate of change thresholds (indicates patient change in glucose goals)

16

CGM Extended Configuration (Cont’d)

Enumeration Objects

PHD DM Status (General disease management status object with common bit

definitions across all specializations)

CGM Status (CGM specific status bits)

17

Compound Numeric

Patient low/high threshold

Handle = assigned by the implementation, cannot be zero

Type = MDC_CONC_GLU_PATIENT_THRESHOLDS_LOW_HIGH

Metric-Spec-Small = (mss-avail-stored-data | mss-upd-aperiodic | mss-

acc-agent-initiated | mss-cat-setting | mss-cat-manual)

Metric-Structure-Small = ms-struct-compound-fix

Metric-Id-List = MDC_CONC_GLU_PATIENT_THRESHOLD_LOW then

MDC_CONC_GLU_PATIENT_THRESHOLD_HIGH

Unit-Code = MDC_DIM_MILLI_MOLE_PER_L

Compound-Basic-Nu-Observed-Value = { 4 mmol/l, 7 mmol/l }

Base-Offset-Timestamp = (date and time of the patient low/high entry)

Extended (Unknown) Configuration

Extended (Known) Configuration

ApplicationProtocolDataUnit

(APDU) Example

20

APDU Example (Cont’d)

21

Insulin Pump Agent

Insulin Pump

Manager

Insulin Pump DIM

23

Insulin Pump

Standard ConfigurationDev-Configuration-Id = 0x076C

Two Numeric Objects: Bolus Delivered, Current Basal Rate Setting

24

Numeric

Bolus Delivered

Handle = 1

Type = MDC_INS_BOLUS

Supplemental Type List = MDC_INS_BOLUS_FAST, MDC_INS_BOLUS_MEAL

Metric-Spec-Small = mss-avail-intermittent | mss-avail-stored-data | mss-upd-aperiodic | mss-

msmt-aperiodic | mss-acc-manager-initiated | mss-acc-agent-initiated |

mss-cat-calculation

Unit-Code = MDC_DIM_X_INTL_UNIT

Attribute-Value-Map = {MDC_ATTR_NU_VAL_OBS_BASIC, then

MDC_ATTR_TIME_STAMP_BO

Basic-Nu-Observed-Value = 0.8 IU

Base-Offset-Time-Stamp = (date and time of the bolus delivered)

Numeric

Current Basal Rate Setting

Handle = 2

Type = MDC_INS_BASAL_RATE_SETTING

Metric-ID = MDC_INS_BASAL_DEVICE

Supplemental Type = MDC_INS_BASAL_PRGM

Metric-Spec-Small = mss-avail-intermittent | mss-avail-stored-data | mss-upd-aperiodic | mss-

acc-manager-initiated | mss-acc-agent-initiated | mss-cat-setting

Unit-Code = MDC_DIM_X_INTL_UNIT_PER_HR

Attribute-Value-Map = {MDC_ATTR_NU_VAL_OBS_BASIC, then

MDC_ATTR_TIME_STAMP_BO

Basic-Nu-Observed-Value = 2.4 IU/h

Base-Offset-Time-Stamp = (date and time of the bolus delivered)

Insulin PumpExtended Configuration

Must include the Bolus Delivered and Current Basal Rate Setting objects and may

include one or more of the optional numeric and enumeration objects.

Numeric Objects

Bolus Delivered (mandatory)

Current Basal Rate Setting (mandatory)

Current Bolus Setting

Pending Bolus Delay

Basal Delivered

Insulin Reservoir Remaining

Insulin Concentration

Enumeration Objects

Operational Status

PHD DM Status (General disease management status object with common bit

definitions across all specializations)

Insulin Pump Status (Insulin Pump specific status bits)

25

Insulin PumpExtended Configuration (Cont’d)

Schedule-Store Objects

Basal Rate Profile Settings

Insulin to Carbohydrate Ratio Profile Settings

Insulin Sensitivity Profile Settings

26

Contains

Numeric

Objects!

Standards

Workshops and

Toolkits

Adoption of Standard Accelerate manufacturer adoption and implementation

of standards, enabling novel applications and systems

to access patient data from diabetes devices without

excessive barriers.

We Want To Help

To investigate the barriers confronted by individual

manufacturers when implementing standards

To develop software/hardware toolkits

To deliver custom workshops for knowledge transfer and

distribute toolkits to both support and accelerate adoption of

standardized protocols into their technologies