FHIR® is the registered trademark of HL7 and is used with the permission of HL7. The Flame Design mark is the registered trademark of HL7 and is used with the permission of HL7.

Amsterdam, 15-17 November | @fhir_furore | #fhirdevdays17 | www.fhirdevdays.com

Continua Implementing FHIR

Melanie Yeung, eHealth Innovation @ University Health Network

About Me

• Name: Melanie Yeung @melaniesyeung

• Company: eHealth Innovation, University Health Network @Official_eHI

• Background:• Trained as a Clinical (Biomedical) Engineer

• Member of PCHAlliance/Continua Health Alliance

• Member of IEEE Personal Health Devices Working Group

• Member of Bluetooth Medical Expert Working Group

• Co-manager of awesome dev team (@ehealthdevs)

My Daytime Job

• Research centre in Toronto, Canada

• Affiliated with the University of Toronto

• Unrivaled access to patients, healthcare professionals and researchers

• 70+ scientists, engineers, project managers, psychologists, human factors specialists, developers, designers, and students

Tutorial Objectives - What can you expect?

• Intro to PCHAlliance, Device Standards, and Continua Design Guidelines

• Device Data Upload using FHIR® Observations

• Consuming Device Data from Home to Hospital• Preeclampsia Use Case

Personal Connected Health Alliance

• improve efficiencies and reduce cost

• advance prevention over treatment

• promote individual ownership and control over personal health data, including the ability to share it with one’s healthcare provider, caregivers or social network

• improve communication and data exchange between patients and providers

• create new incentives for a movement towards personal responsibility and engagement in one’s own health

Published annually, PCHAlliance’s Continua Design Guidelines define a flexible framework for user friendly end-to-end interoperability of personal connected health devices and systems. Continua certified products bear the globally recognized Continua logo, which signals market-readiness for 21st century health data exchange. The Guidelines are recognized as an international standard by the United Nations’ International Telecommunication Union (ITU-T) and available free in six languages.

PCHAlliance’s flagship event, the Connected Health Conference, is the premier international conference and expo for the exchange of research, evidence, ideas, innovations and opportunities in connected health. Formerly the mHealth Summit, and now in its ninth year, the event features industry-leading keynote presentations, dynamic programming, poster presentations, an interactive exhibit floor, and high-value networking sessions. www.ConnectedHealthConf.org

Continua Interoperability Ecosystem

Capture &Collect

Display &Consume

1 3Aggregate, Normalize,

Store & Forward

2

Continua Design Guidelines (CDG)

10

https://www.itu.int/rec/T-REC-H/en

Truly Open Design Guidelines

• Continua guidelines are endorsed by a neutral leader• International Telecommunication Union (ITU),

the global standards agency of the United Nations

• Anyone can get the Continua guidelines for FREE • In six languages• Download via ITU or: www.pchalliance.org/continua-design-guidelines

• Anyone can submit comments• Via Continua or ITU

• Any party welcome to join PCHAlliance at the level of choice • Easy market access for vendors, no vendor lock-in for users• Contribute to new versions

Commercial Ready Platforms

Continua Enabling Software Libraries (CESL)Continua Test Tool (CTT)

Speed the adoption

Reference source code

Testing Prototypes

Basis for Continua Test Tool

Creation of reference devices

for IOP

Existing New

Continua Code and Testing Today and Tomorrow

Key Alliances

Towards adoption in Europe: Oct 2017 highlights

Denmark: (2012) National health IT strategy sets out reliance on (Continua); roll out of national COPD services in 2018.

Norway: (Dec. 2014) MoH announced Continua standards as the framework for new national remote health and social care program

Sweden (April 2016) announced open architecture based on Continua Guidelines

European Commission: (2013) Continua referenced alongside IHE in European eHealth Interoperability Framework

Finland: (Oct 2017) MoH launches personal health record in Dec 2017, expressed interest in diabetes pilot with Continua in 2018.

