Stream: german (d-a-ch)
Topic: Versiegelung von Fällen/Dokumenten
Henrik Blau (Nov 27 2019 at 14:04):
Gibt es auch schon eine Extension für die Versiegelung von Fällen oder Dokumenten, bzw. auch das temporäre Brechen oder stornieren solch eines Siegels?
Simone Heckmann (Nov 27 2019 at 14:05):
Betrifft das im Falle des Falles nur den Fall (Encounter) oder sämtliche Dokumentation, die da dran hängt...?
Henrik Blau (Nov 27 2019 at 14:06):
Der Fall ist samt aller Dokumente gesperrt. Hintergrund: Die Sperrung auch an Subsysteme (DMS, PACS,...) zu kommunizieren.
Simone Heckmann (Nov 27 2019 at 14:08):
Oha! Also würde würde man im FHIR-sprech das gesamte Compartment Encounter sperren...
Simone Heckmann (Nov 27 2019 at 14:12):
Spontan kann ich mir das jetzt nur als eine Operation vorstellen, die ein Client bei einem Server aufrufen kann, mit Fallnummer als Parameter, die auf dem Server einen Business-Logik triggert, die den Fall und alles was dran hängt, sperrt. (Vielleicht nicht alles, die interne Implementierung könnte da etwas genauer differenzieren...).
Um die Sperrung intern zu implementieren, würde ich dazu tendieren, die betroffenen Ressourcen mit einem entsprechenden Security-Flag zu versehen...
Simone Heckmann (Nov 27 2019 at 14:26):
Gibt es denn da eine konkrete Vorgabe wie so eine Fall-Sperrung aussehen soll? Wie lange dauert die Sperrung, wer darf sie wieder aufheben, mit welcher Begründung... Entscheidet das jedes System selbst, oder gibt es da eine (gesetzliche/regulatorische) Grundlagen?
Simone Heckmann (Nov 27 2019 at 14:34):
Ich frag mal die Schwarm-Intelligenz...
https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Sealing.20an.20Encounter
Henrik Blau (Nov 27 2019 at 14:35):
Die regulatorische Grundlage ist die Orientierungshilfe Krankenhausinformationssysteme (OH KIS).
Simone Heckmann (Nov 27 2019 at 14:35):
Link?
Henrik Blau (Nov 27 2019 at 14:36):
https://www.isdsg.de/sites/default/files/DGK_Hinweise_zur_Orientierungshilfe_KIS_Maerz_2014.pdf
Hängt natürlich immer von der Handhabung ab. OH KIS sagt nicht, dass dies an Subsysteme kommuniziert werden muss, Sinn macht es trotzdem.
Simone Heckmann (Nov 27 2019 at 14:50):
Kapitel 3.1?
Simone Heckmann (Nov 27 2019 at 15:23):
Einiges davon müsste man nicht an die Subsysteme kommunizieren (Entlassung, Verlegung usw. bekommen die Subsysteme ja ohnehin mit). Ich vermute, es geht also um die Implementierung von Zugriffsregeln, die an ein Event geknüpft sind, das nur das Primärsystem mitbekommt, z.B. Eingang einer Rechnung oder so ähnlich...
Es wird auch nicht genau gesagt, wie diese "Zugriffsbeschränkung" genau aussehen soll (BTG, read-only, komplett-sperrung).
Sinnvoll wäre also in der Tat eine parametrierbare Operation, bei der das jeweils zutreffende/gewünschte Security-Flag, das im Subsystem gesetzt werden soll, mitgegeben werden kann...
Jonas Schön (Nov 27 2019 at 17:21):
Hallo, wir haben vor kurzem in einem unserer Subsysteme eine Art Versiegelung umgesetzt und dabei ist der Workflow so, dass eine bestimmte Rolle die Versiegelung temporär brechen kann, dabei aber immer eine Begründung angeben muss. Mein erster Gedanke, das mit Fhir zu machen wäre jetzt, die "versiegelte" Instanz mit einer verpflichtenden Referenz auf ein AuditEvent zu versehen. Dabei müsste man aber beim AuditEvent noch ein Profil ableiten, bei dem die Beschreibung o.ä. verpflichtend ist?! Was sagen die Profis ;)
Der Workflow ist übrigens sehr ähnlich, wie die Versiegelung auch in Orbis von Agfa umgesetzt ist.
Simone Heckmann (Nov 27 2019 at 18:24):
Im Prinzip entspricht das dem "Break-The-Glass"-Protokoll.
Dafür gibt es auch ein definiertes Security-Label, das man verwenden könnte, um die Resourcen zu "versiegeln".
Henrik Blau (Nov 28 2019 at 07:52):
Ich tue mich noch schwer mit der Definition der Values in http://terminology.hl7.org/ValueSet/v3-ConfidentialityClassification.
Im Valueset http://hl7.org/fhir/valueset-security-labels.html werde ich schon eher fündig. Kann ich dieses nicht auch in Meta.Security nutzen und somit als Metainformation zum Encounter anhängen? Oder verstehe ich das falsch und muss das Meta.Security-Label an jeder einzelnen Ressource setzen?
Henrik Blau (Nov 28 2019 at 07:53):
Aber schon mal vielen Dank für den vielen Input!
Simone Heckmann (Nov 28 2019 at 10:26):
Ja, das ValueSet kann man an meta.security verwenden. Man könnte das ValueSet sogar erweitern, falls es für diesen konkreten UseCase nichts passendes gibt.
Ich denke aber schon, dass man alle Ressourcen, die versiegelt werden sollen, einzeln mit dem Flag versehen müsste. Ich wüsste sonst nicht, wie eine Access Control Engine die Regeln sonst umsetzen sollte.
Vermutlich ist es auch völlig zweitrangig, wie genau ein System intern die Versiegelung implementiert.
Für ein FHIR-natives backend würde es vermutlich tatsächlich genau so aussehen, dass alle Ressourcen im Encounter-Compartment mit dem Security-Flag versehen werden müssen, während ein anderes System, das lediglich über eine FHIR-Fassade verfügt, in der eigenen Datenbank etwas ganz anderes tut.
Andere Systeme wiederum könnten die Daten ano-/pseudonymisieren anstatt den Zugriff zu sperren...das sollte m.E. dem Subsystem überlassen sein. Die Richtlinie ist da ja maximal vage, was genau unter "Zugriffsbeschränkung" zu verstehen ist.
Viel wichtiger wäre es meines Erachtens, sich auf die Art und Weise zu einigen, wie die Aufforderung zur Versiegelung kommuniziert werden soll.
Ich wäre also durchaus offen dafür, ein entsprechende Operation zu definieren und in den Deutschen Basisprofilen zu publizieren.
Eine Notwendigkeit, das auf höherer/internationaler Ebene festzunageln sehe ich aktuell nicht, da es sich ja um die Implementierung einer deutschen Richtlinie handelt.
Frank Oemig (Nov 30 2019 at 11:30):
Deutsche Anforderungen nicht auf eine internationale Ebene zu heben war schon (und ist noch) immer ein Problem. Unsere Historie zeigt doch, dass wir mit vielen unserer Überlegungen früher dran sind als andere Länder. Nur dass diese später die gleiche Anforderungen einbringen, nur halt anders. Und dann wundern wir uns wieder, dass das "amerikanische" Standards sind.
Insofern sollten wir unsere Vorschläge als German realm core profiles abliefern, und nicht "geheim" halten.
Last updated: Apr 12 2022 at 19:14 UTC
