Revision as of 23:38, 18 October 2017

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.

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

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.

2 Scheduling

Step 1: Availability Search =

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)