This wiki has undergone a migration to Confluence found Here

Difference between revisions of "201801 Scheduling"

From HL7Wiki
Jump to navigation Jump to search
(Added TestScripts section)
 
(20 intermediate revisions by one other user not shown)
Line 4: Line 4:
 
__NOTOC__
 
__NOTOC__
  
 +
Zulip Chat stream for this Track is [https://chat.fhir.org/#narrow/stream/argonaut here]  and issues can be posted  [https://github.com/argonautproject/scheduling/issues here]
  
 
===Background For Scheduling===
 
===Background For Scheduling===
  
'''Based upon [https://github.com/argonautproject/scheduling/wiki Argonaut Scheduling project]''' and the  [https://argonautproject.github.io/scheduling/ Argonaut Scheduling Implementation Guide CI Build]
+
This track is based upon [https://github.com/argonautproject/scheduling/wiki Argonaut Scheduling project] and the  '''[https://argonautproject.github.io/scheduling/ Argonaut Scheduling Implementation Guide CI Build]'''It is based upon the FHIR 3.0.1 Standard.
 
 
This track will focus on these transactions
 
 
 
* Appointment Availability Search Operation
 
* Appointment booking Operation
 
* Patient facing Search for their booked Appointment (GET interaction)
 
* Cancels or cancel/reschedules
 
 
 
If creating a client application, this track should require minimal work in advance of the connectathon, though at least a bit of playing is recommendedIf creating a server, advanced preparation will be required, but this scenario should somewhat limit the effort involved.
 
 
 
  
 
<!-- What will be the actions performed by participants? -->
 
<!-- What will be the actions performed by participants? -->
  
In addition, see the [Appointment introduction] section on the "usual" workflow can be found here:
+
For additional background, review the [http://build.fhir.org/appointment.html Appointment] resource especially the section on the "usual" workflow and a discussion on statuses, and what would be expected.
 
 
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==
 
==Submitting WG/Project/Implementer Group==
 
<!-- Who is asking for this track? -->
 
<!-- Who is asking for this track? -->
Patient Administration/[http://argonautwiki.hl7.org/index.php?title=Main_Page#Security_Authorization The Argonaut Project]
+
 
 +
[http://argonautwiki.hl7.org/index.php?title=Main_Page#Security_Authorization The Argonaut Project]
  
 
==Justification==
 
==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.
+
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==
 
==Proposed Track Lead==
  
(tentative) [mailto:ehaas@healthedatainc.com Eric Haas]
+
[mailto:ehaas@healthedatainc.com Eric Haas]
 
 
(tentative) [mailto:brett@riverrockassociates.com Brett Marquard]
 
  
 
==Expected participants==
 
==Expected participants==
 
<!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track -->
 
<!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track -->
  
Provider Directory:
 
  
* Telstra Health (HealthConnex)
+
Servers:
<!-- SureScripts (uncertain) -->
 
* Epic
 
* Sequoia
 
* Touchstone (AEGIS)
 
  
Scheduling:
+
{| class="wikitable"
* Epic (tentative)
+
|Name
* Telstra Health (HealthConnex) (tentative)
+
|Use Case 1
* HealthSamuri (tentative)
+
|Use Case 2
* 3rd Party Apps (recruiting)
+
|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:
 +
 
 +
{| class="wikitable"
 +
|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==
 
==Roles==
Line 74: Line 120:
 
<!-- Provide a description of the capabilities this role will have within the connectathon -->
 
<!-- Provide a description of the capabilities this role will have within the connectathon -->
 
A Server that that processes appointment availability booking requests and allocates either participants, or times to these requests.
 
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 [https://docs.google.com/spreadsheets/d/1Ye_J75cSdYZZLmQ8GcHsPZY1q167dw_adsZlsrObQE0/edit#gid=0 Argo Scheduling Sprint Test Data] to get you started.  The corresponding FHIR resources for the test data has been loaded on the [http://sqlonfhir-stu3.azurewebsites.net/fhir/ Telstra FHIR test server] and can be fetched using the FHIR API.  They are also available as [https://github.com/argonautproject/scheduling/tree/master/connectathon_test_data FHIR bundles in xml format].
  
 
==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]
+
See 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]'''
 +
** 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
 +
*  '''[https://argonautproject.github.io/scheduling/provider-scheduling.html Provider based Scheduling Use Cases]'''
 +
** Use Case 4: Scheduling across systems
 +
** Use Case 5: Scheduling for existing patient across systems
  
:Action: Appointment Availability Search Operation using [https://github.com/argonautproject/scheduling/wiki/Operations#appointmentfind Appointment$find]
+
====... and specifically these transactions====
: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====
+
* Appointment Availability Search Operation
:Action: Client select from list of proposed appointments and PUT/POST to server
+
* Appointment booking Operation
This appointment should have a status of proposed or pending, and participant statuses of needs-action ( review -todo)
+
* Search for booked Appointment
:Precondition: ( review -todo)
+
* Cancels or cancel/reschedules
:Success Criteria: Appointment passes validation against the Appointment schema and schematron, and has these statuses set
+
* Prefetching and updating Slots
:Bonus point: (tbd)
 
  
====Step 3: Confirm and Process Appointment====
+
==TestScript(s)==
Test the ability to interrogate a schedule and confirm and process a requested appointment
+
<!-- Optional (for initial proposal): Provide links to the TestScript instance(s) that define the behavior to be tested.  
: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.
+
These should be committed to SVN under trunk/connectathons/[connectathon]
:Precondition: (tbd)
+
-->
:Success Criteria: The server is able to confirm appt and return status to Client
+
The supporting TestScripts and corresponding fixtures have been committed to the FHIR documents Github repository at: https://github.com/FHIR/documents/tree/master/connectathons/NewOrleansJan2018/Connectathon17/Scheduling
:Bonus: Errors - The server is returns that it can not confirm appt
 
  
====Step 4:  Cancel Appointment====
+
Please note that the available TestScripts test the [http://hl7.org/fhir/2018Jan/appointment.html#status-flow Typical (Work)flow of statuses] as described in the FHIR specification Schedule resource type page.
: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 !! !====
+
==Security and Privacy Considerations==
 
+
<!-- Optional (for initial proposal): Address the topic of Privacy and Security.
=====1 Server rejects the cancellation/amendment =====
+
* What Authentication/Authorization will be used (e.g. SMART on FHIR (OAuth), HEART (UMA/OAuth), IHE IUA (OAuth), generic OAuth, generic SAML, mutual-Auth-TLS), or explicitly indicate that it is out of scope and left to implementations.
 
+
* What Privacy Consent management will be used? When the Consent Resource is used, define how.
(if business rules justify this)<!-- Any additional complexity to make the scenario more challenging -->
+
* What Audit Logging will be used? When the AuditEvent Resource is used, define expectations of what events will be logged and what each AuditEvent will contain.
 +
* How will Provenance be used? Provenance use should be mandated when data is imported from other systems, so as to track that source of that data. Provenance should be used when data is authored by unusual sources, such as the Patient themselves or devices.
 +
* How will security-labels be used? Security-labels are meta tags used to classify the data into various confidentiality, sensitivity, and integrity classifications. These security-labels are then available for use and available for access control decisions.
 +
I am happy to help: JohnMoehrke@gmail.com -- security co-chair
 +
-->
  
=====2  Create Encounter======
 
  
:Action: Create an encounter to represent when a patient arrived at the facility for an appointment created earlier
+
See the [https://argonautproject.github.io/scheduling/index.html#security Argonaut Scheduling Implementation Guide CI Build Use Cases Security and Assumptions sections]
: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
 

Latest revision as of 21:18, 19 January 2018

Return to Jan 2018 Proposals


Zulip Chat stream for this Track is here and issues can be posted here

Background For Scheduling

This track is based upon Argonaut Scheduling project and the Argonaut Scheduling Implementation Guide CI Build. It is based upon the FHIR 3.0.1 Standard.


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

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 Argonaut Scheduling Implementation Guide CI Build Use Cases:

... and specifically these transactions

  • Appointment Availability Search Operation
  • Appointment booking Operation
  • Search for booked Appointment
  • Cancels or cancel/reschedules
  • Prefetching and updating Slots

TestScript(s)

The supporting TestScripts and corresponding fixtures have been committed to the FHIR documents Github repository at: https://github.com/FHIR/documents/tree/master/connectathons/NewOrleansJan2018/Connectathon17/Scheduling

Please note that the available TestScripts test the Typical (Work)flow of statuses as described in the FHIR specification Schedule resource type page.

Security and Privacy Considerations

See the Argonaut Scheduling Implementation Guide CI Build Use Cases Security and Assumptions sections