eHealth Network: (May 2017) Invited six governments to present at Malta meeting; new MWP being prepared, led by SPMS

Austria: (Oct 2017) MoH published technical framework directive for telemonitoring with Continua

Catalonia (July 2017) MoH mandates Continua compliance for glucose meters to connect with personal health record

Portugal: (Oct 2017) SPMS will test sleep apnea products for Continua compliance at Boston Plugfest

Data Exchange Landscape

15

Personal Health Devices Interface (PHD-IF)

16

Continua Design Guidelines supports devices that can use :• an interface based on ISO/IEEE 11073-

20601 (X73-IF)and a supported transport technology (ZigBee, NFC, USB and Bluetooth BR/EDR)

• an interface based on a Bluetooth LE (BLE-IF) as transport, technology and one or more (application level) services and profiles defined by Bluetooth Special Interest Group (SIG).

Institute of Electrical and Electronics Engineering

• IEEE-11073 Personal Health Devices (PHD) Working Group

• Focus on interoperability of personal health devices for personal use

• Transport agnostic

• Open group, including both industry and academic participation

• Easy access and low cost to published standards

IEEE 11073- PHD’S FOCUS

Agent (aka. Sensor)

• Exchange Protocol + Device Specializations• Domain Information Model (DIM)

• Service Model

• Communication Model

• Device-specific information

• Supported Domains:• Disease Management

• Health and Fitness

• Aging Independence

Manager (aka. Client)

Domain Information Model (DIM)

• Describes the device and physiological data

• Object oriented model

• No requirement to implement in object oriented language

• Generic set of classes created

• Classes define attributes and methods• Attribute type defined in ASN.1 (language for abstract modeling of

data and interactions)• Objects are tailored using the attributes

• Attributes may be:• Mandatory, optional, or conditional• Static or dynamically changing

Services

Actions

Services

Actions

Services

Actions

Services

Actions

Eventing Eventing Eventing

Object 1

• attribute 1

• attribute 2

• attribute 3

• attribute 1

• attribute 2

• attribute 3

• attribute 4

Object 2 Object 3

• attribute 1

• attribute 2

• attribute 3

• attribute 1

• attribute 2

• attribute 3

• attribute 4

Object 4

Agent DIM

IEEE 20601: Objects

Sensor

PM-Store Object ‘n’Agent’s hard disk

*optional*

MDS ObjectDevice’s bureaucratic and system

information

*must have*

Metric Object ‘k’Describes a measurement

(e.g. weight, status, waveform)

*optional*

Scanner Object ‘m’Formats and groups for data

transmission (eventing)

*optional*

IEEE 11073-10407 Blood Pressure Monitor

-00103 Technical Report - Overview

Device Specializations

-10404Pulse

Oximeter

-10407Blood

Pressure

-10408Thermo-

meter

-10415Weighing

Scale

-10417GlucoseMeter

-10441Cardio

-10419InsulinPump

-10425CGM

-104xx…

-20601 Optimized Exchange Protocol

Communication Protocols

NFC Bluetooth BR/EDR USB 2.0 ZigBee OSI

Lay

ers

4-5

OSI

Lay

ers

6-7

IEEE Standards and Specializations

NFC PHD class Bluetooth HD profile USB PHD class ZigBee HC class

Completed Standards (20 / 29)• IEEE Std 11073-10404 Dev specialization – Pulse oximeter

• IEEE Std 11073-10406 Dev specialization – Basic ECG

• IEEE Std 11073-10407 Dev specialization – Blood pressure monitor

• IEEE Std 11073-10408 Dev specialization – Thermometer

• IEEE Std 11073-10415 Dev specialization – Weighing scale

• IEEE Std 11073-10417 Dev specialization – Glucose meter + Revision + Revision

• IEEE Std 11073-10418 Dev specialization – INR (blood coagulation) + Corrigendum

• IEEE Std 11073-10419 Dev specialization – Insulin Pump +Revision

• IEEE Std 11073-10420 Dev specialization – Body composition analyzer

