Erarbeitung einer Strategie zur Einführung der Gesundheitskarte Solution Outline - Skizzierung der Lösungsarchitektur und Planung der Umsetzung

Größe: px
Ab Seite anzeigen:

Download "Erarbeitung einer Strategie zur Einführung der Gesundheitskarte Solution Outline - Skizzierung der Lösungsarchitektur und Planung der Umsetzung"

Transkript

1 Erarbeitung einer Strategie zur Einführung der Gesundheitskarte 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 Projektgruppe bit4health Seite 1 von 127

2 Mache die Dinge so einfach wie möglich, aber nicht einfacher. Albert Einstein Projektmitarbeiter und Experten aus Industrie und Selbstverwaltung Die Einbeziehung eines arbeitsfähigen Kreises von Experten aus der Industrie und der Selbstverwaltung war entscheidend, um eine technisch und organisatorisch umsetzbare und akzeptierte Lösung zu planen. Die eingeladenen Experten aus der Industrie und der Selbstverwaltung haben mit ihrer Expertise wesentlich an den erzielten Ergebnissen mitgewirkt. Das bit4health-konsortium möchte sich hiermit bei allen Beteiligten für deren intensive und konstruktive Mitarbeit und den eingebrachten Ideen bedanken Projektgruppe bit4health Seite 2 von 127

3 Inhaltsverzeichnis Zusammenfassung 11 1 Einleitung 15 2 Skizzierung der Lösungsarchitektur Dezentrale Komponenten Skizzierung des bit4health Connectors Architekturentscheidungen Zentrale Komponenten Skizzierung der bit4health Plattformdienste Skizzierung der bit4health Anwendungsdienste Architekturentscheidungen Sicherheitskomponenten Skizzierung der zentralen und dezentralen Sicherheitsdienste PKI im Gesundheitswesen Architekturentscheidungen Kartenproduktion, -personalisierung und -ausgabe Skizzierung der Kartenpersonalisierung und Ausgabe Architekturentscheidungen Netze und IT Infrastruktur Skizzierung der IT Infrastruktur Betrachtete Architekturoptionen 77 3 Abdeckung der Anforderungen durch Produkte und existierende Lösungen Dezentrale Komponenten Management von Anwendungskomponenten und Diensten im bit4health Connector Schnittstellen zur Primärsystemapplikation und zur Plattform Schnittstelle zum Kartenterminal Transformation Service Zentrale Komponenten Sicherheitskomponenten Kartenproduktion, -personalisierung und -management Kartenproduktion Kartenpersonalisierung und Kartenausgabe Kartenapplikationsverwaltung (CAMS) Netze und IT-Infrastruktur Schematische Darstellung der IT-Infrastruktur Projektgruppe bit4health Seite 3 von 127

4 3.5.2 Zentrale Services Management Services Zentrale Netzkomponenten Dezentrale Netzkomponenten Verteilung der Architektur auf mehrere regionale Datacenter Releaseplanung Teststrategie Risikoplanung Dezentrale Komponenten Meilensteine und Projektrisiken Offene Punkte Zentrale Komponenten Meilensteine und Projektrisiken Offene Punkte Sicherheitskomponenten Meilensteine und Projektrisiken Offene Punkte Kartenproduktion, -personalisierung und ausgabe Meilensteine und Projektrisiken Offene Punkte Netze und IT Infrastruktur Meilensteine und Projektrisiken Offene Punkte 125 Literatur Projektgruppe bit4health Seite 4 von 127

5 Abbildungsverzeichnis Abbildung 1: Aufeinanderfolgende Schritte zur Einführung der elektronischen Gesundheitskarte, des elektronischen Rezeptes, der elektronischen Patientenakte sowie der dazu notwendigen Informations-, Kommunikations- und Sicherheitsinfrastruktur 11 Abbildung 2: Projektorganisation für die Erstellung des Solution Outlines 16 Abbildung 3: Externe Dienstschnittstellung und Komponenten der Telematikplattform im Engineering View von RM-ODP. 18 Abbildung 4: Überblick über die Dienste und Dienstschnittstellen der einzelnen Komponenten der Telematikplattform. 20 Abbildung 5: Netzverbindungen und Kommunikation zwischen den Komponenten der Telematikplattform. 21 Abbildung 6: Komponenten und Schnittstellen des bit4health Connectors 27 Abbildung 7: bit4health Connector im mobilen Kartenterminal 28 Abbildung 8: bit4health Connector im mobilen PSA-PC 29 Abbildung 9: bit4health Connector als Access Point in Thick Client Umgebungen 30 Abbildung 10: bit4health Connector als Access Point in Thin Client Umgebungen 31 Abbildung 11: Zentrale Komponenten und Schnittstellen 37 Abbildung 12: Einordnung der Sicherheitskomponenten in die Lösungsarchitektur. Sicherheitsrelevante Komponente sind schraffiert dargestellt. 42 Abbildung 13: Zentrale und dezentrale Sicherheitsdienste 45 Abbildung 14: Komponenten zur Erstellung und Überprüfung einer qualifizierten Signatur nach SigG47 Abbildung 15: Drei logisch getrennte PK-Strukturen im Gesundheitswesen 52 Abbildung 16: Flache Hierachie mit organisationsspezifischen CAs (mit optionaler Bridge CA) 53 Abbildung 17: Organisationsübergreifende zentrale CAs (mit optionaler Bridge CA) 53 Abbildung 18: Funktionale Struktur (logische Blöcke) zur egk-ausgabe 63 Abbildung 19: Schnittstellen der Telematikplattform zu Herausgebern der egk 64 Abbildung 20: Funktionale Struktur (logische Blöcke) zur Ausgabe von HBA und SMC 65 Abbildung 21: Schnittstellen der Telematikplattform zu Herausgebern der HBA und SMC 65 Abbildung 22: Schematische Darstellung des b4h Netzes und der Infrastruktur für ein Datacenter 70 Abbildung 23: b4h Netze und Infrastruktur mit Backbone für einen Datacenter-Knoten 71 Abbildung 24: Verbindungen zwischen mehreren Datacentern-Knoten 71 Abbildung 25: Lösungsansatz mit zwei Datacenter-Knoten (beispielhaft) 72 Abbildung 26: IT Infrastuktur Management Service Ebenen 76 Abbildung 27: Übersicht OSGi Container 79 Abbildung 28: Open Card Framework Architektur [OCF, S. 11] 80 Abbildung 29: Konfiguration von Kartenterminals [OCF, S.13] 81 Abbildung 30: Drei Tier Architektur 89 Abbildung 31: Lastverteilung zwischen Datacenter und Rückfall-Datacenter 89 Abbildung 32: Lastverteilung zu den Applikationsservern Projektgruppe bit4health Seite 5 von 127

6 Abbildung 33: Überblick Netzwerkkonfiguration Internetzugang, DMZ und Bereich Anwendungsdienste95 Abbildung 34: Überblick Netzwerkkonfiguration Corebereich Anwendungsdienste und Kopplung zu den dahinterliegenden Bereichen 96 Abbildung 35: Überblick Netzwerkkonfiguration Anbindung der Krankenkassen und Kammern über MPLS VPN oder Standleitung an das egk Datacenter 99 Abbildung 36: Verteilung der Architektur auf mehrere Datacenter 101 Abbildung 37: Meilensteine für die bit4health Zulassungsstelle. 102 Abbildung 38: Entwicklungs- Freigabe- und Produktionsumgebung. 104 Abbildung 39: Wichtige Meilensteine der dezentralen Komponenten 107 Abbildung 40: Meilensteine zentrale Komponenten 111 Abbildung 41: Wichtige Meilensteine zum Aufbau der Sicherheitsinfrastruktur PKI für Karte-zu-Karte Authentifizierung 114 Abbildung 42: Wichtige Meilensteine zum Aufbau der Sicherheitsinfrastruktur X.509 PKI und Sicherheitsdienste 115 Abbildung 43: Wichtige Meilensteine für die frühzeitige Lieferbarkeit von egk und HBA/SMC 120 Abbildung 44: Wichtige Meilensteine zum Aufbau der Netze und Infrastruktur 124 Tabellenverzeichnis Tabelle 1: Projektmitarbeiter und Experten aus Industrie und SelbstverwaltungError! Bookmark not defined. Tabelle 2: Überblick über die Geschäftsvorfälle (high level Use Cases) und externe und interne Dienstschnittstellen der Telematikinfrastruktur 22 Tabelle 3: Wesentliche Architekturentscheidungen für die Skizzierung der Lösungsarchitektur 25 Tabelle 4: Überblick Architekturentscheidungen dezentrale Komponenten 36 Tabelle 5: Überblick Architekturentscheidungen zentrale Komponenten 41 Tabelle 6: Schnittstellen und Transportprotokolle des Security Servers 45 Tabelle 7: Anwendungsbereiche der egk mit PK-Technologien 51 Tabelle 8: Überblick Architekturentscheidungen Sicherheitskomponenten 57 Tabelle 9: Überblick übergreifende Architekturentscheidungen zu Herstellung, Personalisierung und Ausgabe 66 Tabelle 10: b4h-datacenter Bandbreiten und Speicherkapazitäten 73 Tabelle 11: 1. Rechnerkomplex bei doppelter Auslegung aller Komponenten in einem Datacenter 74 Tabelle 12: 2. Rechnerkomplex bei doppelter Auslegung aller Komponenten in einem Datacenter 75 Tabelle 13: Überblick Architekturentscheidungen Netze 77 Tabelle 14: Überblick Architekturentscheidungen Infrastruktur 77 Tabelle 15: Überblick Architekturentscheidungen Management InfrastrukturError! Bookmark not defined. Tabelle 16: Web Services - Auswahl an Spezifikationen und Produkten 82 Tabelle 17: Lösungsüberblick Sicherheitskomponenten 84 Tabelle 18: IT-Infrastruktur Management Anforderungen 93 Tabelle 19: Beschreibung der Aktivitäten 106 Tabelle 20: Annahmen und vermiedene Risiken zu den Meilensteinen 108 Tabelle 21: Offene Punkte Dezentrale Komponenten Projektgruppe bit4health Seite 6 von 127

7 Tabelle 22: Meilensteine zentrale Komponenten 110 Tabelle 23: Annahmen und Risiken zu den Meilensteinen Zentrale Komponenten 111 Tabelle 24: Offene Punkte Zentrale Komponenten 112 Tabelle 25: Aktivitäten 113 Tabelle 26: Annahmen, vermiedene und verbleibende Risikien zu den Meilensteinen 114 Tabelle 27: Annahmen, vermiedene und verbleibende Risikien zu den Meilensteinen 116 Tabelle 28: Offene Punkte Sicherheitskomponenten 118 Tabelle 29: Erforderliche Aktivitäten 119 Tabelle 30: Annahmen und vermiedene Risiken zu den Meilensteinen 120 Tabelle 31: Offene Punkte Kartenproduktion, -personalsierung und ausgabe 122 Tabelle 32: Annahmen und vermiedene Risikien zu den Meilensteinen 124 Tabelle 33: Offene Punkte Nezte und IT-Infrastruktur Projektgruppe bit4health Seite 7 von 127

8 Abkürzungsverzeichnis AE-LDn AE-LK AE-Ln AE-LSn AE-LNIn AE-LZn API ASP b4h b4hc b4h int b4h PSA-API b4h Kassen-API b4h Kammer-API b4h PL-API b4h KT-API b4h APP-API b4h EXT-API b4h Komponenten AE=Architekturentscheidung; D = Dezentrale Komponenten; n= Nummer der Entscheidung AE=Architekturentscheidung; L = Lösungsarchitektur Kartenproduktion, -personalisierung, -ausgabe; n= Nummer der Entscheidung AE=Architekturentscheidung; L = Lösungsarchitektur 1 ; n= Nummer der Entscheidung AE=Architekturentscheidung; L = Lösungsarchitektur Sicherheitskomponenten; n= Nummer der Entscheidung AE=Architekturentscheidung; L = Lösungsarchitektur Netze und IT Infrastruktur; n= Nummer der Entscheidung AE=Architekturentscheidung; L = Lösungsarchitektur Zentrale Komponenten; n= Nummer der Entscheidung Application Interface (Dienstschnittstelle) Application Service Provider bit4health bit4health Connector bit4health Integrator Externe Dienstschnittstelle der Telematikinfrastruktur zu den Primärsystemen der Leistungserbringer. Externe Dienstschnittstelle der Telematikinfrastruktur zu den vorhandenen IT-Systemen der Kassen. Externe Dienstschnittstelle der Telematikinfrastruktur zu den IT- Systemen und Verzeichnissen von Heilberuflern. interne Schnittstelle der Telematikplattform zwischen den bit4health Connector-Primärsysteme und der b4h Plattform interne Schnittstelle der Telematikplattform zwischen den bit4health Connector-Primärsysteme und der b4h Kartenterminals interne Schnittstelle der Telematikplattform zwischen der b4h Plattform und den b4h Anwendungen. interne Schnittstelle der Telematikplattform zwischen der b4h Plattform und den b4h externen Diensten zum Zugriff auf die Vertrags- und Kartendaten der Versicherten und Heilberufler. Die Grobkomponenten der Telematikinfrastruktur, die Dienste bereitstellen, insbesondere b4h Connector b4h Anwendungen b4h Plattform b4h Integrator-Backend 1 (Wesentliche) Architekturentscheidungen für die Skizzierung der Lösungsarchitektur Projektgruppe bit4health Seite 8 von 127

