Integrated Rules Professional FAQs
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 APIs.
The Integrated Rules Professional API /professionalclaims/advanced/v1/validation endpoint is an enabling tool for making complex provider claims more accurate, and more likely to be accepted and adjudicated by the payer.
NOTE
The Change Healthcare Integrated Rules Professional API requires the use of the Professional Claims API for submission of claims to the payer. If you have another workflow for claims submissions, you may use that instead.
What does a typical Integrated Rules Professional API call look like?
The input is a complete professional claim that you submit as the request body, as you would with a standard professional claim submission:
```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": "BK",
"diagnosisCode": "496"
},{
"diagnosisTypeCode": "BF",
"diagnosisCode": "25000"
}],
"serviceFacilityLocation": {
"organizationName": "HAPPY DOCTORS GROUP",
"address": {
"address1": "000 address1",
"city": "city2",
"state": "tn",
"postalCode": "372030000"
}
},
"serviceLines":[ {
"serviceDate": "20050514",
"professionalService": {
"procedureIdentifier": "HC",
"lineItemChargeAmount": "25",
"procedureCode": "E0570",
"measurementUnit": "UN",
"serviceUnitCount": "1",
"compositeDiagnosisCodePointers": {
"diagnosisCodePointers": ["1","2"]
}
}
},
{
"serviceDate": "20050514",
"professionalService": {
"procedureIdentifier": "HC",
"lineItemChargeAmount": "3.75",
"procedureCode": "A7003",
"measurementUnit": "UN",
"serviceUnitCount": "1",
"compositeDiagnosisCodePointers": {
"diagnosisCodePointers": ["1" ]
}
}
}
]
}
}
```
What does an Integrated Rules Professional API response look like?
After the Integrated Rules Professional /professionalclaims/advanced/v1/validation endpoint successfully evaluates a professional claim, you will get a summary message stating so, with core claim reference information and a Metadata for troubleshooting:
Integrated Rules Professional API response example
```json
{
"status": "SUCCESS",
"controlNumber": "000000001",
"tradingPartnerServiceId": "9496",
"claimReference": {
"correlationId": "200925R639534~847432178458572",
"submitterId": "395795639534",
"customerClaimNumber": "000000001",
"patientControlNumber": "12345",
"timeOfResponse": "2020-09-25T18:13:48.136-05:00",
"claimType": "PRO",
"formatVersion": "5010"
},
"meta": {
"submitterId": "999898",
"senderId": "Xxxx.Xxxxxx",
"billerId": "009998",
"traceId": "900773a9-c0ba-6aa2-0f61-cfcc30a0200f",
"applicationMode": "pro"
}
}
```
Validation API issues in the claim evaluation example
When the validation API encounters issues in the claim evaluation, it will list each in the reply:
```json
{
"status": "EDITS",
"controlNumber": "000000001",
"tradingPartnerServiceId": "9496",
"claimReference": {
"correlationId": "201117R999898~53196482361992277",
"submitterId": "009998999898",
"customerClaimNumber": "000000001",
"patientControlNumber": "12345",
"timeOfResponse": "2020-11-17T17:46:02.792-06:00",
"claimType": "INS"
"formatVersion": "5010"
},
"errors": [
{
"field": "01",
"value": "1",
"description": "The Type of Admission is required and must be valid.\n\nLOOP 2300 CL101",
"location": "2300 CL1"
},
{
"field": "claimInformation.otherSubscriberInformation.validIndividualRelationshipCode",
"description": "Allowed Values are: '01' Spouse, '18' Self, '19' Child, '20' Employee, '21' Unknown, '39' Organ Donor, '40' Cadaver Donor, '53' Life Partner, 'G8' Other Relationship"
}
]
}
```
Some error listings will also show the EDI loop and element in which the error occurred. Most error listings will also show the EDI loop and element in which the error occurred. The example here shows that the admissionTypeCode in Loop 2300, Element CL101, has an incorrect value and must contain one of the values specified in the correction text. For more information, see Error types in Professional claims.
How do I submit my edited claims?
The Integrated Rules Professional API performs advanced rules-based checking and validation of Professional claims based on the X12 EDI 837p standard. It uses compilations of medical business specialties, called Knowledge Packs, for fine-tuned claim inspection. It does not submit your claim to the payer, and is designed to be complementary to the Professional Claims API /professionalclaims/advanced/v1/validation endpoint.
- You can submit your completed claims to the payer through the standard Professional Claims Submission API (this will incur an additional charge):
https://apigw.changehealthcare.com/medicalnetwork/professionalclaims/v3/submission
- You may use the following endpoint to check and validate your upcoming submission. It applies a different and simpler set of rules that do not affect or repeat the functions from the Integrated Rules Professional API.
https://developers.changehealthcare.com/api/Professional-Claims/v3
Your transaction will not be sent to the payer:
https://apigw.changehealthcare.com/medicalnetwork/professionalclaims/v3/validation
If you use a different claim submission workflow, you can also submit your claim that way. Consult your Change Healthcare representative for more information.
How do Raw-X12 Validation requests and responses work?
See API FAQ.
What is the biggest value-add from using the Integrated Rules Institutional API?
For all Integrated Rules Institutional API applications, be familiar with the term Edits, which has a specific meaning in this context.
Payers control their own claims edit specifications. Edit specifications govern how medical practices must submit correct claims information for payer processing and claim adjudication. Claims Edits can change at any time, and these changes may or may not reach you before you submit an institutional claim, much less be integrated into your claims submission software.
Because of this likelihood, you may encounter unexpected errors and incur delays when filing claims, even when you think your software and processes are up to date.
These issues can occur at any time. Some medical practices may subscribe to continuous payer updates and submission edits. They receive their Claim edits notifications from the payer. Others may not do so, finding the costs prohibitive. The Integrated Rules Services team monitors regulatory requirements from Medicare and from industry organizations of many different types, and develops the Integrated Rules Knowledge Packs based upon the Packs' medical disciplines and the Rules/Edits that apply to them.
We continuously track and follow the Rules/Edits changes so you do not have to. Using the Knowledge Packs that you order as a match for your business, we tailor your Institutional Claims Integrated Rules API to your specific needs.
Knowledge packs for Institutional Claims
Currently available Knowledge Packs for Institutional Claims include the following:
- General Billing
- Ambulance
- Dialysis/End Stage Renal Disease (ESRD) (Institutional claims only)
- Medicare
- Post Acute Care
- Prior Authorization
- Institutional claims from Rural Health Clinics and Federally Qualified Health Centers (Rural FQHC)
- Medical Necessity
- National Correct Coding Initiative (NCCI)
- Therapy (Institutional claims with Therapy Revenue Code, HCPCS/CPT-4 codes)
- Validation Codes
Providers of each of the various Edit/Rule types select the Knowledge Packs that fits their needs. Rules within each category also may apply to specific Payers. For example, rules within the Durable Medical Equipment pack may be applicable for Aetna or for Medicare.
Another benefit: not all fields in an Institutional Claim request will be applicable for every service. A single claim may be a very substantial request body. Our Rules and Knowledge Packs enable you to narrow your claims down to the bodies of information that are only necessary for your claim type.
Edits are directly comparable to individual validation rules in our API, hence we use the term Integrated Rules for our API.
The majority of Integrated Rules Claims Edit categories support both Professional and Institutional claims. Some Edit/Rule categories are supported only through Institutional claims; others are supported only by Professional claims and hence are not listed here.
Does your API support HIPAA Validations?
Our Institutional Claims Integrated Rules EDI supports the following Edit Types and compliance checking for HIPAA Types 1 through 7:
| HIPAA Type | Description |
|---|---|
| Type 1 EDI Standard Integrity Testing | Validate basic syntactical integrity of the EDI submission. |
| Type 2 HIPAA Implementation Guide Requirement Testing | Validate HIPAA requirement-guide-specific syntax requirement by checking limits on repeat counts, used or not used qualifiers, code, elements, and segments. |
| Type 3 HIPAA Balance Testing | Validate that claim line items amounts are equal to total claim amount. |
| Type 4 HIPAA Inter-Segment Situation Testing | Validate inter-segment relationship. For example, if element A exists, element B must be populated. |
| Type 5 HIPAA External Code Set Testing | Validate specific code set values for HIPAA standards. |
| Type 6 Product Type/Type of Service Testing | Validate that segments that differ based on certain Healthcare services are properly created and processed. |
| Type 7 Trading Partner-Specific Testing | Compliance with payer specific requirement. |
What do Integrated Rules Institutional submissions look like?
The Integrated Rules Institutional API uses the POST request. You simply submit the institutional claim to the Integrated Rules API. It goes to work on your claim data, using the Knowledge Packs you have chosen for your account. It does not submit your claim to the payer. Institutional claims can contain up to 999 service line entries, so using the Integrated Rules API can be very helpful in this context.
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 837i transaction standard.
Integrated Rules Institutional submission example
The following example is quite brief compared to what can apply in a real-world transaction.
```javascript
POST https://apigw.changehealthcare.com/medicalnetwork/institutionalclaims/v1/[validation|submission] HTTP/1.1
Host: ${apigee_host}
Authorization:Bearer <Your-Access-Token>
Content-Type: application/json
{
"controlNumber": "000000001",
"tradingPartnerServiceId": "9496",
"submitter" : {
"organizationName" : "happy doctors group",
"taxId":"12345",
"contactInformation": {
"name": "janetwo doetwo",
"phoneNumber": "123456789",
"email": "[email protected]",
"faxNumber": "123456789"
}
},
"receiver": {
"organizationName": "EXTRA HEALTHY INSURANCE",
"taxId":"67890"
},
"subscriber" : {
"memberId": "0000000001",
"paymentResponsibilityLevelCode": "P",
"firstName": "johnOne",
"lastName": "doeOne",
"gender": "M",
"dateOfBirth": "19800101",
"address": {
"address1": "123 address1",
"city": "city1",
"state": "wa",
"postalCode": "981010000"
}
},
"providers": [{
"providerType": "BillingProvider",
"npi": "1760854442",
"employerId": "123456789",
"organizationName": "HAPPY DOCTORS GROUPPRACTICE",
"address": {
"address1": "123 address1",
"city": "city1",
"state": "wa",
"postalCode": "981010000"
}
}],
"claimInformation" : {
"claimFilingCode": "CI",
"patientControlNumber": "12345",
"claimChargeAmount": "3.75",
"placeOfServiceCode": "11",
"claimFrequencyCode": "1",
"signatureIndicator": "Y",
"planParticipationCode": "A",
"releaseInformationCode": "Y",
"benefitsAssignmentCertificationIndicator": "Y",
"billingNote":"ADD",
"claimDateInformation": {
"statementBeginDate": "20181209",
"statementEndDate": "20181214",
"dischargeHour":"1130",
"admissionDateAndHour": "201810131242"
},
"claimCodeInformation": {
"admissionTypeCode": "1",
"patientStatusCode": "10",
"admissionSourceCode": "7"
},
"serviceLines":[{
"assignedNumber": "1",
"institutionalService": {
"serviceLineRevenueCode": "1",
"lineItemChargeAmount": "72.50",
"measurementUnit": "UN",
"serviceUnitCount": "1"
}
}],
"principalDiagnosis": {
"qualifierCode": "ABK",
"principalDiagnosisCode": "S93401A",
"presentOnAdmissionIndicator": "Y"
},
"admittingDiagnosis":{"qualifierCode": "ABJ",
"admittingDiagnosisCode": "S93401A"
},
"otherSubscriberInformation": {
"paymentResponsibilityLevelCode": "A",
"individualRelationshipCode": "19",
"benefitsAssignmentCertificationIndicator": "Y",
"claimFilingIndicatorCode": "11",
"releaseOfInformationCode": "Y",
"otherPayerName":{
"otherPayerOrganizationName": "ABC Insurance Co",
"otherPayerIdentifierTypeCode": "PI",
"otherPayerIdentifier": "11122333"
},
"otherSubscriberName": {
"otherInsuredQualifier": "1",
"otherInsuredLastName": "DOE",
"otherInsuredIdentifierTypeCode": "MI",
"otherInsuredIdentifier": "123456"
}
}
}
}
```
What does a typical Integrated Rules Institutional API response look like?
After the Integrated Rules Institutional /institutionalclaims/advanced/v1/validation endpoint successfully evaluates an institutional claim, you will get a summary message stating so, with core claim reference information see claim reference](doc:professional-claims-integrated-rules-faq#claim-reference-information) and a Metadata for troubleshooting.
Response example
```json
{
"status": "SUCCESS",
"controlNumber": "000000001",
"tradingPartnerServiceId": "9496",
"claimReference": {
"correlationId": "200925R639534~847432178458572",
"submitterId": "395795639534",
"customerClaimNumber": "000000001",
"patientControlNumber": "12345",
"timeOfResponse": "2020-09-25T18:13:48.136-05:00",
"claimType": "INS",
"formatVersion": "5010"
},
"meta": {
"submitterId": "999898",
"senderId": "Xxxx.Xxxxxx",
"billerId": "009998",
"traceId": "900773a9-c0ba-6aa2-0f61-cfcc30a0200f",
"applicationMode": "pro"
}
}
```
Validation API issue
When the validation API encounters issues, it will list each in the reply:
```json
{
"status": "EDITS",
"controlNumber": "000000001",
"tradingPartnerServiceId": "9496",
"claimReference": {
"correlationId": "201117R999898~53196482361992277",
"submitterId": "009998999898",
"customerClaimNumber": "000000001",
"patientControlNumber": "12345",
"timeOfResponse": "2020-11-17T17:46:02.792-06:00",
"claimType": "INS"
"formatVersion": "5010"
},
"errors": [
{
"field": "01",
"value": "1",
"description": "The Type of Admission is required and must be valid.\n\nLOOP 2300 CL101",
"location": "2300 CL1"
},
{
"field": "claimInformation.otherSubscriberInformation.IndividualRelationshipCode",
"description": "Allowed Values are: '01' Spouse, '18' Self, '19' Child, '20' Employee, '21' Unknown, '39' Organ Donor, '40' Cadaver Donor, '53' Life Partner, 'G8' Other Relationship"
}
]
}
```
Most error listings will also show the EDI loop and element in which the error occurred. The example here shows that the admissionTypeCode in Loop 2300, Element CL101, has an incorrect value and must contain one of the values specified in the correction text. For more information, see Error messages in Institutional claims.
Claim Reference information
The claimReference object contains a number of tracking values. You can expect to see results similar to the following:
| JSON Response Object | Description |
|---|---|
json { "status": "SUCCESS", "controlNumber": "000000001", "tradingPartnerServiceId": "9496", "claimReference": { "correlationId": "210322R999898~66684261175841", "submitterId": "009998", "customerClaimNumber": "000000001", "patientControlNumber": "12345", "timeOfResponse": "2021-03-22T19:34:08.85-05:00", "claimType": "PRO", "formatVersion": "5010", "rhclaimNumber": "2108151508527" }, [meta object here] }, "editStatus": "SUCCESS", "payer": { "payerName": "Unknown", "payerID": "9496" }, | The first response you get back from the clearinghouse does not indicate whether the claim is being paid; it indicates that the clearinghouse has accepted the claim and is getting ready to forward it to the payer.claimReference is the response's main object.Key values include the following: customerClaimNumber: An additional claim tracking number assigned by the Change Healthcare clearinghouse:
|
How do Raw-X12 Validation requests and responses work?
You can use the Integrated Rules Institutional /advanced/v1/raw-x12-validation endpoint to validate your EDI request:
https://sandbox.apigw.changehealthcare.com/medicalnetwork/institutionalclaims/advanced/v1/raw-x12-validation
Your transaction will not be sent to the payer. A sample request appears in EDI format:
```javascript
{"x12": "ISA*00* *01*CYCTRANS *ZZ*009998999898 *ZZ*CLAIMSCH *200723*1401*|*00501*000000001*0*T*:~GS*HC*009998999898*1465*20200723*1401*000000001*X*005010X223A3~ST*837*000000001*005010X223A3~BHT*0019*00*000000001*20200723*1401*CH~NM1*41*2*happy doctors group*****46*009998999898~PER*IC*janetwo doetwo*EM*[email protected]~NM1*40*2*EXTRA HEALTHY INSURANCE*****46*CLAIMSCH~HL*1**20*1~NM1*85*2*HAPPY HOSPITAL CHAIN*****XX*1760854442~N3*123 address1~N4*city1*wa*981010000~REF*EI*123456789~HL*2*1*22*0~SBR*P*18*******CI~NM1*IL*1*doeOne*johnOne****MI*0000000001~N3*123 address1~N4*city1*wa*981010000~DMG*D8*19800101*M~NM1*PR*2*EXTRA HEALTHY INSURANCE*****PI*9496~CLM*12345*3.75***11:A:1**A*Y*Y~DTP*096*TM*1130~DTP*434*RD8*20041209-20041214~DTP*435*DT*200410131242~CL1*1*7*10~NTE*ADD*ADD~HI*BK:99761:::::::Y~HI*BJ:99762~SBR*A*19*******11~OI***Y***Y~NM1*IL*1*DOE*****MI*123456~NM1*PR*2*ABC Insurance Co*****PI*11122333~LX*1~SV2*1**72.50*UN*1~SE*32*000000001~GE*1*000000001~IEA*1*000000001~"}
```
Both JSON and EDI endpoints use the same API request model with the same sets of attributes.
Your responses for this API are returned in JSON format, including any errors that the API engine discovers.
NOTE
When your EDI formatted request is corrected and validated, use your normal claim submission workflow to submit the claim. The Institutional Claims v1 API does not directly support X12 EDI submissions.
What's the difference between the Integrated Rules API and the regular Institutional Claims API?
The standard /institutionalclaims/v1/validation endpoint uses a separate set of rules and logic for scrubbing an institutional claim, and is automatically applicable across a range of institutional specialties. The Integrated Rules Institutional API provides greater specialization through the selection of Knowledge Packs to support your provider's medical specialties. It can be considered complementary to the standard Institutional Claims API.
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. People handling Professional claims typically understand both billing and insurance coding. Our APIs help support and automate insurance coding.
What's the difference between standard Professional Claims API and the regular Integrated Rules Professional Claims API?
The standard /professionalclaims/v3/validation endpoint uses a separate set of rules and logic for scrubbing a professional claim, and is applicable across a range of professional specialties. The Integrated Rules Professional API provides greater specialization through the selection of Knowledge Packs to support your provider's medical specialties.
Related Topics
Updated 3 months ago