Für den ILF liegt der Fokus auf Kap. 6:

Implementierungsleitfaden Primärsysteme ePA für alle

Für das FK liegt der Fokus auf Kap. 3.3:

Fachkonzept elektronische Patientenakte für alle

Die Review-Kommentare können hier gespeichert werden:

Review ILF ePA für Alle - Informationen für Krankenhäuser - Confluence (gematik.de)

Claus: Ich habe nachfolgende Kommentarvorschläge für den ILF ePA

Jörg: Ich finde den prozessorientierten Ansatz sehr gut und nachvollziehbar. Insbesondere die Automatisierungslösungen finde ich sehr gut.

Einleitung:

Ein Anspruch auf Vollständigkeit bei der Abdeckung möglicher Versorgungsprozesse, in welche die ePA integriert werden sollte, besteht nicht. 

Ergänzen um: .., soll aber die Mindestanforderungen an die Umsetzung und Bedienbarkeit durchaus reflektieren (Konformität wird erwartet).

Fachlich:

Entitlement-Management (Berechtigungen): 

Wäre ein aktueller Hinweis für den LE sinnvoll, bis wann das erteilte Entitlement noch gültig ist, so dass im Falle eines später noch einzustellenden Dokuments (z.B. ein in Arbeit befindlicher Laborbefund) eine Verlängerung des Entitlements geboten erscheint? In diesem Fall müsste ein Vorhaben (z.B. die Beauftragung einer Laboranalyse mit anschließender Ergebnis-Speicherung in der ePA) bereits zu einem Vermerk in der ePA führen.

Zusammenhang zwischen Aufnahme und Behandlungskontext mit Zugriffsberechtigung ist gut gelöst, weil keine zusätzliche Aktion erforderlich ist. Es bleibt abzuwarten wie sich das in der Praxis bewährt. Hintergrund ist die Anforderung von ärztlicher Seite 10-14 Tage vor dem Krankenhausaufenthalt oder der Behandlung im Krankenhaus Akteneinsicht zu bekommen. Dies wird zur Falleinschätzung und der Terminplanung benötigt. D.h. im Moment muss die administrative Aufnahme deutlich vor dem Besuch erfolgen oder die Patientin muss die Freigabe immer noch manuell durchführen. Schöner wäre hier eine Dienst, der bei Überweisung/Einweisung den Behandlungskontext mitgibt. Dadurch lässt sich die Aufnahme und der ePA Zugriff zum frühesten Zeitpunkt etablieren.

Welche Konsequenzen haben die Vorgaben, wenn die Zugriffsberechtigung abgelaufen ist und relevante Dokumente erst danach freigegeben/archiviert werden? Dies muss ja auch zu einer Aktion führen, z.B. der postalischen Übermittlung oder der Möglichkeit einen erneuten Zugriff zu erbitten. Ich denke das sollten wir noch formulieren.

Hoch- und Runterladen von Dokumenten

Definition: Hochladen/Upload: PS → ePA, Runterladen/Download: ePA → PS

Trigger für das Hochladen frei wählbar

• Trigger manuell oder bei Archivierung oder bei "Fertigstellung des Dokuments". Hintergrund: Ein Dokument kann archiviert aber noch nicht fertig und reif für die ePA sein. Hier sind mehrere Varianten denkbar! Deshalb: Konfigurierbarkeit des PS-Verhaltens (das automatisierte Verhalten wird konfiguriert) und Möglichkeit der manuellen Steuerung (grundsätzlich oder als Unterbrechung des automatisierten Vorgangs).
• Unabhängig davon soll das Hochladen im Hintergrund laufen und die weitere Arbeit nicht unterbrechen.

Hintergrund: z.B. Arztbrief kann sich Ändern wenn er bereits erzeugt wurde und in der ePA abgelegt ist und/oder im lokalen Archivsystem liegt.

(Vorläufiger Arztbrief vs. finaler Arztbrief, unterschiedliche Workflows ) 

Runterladen von Dokumenten

• im Hintergrund

Pflicht und optionalen Dokumente

• klar festlegen welche Dokumente in die ePA müssen/können

Dokument-Einstellverpflichtung

• Ersteller eines Dokuments ist auch verpflichtet das Dokument in ePA zu schieben, es kann nicht in die Verantwortung des Empfängers liegen.

Doubletten-Verhinderung

• Es muss sichergestellt werden, dass ein Dokument nicht mehrfach (Upload bei Freigabe, Upload bei KIM-Versand, durch Empfänger) in der ePA landet.

Unterscheidung vorläufige/endgültige Dokumente

• In den Archiven liegen PDF/A Dokumente, die aber, je nach System, auch aus einem Zwischenstand abbilden können (Unterscheidung vorläufig/endgültig)

KIM ist soweit okay

Upload NFD und eMP als Dokument ist soweit okay, aber

