General FAQs

This section provides 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.



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

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 header format:

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 a Generate authorization token request



The lifespan of a Bearer token is one hour (3600 seconds) for both sandbox and production environments.

What are the endpoints for getting authorization tokens?

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

curl -X POST \
  '****' \
  -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 for all of the APIs (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 API 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. See Institutional Claims API FAQs for more information about using this API!

What do Integrated Rules Institutional submissions look like?

The Integrated Rules Institutional API uses the POST request. Simply submit the institutional claim to the Integrated Rules API. It works 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.

Integrated Rules Institutional submissions example

POST[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",
    "contactInformation": {
      "name": "janetwo doetwo",
      "phoneNumber": "123456789",
      "email": "[email protected]",
      "faxNumber": "123456789"
  "receiver": {
    "organizationName": "EXTRA HEALTHY INSURANCE",
  "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",
    "claimDateInformation": {
      "statementBeginDate": "20181209",
      "statementEndDate": "20181214",
      "admissionDateAndHour": "201810131242"
    "claimCodeInformation": {
      "admissionTypeCode": "1",
      "patientStatusCode": "10",
      "admissionSourceCode": "7"
      "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",
        "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:

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

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



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 these 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, this API is compliant with the OAuth 2.0 specification, which can be found in the attachments. Not all grant types are currently supported.

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 fully compliant with the expectations outlined in the OAuth 2.0 specification. This is backward-compatible to support the migration of Version 1 clients. The token name usage in V2 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 V1 was accessToken.

My client would be billing her clients for the visit which is not a professional/specialist visit but more like evaluation and management services that come under CPT 99214. Other than 98 (Professional physician visit-office), any other code I can use?

Include service type code 30 to pull back all benefit information.

To know patient copay/coinsurance for the visit (probably service type 98) and also for the mental health as covered by the plan, should I be running multiple requests for 98, MH, and A6 for each patient to get complete eligibility? Is there a better combo of service type codes that can yield me the results with lesser number of requests per patient?

98, MH, and A6 are good, include 30.

Is there a code I can use specifically for telehealth coverage? I do not think Change Healthcare covers any codes after 2009 or the 3 character code of E37 I found on the X12 website.

Unfortunately when the guides came out, Virtual and Telemedicine was rarely used so there are no specific code designations or standards on how it should be returned. You could use a different service type code (we have seen 98, 30, 9, and there probably are other variances).
Normally though in a MSG they will have something like: MSG*VIRTUAL VISITS/TELEMEDICINE/TELEHEALTH~.

Other than the X3 and R5 report types, what are the other report types and in what format is this data?

Here is a complete list of report types.