refactoring Diagnose

gematik · Oct 11, 2024 · 9206b15 · 9206b15
1 parent 83bfbf1
commit 9206b15
Show file tree

Hide file tree

Showing 31 changed files with 1,203 additions and 271 deletions.
diff --git a/Resources/fsh-generated/fsh-index.json b/Resources/fsh-generated/fsh-index.json
diff --git a/Resources/fsh-generated/fsh-index.txt b/Resources/fsh-generated/fsh-index.txt
diff --git a/...urces/fsh-generated/resources/CapabilityStatement-ISiKCapabilityStatementBasisServer.json b/...urces/fsh-generated/resources/CapabilityStatement-ISiKCapabilityStatementBasisServer.json
diff --git a/Resources/fsh-generated/resources/CodeSystem-ISiKBehandlungsergebnisRehaCS.json b/Resources/fsh-generated/resources/CodeSystem-ISiKBehandlungsergebnisRehaCS.json
@@ -5,6 +5,7 @@
   "name": "ISiKBehandlungsergebnisReha",
   "id": "ISiKBehandlungsergebnisRehaCS",
   "description": "Behandlungsergebnis Reha gemäß §301(4 UND 4A) SGB V. Diagnosenbezogene Bewertung des Behandlungsergebnisses für einen Versicherten/Berechtigten bei Entlassung aus der Reha-Maßnahme bzw. Stellung eines Antrags auf Verlängerung. Vgl. Schlüsseltabelle 2.71 Diagnose - Behandlungsergebnis.",
+  "version": "4.0.1",
   "url": "https://gematik.de/fhir/isik/CodeSystem/ISiKBehandlungsergebnisRehaCS",
   "concept": [
     {
@@ -24,7 +25,6 @@
       "display": "verschlechtert"
     }
   ],
-  "version": "4.0.1",
   "experimental": false,
   "publisher": "gematik GmbH",
   "date": "2024-10-11",

diff --git a/Resources/fsh-generated/resources/CodeSystem-ISiKBesondereBehandlungsformRehaCS.json b/Resources/fsh-generated/resources/CodeSystem-ISiKBesondereBehandlungsformRehaCS.json
@@ -5,6 +5,7 @@
   "name": "ISiKBesondereBehandlungsformReha",
   "id": "ISiKBesondereBehandlungsformRehaCS",
   "description": "Besondere Behandlungsform der Reha gemäß §301(4 UND 4A) SGB V. Vgl. Schlüsseltabelle 2.51 Besondere Behandlungsformen.",
+  "version": "4.0.1",
   "url": "https://gematik.de/fhir/isik/CodeSystem/ISiKBesondereBehandlungsformRehaCS",
   "concept": [
     {
@@ -31,7 +32,6 @@
       "display": "sonstige"
     }
   ],
-  "version": "4.0.1",
   "experimental": false,
   "publisher": "gematik GmbH",
   "date": "2024-10-11",

diff --git a/Resources/fsh-generated/resources/CodeSystem-ISiKEntlassformRehaCS.json b/Resources/fsh-generated/resources/CodeSystem-ISiKEntlassformRehaCS.json
@@ -5,6 +5,7 @@
   "name": "ISiKEntlassformReha",
   "id": "ISiKEntlassformRehaCS",
   "description": "ISiK Entlassform Reha. Beschreibt Form und ggf. Weiterbehandlung der Entlassung eines Versicherten/Berechtigten aus verwaltungs- und medizinischer Sicht. Vgl. Schlüsseltabelle 2.107 Entlassungsform.",
+  "version": "4.0.1",
   "url": "https://gematik.de/fhir/isik/CodeSystem/ISiKEntlassformRehaCS",
   "concept": [
     {
@@ -76,7 +77,6 @@
       "display": "Entlassung vor Wiederaufnahme (für CIFolgetherapie)"
     }
   ],
-  "version": "4.0.1",
   "experimental": false,
   "publisher": "gematik GmbH",
   "date": "2024-10-11",

