Merge pull request #247 from gematik/TC_4.0.2

TC_4.0.2

.github/workflows/main.yml

@@ -1,6 +1,6 @@
-name: CI (FHIR Validation)
 
-# Controls when the action will run. 
+name: Use Basis main Stufe 4 main.yml
+
 on:
   # Triggers the workflow on push or pull request events but only for the master branch
   push:
@@ -12,47 +12,15 @@ on:
     branches:
     - 'main**'
 
-  # Allows you to run this workflow manually from the Actions tab
-  workflow_dispatch:
+  # Allows you to run this workflow manually from the Actions tab      
+  workflow_dispatch: 
 
-# A workflow run is made up of one or more jobs that can run sequentially or in parallel
 jobs:
 
-  # Validate all resources using Firely Terminal 
-  CI_FHIR_VALIDATION:
-    # The type of runner that the job will run on
-    runs-on: ubuntu-latest
-
-    # Steps represent a sequence of tasks that will be executed as part of the job
-    steps:
-      - name: Checkout code (PR)
-        uses: actions/checkout@v4
-        if: github.event_name == 'pull_request'
-        with:
-          ref: ${{ github.event.pull_request.head.ref }}
-
-      - name: Checkout code (Main)
-        uses: actions/checkout@v4
-        if: github.event_name != 'pull_request'
-
-      # Java and .NET are already installed on ubuntu-latest
-
-      - name: Firely.Terminal (GitHub Actions)
-        uses: FirelyTeam/[email protected]
-        with:
-          PATH_TO_CONFORMANCE_RESOURCES: Resources/fsh-generated/resources/
-          DOTNET_VALIDATION_ENABLED: false
-          JAVA_VALIDATION_ENABLED: true
-          JAVA_VALIDATION_OPTIONS: -allow-example-urls true -advisor-file validator/advisor.json -output-style compact -show-message-ids -resolution-context file:Resources/fsh-generated/resources/
-          SIMPLIFIER_USERNAME: ${{ secrets.SIMPLIFIER_USERNAME }}
-          SIMPLIFIER_PASSWORD: ${{ secrets.SIMPLIFIER_PASSWORD }}
-          SUSHI_ENABLED: true
-          SUSHI_OPTIONS: Resources/
+  call-tool-update:
+    uses: gematik/spec-isik-basismodul/.github/workflows/main.yml@main-isik-stufe-4
+    secrets:
+      SIMPLIFIER_USERNAME: ${{ secrets.SIMPLIFIER_USERNAME }}
+      SIMPLIFIER_PASSWORD: ${{ secrets.SIMPLIFIER_PASSWORD }}
+      WORKFLOW_PERMISSION_GITHUB: ${{ secrets.WORKFLOW_PERMISSION_GITHUB }}      
 
-      - name: Add & Commit
-        uses: EndBug/add-and-commit@v9
-        with:
-          committer_name: GitHub Actions Bot
-          committer_email: [email protected]
-          add: 'Resources/fsh-generated/resources/'
-          message: auto-generated FHIR files by GitHub Actions (CI FSH to FHIR Validation)

.lycheeignore

@@ -2,4 +2,7 @@
 ^https?://test\.krankenhaus\.de
 ^http://hl7\.org/fhir/StructureDefinition/condition-related
 ^http://hl7\.org/fhir/5\.0/StructureDefinition/extension-Encounter\.plannedStartDate
-^http://hl7\.org/fhir/5\.0/StructureDefinition/extension-Encounter\.plannedEndDate
+^http://hl7\.org/fhir/5\.0/StructureDefinition/extension-Encounter\.plannedEndDate
+^https:/confluence.hl7.org/display/FHIR/Using+the+FHIR+Validator
+^https:/confluence.hl7.org/display/FHIR/Validator+Advisor+Framework
+^https:/github.com/gematik/spec-ISiK-Terminplanung/blob/main-stufe-4/.github/workflows/main.yml

ImplementationGuide/Implementierungsleitfaden_ISiKTerminplanung.json

