Profil Termin

Ziel

Patienten erhalten von Krankenversorgern Termine für ihren Besuch in der Gesundheitseinrichtung. Der Patient benötigt für einen Termin neben Datum und Uhrzeit auch weiterführende Informationen, wie den Konsultationsgrund, den Ort sowie einen Ansprechpartner. Termine vermitteln dem Patienten weiterhin Informationen zu weiteren Begleitumständen, d.h. der Patient soll nüchtern kommen, soll Unterlagen oder einen Übersetzer mitbringen, die nicht ausschließlich im Freitext vermittelt werden sollen, um z.B. App-Unterstützung zu ermöglichen.

Dahingegen werden Krankenhausintern Termine für die Ressourcenplanung verwendet, in der Regel besteht deshalb ein nach außen zum Patienten kommunizierter Termin intern aus mehreren Terminen, die nicht zum Patienten exponiert werden sollen. Dieses Datenelement soll deshalb nur die nach außen kommunizierten Termine abdecken.

Terminelemente ermöglichen ein Bestätigen oder Absagen des Termines.

Auf Basis dieser Datenelemente können angeschlossene Applikationen (z.B. Patienten-Smartphone-App) Features wie Erinnerungen oder Meldungen zu Überschneidungen anbieten.

Definition der Ressource

Spalten "Klinik" und "Patient" geben die Relevanz für die jeweilige Partei an und ob eine Änderung möglich sein soll.

Verwendetes FHIR-Profil

Profil wird auf Basis von ISiK v4 erstellt.

https://simplifier.net/guide/isik-terminplanung-v4/ImplementationGuide-markdown-Einfuehrung?version=current

ZIV-Profil Termin

Appointment / AppointmentResponse https://hl7.org/fhir/R4/appointment.html https://hl7.org/fhir/R4/appointmentresponse.html

Beispiel-FHIR-Ressource HL7

{
  "resourceType" : "Appointment",
  "id" : "example",
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">Brian MRI results discussion</div>"
  },
  "status" : "booked",
  "class" : [{
    "coding" : [{
      "system" : "http://terminology.hl7.org/CodeSystem/v3-ActCode",
      "code" : "AMB",
      "display" : "ambulatory"
    }]
  }],
  "serviceCategory" : [{
    "coding" : [{
      "system" : "http://example.org/service-category",
      "code" : "gp",
      "display" : "General Practice"
    }]
  }],
  "serviceType" : [{
    "concept" : {
      "coding" : [{
        "code" : "52",
        "display" : "General Discussion"
      }]
    }
  }],
  "specialty" : [{
    "coding" : [{
      "system" : "http://snomed.info/sct",
      "code" : "394814009",
      "display" : "General practice (specialty)"
    }]
  }],
  "appointmentType" : {
    "coding" : [{
      "system" : "http://terminology.hl7.org/CodeSystem/v2-0276",
      "code" : "FOLLOWUP",
      "display" : "A follow up visit from a previous appointment"
    }]
  },
  "reason" : [{
    "reference" : {
      "reference" : "Condition/example",
      "display" : "Severe burn of left ear"
    }
  }],
  "description" : "Discussion on the results of your recent MRI",
  "start" : "2013-12-10T09:00:00Z",
  "end" : "2013-12-10T11:00:00Z",
  "created" : "2013-10-10",
  "note" : [{
    "text" : "Further expand on the results of the MRI and determine the next actions that may be appropriate."
  }],
  "patientInstruction" : [{
    "concept" : {
      "text" : "Please avoid excessive travel (specifically flying) before this appointment"
    }
  }],
  "basedOn" : [{
    "reference" : "ServiceRequest/myringotomy"
  }],
  "subject" : {
    "reference" : "Patient/example",
    "display" : "Peter James Chalmers"
  },
  "participant" : [{
    "actor" : {
      "reference" : "Patient/example",
      "display" : "Peter James Chalmers"
    },
    "required" : true,
    "status" : "accepted"
  },
  {
    "type" : [{
      "coding" : [{
        "system" : "http://terminology.hl7.org/CodeSystem/v3-ParticipationType",
        "code" : "ATND"
      }]
    }],
    "actor" : {
      "reference" : "Practitioner/example",
      "display" : "Dr Adam Careful"
    },
    "required" : true,
    "status" : "accepted"
  },
  {
    "actor" : {
      "reference" : "Location/1",
      "display" : "South Wing, second floor"
    },
    "required" : true,
    "status" : "accepted"
  }]
}

