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

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. 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 even though I am using the same access token that I used for the API (sandbox).

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.

Related Topics

Updated 14 days ago