Appointment Response Profile

Canonical	../StructureDefinition/nexus-appointment-response
Status	draft · 1.26.0
Base	AppointmentResponse (constraint)
Source	FSH · JSON

A participant's answer to a booking: whether the person an appointment is for has accepted it, is still deciding, or has declined. Written by an integrating system outside the EMR and read wherever a booking's confirmation state is displayed, which is derived from participantStatus rather than from Appointment.status. An answer supersedes an earlier answer rather than amending it, and the latest one describes where the booking stands.

Overview

Handbook: Scheduling

The narrative treatment -- what this is for, why it is shaped this way, and how it is used.

An appointment response is a participant's answer to a booking: whether the person an appointment is for has accepted it, is still deciding, or has declined it.

This is where a booking's confirmation state lives. It is not on the appointment. A day sheet showing a row as Confirmed or Reminder sent is reading participantStatus here; a consumer reading only Appointment.status will see booked for a confirmed booking, a reminded booking and an unanswered one alike, with nothing to separate them.

This specification previously said the opposite

Earlier releases listed AppointmentResponse as out of scope and stated that confirmation was represented through Appointment.status transitions. Both halves were wrong. The type is written into this estate today, and confirmation is derived from participantStatus. If you implemented against the earlier statement, the change you need is to read this resource alongside the appointment -- see the handbook's confirmation model for how the two combine.

An answer is a separate fact, not a change to the booking

Recording an answer does not alter the appointment. Nothing here cancels a booking: a declined response leaves the slot booked in the schedule until somebody acts on it, and a consumer that treats a refusal as a cancellation will free a slot the practice still believes is held.

The relationship runs one way. Read the appointment for where the visit stands -- booked, arrived, fulfilled, cancelled, no-show -- and read the answer only for a booking that has not resolved past that point. A late answer must not reach back and repaint a booking somebody has already arrived for.

An answer supersedes; it does not amend

A participant may answer the same booking more than once -- a reminder is acknowledged, and the answer later changes. Every consumer here keeps the latest answer per appointment and ignores the rest.

Recency is meta.lastUpdated, and that is not a convenience. R4 gives this resource no date of its own: start and end are a proposed new time for the appointment, not a timestamp on the response, and R4 defines no date search parameter on this type either. So the server's own stamp is the only ordering available. A consumer that needs the latest must choose it rather than trust the order a search returned, because a FHIR server may ignore a _sort it does not support and answer unsorted without erroring.

There is no delete. An answer is withdrawn by a newer answer, which is why this profile is exposed for reading and writing but never for deletion.

tentative is ambiguous, and the ambiguity is structural

participantStatus is mandatory in R4. A producer that omits it would have its whole resource rejected and would see only a validation failure it could not act on -- so an omitted or blank status is filled in as tentative rather than refused.

tentative therefore means either that the participant is still deciding or that the producer said nothing, and the two are indistinguishable from the resource. Do not read it as evidence that anybody was asked. A status a producer did supply is never rewritten, including one outside the value set: that is a sender error the store reports, not something to silently replace with an answer nobody gave.

The defaulted-tentative example is exactly this case.

All four codes, not three

The binding is R4's own and is deliberately not narrowed. Three codes drive a display state -- accepted, tentative, declined. needs-action drives none, because "has been asked and has not answered" is what an unanswered booking already says, and promoting it would make "reminder sent" stop meaning that something was sent.

That is a statement about what surfaces do with the codes, not a restriction on which may be written. needs-action is legal here and is produced. A consumer should expect all four and treat an unrecognised value as no answer at all.

Who answered, and why an absent actor matters

actor is optional, matching base R4, and a producer outside the estate may record an answer against a booking without naming the party who gave it.

The consequence is invisible until a chart looks empty: R4's patient search parameter on this type resolves through actor, so an answer with no actor is unreachable by any patient-scoped read. It is still reachable by the appointment it answers, which is how a day's board finds it. Populate actor wherever the producing system knows who answered.

What this profile does not describe

start and end are R4's counter-proposal mechanism -- a participant declining the time offered while proposing another. Nothing in this estate negotiates a time that way; a new time is a change to the appointment. participantType and comment pass through unchanged. None of the three is constrained here, and meeting one means meeting data this specification does not describe.

Terminology bindings

Path	Strength	Value set
AppointmentResponse.participantStatus	required	participationstatus