Erarbeitung einer Strategie zur Einführung der...

© 2004 Projektgruppe bIT4health Seite 1 von 25

Erarbeitung einer Strategie zur Einführung der Gesundheitskarte Existierende Anwendungslandschaften

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.1 vom 12. August 2004

Autoren:

Thomas Liebscher (ICW)

Torsten Müller (IBM)

Stefan Ocke (ICW)


Inhaltsverzeichnis

0 Allgemeines ___________________________________________4

0.1 Änderungsübersicht ________________________________________________4

0.2 Abkürzungsverzeichnis _____________________________________________4

0.3 Referenzierte Dokumente ____________________________________________6

0.4 Glossar ___________________________________________________________6

0.5 Abbildungsverzeichnis ______________________________________________6

0.6 Tabellenverzeichnis_________________________________________________6

1 Zweck des Dokuments __________________________________7

1.1 Ziele des Dokuments________________________________________________7

1.2 Inhalt und Dokumentenstruktur _______________________________________7

1.3 Einordnung in die Rahmenarchitektur__________________________________8

2 Zusammenfassung ____________________________________10

2.1 Ansatz und methodische Vorgehensweise_____________________________10

2.2 Ergebnisse _______________________________________________________10

3 Einführung ___________________________________________12

3.1 Betrachtete Themenfelder __________________________________________12

3.2 Abgrenzung ______________________________________________________12

3.3 Erhebung der Informationen ________________________________________12

3.4 Vorgehensweise zur Analyse ________________________________________12

4 Analyse der erhobenen Informationen ____________________13

4.1 Apothekensoftware (APO) __________________________________________13 4.1.1 Stärken ____________________________________________________________ 13 4.1.2 Schwächen _________________________________________________________ 13 4.1.3 Chancen/Möglichkeiten ________________________________________________ 14 4.1.4 Risiken_____________________________________________________________ 14

4.2 Krankenhaus-Informations-Systeme (KIS) _____________________________14 4.2.1 Stärken ____________________________________________________________ 14 4.2.2 Schwächen _________________________________________________________ 15 4.2.3 Chancen/Möglichkeiten ________________________________________________ 15 4.2.4 Risiken_____________________________________________________________ 15

4.3 Praxisverwaltungssoftware (PVS) ____________________________________16 4.3.1 Stärken ____________________________________________________________ 16


4.3.2 Schwächen _________________________________________________________ 16 4.3.3 Chancen/Möglichkeiten ________________________________________________ 16 4.3.4 Risiken_____________________________________________________________ 17

4.4 Krankenkassen (KK) _______________________________________________17 4.4.1 Stärken ____________________________________________________________ 17 4.4.2 Schwächen _________________________________________________________ 17 4.4.3 Chancen/Möglichkeiten ________________________________________________ 17 4.4.4 Risiken_____________________________________________________________ 17

4.5 Kartenhersteller/Trust-Center (TC) ___________________________________18 4.5.1 Stärken ____________________________________________________________ 18 4.5.2 Schwächen _________________________________________________________ 18 4.5.3 Chancen/Möglichkeiten ________________________________________________ 18 4.5.4 Risiken_____________________________________________________________ 18

5 Schlussfolgerungen____________________________________19

5.1 Kernaussagen ____________________________________________________19

5.2 Einordnung und Bewertung _________________________________________23


0 Allgemeines

0.1 Änderungsübersicht

Version Datum Seite Bemerkungen Bearbeiter

1.0 22.03.04

Erste Version Thomas Liebscher (ICW), Stefan Ocke (ICW)

1.1 12.08.04

Überarbeitete Version aufgrund der öf-fentlichen Kommentierung

Torsten Müller (IBM), Christoph Altenhofen (IAO)

0.2 Abkürzungsverzeichnis ABDA Bundesvereinigung Deutscher Apothekerverbände

ADT Abrechnungs Daten Träger (Standard der KBV. Kann je nach Kontext auch Abrechnungs Daten Transfer heißen.)

APO Apotheken bzw. Apotheken-Software BDT Behandlungsdatenträgertransfer (Der xDT-Standard für Übertragung

von medizinischen und administrativen Behandlungsdaten. Kann je nach Kontext auch Behandlungs Daten Träger heißen.)

BG-Abrechnung Berufsgenossenschaftliche Abrechnung CORBA Common Object Request Broker Architecture DALE-UV Datenaustausch mit Leistungserbringern in der gesetzlichen Un-

fallversicherung DICOM Digital Imaging and Communications in Medicine

Standard für den Austausch von Bilddaten zwischen bildverarbeitenden Systemen in der Medizin

DKG Deutsche Krankenhausgesellschaft DMP Disease Management Programme DRG Diagnosis Related Groups DTA-Abrechnung Abrechnung per Datenträgeraustausch zwischen Arzt und KV, s.a.

KVDT EBM Einheitlicher Bewertungsmaßstab (Auf der Grundlage von § 87 Absatz 1

SGB V zwischen der KBV und den Spitzenverbänden der Krankenkas-sen im Bewertungsausschuss vereinbarte Abrechnungsgrundlage)

EDIFACT Electronic Data Interchange For Administration, Commerce and Trans-port Standard für elektronischen Austausch von Handelsdokumenten und


Geschäftsnachrichten FTP File Transfer Protocol GDT Gerätedatentransfer (Der xDT-Standard für systemunabhängigen Da-

tentransfer zwischen Praxis-EDV Systemen und Messgeräten. Kann je nach Kontext auch Geräte Daten Träger heißen.)

GKV Gesetzliche Krankenversicherung GOÄ Gebührenordnung für Ärzte HL7 Health Level 7 (Internationaler Standard für den Datenaustausch im

klinischen Umfeld) HPC Health Professional Card (Heilberufsausweis) HTTP Hypertext Transfer Protocol ICD International Classification of Diseases

Internationaler Standard zur Klassifikation von Krankheiten, liegt mitt-lerweile in Version 10 vor (ICD10)

J2EE Java 2 Platform, Enterprise Edition (J2EE) JDK Java Development Kit KBV Kassenärztliche Bundesvereinigung KIS Krankenhausinformationssysteme KV Kassenärztliche Vereinigung KVDT Der xDT-Standard für einheitlichen Datenaustausch zwischen Arztpraxis

