Patient Responsibility Estimator v2

Summary API Attachments FAQ CHANGE LOG     

Overview

Patient Responsibility Estimator, or PRE for short, provides real-time estimates of patient out-of-pocket costs to healthcare providers. Patient Responsibility Estimator (PRE) gives providers access to our Intelligent Healthcare Network to help determine patient liability for an encounter. We automate benefits extraction, freeing API users of the need to interpret data from an eligibility and benefits (271) response in order to make an accurate estimate.

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

Yes, but first you need aclient_id and client_secret and for that you can Request Sandbox Access.

After receiving your client_id and client_secret for our sandbox environment, you can test the API from within our interactive documentation, using an application such as Postman, or from your own stack.

Try our Postman Collection Run in Postman

When using the Postman Collection, you will need to create a Postman Environment and add your client_id and client_secret to the Postman Environment.

After adding your client_id and client_secret to the Postman Environment, executing the POST Security Authorization Access Token will add the time sensitive token to the Postman Environment.

Once a valid security token is set in the Postman Environment the other POSTs in the collection will work until the token expires, after which it can be refreshed.

Be sure to read the descriptions of each of the POSTs in the collection as not all of them will return an estimate since some require PHI that cannot be published with the collection.

How is PRE different from other cost estimators?

PRE uses a combination of eligibility and benefits responses, allowed amounts derived from historical claims data, plus additional data specific to a procedure or geolocation to estimate what a patient is likely to owe to a provider for an encounter.

How can I implement the PRE API?

The most popular way to implement PRE is directly into your organization (or practice management system) to post patient estimates natively within your own user interface. This gives you control over how to display the information and keeps your customers from having to open a new application.

The Postman Collection can Generate Sample Code for implementing the POSTs in a variety of different languages.

Is there a specific Eligibility format required to submit an API call for a patient estimate?

We accept patient eligibility and benefits details in two formats as part of the request:

Manually

Manually - Provide the patient’s benefits information (e.g. remaining deductible) in the API request itself. In this scenario, it does not matter how you run the eligibility.

271 Eligibility response

Provide a 271 eligibility response in X12 format within the request. We automatically parse the benefits information and apply to the estimation algorithm.

Internal Eligibility Invocation

  • We run the eligibility for you
  • We then determine the benefit based on eligibility response
  • We will return the estimated amount(s).

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

The Change Healthcare sandbox is an environment where developers can test the PRE API for a variety of use-cases. This will help you become familiar with our domain model and provide an understanding of fields that are required for an API call. From there, you can decide which fields and attributes from the output to use for your platform or product. To request access to the sandbox once our agreement has been executed please contact us developerplatform@changehealthcare.com

How does PRE know the contracted maximum allowable between a provider and payer?

Change Healthcare uses your claims (837) and remittance information (835) processed through our network to determine the allowable amounts. At a high level, these are the primary ways - If a provider's claims and remittances are processed through the network, the solution uses past payment trends to determine. If a provider's claims and remittances are not available in our network, PRE estimates using payer's payment trends in the same geographic area as the provider. PRE can also use Medicare payment rates to price Medicare requests.

What information needs to go in the request header?

In the header for an API request, you need to pass an authorization token. You can get the token by making an API call to:

curl --location --request POST 'https://sandbox.apis.changehealthcare.com/apip/auth/v2/token' \
--header 'Content-Type: application/json' \
--data-raw '{
  "client_id":"<Your_Client_Id>",
  "client_secret": "<Your_Client_Secret>",
  "grant_type": "client_credentials"
}'

This is a precursor to making a PRE API call, which might have the following headers:

Authorization: Bearer <Your-Access-Token>
Accept: application/vnd.changehealthcare.pre-v2.+json

Read all about our protocols in the Security and Authorization section of this portal.

When you're ready for production, simply remove sandbox from the URL and use a production client_id and client_secret.

You will also need to pass an Accept header with value of application/vnd.changehealthcare.pre-v2.+json to specify the version of the API you're calling.

