FHIR®, or Fast Healthcare Interoperability Resources, is a healthcare interoperability standard from HL7 that allows a multitude of systems to exchange healthcare information using agreed upon data models. In FHIR, these data models are simple, straightforward, simultaneously human and computer readable, and, when combined, robust enough to convey complex healthcare information.
The following is a brief introduction to key concepts in FHIR; these concepts are described in detail in the official FHIR Specification.
FHIR is built on the concept of resources, which are discrete units of data represented as JSON or XML. For example, all data about a single patient can be encapsulated as a Patient resource, while information about a single doctor's visit can be captured in an Encounter resource. This Encounter resource would usually contain a reference to the Patient resource of the patient who visited the doctor, avoiding the need to include the patient's data in the Encounter resource itself. Because resources can be stored and retrieved individually using RESTful APIs, FHIR requires less bandwidth and computing resources than other interoperability standards. The ability to express a resource as JSON makes exchanging FHIR data even more lightweight.
The base FHIR specification contains a page for every supported resource. For example, the Patient resource in the latest FHIR version is found at hl7.org/fhir/patient.html. Core information about a resource, for example what data fields belong in the resource and the data types of those fields, can be found in the Resource Content section of the specification page, which includes a Structure tab that explains each resource field. When starting out with FHIR resources, it is useful to compare a specific example of a resource with this structure (sample resources are available on the Examples tab of each resource page in the specification). A portion of the structure for the Patient resource looks like:
For a description of the symbols and icons used on a resource’s Structure tab, see Resource Formats.
FHIR also uses resources to define elements of the standard itself. This metadata, known as conformance resources, defines things like the valid fields of a resource, the search parameters that can be used to retrieve a resource from a FHIR server, and the codes used within a particular healthcare environment.
For a list of resources currently found in the base FHIR specification, see the Resource Index.
FHIR is intended to be adapted for specific healthcare environments and implementations, and provides straightforward strategies for extending and constraining the FHIR standard for these purposes. It often said that FHIR follows a 80/20 rule; the base FHIR specification contains 80% of what your healthcare environment needs, while custom constraints and extensions provide the remaining 20%. Often, a FHIR server conforms to a standard, published Implementation Guide that represents a complete implementation of FHIR for a specific ecosystem. For example, the US Core Implementation Guide sets the standard for using FHIR in healthcare environments in the United States. Of course, a healthcare environment can extend the base FHIR specification, US Core, or another Implementation Guide to meet its own unique needs.
At the heart of a FHIR adaptation are FHIR profiles, which extend or constrain a specific resource. For example, the US Core Implementation Guide contains a unique profile for the Patient resource, another profile for the Observation resource, and so on. At a technical level, each profile is defined by a StructureDefinition conformance resource. According to the FHIR specification, the term "profiling" should be reserved for the act of using these StructureDefinitions to configure resources for a particular implementation.
An adaptation of FHIR can contain more than resource profiles. For example, an Implementation Guide can contain codes and search parameters that are unique to a healthcare environment. Similar to profiles, these assets are defined with conformance resources like ValueSet and SearchParameter.
A coherent collection of profiles and other conformance resources is known as a FHIR package. The contents of a package can vary widely; it can contain an entire Implementation Guide or a single custom profile. In InterSystems products, you configure a FHIR server to support a particular healthcare ecosystem by adding a package to a FHIR endpoint.
Though FHIR can be used in messaging and document-based frameworks like traditional healthcare interoperability standards, its innovation is the ability to use RESTful API calls to work with healthcare data. Using HTTP verbs like GET and POST, a FHIR client can store, delete, update, and retrieve FHIR resources as needed. These actions that a FHIR client can take on resources are known as interactions. For more information about RESTful APIs and supported interactions, see RESTful API in the FHIR specification.
FHIR also allows FHIR clients to use operations to perform functions on the FHIR server. Because they invoke functions on the server, these operations are more like RPC calls than RESTful ones. For example, the standard $validate operation invokes a function on the server that checks whether a resource conforms to a profile. A healthcare environment can implement custom operations to perform a variety of actions at the request of a FHIR client.
Searching for FHIR Resources
Search is a very powerful FHIR interaction. Because the healthcare data is stored as individual resources, FHIR clients can use complex queries to retrieve only the data they need without having to parse through unrelated data. These queries are performed with a GET HTTP verb and can leverage search parameters to narrow the results to those resources that meet certain criteria. In its simplest form, a search can retrieve all resources of a certain type without specifying a search parameter. For example, the following RESTful API call would retrieve all Patient resources:
You can add search parameters to the API call using the ? character. For example, a search could use the name search parameter to find Patient resources that have a specified value in their name field. The API call to retrieve these Patient resources might be:
Multiple search parameters can be chained together using the & character. For example, the following API call can further limit the results by adding the gender of the patient:
The FHIR specification contains many other standard search parameters that can be used to perform powerful and complex queries. For details, see Search in the FHIR specification. You can find the search parameters for a specific resource on the resource’s page in the specification.
InterSystems FHIR Components
InterSystems products include the following technologies:
A FHIR server is an application that receives and processes FHIR requests while leveraging an architecture that is capable of storing and retrieving FHIR resources from an internal repository. In InterSystems products, the out-of-box solution for a FHIR server uses the Resource Repository as its storage. Depending on your product’s license, you might not be able to install a FHIR server with the Resource Repository. In this case, you should use the FHIR Interoperability Adapter to receive and process FHIR requests. When using the FHIR server, requests can be routed through an interoperability production before reaching the server’s internal architecture, but it is not required; FHIR servers that do not use an interoperability production can be significantly faster.
When your application must receive and process FHIR requests, but does not need to store or retrieve resources from internal storage, your best option is to use the FHIR Interoperability Adapter rather than a FHIR server. The FHIR Interoperability Adapter installs the components needed to handle a FHIR request without installing the internal architecture of a FHIR server. The FHIR Interoperability Adapter always use an interoperability production to process requests.
InterSystems products can be used to transform healthcare data captured in a non-FHIR standard such as HL7v2 into FHIR using a set of pre-defined transformations that can be invoked from an interoperability production or directly from an ObjectScript application. Transformations that take FHIR as the input and translate it into another interoperability standard are also provided. At the core of these transformations is the ability to convert FHIR to and from SDA, which is the InterSystems clinical data format.
Within InterSystems technology, a FHIR client is an interoperability business host or ObjectScript application that makes requests to a FHIR endpoint, whether it is the endpoint of an external FHIR server or the FHIR server architecture within the same InterSystems product. The FHIR client classes provide straightforward methods for performing FHIR interactions and operations on a FHIR server.
FHIRPath is a language that allows you to navigate a FHIR resource to evaluate and extract data from its fields using a straightforward syntax. InterSystems products provide a subset of the FHIRPath functions and operations that you can use to evaluate a resource.