Anhang

Transcription

Anhang

Erarbeitung einer Strategie zur Einführung
der Gesundheitskarte
Anhang zu
Solution Outline - Skizzierung der Lösungsarchitektur
und Planung der Umsetzung
Für das Bundesministerium
für Gesundheit
und Soziale Sicherung
Von der IBM Deutschland GmbH
unterstützt durch die Firmen

Fraunhofer-Institut für Arbeitswirtschaft und Organisation

SAP Deutschland AG & Co. KG

InterComponentWare AG

ORGA Kartensysteme GmbH
Version 1.0 vom 9. Juli 2004
© 2004
Projektgruppe bIT4health
Seite 1 von 112
Inhaltsverzeichnis
1
Einleitung _____________________________________________7
2
Architekturentscheidungen ______________________________8
2.1
Architekturentscheidungen des Planungsauftrags _______________________8
2.2
Architekturentscheidungen der Rahmenarchitektur _____________________17
1.1.1
1.1.2
1.1.3
2.3
Architekturentscheidungen des Solution Outline _______________________47
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
2.3.7
3
Allgemein___________________________________________________________ 17
Informationsmodell ___________________________________________________ 26
Sicherheitsinfrastruktur ________________________________________________ 34
Dezentrale Komponenten ______________________________________________ 47
Zentrale Komponenten ________________________________________________ 51
Anwendungen _______________________________________________________ 56
Sicherheitskomponenten _______________________________________________ 60
Kartenproduktion und Kartenpersonalisierung ______________________________ 78
Bereich Kartenproduktion und Kartenpersonalisierung ________________________ 87
Komponentenliste Netze und IT-Infrastruktur _______________________________ 91
Netze und IT Infrastruktur – Berechungen _________________98
3.1
Serverkomponenten _______________________________________________98
3.1.1
3.1.2
3.1.3
1.1.4
3.1.4
3.2
Herleitung der Maschinenkonfigurationen der IT-Infrastruktur __________________ 98
Endausbaustufe IT-Konfiguration _______________________________________ 102
Maschinenkonfigurationen Produktions- und Rückfall-Datacenter ______________ 104
Maschinenkonfigurationen Staging Umgebung_____________________________ 105
Maschinenkonfiguration Entwicklungsumgebung und Testtreiber_______________ 106
Netzkomponenten ________________________________________________108
Literatur _______________________________________________112
© 2004
Seite 2 von 112
Tabellenverzeichnis
Tabelle 1: Architekturoption und notwendige Entscheidung AE-E1 Migrationspfad _______________ 8
Tabelle 2: Architekturoption und notwendige Entscheidung AE-E2: Aufteilung der Rahmenarchitektur 9
Tabelle 3: Architekturoption und notwendige Entscheidung AE-E3: Gestufte Sicherheitszonen ____ 10
Tabelle 4: Architekturoption und notwendige Entscheidung AE-E4: Aufgaben und Abgrenzung der
Sicherheitsinfrastruktur ____________________________________________________ 11
Tabelle
5:
Architekturoption
und
notwendige
Entscheidung
AE-C1:
Wechsel
von
Sicherheitsalgorithmen ____________________________________________________ 13
Tabelle 6: Architekturoption und notwendige Entscheidung AE-C2: Zusammenfassung einheitlicher,
übergreifender Komponenten _______________________________________________ 13
Tabelle 7: Übersicht der erforderlichen Aktivitäten zur Einführung der Telematikplattform_________ 14
Tabelle 8: Wesentliche Architekturentscheidungen der Rahmenarchitektur____________________ 17
Tabelle 9: Architekturentscheidung zu Systemgrenzen der Telematikinfrastruktur und der Integration
existierender Systeme _____________________________________________________ 18
Tabelle 10: Architekturentscheidung zu den Aufgaben der Telematikinfrastruktur _______________ 19
Tabelle 11: Architekturentscheidung zur Patientenorientierung und Datenhoheit _______________ 19
Tabelle 12: Architekturentscheidung zum Datenschutz ___________________________________ 20
Tabelle 13: Architekturentscheidung zur Nutzung von Karte und Server als Speicherort__________ 21
Tabelle 14: Architekturentscheidung zur Berücksichtigung und Verwendung erprobter Konzepte und
Lösungen _______________________________________________________________ 22
Tabelle
15:
Architekturentscheidung
zur
Migrationsfähigkeit
und
Skalierbarkeit
der
Telematikinfrastruktur _____________________________________________________ 23
Tabelle 16: Architekturentscheidung zur Aufteilung der Telematikinfrastruktur in abgegrenzte
Teilbereiche _____________________________________________________________ 23
Tabelle 17: Architekturentscheidung zur Karten- und Einführungsstrategie der eGK _____________ 25
Tabelle 18: Architekturentscheidung: Zweistufige Aufteilung der Zugriffskontrollfunktion__________ 26
Tabelle 19: Architekturentscheidung: Authentisierung zwischen HBA und eGK_________________ 27
Tabelle 20: Architekturentscheidung: Festlegungen der Eigenschaften der PIN ________________ 28
Tabelle 21: Architekturentscheidung: Autorisierung des Zugriffs auf die freiwilligen Anwendungen
durch Vertreter und Vertreter-PIN ____________________________________________ 29
Tabelle 22: Architekturentscheidung: Übertragung und Zwischenspeicherung von medizinischen
Daten durch die bIT4Health Dienste __________________________________________ 31
Tabelle 23: Architekturentscheidung: Schutz aller Sicherheitsobjekte der eGK _________________ 32
Tabelle 24: Architekturentscheidung: Zugriff auf das Karten- und Keymanagement der eGK von einer
(und nur einer) der Karte zugeordneten Stelle___________________________________ 33
Tabelle 25: Architekturentscheidung Sicherheitsarchitektur nach ISO 7498-2 __________________ 34
Tabelle 26: Architekturentscheidung Aufgaben und Abgrenzung der Sicherheitsinfrastruktur _____ 35
Tabelle 27: Architekturentscheidung Benutzerbestimmbare Informationsflusskontrolle, BISS ______ 35
Tabelle 28: Architekturentscheidung Identitätsverwaltung _________________________________ 37
Tabelle 29: Architekturentscheidung Authentifizierungsdatenverwaltung ______________________ 37
Tabelle 30: Architekturentscheidung Authentifizierungsschnittstelle__________________________ 38
© 2004
Seite 3 von 112
Tabelle 31: Architekturentscheidung Zweistufige Aufteilung der Zugriffskontrollfunktion __________ 38
Tabelle 32: Architekturentscheidung Wechsel von Sicherheitsalgorithmen ____________________ 39
Tabelle 33: Architekturentscheidung eGK/HBA-Authentifizierung ___________________________ 40
Tabelle 34: Architekturentscheidung Card2Application-Authentifizierung______________________ 40
Tabelle 35: Architekturentscheidung Applicaton2Server-Authentifizierung_____________________ 41
Tabelle 36: Autorisierungsmechanismen ______________________________________________ 41
Tabelle 37: Architekturentscheidung Vertraulichkeit ______________________________________ 42
Tabelle 38: Architekturentscheidung Datenintegrität______________________________________ 43
Tabelle 39: Architekturentscheidung Nicht-Abstreitbarkeit _________________________________ 43
Tabelle 40: Ver- und Entschlüsselungsmechanismen ____________________________________ 43
Tabelle 41: Zeitstempel____________________________________________________________ 44
Tabelle 42: Integritätsprüfung _______________________________________________________ 44
Tabelle 43: Digitale Signatur ________________________________________________________ 45
Tabelle 44: Architekturentscheidung Sicherheitszonen ___________________________________ 45
Tabelle 45: Architekturentscheidung Speicherung Sicherheitsobjekte ________________________ 46
Tabelle 46: Architekturentscheidung bIT4health Connector Deployment ______________________ 47
Tabelle 47: Architekturentscheidung Bereitstellung der bIT4health Anwendungen über eine
standardisierte Dienstschnittstelle ____________________________________________ 48
Tabelle
48:
automatische
und
verteilte
Aktualisierung
der
Anwendungskomponenten durch den bIT4health Connector _______________________ 48
Tabelle
49: Architekturentscheidung Kommunikation zwischen Primärsystemapplikation und
bIT4health Connector primär im Pull-Verfahren _________________________________ 49
Tabelle 50: Architekturentscheidung SDK nicht Teil der Lösungsarchitektur ___________________ 49
Tabelle
51: Architekturentscheidung Kommunikation zwischen bIT4health Connector und
Kartenterminals über abstrakte Schnittstelle ____________________________________ 50
Tabelle 52: Architekturentscheidung Definition der Kartenterminals auf der Basis des TeleTrust e.V.
(MKT, V1.0) _____________________________________________________________ 50
Tabelle 53: Architekturentscheidung Kommunikation mit zentralen Diensten zunächst grundsätzlich
Pull-basiert______________________________________________________________ 51
Tabelle 54: Architekturempfehlung Service Modellierung __________________________________ 51
Tabelle 55: Architekturempfehlung Service Binding ______________________________________ 52
Tabelle 56: Architekturempfehlung Service Registrierung _________________________________ 52
Tabelle 57: Architekturentscheidung Format der Referenz / Pointer _________________________ 53
Tabelle 58: Architekturentscheidung Optionalität von Anwendungen _________________________ 56
Tabelle 59: Architekturentscheidung Bereitstellung der Anwendungsbestandteile _______________ 56
Tabelle 60: Architekturentscheidung Freigabeverfahren für neue Anwendungen _______________ 57
Tabelle 61: Architekturentscheidung Update der Vertragsdaten als Nachpersonalisierung über das
CAMS _________________________________________________________________ 58
Tabelle 62: Architekturentscheidung Einrichtung eines zentralen Dienstes zur Validierung von KVKs
und Überprüfung des Zuzahlungsstatus _______________________________________ 58
Tabelle 63: Architekturentscheidung Ausschließliche Betrachtung von Arzneimittel- und BTMRezepten in Phase 2 ______________________________________________________ 59
© 2004
Seite 4 von 112
Tabelle 64: Architekturentscheidung Signatur des eRezeptes über die Signaturanwendung des
bIT4health Connectors über die Dienstschnittstelle_______________________________ 59
Tabelle 65: Architekturentscheidung Symmetrische Verschlüsselung der eRezepte auf dem Resource
Provider Server __________________________________________________________ 60
Tabelle 66: Zugriffsfreigabe auf eGK durch Versicherten __________________________________ 60
Tabelle 67: Zweistufiges Autorisierungskonzept _________________________________________ 61
Tabelle 68: Autorisierung des Zugriffs auf einzelne med. Datenobjekte _______________________ 61
Tabelle 69: Authentifizierung des eGK Kartenzugriffs durch den Versicherten mittels qualifizierter
elektronischer Signatur ____________________________________________________ 62
Tabelle 70: Technische Umsetzung der Vertretungsregelung ______________________________ 63
Tabelle 71: Nutzung von PK-Verfahren im Rahmen der Telematikarchitektur im Gesundheitswesen 63
Tabelle 72: Generelle Krypto-Funktionen der Karten _____________________________________ 63
Tabelle 73: Übergreifende PKI Architektur _____________________________________________ 64
Tabelle 74: Die PK-Strukturen bilden ein geschlossenes System für das Gesundheitswesen ______ 65
Tabelle 75: Trennung von CVC und X.509 _____________________________________________ 65
Tabelle 76: Trennung der X.509 basierten PK-Strukturen von Anwendungen und Administration___ 66
Tabelle 77: Schaffung einer zentralen Instanz und PCA für X.509 Zertifikate __________________ 66
Tabelle 78: Einstufiges hierarchisches Modell für die X.509 PKI-Strukturen ___________________ 67
Tabelle 79: Anbindung externer PKIs über Bridge-CAs ___________________________________ 67
Tabelle 80: Schaffung einer zentralen Instanz und PCA für CVCs ___________________________ 67
Tabelle 81: PKI für HBA – PKI-Struktur _______________________________________________ 68
Tabelle 82: Einsatz von speziellen PK-Verfahren und CVC für die Karten-zu-Karten Sicherheit ____ 69
Tabelle 83: Definition der Standards zum Einsatz von CVCs _______________________________ 69
Tabelle 84: Beidseitige C2C-Authentifizierung mittels CVCs _______________________________ 70
Tabelle 85: Einsatz X.509 basierter PK-Verfahren für die Anwendungssicherheit und elektronische
Signatur ________________________________________________________________ 70
Tabelle 86: Einsatz X.509 basierter PK-Verfahren für Anwendungs- und Kartenadministration_____ 71
Tabelle 87: Definition der Standards zum Einsatz von X.509 Zertifikaten _____________________ 71
Tabelle 88: eGK Funktionen auf Basis von X.509 Zertifikaten ______________________________ 72
Tabelle 89: Funktionen für qualifizierte Signaturen _______________________________________ 72
Tabelle 90: Herausgeber der CVC auf eGK ____________________________________________ 73
Tabelle 91: Herausgeber nicht-qualifizierter X.509 Zertifikate ______________________________ 73
Tabelle 92: Herausgeber der CVC auf HBA und SMC ____________________________________ 74
Tabelle 93: Herausgeber der X.509 Zertifikate auf HBA und SMC ___________________________ 74
Tabelle 94: PKI für HBA – Bestätigung der Berufsbezeichnung _____________________________ 75
Tabelle 95: Schlüssel und Zertifikatserzeugung der CVCs _________________________________ 75
Tabelle 96: Verzeichnisdienste eGK __________________________________________________ 76
Tabelle 97: PKI für HBA - Verzeichnisdienst____________________________________________ 76
Tabelle 98: Validierung von Zertifikatsinformationen _____________________________________ 77
Tabelle 99: Nutzung der PK-Clientarchitektur des Signaturbündnisses _______________________ 78
Tabelle 100: AE-LK1 Architekturentscheidung: Signaturfähigkeit der eGK ____________________ 78
© 2004
Seite 5 von 112
Tabelle 101: AE-LK2 Architekturentscheidung zur Sicherheitskonzeption _____________________ 79
Tabelle 102: AE-LK3 Architekturentscheidung „Begrenzte Gültigkeit von Karten im Test“_________ 81
Tabelle 103: AE-LK4 Architekturentscheidung zur Nutzungsgrenze HBA _____________________ 82
Tabelle 104: AE-LK5 Architekturentscheidung zur Nutzungsgrenze eGK _____________________ 83
Tabelle 105: AE-LK6 Sicherheitsniveau der eGK ________________________________________ 84
Tabelle 106: AE-LK7a Architekturentscheidung zur PIN-/PUK-Erzeugung/Ausgabe (1) __________ 85
Tabelle 107: AE-LK7b Architekturentscheidung zur PIN-/PUK-Erzeugung/Ausgabe (2) __________ 86
Tabelle 108: AE-LK8a Architekturentscheidung zum Artwork der eGK _______________________ 87
Tabelle 109: AE-LK8b Architekturentscheidung zum Artwork der eGK (2)_____________________ 88
Tabelle 110: AE-LK9 Architekturentscheidung zur optischen Personalisierung _________________ 88
Tabelle 111: AE-L10 Architekturentscheidung zur Sehbehindertenkennzeichnung ______________ 89
Tabelle 112: AE-L10 Architekturentscheidung zur elektrischen Personalisierung der HBA und SMC 89
Tabelle 113: AE-L10 Architekturentscheidung zur elektrischen Personalisierung der eGK ________ 90
Tabelle 114: 1. Rechnerkomplex – einfache Auslegung für ein Datacenter ___________________ 102
Tabelle 115: 2. Rechnerkomplex – einfache Auslegung für ein Datacenter ___________________ 103
Tabelle 116: 1. Rechnerkomplex – doppelte Auslegung für ein Datacenter ___________________ 103
Tabelle 117: 2. Rechnerkomplex – doppelte Auslegung für ein Datacenter ___________________ 103
Tabelle 118: Maschinen für Produktions- und Rückfall-Datacenter _________________________ 104
Tabelle 119: Maschinen für Staging Environment_______________________________________ 105
Tabelle 120: Maschinen für Entwicklungsumgebung und Testtreiber________________________ 106
Tabelle 121: Hardware Konfiguration für den Internet Zugang zum eGK-Datacenter ___________ 108
Tabelle 122: Konfiguration für VPN Distribution ________________________________________ 109
Tabelle 123: Konfiguration der VPN Konzentratoren ____________________________________ 109
Tabelle 124: Switchkomponenten mit Firewall für die Serverdistribution im Anwendungsbereich __ 109
Tabelle 125: Switchkomponenten Anwendungscorebereich für die Kopplung zu den dahinter
liegenden Bereichen _____________________________________________________ 110
Tabelle 126: Switch Komponenten zentrale Dienste Managementdienste und Datenbankdienste _ 110
Tabelle 127: Router Komponente für ISDN oder DSL Anschluß mit ISDN Backup und PKI Support für
bis zu ca. 20 Kartenlesegeräte pro Standort ___________________________________ 111
Tabelle 128: Router Komponente für 2Mbps Standleitung mit ISDN Backup (2Mbps) mit PKI Support
für mehr als 20 Kartenlesegeräte pro Standort (Beispiel Krankenhaus)______________ 111
© 2004
Seite 6 von 112
1
Einleitung
In dem vorliegenden Anhang sind alle das Hauptdokuments Solution Outline [SolOut04] ergänzenden Details zu finden. Dies sind zum einen die Architekturenscheidungen (Kapitel 2)
und zum anderen die Berechnungen zum Kapitel Netze und IT Infrastruktur (Kapitel 3) des
Solution Outline.
Hierüber hinaus sind die Architekturentscheidungen des Planungsauftrages [Plan04] (Abschnitt 2.1) sowie diejenigen der Rahmenarchitektur [bIT4health] (Abschnitt 2.2) aufgeführt,
so dass in diesem Dokument alle bisher bzgl. der Telematikplattform im Gesundheitswesen
getroffenen Architekturentscheidungen in einem Dokument zusammengeführt sind.
Die Architekturentscheidungen des Solution Outline (Abschnitt 2.3) bauen auf denen des
Planungsauftrages sowie denjenigen der Rahmenarchitektur auf.
© 2004
Seite 7 von 112
2
Architekturentscheidungen
2.1 Architekturentscheidungen des Planungsauftrags
Die Architekturentscheidungen des Planungsauftrages werden hier im Folgenden aufgeführt.
Tabelle 1: Architekturoption und notwendige Entscheidung AE-E11 Migrationspfad
AE-E1
Bereich
Wichtigkeit
Architekturoption und notwendige Entscheidung
Migrationsstufen und weiche Übergänge
Sehr hoch
Dringlichkeit
Sehr hoch
Annahmen
Die derzeitigen papierbasierten Prozesse (mit Medienbrüchen) müssen
in geeigneter Form als Ersatz- bzw. Notfallmaßnahmen zukünftig vorhanden sein.
Die Projektrisiken für die Einführung der neuen und modifizierten Geschäftsprozesse sollen minimiert werden.
Motivation
Vermeidung von Projektrisiken durch Abhängigkeiten der Einführung der
eGK vom Roll Out einzelner Komponenten durch

Minimierung des kritischen Pfades,

Vermeidung von Verzögerungen durch eine nicht vollständige flächendeckende Durchdringung von einzelnen Komponenten,

Festlegung von Übergangszeiten mit Koexistenz.
Die Versichertenstammdatendienste (Vertragsstatus, Zuzahlungsstatus,
etc.) sollen ohne Abhängigkeiten vom Roll Out der eGK verwendet werden können. Die von den Kostenträgern bereitzustellenden Versichertenstammdaten können mit einem HBA auch für noch im Feld befindliche KVK genutzt werden.
Entscheidung
1

Die für die eGK aufgebauten Dienste (für Versicherungsstammdaten
und Abrechnungsmanagement) werden in der Migrationsphase auch
für die KVK bereitgestellt werden. Der Zugriff ist entsprechend den
gesetzlichen Anforderungen mit einer HPC/HBA möglich.

Das elektronische Rezept wird nur im Zusammenhang mit der eGK
realisiert.

Papierbasierte Varianten der entsprechenden Geschäftsvorfälle werden im Migrationszeitraum unterstützt. Die Notfallprozesse orientieren sich am derzeitigen Verfahren. Diese Varianten der Geschäftsvorfälle werden zukünftig als Ersatzmaßnahmen bei Ausfall einzelner
Komponenten der Telematikplattform weiterhin möglich sein. Medienbrüche sind dabei zu minimieren, d.h. die Daten sind so früh wie
möglich elektronisch bereitzustellen und elektronisch zu übertragen.
Für die Ersatzprozesse müssen die Daten nachträglich automatisch
übernommen werden.

Optionale Anwendungen können nur mit HBA und eGK genutzt wer-
Nomenklatur: AE-En: AE = Architekturentscheidung; E = Enterprise Viewpoint [SAGA]; n= Nummer der Entscheidung
© 2004
Seite
8 von 112
AE-E1
Bereich
Migrationsstufen und weiche Übergänge
den.
Alternativen
-
Tabelle 2: Architekturoption und notwendige Entscheidung AE-E2: Aufteilung der Rahmenarchitektur
AE-E2
Bereich
Wichtigkeit
Aufteilung der Rahmenarchitektur und
Übernahme existierender Konzepte, Technologien und Produkte
Sehr hoch
Dringlichkeit
Sehr hoch
Annahmen
Die schnelle Einführung der Telematikplattform kann nur unter Verwendung und Berücksichtigung existierender Produkte und IT Landschaften des Gesundheitswesens erfolgen.
Vorhandene Konzepte und Festlegungen im Rahmen von eGovernment in Deutschland sind für die Übernahme in das Gesundheitswesen
geeignet.
Motivation
Die für das Gesundheitswesen spezifischen Teile der Telematikplattform sollen auf das unbedingt notwendige Maß beschränkt werden. Die
verwendeten Basis IT Dienste werden dann weitgehend auf existierenden Produkte und Dienste aufgebaut. Technische Weiterentwicklung
der Basis IT Dienste und zukünftige Übernahme neuer kostengünstiger
Produkte und Dienste muss möglich sein, daher ist auf eine Unabhängigkeit der fachlichen Anwendungen und Informationsmodelle von den
Details der IT Basisdienste zu achten.
Entscheidung
Die Referenzarchitektur für die Telematikplattform im GesundheitsweDie Referenzarchitektur für die Telematikplattform im Gesundheitswesen wird in die nachfolgenden Bereiche aufgeteilt:

Anwendungs-Software und Informationsmodell

Softwareinfrastruktur und Middleware

Hardware- und Netzwerk Infrastruktur

Sicherheitsinfrastruktur und Karten

Management der Anwendungen und System

Test und Abnahme
Eine lose Kopplung und IT-technische Unabhängigkeit zwischen diesen
Bereichen wird angestrebt. Spezifische technische Standards für das
Gesundheitswesen werden vorwiegend für die Anwendungs-Software
und das Informationsmodell sowie deren Schnittstellen zur Sicherheitsinfrastruktur und Karten und der Softwareinfrastruktur entwickelt und
festgelegt sowie in Test und Abnahme abgenommen.
In den anderen Bereichen werden existierende Produkte und internationale/nationale Standards in der Regel berücksichtigt und übernommen. Die fachlichen Prozesse und Informationsflüsse sind dabei von
der Verwendung der IT-Basisdienste sowie den Systemadministrationsdiensten zu trennen.
Es werden relevante Architekturkonzepte übernommen und insbesondere die Konzepte und Standards sowie festgelegte Technologien im
Rahmen von eGovernment (Vorgehensweisen und Rahmenbedingun© 2004
Seite
9 von 112
AE-E2
Bereich
Aufteilung der Rahmenarchitektur und
Übernahme existierender Konzepte, Technologien und Produkte
gen [eGov Hand], barrierefreier Zugang [BITV], Architekturkonzepte
und technische Basisstandards [SAGA]) berücksichtigt.
Alternativen
Keine – Eine für das Gesundheitswesen eigenständige und separate
Entwicklung, Festlegung und Abnahme aller technischen Komponenten
der Telematikplattform ist weder effektiv noch effizient.
Tabelle 3: Architekturoption und notwendige Entscheidung AE-E3: Gestufte Sicherheitszonen
AE-E3
Bereich
Wichtigkeit
Gestufte Sicherheitszonen
Sehr hoch
Dringlichkeit
Sehr hoch
Die Sicherheitsinfrastruktur soll entsprechend den steigenden Geschäftsrisiken Dienste für eine einheitliche Ende-zu-Ende Sicherheit
bereitstellen. Systeme in der Request/Response-Kette müssen dabei
entsprechend den jeweiligen Bedrohungen durch kostengünstige starke Sicherheitsmaßnahmen unabhängig abgesichert werden.
Annahmen
Gestufte Sicherheitszonen mit einheitlichen Sicherheitsmaßnahmen
werden eingeführt und erlauben eine unabhängige Sicherheitsbetrachtung innerhalb dieser Zone, da sich Schwachstellen, Bedrohungen,
Risiken und Sicherheitsmaßnahmen nur innerhalb einer Sicherheitszone auswirken und daher zu einheitlichen Schutzprofilen zusammenstellen lassen.
Motivation
Anfragen und Antworten für einen Geschäftsvorfall (Transaktion) sind
über den gesamten Weg durch die Systeme abzusichern. Ende-zuEnde Sicherheit beginnt beim Browser oder Client-Programm (intern
oder extern), geht über die Business-Komponenten im "Middle-Tier" bis
hin zu den Backend-Systemen, wobei die Daten öffentliche und private
Netzwerke mit unterschiedlichen Schutzgraden durchlaufen. Prinzipien
der Sicherheitsarchitektur sind:
Sicherheit nicht durch Vertrauen in Personen

Bedrohungen von innen und außen sind gleichzusetzen.

Die besonderen Anforderungen unternehmensübergreifender, verteilter Anwendungen sind zu berücksichtigen.
Anwendernutzen

Das Deployment der Sicherheitstechnologien muss sich in realistischem Rahmen bewegen.

Die eingesetzten Technologien dürfen den Benutzer in seiner Arbeit
nicht behindern, sondern sollen ihm Vorteile bringen.
Schnelle Einführung und Migration

Vorhandene und geplante IT-Architekturen und IT-Systeme sind zu
unterstützen und zu integrieren.

Die Implementierung des Sicherheits-Frameworks muss auf Basis
der am Markt verfügbaren Sicherheitsprodukte möglich sein.

Andere/weitere Sicherheitsfunktionen müssen stufenweise eingeführt werden können. Dabei ist in einem Übergangszeitraum eine
© 2004
Seite
10 von 112
AE-E3
Bereich
Gestufte Sicherheitszonen
Koexistenz zwischen verschieden starken Sicherheitsmechanismen
notwendig.
Modularität und Fehlertoleranz
Entscheidung

Die Sicherheitsarchitektur muss modular erweiterbar sein.

Die Schnittstellen der Komponenten müssen exakt abgegrenzt
werden.

Komponenten und Sicherheitstechnologien müssen austauschbar
sein.

Neue Sicherheitstechnologien müssen integriert werden können.

Die Kompromittierung einer Komponente darf nicht zur Kompromittierung anderer Komponenten führen.

Der Ausfall einer Komponente darf nicht zur Kompromittierung anderer Komponenten führen.
Die Sicherheitsinfrastruktur stellt ein Rahmenwerk für die Aufteilung in
unabhängige, schwach gekoppelte Sicherheitszonen zur Verfügung.
Sicherheitszonen unterscheiden sich durch

die Zuständigkeit für Prozesse und Daten,

die Klassifikation und Sensitivität der vorhandenen Daten,

die Benutzergruppen, die auf diese Daten zugreifen dürfen,

die Bedrohungen, die in der Risikoanalyse zu berücksichtigen sind.
Die Architektur innerhalb der einzelnen Sicherheitszonen muss
Alternativen

die notwendigen Sicherheitsdienste und die Schnittstellen zu diesen beschreiben,

die Interaktionen zwischen den Diensten und Applikationskomponenten beschreiben, die die Sicherheitsdienste nutzen,

auf Standards basieren, um Portabilität und Interoperabilität zu gewährleisten und

unterstützende Dienste zur Verfügung stellen, die benötigt werden,
um die Telematikdienste umzusetzen.
Verwendung von Ende-zu-Ende bzw. Person-zu-Person Sicherheitsmechanismen über Sicherheitsgrenzen hinweg, z.B. durch Verschlüsselung zwischen dem Client und den Backend Systemen (IPSEC, EMail). Dies erfordert hohe bis sehr hohe Sicherheitsmaßnahmen an
Clients/Arbeitsplatz PC (u.a. physikalische Mechanismen, z.B. Zugangskontrolle) und damit einen Eingriff in die existierenden Primärsysteme (z.B. PVS).
Tabelle 4: Architekturoption und notwendige Entscheidung AE-E4: Aufgaben und Abgrenzung der
Sicherheitsinfrastruktur
AE-E4
Bereich
Wichtigkeit
Aufgaben der Sicherheitsinfrastruktur
Sehr hoch
© 2004
Seite
11 von 112
AE-E4
Bereich
Dringlichkeit
Sehr hoch
Festlegung und Abgrenzung der technischen Komponenten und Sicherheitsdienste der Sicherheitsinfrastruktur von den organisatorischen Sicherheitsprozessen. Die Aufgaben werden aufgeteilt in:
Annahmen

Sicherheitsmanagement-Prozesse,

IT-Sicherheitsdienste und

Management der Sicherheitsobjekte (z.B. Karten).
Der Schwerpunkt der technischen Komponenten der Sicherheitsinfrastruktur sind

die Bereitstellung von IT-Sicherheitsdiensten für die ITAnwendungen und IT-Infrastrukturen der Telematikplattform und

das Management der Sicherheitsobjekte (z.B. Schlüssel und Karten).
Die bestehenden Regelungen, Betriebsstandards und Prozesse der
technischen Komponenten der Telematikplattform müssen an die erhöhten Risiken angepasst werden.
Motivation
Festlegung und Abgrenzung der von der Sicherheitsinfrastruktur zu
betrachtenden Prozesse und Dienste.
Eine Festlegung der von der Sicherheitsinfrastruktur zukünftig bereitzustellenden Funktionalität, d.h. die Festlegung von Risikoklassen,
Schutzklassen, Schutzprofilen und Festlegung von Mindestanforderungen an die Stärke der zu verwendeten Sicherheitsmechanismen
muss noch erfolgen.
Die Sicherheitsinfrastruktur soll
Entscheidung
2

das bestehende Sicherheitsniveau während des Betriebes gewährleisten,

eine zukünftige Erhöhung des Sicherheitsniveaus mit angemessenem Aufwand ermöglichen,

relevante Sicherheits-Standards und Sicherheitsrichtlinien berücksichtigen2,

die realisierte Sicherheitsfunktionalität verifizierbar, d.h. nachprüfbar realisieren und

ein Sicherheitszonenkonzept erstellen. Dieses Konzept ist projektbegleitend umzusetzen und unabhängig zu prüfen.
Die Sicherheitsinfrastruktur ist als Infrastrukturkomponente anwendungsneutral definiert und muss als Basis für beliebige Anwendungen
aufgebaut werden. Die Sicherheitsinfrastruktur berücksichtigt die folgenden Sicherheitsmanagementprozesse in den funktionalen Anforderungen:

Administration von Identitäten, Benutzern und Berechtigungen,
Credentials.

Erzeugung, Sammlung und Zusammenführung sicherheitsrelevanter Ereignisse in einem Audit-Trail.
Eine Verfeinerung bzw. neue Richtlinien bzgl. Sicherheitsanforderungen sind ggf. noch festzulegen.
© 2004
Seite
12 von 112
AE-E4
Bereich
Die Festlegung von Risikoklassen der Anwendungen, Schutzklassen,
Schutzprofilen und Festlegung von Mindestanforderungen an die
Stärke der zu verwendenden Sicherheitsmechanismen erfolgt außerhalb der Sicherheitsinfrastruktur. Diese funktionalen Anforderungen
an die Architektur der Sicherheitsinfrastruktur sind im Rahmen eines
Migrationsprozesses zukünftig zu unterstützen.
Alternativen
Keine – Eine anwendungsspezifische Definition der Sicherheitskonzepte sowie Integration der Sicherheitsmechanismen in einzelnen
Anwendungen und Komponenten sind weder effektiv noch effizient.
Tabelle 5: Architekturoption und notwendige Entscheidung AE-C13: Wechsel von Sicherheitsalgorithmen
AE-C1
Bereich
Wichtigkeit
Abhängigkeit von konkreten Sicherheitsalgorithmen vermeiden
Sehr hoch
Dringlichkeit
Sehr hoch
Annahmen
Bei der Architektur der Schnittstellen der Sicherheitsinfrastruktur muss
darauf geachtet werden, dass eine Abhängigkeit von konkreten Sicherheitsalgorithmen und -produkten weitestgehend vermieden wird.
Motivation
Eine Umstellung auf einen anderen, z.B. stärkeren Algorithmus, sollte
möglichst transparent möglich sein, um unnötige Umstellungskosten zu
vermeiden und eine Koexistenzphase für die Migration zu unterstützen.
Entscheidung
Anbieten/Verwenden der Sicherheitsfunktionalitäten über standardisierte Schnittstellen. Dadurch ist eine Änderung in der dahinter liegenden Sicherheitskomponente leichter möglich und im Optimalfall von
außen gar nicht bemerkbar.
Schnittstellen sind noch festzulegen. Standardisierte Java Schnittstellen (JAAS, JCE, JMS) sollten bevorzugt werden.
Alternativen
Direkte Verwendung der Sicherheitsalgorithmen und Krypto-Libraries
Tabelle 6: Architekturoption und
übergreifender Komponenten
notwendige
Entscheidung
AE-C2:
Zusammenfassung
einheitlicher,
AE-C2
Bereich
Wichtigkeit
Zusammenfassung einheitlicher, übergreifender Komponenten
Sehr hoch
Dringlichkeit
Sehr hoch
Annahmen
Die vorhandene Infrastruktur muss zum Erreichen der notwendigen
Service Level Agreements (SLAs) verändert werden.
Der Aufwand für die Realisierung der organisationsspezifischen
Schnittstellen zu den vorhandenen Hintergrundsystemen soll minimiert
werden.
Motivation
Vermeidung von Doppelentwicklungen in Spezifikation, Umsetzung
und Betrieb
Entscheidung
Einheitliche, übergreifende Komponenten werden gemeinsam spezifi-
3
Nomenklatur: AE-Cn: AE = Architekturentscheidung; C = Computational Viewpoint [SAGA]; n= Nummer der Entscheidung
© 2004
Seite
13 von 112
AE-C2
Bereich
Zusammenfassung einheitlicher, übergreifender Komponenten
ziert, entwickelt und betrieben. Bei jeder betroffenen Komponente ist
eine Einzelfallentscheidung der Selbstverwaltung notwendig und die
Entscheidungsvorlagen sind zu erstellen. Nachfolgende Komponenten
sollten vordringlich behandelt werden:
Alternativen