How is PRE different from basic eligibility and benefits and other cost estimators?

PRE uses a combination of eligibility and benefits responses, allowed amounts from claims data, and other data specific to a procedure to estimate what a patient is likely to owe to a provider for a particular encounter.

What type of provider settings and specialities work best with PRE?

PRE works best for professional/ambulatory providers, including multi-specialty physician groups, chiropractors, physical therapists, diagnostic imaging centers, labs, ambulatory surgery centers, durable medical equipment providers, and so on.

Our latest version, PRE 2.0, also works well in the acute care/institutional setting for both inpatient and outpatient services.

How can I implement PRE?

One way is to implement PRE directly into your software (practice management or other) to get cost estimates natively within your own user interface. This gives you control over how you display the information, and keeps your customers from having to open a new application. This documentation serves as a guide on how to do exactly this.

Another option is to use Change Healthcare's Patient Access Advisor (PAA) solution. PAA is a software solution that offers a suite of features, one of which is patient estimation. If you are interested in exploring this option, please let us know.

Who runs the patient eligibility check prior to submitting an API call?

We accept patient eligibility and benefits details in two formats as part of the request:

One way is for you to provide specific benefits information (e.g. remaining deductible) from your own eligibility and benefits checks, no matter how they're done, in the API request itself.

Second way is to simply provide a 271 in X12 format in the request and let us parse the benefits information for you. Let us do the legwork of determining the patient's benefits for you.

Third way is that we check eligibility and use benefits from eligibility response for estimation.

How does the PRE solution know the contracted maximum allowable between a provider and payer?

Change Healthcare uses the claims (837) and remittance information(835) processed through its network to determine the allowable amounts. At a high level these are the primary ways - If a provider's claims and remittances are processed through the network, the solution uses past payment trends to make a decision. If a provider's claims and remittances are not available in the network, it estimates using payer's payment trends in the same geographic area as the provider. It also uses Medicare payment rates to price Medicare requests.

What kind of data is expected to be supplied to PRE solution to get an estimate?

The output consists of primarily two types of data:

Values received in the input

This is the same data that was received in the input such as provider's Tax id, NPI, zip code and various other fields

Information related to the estimate

Summary

This is the total patient estimate of all procedures.

Provider level

This is the total patient estimate due to each provider in case more than one provider was part of the encounter.

Line/Procedure level

This is the patient estimate for each procedure.

Information required for eligibility check

Summary

This is the patient detail required for eligibility check.

We recommend that it is completely up to the client to decide the level of details they want to consume from the PRE API output and map to their front end applications. More details on the Information fields are available in the API definition section

Example Request

{
    "customerPreference": {
        "rateSourceProcessingOrder": "Standard",
        "serviceFlag": "Manual"
    },
    "providerServices": [
        {
            "provider": {
                "npi": "1295162766",
                "postalCode": "05405",
                "taxId": "471511123",
                "placeOfService": "21",
                "lineOfBusiness": "Facility"
            },
            "services": [
                {
                    "procedureCode": "73130"
                }
            ]
        }
    ],
    "payerBenefits": [
        {
            "payer": {
                "tradingPartnerServiceId": "23284",
                "planType": "Automobile Medical",
                "payerSequence": "Primary"
            },
            "benefit": {
                "copay": 0,
                "deductibleRemaining": 100,
                "annualDeductible": 150,
                "coinsurancePercentage": 10,
                "annualOutOfPocketMaximum": 300,
                "annualOutOfPocketMaximumRemaining": 250
            }
        }
    ]
}

Example Response

