HL7®, FHIR® and the flame Design mark are the registered trademarks of Health Level Seven International and are used with per mission.

Boston, 19-21 June | @HL7 @FirelyTeam | #fhirdevdays18 | www.fhirdevdays.com

Working with Personal Health Devices in FHIR

Melanie Yeung, eHealth Innovation @ UHN

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

• Member of IEEE Personal Health Devices

Working Group

• Member of Bluetooth Medical Expert Working

Group

• Manager of awesome development team

(@ehealthdevs)

Tutorial Objectives - What can you expect?

• Intro to PCHAlliance, standards, and Continua Design Guidelines

• How the Continua Design Guidelines enable the FHIR API for remote person monitoring within the secure medical data exchange

• Consuming Device Data from Home to Hospital – a real world example

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 (October 17-19, 2018 Boston)

H.811 H.812 H.813

H.810

ITU Global Standard = Continua Design Guidelines

http://www.itu.int/rec/T-REC-H.810-201312-I

H.812.5

PHD PHG HFS

Why Continua FHIR based observation upload?

• Many developers find it difficult to work with PCD-01

• Developers feel at ease with web technologies such as JSON, OAuth and HTTP REST.

• FHIR as key enabler for Health 2.0, building an ecosystem of apps and cloud enabled services.

• Easy to develop & test applications due to the availability of open source libraries and FHIR servers

• FHIR as data model for other use cases in the remote patient monitoring domain e.g. patient reported outcomes measures

Health

&

Fitness

COPD

Hyper-

Tensio

n

Heart

Failure

Diabete

s

Care

Enabling integration of patient generated data into electronic health records to support chronic disease management built on HL7 FHIR specifications

http://www.pchalliance.org/news/new-continua-design-guidelines-enable-integration-patient-generated-data-electronic-health

Continua Use Cases (just a few examples)

1. Diabetes:

• Glucose meter, Continuous Glucose Monitor, Insulin Pump, Weight Scale, Blood Pressure Monitor, Heart rate monitor (optional)

2. Hypertension:

• Blood Pressure Monitor, Weight Scale, Heart Rate Monitor

3. Heart Failure:

• Weight Scale, Blood Pressure Monitor, ECG, Heart rate monitor

4. COPD:

• Spirometer, Peak Flow, Thermometer, Pulse Oximeter, Heart rate monitor, CO2 monitor (optional)

5. Health & Fitness and many other use-cases …

Remote Patient Monitoring Requirements

• Automatic, device-reported vital signs, obtained from the PHDs

• Manual, patient-reported vital signs, obtained from the PHDs

• Patient takes episodic (typically up to a few times per day) scalar or short-vector vital signs measurements, notably weight, blood glucose level, blood-pressure plus pulse, ECG rhythm strip, etc

• Association of the measurements with the correct patient, proper timestamping, and potential correction for device-specific inaccuracies

• Batch delivery of measurements to the backend server ( E.g. health record server) for use by the care provider, and eventually without measurements getting lost or corrupted

• Installation and configuration of equipment (PHD, PHG) and facilities (power, phone, Internet), preferably by the patient

• Both single-user (personal) and multi-user (shared with residents) PHDs. (E.g. via multiple logical devices on a single physical device)

• Interoperability between PHD, PHG and backend server.

Pregnancy Disorder Use Case

Pregnancy Disorder Use Case

• 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 5oz 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.

Initial diagnosis

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

• Follow-up lab results urinalysis showed Protein:creatinine 863 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

Home monitoring

• On the fourth day, however, her BP spiked to 142 / 90 mmHg.

• 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 mmHg.

• Following these readings, the CDS concludes that Annie should begin start taking her blood pressure every 2 hours.

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 mmHg.

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

• 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.

Hospitalization

• Upon admission, Annie is monitored every hour using a hospital physiological monitor that also transmits its data to the CDS system.

• The new monitor confirms that Annie’s blood pressure remains high at 150-155 / 100-108 mmHg.

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

• Following this addition of 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.

Pregnancy Disorder Use Case

PHD

Continua E2E Architecture

HIS Interface Services

Interface

Personal Health

Device

Personal Health

Gateway

(PHG)

Health & Fitness

Service (HFS)

Healthcare

Information

System (HIS)

Personal Health

Devices

Interface

11073-IF

BLE-IF

110733 Device

Bluetooth LE Device

Direct to Cloud will be added in 2018

HL7 FHIR added in 2017

Personal Health Devices and Personal Health Gateway

HIS Interface Services

Interface

Personal Health

