Die Road­map zur EHDS-Taug­lich­keit Ihres KIS

Ihr KIS ist bereits langjährig im Einsatz und Sie machen sich Gedanken, wie sie den zukünftigen Anforderungen durch die kommenden EHDS-Bestimmungen begegnen können?

Für ein in die Jahre gekommenes KIS ist der praktischste Ansatz die Einrichtung einer Interoperabilitätsschicht, welche die Rolle eines Integrations- und Übersetzungslayers (FHIR-Adapter in Kombination mit einem Terminologie-Server) übernimmt. Während Ihr Altsystem (Lagacy System) im Hintergrund weiterläuft, sorgen ergänzende FHIR-Module für Standardisierung (HL7 FHIR R4/R5) und EHDS-konforme Interoperabilität. Darüber hinaus stellt ein Sicherheits- und Governance-Layer die Erfüllung von DSGVO, EHDS und lokaler e-Health-Regularien sicher. So erfüllen Sie die EHDS-Anforderungen schrittweise, ohne sofort alles neu bauen zu müssen. 

In 6 Phasen können Sie den Weg hin zum EHDS-tauglichen KIS beschreiten - dabei ist es wie so oft: Gute Planung steht für die halbe Zielerreichung! 

#1: Organisieren Sie eine professionelle Analyse & Vorbereitung

Veranlassen Sie eine detaillierte Bestandsaufnahme Ihres Altsystems: 

• Welche Schnittstellen (HL7 v2, proprietär, DICOM, CSV, SQL-Dumps etc.) bietet Ihr KIS aktuell?
• Welche Terminologien sind im Einsatz? (ICD-10, hausinterne Laborkürzel, OPS, Freitext)
• Welche Sicherheits- und Zugriffsmechanismen gibt es schon?

Führen Sie nun eine exakte Gap-Analyse durch: Vergleichen Sie den Istzustand mit den EHDS-Anforderungen (FHIR, IHE, SNOMED CT, LOINC, Zugriffsrechte, Patientenzugriff) und dokumentieren Sie die „Legacy“-Abhängigkeiten.

#2: Schaffen Sie eine Interoperabilitätsschicht

Da ältere Systeme oft nicht direkt modernisiert werden können, ist die Nutzung einer eine Middleware (Integrationsplattform; Interoperability Layer) sinnvoll:

• FHIR-Gateways (z. B. Smile CDR, HAPI FHIR, Firely Server).
• IHE-konforme Plattformen wie Orion Health, Tiani Spirit, NextGen Connect (Mirth).
• API-Management (z. B. WSO2 API Manager, Kong, Azure API Management).

Dieser Layer übersetzt Daten von HL7 v2 oder proprietären Nachrichten in HL7 FHIR, bildet Terminologien (Mapping zu SNOMED CT, LOINC etc.) korrekt ab und sorgt für sichere Bereitstellung über RESTful APIs für EHDS.

#3: Sorgen Sie für Terminologie & Datenqualität

Setzen Sie einen Terminologieserver ein (z.0B. SNOMED CT-Server von Snowstorm, Ontoserver, Apelon DTS) und setzen Sie die erforderlichen Mapping-Prozesse sauber auf:

• Laborkürzel → LOINC
• Diagnosen → ICD-10 / SNOMED CT
• Medikamente → ATC

Transformieren Sie Freitexte .in strukturierte Daten (Validierung & Cleaning).

#4: Managen Sie Sicherheit & Zugriffsmanagement

Für sichere Authentifizierung & Autorisierung der Anwender werden eIDAS-konforme Lösungen (z.B. gematik ID in Deutschland, ELGA/eID in Österreich) eingesetzt. OAuth2.0 / OpenID Connect sorgen für entsprechende API-Sicherheit. TLS 1.3-Verschlüsselung für die Datenübertragung), Datenbankverschlüsselung & Audit-Logs sorgen für entsprechende Sicherheit. Feingranulare Rechte werden rollenbasiert (RBAC) oder attributbasiert (ABAC) vergeben.

#5: Führen Sie die EHDS-Integration durch

Zur Primärnutzung (Patientenversorgung) ist die Anbindung an nationale ePA/eHR-Systeme (z.B. gematik ePA in DE, ELGA in AT, DPIA in FR) vorgesehen. Sie nutzen dabei IHE-XDS/XCA-Profilen für den Dokumentenaustausch.

Für die Sekundärnutzung (Forschung & Politik) erfolgt die Bereitstellung pseudonymisierter Daten über die nationale Health Data Access Body-Infrastruktur. Dazu ist die Implementierung von De-Identifikationsdiensten (z.B. ARX, Synthea für synthetische Daten) erforderlich.

#6: Schützen Sie Ihre Investitionen durch schrittweise Migration & Modernisierung

Führen Sie die schrittweise Ablösung alter KIS-Module durch modernere Systeme durch, die "FHIR-ready" sind (z.B. für Radiologie, Labor, Patientenportal). In einem "Hybridbetrieb" (Ergänzung des Altsystems durch eine Middleware und Implementierung von KIS-Modulen der EHDS-tauglichen neuen Softwaregeneration) sorgen Sie für volle Funktionalität Ihres KIS, bevor Sie schließlich Schritt für Schritt zu einem modernen, EHDS-konformen KIS gelangen.

Praxisbeispiel: Architekturfluss auf Basis eines möglichen Technologie Stacks

Das Alt-KIS erzeugt eine HL7v2 ADT-Nachricht (Patientenaufnahme). Die Middleware (Mirth/Apache Camel) transformiert diese HL7v2-Nachricht in HL7 FHIR, DICOM → FHIR ImagingStudy. Der FHIR Server (HAPI FHIR) speichert die Daten standardisiert. Das FHIR Gateway stellt die Daten per RESTful API oder SMART-on-FHIR App zur Verfügung. Ein EHDS-konformes Exportmodul wandelt die Daten ins EHRxF-Format um und ermöglicht den Austausch mit nationalen/europäischen Datenplattformen. Consent Management (FHIR Consent + Keycloak) steuert, welche Daten für Forschung/Versorgung freigegeben sind.