continua implementing fhir - fhir devdays · standards as the framework for new national remote...
TRANSCRIPT
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”