EDI Converter 2.15.1 Release: EDI Generation, Validation, Python SDK, and More

July 15, 2026

We’re pleased to announce version 2.15.1 of our EDI Converter.

This is a major release that adds EDI generation for 835, 837P, and 837I transactions, production-ready EDI validation, a new Python SDK, updated Java parsing and generation APIs, optional control-segment and transaction-level JSON objects, expanded model support, Homebrew installation for macOS, and updated dependencies with zero reported CVEs.

You can view all model changes in GitHub diff format.

Scroll down to openapi/components/schemas/model to review the schema changes.

EDI Generation

The EDI Converter can now generate X12 EDI from the same business-friendly object model used for EDI-to-JSON conversion. Generation is supported for 835 payment transactions, 837P professional claims, and 837I institutional claims.

Submit a JSON request to the appropriate endpoint and receive the generated EDI as plain text. You can also validate a request before generating the EDI or set failOnValidationErrors=true to stop generation when validation errors are found.

For example, generate an 835 transaction from a JSON request:

curl -H "Content-Type: application/json" \
  --data-binary @edi_gen/request/835-minimal.json \
  "$SERVER_URL/api/edi/gen/835"

See the EDI Generation API documentation for request structures, 835 and 837 examples, validation options, and Python examples.

Python SDK

The new ediconvert-sdk package provides a typed Python interface for the complete EDI Converter API. Its EdiConverterClient groups operations under conversion, generation, validation, and about, while the included edi_model package provides Pydantic models for claims, payments, member coverage, generation requests, validation issues, and supporting objects.

Install the SDK from PyPI and use it with a local or public EDI Converter API:

python -m pip install ediconvert-sdk

from ediconvert_sdk import EdiConverterClient

with EdiConverterClient("http://localhost:5080/api") as client:
    response = client.conversion.to_json_file(
        "claim.edi",
        ndjson=True,
        validate=True,
    )

    for line in response.iter_lines():
        print(line.decode("utf-8"))

See the Python SDK reference for client configuration, typed model usage, endpoint methods, and error handling.

EDI Validation

First introduced in the 2.15.0 beta, EDI validation is now part of the 2.15.1 release. The converter supports SNIP Levels 1, 2, 3, and 5, covering envelope structure, HIPAA implementation guide syntax, balancing, and external healthcare code sets.

You can validate while converting by setting validate=true on /api/edi/json, or call /api/edi/validate to return only structured validation issues. Each issue identifies the affected loop, segment, element, value, source location, and a human-readable message. The /api/edi/validate/text endpoint returns annotated EDI with issues directly beneath the affected segments.

For example, validate an EDI file without returning converted business objects:

curl -H "Content-Type: text/plain" \
  --data-binary @edi_files/837/837P-validation-issues.edi \
  "$SERVER_URL/api/edi/validate"

Read the 2.15.0-beta announcement for examples and a detailed overview of the validation features.

Control Segments Parsing (JSON)

The JSON conversion API can now return structured objects for the X12 interchange and functional-group control segments. Set convertControlSegments=true on /api/edi/json to include INTERCHANGE_CONTROL and FUNCTIONAL_GROUP objects in the same output stream as claims, payments, members, and other business objects.

The same feature is available across all EDI Converter deployments:

For the CLI tool, use the --out-control-segments option.
For AWS Lambda, set isSerializeControlSegments to true in the request.
To enable control-segment output by default, set EDI_CONVERT_CONTROL_SEGMENTS=true. This environment variable is supported by the Docker image, the CLI tool, and AWS Lambda.

For example:

[
   {
      "id": "6a41a2f8eeb7b2414b3a30c7",
      "objectType": "INTERCHANGE_CONTROL",
      "elementSeparator": "*",
      "segmentTerminator": "~",
      "authorizationInformationQualifier": "00",
      "authorizationInformation": "          ",
      ...
      "acknowledgmentRequested": "0",
      "interchangeUsageIndicator": "P",
      "componentElementSeparator": ":",
      "fileInfo": {
         "name": "835-minimal.dat",
         "url": "file:/edi-samples/edi_files/835/835-minimal.dat",
         "lastModifiedDateTime": "2026-06-27T09:24:51.832-04:00"
      }
   },
   {
      "id": "6a41a2f8eeb7b2414b3a30c9",
      "objectType": "FUNCTIONAL_GROUP",
      "functionalIdentifierCode": "HP",
      "senderCode": "SENDER CODE",
      "receiverCode": "RECEIVER CODE",
      "date": "2024-12-25",
      "time": "05:33:00",
      "controlNumber": 225426820,
      "responsibleAgencyCode": "X",
      "version": "005010X221A1"
   }
]

