Integrating HL7, X12 EDI and FHIR JSON for Healthcare Analytics and Reporting

The eiConsole uses the EDI SNIP Validation Processor to apply SNIP Types 1 through 3 out of the box with an option to add Types 4 through 7 for full structural situational plus semantic checks.

Yes. The pattern used in the video is reusable for any X12 transaction so you can plug in different versions for payers or providers without rebuilding the entire route.

You switch the eiConsole to Testing Mode, load a sample X12 file, then step through each stage in the route to inspect raw EDI, baseline XML, mapped canonical XML and the final JSON output before deploying the route to eiPlatform.

Yes. PilotFish supports deployment on virtual machines cloud infrastructure or Docker containers with hot deploy so routes can be updated without downtime.

EDI X12 Healthcare Interface Engine

This is the PilotFish eiConsole – the developer’s workstation you’ll use to build, test, maintain and deploy all of your integration interfaces. Also, along the way, we’ll be diving a little bit deeper into some of the EDI functionalities available with the eiConsole. So let’s get started.

Route Built with HL7, X12 EDI & FHIR JSON Feeds

Opening up this route here – this is our aggregation for analytics and reporting route. Here, we see that we have several different data feeds – some HL7, EDI, and some FHIR JSON – but we will be primarily dealing with our EDI feed. We have our source systems on the left – you can think of each row as a place for getting data “from”. We have our target systems on the right – this is our place for sending data “to”. No matter which system it comes “from” or the data format it moves through, the same assembly line process as ingested, transformed, routed and finally sent to its final destination.

Let’s take a look a little bit closer at our EDI feed here. We’re starting out with an FTP listener to pick up that EDI from our provider. Here, we’ve defined our host port, credentials, and how often we want to look for files and then with that setup, the Listener is ready to go. Next, we’ll be moving into our source Transform stage, where we’re taking that raw EDI and transforming it into XML.

EDI to XML Data Transformation

With the PilotFish software, we use XML as the underlying data format for all of our different transformations. It makes it very easy and extensible to be able to work with these across routes, across transforms – so that anywhere in the product (as long as you’re familiar with XML), you can operate on the data.

We’re transforming this EDI in a two-part process – where first, we’re using our transformation module to take that raw EDI and turn it into that XML baseline format. Since we’re dealing with X12 EDI, we can add some additional context to the structure we’re producing. For example, we can do things like adding in some human-readable friendly name code definitions.

Validation of SNIP Types 1-7 (SNIP Levels) is handled by PilotFish’s stand-alone rules-driven EDI SNIP Validation Processor. The EDI specification includes SNIP Types 1-7 (SNIP Levels) that define checks to ensure a given EDI message is EDI compliant and passes specific criteria for being well-formed. PilotFish provides SNIP validation out-of-the-box for Types 1-3 and Types 4-7 as an add-on.

X12 EDI Data Mapping

The second half of that transformation process is a logical mapping. This is an XML to XML mapping using our data mapper.

This is our data mapper here. It’s our 3-pane graphical drag & drop mapping tool. (Learn more about X12 EDI Data Mapping) The way that this is assembled is that we have our source format on the left. Since we’re dealing with EDI, we’ve got our EDI 837 XML here. You can see all of our loops there. And on our target side, we’ve got this little patient canonical XML structure that we’re hoping to produce.

You basically drag & drop into the center pane to build your mapping, using the tools palette at the top for more complex operations as needed.

It’s really just as simple as looking here – we’ve got our patient last name and we’ve just navigated through the tree to get our 2000 B, 2000 BA, get our NM 103 drag it into the pane – then it’s ready to go.

Routing EDI Messages

Next, we move into the routing stage. The routing stage primarily acts as a kind of balance between the source and target systems. So for any of our incoming source messages, we can set up arbitrarily complex routing rules to save for this given message – it may be based on something in the data itself or some transactional information around that data – send it to a certain subset of target systems. But here, we’re just sending it to all targets and then moving into our target side. Here we’re taking that EDI XML and we’re using it to produce some database insert statements to update this quality measures data store and then we’re also taking that EDI XML and producing some JSON.

Testing the EDI Route

Looking at it in testing mode, we’ll look at some real data flowing through. Here we’ll load up this EDI test that I have saved. As I hit “go”, we’ll see the data move through the system – moving left to right through the stages. Here we can look at the output of each of the different stages in testing mode. We’ll see here the sample 837 claims file that we’re starting out with. Then we can look at the results of our EDI transformer where we’re producing that baseline XML structure and where we see those friendly names that I mentioned earlier.

Next, we can look at our XSLT stage. Here’s that little patient canonical XML that we produced in our data mapper. Moving into the routing stage, we didn’t do any transformation here so there’s nothing really to see. But then looking into our target side, we can look at the results of our XML to JSON and we can see our JSON transformer.

Here’s the final XML payload actually in JSON – so we’ve gone from EDI to XML and then to JSON, all in one step. And then finally here – looks like our RESTful web service wasn’t quite ready to receive our message yet; that’s something that I could then go fix and then come back to retest. So it’s really just that simple with the eiConsole.

As you can see – in just a few easy steps, we were able to ingest some data, transform it to XML and then transform it into both database statements (as well as into some JSON (a different file format)) and then send them both on to their final destination systems.

Try It!

For more on PilotFish’s EDI tools and resources, go to Building an X12 EDI Interface in 10 Easy Steps, X12 EDI Data Mapping, X12 EDI HIPAA Transactions and X12 EDI Healthcare Supply Chain Transactions.

We invite you to take advantage of PilotFish’s eiConsole for X12 EDI by downloading a full, FREE 90-Day Trial Version of our software. Users can try out our new EDI Transformation Module and Format Builder. With the eiConsole X12 EDI Quick Start Tutorial, users can complete an end-to-end interface in less than 20 minutes and get a real sense of the ease-of-use of PilotFish’s Interface Engine solutions.