Discrepancy in validation for Claim Creation having provider restricted to location

For requests or help with our API
Post Reply
avdhutkotkar
Posts: 8
Joined: Mon Sep 15, 2025 11:32 pm

Discrepancy in validation for Claim Creation having provider restricted to location

Post by avdhutkotkar »

Use case :
1. Practice has 2 clinics
2. A Provider is assigned to Clinic#1 and he is not assigned to Clinic#2
3. Procedure is created with Provider selected for Clinic#1.
3. Now that provider is used as Billing provider for a Claim. -> Claim is Sent
4. Now the assignment of the Clinic is changed for the Provider to Clinic#2
4. When deleting the claim and recreating with the the procedure created at step 3.

Through Open dental UI :
It is allowed to create a Claim for the existing procedure which is previously linked to provider and currently allocation is changed. Dropdowns don't show that provider anymore but existing entries stays as it is on top of that claim creation also successful with the provider linked to the procedure.

Through Open dental API :
POST api/v1/claims

{
"PatNum": 517,
"procNums": [9369, 9370],
"ClaimType": "P",
"ProvBill" : 10
}
Error :
"ProvBill is invalid. Provider is not associated with the procedure's clinic."

For existing data since the provider would have actually treated and completed the procedure. the UI behaviour looks correct. Please review this and have the behaviour consistent for the API as well?
RyanH
Posts: 69
Joined: Thu Dec 19, 2024 8:33 am

Re: Discrepancy in validation for Claim Creation having provider restricted to location

Post by RyanH »

avdhutkotkar wrote: Tue Sep 16, 2025 2:25 am Use case :
1. Practice has 2 clinics
2. A Provider is assigned to Clinic#1 and he is not assigned to Clinic#2
3. Procedure is created with Provider selected for Clinic#1.
3. Now that provider is used as Billing provider for a Claim. -> Claim is Sent
4. Now the assignment of the Clinic is changed for the Provider to Clinic#2
4. When deleting the claim and recreating with the the procedure created at step 3.

Through Open dental UI :
It is allowed to create a Claim for the existing procedure which is previously linked to provider and currently allocation is changed. Dropdowns don't show that provider anymore but existing entries stays as it is on top of that claim creation also successful with the provider linked to the procedure.

Through Open dental API :
POST api/v1/claims

{
"PatNum": 517,
"procNums": [9369, 9370],
"ClaimType": "P",
"ProvBill" : 10
}
Error :
"ProvBill is invalid. Provider is not associated with the procedure's clinic."

For existing data since the provider would have actually treated and completed the procedure. the UI behaviour looks correct. Please review this and have the behaviour consistent for the API as well?
Hello avdhutkotkar,

Thank you for the detailed post. There are different options within Open Dental that can set the default billing provider on a claim. Based on the behavior you described, it sounds like the clinic in which the procedure had been treated and completed at has clinic.InsBillingProv set to “Treating Provider” (-1 in the database).

Although it is possible in Open Dental to have a billing provider set for a claim that belongs to a different clinic, it’s only possible when the billing provider is defaulted, such as when you click ‘New Claim’ or ‘Primary’ in the UI. The API mirrors this behavior in Open Dental. The error message you are receiving is correct, as you cannot specify a billing provider that does not belong to the clinic of the procedure, just like you cannot use the drop-down menu to select this provider in the scenario described.

If you’d like to recreate this behavior via API, you must omit the ‘ProvBill’ field from the claim payload, which would result in the claim’s billing provider to be defaulted the same way that Open Dental would default it in the UI.

Thanks!
avdhutkotkar
Posts: 8
Joined: Mon Sep 15, 2025 11:32 pm

Re: Discrepancy in validation for Claim Creation having provider restricted to location

Post by avdhutkotkar »

Thank you this indeed resolved our issue to work with this claim.
Post Reply