Merge branch 'TC_4.0.1' of https://github.com/gematik/spec-ISiK-Basis…

…modul into TC_4.0.1

.github/workflows/ToolUpdate.yml

@@ -5,6 +5,8 @@ on: # Trigger on commits to any branch and manual trigger
     push:
         branches:
         - '**' # Trigger on commits to any branch
+    schedule:
+      - cron: '0 0 * * *' # Runs at 00:00 UTC every day
 
 permissions:
   contents: write

.github/workflows/main.yml

@@ -13,6 +13,14 @@ on:
   pull_request:
     branches:
     - 'main**'
+  workflow_call:
+    secrets:
+      SIMPLIFIER_USERNAME:
+        required: true
+      SIMPLIFIER_PASSWORD:
+        required: true
+      WORKFLOW_PERMISSION_GITHUB:
+        required: true
 
   # Allows you to run this workflow manually from the Actions tab
   workflow_dispatch:
@@ -33,7 +41,7 @@ jobs:
       # Java and .NET are already installed on ubuntu-latest
 
       - name: Firely.Terminal (GitHub Actions)
-        uses: FirelyTeam/[email protected].2
+        uses: FirelyTeam/[email protected].3
         with:
           PATH_TO_CONFORMANCE_RESOURCES: Resources/fsh-generated/resources/
           #PATH_TO_EXAMPLES: Examples

.gitignore

@@ -8,6 +8,11 @@ Thumbs.db:encryptable
 ehthumbs.db
 ehthumbs_vista.db
 
+# Ignore specific fsh-index files
+fsh-index.json
+fsh-index.json.lock
+fsh-index.txt
+
 # Dump file
 *.stackdump
 

Resources/fsh-generated/resources/Account-AbrechnungsfallDRG.json

@@ -20,6 +20,23 @@
       "value": "0123456789"
     }
   ],
+  "coverage": [
+    {
+      "extension": [
+        {
+          "url": "http://fhir.de/StructureDefinition/ExtensionAbrechnungsart",
+          "valueCoding": {
+            "code": "DRG",
+            "system": "http://fhir.de/CodeSystem/dkgev/Abrechnungsart",
+            "display": "Diagnosebezogene Fallgruppen"
+          }
+        }
+      ],
+      "coverage": {
+        "reference": "Coverage/CoverageGesetzlich"
+      }
+    }
+  ],
   "extension": [
     {
       "url": "http://fhir.de/StructureDefinition/ExtensionAbrechnungsDiagnoseProzedur",
@@ -54,22 +71,5 @@
     {
       "reference": "Patient/PatientinMusterfrau"
     }
-  ],
-  "coverage": [
-    {
-      "extension": [
-        {
-          "url": "http://fhir.de/StructureDefinition/ExtensionAbrechnungsart",
-          "valueCoding": {
-            "code": "DRG",
-            "system": "http://fhir.de/CodeSystem/dkgev/Abrechnungsart",
-            "display": "Diagnosebezogene Fallgruppen"
-          }
-        }
-      ],
-      "coverage": {
-        "reference": "Coverage/CoverageGesetzlich"
-      }
-    }
   ]
 }

Resources/fsh-generated/resources/StructureDefinition-ISiKAbrechnungsfall.json

@@ -8,7 +8,7 @@
   "experimental": false,
   "date": "2024-10-29",
   "publisher": "gematik GmbH",
