Key Features and Benefits of Our EDI Converters
We offer two modes for converting EDI files: API (our API back-end can be installed locally as a Docker container) and the command-line tool. Both options produce the same output (except for code descriptions); it is up to you to decide which one you want to employ.
We also offer a Java parser that can be embedded directly into any Java application.
You can convert your EDI files to JSON or a denormalized CSV file.
More details about the API and the schema are available here.
When installed on-prem, there is no limit on the number of API calls or the number of conversions.
Well-Designed Object Model
The converter produces a user-friendly object model (schema) expressed in JSON.
The root of the model is a Claim object (for 837) and a Payment object (for 835). There are no loops or segments to deal with. All segments and elements are mapped to appropriate fields.
See this post for more details. To see more examples of the output, go to our demo app, click on any claim or payment, and select “Export” and then “JSON.”
Each claim/payment contains information about its EDI transaction, the billing provider, the payer, the patient, etc. You don’t need to implement nested loops to extract key data elements from the response.
This also makes it easier to use the output for analytics.
The model greatly simplifies the loop structure of X12 EDI. For example, a claim loop can be nested under the patient or under the subscriber. The converter always returns a claim object with the subscriber and patient fields properly populated. Most other parsers require implementing this “IF” logic in the client.
All people and organizations (providers, payers, patients) are converted to the OrgPerson object. The same object is used for N1 (835) and NM1 segments. Services are always mapped to the ServiceLine object. The same object structure is used across all EDI transactions. E.g., the same object represents a payer from 835 and a payer from 837, even though the segments and elements are different at the EDI level.
The consistent use of reusable objects makes it easy to consume the JSON output and implement reusable components on the client’s side.
The model loosely follows the design of the HL7 FHIR claim resource.
Qualifiers as Constants
All qualifiers are translated into user-friendly constants. For example, instead of encoding the translation of “85” to the billing provider in your app, you’d get “entityRole”: “BILLING_PROVIDER” in JSON.
The raw codes are available when needed.
Code Descriptions
All codes are accompanied by up-to-date descriptions from CPT, ICD, CARC/RARC, and UB code sets. The descriptions can be optionally suppressed in the API.
Alternatively, you can use our code lookup API.
This saves you time from managing your code tables.
Note: the CLI tool currently does not populate code descriptions.
Unlimited File Size and Transaction Size
The converter (the CLI and the API server) can handle files of any size.
More importantly, it can handle 837 and 835 transactions of any size. Large providers can batch thousands of claims in the same EDI transaction. Many EDI parsers parse by transaction, which fails for large transactions. Our parser converts individual claims (CLM segment)/payments (CLP segment) within a transaction, so the transaction size is irrelevant.
The converter’s output is streamed to the client once a batch of claims/payments is parsed. You don’t need to deal with pagination or webhooks, simply stream the input and get the output as it becomes available.
We support line-delimited JSON to make streaming more efficient, although a well-formed JSON can also be produced. In the latter case, you will need to implement the logic in your code to parse large JSON arrays.
You can use multipart requests to convert multiple files at once, e.g.,:
For example:
curl -F files=@"../edi_files/837/837p-1.dat" -F files=@"../edi_files/837/837p-1.dat" ${API_URL}/edi/json/upload?splitTran=true&ndjson=true
You will get the response with a single stream of objects from all uploaded files.
We have more examples in our GitHub repo.
CSV Output Customizations
We provide several options for the CSV output. By default, the API and the CLI converter produce a single file with denormalized claim and service line level columns.
You can also request two separate files, one for claim-level data and another one for line-level data.
By default, CSV contains all the fields from 835/837. You can provide a list of fields to exclude if you’re only interested in a specific subset of fields.
Scalability (On-Prem)
Our API back-end has a small footprint and can run on 1.5GB of RAM. Currently, our distribution requires a database, but no data is saved to the database, so you don’t need to worry about maintaining or scaling it. We will get rid of the database dependency in future releases.
You can scale the API back-end by adding docker containers behind a load balancer; no additional configuration is necessary.
Data Privacy
The converter does not send data outside your network, does not contact our servers, and can run entirely offline.