Historically, access to healthcare information (other than the results of investigations) has been largely restricted to the application within which it was collected. Because there are so many different applications that can collect clinical information, it can be difficult for clinicians caring for a patient to get the complete picture of the person’s current health — and any treatments that they were taking, especially medications. There are numerous examples of where actual patient harm — including death — has resulted from this lack of access to data.
There are a number of reasons we’re in this situation, one of which is a lack of a commonly agreed standard for sharing health care data.
Importance of Healthcare Standards
A standard is simply a commonly agreed way of doing something, and they are widely used in our society. Basic examples include the voltage in our electricity supply, the grades of petrol used in our vehicles, or the rules that apply to driving on our roads.
In the technology world, the adoption of standards has allowed cell phones from different vendors to talk to each other, banks to support eCommerce applications, and airlines to allow external applications to make reservations. While these activities are still possible without standards, it is considerably more difficult for a vendor to deal with a number of different, bespoke interfaces rather than a single, commonly used one.
HL7, DICOM and Other Healthcare Standards
Healthcare has always had standards, of course. HL7 has been producing interoperability standards since 1987 with the version 2 messaging standard and CDA (Clinical Document Architecture) for documents.
DICOM specifies how to store and share images, and terminology standards like SNOMED, LOINC, or RxNorm allow for the meaning of information being exchanged to be explicit (so called semantic interoperability).
There’s also IHE, which isn’t a Standards Development Organization, but rather takes existing standards and describes how to use them for specific use cases like Auditing access to data or sharing documents securely.
But in recent years there have been a number of changes.
- The volume and variety of information has expanded enormously, driven largely by devices of many sorts (including personal ones) and the availability of genomic data
- Population health analytics and quality metrics requires vast amounts of data from many different sources to function effectively
- The complexity of healthcare continues to expand, making easy access to decision support services an increasing requirement
- There has been an increased demand for real-time access to data. As the use of mobile devices has exploded, so has the need for information to be available immediately upon request
- And most importantly, there has been a big demand from the consumers of healthcare for their data to be freely available — both to their providers and to themselves — regardless of where it was captured. And a side-effect of this access has shown that the quality of data collection is often not optimal.
How FHIR Started
These trends were recognized by HL7 in 2011, which commissioned the “Fresh Start” project to consider how best to meet these needs. Coordinated by Grahame Grieve, this resulted in the FHIR standard, now in its fourth release.
FHIR (Fast Healthcare Interoperability Resources) was initially envisaged purely as an interoperability standard, but as its use has grown and the community has grown, it has expanded into other parts of healthcare. It’s possible to think of FHIR in three ways:
- The core specification
- Adapting it for specific uses (Profiling)
- Other standards and uses that build on FHIR as a core capability.
The core specification defines the basic components of FHIR and is freely available at http://hl7.org/fhir. (This easy availability of FHIR — and the fact that it is free to use — has certainly helped with adoption). It consists of:
- A set of information models called resources to represent the information to be shared. Examples include the patient, an allergy, or a medication.
- Standardized ways to connect these resources to terminologies like SNOMED, LOINC or ICD. Any terminology can be supported.
- Next, a way to join resources together in networks to represent more complex clinical interactions — such as a consultation with a provider, or the details of a procedure. This joining together of resources (called references) also allows for the safe extraction of data for the secondary purposes of analytics, quality measures, and decision support
- A standardized way to actually exchange the resources — including a real-time API (Applications Programming Interface) that is web based and widely used outside of the healthcare industry. This makes it much easier for developers to build healthcare applications.
- Guidance on how to use FHIR: checklists for implementers, security considerations, tooling available and so forth. It’s worth mentioning that while it is not a security standard, it integrates well with existing standards such as OAuth2 and OpenID Connect amongst others.
- A community of users that helps new entrants understand and implement FHIR by offering free support in near real time. (It’s not uncommon to get answers to questions within minutes of asking via a free online chat application. This community also makes it easier to get feedback from those users to further enhance the specification.
Recognizing that different communities and countries have different requirements for similar data, FHIR also defines ways that the core resources can be adapted for specific purposes. For example, the U.S. has one set of information needed to represent a patient, while the U.K. has another.
This ability to adapt FHIR is called profiling, and FHIR also defines standardized ways to describe and publish these adaptations called Implementation Guides. The Implementation Guides also describe how to use FHIR for a given scenario and can contain all the required documentation and artifacts — again making it easier for implementers to understand how to develop for these different requirements.
As the use of FHIR has increased, other aspects of implementing a healthcare solution also became (or are becoming) standardized. Examples of these include:
(Substitutable Medical Applications, Reusable Technologies) began as a way to securely launch “mini applications” in the context of an EHR (Electronic Health Record application). It predated FHIR, but adopted it as FHIR became available, and is now part of the standard.
(Clinical Decision Support hooks) describes a way that decision support can be automatically invoked in the context of an EHR. Working behind the scenes, it offers suggestions to the clinicians as part of their normal workflow. An example could be indicating that a particular medication has a significant co-payment and that there are alternatives to consider. The Da Vinci project is using this to integrate this advice with the payer coverage for a consumer.
This specification describes how to extract large quantities of data at a time, generally across patients rather than for a single person. This is particularly important for quality measures and population analytics.
This describes how different applications can keep a single context, for example ensuring that a radiology imaging system and the reporting system are using the same person. Another example is in the use of multidisciplinary meetings for patients with complex conditions.
These support the ability for someone (i.e., the patient or clinician) to be notified that there is new information available to them.
This is a language that describes how to convert to and from FHIR and other standards (or even within different versions of FHIR).
A large number of vendors (especially those new to the sector) are actually using FHIR as the storage medium. There are pros and cons to this approach, especially as the standard is actively evolving, but the ready availability of database servers that natively understand FHIR makes this a cost-effective approach to get started with healthcare applications.
Clinicians and Health IT Implementers a Have Say in FHIR
A key decision made right back in the beginning was that the development of the FHIR standard was to involve the implementer and clinical community as it was being designed. This means that a resource needed to be tested by implementers before its structure was fixed and the amount of testing done recorded.
The way that this is done is that each resource (and the other parts of the spec) is assigned a maturity level (based on the CMM model) that reflects the degree to which it has been tested. The higher the maturity level the more it has been tested and the less likely it is to change between versions.
The latest FHIR release (Release 4) is the first where some of the resources have a normative status, meaning that any subsequent change will not break implementations. While FHIR adopters need a strategy to deal with these changes, they can have confidence that resources have been thoroughly tested in the field before their structure is finalized.
A side effect of this approach is that there is no need to wait for the whole spec to be normative before implementing; indeed there are currently hundreds (if not thousands) of production grade deployments of FHIR enabled solutions globally.
Benefits of FHIR
Some of the value propositions for FHIR include:
- It’s straightforward to implement. As implementability was one of the original goals for FHIR, and it uses existing standards already familiar to developers, the learning curve is much lower than for other standards that have bespoke representations and require significant domain knowledge to implement. This makes it faster and cheaper to implement.
- It enhances the ability to access data from different sources in a consistent way. This is especially important as it is inevitable that data will be held in different systems and with different access requirements, so being able to easily retrieve data from multiple sources is critical.
- It is possible to build single purpose applications that can work against many different data sources and EHRs. This is particularly seen in the SMART community — and there are even conferences focussed on demonstrating these applications.
- Vendor lock-in to specific applications can be avoided if access to the data and services they provide is straightforward. This is of particular relevance to institutions, and the provision of FHIR interfaces is becoming part of many procurement processes.
- Aggregating data from different sources for research, analytics, and creation of decision support services becomes much more practical. And CDS hooks offer a way to deliver the outcomes of those services in a user-friendly way.
- Using the mapping language will enable the sharing of data conversion definitions between different sets of users. This will greatly simplify the incorporation of existing data sources into the FHIR ecosystem (and reduce the cost of doing so). The FHIR community already provides maps for inter-version FHIR conversion, and is currently developing maps for conversion between HL7 Version 2 and FHIR
- The creation of “mash ups,” combining data and functionality from different sources/services into purpose specific applications becomes feasible.
Since its development, FHIR has become the global standard for sharing healthcare data among all participants in the sector, including the patient. It is the belief of the FHIR community that this will result in improved health for consumers and us what drives us to move the specification forward.
David Hay is a consultant specializing in HL7 FHIR and author of the blog Hay on FHIR. David graduated from medical school in 1981, but after a few years of clinical practice moved into the health IT sector, where he has remained since. He is active in the international standards community, traveling widely to give talks about FHIR and related topics.