und Kassenärztlicher Vereinigung. KVK Krankenversichertenkarte KZV Kassenzahnärztliche Vereinigung LDT Labordatentransfer (Der xDT-Standard für die Übermittlung von Labor-

daten. Kann je nach Kontext auch Labor Daten Träger heißen.) MKT Multifunktionales Kartenterminal OEP Object Engineering Process OPS-301 Operationen- und Prozedurenschlüssel nach § 301 SGB V PKCS Public-Key Cryptography Standards

PKV Private Krankenversicherung PTA Pharmazeutisch-Technischer Assistent PVS Praxisverwaltungssystem RIM Reference Information Model (Referenzmodell von HL7 Version 3)

RM-ODP Reference Model for Open Distributed Processing SAGA Standards und Architekturen für eGovernment-Anwendungen des Bun-

desministerium des Innnern SGB V Sozialgesetzbuch, 5. Buch


SOAP Standard für die Kommunikation innerhalb der WEB-Services (ursprüng-lich hervorgegangen aus der Bezeichnung‚ Simple Object Access Pro-tocol’, welche aus der Spezifikation entfernt wurde)

SSL Secure Sockets Layer SW Software VCS VDAP Communication Standard (Industrie-Standard für die

sichere elektronische Kommunikation zwischen Einrichtungen im Gesundheitswesen)

VDAP Verband Deutscher Arztpraxis-Softwarehersteller eV VDDS Verband Deutscher Dental-Software Unternehmen VPN Virtual Private Network XDT Oberbegriff für die verschiedenen, auf dem ADT-Format (Abrechnungs-

DatenTransfer) basierenden Standards der KBV

0.3 Referenzierte Dokumente Alle referenzierten Dokumente werden in den gemeinsamen Projektreferenzen [b4hReferenzen] geführt.

0.4 Glossar Alle Glossareinträge werden im gemeinsamen Projektglossar [b4hGlossar] geführt.

0.5 Abbildungsverzeichnis Abbildung 1: Dokumente und ihre Beziehungen__________________________________________ 8

0.6 Tabellenverzeichnis Tabelle 1: Zusammenfassung der Kernaussagen _______________________________________ 24

Tabelle 2: Bewertung und Einordnung der Kernaussagen _________________________________ 25


1 Zweck des Dokuments

Das Gesetz zur Modernisierung der Gesetzlichen Krankenversicherung (GKV-Modernisierungsgesetz) [GMG], mit dem diverse Gesetze aus dem Bereich der gesetzlichen Krankenversicherung (bspw. SGB V) geändert wurden, schreibt die Einführung einer Infor-mations-, Kommunikations- und Sicherheitsinfrastruktur, die den Einsatz der elektronischen Gesundheitskarte ermöglicht, vor. Notwendige Voraussetzung für die Schaffung einer einheitlichen Telematikinfrastruktur ist die Definition einer verbindlichen Rahmenarchitektur, die als Leitlinie für die Beteiligten im Ge-sundheitswesen und den zuliefernden IT-Firmen akzeptiert wird. Diese ermöglicht insbeson-dere die Interoperabilität zwischen medizinischen Informations- und Kommunikationssyste-men und die Entwicklung einer verlässlichen und gemeinsamen Sicherheitsinfrastruktur. Ein wesentliches Kennzeichen der zu erstellenden Rahmenarchitektur ist dabei ihre Genera-lisierbarkeit, die dadurch – abweichend von einer spezifischen Lösungsarchitektur – Ände-rungen und Erweiterungen der Modelle unabhängig von herstellerspezifischen Anwendun-gen, zulässt.

1.1 Ziele des Dokuments Ziel dieses Dokuments ist es, einen Überblick über bestehende Anwendungslandschaften im Gesundheitswesen zu geben. Die Vielschichtigkeit der bestehenden Anwendungslandschaf-ten und der Fokus auf eine Rahmenarchitektur erfordern eine konsolidierte Aufstellung der wesentlichen Merkmale. Somit liegt die Ausrichtung des Dokuments nicht in einer detaillier-ten Beschreibung, sondern in der Ableitung genereller Aussagen, welche die bestehenden Anwendungslandschaften beschreiben. Eine erfolgreiche Entwicklung und Einführung der Telematikinfrastruktur erfordert die Berücksichtigung dieser Kernaussagen bei der Erstellung der Rahmenarchitektur

1.2 Inhalt und Dokumentenstruktur Im ersten Teil des Dokuments werden die Erkenntnisse aus Marktbefragungen und Workshops mit verschiedenen Systemherstellern und Integratoren zusammengefasst. Die Erfassung und Darstellung der Informationen erfolgt sortiert nach den Sektoren Apotheken, Kliniken, niedergelassene Ärzte und Krankenkassen. Zur besseren Strukturierung der zahl-reichen Aussagen und Informationen werden diese je Sektor in die Dimensionen einer SWOT-Analyse (Stärken/ Schwächen/ Chancen/ Risiken) eingeordnet. Im zweiten Teil des Dokuments werden aus den konsolidierten Informationen kurze Kern-aussagen abgeleitet. Für jede dieser Kernaussagen ergeben sich verschiedene Schlussfol-gerungen hinsichtlich der Entwicklung und Einführung der Telematikinfrastruktur. Am Ende des Dokuments fasst eine tabellarische Übersicht in Kapitel 5 die in den Schluss-folgerungen enthaltenen Auswirkungen auf die Rahmenarchitektur zusammen. Somit lassen sich für jede Kernaussage die Beeinflussung bestimmter Teilbereiche der Rahmenarchitektur in Abhängigkeit des betroffenen Sektors ablesen. Das Dokument soll mit den getroffenen Aussagen und Schlussfolgerungen die Ableitung von Anforderungen an die Rahmenarchitektur unterstützen und hat einen informativen Charakter.


Dabei handelt es sich ausschließlich um eine Ist-Analyse auf abstraktem Niveau. Es werden keine Empfehlungen für zu ergreifende Maßnahmen oder Architekturen gegeben. .

1.3 Einordnung in die Rahmenarchitektur Die nachfolgende Graphik stellt die Beziehungen der Dokumente untereinander dar. Dabei bedeuten die Pfeile eine Beeinflussung der Dokumente untereinander. Insofern ergibt sich eine natürliche Lese-Reihenfolge entlang der Pfeilrichtungen.

