201709 Provider Directories and Scheduling
Background for Service Provider Directory
If considering implementing more than a simple client, extensive pre-connectathon work is recommended.
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
- Argonaut Scheduling CI Build (Still in Draft)
In addition, the Appointment introduction section on the "usual" workflow can be found here: http://build.fhir.org/appointment.html#126.96.36.199
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
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
- Telstra Health (HealthConnex)
- Touchstone (AEGIS)
- Epic (tentative)
- Cerner tentative)
- Apple (tentative)
- MEDITECH (tentative)
- AthenaHealth (tentative)
- 3rd Party Apps (recruiting)
Service Provider Directory Server
A Server that has Service/Provider directory data in it (with associated schedule information)
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.
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.
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)
4 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
5 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.
6 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)
7 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