doc.ai is on fire. Oops we mean FHIR:)
What is FHIR and why are we even writing about it?
Fast Healthcare Interoperability Resources (FHIR, pronounced “fire”) is a new standard proposed by HL7. It is a collection of data formats, rules, and an API to exchange medical record information. FHIR tries to make things simpler for the developer. It leverages existing logical and theoretical models to provide a consistent, easy to implement, and rigorous mechanism for exchanging data between healthcare applications.
Why does this matters to us at doc.ai?
We are building a platform for building predictive models using user’s health data. We have written about our OMICS based data collection approach. OMICS data enables valuable health information to be representable in formats that allow us to perform machine learning on the data, as well as standardize it for transmission.
To build a predictive model platform some of the key problems that we are solving are:
- A standardized representation of the medical concepts to construct a prediction feed for users and enable them to train their own AI.
- A standardized unit of measure for each medical concepts to extract and compare the values against our baseline ontology and build the biomarkers that we will launch as part of our biomarkets later this year.
- A way to identify PHI and PII fields to anonymize data for data trials on our Transient platform. Further, this data should have conformant standards so data scientists on our platform can build reliable machine learning models in the industry.
Having a well-defined data dictionary is critical to perform anything more than just displaying the information back to the user. This is why FHIR matters to us. We think with FHIR we have a chance to use a common standard that is gaining significant momentum in the industry. We will be using FHIR to represent our data schemas.
Challenges of interoperability : for a long time now, the world of healthcare has suffered from data interoperability issues. Medical data gets created in silos, and there are no structured and well-defined pathways for the data to be exchanged between these silos.
For example, data that is captured by your primary care physician is not necessarily easily compatible with the data that your specialist is capturing at a hospital. You may have some lab tests at your local lab, but it is not readily portable back to your PCP and your specialist. Your prescription lives at your pharmacies, and it doesn’t necessarily make it back to the systems your doctors use. The data becomes fragmented, and it is hard to stitch together a complete longitudinal view interfering in providing continuity of care.
There have been several attempts in the past — HL7 v2, HL7 v3, and CDA each with their own limitations. To some extent there are too many standards one might say.
How are we using FHIR?
To show the value of having a structured schema for medical concepts using FHIR, we would like to demonstrate what we have in our beta mobile app.
Proteomics is the class of data that relates to proteins which include lab results for blood and urine tests. Using our importers technology for medical records or labs you can import your lab results. As part of the import process, we classify each test and its components into well know biomarkers using our ontology. This allows us to group all the blood-related tests. We go one step further — having classified each of the components from your lab as blood biomarkers, example HDL Cholesterol, we can provide you range information about each marker. We can tell you whether it is normal, high or low. You can tap on each marker to see more information as shown above.
In order to do this we need a standard representation of data. The FHIR representation of this HDL biomarker is as follows:
As you can notice this is part of the observation type of data from the diagnostics category. Additionally, there are LOINC codes on the data to describe how to infer the values. This allows our own developers as well our data scientists to write code against easily and build smarter models.
Here are a few more examples of where FHIR helps us go a long way to structure and build smartness in the app:
Vaccinomes refer to the immunizations. We are able to pull your immunization information from your medical records.
We represent a single immunization in FHIR standard as below:
Pharmacomes refer to the medications and pharmacy prescriptions. We can import these today from all popular pharmacies (CVS/Walgreens/Rite Aid) and your medical records. The interesting bit that we are solving once we import your medications is to accurately classify it and add associated metadata to it. One such metadata that we add is side effects of the drug. To do this accurately, our distributed services need a clearly defined schema and an ontology to query against.
We will be writing more about our ontology and our classification pipeline in a future post — so stay tuned.
What is missing?
Hopefully, we have whet your appetite on why FHIR can be a great way to standardize the data.
FHIR encompasses key medical concepts that can be found in medical records, but it does not include all types of OMICS data that we at Doc.ai are collecting. Example — we don’t have a standard representation of Exposomics data or even a more nuanced way to represent microbiomics data. We hope to contribute back to FHIR’s emerging standards on new types of OMICS data that we help users capture.
Most sources today don’t support FHIR which means converting data from another custom format to FHIR can be lossy. Converting from CCD to FHIR formats is not necessarily straightforward. However, we are hoping that an active developer ecosystem can be fostered around this, and we would love to do our part of it by open sourcing all our data transformers.
In the industry
Our opinion is that FHIR is going to be the defacto standard of future for data exchange with larger corporations such as Apple, Epic and Cerner who have embraced it. We see FHIR come up during most healthcare meetups and conferences for data exchange formats. We will be going all in FHIR for data representation and data exchange for model building. We have joined HL7 as an organizational member and are adopters and promoters of FHIR.
It time to kill your custom format and embrace FHIR.
If you are really interested in working on these problems, come join us, we ‘re expanding our awesome team!