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

Difference between revisions of "201709 Provider Directories and Scheduling"

From HL7Wiki
Jump to navigation Jump to search
(Created page with "{{subst::Template for FHIR Connectathon Track Proposals}}")
 
 
(37 intermediate revisions by the same user not shown)
Line 1: Line 1:
  
 
[[Category:201709_FHIR_Connectathon_Track_Proposals|Sept 2017 Proposals]]
 
[[Category:201709_FHIR_Connectathon_Track_Proposals|Sept 2017 Proposals]]
 +
 
__NOTOC__
 
__NOTOC__
−
=Track Name=
+
===Background for Service Provider Directory===
 +
If considering implementing more than a simple client, extensive pre-connectathon work is recommended.
 +
 
 +
Specification Page(s):
 +
[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===
 +
 
 +
'''Based upon [https://github.com/argonautproject/scheduling/wiki 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):
 +
 
 +
* [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? -->
 +
 
 +
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==
 
==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]
  
 
==Justification==
 
==Justification==
−
<!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. -->
+
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.
 +
(And hopefully review the Provider Directory created by MiHN, and some mappings on the IHE HPD profile into FHIR)
 +
 
 +
 
 +
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.
  
 
==Proposed Track Lead==
 
==Proposed Track Lead==
−
<!-- Name, email and Skype id of individual who will coordinate the track at the connectathon -->
+
(tentative) Coordinator: [mailto:bpostlethwaite@healthconnex.com.au Brian Postlethwaite](sgtshultzpos)
−
See [[Connectathon_Track_Lead_Responsibilities]]
+
(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)
 +
<!-- SureScripts (uncertain) -->
 +
* Epic
 +
* Sequoia
 +
* Touchstone (AEGIS)
 +
 +
Scheduling:
 +
* Epic (tentative)
 +
* Cerner  tentative)
 +
* MEDITECH (tentative)
 +
* AthenaHealth (tentative)
 +
* 3rd Party Apps (recruiting)
  
 
==Roles==
 
==Roles==
−
Please include information here regarding how much advance preparation will be required if creating a client and/or server.
 
 
<!-- 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 -->
−
===Role 1 Name===
+
===Provider Directory ===
 +
====Service Provider Directory Server====
 +
A Server that has Service/Provider directory data in it
 +
(with associated schedule information)
 +
===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
 +
<!--
 +
===Requester===
 +
Provide a description of the capabilities this role will have within the connectathon
 +
A client that creates appointments (as either booked resources, or requests which need a placer to fill)
 +
-->
 +
====FHIR Server  (EHR)====
 
<!-- 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.
  
 
==Scenarios==
 
==Scenarios==
 
<!-- What will be the actions performed by participants? -->
 
<!-- What will be the actions performed by participants? -->
  
−
===Scenario Step 1 Name===
+
===1 Directory Search - Provider, Location, Organization===
−
:Action: <!--Who does what?  (Use the role names listed above when referring to the participants -->
+
:Action: Perform a search for Provider Directory related resource.
−
:Precondition: <!-- What setup is required prior to executing this step? -->
+
: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)
−
:Success Criteria: <!-- How will the participants know if the test was successful? -->
+
:Precondition: Directory FHIR Resources should already be on a FHIR server to query
−
:Bonus point: <!-- Any additional complexity to make the scenario more challenging -->
+
: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.
 +
 
 +
===2 Scheduling===
 +
 
 +
Background: See the [https://github.com/argonautproject/scheduling/wiki/Use-Cases Use Cases 1 and 2 and Interaction Diagrams]
 +
 
 +
==== Step 1: Availability Search =====
  
−
<!-- Provide a description of each task -->
+
: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)
  
−
==TestScript(s)==
+
====Step 2: Book Appointment====
−
<!-- Optional (for initial proposal): Provide links to the TestScript instance(s) that define the behavior to be tested.
+
:Action: Client select from list of proposed appointments and PUT/POST to server
−
These should be committed to SVN under trunk/connectathons/[connectathon]
+
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 point: server rejects the amendment- (if business rules justify this)<!-- Any additional complexity to make the scenario more challenging -->
  
−
==Security and Privacy Considerations==
+
===3 Create Encounter===
−
<!-- Optional (for initial proposal): Address the topic of Privacy and Security.
+
:Action: Create an encounter to represent when a patient arrived at the facility for an appointment created earlier
−
* 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: An appointment existed that was ready to be turned into an encounter
−
* What Privacy Consent management will be used? When the Consent Resource is used, define how.
+
:Success Criteria: An encounter can be found on the server and can be retrieved through searching on the encounter's appointment search parameter
−
* 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: Can show a history for the encounter and move it through some of the various states
−
* 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
 
−
-->
 

Latest revision as of 15:11, 13 July 2017


Background for Service Provider Directory

If considering implementing more than a simple client, extensive pre-connectathon work is recommended.

Specification Page(s): 

Organization
Location
Practitioner
PractitionerRole
EndPoint
HealthcareService

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):


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

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. (And hopefully review the Provider Directory created by MiHN, and some mappings on the IHE HPD profile into FHIR)


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.

Proposed Track Lead

(tentative) Coordinator: Brian Postlethwaite(sgtshultzpos) (tentative) Brett Marquard

Expected participants

Provider Directory:

  • Telstra Health (HealthConnex)
  • Epic
  • Sequoia
  • Touchstone (AEGIS)

Scheduling:

  • Epic (tentative)
  • Cerner tentative)
  • MEDITECH (tentative)
  • AthenaHealth (tentative)
  • 3rd Party Apps (recruiting)

Roles

Provider Directory

Service Provider Directory Server

A Server that has Service/Provider directory data in it (with associated schedule information)

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

1 Directory Search - Provider, Location, Organization

Action: Perform a search for Provider Directory related resource.
See 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.

2 Scheduling

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 point: server rejects the amendment- (if business rules justify this)

3 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
Retrieved from "https://wiki.hl7.org/w/index.php?title=201709_Provider_Directories_and_Scheduling&oldid=142354"