9 CAMS CMS CRUD CT-API DMP DMZ E ebxml ebms EXT egk epa E-XER FBZ GMG ITU-T ISP LB LE HBA JCE KBps KK KT KTA KVK KV-Nummer MBps MPLS MTA MKT OASIS OCF OID OSGi OS PER PK-Verfahren b4h Zulassungsstelle b4h übergreifende Dienste Card Application Management System Card Management System create, read, update, delete CardTerminal Application Programming Interface Disease Management Program Demilitarized zone Enterprise View Electronic Business using extensible Markup Language ebxml Message Service Externe Dienste Elektronische Gesundheitskarte Elektronische Patientenakte Extended XML Encoding Rules Fehlbedienungszähler GKV-Modernisierungsgesetz International Telecommunication Union Telecommunication Standardization Sector Internet Service Provider Abb. Lastverteilung zu den Applikation-Servern Leistungserbringer Heilberufsausweis Java Cryptography Extension Kilobyte pro Sekunde Krankenkassen Kartenterminal Kartenterminal Ablaufsteuerung Krankenversicherungskarte Krankenversicherungsnummer Megabyte pro Sekunde Multiprotocol Label Switching Mail Transfer Agent Mulitfunktionales Kartenterminal Organization for the Advancement of Structured Information Standards OpenCard Framework Object ID Open Service Gateway initiative Operating System (Abb.6) Packaged Encoding Rules Private-/Public Key-Verfahren 2004 Projektgruppe bit4health Seite 9 von 127

10 PKI PL PSA QoS RA RIM RM-ODP RPC SDK SGB V SigG, SiGV SMC SMP SNMP SOAP TC WSDL WSIL ZDA Public Key Infrastructure (interne Schnittstelle) Primärsystemapplikation Quality of Service Registration Authority Reference Information Model Reference Model of Open Distributed Processing Remote Procedure Call Software Development Kit Fünftes Sozialgesetzbuch Signaturgesetz, Signaturverordnung Secure Module Card symmetrischer Multiprozessor Simple Network Management Protocol Simple Object Access Protocol Trustcenter Web Service Description Language WS Inspection Language Zertifizierungsdienstleister Projektgruppe bit4health Seite 10 von