Online-Zugriff auf die aktuellen Stammdaten, Sperrung von Karten
(KVK, eGK).

eRezept- und Abrechnungsdienste.

Berechnung kryptografischer Personalisierungsdaten für die Kartenproduktion bzw. für die Online-Nachpersonalisierung im Feld befindlicher Karten.
Eigenentwicklung jeder einzelnen Organisationseinheit.
In der folgenden Tabelle sind die identifizierten Aktivitäten zum Aufbau der technischen
Komponenten der Telematikplattform zusammengestellt und hinsichtlich ihrer Wichtig- und
Dringlichkeit bewertet.
Tabelle 7: Übersicht der erforderlichen Aktivitäten zur Einführung der Telematikplattform
Bezeichnung
Aktivität
Wichtigkeit
[AktOrg]
Aufbau einer Organisation zur Verabschiedung der ver- Sehr
bindlichen Standards und Profile für die Telematikplatt- hoch
form im Gesundheitswesen.
Dringlichkeit
Sehr
hoch
1. Schaffung eines gemeinsamen Ausschusses.
2. Etablierung von Arbeitsgruppen. Die nachfolgenden
Bereiche werden vorgeschlagen.
a) Kartenstrategie (HBA, eGK).
Festlegung der Kartenfunktionalität und Ausformung (z.B. physikalische/virtuelle Karten), Weiterentwicklung der Kartenspezifikationen zur Erreichung der Interoperabilität.
b) Sicherheitsausschuss – organisatorische Sicherheitsregelungen
Organisatorischer und technischer Mindestanforderungen an die Komponenten der Telematikplattform.
c) Kartengestützte Gesundheitssysteme und Anwendungen Anwendungs-Architekturen und Datenformate für den Austausch im Gesundheitswesen.
d) Testverfahren und Abnahmen
[AktSpezTele]
Sehr
Von Minimalanforderungen an die medizinische Doku- hoch
mentation und die Strukturierung sowie Definition von
Basiselementen für die technische Kommunikation bis
hin zu technischen Elementen einer transparenten SpeiSpezifikation der Telematikdienste
© 2004
Sehr
hoch
Seite
14 von 112
Bezeichnung
Aktivität
Wichtigkeit
Dringlichkeit
cherung und vertrauenswürdigen Verarbeitung sind verbindliche Festlegungen und Spezifikationen notwendig.
[AktSpez
Prim]
Die frühzeitige Festlegung einer technikneutralen Sehr
Schnittstelle (sowohl für Server und Kartenzentrierte Lö- hoch
sungen) der Telematikdienste wird dringend empfohlen.
Sehr
hoch
[AktSpezInfra]
Spezifikation Softwareinfrastruktur und Middleware:
hoch
hoch
[AktSpez
Sec]
Spezifikation Sicherheitsinfrastruktur und Karten:
Sehr
Wechselwirkung hoch
Sehr
hoch
Für die allgemeine Dienste Infrastruktur (z.B. BasisDienste, Verzeichnisdienste) sind verbindliche Spezifikationen für interoperable Verfahren erforderlich.
Spezifikation
HBAÅÆeGK
eGK
und
der
Von der Sicherheitspolitik (Policy) über die Sicherheitsdienste bis zur Festlegung der Details von kryptografischen Verfahren müssen verbindliche Regeln abgestimmt werden.
[AktSpez
Net]
Spezifikation Hardware- und Netzwerk-Infrastruktur:
hoch
hoch
[AktMin]
Festlegung von Mindestanforderungen an die Betriebs- hoch
umgebung der technischen Komponenten der Telematikinfrastruktur.
Sehr
hoch
Die Systeme- und Netzverbindungen müssen den Austausch der Gesundheitsdaten unterstützen und zusätzlich einen Schutz gegen externe Bedrohungen bieten.
Die Sicherheit der an (offene) Netze angeschlossenen
Systeme soll bei extern erbrachten Services durch Kontrollverfahren garantiert werden
Dies betrifft die nachfolgenden Bereiche:
Sicherheitskonzept - z.B. Vorgehen nach GSHB
Betriebskonzept
[AktTest]
Festlegung und Aufbau eines Testbeds und der Testsui- hoch
tes für die Telematikplattform.
© 2004
hoch
Seite
15 von 112
Abbildung 1: Priorisierung der wichtigsten Roll-Out-Aktivitäten.
In Abbildung 1 ist die vorgeschlagene Priorisierung der wichtigsten Aktivitäten grafisch dargestellt. Der flächendeckende Roll Out der HBA ist als wesentliche Komponente des kritischen Pfades identifiziert worden. Die Bereitstellung der priorisierten Anwendungen zu diesem Zeitpunkt wird dringend empfohlen, um den Nutzen der Dienste der Telematikplattform
frühzeitig zu realisieren sowie die Projektrisiken zu minimieren.
© 2004
Seite
16 von 112
2.2 Architekturentscheidungen der Rahmenarchitektur
Bei der Erstellung der Rahmenarchitektur [bIT4health] wurden eine Reihe grundsätzlicher
Architekturentscheidungen festgelegt, auf die der Solution Outline aufbaut. Aus diesem
Grunde sind die Architekturentscheidungen der Rahmenarchitektur im Folgenden zusammengestellt.
1.1.1 Allgemein
Tabelle 8: Wesentliche Architekturentscheidungen der Rahmenarchitektur
Nr.
Bereich
Begründung und Motivation
AE-R1
Abgrenzung
der
Telematik- Festlegung der Systemgrenzen, Aktionen und
infrastruktur zu existierenden Sys- Geschäftsvorfälle
temen und Anwendungen
AE-R2
Aufgaben der Telematikinfrastruktur
AE-R3
Patientenorientierung und Datenho- Der Versicherte ist "Herr seiner Daten" und beheit
stimmt über deren Verwendung.
AE-R4
Datenschutz
AE-R5
Technologieneutrale Rahmenarchi- In der Rahmenarchitektur wird sowohl die Karte,
tektur mit Karten- und Serverlösung als auch der Server als Speicherort für medizinische Daten berücksichtigt.
AE-R6
Berücksichtigung und Verwendung Existierende stabile Produkte und Standards sind
erprobter Konzepte und Lösungen
für eine zeitgerechte Einführung zu verwenden.
AE-R7
Migrationsfähigkeit- und Skalierbar- Es werden die Konzepte der Rahmenarchitektur
keit
zur Erzielung der Migrationsfähigkeit festgelegt.
AE-R8
Aufteilung der Telematikinfrastruktur Die Telematikinfrastruktur wird in abgegrenzte
in abgegrenzte Bereiche wie Kom- Bereiche aufgeteilt.
munikation, Sicherheit, Datendienste
etc.
AE-R9
Karten- und
der eGK
Definition des Integration Layers
Datensparsamkeit und weitgehende organisatorische und technische Trennung der Daten und
Schnittstellen sowie durch den Benutzer bestimmbare Informationsflusskontrolle.
Einführungsstrategie Aufbauend auf einer zuerst ausgegebenen eGK
sind zukünftig verschiedene Kartenarten bzw. neue
Anwendungen zu integrieren.
Nachfolgend werden die wesentlichen Architekturentscheidungen der Rahmenarchitektur
einzeln dargestellt.
© 2004
Seite
17 von 112
Tabelle 9: Architekturentscheidung zu Systemgrenzen der Telematikinfrastruktur und der
Integration existierender Systeme
AE-R1
Bereich
Annahmen
Systemgrenzen der Telematikinfrastruktur und Integration existierender Systeme
Es gibt eine Vielzahl existierender IT-Systeme im Gesundheitswesen,
u.A. Primärsysteme bei Leistungserbringern sowie Backendsysteme
bei Krankenkassen und Krankenversicherungen von unterschiedlichen
Herstellern mit unterschiedlichen Architekturen.
Motivation
Die Aufwände für die Einführung der neuen und modifizierten Geschäftsprozesse sollen minimiert werden.
Alternativen
Keine. - Eine Modifikation und Redesign der existierenden Anwendungslandschaften im Gesundheitswesen ist weder effektiv noch effizient.
Entscheidung
Die Anbindung von Drittsystemen an die Telematikinfrastruktur erfolgt
mit möglichst kleinen Anpassungskomponenten über einheitliche
Schnittstellen. Die Telematikinfrastruktur stellt einheitliche Dienste und
Schnittstellen zu den nachfolgenden Systemen zur Verfügung:

Primärsysteme: Eine Integration in die vorhandenen Systeme ist
vom jeweiligen Produkthersteller durchzuführen. Der Eingriff in die
vorhandenen Primärsysteme sowie die etablierten Prozesse bei
den Leistungserbringern wird damit auf das unumgängliche Maß
reduziert.

Backendsysteme (z.B. bei Krankenkassen, Krankenversicherungen
oder Apothekenrechenzentren): Eine Integration in die vorhandenen Systeme ist in der jeweiligen Organisation durchzuführen. Es
ist dabei zu berücksichtigen, dass die Abrechnungs- und Stammdaten über die verschiedenen Organisationen verteilt vorhanden
sind und dass durch die Telematikinfrastruktur ein einheitlicher logischer Zugang zu diesen Daten und Verzeichnissen geschaffen
wird.
Einheitliche Schnittstellen zu den im Gesundheitswesen vorhandenen
Karten werden verwendet, um diese Dienste den Anwendungssystemen bereitzustellen.
Begründung
Die schnelle Einführung der Telematikinfrastruktur kann nur unter Verwendung und Berücksichtigung existierender Produkte und IT Landschaften des Gesundheitswesens erfolgen.
Implikation
Für die Lösungsarchitektur wird die frühzeitige Festlegung einer technikneutralen Schnittstelle (sowohl für server- als auch für kartenzentrierte Lösungen) zu den Primärsystemen dringend empfohlen (siehe
bIT4healthConnector). Diese Schnittstelle ermöglicht es den Anbietern
der Primärsysteme, frühzeitig die Telematikdienste zu integrieren. Zusätzlich werden damit sowohl für die Pilotregionen als auch für den
nachfolgenden bundesweiten Betrieb Migrationsmöglichkeiten geschaffen.
Abhängige Archi- AE-R2 Aufgaben der Telematikinfrastruktur
tekturentscheidungen
© 2004
Seite
18 von 112
Tabelle 10: Architekturentscheidung zu den Aufgaben der Telematikinfrastruktur
AE-R2
Bereich
Annahmen
Aufgaben der Telematikinfrastruktur
Die Einführung der Telematikinfrastruktur spielt bei der Modernisierung
des deutschen Gesundheitswesens – im Hinblick auf Effizienz- und
Qualitätssteigerung – eine wesentliche Rolle. Die Einführung der elektronischen Gesundheitskarte ist dafür eine der wichtigsten Voraussetzungen.
Motivation
Zur Verbesserung der Qualität und Wirtschaftlichkeit der Versorgung
soll die papiergebundene Kommunikation unter den Leistungserbringern so bald und so umfassend wie möglich durch die elektronische
und maschinell verwertbare Übermittlung von Befunden, Diagnosen,
Therapieempfehlungen und Behandlungsberichten, die sich auch für
eine einrichtungsübergreifende fallbezogene Zusammenarbeit eignet,
ersetzt werden.
Alternativen
Keine
Entscheidung
Die Funktionalität der Telematikinfrastruktur ist die Übertragung und
temporäre Speicherung von medizinischen und personenbezogenen
Daten zwischen den Beteiligten im Gesundheitswesen.
Begründung
Ohne eine neue Telematikinfrastruktur sind Kosteneinsparungen und
Qualitätssteigerungen im Gesundheitswesen nicht in dem erforderlichen Ausmaß möglich. Hierbei handelt es sich einerseits um die Vereinfachungen etablierter Prozesse, wie beispielsweise bei der papierlosen Übermittlung und Abrechnung des Rezepts und andererseits um
die Verbesserung der Dienstleistungen für die Patienten, wie beispielsweise bei den Notfalldaten.
Implikation
Die neu zu schaffende Telematikinfrastruktur muss von Leistungserbringer und Kostenträger benutzt werden, um die erwarteten Vorteile
realisieren zu können (siehe AE-R1). Außerdem muss die Telematikinfrastruktur ein höchst mögliches Maß an Sicherheit für die Beteiligten gewährleisten.
Abhängige Archi- AE-R1 Aufgaben der Telematikinfrastruktur
Tabelle 11: Architekturentscheidung zur Patientenorientierung und Datenhoheit
AE-R3
Bereich
Annahmen
Patientenorientierung und Datenhoheit
Durch die Telematikinfrastruktur werden personenbezogene und medizinisch relevante Daten gespeichert und übertragen.
Motivation
Alle medizinischen Daten der Versicherten können als äußerst sensitiv
angesehen werden. Dadurch sind Vorkehrungen zu treffen, dass diese
nicht unberechtigt gelesen, verändert oder gelöscht werden können.
Die Souveränität über diese Daten muss letztendlich bei deren Besitzern liegen.
Alternativen
Keine
Entscheidung
Die Datenhoheit der in der Telematikinfrastruktur übertragenen und
temporär gespeicherten Daten liegt beim Versicherten.
© 2004
Seite
19 von 112
AE-R3
Bereich
Begründung
Patientenorientierung und Datenhoheit
Die Bestimmungen des GMG und Datenschutzgesetzes machen diese
Entscheidung notwendig.
Implikation
Die Telematikinfrastruktur muss die Patientenorientierung und Datenhoheit unterstützen und gewährleisten.
Abhängige Archi- AE-R4 Datenschutz
tekturAE/S-C4.1 Autorisierungsmechanismen (siehe [b4h Sicherheitsarchientscheidungen
tektur])
Tabelle 12: Architekturentscheidung zum Datenschutz
AE-R4
Bereich
Annahmen
Datenschutz
Die Schutzwürdigkeit der Daten erfordert übergreifende, einheitliche
Architekturkonzepte.
Motivation
Neben den starken Sicherheitsdiensten der Sicherheitsinfrastruktur
sind

Datensparsamkeit und

eine weitgehende organisatorische und technische Trennung der
Daten und Schnittstellen sowie

durch den Benutzer bestimmbare Informationsflusskontrolle
die Verfahren, um die sehr hohen Datenschutzanforderungen in der
Telematikinfrastruktur umzusetzen.
Alternativen
Keine
Entscheidung
Eine weitgehende logische und physikalische Trennung von Daten, die
sich an nachfolgenden Kriterien orientiert, ist durchzuführen

personenbezogene und medizinische Daten,

den Eigentümer der Prozesse und Daten,

die Klassifikation und Sensitivität der vorhandenen Daten,

die Benutzergruppen, die auf diese Daten zugreifen dürfen,

die Bedrohungen, die in der Risikoanalyse zu berücksichtigen sind.
Die Kontrolle des Informationsflusses zwischen den Anwendungskomponenten muss - unter Kontrolle des Versicherten - sichergestellt werden.
Begründung
Die konkrete Ausgestaltung der Telematikinfrastruktur u.A. des Verfahrens der Übermittlung des Rezepts in der elektronischen Form wird im
Einvernehmen mit dem Bundesbeauftragten für den Datenschutz erfolgen (siehe §291 a Absatz 3 und Absatz 7 SGB V).
Implikation
Die Datensparsamkeit und -trennung ist bei der Verteilung im Engineering Viewpoint der Lösungsarchitektur zu berücksichtigen.
Abhängige Archi- AE/S-E1.3 Durch den Benutzer bestimmbare Informationsflusskontrolle
tektur(siehe b4h Sicherheitsarchitektur)
entscheidungen
© 2004
Seite
20 von 112
Tabelle 13: Architekturentscheidung zur Nutzung von Karte und Server als Speicherort
AE-R5
Bereich
Annahmen
Speicherort von Daten
Es steht eine Online-Verbindung zu den verschiedenen Stellen des
Einsatzes der eGK zur Verfügung (also insbesondere bei Ärzten,
Zahnärzten und Apothekern).
Motivation
Es soll durch die Rahmenarchitektur eine große Flexibilität und Zukunftssicherheit erreicht werden.
Alternativen
Durch die Einführung der Telematikinfrastruktur im Zuge des GMG
entstehen verschiedene Möglichkeiten der Datenablage von patientenbezogenen Daten. Dies betrifft sowohl administrative Daten (Vertragsdaten) wie auch klinische Daten. Diese können technisch sowohl auf
der eGK selbst und auf zentralen Systemen (Servern) abgelegt werden.
Alternative Server: Hier ist der Vorteil, dass für einen Server eine sehr
hohe Verfügbarkeit bei fast unbegrenztem Speicherplatz sichergestellt
werden kann. Dies betrifft insbesondere auch Backup-Mechanismen.
Nachteilig ist, dass hier die Anforderungen an Datensicherheit naturgemäß schärfer sind, da zentrale Datenbestände entstehen. Hier ist es
sicherlich sinnvoll, über eine Pseudonymisierung der Daten (neben
einer vollständigen Verschlüsselung) den Personenbezug zu erschweren.
Alternative Karte: Hier ist der Vorteil, dass die Karte sich im Besitz des
Patienten befindet und dieser somit greifbar „Herr seiner Daten“ ist.
Aus diesem Grunde und weil die eGK als Prozessorkarte sowieso erhöhte Zugangssperren enthält, müssen die Daten nicht notwendigerweise verschlüsselt werden. Nachteilig ist zum einen die begrenzte
Speicherkapazität und der Datenverlust, welcher mit einem Kartenverlust oder Defekt der Karte einhergeht.
Alternative Karte und Server: Hier ist der Vorteil, dass der Speicherort
der Nutzdaten wahlfrei ist und insofern die Vorteile von Server und
Karte kombiniert werden können. Dabei wird ein Zeiger auf den Speicherort der Daten, welcher sehr wenig Platz verbraucht, auf der Karte
liegen und die Daten dann entweder auf der Karte oder dem Server
abgelegt. Dies kann theoretisch für jeden Datensatz neu bestimmt
werden. Nachteilig ist hier das etwas komplexere Speicherschema und
der zusätzliche Verwaltungsaufwand für die Festlegung des Speicherorts.
Entscheidung
Es wird festgelegt, dass sowohl die Karte als auch der Server Speicherort für Daten sein kann.
Begründung
Jede Applikation hat ihre eigenen Anforderungen an den Speicherort.
Während z.B. bei einer elektronischen Patientenakte aufgrund des zu
erwartenden Speicherbedarfs bis auf weiteres eine Kartenlösung nicht
in Betracht kommt, scheint diese für ein eRezept z.B. zunächst angemessen und wird für die administrativen Daten gesetzlich gefordert.
Insofern wird klar, dass beide Speicherarten zu realisieren sind. Über
eine Indirektion den Speicherort wahlfrei zu modellieren, ergibt hierbei
die höchste Flexibilität.
Implikation
Das Speichermodell ist derart auszubilden, dass sowohl ein Zeiger, als
© 2004
Seite
21 von 112
AE-R5
Bereich
Speicherort von Daten
auch das jeweilige Datenpaket modelliert wird.
Abhängige Archi- AE-R9 Karten- und Einführungsstrategie der eGK.
Tabelle 14: Architekturentscheidung zur Berücksichtigung und Verwendung erprobter Konzepte und Lösungen
AE-R6
Bereich
Annahmen
Berücksichtigung und Verwendung erprobter Konzepte und Lösungen
Vorarbeiten aus dem Bereich der elektronischen Gesundheitskarte,
des elektronischen Rezepts und relevante Standardisierungsarbeiten
die von Industrie, Aktionsforen und anderen nationalen und internationalen Initiativen erstellt wurden, sind für die Telematikinfrastruktur relevant. Ebenso sind vorhandene Konzepte und Festlegungen im Rahmen von eGovernment in Deutschland für die Übernahme in das Gesundheitswesen geeignet.
Motivation
Die für das Gesundheitswesen spezifischen Teile der Telematikplattform sollen auf das unbedingt notwendige Maß beschränkt werden.
Die verwendeten Basis IT-Dienste werden dann weitgehend auf existierenden Produkte und Dienste aufgebaut. Die technische Weiterentwicklung der Basis IT-Dienste und die zukünftige Übernahme neuer
kostengünstiger Produkte und Dienste muss möglich sein. Daher ist
auf eine Unabhängigkeit der fachlichen Anwendungen und Informationsmodelle von den Details der technischen Realisierung der Basis
IT-Dienste zu achten.
Alternativen
Keine – Eine für das Gesundheitswesen eigenständige und separate
Entwicklung, Festlegung und Abnahme aller technischen Komponenten der Telematikinfrastruktur ist weder effektiv noch effizient.
Entscheidung
In der Telematikinfrastruktur werden relevante Architekturkonzepte
übernommen und insbesondere die Konzepte und Standards sowie
festgelegte Technologien im Rahmen von eGovernment (Vorgehensweisen und Rahmenbedingungen [eGovHand], barrierefreier Zugang
[BITV], Architekturkonzepte und technische Basisstandards [SAGA])
berücksichtigt.
Für die Lösungsarchitektur der Telematikinfrastruktur werden existierende Produkte und internationale/nationale Standards in der Regel
berücksichtigt und übernommen.
Begründung
Die Telematikinfrastruktur für das Gesundheitswesen soll zügig eingeführt werden und auf breiter Basis funktionieren.
Implikation
Die Varianten innerhalb der Lösungsarchitektur werden durch diese
Entscheidung eingeschränkt.
Abhängige Archi- AE/S-E1.1
Sicherheitsarchitektur
tektur(siehe b4h Sicherheitsarchitektur)
entscheidungen
© 2004
nach
ISO
7498-2
Seite
22 von 112
Tabelle 15: Architekturentscheidung zur Migrationsfähigkeit und Skalierbarkeit der Telematikinfrastruktur
AE-R7
Bereich
Annahmen
Migrationsfähigkeit und Skalierbarkeit
Die Projektrisiken für die Einführung der neuen und modifizierten Geschäftsprozesse sollen minimiert werden.
Motivation
Vermeidung von Projektrisiken durch Abhängigkeiten der Einführung
der eGK vom Roll Out einzelner Komponenten durch

Minimierung des kritischen Pfades,

Vermeidung von Verzögerungen durch eine nicht vollständige flächendeckende Durchdringung von einzelnen Komponenten,

Festlegung von Übergangszeiten mit Koexistenz.
Alternativen
Keine
Entscheidung
Die eGK muss als Basisfunktionalität das Nachladen von Applikationen
ermöglichen. Die derzeitigen papierbasierten Prozesse (mit Medienbrüchen) müssen in geeigneter Form als Ersatz- bzw. Notfallmaßnahmen zukünftig vorhanden sein.
Begründung
Die Regelung des §291 a Absatz 7 SGB V verpflichtet die Vertragspartner auf Bundesebene zur Schaffung einer Telematikinfrastruktur,
die sich nicht auf die Gesundheitskarte beschränken darf, sondern
auch darüber hinausgehend migrationsfähig weitere Telematikanwendungen berücksichtigen muss. Gleichzeitig ist in jedem Fall sicherzustellen, dass die Heilfürsorge der Bürger gewährleistet ist.
Implikation
Die Verwendung von Multifunktionskarten und die Nachpersonalisierung ausgegebener Karten mit neuen Anwendungen ist in der Lösungsarchitektur zu realisieren. Die Erfüllung der nichtfunktionalen
Anforderung NFA 12 (b4h Nichtfunktionale Anforderungen) wird durch
den Fortbestand der papierbasierten Prozesse erreicht.
Abhängige Archi- AE-R8 Aufteilung der Telematikinfrastruktur in abgegrenzte Teilbereitekturche
entscheidungen
AE-R9 Karten- und Einführungsstrategie der eGK
Tabelle 16: Architekturentscheidung zur Aufteilung der Telematikinfrastruktur in abgegrenzte Teilbereiche
AE-R8
Bereich
Annahmen
Aufteilung der Telematikinfrastruktur in abgegrenzte Teilbereiche
Der Aufbau und Betrieb einer Telematikinfrastruktur für informationstechnische Anwendungen im Gesundheitswesen kann nur auf der Basis von - zwischen allen Partnern abgesprochenen und vereinbarten Mindeststandards für Test, Abnahme sowie Betrieb der Anwendungen
und der technischen Komponenten der Telematikinfrastruktur erfolgen.
Motivation
Es werden die nachfolgenden Komponenten betrachtet:

Anwendungs-Software und Informationsmodell: Von Minimalanforderungen an die medizinische Dokumentation und die Strukturierung sowie Definition von Basiselementen für die technische Kommunikation bis hin zu technischen Elementen einer transparenten
Speicherung und vertrauenswürdigen Verarbeitung sind verbindliche Festlegungen und Spezifikationen notwendig.

Softwareinfrastruktur und Middleware: Für diese allgemeine
© 2004
Seite
23 von 112
AE-R8
Bereich
Diensteinfrastruktur (z.B. Basis-Dienste, Verzeichnisdienste) sind
verbindliche Spezifikationen für interoperable Verfahren erforderlich.

Hardware- und Netzwerk Infrastruktur: Die Systeme- und Netzverbindungen müssen den Austausch der Gesundheitsdaten unterstützen und zusätzlich einen Schutz gegen externe Bedrohungen
bieten. Die Sicherheit der an (offene) Netze angeschlossenen Systeme soll bei extern erbrachten Services durch Kontrollverfahren
garantiert werden.

Sicherheitsinfrastruktur und Karten: Von der Sicherheitspolitik (Policy) über die Sicherheitsdienste bis zur Festlegung der Details von
kryptografischen Verfahren müssen verbindliche Regeln abgestimmt werden.

Management der Anwendungen und System: Mindeststandards für
die Administration der technischen Systemkomponenten der technischen Systeme und Komponenten sind festzulegen.

Test und Abnahme – Die Einhaltung der festgelegten Standards für
den Informationsaustausch und der Sicherheitsanforderungen der
Telematikinfrastruktur ist zu prüfen und zugelassene Komponenten
und Produkte können für den Datenaustausch im Gesundheitswesen verwendet werden.
Alternativen
Keine. - Ohne eine Aufteilung und Teilbereiche ist die Migrationsfähigkeit und Skalierbarkeit nicht zu erreichen.
Entscheidung
Die Architektur für die Telematikinfrastruktur im Gesundheitswesen
wird in die nachfolgenden Bereiche aufgeteilt:

Anwendungs-Software und Informationsmodell

Softwareinfrastruktur und querschnittliche Dienste

Hardware- und Netzwerk Infrastruktur

Sicherheitsinfrastruktur und Karten

Management der Anwendungen und des Systems

Test und Abnahme
Eine lose Kopplung und IT technische Unabhängigkeit zwischen diesen Bereichen wird angestrebt. Spezifische technische Standards für
das Gesundheitswesen werden vorwiegend für die AnwendungsSoftware und das Informationsmodell sowie deren Schnittstellen zur
Sicherheitsinfrastruktur und Karten und der Softwareinfrastruktur entwickelt und festgelegt sowie in Test und Abnahme abgenommen. Die
fachlichen Prozesse und Informationsflüsse sind dabei von der Verwendung der IT-Basisdienste sowie den Systemadministrationsdiensten über standardisierte Schnittstellen zu trennen.
Begründung
Die Regelung des §291 a Absatz 7 SGB V verpflichtet die Vertragspartner auf Bundesebene zur Schaffung einer

Informations-,

Kommunikations- und

Sicherheitsinfrastruktur,
die den Einsatz der elektronischen Gesundheitskarte ermöglicht.
© 2004
Seite
24 von 112
AE-R8
Bereich
Test- und Abnahme der eingesetzten Produkte und Lösungen ist erforderlich, um die Interoperabilität und die Einhaltung der festgelegten
Standards zu prüfen.
Implikation
Die Teilbereiche der Telematikinfrastruktur sind durch einheitliche
Dienstschnittstellen zu trennen.
Eine Stelle zur Durchführung der Tests und Abnahmen muss vorhanden sein.
Abhängige Archi- AE/S-E1.1 Sicherheitsarchitektur nach ISO 7498-2
tekturAE/S-E1.2 Aufgaben der Sicherheitsinfrastruktur
entscheidungen
(siehe b4hSicherheitsarchitektur)
Tabelle 17: Architekturentscheidung zur Karten- und Einführungsstrategie der eGK
AE-R9
Bereich
Annahmen
Karten- und Einführungsstrategie der eGK
Minimalanforderungen an die neue elektronische Gesundheitskarte
(eGK) und die Einführungsstrategie zur Erweiterung der existierenden
KVK zur eGK sind zu formulieren.
Aufbauend auf einer zuerst ausgegebenen eGK sind zukünftig verschiedene Kartenarten bzw. neue Anwendungen zu integrieren.
Die derzeitige KVK ist in die Migration einzubeziehen.
Motivation
Ein Kartentausch der neuen eGK vor Ablauf der Kartenlaufzeit ist unter
allen Umständen zu vermeiden. Sowohl die Kosten als auch insbesondere die Akzeptanz der eGK werden durch einen derartigen Kartentausch massiv beeinflusst.
Ein einheitliches minimales Sicherheitsniveau der eGK ist festzulegen.
Dabei ist ein Kompromiss zwischen den Sicherheits- und den Wirtschaftlichkeitsanforderungen im Gesundheitswesen zu finden. Eine
Abstimmung mit dem Datenschutz und BSI hat stattzufinden.
Alternativen
Keine, da die Modularität der Anwendungen von den Karten unterstützt
werden muss.
Entscheidung
Als flexible Multifunktionskarte muss die eGK die heute geplanten sowie zukünftige Anwendungen im Gesundheitswesen unterstützen können. Die Spezifikation der eGK ist dabei technikoffen zu gestalten, das
heißt Architekturentscheidungen (wie etwa Speicherung der medizinischen Daten auf Server versus Karte) werden durch die Spezifikation
der eGK nicht vorweggenommen. Damit dies gewährleistet werden
kann, wird eine Auftrennung der Spezifikation in

die Spezifikation der Funktionalitäten des Kartenbetriebssystems
(„Spezifikation eGK“) und

die Spezifikationen der einzelnen Kartenanwendungen („Spezifikation Applikation XYZ“)
durchgeführt. Bei der Auswahl der Funktionalitäten sind die Wechselwirkung mit der HPC sowie die Eigenschaften marktgängiger Karten
und Kartenbetriebssysteme zu berücksichtigen.
Die Nachpersonalisierung ausgegebener Karten, insbesondere die
Verwaltung der Anwendungen auf der Karte und die Verwaltung und
© 2004
Seite
25 von 112
AE-R9
Bereich
Karten- und Einführungsstrategie der eGK
das Aufbringen von Sicherheitsobjekten wie etwa Schlüssel, Zertifikate
oder Zugriffskontrollinformation muss möglich sein.
Begründung
Nach §291 Absatz 2a SGB V erweitern die Krankenkassen die Krankenversichertenkarte bis spätestens zum 1. Januar 2006 zu einer elektronischen Gesundheitskarte. Die Regelung ist die gesetzliche
Grundlage für die Umsetzung des in der „Gemeinsamen Erklärung des
Bundesministeriums für Gesundheit und der Spitzenorganisationen
zum Einsatz von Telematik im Gesundheitswesen“ unter anderem gefassten Vorhabens, die Krankenversichertenkarte zu einer elektronischen Gesundheitskarte weiterzuentwickeln.
Implikation
Die Festlegung der einzelnen Anwendungen muss in der Lösungsarchitektur erfolgen.
Abhängige Archi- tekturentscheidungen
1.1.2 Informationsmodell
Tabelle 18: Architekturentscheidung: Zweistufige Aufteilung der Zugriffskontrollfunktion
AE/S-I1
Bereich
Annahmen
Zweistufige Aufteilung der Zugriffskontrollfunktion
Neben den gesetzlichen Regelungen für den Zugriff auf die eGK werden von den Versicherten individuelle Rechte für einzelne Heilberufler
und/oder Institutionen im Gesundheitswesen vergeben.
Motivation
Die Granularität der Autorisierungen durch den Versicherten haben
unterschiedliche Stufen. Neben den im GMG beschriebenen Zugriffsrechten für einzelne Berufsgruppen werden Versicherte zukünftig
auch individuelle Rechte für einzelne Heilberufler oder Institutionen im
Gesundheitswesen einrichten und verwalten. Eine feingranulare Verwendung von Zugriffsrechten wird insbesondere bei der Verwendung
der fallbezogenen oder fallübergreifenden ePatientenakte erwartet.
Folgende Stufen sind von den bIT4health Diensten zu unterstützen:
Granularität der Autorisierung: Benutzergruppen
Der Versicherte kann den Zugriff von Benutzergruppen (z.B. Ärzte,
Apotheker) auf die freiwilligen Anwendungen nach § 291a Absatz 3
Nr. 2-6 erlauben, z.B. alle Apotheken und Arzte auf die Arzneimittelhistorie.
Granularität der Autorisierung: Einzelne Heilberufler auf Anwendungen
Ein Versicherter muss die Möglichkeit haben explizit einzelne Leistungserbringer auf die Anwendungen nach § 291 a Absatz 3 Nr. 2-6
SGB V autorisieren. Die Einwilligung ist jederzeit widerruflich und
kann auf einzelne Anwendungen beschränkt werden (§291 a Absatz 3
SGB V).
Alternativen
Die personenbezogene Prüfung der Zugriffsrechte von dem Betriebssystem der Karte und die Änderung dieser Rechte durch den Versicherten kann beim Stand der Technik heute nicht empfohlen werden.
© 2004
Seite
26 von 112
AE/S-I1
Bereich
Nachteile:
Eine Prüfung von X.509 Zertifikaten oder der in [HBA] vorgesehenen
Privilege Attribut Certificates (PAC) auf einer eGK ist technisch auf
den heutigen Karten ohne eine Änderung der Kartenbetriebssysteme
nicht möglich und darüber hinaus so zeitaufwendig, dass die geforderten Antwortzeiten nicht zu erhalten sein werden.
Die Zugriffskontrolllisten der einzelnen Anwendungen sind häufig zu
ändern und die Größe der einzelnen Listen kann stark anwachsen, so
dass die geforderten Antwortzeiten überschritten werden können.
Ein versehentliches Überschreiben der vorgeschriebenen Regeln vom
Versicherten kann angesichts der Komplexität der Verwaltung der
Zugriffsrechte nicht ausgeschlossen werden.
Entscheidung
Die Zugriffskontrollfunktion auf die Anwendungen nach §291 SGB V
wird in der bIT4health Rahmenarchitektur in zwei Stufen aufgeteilt
und die Zugriffskontrollfunktionen werden an unterschiedlichen Stellen
der Rahmenarchitektur platziert:

