This wiki has undergone a migration to Confluence found Here
Difference between revisions of "201601 Scheduling"
Jump to navigation
Jump to search
| (7 intermediate revisions by the same user not shown) | |||
| Line 36: | Line 36: | ||
If creating a client application, this track should require minimal work in advance of the connectathon, though at least a bit of playing is recommended. If creating a server, advanced preparation will be required, but this scenario should somewhat limit the effort involved. | If creating a client application, this track should require minimal work in advance of the connectathon, though at least a bit of playing is recommended. If creating a server, advanced preparation will be required, but this scenario should somewhat limit the effort involved. | ||
| − | Specification Page: [http://hl7.org/fhir/2015Sep/appointment.html Appointment] [http://hl7.org/fhir/2015Sep/appointmentresponse.html AppointmentResponse] [http://hl7.org/fhir/2015Sep/schedule.html Schedule] [http://hl7.org/fhir/2015Sep/slot.html Slot] | + | Specification Page(s): [http://hl7.org/fhir/2015Sep/appointment.html Appointment] [http://hl7.org/fhir/2015Sep/appointmentresponse.html AppointmentResponse] [http://hl7.org/fhir/2015Sep/schedule.html Schedule] [http://hl7.org/fhir/2015Sep/slot.html Slot] |
<!-- What will be the actions performed by participants? --> | <!-- What will be the actions performed by participants? --> | ||
| − | The | + | The introduction section on the "usual" workflow can be found here: |
http://hl7.org/fhir/appointment.html#5.27.1.1 | http://hl7.org/fhir/appointment.html#5.27.1.1 | ||
| − | + | ||
| + | If you're trying to work out what statuses mean, and what would be expected, there is a summary at the bottom of that same page including a collection of examples | ||
http://hl7.org/fhir/appointment.html#typical | http://hl7.org/fhir/appointment.html#typical | ||
Which tie together the 4 resources... | Which tie together the 4 resources... | ||
| − | === | + | ===Create Appointment=== |
| − | :Action: <!--Who does what? (Use the role names listed above when referring to the participants --> | + | :Action: Create an appointment resource and store on a server (Requester) |
| − | :Precondition: <!-- What setup is required prior to executing this step? --> | + | This appointment should have a status of proposed or pending, and participant statuses of needs-action |
| − | :Success Criteria: <!-- How will the participants know if the test was successful? --> | + | :Precondition: None |
| − | :Bonus point: <!-- Any additional complexity to make the scenario more challenging --> | + | :Success Criteria: Appointment passes validation against the Appointment schema and schematron, and has these statuses set |
| + | :Bonus point: Define an Appointment with multiple participants | ||
| + | :Bonus point: Define an appointment with a Location | ||
| + | :Bonus point: Define an Appointment with varied Participant statuses | ||
| + | :Bonus point: Define an Appointment against multiple slots | ||
| + | |||
| + | <!-- Provide a description of each task --> | ||
| + | |||
| + | ===Check Schedule=== | ||
| + | Test the ability to interrogate a schedule to book an appointment | ||
| + | :Action: Query a server for a schedule/slots | ||
| + | :Action: Create an appointment against one of the slots returned | ||
| + | :Action: Update Slot to mark Status | ||
| + | :Precondition: A Server must have a some schedule and slot resources available to search | ||
| + | :Success Criteria: The server is able to indicate that the client searched for the content, and created an appointment against one of the slots. | ||
| + | :Bonus point: The slot was marked as booked | ||
| + | |||
| + | <!-- Provide a description of each task --> | ||
| + | |||
| + | ===Process Appointment (Response)=== | ||
| + | :Action: Server recieves an AppointmentResponse resource, and updates the Appointment with details of the participants answer | ||
| + | :Precondition: an appointment existed with a participant status of needs-action<!-- What setup is required prior to executing this step? --> | ||
| + | :Success Criteria: only the participant defined in the appointmentresponse has its status updated as per the response | ||
| + | :Bonus point: If all participants in the appointment are now accepted and the appointment was in pending or proposed then the appointment status can be changed to booked. | ||
| + | |||
| + | <!-- Provide a description of each task --> | ||
| + | |||
| + | ===Cancel Appointment=== | ||
| + | :Action: Mark an appointment with a cancelled status <!--Who does what? (Use the role names listed above when referring to the participants --> | ||
| + | :Precondition: an appointment was present on the server with a booked status <!-- What setup is required prior to executing this step? --> | ||
| + | :Success Criteria: The history of the appointment will show that it had a booked status, then was changed to a cancelled status <!-- How will the participants know if the test was successful? --> | ||
| + | :Bonus point: server reject a status change to cancelled if an encounter was created - (if business rules justify this)<!-- Any additional complexity to make the scenario more challenging --> | ||
<!-- Provide a description of each task --> | <!-- Provide a description of each task --> | ||
Latest revision as of 20:56, 9 January 2016
Scheduling
Submitting WG/Project/Implementer Group
Patient Administration (PA)
Justification
This track will extend on the experience that was had at the last connectathon and help improve the experience with these resources, and extend into the Encounter resource.
Proposed Track Lead
Coordinator: Brian Postlethwaite
Expected participants
Brian Postlethwaite - HealthConnex
Roles
Server
A Server Role can be either a simple FHIR server that just stores the scheduling resources, or could be smart and perform placing/allocation services on the appointment requests coming in.
Requester
A client that creates appointments (as either booked resources, or requests which need a placer to fill)
Placer
A placer is a client (or server) that processes appointment requests and allocates either participants, or times to these requests.
Scenarios
If creating a client application, this track should require minimal work in advance of the connectathon, though at least a bit of playing is recommended. If creating a server, advanced preparation will be required, but this scenario should somewhat limit the effort involved.
Specification Page(s): Appointment AppointmentResponse Schedule Slot
The introduction section on the "usual" workflow can be found here: http://hl7.org/fhir/appointment.html#5.27.1.1
If you're trying to work out what statuses mean, and what would be expected, there is a summary at the bottom of that same page including a collection of examples http://hl7.org/fhir/appointment.html#typical Which tie together the 4 resources...
Create Appointment
- Action: Create an appointment resource and store on a server (Requester)
This appointment should have a status of proposed or pending, and participant statuses of needs-action
- Precondition: None
- Success Criteria: Appointment passes validation against the Appointment schema and schematron, and has these statuses set
- Bonus point: Define an Appointment with multiple participants
- Bonus point: Define an appointment with a Location
- Bonus point: Define an Appointment with varied Participant statuses
- Bonus point: Define an Appointment against multiple slots
Check Schedule
Test the ability to interrogate a schedule to book an appointment
- Action: Query a server for a schedule/slots
- Action: Create an appointment against one of the slots returned
- Action: Update Slot to mark Status
- Precondition: A Server must have a some schedule and slot resources available to search
- Success Criteria: The server is able to indicate that the client searched for the content, and created an appointment against one of the slots.
- Bonus point: The slot was marked as booked
Process Appointment (Response)
- Action: Server recieves an AppointmentResponse resource, and updates the Appointment with details of the participants answer
- Precondition: an appointment existed with a participant status of needs-action
- Success Criteria: only the participant defined in the appointmentresponse has its status updated as per the response
- Bonus point: If all participants in the appointment are now accepted and the appointment was in pending or proposed then the appointment status can be changed to booked.
Cancel Appointment
- Action: Mark an appointment with a cancelled status
- Precondition: an appointment was present on the server with a booked status
- Success Criteria: The history of the appointment will show that it had a booked status, then was changed to a cancelled status
- Bonus point: server reject a status change to cancelled if an encounter was created - (if business rules justify this)
