This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "201801 Scheduling"

From HL7Wiki
Jump to navigation Jump to search
(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...")
 
(Added TestScripts section)
 
(23 intermediate revisions by one other user not shown)
Line 3: Line 3:
  
 
__NOTOC__
 
__NOTOC__
===Background for Service Provider Directory===
 
If considering implementing more than a simple client, extensive pre-connectathon work is recommended.
 
  
Specification Page(s):
+
Zulip Chat stream for this Track is [https://chat.fhir.org/#narrow/stream/argonaut hereand issues can be posted [https://github.com/argonautproject/scheduling/issues here]
[http://build.fhir.org/organization.html Organization]
 
[http://build.fhir.org/location.html Location]
 
[http://build.fhir.org/practitioner.html Practitioner]
 
  [http://build.fhir.org/practitionerrole.html PractitionerRole]
 
  [http://build.fhir.org/endpoint.html EndPoint]
 
[http://build.fhir.org/organization.html HealthcareService]
 
  
 
===Background For Scheduling===
 
===Background For Scheduling===
  
'''Based upon [https://github.com/argonautproject/scheduling/wiki Argonaut Scheduling project]'''
+
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.
 
 
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):
 
 
 
* [http://build.fhir.org/ig/argonautproject/scheduling/index.html Argonaut Scheduling CI Build (Still in Draft)]
 
** Specifically [http://build.fhir.org/ig/argonautproject/scheduling/profiles.html Profiles] an [http://build.fhir.org/ig/argonautproject/scheduling/operations.html Operations] defined within this Implementation Guide.
 
  
 
<!-- What will be the actions performed by participants? -->
 
<!-- What will be the actions performed by participants? -->
  
In addition, 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.
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==
 
==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==
A key challenge of healthcare is knowing about the resources available in the local, regional, and global healthcare networks. When a patient's care is transitioned from one setting to another, it's critical to know about the doctors, hospitals and clinics available to receive that patient. When a patient is travelling, it improves care when local healthcare facilities can retrieve the patient's up to date medical history  from a primary care provider.
 
There are currently no widely adopted standards for exchanging this directory information. Currently, healthcare organizations use a variety of labor intensive processes to gather, normalize, de-duplicate and consume this data. They share custom flat files, scrape web pages, or pay 3rd parties to curate their practitioner data. Organizational data is often isolated in different networks and aren't easily shared.
 
  
  
This track will test how FHIR can be used to standardize the exchange of services/provider directory data. Defining how healthcare organizations can participate in a federated healthcare directory will promote interoperability and innovation.
+
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.
(And hopefully review the Provider Directory created by MiHN, and some mappings on the IHE HPD profile into FHIR)
 
  
 +
==Proposed Track Lead==
  
This track will also 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.
+
  [mailto:ehaas@healthedatainc.com Eric Haas]
 
 
==Proposed Track Lead==
 
(tentative) Coordinator: [mailto:bpostlethwaite@healthconnex.com.au Brian Postlethwaite](sgtshultzpos)
 
(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
* Cerner  tentative)
+
|Use Case 1
* MEDITECH (tentative)
+
|Use Case 2
* AthenaHealth (tentative)
+
|Use Case 3
* 3rd Party Apps (recruiting)
+
|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==
 
<!-- 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 -->
===Provider Directory ===
+
 
====Service Provider Directory Server====
 
A Server that has Service/Provider directory data in it
 
(with associated schedule information)
 
 
===Appointments===
 
===Appointments===
 
====Provider or 3rd Party consumer application  (Client)====
 
====Provider or 3rd Party consumer application  (Client)====
Line 97: 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? -->
  
===1 Directory Search - Provider, Location, Organization===
+
See the Argonaut Scheduling Implementation Guide CI Build Use Cases:
:Action: Perform a search for Provider Directory related resource.
 
:See '''[http://argonautwiki.hl7.org/index.php?title=2016_11_Argonaut_Provider_Directory_Connectathon_2 Argonaut Provider Directory Connectathon]''' for  1-6 (which have example queries there also)
 
:Precondition: Directory FHIR Resources should already be on a FHIR server to query
 
:Success Criteria: The desired resources were found
 
:Bonus point: The criteria for the resources used several restrictions, possibly Specialty or Location
 
  
We would also like to test to see if extracts can work using paging over an open search, or history can work in these scenarios.
+
* '''[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
  
===2 Scheduling===
+
====... and specifically these transactions====
  
Background: See the [https://github.com/argonautproject/scheduling/wiki/Use-Cases Use Cases 1 and 2 and Interaction Diagrams]
+
* Appointment Availability Search Operation
 +
* Appointment booking Operation
 +
* Search for booked Appointment
 +
* Cancels or cancel/reschedules
 +
* Prefetching and updating Slots
  
==== Step 1: Availability Search =====
+
==TestScript(s)==
 +
<!-- Optional (for initial proposal): Provide links to the TestScript instance(s) that define the behavior to be tested. 
 +
These should be committed to SVN under trunk/connectathons/[connectathon]
 +
-->
 +
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
  
:Action: Appointment Availability Search Operation using [https://github.com/argonautproject/scheduling/wiki/Operations#appointmentfind Appointment$find]
+
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.
: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====
+
==Security and Privacy Considerations==
:Action: Client select from list of proposed appointments and PUT/POST to server
+
<!-- Optional (for initial proposal): Address the topic of Privacy and Security.
This appointment should have a status of proposed or pending, and participant statuses of needs-action ( review -todo)
+
* 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.
:Precondition: ( review -todo)
+
* What Privacy Consent management will be used? When the Consent Resource is used, define how.
:Success Criteria: Appointment passes validation against the Appointment schema and schematron, and has these statuses set
+
* 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.
:Bonus point: (tbd)
+
* 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.
====Step 3:  Confirm and Process Appointment====
+
I am happy to help: JohnMoehrke@gmail.com -- security co-chair
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 point: server rejects the amendment- (if business rules justify this)<!-- Any additional complexity to make the scenario more challenging -->
 
  
===3 Create Encounter===
+
See the [https://argonautproject.github.io/scheduling/index.html#security Argonaut Scheduling Implementation Guide CI Build Use Cases Security and Assumptions sections]
: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
 

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