diff --git a/.github/workflows/ig-publisher.yml b/.github/workflows/ig-publisher.yml
index c1d1f7bf00..205534519f 100644
--- a/.github/workflows/ig-publisher.yml
+++ b/.github/workflows/ig-publisher.yml
@@ -23,17 +23,25 @@ jobs:
       image: ghcr.io/gefyra/ig-publisher-with-snapshot-support:latest
     env:
       SUSHI_INPUT_DIR: Resources
-      IG_PUBLISHER_DIR: publisher-guides/Basis-5
+      IG_PUBLISHER_DIR: publisher-guides/Terminplanung-5
 
     steps:
       - name: Checkout
         uses: actions/checkout@v4
 
+      - name: Fix Git Safe Directory
+        run: git config --global --add safe.directory '*'
+
       # Download dependencies via FHIR Package Tool using sushi-config.yaml from Resources
       - name: Download Dependencies
         run: |
           fhir-pkg-tool --sushi-deps-file ${{ env.SUSHI_INPUT_DIR }}/sushi-config.yaml
 
+      # Run SUSHI on Publisher Markdown directory to create menu.xml and json IG file
+      - name: Run SUSHI for menu
+        run: |
+          sushi ${{ env.IG_PUBLISHER_DIR }}
+
       # Run SUSHI (FSH -> FHIR conversion) on Resources directory
       - name: Run SUSHI
         run: |
@@ -45,7 +53,7 @@ jobs:
         with:
           input_directory: ${{ env.SUSHI_INPUT_DIR }}/fsh-generated
           output_directory: ${{ env.IG_PUBLISHER_DIR }}/input/resources
-          capability_statement_url: 'https://gematik.de/fhir/isik/CapabilityStatement/ISiKCapabilityStatementBasisServerAkteur'
+          capability_statement_url: 'https://gematik.de/fhir/isik/CapabilityStatement/ISiKCapabilityStatementTerminRepositoryAkteur'
       
       # Run the HL7 FHIR IG Publisher
       - name: Build IG
