|
|
| Line 145: |
Line 145: |
| | <!-- What will be the actions performed by participants? --> | | <!-- What will be the actions performed by participants? --> |
| | | | |
| − | Background: See the [https://github.com/argonautproject/scheduling/wiki/Use-Cases Use Cases 1 and 2 and Interaction Diagrams]
| + | See the the Argonaut Scheduling Implementation Guide CI Build Use Cases: |
| | | | |
| − | ==== Step 1: Availability Search =====
| + | * [https://argonautproject.github.io/scheduling/patient-scheduling.html Patient based Scheduling Use Cases] |
| − | | + | * [https://argonautproject.github.io/scheduling/provider-scheduling.html Provider based Scheduling Use Cases] |
| − | :Action: Appointment Availability Search Operation using [https://github.com/argonautproject/scheduling/wiki/Operations#appointmentfind Appointment$find]
| |
| − | :Precondition: The Organization/Location/Practitioner or HealthcareService has an endpoint defined to a FHIR server where a Schedule/Slot can be queried ( othersTBD) | |
| − | :Success Criteria: Return a list of available appts
| |
| − | :Bonus point: Errors ( others tbd)
| |
| − | | |
| − | ====Step 2: Book Appointment====
| |
| − | :Action: Client select from list of proposed appointments and PUT/POST to server
| |
| − | This appointment should have a status of proposed or pending, and participant statuses of needs-action ( review -todo)
| |
| − | :Precondition: ( review -todo)
| |
| − | :Success Criteria: Appointment passes validation against the Appointment schema and schematron, and has these statuses set
| |
| − | :Bonus point: (tbd)
| |
| − | | |
| − | ====Step 3: Confirm and Process Appointment====
| |
| − | Test the ability to interrogate a schedule and confirm and process a requested appointment
| |
| − | :Action: Server receives an Appointment resource, and updates the Appointment with details of the participants answer...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.
| |
| − | :Precondition: (tbd)
| |
| − | :Success Criteria: The server is able to confirm appt and return status to Client
| |
| − | :Bonus: Errors - The server is returns that it can not confirm appt
| |
| − | | |
| − | ====Step 4: Cancel Appointment====
| |
| − | :Action: Client PUTs an appointment with a cancelled status ( how to do this?)
| |
| − | :Action: Server receives an cancel Appointment resource, and processes. ( how to do this?)
| |
| − | :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 ( detail tbd) <!-- 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 -->
| |
| − | ====Step 5: Amend or Change Appointment====
| |
| − | :Action: Client PUTs an amended appointment ( how to do this?)
| |
| − | :Action: Server receives an amended Appointment resource, and processes. (how to do this?)
| |
| − | :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 statusand several versions (detail tbd) <!-- How will the participants know if the test was successful? -->
| |
| − | | |
| − | ==== !!! Bonus Round !! !====
| |
| − | | |
| − | =====1 Server rejects the cancellation/amendment =====
| |
| − | | |
| − | (if business rules justify this)<!-- Any additional complexity to make the scenario more challenging -->
| |
| − | | |
| − | =====2 Create Encounter======
| |
| − | | |
| − | :Action: Create an encounter to represent when a patient arrived at the facility for an appointment created earlier
| |
| − | :Precondition: An appointment existed that was ready to be turned into an encounter
| |
| − | :Success Criteria: An encounter can be found on the server and can be retrieved through searching on the encounter's appointment search parameter
| |
| − | :Bonus point: Can show a history for the encounter and move it through some of the various states
| |
Return to Jan 2018 Proposals
Background For Scheduling
This track is based upon Argonaut Scheduling project and the Argonaut Scheduling Implementation Guide CI Build
This track will focus on these Use Cases:
- Patient based Scheduling Use Cases
- Use Case 1: Patient Portal Scheduling for existing patients
- Use Case 2: Open Scheduling for new patient or existing patient
- Use Case 3 Prefetching Open Slots
- Provider based Scheduling Use Cases
- Use Case 4: Scheduling across systems
- Use Case 5: Scheduling for existing patient across systems
... and specifically these transactions
- Appointment Availability Search Operation
- Appointment booking Operation
- Search for booked Appointment
- Cancels or cancel/reschedules
- Prefetching and updating Slots
For additional background, review the Appointment resource especially the section on the "usual" workflow and a discussion on statuses, and what would be expected.
Submitting WG/Project/Implementer Group
The Argonaut Project
Justification
The Argonaut Scheduling Project is a vendor agnostic specification providing FHIR RESTful APIs and guidance for access to and booking of appointments for patients by both patient and practitioner end users. This specification is based on FHIR Version 3.0.1 and specifically the Scheduling and Appointment resources.
Proposed Track Lead
Eric Haas
Expected participants
Scheduling:
Servers:
| Name
|
Use Case 1
|
Use Case 2
|
Use Case 3
|
Use Case 4
|
Use Case 5
|
| Epic
|
|
|
|
X
|
X
|
| Telstra Health (HealthConnex)
|
X
|
|
|
|
|
| HealthSamuri (tentative)
|
X
|
|
|
|
|
| Health eData Inc (facade)
|
X
|
|
|
|
|
Clients:
| Name
|
Use Case 1
|
Use Case 2
|
Use Case 3
|
Use Case 4
|
Use Case 5
|
| ShareCare
|
|
|
|
|
|
| ZocDoc
|
|
|
X
|
|
|
| Health eData Inc (PostMan Test Client)
|
X
|
X
|
X
|
X
|
X
|
Roles
Appointments
Provider or 3rd Party consumer application (Client)
An application that should be used by an end user (e.g., patient or practitioner) to search for information to support creating a referral, and can book an appointment on a client's behalf
FHIR Server (EHR)
A Server that that processes appointment availability booking requests and allocates either participants, or times to these requests.
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. To somewhat limit the effort involved we have provided a simple set Argo Scheduling Sprint Test Data to get you started. The corresponding FHIR resources for the test data has been loaded on the Telstra FHIR test server and can be fetched using the FHIR API. They are also available as FHIR bundles in xml format.
Scenarios
See the the Argonaut Scheduling Implementation Guide CI Build Use Cases:
