EDI X12 Healthcare Interface Engine

This is the PilotFish eiConsole – it’s 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, some FHIR JSON – but we will be primarily dealing with our EDI feed. How this is assembled is that 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, how often we want to look for files and then with that, 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.  We can do things like adding in some human-readable friendly names 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 make sure 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 for 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 – maybe 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. 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!

Use this link to download a FREE 90-day trial of the eiConsole for X12 EDI and test it out for yourself. Thank you for watching!

X12, chartered by the American National Standards Institute for more than 35 years, develops and maintains EDI standards and XML schemas.