Weiterentwicklung e-card System ein Ausblick - Wien, am 6. November 2018 - IHE-Austria
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Weiterentwicklung e-card System
ein Ausblick
Wien, am 6. November 2018
Das e-card System – Status Quo
● e-card System seit 2005 österreichweit ausgerollt
● >100 Millionen Konsultationen pro Jahr
● >8,5 Millionen e-cards, >24.000 Admin-Karten (aka o-cards)
● >12.000 GDAs (Ärzte, Krankenanstalten, Apotheken, Bandagisten, …)
● 90 SW-Hersteller nutzen die SS12
● 16 Services in bis zu 3 Ausprägungen (SS12, Web-GUI, Standalone)
● Fokus auf Sicherheit, Qualität und Verfügbarkeit
● Garantierte Antwortzeiten, Verfügbarkeit >99,7%
● Regelmässige Erneuerung der Systemkomponenten
– e-cards (5. Generation in Entwicklung)
– GINA (3. Generation im Rollout)
– Zentralsystem wird regelmässig gepflegt/erweitert/erneuert
2Motivation/Hintergründe für
Weiterentwicklung des Gesamtsytems
● Architektur (dezentrale GINAs + Zentralsystem) ist aufwändig und durch
die positiven Entwicklungen im Bereich Infrastruktur nicht mehr
notwendig
● Neue GDA-SW Konzepte (GDA-SW as a Service) mit der aktuellen
Architektur nicht umsetzbar
● Steigender Ressourcenbedarf und Komplexität der Services erhöht den
Erneuerungsdruck für die GINA
● Abkündigung von kritischen Bauteilen (CPU, RAM, Storage) erhöhen
ebenfalls den Erneuerungsdruck auf die GINA
3Was wird sich ändern?
● e-card G5 (Generation 5)
– Foto auf e-card, NFC Fähigkeit, Wegfall der Bürgerkarten-Fähigkeit
● GINO (LAN-CCR 3G)
– NFC-Fähigkeit, Unterstützung für neue Architektur
● GINA as a Service
– GINA 3G ist die letzte physische GINA, Wegfall auch der sGINA
– Erweiterung des Zentralsystems
● Weiterentwicklung GIN
– Kanalbündelung (Zusammenlegung SV- und MWD-Kanal)
– Erhöhung Bandbreite auf 2 MBit, weitere Erhöhung wird mit ÖÄK
abgestimmt
4Von der GINA zu GINAaaS
Arzt-
SW
LAN-CCR 3G
(GINO)
GINA3G
GIN
ggf. GDA- Peering
Software as a Point
Service
e-card Rechenzentrum
/ e-card System
5Was ändert sich, was bleibt gleich
● lokale GINA entfällt – Verlagerung der Funktionalität ins e-card
Rechenzentrum
– Unterstützung neuer Technologien (GDA-Software as a Service, mobile
Lösungen)
– Änderung beim Offline-Szenario lokale GDA-Software übernimmt
Offline Funktionalität und zwischengespeicherte Signaturtoken werden
„nachgesendet“
● SS12 bleibt
● Web-GUI bleibt, ABER
– Aktuelle Browser, JavaScript und Cookies notwendig
– Web-GUI hat keine Offline-Funktionalität mehr
● Stand-Alone Lösung fällt weg
● Router und Kartenleser bleiben lokal in der Ordination
● LAN-CCR 3G (GINO) mit geringfügig erweiterter Funktionalität
● GDA-SW kommuniziert direkt mit dem Kartenleser 6Zeitplan
2018 2019 2020 2021 2022 2023 2024
Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1/2 Q3/4 Q1/2 Q3/4
GINA 3G
Rollout Life Cycle
50%
ecard G5
Vergabe / Umsetzung Rollout
GINO
LAN-CCR 3G
Konzeption Vergabe / Umsetzung Pilot Rollout
GINAaaS
PoC Umsetzung 1. Pilot 2. Pilot Rollout
GINA 3G + LAN-CCR 2G GINAaaS + GINO
heute 7e-card System und IHE/CDA
● SV steht zu Standardisierung und Standards und sieht darin großen
Nutzen, wenn
– österreichweit umgesetzt
– International einsetzbar (vor allem EU)
– für SV-Zwecke sinnvoll nutzbar
● SV trägt die Entscheidung IHE/CDA für ELGA einzusetzen mit
● eKOS ist im Rollout und e-Rezept steht vor der Umsetzung, jeweils nicht
auf IHE basierend
● weitere SV Services stehen auf der Roadmap zur Umsetzung im e-card
System (z.B.: e-Transportschein)
8e-card System und IHE/CDA
● Was erschwert es der SV in e-card Services IHE/CDA einzusetzen
– IHE steht für medizinische Prozesse in und zwischen
Krankenanstalten
• die (administrativen) SV-Prozesse kommen in IHE nicht vor
• Anforderungen aus dem niedergelassenen Bereich sind bisher
nicht oder zu gering berücksichtigt
– Bereitschaft von IHE die SV-Prozesse zu standardisieren nicht
vorhanden
– Dokumentenbasierte Schnittstellen für SV-Prozesse unpraktisch und
aufwändig
– Erweiterungen der bestehenden IHE Profile (z.b. Pharmacy für e-
Rezept) sind nur nationale Erweiterungen, werden nicht in den
Standard übernommen und betrachten nicht den kompletten SV-
Prozess
9e-card System und IHE/CDA
● Was erschwert es der SV in e-card Services IHE/CDA einzusetzen
– SV Backends und SV-Partnersysteme sind nicht mit IHE kompatibel
– Aufwand und Durchlaufzeit zur Umsetzung basierend auf IHE (inkl.
der Standardisierung als IHE-Profil) ist im Vergleich zu SS12 (e-card
Standard) deutlich höher
– Die Komplexität IHE einzusetzen steht in keinem Verhältnis zum
Nutzen für die SV in den SV-Prozessen (für EU weite Vernetzung
der SV ist der Standard EESSI)
– Bereitschaft diese Mehraufwände mitzutragen bei den
Systempartnern nicht vorhanden
10e-card System und IHE/CDA
● Was erschwert es der SV in e-card Services IHE/CDA einzusetzen
– Nicht alle Stakeholder sind bereit IHE/CDA einzusetzen
– Hohe Akzeptanz und Zufriedenheit mit SS12 bei den 90 GDA-SW
Herstellern (Investitionsschutz)
– Hohe Akzeptanz des e-card ELGA Adapters
– Geringe Akzeptanz der Hersteller (vor allem auch im Bereich KIS
Hersteller) IHE (ELGA) zu integrieren
– Es werden fast überall und fast ausschließlich Adaptoren eingesetzt
– Geringe Akzeptanz von e-Medikation durch Krankenanstalten
• Wenn, dann wurde/wird nur Lesen der Medikationsliste
umgesetzt
11Stand: September 2018
90 SW-Hersteller mit
SS12-Integration
8 Apotheken
Zahnärzte 9
Kranken-
13 anstalten
Weitere
GDAs
17
43 ÄrzteStand: September 2018
Nutzung e-Medikation
IHE nativ vs. ELGA-Adapter (SS12)
29 SW-Hersteller
Ärzte
70% nutzen
ELGA-Adapter
30% native 1 SW-Hersteller
Anbindung
Apotheken
Kranken-
anstalten 100% nutzen
Keine KA nutzt ELGA-
eMedikation über
das e-card Adapter
System 13Was wir verstanden haben
● Vereinheitlichung von Code-Systemen im Gesundheitswesen ist
notwendig und sinnvoll
● Vereinheitlichung von Standard-Datenstrukturen ist notwendig und
sinnvoll
● Für Krankenanstalten scheinen dokumentenbasierte Verfahren besser
geeignet zu sein
– CDA Dokumente als alternative in den e-card Schnittstellen sind
denkbar
● GDA-SW Hersteller benötigen eine klare Strategie wie es zukünftig mit
SS12 und IHE weitergeht (Investitionsschutz)
14Was wir uns wünschen
● Zusagen seitens Krankenanstalten das e-card System vollständig
einzubinden
– Prüfung auf gültige e-card (nicht nur public Bereich auslesen)
• Wird mit Foto auf der e-card noch wichtiger bzw. gesetzlich
vorgeschrieben
● Verbindliche Zusage mit Zeitplan seitens Krankenanstalten eKOS und e-
Rezept einzusetzen
15Wie geht es weiter
● SV wird Gespräche mit Ländervertretern, Interessenvertretungen, sowie
Software Industrieaufnehmen
– Was sind konkret die Probleme/Anforderungen
– Welche Maßnahmen können diese lindern/lösen
● Überlegungen/Analysen, ob IHE/FHIR ein Konvergenzpfad für SS12 und
IHE sein kann
● Erstellung einer Roadmap für die Umsetzung zukünftigen Schnittstellen-
Architektur für e-card Services
16Sie können auch lesen