Use the objectType field to distinguish control objects from business objects. See the control-segment documentation for the full response structure and usage details.

Transaction as a Top-level Object (JSON)

By default, transaction-level information is repeated within every claim, payment, or member object. Set transactionsTopLevel=true on the API request to return each transaction once as a separate TRANSACTION object.

You can enable the same output structure in every deployment mode:

For the CLI tool, use the --transaction-top-level option.
For AWS Lambda, set isTransactionTopLevel to true in the request.
To make top-level transaction objects the default, set EDI_TRANSACTION_TOP_LEVEL=true. This environment variable is supported by the Docker image, the CLI tool, and AWS Lambda.

The transaction appears before its business objects in the response, and each claim, payment, or member links back to it through transactionId:

[
  {
    "id": "6a41a2f8eeb7b2414b3a30ca",
    "objectType": "TRANSACTION",
    "transactionType": "PAYMENT"
  },
  {
    "objectType": "PAYMENT",
    "transactionId": "6a41a2f8eeb7b2414b3a30ca",
    "patientControlNumber": "5554555444"
  }
]

This option can substantially reduce the size of JSON responses. See the transaction-object documentation for configuration and processing details.

New JSON Objects and Fields

Remittance Delivery Method Object (`RDM` Segment, 835)

We’ve added a remittanceDeliveryMethod object to the 835 transaction schema to represent the RDM segment.

Example:

"remittanceDeliveryMethod": {
  "reportTransmissionCode": "BM",
  "transmissionType": "BY_MAIL",
  "name": "Name",
  "communicationNumber": "9618215141"
}

See the Remittance Delivery Method object schema for field definitions and EDI mappings.

Multiple Healthcare Policy Identifiers (835)

Service lines can now contain multiple healthcare policy identifiers from REF segments with the 0K qualifier. The identifiers are represented as an array of strings; previously, the ServiceLine object supported only one healthcare policy identifier.

Multiple Referral and Prior Authorization Numbers (837P and 837D)

Service lines can now contain multiple referral numbers and prior authorization numbers from REF segments with the 9F and G1 qualifiers. Both fields are represented as arrays of strings; previously, the ServiceLine object supported only one value of each type.

New Enums for X12 Codes

We’ve added enums that provide readable string constants alongside several X12 code fields:

The Attachment object now includes a type enum for reportTypeCode and a transmissionType enum for transmissionTypeCode.
The Claim object now includes a delayReasonType enum for delayReasonCode and a specialProgramType enum for specialProgramCode.
The RelatedCauseInfo object now includes a relatedCauseType enum for relatedCauseCode.

Codeset Updates

The Docker image now includes the latest HCPCS, NDC, and ICD-10-PCS codes.

We’ve also added complete support for Place of Service codes, including code descriptions in converter output.

CLI Updates

The CLI tool now includes new validation and JSON-output options:

--validate validates EDI files during conversion. Validation messages are logged and, for JSON or JSONL output, included as VALIDATION objects. Set EDI_VALIDATE=true to enable validation by default.
--validate-out-edi validates EDI without converting it. When you specify an output directory, the converter creates a copy of the source EDI with each validation message prefixed by !! directly beneath the segment that failed validation.
--transaction-top-level writes each EDI transaction as a separate top-level TRANSACTION object instead of repeating transaction data in every claim, payment, or member object. This can substantially reduce JSON and JSONL output size. Set EDI_TRANSACTION_TOP_LEVEL=true to enable this behavior by default.
--out-control-segments writes the ISA interchange and GS functional group control segments as JSON objects. Set EDI_CONVERT_CONTROL_SEGMENTS=true to enable control-segment output by default.

On macOS, you can now install the EDI Converter CLI with the Homebrew package manager:

brew install healthcare-data-insight/tap/edi-converter

See the CLI option reference for the complete command syntax and all available options.

EDI Parser for Java Updates

The EDI Parser for Java now provides one consistent parsing pattern across supported transaction types. Create an EdiParser, optionally enable validation, and call parse(chunkSize) in a loop. For each chunk, iterate over EdiParsingResults.rootObjs() to process envelope objects, transaction metadata, business objects, and validation issues in the same order in which they appear in the EDI file. Continue until isDone() returns true.