11 Zusammenfassung Das Gesetz zur Modernisierung der gesetzlichen Krankenversicherung (GKV-Modernisierungsgesetz Modernisierungsgesetz [GMG] schreibt die Einführung einer Telematikinfrastruktur für den Einsatz der elektronischen Gesundheitskarte vor. Die Umsetzung der Telematikinfrastruktur im Gesundheitswesen muss durch eine Reihe von aufeinander aufbauenden Schritten erfolgen. Mit der Fertigstellung und Veröffentlichung der Rahmenarchitektur durch das bit4health Konsortium wurde ein wesentlicher Schritt getan. Aufbauend auf die Rahmenarchitektur ist die Lösungsarchitektur der konsequent folgende Schritt. Diese muss abschließend - vor dem Roll Out bei Versicherten, Leistungserbringern und Kostenträgern - in Testregionen erprobt werden. Diese einzelnen Phasen sind in der folgenden Abbildung verdeutlicht. Die Projektplanung, als Entscheidungsgrundlage für die Spitzenverbände der Selbstverwaltung, ist veröffentlicht.. Rahmenarchitektur als generelles Regelwerk der Bebauungsplan. Nächster Schritt ist der Aufbau der Projektorganisation Lösungsarchitektur, welche die Komponenten und deren Zusammenspiel ausarbeitet und weiter detailliert. und die Erstellung einer interoperablen Lösung. Testregionen, welche konkrete Lösungen schaffen und den Rollout einleiten. Abbildung 1: Aufeinanderfolgende Schritte zur Einführung der elektronischen Gesundheitskarte, des elektronischen Rezeptes, der elektronischen Patientenakte sowie der dazu notwendigen Informations-, Kommunikations- und Sicherheitsinfrastruktur Der Solution Outline beschreibt - ausgehend von der bit4health Rahmenarchitektur [bit4health] sowie des Planungsauftrags erezept der Selbstverwaltung [Plan] - die Komplexität sowie den Umfang der Lösungsarchitektur und stellt damit einen konkretisierten Überblick über Zeitpläne und technische Risiken für die Entwicklung und Umsetzung der Lösungsarchitektur der Gesundheitskarte bereit. Die Einbeziehung eines arbeitsfähigen Kreises von Experten aus der Industrie und der Selbstverwaltung ist entscheidend, um eine technisch und organisatorisch umsetzbare und akzeptierte Lösung zu planen. Aus diesem Grund wurde der Solution Outline nicht allein durch das bit4health Konsortium ausgearbeitet, sondern eine arbeitsfähige Struktur aus Mitgliedern der beteiligten Organisationen etabliert, die in einer Reihe von Arbeitssitzungen die Ergebnisse gemeinsam ausgearbeitet bzw. kommentiert haben Projektgruppe bit4health Seite 11 von

12 Die eingeladenen Experten aus der Industrie und der Selbstverwaltung haben mit ihrer Expertise wesentlich an den erzielten Ergebnissen mitgewirkt. Das bit4health-konsortium möchte sich hiermit bei allen Beteiligten für deren intensive und konstruktive Mitarbeit und den eingebrachten Ideen bedanken. Im Rahmen des vorliegenden Solution Outline konnten folgende, wesentliche Ergebnisse erzielt werden: 1. Die ersten Phasen der Einführung der elektronischen Gesundheitskarte und der damit verbundenen Telematikinfrastruktur bedürfen keiner grundlegend neuen, nicht erprobten Technologien. Durch die getroffenen Architekturentscheidungen und damit gewählten Optionen sind die technischen Komponenten zur Realisierung der Telematikinfrastruktur im Gesundheitswesen in Form von Produkten, Lösungen, Standards und Protokollen im Wesentlichen vorhanden. Die verfügbaren Lösungen müssen jedoch noch modifiziert und dabei an die zu spezifizierenden Schnittstellen der Telematikinfrastruktur angepasst werden. Die ermittelten Transaktionsraten sowie die benötigte Bandbreite und Speicherkapazitäten der Telematikinfrastruktur liegen in einem technisch beherrschbaren Bereich. Die Anforderungen können durch wenige Rechenzentren mit üblicher Ausstattung abgedeckt werden. Die benötigte Bandbreite seitens der Leistungserbringer sind in einem Bereich, der mit ISDN Leitungen abgedeckt werden kann. Breitbandzugänge für Leitungserbringer sind für Phase 1 und 2 noch nicht erforderlich Vordringlich zu spezifizieren und zu implementieren sind die externen Dienstschnittstellen der Telematikplattform zu den existierenden IT Systemen der Leistungserbringer, Kassen und Kammern. Insgesamt wird eine Unterstützung der Feldtests bis Ende 2004 für technisch realisierbar gehalten. Durch die externen Dienstschnittstellen wird in 2004 die unabhängige Anpassung der vorhandenen IT Systeme und Anwendungen der Leistungserbringer, Kassen und Kammern parallel zu den Tests und Zulassungen der bit4health Komponenten (unter anderem bit4health Connector, Kartenterminals, Kartenproduktion der egk, HBA) ermöglicht. Der bit4health Connector zu den Primärsystemen ist als zeitkritischste technische Komponente im Detail beschrieben und verschiedene technische Realisierungen (Software versus Hardware) sind aufgezeigt. Es bestand Einigkeit bei den beteiligten Experten, dass die Spezifikation dieser Dienstschnittstelle zu den vorhandenen Primärsystemen in einem Zeitraum von 2-3 Monaten konzentrierter, gemeinsamer technischer Arbeiten möglich ist. Die Integration und der Test dieser Schnittstelle in die Primärsysteme erfordert zusätzlich 3 Monate. Die Dienstschnittstellen zu Kassen und Kammern können in dem Zeitrahmen bis Ende 2004 soweit realisiert werden, dass sie für die Unterstützung von Testvorhaben ausreichend verwendet werden können. U.A. sind folgende Punkte bis Ende 2004 realisierbar: Aufbau von Versichertenverzeichnissen im Zusammenhang mit der Vergabe der neuen Krankenversichertennummer. Kartenproduktion von egk ohne eine zusätzliche verteilte Infrastruktur (z.b. bediente Terminals). 2 Phase 1a: Einführung egk, Vertragsdaten, E111 und Lichtbild; Phase 1b: Einführung bit4healh Access Point, erste Integrationsszenarien mit den Primärsystemen, Nachladen von Applikationen; Phase 2: erezept-einführung; Phase 3: Einführung Arzneimitteldokumentation und klinische Basisdaten (Wechselwirkungscheck); Phase 4: Mehrwertapplikationen Projektgruppe bit4health Seite 12 von

13 Spezifikation, Entwicklung und Betrieb einheitlicher, übergreifender Dienste für die Kartenproduktion bzw. das Kartenmanagement der egk (siehe AE-C2 Planungsauftrag erezept). Der Aufbau eines Kartenmanagementsystems bzw. die Auswahl von Dienstleistern innerhalb eines Verbandes bis zu den Feldtests wird von Anbietern als realistisch eingeschätzt. Der Aufbau einer Kartenproduktion für die Heilberufsausweise und die Bereitstellung dieser Schnittstelle wird von Dienstleistern bis zu dem Beginn der Feldtests als realistisch angesehen. Parallel sind die entsprechenden Erfassungsarbeiten für Versicherte aufzusetzen, die z.b. noch über keine KV-Nummer oder keine Bilddaten verfügen. Nachgelagerte Verfahren in den Krankenkassen, die auf die bisherige Krankenversichertennummer abstellen, können später angepasst werden. Ebenso kann die Abstimmung der Registrierungsprozesse für verkammerte Berufsgruppen, sonstige Leistungserbringer sowie den Institutionenkarten parallel bzw. nachgelagert erfolgen. 3. Die minimale Anzahl der normativ festzulegenden internen Dienstschnittstellen zwischen den bit4health-komponenten der Telematikinfrastruktur sind identifiziert und festgelegt worden. Durch die normative Festlegung der bit4health-schnittstellen und die Modularität der bit4health-komponenten wird eine Entkopplung der einzelnen Entwicklungen bei den Leistungserbringern, den Kassen und der Ausgabe der Heilberufsausweise und Institutionenkarten erreicht. Die Spezifikation und Implementierung dieser internen Schnittstellen der Telematikinfrastruktur für die prioritären Anwendungen kann bis zum Beginn der Feldversuche erfolgen. Damit können die Testregionen mit zugelassenen Produkten und Lösungen (siehe b4h Zulassungsstelle) verschiedener Anbieter beginnen und schrittweise die freiwilligen Anwendungen hinzunehmen. Die in bit4health definierten Migrationsstufen für die Einführung der egk können damit unabhängig in den einzelnen Regionen eingeführt werden und die Interoperabilität zwischen verschiedenen Regionen ist durch definierte Testverfahren und jeweils eine Abnahmestelle gegeben. 4. Der Aufbau von Public Key-Infrastrukturen (PKI) im Gesundheitswesen ist besonders dringlich. Der Aufbau einer PKI zur Herausgabe von CV-Zertifikaten (zur Sicherstellung vertrauenswürdiger Kommunikation zwischen HPC/SMC und egk) ist vordringlich und vor dem Aufbau einer PKI zur Herausgabe von X.509-Zertifikaten für Versicherte durchzuführen. Eine gemeinsame PKI zur Herausgabe von CV-Zertifikaten wird bis Ende Q als Voraussetzung für die Produktion der egk benötigt. Es ist eine möglichst flache Zertifizierungshierachie (2 stufig für CV-Zertifikate) im Gesundheitswesen mit einer Bridge-CA für X.509-Zertifikate zur Anbindung auf europäischer Ebene bzw. zu Zertifizierungshierachien außerhalb des Gesundheitswesens vorzusehen. Die Verwendung und Interoperabilität der Karten- und IT Systeme ist nur für Aufgaben im Gesundheitswesen vorzusehen und zu testen. Die technischen Vorgaben und Konvergenzkriterien des Signaturbündnisses bei der technischen Ausgestaltung der Signaturkomponenten sind zu berücksichtigen. HBA/SMC und egk enthalten zum Zeitpunkt der ersten Ausgabe CV-Zertifikate zur Sicherstellung vertrauenswürdiger Kommunikation zwischen HBA/SMC und egk mit einer gemeinsamen Root CA. Die egk enthält zum Zeitpunkt der ersten Ausgabe kein X.509- Schlüsselmaterial zur Authentifizierung, Verschlüsselung oder elektronischen Signatur. Dennoch ist sie mit ihrer ersten Ausgabe technisch geeignet Authentifizierung, Verschlüsselung oder elektronischen Signatur zu ermöglichen. Ein Migrationsweg zur Etablierung einer PKI für die egk ist dargestellt. Insbesondere ist ein nachträgliches optionales Aufbringen von entsprechendem Schlüsselmaterial von ausgegebenen Karten vorzusehen und zu testen Projektgruppe bit4health Seite 13 von

14 5. Die wesentlichen Risiken, die zur Verzögerung der Einführung der elektronischen Gesundheitskarte führen können, sind nicht technischer, sondern organisatorischer Natur. Der Aufbau einer übergeordneten Zulassungsstelle im deutschen Gesundheitswesen ist eine überaus dringliche und wichtige Aufgabe. Diese organisatorische Einheit muss die normative Standards und Regeln für die Telematikinfrastruktur festlegen und prüfen. Ein gemeinsamer Ausschusses aller Beteiligter ist zu schaffen und Arbeitsgruppen zu Einzelthemen sind zu etablieren. Die nachfolgenden Bereiche müssen vordringlich durch arbeitsfähige Arbeitsgruppen festgelegt werden: Kartenstrategie (HBA, Institutionenkarte, egk); Datenschutz & Datensicherheit;; bit4health-anwendungen; Rahmenbedingungen für Betreiber & Betriebskonzepte; Testverfahren und Abnahmen. Die vorliegenden Ergebnisse des Solution Outlines werden für die Planung folgender Vorhaben und Aktivitäten im Rahmen der Einführung der elektronischen Gesundheitskarte und den damit verbundnen prioritäten Anwendungen benötigt: Planung der Aktivitäten zur Erstellung der Spezifikationen der Schnittstellen, der Musterlösung sowie der Durchführung von Interoperabilitätstests. Die effiziente und effektive Erstellung und Umsetzung der Lösungsarchitektur durch die Projektorganisation der Selbstverwaltung. Planung der Testregionen. Die bit4health Projektgruppe und die beteiligten Experten hoffen, mit dem vorliegenden Solution Outline für die Erstellung der Lösungsarchitektur sowie für die Planung der Testregionen eine Diskussionsgrundlage geschaffen zu haben Projektgruppe bit4health Seite 14 von

15 1 Einleitung Das Gesetz zur Modernisierung der gesetzlichen Krankenversicherung (GKV- Modernisierungsgesetz [GMG], das am 17. Oktober 2003 die Zustimmung des Bundesrates gefunden hatte, schreibt die Einführung einer Telematikinfrastruktur für den Einsatz der e- lektronischen Gesundheitskarte vor. Die Einführung der elektronischen Gesundheitskarte, des elektronischen Rezeptes, der elektronischen Patientenakte sowie der dazu notwendigen Informations-, Kommunikations- und Sicherheitsinfrastruktur wird als Schlüsselprojekt für die Modernisierung des gesamten Gesundheitswesens gesehen. Ziel ist es, mit der Einführung der Gesundheitskarte die Wirtschaftlichkeit und Qualität des Gesundheitswesens nachhaltig zu steigern. Die Einführung der Gesundheitskarte und der Telematikinfrastruktur führt zur Verbesserung patienten-orientierter Dienstleistungen und stärkt die Eigenverantwortung, Mitwirkungsbereitschaft und -initiative der Patienten. Der Solution Outline erstellt die konkrete Planung für die Erstellung und Umsetzung der Lösungsarchitektur und beschreibt die Komplexität und den Umfang der Lösung und stellt damit einen Überblick über die Aufwände, Zeitpläne und Risiken für die Einführung der Gesundheitskarte bereit. Die Ergebnisse der Rahmenarchitektur [bit4health] sowie des Planungsauftrags der Selbstverwaltung [Plan04] sind die wesentliche Grundlage des Solution Outline. Die Einbeziehung bzw. Kommentierung eines arbeitsfähigen Kreises von technischen Experten aus der Industrie bzw. Selbstverwaltung (siehe Error! Reference source not found.) ist entscheidend, um effizient eine akzeptierte und technisch umsetzbare Lösung zu planen. Daher wurden die nachfolgenden Arbeitsgruppen in die Erstellung des Solution Outline eingebunden (mit der in Abbildung 2 aufgeführten Projektorganisation): Technische Experten Einbringen der Funktionalität existierender Produkte, Komponenten und Dienste, Evaluierung von Lösungsalternativen und Bewertung und Planung technischer Risiken. Anwenderkreis Einbringen der Anforderungen aus den Testregionen, der Selbstverwaltung und der F&E Initiative, Kommentierung der organisatorischen und technischen Rahmenbedingungen für die Umsetzung der Lösungsarchitektur Projektgruppe bit4health Seite 15 von

16 Abbildung 2: Projektorganisation für die Erstellung des Solution Outlines Folgende Lösungsdomänen werden in diesem Dokument getrennt behandelt: Dezentrale Komponenten - bit4health Connector. Container-, Proxy Services, Kartenterminals, Remote Administration, Zentrale Komponenten - bit4health Common Services, Middleware (DB, WAS,..), Anwendungsmanagement, Integration backend, Sicherheitskomponenten - Security Services, Access Mgr., Policy, PKI, Trustcenter, Verzeichnisdienste, Kartenproduktion & Kartenmanagement - Kartenproduktion, Kartenmanagement, (Karten) Anwendungs-Management, Netze und Infrastruktur - Generic Common Services, Netzdienste VPN, ISDN,, Konfig. Hochverfügbarkeit, System- & Netz-Mgmt. Der Solution Outline basiert auf den Ergebnissen der Planungsstudie der Selbstverwaltung sowie auf der veröffentlichten Rahmenarchitektur und ist für die Erstellung der Lösungsarchitektur als notwendiger erster Schritt zu sehen. Er beinhaltet die konkrete Planung für die Erstellung und Umsetzung der Lösungsarchitektur und beschreibt die Komplexität sowie den Umfang der Lösung und stellt damit einen Überblick über Zeitpläne und Risiken für die Einführung der Gesundheitskarte bereit. die Beschreibung der in der Lösungsarchitektur zu definierenden Architekturblöcke. weitere, notwendige Architekturentscheidungen um die Anzahl der Lösungsarchitekturen weiter einzuschränken Projektgruppe bit4health Seite 16 von

17 die Skizzierung der Lösungskomponenten in einem Detaillierungsgrad, der über die Rahmenarchitektur hinausgeht. die Identifizierung und grobe Beschreibung derjenigen Schnittstellen der existierenden IT Systeme (Primärsysteme und Back End-Systeme) zur Telematikplattform, die vordringlich festzulegen sind. Aspekte der im Gesundheitswesen aufzubauenden Public Key-Infrastrukturen und der damit verbundenen technischen und organisatorischen Aspekte sowie konkrete Empfehlungen zur Umsetzung dieser. die Evaluierung existierende Lösungsansätze auf die Abdeckung der Anforderungen der Rahmenarchitektur und des Solution Outline. eine Releaseplanung, die die Grundfunktionalität der Telematikplattform in den einzelnen Projektphasen beschreibt und damit eine verbesserte Planungssicherheit für die Testregionen anbietet. die Beschreibung identifizierter Projektrisiken und risikobegrenzender Maßnahmen. Die einzelnen Kapitel dieses Dokuments besitzen die nachfolgend kurz aufgeführten Inhalte: In Kapitel 2 werden die empfohlenen Optionen für die Lösungsarchitektur skizziert und weitere, notwendige Architekturentscheidungen formuliert. In Kapitel 3 werden ausgewählte Produkte und existierende Anwendungen auf die Abdeckung der Anforderungen evaluiert. Kapitel 4 beschreibt die Releaseplanung und die Grundfunktionalität der Telematikplattform in den einzelnen Projektphasen und bietet damit eine verbesserte Planungssicherheit für die Testregionen. Kapitel 5 stellt die Teststrategie zur Erstellung und dem Betrieb einer interoperablen Lösung vor. Im Rahmen dieses Dokuments wurde der Ansatz verfolgt, alle für den Lesefluss nicht wesentliche Detailinformationen in einem separaten Anhang aufzuführen Projektgruppe bit4health Seite 17 von

18 2 Skizzierung der Lösungsarchitektur In diesem Kapitel werden die empfohlenen Dienstschnittstellen und Komponenten für die Lösungsarchitektur skizziert und weitere, notwendige Architekturentscheidungen formuliert. Die nachfolgende Abbildung 3 stellt die externen Dienstschnittstellen und Komponenten der Telematikplattform im Engineering View von RM-ODP dar. bit4health Zulassungsstelle (normative Aufgaben) Zertifizierung und Zulassung von Produkten und Betreibern Festlegung, Aktualisierung von technischen Standards und Service Levels 1 mal E bit4health übergreifende Dienste (operative Aufgaben) 1..k mal Betrieb von application repositories, Central Service Locator, Object ID Service, Primärsysteme Praxis Klinik Apotheke Versandhandel b4h Connector Plattformdienste (1...n mal) Ressource Provider E bit4health Integrator-Backend Anwendungsdienste (1...m mal) b4h Connector b4h Connector Kassen Verzeichnisdienste Kammern E b4h Connector Primärsysteme E bit4health Plattform E bit4health Anwendungen b4h Connector Backend bit4health Schnittstelle und Connector der Telematikinfrastruktur zu existierenden IT-Sytemen Richtung für die Beauftragung der Geschäftsvorfälle und Nutzung derdienste der Telematikinfrastruktur. E Abbildung 3: Externe Dienstschnittstellung und Komponenten der Telematikplattform im Engineering View von RM-ODP. Nachfolgend die Erläuterung der Grobkomponenten der Telematikplattform: bit4health Connectoren für die Anbindung der vorhandenen IT-Systeme an die Telematikplattform. Beispielsweise der bit4health Connector Primärsysteme ist für die Anbindung der vorhandenen Primärsysteme und die Integration der egk und ehba in die Telematikinfrastruktur bestimmt. Als weitere Komponenten bieten die Backend Connectoren, Dienstschnittstellen zu Kammern, Trustcenter und Kassen. Diese unterschiedliche Dienstschnittstellen werden vorhandenen Systemen der Leistungserbringern, Kassen und Kammern angeboten und bilden die äußere Grenze der Telematikplattform: Die b4h Connectoren bieten den kontrollierten Zugang zu den Diensten der Telematikinfrastruktur: b4h PSA-API: als Dienstschnittstelle des bit4health Connectors Primärsysteme für die vorhandenen Primärsysteme bei den Leistungserbringern b4h Kassen-API: als Dienstschnittstelle des bit4health Connectors Kassen für die Informationssysteme und Versichertenverzeichnisse der Kassen 2004 Projektgruppe bit4health

19 b4h Kammer-API: als Dienstschnittstelle des bit4health Connectors Kammern für die Informationssysteme der Leistungserbringer bei den Kammern bit4health Plattform: für die Bereitstellung der Basisdienste (z.b. Transportdienste) für die von den Primärsystemen der Leistungserbringer angestoßenen Geschäftsvorfälle. bit4health Anwendungen: Serverbasierte Dienste der Anwendungen, die über die Telematikinfrastruktur genutzt werden. bit4health Integrator-Backend: Integration externer Dienste (z.b. Zugriff auf die Vertragsdaten bzw. Kartendaten in den Verzeichnisdiensten für Versicherte oder Leistungserbringer). bit4health übergreifende Dienste: Übergreifende Dienste, die für den Betrieb der Telematikinfrastruktur notwendig sind. Es erfolgt die technische Umsetzung der organisatorischen Regularien der Zulassungsstelle. Dazu werden zentrale Dienste für den Ablauf der Anwendungen sowie die Administrationsregeln der gesamten Telematikinfrastruktur bereitgestellt. Konkret werden z.b. Prozessregeln und Transaktionsregeln erstellt bzw. die Zulassung von Diensten bestimmter Provider technisch umgesetzt. bit4health Zulassungsstelle: Organisatorische Einheit, die normative Standards und Regeln für die Telematikinfrastruktur festlegt und prüft. Ein gemeinsamer Ausschusses aller nach 291 a SGB V Beteiligter ist zu schaffen und Arbeitsgruppen zu Einzelthemen sind zu etablieren. Die nachfolgenden Bereiche müssen vordringlich durch arbeitsfähige Arbeitsgruppen festgelegt werden: Kartenstrategie (HBA, Institutionenkarte, egk): Festlegung der Kartenfunktionalität und Ausformung (z. B. physikalische/virtuelle Institutionen-Karten), Weiterentwicklung der Kartenspezifikationen zur Erreichung der Interoperabilität. Datenschutz und Datensicherheit: Festlegung der Datenschutzrichtlinien und organisatorische Sicherheitsregelungen und damit der organisatorischen und technische Mindestanforderungen an die Komponenten Betreiber der Telematikinfrastruktur. bit4health Anwendungen: Anwendungsarchitekturen und Datenformate für den Austausch im Gesundheitswesen (ABDA, KBV, KZBV, ZI, Vertrauensstellen, Datenaufbereitungsstellen, Kassen) und Medizin. Fach-Referenzsysteme (DIMDI in Koop. mit BfArM u.a.). Rahmenbedingungen für Betreiber, Betriebskonzepte: Festlegung der organisatorischen Rahmenbedingungen für Betreiber von Komponenten der Telematikinfrastruktur im Gesundheitswesen. Testverfahren und Abnahmen: Festlegung von Testfällen und Bereitstellung von Testsuiten. Dafür ist jeweils eine abnehmende Stelle für Produkte und Lösungen festzulegen. In der Abbildung 4 sind die internen Schnittstellen der Telematikplattform und sowie die Dienste der einzelnen Komponenten im Überblick dargestellt. 2004Projektgruppe bit4health Seite 19 von 127

20 E bit4health Zulassungsstelle Central Service Locator Policy Rules (normative Aufgaben) bit4health übergreifende Dienste (operative Aufgaben) Central Object ID Service Application Repository 1 mal Admin. 1..k mal SB-Term egk Praxis egk, HBA Klinik egk, HBA Apotheke egk, HBA E b4hc E b4hc E b4hc E b4hc Primärsysteme Security Services Confidentiality, Auth., Integrity, Policy, Audit,.. Directory Generic Common Services E Transport, Transaction, Persistence, Life Cycle mgmt.,.. b4h Common Services Object Id, Workflow, Query, Info. Access, Terminology,. b4h Plattform 1..n mal E E Resource Provider External Services Verzeichnis: LE, Versicherter aministrative- & Kartendaten b4h Integrator Backend Resource Provider Server erezept Klin. Basisdaten Arzneimitteldoku. Arztbrief epa b4h Anwendungen 1..m mal CMS Kassen Statusabfrage Versichertenverzeichnis Karten-DB (egk) TC Kammern Statusabfrage (OCSP) Ärzte-, Apotheker, LE- Verzeichnis Karten-DB (HBA) Verzeichnisdienste Abbildung 4: Überblick über die Dienste und Dienstschnittstellen der einzelnen Komponenten der Telematikplattform. Die in der Lösungsarchitektur festzulegenden internen Dienstschnittstellen der Telematikplattform sind b4h PL-API: Dienstschnittstelle zwischen den bit4health Connector-Primärsysteme und der b4h Plattform, b4h KT-API: Dienstschnittstelle zwischen den bit4health Connector-Primärsysteme und der b4h Kartenterminals, b4h APP-API: Dienstschnittstelle zwischen der b4h Plattform und den b4h Anwendungen, b4h EXT-API: Dienstschnittstelle zwischen der b4h Plattform und den b4h externen Diensten zum Zugriff auf die Vertrags- und Kartendaten der Versicherten und Heilberufler. Die nachfolgende Abbildung 5 stellt schematisch die Kommunikation und Netze zwischen den b4h Komponenten der Telematikplattform dar. 2004Projektgruppe bit4health Seite 20 von 127

21 Lokale Zugangsnetze Gruppenspezifische Zugänge b4h EConnector E b4h EConnector b4h EConnector b4h EConnector b4h EConnector b4h Connector E b4h EConnector b4h EConnector b4h EConnector b4h EConnector b4h EConnector b4h Connector IPSEC VPN über Internet IPSEC VPN über Internet E b4h Plattform E b4h Plattform E b4h Anwendungen E b4h Int./backend Internes backbone nur beispielhaft VPN b4hc E E b4hc E b4hc Kassen Kammern TC E b4h EConnector b4h EConnector b4h EConnector b4h EConnector b4h EConnector b4h Connector IPSEC VPN über Internet E b4h Plattform E b4h Anwendungen E b4h Int./backend VPN E b4hc E b4hc Ärzte ca Kassen ca. 300 Apotheken ca Kammern ca.?? Krankenhäuser 2240 Trustcenter ca 3-10 Abbildung 5: Netzverbindungen und Kommunikation zwischen den Komponenten der Telematikplattform. In der nachfolgenden Tabelle 1 sind im Überblick die wesentlichen Geschäftsvorfälle (Use Cases) und die von diesen betroffenen Dienstschnittstellen dargestellt. zeigt dabei die Initiierung dieses Geschäftsvorfalls vom Primärsystem des Heilberuflers oder eines SB-Terminal, zeigt dabei die Initiierung dieses Geschäftsvorfalls vom den Backendsystemen der Kassen oder den Registrierungsstellen der Heilberufsausweise oder Institutionenkarten an. x: Kommunikation/Informationsfluss endet an dieser Komponente. : Antwort wird auf egk geschrieben. Die Aufwände für die Spezifikation der Schnittstellen sind auf der Basis der Anzahl der jeweiligen Geschäftsvorfälle erstellt worden. In der Lösungsarchitektur sind diese Use Cases zu detaillieren (z.b. sind unterschiedliche Szenarien zu berücksichtigen) und die Dienstschnittstellen zu spezifizieren. 2004Projektgruppe bit4health Seite 21 von 127

22 Tabelle 1: Überblick über die Geschäftsvorfälle (high level Use Cases) und externe und interne Dienstschnittstellen der Telematikinfrastruktur Akteur Nr. Anwendungsfall Name Verordnungsgeber VO-3 Übergabe-Dokument signieren Administrative Kraft (des Verordnungsgebers) VO-4 Übergabe-Dokument auf einen Datenträger aufbringen Patient VO-5 Verordnung/Überweisung einreichen Verordnungseinlöser VO-6 Verordnung/Überweisung übernehmen Verordnungseinlöse KO-02 Authentizität/Signatur der Daten prüfen Verordnungseinlöser VO-7 Übergabe-Dokument entwerten Patient BE-1 Einmalige Einwilligung bei der ersten Verwendung einer freiwilligen Anwendung geben PSA b4h PSA-API X b4h KT-API b4h PL-API X X X b4h APP-API b4h Ext-API X X X X egk App. Server Primärsystem Trustcenter HBA b4h- Kammer API lok. RA Herausgeber HBA CMS bzw. CAMS X Nachpersonalisierung Patient BE-2 Einwilligung zur Verwendung einer freiwilligen X X Nach- Anwendung widerrufen egk App. persona- lisierung Server Patient BE-3 Heilberufler für den Zugriff X auf medizinische Daten autorisieren (eine Session) PIN Patient BE-4 Medizinische Daten bereitstellen X Approbierter Heilberufleschreiben BE-5 Medizinische Daten fort- X Versicherter VD-1 Stammdaten mitteilen X 2004 Projektgruppe bit4health Seite 22 von 127 b4h Kassen API KK - System

23 Akteur Nr. Anwendungsfall Name X Nachper. Administrative Kraft (des Leistungserbringers) Administrative Kraft (des Leistungserbringers) SB-Term KK-Term VD-3 Patient identifizieren X VD-4 Vertragsdaten übernehmen (egk und Online Abfrage) Versicherter VD-8 Zahlungsbeteiligung nachweisen b4h PSA-API b4h KT-API X egk b4h PL-API b4h APP-API b4h Ext-API Primärsystem PSA Trustcenter HBA b4h- Kammer API lok. RA Herausgeber HBA CMS bzw. CAMS Krankenversicherer VD-2 Vertragsdaten aktualisieren X Vers. DB X X Vers. DB b4h Kassen API KK - System X Kartenherausgeber Versicherter Kartenherausgeber Versicherter KA-02 KE-01 Personalisierungsdaten bereitstellen X Kartenprod. X Vers./Ka rten DB AS-03 Applikation beantragen X X Vers./Ka rten DB Kartenherausgeber AN-02 Applikation aktualisieren Karten- Versicherter herausgeber Kartensperrauftrag erzeugen Karten- Versicherter herausgeber Kartenherausgeber Heilberufler AE-03 KA-02 Applikationslöschung beantragen Personalisierungsdaten bereitstellen SB-Term KK-Term egk X Vers./Ka rten DB X X Vers./Ka rten DB X HBA Prod. X X X X X X 2004Projektgruppe bit4health Seite 23 von 127

24 Akteur Nr. Anwendungsfall Name b4h PSA-API b4h KT-API b4h PL-API b4h APP-API b4h Ext-API Primärsystem PSA Trustcenter HBA b4h- Kammer API lok. RA Herausgeber HBA CMS bzw. CAMS b4h Kassen API KK - System Kartenherausgeber Heilberufler KE-01 Kartensperrauftrag erzeugen X Karten DB, CRL X Kartenherausgeber Institutionenkarte KA-02 Personalisierungsdaten bereitstellen X HBA Prod. X Kartenherausgeber Institutionenkarte KE-01 Kartensperrauftrag erzeugen X X Karten DB, CRL 2004Projektgruppe bit4health Seite 24 von 127

25 Es gibt einige grundsätzliche Architekturentscheidungen, welche an dieser Stelle als Voraussetzung für die Skizzierung der Lösungsarchitektur empfohlen und in den nachfolgenden Kapiteln verwendet werden. Tabelle 2: Wesentliche Architekturentscheidungen für die Skizzierung der Lösungsarchitektur Nr. Bereich Entscheidung AE-L1 AE-L2 AE-L3 AE-L4 Verwendung der Karten- und IT- Systeme nur für Aufgaben im Gesundheitswesen. Aufteilung (Trennung) der übergreifenden Stelle in normative und operative Aufgaben Sicherheitsniveaus sind entsprechend kommerziell verfügbaren und erprobten Standards zu wählen und entsprechend dem Wirtschaftlichkeitsgebot sind dabei Kosten/Nutzen/Risiken abzuwägen. Die Telematikplattform stellt in der Regel passiv Dienste bereit, die durch die Primärsysteme aktiv genutzt werden. Bei der Lösungsarchitektur wird davon ausgegangen, daß die Karten- und IT-System nur für Aufgaben im Gesundheitswesen eingesetzt werden. Dies reduziert die Komplexität der Use-Cases, der technischen Komponenten und der Testaufwände auf das für das Gesundheitswesen notwendige Maß. Eine übergreifende Stelle ist zuständig für die Festlegung von verbindlichen Standards und Schnittstellen, die Prüfung und Zulassung von Geräten und Produkten die Prüfung und Zulassung von Betreibern. Diese Stelle besitzt nur die administrative Verantwortung und ist weder für den Aufbau noch den Betrieb - auch nicht von Teilen - der Telematikinfrastruktur zuständig. Bei der Kartenproduktion und - personalisierung werden heute kommerziell verfügbare Produktionskapazitäten mit hohem Sicherheitniveau angenommen. Heute vorhandene Identifizierungs- und Registrierungsniveaus der Versicherten (Vertragsabschluss) werden beibehalten. Das Pull-Modell betrifft den Wirkbetrieb für den Zugriff auf die medizinischen und administrativen Vertragsdaten. Administrative Aufgaben (Anwendungs-, System-, Kartenapplikationsmanagment) können in Ausnahmen (z.b. proprietäte Schnittstellen für Kartenadministration) davon abweichen. AE-L5 Aufteilung in Komponenten Die Komponenten der Lösungsarchitektur können in ihren internen Strukturen unterschiedlich realisiert und betrieben werden. Die angeboten Dienste sind einheitlich festzulegen. Mit höchster Priorität zu behandeln sind die Schnittstellen zwischen der Telematikinfrastruktur und den vorhandenen IT- Systemen: b4h PSA-API: Primärsysteme und 2004 Projektgruppe bit4health Seite 25 von 127

26 Nr. Bereich Entscheidung bit4health-connector b4h Kassen-API: Schnittstelle zu Kassen zur Bereitstellung des Versicherten- und Identitätsverzeichnisses, Kartenadministration ggf. Verifikationsdienste b4h Kammer-API: Schnittstelle zwischen Kammern und den Kartenherausgebern der HBA für die Bereitstellung der Verifikationsdienste AE-L6 Aufteilung der medizinischen Informationen Für alle medizinischen Anwendungen findet eine Trennung der beschreibenden (links bzw. Referenzen bzw. Tickets) von den medizinischen Daten statt. AE-L7 Erweiterbarkeit Für die im GMG festgelegten Anwendungen sind die Operationen Lesen, Schreiben, Erzeugen und Löschen (RWCD) für die temporäre Speicherung in der Telematikinfrastruktur ausreichend. Die Plattform muss für zusätzliche Operationen/Geschäftstransaktionen erweiterbar sein. Zusätzliche Dienste können in späteren Phasen nachladen von Applikationen auf die Karten (z.b. Java Cards etc.) oder Server Dienste realisiert werden. 2004Projektgruppe bit4health Seite 26 von 127

27 2.1 Dezentrale Komponenten In diesem Abschnitt wird auf die dezentrale Komponente bit4health Connector Primärsysteme mit ihren Schnittstellen zur Primärsystemapplikation, zu den bit4health Plattformdiensten sowie zum Kartenterminal eingegangen (siehe Abbildung 6). Primärsysteme Health Client Applications SDK E b4h Connector Primärsysteme Dienstschnittstelle b4h PSA-API bit4health Container Service Common Services Proxy Services Command Manager Interface Repository bit4health Anwendungskomponenten Vertragsdaten erezept etc. Signature Application Generic Common Services Transport, Protocol, Persistence bit4health Common Services Query, Information Access, Object ID Security Services Client SDK Confidentiality, Policy, Authorization, Audit etc. Generic Common Services Configuration, Application Mgmt. Resource Provider Data Stores Devices Plattformschnittstelle b4h PL-API Kartenterminal API b4h KT-API Remote admin E b4h Plattform Dienste E b4h Card- Terminal egk HBA TSeGK HPC Abbildung 6: Komponenten und Schnittstellen des bit4health Connectors Primärsysteme. Die wesentlichen internen Komponenten der Rahmenarchitur sind in dieser Abbildung für den b4h Connector Primärsysteme schematisch dargestellt. Entscheidend sind die 3 festgelegten externen Schnittstellen (b4h PSA-API, KT-API, PL-API) die in der Lösungsarchitektur zu spezifizieren sind. Die interne Implementierung (Aufteilung auf unterschiedliche Hardware etc) wird durch diese Abbildung nicht festgelegt und wird herstellerspezifisch realisiert werden Skizzierung des bit4health Connectors Der bit4health Connector enthält die bit4health Anwendungskomponenten, die die clientseitige Funktionalität von Anwendungen wie Vertragsdaten und erezept bereitstellen. Die Aufrufe der Primärsystemapplikation werden über den Command Manager an die Anwendungskomponenten verteilt. Um diese zu verwalten und gegebenenfalls zu aktualisieren, nutzt der Command Manager weiterhin Dienste des bit4health Container Service. Für die Realisierung ihrer Funktionalitäten stehen den Anwendungskomponenten im bit4health Connector verschiedene Dienste zur Verfügung (die Client-seitigen Ausprägun Projektgruppe bit4health Seite 27 von

28 gen der bit4health und Generic Common Services und Security Services; s.a. [bit4health] Komponentenmodell). Diese kommunizieren gegebenenfalls über entsprechende Proxies mit zentralen Diensten der bit4health Plattform oder greifen auf lokale Resource Provider (Kartenterminals bzw. Karten) zu Deploymentszenarien für den bit4health Connector Primärsystem Für die physische Verteilung des bit4health Connectors Primärsysteme existieren je nach Einsatzumgebung verschiedene Möglichkeiten. Exemplarisch sollen im Folgenden vier Szenarien mit unterschiedlichen Ausprägungen des b4h Connectors Primärsysteme vorgestellt werden. Szenario 1: Mobiles Kartenterminal egk HBA Printer PSA sync Kartenterminal Disk RS 232 Parallel Display Keyboard / PIN Pad HBA Slot egk Slot Low Level OS b4h KT-API Common Services bit4health Anwendungskomponenten b4h PSA-API Rudimentäre PSA-Funtionalität Abbildung 7: bit4health Connector Primärsystem im mobilen Kartenterminal Mobile Kartenterminals stellen rudimentäre PSA-Funktionalität zur Verfügung wie z.b. das Lesen von Vertragsdaten von der egk. Sie besitzen optional eine Möglichkeit zur Druckerausgabe, um die von der Karte gelesenen Daten auf Papiermedien auszudrucken, und eine Schnittstelle zum asynchronen Datenabgleich mit Primärsystemapplikationen. Beide Übertragungswege können mittels standardisierten Verbindungsarten zu einem PSA-Host- System (z.b. seriell, seriell USB, parallel, wireless etc.) realisiert werden Projektgruppe bit4health Seite 28 von

29 Teilfunktionalitäten des bit4health Connectors können in diesem Szenario in das mobile Kartenterminal eingebettet sein. Die abstrakte Kartenterminalschnittstelle wird in Form einer internen Kommunikation realisiert. Die Teilfunktionalität des bit4health Connectors muss mit den begrenzten Ressourcen eines mobilen Gerätes auskommen. Komponenten für den Zugriff des bit4health Connectors auf Plattformdienste werden nicht benötigt. Dies zeigt beispielhaft, dass in bestimmten Einsatzumgebungen Teilimplementierungen des b4h Connectors mit eingeschränktem Funktionsumfang möglich sind. Szenario 2: Mobiler Primärsystemapplikations-PC RS 232 Karten- Terminal USB PSA PC Modem / ISDN / DSL tcp/ip Parallel Printer Low Level OS b4h KT-API b4h PL-API Common Services ProxyServices bit4health Anwendungskomponenten b4h PSA-API PSA Abbildung 8: bit4health Connector Primärsystem im mobilen PSA-PC Während PSA Einzelplatzinstallationen selbst in kleineren Arztpraxen selten vorkommen, sind sie dennoch denkbar für den mobilen Einsatz (z.b. auf Laptop). In einem solchen Szenario liegt der bit4health Connector als lokale Installation vor. Zu berücksichtigen ist die benötigte Offline-Fähigkeit. So müssen z.b. Rezepte offline erstellt werden können und später bei Verfügbarkeit einer Internetverbindung an den entsprechenden zentralen Dienst der Plattform übergeben werden. Das Kartenterminal kann in diesem Szenario z.b. über einen Übertragungsweg (u.a. USB, Ethernet etc.) angeschlossen sein. Eine entsprechende Implementierung für die Kartenterminal-Schnittstelle muss installiert sein Projektgruppe bit4health Seite 29 von

Strategie zur Einführung der Gesundheitskarte

Strategie zur Einführung der Gesundheitskarte Strategie zur Einführung der Gesundheitskarte Projektübersicht bit4health Rahmenarchitektur Tübinger Archivtage 2004, 17.06.2004 Annette Kirchner IBM Business Consulting Services, Strategy & Change Public

Mehr

r die Anbindung an die Telematikinfrastruktur

r die Anbindung an die Telematikinfrastruktur Start: Die Institutionenkarte (SMC) Voraussetzung fürf r die Anbindung an die Telematikinfrastruktur IT-Trends Trends Medizin Health Telematics 6.September 2007 Dr.Harald Ahrens SignCard GmbH & Co KG 1

Mehr

Standard-(Notizen) zur elektronischen Gesundheitskarte (egk)

Standard-(Notizen) zur elektronischen Gesundheitskarte (egk) Standard-(Notizen) zur elektronischen Gesundheitskarte (egk) page 1 Die egk und Martin Luther King! Seit der Erfindung der Mikroprozessorchipkarte vor mehr als 30 Jahren gilt Martin Luther King`s Satz:

Mehr

Smart Cards im Gesundheitswesen ein Überblick 1

Smart Cards im Gesundheitswesen ein Überblick 1 Smart Cards im Gesundheitswesen ein Überblick 1, Christian Anhalt {loos canhalt}@uni-hohenheim.de Universität Hohenheim, ehealth-lab, 70593 Stuttgart 1 Rahmenbedingungen Zu den zentralen Bestandteilen

Mehr

Die elektronische Gesundheitskarte - Ziele und Perspektiven -

Die elektronische Gesundheitskarte - Ziele und Perspektiven - Die elektronische Gesundheitskarte - Ziele und Perspektiven - Essen, den 7. September 2006 Dr. Stefan Bales Bundesministerium für Gesundheit Elektronische Gesundheitskarte Leuchtturmprojekt im Koalitionsvertrag

Mehr

Sicherheit der Komponenten der Telematik-Infrastruktur

Sicherheit der Komponenten der Telematik-Infrastruktur Sicherheit der Komponenten der Telematik-Infrastruktur IT - Sicherheit im Gesundheitswesen Regelungen und Maßnahmen für eine sichere TI im Zuge der Einführung der egk ( BSI ) Bundesamt für Sicherheit in

Mehr

Die Spezifikation der Lösungsarchitektur zur Umsetzung der Anwendungen der elektronischen Gesundheitskarte Management Summary Prof. Dr.

Die Spezifikation der Lösungsarchitektur zur Umsetzung der Anwendungen der elektronischen Gesundheitskarte Management Summary Prof. Dr. Die Spezifikation der Lösungsarchitektur zur Umsetzung der Anwendungen der elektronischen Gesundheitskarte Management Summary Prof. Dr. Herbert Weber Von Dezember 2004 bis Februar 2005 haben die Fraunhofer-Institute

Mehr

Kommunikation in der Intersektoralen Versorgung

Kommunikation in der Intersektoralen Versorgung Kommunikation in der Intersektoralen Versorgung Dr. Gert Funkat funkat@imise.uni-leipzig.de Was ist ISV? Das Informationsdilemma Die Information, die Du hast, ist nicht die, die Du willst Die Information,

Mehr

Architektur und Funktionsweise des Konnektors für Krankenhausinformationsund Arztpraxissysteme

Architektur und Funktionsweise des Konnektors für Krankenhausinformationsund Arztpraxissysteme Architektur und Funktionsweise des Konnektors für Krankenhausinformationsund Arztpraxissysteme Stefan Menge Siemens Medical Solutions Copyright Siemens AG 2007. All rights reserved. Agenda Überblick Gesamtarchitektur

Mehr

Anforderungen an eine Telematik-Rahmenarchitektur aus Sicht der Standardisierung

Anforderungen an eine Telematik-Rahmenarchitektur aus Sicht der Standardisierung ATG-Forum 2002 Telematik-Rahmenarchitektur Anforderungen an eine Telematik-Rahmenarchitektur aus Sicht der Standardisierung Erwin Bartels Institut für Luft- und Raumfahrtmedizin Deutsches Zentrum für Luft-

Mehr

Aktuelle Telematikanwendungen

Aktuelle Telematikanwendungen Aktuelle Telematikanwendungen Aufbau der Basis-TI und Versichertenstammdatenmanagement - IT-Trends Medizin/Health Telematics 2011 Essen, 21. September 2011, Rainer Höfer, Abteilung IT-Systemfragen / Telematik

Mehr

Use-Cases. Bruno Blumenthal und Roger Meyer. 17. Juli 2003. Zusammenfassung

Use-Cases. Bruno Blumenthal und Roger Meyer. 17. Juli 2003. Zusammenfassung Use-Cases Bruno Blumenthal und Roger Meyer 17. Juli 2003 Zusammenfassung Dieses Dokument beschreibt Netzwerk-Szenarios für den Einsatz von NetWACS. Es soll als Grundlage bei der Definition des NetWACS

Mehr

Die Telematikinfrastruktur als sichere Basis im Gesundheitswesen

Die Telematikinfrastruktur als sichere Basis im Gesundheitswesen Die Telematikinfrastruktur als sichere Basis im Gesundheitswesen conhit Kongress 2014 Berlin, 06.Mai 2014 Session 3 Saal 3 Gesundheitsdaten und die NSA Haben Patienten in Deutschland ein Spionageproblem?

Mehr

Die elektronische Gesundheitskarte Aktueller Stand ehealth Niedersachsen

Die elektronische Gesundheitskarte Aktueller Stand ehealth Niedersachsen Die elektronische Gesundheitskarte Aktueller Stand ehealth Niedersachsen 10.Oktober 2007 Dr.Harald Ahrens SignCard GmbH & Co KG 1 Der Anfang: Das Gesetz 2 Gesetzliche Grundlage Gesetz zur Modernisierung

Mehr

MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP)

MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP) MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP) Oliver Steinhauer.mobile PROFI Mobile Business Agenda MOBILE ENTERPRISE APPLICATION PLATFORM AGENDA 01 Mobile Enterprise Application Platform 02 PROFI News

Mehr

Microsoft.NET und SunONE

Microsoft.NET und SunONE Microsoft.NET und SunONE, Plattformen und Application Service Providing Agenda Einordnung.NET und SunONE Kurzvorstellung Gegenüberstellung Zusammenfassung ASP (Application( Service Providing) ) und Ausblick

Mehr

Die Umsetzung im Krankenhaussektor

Die Umsetzung im Krankenhaussektor Basis-Rollout Die Umsetzung im Krankenhaussektor Dipl.-Ing. (FH) Helga Mesmer Folie 1 Gliederung Einführung 1. Gesundheits-Telematik-Infrastruktur Die Gesamtarchitektur 2. Anwendungen der egk Eine Übersicht

Mehr

Einführung der egk. Notwendige Vorarbeiten in den Krankenhäusern

Einführung der egk. Notwendige Vorarbeiten in den Krankenhäusern Einführung der egk Notwendige Vorarbeiten in den Krankenhäusern Prof. Dr. Anke Häber Westsächsische Hochschule Zwickau Gliederung 1. Die Telematikinfrastruktur 2. Anforderungen aus den Anwendungen 3. Konsequenzen

Mehr

Java und XML 2. Java und XML

Java und XML 2. Java und XML Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik Java und XML Hauptseminar Telematik WS 2002/2003

Mehr

Grid-Systeme. Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit. 07.06.2002 Grid Systeme 1

Grid-Systeme. Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit. 07.06.2002 Grid Systeme 1 Grid-Systeme Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit 07.06.2002 Grid Systeme 1 Gliederung Vorstellung verschiedener Plattformen Globus

Mehr

Potentielle Anwendungen und Rahmenbedingungen für Multiapplikationskarten

Potentielle Anwendungen und Rahmenbedingungen für Multiapplikationskarten 13. Juli 2006 Potentielle Anwendungen und Rahmenbedingungen für Multiapplikationskarten Bruno Struif Rheinstr. 75 64295 Darmstadt bruno.struif@sit.fraunhofer.de Inhalt Begriff Multiapplikationskarte Multiapplikationskarten

Mehr

MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP)

MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP) MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP) Oliver Steinhauer Markus Urban.mobile PROFI Mobile Business Agenda MOBILE ENTERPRISE APPLICATION PLATFORM AGENDA 01 Mobile Enterprise Application Platform

Mehr

PMI Munich Chapter 21.04.2008

PMI Munich Chapter 21.04.2008 Projektmanagement im Rahmen einer IT-Infrastruktur- Standardisierung mit internationalen Teams Christoph Felix PMP, Principal Project Manager, Microsoft Deutschland PMI Munich Chapter 21.04.2008 Agenda

Mehr

Cloud Computing Potenziale für die öffentliche Verwaltung führungskräfte forum im HHI, Berlin

Cloud Computing Potenziale für die öffentliche Verwaltung führungskräfte forum im HHI, Berlin Cloud Computing Potenziale für die öffentliche Verwaltung führungskräfte forum im HHI, Berlin Dr. Klaus-Peter Eckert, Dr. Peter Deussen Fraunhofer FOKUS - Berlin 18.10.2011 Agenda Technische Voraussetzungen

Mehr

Zulassung Produkte der Telematikinfrastruktur hier: gematik Root-CA

Zulassung Produkte der Telematikinfrastruktur hier: gematik Root-CA Einführung der Gesundheitskarte Verfahrensbeschreibung Zulassung Produkte der Version: 1.0.0 Revision: \main\17 Stand: 15.05.2014 Status: freigegeben Klassifizierung: öffentlich Referenzierung: [gemzul_prod_x509root]

Mehr

Desktop Management Interface und andere Initiativen der DMTF

Desktop Management Interface und andere Initiativen der DMTF Desktop Management Interface und andere Initiativen der DMTF Gliederung DMI Übersicht Architektur, Organisation Informationsmodell Kommunikationsmodell Sicherheit DMI-Zertifizierung Weitere DMTF-Initiativen

Mehr

egk-zugriffsprofile: Datensicherheit durch Card-to-Card-Authentifizierung Dr. S. Buschner 27.09.2007

egk-zugriffsprofile: Datensicherheit durch Card-to-Card-Authentifizierung Dr. S. Buschner 27.09.2007 egk-zugriffsprofile: Datensicherheit durch Card-to-Card-Authentifizierung Dr. S. Buschner gematik - Gesellschaft für Telematikanwendungen der Gesundheitskarte mbh Friedrichstraße 136 10117 Berlin 27.09.2007

Mehr

Implementierung von IBM Connections bei der Robert Bosch GmbH: Erfahrungen und Empfehlungen

Implementierung von IBM Connections bei der Robert Bosch GmbH: Erfahrungen und Empfehlungen Implementierung von IBM Connections bei der Robert Bosch GmbH: Erfahrungen und Empfehlungen 19. September 2012, Dr. Erik Wüstner, Technischer Projektleiter im Zentralbereich IT Social Business bei Bosch

Mehr

Zugang/Migration von Gesundheitsdatendiensten als Mehrwertfachdienste in die Telematikinfrastruktur am Beispiel der elektronischen Fallakte

Zugang/Migration von Gesundheitsdatendiensten als Mehrwertfachdienste in die Telematikinfrastruktur am Beispiel der elektronischen Fallakte Zugang/Migration von Gesundheitsdatendiensten als Mehrwertfachdienste in die Telematikinfrastruktur am Beispiel der elektronischen Fallakte Rechtsanwalt Jörg Meister Deutsche Krankenhausgesellschaft 8.9.2010

Mehr

Webservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste

Webservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste Hauptseminar Internet Dienste Sommersemester 2004 Boto Bako Webservices 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung Was sind Web Services? Web Services sind angebotene

Mehr

VERTRAUENSWÜRDIGE IDENTITÄTEN FÜR DIE CLOUD

VERTRAUENSWÜRDIGE IDENTITÄTEN FÜR DIE CLOUD VERTRAUENSWÜRDIGE IDENTITÄTEN FÜR DIE CLOUD Dr. Detlef Hühnlein, Johannes Schmölz ecsec GmbH, Sudetenstraße 16, D96247 Michelau Zusammenfassung 1 Einleitung che Schwachstellen enthalten. 44 FraunhoferGesellschaft

Mehr

Dialog ehealth. " Einführung der elektronischen Gesundheitskarte 2006 - planen, prüfen, praktisch proben"

Dialog ehealth.  Einführung der elektronischen Gesundheitskarte 2006 - planen, prüfen, praktisch proben Dialog ehealth " Einführung der elektronischen Gesundheitskarte 2006 - planen, prüfen, praktisch proben" GoCard! das Projekt der DAK zur Einführung der elektronischen Gesundheitskarten bei der DAK Michael

Mehr

Informationsveranstaltung 3. Mai 2006 in Essen

Informationsveranstaltung 3. Mai 2006 in Essen Informationsveranstaltung 3. Mai 2006 in Essen Stand der Einführung der elektronischen Gesundheitskarte Dipl.-Wirtsch.Ing. Gilbert Mohr Leiter Stabsstelle IT in der Arztpraxis Kassenärztliche Vereinigung

Mehr

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com Merkblatt: HSM Version 1.01 Systemvoraussetzungen, Setup und Trouble Shooting Kontakt: pdfsupport@pdf-tools.com Besitzer: PDF Tools AG Kasernenstrasse 1 8184 Bachenbülach Schweiz www.pdf-tools.com Copyright

Mehr

SaxMediCard Aktueller Stand der Einführung der egk und des HBA in Sachsen

SaxMediCard Aktueller Stand der Einführung der egk und des HBA in Sachsen SaxMediCard Aktueller Stand der Einführung der egk und des HBA in Sachsen Technologieform Elektronische Gesundheitskarte Romain Seibt Regionaler Projektleiter Managementgesellschaft Gesundheitszentrum

Mehr

Eclipse Equinox als Basis für Smart Client Anwendungen. Christian Campo, compeople AG, 5.7.2007 Java Forum Stuttgart 2007

Eclipse Equinox als Basis für Smart Client Anwendungen. Christian Campo, compeople AG, 5.7.2007 Java Forum Stuttgart 2007 Eclipse Equinox als Basis für Smart Client Anwendungen Christian Campo, compeople AG, 5.7.2007 Java Forum Stuttgart 2007 Übersicht Definition / Architektur Smart Client Smart Client mit RCP / Equinox Gesamtfazit

Mehr

MOBILE ON POWER MACHEN SIE IHRE ANWENDUNGEN MOBIL?!

MOBILE ON POWER MACHEN SIE IHRE ANWENDUNGEN MOBIL?! MOBILE ON POWER MACHEN SIE IHRE ANWENDUNGEN MOBIL?! Oliver Steinhauer Sascha Köhler.mobile PROFI Mobile Business Agenda MACHEN SIE IHRE ANWENDUNGEN MOBIL?! HERAUSFORDERUNG Prozesse und Anwendungen A B

Mehr

Kontinuität der Behandlung Chancen durch die deutsche Telematikarchitektur

Kontinuität der Behandlung Chancen durch die deutsche Telematikarchitektur Kontinuität der Behandlung Chancen durch die deutsche Telematikarchitektur Dr. Stefan Buschner gematik - Gesellschaft für Telematikanwendungen der Gesundheitskarte mbh Friedrichstraße 136 10117 Berlin

Mehr

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung mit Enterprise JAVA Beans Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung

Mehr

SaxMediCard egk und ehba im Freistaat Sachsen

SaxMediCard egk und ehba im Freistaat Sachsen SaxMediCard egk und ehba im Freistaat Sachsen Mirko Weißbach Projektleitung AOK Sachsen, Dresden Romain Seibt Regionaler Projektleiter Managementgesellschaft Gesundheitszentrum Löbau-Zittau Projektbeteiligte

Mehr

Aktuelles von der gematik: Testvorbereitungen

Aktuelles von der gematik: Testvorbereitungen Aktuelles von der gematik: Testvorbereitungen Benno Herrmann Leiter Unternehmenskommunikation und Marketing gematik Gesellschaft für Telematikanwendungen der Gesundheitskarte mbh Friedrichstraße 136 10117

Mehr

OFTP2 - Checkliste für die Implementierung

OFTP2 - Checkliste für die Implementierung connect. move. share. Whitepaper OFTP2 - Checkliste für die Implementierung Die reibungslose Integration des neuen Odette-Standards OFTP2 in den Datenaustausch- Workflow setzt einige Anpassungen der Systemumgebung

Mehr

IT-gestützte Kommissionierung im Online-Modehandel. Konzeption, Realisierung und Einführung

IT-gestützte Kommissionierung im Online-Modehandel. Konzeption, Realisierung und Einführung Wirtschaft Daniel Goebel IT-gestützte Kommissionierung im Online-Modehandel. Konzeption, Realisierung und Einführung Masterarbeit Bibliografische Information der Deutschen Nationalbibliothek: Die Deutsche

Mehr

Absicherung von Grid Services Transparenter Application Level Gateway

Absicherung von Grid Services Transparenter Application Level Gateway Absicherung von Grid Services Transparenter Application Level Gateway Thijs Metsch (DLR Simulations- und Softwaretechnik) Göttingen, 27.03.2007, 2. D-Grid Security Workshop Folie 1 Überblick Gliederung

Mehr

SZENARIO BEISPIEL. Implementation von Swiss SafeLab M.ID mit Citrix. Redundanz und Skalierbarkeit

SZENARIO BEISPIEL. Implementation von Swiss SafeLab M.ID mit Citrix. Redundanz und Skalierbarkeit SZENARIO BEISPIEL Implementation von Swiss SafeLab M.ID mit Citrix Redundanz und Skalierbarkeit Rahmeninformationen zum Fallbeispiel Das Nachfolgende Beispiel zeigt einen Aufbau von Swiss SafeLab M.ID

Mehr

Entwicklung von Web-Anwendungen auf JAVA EE Basis

Entwicklung von Web-Anwendungen auf JAVA EE Basis Entwicklung von Web-Anwendungen auf JAVA EE Basis Java Enterprise Edition - Überblick Prof. Dr. Bernhard Schiefer Inhalt der Veranstaltung Überblick Java EE JDBC, JPA, JNDI Servlets, Java Server Pages

Mehr

Manuel Koch, Dr. Herbert Bunz 10. September 2009. Datenschutz fördernde Techniken als vertrauensfördernde Maßnahmen der Gesundheitstelematik

Manuel Koch, Dr. Herbert Bunz 10. September 2009. Datenschutz fördernde Techniken als vertrauensfördernde Maßnahmen der Gesundheitstelematik Manuel Koch, Dr. Herbert Bunz 10. September 2009 Datenschutz fördernde Techniken als vertrauensfördernde Maßnahmen der Gesundheitstelematik 2009 gematik 2009 IBM Corporation Der Patient kann selbstbestimmt

Mehr

Inhaltsverzeichnrs. V Abkürzungsverzeichnis... XV Literaturverzeichnis...XVII

Inhaltsverzeichnrs. V Abkürzungsverzeichnis... XV Literaturverzeichnis...XVII Inhaltsverzeichnrs Vorwort V Abkürzungsverzeichnis... XV Literaturverzeichnis....XVII Teil A Einführung I. Ausgangslage.. 4 II. Rahmenbedingungen für die Telematik im Gesundheitswesen. 5 III. Europäischer

Mehr

CLOUDCYCLE Ferner integriert der Broker neue Konzepte zur geographischen Eingrenzung der Nutzung von Cloud-Diensten und assoziierter Daten.

CLOUDCYCLE Ferner integriert der Broker neue Konzepte zur geographischen Eingrenzung der Nutzung von Cloud-Diensten und assoziierter Daten. TRusted Ecosystem for Standardized and Open cloud-based Resources Das Vorhaben hat den Aufbau eines Cloud-Ecosystems zum Ziel, welches exemplarisch für den Anwendungsbereich der Patientenversorgung im

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Whitepaper D-TRUST onlinera 2010

Whitepaper D-TRUST onlinera 2010 Whitepaper D-TRUST onlinera 2010 Bundesdruckerei GmbH c/o D-TRUST GmbH Kommandantenstraße 15 D - 10969 Berlin www.d-trust.net E-Mail: vertrieb@bdr.de Tel.: +49 (0) 30 / 25 98-0 Fax: + 49 (0) 30 / 25 98-22

Mehr

ARTS Server 3.5. Produktbeschreibung. Uptime Services AG

ARTS Server 3.5. Produktbeschreibung. Uptime Services AG Uptime Services AG Brauerstrasse 4 CH-8004 Zürich Tel. +41 44 560 76 00 Fax +41 44 560 76 01 www.uptime.ch ARTS Server 3.5 Produktbeschreibung Uptime Services AG Inhaltsverzeichnis 1 Einleitung... 2 2

Mehr

Good Dynamics by Good Technology. V1.1 2012 by keyon (www.keyon.ch)

Good Dynamics by Good Technology. V1.1 2012 by keyon (www.keyon.ch) Good Dynamics by Good Technology eberhard@keyon.ch brunner@keyon.ch V1.1 2012 by keyon (www.keyon.ch) 1 Über Keyon Experten im Bereich IT-Sicherheit und Software Engineering Als Value added Reseller von

Mehr

Stand der Einführung der elektronischen Gesundheitskarte

Stand der Einführung der elektronischen Gesundheitskarte Stand der Einführung der elektronischen Gesundheitskarte Dirk Drees gematik - Gesellschaft für Telematikanwendungen der Gesundheitskarte mbh Friedrichstraße 136 10117 Berlin 07.09.2006 IT-Trends Medizin

Mehr

Die elektronische Gesundheitskarte

Die elektronische Gesundheitskarte Die elektronische Gesundheitskarte und ihre Anwendung im Gesundheitswesen Die egk als Schlüssel zur Sicherheit für den Patienten in der Telematikinfrastruktur Tel.: 0271/708-1607 Rainer.Moos@T-Systems.com

Mehr

Enterprise Web-SSO mit CAS und OpenSSO

Enterprise Web-SSO mit CAS und OpenSSO Enterprise Web-SSO mit CAS und OpenSSO Agenda Gründe für SSO Web-SSO selbst gemacht Enterprise Web-SSO mit CAS Enterprise Web-SSO mit SUN OpenSSO Federation-Management Zusammenfassung Gründe für SSO Logins

Mehr

Informations- und Kommunikationstechnologie als Innovationstreiber für Gesundheitswesen und Medizin? Prof. Dr. Herbert Weber September 2007

Informations- und Kommunikationstechnologie als Innovationstreiber für Gesundheitswesen und Medizin? Prof. Dr. Herbert Weber September 2007 Informations- und Kommunikationstechnologie als Innovationstreiber für Gesundheitswesen und Medizin? Prof. Dr. Herbert Weber September 2007 1 Die Wahrnehmung der Patienten Der Umfang und die Qualität der

Mehr

Cloud Computing. Betriebssicherheit von Cloud Umgebungen C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y

Cloud Computing. Betriebssicherheit von Cloud Umgebungen C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y Cloud Computing Betriebssicherheit von Cloud Umgebungen Urs Zumstein Leiter Performance Care Team Urs.Zumstein@DevoTeam.ch 079 639 42 58 Agenda Definition von Cloud Services Anforderungen an die Betriebssicherheit

Mehr

Spring Dynamic Modules for OSGi Service Platforms

Spring Dynamic Modules for OSGi Service Platforms Gerd Wütherich freiberuflicher Softwarearchitekt Spring Dynamic Modules for OSGi Service Platforms Server Anwendungen mit Spring und Eclipse Equinox Agenda OSGi Technologie: OSGi Technologie im Überblick

Mehr

HL7/Sciphox Spezifikationen in Kooperation mit VHitG und KBV für die deutsche ehealth - Plattform

HL7/Sciphox Spezifikationen in Kooperation mit VHitG und KBV für die deutsche ehealth - Plattform Praxis der Informationsverarbeitung in Krankenhaus und Versorgungsnetzen (KIS 2007) 21.-22. Juni 2007 im Heinrich-Pesch-Haus in Ludwigshafen HL7/Sciphox Spezifikationen in Kooperation mit VHitG und KBV

Mehr

Workshop der gematik in Berlin

Workshop der gematik in Berlin Workshop der gematik in Berlin Vorbereitung der Tests der Heil- und Berufsausweise Dr. Jürgen Faltin Dr. Jürgen Faltin Ministerium für Arbeit, Soziales, Gesundheit, Familie und Frauen Rheinland-Pfalz Rechtliche

Mehr

Infrastructure of insurance funds in the context of the electronic health insurance card

Infrastructure of insurance funds in the context of the electronic health insurance card 1 Infrastructure of insurance funds in the context of the electronic health insurance ehealth Conference 2007 From Strategies to Applications April 17th-19th, 2007, Berlin 2 Agenda BKK - We are here Subprocesses

Mehr

Einführung in 802.1x Organisatorische und technische Voraussetzungen Zertifikatsbasierte 802.1x Anwendung in der Praxis

Einführung in 802.1x Organisatorische und technische Voraussetzungen Zertifikatsbasierte 802.1x Anwendung in der Praxis Präsentationen Einführung in 802.1x Organisatorische und technische Voraussetzungen Zertifikatsbasierte 802.1x Anwendung in der Praxis Erfahrungsbericht Wireless 802.1x am USZ Anforderungen des USZ und

Mehr

Vernetzung im Gesundheitswesen. Die häufigsten Fragen zur elektronischen Gesundheitskarte.

Vernetzung im Gesundheitswesen. Die häufigsten Fragen zur elektronischen Gesundheitskarte. Vernetzung im Gesundheitswesen. Die häufigsten Fragen zur elektronischen Gesundheitskarte. 3. Kann ich nicht einfach meine alte Krankenversichertenkarte behalten? Die elektronische Gesundheitskarte ist

Mehr

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

Mehr

Fragen und Antworten zur elektronischen Gesundheitskarte (egk)

Fragen und Antworten zur elektronischen Gesundheitskarte (egk) Fragen und Antworten zur elektronischen Gesundheitskarte (egk) Einführungsphase 1 Wann kommt die elektronische Gesundheitskarte? Die gesetzlichen Krankenkassen beginnen nach intensiven Vorbereitungen ab

Mehr

Workflow, Business Process Management, 4.Teil

Workflow, Business Process Management, 4.Teil Workflow, Business Process Management, 4.Teil 24. Januar 2004 Der vorliegende Text darf für Zwecke der Vorlesung Workflow, Business Process Management des Autors vervielfältigt werden. Eine weitere Nutzung

Mehr

für E-Government-Portale 18.02.2010 Marktforum 3 Portale: Technologien und Konzepte Kurt Maier

für E-Government-Portale 18.02.2010 Marktforum 3 Portale: Technologien und Konzepte Kurt Maier SOA-basierte IT-Sicherheitskomponenten für E-Government-e 18.02.2010 Marktforum 3 e: Technologien und Konzepte Kurt Maier Agenda 1 Anforderungen an Sicherheitslösungen für egovernment-e 2 IT-Sicherheitsarchitektur

Mehr

Elektronischer Zahnarztausweis

Elektronischer Zahnarztausweis Elektronischer Policy Version 1.0 Bundeszahnärztekammer, 17.12.2012 Object-Identifier (OID) 1.2.276.0.76.4.147 2 / 11 AUTOREN: Jochen Gottsmann, BZÄK Dokumentvariablen ÄNDERUNGSHISTORIE Datum Version Autor

Mehr

Java 2, Enterprise Edition Einführung und Überblick

Java 2, Enterprise Edition Einführung und Überblick Universität aiserslautern AG Datenbanken und Informationssysteme Seminar Datenbank-Aspekte des E-Commerce Java 2, Enterprise Edition Einführung und Überblick m_husema@informatik.uni-kl.de Vortragsinhalte

Mehr

Universal Mobile Gateway V4

Universal Mobile Gateway V4 PV-Electronic, Lyss Universal Mobile Gateway V4 Autor: P.Groner Inhaltsverzeichnis Allgemeine Informationen... 3 Copyrightvermerk... 3 Support Informationen... 3 Produkte Support... 3 Allgemein... 4 Definition

Mehr

Web Services. XML, WSDL, SOAP und UDDI Einblicke und Ausblicke. 31.03.2003 J.M.Joller 1

Web Services. XML, WSDL, SOAP und UDDI Einblicke und Ausblicke. 31.03.2003 J.M.Joller 1 Web Services XML, WSDL, SOAP und UDDI Einblicke und Ausblicke 31.03.2003 J.M.Joller 1 Inhalt Architekturen Main Stream.NET J2EE und Applikations-Server Sicht der Anbieter Java J2EE J2EE versus.net Web

Mehr

Thomas Freitag achelos GmbH SmartCard-Workshop. 1 2012 achelos GmbH

Thomas Freitag achelos GmbH SmartCard-Workshop. 1 2012 achelos GmbH Thomas Freitag achelos GmbH SmartCard-Workshop 2012 1 2012 achelos GmbH Übersicht 1. 2. 3. 4. 5. 6. 7. Einführung / Motivation Historie des Testens Schnittstellen im Testbereich Eclipse Plugins Automatisierung,

Mehr

Inhalt I. Blick zurück II. Was sind WebServices? III. Rahmenwerk für edienstleistungen IV. Verwendete WebServices

Inhalt I. Blick zurück II. Was sind WebServices? III. Rahmenwerk für edienstleistungen IV. Verwendete WebServices WebServices Applikationen und Services Ralf Günther Consultant HP Services April, 2003 Ralf.Guenther@hp.com DECUS Symposium 2003, Vortrag 2L06 9.04.2003 Inhalt I. Blick zurück II. Was sind WebServices?

Mehr

IT-Trends Medizin 6. Fachkongress für Informationstechnologien in der Gesundheitswirtschaft

IT-Trends Medizin 6. Fachkongress für Informationstechnologien in der Gesundheitswirtschaft Umsetzung der Telematik in der Modellregion - Test, Massentest, Rollout IT-Trends Medizin 6. Fachkongress für Informationstechnologien in der Gesundheitswirtschaft ursprüngliches Testkonzept der gematik

Mehr

Methode zur Dokumentation der Berechtigungen in der Telematikinfrastruktur

Methode zur Dokumentation der Berechtigungen in der Telematikinfrastruktur Einheitliche Methoden der Informationssicherheit Methode zur Dokumentation der Berechtigungen in der Telematikinfrastruktur Version: 1.1.0 Revision: \main\rel_online\17 Stand: 30.05.2013 Status: freigegeben

Mehr

Secure Messaging. Ihnen? Stephan Wappler IT Security. IT-Sicherheitstag. Sicherheitstag,, Ahaus 16.11.2004

Secure Messaging. Ihnen? Stephan Wappler IT Security. IT-Sicherheitstag. Sicherheitstag,, Ahaus 16.11.2004 Secure Messaging Stephan Wappler IT Security Welche Lösung L passt zu Ihnen? IT-Sicherheitstag Sicherheitstag,, Ahaus 16.11.2004 Agenda Einleitung in die Thematik Secure E-Mail To-End To-Site Zusammenfassung

Mehr

Wiederholung: Beginn

Wiederholung: Beginn B) Webserivces W3C Web Services Architecture Group: "Ein Web Service ist eine durch einen URI eindeutige identifizierte Softwareanwendung, deren Schnittstellen als XML Artefakte definiert, beschrieben

Mehr

UniCard 2.0 / CAPRI. Open Source Software-Lösung für die Kartenproduktion Christof Pohl, IT & Medien Centrum, TU Dortmund

UniCard 2.0 / CAPRI. Open Source Software-Lösung für die Kartenproduktion Christof Pohl, IT & Medien Centrum, TU Dortmund UniCard 2.0 / CAPRI Open Source Software-Lösung für die Kartenproduktion Christof Pohl, IT & Medien Centrum, TU Dortmund Warum UniCard 2.0? Nicht realisierte Funktionen Bezahlfunktion Kopierfunktion E-Ticket

Mehr

Etablierung serviceorientierter Architekturen mit Web Services

Etablierung serviceorientierter Architekturen mit Web Services Etablierung serviceorientierter Architekturen mit Web Services Vorlesung im (Entwicklung von Serviceangeboten) 1 Agenda Einsatzbereiche von Web Service basierten Angeboten Übersicht zur Java-System Application

Mehr

Die neue Welt der Managed Security Services. DI Alexander Graf Antares NetlogiX Netzwerkberatung GmbH

Die neue Welt der Managed Security Services. DI Alexander Graf Antares NetlogiX Netzwerkberatung GmbH Die neue Welt der Managed Security Services DI Alexander Graf Antares NetlogiX Netzwerkberatung GmbH Agenda Über Antares Aktuelle Sicherheitsanforderungen Externe Sicherheitsvorgaben Managed Security Log

Mehr

IAM Area Wer darf was? - Lösungsstrategien für ein erfolgreiches Identity & Access Management

IAM Area Wer darf was? - Lösungsstrategien für ein erfolgreiches Identity & Access Management IAM Area Wer darf was? - Lösungsstrategien für ein erfolgreiches Identity & Access Management Ga-Lam Chang, Peak Solution GmbH, Geschäftsführung und Organisator der IAM Area Ausgangssituation Business

Mehr

Funktionale Spezifikation der OCSP Responder für die PKI der e-arztausweise Version 2.3.2

Funktionale Spezifikation der OCSP Responder für die PKI der e-arztausweise Version 2.3.2 Seite 1 von 9 Funktionale Spezifikation der der e-arztausweise Version Bundesärztekammer, Berlin Identifikation des Dokuments: Funktionale Spezifikation der, Bundesärztekammer Revisions-Datum.: 12.05.2011

Mehr

Private Gesundheitsinformationen im digitalen Zeitalter

Private Gesundheitsinformationen im digitalen Zeitalter Private Gesundheitsinformationen im digitalen Zeitalter http://de.wikipedia.org/wiki/elektronische_gesundheitskarte Ursache Lipobayskandal elektronischen Medikamentenpass http://www.faz.net/aktuell/finanzen/anleihen-zinsen/unternehmensanleihen-wgz-bankraet-von-bayer-anleihen-ab-191783.html

Mehr

... die Zeitschrift der DOAG-Mitglieder. News. Deutsche ORACLE-Anwendergruppe. Grid Computing

... die Zeitschrift der DOAG-Mitglieder. News. Deutsche ORACLE-Anwendergruppe. Grid Computing Deutsche ORACLE-Anwendergruppe News... die Zeitschrift der DOAG-Mitglieder Grid Computing ISSN 0936-0360 www.doag.org Q2/2005 Architektur einer mobilen Swing-Anwendung Autoren: Frank Kohmann, Stefan Götzl,

Mehr

Security for Safety in der Industrieautomation Konzepte und Lösungsansätze des IEC 62443

Security for Safety in der Industrieautomation Konzepte und Lösungsansätze des IEC 62443 Security for Safety in der Industrieautomation Konzepte und Lösungsansätze des IEC 62443 Roadshow INDUSTRIAL IT SECURITY Dr. Thomas Störtkuhl 18. Juni 2013 Folie 1 Agenda Einführung: Standard IEC 62443

Mehr

1. Onlinetests im Projektbüro und in der Arztpraxis. 2. Komponententausch bei den Leistungserbringern. 3. Übersicht BCS-Kartenlesegeräte

1. Onlinetests im Projektbüro und in der Arztpraxis. 2. Komponententausch bei den Leistungserbringern. 3. Übersicht BCS-Kartenlesegeräte NEWSLETTER ARGE SaxMediCard - Testregion Sachsen Ausgabe 6 - August bis Dezember 2009 Seite 1. Onlinetests im Projektbüro und in der Arztpraxis 2 2. Komponententausch bei den Leistungserbringern 2 3. Übersicht

Mehr

OSS/J als Basis für Enterprise Application Integration

OSS/J als Basis für Enterprise Application Integration OSS/J als Basis für Enterprise Application Integration Geschäftsprozessgesteuerte EAI im Telekommunikationsbereich r A business of PwC Agenda OSS-Architekturen als Integrationsherausforderung OSS/J als

Mehr

Neuer Personalausweis und eid-service/server Effiziente Einbindung bei Behörden und Unternehmen

Neuer Personalausweis und eid-service/server Effiziente Einbindung bei Behörden und Unternehmen Neuer Personalausweis und eid-service/server Effiziente Einbindung bei Behörden und Unternehmen Siemens IT Solutions and Services, Hubert Geml npa Einführung Wann realisiere ich was mit wem? Testversion

Mehr

Thema: Web Services. Was ist ein Web Service?

Thema: Web Services. Was ist ein Web Service? Willkommen zum Component Ware Seminar Thema: Achim Grimm & Fabian Unterschütz Folie 1 Was ist ein Web Service? Web Services sind selbstbeschreibende, modulare Softwarekomponenten im Internet, die sich

Mehr

Realisierung der Anbindung an den Handelsplatz Koeln.de Leitfaden zur Projektplanung bei Lieferanten

Realisierung der Anbindung an den Handelsplatz Koeln.de Leitfaden zur Projektplanung bei Lieferanten Handelsplatz Köln.de Leitfaden zur Projektplanung bei en Realisierung der Anbindung an den Handelsplatz Koeln.de Leitfaden zur Projektplanung bei en Autor: Christoph Winkelhage Status: Version 1.0 Datum:

Mehr

Christoph Mathas. SOA intern. » Praxiswissen zu Service-orientierten IT-Systemen HANSER

Christoph Mathas. SOA intern. » Praxiswissen zu Service-orientierten IT-Systemen HANSER Christoph Mathas SOA intern» Praxiswissen zu Service-orientierten IT-Systemen HANSER Inhalt Vorwort XI 1 Einleitung 1 1.1 Wem nützt dieses Buch? 2 1.2 Weshalb dieses Buch? 3 1.3 Die Kapitelstruktur 4 1.4

Mehr

Enterprise Mobility, Live! Pascal Kaufmann, Swisscom IT Services AG 12. Juni 2013

Enterprise Mobility, Live! Pascal Kaufmann, Swisscom IT Services AG 12. Juni 2013 Enterprise Mobility, Live! Pascal Kaufmann, Swisscom IT Services AG 12. Juni 2013 Agenda Mobile Apps aus Sicht der IT Grösste Herausforderungen mobiler Applikationen aus der Sicht der IT Best Practice

Mehr

Spring Dynamic Modules for OSGi Service Platforms

Spring Dynamic Modules for OSGi Service Platforms Gerd Wütherich freiberuflicher Softwarearchitekt Spring Dynamic Modules for OSGi Service Platforms Server Anwendungen mit Spring und Eclipse Equinox Agenda OSGi Technologie: OSGi Technologie im Überblick

Mehr

Next Generation Network oder Die Zukunft der Standortvernetzung

Next Generation Network oder Die Zukunft der Standortvernetzung Next Generation Network oder Die Zukunft der Standortvernetzung Jens Müller, Dipl.-Ing (FH), MSc QSC AG - Managed Services München, Business Partnering Convention 2011 Agenda Standortvernetzung war gestern

Mehr

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131 Architekturen Von der DB basierten zur Multi-Tier Anwendung DB/CRM (C) J.M.Joller 2002 131 Lernziele Sie kennen Design und Architektur Patterns, welche beim Datenbankzugriff in verteilten Systemen verwendet

Mehr

Bes 10 Für ios und Android

Bes 10 Für ios und Android Bes 10 Für ios und Android Architektur einer nicht Container (Sandbox) basierenden MDM Lösung Simple & Secure ios & Android Management mit 10.1.1 Secure Workspace - Sicherer Container für ios und Android

Mehr

Windows Azure Ihre Plattform für professionelles Cloud Computing

Windows Azure Ihre Plattform für professionelles Cloud Computing Windows Azure Ihre Plattform für professionelles Cloud Computing Eine Plattform für Hochverfügbarkeit und maximale Flexibilität und ein Partner, der diese Möglichkeiten für Sie ausschöpft! Microsoft bietet

Mehr

Trend Micro Mobile Mitarbeiter ohne lokale Daten Wie geht das? Safe Mobile Workforce Timo Wege, Technical Consultant

Trend Micro Mobile Mitarbeiter ohne lokale Daten Wie geht das? Safe Mobile Workforce Timo Wege, Technical Consultant Trend Micro Mobile Mitarbeiter ohne lokale Daten Wie geht das? Safe Mobile Workforce Timo Wege, Technical Consultant Eine Kategorie, die es erst seit 6 Jahren gibt, hat bereits den seit 38 Jahren existierenden

Mehr