With this chapter, you will be referencing a number of Swagger files to assist you with the learning experience. You will find these files in GitHub using the following URL: https://github.com/PacktPublishing/Digital-Transformation-and-Modernization-with-IBM-API-Connect.

You should copy the files for this chapter to your development environment. We will be utilizing the LTE and API Manager to perform the development tasks. If you prefer to use some of the skills you learned from Chapter 2, Introducing API Connect, you can use the CLI commands to push the sample files up to API Connect. The assumption going forward is you will begin utilizing the API Manager to draft new APIs.

Now that you understand what you will be attempting, let’s begin with understanding the business use case for FHIR.

Introducing FHIR

Interoperability between healthcare organizations has been like the search for the holy grail. The HL7 organization has been around since 1987 and has tackled the task of establishing standards for sharing healthcare information. There have been many levels of maturity of the standard over the years, with the most prominent being HL7v2.

Version 2 is an exchange of data that is delimited with pipes. Unfortunately, at the time, this method was too lenient, and some fields were left up to the provider to declare. These fields then created issues for consumers because they didn’t have the consistency needed to receive the same type of file from different sources. Fields were of different types and values. Version 3 was introduced by HL7 to improve the data exchange quality by using XML and XML schemas. The adoption of version 3 was not as successful as they had hoped. XML schemas were difficult to digest and made implementations complicated. The goal was still to develop an improved version, but there needed to be something more digital that took advantage of Web 2.0, APIs, and JSON. That is how Fast Healthcare Interoperability Resources (FHIR) got started. The current version is FHIR v4.0.1. Although you can implement FHIR in various ways, the predominant way is by creating an FHIR server and accessing the FHIR resource data with APIs. Remember that the goal is to exchange data. Let’s explore how that is accomplished by creating FHIR resources.

FHIR resources

A resource in FHIR represents small and locally distinct units of exchanged data. Each resource has a defined behavior and meaning. Contained within the resource are elements and extensions of elements, some narrative, and other extensions to the resource.

It also has metadata, which has elements such as known identity and the location of the data. Of course, each resource has some interest in healthcare (patients, observations, diagnostic reports, and so on). Figure 6.1 shows the relationship between resources and elements:

Figure 6.1 – A FHIR resource examined

There are hundreds of resources defined by FHIR. You can visit the HL7 FHIR website, https://www.hl7.org/fhir/resourcelist.html, to peruse the various resource definitions.

Figure 6.2 – FHIR resources

When you review a resource, you will find a data structure that it supports. You might wonder how you support this structure if your data is in relational databases. Your FHIR architecture may vary based on the approach you wish to take, given the tools you have at your disposal. You have various options for implementing your interoperability interface:

• Broker adapter for FHIR: If you have already used HL7 schemas from previous versions, you can set up a broker transformation into FHIR.
• Proprietary mixed APIs: Perhaps you are using multiple methods to exchange FHIR data. It can be a combination of FHIR and other APIs.
• Vendor-neutral clinical repository: In a clinical situation where you have multiple backend systems, you can establish a vendor-neutral repository to hold all your FHIR resources.

Something to keep in mind is the number of API endpoints you may be exposing. Let’s look at the patient operations:

• Get lists of all patients.
• Get a single patient resource.
• Create a patient record.
• Update a patient record.
• Delete a patient record.

There are approximately 144 FHIR resources. If we support the 5 endpoints listed on all the resources, your number of endpoints totals 720, and that doesn’t include custom endpoints based on consumer/business requirements.

Assuming you may be only addressing a small number of resources, let’s discuss where the data resides after you have utilized one of the various options.