HIE Interface Example with CDA and HL7 Data

This is a demonstration of the eiConsole for Healthcare. 

In this demonstration, we’ll be taking in some CDA as well as some HL7 data and sending that on to a database. 

From the main file management screen, we’ll open up our interface. From this view, we’ll see from left to right how we build this interface—starting with the Source System on the left and moving through onto the Target System on the right. 

In the first row, we’re taking in some CDA – picking that up from an FTP. We’ll then send that on to the database. Looking at the second row, we’ve got some HL7 coming in over LLP and we’ll also be sending that onto the database. 

Listener Stage

Let’s start with our first functional stage, the Listener stage. 

By clicking on the Listener stage, you can see that we have some simple configuration boxes below. Preset with defaults, with just a few required fields to hook up to your connectivity protocol. In the case of this SFTP Listener, we’ll fill out required information such as our host and port number. Also, maybe fill in some credentials. 

Looking at this HL7 Listener, we’ll specify our port. We’ll also specify if we want to auto-generate our acknowledgment. We can choose to acknowledge right after this stage or acknowledge later in the process. 

We can also apply different types of pre-processors to our data. Now, this is not a logical transformation of the data; this is simply doing some sort of massaging – such as encryption, decryption or decompression. 

As you can see, we have many of these things out-of-the-box that you can simply click and add. Maybe fill out some simple configuration information. 

Source Transform Stage

Let’s move on to the Source Transform stage. 

Now this stage happens in two parts. First, our Transformation module will take any type of data format coming in and automatically convert that into an XML representation of that data. 

Simply click on this drop-down box and choose the inbound format that you expect to receive. In this case, the CDA that’s coming in is already in XML, which is the canonical format that we use for our transformation. So I don’t need to have a Transformation module in place for this particular inbound data format. 

The second part of our Source Transform will be our logical transformation. This happens within our data mapper, which I’ll show now. 

This is our 3-pane data mapper. On the left-hand side is what we’re mapping “from,” and the right-hand side is what we’re mapping “to.” In this case, on the left, we’re mapping from CDA. On the right-hand side, we’re using SQL XML to connect up to our database and pull in our tables. We can then use SQL functions to do different types of workflows within our database with the data inbound. We have several format builders out-of-the-box. You simply choose what the inbound data format you want to map from is. 

As you can see in our drop-down, we have many industry standards and data formats available. 

In this case, I’m using CDA which is already in XML format and using a sample file so I would choose XML. If I wanted to build CDA out-of-the-box from the standard, I would simply choose HL7 v3. On my Target side, I can do the same. Many of the same format readers out-of-the-box. 

In this case, I’m using SQL XML. 

Here I just enter some simple credentials in my database and pull in the tables I want to use. In this example, I’m pulling out some general basic patient data from the CDA I’m inserting it into this table here. I use the insert function by dragging it onto my mapping in the middle, providing my column names in this mapping as well. Simply find the fields relative to these values and drag & drop them onto the mapping. 

Under the hood, this mapping is actually writing W3C-compliant XSLT. This is a fully-featured editor. Use it if you feel more comfortable using that. Anything that is done within this editor view will also show up in the drag & drop view and vice versa. 

We also have a testing tab at the bottom, which provides inline testing for our mapping so we can test as we go to ensure fields are mapped to the correct spot. 

I can feed it a sample file, press a button and watch the output below. 

HL7 Data Mapping

Let’s take a look at our mapping for HL7. 

First, on the left, we have a transformation module where we’ll choose the inbound format coming in so that we can automatically change that into an XML representation of that data. 

I’ve simply chosen HL7 2.x to find my version and on the right, we can open the data mapper to see the logical transformation. 

Let’s take a look at our HL7 mapping within the data mapper. 

On the left-hand side, I brought in some HL7 data. I can turn on “friendly names” to see more definitions. If I wasn’t super familiar with HL7 as a whole, I could use these “friendly names” to know what I’m looking at. I’ll show how we pull in that HL7 on the left. 

Go ahead and open our format builders and I would choose HL7 2.x. I could then go ahead and define my version here, although I don’t have to and down below, I can use a sample file of my choosing if I want to build the template off of that which I have in this case or I could just use the actual standard itself and choose the message type I want to work with. 

As you can see, again on the right, we’re actually using SQLXML to build this mapping. We’ll go ahead and connect up to that database with some credentials, pulling in this table called SHIEC20 HL7. And here are my column types; so I’m going to use these columns on the mapping and drag & drop the associated fields right onto them. That will give me an insert into this database table for each of these columns with these field types underneath them. 

Again, I can switch over to the testing view, feed it a sample file, hit a button and see my output. So I can toggle between the two to make sure that I’m mapping the fields correctly. 

Routing Stage

Next is our Routing stage and here I’m just going to define which Targets I’m going to send this data to. In this case, I’m on all Targets which is just one database. If I wanted to, I could switch that over and create some XPath rules to define where I want my data to go- which Target, based maybe on some attribute or part of the message and rules that I apply according to my business logic. 

Within this module, I can also set up transaction monitors. What happens in the event of an error? We have out-of-the-box different monitor types such as email alerts. If something were to happen, we can also use this error route trigger which will trigger another workflow or another interface if you will defined by what you want to happen in the event of that error. 

Target Transform

Let’s move on to our Target Transform stage. 

Now here, if I needed to do another logical transformation, I could. If I had multiple outbound Targets or multiple inbound Targets, instead of having to do a one-to-one transformation every time, we would have fewer of those transformations by using that XML canonical format. 

If I did need to send those to multiple Target Systems, I might have another transformation here. 

Transport Stage

Moving on to our Transport stage, this works much like our Listener in that it will define how we connect up to that Target system. Again, out-of-the-box we have a lot of different connectivity protocols. Here, just like our Listener, I’m going to be using the database connection here. I’m just going to enter some simple connection information to my database. I can even test that connection inline. 

Testing Mode

And now, we’ll move over to testing mode to show you how we can run tests or debugging on the interface that we just built. 

Within our testing mode, we can choose to start a test at any point. We can skip stages or end the test early, and we can also save tests that we commonly use if we need to. Kind of a toggle back and forth between editing mode and testing mode. 

I will go ahead and use a saved test that I’ve already created. I’ll be testing the HL7 portion of this data from end to end here. Now since I’m not actually listening to this port for HL7 I’m going to be using a sample file which the system will prompt you to do in the case of starting a test after the Listener stage. So I’ve saved that sample file already into my test configuration. All the arrows you see here is where the test will go once I hit execute test. 

Once I execute that test, you’ll see that I have all green checkmarks which means success. If I were to have any red x’s that would show a failure. 

I can then drill down and look at the data that I just tested. Here I can see the sample file of HL7 that I fed it for the test. I open up this stage here. This is the XML representation of the data that was created. Here I can actually see that SQL that I made when I was doing my mapping and how that will be inserted into my database. 

Over here is my Transport, and I’ll go ahead and actually toggle over to my database, which is an H2 big database that I set up for this demo, so we can see that the data is actually in there. 

Here’s my database with that table, SHIEC20HL7. So I’ll go ahead and run that and there we can see those columns that I created and mapped to now have those values from that sample message and the same would work for our CDA if I were to test that as well. 

So you’ll use this testing mode and editing mode together, toggling back and forth to make small changes and test as you go. 

That is the demo that we have today. Thanks!

We recommend downloading a Free 90-Day Trial of the eiConsole and taking a look at it yourself. More PilotFish videos demonstrating other software features are listed on this summary PilotFish Product Video page. If you have any questions, don’t hesitate to ask.