Generelle Zugriffsrechte (siehe GMG) für Berufsgruppen und die
zugehörigen im Gesundheitswesen festgelegte Rollen. Diese
Zugriffsrechte werden direkt von dem Betriebssystem der eGK
bzw. einer Serverkomponente geprüft und Zugriffe entsprechend
den vorgegebenen Regelungen erlaubt.

Spezifische Zugriffsrechte4 auf einzelne Angehörige einer Berufsgruppe für einzelne Anwendungen mit der jeweiligen Autorisierung
des Versicherten. Diese Zugriffsrechte werden innerhalb der
bIT4health Dienste, aber außerhalb der eGK z.B. im Kartenterminal oder auf dem Server geprüft.
Begründung
-
Implikation
-
Tabelle 19: Architekturentscheidung: Authentisierung zwischen HBA und eGK
AE/S-I2
Bereich
Annahmen
Gegenseitige Authentisierung zwischen HBA und eGK
Die Zugriffe auf die freiwilligen Anwendungen und die elektronischen
Verordnungen setzen eine gegenseitige Authentisierung zwischen der
eGK und einem Heilberufsausweis voraus. Es ist davon auszugehen,
dass die relevanten Benutzergruppen sowohl mit personenbezogenen
Ausweisen als auch mit institutionsbezogenen Ausweisen ausgestattet sind.
Es ist zulässig, nicht-personenbezogene Karten in direkter Verbin-
4
Weitergehende Prüfungen der Zugriffsrechte innerhalb einer Anwendung können in diesen Komponenten zusätzlich noch
durchgeführt werden. Dies kann beispielsweise bei der Realisierung der ePatientenakte notwendig werden. Es kann aber u.A.
auch eine weitere Einschränkung der Zugriffe aufgrund des Erforderlichkeitsvorbehaltes erfolgen. Beispielsweise kann in dieser
Komponenten der Zugriff für einen Apotheker auf Überweisungen oder Einweisungen eingeschränkt werden.
© 2004
Seite
27 von 112
AE/S-I2
Bereich
Gegenseitige Authentisierung zwischen HBA und eGK
dung mit einer HBA in deren Auftrag als HBA fungieren zu lassen. Zu
einem Zeitpunkt können mehrere nicht-personenbezogene Karten
gleichzeitig einem HBA zugeordnet sein und im Auftrag fungieren.
Die Vergabe des Rechts zum Zugriff auf klinische Basisdaten (Notfalldaten) im Falle von Angehörigen eines anderen Heilberufs, der für
die Berufsausübung oder die Führung der Berufsbezeichnung eine
staatliche geregelte Ausbildung erfordert und die keinen elektronischen HBA besitzen (sog. nichtapprobiertes Medizinpersonal), kann
einmalig für einen befristeten Zeitraum durch Personen, die über einen HBA oder einen entsprechenden Berufsausweis verfügen, erfolgen. Danach ist der Zugriff auf klinische Basisdaten (Notfalldaten) für
diesen Zeitraum generell, einzelfall-unbezogen erlaubt.
Es wird davon ausgegangen, dass der Versandhandel in der Regel
den Zugriff auf eRezepte durch Versandhandel nur mittels eines vorhandenen HBA durchführt.
Motivation
Für die Kartenauthentisierung der Gesundheitskarte mit den Heilberufsausweisen wird ein asymmetrisches Verfahren empfohlen. Dabei
werden die in [HBA] definierten Algorithmen verwendet und eine entsprechende PKI für Card Verifiable Authentication Zertifikate ist für die
eGK aufzubauen.
Die Modellierung der komplexen Zugriffsstruktur durch symmetrische
Schlüsselverfahren kann nur mit einem sehr hohen Aufwand für das
Key Management realisiert werden. Daher sind für dieses Anforderungsprofil (m:n) asymmetrische Verfahren zu bevorzugen.
Alternativen
keine - Für die weitere technische Ausgestaltung siehe [b4heGK]
Entscheidung
Die Authentifizierung der eGK gegenüber einer HBA erfolgt direkt auf
Betriebssystemebene der Karten, d.h. mittels direkter wechselseitiger
Authentifizierung „Karte zu Karte“.
Eine Festlegung des Authentisierungsverfahrens zwischen der elektronischen Gesundheitskarte und dem Heilberufsausweis hat bis zur
Produktion von Testkarten zu erfolgen. Notwendige Infrastrukturkomponenten, u.A. die Bereitstellung von Schlüsseln für Kartenzertifikate
oder das Schlüsselmanagement kartenindividueller Schlüssel, sind
dazu rechtzeitig bereitzustellen.
Begründung
-
Implikation
-
Abhängige Architekturentscheidungen
-
Tabelle 20: Architekturentscheidung: Festlegungen der Eigenschaften der PIN
AE/S-I3
Bereich
Annahmen
Eigenschaften der PIN
Für die Autorisierung des Zugriffs auf die freiwilligen Anwendungen
wird durch den Versicherten eine PIN verwendet.
© 2004
Seite
28 von 112
Motivation
Die minimalen Anforderungen an eine PIN sind festzulegen. Beispielsweise hat die Länge der PIN großen Einfluss auf das Sicherheitsniveau. Damit das Erraten und Ausprobieren einer PIN möglichst
schwierig ist, sollte die PIN möglichst viele Stellen haben. Damit sich
die Benutzer die PIN jedoch merken können, muss hier ein Kompromiss geschlossen werden. Falls die Benutzer die PIN selbst wählen
können, ist es üblich, eine längere PIN zu fordern. Dies ist außerdem
sehr empfehlenswert, da bei Selbstwahl-PINs die Gleichverteilung
nicht mehr gewährleistet ist und sich somit die Sicherheitsproblematik
bezüglich der PIN-Länge verschärft. Gebräuchliche Verfahren verwenden für eine zugewiesene PIN nicht weniger als 4 und üblicherweise nicht mehr als 6 Zeichen. Für eine durch den Versicherten gewählte PIN sind nicht weniger als 6 und nicht mehr als 12 Zeichen
üblich. Der Umfang der Zeichen für die PIN-Eingabe (numerisch oder
alphanumerisch) muss festgelegt werden. Aufgrund der Beschränkung der sicheren PIN-Eingabegeräte für Kartenleser sind in diesem
Umfeld numerische PINs üblich.
Um die Anzahl der möglichen Rateversuche zu begrenzen, wird die
Anzahl der möglichen Falscheingaben üblicherweise auf drei beschränkt und danach die weitere PIN-Eingabe gesperrt.
Alternativen
Keine
Entscheidung
Die Länge der PIN, die maximale Anzahl der PIN Fehlbedienungen
und Verfahren zur PIN Rücksetzung sind in der Lösungsarchitektur zu
definieren.
Begründung
-
Implikation
-
-
Tabelle 21: Architekturentscheidung: Autorisierung des Zugriffs auf die freiwilligen Anwendungen durch Vertreter
und Vertreter-PIN
AE/S-I4
Bereich
Annahmen
Autorisierung des Zugriffs auf die freiwilligen Anwendungen
durch Vertreter und Vertreter-PIN sowie Zugriffsrechte eines Vertreters.
Der Patient kann rechtzeitig eine Person seines Vertrauens für die
Zustimmung in Gesundheitsangelegenheiten bevollmächtigen (Vorsorgevollmacht). Diese Vorsorgevollmacht soll für die Geschäftsvorfälle der eGK technisch abgebildet werden.
© 2004
Seite
29 von 112
AE/S-I4
Bereich
Motivation
Autorisierung des Zugriffs auf die freiwilligen Anwendungen
durch Vertreter und Vertreter-PIN sowie Zugriffsrechte eines Vertreters.
Aufgrund der Erweiterung der KVK zur Gesundheitskarte sind neue
Anwendungen hinzugekommen, deren Zugriff vom Versicherten autorisiert werden muss. Der Versicherte kann diese Autorisierung an andere Personen delegieren (Vorsorgevollmacht).
Mit der Verwendung einer PIN autorisiert und ermöglicht der Versicherte Zugriff auf das Patientenfach und die freiwilligen Anwendungen
der eGK nach § 291a Abs. 3 Satz 1 und 2 SGB V.
Die Ausgabe dieser PIN sollte, wie im Strafrecht, auf die Einsichtsfähigkeit des Patienten abgestellt werden, nicht auf dessen Geschäftsfähigkeit im bürgerlich-rechtlichen Sinne. Die nötige Einsichtsfähigkeit können auch Minderjährige und Betreute haben. Insbesondere bei schweren Eingriffen kann auch bei vorhandener Einsichtsfähigkeit des Minderjährigen zusätzlich zu dessen Zustimmung die Zustimmung des gesetzlichen Vertreters – dies sind in der Regel die
Eltern – erforderlich sein (siehe [PAR]) .
Die Ausgabe einer PIN (ermöglicht Zugriff auf Patientenfach und freiwillige Anwendungen der eGK nach § 291a Abs. 3 Satz 1 und 2 SGB
V) ist auch vor Erreichen des 18. Lebensjahres (Volljährigkeit) möglich. Das Alter, ab dem eine PIN vergeben wird, muss in der Lösungsarchitektur festgelegt werden. Wesentlich ist, wann ein Jugendlicher
erstmals allein zum Leistungserbringer geht und dort höchstpersönliche Daten, über sich preisgeben muss. Nur bei Kleinkindern, die ihren
Willen noch nicht artikulieren können, wird man davon ausgehen können, dass sie durch ihre Eltern, als ihre gesetzliche Vertreter, vertreten werden dürfen.
Entscheidung
Alternativen
Für die Umsetzung der technischen Optionen zur Vertretungsregelung ist in der Lösungsarchitektur zu klären:

wie eine Vertreterregelung eingeführt werden kann,

ob eine Änderung der §§ 291, 291a SGB V erforderlich ist,

ob es genügen würde, die umfassenden und allgemein verständlichen Informationen nach § 291a Abs. 3 Satz 1 SGB V des Versicherten/Mitversicherten zu erweitern,

ob die Kostenträger die dauerhaften Vertretungen prüfen und im
Versichertenverzeichnis (§ 288 SGB V) speichern dürfen,

ob bei schweren Eingriffen, die auch bei vorhandener Einsichtsfähigkeit des Minderjährigen/Betreuten noch notwendige zusätzliche
Zustimmung des gesetzlichen Vertreters/Betreuers, auch technisch abgedeckt werden soll und

ob der bevollmächtigte Vertreter alle Zugriffsrechte des Versicherten auf die Gesundheitsdaten übernimmt.
Vertretungen und Vertretungsregeln werden auf der eGK nicht technisch abgebildet.
© 2004
Seite
30 von 112
Tabelle 22: Architekturentscheidung: Übertragung und Zwischenspeicherung von medizinischen Daten durch die
bIT4Health Dienste
AE/S-I5
Bereich
Annahmen
Motivation
Übertragung und Zwischenspeicherung von medizinischen Daten durch die bIT4health Dienste
Die medizinischen und personenbezogenen Daten sowie die Verordnungsdaten sind innerhalb der Telematikinfrastruktur sicher zu übertragen und temporär gespeichert. Ein einheitliches Sicherheitsniveau
wird durch die gewählte Lösungsarchitektur bereitgestellt.
Die bIT4health Rahmenarchitektur ist technikneutral gestaltet und
ermöglicht für die zu entwickelnde interoperable Lösungsarchitektur

kartenzentrierte Lösungen, in denen z.B. die Rezeptdaten komplett auf der eGK gespeichert und verwaltet werden,

kartengestützte Lösungen, in denen die eGK als reines Zugangsmedium (enthält nur die Referenz auf die Anwendung) dient und
die Verordnungs- und medizinischen Daten komplett auf dem Server gespeichert und verwaltet werden,

beliebige Mischformen, in denen der Speicherinhalt (z.B. kompletter Inhalt des Speicherobjekts und/oder Referenzen auf diese Objekte) jeweils auf eGK und/oder Server abgelegt sind.
Ein einheitliches Schutzniveau der übertragenen und zwischengespeicherten Daten muss von der gewählten Lösungsarchitektur sichergestellt werden.
© 2004
Seite
31 von 112
AE/S-I5
Bereich
Entscheidung
Übertragung und Zwischenspeicherung von medizinischen Daten durch die bIT4health Dienste
Die medizinischen und personenbezogenen Daten sowie die Verordnungsdaten

können über ungesicherte Netze übertragen werden, wenn diese
nach aktuellem Stand der Informationstechnik auf Netzwerkebene
verschlüsselt werden (z.B. SSL) sowie eine gegenseitige, sichere
Authentifizierung der beiden Entitäten des Gesundheitswesens
stattfindet (Client- und Server-Authentifizierung).

müssen zusätzlich in allen zwischenspeichernden Stellen verschlüsselt abgelegt werden, so dass ein Zugriff von Administratoren nicht erfolgen kann.
Eine Umschlüsselung medizinischer Daten durch Dritte (Server) wird
in der Regel nicht durchgeführt. In genau definierten Fällen, u. A.
Zugriff im Notfall oder bei Vertreterregelungen, ist eine Umschlüsselung medizinischer Daten durch Dritte möglich. Auch zur Erzeugung
sekundärer Datenströme - z.B. pseudonymisierter Daten für Statistikauswertung- ist eine Umschlüsselung medizinischer Daten durch Dritte möglich.
Eine eventuell erforderliche Umschlüsselung ist nur in speziellen gesicherten Bereichen innerhalb eines Security Servers mit einem
Hardware Security Modul möglich. Dieser ist durch gesonderte organisatorische und technische Maßnahmen so abzusichern, dass ein
Zugriff auf die während der Umschlüsselung im Klartext vorliegenden
Daten nicht möglich ist.
Daten auf dem Server sind in der Regel ohne einen Personenbezug
abgelegt.
Das Sicherheitskonzept der Lösungsarchitektur ist vom BSI zu beurteilen. Dabei sind sicherheitskritische Komponenten nach internationalen Standards (z.B. CC) zu evaluieren. Dem Bundesbeauftragte für
den Datenschutz ist Gelegenheit zur Stellungnahme zu geben (§291
a Absatz (5) und (7) SGB V).
Alternativen
Keine – Die interoperable Lösungsarchitektur muss ein einheitliches
Sicherheitsniveau gewährleisten und der Schutz der personenbezogenen Daten ist unabhängig von der Realisierung gleichartig zu gestalten.
Tabelle 23: Architekturentscheidung: Schutz aller Sicherheitsobjekte der eGK
AE/S-I6
Bereich
Annahmen
Schutz aller Sicherheitsobjekte der eGK
Neben PIN/TAN für die Autorisierung des Zugriffs auf die freiwilligen
Anwendungen und ggf. die elektronischen Verordnungen (§291 a
Absatz 5 Satz 5 SGB V) sind auch die Schlüssel und Zertifikate für die
Sicherheitsfunktionen auf der eGK zu verwalten.
Motivation
-
© 2004
Seite
32 von 112
AE/S-I6
Bereich
Entscheidung
Schutz aller Sicherheitsobjekte der eGK
Sicherheitsobjekte sind bei der Übertragung bzw. Zwischenspeicherung außerhalb der Sicherheitsfunktionen und der Sicherheitskomponenten durch starke kryptographische Verfahren zu schützen, durch

Verschlüsseln (z.B. alle sensitive kryptographische Schlüssel)

Schützen der Integrität (z.B. öffentliche Schlüssel (z.B. in Zertifikaten) oder Zugriffsrechte und Privilegien (z.B. durch PACs)).
Ein unberechtigter Zugriff und die unberechtigte Verwendung dieser
Sicherheitsobjekte außerhalb der dazu festgelegten Sicherheitsdienste (siehe b4h Komponentenmodell) ist auszuschließen. Die Sicherheitsfunktionen stellen innerhalb des Gesundheitswesens eine logisch
abgetrennte Benutzergruppe – mit eigenen Karten und Schlüsselkreisen - dar. Die Verschlüsselungsfunktionen sind auf die Inhaber der
eGK und HBA zu beschränken und es ist durch eine Schlüsseltrennung auszuschließen, dass medizinische Daten außerhalb dieser
berechtigten Benutzergruppe entschlüsselt werden können.
Alternativen
Keine
Tabelle 24: Architekturentscheidung: Zugriff auf das Karten- und Keymanagement der eGK von einer (und nur
einer) der Karte zugeordneten Stelle
AE/S-I6
Bereich
Annahmen
Zugriff auf das Karten- und Keymanagement der eGK von einer
(und nur einer) der Karte zugeordneten Stelle
Die eGK muss technisch geeignet sein, Authentifizierung, Verschlüsselung und elektronische Signatur zu ermöglichen (§291 Absatz 2a
SGB V).
Neben PIN/TAN für die Autorisierung des Zugriffs auf die freiwilligen
Anwendungen ggf. die elektronischen Verordnungen (§291 a Absatz
5 Satz 5) sind auch die Schlüssel und Zertifikate für die oben geforderten Sicherheitsfunktionen auf der eGK zu verwalten.
Motivation
Für die Kartenauthentisierung zum Zugriff auf die administrativen
Funktionen mit der eGK wird ein symmetrisches Verfahren empfohlen. Die in [HPC] definierten Algorithmen (3DES) werden verwendet
und entsprechende symmetrische Ableitungsschlüssel für kartenspezifische Schlüssel sind von einer zentralen Stelle sicher zu erzeugen
und in die Karten zu verteilen.
Der Zugriff für das Management der Kartenanwendungen und Sicherheitsobjekte erfolgt für jede Karte jeweils zentral von einer, dem Kartenherausgeber zugeordneten Stelle. Diese Stelle hat die vollen
Rechte zur Änderung der Kartenstruktur. Die Änderung z.B. der
Zugriffsrechte und die damit verbundene Aktivierung von Anwendungen ist

bei auszugebenden Ersatzkarten aufzubringen und

auch an zentralen Anwendungen – falls vorhanden – weiterzugeben.
Daher müssen diese sicherheitsrelevanten Daten an einer für die Karte zentralen Stelle zusammenfasst und verwaltet werden.
Entscheidung
Das Management der freiwilligen Anwendungen und der Sicherheits© 2004
Seite
33 von 112
AE/S-I6
Bereich
Zugriff auf das Karten- und Keymanagement der eGK von einer
(und nur einer) der Karte zugeordneten Stelle
objekte auf einer eGK wird von jeweils einer (und nur einer) der Karte
zugeordneten Stelle durchgeführt.
Alternativen
Keine - Eine wechselwirkungsfreie gleichzeitige und unabgestimmte
Administration einer eGK von mehreren Stellen ist technisch aufwendig zu realisieren.
1.1.3 Sicherheitsinfrastruktur
2.2.1.1 Sicherheitsdienste
Tabelle 25: Architekturentscheidung Sicherheitsarchitektur nach ISO 7498-2
AE/S-E1.1
Bereich
Annahmen
Sicherheitsarchitektur nach ISO 7498-2
Die Rahmenarchitektur orientiert sich an SAGA (Standards und Architekturen für eGovernment Anwendungen, [SAGA]) als deutschen,
weitgehend akzeptierten und verbreiteten Standard für Anwendungen
im - sowie im Umfeld von - eGovernment Anwendungen.
Motivation
SAGA sieht eine Architektur gemäß RM-ODP (Reference Model of
Open Distributed Processing, [RM-ODP]) vor, die wiederum auf einer
Sicherheitsarchitektur nach ISO 7498-2 und ISO 10181 beruht.
Die der Rahmenarchitektur zu Grunde liegende Sicherheitsarchitektur
orientiert sich an dem internationalen ISO Standard:
ISO 7498-2: OSI Basic Reference Model – Part 2: Security Architecture [ISO7498-2].
Entscheidung
Die zu verwendenden Sicherheitsdienste orientieren sich an folgenden ISO Standards:
ISO 10181 Part 2: Authentication framework [ISO10181-2]
Alternativen

ISO 10181 Part 3: Access control framework [ISO10181-3]

ISO 10181 Part 4: Non-repudiation framework [ISO10181-4]

ISO 10181 Part 5: Confidentiality framework [ISO10181-5]

ISO 10181 Part 6: Integrity framework [ISO10181-6]

ISO 10181 Part 7: Security audit and alarms framework
[ISO10181-7]
Keine, da RM-ODP für die Architektur festgelegt ist.
© 2004
Seite
34 von 112
Tabelle 26: Architekturentscheidung Aufgaben und Abgrenzung der Sicherheitsinfrastruktur 5
AE/S-E1.2
Bereich
Annahmen
Motivation
Entscheidung
Alternativen
Der Schwerpunkt der technischen Komponenten der Sicherheitsinfrastruktur ist

die Bereitstellung von IT Sicherheitsdiensten für die Anwendungen
und Infrastrukturkomponenten der Telematikinfrastruktur,

das Management der Sicherheitsobjekte (z.B. Schlüssel und Karten).
Die Einführung einer Telematikinfrastruktur im Gesundheitswesen mit
der damit verbundenen Unterstützung der entsprechenden Geschäftsvorfälle durch Informationstechnologie hat eine deutliche Erhöhung der IT-Risiken zur Folge. Um diese auf ein im Gesundheitswesen akzeptables Niveau zu reduzieren, ist der Aufbau einer entsprechenden Sicherheitsinfrastruktur, neben zahlreichen anderen
Maßnahmen, notwendig.
Die Sicherheitsinfrastruktur ist als Infrastrukturkomponente anwendungsneutral definiert und muss als Basis für beliebige Anwendungen
aufgebaut werden.

Die Sicherheitsinfrastruktur stellt anwendungsübergreifend Dienste zur Verfügung, um die definierten Schutzziele sicherzustellen.

Die Anwendungen müssen die Sicherheitsdienste über einheitliche Schnittstellen nutzen.

Die Sicherheitsinfrastruktur berücksichtigt die folgenden Sicherheitsmanagementprozesse in den funktionalen Anforderungen:
-
Administration von Identitäten, Benutzern und Berechtigungen
sowie von Authentifizierungs- und Autorisierungsinformationen.
-
Erzeugung, Sammlung und Zusammenführung sicherheitsrelevanter Ereignisse in einem Audit-Trail.
Keine – Eine anwendungsspezifische Definition der Sicherheitskonzepte sowie Integration der Sicherheitsmechanismen in einzelnen
Anwendungen und Komponenten ist weder effektiv noch effizient.
Tabelle 27: Architekturentscheidung Benutzerbestimmbare Informationsflusskontrolle, BISS
AE/S-E1.3
Bereich
Annahmen
Benutzerbestimmbare Informationsflusskontrolle, BISS
Die Kontrolle des Informationsflusses zwischen den Anwendungskomponenten muss sichergestellt werden.
Motivation
Die Benutzerbestimmbare Informationsflusskontrolle (BISS) legt in
einem Schutzprofil die abstrakten Anforderungen an Systeme zur
Informationsflusskontrolle fest6. Durch die Informationsflussvor-
5
AE/S-E1 = Architekturentscheidung / Sicherheitsarchitektur - Enterprise View Nr. 1. Weitere RM-ODP Views werden ebenfalls
mit den entsprechenden Anfangsbuchstaben angedeutet: Computational View, Information View, Engineering View,
Technology View
6
Ein Informationsfluss wird bei BISS von einem Subjekt ausgelöst und ist durch die Angabe eines weiteren Subjekts, eines
Datenortes, eines ausgetauschten Objekts und einer Operation gekennzeichnet. Die zwischen Subjekten und Datenorten
© 2004
Seite
35 von 112
AE/S-E1.3
Bereich
Benutzerbestimmbare Informationsflusskontrolle, BISS
schriften kann die Authentizität, Integrität bzw. Vertraulichkeit der
ausgetauschten Information geschützt werden. Dazu muss in den
BISS-Informationsflussvorschriften mindestens festgelegt werden
können, dass die Information zu verschlüsseln bzw. zu signieren
oder die vorliegenden Daten zu entschlüsseln bzw. die Gültigkeit
von mit den Daten verknüpften Signaturen zu prüfen sind. Dabei
werden von den BISS Informationsflussregeln Parameter für zu
verwendende Verfahren und Schlüssel festgelegt. Darüber hinaus
können in Informationsflussvorschriften zum Lesen bzw. Schreiben
von Information weitere Funktionen einbezogen werden. Es kann
beispielsweise festgelegt werden, dass es notwendig ist, die vorliegenden Daten auf Virenfreiheit zu testen.
Entscheidung

Die Informationsflüsse zwischen den Anwendungskomponenten
der Telematikplattform können durch Module basierend auf einer erweiterten BISS Architektur gesteuert werden. Diese Module verwenden dann regelbasiert die Sicherheitsdienste, um
die kryptographischen Dienste für die Sicherung der Informationsflüsse nutzen zu können.

Die Integration der Anwendungskomponenten hinsichtlich der
Sicherheitsdienste kann mit dem BISS Schutzprofil evaluiert
werden. Eine Evaluierung dieser Integrationskomponenten im
Rahmen des BISS Schutzprofils wird empfohlen. Dabei sind jedoch alle Operationen bzw. Geschäftsvorfälle über die Telematikplattform zu berücksichtigen.

Eine Steuerung der Informationsflüsse in den Primärsysteme
bzw. Backend Systemen ist außerhalb der Telematikinfrastruktur und wird daher nicht betrachtet.
Alternativen
Ein Kontrolle des Informationsflusses wird anwendungsspezifisch
realisiert.
fließende Information bildet zusammen mit dem Behälter, in dem sie aufbewahrt wird, das kontrollierte Objekt. Durch eine Liste
hierarchischer Informationsflussregeln werden in BISS die erlaubten, ausgetauschten Informationsobjekte festgelegt. Eine
Informationsflussregel besteht aus den folgenden Angaben:

Eine Operation – Operationen sind Read (S,I,O), Write(S,I,O), die abhängig sind vom Subjekt (S), den
ausgetauschten Information (I) und dem Objekt bzw. der Anwendung (O).

Eine Menge von Subjekten – Ein Subjekt wird identifiziert durch eine eindeutige Benutzerkennung (z.B. E-MailAdresse bzw. einem DN) und eine aktive funktionale Einheit (z.B. eine Applikation).

Eine Menge von Datenorten – Ein Datenort wird durch die ausgetauschte Information (I) bzw. das Objekt (O) oder die
verarbeitende Anwendung festgelegt. Für Netzverbindungen typisch ist die Angabe einer E-Mail-Adresse des
Postfachs.

Eine Menge von Steuerwerten (Flags) – Flags steuern die Verarbeitung innerhalb des BISS Moduls. Definiert ist ein
Kontrollflag (Bez. CF), ein Vertrauenswürdigkeitsflag (Bez. TF) und ein Protokollierungsflag (Bez. PF).

Eine Menge von Informationsflussvorschriften – Diese bestimmen die Algorithmen zum Schutz der Authentizität,
Integrität bzw. Vertraulichkeit der ausgetauschten Information.
© 2004
Seite
36 von 112
Tabelle 28: Architekturentscheidung Identitätsverwaltung
AE/S-C1.1
Bereich
Annahmen
Identitätsverwaltung für Versicherte
Das existierende Versichertenverzeichnis bei den Kostenträgern
nach §288 SGB V wird erweitert, um die Identitätsdaten der Versicherten aufzunehmen.
Motivation
Die Verwaltung der Identitäten und somit der Versicherten der Telematikinfrastruktur wird dezentral in der Verantwortung der entsprechenden Kostenträger erfolgen. Somit liegt die Identifizierung der
Teilnehmer und die Vergabe und Zuordnung der eindeutigen Identitätsnummern bei den Kostenträgern. Diese führen entsprechende
Versichertenverzeichnisse, die die Identitätsdaten enthalten.
Entscheidung

Die Identifizierung und Zuordnung der eindeutigen Identitätsnummern erfolgen dezentral in der Verantwortung der Kostenträger.

Die derzeitigen Fachverfahren zwischen den Karteninhabern und
dem Kartenherausgeber sind auf das Sicherheitsniveau der eGK
anzupassen (Identifizierung, Registrierung).

Die Identitätsdaten der Versicherten werden von den Kostenträgern in übergreifenden Verzeichnissen bzw. über einen einheitlichen, übergreifenden Zugang der Telematikinfrastruktur zur Verfügung gestellt.

Die Kostenträger sind für die Richtigkeit und Aktualität der in ihrer
Hoheit befindlichen Daten zuständig.

Identitätsfeststellung und Identitätsverwaltung liegen in der Hoheit
der Telematikinfrastruktur oder externer Dienstleister.
Alternativen
Tabelle 29: Architekturentscheidung Authentifizierungsdatenverwaltung
AE/S-C1.2
Bereich
Annahmen
Authentifizierungsdatenverwaltung
Authentifizierungsdaten müssen übergreifend
infrastruktur bereitgestellt werden.
Motivation
Die Erzeugung, Verteilung und Verwaltung von Authentifizierungsinformationen liegt aus Sicherheitsgründen nicht in der Hoheit der Kostenträger. Z.B. darf die PIN zum Zugriff auf freiwillige Anwendungen
zu keinem Zeitpunkt in den Systemen des Kostenträgers vorhanden
sein (weder verschlüsselt noch unverschlüsselt).
Die Datenhoheit der sicherheitskritischen Authentifizierungsinformationen liegt in der Telematikinfrastruktur.
Entscheidung

Alternativen
der
Telematik-
Authentifizierungsdaten verlassen die Sicherheitskomponenten
der Telematikinfrastruktur zu keinem Zeitpunkt in ihrem Lebenszyklus.
Authentifizierungsdaten sind den Geschäftsanwendungen und komponenten zugeordnet und werden anwendungsspezifisch verwendet. Dies widerspricht der Architekturentscheidung E1.2.
© 2004
Seite
37 von 112
Tabelle 30: Architekturentscheidung Authentifizierungsschnittstelle
AE/S-C1.3
Bereich
Annahmen
Authentifizierungsschnittstelle
Authentifizierungsinformationen sind nur in den Sicherheitskomponenten der Telematikinfrastruktur vorhanden und müssen algorithmenneutral über eine einheitliche Dienstschnittstelle zur Verfügung
gestellt werden.
Motivation

Entkopplung einzelner Anwendungssysteme

Austauschbarkeit einzelner Authentifizierungsverfahren

Unterstützung unterschiedlicher Authentifizierungsverfahren
Entscheidung
Es wird eine einheitliche, verfahrens- und protokollunabhängige Authentifizierungsschnittstelle angeboten, die von Anwendungen zur
Authentifizierung verwendet werden muss.
Alternativen
Pro Authentifizierungsverfahren eigene Schnittstellen und Protokolle
Tabelle 31: Architekturentscheidung Zweistufige Aufteilung der Zugriffskontrollfunktion
AE/S-C2.1
Bereich
Annahmen
Neben den gesetzlichen Regelungen für den Zugriff auf die eGK werden von den Versicherten individuelle Rechte für einzelne Heilberufler
und/oder Institutionen im Gesundheitswesen vergeben.
Motivation
Die Granularität der Autorisierungen durch den Versicherten haben
unterschiedliche Stufen. Neben den im GMG beschriebenen Zugriffsrechten für einzelne Berufsgruppen werden Versicherte zukünftig
auch individuelle Rechte für einzelne Heilberufler oder Institutionen im
Gesundheitswesen einrichten und verwalten. Eine feingranulare Verwendung von Zugriffsrechten wird insbesondere bei der Verwendung
der fallbezogenen oder fallübergreifenden ePatientenakte erwartet.
Folgende Stufen sind von den bIT4health Diensten zu unterstützen:
Entscheidung

Granularität
der
Autorisierung:
Benutzergruppen
Der Versicherte kann den Zugriff von Benutzergruppen (z.B. Ärzte, Apotheker) auf die freiwilligen Anwendungen nach § 291a Absatz 3 Nr. 2-6 SGB V erlauben, z.B. alle Apotheken und Ärzte auf
die Arzneimittelhistorie.