Beispiel-FHIR-Ressource HL7 AppointmentResponse

{
  "resourceType" : "AppointmentResponse",
  "id" : "example",
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">Accept Brian MRI results discussion</div>"
  },
  "appointment" : {
    "reference" : "Appointment/example",
    "display" : "Brian MRI results discussion"
  },
  "actor" : {
    "reference" : "Patient/example",
    "display" : "Peter James Chalmers"
  },
  "participantStatus" : "accepted"
}

Organisatorische Regelungen für die Befüllung des FHIR-Profils

Herausforderungen

• Eine zum Patienten veröffentlichte Termin-Ressource kann intern mehrere Terminressourcen beinhalten, die nicht zum Patienten kommuniziert werden
• Bei einer Reihe von sich wiederholenden Besuchen müssten für jede Instanz mehrere Terminressourcen erstellt werden, eine Verknüpfung von Reihenterminen ist aktuell noch nicht vorgesehen.
• Da Terminplanung für Ressourcenplanung wichtig ist, werden intern üblicherweise Termine mit Ressourcen verknüpft, d.h. Pflegekraft, Arzt, Raum, Geräte. In der Regel sollen diese Ressourcen nicht an den Patienten kommuniziert werden. Es muss intern festgelegt werden, welche dieser Informationen freizugeben sind.
• Die Priorität eines Termins kann zum Patienten kommuniziert werden. Es muss intern diskutiert werden, welche Piorität wie dargestellt wird.
• "Comment"-Element sind interne Kommentare und sollten nicht zum Patienten exponiert werden
• Element "PatientInstruction": diese Kommentare werden zum Patienten als Anweisungen exponiert.

Lösungen

• Die Terminbestätigungen/Absagen werden über die FHIR-Ressource AppointmentResponse abgebildet.
• Es muss intern über Markierungen und Abhängigkeiten gewährleistet sein, dass interne Termine zur Resourcenplanung nicht über diese Schnittstelle an den Patienten kommuniziert werden.
• Bei einem Stornieren des Patiententermins muss auch intern dafür gesorgt werden, dass die internen abhängigen Termine storniert werden.

Validierungsregeln

Technische FHIR-Validierung

Die Validierung einer gesendeten FHIR-Ressource erfolgt gegenüber dem ZIV-Profil, indem die Ressourcen-Struktur auf ZIV-Konformität überprüft wird. Konkret muss überprüft werden, ob alle Datenelemente mit Pflichtfeld oder mustSupport-Flag in der Ressource vorhanden sind oder ob nicht zugelassene Datenelemente existieren.

Die Validierung erfolgt via Simplifier, da darüber das Profil spezifiziert ist.

Beschreibung eines Anwendungsszenarios

Ein Krankenhaus bietet ambulante Physiotherapie für Patienten an, die sich von Verletzungen des Bewegungsapparats erholen. Um das Patienten Empowerment und die die Ressourcennutzung zu verbessern, ermöglicht das Krankenhaus den Patienten die Terminvergabe selbst über ein Patientenportal oder über eine App vorzunehmen. Der Patient meldet sich im Portal an und wählt die gewünschten Termine aus. Die App fragt Terminplan- (Schedule) und Slot Ressourcen vom FHIR-Server ab, um verfügbare Zeiten für die Physiotherapie anzuzeigen. Der Patient wählt ein passendes Zeitfenster aus, wodurch das System eine Appointment Ressource erstellt. Automatische Erinnerungen (FHIR Communication oder App-Benachrichtigungen) werden 48 Stunden vor dem Termin an den Patienten gesendet. Nach jeder Sitzung kann der Physiotherapeut den Terminstatus aktualisieren (abgeschlossen, abgesagt) und Verlaufsnotizen eingeben.