-  "description": "Dieses Profil ermöglicht die Gruppierung von medizinischen Leistungen zu einem gemeinsamen Abrechnungskontext.  \r\n### Motivation\r\nKomplementär zum Datenobjekt "Kontakt - Encounter" können Fälle, im Sinne einer Gruppierung von medizinischen Leistungen \r\ninnerhalb eines gemeinsamen Kontextes, zu einem Abrechnungsfall zusammengefasst werden.\r\nEin solcher Abrechnungsfall kann mehrere Kontakte umfassen (z.B. vorstationärer Besuch, stationärer Aufenthalt und nachstationärer Besuch).  \r\n\r\nGemeinsam mit dem Einrichtungskontakt bildet der Abrechnungsfall einen wichtigen Einstiegspunkt in die Dokumentation der Behandlungsleistungen der Patienten.\r\nAls Bindeglied zwischen den Kontakten und dem Versicherungsverhältnis erfolgt eine feingranulare Auflistung, \r\nin welchen Zeiträumen ein Behandlungskontext zwischen einer Gesundheitseinrichtung und der Patienten bestand.\r\nZudem werden Diagnosen abschließend / nachträglich dokumentiert, sodass eine Übersicht von relevanten (DRG)-Diagnosen ermöglicht wird, \r\nohne die Gesamtheit aller Kontakte betrachten zu müssen.\r\n\r\nIn FHIR wird der Abrechnungsfall mit der `Account`-Ressource repräsentiert.\r\n\r\n### Kompatibilität\r\n* zum Zeitpunkt der Veröffentlichung sind keine abweichenden Modellierungen der Account-Ressource bekannt.\r\n\r\nHinweise zu Inkompatibilitäten können über die [Portalseite](https://service.gematik.de/servicedesk/customer/portal/16) gemeldet werden.",
+  "description": "Dieses Profil ermöglicht die Gruppierung von medizinischen Leistungen zu einem gemeinsamen Abrechnungskontext.  \n### Motivation\nKomplementär zum Datenobjekt "Kontakt - Encounter" können Fälle, im Sinne einer Gruppierung von medizinischen Leistungen \ninnerhalb eines gemeinsamen Kontextes, zu einem Abrechnungsfall zusammengefasst werden.\nEin solcher Abrechnungsfall kann mehrere Kontakte umfassen (z.B. vorstationärer Besuch, stationärer Aufenthalt und nachstationärer Besuch).  \n\nGemeinsam mit dem Einrichtungskontakt bildet der Abrechnungsfall einen wichtigen Einstiegspunkt in die Dokumentation der Behandlungsleistungen der Patienten.\nAls Bindeglied zwischen den Kontakten und dem Versicherungsverhältnis erfolgt eine feingranulare Auflistung, \nin welchen Zeiträumen ein Behandlungskontext zwischen einer Gesundheitseinrichtung und der Patienten bestand.\nZudem werden Diagnosen abschließend / nachträglich dokumentiert, sodass eine Übersicht von relevanten (DRG)-Diagnosen ermöglicht wird, \nohne die Gesamtheit aller Kontakte betrachten zu müssen.\n\nIn FHIR wird der Abrechnungsfall mit der `Account`-Ressource repräsentiert.\n\n### Kompatibilität\n* zum Zeitpunkt der Veröffentlichung sind keine abweichenden Modellierungen der Account-Ressource bekannt.\n\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,
@@ -27,7 +27,7 @@
         "path": "Account.extension",
         "sliceName": "AbrechnungsDiagnoseProzedur",
         "short": "Abrechnungsdiagnose /-prozedur",