Geschäfts-prozess-Modell


Use CaseModell

Use CaseModell

Existierende Anwendungs-landschaften


Komponenten-modell

Komponenten-modell

Standards und Initiativen im

Gesundheitswesen


Gesundheitswesen

Informations-modell

Informations-modell

Operationales Modell


Migrations-aspekte

Migrations-aspekte

Sicherheits-anforderungen

Sicherheits-anforderungenNichtfunktionale

Anforderungen

Nichtfunktionale Anforderungen

Sicherheits-Architektur


Pflichtenheft eGK

Pflichtenheft eGK



Use CaseModell

Use CaseModell



Komponenten-modell

Komponenten-modell


Gesundheitswesen


Gesundheitswesen

Informations-modell

Informations-modell



Migrations-aspekte

Migrations-aspekte

Sicherheits-anforderungen

Sicherheits-anforderungenNichtfunktionale

Anforderungen

Nichtfunktionale Anforderungen



Pflichtenheft eGK

Pflichtenheft eGK

Abbildung 1: Dokumente und ihre Beziehungen

In der Graphik können natürlich nicht alle Abhängigkeiten hinsichtlich der Einbindung der bestehenden Anwendungslandschaften in die Dokumentenstruktur aufgezeigt werden. So haben die bestehenden Anwendungslandschaften Auswirkungen auf die Gestaltung zukünf-tiger Prozesse, Organisationen, Anwendungen, Daten, Infrastrukturen sowie Sicherheits- und Migrationsaspekte. Eine Identifikation der Relevanz des Einflusses der Kernaussagen hinsichtlich dieser Sichten auf die Architektur wird in Tabelle 2 gegeben. Dies erleichtert die Einbindung der Kernaus-sagen in die einzelnen Dokumente, welche ebendiese verschiedenen Sichten auf die Archi-tektur beschreiben.


In den einzelnen Dokumenten (z.B. Use Cases [b4hUseCaseI], [b4hUseCaseII], Migration-saspekte [b4hMigr] oder Operationales Modell [b4hOpMod]) werden die Kernaussagen zu den bestehenden Anwendungslandschaften bei der Ableitung der Architekturdefinition be-rücksichtigt. Für die eindeutige Referenzierung einer Kernaussage wird das Kürzel ALKA (Anwendungs-landschaften Kernaussage), gefolgt von der Nummer der Kernaussage, verwendet. Für die zukünftige Detaillierung der Architektur in einer Lösungsarchitektur und Ableitung der konkreten Migrations- und Einführungsschritte ist eine sektorbezogene Detaillierung der Ist-Aufnahme erforderlich. Die vorliegende Dokumentation erleichtert im Zusammenhang mit der Architekturbeschreibung die Identifikation der Schwerpunkte für diese notwendige Detaillie-rung der Ist-Aufnahme.


2 Zusammenfassung

2.1 Ansatz und methodische Vorgehensweise Das vorliegende Dokument der existierenden Anwendungslandschaften beinhaltet eine Übersicht über die zahlreichen vorhandenen Anwendungen, Infrastrukturen sowie telema-tikrelevanten Technologien und Lösungen innerhalb des Gesundheitswesens. Branchen-erfahrung und Ergebnisse verschiedener Workshops mit Industrievertretern wurden in einer Stärken/Schwächen/Möglichkeiten/Gefahren-Analyse (SWOT) konsolidiert und die für die Architektur und Migration relevanten Kernaussagen und spezifischen Schlussfolgerungen abgeleitet.

2.2 Ergebnisse Die existierende Anwendungslandschaft im Gesundheitswesen ist stark zersplittert und wird in den einzelnen Sektoren durch eine große Zahl von Systemanbietern erstellt und betreut. So gibt es ca. 150 Anbieter für Praxisverwaltungssysteme, 25 für Apotheken-Software und 12 für Krankenhausinformationssysteme. Es besteht kaum eine Integration der Systeme zwischen den Sektoren (Apotheken, Praxen, Krankenkassen, Krankenhäuser) - aber auch innerhalb der Sektoren ist sie nicht flächen-deckend vorhanden. Dies hat seine Ursache einerseits in mangelnder Standardisierung und in der Heterogenität der Systeme, andererseits in der Fokussierung der Anwender und An-bieter auf den eigenen Bereich der Software, welche zur mangelnden Bereitschaft zum Da-tenaustausch mit anderen Systemen führt. Hinzu kommt, dass es bisher nur begrenzt Anrei-ze für eine sektorenübergreifende elektronische Integration der Systeme gab. Die Anforderungen der Apotheken und Praxen sind sehr an der Effizienz der Anwendungen orientiert. Internetlösungen konnten sich bisher kaum durchsetzen, wodurch praktische Er-fahrung hinsichtlich der notwendigen Sicherheitsaspekte und möglicher Sicherheitstechnolo-gien fehlt. Somit besitzen auch die Anbieter von Apothekensoftware und Praxisverwaltungs-systemen wenig Erfahrung bei der Einführung komplexer Sicherheitstechnologien. Oft be-stehen die von den Anbietern empfohlenen Sicherheitsrichtlinien lediglich darin, für den Aus-tausch von Daten grundsätzlich nicht das Internet zu verwenden. Alternativen, welche die vorgegebenen Sicherheitsbestimmungen für einen Datenaustausch über das Internet erfül-len, werden kaum angeboten bzw. angenommen und umgesetzt. Fehlende sichere Lösun-gen, hohe Kosten sowie mangelnde Erfahrung und Vorgaben führen zu Vorbehalten gegen-über dem Einsatz neuer Technologien und erschweren die Integrationsbestrebungen. Dagegen werden bei den Krankenkassen und Krankenhäusern stärker moderne Sicherheits-technologien angewandt. So finden im Bereich der Krankenhausinformationssysteme teil-weise bereits digitale Signaturkarten Anwendung. Seitens der Kostenträger besteht hinreichend Erfahrung in der Handhabung von KV-Kartenprozessen. Diese können eine Basis für den Rollout digitaler Signaturen sein, wobei der zu erwartende Umfang die bisherigen Piloten weit übersteigt. Auch die vorhandenen Trust-Center besitzen keine vergleichbaren Erfahrungen im massen-haften Rollout mit digitalen Signaturen (ca. 500.000 HPCs, evtl. 80.000.000 Gesundheitskar-ten).


