In working for a small company in the healthcare industry I was recently given the task of creating a simple workflow to translate X12 837 and 835 EDI files.  I immediately began researching different options.  I’m sharing the results of my research with the hope that others can benefit from it.

I had 3 objectives the software had to meet:

  1. Transform 837/835 into XML (with minimal setup/configuration/coding)
  2. Transform XML into 837/835 (with minimal setup/configuration/coding)
  3. Be as inexpensive as possible

Since expense was an issue and most commercial EDI packages are quite expensive, I looked to open source first. I reviewed several open source applications capable of processing X12 files (this is by no means an exhaustive list).  I considered an application to be “actively developed” if it had a release within the past 12 months. Here are my reviews in no particular order.

BOTS

BOTS is perhaps the most well known open source EDI application (at least that’s what Google tells me), so I thought I’d start there. From the website,

“Bots is complete software for EDI (Electronic Data Interchange): translate and communicate. All major edi data formats are supported: edifact, x12, tradacoms, xml.”

Strengths

  • Complete workflow application – it can pick up, process and save out files according to workflow rules.
  • Can transform X12 to XML and XML to X12.
  • Backed by a consulting company, so if you need help, you can hire them.
  • An active support forum for issues.
  • Actively developed (latest build: 8/31/2010)
  • Python based, cross platform.

Weaknesses

  • Administration portal interface is just so-so. Very basic UI. Often difficult to figure out what to do next.
  • Steep learning curve to get a workflow running due to the routes, channels and translations (not to mention grammars and mapping scripts) that need to be configured. In fact, after installation and several hours of configuration, I was unable to get any where close to running test files through.
  • The further I got into it, the more it looked like it would require knowledge of Python scripts to get it running for 837/835 files. I didn’t want to invest that much time into it, the X12 standards are difficult enough to learn as is!

EDIReader

EDIReader is also a fairly well known EDI app.  It’s a java package with several command line utilities designed as examples of it’s usage.  From the website:

“EDIReader is a Java package for parsing business documents structured according to Electronic Data Interchange (EDI) standards. It supports the SAX and JAXP interfaces defined for XML, making it suitable for use in any XML-based system that allows the configuration of a custom SAX parser.”

Strengths

  • Simple to use – call one of the example .bat scripts from the command line, pass it filenames and you’re done.
  • Very good X12 to XML transform engine – it accurately produced XML for any edi file I tested.
  • Backed by a consulting company, so if you need help, you can hire them.
  • Actively developed (latest build: 2/14/2011)
  • Java based – cross platform.

Weaknesses

  • Not a complete workflow application – though I found that I liked working with the simple scripts files; it meant I could immediately begin testing output without  a lot of install and configuration time. The script functionality could be easily extended to support an simple, but effective, input/output workflow.
  • No XML to X12 transform available in the open source app.  To get that functionality you’d need to purchase ediwriter.
  • Relatively inactive support forum – there haven’t been any post there for several years.  (I do realize the EDI formats don’t change often, but still I would think there would be some activity.)
  • I also ran into a maddening quirk with how EDIReader creates the XML hierarchy. There was a least one instance where a loop level (I forget which loop id) would create a sibling node instead of a child node.  This made it frustrating to build an Xpath statement that represented the relationship between those particular loops.

Pyx12

Pyx12 was mentioned in a couple places so I thought I’d take a look at it as well. From the website:

“Pyx12 is a HIPAA X12 document validator and converter. It parses an ANSI X12N (Healthcare) data file and validates it against a representation of the Implementation Guidelines for a HIPAA transaction.”

Strengths

  • Can transform X12 to XML and XML to X12.
  • Good documentation on the X12 healthcare formats.
  • Python based – cross platform.

Weaknesses

  • Not a complete workflow application – designed to run from the command line.
  • Requires tweaking of configuration, map and transform files to get it running. The deeper I went with Pyx12, the more configuration I found I needed to do.  I finally gave up.
  • Not actively developed (latest build: 6/16/2008) Though I could be wrong here; as of May 2011 the looks to be some development activity.
  • Inactive support forum – Same comment as EDIReader; since the formats have changed very little I could understand why there’s not a lot of activity.

HIPAATalk

I ran across HIPAATalk on sourceforge and it looked like an interesting approach to EDI transform.  It didn’t exactly fit my criteria of being able to transform into XML, but storing in a database would do if I couldn’t find a decent transform to XML app. From the website:

