Stream: smart/scheduling-links
Topic: Apple Vaccination Availability
Cooper Thompson (Mar 19 2021 at 18:21):
@Ricky Bloomfield - I noticed that Apple had a press release about an Apple tool (built in partnership with Boston Children's) for displaying vaccine availability. It looks like that loads data via CSV import. Is there an option (now or in the near future) to use the SMART Scheduling Links spec to load that in?
Cooper Thompson (Mar 19 2021 at 18:23):
It looks like most of the columns in the CSV overlap with the SMART Scheduling Links spec. Exceptions are "Requires Referral", "Requires Appointment" and "Vaccination Location Type".
Cooper Thompson (Mar 19 2021 at 18:27):
It looks like you have a direct VaccineFinder feed, so I guess if VaccineFinder is using SMART Scheduling Links, it ends up being the same. I guess I'm not really sure if there is a real use case for loading data not from VaccineFinder but still using SMART Scheduling Links.
Ricky Bloomfield (Mar 19 2021 at 19:16):
I believe @Josh Mandel may know more about that! I don't think SMART Scheduling Links is necessary to shuttle the data to Apple for display in Maps, but any of those sites could use SMART Scheduling Links to make it easier to schedule!
Josh Mandel (Mar 19 2021 at 19:23):
Re: UX, I think the opportunity would be to push availability data into maps (or whatever app people are using) to give them a view about when appointment slots are available, and a deep link to booking those slots.
Henry Wei (Mar 19 2021 at 22:21):
Hi all. It’s very important to delineate FHIR Slots vs FHIR Scheduling. As we see with “categorical” search (eg ‘vaccines near me’ rather than ‘vaccines at specific provider X’), availability feeds are often what is needed at the first step in the user journey — before scheduling transactions. As the current FHIR standard for Slots notes there is also a good IETF standard deployed for this already and supported in iCalendar format.
I’m in touch with the IETF leads from my organization and y’all may wish to rally quickly with their BOF process.
C. Daboo from Apple also proposed RFC 7953 in 2016.
https://tools.ietf.org/html/rfc7953
https://www.ietf.org/about/participate/tao/
Thanks,
Henry
Josh Mandel (Mar 19 2021 at 22:24):
Re: availability, the aim with Scheduling Links is that you can publish this information at any granularity (# per day, or specific times) just by changing the granularity of the slots you publish. Are there particular aspects of this design that cause you concern @Henry Wei? (Also: hi, and welcome!)
Henry Wei (Mar 19 2021 at 22:31):
(deleted)
Henry Wei (Mar 19 2021 at 22:31):
Scheduling links exist today actually. Google Maps indexes these and also providers and businesses update their links at Google My Business (once they are verified). These scheduling links differ dramatically from Availability Feeds which are deployed for other self-scheduling verticals (eg restaurants).
The Availability feeds also disaggregate into two flavors:
Product Availability
Service Availability
For an example (I am not recommending this but pointing at an existing deployed Availability feed model) see Developer Center guidance here:
https://developers.google.com/maps-booking/reference/feed-specifications/availability-feed
Josh Mandel (Mar 19 2021 at 22:39):
There are clearly a lot of potential APIs that work for this use case; the aim was to standardize one based on our collective healthcare service and scheduling knowledge, in a way that fits for COVID-19 but also for broader "slot discovery" use cases. This provides a way to describe Locations, Schedules that include detailed clinical servicse offered, HealthcareService metadata (if we need them), etc -- so it's a pretty natural direction.
Josh Mandel (Mar 19 2021 at 22:39):
That said, I'd be interested to see how the Locations, Schedules, and Slots from https://github.com/smart-on-fhir/smart-scheduling-links/blob/master/examples/%24bulk-publish would map into the framework you're describing. May be worth building a conversion demo?
Henry Wei (Mar 19 2021 at 23:17):
It may be worth getting already-publishing entities’ perspective — quickly —- as to how easy or difficult the standard proposed at https://github.com/smart-on-fhir/smart-scheduling-links/blob/ea0333bf2b8a576c962a04f7db5d3770d1a1bdfc/specification.md would be to implement.
Conversion demo is maybe not so relevant here, as Google is a receiving endpoint for the feed type example I posted above — which is not currently used for healthcare vertical.
But the design pattern would separate out availability of supply of goods, versus availability of the human service (appointments).
Slot Publisher would be good for the latter. But this part may have some Site Reliability Engineering considerations to consider a pub/sub mode rather than periodic polling:
“A client queries the manifest on a regular basis, e.g. once every 1-5 minutes. The client iterates through the links in the manifest file to retrieve any Location, Schedule, or Slot files it is interested in...”
Feeds, in contrast, are pushed (rather than pulled).
Net-net the content standard should be aligned, but the transmission mode — “push” versus periodic poll-and-pull — matters a lot because (from talking with scheduling aggregators on the market today) some legacy EHR systems and middleware are likely to implement the Slot calculation itself as a fairly inefficient loops through the entire schedule.
Henry Wei (Mar 19 2021 at 23:27):
I’ll try to see if I can get Yijie Hong, our Engineering lead looking at this, in on this thread. He may comment directly as Issues in the GitHub repo, @Josh Mandel . The issue is that the polling data itself can be a large block for some sources, and the interval has similarly been problematic.
The data container standard should still be ok though. It’s just the on-demand query mechanism vs push-subscription mechanism that may need some consideration for pragmatic implementation — as many orgs may balk at on-demand if they are unprepared to implement rate limiting and other throttling mechanisms (or their backends can’t support API performance at the service level objectives of the API).
Henry Wei (Mar 19 2021 at 23:28):
I’ll try to see if I can get Yijie Hong, our Engineering lead looking at this, in on this thread. He may comment directly as Issues in the GitHub repo, @Josh Mandel . The issue is that the polling data itself can be a large block for some sources, and the interval has similarly been problematic.
The data container standard should still be ok though. It’s just the on-demand query mechanism vs push-subscription mechanism that may need some consideration for pragmatic implementation — as many orgs may balk at on-demand if they are unprepared to implement rate limiting and other throttling mechanisms (or their backends can’t support API performance at the SLO / service level objective needed of most modern APIs).
Josh Mandel (Mar 20 2021 at 03:33):
Re: push vs pull, one challenge here is whether you need to set up custom agreements / configuration for every source to send data to every relying app (as this set of apps grows). The initial USDS spec (from which the Scheduling Links pattern derives) was pull based too. Publishing static files works well (e.g.) from cloud storage buckets / CDNs.
Henry Wei (Mar 20 2021 at 04:01):
Good point @Josh Mandel . Periodic polling might incur some type of agreement also, though, especially to avoid peaks / overloads.
Josh, this feels an awful lot like the 2012-2013 discussion we had on push vs pull with Blue Button then, and also more recent CARIN BB IG discussions last year on how notifications of updates can be pushed to downstream entities (perhaps belt-and-suspenders to continuous polling). For example, downstream PHR apps can then be notified of updates rather than continuous polling.
So perhaps a well-articulated “push” mode implementation guidance for data sources and data receivers can be stated in the spec. This would be either as a very lightweight signal to initiate a “pull” might also apply here. That said, I believe FHIR R4 discusses existing resources as being deployable as either push or pull.
https://www.hl7.org/fhir/pushpull.html
The other possibility is meta-data to indicate “this is how often these data will be updated” — future tense. This can set expectations for data receivers to tailor their polling requests to a) the right interval and b) potentially the right time of day / night Eg if EHRs are doing overnight calculations of availability from new bookings and cancellation during the day before.
While these seem extraneous, they can add resilience to the system now, up front, rather than risk API overloads and refactoring later.
So basically 1) push mode and 2) setting expectations of how often pulls make sense.
These overload conditions are also difficult failure modes to test at Connectathons.
I also agree on static file publication as another potential — and articulating a standard for how those published files ought to be “picked up” and the files themselves named and formatted, especially given the CDN scaling advantages. These too should probably carry meta-data to set expectations for if/when the next update is due to appear either at a file level, and/or at an individual record level.
Last updated: Apr 12 2022 at 19:14 UTC