Die technologische Basis der eingesetzten Systeme ist sehr inhomogen. Die Anwendungen werden auf verschiedensten Betriebssystemen und Laufzeitumgebungen betrieben. Dieser Umstand stellt hohe Anforderungen an die Plattformunabhängigkeit und Integrationsfähigkeit der Komponenten einer zukünftigen Telematikinfrastruktur. Die dafür notwendigen plattform-unabhängigen modernen Kommunikations- und Integrationslösungen (z.B. WEB-Services) sind bei den eingesetzten Anwendungen kaum vorhanden. Zwischen 25-50 % der bestehen-den Anwendungen basieren auf einer veralteten technologischen Basis und werden nicht mehr weiter entwickelt. Entsprechend fehlen bei den Anbietern der Software auch praktische Erfahrungen im Einsatz von modernen Integrationstechnologien. Zusammenfassend kann festgestellt werden, dass für die Einführung der Telematik im deut-schen Gesundheitswesen höchste Anstrengungen bezüglich der Bereitstellung adäquater Anwendungen und Infrastrukturen sowie der Etablierung neuer Prozesse zu bewältigen sind.


3 Einführung

3.1 Betrachtete Themenfelder In diesem Dokument werden angebotene und eingesetzte Anwendungen in den einzelnen Sektoren des Gesundheitswesens evaluiert. Hierbei werden insbesondere die verwendeten Integrations- und Sicherheitstechnologien, die zugrundeliegende Infrastruktur und die für die Telematikinfrastruktur relevanten Prozesse und Rollen im Gesundheitswesen betrachtet.

3.2 Abgrenzung Das Dokument betrachtet folgende Sektoren des Gesundheitswesens: Apotheken

Kliniken

niedergelassene Ärzte

Krankenkassen

Nicht näher untersucht wurden hingegen Anwendungen für den Patienten (Gesundheitsak-ten, Home-Care) und Anwendungen im Reha- und Pflegesektor. Im Sinne einer Fokussierung wurden die generellen Aspekte der Anwendungslandschaften betrachtet, welche im Zusammenhang mit den gesetzlich geforderten Anwendungen für die Einführung der Elektronischen Gesundheitskarte im Jahre 2006 stehen (Vertragsdatenma-nagement, Zuzahlung, eRezept, Dokumentation klinischer Basisdaten)

3.3 Erhebung der Informationen Neben der Nutzung öffentlicher Quellen (wie z.B. [EXP], [Warda/Noelle 2002], [KBVInstallStat]) wurden vor allem die im Rahmen der Workshops mit den Primäranbietern gewonnenen Informationen in Form von Protokollen und Fragebögen verwendet. Informatio-nen, die aufgrund ausbleibender Rückmeldungen verschiedener Primärsystemanbieter nicht aus den Ergebnissen der Workshops gewonnen werden konnten, wurden durch das Exper-tenwissen innerhalb des Konsortiums ergänzt.

3.4 Vorgehensweise zur Analyse Es erfolgte eine Analyse der erhobenen Informationen nach bestehenden Stärken, Schwä-chen, Chancen und Risiken. Diese wurden im Einzelnen zu den Kategorien Anwendungen und Daten, Prozesse und Organisation, Infrastruktur sowie Sicherheit zugeordnet. Anschließend wurden für die betrachteten Gebiete Kernaussagen abgeleitet und diese an-hand der Quellen verifiziert. Für jede dieser Aussagen wurden erste Schlussfolgerungen be-züglich der Auswirkungen auf die Telematikrahmenarchitektur sowie die Migration vorge-nommen.


4 Analyse der erhobenen Informationen

Im Folgenden werden die erhobenen Informationen je Sektor zusammengefasst. Die Konso-lidierung erfolgt basierend auf einer SWOT-Analyse (Strength-Weakness-Opportunities-Threats) anhand der pro betrachtetem Sektor die Stärken, Schwächen, Chancen/Möglich-keiten und Risiken herausgestellt und den Kategorien Anwendungen und Daten, Prozesse und Organisation, Infrastruktur sowie Sicherheit zugeordnet werden.

4.1 Apothekensoftware (APO)

4.1.1 Stärken Merkmal Kategorie

Apothekensoftware bietet Unterstützung für verschiedene Arzneimittelda-tenbanken wie ABDA, Arzneimitteltaxe, Rote Liste, Artikelstamm +V.

Anwendungen/Daten

Es handelt sich um Mehrplatzsysteme im Client-Server-Betrieb. Der An-schluss von Kartenlesegeräten ist in unterschiedlichen Konfigurationen möglich.

Infrastruktur

Die Hersteller geben Sicherheitsrichtlinien für Kunden beim Internetzugang vor (Firewall, Virenscanner).

Infrastruktur

Es existieren etablierte Strukturen für Updates von Software und Arznei-mittelinformationen, z.B. wird die ABDA-DB monatlich aktualisiert, die Arz-neimitteltaxe 14-täglich.

Prozesse/Organisation

Vielfach sind Installationen mit moderner Hardware und modernen Betriebs-systemen (LINUX, WINDOWS) durchgeführt. Dies erleichtert die Migration auf die neuen Technologien. (Neue Systeme ca. 75%)

Infrastruktur

Die verwendeten Arzneimitteldatenbanken in der BRD sind in allen Apothe-ken gleich.

Anwendungen/Daten

4.1.2 Schwächen Merkmal Kategorie

Kein einheitlicher Standard für eine Realisierung von Arzneimittelinterakti-onsprüfungen und Erkennung patientenindividueller Arzneimittelrisiken. Es fehlt eine sektorenübergreifende standardisierte Schnittstelle für die Integra-tion der Arzneimitteldatenbanken in die Primärsysteme.

Anwendungen/Daten

Bei der Entwicklung von Apothekensoftware spielen öffentliche SW-Entwicklungsstandards kaum eine Rolle.

Bei den Herstellern besteht wenig Erfahrung bezüglich aktueller Komponen-tentechnologien wie .NET oder J2EE.

Infrastruktur

Es werden kaum Sicherheitskomponenten eingesetzt bzgl. Verschlüsselung und digitaler Signatur.

