EDI Conversion and Parsing API Release Notes

Release 2.10.1

We’ve fixed an issue related to error handling in the API. Now the API correctly returns error information even if it was encountered in the middle of a large file.

It also returns response status “400” in case of EDI parsing errors.

We now also support running EDI API server without Docker.

The distribution now includes a local version of the EDI Viewer without the limitations on the number of claims.

Release 2.10

You can now run our EDI API server as a single docker container without MongoDB dependency.

We also updated our API documentation and usage examples.

Release 2.8

New Conversion API

We now offer a new API endpoint for converting EDI 837/835 transactions to JSON or to CSV. This API is highly scalable and can convert files and transactions of any size.

The output is streamed to the client as the input is parsed. The API supports line-delimited JSON (ndjson), which is more suitable for streaming than the traditional JSON array of objects. The well-formed JSON is supported as well.

The API returns an array of claim or payment objects.

You can post the content of your EDI file to the API or upload multiple files using multipart request:

curl -F files=@"../edi_files/837/prof-encounter.dat" -F files=@"../edi_files/837/anesthesia.dat" "${API_URL}/edi/json/upload?splitTran=true"

Or see our Python example.

The old “parse” API is still fully operational; please keep in mind that it runs entirely in-memory and can only handle smaller files.

Other Changes

  • Each claim, payment and transaction now have a unique ID.
  • New objectType field to distinguish between claims and payments (if you’re converting 837 and 835 files during the same request)
  • New drg field on the claim object
  • New drg (CLP11) and drgWeight (CLP12) fields on the payment object
  • New dischargeFraction (CLP13) field on the payment object
  • Added diagPointers array to the ServiceLine object
  • Added drug (NDC code) to the ServiceLine object for payments.
  • We got rid of the generated identifiers for patient objects. When both subscriber and patient (dependent) are present on a claim, the patient does not have its own identifier. We previously generated this identifier by concatenating the subscriber identifier and the relationship type.
  • The order of fields was re-arranged to be more closely aligned with the 837/835 standard. The transaction information now appears at the end of claim/payment objects.