Device

Personal Health

Gateway

(PHG)

Health & Fitness

Service (HFS)

Healthcare

Information

System (HIS)

Personal Health

Devices

Interface

11073-IF

BLE-IF

110733 Device

Bluetooth LE Device

Direct to Cloud will be added in 2018

HL7 FHIR added in 2017

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).

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)

Bluetooth Special Interest Group (SIG) • Bluetooth SIG Medical Working Group

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

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

Bluetooth Low Energy

SERVICE A

PROFILE

SERVICE B SERVICE C

Characteristic B_2

Descriptors Value Properties

Characteristic B_3 Characteristic B_1

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

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

Supported Specializations and Profiles

Continua PHD/PHG Upload

1. Reuse of 11073 data model in all Phases

2. Keep up with evolving technologies and guidelines relevance for the market

3. Our Lifecycle process is designed to extend, recently introduced more agile development approach

Personal Health

Gateway

(PHG)

Personal Health

Device

11073 Device

Bluetooth LE Device

Payload: PCD-01

Transport: SOAP

Security: SAML 2.0 + TLS

Phase 1 (HL7 V2)

Payload: PCD-01

Transport: hData (HTTP)

Security: OAuth 2.0 + TLS

Payload: FHIR Resources

Transport: Restful FHIR

Security: OAuth 2.0 + TLS

Phase 2 (HL7 V2)

Phase 3 (HL7 FHIR)

Continua Personal Health Device Measurement Upload

• Three FHIR defined resources 1. the Patient Resource,

2. the Device Resource,

3. the Observation Resource.

Observation (Metric OBXes)

Components: (OBX-facets)

Device (PHG)

Patient (PID)

Bundle

Device (sensor)

HTTP POST header

11073 “MDC” PHD Model FHIR Mapping (current)

Medical Device

System (MDS)

Metric

(Abstract)

Numerics /

Enumerations /

Waves

1..*

1..1

Patient

Observation

Device

(PHD MDS Profile)

Blood Pressure Monitoring Device

Observation (BP)

Component: (systolic)

Component: (diastolic)

Component: (MAP)

Device (PHG)

Patient (PID)

Bundle

Device (sensor)

Observation (Pulse Rate)

Patient Resource Challenges for PHDs

Availability:

• patient information is not provided by PHDs through standardized protocols and therefore must be supplied and associated by out-of-band means to a PHG

Privacy:

• PHD measurements are typically taken remotely requiring that any patient information be transferred across the public network.

• For protection of Personal Health Information (PHI) the Continua profile allows PHGs to be supplied with opaque and unique 'key' by out-of-band means that only the health care provider can link to a patient.

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 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 H&FS the generated Logical ID by identifying the Patient Resource using the Patient Designator

Patient Resource

https://api.code.lnihealth.com/hapi-fhir-jpaserver-example/baseDstu3/Patient/AnnieID-9.8.7.6.5.4.3.2.1/_history/1

Device 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 Device Resource shall be unique on the H&FS and should be set to IEEE systemId-Transport Address or if not available, then should be set to UUID

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)

Observation Resource

• “profile”

Observation Resource cont’d

• “category”

Observation Resource cont’d

• “code”

IEEE 11073-10101 Nomenclature

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

MDC_PRESS_BLD_NONINV_DIA = 2*2^16+18950 = 150022

Observation Resource cont’d (Compound Numeric)

• “component”

Summary of Continua Requirements

1. Gateway should map IEEE 11073 or Bluetooth LE data to the following FHIR Resources

2. Gateway is expected to use either JSON or XML when uploading a measurement while the server shall support both

3. Server shall exposes FHIR capabilities via Capability Exchange

4. Security

• OAuth 2.0 is mandatory

• Gateway shall use either Client Credentials or Resource Owner Credentials as grant type, while Server shall support both

• Other grant types such as “Authorization Code” are optional • Measurements must be uploaded using a secure TLS section using a valid OAuth Bearer Token

Continua Personal Health Device Data Implementation Guide (v0.1.0)

• guide describes how information from Continua-certified personal health devices (PHDs) is represented in FHIR

• STU3 Ballot (v0.1.0) of the Devices on FHIR Personal Health Device (PHD) Implementation Guide, based on FHIR STU3 (Version 3.0.0

http://hl7.org/fhir/uv/phd/2018Jan/index.html

What’s next for Continua and FHIR?

1. FHIR Retrieval API

2. Continua FHIR profiles for Patient Reported Outcomes Measures

3. Direct to Cloud Use Case