iomt - high frequency data in fhir - fhir devdays · with automation remote / in-patient home care...

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

November 20-22, Amsterdam | @HL7 @FirelyTeam | #fhirdevdays | www.devdays.com

IoMT - High Frequency Data in FHIR

Dustin Burson

Dustin Burson

• Software Engineer at Microsoft

• Health Cloud and Data Team

• Focus on IoMT devices

IoMT FHIR Connector for Azure https://github.com/microsoft/iomt-fhir

Quick Demo

Demo - Continued

Session Outline

• Define IoMT

• Key Scenarios

• Building for IoMT

• Challenges Encountered

• Lessons Learned

• Existing Support in FHIR

• What we have built

• Future Improvements

What is IoMT?

Internet of Medical Things

• Subset of IoT devices

• Patient health data

• Devices can be…

• Worn

• Ambient

• Used

Internet

of

Medical

Things

Key Scenarios

Use sensors and PROs to

monitor patients

Use sensors and PROs to

monitor patients

Streamline hospital processes

with automation

• Remote / In-patient • Home Care / Telemedicine

• Prevent Patient Readmission

• Early Intervention

Patient Monitoring Research Smart Hospitals

• Clinical Trials • Drug Discovery

• Model Development

• Augment Care teams • Improve workflow safety

and efficiency

Why is Microsoft releasing IoMT solutions? 1. Simplify sharing IoMT data with

physicians and researchers

2. Promote and bootstrap experimentation and learning

3. Support and Evangelize FHIR

Building for IoMT

• Ingest high frequency data

• Low latency

• Associate data to patient

• Support a multitude of devices

• Interoperability

• Privacy and Security

• Support data analytics & ML

Challenges Encountered

• Late arriving data

• Out of order data

• Duplicates

• Error handling

• Linking data to patient

• Balancing latency and load on the FHIR server

• Each device represents data differently

• Keeping number of FHIR resources created reasonable

Lessons Learned

• Single value observations are not sufficient

• Collecting data on device presents problems

• Device complexity

• Introduces latency

• Code portability

• FHIR on devices can be hard

• FHIR is evolving

• FHIR payloads can be large

Storing in FHIR – Sampled Data

• Sequence of values

• Period in milliseconds

• All values for the observation period should be represented

• Missing data represented by “E”

“valueSampledData” : { “origin” : { … }, “dimensions” : 1, “period” : 1000, “data” : “88 89 E E E 77 75 79 81”, }

IoMT FHIR Connector for Azure

Normalize Group Transform Persist

Transforms data into FHIR Observations

Persists Observations to a FHIR Server

Groups data by device, type and time

Normalizes an intermediate to a format

Key Benefits

Scalability

Azure

Interoperability

FHIR

Development Time and

Infrastructure Cost

SECURITY AND COMPLIANCE (Designed for HIPAA, HITRUST, GDPR)

Cost & Time Savings

IoMT FHIR Connector for Azure

• High frequency ingestion

• Can scale with your workload

• Design for compliance

• Configurable end to end latency

• Seamlessly connect to Azure IoT

• Extend with additional analytics

• IoMT data stored in FHIR

Requirements and Setup

• R4 FHIR server

• OAuth 2.0 identity provider

• An existing device resource and patient resource on the FHIR server

• Device content and FHIR mapping templates

Not Covered

• Individual Device Security

• Device Management

• Device Provisioning

• Patient Provisioning

Normalization

• Match and Extract

• Templates use JSONPath

• Configuration evaluated per message batch

• Projection

Normalized

heartrate : 59

name : heartrate value : 65 name : heartrate value : 59 name : heartrate value : 88

Normalization - Projection

Normalized name : heartrate value : 59 name : steps value : 5 name : hrv value : 67

“steps” : 59

“heartrate” : 59

“hrv” : 67

Template Example

{

“Body” : { “hr” : “88”, “date” : “2019-02-12T22:01:55”, “deviceId” : “device123”, }

}

{

“typename” : “heartrate”, “typeMatchExpression” : “$..[?@hr]”, “deviceIdExpression” : “$.deviceId”, …

}

Template Example Continued

{

“Body” : { “hr” : “88”, “date” : “2019-02-12T22:01:55”, “deviceId” : “device123”, }

}

{ …

“timestampExpression” : “$.date”, “values” : [ {

“valueExpression” : “$.hr”, “valueName” : “heartrate”

}

]

}

Grouping & Buffering

• Leverages Azure Stream Analytics

• Grouped according to type, window date, and device

• Controls end to end latency

• Job partitioned by device id

• Should be scaled with Event Hubs

FHIR Conversion

• Define Period

• Define Codings

• Set data type

• Maps data to correct observation

• Identifier handled by system

• Linking to patient & device

• Component support

Persistence

• Data in connector is transient

• Final destination is a FHIR server

Getting Started

Clone the Repo Deploy the ARM Template

Upload Configurations

Open, Extensible, Easy to Deploy

How can we improve?

Limit History Creation

• As E2E latency is reduced the number of history records increase

• Append to observation while in preliminary status

• While in preliminary status history records won’t be created

• History created normally once the observation is final

Sparse Data Streams

• Can be high frequency but short duration

• SampledData type usually results many “E” values in the data stream

• New type with defined time dimension or offset

• Avoid loss of accuracy

Summary

• Defined IoMT

• Covered Challenges and Lessons Learned

• Overview of IoMT FHIR Connector for Azure

• Future improvements

Thank you https://github.com/microsoft/iomt-fhir

Star the repository Contribute to the project See us after

www.devdays.com