Die Roadmap zur EDHS-Tauglichkeit Ihres KIS

Für ein altes KIS ist der praktischste Ansatz die Schaffung einer Interoperabilitätsschicht (FHIR-Adapter in Kombination mit einem Terminologie-Server), während das Altsystem im Hintergrund weiterläuft. So erfüllt man EHDS-Anforderungen schrittweise, ohne sofort alles neu bauen zu müssen.

Phase 1: Analyse & Vorbereitung

• Bestandsaufnahme

Welche Schnittstellen bietet das KIS aktuell? (HL7 v2, proprietär, DICOM, CSV, SQL-Dumps etc.)

Welche Terminologien sind im Einsatz? (ICD-10, hausinterne Laborkürzel, OPS, Freitext)

Welche Sicherheits- und Zugriffsmechanismen gibt es schon?

• Gap-Analyse

Vergleich IST-Zustand mit EHDS-Anforderungen (FHIR, IHE, SNOMED CT, LOINC, Zugriffsrechte, Patientenzugriff).

Dokumentation der „Legacy“-Abhängigkeiten.

Phase 2: Interoperabilitätsschicht schaffen

Da ältere Systeme oft nicht direkt modernisiert werden können, ist eine Middleware/Integrationsplattform sinnvoll:

• Middleware-Lösungen / Interoperability Layer:
  • 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).
• Funktion:
  • Übersetzen von HL7 v2 oder proprietären Nachrichten in HL7 FHIR.
  • Abbildung von Terminologien (Mapping zu SNOMED CT, LOINC etc.).
  • Sichere Bereitstellung über RESTful APIs für EHDS.

Phase 3: Terminologie & Datenqualität

• Terminologieserver einsetzen (z. B. SNOMED CT-Server von Snowstorm, Ontoserver, Apelon DTS).
• Mapping-Prozesse aufsetzen:
  • Laborkürzel → LOINC
  • Diagnosen → ICD-10 / SNOMED CT
  • Medikamente → ATC
• Validierung & Cleaning: Freitexte in strukturierte Daten transformieren (Natural Language Processing optional).

Phase 4: Sicherheit & Zugriffsmanagement

• Authentifizierung & Autorisierung
  • eIDAS-konforme Lösungen (z. B. ELGA/eID, gematik ID in Deutschland).
  • OAuth2.0 / OpenID Connect für API-Sicherheit.
• Verschlüsselung
  • TLS 1.3 für Übertragung.
  • Datenbankverschlüsselung & Audit-Logs.
• Feingranulare Rechte: Rollenbasiert (RBAC) oder attributbasiert (ABAC).

Phase 5: EHDS-Integration

• Primärnutzung (Patientenversorgung)
  • Anbindung an nationale ePA/eHR-Systeme (z. B. gematik ePA in DE, ELGA in AT, DPIA in FR).
  • Nutzung von IHE-XDS/XCA-Profilen für Dokumentenaustausch.
• Sekundärnutzung (Forschung & Politik)
  • Bereitstellung pseudonymisierter Daten über die nationale Health Data Access Body-Infrastruktur.
  • Implementierung von De-Identifikationsdiensten (z. B. ARX, Synthea für synthetische Daten).

Phase 6: Migration & Modernisierung

• Schrittweise Ablösung alter Module durch modernere Systeme, die FHIR-ready sind (z. B. für Radiologie, Labor, Patientenportal).
• Hybridbetrieb: Altsystem + Middleware + neue Module.
• Langfristig: Ablösung durch ein KIS, das EHDS-konform „by design“ ist.

Beispielhafter Technologie-Stack

• Middleware: Mirth Connect + HAPI FHIR Server
• Terminologie: Snowstorm (SNOMED CT), Ontoserver (LOINC/ATC)
• Sicherheit: Keycloak (IAM, OAuth2/OpenID)
• API-Management: Kong oder WSO2
• De-Identifikation: ARX Data Anonymization Tool