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

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

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

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

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

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

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

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

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

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

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

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

Einführung der elektronischen Gesundheitskarte Informationsbroschüre G2 Karten

Einführung der elektronischen Gesundheitskarte Informationsbroschüre G2 Karten Einführung der elektronischen Gesundheitskarte Informationsbroschüre G2 Karten Version: 1.0.0 Stand: 23.07.2012 Status: freigegeben Klassifizierung: öffentlich Referenzierung: [geminfo_g2_karten] Autor:

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

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

PROFILE BEI IPV6 HILFEN IM RFC-DSCHUNGEL. Uwe Kaiser, 24. November 2014. Matthias Heyde / Fraunhofer FOKUS

PROFILE BEI IPV6 HILFEN IM RFC-DSCHUNGEL. Uwe Kaiser, 24. November 2014. Matthias Heyde / Fraunhofer FOKUS Matthias Heyde / Fraunhofer FOKUS PROFILE BEI IPV6 HILFEN IM RFC-DSCHUNGEL Uwe Kaiser, 24. November 2014 REFERENZ-RFCS rfc1772 rfc1981 rfc1997 rfc2080 rfc2205 rfc2207 rfc2210 rfc2401 rfc2402 rfc2404 rfc2406

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

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

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

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

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

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

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

Please quote as: Mauro, C.; Schweiger, A.; Sunyaev, A.; Leimeister, J. M. & Krcmar, H. (2007): Single Sign-On Clinic Card-Lösung - Ein Konzept zur

Please quote as: Mauro, C.; Schweiger, A.; Sunyaev, A.; Leimeister, J. M. & Krcmar, H. (2007): Single Sign-On Clinic Card-Lösung - Ein Konzept zur Please quote as: Mauro, C.; Schweiger, A.; Sunyaev, A.; Leimeister, J. M. & Krcmar, H. (2007): Single Sign-On Clinic Card-Lösung - Ein Konzept zur zentralen Verwaltung von Gesundheitskarten im stationären

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

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

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

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

17 Komponentenbasiertes Software-Engineering

17 Komponentenbasiertes Software-Engineering 17 Komponentenbasiertes Software-Engineering 17.0 Einführung Lernziele Grundlagen, Prinzipien und Probleme des CBSE 17.1 Komponenten und Komponentenmodelle Komponenten und ihre Eigenschaften Komponentenmodelle

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

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

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

Was ist Identity Management?

Was ist Identity Management? DECUS IT - Symposium 2005 Andreas Zickner HP Deutschland 2004 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Problem IT Admin Mitarbeiter

Mehr

Sicherheit und Datenschutz in der Cloud

Sicherheit und Datenschutz in der Cloud Sicherheit und Datenschutz in der Cloud Kennen Sie die Herausforderungen der Zukunft? VDE Rhein-Main e.v. Arbeitsgemeinschaft IK Thomas Kochanek Montag, den 24.10.2011 Sicherheit und Datenschutz in der

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

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

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

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

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

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

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

Das Plus an Unternehmenssicherheit

Das Plus an Unternehmenssicherheit Out-of-The-Box Client Security Das Plus an Unternehmenssicherheit ic Compas TrustedDesk Logon+ Rundum geschützt mit sicheren Lösungen für PC-Zugang, Dateiverschlüsselung, Datenkommunikation und Single

Mehr

Elektronische Patientenakten

Elektronische Patientenakten Zentrum für Telematik im Gesundheitswesen GmbH Elektronische Patientenakten Stefan Kühn, Dipl.-Wirt.-Inf. (FH), Projektleiter Ein Projekt des Ministeriums für Arbeit, Gesundheit und Soziales des Landes

Mehr

ecard-api Framework in Deutschland und Europa ecard Strategie der Bundesregierung elektronischer Personalausweis (epa)

ecard-api Framework in Deutschland und Europa ecard Strategie der Bundesregierung elektronischer Personalausweis (epa) ecard-api Framework in Deutschland und Europa ecard Strategie der Bundesregierung elektronischer Personalausweis (epa) ecard-api Framework europäische Perspektive: eid Large Scale Pilot (LSP) Bundesamt