-        "comment": "Insbesondere bei Abrechnungen im DRG-Kontext muss eine Diagnose als Hauptdiagnose und \r\n  ggf. weitere Diagnosen als abrechnungsrelevante Nebendiagnosen klassifiziert werden. Diese Extension ermöglicht es, diese Qualifikation im Abrechnungskontext vorzunehmen, \r\n  unabhängig von der *medizinischen* Relevanz, die in `Encounter.diagnosis` erfolgt.",
+        "comment": "Insbesondere bei Abrechnungen im DRG-Kontext muss eine Diagnose als Hauptdiagnose und \n  ggf. weitere Diagnosen als abrechnungsrelevante Nebendiagnosen klassifiziert werden. Diese Extension ermöglicht es, diese Qualifikation im Abrechnungskontext vorzunehmen, \n  unabhängig von der *medizinischen* Relevanz, die in `Encounter.diagnosis` erfolgt.",
         "min": 0,
         "max": "*",
         "type": [
@@ -80,7 +80,7 @@
         "path": "Account.identifier",
         "sliceName": "Abrechnungsnummer",
         "short": "Abrechnungsfallnummer",
-        "comment": "Im DRG-Kontext werden häufig sämtliche Besuche (`Encounter`), die unter einen gemeinsamen Abrechnungskontext zusammengefasst werden, \r\n  unter einer "Fallnummer" geführt. In dieser Konstellation sind die Begriffe "Fallnummer" und "Abrechnungsfallnummer" gleichbedeutend.  \r\n  Dies ist insbesondere im Kontext des Mappings zwischen HL7 V2 und HL7 FHIR zu beachten, da es in V2 Usus ist, \r\n  die Fallnummer (eigentlich Identifier des Abrechnungsfalles) im `PV1`-Segment (Patient Visit) zu übermitteln. \r\n  Es handelt sich dabei jedoch *nicht* um den Identifier des Besuchs (`Encounter`) sondern den des Abrechnungsfalles (`Account`), \r\n  da der Identifier oft für die Gruppierung mehrerer Besuche (z.B. vorstationär + stationär + nachstationär) mit gemeinsamem (DRG)-Kontext verwendet wird.  \r\n  Die Abrechnungsfallnummer in `Account.identifier` muss identisch sein mit dem Identifier, \r\n  der bei den Encountern, die unter diesem Account gruppiert werden, unter `Encounter.account.identifier` angegeben ist.",
+        "comment": "Im DRG-Kontext werden häufig sämtliche Besuche (`Encounter`), die unter einen gemeinsamen Abrechnungskontext zusammengefasst werden, \n  unter einer "Fallnummer" geführt. In dieser Konstellation sind die Begriffe "Fallnummer" und "Abrechnungsfallnummer" gleichbedeutend.  \n  Dies ist insbesondere im Kontext des Mappings zwischen HL7 V2 und HL7 FHIR zu beachten, da es in V2 Usus ist, \n  die Fallnummer (eigentlich Identifier des Abrechnungsfalles) im `PV1`-Segment (Patient Visit) zu übermitteln. \n  Es handelt sich dabei jedoch *nicht* um den Identifier des Besuchs (`Encounter`) sondern den des Abrechnungsfalles (`Account`), \n  da der Identifier oft für die Gruppierung mehrerer Besuche (z.B. vorstationär + stationär + nachstationär) mit gemeinsamem (DRG)-Kontext verwendet wird.  \n  Die Abrechnungsfallnummer in `Account.identifier` muss identisch sein mit dem Identifier, \n  der bei den Encountern, die unter diesem Account gruppiert werden, unter `Encounter.account.identifier` angegeben ist.",
         "min": 1,
         "max": "1",
         "type": [
@@ -133,20 +133,20 @@
         "id": "Account.identifier:Abrechnungsnummer.system",
         "path": "Account.identifier.system",
         "short": "Namensraum des Identifiers",
-        "comment": "Hier ist stets der eindeutige Name (URL) des Namensraums anzugeben, \r\n    aus dem der Identifier stammt. \r\n    Hinweise zur Festlegung der URLs für lokale Namensräume sind in den \r\n    [Deutschen Basisprofilen](https://simplifier.net/guide/leitfaden-de-basis-r4/ig-markdown-Terminologie-Namensraeume?version=current) beschrieben.  \r\n    **Begründung Pflichtfeld:** `system` stellt in Kombination mit `value` die Eindeutigkeit eines Identifiers sicher.",
+        "comment": "Hier ist stets der eindeutige Name (URL) des Namensraums anzugeben, \n    aus dem der Identifier stammt. \n    Hinweise zur Festlegung der URLs für lokale Namensräume sind in den \n    [Deutschen Basisprofilen](https://simplifier.net/guide/leitfaden-de-basis-r4/ig-markdown-Terminologie-Namensraeume?version=current) beschrieben.  \n    **Begründung Pflichtfeld:** `system` stellt in Kombination mit `value` die Eindeutigkeit eines Identifiers sicher.",
         "mustSupport": true
       },
       {
         "id": "Account.identifier:Abrechnungsnummer.value",
         "path": "Account.identifier.value",
-        "comment": "Enthält den eigentlichen Wert des Identifiers.  \r\n    **Begründung Pflichtfeld:** Ist der Wert nicht bekannt, sollte der gesamte Slice weggelassen werden.",
+        "comment": "Enthält den eigentlichen Wert des Identifiers.  \n    **Begründung Pflichtfeld:** Ist der Wert nicht bekannt, sollte der gesamte Slice weggelassen werden.",
         "mustSupport": true
       },
       {
         "id": "Account.status",
         "path": "Account.status",
         "short": "Status",
-        "comment": "Zeigt den aktuellen Status der Ressource an.     \r\n  **WICHTIGER Hinweis für Implementierer:**    \r\n  * Alle server-seitigen Implementierungen MÜSSEN in der Lage sein, \r\n  die systemintern möglichen Statuswerte korrekt in FHIR abzubilden, mindestens jedoch `active` und `inactive`.\r\n  * Alle client-seitigen Implementierungen MÜSSEN in der Lage sein, sämtliche Status-Codes zu interpretieren und dem Anwender in angemessener Form darstellen zu können, \r\n  beispielsweise durch Ausblenden/Durchstreichen von Ressourcen mit dem status `entered-in-error` und Ausgrauen von Ressourcen, die einen Plan- oder Entwurfs-Status haben.",
+        "comment": "Zeigt den aktuellen Status der Ressource an.     \n  **WICHTIGER Hinweis für Implementierer:**    \n  * Alle server-seitigen Implementierungen MÜSSEN in der Lage sein, \n  die systemintern möglichen Statuswerte korrekt in FHIR abzubilden, mindestens jedoch `active` und `inactive`.\n  * Alle client-seitigen Implementierungen MÜSSEN in der Lage sein, sämtliche Status-Codes zu interpretieren und dem Anwender in angemessener Form darstellen zu können, \n  beispielsweise durch Ausblenden/Durchstreichen von Ressourcen mit dem status `entered-in-error` und Ausgrauen von Ressourcen, die einen Plan- oder Entwurfs-Status haben.",
         "mustSupport": true
       },
       {
@@ -169,7 +169,7 @@
         "id": "Account.subject.reference",
         "path": "Account.subject.reference",
         "short": "Patienten-Link",
-        "comment": "**Begründung Pflichtfeld:** Die Verlinkung auf eine Patienten-Ressource dient der technischen Zuordnung der Dokumentation zu einem Patienten \r\n    und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.",
+        "comment": "**Begründung Pflichtfeld:** Die Verlinkung auf eine Patienten-Ressource dient der technischen Zuordnung der Dokumentation zu einem Patienten \n    und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.",
         "min": 1,
         "mustSupport": true
       },
@@ -214,15 +214,15 @@
         "id": "Account.coverage.coverage.reference",
         "path": "Account.coverage.coverage.reference",
         "short": "Coverage-Link",
-        "comment": "**Begründung Pflichtfeld:** Die Verlinkung auf eine Coverage-Ressource dient der technischen Zuordnung zwischen Abrechnungsfall und Versicherungsverhältnis\r\n    und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.",
+        "comment": "**Begründung Pflichtfeld:** Die Verlinkung auf eine Coverage-Ressource dient der technischen Zuordnung zwischen Abrechnungsfall und Versicherungsverhältnis\n    und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.",
         "min": 1,
         "mustSupport": true
       },
       {
         "id": "Account.coverage.priority",
         "path": "Account.coverage.priority",
         "short": "Priorität",
-        "comment": "**Begründung des MS:** Wenn ein Primärsystem mehrere Kostenträger angibt, \r\n    sollte für lesende Systeme ersichtlich sein, welches der Hauptkostenträger ist.   \r\n    **Historie:**  \r\n    Diskussionstand der ISIK-Arbeitsgruppe vom 28.5.: Die Abbildung über einen Integer ist wünschenswert. \r\n    Eine binäre Einteilung in Hauptkostenträger (1) und alle anderen (2) wird der Komplexität der Priorisierung zur Kostenträgerschaft nicht gerecht. \r\n    Eine Ausdifferenzierung ist wünschenswert und sollte angestrebt werden.",
+        "comment": "**Begründung des MS:** Wenn ein Primärsystem mehrere Kostenträger angibt, \n    sollte für lesende Systeme ersichtlich sein, welches der Hauptkostenträger ist.   \n    **Historie:**  \n    Diskussionstand der ISIK-Arbeitsgruppe vom 28.5.: Die Abbildung über einen Integer ist wünschenswert. \n    Eine binäre Einteilung in Hauptkostenträger (1) und alle anderen (2) wird der Komplexität der Priorisierung zur Kostenträgerschaft nicht gerecht. \n    Eine Ausdifferenzierung ist wünschenswert und sollte angestrebt werden.",
         "mustSupport": true
       }
     ]

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 \r\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 \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 \r\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 \n    und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.",
         "min": 1,
         "mustSupport": true
       },