Difference between revisions of "201801 Scheduling"
(Created page with "[http://wiki.hl7.org/index.php?title=Category:201801_FHIR_Connectathon_Track_Proposals Return to Jan 2018 Proposals] Category:201801_FHIR_Connectathon_Track_Proposals|Jan 20...") |
|||
Line 3: | Line 3: | ||
__NOTOC__ | __NOTOC__ | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
===Background For Scheduling=== | ===Background For Scheduling=== | ||
Line 48: | Line 39: | ||
==Justification== | ==Justification== | ||
− | |||
− | |||
− | This track will | + | This track will focus on the steps to support basic patient and provider access to a provider's calendar and appointment requests. For this connectathon the scheduling tract activities are distinct from the the provider directory tracts. However, the assumption is that, in the future, the endpoints will be pre-coordinated and the servers will be linked to the provider directories. |
− | |||
+ | ==Proposed Track Lead== | ||
− | + | (tentative) [mailto:ehaas@healthedatainc.com Eric Haas] | |
− | |||
− | |||
(tentative) [mailto:brett@riverrockassociates.com Brett Marquard] | (tentative) [mailto:brett@riverrockassociates.com Brett Marquard] | ||
Line 75: | Line 62: | ||
Scheduling: | Scheduling: | ||
* Epic (tentative) | * Epic (tentative) | ||
− | * | + | * Telstra Health (HealthConnex) (tentative) |
− | + | * HealthSamuri (tentative) | |
− | * | ||
* 3rd Party Apps (recruiting) | * 3rd Party Apps (recruiting) | ||
==Roles== | ==Roles== | ||
<!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on --> | <!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on --> | ||
− | + | ||
− | |||
− | |||
− | |||
===Appointments=== | ===Appointments=== | ||
====Provider or 3rd Party consumer application (Client)==== | ====Provider or 3rd Party consumer application (Client)==== | ||
Line 100: | Line 83: | ||
==Scenarios== | ==Scenarios== | ||
<!-- 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] | Background: See the [https://github.com/argonautproject/scheduling/wiki/Use-Cases Use Cases 1 and 2 and Interaction Diagrams] | ||
Line 146: | Line 118: | ||
:Precondition: an appointment was present on the server with a booked status <!-- What setup is required prior to executing this step? --> | :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? --> | :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 | :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 | :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 | :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 | :Bonus point: Can show a history for the encounter and move it through some of the various states |
Revision as of 23:49, 18 October 2017
Background For Scheduling
Based upon Argonaut Scheduling project
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.
This track will focus on these transactions
- Appointment Availability Search Operation
- Appointment booking Operation
- Patient facing Search for their booked Appointment (GET interaction)
- Handling of other outcomes
- Cancels or cancel/reschedules
- Amends or changes appointments
Specification Page(s):
- Argonaut Scheduling CI Build (Still in Draft)
- Specifically Profiles an Operations defined within this Implementation Guide.
In addition, the Appointment introduction section on the "usual" workflow can be found here:
http://build.fhir.org/appointment.html#5.29.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://build.fhir.org/appointment.html#typical Which tie together the Appointment, Slot, Schedule and AppointmentResponse resources.
Submitting WG/Project/Implementer Group
Patient Administration/The Argonaut Project
Justification
This track will focus on the steps to support basic patient and provider access to a provider's calendar and appointment requests. For this connectathon the scheduling tract activities are distinct from the the provider directory tracts. However, the assumption is that, in the future, the endpoints will be pre-coordinated and the servers will be linked to the provider directories.
Proposed Track Lead
(tentative) Eric Haas
(tentative) Brett Marquard
Expected participants
Provider Directory:
- Telstra Health (HealthConnex)
- Epic
- Sequoia
- Touchstone (AEGIS)
Scheduling:
- Epic (tentative)
- Telstra Health (HealthConnex) (tentative)
- HealthSamuri (tentative)
- 3rd Party Apps (recruiting)
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.
Scenarios
Background: See the Use Cases 1 and 2 and Interaction Diagrams
Step 1: Availability Search =
- Action: Appointment Availability Search Operation using 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
- Success Criteria: The history of the appointment will show that it had a booked status, then was changed to a cancelled status ( detail tbd)
- Bonus point: server reject a status change to cancelled if an encounter was created - (if business rules justify this)
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
- Success Criteria: The history of the appointment will show that it had a booked statusand several versions (detail tbd)
!!! Bonus Round !! !
1 Server rejects the cancellation/amendment
(if business rules justify this)
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