Mehr

TRESOR Sichere Cloud Infrastruktur für das Gesundheitswesen. Abschlussveranstaltung Trusted Cloud 10./11.02.2015

TRESOR Sichere Cloud Infrastruktur für das Gesundheitswesen. Abschlussveranstaltung Trusted Cloud 10./11.02.2015 TRESOR Sichere Cloud Infrastruktur für das Gesundheitswesen Abschlussveranstaltung Trusted Cloud 10./11.02.2015 TRESOR: Zielsetzung TRusted Ecosystem for Standardized and Open cloud based Resources Trusted

Mehr

Grundlagen des Grid Computing

Grundlagen des Grid Computing Grundlagen des Grid Computing Webservices und Grid Computing Globus Toolkit 4 - Grundlagen ICA Joh.. Kepler Universität t Linz Eine Typische Grid-Applikation (Beispiel) VO Management Service Resource Discovery

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

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

HOBLink VPN. HOBLink VPN & Produktionsumgebung- / Steuerung

HOBLink VPN. HOBLink VPN & Produktionsumgebung- / Steuerung HOBLink VPN HOBLink VPN & Produktionsumgebung- / Steuerung 3-rd Party Services an Produktionsanlagen mit HOBlink VPN Erreichbarkeit von Systemen mit embedded software Industrie-Roboter Alarmanlagen Produktionsbändern

Mehr

Inhaltsverzeichnis Vorwort Konzepte des Active Directory

Inhaltsverzeichnis Vorwort Konzepte des Active Directory Vorwort.................................................................. XI Warum dieses Buch.................................................... XI Kapitelübersicht.......................................................

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

nachfolgende Vereinbarung zum Inhalt und zur Anwendung der elektronischen Gesundheitskarte

nachfolgende Vereinbarung zum Inhalt und zur Anwendung der elektronischen Gesundheitskarte Vereinbarung zum Inhalt und zur Anwendung der elektronischen Gesundheitskarte Stand: 1. Januar 2015 Zwischen dem GKV-Spitzenverband (Spitzenverband Bund der Krankenkassen) K.d.ö.R, Berlin und der Kassenärztlichen

Mehr

Hochschule Prof. Dr. Martin Leischner Bonn-Rhein-Sieg Netzwerksysteme und TK Modul 7: SNMPv3 Netzmanagement Folie 1

Hochschule Prof. Dr. Martin Leischner Bonn-Rhein-Sieg Netzwerksysteme und TK Modul 7: SNMPv3 Netzmanagement Folie 1 Modul 7: SNMPv3 18.06.2014 14:42:33 M. Leischner Netzmanagement Folie 1 SNMP-Versionen Party-Based SNMP Version 2 (SNMPv2p) User-Based SNMP Version 2 (SNMPv2u) SNMP Version 3 1988 1989 1990 1991 1992 1993

Mehr

Ingo Schubert Technical Consultant Central Europe +49 89 540 523-01 ischubert@baltimore.com

Ingo Schubert Technical Consultant Central Europe +49 89 540 523-01 ischubert@baltimore.com 1 Ingo Schubert Technical Consultant Central Europe +49 89 540 523-01 ischubert@baltimore.com 2 Baltimore auf einen Blick Weltmarktführer für e security Produkte, Service, und Lösungen Weltweite Niederlassungen

Mehr

Sun ONE. Sun Open Net Environment. Architektur für Web-Services on Demand. Dr. Rainer Eschrich rainer.eschrich@sun.com

Sun ONE. Sun Open Net Environment. Architektur für Web-Services on Demand. Dr. Rainer Eschrich rainer.eschrich@sun.com Sun ONE Sun Open Net Environment Dr. Rainer Eschrich rainer.eschrich@sun.com Architektur für Web-Services on Demand Sun ONE Vision Wie kann Software dem Kunden helfen? Kostenreduktion: Wie? In dem man

