Using Rhapsody as a FHIR® Façade (Part One)

Anyone who maintains a store of clinical data will be thinking about if and how they should be exposing that data for use by external applications. In reality, there are a large number of issues to address when doing this, as it is highly sensitive data, but let’s focus on the technical aspects in this blog — we can come back to security and privacy later.

Access all of our FHIR Resources.

In fact, this is the first in a series of blogs that starts with a simple case then, over subsequent blogs, will build on the original to add more complex scenarios.

But, before we start, let’s think about the architecture – and the toolkits that we’ll use.

We’ll assume, for the moment, that the information we want to expose is stored in a Relational database, and we want to expose that data using a real-time RESTful FHIR interface.

So, we’re going to need something between the client and the database that can accept a query from a client, retrieve the data from the database, and return an appropriately formatted response to the end user.

There are a number of options for the middleware component, with one of them being an integration engine like Rhapsody.

Now, it does need to be stated that Rhapsody is not really built for high-performance real-time use — rather, it’s geared to high-volume message processing. The huge advantage it brings is that it can be quickly deployed with minimal configuration (no development) and will offer reasonable performance until the volumes become large.

This makes it an ideal way to try out ideas to see what is useful, and what is not. In other words, an iterative process where you can deliver results quickly and cheaply, then make them more robust when there is a demand to do so.

In this series, we’ll use the example of exposing encounter information. The first use case will be providing a list of all the encounters in the database (I know that this could be a huge number of encounters, but let’s get the basics set up first.)

The route that we create will look similar to this:

So, the response to a query will be this.

1. The FHIR request will be received by an HTTP Comm point. In the encounter example, it will be something like GET [serverBase]/Encounter.
2. The parameters are extracted next and, in this simple example, we’ll pull out that the resource type we’re after is Encounter.
3. We’ll use these parameters to construct an SQL query, and send that to the database. This will be something like SELECT * FROM TBL_ENCOUNTER.
4. The response is returned as an XML document. Our next job is to convert that to FHIR. This will be a little bit more work – and we have a couple of options we can use which we’ll consider shortly. The output will be a FHIR bundle which is the ‘container’ resource for multiple resources. This can either be in XML or JSON.
5. Finally, the FHIR bundle is returned to the caller.

So that’s the background for our little project. The next blog will focus on how to implement it in Rhapsody and will spend a little time on the fourth step — converting the response from the database into FHIR.

Learn more about Rhapsody Integration Engine.

Health Level Seven, HL7, FHIR, and the FHIR [FLAME DESIGN] are registered trademarks of Health Level Seven International, registered with the United States Patent and Trademark Office. The use of these trademarks does not reflect HL7’s endorsement.

Using Rhapsody as a FHIR Facade:

• Part Two
• Part Three