diff --git a/ImplementationGuide/markdown/Datenobjekte/ISiKTerminAppointment.md b/ImplementationGuide/markdown/Datenobjekte/ISiKTerminAppointment.md index b050b335..07d06c1b 100644 --- a/ImplementationGuide/markdown/Datenobjekte/ISiKTerminAppointment.md +++ b/ImplementationGuide/markdown/Datenobjekte/ISiKTerminAppointment.md @@ -88,15 +88,12 @@ Alle Statuswerte MÜSSEN durch ein bestätigungsrelevantes System unterstützt w **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üzt 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` @@ -116,7 +113,6 @@ Insbesondere ist die Kodierung der Fachrichtung des Termins notwendig im Kontext **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 @@ -163,7 +159,7 @@ Für die Ressource Appointment MÜSSEN die REST-Interaktionen "READ" und "PATCH" ```GET [base]/Appointment?service-type=http://example.org/fhir/CodeSystem/ScheduleServiceType|CT``` - Anwendungshinweise: Bei einer Suche mit dem ":not"-Modifier MÜSSEN Ressourcen, die keinen Wert für "Appointment.serviceType" enthalten, im Suchergebnis enthalten sein. Bei einer Suche ohne den ":not"-Modifier DÜRFEN Ressourcen, die keinen Wert für "Appointment.serviceType" enthalten, NICHT im Suchergebnis enthalten sein. Weitere Informationen zur Suche nach "Appointment.serviceType" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token). + Anwendungshinweise: Weitere Informationen zur Suche nach "Appointment.serviceType" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token). 1. Der Suchparameter "specialty" MUSS unterstützt werden: @@ -171,7 +167,7 @@ Für die Ressource Appointment MÜSSEN die REST-Interaktionen "READ" und "PATCH" ```GET [base]/Appointment?specialty=urn:oid:1.2.276.0.76.5.114|535``` - Anwendungshinweise: Bei einer Suche mit dem ":not"-Modifier MÜSSEN Ressourcen, die keinen Wert für "Appointment.specialty" enthalten, im Suchergebnis enthalten sein. Bei einer Suche ohne den ":not"-Modifier DÜRFEN Ressourcen, die keinen Wert für "Appointment.specialty" enthalten, NICHT im Suchergebnis enthalten sein. Weitere Informationen zur Suche nach "Appointment.specialty" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token). + Anwendungshinweise: Weitere Informationen zur Suche nach "Appointment.specialty" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token). 1. Der Suchparameter "date" MUSS unterstützt werden: diff --git a/ImplementationGuide/markdown/Datenobjekte/ISiKTerminKontaktMitGesundheitseinrichtung.md b/ImplementationGuide/markdown/Datenobjekte/ISiKTerminKontaktMitGesundheitseinrichtung.md index a2f441a4..f54082c5 100644 --- a/ImplementationGuide/markdown/Datenobjekte/ISiKTerminKontaktMitGesundheitseinrichtung.md +++ b/ImplementationGuide/markdown/Datenobjekte/ISiKTerminKontaktMitGesundheitseinrichtung.md @@ -4,11 +4,11 @@ ### Motivation -Das Datenobjekt ISiKKontaktMitGesundheitseinrichtung dient der Verknüpfung des ISiK-Basis-Encounters (ISiKKontaktGesundheitseinrichtung) mit einem Termin (Appointment) und - darauf aufbauend - der Dokumentenkommunikation. +Das Datenobjekt ISiKKontaktMitGesundheitseinrichtung dient der Verknüpfung des ISiK-Basis-Encounters (ISiKKontaktMitGesundheitseinrichtung) mit einem Termin (Appointment) und - darauf aufbauend - der Dokumentenkommunikation. Die Anforderung dieser Verknüpfung stammt aus dem Szenario der Dokument-Übertragung zwischen Patientenportal und krankenhaus-internem Primärsystem (KIS): Dokumente liegen bei Termin-Buchung erst im Patientenportal (im Appointment) vor und werden erst mit Anlage des Encounters in das KIS (etc.) übermittelt. Dazu muss das Appointment mit dem neu angelegten Encounter verknüpft werden, um die Dokumente aus dem Patientenportal darüber zuzuordnen. -Hieraus folgt, dass das Datenobjekt nur relevant ist, falls das bestätigungsrelevante System das Datenobjekt ISiKKontaktGesundheitseinrichtung sowie ISiKTermin implementiert. Zu Beginn des Termins sollte das System die Verknüpfung zwischen Encounter und Appointment herstellen. Ausgenommen hiervon sind Termine, die nicht stattfinden, da für diese in der Regel keine Encounter angelegt werden. +Hieraus folgt, dass das Datenobjekt nur relevant ist, falls das bestätigungsrelevante System das Datenobjekt ISiKKontaktMitGesundheitseinrichtung sowie ISiKTermin implementiert. Zu Beginn des Termins sollte das System die Verknüpfung zwischen Encounter und Appointment herstellen. Ausgenommen hiervon sind Termine, die nicht stattfinden, da für diese in der Regel keine Encounter angelegt werden. --- @@ -52,4 +52,4 @@ Der Suchparameter "appointment" MUSS unterstützt werden: ### Weiteres -Siehe für weitere Anmerkungen und Vorgaben den [ISiK-Basis-Encounters (ISiKKontaktGesundheitseinrichtung)](https://simplifier.net/guide/isik-basis-v4/ImplementationGuide-markdown-Datenobjekte-Datenobjekte_Kontakt?version=current) +Siehe für weitere Anmerkungen und Vorgaben den [ISiK-Basis-Encounters (ISiKKontaktMitGesundheitseinrichtung)](https://simplifier.net/guide/isik-basis-v4/ImplementationGuide-markdown-Datenobjekte-Datenobjekte_Kontakt?version=current) diff --git a/ImplementationGuide/markdown/ReleaseNotes.md b/ImplementationGuide/markdown/ReleaseNotes.md index 5578cc6c..84156081 100644 --- a/ImplementationGuide/markdown/ReleaseNotes.md +++ b/ImplementationGuide/markdown/ReleaseNotes.md @@ -4,6 +4,17 @@ Im Rahmen der ISiK-Veröffentlichungen wird das [Semantic Versioning](https://se Die erste Ziffer X bezeichnet ein Major-Release und regelt die Gültigkeit von Releases. Die dritte Ziffer Y (Release x.0.y) bezeichnet eine technische Korrektur und versioniert kleinere Änderungen (Packages) während eines Jahres, z. B. 1.0.1. +Version 4.0.1 + +Datum: tbd. + +* Implizites ValueSet expandiert https://github.com/gematik/spec-ISiK-Terminplanung/pull/207 +* Dokumentation zur Begründung der Kardinalitäten und Must-Support-Flags ergänzt https://github.com/gematik/spec-ISiK-Terminplanung/pull/209 +* Für ISiKTermin Verschiebung des Slicing auf .specialty.coding. https://github.com/gematik/spec-ISiK-Terminplanung/pull/204 +* Kardinalität für Schedule.actor.display geschwächt https://github.com/gematik/spec-ISiK-Terminplanung/pull/206 + +---- + Version 4.0.0 Datum: 09.09.2024 diff --git a/Resources/fsh-generated/fsh-index.json b/Resources/fsh-generated/fsh-index.json index c11df889..07207c28 100644 --- a/Resources/fsh-generated/fsh-index.json +++ b/Resources/fsh-generated/fsh-index.json @@ -4,40 +4,40 @@ "fshName": "ISiKTerminExample", "fshType": "Instance", "fshFile": "ISiKTermin.fsh", - "startLine": 95, - "endLine": 112 + "startLine": 121, + "endLine": 138 }, { "outputFile": "Appointment-ISiKTerminExampleExtendedICU.json", "fshName": "ISiKTerminExampleExtendedICU", "fshType": "Instance", "fshFile": "ISiKTermin.fsh", - "startLine": 114, - "endLine": 132 + "startLine": 140, + "endLine": 158 }, { "outputFile": "CapabilityStatement-ISiKCapabilityStatementTerminplanungServer.json", "fshName": "ISiKCapabilityStatementTerminplanungServer", "fshType": "Instance", "fshFile": "ISiKTerminplanungCapabilityStatement.fsh", - "startLine": 1, - "endLine": 258 + "startLine": 2, + "endLine": 259 }, { "outputFile": "Communication-ISiKNachrichtExample.json", "fshName": "ISiKNachrichtExample", "fshType": "Instance", "fshFile": "ISiKNachricht.fsh", - "startLine": 32, - "endLine": 41 + "startLine": 40, + "endLine": 49 }, { "outputFile": "HealthcareService-ISiKMedizinischeBehandlungseinheitExample.json", "fshName": "ISiKMedizinischeBehandlungseinheitExample", "fshType": "Instance", "fshFile": "ISiKMedizinischeBehandlungseinheit.fsh", - "startLine": 20, - "endLine": 26 + "startLine": 31, + "endLine": 37 }, { "outputFile": "OperationDefinition-ISiKAppointmentBookOperation.json", @@ -52,16 +52,16 @@ "fshName": "ISiKKalenderExample", "fshType": "Instance", "fshFile": "ISiKKalender.fsh", - "startLine": 41, - "endLine": 48 + "startLine": 64, + "endLine": 71 }, { "outputFile": "Slot-ISiKTerminblockExample.json", "fshName": "ISiKTerminblockExample", "fshType": "Instance", "fshFile": "ISiKTerminblock.fsh", - "startLine": 19, - "endLine": 25 + "startLine": 25, + "endLine": 31 }, { "outputFile": "StructureDefinition-ISiKKalender.json", @@ -69,7 +69,7 @@ "fshType": "Profile", "fshFile": "ISiKKalender.fsh", "startLine": 1, - "endLine": 30 + "endLine": 53 }, { "outputFile": "StructureDefinition-ISiKMedizinischeBehandlungseinheit.json", @@ -77,7 +77,7 @@ "fshType": "Profile", "fshFile": "ISiKMedizinischeBehandlungseinheit.fsh", "startLine": 1, - "endLine": 18 + "endLine": 29 }, { "outputFile": "StructureDefinition-ISiKNachricht.json", @@ -85,15 +85,15 @@ "fshType": "Profile", "fshFile": "ISiKNachricht.fsh", "startLine": 1, - "endLine": 30 + "endLine": 38 }, { "outputFile": "StructureDefinition-ISiKNachrichtExtension.json", "fshName": "ISiKNachrichtExtension", "fshType": "Extension", "fshFile": "ISiKTermin.fsh", - "startLine": 78, - "endLine": 81 + "startLine": 104, + "endLine": 107 }, { "outputFile": "StructureDefinition-ISiKTermin.json", @@ -101,39 +101,39 @@ "fshType": "Profile", "fshFile": "ISiKTermin.fsh", "startLine": 1, - "endLine": 76 + "endLine": 101 }, { "outputFile": "StructureDefinition-ISiKTerminKontaktMitGesundheitseinrichtung.json", "fshName": "ISiKTerminKontaktMitGesundheitseinrichtung", "fshType": "Profile", "fshFile": "ISiKTerminKontaktMitGesundheitseinrichtung.fsh", - "startLine": 1, - "endLine": 5 + "startLine": 2, + "endLine": 7 }, { "outputFile": "StructureDefinition-ISiKTerminPriorityExtension.json", "fshName": "ISiKTerminPriorityExtension", "fshType": "Extension", "fshFile": "ISiKTermin.fsh", - "startLine": 83, - "endLine": 88 + "startLine": 109, + "endLine": 114 }, { "outputFile": "StructureDefinition-ISiKTerminblock.json", "fshName": "ISiKTerminblock", "fshType": "Profile", "fshFile": "ISiKTerminblock.fsh", - "startLine": 1, - "endLine": 12 + "startLine": 2, + "endLine": 18 }, { "outputFile": "StructureDefinition-ScheduleName.json", "fshName": "ScheduleName", "fshType": "Extension", "fshFile": "ISiKKalender.fsh", - "startLine": 34, - "endLine": 39 + "startLine": 57, + "endLine": 62 }, { "outputFile": "ValueSet-ISiKTerminCancelationReason.json", @@ -149,6 +149,6 @@ "fshType": "ValueSet", "fshFile": "valueSets.fsh", "startLine": 11, - "endLine": 15 + "endLine": 31 } ] diff --git a/Resources/fsh-generated/fsh-index.txt b/Resources/fsh-generated/fsh-index.txt index 5d55a594..bd526440 100644 --- a/Resources/fsh-generated/fsh-index.txt +++ b/Resources/fsh-generated/fsh-index.txt @@ -1,20 +1,20 @@ Output File Name Type FSH File Lines -Appointment-ISiKTerminExample.json ISiKTerminExample Instance ISiKTermin.fsh 95 - 112 -Appointment-ISiKTerminExampleExtendedICU.json ISiKTerminExampleExtendedICU Instance ISiKTermin.fsh 114 - 132 -CapabilityStatement-ISiKCapabilityStatementTerminplanungServer.json ISiKCapabilityStatementTerminplanungServer Instance ISiKTerminplanungCapabilityStatement.fsh 1 - 258 -Communication-ISiKNachrichtExample.json ISiKNachrichtExample Instance ISiKNachricht.fsh 32 - 41 -HealthcareService-ISiKMedizinischeBehandlungseinheitExample.json ISiKMedizinischeBehandlungseinheitExample Instance ISiKMedizinischeBehandlungseinheit.fsh 20 - 26 +Appointment-ISiKTerminExample.json ISiKTerminExample Instance ISiKTermin.fsh 121 - 138 +Appointment-ISiKTerminExampleExtendedICU.json ISiKTerminExampleExtendedICU Instance ISiKTermin.fsh 140 - 158 +CapabilityStatement-ISiKCapabilityStatementTerminplanungServer.json ISiKCapabilityStatementTerminplanungServer Instance ISiKTerminplanungCapabilityStatement.fsh 2 - 259 +Communication-ISiKNachrichtExample.json ISiKNachrichtExample Instance ISiKNachricht.fsh 40 - 49 +HealthcareService-ISiKMedizinischeBehandlungseinheitExample.json ISiKMedizinischeBehandlungseinheitExample Instance ISiKMedizinischeBehandlungseinheit.fsh 31 - 37 OperationDefinition-ISiKAppointmentBookOperation.json Book Instance ISiKBookOperation.fsh 1 - 52 -Schedule-ISiKKalenderExample.json ISiKKalenderExample Instance ISiKKalender.fsh 41 - 48 -Slot-ISiKTerminblockExample.json ISiKTerminblockExample Instance ISiKTerminblock.fsh 19 - 25 -StructureDefinition-ISiKKalender.json ISiKKalender Profile ISiKKalender.fsh 1 - 30 -StructureDefinition-ISiKMedizinischeBehandlungseinheit.json ISiKMedizinischeBehandlungseinheit Profile ISiKMedizinischeBehandlungseinheit.fsh 1 - 18 -StructureDefinition-ISiKNachricht.json ISiKNachricht Profile ISiKNachricht.fsh 1 - 30 -StructureDefinition-ISiKNachrichtExtension.json ISiKNachrichtExtension Extension ISiKTermin.fsh 78 - 81 -StructureDefinition-ISiKTermin.json ISiKTermin Profile ISiKTermin.fsh 1 - 76 -StructureDefinition-ISiKTerminKontaktMitGesundheitseinrichtung.json ISiKTerminKontaktMitGesundheitseinrichtung Profile ISiKTerminKontaktMitGesundheitseinrichtung.fsh 1 - 5 -StructureDefinition-ISiKTerminPriorityExtension.json ISiKTerminPriorityExtension Extension ISiKTermin.fsh 83 - 88 -StructureDefinition-ISiKTerminblock.json ISiKTerminblock Profile ISiKTerminblock.fsh 1 - 12 -StructureDefinition-ScheduleName.json ScheduleName Extension ISiKKalender.fsh 34 - 39 +Schedule-ISiKKalenderExample.json ISiKKalenderExample Instance ISiKKalender.fsh 64 - 71 +Slot-ISiKTerminblockExample.json ISiKTerminblockExample Instance ISiKTerminblock.fsh 25 - 31 +StructureDefinition-ISiKKalender.json ISiKKalender Profile ISiKKalender.fsh 1 - 53 +StructureDefinition-ISiKMedizinischeBehandlungseinheit.json ISiKMedizinischeBehandlungseinheit Profile ISiKMedizinischeBehandlungseinheit.fsh 1 - 29 +StructureDefinition-ISiKNachricht.json ISiKNachricht Profile ISiKNachricht.fsh 1 - 38 +StructureDefinition-ISiKNachrichtExtension.json ISiKNachrichtExtension Extension ISiKTermin.fsh 104 - 107 +StructureDefinition-ISiKTermin.json ISiKTermin Profile ISiKTermin.fsh 1 - 101 +StructureDefinition-ISiKTerminKontaktMitGesundheitseinrichtung.json ISiKTerminKontaktMitGesundheitseinrichtung Profile ISiKTerminKontaktMitGesundheitseinrichtung.fsh 2 - 7 +StructureDefinition-ISiKTerminPriorityExtension.json ISiKTerminPriorityExtension Extension ISiKTermin.fsh 109 - 114 +StructureDefinition-ISiKTerminblock.json ISiKTerminblock Profile ISiKTerminblock.fsh 2 - 18 +StructureDefinition-ScheduleName.json ScheduleName Extension ISiKKalender.fsh 57 - 62 ValueSet-ISiKTerminCancelationReason.json ISiKTerminCancelationReason ValueSet valueSets.fsh 1 - 9 -ValueSet-ISiKTerminPriority.json ISiKTerminPriority ValueSet valueSets.fsh 11 - 15 \ No newline at end of file +ValueSet-ISiKTerminPriority.json ISiKTerminPriority ValueSet valueSets.fsh 11 - 31 \ No newline at end of file diff --git a/Resources/fsh-generated/resources/Appointment-ISiKTerminExampleExtendedICU.json b/Resources/fsh-generated/resources/Appointment-ISiKTerminExampleExtendedICU.json index 73c26fdf..cc8fdc9b 100644 --- a/Resources/fsh-generated/resources/Appointment-ISiKTerminExampleExtendedICU.json +++ b/Resources/fsh-generated/resources/Appointment-ISiKTerminExampleExtendedICU.json @@ -44,11 +44,7 @@ { "code": "INTM", "system": "http://ihe-d.de/CodeSystems/AerztlicheFachrichtungen" - } - ] - }, - { - "coding": [ + }, { "code": "3600", "system": "http://fhir.de/CodeSystem/dkgev/Fachabteilungsschluessel-erweitert" diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKKalender.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKKalender.json index 1fa573b9..d119f618 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKKalender.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKKalender.json @@ -19,6 +19,7 @@ { "id": "Schedule.extension", "path": "Schedule.extension", + "comment": "Begründung Must-Support-Flag (MS): Die KalenderName-Extension ermöglicht es einen menschenlesbaren Namen zu definieren, welcher zur Wiedererkennbarkeit des Kalenders im Rahmen der Terminplanung dient.", "mustSupport": true }, { @@ -72,18 +73,27 @@ { "id": "Schedule.active", "path": "Schedule.active", + "comment": "Begründung Kardinalität und Must-Support-Flag (MS): Die Kardinalität 1..1 und das Must-Support-Flag (MS) für das 'active'-Element stellen sicher, dass jeder Kalender eindeutig als aktiv oder inaktiv gekennzeichnet ist. Dies ist entscheidend für die Ressourcenplanung und Verfügbarkeit von Terminen.", "min": 1, "mustSupport": true }, { "id": "Schedule.serviceType", "path": "Schedule.serviceType", + "comment": "Begründung Kardinalität Must-Support-Flag (MS): Die Kardinalität 1..* und das Must-Support-Flag (MS) für das 'serviceType'-Element stellen sicher, dass jeder Kalender mindestens eine Dienstleistungsart angibt. Dies ist wichtig für die Ressourcenplanung und die Verfügbarkeit von Terminen, indem angefragte Termine einem Kalender zugeordnet werden können.", "min": 1, "mustSupport": true }, { "id": "Schedule.specialty", "path": "Schedule.specialty", + "comment": "Hinweis: Ein Kalender kann für ein Akteur gepflegt werden. Dieser Akteur kann in einer oder mehreren Fachrichtungen agieren. Für die Ressourcenplanung (z.B. welche Akteure sind für einen Termin verfügbar) sollte auch auf die Speciality des Akteurs zurückgegriffen werden für den Fall, dass ein Kalender pro Fachbereich - d.h. Akteur-übergreifend - gepflegt wird. \n \n Begründung Kardinalität Must-Support-Flag (MS): Die Kardinalität 1..* und das Must-Support-Flag (MS) für das 'specialty'-Element stellen sicher, dass jeder Kalender mindestens eine Fachrichtung angibt. Dies ist wichtig für die Ressourcenplanung und die Verfügbarkeit von Terminen, sodass angefragte Termine einem Fachbereich zugeordnet werden können.\n\n Hintergrund: Die Festlegung hat in einer Expertengruppe am 4.6.2024 stattgefunden. Diese war zuvor in einer ISiK Arbeitsgruppe bekanntgegeben worden und stand damit allen Beteiligten offen. \n ", + "min": 1, + "mustSupport": true + }, + { + "id": "Schedule.specialty.coding", + "path": "Schedule.specialty.coding", "slicing": { "discriminator": [ { @@ -93,12 +103,13 @@ ], "rules": "open" }, + "comment": "Begründung Kardinalität Fachrichtung: Die Kardinalität der Fachrichtung-Eigenschaft wird auf 1..1 festgelegt, um sicherzustellen, dass genau eine Fachrichtung per IHE-XDS-Kodierung vorhanden ist. Dies ist notwendig, um die Spezialisierung des Kalenders eindeutig zu definieren und eine korrekte Zuordnung zu gewährleisten.\n \n Begründung Kardinalität ErweiterterFachabteilungsschluessel: Die Kardinalität der ErweiterterFachabteilungsschluessel-Eigenschaft wird auf 0..1 festgelegt, um sicherzustellen, dass optional ein erweiterter Fachabteilungsschlüssel vorhanden sein kann.", "min": 1, "mustSupport": true }, { - "id": "Schedule.specialty:Fachrichtung", - "path": "Schedule.specialty", + "id": "Schedule.specialty.coding:Fachrichtung", + "path": "Schedule.specialty.coding", "sliceName": "Fachrichtung", "comment": "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).", "min": 1, @@ -110,15 +121,15 @@ } }, { - "id": "Schedule.specialty:ErweiterterFachabteilungsschluessel", - "path": "Schedule.specialty", + "id": "Schedule.specialty.coding:ErweiterterFachabteilungsschluessel", + "path": "Schedule.specialty.coding", "sliceName": "ErweiterterFachabteilungsschluessel", "comment": "Dieses ValueSet KANN über ein Mapping (siehe Abschnitt https://wiki.hl7.de/index.php?title=IG:Value_Sets_f%C3%BCr_XDS#DocumentEntry.practiceSettingCode) mit dem ValueSet der Fachrichtung verknüpft werden und darüber ggf. die Integration von Systemen erleichtern.", "min": 0, "max": "1", "binding": { "strength": "required", - "valueSet": "http://fhir.de/CodeSystem/dkgev/Fachabteilungsschluessel-erweitert" + "valueSet": "http://fhir.de/ValueSet/dkgev/Fachabteilungsschluessel-erweitert" } }, { @@ -133,17 +144,19 @@ ], "rules": "open" }, + "comment": "Begründung Kardinalität und Must-Support-Flag (MS): Die Kardinalität der Akteur-Eigenschaft wird auf 0..1 festgelegt, um sicherzustellen, dass ein Akteur eindeutig ist, falls dieser vorhanden ist. Durch das MS wird sichergestellt, dass Systeme in der Lage sind, einen Akteur zu unterstützen, wenn er vorhanden ist.", "mustSupport": true }, { "id": "Schedule.actor.identifier", "path": "Schedule.actor.identifier", + "comment": "Begründung Must-Support-Flag (MS):\n Das Must-Support-Flag (MS) für das 'identifier'-Element stellt sicher, dass Systeme in der Lage sind, einen Identifier zu unterstützen, wenn er vorhanden ist. Dies ist wichtig für die eindeutige Identifizierung und Verknüpfung von Akteuren in verschiedenen Systemen.", "mustSupport": true }, { "id": "Schedule.actor.display", "path": "Schedule.actor.display", - "min": 1, + "comment": "Hinweis und Begründung zum Must Support: 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 für welche Akteure ein Terminkalender existiert.\n \n", "mustSupport": true }, { @@ -168,6 +181,7 @@ { "id": "Schedule.actor:Akteur.reference", "path": "Schedule.actor.reference", + "comment": "Begründung Kardinalität: Die Kardinalität der Akteur-Eigenschaft wird auf 1..1 festgelegt, um sicherzustellen, dass ein eindeutiger Akteur vorhanden ist.", "min": 1, "mustSupport": true } diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKMedizinischeBehandlungseinheit.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKMedizinischeBehandlungseinheit.json index c1ba31cb..dce64b63 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKMedizinischeBehandlungseinheit.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKMedizinischeBehandlungseinheit.json @@ -19,18 +19,27 @@ { "id": "HealthcareService.active", "path": "HealthcareService.active", + "comment": "Bedeutung: Ist der HealthcareService in aktiver Verwendung.\n \n Hinweis: Historische HealthcareServices können ebenfalls über die ISiK-Schnittstelle ausgetauscht werden. Für diese dürfen jedoch keine Termine vereinbart werden. Das terminführende System MUSS dies bei der Buchung überprüfen.\n \n Begründung Kardinalität und Must-Support-Flag (MS): Die Kardinalität 1..1 und das Must-Support-Flag (MS) für das 'active'-Element stellen sicher, dass jede Behandlungseinheit eindeutig als aktiv oder inaktiv gekennzeichnet ist. Dies ist entscheidend für die Ressourcenplanung und Verfügbarkeit von Behandlungseinheiten.", "min": 1, "mustSupport": true }, { "id": "HealthcareService.type", "path": "HealthcareService.type", + "comment": "**Bedeutung:** Klassifikation der Behandlungsleistung welche durch den HealthcareService erbracht wird\n\n**Hinweis:** Diese Klassifikation SOLL stets auch in Appointment.serviceType und Schedule.serviceType angegeben werden. Seitens der aktuellen Spezifikation werden keine Vorgaben bezüglich der zu verwendenden Terminologie gemacht. Entsprechend verwendete Kataloge müssen als CodeSystem- und ValueSet-Ressourcen exponiert werden. Siehe [Suchparameter 'context-type-value' in ISiK Basis - Datenobjekt ValueSet](https://simplifier.net/resolve?&scope=isik-basis-v4@current&canonical=https://gematik.de/fhir/isik/StructureDefinition/ISiKValueSet).\n\n**Begründung Kardinalität:** Eine Behandlungseinheit muss mindestens einen Typ haben, sodass im Rahmen der Terminplanung ermittelt werden kann welcher Akteur für die Durchführung eines Termins zur Verfügung steht.", "min": 1, "mustSupport": true }, { "id": "HealthcareService.specialty", "path": "HealthcareService.specialty", + "comment": "**Bedeutung:** Fachrichtung der Behandlungsleistung welche durch den HealthcareService erbracht wird\n\n**Hinweis:** Diese Fachrichtung SOLL stets auch in Appointment.specialty und Schedule.specialty angegeben werden.\n \n**Begründung Kardinalität:** Eine Behandlungseinheit kann multiprofessionell sein und mehere Fachbereiche abdecken. Sie muss jedoch mindestens einem Fachbereich zugeordnet sein, sodass die Behandlungseinheit während der Terminplanung als Akteur miteinbezogen werden für passende Termine.", + "min": 1, + "mustSupport": true + }, + { + "id": "HealthcareService.specialty.coding", + "path": "HealthcareService.specialty.coding", "slicing": { "discriminator": [ { @@ -40,12 +49,13 @@ ], "rules": "open" }, + "comment": "Begründung Kardinalität Fachrichtung: Die Kardinalität der Fachrichtung-Eigenschaft wird auf 1..1 festgelegt, um sicherzustellen, dass genau eine Fachrichtung per IHE-XDS-Kodierung vorhanden ist. Dies ist notwendig, um die Spezialisierung der Behandlungseinheit eindeutig zu definieren und eine korrekte Zuordnung zu gewährleisten.\n \n Begründung Kardinalität ErweiterterFachabteilungsschluessel: Die Kardinalität der ErweiterterFachabteilungsschluessel-Eigenschaft wird auf 0..1 festgelegt, um sicherzustellen, dass optional ein erweiterter Fachabteilungsschlüssel vorhanden sein kann.", "min": 1, "mustSupport": true }, { - "id": "HealthcareService.specialty:Fachrichtung", - "path": "HealthcareService.specialty", + "id": "HealthcareService.specialty.coding:Fachrichtung", + "path": "HealthcareService.specialty.coding", "sliceName": "Fachrichtung", "comment": "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).", "min": 1, @@ -57,20 +67,21 @@ } }, { - "id": "HealthcareService.specialty:ErweiterterFachabteilungsschluessel", - "path": "HealthcareService.specialty", + "id": "HealthcareService.specialty.coding:ErweiterterFachabteilungsschluessel", + "path": "HealthcareService.specialty.coding", "sliceName": "ErweiterterFachabteilungsschluessel", "comment": "Dieses ValueSet KANN über ein Mapping (siehe Abschnitt https://wiki.hl7.de/index.php?title=IG:Value_Sets_f%C3%BCr_XDS#DocumentEntry.practiceSettingCode) mit dem ValueSet der Fachrichtung verknüpft werden und darüber ggf. die Integration von Systemen erleichtern.", "min": 0, "max": "1", "binding": { "strength": "required", - "valueSet": "http://fhir.de/CodeSystem/dkgev/Fachabteilungsschluessel-erweitert" + "valueSet": "http://fhir.de/ValueSet/dkgev/Fachabteilungsschluessel-erweitert" } }, { "id": "HealthcareService.name", "path": "HealthcareService.name", + "comment": "**Bedeutung:** Informeller Name der Behandlungseinheit\n\n**Hinweis:** Es wird im Rahmen dieser Spezifikation davon ausgegangen, dass für einen HealthcareService keine natürlichen Identifier vorliegen, die in einem realen Kontext vergeben werden. Somit kann durch den Namen ein informeller, jedoch identifizierender Bezeichner vergeben werden.\n\n**Begründung Kardinalität:** Eine Behandlungseinheit muss mindestens einen Namen haben, um eine Wiedererkennbarkeit im Rahmen der Terminplanung zu gewährleisten.", "min": 1, "mustSupport": true } diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKNachricht.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKNachricht.json index 9278a9ed..64f349ed 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKNachricht.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKNachricht.json @@ -19,6 +19,7 @@ { "id": "Communication.inResponseTo", "path": "Communication.inResponseTo", + "comment": "Begründung Must Support: Es wird hierdurch ermöglicht auf Nachrichten die der Patient vorab übermittelt hat zu beantworten.", "mustSupport": true }, { @@ -29,7 +30,7 @@ { "id": "Communication.subject", "path": "Communication.subject", - "comment": "Im ISIK-Kontext MUSS der referenzierte Patient konform zum [ISIKPatient](https://gematik.de/fhir/isik/v3/Basismodul/StructureDefinition/ISiKPatient) des Basismoduls sein.", + "comment": "Im ISIK-Kontext MUSS der referenzierte Patient konform zum [ISIKPatient](https://gematik.de/fhir/isik/StructureDefinition/ISiKPatient) des Basismoduls sein.", "min": 1, "type": [ { @@ -44,6 +45,7 @@ { "id": "Communication.sent", "path": "Communication.sent", + "comment": "Begründung Must Support: Eine zeitlich korrekte Darstellung der Nachrichten wird hierdurch ermöglicht", "mustSupport": true }, { @@ -58,18 +60,20 @@ ], "rules": "open" }, - "comment": "Im ISIK-Kontext MUSS die referenzierte Practitioner-Ressource konform zum [ISiKPersonImGesundheitsberuf](https://gematik.de/fhir/isik/v3/Basismodul/StructureDefinition/ISiKPersonImGesundheitsberuf) des Basismoduls sein.", + "comment": "Im ISIK-Kontext MUSS die referenzierte Practitioner-Ressource konform zum [ISiKPersonImGesundheitsberuf](https://gematik.de/fhir/isik/StructureDefinition/ISiKPersonImGesundheitsberuf) des Basismoduls sein.", "min": 1, "mustSupport": true }, { "id": "Communication.recipient.identifier", "path": "Communication.recipient.identifier", + "comment": "Begründung Kardinalität und Must-Support-Flag (MS): Die Kardinalität der identifier-Eigenschaft wird auf 0..1 festgelegt, um sicherzustellen, dass ein Empfänger über einen eindeutigen Identifier referenzierbar ist.", "mustSupport": true }, { "id": "Communication.recipient.display", "path": "Communication.recipient.display", + "comment": "Begründung Kardinalität und Must Support: Die Kardinalität der display-Eigenschaft wird auf 1..1 festgelegt, um sicherzustellen, dass ein Empfänger immer eindeutig benannt wird. Das Must Support wird auf 'true' gesetzt, um sicherzustellen, dass Systeme in der Lage sind, einen Empfänger anzuzeigen, ohne die Referenzen auflösen zu müssen. Somit kann ein Termin-Consumer direkt anzeigen für welche Empfänger eine Nachricht existiert.", "min": 1, "mustSupport": true }, @@ -99,18 +103,33 @@ { "id": "Communication.sender", "path": "Communication.sender", + "comment": "Begründung Kardinalität und Must Support: Die Kardinalität der sender-Eigenschaft wird auf 1..1 festgelegt, um sicherzustellen, dass mindestens ein Sender vorhanden ist. Das Must Support wird auf 'true' gesetzt, um sicherzustellen, dass Systeme in der Lage sind, einen Sender zu unterstützen, wenn er vorhanden ist.", "min": 1, "mustSupport": true }, { "id": "Communication.sender.reference", "path": "Communication.sender.reference", + "comment": "Im ISIK-Kontext MUSS die referenzierte Practitioner-Ressource konform zum [ISiKPersonImGesundheitsberuf](https://gematik.de/fhir/isik/StructureDefinition/ISiKPersonImGesundheitsberuf) des Basismoduls sein. Im ISIK-Kontext MUSS die referenzierte RelatedPerson-Ressource konform zum [ISiKAngehoeriger](https://gematik.de/fhir/isik/StructureDefinition/ISiKAngehoeriger) des Basismoduls sein. Im ISIK-Kontext MUSS die referenzierte RelatedPerson-Ressource konform zum [ISiKPatient](https://gematik.de/fhir/isik/StructureDefinition/ISiKPatient) des Basismoduls sein.", + "mustSupport": true + }, + { + "id": "Communication.sender.identifier", + "path": "Communication.sender.identifier", + "comment": "Begründung Kardinalität und Must-Support-Flag (MS): Die Kardinalität der identifier-Eigenschaft wird auf 0..1 festgelegt, um sicherzustellen, dass höchstens ein Identifier vorhanden ist, damit ein Sender eindeutig über einen Identifier referenzierbar ist.", + "mustSupport": true + }, + { + "id": "Communication.sender.display", + "path": "Communication.sender.display", + "comment": "Begründung Kardinalität und Must Support: Die Kardinalität der display-Eigenschaft wird auf 1..1 festgelegt, um sicherzustellen, dass ein Sender immer eindeutig benannt wird. Das Must Support wird auf 'true' gesetzt, um sicherzustellen, dass Systeme in der Lage sind, einen Empfänger anzuzeigen, ohne die Referenzen auflösen zu müssen. Somit kann ein Termin-Consumer direkt anzeigen welche Sender eine Nachricht verfasst haben.", "min": 1, "mustSupport": true }, { "id": "Communication.payload", "path": "Communication.payload", + "comment": "Begründung Kardinalität und Must Support: Die Kardinalität der payload-Eigenschaft wird auf 1..* festgelegt, um sicherzustellen, dass ein Inhalt vorhanden ist. Das Must Support wird auf 'true' gesetzt, um sicherzustellen, dass Systeme in der Lage sind, einen Inhalt zu unterstützen, wenn er vorhanden ist.", "min": 1, "mustSupport": true }, diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKTermin.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKTermin.json index ef6f2988..03ad3e5b 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKTermin.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKTermin.json @@ -32,6 +32,7 @@ { "id": "Appointment.meta", "path": "Appointment.meta", + "comment": "Ein Tag kann verwendet werden um zu kennzeichnen, dass die Ressource von Extern erstellt worden ist.", "mustSupport": true }, { @@ -63,7 +64,7 @@ { "id": "Appointment.extension", "path": "Appointment.extension", - "definition": "Conditional Must Support - Einschränkung der übergreifenden MS-Definition: Falls ein bestätigungsrelevantes System das ISiK-Profil ISiKNachricht implementiert, MUSS das System auch dieses Element unterstützten. Andernfalls KANN das System dieses Element unterstützen.", + "comment": "Begründung zum Must Support: Termineabsagen sollten verkettbar sein, da am originalen Termin noch weitere Informationen hängen können.", "mustSupport": true }, { @@ -101,11 +102,13 @@ { "id": "Appointment.status", "path": "Appointment.status", + "comment": "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.", "mustSupport": true }, { "id": "Appointment.cancelationReason", "path": "Appointment.cancelationReason", + "comment": "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.", "mustSupport": true, "binding": { "strength": "required", @@ -115,12 +118,19 @@ { "id": "Appointment.serviceType", "path": "Appointment.serviceType", + "comment": "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).", "min": 1, "mustSupport": true }, { "id": "Appointment.specialty", "path": "Appointment.specialty", + "comment": "Optionale Angabe aller Fachbereiche aus denen ein oder mehrere Akteure für die Durchführung des Termins benötigt werden. \n \n Begründung zu Kardinalität und Must Support: KANN auch anhand des Kalenders, in dem ein Termin gebucht wird, ermittelt werden.\n 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.\n ", + "mustSupport": true + }, + { + "id": "Appointment.specialty.coding", + "path": "Appointment.specialty.coding", "slicing": { "discriminator": [ { @@ -134,10 +144,10 @@ "mustSupport": true }, { - "id": "Appointment.specialty:Fachrichtung", - "path": "Appointment.specialty", + "id": "Appointment.specialty.coding:Fachrichtung", + "path": "Appointment.specialty.coding", "sliceName": "Fachrichtung", - "comment": "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).", + "comment": "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.\n \n 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).", "min": 1, "max": "1", "mustSupport": true, @@ -147,25 +157,27 @@ } }, { - "id": "Appointment.specialty:ErweiterterFachabteilungsschluessel", - "path": "Appointment.specialty", + "id": "Appointment.specialty.coding:ErweiterterFachabteilungsschluessel", + "path": "Appointment.specialty.coding", "sliceName": "ErweiterterFachabteilungsschluessel", - "comment": "Dieses ValueSet KANN über ein Mapping (siehe Abschnitt https://wiki.hl7.de/index.php?title=IG:Value_Sets_f%C3%BCr_XDS#DocumentEntry.practiceSettingCode) mit dem ValueSet der Fachrichtung verknüpft werden und darüber ggf. die Integration von Systemen erleichtern.", + "comment": "Hinweis: Dieses ValueSet KANN über ein Mapping (siehe Abschnitt https://wiki.hl7.de/index.php?title=IG:Value_Sets_f%C3%BCr_XDS#DocumentEntry.practiceSettingCode) mit dem ValueSet der Fachrichtung verknüpft werden und darüber ggf. die Integration von Systemen erleichtern.", "min": 0, "max": "1", "binding": { "strength": "required", - "valueSet": "http://fhir.de/CodeSystem/dkgev/Fachabteilungsschluessel-erweitert" + "valueSet": "http://fhir.de/ValueSet/dkgev/Fachabteilungsschluessel-erweitert" } }, { "id": "Appointment.priority", "path": "Appointment.priority", + "comment": "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.", "mustSupport": true }, { "id": "Appointment.priority.extension", "path": "Appointment.priority.extension", + "comment": "Hinweis: In R5 ist die Priority ein CodeableConcept. \n \n 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.", "mustSupport": true }, { @@ -187,19 +199,21 @@ { "id": "Appointment.start", "path": "Appointment.start", + "comment": "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 ist dieses Feld verpflichtend (1..1) und muss unterstützt werden (MS).", "min": 1, "mustSupport": true }, { "id": "Appointment.end", "path": "Appointment.end", + "comment": "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 ist dieses Feld verpflichtend (1..1) und muss unterstützt werden (MS).", "min": 1, "mustSupport": true }, { "id": "Appointment.slot", "path": "Appointment.slot", - "comment": "Zur Referenzierung auf eine Slot-Ressource MUSS eine Reference.reference mit einer URL verwendet werden. Das Termin-Repository muss so gestaltet sein, dass es aus Perspektive des Clients nur eine Service-BaseUrl gibt.", + "comment": "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.", "mustSupport": true }, { @@ -211,13 +225,13 @@ { "id": "Appointment.comment", "path": "Appointment.comment", - "comment": "Im ISiK Kontext sollte dieses Feld zur internen Kommunikation zwischen Leistungserbringern verwendet werden, z.B. für interne Notizen rund um den Termin.\n\nEs gilt weiterhin die Semantik des Elements nach FHIR-Kernspezifikation:\n\n'Additional text to aid in facilitating the appointment. For instance, a comment might be, 'patient should proceed immediately to infusion room upon arrival'\n\nWhere 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.'", + "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.\n\nBegrü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. \n\nEs gilt weiterhin die Semantik des Elements nach FHIR-Kernspezifikation:\n\n'Additional text to aid in facilitating the appointment. For instance, a comment might be, 'patient should proceed immediately to infusion room upon arrival'\n\nWhere 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.'", "mustSupport": true }, { "id": "Appointment.patientInstruction", "path": "Appointment.patientInstruction", - "comment": "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.\n\nBeispiel für eine Nachricht: 'Bitte nüchtern erscheinen' etc.\n\nEs gilt weiterhin der Hinweis der FHIR Kernspezifikation:\n'Note that FHIR strings SHALL NOT exceed 1MB in size'", + "comment": "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.\n\nBeispiel für eine Nachricht: 'Bitte nüchtern erscheinen' etc.\n\nBegrü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. \n\nEs gilt weiterhin der Hinweis der FHIR Kernspezifikation:\n'Note that FHIR strings SHALL NOT exceed 1MB in size'", "mustSupport": true }, { @@ -232,7 +246,7 @@ ], "rules": "open" }, - "comment": "Die Kardinalität von actor.display und das MS-Flag von .status wird an die Slices vererbt und diese sind entsprechend zu implementieren.", + "comment": "Hinweis: Die Kardinalität von actor.display und das MS-Flag von .status wird an die Slices vererbt und diese sind entsprechend zu implementieren.\n\nBegrü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).", "mustSupport": true }, { @@ -256,7 +270,7 @@ "id": "Appointment.participant:AkteurPatient", "path": "Appointment.participant", "sliceName": "AkteurPatient", - "comment": "Im ISIK-Kontext MUSS der referenzierte Patient konform zum [ISIKPatient](https://gematik.de/fhir/isik/v3/Basismodul/StructureDefinition/ISiKPatient) des Basismoduls sein.", + "comment": "Hinweis: Im ISIK-Kontext MUSS der referenzierte Patient konform zum [ISIKPatient](https://gematik.de/fhir/isik/v3/Basismodul/StructureDefinition/ISiKPatient) des Basismoduls sein.\n\nBegrü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 ist dieses Feld verpflichtend (1..*) und muss unterstützt werden (MS).", "min": 1, "max": "*", "mustSupport": true @@ -283,7 +297,7 @@ "id": "Appointment.participant:AkteurPersonImGesundheitsberuf", "path": "Appointment.participant", "sliceName": "AkteurPersonImGesundheitsberuf", - "comment": "Im ISIK-Kontext MUSS die referenzierte Practitioner-Ressource konform zum [ISiKPersonImGesundheitsberuf](https://gematik.de/fhir/isik/v3/Basismodul/StructureDefinition/ISiKPersonImGesundheitsberuf) des Basismoduls sein.", + "comment": "Im ISIK-Kontext MUSS die referenzierte Practitioner-Ressource konform zum [ISiKPersonImGesundheitsberuf](https://gematik.de/fhir/isik/v3/Basismodul/StructureDefinition/ISiKPersonImGesundheitsberuf) des Basismoduls sein.\n\nBegründung zu Kardinalität und Must Support: Die teilnehmenden Personen mit einem Gesundheitsberuf eines Termins sind entscheidend und müssen daher implementiert werden (MS), allerdings sind sie nicht zwingend erforderlich (0..*), da die Übernahme auch durch eine Behandlungseinheit erfolgen kann.", "min": 0, "max": "*", "mustSupport": true diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKTerminKontaktMitGesundheitseinrichtung.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKTerminKontaktMitGesundheitseinrichtung.json index a0697bcf..02301fcb 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKTerminKontaktMitGesundheitseinrichtung.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKTerminKontaktMitGesundheitseinrichtung.json @@ -19,6 +19,7 @@ { "id": "Encounter.appointment", "path": "Encounter.appointment", + "comment": "**Hinweis:** Zur Umsetzung der Funktionalität zum Dokumentenaustausch gemäß ISiK ist der entsprechende [Implementation Guide zum Modul Dokumentenaustausch](https://simplifier.net/guide/isik-dokumentenaustausch-v4?version=current) zu beachten.\n \n Begründung Must Support: Die Referenz auf Appointment ermöglicht Portalen den Fallbezug aus dem Termin zu ermitteln und Dokumente an ein KIS zu senden. Das Element 'appointment' ist Must-Support, um sicherzustellen, dass ein Termin immer abrufbar ist, sofern er mit einem Fallkontaktverknüft ist.", "mustSupport": true } ] diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKTerminblock.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKTerminblock.json index 451d6bd6..7835d06a 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKTerminblock.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKTerminblock.json @@ -32,7 +32,7 @@ { "id": "Slot.schedule", "path": "Slot.schedule", - "comment": "Zur Referenzierung auf eine Schedule-Ressource MUSS eine Reference.reference mit einer URL verwendet werden. Das Termin-Repository muss so gestaltet sein, dass es aus Perspektive des Clients nur eine Service-BaseUrl gibt.", + "comment": "Begründung Kardinalität und MS: Die Kardinalität der reference-Eigenschaft wird auf 1..* festgelegt, um sicherzustellen, dass ein Kalender eindeutig referenziert und identifiziert werden kann.", "mustSupport": true }, { @@ -44,16 +44,19 @@ { "id": "Slot.status", "path": "Slot.status", + "comment": "Begründung Must Support: Dies ist wichtig, um die Verfügbarkeit von Terminen zu gewährleisten, eine Überbuchung zu verhindern und zudem einem Termin-Requestor die Möglichkeit zu bieten nur freie Termine bei der Terminbuchung anzuzeigen.", "mustSupport": true }, { "id": "Slot.start", "path": "Slot.start", + "comment": "Begründung Must Support: Dies ist wichtig, um den Zeitpunkt des Termins an einen Termin-Requestor / Termin-Consumer zu kommunizieren.", "mustSupport": true }, { "id": "Slot.end", "path": "Slot.end", + "comment": "Begründung Must Support: Dies ist wichtig, um die Länge des Termins an einen Termin-Requestor / Termin-Consumer zu kommunizieren.", "mustSupport": true } ] diff --git a/Resources/fsh-generated/resources/ValueSet-ISiKTerminCancelationReason.json b/Resources/fsh-generated/resources/ValueSet-ISiKTerminCancelationReason.json index 0f4abc3e..21edf4a3 100644 --- a/Resources/fsh-generated/resources/ValueSet-ISiKTerminCancelationReason.json +++ b/Resources/fsh-generated/resources/ValueSet-ISiKTerminCancelationReason.json @@ -4,10 +4,10 @@ "name": "ISiKTerminCancelationReason", "id": "ISiKTerminCancelationReason", "description": "Enthaelt alle erlaubten Gruende fuer eine Stornierung eines ISiKTermins", - "version": "4.0.0", "url": "https://gematik.de/fhir/isik/ValueSet/ISiKTerminCancelationReason", "experimental": false, "publisher": "gematik GmbH", + "version": "4.0.0", "date": "2024-09-09", "compose": { "include": [ diff --git a/Resources/fsh-generated/resources/ValueSet-ISiKTerminPriority.json b/Resources/fsh-generated/resources/ValueSet-ISiKTerminPriority.json index b98e741e..30dbf4bf 100644 --- a/Resources/fsh-generated/resources/ValueSet-ISiKTerminPriority.json +++ b/Resources/fsh-generated/resources/ValueSet-ISiKTerminPriority.json @@ -4,20 +4,83 @@ "name": "ISiKTerminPriority", "id": "ISiKTerminPriority", "description": "Enthaelt alle SNOMED Codes, die eine valide Priorität für den ISiKTermin sind", - "version": "4.0.0", "url": "https://gematik.de/fhir/isik/ValueSet/ISiKTerminPriority", "experimental": false, "publisher": "gematik GmbH", + "version": "4.0.0", "date": "2024-09-09", "compose": { "include": [ { "system": "http://snomed.info/sct", - "filter": [ + "concept": [ + { + "code": "709122007", + "display": "ASAP" + }, + { + "code": "441808003", + "display": "Delayed priority" + }, + { + "code": "103390000", + "display": "Elective" + }, + { + "code": "25876001", + "display": "Emergency" + }, + { + "code": "394849002", + "display": "High priority" + }, + { + "code": "88694003", + "display": "Immediate" + }, + { + "code": "1251527002", + "display": "Low priority" + }, + { + "code": "394848005", + "display": "Normal priority" + }, + { + "code": "76561005", + "display": "Reclassified" + }, + { + "code": "44408006", + "display": "Reclassified and rescheduled" + }, + { + "code": "64695001", + "display": "Repeat elective" + }, + { + "code": "21282002", + "display": "Repeat emergency" + }, + { + "code": "58334001", + "display": "Rescheduled" + }, + { + "code": "50811001", + "display": "Routine" + }, + { + "code": "416774000", + "display": "Scheduled - priority" + }, + { + "code": "49499008", + "display": "Stat" + }, { - "property": "concept", - "op": "descendent-of", - "value": "272125009" + "code": "103391001", + "display": "Urgent" } ] } diff --git a/Resources/input/fsh/ISiKKalender.fsh b/Resources/input/fsh/ISiKKalender.fsh index 101d916f..74fe7438 100644 --- a/Resources/input/fsh/ISiKKalender.fsh +++ b/Resources/input/fsh/ISiKKalender.fsh @@ -3,30 +3,51 @@ Parent: Schedule Id: ISiKKalender * insert Meta * active 1..1 MS + * ^comment = "Begründung Kardinalität und Must-Support-Flag (MS): Die Kardinalität 1..1 und das Must-Support-Flag (MS) für das 'active'-Element stellen sicher, dass jeder Kalender eindeutig als aktiv oder inaktiv gekennzeichnet ist. Dies ist entscheidend für die Ressourcenplanung und Verfügbarkeit von Terminen." * serviceType 1..* MS + * ^comment = "Begründung Kardinalität Must-Support-Flag (MS): Die Kardinalität 1..* und das Must-Support-Flag (MS) für das 'serviceType'-Element stellen sicher, dass jeder Kalender mindestens eine Dienstleistungsart angibt. Dies ist wichtig für die Ressourcenplanung und die Verfügbarkeit von Terminen, indem angefragte Termine einem Kalender zugeordnet werden können." * specialty 1..* MS + * ^comment = "Hinweis: Ein Kalender kann für ein Akteur gepflegt werden. Dieser Akteur kann in einer oder mehreren Fachrichtungen agieren. Für die Ressourcenplanung (z.B. welche Akteure sind für einen Termin verfügbar) sollte auch auf die Speciality des Akteurs zurückgegriffen werden für den Fall, dass ein Kalender pro Fachbereich - d.h. Akteur-übergreifend - gepflegt wird. + + Begründung Kardinalität Must-Support-Flag (MS): Die Kardinalität 1..* und das Must-Support-Flag (MS) für das 'specialty'-Element stellen sicher, dass jeder Kalender mindestens eine Fachrichtung angibt. Dies ist wichtig für die Ressourcenplanung und die Verfügbarkeit von Terminen, sodass angefragte Termine einem Fachbereich zugeordnet werden können. + + Hintergrund: Die Festlegung hat in einer Expertengruppe am 4.6.2024 stattgefunden. Diese war zuvor in einer ISiK Arbeitsgruppe bekanntgegeben worden und stand damit allen Beteiligten offen. + " +* specialty.coding 1..* MS * ^slicing.discriminator.type = #pattern * ^slicing.discriminator.path = "$this" * ^slicing.rules = #open -* specialty contains + * ^comment = "Begründung Kardinalität Fachrichtung: Die Kardinalität der Fachrichtung-Eigenschaft wird auf 1..1 festgelegt, um sicherzustellen, dass genau eine Fachrichtung per IHE-XDS-Kodierung vorhanden ist. Dies ist notwendig, um die Spezialisierung des Kalenders eindeutig zu definieren und eine korrekte Zuordnung zu gewährleisten. + + Begründung Kardinalität ErweiterterFachabteilungsschluessel: Die Kardinalität der ErweiterterFachabteilungsschluessel-Eigenschaft wird auf 0..1 festgelegt, um sicherzustellen, dass optional ein erweiterter Fachabteilungsschlüssel vorhanden sein kann." +* specialty.coding contains Fachrichtung 1..1 MS and ErweiterterFachabteilungsschluessel 0..1 -* specialty[Fachrichtung] from $IHEpracticeSettingVS (required) +* specialty.coding[Fachrichtung] from $IHEpracticeSettingVS (required) * ^comment = "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)." -* specialty[ErweiterterFachabteilungsschluessel] from $FachabteilungsschluesselErweitertCS (required) +* specialty.coding[ErweiterterFachabteilungsschluessel] from $FachabteilungsschluesselErweitertVS (required) * ^comment = "Dieses ValueSet KANN über ein Mapping (siehe Abschnitt https://wiki.hl7.de/index.php?title=IG:Value_Sets_f%C3%BCr_XDS#DocumentEntry.practiceSettingCode) mit dem ValueSet der Fachrichtung verknüpft werden und darüber ggf. die Integration von Systemen erleichtern." -* actor 1..* MS - * identifier 0..1 MS - * display 1..1 MS +* actor MS + * ^comment = "Begründung Must-Support-Flag (MS): Das MS-Flag für das 'actor'-Element stellt sicher, dass Systeme in der Lage sind, einen Akteur zu unterstützen, wenn er vorhanden ist. Dies ist wichtig für die Ressourcenplanung und die Verfügbarkeit von Terminen, da jeder Termin nach FHIR-Kernspezifikation einem spezifischen Akteur zugeordnet werden muss. Ohne diese Zuordnung wäre es schwierig, die Verfügbarkeit und Zuständigkeit der Akteure zu verwalten." + * identifier MS + * ^comment = "Begründung Must-Support-Flag (MS): + Das Must-Support-Flag (MS) für das 'identifier'-Element stellt sicher, dass Systeme in der Lage sind, einen Identifier zu unterstützen, wenn er vorhanden ist. Dies ist wichtig für die eindeutige Identifizierung und Verknüpfung von Akteuren in verschiedenen Systemen." + * display MS + * ^comment = "Hinweis und Begründung zum Must Support: 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 für welche Akteure ein Terminkalender existiert. + +" * ^slicing.discriminator.type = #type * ^slicing.discriminator.path = "$this" * ^slicing.rules = #open * actor contains Akteur 0..1 MS + * ^comment = "Begründung Kardinalität und Must-Support-Flag (MS): Die Kardinalität der Akteur-Eigenschaft wird auf 0..1 festgelegt, um sicherzustellen, dass ein Akteur eindeutig ist, falls dieser vorhanden ist. Durch das MS wird sichergestellt, dass Systeme in der Lage sind, einen Akteur zu unterstützen, wenn er vorhanden ist." * actor[Akteur] only Reference(Practitioner or HealthcareService or Location) * actor[Akteur] ^comment = "Im ISIK-Kontext MUSS die referenzierte Practitioner-Ressource konform zum [ISiKPersonImGesundheitsberuf](https://gematik.de/fhir/isik/StructureDefinition/ISiKPersonImGesundheitsberuf) des Basismoduls sein. Zudem MUSS die referenzierte Location-Ressource konform zum [ISiKStandort](https://gematik.de/fhir/isik/StructureDefinition/ISiKStandort) des Basismoduls sein. Dieses Element dient dazu, um alle Akteure zu gruppieren, sodass für diese Einheit von Terminressourcen ein Terminblock herausgegeben werden kann. Unter 'Akteure' fallen hier auch Standorte und Dienstleistungen." * actor[Akteur].reference 1..1 MS + * ^comment = "Begründung Kardinalität: Die Kardinalität der Akteur-Eigenschaft wird auf 1..1 festgelegt, um sicherzustellen, dass ein eindeutiger Akteur vorhanden ist." * extension MS * extension contains http://hl7.org/fhir/5.0/StructureDefinition/extension-Schedule.name named KalenderName 0..1 MS + * ^comment = "Begründung Must-Support-Flag (MS): Die KalenderName-Extension ermöglicht es einen menschenlesbaren Namen zu definieren, welcher zur Wiedererkennbarkeit des Kalenders im Rahmen der Terminplanung dient." * valueString 1..1 // This extension can be safely removed as soon as a package for R5 backport extensions is published and referenced by this project diff --git a/Resources/input/fsh/ISiKMedizinischeBehandlungseinheit.fsh b/Resources/input/fsh/ISiKMedizinischeBehandlungseinheit.fsh index 117da80a..0812f10c 100644 --- a/Resources/input/fsh/ISiKMedizinischeBehandlungseinheit.fsh +++ b/Resources/input/fsh/ISiKMedizinischeBehandlungseinheit.fsh @@ -3,24 +3,48 @@ Parent: HealthcareService Id: ISiKMedizinischeBehandlungseinheit * insert Meta * active 1..1 MS + * ^comment = "Bedeutung: Ist der HealthcareService in aktiver Verwendung. + + Hinweis: Historische HealthcareServices können ebenfalls über die ISiK-Schnittstelle ausgetauscht werden. Für diese dürfen jedoch keine Termine vereinbart werden. Das terminführende System MUSS dies bei der Buchung überprüfen. + + Begründung Kardinalität und Must-Support-Flag (MS): Die Kardinalität 1..1 und das Must-Support-Flag (MS) für das 'active'-Element stellen sicher, dass jede Behandlungseinheit eindeutig als aktiv oder inaktiv gekennzeichnet ist. Dies ist entscheidend für die Ressourcenplanung und Verfügbarkeit von Behandlungseinheiten." * type 1.. MS +* type ^comment = "**Bedeutung:** Klassifikation der Behandlungsleistung welche durch den HealthcareService erbracht wird + +**Hinweis:** Diese Klassifikation SOLL stets auch in Appointment.serviceType und Schedule.serviceType angegeben werden. Seitens der aktuellen Spezifikation werden keine Vorgaben bezüglich der zu verwendenden Terminologie gemacht. Entsprechend verwendete Kataloge müssen als CodeSystem- und ValueSet-Ressourcen exponiert werden. Siehe [Suchparameter 'context-type-value' in ISiK Basis - Datenobjekt ValueSet](https://simplifier.net/resolve?&scope=isik-basis-v4@current&canonical=https://gematik.de/fhir/isik/StructureDefinition/ISiKValueSet). + +**Begründung Kardinalität:** Eine Behandlungseinheit muss mindestens einen Typ haben, sodass im Rahmen der Terminplanung ermittelt werden kann welcher Akteur für die Durchführung eines Termins zur Verfügung steht." * specialty 1.. MS + * ^comment = "**Bedeutung:** Fachrichtung der Behandlungsleistung welche durch den HealthcareService erbracht wird + +**Hinweis:** Diese Fachrichtung SOLL stets auch in Appointment.specialty und Schedule.specialty angegeben werden. + +**Begründung Kardinalität:** Eine Behandlungseinheit kann multiprofessionell sein und mehere Fachbereiche abdecken. Sie muss jedoch mindestens einem Fachbereich zugeordnet sein, sodass die Behandlungseinheit während der Terminplanung als Akteur miteinbezogen werden für passende Termine." +* specialty.coding 1.. MS * ^slicing.discriminator.type = #pattern * ^slicing.discriminator.path = "$this" * ^slicing.rules = #open -* specialty contains + * ^comment = "Begründung Kardinalität Fachrichtung: Die Kardinalität der Fachrichtung-Eigenschaft wird auf 1..1 festgelegt, um sicherzustellen, dass genau eine Fachrichtung per IHE-XDS-Kodierung vorhanden ist. Dies ist notwendig, um die Spezialisierung der Behandlungseinheit eindeutig zu definieren und eine korrekte Zuordnung zu gewährleisten. + + Begründung Kardinalität ErweiterterFachabteilungsschluessel: Die Kardinalität der ErweiterterFachabteilungsschluessel-Eigenschaft wird auf 0..1 festgelegt, um sicherzustellen, dass optional ein erweiterter Fachabteilungsschlüssel vorhanden sein kann." +* specialty.coding contains Fachrichtung 1..1 MS and ErweiterterFachabteilungsschluessel 0..1 -* specialty[Fachrichtung] from $IHEpracticeSettingVS (required) +* specialty.coding[Fachrichtung] from $IHEpracticeSettingVS (required) * ^comment = "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)." -* specialty[ErweiterterFachabteilungsschluessel] from $FachabteilungsschluesselErweitertCS (required) +* specialty.coding[ErweiterterFachabteilungsschluessel] from $FachabteilungsschluesselErweitertVS (required) * ^comment = "Dieses ValueSet KANN über ein Mapping (siehe Abschnitt https://wiki.hl7.de/index.php?title=IG:Value_Sets_f%C3%BCr_XDS#DocumentEntry.practiceSettingCode) mit dem ValueSet der Fachrichtung verknüpft werden und darüber ggf. die Integration von Systemen erleichtern." * name 1.. MS + * ^comment = "**Bedeutung:** Informeller Name der Behandlungseinheit + +**Hinweis:** Es wird im Rahmen dieser Spezifikation davon ausgegangen, dass für einen HealthcareService keine natürlichen Identifier vorliegen, die in einem realen Kontext vergeben werden. Somit kann durch den Namen ein informeller, jedoch identifizierender Bezeichner vergeben werden. + +**Begründung Kardinalität:** Eine Behandlungseinheit muss mindestens einen Namen haben, um eine Wiedererkennbarkeit im Rahmen der Terminplanung zu gewährleisten." Instance: ISiKMedizinischeBehandlungseinheitExample InstanceOf: ISiKMedizinischeBehandlungseinheit Usage: #example * active = true * type = http://terminology.hl7.org/CodeSystem/service-type#124 -* specialty[Fachrichtung] = $IHEAerztlicheFachrichtungen#ALLG -* name = "Allgemeine Beratungsstelle der Fachabteilung 0100" \ No newline at end of file +* specialty.coding[Fachrichtung] = $IHEAerztlicheFachrichtungen#ALLG +* name = "Allgemeine Beratungsstelle der Fachabteilung 0100" diff --git a/Resources/input/fsh/ISiKNachricht.fsh b/Resources/input/fsh/ISiKNachricht.fsh index 585b78ea..165602b6 100644 --- a/Resources/input/fsh/ISiKNachricht.fsh +++ b/Resources/input/fsh/ISiKNachricht.fsh @@ -3,22 +3,29 @@ Parent: Communication Id: ISiKNachricht * insert Meta * inResponseTo MS + * ^comment = "Begründung Must Support: Es wird hierdurch ermöglicht auf Nachrichten die der Patient vorab übermittelt hat zu beantworten." * status MS -* subject 1..1 MS +* subject 1.. MS +* subject ^comment = "Begründung Kardinalität: Das Element 'subject' ist obligatorisch (1..1) und muss immer angegeben werden, um sicherzustellen, dass jede Nachricht eindeutig auf einen Patienten bezogen wird." * subject only Reference(Patient) -* subject ^comment = "Im ISIK-Kontext MUSS der referenzierte Patient konform zum [ISIKPatient](https://gematik.de/fhir/isik/v3/Basismodul/StructureDefinition/ISiKPatient) des Basismoduls sein." +* subject ^comment = "Im ISIK-Kontext MUSS der referenzierte Patient konform zum [ISIKPatient](https://gematik.de/fhir/isik/StructureDefinition/ISiKPatient) des Basismoduls sein." * sent MS + * ^comment = "Begründung Must Support: Eine zeitlich korrekte Darstellung der Nachrichten wird hierdurch ermöglicht" * recipient 1..* MS + * ^comment = "Begründung Kardinalität: Die Kardinalität der recipient-Eigenschaft wird auf 1..* festgelegt, um sicherzustellen, dass mindestens ein Empfänger vorhanden ist." * identifier 0..1 MS + * ^comment = "Begründung Kardinalität und Must-Support-Flag (MS): Die Kardinalität der identifier-Eigenschaft wird auf 0..1 festgelegt, um sicherzustellen, dass ein Empfänger über einen eindeutigen Identifier referenzierbar ist." * display 1..1 MS + * ^comment = "Begründung Kardinalität und Must Support: Die Kardinalität der display-Eigenschaft wird auf 1..1 festgelegt, um sicherzustellen, dass ein Empfänger immer eindeutig benannt wird. Das Must Support wird auf 'true' gesetzt, um sicherzustellen, dass Systeme in der Lage sind, einen Empfänger anzuzeigen, ohne die Referenzen auflösen zu müssen. Somit kann ein Termin-Consumer direkt anzeigen für welche Empfänger eine Nachricht existiert." * ^slicing.discriminator.type = #type * ^slicing.discriminator.path = "$this" * ^slicing.rules = #open * recipient contains ISiKRecipient 1.. MS * recipient[ISiKRecipient] only Reference(Practitioner or HealthcareService) * recipient[ISiKRecipient].reference 1..1 MS -* recipient ^comment = "Im ISIK-Kontext MUSS die referenzierte Practitioner-Ressource konform zum [ISiKPersonImGesundheitsberuf](https://gematik.de/fhir/isik/v3/Basismodul/StructureDefinition/ISiKPersonImGesundheitsberuf) des Basismoduls sein." +* recipient ^comment = "Im ISIK-Kontext MUSS die referenzierte Practitioner-Ressource konform zum [ISiKPersonImGesundheitsberuf](https://gematik.de/fhir/isik/StructureDefinition/ISiKPersonImGesundheitsberuf) des Basismoduls sein." * payload 1..* MS + * ^comment = "Begründung Kardinalität und Must Support: Die Kardinalität der payload-Eigenschaft wird auf 1..* festgelegt, um sicherzustellen, dass ein Inhalt vorhanden ist. Das Must Support wird auf 'true' gesetzt, um sicherzustellen, dass Systeme in der Lage sind, einen Inhalt zu unterstützen, wenn er vorhanden ist." * content[x] MS * contentString MS * contentAttachment MS @@ -27,7 +34,13 @@ Id: ISiKNachricht * url 1.. MS * creation 1.. MS * sender 1.. MS - * reference 1..1 MS + * ^comment = "Begründung Kardinalität und Must Support: Die Kardinalität der sender-Eigenschaft wird auf 1..1 festgelegt, um sicherzustellen, dass mindestens ein Sender vorhanden ist. Das Must Support wird auf 'true' gesetzt, um sicherzustellen, dass Systeme in der Lage sind, einen Sender zu unterstützen, wenn er vorhanden ist." + * reference 0..1 MS + * ^comment = "Im ISIK-Kontext MUSS die referenzierte Practitioner-Ressource konform zum [ISiKPersonImGesundheitsberuf](https://gematik.de/fhir/isik/StructureDefinition/ISiKPersonImGesundheitsberuf) des Basismoduls sein. Im ISIK-Kontext MUSS die referenzierte RelatedPerson-Ressource konform zum [ISiKAngehoeriger](https://gematik.de/fhir/isik/StructureDefinition/ISiKAngehoeriger) des Basismoduls sein. Im ISIK-Kontext MUSS die referenzierte RelatedPerson-Ressource konform zum [ISiKPatient](https://gematik.de/fhir/isik/StructureDefinition/ISiKPatient) des Basismoduls sein." + * identifier 0..1 MS + * ^comment = "Begründung Kardinalität und Must-Support-Flag (MS): Die Kardinalität der identifier-Eigenschaft wird auf 0..1 festgelegt, um sicherzustellen, dass höchstens ein Identifier vorhanden ist, damit ein Sender eindeutig über einen Identifier referenzierbar ist." + * display 1..1 MS + * ^comment = "Begründung Kardinalität und Must Support: Die Kardinalität der display-Eigenschaft wird auf 1..1 festgelegt, um sicherzustellen, dass ein Sender immer eindeutig benannt wird. Das Must Support wird auf 'true' gesetzt, um sicherzustellen, dass Systeme in der Lage sind, einen Empfänger anzuzeigen, ohne die Referenzen auflösen zu müssen. Somit kann ein Termin-Consumer direkt anzeigen welche Sender eine Nachricht verfasst haben." Instance: ISiKNachrichtExample InstanceOf: ISiKNachricht diff --git a/Resources/input/fsh/ISiKTermin.fsh b/Resources/input/fsh/ISiKTermin.fsh index 3f60366f..1abf4b0b 100644 --- a/Resources/input/fsh/ISiKTermin.fsh +++ b/Resources/input/fsh/ISiKTermin.fsh @@ -8,22 +8,32 @@ Id: ISiKTermin * ^slicing.discriminator.path = "$this" * ^slicing.rules = #open * tag contains Source 0..1 MS + * ^comment = "Ein Tag kann verwendet werden um zu kennzeichnen, dass die Ressource von Extern erstellt worden ist." * tag[Source] from http://fhir.de/ValueSet/common-meta-tag-de (required) * insert Meta * extension MS * extension contains ISiKNachrichtExtension named Nachricht 0..* MS - * ^definition = "Conditional Must Support - Einschränkung der übergreifenden MS-Definition: Falls ein bestätigungsrelevantes System das ISiK-Profil ISiKNachricht implementiert, MUSS das System auch dieses Element unterstützten. Andernfalls KANN das System dieses Element unterstützen." + * ^comment = "Einschränkung der übergreifenden MS-Definition: Falls ein bestätigungsrelevantes System das ISiK-Profil ISiKNachricht implementiert, MUSS das System auch dieses Element unterstützten. Andernfalls KANN das System dieses Element unterstützen. + + Begründung zum Must Support: Nachrichten die für diesen Termin verfasst wurden können somit direkt abgerufen werden." * extension contains http://hl7.org/fhir/5.0/StructureDefinition/extension-Appointment.replaces named replaces 0..1 MS -* status 1..1 MS -* cancelationReason 0..1 MS + * ^comment = "Begründung zum Must Support: Termineabsagen sollten verkettbar sein, da am originalen Termin noch weitere Informationen hängen können." +* status MS + * ^comment = "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." +* cancelationReason MS + * ^comment = "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." * cancelationReason from ISiKTerminCancelationReason (required) * start 1..1 MS + * ^comment = "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 ist dieses Feld verpflichtend (1..1) und muss unterstützt werden (MS)." * end 1..1 MS -* slot 0..* MS + * ^comment = "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 ist dieses Feld verpflichtend (1..1) und muss unterstützt werden (MS)." +* slot MS * reference 1.. MS -* slot ^comment = "Zur Referenzierung auf eine Slot-Ressource MUSS eine Reference.reference mit einer URL verwendet werden. Das Termin-Repository muss so gestaltet sein, dass es aus Perspektive des Clients nur eine Service-BaseUrl gibt." //Zur Begründung: verschiedene Referenzierungs-Arten (z.B. mit Business-Identifiern) sind ggf. nicht interoperabel +* slot ^comment = "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." * comment MS - * ^comment = "Im ISiK Kontext sollte dieses Feld zur internen Kommunikation zwischen Leistungserbringern verwendet werden, z.B. für interne Notizen rund um den Termin. + * ^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: @@ -31,49 +41,70 @@ Es gilt weiterhin die Semantik des Elements nach FHIR-Kernspezifikation: 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.'" * patientInstruction MS - * ^comment = "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. + * ^comment = "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'" -* participant 1..* MS +* participant MS * actor 1..1 MS * actor.display 1..1 MS * status 1..1 MS * ^slicing.discriminator.type = #type * ^slicing.discriminator.path = "actor.resolve()" * ^slicing.rules = #open -* participant ^comment = "Die Kardinalität von actor.display und das MS-Flag von .status wird an die Slices vererbt und diese sind entsprechend zu implementieren." +* participant ^comment = "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)." * participant contains AkteurPatient 1.. MS * participant[AkteurPatient].actor only Reference(Patient) * participant[AkteurPatient].actor MS * participant[AkteurPatient].actor.reference 1..1 MS -* participant[AkteurPatient] ^comment = "Im ISIK-Kontext MUSS der referenzierte Patient konform zum [ISIKPatient](https://gematik.de/fhir/isik/v3/Basismodul/StructureDefinition/ISiKPatient) des Basismoduls sein." +* participant[AkteurPatient] ^comment = "Hinweis: Im ISIK-Kontext MUSS der referenzierte Patient konform zum [ISIKPatient](https://gematik.de/fhir/isik/v3/Basismodul/StructureDefinition/ISiKPatient) des Basismoduls sein. + +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 ist dieses Feld verpflichtend (1..*) und muss unterstützt werden (MS)." * participant contains AkteurPersonImGesundheitsberuf 0.. MS * participant[AkteurPersonImGesundheitsberuf].actor only Reference(Practitioner) * participant[AkteurPersonImGesundheitsberuf].actor MS * participant[AkteurPersonImGesundheitsberuf].actor.reference 1..1 MS -* participant[AkteurPersonImGesundheitsberuf] ^comment = "Im ISIK-Kontext MUSS die referenzierte Practitioner-Ressource konform zum [ISiKPersonImGesundheitsberuf](https://gematik.de/fhir/isik/v3/Basismodul/StructureDefinition/ISiKPersonImGesundheitsberuf) des Basismoduls sein." +* participant[AkteurPersonImGesundheitsberuf] ^comment = "Im ISIK-Kontext MUSS die referenzierte Practitioner-Ressource konform zum [ISiKPersonImGesundheitsberuf](https://gematik.de/fhir/isik/v3/Basismodul/StructureDefinition/ISiKPersonImGesundheitsberuf) des Basismoduls sein. + +Begründung zu Kardinalität und Must Support: Die teilnehmenden Personen mit einem Gesundheitsberuf eines Termins sind entscheidend und müssen daher implementiert werden (MS), allerdings sind sie nicht zwingend erforderlich (0..*), da die Übernahme auch durch eine Behandlungseinheit erfolgen kann." * participant contains AkteurMedizinischeBehandlungseinheit 0.. MS * participant[AkteurMedizinischeBehandlungseinheit].actor only Reference(HealthcareService) * participant[AkteurMedizinischeBehandlungseinheit].actor MS * participant[AkteurMedizinischeBehandlungseinheit].actor.reference 1..1 MS -* specialty 0..* MS +* specialty MS + * ^comment = "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. + " +* specialty.coding 1..* MS * ^slicing.discriminator.type = #pattern * ^slicing.discriminator.path = "$this" * ^slicing.rules = #open -* specialty contains +* specialty.coding contains Fachrichtung 1..1 MS and ErweiterterFachabteilungsschluessel 0..1 -* specialty[Fachrichtung] from $IHEpracticeSettingVS (required) - * ^comment = "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)." -* specialty[ErweiterterFachabteilungsschluessel] from $FachabteilungsschluesselErweitertCS (required) - * ^comment = "Dieses ValueSet KANN über ein Mapping (siehe Abschnitt https://wiki.hl7.de/index.php?title=IG:Value_Sets_f%C3%BCr_XDS#DocumentEntry.practiceSettingCode) mit dem ValueSet der Fachrichtung verknüpft werden und darüber ggf. die Integration von Systemen erleichtern." +* specialty.coding[Fachrichtung] from $IHEpracticeSettingVS (required) + * ^comment = "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)." +* specialty.coding[ErweiterterFachabteilungsschluessel] from $FachabteilungsschluesselErweitertVS (required) + * ^comment = "Hinweis: Dieses ValueSet KANN über ein Mapping (siehe Abschnitt https://wiki.hl7.de/index.php?title=IG:Value_Sets_f%C3%BCr_XDS#DocumentEntry.practiceSettingCode) mit dem ValueSet der Fachrichtung verknüpft werden und darüber ggf. die Integration von Systemen erleichtern." * serviceType 1..* MS + * ^comment = "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)." * priority MS + * ^comment = "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." * priority.extension MS * priority.extension contains ISiKTerminPriorityExtension named Priority 0..1 MS + * ^comment = "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." Extension: ISiKNachrichtExtension Id: ISiKNachrichtExtension @@ -124,9 +155,9 @@ Usage: #example * priority * extension[ISiKTerminPriorityExtension].valueCodeableConcept = http://snomed.info/sct#25876001 * serviceType = http://terminology.hl7.org/CodeSystem/service-type#174 -* specialty[Fachrichtung] = $IHEAerztlicheFachrichtungen#INTM -* specialty[ErweiterterFachabteilungsschluessel] = $FachabteilungsschluesselErweitertCS#3600 +* specialty.coding[Fachrichtung] = $IHEAerztlicheFachrichtungen#INTM +* specialty.coding[ErweiterterFachabteilungsschluessel] = $FachabteilungsschluesselErweitertCS#3600 * participant * actor.display = "Test Patient" * actor.reference = "Patient/example" - * status = #accepted \ No newline at end of file + * status = #accepted diff --git a/Resources/input/fsh/ISiKTerminKontaktMitGesundheitseinrichtung.fsh b/Resources/input/fsh/ISiKTerminKontaktMitGesundheitseinrichtung.fsh index b9c626dc..024ce3d0 100644 --- a/Resources/input/fsh/ISiKTerminKontaktMitGesundheitseinrichtung.fsh +++ b/Resources/input/fsh/ISiKTerminKontaktMitGesundheitseinrichtung.fsh @@ -2,4 +2,7 @@ Profile: ISiKTerminKontaktMitGesundheitseinrichtung Parent: ISiKKontaktGesundheitseinrichtung Id: ISiKTerminKontaktMitGesundheitseinrichtung * insert Meta -* appointment MS \ No newline at end of file +* appointment MS +* appointment ^comment = "**Hinweis:** Zur Umsetzung der Funktionalität zum Dokumentenaustausch gemäß ISiK ist der entsprechende [Implementation Guide zum Modul Dokumentenaustausch](https://simplifier.net/guide/isik-dokumentenaustausch-v4?version=current) zu beachten. + + Begründung Must Support: Die Referenz auf Appointment ermöglicht Portalen den Fallbezug aus dem Termin zu ermitteln und Dokumente an ein KIS zu senden. Das Element 'appointment' ist Must-Support, um sicherzustellen, dass ein Termin immer abrufbar ist, sofern er mit einem Fallkontaktverknüft ist." \ No newline at end of file diff --git a/Resources/input/fsh/ISiKTerminblock.fsh b/Resources/input/fsh/ISiKTerminblock.fsh index 4c079b3e..319338d0 100644 --- a/Resources/input/fsh/ISiKTerminblock.fsh +++ b/Resources/input/fsh/ISiKTerminblock.fsh @@ -3,13 +3,16 @@ Parent: Slot Id: ISiKTerminblock * insert Meta * obeys ISiK-slot-1 -* schedule 1..1 MS +* schedule MS * schedule only Reference(Schedule) - * reference 1.. MS -* schedule ^comment = "Zur Referenzierung auf eine Schedule-Ressource MUSS eine Reference.reference mit einer URL verwendet werden. Das Termin-Repository muss so gestaltet sein, dass es aus Perspektive des Clients nur eine Service-BaseUrl gibt." //Zur Begründung: verschiedene Referenzierungs-Arten (z.B. mit Business-Identifiern) sind ggf. nicht interoperabel. -* status 1..1 MS -* start 1..1 MS -* end 1..1 MS + * reference 1.. MS +* schedule ^comment = "Begründung Kardinalität und MS: Die Kardinalität der reference-Eigenschaft wird auf 1..* festgelegt, um sicherzustellen, dass ein Kalender eindeutig referenziert und identifiziert werden kann." +* status MS +* status ^comment = "Begründung Must Support: Dies ist wichtig, um die Verfügbarkeit von Terminen zu gewährleisten, eine Überbuchung zu verhindern und zudem einem Termin-Requestor die Möglichkeit zu bieten nur freie Termine bei der Terminbuchung anzuzeigen." +* start MS +* start ^comment = "Begründung Must Support: Dies ist wichtig, um den Zeitpunkt des Termins an einen Termin-Requestor / Termin-Consumer zu kommunizieren." +* end MS +* end ^comment = "Begründung Must Support: Dies ist wichtig, um die Länge des Termins an einen Termin-Requestor / Termin-Consumer zu kommunizieren." Invariant: ISiK-slot-1 Description: "Der Endzeitpunkt eines Terminsblocks MUSS nach dem Startzeitpunkt liegen" @@ -22,4 +25,4 @@ Usage: #example * schedule = Reference(ISiKKalenderExample) * status = #busy * start = "2022-12-10T09:00:00Z" -* end = "2022-12-10T11:00:00Z" \ No newline at end of file +* end = "2022-12-10T11:00:00Z" diff --git a/Resources/input/fsh/aliases.fsh b/Resources/input/fsh/aliases.fsh index 6311df99..f59c9c45 100644 --- a/Resources/input/fsh/aliases.fsh +++ b/Resources/input/fsh/aliases.fsh @@ -1,4 +1,5 @@ Alias: $appointmentStatus = http://hl7.org/fhir/appointmentstatus +Alias: $sct = http://snomed.info/sct Alias: $cancelationReason = http://terminology.hl7.org/CodeSystem/appointment-cancellation-reason Alias: $authorSpecialtyVS = http://ihe-d.de/ValueSets/IHEXDSauthorSpeciality Alias: $IHEpracticeSettingVS = http://ihe-d.de/ValueSets/IHEXDSpracticeSettingCode diff --git a/Resources/input/fsh/valueSets.fsh b/Resources/input/fsh/valueSets.fsh index 5ccef6bc..0df4cdb4 100644 --- a/Resources/input/fsh/valueSets.fsh +++ b/Resources/input/fsh/valueSets.fsh @@ -12,4 +12,20 @@ ValueSet: ISiKTerminPriority Id: ISiKTerminPriority Description: "Enthaelt alle SNOMED Codes, die eine valide Priorität für den ISiKTermin sind" * insert Meta -* include codes from system SNOMED_CT where concept descendent-of #272125009 \ No newline at end of file +* $sct#709122007 "ASAP" +* $sct#441808003 "Delayed priority" +* $sct#103390000 "Elective" +* $sct#25876001 "Emergency" +* $sct#394849002 "High priority" +* $sct#88694003 "Immediate" +* $sct#1251527002 "Low priority" +* $sct#394848005 "Normal priority" +* $sct#76561005 "Reclassified" +* $sct#44408006 "Reclassified and rescheduled" +* $sct#64695001 "Repeat elective" +* $sct#21282002 "Repeat emergency" +* $sct#58334001 "Rescheduled" +* $sct#50811001 "Routine" +* $sct#416774000 "Scheduled - priority" +* $sct#49499008 "Stat" +* $sct#103391001 "Urgent" \ No newline at end of file