• IEEE Std 11073-10421 Dev specialization – Peak flow

• IEEE Std 11073-10422 Dev specialization – Urine analyzer

• IEEE Std 11073-10424 Dev specialization – SABTE +Corrigendum

• IEEE Std 11073-10425 Dev specialization – CGM +Revision

• IEEE Std 11073-10427 Dev specialization – Power Status Monitor(PSM)

• IEEE Std 11073-10441 Dev specialization – Cardiovascular + Revision

• IEEE Std 11073-10442 Dev specialization – Strength fitness equip

• IEEE Std 11073-10471 Dev specialization – Activity hub

• IEEE Std 11073-10472 Dev specialization – Medication monitor

• IEEE Std 11073-20601 Optimized exchange protocol + Amd + Rev+Cor

• IEEE Std 11073-00103 Personal health device communication -Overview

Projects Underway (12)

• IEEE P11073-10426 Dev specialization – Home Healthcare Environment Ventilator (New)

• IEEE P11073-20601 Optimized exchange protocol (Revision)

• IEEE P11073-10404 Dev specialization – Pulse Oximeter (Revision)

• IEEE P11073-10407 Dev specialization – Blood Pressure Monitor (Revision)

• IEEE P11073-10408 Dev specialization – Thermometer (Revision)

• IEEE P11073-10415 Dev specialization – Weighing Scale (Revision)

• IEEE P11073-10420 Dev specialization – Body composition analyzer (Revision)

• IEEE P11073-10406a Dev specialization – Basic ECG (Revision)

• IEEE P11073-10471a Dev specialization – AI Living Hub (Revision)

• IEEE P11073-10425 Dev specialization – Continuous Glucose Meter (Revision)

• IEEE P11073-10419 Dev specialization – Glucose Meter (Revision)

• IEEE P11073-10428 Dev specialization – Electronic Stethoscope

Regulatory Recognition

Bluetooth Special Interest Group (SIG)

• Bluetooth SIG Medical Working Group

• Scope: to improve the user experience for Bluetooth-enabled medical, healthcare, and fitness devices

• Industry-focused, closed group (membership required to develop standards)

Bluetooth Core Specifications

https://www.bluetooth.com/specifications/bluetooth-core-specification

Bluetooth Generic Attributes (GATT) Specifications

• GATT profile• describes a use case, roles, and general behaviors based on the GATT

functionality, enabling extensive innovation while maintaining full interoperability with other Bluetooth® devices.

• GATT services• collections of characteristics and relationships to other services that

encapsulate the behavior of part of a device.

GATT Specifications (Medical Device)

• BLP/BLS Blood Pressure Profile/Service

• CGMP/CGMS Continuous Glucose Monitoring Profile/Service

• GLP/GLS Glucose Profile/Service

• HRP/HRS Heart Rate Profile/Service

https://www.bluetooth.com/specifications/gatt

• HTP/HTS Health Thermometer Profile/Service

• PLXP/PLXS Pulse OximeterProfile/Service

• WSP/WSS Weight Scale Profile/Service

• IDP/IDS Insulin Delivery Profile/Service (in development)

Hierarchy

SERVICE A

PROFILE

SERVICE B SERVICE C

Characteristic B_2

DescriptorsValueProperties

Characteristic B_3Characteristic B_1

IEEE and Bluetooth

Personal Health Devices Interface

Services Interface

CDG Technical

Continua Device Data to FHIR® server Upload Objectives

• Ensure no loss of information

• Equivalent to what is available via IHE PCD-01 upload

• Represent information using HL7 Defined FHIR® resources

• Support secure, interoperable uploads from Personal Health Gateway to Health & Fitness Service• https transport

• OAuth-2 based authorization framework

• Allow consumer choice in PHGs

Data Exchange Landscape

36

Service-IF

37

Continua Design Guidelines specify three implementations for uploading HL7 V2.6 Observations payloads:• IHE PCD-01 message packaged in

SOAP and authenticated using SAML,

