Q&A 2021 Dev Community

📘

NOTE

Please see the API FAQs section for 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 API.

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
• Request and response contents for all the APIs
• Examples
• JSON-to-EDI mapping
• Release notes
• Error messages
• FAQs (periodically updated)
• Troubleshooting

In the API resources section, these resources are available:

• References to all API categories
• Download Swagger/OpenAPI, such as for Eligibility API – application in JSON format that generates our documentation for developers to view and use
• API testing
  • Postman collection, such as for Eligibility – for use with the Postman application, this collection allows users to call and test the APIs
  • TryIt! interactive documentation for real-time API testing, such as for Eligibility API

What is the Eligibility API? Wondering what kind of services it provides and the benefits of the product?

The Eligibility API is an easy way to check if a patient has healthcare coverage with a specific insurance company (payer). For example, if I were to schedule an appointment with my doctor for some reason, the first thing they are going to ask for, is my insurance card, and then run an eligibility call to my insurance company to verify that I have insurance. The response of that eligibility call will also provide how much my co-pay is.
Visit our developer portal for specific documentation.

This service uses the standard X12 EDI 270 eligibility transaction, and formats it in JSON for an HTTP request. It makes this popular EDI transaction set more accessible to developers and to users' applications. We manage the X12 standards behind the scenes and give you efficient access to medical subscriber or dependent plan membership, copays, coinsurances, deductibles, and more in an easy-to-use, human-readable format.

Our Eligibility API solution provides complete patient profile and benefits information to support healthcare delivery and more-efficient and accurate reimbursement. Providers get better front-end information to improve claiming processes and reimbursement rates. For payers, it means claims spend less time in pending status, and also means fewer rejected and reworked claims.

Eligibility v3 API throws the 79 (Invalid Participant Identification) error when the CMSMED is passed as the tradingPartnerServiceId. It is not even working on the Change Health care dashboard and throws the same error. Are the any extra details do we need to send while checking eligibility for the medicare insurance?

CMSMED requires NPI enrollment before they reply to your requests. Have you enrolled any NPIs you are using in the request with CMS through the ConnectCenter and Enrollments Central?
If you are still in implementation, you can contact [email protected] for more detailed help.

Some responses have policyNumber and planInformation while some do not have. How can I get that? Is the policyNumber same as the subscriber's memberId?

For a background, the identifiers within the planInformation object are additional identifiers that a payer might send back when it is helpful to have more information than just the memberId. The main identifier for the member is typically the memberId, and that value will come back in the subscriber object. This is a required field, so you should be getting this back consistently.

The additional IDs within planInformation are optional fields for the payer to return, and so you may see different fields come back based on who you are sending the request to. For example, Aetna may return more or less information than Cigna would. See more information on these fields.

If there is ever something critical that a payer should be returning that is not in the response, our Eligibility support team may be able to help troubleshoot.

How can i get member copay, deductible apart from status in the eligibility response API?

The member's co-pay and deductible will appear in the response when it is applicable. Some health plans may not have a deductible or have co-insurance rather than a co-pay, so those fields will not always be present.

In sandbox, we have a range of emulated payer responses that you can test with. These are found by changing the value of the tradingPartnerServiceId field in the request with the values located on this page sandbox predefined values and test responses.

When I enter wrong memberId or birthdate, the Eligibility API takes a long time to respond on a live server, can you help?

The Eligibility API communicates with the payer's database in real time, and we have found that some payers have high response times during peak volumes. If you are in production, please work with your implementation analyst to troubleshoot.

If the Eligibility API is not guaranteed to provide plan or benefit information, how do we determine the co-pay if we do not have the card?

I think the item to clarify is the data contained in the Eligibility response. If you get a successful response from the Eligibility API based on the patient information in the request, that data is coming directly from the source of truth, which is the payer. The variance you might find is differences in the kinds of data returned between payer to payer or between plans. If a patient has a co-payment that the payer wants you to know about, it will be contained in the response. Benefits listed as co-payments are generally collected from the patient at the point of service, and this is typically understood by the payer. The details can vary between payers or plans, so if in doubt you should always clarify with the payer.

