X12 EDI Transaction Integration Made Painless with PilotFish

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. Within this table, you can see all the routes and 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 our first route. Now that our first route is open, we can see the main eiConsole screen, which features 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 targets were necessary to describe your interface. You then move left to right through our assembly-line approach to 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’ll choose a listener type from this drop-down or this dialog. There are a number of ways to send and receive data, such as databases, email, FTP, HTTP directories and so on. Generally, if you can think of a way to send and receive data, there’s a listener available.

Simply choose the listener, provide some configuration, and it’s ready to pick up messages and send them through the system. 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’ll decompress it and then decrypt it.

Transform Your EDI Data into a Common XML 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 that takes in any non-XML format and converts it to XML. Optionally, a logical transformation from that XML is produced into whatever we consider our route canonical.

We’ll now take a look at the EDI Transformer. This component automatically converts X12 EDI messages to XML and performs 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. 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 Mapper

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. The left-hand side here is our source format. In this case, it is the X12 EDI 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 NM104. You can map to and from EDI without really understanding the intricacies of the format itself. Now, the right-hand side is SQLXML, which 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 to 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 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 and available in these tabs along with further information or sample files or coded values. It shows what the code value in this particular case is.

Testing Your X12 EDI Data Route

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

We can now view the original X12 EDI message, which is 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 tells us this 41 represents a submitter.

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

Our Transform here is to our database product. This is a very small segment of some sequel XML, so we’re going to insert this column into this table. 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 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. We have a Listener here that’s going to accept the data from the first route, and 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-line for human legibility and what the different delimiters are that we’re going to use in the product EDI. That’s it.

The next step is to go to the Transport and specify how we want to send it. 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 will 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 will 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 available in the eiConsole. 

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 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.

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