diff --git a/Resources/fsh-generated/resources/CodeSystem-ISiKUnterbrechnungRehaCS.json b/Resources/fsh-generated/resources/CodeSystem-ISiKUnterbrechnungRehaCS.json
@@ -5,6 +5,7 @@
   "name": "ISiKUnterbrechnungReha",
   "id": "ISiKUnterbrechnungRehaCS",
   "description": "ISiK Unterbrechung Reha. Dokumentiert die relevanten Gründe einer Unterbrechung einer Rehabilitationsmaßnahme im Einzelfall. Vgl. Schlüsseltabelle 2.111 Erläuterung zur Unterbrechung.",
+  "version": "4.0.1",
   "url": "https://gematik.de/fhir/isik/CodeSystem/ISiKUnterbrechnungRehaCS",
   "concept": [
     {
@@ -36,7 +37,6 @@
       "display": "Sonstiger Grund, der zur Unterbrechung der Pflegekosten führt"
     }
   ],
-  "version": "4.0.1",
   "experimental": false,
   "publisher": "gematik GmbH",
   "date": "2024-10-11",

diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKAbrechnungsfall.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKAbrechnungsfall.json
@@ -161,7 +161,7 @@
       {
         "id": "Account.coverage.priority",
         "path": "Account.coverage.priority",
-        "comment": "Motivation des MS: Wenn ein Primärsystem mehrere Kostenträger angibt, sollte für lesende Systeme ersichtlich sein, welches der Hauptkostenträger ist. \n    \nDiskussionstand der ISIK-Arbeitsgruppe vom 28.5.: Die Abbildung über einen Integer ist wünschenswert. Eine binäre Einteilung in Hauptkostenträger (1) und alle anderen (2) wird der Komplexität der Priorisierung zur Kostenträgerschaft nicht gerecht. Eine Ausdifferenzierung ist wünschenswert und sollte angestrebt werden.",
+        "comment": "Motivation des MS: Wenn ein Primärsystem mehrere Kostenträger angibt, sollte für lesende Systeme ersichtlich sein, welches der Hauptkostenträger ist. \r\n    \r\nDiskussionstand der ISIK-Arbeitsgruppe vom 28.5.: Die Abbildung über einen Integer ist wünschenswert. Eine binäre Einteilung in Hauptkostenträger (1) und alle anderen (2) wird der Komplexität der Priorisierung zur Kostenträgerschaft nicht gerecht. Eine Ausdifferenzierung ist wünschenswert und sollte angestrebt werden.",
         "mustSupport": true
       }
     ]

diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKAllergieUnvertraeglichkeit.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKAllergieUnvertraeglichkeit.json
@@ -205,7 +205,7 @@
         "id": "AllergyIntolerance.patient.reference",
         "path": "AllergyIntolerance.patient.reference",
         "short": "Patienten-Link",
-        "comment": "Die Verlinkung auf eine Patienten-Ressource dient der technischen Zuordnung der Dokumentation \n    zu einem Patienten und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.",
+        "comment": "Die Verlinkung auf eine Patienten-Ressource dient der technischen Zuordnung der Dokumentation \r\n    zu einem Patienten und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.",
         "min": 1,
         "mustSupport": true
       },
@@ -219,7 +219,7 @@
         "id": "AllergyIntolerance.encounter.reference",
         "path": "AllergyIntolerance.encounter.reference",
         "short": "Encounter-Link",
-        "comment": "Die Verlinkung auf eine Encounter-Ressource dient der technischen Zuordnung der Dokumentation zu einem Aufenthalt \n    und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.",
+        "comment": "Die Verlinkung auf eine Encounter-Ressource dient der technischen Zuordnung der Dokumentation zu einem Aufenthalt \r\n    und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.",
         "min": 1,
         "mustSupport": true
       },

diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKDiagnose.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKDiagnose.json
@@ -8,7 +8,7 @@
   "experimental": false,
   "date": "2024-10-11",
   "publisher": "gematik GmbH",
