Inhaltsverzeichnis
Elektronische Patientenakte (ePA)
Abgrenzung zur Primärdokumentation
Primärdokumentation | ePA |
---|---|
Leistungserbringer-geführt | Versicherten-geführt |
Im Primärsystem / LE-Umgebung | Angebot der Krankenkassen |
Behandlungsdokumentation | Verfügbarkeit von Daten für Versicherten Kein Ersatz der Behandlungsdokumentation! |
Gesetzl. Befugnis zur Datenverarbeitung (§ 22 Abs. 1 Nr. 1 lit. b BDSG) Dokumentationspflicht (§ 630f Abs. 2 BGB Aufbewahrungspflicht (§ 630f Abs. 3 BGB | Verfügbarkeit von Daten für Versicherten |
Das bedeutet auch:
- Übernahme von Daten aus der ePA in die Primärdokumentation, wenn erforderlich.
- Übernahme von Daten aus Primärdokumentation in ePA, wenn von Patient:innen gewünscht.
Weiterentwicklung/Roadmap
Statt einer Spezifikation für die ePA 3.0 wird nun zunächst eine Spezifikation für eine Version ePA 2.5 erarbeitet. Im Prinzip handelt es sich um die um die Integration der Anwendungen „Elektronischer Medikationsplan online“ (eMP online) und „Elektronische Patientenkurzakte“ (ePKA) abgespeckte ePA 3.0.
Das Go-Live der ePA 2.5 ist für 1.1.2023 geplant, die ePA 3.0 zunächst für 15.12.2023.
Das ePA-Aktensystem soll wohl zu einer Aktensystem-Plattform weiterentwickelt werden, auf der dann andere Anwendungen wie eMP oder ePKA aufsetzen können. Die beiden Anwendungen werden dann getrennte Anwendungskontexte der Aktensystem-Plattform sein.
Zudem stellt sich die Frage, ob und wie (ab wann) sich die ePA von einem dokumentenorientierten zu einem datenorientierten System („persönlicher Gesundheitsdatenraum“) wandelt.
ePA 2.5
- Features
- MIOs
- DiGA-Toolkit
- Pflegeüberleitungsbogen
- Telemedizinisches Monitoring
- Weitere IO
- eAU
- DMP
- Neue Nutzergruppen
- DiGA-Hersteller
ePA 2.5.2
- Features
- Neue Nutzergruppen
- Forschung
ePA 2.6
- Features
- IdP-Nutzung für die ePA (al.vi 2.0)
- Umgang mit Bilddaten
- Automatisiertes E-Rezept-Zusammenspiel
- Papierkorb
- Umschlüsselung Stufe 2
- Anbindung Organspenderegister
- MIOs
- Laborbefund
- Überleitungsbogen chronische Wunde
- eBildbefund
- Krankenhausentlassbrief
- Pflegeüberleitungsbogen (1.4.2024)
- Telemedizinisches Monitoring?
- Neue Nutzergruppen
- Pflege
Features ePA 3.0
- eMP online als Plattformfunktionalität
- ePKA als Plattformfunktionalität
- TIM-Anbindung
- Weitere IO
- eMP
- ePKA
Sanktionen Ärzt:innen
Wie das Bundesgesundheitsministerium (BMG) der Bundesärztekammer (BÄK) bestätigte, sollen die Sanktionen nicht gelten, wenn die notwendigen und von der Industrie zugelassenen Komponenten vor dem 1. Juli 2021 von Vertragsärzt:innen bei einem oder mehreren Anbietern bestellt werden.1)
Inhalte der ePA
Architektur der ePA
Verschlüsselungsmechanismus der ePA
Erzeugung des symmetrischen Aktenschlüssel (AES-256) beim initialen Anlegen des Aktenkontos in den dezentralen Komponenten (notwendiger Aktivierungsschritt beim LE oder im FdV, nach der Eröffnung bei Krankenkasse) und für den Versicherten SGD-verschlüsselte Speicherung des Aktenschlüssels im HSM der Autorisierungskomponente
- Generierung eines zufälligen, symmetrischen Dokumentenschlüssels in den dezentralen Umgebungen
- Verschlüsselung des Dokumentenschlüssels mit dem Aktenschlüssel (Löschen Dokumentenschlüssel lokal)
- Beifügung des verschlüsselten Dokumentenschlüssels zum Dokument (als AuthorizationKey)
- Speicherung dieses „Verschlüsselungspaket“ als „Dokument“ in der Komponente „Dokumentenverwaltung“ des Aktensystems
Verschlüsselung des Aktenschlüssels (im Rahmen der Berechtigungsvergabe) für jeden Zugriffsberechtigten nacheinander mit zwei symmetrischen Schlüsseln des SGD. Errechnung der beiden SGD-Schlüssel auf Basis der bestätigten Merkmale KVNR bzw. Telematik-ID aus einem geheimen Ableitungsschlüssel (Mastersecret/Masterkey ⇒ ändert sich halbjährlich) / Die KVNR kommt von der eGK des Versicherten, die TID bekommt der Versicherte aus den öffentlichen Zertifikaten des LE aus dem VZD. Die Keys besorgen sich die Clients bei der Ver-/Entschlüsselung nach der Authentisierung mittels eGK/al.vi direkt von den beiden SGDs. Speicherung des so verschlüsselten Aktenschlüssels im HSM der Komponente Autorisierung des Aktensystems
Die Berechtigungsschlüssel (symmetrische AES-256-Bit-Schlüssel) werden von zwei Schlüsselgenerierungsdiensten (SGD) für die jeweils authentisierte eGK, al.vi-Identität, SMC-B(/-KTR) generiert, einem fachanwendungsspezifischen (SGD 1) und einem zentralen (SGD 2). Letzterer gehört zu den zentralen Diensten der TI. Vor der Speicherung durch den Fachdienst werden die Daten vom Client (FdV bzw. Konnektor) mit dem Schlüssel des SGD 1, dann das Chiffrat mit dem Schlüssel des SGD 2 verschlüsselt. Auf diese Weise ist sichergestellt, dass die Daten weder von der TI-Plattform noch vom Anbieter des Fachdienstes entschlüsselt werden können. Zudem lassen sich trotz Verlust des privaten asymmetrischen Schlüssels (der eGK, al.vi-Identität, SMC-B(/KTR) individuell für einen Benutzer verschlüsselte Daten widerherstellen, ohne dass ein Ersatzschlüssel (ggf. treuhänderisch) sicher aufbewahrt oder bei Bedarf z.B. aus geteilten Geheimnissen erzeugt werden müsste.4)
Die Metadaten und technische Daten (Inhalte des Zugriffsprotokolls und Policy Document als Summe aller vom Versicherten vergebenen Zugriffsberechtigungen auf Datenobjekte in der Komponente Dokumentenverwaltung) eines Aktenkontos werden ebenfalls verschlüsselt abgelegt. Die Verschlüsselung erfolgt mittels eines sogenannten Kontextschlüssels. Dieser wird beim Start einer Aktenkonto-Session in die VAU eingebracht, in der Metadaten und andere technische Daten über den sog. Verarbeitungskontext verarbeitet werden können. Auf die sensiblen Daten des Verarbeitungskontextes kann nur von Berechtigten zugegriffen werden, die über das kryptografische Material verfügen. Beim Beenden der Sitzung wird der Kontextschlüssel wieder aus dem Arbeitsspeicher der VAU gelöscht. Das Prinzip ist mit einer virtuellen Festplattenverschlüsselung vergleichbar. Auch der Kontextschlüssel wird initial beim Aktivieren eines Aktenkontos erzeugt und mit den SGD-Schlüsseln für die Zugriffsberechtigten verschlüsselt abgelegt.
Anders bei der VAU des E-Rezept-Fachdienstes. Die symmetrischen Schlüssel zur verschlüsselten Persistierung der E-Rezepte werden in einem HSM in der VAU abgeleitet. Es gibt keine Kontextseparierung, da Versicherte keinen schreibenden Zugriff haben, d.h. der versichertenindividuelle Kontextschlüssel entfällt und ein Sandboxing der verarbeiteten Daten verschiedener Versicherter während des Betriebs ist nicht notwendig.
Kritik an VAU-Konzept/-Implementierung
- SGX-Exploits: https://downfall.page/media/downfall.pdf
Metadaten
Quellen:
- [gemSysL_ePA#2.5.1.3] f.
- [gemSpec_DM_ePA]
Die Dokumentenverwaltung der ePA basiert auf dem Registry-Repository-Designmuster des XDS.b-Profiles gem. der ITI-Implementierungsstrategie der IHE. Metadaten und Dokumenteninhalte sind entkoppelt.
Verpflichtende Metadaten:
- Autor (gem. IHE-ITI-TF Vol. 3, 4.2.3.2.1)
- Name des Autors (gem. [gemSpec_DM_ePA#2.1.4.3.4])
- Institution des Autors (gem. [gemSpec_DM_ePA#2.1.4.3.5])
- Dokumentenklassifizierung (gem. [gemSpec_DM_ePA#2.1.4.1.1])
Sicherheit
Dateitypen, die Schadsoftware enthalten könnten (Word, Excel, PPT und ZIP) sind explizit ausgeschlossen, wobei eine inhaltliche Prüfung durch das ePA-Aktensystem aufgrund der Verschlüsselung nicht stattfinden kann. Die Dokumentenverwaltung der ePA überprüft die Gültigkeit des Dateityps daher ausschließlich auf Basis der Metadaten. Anfang 2021 gelang es der c't dem Aktensystem den Dateityp „text/plain“ für eine ZIP-Datei vorzutäuschen5) und auf diese Weise eine solche mittels ePA-App der TK einzuschleusen, da auch die TK-App keine Typprüfung durchführte, sondern lediglich eine Prüfung auf Basis der Metadaten. Für Primärsysteme adressiert der Implementierungsleitfaden diesen Fall und fordert Maßnahmen nach einer Plausibilitätsprüfung durch die Primärsysteme.6) Praxen sollten allerdings darüber hinaus stets die Hinweise und Empfehlungen zum sicheren Betrieb (bspw. des BSI) und die IT-Sicherheitsrichtlinie der KBV beachten und umsetzen.
TODO: Afos an FdV geben eigentlich keien Typprüfung her!, Verlinkung KBV-Sicherheitsrichtlinie
Forschungsdaten
Nach § 363 Abs. 7 SGB V sollen durch Rechtsverordnung des BMG Einzelheiten geregelt werden. Hier scheint ein Gremium vorgesehen zu sein, dass zusammengerufen wird, wenn neue bzw. aktualisierte MIOs veröffentlicht werden. Bisher sollen nach vorliegenden Informationen in dem Gremium vertreten sein:
- gematik
- GKV-SV
- AG Versorgungsdaten des FZD
- KBV.
Das Feature Datenfreigabe zu Forschungszwecken ist Teil der ePA-Version 2.5. Es scheint festgelegt zu werden, dass als Datensätze nur MIOs an das Forschungszentrum übermittelt werden können. Die Pseudonymisierung erfolgt über eine Schablone, die Felder mit Personenbezug ausklammert.
Literatur:
Technische Umsetzung
Erste Erkenntnisse zur Umsetzung liefert das Pilotprojket PrETTI (Privacy Enhancing Technologies in der Telematikinfrastruktur), eine Kooperation der gematik mit IBM und der Uni Mannheim (Lehrstuhl Prof. Dr. Frederik Armknecht). Professor Armknecht entwickelte hierbei die Backend-Systeme zum datenschutzfreundlichen Machine Learning Verfahren, IBM Consulting passte die ePA-Oberfläche für Versicherte (ePA-Frontend des Versicherten) an. Die Einsatzmöglichkeiten in der TI sollen nun evaluiert und zusammen mit weiteren Partnern ausgebaut werden.7)
Fristen und Sanktionen
- Krankenkassen sind zum 1.1.2021 verpflichtet, den Versicherten eine ePA zur Verfügung zu stellen. Zudem sind die für die Folgestufen definierten Anforderungen zu den jeweiligen Terminen ebenfalls fristgerecht zu erfüllen.9)
- An der vertragsärztlichen Versorgung teilnehmende Leistungserbringer müssen die erforderlichen Komponenten für die ePA bis zum 30.6.2021 gegenüber ihrer KV nachweisen, andererseits erfolgt die pauschale Kürzung der Vergütung vertragsärztlicher Leistungen um 1 Prozent.10) Zu den erforderlichen Komponenten zählen:
- TI-Anschluss
- Konnektor-Update auf (mindestens) PTV 4
- Primärsystemmodul ePA
- eHBA (technisch nicht benötigt, aber rechtlich wegen § 339 Abs. 3 SGB V)
- Die Verpflichtung zur Unterstützung der ePA im Krankenhaus greift ab 1.1.2021.11) Eine gesetzliche Sanktionierung von 1 Prozent des Rechnungsbetrags für jeden voll- und teilstationären Fall ist für Krankenhäuser vorgesehen, die zum 1.1.2022 die notwendigen Voraussetzungen für die TI und damit ePA im Krankenhaus noch nicht geschaffen haben.12)
Finanzierung
Praxen Ärzt:innen und Psychotherapeut:innen
Quelle: Vereinbarung zur Finanzierung und Erstattung der bei den Vertragsärzten entstehenden Kosten im Rahmen der Einführung und des Betriebes der Telematikinfrastruktur gemäß § 378 Absätze 1 und 2 SGB V vom 14. Dezember 2017 (Anlage 32 zum Bundesmantelvertrag-Ärzte (BMV-Ä)). (= TI-Finanzierungsvereinbarung)
Vergütung
Praxen Ärzt:innen und Psychotherapeut:innen
Seit 9.9.2021 rückwirkend zum 1.1.2021 sind die Regelungen für die Erstbefüllung im Detail festgelegt.15)
s. auch KBV-Seiten sowie den Beschluss des Bewertungsausschusses vom 17.2.2021.
- Zusatzpauschalen für die ePA-Unterstützungsleistung:
Für 2023 wurde die extrabudgetäre Vergütung verlängert.(vgl. Beschluss des GB-A und Infoseiten der KBV.))
Auch für 2024 beschließt der Bewertungsausschuss eine unveränderte Verlängerung der extrabudgetär vergüteten Gebührenpositionen 01648 für die Erstbefüllung, die für die aktuelle Behandlung relevant ist (89 Punkte = 10,23 €) vorerst bis zum 1. Januar 2025. Abrechenbar ist die Position ein mal pro Patient, d.h. im Ärzt*innen sollten vor der Erstbefüllung prüfen, ob bereits Einträge von anderen Ärzten, Psychotherapeuten oder Zahnärzten vorgenommen wurden. Dann ist die GOP 01648 nicht berechnungsfähig, sondern anstelle dessen die reguläre Zusatzpauschale für die ePA-Unterstützungsleistung nach der GOP 01647 (15 Punkte, 2023: 1,72 Euro).17)
Q&A
Kann man einfach ein Tablet mit einem FdV (ePA-App des Versicherten) in eine Arztpraxis oder eine Geschäftsstelle der Krankenversicherung „hinlegen“, um auch Menschen, die kein Smartphone besitzen, eine (feingranulare) Berechtigungsvergabe für ihre ePA-Dokumente zu ermöglichen? Nein. Die App (bzw. das FdV) ist an das Gerät gebunden, was durch eine Codeeingabe jeweils bestätigt werden muss. Für das erste Gerät, dass in Betrieb genommen wird, muss zudem eine Identifizierung (bspw. über Post- oder Video/Robo-Ident) erfolgen. Man müsste auf eine Webbrowser-Lösung ausweichen, die aber auch nicht besonders geeignet sind für sichere Lösungen auf einem öffentlich zugänglichen PC/Gerät.