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 health care and insurance industry. These standards are widely adopted across providers, payers, and technology vendors such as Change Healthcare. We intend these TR3s and the X12 metadata contained in them to be used in conjunction with Change Healthcare’s 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. To obtain a license that also provides access to the full requirements for these transactions, you can visit https://x12.org/licensing. We make every effort to ensure consistency between Change Healthcare’s 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 (Swagger) 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, Change Healthcare 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 various Change Healthcare JSON-to-EDI API contents, use the links in the following table.

API

Note

Eligibility JSON-to-EDI-API Contents

The Consolidated 270/271 Implementation Guide, p. 54 discusses this in further detail.

Professional Claims JSON-to-EDI Contents

The Consolidated 837p Implementation Guide, p. 53-54, discusses this in further detail.

Institutional Claims API JSON-to-EDI Contents

The Consolidated 837i Implementation Guide, p. 53 discusses this in further detail.

Integrated Rules Professional JSON-to-EDI Contents

The Consolidated 837p Implementation Guide, p. 53-54, discusses this in further detail.

Integrated Rules Institutional Claims JSON-to-EDI Contents

The Consolidated 837i Implementation Guide, p. 53 discusses this in further detail.

Claim Status JSON-to-EDI Contents

The Consolidated 276/277 Implementation Guide, p. 26 discusses this in further detail.

Attachment Submissions API JSON-to-EDI Contents

The X12 EDI loop associated with each field in the 275 request.


Did this page help you?