Appointment Slots (proposal for API)
Appointment Slots (proposal for API)
I am rewriting my online booking system from the ground up. The current version reads data from appointment and schedule and scheduleOp to build a day and then block out slots that have appointments or blockouts.
For security I am switching everything to use the open dental API....I am not sure if it is possible to return:
1. Available slots for a particular OP and or Provider. Currently, it does NOT seem to factor in blockouts...it also combines appointments for a specified provider across all ops....this doesn't work for me either...
The other option is to write my own queries request and save in csv file....my current algorithm uses inner join statements as well. Is there a way to submit a custom api call to the open dental team?
Ideally I would like to call the API with: Date, ProviderNum, Chair, Appointment Length and the response would display all the open slots in that particular operatory only and also factor in blockouts.
For security I am switching everything to use the open dental API....I am not sure if it is possible to return:
1. Available slots for a particular OP and or Provider. Currently, it does NOT seem to factor in blockouts...it also combines appointments for a specified provider across all ops....this doesn't work for me either...
The other option is to write my own queries request and save in csv file....my current algorithm uses inner join statements as well. Is there a way to submit a custom api call to the open dental team?
Ideally I would like to call the API with: Date, ProviderNum, Chair, Appointment Length and the response would display all the open slots in that particular operatory only and also factor in blockouts.
Re: Appointment Slots (proposal for API)
Hello thjomha,thjomha wrote: ↑Tue Dec 26, 2023 9:36 pmI am rewriting my online booking system from the ground up. The current version reads data from appointment and schedule and scheduleOp to build a day and then block out slots that have appointments or blockouts.
For security I am switching everything to use the open dental API....I am not sure if it is possible to return:
1. Available slots for a particular OP and or Provider. Currently, it does NOT seem to factor in blockouts...it also combines appointments for a specified provider across all ops....this doesn't work for me either...
The other option is to write my own queries request and save in csv file....my current algorithm uses inner join statements as well. Is there a way to submit a custom api call to the open dental team?
Ideally I would like to call the API with: Date, ProviderNum, Chair, Appointment Length and the response would display all the open slots in that particular operatory only and also factor in blockouts.
Reading data from appointment, schedule and schduleOp is the recommended way of calculating appointment slots.
For additional information, please see:
https://www.opendentalsoft.com:8085/for ... 942#p34946
https://www.opendentalsoft.com:8085/for ... 574#p35342
Additionally, you can run a custom query using the ShortQuery endpoint.
Thanks!
Re: Appointment Slots (proposal for API)
Thank you. I was using ScheduleOp, Schedule, and Appointment to generate my list of available time slots...You are correct in that I can generate the same end result with only the Schedule and Appointment API calls. I use those 2 calls to generate an array with 138 values of 1 or 0 to represent time units from 12am to 11:30pm.
-
- Posts: 101
- Joined: Wed Apr 06, 2022 12:04 pm
Re: Appointment Slots (proposal for API)
I just went through a remodel of my scheduling algorithm as well. I've taken the same approach, using just Apt and Schedule to get to a base set of availability but found that to still be too dumb... at least with respect to maximizing hyg/provider time when that hyg/provider is working across multiple rooms. In other words, we found that provider and room availability was more like a venn diagram and we needed to find the overlap. So, the addition I've made is considering provider time using OD's patterns. The end results is two types of slots.. a 'room slot' and a 'provider slot'. Given a pattern, you can be more precise with availability. Then, layer in cached results from provider, blocktype, and op APIs, we can get even smarter with how you filter the end result.
Re: Appointment Slots (proposal for API)
Are you syncing a local database with API results? If so, how often do you update? My original program accesses the database in real-time, but now I am switching everything to use the APIs...which are slower.
Our online booking is kept simple, we just have providers associated with Operatories and book accordingly...
Is any of your work available open source?
Our online booking is kept simple, we just have providers associated with Operatories and book accordingly...
Is any of your work available open source?
-
- Posts: 37
- Joined: Fri Jan 19, 2024 10:57 am
Re: Appointment Slots (proposal for API)
I'm interested in what the intended use of the Slots API is. My expectation is that it would provide me with *all* slots that fit a certain set of criteria (eg operatory + appt length in the simplest case), but it instead only appears to return one slot per day, and doesn't line up with what the schedule shows. I expect it to appears as though I use the Openings Search functionality within the OpenDental UI. It sounds like from this thread and the linked ones that everyone is instead rebuilding their own version with a mix of different APIs, so what's the use case for this one?
Re: Appointment Slots (proposal for API)
Good afternoon,
The Appointments GET Slots endpoint was released in the very first version of the API (21.1). As mentioned in its documentation, it is meant for dental offices for simple scheduling setups and works almost identically to the standard appointment search found within Open Dental.
Depending on the custom algorithm the developer has designed for their application, they will need to subsequently customize the data they grab to suit their needs. Some developers prefer to use a query, other some of our GET endpoints, and others use Appointments GET Slots. It is unlikely that developers utilizing the Slots endpoint without issue would post on the forum about it.
The Appointments GET Slots endpoint was released in the very first version of the API (21.1). As mentioned in its documentation, it is meant for dental offices for simple scheduling setups and works almost identically to the standard appointment search found within Open Dental.
The Slots endpoint does this. It considers appointments for the provider in question in a specific operatory for the date range you specify. If the provider in that operatory is available from noon to 3pm, the returned JSON will contain a single object with "DateTimeStart: 12:00:00" and "DateTimeEnd: 15:00:00". If they are not available, an empty list is returned. Use the "lengthMinutes" parameter to specify the size of the opening.My expectation is that it would provide me with *all* slots that fit a certain set of criteria (eg operatory + appt length in the simplest case)...
See my above comment (and our documentation) on how the payload is structured. If you are only seeing results for a single day, the provider may not have any openings or adjust the date parameters you use....but it instead only appears to return one slot per day...
There are many strategies to scheduling, and they will differ greatly across dental offices and third party applications. Some offices treat operatories as physical locations and others do not. Some offices schedule hygienists to operatories, some assign them to operatories, some neither, and other both. Other operatories are dedicated solely to the type of appointment done (such as emergency or recall). Further still, offices use schedule blockouts in a myriad of ways: restricted to some appointment types or procedures, exclusive to some appointment type or procedures, notes on the schedule, or unable to schedule for appointments at all.It sounds like from this thread and the linked ones that everyone is instead rebuilding their own version
Depending on the custom algorithm the developer has designed for their application, they will need to subsequently customize the data they grab to suit their needs. Some developers prefer to use a query, other some of our GET endpoints, and others use Appointments GET Slots. It is unlikely that developers utilizing the Slots endpoint without issue would post on the forum about it.
-
- Posts: 37
- Joined: Fri Jan 19, 2024 10:57 am
Re: Appointment Slots (proposal for API)
Perhaps I was unclear with what I meant here, I expected this to be the case and it was not. I was not getting similar results; when I would search via the OD UI, I was presented with many more options for the same appointment type / length. I called your support and asked about this and your support person confirmed that my results seemed out of whack, I’d be happy to jump on a call with an engineer to walk through it again too.
I wasn’t seeing only one day, I was seeing one slot per day. If a doc has 7-10 available, then two hours of appointments, then 12-2, I would expect to see two slots. Instead, I only get the 7-10.
Sure, I just want *rough* parity with the search function. If slots isn’t the way to do that, is there a better prebuilt option, or is it a matter of compiling a few of the other APIs?
Re: Appointment Slots (proposal for API)
Good morning,
I understand that you are not seeing the results you expect when using Appointment GET Slots. I am the engineer who wrote this method, and am happy to clear up any issues. You are also welcome to email us at the email address found in the Developer Portal (click Contact Us). The latter address is monitored by Implementation experts and API Engineers.
This endpoint is the only "pre-built" option. Appointment openings are not a database table in our schema, so it is not a simple data grab like our other GET endpoints. We provide a basic search for basic office scheduling set ups, and expect third party scheduling applications to implement their own scheduling algorithm.
I understand that you are not seeing the results you expect when using Appointment GET Slots. I am the engineer who wrote this method, and am happy to clear up any issues. You are also welcome to email us at the email address found in the Developer Portal (click Contact Us). The latter address is monitored by Implementation experts and API Engineers.
Can you please provide more information? Is the provider scheduled during 12-2p in the operatory you are specifying in your Appointments GET Slots request? Does this provider have appointments during this time in other operatories?If a doc has 7-10 available, then two hours of appointments, then 12-2, I would expect to see two slots. Instead, I only get the 7-10.
This endpoint is the only "pre-built" option. Appointment openings are not a database table in our schema, so it is not a simple data grab like our other GET endpoints. We provide a basic search for basic office scheduling set ups, and expect third party scheduling applications to implement their own scheduling algorithm.
-
- Posts: 101
- Joined: Wed Apr 06, 2022 12:04 pm
Re: Appointment Slots (proposal for API)
@thjomhaAre you syncing a local database with API results? If so, how often do you update? My original program accesses the database in real-time, but now I am switching everything to use the APIs...which are slower.
Our online booking is kept simple, we just have providers associated with Operatories and book accordingly...
Is any of your work available open source?
We run Open Dental using their Middle Tier config. The server sits on a GCP VM. The APIs performance via middle tier was quite slow, so we updated the configuration to use the LOCAL API setup which is significantly faster. I'm not going to pretend to be an expert - I'm all but certain there are infinitely better/faster ways for our setup but we're still small so it works for us. Honestly, our performance is good enough using the GET methods - we can hit the Appointments, Schedule, Blockouts (to get the 'NS' flag), Providers, and Operatories APIs all at once with sub-second response times (e.g. max 250 ms for 2 weeks of Apts). The work I still need to do optimize the routine that then runs through all 5 arrays to ultimate generate bookable slots. The 'caching' for provider, blockouts, and operatories is less about improve return times but instead limit the abuse to our Open Dental Server and cloud VM.