Complete information on the patient responsibility and other usage information for the Eligibility transaction can be found in the X12 270/271 Implementation Guide. That industry guide is licensed and is available for purchase from the X12 organization.
Here is an example snippet from the Eligibility API in sandbox using tradingPartnerServiceId as UHC:

{
            "code": "B",
            "name": "Co-Payment",
            "coverageLevelCode": "IND",
            "coverageLevel": "Individual",
            "serviceTypeCodes": [
                "33"
            ],
            "serviceTypes": [
                "Chiropractic"
            ],
            "timeQualifierCode": "7",
            "timeQualifier": "Day",
            "benefitAmount": "12",
            "inPlanNetworkIndicatorCode": "W",
            "inPlanNetworkIndicator": "Not Applicable"
 },

Request: please use standard HTTP responses to indicate the result of a request. For example, a request to the eligibility API that has multiple invalid values returns a 200 status code, but the response has an error key with details on the error fields (this should be a 400 status code to indicate issues with the request parameters). Additionally, if the Authorization header is not sent, a 400 status code is returned, although a 403 unauthorized status code would be much more clear what the issue is.

There are a few reasons for why we use the status codes we do today. For the Eligibility API, it is possible to get back errors from applications downstream of the API itself. Those might come back from Change Healthcare's clearinghouse where our payer connections are configured or from the payer. These errors would come back as 200 status because we successfully made the connection to the downstream entity and the request is being rejected by a different system.

As for the error with the missing Authorization header, I can see why a 400 Bad Request might describe the error. It is not that your authentication is invalid, but a basic requirement of the request is not being met. All requests must have the Authorization header, so any request without the header would be considered a 400 Bad Request. If you send the Authorization header with an invalid or expired token, you will receive a 401 Unauthorized.

Eligibility API is giving Unable to process the request at this time, please try again later? In Postman, the auth API gives Either client_id or client_secret are invalid, when using correct value for both. It works via curl though.

Here are some general troubleshooting tips:

1. Check the headers for any typos or unexpected values.
2. Validate your JSON to make sure it is properly formatted.
3. Try the healthcheck endpoint to make sure the API is up and running.
4. Check out our pre-formatted Postman collections in the documentation to compare values and troubleshoot differences.

If you still experience issues, send over the headers and body of the request, and we will troubleshoot in depth.

Can you explain what the Claims Status API is? Is it different from the professional and institutional claims APIs?

The submitter uses a Claim Status request to ask about the status of a previously submitted claim. The payer returns the response as an X12 EDI 277 transaction, which is translated back to JSON by the API gateway. It describes where the claim is in the adjudication process (for example, Pending or Finalized).
If the claim is finalized, the response provides the disposition of the claim (for example, Paid or Denied). For denied or rejected outcomes, the response includes the reasons for the denial or rejection.

What is Professional Claims API and what is it used for?

The Professional Claims API allows for the creation and submission of claims so that your providers can be reimbursed for their services. This API takes the standard established in the X12 EDI 837P transaction and translates this standard to JSON so it is more accessible to developers and easily integrated into users' applications.

The ASC X12N Health Care Claim: Professional (837P) transaction allows healthcare providers to submit healthcare claims for a service or encounter. A healthcare claim includes patient information, related diagnoses, procedures performed or services provided, and any related charges.

This service includes the Validation endpoint to check and verify your claim prior to submission to the payer. This endpoint checks for the correct well-formed syntax of the submission as well as correctly summing service line charges and verifying codes in order to minimize the chance of rejection by the payer.

I am trying to test out a scenario where the clinic would enter a specific service type code and want to get patient benefits for that specific service code?

All of our sandbox Eligibility responses are real payer responses that have been de-identified and emulated. The only value that affects the response in sandbox is the "tradingPartnerServiceId". You can receive different responses by switching that out, but the responses will not vary if you change other values like the "serviceTypeCode".

Do the doctors have to be re-registered in all each Medicare variant in order to return benefits correctly?

