What business needs or situation did you have?
We had a need to be able to create and parse 270/271 eligibility on behalf of our clients. This grew to include 837i claims and 835 remittance advice files. We needed whatever library we used to be fast and well maintained with updates as business outages due to file spec changes would cause our applications to no longer work (e.g. 5010 changes). We needed to make sure that we could handle whatever EDI given to us by our clients in the healthcare sector, regardless of whether or not there were structural errors, or had unusual delimiters or simply had missing required data.
What led you to decide to use our product?
We had evaluated many competing products, and found the following reasons most compelling with your product:
- Better handling of ‘damaged’/malformed files (we see plenty of files that aren’t quite right; your API for validation is fast and helps narrow down what the problem is, to see if we can repair sets of files).
- Speed – both in terms of parsing of EDI, as well as time-to-market. The API was extremely quick to learn and implement within our products.
- Most of the benefit was actually NOT having some mapping tool that forced us to do field-to-field database mapping.
- Application examples, specifically your validator application sample, which helped to start validating files even before implementing your product.
- NET (we’re a pure .NET development group)
How did our product help you to meet your goals?
- First, it allowed us to quickly modernize a consulting service that our firm had provided for years into directly working with 270/271 files. The product was straightforward, and easy to integrate into our infrastructure. It is great that there was no installation aside from the DLL reference, which makes deployment a breeze to our servers.
- We had also had a couple great experiences with support. Once was due to a need for a fix to rules files we had purchased weren’t appropriately parsing some files; we had a quick fix to our rules files and did not experience any costly delays. The second incident was where we had come across files that had so many errors that it wasn’t realistic to analyze them individually. Our feedback on how to handle such invalid files was included in the product and helped reduce a lot of the memory costs during execution that we can have during times where we load in large amounts of data.
- Once integrated in our products, the EDI parsing is rarely changed. This is a testament to how solid the code is – it rarely needs changing, and when it does it’s almost always just due to new functionality being added to our products.