Das eCard-API-Framework - Medizin-EDV

Ausgabe 4/2010
Fokus Dokumentenmanagement
Das eCard-API-Framework
Schlüsselkomponente bei der elektronischen Dokumentation,
Kommunikation und Archivierung
Die Autoren geben einen Überblick über die
wichtigsten Anforderungen an eine vertrauenswürdige elektronische Dokumentation, Kommunikation und Archivierung im
Gesundheitswesen und beschreiben, wie diese Anforderungen auf Basis des eCard-APIFrameworks umgesetzt werden können.
Bei der vertrauenswürdigen elektronischen
Dokumentation, Kommunikation und Archivierung im Gesundheitswesen spielt die
sichere Authentisierung, Verschlüsselung
und Elektronische Signatur eine wesentliche Rolle. Für genau diese Zwecke wurde
vom Bundesamt für Sicherheit in der Informationstechnik mit dem eCard-APIFramework [BSI-TR03112] im Einklang mit
internationalen Standards ein Rahmenwerk geschaffen, das in Form eines kostenlosen „Bürgerclients“ zur Verfügung
steht und die Integration der Elektronischen Signatur in unterschiedliche Anwendungen signifikant erleichtern wird.
Darüber hinaus kann dieses Rahmen werk bei der vertrauenswürdigen Langzeitarchivierung [BSI-TR03125] genutzt
werden, damit die Beweiskraft von qualifizierten elektronischen Signaturen langfristig bewahrt werden kann.
Rechtliche Rahmenbedingungen
der Dokumentation, Kommunikation und Archivierung
ansprüche von Patienten empfiehlt es sich,
alle Dokumentationen (Dokumente, Bilder,
Signale, Filme etc.) in der Regel 30 Jahre aufzubewahren, auch wenn verschiedene Verordnungen kürzere Aufbewahrungsfristen
vorgeben (z. B. Ärzteverordnung 10 Jahre,
Röntgenverordnung 10 Jahre bei Diagnostik).
l
Bei dem Zugriff auf die Dokumentationen und deren Weiterleitung sind die hochkomplexen Anforderungen des Datenschutzes zu berücksichtigen. Zugreifen dürfen
grundsätzlich nur Ärzte, Therapeuten, Pflegekräfte etc., wenn Sie direkt an der Behandlung beteiligt sind oder waren.
l
Eine qualifizierte elektronische Signatur – vorzugsweise mit Anbieterakkreditierung – ist für die elektronisch erzeugten Dokumente unabdingbar, die aufgrund
gesetzlicher Regelungen eine Schriftform erfordern. Zusätzlich empfiehlt das Competence Center für die Elektronische Signatur im
Gesundheitswesen (CCESigG), für Dokumente zur externen Verwendung und für interne
Dokumente mit besonders hohem Beweiswert (z. B. Arztbrief) eine qualifizierte elektronische Signatur mit Anbieterakkreditierung, für die Dokumente externer Einsender
einen qualifizierten Zeitstempel und für die
sonstigen Dokumente geeignete Authentifizierungsverfahren zu verwenden.
Aus den rechtlichen Rahmenbedingungen ergeben sich hohe Anforderungen an den Datenschutz, die Beweissicherheit und die IT-Sicherheit.
l
Zur Sicherstellung des Datenschutzes
werden mächtige Zugriffsberechtigungskonzepte in Abhängigkeit von der Rolle des Arztes, der Organisationseinheit, der Programmfunktion und dem Zeitpunkt der
Behandlung benötigt, verbunden mit starken
Mechanismen zur Authentisierung.
l
Elektronisch erzeugte Dokumente müssen mit elektronischen Signaturen versehen
werden können. Für den Beweiswerterhalt
muss später eine Nachsignatur möglich sein,
da die benutzten kryptographischen Algorithmen mit der Zeit ihre Sicherheitseignung
verlieren können.
l
Zumindest für die einrichtungsübergreifende Kommunikation und zentrale Archive ist eine Verschlüsselung unabdingbar.
l
Der Betrieb der elektronischen Dokumentations-, Signatur- und Archivierungssysteme muss nach dem Stand der Technik
durch Umsetzung allgemein anerkannter Regelungen und Normen (z.B. ISO 27001, BSI)
abgesichert werden.
Umsetzung mit dem
eCard-API-Framework
Wie in Abbildung 1 dargestellt, können die
für die Dokumentation, Kommunikation
und Archivierung relevanten Funktionen
des eCard-API-Frameworks (Technische
Richtlinie 03112 des BSI) den oben genannten funktionalen Anforderungen (Ver-
Wesentliche Rahmenbedingungen sind die
Dokumentationspflicht, die Aufbewahrungsfristen, der Datenschutz und die Beweissicherheit.
l
Der Arzt ist aufgrund standesrechtlicher und gesetzlicher Regelungen verpflichtet, sein diagnostisches und therapeutisches
Handeln vollständig, verständlich, korrekt,
nachvollziehbar und zeitnah zu dokumentieren (Dokumentationspflicht). Dabei gibt es
Dokumentationen, die wegen rechtlicher Vorgaben mit einer Unterschrift bzw. einer qualifizierten elektronischen Signatur versehen
werden müssen (z.B. Untersuchungen mit
ionisierenden Strahlen, Gutachten, Überweisungen, verschreibungspflichtige Medikationen). Zur möglichen Abwehr der Haftungs-
18
Abbildung 1: Relevante Funktionen des eCard-API-Frameworks
Fokus Dokumentenmanagement
Ausgabe 4/2010
Authentisierungsprotokolle, die die VerifyUser-Funktion im Terminal-Layer nutzen,
um eine sichere PIN-Eingabe und/oder
Erfassung von biometrischen Merkmalen
zu realisieren.
Beweiswerterhalt kryptographisch
signierter Daten
Abbildung 2: Referenzmodell für den Beweiswerterhalt signierter Daten
schlüsselung, elektronische Signatur
und Authentisierung) zugeordnet werden.
Verschlüsselung
Wie aus der Abbildung 1 ersichtlich, existieren für die Ver- und Entschlüsselung im
anwendungsnahen eCard-Interface die auf
dem internationalen OASIS DSS-Standard
basierenden Funktionen EncryptRequest
und DecryptRequest, mit denen binäre oder
XML-basierte Dokumente und Daten verschlüsselt werden können. Sofern die Veroder Entschlüsselung durch ein Hardwaretoken erfolgt, werden die in ISO/IEC
24727-3 standardisierten Funktionen Encipher bzw. Decipher verwendet, die ihrerseits die Transmit-Funktion aus ISO/IEC
24727-4 aufrufen.
Elektronische Signatur
In ähnlicher Form enthält das eCard-Interface die von OASIS standardisierten
Funktionen SignRequest und VerifyRequest,
mit denen qualifizierte elektronische Signaturen und Zeitstempel erzeugt und geprüft werden können. Hierbei kann im Aufruf von SignRequest [BSI-TR03112]
angegeben werden, welcher Signatur- oder
Zeitstempel-Typ erzeugt und wie die Signatur im Detail gestaltet werden soll.
Für die Erzeugung einer elektronischen
Signatur greift der Identity Layer auf die
Funktionen Sign und Hash aus dem Service
Access Layer zu, die ihrerseits die Transmit-
Funktion aus dem Terminal Layer nutzen.
Beim Prüfen von elektronischen Signaturen ist typischerweise nur der Identity Layer involviert, da bei der Prüfung von elektronischen Signaturen in der Regel nicht auf
eine Hardwaretoken zugegriffen werden muss.
In der Funktion VerifyRequest wird dem
eCard-API-Framework eine Folge von Dokumenten und/oder Signaturen übergeben,
und man erhält einen standardisierten XMLbasierten Verification Report zurück, der alle für die Gültigkeit einer qualifizierten elektronischen Signatur relevanten Informationen
und Prüfergebnisse enthält.
Authentisierung
Für Zwecke der Authentisierung existiert
im Service Access Layer des eCard-APIFrameworks die generische DIDAuthenticate-Funktion, die mit beliebigen Authentisierungsprotokollen instantiiert
werden kann. Dadurch können sowohl
einfache Challenge-Response-Protokolle
als auch sehr komplexe Authentisierungsprotokolle in einfacher Weise genutzt werden. Beispielsweise können hierdurch die im Gesundheitswesen sehr
wichtigen Card-to-Card-Authentisierungsprotokolle zwischen der elektronischen Gesundheitskarte und dem Heilberufsausweis oder das Extended Access
Control-Protokoll des neuen Personalausweises in einfacher Weise genutzt werden. Auch für die lokale Benutzerauthentisierung existieren verschiedene
Während das eCard-API-Framework bereits alle für die vertrauenswürdige Langzeitarchivierung notwendigen Basisfunktionen enthält und eine Anwendung selbst
(z. B. unter Verwendung der {C,X}AdESSignaturformate) für die in § 17 SigV geforderte Nachsignatur sorgen könnte, so
empfiehlt es sich, die regelmäßige Nachsignatur an eine spezifische Middlewarekomponente zu delegieren, die zwischen
Anwendung, eCard-API-Framework und
Langzeitspeicher vermittelt. In der TR 03125
des BSI [BSI-TR03125] wurde ein Referenzmodell für eine solche Komponente
entwickelt, durch die der Beweiswert von
kryptographisch signierten Dokumenten
und Daten über einen sehr langen Zeitraum erhalten werden kann. Wie in Abbildung 2 dargestellt, besteht die Referenzmodell aus den folgenden Modulen:
l
Das ArchiSafe-Modul nimmt die Archivanfragen der Geschäftsanwendungen entgegen und steuert die wesentlichen Abläufe
im Archiv, indem das ArchiSig-Modul oder
der Langzeitspeicher angesprochen werden.
l
Das ArchiSig-Modul verwaltet die
Merkle-Hashbäume [Merk80] zu den registrierten Archivdatenobjekten, fordert bei Bedarf über das Krypto-Modul qualifizierte
Zeitstempel gemäß RFC 3161 an und erzeugt
auf Anforderung technische Beweisdaten
gemäß RFC 4998.
l
Das Krypto-Modul kann auf Basis des
eCard-API-Frameworks realisiert werden
und ist zumindest in der Lage, Hashwerte zu
berechnen sowie Signaturen und Zeitstempel samt der zugehörigen Zertifikatsketten
zu prüfen. Außerdem können qualifizierte
Zeitstempel bei einem Zertifizierungsdiensteanbieter (ZDA) angefordert werden.
Im Langzeitspeicher werden schließlich
die Archivdatenobjekte abgelegt und können bei Bedarf dort wieder ausgelesen oder
– z.B. nach Ablauf der Aufbewahrungsfrist
– gelöscht werden.
Zusammenfassung und Ausblick
In diesem Beitrag wurden die wesentlichen
rechtlichen und funktionalen Anforde-
19