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 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 database, 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 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 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 X12 EDI 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 including Type 1 – integrity testing, Type 2 – requirement testing and Type 3 – balancing. For example, adding up all the values for claims and then specifying how you want those validation results to be produced. Once we’ve configured our EDI transformer, it’s ready to convert X12 data to XML.
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, 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 take this name field, right-click and delete. To map it, we simply drag & drop it from the right on to 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 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 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, 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 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.
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.
For more information, please call us at 813 864 8662 or click the link below to email us.
X12, chartered by the American National Standards Institute for more than 35 years, develops and maintains EDI standards and XML schemas.