-  "description": "Dieses Profil ermöglicht die Nutzung von Diagnosen in ISiK Szenarien.",
+  "description": "Dieses Profil spezifiziert die Minimalanforderungen für die Bereitstellung von Informationen \r\nüber die Diagnosen eines Patienten im Rahmen des Bestätigungsverfahrens der gematik.  \r\n### Motivation\r\nDie Möglichkeit, auf eine Übersicht der Diagnosen eines Patienten zuzugreifen, Patienten anhand ihrer Diagnose zu suchen oder zu prüfen, \r\nob eine konkrete Diagnose bei einem Patienten vorliegt, sind wichtige Funktionen im klinischen Behandlungsablauf.  \r\n\r\nIn FHIR werden Diagnosen mit der Condition-Ressource repräsentiert.  \r\n\r\nDa die Diagnosen in klinischen Primärsystemen in der Regel in ICD-10-codierter Form vorliegen, fordert ISiK in erster Linie diese Form des Austausches. \r\nFalls eine Diagnose zwar dokumentiert, aber noch nicht codiert wurde (z.B. wenn die Kodierung erst nach der Entlassung erfolgt), \r\nist alternativ eine Repräsentation als Freitext-Diagnose möglich.\r\n\r\n### Kompatibilität\r\nFü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:\r\n* das [Profil ProfileConditionDiagnose der Medizininformatik-Initative](https://www.medizininformatik-initiative.de/fhir/core/modul-diagnose/StructureDefinition/Diagnose)\r\n* das [Profil KBV_PR_Base_Condition_Diagnosis der KBV](https://fhir.kbv.de/StructureDefinition/KBV_PR_Base_Condition_Diagnosis)]  \r\nHinweise zu Inkompatibilitäten können über die [Portalseite](https://service.gematik.de/servicedesk/customer/portal/16) gemeldet werden.",
   "fhirVersion": "4.0.1",
   "kind": "resource",
   "abstract": false,
@@ -39,6 +39,8 @@
         "id": "Condition.extension:related",
         "path": "Condition.extension",
         "sliceName": "related",
