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.

Examples

Answer Stored Without a Status · Booking Confirmed by the Patient

Answer Stored Without a Status

An answer that arrived carrying neither a participantStatus nor an actor. The element is mandatory in R4, so it is filled in as tentative rather than the resource being rejected and the answer lost -- which is why tentative means either that the participant is deciding or that the producer said nothing. With no actor it is invisible to a patient-scoped read, though a search naming the appointment still finds it

AppointmentResponse/nexus-appointment-response-defaulted-tentative — claims conformance to Appointment Response Profile

{
  "resourceType": "AppointmentResponse",
  "id": "nexus-appointment-response-defaulted-tentative",
  "meta": {
    "profile": [
      "../StructureDefinition/nexus-appointment-response"
    ],
    "lastUpdated": "2026-05-29T09:12:47.001-04:00"
  },
  "text": {
    "status": "generated",
    "div": "<div xmlns='http://www.w3.org/1999/xhtml'><p>An answer that arrived carrying neither a status nor an actor. <code>participantStatus</code> is mandatory in R4, so the resource as sent could not be stored at all; it is filled in as <code>tentative</code> rather than rejected, because rejecting it would discard the only record that a response existed.</p><p><strong>So <code>tentative</code> here does not mean the patient is deciding.</strong> It means the producer said nothing, and the two are indistinguishable from the resource. A day sheet renders this booking as <em>Reminder sent</em>, which is the weakest claim the display can make; do not read it as evidence that anybody was asked or answered.</p><p><strong>With no <code>actor</code>, this answer is invisible to a patient-scoped read.</strong> R4's <code>patient</code> search parameter on this type resolves through <code>actor</code>, so the chart timeline will not find it. The day sheet still will, because it searches by the appointment.</p><p><strong>The <code>participantType</code> below is here only because R4 requires one of the two.</strong> <code>apr-1</code> is the type's single invariant -- <em>either the participantType or actor must be specified</em> -- so an answer naming neither cannot be stored at all, and a producer that omits the actor has to say something about the role instead. The generic <code>PART</code> is what is recorded: someone answered, and the resource does not say in what capacity. It is not a stand-in for the missing actor, and nothing should be inferred from it.</p></div>"
  },
  "appointment": {
    "reference": "Appointment/nexus-emr-core-appointment-example-with-requestedPeriod",
    "display": "Avery Linwood, requested-period booking"
  },
  "participantType": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/v3-ParticipationType",
          "code": "PART",
          "display": "Participation"
        }
      ]
    }
  ],
  "participantStatus": "tentative"
}