Deprecation of PayPlans POST

[JTS]

Good morning,

Starting in version 23.3.1, Open Dental will no longer support creating new Patient Payment Plans. This means the PayPlans POST endpoint will cease to function for dental offices starting with 23.3.1. Existing Patient Payment Plans can still be interacted with in Open Dental. This version is expected to enter beta within the next few weeks.

Instead, please use PayPlans POST Dynamic to create Dynamic Payment Plans. Dynamic Payment Plans are feature rich, and include all of the functionality of Patient Payment Plans.

[saskia]

This seems like a big loss - we have clients who want to be able to create payment plans without needing to associate it with specific procedures. Will dynamic payment plans support this in the future?

[SLeon]

Dynamic Payment Plans must have some production associated with it to justify the total balance. You can attach Completed procedures, Treatment Planned procedures, and adjustments.

What is the reason behind the dental office's practice of charging patients when no dental work has been done or planned?

[saskia]

Couple of different scenarios - sometimes it's purely for speed - they want to get the payment setup quickly and get the patient out the door, deal with the splits later (or, as OpenDental for straight up payments just applies to the oldest first, that meets their requirements so they can keep it super quick and simple). The other big scenario is AR - we use the xml version of the statement file to create invoices and that doesn't include the procedure codes for us to be able to associate with a dynamic plan when posting the payments via the API.

Thanks!

[SLeon]

Good morning,

I would like to address both of your concerns on transitioning to Dynamic Payment Plans:

...
Speed - they want to get the payment setup quickly and get the patient out the door
...

You can set up a Dynamic Payment Plan very quickly with the procedures that were Completed and/or Treatment Planned during the patient's visit. It is the exact same number of clicks as creating a deprecated Patient Payment Plan, without the hassle of manually entering the correct total amount (DPPs automatically calculate this from the attached production).

...
The other big scenario is AR - we use the xml version of the statement file to create invoices and that doesn't include the procedure codes for us to be able to associate with a dynamic plan when posting the payments via the API.
...
Thanks!

You will be able to use PayPlanCharges GET when it is available shortly. This will get you their Primary Keys that you can use to make payment on explicitly.

[saskia]

They're making these plans in our product, not directly in OpenDental. Within our product, users can select the patient, the payment amount and then head straight to paying. That's a lot less clicks than selecting patient, then selecting the procedures, then going to pay. This one we can certainly get around and simply encourage users to take a little more time to save them time later.

As for the other scenario - I don't understand. How will PayPlanCharges GET help us (no plan has been created yet) if we're creating an invoice based on the xml statement file generated? We'll have the names of the procedures, but won't have the procedure codes so when the patient goes to pay that invoice there's no way to create a dynamic plan. I'm open to other suggestions, or maybe you can add the procNum to the xml file for us to be able to use? Or automatically add in the oldest procedures up to the amount that the plan is being made for? This is the logic used for non payment plan payments so would make sense.

Thanks.

[allends]

Saskia,
It is not clear to me what exactly you are trying to do in your program in regards to payment plans, but I will attempt to address some concerns that I believe you might have.

As for the other scenario - I don't understand. How will PayPlanCharges GET help us (no plan has been created yet)

So my understanding is that your concern stems from the point where they need to create a plan, not after they are created. Utilizing PayPlanCharges should be done after the payment plan is created and it should be used to create payments that specifically pay payment plans.

They're making these plans in our product, not directly in OpenDental. Within our product, users can select the patient, the payment amount and then head straight to paying. That's a lot less clicks than selecting patient, then selecting the procedures, then going to pay.

Your main concern seems to be the need to choose procedures for the payment plan. You are correct, that will need to be a part of the new process in your program, but if you would like to make it easier for your patients, I am sure there are ways you could auto-suggest specific procedures for them that they would want attached to the payment plan.

Open Dental no longer supports allowing users or developers to set up payment plans without any attached production and then charge patients for those payment plans.

[saskia]

One of big use cases we have is for AR invoices generated using the statement XML file - Is it possible to add the procNums to this file? Then when patients pay their invoice, we know which procedures to associate the plan to.

[allends]

I am unsure of what this process has to do with the deprecation of Patient Payment Plans. I am not following how the process of making a payment plan has anything to do with taking payment for a statement.

Developers using the XML file from a statement to attempt to discern which procedures a patient owes money on is not really the intended use.
I recommend using https://www.opendental.com/site/apiacco ... ceDateView to find the outstanding production.

Payment plans in 23.3 and greater will now always require production to be attached during their creation. This means there will need to be a process where the patient (or your program) will need to agree to the terms and attached procedures of the payment plan.

sometimes it's purely for speed - they want to get the payment setup quickly and get the patient out the door, deal with the splits later (or, as OpenDental for straight up payments just applies to the oldest first, that meets their requirements so they can keep it super quick and simple).

If the goal is speed, then utilizing https://www.opendental.com/site/apipaym ... 20(create) is the best bet. You can create a payment that pays the oldest outstanding balance first and then move on with very little effort on the user or the patient's part.

[saskia]

We've been using the statement file to generate a statement for the patient as it's the easiest way to get the appropriate list of procedures out of OpenDental (it shows everything since a zero or negative balance which is what we're looking for). Then when patients pay (often using a payment plan) we post that back to OpenDental. So we're already posting the payment back with no issues under the FIFO rules OD has, but, obviously can't create payment plans in those scenarios leading to AR balances remaining despite a payment plan being setup. Practice users have to manually go in to create the payment plan manually as the file doesn't contain procNums for us to do this via the API.

Is there any more information on the service date view? Based on the documentation it's a full list of all transactions and it's unclear to me to distinguish between what's outstanding and what's not (unlike the xml file which based on the parameters will give you the list of items that are outstanding - hence this is used for statements).

Thanks!

[SLeon]

...
Is there any more information on the service date view?
...

The API method AccountModules GET ServiceDateView is directly based on the Service Date View in Open Dental. You will see in the link's screenshot that all charges on the account are detailed and you can determine what has been paid. You can also see which line items are procedures, payplancharges, etc. The API method includes this exact information with two additional fields to help you obtain further information on each row, detailed in our documentation:

ObjectType: The type of object being returned. Either ProcedureLog, Adjustment, PaySplit, ClaimProc, PayPlanCharge, or PayPlan. Otherwise blank.
PrimaryKey: Primary Key corresponding to the ObjectType. Example: procedure.ProcNum=985.

This allows you to see specific procedures, for example, with associated procnums, and be able to act on them accordingly in your application.

[saskia]

I think I understand - I'll have to take a look at my demo instance to wrap my head around how the charges/payments link to one another. The big challenge we have is getting all the patients that have an outstanding balance, and then getting all the outstanding charges for those patients (again where the XML file gives us a lot of data in one hit which is then also quick/easy for us to process). If we were to do everything via the API I think we'd first have to GET PatientBalances to get us a list of patients with balances, and then make another call (GET ServiceDateView) for each patient with a balance (often hundreds!). Or is there a more efficient way to get the data we're after? Thanks.

[SLeon]

If we were to do everything via the API I think we'd first have to GET PatientBalances to get us a list of patients with balances, and then make another call (GET ServiceDateView) for each patient with a balance (often hundreds!). Or is there a more efficient way to get the data we're after?

This definitely would be a strategy you could use to send monthly statements. Looping through a couple hundred patients would take less than five minutes. You could also write a query to select all patients with a balance, etc.