• HL7 FHIR Resources via REST and OAuth, and

• IHE PCD-01 message sent over HL7 hData Framework and hDataREST transport binding.

Service-IF

38

Continua Design Guidelines specify three implementations for uploading HL7 V2.6 Observations payloads:• IHE PCD-01 message packaged in

SOAP and authenticated using SAML,

• HL7 FHIR Resources via REST and OAuth, and

• IHE PCD-01 message sent over HL7 hData Framework and hDataREST transport binding.

HL7 v.2.6 HL7 v.3.0 HL7 FHIR STU3

11073 “MDC” Device Info Model (highly simplified!)

Physical Top-Level Device Info (ID, H/W & S/W versions, battery …)Medical Device System (MDS)

Virtual Medical Device (VMS)

Channel

Metric

Device Subsystem Info (BP, ECG, temp …)

Related Parameter Group Info (ECG Channel #1, #2, #3, …)

Parameter Metadata Info (Datatype independent info, e.g. period)

1..*

1..*

1..*

Numerics / Enumerations /

Waves

1..1

Parameter Info (Value + datatype-specific elements)

Defined in ISO/IEEE 11073-10201 & 11073-20601

11073 “MDC” PoCD Model FHIR Mapping (current)

Medical Device System (MDS)

Virtual Medical Device (VMS)

Channel

Metric(Abstract)

Numerics / Enumerations /

Waves

1..*

1..*

1..*1..1

Device

Patient

Observation

DeviceComponent(MDS Profile)

DeviceComponent(VMD Profile)

DeviceComponent(Channel Profile)

DeviceMetric

11073 “MDC” PHD Model FHIR Mapping (current)

Medical Device System (MDS)

Metric(Abstract)

Numerics / Enumerations /

Waves

1..*

1..1

Patient

Observation

DeviceComponent(PHD MDS Profile)

Continua Personal Health Device Measurement Upload

• Three FHIR defined resources 1. the Patient Resource,

2. the DeviceComponent Resource,

3. the Observation Resource.

42

Observation (Metric OBXes)Components: (OBX-facets)

DeviceComponent (PHG)

Patient (PID)

Bundle

DeviceComponent (sensor)

HTTP POST header

Patient Resource

• Managing Patient Identity• PHG must properly reference the patient resource in any observation

resource being uploaded

• In the FHIR protocol this is done by having the PHG provide the Logical ID of the patient resource to the FHIR server.

• Potential challenges in obtaining the Logical ID of the patient resource for the PHG• PHG must know the Logical ID of the Patient Resource, or

• must be able to provide a Patient Designator which will allow the Logical ID to be located

Patient Resource (Scenario – Logical ID is provided)• Logical ID is

communicated to the H&FS party responsible for configuring the PHG in the home environment.

• PHG is configured with the appropriate Logical Identification of the Patient Resource

Patient Designator (Scenario – Logical ID is not provided)Patient Designator is:

• other information, which identifies the patient

• can represent a wide range of different forms of patient identity, appropriate to different situations

• contains information about who the assigning authority is, and how the patient is identified by that assigning authority

• is used to establish the identity of the patient in the uploading of a measurement

• Patient Designator is can be used to generate a FHIR Patient Resource 1) PHG takes the responsibility of specifying the Logical ID of this resource, which must be

unique when used in the FHIR server

2) PHG obtains from HF&S the generated Logical ID by identifying the Patient Resource using the Patient Designator

DeviceComponent Resource

• Characteristics, operational status and capabilities for a component of a healthcare device. Used to describe PHG or sensor attributes such as:• System ID

• Device Type

• Production specification

• Regulation certification information

• Time synchronization/capabilities

• The Logical ID of the DeviceComponent Resource shall be unique on the H&F and should be set to IEEE systemId-Transport Address or if not available, then shouldbe set to UUID

46

Observation Resource

• mapping of [ISO/IEEE 11073-20601] to FHIR is primarily through the IEEE nomenclature codes • codes describe what the measurement is, the units, and can be the

