API & Services Connection™
Request Sandbox AccessMarketplaceApp RegistryCommunityQuick Reference

FAQs

Suggest Edits

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 our APIs.

📘

NOTE

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

What kind of resources do you offer in your API documentation?

Here are the developer-focused resources.

In the Guides section, these resources are available:

  • Quick start
  • Security and authorization to access our APIs
  • API test environment
  • Overview of all our APIs
  • Request and response contents for all the APIs
  • Examples
  • JSON-to-EDI mapping
  • Predefined fields and values for trying our APIs in sandbox
  • Release notes
  • Error messages
  • FAQs (periodically updated)
  • Troubleshooting

In the API Reference section, these resources are available:

  • API Reference
  • Overview of the APIs
  • Downloadable Swagger/OpenAPI spec, such as Eligibility API – application in JSON format that generates our documentation for developers to view and use
  • Resources for API testing/trying
    • Postman collection, such as for Eligibility – for use with the Postman application (not owned by Change Healthcare), this collection allows users to call and test our APIs
    • TryIt! interactive interface for real-time API testing, such as for Eligibility API
  • Predefined fields and values for trying our APIs in sandbox

How can I access the ConnectCenter?

You will get access to the ConnectCenter when you contract with us.

Is there a call to understand if a provider is PAR or EPO for a given insurance provider?

We do not have an API to check provider directories to see if they are part of a network.

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

Yes, we do. Please sign up for a sandbox test environment here to familiarize yourself with our APIs without signing a contract without any financial obligations. For more information, see API testing environments. We provide a list of predefined fields and values for sandbox that you can use for testing a variety of responses by using API URLs and endpoints.

How to use test Payers in the sandbox?

See use test payers in sandbox.

What API domain should be used?

The most up-to-date URL is, https://apigw.changehealthcare.com. This URL provides overall increased performance and stability. The https://apis.changehealthcare.com URL is an older domain that is no longer supported.

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:

```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 an authorization token by making a request Generate authorization token

📘

BEARER TOKEN LIFESPAN

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

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 requested 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, see API Healthcheck.

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 Claims and billing sometimes also encompasses collections while, Professional Claims and billing 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.

Does Change Healthcare support appeals for denials? Are there any APIs through which these appeals can be submitted?

If a claim is denied or partially paid by a payer, a corrected claim should be sent for additional review. Submitting a corrected claim would require the claim frequency code '7', and the payer claim controlNumber must be included on the claim in the claimControlNumber field in the claimSupplementalInformation.

The claimControlNumber is the number assigned by the payer to identify a claim. Once submitted, the payer will review the claim and make any changes based on their internal review. The claimControlNumber is found on the payer 277 report.

The same process would need to be followed for voided claims, but using a frequency code '8.' Here is a sample corrected claim.

{ "controlNumber": "000000001", "tradingPartnerServiceId": "9496", "submitter": { "organizationName": "REGIONAL PPO NETWORK", "contactInformation": { "name": "SUBMITTER CONTACT INFO", "phoneNumber": "123456789" } }, "receiver": { "organizationName": "EXTRA HEALTHY INSURANCE" }, "subscriber": { "memberId": "0000000001", "paymentResponsibilityLevelCode": "P", "firstName": "johnone", "lastName": "doeOne", "gender": "M", "dateOfBirth": "19800102", "policyNumber": "00001", "address": { "address1": "123 address1", "city": "city1", "state": "wa", "postalCode": "981010000" } }, "providers": [{ "providerType": "BillingProvider", "npi": "1760854442", "employerId": "123456789", "organizationName": "HAPPY DOCTORS GROUPPRACTICE", "address": { "address1": "000 address1", "city": "city2", "state": "tn", "postalCode": "372030000" }, "contactInformation": { "name": "janetwo doetwo", "phoneNumber": "0000000001" } }, { "providerType": "ReferringProvider", "npi": "1942788757", "firstName": "johntwo", "lastName": "doetwo", "employerId" : "123456" },{ "providerType": "RenderingProvider", "npi": "1942788757", "firstName": "janetwo", "lastName": "doetwo", "middleName": "middletwo", "ssn" : "000000000" }], "claimInformation": { "claimFilingCode": "CI", "patientControlNumber": "12345", "claimChargeAmount": "28.75", "placeOfServiceCode": "11", "claimFrequencyCode": "7", "signatureIndicator": "Y", "planParticipationCode": "A", "benefitsAssignmentCertificationIndicator": "Y", "releaseInformationCode": "Y", "claimSupplementalInformation": { "claimControlNumber": "12345" }, "healthCareCodeInformation": [{ "diagnosisTypeCode": "BK", "diagnosisCode": "496" },{ "diagnosisTypeCode": "BF", "diagnosisCode": "25000" }], "serviceFacilityLocation": { "organizationName": "HAPPY DOCTORS GROUP", "address": { "address1": "000 address1", "city": "city2", "state": "tn", "postalCode": "372030000" } }, "serviceLines":[ { "serviceDate": "20050514", "professionalService": { "procedureIdentifier": "HC", "lineItemChargeAmount": "25", "procedureCode": "E0570", "measurementUnit": "UN", "serviceUnitCount": "1", "compositeDiagnosisCodePointers": { "diagnosisCodePointers": ["1","2"] } } }, { "serviceDate": "20050514", "professionalService": { "procedureIdentifier": "HC", "lineItemChargeAmount": "3.75", "procedureCode": "A7003", "measurementUnit": "UN", "serviceUnitCount": "1", "compositeDiagnosisCodePointers": { "diagnosisCodePointers": ["1" ] } } } ] } }

How do you re-submit a claim that was denied – Appeal & Denial

If a claim is denied or partially paid by a payer, a corrected claim would need to be sent for additional review. Submitting a corrected claim would require the claim frequency code '7', and the payer claim controlNumber must be included on the claim in the claimControlNumber field in the claimSupplementalInformation.

The claimControlNumber is the number assigned by the payer to identify a claim. Once submitted, the payer will review the claim and make any changes based on their internal review. The claimControlNumber is found on the payer 277 report.

The same process would need to be followed for voided claims, but using a frequency code '8.' Here's a sample corrected claim.

{
  "controlNumber": "000000001",
  "tradingPartnerServiceId": "9496",
  "submitter": {
    "organizationName": "REGIONAL PPO NETWORK",
    "contactInformation": {
      "name": "SUBMITTER CONTACT INFO",
      "phoneNumber": "123456789"
    }
  },
  "receiver": {
    "organizationName": "EXTRA HEALTHY INSURANCE"
  },
  "subscriber": {
    "memberId": "0000000001",
    "paymentResponsibilityLevelCode": "P",
    "firstName": "johnone",
    "lastName": "doeOne",
    "gender": "M",
    "dateOfBirth": "19800102",
    "policyNumber": "00001",
    "address": {
      "address1": "123 address1",
      "city": "city1",
      "state": "wa",
      "postalCode": "981010000"
    }
  },
  "providers": [{
    "providerType": "BillingProvider",
    "npi": "1760854442",
    "employerId": "123456789",
    "organizationName": "HAPPY DOCTORS GROUPPRACTICE",
    "address": {
      "address1": "000 address1",
      "city": "city2",
      "state": "tn",
      "postalCode": "372030000"
    },
    "contactInformation": {
      "name": "janetwo doetwo",
      "phoneNumber": "0000000001"
    }
  },
  {
    "providerType": "ReferringProvider",
    "npi": "1942788757",
    "firstName": "johntwo",
    "lastName": "doetwo",
    "employerId" : "123456"
  },{
    "providerType": "RenderingProvider",
    "npi": "1942788757",
    "firstName": "janetwo",
    "lastName": "doetwo",
    "middleName": "middletwo",
    "ssn" : "000000000"
  }],
  "claimInformation": {
    "claimFilingCode": "CI",
    "patientControlNumber": "12345",
    "claimChargeAmount": "28.75",
    "placeOfServiceCode": "11",
    "claimFrequencyCode": "7",
    "signatureIndicator": "Y",
    "planParticipationCode": "A",
    "benefitsAssignmentCertificationIndicator": "Y",
    "releaseInformationCode": "Y",
    "claimSupplementalInformation": {
      "claimControlNumber": "12345"
    },
    "healthCareCodeInformation": [{
      "diagnosisTypeCode": "BK",
      "diagnosisCode": "496"
    },{
      "diagnosisTypeCode": "BF",
      "diagnosisCode": "25000"
    }],
    "serviceFacilityLocation": {
      "organizationName": "HAPPY DOCTORS GROUP",
      "address": {
        "address1": "000 address1",
        "city": "city2",
        "state": "tn",
        "postalCode": "372030000"
      }
      },
    "serviceLines":[ {
      "serviceDate": "20050514",
      "professionalService": {
        "procedureIdentifier": "HC",
        "lineItemChargeAmount": "25",
        "procedureCode": "E0570",
        "measurementUnit": "UN",
        "serviceUnitCount": "1",
        "compositeDiagnosisCodePointers": {
          "diagnosisCodePointers": ["1","2"]
        }
      }
      },
      {
        "serviceDate": "20050514",
        "professionalService": {
          "procedureIdentifier": "HC",
          "lineItemChargeAmount": "3.75",
          "procedureCode": "A7003",
          "measurementUnit": "UN",
          "serviceUnitCount": "1",
          "compositeDiagnosisCodePointers": {
            "diagnosisCodePointers": ["1" ]
          }
        }
        }
    ]
  }
}

Is it possible to submit multiple claims at once, in batches?

We do offer batch submissions through SFTP only, our current API does not allow for batch submissions. These would have to be 5010-compliant EDI files. Please reach out to your sales representative to discuss pricing options for SFTP submissions.

When a claim is submitted via the API, the API returns a change healthcare claim ID. What API can I use to fetch the payer's claim number before we receive the ERA, ideally the next day after the claim is submitted successfully?

The payer-assigned claim ID would be returned through the SF and SD reports we provide through the responses and reports API. Additionally, you may be able to check the provider portal for the payer for this information.

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 controlNumbers come from?

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

Where can I get the Consolidated 270/271 Implementation Guide?

You need to license it directly from the X12 org.

How do we present ConnectCenter in an iframe in our site?

There is no iFrame capability for ConnectCenter right now. If you want to give your customers access to ConnectCenter, let us know during your implementation and we will set it up accordingly.

Is there a webhook that tells us when there is a change in status of a claim? We could have thousands of outstanding claims at a time, and rather than regularly checking a claim's status with an API call, it might be beneficial for us if we could get notified when there is an update.

We do not offer webhooks for this information. You would need to pull the payer report information we send through the responses and reports API. Here is a list of available reports.

What is Y, N, U, and W?

  • 'Y' is In-Network
  • 'N' is Out-Network
  • 'U' is Unknown
  • 'W' is Not Applicable
    When benefits are the same regardless of whether they are in or out of network or a plan network, does not apply.

I am currently doing FE testing in a staging environment for a client using Change Healthcare to pull up information for users that already have a healthcare plan. I found the sandbox data that can be used, but is there something similar outside of sandbox? I just need to be able to get some sort of data back in order to properly test that the functionality is working, but I would need a user that has a valid member and group ID.

Once you are contracted with Change Healthcare, the implementation team can work with you on possible testing scenarios depending on the internal Change Healthcare clearinghouse your transactions are assigned.

The sandbox requires pre-defined groupNumber value but it need not be sent. If you do, it must be one of the accepted pre-defined values, but it is optional. For integration, we need to give QA a way to test and pass one of the pre-defined values. Is it ok to remove it from being sent, what are the pros and cons of doing this in production?

From the TR3 document for the 270/271 transactions, use the Group or Policy Number code only if you cannot determine if the number is a Group Number or a Policy Number. Use codes IG or 6P when they can be determined.
Group numbers are usually tied to a dependent's information on an insurance card. There should not be an issue if you do not have it.

I am using the nuxt3 framework inside the server API. For some reason, I am having an issue getting a response back on both my own server and when using the testing functionality on the change testing site with the inline try its features.

You do not have a value in the tradingPartnerServiceId field. Use in the request body from this sandbox values list. Scroll down to view different responses based on that tradingPartnerServiceId field.

As a partner with Change Healthcare, what is the process after providers complete EDI enrollment? Who updates enrollment status for the provider?

We update Enrollment Central to approved or denied after following up and receiving a status from the payer. There are some payers that send the status to the provider directly and it is on the provider to forward that to us so we can update Enrollment Central.
If you have more questions, reach out to our enrollment team directly.

For Registration / Payer Enrollment

Is there a list of test Care Cost Estimate API requests that we can use to send API calls and determine all possible responses?

You can use the sandbox predefined fields and values there to test. The sandbox environment is made up of canned responses. We have created these for you to test or build out your own environment. So in theory, you can enter whatever you would like, but the responses will be the same.

Is there a way to retrieve the cost estimate data for multiple providers from a single API call?

No, the purpose is to provide the patient an out-of-pocket estimate for a specific procedure/service type code. Not for multiple providers.

What is a StatusTypeCode?

ServiceType codes are used to identify business groupings for healthcare services and benefits. Include the serviceType code in the API request body, and then submit to payers on an eligibility and benefit inquiry transaction to get the patient’s eligibility and benefit details. The serviceType code consists of value and valueType. An example: 

"service": {
    "codes": [
      {
        "value": "98",
        "valueType": "ServiceTypeCode"
      }

Each payer may have different supported service types for eligibility and benefit inquiries. You may visit individual payer site to find supported serviceType codes and the serviceType code best to use for the procedure you or your patients are trying to get an estimate of out-of-pocket cost. We recommend you purchase and use the 270 Implementation Guide specs.
Or
List of serviceType codes you can find on Connect Center >> under Verification >> New Eligibility Request >> drop-down list under ‘Service Information’ >> Service Type.

If you are not sure what service type code to use, you can use serviceType code “30” for a general Health Benefit Plan Coverage inquiry. Here is a list of official list from the x12 org.

📘

NOTE

Only serviceType codes with Starting date: 09/20/2009 will be active.

What is the difference between the Change Healthcare Payer List, Revenue Performance Advisor Payer List, ConnectCenter Payer List, Change Healthcare Attachment Payer List?

Each of these payer lists represents different products or services that customers can purchase from Change Healthcare. There are plans to consolidate all of the payer lists but that will not be available for some time. The payer lists may have some overlap but customers should only use the payer lists for the products/services they are contracted or testing with.

  • Change Healthcare (also internally known as Legacy Change, Emdeon, or Ark) payer list is for our Submitters who are given a 9-digit submitter ID, and typically do not utilize APIs to submit their transactions. If you have a 6-digit submitter ID, you will want to use the below mentioned ConnectCenter payer ID.
  • Revenue Performance Advisor (known internally as RPA or Capario) is another product that has a specific payer list for users of that product. Change Healthcare Attachment is a payer list for customers who are sending attachments through Change Healthcare.
  • ConnectCenter (aka Legacy Relay Health (LRH) payer list is a portal for our customers who are utilizing our Clearance or Assurance solutions. When you log into ConnectCenter it does show all payer lists so that may be what you are looking for (Payer tools >> Payer Search). If you are using our APIs for Claims and Eligibility you will want to use the ConnectCenter payer list.

What is the Claim submission flow in Change Healthcare

Please see claim submission workflow.

I get an invalid access token error for the API (sandbox). What is wrong?

These are the most common reasons for this issue:

  • Access token might not be valid for the selected API or you might have selected one API to test but tried a different API.
    Or
  • You might not have followed the Postman instructions correctly.
    Or
  • You might have used your own data instead of the our predefined values and fields.
    Or
  • You might not have followed the OpenAPI specs (if you are using a different testing environment other than Postman).

To resolve, try requesting for new access token and sending the request again, if the issue persists, perform one of these:

  • If you are trying our API in sandbox, contact your sales representative for help or post a question in the developer community.
  • If you are a contracted customer, contact support.
  • Additionally, if you are either a contracted customer or trying our APIs in sandbox, please plan to attend our office hours, where different Change Healthcare departments' representatives would be present, and can answer your queries or help you.

While calling the API, the following DNS error occurs:

  • javax.net.ssl.SSLHandshakeException: No subject alternative DNS name matching sandbox.apigw.changehealthcare.com found

Please refer to this link:
https://www.sslshopper.com/ssl-checker.html#hostname=sandbox.apigw.changehealthcare.com
Our SSL certificates for sandbox are set up correctly, share this link with your IT department along with the error you are getting. We hope this clarifies your concern.

When doing a payer search (accessed via Connect Center > Payer Tools > Payer Search) and selecting for Claims and Eligibility products, I get 3 different IDs. These are CPID, Real Time ID, and Payer ID. Why are they not particularly unique?

  • The CPID is for claims process only. We have this unique identifier that is setup to process claims with payers. Per the Claim type column, you can tell if it is a Professional CPID, or an Institutional CPID. You should use that for submitting the claim, the Trading Partner Service ID Field.
  • Eligibility or Claims status uses the Realtime Payer ID.
  • The Payer ID is found on the back of the insurance card. If it is not available, you can use the Realtime Payer ID.

Is submitter ID provided by Change Healthcare? Will this be provided for each of our clients?

At the time of account creation, only one submitter ID would be assigned to your organization. We can set up your organization as a "master billing organization", which would allow for you all to have individual submitters under the organization's umbrella. here is a document that explains this in further detail. The submitter ID would be one of the IDs used to identify transactions routing to and from specific customers. The submitter ID is an internal ID used by Change Healthcare. If you would like to pursue individual submitter IDs, please reach out to our team at [email protected] to schedule a call for additional information.

What are the steps to get the access for demo ConnectCenter?

The demo version of the ConnectCenter site is typically reserved for internal users only. When using the Eligibility API for testing in the sandbox, you can edit the request body and send it to the API engine to view what kinds of responses you will get. You can use the these values as the tradingPartnerServiceId (this is the Payer ID; this will vary based on the payer you want to connect to) to change the responses. These range from a canned response that returns a single coverage plan, Low Deductible High Premium with many different copayments, and even sample responses for Humana along side multiple other payers.

Testing claims in the sandbox is limited to the predefined data values but in production, you have the ability to submit test transactions through two methods:

  • The first would be, to send the value of '9496' as the tradingPartnerServiceId, this would allow for a claim submitted with live data to run through clearinghouse edits without being submitted to a payer.
  • The other option would be, to add a value of "usageIndicator":"T" to the claim; this would allow you to test against different tradingPartnerServiceIds and any payer-specific edits they may have.
{
  "controlNumber": "000000001",
  "tradingPartnerServiceId": "9496",
  "usageIndicator":"T",
  "submitter": {

We need to demo for a potential client; which APIs can we integrate with in the sandbox environment to demonstrate the ability to upload claims and, receive and view disputed/rejected claims?

If sandbox access has not been acquired yet, submit a request through our Developer Portal by clicking Request Sandbox Access. We recommend the Professional Claims v3 API for the demo purpose. This would allow you to submit the required sandbox data while being able to edit key elements in the claim to solicit different edit responses. Real-time demo can be performed by using our Postman collection available here.

How to handle multiple authorization numbers per claim?

If the Institutional Claims required multiple authorization numbers, multiple claims need to be submitted. Submission through the Professional API allows for prior authorization information to be submitted at both the claim and line level Institutional Claims APIs allows for prior authorization information to be submitted at the claim level only. Here is a sample from our Open API Specs.

Professional Claims mapping:

ServiceLineReferenceInformation:
      type: object
      properties:
        repricedLineItemReferenceNumber:
          type: string
          description: 'Loop: 2400, Segment: REF, Element: REF02 Notes: When REF01=9B'
        adjustedRepricedLineItemReferenceNumber:
          type: string
          description: 'Loop: 2400, Segment: REF, Element: REF02 Note: When REF01=9D'
        priorAuthorization:
          maxItems: 5
          minItems: 0
          type: array
          description: Loop 2400 REF
          items:

Institutional Claims mapping:

 ClaimSupplementalInformation:
      type: object
      properties:
        reportInformation:
          $ref: '#/components/schemas/ReportInformation'
        priorAuthorizationNumber:
          type: string
          description: 'Loop 2300; Segment: REF; Element: REF02 when REF01 = G1'

Related Topics

Updated about 2 months ago