|NOTE: The Claim Status API works with both Professional Claims and Institutional Claim types.|
Our goal for onboarding is to ensure API customers can automate their API consumption process. For end use, API consumption shouldn't require 'seeing' the APIs. Ideally, several tasks can be developed and automated for the best user experience:
A data entry console to make claims requests. All providers' offices need an effective and straightforward console for creating and filing new claims, with the common knowledge shared across the team reflected across the UI.
Automate API bearer token usage, using OAuth2 token retrieval. API users should never have to think about the basic task of getting new tokens so they can submit more Professional Claims transactions.
Abstract the complex data that's needed for a successful request; users should easily make Professional Claims requests and efficiently get replies. For example, Control Numbers exist in all of our APIs as a required value that the provider or institution generates to identify each transaction. When the provider's office sends a request, they should never have to worry about defining and entering these values, and they should be handled programmatically.
Auditing and tracking for all transactions, including tracking of all Control Numbers, payer ID information and patient information for effective cross-referencing.
Actionable information for solving problems and successfully completing medical network tasks.
For token automation 'under the hood,' for example, you can apply one of the following choices:
Get a unique token for each transaction;
Apply the same token across all transactions during the full token lifespan and automatically refresh the token just before it expires. Tokens for production APIs have a two-hour/7200 second lifespan.
|NOTE: We recommend automating transactions to use the tokens generated over the token lifespan. Obtaining tokens for each individual transaction is less efficient and does not improve the security posture for any transaction.|
You’ll need the following to work with our APIs:
API Credentials – The
client_secret used in the Security and Authorization API. These are the credentials for your company. You should have two sets of credentials; one set for sandbox, and one set for production. You use the Sandbox credentials to get familiar with Change Healthcare APIs, with no financial obligation.
Postman Collection – Postman is a free tool that enables you to test calls to RESTful APIs. By importing using the links we provide here, you can quickly submit new API requests to our gateways with the Postman application. Postman is not associated with Change Healthcare.
You can test the APIs from within our interactive OpenAPI documentation (see the API Reference link near the top left).
You work with our REST APIs using a series of HTTP URLs.
To use our REST APIs, you use access credentials provided by Change Healthcare. A credential set consists of a random alphanumeric client_id and client_secret pair. Contact your Change Healthcare representative if you do not have this information.
|NOTE: Change Healthcare strongly recommends you carefully guard your API access credentials. Avoid sharing them with others..|
You can access all Change Healthcare APIs using the following URLs. You will have a separate set of credentials for each URL – one set for sandbox and one set for production:
Change Healthcare supports a traditional X12 EDI request if you choose to implement requests in native EDI format. The responses will also appear in EDI format.
The Claims Status Raw-X12 endpoint is as follows:
|NOTE: Using our Claim Status API for Raw-X12 EDI transactions, you can send your API request and receive your responses in X12 format instead of JSON. We provide it in the Claim Status Postman collection for testing and investigation of API usage; it isn't a substitute for a console used in a business context for processing eligibility requests and claims requests of various types.|
Open API Spec – A JSON document, also known as the Swagger file, that shows all the allowable fields and objects for the API. All of our API collections provide this specification as an easy download.
Developer Portal – the home of Change Healthcare’s API documentation.
ConnectCenter – Change Healthcare’s portal for Medical Network transactions. It contains Change Healthcare’s Payer Lists, the Payer List Enrollments wizard, and other API customer resources.
If you are missing any of the above resources, contact your Change Healthcare account manager.
Updated 4 months ago