InterweaveAppointment

FHIR Profile

The Notts Care Record will use the following Interweave Profiles, as published in the Interweave Implementation Guide:

Notts Guidance

Encounters vs Appointments

Whilst the terms “Encounter” and “Appointment” might be used interchangeably in everyday speech, in FHIR they have specific meanings:

  • An Appointment predominantly describes a plan for the future
  • An Encounter generally describes something that is happening now, or has occurred in the past

In general therefore:

  • An Appointment will lead to an Encounter - when the patient attends
  • An Encounter may or may not come from an Appointment (ie scheduled vs unscheduled care)

The picture is further complicated as FHIR does allow an Encounter to be created with status “planned”, however this is not recommended for the Notts Care Record and should normally be represented instead with an Appointment.

The main point of the Appointment is to show plans for the future – hence enabling providers to avoid certain days slots if the patient is already booked. It also would support proactive notifications … alert all providers who have an appointment with patient xyz in the next ‘n’ days, if that individual has an unplanned hospital admission.

However, there is an expectation that the Appointment will be updated with cancellations/DNA using the Appointment.status

The Outpatient Encounter that results from an appointment (assuming the patient turns up and the Encounter happens) would be linked using Encounter.appointment

Mandatory fields

The following mandatory fields are defined:

  1. Status - this is already mandatory in FHIR. Note that for future appointments it will be important to keep this status up-to-date.

  2. Service Type - to describe the type of appointment and/or clinic. We pre-adopt the UKCore value set (based on SNOMED refset 1127531000000102: Services Simple Reference Set) - for consistency with the Encounter, and because it is more relevant than the default FHIR example and also covers social care

  3. Participant: Subject - rather unusually, the FHIR Appointment does not actually have a "subject" field, but instead a multi-purpose "participant" field. It is therefore mandatory to have exactly one "participant" of type "subject" to identify the Patient involved.

Must Support fields

In addition the following fields are "Must Support" - ie they must be populated if relevant and known.

  1. Identifier - a Local Id should be provided, such that could be quoted if manually getting in touch to find out more

  2. Start - the date/time that an appointment is to take place
    the End* dateTime must also be provided when there is a Start - this can be challenging for providers, as many Line of Business Susytems do not include an end time. In there cases it is suggested providers use a default interval (e.g. 30 mins)
    (Note that FHIR requires this field to be populated for appointments that are not at status “proposed” or “cancelled”)

  3. Appointment Type - a simple list of codes eg "routine", "emergency" etc. We add a value for "urgent" to cover scheduled but urgent appointments.

  4. Description - any other title or text to further describe the appointment

  5. Participant: Primary Performer - a reference to the main practitioner involved, once they have been allocated.

  6. Participant: Location - again, rather unusually, the location is considered as another "participant" in the FHIR Appointment. A reference to the location is therefore required, once this has been allocated.

    • Note that a location that is as granular as possible should be provided, although what this means may vary by Data Provider. Some may be able to allocate locations down to the "room" level - with this obviously being essential if the aim is to guide the patient directly to the right place. Others may allocate only at a "ward" or even "site" level - with the patient having to ask for further directions on arrival.

  7. Reason: A long list of SNOMED codes to describe different reasons which have led to the Appointment.

    We pre-adopt the value set used in R4. This builds on the existing STU3 list covering SNOMED codes for "Clinical Finding" and "Procedure", and adds codes for "Context-dependent categories" (Social Care) and "Events" (A&E)

  8. Delivery Channel (Care Connect Extension) - simple and useful field to indicate whether in-person, telephone, or video

  9. Appointment Cancellation Reason (Extension, from R4) - obviously only relevant if the appointment is cancelled, but then useful to populate. (CareConnect offers a free-text extension - however we replace this by pre-adopting the field from R4 which offers a better coded list).


Click here to see an example of an Appointment for an Outpatient Visit