X12 EDI Transaction Integration Made Painless

As a select distribution partner of X12, the Pilotfish eiConsole Integration Engine now offers a suite of productivity-boosting features that strip away the technical complexity of parsing, validating, mapping and producing X12 EDI Files. Over the next several minutes you’ll see these new capabilities in action.

This is the eiConsole – It’s an integrated development environment for building, testing, deploying and maintaining integration interfaces. When you first open the eiConsole you’re shown this route file management dialog.

Up at the top, you have your currently selected working directory, you can think of this as your project folder and then within this table, you can see all the routes and all the individual workflows composing your interface.

Our interface is composed of these three routes. The first, ASC X12 837 claims processing, receives ADS messages, converts them to XML, validates them and maps their contents to a database.

The second, 999 acknowledgment creation, generates the X12 acknowledgment and last the EDI transaction forking demonstrates handling batches and high volumes of X12 EDI Transactions.

We’ll start by opening up our first route. Now that our first route is open, we can see the main eiConsole screen featuring our assembly line approach to building interfaces.

This assembly-line approach allows you to quickly and easily connect any system to any other system regardless of the format or protocol between them.

Now in the main eiConsole screen on the left-hand side, you have rows representing sources and rows representing targets. You would start by adding however many sources and however many targets were necessary to describe your interface. You then move left to right through our assembly line approach configuring each stage.

Define Your X12 EDI Data Source

Your first stage is the source system. This is a place to provide a name and optionally an icon for what it is you’re connecting to – typically describing the format or the name of the system.

The first functional stage is the listener. At the listener stage, you’re going to choose a listener type from this drop-down or this dialog here. There are a number of ways to send and receive data databases, email, FTP, HTTP directories and so on. Generally, if you can think of a way to send receive data there’s a listener available.

Simply choose the listener, provide some configuration and now it’s ready to pick up messages and send them through the system. Those messages will move left to right through each of the stages you configure, generally, in the same order you’ve configured them.

Select Your X12 EDI Message Processor

In the first set of stages, that message goes to our processors. Processors perform high-level operations on data. Typically, things like decryption, decompression, character conversion and so on.

In this particular route, after we’ve received our message (we’re assuming it’s a zip file), we’re going to decompress it, and then we’re going to decrypt it.

Transform Your EDI Data into a Common Format

Each source system then has its own source transform associated with it. Now the job of the source transform is to take whatever that particular source system gave you and convert it to a common representation that’s understood by the rest of the route. This is a two-stage process.

The first part is a transformation module to take in any non-XML format and convert it to XML, and then optionally there’s a logical transformation from that XML that’s produced into whatever we consider our route canonical.

We’ll now take a look at the EDI Transformer. This component automatically converts EDI X12 messages to XML, as well as performing validation along the way.  There are a number of useful features configured in these tabs. We’ll start at the transform to XML. The first option allows us to specify EDI table data for use in validation naming and structuring of data. Here we can provide a location for those table files.

Next, we can enable code definitions to get more contextual information whenever EDI code values are used, such as in a REF or NM1 segment. The friendly naming feature provides friendly human-readable names and meanings. The created XML is very useful in allowing you to understand EDI messages easily.

We also have built-in support for automatically performing SNIP validations. 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

Let’s take a look at Mapping X12 Data to, or from another format using the data mapper. Here, we have a mapping from X12 to a relational database. We’ll take a look at it in the data mapper by clicking here. Our data mapper is a 3-pane mapping tool. On the left-hand side here is our source format. In this case, it is the EDI X12 we’re mapping. From our right-hand side is our target format. In this case, it’s what we call SQLXML, and in the center is a tree representing our actual mapping logic. 

Now use this tool by dragging and dropping from the left and right-hand panels into the center tree.  Everything’s completely graphical drag & drop. The first thing we’re going to do when we get in here is to push this button to enable “Friendly Names”. This is going to tell us, for example, that a loop 2000 A is our billing provider loop. If we expand this, we’ll see, for example, that the loop 2010 AAA is the billing provider name loop with the various segments for naming the billing provider.

