Professional Claims FAQs
NOTE
Please see API FAQs 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 APIs.
NOTE
Medicare payers accept claims only for subscribers. If you want to submit a dependent claim with a Medicare payer, submit the dependent as a subscriber in the claim request.
How do I access the Professional Claims APIs?
Providers use the Professional Claims APIs to submit their medical procedure claims to their payers.
- API environments](doc:testing-environments)
- Try our APIs
- API URLs and endpoints
- Use the
/professionalclaims/v3/validation
endpoint to check your request:
The /validation
endpoint does not send your transaction to the payer. It checks for the correct well-formed syntax of your submission. It does not check the accuracy of the information included in your submission, so you must separately ensure that the claim is complete and accurate before submission.
NOTE
The
/validation
and/submission
endpoints use the same request model. Avoid sending any claims until you have tested your submission process and validated your claim!
What information goes in the API Request header?
See API request header information.
How do I check the Operating Status of the API?
Change Healthcare's /professionalclaims/v3/healthcheck
endpoint checks the operating status of the Professional Claims API engine. See API Health Check.
Do you have a sandbox that I can test with before signing a contract?
Yes, we do. See API FAQ and API environments.
What does a typical Professional Claims API request look like?
The Professional Claims API uses a POST
request. Responses to our Medical Network APIs can be lengthy due to the many data points that a payer or trading partner provides in the query response. Professional claims can have up to fifty line items (Loop 2400) in the claimInformation
object (Loop 2300 in the EDI spec), each of which, reflects payer decisions on payment.
Our APIs translate back-and-forth between JSON and X12 EDI when the information departs into and returns from the medical network. All fields and JSON objects conform to the EDI 837p transaction standard.
Professional Claims API request example
The following example is quite brief compared to what can apply in a real-world transaction.
```javascript
POST ${api_basepath}/[validation|submission] HTTP/1.1
Host: ${apigee_host}
Authorization:Bearer <Your-Access-Token>
Content-Type: application/json
{
"controlNumber": "000000001",
"tradingPartnerServiceId": "9496",
"submitter": {
"organizationName": "REGIONAL PPO NETWORK",
"contactInformation": {
"name": "SUBMITTER CONTACT INFO",
"phoneNumber": "123456789"
}
},
"receiver": {
"organizationName": "EXTRA HEALTHY INSURANCE"
},
"subscriber": {
"memberId": "0000000001",
"paymentResponsibilityLevelCode": "P",
"firstName": "johnone",
"lastName": "doeOne",
"gender": "M",
"dateOfBirth": "19800102",
"policyNumber": "00001",
"address": {
"address1": "123 address1",
"city": "city1",
"state": "wa",
"postalCode": "981010000"
}
},
"dependent": {
"memberId": "0000000002",
"paymentResponsibilityLevelCode": "P",
"firstName": "janeone",
"lastName": "doeOne",
"gender": "F",
"dateOfBirth": "19800102",
"policyNumber": "00002",
"relationshipToSubscriberCode": "01",
"address": {
"address1": "123 address1",
"city": "city1",
"state": "wa",
"postalCode": "981010000"
}
},
"providers": [{
"providerType": "BillingProvider",
"npi": "1760854442",
"employerId": "123456789",
"organizationName": "HAPPY DOCTORS GROUPPRACTICE",
"address": {
"address1": "000 address1",
"city": "city2",
"state": "tn",
"postalCode": "372030000"
},
"contactInformation": {
"name": "janetwo doetwo",
"phoneNumber": "0000000001"
}
},{
"providerType": "ReferringProvider",
"npi": "1942788757",
"firstName": "johntwo",
"lastName": "doetwo",
"employerId" : "123456"
},{
"providerType": "RenderingProvider",
"npi": "1942788757",
"firstName": "janetwo",
"lastName": "doetwo",
"middleName": "middletwo",
"ssn" : "000000000"
}],
"claimInformation": {
"claimFilingCode": "CI",
"patientControlNumber": "12345",
"claimChargeAmount": "28.75",
"placeOfServiceCode": "11",
"claimFrequencyCode": "1",
"signatureIndicator": "Y",
"planParticipationCode": "A",
"benefitsAssignmentCertificationIndicator": "Y",
"releaseInformationCode": "Y",
"claimSupplementalInformation": {
"repricedClaimNumber": "00001",
"claimNumber": "12345"
},
"healthCareCodeInformation": [{
"diagnosisTypeCode": "ABK",
"diagnosisCode": "S93401A"
},{
"diagnosisTypeCode": "ABF",
"diagnosisCode": "S72044G"
}],
"serviceFacilityLocation": {
"organizationName": "HAPPY DOCTORS GROUP",
"address": {
"address1": "000 address1",
"city": "city2",
"state": "tn",
"postalCode": "372030000"
}
},
"serviceLines":[ {
"serviceDate": "20180514",
"professionalService": {
"procedureIdentifier": "HC",
"lineItemChargeAmount": "25",
"procedureCode": "E0570",
"measurementUnit": "UN",
"serviceUnitCount": "1",
"compositeDiagnosisCodePointers": {
"diagnosisCodePointers": ["1","2"]
}
}
},
{
"serviceDate": "20180514",
"professionalService": {
"procedureIdentifier": "HC",
"lineItemChargeAmount": "3.75",
"procedureCode": "A7003",
"measurementUnit": "UN",
"serviceUnitCount": "1",
"compositeDiagnosisCodePointers": {
"diagnosisCodePointers": ["1" ]
}
}
}
]
}
}
```
Example Claim JSON objects
As shown below, the sample claim contains the JSON objects:
JSON Object | Description |
---|---|
submitter | Provider submitting the claim. |
receiver | Payer. |
subscriber | Medical insurance policy holder. |
dependent | Dependent of the insurance policyholder receiving the care. |
providers | List of one or more providers involved in the medical care. |
claimInformation | Complete breakdown of the medical encounter and its associated charges. |
serviceLines and serviceDate | serviceLines is an array of one or more medical services, procedures, or products for the encounter each of which, is specified as a serviceDate record in the array. |
What do Professional Claims Validation API responses look like?
A successful validation of a professional claim gives a response similar to the following:
```json
{
"status": "SUCCESS",
"controlNumber": "000000001",
"tradingPartnerServiceId": "9496",
"claimReference": {
"correlationId": "201210R999898~2014364838718969",
"submitterId": "009998999898",
"customerClaimNumber": "000000001",
"patientControlNumber": "12345",
"timeOfResponse": "2020-12-10T20:07:05.4-06:00",
"claimType": "PRO",
"formatVersion": "5010"
}
}
```
After the API validates the claim, it is ready to submit to the payer unless you want to make further changes and run the checks.
What is the claimReference field in the Submission response?
The claimReference
field is an object containing the list of identifiers that you can use to track a claim. If questions arise about a claim, you can provide the information listed in the claimReference
object to Change Healthcare support for troubleshooting purposes. It appears in all submission responses for claims. The list of identifiers may differ depending on the context for the response.
```json
{
"status": "SUCCESS",
"controlNumber": "000000001",
"tradingPartnerServiceId": "9496",
"claimReference": {
"correlationId": "201113R999898~2634061369394033",
"submitterId": "009998999898",
"customerClaimNumber": "000000001",
"patientControlNumber": "12345",
"timeOfResponse": "2020-11-13T09:30:33.29-06:00",
"claimType": "PRO",
"formatVersion": "5010",
"rhclaimNumber": "2031851503057"
}
}
```
claimReference
object fields
claimReference
object fieldsFields | Description |
---|---|
correlationId | ID used by the support team to locate a transaction at the clearinghouse. |
submitterId | Customer's combined biller ID and submitter ID. |
customerClaimNumber | ID set by the customer in the claim. |
patientControlNumber | ID set by the customer in the claim for the patient. |
timeOfResponse | Timestamp for the response. |
claimType | Type of claim, Professional or Institutional. |
formatVersion | EDI format version, will always be 5010 for the current version of the 837 claim. |
rhclaimNumber | Number assigned by the clearinghouse. This value appears to search for the claim in ConnectCenter. |
If the Primary claims are sent electronically, will the Secondary/Tertiary claims be sent electronically as well all the time?
For the secondary claim to be paid electronically, the primary payer must accept secondary claim.
These payers can be reviewed in the Change Healthcare [Payer Finder tool](https://payerfinder.changehealthcare.com/npd or https://payerfinder.changehealthcare.com/cap). The āAccepts Secondaryā column is not automatically displayed.
- Click the gear (highlighted below) at the top-right of the list.

Payer Finder Tool
- From the menu that shows, select the Accepts Secondary checkbox.

Column Settings
- Save your settings.
This will display an additional column. Those with a āYā designation, accept secondary claims.
However, the secondary payer must also process claims electronically and the appropriate payer ID must be included within the claim for the process to be fully electronic.
Do you bill for a failed claim due to technical error?
Every transaction that makes it to the clearinghouse is billable. All errors at the API level, and some errors at the ingress of the clearinghouse, are considered non-billable.
What's the difference between a Professional claim and an Institutional 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 billing also sometimes encompasses collections while professional claims and billing typically 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.
A provider has two different teams; one enters the claim and the other verifies and submits it. Before submitting, can they enter the claim, save it and have it released when ready?
Our APIs do not have a caching/drafting feature. Customers can develop and automate this feature. Customers should hold the claims at their end, and programmatically set up a console to separate working on claims from submitting them.
How many line items can be on a single claim?
A single professional claim supports up to 50 service line items (serviceLine).
Are there guidelines for predicting the rate of unique claims submitted for a practice?
Rates of unique claims are isolated to each individual provider. Every provider is different. Whenever you render a medical service, file a claim.
Where can we include the information about the primary claim on the API request for the secondary claim?
Send any payer-specific information in the otherPayerName object. Use otherSubscriberInformation to convey details for the member specifically. For more information see.
Are there any other fields in the request body to be aware of?
Yes, see request contents.
If I wanted to send an EOB from the primary payer with the claim, how would I go about doing that?
Secondary claim information goes in to loop 2320. We do not have any documentation on what is required for secondary claims since that is a billing-specific question. Also, if you want to send the EOB to the payer you need to work with them directly to determine how you want those submitted. To learn more about Billing or Invoice Assistance, check out the last page of the Support & Escalation Guide.
What would be the correct co-insurance amount for Professional (Physician) Visit ā Office, for example, for Professional (Physician) Visit ā Office but one says 0% and the other says 10%?
serviceTypes: Professional (Physician) Visit ā Office is the correct amount. The other serviceType codes are not Professional Visit and would have a higher % based on that payer's response.
Why is the Claim Submission API is giving 400 error for the test values?
Error 400 means, there is a missing or invalid data or parameters in the request. Here is a listing of HTTP error responses.
Can we make multiple claims in one API call? If so, which endpoint should we use?
This is not possible through the current APIs. Only single submission is allowed. You can submit batch through SFTP but the batch file would need to be in X12 formats. Here is documentation that describes the available reports.
I am developing an application that will replace the old paper forms and start using the Professional Claim API. I cannot find the Prior Authorization Number.
- Open the Professional Claims OpenAPI spec.
- Do a Ctrl + F and search for priorAuthoriationNumber (under ClaimSupplementalInformation) in the spec shown as below.
"priorAuthorizationNumber":{"type":"string","description":"Loop: 2300, Segment: REF, Element: REF02 and REF01=G1"}
I sometimes get back errors from the payer like: "Loop 2310B (rendering provider name) is missing, it is expected to be used when loop 2420A is used with the same value in every loop 2400". How can I send the rendering provider in loop 2310B?
See Provider object.
For EDI claims, where can I put the session times in Loop 2400 for each individual line in the claim request when using the claims API?
In the developers portal's JSON-to-EDI mapping, scroll down to Loop 2400 to view different SV segments.
How to avoid the error "OTHER PAYER PRIMARY ID# IS MISSING OR INVALID" when the other payer doesn't have a payor ID and for which the claims are set up to be sent by paper?
The CPID for paper claims are listed here:
Professional 1500 form (Medical Claims):
- Commercial CPID 4320
- Medicaid CPID 4322
- BCBS CPID 4323
Institutional UB-04 form (Hospital Claims):
- Commercial CPID 4350
- Medicaid CPID 4352
- BCBS CPID 4353
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 (https://payerfinder.changehealthcare.com/npd or https://payerfinder.changehealthcare.com/cap). 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.
My client would be billing her 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 98 (Professional physician visit-office), any other code I can use?
Include service type code 30 to pull back all benefit information.
What is the Claim submission Flow in Change Healthcare?
Please see Claim Submission Workflow.
Do we need to use same control ID for a claim in submission and checking its claim status?
The controlNumber should be unique for each individual submission.
How can I add modifiers to the services/procedures/other codes of a claim? How can you express that a CPT code had to be added to a claim so that the payer haver sufficient support or their adjudication?
The following are the mapping for submitting modifiers. In an instance where a code needs to be added to a claim, a corrected claim should be submitted. This would require the claim frequency code '7' to be submitted, and the payer claim control number must be included on the claim in the claimControlNumber
field in the claimSupplementalInformation
. The claimControlNumber
is the number assigned by the payer to identify a claim. Once submitted, payers will review the claim and make any changes based on their internal review.
ProfessionalService:
required:
- compositeDiagnosisCodePointers
- lineItemChargeAmount
- measurementUnit
- procedureCode
- procedureIdentifier
- serviceUnitCount
type: object
properties:
procedureIdentifier:
type: string
description: >-
Loop: 2400, Segment: SV1, Element: SV101-01, Notes: Allowed Values are:
- 'ER' Jurisdiction Specific Procedure and Supply Codes,
- 'HC' Health Care Financing Administration Common Procedural Coding System
(HCPCS) Codes, 'IV' Home Infusion EDI Coalition (HIEC) Product/Service Code,'WK' Advanced Billing Concepts (ABC) Codes
example: HC
enum:
- ER
- HC
- IV
- WK
procedureCode:
- type: string
- description: 'Loop 2400, Segment: SV1, Element: SV101-02'
- example: E0570
procedureModifiers:
- maxItems: 4
- minItems: 0
- type: array
- description: >-
Loop 2400, Segment: SV1, Elements: SV101-03 to SV101-06, Notes:
Required when modifier clarifies or improves the reporting accuracy
of the associated procedure code. If not required then do not send
items:
- type: string
description:
- type: string
- description: >-
Loop 2400, Segment: SV1, Element: SV101-07, Notes: A free form
description to clarify teh related data elements and their content
Can the modifier code be added to the first submission or I need to submit another claim with frequency code 7, just to add the modifier?
We are not able to say if a code would be 'required'; it will vary payer-to-payer. However, you can add a modifier to the initial claim in the professionalService
object from the Professional Claims JSON to EDI Mapping Guide's procedureModifier.
Provide the source to obtain the master list related to CMS1500/UB04 Claims forms.
A 1500 is a medical claim (Professional) and UB04 is hospital claim (Institutional). And 837P is a 1500 Medical Claims and 837I is a UB04 Hospital claims. When paper is sent, they use a 1500 form for Medical claims and UB04 for Hospital. Change Healthcare does not have a master list of information. The information is common across the medical industry and there are many crosswalks or sites you can find that map the paper claim locations to a 837.
Related Topics
Updated 4 days ago