FHIR Search Slots request

Question

I am implementing FHIR server and for some un-avoidable reason I do not have access to doctor's schedule, however, I have access to the slots available for appointment booking.

I can get slots from 4 parameters using

1. doctor id
2. organization id
3. location id
4. date of slot

Will below be considered as valid slot query using FHIR :

http://localhost:8080/context/fhir/Slot?practitioner=Practitioner/123456789&organization=Organization/1234&location=Location/2&start=2016-07-25

Also, in the response to above query, since reference to Schedule is absolutely necessary (Slot has card=1..1 for Schedule reference), can I pass reference value as something like :

"schedule": {
    "reference": "Schedule/notrequired"
  }

in Slot response ?

Answer 1

Unfortunately, right now, you do have to expose a Schedule, but there isn't any reason it has to be "real". The way we have currently implemented Slot searching is by exposing a dummy Schedule with the only data element being the link to the actor. For example:

<Schedule xmlns="http://hl7.org/fhir">
<id value="1234" />
<actor>
    <display value="Cooper Thompson, MD" />
    <reference value="http://host/api/FHIR/DSTU2/Practitioner/1234" />
</actor>

Our Slot search ends up looking like this (with some edits for brevity and clarity, specifically around the slottype):

http://host/api/FHIR/DSTU2/Slot?Schedule.actor:Practitioner=1234&Schedule.actor:Patient=5678&slottype=urn:oid:1.2.3|Cardiology&start=2016-07-21

Note that this is technically invalid, as a Slot can only have one Schedule, and we are including multiple chained search parameters for Schedule. We also make use of extensions to send back the patient, practitioner, and location associated with the slot, since Slot.schedule is 1:1. However this "intentional misuse" is the best option I've found without forcing the client to become the scheduling system and deal with lining up slots for each resource.

There are some tracker items (9989, 9208) in the FHIR gforge about making updates to Slot to be more friendly to "simple clients". We'd appreciate your input :).

Answer 2

I might be missing something here, but not sure how you are defining the difference between the slot and schedule?

The Schedule resource simply defines a period of time that slots may exist within, and for which other resource. It does not define or expose the appointments that may exist during this time.

The slot search parameters do not define any search parameters as you've implied. These are all on the schedule resource that it links from.

A Practitioner, Location and Patient can each have their own schedule/slots and thus it depends on the system where the complexity is defined. Some systems decide that they are only going to worry about practitioners (who have their own room), others only worry about the room and will allocate practitioners later.

From my understanding of what I think you're trying to so (creating a FHIR Façade in front of a practice management system) I think you will need to expose the following resources:

• Practitioner: To expose the details of the practitioner (interested if your practitioners can work in multiple locations)
• Schedule: To simply expose the date range that you are accepting appointments (and will have slot availability defined) and the practitioner is linked to this resource, if they work at multiple locations, you'll have one of these for each location the practitioner works. (If the location resources have their own schedule, then will need to further consider it, and where the negotiation for available slots is done)
• Slot: To define the available slots that appointments could be scheduled into. (note: these are not appointments)
• Appointment: To receive the created appointments (Not sure how you're going to handle this if you don't have access to the schedule)
• Patient: Assuming that you want to assign patients to the appointments ;)

If this all makes sense and you clarify your environment, I'll put in the likely queries that you'll need to handle.

This was a great question, and Patient Administration is planning to write some implementation guidance on implementing this functionality in the various environments (General Practice, inpatient, outpatient, community, lab, etc.)