Sicherheit


4.1.3 Chancen/Möglichkeiten Merkmal Kategorie

Mit Einführung des elektronischen Rezeptes wird der Medienbruch beseitigt und die Rezeptabrechnung rationalisiert.


Die Gesundheitskarte als Bestandteil der Telematikinfrastruktur ermöglicht eine Vielzahl von Mehrwertlösungen.


Für die Verbreitung von Kartenapplikationen können die bisherigen Vertei-lungsstrukturen für Apothekensoftware mitgenutzt werden.


Die Zuzahlungsbefreiung (Überforderungsklausel) könnte automatisiert werden.


Die Kontrolle der Medikation eines Kunden auf mögliche Arzneimittelinterak-tionen, Kontraindikationen sowie atypische Dosierungen könnte automatisch bzw. auf einer standardisierten Datenbasis durchgeführt werden.


4.1.4 Risiken Merkmal Kategorie

Es ergäbe sich eine erhebliche Störung der Abläufe in der Apotheke, wenn Pharmazeutisch-Technische Assistenten keine Arzneimittel-Interaktions-checks mehr durchführen könnten.


Fehlende oder mangelhafte Anreizsysteme könnten zur Verschiebung der Testphase führen.

Akzeptanz

Die rechtzeitige Fertigstellung von Hard- und Software ist aufgrund des en-gen Zeitplanes problematisch.

Migration, Infrastruktur

Bei den Abläufen an den Kassensystemen, für die Belieferung der Rezepte und für die Abgabe von OTC-Produkten kommt es auf Sekunden an. Eine Dauer der Abläufe > 3-4 sec. würde auf massive Ablehnung der Apotheken und der Patienten stoßen.

Anwendungen/Daten

4.2 Krankenhaus-Informations-Systeme (KIS)


KIS sind umfangreiche SW-Systeme zur Unterstützung aller anfallenden Prozesse im Krankenhaus (Behandlung, Abrechnung mit Kostenträgern,...).


Einige Produkte unterstützen fallübergreifende Patientenakten. Anwendungen/Daten

Es existieren zahlreiche Anwendungen, die verschiedene Standards inner-halb der Krankenhäuser und für den Datenaustausch mit den Krankenkas-sen nutzen (HL7 V2.3, DICOM, EDIFACT).

Anwendungen/Daten

Für Abrechnungszwecke werden in der Diagnostik und Behandlung etablier-te Klassifikationen (ICD-10-GM, OPS-301, DRG) verwendet.

Anwendungen/Daten

KIS sind skalierbare Mehrplatzsysteme. Infrastruktur

Medizinische Daten werden bei elektronischer Übermittelung gemäß § 301 SGB V verschlüsselt.

Sicherheit

Zum Signieren von Befunden oder Leistungsanforderungen durch den Arzt finden teils digitale Signaturkarten Anwendung.

Sicherheit



Es existiert ein Medienbruch bei der Kommunikation mit dem niedergelasse-nen Sektor (Arztbrief), da keine einheitlichen Standards (HL7 versus xDT) verwendet werden.

Prozesse/Organisa-tion,

Anwendungen/Daten

Es kommt teilweise Altsoftware zum Einsatz. Infrastruktur

Zahlreiche proprietäre Integrationen zwischen Anwendungssystemen und Datenbeständen existieren mangels fehlender Standards zum Integrations-zeitpunkt oder auch aktuell (siehe Dokument [b4hStds] in ausführlicher Be-trachtung).

Anwendungen/Daten


Die Wiederverwendung von bereits vorhandenen Untersuchungsergebnis-sen kann unterstützt werden und somit helfen, Doppeluntersuchungen zu vermeiden.


Durch Einführung der Elektronische Patientenquittung kann Kostentranspa-renz beim Patienten erreicht werden.

Anwendungen/Daten

Eine kurzfristige Validierung der Versichertendaten, insbesondere der Zu-zahlungsdaten des Patienten ist möglich.


Durch eine „Standardbereinigung“ und Herstellen von Interoperabilität kann langfristig eine Kostenreduzierung bei den Beteiligten erreicht werden.

Anwendungen/Daten

Zahlreiche aktuelle Standards und Initiativen werden von Systemen und Herstellern bereits umgesetzt, beherrscht oder pilotiert. (DICOM-Kommunikation, HL7-Kommunikation, LOINC, etc.) Diese umfassenden Erfahrungen können genutzt werden.

Anwendungen/Daten


Es muss Rechtssicherheit bezüglich Dokumentationspflichten und Kenntnis der Dokumentation durch den Arzt bestehen.

Rechtlicher Rahmen

Bisher wurden die Krankenhäuser und KIS-Hersteller bei der HPC Spezifika-tion vernachlässigt. Daher ist nicht klar, wie die Krankenhäuser investieren und diese Investitionen finanzieren sollen. Dies könnte die Testphase verzö-gern.

Akzeptanz

Fehlende oder mangelhafte Anreizsysteme könnten zur Verschiebung der Testphase führen.

Akzeptanz

Die rechtzeitige Fertigstellung von Hard- und Software ist aufgrund des en-gen Zeitplanes problematisch.

Migration, Infrastruktur

Kleine und mittlere Unternehmen werden durch „zu hohe“ Standards u.U. ausgeschlossen.

Neben den KIS-Systemen ist im Umfeld der Krankenhäuser eine komplexe Integration mit einer Vielzahl anderer Lösungen zu beachten.

Anwendungen/Daten


4.3 Praxisverwaltungssoftware (PVS)


PVS unterstützen fallübergreifende (nicht jedoch institutionsübergreifende) Patientenakten.

Anwendungen/Daten

Es existieren etablierte Standards zur Kommunikation mit den KV (ADT bzw. KVDT), zur Übertragung von Labordaten (LDT) und zur Kommunikation mit Medizingeräten (GDT).

Anwendungen/Daten

PVS sind meist Mehrplatzsysteme im Client-Server Betrieb. Infrastruktur

Es werden zahlreiche Anwendungen zur Unterstützung der bestehenden KVK sowie zusätzliche Funktionen eingesetzt (z.B. Arzneimittel- Datenbanken bei der Verordnung oder automatische Prüfungen).

Anwendungen/Daten

Es existieren etablierte Strukturen für Updates der Software mindestens quartalsweise.



