Institutional Claims FAQs
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.
What does a typical Institutional Claims API request look like?
The Institutional Claims Submission API uses the POST HTTPS call. Responses to our Medical Network APIs can be lengthy due to the many data points that a payer or trading partner provides in the query response. This is especially true since institutional claims can have hundreds of line items in the claimInformation object (Loop 2300 in the EDI spec), each of which reflects payer decisions on payment.
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.
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"
}
}
}
}
```
In its header section, the request body supports use of either the tradingPartnerServiceId or the serviceId as the required payer identification.
The submitter object describes the information for the medical institution submitting the transaction. The core claimInformation object follows the provider information. It contains the insurance coding for the claim.
What does a typical Institutional Claims API response look like?
The primary elements of a medical claims submission response consist of the aforementioned meta object and a claimReference object. It contains a number of tracking values. You can expect to see results similar to the following:
```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": {
"submitterId": "999898",
"senderId": "Xxxx.Xxxxxx",
"billerId": "009998",
"traceId": "900773a9-c0ba-6aa2-0f61-cfcc30a0200f",
"applicationMode": "pro"
},
"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.
Institutional Claims API Response Example | Description |
|---|---|
|
|
What do Institutional Claims error responses look like?
If something is wrong with the syntax of the data, you may get a response from our validation endpoint:
```javascript
{
"errors": [
{
"field": "claimInformation.validReleaseInformationCode",
"description": "Allowed Values are: 'I' Informed Consent to Release Medical Information for Conditions or Diagnoses Regulated by Federal Statutes,'Y' Yes, Provider has a Signed Statement Permitting Release of Medical Billing Data Related to a Claim"
}
]
}
```
The error is in the claimInformation object's validReleaseInformationCode attribute. The API also lists out the permissible values that you can apply to correct the error (of course, the chosen value must be correct in the context of the claim).
If the syntax is correct but an error in the format of the claim makes it to the clearinghouse, you may get a response from our Edit engine similar to the following:
```javascript
{
"status": "EDITS",
"controlNumber": "000000001",
"tradingPartnerId": "RANDOM_ID",
"tradingPartnerServiceId": "9496",
"claimReference": {
"correlationId": "200331R999898~1612903439033376",
"submitterId": "009998999898",
"customerClaimNumber": "000000001",
"patientControlNumber": "12345",
"timeOfResponse": "2020-03-31T16:41:00.895-05:00",
"claimType": "INS"
},
"errors": [
{
"field": "03",
"value": "981010000",
"description": "When entered, the Billing Provider Postal Code must be nine numeric characters and valid for the state.\n\nLOOP 2010AA N403",
"location": "2010AA N4"
}
]
}
```
The error reports the X12 loop and segment where the incorrect value occurred. It corresponds to the postalCode attribute in the subscriber object.
Also check Error Messages in Institutional Claims for more information.
NOTE
We recommend using the Validation API before sending the claim request to the payer. Validation rules help prevent claims with incorrect information from being sent to the payer, such as a typo in the NPI, errors in calculations, or poor formatting and syntax in the claim. You can use the Professional Claims API Healthcheck
/institutionalclaims/v1/healthcheckendpoint to check on the operating status of the service endpoint before sending the claim.
How do Institutional Claims work for Medicare?
Medicare payers accept claims only for subscribers. If you want to submit a dependent claim with a Medicare payer, submit the dependent as a subscriber in the claim request.
What are the differences between an Institutional claim and a Professional claim?
- Professional billing typically uses the 837p transaction (or the CMS-1500 form in hard copy)
- Institutional billings use the 837i transaction.
We support both types of electronic claims and transactions. Institutional billing also sometimes encompasses collections while Professional claims and billing typically do not.
Professional billing controls the billing of claims generated for work performed by physicians, suppliers, and other non-institutional providers for both outpatient and inpatient services. One commonality: our APIs help support and automate insurance coding for both Institutional and Professional claims.
What is the claimReference field in the Submission response?
The claimReference field is an object containing the list of identifiers that you and others can use to track an institutional claim. If questions arise about a claim, you can provide the information listed in the claimReference object to Change Healthcare support for troubleshooting purposes. It appears in all Submission responses for claims, Institutional Claims API response. The list of identifiers may differ depending on the context for the response:
```json
{
"status": "SUCCESS",
"controlNumber": "000000001",
"tradingPartnerServiceId": "9496",
"claimReference": {
"correlationId": "201007R999898~49588871937782918",
"submitterId": "009998999898",
"customerClaimNumber": "000000001",
"patientControlNumber": "12345",
"timeOfResponse": "2020-10-07T00:31:07.723-05:00",
"claimType": "INS"
}
}
```
claimReference object fields
The fields in the claimReference object include the following:
Field | Description |
|---|---|
| ID used by support to locate a transaction at the clearinghouse. |
| The customer's combined biller ID and submitter ID. |
| ID set by the customer in the claim. |
| ID set by the customer in the claim for the patient. |
| Timestamp for the response. |
| The type of claim, Professional or Institutional. |
| EDI format version, will always be 5010 for the current version of the 837 claim. |
| Number assigned by the clearinghouse. You use this value to search for the claim in ConnectCenter. |
What is the tradingPartnerServiceId?
This value is also known as the payer ID. For any of our Claims APIs, this will always be an alphanumeric five-digit value, such as "aetna" or "87226" for United Healthcare.
Can we electronically bill Worker's Compensation?
Our APIs can transmit accident and worker's compensation claims.
A provider has two different teams; one enters the claim and the other verifies and submits it. Before submitting, can they enter the claim, save it and have it released when ready?
Our APIs do not have a cache/drafting feature. Customers can develop and automate this feature. Customers should hold the claims on their end, and programmatically set up a console to separate working on claims from submitting them.
Updated 6 days ago