JSON-to-EDI API Mapping

Preface

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

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);
  • S = Situational (may be required depending on how the transaction content is structured).

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

  • Required IF a condition is met, but can be used at the discretion of the sender if it is not required (for example, 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 their request ("Do not send").

📘

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.

APINote
Eligibility JSON-to-EDI-API ContentsThe Consolidated 270/271 Implementation Guide, p. 54 discusses this in further detail.
Professional Claims JSON-to-EDI ContentsThe Consolidated 837p Implementation Guide, p. 53-54, discusses this in further detail.
Institutional Claims API JSON-to-EDI ContentsThe Consolidated 837i Implementation Guide, p. 53 discusses this in further detail.
Integrated Rules Professional JSON-to-EDI ContentsThe Consolidated 837p Implementation Guide, p. 53-54, discusses this in further detail.
Integrated Rules Institutional Claims JSON-to-EDI ContentsThe Consolidated 837i Implementation Guide, p. 53 discusses this in further detail.
Claim Status JSON-to-EDI ContentsThe Consolidated 276/277 Implementation Guide, p. 26 discusses this in further detail.
Attachment Submissions API JSON-to-EDI ContentsThe X12 EDI loop associated with each field in the 275 request.
Attachments Retrieval API JSON-to-EDI ContentsThe Consolidated 270/271 Implementation Guide discusses this in further detail.

Eligibility JSON-to-EDI API Mapping change log