Planned Procedure Status

[graham_mueller]

Hello,

Trying to understand Planned Procedures now as well. I have a patient that has six items in the Planned Appointment view. Four of the six are "complete" in the OD UI. What is used to mark this? The PlannedAppt table has four columns, I initially expected that AptNum would be empty for incomplete messages, but all six for this patient have a value, and all six are real appointments that have an AptDateTime set, but also all six are set to the status planned. What is the link I'm missing to understand when a planned appointment becomes complete?

Also - I would love to get an update where hitting the escape key doesn't close the User Query window... I've lost hours of queries to this at this point. My other database viewer is over aggressive on autocomplete so I've gotten used to hitting esc to stop it.

[DerekR]

Trying to understand Planned Procedures now as well. I have a patient that has six items in the Planned Appointment view. Four of the six are "complete" in the OD UI. What is used to mark this? The PlannedAppt table has four columns, I initially expected that AptNum would be empty for incomplete messages, but all six for this patient have a value, and all six are real appointments that have an AptDateTime set, but also all six are set to the status planned. What is the link I'm missing to understand when a planned appointment becomes complete?

A "Planned" appointment is linked to a "Scheduled" or "Complete" appointment by appointment.NextAptNum, which is the FK to appointment.AptNum. A better description of this field would be PlannedAptNum. Only used to show that this apt is derived from specified planned apt. Otherwise, 0. When the linked appointment is marked as complete, then the planned appointment will show complete in OD UI.

The PlannedAppt tables main purpose was to keep track of the ItemOrder for the planned appointments, and it is worth noting that this table has been deprecated in version 24.2, and has been replaced by adding ItemOrderPlanned to the appointment table.

[graham_mueller]

If I'm understanding you (and the data I'm seeing), it appears that the appointments that are linked to the PlannedAppointments do not ever have a NextAptNum, but there are appointments that are linked to *those* appointments via the NextAptNum. So if PlannedAppointment has Appointment 1 linked to it, there will be a appointment 2 that links to 1 as the NextAptNum, for the completed appointments.

Most of the clients we have are not quite at the point of getting the new table (at least in the cases that I've seen). If this is going to be deprecated, what versions do you expect it to see it removed?

[justine]

If I'm understanding you (and the data I'm seeing), it appears that the appointments that are linked to the PlannedAppointments do not ever have a NextAptNum, but there are appointments that are linked to *those* appointments via the NextAptNum. So if PlannedAppointment has Appointment 1 linked to it, there will be a appointment 2 that links to 1 as the NextAptNum, for the completed appointments.

Most of the clients we have are not quite at the point of getting the new table (at least in the cases that I've seen). If this is going to be deprecated, what versions do you expect it to see it removed?

Good morning graham_mueller,

The plannedappt table was deprecated in version 24.2.

[graham_mueller]

Hi Justine,

Could you confirm that my understanding of the NextAptNum link is correct? You can determine that a PlannedAppt is complete by looking for a Appointment that has a NextAptNum that's the AptNum in the PlannedApt table?

If you're deprecating it in 24.2, I would expect that to mean it continues to exist for a number of versions, perhaps dropped as part of 25? I'm not sure what your deprecation policy is, do you have that documented somewhere? I don't have version 24 available yet to start building around that redesign.

[DerekR]

If I'm understanding you (and the data I'm seeing), it appears that the appointments that are linked to the PlannedAppointments do not ever have a NextAptNum, but there are appointments that are linked to *those* appointments via the NextAptNum. So if PlannedAppointment has Appointment 1 linked to it, there will be a appointment 2 that links to 1 as the NextAptNum, for the completed appointments.

Yes, the "Planned" appointment will have a NextAptNum of 0, and the "Scheduled" or "Complete" appointment will have a NextAptNum that is the "Planned" appointments AptNum.

Example:

PlannedApptExample.png (3.25 KiB) Viewed 20789 times

The example image above shows that AptNum 900 is the "Planned" appointment, and AptNum 902 is the "Scheduled" appointment that is derived from the "Planned" appointment.

If you're deprecating it in 24.2, I would expect that to mean it continues to exist for a number of versions, perhaps dropped as part of 25? I'm not sure what your deprecation policy is, do you have that documented somewhere? I don't have version 24 available yet to start building around that redesign.

When the dental office updates to version 24.2, a convert script runs, and the plannedappt table will be deprecated. When viewing the
Database Schema Changes for 24.2 the appointment table gained the ItemOrderPlanned field, and the plannedappt table is shown in red as it will no longer exist.

[graham_mueller]

Ok, so to clarify, it isn't being deprecated in version 24.2, it's just going to be removed at that point. Not sure if you're in a position to ask this of the dev team, but it would be useful if the planned table could be maintained for an additional version when the new field is added so that I can test and migrate my code and not just break at that point, especially if my clients don't all take the version update at the same time.

[SLeon]

Good morning,

isn't being deprecated in version 24.2, it's just going to be removed at that point.

The PlannedAppt table was deprecated in 24.2.0. This is our Beta version, currently. It fits the Wikipedia page you linked's description of deprecation, because we did not outright remove the concept of Planned Appointments from our software. We simply moved information that was stored in one table to another. We are the development team, and we have made sure there was no loss of functionality in this transition from the PlannedAppt table to the Appointment.ItemOrderPlanned field. If you are using the API, your code cannot break, as we do not introduce breaking changes. For example, the Appointments POST Planned and Appointments POST ScheduledPlanned work with the same payloads before and after this change. The other engineers in this thread and I put great effort to make this the case.

As mentioned previously, the PlannedAppt table was removed (not "is going to be removed"). It is gone. You can see this with the Public Demo credentials (version 24.2.23), by calling Queries PUT ShortQuery with "SqlCommand":"SELECT * FROM PlannedAppt" in the payload. The purpose of the Beta is to give developers a chance to digest the new features and incorporate them into their applications (if they desire). Most dental offices are on Stable (24.1) or lower. Again, the API endpoints are unchanged and require no new URL/payload parameters to function. It is only custom queries that would need a slight adjustment (use appointments.ItemOrderPlanned to populate the UI instead of plannedappt.ItemOrder). The NextAptNum logic DerekR described above is unchanged, and your code won't need to change its parsing of it either.

[graham_mueller]

Unfortunately as you may have gathered from my trying to piece together tables above... no API for what I'm trying to do here, currently working via ShortQuery bandaids that will break on update. Would be happy to see a GET Appointments/Planned or etc, though. That and TreatPlans that provide the same billing info available in the Tx Plan tab in the application, since a mix of the two are what I'm currently working to build.

[DerekR]

Would be happy to see a GET Appointments/Planned or etc, though.

Appointments GET (multiple) allowes filtering the results by AptStatus.