+        "short": "Verknüpfte Diagnose",
+        "comment": " Die Deutschen Kodierrichtlinien und die 'German MOdification' ermöglichen es teilweise, \r\n  ICD-10-Codierte Diagnosen miteinander zu verknüpfen (&quot;Kreuz-Stern-Ausrufezeichen-Notation&quot;), \r\n  diese aber dennoch wie eigenständige Diagnosen (mit jeweils eigener Diagnosesicherheit oder -Lokalisation) zu kommunizieren.\r\n  Daher ist es in Deutschland nicht möglich, dem internationalen Usus zu folgen und verknüpfte Diagnosen als postkoordinierten Code *einer* Condition-Ressource aufzufassen.\r\n  Statt dessen müssen sie zwei eigenständige Condition-Ressourcen abgebildet werden, die mit Hilfe der `related`-Extension miteinander verknüpft werden.",
         "min": 0,
         "max": "1",
         "type": [
@@ -54,13 +56,15 @@
       {
         "id": "Condition.clinicalStatus",
         "path": "Condition.clinicalStatus",
-        "definition": "Conditional Must Support - 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 4 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.",
+        "short": "klinischer Status",
+        "comment": "**Begründung MS:** Auch in Stufe 4 sind keine (Client-seitigen) schreibenden Operationen für das Erstellen einer Condition-Ressource vorgesehen \r\n  (siehe CapabilityStatement). Das heißt entweder führen KISe entsprechende Informationen und exponieren diese, \r\n  oder es gibt keinen pragmatischen Mechanismus (im ISIK-Kontext), um den Use Case einer zusätzlichen Annotation mittels Client zu erfüllen. \r\n  Da alle KIS-Hersteller, die sich zu Wort gemeldet haben, eine Befüllung von Condition.clinicalStatus NICHT unterstützen, \r\n  erscheint das MS nach übergreifender Definition und ein verpflichtender Testfall nicht angemessen.  \r\n  **Einschränkung der übergreifenden MS-Definition:** Verfügt ein bestätigungsrelevantes System nicht über die Datenstruktur \r\n  zur Hinterlegung des Status einer Diagnose, so MUSS dieses System die Information NICHT abbilden. \r\n  Das System MUSS jedoch den Status kodieren in der Diagnose, sofern die Information verfügbar ist.",
         "mustSupport": true
       },
       {
         "id": "Condition.code",
         "path": "Condition.code",
+        "short": "Diagnose-Code",
+        "comment": "Diagnosen SOLLEN mindestens entweder mit einem der angebenen standardisierten Codier-Verfahren codiert werden. \r\n  Ist keine Codierung möglich, MUSS statt dessen eine textuelle Beschreibung der Prozedur angegeben werden.  \r\n   **Begründung Pflichtfeld:** Ist *weder* eine Codierung *noch* eine textuelle Beschreibung vorhanden, besitzt diese Ressource keine medizinische Aussagefähigkeit.",
         "min": 1,
         "constraint": [
           {
@@ -201,7 +205,7 @@
       {
         "id": "Condition.bodySite",
         "path": "Condition.bodySite",
-        "comment": "Motivation: Harmonisierung mit KBV (KBV_PR_Base_Condition_Diagnosis)",
+        "comment": "**Begründung MS:** Harmonisierung mit KBV-Profil (KBV_PR_Base_Condition_Diagnosis)",
         "mustSupport": true
       },
       {
@@ -244,7 +248,7 @@
         "id": "Condition.subject.reference",
         "path": "Condition.subject.reference",
         "short": "Patienten-Link",
-        "comment": "Die Verlinkung auf eine Patienten-Ressource dient der technischen Zuordnung der Dokumentation \n    zu einem Patienten und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.",
+        "comment": "Die Verlinkung auf eine Patienten-Ressource dient der technischen Zuordnung der Dokumentation \r\n    zu einem Patienten und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.",
         "min": 1,
         "mustSupport": true
       },
@@ -258,7 +262,7 @@
         "id": "Condition.encounter.reference",
         "path": "Condition.encounter.reference",
         "short": "Encounter-Link",
-        "comment": "Die Verlinkung auf eine Encounter-Ressource dient der technischen Zuordnung der Dokumentation zu einem Aufenthalt \n    und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.",
+        "comment": "Die Verlinkung auf eine Encounter-Ressource dient der technischen Zuordnung der Dokumentation zu einem Aufenthalt \r\n    und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.",
         "min": 1,
         "mustSupport": true
       },
@@ -275,46 +279,36 @@
           "ordered": false,
           "rules": "open"
         },
+        "short": "Erkrankungsbeginn",
+        "comment": "Datum oder Alter/Lebensphase des Erkrankungsbeginns\r\n  **Begründung MS:** Die Kenntnis des Erkrankungszeitraumes ist wichtig für die korrekte Einschätzung der medizinischen Relevanz einer Erkraknung.  \r\n  **Einschränkung der übergreifenden MS-Definition:** Verfügt ein bestätigungsrelevantes System nicht über die Datenstruktur zur Hinterlegung des Erkrankungszeitraumes,\r\n  so MUSS dieses System die Information NICHT abbilden. \r\n  Das System MUSS jedoch klinischen Status (`active`/`inactive`/`resolved`...) der Diagnose korrekt angeben, sofern die Information verfügbar ist.",
         "type": [
           {
             "code": "dateTime"
           },
           {
-            "code": "Period"
+            "code": "Age"
           }
-        ]
+        ],
+        "mustSupport": true
       },
       {
-        "id": "Condition.onset[x]:onsetPeriod",
+        "id": "Condition.onset[x]:onsetAge",
         "path": "Condition.onset[x]",
-        "sliceName": "onsetPeriod",
+        "sliceName": "onsetAge",
         "min": 0,
         "max": "1",
         "type": [
           {
-            "code": "Period"
-          }
-        ]
-      },
-      {
-        "id": "Condition.onset[x]:onsetPeriod.start.extension:Lebensphase-Start",
-        "path": "Condition.onset[x].start.extension",
-        "sliceName": "Lebensphase-Start",
-        "min": 0,
-        "max": "1",
-        "type": [
-          {
-            "code": "Extension",
-            "profile": [
-              "http://fhir.de/StructureDefinition/lebensphase"
-            ]
+            "code": "Age"
           }
         ]
       },
       {
-        "id": "Condition.onset[x]:onsetPeriod.end.extension:Lebensphase-Ende",
-        "path": "Condition.onset[x].end.extension",
-        "sliceName": "Lebensphase-Ende",
+        "id": "Condition.onset[x]:onsetAge.extension:Lebensphase-Beginn",
+        "path": "Condition.onset[x].extension",
+        "sliceName": "Lebensphase-Beginn",
+        "short": "Lebensphase des Erkrankungsbeginns",
+        "comment": "Alternative Angabe, wenn genauere Eingrenzungen des Zeitraums nicht möglich sind, insbesondere im Kontext anamnestischer Diagnosen",
         "min": 0,
         "max": "1",
         "type": [
@@ -339,8 +333,16 @@
           "ordered": false,
           "rules": "open"
         },
-        "definition": "Einschränkung der übergreifenden MS-Definition: Verfügt ein bestätigungsrelevantes System nicht über die Datenstruktur zur Hinterlegung des Abklingzeitraums oder Zeitpunkts, 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": "Motivation: Harmonisierung mit KBV (KBV_PR_Base_Condition_Diagnosis) - Hintergrund zur Motivation der MS-Definition: Auch in Stufe 4 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 viele KIS-Hersteller im analogen Fall eine Befüllung von Condition.clinicalStatus NICHT unterstützen, erscheint das MS nach übergreifender Definition auch an dieser Stelle nicht angemessen.",
+        "short": "Erkrankungsende",
+        "comment": "Datum oder Alter/Lebensphase des Erkrankungsendes  \r\n  **Begründung MS:** Die Kenntnis des Erkrankungszeitraumes ist wichtig für die korrekte Einschätzung der medizinischen Relevanz einer Erkraknung.  \r\n  **Einschränkung der übergreifenden MS-Definition:** Verfügt ein bestätigungsrelevantes System nicht über die Datenstruktur zur Hinterlegung des Erkrankungszeitraumes,\r\n  so MUSS dieses System die Information NICHT abbilden. \r\n  Das System MUSS jedoch klinischen Status (`active`/`inactive`/`resolved`...) der Diagnose korrekt angeben, sofern die Information verfügbar ist.",
+        "type": [
+          {
+            "code": "dateTime"
+          },
+          {
+            "code": "Age"
+          }
+        ],
         "mustSupport": true
       },
       {
@@ -359,6 +361,8 @@
         "id": "Condition.abatement[x]:abatementAge.extension:Lebensphase-Ende",
         "path": "Condition.abatement[x].extension",
         "sliceName": "Lebensphase-Ende",
+        "short": "Lebensphase des Erkrankungsendes",
+        "comment": "Alternative Angabe, wenn genauere Eingrenzungen des Zeitraums nicht möglich sind, insbesondere im Kontext anamnestischer Diagnosen",
         "min": 0,
         "max": "1",
         "type": [
@@ -379,6 +383,8 @@
       {
         "id": "Condition.note",
         "path": "Condition.note",
+        "short": "Notizen",
+        "comment": "Ergänzende Hinweise und Anmerkungen zur Diagnose",
         "mustSupport": true
       }
     ]

diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKLebensZustand.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKLebensZustand.json
@@ -92,7 +92,7 @@
         "id": "Observation.subject.reference",
         "path": "Observation.subject.reference",
         "short": "Patienten-Link",
-        "comment": "Die Verlinkung auf eine Patienten-Ressource dient der technischen Zuordnung der Dokumentation \n    zu einem Patienten und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.",
+        "comment": "Die Verlinkung auf eine Patienten-Ressource dient der technischen Zuordnung der Dokumentation \r\n    zu einem Patienten und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.",
         "min": 1,
         "mustSupport": true
       },
@@ -106,7 +106,7 @@
         "id": "Observation.encounter.reference",
         "path": "Observation.encounter.reference",
         "short": "Encounter-Link",
-        "comment": "Die Verlinkung auf eine Encounter-Ressource dient der technischen Zuordnung der Dokumentation zu einem Aufenthalt \n    und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.",
+        "comment": "Die Verlinkung auf eine Encounter-Ressource dient der technischen Zuordnung der Dokumentation zu einem Aufenthalt \r\n    und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.",
         "min": 1,
         "mustSupport": true
       },