:quality(80))
Eine teleradiologische Integration verbindet mehrere Systeme mit unterschiedlichen Aufgaben. Das KIS oder RIS liefert den Auftrag, die Bildgebung erzeugt die Untersuchung und der fertige Befund muss anschließend wieder in der klinischen Dokumentation verfügbar sein.
HL7 und DICOM schaffen dafür eine gemeinsame technische Grundlage. Entscheidend bleibt jedoch, welche Nachrichten, Dienste, Datenfelder und Übertragungsrichtungen in der konkreten Systemlandschaft tatsächlich umgesetzt werden.
Fragen zur Einbindung
H2: Wie funktioniert die Anbindung von KIS, RIS und PACS?
Eine belastbare KIS-/RIS-Anbindung beginnt mit der Aufnahme der vorhandenen Systeme und klinischen Arbeitsabläufe. Auf dieser Grundlage werden die benötigten Datenflüsse, technischen Endpunkte und Verantwortlichkeiten festgelegt.
System- und Workflowanalyse: Erfasst werden die beteiligten KIS-, RIS- und PACS-Systeme, die vorhandenen Schnittstellen sowie der vorgesehene Ablauf vom Auftrag bis zum Befundrücklauf.
Schnittstellenspezifikation: Festgelegt werden Nachrichtentypen, Übertragungsrichtungen, Feldbelegungen, Identifikatoren, lokale Codes und technische Endpunkte.
Mapping und Konfiguration: Die Daten aus den klinischen Quellsystemen werden auf die im Zielsystem benötigten Felder, Codes und Verarbeitungsregeln abgebildet.
Test und Abnahme: Definierte Testfälle prüfen den Auftragsweg, die Zuordnung der Bilddaten, Statusmeldungen, Textbefunde, Befunddokumente und das Verhalten bei Fehlern.
Produktivsetzung und Betrieb: Nach erfolgreicher Abnahme wird die Schnittstelle in den produktiven Betrieb überführt. Monitoring, Fehlerbehandlung und geregelte Änderungsprozesse unterstützen anschließend den stabilen Betrieb.
Warum eine vorhandene HL7-Schnittstelle noch keine vollständige Integration ist
HL7 und DICOM sind Standardfamilien, keine fertig konfigurierten Plug-and-play-Verbindungen. Zwei Systeme können denselben Standard unterstützen und sich dennoch bei Versionen, Pflichtfeldern, lokalen Codes oder der Verarbeitung von Statusmeldungen unterscheiden.
Vor dem produktiven Betrieb muss deshalb festgelegt werden, welche Informationen in welcher Richtung übertragen werden und wie Fehler, Abweichungen oder unvollständige Daten behandelt werden.
Für die Anbindung an Radiology Advanced wird der benötigte Workflow gemeinsam mit der Klinik und den beteiligten Systemen abgegrenzt. Anschließend werden Nachrichten, Identifikatoren, Feldbelegungen und technische Endpunkte aufeinander abgestimmt.
Welche HL7-Nachrichten werden für Aufträge und Befunde genutzt?
Die derzeitige HL7-v2-Anbindung von Radiology Advanced konzentriert sich auf drei Informationsflüsse: Auftragsdaten, Textbefunde und Befunddokumente. Weitere Nachrichtentypen werden einbezogen, wenn sie für das jeweilige Projekt vereinbart und technisch umgesetzt werden.
Aufträge werden über ORM aus dem KIS oder RIS übernommen. In der vereinbarten Schnittstellenausprägung wird darüber auch die Statusmeldung zur erteilten rechtfertigenden Indikation verarbeitet.
Welche Felder, Trigger-Ereignisse und Codes verwendet werden, richtet sich nach dem Zielsystem und der projektbezogenen Schnittstellenbeschreibung.
Der Textbefund wird über ORU an das klinische System übertragen. Dadurch kann er dem richtigen Patienten, Fall und Auftrag zugeordnet und ohne zusätzlichen manuellen Übertragungsschritt im KIS oder RIS bereitgestellt werden.
Die konkrete Nachrichtenausprägung und Feldbelegung werden für das jeweilige Zielsystem festgelegt.
Zusätzlich zum Textbefund können Befunddokumente als PDF über MDM übertragen werden. Das konkrete Trigger-Ereignis und die Feldbelegung werden im jeweiligen Integrationsprojekt abgestimmt.
Die allgemeine Bezeichnung „MDM-Schnittstelle“ reicht deshalb nicht aus, um den technischen Datenweg vollständig zu spezifizieren.
Die Bildübertragung erfolgt im beschriebenen Workflow über DICOM C-STORE. Dabei sendet das klinische Quellsystem die DICOM-Objekte an das konfigurierte Ziel der Teleradiologie.
Weitere DICOM-Dienste wie Modality Worklist, MPPS oder Storage Commitment sind nicht Bestandteil dieser Anbindung. Die Ausfallsicherheit der Übertragung wird deshalb nicht durch Storage Commitment, sondern durch die Puffer- und Nachlieferlogik der Übertragungsschicht unterstützt.
Kann die Gegenstelle DICOM-Objekte vorübergehend nicht annehmen oder ist die Verbindung unterbrochen, werden noch nicht übertragene Objekte lokal gepuffert. Sobald das Ziel wieder erreichbar ist, wird die Übertragung automatisch erneut angestoßen.
Die Warteschlange entkoppelt einen vorübergehenden Ausfall der Gegenstelle vom klinischen Versandprozess. Sie ist Bestandteil der Übertragungsarchitektur und nicht mit dem DICOM-Dienst Storage Commitment gleichzusetzen.
Welche technischen Details entscheiden über die Integration?
Die meisten Abstimmungen entstehen nicht bei der Frage, ob HL7 oder DICOM grundsätzlich verfügbar sind. Maßgeblich sind die Details der jeweiligen Implementierung.
Identifikatoren:
Patienten-ID, Fallnummer, Auftragsnummer und Accession Number müssen über alle beteiligten Systeme konsistent zugeordnet werden. Abweichungen können dazu führen, dass Aufträge, Bilddaten oder Befunde nicht richtig zusammengeführt werden.
Zeichenkodierung
HL7 und DICOM kennzeichnen Zeichensätze auf unterschiedliche Weise. Für HL7 ist unter anderem MSH-18 relevant, bei DICOM das Attribut Specific Character Set mit dem Tag 0008,0005. Eine nicht abgestimmte Kodierung kann Namen und andere Freitexte fehlerhaft darstellen.
Z-Segmente
HL7 erlaubt lokal definierte Segmente mit dem Präfix Z. Ihre Bedeutung muss zwischen Sender und Empfänger vereinbart und gegebenenfalls über Mapping-Regeln umgesetzt werden.
Auftrags- und Prozedurcodes
Lokale Leistungskataloge müssen eindeutig auf die im Zielsystem erwarteten Codes abgebildet werden. Ein bestimmter übergreifender Codekatalog ist nicht automatisch für jedes Projekt vorgegeben.
Bestätigungen und Fehlerantworten
Im Schnittstellenkonzept ist festzulegen, welche HL7-Acknowledgments und DICOM-Statusantworten erwartet werden. Zusätzlich muss geregelt sein, wie bei Ablehnungen, Zeitüberschreitungen oder fehlerhaften Daten reagiert wird.
Welche Informationen werden für die technische Anbindung benötigt?
Für eine belastbare technische Bewertung werden Angaben zur vorhandenen Systemlandschaft und zum gewünschten Workflow benötigt. Dazu gehören insbesondere:
eingesetzte KIS-, RIS- und PACS-Systeme einschließlich der relevanten Versionen
vorhandene Schnittstellen- und Herstellerdokumentationen
benötigte Übertragungsrichtungen
Patienten-, Fall-, Auftrags- und Untersuchungsidentifikatoren
lokale Leistungs-, Verfahrens- und Statuscodes
verwendete HL7-Versionen, Nachrichtentypen und Z-Segmente
benötigte DICOM-Dienste und beteiligte Application Entities
Netzwerk-, Berechtigungs- und Sicherheitsanforderungen
ACK-, Fehler- und Wiederholungsprozesse
Testfälle, Abnahmekriterien und technische Ansprechpartner
Auf dieser Grundlage lassen sich der benötigte Integrationsumfang, projektspezifische Mapping-Regeln und die erforderlichen Tests bestimmen.
Warum der Produktname allein wenig über den Aufwand aussagt
Die Anbindbarkeit eines KIS, RIS oder PACS lässt sich nicht allein aus dem Herstellernamen ableiten. Maßgeblich sind die tatsächlich verfügbare Schnittstellenversion, die unterstützten Nachrichten und Dienste, lokale Erweiterungen sowie die Konfiguration am jeweiligen Standort.
Für eine belastbare Einschätzung werden deshalb die Schnittstellenbeschreibung und die benötigten Datenflüsse herangezogen. Dadurch wird sichtbar, welche Bestandteile übernommen werden können und an welchen Stellen ein projektspezifisches Mapping erforderlich ist.
Welche Rolle spielen FHIR und DICOMweb?
FHIR und DICOMweb können bestehende Integrationswege ergänzen. ISiK beschreibt FHIR-Ressourcen und REST-basierte Schnittstellen für definierte Anwendungsfälle in Krankenhausinformationssystemen. Daraus folgt jedoch nicht automatisch, dass ein bestehender teleradiologischer Auftrags-, Bild- und Befundweg ersetzt wird.
Entscheidend bleibt, welche Nachrichten, Ressourcen, Dienste, Übertragungsrichtungen und Fehlerprozesse die beteiligten Systeme tatsächlich unterstützen. Ob FHIR oder DICOMweb eingesetzt werden, richtet sich deshalb nach der vorhandenen Systemlandschaft und dem vereinbarten Integrationsmodell.
Wie werden IT-Sicherheit und regulatorischer Betrieb berücksichtigt?
Teleradiologische Schnittstellen verarbeiten Gesundheitsdaten und benötigen geschützte Übertragungswege, geregelte Zugriffe und nachvollziehbare technische Prozesse.
Bei DICOM kommt hinzu, dass die Objekte neben den Bilddaten weitere Inhalte und private Datenfelder enthalten können. Eingehende Objekte sollten deshalb entsprechend dem Einsatzzweck geprüft und verarbeitet werden. Weitere Informationen enthält der Beitrag „DICOM-Sicherheit: Schutzmaßnahmen für Klinik und Praxis“.
Eine funktionierende Schnittstelle ersetzt nicht die strahlenschutzrechtlichen Voraussetzungen für den teleradiologischen Betrieb. Die Genehmigungsvoraussetzungen ergeben sich aus § 12 Absatz 1 Nummer 4 in Verbindung mit § 14 Absatz 2 Strahlenschutzgesetz. Anforderungen an den Betrieb einer Röntgeneinrichtung zur Teleradiologie enthält § 123 Strahlenschutzverordnung.
Weitere Informationen zum regulatorischen Rahmen enthält der Beitrag „Das Strahlenschutzgesetz in der Teleradiologie“.
Datenschutz, geschützte Übertragung, Zugriffssteuerung, Audit-Logs und Fallback-Prozesse werden auf der Landingpage „Datenschutz und IT-Sicherheit in der Teleradiologie“ erläutert.
Nach der Produktivsetzung bleibt die Schnittstelle Bestandteil des laufenden IT-Betriebs. Welche Leistungen dabei dauerhaft anfallen, beschreibt der Beitrag „Warum eine HL7-Schnittstelle laufende Kosten verursacht“.
FAQ
Häufige Fragen
Die technische Anbindung basiert auf abgestimmten HL7- und DICOM-Datenflüssen. Zunächst werden Systeme, Schnittstellen und klinische Abläufe aufgenommen. Anschließend werden Nachrichtentypen, Feldbelegungen, Identifikatoren, technische Endpunkte, Fehlerprozesse und Testfälle festgelegt.
Der beschriebene Workflow nutzt ORM für Aufträge und vereinbarte Statusmeldungen, ORU für Textbefunde und MDM für Befunddokumente als PDF. Die konkrete Nachrichtenausprägung wird für das jeweilige Zielsystem festgelegt.
Der Bildtransfer erfolgt über DICOM C-STORE. Modality Worklist, MPPS und Storage Commitment sind nicht Bestandteil der hier beschriebenen Anbindung.
Noch nicht übertragene DICOM-Objekte werden lokal gepuffert. Nach Wiederherstellung der Erreichbarkeit wird die Übertragung automatisch erneut angestoßen.
Nein. HL7 und DICOM schaffen eine standardisierte Grundlage, ersetzen aber nicht die Prüfung der konkreten Schnittstelle. Versionen, lokale Erweiterungen, Codes, technische Rollen und unterstützte Dienste müssen vor der Umsetzung abgestimmt werden.
Benötigt werden insbesondere Informationen zu den eingesetzten Systemen, Schnittstellenversionen, Datenflüssen, Identifikatoren, lokalen Codes, Netzwerkbedingungen, Fehlerprozessen und Abnahmekriterien.
Die Dauer hängt unter anderem von der Anzahl der beteiligten Systeme und Datenflüsse, der Verfügbarkeit technischer Dokumentationen, dem erforderlichen Mapping, den Netzwerkfreigaben sowie den Test- und Freigabeprozessen ab. Eine allgemeingültige Projektlaufzeit lässt sich deshalb nicht nennen.
Nicht automatisch. FHIR und DICOMweb können bestehende Datenwege ergänzen oder in einzelnen Anwendungsfällen ablösen. Entscheidend ist, welche Ressourcen, Dienste und Übertragungsrichtungen die beteiligten Systeme tatsächlich unterstützen.
:quality(80))
:quality(80))
:quality(80))
:quality(80))