Introduction on FHIR and HL7

19 August 2022

Introduction to HL7 and FHIR Interoperable Standards

The standardization of data structure and transfer protocols are essential for interoperability between different healthcare systems. To this regard, the HL7 body created the HL7 v.2, the less successful implementation HL7 v.3 and the newest, most developer friendly version FHIR. HL7 is a set of standards for transferring clinical and administrative data between hospital information systems [1,2]. The standard specifies structures and mechanisms to describe and communicate administrative and clinical data [3].
The DICOM standard is mainly dedicated to medical imaging and it mostly used in the radiology department. HL7 is needed in order to transfer these DICOM images with other types of data such as data related to patient charts, files and other associated documents and audio recordings. HL7 FHIR, the latest version of the standard, defines both a file structure, and a method to transfer and store the data.

HL7 domains (v.2)

The oldest most widely implemented version of the HL7 standard was v.2. This version focused on the following fields/domains:

Patient management – admit, discharge, transfer patient (ADT);
Queries, resources (rooms, beds, devices, etc.), patient scheduling;
Scheduling of medical procedures, results, clinical trials;
Financial administration;
Medical documents;
Medical records;
Medical treatments;

The HL7 dictates the precise structure of the messages that need to be exchanged between different hospital information systems.
HL7 CDA is an XML-based standard that specifies the structure and semantics of clinical documents having in mind the exchange of such data. CDA documents are based on the XML standard (Extensible Markup Language). A CDA document is a completely defined object and can include text, images, sound recording and other multimedia components;

HL7 v.2 message break down

Fig.1 HL7 message

Each segment begins with its own 3 letters header that identify what the segment is about. Some common ones:

PID: patient information
NK1: next of kin
PV1: patient visit
SCH: scheduling activity information
OBR: observation results

Each segment is divided into fields. These are divided by the pipe character |. The caret ^ characters are field separators, they divide, for example, first name from family name. These are called components (ex first name is a component and last name is another component). Multiple carets characters hold the space for empty fields, where there could instead have been multiple entries, such as middle name. Each component can be divided into sub-components. These are delimited by the character &. This can be for example, in the name component, the sub-components prefix & first name. If a field is repeated, ex: 2 addresses, the symbol is tilde. The MSH9 component tells which system of the hospital the HL7 message is intended for.

Dicom/HL7 interaction

When a patient is registered for an exam, an HL7 order entry message (ORM) is sent to the RIS (radiology information system). The information of the HL7 will be then applied to the DICOM tags as metadata.
After the exam is carried out, the reports from the radiologist is sent from the voice dictation system to PACS via an HL7 observation result message (ORU). In this way the end viewers can read the text report while viewing the DICOM images.
In general, a FHIR imaging study is used to retrieve the imaging records, while DICOM is used to check the image itself.

HL7 FHIR (newest version)

The new version of HL7 is the Fast Healthcare Interoperability Resources which allows to exchange healthcare information between different hospital systems. From the snippets of the images included in this report, taken from the FHIR HL7 website, one can see what an amazing resource the new standard is, which allows to include a vast amount of patient information from different departments. FHIR allows for easy request, transfer and query (retrieval) of data between different healthcare systems.
FHIR is a RESTful API, so it defines how the systems request and send data. FHIR’s building blocks are called resources. Figure 2 shows what the different resources look like.

Fig.2 Resources list. Example taken from https://build.fhir.org/resourcelist.html

A resource is a data model that serves some specific purpose. An example of a resource can be seen from Figure 3. A patient’s resource will be a collection of attributes pertaining to the patient which is a standard to model patients. FHIR’s list of resources is very wide (covers many healthcare topics). Figure 3 shows the UI of FHIR’s patient resource.

Fig.3 Patient Resource example. https://www.hl7.org/fhir/patient.html

Figure 4 shows the FHIR data type called general purpose composite. Specifically, this is an example of a human name, a field which is reused for many purposes. The figure shows how FHIR structures this reusable field. Different data types are used to fill in the resources pages.

Fig.4 Data type example. https://www.hl7.org/fhir/datatypes.html#HumanName

A FHIR resource is structures as follows:

metadata. This field stores info such as resource ID and version number.
extensions.
narrative. This is the human readable part.
body. Raw structured data.

FHIR has 3 main encodings:

]- JSON

XML
RDF/turtle

90\% of developers use JSON. Figure 5 shows what a JSON blood pressure observation resource looks like.

Fig.5 Observation example. https://build.fhir.org/observation-example-bloodpressure.json.html

It can be seen that the metadata (ID, resource type, etc,) is stored at the top of the file. As it can be seen, the file is composed of key value pairs.
FHIR contains identifiers data types which are the:

System. It tells what kind of identifier this is.
Value. The actual identifier.

The JSON file also has a codes, which serve to transmit information about the tests taken.

URI. Used to identify many medical tests
code. just a number.
display. A sentence that a human can understand.

JSON files also have extensions. These are key-value pairs where there is an:

url.
data type.

Extensions can also have nested extensions.

Useful resources

FHIR standard \url{https://build.fhir.org/index.html}
Jason files types \url{https://www.w3schools.com/js/js_json_intro.asp}
xml files types \url{https://www.w3schools.com/xml/}

Accessing data

All data from EPIC should be stored as FHIR resources. Data can be accessed through FHIR requests.

Conclusion

This article has shown what the FHIR standard for query, storage and transfer of data between different hospital information systems is structured. It has also shown its relationship with the DICOM standard.

References

Blazona, Bojan and Miroslav Koncar (2007). ?HL7 and DICOM based integration of radiology departments with healthcare enterprise information systems? inInternational journal of medical informatics: 76, S425–S432.
Bogdan, Orza andothers (2010). Integrated medical system using DICOM and HL7 standards. Citeseer.
Oosterwijk, Herman (1998). ?DICOM versus HL7 for modality interfacing? inJournal of digital imaging: 11.1, pages 39–41.