Issues with fetching slots in PreFetch Scenario

[Healthedata1]

Assuming:

1. our goal is to get all the open slots for a service for all actors needed for that service.
2. client has a set of business rules to know what actors are needed to create an Appointmenr for a particular service

3. a "service based approach" can be used ( "visit type" links all the actors, schedules and slots together )

   Example:

   • visit-type = "Physical"
   • Set of rules for what is needed:
   • a Room (Location A)
   • a Doctor (Practitioner A)
   • a Nurse (Practitioner B)

Getting open slots for type "Physical" --> just a pile of slots:

• need to first figure out which schedules are applicable (i.e., a room , a practitioner or a machine)
• 'Determining which schedules should be consulted often will involve searching via the properties of the referenced actors, such as the ServiceCategory on the HealthcareService, or the Address on a Location or the specialty on a PractitionerRole.'

Options:

• include schedules ( and possible recursively Location and PractitionerRole and Practitioner) in the search bundle (reconstruct on client side)
• filter Slots by chained search on schedule.actor ( all open slots for schedules with type = X and actor = PractitionerRole )
• Alternative: is to search by schedule by type and rev_include all open slots ( can't do this by standard search - custom operation )
• Alternative is to add actor extension to slot

[Healthedata1]

separated prefetch with realtime WF:

specific to prefecth WF and search params. ...

follow up offline--2 questions;

1. What (if any) search parameters
2. _includes?

[brandon-larue-zocdoc]

Start date and end date seem like minimal requirements, as the search needs to be bounded.

As a consumer of these, we like to be able to narrow down further - practitioner (via Schedule.actor is fine) and location are the best candidates, and requiring one but not both gives a lot of flexibility.

Cerner has a good pattern here: http://fhir.cerner.com/millennium/dstu2/scheduling/slot/ although they also require Slot.type (they're using DSTU2) which is isn't ideal for a pre-fetch scenario.

[Healthedata1]

Discussed on call will Use the approach described above for both intitial load and for polling updates.

Detail technical search details in specification.