Claims Responses and Reports FAQs
The Claims Responses and Reports v2 API provides a direct connection to your mailbox where payers send their responses and reports to your claims. Use this API to access your mailbox for claim payments, claim status updates, and other communications regarding the revenue cycle from the payer.
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.
Can Reports v2 handle large/data/reports files?
Yes, Claims Responses and Reports v2 performs real-time streaming of large amount of data. Our service will return a response with a 413 if the file size is too large for real-time retrieval and EDI 277 and EDI 835 stream larger files.
Other than the X3 and R5 report types, what are the other report types and in what format are this data?
Here is a complete list of available claims responses and reports.
How long are the finished/downloaded Claims files available in the mailbox?
The files are kept in the mailbox for a maximum of 30 days. For more information, please follow the recommended File Retrieval workflow, best practices, and retention rules.
File types supported
This API enables you to obtain files of the following types:
-
EDI 277 Claim Status report files â responses to EDI 276 Claim Status inquiries, that you can send using our Claim Status APIs;
-
EDI 835 Claim Payment/Advice reports â provide detailed payment information for submitted Professional or Institutional claims. 835 Transactions can be returned for Professional (837p) and
Institutional (837i) Claim electronic submissions, and for paper and electronic CMS 1500 and
UB04 claims submissions.
Change Healthcare Medical Network Claims Responses and Reports v2 API endpoint
https://apigw.changehealthcare.com/medicalnetwork/reports/v2/
If you run this endpoint, you will see a list of all 277 files (X3 prefix) and 835 files (*R5** prefix). The contents of these files are in EDI format.
How do I access the Claims Responses and Reports v2 production APIs?
Search for a specific file
https://apigw.changehealthcare.com/medicalnetwork/reports/v2/
Endpoint to translate a 277 EDI report file to JSON
https://apigw.changehealthcare.com/medicalnetwork/reports/v2/{ReportID}/277
Endpoint to translate an 835 EDI report file to JSON
https://apigw.changehealthcare.com/medicalnetwork/reports/v2/{ReportID}/835
Delete HTTP endpoint
You can delete files from your mailbox using the DELETE endpoint.
DELETE https://apigw.changehealthcare.com/medicalnetwork/reports/v2/
What types of files does this API get from the mailbox?
277 transaction is claim status response to an EDI 276 transaction.
276 transaction is a request for the status of a health care claim. It is submitted by a provider, a health care/services recipient, or an authorized agent (any of these could be the consumer of our APIs).
A 277 might be a solicited response or an unsolicited one, in which case you need to proactively use our API to check your mailbox for any new 277 claim responses. 277 files use the phrase X3 as the prefix in the file name for any 277 claim status response.
835 responses are claims remittance notifications letting the recipient know what the payer has approved and by what percentage coverage is approved for medical services. 835 files begin with the prefix R5. These files are returned in EDI format by default. You can open such files in JSON using our /835 API endpoint.
What information needs to go in the request header?
See API FAQs.
What does a typical Reports API request and response look like?
The core request does not send a request body, and simply queries for the entire contents of the customer's mailbox:
https://apigw.changehealthcare.com/medicalnetwork/reports/v2
The API returns a complete listing of all documents available to a customer:
```json
{
"reports": [
"X3000000.XX",
"R5000000.XY",
"R5000000.XX",
"X3000000.AB",
"X3000000.AC",
"X3000000.ZZ",
"R5000000.XZ",
"R5000000.YZ",
"R5000000.WA",
"R5000000.WB"
...
]
}
```
By appending the X3 or R5 filename to the request, you will see the X12 EDI contents of the file (the following is an example; your documents will show different information):
https://apigw.changehealthcare.com/medicalnetwork/reports/v2/R5000000.XZ
X12 EDI Contents Example
What does the filename structure mean?
The API returns a list of file names with the following structure:
AAnnnnnn.XX
where:
AA= the two-character prefix that designates the type of filennnnnn= the six-digit submitter IDXX= the two-character extension that separates files. Files begin with the prefix AA, AB, ACâŚ.A0, A1, A2âŚ..BA, BB, BCâŚ..ending with W9 before rolling back to AA (excluding the AU, BK, DB, DV, GI, GW, HT, JS, QT, RA, RP and WM prefixes as these are reserved).
The most common reports are the Claim Status Response (X3) and the Claim Remittance (R5). Electronic reports also exist to support all available transactions, including medical statements and Electronic Remittance Advice (ERA).
How does EDI to JSON translation work?
By appending an X3 or R5 filename to the request, you will see the X12 EDI contents of the file:
https://apigw.changehealthcare.com/medicalnetwork/reports/v2/R5000000.XZ
X12-EDI-Example
Add the 835 suffix to the path, and the API translates the same content to a more-readable JSON:
https://apigw.changehealthcare.com/medicalnetwork/reports/v2/R5000000.XZ/835
```JSON
{
"transactions": [
{
"detailInfo": [
{
"assignedNumber": "1",
"paymentInfo": [
{
"claimPaymentInfo": {
"claimFilingIndicatorCode": "12",
"claimFrequencyCode": "1",
"claimPaymentAmount": "500",
"claimStatusCode": "1",
"facilityTypeCode": "11",
"patientControlNumber": "5554555444",
"patientResponsibilityAmount": "300",
"payerClaimControlNumber": "94060555410000",
"totalClaimChargeAmount": "800"
},
"claimSupplementInformation":
(...)
```
What's the difference between Claim Status and Claim Responses and Reports?
These two APIs are complementary to one another.
Claim Status main task is to check the status of a claim in the payerâs system. If a provider has not received a payer report on a claim, or if they have not received payment, they can run a claim status request to find out the most recent state of that claim. When a claim is paid, the claim status response from the payer provides only basic payment details, and excludes the details such as payer adjustments to the total charge, the patient copays and coinsurance, and other payer adjudication details. It produces a status summary instead of a complete breakdown.
Claim Responses and Reports is a tool to fetch claims information files from your mailbox. You can get your complete claims adjudication results here. The Reports files provide deeper details on the payments for individual Service Lines, the individual amounts the payer agreed on for each, and all other relevant adjudication details.
For more information about the Claim Status API, see Claim Status API Reference and the Claim Status API.
How do I convert an EDI Reports file to JSON?
You specify the Report file in the request URL, including its two-letter extension, along with the correct endpoint type. The endpoint will always be either /277 or /835.
- Example using our sandbox test values:
https://apigw.changehealthcare.com/medicalnetwork/reports/v2/{filename}/277
The file, which is available in the sandbox API implementation, is for a relatively brief single-claim 277 claim status response.
```json
{
"transactions": [
{
"controlNumber": "0001",
"referenceIdentification": "000000001",
"transactionSetCreationDate": "20201201",
"transactionSetCreationTime": "120558",
"payers": [
{
"organizationName": "PREMERA",
"payerIdentification": "430",
"claimStatusTransactions": [
{
"provider": {
"organizationName": "CHC3",
"etin": "000000000"
},
"claimStatusDetails": [
{
"serviceProvider": {
"organizationName": "HAPPY DOCTORS GROUP",
"npi": "1111111111"
},
"patientClaimStatusDetails": [
{
"subscriber": {
"lastName": "DOEONE",
"firstName": "JOHNONE",
"memberId": "0000000000"
},
"claims": [
{
"claimStatus": {
"referencedTransactionTraceNumber": "000000001",
"informationClaimStatuses": [
{
"statusInformationEffectiveDate": "20200613",
"totalClaimChargeAmount": "100",
"claimPaymentAmount": "80",
"adjudicatedFinalizedDate": "20200609",
"remittanceDate": "20200613",
"remittanceTraceNumber": "1111111",
"informationStatuses": [
{
"healthCareClaimStatusCategoryCode": "F1",
"healthCareClaimStatusCategoryCodeValue": "Finalized/Payment-The claim/line has been paid.",
"statusCode": "65",
"statusCodeValue": "Claim/line has been paid."
}
]
}
],
"tradingPartnerClaimNumber": "AAAAAAAAAAA1",
"patientAccountNumber": "00000",
"clearinghouseTraceNumber": "111111111111111",
"claimServiceBeginDate": "20200214",
"claimServiceEndDate": "20200214"
},
"serviceLines": [
{
"service": {
"serviceIdQualifierCode": "HC",
"serviceIdQualifierCodeValue": "Health Care Financing Administration Common Procedural Coding System (HCPCS) Codes",
"procedureCode": "97161",
"procedureModifiers": [
"95"
],
"chargeAmount": "100",
"amountPaid": "80",
"submittedUnits": "1"
},
"serviceClaimStatuses": [
{
"effectiveDate": "20200613",
"serviceStatuses": [
{
"healthCareClaimStatusCategoryCode": "F1",
"healthCareClaimStatusCategoryCodeValue": "Finalized/Payment-The claim/line has been paid.",
"statusCode": "65",
"statusCodeValue": "Claim/line has been paid."
}
]
}
],
"beginServiceLineDate": "20200214",
"endServiceLineDate": "20200214"
}
]
}
]
}
]
}
]
}
]
...
```
The lengthy example is a completed record for a single claim in a multiple-claim report.
You can determine how many claims the current 277 file contains by looking for the following three JSON attributes in a group:
```json
"organizationName": "PREMERA",
"payerIdentification": "430",
"claimStatusTransactions": [
```
Each of these attributes is a complete claims entry in the transactions list.
What are the most important contents of the 277 and 835 Reports?
Key JSON attributes of any list of multiple payouts in an 835 report include the following:
| Attribute | Definition |
|---|---|
claimPaymentInfo | Multiple instances, each for a different patient claim, all of which are unique in the report. This line defines the beginning of each completed claim within the report. |
payee | One for each report. This is the provider or institution receiving the payments. |
payer | One medical insurance payer for each 835 report. Any single Reports file, no matter how many claim records in the transaction list, will have only one Payer. The Payer is unique for each file. |
serviceLines | Array containing all medical services rendered by the medical provider(s) for the individual patient in each claim. This is arranged just under the patientName and renderingProvider identifying information. Also watch the serviceDate attribute instances, which illustrate each individual procedure giving rise to medical service payment requests to the Payer in a claim. Each of these contain the insurance-adjusted payments agreed to by the Payer. |
Here is a somewhat typical serviceLines array record for a dental encounter:
```json
"serviceLines": [
{
"serviceDate": "20190313",
"servicePaymentInformation": {
"productOrServiceIDQualifier": "AD",
"productOrServiceIDQualifierValue": "American Dental Association Codes",
"adjudicatedProcedureCode": "D4342",
"lineItemChargeAmount": "125",
"lineItemProviderPaymentAmount": "0"
},
"serviceAdjustments": [
{
"claimAdjustmentGroupCode": "CO",
"claimAdjustmentGroupCodeValue": "Contractual Obligations",
"adjustmentReasonCode1": "45",
"adjustmentAmount1": "125"
}
]
},
{
"serviceDate": "20190313",
"servicePaymentInformation": {
"productOrServiceIDQualifier": "AD",
"productOrServiceIDQualifierValue": "American Dental Association Codes",
"adjudicatedProcedureCode": "D4381",
"lineItemChargeAmount": "43",
"lineItemProviderPaymentAmount": "0"
},
"serviceAdjustments": [
{
"claimAdjustmentGroupCode": "PR",
"claimAdjustmentGroupCodeValue": "Patient Responsibility",
"adjustmentReasonCode1": "3",
"adjustmentAmount1": "33"
},
{
"claimAdjustmentGroupCode": "CO",
"claimAdjustmentGroupCodeValue": "Contractual Obligations",
"adjustmentReasonCode1": "45",
"adjustmentAmount1": "10"
}
]
},
...
```
Each line item specifies whether the payer agrees to pay any cash for each line item. In the preceding example, the lineItemProviderPaymentAmount for each indicates that the provider did not apply any discounts or on-site payments towards the procedure. Each individual adjudicatedProcedureCode denotes the procedure line item. The 'serviceAdjustments` object describes the payment that the payer agrees to pay for each individual line item.
For 277 reports, look for the following
-
payers: One for each report. Any single 277 Reports file, regardless of how many claim records are in the transaction list, it will have only one Payer. The Payer is unique for each file. -
You can quickly determine how many claims the current 277 file contains by looking for the following three JSON attributes in a group:
```json
"organizationName": "PREMERA",
"payerIdentification": "430",
"claimStatusTransactions": [
```
Each of these sets of attributes is the beginning of a complete claim in the transactions list:
| Attribute | Definition |
|---|---|
claims | This attribute, which is a bit deeper into each claims record in a list of transactions, describes the completed state of the claim, including the totalClaimChargeAmount and the claimPaymentAmount along with the remittanceDate. |
serviceLines | As with 835s, the serviceLines objects describe the details of each procedure payment for the individual claims. Added up, the cumulative amounts in the serviceLines go into the totalClaimChargeAmount and the claimPaymentAmount along with other totals. |
Values in Common
Values, such as totalClaimChargeAmount and claimPaymentAmount are common to both types of reports.
Other than the X3 and R5 report types, what are the other report types and in what format is this data?
Here is a complete list of report types.
How many report names can the Claims Responses and Reports request include?
The report is generated by the Change Healthcare clearinghouse, there is no limit to how many report names can be shown.
When I tried to request a token to the Responses and Reports/Eligibility API, I get an invalid access token error even though I am using the same access token that I used for the Claim Status request. Invalid access token for Claim Responses and Reports/Eligibility 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 predefine 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.
I am working on a potential new project and I'm considering using Change Health's JSON format.
- Do you have this mapping in a non-web form? CSV, DB table ... etc?
No, we do not have this in a non-web form. We provide this as a reference point, but the final authority is the TR3 documentation.
- I am looking for mapping for 835s or 999s, do you have them?
Check out the Responses and Reports v2 API, this goes well with the claims API. The responses will be the 999 reports. There are reports to show an 835. The actual 835 file stays in the format received from the payer. We also offer assistance in the workflow for the responses and reports API when you are in implementation.
- Do you happen to have any tools for transforming X12 â Change Healthcare JSON and/or Change Healthcare JSON X12?
We do not have any tools to do this. You can send the X12 format through API and JSON.
How do we know that our claim has been forwarded to payer?
You can make Responses & Reports API requests. During implementation, we can provide additional recommendations on how to best use these reports and responses. Our ConnectCenter helps you view all your information.
I want to make multiple requests with different service types to completely get mental health providers their coverage. Is there a way to reduce the number of requests by clubbing the service types together? Any idea which payers allow that and which don't?
We do not know which payers allow more than one service type code. However, we recommend no more than two in a single request. All payers might not accept two, but two have worked for most.
Other than the X3 and R5 report types, what are the other report types and in what format is this data?
Here is a complete list of report types.
My client would be billing the clients for the visit, which is not a professional/specialist visit but more like evaluation and management services that come under CPT 99214. Other than serviceType 98, which other code can I use?
Include serviceType code 30 to pull back all benefit information.
So should I be running multiple requests for 98, MH, and A6 for each patient to get their complete eligibility? Is there a better combo of service type codes that can yield me the results with lesser number of requests per patient?
98, MH, and A6 are good; add 30.
Do you have any API which sends electronic remittance notices regarding payments?
Check out the responses and reports API section. We will also walk you through the best way to use these reports while you are in the implementation stage.
How to identify which reports concern which patients?
The primary reports you would be using should be the SD and SF reports. The mapping for these can be found here. The patientControlNumber submitted by you would appear on all reports, and should be used as the primary method of linking a report back to a claim.
Which report (277, 835) contains information about successful adjudication and denial? Should we check all the reports or check only files with prefixes X (277)or R (835)?
The R5 would be the report that specifically contains payment/denial information. Please see the Available Responses and Reports for processing the claims.
Instead of checking every file can we go with the R5 Prefix file because it contains detailed information regarding the claim?
We cannot advise you to only check the R5 file as you would be missing anything related to rejected claims by using only that. Please review our Available Responses and Reports for processing the claims.
Related Topics
Updated 29 days ago