What does an Integrated Rules Professional API response look like?

After the Integrated Rules Professional /validation endpoint successfully evaluates a professional 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": "PRO",
        "formatVersion": "5010"
    },
    "meta": {
        "submitterId": "999898",
        "senderId": "Xxxx.Xxxxxx",
        "billerId": "009998",
        "traceId": "900773a9-c0ba-6aa2-0f61-cfcc30a0200f",
        "applicationMode": "pro"
    }
}

When the validation API encounters issues in the claim evaluation, 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.validIndividualRelationshipCode",
            "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"
        }
    ]
}

Some error listings will also show the EDI loop and element in which the error occurred. 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 Professional claims.

Metadata (for Troubleshooting)

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

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.

{
   "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.

Claim Reference information

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

JSON Response Object Description

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.

{
    "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.