This wiki has undergone a migration to Confluence found Here

Difference between revisions of "201605 ServicesDirectoryAndScheduling Track"

From HL7Wiki
Jump to navigation Jump to search
 
(15 intermediate revisions by one other user not shown)
Line 2: Line 2:
 
[[Category:201605_FHIR_Connectathon_Track_Proposals|May 2016 Proposals]]
 
[[Category:201605_FHIR_Connectathon_Track_Proposals|May 2016 Proposals]]
 
__NOTOC__
 
__NOTOC__
=Services Directory and Scheduling=
+
= Provider Directories and Scheduling =
 +
 
 +
===Background for Service Provider Directory===
 +
If considering implementing more than a simple client, extensive pre-connectathon work is recommended.
 +
 
 +
Specification Page(s):
 +
[http://hl7.org/fhir/2016May/organization.html Organization]
 +
[http://hl7.org/fhir/2016May/location.html Location]
 +
[http://hl7.org/fhir/2016May/practitioner.html Practitioner]
 +
[http://hl7.org/fhir/2016May/healthcareservice.html HealthcareService]
 +
 
 +
And we are seeking some feeback on the new Directory Support resources:
 +
[http://hl7.org/fhir/2016May/practitionerrole.html PractitionerRole]
 +
[http://hl7-fhir.github.io/endpoint.html Endpoint]
 +
 
 +
===Background For Scheduling===
 +
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.
 +
 
 +
Specification Page(s): [http://hl7.org/fhir/2016May/appointment.html Appointment] [http://hl7.org/fhir/2016May/appointmentresponse.html AppointmentResponse] [http://hl7.org/fhir/2016May/schedule.html Schedule] [http://hl7.org/fhir/2016May/slot.html Slot]
 +
 
 +
<!-- What will be the actions performed by participants? -->
 +
The introduction section on the "usual" workflow can be found here:
 +
http://hl7.org/fhir/2016May/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://hl7.org/fhir/2016May/appointment.html#typical
 +
Which tie together the 4 resources...
  
 
==Submitting WG/Project/Implementer Group==
 
==Submitting WG/Project/Implementer Group==
Line 10: Line 36:
 
==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.  
 
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.
+
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 project will define how FHIR will be used to standardize the exchange of provider directory data. Defining how healthcare organizations can participate in a federated healthcare directory will promote interoperability and innovation. This directory structure can later be extended to support other workflows like electronic scheduling, advanced case management, and automated insurance eligibility checks.
+
 
 +
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 lead into the creation of Appointments based on schedules found associated with the above services/providers, and also verify the workflow of proceeding from a booked appointment into the creation of the Encounter.
 
This track will also lead into the creation of Appointments based on schedules found associated with the above services/providers, and also verify the workflow of proceeding from a booked appointment into the creation of the Encounter.
  
==Proposed Track Lead==
+
==Track Lead==
Brian Postlethwaite (sgtshultzpos)
+
Coordinator: [mailto:bpostlethwaite@healthconnex.com.au Brian Postlethwaite](sgtshultzpos)
  
 
==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 -->
 +
* Telstra Health (HealthConnex)
 
* SureScripts
 
* SureScripts
 
* Epic
 
* Epic
* HealthConnex
 
  
 
==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 -->
===Service Directory Server===
+
===Service Provider Directory Server===
 
A Server that has Service/Provider directory data in it
 
A Server that has Service/Provider directory data in it
 
(with associated schedule information)
 
(with associated schedule information)
Line 36: Line 64:
 
An application that should be used by a provider to search for information to support creating a referral, and can book an appointment on a client's behalf
 
An application that should be used by a provider 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)
  
 +
===Placer===
 +
<!-- Provide a description of the capabilities this role will have within the connectathon -->
 +
A placer is a client (or server) that processes appointment 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 Directory Search===
+
===1 Scenario Directory Search - Provider===
 
:Action: Perform a search for either Practitioner or HealthsareService resources
 
:Action: Perform a search for either Practitioner or HealthsareService resources
 
:Precondition: Directory FHIR Resources should already be on a FHIR server to query
 
:Precondition: Directory FHIR Resources should already be on a FHIR server to query
Line 49: Line 83:
 
<!-- Provide a description of each task -->
 
<!-- Provide a description of each task -->
  
===Scenario Directory Update===
+
===2 Scenario Directory Search - Consumer===
 +
:Action: Perform a search for either Practitioner or HealthsareService resources
 +
: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
 +
 
 +
<!-- Provide a description of each task -->
 +
 
 +
===3 Scenario Directory Update===
 
:Action: <!--Who does what?  (Use the role names listed above when referring to the participants -->
 
:Action: <!--Who does what?  (Use the role names listed above when referring to the participants -->
 
:Precondition: <!-- What setup is required prior to executing this step? -->
 
:Precondition: <!-- What setup is required prior to executing this step? -->
Line 57: Line 99:
 
<!-- Provide a description of each task -->
 
<!-- Provide a description of each task -->
  
===Check Availability===
+
===4 Check Availability===
 
:Action: <!--Who does what?  (Use the role names listed above when referring to the participants -->
 
:Action: <!--Who does what?  (Use the role names listed above when referring to the participants -->
 
:Precondition: <!-- What setup is required prior to executing this step? -->
 
:Precondition: <!-- What setup is required prior to executing this step? -->
Line 65: Line 107:
 
<!-- Provide a description of each task -->
 
<!-- Provide a description of each task -->
  
===Book Appointment===
+
===5 Create Appointment===
:Action: <!--Who does what?  (Use the role names listed above when referring to the participants -->
+
:Action: Create an appointment resource and store on a server (Requester)
:Precondition: <!-- What setup is required prior to executing this step? -->
+
This appointment should have a status of proposed or pending, and participant statuses of needs-action
:Success Criteria: <!-- How will the participants know if the test was successful? -->
+
:Precondition: None
:Bonus point: <!-- Any additional complexity to make the scenario more challenging -->
+
:Success Criteria: Appointment passes validation against the Appointment schema and schematron, and has these statuses set
 +
:Bonus point: Define an Appointment with multiple participants
 +
:Bonus point: Define an appointment with a Location
 +
:Bonus point: Define an Appointment with varied Participant statuses
 +
:Bonus point: Define an Appointment against multiple slots
 +
 
 +
<!-- Provide a description of each task -->
 +
 
 +
===6 Check Schedule===
 +
Test the ability to interrogate a schedule to book an appointment
 +
:Action: Query a server for a schedule/slots
 +
:Action: Create an appointment against one of the slots returned
 +
:Action: Update Slot to mark Status
 +
:Precondition: A Server must have a some schedule and slot resources available to search
 +
:Success Criteria: The server is able to indicate that the client searched for the content, and created an appointment against one of the slots.
 +
:Bonus point: The slot was marked as booked
 +
 
 +
<!-- Provide a description of each task -->
 +
 
 +
===7 Process Appointment (Response)===
 +
:Action: Server recieves an AppointmentResponse resource, and updates the Appointment with details of the participants answer
 +
:Precondition: an appointment existed with a participant status of needs-action<!-- What setup is required prior to executing this step? -->
 +
:Success Criteria: only the participant defined in the appointmentresponse has its status updated as per the response
 +
:Bonus point: 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.
  
 
<!-- Provide a description of each task -->
 
<!-- Provide a description of each task -->
  
===Progress Appointment into an Encounter===
+
===8 Cancel Appointment===
:Action: <!--Who does what?  (Use the role names listed above when referring to the participants -->
+
:Action: Mark an appointment with a cancelled status <!--Who does what?  (Use the role names listed above when referring to the participants -->
:Precondition: <!-- 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: <!-- How will the participants know if the test was successful? -->
+
:Success Criteria: The history of the appointment will show that it had a booked status, then was changed to a cancelled status <!-- How will the participants know if the test was successful? -->
:Bonus point: <!-- Any additional complexity to make the scenario more challenging -->
+
: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 -->
  
 
<!-- Provide a description of each task -->
 
<!-- Provide a description of each task -->
Line 85: Line 150:
 
These should be committed to SVN under trunk/connectathons/[connectathon]
 
These should be committed to SVN under trunk/connectathons/[connectathon]
 
-->
 
-->
 +
TBD

Latest revision as of 11:04, 8 May 2016


Provider Directories and Scheduling

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
HealthcareService

And we are seeking some feeback on the new Directory Support resources:

PractitionerRole
Endpoint

Background For Scheduling

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.

Specification Page(s): Appointment AppointmentResponse Schedule Slot

The introduction section on the "usual" workflow can be found here: http://hl7.org/fhir/2016May/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://hl7.org/fhir/2016May/appointment.html#typical Which tie together the 4 resources...

Submitting WG/Project/Implementer Group

Patient Administration/Implementer Communities

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 lead into the creation of Appointments based on schedules found associated with the above services/providers, and also verify the workflow of proceeding from a booked appointment into the creation of the Encounter.

Track Lead

Coordinator: Brian Postlethwaite(sgtshultzpos)

Expected participants

  • Telstra Health (HealthConnex)
  • SureScripts
  • Epic

Roles

Service Provider Directory Server

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

Patient Consumer application

An application that should be used by a client to search for where services could be provided, and can book an appointment

Provider Consumer application

An application that should be used by a provider to search for information to support creating a referral, and can book an appointment on a client's behalf

Requester

A client that creates appointments (as either booked resources, or requests which need a placer to fill)

Placer

A placer is a client (or server) that processes appointment requests and allocates either participants, or times to these requests.

Scenarios

1 Scenario Directory Search - Provider

Action: Perform a search for either Practitioner or HealthsareService resources
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


2 Scenario Directory Search - Consumer

Action: Perform a search for either Practitioner or HealthsareService resources
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


3 Scenario Directory Update

Action:
Precondition:
Success Criteria:
Bonus point:


4 Check Availability

Action:
Precondition:
Success Criteria:
Bonus point:


5 Create Appointment

Action: Create an appointment resource and store on a server (Requester)

This appointment should have a status of proposed or pending, and participant statuses of needs-action

Precondition: None
Success Criteria: Appointment passes validation against the Appointment schema and schematron, and has these statuses set
Bonus point: Define an Appointment with multiple participants
Bonus point: Define an appointment with a Location
Bonus point: Define an Appointment with varied Participant statuses
Bonus point: Define an Appointment against multiple slots


6 Check Schedule

Test the ability to interrogate a schedule to book an appointment

Action: Query a server for a schedule/slots
Action: Create an appointment against one of the slots returned
Action: Update Slot to mark Status
Precondition: A Server must have a some schedule and slot resources available to search
Success Criteria: The server is able to indicate that the client searched for the content, and created an appointment against one of the slots.
Bonus point: The slot was marked as booked


7 Process Appointment (Response)

Action: Server recieves an AppointmentResponse resource, and updates the Appointment with details of the participants answer
Precondition: an appointment existed with a participant status of needs-action
Success Criteria: only the participant defined in the appointmentresponse has its status updated as per the response
Bonus point: 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.


8 Cancel Appointment

Action: Mark an appointment with a cancelled status
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
Bonus point: server reject a status change to cancelled if an encounter was created - (if business rules justify this)


TestScript(s)

TBD