How it Works and How We’re Using It
Apr 6, 2020 | Alicia Hetrick | crosscom.com
FHIR (pronounced “fire”), or “Fast Healthcare Interoperability Resources,” is a standard for healthcare data exchange that is quickly gaining relevance in the healthcare industry. Through use of this clearly defined structure for sharing digital healthcare information, organizations such as hospitals and research institutions are able to collaborate more efficiently and effectively whenever the sharing of healthcare data is involved. Ultimately, improving the effectiveness of these stakeholders can lead to improved quality of research and better patient care. Here at CrossComm, we’re already using the FHIR standard and expect it to keep gaining use across the industry as it matures.
Who’s Using It?
Many small and large stakeholders are already using FHIR. Big names like Microsoft, Google, Amazon, IBM, Oracle and Salesforce are building FHIR servers and integrating with FHIR data, and there’s opportunity in the space for small teams to get on board and begin to provide and consume it for a large variety of applications.
We’re currently using it on a project in partnership with Karmanos Cancer Institute on the MyPatientPal app. In this mobile app, study participants anonymously record daily entries about their use of prescribed medications, symptom severities, and quantitative metrics (such as blood pressure readings), as shown in the above screenshot.
Patients can view charts and comparisons to track effectiveness of medications over time in the mobile app, and researchers access a web portal where they can export the data and adjust tracked symptoms, metrics, and medications as needed for their project.
Without a standard like FHIR, it would be difficult to share this information with other projects. But with the FHIR format, we can simply transform the data to follow the prescribed standard, and then multiple parties can consume the aspects that are relevant to their research, while still fully preserving patient confidentiality.
How it Works
The “R” in FHIR stands for “Resources,” which are the building blocks of FHIR data. Each resource has a standard format which all parties exchanging the data can expect consistency on. Architects can choose various data structures to transmit depending on the needs of their application: JSON, XML, UML, Turtle, or R3 Diff. Some example resources (with their definitions quoted straight from the standard) include:
- Episode of Care: “An association between a patient and an organization / healthcare provider(s) during which time encounters may occur.”
- Medication: “This resource is primarily used for the identification and definition of a medication for the purposes of prescribing, dispensing, and administering a medication as well as for making statements about medication use.”
- Procedure: “An action that is or was performed on or for a patient. This can be a physical intervention like an operation, or less invasive like long term services, counseling, or hypnotherapy.”
Let’s look a little closer at a Medication resource in a commonly used format – JSON (JavaScript Object Notation), as it’s outlined by the standard:
Each resource type has a few required fields and a number of optional fields which can be used when pertinent — these can be seen in pink. For example, if we were defining a medication that was being used in a study tracking its effectiveness, we might want to include all of the fields shown, because it would be important to have all of these details. However, if we were just tracking a patient’s use of medication in an app, then we might not know the particular batch they were taking, so we could leave that data out.
Each field in the FHIR standard has a defined data type (or enumerates a limited set of options) which specifies the format that consumers can expect — these can be seen above in green. So, under ingredient, the “isActive” field is noted as a boolean, meaning that its value will only ever be true or false. Other fields specify more complicated data types, such as Ratio or Identifier. All of these types are standardized as well.
One particularly important data type is the CodeableConcept. This allows for reference by code and/or name to an external industry standard – often LOINC, though any system can be supported. This means that any stakeholders who already integrate with an existing standard can more easily consume FHIR data. This is because there is a built-in way to reference items in FHIR by their categories and codes within prevalent existing industry standards. For example, if we wanted to share data for a patient’s resting heart rate, we could reference it by the LOINC code 40443-4 for “Heart rate –resting” and that would enable users searching by the specific LOINC code to more easily consume our data and understand its context.
Why it’s Useful
There are dozens of these resource options to choose from and more in the pipeline to be added. The intent is for FHIR to cover essentially every healthcare data type that can be shared among industry stakeholders, simplifying communication and automating data processing across complex systems. It even opens up opportunities that may have been very challenging in the past.
As an example, data could be collected in ways that preserve patient confidentiality by referencing external ID systems. The data could then be exposed to a wide range of medical studies to get access to whatever parts they need for their particular studies. This data would be provided in a consistent format that they can then accurately process and analyze.
As adoption increases, FHIR will become more and more relevant. It’s right in the name – the goal is to achieve the highest possible level of interoperability among stakeholders.
Where Did it Come From?
FHIR was released by HL7 (Health Level 7 International), a not-for-profit organization with industry stakeholders in government, healthcare, pharmaceutical companies, insurance organizations, and others who come together with a mission “to provide standards that empower global health data interoperability.” HL7 has been working for over 30 years towards this, and FHIR is the digital implementation of this mission. FHIR itself was released in draft format in 2012 and has been iterated on since then through feedback from early adopters.
Current Challenges
-
The current release of FHIR is version 4. While this version has the first release of some normative content (meaning that forward and backward compatibility is assured), there are still elements of it that could change in the future. However, it is only through adoption that any kinks can be worked out, and the evolution of FHIR has been extremely well documented so that parties can follow its progress and growth and adapt to it as needed.
-
FHIR is built to be very customizable to particular use cases – meaning that much of the data in the standard is optional. While this is helpful for applications where all of the resource fields are not tracked or may not be relevant, this adds a layer of complexity when the data contract is being laid out between parties, since data consumers may require some of the optional fields for their particular use case. This can be mitigated with upfront negotiation and awareness of the standard.
-
FHIR has been around for a little less than ten years. While this may seem like a lifetime in the tech industry, for large, bureaucracy-prone organizations such as government entities, it’s just a flash. While some organizations may be interested in implementing FHIR, it takes time and significant effort to migrate existing systems. New startups may want to use FHIR, but they need to be sure that other systems they want to integrate with are on board. However, there are some existing solutions that can assist with translating from older standards into FHIR if necessary.
Here at CrossComm, we’re interested in watching FHIR’s growth as it spreads further across the healthcare industry, and we’re happy to discuss implementation in both FHIR-producing & consuming applications. If you’d like to learn more about FHIR yourself, check out executive, technical, and clinical overviews directly from HL7.