Es besteht ein Medienbruch bei der elektronischen Kommunikation mit den Apotheken und dem stationärem Bereich.


Der Austausch von elektronischen Daten zwischen Praxen untereinander mittels BDT ist nicht einheitlich realisiert.

Anwendungen/Daten

Es sind noch zahlreiche Altsysteme (z.B. MS-DOS-basiert und älter) vor-handen.

Infrastruktur

Bei der Entwicklung von PVS fanden öffentliche Software-Entwicklungsstandards bisher eher kaum Beachtung.

Oft geben die Hersteller nur unzureichende Richtlinien für Absicherung des Internetzugangs vor oder raten ganz von der Verwendung des Internets ab.

Sicherheit

Nur zum Teil kommen Sicherheitskomponenten zum Einsatz. So richten sich beispielsweise einige Hersteller nach den Vorgaben des Kommunikations-standards VCS bezüglich Authentifizierung, Verschlüsselung und Signatur.

Sicherheit


Elektronisches Rezept und elektronischer Arztbrief können den Medienbruch bei der Kommunikation beseitigen.


Mit der elektronische Patientenquittung kann mehr Transparenz für den Pa-tienten erreicht werden.

Anwendungen/Daten

Zugriff auf bereits vorhandene klinische Daten hilft Doppeluntersuchungen zu vermeiden.


Durch verringerten Verwaltungsaufwand wäre eine Effizienzsteigerung bei täglichen Abläufen in der Praxis möglich.




Es besteht ein enger Zeitrahmen für die Fertigstellung von Hard- und Soft-ware.

Migration

Fehlende oder unzureichende Motivationsmodelle für Ärzte führen zu man-gelnder Akzeptanz.

Akzeptanz

Es muss Rechtssicherheit bezüglich Dokumentationspflichten und Kenntnis der Dokumentation durch den Arzt bestehen.

Rechtlicher Rahmen

Unterschiedliche Ausbaustufen der Arztpraxen hinsichtlich der vorhandenen Anwendungsdurchsetzung und Integrationstiefe bedingen sehr spezifische Migrationsaufwendungen

Anwendungen/Daten

Die Abläufe in den Praxen könnten durch Störungen bei den Kartenanwen-dungen erheblich beeinträchtigt werden. Fallback-Lösungen sind daher un-erlässlich.


Arzthelferinnen werden keine HPC zur Verfügung stehen. Entsprechende Richtlinien und Architekturen müssen effiziente Abläufe ermöglichen.


4.4 Krankenkassen (KK)


Für die Abrechnung mit Leistungserbringern finden etablierte Standards Anwendung (EDIFACT).

Anwendungen/Daten

Es existieren bei den meisten Kassen etablierte Prozesse für KV-Karten-management (Ausgabe etc.).



Einige (private) Kassen haben geringe Erfahrung mit Kartenprozessen. Prozesse/Organisation


Der Missbrauch der KVK könnte durch sichere Karten und Lesegeräte ver-hindert werden.



Änderungen der bestehenden Kartenmanagementprozesse sind nur mit erheblichem Aufwand möglich.



4.5 Kartenhersteller/Trust-Center (TC)


Erfahrungen mit Ausgabe von jährlich Millionen von Chipkarten in anderen Bereichen (Banken, Telekommunikation)


Bisher existiert keine Erfahrungen mit digitalen Signaturen im benötigten Umfang (ca. 500000 HPCs, ca. 80.000.000 Gesundheitskarten).

Infrastruktur


Die HPC stellt eine weitere, umfangreiche Anwendung digitaler Signaturen dar.


Der enge Zeitplan ist eine Herausforderung für die Herstellung der benötig-ten Karten und Lesegeräte.

Migration


5 Schlussfolgerungen

Im Folgenden werden zunächst die aus der Analyse abgeleiteten Kernaussagen getroffen und erläutert. Anschließend wird für die Aussagen eine Einordnung und grobe Bewertung der Auswirkungen auf Rahmenarchitektur und Migration vorgenommen.

5.1 Kernaussagen

1) Es existieren zahlreiche Softwareanbieter für Abrechnungsprozesse und klinische Dokumentation.

Es gibt ca. 150 (KBV-gemeldete) Anbieter für Praxisverwaltungssysteme, 30 für A-pothekensoftware sowie 12 für Krankenhausinformationssysteme. Schlussfolgerung:

- Die große Vielfalt von Anbietern mit unterschiedlichsten Systemen erfordert Kompo-nenten, welche eine flexible Integration der zahlreichen unterschiedlichen Systeme er-möglicht. Eine effiziente Zusammenarbeit erfordert die Anwendung von standardisier-ten Regeln und Austauschformaten.

2) Institutionsübergreifende telematische Prozesse werden von Softwareanbietern unzureichend unterstützt und sind bisher nur in speziellen Gebieten flächende-ckend realisiert (z.B. weit verbreitete Standards zur elektronischen Abrechnung von Dienstleistungen).

In Modellprojekten wurden bisher verschiedenste Ansätze und Technologien für segment-übergreifenden Austausch von medizinischen Informationen erprobt. Es hat sich hier je-doch nichts flächendeckend durchsetzen können.

Es bestehen nach wie vor Medienbrüche zwischen niedergelassenem Sektor und Kran-kenhäusern bzw. Apotheken.

Für die Abrechnung niedergelassener Ärzte mit den KV bzw. der Krankenhäuser mit den Krankenkassen finden KVDT bzw. EDIFACT Anwendung. Für Abrechnungs-zwecke wird eine Codierung der Diagnosen bzw. Operationen und Prozeduren ent-sprechend ICD bzw. OPS-301 vorgenommen. Schlussfolgerung:

- Bisher existiert keine vergleichbare Telematikinfrastruktur im Gesundheitswesen. Es besteht Bedarf für die Definition einheitlicher Regeln und Formate für den Austausch medizinischer Daten.

3) Es gibt keine Erfahrung bei Trust-Centern für den Betrieb und die Bereitstellung digitaler Signaturen im benötigten Umfang. Die kartenausgebenden Stellen sind nicht vertraut mit dem Rollout von digitalen Signaturen im Zusammenhang mit dem Rollout von Karten.

