FHIR (Fast Healthcare Interoperability Resources – pronounced “fire”) is a standard for manipulating, storing and sharing healthcare information electronically. It is a freely available specification created by the HL7 organization first published in 2012. It is now in its fifth major version.
FHIR can be a part of any healthcare-related tech implementation: custom Electronic Health Records applications, data integration solutions, internal and external-facing web and mobile applications – it even supports veterinary use!
At ACN, we strongly believe that FHIR is an important ingredient to the success of any Healthcare solution implementation. In this post, we will go through the major reasons why it’s such a strong foundation, some caveats, and the challenges associated with a FHIR implementation.
So… Why is FHIR awesome?
- It is a free-to-use international standard: in existence for more than 10 years now, FHIR boasts the common established knowledge of thousands of Healthcare professionals around the world—adopting it is like having access to many consultants working for free! And there are no restrictions or limitations associated with the specification.
- The documentation is exhaustive and very thorough; as with the rest of the specification, it is freely available on the web at https://hl7.org/fhir
- It covers a very large area in the Healthcare domain: from base resources (Patients, Practitioners…) to clinical (Conditions, Observations, Care Plans…), financial (Claims, Invoices, Insurance Plans…) and research-focused (Citation, Evidence, Clinical Measures…) resources, version 5 proposes 157 resources to choose from!
- FHIR makes data sharing easier: the “I” in FHIR means “Interoperability”, and the specification has been specifically designed to enhance and facilitate data exchange;
- It is becoming a legal obligation: as the pressure for healthcare efficiency and patients’ ability to access to their data mounts, an increasing number of governments and organizations around the world mandate FHIR as the data standard of choice for exchanging information – one such example is the US ONC final rule on interoperability that requires FHIR R4 support for health plans on federal exchanges; as time passes, more and more official bodies are honing in on FHIR as a requirement.
- It is customizable to specific needs: there is a impressive extensibility model, which means that implementations can add their own particulars if they are not already covered by the specification; it also supports many different terminology systems (e.g. SNOMED, LOINC, etc.).
- It does not impose a specific workflow: the implementer decides how the resources are orchestrated, which means agency and control over the way tasks are conducted – FHIR can accommodate the needs of very specialized organizations; this is a specific point where non-FHIR implementations often struggle, and a lot of healthcare professionals experience friction using those systems for their day-to-day activities.
- FHIR benefits from an entire ecosystem: as more and more products adopt FHIR, it becomes a lingua franca; interoperability and extensions become much easier and cheaper: think about connecting clinical decision-making systems, exchanging patient information, managing revenue, integrating lab results, it all becomes easier when all parties speak the same language. FHIR even integrates specialized domain-specific languages such as FHIRPath (to search and extract FHIR resources) and CQL (Clinical Quality Language, focused on clinical quality and measurement).
- It is robust: the data model is very mature and allows modeling different levels of complexity depending on needs; it also emphasizes human readability (by encouraging systematic text representation for human consumption) and allows partial degradation of the information (in the spirit that having less information is better than no information).
That’s great! Now, what are the challenges associated with FHIR implementations?
- It can be intimidating to get started: although the documentation is very detailed and thorough, it is hard to know where to start, and in which order, to learn about the FHIR spec.
- The data model is large: 64 Datatypes and 157 Resource Types; every successful FHIR implementation starts with an adequate mapping between the implementation’s needs and the FHIR data model, which requires both digging into the specification and a bit of experience to do well.
- Managing terminologies is hard: terminologies refer to any FHIR element that has a coded value (e.g. refers to a Code System: SNOMED, CPT, LOINC, ICD-10, etc.); although FHIR has great support for terminologies (see for example Terminology Service), it is hard to collect and manage the data for external code systems (that are not managed by the FHIR committee).
- Producing the first few features takes a long time: since the data model is large and has a lot of resources and data types, it can take a good chunk of time to have everything setup before producing the first feature / the first screen, assuming you want to build it in a way that is architecturally sound.
At ACN we are strong supporters of FHIR, and believe that the benefits far outweigh the added complexity – especially as products mature and gain additional features and use cases; we have found time and time again that the answers were already available in FHIR, right at our fingertips.
Whether choosing off-the-shelf products or building custom solutions (or, most likely, a mix of both), we recommend considering FHIR support as an important decision criteria.
We are currently working to contribute to the ecosystem to decrease its complexity and make it more approachable – stay tuned for future announcements. 🔥