{
  "resourceType": "Appointment",
  "id": "physiotherapy-session-001",
  "meta": {
    "profile": [
      "http://example.org/fhir/StructureDefinition/Appointment-AmbulatoryPhysio|1.0.0"
    ],
    "lastUpdated": "2025-06-15T10:00:00Z"
  },
  "status": "booked",
  "serviceCategory": [
    {
      "coding": [
        {
          "system": "http://fhir.de/CodeSystem/dkgev/efas",
          "code": "1711",
          "display": "Physiotherapie"
        }
      ]
    }
  ],
  "serviceType": [
    {
      "coding": [
        {
          "system": "http://example.org/service-type",
          "code": "manual-therapy",
          "display": "Manual Therapy"
        }
      ]
    }
  ],
  "specialty": [
    {
      "coding": [
        {
          "system": "http://snomed.info/sct",
          "code": "410158009",
          "display": "Physiotherapy service"
        }
      ]
    }
  ],
  "appointmentType": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/v2-0276",
        "code": "ROUTINE",
        "display": "Routine appointment"
      }
    ]
  },
  "reason": [
    {
      "reference": {
        "reference": "ServiceRequest/physio-referral-12345",
        "display": "Post-op rehabilitation after ACL surgery"
      }
    }
  ],
  "description": "Outpatient physiotherapy - Session 1/10 - ACL post-op rehab",
  "start": "2025-06-24T08:00:00Z",
  "end": "2025-06-24T09:00:00Z",
  "created": "2025-06-15T09:30:00Z",
  "note": [
    {
      "text": "First session booked by patient via mobile app."
    }
  ],
  "patientInstruction": [
    {
      "concept": {
        "text": "Please wear comfortable clothing suitable for movement exercises. Arrive 10 minutes early."
      }
    }
  ],
  "basedOn": [
    {
      "reference": "ServiceRequest/physio-referral-12345"
    }
  ],
  "subject": {
    "reference": "Patient/12345",
    "display": "Jane Doe"
  },
  "participant": [
    {
      "actor": {
        "reference": "Patient/12345",
        "display": "Jane Doe"
      },
      "required": true,
      "status": "accepted"
    },
    {
      "type": [
        {
          "coding": [
            {
              "system": "http://terminology.hl7.org/CodeSystem/v3-ParticipationType",
              "code": "ATND",
              "display": "attender"
            }
          ]
        }
      ],
      "actor": {
        "reference": "Practitioner/physio-john-smith",
        "display": "John Smith, PT"
      },
      "required": true,
      "status": "accepted"
    },
    {
      "actor": {
        "reference": "Location/clinic-physio-01",
        "display": "Outpatient Physio Clinic - Room 1"
      },
      "required": true,
      "status": "accepted"
    }
  ],
  "slot": [
    {
      "reference": "Slot/clinic-physio-room1-20250624-0800"
    }
  ]
}

Beschreibung der Elemente und Implementierungshilfen

Wir empfehlen allgemein in Ihren FHIR Profilen die Verwendung von display oder text als hilfreiche Zusammenfassungen für Ihre Elemente, insbesondere für User Interfaces, Dashboards, oder FHIR viewers.

Bei Zeitstempeln empfehlen wir die Verwendung der UTC-Zeiten, da hierdurch Unklarheiten vermieden werden, die durch Zeitzonen und Sommerzeitänderungen entstehen. Die Verwendung von Z weist ausdrücklich darauf hin, dass die Zeit in koordinierter Weltzeit angegeben ist. Dadurch ist es einfacher für Systeme in verschiedenen Regionen konsistent zu arbeiteten. Verwenden Sie immer das ISO 8601-Format (z.B. JJJJ-MM-TThh:mm:ssZ). Bevorzugen Sie UTC (Z) für den Datenaustausch von Server zu Server. Achten Sie unbedingt darauf, dass Sie einheitliche Zeitzonen innerhalb Ihres Systems verwenden. Die Vermischung von UTC- und Ortszeiten kann zu Fehlern bei der Planung führen. Konvertieren Sie in der Benutzeroberfläche UTC-Zeitstemple in die lokale Zeitzone des Benutzers, aber speichern und tauschen Sie Daten in UTC aus.

Appointment.meta: Standard Block, der technischen Details über die Ressource und nicht deren klinische Inhalte erfasst, d.h. Versionierung oder Konformität. Häufige meta Elemente sind:

• versionId: Versionsnummer dieser Ressource. Sie ist nützlich, wenn Ihr Server die Versionierung unterstützt (Interaktion mit der Historie)
• lastUpdated: Zeitstempel, der die letzte Änderung dieser Ressource angibt.
• profile: gibt an, welchem FHIR-Profil diese Ressource entspricht (sehr wichtig für Validerung und Interoperabilität)
  • Ohne meta.profile können die empfangenden Systeme nicht erkennen, ob ein Termin ein "Haupttermin" oder ein "spezieller Termin" (z.B. ambulante Physio-Selbsplanung) ist
  • Verwenden Sie eindeutige, versionierte URLs für Ihre Profile
  • Wenn Ihr System mehrere Terminprofile unterstützt, muss auf die Wahl des richtigen Profils pro Anwendungsfall geachtet werden
  • Verwenden Sie vor dem Versenden eines Termins einen FHIR-Validator (z.B. HAPI FHIR, Firely.NET, Smile CDR) um sicherzustellen, dass er dem deklarierten Meta-Profil entspricht.
• security: Sicherheitskennzeichnungen, z.B. Vertraulichkeit-Tags
• tag: Allgemeine Tags, z.B. Workflow-Status, Herkunft

Appointment.status: Gibt den aktuellen Status des Termins im Planungsprozess an. Mögliche Werte sind:

Die Patienten App verwendet den Status um zu zeigen, was der Patient tun kann:

Die Klinik verwenden den Staus, um den Betriebsstatus zu kennen:

• Beachten Sie dass Termine dynamisch sind und ihren Status im Laufe der Zeit ändern
• Wenn ein Termin abgesagt/storniert (cancelled) wurde oder der Patient nicht erschienen ist (noshow), verwenden Sie diese beiden Statusanzeigen und löschen nicht die Appointment Ressource

Appointment.cancelationReason: ein CodeableConcept, das beschreibt warum ein Termin abgesagt wurde

• Mögliche HL7 Wertesets Absagen können hier eingesehen werden: https://terminology.hl7.org/6.4.0/ValueSet-appointment-cancellation-reason.html
• wenn Appointment.status = cancelled immer cancelationReason ausfüllen
• Verwenden Sie definierte Codesysteme und vermeiden Sie ausschließlich Freitext
• Sie können Text hinzufügen, wenn Sie den vom Benutzer eingegebenen Grund erfassen möchten
• Mögliche Szenarien in Bezug auf das Anwendungsszenario:
  • Patient sagt über die App ab → "pat"
  • Patient meldet sich krank → "phys"
  • Klinikpersonal sagt krankheitsbedingt ab → "prov"
  • Technisches Problem (z.B. Raum nicht verfügbar) → "se"

{
  "resourceType": "Appointment",
  "id": "example-cancelled",
  "meta": {
    "profile": [
      "https://my-org.org/fhir/StructureDefinition/Appointment-AmbPhysio-v1"
    ],
    "lastUpdated": "2025-06-17T16:00:00+02:00"
  },
  "status": "cancelled",
  "cancellationReason": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/appointment-cancellation-reason",
        "code": "pat",
        "display": "Patient cancelled"
      }
    ],
    "text": "Patient had a scheduling conflict"
  },
  "description": "Physiotherapy appointment",
  "start": "2025-06-25T10:00:00+02:00",
  "end": "2025-06-25T10:30:00+02:00",
  "participant": [
    {
      "actor": {
        "reference": "Patient/example",
        "display": "Anna Müller"
      },
      "status": "declined"
    },
    {
      "actor": {
        "reference": "Practitioner/example",
        "display": "Physiotherapist Dr. Krause"
      },
      "status": "accepted"
    }
  ]
}

Appointment.serviceCategory: beschreibt die allgemeine Dienstleistungskategorie für den Termin. Also um welche Art von Klinik oder Dienstleistung es geht.

• serviceCategory ist eine höhere Ebenen als serviceType und nicht hiermit zu verwechseln
  • Hierarchie: serviceCategory > serviceType > specialty
• Beispiele für CodeableConcept können auf https://terminology.hl7.org/6.4.0/CodeSystem-service-category.html gefunden werden
• Verwenden Sie offizielle Codes
• Verwenden Sie immer das serviceCategory Element, auch wenn Ihre App sie nur auf eine Art der Pflege/Behandlung fokussiert

