FHIR: Three Steps to Your Own Profile
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.
1. What you should know about FHIR…
a) … as a manager
… at a manufacturer
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:
- Section 7 of the German Interoperabilitätsverordnung requires healthcare facilities to use systems that meet interoperability requirements
- The time and cost of integrating your device into systems at healthcare facilities is increased disproportionately
Further information
Read more on the Interoperabilitätsverordnung and its effects on manufacturers here.
… at a hospital
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.
b) … as a software developer
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.
c) … as a quality and regulatory affairs manager
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.
Further information
Read more on “substantial design changes” and the resulting consequences here.
2. Where FHIR applies
a) The exchange of messages and documents in healthcare
FHIR is used to exchange information between systems (medical devices, apps, IT systems) in healthcare. FHIR supports the exchange of both messages and documents.
- Messages are generally short, are not saved and do not provide the full context. An example would be a message from a laboratory information system to a clinical workstation that a new laboratory value is available.
- Documents provide a broader context, e.g., the institution that created it, the patient it relates to as well as data from various “pots” such as diagnoses, laboratory values and medication plans. Examples of documents include case and discharge summaries.
This information can relate to:
- Patients, including master data and medical histories
- Findings relating to these patients (e.g., laboratory values, vital signs) and diagnoses
- Their treatments, e.g., medications and operations
- The workflow for these findings and treatments (e.g., service requests, appointments and referrals)
- The billing of all these services
b) Information exchange within organizations
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:
- Clinical information systems, e.g.:
- HIS (hospital information systems)
- CWS (clinical workstation systems)
- RIS (radiology information systems)
- LIMS (laboratory information management systems)
- PDMS (patient data management systems)
- PMS (practice management systems)
- DIS (doctor information systems)
- Medical devices, e.g.:
- Some of the above clinical information systems
- Systems for radiological imaging
- Administrative systems, e.g.:
- Systems for service recording and billing
- Systems for statistics and (medical) controlling
- Other systems
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.
c) Information exchange between organizations and with patients
FHIR is intended to and will encourage cross-sector information exchange, while also involving patients as the party directly affected.
- Hospitals have to communicate better with doctor's practices and medical care centers.
- Prescriptions should be sent digitally to pharmacies by doctors and also accessed digitally by patients.
- Patients access their electronic health record through apps and complement this data with data on their vital signs from, e.g., smartwatches.
- All the parties involved should have access to the telematics infrastructure and its services.
- Researchers want to collect care data from different institutions.
- The parties paying for the services (insurance companies) and service providers (e.g., hospitals, practices, physiotherapists) exchange the necessary data.
3) What FHIR standardizes
As an interoperability standard. FHIR standardizes across multiple interoperability levels:
- Organizational interoperability (e.g., workflows and user permissions)
- Semantic interoperability (e.g., code systems and taxonomies such as ICD-10)
- Syntactic interoperability (e.g., formats like XML and JSON)
- Structural interoperability (e.g., transfer protocols)
a) Resources (semantic level)
Firstly, FHIR standardizes resources. Examples of resources include:
- Patients
- Drug prescriptions
- Observations, e.g., laboratory values and vital signs (e.g., blood pressure)
- Organizations (e.g., doctors’ offices)
- Appointments
For each resource, FHIR specifies which attributes (FHIR uses the term “elements”) it can or must have. For example, a patient has:
- No, one, or more names
- No, one, or more telephone numbers
- No or exactly one gender
- No or exactly one date of birth
- No, one, or more contacts, where each contact has the type of relationship, an optional name or more than one name, and contact information.
b) Data elements, data types (semantic level)
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.
c) Access to resources (structural and syntactic level)
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:
- Display history (GET https://meinepraxis.de/pfad/patient/172/_history)
- Edit resource through operation: GET https://meinepraxis.de/pfad/patient/172$merge
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.
d) Other
Extensions
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).
Human readable summaries
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.
4) What are FHIR protocols?
a) Concept
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). |
b) Examples of profiles in Germany
HL7 has developed a range of FHIR profiles, including the profiles in the “Basisprofil DE”. These include:
- German addresses
- The “ChargeItem für EBM-Ziffer als Abrechnungsposition” mentioned above.
- The code profile for OPS (the operations and procedure codes)
- The coverages for the German “GKV-Profil”
- The identifier profile for the “Telematik-ID”
c) Self-created profiles
Caution
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”.
Step 1: clone the “datatype” “coding” using Forge
The “datatype” “coding” can be cloned using Forge (see Fig. 5a)
and named “CodingATC” (see Fig. 5b).
Step 2: define the code system
Now we have to adjust the coding defaults. This concerns the following attributes in particular:
- “system”: The attribute becomes a mandatory attribute, and the URL of the code system is defined as http://fhir.de/CodeSystem/bfarm/atc (see Fig. 5c)
- “version”: This attribute also becomes a mandatory attribute. The short and long descriptions are also changed.
“code”: This attribute also becomes a mandatory attribute
The result is a StructureDefinition in XML format that is the same as the “official example,” the “Coding-Profil für ATC,” except for administrative information (see Fig. 5d).
Step 3: publish the profile
The profile can now be uploaded to Simplifier.net and published (see Fig. 5e).
5) Conclusion
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:
- The protocol is consistent and does not appear to be as haphazard as HL7 V2.
- At the same time, it is not as “over-academicized” and incomprehensible as HL7 V3.
- It takes developers into account and uses their architectural styles (REST), standards (http, XML, JSON) and development tools.
- There is FHIR-specific tool support, e.g., with Forge and the platform Simplifier.net.
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.
Author:
Prof. Dr. Christian Johner
Back To Top
Privacy settings
We use cookies on our website. Some of them are essential, while others help us improve this website and your experience.