How can I use X12 EDI as the coding for my API request?

NOTE: Before using the claimstatus /Raw-X12 endpoint, contact your Change Healthcare implementation analyst. Our Raw-X12 service requires custom headers with credentials, and other information specific to each customer's contracted Payer List relationships that you will need to obtain from your analyst contact.

The Claims Status Raw-X12 endpoint supports the X12 EDI standard if you choose to implement the 276 transaction set in its native EDI format. The 277 transaction responses you receive will also appear in EDI format.

We support a traditional X12 EDI request if you choose to implement the 276 transaction set in its native EDI format. The 277 transaction responses you receive will also appear in EDI format.

The Claims Status Raw-X12 endpoint is as follows:

An X12 EDI 276 Claim Status request appears similar to the following:

EDI 276 Request Description
POST ${api_basepath}/raw-x12 HTTP/1.1
Host: ${apigee_host}
Authorization: Bearer <Your-Access-Token>
Content-Type: application/json
    "x12": "ISA*00*..........*01*password  *ZZ*something*
0123456789~HL*3*2*19*1~NM1*1P*2*happy doctors group*****

A few notes about this example: In the X12 transmission payload, the ISA, GS and ST control segments are used as envelopes to encapsulate the medical transaction data and confidentially manage its transmission. The GS header ends with the Version ID code (005010X212), which describes the EDI standard used in the transaction. The ST header states the type of medical transaction, which is 276 in this example (Claim Status submission). When the envelope headers are complete, the Beginning of Hierarchical Transaction (BHT) field shows the start of the data that forms the Claim Status medical transaction. The end of the claim status request body carries the TRN (Claim Tracking Number) and REF (Payer Claim Control Number) segments.

The transaction example contains five HL segments. The first field of each HL segment identifies its position in the hierarchical levels in the claim. Here is the simple segment list shown in the example:

  • HL 1 - Information Source (essentially, the payer - Loop 2000A)
  • HL 2 - Information Receiver (the submitter of the inquiry - Loop 2000B)
  • HL 3 - Service Provider (the provider delivering or organizing the care - Loop 2000C)
  • HL 4 - Subscriber (the holder of the insurance policy - Loop 2000D)
  • HL 5 - Dependent (if necessary, the other member of the family needing care - Loop 2000E)

This sequence will change based on different claim factors. See pages 8-10 of the ASC X12 276/277 Implementation Guide for details.

An NM1 segment follows each HL segment in the request body. It separately describes each of these five entities in our example. Demographic information (DMG) follows for the subscriber and dependent records. The 276 submission requires all of this information to help ensure the payer/information source can locate the claim and send an informative response.

The TRN segment is required when the patient has their own policy ID number (the subscriber, or a dependent that has a unique policy ID).

The REF (Reference Information) segment appears whenever the information receiver knows the specific payer-assigned claim number, and is inquiring about that claim. The REF segment takes several different forms depending on the type of claim, but is always defined as the Claim Status Tracking Number. See pages 59-65 of the ASC X12 276/277 Implementation Guide to find out more details about how this works.

Ensuring Integrity of X12 Transmissions

When you create and send your X12 content through our API, ensure that the final field in the ISA header, ISA16, contains the colon character (":"). ISA16 is a single-character field that defines the component element separator in the ISA header. For your X12 EDI transactions to work in your contracted APIs you must use the colon character in this field. It should be used only in ISA16 and not for any other X12 header or trailer. See Appendix C of the ASC X12 276/277 Implementation Guide for more information about the Claim Status transaction structure.

The X12 EDI 277 response for this example is the following:

EDI 277 Response Description
POST ${api_basepath}/raw-x12 HTTP/1.1
Host: ${apigee_host}
Authorization: Bearer <Your-Access-Token>
Content-Type: application/json
"x12": "ISA*00*.........*01*SomePwd*ZZ*EMDEON.........*
HL*3*2*19*1~NM1*1P*2*happy doctors group*****XX*1760854442~

Core claim information consists of the STC segments, which vary by loop based on the entities receiving the status information: Information Receiver status information; Provider status information; Claim Level status information; and Service Line status information. Claim Level status information and service line status information can include monetary amounts. The second and third STC segments in the response above show monetary amounts of $184.05 and $219. Responses may or may not provide monetary amounts, based on the current claim status. Also, payers may or may not support service line reporting. See page 138 of the ASC X12 276/277 Implementation Guide for Claim Level Status Information and page 160 for Service Lines Status Information.

Zooming in on the STC Codes

The first element of all STC segments, STC01, is named Health care status claim. Field STC01 is a composite field that holds several code values. Consider the following snippet:


This is the first part of the substantial STC segment. In a composite field, the colon (:) is used as a separator to isolate each coding value. It's another use of the composite element delimiter.

  • The first sub-field, (F1), is the Health Care Claim Status Category code. Here, the code indicates the claim or service line item is Finalized and Paid (Finalized/Paid). This list is publicly available and is not published in the Implementation Guide;
  • The second sub-field, (65), is the Claim Status Code. This code is added by the adjudication authority. The value shown also indicates the claim item is Paid. This list is publicly available and is not published in the Implementation Guide;
  • The third sub-field (1E) is the entity identifier. Here, it shows that the payment is coming from an HMO. The code defines the context for the previous two values, and comes from a substantial code list (see page 161-167 of the ASC X12 276/277 Implementation Guide).

Did this page help you?