In our previous "Health Care is on FHIR" post, we looked at the FHIR standard and how it improves on previous attempts to facilitate the seamless exchange of health data. In this post, we look at how FHIR is powering new interoperability solutions and how you can prepare to use the new standard.
FHIR starter
The FHIR standard supports a broad range of application development, data exchange, and documentation needs across different settings of care. FHIR is also modular, allowing parties exchanging data to adopt only the pieces of the standard that are relevant to their specific needs.
The five major components of FHIR are:
Resources, which define a grammar and vocabulary for health care data
Resources provide an expressive yet precise language for talking about Patients, Practitioners, Medications, Procedures, and all of the other basic building blocks of clinical and financial operations. For example, a Patient may optionally have a Marital Status, which must drawn from a standardized set of codes.
Profiles, which use Resources as building blocks to build templates that refine the standard for use in a specific region and for a targeted set of use cases
Profiles provide useful bounds that simplify integrations between health IT systems operating under the same basic assumptions and regulations. For example, FHIR's U.S. Lab Profiles require that lab orders and results include the National Provider Identifier (NPI) of the ordering institution. NPIs are both specific to the U.S. health care system, and a mandatory EHR certification requirement under meaningful use.
Documents, which are a collection of FHIR records that serve as a formal record.
FHIR documents can include any collection of resources, may conform to a profile, and can be securely signed by a patient, practitioner, or organization to verify their authenticity. Common documents include patient discharge summaries and continuity of care documents.
Messages, which are used to communicate an event from one system to another.
Notices of admission or delivery of lab results are common ways messages tie together distinct IT systems to help enable efficient workflows.
APIs (application programming interfaces), which define a set of "requests" that a FHIR-enabled system can support to accomplish useful work
APIs are often thought of as contracts: If a client can meet the requirements of the contract, the service provider will execute the request in a well-defined way. For example, FHIR provides a "create" request that can be used to create new Patients, Providers, Visits, Lab Results, and other types of FHIR Resources. The API contract mandates specific rules for how a FHIR-compliant technology must behave when servicing a "create" request.
Building on FHIR
While FHIR lays a strong foundation for interoperability, it's not a complete solution. Fortunately, FHIR was designed with extension in mind, and several interoperability and application development standards now use FHIR as the basis for their development frameworks.
The SMART Health IT initiative started in 2010 with the goal of building an EHR-agnostic data platform for application development. SMART predates FHIR, but it has embraced the standard as part of its foundation going forward. SMART improves on the FHIR standard in several ways. For instance, SMART includes a more detailed security model, added rigor in the definitions of many commonly used data elements, and extensions to improve support for genomic data and clinical decision support.
Most of the leading EHR and information management vendors have committed to supporting FHIR as part of their open API and application development platforms. Some have embraced SMART, while others are using FHIR's Resource model but service requests through their own proprietary APIs or data exchange processes. Regardless of each vendor's specific approach, FHIR's practical, foundational model for health care data should simplify third-party solution development and smooth the flow of patient data between disparate systems.
Ready, aim...
Many vendors are rolling out support for FHIR gradually as the standard matures towards "normative" status that provides for long-term stability. In March 2017, HL7 took another step in that direction by publishing FHIR 3.0 as a "standard for trial use," the final stage of maturity before the standard is declared "normative" and ready for long-term support.
There are steps health systems and partners can take today to prepare for the new standard. We recommend that you:
- Ask your EHR, interface, analytics, and other application vendors about their FHIR and SMART on FHIR support, both on their current products and committed plans for future releases. While some vendors are waiting for the "normative" version of the standard to be published, many vendors have released full production support based on the current pre-normative standard.
- Upgrade your EHR and integration technology platforms to versions that support FHIR. Interface engines, data repositories, and EHR products from a few years ago are unlikely to support FHIR.
- Educate key interface and application development staff on FHIR essentials. HL7 offers regular online and in person training, and FHIR's public web site publishes very approachable public documentation, complete with example data.
- Encourage your integration and technology teams to experiment with the technologies underlying FHIR, including JSON and RESTful APIs. Many vendors are already offering public test systems and sample data for those ready to experiment, and the FHIR documentation is readily accessible to staff with backgrounds in technology and health care concepts.
- Plan your first FHIR projects based on vendor and staff readiness. As with any new technology, the first implementation may require more time and vendor support than usual, but FHIR is expected to greatly reduce the time and expense of interoperability as it becomes mainstream.
FHIR offers significant benefits over prior data exchange standards, but it's unlikely to replace those standards completely in the near term. It rarely makes economic sense to replace an established channel for data exchange if that channel is meeting the needs of the health system. FHIR is likely to have the greatest near-term impact on new application deployments and new data exchanges projects with affiliates.
The Advisory Board Company is a founding member of the Argonaut Project, which is dedicated to the advancement of FHIR and related open standards. Learn more.