{
    "customerPreference": {
        "rateSourceProcessingOrder": "Standard",
        "serviceFlag": "Manual"
    },
    "payerBenefits": [
        {
            "benefit": {
                "annualDeductible": 150,
                "annualOutOfPocketMaximum": 300,
                "annualOutOfPocketMaximumRemaining": 250,
                "coinsurancePercentage": 10,
                "deductibleRemaining": 100
            },
            "memberAccount": {},
            "payer": {
                "payerSequence": "Primary",
                "planType": "Automobile Medical",
                "tradingPartnerServiceId": "23284"
            }
        }
    ],
    "providerEstimateAndBenefit": [
        {
            "provider": {
                "lineOfBusiness": "Facility",
                "npi": "XXXXXXXXXX",
                "postalCode": "05405",
                "taxId": "XXXXXXXXXX"
            },
            "providerSummary": {
                "totalChargeAmount": 0,
                "totalEstimateAmount": 35.69
            },
            "serviceLineDetails": [
                {
                    "estimateAmount": 35.69,
                    "lineAdjustments": [
                        {
                            "appliedCoinsuranceAmount": 0,
                            "appliedDeductible": 35.69,
                            "payer": {
                                "payerSequence": "Primary",
                                "planType": "Automobile Medical",
                                "tradingPartnerServiceId": "23284"
                            },
                            "payerDueAmount": 0,
                            "perUnitPayerRate": 35.69,
                            "rateSource": "Medicare rates in your region as a baseline with 5% added as a proxy for commercial rates",
                            "rateSourceId": "06",
                            "totalPayerRate": 35.69
                        }
                    ],
                    "service": {
                        "procedureCode": "73130",
                        "unit": 1
                    }
                }
            ]
        }
    ],
    "totalEstimateAndBenefit": {
        "legalDisclaimer": "This is an estimate and not a guarantee of payment. It is based on an estimate of negotiated rates and not actual contracts. It does not consider medical necessity, limitation or exclusion.",
        "payerSummary": [
            {
                "appliedCoinsuranceAmount": 0,
                "appliedCopay": 0,
                "appliedDeductible": 35.69,
                "benefitAppliedNarrative": "$35.69 was applied from patient's deductible, $0.00 was applied as Coinsurance amount. $0.00 was applied as Copayment.",
                "payer": {
                    "payerSequence": "Primary",
                    "planType": "Automobile Medical",
                    "tradingPartnerServiceId": "23284"
                },
                "payerDueAmount": 0,
                "payerDueAmountNarrative": "The Primary payer is expected to pay $0.00 of the adjusted charges."
            }
        ],
        "summary": {
            "estimateAmount": 35.69,
            "estimateAmountNarrative": "The patient's estimated payment amount is $35.69",
            "totalChargeAdjustment": 0,
            "totalChargeAdjustmentsNarrative": "The patient saved $0.00 in total charges. Contractual rules between health plans and healthcare providers reduce charges to negotiated rates.",
            "totalChargeAmount": 0,
            "totalChargeAmountNarrative": "The total charges submitted by the provider for this visit was $0.00"
        }
    },
    "transactionIdentifier": {
        "transactionId": "33ee9fb7-1a5c-446e-93cd-44c58c981158"
    }
}

Mandatory Fields

This section provides information on required fields for the PRE API. This will help you get a headstart on identifying the data you'll need to supply to successfuly implement PRE.

As mentioned in PRE API Overview, the solution makes use of historical claims and remittances to estimate maximum allowables/fee schedules. You must ensure that values supplied in the input to PRE, such as NPI, tax ID, zip codes, and place of service, match with the values typically used in a claim.

Customer Preference -

serviceFlag - this must contain one of the four possible values below to indicate where benefit data will come from

"Self Pay" - user identifies the patient self pay with no known insurance benefits   

"Manual" - user supplies patient benefits as discrete fields in the request

"271" - user includes a complete X12 271 response in the request

"PRE&Eligibility" - To use Eligibility API for deriving the patient responsibility

Provider information

npi - preferably billing NPI but rendering NPI also valid

taxId - tax ID used in claim billing

postalCode- the 5 or 9 digit zip code used in claim billing

lineOfBusiness - use professional for professional/ambulatory settings and facility for institutional settings

