Three Challenges FHIR 4 Faces
In January 2019, HL7 published the fourth release of their An HL7 standard that is short for Fast Healthcare Interoperability Resources and pronounced “Fire”. The standard defines a set of “Resources” that represent granular clinical concepts. The resources provide flexibility for a range of healthca... (Fast Healthcare Interoperability refers to the ability of two or more systems or components to exchange information and to use the information that has been exchanged. Resources) standard. While this release was notable due to the standard passing the normative ballot — meaning future changes will be backward compatible — FHIR 4 still faces challenges when it comes to solving interoperability issues in healthcare IT.
Three of the obstacles that the FHIR 4 standard faces are:
- Integrating with legacy approaches
Security of both access control and data-in-transit is always paramount — regardless of the data standard used to exchange information.
While FHIR is not a proper security standard, it does provide:
- Security guidance for implementers, and
- Internal security structure (such as audit resources)
Addressing the overreaching goal of security in conjunction with the workflow and business requirements is a must. For example, FHIR recommends OAuth for authentication, but the specific details around the implementation of OAuth must be addressed by the implementers or via a realm-specific agreement.
The SMART App Launch was also recently released, and it provides reliable, secure authorization for a variety of app architectures wanting to connect to Electronic Health Record (EHR), as defined in Defining Key Health Information Technology Terms (The National Alliance for Health Information Technology, April 28, 2008): An electronic record of health-related information on an individual that conform... data via a FHIR system.
FHIR will mostly enable lower-friction data exchanges, which will then lead to more security discussions and concerns.
Because we are early in the implementation cycle and there are deep, pent-up demands to solve a wide range of interoperability concerns urgently, over-hyped expectations for FHIR are pervasive.
FHIR’s ability to query source-of-truth systems in real time and its improved data model reducing friction for data exchange makes sugarplums dance in the minds of most stakeholders.
The reality will be much more difficult. Even allowing that FHIR is a dramatically and transformationally better approach to interoperability, no single standard will meet the panacea about which everyone dreams.
Legacy Interoperability Approaches
Established interoperability infrastructure is not going away — or anytime soon at least.
From integration engines to data lakes with Clinical Document Architecture (CDA) HL7 CDA uses XML for encoding of the documents and breaks down the document in generic, unnamed, and non-templated sections. Documents can include discharge summaries, progress notes, history and physical reports,... documents, the existing approaches to data exchange will continue for decades. FHIR will not replace V2 nor CDA. Rather, it will augment the existing solutions.
The key to having FHIR improve interoperability will be effectively integrating the transaction-oriented standards (V2, CDA, X12 provides for electronic exchange of business transactions-electronic data interchange (EDI). The American National Standards Institute (ANSI) chartered the Accredited Standards Committee (ASC) X12 to develop uniform standards., SCRIPT, etc.) with the interaction-orientated FHIR standard.
Despite these challenges, the future is bright.