argonautproject / scheduling

Argonaut Scheduling and Appointments: This project supports basic patient and provider access to a provider's calendar and appointment requests, including APIs and guidance for searching and publishing a providers schedule andrequesting, cancelling or updating an appointment.
http://www.fhir.org/guides/argonaut/scheduling/
15 stars 2 forks source link

Using a REStful update using PUT or PATCH instead of an operation #27

Closed Healthedata1 closed 6 years ago

Healthedata1 commented 7 years ago

A REStful update using PUT or PATCH instead of an operation with the selected Appointment. Technically the FHIR Server is doing more than storing but this could be used as well.

Pro: lighter weight. Con: the Appointment is modified by the client ?

Others

daliboz commented 7 years ago

Also related to https://github.com/argonautproject/scheduling/issues/32

If we switched this to PUT or PATCH, I assume GET would no longer be an option :)

Healthedata1 commented 7 years ago

The current design assumes the Appointment is updated only by the Server/Scheduler rather than both parties exchanging updated resources so there is only a single source of truth. This was how Cooper had laid it out. I thought about Patch too - the server has to go through the same business rules/processing before updating the Appointment. Happy to discuss - it doesn't change the status and state diagrams..

Eric

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 Tue, Aug 22, 2017 at 11:54 AM, Jenni Syed notifications@github.com wrote:

Also related to #32 https://github.com/argonautproject/scheduling/issues/32

If we switched this to PUT or PATCH, I assume GET would no longer be an option :)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/argonautproject/scheduling/issues/27#issuecomment-324119257, or mute the thread https://github.com/notifications/unsubscribe-auth/AHEU6r0pt-YgPLIWl4nuSGeZnJL2h0Hnks5sayPsgaJpZM4O8efX .

cooperthompson commented 7 years ago

Is this issue (#27) about the Appointment availability query or the Appointment booking? For Appointment availability, long term I think we need a POST operation, but short term I'm ok with just a GET. For Appointment booking, I would think we'd want a POST not GET, since that isn't idempotent.

cooperthompson commented 7 years ago

We had a lot of discussion on the call today. We clarified that the point of discussion wasn't GET vs. PUT/POST, but rather whether Appointment booking should be an Apportionment.interaction vs. a Appointment.$book operation.

Edit: There was actually a question about GET, but we determined that since booking is not an idempotent operation (can lead to overbooking potentially), we'll stick with a POST.

Healthedata1 commented 7 years ago

also discussed canceling a booked appt by end user and was decided to use PATCH there. Likely use PATCH for Amend to if scope is limited (e.g. comments)

Healthedata1 commented 7 years ago

applied here: https://github.com/argonautproject/scheduling/wiki/Operations#define-handling-of-other-outcomes