@@ -37,39 +37,32 @@
           "generation": "markdown",
           "page": [
             {
-              "nameUrl": "ImplementationGuide/markdown/UseCases/UseCases.md",
-              "title": "Anwendungsfälle (Use Cases)",
-              "generation": "markdown"
-            }
-          ]
-        },
-        {
-          "nameUrl": "ImplementationGuide/markdown/UebergreifendeFestlegungen.md",
-          "title": "Übergreifende Festlegungen",
-          "generation": "markdown",
-          "page": [
-            {
-              "nameUrl": "ImplementationGuide/markdown/UebergreifendeFestlegungen/BestaetigungsrelevanteSysteme.md",
-              "title": "Bestätigungsrelevante Systeme",
+              "nameUrl": "ImplementationGuide/markdown/UseCases/Akteure.md",
+              "title": "Akteure",
               "generation": "markdown"
             },
             {
-              "nameUrl": "ImplementationGuide/markdown/UebergreifendeFestlegungen/Kompatibilitaet.md",
-              "title": "Kompatibilität",
+              "nameUrl": "ImplementationGuide/markdown/UseCases/Prozesse.md",
+              "title": "Prozesse und Workflows",
               "generation": "markdown"
             },
             {
-              "nameUrl": "ImplementationGuide/markdown/UebergreifendeFestlegungen/Akteure.md",
-              "title": "Akteure",
+              "nameUrl": "ImplementationGuide/markdown/UseCases/Interaktionen.md",
+              "title": "Interaktionen",
               "generation": "markdown"
             },
             {
-              "nameUrl": "ImplementationGuide/markdown/UebergreifendeFestlegungen/Interaktionen.md",
-              "title": "Interaktionen",
+              "nameUrl": "ImplementationGuide/markdown/UseCases/Kompatibilitaet.md",
+              "title": "Kompatibilität zu FHIR-Spezifikationen",
               "generation": "markdown"
             }
           ]
         },