Granularität der Autorisierung: Einzelne Heilberufler auf Anwendungen
Ein Versicherter muss die Möglichkeit haben, explizit einzelne
Leistungserbringer für den Zugriff auf die Anwendungen nach §
291 a Absatz 3 Nr. 2-6 SGB V zu autorisieren. Die Einwilligung ist
jederzeit widerruflich und kann auf einzelne Anwendungen beschränkt werden (§291 a Absatz 3 SGB V).
Die Zugriffskontrollfunktion auf die Anwendungen nach §291 SGB V
wird in der bIT4health Rahmenarchitektur in zwei Stufen aufgeteilt
und die Zugriffskontrollfunktionen werden an unterschiedlichen Stellen
der Rahmenarchitektur platziert:

Generelle Zugriffsrechte (siehe [GMG]) für Berufsgruppen und die
zugehörigen im Gesundheitswesen festgelegten Rollen.

Diese Zugriffsrechte werden direkt von dem Betriebssystem der
© 2004
Seite
38 von 112
AE/S-C2.1
Bereich
eGK bzw. einer Serverkomponente geprüft und Zugriffe entsprechend den vorgegebenen Regelungen erlaubt.

Spezifische Zugriffsrechte7 auf einzelne Angehörige einer Berufsgruppe für einzelne Anwendungen mit der jeweiligen Autorisierung
des Versicherten.
Diese Zugriffsrechte werden innerhalb der bIT4health Dienste, aber außerhalb der eGK - z.B. im Kartenterminal oder auf dem Server - überprüft.
Alternativen
Alle Zugriffsrechte, d.h. generelle und spezifische, werden auf der
eGK verwaltet und bei Zugriffsanfragen überprüft.
Die personenbezogene Prüfung der Zugriffsrechte von dem Betriebssystem der Karte und die Änderung dieser Rechte durch den Versicherten kann beim heutigen Stand der Technik nicht empfohlen werden.
Nachteile dieser Alternative:

Eine Prüfung von X.509 Zertifikaten oder der in [HBA] vorgesehenen Privilege Attribut Certificates (PAC) auf einer eGK ist technisch auf den heutigen Karten ohne eine Änderung der Kartenbetriebssysteme nicht möglich und darüber hinaus so zeitaufwendig,
dass die geforderten Antwortzeiten nicht zu erreichen sein werden.

Die Zugriffskontrolllisten der einzelnen Anwendungen sind häufig
zu ändern und die Größe der einzelnen Listen kann stark anwachsen, so dass die geforderten Antwortzeiten überschritten werden
können.

Ein unbeabsichtigtes Überschreiben der vorgeschriebenen Regeln
vom Versicherten kann angesichts der Komplexität der Verwaltung der Zugriffsrechte nicht ausgeschlossen werden.
2.2.1.2 Sicherheitsmechanismen
Tabelle 32: Architekturentscheidung Wechsel von Sicherheitsalgorithmen
AE/S-C3.1
Bereich
Annahmen
Bei der Architektur der Schnittstellen der Sicherheitsinfrastruktur muss
darauf geachtet werden, dass eine Abhängigkeit von konkreten Sicherheitsalgorithmen und -produkten weitestgehend vermieden wird.
Motivation
Eine Umstellung auf einen anderen, z.B. stärkeren Algorithmus, sollte
möglichst transparent möglich sein, um unnötige Umstellungskosten zu
vermeiden und eine Koexistenzphase für die Migration zu unterstützen.
Entscheidung
Anbieten/Verwenden der Sicherheitsfunktionalitäten über standardisierte Schnittstellen. Dadurch ist eine Änderung in der dahinter liegen-
7
Weitergehende Prüfungen der Zugriffsrechte innerhalb einer Anwendung können in dieser Komponenten zusätzlich noch
durchgeführt werden. Dies kann beispielsweise bei der Realisierung der ePatientenakte notwendig werden. Es kann aber u.A.
auch eine weitere Einschränkung der Zugriffe aufgrund des Erforderlichkeitsvorbehaltes erfolgen. Beispielsweise kann in dieser
Komponenten der Zugriff für einen Apotheker auf Überweisungen oder Einweisungen eingeschränkt werden.
© 2004
Seite
39 von 112
AE/S-C3.1
Bereich
den Sicherheitskomponente leichter möglich und im Optimalfall von
außen gar nicht bemerkbar.
Schnittstellen sind noch festzulegen. Standardisierte Java Schnittstellen (JAAS, JCE, JMS) sollten bevorzugt werden.
Alternativen
Direkte Verwendung der Sicherheitsalgorithmen und Kyrpto-Libraries.
Tabelle 33: Architekturentscheidung eGK/HBA-Authentifizierung
AE/S-C3.2
Bereich
Annahmen
Motivation
eGK/HBA-Authentifizierung
Die Zugriffsrechte auf med. Daten des Versicherten sind im SGB V
§291a Absatz 4, 5 detailliert festgelegt. In §291a, Abs. 5 Privilege
Attribut Certificates heißt es:
„Der Zugriff auf Daten sowohl nach Absatz 2 Satz 1 Nr. 1 als auch
nach Absatz 3 Satz 1 mittels der elektronischen Gesundheitskarte
darf nur in Verbindung mit einem elektronischen Heilberufsausweis,
im Falle des Absatzes 2 Satz 1 Nr. 1 auch in Verbindung mit einem
entsprechenden Berufsausweis, erfolgen. [...]“.
Daraus folgt die Anforderung für eine gegenseitige Authentifizierung
der Karten (eGK, HBA) mit dem nachfolgenden Aufbau eines sicheren Kanals.
Die technische Ausprägung ist festzulegen.

Entscheidung
Alternativen
Eine gegenseitige Authentifizierung der HBA bzw. des Berufsausweises gegenüber der eGK und umgekehrt wird gefordert,
um sicherzustellen, dass
–
auf die eGK nur berechtigte Personen (z.B. über die
Auswertung auf der HBA/Berufsausweis vorhandenen
Attributen) zugreifen können.
–
Heilberufler nur auf gültige eGKs Daten schreiben können (und nicht auf andere Kartenkörper).

Die gegenseitige Authentifizierung der HBA/eGK soll technisch
einfach und mit hoher Performance erfolgen sowie im Sinne einer notwendigen Sicherheitsevaluierung als abgrenzbares Evaluierungstarget darstellbar sein.

Die HBA muss sich gegenüber der eGK authentifizieren.

Die eGK muss sich gegenüber der HBA authentifizieren.

Eine Überprüfung der Gültigkeit der Authentifizierungsinformationen im Rahmen der gegenseitigen Authentifizierung ist nicht
notwendig - weder offline (mit zeitnahen Gültigkeitsinformationen) noch online.
Im Rahmen eines jeden Authentifizierungsvorgangs muss die Gültigkeit der entsprechenden Authentifizierungsinformationen überprüft werden.
Tabelle 34: Architekturentscheidung Card2Application-Authentifizierung
AE/S-C3.3
Bereich
Card2Application-Authentifizierung
© 2004
Seite
40 von 112
AE/S-C3.3
Bereich
Annahmen
Card2Application-Authentifizierung
Es kann zukünftige Anwendungsszenarien geben, in denen die eGK
sich gegenüber einer Applikation/Anwendung authentifizieren müssen.
Motivation
Card2Application-Authentifizierung im Falle der eGK kann notwendig sein.
Entscheidung

Die eGK muss sich mittels Authentifizierungszertifikaten gegenüber Applikationen authentifizieren, falls eine direkte Kommunikation zwischen Karte und Applikation notwendig sein sollte.

Eine Prüfung der Gültigkeit des Authentifizierungszertifikats der
Karte muss technisch möglich sein, auch wenn nicht stets hiervon Gebrauch gemacht werden muss oder kann.

Die Prüfung der Gültigkeit der Authentifizierungszertifikate kann
online oder offline mit zeitnahen Gültigkeitsinformationen erfolgen.
Alternativen
Die Authentifizierungsinformationen liegen nicht auf der eGK.
Tabelle 35: Architekturentscheidung Applicaton2Server-Authentifizierung
AE/S-C3.4
Bereich
Annahmen
Application2Server-Authentifizierung
Applikationen/Anwendungen müssen sich gegenüber einem Server
authentifizieren.
Motivation
Nur berechtigte, innerhalb des Gesundheitswesens zugelassenen
Applikationen/Anwendungen dürfen mit Servern des Gesundheitswesen kommunizieren.
Entscheidung

Applicaton2Server-Authentifizierung nur mittels X.509 Authentifizierungszertifikaten.

Eine gegenseitige Authentifizierung ist notwendig (Client/ServerAuthentifizierung).

Eine Überprüfung der Gültigkeit der AuthentifizierungsZertifikate im Rahmen der Authentifizierung ist notwendig.

Die Prüfung der Gültigkeit der Authentifizierungszertifikate kann
online oder offline mit zeitnahen Gültigkeitsinformationen erfolgen.
Alternativen
Keine – Die Sicherstellung der Schutzziele erfordert eine starke
Client/Server-Authentifizierung.
Tabelle 36: Autorisierungsmechanismen
AE/S-C4.1
Bereich
Annahmen
Autorisierungsmechanismen
Der Versicherte hat die Möglichkeit, den Zugriff auf die eGK mittels
einer PIN zu autorisieren. Sowohl aus Sicht der verpflichtenden Anwendungen als auch aus Sicht der freiwilligen Anwendungen ist ein
Berechtigungssystem notwendig.
© 2004
Seite
41 von 112
AE/S-C4.1
Bereich
Motivation
Autorisierungsmechanismen
Nutzung etablierter, einfacher und wirtschaftlicher Mechanismen zur
Freigabe von Zugriffsrechten.
Entscheidung

Autorisierung des Zugriffs auf die eGK durch den Versicherten
erfolgt bevorzugt mittels PIN. Regeln zum Aufbau sowie der Länge der PIN und Regeln zur Wahl einer PIN durch den Versicherten sind festzulegen.

Autorisierungsmechanismen basierend auf biometrischen Verfahren sind unter dem Gesichtspunkt der Datensparsamkeit im Einzelfall kritisch zu bewerten. Nutzerfreundlichkeit darf kein Kriterium für den Einsatz biometrischer Verfahren darstellen. Der Einsatz biometrischer Verfahren bedarf es, dass die geforderte Sicherheitsstufe der Autorisierung nicht mit anderen Mitteln, die eine sparsamere Datenerhebung zu Grunde legen, erreichbar ist.
Auf diese Weise ist die Speicherung und Nutzung biometrischer
Daten zu rechtfertigen.

Die gesetzlich vorgegebenen Zugriffsregeln werden in jedem Fall
durch die Karte selbst zugesichert und können nicht umgangen
werden.

Darüber hinaus kann eine rollen-, gruppen- und identitätsbasierte
Verfeinerung der Berechtigungsvergabe erfolgen.

Keine Trennung der gesetzlichen Vorgaben von den identitätsbezogenen Zugriffskontrollrechten.

Eine Vermischung der Zugriffskontrollmechanismen erschwert
den Nachweis der Einhaltung der gesetzlichen Regelungen.
Durch Fehlkonfigurationen kann es unbeabsichtigt zu Verletzungen der gesetzlichen Vorgaben kommen.
Alternativen
Tabelle 37: Architekturentscheidung Vertraulichkeit
AE/S-C5.1
Bereich
Annahmen
Vertraulichkeit
Die Sicherstellung der Vertraulichkeit von Daten ist sowohl im Rahmen der Kommunikation als auch im Rahmen der Datenspeicherung
in zahlreichen Geschäftsvorfällen notwendig.
Motivation
Aufgrund der Architekturentscheidung, Sicherheitsdienste anwendungsübergreifend als Dienst zur Verfügung zu stellen, soll das
Schutzziel Vertraulichkeit mittels eines Dienstes realisiert werden.
Entscheidung

Bereitstellung eines anwendungsübergreifenden Dienstes zum
Schutz der Vertraulichkeit.

Algorithmen zur Wahrung der Vertraulichkeit sind modular und
einfach austauschbar.
Alternativen
Kryptographische Funktionen zur Sicherstellung der Vertraulichkeit
direkt in den Applikationen der Telematikinfrastruktur
© 2004
Seite
42 von 112
Tabelle 38: Architekturentscheidung Datenintegrität
AE/S-C6.1
Bereich
Annahmen
Datenintegrität
Die Sicherstellung der Integrität von Daten ist sowohl im Rahmen der
Kommunikation als auch im Rahmen der Datenspeicherung in zahlreichen Geschäftsvorfällen notwendig.
Motivation
Aufgrund der Architekturentscheidung, Sicherheitsdienste anwendungsübergreifend als Dienst zur Verfügung zu stellen, soll das
Schutzziel Datenintegrität mittels eines Dienstes realisiert werden.
Entscheidung

Bereitstellung eines anwendungsübergreifenden Dienstes zum
Schutz der Datenintegrität

Algorithmen zur Sicherstellung und Überprüfung der Datenintgerität sind modular und einfach austauschbar
Alternativen
Kryptographische Funktionen zur Sicherstellung der Integrität werden
direkt in die Applikationen der Telematikinfrastruktur integriert. Eine
Evaluierung der Sicherheitskomponenten wird komplexer, da das
Evaluierungstarget schwieriger abzugrenzen ist, und zusätzlich wird
ein Austausch von Mechanismen schwierig.
Tabelle 39: Architekturentscheidung Nicht-Abstreitbarkeit
AE/S-C7.1
Bereich
Annahmen
Nicht-Abstreitbarkeit
Die Sicherstellung der Nicht-Abstreitbarkeit ist sowohl im Rahmen
der Kommunikation als auch im Rahmen der Datenspeicherung in
zahlreichen Geschäftsvorfällen notwendig.
Motivation
Aufgrund der Architekturentscheidung Sicherheitsdienste, anwendungsübergreifend als Dienst zur Verfügung zu stellen, soll die
Nicht-Abstreitbarkeit mittels eines Dienstes realisiert werden.
Entscheidung

Bereitstellung eines anwendungsübergreifenden Dienstes zur
Sicherstellung der Nicht-Abstreitbarkeit

Verfahren zur Sicherstellung der Nicht-Abstreitbarkeit sind modular und einfach austauschbar
Alternativen
Anwendungsbezogene und -integrierte Funktionen zur Sicherstellung der Nicht-Abstreitbarkeit.
Tabelle 40: Ver- und Entschlüsselungsmechanismen
AE/S-C8.1
Bereich
Annahmen
Ver- und Entschlüsselungsmechanismen
In zahlreichen Geschäftsvorfällen ist eine kryptographische, starke
Verschlüsselung medizinischer Daten notwendig.
Motivation
Nutzung etablierter Mechanismen sowie Konformität zu nationalen
und internationalen Standardisierungsbestrebungen
© 2004
Seite
43 von 112
AE/S-C8.1
Bereich
Entscheidung
Alternativen
Ver- und Entschlüsselungsmechanismen
Die Ver- und Entschlüsselung von Inhalten aller Art (auch kryptografischen Materials) kann auf symmetrischen, asymmetrischen
sowie Hybridverfahren beruhen.

Es werden nur Verschlüsselungsalgorithmen gemäß der jeweils
aktuellen ISIS-MTT Spezifikation sowie der dort festgelegten Betriebsmodi eingesetzt [ISIS-MTT].

Der Einsatz mehrerer kryptographischer Verfahren gemäß ISISMTT muss parallel möglich sein.

Der Austausch kryptographischer Verfahren muss im Rahmen
einer modularen Architektur einfach möglich sein.
Festlegung eigener Interoperabilitätskriterien für das Gesundheitswesen
Tabelle 41: Zeitstempel
AE/S-C9.1
Bereich
Annahmen
Zeitstempel
In zahlreichen Geschäftsvorfällen sind zur Sicherstellung der Revisionssicherheit die Verwendung einer übergeordneten, sicheren Zeit
notwendig.
Motivation
und internationalen Standardisierungsbestrebungen.
Entscheidung
Zeitstempel sind gemäß ISIS-MTT Spezifikation in der jeweils aktuellen Version einzusetzen [ISIS-MTT].
Alternativen
Festlegung eigener Interoperabilitätskriterien für das Gesundheitswesen
2.2.1.3 Integritätsprüfung
Tabelle 42: Integritätsprüfung
AE/S-C10.1
Bereich
Annahmen
Integritätsprüfung
In zahlreichen Geschäftsvorfällen sind zur Sicherstellung der Authentizität Integritätsprüfungen notwendig.
Motivation
und internationalen Standardisierungsbestrebungen
Entscheidung

Es sind lediglich Hash-Verfahren gemäß ISIS-MTT Spezifikation
in der jeweils aktuellen Version einzusetzen [ISIS-MTT]. Hierbei
ist SHA-1 der bevorzugte Hash-Algorithmus.

Der Einsatz mehrerer Hash-Verfahren gemäß ISIS-MTT muss
parallel möglich sein.

Der Austausch eines Hash-Verfahrens muss im Rahmen einer
modularen Architektur einfach möglich sein.
© 2004
Seite
44 von 112
AE/S-C10.1
Bereich
Alternativen
Integritätsprüfung
Festlegung eigener Interoperabilitätskriterien für das Gesundheitswesen.
Tabelle 43: Digitale Signatur
AE/S-C11.1
Bereich
Annahmen
Digitale Signatur
Das GMG fordert, dass die eGK technisch geeignet ist, Authentifizierung, Verschlüsselung und elektronische Signatur zu ermöglichen. Digitale Signatur wird zudem benötigt, um die NichtAbstreitbarkeit bestimmter Geschäftsvorfälle zu gewährleisten.
Die Rahmenarchitektur muss zukünftige Optionen der Telematikinfrastruktur, die Authentifizierungs- und Signaturzertifikate auf der
eGK vorsehen können, abbilden können. Dies bedeutet, dass die
Erstellung elektronischer Signaturen als Sicherheitsmechanismus
angeboten werden können muss.
Motivation
Entscheidung
Alternativen

Elektronische Signaturen werden ausschließlich direkt auf der
eGK bzw. der HBA erstellt, unabhängig ob fortgeschrittene oder
qualifizierte Signatur.

Die Verifizierung elektronischer Signaturen wird über eine entsprechende Schnittstelle angeboten und erfolgt außerhalb der
eGK/HBA.

Erstellung fortgeschrittener elektronischer Signatur außerhalb
der eGK/HBA

Verifizierung elektronischer Signatur innerhalb der eGK/HBA
2.2.1.4 Speicherung Sicherheitsobjekte
Tabelle 44: Architekturentscheidung Sicherheitszonen
AE/S-En12.1
Bereich
Annahmen
Sicherheitszonen
Die Primärsysteme befinden sich in Bereichen, in denen der Zugang
von Versicherten möglich ist. Ein gestuftes Sicherheitskonzept ist
notwendig, um diese Systeme durch die Telematikinfrastruktur zu
verbinden und die Zusatzrisiken zu begrenzen.
Motivation
Reduzierung und Entkopplung der IT Risiken
Entscheidung
Anwendungszonen mit gleicher Technologie werden so aufgetrennt,
dass primäre Bedrohungen auf eine Zone eingeschränkt werden
können. Eine Wechselwirkung zwischen einzelnen Bedrohungstypen
durch

Angreifer,

Benutzer und

Administratoren
wird durch die Trennung in einzelne Sicherheitszonen vermieden.
© 2004
Seite
45 von 112
AE/S-En12.1
Bereich
Alternativen
Sicherheitszonen
Keine - da alternativ Schutzziele der Stufe „Hoch“ bis „Sehr Hoch“
in den Primärsystemen realisiert werden müssen und damit der
aktuelle IT-Betrieb der Leistungserbringer und Kostenträger stark
verändert werden müsste.
Tabelle 45: Architekturentscheidung Speicherung Sicherheitsobjekte
AE/S-En12.2
Bereich
Annahmen
Speicherung Sicherheitsobjekte
Unter dem Begriff Sicherheitsobjekte werden allgemein alle Daten und Objekte verstanden, die von Sicherheitsmechanismen
verwendet werden: Passwörter, PINs, TANs, allg. Schlüsselmaterial (private und öffentliche Schlüssel, sym. Schlüssel), ACLs,
Audit Files, etc.

Sicherheitsobjekte sind generell als sensible Daten anzusehen.
Motivation
Sicherheitsobjekte müssen gemäß ihres Schutzbedarfs geschützt
werden.
Entscheidung

Speicherung der Sicherheitsobjekte gemäß ihres jeweiligen
Schutzbedarfs in entsprechenden Sicherheitszonen der Sicherheitsarchitektur.

Private Schlüssel zur Signaturbildung werden ausschließlich in
einer entsprechenden Sicherheitsumgebung gespeichert.

Im Falle automatischer Signaturbildung ohne Beteiligung natürlicher Personen (d.h. HBA, Heilberufsausweis, eGK) sind die entsprechenden privaten Signaturschlüssel ausschließlich in Hardware Security Modules (HSM) aufzubewahren, wobei sichergestellt sein muss, dass diese das HSM zu keinem Zeitpunkt ihres
Lebenszyklus verlassen können.