Mehr

Interoperabilität elektronischer Aktensysteme

Interoperabilität elektronischer Aktensysteme Interoperabilität elektronischer Aktensysteme Nürnberger Archivtage 2014 Dr. Ralf Brandner Anwendungsfälle Datenaustausch auf Basis von Aktensystemen Archivierung Konsil Befundung Fallbesprechung Überweisung

Mehr

Kurzeinführung VPN. Veranstaltung. Rechnernetze II

Kurzeinführung VPN. Veranstaltung. Rechnernetze II Kurzeinführung VPN Veranstaltung Rechnernetze II Übersicht Was bedeutet VPN? VPN Typen VPN Anforderungen Was sind VPNs? Virtuelles Privates Netzwerk Mehrere entfernte lokale Netzwerke werden wie ein zusammenhängendes

Mehr

Kompetenz der GAIN-Gruppe im Gesundheitswesen. Kompetenz der GAIN-Gruppe im Gesundheitswesen 1

Kompetenz der GAIN-Gruppe im Gesundheitswesen. Kompetenz der GAIN-Gruppe im Gesundheitswesen 1 Kompetenz der GAIN-Gruppe im Gesundheitswesen Kompetenz der GAIN-Gruppe im Gesundheitswesen 1 bis 2005: Arbeiten überwiegend im Kostenträgerumfeld Entwicklung einer Software für den Außendienst (Akquisition

Mehr

Informationen für Kunden zur Anbindung an die Systeme von SIX Financial Information. Juli 2013

Informationen für Kunden zur Anbindung an die Systeme von SIX Financial Information. Juli 2013 Informationen für Kunden zur Anbindung an die Systeme von SIX Financial Information Juli 2013 Inhalt 1 Einleitung 3 2 Anbindungsmöglichkeiten 4 2.1 Übersicht 4 2.2 IP VPN über MPLS 5 2.2.1 Anschluss in

Mehr

Diameter. KM-/VS-Seminar. Wintersemester 2002/2003. schulze_diameter.ppt Christian Schulze_03-Februar-07

Diameter. KM-/VS-Seminar. Wintersemester 2002/2003. schulze_diameter.ppt Christian Schulze_03-Februar-07 Diameter KM-/VS-Seminar Wintersemester 2002/2003 Betreuer: Martin Gutbrod 1 Übersicht Einleitung AAA Szenarien Remote dial-in Mobile dial-in Mobile telephony Design von Diameter Ausblick Features Protokoll

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

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

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen Daniel Liebhart SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen ISBN-10: 3-446-41088-0 ISBN-13: 978-3-446-41088-6 Inhaltsverzeichnis Weitere Informationen oder Bestellungen

Mehr

WINDOWS APPLIKATIONEN UNTER LINUX/UNIX SECURE REMOTE ACCESS

WINDOWS APPLIKATIONEN UNTER LINUX/UNIX SECURE REMOTE ACCESS WINDOWS APPLIKATIONEN UNTER LINUX/UNIX SECURE REMOTE ACCESS Dipl.-Ing. Swen Baumann Produktmanager, HOB GmbH & Co. KG April 2005 Historie 2004 40 Jahre HOB Es begann mit Mainframes dann kamen die PCs das

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

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

Workflow Management: Workflow (1)

Workflow Management: Workflow (1) Workflow Management: Workflow (1) Abgrenzung: Geschäftsprozeß Vorgang (Aktivität) Arbeitsablauf (Workflow) Arbeitsschritt (Work Item) Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut

Mehr

Hybride Cloud Datacenters

Hybride Cloud Datacenters Hybride Cloud Datacenters Enterprise und KMU Kunden Daniel Jossen Geschäftsführer (CEO) dipl. Ing. Informatik FH, MAS IT Network Amanox Solutions Unsere Vision Wir planen und implementieren für unsere

Mehr

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition Inhaltsverzeichnis Vorwort 13 I Enterprise Java im Überblick 1 Bedeutung von Enterprise Java und IBM WebSphere 21 1.1 Enterprise Java 23 1.1.1 Anforderungen 23 1.1.2 E-Business 30 1.1.3 Java 36 1.2 IBM

Mehr

H A R D U N D S O F T W A R E A N F O R D E R U N G E N F Ü R E I N W O H N E R - U N D A U S L Ä N D E R V E R F A H R E N

H A R D U N D S O F T W A R E A N F O R D E R U N G E N F Ü R E I N W O H N E R - U N D A U S L Ä N D E R V E R F A H R E N H A R D U N D S O F T W A R E A N F O R D E R U N G E N F Ü R E I N W O H N E R - U N D A U S L Ä N D E R V E R F A H R E N Anforderungen an die IT-Ausstattung der Arbeitsplätze für die Beantragung und

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

Information der Landesärztekammer Brandenburg zum earztausweis Beantragung und Herausgabe des elektronischen Arztausweises

Information der Landesärztekammer Brandenburg zum earztausweis Beantragung und Herausgabe des elektronischen Arztausweises Information der zum earztausweis Beantragung und Herausgabe des elektronischen Arztausweises Aktuelle Rahmenbedingungen zum earztausweis 1. Zurzeit können elektronische Arztausweise der Generation 0 produziert

Mehr

Anwendung Rechnernetze. 7.Semester INF - WS 2005/2006 Vorstellung der Projekte (Prof. Dr. Uwe Heuert)

Anwendung Rechnernetze. 7.Semester INF - WS 2005/2006 Vorstellung der Projekte (Prof. Dr. Uwe Heuert) Anwendung Rechnernetze 7.Semester INF - WS 2005/2006 Vorstellung der Projekte (Prof. Dr. Uwe Heuert) Übersicht Schwerpunkte Netzwerk Microsoft.NET Dienste und Enterprise Computing Sicherheit Praktikum

Mehr

SAP NetWeaver Gateway. Connectivity@SNAP 2013

SAP NetWeaver Gateway. Connectivity@SNAP 2013 SAP NetWeaver Gateway Connectivity@SNAP 2013 Neue Wege im Unternehmen Neue Geräte und Usererfahrungen Technische Innovationen in Unternehmen Wachsende Gemeinschaft an Entwicklern Ausdehnung der Geschäftsdaten

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

Multizentrische, bildbasierte klinische Forschung. PACS & mehr, 20.06.2013 Johannes Stemmer

Multizentrische, bildbasierte klinische Forschung. PACS & mehr, 20.06.2013 Johannes Stemmer PACS & mehr, Johannes Stemmer Die biomedizinische Forschungslandschaft Wissenschaft Universitäten Kliniken Forschungseinrichtungen Max-Planck Helmholtz DLR Fraunhofer Industrie Pharmaindustrie Medizingerätehersteller

Mehr

Vorlesung. Informationssysteme. Prof. Dr. Hans Czap. Lehrstuhl für Wirtschaftsinformatik I. Email: Hans.Czap@uni-trier.de

Vorlesung. Informationssysteme. Prof. Dr. Hans Czap. Lehrstuhl für Wirtschaftsinformatik I. Email: Hans.Czap@uni-trier.de Vorlesung Grundlagen betrieblicher Informationssysteme Prof. Dr. Hans Czap Email: Hans.Czap@uni-trier.de - II - 1 - Inhalt Kap. 1 Ziele der Datenbanktheorie Kap. 2 Datenmodellierung und Datenbankentwurf

Mehr

Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim

Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim Sven Hartlieb Cloud-Computing Seminar Hochschule Mannheim WS0910 1/23 Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim Sven Hartlieb Fakultät für Informatik Hochschule

Mehr

Fujitsu BeanConnect TM V3.0 Software 0 FUJITSU LIMITED 2013

Fujitsu BeanConnect TM V3.0 Software 0 FUJITSU LIMITED 2013 Fujitsu BeanConnect TM V3.0 Software 0 FUJITSU LIMITED 2013 Die Herausforderung: Hostanbindung Viele Unternehmen besitzen Mainframe- und Legacy-Anwendungen, so genannte Enterprise Information Systems (EIS),

Mehr

Entscheiderfabrik 2015. Software as a Service (SaaS)! als neues IT Modell, um integrierte Versorgungslösungen

Entscheiderfabrik 2015. Software as a Service (SaaS)! als neues IT Modell, um integrierte Versorgungslösungen Entscheiderfabrik 2015! Software as a Service (SaaS)! als neues IT Modell, um integrierte Versorgungslösungen! am Beispiel der Überleitung Akut-/ Reha-Versorgung effizient umzusetzen! ider-event 2015 orf,

Mehr

Oliver Olbrich Das ebxml Projekt Entstand 1999 in einer gemeinsamen Initiative von OASIS (Organisation for the Advancement of Structured Information Standards) und UN/CEAFACT (United Nations Center for

Mehr

Portal for ArcGIS - Eine Einführung

Portal for ArcGIS - Eine Einführung 2013 Europe, Middle East, and Africa User Conference October 23-25 Munich, Germany Portal for ArcGIS - Eine Einführung Dr. Gerd van de Sand Dr. Markus Hoffmann Einsatz Portal for ArcGIS Agenda ArcGIS Plattform

Mehr

ECOS Technology GmbH Moderne Telearbeitsplätze

ECOS Technology GmbH Moderne Telearbeitsplätze ECOS Technology GmbH Moderne Telearbeitsplätze Machen Sie es einfach - aber sicher! von René Rühl Teamleiter Vertrieb ECOS Technology GmbH in Zusammenarbeit mit Über ECOS Technology Bestehen Seit 1983

Mehr

Bestätigung für technische Komponenten gemäß 14 (4) Gesetz zur digitalen Signatur und 16 und 17 Signaturverordnung

Bestätigung für technische Komponenten gemäß 14 (4) Gesetz zur digitalen Signatur und 16 und 17 Signaturverordnung Bestätigung für technische Komponenten gemäß 14 (4) Gesetz zur digitalen Signatur und 16 und 17 Signaturverordnung debis Systemhaus Information Security Services GmbH - Zertifizierungsstelle debiszert-

Mehr

Theorie und Praxis einer JSON-RPC-basierten Web-API

Theorie und Praxis einer JSON-RPC-basierten Web-API Theorie und Praxis einer JSON-RPC-basierten Web-API Christian Krause Christian.Krause@raritan.com Raritan Deutschland GmbH Chemnitzer LinuxTage 2015 Gliederung 1 2 Remote Procedure Call Interface Definition

Mehr

Behandlungsunterstützung mittels App. Lars Erdmann, Partner, Q_PERIOR AG SAP Mobile Forum, 17. April 2013

Behandlungsunterstützung mittels App. Lars Erdmann, Partner, Q_PERIOR AG SAP Mobile Forum, 17. April 2013 Behandlungsunterstützung mittels App Lars Erdmann, Partner, Q_PERIOR AG SAP Mobile Forum, 17. April 2013 Agenda Hintergrund Warum eine mobile Lösung? Lösungsansatz Was sind die Vorteile? Technische Umsetzung

Mehr

Virtual Private Networks. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH

Virtual Private Networks. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Virtual Private Networks Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Inhalt Einleitung Grundlagen Kryptographie IPSec Firewall Point-to-Point Tunnel Protokoll Layer 2 Tunnel Protokoll Secure Shell

Mehr

Gültigkeitsmodell der elektronischen Arztausweise und Laufzeit der Zertifikate

Gültigkeitsmodell der elektronischen Arztausweise und Laufzeit der Zertifikate Seite 1 von 6 Autor: G. Raptis Gültigkeitsmodell der elektronischen Arztausweise und Laufzeit der Zertifikate Gültigkeitsmodelle beschreiben den Algorithmus nach dem ein Client oder Dienst entscheidet,

Mehr

Elektronische Gewerbemeldung

Elektronische Gewerbemeldung E-Government in der IHK-Organisation Elektronische Gewerbemeldung Arbeitshilfe für die Prozess-Implementierung: Technische Rahmenbedingungen für die Anlieferung von Gewerbemeldungen an die IHK-Organisation

Mehr

Notfalldaten und Datenerhalt mit der elektronischen Gesundheitskarte

Notfalldaten und Datenerhalt mit der elektronischen Gesundheitskarte Notfalldaten und Datenerhalt mit der elektronischen Gesundheitskarte Smartcard-Workshop Darmstadt, 9. Februar 2012 Georgios Raptis Bundesärztekammer Notfalldatensatz auf der egk 2003 291a SGB V die egk

Mehr

Programmierhandbuch SAP NetWeaver* Sicherheit

Programmierhandbuch SAP NetWeaver* Sicherheit Martin Raepple Programmierhandbuch SAP NetWeaver* Sicherheit Galileo Press Bonn Boston Inhalt Vorwort 13 2.1 Sicherheit und serviceorientierte Architekturen 24 2.1.1 Sicherheitsziele der Informationssicherheit

Mehr

HYPERCOM MEDHYBRID EINRICHTUNG UNTER CHREMASOFT

HYPERCOM MEDHYBRID EINRICHTUNG UNTER CHREMASOFT HYPERCOM MEDHYBRID EINRICHTUNG UNTER CHREMASOFT 13. OKTOBER 2011 EINLEITUNG Beim Gesundheitskartenterminal medhybrid handelt es sich um ein Kombigerät, das neben der Verarbeitung der Krankenversichertenkarte

Mehr

Basistechnologien: Web-Services

Basistechnologien: Web-Services Alexander Rudolf Cloud-Computing Seminar Hochschule Mannheim WS0910 1/29 Basistechnologien: Web-Services Alexander Rudolf Hochschule Mannheim Fakultät für Informatik alexander.rudolf@stud.hs-mannheim.de

Mehr

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Ziele Common Object Request Broker Architecture CORBA Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Object Management Group Spezifiziert den CORBA-Standard

Mehr

Open Source und Sicherheit

Open Source und Sicherheit Open Source und Sicherheit Jochen Bauer Inside Security IT Consulting GmbH Nobelstraße 15 70569 Stuttgart info@inside-security.de Open Source und Sicherheit 1 Passive und aktive Sicherheit oder: Sicherheit

Mehr

Internet Information Services v6.0

Internet Information Services v6.0 Internet Information Services v6.0 IIS History Evolution von IIS: V1.0 kostenlos auf der CeBit 1996 verteilt V2.0 Teil von Windows NT 4.0 V3.0 Als Update in SP3 von NT4.0 integriert V4.0 Windows NT 4.0

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

Softwaregestütztes Einwilligungsmanagement

Softwaregestütztes Einwilligungsmanagement Softwaregestütztes Einwilligungsmanagement Vom Konzept zum Prototyp Berlin, 24. März 2010 Markus BIRKLE, Oliver Heinze, Lennart Köster, Björn Bergh Sektion Medizinische Informationssysteme Agenda Begriffsbestimmung

Mehr

Migration einer bestehenden Umgebung in eine private Cloud mit OpenStack

Migration einer bestehenden Umgebung in eine private Cloud mit OpenStack Migration einer bestehenden Umgebung in eine private Cloud mit OpenStack CeBIT 2014 14. März 2014 André Nähring Cloud Computing Solution Architect naehring@b1-systems.de - Linux/Open Source Consulting,

Mehr

Integration mobiler Endgeräte in Medizinprodukte und Medizintechnik-nahe Produkte

Integration mobiler Endgeräte in Medizinprodukte und Medizintechnik-nahe Produkte Integration mobiler Endgeräte in Medizinprodukte und Medizintechnik-nahe Produkte Agenda Problemstellung Medizinprodukt App Grundlagen Szenarien (Problemstellungen und Lösungsansätze) 03.06.2013 2 Innovationen

Mehr