try (var parser = new EdiParser(ediFile)) {
    EdiParsingResults results;
    do {
        results = parser.parse(20);
        for (var rootObj : results.rootObjs()) {
            process(rootObj);
        }
    } while (!results.isDone());
}

This pattern works with Claim objects for 837, Payment and ProviderAdjustment objects for 835, MemberCoverage objects for 834, and status objects for 277CA. When source order is not important, typed collections such as claims(), payments(), and memberCoverages() provide direct access to a specific object type. The older transaction-specific parse837(int) and parse835(int) methods are deprecated.

See the Java EDI parsing guide for the complete parsing flow and transaction-specific examples.

The library can also generate 835, 837P, and 837I EDI directly from Java business objects. Use EdiWriter to write the interchange, functional group, transaction, and claims or payments in order. The writer returns validation issues as it writes each object and adds the required closing segments when it is closed.

Parsing and generation use the same object model, so applications can parse existing EDI, update its Claim, Payment, ServiceLine, and related objects, and write the modified data back to EDI without converting through JSON or making an HTTP request.

See the Java EDI generation guide for EdiWriter examples, validation guidance, and a complete parse-modify-generate workflow.

Public API

You can now evaluate EDI conversion, generation, and validation without installing the Docker container or the CLI tool locally. Request a trial license key, pass it in the X-Api-Key header, and use the same API request formats supported by a local installation.

For example, convert a de-identified EDI sample to JSON:

curl -H "Content-Type: text/plain" \
  -H "X-Api-Key: $API_KEY" \
  --data-binary @edi_files/837/837P-minimal.dat \
  "https://datainsight.health/clinsight/api/edi/json"

The public API is intended for evaluation with de-identified sample files. Do not submit PHI, personally identifiable information, or production healthcare data. For production workloads, install the API server inside your own network.

See the public EDI Converter API announcement for setup instructions and conversion, generation, and validation examples.

Addressing Security Vulnerabilities

We’ve updated all third-party libraries used by the EDI Converter to their latest available versions. This keeps the converter current with upstream security fixes and reduces the risk of carrying stale dependencies into production deployments.

The previous dependency set included several critical and high-severity CVEs. This release addresses those vulnerabilities, and the current security scan reports zero CVEs for the EDI Converter image.

You can find the latest security reports and SBOM at the following links:

How to Upgrade

API Docker Container

Pull the 2.15.1 image:

docker pull myarch/ediconvert:2.15.1

If you use Docker Compose, update the image tag to myarch/ediconvert:2.15.1 and run docker compose pull.

Note that we’ve switched to using the Docker Hub for our images.

The old Docker repository repo.datainsight.health will remain available for all previous releases.

Python SDK

Install or upgrade to the matching SDK release:

python -m pip install --upgrade ediconvert-sdk==2.15.1

EDI Parser for Java

Update your Gradle or Maven dependency:

implementation "hdi:edi:2.15.1"

AWS Lambda Function

Update the Lambda deployment from our S3 bucket:

aws lambda update-function-code --function-name <your-function-name> \
  --s3-bucket ediconverter \
  --s3-key ediconvert-lambda-2.15.1.zip

CLI Tool

On macOS:

Run brew upgrade healthcare-data-insight/tap/edi-converter if the CLI is already installed, or brew install healthcare-data-insight/tap/edi-converter for a new installation.
Keep your license file in the ~/.ediconvert folder.
Run ediconvert -V and verify that the output includes ediconvert 2.15.1.

On all other platforms:

Download the new version.
Unzip the archive and replace your existing installation files, including the lib and conf folders.
Do not delete your license file.
Run ediconvert -V and verify that the output includes ediconvert 2.15.1.

EDI Converter 2.15.1 Release: EDI Generation, Validation, Python SDK, and More

EDI Generation

Python SDK

EDI Validation

Control Segments Parsing (JSON)

Transaction as a Top-level Object (JSON)

New JSON Objects and Fields

Remittance Delivery Method Object (RDM Segment, 835)

Multiple Healthcare Policy Identifiers (835)

Multiple Referral and Prior Authorization Numbers (837P and 837D)

New Enums for X12 Codes

Codeset Updates

CLI Updates

EDI Parser for Java Updates

Public API

Addressing Security Vulnerabilities

How to Upgrade

API Docker Container

Python SDK

EDI Parser for Java

AWS Lambda Function

CLI Tool

Remittance Delivery Method Object (`RDM` Segment, 835)