Integrated Rules Institutional FAQs

The Integrated Rules Institutional API is an enabling tool for making complex provider claims more accurate, and more likely to be accepted and adjudicated by the pay.

📘

NOTE

Please see the API FAQs section for tips and solutions to some of the most common questions asked by customers, developer community, and internal staff about the use of the Change Healthcare APIs.

📘

NOTE

The Change Healthcare Integrated Rules Institutional API requires the use of the Institutional Claims API for submission of claims to the payer; or, if you have another workflow for claims submissions, you may use that instead.

How do I submit my edited claims?

The Integrated Rules Institutional API performs advanced rules-based checking and validation of Professional claims based upon the X12 EDI 837i standard. It uses compilations of medical business specialties, called Knowledge Packs, for fine-tuned claim inspection. It does not submit your claim to the payer, and is designed to be complementary to the Professional Claims API /professionalclaims/v3/validation endpoint.

  • You can submit your completed claims to the payer through the standard Institutional Claims Submission API /professionalclaims/v3/validation endpoint (this will incur an additional charge):
  • Use the Standard Professional Claims API /professionalclaims/v3/validation endpoint to check and validate your upcoming submission. It applies a different and simpler set of rules that do not affect or repeat the functions from the Integrated Rules Professional API /institutionalclaims/v3/validation endpoint. Your transaction will not be sent to the payer:

What do Integrated Rules Institutional submissions look like?

The Integrated Rules Institutional API uses the POST request. You simply submit the institutional claim to the Integrated Rules API. It goes to work on your claim data, using the Knowledge Packs you have chosen for your account. It does not submit your claim to the payer. Institutional claims can contain up to 999 service line entries, so using the Integrated Rules API can be very helpful in this context.

Our APIs translate back and forth between JSON and X12 EDI when the information departs into and returns from the medical network. All fields and JSON objects conform to the EDI 837i transaction standard.

Integrated rules institutional submission example

The following example is quite brief compared to what can apply in a real-world transaction.

```javascript
POST https://apigw.changehealthcare.com/medicalnetwork/institutionalclaims/v1/[validation|submission] HTTP/1.1
Host: ${apigee_host}
Authorization:Bearer <Your-Access-Token>
Content-Type: application/json

{
  "controlNumber": "000000001",
  "tradingPartnerServiceId": "9496",
  "submitter" : {
    "organizationName" : "happy doctors group",
    "taxId":"12345",
    "contactInformation": {
      "name": "janetwo doetwo",
      "phoneNumber": "123456789",
      "email": "[email protected]",
      "faxNumber": "123456789"
    }
  },
  "receiver": {
    "organizationName": "EXTRA HEALTHY INSURANCE",
    "taxId":"67890"
  },
  "subscriber" : {
    "memberId": "0000000001",
    "paymentResponsibilityLevelCode": "P",
    "firstName": "johnOne",
    "lastName": "doeOne",
    "gender": "M",
    "dateOfBirth": "19800101",
    "address": {
      "address1": "123 address1",
      "city": "city1",
      "state": "wa",
      "postalCode": "981010000"
    }
  },
  "providers": [{
    "providerType": "BillingProvider",
    "npi": "1760854442",
    "employerId": "123456789",
    "organizationName": "HAPPY DOCTORS GROUPPRACTICE",
    "address": {
      "address1": "123 address1",
      "city": "city1",
      "state": "wa",
      "postalCode": "981010000"
    }
  }],
  "claimInformation" : {
    "claimFilingCode": "CI",
    "patientControlNumber": "12345",
    "claimChargeAmount": "3.75",
    "placeOfServiceCode": "11",
    "claimFrequencyCode": "1",
    "signatureIndicator": "Y",
    "planParticipationCode": "A",
    "releaseInformationCode": "Y",
    "benefitsAssignmentCertificationIndicator": "Y",
    "billingNote":"ADD",
    "claimDateInformation": {
      "statementBeginDate": "20181209",
      "statementEndDate": "20181214",
      "dischargeHour":"1130",
      "admissionDateAndHour": "201810131242"
    },
    "claimCodeInformation": {
      "admissionTypeCode": "1",
      "patientStatusCode": "10",
      "admissionSourceCode": "7"
    },
    "serviceLines":[{
      "assignedNumber": "1",
      "institutionalService": {
        "serviceLineRevenueCode": "1",
        "lineItemChargeAmount":  "72.50",
        "measurementUnit": "UN",
        "serviceUnitCount": "1"
      }
    }],
    "principalDiagnosis": {
      "qualifierCode": "ABK",
      "principalDiagnosisCode": "S93401A",
      "presentOnAdmissionIndicator":  "Y"
    },
    "admittingDiagnosis":{"qualifierCode": "ABJ",
      "admittingDiagnosisCode": "S93401A"
    },
    "otherSubscriberInformation": {
      "paymentResponsibilityLevelCode": "A",
      "individualRelationshipCode": "19",
      "benefitsAssignmentCertificationIndicator": "Y",
      "claimFilingIndicatorCode": "11",
      "releaseOfInformationCode": "Y",
      "otherPayerName":{
        "otherPayerOrganizationName": "ABC Insurance Co",
        "otherPayerIdentifierTypeCode": "PI",
        "otherPayerIdentifier": "11122333"

      },
      "otherSubscriberName": {
        "otherInsuredQualifier": "1",
        "otherInsuredLastName": "DOE",
        "otherInsuredIdentifierTypeCode": "MI",
        "otherInsuredIdentifier": "123456"
      }

    }
  }
}

```

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

