FHIR, The Big Bits
Posted on August 26, 2016
Fast Health Interoperability Resources or FHIR (pronounced “fire”) is a relative newcomer in Health IT, and the latest generation of HL7 standards. It is also somewhat unusual in that it is being made available free of charge, and is being developed through an open process in this post I explore a few of the main concepts underlying FHIR (the “big bits”), and why it is perhaps different from its predecessors.
Its current version, Draft Standard for Trial Use 2 (DSTU 2) isn’t even an official release. Yet, it enjoys tremendous popularity, and there are many early adopters, such as Regenstrief. Part of the reason for this is that expectations are high, and the time seems to be right for this technology. For example, though it doesn’t require the use of REST, it builds on the concepts of APIs and HTTP, and the RESTful API will probably be the most common way of using FHIR.
Not surprisingly, the core concept of FHIR is the resource. A resource is something having an identity, representing a core class in healthcare. Some examples of resources are: Patient, Practitioner, Medication, CarePlan, Specimen. Non-clinical examples include Person, Organization, Claim, Coverage, and SupplyDelivery. Abstractly, a resource consists of elements. For example, elements of the Patient resource include:
The elements of a resource have cardinalities and may be multiple-valued. For example, a patient may have many identifiers and many telephone numbers. Some resources will have values with fundamental types, but others will be references to other resources (for example, careProvider is a reference to a resource of type Practitioner). This structure is purely abstract in the sense that it isn’t tied to any particular serialization or representation of the resource. In fact, FHIR defines two (actually three, and more are possible) methods of encoding a resource. They are JSON, XML, and RDF. The encodings are fairly intuitive and common sense. For example, as you might expect, the JSON encoding makes use of a separate key for each element. If the element is multiple, the value will be a JSON array. Some values will be primitive types, but most fields will have values of a complex (structured) type. They are represented by JSON objects that include fields identifying coding systems, units, external vocabularies (SNOMED CT, LOINC, ICD-10, etc.). For the XML encoding, elements are represented, naturally enough by XML elements. Resource Description Format (RDF) is just now beginning to be used in FHIR, and it’s probably too early to speculate on how it will be used.
There are at least three ways FHIR resources can be used (all discussed in the standard):
- The FHIR API
The FHIR API is a RESTful API that provides a standard way to request resources and perform actions (such as making an appointment). Messaging is similar to the interaction model of HL7 v2 or v3. FHIR resources can also be used as standalone documents, similar to the Clinical Document Architecture (CDA). The difference, of course, is that CDA is based on HL7 v3 rather than FHIR resources.
As you might expect, there is also an extension mechanism defined in FHIR. The mechanism for defining conformance profiles and registering extensions is more formal than HL7 v2, but not as cumbersome as HL7 v3.