Appointment FHIR Resource Proposal

Appointment

Owning committee name

Patient Administration

Contributing or Reviewing Work Groups

• "None"

FHIR Resource Development Project Insight ID

pending

Scope of coverage

Appointment resources are used to provide information about a planned meeting that may be in the future or past. Each Appointment resource only describes a single meeting. A series of repeating visits would require multiple Appointment resources be created, one for each visit.

Examples include a scheduled surgery, a follow-up for a clinical visit, a scheduled conference call between clinicians to discuss a case, the reservation of a piece of diagnostic equipment for a particular use, etc. The visit scheduled by an appointment may be in person or remote (by phone, video conference, etc.) All that matters is that the time and usage of one or more individuals, locations and/or pieces of equipment is being fully or partially reserved for a designated period of time.

This definition takes the concepts of appointments in a clinical setting and also extends them to be relevant in the community healthcare space, and also ease exposure to other appointment / calendar standards widely used outside of healthcare.

This resource is not expected to handle recurring appointments due to the complexities of recurrences, time-zone transitions, and status changes of variations to the recurrence. If a user of an appointment desires to handle recurrences, they will need to "expand" the recurrences as separate resource instances and use some form of identifier to "join" them together as the one logical collection.

This resource does not also cover a more extensive definition/description of the actual service that is to take place during this appointment. This is likely to be the content of another new resource "Healthcare Service".

This new "Healthcare Service" would cover a multi-level category and type structure to assist in the discovery of what services are provided in an organization/location.

There are a number of resources that are associated with making appointments:

• Availability (Schedule) – grouper for slots that can be used for an appointment (is referenced by the slot – not the other way around)
• Slot – a specific single unit of time (may come from a slot) that can be used for an appointment. Has a status (available
• Appointment. Represents an actual appointment between 2 or more parties. Can have different status (proposed, confirmed, declined etc), The appointment can be created by any participant.
• AppointmentResponse. Indicates whether the participant will attend the appointment. Each participant will have a separate appointmentResponse. There is no resource that is a ‘request resource’. Each participant in the appointment has a status that indicates a new appointment request.
• HeathCareService – a service that can have appointments made against it (like a doctors clinic).
• EpisodeOfCare - groups together encounters for a single person/purpose
• SeventhResource – (?Brian)

A common Scenario for using these resources would be:

• A User (which could be a patient, admin person or a clinician) creates an Appointment resource with a status of 'new'. It would have any number of participants. The person making the appointment is termed the 'Requester'.
• Participants monitor the creation of appointment resources where they are a participant using some implementation specific architecture such as pub/sub. They create AppointmentResponse resources indicating their acceptance (or not) of the appointment using the appointmentResponse.participantStatus.
• Once all participants have created appointmentResponse resources, the appointmentStatus can be updated.

At any stage, the overall status of the appointment workflow can be determined by examining the Appointment and associated AppointmentResponse resource.

RIM scope

Act (ActMood = ActMoodAppointment or ActMoodAppointmentRequest)

Resource appropriateness

Many systems already exchange appointment information using iCal appointments, and some use the HL7v2 schedule messages, or proprietary format messages.

The existing iCal standard does provide a good basis that is widely accepted by many (mostly non-healthcare related) software packages. However we would like to extend these basic features to better meet the complex needs in the healthcare space where transparency and traceability is critical.

Expected implementations

This resource is expected to be implemented by scheduling systems used by community clinics, general practice and specialists to receive and publish their appointments directly to/from users external to the organization providing the information.

Content sources

The appointment resource has a lot of similarities and has been inspired by the iCal standard, and as such there will be a mapping provided to this standard.

We also considered the HL7 v2 and v3 schedule messages and models which are also closely related.

Example Scenarios

A Physio-Therapy clinic that has its available times published via Availability and Slot resources wants to be able to accept appointment requests from users outside the organization.

Appointment resources would exist for appointments that have occurred in the past, are scheduled to occur in the future, and also requested appointments which may occur once accepted/approved.

Resource Relationships

The Appointment Resource will reference any slots that it is booking to, along with the participants that are involved in the appointment, such as the patient and provider (but not restricted to just these). It will also reference the Location resource where the appointment is to take place.

The Appointment will be referenced by both the Encounter, and also the AppointmentResponse, where replies to requests are made.

Timelines

Given the progress to date, we expect that this resource will be ready for inclusion in the next Ballot (expecting September 2014) the resource has already undergone a great deal of review in PA over the last 6 months.

gForge Users

brian_pos ewoutkramer grahameg