Everyone has a lot of fun utilizing FHIR in puns, but when it gets down to interoperability in healthcare, utilizing FHIR APIs is just what the doctor ordered. What you will be creating is the FHIR Patient resource as an API and retrieving data from an FHIR server on the web. The endpoint you will be calling is http://hapi.fhir.org/baseR4/Patient?_pretty=true.

If you were to call this from your browser, you would see all the patients in JSON data format returned, as shown in Figure 6.5:

Figure 6.5 – Patient resource data

You will be working with the Patient-swagger.json file that you downloaded from the book’s GitHub repository.

To create the FHIR, perform these steps:

1. Start the LTE environment:

apic-lte start

With a successful start of the LTE, you will receive some valuable information that you will need to log in to API Connect. They are shown as follows:

Figure 6.6 – apic-lte startup output

For now, that is all you will be needing to log in.

2. Launch the API Designer by double-clicking on the API Designer app that you installed previously:

Figure 6.7 – Starting the API Designer

3. Choose the directory/folder where you have downloaded the Swagger files previously. Most likely you already have logged on previously:

Figure 6.8 – Logged-on environment

4. Click on the localhost:2000 listing. You may get prompted to log in again, so you should use the information that was output when you started the LTE.

5. Select the Develop APIs and products tile. You should see the Patient API title and perhaps other APIs from prior chapters:

Figure 6.9 – Imported Patient API

Notice that the Version is 4.0.1. This represents the version of FHIR that this API supports. You can also see that it supports OpenAPI 2.0 specifications.

Tip

If you do not find the patient API file loaded, please download it from the GitHub site and use the LTE to add a new API using the existing OpenAPI import. You will find these files in GitHub using this URL: https://github.com/PacktPublishing/Digital-Transformation-and-Modernization-with-IBM-API-Connect. Once completed, you can continue with these steps.

6. Select Patient API to bring up the designer so you can review the FHIR API and make modifications. You should explore the following sections to gain a better understanding of what FHIR requires.

Click on Design and then the General drop-down menu. Click on Base Path to review the base path. This is shown in Figure 6.10:

Figure 6.10 – Patient API Base Path

Another important section relating to the URL is the parameters. Click on Design | Parameter Definitions. This is where you will see all the parameters defined within the API. Figure 6.11 shows some of the parameters:

Figure 6.11 – Patient API Parameter Definitions

Another important section is your schema definitions. Click on Design | Definitions to observe what is already defined. These are the elements for the FHIR resource. This is shown in Figure 6.12:

Figure 6.12 – Definitions shows the FHIR data elements

Next, you can review how API Connect provides the ability to enhance the runtime of the API.

Click on the Gateway tab and then select Gateway and portal settings. Scroll until you see the Gateway (option) label. Notice the two gateway types (datapower-api-gateway and datapower-gateway). Figure 6.13 shows the location of the Gateway dropdown:

Figure 6.13 – Gateway selections on the Gateway tab

The two gateways allow the API developer to choose which implementation of gateway will satisfy the type of API developed. For APIs migrated from the previous version 5 release of API Connect, datapower-gateway provides version 5 compatibility. For newly developed APIs, datapower-api-gateway provides additional functionality and an increase in the API performance.

Also on the Gateway tab is the Properties section. Notice the default endpoint. It is named target-url and its associated value is https://hapi.fhir.org:

Figure 6.14 – Properties displays references to variable fields

As you can see, a lot has already been defined for you and there are places where you can add documentation about your API. If you were doing this with an empty OpenAPI Swagger file, you would have had to create all of those details. Luckily for you, it was all handled previously.