A Quick Summary

The recording of the full webinar is available here, but I’ll summarize it briefly if you can’t watch it yet.

Every industry is facing a litany of data challenges — interoperability in the face of different data formats, government regulations, differing standards (and implementations of standards) between applications, infrastructure control. With healthcare, these challenges are amplified because of higher burdens on data integrity, cross-provider integration, and regulatory oversight.

So the challenge presented here is how can we get a lot of disparate systems talking together? Another way of putting it is how do we (effectively) get healthcare interoperability or healthcare integration? Christina’s approach to this is influenced by microservices architecture. The individual applications are separate yet connected through a common messaging framework (Apache Camel, in her demo app). The sample workflow takes a registration event (the client application) and sends it to a registry which defines the APIs and routes for the workflow. Routing engines at various points in the workflow allow data to be transformed when necessary and sent to the next application.

In imperfect but interesting parallel is to look at Christina’s design like an inventory system. Registration information is a box that just got dropped on a UPS conveyor belt and information about that box is passed through the system until it reaches its endpoint.

Q1: What is HL7?

It’s short for Health Level 7. It’s a data standard that defines how clinical and administrative data for patients are transferred between applications. This covers a variety of services, from billing to patient transport. As a standard, it is fairly old; it was defined first in 1987.

Q2: How does HL7 relate to HIPAA?

HL7 is one part of the overall Health Insurance Portability and Accountability Act (HIPAA) regulation.

Q3: What is the value of having both a registry and a routing engine? It seems redundant for an internal application.

A registry keeps a list of artifacts. The routing engine defines and executes routing logic.

Now, this question is really specific to the demo, so let’s take a look at the sample registration workflow. Using a web app, an admitting nurse enters the information for a new patient. That information is sent to the Admit Patient endpoint, which is the registry.

The registry has a set of APIs and a single API endpoint to allow the application to detect the registration information. The registry stores the information in a database. From there, it sends a (synchronous) message through the queue to the next step in the flow. That is the HISESB area, which routes the information to all of the departments within the hospital. (Although this is an enterprise bean, an ESB is actually pretty heavyweight for the function it is performing in this particular flow. The ESB are being used just for routing; it tells where to send the information at the next step in the flow, so it is just being used as a routing engine.)

At this point, all of the applications are using an HL7 data format, except for one: the laboratory. The FHIRESB / routing engine sends information to the laboratory but it first transforms it from HL7 to FHIR/REST, which the laboratory application can read.

So, to circle back to the original question: the registry is used to detect and store incoming data and to define the APIs and endpoints throughout the workflow to use for data integration and messaging. The routing engines are used to forward information and, when necessary, transform it into required data formats.

Q3: Where can I find this demo?

The core of the webinar is available in three blog posts by technical marketing manager Christina Lin:

I don’t have any contact information for Christina (and that wouldn’t be appropriate, naturally), but you can try commenting on her blog. She has a number of Fuse posts there. Link: http://wei-meilin.blogspot.tw/