+        {
+          "nameUrl": "ImplementationGuide/markdown/UebergreifendeFestlegungen.md",
+          "title": "Übergreifende Festlegungen",
+          "generation": "markdown"
+        },
         {
           "generation": "markdown",
           "nameUrl": "ImplementationGuide/markdown/Datenobjekte.md",

ImplementationGuide/markdown/Datenobjekte.md

@@ -5,9 +5,8 @@ Folgende Datenobjekte aus dem Modul [ISiK Basis Stufe 4](https://simplifier.net/
 * [Practitioner](https://simplifier.net/guide/isik-basis-v4/markdown-Datenobjekte-Datenobjekte_PersonImGesundheitsberuf?version=current)
 * [Binary](https://simplifier.net/guide/isik-basis-v4/ImplementationGuide-markdown-Datenobjekte-Datenobjekte_Binary?version=current)
 
-Die Verwendung in diesem Modul bedeutet:
-Wenn dieses Modul auf Datenobjekte aus dem Basismodul referenziert, dann MÜSSEN die referenzierten FHIR-Ressourcen konform zu den Vorgaben aus dem Basismodul sein. 
-Die Referenzierung von im Basismodul spezifizierten Datenobjekten, bedeutet nicht, dass die Interaktionen für die entsprechenden Datenobjekte aus dem Basismodul auch im Modul Terminplanung bestätigungsrelevant sind.
+Die Verwendung der genannten Ressourcen in diesem Modul bedeutet:
+Wenn ein Profil aus diesem Modul auf die genannten Datenobjekte aus dem Basismodul referenziert, dann MÜSSEN die referenzierten FHIR-Ressourcen im ISiK-Kontext konform zu Vorgaben an diese Ressourcen aus dem Basismodul sein (Profilkonformität). Die konkreten Vorgaben zu Interaktionen und Abhängigkeiten zwischen Modulen werden noch präzisiert.
 
 Darüber hinaus gelten in diesem Modul folgende Datenobjekt-spezifische Festlegungen:
 

ImplementationGuide/markdown/Datenobjekte/ISiKKalenderSchedule.md

@@ -10,7 +10,7 @@ Das Datenobjekt ISiKKalender bietet die Möglichkeit Kalender für verschiedene
 
 ### Kompatibilität
 
-Siehe {{pagelink:ImplementationGuide/markdown/UebergreifendeFestlegungen/Kompatibilitaet.md, text:Kompatibilität}}.
+Siehe {{pagelink:ImplementationGuide/markdown/UseCases/Kompatibilitaet.md, text:Kompatibilität}}.
 
 ---
 

ImplementationGuide/markdown/Datenobjekte/ISiKMedizinischeBehandlungseinheitHealthcareService.md

@@ -17,7 +17,7 @@ Hintergrund: Die Suche nach verfügbaren Terminenblöcken (Slot) unter Einbezieh
 
 ### Kompatibilität
 
-Siehe {{pagelink:ImplementationGuide/markdown/UebergreifendeFestlegungen/Kompatibilitaet.md, text:Kompatibilität}}.
+Siehe {{pagelink:ImplementationGuide/markdown/UseCases/Kompatibilitaet.md, text:Kompatibilität}}.
 
 ---
 

ImplementationGuide/markdown/Datenobjekte/ISiKNachrichtCommunication.md

@@ -20,7 +20,7 @@ Dieses Profil MUSS im Rahmen der Bestätigung NICHT unterstützt werden. Falls d
 
 ### Kompabilität
 
-Siehe {{pagelink:ImplementationGuide/markdown/UebergreifendeFestlegungen/Kompatibilitaet.md, text:Kompabilität}}.
+Siehe {{pagelink:ImplementationGuide/markdown/UseCases/Kompatibilitaet.md, text:Kompabilität}}.
 
 ---
 

ImplementationGuide/markdown/Datenobjekte/ISiKTerminAppointment.md

@@ -10,7 +10,7 @@ Das Datenobjekte ISiKTermin repräsentiert einen gebuchten Termin, sowie einen T
 
 ### Kompatibilität
 
-Siehe {{pagelink:ImplementationGuide/markdown/UebergreifendeFestlegungen/Kompatibilitaet.md, text:Kompatibilität}}.
+Siehe {{pagelink:ImplementationGuide/markdown/UseCases/Kompatibilitaet.md, text:Kompatibilität}}.
 
 ---
 

ImplementationGuide/markdown/Datenobjekte/ISiKTerminKontaktMitGesundheitseinrichtung.md

@@ -14,7 +14,7 @@ Hieraus folgt, dass das Datenobjekt nur relevant ist, falls das bestätigungsrel
 
 ### Kompabilität
 
-Siehe {{pagelink:ImplementationGuide/markdown/UebergreifendeFestlegungen/Kompatibilitaet.md, text:Kompabilität}}.
+Siehe {{pagelink:ImplementationGuide/markdown/UseCases/Kompatibilitaet.md, text:Kompabilität}}.
 
 ---
 

ImplementationGuide/markdown/Datenobjekte/ISiKTerminblockSlot.md

@@ -10,7 +10,7 @@ Die Slot-Ressource repräsentiert die Verbindung eines Termins (Appointment) und
 
 ### Kompabilität
 
-Siehe {{pagelink:ImplementationGuide/markdown/UebergreifendeFestlegungen/Kompatibilitaet.md, text:Kompabilität}}.
+Siehe {{pagelink:ImplementationGuide/markdown/UseCases/Kompatibilitaet.md, text:Kompabilität}}.
 
 ---
 

ImplementationGuide/markdown/Einfuehrung.md

@@ -1,9 +1,9 @@
 <img src="https://raw.githubusercontent.com/gematik/spec-ISiK-Terminplanung/main-stufe-4/Material/images/Gematik_Logo_Flag.svg" alt="gematik logo" width="400"/>
 
 ----
-Version: 4.0.1
+Version: 4.0.2
 
-Datum: 02.12.2024
+Datum: 20.02.2025
 
 Status: Active
 

ImplementationGuide/markdown/ReleaseNotes.md

@@ -4,6 +4,23 @@ 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.2
+
+Datum: 20.02.2025
+
+
+* `change` Die Verbindlichkeit des Suchaparameters `subject` in Communication wurde von SHALL auf MAY reduziert. https://github.com/gematik/spec-ISiK-Terminplanung/pull/247
+Statt dessen wird der neue verbindliche Suchparameter `patient` eingeführt. Die geschieht zur Harmonisierung der Suchparameter mit den anderen ISiK-Modulen. 
+* `improve` Falscher Satz über keine notwendige Verbindlichkeit entfernt und Formulierung verbessert https://github.com/gematik/spec-ISiK-Terminplanung/pull/248
+* `fix` Display Values ISiKTerminCancelationReason https://github.com/gematik/spec-ISiK-Terminplanung/pull/264
+* `improve` Reiter-Struktur vereinfacht https://github.com/gematik/spec-ISiK-Terminplanung/pull/266
+* `documentation` Neue Seite zur Zusammenfassung rund um Prozesse des Patient-Onboardings https://github.com/gematik/spec-ISiK-Terminplanung/pull/267
+* `fixed` Anpassung Kardinalität Appointment.start/end https://github.com/gematik/spec-ISiK-Terminplanung/pull/260
+
+
+
+---
+
 Version 4.0.1
 
 Datum: 02.12.2024

ImplementationGuide/markdown/UebergreifendeFestlegungen.md

@@ -1,12 +1,3 @@
 # Übergreifende Festlegungen
 
-Folgende Festlegungen aus dem Modul [ISiK Basis Stufe 4](https://simplifier.net/guide/isik-basis-v4/ImplementationGuide-markdown-Einfuehrung?version=current) haben in diesem Modul Gültigkeit: 
-* [Methodik der Schlüsselworte MUSS, SOLL, KANN](https://simplifier.net/guide/isik-basis-v4/markdown-UebergreifendeFestlegungen-UebergreifendeFestlegungen_Methodik?version=current)
-* [Bedeutung der Must-Support-Flags](https://simplifier.net/guide/isik-basis-v4/UebergreifendeFestlegungen-UebergreifendeFestlegungen_Must-Support-Flags?version=current)
-* [Zu implementierende Repräsentationsformate](https://simplifier.net/guide/isik-basis-v4/UebergreifendeFestlegungen_Repraesentationsformate?version=current)
-* [Allgemeine Hinweise zu Suchparametern](https://simplifier.net/guide/isik-basis-v4/UebergreifendeFestlegungen-UebergreifendeFestlegungen_Suchparameter?version=current)
-* [Allgemeine Hinweise zur REST API](https://simplifier.net/guide/isik-basis-v4/markdown-UebergreifendeFestlegungen-UebergreifendeFestlegungen_Rest?version=current)
-
-Darüber hinaus gelten in diesem Modul folgende Datenobjekt-übergreifende Festlegungen:
-
-{{index:current}}
+Es gelten die Festlegungen aus dem Modul [ISiK Basis Stufe 4](https://simplifier.net/guide/isik-basis-403/Einfuehrung?version=4.0.3).

ImplementationGuide/markdown/UseCases.md

@@ -1,6 +1,6 @@
 # Use Cases
 
-Das Modul Terminplanung umfasst alle Datenmodule die notwendig sind, um eine Abfrage für eine Behandlungsleistung inkl. anschließender Terminvereinbarung durchzuführen. 
+Das Modul Terminplanung umfasst die Datenobjekte die notwendig sind, um eine Abfrage für eine Behandlungsleistung inkl. anschließender Terminvereinbarung durchzuführen. 
 Die Terminvereinbarung ist durchführbar durch die Patientinnen und Patienten oder deren vorgelagerten Leistungserbringern.
 
 Dies umfasst:
@@ -10,3 +10,11 @@ Dies umfasst:
 - Buchungsmanagement von verfügbaren Terminen (Zusage, Absage, Temporäre Buchung, Wiederholende Termine)
 - Benachrichtigungen bei Terminänderungen
 - Anlage eines neues Patienten im KIS
+
+Darüber hinaus gelten in diesem Modul Festlegungen:
+
+{{index:current}}
+
+Eine grafische Übersicht über die Use Cases und ihre Zusammenhänge bietet folgendes Diagramm:
+
+{{render:Material/images/diagrams/patient-buchung-UseCase.png}}

ImplementationGuide/markdown/UebergreifendeFestlegungen/Akteure.md → ImplementationGuide/markdown/UseCases/Akteure.md

@@ -1,6 +1,6 @@
 ## {{page-title}}
 
-Innerhalb des ISiK Moduls Terminplanung kann ein beteiligtes System verschiedene Rollen einnehmen und somit unterschiedliche Aufgaben innerhalb der im Abschnitt {{pagelink:ImplementationGuide/markdown/UebergreifendeFestlegungen/Interaktionen.md}} definierten Arbeitsabläufe übernehmen. Im Weiteren werden diese Rollen mithilfe der Definition von Akteuren formalisiert, sodass eine Zuordnung von relevanten Interaktionen zum jeweiligen Akteur erfolgen kann.
+Innerhalb des ISiK Moduls Terminplanung kann ein beteiligtes System verschiedene Rollen einnehmen und somit unterschiedliche Aufgaben innerhalb der im Abschnitt {{pagelink:ImplementationGuide/markdown/UseCases/Interaktionen.md}} definierten Arbeitsabläufe übernehmen. Im Weiteren werden diese Rollen mithilfe der Definition von Akteuren formalisiert, sodass eine Zuordnung von relevanten Interaktionen zum jeweiligen Akteur erfolgen kann.
 
 Grundsätzlich wird als Terminblock eine für einen Termin buchbare Zeiteinheit verstanden, in der bestimmte Ressourcen (z.B. Fachabteilungen, Personen im Gesundheitswesen, Geräte, Räume) zur Verfügung stehen. Übergreifend über ein oder mehrere Terminblöcke hinweg kann für diese Ressourcen anschließend ein Termin vereinbart werden.
 

ImplementationGuide/markdown/UebergreifendeFestlegungen/Interaktionen.md → ImplementationGuide/markdown/UseCases/Interaktionen.md

@@ -3,7 +3,7 @@
 Für folgende Interaktionen werden im vorliegenden Implementierungsleitfaden Vorgaben für die Umsetzung innerhalb der ISiK-Schnittstelle definiert:
 
 
-| Akteure             | Transaktionen                                                                                                                   | Optionalität |
+| Akteure             | Transaktionen                                                                                                                   | Festlegungsstatus |
 |--------------------|-------------------------------------------------------------------------------------------------------------------------------|-------------|
 | **Termin Repository** | - Übermittlung von Patienteninformationen <br> - Verfügbare Behandlungsleistungen abrufen <br> - Verfügbare Terminlisten abrufen <br> - Abfrage von (verfügbaren) Terminblöcken <br> - Termin neu buchen (Buchungsmanagement von verfügbaren Terminen) <br> - Termin absagen (ausgehend vom Client) <br> - Termin verschieben (ausgehend vom Client) <br> - Terminzusatzinformationen aktualisieren (ausgehend vom Client) | Verplichtend           |
 | **Termin Requestor**  | - Übermittlung von Patienteninformationen <br> - Verfügbare Behandlungsleistungen abrufen <br> - Verfügbare Terminlisten abrufen <br> - Abfrage von (verfügbaren) Terminblöcken <br> - Termin neu buchen (Buchungsmanagement von verfügbaren Terminen) <br> - Termin absagen (ausgehend vom Client) <br> - Termin verschieben (ausgehend vom Client) <br> - Terminzusatzinformationen aktualisieren (ausgehend vom Client) | Optional           |

ImplementationGuide/markdown/UseCases/Prozesse.md

@@ -0,0 +1,45 @@
+# {{page-title}}
+
+<img src="https://raw.githubusercontent.com/gematik/spec-ISiK-Terminplanung/c604c61a3887bd5532d2c7392eb20d8c79403028/Material/images/piktogramme/Betriebskoordination_Gruen_gematik.svg" width="40"/>
+
+**Diskussion**: Dieser Abschnitt fasst einen Diskussionsstand mit beteiligten Stakeholdern zusammen und enthält keine normativen Festlegungen.
+<img src="https://raw.githubusercontent.com/gematik/spec-ISiK-Terminplanung/c604c61a3887bd5532d2c7392eb20d8c79403028/Material/images/piktogramme/Betriebskoordination_Gruen_gematik.svg" width="40"/>
+
+
+Ein Terminbuchungsprozess in einem Krankenhaus kann sowohl automatisierte als auch manuelle Zwischenschritte umfassen, um eine nahtlose Terminbuchung und Terminwahrnehmung für Patienten zu gewährleisten. Hier finden sich Skizzen zu entsprechenden Prozessen.
+
+
+## Allgemeiner Prozess (Übersicht)
+
+Ein grobes Prozessmodell gewährt eine Übersicht zu drei möglichen Sub-Prozessen der Terminbuchung:
+
+{{render:Material/images/diagrams/process-allgemein-bpmn.png}}
+
+## Registrierung und Terminbuchung (happy path)
+
+Folgendes BPMN-Diagramm gibt eine Übersicht zu einer Terminbuchung durch einen User mittels Patientenportal:
+
+{{render:Material/images/diagrams/buchung-termin-portal.drawio.png}}
+
+Folgendes Sequenzdiagramm detailliert den Ablauf unter Berücksichtigung der Akteure Termin Requestor (z.B. Patientenportal) und Termin Repository (z.B. KIS); 
+offen bleibt hier allerdings noch der Ablauf zum Austausch von Patientendaten zwischen den Systemen:
+
+{{render:Material/images/diagrams/patient-buchung-sequenz.png}}
+
+Einzelne Interaktionen, die in diesem Sequenzdiagramm skizziert werden und für die der vorliegende Implementierungsleitfaden spezifischere Festlegungen trifft, sind unter {{pagelink:ImplementationGuide/markdown/UseCases/Interaktionen.md, text:Interaktionen}} gelistet.
+
+
+## Identitätsnachweis der Patienten
+
+Insbesondere zur nahtlosen Integration von Prozessen über verschiedene Systeme (z.B. Patientenportal und KIS), die sich in gekapselten Zugriffsumgebungen befinden, sind Workflows zum Identitätsnachweis von Patienten unabdinglich.
+
+Folgende Alternativen zur Erbringung eines Identitätsnachweises können schematisch angeführt werden:
+
+{{render:Material/images/diagrams/identitaetsnachweis-bpmn.png}}
+
+Insbesondere für die Verifizierung des Patienten im Laufe der Registrierung im Patientenportal soll hier ein Workflow vorgestellt werden, der einem künftigen Happy Path zur Terminbuchung samt Datenaustausch über eine validierte Patienten-Identität und zugehöriger Daten (in Portal und KIS) entspricht. 
+Der Nachweis-Workflow soll die Übernahme validierter Patienten-Identitäten unter der Annahme von Read-Only Operationen (GET) zwischen den daten-führenden Systemen zur Übernahme sowie vorgelagerter Identifizierung eines Patienten mittels IDP (z.B. mittels GesundheitsID) skizzieren:
+
+{{render:Material/images/diagrams/identitaetsnachweis-sequenz.png}}
+
+Die Abfragen von Patientendaten gegenüber dem Basis-Server dienen anknüpfenden Workflows (z.B. zur Bereitstellung von Dokumenten, Vitaldaten etc.). Das Zugriffsmanagement bleibt bei dieser Skizze jedoch noch offen.