Skip to content

Commit

Permalink
fix fsh
Browse files Browse the repository at this point in the history
  • Loading branch information
@simoneOnFhir
simoneOnFhir committed Nov 5, 2024
1 parent 0009e0f commit 6fccd9e
Show file tree
Hide file tree
Showing 17 changed files with 286 additions and 931 deletions.
2 changes: 1 addition & 1 deletion Resources/fsh-generated/fsh-index.json
View file
Original file line number Diff line number Diff line change
Expand Up @@ -101,7 +101,7 @@
"fshType": "Instance",
"fshFile": "ISiKCapabilityStatementBasisServer.fsh",
"startLine": 1,
"endLine": 1457
"endLine": 1100
},
{
"outputFile": "CodeSystem-CodeSystemExample.json",
Expand Down
2 changes: 1 addition & 1 deletion Resources/fsh-generated/fsh-index.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ Bundle-ISiKBundle-Example.json ISiKBun
Bundle-SubscriptionNotificationBundleExample.json SubscriptionNotificationBundleExample Instance IsiKPatientMerge.fsh 100 - 113
Bundle-Szenario1.json Szenario1 Instance Beispiel-Szenario-1.fsh 164 - 174
Bundle-Szenario2.json Szenario2 Instance Beispiel-Szenario-2.fsh 99 - 107
CapabilityStatement-ISiKCapabilityStatementBasisServer.json ISiKCapabilityStatementBasisServer Instance ISiKCapabilityStatementBasisServer.fsh 1 - 1457
CapabilityStatement-ISiKCapabilityStatementBasisServer.json ISiKCapabilityStatementBasisServer Instance ISiKCapabilityStatementBasisServer.fsh 1 - 1100
CodeSystem-CodeSystemExample.json CodeSystemExample Instance ISiKCodeSystem.fsh 16 - 26
CodeSystem-ISiKBehandlungsergebnisRehaCS.json ISiKBehandlungsergebnisReha CodeSystem CodeSystems.fsh 11 - 18
CodeSystem-ISiKBesondereBehandlungsformRehaCS.json ISiKBesondereBehandlungsformReha CodeSystem CodeSystems.fsh 1 - 9
Expand Down
34 changes: 17 additions & 17 deletions Resources/fsh-generated/resources/Account-AbrechnungsfallDRG.json
View file
Original file line number Diff line number Diff line change
Expand Up @@ -20,23 +20,6 @@
"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",
Expand Down Expand Up @@ -71,5 +54,22 @@
{
"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"
}
}
]
}
859 changes: 121 additions & 738 deletions ...urces/fsh-generated/resources/CapabilityStatement-ISiKCapabilityStatementBasisServer.json
View file

Large diffs are not rendered by default.

18 changes: 9 additions & 9 deletions Resources/fsh-generated/resources/StructureDefinition-ISiKAbrechnungsfall.json
View file
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@
"experimental": false,
"date": "2024-11-05",
"publisher": "gematik GmbH",
"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.",
"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.",
"fhirVersion": "4.0.1",
"kind": "resource",
"abstract": false,
Expand All @@ -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 \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.",
"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.",
"min": 0,
"max": "*",
"type": [
Expand Down Expand Up @@ -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, \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.",
"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.",
"min": 1,
"max": "1",
"type": [
Expand Down Expand Up @@ -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, \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.",
"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.",
"mustSupport": true
},
{
"id": "Account.identifier:Abrechnungsnummer.value",
"path": "Account.identifier.value",
"comment": "Enthält den eigentlichen Wert des Identifiers. \n **Begründung Pflichtfeld:** Ist der Wert nicht bekannt, sollte der gesamte Slice weggelassen werden.",
"comment": "Enthält den eigentlichen Wert des Identifiers. \r\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. \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.",
"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.",
"mustSupport": true
},
{
Expand All @@ -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 \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 \r\n und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.",
"min": 1,
"mustSupport": true
},
Expand Down Expand Up @@ -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\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\r\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, \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.",
"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.",
"mustSupport": true
}
]
Expand Down
4 changes: 2 additions & 2 deletions Resources/fsh-generated/resources/StructureDefinition-ISiKAllergieUnvertraeglichkeit.json
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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
},
Expand All @@ -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
},
Expand Down
Loading

0 comments on commit 6fccd9e

Please sign in to comment.