A couple things here: now that you are off the old PokitDok APIs, the best payer list for you is accessible through ConnectCenter. You can also access this behind the log in and export to .CSV format. For this, filter to Eligibility and Medicare before your search.

Most Medicares have the Eligibility ID/Real Time ID of CMSMED. If there are specifics that do not, such as, a Medicare Advantage plan, that might require separate enrollment.

In this situation, I recommend submitting a ticket to our Registrations team. You can submit a ticket through ConnectCenter or by email to [email protected].

Is a list of Eligibility AAA errors with a description available?

Yes, here is a list of AAA error codes.

• AAA Rejection codes are part of the Eligibility standard, but since that standard is licensed, we are limited in what we can show. Most are clear when they are defined, such as AAA 72 for Invalid/Missing Subscriber/Insured ID. That basically means that the memberId in the request does not have a match with the payer.

A couple others that might be nuclear:

• AAA 41 — Authorization/Access Restrictions: This is an enrollment issue where the NPI in the request needs to be recognized by the payer. You can check enrollment requirements on our payer list, and complete the enrollment form through Enrollment Central. This may also be represented with AAA 79 for Invalid Participant Identification.

• AAA 42/80 — These indicate something is wrong like a transaction time out or an exception that does not fit in other AAA codes. Most of the time, these are temporary and will resolve on their own. If you continue to get this error on a request, you should open a support ticket.

The complete list of AAA codes and Eligibility request and response codes can be purchased here.

Does the Revenue Performance Advisor work with claims submitted with the API as well as claims submitted through the revenue advisor interface?

Only the Eligibility API works with Revenue Performance Advisor. Our claims APIs currently route to another one of our switches, this will be considered for a future enhancement.

Claim status response message: "Patient eligibility not found with entity. Usage: This code requires use of an Entity Code". What does this mean?

This reads that the payer (entity: Insurer) cannot find the patient in their system. This would either indicate that you are calling the wrong payer or there could be a typo in the request that is sending wrong information.

Here are the claim status codes. Reverify the patient's insurance information and make sure all the details are correct.

How can I interpret the following?

1. How would you interpret this service level info from sandbox response?

{
            "code": "C",
            "name": "Deductible",
            "serviceTypeCodes": [
                "45",
                "42"
            ],
            "serviceTypes": [
                "Hospice",
                "Home Health Care"
            ],
            "insuranceTypeCode": "MA",
            "insuranceType": "Medicare Part A",
            "timeQualifierCode": "26",
            "timeQualifier": "Episode",
            "benefitAmount": "0",
            "benefitsDateInformation": {
                "benefit": "20170101-20171231"
            }
        },

How do I interpret "329 days" here in terms of co-payment?
{
"code": "B",
"name": "Co-Payment",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"insuranceTypeCode": "MA",
"insuranceType": "Medicare Part A",
"timeQualifierCode": "7",
"timeQualifier": "Day",
"benefitAmount": "329",
"benefitsDateInformation": {
"admission": "20170101-20171231"
},
"benefitsServiceDelivery": [
{
"unitForMeasurementCode": "Days",
"timePeriodQualifierCode": "30",
"timePeriodQualifier": "Exceeded",
"numOfPeriods": "60",
"unitForMeasurementQualifierCode": "DA",
"unitForMeasurementQualifier": "Days"
},
{
"unitForMeasurementCode": "Days",
"timePeriodQualifierCode": "31",
"timePeriodQualifier": "Not Exceeded",
"numOfPeriods": "90",
"unitForMeasurementQualifierCode": "DA",
"unitForMeasurementQualifier": "Days"
},
{
"timePeriodQualifierCode": "26",
"timePeriodQualifier": "Episode",
"numOfPeriods": "1"
}
]
},

2. In the preceding code snippet, does it mean that "0 episodes" come under deductible, that is, they are fully covered by insurance?

The following information is from the documentation.
Answer for # 1. — the 'Episode' is the episode of care and '26' is the number of days in that episode.
Answer for #2. — $329 is the benefit amount.

Benefits, Time Periods, and Coverage Amounts
Every Service Type segment has more or less the same format:

Related Topics

• API Reference
• Troubleshoot APIs with Metadata