Entsprechende Sicherheitsevaluierungen der Speicherkomponenten sind in Abhängigkeit des Schutzbedarfs der Sicherheitsobjekte zu fordern.
Alternativen
Keine – eine ungeschützte nicht den entsprechenden Sicherheitszonen zugeordnete Speicherung der Sicherheitsobjekte erhöht die IT
Risiken.
© 2004
Seite
46 von 112
2.3 Architekturentscheidungen des Solution Outline
Im Folgenden werden die Architekturentscheidungen des Solution Outline im Einzelnen aufgelistet.
2.3.1
Dezentrale Komponenten
Tabelle 46: Architekturentscheidung bIT4health Connector Deployment
AE-LD 1
Bereich
Annahmen
bIT4health Connector Deployment
Je nach Einsatzumgebung (Arztpraxis, Krankenhaus) ergeben sich
unterschiedliche Anforderungen an die Integration des bIT4health
Connectors.
Eine Grundsicherheitsannahme ist für viele Umgebungen im Gesundheitswesen nicht möglich.
Bei Installation des bIT4health Connectors auf Standard-PCs kann es
durch vielfältige Konfigurationsmöglichkeiten zu Wechselwirkungen
kommen, die den Betrieb beeinträchtigen.
Motivation
Schaffung einer stabilen, sicheren Ablaufumgebung für den b4hConnector
Alternativen
-
Entscheidung
Für die physische Verteilung des bIT4health Connectors sind je nach
Einsatzumgebung verschiedene Szenarien möglich. Insbesondere
kann der bIT4health Connector in Kombination mit Hardware als
bIT4health Access Point auftreten. Dieser kann optional DSL/ISDNModem/Router/Firewall Funktionalität enthalten.
Die Kriterien, in welchen Fällen der bIT4health-Connector als
bIT4health Access Point werden sollte (bzw. muss) und welche Bestandteile des Access Points Gegenstand einer Zertifizierung sein
müssen (und welches das Äquivalent einer solchen Zertifizierung im
Falle des Betriebes des bIT4health Connectors auf einem bereits vorhanden Server ist), sind in der Lösungsarchitektur in Abstimmung mit
dem BSI festzulegen.
Begründung
Der Access Point ist eine „versiegelte“ Umgebung mit minimierten
Eingriffsmöglichkeiten.
Implikation
Herstellung und Verteilung der Hardware für den Access Point sind
notwendig.
-
© 2004
Seite
47 von 112
Tabelle 47: Architekturentscheidung Bereitstellung der bIT4health Anwendungen über eine standardisierte
Dienstschnittstelle
AE-LD 2
Bereich
Annahmen
Integration in Primärsystemapplikationen
Große Heterogenität im Bereich der Primärsystemapplikationshersteller;
Geringes Know-How, Geringe Ressourcen für die Sicherheitstechnologien
Motivation
Minimierung des Änderungsaufwands auf Seiten PSA;
Standardisierte Anbindung der b4h-Applikationen;
Entkopplung und Abstrahierung der clientseitigen Geschäftskomponenten
Alternativen
Weiterführung des aktuellen Peer-to-Peer-Zustandes;
direkte Kommunikation der PSA mit b4h-Servern
Entscheidung
Die bIT4health Anwendungen (z.B. Vertragsdaten, eRezept) und Basisfunktionen (z.B. Signieren von Dokumenten, Object-ID) werden der
Primärsystemapplikation über eine standardisierte Dienstschnittstelle
bereitgestellt. Die Primärsystemapplikationen kommunizieren nicht
direkt mit den Kartenterminals und den zentralen Diensten der Plattform. Diese Kommunikation wird durch den bIT4health Connector
gekapselt.
Für die Dienstschnittstelle wird die Nutzung von WSDL und SOAP
festgelegt.
Begründung
Höchste Flexibilität bei der Erweiterbarkeit und Upgradefähigkeit auf
Clientseite;
Plattform- und Sprach-Unabhängigkeit der Dienstschnittstelle;
Reduktion der Integrationskomplexität;
Implikation
Definition der Schnittsstelle;
Verteilung des b4h-Connectors notwendig;
WSDL Know-How und rechtzeitige Bereitstellung von SDKs nötig
-
Tabelle 48: Architekturentscheidung automatische und verteilte Aktualisierung der Anwendungskomponenten
durch den bIT4health Connector
AE-LD 3
Bereich
Annahmen
-
Motivation
Wartungsfreiheit des bIT4health Connectors; Änderungen von Anwendungen in der Plattform „gleichzeitig“ für alle bIT4health Connectoren durchsetzen
Alternativen
Aktualisierung des bIT4health Connectors bei Quartalsupdates der
Primärsystemapplikationen
© 2004
Seite
48 von 112
AE-LD 3
Bereich
Entscheidung
Der bIT4health Connector unterstützt automatische und verteilte Aktualisierung der Anwendungskomponenten. Die Schnittstelle des
Command Managers ist generischer Natur; er ermittelt für übergebene Kommandos die zuständigen Anwendungskomponenten. Falls
nötig, werden diese nachgeladen bzw. aktualisiert.
Begründung
Beste Abdeckung der Motivation. Bei Quartalsupdates können z.B.
kritische Patches nicht zeitnah installiert werden.
Implikation
Management-/Updatefähigkeiten im bIT4health Connector benötigt;
Plattformdienste für das Anwendungsmanagement benötigt
-
Tabelle 49: Architekturentscheidung Kommunikation zwischen Primärsystemapplikation und bIT4health
Connector primär im Pull-Verfahren
AE-LD 4
Bereich
Annahmen
Bei vielen Geschäftsprozessen wird die Kommunikation durch die
PSA initiiert.
Motivation
Reduktion des Eingriffes in die PSA
Alternativen
Durchgreifen von Pushs der Plattform bis in das Primärsystem
Entscheidung
Die
Kommunikation
zwischen
Primärsystemapplikation
und
bIT4health Connector erfolgt hauptsächlich im Pull-Verfahren. Kontrollierte, lokale Pushs (z.B. von Karten-Events) sind möglich.
Begründung
Sicherheit;
zukünftige Geschäftsprozesse können einen kontrollierten Push benötigen.
Implikation
Ein direkter Zugriff auf Primärsystemapplikationen aus der Telematikplattform ist nicht möglich.
Primärsystemapplikation wird im Fall lokaler, kontrollierter Pushs zum
Service Provider.
-
Tabelle 50: Architekturentscheidung SDK nicht Teil der Lösungsarchitektur
AE-LD 5
Bereich
Annahmen
Unterschiedlicher Wissensstand bezüglich Web Services bei den PSA
Herstellern;
Unterschiedliche Anforderungen an Einbindung der Dienstschnittstelle
(z.B. als Dateischnittstelle)
Motivation
Vereinfachung der Handhabung der Dienstschnittstelle für PSAAnbieter
Alternativen
© 2004
Seite
49 von 112
AE-LD 5
Bereich
Entscheidung
SDKs, die den Umgang mit der Dienstschnittstelle vereinfachen und
an spezielle Bedürfnisse der Primärsystemapplikation anpassen, sind
nicht Teil der Lösungsarchitektur, können aber optional von Drittanbietern angeboten werden
Begründung
-
Implikation
-
-
Tabelle 51: Architekturentscheidung Kommunikation zwischen bIT4health Connector und Kartenterminals über
abstrakte Schnittstelle
AE-LD 6
Bereich
Annahmen
Kartenterminal
Vielzahl unterschiedlicher Kommunikationsprotokolle mit Kartenterminals aufgrund unterschiedlicher Hersteller und unterschiedlicher Anschlussvarianten
Motivation
Verbergen der Komplexität der Kommunikation mit den Kartenterminals und deren Konfiguration vor den Anwendungskomponenten und
Common Services im bIT4health Connector
Alternativen
Komponenten im bIT4health Connector, die auf die Karten zugreifen,
(z.B. Data Store) berücksichtigen verschiedene mögliche Kommunikationsprotokolle mit Kartententerminals.
Entscheidung
Für die Kommunikation zwischen bIT4health Connector und Kartenterminals ist eine abstrakte Schnittstelle zu definieren. Für die verschiedenen Low-Level-Schnittstellen bzw. Kommunikationsprotokolle
von Kartenterminals sind entsprechende Treiber/Plug-Ins für den
bIT4health-Connector bereitzustellen, die die Adaption an diese
Schnittstelle vornehmen.
Begründung
Bestmögliche Kapselung des Kartenzugriffs, Vorhandensein geeigneter Schnittstellen (z.B. OCF)
Implikation
Bereitstellung der Treiber/Plug-Ins durch Kartenterminalanbieter
-
Tabelle 52: Architekturentscheidung Definition der Kartenterminals auf der Basis des TeleTrust e.V. (MKT, V1.0)
AE-LD 7
Bereich
Annahmen
Kartenterminal
-
Motivation
-
Alternativen
Nicht-MKT-konforme Kartenterminals
Entscheidung
Kartenterminals sollten auf der Basis des TeleTrust e.V. Standards
Multifunktionales Kartenterminal (MKT, V1.0) definiert werden.
© 2004
Seite
50 von 112
AE-LD 7
Bereich
Begründung
Kartenterminal
MKT-Geräte stellen eine Abwärtskompatibilität zur heutigen KVK sicher. Entsprechende Herstell- und Zertifizierungsprozesse existieren.
Eine Versorgung mit dieser Geräteklasse ist sichergestellt. Die Form
der MKT-Spezifikation erlaubt eine Erweiterung hinsichtlich des Einsatzes dieser Geräte speziell im Gesundheitswesen. Die MKTSpezifikation lässt diverse Verbindungsmöglichkeiten (z.B. USB,
RS232, Ethernet etc.) explizit zu.
Implikation
Funktionale Ergänzungen zur MKT-Spezifikation mindestens für Kartenterminals mit USB- und Ethernetschnittstellen
-
Tabelle 53: Architekturentscheidung Kommunikation mit zentralen Diensten zunächst grundsätzlich Pull-basiert
AE-LD 8
Bereich
Annahmen
Schnittstelle bIT4health Connector zu zentralen Diensten der
Plattform
Updates aus Backend-Systemen und Administrationsinformationen
für den bIT4health-Connector (z.B. Aktualisierung von Anwendungskomponenten werden nicht im Zusammenhang mit Patientenbesuchen bereitgestellt).
Motivation
Reduktion des Eingriffes in den bIT4health Connector
Alternativen
Grundsätzlicher Push von Aktualisierungen von Komponenten und
Daten aus der Plattform
Entscheidung
Die Kommunikation mit zentralen Diensten der Plattform ist zunächst
grundsätzlich Pull-basiert. Ein Push-basiertes Remote-Management
von bIT4health Connectoren (z.B.) im Fehlerfall kann jedoch sinnvoll
sein.
Begründung
Sicherheit
Implikation
Der bIT4health Connector benötigt keine permanente Internetverbindung.
-
2.3.2 Zentrale Komponenten
Tabelle 54: Architekturempfehlung Service Modellierung
AE-LZ 1
Bereich
Annahmen
Service Modellierung
-
Motivation
Die Festlegung einer einheitlichen Beschreibungsform der Schnittstellen erleichtert das Schnittstellenmanagement.
© 2004
Seite
51 von 112
AE-LZ 1
Bereich
Alternativen
Service Modellierung
1. WSDL
2. IDL
3. keine Schnittstellenbeschreibung, sondern manuelle Verteilung von
Proxy – Klassen
Entscheidung
1. WSDL
Begründung
WSDL erfüllt Anforderung
unabhängigkeit.
nach
Plattform-
und
Technologie-
Weitreichende Toolunterstützung.
Implikation
Festlegung von Namensräumen erforderlich.
Organisatorische Rahmenbedingungen für das
management abstimmen und einführen.
Abhängige
Schnittstellen-
-
Tabelle 55: Architekturempfehlung Service Binding
AE-LZ 2
Bereich
Annahmen
Service Binding
-
Motivation
Das gewählte Binding zwischen bIT4health Connector und Diensten
der Telematikplattform hat weitreichende Konsequenzen auf die Lösungsarchitektur.
Alternativen
1. SOAP
2. weitere Bindings (Java, EJB, JMS) über WS-Invocation Framework
(WSIF)
Entscheidung
1. SOAP (WSIF unter Beobachtung)
Begründung
Nur SOAP Binding ist bisher standardisiert und ermöglicht damit Interoperabilität zwischen heterogenen Service Providern.
Implikation
Auswahl der SOAP Runtime
Auswahl der SOAP Client API
Auswahl des Transport Protokolls http(s), MOM, (SMTP, FTP)
Auswahl der Kommunikationsart und Enkodierung (rpc/encoded oder
document/literal style)
Abhängige
-
Tabelle 56: Architekturempfehlung Service Registrierung
AE-LZ 3
Bereich
Annahmen
Service Registrierung
Ein Service Broker ist für die ersten Phasen der Lösungsarchitektur
optional, da Interface-statisches Linken für die betrachteten Anwendungsfälle ausreicht.
© 2004
Seite
52 von 112
AE-LZ 3
Bereich
Motivation
Service Registrierung
Der Lookup eines Service Providers durch den Service Requestor
kann zur Entwicklungszeit (statisches Interface Linking) oder zur
Laufzeit (dynamisches Interface Linking) erfolgen. Ein Verzeichnisdienst stellt die Interface Beschreibungen zur Verfügung und bietet
optional standardbasierte Funktionen zur Suche nach „passenden“
Service Providern an.
Alternativen
1. keine Registrierung
2. UDDI Registry (privat oder öffentlich)
3. WS-Inspection Language (WSIL)
4. Eigenentwicklung
Entscheidung
4. Eigenentwicklung (später WSIL und / oder UDDI)
Begründung
Siehe Annahme
Sicherer Zugriff auf öffentliche UDDI Registry zur Zeit nicht zu gewährleisten.
Implikation
Binding – dynamisches Linking muss trotzdem unterstützt werden
(Auswahl des passenden Endpunkts zur Laufzeit).
Spezifikation einer Service Locator Komponente im b4h Connector
Abhängige
-
Tabelle 57: Architekturentscheidung Format der Referenz / Pointer
AE-LZ 4
Bereich
Annahmen
Motivation
Referenz- / Pointerformat
Die Spezifikation des genauen Pointer Formats und der Generierungsvorschrift ist vordringliche Aufgabe der Lösungsarchitektur.
Die Referenz auf der Karte muss die eindeutige Lokalisierung des
physischen Informationsobjektes erlauben und entspricht damit einem
Uniform Resource Locator (URL). Ein Uniform Resource Indentifier
(URI) bezeichnet allgemeiner eine eindeutige Referenz, die nicht notwendigerweise auflösbar sein muss. Es ist zu beachten, dass die URL
vor dem eigentlichen Speichervorgang bekannt sein muss und als
Attribut dem Informationsobjekt zugewiesen wird. Außerdem müssen
alternative Suchmöglichkeiten nach Informationsobjekten bestehen,
um einen Zugriff auf die Informationsobjekte auch ohne Karte zu erlauben. Zusätzlich sollte die Referenz auch bei Änderung der physischen „Speicheradresse“ valide bleiben.
Alternativen
Entscheidung
1. Referenz ist gleich Objekt ID des Informationsobjektes
2. Referenz beinhaltet OID und zusätzliche URL zum Auflösen des
Speicherorts
2. OID + zusätzliche URL
© 2004
Seite
53 von 112
AE-LZ 4
Bereich
Begründung
Implikation
Referenz- / Pointerformat
Nur die OID in der Referenz zu speichern, würde es erforderlich machen, zu jedem Informationsobjekt an einer Stelle zentral ein Handle
abzulegen, das die Informationen zum Speicherort enthält. Wie in
[DOLSA] erläutert, ist dieses Verfahren nicht skalierbar.
Angelehnt an den allgemeinen Aufbau einer URL wird vorgeschlagen,
die Referenz in nach folgendem Muster aufzubauen: <Schema>:<Schemaspezifika>#<fragment>.
Das Schema bestimmt das Format des nachfolgenden schemaspezfischen Anteils der URL. So können z.B. unterschiedliche Versionen
des URL Formats definiert werden. Passend zum Schema übernimmt
ein Handler die Auflösung der Referenz anhand der restlichen Parameter. Hier kann z.B. der Service enkodiert werden (Schemaspezifika), der das Informationsobjekt mit dem übergebenen eindeutigen
Schlüssel (fragment) zurückliefert.
Abhängige
-
Weiterführende Architekturempfehlungen
Die Plattformdienste der Telematikplattform müssen in erster Linie die Interoperabilität und
lose Kopplung zwischen den Anwendungssystemen des Gesundheitswesens gewährleisten.
Sie stellen Funktionalitäten über einheitliche und standardbasierte Schnittstellen zur Verfügung, die von allen Anwendungssystemen gemeinsam genutzt werden.
Interoperabilität
Das in [b4h Komponentenmodell] geforderte Architekturprinzip der Interoperabilität unterscheidet zwischen funktionaler und semantischer Interoperabilität.
Funktionale Interoperabilität fordert von Anwendungssystemen, dass sie ihre Schnittstellen
gegenseitig kennen und aufrufen können. Abgebildet auf die Lösungsarchitektur bedeutet
das eine frühzeitige Festlegung der Modellierung, der Protokolle und der Registrierung von
Services.
Die dargestellten Architekturentscheidungen empfehlen für die Service Modellierung grundsätzlich WSDL, da WSDL eine einheitliche, technologieneutrale und erweiterbare Definition
der Schnittstellen zulässt.
Als Service Protokoll wird grundsätzlich SOAP empfohlen, da es als XML basiertes Nachrichtenformat die Grundlage für funktionale und semantische Interoperabilität zwischen Anwendungssystemen bilden kann. Es ist wichtig zu betonen, dass mit der grundsätzlichen
Empfehlung von SOAP keine ausschließliche Nutzung RPC basierter Web Services über
http(s) gefordert wird. Vielmehr sind bei der Realisierung konkreter Plattform- und Anwendungsdienste nicht - funktionale und Qualitätsanforderungen zu berücksichtigen, die z.B. den
Einsatz von dokumentzentrierten Nachrichtenprotokollen über MOM Systeme erforderlich
machen. SOAP und WSDL bieten jedoch die Flexibilität, die unterschiedlichen Lösungsalternativen einheitlich und auf verfügbaren Standards basierend umzusetzen.
Die Beschreibung der öffentlichen Schnittstellen der Plattform- und Anwendungsdienste
müssen bereits zur Entwicklungszeit der Anwendungskomponenten im bIT4health Connector
bekannt und zugreifbar sein. Dasselbe gilt für die Schnittstellen der verfügbaren externen
Zusatzdienste. Die WSDL Dokumente werden benötigt, um bei der Anwendungsentwicklung
Proxy Klassen zu generieren, über die sich Service Consumer statisch an die Service Provi© 2004
Seite
54 von 112
der binden. Zukünftig sind dynamische Mechanismen denkbar und sinnvoll, in denen erst zur
Laufzeit vom Consumer die abstrakte Schnittstelle des Providers nach bestimmten Kriterien
gesucht und ausgewählt wird. Dynamisches Linken erfordert eine Broker Instanz, die als
Vermittler zwischen Requestor und Provider fungiert und u.a. eine API für Service Registrierung und Suchanfragen zur Verfügung stellt. Die Broker Funktionalität wird im Web Service
Architektur durch die UDDI Spezifikation abgedeckt.
Für die Lösungsarchitektur Phase 1 und 2 wird die UDDI Broker Implementierung zur Laufzeit nicht empfohlen, da vollständiges dynamisches Linken der Schnittstellendefinitionen bei
den betrachteten Use Cases nicht erforderlich ist. Allerdings muss die Auswahl einer konkreten Implementierung einer abstrakten Service Schnittstelle (Protokoll- und Adressdynamik)
zur Laufzeit unterstützt werden, was beispielsweise durch die Programmierung eines Service
Locators im bIT4health Connector möglich ist.
Die dargestellten Architekturempfehlungen sind alleine keine Gewährleistung für semantische Interoperabilität zwischen den Anwendungssystemen der Telematikplattform. Allerdings
wird die einheitliche und eindeutige Festlegung der Nachrichtenformate und Servicetypen
durch Namensräume in den XML Schema - basierten SOAP, WSDL und UDDI Spezifikationen erleichtert. Diese Festlegungen müssen frühzeitig in der Lösungsarchitektur getroffen
werden. Weitergehende Konzepte wie Resource Description Framework (RDF), RDF Schema und Web Ontology Language WOL) zur Semantikbeschreibung von Web Services
und Resourcen sind erst im Draft Status und nicht mit WSDL bzw. UDDI Spezifikationen abgestimmt. Für die Lösungsarchitektur sollten sie daher nur informell betrachtet werden.
Lose Kopplung
In [b4h Komponentenmodell] wurde das Architekturprinzip der losen Kopplung in erster Linie
auf die Anbindung zwischen Primärsystemen und bIT4health Connector bezogen und mit der
Architekturentscheidung für eine nachrichtenbasierte Kommunikationsschnittstelle adressiert.
Dasselbe Architekturprinzip muss aber auch für die Schnittstelle der Anwendungskomponenten im bIT4health Connector und den Plattform- bzw. Anwendungsdiensten gelten. Insbesondere sollte es keine clientspezifischen Varianten von serverseitigen Serviceimplementierungen geben und umgekehrt keine serverspezifischen Varianten von clientseitigen Anwendungskomponenten, da der Aufwand für Implementierung, Test, Verteilung, Wartung und
Deployment mit dem Grad der Heterogenität unverhältnismäßig stark ansteigt.
SOAP unterstützt die syntaktische und technologische Entkopplung zwischen Service Provider und Consumer durch das XML basierte Nachrichtenformat, garantiert sie aber nicht. Dazu sind in der Lösungsarchitektur weitergehende Festlegungen des Kommunikationsmusters
und des Protokolls notwendig. Die SOAP Spezifikation erlaubt sowohl RPC als auch dokumentenbasierte Kommunikationsmuster zwischen Consumer und Provider. Dokumentenbasierte Kommunikation übermittelt beliebige Inhaltsdaten innerhalb des SOAP Body an den
adressierten Service Provider und überlässt diesem, den Inhalt zu verarbeiten, zu validieren
und ggf. eine Rückantwort zu senden. Bei der RPC Kommunikation ist die Struktur des
SOAP Body vorgegeben und umfasst Syntax und Parameter des Remoteaufrufes. Alle Elemente können aufgrund der vorgegebenen Struktur von der SOAP Runtime validiert werden.
Das dokumentenzentrierte Kommunikationsmuster eignet sich insbesondere für generische
Dienste, die eine Vielzahl unterschiedlicher Dokumente zur Weiterverarbeitung oder Speicherung entgegennehmen und kontextsensitiv auswerten. Die Validierung und ggf. Transformation ist Aufgabe der Dienste. In Kombination mit einer asynchronen Kommunikationsform über MOM Systeme lassen sich so performante Dienste mit hoher Qualitätsgüte realisieren. Im Allgemeinen sind Consumer und Provider im Vergleich zu RPC loser gekoppelt,
da die Schnittstelle weniger detailliert definiert werden muss.
Das RPC Muster unterstützt in erster Linie die synchrone Kommunikationsform, bei der die
übergebenen Parameterwerte strukturiert sind und das Ergebnis des Methodenaufrufs dem
© 2004
Seite
55 von 112
Consumer ad hoc zur Verfügung stehen muss. Die Validierung der Parameter kann von der
SOAP Runtime übernommen werden. Syntaktisch sind die beteiligten Systeme enger gekoppelt, da eine Änderung im Service Provider Interface auch Code Änderungen im Consumer erforderlich macht. Lese-, Such- und Transformationsfunktionen sind geeignete Beispiele für RPC basierte Aufrufe.
Eine generelle Festlegung eines Kommunikationsmusters ist insbesondere im Hinblick auf
die zukünftigen externen Dienste zum jetzigen Zeitpunkt nicht möglich. In der Lösungsarchitektur müssen unter Berücksichtigung nicht funktionaler Anforderungen für die konkreten
Anwendungsfälle die passenden Kommunikationsmuster ausgewählt werden.
2.3.3
Anwendungen
Tabelle 58: Architekturentscheidung Optionalität von Anwendungen
AE-LAW 1
Bereich
Annahmen
Optionalität von Anwendungen
Es wird eine nicht bekannte und von vornherein nicht limitierte Anzahl
von Applikationen geben.
Das GMG definiert Pflicht- und freiwillige Anwendungen für den Patienten im Zusammenhang mit der eGK.
Es gibt keine Verpflichtung für Leistungserbringer, irgendeine Applikation der Telematikinfrastruktur zu verwenden.
Motivation
Für die Basisapplikationen des GMG muss allgemeine Verfügbarkeit
sichergestellt werden.
Innovative Anwendungen sollten nicht blockiert werden.
Alternativen
Entscheidung
Begründung
Implikation
Im GMG definierte Anwendungen sind von den Softwareherstellern
entsprechend ihrer Relevanz verpflichtend in die Primärsystemapplikation zu integrieren. Innovative Zusatzanwendungen der Plattform können optional integriert werden
Eine Liste der relevanten Pflichtanwendungen für die jeweiligen PSA
ist zu erstellen.
PSA-Hersteller haben Integrationsaufwand für die GMG-Anwendungen.
Tabelle 59: Architekturentscheidung Bereitstellung der Anwendungsbestandteile
AE-LAW 2
Bereich
Annahmen
Bereitstellung der Anwendungsbestandteile
Es kommt zum Wettbewerb der Anwendungen. Es wird sowohl
Pflichtanwendungen geben als auch innovative Anwendungen von
„Vorreitern“.
© 2004
Seite
56 von 112
AE-LAW 2
Bereich
Motivation
Bereitstellung der Anwendungsbestandteile
Vermeidung von Kollisionen und Uneindeutigkeiten bei referenzierten
Applikationen;
Unterstützung der Erweiterbarkeit der Plattform um neue Applikationen
Alternativen
Entscheidung
Begründung
Implikation
Abhängige
Unkontrollierte Bereitstellung von Anwendungen
bIT4health Anwendungen sind zentral zu registrieren. Die Registrierung beinhaltet die Beschreibung der Dienstschnittstelle, die Anwendungskomponente für den bIT4health Connector und ggf. Metadaten
für die Kartenapplikation (z.B. Application Identifier).
Definition der Schnittstelle und des Formates der Einträge der Registry
-
Tabelle 60: Architekturentscheidung Freigabeverfahren für neue Anwendungen
AE-LAW 3
Bereich
Annahmen
Motivation
Freigabeverfahren für neue Anwendungen
Applikationen werden von unabhängigen Lösungsanbietern erstellt.
Funktionale Erweiterbarkeit der Plattform;
Interoperabilität des Applikationsmanagements;
Interoperabilität der Standardanwendungen zur Gewährleistung eines
sicheren und stabilen Betriebs der Plattform
Alternativen
Entscheidung
Begründung
Implikation
Abhängige
Beliebige Services können in der Telematikinfrastruktur und auf dem
b4h-Connector bereitgestellt und betrieben werden.
bIT4health Anwendungen müssen vor ihrem Einsatz ein Freigabeverfahren durchlaufen. Dafür ist mindestens eine zentrale Stelle einzurichten. Kriterien für die Freigabe sind:

Domainrelevanz

technische Konformität zu Applikationsmanagement

technische Konformität bei Standardanwendungen

Sicherheitsevaluation, wenn nötig
Schaffung der zentralen Stelle zur Freigabe;
Code Signing oder ähnliche Mechanismen zur Durchsetzung der Entscheidung
-
© 2004
Seite
57 von 112
Tabelle 61: Architekturentscheidung Update der Vertragsdaten als Nachpersonalisierung über das CAMS
AE-LAW 4
Bereich
Annahmen
Vertragsdaten
Die Vertragsdaten des Patienten ändern sich während der Lebenszeit
einer eGK durch Mobilität und Lebensumstände.
Motivation
Auf der eGK sollen die jeweils aktuellen Vertragsdaten des Patienten
zur Verfügung stehen.
Alternativen
Direkte Abfrage der aktuellen Daten an den Systemen der jeweiligen
Krankenkasse.
Entscheidung
Begründung
Implikation
Abhängige
Das Update der Vertragsdaten auf der eGK erfolgt als Nachpersonalisierung über das Kartenapplikationsmanagementsystem (CAMS).
Dem CAMS sind Vertragsdatenserver zugeordnet, auf denen die
Krankenkassen per zu definierender Einlieferungsschnittstelle Updates für Vertragsdaten bereitstellen.
Datenvermeidung: Nicht alle Vertragsdaten aller Versicherten sind
permanent in der Plattform abrufbar.
Definition der Einlieferungsschnittstelle für Krankenkassen nötig;
Kassenwechsel muss definiert werden.
-
Tabelle 62: Architekturentscheidung Einrichtung eines zentralen Dienstes zur Validierung von KVKs und
Überprüfung des Zuzahlungsstatus
AE-LAW 5
Bereich
Annahmen
Vertragsdaten
Während einer Übergangszeit werden sich noch KVKs im Feld befinden.
Es wird komplexe, sich ändernde Zuzahlungsmodelle geben, die sich
in den Vertragdaten auf der eGK nicht hinreichend abbilden lassen.
Motivation
Alternativen
Entscheidung
Begründung
Implikation
Abhängige
Auch KVKs sollen auf ihre Gültigkeit überprüft werden können.
Der aktuelle Zuzahlungsstatus des Patienten soll zur Verfügung stehen.
Zur Validierung noch im Feld befindlicher KVKs und zur Überprüfung
des Zuzahlungsstatus ist die Einrichtung eines zentralen Dienstes
nötig.
Schnittstellen für Krankenkassen sind zu definieren;
Zentraler Dienst ist einzurichten
-
© 2004
Seite
58 von 112
Tabelle 63: Architekturentscheidung Ausschließliche Betrachtung von Arzneimittel- und BTM-Rezepten in Phase
2
AE-LAW 6
Bereich
Annahmen
Motivation
Elektronische Rezept in Phase 2
Das elektronische Rezept ist ein administratives Dokument.
Teileinlösungen von Rezepten haben ein geringes Vorkommen.
Die Rahmenarchitektur macht Vorgaben für Arzneimittelrezepte (inklusive BTM und Hilfsmittel).
Überweisungen und Einweisungen sind noch nicht abschließend als
administrative Dokumente oder als Arztbriefe diskutiert.
Alternativen
Einweisungen und Überweisungen werden als administrative Dokumente betrachtet und im Prozess wie ein elektronisches Rezept behandelt.
Teileinlösungen werden sofort unterstützt.
Entscheidung
Begründung
Implikation
Abhängige
In Phase 2 werden ausschließlich Arzneimittel- und BTM-Rezepte
betrachtet. Rezepte können nur komplett eingelöst werden.
Überweisungen und Einweisungen enthalten klinische Daten und
müssen somit anderen Sicherheitsanforderungen genügen (und sind
eventuell als Arztbrief zu betrachten).
Geringere Komplexität für Realisierung des elektronischen Rezeptes
-
Tabelle 64: Architekturentscheidung Signatur des eRezeptes über die Signaturanwendung des bIT4health
Connectors über die Dienstschnittstelle
AE-LAW 7
Bereich
Annahmen
Motivation
Alternativen
Entscheidung
Signieren des Rezeptes erfolgt während der Abarbeitung durch die
eRezept-Anwendungskomponente.
Die Signatur des eRezeptes (wie auch aller anderen Dokumente) erfolgt explizit durch Aufruf der Signaturanwendung des bIT4health
Connectors über die Dienstschnittstelle.
Begründung
Bessere Kontrolle des
applikationen möglich
Workflows
durch
die
Primärsystem-
Implikation
Bereitstellung der Signatur- bzw. Securityanwendung inklusive
Dienstschnitttstelle durch den bIT4health-Connector;
Prüfung der Signatur durch die eRezept-Anwendungskomponente
Abhängige
-
© 2004
Seite
59 von 112
Tabelle 65: Architekturentscheidung Symmetrische Verschlüsselung der eRezepte auf dem Resource Provider
Server
AE-LAW 8
Bereich
Annahmen
Motivation
Alternativen
Entscheidung
Begründung
Implikation
Unterstützung von Internetapotheken;
Life-Cycle-Management von Rezepten
Asymmetrische oder keine Verschlüsselung der Rezepte auf dem
Server
Auf dem Resource Provider Server für eRezepte sind diese symmetrisch verschlüsselt. Sie sind nur zu entschlüsseln mit Hilfe des entsprechenden Rezept-Pointers auf der eGK oder mit Hilfe einer TAN (> Versandapotheken). Weiterhin enthalten die Rezepte auf dem Server als Envelope auch unverschlüsselte Daten zum Zwecke des LifeCycle-Management (z.B. Ablaufdatum).
Unverschlüsselte Rezepte auf dem Server sind aufgrund der Datenschutzbestimmungen nicht akzeptabel. Asymmetrische Verschlüsselung ist aufwändig und erfordert die Verwendung eines privaten
Schlüssels (->Anwesenheit der eGK erforderlich).
Einrichtung des Resource Provider Servers für eRezepte.
Definition des Pointer-Formates, der TAN und des Envelopes nötig
2.3.4
Sicherheitskomponenten
2.3.4.1 Autorisierung und Berechtigung
Tabelle 66: Zugriffsfreigabe auf eGK durch Versicherten
AE-SL 1
Bereich
Annahmen
Zugriffsfreigabe auf eGK durch Versicherten
§ 291a, Absatz 5 SGB V: „[...] Durch technische Vorkehrungen ist
zu gewährleisten, dass in den Fällen des Absatzes 3 Satz 1 Nr. 2
bis 6 der Zugriff nur durch Autorisierung der Versicherten möglich
ist.[...]“

Das GMG macht keine Vorgaben bzgl. der technischen Realisierung.
Motivation
Das technische Verfahren sollte einfach, erprobt und dem Versicherten
vertraut sein.
Alternativen
Zugriffsfreigabe mittels biometrischer Verfahren.
Entscheidung
Zugriffsfreigabe durch Versicherten auf eGK in den Fällen des GMG
Absatzes 3 Satz 1 Nr. 2 bis 6 ausschließlich mittels PIN.
Begründung
Einfaches, dem Versicherten aus anderen Bereichen (Finanzwesen
etc.) vertrautes Verfahren.
© 2004
Seite
60 von 112
AE-SL 1
Bereich
Implikation
Zugriffsfreigabe auf eGK durch Versicherten
Aufbau und Länge der PIN muss im Rahmen der eGK-Spezifikation
festgelegt werden.
Tabelle 67: Zweistufiges Autorisierungskonzept
AE-LSL 2
Bereich
Annahmen
Zweistufiges Autorisierungskonzept
Der Versicherte muss den Zugriff auf einzelne freiwillige Anwendungen
sowie auf Teile dieser explizit freigeben können.
Motivation
Ein komplexes Berechtigungsmanagement lässt sich alleine mit Hilfe
der eGK nicht abbildbar.
Alternativen

Nur rollenbasierte Autorisierung

Nur personenbasierte Autorisierung
Entscheidung
Zweistufiges Autorisierungskonzept:

Stufe: Rollenbasierte Autorisierung

Stufe: Personenbasierte Autorisierung: Expliziter Ausschluss bzw.
Einschluss einzelner Heilberufler für den Zugriff auf eine freiwillige
Anwendung

Der Ausschluss/Einschluss von Zugriffsrechten einzelner, weniger
Leistungserbringer kann auf der eGK gespeichert werden.

Diese Autorisierung für einzelne Teilfelder bzw. Objekte innerhalb
einer Anwendung ist technisch innerhalb der Fachanwendungen zu
realisieren.
Begründung
Es handelt sich um ein minimales, umsetzbares Berechtigungskonzept, das die Anforderung nach expliziter Zulassung/Sperrung einzelner Leistungserbringer auf freiwillige Anwendungen gerecht wird.
Implikation
Die rollenbasierte Autorisierung erfolgt auf Kartenebene. Die personenbezogene Autorisierung wird im bIT4health Connector bzw. auf
dem Server durchgesetzt.
Tabelle 68: Autorisierung des Zugriffs auf einzelne med. Datenobjekte
AE-LSL 3
Bereich
Annahmen
Motivation
Autorisierung des Zugriffs auf einzelne med. Datenobjekte.
Architekturentscheidung Rahmenarchitektur

Eindeutige Objekt IDs und Referenzen werden verwendet, um auf
die med. Daten zu zugreifen.

Eine Trennung der med. Daten von den Referenzen ist von allen
Fachanwendungen einheitlich vorzusehen.
Flexible Verwaltung der Zugriffsautorisierung auf einzelne med. Daten-
© 2004
Seite
61 von 112
AE-LSL 3
Bereich
Autorisierung des Zugriffs auf einzelne med. Datenobjekte.
objekte durch den Versicherten
Alternativen
Der Zugriff auf beschreibende Informationen med. Daten (Referenzen)
schließt den möglichen Zugriff unmittelbar ein.
Entscheidung
Der Versicherte hat die Möglichkeit nach dem Zugriff auf die Referenzen (beschreibende Informationen) die zugehörige medizinische Informationen explizit freizugeben.
Begründung
Die technikneutrale Gestaltung der Anwendung (z.B. Karte, Server)
beim Zugriff auf die in der Telematikplattform temporär gespeicherten
Daten erfordert eine Trennung von Inhalt und beschreibenden Informationen.
Implikation
Autorisierung durch PIN-Eingabe oder Verwaltung der beschreibenden
Informationen in öffentlichen und privaten Fächern
Tabelle 69: Authentifizierung des eGK Kartenzugriffs durch den Versicherten mittels qualifizierter elektronischer
Signatur
AE- LS 4
Bereich
Annahmen
Motivation
Alternativen
Entscheidung
Begründung
Implikation
Authentifizierung des eGK Kartenzugriffs durch den Versicherten
mittels qualifizierter elektronischer Signatur
Der Versicherte authentifiziert sich mittels PIN-Eingabe gegenüber
seiner eGK.
Festlegung eines sicheren, praktikablen und umsetzbaren Verfahren
für die Authentifizierung eines Karteninhabers
Authentifizierung mittels Signatur und Zertifikat durch die eGK selbst
oder eine andere SigG/SigV Signaturkarte
Keine Authentifizierung des eGK Kartenzugriffs durch den Versicherten
mittels qualifizierter elektronischer Signatur
Die Authentifizierung und abgeleitete Autorisierung des Zugriffs eines
Versicherten auf seine Karte erfolgt nur über die PIN.
Der Zugriff auf das Patientenfach kann durch eine (qualifizierte) Signatur protokolliert werden. Dies erfolgt ggf. außerhalb der eGK.
Online Prüfung der Signatur / des Zertifikates ist nur schwer zu implementieren.
Jeder Versicherte bräuchte ein qualifiziertes Zertifikat.
Mehrere PINs sind notwendig (sonst kein zusätzlicherer Sicherheitsgewinn).
Einbindung externer PKIs (qualifizierte Signaturkarten des Marktes)
sind aufwendig zu implementieren.
-
© 2004
Seite
62 von 112
Tabelle 70: Technische Umsetzung der Vertretungsregelung
AE-LSL 5
Bereich
Annahmen
Technische Umsetzung der Vertretungsregelung
Die Abbildung von Vertretungsregelungen werden benötigt, um vorübergehenden bzw. ständigen Vertretern die Freigabe auf freiwillige
Anwendungen im Auftrage des zu Vertretenden zu ermöglichen.
Motivation
Es existieren zahlreiche Fälle in der Praxis, in denen Versicherte durch
Dritte vertreten werden müssen.
Alternativen
-
Entscheidung
Es wird nicht zwischen einer temporären, nicht dauerhaften Vertretungsregelung und einer dauerhaften (z.B. gesetzliche Vertreter eines
Versicherten) unterschieden.
Es wird eine zweite PIN zur Freischaltung der eGK durch einen berechtigten Vertreter vorgesehen.
Begründung
Im Falle nicht-temporärer Vertretungsregelungen muss sichergestellt
sein, dass ein definierter Prozess zur Identifizierung und Festlegung
des Vertreter existiert.
Implikation
Einfluss auf die Spezifikation der eGK.
2.3.4.2 Public Key Infrastruktur - Allgemein
Tabelle 71: Nutzung von PK-Verfahren im Rahmen der Telematikarchitektur im Gesundheitswesen
AE-LSL 6
Bereich
Annahmen
Motivation
Alternativen
Nutzung von PK-Verfahren im Rahmen der Telematikarchitektur
im Gesundheitswesen
Es ist ein hohes Sicherheitsniveau im Rahmen der Telematikinfrastruktur notwendig.
Es sind unterschiedliche Sicherheitsdienste (Authentifizierung, Autorisierung, Nachweisbarkeit, Integrität etc.) notwendig.
Schaffung einer durchgängigen PK-Inftrastruktur.
Begründung
Nutzung anderer Sicherheitsverfahren (User-ID / Passwort, symmetrische Schlüssel, PIN/TAN etc.)
Zur Umsetzung der Sicherheitsanforderungen im Gesundheitswesen
kommen asymmetrische PK-Verfahren zum Einsatz.
Sicherheits- und datenschutztechnisch notwendig
Implikation
Hoher technischer und organisatorischer Aufwand
Entscheidung
Tabelle 72: Generelle Krypto-Funktionen der Karten
AE- LS 7
Bereich
Annahmen
Generelle Krypto-Funktionen der Karten
Notwendig für die Spezifikation der Karte
© 2004
Seite
63 von 112
AE- LS 7
Bereich
Motivation
Alternativen
Generelle Krypto-Funktionen der Karten
Die Karte sieht in einer ersten Ausprägung keine Funktionen für
Krypto-Funktionen vor.

Entscheidung
Begründung
Die Karte sieht in einer ersten Ausprägung nur Funktionen für CVC
Schlüssel und Zertifikate vor.
Die HBA und eGK sind technisch geeignet, Authentifizierung, Verschlüsselung und elektronische Signatur auf der Basis von CVC und
X.509 Zertifikaten zu ermöglichen.
Vom Gesetz und der Rahmenarchitektur gefordert
Implikation
Die Karte erlaubt die Speicherung von mindestens zwei asymmetrischen Schlüsselpaaren und entsprechenden CVC Zertifikaten (Auth,
Crypt)
Die Karte erlaubt die Speicherung von mindestens drei asymmetrischen Schlüsselpaaren und entsprechenden X.509 Zertifikaten (Auth,
Crypt, fort Sig und / oder qual. Sig).
2.3.4.3 Public Key Infrastruktur – Organisation / Trust Modelle
Tabelle 73: Übergreifende PKI Architektur
AE- LS 8
Bereich
Annahmen
Motivation
Alternativen
Entscheidung
Übergreifende PKI Architektur
Asymmetrische Krypto-Verfahren finden Einsatz zur Absicherung der
Kommunikation zwischen einer Vielzahl von Entitäten im Gesundheitswesen.
Notwendig für die Definition und Umsetzung der gesamten Lösungsarchitektur
Es werden „Insellösungen“ in einzelnen Bereichen (KVs <-> Versicherte / Kammern <-> Leistungserbringer / etc.) Gesundheitswesens definiert und umgesetzt.
Es wird eine übergreifende PKI Architektur von zentraler Stelle für
das gesamte Gesundheitswesen definiert und implementiert.

Es kommen mehrere PKI-Strukturen (Schlüsselpaare, Zertifikate,
CAs etc) für unterschiedliche Funktionen mit unterschiedlichen Sicherheitsniveaus zum Einsatz.
Begründung
Notwendig für einen interoperablen und übergreifenden Einsatz von
asymmetrischen kryptografischen Verfahren
Implikation
Es werden zentrale Verantwortlichkeiten für die Planung und Umsetzung installiert.
© 2004
Seite
64 von 112
Tabelle 74: Die PK-Strukturen bilden ein geschlossenes System für das Gesundheitswesen
AE- LS 9
Bereich
Annahmen
Motivation
Alternativen
Entscheidung
Begründung
PK-Strukturen für das Gesundheitswesen
Es kommen PK-Verfahren im Gesundheitswesen zum Einsatz.

Es gibt keinen definierten Anwendungsfall im Rahmen der medizinischen, betriebswirtschaftlichen oder administrativen Kommunikation mit Entitäten außerhalb des Gesundheitswesens.

Definition eingegrenzter, definier- und administrierbarer PKStrukturen

Verminderung der Komplexität und Sicherstellung der Interoperabilität, Verfügbarkeit und Sicherheitsstandards

Offene PK-Strukturen sowohl als Relying- als auch als SubscribingParty

Offene Trustmodelle mit Verknüpfungen zu (beliebigen) anderen
PKIs
Schlüssel, Zertifikate und Signaturen des Gesundheitswesens können
/ dürfen außerhalb des Systems genutzt werden, wenn die zu Grunde
liegende PKI mit PK-Strukturen außerhalb des Gesundheitswesens
verbunden sind. Dies kann z.B. über eine Bridge-CA geschehen.
Schlüssel, Zertifikate und Signaturen externen PKIs können / dürfen
innerhalb des Gesundheitssystems nicht genutzt werden, es sei denn
sie sind mit PK-Strukturen des Gesundheitswesens verbunden. Dies
kann z.B. über eine Bridge-CA geschehen.
Zeitdruck bei der Umsetzung

Gewährleistung der Sicherheitsstandards innerhalb des Systems
Implikation
Keine Nutzung der eGK und HBA für externe Anwendung (z.B. für
Homebanking) möglich
Tabelle 75: Trennung von CVC und X.509
AE- LS 10
Bereich
Annahmen
Motivation
Trennung von CVC und X.509
Die eGK erhält Funktionen zur C2C-Authentication und Funktionen
auf Basis von X.509 Zertifikaten.

CVCs haben eine andere Struktur als X.509 Zertifikate.

Notwendige Definition / Abgrenzung der Funktionalen Rahmenbedingungen

