Anmerkungen zu Must-Support-Feldern
| Feldname | Hinweise |
|---|---|
| Appointment.meta | Ein Tag kann verwendet werden um zu kennzeichnen, dass die Ressource von Extern erstellt worden ist. |
| Appointment.meta.tag | |
| Appointment.meta.tag:Source | |
| Appointment.extension | Begründung zum Must Support: Termineabsagen sollten verkettbar sein, da am originalen Termin noch weitere Informationen hängen können. |
| Appointment.extension:replaces | |
| Appointment.status | Begründung zu Must Support : Im ISiK Kontext ist der Status eines Termins von entscheidender Bedeutung, um den aktuellen Stand und die Verfügbarkeit des Termins zu kommunizieren. |
| Appointment.cancelationReason | Begründung zu Must Support: Dieses Feld ist optional (0..1), muss jedoch implementiert werden (MS), um die Möglichkeit zu bieten, einen Grund für die Absage eines Termins zu hinterlegen. |
| Appointment.serviceType | Begründung zu Kardinalität und Must Support: Die Dienstleistungsart eines Termins ist von entscheidender Bedeutung, um die Verfügbarkeit und Planung des Termins zu gewährleisten. Daher ist dieses Feld verpflichtend (1..*) und muss unterstützt werden (MS). Aufgrund der Heterogenität von Dienstleistungen ist eine standardisierte Kodierung nicht zwingend notwendig, eine Freitextbeschreibung ist ausreichend. |
| Appointment.serviceType.text | |
| Appointment.specialty | Optionale Angabe aller Fachbereiche aus denen ein oder mehrere Akteure für die Durchführung des Termins benötigt werden. Begründung zu Kardinalität und Must Support: KANN auch anhand des Kalenders, in dem ein Termin gebucht wird, ermittelt werden. Die Angabe der Fachbereiche ist optional (0..*), muss jedoch implementiert werden (MS), um die Spezialisierung hinsichtlich der zugeordneten Behandlungseinheit des Termins eindeutig zu definieren und eine korrekte Zuordnung zu gewährleisten. |
| Appointment.specialty.coding | |
| Appointment.specialty.coding:Fachrichtung | Begründung zur Kardinalität: Die Kardinalität der Fachrichtung-Eigenschaft wird auf 1..1 festgelegt, um sicherzustellen, dass genau eine Fachrichtung vorhanden ist. Dies ist notwendig, um die Spezialisierung des Termins eindeutig zu definieren und eine korrekte Zuordnung zu gewährleisten. Hintergrund zur Entscheidung: Die Wahl des hinterlegten ValueSets (http://ihe-d.de/ValueSets/IHEXDSpracticeSettingCode) wurde mit einem Mitglied der IHE Deutschland Arbeitsgruppe XDS ValueSets (https://www.ihe-d.de/projekte/xds-value-sets-fuer-deutschland/) sowie mit der KBV abgestimmt (Stand:13.6.2024). |
| Appointment.priority | Begründung Must Support: Die Priorität eines Termins ist von entscheidender Bedeutung, um die Dringlichkeit und Relevanz des Termins zu kommunizieren und zu priorisieren. Eine Priorität ist nicht zwingend erforderlich, muss jedoch implementiert werden (MS), um die Möglichkeit zu bieten, die Dringlichkeit und Relevanz des Termins abzurufen. |
| Appointment.priority.extension | Hinweis: In R5 ist die Priority ein CodeableConcept. Begründung zu Must Support: Dieses Element ist optional (0..1), muss jedoch implementiert werden (MS), um besonders einen Notfall als solchen ausweisen zu können. |
| Appointment.priority.extension:Priority | |
| Appointment.start | Begründung zu Kardinalität und Must Support: Der Startzeitpunkt eines Termins ist von entscheidender Bedeutung, um die Verfügbarkeit und Planung des Termins zu gewährleisten. Daher muss dieses Feld unterstützt werden (MS). Das Feld ist in den meisten Fällen verpflichtend, nur für die Status 'proposed', 'cancelled', 'waitlist' existiert kein Wert. |
| Appointment.end | Begründung zu Kardinalität und Must Support: Der Endzeitpunkt eines Termins ist von entscheidender Bedeutung, um die Verfügbarkeit und Planung des Termins zu gewährleisten. Daher muss dieses Feld unterstützt werden (MS). Das Feld ist in den meisten Fällen verpflichtend, nur für die Status 'proposed', 'cancelled', 'waitlist' existiert kein Wert. |
| Appointment.slot | Begründung zu Kardinalität und Must Support: Die Kardinalität der slot-Eigenschaft bleibt 0..*, sodass ein Termin-Requestor bei der Terminbuchung nur einen Termin und ein Verweis auf ein ISiKKalender übergeben kann. Es ist dann die Aufgabe des Termin-Repositories in Abhängigkeit der gebuchten Dienstleistung freie Terminblöcke zu finden. Diese sind im Appointment zu referenzieren. |
| Appointment.slot.reference | |
| Appointment.comment | Hinweis: Im ISiK Kontext sollte dieses Feld zur internen Kommunikation zwischen Leistungserbringern verwendet werden, z.B. für interne Notizen rund um den Termin. Begründung zum Must Support: Dieses Feld ist optional (0..1), muss jedoch implementiert werden (MS), um die Möglichkeit zu bieten, zusätzliche Informationen zum Termin zu hinterlegen und abrufen zu können. Es gilt weiterhin die Semantik des Elements nach FHIR-Kernspezifikation: 'Additional text to aid in facilitating the appointment. For instance, a comment might be, 'patient should proceed immediately to infusion room upon arrival' Where this is a planned appointment and the start/end dates are not set then this field can be used to provide additional guidance on the details of the appointment request, including any restrictions on when to book it.' |
| Appointment.patientInstruction | Hinweis: Dieses Feld sollte im Kontext von ISIK verwendet werden für die Kommunikation im Sinne der Definition der FHIR-Kernspezifikation - sowohl von Systemseite (administrativ) als auch von Seiten des medizinischen Fachpersonals. Beispiel für eine Nachricht: 'Bitte nüchtern erscheinen' etc. Begründung zum Must Support: Dieses Feld ist optional (0..1), muss jedoch implementiert werden (MS), um die Möglichkeit zu bieten, zusätzliche Informationen für Patienten zum Termin zu hinterlegen und abrufen zu können. Es gilt weiterhin der Hinweis der FHIR Kernspezifikation: 'Note that FHIR strings SHALL NOT exceed 1MB in size' |
| Appointment.participant | Hinweis: Die Kardinalität von actor.display und das MS-Flag von .status wird an die Slices vererbt und diese sind entsprechend zu implementieren. Begründung zu Kardinalität und Must Support: Die Teilnehmer eines Termins sind von entscheidender Bedeutung, um die Verfügbarkeit und Planung des Termins zu gewährleisten. Daher muss dieses Feld unterstützt werden (MS). |
| Appointment.participant.actor | |
| Appointment.participant.actor.display | Hinweis: Für alle Target-Ressourcen SOLL ein Displaywert für die Referenz angegeben werden, sodass Systeme eine Übersicht der am Termin beteiligten Akteure anzeigen können ohne die Referenzen auflösen zu müssen. Somit kann ein Termin-Consumer direkt anzeigen welche Akteure für den Termin relevant sind. |
| Appointment.participant.status | |
| Appointment.participant:AkteurPatient | Hinweis: Im ISIK-Kontext MUSS der referenzierte Patient konform zum ISIKPatient des Basismoduls sein. Ein Sonderfall sind Patienten, über die ein Termin-Requestor oder Termin-Repository nur rudimentäre Informationen verfügt. Diese Patienten-Ressourcen sind bis zur Vervollständigung nur gegen den Kernstandard valide. Begründung zu Kardinalität und Must Support: Die teilnehmenden Patienten eines Termins sind von entscheidender Bedeutung, um die Verfügbarkeit und Planung des Termins zu gewährleisten. Daher muss dieses Feld unterstützt werden (MS). Hingegen kann die Patienten-Referenz separat in der $book-Operation übergeben werden, sodass hier keine verpflichtende Kardinaltiät gewählt werden kann. |
| Appointment.participant:AkteurPatient.actor.reference | |
| Appointment.participant:AkteurPersonImGesundheitsberuf | Im ISIK-Kontext MUSS die referenzierte RelatedPerson-Ressource konform zum ISiKAngehoeriger des Basismoduls sein. Begründung zu Kardinalität und Must Support: Die Angabe eines Angehörigen ist optional, da in vielen Fällen die Referenzierung des Patienten ausreichend ist. Bei Terminen, die durch einen Angehörigen gebucht/verwaltet werden, ist es jedoch wichtig, dass diese Information an das Termin-Repository übermittelt werden kann. |
| Appointment.participant:AkteurPersonImGesundheitsberuf.actor.reference | |
| Appointment.participant:AkteurMedizinischeBehandlungseinheit | |
| Appointment.participant:AkteurMedizinischeBehandlungseinheit.actor.reference | |
| Appointment.participant:Angehoeriger | |
| Appointment.participant:Angehoeriger.actor.reference |
Appointment.meta.tag
Bedeutung: Herkunft der Termins
Hinweis: Angabe, ob der Termin durch einen externen Termin-Requestor eingestellt wurde. Falls das Datenobjekt dauerhaft in das Termin-Repository gespeichert wird, KANN der Tag entfernt werden. Für die weitere Prozesssteuerung kann eine Unterscheidung, ob es sich um einen intern oder extern erstellten Termin handelt, notwendig sein, sodass aus Gründen der Nachvollziehbarkeit der Tag bestehen bleiben sollte. Des Weiteren gelten die Vorgaben des ISiK Basismoduls zur CREATE-Interaktion.
Appointment.extension:replaces
Bedeutung: Angabe eines abgesagten / verschobenen Termins
Hinweis: Im Falle, dass per $book-Operation ein verschobener / abgesagter Termin angegeben wird, MUSS dieser für die Rückverfolgbarkeit referenziert werden.
Appointment.status
Bedeutung: Differenzierung zwischen Terminwunsch und gebuchten Termin
Hinweis: Ein Termin-Requestor kann im Status entsprechend wählen, sodass der Termin als Terminwunsch zu interpretieren ist. Nachdem der Termin bestätigt wurde, ist der Terminstatus durch das Termin-Repository anzupassen.
Alle Statuswerte MÜSSEN durch ein bestätigungsrelevantes System unterstützt werden, insbesondere der Status "proposed" und "booked".
Appointment.cancelationReason
Bedeutung: Grund für die Absage eines Termins
Hinweis: Eine minimale Kodierung MUSS mittels des vorgeschlagenen Bindings vorliegen. Differenzierungen mit feinerer Granularität können durch weitere Codings erfolgen.
Appointment.serviceType
Bedeutung: Kodierung der Behandlungsleistung des Termins
Hinweis: Dies SOLL der Kodierung des serviceType eines Schedules entsprechen, der innerhalb des Termins gebucht wird. Ein Termin-Repository SOLL einen Termin abweisen, falls unbekannte Kodierungen in .serviceType durch den Termin-Requestor übermittelt werden, sodass ein Termin-Repository sicherstellen kann, dass alle Ressourcen für die Behandlungsleistung(en) bereitgestellt werden können. Hierzu ist eine Interpretation der Behandlungsleistung notwendig. Ein Termin KANN für mehrere Behandlungsleistungen gebucht werden, falls dies durch die Fachlogik des Termin-Repositories unterstützt wird.
Appointment.specialty
Bedeutung: Kodierung der Fachrichtung des Termins
Hinweis: Sofern aus den auf der Appointment-Ressource aufsetzenden Anwendungsfällen eine weitere Verarbeitung der Ressource durch einen menschlichen Nutzer nicht ausgeschlossen werden kann, MUSS das bestätigungsrelevante System mit dem Termin verbundenen Ressourcen (insb. Appointment.slot, Appointment.slot.schedule, Appointment.participant:AkteurMedizinischeBehandlungseinheit.actor) oder aus dem spezifischen Kontext verfügbare Informationen auswerten und das Element Appointment.specialty mit einem sinnvollen Wert kodieren (eine Ausnahme bildet hier zum Beispiel die fachrichtungs-unabhängige Terminplanung durch krankenhausinterne, zentrale Organisationseinheiten).
Insbesondere ist die Kodierung der Fachrichtung des Termins notwendig im Kontext der Bereitstellung einer graphischen Oberfläche, wie sie Endnutzenden in einem Zuweiserportal/Patientenportal zur Ansicht gebracht wird.
Appointment.priority.extension:Priority
Bedeutung: Kodierte Angabe der Priorität des Termins
Hinweis: Anstelle der numerischen Priorität MUSS in ISiK eine kodierte Priorität angegeben werden.
Appointment.start
Bedeutung: Startzeitpunkt des Termins
Hinweis: Sofern der Termin an einen Slot gebunden ist, SOLL der Startzeitpunkt des Termins dem Startzeitpunkt des ersten Slots des Termins entsprechen.
Appointment.end
Bedeutung: Endzeitpunkt des Termins
Hinweis: Sofern der Termin an einen Slot gebunden ist, SOLL der Endzeitpunkt des Termins dem Endzeitpunkt des letzten Slots des Termins entsprechen.
Appointment.slot
Bedeutung: Referenzierung der Slots für die Verknüpfung des Termins mit einem Schedule
Hinweis: Die Referenzierung des Schedules KANN durch einen oder mehrere Slots erfolgen. Es kann keine Reihenfolge durch die Angabe der Slots abgeleitet werden.
Hinweis: In der Vergangenheit liegende Slots, welche nicht verknüpft wurden, DÜRFEN NICHT mehr abrufbar sein. Jegliche andere Slots müssen auch per id, herausgegeben werden. Sobald die id einmalig per Search herausgeben wurde, müssen diese gleichbleibend abrufbar sein.
Appointment.patientInstruction
Bedeutung: Handlungsanweisungen für die Patienten in Vorbereitung auf den Termin
Appointment.participant
Bedeutung: Teilnehmer des Termins
Hinweis: Mindestens eine Patient-Referenz MUSS angegeben werden. Dies MUSS durch das Termin-Repository während der Buchung des Termins geprüft werden. Weitere Leistungserbringer KÖNNEN angegeben werden.