Need to document current vs. future pre-fetch availability

[cooperthompson]

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.

[cooperthompson]

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).

[cooperthompson]

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

[Healthedata1]

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 .

[Healthedata1]

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?

[Healthedata1]

Define "Sessions based" approach as server session and proposed Appt id's lasts as long as session. (not same as browser session)

• So when $book using id after session expired will fail and will need to restart session
• Proposal to convey expiration time in http header.
• Need to document this.

[Healthedata1]

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
• $hold and $book would use Appt resource instead of id as described above
  • would need extra validation on the Appt resource to make sure is unchanged from the published resource

[Healthedata1]

See my summary of email discussion

[Healthedata1]

Merged with #44