FHIR Chat · scheduling / Issue #59 Prefetch issues: "Smart Polling" ...

Stream: argonaut

Topic: scheduling / Issue #59 Prefetch issues: "Smart Polling" ...

argo-scheduling-bot (Jan 27 2018 at 18:11):

Healthedata1 opened Issue #59

"Smart Polling"
1. single operation for load, updates, reconciliation.
- inputs providers and date range ( possible others)
1. initial load mode - give me everything
- max date ranges
- run periodically to reset or to resync
- minimum daily
1. server informs what changes
- Triggers
1. Schedule changes
1. 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.

argo-scheduling-bot (Jan 27 2018 at 18:34):

Healthedata1 commented on Issue #59

New Operation to differentiates from runtime fetch:

name Availability Prefetch : $prefetch

see the attached figure for inputs.

output (e.g., session limit example) server would apply to slots there logic prior to returning.

See similar language in $find

argo-scheduling-bot (Jan 27 2018 at 21:37):

Healthedata1 commented on Issue #59

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

argo-scheduling-bot (Jan 28 2018 at 20:42):

Healthedata1 commented on Issue #59

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

argo-scheduling-bot (Jan 28 2018 at 20:44):

Healthedata1 commented on Issue #59

implement

argo-scheduling-bot (Feb 13 2018 at 01:56):

Healthedata1 commented on Issue #59

### 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?