Date Issue with API

[omar22]

Hello,

I found that when I try to add history in the ProcedureLogs API and put the date in the YYYY-MM-DD format, the date gets uploaded as the next day. This issue is also present when I try to search for patients using the GET and filter by DOB, it doesn't work, since the date I enter is a day ahead of the DOB in Open Dental.

Is there any way we can fix this?

Thank you for all your amazing work!
Omar

[justine]

Hello,

I found that when I try to add history in the ProcedureLogs API and put the date in the YYYY-MM-DD format, the date gets uploaded as the next day. This issue is also present when I try to search for patients using the GET and filter by DOB, it doesn't work, since the date I enter is a day ahead of the DOB in Open Dental.

Is there any way we can fix this?

Thank you for all your amazing work!
Omar

Good morning Omar22,

I've tested both GET patients and GET patients/Simple on the demo database and am getting expected results.

Code: Select all

https://api.opendental.com/api/v1/patients?Birthdate=1980-06-05
https://api.opendental.com/api/v1/patients/Simple?Birthdate=1980-06-05

Both return Allowed Allen.

Dates saved in the database have no time component. Since there is no time component, when you pull this data, I'm guessing your local timezone is being applied. If you are east of UTC, it will end up in the day after.

[omar22]

I am in EST, I'm not really sure why it's happening, but if there's no time component then it must be something on our side; thank you for the clarification!

The other issue I've been having is, this sample patient had a maximum of 1500, and the insurance used was 163. When I use the ClaimProcs PUT InsAdjust and put the "InsUsed" as 163, I get the following:

Screenshot 2023-05-17 094053.png (6.18 KiB) Viewed 4295 times

Is there any way I can avoid these miscalculations, as they happen quite often?

Thanks again,
Omar

[SLeon]

Good morning,

We are investigating this issue and are not yet able to duplicate this behavior. Could you please confirm that "this sample patient had a maximum of 1500" means the patient's Insurance Plan has either an Individual or Family "Annual Max" value of $1500?

Also, were there any other adjustments (insurance or otherwise) on this patient's account? The ClaimProcs PUT InsAdjust method is unique and works by summing the InsPayAmt values on existing claimprocs.

[omar22]

Hey @Sleon!

Yes, the individual annual max was 1500; family annual max was n/a. I am not positive if there were prior adjustments made, but if there can be a way to override that, even if there were prior adjustments, and just include the latest value inserted via the API, that would be fantastic.

Thanks so much.

[SLeon]

A member of our team was able to duplicate your described behavior. For us, it occurred when insurance has already paid the Annual Max (eg $1500) on received claim(s). Because ClaimProcs PUT InsAdjust is used to override all existing insurance pay amounts, passing in an InsUsed value of 163 conveys that you need to adjust the insurance pay amount down by $1337.

The calculation is the InsUsed passed in minus the sum of insurance payments that aren't adjustments. So in this instance, we are calculating $163-1500 resulting in $-1337, meaning insurance has overpaid by this amount. What you are more likely trying to convey is that the insurance paid an additional $163 (or $1663 in total). The math would work out to $1663-1500= $163, which is what you are likely expecting.

We understand this method is complex and some developers, such as yourself, may want to make these adjustments differently. We are adding ClaimProcs POST InsAdjust to our development list to support this workflow.

[omar22]

That makes perfect sense. Thank you for the thorough explanation I really appreciate it, and I look forward to the POST addition

[omar22]

A member of our team was able to duplicate your described behavior. For us, it occurred when insurance has already paid the Annual Max (eg $1500) on received claim(s). Because ClaimProcs PUT InsAdjust is used to override all existing insurance pay amounts, passing in an InsUsed value of 163 conveys that you need to adjust the insurance pay amount down by $1337.

The calculation is the InsUsed passed in minus the sum of insurance payments that aren't adjustments. So in this instance, we are calculating $163-1500 resulting in $-1337, meaning insurance has overpaid by this amount. What you are more likely trying to convey is that the insurance paid an additional $163 (or $1663 in total). The math would work out to $1663-1500= $163, which is what you are likely expecting.

We understand this method is complex and some developers, such as yourself, may want to make these adjustments differently. We are adding ClaimProcs POST InsAdjust to our development list to support this workflow.

Hi @SLeon!
I just wanted to follow up with you on this POST InsAdjust method.

Thank you so much,
Omar

[SLeon]

Good afternoon Omar,

ClaimProcs POST InsAdjust is next in our development list, and I expect it to be complete a couple weeks after development begins. There are a lot of API feature requests currently in the pipeline, thank you for your patience as we work through them. We will update this thread as soon as it is available.

[omar22]

Thank you so much for the prompt response!! )

[DerekR]

The feature request for ClaimProcs POST InsAdjust has been completed and is available in our beta version, 23.2.5. This method will allow the creation of a ClaimProc that is acting as an insurance adjustment. Documentation can be found at https://www.opendental.com/site/apiclaimprocs.html.