What does a typical Integrated Rules Institutional API response look like?

After the Integrated Rules Institutional /validation endpoint successfully evaluates an institutional claim, you'll get a summary message stating so, with core claim reference information (see field explanations here) and a Metadata object for troubleshooting:

{
    "status": "SUCCESS",
    "controlNumber": "000000001",
    "tradingPartnerServiceId": "9496",
    "claimReference": {
        "correlationId": "200925R639534~847432178458572",
        "submitterId": "395795639534",
        "customerClaimNumber": "000000001",
        "patientControlNumber": "12345",
        "timeOfResponse": "2020-09-25T18:13:48.136-05:00",
        "claimType": "INS",
        "formatVersion": "5010"
    },
    "meta": {
        "submitterId": "999898",
        "senderId": "Xxxx.Xxxxxx",
        "billerId": "009998",
        "traceId": "900773a9-c0ba-6aa2-0f61-cfcc30a0200f",
        "applicationMode": "pro"
    }
}

When the validation API encounters issues, it will list each in the reply:

{
    "status": "EDITS",
    "controlNumber": "000000001",
    "tradingPartnerServiceId": "9496",
    "claimReference": {
        "correlationId": "201117R999898~53196482361992277",
        "submitterId": "009998999898",
        "customerClaimNumber": "000000001",
        "patientControlNumber": "12345",
        "timeOfResponse": "2020-11-17T17:46:02.792-06:00",
        "claimType": "INS"
        "formatVersion": "5010"
    },
    "errors": [
        {
            "field": "01",
            "value": "1",
            "description": "The Type of Admission is required and must be valid.\n\nLOOP 2300 CL101",
            "location": "2300 CL1"
        },
        {
            "field": "claimInformation.otherSubscriberInformation.IndividualRelationshipCode",
            "description": "Allowed Values are: '01' Spouse, '18' Self, '19' Child, '20' Employee, '21' Unknown, '39' Organ Donor, '40' Cadaver Donor, '53' Life Partner, 'G8' Other Relationship"
        }
    ]
}

Most error listings will also show the EDI loop and element in which the error occurred. The example here shows that the admissionTypeCode in Loop 2300, Element CL101, has an incorrect value and must contain one of the values specified in the correction text. For more information, see Error messages in Institutional claims.

Change Healthcare Medical Network APIs support a significant troubleshooting feature called metadata. API users do not need to enable this capability; it is automatic and has no effect on information in any medical transaction. If you encounter any issues with a transaction and need to work with CHC technical support, give the values provided in the meta object to the CHC representative.


JSON Response Object Description
{
   "meta": {
       "submitterId": "999898",
       "senderId": "Xxxx.Xxxxxx",
       "billerId": "009998",
       "traceId": "900773a9-c0ba-6aa2-0f61-cfcc30a0200f",
       "applicationMode": "prod"
   },













Give this entire object to CHC
support for troubleshooting. All
values in the meta object are
automatically taken from the
API request header or from the
secure token.
If they appear, consider the IDs in
the metadata object as a hierarchy
from less specific to most specific:
submitterId as least specific, as the
entity from which the request came;
the senderId denoting the API
customer; and billerId as the
customer medical department that
is responsible for the billing.
ApplicationMode describes the
operating environment,
which for API customers will
either be Production ("prod") or
Sandbox.

The claimReference object contains a number of tracking values. You can expect to see results similar to the following:

JSON Response Object Description
{
    "status": "SUCCESS",
    "controlNumber": "000000001",
    "tradingPartnerServiceId": "9496",
    "claimReference": {
        "correlationId": "210322R999898~66684261175841",
        "submitterId": "009998",
        "customerClaimNumber": "000000001",
        "patientControlNumber": "12345",
        "timeOfResponse": "2021-03-22T19:34:08.85-05:00",
        "claimType": "PRO",
        "formatVersion": "5010",
        "rhclaimNumber": "2108151508527"
    },
    [meta object here]
    },
    "editStatus": "SUCCESS",
    "payer": {
        "payerName": "Unknown",
        "payerID": "9496"
    },















The first response you get back from the
clearinghouse doesn't indicate whether
the claim is being paid; it indicates that the
clearinghouse has accepted the claim and is
getting ready to forward it to the payer.

claimReference is the response's main object.
Key values include the following:

  • customerClaimNumber - An additional claim
    tracking number assigned by the CHC
    clearinghouse.
  • submitterId - Describes the entity that
    submitted the claim. Value is in
    Loop 1000A, element NM109.
  • patientControlNumber - echoes the Patient
    controlNumber back from the
    original request.
  • timeOfResponse - the date and time of the
    response from the clearinghouse.
  • formatVersion - describes the X12 EDI version
    to which the claim conforms.
  • claimType - will be "PRO" for Professional
    or "INST" for Institutional.
  • rhClaimNumber - unique claim number to track
    the claim at the CHC clearinghouse.
    You can use this value to search for
    the claim in ConnectCenter and check
    for updates
    .
  • If the Integrated Edits evaluation is successful, it reports an editStatus of "SUCCESS" and the claim will be forwarded to the payer.

Did this page help you?