After the Integrated Rules Institutional /institutionalclaims/advanced/v1/validation endpoint successfully evaluates an institutional claim, you will get a summary message stating so, with core claim reference information and a Metadata for troubleshooting:

```json
{
    "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:

```json
{
    "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"
        }
    ]
}
```

Claim Reference information

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

JSON Response ObjectDescription
json { "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 does not 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 Change Healthcare 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: Date and time of the response from the clearinghouse.
formatVersion: describes the X12 EDI version to which the claim conforms.
claimType: "PRO" for Professional or "INST" for Institutional.
rhClaimNumber - Unique claim number to track the claim at the Change Healthcare clearinghouse. You can use this value to search for the claim in ConnectCenter and check for updates.
If the Integrated Edits evaluation was successful, it reports an editStatus of "SUCCESS" and the claim will be forwarded to the payer.

Does the Integrated Rules Institutional API have a Submission endpoint?

No, it does not. When you finish evaluating and correcting your claim through the Integrated Rules Institutional API, you can submit your corrected claim through the standard Change Healthcare Institutional Claims API institutionalclaims/v1/submission endpoint or through your accustomed workflow for that task.

The Integrated Rules Institutional API is designed as a complementary product for use with the Change Healthcare Institutional Claims API.

How do Raw-X12 Validation requests and responses work?

See API FAQ.

What is the biggest value-add from using this API?

See API FAQ.

Does your API support HIPAA Validations?

See API FAQ.

If you use a different claim submission workflow, you can also submit your claim that way. Consult your Change Healthcare representative for more information.

What are the differences between an Institutional claim and a Professional claim?

See API FAQ.

What's the difference between this API and the regular Institutional Claims API?

See API FAQ.

Are there guidelines for predicting the rate of unique claims submitted for a practice?

Rates of unique claims are isolated to each individual provider. Every provider is different. Whenever you render a medical service, file a claim.

The Institutional Claims API FAQs topic discusses about many informative items that describe the various features and reasons to use the Institutional Claims API.

How do Raw-X12 Validation requests and responses work?

You can use the Integrated Rules Institutional /raw-x12-validation endpoint to validate your EDI request:

https://sandbox.apigw.changehealthcare.com/medicalnetwork/institutionalclaims/advanced/v1/raw-x12-validation

Your transaction will not be sent to the payer. A sample request appears in EDI format:

```javascript
{"x12": "ISA*00*          *01*CYCTRANS  *ZZ*009998999898   *ZZ*CLAIMSCH       *200723*1401*|*00501*000000001*0*T*:~GS*HC*009998999898*1465*20200723*1401*000000001*X*005010X223A3~ST*837*000000001*005010X223A3~BHT*0019*00*000000001*20200723*1401*CH~NM1*41*2*happy doctors group*****46*009998999898~PER*IC*janetwo doetwo*EM*[email protected]~NM1*40*2*EXTRA HEALTHY INSURANCE*****46*CLAIMSCH~HL*1**20*1~NM1*85*2*HAPPY HOSPITAL CHAIN*****XX*1760854442~N3*123 address1~N4*city1*wa*981010000~REF*EI*123456789~HL*2*1*22*0~SBR*P*18*******CI~NM1*IL*1*doeOne*johnOne****MI*0000000001~N3*123 address1~N4*city1*wa*981010000~DMG*D8*19800101*M~NM1*PR*2*EXTRA HEALTHY INSURANCE*****PI*9496~CLM*12345*3.75***11:A:1**A*Y*Y~DTP*096*TM*1130~DTP*434*RD8*20041209-20041214~DTP*435*DT*200410131242~CL1*1*7*10~NTE*ADD*ADD~HI*BK:99761:::::::Y~HI*BJ:99762~SBR*A*19*******11~OI***Y***Y~NM1*IL*1*DOE*****MI*123456~NM1*PR*2*ABC Insurance Co*****PI*11122333~LX*1~SV2*1**72.50*UN*1~SE*32*000000001~GE*1*000000001~IEA*1*000000001~"}
```

Both JSON and EDI use the same API request model with the same sets of attributes.

Your responses for this API are returned in JSON format, including any errors that the API engine discovers.

📘

NOTE

When your EDI formatted request is corrected and validated, use your normal claim submission workflow to submit the claim. The Institutional Claims v1 API does not directly support the X12 EDI submissions.

Related Topics