Hi all,
New to the forums, going to bundle a couple things here under a primary question. Let me know if you prefer things broken up. The gist of my goal here is, I'm hoping to surface referral options to users as they book appointments. The clinic I'm working with has many referrals set up; I want only the non-human and also "preferred" options.
The GET /referrals endpoint doesn't offer me filtering options, or I don't understand how to use filtering on the open GET calls. I haven't succeeded here with anything, open to suggestions because I *believe* that passing query params is supposed to work here, but doesn't seem to.
Without being able to filter in the call, I am getting a limit of 100 items, where this clinic seems to have multiple hundreds (of which, only six are useful to me). I would like to be able to specify a larger page size, but it doesn't seem to be possible, but iterating with offsets seems a bit silly.
The response is missing some/most of the fields that are present in the OpenDental UI. In general, this is ok for my use case - I don't need things like address, but specifically, if nothing else in this post were addressed, providing the "preferred referral" field present in the desktop would be great.
The other fields in the response are inconsistent, which in itself isn't a major problem, but providing both Specialty and specialty seems problematic. Could this instead have something like SpecialtyNum and SpecialtyDescription?
Sorry again if there's a different preferred way to do this, support suggested I come over here.
Referrals API Update
Re: Referrals API Update
Good Afternoon,
The documentation page lists all of the currently possible query params and JSON body fields with each of our method calls. Referrals GET does not currently have any query params, but you can request to add new ones to our development list. Which fields would you like to filter the results by?
For more information on our Pagination please see API Implementation for more details.
As for the API referral objects being returned, we can enhancement them to include the "IsPreferred" field. This request will be added to our development list.
The difference between "Specialty" and "specialty" is that the uppercase version is part of the referral table, and is a FK to definition.DefNum where category=35, aka ProviderSpecialties definitions. The lowercase version is not part of the referral table and is the "ItemName" of that definition. See Definitions: Provider Specialties, and the Foreign Keys section of API Implementation for more information.
Thanks!
The documentation page lists all of the currently possible query params and JSON body fields with each of our method calls. Referrals GET does not currently have any query params, but you can request to add new ones to our development list. Which fields would you like to filter the results by?
For more information on our Pagination please see API Implementation for more details.
As for the API referral objects being returned, we can enhancement them to include the "IsPreferred" field. This request will be added to our development list.
The difference between "Specialty" and "specialty" is that the uppercase version is part of the referral table, and is a FK to definition.DefNum where category=35, aka ProviderSpecialties definitions. The lowercase version is not part of the referral table and is the "ItemName" of that definition. See Definitions: Provider Specialties, and the Foreign Keys section of API Implementation for more information.
Thanks!
-
- Posts: 33
- Joined: Fri Jan 19, 2024 10:57 am
Re: Referrals API Update
For my specific scenario, I would like to filter by the preferred field that doesn’t currently exist. The non human would make a possible alternative, but more generally on all the endpoints, having the ability to filter by any of the keys that come back in the result would be useful.
This seems to confirm that yes, the limit is 100. The drift issue is a fun one I hadn’t considered, though unlikely to be an issue for my case.DerekR wrote: ↑Fri Jan 19, 2024 1:17 pmFor more information on our Pagination please see API Implementation for more details.
What sort of timeline should I expect for items on this list?
I understand what you’re saying here, but this seems like a horribly confusing way to join a foreign object (and flatten it into the response object?). For this API especially, what’s the use case for having both? It seems like I would never want the number, I might only ever want the providers specialty if I hoped to filter the set on that?DerekR wrote: ↑Fri Jan 19, 2024 1:17 pmThe difference between "Specialty" and "specialty" is that the uppercase version is part of the referral table, and is a FK to definition.DefNum where category=35, aka ProviderSpecialties definitions. The lowercase version is not part of the referral table and is the "ItemName" of that definition.
Re: Referrals API Update
We have also added the ability to filter by "IsPreferred" to this request.
API feature requests are started in the order in which they are received. There are a couple dozen requests ahead of this one. I would estimate this to be completed in 8-10 weeks, and we will update this thread with our progress.graham_mueller wrote: ↑Fri Jan 19, 2024 11:28 pmWhat sort of timeline should I expect for items on this list?
Thanks!
Re: Referrals API Update
Hello graham_mueller,
The referrals GET feature requests have been completed. Referrals GET (single) has been added and referrals GET (multiple) has been enhanced with several optional filters.
These enhancements are available in version 24.1.34. Please see https://www.opendental.com/site/apireferrals.html for more information.
Thanks!
The referrals GET feature requests have been completed. Referrals GET (single) has been added and referrals GET (multiple) has been enhanced with several optional filters.
These enhancements are available in version 24.1.34. Please see https://www.opendental.com/site/apireferrals.html for more information.
Thanks!