Here we can see the friendly naming providing us all the information we need to be able to map from. If we can understand what the billing provider’s first name is, then you don’t need to know that it’s under a loop 2010 AAA and NM1 NM 104. You can map to and from EDI without really understanding the intricacies of the format itself. Now the right-hand side is SQLXML, this is an XML representation of SQL statements. So, what we’re going to be doing is an insert into this table, using this column, and this column and this column and so on. 

Now we have those columns represented here dragging and dropping from the right and then we populate them from the left so what we’ll do is show that. We’re going to take this name field, right-click and delete it. To map it, we simply drag & drop it from the right onto the EDI billing provider and then go on and provide a name.  Here I could just say, well I want to use the first name; then we’ll drag & drop that here and it’s going to create the logic necessary to accomplish that mapping.

That’s all you do, drag & drop from the left and right. You can map anything to or from EDI.  Now underneath this mapping, it is producing a W3C compliant XSLT which you can always view by dropping this XSLT view down here. Now, this is a fully-featured editor allowing you to make changes. Any changes you make will show up in the mapping and vice versa. The only reason we show this is to note the W3C standard transformation language. There’s nothing proprietary, there’s nothing tying mapping specific to our tool so the drag & drop is going to produce this.

Then you also have the ability to do testing. You can give it a sample file, push a button, and see your output. We have a debugger to allow you to do that step-by-step and a number of other features that make it kind of easy to do mappings. You can search and sort through the source and target format, you can add notes for collaboration, and where there’s documentation in the EDI standard those are down here available in these tabs along with further information or sample files or for coded values. It shows what the code value in this particular case is.

Testing Your EDI Data Route

Now that we’ve quickly walked through our mapping we’ll return to our main eiConsole for X12 screen and perform some testing. I’m going to go to the route, switch to testing mode, and then we’re going to run the test from a certain point. We’re going to choose a source transform, provide a sample file, and then we’ll hit Execute Test and we’ll see our transform run across.

We could now view the original X12 EDI message – shown here broken into different lines for legibility. We can see the XML representation of that with our friendly naming. We can see for example that an NM 101 is an entity identifier code and some information about the code definition telling us this 41 represents a submitter.

This shows our XML with the human-readable, “Friendly Name” option enabled. You can see that as long as you can understand what a subscriber’s first name is or what healthcare code information is you can work with this.

Our transform over here to our database product. This a very small segment of some sequel XML so we’re going to do an insert into this table this column. We’ll get the value, then the area of service, address, city, state, zip and so on.  What I’ll quickly do is just take a look at our database and see what the contents within look like.

Here we have our database shown in a browser. It’s a simple embedded H2 database with a single table. We’ll run a basic query, hit run and we can see the insert from our latest test here – with a name, address, city, state and zip as it came from the EDI.

Now for this interface, we do a few other things too. In addition to inserting it into a database, we also call another route that is used for generating the acknowledgment that is generating some EDI that’s going to be sent back to the original caller.

Here’s that route here. We have a listener here that’s going to accept the data from the first route and here we see an EDI transformer being used on the target side for this. All we really need to do is specify if we want in lines for human legibility and what the different delimiter is that we’re going to use in the product EDI. That’s it.

The next step is just going to the transport and specifying how we want to send that out. In this case, we’re just going to write out a file. But if you can think of a way to send or receive data, it’s probably transport available.

For now, the last route we want to take a look at is our EDI transaction forking.  This demonstrates the handling of large transaction sets either in batches or in parallel. Now the source transform we’ve specified in this forking tab for this EDI transaction forking module and what this is going to do is enable it to take an EDI message containing maybe one, dozens, hundreds, thousands or even millions of EDI messages and break them into discrete batches according to some delimiter. Here they’ll then operate in parallel where they can be reordered and sent along to your final destination system.

This has been a relatively quick walkthrough of some of the EDI features and functionality that are now in the eiConsole.  Read more about X12 EDI Transaction Processing with PilotFish.

Try it for Yourself!

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 Video page.  If you have any questions, don’t hesitate to ask.

Product Note: The eiConsole may be purchased with X12 artifacts, or X12 artifacts may be licensed directly from X12.

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