Prefetch issues: "Smart Polling" = Subscription for change of events

[Healthedata1]

"Smart Polling"

1. single operation for load, updates, reconciliation.
   • inputs providers and date range ( possible others)
2. initial load mode - give me everything
   • max date ranges
   • run periodically to reset or to resync
   • minimum daily
3. server informs what changes
   • Triggers
     1. Schedule changes
     2. Visit type changes?
   • Suggested Approach is FHIR Subscription using Schedule
   • Notifies
     • date range
       • often single day
     • provider/facility/group (depending on system)
     • SHOULD be lowest schedulable entity
     • time horizon needs to be defined by clients - events beyond time horizon would be discarded.
     • "heartbeat" every frequency is site specific
     • content: ?
     • per location/facility
     • on/off event service notification ??

example: e.g., provider x gets 6 new appointments get booked - EHR sends 6 notifications

Questions:

1. Whether is technically a "feed" or FHIR Based sub/pub "Subscription."

   
   Design Pattern using a "Feed Handler" in the middle.

Long pull on the Feed Handler by many clients possible without burdening server.

1.  Does CapabilityStatement cover subscription events and plans.

[Healthedata1]

New Operation to differentiates from runtime fetch:

• name Availability Prefetch : $prefetch
• method 'GET'
• see the attached figure for inputs.
• output bundle of slots
  • (e.g., session limit example) server would apply their logic prior to returning slot to filter unschedulable slots (See similar language in $find)

[Healthedata1]

See https://docs.google.com/document/d/1P8yLaXp9aE1rxM8-ey9-7x-VCwwdmGmOASx9vuq1Ius/edit?usp=sharing for PreFetch output content and guidance.

[Healthedata1]

for hold and book: POST Appt

• equivalent to $hold = with slots ids, status of pending , patient optional
  • client needs to create or fetch patient first and server should return a valid
  • server return valid id or reject if slots not available, etc patient id e.g. server side conditional create (server side impementation )
• equivalent to $book = with slots ids,status of booked and patient as referencer
  • server return valid id or reject if slots not available, etc

[Healthedata1]

implement

[Healthedata1]

Issues with current way Subscription works and what was discussed for updating slots.

From above

• Subscribe to receive notification of changes to free slots from server. Each notification needs to contain the date and provider id (lowest schedulable entity) so that the client can refetch that day's worth of slots for that actor.

• We talked about using Schedule and I am unclear how that would work with the existing FHIR Subscription resource.

• Here is what I propose:

  • Option 1

    • Can add extension topic extension to subscription to describe event ( I hope something like it will be in the next release of FHIR)
    • output slot from which the date and actor can be obtained.

    Example:

    The app creates a Subscription on the EHR's FHIR server for the given EventDefinition

    POST <fhir base url>/Subscription
    
    {
     "resourceType": "Subscription",
     "extension": {[
    "url": "[argo-scheduling-url]subscription-topic",
    "valueString": {trigger notification when free slots change}
        ]
     }
     "channel": {
       "type": "rest-hook",
       "endpoint": "[prefetch endpoint]",
       "payload": "application/fhir+json"
     }
    }

    EHR notifies app of change

    PUT <app notification endpoint>/free-slot-change/Slot
    
    {
          "resourceType": "Slot",
          "id": "example",
          "text": {
            "status": "generated",
            "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n\t\t\t25 Dec 2013 9:15am - 9:30am: <b>Busy</b> Physiotherapy\n\t\t</div>"
          },
          "serviceCategory": {
            "coding": [
              {
                "code": "17",
                "display": "General Practice"
              }
            ]
          },
          "serviceType": [
            {
              "coding": [
                {
                  "code": "57",
                  "display": "Immunization"
                }
              ]
            }
          ],
          "specialty": [
            {
              "coding": [
                {
                  "code": "408480009",
                  "display": "Clinical immunology"
                }
              ]
            }
          ],
          "appointmentType": {
            "coding": [
              {
                "system": "http://hl7.org/fhir/v2/0276",
                "code": "WALKIN",
                "display": "A previously unscheduled walk-in visit"
              }
            ]
          },
          "schedule": {
            "reference": "Schedule/example"
          },
          "status": "busy",
          "start": "2013-12-25T09:15:00Z",
          "end": "2013-12-25T09:30:00Z",
          "comment": "Assessments should be performed before requesting appointments in this slot."
        }

    • Option 2 can simply describe how the subscription service should behave
    • Other suggestions?

[Healthedata1]

Option 2:

Will trigger on Slots but send the Schedule ( referenced in the triggering Slot.schedule) in the notification payload.

[Healthedata1]

applied to IG