diff --git a/publisher-guides/Terminplanung-5/fsh-generated/includes/fsh-link-references.md b/publisher-guides/Terminplanung-5/fsh-generated/includes/fsh-link-references.md
new file mode 100644
index 0000000000..86b1623ea1
--- /dev/null
+++ b/publisher-guides/Terminplanung-5/fsh-generated/includes/fsh-link-references.md
@@ -0,0 +1 @@
+[TestImplementationGuide]: ImplementationGuide-terminplanung.test.ig.html
\ No newline at end of file
diff --git a/publisher-guides/Terminplanung-5/fsh-generated/includes/menu.xml b/publisher-guides/Terminplanung-5/fsh-generated/includes/menu.xml
new file mode 100644
index 0000000000..fdc54fde00
--- /dev/null
+++ b/publisher-guides/Terminplanung-5/fsh-generated/includes/menu.xml
@@ -0,0 +1,85 @@
+<!-- menu.xml {% comment %}
+*****************************************************************************************************
+*                                  WARNING: DO NOT EDIT THIS FILE                                   *
+*                                                                                                   *
+* This file is generated by SUSHI. Any edits you make to this file will be overwritten.             *
+*                                                                                                   *
+* To change the contents of this file, edit the "menu" attribute in the tank sushi-config.yaml file *
+* or provide your own menu.xml in the input\includes folder                                         *
+*****************************************************************************************************
+{% endcomment %} -->
+
+<ul xmlns="http://www.w3.org/1999/xhtml" class="nav navbar-nav">
+  <li>
+    <a href="index.html">Index</a>
+  </li>
+  <li>
+    <a href="Motivation.html">Motivation</a>
+  </li>
+  <li>
+    <a href="ReleaseNotes.html">Release Notes</a>
+  </li>
+  <li class="dropdown">
+    <a data-toggle="dropdown" href="#" class="dropdown-toggle">UseCases
+      <b class="caret"></b>
+    </a>
+    <ul class="dropdown-menu">
+      <li>
+        <a href="UseCases.html">UseCases</a>
+      </li>
+      <li>
+        <a href="Akteure.html">Akteure</a>
+      </li>
+      <li>
+        <a href="Interaktionen.html">Interaktionen</a>
+      </li>
+      <li>
+        <a href="Kompatibilitaet.html">Kompatibilität</a>
+      </li>
+      <li>
+        <a href="Prozesse.html">Prozesse</a>
+      </li>
+      <li>
+        <a href="Informationsmodell.html">Informationsmodell</a>
+      </li>
+      <li>
+        <a href="Architekturoptionen.html">Architekturoptionen</a>
+      </li>
+    </ul>
+  </li>
+  <li class="dropdown">
+    <a data-toggle="dropdown" href="#" class="dropdown-toggle">Festlegungen
+      <b class="caret"></b>
+    </a>
+    <ul class="dropdown-menu">
+      <li>
+        <a href="Festlegungen.html">Festlegungen</a>
+      </li>
+      <li>
+        <a href="UebergreifendeFestlegungen.html">Übergreifende Festlegungen</a>
+      </li>
+      <li>
+        <a href="Operations.html">Operation $book</a>
+      </li>
+    </ul>
+  </li>
+  <li class="dropdown">
+    <a data-toggle="dropdown" href="#" class="dropdown-toggle">FHIR-Artefakte
+      <b class="caret"></b>
+    </a>
+    <ul class="dropdown-menu">
+      <li>
+        <a href="artifacts.html">Artefakte</a>
+      </li>
+      <li>
+        <a href="capabilitystatements.html">CapabilityStatements</a>
+      </li>
+      <li>
+        <a href="profiles.html">Profile</a>
+      </li>
+      <li>
+        <a href="terminology.html">Terminology</a>
+      </li>
+    </ul>
+  </li>
+</ul>
\ No newline at end of file
diff --git a/publisher-guides/Terminplanung-5/fsh-generated/resources/ImplementationGuide-terminplanung.test.ig.json b/publisher-guides/Terminplanung-5/fsh-generated/resources/ImplementationGuide-terminplanung.test.ig.json
new file mode 100644
index 0000000000..7d29a137d0
--- /dev/null
+++ b/publisher-guides/Terminplanung-5/fsh-generated/resources/ImplementationGuide-terminplanung.test.ig.json
@@ -0,0 +1,163 @@
+{
+  "resourceType": "ImplementationGuide",
+  "id": "terminplanung.test.ig",
+  "url": "http://example.org/fhir/test-terminplanung-ig/ImplementationGuide/terminplanung.test.ig",
+  "version": "0.0.1",
+  "name": "TestImplementationGuide",
+  "title": "Test Implementation Guide",
+  "status": "draft",
+  "description": "A test implementation guide for validating the local FHIR IG Publisher environment",
+  "packageId": "terminplanung.test.ig",
+  "license": "CC0-1.0",
+  "fhirVersion": [
+    "4.0.1"
+  ],
+  "dependsOn": [
+    {
+      "packageId": "hl7.fhir.uv.ips",
+      "version": "1.1.0",
+      "uri": "http://hl7.org/fhir/uv/ips/ImplementationGuide/hl7.fhir.uv.ips",
+      "id": "hl7_fhir_uv_ips"
+    },
+    {
+      "packageId": "hl7.fhir.uv.subscriptions-backport.r4",
+      "version": "1.1.0",
+      "uri": "http://hl7.org/fhir/uv/subscriptions-backport/ImplementationGuide/hl7.fhir.uv.subscriptions-backport",
+      "id": "hl7_fhir_uv_subscriptions_backport_r4"
+    },
+    {
+      "packageId": "de.basisprofil.r4",
+      "version": "1.5.4",
+      "uri": "http://fhir.org/packages/de.basisprofil.r4/ImplementationGuide/de.basisprofil.r4",
+      "id": "de_basisprofil_r4"
+    },
+    {
+      "packageId": "de.ihe-d.terminology",
+      "version": "3.0.1",
+      "uri": "http://fhir.de/packages/de.ihe-d.terminology",
+      "id": "de_ihe_d_terminology"
+    },
+    {
+      "packageId": "dvmd.kdl.r4",
+      "version": "2025.0.1",
+      "uri": "http://fhir.org/packages/dvmd.kdl.r4/ImplementationGuide/dvmd.kdl.r4",
+      "id": "dvmd_kdl_r4"
+    },
+    {
+      "packageId": "ihe.formatcode.fhir",
+      "version": "1.4.0",
+      "uri": "https://profiles.ihe.net/fhir/ihe.formatcode.fhir/ImplementationGuide/ihe.formatcode.fhir",
+      "id": "ihe_formatcode_fhir"
+    },
+    {
+      "packageId": "hl7.fhir.uv.sdc",
+      "version": "3.0.0",
+      "uri": "http://hl7.org/fhir/uv/sdc/ImplementationGuide/hl7.fhir.uv.sdc",
+      "id": "hl7_fhir_uv_sdc"
+    },
+    {
+      "packageId": "de.gematik.terminology",
+      "version": "1.0.6",
+      "uri": "https://gematik.de/fhir/terminology/ImplementationGuide/de.gematik.terminology",
+      "id": "de_gematik_terminology"
+    }
+  ],
+  "definition": {
+    "resource": [
+      {
+        "reference": {
+          "reference": "ImplementationGuide/terminplanung.test.ig"
+        },
+        "description": "A test implementation guide for validating the local FHIR IG Publisher environment",
+        "exampleBoolean": false,
+        "name": "Test Implementation Guide"
+      }
+    ],
+    "page": {
+      "nameUrl": "toc.html",
+      "title": "Table of Contents",
+      "generation": "html",
+      "page": [
+        {
+          "nameUrl": "index.html",
+          "title": "Index",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "Motivation.html",
+          "title": "Motivation",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "ReleaseNotes.html",
+          "title": "Release Notes",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "UseCases.html",
+          "title": "UseCases",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "Akteure.html",
+          "title": "Akteure",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "Interaktionen.html",
+          "title": "Interaktionen",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "Kompatibilitaet.html",
+          "title": "Kompatibilität",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "Prozesse.html",
+          "title": "Prozesse",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "Informationsmodell.html",
+          "title": "Informationsmodell",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "Architekturoptionen.html",
+          "title": "Architekturoptionen",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "Festlegungen.html",
+          "title": "Festlegungen",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "UebergreifendeFestlegungen.html",
+          "title": "Übergreifende Festlegungen",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "Operations.html",
+          "title": "Operation: $book",
+          "generation": "markdown"
+        }
+      ]
+    },
+    "parameter": [
+      {
+        "code": "copyrightyear",
+        "value": "2025+"
+      },
+      {
+        "code": "releaselabel",
+        "value": "STU1"
+      },
+      {
+        "code": "no-validate",
+        "value": "true"
+      }
+    ]
+  }
+}
diff --git a/publisher-guides/Terminplanung-5/ig.ini b/publisher-guides/Terminplanung-5/ig.ini
new file mode 100644
index 0000000000..792f2a1828
--- /dev/null
+++ b/publisher-guides/Terminplanung-5/ig.ini
@@ -0,0 +1,4 @@
+[IG]
+ig = input/resources/ImplementationGuide-example.test.ig.json
+template = https://github.com/gematik/fhir-ig-template
+auto-load = true
\ No newline at end of file
diff --git a/publisher-guides/Terminplanung-5/input/pagecontent/Akteure.md b/publisher-guides/Terminplanung-5/input/pagecontent/Akteure.md
new file mode 100644
index 0000000000..333a1cc0fa
--- /dev/null
+++ b/publisher-guides/Terminplanung-5/input/pagecontent/Akteure.md
@@ -0,0 +1,51 @@
+---
+topic: Akteure
+---
+
+
+## {{page-title}}
+
+Innerhalb des ISiK Moduls Terminplanung kann ein beteiligtes System verschiedene Rollen einnehmen und somit unterschiedliche Aufgaben innerhalb der im Abschnitt {{pagelink:Interaktionen}} 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.
+
+Allein für den Akteur Termin-Repository gelten normative Festlegungen für die Implementierung einer Schnittstelle.
+
+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.
+
+### Termin-Repository
+
+**Definition:**
+
+Als Termin-Repository werden alle Systeme definiert, die Informationen zu verfügbaren Termineinheiten von Ressourcen (vgl. zuvor genannte Definition) vorhalten und die dafür vereinbarten Termine als führendes System verwalten. In diesem Sinne ist ein Termin-Repository als ein zentraler Terminplanungs-Server zu verstehen.
+
+Das Termin-Repository kann intern in ein Repository für die Termine und ein separates Repository für die buchbaren Terminblöcke (Terminblock Repository) geteilt werden.
+
+**Beispielsysteme:**
+
+* Patientenportal im Falle, dass das System selbst terminführend ist
+* KIS / KAS inkl. Terminverwaltung 
+
+**Festlegungen'**
+In diesem Modul gilt für den Akteur Termin-Repository das entsprechende {{pagelink:ISiKCapabilityStatementTerminRepositoryAkteur, text=Capability Statement}}.
+
+### Termin-Requestor / Termin Source
+
+**Definition:**
+
+Als Termin-Requestor (in Anlehnung an die IHE Terminologie auch als Termin Source zu bezeichnen) werden alle Systeme definiert, die zur Erhebung, Erfassung, Anpassung oder Veränderung von Termininformationen dienen. Ein Termin-Requestor verfügt über keine permanente Persistierung der verarbeiteten Informationen. Der Termin-Requestor übernimmt die Koordination der Schnittstellenaufrufe, um einen Termin zu buchen. 
+
+**Beispielsysteme:**
+
+* Patientenportal im Falle, dass ein externes System das terminführende System ist
+
+### Termin-Consumer
+
+**Definition:**
+
+Als Termin-Consumer werden alle System definiert, die Termininformationen abfragen, um diese einem Benutzer zu präsentieren. Ein Termin-Consumer verfügt über keine permanente Persistierung der abgefragten Informationen. Durch den Termin-Consumer erfolgt explizit nur die Aufbereitung und Präsentation der Termininformationen. Eine anderweitige Verarbeitung der Termininformationen fällt in die Kategorie der anderen Akteure.
+
+**Beispielsysteme:**
+
+* Apps zum Anzeigen eines Kalenders
+* Backendsysteme zum Versenden von Benachrichtigungen im Kontext eines Termins
+* Ressourcenmanagementsoftware
+
diff --git a/publisher-guides/Terminplanung-5/input/pagecontent/Architekturoptionen.md b/publisher-guides/Terminplanung-5/input/pagecontent/Architekturoptionen.md
new file mode 100644
index 0000000000..20866a99bb
--- /dev/null
+++ b/publisher-guides/Terminplanung-5/input/pagecontent/Architekturoptionen.md
@@ -0,0 +1,19 @@
+---
+topic: Architekturoptionen
+---
+
+## {{page-title}}
+
+Im folgenden werden beispielhafte mögliche Architekturen dargestellt, die das Zusammenspiel von Systemen im Kontext der Terminplanung darstellen.
+
+### KIS als terminführendes System
+
+Eine in der Praxis vermutlich häufig vorkommende Architektur sieht das KIS als terminführendes System, im Sinne des IGs ist es somit das Termin-Repository. Darüber hinaus existiert ein Patientenportal, über das Patienten online Termine buchen können. Das Patientenportal ist somit zugleich Termin-Requestor und Termin-Consumer.
+
+<img src="https://raw.githubusercontent.com/gematik/spec-ISiK-Basismodul/refs/heads/archive-stable-pics-etc/Material/Terminplanung/Termin_KIS_als_Repository.drawio.svg"/>
+
+### Patientenportal als Terminführendes System
+
+Eine andere Variante ist das Patientenportal als terminführendes System einzubinden. In dieser Variente ist das KIS weiterhin auch als Repository zu betrachten, da Kapazitäten der Leistungserbringer hier vorgehalten werden. Das Patientenportal erhält jedoch weitergehende Rechte und kann hierdurch direkt Termine buchen. Eine bidirektionale Synchronisierung des Patientenportals und des KIS muss fortlaufend durchgeführt werden. 
+
+<img src="https://raw.githubusercontent.com/gematik/spec-ISiK-Basismodul/refs/heads/archive-stable-pics-etc/Material/Terminplanung/Termin_Patientenportal_als_Repository.drawio.svg"/>
diff --git a/publisher-guides/Terminplanung-5/input/pagecontent/Festlegungen.md b/publisher-guides/Terminplanung-5/input/pagecontent/Festlegungen.md
new file mode 100644
index 0000000000..a6b7fdf340
--- /dev/null
+++ b/publisher-guides/Terminplanung-5/input/pagecontent/Festlegungen.md
@@ -0,0 +1,3 @@
+## {{page-title}}
+
+{{index:current}}
diff --git a/publisher-guides/Terminplanung-5/input/pagecontent/Informationsmodell.md b/publisher-guides/Terminplanung-5/input/pagecontent/Informationsmodell.md
new file mode 100644
index 0000000000..cf947e0af6
--- /dev/null
+++ b/publisher-guides/Terminplanung-5/input/pagecontent/Informationsmodell.md
@@ -0,0 +1,6 @@
+## Informationsmodell
+
+**Vereinfachtes Informationsmodell**
+
+
+<img src="https://raw.githubusercontent.com/gematik/spec-ISiK-Basismodul/refs/heads/main-stufe-5/Material/Terminplanung/ISiK_Terminplanung_ER_Diagram.svg" width="90%"/>
diff --git a/publisher-guides/Terminplanung-5/input/pagecontent/Interaktionen.md b/publisher-guides/Terminplanung-5/input/pagecontent/Interaktionen.md
new file mode 100644
index 0000000000..2eb6b14df6
--- /dev/null
+++ b/publisher-guides/Terminplanung-5/input/pagecontent/Interaktionen.md
@@ -0,0 +1,109 @@
+---
+topic: Interaktionen
+---
+
+## {{page-title}}
+
+Für folgende Interaktionen werden im vorliegenden Implementierungsleitfaden Vorgaben für die Umsetzung innerhalb der ISiK-Schnittstelle definiert:
+
+
+| 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           |
+| **Termin-Consumer**   | - Abfrage von (vereinbarten) Terminen                                                                                      | Optional           |
+
+Zudem kann die Situation eintreten, dass ein System die Aufgaben eines Termin Repositories übernimmt, jedoch kein terminführendes System ist (z. B. ein Patientenportal) und die Termine mit einem weiteren Termin-Repository synchronisiert (z. B. KIS). In diesem Fall übernimmt das System, welches Termine an das terminführende System sendet, die Rolle eines Termin-Requestors. Diese Option steht einem Termin-Repository offen, falls es für bestimmte Use Cases notwendig ist; jedoch ist dies nicht verpflichtend für die Rolle des Termin Repositories.
+
+---
+
+{{render:Material/Terminplanung/images/Interaktionen/1. Übermittelung Patienteninformationen - zum Termin zugehörige Vorabinformationen.png}}
+
+Für die Auswahl eines verfügbaren Terminblocks kann es notwendig sein, dass das Termin-Repository vorab durch den Termin-Requestor Vorabinformationen (z.B. für die Krankenversicherung) erhält. Diese können über eine schreibende Schnittstelle an das Termin-Repository übermittelt werden. Es ist zu beachten, dass das Termin-Repository gegebenenfalls diese Informationen separat von eigens erstellten Datenobjekten vorhält und/oder die Information dauerhaft erst nach einer manuellen Überprüfung durch einen Benutzer freigibt.
+
+Gleichermaßen können Informationen zum Patienten vorab übermittelt werden, sodass gewisse Basisangaben bereits im Terminrepository vorliegen.
+
+Siehe {{pagelink:guides/Terminplanung-5/Einfuehrung/Festlegungen/Operations.page.md, text:Anlage einer Patient-Ressource}} für die technische Umsetzung.
+
+---
+
+{{render:Material/Terminplanung/images/Interaktionen/2. Verfügbare Behandlungsleistungen abrufen.png}}
+
+Als Einstiegspunkt in die Terminvereinbarung können durch den Termin Requestor alle verfügbaren Behandlungsleistungen (HealthcareServices) abgerufen werden, für die das Termin-Repository Informationen zu notwendigen Ressourcen (Räume, Personen, Geräte, etc.) bereitstellt.
+
+Siehe {{pagelink:guides/Terminplanung-5/Einfuehrung/Artefakte/Datenobjekt_MedizinischeBehandlungseinheit/Interaktionen.page.md, text: ISiKMedizinischeBehandlungseinheit (HealthcareService) - Interaktionen}} für die technische Umsetzung. Es sind die Hinweise zum Abruf der ValueSets für die Kodierung der Medizinischen Behandlungseinheit zu beachten.
+
+---
+
+{{render:Material/Terminplanung/images/Interaktionen/3. Verfügbare Terminlisten abrufen.png}}
+
+Der Termin-Requestor kann nach der Auswahl einer Behandlungsleistung verfügbare Terminlisten (Schedules) für diese im Termin-Repository abrufen. Die Terminlisten repräsentieren somit den "Kalender", in dem Termine gebucht werden können.
+
+Siehe {{pagelink: guides/Terminplanung-5/Einfuehrung/Artefakte/Datenobjekt_Kalender/Interaktionen.page.md, text: ISiKKalender (Schedule) - Interaktionen}} für die technische Umsetzung.
+
+---
+
+{{render:Material/Terminplanung/images/Interaktionen/4. Abfrage von (verfübaren) Terminblöcken.png}}
+
+Für einen jeweiligen Kalender kann der Termin-Requestor die darin definierten Terminblöcke abfragen. Diese können entsprechend eines Zeitraums und/oder Status (verfügbar, belegt) gefiltert werden.
+
+Siehe {{pagelink:guides/Terminplanung-5/Einfuehrung/Artefakte/Datenobjekt_Terminblock/Interaktionen.page.md, text: ISiKTerminblock (Slot) - Interaktionen}} für die technische Umsetzung.
+
+---
+
+{{render:Material/Terminplanung/images/Interaktionen/5. Termin neu buchen - Buchungsmanagemnent von verfügbaren Terminen.png}}
+
+Für einen durch den Benutzer ausgewählten Terminblock bzw. mehreren aufeinander folgenden Terminblöcken kann durch den Termin-Requestor ein Termin angefragt werden. Dieser kann direkt oder erst nach manueller Bestätigung durch das Termin-Repository freigegeben werden.
+
+Es ist zu beachten, dass innerhalb dieser Aktion ein terminführendes Termin-Repository die Rolle des Termin-Requestors übernehmen kann und den neu-angelegten Termin in ein weiteres Terminrepository spiegelt.
+
+In diesem Kontext kann das Termin-Repsoitory zudem Zusatzinformationen (z.B. Lagepläne) an den Termin-Requestor übermitteln.
+
+Die Buchung eines Termins kann auch eine Aktualisierung eines Termins darstellen, indem für einen bestehenden Termin ein oder mehrere neu ausgewählte Terminblöcke an das Terminrepository übergeben werden.
+
+Siehe {{pagelink:guides/Terminplanung-5/Einfuehrung/Festlegungen/Operations.page.md, text:Buchung eines Termins}} für die technische Umsetzung.
+
+---
+
+{{render:Material/Terminplanung/images/Interaktionen/6.1 Termin absagen (ausgehend vom Client).png}}
+
+
+{{render:Material/Terminplanung/images/Interaktionen/6.2 Termin absagen (ausgehend vom terminführenden System).png}}
+
+Termine können sowohl durch den Termin-Requestor als Client oder durch das Termin-Repository als terminführendes System abgesagt werden.
+
+Siehe {{pagelink:guides/Terminplanung-5/Einfuehrung/Festlegungen/Operations.page.md, text:Aktualisierung / Absage eines Termins}} für die technische Umsetzung.
+
+---
+
+Eine Verschiebeoperation kann im Normalfall als eine Neubuchung mit geändertem Zeitfenster ausgeführt werden (siehe Interaktion 5, bzw. {{pagelink:guides/Terminplanung-5/Einfuehrung/Festlegungen/Operations.page.md, text:Aktualisierung / Absage eines Termins}} für die technische Umsetzung.)
+
+Bei einer Verschiebung kann allerdings auch eine Absage und Neubuchung eines Termins notwendig werden, wenn ursprüngliche Ressourcen nicht mehr verfügbar sind für den neu zu belegenden Slot:
+
+{{render:Material/Terminplanung/images/Interaktionen/7.1 Termin verschieben (ausgehend vom Client).png}}
+
+{{render:Material/Terminplanung/images/Interaktionen/7.2 Termin verschieben (ausgehend vom Termin Repository).png}}
+
+Termine können sowohl durch den Termin-Requestor als Client oder durch das Termin-Repository als terminführendes System verschoben werden. Im Falle, dass das Termin-Repository den Termin verschiebt ist der Termin-Consumer darüber zu benachrichtigen.
+
+Siehe {{pagelink:guides/Terminplanung-5/Einfuehrung/Festlegungen/Operations.page.md, text:Buchung eines Termins}} für die technische Umsetzung.
+
+---
+
+{{render:Material/Terminplanung/images/Interaktionen/8.1 Terminzusatzinformationen aktualisieren (ausgehend vom Client).png}}
+
+{{render:Material/Terminplanung/images/Interaktionen/8.2 Terminzusatzinformationen aktualisieren (ausgehend vom Termin Repository).png}}
+
+Termine können sowohl durch den Termin-Requestor als Client oder durch das Termin-Repository als terminführendes System durch Zusatzinformationen (z.B. welche Teilnehmer oder Ressourcen sind Teil des Termins) erweitert werden.
+
+In diesem Kontext kann der Termin-Requestor zudem Zusatzinformationen (z.B. Einwilligungen) an das Termin-Repository übermitteln.
+
+Siehe {{pagelink:guides/Terminplanung-5/Einfuehrung/Festlegungen/Operations.page.md, text:Aktualisierung / Absage eines Termins}} für die technische Umsetzung.
+
+---
+
+{{render:Material/Terminplanung/images/Interaktionen/9. Abfrage von (verinbarten) Terminen.png}}
+
+Der Termin-Requestor oder Termin-Consumer kann einen, mehrere oder alle Termine eines Termin Repositories abfragen.
+
+Siehe {{pagelink:guides/Terminplanung-5/Einfuehrung/Artefakte/Datenobjekt_Termin/Interaktionen.page.md, text: ISiKTermin (Appointment) - Interaktionen}} für die technische Umsetzung.
diff --git a/publisher-guides/Terminplanung-5/input/pagecontent/Kompatibilitaet.md b/publisher-guides/Terminplanung-5/input/pagecontent/Kompatibilitaet.md
new file mode 100644
index 0000000000..5a857e36be
--- /dev/null
+++ b/publisher-guides/Terminplanung-5/input/pagecontent/Kompatibilitaet.md
@@ -0,0 +1,20 @@
+---
+topic: Kompatibilitaet
+---
+
+## Kompatibilität zu anderen nationalen FHIR-basierten Spezifikationen
+
+Die vorliegende Spezifikation orientiert sich teilweise an bereits vorhandenen (internationalen) FHIR-Projekten zum Thema Terminvergabe. Hier sei vorallem das [Argonaut Scheduling Project](https://fhir.org/guides/argonaut/scheduling/) hervorgehoben.
+
+## Kompatibilität zum KBV eTerminService
+
+Bei folgenden FHIR-Ressourcen wurde zum Zeitpunkt der Erstveröffentlichung eine inhaltliche Überschneidung mit dem [eTerminService der KBV](https://simplifier.net/eTerminservice-R4/~introduction) erreicht, die auch weiter angestrebt wird. Erforderliche Maßnahmen zur Kompatibilitätswahrung sind:
+
+* [Patient](https://simplifier.net/eterminservice-r4/patientets) - Die Validität der ISiK "Patient"-Instanz gegen das entsprechende KBV ETS Profil, kann erreicht werden, wenn zumindest:
+  * Elemente, die auf eine Kardinalität von 0..0 beschränkt sind, entfernt werden
+
+* [Appointment](https://simplifier.net/eterminservice-r4/appointmentets-duplicate-2) - Die Validität von ISiK "Appointment"-Instanz gegen das entsprechende KBV ETS Profil, kann erreicht werden, wenn zumindest:
+  * Elemente, die auf eine Kardinalität von 0..0 beschränkt sind, entfernt werden
+  * Eine PractitionerRole Referenz als Akteur angegeben wird
+
+Aufgrund von fachlichen Unterschieden in den zu unterstützenden Arbeitsabläufen sind die OperationDefinitions für die Buchung eines Termins nicht vergleichbar.
\ No newline at end of file
diff --git a/publisher-guides/Terminplanung-5/input/pagecontent/Operations.md b/publisher-guides/Terminplanung-5/input/pagecontent/Operations.md
new file mode 100644
index 0000000000..687f8f74d9
--- /dev/null
+++ b/publisher-guides/Terminplanung-5/input/pagecontent/Operations.md
@@ -0,0 +1,272 @@
+---
+topic: ISiKAppointmentBookOperation
+canonical: https://gematik.de/fhir/isik/OperationDefinition/AppointmentBook
+---
+
+# Operations
+
+Es gelten die allgemeinen Vorgaben der FHIR-Kernspezifikation für die Ausführung von [Custom Operations](https://www.hl7.org/fhir/R4/operations.html).
+
+---
+
+### Buchung eines Termins
+
+{{render:ISiKAppointmentBookOperation}}
+
+### Übersicht Interaktion Termin-Requestor mit Termin-Repository
+
+Folgende Schritte KÖNNEN notwendig sein, sodass ein Termin durch einen Termin-Requestor innerhalb eines Termin-Repository eingestellt wird. Es ist zu beachten, dass für spezielle Implementierungen nicht alle Schritte hiervon relevant sind und übersprungen werden können.
+
+Generell wird darauf hingewiesen, dass abhängig davon, welcher Client oder Benutzer eine Interaktion ausführt, unterschiedliche Ergebnisse zurückgeliefert werden können. Die vorliegende Spezifikation macht keine Vorgaben, wie eine Authentifizierung und Autorisierung zu implementieren ist. Es wird hierzu auf das [ISiK-Modul 'Connect'](https://simplifier.net/guide/isik-connect-stufe-5) verwiesen.
+
+User Story für die folgenden Beispiele: Ein Patient bucht über ein externes Patientenportal einen Termin in der allgemeinmedizinischen Ambulanz eines Krankenhauses. Da der Patient seit Tagen Bauchschmerzen hat, die in den letzten Stunden stärker werden, wählt er die Priorität "Notfall".
+
+1. Abfrage aller Kodierungen der angebotenen gesundheitlichen Dienstleistungen durch den Termin-Requestor: `GET https://example.org/fhir/CodeSystem?context-type-value=https://gematik.de/fhir/isik/CodeSystem/ContextType|ResourceUsage$http://hl7.org/fhir/resource-types|HealthcareService` bzw. `GET https://example.org/fhir/CodeSystem?context-type-value=https://gematik.de/fhir/isik/CodeSystem/ContextType|ResourceUsage$http://hl7.org/fhir/resource-types|Schedule`
+
+Das Termin-Repository MUSS alle CodeSysteme exponieren, welche für die Kodierung einer verfügbaren gesundheitlichen Dienstleistungen relevant sind. Die Anfrage ist nicht auf HealthcareService beschränkt. Weitere Ressourcen-Kontexte können hierfür relevant sein. Beispielsweise erfolgt die Kodierung der Leistungen für einen Behandler im Kontext eines Schedules (vgl. {{pagelink:guides/Terminplanung-5/Einfuehrung/Artefakte/Datenobjekt_Kalender/Profil.page.md, text:Schedule.serviceType}}). Alle verwendeten CodeSysteme MÜSSEN exponiert werden, insoweit diese sich als CodeSystem-Ressourcen ausdrücken lassen.
+
+Hinweis: Diese Abfrage ist für eine Initialisierung des Termin-Requestors gedacht. Es ist davon auszugehen, dass diese Auswahlliste nicht dynamisch angepasst wird durch das Termin-Repository und nicht bei jeder Terminbuchung erneut abgefragt werden muss.
+
+2. Abfrage aller verfügbaren Kalender durch den Termin-Requestor: `GET https://example.org/fhir/Schedule` bzw. `GET https://example.org/fhir/Schedule?actor=Practitioner/ISiKPractitionerExample`
+
+Der Termin-Requestor KANN durch die Abfrage aller verfügbaren Kalender alle Ressourcen abfragen, für die eine Terminbuchung zur Verfügung steht. Diese Abfrage kann auf ein oder mehrere Akteure eingeschränkt werden.
+
+3. Abfrage aller verfügbaren Slots für einen Kalender durch den Termin-Requestor: `GET https://example.org/fhir/Slot?schedule=<Schedule/ISiKKalenderExample>&status=free`
+
+In diesem Fall ist auch ein Chaining auf weitere verknüpfte Akteure möglich: `GET https://example.org/fhir/Slot?schedule.actor:HealthcareService.type=http://dicom.nema.org/resources/ontology/DCM|CT`
+
+4. Anlage einer Patient-Ressource durch den Termin-Requestor: `POST https://example.org/fhir/Patient`
+
+```json
+{
+    "resourceType": "Patient",
+    "meta": {
+        "tag": [
+            {
+                "system": "http://fhir.de/CodeSystem/common-meta-tag-de",
+                "code": "external"
+            }
+        ]
+    }
+    [...]
+}
+```
+
+Hinweis: Dieser Schritt ist optional und kann nur ausgeführt werden, falls das Termin-Repository eine Create-Interaktion für Patient-Ressourcen erlaubt. Andernfalls ist der ``patient``-Parameter in der ``$book``-Operation zu verwenden.
+
+5. Aufruf der $book-Operation durch den Termin-Requestor: `POST https://example.org/fhir/Appointment/$book`
+
+```json
+{
+  "resourceType": "Appointment",
+  "id": "ISiKTerminExample",
+  "meta": {
+    "tag": [
+      {
+        "code": "external",
+        "system": "http://fhir.de/CodeSystem/common-meta-tag-de"
+      }
+    ],
+    "profile": [
+      "https://gematik.de/fhir/isik/StructureDefinition/ISiKTermin"
+    ]
+  },
+  "status": "proposed",
+  "start": "2022-12-10T09:00:00Z",
+  "end": "2022-12-10T09:30:00Z",
+  "slot": [
+    {
+      "reference": "ISiKSlotExample"
+    }
+  ],
+  "serviceType": [
+    {
+      "coding": [
+        {
+          "code": "124",
+          "system": "http://terminology.hl7.org/CodeSystem/service-type"
+        }
+      ]
+    }
+  ],
+  "specialty": [
+    {
+      "coding": [
+        {
+          "code": "010",
+          "system": "urn:oid:1.2.276.0.76.5.114"
+        }
+      ]
+    }
+  ],
+  "participant": [
+    {
+      "actor": {
+        "display": "Test Patient",
+        "reference": "Patient/example"
+      },
+      "status": "accepted"
+    }
+  ],
+  "_priority": {
+    "extension": [
+      {
+        "url": "https://gematik.de/fhir/isik/StructureDefinition/ISiKTerminPriorityExtension",
+        "valueCodeableConcept": {
+          "coding": [
+            {
+              "code": "25876001",
+              "system": "http://snomed.info/sct"
+            }
+          ]
+        }
+      }
+    ]
+  }
+}
+```
+
+Antwort des Termin-Repository:
+
+```json
+{
+  "resourceType": "Appointment",
+  "id": "ISiKTerminExample",
+  "meta": {
+    "tag": [
+      {
+        "code": "external",
+        "system": "http://fhir.de/CodeSystem/common-meta-tag-de"
+      }
+    ],
+    "profile": [
+      "https://gematik.de/fhir/isik/StructureDefinition/ISiKTermin"
+    ]
+  },
+  "status": "booked",
+  "start": "2022-12-10T09:00:00Z",
+  "end": "2022-12-10T09:30:00Z",
+  "slot": [
+    {
+      "reference": "ISiKSlotExample"
+    }
+  ],
+  "serviceType": [
+    {
+      "coding": [
+        {
+          "code": "124",
+          "system": "http://terminology.hl7.org/CodeSystem/service-type"
+        }
+      ]
+    }
+  ],
+  "specialty": [
+    {
+      "coding": [
+        {
+          "code": "010",
+          "system": "urn:oid:1.2.276.0.76.5.114"
+        }
+      ]
+    }
+  ],
+  "participant": [
+    {
+      "actor": {
+        "display": "Test Patient",
+        "reference": "Patient/example"
+      },
+      "status": "accepted"
+    }
+  ],
+  "_priority": {
+    "extension": [
+      {
+        "url": "https://gematik.de/fhir/isik/StructureDefinition/ISiKTerminPriorityExtension",
+        "valueCodeableConcept": {
+          "coding": [
+            {
+              "code": "25876001",
+              "system": "http://snomed.info/sct"
+            }
+          ]
+        }
+      }
+    ]
+  }
+}
+```
+
+Für den Fall, dass ein Termin-Repository zum aktuellen Zeitpunkt keine Terminbestätigung geben kann, wird in der Antwortnachricht zurückgegebenen Appointment-Ressource der Wert von "Appointment.status" auf "pending" gesetzt. Als HTTP-Status-Code MUSS das Termin-Repository "202 - Accepted" zurückgeben.
+Beispielsweise kann dies der Fall sein, falls ein Termin zunächst manuell im Termin-Repository bestätigt werden muss. Sobald ein Termin im Status "pending" seitens des Termin-Repository bestätigt oder abgesagt wurde, MUSS das Termin-Repository den Status des Termins auf "booked" bzw. "cancelled" stellen. Sofern dieses unterstützt wird, SOLL eine Benachrichtigung des Termin-Consumers per Push-Mechanismus erfolgen (siehe auch nächster Abschnitt). In jedem Fall MUSS der Termin-Consumer über eine Lese- oder Such-Anfrage jederzeit den aktuellen Status der Terminbuchung ermitteln können.
+
+---
+
+### Aktualisierung / Absage eines Termins
+
+Es ist zu beachten, dass es aus Effizienzgründen für bestimmte Implementierungen sinnvoll sein kann, dass Updates einer Appointment-Ressource ausgelöst durch das Termin-Repository mittels eines Push-Mechanismus an Termin-Consumer / Termin-Requestor übermittelt werden. Im Standard-Fall müssen diese Akteure die Ressourcen mittels des entsprechenden Endpunktes eigenständig abfragen und auf Updates überprüfen. Für einen Push-Mechanismus wird auf [FHIR Subscriptions](https://www.hl7.org/fhir/R4/subscription.html) verwiesen. Die vorliegende Spezifikation macht jedoch KEINE Vorgaben für die Verwendung einer solchen Methodik.
+
+Eine Aktualisierung der Ressource erfolgt mittels einer [HTTP PATCH-Interaktion](https://www.hl7.org/fhir/R4/http.html#patch). Updates einer Appointment-Ressource MUSS das Termin-Repository unterstützen. Es MUSS mindestens die PATCH-Interaktion auf Basis einer FHIRPath-Patch-Parameter Ressource unterstützt werden.
+
+Folgende Elemente DÜRFEN NICHT durch ein Update der Ressourcen verändert werden:
+
+- Appointment.slot
+- Appointment.start
+- Appointment.end
+- Appointment.participant.actor.where(resolve() is Patient)
+
+**Hinweis:** Ein Termin-Repository MUSS einen Termin ablehnen, falls der Termin auf einen nicht vorhandenen (gelöscht oder inaktiv) Patienten referenziert. Dies gilt insbesondere auch nachträglich für vorläufig angelegte Patienten-Ressourcen.
+
+Sollte die PATCH-Parameter-Ressource eins dieser Elemente verändern, MUSS die Operation mit einem Status Code "HTTP 400 - Bad Request" zurückgewiesen werden. Eine OperationOutcome Ressource MUSS zurückgegeben werden, die in kodierter Form den entsprechenden Fehler beschreibt.
+
+Beispiel: Absage eines Termins
+
+```json
+{
+    "resourceType": "Parameters",
+    "parameter": [{
+        "name": "operation",
+        "part": [
+            {
+                "name": "type",
+                "valueCode": "replace"
+            },
+            {
+                "name": "path",
+                "valueString": "Appointment.status"
+            },
+            {
+                "name": "value",
+                "valueCode": "cancelled"
+            }
+        ]
+    }]
+}
+```
+
+Falls die Aktualisierung eines Termins die Veränderung eines der oben genannten Elemente zur Folge hat, z.B. aufgrund einer zeitlichen Verschiebung des Termins, so kann die Appointment-Ressource erneut unter Beibehaltung der id an die $book-Operation übergeben werden. Das Termin-Repository kann so feststellen, ob der Termin in abgeänderter Form verfügbar ist.
+
+### Anlage / Aktualisierung einer Patient-Ressource
+
+Mindestens einer der nachfolgenden Wege MUSS unterstützt werden, um eine Patient-Ressource im Kontext der Terminbuchung zu erstellen oder zu übermitteln:
+
+- Direkte Erstellung über Create-Interaktion:
+  Das Termin-Repository unterstüzt die Anlage einer Patient-Ressource über eine FHIR-Create-Interaktion – gemäß den Vorgaben des [ISiK-Basismoduls (Stufe 5)](https://simplifier.net/guide/isik-basis-stufe-5/Einfuehrung/Festlegungen/UebergreifendeFestlegungen_Rest).  
+  Um auch eine Aktualisierung von Patienteninformationen zu ermöglichen, SOLLTE zusätzlich die Unterstützung einer Update-Interaktion bereitgestellt werden.  
+
+  > **Hintergrund**: Ein Update der Patient-Ressource über den `patient`-Parameter in der `$book`-Operation ist technisch aufwändiger, da das Termin-Repository hierzu zunächst die interne ID der bestehenden Instanz mittels Patient-Matching ermitteln müsste. Dies ist bei unvollständigen oder minimalen Patientenangaben häufig nicht zuverlässig möglich.
+
+- Übergabe innerhalb der `$book`-Operation:
+  Das Termin-Repository unterstützt die Übergabe einer Patient-Instanz mittels des dafür vorgesehenen Parameters innerhalb der `$book`-Operation.
+
+### Asynchrone Ausführung $book
+
+Die Operation zur Buchung eines Termins MUSS ebenfalls asynchron ausgeführt werden können, falls ein Termin-Repository keine Zusagen zu Antwortzeiten machen kann und somit das Problem besteht, dass der Client in einen Timeout läuft. Beispielsweise kann dies der Fall sein, wenn die Buchungsanfrage im Termin-Repository asynchrone Anfragen an andere Systeme auslöst und der Termin erst bestätigt werden kann, wenn diese durchgelaufen sind. Es gelten die Regeln der [FHIR Kernspezifikation - Abschnitt 3.2.0.7 Executing an Operation Asynchronously](https://www.hl7.org/fhir/r4/operations.html):
+
+- Der Aufruf der $book-Operation erfolgte auch im asynchronen Fall durch einen POST-Request
+- Ein HTTP-Header mit dem Namen "Prefer" und dem Inhalt "respond-async" MUSS im Aufruf der Operation enthalten sein
+- Als HTTP-Status-Code MUSS das Termin-Repository "202 - Accepted" zurückgeben
+- Im Fehlerfall MUSS ein 4XX- oder 5XX-HTTP-Status-Code zurückgeben werden
+- Zudem MUSS das Termin-Repository einen ‚Content-Location‘-Header zurückliefern, in dem eine valide absolute URL enthalten ist, unter der die oben beschriebene Appointment- bzw. OperationOutcome-Ressource als Antwort auf die Buchung des Termins abgerufen werden kann
+
diff --git a/publisher-guides/Terminplanung-5/input/pagecontent/Prozesse.md b/publisher-guides/Terminplanung-5/input/pagecontent/Prozesse.md
new file mode 100644
index 0000000000..5abec5626b
--- /dev/null
+++ b/publisher-guides/Terminplanung-5/input/pagecontent/Prozesse.md
@@ -0,0 +1,70 @@
+---
+topic: Prozesse
+---
+
+# {{page-title}}
+
+<img src="https://raw.githubusercontent.com/gematik/spec-ISiK-Basismodul/refs/heads/archive-stable-pics-etc/Material/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-Basismodul/refs/heads/archive-stable-pics-etc/Material/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/Terminplanung/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/Terminplanung/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/Terminplanung/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:Interaktionen, text:Interaktionen}} gelistet.
+
+**Hinweis:** Es sei darauf hingewiesen, dass hier explizit der UML-Akteur **'Buchender'** genutzt wurde, wobei dies sowohl einen **Patienten** als auch eine **angehörige Person** bedeuten kann, die im Namen des Patienten einen Termin bucht.
+Der Anteil an Buchungen durch Dritte ist relevant und kann in bestimmten Versorgungs-Settings sogar die Regel darstellen. Entsprechend sollten auch die Registrierungs-, Authentifizierungs und die Patientendatenübermittlung gestaltet werden.
+
+
+**Hinweis:** Es sei darauf hingewiesen, dass hier explizit der UML-Akteur **'Buchender'** genutzt wurde, wobei dies sowohl einen **Patienten** als auch eine **angehörige Person** bedeuten kann, die im Namen des Patienten einen Termin buchen können.
+
+
+## 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/Terminplanung/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 (Annahme: Patientendaten liegen bereits intern im Basis-Server vor, da Patient bereits Kontakt mit dem Krankenhaus hatte):
+
+{{render:Material/Terminplanung/images/diagrams/identitaetsnachweis-sequenz-happy-path-patient.png}}
+
+**Hinweis zur Abfolge von Terminbuchung und Registrierung:**
+Explizit soll eine Registrierung erst bei tatsächlicher Buchung erfolgen – nicht bereits zur Anzeige verfügbarer Termine. So ist es möglich Absprungraten zu senken, die digitale Zugänglichkeit zu steigern sowie die Nutzerakzeptanz allgemein zu verbessern. Auch der Vorsatz der Datenminimierung kann besser eingehalten werden.
+Es muss angenommen werden, dass viele Termine durch Dritte gebucht werden – etwa Angehörige, Eltern oder gesetzlich betreuende Personen. Eine sofortige Registrierung erschwert diese unterstützenden Prozesse und schränkt die barrierearme Nutzung deutlich ein, vor allem bei einmaliger oder sporadischer Inanspruchnahme.
+Zudem ist naheliegend, dass Patienten sich zunächst unverbindlich orientieren möchten, ob passende Termine oder Leistungen angeboten werden. Eine Registrierung als Einstieg widerspräche etablierten UX-Prinzipien („erst Wert zeigen, dann Verpflichtung“) und erhöht die Nutzungshürde ohne erkennbaren Mehrwert.
+
+Zur Darstellung des Sachverhalts einer Buchung durch Angehörige kann folgendes Diagramm dienen:
+
+{{render:Material/Terminplanung/images/diagrams/identitaetsnachweis-sequenz-angehoeriger.png}}
+
+In diesem Kontext sollte gelten:
+- Die Registrierung im Patientenportal bezieht sich ausschließlich auf die buchende Person. Ihre Identität und Kontaktdaten werden zur Nutzerführung, Kommunikation und ggf. Authentifizierung verwendet.
+- Die Terminbuchung selbst sollte die Identität der zu behandelnden Person erfassen – also des tatsächlichen Patienten. Diese Patientendaten (z. B. Name, Geburtsdatum, KVNR) sind mit dem gebuchten Termin zu verknüpfen und sollten korrekt an nachgelagerte Systeme (z. B. Termin-Repository, Basis-Server) übergeben werden.
+- Bei Bedarf (z. B. für die Slot-Suche) kann bereits vor der Buchung eine (minimale) strukturierte Erfassung von Patientendaten (z. B. Sprache, Alter, Geschlecht etc.) im Termin-Requestor (oder angeschlossener Komponente) erfolgen, ohne dabei eine Registrierung zu erzwingen.
+
+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.
\ No newline at end of file
diff --git a/publisher-guides/Terminplanung-5/input/pagecontent/ReleaseNotes.md b/publisher-guides/Terminplanung-5/input/pagecontent/ReleaseNotes.md
new file mode 100644
index 0000000000..3298ccc99b
--- /dev/null
+++ b/publisher-guides/Terminplanung-5/input/pagecontent/ReleaseNotes.md
@@ -0,0 +1,273 @@
+# Release Notes
+
+Im Rahmen der ISiK-Veröffentlichungen wird das [Semantic Versioning](https://semver.org/lang/de/) verwendet.
+
+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 5.1.0
+
+Datum: 23.10.2025
+
+* `improve` Hinweis zur Handhabung von Create-Interaktionen hinzugefügt https://github.com/gematik/spec-ISiK-Basismodul/pull/792
+* `improve` Klarstellung zur Fallunterscheidung bei der Patienteninstanz-Übergabe und Begründung sowie Hinweis hinzugefügt https://github.com/gematik/spec-ISiK-Basismodul/pull/793
+* `improve` Klarstellung zum Fehlercode bei nicht unterstütztem alleinstehendem Parameter 'start' https://github.com/gematik/spec-ISiK-Basismodul/pull/797 und Vorgabe zur error Code 422 gelockert (SOLL statt MUSS) https://github.com/gematik/spec-ISiK-Basismodul/pull/805
+* `improve` id-Elemente sind in *allen* Profilen dokumentiert und als bedingtes Pflicht-/MS-Feld gekennzeichnet. https://github.com/gematik/spec-ISiK-Basismodul/pull/799
+* `improve` Klarstellung welche Fehler zu einem HTTP 422 Response Code bei der Verarbeitung der $book-Operation führen
+* `documentation` Rendering der im Modul verwendeten ValueSets https://github.com/gematik/spec-ISiK-Basismodul/pull/802
+* `documentation` Dokumentation der Suchparameter (Beispiele) in CpS überführt. Darüber hinaus wurden einige Suchparameter, aus Stufe 3 in Stufe 5 übernommen https://github.com/gematik/spec-ISiK-Basismodul/pull/809
+* `documentation` Durch Entfernung des Abschnittes "Übersicht der Akteure" den Abschnitt Akteure klarer gestaltet https://github.com/gematik/spec-ISiK-Basismodul/pull/848
+
+
+## Version 5.0.0
+
+Datum: 26.06.2025
+
+* `documentation` Dokumentation und Klarstellung zur Verwendung des Akteurs "Buchender" (als Patient und Angehöriger) in Prozessen https://github.com/gematik/spec-ISiK-Basismodul/pull/763
+* `improve` Ausdifferenzierung der Prozesse rund um die Registrierung und den Identitätsnachweis bei Terminbuchung https://github.com/gematik/spec-ISiK-Basismodul/pull/764/files`
+* `improve` Entfernen der modulübergreifenden Terminologieseite, da nicht zielführend https://github.com/gematik/spec-ISiK-Basismodul/pull/767
+* `improve` Satz zur Übergabe von Appointments mit einer id klarer formuliert https://github.com/gematik/spec-ISiK-Basismodul/pull/773
+
+Mit Inkrafttreten der Stufe 5 werden auch sämtliche nachfolgend aufgeführten Änderungen verbindlich.
+
+## Version 5.0.0-rc2 (Benehmensherstellung)
+
+Datum: 5.6.2025
+
+* `documentation` Dokumentation zu den Interaktionen entsprechend der $book-Operation zur Terminverschiebung angepasst https://github.com/gematik/spec-ISiK-Basismodul/pull/745
+
+
+## Version 5.0.0-rc
+
+Mit der Stufe 5 werden alle Technical Corrections der Stufe 4 bindend.
+
+Datum: 09.04.2025
+
+* `improve` Communication aus dem Modul Terminplanung entfernt zur Vermeidung einer Überlappung mit der Verwendung weiterer TI-Produkte (z.B. TI-Messenger und KIM-Nachrichten) https://github.com/gematik/spec-ISiK-Basismodul/pull/607
+* `improve` Encounter aus dem Modul Terminplanung als Profil entfernt und in das Basismodul übertragen, dafür Capability Statement erweitert um entsprechende Rolle https://github.com/gematik/spec-ISiK-Basismodul/pull/604
+* `documentation` Migration des IG auf die neue IG Struktur basierend auf FQL Templates, die für ISiK-Basis erstellt wurden https://github.com/gematik/spec-ISiK-Terminplanung/pull/277
+* `improve` ISiKKalender enthielt ein required Binding auf ein VS welches auf ein `fragment`
+  CodeSystem
+  referenziert (Schedule.specialty.coding:ErweiterterFachabteilungsschluessel). Dies wurde durch ein
+  extensible Binding und ein Pattern auf .system ersetzt um die Validierbarkeit des Feldes zu
+  ermöglichen. https://github.com/gematik/spec-ISiK-Basismodul/pull/613
+
+---
+
+## Version 4.0.3
+
+Datum: 08.04.2025
+
+* `documentation` Verbesserung der Dokumentation der Interaktionen auf der Communication-Ressource nach Anpassung der Suchparameter `subject` und `patient`  https://github.com/gematik/spec-ISiK-Terminplanung/pull/273
+* `improve` Erweiterung zur Übergabe einer Patienten- und RelatedPerson-Instanz mittels Parameters in $book https://github.com/gematik/spec-ISiK-Terminplanung/pull/269  und https://github.com/gematik/spec-ISiK-Terminplanung/commit/7f13332c26269ca95c024cf1167c2e8a7239681c
+
+
+---
+
+## Version 4.0.2
+
+Datum: 20.02.2025
+
+
+* `improve` Die Verbindlichkeit des Suchparameters `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
+* `improve` Neue Seite zur Zusammenfassung rund um Prozesse des Patient-Onboardings https://github.com/gematik/spec-ISiK-Terminplanung/pull/267
+* `fix` Anpassung Kardinalität Appointment.start/end https://github.com/gematik/spec-ISiK-Terminplanung/pull/260
+
+
+
+---
+
+## Version 4.0.1
+
+Datum: 02.12.2024
+
+* `improve` Implizites ValueSet expandiert https://github.com/gematik/spec-ISiK-Terminplanung/pull/207
+* `documentation` Dokumentation zur Begründung der Kardinalitäten und Must-Support-Flags ergänzt https://github.com/gematik/spec-ISiK-Terminplanung/pull/209
+* `improve` 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
+* Anforderungen an die Kodierung von Appointment/Schedule.serviceType geschwächt https://github.com/gematik/spec-ISiK-Terminplanung/pull/227
+* `improve` Schwächung der Kardinalität von actor.display im Profil StructureDefinition-ISiKTermin https://github.com/gematik/spec-ISiK-Terminplanung/pull/233
+ * Ergänzung von Anforderungen an Akteure https://github.com/gematik/spec-ISiK-Terminplanung/pull/236
+ * `fix` Fix der Canonical URL im Capability-Statement des Terminplanungsserver https://github.com/gematik/spec-ISiK-Terminplanung/pull/238
+ * `improve` Hinzufügen der Extension "Appointment Replaces" zum Profil ISiKTermin https://github.com/gematik/spec-ISiK-Terminplanung/pull/242
+ * `improve` Update der Dependency de.ihe-d.terminology auf Version 3.0.1 https://github.com/gematik/spec-ISiK-Terminplanung/pull/240
+* `fix` Korrektur des Extension Kontext in ISiKKalender https://github.com/gematik/spec-ISiK-Terminplanung/pull/239
+* Aktualisierung der Operation ISiKBookOperation https://github.com/gematik/spec-ISiK-Terminplanung/pull/245
+
+----
+
+## Version 4.0.0
+
+Datum: 01.10.2024
+
+* Aktive Version ohne weitere Änderungen 
+
+----
+
+## Version 4.0.0-rc2
+
+Datum: 26.6.2024
+
+* `improve` Schwächung der Anforderung für ISiKBinary (entspricht Änderung in TC 3.0.4) https://github.com/gematik/spec-ISiK-Terminplanung/pull/187 
+* Anpassen der MS-Definition für Appointment.communication https://github.com/gematik/spec-ISiK-Terminplanung/pull/191
+* `improve` Update der IHE ValueSets zu "practiceSetting" in ISiKTermin, ISiKKalender und ISiK MedizinischeBehandlungseinheit https://github.com/gematik/spec-ISiK-Terminplanung/pull/184/files
+* `improve` Klarstellung , dass unbekannte Kodierungen in .serviceType abgewiesen werden können https://github.com/gematik/spec-ISiK-Terminplanung/pull/195
+* `improve` Änderung der Anforderung für Suchanfrage zu Terminblöcken aus Kalendern https://github.com/gematik/spec-ISiK-Terminplanung/pull/193
+
+----
+
+## Version 4.0.0-rc
+
+Datum: 4.4.2024
+
+* `improve` Location als Aktuer eines Kalenders hinzugefügt, da in ISiK Basis Stufe 4 vorhanden by @alexzautke in https://github.com/gematik/spec-ISiK-Terminplanung/pull/178
+* `improve` Update $book: Verschiebung eines Termins by @alexzautke in https://github.com/gematik/spec-ISiK-Terminplanung/pull/174
+* `improve` Dependency zu IHE-Package zwecks Auflösung von ValueSets hinzugefügt https://github.com/gematik/spec-ISiK-Terminplanung/pull/175
+* Erweiterung von ISiKTermin zur Abdeckung der Kommunikations-Use-Cases und Hinweise zu letzteren https://github.com/gematik/spec-ISiK-Terminplanung/pull/173
+* `improve` Klarstellung hinzugefügt, dass Terminkalender im Kontext eines Leistungserbringers abgefragt werden können
+  * `improve` Hinweis zur Abfrage von Behandlungsleistungen im Kontext eines Behandlers @alexzautke in https://github.com/gematik/spec-ISiK-Terminplanung/pull/87
+* Präzisierung book-Operation https://github.com/gematik/spec-ISiK-Terminplanung/pull/177
+* `improve` Hinweis zur Abfrage von Behandlungsleistungen im Kontext eines Leistungserbringers by @alexzautke in https://github.com/gematik/spec-ISiK-Terminplanung/pull/144
+* `fix` Fix CpS by @alexzautke in https://github.com/gematik/spec-ISiK-Terminplanung/pull/179
+* `improve` Klarstellung cancelled-appt-id by @alexzautke in https://github.com/gematik/spec-ISiK-Terminplanung/pull/177
+
+----
+
+## Version: 3.0.4
+
+Diese Technical Correction entfällt für Stufe 4, da die Änderungen direkt in Stufe 4 (4.0.0-rc2) eingebracht sind.
+
+---
+
+## Version: 3.0.3
+
+Datum: 25.3.2024
+
+* Reduzierung der Anforderung für ISiKNachricht https://github.com/gematik/spec-ISiK-Terminplanung/pull/172
+* Präzisieren der Suchparameter-Anforderungen für Slot : https://github.com/gematik/spec-ISiK-Terminplanung/pull/168
+* Präzisieren der Anforderungen für Encounter: https://github.com/gematik/spec-ISiK-Terminplanung/commit/d596744d910fd39b421fc7f6f97f73edf471d47a 
+* Präzisierung informativ zu ISiKMedizinischeBehandlungseinheit (HealthcareService) https://github.com/gematik/spec-ISiK-Terminplanung/pull/176
+* `improve` Update Dependency des Basismoduls auf 3.0.4
+
+----
+
+## Version: 3.0.2
+
+Datum: 03.01.2024
+
+* `improve` Update ISiK Basismodul Dependency -> 3.0.1
+* Klärung zur Verwendung der Binary: add link for clarification by @f-peverali in https://github.com/gematik/spec-ISiK-Terminplanung/pull/156
+* `fix` CapabilityStatement Anforderungen entsprechend angepasst: fix CpS Encounter Read and Search interaction by @f-peverali in https://github.com/gematik/spec-ISiK-Terminplanung/pull/154
+* Klärung zur Verwendung der Ressourcen aus dem Basismodul: Feature/ptdata 723 update interactions by @f-peverali in https://github.com/gematik/spec-ISiK-Terminplanung/pull/158
+* Klärung zur Nutzung der ISiKNachricht;  Feature/clarify bidirectional anfisk 178 by @f-peverali in https://github.com/gematik/spec-ISiK-Terminplanung/pull/160
+
+----
+## Version: 3.0.1
+
+Datum: 30.10.2023
+
+Mit dem Release der Stufe 3.0.1 werden die unten gelisteten Änderungen normativ festgesetzt.
+
+* `fix` Fixing KalenderName extension name ISiKKalenderSchedule.md by @alexey-tschudnowsky in https://github.com/gematik/spec-ISiK-Terminplanung/pull/110
+* `fix` Fix Suchparameter "content-mode" zu "context-type-value" by @f-peverali in https://github.com/gematik/spec-ISiK-Terminplanung/pull/120
+* `improve` Anpassung CapabilityStatement an die textuelle Beschreibung der verpflichtenden Interaktionen by @alexzautke in https://github.com/gematik/spec-ISiK-Terminplanung/pull/125
+* Informative Anmerkung für den Fall, dass .extenstion:name nicht verfügbar ist by @alexzautke in https://github.com/gematik/spec-ISiK-Terminplanung/pull/129
+* `improve` Anpassung Sequenzdiagramme by @alexzautke in https://github.com/gematik/spec-ISiK-Terminplanung/pull/127 
+* `improve` Example Canonical für Behandlungsleistung angepasst by @alexzautke in https://github.com/gematik/spec-ISiK-Terminplanung/pull/134
+* Abfrage aller verfügbaren Slots für Kalender durch Termin-Requestor by @alexzautke in https://github.com/gematik/spec-ISiK-Terminplanung/pull/135
+* Verwendung realistische Dauer für einen Slot in den Beispielen by @alexzautke in https://github.com/gematik/spec-ISiK-Terminplanung/pull/137
+* Angleichung der Regeln zu meta.tag in Appointments by @alexzautke in https://github.com/gematik/spec-ISiK-Terminplanung/pull/136
+* `fix` Fix HTTP return code by @f-peverali in https://github.com/gematik/spec-ISiK-Terminplanung/pull/131
+* `improve` Hinweis zur Abfrage von Behandlungsleistungen hinzugefügt by @alexzautke in https://github.com/gematik/spec-ISiK-Terminplanung/pull/139
+* BookOperation Anforderung von KANN zu SOLLTE by @alexzautke in https://github.com/gematik/spec-ISiK-Terminplanung/pull/143
+* Austausch der Communication/Binary-Ressourcen genauer beschrieben by @alexzautke in https://github.com/gematik/spec-ISiK-Terminplanung/pull/140
+* `improve` Enhancement Appointment and Slot reference MS by @f-peverali in https://github.com/gematik/spec-ISiK-Terminplanung/pull/133
+
+----
+## Version: 3.0.0
+
+Datum: 01.07.2023
+
+* Mit dem Release der Stufe 3.0.0 werden die unten gelisteten Änderungen normativ festgesetzt.
+
+----
+## Version: 3.0.0-rc2
+
+Datum: 31.05.2023
+
+* ISiKTerminAppointment   * Änderung zu Appointment.serviceType aus 3.0.0-rc1 (Kommentierung) wurde zurückgezogen
+    * wurde revert Changes for Appointment.serviceType #88 by @f-peverali in https://github.com/gematik/spec-ISiK-Terminplanung/pull/89
+  * `documentation` Eine IG Seite zur Encounter Beschreibung für Terminplanung wurde hinzugefügt
+    * Encounter Beschreibung für Terminplanung by @f-peverali in https://github.com/gematik/spec-ISiK-Terminplanung/pull/87
+  * Mehrere Slots müssen nicht mehr  ein und denselben Schedule referenzieren
+    * rm cosntraint: allow different Schedules #82 by @f-peverali in https://github.com/gematik/spec-ISiK-Terminplanung/pull/92
+  * Die Änderung zu Appointment.specialty wurde um eine textuelle Vorgabe zum MS ergänzt
+    * MS + textual constraint #72 by @f-peverali in https://github.com/gematik/spec-ISiK-Terminplanung/pull/91
+* Operations statt eines Bundle reicht als Return-Wert ein Appointment
+  * return Ressources #85 by @f-peverali in https://github.com/gematik/spec-ISiK-Terminplanung/pull/93
+
+----
+## Version: 3.0.0-rc1
+
+Datum: 04.04.2023
+
+* ISiKTerminKontaktMitGesundheitseinrichtung - by @f-peverali in <https://github.com/gematik/spec-ISiK-Terminplanung/commit/9f523157682bd26a304f388a6f0d7c91a91811da> : Entfernen des Profils da kein integraler Use Case für Terminvereinbarung und Inkompatibilität zum ISiK Basisprofil
+* ISiKNachricht Hinweis zum Thema Sicherheit eingefügt. Ohne weitere Maßnahmen können über ISiKNachricht keine medizinischen Daten ausgetauscht werden. Hierfür sollte daher bevorzugt die ePA verwendet werden.
+* ISiKTermin - Enhancement /appointment by @jcaumann in <https://github.com/gematik/spec-ISiK-Terminplanung/pull/79> :
+  * `improve` Kardinalität der Elemente Appointment.specialty und Appointment.serviceType von 1..* auf 0..* geändert . MustSupport dieser Elemente von "true" auf "false" geändert.
+    * FHIR erlaubt die Anlage von Appointments ohne Bindung an einen Slot und außerhalb des Worksflows über einen Kalender. Dies kann z.B. auch dann erforderlich sein, wenn ein Termin außerhalb der definierten Slots per Telefon vereinbart und dann in das System eingespeist wird. In diesem Fall findet keine "Vererbung" von serviceType und specialty aus einem Kalender statt. Die Person, die den Termin in das System einträgt sollte hier selbst entscheiden können, welche Attribute sie explizit angibt und welche sich implizit aus dem Kontext erschließen.
+    * ISiK Terminblöcke referenzieren auf Kalender, die auch andere als ISIK Kalender sein können. Damit ist nicht sichergestellt, dass eine durchgängige, automatische "Vererbung" von specialty und serviceType über Schedule und Slot in ein Appointment möglich ist (in FHIR Schedule und ISiK Terminblock ist die Kardinalität jeweils "0..*", d.h. diese Angaben können auch gänzlich fehlen).
+  * Kongruenz der Angaben in Appointment.start/end und Appointment.slot.start/end von MUSS auf SOLL herabgestuft.
+    * s .o. Bei off-band-Buchungen wird eine gewisse Flexibilität im Umgang mit dem Kalender benötigt.
+  * Hinweise zu den erwarteten Ergebnissen bei Suchanfragen auf "sepcialty" und "serviceType" in Fällen, bei denen diese Elemente keinen Wert haben.
+* ISiKBookOperation Für die Abbildung eines manuellen Buchungsprozesses wurden die Vorgaben zu den Return Values beim Appointment.status um "pending" erweitert
+  * in Enhancement/appointment by @jcaumann in <https://github.com/gematik/spec-ISiK-Terminplanung/pull/79>
+
+____
+## Version: 2.0.3
+
+Datum: 24.03.2023
+
+* `improve` enhancement backport extension r5 by @f-peverali in https://github.com/gematik/spec-ISiK-Terminplanung/pull/61
+  * ISiKKalender - Harmonisierung mit den Empfehlungen der Basisprofile DE
+* `fix` quickfix typo IG by @f-peverali in https://github.com/gematik/spec-ISiK-Terminplanung/pull/63
+
+
+**Full Changelog**: https://github.com/gematik/spec-ISiK-Terminplanung/compare/v2.0.2...v.2.0.3
+
+----
+## Version: 2.0.2
+
+Datum: 31.01.2023
+
+- ISiKTerminblock   
+  - Reference(Schedule) statt Reference(ISiKKalender). Reference-Element erweitert auf die Kernspezifikation (entspricht allgemeinem Design-Prinzip), damit die Profile auch außerhalb des ISiK-Kontextes nutzbar sind.
+
+- Update Basismodul Dependency -> 2.0.4
+- weitere Änderungen an IG (informativ)
+
+----
+## Version: 2.0.1
+
+Datum: 31.10.2022
+
+- Update Basismodul Dependency -> 2.0.2
+
+----
+## Version: 2.0.0
+
+Datum: 30.06.2022
+
+- Initialer Release
+
+----
+## Version: 2.0.0 (Ballotierung)
+
+Datum: 31.03.2022
+ - Initiale Ballotierungsversion für ISiK Stufe 2
+
+----
diff --git a/publisher-guides/Terminplanung-5/input/pagecontent/UebergreifendeFestlegungen.md b/publisher-guides/Terminplanung-5/input/pagecontent/UebergreifendeFestlegungen.md
new file mode 100644
index 0000000000..edab117ab1
--- /dev/null
+++ b/publisher-guides/Terminplanung-5/input/pagecontent/UebergreifendeFestlegungen.md
@@ -0,0 +1,5 @@
+# Übergreifende Festlegungen
+
+Es gelten die Festlegungen aus dem Modul [ISiK Basis Stufe 5](https://simplifier.net/guide/isik-basis-stufe-5/Einfuehrung).
+
+Die Herstellung eines Patient- und Encounterkontext kann im vorliegenden Modul abweichen vom Basismodul.
\ No newline at end of file
diff --git a/publisher-guides/Terminplanung-5/input/pagecontent/UseCases.md b/publisher-guides/Terminplanung-5/input/pagecontent/UseCases.md
new file mode 100644
index 0000000000..0923504823
--- /dev/null
+++ b/publisher-guides/Terminplanung-5/input/pagecontent/UseCases.md
@@ -0,0 +1,24 @@
+---
+topic: UseCases
+---
+
+# Use Cases
+
+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:
+
+- Abbildung von verfügbaren teil- und voll- stationären Behandlungen
+- Abfrage von verfügbaren Terminen
+- 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 folgende Festlegungen:
+
+{{index:current}}
+
+Eine grafische Übersicht über die Use Cases und ihre Zusammenhänge bietet folgendes Diagramm:
+
+{{render:Material/Terminplanung/images/diagrams/patient-buchung-UseCase.png}}
diff --git a/publisher-guides/Terminplanung-5/input/pagecontent/artifacts.md b/publisher-guides/Terminplanung-5/input/pagecontent/artifacts.md
new file mode 100644
index 0000000000..e69de29bb2
diff --git a/publisher-guides/Terminplanung-5/input/pagecontent/capabilitystatements.md b/publisher-guides/Terminplanung-5/input/pagecontent/capabilitystatements.md
new file mode 100644
index 0000000000..ec6d656fc2
--- /dev/null
+++ b/publisher-guides/Terminplanung-5/input/pagecontent/capabilitystatements.md
@@ -0,0 +1,14 @@
+---
+---
+
+# CapabilityStatements
+
+Diese Seite beschreibt die CapabilityStatements, die die erwarteten Fähigkeiten von FHIR-Servern für dieses Implementation Guide definieren.
+
+## Überblick
+
+CapabilityStatements dokumentieren die FHIR-Funktionalitäten, die ein Server implementieren muss, um mit diesem Implementation Guide konform zu sein.
+
+[Akteur Capability Statement](CapabilityStatement-ISiKCapabilityStatementTerminRepositoryAkteur.html)
+
+[Rolle Termin-Repository](CapabilityStatement-ISiKCapabilityStatementTerminRepositoryRolle.html)
diff --git a/publisher-guides/Terminplanung-5/input/pagecontent/index.md b/publisher-guides/Terminplanung-5/input/pagecontent/index.md
new file mode 100644
index 0000000000..a0bcbc8d7f
--- /dev/null
+++ b/publisher-guides/Terminplanung-5/input/pagecontent/index.md
@@ -0,0 +1,58 @@
+<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: 5.1.0
+
+Datum: 23.10.2025
+
+
+Status: Aktiv
+
+Realm: Deutschland
+
+----
+
+# Motivation Terminplanung
+
+Die Vereinbarung von Terminen für Behandlungsleistungen repräsentiert oftmals für Patienten oder für sie zuständige Leistungserbringer den Einstieg in den Versorgungsablauf im Krankenhaus. Die Terminplanung agiert somit als kritische Schnittstelle zwischen diversen Akteuren im Gesundheitswesen, inklusive der zu behandelnden Personen. Informationen zu notwendigen bzw. gewünschten Behandlungen, Verfügbarkeiten der involvierten Personen und abrechnungsrelevante Details zur Krankenversicherung müssen potenziell ausgetauscht werden, um einen optimierten Ablauf des Aufenthaltes im Krankenhaus zu ermöglichen.
+
+Das Krankenhauszukunftsgesetz (KHZG) hebt die zentrale Rolle der Terminvereinbarung hervor in dem in den dazugehörigen Fördertatbeständen Vorgaben für die Terminplanung im digitalen Aufnahmemanagement bzw. für die Terminplanung mittels Patientenportalen gemacht werden (vgl. §19 Abs. 1 Satz 1 Nr. 2 KHSFV bzw. §21 Abs. 2 KHSFV).
+
+Angelehnt an diese Vorgaben soll mittels ISiK die Grundlage geschaffen werden, um die beschriebenen oder ähnliche Use Cases durchzuführen und die fachlich-inhaltlichen Informationen in einer interoperablen Art und Weise auszutauschen. ISiK versteht sich somit als Schnittstellenbeschreibung, um eine einheitliche API zu dokumentieren, durch die ein Termin vereinbart und verwaltet werden kann. Das vorliegende ISiK-Modul bietet somit explizit KEIN umfassendes Datenmodell für die krankenhausinterne Ressourcenplanung. Hingegen werden durch ISiK Minimalvorgaben für bestätigungsrelevante Systeme spezifiziert, auf die komplexere Workflows ausgestaltet werden können.
+
+Durch ISiK Terminplanung sollen folgende Möglichkeiten eröffnet werden:
+
+* Abruf von Abbildungen von verfügbaren teil- und voll- stationären Behandlungsleistungen durch ein Krankenhaus
+* Abfrage von Terminen und Verfügbarkeiten
+* Buchungsmanagement von verfügbaren Terminen
+* Benachrichtigungen bei Terminänderungen
+* Anlage eines neuen Patienten im terminführenden System (Übermittlung Patient/Versicherungsinformationen)
+
+# Interoperabler Datenaustausch durch Informationssysteme im Krankenhaus (ISiK)
+
+Die gematik wurde vom Gesetzgeber beauftragt, im Benehmen mit der Deutschen Krankenhausgesellschaft (DKG) und den maßgeblichen Bundesverbänden der Industrie im Gesundheitswesen, verbindliche Standards für den Austausch von Gesundheitsdaten mit Informationssystemen im Krankenhaus zu erarbeiten. Dieser FHIR ImplementationGuide (IG) beschreibt die für diesen Zweck entwickelten FHIR Profile und das [REST](https://de.wikipedia.org/wiki/Representational_State_Transfer)-basierte Application Programming Interface (API). Die REST-API wird im Wesentlichen [vom FHIR Standard vorgegeben](https://www.hl7.org/fhir/R4/http.html). Dieser Leitfaden konkretisiert die ISiK-relevanten Funktionen der Standard-REST-API und trifft inhaltliche Festlegungen zu den ISiK-relevanten Ressourcen in Form von Ressourcen-Profilen.
+
+Hersteller bestätigungsrelevanter Systeme sollen durch diesen IG in die Lage versetzt werden, eine konforme Implementierung zu erstellen und das Bestätigungsverfahren der gematik erfolgreich zu absolvieren.
+
+Weitere Informationen siehe [§373 SGB V](https://www.gesetze-im-internet.de/sgb_5/__373.html).
+
+Hinweis: Sowohl für die Implementierung der ISiK-Spezifikation als auch für den Betrieb eines Produktes, das die ISiK-Spezifikation implementiert, ist eine SNOMED-CT-Lizenz notwendig. Diese kann beim [National Release Center für SNOMED CT in Deutschland](https://www.bfarm.de/DE/Kodiersysteme/Terminologien/SNOMED-CT/_node.html) beantragt werden.
+
+**Kontakt**
+
+Bringen Sie allgemeine Fragen und Anmerkungen gerne über unser Anfrageportal ein: [Anfragen ISiK + ISiP](https://service.gematik.de/servicedesk/customer/portal/16)
+
+Falls Sie keinen Zugang zum Anfrageportal haben und dieses nutzen wollen, senden Sie uns bitte eine Nachricht an die Adresse isik [ at ] gematik.de mit dem Betreff "Portalzugang".
+
+**Herausgeber**
+
+gematik GmbH
+
+[Impressum](https://www.gematik.de/impressum/)
+
+**Gender-Hinweis**
+
+Zugunsten des Leseflusses wird in dieser Publikation meist die
+männliche Form verwendet. Wir bitten, dies nicht als Zeichen einer
+geschlechtsspezifischen Wertung zu deuten. Diese Variante deckt auch alle
+weiteren Geschlechter, neben männlich und weiblich, ab.
diff --git a/publisher-guides/Terminplanung-5/input/pagecontent/profiles.md b/publisher-guides/Terminplanung-5/input/pagecontent/profiles.md
new file mode 100644
index 0000000000..7902b68768
--- /dev/null
+++ b/publisher-guides/Terminplanung-5/input/pagecontent/profiles.md
@@ -0,0 +1,16 @@
+---
+---
+
+# Profile
+
+Diese Seite beschreibt alle FHIR-Profile, die in diesem Implementation Guide definiert sind.
+
+Die Profile in diesem IG definieren Einschränkungen und Erweiterungen für FHIR-Basisressourcen, um spezifische Anwendungsfälle zu unterstützen.
+
+#TODO Liste hier ggf. alle PROFILE ?!
+
+
+
+#### Implementierungshinweise
+
+Siehe Beschreibungen im Profil.
diff --git a/publisher-guides/Terminplanung-5/input/pagecontent/terminology.md b/publisher-guides/Terminplanung-5/input/pagecontent/terminology.md
new file mode 100644
index 0000000000..e5b75a01aa
--- /dev/null
+++ b/publisher-guides/Terminplanung-5/input/pagecontent/terminology.md
@@ -0,0 +1,11 @@
+---
+---
+
+
+# Terminologien
+
+Diese Seite listet alle wesentlichen FHIR-Terminologien, die in diesem Implementation Guide definiert sind.
+
+TODO: hier ggf. die entsprechenden CS und VS einfügen - analog Subscription?!
+
+
diff --git a/publisher-guides/Terminplanung-5/input/resources/ImplementationGuide-example.test.ig.json b/publisher-guides/Terminplanung-5/input/resources/ImplementationGuide-example.test.ig.json
new file mode 100644
index 0000000000..065f1cbfef
--- /dev/null
+++ b/publisher-guides/Terminplanung-5/input/resources/ImplementationGuide-example.test.ig.json
@@ -0,0 +1,163 @@
+{
+  "resourceType": "ImplementationGuide",
+  "id": "terminplanung.test.ig",
+  "url": "http://example.org/fhir/test-termin-ig/ImplementationGuide/terminplanung.test.ig",
+  "version": "0.0.1",
+  "name": "TestImplementationGuide",
+  "title": "Test Implementation Guide",
+  "status": "draft",
+  "description": "A test implementation guide for validating the local FHIR IG Publisher environment",
+  "packageId": "example.test.ig",
+  "license": "CC0-1.0",
+  "fhirVersion": [
+    "4.0.1"
+  ],
+  "dependsOn": [
+    {
+      "packageId": "hl7.fhir.uv.ips",
+      "version": "1.1.0",
+      "uri": "http://hl7.org/fhir/uv/ips/ImplementationGuide/hl7.fhir.uv.ips",
+      "id": "hl7_fhir_uv_ips"
+    },
+    {
+      "packageId": "de.basisprofil.r4",
+      "version": "1.5.4",
+      "uri": "http://fhir.org/packages/de.basisprofil.r4/ImplementationGuide/de.basisprofil.r4",
+      "id": "de_basisprofil_r4"
+    },
+    {
+      "packageId": "de.ihe-d.terminology",
+      "version": "3.0.1",
+      "uri": "http://fhir.de/packages/de.ihe-d.terminology",
+      "id": "de_ihe_d_terminology"
+    },
+    {
+      "packageId": "dvmd.kdl.r4",
+      "version": "2025.0.1",
+      "uri": "http://fhir.org/packages/dvmd.kdl.r4/ImplementationGuide/dvmd.kdl.r4",
+      "id": "dvmd_kdl_r4"
+    },
+    {
+      "packageId": "ihe.formatcode.fhir",
+      "version": "1.4.0",
+      "uri": "https://profiles.ihe.net/fhir/ihe.formatcode.fhir/ImplementationGuide/ihe.formatcode.fhir",
+      "id": "ihe_formatcode_fhir"
+    },
+    {
+      "packageId": "hl7.fhir.uv.sdc",
+      "version": "3.0.0",
+      "uri": "http://hl7.org/fhir/uv/sdc/ImplementationGuide/hl7.fhir.uv.sdc",
+      "id": "hl7_fhir_uv_sdc"
+    },
+    {
+      "packageId": "de.gematik.terminology",
+      "version": "1.0.6",
+      "uri": "https://gematik.de/fhir/terminology/ImplementationGuide/de.gematik.terminology",
+      "id": "de_gematik_terminology"
+    }
+  ],
+  "definition": {
+    "resource": [],
+    "page": {
+      "nameUrl": "toc.html",
+      "title": "Table of Contents",
+      "generation": "html",
+      "page": [
+        {
+          "nameUrl": "index.html",
+          "title": "Home",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "ReleaseNotes.html",
+          "title": "Release Notes",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "UseCases.html",
+          "title": "UseCases",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "Akteure.html",
+          "title": "Akteure",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "Interaktionen.html",
+          "title": "Interaktionen",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "Kompatibilitaet.html",
+          "title": "Kompatibilität",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "Prozesse.html",
+          "title": "Prozesse",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "Informationsmodell.html",
+          "title": "Informationsmodell",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "Architekturoptionen.html",
+          "title": "Architekturoptionen",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "Festlegungen.html",
+          "title": "Festlegungen",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "UebergreifendeFestlegungen.html",
+          "title": "Übergreifende Festlegungen",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "Operations.html",
+          "title": "Operation $book",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "artifacts.html",
+          "title": "FHIR-Artefakte",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "profiles.html",
+          "title": "Profile",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "terminology.html",
+          "title": "Terminology",
+          "generation": "markdown"
+        },
+        {
+          "nameUrl": "capabilitystatements.html",
+          "title": "Capability Statements",
+          "generation": "markdown"
+        }
+      ]
+    },
+    "parameter": [
+      {
+        "code": "copyrightyear",
+        "value": "2025+"
+      },
+      {
+        "code": "releaselabel",
+        "value": "STU1"
+      },
+      {
+        "code": "no-validate",
+        "value": "true"
+      }
+    ]
+  }
+}
diff --git a/publisher-guides/Terminplanung-5/sushi-config.yaml b/publisher-guides/Terminplanung-5/sushi-config.yaml
new file mode 100644
index 0000000000..1b6f7781d1
--- /dev/null
+++ b/publisher-guides/Terminplanung-5/sushi-config.yaml
@@ -0,0 +1,79 @@
+id: terminplanung.test.ig
+canonical: http://example.org/fhir/test-terminplanung-ig
+name: TestImplementationGuide
+title: Test Implementation Guide
+description: A test implementation guide for validating the local FHIR IG Publisher environment
+status: draft
+version: 0.0.1
+fhirVersion: 4.0.1
+copyrightYear: 2025+
+releaseLabel: STU1
+license: CC0-1.0
+publisher: Test Organization
+
+applyExtensionMetadataToRoot: false
+dependencies:
+  # hl7.fhir.extensions.r5: 4.0.1
+  hl7.fhir.uv.ips: 1.1.0
+  hl7.fhir.uv.subscriptions-backport.r4: 1.1.0
+  de.basisprofil.r4: 1.5.4
+  de.ihe-d.terminology: 3.0.1
+  dvmd.kdl.r4: 2025.0.1
+  ihe.formatcode.fhir: 1.4.0
+  hl7.fhir.uv.sdc: 3.0.0
+  de.gematik.terminology: 1.0.6
+  
+pages:
+  index.md:
+    title: Index
+  ReleaseNotes.md:
+    title: Release Notes
+  UseCases.md:
+    title: UseCases
+    filename: UseCases.md
+  Akteure.md:
+    title: Akteure
+  Interaktionen.md:
+    title: Interaktionen
+  Kompatibilitaet.md:
+    title: Kompatibilität
+  Prozesse.md:
+    title: Prozesse
+  Informationsmodell.md:
+    title: Informationsmodell
+  Architekturoptionen.md:
+    title: Architekturoptionen
+  Festlegungen.md:
+    title: Festlegungen
+  UebergreifendeFestlegungen.md:
+    title: Übergreifende Festlegungen
+  Operations.md:
+    title: 'Operation: $book'
+
+
+menu:
+  Index: index.html
+  Release Notes: ReleaseNotes.html
+  UseCases: 
+    UseCases: UseCases.html
+    Akteure: Akteure.html
+    Interaktionen: Interaktionen.html
+    Kompatibilität: Kompatibilitaet.html
+    Prozesse: Prozesse.html
+    Informationsmodell: Informationsmodell.html
+    Architekturoptionen: Architekturoptionen.html
+  Festlegungen: 
+    Festlegungen: Festlegungen.html
+    Übergreifende Festlegungen: UebergreifendeFestlegungen.html
+    Operation $book: Operations.html
+  FHIR-Artefakte:
+    Artefakte: artifacts.html
+    CapabilityStatements: capabilitystatements.html
+    Profile: profiles.html
+    Terminology: terminology.html
+
+parameters:
+  no-validate: true
+
+#und ggfs noch:
+#  no-narrative: true
\ No newline at end of file