update requirement .clinicalStatus (#428)

* update requirement .clinicalStatus * auto-generated FHIR files by GitHub Actions (CI FSH to FHIR Validation) * update releasenotes * Apply suggestions from code review * Update ImplementationGuide/markdown/ReleaseNotes.md --------- Co-authored-by: f-peverali <[email protected]>
gematik · Jul 3, 2024 · 09c3c94 · 09c3c94
1 parent 702535b
commit 09c3c94
Show file tree

Hide file tree

Showing 5 changed files with 14 additions and 2 deletions.
diff --git a/...mentationGuide/markdown/Diagnose/Diagnose_AnmerkungenZuDenMustSupportFeldern.md b/...mentationGuide/markdown/Diagnose/Diagnose_AnmerkungenZuDenMustSupportFeldern.md
@@ -2,7 +2,7 @@
 
 ### `Condition.clinicalStatus`
 
-**Bedeutung:** Kodierter klinischer Status der Diagnose. MUSS 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 über FHIR korrekt repräsentiert werden, können mindestens jedoch die Status-Werte "active" und "inactive" unterstützen. Deren korrekte Abbildung wird im Rahmen des Bestätigungsverfahrens überprüft.
+**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:**
 

diff --git a/ImplementationGuide/markdown/Diagnose/Diagnose_Interaktionen.md b/ImplementationGuide/markdown/Diagnose/Diagnose_Interaktionen.md
@@ -12,7 +12,7 @@ Folgende Suchparameter sind für das Bestätigungsverfahren relevant, auch in Ko
 
     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:
+1. Der Suchparameter "clinical-status" MUSS unterstützt werden, sofern das Element implementiert wird (siehe in der Profilstruktur Festlegung zu bedingtem Must Support):
 
     Beispiele:
 

diff --git a/ImplementationGuide/markdown/ReleaseNotes.md b/ImplementationGuide/markdown/ReleaseNotes.md
@@ -4,6 +4,14 @@ Im Rahmen der ISiK-Veröffentlichungen wird das [Semantic Versioning](https://se
 
 Die erste Ziffer X bezeichnet ein Major-Release und regelt die Gültigkeit von Releases. Die dritte Ziffer Y (Release x.0.y) bezeichnet eine technische Korrektur und versioniert kleinere Änderungen (Packages) während eines Jahres, z. B. 1.0.1.
 
+Version: 3.0.6
+
+Datum: t.b.d
+
+* Lockerung der Anforderung für MS-Definition und Suchparameter zu Condition.clinicalStatus (entspricht Änderungen in 4.0.0-rc3 und 2.0.7) https://github.com/gematik/spec-ISiK-Basismodul/pull/428
+
+----
+
 Version 3.0.5
 
 Datum: 30.04.2024

diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKDiagnose.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKDiagnose.json
@@ -59,6 +59,8 @@
       {
         "id": "Condition.clinicalStatus",
         "path": "Condition.clinicalStatus",
+        "definition": "Einschränkung der übergreifenden MS-Definition: Verfügt ein bestätigungsrelevantes System nicht über die Datenstruktur zur Hinterlegung des Status einer Diagnose, so MUSS dieses System die Information NICHT abbilden. Das System MUSS jedoch den Status kodieren in der Diagnose, sofern die Information verfügbar ist.",
+        "comment": "Hintergrund zur Motivation der MS-Definition: Auch in Stufe 3 sind keine (Client-seitigen) schreibenden Operationen für das Erstellen einer Condition-Ressource vorgesehen (siehe CapabilityStatement). Das heißt entweder führen KISe entsprechende Informationen und exponieren diese, oder es gibt keinen pragmatischen Mechanismus (im ISIK-Kontext), um den Use Case einer zusätzlichen Annotation mittels Client zu erfüllen. Da alle KIS-Hersteller, die sich zu Wort gemeldet haben, eine Befüllung von Condition.clinicalStatus NICHT unterstützen, erscheint das MS nach übergreifender Definition und ein verpflichtender Testfall nicht angemessen.",
         "mustSupport": true
       },
       {

diff --git a/Resources/input/fsh/ISiKDiagnose.fsh b/Resources/input/fsh/ISiKDiagnose.fsh
@@ -11,6 +11,8 @@ Description: "Dieses Profil ermöglicht die Nutzung von Diagnosen in ISiK Szenar
   * ^slicing.rules = #open
 * extension contains $condition-related named related 0..1 MS
 * clinicalStatus MS
+  * ^definition = "Einschränkung der übergreifenden MS-Definition: Verfügt ein bestätigungsrelevantes System nicht über die Datenstruktur zur Hinterlegung des Status einer Diagnose, so MUSS dieses System die Information NICHT abbilden. Das System MUSS jedoch den Status kodieren in der Diagnose, sofern die Information verfügbar ist."
+  * ^comment = "Hintergrund zur Motivation der MS-Definition: Auch in Stufe 3 sind keine (Client-seitigen) schreibenden Operationen für das Erstellen einer Condition-Ressource vorgesehen (siehe CapabilityStatement). Das heißt entweder führen KISe entsprechende Informationen und exponieren diese, oder es gibt keinen pragmatischen Mechanismus (im ISIK-Kontext), um den Use Case einer zusätzlichen Annotation mittels Client zu erfüllen. Da alle KIS-Hersteller, die sich zu Wort gemeldet haben, eine Befüllung von Condition.clinicalStatus NICHT unterstützen, erscheint das MS nach übergreifender Definition und ein verpflichtender Testfall nicht angemessen."
 * code 1.. MS
   * obeys icd-text-1
   * coding MS