FHIR compliant healthcare Architecture
Healthcare industry has been a ripe area for invention across the different areas of it its operations –provider and payer solutions, innovations in pharmaceuticals and biotech, better engagement with the patients to focus on measurable health outcome. In order for a platform to provide a useful service, it is important that it adheres to the regulatory and compliance standards of the healthcare industry. In this article, we provide pointers to reference architectures that enable developers to build robust healthcare solutions that are interoperable and compliant.
A good starting point is to understand a high level overview of the standards that the platform needs to support. The most common one that developers in the healthcare domain need to understand is FHIR. FHIR is acronym for Fast Healthcare Interoperable Resource. FHIR combines the best features of the earlier Health Level Seven(HL7) versions V2, V3, and the Clinical Document Architecture (CDA). The design for FHIR is based on RESTful web services compared to using SOAP based messaging used in Integrating the Healthcare Enterprise (IHE). IHE mainly used the Digital Imaging and Communications in Medicine (DICOM) and HL7 standards. Another standard that is often discussed about is the SMART standard. It is an acronym for Substitutable Medical Applications, Reusable Technologies. The goal for SMART is that a developer can write an app once, and expect that it will run anywhere in the health care system. Further, the app should be readily substitutable for another.
Microsoft Azure has robust set of services to build a solutions in healthcare domain that are compliant with the FHIR standard. Below is an example of a reference solution architecture.
It makes sense to break this architecture into logical components meant to ingest, persist, query, derive intelligence, and reporting. The cross cutting concerns of application and network level security, monitoring, and authentication are shown at the bottom of the diagram. A few salient features for the different layers are listed below:
Ingest Layer
- There are multiple sources from which data can be input as shown on the left. These span from Internet of Medical Things (IoMT) to standard healthcare inputs that contain Electronic Health Records, Imaging, Billing etc. The IoMT devices are interesting because of the volume and velocity of this incoming data that is ingested real time. Here are some examples for these IoMT devices. Fitness wearables like Fitbit and iWatch, smart shoes from Under Armour, Continuous Glucose Monitoring devices, connected inhalers, automated insulin delivery, pacemakers, Smart Pills (drug with a sensor that gets activated once ingested in the stomach. Upon activation, the data about pill consumption is transmitted to wearable patch on the patient’s arm and picked up by the smartphone app). For the data coming in through IoMT devices, it is recommended to use an IoT hub to enable bidirectional communication and the high rate of input data.
- The rest of the data from “traditional” healthcare systems flows in through the event hub. A function is triggered activated by data entering the event hub to serve as an endpoint for the incoming data to be sent downstream.
- Azure Data Factory (ADF) helps to massage the data (format/transform) to be sent data to the persist stage
Persist Layer
- The incoming processed data is stored in an Azure Data Lake (ADL)
- The data from the Function endpoint and ADF is processed by FHIR compliant endpoint (PaaS or an IaaS) and the results are persisted in ADL
Query Layer
- The results can be queried by Azure Search or run any OLAP like analytics on Synapse analytics or be fed to Data Bricks. Data Bricks is powerful with Machine Learning and Deep Learning capabilities, has built in workflows, and has native support to run R and Python based Notebooks for data scientists.
Intelligence Layer
- This layer leverages Azure Cognitive Services for Image, Speech, Natural Language Processing (NLP) based analytics. One can also use Auto ML capabilities and ML Studio for more of a drag and drop analytics experience. In order to build interactive virtual agent solutions and smart bots, Microsoft Language Understanding Intelligent Services (LUIS) can be used.
Reporting Layer
- Depending on the healthcare app, the users can view the results on different platforms and form factors. The popular option for dashboard solutions is Power BI, Teams can be used as the platform to publish virtual agents and bot solutions, and you can pick from Web App, Mobile App, Office 365, Dynamics 365 to connect with the provider, payer, or the patient for an end to end experience.
The two options in the scenario shown below double clicks on the Ingest/Persist layers to illustrate connecting a web application to a FHIR compliant service.
The key components in the solution are pretty straight forward.
- The solution uses data from Synthea and is contained into a BLOB container in an Azure Storage container.
- An azure function job takes this data and bulk ingests by a FHIR compliant service (either a PaaS or a Server).
- Ingested data is exported to a storage account and data can be further fed to downstream consumer by using Data Bricks for analytics.
- The architecture also shows a SMART on FHIR Active Directory Proxy. This service handles the authorization of the incoming requests. Azure AD supports OAuth2 authorization but SMART on FHIR expects a specific format to initiate the authorization request. An example URL with the format is listed below:
https://auth-server/authorize?aud=https://fhir-server&client_id=XXX&scope=patient/*.read&...
The proxy translates the parameter specifications provided by SMART on FHIR application into a format that Azure AD can accept (in OAuth2 format)
In the first diagram, the FHIR compliant service is an Azure API for FHIR PaaS server an in the second scenario, it is the open source FHIR Server for Azure.
It is generally considered a challenge to get patient data for legal and practical reasons when building a prototype for a healthcare application, but you can use the Synthea open source patient generator that models the medical history of synthetic patients. This dataset provides high quality, synthetic, realistic (but not real) patient data and associated health records. The data is free to use to build a proof of concept and does not have any privacy restrictions. More information at https://synthetichealth.github.io/synthea/
More information about the solution available at https://github.com/Microsoft/fhir-server-samples
