The IoMT FHIR Connector for Azure is an open-source project for ingesting data from IoMT (internet of medical things) devices and persisting the data in a FHIR® server. The goal of this Microsoft Healthcare project is to enable developers to rapidly deploy a service for ingesting high frequency IoMT data and landing the data in a FHIR server of their choice.
Device data can be directly written to the IoMT FHIR Connector for Azure or seamlessly used in concert with other Azure IoT solutions (IoT Hub and IoT Central). Please be aware the the connector itself is an open-source project and does not provide device security or management. The Azure IoT solutions themselves support compliance with national, regional, and industry-specific requirements.
The IoMT FHIR Connector for Azure is intended only for use in transferring and formatting data. It is not intended for use as a medical device or to perform any analysis or any medical function, and the performance of the software for such purposes has not been established. You bear sole responsibility for any use of this software, including incorporation into any product intended for a medical purpose.
The IoMT FHIR Connector for Azure is built with extensibility in mind, enabling developers to modify and extend the capabilities to support additional device mapping template types and FHIR resources. The different points for extension are:
- Normalization: Device data information is extracted into a common format for further processing.
- FHIR Conversion: Normalized and grouped data is mapped to FHIR. Observations are created or updated according to configured templates and linked to the device and patient.
The IoMT FHIR Connector for Azure empowers developers – saving time when they need to quickly integrate IoMT data into their FHIR server for use in their own applications or providing them with a foundation on which they can customize their own IoMT FHIR connector service. As an open source project, contributions and feedback from the FHIR developer community will continue to improve this project.
- R4 FHIR server with support for Device, Patient, and Observation resources.
- OAuth 2.0 identity provider with configured client credentials granted access to the FHIR server.
- An existing device resource and patient resource on the FHIR server. The device should be linked to the patient. Please note the identity extracted for the device during the normalization step should be a device identifier not the internal id.
- A device content template uploaded to the template storage container. See Configuration for more information.
- A FHIR mapping template uploaded to the template storage container. See Configuration for more information.
Deploy the IoMT FHIR Connector for Azure with a FHIR service in Azure Health Data Services, Azure Event Hub and all other required dependencies. Setting the
Resource Identity Resolution Type to
Create during deployment will create Patient and Device resources when messages are processed. See here for more information about
Resource Identity Resolution Type.
When the IoMT FHIR Connector for Azure is deployed using the instructions outlined [BicepInstallation.md], sample templates are uploaded for testing. Test messages can be sent to test the deployment using the Event Hubs Data Generator.
Ingest: The ingestion point for device data is an Event Hub. Scale your Event Hub throughput units based on your message volume.
Normalize: Device data is processed and compared to templates defined in the
devicecontent.jsonconfiguration file. Types, values, and other important information are extracted. The output is written to a second Event Hub.
Group: Normalized data is grouped according to device identity, measurement type, and the configured time period. The time period controls the latency that observations are written to FHIR.
Transform: Output from the group and buffering stage is processed. Observations are created by matching the types from the grouped normalized data to the templates defined in the
fhirmapping.jsonconfiguration file. It is at this point that the device is retrieved from the FHIR server along with the associated patient.
Note all identity look ups are cached once resolved to decrease load on the FHIR server. If you plan on reusing devices with multiple patients it is advised you create a virtual device resource that is specific to the patient and the virtual device identifier is what is sent in the message payload. The virtual device can be linked to the actual device resource as a parent.
Persist: Once the observation is generated in the FHIR conversion step it is created or merged in the configured destination FHIR server.
- Configuration: Documents the different configurations required for the connector.
- Connecting to Azure IoT: Describes how to set up the IoMT FHIR Connector using Azure IoT Hub.
- Debugging: Documents steps for local and cloud debugging.
This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.
When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.
There are many other ways to contribute to IoMT FHIR Connector for Azure.
- Submit bugs and help us verify fixes as they are checked in.
- Review the source code changes.
- Engage with IoMT FHIR Connector for Azure users and developers on StackOverflow.
- Contribute bug fixes.
See Contributing to IoMT FHIR Connector for Azure for more information.
FHIR® is a registered trademark of Health Level Seven International, registered in the U.S. Trademark Office and is used with their permission.