JSON-to-EDI API Mapping

X12 is a non-profit organization chartered by the American National Standards Institute (ANSI) to develop and maintain business-to-business transaction standards. Several of the X12 Implementation Guides (X12 Type 3 Technical Report (TR3), also known as an X12 Implementation Guide (IG)) have been adopted under HIPAA for use by covered entities in the healthcare and insurance industry. These standards are widely adopted across providers, payers, and technology vendors, such as Optum. We intend these TR3s and the X12 metadata contained in them to be used in conjunction with our APIs, so your organization can access the reference industry standards that include the codes and rules necessary to submit Eligibility, Claims, and Claim Status transactions.

📘

NOTE

To obtain a license that also provides access to the full requirements for these transactions, visit https://x12.org/licensing. We make every effort to ensure consistency between our APIs and the X12 TR3. If there is a discrepancy, the X12 TR3 is the final authority.

How to use this document

IMPORTANT

Use our OpenAPI Spec JSON file as a reference for development. Notes on the data in the following sections include:

• The Constraints column describes the minimum and maximum number of alphanumeric characters that a field entry can occupy: for example, 1/60 R is a Required field with a minimum of one and maximum of 60 characters.
• If a field is required, the Constraints entry notes it.

For the Constraints column in each table, the following letters stand for specific meanings:

• R = Required (must be used if/when the object is part of the transaction). For example, if umClearingHouseId is empty, payerId value will also be used to populate ISA08 GS03. All of the fields marked as R are not required to be filled in; only one of the fields marked as R is required. That is, if you have provided the payerId, the remaining fields are not mandatory.
• If the segment is not included, none of its fields matter—even if they’re labeled “Required.”
  If the segment is included, all fields marked “Required” inside that segment must be present.

Situational loops, segments, or elements can be Situational in two forms:

• S = Situational (may be required depending on how the transaction content is structured).
• Required IF a condition is met, but can be used at the discretion of the sender if it is not required (that is, if you have provided the payerId, the remaining fields are not mandatory, some descriptive notes can be added to a claim if necessary).
• Required IF a condition is met, but if not, the sender must not use it in the request ("Do not send").

📘

NOTE

To obtain a license that also provides access to the full requirements for these transactions, visit https://x12.org/licensing. We make every effort to ensure consistency between our APIs and the X12 TR3. If there is a discrepancy, the X12 TR3 is the final authority.

📘

NOTE

While we make every effort to keep all information up to date and accurate, Optum makes no warranties, express or implied, about completeness, accuracy, reliability, or availability regarding the content, images, services or hyperlinks in our documentation. We provide this information as a service to our customers; your use of this information is entirely your responsibility.

JSON-to-EDI API Contents

For the respective JSON-to-EDI API contents, click the links in the following table.

Eligibility JSON-to-EDI API mapping change log