Using FHIR Adapter to offer FHIR services over legacy systems - Architecture

We return with our example of using the FHIR Adapter, in this article we are going to review how we can configure it in our IRIS instances and what the result of the installation is.

The steps taken to configure the project are the same as indicated in the official documentation, you can review them directly here. Well, let's get to work!

Installation

As you can see in the project associated with the article, we have our IRIS instance deployed in Docker, so the main part of the initial configuration will be done in the Dockerfile. Don't worry, we won't go into details about the Docker configuration.

To install our FHIR Adapter we only had to:

1. Create a Namespace called ADAPTER in our IRIS instance with the Interoperability functionality.
2. From the IRIS terminal, access our Namespace and execute the following command.

set status = ##class(HS.FHIRServer.Installer).InteropAdapterConfig("/Adapter/r4")

In our case we have defined that the URL of the IRIS endpoint that will receive the REST requests will be /Adapter/r4.

Installation result

Once the installation of FHIR Adapter is complete, we can review what has happened in our IRIS instance. To do this, we will first go to review the web applications menu (System Administration -> Security -> Applications -> Web Applications)

As we can see, a new web application has been added to the list, indicating that it corresponds to our ADAPTER Namespace. Let's access it to review its configuration in more detail.

As we see, the web application created has the reception of REST calls enabled and the class responsible for managing these calls is HS.FHIRServer.HC.FHIRInteropAdapter. Another detail we see is that both password authentication and unauthenticated calls are enabled. For our example we are not going to modify anything, but it would be interesting if JWT authentication were enabled in any production environment.

Let's review what has happened in the production of our Namespace.

The installation has created and deployed two new components, the Business Service InteropService and the Business Operation InteropOperation. For our example we are going to only use InteropService which will be in charge of forwarding the FHIR message received, this will be of the class HS.FHIRServer.Interop.Request and it will be the one on which we will work to extract the information received. The response that InteropService must receive to return the response JSON will be of type HS.FHIRServer.Interop.Response.

Configuration of our "HIS"

We mentioned in the previous article that we were going to simulate interoperability with a theoretical HIS, for this we have deployed a PostgreSQL instance in our Docker with a series of test tables. In order to launch queries on this external database we have included and configured the Java Gateway, so that we can make the necessary connections via JDBC. We have also included the JAVA library that we will use to connect with PostgreSQL.

Let's look at the production components responsible for this connection.

We have our JavaGateway configured to point to the Java virtual machine that we have deployed in our Docker:

The Business Operation FromAdapterToHIS will be in charge of queries to our PostgreSQL, let's see its configuration:

As we can see, it uses EnsLib.SQL.OutboundAdapter as the Adapter class, which will allow us to connect directly to the database of our "HIS". The DSN value will be the connection string to the PostgreSQL instance deployed in our Docker.

In summary...

Let's review what we've done in this article:

1. Installing the FHIRAdapter in our Namespace and checking that we have an endpoint to send our FHIR messages to.
2. Checking the components created by defects in the production of our Namespace (InteropService and InteropOperation).
3. Creation of the necessary components to communicate with our "HIS" database.

With these steps we have everything ready to start receiving FHIR messages in JSON format. In the next article we will create the Business Process in charge of processing the received messages and implement the different functionalities that we will need to consult and write about our PostgreSQL database.

Thank you so much for your attention!