[AG-Gesundheit] eGK / ePA

[Enrico Weigelt <weigelt AT metux.de>]

* Thorsten W. <jumpfunky AT web.de> schrieb:

> Die USB-Stick Hersteller wurden geben, Geräte vorzulegen die den
> Sicherheitsanforderungen der gematik entsprechen. Wurde nicht getan.

Welche Hersteller waren das ?
Wie genau lauteten die verlangten Anforderungen ?

> 1. Ich glaube, es existieren keine Smartcards mit solch großer Kapazität
> (bin ich mir nicht sicher, müsste man mal recherchieren)

Kein Problem. Gute cryptcores gibts genug (zT. auch schon opensource), 
cpucores sind auch kein Problem und über RAMs oder die ganze 
Periphärlogik brauchen wir garnicht mehr reden, völlig langweilig.
Man muß das alles nur noch zusammensetzen und in Plastikschnipsel
gießen. Wenn man davon 'ne Million produziert, dann kostet's pro
Stück auch noch 'n paar EUR.

Bereits 1990 gabs schon (damals noch prototypisch praktisch komplette
x86-Maschinen auf Smartcard. Heutzutage hat bereits jedes halbwegs
aktuelle Billighandy ein Vielfaches der Rechenleistung. Langweilig.

> 2. Selbst wenn, sind die Prozessoren auf dieser Smartcard sehr langsam.
> Eine Verschlüsselung und Entschlüsselung wäre in annehmbarer Zeit von
> Seiten der Karte unmöglich. 

Ja, bei der billigen Massenware (im cent-Bereich).

> Entschlüsseln von Seiten der Leistungserbringer wäre ziemlich unsicher,
> da hier der private Schlüssel des Patienten die Karte verlassen müsste. 

Das ist nicht erforderlich.

> Die Sicherheitsvorkehrungen der Gesundheitskarte übertreffen die 
> von Scheckkarten und des Homebanking um längen.

Nun, das ist ja auch nicht schwer. Gegen die schon seit Jahrzehnten
überholten Scheckkarten wirkt jeder langweilige TLS-Link wie
ein Hochsicherheitstrakt.

> Führt man ein System möglichst schnell ein, und treten dann Fehler auf, 
> wird gemeckert dass man vorschnell und unüberlegt gehandelt hat.

Wie wäre es denn, wenn man erstmal eine saubere Systemarchitektur
konzipiert, _bevor_ man überhaupt ein solches Großprojekt anstößt ?

> Entschließt man sich ein System langsam, schrittweise und mit einigen 
> Testphasen einzuführen (die logischerweise zu längeren Projektlaufzeit
> führen) wird auch gemeckert und direkt gefordert, nach den vielen Fehlern 
> der ersten Testphase das System einfach aufzugeben 

Die grundlegenden Mängel ergeben sich bereits aus dem Konzept und
sind schon lange lange klar, bevor überhaupt die erste Zeile Code
geschrieben wird.

> (Das in Testphasen bei dem größten IT-Projekt in Europa Fehler auftreten 
> ist ja auch wirklich verwunderlich...)

Warum ist das Projekt eigentlich überhaupt so monströs ?!

> Das deren Standpunkt nicht mehr ganz aktuell ist, lässt sich auch daran
> erkennen, dass von der Pflichtanwendung eRezept gesprochen wird,
> dennoch: Die aktuelle Planung sieht so etwas nicht vor. 

Der CCC bezieht sich auf das Gesamtkonzept, die kleinen Häppchen,
die man im Moment an uns Verfüttert. Die Jungs+Mädls dort wissen
halt wie Politik funktioniert.

> - Manuell: 
> 
> Alle Daten müssen neu erhoben werden, die verschlüsselten Daten sind
> verloren

Wäre in einem sauberen Konzept (basierend auf einem storage-grid der 
Art Freenet oder Nebulon) nicht nötig. Man müßte lediglich von
den Ärzten die Dokumente neu einlinken lassen (in git-Terminologie:
remote-import und merge ;-o).

> - Teilautomatisiert: 
> Der Patient bewahrt ein Geheimnis oder lässt einen Treuhänder dieses für
> dich aufbewahren. Mit diesem Geheimnis lassen sich dann die Daten auf
> die neue Ersatzkarte überspielen. In diesem Rahmen werden zwei Varianten
> vorgeschlagen:

Noch einfacher: spielt den gleichen rootkey auf mehrere Karten ein.
Klar ist natürlich: der Key wird vom Patienten erzeugt und initial
eingespielt - einem Hersteller kann man hier _nicht_ vertrauen.

Ein kontrollierter Kartenwechsel (dh. die alte Karte ist noch vorhanden,
wird aber geplant ausgetauscht), kann praktisch automatisch laufen,
indem die alte Karte der neuen iterativ Zugriff auf alle Dokumente
gibt (ggf. unter Verwendung eines separaten Passworts) und die neue
Karte dann die Metadatan neu verschlüsselt.

>     - Mittels alter eGK: Alte und neue eGK werden in sicherer Umgung
> kopiert, die Daten werden umverschlüsselt
>     - Mittels Treuhänderkarte: Wie mit alter eGK, nur eben durch
> Treuhänderkarte statt alter eGK. Denkbar ist auch, dass eine eGK eines
> Freundes als Treuhänderkarte fungiert.

Wie genau soll diese "sichere Umgebung" aussehen ? 
Wer verwahrt die nötigen Keys ? Irgentjemand muß ja dann wieder
die privkeys aller Leute aufbewahren.

> - Automatisiert:
> Die Ersatzkarte kann automatisiert hergestellt werden, ohne dass der
> Patient anwesend sein muss. Zwei Verfahren sind denkbar (beide
> vereinfacht):
>          - Key-Recovery-Verfahren: Aus dem privaten Schlüssel des
> Patienten werden zusätzlich 2 Teilschlüssel erstellt. Einer erhält der
> Hersteller, einer ein Treuhänder. Geht eine Karte verloren, können die
> Patientendaten mittels beider Schlüssel entschlüsselt werden,
> anschließend umverschlüsselt werden.

Genau wie oben. Dritte haben die privkeys.

> Zu den Piraten: 
> Ein neuer Standpunkt ist wegen alten dem alten Standpunkt also nicht
> mehr möglich?

Erst wenn sich die Ausgangsbedingungen dahingehend geändert haben,
daß das defekte Systemkonzept durch ein korrektes ersetzt wurde.

> > Soll sich der Arzt tatsächlich MRT-Bilder (Größe oft mehrere 100MB) 
> > online anschauen - wie lange soll das dauern usw? 
> 
> Das sind Detailfragen, die wir hier gerne auch diskutieren können. 

Mit einem ordentlichen Storage-Grid und aktuellen Netzbandbreiten ist
das eigentlich kein Problem. Sicherlich kann es erstmal eine Weile 
dauern bis alles runtergeladen ist. Durch entsprechende Codierung
ist es auch möglich, daß zunächst nur die aktuell benötigten
Daten geladen (und der Rest ggf. später nachgeladen) wird. Aber das
ist erstmal ein von der eGK unabhängiges Implementierungsdetail,
das sich auch nachträglich noch ändern läßt.

> Ich habe mich in der Vergangenheit intensiver mit der Analyse und 
> Auswertung hochauflösender Histologie-Bilddaten (wir sprechen hier
> von 2-4 GB pro Bild) beschäftigt. Diese sind sicherlich nicht für eine
> Nutzung innerhalb der ePA geeignet.

Warum nicht ? Storage-Grids auf Petabyte-scale sind doch heutzutage
kein so großes Problem mehr.

> > Wer soll den Unterlagen suchfunktionsfähige Namen geben?
> 
> - SNOMED (Systematisierte Nomenklatur der Medizin)
> - ICD-10 (Internationale Klassifikation der Krankheiten), 
> - ICF (Internationale Klassifikation der Funktionsfähigkeit, Behinderung
> und Gesundheit ) 
> - und und und 
> können für einheitliche Bezeichnungen sorgen. Selbst die Synonyme werden
> von SNOMED unterstützt. 

Dazu könnte man ja auch noch Tagging udgl. nehmen.
Mittlerweile auch schon relativ langweilig.


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt AT metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------