FHIR has become the standard for the exchange of data in healthcare. FHIR stands for Fast Healthcare Interoperability Resources and is pronounced “fire.”
This standard, published by HL7, is intended to cover all “use cases.” From querying insurance master data to intersectoral data exchange all the way through to integrating measuring devices.
For modern clinical information systems, a lot of medical devices and even health apps, there's no avoiding FHIR.
FHIR standardizes communication in healthcare, e.g., between medical devices and IT systems such as apps and hospital information systems.
If your devices do not support FHIR, the risk that your customers will stop purchasing your devices is increasing because:
Read more on the Interoperabilitätsverordnung and its effects on manufacturers here.
FHIR standardizes communication in healthcare, e.g., between medical devices and IT systems within your organization and also with third parties, such as other healthcare service providers (e.g., doctors’ offices), authorities and health insurers.
You should make sure that, where possible and appropriate, you only purchase IT systems and medical devices that support the interoperability standards recommended by the German Federal Ministry of Health's expert panel. FHIR and the profiles based on it are among these standards.
The German Interoperabilitätsverordnung (the official name is the “IOP Governance-Verordnung (GIGV))” makes them mandatory.
Furthermore, without end-to-end system interoperability, it is almost impossible to make your processes efficient and productive.
At long last, FHIR is an interoperability standard for healthcare that allows to you to use your knowledge from your studies and other sectors because FHIR is based on standards such as REST and, therefore, on http(s), XML, JSON, OAUTH and the resource-oriented architecture paradigm.
In other words, you can continue to use your standard tools (IDEs, test frameworks, etc.) but you do have to familiarize yourself with the specifics, such as the semantic standards and FHIR profiles.
Read on below and use the resources linked there.
FHIR is an interoperability standard that allows medical devices to communicate with neighboring systems. Therefore, FHIR is used to specify a medical device's external interfaces.
This specification must be part of the product or software requirements specification (PRS/SRS). Similarly, the product or software system testing must verify that these product or software requirements are met.
The interface specification does not necessarily have to be included in the PRS or SRS. References are enough. But simply requiring interfaces to support FHIR is not enough. Rather, the PRS/SRS must fully specify the interface, e.g., by defining the profiles used or the semantic interoperability standards used for them.
Switching from a non-FHIR-based to an FHIR-based interface is a substantial change.
Read more on “substantial design changes” and the resulting consequences here.
FHIR is used to exchange information between systems (medical devices, apps, IT systems) in healthcare. FHIR supports the exchange of both messages and documents.
This information can relate to:
HL7 Version 2 is still the main version used in clinics. But HL7 FHIR aims to replace/complement the message-oriented version 2.
Endpoints of this communication are or will be:
Communication within an organization is not limited to communication within an organization's physical walls. FHIR also standardizes the exchange of information between different locations within an organization and with doctors working remotely.
FHIR is intended to and will encourage cross-sector information exchange, while also involving patients as the party directly affected.
As an interoperability standard. FHIR standardizes across multiple interoperability levels:
Firstly, FHIR standardizes resources. Examples of resources include:
For each resource, FHIR specifies which attributes (FHIR uses the term “elements”) it can or must have. For example, a patient has:
In addition, in places the FHIR specifies the possible values for resource attributes. For example, the gender may only take one of the following values: male, female or unknown
To define these coded values, FHIR uses its own code systems (e.g., the AdministrativeGender mentioned here) or there is the option to incorporate a code system such as ICD-10.
FHIR profiles (more on them below) restrict some options, e.g., when choosing the code system, or specify particular code systems.
FHIR is based on REST architectures. These are software architectures for distributed systems that generally allow http(s)-based access to resources.
The http methods determine what should be done with the resource. This results in the following form of application programming interfaces (API):
Objective: Resource … | http method | Example |
Create | POST | |
Display | GET | |
Search | GET | |
Modify | PUT | |
Delete | DELETE |
FHIR defines actions beyond this:
The resources and their content are exchanged between client and server in XML or JSON format.
For the resource “patient” (see Fig. 3), this might look like this:
Figure 4 also shows how FHIR specifies data types, using general data types such as “boolean” or “date” as well as specific data types such as HumanName, Address and CodableConcept.
The JSON file shown in Figure 4 would, for example, be the information returned by the server in response to a GET request https://meinepraxis.de/pfad/patient/1234567. Or it would be the payload contained in the http body of a POST request. However, the identifier, which would only be assigned by the server, would still be missing in this case.
Since FHIR is based on http, access permissions can be restricted at the http level rather than just the application level.
OAuth 2.0 is generally used as the protocol for securing the REST API.
Extensions allow attributes to be added. This is necessary, for example, so that country-specific values can be recorded. In the Netherlands, for example, patients must have a “preferredPharmacy” attribute. This is implemented using an extension.
Extensions are used as part of profiles (see section 4).
Optionally, resources can also be described in a human-readable format using texts. A limited set of HTML tags is available for this purpose and can be used to design paragraphs, lists and tables.
The FHIR specification was created by HL7, which is a global organization. Therefore, the specification is not specific to any one country. The specification is also neither sufficiently specific for a lot of use cases nor sufficiently concrete for implementation.
For example, there is no care level, as it is called in Germany, on the global level.
The profiles use different approaches to achieve a precise interface specification based on FHIR. The following table shows several approaches as examples.
Approach | Explanation | Example |
Cardinality constraint | The FHIR standard often allows attributes to be omitted or used multiple times. A profile, on the other hand, can specify this cardinality precisely and, therefore, set mandatory fields. | While the resource ChargeItem allows 0 or 1 as the “quantity” number (i.e., makes the attribute optional), in the German base profile, this attribute (ChargeItemEBM) is a mandatory field (i.e., has the cardinality 1) |
Expansion using extensions | The FHIR standard permits extensions (see 2.d)) | The “Coding-Profil für ICD-10-GM” adds an attribute “diagnosesicherheit” to the resource “Observation.” |
Specifying values | A profile can specify concrete code systems. We also talk about ValueSetBindings. | The “Coding-Profil für ICD-10-GM” specifies the ICD-10 catalog with the URN http://fhir.de/CodeSystem/bfarm/icd-10-gm for the coding of diagnoses. The identifier of fund doctors’ practices must come from the http://fhir.de/sid/kbv/vknr system, which includes the National Insurance Payor Identifier (NIIP). |
HL7 has developed a range of FHIR profiles, including the profiles in the “Basisprofil DE”. These include:
In order to avoid an uncontrolled increase in the number of profiles, you should check whether creating your own profiles is really necessary.
The tool “Forge” helps you to create your own profiles. It is also useful for practicing creating profiles by recreating other profiles. The following example illustrates this using the “Coding-Profil für ATC”.
The “datatype” “coding” can be cloned using Forge (see Fig. 5a)
Now we have to adjust the coding defaults. This concerns the following attributes in particular:
“code”: This attribute also becomes a mandatory attribute
At long last, a practical interoperability standard that is also used!
FHIR is adding momentum to the standardization of information exchange in healthcare. Manufacturers, gematik, the associations, insurance companies and hospitals have agreed to FHIR. The numerous profiles and use cases confirm this. This also includes the “ISiK Basismodul” specification (ISiK = IT systems in hospitals).
There are several reasons why FHIR is having this success:
At the same time, however, FHIR is a victim of its own success. A huge number of profiles have been created, making it difficult to keep track of them all. So, it is understandable that the German Federal Ministry of Health is trying to restore some order to the standards chaos with the German Interoperabilitätsverordnung.
The dynamic development is also reflected in the fact that HL7 Deutschland has made big changes to the profiles. As a result, the German base profile no longer contains a central patient profile. The documentation has not yet been followed everywhere, countless links lead nowhere. This makes it difficult for beginners to learn the ropes.
But that is not a criticism. On the contrary: a big thank you goes out to those involved. With FHIR and the healthcare profiles, they have set out a path for healthcare to catch up with the 21st century, in terms of interoperability at least.