API FAQs

This section provides tips and solutions to some of the most commonly questions asked by customers, developer community, and internal staff about the use of the Change Healthcare APIs.

📘

NOTE

Scroll down to the end of this topic to access the links to FAQs for all Change Healthcare API categories.

What information goes in the API request header?

We use two standard HTTP headers in our API requests: Authorization and Content-Type.

The API request uses the following headers as follows:

```javascript
Content-Type: application/json
Authorization: Bearer <Your-Access-Token>
```
  • Content-Type header always defaults to application/json.
  • Bearer authorization token in the Authorization header.
  • Get the authorization token by making an API call, see Generate authorization token.

📘

NOTE

  • For sandbox, the lifespan of a Bearer token is one hour (3600 seconds)
  • For production, the lifespan of a Bearer token is two hours (7200 seconds)

How do I access the Production APIs?

For the Change Healthcare Medical Network API, the production endpoint is:

https://apigw.changehealthcare.com/medicalnetwork/eligibility/v3/

What are the endpoints for getting authorization tokens?

The endpoint for retrieving the authorization token is, /apip/auth/v2/token. For more information, see Security Protocols and their Implementation.

```javascript
curl -X POST \
  '**https://apigw.changehealthcare.com/apip/auth/v2/token/**' \
  -H 'Content-Type: application/json' \
  -d '{
  "client_id": "<Your-ClientId>",
  "client_secret": "<Your-ClientSecret>",
  "grant_type": "client_credentials"
}'
```

How can I check the operating status of the APIs?

Change Healthcare provides a /healthcheck endpoint in all of the API categories (for example, Eligibility, Claims Responses and Reports V2, and so on) to verify that the operating status of the API is optimal and the API is running and is accessible. It is the first thing you can do if something goes wrong. For more information and links to all API categories, see API Healthcheck.

Do you have a sandbox that I can test before signing a contract?

Yes, sign in to the sandbox test environment where you can familiarize yourself with our APIs without signing a contract and without any financial obligation. For more information, see API testing environments. We provide a list of predefined fields and values that you can use for testing a variety of different responses by using HTTP URLs.

Do you bill for a failed claim due to technical error?

Every transaction that makes it to the clearinghouse is billable. All errors at the API level, and some errors at the ingress of the clearinghouse, are considered non-billable.

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.

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.

This topic discusses about many informative items that describe the various features and reasons to use the Change Healthcare Institutional Claims API. Some questions originate with customers or prospective customers; other from Change Healthcare's marketing and sales staff. We hope this section will help answer some of your questions about using this API!

What do Integrated Rules Institutional submissions look like?

The Integrated Rules Institutional API uses the POST HTTPS call. 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.

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"
      }

    }
  }
}

```

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.

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's the difference between the Integrated Rules API and the regular Institutional Claims API?

The standard Institutional Claims API uses a separate set of rules and logic for scrubbing an institutional claim, and is automatically applicable across a range of institutional specialties. The Integrated Rules Institutional API provides greater specialization through the selection of Knowledge Packs to support your provider's medical specialties. It can be considered complementary to the standard Institutional Claims API.

What is the Tracking Number field?

The trackingNumber field is a tracking value that you can use at your discretion. It will accept any value and is not required. It exists so that you can link the 277 response back to your original request, and the payer will always echo this value back exactly as you sent it.

Where do the Control Numbers come from?

The providers and often, Payers originate the Control Numbers (controlNumber) attribute for transactions. Control Numbers must be a nine-digit numeric value.

What file format types does the Attachment Submission API support?

Change Healthcare's Attachment Submissions API supports the following formats for 275 attachments: JPG, TIF, TIFF, PDF, JPEG, and PNG.

Change Healthcare’s attachment solution includes workers’ compensation attachments and medical attachments. Any receiver who does not support electronic attachments will receive the documentation through fax or mail.

Security and Authorization FAQs

Is this API OAuth 2.0 compliant?

Yes. Not all grant types are currently supported, but this API is compliant with the OAuth 2.0 specification, which can be found in the attachments.

What grant types are currently supported?

The platform currently supports the client_credentials grant type.

What if my API includes user context?

Platform tokens are appropriate for system to system communications. For APIs where user context is required, tokens should be issued by and retrieved from the CIAM system. The API Marketplace supports tokens issued by either of these identity providers.

What is the difference between version 1 and version 2 APIs?

  • Version 2 is more fully compliant with the expectations outlined in the OAuth 2.0 specification. This is backwards-compatible to support the migration of Version 1 clients. The token name usage in this version is access_token.
  • Version 1 of this API was designed to facilitate the migration of legacy APIs onto the platform. Version 1 should not be used for new implementations. The token name usage in this version was accessToken.

Did this page help you?