Kurze Antwort: Ein Krankenhaus betreibt Dutzende von Systemen, und die Integration ist die Arbeit, sie über einen Patienten einig zu machen. Im Zentrum sitzt das KIS (Krankenhausinformationssystem) oder EHR, das die Patientenidentität, Aufnahmen und die klinische Akte besitzt. Drumherum: das Laborsystem (LIS), Radiologie (RIS und PACS), Apotheke, OP, Notaufnahme, Abrechnung, Geräte (Monitore, Infusionspumpen) und zunehmend Patienten-Apps, Wearables und Telemedizin. Eine Schnittstellen-Engine in der Mitte empfängt, transformiert und leitet Nachrichten weiter, sodass jedes System einmal statt mit jedem anderen verbunden ist. Der Verkehr besteht hauptsächlich aus HL7 v2-Nachrichten über MLLP für Ereignisse (Aufnahmen, Bestellungen, Ergebnisse), DICOM für Bilder, CDA oder PDF für Dokumente und FHIR über REST für alles Neue, Patientenbezogene oder Externe.
Die Systeme und was sie austauschen
Die Integrationslandschaft eines Krankenhauses besteht aus dem KIS oder K$^2$R, das die Patientenidentität, die Behandlungsfälle und die klinische Akte verwaltet, sowie dem Laborsystem, der Radiologie (RIS und PACS), der Apotheke, den Geräten, Patienten-Apps, der Telemedizin und regionalen Systemen. Sie tauschen HL7 v2-Nachrichten wie ADT, Aufträge und ORU-Ergebnisse, DICOM-Bilder, CDA-Dokumente und FHIR-Ressourcen aus.
| System | Besitzt | Sendet | Empfängt |
|---|---|---|---|
| KIS / EHR | Patientenidentität, Aufnahmen, Bestellungen, die klinische Akte | ADT (Aufnahmen, Verlegungen), ORM/OML Bestellungen, SIU Terminplanung | ORU Ergebnisse, MDM Dokumente, DFT Gebühren |
| LIS (Labor) | Proben, Analysen, Ergebnisse, Referenzbereiche | ORU^R01 Ergebnisse, ORR Bestellantworten | ORM/OML Bestellungen, ADT für Demografie |
| RIS / PACS | Bildgebungsaufträge, Arbeitslisten, Berichte, Bilder | ORU Berichte, DICOM an Viewer, SIU | ORM/OMI Bestellungen, ADT; DICOM MWL an Modalitäten |
| Apotheke | Medikamentenverzeichnis, Abgabe, Lagerbestand | RDS Abgabe, RAS Verabreichung | OMP/RDE Medikamentenbestellungen, ADT |
| Geräte und Monitore | Vitalparameter, Wellenformen, Alarme | ORU^R01 Beobachtungen (IHE PCD), proprietär | ADT für Patientenzusammenhang |
| Patientenportal / Apps | Vom Patienten eingegebene Daten, Zugriff | FHIR Beobachtungen, Fragebögen, Nachrichten | FHIR Lesezugriff auf Ergebnisse, Termine, Dokumente |
| Telemedizin | Videosprechstunden, Fernüberwachung | FHIR Encounter, Observation, DocumentReference | Termin, Patientenzusammenhang, SMART Launch |
| Regionale und nationale Systeme | Gemeinsame Akten, Register, E-Rezept | CDA Dokumente (XDS), FHIR, nationale Nachrichten | Abfragen, Benachrichtigungen |
Die Schnittstellen-Engine
Eine Schnittstellen-Engine ist die zentrale Nachrichtenvermittlungsstelle eines Krankenhauses: Sie empfängt HL7 v2-, FHIR-, Datei- und Datenbankverkehr von jedem System, wandelt ihn um und leitet ihn an jedes andere System weiter, das ihn benötigt. Sie verwaltet Warteschlangen, Wiederholungsversuche, Überwachung und Protokollierung. Ohne eine solche Engine benötigen N Systeme bis zu N×(N−1)/2 manuell erstellte Schnittstellen; mit einer Engine verbindet sich jedes System nur einmal.
Die Engine (u.a. Mirth Connect / NextGen Connect, Rhapsody, InterSystems HealthShare und IRIS for Health, Infor Cloverleaf, Qvera QIE) bietet Listener (MLLP, HTTP, Datei, Datenbank), Transformationen (Felder zuordnen, Codes korrigieren, v2 in FHIR konvertieren), Routing (ein ADT mit acht Filtern an acht Systeme senden), Warteschlangen und Wiederholungsversuche, Überwachung und Protokollierung. Hier wird auch die Patientenidentität abgeglichen, wenn Systeme voneinander abweichen, und oft eine FHIR-Fassade über einer Legacy-Datenbank aufgebaut. Siehe Schnittstellen-Engines erklärt.
Die wichtigsten Abläufe
Die wichtigsten Integrationsabläufe im Krankenhaus sind ADT (Aufnahmen, Entlassungen, Verlegungen und demografische Aktualisierungen, die vom KIS ausgehen), Aufträge und Ergebnisse zwischen dem K$^2$R und dem Labor oder der Radiologie, Medikamentenaufträge und -abgabe, Dokumente wie Entlassbriefe, Gerätedaten von Monitoren und der patientenseitige Austausch von Ergebnissen, Terminen und Heimmessungen über FHIR.
- ADT: Jede Aufnahme, Entlassung, Verlegung, Registrierung und jede demografische Aktualisierung (A01, A03, A02, A04, A08, A40 Merge) wird vom KIS an alle anderen weitergeleitet. Wenn ADT verspätet oder falsch ist, werden alle nachgelagerten Systeme Daten unter dem falschen Patienten oder der falschen Aufnahme ablegen. Siehe HL7 v2 Nachrichten erklärt: ADT und ORU.
- Bestellungen und Ergebnisse: ORM/OML hinaus, ORU zurück, mit Platzierungs- und Füllernummern, die sie verbinden; LOINC und UCUM in den Ergebnissen. Siehe HL7 v2 Bestellnachrichten und Integration eines Laborsystems mit einem EHR.
- Bildgebung: Bestellungen an das RIS, DICOM-Arbeitslisten an die Scanner, Bilder an das PACS, Berichte als ORU zurück, Viewer über DICOMweb. Siehe PACS vs RIS vs VNA.
- Medikation: Bestellungen an die Apotheke, Abgabe und Verabreichung zurück, mit dem geschlossenen Kreislauf (Barcode am Bett) als Sicherheitsziel.
- Dokumente: Entlassbriefe, Operationsberichte und gescannte Dokumente als MDM-Nachrichten, CDA oder PDFs in einem Dokumentenrepository, veröffentlicht in regionalen Registern.
- Geräte: Monitore, die Vitalparameter über IHE PCD-Profile oder Anbieter-Gateways in die Akte einspeisen, wobei das Alarmmanagement eine separate Disziplin ist.
- Patientenbezogen: Ergebnisse, Termine und Dokumente über FHIR an das Portal und die Apps; Fragebögen, Heimmessungen und Wearable-Daten zurück, mit Herkunftsangaben, die sie als vom Patienten gemeldet kennzeichnen. Siehe Fernüberwachung von Patienten mit FHIR.
Funktionierende Muster
Erfolgreiche Muster für die Krankenhausintegration sind: ein Master-System für die Patientenidentität, bei dem alle anderen ADTs abonnieren; Code-Zuordnung zu LOINC, SNOMED CT und ATC einmalig an der Engine; Bestätigungen, Warteschlangen und Wiederholungsversuche für jede Nachricht; idempotente Ergebnisse und Dokumente; eine FHIR-Schicht für Patienten-Apps und externe Partner; sowie Testumgebungen mit synthetischen Patienten vor der Inbetriebnahme.
- Eine Master-Identität. Das KIS (oder ein Master Patient Index) besitzt die Identifikatoren; alle anderen abonnieren ADT und erfinden niemals Patienten.
- Codes an der Grenze. Lokale Codes an der Engine einmalig in LOINC, SNOMED CT, ATC übersetzen und den lokalen Code daneben beibehalten.
- Bestätigen, in die Warteschlange stellen, wiederholen. Jede v2-Nachricht erhält eine ACK; die Engine speichert und spielt sie erneut ab; niemand verliert ein Ergebnis, weil ein System neu gestartet wurde.
- Idempotenz. Ergebnisse und Dokumente tragen Identifikatoren; eine Wiederholung aktualisiert statt zu duplizieren.
- Eine FHIR-Schicht für alles Neue. Patienten-Apps, Telemedizin, Forschungsdatenextraktionen und externe Partner sprechen FHIR mit einer Fassade oder einem dedizierten FHIR-Server, der aus den internen Abläufen gespeist wird, anstatt direkt mit dem KIS zu sprechen.
- Testumgebungen mit synthetischen Patienten und ein Konformitätsschritt (IHE Connectathon-Profile, nationale Testsuiten), bevor etwas in die Produktion gelangt.
Überall beobachtete Fehlermodi
Die in fast jeder Krankenhausintegration beobachteten Fehlerarten sind doppelte Patienten aufgrund von Registrierungsfehlern, Ergebnisse, die nach einer Zusammenführung dem falschen Behandlungsfall zugeordnet werden, nicht zugeordnete lokale Codes, Fehler bei Zeitstempeln aufgrund von Zeitzonen und Sommerzeit, Einheiten in Freitext, Schnittstellen, die ohne Überwachung stillschweigend ausfallen, Vendor-Z-Segmente, die Parser beschädigen, und temporäre CSV-Feeds, die nie abgeschafft werden.
Doppelte Patienten durch Registrierungsfehler; Ergebnisse, die nach einer Zusammenführung der falschen Aufnahme zugeordnet wurden; lokale Testcodes, die niemand zugeordnet hat; Zeitzonen und Sommerzeit in Nachrichten-Zeitstempeln; Einheiten in Freitext; eine Schnittstelle, die stillgelegt wurde und die niemand überwacht hat; herstellerspezifische Z-Segmente, die Parser brechen; und der "temporäre" CSV-Feed, der immer noch zehn Jahre später läuft.
Wo FHIR das Bild verändert
FHIR verändert die Krankenhausintegration eher am Rand als im Kern. Innerhalb des Gebäudes bleiben HL7 v2 und DICOM bestehen, da Analysegeräte, Scanner und Legacy-Module diese sprechen; FHIR übernimmt den Patientenzugang, SMART on FHIR-Apps, die Entscheidungsunterstützung durch CDS Hooks, Abonnements, den regionalen und nationalen Austausch unter EHDS und TEFCA sowie Forschungsdatenextrakte.
Intern bleiben HL7 v2 und DICOM jahrelang bestehen, da jeder Analysator, Scanner und jedes Legacy-Modul sie spricht. FHIR gewinnt an den Rändern: Patientenzugang, Apps, die innerhalb des EHR gestartet werden (SMART on FHIR), Entscheidungsunterstützung (CDS Hooks), Abonnements für ereignisgesteuerte Integration, regionaler und nationaler Austausch unter der EHDS und TEFCA sowie Forschungsdatenextraktionen. Viele Krankenhäuser betreiben heute einen FHIR-Server, der von der Engine gespeist wird, als ihre Integrationsschicht für alles außerhalb des Gebäudes; siehe Standards für die Interoperabilität im Gesundheitswesen: die Karte.
In Anpheros
Die Anpheros Platform sitzt am FHIR-Rand der Krankenhausintegration: ein FHIR R4-Datensatz, in den ein Krankenhaus oder eine Klinik mit Zustimmung des Patienten schreiben und aus dem es lesen kann. Dieser wird über den Labor-Konnektor (HL7 v2 ORU, CSV oder JSON) aus dem eigenen Krankenhaus-System gespeist, mit Webhooks und Herkunftsnachweisen pro Quelle. Sie ersetzt weder das KIS noch die Engine.
Die Anpheros Platform sitzt an diesem Rand: ein FHIR R4-Datensatz, in den ein Krankenhaus oder eine Klinik mit Zustimmung des Patienten schreiben und aus dem es lesen kann, gespeist durch die eigene Integration des Krankenhauses (der Labor-Konnektor nimmt HL7 v2 ORU, CSV oder JSON entgegen), mit Webhooks zur Änderungsbenachrichtigung und Herkunftsangaben pro Quelle. Sie ersetzt nicht das KIS oder die Engine; sie gibt dem Patienten eine Akte, die ihn aus dem Gebäude begleitet.
Verwandte Seiten
- Schnittstellen-Engines erklärt
- Wie man ein Laborsystem mit einem EHR integriert
- HL7 v2 Nachrichten erklärt: ADT und ORU
- PACS vs RIS vs VNA
- Fernüberwachung von Patienten mit FHIR
- Standards für die Interoperabilität im Gesundheitswesen: die Karte
- Kliniksysteme mit FHIR integrieren (Entwicklerseite)
Quellen
- HL7 Version 2 Produkt-Suite
- IHE IT Infrastructure Technical Framework
- IHE Devices Domain (Patient Care Device Profiles)
- HL7 FHIR R4: Messaging und Workflow
- HL7 v2-zu-FHIR Implementierungsleitfaden
Häufige Fragen
Sollte ein neues Krankenhaus alles mit FHIR integrieren?
Nicht alles. Analysatoren, Scanner und die meisten Abteilungssysteme sprechen HL7 v2 und DICOM, und das wird sich nicht bald ändern. Verwenden Sie FHIR für patientenbezogene, externe und neue Integrationen und eine Engine zur Überbrückung.
Was ist der Unterschied zwischen einem KIS und einem EHR?
Die Verwendung variiert je nach Land. KIS bedeutet oft das administrative und klinische Krankenhausinformationssystem zusammen; EHR betont die klinische Akte. In Integrationsbegriffen sind beide das System, das die Identität, Aufnahmen und die Akte besitzt.
Wie viele Schnittstellen hat ein mittelgroßer Krankenhaus?
Typischerweise fließen zwischen fünfzig und einigen hundert Nachrichten durch die Engine, wobei jede Richtung und jedes empfangende System gezählt wird. Der Überwachungsbildschirm der Engine ist der Ort, an dem Integrationsteams leben.
Wer ist für die Integration in einem Krankenhaus verantwortlich?
Das IT-Integrationsteam des Krankenhauses, normalerweise mit Unterstützung des Anbieters der Engine, und jeder Abteilungsanbieter für seine Seite. Nationale Programme und IHE-Profile reduzieren, entfernen aber nicht die Projektarbeit.
Kostenlos in der Sandbox testen
Ihr erster FHIR-Aufruf in 5 Minuten. Eine HL7 FHIR R4 API mit der Zustimmung des Patienten: probieren Sie sie in der Sandbox aus und verbinden Sie dann Ihre eigene App oder Ihr Kliniksystem.
Kostenlos · 30 synthetische Patienten · keine Karte
Anpheros entwickelt eine Patientenakte, die der Patient kontrolliert und mit jeder Klinik teilen kann, auf einer HL7 FHIR R4-Plattform mit Sitz in der EU. Diese Anleitungen helfen Ihnen, Ihre Gesundheit zu verstehen und zu organisieren; sie ersetzen nicht Ihren Arzt.
Über Anpheros →