Signaturkarten wurden in Einzelprojekten bisher allenfalls in Größenordnungen von 20.000 ausgegeben.

Es werden ca. 500.000 HPCs benötigt. Falls es sich auch bei der Gesundheitskarte um


eine digitale Signaturkarte handeln soll, erfordert dies den Rollout von ca. 80.000.000 digi-talen Signaturen.

Die vorhandenen Projekte können wegen ihrer Größe nur unzureichende Aussagen da-hingehend machen, ob die gewählten Architekturen die notwendigen Mengen im Echtbe-trieb realisieren können.

Schlussfolgerung: - Die Einführung der HPC und Gesundheitskarte kann ohne gezielte Maßnahmen und

Vorbereitungen zu erheblichen Anlaufschwierigkeiten führen.

- Erfahrungen aus anderen Branchen (Banken, Telekommunikation), die Chipkarten im mehrstelligen Millionenbereich jährlich ausgeben, sollten berücksichtigt werden.

4) KV-Kartenprozesse sind bei den Kostenträgern weitgehend etabliert. Es gibt je-doch auch Kostenträger, die bisher keinerlei Erfahrung mit der Ausgabe von Kar-ten haben.

Gesetzliche Krankenversicherungen verwenden seit 01.01.1995 bundesweit die KVK als Nachweis der Berechtigung zur Inanspruchnahme von Leistungen. Privat-kassen geben an ihre Versicherten optional die Card für Privatversicherte (CfP) aus. Schlussfolgerung:

- Die bestehenden Erfahrungen der Kostenträger mit KV-Kartenprozessen können bei dem Entwurf und der Einführung der die Gesundheitskarte betreffenden Prozesse ge-nutzt werden. Die existierenden Abläufe bei den Kostenträgern sollten möglichst wenig modifiziert werden.

5) Es gibt keine standardisierten Arzneimitteldatenbanken. Es fehlt eine sektorenübergreifende standardisierte Schnittstelle für die Integration

der Arzneimitteldatenbanken in die Primärsysteme. Weiterhin existieren keine stan-dardisierten Stoff-Codes für Wirkstoffe und Hilfsstoffe im Falle von Rezepturen und keine Standards für die Codierung der integrationsrelevanten Individualparameter (Alter, Geschlecht, Schwangerschaft, Allergien, individuelle Interaktionen). Schlussfolgerung:

- In der Rahmenarchitektur besteht Bedarf für die Standardisierung von Arzneimittelda-tenbanken. Während der Migration sind dann bestehende Datenbank-Systeme ent-sprechend zu erweitern.

6) Wissen über Sicherheitstechnologien (SmartCards/Kryptographie) ist bei einem Großteil der SW-Hersteller nur rudimentär vorhanden.

Die meisten der befragten Anbieter gaben an, weder Sicherheitstechnologien in ihren Produkten einzusetzen, noch Erfahrungen in diesem Bereich zu besitzen.

Wenn im Falle von Praxisverwaltungssystemen Sicherheitstechnologien zum Einsatz kommen, dann sind diese zumeist zentral vorgegeben, z.B. KV-Kryptomodul, VCS-Client oder D2D-Client.

Eine Ausnahme stellen Krankenhausinformationssysteme dar, diese setzen zum Teil bereits digitale Signaturkarten ein zum Signieren von Befunden oder Leis-tungsanforderungen durch den Arzt.


Schlussfolgerung: - Sicherheitstechnologie ist weitgehend vor den Primärsystemanbietern zu kapseln und

einheitlich zur Verfügung zu stellen. - Längerfristig ist ein Aufbau von Wissen um Sicherheitstechnologien bei den Anbietern

notwendig.

7) 25 Prozent der eingesetzten SW wird von den Herstellern nicht mehr weiterentwi-ckelt (Altsoftware) und eignet sich nicht für telematische Anwendungen.

Einzelne Hersteller gaben an, sogar bis zu 50% Altsoftware einzusetzen.

Schlussfolgerung: - Die direkte Einbindung moderner Integrationstechnologien (z.B. WebServices) kann

zum großen Teil nur durch eine Neuentwicklung geschehen.

- Die Komponenten zur Integration müssen vorhandene Altsysteme berücksichtigen (z.B. Datei-Schnittstellen).

8) Es existiert eine große Vielfalt bei der eingesetzten Infrastruktur (Betriebssysteme, Plattformservices, Middleware, ).

Diese Heterogenität besteht zwischen den Systemen aber auch innerhalb einzelner Sys-teme.

Die Heterogenität ergibt sich aus einer Vielzahl von unterschiedlichen Architekturelemen-ten und umgesetzten Architekturkonzepten (z.B. unterschiedlichen Betriebssystemen, Entwicklungsumgebungen, Middleware)

Schlussfolgerung: - Die heterogene Infrastruktur bedingt eine Plattformunabhängigkeit der zu entwickeln-

den Komponenten.

- Gerade die hohen bestehenden Integrationslösungen im Krankenhausumfeld erfordern plattformunabhängige Komponenten.

9) Wissen über die Entwicklung plattformunabhängiger Komponenten ist nicht all-gemein verbreitet.

Ein großer Teil der befragten Anbieter von Apotheken-Software und Praxisverwal-tungssystemen verwendet weder J2EE noch .NET und kann sich eine Adaption an Java-Komponenten nicht oder allenfalls per Datei-Schnittstelle vorstellen. Schlussfolgerung:

- Ein kontinuierlicher Aufbau von Kompetenzen bezüglich moderner Komponententech-nologien bei den Herstellern ist erforderlich.


10) Die eingesetzte Software ist skalierbar und mehrplatzfähig. Nahezu alle befragten Anbieter gaben für ihre Systeme Mehrplatzfähigkeit und

Client-Server-Betrieb an. Während in einigen Fällen Obergrenzen für die Anzahl der Arbeitsplätze vorhanden sind, besteht diese Beschränkung insbesondere für Kran-kenhausinformationssysteme nicht. Schlussfolgerung:

- Die eingesetzte Software ist auf potentielle zusätzliche EDV-Arbeitsplätze im Rahmen der Einführung telematischer Prozesse vorbereitet.

11) Dienstleister informieren die Anwender oft nur unzureichend über die Möglichkei-ten der Absicherung des Internetzugangs.

