Secondary Claim Status Update

[ajaykodam]

When a patient has both Primary and Secondary insurance, the Secondary Claim remains in the status “Hold until Primary Received.”
Currently, when we post a payment for the Primary Claim using the endpoint, the payment gets posted, and we have to find and change the status of the secondary claim with additional API calls:

Code: Select all

POST /claimpayments/Batch
{
  "claimNums": [2547, 2568, 2591],
  "CheckAmt": "350.35"
}

We would like to have an option (such as a flag in the existing API, which we already use for posting payments) that automatically updates the Secondary Claim status from “Hold until Primary Received” to “Waiting to Send” once the Primary Claim payment is posted.

[justine]

When a patient has both Primary and Secondary insurance, the Secondary Claim remains in the status “Hold until Primary Received.”
Currently, when we post a payment for the Primary Claim using the endpoint, the payment gets posted, and we have to find and change the status of the secondary claim with additional API calls:

Code: Select all

POST /claimpayments/Batch
{
  "claimNums": [2547, 2568, 2591],
  "CheckAmt": "350.35"
}

We would like to have an option (such as a flag in the existing API, which we already use for posting payments) that automatically updates the Secondary Claim status from “Hold until Primary Received” to “Waiting to Send” once the Primary Claim payment is posted.

Hello ajaykodam,

The API does not provide a way to automatically change the status of a secondary claim when a primary claim payment is posted. In OD itself, this step requires explicit user input, so the same logic applies when using the API.

Thanks!

[mandmdiet]

Hi Justine,

Thank you for your reply and your time with this.

I think we understand yours and Open Dental's concern here, and it makes sense to me as well. Fundamentally changing the nature of the feature and the business logic itself by omitting the user input portion of the feature would be undesirable. We definitely don't want to request that Open Dental do that. I'm also guessing that part of the concern is that you would like to keep the posting API call separate from the initiation of the business logic that conditionally finds and moves secondary claims into a "Waiting to Send" status. Is that correct as well? If I were in your shoes I think I'd have that concern as well.

If that is the case, then could we instead request a separate API call that would allow us to initiate this second part of the process? Allow us to provide the input from the user but reduce our total API calls and allow us to rely on the business logic as defined in Open Dental? Something like this:

1. Post a payment to a primary claim
2. Make an API request, providing the user input you mention, that Open Dental employ its business logic to check for and conditionally update the status on secondary claims

Of course, if Open Dental would be OK with us just passing this explicit user input as part of the posting payment request, we'd prefer that as it does remove a step from our process.

Either way, this would help us avoid a complex implementation on our side that would otherwise be like the below:

1. Post a payment to a primary claim
2. Check for Prompt for Secondary flag status
3. If checked, find any relevant secondary claims
4. If one or more secondary claims are found, update their status to Waiting to Send

We're trying to avoid attempting to duplicate Open Dental business logic on our side since matching that kind of logic in our system would be imprecise and require us to track all the business logic we've mirrored in our system over time with changes in Open Dental. This current method also has the disadvantage of being slow and fragile as it requires so many successful successive API calls, which could hurt the stability of our application. The number of payments we post will be increasing significantly soon when we start rolling out to all of our clients.

Thank you again!

[justine]

Hi Justine,

Thank you for your reply and your time with this.

I think we understand yours and Open Dental's concern here, and it makes sense to me as well. Fundamentally changing the nature of the feature and the business logic itself by omitting the user input portion of the feature would be undesirable. We definitely don't want to request that Open Dental do that. I'm also guessing that part of the concern is that you would like to keep the posting API call separate from the initiation of the business logic that conditionally finds and moves secondary claims into a "Waiting to Send" status. Is that correct as well? If I were in your shoes I think I'd have that concern as well.

If that is the case, then could we instead request a separate API call that would allow us to initiate this second part of the process? Allow us to provide the input from the user but reduce our total API calls and allow us to rely on the business logic as defined in Open Dental? Something like this:

1. Post a payment to a primary claim
2. Make an API request, providing the user input you mention, that Open Dental employ its business logic to check for and conditionally update the status on secondary claims

Of course, if Open Dental would be OK with us just passing this explicit user input as part of the posting payment request, we'd prefer that as it does remove a step from our process.

Either way, this would help us avoid a complex implementation on our side that would otherwise be like the below:

1. Post a payment to a primary claim
2. Check for Prompt for Secondary flag status
3. If checked, find any relevant secondary claims
4. If one or more secondary claims are found, update their status to Waiting to Send

We're trying to avoid attempting to duplicate Open Dental business logic on our side since matching that kind of logic in our system would be imprecise and require us to track all the business logic we've mirrored in our system over time with changes in Open Dental. This current method also has the disadvantage of being slow and fragile as it requires so many successful successive API calls, which could hurt the stability of our application. The number of payments we post will be increasing significantly soon when we start rolling out to all of our clients.

Thank you again!

Hello mandmdiet,

Thanks for the thoughtful follow-up. To clarify: this step in OD is more than a preference check. The preference simply enables the popup, but in the claims UI the user is explicitly given four choices (change status, send secondary now, print, or do nothing). The API intentionally mirrors this separation — when you post a payment to a primary claim, OD will auto-update secondary claim estimates, but changing the claim status always requires a separate, explicit action.

Because of that design, the API will not be adding a “one call does both” endpoint. Would the following approach work for you?

1. Post payment to the primary claim.
2. Use ShortQuery to return the secondary claim numbers tied to the same procedures.
2. Make a follow-up claims API call to change the status on the secondary claim(s) as needed.

This mirrors how OD behaves in the UI, and it keeps the API focused on data and explicit actions rather than duplicating UI workflows.

ShortQuery Example:

Code: Select all

SELECT DISTINCT claimSecondary.ClaimNum
FROM claim AS claimSecondary
JOIN claimproc AS claimProcSecondary ON claimProcSecondary.ClaimNum=claimSecondary.ClaimNum
WHERE claimSecondary.ClaimType='S'
  AND claimSecondary.ClaimStatus='H'
  AND claimProcSecondary.ProcNum IN (
        SELECT claimProcPrimary.ProcNum
        FROM claimproc AS claimProcPrimary
        WHERE claimProcPrimary.ClaimNum IN (1,2,3));

Thanks!