“HIPAATalk - Contains stored procedures and sample DTS packages for parsing and converting X12 to flat tables and creating HIPAA-compliant X12 files.”

Strengths

  • Complete workflow application – it can pick up, process and save out files according to workflow rules. The caveat here is you need to be running SQL Server Integration Services (SSIS) on SQL Server Standard or above to get the full workflow functionality, so it could be expensive if you don’t already have SQL Server available.
  • If you’re a big MS SQL fan – this one’s for you. It’s a set of DTS packages and a database designed to do the X12 transformations.
  • Can transform X12 to database and database to X12.
  • Actively developed (latest build: 2/17/2011)
  • Active support forum – not a lot of entries there, but the developer is responsive.

Weaknesses

  • It’s currently written as DTS packages (SQL Server 2000) that need to be converted to DTSX packages to run on SQL Server 2005/2008 systems.  That process was more difficult than it should have been.  (I could have just been me though).
  • Documentation is light – it pretty much assumes that you know what to do with the DTS packages and how to do it.
  • Not cross platform.
  • Can’t transform  to XML.

Mirth Connect

Mirth came up on a on a separate project having to do with HL7 messaging.  Since it has X12 capability, I thought I’d look into it.  From the website:

“Mirth Connect, the Swiss Army knife healthcare integration engine. Specifically designed for HL7 message integration, Mirth provides the necessary tools for developing, testing, deploying, and monitoring interfaces.”

Strengths

  • Complete workflow application – it can pick up, process and save out files according to workflow rules.
  • Great UI – it was pretty simple to get a workflow set without reading much documentation.
  • Can transform X12 to XML and XML to X12.
  • Backed by a company, so if you need help, you can purchase support.
  • An active support forum for issues.
  • Actively developed (latest build: 7/6/2011)
  • Java based, cross platform.

Weaknesses

  • Flat X12 XML format – by this I mean it creates all XML nodes as siblings – there is no hierarchy at all.  This makes it very difficult to produce a useable XML file without a lot of additional work.
  • Restricted access to documentation – Yes they do have some available for free, but it looks like most of the advanced documentation (online tutorials and developer Q&A) is available only if you purchase support.

X12Parser

X12Parser showed up on a google search so I thought I’d check it out. From the website:

“The parser allows for a specification of any X12 transaction set to create a generic X12 xml representation of the hierarchical data contained within the X12 document.”

Strengths

  • Simple to use – call one of the example exe’s from the command line, pass it filenames and you’re done. I was testing files within 5 minutes of downloading the app.
  • Accurate representation of X12 structure in XML – this really differentiated it from EDIReader; X12Parser accurately represents all the loops and their relationships to parent, child and sibling loops.
  • Good use of internal XML comments.  The XML is well documented – which helps newbies like myself understand what each node is.
  • X12 Unbundle feature – this new feature will “unbundle” an X12 file into multiple valid X12 files based on a specified loop id. Great for separating into individual claims.
  • Actively developed (latest build: 7/10/2011)
  • Quick development iteration – I initially had trouble with a couple files causing X12Parser to fail, but contacted Dannie and he quickly resolved the issues .
  • Active support forum.

Weaknesses

  • Not a complete workflow application – though I like working with the command line executables; it means I can test output without a lot of install and configuration time.
  • Not cross platform. (Not too big of a deal for me since Windows is my preferred OS)

Conclusion

As you can imagine, since I’m writing this on the X12Parser site, that it’s ultimately what I ended up using.

I’ve now tested 100’s of 837/835 files through it and feel confident enough in it’s ability to put it into production use. I’m planning on integrating the X12Parser executables into an ETL workflow process (most likely Pentaho or Talend).

Last edited Jul 15, 2011 at 4:34 PM by nth, version 5

Comments

DonZoeggerle Jan 2, 2013 at 6:46 PM 
You should try edifabric - it's plain easy to use and supports ALL X12 and EDIFACT transactions.

rageit Jun 18, 2012 at 3:03 PM 
Nice review!

cherio Dec 29, 2011 at 9:51 PM 
Great review by the way!

cherio Dec 29, 2011 at 9:51 PM 
Cross platform criteria is very important since quite often the format conversion runs on the server and Windows may either be not the best choice for that or there may be already existing servers running Linux/Unix OS. I am wondering if this parser can be compiled for/on Linux with Mono framework ........