Appointment.serviceType: beschreibt die genauere Dienstleistung, die bei diesem Termin erbracht wird

• Kann ein code, display, oder text sein

• bei Bedarf können mehrere serviceType's angeboten werden

• erweiterterFachabteilungsschlüssel: ist ein Operationen- und Prozendurenschlüssel (OPS), der vom BfArM herausgegeben werden und ist in Anlage 2 nach § 301 Abs. 3 SGB Vereinbarung Schlüsselverzeichnis zu finden https://www.gkv-datenaustausch.de/media/dokumente/leistungserbringer_1/krankenhaeuser/anlage_2/2_anl2-129.pdf

• FHIR R5 führt das concept Element ein, aber im R4 Kernprofile ist serviceType nur ein CodeableConcept → es ist kein concept Wrapper erforderlich

  • Beispiel FHIR R5

  "serviceType": [
    {
      "concept": {
        "coding": [...]
      }
    }
  ]
  
  

  • Beispiel FHIR R4

    "serviceType": [
      {
        "coding": [
          {
            "system": "...",
            "code": "...",
            "display": "..."
          }
        ]
      }
    ]
    
    

Appointment.speciality: beschreibt, welches klinische Fachgebiet mit diesem Termin verbunden ist, unabhängig davon, welche Leistung geplant ist

• Es können SNOMED CT Codes für eine internationale Interoperabilität verwenden werden, oder lokale mapping Listen (z.B. von der KBV oder ISiK).
• Wenn Ihr Terminsystem mehrere Fachabteilungen unterstützt verwenden sie ein Array (z.B. wenn ein Orthopäde und Physiotherapeut bei der Behandlung zusammenarbeiten)

"specialty": [
  {
    "coding": [
      {
        "system": "http://snomed.info/sct",
        "code": "408467006",
        "display": "Orthopaedic surgery"
      }
    ]
  },
  {
    "coding": [
      {
        "system": "http://snomed.info/sct",
        "code": "394913002",
        "display": "Physiotherapy"
      }
    ]
  }
]

Appointment.appointmentType: beschreibt die Art des Termins oder deren Zweck auf einer allgemeinen Ebene

• Mögliche Werteset von HL7: https://terminology.hl7.org/CodeSystem-v2-0276.html

• Sie können auch eiin eigenes ValueSet erstellen, das lokale Codes auf v2-0276 abbildet (Beispiel: z.B. "AN"= Anfganstermin oder "FT"= Folgetermin). Wir empfehlen aber nach Möglichkeiten Codes aus v2-0276 zu verwenden.
• um ein vollständiges klinisches und planerisches Bild zu bekommen, sollten serviceType und specialty kombiniert werden

Appointment.reasonCode: beschreibt den Grund, warum dieser Termin angesetzt wurde in From von klinischen oder administrativen Codes

• Sie können klinische Codes (z.B. SNOMED CT oder ICD-10) oder administrative Codes verwenden

• Beispiel SNOMED CT:

  "reasonCode": [
    {
      "coding": [
        {
          "system": "http://snomed.info/sct",
          "code": "225358003",
          "display": "Physiotherapy for osteoarthritis of knee"
        }
      ]
    }
  ]
  
  

• Beispiel ICD-10:

  "reasonCode": [
    {
      "coding": [
        {
          "system": "http://fhir.de/CodeSystem/bfarm/icd-10-gm",
          "code": "M17.11",
          "display": "Gonarthrose, einseitig, primär: Rechtes Kniegelenk"
        }
      ]
    }
  ]
  
  

Appointment.description: kurze Freitext Beschreibung worum es bei dem Termin geht.

• ist für den menschlichen Gebrauch gedacht und sollte deshalb keine Codes enthalten
  • Raw Codes sollten in reasonCode und serviceType abgelegt werden
• dient zur Anzeige in Patienten-Apps
• Text sollte kurz und prägnant sein
• idealerweise generiert Ihr System diesen Text automatisch auf Grundlage der FHIR Elemente appointmentType + serviceType + reasonCode
• Der Datenschutz sollte beachtet werden: wenn dieser Text in Kalendereinträgen oder E-Mail Erinnerungen angezeigt wird, sollten keine sensiblen Diagnoseworte verwendet werden

