FHIR Chat · scheduling / Issue #40 Need to document current vs. futur...

Stream: argonaut

Topic: scheduling / Issue #40 Need to document current vs. futur...

argo-scheduling-bot (Sep 11 2017 at 23:28):

cooperthompson opened Issue #40

Based on PA discussion:

1. Folks are in favor of pub-sub for exposing availability for "pre-fetch".
2. Need to determine if we want to design $find to account for pre-fetch, or carve out pre-fetch into a (near future) pub-sub solution.

argo-scheduling-bot (Sep 11 2017 at 23:32):

cooperthompson commented on Issue #40

Other considerations for pre-fetch is that appointment IDs can expire before booking, so we need to consider documenting how long proposed appointment IDs should be considered value (i.e. session expiration time).

argo-scheduling-bot (Sep 11 2017 at 23:48):

cooperthompson commented on Issue #40

We could consider adding a "mode" parameter to the $find operation to indicate whether we are doing pre-fetch or not. This would tell the server if they need to do a "session" based approach. It could also drive whether $book accepts an ID, or is effectively a Appointment.create

argo-scheduling-bot (Sep 12 2017 at 02:21):

Healthedata1 commented on Issue #40

what is a session based approach?

Eric M Haas, DVM, MS
Health eData Inc
211 South Jefferson Street, Napa, CA, 94559
707.227.2608|Skype: haas.eric1
ehaas@healthedatainc.com <ehaas@healhtedatainc.com>

On Mon, Sep 11, 2017 at 4:48 PM, Cooper Thompson <notifications@github.com>
wrote:

We could consider adding a "mode" parameter to the $find operation to
indicate whether we are doing pre-fetch or not. This would tell the server
if they need to do a "session" based approach. It could also drive whether
$book accepts an ID, or is effectively a Appointment.create

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/argonautproject/scheduling/issues/40#issuecomment-328690101>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHEU6r3MubTAVSkBW5g4usmdUjfV7pX_ks5shcbHgaJpZM4PT5jz>
.

argo-scheduling-bot (Sep 27 2017 at 17:00):

Healthedata1 commented on Issue #40

It could also drive whether $book accepts an ID, or is effectively a Appointment.create

We have been working under the principle that the client can't directly write to the FHIR Server but needs to POST and operation. Can you clarify what you mean here?

argo-scheduling-bot (Sep 27 2017 at 21:55):

Healthedata1 commented on Issue #40

Define "Sessions based" approach as server session and id lasts as long as session. (not same as browser session)
- Expiration time conveyed in Header.
- Need to document this.

argo-scheduling-bot (Sep 27 2017 at 21:58):

Healthedata1 commented on Issue #40

To summarize:
Propose: Prefetch Scenario as a separate sub-pub workflow from the "Sessions based" approach (i.e.,Patient Portal)

Benefit is that would allow us to optimize each scenario.

Could piggyback on a future subscriptions connectathon track to test out

Next steps: draft outline of pre-fetch wf