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
61
Embed
Continua Implementing FHIR - FHIR DevDays · standards as the framework for new national remote health and social care program Sweden (April 2016) announced open architecture based
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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 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
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
• 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
• 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
• 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