API & Services Connection™
Request Sandbox AccessMarketplaceApp RegistryCommunity

Professional Claims FAQs

Suggest Edits

📘

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. To access them for testing, you can use the Postman tool or your own API console. The best way to investigate our APIs is through our sandbox, which enables you to test our APIs without sending an actual claim to your payer.
.

  • Use the /professionalclaims/v3/validation endpoint to check your request: 
https://apigw.changehealthcare.com/medicalnetwork/professionalclaims/v3/validation

Validation 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.

  • Use the /professionalclaims/v3/submission endpoint to submit your professional claim transaction to the payer:
https://apigw.changehealthcare.com/medicalnetwork/professionalclaims/v3/submission

📘

NOTE

The /validation and /submission endpoints use the same request model. Avoid sending any claim 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 HTTPS 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 following JSON objects:

JSON ObjectDescription
submitterProvider submitting the claim.
receiverPayer.
subscriberMedical insurance policy holder.
dependentDependent of the insurance policyholder receiving the care.
providersList of one or more providers involved in the medical care.
claimInformationComplete breakdown of the medical encounter and its associated charges.
serviceLines and serviceDateserviceLines 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

FieldsDescription
correlationIdID used by the support team to locate a transaction at the clearinghouse.
submitterIdCustomer's combined biller ID and submitter ID.
customerClaimNumberID set by the customer in the claim.
patientControlNumberID set by the customer in the claim for the patient.
timeOfResponseTimestamp for the response.
claimTypeType of claim, Professional or Institutional.
formatVersionEDI format version, will always be 5010 for the current version of the 837 claim.
rhclaimNumberNumber assigned by the clearinghouse. This value appears to search for the claim in ConnectCenter.

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 cache/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.

Updated 24 days ago