From b3678f97e307d59b0785c6a7f892264602305d67 Mon Sep 17 00:00:00 2001
From: f-peverali <112709306+f-peverali@users.noreply.github.com>
Date: Thu, 21 Nov 2024 10:29:44 +0100
Subject: [PATCH] remove legacy guide
---
...lementierungsleitfaden_ISiKBasismodul.json | 770 ------------------
...fall_AnmerkungenZuDenMustSupportFeldern.md | 31 -
.../Abrechnungsfall_Beispiele.md | 5 -
.../Abrechnungsfall_Interaktionen.md | 47 --
.../Abrechnungsfall_Kompatibilitaet.md | 5 -
.../Abrechnungsfall_Motivation.md | 10 -
.../Abrechnungsfall/Abrechnungsfall_Profil.md | 29 -
...keit_AnmerkungenZuDenMustSupportFeldern.md | 12 -
.../AllergieUnvertraeglichkeit_Beispiele.md | 5 -
...llergieUnvertraeglichkeit_Interaktionen.md | 62 --
...ergieUnvertraeglichkeit_Kompatibilitaet.md | 11 -
.../AllergieUnvertraeglichkeit_Motivation.md | 8 -
.../AllergieUnvertraeglichkeit_Profil.md | 27 -
...iger_AnmerkungenZuDenMustSupportFeldern.md | 43 -
.../Angehoeriger/Angehoeriger_Beispiele.md | 7 -
.../Angehoeriger_Interaktionen.md | 65 --
.../Angehoeriger_Kompatibilitaet.md | 7 -
.../Angehoeriger/Angehoeriger_Motivation.md | 5 -
.../Angehoeriger/Angehoeriger_Profil.md | 11 -
...stem_AnmerkungenZuDenMustSupportFeldern.md | 107 ---
.../BerichtSubsystem_Beispiele.md | 3 -
.../BerichtSubsystem_Interaktionen.md | 75 --
.../BerichtSubsystem_Motivation.md | 24 -
.../BerichtSubsystem_Profil.md | 9 -
...nary_AnmerkungenZuDenMustSupportFeldern.md | 11 -
.../markdown/Binary/Binary_Beispiele.md | 5 -
.../markdown/Binary/Binary_Interaktionen.md | 7 -
.../markdown/Binary/Binary_Kompatibilitaet.md | 3 -
.../markdown/Binary/Binary_Motivation.md | 12 -
.../markdown/Binary/Binary_Profil.md | 9 -
.../markdown/CapabilityStatement.md | 23 -
.../markdown/Datenobjekte/Datenobjekte.md | 3 -
.../Datenobjekte_Abrechnungsfall.md | 3 -
...Datenobjekte_AllergieUnvertraeglichkeit.md | 3 -
.../Datenobjekte/Datenobjekte_Angehoeriger.md | 3 -
.../Datenobjekte_BerichtSubsystem.md | 3 -
.../Datenobjekte/Datenobjekte_Binary.md | 3 -
.../Datenobjekte/Datenobjekte_CodeSystem.md | 3 -
.../Datenobjekte/Datenobjekte_Diagnose.md | 3 -
.../Datenobjekte/Datenobjekte_Kontakt.md | 3 -
.../Datenobjekte_Lebenszustand.md | 3 -
.../Datenobjekte/Datenobjekte_Observation.md | 3 -
.../Datenobjekte/Datenobjekte_Organisation.md | 5 -
.../Datenobjekte/Datenobjekte_Patient.md | 5 -
.../Datenobjekte_PersonImGesundheitsberuf.md | 4 -
.../Datenobjekte/Datenobjekte_Prozedur.md | 3 -
.../Datenobjekte/Datenobjekte_Standort.md | 5 -
.../Datenobjekte/Datenobjekte_Subscription.md | 3 -
.../Datenobjekte/Datenobjekte_ValueSet.md | 3 -
.../Datenobjekte_Versicherungsverhaeltnis.md | 3 -
ImplementationGuide/markdown/DecisionLog.md | 62 --
...nose_AnmerkungenZuDenMustSupportFeldern.md | 67 --
.../markdown/Diagnose/Diagnose_Beispiele.md | 5 -
.../Diagnose/Diagnose_Interaktionen.md | 77 --
.../Diagnose/Diagnose_Kompatibilitaet.md | 9 -
.../markdown/Diagnose/Diagnose_Motivation.md | 10 -
.../markdown/Diagnose/Diagnose_Profil.md | 35 -
ImplementationGuide/markdown/Einfuehrung.md | 47 --
...stem_AnmerkungenZuDenMustSupportFeldern.md | 39 -
.../markdown/Katalog/CodeSystem_Beispiele.md | 5 -
.../Katalog/CodeSystem_Interaktionen.md | 23 -
.../Katalog/CodeSystem_Kompatibilitaet.md | 3 -
.../markdown/Katalog/CodeSystem_Motivation.md | 15 -
.../markdown/Katalog/CodeSystem_Profil.md | 8 -
...takt_AnmerkungenZuDenMustSupportFeldern.md | 37 -
.../Kontakt_Beispiele.md | 5 -
.../Kontakt_Interaktionen.md | 118 ---
.../Kontakt_Kompatibilitaet.md | 8 -
.../Kontakt_Motivation.md | 85 --
.../Kontakt_Profil.md | 47 --
...tand_AnmerkungenZuDenMustSupportFeldern.md | 5 -
.../Lebenszustand/Lebenszustand_Beispiele.md | 21 -
.../Lebenszustand_Interaktionen.md | 5 -
.../Lebenszustand_Kompatibilitaet.md | 10 -
.../Lebenszustand/Lebenszustand_Motivation.md | 10 -
.../Lebenszustand/Lebenszustand_Profil.md | 183 -----
ImplementationGuide/markdown/Motivation.md | 28 -
...tion_AnmerkungenZuDenMustSupportFeldern.md | 41 -
.../Observation/Observation_Interaktionen.md | 99 ---
.../Observation/Observation_Motivation.md | 5 -
.../Observation/Observation_Profil.md | 37 -
...tion_AnmerkungenZuDenMustSupportFeldern.md | 6 -
.../Organisation/Organisation_Beispiele.md | 9 -
.../Organisation_Interaktionen.md | 73 --
.../Organisation_Kompatibilitaet.md | 5 -
.../Organisation/Organisation_Motivation.md | 20 -
.../Organisation/Organisation_Profil.md | 60 --
...ient_AnmerkungenZuDenMustSupportFeldern.md | 70 --
.../markdown/Patient/Patient_Beispiele.md | 5 -
.../markdown/Patient/Patient_Interaktionen.md | 141 ----
.../Patient/Patient_Kompatibilitaet.md | 10 -
.../markdown/Patient/Patient_Motivation.md | 9 -
.../markdown/Patient/Patient_Profil.md | 12 -
...eruf_AnmerkungenZuDenMustSupportFeldern.md | 31 -
.../PersonImGesundheitsberuf_Beispiele.md | 5 -
.../PersonImGesundheitsberuf_Interaktionen.md | 65 --
...ersonImGesundheitsberuf_Kompatibilitaet.md | 10 -
.../PersonImGesundheitsberuf_Motivation.md | 7 -
.../PersonImGesundheitsberuf_Profil.md | 35 -
...edur_AnmerkungenZuDenMustSupportFeldern.md | 48 --
.../markdown/Prozedur/Prozedur_Beispiele.md | 5 -
.../Prozedur/Prozedur_Interaktionen.md | 75 --
.../Prozedur/Prozedur_Kompatibilitaet.md | 8 -
.../markdown/Prozedur/Prozedur_Motivation.md | 10 -
.../markdown/Prozedur/Prozedur_Profil.md | 35 -
ImplementationGuide/markdown/ReleaseNotes.md | 301 -------
...dort_AnmerkungenZuDenMustSupportFeldern.md | 6 -
.../markdown/Standort/Standort_Beispiele.md | 9 -
.../Standort/Standort_Interaktionen.md | 73 --
.../Standort/Standort_Kompatibilitaet.md | 5 -
.../markdown/Standort/Standort_Motivation.md | 27 -
.../markdown/Standort/Standort_Profil.md | 92 ---
...tion_AnmerkungenZuDenMustSupportFeldern.md | 49 --
.../Subscription/Subscription_Beispiele.md | 15 -
.../Subscription_Interaktionen.md | 11 -
.../Subscription_Kompatibilitaet.md | 8 -
.../Subscription/Subscription_Motivation.md | 9 -
.../Subscription/Subscription_Profil.md | 11 -
.../IHE-Konformitaet.md | 81 --
.../KompatibilitaetDerGematikSpezifikation.md | 3 -
...ibilitaetDerGematikSpezifikation_Andere.md | 22 -
...patibilitaetDerGematikSpezifikation_IHE.md | 73 --
.../UebergreifendeFestlegungen.md | 5 -
...tlegungen_BestaetigungsrelevanteSysteme.md | 245 ------
.../UebergreifendeFestlegungen_Methodik.md | 3 -
...reifendeFestlegungen_Must-Support-Flags.md | 33 -
...ebergreifendeFestlegungen_Patient-merge.md | 109 ---
...ndeFestlegungen_Repraesentationsformate.md | 17 -
.../UebergreifendeFestlegungen_Rest.md | 51 --
...ebergreifendeFestlegungen_Suchparameter.md | 174 ----
.../markdown/UseCasesAnwendung.md | 3 -
.../markdown/UseCasesAnwendung/UseCases.md | 15 -
...eSet_AnmerkungenZuDenMustSupportFeldern.md | 39 -
.../markdown/ValueSet/ValueSet_Beispiele.md | 5 -
.../ValueSet/ValueSet_Interaktionen.md | 67 --
.../ValueSet/ValueSet_Kompatibilitaet.md | 3 -
.../markdown/ValueSet/ValueSet_Motivation.md | 6 -
.../markdown/ValueSet/ValueSet_Profil.md | 8 -
...tnis_AnmerkungenZuDenMustSupportFeldern.md | 53 --
.../Versicherungsverhaeltnis_Beispiele.md | 9 -
.../Versicherungsverhaeltnis_Interaktionen.md | 108 ---
...ersicherungsverhaeltnis_Kompatibilitaet.md | 19 -
.../Versicherungsverhaeltnis_Motivation.md | 7 -
.../Versicherungsverhaeltnis_Profil.md | 21 -
ImplementationGuide/style/master.html | 54 --
ImplementationGuide/style/settings.style | 1 -
ImplementationGuide/style/style.css | 43 -
147 files changed, 5308 deletions(-)
delete mode 100644 ImplementationGuide/Implementierungsleitfaden_ISiKBasismodul.json
delete mode 100644 ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_AnmerkungenZuDenMustSupportFeldern.md
delete mode 100644 ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_Beispiele.md
delete mode 100644 ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_Interaktionen.md
delete mode 100644 ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_Kompatibilitaet.md
delete mode 100644 ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_Motivation.md
delete mode 100644 ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_Profil.md
delete mode 100644 ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_AnmerkungenZuDenMustSupportFeldern.md
delete mode 100644 ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_Beispiele.md
delete mode 100644 ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_Interaktionen.md
delete mode 100644 ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_Kompatibilitaet.md
delete mode 100644 ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_Motivation.md
delete mode 100644 ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_Profil.md
delete mode 100644 ImplementationGuide/markdown/Angehoeriger/Angehoeriger_AnmerkungenZuDenMustSupportFeldern.md
delete mode 100644 ImplementationGuide/markdown/Angehoeriger/Angehoeriger_Beispiele.md
delete mode 100644 ImplementationGuide/markdown/Angehoeriger/Angehoeriger_Interaktionen.md
delete mode 100644 ImplementationGuide/markdown/Angehoeriger/Angehoeriger_Kompatibilitaet.md
delete mode 100644 ImplementationGuide/markdown/Angehoeriger/Angehoeriger_Motivation.md
delete mode 100644 ImplementationGuide/markdown/Angehoeriger/Angehoeriger_Profil.md
delete mode 100644 ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_AnmerkungenZuDenMustSupportFeldern.md
delete mode 100644 ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_Beispiele.md
delete mode 100644 ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_Interaktionen.md
delete mode 100644 ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_Motivation.md
delete mode 100644 ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_Profil.md
delete mode 100644 ImplementationGuide/markdown/Binary/Binary_AnmerkungenZuDenMustSupportFeldern.md
delete mode 100644 ImplementationGuide/markdown/Binary/Binary_Beispiele.md
delete mode 100644 ImplementationGuide/markdown/Binary/Binary_Interaktionen.md
delete mode 100644 ImplementationGuide/markdown/Binary/Binary_Kompatibilitaet.md
delete mode 100644 ImplementationGuide/markdown/Binary/Binary_Motivation.md
delete mode 100644 ImplementationGuide/markdown/Binary/Binary_Profil.md
delete mode 100644 ImplementationGuide/markdown/CapabilityStatement.md
delete mode 100644 ImplementationGuide/markdown/Datenobjekte/Datenobjekte.md
delete mode 100644 ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Abrechnungsfall.md
delete mode 100644 ImplementationGuide/markdown/Datenobjekte/Datenobjekte_AllergieUnvertraeglichkeit.md
delete mode 100644 ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Angehoeriger.md
delete mode 100644 ImplementationGuide/markdown/Datenobjekte/Datenobjekte_BerichtSubsystem.md
delete mode 100644 ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Binary.md
delete mode 100644 ImplementationGuide/markdown/Datenobjekte/Datenobjekte_CodeSystem.md
delete mode 100644 ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Diagnose.md
delete mode 100644 ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Kontakt.md
delete mode 100644 ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Lebenszustand.md
delete mode 100644 ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Observation.md
delete mode 100644 ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Organisation.md
delete mode 100644 ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Patient.md
delete mode 100644 ImplementationGuide/markdown/Datenobjekte/Datenobjekte_PersonImGesundheitsberuf.md
delete mode 100644 ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Prozedur.md
delete mode 100644 ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Standort.md
delete mode 100644 ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Subscription.md
delete mode 100644 ImplementationGuide/markdown/Datenobjekte/Datenobjekte_ValueSet.md
delete mode 100644 ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Versicherungsverhaeltnis.md
delete mode 100644 ImplementationGuide/markdown/DecisionLog.md
delete mode 100644 ImplementationGuide/markdown/Diagnose/Diagnose_AnmerkungenZuDenMustSupportFeldern.md
delete mode 100644 ImplementationGuide/markdown/Diagnose/Diagnose_Beispiele.md
delete mode 100644 ImplementationGuide/markdown/Diagnose/Diagnose_Interaktionen.md
delete mode 100644 ImplementationGuide/markdown/Diagnose/Diagnose_Kompatibilitaet.md
delete mode 100644 ImplementationGuide/markdown/Diagnose/Diagnose_Motivation.md
delete mode 100644 ImplementationGuide/markdown/Diagnose/Diagnose_Profil.md
delete mode 100644 ImplementationGuide/markdown/Einfuehrung.md
delete mode 100644 ImplementationGuide/markdown/Katalog/CodeSystem_AnmerkungenZuDenMustSupportFeldern.md
delete mode 100644 ImplementationGuide/markdown/Katalog/CodeSystem_Beispiele.md
delete mode 100644 ImplementationGuide/markdown/Katalog/CodeSystem_Interaktionen.md
delete mode 100644 ImplementationGuide/markdown/Katalog/CodeSystem_Kompatibilitaet.md
delete mode 100644 ImplementationGuide/markdown/Katalog/CodeSystem_Motivation.md
delete mode 100644 ImplementationGuide/markdown/Katalog/CodeSystem_Profil.md
delete mode 100644 ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_AnmerkungenZuDenMustSupportFeldern.md
delete mode 100644 ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Beispiele.md
delete mode 100644 ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Interaktionen.md
delete mode 100644 ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Kompatibilitaet.md
delete mode 100644 ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Motivation.md
delete mode 100644 ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Profil.md
delete mode 100644 ImplementationGuide/markdown/Lebenszustand/Lebenszustand_AnmerkungenZuDenMustSupportFeldern.md
delete mode 100644 ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Beispiele.md
delete mode 100644 ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Interaktionen.md
delete mode 100644 ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Kompatibilitaet.md
delete mode 100644 ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Motivation.md
delete mode 100644 ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Profil.md
delete mode 100644 ImplementationGuide/markdown/Motivation.md
delete mode 100644 ImplementationGuide/markdown/Observation/Observation_AnmerkungenZuDenMustSupportFeldern.md
delete mode 100644 ImplementationGuide/markdown/Observation/Observation_Interaktionen.md
delete mode 100644 ImplementationGuide/markdown/Observation/Observation_Motivation.md
delete mode 100644 ImplementationGuide/markdown/Observation/Observation_Profil.md
delete mode 100644 ImplementationGuide/markdown/Organisation/Organisation_AnmerkungenZuDenMustSupportFeldern.md
delete mode 100644 ImplementationGuide/markdown/Organisation/Organisation_Beispiele.md
delete mode 100644 ImplementationGuide/markdown/Organisation/Organisation_Interaktionen.md
delete mode 100644 ImplementationGuide/markdown/Organisation/Organisation_Kompatibilitaet.md
delete mode 100644 ImplementationGuide/markdown/Organisation/Organisation_Motivation.md
delete mode 100644 ImplementationGuide/markdown/Organisation/Organisation_Profil.md
delete mode 100644 ImplementationGuide/markdown/Patient/Patient_AnmerkungenZuDenMustSupportFeldern.md
delete mode 100644 ImplementationGuide/markdown/Patient/Patient_Beispiele.md
delete mode 100644 ImplementationGuide/markdown/Patient/Patient_Interaktionen.md
delete mode 100644 ImplementationGuide/markdown/Patient/Patient_Kompatibilitaet.md
delete mode 100644 ImplementationGuide/markdown/Patient/Patient_Motivation.md
delete mode 100644 ImplementationGuide/markdown/Patient/Patient_Profil.md
delete mode 100644 ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_AnmerkungenZuDenMustSupportFeldern.md
delete mode 100644 ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_Beispiele.md
delete mode 100644 ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_Interaktionen.md
delete mode 100644 ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_Kompatibilitaet.md
delete mode 100644 ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_Motivation.md
delete mode 100644 ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_Profil.md
delete mode 100644 ImplementationGuide/markdown/Prozedur/Prozedur_AnmerkungenZuDenMustSupportFeldern.md
delete mode 100644 ImplementationGuide/markdown/Prozedur/Prozedur_Beispiele.md
delete mode 100644 ImplementationGuide/markdown/Prozedur/Prozedur_Interaktionen.md
delete mode 100644 ImplementationGuide/markdown/Prozedur/Prozedur_Kompatibilitaet.md
delete mode 100644 ImplementationGuide/markdown/Prozedur/Prozedur_Motivation.md
delete mode 100644 ImplementationGuide/markdown/Prozedur/Prozedur_Profil.md
delete mode 100644 ImplementationGuide/markdown/ReleaseNotes.md
delete mode 100644 ImplementationGuide/markdown/Standort/Standort_AnmerkungenZuDenMustSupportFeldern.md
delete mode 100644 ImplementationGuide/markdown/Standort/Standort_Beispiele.md
delete mode 100644 ImplementationGuide/markdown/Standort/Standort_Interaktionen.md
delete mode 100644 ImplementationGuide/markdown/Standort/Standort_Kompatibilitaet.md
delete mode 100644 ImplementationGuide/markdown/Standort/Standort_Motivation.md
delete mode 100644 ImplementationGuide/markdown/Standort/Standort_Profil.md
delete mode 100644 ImplementationGuide/markdown/Subscription/Subscription_AnmerkungenZuDenMustSupportFeldern.md
delete mode 100644 ImplementationGuide/markdown/Subscription/Subscription_Beispiele.md
delete mode 100644 ImplementationGuide/markdown/Subscription/Subscription_Interaktionen.md
delete mode 100644 ImplementationGuide/markdown/Subscription/Subscription_Kompatibilitaet.md
delete mode 100644 ImplementationGuide/markdown/Subscription/Subscription_Motivation.md
delete mode 100644 ImplementationGuide/markdown/Subscription/Subscription_Profil.md
delete mode 100644 ImplementationGuide/markdown/UebergreifendeFestlegungen/IHE-Konformitaet.md
delete mode 100644 ImplementationGuide/markdown/UebergreifendeFestlegungen/KompatibilitaetDerGematikSpezifikation.md
delete mode 100644 ImplementationGuide/markdown/UebergreifendeFestlegungen/KompatibilitaetDerGematikSpezifikation_Andere.md
delete mode 100644 ImplementationGuide/markdown/UebergreifendeFestlegungen/KompatibilitaetDerGematikSpezifikation_IHE.md
delete mode 100644 ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen.md
delete mode 100644 ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_BestaetigungsrelevanteSysteme.md
delete mode 100644 ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Methodik.md
delete mode 100644 ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Must-Support-Flags.md
delete mode 100644 ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Patient-merge.md
delete mode 100644 ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Repraesentationsformate.md
delete mode 100644 ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Rest.md
delete mode 100644 ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Suchparameter.md
delete mode 100644 ImplementationGuide/markdown/UseCasesAnwendung.md
delete mode 100644 ImplementationGuide/markdown/UseCasesAnwendung/UseCases.md
delete mode 100644 ImplementationGuide/markdown/ValueSet/ValueSet_AnmerkungenZuDenMustSupportFeldern.md
delete mode 100644 ImplementationGuide/markdown/ValueSet/ValueSet_Beispiele.md
delete mode 100644 ImplementationGuide/markdown/ValueSet/ValueSet_Interaktionen.md
delete mode 100644 ImplementationGuide/markdown/ValueSet/ValueSet_Kompatibilitaet.md
delete mode 100644 ImplementationGuide/markdown/ValueSet/ValueSet_Motivation.md
delete mode 100644 ImplementationGuide/markdown/ValueSet/ValueSet_Profil.md
delete mode 100644 ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_AnmerkungenZuDenMustSupportFeldern.md
delete mode 100644 ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Beispiele.md
delete mode 100644 ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Interaktionen.md
delete mode 100644 ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Kompatibilitaet.md
delete mode 100644 ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Motivation.md
delete mode 100644 ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Profil.md
delete mode 100644 ImplementationGuide/style/master.html
delete mode 100644 ImplementationGuide/style/settings.style
delete mode 100644 ImplementationGuide/style/style.css
diff --git a/ImplementationGuide/Implementierungsleitfaden_ISiKBasismodul.json b/ImplementationGuide/Implementierungsleitfaden_ISiKBasismodul.json
deleted file mode 100644
index 86adbfe9..00000000
--- a/ImplementationGuide/Implementierungsleitfaden_ISiKBasismodul.json
+++ /dev/null
@@ -1,770 +0,0 @@
-{
- "resourceType": "ImplementationGuide",
- "url": "https://gematik.de/fhir/isik/ImplementationGuide/ISiK-Basismodul",
- "version": "4.0.1",
- "name": "Implementierungsleitfaden ISiK-Basismodul",
- "status": "active",
- "fhirVersion": [
- "4.0.1"
- ],
- "packageId": "de.gematik.isik-basismodul",
- "definition": {
- "resource": [
- {
- "reference": {
- "reference": "Patient/test"
- }
- }
- ],
- "page": {
- "nameUrl": "ImplementationGuide/markdown/Einfuehrung.md",
- "title": "Einführung",
- "generation": "markdown",
- "page": [
- {
- "nameUrl": "ImplementationGuide/markdown/Motivation.md",
- "title": "Motivation",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/ReleaseNotes.md",
- "title": "ReleaseNotes",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/UseCasesAnwendung.md",
- "title": "Use Cases",
- "generation": "markdown",
- "page": [
- {
- "nameUrl": "ImplementationGuide/markdown/UseCasesAnwendung/UseCases.md",
- "title": "Anwendungsfälle (Use Cases)",
- "generation": "markdown"
- }
- ]
- },
- {
- "nameUrl": "ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen.md",
- "title": "Übergreifende Festlegungen",
- "generation": "markdown",
- "page": [
- {
- "nameUrl": "ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Methodik.md",
- "title": "Methodik",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_BestaetigungsrelevanteSysteme.md",
- "title": "Bestätigungsrelevante Systeme",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/UebergreifendeFestlegungen/KompatibilitaetDerGematikSpezifikation.md",
- "title": "Kompatibilität der gematik-Spezifikation",
- "generation": "markdown",
- "page": [
- {
- "nameUrl": "ImplementationGuide/markdown/UebergreifendeFestlegungen/KompatibilitaetDerGematikSpezifikation_IHE.md",
- "title": "IHE-Profile",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/UebergreifendeFestlegungen/KompatibilitaetDerGematikSpezifikation_Andere.md",
- "title": "Nationale FHIR-Spezifikationen",
- "generation": "markdown"
- }
- ]
- },
- {
- "nameUrl": "ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Must-Support-Flags.md",
- "title": "Must-Support-Flags",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Repraesentationsformate.md",
- "title": "Repräsentationsformate",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Suchparameter.md",
- "title": "Suchparameter",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Rest.md",
- "title": "REST-API",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Patient-merge.md",
- "title": "Patient-Merge",
- "generation": "markdown"
- }
- ]
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Datenobjekte/Datenobjekte.md",
- "title": "Datenobjekte",
- "generation": "markdown",
- "page": [
- {
- "nameUrl": "ImplementationGuide/markdown/CapabilityStatement.md",
- "title": "CapabilityStatement",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Patient.md",
- "title": "Patient (Patient)",
- "generation": "markdown",
- "page": [
- {
- "nameUrl": "ImplementationGuide/markdown/Patient/Patient_Motivation.md",
- "title": "Motivation",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Patient/Patient_Kompatibilitaet.md",
- "title": "Kompatibilität",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Patient/Patient_Profil.md",
- "title": "Profil",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Patient/Patient_AnmerkungenZuDenMustSupportFeldern.md",
- "title": "Anmerkungen zu den Must-Support Feldern",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Patient/Patient_Interaktionen.md",
- "title": "Interaktionen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Patient/Patient_Beispiele.md",
- "title": "Beispiele",
- "generation": "markdown"
- }
- ]
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Kontakt.md",
- "title": "Kontakt/Fall (Encounter)",
- "generation": "markdown",
- "page": [
- {
- "nameUrl": "ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Motivation.md",
- "title": "Motivation",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Kompatibilitaet.md",
- "title": "Kompatibilität",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Profil.md",
- "title": "Profil",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_AnmerkungenZuDenMustSupportFeldern.md",
- "title": "Anmerkungen zu den Must-Support Feldern",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Interaktionen.md",
- "title": "Interaktionen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Beispiele.md",
- "title": "Beispiele",
- "generation": "markdown"
- }
- ]
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Abrechnungsfall.md",
- "title": "Abrechnungsfall (Account)",
- "generation": "markdown",
- "page": [
- {
- "nameUrl": "ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_Motivation.md",
- "title": "Motivation",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_Kompatibilitaet.md",
- "title": "Kompatibilität",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_Profil.md",
- "title": "Profil",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_AnmerkungenZuDenMustSupportFeldern.md",
- "title": "Anmerkungen zu den Must-Support Feldern",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_Interaktionen.md",
- "title": "Interaktionen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_Beispiele.md",
- "title": "Beispiele",
- "generation": "markdown"
- }
- ]
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Diagnose.md",
- "title": "Diagnose (Condition)",
- "generation": "markdown",
- "page": [
- {
- "nameUrl": "ImplementationGuide/markdown/Diagnose/Diagnose_Motivation.md",
- "title": "Motivation",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Diagnose/Diagnose_Kompatibilitaet.md",
- "title": "Kompatibilität",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Diagnose/Diagnose_Profil.md",
- "title": "Profil",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Diagnose/Diagnose_AnmerkungenZuDenMustSupportFeldern.md",
- "title": "Anmerkungen zu den Must-Support Feldern",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Diagnose/Diagnose_Interaktionen.md",
- "title": "Interaktionen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Diagnose/Diagnose_Beispiele.md",
- "title": "Beispiele",
- "generation": "markdown"
- }
- ]
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Datenobjekte/Datenobjekte_AllergieUnvertraeglichkeit.md",
- "title": "Allergie/Unverträglichkeit (AllergyIntolerance)",
- "generation": "markdown",
- "page": [
- {
- "nameUrl": "ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_Motivation.md",
- "title": "Motivation",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_Kompatibilitaet.md",
- "title": "Kompatibilität",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_Profil.md",
- "title": "Profil",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_AnmerkungenZuDenMustSupportFeldern.md",
- "title": "Anmerkungen zu den Must-Support Feldern",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_Interaktionen.md",
- "title": "Interaktionen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_Beispiele.md",
- "title": "Beispiele",
- "generation": "markdown"
- }
- ]
- }, {
- "nameUrl": "ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Lebenszustand.md",
- "title": "Spezifische Lebenszustände (Observation)",
- "generation": "markdown",
- "page": [
- {
- "nameUrl": "ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Motivation.md",
- "title": "Motivation",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Kompatibilitaet.md",
- "title": "Kompatibilität",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Profil.md",
- "title": "Profil",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Lebenszustand/Lebenszustand_AnmerkungenZuDenMustSupportFeldern.md",
- "title": "Anmerkungen zu den Must-Support Feldern",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Interaktionen.md",
- "title": "Interaktionen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Beispiele.md",
- "title": "Beispiele",
- "generation": "markdown"
- }
- ]
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Observation.md",
- "title": "Observation",
- "generation": "markdown",
- "page": [
- {
- "nameUrl": "ImplementationGuide/markdown/Observation/Observation_Motivation.md",
- "title": "Motivation",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Observation/Observation_Profil.md",
- "title": "Profil",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Observation/Observation_AnmerkungenZuDenMustSupportFeldern.md",
- "title": "Anmerkungen zu den Must-Support Feldern",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Observation/Observation_Interaktionen.md",
- "title": "Interaktionen",
- "generation": "markdown"
- }
- ]
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Prozedur.md",
- "title": "Prozedur (Procedure)",
- "generation": "markdown",
- "page": [
- {
- "nameUrl": "ImplementationGuide/markdown/Prozedur/Prozedur_Motivation.md",
- "title": "Motivation",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Prozedur/Prozedur_Kompatibilitaet.md",
- "title": "Kompatibilität",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Prozedur/Prozedur_Profil.md",
- "title": "Profil",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Prozedur/Prozedur_AnmerkungenZuDenMustSupportFeldern.md",
- "title": "Anmerkungen zu den Must-Support Feldern",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Prozedur/Prozedur_Interaktionen.md",
- "title": "Interaktionen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Prozedur/Prozedur_Beispiele.md",
- "title": "Beispiele",
- "generation": "markdown"
- }
- ]
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Versicherungsverhaeltnis.md",
- "title": "Versicherungsverhältnis (Coverage)",
- "generation": "markdown",
- "page": [
- {
- "nameUrl": "ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Motivation.md",
- "title": "Motivation",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Kompatibilitaet.md",
- "title": "Kompatibilität",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Profil.md",
- "title": "Profil",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_AnmerkungenZuDenMustSupportFeldern.md",
- "title": "Anmerkungen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Interaktionen.md",
- "title": "Interaktionen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Beispiele.md",
- "title": "Beispiele",
- "generation": "markdown"
- }
- ]
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Angehoeriger.md",
- "title": "Angehöriger (RelatedPerson)",
- "generation": "markdown",
- "page": [
- {
- "nameUrl": "ImplementationGuide/markdown/Angehoeriger/Angehoeriger_Motivation.md",
- "title": "Motivation",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Angehoeriger/Angehoeriger_Kompatibilitaet.md",
- "title": "Kompatibilität",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Angehoeriger/Angehoeriger_Profil.md",
- "title": "Profil",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Angehoeriger/Angehoeriger_AnmerkungenZuDenMustSupportFeldern.md",
- "title": "Anmerkungen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Angehoeriger/Angehoeriger_Interaktionen.md",
- "title": "Interaktionen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Angehoeriger/Angehoeriger_Includes.md",
- "title": "Beispiele",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Angehoeriger/Angehoeriger_Beispiele.md",
- "title": "Beispiele",
- "generation": "markdown"
- }
- ]
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Datenobjekte/Datenobjekte_PersonImGesundheitsberuf.md",
- "title": "PersonImGesundheitsberuf (Practitioner)",
- "generation": "markdown",
- "page": [
- {
- "nameUrl": "ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_Motivation.md",
- "title": "Motivation",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_Kompatibilitaet.md",
- "title": "Kompatibilität",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_Profil.md",
- "title": "Profil",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_AnmerkungenZuDenMustSupportFeldern.md",
- "title": "Anmerkungen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_Interaktionen.md",
- "title": "Interaktionen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_Beispiele.md",
- "title": "Beispiele",
- "generation": "markdown"
- }
- ]
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Datenobjekte/Datenobjekte_BerichtSubsystem.md",
- "title": "Bericht aus Subsystemen (Composition)",
- "generation": "markdown",
- "page": [
- {
- "nameUrl": "ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_Motivation.md",
- "title": "Motivation",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_Interaktionen.md",
- "title": "Interaktionen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_Profil.md",
- "title": "Profil",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_AnmerkungenZuDenMustSupportFeldern.md",
- "title": "Anmerkungen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_Beispiele.md",
- "title": "Beispiele",
- "generation": "markdown"
- }
- ]
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Datenobjekte/Datenobjekte_CodeSystem.md",
- "title": "Katalog (CodeSystem)",
- "generation": "markdown",
- "page": [
- {
- "nameUrl": "ImplementationGuide/markdown/Katalog/CodeSystem_Motivation.md",
- "title": "Motivation",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Katalog/CodeSystem_Profil.md",
- "title": "Profil",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Katalog/CodeSystem_Interaktionen.md",
- "title": "Interaktionen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Katalog/CodeSystem_AnmerkungenZuDenMustSupportFeldern.md",
- "title": "Anmerkungen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Katalog/CodeSystem_Beispiele.md",
- "title": "Anmerkungen",
- "generation": "markdown"
- }
- ]
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Datenobjekte/Datenobjekte_ValueSet.md",
- "title": "ValueSet (ValueSet)",
- "generation": "markdown",
- "page": [
- {
- "nameUrl": "ImplementationGuide/markdown/ValueSet/ValueSet_Motivation.md",
- "title": "Motivation",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/ValueSet/ValueSet_Kompatibilitaet.md",
- "title": "Kompatibilität",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/ValueSet/ValueSet_Profil.md",
- "title": "Profil",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/ValueSet/ValueSet_AnmerkungenZuDenMustSupportFeldern.md",
- "title": "Anmerkungen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/ValueSet/ValueSet_Interaktionen.md",
- "title": "Anmerkungen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/ValueSet/ValueSet_Beispiele.md",
- "title": "Beispiele",
- "generation": "markdown"
- }
- ]
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Organisation.md",
- "title": "Organisation (Organization)",
- "generation": "markdown",
- "page": [
- {
- "nameUrl": "ImplementationGuide/markdown/Organisation/Organisation_Motivation.md",
- "title": "Motivation",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Organisation/Organisation_Kompatibilitaet.md",
- "title": "Kompatibilität",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Organisation/Organisation_Profil.md",
- "title": "Profil",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Organisation/Organisation_Interaktionen.md",
- "title": "Interaktionen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Organisation/Organisation_AnmerkungenZuDenMustSupportFeldern.md",
- "title": "Anmerkungen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Organisation/Organisation_Beispiele.md",
- "title": "Beispiele",
- "generation": "markdown"
- }
- ]
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Standort.md",
- "title": "Standort (Location)",
- "generation": "markdown",
- "page": [
- {
- "nameUrl": "ImplementationGuide/markdown/Standort/Standort_Motivation.md",
- "title": "Motivation",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Standort/Standort_Kompatibilitaet.md",
- "title": "Kompatibilität",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Standort/Standort_Profil.md",
- "title": "Profil",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Standort/Standort_Interaktionen.md",
- "title": "Interaktionen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Standort/Standort_AnmerkungenZuDenMustSupportFeldern.md",
- "title": "Anmerkungen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Standort/Standort_Beispiele.md",
- "title": "Beispiele",
- "generation": "markdown"
- }
- ]
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Binary.md",
- "title": "Binary (Binary)",
- "generation": "markdown",
- "page": [
- {
- "nameUrl": "ImplementationGuide/markdown/Binary/Binary_Motivation.md",
- "title": "Motivation",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Binary/ValueSet_Kompatibilitaet.md",
- "title": "Kompatibilität",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Binary/Binary_Profil.md",
- "title": "Profil",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Binary/Binary_AnmerkungenZuDenMustSupportFeldern.md",
- "title": "Anmerkungen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Binary/Binary_Interaktionen.md",
- "title": "Anmerkungen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Binary/Binary_Beispiele.md",
- "title": "Beispiele",
- "generation": "markdown"
- }
- ]
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Subscription.md",
- "title": "Subscription patient-merge (R5 Backport Subscription)",
- "generation": "markdown",
- "page": [
- {
- "nameUrl": "ImplementationGuide/markdown/Subscription/Subscription_Motivation.md",
- "title": "Motivation",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Subscription/Subscription_Kompatibilitaet.md",
- "title": "Kompatibilität",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Subscription/Subscription_Profil.md",
- "title": "Profil",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Subscription/Subscription_AnmerkungenZuDenMustSupportFeldern.md",
- "title": "Anmerkungen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Subscription/Subscription_Interaktionen.md",
- "title": "Interaktionen",
- "generation": "markdown"
- },
- {
- "nameUrl": "ImplementationGuide/markdown/Subscription/Subscription_Beispiele.md",
- "title": "Beispiele",
- "generation": "markdown"
- }
- ]
- }
- ]
- }
- ]
- }
- }
-}
diff --git a/ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_AnmerkungenZuDenMustSupportFeldern.md
deleted file mode 100644
index c525a091..00000000
--- a/ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_AnmerkungenZuDenMustSupportFeldern.md
+++ /dev/null
@@ -1,31 +0,0 @@
-### Anmerkungen zu den Must-Support Feldern
-
-### `Account.extension:Abrechnungsdiagnose`
-
-**Bedeutung:** DRG- und hiervon abweichende Krankenhausdiagnosen sollten im Account zusammenfassend und abschließend angegeben werden. Relevante Prozeduren können ebenfalls aufgelistet werden.
-
-### `Account.identifier`
-
-**Bedeutung:** Der Account muss die Abrechnungsnummer des referenzierenden Kontaktes (Encounter) enthalten. Dies entspricht dem Wert des Elements Encounter.account.identifier.
-
-### `Account.status`
-
-**Bedeutung:** Der Status MUSS insbesondere zur Differenzierung von abgeschlossenen und derzeitig noch aktiven Abrechnungsfällen angegeben werden. Alle in einem System möglichen Status-Werte müssen über FHIR korrekt repräsentiert werden können, mindestens jedoch die Status-Werte "active", "inactive". Deren korrekte Abbildung wird im Rahmen des Bestätigungsverfahrens überprüft.
-
-**Hinweise:** Siehe Beschreibung in der [FHIR Kernspezifikation](https://hl7.org/fhir/R4/account-definitions.html#Account.status)
-
-### `Account.type`
-
-**Bedeutung:** Alle Accounts MÜSSEN eindeutig kategorisiert werden können, sodass eine Filterung pro Typ möglich ist.
-
-**Hinweise:** Verpflichtende Kodierung per [HL7 v3 Value Set ActEncounterCode](https://hl7.org/fhir/R4/v3/ActEncounterCode/vs.html) als Äquivalent zu Encounter.class.
-
-### `Account.subject`
-
-**Bedeutung:** Ein Patientenbezug des Falls MUSS stets zum Zwecke der Nachvollziehbarkeit und Datenintegrität vorliegen.
-
-### `Account.coverage`
-
-**Bedeutung:** Pro Abrechnungskontext (z.B. Selbstzahler, DRG, PEPP) sollte ein eigener Account angelegt werden. Für jeden Account sollte ersichtlich sein über welche Coverage der Account beglichen werden soll.
-
----
diff --git a/ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_Beispiele.md b/ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_Beispiele.md
deleted file mode 100644
index b8eaf3ac..00000000
--- a/ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_Beispiele.md
+++ /dev/null
@@ -1,5 +0,0 @@
-#### Beispiele
-
-Ein Beispiel für das Profil ISiKAbrechnungsfall:
-
-{{json:Resources/fsh-generated/resources/Account-AbrechnungsfallDRG.json}}
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_Interaktionen.md b/ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_Interaktionen.md
deleted file mode 100644
index 67b9f7db..00000000
--- a/ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_Interaktionen.md
+++ /dev/null
@@ -1,47 +0,0 @@
-### Interaktionen
-
-Für die Ressource Account MUSS die REST-Interaktion "READ" implementiert werden.
-
-Folgende Suchparameter sind für das Bestätigungsverfahren relevant, auch in Kombination:
-
-1. Der Suchparameter "_id" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Account?_id=103270```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "_id" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Parameters for all resources"](https://hl7.org/fhir/R4/search.html#all).
-
-1. Der Suchparameter "identifier" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Account?identifier=http://test.krankenhaus.de/fhir/sid/fallnr|123456```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Account.identifier" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "status" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Account?status=active```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Account.status" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "type" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Account?type=http://terminology.hl7.org/CodeSystem/v3-ActCode|AMB```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Account.type" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "patient" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Account?patient=Patient/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Account.subject" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
- ---
diff --git a/ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_Kompatibilitaet.md b/ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_Kompatibilitaet.md
deleted file mode 100644
index 60d414d8..00000000
--- a/ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_Kompatibilitaet.md
+++ /dev/null
@@ -1,5 +0,0 @@
-### Kompatibilität
-
-Für das Profil ISiKAbrechnungsfall wurde bis zum Zeitpunkt der Veröffentlichung kein Abgleich der Kompatibilität zu anderen Profilen (der KBV und der Medizininformatik-Initiative) durchgeführt.
-
----
diff --git a/ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_Motivation.md b/ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_Motivation.md
deleted file mode 100644
index f5c6e08c..00000000
--- a/ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_Motivation.md
+++ /dev/null
@@ -1,10 +0,0 @@
-### Motivation
-
-Komplementär zum Datenobjekt "Kontakt - Encounter" können Fälle, im Sinne einer Gruppierung von medizinischen Leistungen, innerhalb eines gemeinsamen Kontextes, zu einem Abrechnungsfall zusammengefasst werden.
-Ein solcher Abrechnungsfall kann mehrere Kontakte umfassen (z.B. vorstationärer Besuch, stationärer Aufenthalt und nachstationärer Besuch).
-
-Gemeinsam mit dem Einrichtungskontakt bildet der Abrechnungsfall einen wichtigen Einstiegspunkt in die Dokumentation der Behandlungsleistungen der Patienten.
-Als Bindeglied zwischen den Kontakten und dem Versicherungsverhältnis erfolgt eine feingranulare Auflistung, in welchen Zeiträumen ein Behandlungskontext zwischen einer Gesundheitseinrichtung und der Patienten bestand.
-Zudem werden Diagnosen abschließend / nachträglich dokumentiert, sodass eine Übersicht von relevanten (DRG)-Diagnosen ermöglicht wird, ohne die Gesamtheit aller Kontakte betrachten zu müssen.
-
----
diff --git a/ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_Profil.md b/ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_Profil.md
deleted file mode 100644
index eb05874a..00000000
--- a/ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_Profil.md
+++ /dev/null
@@ -1,29 +0,0 @@
-### Profil
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKAbrechnungsfall' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKAbrechnungsfall, hybrid}}
-
-Weitere Hinweise zu den Abgrenzungen der Begrifflichkeiten Fall und Kontakt finden sie unter [Deutsche Basisprofile - Abschnitt Ambulanter/stationärer Fall / Kontakt (Encounter)](https://ig.fhir.de/basisprofile-de/1.2.0/Ressourcen-AmbulanterStationaererFall.html).
-
----
-
-**Terminology Bindings**
-
-@```
-from StructureDefinition
-where url in ('https://gematik.de/fhir/isik/StructureDefinition/ISiKAbrechnungsfall' )
-for differential.element
-select
-Path: path,
-join binding.where(valueSet.exists())
-{
- Name: valueSet.substring((9 + valueSet.indexOf('ValueSet/'))),
- Strength: strength,
- URL: valueSet
-}
-```
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_AnmerkungenZuDenMustSupportFeldern.md
deleted file mode 100644
index fca58a31..00000000
--- a/ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_AnmerkungenZuDenMustSupportFeldern.md
+++ /dev/null
@@ -1,12 +0,0 @@
-### Anmerkungen zu den Must-Support-Feldern
-
-@```from
- StructureDefinition
-where
- url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKAllergieUnvertraeglichkeit'
-for differential.element
-where mustSupport = true
- and short.exists()
-select
- Feldname: id, Kurzbeschreibung: short, Hinweise: comment
-```
diff --git a/ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_Beispiele.md b/ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_Beispiele.md
deleted file mode 100644
index 34015a5e..00000000
--- a/ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_Beispiele.md
+++ /dev/null
@@ -1,5 +0,0 @@
-### Beispiel
-
-Valides Beispiel Allergie/Unverträglichkeit:
-
-{{json:Resources/fsh-generated/resources/AllergyIntolerance-ISiKAllergieUnvertraeglichkeitBeispiel1.json}}
diff --git a/ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_Interaktionen.md b/ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_Interaktionen.md
deleted file mode 100644
index 5319835f..00000000
--- a/ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_Interaktionen.md
+++ /dev/null
@@ -1,62 +0,0 @@
-### Interaktionen
-
-Für die Ressource AllergyIntolerance MUSS die REST-Interaktion "READ" implementiert werden.
-
-Folgende Suchparameter sind für das Bestätigungsverfahren relevant, auch in Kombination:
-
-1. Der Suchparameter "_id" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/AllergyIntolerance?_id=test```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "_id" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Parameters for all resources"](https://hl7.org/fhir/R4/search.html#all).
-
-1. Der Suchparameter "clinical-status" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/AllergyIntolerance?clinical-status=active```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "AllergyIntolerance.clinicalStatus" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
- Dieser Suchparameter ist für die Umsetzung des IHE QEDm Profils verpflichtend.
-
-1. Der Suchparameter "patient" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/AllergyIntolerance?patient=Patient/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "AllergyIntolerance.subject" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-1. Der Suchparameter "onset" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/AllergyIntolerance?onset=2015-01-01T12:00:23Z+02:00```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "AllergyIntolerance.onset\[x]" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Date Search"](https://hl7.org/fhir/R4/search.html#date).
-
-1. Der Suchparameter "date" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/AllergyIntolerance?date=2015-01-01T12:00:23Z+02:00```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "AllergyIntolerance.recordedDate" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Date Search"](https://hl7.org/fhir/R4/search.html#date).
-
-1. Der Suchparameter "category" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/AllergyIntolerance?category=environment```
-
-1. Der Suchparameter "type" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/AllergyIntolerance?type=allergy```
-
-
----
diff --git a/ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_Kompatibilitaet.md b/ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_Kompatibilitaet.md
deleted file mode 100644
index 22a2c6b1..00000000
--- a/ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_Kompatibilitaet.md
+++ /dev/null
@@ -1,11 +0,0 @@
-### Kompatibilität
-
-
-Für das Profil ISiKAllergieUnvertraeglichkeit wird eine Kompatibilität mit folgenden Profilen angestrebt; allerdings kann nicht sichergestellt werden, dass Instanzen, die gegen ISiKAllergieUnvertraeglichkeit valide sind, auch valide sind gegen:
-* [das Profil KBV_PR_Base_AllergyIntolerance der KBV](https://fhir.kbv.de/StructureDefinition/KBV_PR_Base_AllergyIntolerance)
-* [das Profil EMDAF_PR_AllergyIntolerance der GEVKO](https://fhir.gevko.de/StructureDefinition/EMDAF_PR_AllergyIntolerance)
-* [das Profil AllergyIntolerance-uv-ips der International Patient Summary](http://hl7.org/fhir/uv/ips/StructureDefinition/AllergyIntolerance-uv-ips)
-
-Hinweise zu Inkompatibilitäten können über die [Portalseite](https://service.gematik.de/servicedesk/customer/portal/16) gemeldet werden.
-
----
diff --git a/ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_Motivation.md b/ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_Motivation.md
deleted file mode 100644
index acb004e6..00000000
--- a/ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_Motivation.md
+++ /dev/null
@@ -1,8 +0,0 @@
-### Motivation
-
-Die Möglichkeit, auf eine Übersicht der Allergien und Unverträglichkeiten eines Patienten zuzugreifen, ist eine wichtige Funktion im klinischen Behandlungsablauf. Dies gilt insbesondere, aber nicht ausschließlich, im Bereich der Arzneimitteltherapiesicherheit.
-Motivierender Use-Case zur Einführung dieser Profile ist die [Arzneitmitteltherapiesicherheit im Krankenhaus - AMTS](https://simplifier.net/guide/isik-medikation-v4/ImplementationGuide-markdown-UebergreifendeUseCases-AMTS).
-
-In FHIR werden Allergien und Unverträglichkeiten mit der [AllergyIntolerance](https://hl7.org/fhir/R4/allergyintolerance.html)-Ressource repräsentiert.
-
----
diff --git a/ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_Profil.md b/ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_Profil.md
deleted file mode 100644
index e9f89b0b..00000000
--- a/ImplementationGuide/markdown/AllergieUnvertraeglichkeit/AllergieUnvertraeglichkeit_Profil.md
+++ /dev/null
@@ -1,27 +0,0 @@
-### Profil
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKAllergieUnvertraeglichkeit' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKAllergieUnvertraeglichkeit, hybrid}}
-
----
-
-**Terminology Bindings**
-
-@```
-from StructureDefinition
-where url in ('https://gematik.de/fhir/isik/StructureDefinition/ISiKAllergieUnvertraeglichkeit' )
-for differential.element
-select
-Path: path,
-join binding.where(valueSet.exists())
-{
- Name: valueSet.substring((9 + valueSet.indexOf('ValueSet/'))),
- Strength: strength,
- URL: valueSet
-}
-```
-
----
diff --git a/ImplementationGuide/markdown/Angehoeriger/Angehoeriger_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/Angehoeriger/Angehoeriger_AnmerkungenZuDenMustSupportFeldern.md
deleted file mode 100644
index 0d8f4adf..00000000
--- a/ImplementationGuide/markdown/Angehoeriger/Angehoeriger_AnmerkungenZuDenMustSupportFeldern.md
+++ /dev/null
@@ -1,43 +0,0 @@
-### Anmerkungen zu den Must-Support-Feldern
-
-### `RelatedPerson.name`
-
-**Bedeutung:** Name der angehörigen Person
-
-**Hinweise:** Siehe [Beschreibung der Deutschen Basisprofile](https://ig.fhir.de/basisprofile-de/1.2.0/Datentypen-HumanName.html)
-
-### `RelatedPerson.patient`
-
-**Bedeutung:** Referenz zum verwandten Patienten
-
-### `RelatedPerson.address.type`
-
-**Bedeutung:** Die Art der Adresse (physisch / postalisch)
-
-**Hinweise:** Siehe [Beschreibung der Deutschen Basisprofile](https://ig.fhir.de/basisprofile-de/1.2.0/Datentypen-Address.html)
-
-### `RelatedPerson.address.line`
-
-**Bedeutung:** Enthält Straßenname, Hausnummer, Richtung, Postfach und ähnliche Adressinformationen
-
-**Hinweise:** Siehe [Beschreibung der Deutschen Basisprofile](https://ig.fhir.de/basisprofile-de/1.2.0/Datentypen-Address.html)
-
-### `RelatedPerson.address.city`
-
-**Bedeutung:** Enthält Name der Stadt oder des Ortes
-
-**Hinweise:** Siehe [Beschreibung der Deutschen Basisprofile](https://ig.fhir.de/basisprofile-de/1.2.0/Datentypen-Address.html)
-
-### `RelatedPerson.address.postalCode`
-
-**Bedeutung:** Postleitzahl für das Gebiet
-
-**Hinweise:** Siehe [Beschreibung der Deutschen Basisprofile](https://ig.fhir.de/basisprofile-de/1.2.0/Datentypen-Address.html)
-
-### `RelatedPerson.address.country`
-
-**Bedeutung:** Land (kann z. B. ein ISO 3166-Code mit 2 oder 3 Buchstaben sein)
-
-**Hinweise:** Siehe [Beschreibung der Deutschen Basisprofile](https://ig.fhir.de/basisprofile-de/1.2.0/Datentypen-Address.html)
-
----
diff --git a/ImplementationGuide/markdown/Angehoeriger/Angehoeriger_Beispiele.md b/ImplementationGuide/markdown/Angehoeriger/Angehoeriger_Beispiele.md
deleted file mode 100644
index 3267d208..00000000
--- a/ImplementationGuide/markdown/Angehoeriger/Angehoeriger_Beispiele.md
+++ /dev/null
@@ -1,7 +0,0 @@
-### Beispiele
-
-Valides Minimalbeispiel für das Profil ISiKAngehoeriger:
-
-{{json:isikangehoerigermustermann}}
-
----
diff --git a/ImplementationGuide/markdown/Angehoeriger/Angehoeriger_Interaktionen.md b/ImplementationGuide/markdown/Angehoeriger/Angehoeriger_Interaktionen.md
deleted file mode 100644
index d0ebd2ba..00000000
--- a/ImplementationGuide/markdown/Angehoeriger/Angehoeriger_Interaktionen.md
+++ /dev/null
@@ -1,65 +0,0 @@
-### Interaktionen
-
-Für die Ressource RelatedPerson MUSS die REST-Interaktion "READ" implementiert werden.
-
-Folgende Suchparameter sind für das Bestätigungsverfahren relevant, auch in Kombination:
-
-1. Der Suchparameter "_id" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/RelatedPerson?_id=103270```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "_id" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Parameters for all resources"](https://hl7.org/fhir/R4/search.html#all).
-
-1. Der Suchparameter "patient" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/RelatedPerson?patient=Patient/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "RelatedPerson.patient" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-1. Die Suche nach einem beliebigen Bestandteil des Namens KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/RelatedPerson?name=Heidi```
-
- ```GET [base]/RelatedPerson?name=Alpenzauber```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "RelatedPerson.name" finden sich in der [FHIR-Basisspezifikation - Abschnitt "String Search"](https://hl7.org/fhir/R4/search.html#string).
-
-1. Der Suchparameter "address" KANN unterstützt werden:
-
- Beispiele
-
- ```GET [base]/RelatedPerson?address=Berlin```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "RelatedPerson.address" finden sich in der [FHIR-Basisspezifikation - Abschnitt "String Search"](https://hl7.org/fhir/R4/search.html#string).
-
- 1. Der Suchparameter "address-city" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/RelatedPerson?address-city=Berlin```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "RelatedPerson.address.city" finden sich in der [FHIR-Basisspezifikation - Abschnitt "String Search"](https://hl7.org/fhir/R4/search.html#string).
-
-1. Der Suchparameter "address-country" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/RelatedPerson?address-country=DE```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "RelatedPerson.address.country" finden sich in der [FHIR-Basisspezifikation - Abschnitt "String Search"](https://hl7.org/fhir/R4/search.html#string).
-
-1. Der Suchparameter "address-postalcode" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/RelatedPerson?address-postalcode=10117```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "RelatedPerson.address.postalCode" finden sich in der [FHIR-Basisspezifikation - Abschnitt "String Search"](https://hl7.org/fhir/R4/search.html#string).
-
- ---
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Angehoeriger/Angehoeriger_Kompatibilitaet.md b/ImplementationGuide/markdown/Angehoeriger/Angehoeriger_Kompatibilitaet.md
deleted file mode 100644
index 96bd4aa7..00000000
--- a/ImplementationGuide/markdown/Angehoeriger/Angehoeriger_Kompatibilitaet.md
+++ /dev/null
@@ -1,7 +0,0 @@
-### Kompatibilität
-
-Für das Profil ISiKAngehoeriger wurde bis zum Zeitpunkt der Veröffentlichung kein Abgleich der Kompatibilität zu anderen Profilen (der KBV und der Medizininformatik-Initiative) durchgeführt.
-
----
-
-
diff --git a/ImplementationGuide/markdown/Angehoeriger/Angehoeriger_Motivation.md b/ImplementationGuide/markdown/Angehoeriger/Angehoeriger_Motivation.md
deleted file mode 100644
index ab4f31ca..00000000
--- a/ImplementationGuide/markdown/Angehoeriger/Angehoeriger_Motivation.md
+++ /dev/null
@@ -1,5 +0,0 @@
-## Motivation
-
-Der Angehörige wird vor allem im Zusammenhang mit Anwendungsszenarien verwendet, in denen das Versicherungsverhältnis eine Rolle spielt. Hier können Angehörige, bspw. der hauptversicherte Elternteil eines minderjährigen Kindes, in der Familienversicherung sein. In Selbstzahler-Szenarien können Angehörige die Zahler für eine im Krankenhaus erbrachte Leistung sein.
-
----
diff --git a/ImplementationGuide/markdown/Angehoeriger/Angehoeriger_Profil.md b/ImplementationGuide/markdown/Angehoeriger/Angehoeriger_Profil.md
deleted file mode 100644
index 761b0014..00000000
--- a/ImplementationGuide/markdown/Angehoeriger/Angehoeriger_Profil.md
+++ /dev/null
@@ -1,11 +0,0 @@
-## Profil
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKAngehoeriger' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKAngehoeriger, hybrid}}
-
-@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKAngehoeriger' for differential.element.constraint select key, severity, human, expression```
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_AnmerkungenZuDenMustSupportFeldern.md
deleted file mode 100644
index 6444254f..00000000
--- a/ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_AnmerkungenZuDenMustSupportFeldern.md
+++ /dev/null
@@ -1,107 +0,0 @@
-### Anmerkungen zu den Must-Support-Feldern
-
-### `Composition.id`
-
-**Bedeutung:** Subsystem-interne Datensatz-ID
-
-### `Composition.profile`
-
-**Bedeutung:** Erklärung zur Konformität zum ISiK-Profil
-
-### `Composition.text`
-
-**Bedeutung:** menschenlesbare Repräsentation des Dokumentenkopfes (Metadaten)
-
-**Hinweise:** Die Mindestanforderungen an den Inhalt der menschenlesbaren Repräsentation umfasst folgende Informationen:
-
-* Composition.subject:Patient.name.family
-* Composition.subject:Patient.birthDate
-* Composition.subject:Patient.identifier:pid
-* Composition.status
-* Composition.type.text
-* Composition.date
-* Composition.title
-* Composition.author.display
-
-### `Composition.identifier`
-
-**Bedeutung:** Subsystem-seitig zugewiesener Identifier des Berichtes mit Angabe der URL des vom Subsystem verwendeten Namensraumes
-
-**Hinweise:** Werden eigene Identifier bzw. NamingSystems verwendet, so sei auf den Leitfaden der Basisprofile Deutschland (HL7 Deutschland) zu den [Best-Practices bei Namensräumen](https://ig.fhir.de/basisprofile-de/stable/Terminologie-Namensraeume.html) verwiesen.
-
-Dazu ein Beispiel für einen Identifier eines Sub-System-Berichts:
-```xml
-
-
-
-
-```
-Die Verwendung von OIDs ist möglich, wird jedoch nicht empfohlen. Für die Verwendung von OIDs KANN folgendes Format verwendet werden:
-
-* Das Feld `system` enthält den festen Wert "urn:ietf:rfc:3986"
-* Das Feld `value` enthält die OID mit dem Präfix "urn:oid:"
-
-Beispiel:
-```xml
-
-
-
-
-```
-
-### `Composition.status`
-
-**Bedeutung:** Status des Dokumentes
-
-### `Composition.type`
-
-**Bedeutung:** Dokumenttyp
-
-**Hinweise:** In der aktuellen Ausbaustufe von ISiK ist textuelle Repräsentation des Dokumenttyps (`type.text`) ausreichend. Die darüber hinausgehende Codierung des Dokumenttyps (z.B. mit LOINC, IHE-Typecodes oder KDL) in `type.coding` KANN implementiert werden
-
-### `Composition.subject`
-
-**Bedeutung:** Patientenbezug des Dokumentes
-
-### `Composition.encounter`
-
-**Bedeutung:** Fallbezug des Dokumentes
-
-### `Composition.date`
-
-**Bedeutung:** Datum der letzten Änderung am Dokument
-
-### `Composition.author.display`
-
-**Bedeutung:** Autor des Dokumentes (Person, Subsystem)
-
-**Hinweise:** In der aktuellen Ausbaustufe von ISiK ist die Verwendung der textuellen Repräsentation (display) von Autor und Subsystem ausreichend. Die darüber hinausgehende Verlinkung auf Practitioner bzw. Device-Ressourcen KANN implementiert werden.
-
-### `Composition.title`
-
-**Bedeutung:** Dokumentenbezeichnung
-
-**Hinweise:** Die Dokumentenbezeichnung dient der Darstellung des Dokumentes in einer Übersicht, z.B. in einer Patientenakte, und KANN der schnellen Auffindbarkeit eines gesuchten Dokumentes dienen. Geeignete Bezeichnungen sind zum Beispiel
-
-* "Kleines Blutbild vom 13.10.2020"
-* "Pathologiebefund (Abstrich) vom 13.10.2020"
-* "Blutgasmessung vom 13.10.2020 14:14h"
-
-### `Composition.section.title`
-
-**Bedeutung:** Kapitelüberschrift
-
-### `Composition.section.text`
-
-**Bedeutung:** menschenlesbare Repräsentation des Inhalts eines Kapitels
-
-**Hinweise:** Für Aggregation einer vollständigen menschenlesbaren Repräsentation MÜSSEN die Repräsentationen der einzelnen Kapitel an die Repräsentation der Metadaten (`Composition.text`) angehängt werden. Für die Separierung KÖNNEN einfache \-Tags verwendet werden.
-Es ist zu beachten, dass Kapitel auch Unterkapitel enthalten KÖNNEN (`Composition.section.section`), die bei der Aggregation entsprechend berücksichtigt werden MÜSSEN.
-
-Die Mindestanforderungen an den Inhalt der menschenlesbaren Repräsentation umfasst folgende Informationen:
-
-* `section.title` + Freitext **oder**
-* `section.title` + `Resource.text` der referenzierten Ressource **oder**
-* `section.title` + eine aggregierte Repräsentation von `Resource.text` wenn in einer Section mehrere Ressourcen referenziert werden.
-
----
diff --git a/ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_Beispiele.md b/ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_Beispiele.md
deleted file mode 100644
index 6e631209..00000000
--- a/ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_Beispiele.md
+++ /dev/null
@@ -1,3 +0,0 @@
-### Beispiele
-
-{{json:composition-blutdruck}}
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_Interaktionen.md b/ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_Interaktionen.md
deleted file mode 100644
index 42a417f6..00000000
--- a/ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_Interaktionen.md
+++ /dev/null
@@ -1,75 +0,0 @@
-### Interaktionen
-
-Die Rückübermittlung eines Document-Bundles an ein Primärsystem erfolgt mittels einer 'POST'-Interaktion auf den Endpunkt des Primärsystems.
-
- Beispiele:
-
- `POST [base]/` mit einer FHIR-Bundle Ressource im Request-Body.
-
- Anwendungshinweise: Weitere Informationen zu den verschiedenen Endpunkten für Dokumente finden sich in der [FHIR-Basisspezifikation - Abschnitt "Document End-Points"](https://www.hl7.org/fhir/R4/documents.html#bundle).
-
-Das Bundle dient der Aggregation aller Ressourcen, die Bestandteil des Dokumentes sind. Dabei ist die erste Ressource im Bundle (Bundle.entry.resource) stets eine Composition, alle weiteren Entries enthalten zusätzliche Ressourcen, auf die die Composition verweist.
-
-Falls die im Dokumenten-Bundle enthaltene Patient-Ressource und/oder Encounter-Ressource nicht anhand der Business-Identifier oder anderer Matching-Kriterien im empfangenden System gefunden werden kann (d.h. der Patient oder der Encounter existiert im empfangenden System noch nicht), MUSS als Antwort der HTTP Status Code "422 - Unprocessable Entity" zurückgegeben werden. Im Body der Response ist eine OperationOutcome zurückzugeben, welche ein Issue mit dem Verweis auf die nicht auflösbare Referenz enthält. Zur Kodierung von OperationOutcome.issue.code MUSS als Code ["processing"](https://hl7.org/fhir/R4/codesystem-issue-type.html) verwendet werden.
-
-Das Bundle muss folgendem Profil entsprechen:
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKBerichtBundle, hybrid}}
-
-Unterscheidungshinweis: Informationen zu Interaktionen mit Dokument-Binaries finden sich im Modul [ISiK Dokumentenaustausch](https://simplifier.net/guide/isik-dokumentenaustausch-v4/AkteureUndInteraktionen-AkteureUndInteraktionen-ErzeugenVonMetadaten?version=current).
-
-### Verarbeitung des Dokumentes
-
-**Hinweis:** Die nachfolgenden Regeln für die Verarbeitung eines Dokumentes gelten nur für Document-Bundles, die an den oben genannten Endpunkt gesendet werden. Weitere ISiK-Module können Regeln für die Verarbeitung von anderen Bundle-Typen (z.B. 'transaction') aufstellen.
-
-In der aktuellen Ausbaustufe von ISiK MUSS ein empfangenes Dokument in folgenden Schritten verarbeitet werden:
-
-1. Extraktion der Patient-Ressource aus dem Bundle und Herstellung des Patientenbezuges anhand eines eindeutigen Identifiers ('Patient.identifier') oder ähnlich identifizieren Merkmalen
-2. Extraktion der Encounter-Ressource aus dem Bundle und Herstellung des Fallbezuges anhand der Abrechnungsfallnummer ('Encounter.account.identifier') oder ähnlich identifizieren Merkmalen
-3. Extraktion der Composition-Ressource aus dem Bundle und Auslesen der mit 'mustSupport' gekennzeichneten Meta-Daten, sowie der menschenlesbaren Repräsentation des Dokumentes ('Composition.text', 'Composition.section.text', 'Composition.section.section.text')
-4. Hinzufügen des Dokumentes und seiner Metadaten zur Fallakte des Patienten.
-5. Visualisierung des Dokumentes und seiner Metadaten in der Fallakte des Patienten
-
-
-
-Die Grafik zeigt an einem vereinfachten Beispiel die Zuordnung des HTML-Dokumentes zu Patient und Kontakt in der aktuellen Ausbaustufe von ISiK (schwarze Pfeile). Die grauen Pfeile deuten die Übernahme strukturierter Daten, wie sie in weiteren Ausbaustufen erforderlich wird.
-
-### Hinweise zum Umgang mit der menschenlesbaren Repräsentation
-
-Die menschenlesbare Repräsentation ("Narrative") eines Dokumentes setzt sich zusammen aus dem Inhalt von 'Composition.text', einer Repräsentation der Metadaten (z.B. Dokumenttyp, Patientenname, Patientennummer, Aufnahmenummer, Datum) sowie der Aggregation der Inhalte von 'Composition.section', wobei zu beachten ist, dass ein Dokument beliebig viele Sections haben kann.
-Die einzelnen Bestandteile des Narratives KÖNNEN mit \-Elementen zusammengefügt werden.
-
-### Extraktion der Patient-/ und Encounter-Ressource im Document-Bundle
-
-Folgende Fälle sind zu beachten, um eine Patient-/ und Encounter-Ressource aus dem Document-Bundle zu extrahieren:
-
-* Die aufzulösende Referenz ist eine URN (immer absolut, z. B. "urn:uuid:9d1714da-b7e6-455b-bfd2-69ce0ff5fb12"):
- * Suche nach einem Bundle-Entry mit einer fullUrl, die mit dem reference.value übereinstimmt
- * Wenn einer gefunden wird, ist die Auflösung erfolgreich (und endet hier)
- * Andernfalls schlägt die Auflösung fehl (und endet hier). Die Referenz hat in dieser Spezifikation keine definierte Bedeutung.
-
-* Wenn die Referenz eine absolute URL ist (z. B. "https://fhir.example.org/base/Patient/123", "https://fhir.example.org/base/Patient/123/_history/a"):
- * Suche nach einem Bundle-Entry mit einer fullUrl, die mit dem reference.value übereinstimmt
- * Wenn einer gefunden wird, ist die Auflösung hier erfolgreich (und endet)
- * Wird mehr als ein Eintrag gefunden, KANN der Server nach der neuesten Version suchen (basierend auf meta.lastUpdated). Wenn jener auf diese Weise genau eine aktuelle Version findet, ist die Auflösung erfolgreich (und endet hier)
-
-* Wenn die Referenz die Form "[Typ]/[id]" hat (z. B. "Patient/123")
- * Wenn der Bundle-Entry, der den Verweis enthält, eine FullUrl hat, die dem [RESTful-URL-Regex](https://hl7.org/fhir/R4/references.html#regex) entspricht (z. B. "https://fhir.example.org/Observation/456"):
- * Extrahiert wird die [root] aus der fullUrl des Bundle-Entries und mit der relative Referenz zusammengefügt (z. B. "https://fhir.example.org/" + "Patient/123" --> "https://fhir.example.org/Patient/123")
- * Gefolgt wird den Schritten für die Auflösung absoluter Referenzen. Siehe oben.
-
-### Persistierung der menschenlesbaren Repräsentation
-
-Das Narrative der Ressource KANN innerhalb einer DocumentReference-Ressource persistiert werden. Zum derzeitigen Zeitpunkt obliegt es der jeweiligen Implementierung wie diese DocumentReference Ressource ausgestaltet ist.
-Ein Mapping der Composition-Metadaten auf DocumentReference-Metadaten KANN der FHIR Kernspezifikation entnommen werden. Siehe [Abschnitt "2.42.8.7 FHIR Composition"](https://www.hl7.org/fhir/R4/documentreference-mappings.html#fhircomposition).
-
-Das Narrative MUSS als Binary-Ressource unter DocumentReference.content.attachment.url angegeben werden.
-
-**Hinweis:** Es ist zu beachten, dass in einem Attachment-Datentyp im Element "url" eine absolute URL anzugeben ist. Somit muss zunächst das Binary auf dem externen System per POST angelegt werden. Der hieraus resultierende Link kann anschließend im Attachment verwendet werden.
-
-Falls ein Bundle erneut mit dem gleichen Bundle.identifier übermittelt wird, MUSS eine neue DocumentReference erstellt werden, welche unter DocumentReference.relatesTo.target angegeben wird.
-
-### Hinweise zum Umgang mit strukturierten Daten
-
-Auch wenn in der aktuellen Stufe nur die Übernahme der menschenlesbaren Repräsentation erforderlich ist, empfiehlt es sich dennoch, das vollständige Bundle samt der strukturierten Anteile zu einem Dokument zu persistieren, sodass zu einem späteren Zeitpunkt, wenn eine Übernahme einzelner Daten möglich ist, diese auch rückwirkend erfolgen kann.
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_Motivation.md b/ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_Motivation.md
deleted file mode 100644
index 4b54ae24..00000000
--- a/ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_Motivation.md
+++ /dev/null
@@ -1,24 +0,0 @@
-### Motivation
-
-In der heterogenen Systemlandschaft im Krankenhaus sind eine Vielzahl spezialisierter Subsysteme im Einsatz. Die Ergebnisse aus diesen Subsystemen sind aktuell jedoch häufig nicht in den Primärsystemen des Krankenhauses verfügbar, denn es bestehen folgende Herausforderungen:
-
-1. Die Daten in Subsystemen sind sehr heterogen und können hochspezialisiert sein.
-1. Bei der Nutzung dieser Subsysteme besteht häufig ein Interesse, auf die menschenlesbare Repräsentation der strukturierten Daten einwirken zu können.
-1. Künftig ist mit Szenarien zu rechnen, bei denen Befunde aus Subsystemen in eine elektronische Patientenakte übertragen werden sollen.
-1. Aktuell werden Befunde, obwohl diese in den Subsystemen in hochstrukturierter Form vorliegen, nur als PDF an das Primärsystem übermittelt. Oft weil kein strukturiertes Format spezifiziert ist, das sowohl versendendes Subsystem als auch empfangendes Primärsystem implementiert haben.
-1. Der Umfang, in dem eine Datenübernahme in ein Primärsystem möglich ist, variiert stark zwischen den Systemen oder Installationen, z.B. abhängig davon, ob ein Modul für Vitalparameter installiert ist.
-
-Die ISiK-Spezifikation begegnet diesen Herausforderungen, indem sie die Übermittlung von Ergebnissen aus Subsystemen an die Primärsysteme in Form von strukturierten Dokumenten erfordert, die über eine menschenlesbare Repräsentation verfügen. Diese strukturierten Dokumente werden im ISiK-Kontext als Berichte bezeichnet. Dabei sind die strukturierten Inhalte der Berichte harmonisiert mit den verbreiteten Formaten für Primärsysteme.
-
-In der aktuellen Ausbaustufe von ISiK ist lediglich die Übernahme und Anzeige der Dokument-Metadaten (z.B. Dokumenttyp, Dokumentdatum, Quelle) und der menschenlesbaren HTML-Repräsentation in die Primärsysteme erforderlich.
-
-In weiteren Ausbaustufen von ISiK soll darüber hinaus eine Übernahme der strukturierten Anteile der Dokumente möglich sein, die den ISiK-Spezifikationen entsprechen, z.B. Diagnosen und Prozeduren.
-
-Es obliegt dabei dem Ermessen des Herstellers, ob die Übernahme strukturierter Daten in das Primärsystem automatisch erfolgt, oder durch den Benutzer initiiert wird.
-
-Die Berichte werden, wie von der [FHIR Spezifikation für die Composition Ressource vorgesehen](https://www.hl7.org/fhir/R4/composition.html), in einem FHIR-Bundle versendet.
-
-Folgendes Diagramm bietet eine Übersicht zu den Profilen und ihren Zusammenhängen, die im ISiK-Kontext von einem Subsystem übermittelt werden können (nicht abschließend; d.h. auch andere Profile können übermittelt werden):
-
-
----
diff --git a/ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_Profil.md b/ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_Profil.md
deleted file mode 100644
index 92b173ef..00000000
--- a/ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_Profil.md
+++ /dev/null
@@ -1,9 +0,0 @@
-### Profil
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKBerichtSubSysteme' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKBerichtSubSysteme, hybrid}}
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Binary/Binary_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/Binary/Binary_AnmerkungenZuDenMustSupportFeldern.md
deleted file mode 100644
index fb2e1efe..00000000
--- a/ImplementationGuide/markdown/Binary/Binary_AnmerkungenZuDenMustSupportFeldern.md
+++ /dev/null
@@ -1,11 +0,0 @@
-### Anmerkungen zu den Must-Support Feldern
-
-### `Binary.contentType`
-
-**Bedeutung:** MimeType der Binärdaten
-
-### `Binary.data`
-
-**Bedeutung:** Base64-codierte Binärdaten
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Binary/Binary_Beispiele.md b/ImplementationGuide/markdown/Binary/Binary_Beispiele.md
deleted file mode 100644
index 375229f6..00000000
--- a/ImplementationGuide/markdown/Binary/Binary_Beispiele.md
+++ /dev/null
@@ -1,5 +0,0 @@
-### Beispiele
-
-{{json:Binary-JPEG-Example}}
-
-{{json:Binary-PDF-Example}}
diff --git a/ImplementationGuide/markdown/Binary/Binary_Interaktionen.md b/ImplementationGuide/markdown/Binary/Binary_Interaktionen.md
deleted file mode 100644
index e7e24bc6..00000000
--- a/ImplementationGuide/markdown/Binary/Binary_Interaktionen.md
+++ /dev/null
@@ -1,7 +0,0 @@
-### Interaktionen
-
-Für die Ressource Binary MUSS die REST-Interaktion "READ" implementiert werden. Es MÜSSEN die Regeln aus der FHIR-Kernspezifikation zur Abfrage einer Binary Ressource beachtet werden. Siehe ["Serving Binary Resources using the RESTful API"](https://www.hl7.org/fhir/R4/binary.html#rest).
-
-Um die Handhabung der base64-kodierten Binary-Ressourcen clientseitig zu erleichtern, MUSS ein bestätigungsrelevantes System (Server) bei READ-Interaktionen Accept-Header mit einem Wert außer den [FHIR-Mime-Types](https://www.hl7.org/fhir/R4/http.html#mime-type) unterstützen. Falls ein solcher Accept-Header durch einen Client verwendet wird, MUSS bestätigungsrelevante System (Server) das Binary in seiner nativen Form (definiert durch Binary.contentType) zurückgeben.
-
----
diff --git a/ImplementationGuide/markdown/Binary/Binary_Kompatibilitaet.md b/ImplementationGuide/markdown/Binary/Binary_Kompatibilitaet.md
deleted file mode 100644
index 1c98bb17..00000000
--- a/ImplementationGuide/markdown/Binary/Binary_Kompatibilitaet.md
+++ /dev/null
@@ -1,3 +0,0 @@
-### Kompatibilität
-
-Für das Profil ISiKBinary wurde bis zum Zeitpunkt der Veröffentlichung kein Abgleich der Kompatibilität zu anderen Profilen (der KBV und der Medizininformatik-Initiative) durchgeführt.
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Binary/Binary_Motivation.md b/ImplementationGuide/markdown/Binary/Binary_Motivation.md
deleted file mode 100644
index ebdabd58..00000000
--- a/ImplementationGuide/markdown/Binary/Binary_Motivation.md
+++ /dev/null
@@ -1,12 +0,0 @@
-### Motivation
-
-Die Binary-Ressource erlaubt den Umgang mit FHIR-fremden Formaten (z.B. PDFs, Bilder, CDA) innerhalb des FHIR-Frameworks.
-Dazu werden die Daten base64-codiert in der Binary-Ressource (in XML oder JSON) transportiert oder
-über die REST-API am Binary-Endpunkt in ihrem nativen Format bereitgestellt.
-Binary-Ressourcen werden von Attachment-Elementen verlinkt und damit in den Kontext anderer FHIR-Ressourcen
-(z.B. Patient und Encounter) gestellt.
-
-Das ISIK-Binary-Profil ist *nicht* Bestandteil der Implementierung und des Bestätigungsverfahrens zum ISIK Basismodul.
-Das Profil ist Teil des ISIK Basismoduls, da es als übergreifend genutzte Ressource sowohl im [Modul Terminplanung](https://simplifier.net/guide/isik-terminplanung-v4/ImplementationGuide-markdown-Datenobjekte?version=current) als auch im [Modul Dokumentenaustausch](https://simplifier.net/guide/isik-dokumentenaustausch-v4/ImplementationGuide-markdown-Datenobjekte?version=current) implementiert werden muss.
-
----
diff --git a/ImplementationGuide/markdown/Binary/Binary_Profil.md b/ImplementationGuide/markdown/Binary/Binary_Profil.md
deleted file mode 100644
index 5277f4db..00000000
--- a/ImplementationGuide/markdown/Binary/Binary_Profil.md
+++ /dev/null
@@ -1,9 +0,0 @@
-### Profil
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKBinary' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKBinary, hybrid}}
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/CapabilityStatement.md b/ImplementationGuide/markdown/CapabilityStatement.md
deleted file mode 100644
index 364046ab..00000000
--- a/ImplementationGuide/markdown/CapabilityStatement.md
+++ /dev/null
@@ -1,23 +0,0 @@
-## Konformitätserklärung [(CapabilityStatement)](https://hl7.org/fhir/R4/capabilitystatement.html)
-
-Jede Instanz eines bestätigungsrelevanten Systems MUSS an ihrem Endpunkt eine [CapabilityStatement](https://hl7.org/fhir/R4/capabilitystatement.html)-Ressource bereitstellen.
-
-Hierzu MUSS die [capabilities-Interaktion gemäß FHIR-Spezifikation](https://hl7.org/fhir/R4/http.html#capabilities) unterstützt werden.
-Der MODE-Parameter kann ignoriert werden.
-
-Das CapabilityStatement in dieser Spezifikation stellt die Anforderungen seitens der gematik dar (`kind` = "requirements"). Zur Unterscheidung von Anforderungen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die [CapabilityStatement-Expectation](https://hl7.org/fhir/R4/extension-capabilitystatement-expectation.html)-Extension mit den möglichen Werten "SHALL" (=MUSS) und "MAY" (=KANN) verwendet.
-
-Eine Server-Instanz MUSS ihrerseits ein CapabilityStatement vom `kind`= "instance" liefern und im Element `software` den Namen und die Versionsnummer angeben.
-Darüber hinaus MUSS in `CapabilityStatement.instantiates` die Canonical URL des nachfolgenden CapabilityStatement in der jeweiligen CapabilityStatement Instanz angegeben werden.
-
-Das CapabilityStatement der Instanz MUSS alle Funktionalitäten auflisten, die im folgenden CapabilityStatement mit "SHALL" gekennzeichnet sind. Das CapabilityStatement KANN darüber hinaus die mit "MAY" gekennzeichneten Funktionalitäten, sowie weitere Funktionalitäten auflisten, sofern diese in der Instanz implementiert wurden.
-
-Die Verwendung der [CapabilityStatement-Expectation](https://hl7.org/fhir/R4/extension-capabilitystatement-expectation.html)-Extension ist im CapabilityStatement der Server-Instanz nicht erforderlich.
-
-## CapabilityStatement (Requirement) ISiK
-
-Canonical: ```https://gematik.de/fhir/isik/CapabilityStatement/ISiKCapabilityStatementBasisServer```
-
-[Link Simplifier Profil Übersicht](https://gematik.de/fhir/isik/CapabilityStatement/ISiKCapabilityStatementBasisServer)
-
-{{render:https://gematik.de/fhir/isik/CapabilityStatement/ISiKCapabilityStatementBasisServer}}
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte.md
deleted file mode 100644
index ca0a1ab7..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte.md
+++ /dev/null
@@ -1,3 +0,0 @@
-# Datenobjekte
-
-In den folgenden Unterkapiteln werden die ISiK-Datenobjekte und ihre FHIR-Spezifikation beschrieben.
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Abrechnungsfall.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Abrechnungsfall.md
deleted file mode 100644
index 5a6923d2..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Abrechnungsfall.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Abrechnungsfall [(Account)](https://hl7.org/fhir/R4/account.html)
-
----
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_AllergieUnvertraeglichkeit.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_AllergieUnvertraeglichkeit.md
deleted file mode 100644
index a8d6d731..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_AllergieUnvertraeglichkeit.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Allergie/Unverträglichkeit [(AllergyIntolerance)](https://hl7.org/fhir/R4/allergyintolerance.html)
-
----
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Angehoeriger.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Angehoeriger.md
deleted file mode 100644
index 0e3134bd..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Angehoeriger.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Angehöriger [(RelatedPerson)](https://hl7.org/fhir/R4/relatedperson.html)
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_BerichtSubsystem.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_BerichtSubsystem.md
deleted file mode 100644
index 6fc0e5aa..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_BerichtSubsystem.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Bericht aus Subsystemen [(Composition)](https://hl7.org/fhir/R4/composition.html)
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Binary.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Binary.md
deleted file mode 100644
index 6ff591a2..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Binary.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Binary [(Binary)](https://hl7.org/fhir/R4/binary.html)
-
----
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_CodeSystem.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_CodeSystem.md
deleted file mode 100644
index 0776ee2f..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_CodeSystem.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Katalog [(CodeSystem)](https://hl7.org/fhir/R4/codesystem.html)
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Diagnose.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Diagnose.md
deleted file mode 100644
index 3af33291..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Diagnose.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Diagnose [(Condition)](https://hl7.org/fhir/R4/condition.html)
-
----
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Kontakt.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Kontakt.md
deleted file mode 100644
index 11fb42dc..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Kontakt.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Kontakt/Fall [(Encounter)](https://hl7.org/fhir/R4/encounter.html)
-
----
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Lebenszustand.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Lebenszustand.md
deleted file mode 100644
index b756f662..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Lebenszustand.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Spezifische Lebenszustände [(Observation)](https://hl7.org/fhir/R4/observation.html)
-
----
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Observation.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Observation.md
deleted file mode 100644
index ef038dbb..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Observation.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Observation [(Observation)](https://hl7.org/fhir/R4/observation.html)
-
----
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Organisation.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Organisation.md
deleted file mode 100644
index 08f68d5e..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Organisation.md
+++ /dev/null
@@ -1,5 +0,0 @@
-## Organisation [(Organization)](https://hl7.org/fhir/R4/organization.html)
-
-Die nachfolgenden Festlegungen spezifizieren die Abbildung von Minimalanforderungen für die Bereitstellung von Daten zur Aufbauorganisation im Rahmen von ISiK.
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Patient.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Patient.md
deleted file mode 100644
index dce283c8..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Patient.md
+++ /dev/null
@@ -1,5 +0,0 @@
-## Patient [(Patient)](https://hl7.org/fhir/R4/patient.html)
-
-Die nachfolgenden Festlegungen spezifizieren die Abbildung von Minimalanforderungen für die Bereitstellung von administrativen Patientendaten im Rahmen des Bestätigungsverfahrens der gematik.
-
----
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_PersonImGesundheitsberuf.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_PersonImGesundheitsberuf.md
deleted file mode 100644
index 301b4599..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_PersonImGesundheitsberuf.md
+++ /dev/null
@@ -1,4 +0,0 @@
-## PersonImGesundheitsberuf [(Practitioner)](https://hl7.org/fhir/R4/practitioner.html)
-
----
-
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Prozedur.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Prozedur.md
deleted file mode 100644
index 96bc25b7..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Prozedur.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Prozedur [(Procedure)](https://hl7.org/fhir/R4/procedure.html)
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Standort.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Standort.md
deleted file mode 100644
index e86419bb..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Standort.md
+++ /dev/null
@@ -1,5 +0,0 @@
-## Standort [(Location)](https://hl7.org/fhir/R4/location.html)
-
-Die nachfolgenden Festlegungen spezifizieren die Abbildung von Minimalanforderungen für die Bereitstellung von Standortdaten im Rahmen von ISiK.
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Subscription.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Subscription.md
deleted file mode 100644
index df6721c6..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Subscription.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Subscription patient-merge [(R5 Backport Subscription)](https://hl7.org/fhir/uv/subscriptions-backport/components.html)
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_ValueSet.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_ValueSet.md
deleted file mode 100644
index be3423c6..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_ValueSet.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## ValueSet [(ValueSet)](https://hl7.org/fhir/R4/valueset.html)
-
----
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Versicherungsverhaeltnis.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Versicherungsverhaeltnis.md
deleted file mode 100644
index 87ae4868..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Versicherungsverhaeltnis.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Versicherungsverhältnis [(Coverage)](https://hl7.org/fhir/R4/coverage.html)
-
----
diff --git a/ImplementationGuide/markdown/DecisionLog.md b/ImplementationGuide/markdown/DecisionLog.md
deleted file mode 100644
index 3cfd3c33..00000000
--- a/ImplementationGuide/markdown/DecisionLog.md
+++ /dev/null
@@ -1,62 +0,0 @@
-# Decision Log
-
-
-7.6.2024
-* Problem: Die Übergreifende Definition der Suchparameter ist problematisch, da nur im Kontext des Tests definiert
-* Lösung: Anpassung der Definition in Bezug auf bestätigungsrelevantes System. Inklusive Vorgabe zu spezifischen MS-Definitionen . Weitere Klärung in Bezug auf Testszenarien mit Erläuterung zu: 1) Implikationen für MS-Flags, 2) Nutzung von data-absent-reason. Die Data-Absent-Reason soll nicht allgemein genutzt werden können, um Testfällen aufzuweichen.
-
-18.03.2024
-* Problem: Auswahl der Suchparameter für Organisation und Standort
-*Lösung: Die Suchparameter Liste wurde geprüft in Hinblick auf naheligende Suchabfragen rund um Organisation und Standort (Location). In Bezug auf Standort wurden vorerst nicht berücksichtigt die Suchparameter: "endpoint", konkrete "address"-Paramter - z.B. address-city etc. -, "mode" und "name"
-
-11.3.2024
-* Problem: Zum Kontext des Problems rund um spezifische Profile für Versicherten-IDs für GKV und PKV siehe https://chat.fhir.org/#narrow/stream/179183-german-.28d-a-ch.29/topic/Community-Feedback.20zum.20PKV-Identifier (bzw. PTData-718)
-VersichertenId-GKV
-* Lösung: siehe https://github.com/gematik/spec-ISiK-Basismodul/pull/382
-
-
-Datum 27.02.2024
-* Problem: Die MUSS-Anforderungen im Kontext von ISIKKatalog scheinen zu umfassend zu sein.
-* Lösung: Schwächung der Anforderungen für das Profil als ganzes:
- * Ressource ISIKKatalog als optional kennzeichnen (im Capability Statement). Alle anderen Suchparameter entfernen - genauso für IG. Nur für diese bleiben Test-Cases (optional) erhalten.
- * Nur die Suchparameter "_id" Und "url" sind MUSS-Anforderungen (auch nur, wenn die Ressource optional unterstützt wird), da ein bekanntes Codesystem abrufbar sein sollte, wenn die Ressource an sich unterstützt wird.
- *Anmerkungen und MUST-SUpport Felder bleiben unberührt (SOLL).
-
-----
-Version Technical Correction 3.0.4
-
-* Problem: In der [Extension Abrechnungsart](http://fhir.de/StructureDefinition/ExtensionAbrechnungsDiagnoseProzedur) ist eine eindeutige Zuweisung zwischen Use und Referenz nicht möglich aufgrund der Kardinalität von Use - (vergleiche ANFISK-206)
- * Option zur Lösung:
- * Die Extension sollte in ISiK auf 0..* gesetzt werden
- * In den Basisprofilen sollte die Extension angepasst werden, sodass Use auf 0..1 gesetzt wird
- * ggf. erneute Prüfung der Codes unter "Use" prüfen
-
-
-----
-Version: Technical Correction 3.0.2
-
-Datum: 11.12.2023
-
-* Problem: Das Datenobjekt RelatedPerson sollte einen optionalen Suchparameter enthalten für .address, da das Element ein MS-Flag besitzt.
- * Option A: Hinzufügen optionaler Suchparameter für die UCs:
- * Suchabfragen von Angehörigen mit Hilfe der Adresse
- * Suchabfragen von Angehörigen mit Hilfe der Adresse unter Angabe der Stadt
- * Suchabfragen von Angehörigen mit Hilfe der Adresse unter Angabe des Ländercodes
- * Suchabfragen von Angehörigen mit Hilfe der Adresse unter Angabe der Postleihzahl
- * Option B (ggf. mit Nennung der Risiken): Keine Änderung.
- * Risiko: könnte ggf. zu Abweichung bei den oben gelisteten Abfragen führen, bei Implementierung abweichender Custom-Suchparameter.
- * Entscheidung: Option A - umgesetzt hier: Add new optional SearchParameter for RelatedPerson.address - https://github.com/gematik/spec-ISiK-Basismodul/pull/345/commits/beca71aaae70538f52f934a072928e93d23fd6fd
-
- ----
-
-Version: 3.0.1
-
-Datum: 05.12.2023
-
-* Problem: SNOMED Code (103693007|Diagnostic procedure) zur Codierung einer Prozeduren-Kategorie wurde zurückgezogen.
- * Option A (ggf. mit Nennung der Risiken): Der obsolete Code wird ersetzt (165197003|Diagnostic assessment), um zu verhindern, dass Terminologieserver diesen nicht verarbeiten können.
- * Risiko: Ein Breaking Change wird eingeführt.
- * Option B (ggf. mit Nennung der Risiken): Der obsolete Code wird nicht angepasst, um einen Breaking Change zu vermeiden, mit dem Risiko, dass Terminologieserver diesen nicht verarbeiten können.
- * Entscheidung: Option A - umgesetzt hier: obsoleter SNOMED Code ersetzt: https://github.com/gematik/spec-ISiK-Basismodul/pull/322/commits/d72f3a08a41b999074b4f33db299d5d71cd04be9
-
-
diff --git a/ImplementationGuide/markdown/Diagnose/Diagnose_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/Diagnose/Diagnose_AnmerkungenZuDenMustSupportFeldern.md
deleted file mode 100644
index 387999f6..00000000
--- a/ImplementationGuide/markdown/Diagnose/Diagnose_AnmerkungenZuDenMustSupportFeldern.md
+++ /dev/null
@@ -1,67 +0,0 @@
-### Anmerkungen zu den Must-Support-Feldern
-
-### `Condition.clinicalStatus`
-
-**Bedeutung:** Der kodierte klinische Status der Diagnose MUSS, sofern vorhanden, angegeben werden, da die Interpretation der Diagnose davon abhängt ob diese 'aktiv' ist oder einen anderen Status aufweist. Alle in einem System möglichen Clinical-Status-Werte MÜSSEN, sofern vorhanden, über FHIR korrekt repräsentiert werden, können mindestens jedoch die Status-Werte "active" und "inactive" unterstützen.
-
-**Hinweise:**
-
-[FHIRPath Constraints seitens der FHIR-Kernspezifikation](https://www.hl7.org/fhir/R4/condition.html#invs) rund um Condition.clinicalStatus sind zu beachten.
-
-### `Condition.code.coding`
-
-**Bedeutung:** Kodierte Diagnose. Die Kodierung KANN nach den Vorgaben des BfArM per [ICD-10GM](https://www.bfarm.de/DE/Kodiersysteme/Klassifikationen/ICD/ICD-10-GM/_node.html) kodiert werden. Weiterhin sind folgende Kodiersysteme u.a. auf Basis von Empfehlungen des BfArM zulässig:
- - [SNOMED CT](https://www.snomed.org)
- - [Alpha-ID](https://www.bfarm.de/DE/Kodiersysteme/Terminologien/Alpha-ID-SE/_node.html)
- - [Orpha-Kennnummer](https://www.orpha.net/consor/cgi-bin/index.php?lng=DE)
-
-### `Condition.code.text`
-
-**Bedeutung:** Freitextdiagnose
-
-**Hinweise:**
-
-Die Freitextdiagnose darf nur alleinstehend angegeben werden, solange keine kodierte Diagnose vorliegt.
-
-### `Condition.code.coding:ICD-10-GM.extension:Seitenlokalisation`
-
-**Hinweise:** Angaben zur ICD-Seitenlokalisation ("R", "L", "B") müssen vom Code abgetrennt und in der Extension angegeben werden.
-
-### `Condition.code.coding:ICD-10-GM.extension:Mehrfachcodierungs-Kennzeichen`
-
-**Hinweise:** ICD-Mehfachcodierungs-Kennzeichen ("†", "\*", "!") müssen vom Code abgetrennt und in der Extension angegeben werden.
-
-### `Condition.code.coding:ICD-10-GM.extension:Diagnosesicherheit`
-
-**Hinweise:** Angaben zur ICD-Diagnosesicherheit ("A", "G", "V", "Z") müssen vom Code abgetrennt und in der Extension angegeben werden.
-
-### `Condition.subject`
-
-**Bedeutung:** Ein Patientenbezug der Diagnose MUSS stets zum Zwecke der Nachvollziehbarkeit und Datenintegrität vorliegen.
-
-### `Condition.encounter`
-
-**Bedeutung:** Der Fallbezug einer Diagnose MUSS stets zum Zwecke der Nachvollziehbarkeit und Datenintegrität vorliegen.
-
-**Hinweise:**
-
-Eine Verlinkung der Referenz auf den dazugehörigen Kontakt MUSS auf die Ebene des Abteilungskontaktes (entsprechend ISiKKontaktGesundheitseinrichtung) erfolgen.
-Bei der Auswahl des Kontaktes ist zu beachten, dass mehrere Encounter-Ressourcen mit identischen Aufnahmenummer-Identifiern existieren können (Abbildung Vor- und nachstationäre Kontakte).
-
-### `Condition.recordedDate`
-
-**Bedeutung:** Das Dokumentationsdatum der Diagnose MUSS zu Qualitätssicherungszwecken angegeben werden. Dies ist das fachliche Dokumentationsdatum, nicht zu verwechseln mit der technischen Anlage des Datensatzes im Primärsystem. Diese beiden Daten können jedoch identisch sein.
-
-**Hinweise:**
-
-Das Recorded Date MUSS mindestens auf den Monat genau angegeben werden (vgl. FHIRPath Constraint rec-1)
-
-### `Condition.note`
-
-**Bedeutung:** Weitere optionale Freitext-Notizen bezogen auf die Diagnose.
-
-### `Condition.extension:ReferenzPrimaerdiagnose`
-
-**Bedeutung:** Bei mehrfachkodierten ICD-Diagnosen (z.B. Kreuz-Stern-Notation) muss die Sekundär- auf die Primärdiagnose verlinkt werden
-
----
diff --git a/ImplementationGuide/markdown/Diagnose/Diagnose_Beispiele.md b/ImplementationGuide/markdown/Diagnose/Diagnose_Beispiele.md
deleted file mode 100644
index cf1694f7..00000000
--- a/ImplementationGuide/markdown/Diagnose/Diagnose_Beispiele.md
+++ /dev/null
@@ -1,5 +0,0 @@
-### Beispiel
-
-Valides Minimalbeispiel Diagnose:
-
-{{json:example-condition-kreuz-stern-primaer}}
diff --git a/ImplementationGuide/markdown/Diagnose/Diagnose_Interaktionen.md b/ImplementationGuide/markdown/Diagnose/Diagnose_Interaktionen.md
deleted file mode 100644
index 61376a0b..00000000
--- a/ImplementationGuide/markdown/Diagnose/Diagnose_Interaktionen.md
+++ /dev/null
@@ -1,77 +0,0 @@
-### Interaktionen
-
-Für die Ressource Condition MUSS die REST-Interaktion "READ" implementiert werden.
-
-Folgende Suchparameter sind für das Bestätigungsverfahren relevant, auch in Kombination:
-
-1. Der Suchparameter "_id" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Condition?_id=test```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "_id" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Parameters for all resources"](https://hl7.org/fhir/R4/search.html#all).
-
-1. Der Suchparameter "clinical-status" MUSS, sofern das Element unterstützt wird (siehe in der Profilstruktur Festlegung zu bedingtem MS), unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Condition?clincial-status=active```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Condition.clinicalStatus" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
- Dieser Suchparameter ist für die Umsetzung des IHE QEDm Profils verpflichtend.
-
-1. Der Suchparameter "patient" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Condition?patient=Patient/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Condition.subject" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
- Dieser Suchparameter ist für die Umsetzung des IHE QEDm Profils verpflichtend.
-
-1. Der Suchparameter "subject" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Condition?subject=Patient/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Condition.subject" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-1. Der Suchparameter "encounter" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Condition?encounter=Patient/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Condition.encounter" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-1. Der Suchparameter "recorded-date" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Condition?recorded-date=2015-01-01T12:00:23Z+02:00```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Condition.recordedDate" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Date Search"](https://hl7.org/fhir/R4/search.html#date).
-
-1. Der custom Suchparameter "related" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Condition?related=Condition/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Condition.related" finden sich im [Leitfaden Basis DE (R4) - Abschnitt "Diagnosen (Condition) - Doppel-/Mehrfachkodierte ICD-Codes"](https://ig.fhir.de/basisprofile-de/1.2.0/Ressourcen-DiagnosenCondition.html).
-
-1. Der Suchparameter "category" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Condition?category=http://hl7.org/fhir/ValueSet/condition-category|problem-list-item```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "category" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
- Dieser Suchparameter ist für die Umsetzung des IHE QEDm Profils verpflichtend.
-
----
diff --git a/ImplementationGuide/markdown/Diagnose/Diagnose_Kompatibilitaet.md b/ImplementationGuide/markdown/Diagnose/Diagnose_Kompatibilitaet.md
deleted file mode 100644
index ea07d9a2..00000000
--- a/ImplementationGuide/markdown/Diagnose/Diagnose_Kompatibilitaet.md
+++ /dev/null
@@ -1,9 +0,0 @@
-### Kompatibilität
-
-
-Für das Profil ISiKDiagnose wird eine Kompatibilität mit folgenden Profilen angestrebt; allerdings kann nicht sichergestellt werden, dass Instanzen, die gegen ISiKDiagnose valide sind, auch valide sind gegen:
-* [das Profil ProfileConditionDiagnose der Medizininformatik-Initative](https://www.medizininformatik-initiative.de/fhir/core/modul-diagnose/StructureDefinition/Diagnose)
-* [das Profil KBV_PR_Base_Condition_Diagnosis der KBV](https://fhir.kbv.de/StructureDefinition/KBV_PR_Base_Condition_Diagnosis)
-
-Hinweise zu Inkompatibilitäten können über die [Portalseite](https://service.gematik.de/servicedesk/customer/portal/16) gemeldet werden.
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Diagnose/Diagnose_Motivation.md b/ImplementationGuide/markdown/Diagnose/Diagnose_Motivation.md
deleted file mode 100644
index e21b7a18..00000000
--- a/ImplementationGuide/markdown/Diagnose/Diagnose_Motivation.md
+++ /dev/null
@@ -1,10 +0,0 @@
-### Motivation
-
-Die Möglichkeit, auf eine Übersicht der Diagnosen eines Patienten zuzugreifen, Patienten anhand ihrer Diagnose zu suchen oder zu prüfen, ob eine konkrete Diagnose bei einem Patienten vorliegt, sind wichtige Funktionen im klinischen Behandlungsablauf.
-
-In FHIR werden Diagnosen mit der [Condition](https://hl7.org/fhir/R4/condition.html)-Ressource repräsentiert.
-
-Da die Diagnosen in klinischen Primärsystemen in der Regel in ICD-10-codierter Form vorliegen, fordert ISiK in erster Linie diese Form des Austausches.
-Falls eine Diagnose zwar dokumentiert, aber noch nicht codiert wurde (z.B. wenn die Kodierung erst nach der Entlassung erfolgt), ist alternativ eine Repräsentation als Freitext-Diagnose möglich.
-
----
diff --git a/ImplementationGuide/markdown/Diagnose/Diagnose_Profil.md b/ImplementationGuide/markdown/Diagnose/Diagnose_Profil.md
deleted file mode 100644
index 0fa2e7a3..00000000
--- a/ImplementationGuide/markdown/Diagnose/Diagnose_Profil.md
+++ /dev/null
@@ -1,35 +0,0 @@
-### Profil
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKDiagnose' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKDiagnose, hybrid}}
-
----
-
-**Constraints**
-
-Folgende FHIRPath-Constraints sind im Profil zu beachten:
-
-@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKDiagnose' for differential.element.constraint select key, severity, human, expression```
-
----
-
-**Terminology Bindings**
-
-@```
-from StructureDefinition
-where url in ('https://gematik.de/fhir/isik/StructureDefinition/ISiKDiagnose' )
-for differential.element
-select
-Path: path,
-join binding.where(valueSet.exists())
-{
- Name: valueSet.substring((9 + valueSet.indexOf('ValueSet/'))),
- Strength: strength,
- URL: valueSet
-}
-```
-
----
diff --git a/ImplementationGuide/markdown/Einfuehrung.md b/ImplementationGuide/markdown/Einfuehrung.md
deleted file mode 100644
index 745ac5c9..00000000
--- a/ImplementationGuide/markdown/Einfuehrung.md
+++ /dev/null
@@ -1,47 +0,0 @@
-
-
-----
-Version: 4.0.1
-
-Datum: 21.11.2024
-
-Status: Active
-
-Realm: Deutschland
-
-
-
-Abgekündigte Versionen oder Zwischenveröffentlichungen der Implementierungsleitfäden finden Sie unter: https://gematik.github.io/spec-ISiK-Basismodul/index.html
-
-
-----
-
-
-# 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/ImplementationGuide/markdown/Katalog/CodeSystem_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/Katalog/CodeSystem_AnmerkungenZuDenMustSupportFeldern.md
deleted file mode 100644
index d1ead5b0..00000000
--- a/ImplementationGuide/markdown/Katalog/CodeSystem_AnmerkungenZuDenMustSupportFeldern.md
+++ /dev/null
@@ -1,39 +0,0 @@
-### Anmerkungen zu Must-Support-Feldern
-
-### `CodeSystem.url`
-
-**Bedeutung:** Eindeutige Url zur Identifizierung des CodeSystems. Absolute Url sind zu bevorzugen.
-
-**Hinweise:** OIDs SOLLTEN als weitere Identifier des CodeSystems verwendet werden. In jedem Fall SOLLTE ein Canonical Url vergeben werden.
-
-### `CodeSystem.version`
-
-**Bedeutung:** Version des CodeSystems
-
-**Hinweise:** Jede Änderung des CodeSystems MUSS eine Änderung in der Version des CodeSystems und gebundenen ValueSets nach sich ziehen. Die Versionierung SOLLTE auf Basis von [Semantic Versioning](https://semver.org) basieren.
-
-### `CodeSystem.name`
-
-**Bedeutung:** Maschinenlesbarer Name des CodeSystems
-
-**Hinweise:** Der Constraint [cps-0](https://www.hl7.org/fhir/R4/codesystem.html#invs) ist hierbei zu beachten.
-
-### `CodeSystem.status`
-
-**Bedeutung:** Indikation, ob das CodeSystem in aktiver Verwendung ist.
-
-**Hinweise:** Alle in einem System möglichen Status-Werte MÜSSEN über FHIR korrekt repräsentiert werden. KÖNNEN mindestens jedoch die Status-Werte "active" und "retired". Deren korrekte Abbildung wird im Rahmen des Bestätigungsverfahrens überprüft.
-
-### `CodeSystem.content`
-
-**Bedeutung:** Angabe, ob es sich um eine vollständige Repräsentation des CodeSystems oder nur um einen Auszug handelt.
-
-**Hinweise:** Alle in einem System möglichen Status-Werte müssen über FHIR korrekt repräsentiert werden können, mindestens jedoch die Status-Werte "fragment" und "complete". Deren korrekte Abbildung wird im Rahmen des Bestätigungsverfahrens überprüft.
-
-### `CodeSystem.concept`
-
-**Bedeutung:** Angabe der Konzepte, aus denen sich das CodeSystem zusammensetzt.
-
-**Hinweise:** Es MUSS mindestens ein Code und ein Anzeigetext spezifiziert werden.
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Katalog/CodeSystem_Beispiele.md b/ImplementationGuide/markdown/Katalog/CodeSystem_Beispiele.md
deleted file mode 100644
index be3c3a7a..00000000
--- a/ImplementationGuide/markdown/Katalog/CodeSystem_Beispiele.md
+++ /dev/null
@@ -1,5 +0,0 @@
-### Beispiele
-
-Valides Minimalbeispiel CodeSystem:
-
-{{json:CodeSystemExample}}
diff --git a/ImplementationGuide/markdown/Katalog/CodeSystem_Interaktionen.md b/ImplementationGuide/markdown/Katalog/CodeSystem_Interaktionen.md
deleted file mode 100644
index bec9df1b..00000000
--- a/ImplementationGuide/markdown/Katalog/CodeSystem_Interaktionen.md
+++ /dev/null
@@ -1,23 +0,0 @@
-### Interaktionen
-
-Für die Ressource CodeSystem MUSS die REST-Interaktion "READ" implementiert werden, falls die Resource CodeSystem umgesetzt wird.
-
-Folgende Suchparameter sind für das Bestätigungsverfahren relevant, auch in Kombination:
-
-1. Der Suchparameter "_id" MUSS unterstützt werden, falls die Resource CodeSystem umgesetzt wird:
-
- Beispiele:
-
- ```GET [base]/CodeSystem?_id=103270```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "_id" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Parameters for all resources"](https://hl7.org/fhir/R4/search.html#all).
-
-1. Der Suchparameter "url" MUSS unterstützt werden, falls die Resource CodeSystem umgesetzt wird:
-
- Beispiele:
-
- ```GET [base]/CodeSystem?url=http://example.org/fhir/CodeSystem/test```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "CodeSystem.url" finden sich in der [FHIR-Basisspezifikation - Abschnitt "uri"](https://www.hl7.org/fhir/R4/search.html#uri).
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Katalog/CodeSystem_Kompatibilitaet.md b/ImplementationGuide/markdown/Katalog/CodeSystem_Kompatibilitaet.md
deleted file mode 100644
index f76cfeaf..00000000
--- a/ImplementationGuide/markdown/Katalog/CodeSystem_Kompatibilitaet.md
+++ /dev/null
@@ -1,3 +0,0 @@
-### Kompatibilität
-
-Für das Profil ISiKCodeSystem wurde bis zum Zeitpunkt der Veröffentlichung kein Abgleich der Kompatibilität zu anderen Profilen (der KBV und der Medizininformatik-Initiative) durchgeführt.
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Katalog/CodeSystem_Motivation.md b/ImplementationGuide/markdown/Katalog/CodeSystem_Motivation.md
deleted file mode 100644
index 1eb43f44..00000000
--- a/ImplementationGuide/markdown/Katalog/CodeSystem_Motivation.md
+++ /dev/null
@@ -1,15 +0,0 @@
-### Motivation
-
-ISiK erlaubt in diversen Kontexten die Erweiterung der Kodierung durch Krankenhaus-/System-interne Kodierungen. Das Profil ISiKKatalog (CodeSystem) als Profil erlaubt die Repräsentation der dazugehörigen Codes und Display-Werte.
-
-Eine maschinenlesbare Repräsentation dieser Kodierungen erlaubt es Clients, dazugehörige Anzeigetext und Definitionen zu verarbeiten.
-
-Ein Codesystem eignet sich auch dazu, auf dessen Basis definierte [ValueSets zu expandieren](https://hl7.org/fhir/R4/valueset-operation-expand.html).
-Da ISiKValueSet expandierte Valuesets vorsieht, ist eine dynamische Expansion in der Regel nicht erforderlich.
-Darüber hinausgehend ist ein Use Case im Kontext der Katalogabfrage folgender: Ein Client möchte eine Expansion neu generieren (z.B. mit anderen Expansionen-Parametern), um das ValueSet beispielsweise in einer anderen Sprache auszugeben.
-
-### Normativer Status und Bestätigung
-
-Dieses Profil MUSS im Rahmen der Bestätigung NICHT unterstützt werden. Falls das Profil unterstützt werden soll, MÜSSEN die hier definierten Festlegungen greifen (auch im Bestätigungsverfahren).
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Katalog/CodeSystem_Profil.md b/ImplementationGuide/markdown/Katalog/CodeSystem_Profil.md
deleted file mode 100644
index c90560a2..00000000
--- a/ImplementationGuide/markdown/Katalog/CodeSystem_Profil.md
+++ /dev/null
@@ -1,8 +0,0 @@
-### FHIR-Profil
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKCodeSystem' select Name: name, Canonical: url
-```
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKCodeSystem, hybrid}}
-
----
diff --git a/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_AnmerkungenZuDenMustSupportFeldern.md
deleted file mode 100644
index 83aaaacb..00000000
--- a/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_AnmerkungenZuDenMustSupportFeldern.md
+++ /dev/null
@@ -1,37 +0,0 @@
-### Anmerkungen zu den Must-Support Feldern
-
-### `Encounter.status`
-
-**Bedeutung:** Der Status MUSS insbesondere zur Differenzierung von abgeschlossenen und derzeitig noch aktiven Kontakten angegeben werden. Alle in einem System möglichen Status-Werte müssen über FHIR korrekt repräsentiert werden. Es KÖNNEN jedoch mindestens die Status-Werte "in-progress", "finished" und "cancelled" unterstützt werden. Deren korrekte Abbildung wird im Rahmen des Bestätigungsverfahrens überprüft.
-
-**Hinweise:** Siehe Beschreibung in der [FHIR Kernspezifikation](https://hl7.org/fhir/R4/encounter-definitions.html#Encounter.status)
-
-### `Encounter.class`
-
-**Bedeutung:** Alle Encounter MÜSSEN eindeutig kategorisiert werden können, sodass eine Filterung pro Typ möglich ist.
-
-**Hinweise:** Verpflichtende Kodierung per [HL7 v3 Value Set ActEncounterCode](https://hl7.org/fhir/R4/v3/ActEncounterCode/vs.html), um eine internationale Kompatibilität aufrecht zu erhalten.
-
-### `Encounter.type`
-
-**Bedeutung:** Angabe vom Typ des Kontaktes. Alle Möglichkeiten eines Einrichtungskontaktes nach SGB V sind vorhanden.
-
-### `Encounter.subject`
-
-**Bedeutung:** Ein Patientenbezug des Falls MUSS stets zum Zwecke der Nachvollziehbarkeit und Datenintegrität vorliegen.
-
-### `Encounter.period`
-
-**Bedeutung:** Der Rahmen des Kontaktes MUSS zur zeitlichen Einordnung angeben werden.
-
-**Hinweise:** Es ist der FHIRPath Constraint ISiK-enc-1 zu beachten. Siehe [JSON Repräsentation FHIR Profil ISiK Encounter](https://simplifier.net/IsiK/ISiKKontaktGesundheitseinrichtung/~json).
-
-### `Encounter.location`
-
-**Bedeutung:** Falls Details zum Ort, an dem der Kontakt stattfindet, vorliegen, KÖNNEN diese in einer beliebigen Detailtiefe angegeben werden.
-
-### `Encounter.serviceProvider`
-
-**Bedeutung:** Falls Details zur verantwortlichen Organisationeinheit vorliegen, KÖNNEN diese in einer beliebigen Detailtiefe angegeben werden.
-
----
diff --git a/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Beispiele.md b/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Beispiele.md
deleted file mode 100644
index d78c921d..00000000
--- a/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Beispiele.md
+++ /dev/null
@@ -1,5 +0,0 @@
-#### Beispiele
-
-Ein Beispiel für das Profil ISiKKontaktGesundheitseinrichtung:
-
-{{json:Resources/fsh-generated/resources/Encounter-Fachabteilungskontakt.json}}
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Interaktionen.md b/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Interaktionen.md
deleted file mode 100644
index 7a031dcb..00000000
--- a/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Interaktionen.md
+++ /dev/null
@@ -1,118 +0,0 @@
-### Interaktionen
-
-Für die Ressource Encounter MUSS die REST-Interaktion "READ" implementiert werden.
-
-Folgende Suchparameter sind für das Bestätigungsverfahren relevant, auch in Kombination:
-
-1. Der Suchparameter "_id" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Encounter?_id=103270```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "_id" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Parameters for all resources"](https://hl7.org/fhir/R4/search.html#all).
-
-1. Der Suchparameter "identifier" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Encounter?identifier=http://test.krankenhaus.de/fhir/sid/fallnr|123456```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Encounter.identifier" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "status" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Encounter?status=finished```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Encounter.status" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "class" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Encounter?class=IMP```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Encounter.class" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "type" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Encounter?type=http://fhir.de/CodeSystem/kontaktart-de|stationaer```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Encounter.type" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "subject" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Encounter?subject=Patient/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Encounter.subject" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-1. Der Suchparameter "patient" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Encounter?patient=Patient/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Encounter.subject" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
- Dieser Suchparameter ist für die Umsetzung des IHE QEDm Profils verpflichtend.
-
-1. Der Suchparameter "account" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Encounter?account=Account/123```
-
- ```GET [base]/Encounter?account:identifier=https://example.org/fhir/sid/abrechnungsfallnr|123456```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Encounter.account" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-1. Der Suchparameter "date" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Encounter?date=eq2020-26-10```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Encounter.period" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Date Search"](https://hl7.org/fhir/R4/search.html#date). Bei der Formulierung der Suche sollten die Vorgaben aus der [Definition der Such-Prefixe](https://hl7.org/fhir/R4/search.html#prefix) - und hier insbesondere die Unterschiede zwischen "lt" und "eb" bzw. "gt" und "sa" - beachtet werden.
-
- Dieser Suchparameter ist für die Umsetzung des IHE QEDm Profils verpflichtend.
-
-1. Der Suchparameter "date-start" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Encounter?date-start=lt2020-26-10```
-
- Anwendungshinweise: Bei diesem custom Suchparameter handelt es sich um eine Lösung, die aus einer [abweichenden FHIR-Version (R5)](https://hl7.org/fhir/R5/encounter-search.html#Encounter-date-start) stammt. Weitere Informationen zur Suche nach "Encounter.period" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Date Search"](https://hl7.org/fhir/R4/search.html#date).
-
-1. Der Suchparameter "end-date" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Encounter?end-date=lt2020-26-10```
-
- Anwendungshinweise: Bei diesem custom Suchparameter handelt es sich um eine Lösung, die aus einer [abweichenden FHIR-Version (R5)](https://hl7.org/fhir/R5/SearchParameter/Encounter-end-date) stammt. Weitere Informationen zur Suche nach "Encounter.period" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Date Search"](https://hl7.org/fhir/R4/search.html#date).
-
-1. Der Suchparameter "location" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Encounter?location=Location/test```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Encounter.location" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-1. Der Suchparameter "service-provider" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Encounter?service-provider=Organization/test```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Encounter.serviceProvider" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
----
-
diff --git a/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Kompatibilitaet.md b/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Kompatibilitaet.md
deleted file mode 100644
index 549ee07c..00000000
--- a/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Kompatibilitaet.md
+++ /dev/null
@@ -1,8 +0,0 @@
-### Kompatibilität
-
-Für das Profil ISiKKontaktGesundheitseinrichtung wird eine Kompatibilität mit folgenden Profilen angestrebt; allerdings kann nicht sichergestellt werden, dass Instanzen, die gegen ISiKKontaktGesundheitseinrichtung valide sind, auch valide sind gegen:
-* [Profil Kontakt mit einer Gesundheitseinrichtung der Medizininformatik-Initiative](https://www.medizininformatik-initiative.de/fhir/core/modul-fall/StructureDefinition/KontaktGesundheitseinrichtung)
-
-Hinweise zu Inkompatibilitäten können über die [Portalseite](https://service.gematik.de/servicedesk/customer/portal/16) gemeldet werden..
-
----
diff --git a/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Motivation.md b/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Motivation.md
deleted file mode 100644
index 4fbfa8be..00000000
--- a/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Motivation.md
+++ /dev/null
@@ -1,85 +0,0 @@
-### Motivation
-
-Informationen über die Besuche des Patienten entlang seines Behandlungspfades im Krankenhaus sind ein wichtiger Bestandteil des einrichtungsinternen Datenaustausches.
-Sie ermöglichen die Unterscheidung von stationären und ambulanten sowie aufgenommenen und entlassenen Patienten.
-Weiterhin ist aus den Besuchsinformationen der aktuelle Aufenthaltsort des Patienten (Fachabteilung, Station, Bettplatz) ermittelbar.
-Klinische Ressourcen werden in FHIR durch Verlinkung auf die Encounter-Ressource in einen Kontext zum Besuch gestellt. Dieser Kontext ist wichtig für die Steuerung von Zugriffsberechtigungen und Abrechnungsprozessen.
-
-
-Zu Beginn der meisten klinischen Workflows steht die Auswahl des Besuchskontextes. Dies geschieht bspw. durch das Suchen der Encounter-Ressource anhand von Eigenschaften wie Aufnahmenummer, Fallart oder Aufnahmedatum. Daraufhin werden die zutreffenden Suchergebnisse angezeigt und der gewünschte Besuch ausgewählt.
-
----
-
-#### Der Begriff "Fall" im Kontext von FHIR
-
-Wichtig ist die Herausstellung, dass "Besuch" und "Fall" wechselseitig keine synonyme Begriffe sind.
-
-Der Begriff "Fall" gruppiert im Sprachgebrauch verschiedene Konzepte, die in FHIR durch unterschiedliche Ressourcen repräsentiert werden:
-
-* **Aufenthalt/Besuch/Kontakt (Encounter):**
-Der stationäre Aufenthalt oder der ambulante Kontakt eines Patienten in einer Gesundheitseinrichtung wird in FHIR durch die Ressource Encounter abgebildet.
-
-* **Abrechnungsfall (Account):**
-Der Fall, im Sinne einer Gruppierung von medizinischen Leistungen, die in einem gemeinsamen Kontext abgerechnet werden, sind in FHIR durch die Ressource Account repräsentiert. Ein Abrechnungsfall kann mehrere Encounter umfassen (z.B. vorstationärer Besuch, stationärer Aufenthalt und nachstationäre Besuche)
-{{render:Material/Images/Encounter/Encounter-Modell-Abrechnung.png}}
-
-* **Medizinischer Fall (EpisodeOfCare):**
-Der medizinische Fall gruppiert Informationen, die im Kontext einer gemeinsamen (Dauer-)Diagnose stehen und wird in FHIR durch die EpisodeOfCare dargestellt.
-{{render:Material/Images/Encounter/Encounter-Modell-Medizinisch.png}}
-
----
-
-#### Der Begriff "Fall" im Kontext der Medizininformatik-Initiative
-In dem [von der Medizininformatik-Initiative zur Kontaktverfolgung (Infektionsketten) des Patienten entworfenen Modell](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide-backup/EinfachesAufbaumodell?version=current) wird der Encounter in drei verschiedenen Ebenen verwendet:
-
-* **Einrichtungskontakt:**
-Als Kontakt eines Patienten mit einer Einrichtung (z.B: Klinik) gruppiert mehrere Besuche bei einer Einrichtung als gemeinsamen Behandlungskontext.
-
-* **Abteilungskontakt:**
-Als Kontakt des Patienten mit einer Fachabteilung eines Krankenhauses (z.B. einer Ambulanz oder einer stationären Fachabteilung).
-
-* **Versorgungsstellenkontakt:**
-Als Kontakt des Patienten mit konkreten Servicestellen, wie z.B. Radiologie oder Endoskopie
-
-Zur Unterscheidung der verschiedenen Kontaktebenen wird in der MI-I eine Codierung in `Encounter.type` verwendet. Die Hierarchie der Encounter wird über die `Encounter.partOf`-Relation hergestellt. Ambulante Besuche werden in dem Modell derzeit noch nicht berücksichtigt.
-
-{{render:Material/Images/Encounter/Encounter-Modell-MII.png}}
-
----
-
-#### Der Begriff "Fall" im Kontext der ISiK-Spezifikation
-
-Für die derzeitige Ausbaustufe des ISiK Basismoduls werden alle zuvor genannten Sichtweise und Modelle berücksichtigt:
-
-{{render:Material/Images/Encounter/Encounter-Modelle.png}}
-
-Verpflichtend umzusetzen ist für die bestätigungsrelevanten Systeme der Account, im Sinne der Gruppierung einzelner Besuche, zu einem gemeinsamen (Abrechnungs-)Fall sowie der Encounter der Ebene "Abteilungskontakt" im Sinne des Modells der Medizininformatikinitiative.
-
-Herstellern steht es frei, weitere Ressourcen, wie zum Beispiel die EpisodeOfCare oder den Encounter, im Sinne des Einrichtungskontaktes bzw. des Versorgungsstellenkontaktes, zu implementieren.
-
-Wichtig sind dabei jedoch folgende Punkte zu beachten:
-
-* Encounter im ISiK-Kontext sind stets als "Abteilungskontakte", im Sinne der MI-I mit dem entsprechenden `Encounter.type`-Code, zu kennzeichnen.
-* Jegliche im ISiK-Basis-Modul, als auch in anderen ISiK-Modulen definierte Ressourcen, die über einen Encounter-Kontext verfügen, müssen auf einen ISiK-Encounter (Abteilungskontakt) referenzieren.
-{{render:Material/Images/Encounter/Encounter-Modell-ISiK.png}}
-
----
-
-#### Die Repräsentation der "Fall"-Nummer
-
-Die "Fall"-Nummer ist ein im Kontext der stationären Versorgung häufig verwendetes Vehikel, um (insbesondere in der HL7-V2-Kommunikation) mit einfachen Mitteln den Fallkontext medizinischer Dokumentationen herzustellen.
-
-In den meisten Fällen handelt es sich bei der "Fall"-Nummer um einen eindeutigen Identifier des Abrechnungsfalls.
-Im ISiK-Kontext ist die Fallnummer daher als Identifier des Accounts zu sehen und nicht geeignet, einen Encounter eindeutig zu identifizieren und damit den für FHIR-Ressourcen erforderlichen Encounter-Kontext zu etablieren.
-Es müssen zusätzliche Kriterien, wie z.B. Zeitraum(`Encounter.period`), Fallart (`Encounter.class`) oder Status (`Encounter.status`) berücksichtigt werden, um den korrekten Encounter zu finden.
-
-ISiK berücksichtigt jedoch die gängige Praxis, dass die Fallnummer als primäres Suchkriterium verwendet wird; auch von Systemen, die rein der medizinischen Versorgung dienen und keine Abrechnungsfunktionen implementieren.
-Um insbesondere Subsysteme von der Pflicht zu entbinden, die Account-Ressource zu implementieren, nur um Zugriff zur Fallnummer zu bekommen, ist das Mitführen des Account-Identifiers als logische Referenz auf den Account im Encounter verpflichtend. Die Fallnummer eines Encounters kann daher auch ohne Kenntnis des Accounts ermittelt werden.
-
-| Hinweis | Änderung gegenüber ISiK-Basis-Modul Stufe 1!|
-|---------|---------------------|
-| {{render:Material/Images/IG_Warning}} | Die Abbildung der Fallnummer als Identifier des Accounts ist abweichend von der im Basismodul Stufe 1 festgelegten Abbildung der Fallnummer als Identifier des Encounters. Diese Änderung ist erforderlich, da die Fallnummer nicht geeignet ist, einen Encounter eindeutig zu identifizieren. Der Encounter kann weiterhin einen von der Abrechnungsfallnummer unabhängigen Identifier enthalten (z.B. "Aufnahmenummer", Bewegungsnummer). Dieser identifiziert eineindeutig den jeweiligen Kontakt.|
-
-{{render:Material/Images/Encounter/Encounter-Modell-Fallnummer.png}}
-
----
diff --git a/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Profil.md b/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Profil.md
deleted file mode 100644
index 9ef05487..00000000
--- a/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Profil.md
+++ /dev/null
@@ -1,47 +0,0 @@
-### Profil
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKKontaktGesundheitseinrichtung' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKKontaktGesundheitseinrichtung, hybrid}}
-
-**Bei Abbildung von Versorgungsstellenkontakten**
-
-Es ist ein üblicher Fall, dass die Dauer eines Versorgungsstellenkontaktes die eines Abteilungskontaktes übersteigt. Ein Beispiel hierfür: Ein Patient bleibt im Bett (Versorgungsstellenkontakt), aber ein Fachabteilungswechsel geschieht, da die Diagnose über eine Fachabteilung (Onkologie) läuft, dann aber der Wechsel zur Fachabteilung Chirurgie (neuer Abteilungskontakt) notwendig wird.
-
-Für einen solchen Fall gilt:
-
-Im Falle eines Fachabteilungswechsels legt ein System einen neuen Abteilungskontakt an. Bestehende Versorgungsstellenkontakt SOLLEN nicht in ihrer Relation (.partOf) zum Abteilungskontakt modifiziert werden. Hingegen SOLL das System einen oder mehrere Versorgungsstellenkontakte erzeugen und mit dem neu angelegten Abteilungskontakt in Verbindung setzen.
-
-Hinweis: Ein Versorgungsstellenkontakt endet zugleich nicht notwendigerweise mit einem Fachabteilungswechsel.
-
----
-
-**Constraints**
-
-Folgende FHIRPath-Constraints sind im Profil zu beachten:
-
-@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKKontaktGesundheitseinrichtung' for differential.element.constraint select key, severity, human, expression```
-
-Weitere Hinweise zu den Abgrenzungen der Begrifflichkeiten Fall und Kontakt finden sie unter [Deutsche Basisprofile - Abschnitt Ambulanter/stationärer Fall / Kontakt (Encounter)](https://ig.fhir.de/basisprofile-de/1.2.0/Ressourcen-AmbulanterStationaererFall.html).
-
----
-
-**Terminology Bindings**
-
-@```
-from StructureDefinition
-where url in ('https://gematik.de/fhir/isik/StructureDefinition/ISiKKontaktGesundheitseinrichtung' )
-for differential.element
-select
-Path: path,
-join binding.where(valueSet.exists())
-{
- Name: valueSet.substring((9 + valueSet.indexOf('ValueSet/'))),
- Strength: strength,
- URL: valueSet
-}
-```
-
----
diff --git a/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_AnmerkungenZuDenMustSupportFeldern.md
deleted file mode 100644
index 8ae3ffbd..00000000
--- a/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_AnmerkungenZuDenMustSupportFeldern.md
+++ /dev/null
@@ -1,5 +0,0 @@
-### Anmerkungen zu den Must-Support-Feldern
-
-Es gelten die Festlegungen für {{pagelink:ImplementationGuide/markdown/Observation/Observation_AnmerkungenZuDenMustSupportFeldern.md, text:Observations}}.
-
----
diff --git a/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Beispiele.md b/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Beispiele.md
deleted file mode 100644
index d655c264..00000000
--- a/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Beispiele.md
+++ /dev/null
@@ -1,21 +0,0 @@
-### Beispiele
-
-Schwangerschaftsstatus:
-
-{{json:ISiKSchwangerschaftsstatusBeispiel}}
-
-Erwarteter Entbindungstermin:
-
-{{json:ISiKSchwangerschaftErwarteterEntbindungsterminBeispiel}}
-
-Alkoholabusus:
-
-{{json:ISiKAlkoholAbususBeispiel}}
-
-Raucherstatus:
-
-{{json:ISiKRaucherStatusBeispiel}}
-
-Stillstatus:
-
-{{json:ISiKStillstatusBeispiel}}
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Interaktionen.md b/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Interaktionen.md
deleted file mode 100644
index d2b1e96a..00000000
--- a/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Interaktionen.md
+++ /dev/null
@@ -1,5 +0,0 @@
-### Interaktionen
-
-Es gelten die Festlegungen für Observations: {{pagelink:ImplementationGuide/markdown/Observation/Observation_Interaktionen.md}}
-
----
diff --git a/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Kompatibilitaet.md b/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Kompatibilitaet.md
deleted file mode 100644
index 7ed37a1e..00000000
--- a/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Kompatibilitaet.md
+++ /dev/null
@@ -1,10 +0,0 @@
-### Kompatibilität
-
-Für Schwangerschaftsstatus & Erwarteter Geburtstermin wird eine Kompatibilität mit folgenden **IPS** Profilen angestrebt:
-* [IPS Resource Profile: Observation - Pregnancy: EDD](https://hl7.org/fhir/uv/ips/STU1.1/StructureDefinition-Observation-pregnancy-edd-uv-ips.html).
-* [IPS Resource Profile: Observation - Pregnancy: status](https://hl7.org/fhir/uv/ips/STU1.1/StructureDefinition-Observation-pregnancy-status-uv-ips.html)
-
-Hinweise zu Inkompatibilitäten können über die [Portalseite](https://service.gematik.de/servicedesk/customer/portal/16) gemeldet werden..
-
----
-
diff --git a/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Motivation.md b/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Motivation.md
deleted file mode 100644
index 403ca0b9..00000000
--- a/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Motivation.md
+++ /dev/null
@@ -1,10 +0,0 @@
-### Motivation
-
-Viele medizinischen Entscheidungen benötigen Informationen zu den Lebensumständen eines Patienten. Hierzu gehören eine aktuelle Schwangerschaft, Raucherstatus sowie der Alkoholabususstatus.
-Motivierender Use-Case zur Einführung dieser Profile ist die [Arzneitmitteltherapiesicherheit im Krankenhaus - AMTS](https://simplifier.net/guide/isik-medikation-v4/ImplementationGuide-markdown-UebergreifendeUseCases-AMTS).
-
-In FHIR werden Untersuchungen, bzw. Beobachtungen als [`Observation`](https://hl7.org/fhir/R4/observation.html)-Ressource repräsentiert.
-
-Die folgenden Profile vom Typ Observation sind spezifische Profile im oben genannten Sinn. Eine generische, ISiK-spezifische Observation wir beschrieben unter {{pagelink:ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Observation.md, text:generische Observation}}.
-
----
diff --git a/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Profil.md b/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Profil.md
deleted file mode 100644
index e99d1220..00000000
--- a/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Profil.md
+++ /dev/null
@@ -1,183 +0,0 @@
-### Profil
-
-#### ISiKSchwangerschaftsstatus
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKSchwangerschaftsstatus' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKSchwangerschaftsstatus, hybrid}}
-
----
-
-**Constraints**
-
-Folgende FHIRPath-Constraints sind im Profil zu beachten:
-
-@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKSchwangerschaftsstatus' for differential.element.constraint select key, severity, human, expression```
-
----
-
-**Terminology Bindings**
-
-@```
-from StructureDefinition
-where url in ('https://gematik.de/fhir/isik/StructureDefinition/ISiKSchwangerschaftsstatus' )
-for differential.element
-select
-Path: path,
-join binding.where(valueSet.exists())
-{
- Name: valueSet.substring((9 + valueSet.indexOf('ValueSet/'))),
- Strength: strength,
- URL: valueSet
-}
-```
-
-----
-
-#### ISiKSchwangerschaftErwarteterEntbindungstermin
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKSchwangerschaftErwarteterEntbindungstermin' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKSchwangerschaftErwarteterEntbindungstermin, hybrid}}
-
----
-
-**Constraints**
-
-Folgende FHIRPath-Constraints sind im Profil zu beachten:
-
-@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKSchwangerschaftErwarteterEntbindungstermin' for differential.element.constraint select key, severity, human, expression```
-
----
-
-**Terminology Bindings**
-
-@```
-from StructureDefinition
-where url in ('https://gematik.de/fhir/isik/StructureDefinition/ISiKSchwangerschaftErwarteterEntbindungstermin' )
-for differential.element
-select
-Path: path,
-join binding.where(valueSet.exists())
-{
- Name: valueSet.substring((9 + valueSet.indexOf('ValueSet/'))),
- Strength: strength,
- URL: valueSet
-}
-```
-
-----
-
-
-#### ISiKAlkoholAbusus
-
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKAlkoholAbusus' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKAlkoholAbusus, hybrid}}
-
----
-
-**Constraints**
-
-Folgende FHIRPath-Constraints sind im Profil zu beachten:
-
-@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKAlkoholAbusus' for differential.element.constraint select key, severity, human, expression```
-
----
-
-**Terminology Bindings**
-
-@```
-from StructureDefinition
-where url in ('https://gematik.de/fhir/isik/StructureDefinition/ISiKAlkoholAbusus' )
-for differential.element
-select
-Path: path,
-join binding.where(valueSet.exists())
-{
- Name: valueSet.substring((9 + valueSet.indexOf('ValueSet/'))),
- Strength: strength,
- URL: valueSet
-}
-```
-
-
-----
-
-#### ISiKRaucherStatus
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKRaucherStatus' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKRaucherStatus, hybrid}}
-
----
-
-**Constraints**
-
-Folgende FHIRPath-Constraints sind im Profil zu beachten:
-
-@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKRaucherStatus' for differential.element.constraint select key, severity, human, expression```
-
----
-
-**Terminology Bindings**
-
-@```
-from StructureDefinition
-where url in ('https://gematik.de/fhir/isik/StructureDefinition/ISiKRaucherStatus' )
-for differential.element
-select
-Path: path,
-join binding.where(valueSet.exists())
-{
- Name: valueSet.substring((9 + valueSet.indexOf('ValueSet/'))),
- Strength: strength,
- URL: valueSet
-}
-```
-
-----
-
-#### ISiKStillstatus
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKStillstatus' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKStillstatus, hybrid}}
-
----
-
-**Constraints**
-
-Folgende FHIRPath-Constraints sind im Profil zu beachten:
-
-@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKStillstatus' for differential.element.constraint select key, severity, human, expression```
-
----
-
-**Terminology Bindings**
-
-@```
-from StructureDefinition
-where url in ('https://gematik.de/fhir/isik/StructureDefinition/ISiKStillstatus' )
-for differential.element
-select
-Path: path,
-join binding.where(valueSet.exists())
-{
- Name: valueSet.substring((9 + valueSet.indexOf('ValueSet/'))),
- Strength: strength,
- URL: valueSet
-}
-```
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Motivation.md b/ImplementationGuide/markdown/Motivation.md
deleted file mode 100644
index 16992e8d..00000000
--- a/ImplementationGuide/markdown/Motivation.md
+++ /dev/null
@@ -1,28 +0,0 @@
-# Motivation
-
-Die Landschaft informationstechnischer Systeme in Krankenhäusern ist enorm heterogen. Für die Patientenverwaltung und -abrechnung, die medizinische Dokumentation, die Laborverwaltung, die Blutbank bis hin zum Dokumentenarchiv werden verschiedene, auf das jeweilige Fachgebiet spezialisierte Systeme verwendet. Es besteht daher der Bedarf, diese Systeme über ihren Primärzweck hinaus sinnvoll zu integrieren. Ein Szenario ist beispielsweise die Abrechnung der im Krankenhaus erbrachten Leistungen. Aus den ursprünglich in verschiedenen Spezialsystemen erfassten Informationen werden die für die Abrechnung relevanten Informationen an ein Abrechnungssystem gesendet und dort zur Rechnungslegung weiterverarbeitet.
-
-Herausforderungen stellen dabei die Vielzahl der Schnittstellen von informationstechnischen Systemen im Krankenhaus sowie zusätzliche Anforderungen für die Nutzung in mobilen Anwendungen dar. Durch die Festlegung und Verwendung von offenen und standardisierten Schnittstellen können diese Herausforderungen effizienter angenommen werden.
-
-Im Folgenden leiten wir - die gematik GmbH - her, warum die bestehenden Integrationsansätze im Krankenhaus noch unzureichend sind und durch die im Bestätigungsverfahren „Interoperabler Datenaustausch durch Informationssysteme im Krankenhaus“ (ISiK) spezifizierten Ansätze ergänzt werden, um die Vielzahl sinnvoller Integrationsszenarien effizient abzudecken.
-
-## Reaktiver Datenaustausch im Krankenhaus
-
-Der aktuell in Krankenhäusern vorherrschende Integrationsansatz nach dem Standard HL7 Version 2 (HL7v2) sieht vor, dass fachdomänenspezifische Systeme Nachrichten versenden, sobald für andere Systeme interessante Ereignisse eintreten. Bei Anlegen einer Diagnose in einem System für medizinische Dokumentation wird beispielsweise eine entsprechende Nachricht versendet, die vom Abrechnungssystem konsumiert und in der Rechnungslegung berücksichtigt wird. Für diesen Ansatz ist es nötig, dass die konsumierenden Systeme direkt auf die für sie passenden Nachrichten reagieren können. Leider werden dieselben Inhalte in verschiedenen Krankenhäusern oft unterschiedlich in HL7v2-Nachrichten kodiert. Darum wird häufig ein Kommunikationsserver verwendet, der die krankenhausspezifischen Nachrichten in ein Format übersetzt, dass die konsumierenden Systeme verarbeiten können. Erst wenn diese Übersetzung der HL7v2 Nachrichten eingerichtet ist, können Daten zwischen den Systemen ausgetauscht werden.
-
-Daraus ergeben sich einige relevante Nachteile:
-
-1. Es ist nur eine im Voraus definierte Datenverarbeitung möglich. Es müssen Verarbeitungsregeln im Kommunikationsserver festgelegt werden, die empfangene HL7v2-Nachrichten zur Weiterverarbeitung in ein geeignetes Format überführen.
-2. Es können keine HL7v2-Nachrichten genutzt werden, die vor Aktivierung der Verarbeitungsregeln im Krankenhaus versandt wurden. Damit bleibt ein großer Teil der verfügbaren Daten des Krankenhauses ungenutzt.
-3. Gerade große Krankenhäuser müssen tausende dieser Verarbeitungsregeln verwalten. Dies erschwert den Überblick und nicht mehr benötigte Regeln belasten den Kommunikationsserver.
-
-Daher hat der Gesetzgeber im Patientendaten-Schutzgesetz (PDSG) der gematik den Auftrag erteilt, offene und standardisierte Schnittstellen zu spezifizieren, die über den reaktiven Datenaustausch hinaus einen bedarfsgerechten Datenaustausch ermöglichen. Die Einhaltung dieser Spezifikation wird in dem ISiK Bestätigungsverfahren geprüft. Die Beschreibung des Bestätigungsverfahrens ist nicht Inhalt dieses Implementierungsleitfadens und ist im Fachportal der gematik beschrieben ().
-
-## Bedarfsgerechter Datenaustausch im Krankenhaus
-
-Um die oben skizzierten Nachteile zu vermeiden, wird in diesem Leitfaden ein bedarfsgerechter Datenaustausch im Krankenhaus spezifiziert. Benötigte Daten werden zum gewünschten Zeitpunkt im nötigen Umfang angefragt und zur Verfügung gestellt. So sind prinzipiell alle Daten eines Krankenhauses nutzbar, auch wenn sie lange vor dem Bedarf zur Nachnutzung erhoben wurden. Es müssen keine statischen Verarbeitungsregeln in einer Drittsoftware - dem Kommunikationsserver - verwaltet werden. Diese Art des bedarfsgerechten Datenaustausches wird in ISiK durch den internationalen HL7-Standard FHIR in seiner aktuellen Version R4 realisiert. Dabei folgt die Kommunikation dem Architekturstil Representational State Transfer (REST), auf dem auch wesentliche Teile der Kommunikation im Internet und mit mobilen Geräten im Besonderen basieren.
-
-## Anwendungsfälle und Interaktionen
-
-Mit ISiK und insbesondere dem Basismodul sollen eine Vielzahl digital unterstützter Anwendungsfälle im Krankenhaus realisiert werden. Dabei soll nicht die Vielfalt an möglichen Anwendungsfällen im Voraus komplett spezifiziert werden. Damit würde die Implementierung von ISiK durch zu enge und komplexe Vorgaben eher verhindert werden, gerade mit Blick auf zu erwartende zukünftige Anwendungsfälle.
-Das Ziel von ISiK ist es, digitale Interaktionen in den Anwendungsfällen zu identifizieren, für die eine Standardisierung besonders wertstiftend ist. Wertstiftend sind Interaktionen, die bspw. viele Anwendungsfälle unterstützen oder in einem Anwendungsfall einen besonders aufwändigen manuellen Schritt automatisieren.
diff --git a/ImplementationGuide/markdown/Observation/Observation_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/Observation/Observation_AnmerkungenZuDenMustSupportFeldern.md
deleted file mode 100644
index 2481ce8a..00000000
--- a/ImplementationGuide/markdown/Observation/Observation_AnmerkungenZuDenMustSupportFeldern.md
+++ /dev/null
@@ -1,41 +0,0 @@
-### Anmerkungen zu den Must-Support-Feldern
-
-### `Observation.status`
-
-**Bedeutung:** Der Status MUSS insbesondere zur Differenzierung von abgeschlossenen, vorläufigen oder korrigierten Beobachtungen angegeben werden.
-Es ist möglich, dass einzelne Systeme nur Werte vom Status `final` bereitstellen. Empfangende Systeme müssen jedoch in der Lage sein, sämtliche Status-Codes zu interpretieren.
-
-**Hinweis:** Siehe Beschreibung in der [FHIR Kernspezifikation](https://hl7.org/fhir/R4/observation-definitions.html#Observation.status).
-
-### `Observation.category`
-**Bedeutung:** Kategorie-Code, der die Untersuchung kategorisiert.
-
-### `Observation.code`
-**Bedeutung:** Code, der die Untersuchung repräsentiert und kodiert.
-
-### `Observation.subject`
-**Bedeutung:** Ein Patientenbezug der Observation MUSS stets zum Zwecke der Nachvollziehbarkeit und Datenintegrität vorliegen.
-
-### `Observation.encounter`
-**Bedeutung:** Der Fallbezug einer Observation MUSS stets zum Zwecke der Nachvollziehbarkeit und Datenintegrität vorliegen.
-
-**Hinweise:**
-
-Eine Verlinkung der Referenz auf den dazugehörigen Kontakt MUSS auf die Ebene des Abteilungskontaktes (entsprechend ISiKKontaktGesundheitseinrichtung) erfolgen.
-Bei der Auswahl des Kontaktes ist zu beachten, dass mehrere Encounter-Ressourcen mit identischen Aufnahmenummer-Identifiern existieren können (Abbildung Vor- und nachstationäre Kontakte).
-
-### `Observation.effective[x]`
-**Bedeutung:** Klinisch relevanter Zeitpunkt/Zeitspanne für die Observation.
-
-### `Observation.hasMember`
-**Bedeutung:** Weitere Observation, die mit dieser Observation gemeinsam zu betrachten ist.
-
-### `Observation.value[x]`
-**Bedeutung:** Erfasster Wert der Observation.
-
-### `Observation.component`
-
-**Bedeutung:** Bei Vitalparametern, die aus mehreren Einzelnen Messpunkten bestehen (Blutdruck, EKG, GCS), werden die gemessenen Einzelwerte
-jeweils mit einem separaten LOINC-Code in `Observation.component.code` versehen und der entsprechende Messwert in `Observation.component.value` erfasst.
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Observation/Observation_Interaktionen.md b/ImplementationGuide/markdown/Observation/Observation_Interaktionen.md
deleted file mode 100644
index b360381d..00000000
--- a/ImplementationGuide/markdown/Observation/Observation_Interaktionen.md
+++ /dev/null
@@ -1,99 +0,0 @@
-### Interaktionen
-
-Für die Ressource Observation MUSS die REST-Interaktion "READ" implementiert werden.
-
-Folgende Suchparameter sind für das Bestätigungsverfahren relevant, auch in Kombination:
-
-1. Der Suchparameter "_id" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Observation?_id=1234567890```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "_id" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Parameters for all resources"](https://www.hl7.org/fhir/R4/search.html#all).
-
-1. Der Suchparameter "status" MUSS unterstützt werden:
-
- Beispiel:
-
- ``` GET [base]/Observation?status=http://hl7.org/fhir/observation-status|final```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "status"
- finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "category" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Observation?category=http://terminology.hl7.org/CodeSystem/observation-category|social-history```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Observation.category" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "code" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Observation?code=http://terminology.hl7.org/CodeSystem/observation-category|social-history```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Observation.category" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "patient" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Observation?patient=Patient/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Condition.subject" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
- Dieser Suchparameter ist für die Umsetzung des IHE QEDm Profils verpflichtend.
-
-1. Der Suchparameter "subject" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Observation?subject=Patient/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Condition.subject" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-1. Der Suchparameter "date" MUSS unterstützt werden:
-
- Beispiel:
-
- ``` GET [base]/Observation?date=ge2013-01-14&date=le2021-12-31```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "date"
- finden sich in der [FHIR-Basisspezifikation - Abschnitt "Parameters for all resources"](https://www.hl7.org/fhir/R4/search.html#all).
-
-1. Der Suchparameter "combo-code" MUSS unterstützt werden:
-
- Beispiel:
-
- ```GET [base]/Observation?combo-code=85354-9```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "combo-code" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token"](https://www.hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "combo-code-value-quantity" MUSS unterstützt werden:
-
- Beispiel:
-
- ```GET [base]/Observation?combo-code-value-quantity=http://loinc.org|8480-6$120|http://unitsofmeasure.org|mm[Hg]```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "combo-code-value-quantity" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Composite Search Parameters"](https://www.hl7.org/fhir/R4/search.html#combining).
-
-1. Der Suchparameter "component-code" MUSS unterstützt werden:
-
- Beispiel:
-
- ```GET [base]/Observation?component-code=http://loinc.org|85354-9```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "component-code" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token"](https://www.hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "encounter" MUSS unterstützt werden:
-
- Beispiel:
-
- ```GET [base]/Observation?encounter=Encounter/234```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "encounter" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
----
diff --git a/ImplementationGuide/markdown/Observation/Observation_Motivation.md b/ImplementationGuide/markdown/Observation/Observation_Motivation.md
deleted file mode 100644
index 475641e8..00000000
--- a/ImplementationGuide/markdown/Observation/Observation_Motivation.md
+++ /dev/null
@@ -1,5 +0,0 @@
-### Motivation
-
-Dieses Seite dient der generischen Festlegung und Darstellung von Interaktionen, die verschiedene Observations im Kontext von ISiK erfüllen MÜSSEN.
-Entsprechend wird hier ein generisches Profil ISiKLebenszustand abgebildet.
-Zu spezifischen Observation-Profilen siehe {{pagelink:ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Lebenszustand.md, text:spezifische Lebenszustände}}.
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Observation/Observation_Profil.md b/ImplementationGuide/markdown/Observation/Observation_Profil.md
deleted file mode 100644
index 253fe6c8..00000000
--- a/ImplementationGuide/markdown/Observation/Observation_Profil.md
+++ /dev/null
@@ -1,37 +0,0 @@
-### Profil
-
-#### ISiKLebenszustand
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKLebenszustand' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKLebenszustand, hybrid}}
-
----
-
-**Constraints**
-
-Folgende FHIRPath-Constraints sind im Profil zu beachten:
-
-@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKLebenszustand' for differential.element.constraint select key, severity, human, expression```
-
----
-
-**Terminology Bindings**
-
-@```
-from StructureDefinition
-where url in ('https://gematik.de/fhir/isik/StructureDefinition/ISiKLebenszustand' )
-for differential.element
-select
-Path: path,
-join binding.where(valueSet.exists())
-{
- Name: valueSet.substring((9 + valueSet.indexOf('ValueSet/'))),
- Strength: strength,
- URL: valueSet
-}
-```
-
-----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Organisation/Organisation_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/Organisation/Organisation_AnmerkungenZuDenMustSupportFeldern.md
deleted file mode 100644
index e3241679..00000000
--- a/ImplementationGuide/markdown/Organisation/Organisation_AnmerkungenZuDenMustSupportFeldern.md
+++ /dev/null
@@ -1,6 +0,0 @@
-### Anmerkungen zu Must-Support-Feldern
-
-Zu beachten sind die die Comment-Felder der einzelnen (Sub-)Elemente im Profil.
-
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Organisation/Organisation_Beispiele.md b/ImplementationGuide/markdown/Organisation/Organisation_Beispiele.md
deleted file mode 100644
index 2c72bb60..00000000
--- a/ImplementationGuide/markdown/Organisation/Organisation_Beispiele.md
+++ /dev/null
@@ -1,9 +0,0 @@
-### Beispiele
-Valides Minimalbeispiel eines Krankenhauses:
-{{json:KrankenhausOrganisationBeispiel}}
-
-Valides Minimalbeispiel einer Fachabteilung:
-{{json:AbteilungAllgemeinchirurgieOrganisationBeispiel}}
-
-
-
diff --git a/ImplementationGuide/markdown/Organisation/Organisation_Interaktionen.md b/ImplementationGuide/markdown/Organisation/Organisation_Interaktionen.md
deleted file mode 100644
index d9f4f323..00000000
--- a/ImplementationGuide/markdown/Organisation/Organisation_Interaktionen.md
+++ /dev/null
@@ -1,73 +0,0 @@
-### Interaktionen
-
-Sofern die Ressourcen zur Organisation unterstützt werden, SOLL die REST-Interaktion "READ" implementiert werden.
-
-Interaktionen zur Organisation werden derzeit für das Bestätigungsverfahren nicht festgelegt.
-
-Auf folgende Suchparameter sei aufgrund der Relevanz hingewiesen - diese SOLLEN (in Einzelfällen KÖNNEN) implementiert werden, falls die oben genannten Ressourcen unterstützt werden:
-
-1. Der Suchparameter "identifier" SOLL unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Organization?identifier=http://fhir.de/sid/arge-ik/iknr|260120196```
-
- ```GET [base]/Organization?identifier=http://fhir.de/StructureDefinition/identifier-bsnr|345678975```
-
- ```GET [base]/Organization?identifier=345678975```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Organization.identifier" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "active" SOLL unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Organization?active=true```
-
- ```GET [base]/Organization?active=false```
-
- Anwendungshinweise: Insbesondere für die Suche nach Daten historischer Organisationsstrukturen - z.B. nach Schließung, Zusammenlegung von Fachabteilungen etc. - erscheint es erforderlich nach Ressourcen nicht aktiver Organisationseinheiten suchen zu können. Weitere Informationen zur Suche nach "Organization.active" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "type" SOLL unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Organization?type=dept```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Organization.type" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "name" SOLL unterstützt werden (dies gilt auch für das Element .alias):
-
- Beispiele:
-
- ```GET [base]/Organization?name=FA-Gynäkologie```
-
- ```GET [base]/Organization?name=GYN```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Organization.name" und "Organization.alias" finden sich in der [FHIR-Basisspezifikation - Abschnitt "String Search"](https://hl7.org/fhir/R4/search.html#string).
-
-
-1. Der Suchparameter "partof" in Kombination mit einem identifier-Modifier SOLL unterstützt werden :
-
- Beispiele:
-
- ```GET [base]/Organization?partof:identifier=260120196```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Organization.partof" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://hl7.org/fhir/R4/search.html#reference).
-
-1. Der Suchparameter "address" KANN unterstützt werden:
-
- Beispiele
-
- ```GET [base]/Organization?address=Berlin```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Organization.address" finden sich in der [FHIR-Basisspezifikation - Abschnitt "String Search"](https://hl7.org/fhir/R4/search.html#string).
-
-1. Der Suchparameter "endpoint" in Kombination mit einem identifier-Modifier KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Organization?endpoint:identifier=123456```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Organization.endpoint" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://hl7.org/fhir/R4/search.html#reference).
-
diff --git a/ImplementationGuide/markdown/Organisation/Organisation_Kompatibilitaet.md b/ImplementationGuide/markdown/Organisation/Organisation_Kompatibilitaet.md
deleted file mode 100644
index 9a3864cc..00000000
--- a/ImplementationGuide/markdown/Organisation/Organisation_Kompatibilitaet.md
+++ /dev/null
@@ -1,5 +0,0 @@
-### Kompatibilität
-
-Für das Profil ISiKOrganisation wurde bis zum Zeitpunkt der Veröffentlichung kein Abgleich der Kompatibilität zu anderen Profilen (der KBV und der Medizininformatik-Initiative) durchgeführt.
-
----
diff --git a/ImplementationGuide/markdown/Organisation/Organisation_Motivation.md b/ImplementationGuide/markdown/Organisation/Organisation_Motivation.md
deleted file mode 100644
index 6ad934b8..00000000
--- a/ImplementationGuide/markdown/Organisation/Organisation_Motivation.md
+++ /dev/null
@@ -1,20 +0,0 @@
-### Motivation
-
-Die Abbildung der Aufbauorganisation eines Krankenhauses dient der Festlegung von Zuständigkeiten und (Entscheidungs-)Verantwortungen von Organisationseinheiten (z.B. Fachkliniken, Fachabteilungen und -bereichen etc.) in strukturierter Form.
-
-In FHIR wird die Organisation (Organization) vom Standort (Location) eindeutig abgegrenzt.
-
-Die Erfassung der Organisation in strukturierter Form ermöglicht u.a.:
-- Zuweisungen von Diensten an bestimmte Bereiche der Aufbauorganisation im Rahmen des Terminmanagements
-- Die Raum- und Betten-Belegung in strukturierter Form (interdisziplinär)
-
-Auch die Erfassung des Krankenhauses als Ganzem ist relevant.
-Entsprechend fokussieren die folgenden Profile zur Organisation auf das Krankenhaus als Ganzes und die Fachabteilung als Organisation.
-
----
-
-#### Normativer Status und Bestätigung
-
-Diese Profile MÜSSEN im Rahmen der Bestätigung NICHT unterstützt werden. Falls ein Profil unterstützt wird, SOLLEN die hier definierten Festlegungen greifen.
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Organisation/Organisation_Profil.md b/ImplementationGuide/markdown/Organisation/Organisation_Profil.md
deleted file mode 100644
index 34f94174..00000000
--- a/ImplementationGuide/markdown/Organisation/Organisation_Profil.md
+++ /dev/null
@@ -1,60 +0,0 @@
-### FHIR-Profil
-
-Das Profil ISiKOrganisation soll auch ein Krankenhaus als Ganzes abbilden können:
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKOrganisation' select Name: name, Canonical: url
-```
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKOrganisation, hybrid}}
-
-Folgende FHIRPath-Constraints sind im Profil zu beachten:
-
-@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKOrganisation' for differential.element.constraint select key, severity, human, expression```
-
-**Terminology Bindings**
-
-@```
-from StructureDefinition
-where url in ('https://gematik.de/fhir/isik/StructureDefinition/ISiKOrganisation' )
-for differential.element
-select
-Path: path,
-join binding.where(valueSet.exists())
-{
- Name: valueSet.substring((9 + valueSet.indexOf('ValueSet/'))),
- Strength: strength,
- URL: valueSet
-}
-```
-
----
-
-Das Profil ISiKOrganisationFachabteilung soll eine einzelne Fachabteilung abbilden:
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKOrganisationFachabteilung' select Name: name, Canonical: url
-```
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKOrganisationFachabteilung, hybrid}}
-
-Folgende FHIRPath-Constraints sind im Profil zu beachten:
-
-@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKOrganisationFachabteilung' for differential.element.constraint select key, severity, human, expression```
-
-
-**Terminology Bindings**
-
-@```
-from StructureDefinition
-where url in ('https://gematik.de/fhir/isik/StructureDefinition/ISiKOrganisationFachabteilung' )
-for differential.element
-select
-Path: path,
-join binding.where(valueSet.exists())
-{
- Name: valueSet.substring((9 + valueSet.indexOf('ValueSet/'))),
- Strength: strength,
- URL: valueSet
-}
-```
-
----
diff --git a/ImplementationGuide/markdown/Patient/Patient_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/Patient/Patient_AnmerkungenZuDenMustSupportFeldern.md
deleted file mode 100644
index 9987194e..00000000
--- a/ImplementationGuide/markdown/Patient/Patient_AnmerkungenZuDenMustSupportFeldern.md
+++ /dev/null
@@ -1,70 +0,0 @@
-### Anmerkungen zu Must-Support-Feldern
-
-### `Patient.active`
-
-**Bedeutung:** Indikator "Patientdatensatz ist in aktiver Benutzung"
-
-**Hinweise:** Siehe Beschreibung in der [FHIR Kernspezifikation](https://hl7.org/fhir/R4/patient-definitions.html#Patient.active)
-
-### `Patient.identifier:versichertenId_GKV`
-
-**Bedeutung:** Versicherten ID der gesetzlichen Krankenkasse
-
-**Hinweise:** Siehe [Beschreibung der Deutschen Basisprofile](https://ig.fhir.de/basisprofile-de/1.2.0/GesetzlicheKrankenversichertennummer10-stelligeKVID-Identifier.html)
-
-### `Patient.identifier:pid`
-
-**Bedeutung:** Organisationsinterner Patienten-Identifier
-
-**Hinweise:** Siehe [Beschreibung der Deutschen Basisprofile](https://ig.fhir.de/basisprofile-de/1.2.0/OrganisationsinternerPatienten-Identifier.html)
-
-### `Patient.identifier:versicherungsnummer_pkv`
-
-**Bedeutung:** Versicherten Nr., falls versichert bei einer privaten Krankenkasse
-
-**Hinweise:** Siehe [Beschreibung der Deutschen Basisprofile](https://ig.fhir.de/basisprofile-de/1.2.0/PrivateKrankenversichertennummer-Identifier.html)
-
-### `Patient.name:name`
-
-**Bedeutung:** Vollständiger Name
-
-**Hinweise:** Wenn kein Name vorliegt, SOLLTE die [data-absent-reason](https://www.hl7.org/fhir/R4/extension-data-absent-reason.html)-Extension eingesetzt werden. Siehe [Beschreibung der Deutschen Basisprofile](https://ig.fhir.de/basisprofile-de/1.2.0/Ressourcen-Patient.html#Ressourcen-Patient-Name)
-
-### `Patient.name:geburtsname`
-
-**Bedeutung:** Geburtsname des Patienten (nur Nachname)
-
-**Hinweise:** Siehe [Beschreibung der Deutschen Basisprofile](https://ig.fhir.de/basisprofile-de/1.2.0/Ressourcen-Patient.html#Ressourcen-Patient-Name)
-
-### `Patient.address:Strassenanschrift`
-
-**Bedeutung:** Straßenadresse
-
-**Hinweise:** Siehe [Beschreibung der Deutschen Basisprofile](https://ig.fhir.de/basisprofile-de/1.2.0/Ressourcen-Patient.html#Ressourcen-Patient-Addresse)
-
-### `Patient.address:Postfach`
-
-**Bedeutung:** Postfachadresse
-
-**Hinweise:** Siehe [Beschreibung der Deutschen Basisprofile](https://ig.fhir.de/basisprofile-de/1.2.0/Ressourcen-Patient.html#Ressourcen-Patient-Addresse)
-
-### `Patient.gender`
-
-**Bedeutung:** Administratives Geschlecht
-
-**Hinweise:** Siehe [Beschreibung der Deutschen Basisprofile](https://ig.fhir.de/basisprofile-de/1.2.0/Ressourcen-Patient.html#Ressourcen-Patient-Geschlecht)
-
-### `Patient.birthdate`
-
-**Bedeutung:** Geburtsdatum
-
-**Hinweise:** Siehe [Beschreibung der Deutschen Basisprofile](https://ig.fhir.de/basisprofile-de/1.2.0/Ressourcen-Patient.html#Ressourcen-Patient-Geburtsdatum)
-
-### Stornierung von Patienten
-
-"Im Rahmen des ISiK Basismoduls SOLL die Stornierung eines Patienten entweder erfolgen durch
-* das Löschen der Patienten-Ressource oder
-* die Verwendung des Feldes Patient.active
-Die konkrete Implementierung ist abhängig davon, wie die Stornierung im bestätigungsrelevanten System umgesetzt ist. Im letzteren Fall wird die Stornierung durch das Setzen von Patient.active auf "false" gekennzeichnet.
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Patient/Patient_Beispiele.md b/ImplementationGuide/markdown/Patient/Patient_Beispiele.md
deleted file mode 100644
index a65ca6a3..00000000
--- a/ImplementationGuide/markdown/Patient/Patient_Beispiele.md
+++ /dev/null
@@ -1,5 +0,0 @@
-### Beispiele
-
-Valides Minimalbeispiel Patient:
-
-{{json:patientinmusterfrau}}
diff --git a/ImplementationGuide/markdown/Patient/Patient_Interaktionen.md b/ImplementationGuide/markdown/Patient/Patient_Interaktionen.md
deleted file mode 100644
index 4deeb16e..00000000
--- a/ImplementationGuide/markdown/Patient/Patient_Interaktionen.md
+++ /dev/null
@@ -1,141 +0,0 @@
-### Interaktionen
-
-Für die Ressource Patient MUSS die REST-Interaktion "READ" implementiert werden.
-
-Für die Ressource Patient KANN die REST-Interaktion "POST" implementiert werden. Diese Interaktion dient für die Vorabübermittelung von (unverifizierten und/oder unvollständigen) Patientenstammdaten.
-
-* Das bestätigungsrelevante System SOLL die übermittelte ```Patient```-Ressource löschen oder als inaktiv kennzeichnen, insoweit Geschäftsregeln oder andere Gründe dazu führen, dass die ```Patient```-Ressource nicht permanent im System angelegt wird (z.B. keine Bestätigung durch die Anwender\*in des Systems oder keine Aufnahme der Patient\*in).
-
-Folgende Suchparameter sind für das Bestätigungsverfahren relevant, auch in Kombination:
-
-1. Der Suchparameter "_id" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Patient?_id=103270```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "_id" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Parameters for all resources"](https://hl7.org/fhir/R4/search.html#all).
-
- Dieser Suchparameter ist für die Umsetzung des IHE PDQm Profils verpflichtend.
-
-1. Der Suchparameter "identifier" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Patient?identifier=http://fhir.krankenhaus.example|1032702```
-
- ```GET [base]/Patient?identifier=1032702```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Patient.identifier" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
- Dieser Suchparameter ist für die Umsetzung des IHE PDQm Profils verpflichtend.
-
-1. Der Suchparameter "given" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Patient?given=Erika```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Patient.name.given" finden sich in der [FHIR-Basisspezifikation - Abschnitt "String Search"](https://hl7.org/fhir/R4/search.html#string).
-
- Dieser Suchparameter ist für die Umsetzung des IHE PDQm Profils verpflichtend.
-
-1. Der Suchparameter "family" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Patient?family=Musterfrau```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Patient.name.family" finden sich in der [FHIR-Basisspezifikation - Abschnitt "String Search"](https://hl7.org/fhir/R4/search.html#string).
-
- Dieser Suchparameter ist für die Umsetzung des IHE PDQm Profils verpflichtend.
-
-1. Der Suchparameter "birthdate" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Patient?birthdate=1964-12-08```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Patient.birthDate" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Date Search"](https://hl7.org/fhir/R4/search.html#date).
-
-1. Der Suchparameter "gender" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Patient?gender=female```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Patient.gender" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
- Dieser Suchparameter ist für die Umsetzung des IHE PDQm Profils verpflichtend.
-
-1. Der Suchparameter "name" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Patient?name=Erika```
-
- ```GET [base]/Patient?name=Musterfrau```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Patient.name" finden sich in der [FHIR-Basisspezifikation - Abschnitt "String Search"](https://hl7.org/fhir/R4/search.html#string).
-
-1. Der Suchparameter "address" KANN unterstützt werden:
-
- Beispiele
-
- ```GET [base]/Patient?address=Berlin```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Patient.address" finden sich in der [FHIR-Basisspezifikation - Abschnitt "String Search"](https://hl7.org/fhir/R4/search.html#string).
-
- Dieser Suchparameter ist für die Umsetzung des IHE PDQm Profils verpflichtend.
-
-1. Der Suchparameter "address-city" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Patient?address-city=Berlin```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Patient.address.city" finden sich in der [FHIR-Basisspezifikation - Abschnitt "String Search"](https://hl7.org/fhir/R4/search.html#string).
-
- Dieser Suchparameter ist für die Umsetzung des IHE PDQm Profils verpflichtend.
-
-1. Der Suchparameter "address-country" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Patient?address-country=DE```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Patient.address.country" finden sich in der [FHIR-Basisspezifikation - Abschnitt "String Search"](https://hl7.org/fhir/R4/search.html#string).
-
- Dieser Suchparameter ist für die Umsetzung des IHE PDQm Profils verpflichtend.
-
-1. Der Suchparameter "address-postalcode" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Patient?address-postalcode=10117```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Patient.address.postalCode" finden sich in der [FHIR-Basisspezifikation - Abschnitt "String Search"](https://hl7.org/fhir/R4/search.html#string).
-
- Dieser Suchparameter ist für die Umsetzung des IHE PDQm Profils verpflichtend.
-
-1. Der Suchparameter "active" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Patient?active=true```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Patient.active" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
- Dieser Suchparameter ist für die Umsetzung des IHE PDQm Profils verpflichtend.
-
-1. Der Suchparameter "telecom" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Patient?telecom=phone|+49152236898```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Patient.telecom" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
- Dieser Suchparameter ist für die Umsetzung des IHE PDQm Profils verpflichtend.
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Patient/Patient_Kompatibilitaet.md b/ImplementationGuide/markdown/Patient/Patient_Kompatibilitaet.md
deleted file mode 100644
index ad22fc4d..00000000
--- a/ImplementationGuide/markdown/Patient/Patient_Kompatibilitaet.md
+++ /dev/null
@@ -1,10 +0,0 @@
-### Kompatibilität
-
-Für das Profil ISIKPatient wird eine Kompatibilität mit folgenden Profilen angestrebt; allerdings kann nicht sichergestellt werden, dass Instanzen, die gegen ISIKPatient valide sind, auch valide sind gegen:
-* [Profil KBV_PR_Base_Patient der KBV Basisprofile](https://fhir.kbv.de/StructureDefinition/KBV_PR_Base_Patient)
-* [Profil Patient im International Patient Summary (IPS)](https://hl7.org/fhir/uv/ips/StructureDefinition-Patient-uv-ips.html)
-* [Profil Patient der MI-Initiative](https://www.medizininformatik-initiative.de/fhir/core/modul-person/StructureDefinition/Patient)
-
-Hinweise zu Inkompatibilitäten können über die [Portalseite](https://service.gematik.de/servicedesk/customer/portal/16) gemeldet werden..
-
----
diff --git a/ImplementationGuide/markdown/Patient/Patient_Motivation.md b/ImplementationGuide/markdown/Patient/Patient_Motivation.md
deleted file mode 100644
index 6a7184e8..00000000
--- a/ImplementationGuide/markdown/Patient/Patient_Motivation.md
+++ /dev/null
@@ -1,9 +0,0 @@
-### Motivation
-
-Der Austausch administrativer Patientendaten ist eine der grundlegenden Funktionalitäten beim Datenaustausch in der klinischen Versorgung.
-
-In FHIR werden sämtliche klinischen Ressourcen durch Verlinkung auf die Ressource 'Patient' in einen Patientenkontext gestellt.
-
-Die Herstellung des korrekten Patientenkontextes durch Suchen der Patientenressource anhand von Eigenschaften wie Aufnahmenummer, Name oder Geburtsdatum, die Anzeige der zutreffenden Suchergebnisse und der Auswahl bzw. Bestätigung des richtigen Datensatzes durch den Anwender steht am Beginn der meisten klinischen Workflows.
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Patient/Patient_Profil.md b/ImplementationGuide/markdown/Patient/Patient_Profil.md
deleted file mode 100644
index 8c547a0d..00000000
--- a/ImplementationGuide/markdown/Patient/Patient_Profil.md
+++ /dev/null
@@ -1,12 +0,0 @@
-### FHIR-Profil
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKPatient' select Name: name, Canonical: url
-```
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKPatient, hybrid}}
-
-Folgende FHIRPath-Constraints sind im Profil zu beachten:
-
-@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKPatient' for differential.element.constraint select key, severity, human, expression```
-
----
diff --git a/ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_AnmerkungenZuDenMustSupportFeldern.md
deleted file mode 100644
index a3eb1989..00000000
--- a/ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_AnmerkungenZuDenMustSupportFeldern.md
+++ /dev/null
@@ -1,31 +0,0 @@
-### Anmerkungen zu den Must-Support-Feldern
-
-### `Practitioner.identifier:ANR`
-
-**Bedeutung:** Lebenslange Arztnummer. Im Krankenhaus ist die lebenslange Arztnummer der Ärzte bekannt und MUSS zur eindeutigen Identifikation eines Arztes bereitgestellt werden.
-
-**Hinweise:** Siehe [Beschreibung der Deutschen Basisprofile](https://ig.fhir.de/basisprofile-de/1.2.0/LebenslangeArztnummerLANR-Identifier.html)
-
-Während die Deutschen Basisprofile hier die Abkürzung LANR verwenden, ist im KBV-Kontext das Akronym ANR gebräuchlich. Die Bezeichnung des Slices hat jedoch keinerlei Auswirkungen auf die Kompatibilität.
-
-### `Practitioner.name:name`
-
-**Bedeutung:** Vollständiger Name. Der Name des Arztes MUSS in konkreten Anwendungen angezeigt werden können. Es MUSS nach dem Namen des Arztes gesucht werden können.
-
-### `Practitioner.address:Strassenanschrift`
-
-**Bedeutung:** Straßenanschrift. Ist die Adresse bekannt, unter der ein Arzt erreichbar ist, MUSS sie bereitgestellt werden.
-
-### `Practitioner.address:Postfach`
-
-**Bedeutung:** Postfachanschrift. Ist die Postfachadresse bekannt, unter der ein Arzt erreichbar ist, MUSS sie bereitgestellt werden.
-
-### `Practitioner.gender`
-
-**Bedeutung:** Administratives Geschlecht. Ist das Geschlecht des Arztes bekannt, MUSS es bereitgestellt werden.
-
-### `Practitioner.birthDate`
-
-**Bedeutung:** Geburtsdatum. Ist das Geburtsdatum des Arztes bekannt, MUSS es bereitgestellt werden.
-
----
diff --git a/ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_Beispiele.md b/ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_Beispiele.md
deleted file mode 100644
index bc74f996..00000000
--- a/ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_Beispiele.md
+++ /dev/null
@@ -1,5 +0,0 @@
-### Beispiele
-
-Valides Minimalbeispiel PersonImGesundheitsberuf:
-
-{{json:practitionerwalterarzt}}
diff --git a/ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_Interaktionen.md b/ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_Interaktionen.md
deleted file mode 100644
index 97a37b42..00000000
--- a/ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_Interaktionen.md
+++ /dev/null
@@ -1,65 +0,0 @@
-### Interaktionen
-
-Für die Ressource Practitioner MUSS die REST-Interaktion "READ" implementiert werden.
-
-Folgende Suchparameter sind für das Bestätigungsverfahren relevant, auch in Kombination:
-
-1. Der Suchparameter "_id" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Practitioner?_id=1234567890```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "_id" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Parameters for all resources"](https://www.hl7.org/fhir/R4/search.html#all).
-
-1. Der Suchparameter "identifier" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Practitioner?identifier=42```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Practitioner.identifier" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "given" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Practitioner?given=Heidi```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Practitioner.name.given" finden sich in der [FHIR-Basisspezifikation - Abschnitt "String Search"](https://hl7.org/fhir/R4/search.html#string).
-
-1. Der Suchparameter "family" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Practitioner?family=Alpenzauber```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Practitioner.name.family" finden sich in der [FHIR-Basisspezifikation - Abschnitt "String Search"](https://hl7.org/fhir/R4/search.html#string).
-
-1. Der Suchparameter "name" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Practitioner?name=Heidi```
-
- ```GET [base]/Practitioner?name=Alpenzauber```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Practitioner.name" finden sich in der [FHIR-Basisspezifikation - Abschnitt "String Search"](https://hl7.org/fhir/R4/search.html#string).
-
-1. Der Suchparameter "address" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Practitioner?address=Berlin```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Practitioner.address" finden sich in der [FHIR-Basisspezifikation - Abschnitt "String Search"](https://hl7.org/fhir/R4/search.html#string).
-
-1. Der Suchparameter "gender" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Practitioner?gender=female```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Practitioner.gender" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
----
diff --git a/ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_Kompatibilitaet.md b/ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_Kompatibilitaet.md
deleted file mode 100644
index 7ab604ab..00000000
--- a/ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_Kompatibilitaet.md
+++ /dev/null
@@ -1,10 +0,0 @@
-### Kompatibilität
-
-Für das Profil ISIKPersonImGesundheitsberuf wird eine Kompatibilität mit folgenden Profilen angestrebt; allerdings kann nicht sichergestellt werden, dass Instanzen, die gegen ISIKPatient valide sind, auch valide sind gegen:
-* [Profil KBV_PR_Base_Practitioner der KBV Basisprofile](https://fhir.kbv.de/StructureDefinition/KBV_PR_Base_Practitioner).
-* [Profil HiGHmed_IC_Practitioner, MI Initiative - HiGHmed Use Case Infection Control der Medizininformatik Initiative ](https://simplifier.net/medizininformatikinitiative-highmed-ic/highmed-ic-practitioner)
-
-Hinweise zu Inkompatibilitäten können über die [Portalseite](https://service.gematik.de/servicedesk/customer/portal/16) gemeldet werden..
-
----
-
diff --git a/ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_Motivation.md b/ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_Motivation.md
deleted file mode 100644
index c97a3358..00000000
--- a/ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_Motivation.md
+++ /dev/null
@@ -1,7 +0,0 @@
-### Motivation
-
-Das Profil ISIKPersonImGesundheitsberuf bildet alle denkbaren medizinischen Leistungserbringer und Fachexperten ab. In den ISiK-FHIR-Profilen können PersonImGesundheitsberuf bspw. als Ausführende einer Prozedur auftreten, im Element `performer` der Procedure Ressource, oder als die Person, die eine Diagnose stellt, im Element `asserter` der Condition Ressource.
-
-In FHIR werden PersonImGesundheitsberuf mit der [`Practitioner`](https://hl7.org/fhir/R4/practitioner.html)-Ressource repräsentiert.
-
----
diff --git a/ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_Profil.md b/ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_Profil.md
deleted file mode 100644
index 6da6cf3c..00000000
--- a/ImplementationGuide/markdown/PersonImGesundheitsberuf/PersonImGesundheitsberuf_Profil.md
+++ /dev/null
@@ -1,35 +0,0 @@
-### Profil
-
-@```
-from StructureDefinition where url = '3/Basismodul/StructureDefinition/ISiKPersonImGesundheitsberuf' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKPersonImGesundheitsberuf, hybrid}}
-
----
-
-**Constraints**
-
-Folgende FHIRPath-Constraints sind im Profil zu beachten:
-
-@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKPersonImGesundheitsberuf' for differential.element.constraint select key, severity, human, expression```
-
----
-
-**Terminology Bindings**
-
-@```
-from StructureDefinition
-where url in ('https://gematik.de/fhir/isik/StructureDefinition/ISiKPersonImGesundheitsberuf' )
-for differential.element
-select
-Path: path,
-join binding.where(valueSet.exists())
-{
- Name: valueSet.substring((9 + valueSet.indexOf('ValueSet/'))),
- Strength: strength,
- URL: valueSet
-}
-```
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Prozedur/Prozedur_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/Prozedur/Prozedur_AnmerkungenZuDenMustSupportFeldern.md
deleted file mode 100644
index e961c131..00000000
--- a/ImplementationGuide/markdown/Prozedur/Prozedur_AnmerkungenZuDenMustSupportFeldern.md
+++ /dev/null
@@ -1,48 +0,0 @@
-### Anmerkungen zu den Must-Support Feldern
-
-### `Procedure.extension:recordedDate`
-
-**Bedeutung:**
-Das Dokumentationsdatum der Prozedur MUSS zu Qualitätssicherungszwecken angegeben werden. Dies ist das fachliche Dokumentationsdatum, nicht zu verwechseln mit der technischen Anlage des Datensatzes im Primärsystem. Diese beiden Daten können jedoch identisch sein.
-
-### `Procedure.status`
-
-**Bedeutung:**
-Kodierter klinischer Status der Prozedur. MUSS angegeben werden, da die Interpretation der Prozedur davon abhängt, ob diese 'completed' ist oder einen anderen Status aufweist. Alle in einem System möglichen Status-Werte müssen über FHIR korrekt repräsentiert werden können, mindestens jedoch die Status-Werte "completed" und "unknown". Deren korrekte Abbildung wird im Rahmen des Bestätigungsverfahrens überprüft.
-
-### `Procedure.category`
-
-**Bedeutung:**
-Zur groben Kategorisierung MUSS eine Kodierung auf Basis der OPS-Klassencodes erfolgen. Eine ConceptMap für das Mapping von OPS-Kodes -> Kategorie findet sich in den [Deutschen Basisprofilen - Implementierungsleitfaden Abschnitt Terminologien](https://ig.fhir.de/basisprofile-de/stable/Terminologie-ConceptMaps.html). Die Angabe der Kategeorie MUSS nur für OPS-kodierte Prozeduren erfolgen.
-
-### `Procedure.code.coding`
-
-**Bedeutung:** Codierte Prozedur. Entweder kodiert per [OPS](https://www.bfarm.de/DE/Kodiersysteme/Klassifikationen/OPS-ICHI/OPS/_node.html) oder [SNOMED CT](https://www.snomed.org). Bei der Kodierung per SNOMED CT ist das ValueSet [ProzedurenCodesSCT](https://simplifier.net/ISiK/ProzedurenCodesSCT) zu beachten.
-
-### `Procedure.code.text`
-
-**Bedeutung:** Freitext-Beschreibung der Prozedur
-
-### `Procedure.performed`
-
-**Bedeutung:** Zur zeitlichen Einordnung der Prozedur KANN das Durchführungsdatum der Prozedur dokumentiert werden. Mindestens MUSS der Beginn der Prozedur dokumentiert werden, das Ende KANN implementiert werden.
-
-### `Procedure.subject`
-
-**Bedeutung:** Ein Patientenbezug der Prozedur MUSS stets zum Zwecke der Nachvollziehbarkeit und Datenintegrität vorliegen.
-
-### `Procedure.encounter`
-
-**Bedeutung:** Der Fallbezug einer Prozedur MUSS stets zum Zwecke der Nachvollziehbarkeit und Datenintegrität vorliegen.
-
-**Hinweise:**
-
-Eine Verlinkung der Referenz auf den dazugehörigen Kontakt MUSS auf die Ebene des Abteilungskontaktes (entsprechend ISiKKontaktGesundheitseinrichtung) erfolgen.
-Bei der Auswahl des Kontaktes ist zu beachten, dass mehrere Encounter-Ressourcen mit identischen Aufnahmenummer-Identifiern existieren können (Abbildung Vor- und nachstationäre Kontakte).
-
-
-### `Procedure.note`
-
-**Bedeutung:** Weitere optionale Freitext-Notizen bezogen auf die durchgeführte Prozedur.
-
----
diff --git a/ImplementationGuide/markdown/Prozedur/Prozedur_Beispiele.md b/ImplementationGuide/markdown/Prozedur/Prozedur_Beispiele.md
deleted file mode 100644
index 6c914924..00000000
--- a/ImplementationGuide/markdown/Prozedur/Prozedur_Beispiele.md
+++ /dev/null
@@ -1,5 +0,0 @@
-### Beispiele
-
-Valides Minimalbeispiel Prozedur:
-
-{{json:appendektomie}}
diff --git a/ImplementationGuide/markdown/Prozedur/Prozedur_Interaktionen.md b/ImplementationGuide/markdown/Prozedur/Prozedur_Interaktionen.md
deleted file mode 100644
index 82ce263c..00000000
--- a/ImplementationGuide/markdown/Prozedur/Prozedur_Interaktionen.md
+++ /dev/null
@@ -1,75 +0,0 @@
-### Interaktionen
-
-Für die Ressource Procedure MUSS die REST-Interaktion "READ" implementiert werden.
-
-Folgende Suchparameter sind für das Bestätigungsverfahren relevant, auch in Kombination:
-
-1. Der Suchparameter "_id" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Procedure?_id=test```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "_id" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Parameters for all resources"](https://hl7.org/fhir/R4/search.html#all).
-
-1. Der Suchparameter "status" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Procedure?status=http://hl7.org/fhir/event-status|entered-in-error```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Procedure.status" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "category" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Procedure?category=http://snomed.info/sct|387713003```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Procedure.category" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "code" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Procedure?code=http://fhir.de/CodeSystem/bfarm/ops|5-470```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Procedure.code" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "subject" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Procedure?subject=Patient/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Procedure.subject" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-1. Der Suchparameter "patient" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Procedure?patient=Patient/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "patient" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
- Dieser Suchparameter ist für die Umsetzung des IHE QEDm Profils verpflichtend.
-
-1. Der Suchparameter "encounter" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Procedure?encounter=Encounter/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "encounter" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-1. Der Suchparameter "date" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Procedure?date=lt2020-26-10```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "date" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Date Search"](https://hl7.org/fhir/R4/search.html#date).
-
- Dieser Suchparameter ist für die Umsetzung des IHE QEDm Profils verpflichtend.
-
----
diff --git a/ImplementationGuide/markdown/Prozedur/Prozedur_Kompatibilitaet.md b/ImplementationGuide/markdown/Prozedur/Prozedur_Kompatibilitaet.md
deleted file mode 100644
index 47fc9744..00000000
--- a/ImplementationGuide/markdown/Prozedur/Prozedur_Kompatibilitaet.md
+++ /dev/null
@@ -1,8 +0,0 @@
-### Kompatibilität
-
-Für das Profil ISIKProzedur wird eine Kompatibilität mit folgenden Profilen angestrebt; allerdings kann nicht sichergestellt werden, dass Instanzen, die gegen ISIKProzedur valide sind, auch valide sind gegen:
-* [Profil "Prozedur" der Medizininformatik Initiative](https://www.medizininformatik-initiative.de/fhir/core/modul-prozedur/StructureDefinition/Procedure)
-
-Hinweise zu Inkompatibilitäten können über die [Portalseite](https://service.gematik.de/servicedesk/customer/portal/16) gemeldet werden..
-
----
diff --git a/ImplementationGuide/markdown/Prozedur/Prozedur_Motivation.md b/ImplementationGuide/markdown/Prozedur/Prozedur_Motivation.md
deleted file mode 100644
index 84568453..00000000
--- a/ImplementationGuide/markdown/Prozedur/Prozedur_Motivation.md
+++ /dev/null
@@ -1,10 +0,0 @@
-### Motivation
-
-Die Möglichkeit auf eine Übersicht der Prozeduren eines Patienten zuzugreifen, Patienten anhand durchgeführter oder geplanter Prozeduren zu suchen, oder zu prüfen, ob eine konkrete Prozedur bei einem Patienten durchgeführt wurde, sind wichtige Funktionen im klinischen Behandlungsablauf.
-
-In FHIR werden Prozeduren mit der [Procedure](https://hl7.org/fhir/R4/procedure.html)-Ressource repräsentiert.
-
-Da die Prozeduren in klinischen Primärsystemen, in der Regel, in OPS-codierter Form vorliegen, fordert ISiK in erster Linie diese Form des Austausches.
-Falls eine Prozedur zwar dokumentiert aber noch nicht codiert wurde (z.B. wenn die Kodierung erst nach der Entlassung erfolgt), ist alternativ eine Repräsentation als Freitext-Prozedur möglich.
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Prozedur/Prozedur_Profil.md b/ImplementationGuide/markdown/Prozedur/Prozedur_Profil.md
deleted file mode 100644
index 3692b8a2..00000000
--- a/ImplementationGuide/markdown/Prozedur/Prozedur_Profil.md
+++ /dev/null
@@ -1,35 +0,0 @@
-### Profil
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKProzedur' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKProzedur, hybrid}}
-
----
-
-**Constraints**
-
-Folgende FHIRPath-Constraints sind im Profil zu beachten:
-
-@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKProzedur' for differential.element.constraint select key, severity, human, expression```
-
----
-
-**Terminology Bindings**
-
-@```
-from StructureDefinition
-where url in ('https://gematik.de/fhir/isik/StructureDefinition/ISiKProzedur' )
-for differential.element
-select
-Path: path,
-join binding.where(valueSet.exists())
-{
- Name: valueSet.substring((9 + valueSet.indexOf('ValueSet/'))),
- Strength: strength,
- URL: valueSet
-}
-```
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/ReleaseNotes.md b/ImplementationGuide/markdown/ReleaseNotes.md
deleted file mode 100644
index a8afa986..00000000
--- a/ImplementationGuide/markdown/ReleaseNotes.md
+++ /dev/null
@@ -1,301 +0,0 @@
-# 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: 4.0.1
-
-Datum: tbd
-
-
-
-----
-
-Version: 4.0.0
-
-Datum: 30.8.2024
-
-* Neudefinition der bestätigungsrelevanten Systeme https://github.com/gematik/spec-ISiK-Basismodul/pull/426
-* Überarbeitung des Abschnitts zu Suchparametern mit Änderung der Anforderungen https://github.com/gematik/spec-ISiK-Basismodul/pull/411
-* Überarbeitung der Must Support Definition: https://github.com/gematik/spec-ISiK-Basismodul/pull/412
-* Hinzufügen von MS und weitere Anpassung von Encounter.location, um Abbildung von Standort-Historie zu ermöglichen: https://github.com/gematik/spec-ISiK-Basismodul/pull/407
-* Added MS for Account.coverage.priority https://github.com/gematik/spec-ISiK-Basismodul/pull/405 and https://github.com/gematik/spec-ISiK-Basismodul/pull/406
-* Erläuterung zur Handhabung von Mime-Types im Fall der Rückgabe von Binaries in ihrer nativen Form hinzugefügt: https://github.com/gematik/spec-ISiK-Basismodul/pull/380
-* Hinzufügen von MS für Coverage.subscriber.reference für Gesetzlich- und Privatversicherte https://github.com/gematik/spec-ISiK-Basismodul/pull/408
-* Hinzufügen von Use Case Beschreibungen (nicht normativ) https://github.com/gematik/spec-ISiK-Basismodul/pull/399
-* Hinzufügen einer Referenz zwischen Observation-Seiten und Profildarstellung
-* Entfernen der MS-Flag für .id, da irreführend https://github.com/gematik/spec-ISiK-Basismodul/pull/414
-* Fix Beispiel DorisResultat für patient-merge https://github.com/gematik/spec-ISiK-Basismodul/pull/415
-* Anforderung zu Procedure.Encounter hinzu https://github.com/gematik/spec-ISiK-Basismodul/pull/419
-* Änderung der MS-Definition für Patient.active https://github.com/gematik/spec-ISiK-Basismodul/pull/421
-* Definition für MS bei Condition.clinicalStatus geschwächt https://github.com/gematik/spec-ISiK-Basismodul/pull/422
-* SnomedCT Coding.version muss auf die German Edition zeigen https://github.com/gematik/spec-ISiK-Basismodul/pull/417
-* ISiKAngehoeriger: hinzufügen von MS auf .relation & .telecom, entfernen der gender extension https://github.com/gematik/spec-ISiK-Basismodul/pull/417
-* ISiKDiagnose: hinzufügen von MS auf .bodySite incl. SnomedCT Slice zur Kodierung https://github.com/gematik/spec-ISiK-Basismodul/pull/417
-* ISiKOrganisation: identifier:TelematikId hinzugefügt https://github.com/gematik/spec-ISiK-Basismodul/pull/417
-* Harmonisierung mit Anforderung mit Kontakt/Fall-Seite https://github.com/gematik/spec-ISiK-Basismodul/pull/424
-* Definition für MS bei Condition.clinicalStatus geschwächt https://github.com/gematik/spec-ISiK-Basismodul/pull/422 und https://github.com/gematik/spec-ISiK-Basismodul/pull/423
-* Hinzufügen von ValueSets zur Harmonisierung der Organisation mit den Anpassungen im Modul Terminplanung https://github.com/gematik/spec-ISiK-Basismodul/pull/418
-* Fix des ValueSets für SNOMED-CT-Diagnosen (entspricht TC 3.0.5) https://github.com/gematik/spec-ISiK-Basismodul/pull/398
-
-----
-
-Version: 4.0.0-rc2
-
-Datum: 4.4.2024
-
-* Neues Feature: Patient merge Notification; Hinzufügen MustSupport für Patient.link & patient-merge Subscription(Topic) https://github.com/gematik/spec-ISiK-Basismodul/pull/359
-* Neue Profile für Standort und Organisation https://github.com/gematik/spec-ISiK-Basismodul/pull/358
-* Neue Profile für Allergien https://github.com/gematik/spec-ISiK-Basismodul/pull/369
-* Neue Profile für Lebenszustände - Schwangerschaftsstatus, SS-ET, Raucher & Alkoholabususstatus by @patrick-werner in https://github.com/gematik/spec-ISiK-Basismodul/pull/378
- * Hinzugefügt Lebenszustand markdown descriptions by @patrick-werner in https://github.com/gematik/spec-ISiK-Basismodul/pull/379
-* Feature: Ptdata 827 reha entlassung by @alexzautke in https://github.com/gematik/spec-ISiK-Basismodul/pull/393
-* Update Deutsche Basisprofile v1.5.0 by @alexzautke in https://github.com/gematik/spec-ISiK-Basismodul/pull/372
-* Verwende IdentifierAbrechnungsnummer aus den Deutschen Basisprofilen by @alexzautke in https://github.com/gematik/spec-ISiK-Basismodul/pull/381
-* Abkündigen der Slices zu VersichertenId-GKV und ersetzen mit generischer Versicherten-ID : https://github.com/gematik/spec-ISiK-Basismodul/pull/382/files
-* Fix/canonical to new format by @patrick-werner in https://github.com/gematik/spec-ISiK-Basismodul/pull/383
-* Feature/ptdata 821 account abrechnungsart by @alexzautke in https://github.com/gematik/spec-ISiK-Basismodul/pull/386
-* Feature/ptdata 671 // MS für coding.version by @patrick-werner in https://github.com/gematik/spec-ISiK-Basismodul/pull/390
-* Feature: added Allergyintollerance to CapStatement by @patrick-werner in https://github.com/gematik/spec-ISiK-Basismodul/pull/385
-* Lockerung der Anforderung für den Suchparameter "context-type-value" definiert für ISiKValueSet zu "KANN"
-
-----
-
-Version: 3.0.5
-
-Diese Technical Correction entfällt für Stufe 4, da die Änderungen direkt in Stufe 4 eingebracht sind.
-
-----
-
-Version: 3.0.4
-
-Datum: 1.3.2024
-
-* Entfernen der Festlegungen zum .identifier in ISiKVersicherungsverhaeltnisGesetzlich: https://github.com/gematik/spec-ISiK-Basismodul/pull/362
-* Korrektur der Anforderung zur Encounter-Kontaktebene: https://github.com/gematik/spec-ISiK-Basismodul/pull/363
-* Hinweis zur Nutzung des Suchparameter "context-type-value" hinzugefügt: https://github.com/gematik/spec-ISiK-Basismodul/pull/367
-* Änderung der Anforderung zu KANN für Profil ISIKKatalog: https://github.com/gematik/spec-ISiK-Basismodul/pull/367
-* Lockerung für Extension Kardinalität in Account zu ..* und hinzufügen einer Beschreibung: https://github.com/gematik/spec-ISiK-Basismodul/pull/366
-
-
-----
-Version: 3.0.3
-
-Datum: 15.01.2024
-
-* Anpassung und Harmonisierung der Anforderungen zu HTTP-Responses: update HTTP response requirement #308 by @f-peverali in https://github.com/gematik/spec-ISiK-Basismodul/pull/354
-
-**Full Changelog**: https://github.com/gematik/spec-ISiK-Basismodul/compare/v.3.0.2...v.3.0.3
-
-----
-Version: 3.0.2
-
-Datum: 09.01.2024
-
-* Hinzufügen optionaler Suchparameter für RelatedPerson: Add new optional SearchParameter for RelatedPerson.address - Feature/anfisk 146 search related person by @f-peverali in https://github.com/gematik/spec-ISiK-Basismodul/pull/346
-
-**Full Changelog**: https://github.com/gematik/spec-ISiK-Basismodul/compare/v.3.0.1...v.3.0.2
-
-----
-Version: 3.0.1
-
-Datum: 05.12.2023
-
-* Obsoleter SNOMED Code ersetzt: https://github.com/gematik/spec-ISiK-Basismodul/pull/322/commits/d72f3a08a41b999074b4f33db299d5d71cd04be9
-* Hinweis zur Nutzung der ISIKBinary-Ressource hinzugefügt: https://github.com/gematik/spec-ISiK-Basismodul/pull/322/commits/7dc3026686856efd3e61660a37f1e15955d45a11
-* Invariante zur Strassenanschrift modifiziert - fix invariant context #330: https://github.com/gematik/spec-ISiK-Basismodul/pull/322/commits/345d776f3b75442e391d8787c71a051628050b9e
- * hier auch Constraint bezüglich ISiKAngehoeriger aus Strassenanschrift entfernt
-* Anforderungen im CapabilityStatement zum Account entsprechend der textuellen Anforderungen angepasst: https://github.com/gematik/spec-ISiK-Basismodul/pull/322/commits/ac4d2c730bb94dd50cc4f5deea8c2b1344329d2c
-* Neue (klärende) Anforderung zum Versorgungsstellenkontakt: https://github.com/gematik/spec-ISiK-Basismodul/pull/322/commits/d7005923c4596f8a646468f20e1f9975f2489bef
-* Öffnung der Festlegung einer Coverage-ID - fix identifier slices + add MS beneficiary + rm MS kvid: https://github.com/gematik/spec-ISiK-Basismodul/pull/322/commits/bd66cca38397b987581bece3d2e9f508813ff765
-* Zielstellung zur Interoperabilität der Profile angepasst: https://github.com/gematik/spec-ISiK-Basismodul/pull/322/commits/3130973de182a078208f181a64ff1cfd8783493a
-
-
-**Full Changelog**: https://github.com/gematik/spec-ISiK-Basismodul/compare/v.3.0.0...v.3.0.1
-
-----
-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-rc3
-
-Datum: 30.05.2023
-
-* Allgemein: Vorgaben zur Herkunftsausweisung/Provenance (meta.tag) gelockert
- * update provenance constraints by @f-peverali in https://github.com/gematik/spec-ISiK-Basismodul/pull/263
-* ISiKCapabilityStatementBasisServer: Read Shall für Composition entfernt
- * fix capability for Composition #259 by @f-peverali in https://github.com/gematik/spec-ISiK-Basismodul/pull/260
-* ISiKAbrechnungsfall:
- * Änderung des Kodierungs-Pattern, Value Set hinzugefügt und Beispiel angepasst
- * Enhancement/account identifier by @f-peverali in https://github.com/gematik/spec-ISiK-Basismodul/pull/238
- * Update/identifier Abrechnungsnummer vs by @f-peverali in https://github.com/gematik/spec-ISiK-Basismodul/pull/269
- * Änderung der falschen Kardinalität
- * fix cardinality #258 by @f-peverali in https://github.com/gematik/spec-ISiK-Basismodul/pull/262
- * Nur der Patient als Subject zugelassen
- * Update/account.subject only patient #251 by @f-peverali in https://github.com/gematik/spec-ISiK-Basismodul/pull/265
-* ISiK Prozedur: MS für SNOMED-Codierung
- * add: MS for SNOMED by @f-peverali in https://github.com/gematik/spec-ISiK-Basismodul/pull/239
-* ISiKVersicherungsverhaeltnisSelbstzahler: Organisation als zahlende Instanz hinzugefügt
- * add: organization as payor by @f-peverali in https://github.com/gematik/spec-ISiK-Basismodul/pull/236
-* ISiK KontaktGesundheitseinrichtung: Suchparameter für Encounter.date start/end aus R5 übernommen
- * feat: Encounter.date start/end SearchParameters backported from R5, e… by @patrick-werner in https://github.com/gematik/spec-ISiK-Basismodul/pull/242
-* ISiKBerichtSubSysteme: References generisch statt ISiK-spezifisch
- * update Reference - Kommentierung Stufe 3 by @f-peverali in https://github.com/gematik/spec-ISiK-Basismodul/pull/256
-
-----
-Version: 3.0.0-rc2
-
-Datum: 03.04.2023
-
-* KontaktGesundheitseinrichtung: SearchParameter aus FHIR-R5 für Encounter.period als Custom SearchParameter eingeführt, um die effektive Suche auf Encounter ohne abgeschlossene "period" zu ermöglichen
- * feat: Encounter.date start/end SearchParameters backported from R5, e… by @patrick-werner in
-
-----
-Version: 3.0.0-rc1
-
-Datum: 31.03.2023
-
-* ISiKAbrechnungsfall: Identifier-Pattern und Kodierung ersetzt durch Anpassung an das Basisprofil DE Pre-Release
- * Enhancement/account identifier by @f-peverali in
-* ISiKProzedur: SNOMED-Kodierung auf Must Support gesetzt
- * add: MS for SNOMED by @f-peverali in
-* ISiKVersicherungsverhaeltnisSelbstzahler: Organisation als möglicher 'payor' hinzugefügt (es gibt auch Konstellationen, in denen die Zahlung direkt über die PKV erfolgt)
- * add: organization as payor by @f-peverali in
-
-**Full Changelog**:
-
-----
-Version: 2.0.5
-
-Datum: 24.03.2023
-
-- Änderungen am IG
- - Hinweis Inkompatibilität zu KBV Basisprofile bei Patient.Adress.country
- - Einschränkung der Umsetzungspflicht für Suchparameter vom Typ "Token" auf Datentypen "code", "Coding" oder "CodeableConcept"
-- ISiKBerichtBundle
- - Slicing-Korrektur - betrifft Validierung und erfordert keine Anpassung von Seiten der Implementierung (https://github.com/gematik/spec-ISiK-Basismodul/pull/202/commits/e4cf702116c0d9c7a11260efc4cc9e583ba4ea889)
-- ISiKPatient (Beispiel - erfordert keine Anpassung von Seiten der Implementierung)
- - Fixed identifier-Slicing of Type VersichertenId-GKV
-
-----
-Version: 2.0.4
-
-Datum: 31.01.2023
-
-- ISiKVersicherungsverhaeltnisGesetzlich
- - ```Reference``` auf Kernspezifikation-Profil RelatedPerson statt ISiKAngehoeriger (entspricht allgemeinem Design-Prinzip)
- - ```Coverage.beneficiary.identifier``` URL in ```patternidentifier.system``` ersetzt
-- weitere Änderungen an Implementierungsleitfaeden (informativ)
-
-----
-Version: 2.0.3
-
-Datum: 21.12.2022
-
-- CapabilityStatemtent
- - Composition und Bundle-Parameter hinzugefügt
-- ISiKBerichtSubsystem
- - ```encounter``` auf FHIR-Core gesetzt
-- ISiKBerichtBundle
- - Beispiele hinzugefügt
-- Weitere geringfügige Änderungen am Implementierungsleitfaden
-
-
-
-----
-Version: 2.0.2
-
-Datum: 31.10.2022
-
-- Bericht für Subsysteme
- - ```id``` ist nun 0..1
-- Kontakt
- - ```id``` ist nun 0..1
-- Patient
- - ```id``` ist nun 0..1
- - Der Identifier ```Versichertennummer-GKV``` wurde zu ```VersichertenId-GKV```
-- Prozedur
- - ```id``` ist nun 0..1
-- Versicherungeverhältnis Gesetzlich
- - ```id``` ist nun 0..1
- - ```type.coding``` ist nun Must Support
- - ```VersicherungsArtDeBasis``` ist nun Must Support
-- Invarianten wurden verbessert
-
-----
-Version: 2.0.1
-
-Datum: 30.09.2022
-
-* ISiKPatient:
- * .address.Strassenanschrift.extension:Stadtteil, .type, .status nun Must Support
-* ISiKPersonImGesundheitsberuf:
- * .address.Strassenanschrift.extension:Stadtteil, nun Must Support
-* ISiKAngehöriger:
- * .address.Strassenanschrift.extension:Stadtteil, nun Must Support
-* ISiKAbrechnungsfall
- * .identifier.system im Example nun https://test.krankenhaus.de/fhir/sid/besuchsnummer
-* ISiKKontaktGesundheitseinrichtung
- * .identifier.system im Example nun https://test.krankenhaus.de/fhir/sid/besuchsnummer
-* ISiKVersicherungsverhaeltnisGesetzlich
- * .type ist nun Must Support
-* ISiKVersicherungsverhaeltnisSelbstzahler
- * .type und .status ist nun Must Support
-
-----
-Version: 2.0.0
-
-Datum: 30.06.2022
-
-* Allgemein:
- * Alle Conformance Ressourcen enthalten den Prefix "https://gematik.de/fhir/isik/v2/Basismodul/" in ihrer Canonical URL
- * Erweiterung des Abschnittes "Verpflichtende Suchparameter (Alle Datenobjekte)" durch _tag, , _count, _include, _revinclude
- * Best Practice Empfehlungen für Standard-Suchfilter hinzugefügt
- * Verpflichtung :type-Modifier auf Referenzen hinzugefügt
- * Aufhebung der Einschränkung von Chaining und Reverse Chaining auf die Referenzen "patient", "subject" und "encounter"
- * Anpassung der Vorgaben für den "Self"-Link als Antwort auf eine Suchanfrage.
-* Neue Profile hinzugefügt:
- * ISiKAbrechnungsfall
- * ISiKBerichtBundle
- * ISiKBinary
- * ISiKCodeSystem
- * ISiKValueSet
-* ISiKAngehöriger:
- * Target Profil Einschränkung auf ISiKPatient in RelatedPerson.patient aufgehoben
-* ISiKBerichtSubsystem:
- * Must-Support Flags hinzugefügt
-* ISiKDiagnose:
- * Beschreibung von "isik-con1"-Constraint korrigiert
- * Must Support Flag für Extension "related" hinzugefügt
-* ISiKPatient:
- * Umbenennung Slice von "Patient.identifier:Versichertennummer-GKV in "Patient.identifier:VersichertenId-GKV"
-* ISiKPersonImGesundheitsberuf:
- * Element "Practitioner.identifier:TelematikId" hinzugefügt (must-support)
-* ISiKVersicherungsverhaeltnisGesetzlich:
- * Must-Support Flag auf "Coverage.payor.identifier.type" hinzugefügt
-* ISiKKontaktGesundheitseinrichtung
- * Constraints ISiK-enc-2 bis ISiK-enc-8 hinzugefügt
- * Extensions plannedStartDate, plannedEndDate und Wahlleistung hinzugefügt
- * Änderung Kardinalität von Element "Encounter.identifier:Aufnahmenummer.type" auf 1..1
- * Änderung Kardinalität von Element "Encounter.type:Kontaktebene" auf 1..1
- * Element "Encounter.serviceType.coding:ErweiterterFachabteilungsschluessel" hinzugefügt
- * Änderung Kardinalität von "Encounter.period" von 1..1 auf 0..1
- * Element "Encounter.diagnosis.use.coding:Diagnosetyp" und "Encounter.diagnosis.use.coding:DiagnosesubTyp" hinzugefügt
- * Must-Support Flag auf Element "Encounter.account" hinzugefügt
- * Änderung der Binding-Strength des Elementes "Encounter.hospitalization.admitSource" von "preferred" auf "extensible"
- * Extensible ValueSet zu Element "Encounter.location.physicalType" hinzugefügt
- * Anstelle von "Encounter.location.location.display" ist nun "Encounter.serviceProvider.identifier" zu verwenden
- * Must-Support-Flag entfernt auf Element "Encounter.partOf"
-
-----
-Version: 2.0.0-ballot
-
-Datum: 08.04.2022
-
-* Initiale Ballotierungsversion für ISiK Stufe 2
-----
diff --git a/ImplementationGuide/markdown/Standort/Standort_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/Standort/Standort_AnmerkungenZuDenMustSupportFeldern.md
deleted file mode 100644
index e3241679..00000000
--- a/ImplementationGuide/markdown/Standort/Standort_AnmerkungenZuDenMustSupportFeldern.md
+++ /dev/null
@@ -1,6 +0,0 @@
-### Anmerkungen zu Must-Support-Feldern
-
-Zu beachten sind die die Comment-Felder der einzelnen (Sub-)Elemente im Profil.
-
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Standort/Standort_Beispiele.md b/ImplementationGuide/markdown/Standort/Standort_Beispiele.md
deleted file mode 100644
index 037b2759..00000000
--- a/ImplementationGuide/markdown/Standort/Standort_Beispiele.md
+++ /dev/null
@@ -1,9 +0,0 @@
-### Beispiele
-
-Ein Minimalbeispiel zum Standort Bettenstellplatz:
-{{json:BettenstellplatzStandortBeispiel}}
-
-
-Ein Minimalbeispiel zum Standort Raum:
-{{json:RaumStandortBeispiel}}
-
diff --git a/ImplementationGuide/markdown/Standort/Standort_Interaktionen.md b/ImplementationGuide/markdown/Standort/Standort_Interaktionen.md
deleted file mode 100644
index 1400e7ba..00000000
--- a/ImplementationGuide/markdown/Standort/Standort_Interaktionen.md
+++ /dev/null
@@ -1,73 +0,0 @@
-### Interaktionen
-
-Sofern die Ressourcen zum Standort unterstützt werden, SOLL die REST-Interaktion "READ" implementiert werden. Ebenso SOLL die REST-Interaktion "UPDATE" implementiert werden. Letztere dient insbesondere dem Synchronisieren des Status (.operationalStatus) der abgeleiteten Ressourcen ISiKStandortRaum und ISiKStandortBettenstellplatz - u.a. zur Kennzeichnung als "Frei", "Besetzt", "Kontaminiert", "Isoliert", in "Reinigung" etc.
-
-
-Interaktionen zum Standort werden derzeit für das Bestätigungsverfahren nicht festgelegt.
-
-Auf folgende Suchparameter sei aufgrund der Relevanz hingewiesen - diese SOLLEN implementiert werden, falls die oben genannten Ressourcen unterstützt werden:
-
-
-1. Der Suchparameter "identifier" SOLL unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Location?identifier=http://fhir.krankenhaus.example|260120196```
-
- ```GET [base]/Location?identifier=345678975```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Location.identifier" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "operational-status" SOLL unterstützt werden:
-
- Beispiel zur Suche freier Standorte:
-
- ```GET [base]/Location?operational-status=Unoccupied```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Location.operational-status" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "organization" SOLL unterstützt werden:
-
- Beispiel zur Suche von Standorten einer Organisation:
-
- ```GET [base]/Location?organization=AbteilungAllgemeinchirurgieOrganisationBeispiel```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Location.organization" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://hl7.org/fhir/R4/search.html#reference).
-
-1. Der Suchparameter "partof" SOLL unterstützt werden:
-
- Beispiel zur Suche nach Standort-Zugehörigkeit eines Raums (Zu welcher Abteilung gehört dieser Raum?):
- ```GET [base]/Location?partof=RaumStandortBeispiel```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Location.partof" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://hl7.org/fhir/R4/search.html#reference).
-
-1. Der Suchparameter "address" KANN unterstützt werden:
-
- Beispiele
-
- ```GET [base]/Location?address=Berlin```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Location.address" finden sich in der [FHIR-Basisspezifikation - Abschnitt "String Search"](https://hl7.org/fhir/R4/search.html#string).
-
-1. Der Suchparameter "type" KANN unterstützt werden:
-
- Beispiel zur Suche nach Typ eines Standorts:
- ```GET [base]/Location?type=bed```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Location.type" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "contains" KANN unterstützt werden:
-
- Beispiel zur Suche nach Standort-Zugehörigkeit eines Raums:
- ```GET [base]/Location?contains=KoordinatenBeispielGeoJSON```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Location.contains" finden sich in der [FHIR-Basisspezifikation - Abschnitt "String Search"](https://hl7.org/fhir/R4/search.html#string).
-
-1. Der Suchparameter "near" KANN unterstützt werden:
-
- Beispiel zur Suche nach Standort nahe (100m) Koordinaten:
- ```GET [base]/Location?contains=52.525851|13.37774|100|m```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Location.near" finden sich in der [FHIR-Basisspezifikation - Abschnitt "String Search"](https://hl7.org/fhir/R4/search.html#string).
-
-
diff --git a/ImplementationGuide/markdown/Standort/Standort_Kompatibilitaet.md b/ImplementationGuide/markdown/Standort/Standort_Kompatibilitaet.md
deleted file mode 100644
index a5ae1b4d..00000000
--- a/ImplementationGuide/markdown/Standort/Standort_Kompatibilitaet.md
+++ /dev/null
@@ -1,5 +0,0 @@
-### Kompatibilität
-
-Für das Profil ISiKStandort wurde bis zum Zeitpunkt der Veröffentlichung kein Abgleich der Kompatibilität zu anderen Profilen (der KBV und der Medizininformatik-Initiative) durchgeführt.
-
----
diff --git a/ImplementationGuide/markdown/Standort/Standort_Motivation.md b/ImplementationGuide/markdown/Standort/Standort_Motivation.md
deleted file mode 100644
index d50ee957..00000000
--- a/ImplementationGuide/markdown/Standort/Standort_Motivation.md
+++ /dev/null
@@ -1,27 +0,0 @@
-### Motivation
-In FHIR wird die Organisation (Organization) vom Standort (Location) eindeutig abgegrenzt.
-
-Die Abbildung von Standorten in einem Krankenhaus unterstützt u.a. die Raum- und Bettenbelegung in strukturierter Form.
-
-Die Erfassung des Standortes in strukturierter Form soll u.a. ermöglichen:
-- Zuweisungen von Diensten an bestimmte Standorte im Rahmen des Terminmanagements
-- Die Raum- und Betten-Belegung in strukturierter Form (interdisziplinär) - u.a. für
- - Patientenportale im Rahmen der Terminbuchung, z.B. um den Wunsch nach Einzelbett, bzw. 1 oder 2 Betten abzubilden
- - KIS und weitere Subsysteme:
- - zur Patientenabholung und Information für den Transportdienst
- - Abbildung der Verfügbarkeit eines spezifischen Bettenstellplatzes (z.B. mit spezifischem Monitoring-Device)
-- Im Rahmen der Versorgung kann eine der folgenden Beispiel-Fragen beantworten werden:
- - Handelt es sich um ein Isolationszimmer?
- - Gibt es bestimmte Ausstattung, z.B. Beatmungsgeräte?
- - etc.
-
-Dafür werden Standort-Profile in unterschiedlicher Granularität definiert.
-
----
-
-#### Normativer Status und Bestätigung
-
-Diese Profile MÜSSEN im Rahmen der Bestätigung NICHT unterstützt werden. Falls ein Profil unterstützt wird, SOLLEN die hier definierten Festlegungen greifen.
-
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Standort/Standort_Profil.md b/ImplementationGuide/markdown/Standort/Standort_Profil.md
deleted file mode 100644
index 84a44613..00000000
--- a/ImplementationGuide/markdown/Standort/Standort_Profil.md
+++ /dev/null
@@ -1,92 +0,0 @@
-### FHIR-Profile
-
-Das Profil ISiKStandort soll auch den Standort eines Krankenhauses abbilden können.
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKStandort' select Name: name, Canonical: url
-```
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKStandort, hybrid}}
-
-Folgende FHIRPath-Constraints sind im Profil zu beachten:
-
-@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKStandort' for differential.element.constraint select key, severity, human, expression```
-
-**Terminology Bindings**
-
-@```
-from StructureDefinition
-where url in ('https://gematik.de/fhir/isik/StructureDefinition/ISiKStandort' )
-for differential.element
-select
-Path: path,
-join binding.where(valueSet.exists())
-{
- Name: valueSet.substring((9 + valueSet.indexOf('ValueSet/'))),
- Strength: strength,
- URL: valueSet
-}
-```
-
----
-
-Folgendes Profil dient der Abbildung eines Raums:
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKStandortRaum' select Name: name, Canonical: url
-```
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKStandortRaum, hybrid}}
-
-Folgende FHIRPath-Constraints sind im Profil zu beachten:
-
-@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKStandort' for differential.element.constraint select key, severity, human, expression```
-
-**Terminology Bindings**
-
-@```
-from StructureDefinition
-where url in ('https://gematik.de/fhir/isik/StructureDefinition/ISiKStandortRaum' )
-for differential.element
-select
-Path: path,
-join binding.where(valueSet.exists())
-{
- Name: valueSet.substring((9 + valueSet.indexOf('ValueSet/'))),
- Strength: strength,
- URL: valueSet
-}
-```
-
----
-
-Folgendes Profil dient der Abbildung eines Bettenstellplatzes :
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKStandortBettenstellplatz' select Name: name, Canonical: url
-```
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKStandortBettenstellplatz, hybrid}}
-
-Folgende FHIRPath-Constraints sind im Profil zu beachten:
-
-@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKStandortBettenstellplatz' for differential.element.constraint select key, severity, human, expression```
-
----
-
-**Hinweis:** Ein einzelnes Bett als Gegenstand kann als FHIR-Ressource 'Device' abgebildet werden, das einen Bettenstellplatz referenziert.
-
-**Terminology Bindings**
-
-@```
-from StructureDefinition
-where url in ('https://gematik.de/fhir/isik/StructureDefinition/ISiKStandortBettenstellplatz' )
-for differential.element
-select
-Path: path,
-join binding.where(valueSet.exists())
-{
- Name: valueSet.substring((9 + valueSet.indexOf('ValueSet/'))),
- Strength: strength,
- URL: valueSet
-}
-```
-
-
diff --git a/ImplementationGuide/markdown/Subscription/Subscription_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/Subscription/Subscription_AnmerkungenZuDenMustSupportFeldern.md
deleted file mode 100644
index 4b4b7887..00000000
--- a/ImplementationGuide/markdown/Subscription/Subscription_AnmerkungenZuDenMustSupportFeldern.md
+++ /dev/null
@@ -1,49 +0,0 @@
-### Anmerkungen zu den Must-Support-Feldern
-
-### `Subscription.status`
-
-**Bedeutung:** Der Status der Subscription, der den Serverstatus der Subscription angibt. Neue Subscriptions werden immer mit dem Status `requested` an den Server übergeben. Der Server ändert im Anschluss den Status auf `active` oder im Fehlerfall auf `error`.
-
-**Hinweise:** Siehe [R4 Subscriptions](https://hl7.org/fhir/R4/subscription.html)
-
-### `Subscription.reason`
-
-**Bedeutung:** Beschreibung wieso diese Subscription erstellt wurde.
-
-**Hinweise:** Siehe [R4 Subscriptions](https://hl7.org/fhir/R4/subscription.html)
-
-### `Subscription.category`
-
-**Bedeutung:** Canonical URL des Subscription-Topics, aktuell wird nur folgendes SubscriptionTopic unterstützt: https://gematik.de/fhir/isik/SubscriptionTopic/patient-merge
-
-**Hinweise:** Siehe [Subscriptions R5 Backport](https://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition-backport-subscription.html)
-
-### `Subscription.type`
-
-**Bedeutung:** Der Typ des Kommunikationskanals, über den Subscription-Benachrichtigungen gesendet werden sollen.
-
-**Hinweise:** Siehe [R4 Subscriptions](https://hl7.org/fhir/R4/subscription.html)
-
-### `Subscription.endpoint`
-
-**Bedeutung:** Adresse des Kommunikationskanals/ Endpunkts, an den Subscription-Benachrichtigungen gesendet werden sollen. Dies ist nur für rest-hook Subscriptions relevant.
-
-**Hinweise:** Siehe [R4 Subscriptions](https://hl7.org/fhir/R4/subscription.html)
-
-### `Subscription.payload`
-
-**Bedeutung:** Format in dem Subscription Notifications versendet werden sollen (JSON oder XML)
-
-**Hinweise:** Siehe [R4 Subscriptions](https://hl7.org/fhir/R4/subscription.html)
-
-### `Subscription.payload.extension[content]`
-
-**Bedeutung:** Welcher Ressourceninhalt in der Nutzlast der Benachrichtigung geliefert werden soll. Zur Auswahl stehen eine leere Nutzlast (`empty`), nur die Ressourcen-id (`id-only`) oder der gesamte Inhalt der Ressource (`full-resource`).
-
-**Hinweise:** Siehe [Extension: Backport R5 Subscription Payload Content Information](https://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition-backport-payload-content.html)
-
-### `Subscription.header`
-
-**Bedeutung:** http-Header welcher dazu genutzt werden kann einen Authorization-header zu setzen. Dies ist nur für rest-hook Subscriptions relevant.
-
-**Hinweise:** ACHTUNG: dieses Datenfeld muss bei READ-Interaktionen maskiert werden! Siehe [R4 Subscriptions](https://hl7.org/fhir/R4/subscription.html)
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Subscription/Subscription_Beispiele.md b/ImplementationGuide/markdown/Subscription/Subscription_Beispiele.md
deleted file mode 100644
index 1af91da4..00000000
--- a/ImplementationGuide/markdown/Subscription/Subscription_Beispiele.md
+++ /dev/null
@@ -1,15 +0,0 @@
-### Beispiele
-
-#### Subscription
-
-{{json:Resources/fsh-generated/resources/Subscription-PatientMergeSubscriptionExample.json}}
-
-#### SubscriptionNotification-Bundle
-
-{{json:SubscriptionNotificationBundleExample}}
-
-#### Patientenobjekte
-
-Zum Beispiel für den Merge auf Ebene der Patient-Instanzen siehe {{pagelink:ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Patient-merge.md, text:Übergreifende Festlegungen Patient-merge}}.
-
----
diff --git a/ImplementationGuide/markdown/Subscription/Subscription_Interaktionen.md b/ImplementationGuide/markdown/Subscription/Subscription_Interaktionen.md
deleted file mode 100644
index 240ad204..00000000
--- a/ImplementationGuide/markdown/Subscription/Subscription_Interaktionen.md
+++ /dev/null
@@ -1,11 +0,0 @@
-### Interaktionen
-
-Für die Ressource Subscription SOLL die REST-Interaktion "READ", "CREATE", "UPDATE", "DELETE" implementiert werden, insofern der festgelegte Lösungsansatz zu 'Patient merge Notification' implementiert wird.
-
-## Operations
-
-Bei der Umsetzung des Subscription Channel Type `websocket` SOLL die Operation [`$get-ws-binding-token`](https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/OperationDefinition-backport-subscription-get-ws-binding-token.html) supported werden.
-
-Siehe auch: {{pagelink:ImplementationGuide/markdown/CapabilityStatement.md, text:CapabilityStatement}} & {{pagelink:ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Patient-merge.md, text:Patient merge und Notification}}
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Subscription/Subscription_Kompatibilitaet.md b/ImplementationGuide/markdown/Subscription/Subscription_Kompatibilitaet.md
deleted file mode 100644
index 49209257..00000000
--- a/ImplementationGuide/markdown/Subscription/Subscription_Kompatibilitaet.md
+++ /dev/null
@@ -1,8 +0,0 @@
-### Kompatibilität
-
-Das Profil PatientMergeSubscription basiert auf dem [Backport-Subscription Profil](https://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition-backport-subscription.html).
-Der [SubscriptionStatus](https://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition-backport-subscription-status-r4.html), sowie das [Subscription Notification Bundle](https://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition-backport-subscription-notification-r4.html) werden unverändert direkt aus dem [Subscriptions R5 Backport IG](https://hl7.org/fhir/uv/subscriptions-backport/index.html) genutzt.
-
----
-
-
diff --git a/ImplementationGuide/markdown/Subscription/Subscription_Motivation.md b/ImplementationGuide/markdown/Subscription/Subscription_Motivation.md
deleted file mode 100644
index 3d242537..00000000
--- a/ImplementationGuide/markdown/Subscription/Subscription_Motivation.md
+++ /dev/null
@@ -1,9 +0,0 @@
-## Motivation
-
-Subscription ist eine FHIR Ressource, um als Client-System Benachrichtigungen über Events auf dem FHIR Server anzufragen. Der Subscription Mechanismus in FHIR R4 ist nicht geeignet, um alle relevanten Events (hier im Speziellen das Mergen von Patienten) zu unterstützen. Daher basiert das ISiK Subscription-Profil auf dem [Subscriptions R5 Backport Profil von HL7](https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/StructureDefinition-backport-subscription.html).
-
-Siehe auch: {{pagelink:ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Patient-merge.md, text:Übergreifende Festlegungen Patient-merge}}
-
-Um als Subsystem über ein Patienten-Merge-Event informiert zu werden, KANN der FHIR Subscription Mechanismus gemäß des [Subscriptions R5 Backport IGs von HL7](https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/index.html) genutzt werden.
-
----
diff --git a/ImplementationGuide/markdown/Subscription/Subscription_Profil.md b/ImplementationGuide/markdown/Subscription/Subscription_Profil.md
deleted file mode 100644
index 714c85fe..00000000
--- a/ImplementationGuide/markdown/Subscription/Subscription_Profil.md
+++ /dev/null
@@ -1,11 +0,0 @@
-## Profil
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/patient-merge-subscription' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/patient-merge-subscription, hybrid}}
-
-@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/patient-merge-subscription' for differential.element.constraint select key, severity, human, expression```
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/UebergreifendeFestlegungen/IHE-Konformitaet.md b/ImplementationGuide/markdown/UebergreifendeFestlegungen/IHE-Konformitaet.md
deleted file mode 100644
index dbdffe23..00000000
--- a/ImplementationGuide/markdown/UebergreifendeFestlegungen/IHE-Konformitaet.md
+++ /dev/null
@@ -1,81 +0,0 @@
-### IHE Konformität
-
-Die ISiK-Spezifikation wurde basierend auf folgenden IHE-Spezifikationen entwickelt:
-* [PDQm (Patient Demographic Query for mobile)](https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_PDQm.pdf)
-* [QEDm (Query for Existing Data for mobile)](https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_Suppl_QEDm.pdf)
-
-künftige Ausbaustufen werden auch die Profile
-* [MHD (Mobile access to Health Documents)](https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_MHD.pdf)
-* [mXDE (Mobile Cross-EnterpriseDocument Data Element Extraction)](https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_mXDE.pdf)
-
-berücksichtigen.
-
-Hierbei ist anzumerken, dass der Zusatz "for mobile" seitens IHE irreführend sein kann.
-Konkret fasst IHE unter diesem Begriff nicht nur Systeme zusammen, die "Plattform- und Ressourcenbeschränkt sind, wie z.B. Tablets, Smartphones und Embedded Devices, sondern auch größere Systeme in Umgebungen, in denen die Interoperabilitätsanforderungen einfach sind (z.B. Anzeige der aktuellen Übersicht eines Patienten)" (Quelle: IHE QEDm - Introduction)
-
-Die im Folgenden genannten IHE-Spezifikationen beschreiben lediglich Interaktionen zwischen den Systemen und machen verbindliche Vorgaben zum Ablauf, Format. Zu den unterstützen Parametern wurden jedoch keine inhaltlichen Vorgaben gemacht. So beschreibt PDQm beispielweise den Ablauf einer Suche nach Patientendaten, enthält aber keine Vereinbarungen, wie die zurückgelieferte Patientenressource konkret auszusehen hat (Pflichtfelder, Terminologien, Constraints).
-
-Der Mehrwert der ISiK-Spezifikation besteht darin, dass die genannten IHE-Interaktionen um Festlegungen zu den auszutauschenden Inhalten ergänzt werden. Diese sind auf die Anforderungen des Datenaustausches zwischen Systemen innerhalb einer Einrichtung zugeschnitten. Basierend auf den Deutschen Basisprofilen von HL7 Deutschland e.V., wurde die ISiK-Spezifikation mit den Festlegungen der KBV zu den Inhalten der elektronischen Patientenakte (MIOs) sowie den Spezifikationen der Medizininformatik-Initiative abgeglichen.
-
-Die Darstellungen der in diesen IHE-Profilen festgelegten Interaktionen und UseCases sind den oben verlinkten Dokumenten zu entnehmen.
-
-
-
-
-#### IHE PDQm
-
-##### Umfang
-PDQm unterstützt das Abfragen von demografischen Patientendaten.
-Damit fällt dieser Anwendungsfall vollständig in den Umfang der Festlegungen von ISiK.
-
-##### Akteure
-PDQm definiert die Kommunikation zwischen zwei Akteuren:
-1. dem *Patient Demographics Consumer* und
-2. dem *Patient Demographics Supplier*
-
-Im ISiK Kontext nehmen die
-Systeme die Rolle des Patient Demographics Supplier ein.
-Die *Pediatric Demographics Option* liegt außerhalb des Abdeckungsbereiches von ISiK.
-
-##### Transaktionen
-PDQm definiert die Transaktion *ITI-78 (Mobile Patient Demographics Query)*, deren Grundlagen identisch sind mit den in ISiK definierten Interaktionen.
-Der Unterschied zwischen PDQm und ISiK besteht lediglich darin, dass ISiK nicht alle in PDQm spezifizierten Suchparameter zwingend erfordert.
-
-
-
-#### IHE QEDm
-
-##### Umfang
-QEDm unterstützt das Abfragen klinischer Informationen wie zum Beispiel Diagnosen, Beobachtungen, Messdaten und Allergien unter Verwendung des FHIR-Standards.
-Damit überlappt der Anwendungsfall von QEDm in großen Teilen mit den Festlegungen von ISiK.
-
-##### Akteure
-QEDm definiert die Kommunikation zwischen zwei Akteuren:
-1. dem *Clinical Data Consumer* und
-2. der *Clinical Data Source*
-
-Im ISiK Kontext nehmen die bestätigungsrelevanten Systeme die Rolle der Clinical Data Source mit folgenden Optionen ein:
-
-* Conditions Option
-* Procedures Option
-* Encounters Option
-
-alle weiteren Optionen liegen außerhalb des Abdeckungsbereiches von ISiK.
-
-Die Aufgabe der Clinical Data Source liegt in der Beantwortung der Anfragen nach Informationen durch die Rückgabe von FHIR-Ressourcen, die den gegebenen Suchparametern entsprechen.
-
-##### Transaktionen
-QEDm definiert die Transaktion *PCC-44 (Mobile Query Existing Data)*, deren Grundlagen mit den in ISiK definierten Interaktionen identisch sind.
-Der Unterschied zwischen QEDm und ISiK besteht lediglich darin, dass ISiK über die Vorgaben von PDQm hinaus die Implementierung weiterer Suchparameter fordert.
-
-So beschränkt sich QEDm zum Beispiel auf die Encounter-Suchparameter `patient` und `date`, während ISiK auch die Suche nach der Fallnummer (`identifier`) und weiteren relevanten Kriterien unterstützt.
-
-#### Abweichungen
-Hersteller, die die ISiK-Vorgaben implementiert haben, können erwarten, dass ihre Systeme damit die Anforderungen von QEDm im Rahmen der oben genannten Optionen sowie PDQm vollständig erfüllen.
-
-Sollten sich Abweichungen ergeben, die im Sinne, dass Hersteller, die ISiK implementiert und erfolgreich bestätigt haben, *zusätzliche* Funktionen implementieren müssen, um QEDm- bzw. PDQm-konform zu sein, so werden diese hier aufgelistet:
-* PDQm fordert die Implementierung des Suchparameters `address-state`. Dieser ist nicht Bestandteil der ISiK-Spezifikation
-
-#### Sicherheit
-IHE fordert von Clinical Data Source- sowie Patient Demographic Supplier-Akteuren die Implementierung der Spezifikationen ATNA Secure Node oder ATNA Secure Application. Diese sind nicht Bestandteil des ISiK-Bestätigungsverfahrens.
-
diff --git a/ImplementationGuide/markdown/UebergreifendeFestlegungen/KompatibilitaetDerGematikSpezifikation.md b/ImplementationGuide/markdown/UebergreifendeFestlegungen/KompatibilitaetDerGematikSpezifikation.md
deleted file mode 100644
index 5ac2d6bd..00000000
--- a/ImplementationGuide/markdown/UebergreifendeFestlegungen/KompatibilitaetDerGematikSpezifikation.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Kompatibilität der gematik-Spezifikation
-
-{{index:current}}
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/UebergreifendeFestlegungen/KompatibilitaetDerGematikSpezifikation_Andere.md b/ImplementationGuide/markdown/UebergreifendeFestlegungen/KompatibilitaetDerGematikSpezifikation_Andere.md
deleted file mode 100644
index 51015f88..00000000
--- a/ImplementationGuide/markdown/UebergreifendeFestlegungen/KompatibilitaetDerGematikSpezifikation_Andere.md
+++ /dev/null
@@ -1,22 +0,0 @@
-## Kompatibilität zu anderen nationalen FHIR-basierten Spezifikationen
-
-Grundlage des ISiK-Leitfadens sind in Deutschland bereits abgestimmte und erprobte Profile, unter anderem:
-* die [Basisprofile von HL7 Deutschland e.V.](https://simplifier.net/basisprofil-de-r4)
-* die [Spezifikationen der KBV](https://simplifier.net/organization/kassenrztlichebundesvereinigungkbv/~projects), insbesondere
- * die [KBV-Basisprofile](https://simplifier.net/base1x0)
- * die [Formularübergreifenden Vorgaben für Digitale Muster](https://simplifier.net/for) (eRezept/eAU)
-* die [Kerndatensatz-Module der Medizininformatik-Initiative](https://simplifier.net/organization/koordinationsstellemii/~projects), insbesondere die Module
- * [Person](https://simplifier.net/medizininformatikinitiative-modulperson)
- * [Fall](https://simplifier.net/medizininformatikinitiative-modulfall)
- * [Diagnose](https://simplifier.net/medizininformatikinitiative-moduldiagnosen) und
- * [Prozedur](https://simplifier.net/medizininformatikinitiative-modulprozeduren)
-
-Dennoch erstellt die gematik für die Durchführung des Verfahrens eigene, technisch unabhängige Profile. Es wird angestrebt, dass Instanzen, die gegen gematik-Profile valide sind, ebenfalls gegen die zugrunde gelegten Profile valide sind. Sollte dies nicht der Fall sein, dann enthalten die Profile der gematik einen entsprechenden Hinweis mit einer Begründung, warum von dem Profil abgewichen wurde bzw. eine Information darüber, welche Schritte notwendig sind, um die Kompatibilität herzustellen. Dies kann beispielsweise die zusätzliche Implementierung weiterer Elemente sein, die nicht Bestandteil des ISiK-Bestätigungsverfahrens sind, für die Erfüllung des zugrundeliegenden Profils jedoch notwendig sind. Bei der Betrachtung der Kompatibilität wird stets von Implementierungen ausgegangen, die exakt die Minimalanforderungen (Pflichtfelder, Must-Support-Felder) der gematik-Spezifikation umsetzen. Weiterhin ist die Betrachtung auf harte Inkompatibilitäten begrenzt, d.h. widersprüchliche Kardinalitäten oder abweichende Kodierungen. Auf ggf. abweichende Must-Support-Felder mit optionaler Kardinalität, die zu keiner technischen Inkompatibilität führen, wird nicht explizit hingewiesen.
-
-Die Hinweise zur Kompatibilität sind jeweils im Unterkapitel "Kompatibilität" der einzelnen Datenobjekte zu finden.
-
-
-Das Erfordernis der Erstellung eigener, unabhängiger Profile für ISiK ergibt sich aus folgenden Gründen:
- 1. Technische Gründe: Im Rahmen von Connectathons können kurzfristige Bugfixes erforderlich werden, die von der gematik umsetzbar sein müssen, ohne auf einen Beschluss/ein Update seitens der MI-Initiative oder der KBV warten zu müssen.
- 2. Tooling: Das von der gematik verwendete Tooling für die Bestätigung kann es erforderlich machen, dass Profile mit zusätzlichen Attributen/Extensions versehen werden müssen, die seitens anderer Organisationen nicht benötigt werden.
- 3. Darstellung: Für die Teilnehmer am Bestätigungsverfahren soll auf einen Blick erkennbar sein, welche Elemente der Profile für die Bestätigung relevant sind. Um dies zu vereinfachen, setzt die gematik sog. "Must-Support"-Flags ein, um die relevanten Merkmale hervorzuheben. Die Bedeutung des Must-Support-Flags und der Umfang der entsprechend markierten Elemente kann in anderen Szenarien abweichen. Da es sich bei Must-Support-Flags jedoch um rein informative Attribute handelt, deren Einhaltung im Rahmen der Validierung nicht maschinell überprüft werden kann, hat dies keinen Einfluss auf die Kompatibilität. Slices und Extensions, die in den zugrundeliegenden Profilen optional und nicht Bestandteil des Bestätigungsverfahrens sind, können in den gematik-Profilen weggelassen werden, um die Lesbarkeit zu verbessern. Auch diese haben keine Auswirkungen auf die Kompatibilität.
diff --git a/ImplementationGuide/markdown/UebergreifendeFestlegungen/KompatibilitaetDerGematikSpezifikation_IHE.md b/ImplementationGuide/markdown/UebergreifendeFestlegungen/KompatibilitaetDerGematikSpezifikation_IHE.md
deleted file mode 100644
index fd8c5efc..00000000
--- a/ImplementationGuide/markdown/UebergreifendeFestlegungen/KompatibilitaetDerGematikSpezifikation_IHE.md
+++ /dev/null
@@ -1,73 +0,0 @@
-## Kompatibilität zu IHE-Profilen
-
-Die ISiK-Spezifikationen werden basierend auf folgenden IHE-Profilen entwickelt:
-* [PDQm (Patient Demographic Query for mobile)](https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_PDQm.pdf)
-* [QEDm (Query for Existing Data for mobile)](https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_Suppl_QEDm.pdf)
-
-Das [Modul Dokumentenaustausch](https://simplifier.net/guide/isik-dokumentenaustausch-v4/ImplementationGuide-markdown-UebergreifendeFestlegungen-Kompatibilitaet?version=current) basiert zudem auf:
-* [MHD (Mobile access to Health Documents)](https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_MHD.pdf)
-
-Hierbei ist anzumerken, dass der Zusatz "for mobile" seitens IHE irreführend sein kann.
-Konkret fasst IHE unter diesem Begriff nicht nur Systeme zusammen, die "Plattform- und Ressourcenbeschränkt sind, wie z.B. Tablets, Smartphones und Embedded Devices, sondern auch größere Systeme in Umgebungen, in denen die Interoperabilitätsanforderungen einfach sind (z.B. Anzeige der aktuellen Übersicht eines Patienten)" (Quelle: IHE QEDm - Introduction)
-
-Die im Folgenden genannten IHE-Spezifikationen beschreiben lediglich Interaktionen zwischen den Systemen und machen verbindliche Vorgaben zum Ablauf, Format und zu den unterstützten Such-Parametern, jedoch keine inhaltlichen Vorgaben. So beschreibt PDQm beispielsweise den Ablauf einer Suche nach Patientendaten, enthält aber keine Vereinbarungen, wie die zurückgelieferte Patientenressource konkret auszusehen hat (Pflichtfelder, Terminologien, Constraints).
-
-Der Mehrwert der ISiK-Spezifikation besteht darin, dass die genannten IHE-Interaktionen um Festlegungen zu den auszutauschenden Inhalten ergänzt werden, die zugeschnitten sind auf die Anforderungen des Datenaustausches zwischen Systemen innerhalb einer Einrichtung, basierend auf den Deutschen Basisprofilen von HL7 Deutschland e.V. Zudem wird ein beständiger Abgleich mit den Festlegungen der KBV zu den Inhalten der elektronischen Patientenakte (MIOs) sowie den Spezifikationen der Medizininformatik-Initiative angestrebt.
-
-
-Die Darstellungen der in diesen IHE-Profilen festgelegten Interaktionen und Use Cases sind den oben verlinkten Dokumenten zu entnehmen.
-
-### IHE PDQm
-
-#### Umfang
-PDQm unterstützt das Abfragen von demografischen Patientendaten.
-Damit fällt dieser Anwendungsfall vollständig in den Umfang der Festlegungen von ISiK.
-
-#### Akteure
-PDQm definiert die Kommunikation zwischen zwei Akteuren:
-1. dem *Patient Demographics Consumer* und
-2. dem *Patient Demographics Supplier*
-
-Im ISiK Kontext nehmen die bestätigungsrelevanten Systeme die Rolle des *Patient Demographics Supplier* ein.
-Die *Pediatric Demographics Option* liegt außerhalb des Abdeckungsbereiches von ISiK.
-
-#### Transaktionen
-PDQm definiert die Transaktion *ITI-78 (Mobile Patient Demographics Query)*, deren Grundlagen identisch sind mit den in ISiK definierten Interaktionen auf dem Datenobjekt "Patient".
-Der Unterschied zwischen PDQm und ISiK besteht lediglich darin, dass ISiK nicht alle in PDQm spezifizierten Suchparameter zwingend erfordert.
-Suchparameter, die in PDQm obligatorisch sind, in ISiK jedoch optional, sind in diesem Leitfaden mit einem entsprechenden Hinweis versehen.
-
-
-### IHE QEDm
-
-#### Umfang
-QEDm unterstützt das Abfragen klinischer Informationen wie zum Beispiel Diagnosen, Beobachtungen (u.a. Vitalparameter), Messdaten und Allergien unter Verwendung des FHIR-Standards.
-Damit überlappt der Anwendungsfall von QEDm in großen Teilen mit den Festlegungen von ISiK.
-
-#### Akteure
-QEDm definiert die Kommunikation zwischen zwei Akteuren:
-1. dem *Clinical Data Consumer* und
-2. der *Clinical Data Source*
-
-Im ISiK Kontext nehmen die bestätigungsrelevanten Systeme die Rolle der *Clinical Data Source* mit folgenden Optionen ein:
-
-* Conditions Option
-* Procedures Option
-* Encounters Option
-
-Alle weiteren Optionen liegen außerhalb des Abdeckungsbereiches von ISiK in Hinblick auf den Scope der aktuellen Veröffentlichung.
-
-Die Aufgabe der Clinical Data Source liegt in der Beantwortung der Anfragen nach Informationen durch die Rückgabe von FHIR-Ressourcen, die den gegebenen Suchparametern entsprechen.
-
-#### Transaktionen
-QEDm definiert die Transaktion *PCC-44 (Mobile Query for Existing Data)*, deren Grundlagen identisch sind mit den in ISiK definierten Interaktionen auf den Datenobjekten "Diagnose" "Prozedur" und "Kontakt/Fall".
-Der Unterschied zwischen QEDm und ISiK besteht lediglich darin, dass ISiK über die Vorgaben von PDQm hinaus die Implementierung weiterer Suchparameter fordert.
-
-So beschränkt sich QEDm zum Beispiel auf die Encounter-Suchparameter `patient` und `date`, während ISiK auch die Suche nach der Fallnummer (`identifier`) und weiteren, für die einrichtungsinterne Kommunikation relevanten Kriterien unterstützt.
-
-### Abweichungen
-Hersteller, die die ISiK-Vorgaben implementiert haben, können erwarten, dass ihre Systeme damit die Anforderungen von QEDm im Rahmen der oben genannten Optionen sowie PDQm vollständig erfüllen.
-
-Sollten sich Abweichungen ergeben in dem Sinne, dass Hersteller, die ISiK implementiert und erfolgreich bestätigt haben *zusätzliche* Funktionen implementieren müssen, um QEDm- bzw. PDQm-konform zu sein, so werden diese hier aufgelistet:
-
-* PDQm fordert die Implementierung des Suchparameters `address-state`. Dieser ist nicht Bestandteil der ISiK-Spezifikation
-* IHE fordert von Clinical Data Source- sowie Patient Demographic Supplier-Akteuren die Implementierung der Spezifikationen ATNA Secure Node oder ATNA Secure Application. Diese sind nicht Bestandteil des ISiK-Bestätigungsverfahrens.
diff --git a/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen.md b/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen.md
deleted file mode 100644
index 7ad6a445..00000000
--- a/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen.md
+++ /dev/null
@@ -1,5 +0,0 @@
-# Übergreifende Festlegungen
-
-In diesem Kapitel werden die folgenden übergreifenden Festlegungen definiert, die generell für die weitere Spezifikation gelten:
-
-{{index:current}}
diff --git a/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_BestaetigungsrelevanteSysteme.md b/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_BestaetigungsrelevanteSysteme.md
deleted file mode 100644
index 4ab3b844..00000000
--- a/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_BestaetigungsrelevanteSysteme.md
+++ /dev/null
@@ -1,245 +0,0 @@
-# Bestätigungsrelevante Systeme
-
-Gemäß §373 (2) SGB V legt das Kompetenzzentrum für Interoperabilität im Gesundheitswesen (KIG) gegenwärtig die Definition der bestätigungsrelevanten Systeme fest.
-
-# **Definition Bestätigungsrelevante Systeme**
-# **Allgemein**
-Für den Austausch von versorgungsrelevanten Daten in Krankenhäusern erarbeitet die gematik einen verbindlichen Standard über eine standardisierte Schnittstelle für informationstechnische Systeme in Krankenhäusern (ISiK). Damit kommt sie ihrem gesetzlichen Auftrag nach § 373 SGB V nach.
-Die standardisierte Schnittstellen-Festlegung ISiK wird in Modulen veröffentlicht. An dieser Stelle werden die Festlegungen für die bestätigungsrelevanten IT-Systeme anhand definierter Akteure getroffen.
-
-Bei bestätigungsrelevanten IT-Systemen in ISiK handelt es sich stets um Software-Systeme, die versorgungsrelevante Daten verarbeiten oder dauerhaft speichern. Ausgenommen sind Software-Produkte, die ausschließlich zur redundanten Datenspeicherung und -wiederherstellung eingesetzt werden. Wenn im Folgenden die Rede ist von einem *primären, dauerhaften Ort zur Speicherung und Verwaltung von Daten*, so ist damit im Sinne einer Single Source of Truth (führendes System) ein allgemeingültiger Datenbestand gemeint.
-
-Versorgungsrelevante Daten sind administrative Daten (z.B. Alter des Patienten, Name der Einrichtung, Arztnummer usw.) sowie Daten zu klinischen Verfahren (z.B. Prozeduren-Codes), Diagnostik (z.B. Laborbefunde), Medikation (z.B. Medikamenten-Verordnung) und Abrechnung (z.B. Versicherungsverhältnis).
-
-Es wird eine Kategorisierung der bestätigungsrelevanten Subsysteme entlang von definierten Akteuren und des groben Funktionsumfangs von Produkten im Markt angestrebt. In diesem Sinne sind die unten gelisteten **Definitionen** als Funktionsklärungen zu verstehen. Ein Akteur ist zu verstehen als ein System, das in einer bestimmten Rolle fungiert. Der **Geltungsbereich** konkretisiert wiederum die Definition in Bezug auf Produktkategorien. Der **normative Status** wird schließlich tabellarisch unter den entsprechenden Abschnitten zur **Bestätigungsrelevanz** aufgeführt.
-
-Eine weitere Detaillierung zu den einzelnen Festlegungen und Anforderungen, die im Rahmen des Bestätigungsverfahrens geprüft werden, erfolgt ggf. in entsprechenden Abschnitten des Implementierungsleitfadens der einzelnen Module. Eine technische Aufbereitung der Anforderungen in der REST-API erfolgt in der (FHIR-Ressource) CapabilityStatement.
-
-An dieser Stelle werden Festlegungen getroffen, die folgende ISiK-Module betreffen:
-
-- Basismodul
-- Dokumentenaustausch
-- Vitalparameter und Körpermaße
-- Terminplanung
-- Medikation
-
-Das Support-Modul Labor stellt Profile bereit, die im Kontext anderer Module bestätigungsrelevant sein können, ist als Modul selbst jedoch nicht bestätigungsrelevant.
-
-+++++++++++++++++++++++++++++
-# **Basismodul**
-## **Akteur: Basis-Server**
-### **Definition**
-Der Akteur "Basis-Server" im Sinne des ISiK-Moduls "Basis" ist ein System, das versorgungsrelevante Daten für andere Applikationen (Akteur: Basis-Client) über eine FHIR R4 REST API nach ISiK zur Abfrage und Weiternutzung bereitstellt.
-
-Nicht-normative Erläuterung in Bezug auf IHE Festlegungen (genaueres in den ISIK Implementation Guides): Der Basis-Server nimmt im IHE-PDQm-Kontext die Rolle des Akteurs *Patient Demographics Supplier* und im IHE-QEDm-Kontext die Rolle des Akteurs *Clinical Data Source* ein*.*
-### **Geltungsbereich**
-Als Basis-Server gelten in diesem Kontext Systeme, die strukturierte, versorgungsrelevante Daten über Schnittstellen entgegennehmen oder selbst erstellen und als primärer, dauerhafter Ort zur Speicherung und Verwaltung dieser Daten während der Patientenversorgung im Krankenhaus dienen.
-
-Dies betrifft u.a.:
-
-- KIS-Systeme
-- Clinical Data Repository
-- Abrechnungssysteme, sofern diese als führende Systeme für die Speicherung und Verwaltung versorgungsrelevanter Daten genutzt werden
-## **Akteur: Basis-Client**
-### **Definition**
-Der Akteur "Basis-Client" im Sinne des ISiK-Moduls "Basis" ist ein System, das versorgungsrelevante Daten von einem Basis-Server abfragt. Der vorrangige Zweck des Abrufs dieser versorgungsrelevanten Daten ist sie einem Anwender anzuzeigen, um eine redundante Erfassung zu vermeiden oder sie in internen Prozesse zu verarbeiten. Auch das Aufrufen von strukturierten Workflows zur Erstellung, Manipulation (Ändern, Anreichern etc.) und Synchronisation der zuvor genannten Daten kennzeichnet "Basis-Clients".
-
-Dabei können sie die für die Server verpflichtend festgelegten Suchkriterien beliebig kombinieren. Basis-Clients sind nicht verpflichtet, alle von den Servern geforderten Suchkriterien zu unterstützen. Weiterhin können Basis-Clients neu erstellte patientenbezogene Daten in Form eines strukturierten FHIR-Dokumentes an Basis-Server übermitteln, sofern diese die entsprechende Interaktion unterstützen. Dabei müssen sie jedoch mindestens die in diesem Modul verpflichtend festgelegten Metadaten zu den Dokumenten sowie eine HTML-Repräsentation (Narrative) bereitstellen.
-
-Nicht-normative Erläuterung in Bezug auf IHE Festlegungen (genaueres in den ISIK Implementation Guides): Der Basis-Client nimmt im IHE-PDQm-Kontext die Rolle des Akteurs *Patient Demographics Consumer* und im IHE-QEDm-Kontext die Rolle des Akteurs *Clinical Data Consumer* ein*.*
-### **Geltungsbereich**
-Als Basis-Clients gelten in diesem Kontext alle Systeme, die strukturierte versorgungsrelevante Daten von anderen Systemen abfragen. Basis-Clients gelten *nicht* als primärer, dauerhafter Speicherort für die abgefragten Daten.
-
-Dies betrifft u.a. :
-
-- Systeme, die Patientenstammdaten nicht über eine HL7 V2-Datenstrom empfangen, sondern diese bei Bedarf im patientenführenden System abfragen möchten
-- Systeme, die versorgungsrelevante Daten in anderen Systemen abfragen möchten, um redundante Datenerfassung zu verhindern
-- Systeme, die Daten aus anderen Systemen abfragen möchten, um sie Anwendern oder Prozessen bedarfsgerecht zur Verfügung zu stellen zu können, ohne diese redundant speichern zu müssen
-
-## **Bestätigungsrelevanz**
-Tabellarisch gelistet wird hier die Bestätigungsrelevanz in Bezug auf die zuvor definierten Akteure:
-
-|**Akteur**|**konkrete Anforderungen**|**bestätigungsrelevant**|
-| :-: | :-: | :-: |
-|Basis-Server||ja|
-|Basis-Client|keine|nein|
-# **Dokumentenaustausch**
-## **Akteur: Dokumenten-Server**
-### **Definition**
-Der Akteur "Dokumenten-Server" im Sinne des ISiK-Moduls "Dokumentenaustausch" ist ein System, das (potentiell) versorgungsrelevante Dokumente über eine FHIR R4 API nach ISIK von anderen Applikationen (Akteur: Dokumenten-Client) entgegennimmt, speichert und Dokumenten-Clients zur Abfrage und Weiternutzung zur Verfügung stellt.
-
-Nicht-normative Erläuterung in Bezug auf IHE Festlegungen (genaueres in den ISIK Implementation Guides): Der Dokumenten-Server nimmt im Kontext der [Spezifikation IHE ITI Mobile access to Health Documents (MHD)](https://profiles.ihe.net/ITI/MHD/index.html) die Rollen der Akteure [Document Recipient](https://profiles.ihe.net/ITI/MHD/1331_actors_and_transactions.html#133113-document-recipient) und [Document Responder](https://profiles.ihe.net/ITI/MHD/1331_actors_and_transactions.html#133114-document-responder) ein und implementiert die IHE-MHD-Interaktionen gemäß Version 4.2.0
-
-- Simplified Publish [ITI-105] (verpflichtend)
-- Generate Metadata [ITI-106] (optional)
-- Find Document References [ITI-67] (verpflichtend)
-- Retrieve Document [ITI-68] (verpflichtend)
-### **Geltungsbereich**
-Als Dokumenten-Server gelten in diesem Kontext alle Systeme, die strukturierte und/ oder unstrukturierte versorgungsrelevante Dokumente über Schnittstellen entgegennehmen oder selbst erstellen und als primärer, dauerhafter Ort zur Speicherung und Verwaltung dieser Dokumente dienen.
-
-Dies betrifft u.a.:
-
-- KIS-Systeme mit integrierter Dokumentenverwaltung
-- Archivsysteme, sofern diese nicht ausschließlich zur Umsetzung einer Backup-Lösung genutzt werden
-- Dokumentenverwaltungssysteme (DMS), sofern diese zur Speicherung von versorgungsrelevante Dokumenten (s.o. zu versorgungsrelevante Daten) verwendet werden
-## **Akteur: Dokumenten-Client**
-### **Definition**
-Der Akteur "Dokumenten-Client" im Sinne des ISiK-Moduls "Dokumentenaustausch" ist ein System, das Dokumente von einem Dokumenten-Server abfragt, um sie z.B. einem Anwender anzuzeigen. Dabei können sie die für die Server verpflichtend festgelegten Suchkriterien beliebig kombinieren. Dokumenten-Clients sind nicht verpflichtet, alle von den Servern geforderten Suchkriterien zu unterstützen. Weiterhin können Dokumenten-Clients neu erstellte, geänderte oder erweiterte Dokumente an einen Dokumenten-Server übermitteln. Dabei müssen sie jedoch mindestens die in diesem Modul verpflichtend festgelegten Metadaten zu den Dokumenten bereitstellen. Sowohl die Implementierung der Interaktion "Dokumentenabfrage" als auch "Dokumentenbereitstellung" sind für Dokumenten-Clients optional.
-
-Nicht-normative Erläuterung in Bezug auf IHE Festlegungen (genaueres in den ISIK Implementation Guides): Der Dokumenten-Client nimmt agiert IHE-MHD-Kontext als Akteur [Document Source](https://profiles.ihe.net/ITI/MHD/1331_actors_and_transactions.html#133111-document-source) und [Document Consumer](https://profiles.ihe.net/ITI/MHD/1331_actors_and_transactions.html#133112-document-consumer) ein und implementiert die IHE-MHD-Interaktionen
-
-- Simplified Publish [ITI-105] (optional)
-- Generate Metadata [ITI-106] (optional)
-- Find Document References [ITI-67] (optional)
-- Retrieve Document [ITI-68] (optional)
-### **Geltungsbereich**
-Als Dokumenten-Clients gelten in diesem Kontext alle Systeme, die strukturierte und/oder unstrukturierte versorgungsrelevante Dokumente erstellen und über Schnittstellen kommunizieren oder solche Dokumente von Dokumenten-Servern abfragen. Dokumenten-Clients gelten *nicht* als primärer, dauerhafter Speicherort für die erstellten oder abgefragten Dokumente.
-
-Dies betrifft u.a.:
-
-- Anwendersysteme, die medizinischem Personal den bedarfsgerechten Zugang zu versorgungsrelevanten, andernorts gespeicherten Dokumenten ermöglichen
-- Telekonsil-System gemäß § 31a BMV-Ä die Dokumente von Dokumenten-Servern abfragen und zur Verwendung in Telekonsilien bereitstellen
-- KIM-Client-Anwendungssoftware, die Dokumente aus Anhängen an KIM-Nachrichten zur Speicherung an Dokumenten-Server übermitteln und/oder Dokumente von Dokumenten-Servern abfragen, um sie im Anhang an KIM-Nachrichten zu versenden
-## **Bestätigungsrelevanz**
-Tabellarisch gelistet wird hier die Bestätigungsrelevanz in Bezug auf die zuvor definierten Akteure:
-
-|**Akteur**|**konkrete Anforderungen**|**bestätigungsrelevant**|
-| :-: | :-: | :-: |
-|Dokumenten-Server||ja|
-|Dokumenten-Client|keine|nein|
-# **Vitalparameter und Körpermaße**
-## **Akteur: Vitalparameter-Server**
-### **Definition**
-Der Akteur "Vitalparameter-Server" im Sinne des ISiK-Moduls "Vitalparametern und Körpermaße" ist ein System, das versorgungsrelevante Daten für andere Applikationen (Akteur: Vitalparameter-Client) über eine FHIR R4 REST API nach ISiK zur Abfrage und Weiternutzung zur Verfügung stellt und persistiert.
-
-Nicht-normative Erläuterung in Bezug auf IHE Festlegungen (genaueres in den ISIK Implementation Guides): Analog zum ISiK Basismodul ist ein Vitalparameter-Server im Modul Vitalparameter weitgehend analog zu IHE QEDm '*Clinical Data Source'* zu betrachten.
-### **Geltungsbereich**
-Als Vitalparameter-Server gelten in diesem Kontext alle Systeme, die strukturierte versorgungsrelevante Daten über eine Schnittstellen bereitstellen, verarbeiten und als primärer, dauerhafter Speicherort dieser Daten dienen.
-
-Systeme, die als Vitalparameter-Server agieren sind u.a.:
-
-- KIS mit Funktion elektronische Kurve bzw. entsprechendes KIS-Modul
-- Patientendaten-Managementsystem (PDMS) [z.B. für Intensivbereiche]
-- Clinical Data Repository
-- Elektronische Kurve [z.B. für die Verwendung auf Normal-Stationen]
-## **Akteur: Vitalparameter-Client**
-### **Definition**
-Im Kontext des Moduls Vitalparameter und Körpermaße fragen Vitalparameter-Clients versorgungsrelevante Daten von einem Vitalparameter-Server ab (entspricht weitgehend einem IHE QEDm Akteur *Clinical Data Consumer)*, um sie z.B. einem Anwender anzuzeigen oder mittels dedizierter Software zu verarbeiten, z.B. zur Entscheidungsunterstützung. Vitalparameter-Clients sind nicht verpflichtet, alle von den Vitalparameter-Servern geforderten Suchkriterien zu unterstützen.
-### **Geltungsbereich**
-Als Vitalparameter-Clients gelten in diesem Kontext alle Systeme, die strukturierte versorgungsrelevante Daten über eine Schnittstelle abfragen oder kommunizieren. Vitalparameter-Clients gelten *nicht* als primärer, dauerhafter Speicherort für die versorgungsrelevante Daten.
-
-Vitalparameter-Clients sind zum Beispiel:
-
-- Elektronische Kurve [z.B. für die Verwendung auf Normal-Stationen]
-
-Dabei ist zu beachten, dass auch Systeme, die oben als Akteur 'Vitalparameter-Server' gelistet sind, zusätzlich als Akteur 'Vitalparameter-Client' agieren können. Insbesondere für die Unterstützung zwischen Überleitungs-Workflows gilt dies für:
-
-- KIS
-- PDMS
-## **Bestätigungsrelevanz**
-Bestätigungsrelevant im Kontext des Moduls Vitalparameter sind alle Software-Produkte, die eine Teilmenge der in diesem Modul in Form von FHIR-Profilen definierten Daten zu klinischen Vitalparametern und Körpermaßen verarbeiten und dauerhaft speichern (die Bestätigung wird dann ggf. nur für eine Teilmenge der Datenschemata erfolgen): auch wenn z.B. nur ein Profil für die Schnittstelle umgesetzt werden MUSS (z.B. im hypothetischen Falle, dass ein System nur dieses unterstützt ), ist der "Vitalparameter-Server" bestätigungsrelevant (für dieses eine Profil).
-
-Tabellarisch gelistet wird hier die Bestätigungsrelevanz in Bezug auf die zuvor definierten Akteure:
-
-|**Akteur**|**konkrete Anforderungen**|**bestätigungsrelevant**|
-| :-: | :-: | :-: |
-|Vitalparameter-Server||ja|
-|Vitalparameter-Client|keine|nein|
-# **Terminplanung**
-## **Akteur: Termin-Repository**
-### **Definition**
-Der Akteur "Termin-Repository" im Sinne des ISiK-Moduls "Terminplanung" ist ein System, das Informationen zu verfügbaren Termineinheiten von Ressourcen (z.B. Ambulanzen, Leistungsstellen, Mitarbeiter, Geräte und Räume) vorhalten und die dafür vereinbarten Termine über eine FHIR R4 REST API nach ISiK zur Abfrage und Weiternutzung zur Verfügung stellt und verwaltet. Das Termin-Repository gilt stets als autoritative Quelle zur Verwaltung von Termindaten und ist damit als ein patientenführendes System zu verstehen.
-### **Geltungsbereich**
-Systeme, die als Termin-Repository agieren sind u.a.:
-
-- Patietenportal im Falle, dass das System selbst terminführend ist
-- terminführenden Systeme, z.B. KIS oder auch Klinische Arbeitsplatz-Systeme (KAS) inkl. Terminverwaltung
-- PDMS, die Termine verwalten
-## **Akteur: Termin-Requestor (Termin-Source)**
-### **Definition**
-Als Termin-Requestor (in Anlehnung an die IHE Terminologie auch als Termin-Source zu bezeichnen) werden alle Client-Systeme definiert, die mittels Schnittstellenanfrage zur Erhebung und Veränderung von Termininformationen dienen. Der Termin-Requestor übernimmt die Koordination der Schnittstellenaufrufe per FHIR R4 REST API nach ISiK, um einen Termin zu buchen. Das Termin-Requestor allein gilt *nicht* als autoritative Quelle zur Verwaltung von Termindaten., d.h. sofern der Termin-Requestor Termindaten von einem Termin-Repository synchronisiert und speichert/cached, sollten diese Termindaten nicht als solche verbindlich für einen mögliche Weiterverbreitung gelten, es muss vielmehr sichergestellt werden, dass die Daten mit denen des Quellsystems (Termin-Repository) übereinstimmen.
-### **Geltungsbereich**
-Systeme, die als Termin-Requestor agieren sind u.a.:
-
-- Mobile Apps zur Verwaltung von Terminen
-- Patientenportal bei der Synchronisierung mit einem weiteren Termin-Repository
-- KIS / KAS bei der Synchronisierung mit einem weiteren Termin-Repository
-## **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 in der Regel ü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 Termin-Repositories und Termin-Requestors.
-### **Geltungsbereich**
-Systeme, die als Termin-Consumer agieren sind u.a.:
-
-- Apps zum Anzeigen eines Kalenders
-- Systeme zum Versenden von Benachrichtigungen im Kontext eines Termins
-- Ressourcen-Managementsoftware
-## **Bestätigungsrelevanz**
-Tabellarisch gelistet wird hier die Bestätigungsrelevanz in Bezug auf die zuvor definierten Aktuere:
-
-|**Akteur**|**konkrete Anforderungen**|**bestätigungsrelevant**|
-| :-: | :-: | :-: |
-|Termin-Repository|[https://simplifier.net/isik-terminplanung-v4/~guides](https://simplifier.net/isik-terminplanung-v3/~guides)|ja|
-|Termin-Requestor|keine|nein|
-|Termin-Consumer|keine|nein|
-# **Medikation**
-Das Modul "Medikation" unterscheidet die im Folgenden definierten Akteure.
-## **Akteur: Medikations-Server**
-### **Definition**
-Der Akteur "Medikations-Server" im Sinne des ISiK-Moduls "Medikation" ist ein System, das Informationen über Verordnung, Abgabe und Verabreichung von Medikamenten für andere Applikationen (Akteur: Medikations-Client) über eine FHIR R4 REST API nach ISiK zur Abfrage und Weiternutzung zur Verfügung stellt und persistiert.
-### **Geltungsbereich**
-Als Medikations-Server gelten in diesem Kontext alle Systeme, die strukturierte versorgungsrelevante Medikationsdaten über eine Schnittstellen bereitstellen, verarbeiten und als primärer, dauerhafter Speicherort dieser Daten dienen. Medikationsdaten bilden Informationen zur Medikation ab, diese ist "die Verordnung und Anwendung von Medikamenten unter Festlegung einer bestimmten Dosierung. [[...](https://wiki.gematik.de/pages/createpage.action?spaceKey=IOPAK&title=...)] Sie ist die konkrete Ausführung der Pharmakotherapie." ()
-
-Systeme, die als Medikations-Server agieren können, sind u.a.:
-
-- KIS mit Funktion Medikationsdatenverwaltung bzw. entsprechendes KIS-Modul
-- Patientendaten-Managementsystem (PDMS) [z.B. für Intensivbereiche] (Anwendungsfallbeispiel: Medikationsdaten in das KIS übertragen bei Verlegung vom Intensivbereich auf Normal-Station)
-- Software für digitales Medikationsmanagement (z.B. für die Umsetzung von KHZG Fördertatbestand 5)
-- E-Therapieplan-System für Zytostatika-Behandlung mit Verarbeitung von Verordnungs- und Medikationsinformationen
- (gemäß Festlegungen keine Umsetzung des ISIK-Datenobjekts MedikationsVerabreichung notwendig)
-- Herstellungssystem mit Verarbeitung von Verordnungs- und Medikationsinformationen
- (gemäß Festlegungen keine Umsetzung des ISIK-Datenobjekts MedikationsVerabreichung notwendig)
-## **Akteur: AMTS Data Provider**
-### **Definition**
-Der Akteur AMTS Data Provider im Sinne des ISiK-Moduls "Medikation" ist ein System, das AMTS relevante Informationen für andere Applikationen (Akteur: Medikations-Client) über eine FHIR R4 REST API nach ISiK zur Abfrage und Weiternutzung zur Verfügung stellt und persistiert. Beispiele für ATMS-relevante Informationen sind z.B. der Stillstatus, Schwangerschafts- und Raucherstatus.
-
-Es geht hier nicht um ein System das AMTS-Resultate bereitstellt - daher wurde die Bezeichnung AMTS Data Provider gegenüber AMTS-Server hier bevorzugt.
-### **Geltungsbereich**
-Als AMTS data provider gelten in diesem Kontext alle Systeme, die AMTS relevante, strukturierte klinische Daten über eine Schnittstellen bereitstellen, verarbeiten und als primärer, dauerhafter Speicherort dieser Daten dienen.
-
-Systeme, die als AMTS data provider agieren können sind u.a.:
-
-- KIS
-- Laborinformationssysteme (LIS)
-- PDMS (Anwendungsfallbeispiel: Abrufen von AMTS relevanten Zusatzinformationen)
-## **Akteur: Medikations-Client**
-### **Definition**
-Im Kontext des Moduls Medikation fragen Medikations-Clients versorgungsrelevante Daten von einem Server ab, um sie z.B. einem Anwender (End-User als Mensch) anzuzeigen oder mittels dedizierter Software zu verarbeiten, z.B. zur Entscheidungsunterstützung. Medikations-Clients sind nicht verpflichtet, alle von den Servern bereitgestellten Suchkriterien zu unterstützen.
-### **Geltungsbereich**
-Als Medikations-Clients gelten in diesem Kontext alle Systeme, die strukturierte versorgungsrelevante Daten zur Medikation über eine Schnittstelle abfragen oder kommunizieren. Medikations-Clients gelten *nicht* als primärer, dauerhafter Speicherort für die versorgungsrelevante Daten.
-
-Medikations-Clients sind zum Beispiel:
-
-- AMTS Systeme
-
-Dabei ist zu beachten, dass auch Systeme, die oben als Medikations-Server gelistet sind, zusätzlich als Akteur 'Medikations-Client' agieren können. Insbesondere für die Unterstützung eines Überleitungs-Workflows gilt dies für:
-
-- KIS
-- PDMS
-## **Bestätigungsrelevanz**
-
-Bestätigungsrelevant im Kontext des Moduls Medikation sind alle Systeme, die eine Teilmenge der in diesem Modul in Form von FHIR-Profilen definierten Daten zu Medikationsinformationen verarbeiten und dauerhaft speichern (die Bestätigung wird dann ggf. nur für eine Teilmenge der Datenschemata erfolgen): auch wenn z.B. nur ein Profil für die Schnittstelle umgesetzt werden MUSS (z.B. im hypothetischen Falle, dass ein System nur dieses unterstützt ), ist das System bestätigungsrelevant (für dieses eine Profil).
-
-Bestandteile des Support Moduls Labor sind im Kontext des Medikationsmoduls bestätigungsrelevant, insbesondere für die Anwendungsfälle rund um AMTS.
-
-Tabellarisch gelistet wird hier die Bestätigungsrelevanz in Bezug auf die zuvor definierten Akteure:
-
-|**Akteur**|**konkrete Anforderungen**|**bestätigungsrelevant**|
-| :-: | :-: | :-: |
-|Medikations-Server||ja|
-|AMTS Data Provider| |ja|
-|Medikations-Client|keine|nein|
-
-
-# Festlegungen auf Profilebene im CapabilityStatement
-
-Festlegungen zu Anforderungen auf Profilebene werden unter {{pagelink:ImplementationGuide/markdown/CapabilityStatement.md}} geführt.
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Methodik.md b/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Methodik.md
deleted file mode 100644
index 65890fdf..00000000
--- a/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Methodik.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Methodik
-
-Anforderungen als Ausdruck normativer Festlegungen werden durch die dem [RFC2119](https://tools.ietf.org/html/rfc2119) entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN sowie ihrer Pluralformen gekennzeichnet.
diff --git a/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Must-Support-Flags.md b/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Must-Support-Flags.md
deleted file mode 100644
index 6f61aa91..00000000
--- a/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Must-Support-Flags.md
+++ /dev/null
@@ -1,33 +0,0 @@
-## Must-Support-Flags
-
-Das [Must-Support-Flags](https://hl7.org/fhir/R4/profiling.html#mustsupport) (MS-Flag) kennzeichnet Elemente, die auf bestimmte Weise unterstützt werden müssen. Sowohl für die Erstellung - d.h. das Exponieren der Ressource -, als auch für die Verarbeitung - d.h. den Umgang beim Eingang von extern - greifen die MS-Flag Festlegungen.
-Die Verwendung des MS-Flag an Profil-Elementen hat im Kontext dieses Leitfadens folgende Bedeutung:
-
-1. Im Kontext der Erstellung von FHIR-Ressourcen:
-
- Elemente, die mit MS gekennzeichnet sind, MÜSSEN vom erstellenden System implementiert werden. Dies bedeutet:
- - Systeme MÜSSEN die entsprechenden Elemente in der eigenen Persistenz-Ebene vorhalten können.
- - Systeme MÜSSEN die entsprechenden Elemente in den entsprechenden Profil-Instanzen bei Abfrage über eine FHIR-Schnittstelle befüllen und ausgeben können.
- - Systeme MÜSSEN die entsprechenden Elemente zur Anzeige bringen können (ausgenommen davon sind Systeme mit reiner Middleware-Funktion, die über keine grafische Nutzeroberfläche verfügen).
- - MS-Elemente, die als optional gekennzeichnet sind (0..-Kardinalität) KÖNNEN bei der Erstellung einer FHIR-Instanz fehlen, wenn die entsprechende Information im Einzelfall unbekannt, nicht zutreffend ist oder (noch) nicht erhoben wurde.
-
- Eine **Ausnahme** stellen implizit vorhandene Informationen dar, die nicht aus der Persistenz-Ebene sondern nur aus dem Kontext des erstellenden Systems entnommen werden können. Beispiel: In einem System werden stets nur Informationen aktiver Patienten vorgehalten (inaktive Patienten werden verschoben/archiviert/gelöscht). Der Status eines Patienten wird daher nicht explizit angezeigt und in der Persistenz-Ebene gespeichert, sondern ergibt sich allein aus der Existenz des Datensatzes in diesem System. In solchen Fällen gilt:
- - Bei lediglich implizit vorhandenen Informationen KANN der Inhalt eines MS-Elementes in der Schnittstelle hartkodiert werden (sofern gesichert ist, dass der entsprechende Wert des Elementes ausnahmslos auf alle Instanzen zutrifft, die dieses System erstellt).
-
- Insbesondere für solche implizit vorhandene Informationen, können in den Profilen auf der Ebene einzelner, mit MS-Flag versehener Elemente konkretere Hinweise zur Implementierung enthalten sein, die die übergreifende Definition zu Must-Support für den Einzelfall konkretisieren, zum Beispiel zur Klarstellung wo und unter welchen Umständen hartkodierte Werte erlaubt sind.
-Ob für ein MS-Flag konkrete Ausnahmen gelten, in denen ein impliziter Wert hartcodiert gesetzt werden darf oder das MS-Flag nur unter bestimmten Bedingungen gilt, ist der Definition des jeweiligen Elementes zu entnehmen.
-
- Hinweis: Bei den Testszenarien von READ-Interaktionen im Rahmen des Bestätigungsverfahrens werden für MS-Elemente Informationen vorgegeben, die in den Systemen erfasst und über die FHIR-Schnittstelle reproduziert werden MÜSSEN, unabhängig von der angegebenen Kardinalität.
-
-2. Im Kontext der Verarbeitung von FHIR-Ressourcen:
-
- Elemente, die mit MS gekennzeichnet sind, MÜSSEN vom empfangenden System verarbeitet werden. Dies bedeutet:
- - Das System MUSS in der Lage sein, diese Elemente in der eigenen Persistenz-Ebene zu speichern
- - Das System MUSS bei einer erneuten Abfrage der Information über die FHIR-Schnittstelle in der Lage sein diese Information zu reproduzieren.
- - Systeme MÜSSEN die entsprechenden Elemente zur Anzeige bringen können (ausgenommen davon sind Systeme mit reiner Middleware-Funktion, die über keine grafische Nutzeroberfläche verfügen).
- - Systeme KÖNNEN es darüber hinaus ermöglichen, dass die jeweiligen Informationen vom Anwender ergänzt oder editiert werden.
- - MS-Elemente, die als optional gekennzeichnet sind (0..-Kardinalität) KÖNNEN bei der Übermittlung einer Instanz fehlen, wenn die entsprechende Information im sendenden System unbekannt, nicht zutreffend ist oder (noch) nicht erhoben wurde. Das Fehlen optionaler MS-Elemente DARF bei der Verarbeitung NICHT zu einem Fehler führen.
-
- Hinweis: Bei den Testszenarien von WRITE/UPDATE-Interaktionen im Rahmen des Bestätigungsverfahrens werden Instanzen an das zu testende System übermittelt, in denen alle MS-Elemente, unabhängig von Ihrer Kardinalität, gegeben sind. Diese MÜSSEN von den getesteten Systemen in einer anschließenden READ-Interaktion vollständig über die FHIR-Schnittstelle reproduziert werden können.
-
-Wenn ein Hersteller neben den in ISiK geforderten Elementen die Verarbeitung *weiterer* Elemente unterstützt, so sollte dies durch abgeleitete Profile, in denen die zusätzlichen Elemente ebenfalls als MS gekennzeichnet sind, dokumentiert und im Rahmen der Schnittstellendokumentation publiziert werden.
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Patient-merge.md b/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Patient-merge.md
deleted file mode 100644
index 3ed0a72c..00000000
--- a/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Patient-merge.md
+++ /dev/null
@@ -1,109 +0,0 @@
-# Patient merge und Notification
-
-## Motivation
-Im Rahmen von Krankenhausbesuchen umfassen u.a. die Aufnahme-Workflows regelmäßig die manuelle Bearbeitung von Patientenstammdaten. Daher ist hier das Risiko redundant persistierter Patientendaten stets vorhanden. Dies hat auch zur Folge, dass Zusammenführungen von Patientendaten in Krankenhäusern an der Tagesordnung stehen.
-
-Die Patientendatenzusammenführung (Patient merge) bezeichnet den Workflow der Bereinigung redundanter Patienten-Instanzen innerhalb eines KIS oder einer KH-IT-Umgebung. Die Bereinigung geschieht erfahrungsgemäß als halb-automatisierter Prozess, für den dedizierte Komponenten eingesetzt werden können (d.h. Master-Patient-Index).
-
-Im Kontext verteilter Systeme ist es entscheidend, dass ein patientenführendes System/Server (KIS) einen Client über einen Patient merge benachrichtigt (Patient merge Notification), damit der Client weiterhin auf eine korrekte Patienteninstanz zugreifen kann. Daher trifft dieser Abschnitt eine Festlegung zur Umsetzung einer Patient merge Notification auf Basis von FHIR.
-
-## Normativer Status
-Alle hier getroffenen Festlegungen haben den normativen Status einer KANN-Anforderung. Werden allerdings die hier festgelegten Lösungen genutzt, so SOLLEN die hier angeführten Vorgaben (inklusive Profil-Ebene) eingehalten werden.
-
-Eine Prüfung im Rahmen des Bestätigungsverfahrens zur Patient merge Notification ist in der jetzigen Entwicklungsstufe nicht vorgesehen.
-
-## Zweck und Definition 'Patient merge Notification'
-Zweck dieses Abschnitts ist eine Festlegung darüber zu treffen, wie externe Clients Patient-merge-Vorgänge nachvollziehen und entsprechend verarbeiten können.
-Entsprechend wird hier eine Festlegung zur Kommunikation eines stattgefundenen Patient merges (Patient merge Notification) gegenüber einem Subsystem oder einem externen Service - u.a. mittels FHIR Subscriptions - festgelegt.
-
-**Definition**: Der Workflow 'Patient merge Notification' entspricht der Benachrichtigung angeschlossener Systeme über den erfolgreichen Patient merge. Die Benachrichtigung unterstützt das Kernziel einer reibungslosen Kommunikation zwischen zwei Systemen, nachdem ein Patient merge stattgefunden hat. Durch die Benachrichtigung wird ein fehlerhafter Abruf oder falsche Referenzierung einer alten Patientenressource von Seiten des Clients verhindert oder zumindest vorgebeugt und damit eine Verbesserung der Qualität hinsichtlich Robustheit und damit auch eine Stärkung der Praxistauglichkeit von ISiK als Schnittstellen-Lösung erreicht.
-
-## Festlegungen zu 'Patient merge Notification'
-Falls eine Patient merge Notification im Rahmen von ISIK bereitgestellt wird, gelten folgende Festlegungen:
-
-Das patientenführende System SOLL einen Client mittels FHIR Subscription über einen erfolgten Patienten merge informieren können. Dieser Mechanismus basiert auf dem [Subscriptions R5 Backport IG](https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/channels.html) und nutzt das Konzept der "Topic-Based Subscription" aus FHIR R5.
-
-Hierfür wurde das Subscription Topic: *https://gematik.de/fhir/isik/SubscriptionTopic/patient-merge* definiert.
-
-Das patientenführende System SOLL den Support dieser Subscription innerhalb des CapabilityStatements bekannt geben.
-
-Weitere Informationen zum Subscription Workflow finden sich hier:
-
-[Subscription Workflow - Subscriptions R5 Backport](https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/workflow.html)
-
-### Prove of Concept Implementierung
-Zur Illustration der technischen Umsetzung für die Patient merge Notification dient ein [Prove of Concept (POC) mit Anleitung](https://github.com/gematik/poc-isik-patient-merge).
-
-### Notification Channel Types
-Notifications über einen Patient-merge-Vorgang können per *rest-hook* oder *websocket* an das subscribende System versandt werden. Im *rest-hook* Fall postet das patientenführende System ein NotificationBundle an den in `Subscription.channel.endpoint` definierten REST Endpunkt. Bei einer *websocket* Notification geschieht das über einen Websocket-Channel. Die Websocket URL, sowie ein Access Token können mittels [`$get-ws-binding-token` Operation](https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/OperationDefinition-backport-subscription-get-ws-binding-token.html) vom Server abgerufen werden.
-
-## Abgrenzung zu 'Patient merge'
-Das Mergen von Patientendaten ist Aufgabe des bestätigungsrelevanten Systems (d.h. hier des patientenführenden Systems / KIS).
-Ein externes Starten eines Patient merge - bspw. durch die [$patient-merge Operation aus R5](https://hl7.org/fhir/R5/patient-operation-merge.html) - MUSS von einem bestätigungsrelevanten System NICHT unterstützt werden.
-
-**Hinweis**: Die Patienten-Ressource, die nicht weiter verwendet werden soll, nennen wir im Folgenden die "obsolete Ressource". Die Ressource, die erhalten bleiben soll, nennen wir "resultierende Ressource".
-
-### Obsolete Patienten-Ressource
-Es gelten keine gesonderten Anforderungen an eine obsolete Patienten-Ressource über die ISiKPatient Profilanforderungen hinaus.
-
-Allerdings KANN das patientenführende System die obsolete Patienten-Ressource weiter vorhalten. Ein Entfernen der obsoleten Ressource ist ebenfalls erlaubt.
-
-Falls die obsolete Ressource nach einem merge weiter vorgehalten wird, SOLLEN die Elemente der obsoleten Ressource folgendermaßen befüllt werden, um sicherzustellen, dass die obsolete Ressource auf die resultieren Ressource verweist und dass die obsolete Ressource als inaktiv gekennzeichnet ist:
-- .active = false
-- .link.other = Reference(auf “resultierenden” Patient)
-- .link.type = “replaced-by”
-
-### Resultierende Patienten-Ressource
-Es gelten keine gesonderten Anforderungen an eine obsolete Patienten-Ressource über die ISIKPatient Profilanforderungen hinaus.
-
-Allerdings SOLL das patientenführende System nach einem merge die Elemente der resultierenden Ressource folgendermaßen befüllen, um sicherzustellen, dass die resultierende Ressource auf die obsolete Ressource verweist:
-- .link.other = Reference.identifier (logische Referenz mittels Patientennummer Identifier auf “obsoleten” Patient)
-- .link.type = “replaces”
-
-Siehe auch: {{pagelink:ImplementationGuide/markdown/Patient/Patient_Profil.md, text:Patienten Profil }}
-
-### Referenzen auf das Patientenobjekt
-Es gilt folgende Annahme: Das patientenführende System SOLL sicherstellen, dass alle auf die obsolete Ressource referenzierenden FHIR-Ressourcen nach dem Patient merge auf die resultierende Ressource referenzieren.
-
-## Hinweise zum Client-System
-
-### Recovery Mechanismus
-Ein Recovery Mechanismus wird benötigt, damit im Falle einer ausgebliebenen Patient merge Notification ein Client die aktuelle Patienteninstanz auffinden und erneut referenzieren kann.
-
-Folgender Hinweis dient der Einhaltung eines Recovery Mechanismus:
-
-Client-Systeme SOLLEN den Status einer gecachten Patienteninstanz vor der Interaktion mit einem patientenführenden System per READ auf das Patientenobjekt überprüfen.
-Sollte die Patienten-Ressource nicht mehr bereitstehen, oder die Ressource den status `active=false` haben, kann das Patientenobjekt mittels Suche auf einen bekannten und stabilen Identifier, bspw. die gesetzliche Krankenversichertennummer, neu geladen werden.
-
-
-### Datensicherheit Client
-
-**Hinweis**: Die "patient-merge Subscription-Notification" kann personenbezogene Daten versenden, falls man "full-resource" als Content-Code gewählt hat. Für den REST-Hook sollte daher stets ein HTTPS-Endpunkt genutzt werden. Zusätzlich kann Subscription.channel.header genutzt werden, um einen Autorisierungs-Header an den Endpunkt zu übertragen.
-Siehe auch: [Safety and Security, Subscription Backport IG](https://hl7.org/fhir/uv/subscriptions-backport/safety_security.html)
-
-In jedem Fall sind auch Client-seitig die notwendigen Maßnahmen zu ergreifen, um eine sichere Kommunikation personenbezogener Daten zu gewährleisten.
-
-### Websocket
-
-Hier muss sich der Client per [`$get-ws-binding-token` Operation](https://hl7.org/fhir/uv/subscriptions-backport/OperationDefinition-backport-subscription-get-ws-binding-token.html) einen Token zum Zugriff auf den Websocket-Endpunkt des patientenführenden Systems holen. In der Operation-Response sind zusätzlich die Expiration-Dauer, sowie der Websocket-Endpunkt enthalten.
-Siehe auch: [Subscriptions R5 Backport IG, Websocket](https://hl7.org/fhir/uv/subscriptions-backport/channels.html#websockets)
-
-## Beispiele
-Die Patient merge Notification kann folgendermaßen illustriert werden:
-
-Es existieren fälschlicherweise zwei Instanzen im patientenführenden System, die sich lediglich hinsichtlich der organisationsspezifischen Patienten-ID unterscheiden.
-Diese sind:
-
-"Quell" Patienten-Ressource:
-{{json:DorisQuelle}}
-
-und
-
-"Ziel" Patienten-Ressource:
-{{json:DorisZiel}}
-
-Mittels eines Patient merge wird die "Ziel" Patienten-Ressource ausgewählt und beide Ressourcen entsprechend modifiziert. Daraus entsteht die resultierende Patienten-Instanz:
-{{json:Resources/static/Patient-DorisResultat.json}}
-
-Da sich ein Client am patientenführenden System für das dedizierte SubscriptionTopic (http://hl7.org/SubscriptionTopic/patient-merge) registriert hat, erhält der Client eine Benachrichtigung in Form eines Bundles mit Verweis auf die resultierende Ressource.
-
diff --git a/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Repraesentationsformate.md b/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Repraesentationsformate.md
deleted file mode 100644
index 2661fbf2..00000000
--- a/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Repraesentationsformate.md
+++ /dev/null
@@ -1,17 +0,0 @@
-## Repräsentationsformate
-
-Der FHIR-Standard beschreibt drei verschiedene [Repräsentationsformate](https://hl7.org/fhir/R4/formats.html#wire): XML, JSON und RDF (Turtle).
-Im Rahmen der ISiK-Spezifikation MÜSSEN bestätigungsrelevante Systeme (Server) die Formate [XML](https://hl7.org/fhir/R4/xml.html) und [JSON](https://hl7.org/fhir/R4/json.html) unterstützen.
-
-Client-seitige Implementierungen haben die Wahl zwischen XML- und JSON-Repräsentation, müssen jedoch in den HTTP Accept- und Content-Type-Headern entsprechend ausweisen, welche Repräsentation gewählt wurde.
-
-Wenn ein Client im Accept-Header ein vom Server nicht unterstütztes Format anfordert, so MUSS der Server mit dem Fehlercode `406 not acceptable` antworten.
-Wenn ein Client im Content-Type-Header ein vom Server nicht unterstütztes Format sendet, so MUSS der Server mit dem Fehlercode `415 unsupported media type` antworten.
-
-Es ist zu beachten, dass die Header `Content-Type` und `Accept` noch weitere FHIR-spezifische und allgemeine Parameter enthalten können. Siehe beispielsweise https://www.hl7.org/fhir/R4/http.html#version-parameter. Das Vorhandensein dieser Parameter darf nicht zu einem Fehler führen.
-
-Anfragen, in denen eine andere FHIR-Version als die hier vereinbarte Version `4.0` angefordert wird, müssen mit Fehlercode `406 - not acceptable` beantwortet werden.
-
-
-
-
diff --git a/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Rest.md b/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Rest.md
deleted file mode 100644
index a756d661..00000000
--- a/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Rest.md
+++ /dev/null
@@ -1,51 +0,0 @@
-# REST-API
-
-## Read-Interaktionen
-Instanzen von Datenobjekten, die die REST-Interaktion "READ" fordern, MÜSSEN per HTTP GET auf ```[BASE_URL]/[resourceType]/[ID]``` abgerufen werden können.
-Siehe: https://www.hl7.org/fhir/R4/http.html#read
-
-## Search-Interaktionen
-Die Suche MUSS sowohl mittels HTTP GET als auch HTTP POST (vgl. [FHIR RESTful Search - Introduction](https://www.hl7.org/fhir/R4/search.html#Introduction)) unterstützt werden. Die URL-Parameter komplexer Suchanfragen können personenbezogene Merkmale enthalten, daher ist im Echtbetrieb die Suche mittels HTTP POST in Verbindung mit TLS-Verschlüsselung vorzuziehen.
-
-## Create-Interaktionen
-Das Erstellen einer Ressource kann per HTTP POST (vgl. [FHIR RESTful API - create](https://www.hl7.org/fhir/R4/http.html#create)) unterstützt werden. Einzelne Datenobjekte (spezifiziert im vorliegenden Basismodul oder in einem ISiK Erweiterungsmodul) können diese Interaktion als verpflichtend kennzeichnen.
-
-Es liegt im Ermessen des bestätigungsrelevanten Systems, ob eine externe Ressource durch das System direkt übernommen wird. Auch wie die Herkunft der übernommenen Ressource gekennzeichnet wird, liegt im Ermessen des bestätigungsrelevanten Systems.
-
-Eine Ressource welche nicht durch das bestätigungsrelevante System angelegt wird, KANN in ```Resource.meta.tag``` eine Angabe enthalten, welche indiziert, dass diese Ressource durch ein Fremdsystem erzeugt wurde. Dieser Tag KANN durch den Server hinzugefügt werden, sollte der Client diese Angabe nicht mit übermitteln. Eine von einem System vorgenommene Auszeichnung von Fremdübernahmen SOLL über den Code ```external``` aus dem Kodiersystem ```https://fhir.de/CodeSystem/common-meta-tag-de``` erfolgen. Weitere Kodierungen KÖNNEN hinzugefügt werden.
-
-```
-json
-{
- "resourceType": "Patient",
- "meta": {
- "tag": [
- {
- "system": "http://fhir.de/CodeSystem/common-meta-tag-de",
- "code": "external"
- }
- ]
- }
- [...]
-}
-```
-
-Eine weitere Differenzierung der Herkunft kann mittels ```Resource.meta.security``` kodiert werden. Hierzu KÖNNEN Codes aus dem ValueSet [SecurityIntegrityObservationValue](https://terminology.hl7.org/ValueSet/v3-SecurityIntegrityObservationValue) verwendet werden.
-
-Sollte die erzeugte Ressource dauerhaft in das bestätigungsrelevante System übernommen werden, KANN der entsprechende Tag in ```Patient.meta.tag``` entfernt werden. In diesem Falle MUSS die id der Ressource stabil bleiben und darf nicht verändert werden.
-
-
-Per Create-Interaktion erzeugte Ressourcen MÜSSEN im Falle einer erfolgreichen Übermittlung direkt über die READ- und SEARCH-Interaktionen zur Verfügung gestellt werden.
-
-Ressourcen, die zu einem entsprechenden ISiK-Profil nicht konform sind, MÜSSEN durch das bestätigungsrelevante System abgelehnt werden. Als Antwort MUSS ein HTTP Status-Code 400 - Bad Request mit einer ```OperationOutcome```-Ressource zurückgegeben werden, falls es sich um einen syntaktischen Fehler in der Repräsentation der Ressource handelt. Die ```OperationOutcome``` MUSS eine Auflistung aller Fehler in der übermittelten Ressource in kodierter Form vorweisen. Anderweitig (semantisch) invalide Ressourcen MÜSSEN ebenfalls mit einer entsprechenden OperationOutcome-Ressource abgewiesen werden. In diesem Fall SOLLTE der HTTP Status-Code HTTP 422 - Unprocessable Entity verwendet werden.
-
-
-## Update-Interaktionen
-Das Update einer Ressource KANN per HTTP PUT (vgl. [FHIR RESTful API - update](https://www.hl7.org/fhir/R4/http.html#update)) unterstützt werden. Es ist zu beachten, dass beim Update einer Ressource bestimmte dazugehörige [Metadaten](https://www.hl7.org/fhir/R4/resource.html#Meta) beibehalten werden SOLLTEN. Die gleichen Vorgaben für die Handhabung von invaliden Ressourcen wie beschrieben im Abschnitt "Create-Interaktionen", gelten auch für Update-Interaktionen.
-
-
-## Sicherheitsaspekte
-Alle REST-Interaktionen müssen sowohl mittels HTTP als auch HTTPS (TLS-Verschlüsselung) unterstützt werden. Vorgaben zur TLS-Verschlüsselung sind dem nachfolgenden Link für die FHIR Security Check List zu entnehmen.
-Im Echtbetrieb MUSS die Kommunikation ausschließlich per HTTPS erfolgen.
-Weiterhin sind geeignete Maßnahmen zur Risiko-Minimierung (z.B. Benutzerautorisierung / -authentifikation) zu treffen, siehe http://build.fhir.org/security.html#6.1.0.
-Diese sind in der jetzigen Stufe des ISiK Basismoduls jedoch nicht bestätigungsrelevant.
diff --git a/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Suchparameter.md b/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Suchparameter.md
deleted file mode 100644
index fa6155ac..00000000
--- a/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Suchparameter.md
+++ /dev/null
@@ -1,174 +0,0 @@
----
-topic: UebergreifendeFestlegungen-UebergreifendeFestlegungen-Suchparameter
----
-## Allgemeine Hinweise zu Suchparametern
-Originäre ISiK Use Cases sind versorgungsorientiert und patientenorientiert. Dies resultiert darin, dass in der Profilierung der ISiK-Datenobjekte das Vorhandensein einer Referenz auf ISiKPatient (Patient) und ISiKKontaktGesundheitseinrichtung (Encounter) wo möglich gefordert wird. Entsprechend sind Abfragen durch Clients auf Basis von bekannten Informationen aus dem Kontext *einer einzelnen* Patient- und/oder Encounter-Ressource zu begrenzen (Abfragen auf Patientenkohorten oder sonstige Forschungsabfragen sind nicht im Fokus von ISiK).
-Auf Basis dieser grundsätzlichen Design-Entscheidung können Clients davon ausgehen, dass alle vorliegenden referenzierten bzw. referenzierenden Ressourcen aus dem Kontext der genannten Ressourcen-Typen abrufbar sind. Durch das Vorliegen der Referenzen erfolgt die Dokumentation aller Datenobjekte stets im korrekten Patientenkontext. Zudem liegen für den jeweiligen Kontext relevante Informationen zur Interpretation der Dokumentation und Sicherstellung der Datenintegrität vor.
-
-Innerhalb der jeweiligen Abschnitte 'Interaktionen' (Siehe {{pagelink:ImplementationGuide/markdown/Datenobjekte/Datenobjekte.md}}) werden für alle innerhalb dieses Implementierungsleitfadens spezifizierten FHIR-Ressourcen Suchparameter bestimmt, welche im Rahmen des Bestätigungsverfahrens von ISiK unterstützt werden MÜSSEN.
-
-Ein Server MUSS sicherstellen, dass nicht unterstützte oder leere Suchparameter ignoriert werden und **nicht** zu einem Fehler führen. Siehe [FHIR RESTful Search - Handling Errors](https://www.hl7.org/fhir/R4/search.html#errors).
-Alle vom Server für eine konkrete Suche verwendeten Parameter MÜSSEN im Self-Link des Searchset-Bundles angegeben sein, siehe [Self-Link](https://hl7.org/fhir/R4/search.html#selflink).
-
-Alle Suchparameter in FHIR entsprechen einem von neun definierten [Such-Parameter-Typen](https://hl7.org/fhir/R4/search.html):
-
-* Number
-* Date/DateTime
-* String
-* Token
-* Reference
-* Composite
-* Quantity
-* URI
-* Special
-
-Des Weiteren werden zusätzlich sogenannte 'Modifier' pro Suchparameter-Typ definiert. Eine Übersicht findet sich unter ["Search Modifiers"](https://hl7.org/fhir/R4/search.html#modifiers).
-
-Für die im Rahmen dieses Leitfadens relevanten Typen gelten folgende allgemeinen Festlegungen:
-
-### Date/DateTime
-
-Die Präfixe `lt`,`le`,`gt`,`ge`,`eq` MÜSSEN für jeden Suchparameter vom Typ 'date/dateTime' unterstützt werden.
-
-
-Begründung: Die Abfragemöglichkeit mittels Präfix arbeitet ungewollten Massendatenabfragen entgegen, da sich sonst Suchen zwangsläufig über den gesamten Zeitraum erstrecken würden.
-
-
-
-**Beispiele**:
-
-```[base]/Encounter?date=eq2024-01-01&patient=Patient/Test```
-Suche nach allen Kontakten mit einem Datum am 2024-01-01 für den Patienten "Test".
-
-```[base]/Condition?recorded-date=ge2024-01-01&recorded-date=lt2024-02-01&patient=Patient/Test```
-Suche nach allen Diagnosen mit einem Dokumentationsdatum im Zeitraum Januar 2024 (von 2024-01-01 bis - aber nicht einschließlich - 2024-02-01) im Patientenkontext "Test".
-
-Es ist zu beachten, dass jedes Datum einen impliziten Werte-Bereich besitzt. Siehe https://hl7.org/fhir/R4/search.html#date.
-
-### String
-
-Der Modifier `:contains` MUSS für alle spezifizierten Suchparameter vom Typ 'String' unterstützt werden.
-
-**Beispiele**:
-
-```[base]/Patient?address:contains=Berlin```
-Diese Suchanfrage gibt alle Patienten zurück zum Client, welche in einem Adress-Bestandteil den String 'Berlin' enthält (z.B. alle Berliner Adressen unabhängig von konkreten Bezirken).
-
-### Token
-
-Der Modifier `:not` MUSS für alle spezifizierten Suchparameter vom Typ 'Token' unterstützt werden, sofern diese auf die Datentypen "code", "Coding" oder "CodeableConcept" verwendet werden.
-
-Der Modifier `:text` MUSS für alle spezifizierten Suchparameter vom Typ 'Token' unterstützt werden, sofern diese auf die Datentypen "Coding" oder "CodeableConcept" verwendet werden.
-
-**Beispiele**:
-
-```[base]/Condition?code:text=Freitext```
-Diese Suche gibt alle Condition-Ressourcen zurück zum Client, welche innerhalb `Condition.code.text` das Wort "Freitext" enthält. Es ist zu beachten, dass hier ein partielles Matching erfolgen MUSS (es ist implizit der Modifier :contains anzunehmen).
-
-```[base]/Condition?code:not=Test```
-Diese Suche gibt alle Condition-Ressourcen zurück zum Client, welche innerhalb `Condition.code.coding` NICHT den Code 'Test' enthält. Es ist zu beachten, dass dies auch alle Ressourcen beinhaltet, die keinen kodierten Wert für `Condition.code` enthalten.
-
-### Reference
-
-Der Modifier `:identifier` KANN für alle spezifizierten Suchparameter vom Typ 'Reference' unterstützt werden.
-
-Der Modifier `:identifier` MUSS implementiert werden, wenn die entsprechende Reference eine 1..1-Kardinalität oder ein MS-Flag auf Reference.identifier hat.
-
-Dies gilt beispielsweise für Encounter.account - also die Referenz zwischen ISiKKontaktGesundheitseinrichtung und ISiKAbrechnungsfall. Encounter MÜSSEN anhand der Fallnummer gesucht werden können, ohne dass Clients Zugriffsberechtigungen auf Accounts haben müssen, bzw. ohne dass Account zwingend implementiert/referenziert werden muss. Der Suchabruf erfolgt entsprechend dann nur über die logische Referenz.
-
-
-
-**Beispiele**:
-
-```[base]/Coverage?Payor:identifier=http://fhir.de/sid/arge-ik/iknr|123456```
-Diese Suche gibt alle Coverage-Ressourcen zurück zum Client, welche innerhalb `Coverage.payor` eine logische Referenz auf den Versicherer mit der IK-Nummer "123456" enthält.
-
-Für Suchparameter vom Typ 'Reference' sind nur teilweise die Festlegungen für [Chaining](https://hl7.org/fhir/R4/search.html#chaining) und [Reverse Chaining](https://hl7.org/fhir/R4/search.html#has) verpflichtend zu implementieren (siehe "Verkettete Suchparameter").
-
-**Beispiele**:
-
-``[base]/Procedure?subject.name=Test``
-Diese Suche gibt alle Prozeduren zurück zum Client, welche innerhalb `Procedure.subject` auf einen Patienten verweist mit dem Namen "Test".
-
-``[base]/Condition?_has:Encounter:diagnosis:identifier=https://example.org/fhir/sid/aufnahmenummer|1234``
-Diese Suche gibt alle Diagnosen zurück, die im Kontext des Kontakts mit der Aufnahmenummer '1234' dokumentiert worden sind.
-
-## Verpflichtende Suchparameter (Alle Datenobjekte)
-
-Folgende Suchparameter MÜSSEN für alle bestätigungsrelevanten Datenobjekte implementiert werden:
-
-* ``_id``
-
- - Beispiele: ``GET [base]/Patient?_id=103270``
- - Anwendungshinweise: Weitere Informationen zur Suche nach "_id" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Parameters for all resources"](https://hl7.org/fhir/R4/search.html#all).
- - Dieser Suchparameter ist für die Umsetzung des IHE PDQm Profils verpflichtend.
-
-* ``_tag``
-
- - Beispiele: ``GET [base]/Patient?_tag=https://example.org/codes|needs-review``
- - Anwendungshinweise: Weitere Informationen zur Suche nach "_tag" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Parameters for all resources"](https://hl7.org/fhir/R4/search.html#all) und [FHIR-Basisspezifikation - Abschnitt "Tags"](https://www.hl7.org/fhir/R4/resource.html#simple-tags).
-
-* ``_count``
-
- - Beispiele: ``GET [base]/Patient?_count=100``
- - Anwendungshinweise: Weitere Informationen zur Suche nach "_count" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Page Count"](https://www.hl7.org/fhir/R4/search.html#count).
-
- Hieraus ergibt sich, dass durch ein [Paging entsprechend der FHIR-Kernspezifikation](https://www.hl7.org/fhir/R4/http.html#paging) unterstützt werden MUSS.
- Für die URIs in den Link-Relationen "first", "last", "next", sowie "prev" MUSS sichergestellt werden, dass NICHT die ursprünglich verwendeten Suchparameter, sowie anderweitig sensitive Informationen enthalten, welche in der Suchanfrage an das bestätigungsrelevante System versendet wurden.
- Der "self"-Link innerhalb des Such-Bundles MUSS entsprechend der Vorgaben aus [FHIR Kernspezifikation - 3.1.1.6 - Server Conformance](https://www.hl7.org/fhir/R4/search.html#conformance) strukturiert sein.
-
- Der ```:iterate``` Modifier KANN unterstützt werden.
-
-Die aufgelisteten Suchparameter MÜSSEN entsprechend der Vorgaben für das CapabilityStatement pro Ressource aufgelistet werden.
-
-## Verkettete Suchparameter (Fokus auf Patient und Encounter)
-
-Für Suchparameter namens 'patient' und 'encounter' MÜSSEN die Festlegungen für [Chaining](https://hl7.org/fhir/R4/search.html#chaining) verpflichtend implementiert werden. Eine Verkettung über die Chaining-Parameter (Multi-Chaining) KANN implementiert werden.
-
-* ``Chaining``
-
- - Beispiel für Chaining mit Referenz auf einen Patienten: ``GET [base]/Encounter?patient.identifier=1234``
- - Hinweis: Die Patient-Instanz ist für die Abfrage zentral, weshalb diese Form der Suchabfrage hier notwendig erscheint (siehe einleitenden Absatz dieses Abschnitts). Analog gilt dies für den Fallkontakt (Encounter).
-
-Für Suchparameter KÖNNEN die Festlegungen für [Reverse Chaining](https://hl7.org/fhir/R4/search.html#has) implementiert werden.
-
-* ``Reverse Chaining``
-
- - Beispiel für Reverse Chaining mit Referenz auf einen Patienten aus einem Observation-Kontext: ```GET [base]/Patient?_has:Observation:patient:code=1234-5```
- - Hinweis: Diese Form der Suchanfrage dient im Wesentlichen dem Auffinden von Patienten (z.B. unter Angabe einer besonderen Diagnose, Beobachtung, Prozedur etc.) oder Fallkontakten (z.B. zum Ermitteln des Kontextes einer Prozedur)
-
-Der Suchparameter ``_include`` MUSS verpflichtend für Suchparameter implementiert werden, für die auch Chaining erforderlich ist ('patient' und 'encounter'):
-
-* ``_include``
-
- - Beispiele: ``GET [base]/Encounter?_include=Encounter:patient``
- - Anwendungshinweise: Weitere Informationen zur Suche nach "_include" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Including other resources in result"](https://www.hl7.org/fhir/R4/search.html#revinclude).
- - Für alle Referenzen, für die ein Chaining unterstützt wird, MUSS auch der _include-Parameter implementiert werden. Alle unterstützten Include-Referenzen MÜSSEN im CapabilityStatement unter ```CapabilityStatement.rest.resource.searchInclude``` angegeben werden. Siehe {{pagelink:ImplementationGuide/markdown/CapabilityStatement.md}}.
-
-
-Für Suchparameter KÖNNEN die Festlegungen für `_revinclude` implementiert werden.
-
-* ``_revinclude``
-
- - Beispiele: ``GET [base]/Patient?_revinclude=Encounter:subject``
- - Anwendungshinweise: Weitere Informationen zur Suche nach "_revinclude" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Including other resources in result"](https://www.hl7.org/fhir/R4/search.html#revinclude).
- - Alle unterstützten Revinclude-Referenzen MÜSSEN im CapabilityStatement unter ```CapabilityStatement.rest.resource.searchRevInclude``` angegeben werden. Siehe {{pagelink:ImplementationGuide/markdown/CapabilityStatement.md}}.
-
-Im Kontext dieser Spezifikation (einschließlich weitere ISIK Module) werden - wo notwendig - weitere Festlegungen für [Chaining](https://hl7.org/fhir/R4/search.html#chaining) und [Reverse Chaining](https://hl7.org/fhir/R4/search.html#has) getroffen.
-
-Mehrfach-Chaining ist generell nicht gefordert, es sei denn es wird in einem Modul für einzelne Parameter explizit verlangt.
-
-
-## Best-Practice-Empfehlungen für Standard-Suchfilter
-
-Diese grundlegenden Best-Practice-Empfehlungen beziehen sich auf die korrekte Verwaltung des Suchprozesses seitens des Servers, mit Bezug auf Sicherheit im klinischen Umfeld. Unstimmigkeiten in den Erwartungen zwischen Client und Server können dazu führen, dass mehr Ressourcen als erwartet oder angemessen gefunden werden, oder, dass Ressourcen in den Suchergebnissen fehlen, die eigentlich vorhanden sein sollten. Im Folgenden werden daher Empfehlungen für Standard-Suchfilter genannt, die ein Grundmaß an Sicherheit im klinischen Umfeld bereitstellen sollen.
-
-- Der Server SOLLTE dafür sorgen, dass Clients die benötigten Informationen finden können, auch bei Inhalten, die sich über mehrere FHIR-Ressourcen hinweg strecken.
-
-- Wenn der Inhalt eines Suchparameters leer ist, SOLLTE der Server diesen ignorieren.
-
-- Wenn der Inhalt eines Suchparameters syntaktisch falsch ist, SOLLTE der Server einen Fehler zurückgeben. Handelt es sich jedoch um eine logische Bedingung (z.B. einen Code), SOLLTE der Server die Suche verarbeiten, einschließlich des Parameters. Als Ergebnis wird in diesem Fall eine leere Suchmenge zurückgegeben, da der Parameter nicht erfüllt werden kann. In solchen Fällen kann zusätzlich ein OperationOutcome mit Hinweisen und Warnungen über den Suchprozess in das Ergebnis aufgenommen werden. Dieses wird in die Suchergebnisse als Eintrag mit [search mode](https://www.hl7.org/fhir/R4/bundle-definitions.html#Bundle.entry.search.mode) = [`outcome`](https://www.hl7.org/fhir/R4/valueset-search-entry-mode.html) aufgenommen. Clients können diese Informationen nutzen, um zukünftige Suchen zu verbessern.
-
-- Wenn der Server geeignete Standardfilter bei der Suche auf der Grundlage des Patientenkontextes (z.B. das Herausfiltern von fehlerhaften Datensätzen oder inaktiven und verstorbenen Patienten) enthält, SOLLTEN diese angemessen und eindeutig dokumentiert sein (vorzugsweise durch Aufnahme in den 'self link' für eine Suche).
-
-- Weitere Hinweise können in der [FHIR Spezifikation im Abschnitt `Search`](https://www.hl7.org/fhir/R4/search.html#errors) eingesehen werden.
diff --git a/ImplementationGuide/markdown/UseCasesAnwendung.md b/ImplementationGuide/markdown/UseCasesAnwendung.md
deleted file mode 100644
index 0ae89646..00000000
--- a/ImplementationGuide/markdown/UseCasesAnwendung.md
+++ /dev/null
@@ -1,3 +0,0 @@
-# Use Cases und Anwendungszusammenhänge
-
-{{index:current}}
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/UseCasesAnwendung/UseCases.md b/ImplementationGuide/markdown/UseCasesAnwendung/UseCases.md
deleted file mode 100644
index 362a0675..00000000
--- a/ImplementationGuide/markdown/UseCasesAnwendung/UseCases.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# Use Cases - Übersicht
-Im Folgenden wird ein grafischer Überblick über für dieses Modul relevante Anwendungsfälle gegeben.
-Da es sich um eine Zusammenfassung handelt, werden nur folgende Use Case und dafür hinreichende Funktionen dargestellt:
-* Allgemeine und intuitive verständliche Use Cases.
- * Kombinationen und weitere Details sind möglich.
- * Übergreifende Use Cases und ihre Sub-Use-Cases können ggf. in einem separaten Diagramm auf den entsprechenden Seiten gefunden werden.
-* Allgemeine und intuitive Adverse Use Cases. Diese gilt es zu vermeiden.
-
-
-**Use Case Digramm**
-
-
-
-
-
diff --git a/ImplementationGuide/markdown/ValueSet/ValueSet_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/ValueSet/ValueSet_AnmerkungenZuDenMustSupportFeldern.md
deleted file mode 100644
index 15838a0f..00000000
--- a/ImplementationGuide/markdown/ValueSet/ValueSet_AnmerkungenZuDenMustSupportFeldern.md
+++ /dev/null
@@ -1,39 +0,0 @@
-### Anmerkungen zu Must-Support-Feldern
-
-### `ValueSet.url`
-
-**Bedeutung:** Eindeutige Url zur Identifizierung des ValueSets. Absolute Urls sind zu bevorzugen.
-
-**Hinweise:** OIDs SOLLTEN als weitere Identifier des CodeSystems verwendet werden. In jedem Fall SOLLTE eine Canonical Url vergeben werden.
-
-### `ValueSet.version`
-
-**Bedeutung:** Version des ValueSets
-
-**Hinweise:** Jede Änderung des dazugehörigen CodeSystems MUSS eine Änderung in der Version des CodeSystems und ValueSets nach sich ziehen.
-
-### `ValueSet.name`
-
-**Bedeutung:** Maschinenlesbarer Name des ValueSets
-
-**Hinweise:** Der Constraint [vsd-0](https://www.hl7.org/fhir/R4/valueset.html#invs) ist hierbei zu beachten.
-
-### `ValueSet.status`
-
-**Bedeutung:** Indikation, ob das ValueSet in aktiver Verwendung ist.
-
-**Hinweise:** Alle in einem System möglichen Status-Werte müssen über FHIR korrekt repräsentiert werden können, mindestens jedoch die Status-Werte "active" und "retired". Deren korrekte Abbildung wird im Rahmen des Bestätigungsverfahrens überprüft.
-
-### `ValueSet.useContext`
-
-**Bedeutung:** Angabe für welches Datenelement das ValueSet relevant ist
-
-**Hinweise:** Es muss mindestens ein useContext angegeben werden, in dem der Ressourcen-Typ kodiert wird, in dem das ValueSet in einem Element zur Verwendung kommt.
-
-### `ValueSet.expansion`
-
-**Bedeutung:** Angabe der Konzepte aus denen sich das ValueSet zusammensetzt.
-
-**Hinweise:** Mindestens MUSS ein Code und ein Anzeigetext spezifiziert werden.
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/ValueSet/ValueSet_Beispiele.md b/ImplementationGuide/markdown/ValueSet/ValueSet_Beispiele.md
deleted file mode 100644
index 240b2810..00000000
--- a/ImplementationGuide/markdown/ValueSet/ValueSet_Beispiele.md
+++ /dev/null
@@ -1,5 +0,0 @@
-### Beispiele
-
-Valides Minimalbeispiel Patient:
-
-{{json:isikvaluesetexample}}
diff --git a/ImplementationGuide/markdown/ValueSet/ValueSet_Interaktionen.md b/ImplementationGuide/markdown/ValueSet/ValueSet_Interaktionen.md
deleted file mode 100644
index a6c8a8ec..00000000
--- a/ImplementationGuide/markdown/ValueSet/ValueSet_Interaktionen.md
+++ /dev/null
@@ -1,67 +0,0 @@
-### Interaktionen
-
-Für die Ressource ValueSet MUSS die REST-Interaktion "READ" implementiert werden.
-
-Folgende Suchparameter sind für das Bestätigungsverfahren relevant, auch in Kombination:
-
-1. Der Suchparameter "_id" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/ValueSet?_id=103270```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "_id" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Parameters for all resources"](https://hl7.org/fhir/R4/search.html#all).
-
-1. Der Suchparameter "url" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/ValueSet?url=http://example.org/fhir/ValueSet/test```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "ValueSet.url" finden sich in der [FHIR-Basisspezifikation - Abschnitt "uri"](https://www.hl7.org/fhir/R4/search.html#uri).
-
-1. Der Suchparameter "name" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/ValueSet?name=TestValueSet```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "ValueSet.name" finden sich in der [FHIR-Basisspezifikation - Abschnitt "String Search"](https://hl7.org/fhir/R4/search.html#string).
-
-1. Der Suchparameter "status" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/ValueSet?status=active```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "ValueSet.status" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search""](https://hl7.org/fhir/R4/search.html#token).
-
-
-1. Der Suchparameter "version" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/ValueSet?version=1.0.0```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "ValueSet.version" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "context-type-value" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/ValueSet?context-type-value=http://terminology.hl7.org/CodeSystem/usage-context-type|focus$http://hl7.org/fhir/resource-types|Encounter```
-
-
- Mit dieser Abfrage können hausinterne Kataloge anhand des Ressource-Typs ermittelt werden. Diese Informationen sind u.a. relevant im Kontext von:
- - Hausinternen Prozeduren/Diagnosen-Codes
- - Kodierung von Encounter-Informationen (z.B. Wahlleistungen, Orttypen)
-
- Use Cases im Zusammenhang:
-
- (A) Zur Konfigurationszeit können passende ValueSets von einem Server spezifisch für einen Ressourcentyp abgerufen und vorbereitend auf eine Systemintegration begutachtet bzw. in Client-Systeme eingebunden werden. In diesem Sinne wird die Abfrage im Kontext der [Terminvereinbarung durch einen Termin-Requestor genutzt](https://simplifier.net/guide/isik-terminplanung-v4/ImplementationGuide-markdown-Datenobjekte-Operations?version=current).
-
- (B) Zur Laufzeit können spezifische ValueSets synchronisiert bzw. direkt in die Eingabemasken von Clients eingebunden werden.
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "CodeSystem.useContext" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Composite Search Parameters"](https://www.hl7.org/fhir/R4/search.html#composite).
-
----
diff --git a/ImplementationGuide/markdown/ValueSet/ValueSet_Kompatibilitaet.md b/ImplementationGuide/markdown/ValueSet/ValueSet_Kompatibilitaet.md
deleted file mode 100644
index a913d41a..00000000
--- a/ImplementationGuide/markdown/ValueSet/ValueSet_Kompatibilitaet.md
+++ /dev/null
@@ -1,3 +0,0 @@
-### Kompatibilität
-
-Für das Profil ISiKValueSet wurde bis zum Zeitpunkt der Veröffentlichung kein Abgleich der Kompatibilität zu anderen Profilen (der KBV und der Medizininformatik-Initiative) durchgeführt.
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/ValueSet/ValueSet_Motivation.md b/ImplementationGuide/markdown/ValueSet/ValueSet_Motivation.md
deleted file mode 100644
index 2a7c4b08..00000000
--- a/ImplementationGuide/markdown/ValueSet/ValueSet_Motivation.md
+++ /dev/null
@@ -1,6 +0,0 @@
-### Motivation
-
-ISiK erlaubt in diversen Kontexten die Erweiterung der Kodierung durch Krankenhaus- / System-interne Kodierungen.
-Mittels der Veröffentlichung von ValueSets können Auswahllisten für externe Clients bereitgestellt werden, sodass diese entsprechende Kodierungen ebenfalls anbieten können.
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/ValueSet/ValueSet_Profil.md b/ImplementationGuide/markdown/ValueSet/ValueSet_Profil.md
deleted file mode 100644
index 85e69fb1..00000000
--- a/ImplementationGuide/markdown/ValueSet/ValueSet_Profil.md
+++ /dev/null
@@ -1,8 +0,0 @@
-### FHIR-Profil
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKValueSet' select Name: name, Canonical: url
-```
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKValueSet, hybrid}}
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_AnmerkungenZuDenMustSupportFeldern.md
deleted file mode 100644
index 97d4b872..00000000
--- a/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_AnmerkungenZuDenMustSupportFeldern.md
+++ /dev/null
@@ -1,53 +0,0 @@
-### Anmerkungen zu den Must-Support Feldern
-
-#### Das Profil ISiKVersicherungsverhaeltnisGesetzlich
-
-### `Coverage.identifier`
-
-**Hinweise:** Grundsätzlich ist zu beachten, dass das Versicherungsverhältnis für die gesetzliche Versicherung durch die 30-stellige KVNR identifiziert wird. Die 10-stellige KVNR ist hingegen ein Identifier für das Datenobjekt Patient. Siehe {{pagelink:ImplementationGuide/markdown/Patient/Patient_Profil.md, text:Datenobjekt - Patient}}. Es wird in ISiK davon ausgegangen, dass die 30-stellige KVNR nicht in bestätigungrelevanten Systemen geführt wird, sodass diese nicht als zuverlässiger Identifier für das Versicherungsverhältnis verwendbar ist. Bei einer Suche nach einem Versicherungsverhältnis SOLLTE dieses per Chaining auf das Datenobjekt Patient ermittelt werden.
-
-### `Coverage.status`
-
-**Bedeutung:** Der Status einer Instanz des Profils ISiKVersicherungsverhaeltnisGesetzlich.
-
-**Hinweise:** Das Element status macht deutlich, ob diese Instanz genutzt werden kann oder ob sie bspw. als ungültig oder falsch gekennzeichnet ist, siehe [FHIR Kernspezifikaton](https://hl7.org/fhir/R4/coverage-definitions.html#Coverage.status).
-
-### `Coverage.type`
-
-**Bedeutung:** Das Element type kennzeichnet die Art der Versicherung.
-
-**Hinweise:** Kennzeichnung als gesetzliche Versicherung, siehe [Beschreibung der deutschen Basisprofile](https://fhir.de/CodeSystem/versicherungsart-de-basis).
-
-### `Coverage.beneficiary`
-
-**Bedeutung:** Das Element beneficiary benennt die versicherte Person, auf die sich die Kostenübernahme durch die Versicherung bezieht.
-
-**Hinweise:** Für ISiK MUSS beneficiary ein Patient nach dem Profil ISiKPatient sein.
-
-### `Coverage.payor`
-
-**Bedeutung:** Der Kostenträger des Versicherten.
-
-**Hinweise:** Der Kostenträger der gesetzlichen Versicherung wird durch ein Institutskennzeichen in Coverage.payor.identifier identifiziert.
-
----
-
-#### Das Profil ISiKVersicherungsverhaeltnisSelbstzahler
-
-### `Coverage.subscriber`
-
-**Bedeutung:** Der Inhaber der Versicherungspolice.
-
-**Hinweise:** Kann entweder der Patient selbst oder ein Hauptversicherter nach dem Profil ISiKHauptversicherter sein.
-
-### `Coverage.beneficiary`
-
-Siehe entsprechenden Eintrag zum Profil ISiKVersicherungsverhaeltnisGesetzlich oben.
-
-### `Coverage.payor`
-
-**Bedeutung:** Der Rechnungsempfänger.
-
-**Hinweise:** Der Rechnungsempfänger für Selbstzahler ist entweder der Patient selbst, Hauptversicherte oder eine andere Partei.
-
----
diff --git a/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Beispiele.md b/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Beispiele.md
deleted file mode 100644
index c311e02e..00000000
--- a/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Beispiele.md
+++ /dev/null
@@ -1,9 +0,0 @@
-### Beispiele
-
-Valides Minimalbeispiel für das Profil ISiKVersicherungsverhaeltnisGesetzlich:
-
-{{json:coverageGesetzlich}}
-
-Valides Minimalbeispiel für das Profil ISiKVersicherungsverhaeltnisSelbstzahler:
-
-{{json:coveragePrivat}}
diff --git a/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Interaktionen.md b/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Interaktionen.md
deleted file mode 100644
index 6281f544..00000000
--- a/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Interaktionen.md
+++ /dev/null
@@ -1,108 +0,0 @@
-### Interaktionen
-
-Für die Ressource Coverage MUSS die REST-Interaktion "READ" implementiert werden.
-
-Folgende Suchparameter sind für das Bestätigungsverfahren relevant, auch in Kombination:
-
-#### Profil ISiKVersicherungsverhaeltnisGesetzlich
-
-1. Der Suchparameter "_id" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Coverage?_id=103270```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "_id" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Parameters for all resources"](https://hl7.org/fhir/R4/search.html#all).
-
-
-3. Der Suchparameter "status" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Coverage?status=active```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Coverage.status" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-4. Der Suchparameter "type" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Coverage?type=http://fhir.de/CodeSystem/versicherungsart-de-basis|GKV```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Coverage.type" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-5. Der Suchparameter "beneficiary" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Coverage?beneficiary=Patient/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Coverage.beneficiary" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-6. Der Suchparameter "patient" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Coverage?patient=Patient/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Coverage.beneficiary" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-7. Der Suchparameter "payor" in Kombination mit einem identifier-Modifier MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Coverage?payor:identifier=0123456789```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Coverage.payor" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-#### Profil ISiKVersicherungsverhaeltnisSelbstzahler
-
-1. Der Suchparameter "_id" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Coverage?_id=103270```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "_id" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Parameters for all resources"](https://hl7.org/fhir/R4/search.html#all).
-
-1. Der Suchparameter "beneficiary" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Coverage?beneficiary=Patient/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Coverage.beneficiary" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-1. Der Suchparameter "payor" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Coverage?payor=0123456789```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Coverage.payor" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-1. Der Suchparameter "subscriber" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Coverage?subscriber=Patient/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Coverage.subscriber" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-1. Der Suchparameter "status" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Coverage?status=active```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Coverage.status" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "type" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Coverage?type=http://fhir.de/CodeSystem/versicherungsart-de-basis|SEL```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Coverage.type" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Kompatibilitaet.md b/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Kompatibilitaet.md
deleted file mode 100644
index f970f415..00000000
--- a/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Kompatibilitaet.md
+++ /dev/null
@@ -1,19 +0,0 @@
-### Kompatibilität
-
-#### Profil ISiKVersicherungsverhaeltnisGesetzlich
-
-Das Profil ISiKVersicherungsverhaeltnisGesetzlich basiert auf dem Profil [Coverage der deutschen Basisprofile](http://fhir.de/StructureDefinition/coverage-de-basis).
-Instanzen, die gegen ISiKVersicherungsverhaeltnisGesetzlich valide sind, sind auch valide gegen
-* Profil ["Coverage, deutsches GKV Profil" der deutschen Basisprofile](https://fhir.de/StructureDefinition/coverage-de-gkv)
-
-Hinweise zu Inkompatibilitäten können über die [Portalseite](https://service.gematik.de/servicedesk/customer/portal/16) gemeldet werden..
-
-#### Profil ISiKVersicherungsverhaeltnisSelbstzahler
-
-Das Profil ISiKVersicherungsverhaeltnisSelbstzahler basiert auf dem Profil ["Coverage, deutsches Selbstzahlerprofil" der deutschen Basisprofile](https://fhir.de/StructureDefinition/coverage-de-sel).
-Instanzen, die gegen ISiKVersicherungsverhaeltnisSelbstzahler valide sind, sind auch valide gegen
-* Profil ["Coverage, deutsches Selbstzahlerprofil" der deutschen Basisprofile](https://fhir.de/StructureDefinition/coverage-de-sel)
-
-Hinweise zu Inkompatibilitäten können über die [Portalseite](https://service.gematik.de/servicedesk/customer/portal/16) gemeldet werden..
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Motivation.md b/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Motivation.md
deleted file mode 100644
index cd479ef1..00000000
--- a/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Motivation.md
+++ /dev/null
@@ -1,7 +0,0 @@
-### Motivation
-
-ISiK unterstützt Anwendungsszenarien, in denen durch das Krankenhaus erbrachte Leistungen erfasst oder gegenüber Kostenträgern abgerechnet werden. In diesen Anwendungsszenarien wird das Versicherungsverhältnis verwendet, um bspw. den Versicherungsstatus oder die Rechnungsanschrift der Versicherung zu ermitteln.
-
-In FHIR werden Versicherungsverhältnisse mit der [`Coverage`](https://hl7.org/fhir/R4/coverage.html)-Ressource repräsentiert.
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Profil.md b/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Profil.md
deleted file mode 100644
index eab2cd1c..00000000
--- a/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Profil.md
+++ /dev/null
@@ -1,21 +0,0 @@
-### Profil
-
-#### Profil ISiKVersicherungsverhaeltnisGesetzlich
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKVersicherungsverhaeltnisGesetzlich' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKVersicherungsverhaeltnisGesetzlich, hybrid}}
-
----
-
-#### Profil ISiKVersicherungsverhaeltnisSelbstzahler
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKVersicherungsverhaeltnisSelbstzahler' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKVersicherungsverhaeltnisSelbstzahler, hybrid}}
-
----
diff --git a/ImplementationGuide/style/master.html b/ImplementationGuide/style/master.html
deleted file mode 100644
index a25e85f4..00000000
--- a/ImplementationGuide/style/master.html
+++ /dev/null
@@ -1,54 +0,0 @@
-
-
-
-
-
-
-
- {{ guide-title }}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Die Grafik zeigt an einem vereinfachten Beispiel die Zuordnung des HTML-Dokumentes zu Patient und Kontakt in der aktuellen Ausbaustufe von ISiK (schwarze Pfeile). Die grauen Pfeile deuten die Übernahme strukturierter Daten, wie sie in weiteren Ausbaustufen erforderlich wird.
-
-### Hinweise zum Umgang mit der menschenlesbaren Repräsentation
-
-Die menschenlesbare Repräsentation ("Narrative") eines Dokumentes setzt sich zusammen aus dem Inhalt von 'Composition.text', einer Repräsentation der Metadaten (z.B. Dokumenttyp, Patientenname, Patientennummer, Aufnahmenummer, Datum) sowie der Aggregation der Inhalte von 'Composition.section', wobei zu beachten ist, dass ein Dokument beliebig viele Sections haben kann.
-Die einzelnen Bestandteile des Narratives KÖNNEN mit \
-
----
diff --git a/ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_Profil.md b/ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_Profil.md
deleted file mode 100644
index 92b173ef..00000000
--- a/ImplementationGuide/markdown/BerichtSubsystem/BerichtSubsystem_Profil.md
+++ /dev/null
@@ -1,9 +0,0 @@
-### Profil
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKBerichtSubSysteme' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKBerichtSubSysteme, hybrid}}
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Binary/Binary_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/Binary/Binary_AnmerkungenZuDenMustSupportFeldern.md
deleted file mode 100644
index fb2e1efe..00000000
--- a/ImplementationGuide/markdown/Binary/Binary_AnmerkungenZuDenMustSupportFeldern.md
+++ /dev/null
@@ -1,11 +0,0 @@
-### Anmerkungen zu den Must-Support Feldern
-
-### `Binary.contentType`
-
-**Bedeutung:** MimeType der Binärdaten
-
-### `Binary.data`
-
-**Bedeutung:** Base64-codierte Binärdaten
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Binary/Binary_Beispiele.md b/ImplementationGuide/markdown/Binary/Binary_Beispiele.md
deleted file mode 100644
index 375229f6..00000000
--- a/ImplementationGuide/markdown/Binary/Binary_Beispiele.md
+++ /dev/null
@@ -1,5 +0,0 @@
-### Beispiele
-
-{{json:Binary-JPEG-Example}}
-
-{{json:Binary-PDF-Example}}
diff --git a/ImplementationGuide/markdown/Binary/Binary_Interaktionen.md b/ImplementationGuide/markdown/Binary/Binary_Interaktionen.md
deleted file mode 100644
index e7e24bc6..00000000
--- a/ImplementationGuide/markdown/Binary/Binary_Interaktionen.md
+++ /dev/null
@@ -1,7 +0,0 @@
-### Interaktionen
-
-Für die Ressource Binary MUSS die REST-Interaktion "READ" implementiert werden. Es MÜSSEN die Regeln aus der FHIR-Kernspezifikation zur Abfrage einer Binary Ressource beachtet werden. Siehe ["Serving Binary Resources using the RESTful API"](https://www.hl7.org/fhir/R4/binary.html#rest).
-
-Um die Handhabung der base64-kodierten Binary-Ressourcen clientseitig zu erleichtern, MUSS ein bestätigungsrelevantes System (Server) bei READ-Interaktionen Accept-Header mit einem Wert außer den [FHIR-Mime-Types](https://www.hl7.org/fhir/R4/http.html#mime-type) unterstützen. Falls ein solcher Accept-Header durch einen Client verwendet wird, MUSS bestätigungsrelevante System (Server) das Binary in seiner nativen Form (definiert durch Binary.contentType) zurückgeben.
-
----
diff --git a/ImplementationGuide/markdown/Binary/Binary_Kompatibilitaet.md b/ImplementationGuide/markdown/Binary/Binary_Kompatibilitaet.md
deleted file mode 100644
index 1c98bb17..00000000
--- a/ImplementationGuide/markdown/Binary/Binary_Kompatibilitaet.md
+++ /dev/null
@@ -1,3 +0,0 @@
-### Kompatibilität
-
-Für das Profil ISiKBinary wurde bis zum Zeitpunkt der Veröffentlichung kein Abgleich der Kompatibilität zu anderen Profilen (der KBV und der Medizininformatik-Initiative) durchgeführt.
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Binary/Binary_Motivation.md b/ImplementationGuide/markdown/Binary/Binary_Motivation.md
deleted file mode 100644
index ebdabd58..00000000
--- a/ImplementationGuide/markdown/Binary/Binary_Motivation.md
+++ /dev/null
@@ -1,12 +0,0 @@
-### Motivation
-
-Die Binary-Ressource erlaubt den Umgang mit FHIR-fremden Formaten (z.B. PDFs, Bilder, CDA) innerhalb des FHIR-Frameworks.
-Dazu werden die Daten base64-codiert in der Binary-Ressource (in XML oder JSON) transportiert oder
-über die REST-API am Binary-Endpunkt in ihrem nativen Format bereitgestellt.
-Binary-Ressourcen werden von Attachment-Elementen verlinkt und damit in den Kontext anderer FHIR-Ressourcen
-(z.B. Patient und Encounter) gestellt.
-
-Das ISIK-Binary-Profil ist *nicht* Bestandteil der Implementierung und des Bestätigungsverfahrens zum ISIK Basismodul.
-Das Profil ist Teil des ISIK Basismoduls, da es als übergreifend genutzte Ressource sowohl im [Modul Terminplanung](https://simplifier.net/guide/isik-terminplanung-v4/ImplementationGuide-markdown-Datenobjekte?version=current) als auch im [Modul Dokumentenaustausch](https://simplifier.net/guide/isik-dokumentenaustausch-v4/ImplementationGuide-markdown-Datenobjekte?version=current) implementiert werden muss.
-
----
diff --git a/ImplementationGuide/markdown/Binary/Binary_Profil.md b/ImplementationGuide/markdown/Binary/Binary_Profil.md
deleted file mode 100644
index 5277f4db..00000000
--- a/ImplementationGuide/markdown/Binary/Binary_Profil.md
+++ /dev/null
@@ -1,9 +0,0 @@
-### Profil
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKBinary' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKBinary, hybrid}}
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/CapabilityStatement.md b/ImplementationGuide/markdown/CapabilityStatement.md
deleted file mode 100644
index 364046ab..00000000
--- a/ImplementationGuide/markdown/CapabilityStatement.md
+++ /dev/null
@@ -1,23 +0,0 @@
-## Konformitätserklärung [(CapabilityStatement)](https://hl7.org/fhir/R4/capabilitystatement.html)
-
-Jede Instanz eines bestätigungsrelevanten Systems MUSS an ihrem Endpunkt eine [CapabilityStatement](https://hl7.org/fhir/R4/capabilitystatement.html)-Ressource bereitstellen.
-
-Hierzu MUSS die [capabilities-Interaktion gemäß FHIR-Spezifikation](https://hl7.org/fhir/R4/http.html#capabilities) unterstützt werden.
-Der MODE-Parameter kann ignoriert werden.
-
-Das CapabilityStatement in dieser Spezifikation stellt die Anforderungen seitens der gematik dar (`kind` = "requirements"). Zur Unterscheidung von Anforderungen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die [CapabilityStatement-Expectation](https://hl7.org/fhir/R4/extension-capabilitystatement-expectation.html)-Extension mit den möglichen Werten "SHALL" (=MUSS) und "MAY" (=KANN) verwendet.
-
-Eine Server-Instanz MUSS ihrerseits ein CapabilityStatement vom `kind`= "instance" liefern und im Element `software` den Namen und die Versionsnummer angeben.
-Darüber hinaus MUSS in `CapabilityStatement.instantiates` die Canonical URL des nachfolgenden CapabilityStatement in der jeweiligen CapabilityStatement Instanz angegeben werden.
-
-Das CapabilityStatement der Instanz MUSS alle Funktionalitäten auflisten, die im folgenden CapabilityStatement mit "SHALL" gekennzeichnet sind. Das CapabilityStatement KANN darüber hinaus die mit "MAY" gekennzeichneten Funktionalitäten, sowie weitere Funktionalitäten auflisten, sofern diese in der Instanz implementiert wurden.
-
-Die Verwendung der [CapabilityStatement-Expectation](https://hl7.org/fhir/R4/extension-capabilitystatement-expectation.html)-Extension ist im CapabilityStatement der Server-Instanz nicht erforderlich.
-
-## CapabilityStatement (Requirement) ISiK
-
-Canonical: ```https://gematik.de/fhir/isik/CapabilityStatement/ISiKCapabilityStatementBasisServer```
-
-[Link Simplifier Profil Übersicht](https://gematik.de/fhir/isik/CapabilityStatement/ISiKCapabilityStatementBasisServer)
-
-{{render:https://gematik.de/fhir/isik/CapabilityStatement/ISiKCapabilityStatementBasisServer}}
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte.md
deleted file mode 100644
index ca0a1ab7..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte.md
+++ /dev/null
@@ -1,3 +0,0 @@
-# Datenobjekte
-
-In den folgenden Unterkapiteln werden die ISiK-Datenobjekte und ihre FHIR-Spezifikation beschrieben.
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Abrechnungsfall.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Abrechnungsfall.md
deleted file mode 100644
index 5a6923d2..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Abrechnungsfall.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Abrechnungsfall [(Account)](https://hl7.org/fhir/R4/account.html)
-
----
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_AllergieUnvertraeglichkeit.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_AllergieUnvertraeglichkeit.md
deleted file mode 100644
index a8d6d731..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_AllergieUnvertraeglichkeit.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Allergie/Unverträglichkeit [(AllergyIntolerance)](https://hl7.org/fhir/R4/allergyintolerance.html)
-
----
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Angehoeriger.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Angehoeriger.md
deleted file mode 100644
index 0e3134bd..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Angehoeriger.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Angehöriger [(RelatedPerson)](https://hl7.org/fhir/R4/relatedperson.html)
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_BerichtSubsystem.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_BerichtSubsystem.md
deleted file mode 100644
index 6fc0e5aa..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_BerichtSubsystem.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Bericht aus Subsystemen [(Composition)](https://hl7.org/fhir/R4/composition.html)
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Binary.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Binary.md
deleted file mode 100644
index 6ff591a2..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Binary.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Binary [(Binary)](https://hl7.org/fhir/R4/binary.html)
-
----
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_CodeSystem.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_CodeSystem.md
deleted file mode 100644
index 0776ee2f..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_CodeSystem.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Katalog [(CodeSystem)](https://hl7.org/fhir/R4/codesystem.html)
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Diagnose.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Diagnose.md
deleted file mode 100644
index 3af33291..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Diagnose.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Diagnose [(Condition)](https://hl7.org/fhir/R4/condition.html)
-
----
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Kontakt.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Kontakt.md
deleted file mode 100644
index 11fb42dc..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Kontakt.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Kontakt/Fall [(Encounter)](https://hl7.org/fhir/R4/encounter.html)
-
----
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Lebenszustand.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Lebenszustand.md
deleted file mode 100644
index b756f662..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Lebenszustand.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Spezifische Lebenszustände [(Observation)](https://hl7.org/fhir/R4/observation.html)
-
----
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Observation.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Observation.md
deleted file mode 100644
index ef038dbb..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Observation.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Observation [(Observation)](https://hl7.org/fhir/R4/observation.html)
-
----
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Organisation.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Organisation.md
deleted file mode 100644
index 08f68d5e..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Organisation.md
+++ /dev/null
@@ -1,5 +0,0 @@
-## Organisation [(Organization)](https://hl7.org/fhir/R4/organization.html)
-
-Die nachfolgenden Festlegungen spezifizieren die Abbildung von Minimalanforderungen für die Bereitstellung von Daten zur Aufbauorganisation im Rahmen von ISiK.
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Patient.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Patient.md
deleted file mode 100644
index dce283c8..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Patient.md
+++ /dev/null
@@ -1,5 +0,0 @@
-## Patient [(Patient)](https://hl7.org/fhir/R4/patient.html)
-
-Die nachfolgenden Festlegungen spezifizieren die Abbildung von Minimalanforderungen für die Bereitstellung von administrativen Patientendaten im Rahmen des Bestätigungsverfahrens der gematik.
-
----
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_PersonImGesundheitsberuf.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_PersonImGesundheitsberuf.md
deleted file mode 100644
index 301b4599..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_PersonImGesundheitsberuf.md
+++ /dev/null
@@ -1,4 +0,0 @@
-## PersonImGesundheitsberuf [(Practitioner)](https://hl7.org/fhir/R4/practitioner.html)
-
----
-
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Prozedur.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Prozedur.md
deleted file mode 100644
index 96bc25b7..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Prozedur.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Prozedur [(Procedure)](https://hl7.org/fhir/R4/procedure.html)
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Standort.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Standort.md
deleted file mode 100644
index e86419bb..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Standort.md
+++ /dev/null
@@ -1,5 +0,0 @@
-## Standort [(Location)](https://hl7.org/fhir/R4/location.html)
-
-Die nachfolgenden Festlegungen spezifizieren die Abbildung von Minimalanforderungen für die Bereitstellung von Standortdaten im Rahmen von ISiK.
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Subscription.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Subscription.md
deleted file mode 100644
index df6721c6..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Subscription.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Subscription patient-merge [(R5 Backport Subscription)](https://hl7.org/fhir/uv/subscriptions-backport/components.html)
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_ValueSet.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_ValueSet.md
deleted file mode 100644
index be3423c6..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_ValueSet.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## ValueSet [(ValueSet)](https://hl7.org/fhir/R4/valueset.html)
-
----
diff --git a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Versicherungsverhaeltnis.md b/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Versicherungsverhaeltnis.md
deleted file mode 100644
index 87ae4868..00000000
--- a/ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Versicherungsverhaeltnis.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Versicherungsverhältnis [(Coverage)](https://hl7.org/fhir/R4/coverage.html)
-
----
diff --git a/ImplementationGuide/markdown/DecisionLog.md b/ImplementationGuide/markdown/DecisionLog.md
deleted file mode 100644
index 3cfd3c33..00000000
--- a/ImplementationGuide/markdown/DecisionLog.md
+++ /dev/null
@@ -1,62 +0,0 @@
-# Decision Log
-
-
-7.6.2024
-* Problem: Die Übergreifende Definition der Suchparameter ist problematisch, da nur im Kontext des Tests definiert
-* Lösung: Anpassung der Definition in Bezug auf bestätigungsrelevantes System. Inklusive Vorgabe zu spezifischen MS-Definitionen . Weitere Klärung in Bezug auf Testszenarien mit Erläuterung zu: 1) Implikationen für MS-Flags, 2) Nutzung von data-absent-reason. Die Data-Absent-Reason soll nicht allgemein genutzt werden können, um Testfällen aufzuweichen.
-
-18.03.2024
-* Problem: Auswahl der Suchparameter für Organisation und Standort
-*Lösung: Die Suchparameter Liste wurde geprüft in Hinblick auf naheligende Suchabfragen rund um Organisation und Standort (Location). In Bezug auf Standort wurden vorerst nicht berücksichtigt die Suchparameter: "endpoint", konkrete "address"-Paramter - z.B. address-city etc. -, "mode" und "name"
-
-11.3.2024
-* Problem: Zum Kontext des Problems rund um spezifische Profile für Versicherten-IDs für GKV und PKV siehe https://chat.fhir.org/#narrow/stream/179183-german-.28d-a-ch.29/topic/Community-Feedback.20zum.20PKV-Identifier (bzw. PTData-718)
-VersichertenId-GKV
-* Lösung: siehe https://github.com/gematik/spec-ISiK-Basismodul/pull/382
-
-
-Datum 27.02.2024
-* Problem: Die MUSS-Anforderungen im Kontext von ISIKKatalog scheinen zu umfassend zu sein.
-* Lösung: Schwächung der Anforderungen für das Profil als ganzes:
- * Ressource ISIKKatalog als optional kennzeichnen (im Capability Statement). Alle anderen Suchparameter entfernen - genauso für IG. Nur für diese bleiben Test-Cases (optional) erhalten.
- * Nur die Suchparameter "_id" Und "url" sind MUSS-Anforderungen (auch nur, wenn die Ressource optional unterstützt wird), da ein bekanntes Codesystem abrufbar sein sollte, wenn die Ressource an sich unterstützt wird.
- *Anmerkungen und MUST-SUpport Felder bleiben unberührt (SOLL).
-
-----
-Version Technical Correction 3.0.4
-
-* Problem: In der [Extension Abrechnungsart](http://fhir.de/StructureDefinition/ExtensionAbrechnungsDiagnoseProzedur) ist eine eindeutige Zuweisung zwischen Use und Referenz nicht möglich aufgrund der Kardinalität von Use - (vergleiche ANFISK-206)
- * Option zur Lösung:
- * Die Extension sollte in ISiK auf 0..* gesetzt werden
- * In den Basisprofilen sollte die Extension angepasst werden, sodass Use auf 0..1 gesetzt wird
- * ggf. erneute Prüfung der Codes unter "Use" prüfen
-
-
-----
-Version: Technical Correction 3.0.2
-
-Datum: 11.12.2023
-
-* Problem: Das Datenobjekt RelatedPerson sollte einen optionalen Suchparameter enthalten für .address, da das Element ein MS-Flag besitzt.
- * Option A: Hinzufügen optionaler Suchparameter für die UCs:
- * Suchabfragen von Angehörigen mit Hilfe der Adresse
- * Suchabfragen von Angehörigen mit Hilfe der Adresse unter Angabe der Stadt
- * Suchabfragen von Angehörigen mit Hilfe der Adresse unter Angabe des Ländercodes
- * Suchabfragen von Angehörigen mit Hilfe der Adresse unter Angabe der Postleihzahl
- * Option B (ggf. mit Nennung der Risiken): Keine Änderung.
- * Risiko: könnte ggf. zu Abweichung bei den oben gelisteten Abfragen führen, bei Implementierung abweichender Custom-Suchparameter.
- * Entscheidung: Option A - umgesetzt hier: Add new optional SearchParameter for RelatedPerson.address - https://github.com/gematik/spec-ISiK-Basismodul/pull/345/commits/beca71aaae70538f52f934a072928e93d23fd6fd
-
- ----
-
-Version: 3.0.1
-
-Datum: 05.12.2023
-
-* Problem: SNOMED Code (103693007|Diagnostic procedure) zur Codierung einer Prozeduren-Kategorie wurde zurückgezogen.
- * Option A (ggf. mit Nennung der Risiken): Der obsolete Code wird ersetzt (165197003|Diagnostic assessment), um zu verhindern, dass Terminologieserver diesen nicht verarbeiten können.
- * Risiko: Ein Breaking Change wird eingeführt.
- * Option B (ggf. mit Nennung der Risiken): Der obsolete Code wird nicht angepasst, um einen Breaking Change zu vermeiden, mit dem Risiko, dass Terminologieserver diesen nicht verarbeiten können.
- * Entscheidung: Option A - umgesetzt hier: obsoleter SNOMED Code ersetzt: https://github.com/gematik/spec-ISiK-Basismodul/pull/322/commits/d72f3a08a41b999074b4f33db299d5d71cd04be9
-
-
diff --git a/ImplementationGuide/markdown/Diagnose/Diagnose_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/Diagnose/Diagnose_AnmerkungenZuDenMustSupportFeldern.md
deleted file mode 100644
index 387999f6..00000000
--- a/ImplementationGuide/markdown/Diagnose/Diagnose_AnmerkungenZuDenMustSupportFeldern.md
+++ /dev/null
@@ -1,67 +0,0 @@
-### Anmerkungen zu den Must-Support-Feldern
-
-### `Condition.clinicalStatus`
-
-**Bedeutung:** Der kodierte klinische Status der Diagnose MUSS, sofern vorhanden, angegeben werden, da die Interpretation der Diagnose davon abhängt ob diese 'aktiv' ist oder einen anderen Status aufweist. Alle in einem System möglichen Clinical-Status-Werte MÜSSEN, sofern vorhanden, über FHIR korrekt repräsentiert werden, können mindestens jedoch die Status-Werte "active" und "inactive" unterstützen.
-
-**Hinweise:**
-
-[FHIRPath Constraints seitens der FHIR-Kernspezifikation](https://www.hl7.org/fhir/R4/condition.html#invs) rund um Condition.clinicalStatus sind zu beachten.
-
-### `Condition.code.coding`
-
-**Bedeutung:** Kodierte Diagnose. Die Kodierung KANN nach den Vorgaben des BfArM per [ICD-10GM](https://www.bfarm.de/DE/Kodiersysteme/Klassifikationen/ICD/ICD-10-GM/_node.html) kodiert werden. Weiterhin sind folgende Kodiersysteme u.a. auf Basis von Empfehlungen des BfArM zulässig:
- - [SNOMED CT](https://www.snomed.org)
- - [Alpha-ID](https://www.bfarm.de/DE/Kodiersysteme/Terminologien/Alpha-ID-SE/_node.html)
- - [Orpha-Kennnummer](https://www.orpha.net/consor/cgi-bin/index.php?lng=DE)
-
-### `Condition.code.text`
-
-**Bedeutung:** Freitextdiagnose
-
-**Hinweise:**
-
-Die Freitextdiagnose darf nur alleinstehend angegeben werden, solange keine kodierte Diagnose vorliegt.
-
-### `Condition.code.coding:ICD-10-GM.extension:Seitenlokalisation`
-
-**Hinweise:** Angaben zur ICD-Seitenlokalisation ("R", "L", "B") müssen vom Code abgetrennt und in der Extension angegeben werden.
-
-### `Condition.code.coding:ICD-10-GM.extension:Mehrfachcodierungs-Kennzeichen`
-
-**Hinweise:** ICD-Mehfachcodierungs-Kennzeichen ("†", "\*", "!") müssen vom Code abgetrennt und in der Extension angegeben werden.
-
-### `Condition.code.coding:ICD-10-GM.extension:Diagnosesicherheit`
-
-**Hinweise:** Angaben zur ICD-Diagnosesicherheit ("A", "G", "V", "Z") müssen vom Code abgetrennt und in der Extension angegeben werden.
-
-### `Condition.subject`
-
-**Bedeutung:** Ein Patientenbezug der Diagnose MUSS stets zum Zwecke der Nachvollziehbarkeit und Datenintegrität vorliegen.
-
-### `Condition.encounter`
-
-**Bedeutung:** Der Fallbezug einer Diagnose MUSS stets zum Zwecke der Nachvollziehbarkeit und Datenintegrität vorliegen.
-
-**Hinweise:**
-
-Eine Verlinkung der Referenz auf den dazugehörigen Kontakt MUSS auf die Ebene des Abteilungskontaktes (entsprechend ISiKKontaktGesundheitseinrichtung) erfolgen.
-Bei der Auswahl des Kontaktes ist zu beachten, dass mehrere Encounter-Ressourcen mit identischen Aufnahmenummer-Identifiern existieren können (Abbildung Vor- und nachstationäre Kontakte).
-
-### `Condition.recordedDate`
-
-**Bedeutung:** Das Dokumentationsdatum der Diagnose MUSS zu Qualitätssicherungszwecken angegeben werden. Dies ist das fachliche Dokumentationsdatum, nicht zu verwechseln mit der technischen Anlage des Datensatzes im Primärsystem. Diese beiden Daten können jedoch identisch sein.
-
-**Hinweise:**
-
-Das Recorded Date MUSS mindestens auf den Monat genau angegeben werden (vgl. FHIRPath Constraint rec-1)
-
-### `Condition.note`
-
-**Bedeutung:** Weitere optionale Freitext-Notizen bezogen auf die Diagnose.
-
-### `Condition.extension:ReferenzPrimaerdiagnose`
-
-**Bedeutung:** Bei mehrfachkodierten ICD-Diagnosen (z.B. Kreuz-Stern-Notation) muss die Sekundär- auf die Primärdiagnose verlinkt werden
-
----
diff --git a/ImplementationGuide/markdown/Diagnose/Diagnose_Beispiele.md b/ImplementationGuide/markdown/Diagnose/Diagnose_Beispiele.md
deleted file mode 100644
index cf1694f7..00000000
--- a/ImplementationGuide/markdown/Diagnose/Diagnose_Beispiele.md
+++ /dev/null
@@ -1,5 +0,0 @@
-### Beispiel
-
-Valides Minimalbeispiel Diagnose:
-
-{{json:example-condition-kreuz-stern-primaer}}
diff --git a/ImplementationGuide/markdown/Diagnose/Diagnose_Interaktionen.md b/ImplementationGuide/markdown/Diagnose/Diagnose_Interaktionen.md
deleted file mode 100644
index 61376a0b..00000000
--- a/ImplementationGuide/markdown/Diagnose/Diagnose_Interaktionen.md
+++ /dev/null
@@ -1,77 +0,0 @@
-### Interaktionen
-
-Für die Ressource Condition MUSS die REST-Interaktion "READ" implementiert werden.
-
-Folgende Suchparameter sind für das Bestätigungsverfahren relevant, auch in Kombination:
-
-1. Der Suchparameter "_id" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Condition?_id=test```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "_id" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Parameters for all resources"](https://hl7.org/fhir/R4/search.html#all).
-
-1. Der Suchparameter "clinical-status" MUSS, sofern das Element unterstützt wird (siehe in der Profilstruktur Festlegung zu bedingtem MS), unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Condition?clincial-status=active```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Condition.clinicalStatus" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
- Dieser Suchparameter ist für die Umsetzung des IHE QEDm Profils verpflichtend.
-
-1. Der Suchparameter "patient" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Condition?patient=Patient/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Condition.subject" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
- Dieser Suchparameter ist für die Umsetzung des IHE QEDm Profils verpflichtend.
-
-1. Der Suchparameter "subject" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Condition?subject=Patient/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Condition.subject" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-1. Der Suchparameter "encounter" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Condition?encounter=Patient/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Condition.encounter" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-1. Der Suchparameter "recorded-date" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Condition?recorded-date=2015-01-01T12:00:23Z+02:00```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Condition.recordedDate" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Date Search"](https://hl7.org/fhir/R4/search.html#date).
-
-1. Der custom Suchparameter "related" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Condition?related=Condition/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Condition.related" finden sich im [Leitfaden Basis DE (R4) - Abschnitt "Diagnosen (Condition) - Doppel-/Mehrfachkodierte ICD-Codes"](https://ig.fhir.de/basisprofile-de/1.2.0/Ressourcen-DiagnosenCondition.html).
-
-1. Der Suchparameter "category" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Condition?category=http://hl7.org/fhir/ValueSet/condition-category|problem-list-item```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "category" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
- Dieser Suchparameter ist für die Umsetzung des IHE QEDm Profils verpflichtend.
-
----
diff --git a/ImplementationGuide/markdown/Diagnose/Diagnose_Kompatibilitaet.md b/ImplementationGuide/markdown/Diagnose/Diagnose_Kompatibilitaet.md
deleted file mode 100644
index ea07d9a2..00000000
--- a/ImplementationGuide/markdown/Diagnose/Diagnose_Kompatibilitaet.md
+++ /dev/null
@@ -1,9 +0,0 @@
-### Kompatibilität
-
-
-Für das Profil ISiKDiagnose wird eine Kompatibilität mit folgenden Profilen angestrebt; allerdings kann nicht sichergestellt werden, dass Instanzen, die gegen ISiKDiagnose valide sind, auch valide sind gegen:
-* [das Profil ProfileConditionDiagnose der Medizininformatik-Initative](https://www.medizininformatik-initiative.de/fhir/core/modul-diagnose/StructureDefinition/Diagnose)
-* [das Profil KBV_PR_Base_Condition_Diagnosis der KBV](https://fhir.kbv.de/StructureDefinition/KBV_PR_Base_Condition_Diagnosis)
-
-Hinweise zu Inkompatibilitäten können über die [Portalseite](https://service.gematik.de/servicedesk/customer/portal/16) gemeldet werden.
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Diagnose/Diagnose_Motivation.md b/ImplementationGuide/markdown/Diagnose/Diagnose_Motivation.md
deleted file mode 100644
index e21b7a18..00000000
--- a/ImplementationGuide/markdown/Diagnose/Diagnose_Motivation.md
+++ /dev/null
@@ -1,10 +0,0 @@
-### Motivation
-
-Die Möglichkeit, auf eine Übersicht der Diagnosen eines Patienten zuzugreifen, Patienten anhand ihrer Diagnose zu suchen oder zu prüfen, ob eine konkrete Diagnose bei einem Patienten vorliegt, sind wichtige Funktionen im klinischen Behandlungsablauf.
-
-In FHIR werden Diagnosen mit der [Condition](https://hl7.org/fhir/R4/condition.html)-Ressource repräsentiert.
-
-Da die Diagnosen in klinischen Primärsystemen in der Regel in ICD-10-codierter Form vorliegen, fordert ISiK in erster Linie diese Form des Austausches.
-Falls eine Diagnose zwar dokumentiert, aber noch nicht codiert wurde (z.B. wenn die Kodierung erst nach der Entlassung erfolgt), ist alternativ eine Repräsentation als Freitext-Diagnose möglich.
-
----
diff --git a/ImplementationGuide/markdown/Diagnose/Diagnose_Profil.md b/ImplementationGuide/markdown/Diagnose/Diagnose_Profil.md
deleted file mode 100644
index 0fa2e7a3..00000000
--- a/ImplementationGuide/markdown/Diagnose/Diagnose_Profil.md
+++ /dev/null
@@ -1,35 +0,0 @@
-### Profil
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKDiagnose' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKDiagnose, hybrid}}
-
----
-
-**Constraints**
-
-Folgende FHIRPath-Constraints sind im Profil zu beachten:
-
-@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKDiagnose' for differential.element.constraint select key, severity, human, expression```
-
----
-
-**Terminology Bindings**
-
-@```
-from StructureDefinition
-where url in ('https://gematik.de/fhir/isik/StructureDefinition/ISiKDiagnose' )
-for differential.element
-select
-Path: path,
-join binding.where(valueSet.exists())
-{
- Name: valueSet.substring((9 + valueSet.indexOf('ValueSet/'))),
- Strength: strength,
- URL: valueSet
-}
-```
-
----
diff --git a/ImplementationGuide/markdown/Einfuehrung.md b/ImplementationGuide/markdown/Einfuehrung.md
deleted file mode 100644
index 745ac5c9..00000000
--- a/ImplementationGuide/markdown/Einfuehrung.md
+++ /dev/null
@@ -1,47 +0,0 @@
-
-
-----
-Version: 4.0.1
-
-Datum: 21.11.2024
-
-Status: Active
-
-Realm: Deutschland
-
-
-
-Abgekündigte Versionen oder Zwischenveröffentlichungen der Implementierungsleitfäden finden Sie unter: https://gematik.github.io/spec-ISiK-Basismodul/index.html
-
-
-----
-
-
-# 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/ImplementationGuide/markdown/Katalog/CodeSystem_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/Katalog/CodeSystem_AnmerkungenZuDenMustSupportFeldern.md
deleted file mode 100644
index d1ead5b0..00000000
--- a/ImplementationGuide/markdown/Katalog/CodeSystem_AnmerkungenZuDenMustSupportFeldern.md
+++ /dev/null
@@ -1,39 +0,0 @@
-### Anmerkungen zu Must-Support-Feldern
-
-### `CodeSystem.url`
-
-**Bedeutung:** Eindeutige Url zur Identifizierung des CodeSystems. Absolute Url sind zu bevorzugen.
-
-**Hinweise:** OIDs SOLLTEN als weitere Identifier des CodeSystems verwendet werden. In jedem Fall SOLLTE ein Canonical Url vergeben werden.
-
-### `CodeSystem.version`
-
-**Bedeutung:** Version des CodeSystems
-
-**Hinweise:** Jede Änderung des CodeSystems MUSS eine Änderung in der Version des CodeSystems und gebundenen ValueSets nach sich ziehen. Die Versionierung SOLLTE auf Basis von [Semantic Versioning](https://semver.org) basieren.
-
-### `CodeSystem.name`
-
-**Bedeutung:** Maschinenlesbarer Name des CodeSystems
-
-**Hinweise:** Der Constraint [cps-0](https://www.hl7.org/fhir/R4/codesystem.html#invs) ist hierbei zu beachten.
-
-### `CodeSystem.status`
-
-**Bedeutung:** Indikation, ob das CodeSystem in aktiver Verwendung ist.
-
-**Hinweise:** Alle in einem System möglichen Status-Werte MÜSSEN über FHIR korrekt repräsentiert werden. KÖNNEN mindestens jedoch die Status-Werte "active" und "retired". Deren korrekte Abbildung wird im Rahmen des Bestätigungsverfahrens überprüft.
-
-### `CodeSystem.content`
-
-**Bedeutung:** Angabe, ob es sich um eine vollständige Repräsentation des CodeSystems oder nur um einen Auszug handelt.
-
-**Hinweise:** Alle in einem System möglichen Status-Werte müssen über FHIR korrekt repräsentiert werden können, mindestens jedoch die Status-Werte "fragment" und "complete". Deren korrekte Abbildung wird im Rahmen des Bestätigungsverfahrens überprüft.
-
-### `CodeSystem.concept`
-
-**Bedeutung:** Angabe der Konzepte, aus denen sich das CodeSystem zusammensetzt.
-
-**Hinweise:** Es MUSS mindestens ein Code und ein Anzeigetext spezifiziert werden.
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Katalog/CodeSystem_Beispiele.md b/ImplementationGuide/markdown/Katalog/CodeSystem_Beispiele.md
deleted file mode 100644
index be3c3a7a..00000000
--- a/ImplementationGuide/markdown/Katalog/CodeSystem_Beispiele.md
+++ /dev/null
@@ -1,5 +0,0 @@
-### Beispiele
-
-Valides Minimalbeispiel CodeSystem:
-
-{{json:CodeSystemExample}}
diff --git a/ImplementationGuide/markdown/Katalog/CodeSystem_Interaktionen.md b/ImplementationGuide/markdown/Katalog/CodeSystem_Interaktionen.md
deleted file mode 100644
index bec9df1b..00000000
--- a/ImplementationGuide/markdown/Katalog/CodeSystem_Interaktionen.md
+++ /dev/null
@@ -1,23 +0,0 @@
-### Interaktionen
-
-Für die Ressource CodeSystem MUSS die REST-Interaktion "READ" implementiert werden, falls die Resource CodeSystem umgesetzt wird.
-
-Folgende Suchparameter sind für das Bestätigungsverfahren relevant, auch in Kombination:
-
-1. Der Suchparameter "_id" MUSS unterstützt werden, falls die Resource CodeSystem umgesetzt wird:
-
- Beispiele:
-
- ```GET [base]/CodeSystem?_id=103270```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "_id" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Parameters for all resources"](https://hl7.org/fhir/R4/search.html#all).
-
-1. Der Suchparameter "url" MUSS unterstützt werden, falls die Resource CodeSystem umgesetzt wird:
-
- Beispiele:
-
- ```GET [base]/CodeSystem?url=http://example.org/fhir/CodeSystem/test```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "CodeSystem.url" finden sich in der [FHIR-Basisspezifikation - Abschnitt "uri"](https://www.hl7.org/fhir/R4/search.html#uri).
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Katalog/CodeSystem_Kompatibilitaet.md b/ImplementationGuide/markdown/Katalog/CodeSystem_Kompatibilitaet.md
deleted file mode 100644
index f76cfeaf..00000000
--- a/ImplementationGuide/markdown/Katalog/CodeSystem_Kompatibilitaet.md
+++ /dev/null
@@ -1,3 +0,0 @@
-### Kompatibilität
-
-Für das Profil ISiKCodeSystem wurde bis zum Zeitpunkt der Veröffentlichung kein Abgleich der Kompatibilität zu anderen Profilen (der KBV und der Medizininformatik-Initiative) durchgeführt.
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Katalog/CodeSystem_Motivation.md b/ImplementationGuide/markdown/Katalog/CodeSystem_Motivation.md
deleted file mode 100644
index 1eb43f44..00000000
--- a/ImplementationGuide/markdown/Katalog/CodeSystem_Motivation.md
+++ /dev/null
@@ -1,15 +0,0 @@
-### Motivation
-
-ISiK erlaubt in diversen Kontexten die Erweiterung der Kodierung durch Krankenhaus-/System-interne Kodierungen. Das Profil ISiKKatalog (CodeSystem) als Profil erlaubt die Repräsentation der dazugehörigen Codes und Display-Werte.
-
-Eine maschinenlesbare Repräsentation dieser Kodierungen erlaubt es Clients, dazugehörige Anzeigetext und Definitionen zu verarbeiten.
-
-Ein Codesystem eignet sich auch dazu, auf dessen Basis definierte [ValueSets zu expandieren](https://hl7.org/fhir/R4/valueset-operation-expand.html).
-Da ISiKValueSet expandierte Valuesets vorsieht, ist eine dynamische Expansion in der Regel nicht erforderlich.
-Darüber hinausgehend ist ein Use Case im Kontext der Katalogabfrage folgender: Ein Client möchte eine Expansion neu generieren (z.B. mit anderen Expansionen-Parametern), um das ValueSet beispielsweise in einer anderen Sprache auszugeben.
-
-### Normativer Status und Bestätigung
-
-Dieses Profil MUSS im Rahmen der Bestätigung NICHT unterstützt werden. Falls das Profil unterstützt werden soll, MÜSSEN die hier definierten Festlegungen greifen (auch im Bestätigungsverfahren).
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Katalog/CodeSystem_Profil.md b/ImplementationGuide/markdown/Katalog/CodeSystem_Profil.md
deleted file mode 100644
index c90560a2..00000000
--- a/ImplementationGuide/markdown/Katalog/CodeSystem_Profil.md
+++ /dev/null
@@ -1,8 +0,0 @@
-### FHIR-Profil
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKCodeSystem' select Name: name, Canonical: url
-```
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKCodeSystem, hybrid}}
-
----
diff --git a/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_AnmerkungenZuDenMustSupportFeldern.md
deleted file mode 100644
index 83aaaacb..00000000
--- a/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_AnmerkungenZuDenMustSupportFeldern.md
+++ /dev/null
@@ -1,37 +0,0 @@
-### Anmerkungen zu den Must-Support Feldern
-
-### `Encounter.status`
-
-**Bedeutung:** Der Status MUSS insbesondere zur Differenzierung von abgeschlossenen und derzeitig noch aktiven Kontakten angegeben werden. Alle in einem System möglichen Status-Werte müssen über FHIR korrekt repräsentiert werden. Es KÖNNEN jedoch mindestens die Status-Werte "in-progress", "finished" und "cancelled" unterstützt werden. Deren korrekte Abbildung wird im Rahmen des Bestätigungsverfahrens überprüft.
-
-**Hinweise:** Siehe Beschreibung in der [FHIR Kernspezifikation](https://hl7.org/fhir/R4/encounter-definitions.html#Encounter.status)
-
-### `Encounter.class`
-
-**Bedeutung:** Alle Encounter MÜSSEN eindeutig kategorisiert werden können, sodass eine Filterung pro Typ möglich ist.
-
-**Hinweise:** Verpflichtende Kodierung per [HL7 v3 Value Set ActEncounterCode](https://hl7.org/fhir/R4/v3/ActEncounterCode/vs.html), um eine internationale Kompatibilität aufrecht zu erhalten.
-
-### `Encounter.type`
-
-**Bedeutung:** Angabe vom Typ des Kontaktes. Alle Möglichkeiten eines Einrichtungskontaktes nach SGB V sind vorhanden.
-
-### `Encounter.subject`
-
-**Bedeutung:** Ein Patientenbezug des Falls MUSS stets zum Zwecke der Nachvollziehbarkeit und Datenintegrität vorliegen.
-
-### `Encounter.period`
-
-**Bedeutung:** Der Rahmen des Kontaktes MUSS zur zeitlichen Einordnung angeben werden.
-
-**Hinweise:** Es ist der FHIRPath Constraint ISiK-enc-1 zu beachten. Siehe [JSON Repräsentation FHIR Profil ISiK Encounter](https://simplifier.net/IsiK/ISiKKontaktGesundheitseinrichtung/~json).
-
-### `Encounter.location`
-
-**Bedeutung:** Falls Details zum Ort, an dem der Kontakt stattfindet, vorliegen, KÖNNEN diese in einer beliebigen Detailtiefe angegeben werden.
-
-### `Encounter.serviceProvider`
-
-**Bedeutung:** Falls Details zur verantwortlichen Organisationeinheit vorliegen, KÖNNEN diese in einer beliebigen Detailtiefe angegeben werden.
-
----
diff --git a/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Beispiele.md b/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Beispiele.md
deleted file mode 100644
index d78c921d..00000000
--- a/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Beispiele.md
+++ /dev/null
@@ -1,5 +0,0 @@
-#### Beispiele
-
-Ein Beispiel für das Profil ISiKKontaktGesundheitseinrichtung:
-
-{{json:Resources/fsh-generated/resources/Encounter-Fachabteilungskontakt.json}}
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Interaktionen.md b/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Interaktionen.md
deleted file mode 100644
index 7a031dcb..00000000
--- a/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Interaktionen.md
+++ /dev/null
@@ -1,118 +0,0 @@
-### Interaktionen
-
-Für die Ressource Encounter MUSS die REST-Interaktion "READ" implementiert werden.
-
-Folgende Suchparameter sind für das Bestätigungsverfahren relevant, auch in Kombination:
-
-1. Der Suchparameter "_id" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Encounter?_id=103270```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "_id" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Parameters for all resources"](https://hl7.org/fhir/R4/search.html#all).
-
-1. Der Suchparameter "identifier" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Encounter?identifier=http://test.krankenhaus.de/fhir/sid/fallnr|123456```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Encounter.identifier" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "status" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Encounter?status=finished```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Encounter.status" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "class" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Encounter?class=IMP```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Encounter.class" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "type" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Encounter?type=http://fhir.de/CodeSystem/kontaktart-de|stationaer```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Encounter.type" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "subject" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Encounter?subject=Patient/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Encounter.subject" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-1. Der Suchparameter "patient" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Encounter?patient=Patient/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Encounter.subject" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
- Dieser Suchparameter ist für die Umsetzung des IHE QEDm Profils verpflichtend.
-
-1. Der Suchparameter "account" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Encounter?account=Account/123```
-
- ```GET [base]/Encounter?account:identifier=https://example.org/fhir/sid/abrechnungsfallnr|123456```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Encounter.account" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-1. Der Suchparameter "date" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Encounter?date=eq2020-26-10```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Encounter.period" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Date Search"](https://hl7.org/fhir/R4/search.html#date). Bei der Formulierung der Suche sollten die Vorgaben aus der [Definition der Such-Prefixe](https://hl7.org/fhir/R4/search.html#prefix) - und hier insbesondere die Unterschiede zwischen "lt" und "eb" bzw. "gt" und "sa" - beachtet werden.
-
- Dieser Suchparameter ist für die Umsetzung des IHE QEDm Profils verpflichtend.
-
-1. Der Suchparameter "date-start" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Encounter?date-start=lt2020-26-10```
-
- Anwendungshinweise: Bei diesem custom Suchparameter handelt es sich um eine Lösung, die aus einer [abweichenden FHIR-Version (R5)](https://hl7.org/fhir/R5/encounter-search.html#Encounter-date-start) stammt. Weitere Informationen zur Suche nach "Encounter.period" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Date Search"](https://hl7.org/fhir/R4/search.html#date).
-
-1. Der Suchparameter "end-date" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Encounter?end-date=lt2020-26-10```
-
- Anwendungshinweise: Bei diesem custom Suchparameter handelt es sich um eine Lösung, die aus einer [abweichenden FHIR-Version (R5)](https://hl7.org/fhir/R5/SearchParameter/Encounter-end-date) stammt. Weitere Informationen zur Suche nach "Encounter.period" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Date Search"](https://hl7.org/fhir/R4/search.html#date).
-
-1. Der Suchparameter "location" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Encounter?location=Location/test```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Encounter.location" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-1. Der Suchparameter "service-provider" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Encounter?service-provider=Organization/test```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Encounter.serviceProvider" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
----
-
diff --git a/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Kompatibilitaet.md b/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Kompatibilitaet.md
deleted file mode 100644
index 549ee07c..00000000
--- a/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Kompatibilitaet.md
+++ /dev/null
@@ -1,8 +0,0 @@
-### Kompatibilität
-
-Für das Profil ISiKKontaktGesundheitseinrichtung wird eine Kompatibilität mit folgenden Profilen angestrebt; allerdings kann nicht sichergestellt werden, dass Instanzen, die gegen ISiKKontaktGesundheitseinrichtung valide sind, auch valide sind gegen:
-* [Profil Kontakt mit einer Gesundheitseinrichtung der Medizininformatik-Initiative](https://www.medizininformatik-initiative.de/fhir/core/modul-fall/StructureDefinition/KontaktGesundheitseinrichtung)
-
-Hinweise zu Inkompatibilitäten können über die [Portalseite](https://service.gematik.de/servicedesk/customer/portal/16) gemeldet werden..
-
----
diff --git a/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Motivation.md b/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Motivation.md
deleted file mode 100644
index 4fbfa8be..00000000
--- a/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Motivation.md
+++ /dev/null
@@ -1,85 +0,0 @@
-### Motivation
-
-Informationen über die Besuche des Patienten entlang seines Behandlungspfades im Krankenhaus sind ein wichtiger Bestandteil des einrichtungsinternen Datenaustausches.
-Sie ermöglichen die Unterscheidung von stationären und ambulanten sowie aufgenommenen und entlassenen Patienten.
-Weiterhin ist aus den Besuchsinformationen der aktuelle Aufenthaltsort des Patienten (Fachabteilung, Station, Bettplatz) ermittelbar.
-Klinische Ressourcen werden in FHIR durch Verlinkung auf die Encounter-Ressource in einen Kontext zum Besuch gestellt. Dieser Kontext ist wichtig für die Steuerung von Zugriffsberechtigungen und Abrechnungsprozessen.
-
-
-Zu Beginn der meisten klinischen Workflows steht die Auswahl des Besuchskontextes. Dies geschieht bspw. durch das Suchen der Encounter-Ressource anhand von Eigenschaften wie Aufnahmenummer, Fallart oder Aufnahmedatum. Daraufhin werden die zutreffenden Suchergebnisse angezeigt und der gewünschte Besuch ausgewählt.
-
----
-
-#### Der Begriff "Fall" im Kontext von FHIR
-
-Wichtig ist die Herausstellung, dass "Besuch" und "Fall" wechselseitig keine synonyme Begriffe sind.
-
-Der Begriff "Fall" gruppiert im Sprachgebrauch verschiedene Konzepte, die in FHIR durch unterschiedliche Ressourcen repräsentiert werden:
-
-* **Aufenthalt/Besuch/Kontakt (Encounter):**
-Der stationäre Aufenthalt oder der ambulante Kontakt eines Patienten in einer Gesundheitseinrichtung wird in FHIR durch die Ressource Encounter abgebildet.
-
-* **Abrechnungsfall (Account):**
-Der Fall, im Sinne einer Gruppierung von medizinischen Leistungen, die in einem gemeinsamen Kontext abgerechnet werden, sind in FHIR durch die Ressource Account repräsentiert. Ein Abrechnungsfall kann mehrere Encounter umfassen (z.B. vorstationärer Besuch, stationärer Aufenthalt und nachstationäre Besuche)
-{{render:Material/Images/Encounter/Encounter-Modell-Abrechnung.png}}
-
-* **Medizinischer Fall (EpisodeOfCare):**
-Der medizinische Fall gruppiert Informationen, die im Kontext einer gemeinsamen (Dauer-)Diagnose stehen und wird in FHIR durch die EpisodeOfCare dargestellt.
-{{render:Material/Images/Encounter/Encounter-Modell-Medizinisch.png}}
-
----
-
-#### Der Begriff "Fall" im Kontext der Medizininformatik-Initiative
-In dem [von der Medizininformatik-Initiative zur Kontaktverfolgung (Infektionsketten) des Patienten entworfenen Modell](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide-backup/EinfachesAufbaumodell?version=current) wird der Encounter in drei verschiedenen Ebenen verwendet:
-
-* **Einrichtungskontakt:**
-Als Kontakt eines Patienten mit einer Einrichtung (z.B: Klinik) gruppiert mehrere Besuche bei einer Einrichtung als gemeinsamen Behandlungskontext.
-
-* **Abteilungskontakt:**
-Als Kontakt des Patienten mit einer Fachabteilung eines Krankenhauses (z.B. einer Ambulanz oder einer stationären Fachabteilung).
-
-* **Versorgungsstellenkontakt:**
-Als Kontakt des Patienten mit konkreten Servicestellen, wie z.B. Radiologie oder Endoskopie
-
-Zur Unterscheidung der verschiedenen Kontaktebenen wird in der MI-I eine Codierung in `Encounter.type` verwendet. Die Hierarchie der Encounter wird über die `Encounter.partOf`-Relation hergestellt. Ambulante Besuche werden in dem Modell derzeit noch nicht berücksichtigt.
-
-{{render:Material/Images/Encounter/Encounter-Modell-MII.png}}
-
----
-
-#### Der Begriff "Fall" im Kontext der ISiK-Spezifikation
-
-Für die derzeitige Ausbaustufe des ISiK Basismoduls werden alle zuvor genannten Sichtweise und Modelle berücksichtigt:
-
-{{render:Material/Images/Encounter/Encounter-Modelle.png}}
-
-Verpflichtend umzusetzen ist für die bestätigungsrelevanten Systeme der Account, im Sinne der Gruppierung einzelner Besuche, zu einem gemeinsamen (Abrechnungs-)Fall sowie der Encounter der Ebene "Abteilungskontakt" im Sinne des Modells der Medizininformatikinitiative.
-
-Herstellern steht es frei, weitere Ressourcen, wie zum Beispiel die EpisodeOfCare oder den Encounter, im Sinne des Einrichtungskontaktes bzw. des Versorgungsstellenkontaktes, zu implementieren.
-
-Wichtig sind dabei jedoch folgende Punkte zu beachten:
-
-* Encounter im ISiK-Kontext sind stets als "Abteilungskontakte", im Sinne der MI-I mit dem entsprechenden `Encounter.type`-Code, zu kennzeichnen.
-* Jegliche im ISiK-Basis-Modul, als auch in anderen ISiK-Modulen definierte Ressourcen, die über einen Encounter-Kontext verfügen, müssen auf einen ISiK-Encounter (Abteilungskontakt) referenzieren.
-{{render:Material/Images/Encounter/Encounter-Modell-ISiK.png}}
-
----
-
-#### Die Repräsentation der "Fall"-Nummer
-
-Die "Fall"-Nummer ist ein im Kontext der stationären Versorgung häufig verwendetes Vehikel, um (insbesondere in der HL7-V2-Kommunikation) mit einfachen Mitteln den Fallkontext medizinischer Dokumentationen herzustellen.
-
-In den meisten Fällen handelt es sich bei der "Fall"-Nummer um einen eindeutigen Identifier des Abrechnungsfalls.
-Im ISiK-Kontext ist die Fallnummer daher als Identifier des Accounts zu sehen und nicht geeignet, einen Encounter eindeutig zu identifizieren und damit den für FHIR-Ressourcen erforderlichen Encounter-Kontext zu etablieren.
-Es müssen zusätzliche Kriterien, wie z.B. Zeitraum(`Encounter.period`), Fallart (`Encounter.class`) oder Status (`Encounter.status`) berücksichtigt werden, um den korrekten Encounter zu finden.
-
-ISiK berücksichtigt jedoch die gängige Praxis, dass die Fallnummer als primäres Suchkriterium verwendet wird; auch von Systemen, die rein der medizinischen Versorgung dienen und keine Abrechnungsfunktionen implementieren.
-Um insbesondere Subsysteme von der Pflicht zu entbinden, die Account-Ressource zu implementieren, nur um Zugriff zur Fallnummer zu bekommen, ist das Mitführen des Account-Identifiers als logische Referenz auf den Account im Encounter verpflichtend. Die Fallnummer eines Encounters kann daher auch ohne Kenntnis des Accounts ermittelt werden.
-
-| Hinweis | Änderung gegenüber ISiK-Basis-Modul Stufe 1!|
-|---------|---------------------|
-| {{render:Material/Images/IG_Warning}} | Die Abbildung der Fallnummer als Identifier des Accounts ist abweichend von der im Basismodul Stufe 1 festgelegten Abbildung der Fallnummer als Identifier des Encounters. Diese Änderung ist erforderlich, da die Fallnummer nicht geeignet ist, einen Encounter eindeutig zu identifizieren. Der Encounter kann weiterhin einen von der Abrechnungsfallnummer unabhängigen Identifier enthalten (z.B. "Aufnahmenummer", Bewegungsnummer). Dieser identifiziert eineindeutig den jeweiligen Kontakt.|
-
-{{render:Material/Images/Encounter/Encounter-Modell-Fallnummer.png}}
-
----
diff --git a/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Profil.md b/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Profil.md
deleted file mode 100644
index 9ef05487..00000000
--- a/ImplementationGuide/markdown/KontaktGesundheitseinrichtung/Kontakt_Profil.md
+++ /dev/null
@@ -1,47 +0,0 @@
-### Profil
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKKontaktGesundheitseinrichtung' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKKontaktGesundheitseinrichtung, hybrid}}
-
-**Bei Abbildung von Versorgungsstellenkontakten**
-
-Es ist ein üblicher Fall, dass die Dauer eines Versorgungsstellenkontaktes die eines Abteilungskontaktes übersteigt. Ein Beispiel hierfür: Ein Patient bleibt im Bett (Versorgungsstellenkontakt), aber ein Fachabteilungswechsel geschieht, da die Diagnose über eine Fachabteilung (Onkologie) läuft, dann aber der Wechsel zur Fachabteilung Chirurgie (neuer Abteilungskontakt) notwendig wird.
-
-Für einen solchen Fall gilt:
-
-Im Falle eines Fachabteilungswechsels legt ein System einen neuen Abteilungskontakt an. Bestehende Versorgungsstellenkontakt SOLLEN nicht in ihrer Relation (.partOf) zum Abteilungskontakt modifiziert werden. Hingegen SOLL das System einen oder mehrere Versorgungsstellenkontakte erzeugen und mit dem neu angelegten Abteilungskontakt in Verbindung setzen.
-
-Hinweis: Ein Versorgungsstellenkontakt endet zugleich nicht notwendigerweise mit einem Fachabteilungswechsel.
-
----
-
-**Constraints**
-
-Folgende FHIRPath-Constraints sind im Profil zu beachten:
-
-@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKKontaktGesundheitseinrichtung' for differential.element.constraint select key, severity, human, expression```
-
-Weitere Hinweise zu den Abgrenzungen der Begrifflichkeiten Fall und Kontakt finden sie unter [Deutsche Basisprofile - Abschnitt Ambulanter/stationärer Fall / Kontakt (Encounter)](https://ig.fhir.de/basisprofile-de/1.2.0/Ressourcen-AmbulanterStationaererFall.html).
-
----
-
-**Terminology Bindings**
-
-@```
-from StructureDefinition
-where url in ('https://gematik.de/fhir/isik/StructureDefinition/ISiKKontaktGesundheitseinrichtung' )
-for differential.element
-select
-Path: path,
-join binding.where(valueSet.exists())
-{
- Name: valueSet.substring((9 + valueSet.indexOf('ValueSet/'))),
- Strength: strength,
- URL: valueSet
-}
-```
-
----
diff --git a/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_AnmerkungenZuDenMustSupportFeldern.md
deleted file mode 100644
index 8ae3ffbd..00000000
--- a/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_AnmerkungenZuDenMustSupportFeldern.md
+++ /dev/null
@@ -1,5 +0,0 @@
-### Anmerkungen zu den Must-Support-Feldern
-
-Es gelten die Festlegungen für {{pagelink:ImplementationGuide/markdown/Observation/Observation_AnmerkungenZuDenMustSupportFeldern.md, text:Observations}}.
-
----
diff --git a/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Beispiele.md b/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Beispiele.md
deleted file mode 100644
index d655c264..00000000
--- a/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Beispiele.md
+++ /dev/null
@@ -1,21 +0,0 @@
-### Beispiele
-
-Schwangerschaftsstatus:
-
-{{json:ISiKSchwangerschaftsstatusBeispiel}}
-
-Erwarteter Entbindungstermin:
-
-{{json:ISiKSchwangerschaftErwarteterEntbindungsterminBeispiel}}
-
-Alkoholabusus:
-
-{{json:ISiKAlkoholAbususBeispiel}}
-
-Raucherstatus:
-
-{{json:ISiKRaucherStatusBeispiel}}
-
-Stillstatus:
-
-{{json:ISiKStillstatusBeispiel}}
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Interaktionen.md b/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Interaktionen.md
deleted file mode 100644
index d2b1e96a..00000000
--- a/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Interaktionen.md
+++ /dev/null
@@ -1,5 +0,0 @@
-### Interaktionen
-
-Es gelten die Festlegungen für Observations: {{pagelink:ImplementationGuide/markdown/Observation/Observation_Interaktionen.md}}
-
----
diff --git a/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Kompatibilitaet.md b/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Kompatibilitaet.md
deleted file mode 100644
index 7ed37a1e..00000000
--- a/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Kompatibilitaet.md
+++ /dev/null
@@ -1,10 +0,0 @@
-### Kompatibilität
-
-Für Schwangerschaftsstatus & Erwarteter Geburtstermin wird eine Kompatibilität mit folgenden **IPS** Profilen angestrebt:
-* [IPS Resource Profile: Observation - Pregnancy: EDD](https://hl7.org/fhir/uv/ips/STU1.1/StructureDefinition-Observation-pregnancy-edd-uv-ips.html).
-* [IPS Resource Profile: Observation - Pregnancy: status](https://hl7.org/fhir/uv/ips/STU1.1/StructureDefinition-Observation-pregnancy-status-uv-ips.html)
-
-Hinweise zu Inkompatibilitäten können über die [Portalseite](https://service.gematik.de/servicedesk/customer/portal/16) gemeldet werden..
-
----
-
diff --git a/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Motivation.md b/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Motivation.md
deleted file mode 100644
index 403ca0b9..00000000
--- a/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Motivation.md
+++ /dev/null
@@ -1,10 +0,0 @@
-### Motivation
-
-Viele medizinischen Entscheidungen benötigen Informationen zu den Lebensumständen eines Patienten. Hierzu gehören eine aktuelle Schwangerschaft, Raucherstatus sowie der Alkoholabususstatus.
-Motivierender Use-Case zur Einführung dieser Profile ist die [Arzneitmitteltherapiesicherheit im Krankenhaus - AMTS](https://simplifier.net/guide/isik-medikation-v4/ImplementationGuide-markdown-UebergreifendeUseCases-AMTS).
-
-In FHIR werden Untersuchungen, bzw. Beobachtungen als [`Observation`](https://hl7.org/fhir/R4/observation.html)-Ressource repräsentiert.
-
-Die folgenden Profile vom Typ Observation sind spezifische Profile im oben genannten Sinn. Eine generische, ISiK-spezifische Observation wir beschrieben unter {{pagelink:ImplementationGuide/markdown/Datenobjekte/Datenobjekte_Observation.md, text:generische Observation}}.
-
----
diff --git a/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Profil.md b/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Profil.md
deleted file mode 100644
index e99d1220..00000000
--- a/ImplementationGuide/markdown/Lebenszustand/Lebenszustand_Profil.md
+++ /dev/null
@@ -1,183 +0,0 @@
-### Profil
-
-#### ISiKSchwangerschaftsstatus
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKSchwangerschaftsstatus' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKSchwangerschaftsstatus, hybrid}}
-
----
-
-**Constraints**
-
-Folgende FHIRPath-Constraints sind im Profil zu beachten:
-
-@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKSchwangerschaftsstatus' for differential.element.constraint select key, severity, human, expression```
-
----
-
-**Terminology Bindings**
-
-@```
-from StructureDefinition
-where url in ('https://gematik.de/fhir/isik/StructureDefinition/ISiKSchwangerschaftsstatus' )
-for differential.element
-select
-Path: path,
-join binding.where(valueSet.exists())
-{
- Name: valueSet.substring((9 + valueSet.indexOf('ValueSet/'))),
- Strength: strength,
- URL: valueSet
-}
-```
-
-----
-
-#### ISiKSchwangerschaftErwarteterEntbindungstermin
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKSchwangerschaftErwarteterEntbindungstermin' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKSchwangerschaftErwarteterEntbindungstermin, hybrid}}
-
----
-
-**Constraints**
-
-Folgende FHIRPath-Constraints sind im Profil zu beachten:
-
-@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKSchwangerschaftErwarteterEntbindungstermin' for differential.element.constraint select key, severity, human, expression```
-
----
-
-**Terminology Bindings**
-
-@```
-from StructureDefinition
-where url in ('https://gematik.de/fhir/isik/StructureDefinition/ISiKSchwangerschaftErwarteterEntbindungstermin' )
-for differential.element
-select
-Path: path,
-join binding.where(valueSet.exists())
-{
- Name: valueSet.substring((9 + valueSet.indexOf('ValueSet/'))),
- Strength: strength,
- URL: valueSet
-}
-```
-
-----
-
-
-#### ISiKAlkoholAbusus
-
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKAlkoholAbusus' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKAlkoholAbusus, hybrid}}
-
----
-
-**Constraints**
-
-Folgende FHIRPath-Constraints sind im Profil zu beachten:
-
-@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKAlkoholAbusus' for differential.element.constraint select key, severity, human, expression```
-
----
-
-**Terminology Bindings**
-
-@```
-from StructureDefinition
-where url in ('https://gematik.de/fhir/isik/StructureDefinition/ISiKAlkoholAbusus' )
-for differential.element
-select
-Path: path,
-join binding.where(valueSet.exists())
-{
- Name: valueSet.substring((9 + valueSet.indexOf('ValueSet/'))),
- Strength: strength,
- URL: valueSet
-}
-```
-
-
-----
-
-#### ISiKRaucherStatus
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKRaucherStatus' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKRaucherStatus, hybrid}}
-
----
-
-**Constraints**
-
-Folgende FHIRPath-Constraints sind im Profil zu beachten:
-
-@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKRaucherStatus' for differential.element.constraint select key, severity, human, expression```
-
----
-
-**Terminology Bindings**
-
-@```
-from StructureDefinition
-where url in ('https://gematik.de/fhir/isik/StructureDefinition/ISiKRaucherStatus' )
-for differential.element
-select
-Path: path,
-join binding.where(valueSet.exists())
-{
- Name: valueSet.substring((9 + valueSet.indexOf('ValueSet/'))),
- Strength: strength,
- URL: valueSet
-}
-```
-
-----
-
-#### ISiKStillstatus
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKStillstatus' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKStillstatus, hybrid}}
-
----
-
-**Constraints**
-
-Folgende FHIRPath-Constraints sind im Profil zu beachten:
-
-@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKStillstatus' for differential.element.constraint select key, severity, human, expression```
-
----
-
-**Terminology Bindings**
-
-@```
-from StructureDefinition
-where url in ('https://gematik.de/fhir/isik/StructureDefinition/ISiKStillstatus' )
-for differential.element
-select
-Path: path,
-join binding.where(valueSet.exists())
-{
- Name: valueSet.substring((9 + valueSet.indexOf('ValueSet/'))),
- Strength: strength,
- URL: valueSet
-}
-```
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Motivation.md b/ImplementationGuide/markdown/Motivation.md
deleted file mode 100644
index 16992e8d..00000000
--- a/ImplementationGuide/markdown/Motivation.md
+++ /dev/null
@@ -1,28 +0,0 @@
-# Motivation
-
-Die Landschaft informationstechnischer Systeme in Krankenhäusern ist enorm heterogen. Für die Patientenverwaltung und -abrechnung, die medizinische Dokumentation, die Laborverwaltung, die Blutbank bis hin zum Dokumentenarchiv werden verschiedene, auf das jeweilige Fachgebiet spezialisierte Systeme verwendet. Es besteht daher der Bedarf, diese Systeme über ihren Primärzweck hinaus sinnvoll zu integrieren. Ein Szenario ist beispielsweise die Abrechnung der im Krankenhaus erbrachten Leistungen. Aus den ursprünglich in verschiedenen Spezialsystemen erfassten Informationen werden die für die Abrechnung relevanten Informationen an ein Abrechnungssystem gesendet und dort zur Rechnungslegung weiterverarbeitet.
-
-Herausforderungen stellen dabei die Vielzahl der Schnittstellen von informationstechnischen Systemen im Krankenhaus sowie zusätzliche Anforderungen für die Nutzung in mobilen Anwendungen dar. Durch die Festlegung und Verwendung von offenen und standardisierten Schnittstellen können diese Herausforderungen effizienter angenommen werden.
-
-Im Folgenden leiten wir - die gematik GmbH - her, warum die bestehenden Integrationsansätze im Krankenhaus noch unzureichend sind und durch die im Bestätigungsverfahren „Interoperabler Datenaustausch durch Informationssysteme im Krankenhaus“ (ISiK) spezifizierten Ansätze ergänzt werden, um die Vielzahl sinnvoller Integrationsszenarien effizient abzudecken.
-
-## Reaktiver Datenaustausch im Krankenhaus
-
-Der aktuell in Krankenhäusern vorherrschende Integrationsansatz nach dem Standard HL7 Version 2 (HL7v2) sieht vor, dass fachdomänenspezifische Systeme Nachrichten versenden, sobald für andere Systeme interessante Ereignisse eintreten. Bei Anlegen einer Diagnose in einem System für medizinische Dokumentation wird beispielsweise eine entsprechende Nachricht versendet, die vom Abrechnungssystem konsumiert und in der Rechnungslegung berücksichtigt wird. Für diesen Ansatz ist es nötig, dass die konsumierenden Systeme direkt auf die für sie passenden Nachrichten reagieren können. Leider werden dieselben Inhalte in verschiedenen Krankenhäusern oft unterschiedlich in HL7v2-Nachrichten kodiert. Darum wird häufig ein Kommunikationsserver verwendet, der die krankenhausspezifischen Nachrichten in ein Format übersetzt, dass die konsumierenden Systeme verarbeiten können. Erst wenn diese Übersetzung der HL7v2 Nachrichten eingerichtet ist, können Daten zwischen den Systemen ausgetauscht werden.
-
-Daraus ergeben sich einige relevante Nachteile:
-
-1. Es ist nur eine im Voraus definierte Datenverarbeitung möglich. Es müssen Verarbeitungsregeln im Kommunikationsserver festgelegt werden, die empfangene HL7v2-Nachrichten zur Weiterverarbeitung in ein geeignetes Format überführen.
-2. Es können keine HL7v2-Nachrichten genutzt werden, die vor Aktivierung der Verarbeitungsregeln im Krankenhaus versandt wurden. Damit bleibt ein großer Teil der verfügbaren Daten des Krankenhauses ungenutzt.
-3. Gerade große Krankenhäuser müssen tausende dieser Verarbeitungsregeln verwalten. Dies erschwert den Überblick und nicht mehr benötigte Regeln belasten den Kommunikationsserver.
-
-Daher hat der Gesetzgeber im Patientendaten-Schutzgesetz (PDSG) der gematik den Auftrag erteilt, offene und standardisierte Schnittstellen zu spezifizieren, die über den reaktiven Datenaustausch hinaus einen bedarfsgerechten Datenaustausch ermöglichen. Die Einhaltung dieser Spezifikation wird in dem ISiK Bestätigungsverfahren geprüft. Die Beschreibung des Bestätigungsverfahrens ist nicht Inhalt dieses Implementierungsleitfadens und ist im Fachportal der gematik beschrieben (
-
-
-
diff --git a/ImplementationGuide/markdown/ValueSet/ValueSet_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/ValueSet/ValueSet_AnmerkungenZuDenMustSupportFeldern.md
deleted file mode 100644
index 15838a0f..00000000
--- a/ImplementationGuide/markdown/ValueSet/ValueSet_AnmerkungenZuDenMustSupportFeldern.md
+++ /dev/null
@@ -1,39 +0,0 @@
-### Anmerkungen zu Must-Support-Feldern
-
-### `ValueSet.url`
-
-**Bedeutung:** Eindeutige Url zur Identifizierung des ValueSets. Absolute Urls sind zu bevorzugen.
-
-**Hinweise:** OIDs SOLLTEN als weitere Identifier des CodeSystems verwendet werden. In jedem Fall SOLLTE eine Canonical Url vergeben werden.
-
-### `ValueSet.version`
-
-**Bedeutung:** Version des ValueSets
-
-**Hinweise:** Jede Änderung des dazugehörigen CodeSystems MUSS eine Änderung in der Version des CodeSystems und ValueSets nach sich ziehen.
-
-### `ValueSet.name`
-
-**Bedeutung:** Maschinenlesbarer Name des ValueSets
-
-**Hinweise:** Der Constraint [vsd-0](https://www.hl7.org/fhir/R4/valueset.html#invs) ist hierbei zu beachten.
-
-### `ValueSet.status`
-
-**Bedeutung:** Indikation, ob das ValueSet in aktiver Verwendung ist.
-
-**Hinweise:** Alle in einem System möglichen Status-Werte müssen über FHIR korrekt repräsentiert werden können, mindestens jedoch die Status-Werte "active" und "retired". Deren korrekte Abbildung wird im Rahmen des Bestätigungsverfahrens überprüft.
-
-### `ValueSet.useContext`
-
-**Bedeutung:** Angabe für welches Datenelement das ValueSet relevant ist
-
-**Hinweise:** Es muss mindestens ein useContext angegeben werden, in dem der Ressourcen-Typ kodiert wird, in dem das ValueSet in einem Element zur Verwendung kommt.
-
-### `ValueSet.expansion`
-
-**Bedeutung:** Angabe der Konzepte aus denen sich das ValueSet zusammensetzt.
-
-**Hinweise:** Mindestens MUSS ein Code und ein Anzeigetext spezifiziert werden.
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/ValueSet/ValueSet_Beispiele.md b/ImplementationGuide/markdown/ValueSet/ValueSet_Beispiele.md
deleted file mode 100644
index 240b2810..00000000
--- a/ImplementationGuide/markdown/ValueSet/ValueSet_Beispiele.md
+++ /dev/null
@@ -1,5 +0,0 @@
-### Beispiele
-
-Valides Minimalbeispiel Patient:
-
-{{json:isikvaluesetexample}}
diff --git a/ImplementationGuide/markdown/ValueSet/ValueSet_Interaktionen.md b/ImplementationGuide/markdown/ValueSet/ValueSet_Interaktionen.md
deleted file mode 100644
index a6c8a8ec..00000000
--- a/ImplementationGuide/markdown/ValueSet/ValueSet_Interaktionen.md
+++ /dev/null
@@ -1,67 +0,0 @@
-### Interaktionen
-
-Für die Ressource ValueSet MUSS die REST-Interaktion "READ" implementiert werden.
-
-Folgende Suchparameter sind für das Bestätigungsverfahren relevant, auch in Kombination:
-
-1. Der Suchparameter "_id" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/ValueSet?_id=103270```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "_id" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Parameters for all resources"](https://hl7.org/fhir/R4/search.html#all).
-
-1. Der Suchparameter "url" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/ValueSet?url=http://example.org/fhir/ValueSet/test```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "ValueSet.url" finden sich in der [FHIR-Basisspezifikation - Abschnitt "uri"](https://www.hl7.org/fhir/R4/search.html#uri).
-
-1. Der Suchparameter "name" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/ValueSet?name=TestValueSet```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "ValueSet.name" finden sich in der [FHIR-Basisspezifikation - Abschnitt "String Search"](https://hl7.org/fhir/R4/search.html#string).
-
-1. Der Suchparameter "status" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/ValueSet?status=active```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "ValueSet.status" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search""](https://hl7.org/fhir/R4/search.html#token).
-
-
-1. Der Suchparameter "version" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/ValueSet?version=1.0.0```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "ValueSet.version" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "context-type-value" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/ValueSet?context-type-value=http://terminology.hl7.org/CodeSystem/usage-context-type|focus$http://hl7.org/fhir/resource-types|Encounter```
-
-
- Mit dieser Abfrage können hausinterne Kataloge anhand des Ressource-Typs ermittelt werden. Diese Informationen sind u.a. relevant im Kontext von:
- - Hausinternen Prozeduren/Diagnosen-Codes
- - Kodierung von Encounter-Informationen (z.B. Wahlleistungen, Orttypen)
-
- Use Cases im Zusammenhang:
-
- (A) Zur Konfigurationszeit können passende ValueSets von einem Server spezifisch für einen Ressourcentyp abgerufen und vorbereitend auf eine Systemintegration begutachtet bzw. in Client-Systeme eingebunden werden. In diesem Sinne wird die Abfrage im Kontext der [Terminvereinbarung durch einen Termin-Requestor genutzt](https://simplifier.net/guide/isik-terminplanung-v4/ImplementationGuide-markdown-Datenobjekte-Operations?version=current).
-
- (B) Zur Laufzeit können spezifische ValueSets synchronisiert bzw. direkt in die Eingabemasken von Clients eingebunden werden.
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "CodeSystem.useContext" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Composite Search Parameters"](https://www.hl7.org/fhir/R4/search.html#composite).
-
----
diff --git a/ImplementationGuide/markdown/ValueSet/ValueSet_Kompatibilitaet.md b/ImplementationGuide/markdown/ValueSet/ValueSet_Kompatibilitaet.md
deleted file mode 100644
index a913d41a..00000000
--- a/ImplementationGuide/markdown/ValueSet/ValueSet_Kompatibilitaet.md
+++ /dev/null
@@ -1,3 +0,0 @@
-### Kompatibilität
-
-Für das Profil ISiKValueSet wurde bis zum Zeitpunkt der Veröffentlichung kein Abgleich der Kompatibilität zu anderen Profilen (der KBV und der Medizininformatik-Initiative) durchgeführt.
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/ValueSet/ValueSet_Motivation.md b/ImplementationGuide/markdown/ValueSet/ValueSet_Motivation.md
deleted file mode 100644
index 2a7c4b08..00000000
--- a/ImplementationGuide/markdown/ValueSet/ValueSet_Motivation.md
+++ /dev/null
@@ -1,6 +0,0 @@
-### Motivation
-
-ISiK erlaubt in diversen Kontexten die Erweiterung der Kodierung durch Krankenhaus- / System-interne Kodierungen.
-Mittels der Veröffentlichung von ValueSets können Auswahllisten für externe Clients bereitgestellt werden, sodass diese entsprechende Kodierungen ebenfalls anbieten können.
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/ValueSet/ValueSet_Profil.md b/ImplementationGuide/markdown/ValueSet/ValueSet_Profil.md
deleted file mode 100644
index 85e69fb1..00000000
--- a/ImplementationGuide/markdown/ValueSet/ValueSet_Profil.md
+++ /dev/null
@@ -1,8 +0,0 @@
-### FHIR-Profil
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKValueSet' select Name: name, Canonical: url
-```
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKValueSet, hybrid}}
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_AnmerkungenZuDenMustSupportFeldern.md
deleted file mode 100644
index 97d4b872..00000000
--- a/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_AnmerkungenZuDenMustSupportFeldern.md
+++ /dev/null
@@ -1,53 +0,0 @@
-### Anmerkungen zu den Must-Support Feldern
-
-#### Das Profil ISiKVersicherungsverhaeltnisGesetzlich
-
-### `Coverage.identifier`
-
-**Hinweise:** Grundsätzlich ist zu beachten, dass das Versicherungsverhältnis für die gesetzliche Versicherung durch die 30-stellige KVNR identifiziert wird. Die 10-stellige KVNR ist hingegen ein Identifier für das Datenobjekt Patient. Siehe {{pagelink:ImplementationGuide/markdown/Patient/Patient_Profil.md, text:Datenobjekt - Patient}}. Es wird in ISiK davon ausgegangen, dass die 30-stellige KVNR nicht in bestätigungrelevanten Systemen geführt wird, sodass diese nicht als zuverlässiger Identifier für das Versicherungsverhältnis verwendbar ist. Bei einer Suche nach einem Versicherungsverhältnis SOLLTE dieses per Chaining auf das Datenobjekt Patient ermittelt werden.
-
-### `Coverage.status`
-
-**Bedeutung:** Der Status einer Instanz des Profils ISiKVersicherungsverhaeltnisGesetzlich.
-
-**Hinweise:** Das Element status macht deutlich, ob diese Instanz genutzt werden kann oder ob sie bspw. als ungültig oder falsch gekennzeichnet ist, siehe [FHIR Kernspezifikaton](https://hl7.org/fhir/R4/coverage-definitions.html#Coverage.status).
-
-### `Coverage.type`
-
-**Bedeutung:** Das Element type kennzeichnet die Art der Versicherung.
-
-**Hinweise:** Kennzeichnung als gesetzliche Versicherung, siehe [Beschreibung der deutschen Basisprofile](https://fhir.de/CodeSystem/versicherungsart-de-basis).
-
-### `Coverage.beneficiary`
-
-**Bedeutung:** Das Element beneficiary benennt die versicherte Person, auf die sich die Kostenübernahme durch die Versicherung bezieht.
-
-**Hinweise:** Für ISiK MUSS beneficiary ein Patient nach dem Profil ISiKPatient sein.
-
-### `Coverage.payor`
-
-**Bedeutung:** Der Kostenträger des Versicherten.
-
-**Hinweise:** Der Kostenträger der gesetzlichen Versicherung wird durch ein Institutskennzeichen in Coverage.payor.identifier identifiziert.
-
----
-
-#### Das Profil ISiKVersicherungsverhaeltnisSelbstzahler
-
-### `Coverage.subscriber`
-
-**Bedeutung:** Der Inhaber der Versicherungspolice.
-
-**Hinweise:** Kann entweder der Patient selbst oder ein Hauptversicherter nach dem Profil ISiKHauptversicherter sein.
-
-### `Coverage.beneficiary`
-
-Siehe entsprechenden Eintrag zum Profil ISiKVersicherungsverhaeltnisGesetzlich oben.
-
-### `Coverage.payor`
-
-**Bedeutung:** Der Rechnungsempfänger.
-
-**Hinweise:** Der Rechnungsempfänger für Selbstzahler ist entweder der Patient selbst, Hauptversicherte oder eine andere Partei.
-
----
diff --git a/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Beispiele.md b/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Beispiele.md
deleted file mode 100644
index c311e02e..00000000
--- a/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Beispiele.md
+++ /dev/null
@@ -1,9 +0,0 @@
-### Beispiele
-
-Valides Minimalbeispiel für das Profil ISiKVersicherungsverhaeltnisGesetzlich:
-
-{{json:coverageGesetzlich}}
-
-Valides Minimalbeispiel für das Profil ISiKVersicherungsverhaeltnisSelbstzahler:
-
-{{json:coveragePrivat}}
diff --git a/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Interaktionen.md b/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Interaktionen.md
deleted file mode 100644
index 6281f544..00000000
--- a/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Interaktionen.md
+++ /dev/null
@@ -1,108 +0,0 @@
-### Interaktionen
-
-Für die Ressource Coverage MUSS die REST-Interaktion "READ" implementiert werden.
-
-Folgende Suchparameter sind für das Bestätigungsverfahren relevant, auch in Kombination:
-
-#### Profil ISiKVersicherungsverhaeltnisGesetzlich
-
-1. Der Suchparameter "_id" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Coverage?_id=103270```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "_id" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Parameters for all resources"](https://hl7.org/fhir/R4/search.html#all).
-
-
-3. Der Suchparameter "status" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Coverage?status=active```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Coverage.status" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-4. Der Suchparameter "type" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Coverage?type=http://fhir.de/CodeSystem/versicherungsart-de-basis|GKV```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Coverage.type" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-5. Der Suchparameter "beneficiary" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Coverage?beneficiary=Patient/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Coverage.beneficiary" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-6. Der Suchparameter "patient" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Coverage?patient=Patient/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Coverage.beneficiary" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-7. Der Suchparameter "payor" in Kombination mit einem identifier-Modifier MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Coverage?payor:identifier=0123456789```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Coverage.payor" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-#### Profil ISiKVersicherungsverhaeltnisSelbstzahler
-
-1. Der Suchparameter "_id" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Coverage?_id=103270```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "_id" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Parameters for all resources"](https://hl7.org/fhir/R4/search.html#all).
-
-1. Der Suchparameter "beneficiary" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Coverage?beneficiary=Patient/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Coverage.beneficiary" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-1. Der Suchparameter "payor" MUSS unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Coverage?payor=0123456789```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Coverage.payor" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-1. Der Suchparameter "subscriber" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Coverage?subscriber=Patient/123```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Coverage.subscriber" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Reference Search"](https://www.hl7.org/fhir/R4/search.html#reference).
-
-1. Der Suchparameter "status" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Coverage?status=active```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Coverage.status" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
-1. Der Suchparameter "type" KANN unterstützt werden:
-
- Beispiele:
-
- ```GET [base]/Coverage?type=http://fhir.de/CodeSystem/versicherungsart-de-basis|SEL```
-
- Anwendungshinweise: Weitere Informationen zur Suche nach "Coverage.type" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Token Search"](https://hl7.org/fhir/R4/search.html#token).
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Kompatibilitaet.md b/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Kompatibilitaet.md
deleted file mode 100644
index f970f415..00000000
--- a/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Kompatibilitaet.md
+++ /dev/null
@@ -1,19 +0,0 @@
-### Kompatibilität
-
-#### Profil ISiKVersicherungsverhaeltnisGesetzlich
-
-Das Profil ISiKVersicherungsverhaeltnisGesetzlich basiert auf dem Profil [Coverage der deutschen Basisprofile](http://fhir.de/StructureDefinition/coverage-de-basis).
-Instanzen, die gegen ISiKVersicherungsverhaeltnisGesetzlich valide sind, sind auch valide gegen
-* Profil ["Coverage, deutsches GKV Profil" der deutschen Basisprofile](https://fhir.de/StructureDefinition/coverage-de-gkv)
-
-Hinweise zu Inkompatibilitäten können über die [Portalseite](https://service.gematik.de/servicedesk/customer/portal/16) gemeldet werden..
-
-#### Profil ISiKVersicherungsverhaeltnisSelbstzahler
-
-Das Profil ISiKVersicherungsverhaeltnisSelbstzahler basiert auf dem Profil ["Coverage, deutsches Selbstzahlerprofil" der deutschen Basisprofile](https://fhir.de/StructureDefinition/coverage-de-sel).
-Instanzen, die gegen ISiKVersicherungsverhaeltnisSelbstzahler valide sind, sind auch valide gegen
-* Profil ["Coverage, deutsches Selbstzahlerprofil" der deutschen Basisprofile](https://fhir.de/StructureDefinition/coverage-de-sel)
-
-Hinweise zu Inkompatibilitäten können über die [Portalseite](https://service.gematik.de/servicedesk/customer/portal/16) gemeldet werden..
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Motivation.md b/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Motivation.md
deleted file mode 100644
index cd479ef1..00000000
--- a/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Motivation.md
+++ /dev/null
@@ -1,7 +0,0 @@
-### Motivation
-
-ISiK unterstützt Anwendungsszenarien, in denen durch das Krankenhaus erbrachte Leistungen erfasst oder gegenüber Kostenträgern abgerechnet werden. In diesen Anwendungsszenarien wird das Versicherungsverhältnis verwendet, um bspw. den Versicherungsstatus oder die Rechnungsanschrift der Versicherung zu ermitteln.
-
-In FHIR werden Versicherungsverhältnisse mit der [`Coverage`](https://hl7.org/fhir/R4/coverage.html)-Ressource repräsentiert.
-
----
\ No newline at end of file
diff --git a/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Profil.md b/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Profil.md
deleted file mode 100644
index eab2cd1c..00000000
--- a/ImplementationGuide/markdown/Versicherungsverhaeltnis/Versicherungsverhaeltnis_Profil.md
+++ /dev/null
@@ -1,21 +0,0 @@
-### Profil
-
-#### Profil ISiKVersicherungsverhaeltnisGesetzlich
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKVersicherungsverhaeltnisGesetzlich' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKVersicherungsverhaeltnisGesetzlich, hybrid}}
-
----
-
-#### Profil ISiKVersicherungsverhaeltnisSelbstzahler
-
-@```
-from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/ISiKVersicherungsverhaeltnisSelbstzahler' select Name: name, Canonical: url
-```
-
-{{tree:https://gematik.de/fhir/isik/StructureDefinition/ISiKVersicherungsverhaeltnisSelbstzahler, hybrid}}
-
----
diff --git a/ImplementationGuide/style/master.html b/ImplementationGuide/style/master.html
deleted file mode 100644
index a25e85f4..00000000
--- a/ImplementationGuide/style/master.html
+++ /dev/null
@@ -1,54 +0,0 @@
-
-
-
-
-
-
-
-