Closed briandiggle closed 7 years ago
@briandiggle worth putting through the decision log but think the second option of stating that the provider system is responsible is sensible. Note, we will need a test case and suitable error handling guidance for this one as well.
It is worth noting that the slots to be booked must be consecutive. Therefore a "block booking" could not be made across multiple schedules.
I would image that provider systems would have logic in place already to protect against such "block bookings" being made from other contexts, and that business logic to be applied for gpconnect interactions would follow that.
Each appointment booking is associated with a patient record. Healthcare organisations for appropriate use of patient record information. Therefore local standard best-practice at consumers (booking organisation) can be assumed to be followed - consumers would be acting illegally if using a particular patient to make a block booking.
In addition, it is worth stating that provider systems are responsible to implement business rules to protect the responsible use of the booking API along the lines of those business rules already in place to prevent misuse outside of the GPConnect API implementation.
Decision taken that Book Appointment API will not restrict the booking of numerous adjacent slots, but guidance to be added as in previous comment
appointments_use_case_book_an_appointment.html
Do we need to put limits on the amount of slots which can be booked by a consumer? To protect against block bookings, or bookings which are for long time periods? Should we simply state that the provider system is responsible for implementing any business logic required here?