FHIR is gaining momentum. The recent FHIR Dev Days conference in Redmond, WA, with a huge international presence, emphasized a common thread: health interoperability is at a historic inflection point. This generational shift to a new, more modern API, promises to make healthcare data more accessible not just for providers, but patients and consumers.
FHIR, as I’m sure you know, is a draft standard from Health Level 7 (HL7), designed for better healthcare interoperability. It stands to overtake much of the previous standard, HL7v2, as the choice for a true and fluid exchange of healthcare data, especially in ways that empower patients to have better access to their data.
For those unfamiliar with FHIR, the basic unit of information exchange is the resource. Resources and data types are presented in a concise XML-like format, but also have detailed descriptions of their contents. Examples of resources include the patient, organization, appointment, encounter, and observation.
The speed of FHIR adoption is nothing short of remarkable. Originally launched as the Argonaut project in 2014 to advance open interoperability standards, it has gained rapid acceptance. Now, the second draft standard for trial use, FHIR DTSUv2, has been adopted by 80% of hospitals and 70% of ambulatory clinics. The vice president of Microsoft’s Healthcare division sees FHIR as a “first-class” datatype, and believes FHIR data exchange will essentially be universal in the next 10 years.
There are two forces contributing to this growth. First, is its maturity. The first “normative” FHIR resources were announced with the FHIR R4 release in December 2018. Normative means that going forward, changes in the standard will not break the resource. Normative implies a degree of maturity users normally associate with production systems. There are approximately 25-30 resources that may go normative in the R5 release, tentatively scheduled in October 2020. This is a significant development.
The second force contributing to FHIR’s growth is the strong push by the U.S. Federal government, namely Title IV of the 21st Century Cures Act. The U.S. Congress has mandated consumer access to their electronic medical record data through APIs, which are transparent, with no or minimal fees, and are open and pro-competitive. A standard health data set will be available through FHIR, encompassing roughly 40 fields of information, including medications, labs, etc. The implementation timetable is uncertain, but will be no later than the end of 2020. The Office of the National Coordinator (ONC) developed a community tool for certification of FHIR servers, called INFERNO ( https://inferno.healthit.gov/), which fully supports FHIR R2, and now FHIR R4.
The open source community created several tools for working with FHIR resources that were demonstrated at the conference. One called “ Forge” is used in creating FHIR profiles. The FHIR specification only describes a set of base resources, frameworks, and APIs that can be used in different healthcare contexts. However, there is variability across the healthcare ecosystem around practices, requirements, regulations, education and actions, which are feasible and/or beneficial (see https://www.hl7.org/fhir/profiling.html).
Forge enables a user to employ a graphical editor to create:
- Rules about which resource elements are used, and what additional elements are added that are not part of the base specification;
- Rules about which API features are used, and how;
- Rules about which terminologies are used in particular elements; and
- Descriptions of how the resource elements and API features map to local requirements and/or implementations
Another demoed tool was FHIRPath, a path-based navigation and extraction language, similar to XPATH, currently in STU1 release. FHIRPath enables a developer to navigate, point to parts of a resource instance, or define their own search parameters. Developers can use FHIRPath to extract data from a profile/resource instance. FHIRPath is expected to become normative later this year.
Daniel Gottlieb, Principal, FHIR and Healthcare Data Standards at Central Square Solutions, spoke about the Bulk FHIR resource, which is under active development and promises to be an easier way to get bulk FHIR data. There are several use cases, including syncing a large number of third-party progress notes to an EMR, integrating a population health system with an EMR system, and utilizing machine learning. The queries would use an asynchronous request and implement public/private keys for security. It employs “ndjson,” or new line-delimited JSON to separate FHIR records. The trial FHIR implementation has been done as a proof of concept with both Cerner and Epic. It is also being refined at FHIR Connectathons. Currently, it is for export only, although an import implementation is planned.
Perhaps Ed Hammond, Ph,D, chair emeritus and founder of HL7, summed it up best in his closing of the event: FHIR is a specification based on new industry approaches, but informed by the requirements, successes and challenges of defining and implementing HL7 v2, v3 and the RIM, and CDA. FHIR is essential to making electronic health records available, discoverable, and exchangeable.
I agree, and I’m proud that InterSystems is bringing FHIR to the world.