measurement itself.

• mapped to the appropriate FHIR CodeableConcept elements

Measurement representation (Metric Object)

Continua Data Use Cases (just a few examples)

Use Case Overview

• Annie is a 31 y.o. female, 1st pregnancy

• Asymptomatic hypertension (DBP > 90-99mmHg SBP > 140-149mmHg) and proteinuria (conc. 30mg/dl >1+ dipstick) > 20wk gestation

• She delivered a healthy 7lbs 5 oz baby boy 1/29/2017 at 19:50 following induction at 37 + 6 weeks.

• Infant was delivered vaginally without complications, APGARS 8/9. Infant and mother transitioned normally to the postpartum ward and were discharged to home on Hospital Day 2.

50

Initial diagnosis

• Annie first presented at wk35 prenatal visit with +3 proteinuria dipstick

• Follow-up lab results urinalysis showed Protein:creatinine863 mg/mmol (norm <30mg/mmol)

• Home blood pressure readings (taken every 6 hours) ranged from 98-114 / 65-76 mmHg.

• Daily home dipstick shows –ve results

51

Home monitoring

• On the fourth day, however, her BP spiked to 142/90.• This data was analyzed by the CDS system that automatically sent her an SMS

text message reminding her that she was to repeat the measurement every hour for 3 hours.

• When repeating the measurements, her BPs are still 140-149 / 90-99.

• Following these readings, the CDS concludes that Annie should begin start taking her blood pressure every 4 hours.• The system sends an SMS text to Annie and an EMR alert to her provider

notifying them of the recommendation.

• Upon receiving the alert, Annie’s provider logs into the EMR and reviews the vital signs obtained at home.

52

Analysis and Escalation

• Over the next 48 hours, Annie dutifully records her blood pressure.

• Annie’s blood pressures continue to trend up, now ranging between 150-155 / 100-108.

• CDS concludes that Annie needs to be evaluated and stabilized as an inpatient.

• System sends an SMS text to Annie and a traditional EMR alert to her provider notifying them of the recommendation.

• Upon receiving the alert, Annie’s provider logs into the EMR, reviews the home vital signs before arranging for her admission.

53

Hospitalization

• Upon admission, Annie is monitored every hour x 2 using a hospital blood pressure device that also transmits its data to the CDS system.

• The new monitor confirms that Annie’s blood pressure is ranging between 150-155 / 100-108.

• CDS system alerts her provider, recommending that her therapy be augmented with oral medication.

• Following this addition to her oral therapy, Annie’s blood pressure normalizes over the next 48 hours to 100-125 / 65-80 mmHg and she is subsequently discharged to complete her home remote monitoring.

54

Noninvasive Blood Pressure Monitor Device

• Typically two numbers reported • Systolic pressure: contraction of the

heart

• Diastolic pressure: relaxation of the heart

• Third number may be available• Mean arterial pressure

• Units of measurement (mmHg)

• Pulse Rate (/min) *optional

Observation (BP)Component: (systolic)Component: (diastolic)

Component: (MAP)

Device (PHG)

Patient (PID)

Bundle

Device (sensor)

Observation (Pulse Rate)

Blood Pressure:

Patient Resource

• Annie Pchaid

https://fhirtest.uhn.ca/baseDstu3/Patient/PatientId-anniepchaId/_history/1

DeviceComponent Resource

https://fhirtest.uhn.ca/baseDstu3/DeviceComponent/SysId-0000000000000000

Observation Resource

• “profile”

Observation Resource cont’d

• “category”

Observation Resource cont’d

• “code”

• “subject”

IEEE 11073-10101 Nomenclature

62

Encoded value for the code element = (partition)*2^16 + (IEEE reference ID)

MDC_PRESS_BLD_NONINV_DIA = 2*2^16+18950 = 150022

https://rtmms.nist.gov/rtmms/index.htm#!rosetta

Observation Resource cont’d (Compound Numeric)

• “component”