• Zugriff auf die Dokumente über die ePA und nicht mehr auf der Karte
• Migration von der Karte zur ePA
• Lesen/Schreiben in ePA muss das PS beherrschen
• Regelung darüber wer alleiniger Daten-Master ist, Karte vs. Akte

Meta-Daten

• im System als Parameter pro Dokumententyp soweit okay
• Meta-Daten der Dokumente müssen in der Akte/Archiv des PVS/KIS übernommen werden und in den Dokumentenlisten des PVS/KIS filterbar sein
• Es ist nicht ganz klar welche Auswirkungen die Änderung von Meta-Daten haben.
  • könnte dies bitte als Anwendungsfall ausformuliert werden?
  • Umsetzungshinweise pro Meta-Datum
  • Welches System, PS oder Akte, ist Meta-Daten-Führend?

EML → wird sehr positiv eingeschätzt!

• eML als strukturiertes Objekt auch im KIS/PVs, damit die Daten weiterverarbeitet werden können
• z.B. Auswählen, rechte Maustaste → Verordnung erzeugen
• Was passiert, wenn das eRezept nicht funktioniert und ein rosa Formular ausgestellt wird.
• Was verordnet wurde ist nicht gleich dem was in der Apotheke geholt wird und dem was tatsächlich genommen wird. Wie wird damit umgegangen?

Download/Upload im Stapel

• wird nicht erwähnt
• es muss möglich sein mehrere Dokumente in einem Vorgang herunterzuladen

Hochladen

• Es ist nicht klar wie der Hash-Wert gebildet wird und wie die Eindeutigkeit darüber sichergestellt wird (evtl. Verweis hinzufügen).

Parallele Veränderung von Daten in der ePA

• theoretisch ist es möglich, dass gleiche Daten bei zwei unterschiedlichen LEI parallel geändert werden können
• gibt es da realistische Anwendungsfälle und wie wird dies dann Umgesetzt
• z.B. Prüfung des Zeitstempels der letzten Speicherung in der ePA, wenn der nicht dem gelesenen entspricht wird eine Warnung angezeigt, oder so..

Historische Führung von bestimmten Objekten

• gibt es dazu Anwendungsfälle?

Patientenportal

• Wie spielen ePA und Patientenportale zusammen? Müsste das nicht auch in dem ILF aufgenommen werden?

Synchronisation Karteikarte <-> ePA:

2 Aspekte:

• Fortzuschreibende Dokumente: Ist es gewährleistet, das fortzuschreibende MIOs, wie z.B. die eML, als das „gleiche“ Objekt, z.B. durch Namensvergleich in der ePA und der Karteikarte als zusammengehörend identifizierbar sind? Brauch es hierzu eventuell eine zusätzliche Definition wie z.B. eine Benamungskonvention? Im gegenteiligen Fall bestünde eventuell die Gefahr, das ein LE „mühsam“ vergleichen müsste was zusammen gehört.
• Missing Dokuments: Wäre es sinnvoll, einem LE „noch nicht eingestellte Dokumente“ anzuzeigen, die beim vorherigen Besuch einer anderen LEI als einzustellend geplant sind aber noch nicht eingestellt wurden (z.B. ein Laborbefund)? In diesem Fall müsste es einerseits eine Liste der vergangen LEI-Besuche für den aktuellen LE angezeigt geben, und zweitens die Liste der noch fehlenden Dokumente. Die fehlenden Dokumente könnten als Ursache für ihr Fehlen sowohl Vergesslichkeit, ein abgelaufenes Entitlement, oder ein technisches Problem haben. Für den LE sollte es daher die Möglichkeit des Nachhakens geben.

Fortlaufende eAU:

Wäre es sinnvoll, das Datum der letzten ausgestellten eAU anzuzeigen? Dann könnte der LE gleich für sich festlegen ab wann die neue, im Fall einer länger andauernden Behandlung, eAU gelten soll. Dazu müssten die eAU aus den KIM-Nachrichten exakt herauszufiltern sein.

Dokumentarisch:

Es wäre übersichtlicher wenn es eine Tabelle gäbe in der die geforderten Karteikartenmarkierungen für nicht in die ePA-eingestellten MIOs gelistet sind. 

Technisch:

Server-Zertifikats-Prüfung:

Die Prüfung der Serverzertifikate von TI-Diensten hat in der Vergangenheit zu Problemen geführt (mit teils hohen Fehler-Analysen in den KH, vor-Ort). Die Serverzertifikate-Prüfung führte zum Problem, wenn die Serverzertifikate gewechselt wurden, ohne das den prüfenden Clients die neue Zertifikatskette, die gegen die geprüft werden müsste, bekannt war. Es gibt zwei Mechanismen, mit denen Zertifikatsketten  bekannt gemacht werden. Ein PVS muss sicherheitshalber beide Möglichkeiten "können":

