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
