Stream: argonaut
Topic: scheduling / Issue #49 Should we explore providing patien...
argo-scheduling-bot (Nov 20 2017 at 18:14):
Healthedata1 opened Issue #49
Should we explore providing patient details to the hold call so that the server can use that info to further validate prior to registration?
background
Assumptions:
- Server not going to hold patient demographic information from appt $find operation until the booking
- Client needs to resend this information to register patient prior to booking the appointment
- Server needs to return a Patient ID to client for bookingThe patient registration is a separate interaction sandwiched between a hold and book.
Other workflow has the patient registration at the beginning instead of prior to booking...There's still a possible bad state if the final booking fails post-registration, then you have a newly created patient with no context to provide the server around why this was created.
Issuing a hold first prevents most of these, but there are still possible cases where a server might reject the final booking once it has the patient context.
argo-scheduling-bot (Nov 20 2017 at 18:14):
Healthedata1 edited Issue #49
Should we explore providing patient details to the hold call so that the server can use that info to further validate prior to registration?
background
Assumptions:
- Server not going to hold patient demographic information from appt $find operation until the booking
- Client needs to resend this information to register patient prior to booking the appointment
- Server needs to return a Patient ID to client for bookingThe patient registration is a separate interaction sandwiched between a hold and book.
Other workflow has the patient registration at the beginning instead of prior to booking...There's still a possible bad state if the final booking fails post-registration, then you have a newly created patient with no context to provide the server around why this was created.
Issuing a hold first prevents most of these, but there are still possible cases where a server might reject the final booking once it has the patient context.
argo-scheduling-bot (Nov 20 2017 at 22:27):
Healthedata1 closed Issue #49
argo-scheduling-bot (Nov 20 2017 at 22:27):
Healthedata1 commented on Issue #49
Discussed on today's call: Keep as separate interactions. The registration and scheduling systems may be separate and is simpler ( at least from a server perspective ) to not comingle this information.
Last updated: Apr 12 2022 at 19:14 UTC
