From 916fb5060d7ef80bd925862d4893c5db230ed526 Mon Sep 17 00:00:00 2001 From: f-peverali Date: Thu, 10 Oct 2024 14:40:42 +0000 Subject: [PATCH 01/10] auto-generated file update of TC version by GitHub Actions (CI FSH to FHIR Validation) --- .../ImplementierungsleitfadenIsiK_basismodul.json | 2 +- ImplementationGuide/markdown/Einfuehrung.md | 4 ++-- Resources/input/fsh/ruleset.fsh | 8 ++++---- package.json | 2 +- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/ImplementationGuide/ImplementierungsleitfadenIsiK_basismodul.json b/ImplementationGuide/ImplementierungsleitfadenIsiK_basismodul.json index 7a07cd2f..8cd03041 100644 --- a/ImplementationGuide/ImplementierungsleitfadenIsiK_basismodul.json +++ b/ImplementationGuide/ImplementierungsleitfadenIsiK_basismodul.json @@ -1,7 +1,7 @@ { "resourceType": "ImplementationGuide", "url": "https://gematik.de/fhir/ISiK/v2/Basismodul/ImplementationGuide/ISiK-basismodul", - "version": "2.0.7", + "version": "2.0.8", "name": "Implementierungsleitfaden ISiK-Basismodul Stufe 2", "status": "active", "fhirVersion": [ diff --git a/ImplementationGuide/markdown/Einfuehrung.md b/ImplementationGuide/markdown/Einfuehrung.md index cd602daa..9b3ac6ea 100644 --- a/ImplementationGuide/markdown/Einfuehrung.md +++ b/ImplementationGuide/markdown/Einfuehrung.md @@ -1,9 +1,9 @@ gematik logo ---- -Version: 2.0.7 +Version: 2.0.8 -Datum: 04.07.2024 +Datum: 10.10.2024 Realm: Deutschland diff --git a/Resources/input/fsh/ruleset.fsh b/Resources/input/fsh/ruleset.fsh index 557a6f58..51005e5c 100644 --- a/Resources/input/fsh/ruleset.fsh +++ b/Resources/input/fsh/ruleset.fsh @@ -2,13 +2,13 @@ RuleSet: Meta * ^status = #active * ^experimental = false * ^publisher = "gematik GmbH" -* ^date = "2024-07-04" +* ^date = "2024-10-10" RuleSet: Meta-CapabilityStatement * status = #active * experimental = false -* version = "2.0.7" +* version = "2.0.8" * publisher = "gematik GmbH" -* date = "2024-07-04" -* implementationGuide = "https://gematik.de/fhir/isik/v2/Basismodul/ImplementationGuide|2.0.7" +* date = "2024-10-10" +* implementationGuide = "https://gematik.de/fhir/isik/v2/Basismodul/ImplementationGuide|2.0.8" * url = "https://gematik.de/fhir/isik/v2/Basismodul/CapabilityStatement/basis-server" diff --git a/package.json b/package.json index a73b8d69..38645d1a 100644 --- a/package.json +++ b/package.json @@ -1,6 +1,6 @@ { "name": "de.gematik.isik-basismodul", - "version": "2.0.7", + "version": "2.0.8", "fhirVersions": [ "4.0.1" ], From 00ac0b21a773a596351934f7c29c5df2743edaf1 Mon Sep 17 00:00:00 2001 From: f-peverali <112709306+f-peverali@users.noreply.github.com> Date: Mon, 14 Oct 2024 09:13:04 +0200 Subject: [PATCH 02/10] update suchparameter (backport aus V.4.0.1) (#452) * update suchparameter (backport aus V.4.0.1 * update releasenotes --- ImplementationGuide/markdown/ReleaseNotes.md | 8 ++ ...ebergreifendeFestlegungen_Suchparameter.md | 104 +++++++++++------- 2 files changed, 70 insertions(+), 42 deletions(-) diff --git a/ImplementationGuide/markdown/ReleaseNotes.md b/ImplementationGuide/markdown/ReleaseNotes.md index 073e1714..9b2421ef 100644 --- 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: 2.0.8 + +Datum: t.b.d + +* Schwächung der Anforderungen für Suchparameter https://github.com/gematik/spec-ISiK-Basismodul/pull/452 + +--- + Version: 2.0.7 diff --git a/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Suchparameter.md b/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Suchparameter.md index 4660b66f..684d3868 100644 --- a/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Suchparameter.md +++ b/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Suchparameter.md @@ -1,8 +1,14 @@ +--- +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 *einer* 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. -Es MUSS sichergestellt werden, dass nicht unterstützte oder leere Suchparameter **nicht** zu einem Fehler führen. Siehe [FHIR RESTful Search - Handling Errors](https://www.hl7.org/fhir/R4/search.html#errors). Alle unterstützten und verwendeten Suchparameter sind im Self-Link des Suchbundles korrekt anzugeben. +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): @@ -24,15 +30,21 @@ Für die im Rahmen dieses Leitfadens relevanten Typen gelten folgende allgemeine Die Präfixe `lt`,`le`,`gt`,`ge`,`eq` MÜSSEN für jeden Suchparameter vom Typ 'date/dateTime' unterstützt werden. +Begründung: Die Funktionalität datums-eingeschränkt suchen zu können ist essentiell. + +Hinweis: Die Abfragemöglichkeit arbeitet ungewollten Massendatenabfragen entgegen, da sich sonst Suchen zwangsläufig über den gesamten Zeitraum erstrecken würden. + + + **Beispiele**: -```[base]/Patient?birthDate=ge2000-01-01```
-Suche nach allen Patienten mit einem Geburtsdatum 2000-01-01T00:00 oder später. +```[base]/Encounter?date=eq2024-01-01&patient=Patient/Test```
+Suche nach allen Kontakten mit einem Datum am 2024-01-01T00:00 im Patientenkontext "Test". -```[base]/Patient?birthDate=eq2000-01-01```
-Suche nach allen Patienten mit einem Geburtsdatum von 2000-01-01T00:00 bis (aber nicht einschließlich) 2000-02-01T00:00 +```[base]/Condition?recorded-date=eq2024-01-01&patient=Patient/Test```
+Suche nach allen Diagnosen mit einem Dokumentationsdatum von 2024-01-01T00:00 bis (aber nicht einschließlich) 2024-01-02T00:00 im Patientenkontext "Test". -Es ist zu beachten, dass jedes Datum einen impliziten Werte-Bereich besitzt. Siehe http://hl7.org/fhir/search.html#date. +Es ist zu beachten, dass jedes Datum einen impliziten Werte-Bereich besitzt. Siehe https://hl7.org/fhir/R4/search.html#date. ### String @@ -59,42 +71,33 @@ Diese Suche gibt alle Condition-Ressourcen zurück zum Client, welche innerhalb ### Reference -Der Modifier `:identifier` MUSS für alle spezifizierten Suchparameter vom Typ 'Reference' unterstützt werden. +Der Modifier `:identifier` KANN für alle spezifizierten Suchparameter vom Typ 'Reference' unterstützt werden. -Der [type] Modifier MUSS 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. -**Beispiele**: +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. + +Begründung: Die Unterstützung dieser Suchparameter-Typen ist essentiell für Abfragen mit [Chaining](https://hl7.org/fhir/r4/search.html#chaining) und [Reverse Chaining](https://hl7.org/fhir/r4/search.html#has). Innerhalb der Spezifikation ist für jedes Datenobjekt spezifiziert weshalb eine solche Abfrage versorgungsrelevant ist. -``[base]/Procedure?subject:Patient=Test`` -Diese Suche gibt alle Prozeduren zurück zum Client, welche innerhalb `Procedure.subject` auf einen Patienten verweist mit dem der ID "Test". Hierdurch werden Referenzen auf den Ressourcentyp "Group" in der Suche ausgeschlossen. **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' MÜSSEN 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 implementiert werden. Chaining und Reverse Chaining MUSS für alle Suchparameter über alle Ebenen und Datenobjekte hinweg (potentiell in Kombination) unterstützt werden. +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?encounter.subject.name=Test`` -Diese Suche gibt alle Diagnosen zurück zum Client, welche eine Encounter Reference besitzen und innerhalb `Encounter.subject` auf einen Patienten verweist mit dem Namen "Test". - -``[base]/Patient?_has:Procedure:patient:code=1234-5`` -Diese Suche gibt alle Patienten zurück zum Client, welche innerhalb `Procedure.subject` auf einen Patienten verweisen und einen Code mit dem Wert '1234-5' in `Procedure.code` enthalten. - -``[base]/Patient?_has:Procedure:patient:encounter.identifier=12345`` -Diese Suche gibt alle Patienten zurück zum Client, welche innerhalb `Procedure.subject` auf einen Patienten verweisen und einen deren Procedure auf einen Encounter verweist z.B. mit der Aufnahmenummer '1234-5'. - -``[base]/Procedure?_has:Encounter:diagnosis:diagnosis:Condition.code=http://fhir.de/CodeSystem/bfarm/icd-10-gm|F16.1`` -Diese Suche gibt alle Prozeduren zurück zum Client, welche innerhalb `Encounter.diagnosis.condition` auf einen Encounter verweisen, der wiederrum mit einer Condition verlinkt ist mit dem ICD-10-GM Code 'F16.1'. +``[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ätigungsrelevante Datenojekte implementiert werden: +Folgende Suchparameter MÜSSEN für alle bestätigungsrelevanten Datenobjekte implementiert werden: * ``_id`` @@ -107,47 +110,64 @@ Folgende Suchparameter MÜSSEN für alle bestätigungsrelevante Datenojekte impl - 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). -* ``_has`` - - - Siehe Abschnitt "Allgemeine Hinweise zu Suchparametern". - * ``_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). - Hierraus ergibt sich, dass durch ein [Paging ensprechende der FHIR-Kernspezifikation](https://www.hl7.org/fhir/R4/http.html#paging) unterstützt werden MUSS. + 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. -* ``_include`` + Der ```:iterate``` Modifier KANN unterstützt werden. + +Die aufgelisteten Suchparameter MÜSSEN entsprechend der Vorgaben für das CapabilityStatement pro Ressource aufgelistet werden. - - Beispiele: ``GET [base]/Encounter?_include=Patient:subject`` - - Anwendungshinweise: Weitere Informationen zur Suche nach "_tag" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Including other resources in result"](https://www.hl7.org/fhir/R4/search.html#revinclude). - - 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}}. +## Verkettete Suchparameter (Fokus auf Patient und Encounter) - Der ```:iterate``` Modifier KANN unterstützt werden. +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. + +* ``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 BEsondern Diagnose, beobachtung Prozedur etc.) oder Fallkontakten (z.B. zum Ermitteln des Kontextes einer Prozedur) + +Folgende Suchparameter MÜSSEN 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}}. * ``_revinclude`` - Beispiele: ``GET [base]/Patient?_revinclude=Encounter:subject`` - - Anwendungshinweise: Weitere Informationen zur Suche nach "_tag" finden sich in der [FHIR-Basisspezifikation - Abschnitt "Including other resources in result"](https://www.hl7.org/fhir/R4/search.html#revinclude). - - 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.searchRevInclude``` angegeben werden. Siehe {{pagelink:ImplementationGuide/markdown/CapabilityStatement.md}}. + - 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 Referenzen für die ein Chaining unterstützt wird MUSS auch der _revinclude-Parameter implementiert werden. Alle unterstützten Revinclude-Referenzen MÜSSEN im CapabilityStatement unter ```CapabilityStatement.rest.resource.searchRevInclude``` angegeben werden. Siehe {{pagelink:ImplementationGuide/markdown/CapabilityStatement.md}}. - Der ```:iterate``` Modifier KANN unterstützt werden. +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. -Die aufgelisteten Suchparameter MÜSSEN entsprechend der Vorgaben für das CapabilityStatement pro Ressource aufgelistet werden. -## Best Practice Empfehlungen für Standard-Suchfilter +## 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. +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 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). +- 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. From 26a0db516b588fdf6daad773aef9a92633f34102 Mon Sep 17 00:00:00 2001 From: f-peverali Date: Mon, 14 Oct 2024 07:13:26 +0000 Subject: [PATCH 03/10] auto-generated file update of TC version by GitHub Actions (CI FSH to FHIR Validation) --- ImplementationGuide/markdown/Einfuehrung.md | 2 +- Resources/input/fsh/ruleset.fsh | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/ImplementationGuide/markdown/Einfuehrung.md b/ImplementationGuide/markdown/Einfuehrung.md index 9b3ac6ea..dd8044e0 100644 --- a/ImplementationGuide/markdown/Einfuehrung.md +++ b/ImplementationGuide/markdown/Einfuehrung.md @@ -3,7 +3,7 @@ ---- Version: 2.0.8 -Datum: 10.10.2024 +Datum: 14.10.2024 Realm: Deutschland diff --git a/Resources/input/fsh/ruleset.fsh b/Resources/input/fsh/ruleset.fsh index 51005e5c..86209d9a 100644 --- a/Resources/input/fsh/ruleset.fsh +++ b/Resources/input/fsh/ruleset.fsh @@ -2,13 +2,13 @@ RuleSet: Meta * ^status = #active * ^experimental = false * ^publisher = "gematik GmbH" -* ^date = "2024-10-10" +* ^date = "2024-10-14" RuleSet: Meta-CapabilityStatement * status = #active * experimental = false * version = "2.0.8" * publisher = "gematik GmbH" -* date = "2024-10-10" +* date = "2024-10-14" * implementationGuide = "https://gematik.de/fhir/isik/v2/Basismodul/ImplementationGuide|2.0.8" * url = "https://gematik.de/fhir/isik/v2/Basismodul/CapabilityStatement/basis-server" From e32484651eeaf2362b29a4d2b3da15629bfcfff5 Mon Sep 17 00:00:00 2001 From: f-peverali <112709306+f-peverali@users.noreply.github.com> Date: Wed, 23 Oct 2024 17:04:09 +0200 Subject: [PATCH 04/10] Feature/backport requirements to stufe2 ptdata 974 (#471) * soften requirements for REST API * update releasenotes * Update ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Rest.md --- ImplementationGuide/markdown/ReleaseNotes.md | 1 + .../UebergreifendeFestlegungen_Rest.md | 16 ++++++++++------ 2 files changed, 11 insertions(+), 6 deletions(-) diff --git a/ImplementationGuide/markdown/ReleaseNotes.md b/ImplementationGuide/markdown/ReleaseNotes.md index 9b2421ef..8dff47f9 100644 --- a/ImplementationGuide/markdown/ReleaseNotes.md +++ b/ImplementationGuide/markdown/ReleaseNotes.md @@ -9,6 +9,7 @@ Version: 2.0.8 Datum: t.b.d * Schwächung der Anforderungen für Suchparameter https://github.com/gematik/spec-ISiK-Basismodul/pull/452 +* Schwächung der Anforderungen für die Übernahme fremder Ressourcen (+ Konkretisierung bei Ablehnung) https://github.com/gematik/spec-ISiK-Basismodul/pull/471 --- diff --git a/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Rest.md b/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Rest.md index 471a9b72..5deab905 100644 --- a/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Rest.md +++ b/ImplementationGuide/markdown/UebergreifendeFestlegungen/UebergreifendeFestlegungen_Rest.md @@ -8,9 +8,11 @@ Siehe: https://www.hl7.org/fhir/R4/http.html#read 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. +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. -Eine Ressource welche NICHT durch das bestätigungsrelevante System angelegt wird, MUSS in ```Resource.meta.tag``` eine Angabe enthalten, welche indiziert, dass diese Ressource durch ein Fremdsystem erzeugt wurde. Dieser Tag MUSS durch den Server hinzugefügt werden, sollte der Client diese Angabe nicht mit übermitteln. Die Kodierung MUSS mindestens mittels des CodeSystems ```http://fhir.de/CodeSystem/common-meta-tag-de``` erfolgen. Weitere Kodierungen KÖNNEN hinzugefügt werden. +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 @@ -30,18 +32,20 @@ json 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, MUSS 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. +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 400 Status Code mit einer ```OperationOutcome```-Ressource zurückgegeben werden. Diese enthält eine Auflistung aller Fehler in der übermittelten Ressource in kodierter Form. +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. +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 Stufe 1 des ISiK Basismoduls jedoch nicht bestätigungsrelevant. \ No newline at end of file +Diese sind in Stufe 2 des ISiK Basismoduls jedoch nicht bestätigungsrelevant. From e92ad11126e93ec63d8c90ca3018c6a9447c2b15 Mon Sep 17 00:00:00 2001 From: f-peverali Date: Wed, 23 Oct 2024 15:04:28 +0000 Subject: [PATCH 05/10] auto-generated file update of TC version by GitHub Actions (CI FSH to FHIR Validation) --- ImplementationGuide/markdown/Einfuehrung.md | 2 +- Resources/input/fsh/ruleset.fsh | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/ImplementationGuide/markdown/Einfuehrung.md b/ImplementationGuide/markdown/Einfuehrung.md index dd8044e0..2dfa8ee4 100644 --- a/ImplementationGuide/markdown/Einfuehrung.md +++ b/ImplementationGuide/markdown/Einfuehrung.md @@ -3,7 +3,7 @@ ---- Version: 2.0.8 -Datum: 14.10.2024 +Datum: 23.10.2024 Realm: Deutschland diff --git a/Resources/input/fsh/ruleset.fsh b/Resources/input/fsh/ruleset.fsh index 86209d9a..4e52d3bc 100644 --- a/Resources/input/fsh/ruleset.fsh +++ b/Resources/input/fsh/ruleset.fsh @@ -2,13 +2,13 @@ RuleSet: Meta * ^status = #active * ^experimental = false * ^publisher = "gematik GmbH" -* ^date = "2024-10-14" +* ^date = "2024-10-23" RuleSet: Meta-CapabilityStatement * status = #active * experimental = false * version = "2.0.8" * publisher = "gematik GmbH" -* date = "2024-10-14" +* date = "2024-10-23" * implementationGuide = "https://gematik.de/fhir/isik/v2/Basismodul/ImplementationGuide|2.0.8" * url = "https://gematik.de/fhir/isik/v2/Basismodul/CapabilityStatement/basis-server" From 78a6bd9208e40ca2c38a54db5a102a5e5b3f6591 Mon Sep 17 00:00:00 2001 From: f-peverali <112709306+f-peverali@users.noreply.github.com> Date: Wed, 6 Nov 2024 13:49:12 +0100 Subject: [PATCH 06/10] Feature/update extension cardinality stufe 2 (#477) * add changes of cardinality for extension * Update ImplementationGuide/markdown/ReleaseNotes.md --- .../Abrechnungsfall_AnmerkungenZuDenMustSupportFeldern.md | 2 +- ImplementationGuide/markdown/ReleaseNotes.md | 1 + Resources/input/fsh/ISiKAbrechnungsfall.fsh | 4 ++-- 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_AnmerkungenZuDenMustSupportFeldern.md index 0048e909..c62ae56f 100644 --- a/ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_AnmerkungenZuDenMustSupportFeldern.md +++ b/ImplementationGuide/markdown/Abrechnungsfall/Abrechnungsfall_AnmerkungenZuDenMustSupportFeldern.md @@ -26,6 +26,6 @@ ### `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. +**Bedeutung:** Unter `Account.coverage` SOLL der Kostenträger referenziert werden, über den der Fall abgerechnet wird. Falls bekannt, SOLL angegeben werden, in welcher Abrechnungsart die Abrechnung erfolgt. --- diff --git a/ImplementationGuide/markdown/ReleaseNotes.md b/ImplementationGuide/markdown/ReleaseNotes.md index 8dff47f9..f176304f 100644 --- a/ImplementationGuide/markdown/ReleaseNotes.md +++ b/ImplementationGuide/markdown/ReleaseNotes.md @@ -10,6 +10,7 @@ Datum: t.b.d * Schwächung der Anforderungen für Suchparameter https://github.com/gematik/spec-ISiK-Basismodul/pull/452 * Schwächung der Anforderungen für die Übernahme fremder Ressourcen (+ Konkretisierung bei Ablehnung) https://github.com/gematik/spec-ISiK-Basismodul/pull/471 +* Anpassung der Kardinalität für Account.coverage.extension:Abrechnungsart https://github.com/gematik/spec-ISiK-Basismodul/pull/477 (Backport aus Stufe 3 : https://github.com/gematik/spec-ISiK-Basismodul/pull/464) --- diff --git a/Resources/input/fsh/ISiKAbrechnungsfall.fsh b/Resources/input/fsh/ISiKAbrechnungsfall.fsh index f8e618a8..2cc2ec9c 100644 --- a/Resources/input/fsh/ISiKAbrechnungsfall.fsh +++ b/Resources/input/fsh/ISiKAbrechnungsfall.fsh @@ -26,8 +26,8 @@ Description: "Dieses Profil beschreibt die Gruppierung von medizinischen Leistun * subject contains PatientISiK 1..1 MS * subject[PatientISiK] only Reference(Patient) * coverage MS - * extension 1..1 MS - * extension contains http://fhir.de/StructureDefinition/ExtensionAbrechnungsart named Abrechnungsart 1..1 MS + * extension 0..1 MS + * extension contains http://fhir.de/StructureDefinition/ExtensionAbrechnungsart named Abrechnungsart 0..1 MS * coverage MS Instance: AbrechnungsfallAmbulant From 54fec3d27ed89a2b7c467df011d7bc3ffce697f6 Mon Sep 17 00:00:00 2001 From: f-peverali Date: Wed, 6 Nov 2024 12:49:28 +0000 Subject: [PATCH 07/10] auto-generated file update of TC version by GitHub Actions (CI FSH to FHIR Validation) --- ImplementationGuide/markdown/Einfuehrung.md | 2 +- Resources/input/fsh/ruleset.fsh | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/ImplementationGuide/markdown/Einfuehrung.md b/ImplementationGuide/markdown/Einfuehrung.md index 2dfa8ee4..8ed5f357 100644 --- a/ImplementationGuide/markdown/Einfuehrung.md +++ b/ImplementationGuide/markdown/Einfuehrung.md @@ -3,7 +3,7 @@ ---- Version: 2.0.8 -Datum: 23.10.2024 +Datum: 06.11.2024 Realm: Deutschland diff --git a/Resources/input/fsh/ruleset.fsh b/Resources/input/fsh/ruleset.fsh index 4e52d3bc..61c13094 100644 --- a/Resources/input/fsh/ruleset.fsh +++ b/Resources/input/fsh/ruleset.fsh @@ -2,13 +2,13 @@ RuleSet: Meta * ^status = #active * ^experimental = false * ^publisher = "gematik GmbH" -* ^date = "2024-10-23" +* ^date = "2024-11-06" RuleSet: Meta-CapabilityStatement * status = #active * experimental = false * version = "2.0.8" * publisher = "gematik GmbH" -* date = "2024-10-23" +* date = "2024-11-06" * implementationGuide = "https://gematik.de/fhir/isik/v2/Basismodul/ImplementationGuide|2.0.8" * url = "https://gematik.de/fhir/isik/v2/Basismodul/CapabilityStatement/basis-server" From e49151710118d08d0b052179c585507b2fe9ba34 Mon Sep 17 00:00:00 2001 From: Alexander Zautke Date: Tue, 12 Nov 2024 09:38:42 +0100 Subject: [PATCH 08/10] =?UTF-8?q?Klarstellung=20zu=20Patient.active=20aus?= =?UTF-8?q?=20Stufe=204=20=C3=BCbernommen=20(#481)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Klarstellung zu Patient.active aus Stufe 4 übernommen * update --------- Co-authored-by: f-peverali <112709306+f-peverali@users.noreply.github.com> --- .../Patient/Patient_AnmerkungenZuDenMustSupportFeldern.md | 6 +++++- ImplementationGuide/markdown/ReleaseNotes.md | 1 + Resources/input/fsh/ISiKPatient.fsh | 1 + 3 files changed, 7 insertions(+), 1 deletion(-) diff --git a/ImplementationGuide/markdown/Patient/Patient_AnmerkungenZuDenMustSupportFeldern.md b/ImplementationGuide/markdown/Patient/Patient_AnmerkungenZuDenMustSupportFeldern.md index ebc80383..9a9ce2db 100644 --- a/ImplementationGuide/markdown/Patient/Patient_AnmerkungenZuDenMustSupportFeldern.md +++ b/ImplementationGuide/markdown/Patient/Patient_AnmerkungenZuDenMustSupportFeldern.md @@ -62,6 +62,10 @@ ### Stornierung von Patienten -Im Rahmen des ISiK Basismoduls SOLLTE die Stornierung eines Patienten entweder durch das Löschen der Patienten-Ressource oder der Verwendung des Feldes `Patient.active` abgebildet werden. Dies 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. +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/ReleaseNotes.md b/ImplementationGuide/markdown/ReleaseNotes.md index f176304f..aff0d974 100644 --- a/ImplementationGuide/markdown/ReleaseNotes.md +++ b/ImplementationGuide/markdown/ReleaseNotes.md @@ -11,6 +11,7 @@ Datum: t.b.d * Schwächung der Anforderungen für Suchparameter https://github.com/gematik/spec-ISiK-Basismodul/pull/452 * Schwächung der Anforderungen für die Übernahme fremder Ressourcen (+ Konkretisierung bei Ablehnung) https://github.com/gematik/spec-ISiK-Basismodul/pull/471 * Anpassung der Kardinalität für Account.coverage.extension:Abrechnungsart https://github.com/gematik/spec-ISiK-Basismodul/pull/477 (Backport aus Stufe 3 : https://github.com/gematik/spec-ISiK-Basismodul/pull/464) +* Klarstellung zu Patient.active aus Stufe 4 übernommen https://github.com/gematik/spec-ISiK-Basismodul/pull/481 --- diff --git a/Resources/input/fsh/ISiKPatient.fsh b/Resources/input/fsh/ISiKPatient.fsh index 2a4bfd4f..df9b01f7 100644 --- a/Resources/input/fsh/ISiKPatient.fsh +++ b/Resources/input/fsh/ISiKPatient.fsh @@ -35,6 +35,7 @@ Description: "Dieses Profil beschreibt die Nutzung von administrativen Patienten * identifier.value MS * display MS * active MS + * ^comment = "Einschränkung der Übergreifenden MS-Definition: Verfügt ein bestätigungsrelevantes System nicht über die Datenstruktur zur Hinterlegung des Aktivitätsstatus einer Patienten-Ressource, so MUSS dieses System die Information NICHT abbilden. Das System SOLL jedoch den Aktivitätsstatus hart kodieren in der Patienteninstanz (Patient.active auf 'true'), sodass Clients nicht missverständlich mit einer inaktiven Patient-Ressource interagieren." * name MS * ^slicing.discriminator.type = #pattern * ^slicing.discriminator.path = "$this" From 4a636bad4f50fe3fd1add46d677332e615f3ae48 Mon Sep 17 00:00:00 2001 From: f-peverali Date: Tue, 12 Nov 2024 08:38:59 +0000 Subject: [PATCH 09/10] auto-generated file update of TC version by GitHub Actions (CI FSH to FHIR Validation) --- ImplementationGuide/markdown/Einfuehrung.md | 2 +- Resources/input/fsh/ruleset.fsh | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/ImplementationGuide/markdown/Einfuehrung.md b/ImplementationGuide/markdown/Einfuehrung.md index 8ed5f357..a75d5216 100644 --- a/ImplementationGuide/markdown/Einfuehrung.md +++ b/ImplementationGuide/markdown/Einfuehrung.md @@ -3,7 +3,7 @@ ---- Version: 2.0.8 -Datum: 06.11.2024 +Datum: 12.11.2024 Realm: Deutschland diff --git a/Resources/input/fsh/ruleset.fsh b/Resources/input/fsh/ruleset.fsh index 61c13094..030b66a0 100644 --- a/Resources/input/fsh/ruleset.fsh +++ b/Resources/input/fsh/ruleset.fsh @@ -2,13 +2,13 @@ RuleSet: Meta * ^status = #active * ^experimental = false * ^publisher = "gematik GmbH" -* ^date = "2024-11-06" +* ^date = "2024-11-12" RuleSet: Meta-CapabilityStatement * status = #active * experimental = false * version = "2.0.8" * publisher = "gematik GmbH" -* date = "2024-11-06" +* date = "2024-11-12" * implementationGuide = "https://gematik.de/fhir/isik/v2/Basismodul/ImplementationGuide|2.0.8" * url = "https://gematik.de/fhir/isik/v2/Basismodul/CapabilityStatement/basis-server" From d981f0504599ecc1b1aa9f1428715b46578bd248 Mon Sep 17 00:00:00 2001 From: f-peverali <112709306+f-peverali@users.noreply.github.com> Date: Tue, 12 Nov 2024 09:54:44 +0100 Subject: [PATCH 10/10] update releasenotes + main.yml --- .github/workflows/main.yml | 4 ++-- ImplementationGuide/markdown/ReleaseNotes.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index 7691c551..1f37f799 100644 --- a/.github/workflows/main.yml +++ b/.github/workflows/main.yml @@ -29,7 +29,7 @@ jobs: # Java and .NET are already installed on ubuntu-latest - name: Firely.Terminal (GitHub Actions) - uses: FirelyTeam/firely-terminal-pipeline@v0.4.1 + uses: FirelyTeam/firely-terminal-pipeline@v0.4.3 with: PATH_TO_CONFORMANCE_RESOURCES: Resources/fsh-generated/resources/ #PATH_TO_EXAMPLES: Examples @@ -42,7 +42,7 @@ jobs: SIMPLIFIER_PASSWORD: ${{ secrets.SIMPLIFIER_PASSWORD }} SUSHI_ENABLED: true SUSHI_OPTIONS: Resources/ - SUSHI_VERSION: 3.8.0 + SUSHI_VERSION: 3.12.0 EXPECTED_FAILS: VALIDATION_CONFORMANCE_DOTNET VALIDATION_CONFORMANCE_JAVA VALIDATION_EXAMPLES_JAVA - name: Add & Commit diff --git a/ImplementationGuide/markdown/ReleaseNotes.md b/ImplementationGuide/markdown/ReleaseNotes.md index aff0d974..445a0b5e 100644 --- a/ImplementationGuide/markdown/ReleaseNotes.md +++ b/ImplementationGuide/markdown/ReleaseNotes.md @@ -6,7 +6,7 @@ Die erste Ziffer X bezeichnet ein Major-Release und regelt die Gültigkeit von R Version: 2.0.8 -Datum: t.b.d +Datum: 12.11.2024 * Schwächung der Anforderungen für Suchparameter https://github.com/gematik/spec-ISiK-Basismodul/pull/452 * Schwächung der Anforderungen für die Übernahme fremder Ressourcen (+ Konkretisierung bei Ablehnung) https://github.com/gematik/spec-ISiK-Basismodul/pull/471