Definition der PKI Umgebung
Alternativen
Gemeinsame (verknüpfte) Verwaltung von CVC und X.509
Entscheidung
Die PKI-Strukturen der CVCs sind technisch und organisatorisch von
den Strukturen der X.509 Zertifikate getrennt.
Es handelt sich um unterschiedliche Funktionsbereiche, die auch technisch und organisatorisch von einander getrennt sein sollten.
Es gibt getrennte PKI-Strukturen (Trustmodelle) für CVC und X.509.
Die Ausgabe und Verwaltung von CVC und X.509 Zertifikaten erfolgt
Begründung
Implikation
© 2004
Seite
65 von 112
AE- LS 10
Bereich
Trennung von CVC und X.509
getrennt.
Tabelle 76: Trennung der X.509 basierten PK-Strukturen von Anwendungen und Administration
AE- LS 11
Bereich
Motivation
Trennung der X.509 basierten PK-Strukturen von Anwendungen
und Administration
Es kommen sowohl im Bereich der medizinischen und wirtschaftlichen
Anwendungen als auch im administrativen Bereich X.509 Zertifikate
zum Einsatz.
Definition der PK-Strukturen und Verantwortlichkeiten
Alternativen
Einheitliche PK-Struktur (Trust-Modell) für beide Bereiche
Entscheidung
Die anwendungsbezogenen und administrativen PKI-Strukturen sind
technisch und organisatorisch getrennt.
Es handelt sich um unterschiedliche Funktionsbereiche, die auch technisch und organisatorisch von einander getrennt sein sollten.
Es gibt getrennte PKI-Strukturen (Trustmodelle).
Annahmen
Begründung
Implikation

Die Ausgabe und Verwaltung der X.509 Zertifikaten erfolgt getrennt.
Tabelle 77: Schaffung einer zentralen Instanz und PCA für X.509 Zertifikate
AE- LS 12
Bereich
Annahmen
Schaffung einer zentralen Instanz und PCA für X.509 Zertifikate
X.509 Zertifikate werden im Gesundheitswesen genutzt.
Motivation
Notwendig für die Definition der Rollen und Verantwortlichkeiten im
Rahmen der PKI-Architektur
Keine Schaffung einer zentralen Instanz
Alternativen
Entscheidung
Begründung
Die Festlegung der Standards und Policies im Rahmen der Ausgabe
von X.509 Zertifikaten erfolgt durch eine zentrale übergeordnete Instanz im Gesundheitswesen.
Schaffung klarer und einfacher Strukturen und Verantwortlichkeiten
Implikation
Es muss „die“ zentrale Instanz geschaffen und betrieben werden.
© 2004
Seite
66 von 112
Tabelle 78: Einstufiges hierarchisches Modell für die X.509 PKI-Strukturen
AE- LS 13
Bereich
Annahmen
Einstufiges hierarchisches Modell für die X.509 PKI-Strukturen
Motivation
Mehrstufige Hierarchien
Alternativen
Entscheidung
Begründung

Bridge-Modelle

Cross-Zertifizierung
Die PK-Strukturen für die Ausgabe von X.509 Zertifikaten werden als
flache (einstufige) Hierarchien implementiert.
Implikation
Tabelle 79: Anbindung externer PKIs über Bridge-CAs
AE- LS 14
Bereich
Annahmen
Anbindung externer PKIs über Bridge-CAs
Motivation
Mehrstufige Hierarchien
Alternativen

Entscheidung
Begründung
Cross-Zertifizierung
Weitere (externe) PKIs (z.B. CAs anderer EU Staaten) werden über
Bridge-Modelle mit dem deutschen System verbunden.

Flexible optionale Erweiterung
Implikation
Bridge-Strukturen, Policies und Verfahren müssen ggf. definiert werden.
Tabelle 80: Schaffung einer zentralen Instanz und PCA für CVCs
AE- LS 15
Bereich
Annahmen
Schaffung einer zentralen Instanz und PCA für CVCs
CVCs werden auf die eGK aufgebracht.
Motivation
Keine Schaffung einer zentralen Instanz
Alternativen

Zentrale Instanz legt nur die Standards und Policies fest (keine PKI
Hierarchie)

Mehrstufige hierarchische Modelle
© 2004
Seite
67 von 112
AE- LS 15
Bereich
Entscheidung
Schaffung einer zentralen Instanz und PCA für CVCs
Die Festlegung der Standards und Policies im Rahmen der Ausgabe von CVCs erfolgt durch eine zentrale übergeordnete Instanz im
Gesundheitswesen.
Begründung
Implikation

Die Instanz fungiert als Policy-CA (PCA) und zertifiziert die CAs der
Kartenherausgeber.

Definition nachvollziehbarer Trustmodelle
Es muss „die“ zentrale Instanz geschaffen und betrieben werden.
Tabelle 81: PKI für HBA – PKI-Struktur
AE- LS 16
Bereich
PKI für HBA – PKI-Struktur
Annahmen
Berufsgruppenspezifische Organisationen/Verbände listen ihre jeweiligen Heilberufler.
HBA muss Schlüssel zur Erstellung qual. Signaturen erhalten, Aufbau
einer PKI ist erforderlich.
Keine zentrale Instanz für alle Heilberufler im deutschen Gesundheitswesen, Einsatz Bridge-CA bzw. Cross-Zertifizierung der einzelnen CA´s (Modell 1)
Motivation
Alternativen
Entscheidung
Begründung
Implikation

Mehrere CA´s pro Berufsgruppe (Modell 3), Regelung übernimmt
der „Markt“

Pro Heilberuf – eine CA, Root-CA als Vorbereitung für Anbindung an
europäische Lösung

Root-CA zertifiziert die CA´s der einzelnen Berufsgruppen.
Logische Konsequenz aus der Rolle als Herausgeber der Karten und
Bindeglied zwischen Versicherten und anderen Instanzen des Gesundheitswesens
Entspricht derzeitiger Organisation-Struktur der Heilberufgruppen

Heilberufsgruppenspezifische Ausprägung der Prozesse/Verfahren
zur Ausgabe möglich

Infrastrukturen für Root-CA (z.B. RegTP) und Instanz für Rahmenpolicy (z.B. BSI) bereits vorhanden
Abhängige Ar- chitekturentscheidungen
© 2004
Seite
68 von 112
2.3.4.4 Public Key Infrastruktur – CVC
Tabelle 82: Einsatz von speziellen PK-Verfahren und CVC für die Karten-zu-Karten Sicherheit
AE-LSL 17
Bereich
Annahmen
Motivation
Einsatz von speziellen PK-Verfahren und CVC für die Karten-zuKarten Sicherheit
Es sind kartenbasierte Dienste für eine Authentifizierung zwischen
eGK und HBA notwendig.

Die Verfahren sind durch die HBA im Gesundheitswesen definiert
und spezifiziert.

Authentifizierung auf Ebene der Karten

Einheitliche Standards im Rahmen der Karten-zu-Karten Sicherheit
Alternativen
Nutzung von X.509 basierten Verfahren
Entscheidung
Begründung
Zur Umsetzung der Karten-zu-Karten Authentifizierung kommen die im
Rahmen der HBA-Spezifikation definierten Verfahren und Zertifikatsformate (CVC) zum Einsatz.
Sicherheitstechnisch notwendig
Implikation
Nutzung eines in der Praxis nicht erprobten PK-Verfahrens
Tabelle 83: Definition der Standards zum Einsatz von CVCs
AE- LS 18
Bereich
Annahmen
Definition der Standards zum Einsatz von CVCs
CVCs kommen als Sicherheitsmechanismus im Gesundheitswesen
zum Einsatz.

CVCs lassen sich ausschließlich im Umfeld des Gesundheitswesens einsetzen.
Motivation
Notwendig für eine übergreifende Sicherheitsarchitektur
Alternativen

Die Sicherheitsfunktionen auf Kartenebene werden ohne asym.
Krypto implementiert.

Für die Sicherheitsfunktionen auf Kartenebene werden auch X.509
Zertifikate eingesetzt.
Entscheidung
Die Funktionen zur Authentifizierung und Verschlüsselung auf Kartenebene (Card2Card) basieren auf den aktuellen (V2.1) Spezifikationen
der HBAs und SMCs und werden übergreifend im Gesundheitswesen
festgelegt.
Begründung
Spezifikationen sind für HBAs und SMCs im Gesundheitswesen „gesetzt“.
Implikation
Nutzung eines neuen (nicht erprobten) kryptografischen Verfahrens,
das nicht auf gängigen Standards basiert.
© 2004
Seite
69 von 112
Tabelle 84: Beidseitige C2C-Authentifizierung mittels CVCs
AE- LS 19
Bereich
Annahmen
Motivation
Alternativen
Entscheidung
Begründung
Beidseitige C2C-Authentifizierung mittels CVCs
Alle eGKs, HBAs und SMCs nutzen die Verfahren der C2CAuthentifizierung.
Notwendig für das Design und die Ausstattung der Karte

Notwendig für die Ausgestaltung der Infrastrukturdienste

Notwendig für die Ausgestaltung der Anwendungen (Sicherheitskomponenten)

Es erfolgt keine Authentifizierung zwischen eGK und HBA / SMC.

Es erfolgt nur eine einseitige Authentifizierung des HBA bzw. der
SMC (keine Authentifizierung der eGK).
Alle eGKs erhalten CVCs zur Authentifizierung der Karte.
Beidseitige Authentifizierung der Karten mittels CVCs (eGK->HBA,
eGK<->SMC, etc.).
Funktion Bestandteil der Rahmenarchitektur
Implikation
Die Authentifizierung erfolgt auf Ebene der Rolle „Versicherter“.
Alle eGKs werden mit Schlüsselpaaren und Auth-CVCs personalisiert.
2.3.4.5 Public Key Infrastruktur – X.509
Tabelle 85: Einsatz X.509 basierter PK-Verfahren für die Anwendungssicherheit und elektronische Signatur
AE- LS 20
Bereich
Motivation
Einsatz X.509 basierter PK-Verfahren für die Anwendungssicherheit und elektronische Signatur
Es kommen PK-Verfahren im Gesundheitswesen zum Einsatz, die
über die Karten-zu-Karten basierten Dienste hinausgehen.
Festlegung der Verfahren
Alternativen
Nutzung von CVC oder anderen PK-Verfahren
Annahmen
Entscheidung
Zur Umsetzung aller anwendungsbezogenen PK-basierten Sicherheitsdienste kommen X.509 Zertifikate zum Einsatz (Ausnahme Karten-zu-Karten Authentifizierung).
Begründung
Nutzung internationaler Standards und gängiger Verfahren und Infrastrukturen
Implikation
Unterschiedliche PK-Verfahren und Zertifikatsformate im Gesundheitswesen (CVC / X.509)
© 2004
Seite
70 von 112
Tabelle 86: Einsatz X.509 basierter PK-Verfahren für Anwendungs- und Kartenadministration
AE- LS 21
Bereich
Motivation
Einsatz X.509 basierter PK-Verfahren für Anwendungs- und Kartenadministration
Es kommen PK-Verfahren im Gesundheitswesen zum Einsatz, die
über die Karten-zu-Karten basierten Dienste hinausgehen
Festlegung der Verfahren
Alternativen
Nutzung von CVC oder anderen (PK)-Verfahren
Annahmen
Entscheidung
Zur Umsetzung aller PK-basierten Sicherheitsdienste zur Administration von Karten und Anwendungen kommen X.509 Zertifikate zum Einsatz (Ausnahme Karten-zu-Karten Authentifizierung).
Begründung
Nutzung internationaler Standards und gängiger Verfahren und Infrastrukturen
Implikation
Unterschiedliche PK-Verfahren und Zertifikatsformate im Gesundheitswesen (CVC / X.509)
Tabelle 87: Definition der Standards zum Einsatz von X.509 Zertifikaten
AE- LS 22
Bereich
Annahmen
Definition der Standards zum Einsatz von X.509 Zertifikaten
X.509 Zertifikate kommen parallel zu den CVC Verfahren zum Einsatz.
Motivation
Erreichung einer größtmöglichen Interoperabilität mit anderen PKIs,
Verfahren, Produkten und Dienstleistungen
Nutzung / Entwicklung proprietärer Lösungen im Gesundheitswesen
Alternativen
Entscheidung
Begründung
Implikation
Die Funktionen zur Authentifizierung, Verschlüsselung und elektronischen Signatur auf Basis von X.509 Zertifikaten basieren auf internationalen Standards (X.509, RSA, PKCS etc) und berücksichtigen die
Vorgaben nationaler Standardisierungsgremien (u.a. ISIS-MTT und
Signatur-Bündnis).
Prinzipielle Anforderung aus der Rahmenarchitektur

Vorgaben der Bundesregierung (e-Card Initiative)

Berücksichtigung der Standards beim Lösungsdesign notwendig

Enge Abstimmung mit den entsprechenden Gremien notwendig
© 2004
Seite
71 von 112
2.3.4.6 Public Key Infrastruktur – Ausstattung eGK
Tabelle 88: eGK Funktionen auf Basis von X.509 Zertifikaten
AE- LS 23
Bereich
Annahmen
eGK Funktionen auf Basis von X.509 Zertifikaten
Es gibt zum Startpunkt der eGK keine Pflichtanwendung, die die Personalisierung der eGK mit X.509 Zertifikaten zwingend für alle eGKs
erfordert.
Motivation

Notwendig für das Design und die Ausstattung der Karte

Notwendig für die Ausgestaltung der Infrastrukturdienste

Notwendig für die Ausgestaltung der Anwendungen (Sicherheitskomponenten)

Karten werden zwingend mit einem oder mehreren Schlüsselpaaren und Zertifikaten personalisiert.

Karten werden mit unpersonalisierten Schlüsseln ausgeliefert (für
nachträgliche Zertifizierung).
Alternativen
Entscheidung
Begründung
Implikation
Das Aufbringen von Schlüsseln und X.509 Zertifikaten für die Funktionen Authentifizierung, Verschlüsselung und elektronische Signatur ist
optional.
Reduzierung der Komplexität

Erhebliche Kostensenkung

Karten können vom Herausgeber optional bei der ersten Personalisierung oder zu einem späteren Zeitpunkt mit Zertifikaten ausgestattet werden

X.509 basierte Funktionen stehen nicht flächendeckend zur Verfügung
Tabelle 89: Funktionen für qualifizierte Signaturen
AE- LS 24
Bereich
Funktionen für qualifizierte Signaturen
Annahmen
Es werden zu einem späteren Zeitpunkt qualifizierte Signaturen mittels
der eGK benötigt.
Notwendig für die Spezifikation der Karte
Motivation
Alternativen
Entscheidung
Begründung
Die eGK sieht in einer ersten Ausprägung keine Funktionen für qualifizierte Signaturen vor.
Die eGK ist technisch geeignet, qualifizierte Signaturen nach
SigG/SigV auf der Basis von qualifizierten X.509 Zertifikaten zu erzeugen.
Optionaler Einsatz qualifizierter Signaturen ohne Wechsel der Karten
möglich
© 2004
Seite
72 von 112
AE- LS 24
Bereich
Funktionen für qualifizierte Signaturen
Implikation
Die Karte erfüllt die Anforderungen von SigG/SigV (Evaluierte Karte
CC EAL4+ und PP für Signaturkarten).
2.3.4.7 Public Key Infrastruktur – Verantwortlichkeiten im Gesundheitswe-
sen
Tabelle 90: Herausgeber der CVC auf eGK
AE- LS 25
Bereich
Annahmen
Herausgeber der CVC auf eGK
Die Krankenversicherer sind Herausgeber der eGK.
Motivation

Vereinfachung der Verfahren

Schaffung klarer rechtlicher Verantwortlichkeiten

Kartenpersonalisierer als Herausgeber

Unabhängige Dienstleister als Herausgeber
Alternativen
Entscheidung
Die Krankenversicherer sind die Herausgeber (Certificate Issuer) der
CVC.
Begründung
Implikation
Kassen übernehmen die (juristische) Verantwortung für die PKStrukturen der eGK.
Tabelle 91: Herausgeber nicht-qualifizierter X.509 Zertifikate
AE- LS 26
Bereich
Annahmen
Motivation
Alternativen
Entscheidung
Herausgeber nicht-qualifizierter X.509 Zertifikate
Die eGK kann optional fort. X.509 Zertifikate und entsprechende Funktionen aufnehmen.
Eine übergeordnete zentrale Instanz im Gesundheitswesen gibt die
X.509 Zertifikate als „Issuer“ heraus.

Die Kartenpersonalisierer geben die X.509 Zertifikate als „Issuer“
heraus.

Unabhängige TTPs geben die X.509 Zertifikate als „Issuer“ heraus.

Die KVs fungieren als „Herausgeber“ der optionalen nichtqualifizierten X.509 Zertifikate (KVs sind „Issuer“).

Eine organisatorisch / rechtliche Zusammenfassung mehrerer KVs
zu einem Herausgeber ist möglich.
© 2004
Seite
73 von 112
AE- LS 26
Bereich
Begründung
Herausgeber nicht-qualifizierter X.509 Zertifikate
KVs haben die Kundendaten.
Implikation

KVs sind für die Karten „verantwortlich“.

Die Rollen von Kartenherausgeber und X.509 Zertifikats Herausgeber sind identisch.

Die KVs liefern die Personalisierungsdaten (RA-Funktion).

Jeder Zertifikats-Herausgeber hat eine eigene X.509 CA.
Tabelle 92: Herausgeber der CVC auf HBA und SMC
AE- LS 27
Bereich
Annahmen
Herausgeber der CVC auf HBA und SMC
Die Kammern und Berufsverbände sind Herausgeber der HBA und
SMC.
Motivation
Alternativen

Entscheidung
Die Kammern und Berufsverbände nicht-verkammerter Berufsgruppen
fungieren als Herausgeber (Certificate Issuer) der CVC.
Begründung
Implikation
Kammern und Verbände übernehmen die (juristische) Verantwortung
für die PK-Strukturen der HBA / SMC.
Tabelle 93: Herausgeber der X.509 Zertifikate auf HBA und SMC
AE- LS 28
Bereich
Herausgeber der X.509 Zertifikate auf HBA und SMC
Annahmen
Die Kammern und Berufsverbände sind Herausgeber der HBA und
SMC.
Motivation
Alternativen
Entscheidung

Die Kammern und Berufsverbände nicht-verkammerter Beruftgruppen
fungieren als Herausgeber (Certificate Issuer) der X.509 Zertifikate auf
HBA und SMC.
© 2004
Seite
74 von 112
AE- LS 28
Bereich
Herausgeber der X.509 Zertifikate auf HBA und SMC
Begründung
Implikation
Abhängige
chitekturentscheidungen
Kammern und Verbände übernehmen die (juristische) Verantwortung für
die PK-Strukturen der HBA/SMC.
Ar- -
Tabelle 94: PKI für HBA – Bestätigung der Berufsbezeichnung
AE- LS 29
Bereich
PKI für HBA – Bestätigung der Berufsbezeichnung
Annahmen
Motivation
Berufsgruppenspezifische Organisationen listen ihre jeweiligen Heilberufler.
Signaturen müssen Berufsbezeichnung des „Heilberuflers“ tragen.
Alternativen
-
Entscheidung
Pro Berufsgruppe ist eine Standesorganisation (z.B. Kammer) für die
Attributsbestätigung zuständig.
Standesorganisationen werden in Prozess zur HBA-Beantragung (RA
des TC) integriert.
Begründung
Standesorganisationen listen ihre jeweiligen Mitglieder (derzeit z.T. nur
regional). Eine berufsgruppenübergreifende Gesamtliste ist derzeit nicht
verfügbar.
Implikation
Entsprechende Standesorganisationen stellen Schnittstelle zum Trustcenter zur Verfügung.
Abhängige Ar- chitekturentscheidungen
Tabelle 95: Schlüssel und Zertifikatserzeugung der CVCs
AE- LS 30
Bereich
Schlüssel und Zertifikatserzeugung der CVCs
Annahmen
CVCs werden auf die eGK aufgebracht.
Motivation
Zertifizierung (Zertifikatserstellung) durch getrennten ZDA
Dienstleister (Trennung der Rollen)
Alternativen

Entscheidung
Schlüsselerzeugung UND Zertifizierung (Zertifikatserstellung) durch
getrennten ZDA Dienstleister (Trennung der Rollen)
Die Schlüssel- & Zertifikatserzeugung der CVC Schlüssel und Zertifika-
© 2004
Seite
75 von 112
AE- LS 30
Bereich
Schlüssel und Zertifikatserzeugung der CVCs
Begründung
te erfolgt durch den Kartenpersonalisierer.
Performantere Produktionsprozesse

Einfachere Zuständigkeiten
Implikation
Kartenpersonalisierer fungieren als ZDA (müssen CA aufbauen und
betreiben).
2.3.4.8 Public Key Infrastruktur – Verzeichnisse und Validierung
Tabelle 96: Verzeichnisdienste eGK
AE- LS 31
Bereich
Verzeichnisdienste eGK
Annahmen
Die eGK enthalten in der ersten Basisversion keine X.509 Zertifikate
mit zugehörigem Schlüsselmaterial.
Applikation der eGK werden über CAMS verwaltet.
Zentrale Datenhaltung personenbezogener Daten sollte vermieden
werden.
Unter Umständen kann die Verwaltung von Schlüsselmaterial zur Verwaltung der Karten notwendig sein.
Zentraler Verzeichnisdienst für CVC-Zertifikate
Motivation
Alternativen
Entscheidung
Begründung
Implikation
eGK: Zur An- und Abfrage des Vertragsstatus (Versichert ja/nein, Zuzahlungsstatus) ist eine zentrale Stelle zur Statusanfrage, die diese an
lokale Verzeichnisse weiterleitet, einzurichten. Als Protokoll kann u.U.
OCSP verwendet werden.
eGK: Zunächst sind keine Verzeichnisse zur Verwaltung von X.509
Zertifikaten notwendig.
eGK/HBA: Bzgl. der CVC ist kein übergeordneter Verzeichnisdienst
notwendig (da keine Prüfung der Gültigkeit dieser stattfindet).
Statusabfrage bzgl. des Vertragsstatus eines Versicherten muss mögliche sein.
-
Tabelle 97: PKI für HBA - Verzeichnisdienst
AE-LSL 32
Bereich
PKI für HBA - Verzeichnisdienst
© 2004
Seite
76 von 112
AE-LSL 32
Bereich
Motivation
PKI für HBA - Verzeichnisdienst
Verzeichnisdienste werden für die Statusabfrage eines HBA genutzt
(LDAP, Sperrlisten)
Status eines HBA bzw. einer HBA-Signatur muss überprüfbar sein
Alternativen
-
Entscheidung
Nutzung der mit qual. Sign. aufzubauenden berufsgruppenspezifischen
Verzeichnisdienste für die Statusabfrage einer HBA
Öffentlicher Verzeichnisdienst ist durch PKI gegeben.
Verweis auf „dezentrale“ Verzeichnisdienste/Sperrlisten durch Attribute
im Zertifikat möglich
Offenheit bei Hinzunahme von weiteren Berufsgruppen
Wenn aus Sicht von Anwendungen zentrales Verzeichnis sinnvoll werden sollte, Lösung über MetaDirectory möglich
-
Annahmen
Begründung
Implikation
Tabelle 98: Validierung von Zertifikatsinformationen
AE-LSL 33
Bereich
Annahmen
Motivation
Alternativen
Entscheidung
Validierung von Zertifikatsinformationen
HBA: Enthält Schlüsselmaterial zur Erstellung qual. Signaturen

eGK: enthalten in der ersten Basisversion keine X.509 Zertifikate
mit zugehörigem Schlüsselmaterial
Zertifikatsinformationen (Zertifikate gesperrt etc.) ist in vielen Fällen
notwendig.
Generelle Validierung der CVC im Rahmen eines jeden Card2Card
Authentifizierungsvorgangs

Generelle OCSP-Abfrage im Rahmen einer jeden Signaturprüfung
(qual.)

CVC: Keine Online-Validierung vorgesehen. Kritisch ist nur die Gültigkeit des CVC des HBA. Eine organisatorische Lösung (HBA eines Leistungserbringers wird sehr zeitnah bei Sperrung der Karte
eingezogen) ist gegenüber verpflichtender Online-Überprüfung bei
jeder Card2Card Authentifizierung zu empfehlen.

Qual. Zert. HBA: Zentraler Verzeichnisdienst nach SigG vorhanden. Prüfung der Gültigkeit des qual. Zert. eines Leistungserbringers mittels CRL /OCSP
Begründung
Vermeidung von Netzwerkverkehr
Implikation
-
Abhängige Archi- tekturentschei© 2004
Seite
77 von 112
dungen
2.3.4.9 Public Key Infrastruktur – Clientumgebung für PK-Funktionen
Tabelle 99: Nutzung der PK-Clientarchitektur des Signaturbündnisses
AE- LS 34
Bereich
Annahmen
Motivation
Alternativen
Entscheidung
Begründung
Implikation
2.3.5
Nutzung der PK-Clientarchitektur des Signaturbündnisses
Einsatz von eGK und HBA in einer definierten Clientumgebung
Schaffung einheitlicher Standards und größtmöglicher Interoperabilität,
auch für einen Parallelbetrieb anderer kryptografischer Funktionen auf
dem gleichen System
Keine Festlegung einer einheitlichen Krypto-Client-Architektur

Definition einer eigenen Krypto-Client-Architektur

Der bIT4health Connector greift auf die Basisarchitekturdefinitionen
des Signaturbündnisses zurück.

Standards des Signaturbündnisses werden soweit möglich übernommen.

Spezifische Erweiterungen des Gesundheitswesens werden – soweit möglich – in den Standard integriert.
Schaffung einer übergreifenden interoperablen Plattform für den Betrieb kryptografischer Komponenten in Deutschland
Das Gesundheitswesen bringt sich aktiv in das Signaturbündnis ein
und übernimmt / steuert die Standardisierung.
-
Kartenproduktion und Kartenpersonalisierung
Tabelle 100: AE-LK1 Architekturentscheidung: Signaturfähigkeit der eGK
AE-LK1
Bereich
Annahmen
Motivation
Alternativen
Signaturfähigkeit der eGK
Es sind bislang keine Nutzungsfälle für die elektronische Signatur
eines Versicherten in der bIT4Health-Rahmenarchitektur bekannt.
§ 291 (2a) SGB V fordert , die eGK „muss technisch geeignet sein,
Authentifizierung, Verschlüsselung und elektronische Signatur zu ermöglichen“.
Eine Versorgung von mehr als 70 Mio. Versicherten mit fortgeschrittenen oder qualifizierten Signaturen ist technisch, organisatorisch und kommerziell erheblicher Aufwand, dem z. Z. überhaupt
kein Nutzen gegenübersteht.

Es soll die Möglichkeit geschaffen werden, diese Funktionalität bei
Bedarf bereitzustellen.

Auslieferung der eGK mit einer personalisierten Anwendung für
fortgeschrittene Signaturen

Auslieferung der eGK mit einer personalisierten Anwendung für
qualifizierte Signaturen
© 2004
Seite
78 von 112
AE-LK1
Bereich
Entscheidung
Begründung
Implikation
Signaturfähigkeit der eGK
Die eGK ist als sichere Signaturerstellungseinheit zu zertifizieren.
Die eGK wird zum Zeitpunkt der Ausstellung keine Signaturapplikation
enthalten bzw. wird nicht mit den nötigen Schlüssel versehen.
Es ist möglich, im Feld eine fortgeschrittene oder qualifizierte Signaturanwendung auf die eGK aufzubringen.
Es gibt im Kontext der bIT4health-Rahmenarchitektur keinen bekannten Nutzfall für eine elektronische Signatur des Versicherten.
Der technische und organisatorische Aufwand zur flächendeckenden
Versorgung mit Signaturanwendungen verursacht erhebliche Kosten,
denen z.Z. kein Nutzen gegenübersteht.
Die Technologie zur Bereitstellung von personalisierten Anwendungen zur qualifizierten Signatur (Trust Censter) ist nur in verhältnismäßig geringen Stückzahlen vorhanden und zugelassen. Eine rechtzeitige Bereitstellung und Zertifizierung der erforderlichen Technik stellt
ein hohes Risiko für die Einhaltung der Zeitvorgaben dar.
An die Erhebung von Personendaten, die Kartenpersonalisierung und
die Kartenzustellung werden für die eGK keine so hohen Anforderungen gestellt, wie sie bei einer Signaturkarte erforderlich wären.
Kostensenkung für die Ausstellung/Ausgabe von eGKs, solange eine
Signaturanwendung nicht in erheblichem Umfang genutzt wird.
Eine Nutzbarkeit von Signaturanwendungen auf der eGK ist dennoch
ab der ersten eGK gewährleistet, indem die erforderlichen Registrierungs- und Personalisierungsprozesse im Feld (z. B. in einem Trust
Center) erfolgen.
E-LK2, AE-LK6
Tabelle 101: AE-LK2 Architekturentscheidung zur Sicherheitskonzeption
AE-LK2
Bereich
Annahmen
Motivation
Alternativen
Sicherheitskonzeption Herstellung bis Ausgabe
Die Erstellung eines vollständigen neuen Sicherheitskonzeptes wird
sehr lange dauern. Terminvorgaben können dadurch möglicherweise
nicht eingehalten werden.
Der European Digital Tachograph ist ein europaweites Projekt, in dem
auch Vorgaben an eine europaweite Interoperabilität gemacht werden.
Die technische Ausprägungen bzgl. der eGK, HBA und SMC sind z.B.
denen der Chipkarten in europäischen Tachograph-Projekten vergleichbar (z. B. CVCs).
Für die Herstellung und Ausgabe von eGK, HBA und SMC muss eine
akzeptierte Sicherheitskonzeption zu Grunde gelegt werden, die sowohl Anbietern wie auch Nutzern der Karte Planungssicherheit bietet.
Für die Aspekte Herstellung bis Ausgabe der neuen Karten sollten existierende und vergleichbare Sicherheitskonzepte berücksichtigt werden.
Es werden eGK, HBA und SMC von unterschiedlichen Anbietern hergestellt, die keiner einheitlichen Sicherheitsrichtlinie entsprechen, damit
potentiell unsicher und ggf. auszutauschen sind, sobald ein finales und
neues Sicherheitskonzept vorgeschrieben wird.
© 2004
Seite
79 von 112
AE-LK2
Bereich
Entscheidung
Begründung
Implikation
Sicherheitskonzeption Herstellung bis Ausgabe
Die Produktion und Ausgabe von eGKs und HBAs werden erst nach
Vollendung und Abstimmung eines Sicherheitskonzepts bereitgestellt,
was den Rollout deutlich verzögert.
Als existierendes Sicherheitskonzept für die Herstellung und Ausgabe
von Chipkarten werden die „European Digital Tachograph Common
Security Guideline“ [TachoCSG] und „Guideline und Template National
CA Policy“ [TachoCAP] beispielhaft vorgeschlagen. Gegebenenfalls
erforderliche Anpassungen haben sich auf dem von diesem Dokument
dargestellten Sicherheitsniveau zu bewegen bzw. den entsprechenden
nationalen Ausprägungen zu folgen.
Die weiteren Inputs des BSI und des BfD sind zu berücksichtigen.
Die Unterschiede bezüglich eGK (ohne/mit elektronischer Signatur)
und HBA/SMC müssen berücksichtigt werden.
Das Adaptieren einer oder mehrerer bestehenden Sicherheitskonzeptionen wird als schnelle und effektive Lösung betrachtet, um die langwierige Entwicklung und Abstimmung eines völlig neuen Sicherheitskonzepts zu vermeiden.
Nur auf Basis vollständiger Sicherheitskonzepte lassen sich notwendige Sicherheitsevaluierungen und Zertifizierungen der Produkte (Chipkarten) durchführen.
Produktionsumgebungen und Einrichtungen können nur gemäß einheitlich festgelegter Sicherheitsanforderungen vorbereitet werden.
-
© 2004
Seite
80 von 112
Tabelle 102: AE-LK3 Architekturentscheidung „Begrenzte Gültigkeit von Karten im Test“
AE-LK3
Bereich
Annahmen
Motivation
Alternativen
Entscheidung
Begründung
Implikation
Abhängige
Begrenzte Gültigkeit von Karten in Pilot und Testregionen
Karten zur Verwendung in Pilotvorhaben sollen eine beschränkte Gültigkeit erhalten, welche den beabsichtigten Nutzungszeitraum mit vernünftiger Toleranz zulässt.
Karten zur Verwendung in Testregionen sollen eine beschränkte Gültigkeit erhalten.
Die Gültigkeit jeder einzelnen Karte wird vom Herausgeber der Karte
aufgrund diverser Kriterien festgelegt.
eGK, ausgegeben für Pilotvorhaben, sind ggf. nicht geeignet alle zukünftigen Funktionen zu unterstützen (als mögliches Ergebnis eines
Pilotes können Änderungen notwendig werden).
Karten haben generell eine übliche (max.) Lebensdauer, welche durch
Häufigkeit der Nutzung, Art der Aufbewahrung, die Art der verwendeten Kartenmaterialien und Herstellmethoden beeinflusst wird.
Kürzere Gültigkeit der Karten mit Akzeptanzproblemen, wenn frühzeitig
Karten ablaufen und neu ausgegeben werden.
Längere Gültigkeit der Karten, mit dem Risiko, dass Karten neue Funktionen für diese Karten nicht verfügbar sind.
Karten (eGK) für Pilote erhalten eine max. Gültigkeit bis 31.12.07.
Karten (eGK) für Testregionen erhalten eine max. Gültigkeit von 5 Jahren ab Ausgabe.
Ab 01.01.08 erfolgt eine Harmonisierung innerhalb der EU.
Investitions- und Planungssicherheit für Hersteller ist notwendig. Kürzere Gültigkeit der Karten führen zu Akzeptanzproblemen, wenn frühzeitig Karten ablaufen und neu ausgegeben werden.
Längere Gültigkeit der Karten erhöht das Risiko, dass für diese Karten
neue Funktionen nicht verfügbar sind.
-
© 2004
Seite
81 von 112
Tabelle 103: AE-LK4 Architekturentscheidung zur Nutzungsgrenze HBA
AE-LK4
Bereich
Annahmen
Motivation
Alternativen
Entscheidung
Begründung
Implikation
Abhängige
Nutzungsgrenze des HBA und der SMC
HBA sollen u.A. zur Erzeugung von qualifizierten Signaturen und zur
Authentifikation mit eGK im Rahmen des Gesundheitssystems verwendet werden.
Der Einsatz des HBA bzw. der SMC außerhalb des Gesundheitswesens ist derzeit nicht gefordert.
Der HBA und die SMC sind erforderliche Komponenten und Bestandteil der Telematikplattform.
Die Erstellung der notwendigen Infrastruktur und die Ausgabe der HBA
und SMC und sollen zeitgerecht erfolgen.
Der HBA kann/soll über das Gesundheitswesen hinaus z.B. als Signaturkarte verwendet werden.
Der HBA und die SMC sollen im Rahmen ihrer Funktionen ausschließlich im Gesundheitswesen verwendet werden.
Die Prozesse, um Registrierung von Heilberuflern zum Erhalt (Beantragung) einer HBA und SMCs, die Herstellung, Personalisierung und
Ausgabe sind nicht Bestandteil oder Aufgabe der Telematikplattform.
Trotzdem haben diese Prozesse technische und organisatorische
Schittstellen in die Telematikplattform, da der HBA und die SMC nach
seiner Ausgabe durch Benutzung Bestandteil der Telematikplattform
werden.
Strikte Abgrenzung der Nutzung, um die Komplexität der erforderlichen
Infrastruktur zum HBA und zur SMC wie auch der gesamten Telematikplattform zu minimieren.
Geschlossene Benutzergruppe mit einer auf das Gesundheitswesen
beschränkten Infrastruktur.
Starke Implikation auf das Trust Modell der PKI im Gesundheitswesen
Organisatorische und technische Schnittstellen der Herausgeber der
HBA und der SMC zur Telematikplattform
© 2004
Seite
82 von 112
Tabelle 104: AE-LK5 Architekturentscheidung zur Nutzungsgrenze eGK
AE-LK5
Bereich
Annahmen
Motivation
Alternativen
Entscheidung
Begründung
Implikation
Abhängige
Nutzungsgrenze der eGK
Das GMG (§ 291, § 291a SGB V) macht Vorgaben für die eGK ausschließlich für die Verwendung im Gesundheitswesen.
Die Notwendigkeit fortgeschrittener bzw. qualifizierter Signaturen mittels eGK in Zukunft ist nicht sicher, aber denkbar.
Die eGK sollte nur im Zusammenhang mit zertifizierten und zugelassenen Komponenten im Gesundheitssystem zum Einsatz kommen, um
ein Missbrauch personenbezogener Daten auszuschließen.
Die eGK wird über das Gesundheitswesen hinaus z.B. als Signaturkarte verwendet.
Die eGK soll im Rahmen ihrer Funktionen ausschließlich im Gesundheitswesen verwendet werden.
Die Prozesse Registrierung von Versicherten (einschl. der Fotoerfassung/-zuordnung) zum Erhalt (Beantragung) einer eGK, Herstellung,
Personalisierung und Ausgabe sind nicht Bestandteil oder Aufgabe der
Telematikplattform. Trotzdem haben diese Prozesse technische und
organisatorische Schittstellen in die Telematikplattform, da die eGK
nach ihrer Ausgabe elementarer Bestandteil der Telematikplattform
wird.
Strikte Abgrenzung der Nutzung, um Sicherheitsrisiken zu minimieren.
Geschlossene Benutzergruppe mit einer auf das Gesundheitswesen
beschränkten Infrastruktur.
Starke Implikation auf das Trust Modell der PKI im Gesundheitswesen
-
© 2004
Seite
83 von 112
Tabelle 105: AE-LK6 Sicherheitsniveau der eGK
AE-LK6
Bereich
Annahmen
Motivation
Alternativen
Entscheidung
Begründung
Implikation
Sicherheitsniveu der eGK
eGK müssen technisch geeignet sein elek. Signaturen zu erstellen.
Die Erzeugung qualifizierter Signaturen mittels eGK in Zukunft ist nicht
sicher, aber denkbar.
Das erforderliche Sicherheitsniveau für eGK als Träger und/oder
Schlüssel für personenbezogenen medizinische Daten muss mindestens so hoch sein wie das für qualifizierte Signaturkarten.
Planungs- und Investitionssicherheit
eGK muss neben Anforderungen an mögl. qual. Signaturen geeignet
sein, den Schutz von personenbezogenen med. Daten zu gewährleisten.
Nach Ausgabe der eGK sollte es möglich sein, bei entsprechenden
autorisierten Stellen in einem entsprechenden Registrierungs- und
Nachpersonalisierungsprozess, die eGK zu einer Signaturkarte für
qualifizierte Signaturen zu erweitern.
Keine
BSI definiert (nach Vorschlag) Zertifizierungslevel und Protection Profiles, die der eGK zugrunde liegen.
BSI erstellt (nach Vorschlag) Sicherheitskonzept für Produktion, Personalisierung und Ausgabe der eGK.
Selbstverwaltung beauftragt die Erstellung eines Sicherheitskonzept/Policy für Produktion, Ausgabe und Einsatz der eGK im deutschen Gesundheitswesen.
Sicherheitsniveau der eGK kann nicht ohne Vorgaben des BSI und BfD
definiert werden.
Eine einfache Ableitung des erforderlichen Sicherheitsniveau der eGK
aus Anforderungen des GMG sind bzgl. der eGK nicht möglich.
Im Rahmen des Solution Outline wird angenommen:

eGK Sicherheit CC/EAL4+ evaluiert

Sicherheitskonzept/-niveau für Produktion und Personalisierung hat
mind. den Level, der bei Tachograph-Chipkarten (neue EU-weite
Fahrtenschreiberkarten) bzw. Bankkarten mit Chip üblich ist.
-
© 2004
Seite
84 von 112
Tabelle 106: AE-LK7a Architekturentscheidung zur PIN-/PUK-Erzeugung/Ausgabe (1)
AE-LK7a
Bereich
Annahmen
Motivation
Alternativen
Entscheidung
Begründung
Implikation
PIN/PUK zur eGK (1)
Für die Nutzung bestimmter Anwendungen mittels einer eGK ist eine
PIN-Funktionalität erforderlich.
Mehrfach fehlerhafte PIN-Eingaben führen über einen Fehlbedienungszähler (FBZ) in der eGK zur Sperrung der entsprechenden Anwendungen dieser eGK.
Schutz vor Missbrauch
Einfacher Umgang
Eine vergessene oder mehrfach falsch eingegebene PIN soll nicht zur
endgültigen Unbrauchbarkeit der eGK und Verlust der in ihr gespeicherten medizinischen Daten führen.
eGK muss neu ausgestellt werden.
Alle in einer eGK gespeicherten Daten müssen immer auch an anderer
Stelle sicher gespeichert sein (Datenkopie).
Durch den berechtigten Versicherten soll mittels einer ihm bei Ausgabe
der eGK, übersandten PUK der FBZ in der eGK zurückgesetzt und
eine neue PIN definiert werden können. Dadurch wird die Sperre aufgehoben.
PIN-/PUK-Verfahren sind etabliert und akzeptiert.
Das PIN-PUK-Verfahren lässt sich ohne besondere Infrastrukturmaßnahmen mit der Ausgabe der ersten eGK bereits in den Piloten an geeigneten Kartenterminals einsetzen.
Sichere Erzeugung und Ausgabe von PIN-/PUK-Briefen an die Versicherten bei der Ausgabe der eGK.
-
© 2004
Seite
85 von 112
Tabelle 107: AE-LK7b Architekturentscheidung zur PIN-/PUK-Erzeugung/Ausgabe (2)
AE-LK7b
Bereich
Annahmen
Motivation
Alternativen
Entscheidung
Begründung
Implikation
PIN/PUK zur eGK (2)
Ausschließlich der berechtigte Versicherte muss die Möglichkeit erhalten, die Sperre (fehlerhafte PIN-Eingabe) aufzuheben und eine neue
PIN zu definieren.
Eine vergessene oder mehrfach falsch eingegebene PIN soll nicht zur
endgültigen Unbrauchbarkeit der eGK und Verlust der in ihr gespeicherten medizinischen Daten führen.
Schutz vor Missbrauch und Sicherstellung der Funktion
Null-PIN oder Transport-PIN-Verfahren bei Ausgabe der eGK kombiniert mit bedienten Sonderfunktionsterminals (ausschließlich autorisierte Stellen) bei denen der Versicherte nach einer positiven Identitätsprüfung eine neue PIN definieren kann.
PIN-/PUK-Briefe werden während der Personalisierung der eGK erzeugt und separat zur eGK dem Versicherten zugesandt.
PIN und PUK werden sicherheitstechnisch gleich behandelt und müssen in einer sicheren Umgebung generiert und sicher zur Chipkarte
übertragen werden (siehe Sicherheitsniveau).
Sobald die notwendige Infrastuktur verfügbar ist und entsprechend
autorisierten
Stellen
eingerichtet
sind,
werden
PIN-FBZRücksetzungen alternativ möglich. Auf PIN-/PUK-Briefe für weiter auszugebende eGK kann dann zugunsten einer Transport-PIN verzichtet
werden.
Das Null-PIN-Verfahren ist patentiert.
Sonderfunktionsterminals bei autorisierten Stellen erfordern zusätzliche Infrastrukturmaßnahmen wie auch organisatorische Maßnahmen.
Anfängliche eingesetzte PIN-/PUK-Verfahren schließen spätere Transport-PIN/Sonderfunktionsterminal-Verfahren nicht aus.
Die eGK muss technisch für eine PIN-Rücksetzung via Sonderfunktionsterminal gerüstet sein.
PIN und PUK müssen zur Personalisierung generiert werden und separat an den Versicherten versendet werden.
-
© 2004
Seite
86 von 112
2.3.6 Bereich Kartenproduktion und Kartenpersonalisierung
Tabelle 108: AE-LK8a Architekturentscheidung zum Artwork der eGK
AE-LK8a
Bereich
Annahmen
Motivation
Alternativen
Entscheidung
Begründung
Implikation
Anforderungen zum Artwork eGK (1)
Das Artwork darf die Auswahl des Materials für den Kartenkörper nicht
einschränken.
Die Fälschungssicherheit der Karte wird vorrangig durch den Chip
(einschl. Betriebssystem und Anwendungen) und den Personalisierungsprozess des Kartenkörpers realisiert. Optional kann ein zusätzlicher UV-Druck im Artwork erfolgen.
Die Auswahl des Kartenmaterials sollte aus Nutzungs-, Umwelt- und
Kostengesichtspunkten erfolgen.
Die Sicherheitsmerkmale des Kartenkörpers müssen angemessen sein
und durch den Leistungserbringer bei Bedarf einfach überprüft werden
können.
Keine
Keine Flächen im Artwork mit einem Farbanteil von > 50%.
Am Kartenrand ist ein maximaler Farbanteil von 40% vorzusehen. Eine
Absoftung auf einen 1mm breiten weißen Rand ist ideal.
Zusätzliche Sicherheitsmerkmale wie Guillochen- & Irisdruck, CLI, MLI
& OVI werden aus Kostengründen nicht favorisiert.
Die Berücksichtigung der Anforderungen zum Artwork erlauben den
Einsatz von umweltfreundlichem Material.
Für die eGK ist die Fälschungssicherheit bei Verwendung eines geeigneten Personalisiervefahrens (Kartenkörper) ausreichend.
-
© 2004
Seite
87 von 112
Tabelle 109: AE-LK8b Architekturentscheidung zum Artwork der eGK (2)
AE-LK8b
Bereich
Annahmen
Motivation
Alternativen
Entscheidung
Begründung
Implikation
Anforderungen zum Artwork eGK (2)
Auf der Rückseite der eGK ist ein einheitliches Artwork (Europäische
Krankenversicherungskarte) spezifiziert. Für die Vorderseite (Chipseite) wird ein einheitliches Basis-Artwork verwendet mit einem noch zu
definierenden freien Anteil für die Darstellung des Versicherers (ähnlich heutige KVK).
Kosteneinsparung bei der Produktion und „Product Identity“
Individuelle Gestaltung der Vorderseite nach Vorgaben der einzelnen
Krankenversicherungen
Es wird ein einheitliches Basis-Artwork für die Vorderseite der eGK
erstellt.
eGK für Pilote und Testvorhaben sollen sich nicht durch unterschiedliche Artworks unterscheiden.
Die eGK wird sofort als Gesundheitskarte erkannt und Fälschungen
fallen eher auf.
Unterschiedliche Artwork verunsichern die Nutzer.
Die Logistikkosten beim Kartenhersteller werden reduziert.
-
Tabelle 110: AE-LK9 Architekturentscheidung zur optischen Personalisierung
AE-LK9
Bereich
Annahmen
Motivation
Alternativen
Entscheidung
Begründung
Implikation
Optische Personalisierung von HBA, eGK und SMC
Die optische Personalisierung (Beschriftung & Foto auf Kartenkörper)
aller drei Kartentypen sollte nur in einer Technologie erfolgen, die eine
gewisse Fälschungssicherheit darstellt.
Die Fälschung von Karten muß erschwert werden.
Die Lesbarkeit der Bedruckung muß auch nach mehreren Jahren der
Nutzung gewährleistet werden.
Optische Personalisierung mit Thermotransferverfahren
Die optische Personalisierung erfolgt mittels Lasertechnik oder einem
bzgl. Fälschungssicherheit und Qualität (Lesbarkeit der Bedruckung)
gleichwertigen Verfahren.
HBA & eGK erhalten ein Graustufen-Foto mit einer Mindestauflösung
von 300dpi.
Das Format des Fotos sollte ca. 24*32mm betragen.
Lasertechnik zur Kartenkörperpersonalisierung kommt bei viele Ausweisdokumenten (z.B. Führerscheine, Bankkarten) zum Einsatz und ist
bei den Personalisierungsdiensteanbietern Standard-Technologie.
Vorlaufzeit von ca. 6 Monaten bis zum Roll Out für Bestellung und Integration benötigter Maschinenkapazitäten
-
© 2004
Seite
88 von 112
Tabelle 111: AE-L10 Architekturentscheidung zur Sehbehindertenkennzeichnung
AE-LK10
Bereich
Annahmen
Motivation
Alternativen
Entscheidung
Begründung
Implikation
Blindenschrift
HBA & eGK sollen eine fixe Kennzeichnung erhalten im Kartenkörper
erhalten, die Blinden bzw. stark Sehbehinderten eine Erkennung des
Kartentyps ermöglicht.
Blinden bzw. stark Sehbehinderten muß die Möglichkeit gegeben werden, unter der Vielzahl heute möglicher Kartentypen die Gesundheitskarte zu erkennen.
Blinden bzw. stark Sehbehinderten muß die Möglichkeit gegeben werden zu erkennen, ob der Gegenüber eine HBA besitzt.
Keine Kennzeichnung
Personalisierte Kennzeichnung der eGK (z.B. Name des Versicherten)
Alle HBA werden mittels Braille-Schrift an geeigneter Stelle jeweils mit
max. drei Buchstaben (z.B. HBA oder HPC) gekennzeichnet.
Alle eGK werden mittels Braille-Schrift an geeigneter Stelle jeweils mit
max. drei Buchstaben (z.B. eGK oder PDC) gekennzeichnet.
Extrem gute Akzeptanzmassnahme für
die „Gesundheitskarte“ auch für nicht-Sehbehinderte.
Eine personifizierte Kennzeichnung mittels Braille-Schrift für alle Karten ist zu aufwändig.
Der verfügbare Platz auf den Karten ist sehr beschränkt.
Fertigungsprozess der Kartenkörper muss vorbereitet werden.
-
Tabelle 112: AE-L10 Architekturentscheidung zur elektrischen Personalisierung der HBA und SMC
AE-LK11
Bereich
Annahmen
Motivation
Alternativen
Entscheidung
Begründung
Elektrische Personalisierung HBA/SMC
HBA werden als Karten zur Erzeugung qualifizierter Signaturen gemäss SigG/SigV an Heilberufler herausgegeben.
SMC werden nur an registrierte Heilberufler herausgegeben.
Trustcenter sind massgeblich beteiligt.
Trustcenter und Personalisierer müssen zeitgerecht die Anforderungen
umsetzen. Zur Zeit sind Trustcenter alleine nicht aufgestellt, die erforderlichen Stückzahlen von HBA und SMC selbst zu personalisieren.
z.Z. keine
Trustcenter und Personalisierer agieren gemeinsam im Auftrag der
Herausgeber.
Die Anforderungen an die Personalisierung des Chips der HBA und
der SMC sind gemäß den Vorgaben zur Evaluierung und Zertifizierung
des Produktes “HBA” bzw. “SMC” einzuhalten und müssen den Anforderungen des SigG/SigV genügen.
Die Schnittstellen zur Kommunikation zwischen Trustcentern und Personalisierern dürfen proprietär gestaltet sein, müssen aber den Anforderungen von SigG/SigV genügen.
Die erforderlichen Infrastrukturen zur Personalisierung von großen
Stückzahlen an Signaturkarten ist derzeit nur bei Personalisierern vorhanden.
© 2004
Seite
89 von 112
AE-LK11
Bereich
Implikation
Elektrische Personalisierung HBA/SMC
Die erforderlichen Funktionen und Infrastrukturen zur Registrierung,
Herausgabe und Verwaltung von Signaturkarten bzw. der damit verbundenen Betriebsprozesse und Funktionen über einen langen Zeitraum werden derzeit nur von Trustcentern bereitgestellt.
Skalierung vorhanderner Infrastrukturen bei Trustcentern.
-
Tabelle 113: AE-L10 Architekturentscheidung zur elektrischen Personalisierung der eGK
AE-LK12
Bereich
Annahmen
Motivation
Alternativen
Entscheidung
Begründung
Elektrische Personalisierung eGK
§ 291 (2a) SGB V fordert, die eGK „muss technisch geeignet sein, Authentifizierung, Verschlüsselung und elektronische Signatur zu ermöglichen“.
Personalisierer müssen eGK handhaben wie Karten, die als Signaturkarten ausgegeben werden.
Nur ausgegebene eGK, welche den gestellten Anforderungen genügen, dürfen im Lauf ihres Lebenszyklus während der Benutzung nachträglich zu Signaturkarten aufgewertet werden.
Bei Bedarf einer Signaturanwendung im Gesundheitswesen durch den
Versicherten wird ihm nach entsprechender Registrierung eine neue
eGK mit personalisierter Signaturanwendung im Austausch zur eGK
ohne Signaturanwendung übergeben.
eGK sollen nach Ausgabe mittels entsprechender Prozesse durch
Nachpersonalisierung zu einer Signaturkarte aufgewertet werden können.
Die Anforderungen an die Personalisierung des Chips der eGK sind
aus dem zu erstellendem Sicherheitskonzept, den Erfordernissen bezüglich der Sicherheitszertifizierung des Produktes „eGK“ der technischen Spezifikation eGK sowie den jeweiligen besonderen Anforderungen der Auftraggeber zu entnehmen.
Es wird angenommen, dass die eGK gemäß den Anforderungen an
eine Signaturkarte zu evaluieren und zu zertifizieren sind. Daher wird
eine Evaluierung und Zertifizierung nach CC EAL 4+ erforderlich.
Dementsprechend sind die anzuwendenden Mechanismen zur elektrischen Personalisierung vor der Ausgabe aber auch die zur Nachpersonalisierung ausgegebener eGK entsprechend der Zertifizierung von
den Herstellern zu dokumentieren und zu implementieren.
Die Schnittstellen zur Kommunikation zwischen den Krankenversicherungen und den Personalisierern wie auch die zur Telematikinfrastruktur (den CAMS) sind entsprechend der zu erstellenden Schnittstellenspezifikationen und den Anforderungen des Sicherheitskonzeptes zu
implementieren und zu testen.
Die notwendige Infrastruktur zur Herausgabe von mehr als 70 Millionen
eGK als Signaturkarten (u.A. vorherige Identitätsfeststellung und Registrierung der Versicherten) ist z.Z. nicht in der für Signaturkarten erforderlichen Güte notwendig.
Die Schnittstellen der Personalisierer von eGK zu Trustcentern werden
© 2004
Seite
90 von 112
AE-LK12
Bereich
Elektrische Personalisierung eGK
erst benötigt, wenn tatsächlich eGK als Signaturkarten herausgegeben
werden sollen.
Die notwendige Infrastruktur zur Aufwertung von im Feld befindlichen
eGK zu Signaturkarten braucht erst bei Bedarf implementiert werden.
-
Implikation
2.3.7
-
Komponentenliste Netze und IT-Infrastruktur
2.3.7.1 Berechnungsgrundlagen von Netz- und IT-Infrastruktur
Für die Berechnung der Bandbreite wurde von dem Divisor 2 für 220 Tage / Jahr und 8
Stunden / Tag ausgegangen und die Gesamtlast (365 Tage / 24 Stunden) nur auf diesen
Zeitraum verteilt.
Nutzungstage
Stun- Minuden
ten
Sekunden
Divisor 1
Netzauslastung
Divisor 2
365
8
60,0
60 10.512.000
70%
7.358.400
260
24
60,0
60 22.464.000
70%
15.724.800
220
8
60,0
60
70%
4.435.200
6.336.000
Des weiteren wurden folgende Annahmen getroffen:
© 2004
Seite
91 von 112
Annahmen
Wert
Verschlüsselungsfaktor auf der eGK
1,8
Anzahl der Patientenfachbenutzer
20%
eGK Karte neu ausstellen /Jahr
5%
Mittlere Anzahl Arztbesuche / Jahr
2,80
Verhältnis von Spitzen – zu Dauerlast im Netz
1 : 1,2
Folgende weitere Faktoren wurden bei den Berechnungen zugrunde gelegt:
Faktoren
Wert
IP (24) und TCP Header (28) (Byte)
52
IPSEC Header (Byte)
30
Neuer IP Header bei IPSEC ESP (24 Bytes)
24
Neuer IP Header + Layer2 Header
42
L2 Header 802.3 Ethernet
18
Max Datengröße @ mtu
1376
L2 Paketgröße
1500
Antwortzeitkategorie 1 (in Sekunden)
3
Antwortzeitkategorie 2 (in Sekunden)
8
Anzahl Fachärzte
130.000
Anzahl Ärzte (BfS 2001)
297.893
Anzahl Zahnärzte (2001 = 63.854)
77.000
Anzahl Krankenhäuser (Krankhausärzte 142.310 in
2002)
Anzahl Apotheken (Apotheker 47.692 in 2002)
2.240
22.000
Arztbriefe pro Tag (Fachärzte)
10
Arztbriefe / Jahr / Krankenhaus /ambulant
25.000
Durchgangsärzte und H-Ärzte
6.500
BG Arztbriefe / Arzt / Monat
130
Länge Arztbrief zw. 2- 20Kbyte
20.000
Entlassbriefe /Jahr/KH stationär8
9.500
8
Krankenhauszahlen aus 2001:
•
stationäre Krankenhaus-Fallzahl: 16.583.906 (ohne Stundenfälle innerhalb eines Tages);
•
die Zahl der Aufnahmen: 17.319.492,
•
die Anzahl teilstationär entlassener Patienten: 338.051 (Quelle: StBA Fachserie 12, Reihe 1)
© 2004
Seite
92 von 112
2.3.7.2
Berechnungsergebnisse - Erstellung von Vertragsdaten
Die folgenden Informationen werden einmalig von den Krankenkassen bzw. vom Trustcenter
an die eGK-Plattform versandt.
Nachricht
Quelle
Anzahl/
Jahr
Vertragsdaten
2.3.7.3
KRK
71.000.000
Anzahl/Sek.
16,0
Länge
Byte
(Netz)
Anzahl
Zugriffe /
Fall
559
1
Bandbreite (kbps)
37,3
Speicherbedarf
29,8 GB
Berechnungsergebnisse – Nutzung von Vertragsdaten
Patientendaten werden bei allen 1,24 Mrd. Besuchen jeweils 2 x gelesen (Anmeldung, Arzt)
inkl. aller Notfälle.
Nachricht
Quelle
Anzahl/
Jahr
Anzahl/
Sek.
Nutzung Vertragsdaten
2.3.7.4
eGK/
Server
1.240.000000
559,2
Länge
Byte
(Netz)
Anzahl
Zugriffe /
Fall
559
2
Bandbreite (kbps)
Speicherbedarf
1.302,8
-
Berechnungsergebnisse – Notfalldaten
Notfalldaten werden bei jedem Notfall 2 x gelesen.
Nachricht
Quelle
Anzahl/
Jahr
Anzahl/
Sek.
Notfalldaten
2.3.7.5
eGK
11.343.405
5,4
Länge
Byte
(Netz)
1.020
Anzahl
Zugriffe /
Fall
2
Bandbreite (kbps)
54,95
Speicherbedarf
10,75 GB
Berechnungsergebnisse – e-Rezept
e-Rezepte werden vom Arzt auf die eGK geschrieben, parallel im Datacenter gespeichert
und können vom Apotheker bearbeitet werden. Der Apotheker prüft u.U. ob der Zuzahlungsstatus korrekt ist. Nach erfolgter Medikamentenausgabe werden deren Positionen in die Arzneimitteldokumentation übertragen.
Nachricht
Quelle
Anzahl/
Jahr
Anzahl/
Sek.
e-Rezept schreiben
(Selbstmedikation)
Apoth.
e-Rezept erstellen
Länge
Byte
(Netz)
Anzahl
Zugriffe /
Fall
Bandbreite (kbps)
Speicherbedarf
205.900.00
46,4
1.482
1
687,95
266,84 GB
Arzt
890.000
200,7
1.482
1
2.973,7
1,153 TB
e-Rezept
lesen,
update, löschen
Apoth.
890.000
200,7
1.482
3
8.921,0
-
Zuzahlungsstatus
prüfen
Apoth.
890.000
200,7
559
1
1.120,8
-
13.703,5
-
Summe
849,1
© 2004
Seite
93 von 112
2.3.7.6
Berechnungsergebnisse –Arzneimitteldokumentation
Alle eingelösten e-Rezepte werden in der Arzneimitteldokumentation (AMDoc) für eine Jahr
online zur Verfügung gestellt - Langzeitmedikationen auch länger. Alle anderen älteren Daten werden auf Langzeitspeichern verwaltet. Sie werden hier nicht weiter betrachtet.
Nachricht
Quelle
Anzahl/
Jahr
Anzahl/
Länge
Byte
(Netz)
Sek.
Anzahl
Zugriffe /
Fall
Bandbreite (kbps)
Speicherbedarf
AMDoc schreiben
1.278.000.00
0
288,1
1.218
1
3.509,9
1,38 TB
AMDoc lesen
1.278.000.00
0
288,1
1.218
2
7.019,8
-
10.529,7
-
Summe
2.3.7.7
864,4
Berechnungsergebnisse – e-Überweisung
e-Überweisungen werden Arzt geschrieben und vom aufnehmenden Arzt gelesen. Sie können in den Patientenakte vermerkt sein.
Nachricht
Quelle
Anzahl/
Jahr
Anzahl/
Länge
Byte
(Netz)
Sek.
Anzahl
Zugriffe /
Fall
Bandbreite (kbps)
Speicherbedarf
e-Überweisung
schreiben
Arzt
273.000.000
61,6
954
1
587,4
221,13 GB
e-Überweisung
lesen
Arzt
273.000.000
61,6
954
1
587,4
-
1.117,8
-
Summe
2.3.7.8
123,1
Berechnungsergebnisse – e-Einweisung
e-Einweisungen werden Arzt geschrieben und vom aufnehmenden Krankenhausarzt gelesen. Sie können in den Patientenakte vermerkt sein.
Nachricht
Quelle
Anzahl/
Jahr
Anzahl/
Länge
Byte
(Netz)
Sek.
Anzahl
Zugriffe /
Fall
Bandbreite (kbps)
e-Einweisung
schreiben
Arzt
16.583.906
3,7
954
1
35,68
e-Einweisung
KR
16.583.906
3,7
954
1
35,68
KR
16.583.906
37
559
10
208,85
Speicherbedarf
13,44 GB
lesen
Patientendaten
lesen
Summe
44,9
© 2004
280,21
Seite
94 von 112
2.3.7.9
Berechnungsergebnisse – e-Arztbrief Krankenhaus / Facharzt
e-Arztbriefe werden von Krankenhausärzten und Fachärzten geschrieben (inkl. H- und DÄrzten. Sie können Teil der Patientenakte sein. Sie enthalten keine Bildinformationen (Röntgen, CTG o.ä.).
Nachricht
Quelle
Anzahl/
Jahr
Anzahl/
Sek.
Länge
Byte
(Netz)
Anzahl
Zugriffe /
Fall
Bandbreite (kbps)
Speicherbedarf
e-KR-Arztbrief
schreiben
KR
77.280.000
17,4
38.416
1
6.693,7
e-KR-Arztbrief
lesen
KR
77.280.000
17,4
38.416
2
13.387,3
D- und H-Arztbrief
schreiben
KR
845.000
0,2
38.416
1
73.190
0,031TB
Zwischensumme
KR
20.154,2
2,813 TB
Facharztbrief
schreiben
AR
273.000.000
9,828 TB
Facharztbrief lesen
AR
273.000.000
Zwischensumme
AR
2.3.7.10
52,5
61,6
38.416
1
23.646,12
61,6
38.416
2
47.292,23
184,7
2,782 TB
70.938,35
Berechnungsergebnisse – e-Patientenakte
e-Patientenakte wird vom Arzt gepflegt. Sie enthält die Beschreibung der Patientenbeschwerden, Medikationen, Befunde sowie Hinweise auf Arztbriefe, Über- und Einweisungen.
Die hier vorgelegte Patientenakte enthält keine Bildinformationen (Röntgen, CTG o.ä.). Sie
würden die Patientenakte um eine vielfaches bezüglich ihres Speicherbedarfs erhöhen. Ob
es eine sinnvolle Lösung zur Vermeidung von Doppelspeicherung der Daten über den Entstehungsort hinaus gibt, muss in der Zukunft entschieden werden.
Nachricht
Quelle
Anzahl/
Jahr
Anzahl/
Sek.
Länge
Byte
(Netz)
Anzahl
Zugriffe /
Fall
Bandbreite (kbps)
e-Patientenakte
schreiben
AR
1.240.000.00
0
279,6
3.263
1
9.121,73
e-Patientenakte
lesen
AR
1.174.663.40
5
264,9
3.263
1
8.648,11
e-Patientenakte
lesen
KR
65.336.595
14,7
3.263
1
480,06
Summe
2.3.7.11
559,2
Speicherbedarf
3,72 TB
18.243,46
Berechnungsergebnisse – e-Patientenfach
In das e-Patientenfach kann der Patient freiwillige Daten legen und sie nur gegen Eingabe
seiner PIN Nummer anzeigen lassen. Die Daten sind damit auch vor dem Zugriff durch den
behandelnden Arzt geschützt (auf der eGK und äquivalent auch im Datacenter). Es wird davon ausgegangen, dass 20% der Patienten von dieser Funktion Gebrauch machen.
© 2004
Seite
95 von 112
Nachricht
Quelle
Anzahl/
Anzahl/
Jahr
Länge
Byte
(Netz)
Sek.
Anzahl
Zugriffe /
Fall
Bandbreite (kbps)
Speicherbedarf
e-Patientenfach
anzeigen
PA
325.656.000
73,6
41.648
1
30.579,86
e-Patientenakte
Einträge indizieren
PA
325.656.000
73,6
295
1
216,41
e-Patientenakte
löschen Indizierung
PA
325.656.000
73,6
295
1
216,41
Summe
2.3.7.12
220,3
58,618 GB
31.012,67
Berechnungsergebnisse – e-Zuzahlungsquittung
Zuzahlungsquittung für eine an einen Leistungserbringer (Praxisgebühr, Medikamentenzuzahlung, Krankenhauszuzahlung usw.) entrichtete Zuzahlung. Die e-Zuzahlungsquittung
werden für ein Jahr online gespeichert.
Nachricht
Quelle
Anzahl/
Anzahl/
Jahr
Länge
Byte
(Netz)
Sek.
Anzahl
Zugriffe /
Fall
Bandbreite (kbps)
Speicherbedarf
eZuzahlungsquittung
Praxisgebühr
etc.
schreiben
AR/AP/
NF/KR
125.700.00
0
28,3
888
1
251,8
eZuzahlunsgquittung
AR/AP/
NF/KR
125.700.00
0
28,3
888
1
251,8
95,9 GB
Praxisgebühr lesen
Summe
2.3.7.13
57,6
503,5
Berechnungsergebnisse – e-Patientenquittung
Zusammenfassung aller Leistungen pro Patient und Quartal. Wie diese Informationen zu
handhaben sind, ist in der Rahmenarchitektur nicht geklärt, da sie erst jeweils nach dem letzten Arztbesuch pro Quartal erstellt werden könnten. Deshalb wurden diese Daten vorerst
nicht berücksichtigt.
Nachricht
Quelle
Anzahl/
Anzahl/
Jahr
Länge
Byte
(Netz)
Sek.
Anzahl
Zugriffe /
Fall
Bandbreite (kbps)
Speicherbedarf
ePatientenquittungen
schreiben
AR
-
-
-
-
-
-
e-Patientenquittung
AR
-
-
-
-
-
-
-
-
-
-
-
-
lesen
Summe
© 2004
Seite
96 von 112
2.3.7.14
Berechnungsergebnisse – eGK austauschen
Bei Kassenwechsel oder Verlust wird eine neue eGK ausgestellt. Es wird von 5% solcher
Fälle pro Jahr ausgegangen.
Nachricht
Quelle
Anzahl/
Jahr
Anzahl/
Länge
Byte
(Netz)
Sek.
Datenabgleich
2.3.7.15
AR
7.100.000
1,6
Anzahl
Zugriffe /
Fall
8077
Bandbreite (kbps)
1
129,3
Speicherbedarf
53,3 GB
Berechnungsergebnisse – Summation
Die Summation aller zuvor genannter Teilergebnisse führt zu folgendem Gesamtergebnis für
ein Datacenter. Werden mehrere Datacenter aufgebaut, so sind die Ergebnisse entsprechend der Anzahl der dort vertretenen Versicherten, sowie der niedergelassenen Ärzte, Apotheken und Krankenhäuser zu verifizieren. Die Einzelberechnungen werden in Form eines
Excel-Charts zur Verfügung gestellt.
Nachricht
Anzahl /
Sek.
Bandbreite (Mbps)
Speicherbedarf
(TB)
3.488
153,215
17,46
4.186
183,858
20,95
Transaktion netto
Transaktion
20%
mit
Sicherheitsaufschlag
© 2004
Seite
97 von 112
3
Netze und IT Infrastruktur – Berechungen
3.1 Serverkomponenten
3.1.1
Herleitung der Maschinenkonfigurationen der IT-Infrastruktur
Die genannten IBM Maschinentypen sind exemplarisch zu betrachten. Sie können auch
durch Komponenten anderer Hersteller mit gleicher Leistung ersetzt werden.
Aus der Anzahl von 234.000 Benutzern ergeben sich 1.881 „gleichzeitige Benutzer“. Bei einer fiktiven mittleren Last (nicht eGK spezifisch) ergibt sich:
Rechnertyp
Modell
Anzahl
Knoten
Tier
1
pSeries(RS/6000)
p630 6C4
Relative
Festplatten-
Perf. /
Knoten*9
Zugriffszeiten
(ms)
Anzahl
Prozessor
Auslastung
Platten
1
2,5
13.0
4
27 %
1
4,41
13.0
4
75 %
1
2,5
13.0
16
35 %
Antwortzeit
pro Seite
2,81 s
1-way
1200 MHz
Tier
2
pSeries(RS/6000)
P630 6E4
2-way
1450 MHz
Tier
3
pSeries(RS/6000)
p630 6E4
1-way
1200 MHz
Bei 300.000 Benutzern ergeben sich 2.412 gleichzeitige Benutzer und eine fiktive mittlere
Last von:
Rechnertyp
Modell
Anzahl
Knoten
Tier
1
pSeries(RS/6000)
p630 6C4
Relative
Perf.
Knoten*
/
Festplatten-
Anzahl
Zugriffszeiten (ms)
Platten
Prozessor
Antwortzeit
Auslastung
pro Seite
1
2,5
13.0
4
33 %
1
5,13
13.0
4
80 %
13.0
16
1,92 s
1-way
1200 MHz
Tier
2
pSeries(RS/6000)
p630-6E4
2-way
1200 MHz
Tier
3
pSeries(RS/6000)
p630 6E4
1
2,94
42 %
1-way
1450 MHz
9
Die relative Performance von 1 entspricht einem Rechner pSeries 640 B80, 1 Prozessor P3-II, 375MHz, 32MB L1 Cache,
8MB L2 Cache
© 2004
Seite
98 von 112
Bei 400.000 Benutzern ergeben sich 3.216 gleichzeitige Benutzer und eine fiktive mittlere
Last von:
Rechnertyp
Modell
Tier
1
pSeries(RS/6000)
p630 6C4 1-way
1200 MHz
Tier
2
pSeries(RS/6000)
p630 6C4 2-way
Tier
3
pSeries(RS/6000)
p630 6E4 1-way
Anzahl
Relative
Knoten
Perf.
Knoten*
1
Festplatten/
Zugriffszeiten
(ms)
2,5
5,13
2,94
1
Platten
13.0
1
1200 MHz
Anzahl
4
13.0
4
13.0
4
Prozessor
Antwortzeit
Auslastung
pro Seite
45 %
2,12 s
85 %
55 %
1450 MHz
Wenn nur die Bearbeitung von 559 Vertragsdaten Daten pro Sekunde betrachtet wird, ergibt
sich bei 234.000 Benutzern und einer vertikalen strukturierten Lösung (wenige, aber große
Maschinen) folgendes Bild:
Rechnertyp
Tier
1
pSeries(RS/6000)
Tier
2
pSeries(RS/6000)
Tier
3
pSeries(RS/6000)
Modell
p650 6-way
Anzahl
Relative
Knoten
Perf.
Knoten*
Festplatten/
Zugriffszeiten
(ms)
Anzahl
Prozessor
Platten
Auslastung
2
11,77
13.0
4
90 %
2
52,45
13.0
4
87 %
13.0
16
Antwortzeit
pro Seite
3s
1200 MHz
P690 16-way
turbo
1700 MHz
P655 8-way
1
21,87
90 %
1700 MHz
© 2004
Seite
99 von 112
Bei horizontaler Skalierung ergibt sich folgendes Bild:
Rechnertyp
Tier
1
Tier
2
Tier
3
Modell
pSeries(RS/6000)
p630 6E4 1-way
1200 MHz
pSeries(RS/6000)
p650 6-way
pSeries(RS/6000)
P655 8-way
1200 MHz
Anzahl
Relative
Knoten
Perf.
Knoten*
9
Festplatten/
Zugriffszeiten
(ms)
2,5
11,77
10
21,87
1
Anzahl
Prozessor
Platten
13.0
4
13.0
4
13.0
16
Auslastung
90 %
Antwortzeit
pro Seite
2,87 s
90 %
91 %
1500 MHz
Bezieht man neben der Bearbeitung der Vertragsdaten (559 Transaktionen/s) auch die Abwicklung von e-Rezepten (849 Transaktionen/s) mit ein, so ergibt sich folgendes Bild:
Rechnertyp
Modell
Anzahl
Relative
Knoten
Perf.
Knoten*
Tier
1
pSeries(RS/6000)
p630 6E4 1-way
1200 MHz
24
Tier
2
pSeries(RS/6000)
P650 2-way
58
Tier
3
pSeries(RS/6000)
P670 16-way
Festplatten/
Zugriffszeiten
(ms)
2,5
4,47
Anzahl
Platten
13.0
12
13.0
12
13.0
24
Prozessor
Auslastung
100 %
Antwortzeit
pro Seite
2,97 s
100 %
1450 MHz
1
46,79
94 %
1500 MHz
© 2004
Seite
100 von 112
Bezieht man Vertragsdaten, e-Rezepte und AMDoc (864 Transaktionen/s) mit ein, ergibt sich
folgendes Bild:
Rechnertyp
Modell
Anzahl
Relative
Knoten
Perf.
Knoten*
Tier
1
pSeries(RS/6000)
p630 6C4 2-way
1450 MHz
20
Tier
2
pSeries(RS/6000)
p650 6-way
41
Tier
3
pSeries(RS/6000)
Festplatten/
Zugriffszeiten
(ms)
4,41
11,77
Anzahl
Platten
13.0
28
13.0
28
13.0
40
Prozessor
Auslastung
97 %
Antwortzeit
pro Seite
2,91 s
< 98 %
1200 MHz
P690 24-way
72,86
1
turbo 1700 MHz
98 %
Bezieht man Vertragsdaten, e-Rezepte, AMDoc und Ein- und Überweisungen (44,1 Transaktionen/s und 123,1 Transaktionen /s) mit ein, ergibt sich folgendes Bild:
Rechnertyp
Tier
1
pSeries(RS/6000)
Tier
2
pSeries(RS/6000)
Tier
3
pSeries(RS/6000)
Modell
P630 4-way
Anzahl
Relative
Knoten
Perf.
Knoten*
13
Festplatten/
8,05
Zugriffszeiten
(ms)
Anzahl
Platten
13.0
30
13.0
30
13.0
42
Prozessor
Auslastung
< 96 %
Antwortzeit
pro Seite
3,0 s
1200 MHz
P630-6C4
2way 1450 MHz
P690 32-way
79
1
6,07
81,95
< 96 %
94 %
1500 MHz
© 2004
Seite
101 von 112
Bezieht man Vertragsdaten, e-Rezepte, AMDoc, Ein- und Überweisungen auch die Arztbriefe (237 Transaktionen/s) mit ein ergibt sich folgendes Bild:
Rechnertyp
Tier
1
pSeries(RS/6000)
Modell
P630-6C4
way
Anzahl
Relative
Knoten
Perf.
Knoten*
2-
Festplatten/
Zugriffszeiten
(ms)
6,07
17
Anzahl
Platten
13.0
34
13.0
34
13.0
46
Prozessor
Auslastung
91 %
Antwortzeit
pro Seite
2,9 s
1450 MHz
Tier
2
pSeries(RS/6000)
P670 8-way
Tier
3
pSeries(RS/6000)
P690 32-way
3.1.2
24,18
20
93 %
1500 MHz
92,19
1
85 %
turbo 1700 MHz
Endausbaustufe IT-Konfiguration
Für die Endausbaustufe ergeben sich zwei Prozessorkomplexe, in denen sich die Applikation
unterbringen lässt. Die genannten Zahlen beziehen sich auf eine einfache Auslegung. Um
Absicherung herzustellen ist eine doppelten Auslegung pro Komplex erforderlich.
Außerdem besteht diese doppelte Auslegung auch im Rückfall-Datacenter.
1. Rechnerkomplex
Werden alle Transaktionen bezüglich Vertragsdaten (559 Transaktionen/s), e-Rezepte (849
Transaktionen/s), AMDoc (864 Transaktionen/s), Ein- und Überweisungen (44 Transaktionen/s 123 Transaktionen/s), die Arztbriefe (237 Transaktionen/s) und PatientenfachTransaktionen (220 Transaktionen/s) mit einbezogen, ergibt sich für den ersten der beiden
Prozessorkomplexe folgendes Bild:
Tabelle 114: 1. Rechnerkomplex – einfache Auslegung für ein Datacenter
Rechnertyp
Tier
1
pSeries(RS/6000)
Modell
p630 6E4
Anzahl
Relative
Knoten
Perf.
Knoten*
28
Festplatten/
4,00
2-way
Zugriffszeiten
(ms)
Anzahl
Platten
112,3
38
633,68
38
92,19
50
Prozessor
Auslastung
86 %
Antwortzeit
pro Seite
2,99s
1200 MHz
Tier
2
Tier
3
pSeries(RS/6000)
p630 4-way
8,05
89
86 %
1200 MHz
pSeries(RS/6000)
P690
1
92,19
85 %
32-way turbo
1700 MHz
© 2004
Seite
102 von 112
2. Rechnerkomplex
Alle weiteren erforderlichen Funktionen müssen in einem weiteren Prozessorkomplex zusammengefasst werden. Dabei handelt es sich um die Patientenakte (559 Transaktionen/s),
Zuzahlungs- und Patientenquittungen (58 Transaktionen/s, ? Transaktionen/s ), sowie Notfälle (5,4 Transaktionen/s) und den Austausch von eGK (1,6 Transaktionen/s).
Tabelle 115: 2. Rechnerkomplex – einfache Auslegung für ein Datacenter
Rechnertyp
Tier
1
pSeries(RS/6000)
Tier
2
pSeries(RS/6000)
Tier
3
pSeries(RS/6000)
Modell
P630 4-way
Anzahl
Relative
Knoten
Perf.
Knoten*
3
FestplattenZugriffszeiten
/
(ms)
8,69
Anzahl
Prozessor
Auslastung
Platten
24,69
4
104,90
4
21,91
16
Antwortzeit
pro Seite
95 %
2,3
1450 MHz
P690 16-way
turbo 1700
MHz
P690 8-way
52,45
2
1
27,1
100 %
80 %
1700 MHz
Die in den beiden zuvor stehenden Tabellen genannte Anzahl Knoten ist pro Datacenter aus
Sicherheitsgründen zu verdoppeln. D.h. für den Prozessorkomplex 1 und 2 ergibt sich:
Tabelle 116: 1. Rechnerkomplex – doppelte Auslegung für ein Datacenter
Rechnertyp
Tier
1
Tier
2
Tier
3
pSeries(RS/6000)
Modell
p630 6E4 2-way
Anzahl
Relative
Knoten
Perf.
Knoten*
56
Festplatten/
Zugriffszeiten
(ms)
Prozessor
Anzahl
Platten
Auslastung
Antwortzeit
pro Seite
/Syst
4,00
224,6
38
1267,38
38
184,38
50
~ 43 %
2,99s
1200 MHz
pSeries(RS/6000)
p630 4-way
pSeries(RS/6000)
P690 32-way
8,05
178
~ 43 %
1200 MHz
92,19
2
~ 42 %
turbo 1700 MHz
Tabelle 117: 2. Rechnerkomplex – doppelte Auslegung für ein Datacenter
Rechnertyp
Tier
1
Tier
2
Tier
pSeries(RS/6000)
pSeries(RS/6000)
pSe-
Modell
P630 4-way
Anzahl
Relative
Knoten
Perf.
Knoten*
6
Festplatten/
8,69
Zugriffszeiten
(ms)
Prozessor
Anzahl
Platten
Auslastung
Antwortzeit
pro Seite
/Syst.
49,38
8
209,80
8
43,82
32
~ 46 %
2,3s
1450 MHz
P690 16-way
turbo 1700 MHz
4
P690 8-way
2
© 2004
52,45
27,10
~ 50 %
~ 40 %
Seite
103 von 112
3
ries(RS/6000)
1700 MHz
Müssen nur die Hälfte der Transaktionen abgewickelt werden, weil es zum Einsatz von zwei
Datacenter-Knoten kommt, können die o.g. Anzahlen in Bezug auf die Anzahl Prozessoren
oder die Anzahl der Prozessor-Knoten in etwa halbiert, beim Einsatz von drei DatacenterKnoten in etwa gedrittelt werden (+15% mehr relative Performance Pro Knoten).
3.1.3
Maschinenkonfigurationen Produktions- und Rückfall-Datacenter
Folgende Tabelle enthält die Maschinen der Produktionsseite eines Datacenters. Für das
Rückfall-Datacenter ist eine identische Konfiguration erforderlich.
Beispielhaft wurde das Szenario mit IBM p-Series Komponenten konfiguriert.
Tabelle 118: Maschinen für Produktions- und Rückfall-Datacenter
Funktion
Anzahl
Maschinentyp
Proz
.MHz
Anz
Haupt-
Pro
z
speicher
Festplatten
int. /Syst.
Load Balancer 0 (Prod. +Rückfall)
4
p650
12
00
6
8 GB
4
Load Balancer 1
4
p630-6C4
12
00
1
2 GB
4
Load Balance 2
4
p630-6C4
12
00
1
2 GB
4
56
p630 6E4
12
00
2
8 GB
38
178
p630-6E4
12
00
4
8 GB
38
2
p690
17
00t
32
256
50
6
p630-6C4
14
50
4
8 GB
4
Rechnerkomplex 1
Web-Server / Message Broker 1
Web-App. Server e-Rezept 1
Web-App. Server e-AMDoc 1
Web-App.Server e-Über-, e-Einweisung 1
Web-App.Server e-Über-, e-Einweisung 2
Web-App.Server e-Arztbrief 1
Datenbank-Server e-Rezept 1
Datenbank-Server e-AMDoc 1
Datenbank-Server e-Über- e-Einweisung
1
2
Datenbank-Server e-Arztbrief 1
Rechnerkomplex 2
© 2004
Seite
104 von 112
4
p690
17
00t
16
8GB
4
2
p690
17
00
8
256
GB
16
LDAP Server 1
2
p670
15
00
8
128
GB
16
LDAP Server 2
2
p670
15
00
8
128
GB
16
Mail-Server 1
2
p670
15
00
8
64 GB
8
Mail-Server 2
2
p670
15
00
8
64 GB
8
Systemsmanagement
2
p670
15
00
4
8 GB
8
Asset Management
1
p630
12
00
1
1 GB
4
Web-App.Server e-Patientenakte 1
Web-App.Server Patientenfach 1
Web-App Server Notfälle
Datenbank Server e-Patientenakte 1
Allgemeine Funktionen
Externe Plattenspeicher (1 Jahr)
Platten
Langzeitspeicher (10Jahre)
Langzeit(TB)
(TB )
Datenspeicher Vertragsdaten
1
0,075
0,75
Datenspeicher e-Rezept
1
3,500
35,00
Datenspeicher e-AMDoc
1
3,800
38,00
Datenspeicher e-Über, e-Einweisung
1
0,600
6,00
Datenspeicher e-Arztbrief
1
25,70
3
257,03
Datenspeicher e-Patientenakte
1
9,3
93,00
Patientenfach, Zuzahlung, etc.
1
0,6
6,0
1.1.4 Maschinenkonfigurationen Staging Umgebung
Staging Umgebung (Testumgebung) wurde beispielhaft mit IBM p-Series konfiguriert. Sie ist
ebenfalls doppelt auszulegen, um Produktion und Rückfall testen zu können:
Tabelle 119: Maschinen für Staging Environment
Funktion
Anzahl
Maschinentyp
Proz.
Anz
Haupt-
MHz
Proz.
speicher
1200
Festplatten
intern / Syst.
Load Balancer 0 (Prod. +Rückfall)
4
p650
6
8 GB
4
Load Balancer 1
2
p630-6C4
1200
1
2 GB
4
Load Balance 2
2
p630-6C4
1200
1
2 GB
4
28
p630 6E4
1200
2
8 GB
38
89
p630-6E4
1200
4
8 GB
38
Rechnerkomplex 1
Web-App.Server e-Über-, e-Einweisung
1
© 2004
Seite
105 von 112
Funktion
Anzahl
Maschinentyp
Proz.
Anz
Haupt-
MHz
Proz.
speicher
Festplatten
intern / Syst.
1
p690
1700t
32
256 GB
16
3
p630-6C4
1450
4
8 GB
4
2
p690
1700t
16
8GB
4
2
p690
1700
8
LDAP Server 1
2
p670
1500
8
128 GB
16
Mail-Server 1
2
p670
1500
8
64 GB
8
Systemsmanagement Rechner
2
p670
1500
4
8 GB
8
Asset Management
1
p630
1200
1
1 GB
1
1
Rechnerkomplex 2
Web-App Server Notfälle 1
16
Allgemeine Funktionen
Festpl. ext.
(TB)
Datenspeicher Vertragsdaten
1
0,038
Datenspeicher e-Rezept
1
0,500
Datenspeicher e-AMDoc
1
0,600
Datenspeicher e-Über, e-Einweisung
1
0,300
Datenspeicher e-Arztbrief
1
12,400
Datenspeicher e-Patientenakte
1
4,6
Patientenfach, Zuzahlung, etc.
1
0,3
Der angegebene Raid5 Festplattenspeicher ist eine erste Abschätzung und bedarf der Verifizierung.
Die endgültige Testumgebung kann mit der Hälfte der Maschinen und des Speichers auskommen, wenn in der Produktionsumgebung und Testumgebung Tests gefahren werden, die
das Verhältnis der beiden Umgebungen zueinander in Relation stellen können, um Aussagen bei Änderungen am Code bereits beim Test in der Testumgebung auf die Produktionsumgebung projizieren zu können.
Die Testumgebung in der Phase 1 wird zuerst die spätere Produktionsumgebung sein. Sie ist
auszubauen und zur Produktionsumgebung umzufunktionieren sobald die endgültige
Testumgebung aufgebaut ist.
3.1.4
Maschinenkonfiguration Entwicklungsumgebung und Testtreiber
Tabelle 120: Maschinen für Entwicklungsumgebung und Testtreiber
Maschinenfunktion
Maschinentyp
Proz.-
Anz.
MHz
12
Intel
Testtreiber Datenbank
2
Testtreiber Webservices
3
Entwicklungsrechner
Anzahl
Proz
Hauptspeicher
Festplatten
> 2GHz
1
2GB
80 GB
Intel
> 2GHz
1
2GB
80 GB
Intel
> 2GHz
1
2GB
80 GB
© 2004
Seite
106 von 112
© 2004
Seite
107 von 112
3.2 Netzkomponenten
Zentrale Netzkomponenten
Die Angaben zu Leistungsdaten und Funktionen (Features) der einzelnen Komponenten sind
den entsprechenden Datenblättern eines Herstellers entnommen und exemplarisch zu betrachten .
Die Funktionalitäten wurden, so weit dieses möglich war, auf getrennte Komponenten verteilt. Interoperabilitätsprobleme auf einzelnen Komponenten, aufgrund der gleichzeitigen
Nutzung verschiedener Features können in diesem Stadium der Planung nicht vollständig
ausgeschlossen werden.
Es hat bei der Zusammenstellung der folgenden Komponenten keine detaillierte Überprüfung
der Architektur durch den Hersteller stattgefunden, deshalb kann sie sich noch in Teilbereichen ändern. Produktspezifische Annahmen für die Konfiguration der Komponenten:
•
•
•
•
•
Die Cisco Catalyst 65XX Switche wurden bis auf den Coreswitch im Anwendungsbereich alle mit Supervisorengine2 ohne Switch Fabric Modul ausgestattet und verfügen
somit über eine Backplanekapazität von 32GB (mit SFM 256GB) . Eine Erweiterung
der Backplanekapazität auf 720GB ist durch den Einsatz der Supervisorengine720
möglich. Es muß allerdings im Detail geprüft werden, ob alle erforderlichen Features
auch auf der Supervisorengine 720 verfügbar sind. Die Coreswitche verfügen auf
Grund der Anforderung über eine Supervisorengine720 und somit über eine hohe
Switchingkapazität.
Die Portkapazitäten für die Serveranschlüsse in den einzelnen Serverbereichen wurden pro Datacenter mit 48 x 10/100/1000 Kupferports kalkuliert. Bei den derzeit verwendeten Cisco 6509 bzw. 6506 Chassis liegt die maximale Ausbaustufe bei ca. 144
Ports pro Bereich und Datacenter.
Der Durchsatz eines Firewallmoduls liegt in unserem Beispiel bei ca. 5Gbps. (Herstellerangabe)
Der Einsatz von AES (Advanced Encryption Standard) als Verschlüsselungsstandard
ist in der Beispielkonfiguration für die zentralen Komponenten noch nicht berücksichtigt, da die VPN Module derzeit nicht über AES Unterstützung verfügen.
Die dezentralen Komponenten unterstützen AES.
Tabelle 121: Hardware Konfiguration für den Internet Zugang zum eGK-Datacenter
Exemplarische Produkte
Beschreibung
CISCO7304-G100
4-slot chassis, NPE-G100, 1 Power Supply
Anzahl
2
S730AHK91-12220S
Cisco 7300 Series IOS ENTERPRISE/FW/IDS SECURED SHELL 3DES
2
7300-PWR-AC
Cisco 7304 AC Power Supply
2
7300-PWR/2-AC
Cisco 7304 Redundant AC Power Supply Option
2
CAB-AC10A-90L-EU
10A AC Pwr Cord, left-angle (Europe) (bundle option)
4
7304-NPE-G100
Cisco 7304 NPE-G100 w/1GB SDRAM, 256MB Flsh, (3)GE/FE/E
2
7304-MEM-G100-1GB
1GB default SDRAM for 7304 NPE-G100
2
7304-I/O-CFM-256M
Cisco 7304 Compact Flash Memory for NPE-G100, 256MB default
2
GLC-SX-MM
GE SFP, LC connector SX transceiver
6
7304-NPE-G100/2
Redundant 7304 NPE-G100 w/1GB SDRAM, 256MB Flsh, (3)GE/FE/E
2
7304-MEM-G100-1GB
1GB default SDRAM for 7304 NPE-G100
2
7304-I/O-CFM-256M
Cisco 7304 Compact Flash Memory for NPE-G100, 256MB default
2
GLC-SX-MM
6
7300-CC-PA
7304 Carrier Card for 7200 Series Port Adapters
4
PA-2FE-TX
2-Port Fast Ethernet 100Base TX Port Adapter
4
© 2004
Seite
108 von 112
Tabelle 122: Konfiguration für VPN Distribution
Beschreibung
WS-C6509
Cat 6509 Chassis, 9slot, 15RU, No Pow Supply, No Fan Tray
Anzahl
2
S6S22AK2H-12113E
Catalyst 6000 SUP2/MSFC2 IOS ENTERPRISE WITH FW/VIP 3DES
2
FR-IOSSLB
Catalyst 6000 Supervisor IOS SLB Feature License
2
WS-X6K-S2-MSFC2
Catalyst 6500 Supervisor Engine-2, 2GE, plus MSFC-2 / PFC-2
2
MEM-C6K-ATA-1-64M
Cat6500 Sup2, ATA Type1 Flash Mem Card, 64MB Option
2
MEM-S2-512MB
Catalyst 6500 512MB DRAM on the Supervisor (SUP2 or SUP720)
2
MEM-MSFC2-512MB
Catalyst 6500 512MB DRAM on the MSFC2 or SUP720 MSFC3
2
WS-X6K-S2-MSFC2
2
MEM-C6K-ATA-1-64M
2
MEM-S2-512MB
2
MEM-MSFC2-512MB
2
WS-X6516-GBIC
Catalyst 6500 16-port GigE Mod: Fabric-Enabled (Req. GBICs)
4
WS-SVC-FWM-1-K9
Firewall blade for Catalyst 6500
4
SC-SVC-FWM-2.2-K9
Firewall Module Software 2.2 for Catalyst 6500
4
WS-X6066-SLB-APC
Catalyst 6000 Content Switching Module
2
SC6K-4.1.1-CSM
CSM 4.1(1) Software Release
WS-G5484
1000BASE-SX Short Wavelength GBIC (Multimode only)
2
68
WS-C6K-9SLOT-FAN2
Catalyst 6509 High Speed Fan Tray
2
WS-CAC-2500W
Catalyst 6000 2500W AC Power Supply
4
CAB-AC-2500W-EU
Power Cord, 250Vac 16A, Europe
4
SF-PIX-PDM-2.1
PIX Device Manager for FW Module for Catalyst 6500
2
SF-PIX-PDM-2.1
2
Tabelle 123: Konfiguration der VPN Konzentratoren
Beschreibung
Anzahl
WS-C6509
S6222AK9-12214SY
Catalyst 6000 S2/M2/P2 IOS ENTERPRISE W/VIP SSH 3DES
12
WS-X6K-S2-MSFC2
12
MEM-S2-512MB
12
MEM-MSFC2-512MB
12
WS-X6516-GBIC
12
WS-SVC-IPSEC-1
IPSec VPN Security Module for 6500 and 7600 series
72
WS-G5486
1000BASE-LX/LH long haul GBIC (singlemode or multimode)
WS-C6K-9SLOT-FAN2
12
WS-CAC-2500W
24
CAB-AC-2500W-EU
24
12
216
Tabelle 124: Switchkomponenten mit Firewall für die Serverdistribution im Anwendungsbereich
Beschreibung
WS-C6509
Anzahl
2
S6S22AK2H-12113E
2
FR-IOSSLB
2
WS-X6K-S2-MSFC2
2
MEM-C6K-ATA-1-64M
2
MEM-S2-512MB
2
MEM-MSFC2-512MB
2
WS-X6K-S2-MSFC2
2
MEM-C6K-ATA-1-64M
2
MEM-S2-512MB
2
© 2004
Seite
109 von 112
Beschreibung
MEM-MSFC2-512MB
Anzahl
WS-X6516-GBIC
2
WS-SVC-FWM-1-K9
4
SC-SVC-FWM-2.2-K9
4
WS-X6548-GE-TX
Catalyst 6500 48-port fabric-enabled 10/100/1000 Module
2
WS-G5484
36
WS-C6K-9SLOT-FAN2
2
WS-CAC-2500W
4
CAB-AC-2500W-EU
4
SF-PIX-PDM-2.1
2
SF-PIX-PDM-2.1
2
2
Tabelle 125: Switchkomponenten Anwendungscorebereich für die Kopplung zu den dahinter liegenden Bereichen
Beschreibung
WS-C6506
Anzahl
2
S733AK9H-12217SX
Cisco CAT6000-SUP720 IOS ENTERPRISE FW W/MPLS/IPV6 W/SSH
2
WS-SUP720
Catalyst 6500 / Cisco 7600 Supervisor 720 Fabric MSFC3 PFC3A
2
MEM-C6K-CPTFL128M
Cat6500 Sup720 Compact Flash Mem 128MB
2
GLC-SX-MM
8
WS-SUP720
Catalyst 6500 / Cisco 7600 Supervisor 720 Fabric MSFC3 PFC3A
2
MEM-C6K-CPTFL128M
Cat6500 Sup720 Compact Flash Mem 128MB
2
WS-X6516-GBIC
2
WS-G5484
WS-C6K-6SLOT-FAN2
High Speed Fan Tray, Spare, for Catalyst 6506
32
2
WS-CAC-2500W
4
CAB-AC-2500W-EU
4
MEM-S2-512MB
2
MEM-MSFC2-512MB
2
MEM-S2-512MB
2
MEM-MSFC2-512MB
2
Tabelle 126: Switch Komponenten zentrale Dienste Managementdienste und Datenbankdienste
Beschreibung
WS-C6506
Anzahl
6
S6S22AK2H-12113E
6
FR-IOSSLB
6
WS-X6K-S2-MSFC2
6
MEM-C6K-ATA-1-64M
6
MEM-S2-512MB
6
MEM-MSFC2-512MB
6
WS-X6516-GBIC
6
WS-SVC-FWM-1-K9
6
SC-SVC-FWM-2.2-K9
6
WS-X6548-GE-TX
Catalyst 6500 48-port fabric-enabled 10/100/1000 Module
6
WS-G5484
WS-C6K-6SLOT-FAN2
High Speed Fan Tray, Spare, for Catalyst 6506
WS-CAC-2500W
12
CAB-AC-2500W-EU
12
SF-PIX-PDM-2.1
6
SF-PIX-PDM-2.1
6
© 2004
108
6
Seite
110 von 112
Tabelle 127: Router Komponente für ISDN oder DSL Anschluß mit ISDN Backup und PKI Support für bis zu ca.
20 Kartenlesegeräte pro Standort
Beschreibung
Anzahl**
CISCO836-SEC-I-K9
Cisco 836 Security Bundle w/ PLUS ISDN bkup
MEM830-12U16F
Cisco 830 series 12MB to 16MB flash upgrade
CAB-800-ISDN
ISDN S/T RJ45 Cable for SOHO/800 series routers
CAB-AC2E
AC Power cord Europe
CAB-ADSL-RJ45
RJ45 ADSL cable
ROUTER-SDM
Device manager for routers
S836CHSK9-12213ZH
Cisco 836 Series IOS IP/FW/PLUS DIAL BACKUP 3DES
MEM830-16D
Cisco 830 Series 16MB SDRAM factory upgrade
**Mengenangaben fehlen, da noch keine Angaben über die Anzahl der Kartenlesegeräte in den einzelnen Arztpraxen und
Apotheke vorliegen
Tabelle 128: Router Komponente für 2Mbps Standleitung mit ISDN Backup (2Mbps) mit PKI Support für mehr als
20 Kartenlesegeräte pro Standort (Beispiel Krankenhaus)
Beschreibung
Anzahl**
C3725-VPN/K9
3725 VPN Bundle,AIM-VPN/EPII,AdvancedIP,64-192Mem
MEM3725-64U128CF
64 to 128MB Compact Flash factory upgrade for Cisco 3700
MEM3725-64CF-EXT
64MB External Compact Flash factory upgrade for Cisco 3725
MEM3725-192U256D
192 to 256MB SODIMM DRAM factory upgrade for Cisco 3725
NM-2W
2 WAN Card Slot Network Module(no LAN)
WIC-2T
2-Port Serial WAN Interface Card
NM-1CE1B
1-Port Channelized E1/ISDN-PRI Balanced Network Module
CAB-ACE
Power Cord Europe
CAB-E1-DB15
E1 Cable DB15 120 ohm/Balanced, 5 Meters
CAB-X21MT
X.21 Cable, DTE, Male, 10 Feet
S372AISK9-12304T
Cisco 3725 Ser IOS ADVANCED IP SERVICES
AIM-VPN/EPII
DES/3DES/AES VPN Encryption and Compression Module EPII
ROUTER-SDM
Device Manager for Routers
**Mengenangaben fehlen, da noch keine Angaben über die Anzahl der Kartenlesegeräte in den Krankenhäusern vorliegen
© 2004
Seite
111 von 112
Literatur
Die in diesem Anhang aufgeführten Literaturverweise kommen aufgrund der Übernahme der
Architekturentscheidungen aus der Rahmenarchitektur [bIT4health] und des Planungsauftrages [Plan04] in dieses Dokument zustande. Es wird daher generell bzgl. der hier aufgeführten Referenzen auf die Literaturverzeichnisse der Rahmenarchitektur, des Planungsauftrages und des Hauptdokuments Solution Outline [SolOut04] verwiesen.
[bIT4health] Projektgruppe bIT4health: Rahmenarchitektur der Telematikplattform im Gesundheitswesen (2004), www.dimdi.de/de/ehealth/karte/bit4health/ergebnisse
[Plan04]
Planungsauftrag eRezept, eArztbrief, ePatientenakte und Telematikinfrastruk-tur
(März 2004),
http://www.pkv.de/telematik/Projektdokument%20Planungsauftrag%20final.pdf
[SolOut04] Projektgruppe bIT4health: Solution Outline - Skizzierung der Lösungsarchitektur und Planung der Umsetzung (2004)
© 2004
Seite
112 von 112

Anhang

Transcription

Similar documents

Kraftfahrt-Bundesamt Jahresbericht 2004

VDV-Kernapplikation - Verkehrsunternehmen

PDF erstellen - Guidelines.ch

Architektur-Frameworks 1 Architektur

Schulungshandbuch digital tacho

Download: * 141,57kB