Appointment.start: geplante Startzeitpunkt des Termins

• muss Zeitzonen konform sein, sonst zeigen Kalender in Szenarien mit mehreren Zeitzonenen oder Sommerzeit falsche Zeiten an
• obligatorisch bei gebuchten Terminen
• Startzeiten sollten zu Ihrem Planungssystem passen (Slots, Zeitfenster). Wenn Ihr Buchungssystem nur 15-Minuten-Intervalle zulässt, sollten Sie sicherstellen, dass die Startzeiten übereinstimmen.
• Start in der Vergangenheit oder in der Zukunft validieren, sodass Buchungen in der Vergangenheit verhindert werden

Appointment.end: das geplante Ende des Termins

• muss Zeitzonen konform sein, sonst zeigen Kalender in Szenarien mit mehreren Zeitzonenen oder Sommerzeit falsche Zeiten an
• nicht zwingend für alle Fälle nötig (z.B. bei unbefristeten Buchungen), aber notwendig für Kalendersynchronisation und fehlende Endzeiten können zu Doppelbuchungen führen
• Sie sollten sicherstellen, dass das Ende nach dem Beginn liegt
• automatisierte Validieren kann Termine blockieren, die nach den Öffnungszeiten enden

Appointment.created: gibt an, wann der Termin ursprünglich im System erstellt wurde

• optional, aber hilfreich für Rückverfolgbarkeit
• kann automatisch vom System beim ersten Erstellen des Termins erzeugt werden und sollte danach nicht mehr geupdatet werden

Appointment.comment: zusätzliche Kommentar zu dem Termin für internen Gebrauch

• kurz und prägnant
• wird nicht unbedingt dem Patienten angezeigt
  • Beispiel: "Patient bevorzugt Therapeut Müller wenn verfügbar" oder "benötigt Zugang zu einem Rollstuhl"
• keine medizinische Befunde
• keine vertraulichen, sensiblen Daten, wenn das System diese dem Patienten anzeigt
• keine Anweisungen an den Patienten → das gehört in patientInstruction
• ZIV empfiehlt kein Comment an Patienten zu übermitteln.

Appointment.patientInstruction: besondere Anweisungen für den Patienten, die sich auf diesen Termin beziehen (wie er sich vorbereiten soll, was er mitbringen soll, etc.)

• CodeableConcpet[] in R5 (kann auch nur einen Text enthalten), oder string in R4
• keine klinikinternen Anweisungen, die gehören in Appointment.comment
• keine Diagnose (Datenschutz)
• der Text sollte kurz, aber in einfacher für den Patienten verständlicher Sprache sein: 'Bitte nüchtern erscheinen'
• duplizieren Sie nicht description oder comment

Appointment.participant: definiert die Liste der Teilnehmer an einem Termin.

• jeder Teilnehmer kann eine Person, ein Patient, ein Behandelnder, ein Ort, oder ein Gerät sein. Sie können also einen oder mehrere Teilnehmer haben
• Akteure: wer oder was nimmt teil → Verweis auf FHIR Referenzen Patient, Practioner, Location. Der Patient sollte hier zwingend referenziert werden
• required: Boolean kodiert (0/1) ob der Akteur benötigt wird
• status: Teilnehmerstatus (accepted, declined, tentative)
• type: optional, wenn die Rolle geklärt werden muss
  • z.B. Therapeut, überweisender Arzt, Assistent
• Für Apps die eine Eigenbuchung des Termins durch den Patienten zulassen, sollte der Patient sehen, ob der der Termin bestätigt ist (status accepted) oder noch aussteht

Appointment.slot: verweist auf eine oder mehrere slot Ressourcen

• ein vordefinierter Zeitblock in einem Kalender
• wird hauptsächlich verwendet, wenn Ihr System strukturierte Kalender mit vordefinierter Verfügbarkeit verwaltetet bzw. Ihre Terminplanung mit Slots arbeitet, die von einem Administrator oder einer Software erstellt werden, in die gebucht wird
• Füllen Sie Appointment.slot immer aus, wenn Sie einen elektronischen Kalender haben
• Halten Sie die Slot-Zeiten übereinstimmend mit Appointment.start und Appointment.end