Oft ist einfach nur die Richtlinie vorhanden, das Internet für die Übertragung von Daten nicht zu verwenden. Das Kosten / Nutzen Verhältnis erschwerte die Betrachtung und Einführung von

Internettechnologien in den Arztpraxen. Schlussfolgerung:

- Unzureichende Kenntnisse über Absicherung des Internetzugangs bzw. generelle Ab-lehnung der Nutzung des Internets für die Datenübertragung zwischen medizinischen Anwendungen erschweren die Einführung einer internetbasierten Telematik-infrastruktur.

12) Bestehende Software wird nur selten anhand öffentlicher Entwicklungsstandards bzw. anhand von Referenzmodellen entwickelt.

Nur ein kleiner Teil der befragten Hersteller richtet sich nach dem V-Modell oder einem anderen Vorgehensmodell (wie z.B. Rational Unified Process, Extreme Pro-gramming, OEP, HL7 Development Framework, etc.). Die Mehrheit gab keine Stan-dards oder Referenzmodelle an, die bei der Entwicklung angewandt werden. Schlussfolgerung:

- Es besteht ein Risiko bei der Vermittelung der Ergebnisse der Rahmenarchitektur an die Primärsystemanbieter bezüglich Vorgehen und verwendeter Basistechniken.

13) Es existieren regelmäßige etablierte Auslieferungsprozesse für Updates durch die SW-Hersteller.

Üblich sind mindestens vierteljährliche Software-Updates.

Ebenso existieren etablierte Strukturen, um Daten über SW-Hersteller verteilen zu lassen bzw. zu aktualisieren (z.B. Klassifikationssysteme, Abrechnungsschlüssel, Kostenträger-verzeichnisse).

Schlussfolgerung: - Bei der Auslieferung der neuen, telematikrelevanten Komponenten kann auf bestehen-

de Prozesse für Software-Updates zurückgegriffen werden.


14) Administrative Prozesse werden häufig von nichtmedizinischem Personal (Helfer, Assistenten) ausgeführt. So wird z.B. das Einlesen der KVK in Arztpraxen grundsätzlich von der Helferin an der

Rezeption durchgeführt.

Schlussfolgerung: - Derartige administrative Prozesse müssen bei der Definition von Rollen und Berechti-

gungen beachtet werden. Insbesondere darf die eingeführte Autorisierung mittels HPC gängige administrative Prozesse nicht behindern.

5.2 Einordnung und Bewertung Die im vorigen Abschnitt getroffenen Kernaussagen sollen als Grundlage dienen, um in wei-teren Dokumenten Anforderungen für Teilbereiche wie Daten- bzw. Komponentenmodell, Prozessmodell und Sicherheitsinfrastruktur abzuleiten. Um hierfür die unterschiedliche Wich-tigkeit der einzelnen Kernaussagen darzustellen, werden im Folgenden deren Auswirkungen auf die Definition des Zielsystems (Rahmenarchitektur) und auf den Übergang zum Zielsys-tem (Migration) bewertet. Kaum eine der Kernaussagen trifft für alle der betrachteten Sektoren Apotheken, Kranken-häuser, Arztpraxen, Krankenkassen und Kartenhersteller bzw. Trust-Center gleichermaßen zu. Daher wird für jede Aussage eine Zuordnung zu den Sektoren vorgenommen. Um die primär betroffenen Teilbereiche der Modellierung ableiten zu können, erfolgt weiter-hin eine Zuordnung der Kernaussagen zu den Kategorien Anwendungen und Daten, Prozes-se und Organisation, Infrastruktur und Sicherheit. Dies kann als Grundlage dienen, um für Folgedokumente vordergründig zu berücksichtigende Kernaussagen zu selektieren. Zur ein-deutigen Referenzierung der Kernaussagen in anderen Dokumenten ist hierbei das Kürzel ALKA (Anwendungslandschaften Kernaussage), gefolgt von der laufenden Nummer der Kernaussage, zu verwenden.


ALKA1 Zahlreiche Softwareanbieter für Abrechnungsprozesse und klinische Dokumentation

ALKA2 Institutionsübergreifende telematische Prozesse sind bzgl. der Primäranwendungen 2006 unzureichend etabliert, nur für elektronische Abrechnungen haben sich sektor-übergreifend Standards etabliert.

ALKA3 Bisher keine Erfahrungen mit Betrieb und Bereitstellung digitaler Signaturkarten im be-nötigten Umfang.

ALKA4 KV-Kartenprozesse bei Kostenträgern weitgehend etabliert

ALKA5 Keine standardisierten Arzneimitteldatenbanken

ALKA6 Wissen über Sicherheitstechnologien meist rudimentär

ALKA7 25% Altsoftware

ALKA8 Heterogenität der eingesetzten Infrastruktur

ALKA9 Wissen der Anbieter über Entwicklung plattformunabhängiger Komponenten nicht über-all verbreitet

ALKA10 Eingesetzte Software skalierbar und mehrplatzfähig

ALKA11 Oft geringe Informationen über Absicherung des Internetzugangs

ALKA12 Nur selten Anwendung von öffentlichen SW-Entwicklungsstandards und Referenzmodel-len

ALKA13 Etablierte Updateprozesse für Software

ALKA14 Administrative Prozesse häufig von nichtmedizinischem Personal ausgeführt

Tabelle 1: Zusammenfassung der Kernaussagen


Tabelle 2: Bewertung und Einordnung der Kernaussagen

Anwendungen und Daten

Prozesse und Organisation

Infrastruktur

Sicherheit

Kategorien

Kernaussage (ALKA)

Apotheken

Krankenhäuser

Arztpraxen

Krankenkassen

Sektoren

Kartenhersteller/Trust-

Auswirkungen auf Rah-menarchitektur und

Migration

Auswirkung auf Rahmenarchitektur

Auswirkung auf Migration

Hat starke Aus-

wirkung, erfordert

dringend Berück-

sichtigung.

Hat Auswirkung,

erfordert norma-

le Berücksichti-

gung.

Hat geringe Aus-

wirkung, erfordert

kaum Berücksich-

tigung.

Kennzeichnet (vorrangig) betroffene Sektoren und Kategorien

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Legende

Erarbeitung einer Strategie zur Einführung der...

Documents

Transcript of Erarbeitung einer Strategie zur Einführung der...