placeOfService - the 2 digit place of service code (professional) or 2 digit facility code (institutional) that a provider uses in claim billing (11 - office for professional claims; 24 - ambulatory surgery center for professional claims; 13 - ambulatory surgery for institutional claims)

organizationName - required when the serviceFlag is "PRE&Eligibility"

Payer Information

tradingPartnerServiceId - this is a 5 digit payer ID that is available on our publicly-facing payer list for remittance files (835); UnitedHealthcare, for example, uses the ID 87726. Most, but not all, trading partners and payers use the same 5 digit ID for both claims and remittances.

tradingPartnerEligibilityServiceId - This is eligibility service payer id. To get the payer list, please contact us @ developerplatform@changehealthcare.com

Note: these IDs are not yet available through our Trading Partner API but will be in future versions

planType - the type of plan, also called as the claim filing indicator on a claim, such as ppo, hmo, or medicare part b

benefit - the benefit section is required when the serviceFlag is "Manual"

Service

procedureCode - five digit HCPCS or CPT code; more than one procedure code can be supplied

Errors

When does the PRE API generally throw errors?

An error may be thrown in the following scenarios:

  1. Incorrect data is supplied in the request, such as an invalid procedure code, NPI or plan name
  2. Mandatory data is missing from the request, such as NPI, tax ID, or procedure code
  3. PRE is not able to determine the allowed amount for the procedure

What do error responses look like?

The error response is structured to show you all of the errors identified in a request so that you can make all necessary changes needed for a succesful response on your next call.

The structure has consolidated errors at a summary level under the object errorResponse and each individual error is reported in subsequent objects.

Example of an errorResponse object:

{  
   "errorResponse":[  
      {  
         "code":"INVALID_MISSING_INPUT_DATA",
         "description":"The length of procedure code should be 5 characters. Value provided in plan type should be one of the following - HMO,PPO,POS,EPO,FFS,Medicare Part B,Medicaid,Automobile Medical,Champus,Dental Maintenance Organization,Veterans Affairs Plan,Workers Compensation,Self Pay,Other. ",
         "transactionIdentifier":{  
            "customerTransactionId":"12345678",
            "transactionId":"2a6ed492-02e3-46b6-aed9-8b53e84767a3"
         },
         "errors":[  
            {  
               "field":"procedureCode",
               "value":"9921",
               "code":"INVALID_LENGTH",
               "description":"The length of procedure code should be 5 characters",
               "location":"$.providerServices[0].services[0]",
               "followupAction":""
            },
            {  
               "field":"planType",
               "value":"epo9",
               "code":"INVALID_VALUE",
               "description":"Value provided in plan type should be one of the following - HMO,PPO,POS,EPO,FFS,Medicare Part B,Medicaid,Automobile Medical,Champus,Dental Maintenance Organization,Veterans Affairs Plan,Workers Compensation,Self Pay,Other",
               "location":"$.payerBenefits[0].payer",
               "followupAction":""
            }
         ]
      }
   ]
}

Error response fields

code - code assigned to a particular type of error

description - description of an error

transactionIdentifier - contains the transaction ID assigned by PRE and by the your application, if provided

field - the specific field name with the error

value - value in the field that caused the error

location - JSON object location of the field with the error

What are all of the possible values for code?

  1. MISSING_MANDATORY_FIELD
  2. MISSING_SECTION
  3. TOO_MANY_ELEMENTS
  4. INVALID_LENGTH
  5. INVALID_MAX_VALUE
  6. INVALID_VALUE
  7. INVALID_PATIENT_BENEFITS
  8. MISSING_271
  9. 271_TRANSLATION_ISSUE
  10. INVALID_JSON
  11. UNABLE_TO_RETRIEVE_REQUIRED_BENEFITS_FROM_271
  12. ALLOWED_AMOUNT_NOT_FOUND
  13. INVALID_MISSING_INPUT_DATA

Change Log

API Name API Version Date Introduced Available Until
PRE v2 09/25/2019 -