1. Dienst innerhalb der TI, z.B. "wahrscheinlich" ePA-FD via Konnektor/TI-Gateway: Das PS muss zyklisch oder per ge-PUSH-ter Nachricht die TSL der TI downloaden, auswerten und in seinem Zertifikatespeichers die neuen, relevanten Zertifikatsketten für die Zertifikatsprüfung verfügbar machen, oder
2. Dienst via Internet erreichbar: Der Dienst selbst, z.B. ePA-FD, sendet neben dem Serverzertifikat gleich die ganze Kette mit. Der ePA-Client im PS muss dies entsprechend verarbeiten können.

Beides ist bisher in den ILF nicht gefordert worden, spielt aber insbesondere dann, wenn wie im Falle von "ePA für Alle" der Konnektor lediglich als Router benutzt oder gänzlich umgangen wird, da ePA-CL (PS/KIS) und ePA-FD direkt via TLS miteinander kommunizieren. 

Sicherheit:

Virenprüferanschluss-Möglichkeit innerhalb des ePA-CL (PS/KIS)

Die KH, und prinzipiell auch alle anderen LEI, benötigen "Best Practice"-Schnittstellen an den ePA-CL zum Anschluss von "verbreiteten" und "etablierten" Virenscannern, so dass Dokumente das PS vom Datenfluss her erst dann erreichen, wenn sie lokal auf Viren geprüft wurden.

• Ausspezifizierung der ICAP-Schnittstelle, um den Spielraum/Variationen zu minimieren (Rückfragen beantwortet gern Sana). Unterstützt durch User-Stories von erfolgreichen und begutachteten (Blaupausen) Implementierungen. Wichtig ist, dass es für die niedergelassenen Ärzte und großen Krankenhäuser in unterschiedlichen Lösungen funktioniert.
• Das jetzige ePA-AV-Gate so wie es heute aussieht wird es vermutlich für die ePA 3.0 so nicht mehr funktionieren. Schön wäre aber, wenn die erfolgten Investitionen nicht verloren gehen, also das AV-Gate ertüchtigt wird.

Verlagerung ePA-CL in eine DMZ

Wie kann eine Architektur aussehen, die die Sicherheit in großen Organisationen unterstützt. Z.B. Verlagerung des ePA-Clients in die DMZ?

Virenschutz für Versicherte

Wie wird der Virenschutz für den Patienten aussehen? → Insbesondere Android-Handies könnten betroffen sein.

Optimierung des AV-Gates (nach Rücksprache mit der ConSol)

Aktuell ist der Einsatz des AV-Gates dadurch begründet, dass die Dokumente einer Patientenakte gebündelt in einem Response geschickt werden. Die Übertragung erfolgt via SOAP + XOP. Durch die gebündelte Übertragung ist es nicht möglich, die Übertragung einzelner schadhafter Dokumente zu unterbinden.

Aus technischer Sicht wäre es wünschenswert, wenn Dokumente jeweils über eine eigene URI bereitgestellt werden würden. Dann wäre die Integration eines AV-Scans ohne Manipulation des SOAP Responses möglich und auch mit Standart-Lösungen - z.B. ICAP - zu implementieren. Die Metadaten wären dann getrennt von den Dokumenten.

XOP https://www.w3.org/TR/xop10/

Rückfrage:

Systemüberblick -

genannte "vertrauenswürdige Ausführungsumgebung (VAU)" soll den Zugriff mittels Konnektor Fachmodul ersetzten. Der Konnektor selbst ist weiterhin für den Zugriff notwendig.

In Punkt 3.5 "SOAP" ist beschrieben, dass der Zugriff für XDS Document Service weiterhin via SOAP1.2 übertragen werden. Es ist ein BasicProfile2.0 erwähnt, zu dem ich keine weiteren Detailinformationen ausmachen konnte.

Die in Punkt 3.11.3.2 beschriebene Nutzung stimmt mit der bisherigen Beschreibung für den Empfang von Dokumenten überein. Ich erwarte daher keine technisch relevante Veränderung, die den Betrieb des AVGates einschränkt.

Maßnahmen zum Schutz von heruntergeladenen Dokumenten (A_17769 & A_17770 aus dem ILF)

Schutz von heruntergeladenen Dokumenten soll laut ILF von den Primärsystemhersteller mit geeigneten Maßnahmen sichergestellt werden. Wenn die Maßnahmen auf der Seite der Hersteller liegen, würde das den Einsatz des AV Gates seitens der Leistungserbringer überflüssig machen.

Welcher Mindeststandard ist vorgegeben? Reicht eine ICAP Schnittstelle aus dem Primärsystem, oder wird eine Lösung nach der dargelegten Beispielimplementierung (Blaupause AV Gate) gefordert?