Kurze Antwort: Eine Labor-Schnittstelle hat zwei Richtungen. Aufträge gehen vom KIS zum Laborinformationssystem (LIS) als HL7 v2 ORM^O01 oder OML^O21 Nachrichten (oder als FHIR ServiceRequest), und das LIS antwortet mit ORR/ORL und später mit Ergebnissen als ORU^R01 (oder FHIR DiagnosticReport mit Observations). Die schwierigen Teile sind nicht die Nachrichten, sondern die Details darin: Placer- und Filler-Nummern, die Ergebnisse mit Aufträgen verknüpfen, Ergebnisstatus (vorläufig, endgültig, korrigiert), Abnormalitätskennzeichen, Einheiten und Referenzbereiche, Probeninformationen, Mikrobiologie mit ihren mehrteiligen Ergebnissen und Code-Mapping zu LOINC. Gut gemacht landet jedes Ergebnis beim richtigen Patienten, zum richtigen Auftrag und an der richtigen Stelle in der Akte, mit seiner Bedeutung intakt.
Schritt 1: Abläufe festlegen
Der erste Schritt bei der Anbindung eines Laborinformationssystems an ein KIS ist die Abstimmung mit dem Labor, welche Abläufe es gibt: Bestellungen, Status-Updates zu Bestellungen, Ergebnisse, Korrekturen, Stornierungen, Zusatz- und Reflexuntersuchungen sowie ein ADT-Demografie-Feed an das LIS. Die Parteien legen auch die HL7-Version fest, meist 2.3.1 oder 2.5.1, und den Transport, typischerweise MLLP mit Bestätigungen.
Entscheiden Sie mit dem Labor, welche Abläufe existieren: Aufträge raus (oder erhält das Labor Papier und registriert sich selbst?), Auftragsstatus-Updates, Ergebnisse rein, Korrekturen, Stornierungen, Zusatztests, Reflex-Tests und Demografie (ADT-Feed an das LIS, damit es den Patienten kennt, bevor die Probe eintrifft). Zeichnen Sie die Sequenz für ein normales Ergebnis, ein korrigiertes Ergebnis und einen stornierten Auftrag. Legen Sie die HL7-Version fest (2.3.1 und 2.5.1 sind am gebräuchlichsten) und den Transport (MLLP mit ACKs; manchmal Dateien). Siehe HL7 v2 Auftragsnachrichten.
Schritt 2: Die Ergebnisnachricht, Feld für Feld
Ein Laborergebnis kommt im KIS als HL7 v2 ORU^R01-Nachricht an: MSH identifiziert Sender und Empfänger, PID den Patienten, PV1 den Besuch, ORC und OBR enthalten die Bestellnummern des Auftraggebers und Ausführenden, das bestellte Panel und den Berichtsstatus, und jedes OBX enthält ein Analyten mit seinem LOINC-Code, Wert, Einheiten, Referenzbereich, abnormalem Flag und Ergebnisstatus.
MSH|^~\&|LIS|CENTRALLAB|EHR|GENHOSP|20260314130500||ORU^R01^ORU_R01|RES0001|P|2.5.1
PID|1||MRN-00012345^^^GENHOSP^MR||DOE^JANE||19800523|F
PV1|1|O|CLINIC-3^^^GENHOSP
ORC|RE|PLC-778812^EHR|FIL-556701^LIS|||||||||42^SMITH^JOHN
OBR|1|PLC-778812^EHR|FIL-556701^LIS|58410-2^CBC panel - Blood by Automated count^LN|||20260314084000|||||||||42^SMITH^JOHN||||||20260314130000|||F
OBX|1|NM|718-7^Hemoglobin [Mass/volume] in Blood^LN||10.9|g/dL|12.0-15.5|L|||F|||20260314125800
OBX|2|NM|6690-2^Leukocytes [#/volume] in Blood by Automated count^LN||6.4|10*3/uL|4.0-10.0|N|||F|||20260314125800
OBX|3|NM|777-3^Platelets [#/volume] in Blood by Automated count^LN||230|10*3/uL|150-400|N|||F|||20260314125800
NTE|1||Mild normocytic anaemia; suggest iron studies if clinically indicated.
- ORC-2 / OBR-2 Placer-Nummer und ORC-3 / OBR-3 Filler-Nummer: die Verknüpfung zum Auftrag. OBR-4: das Panel, kodiert (LOINC
LN). OBR-7: Zeitpunkt der Probenentnahme. OBR-22: Zeitpunkt des Ergebnisberichts. OBR-25: Ergebnisstatus für den gesamten Auftrag (Pvorläufig,Fendgültig,Ckorrigiert,Xstorniert). - OBX-2: Werttyp (
NMnumerisch,STString,TXText,CE/CWEkodiert,SNstrukturiert numerisch wie<^5). OBX-3: das Analyten, kodiert. OBX-5: der Wert. OBX-6: Einheiten, idealerweise UCUM (10*3/uL, nichtK/µL). OBX-7: Referenzbereich als Text. OBX-8: Abnormalitätskennzeichen (L,H,LL,HH,A,N). OBX-11: Ergebnisstatus pro Analyt (P,F,C,X,Dgelöscht). OBX-14: Beobachtungszeitpunkt. OBX-19: Analysezeitpunkt. - NTE: Kommentare, an die OBR oder eine bestimmte OBX nach Position angehängt.
- SPM (2.5+): Probentyp (SNOMED CT), Entnahmezeitpunkt, Eingangszeitpunkt, Zustand.
Schritt 3: Die Sonderfälle
Die Sonderfälle, die eine Laboranbindung handhaben muss, sind korrigierte Ergebnisse (Status C mit den ursprünglichen Bestellnummern, die ersetzen und alarmieren statt zu löschen), vorläufige und dann endgültige Ergebnisse, Mikrobiologie mit Organismen und Empfindlichkeiten, die per Unter-ID verknüpft sind, Text-Ergebnisse und eingebettete PDFs, Reflex- und Zusatzuntersuchungen, Stornierungen sowie Einheiten und Referenzbereiche, die sich ändern, wenn das Labor die Analysegeräte wechselt.
- Korrekturen: eine neue ORU mit
Cin OBR-25 und OBX-11 und denselben Placer/Filler-Nummern; das KIS muss ersetzen, die Änderung kennzeichnen und den Kliniker benachrichtigen. Löschen Sie niemals das Original stillschweigend. - Vorläufig dann endgültig:
P-Ergebnisse (eine Gram-Färbung) gefolgt vonF(die Kultur); die Akte muss den Status anzeigen. - Mikrobiologie: eine OBX für den identifizierten Organismus (kodiert, SNOMED CT), dann Empfindlichkeitsergebnisse als OBX pro Antibiotikum mit dem Organismus als Unter-ID (OBX-4), oft über mehrere Nachrichten hinweg. Hier verstecken sich die meisten Schnittstellenfehler.
- Text-Ergebnisse und PDFs: Pathologie- und einige Chemie-Kommentare kommen als TX-Zeilen oder als eingebettetes PDF (OBX-2
ED); die Akte benötigt sowohl den Text als auch die Datei. - Reflex- und Zusatztests: neue OBRs unter dem ursprünglichen Auftrag oder ein neuer Auftrag, der vom Labor erstellt wurde; vereinbaren Sie, wie sie nummeriert werden.
- Stornierungen:
X-Status, mit den ursprünglichen Nummern. - Einheiten und Bereiche pro Analysator: derselbe Test kann die Einheiten ändern, wenn das Labor die Analysatoren wechselt; die Schnittstelle muss den Bereich mit jedem Ergebnis mitführen und nicht davon ausgehen.
Schritt 4: Codes
Code-Mapping in einer Laboranbindung bedeutet, die lokalen Testcodes des Labors einmalig in einer gepflegten Tabelle in LOINC zu übersetzen und sowohl den lokalen als auch den LOINC-Code in OBX-3 zu senden, Einheiten in UCUM zu normalisieren und Probenarten und Organismen in SNOMED CT zu kodieren. Ohne dieses Mapping können Ergebnisse nicht über Labore hinweg verglichen oder von externen Systemen gelesen werden.
Ordnen Sie die Testcodes des Labors einmal einer gepflegten Tabelle zu LOINC zu und senden Sie sowohl lokale als auch LOINC-Codes in OBX-3 (GLU^Glucose^L~2345-7^Glucose [Mass/volume] in Serum or Plasma^LN). Normalisieren Sie Einheiten auf UCUM. Probentypen und Organismen in SNOMED CT. Die Methode finden Sie unter Lokale Laborcodes zu LOINC zuordnen; ohne sie können Ergebnisse nicht über Labore hinweg getrendet oder von externen Systemen gelesen werden.
Schritt 5: Die FHIR-Alternative
Die FHIR-Alternative zu einer HL7 v2-Laboranbindung verwendet eine ServiceRequest für die Bestellung, eine Observation pro Analyt mit LOINC-Code, UCUM-Menge, Referenzbereich und Interpretation sowie einen DiagnosticReport, der diese mit Status, Ausführendem, Ausstellungszeitpunkt, Schlussfolgerung und PDF gruppiert. Die Zustellung erfolgt über REST-Schreibvorgänge, ein Transaktions-Bundle pro Bericht oder FHIR-Subscriptions.
Mit FHIR ist der Auftrag ein ServiceRequest, die Ergebnisse sind Observations (eine pro Analyt, LOINC-Code, UCUM-Menge, referenceRange, Interpretation), gruppiert nach einem DiagnosticReport, der Status, Leistungserbringer, Ausstellungsdatum, Schlussfolgerung und das PDF trägt, wobei basedOn auf den ServiceRequest verweist. Korrekturen sind Versionen derselben Ressourcen mit Status amended oder corrected. Die Lieferung erfolgt als REST-Schreibvorgänge an den FHIR-Server des KIS, ein Transaktions-Bundle pro Bericht oder Abonnements. Der HL7 v2-zu-FHIR-Leitfaden ordnet jedes Feld oben zu; viele Labore bieten jetzt beides an. Siehe FHIR DiagnosticReport erklärt und FHIR Observation erklärt.
Schritt 6: Testen und Go-Live
Das Testen einer Laboranbindung vor dem Go-Live bedeutet, synthetische Patienten durch jeden Sonderfall laufen zu lassen, einen Tag paralleler Ergebnisse zwischen dem Laborbericht und der KIS-Akte zu vergleichen, Zeitzonen und Sommerzeitübergänge zu überprüfen, die Behandlung von Bestätigungen und Wiederholungen nach einem Ausfall zu verifizieren und ein Bereitschaftsverfahren für fehlgeschlagene Nachrichten zu vereinbaren, wobei das Laboratory Testing Workflow-Profil von IHE als Basis dient.
Testen Sie mit synthetischen Patienten alle Fälle aus Schritt 3; vergleichen Sie einen Tag paralleler Ergebnisse zwischen dem Papier- oder PDF-Bericht und der Akte; überprüfen Sie Zeitzonen und Sommer-/Winterzeitumstellungen; verifizieren Sie die ACK-Verarbeitung und das Wiederholen nach einem Ausfall; vereinbaren Sie ein Bereitschaftsverfahren für fehlgeschlagene Nachrichten. IHEs Laboratory Testing Workflow-Profil und nationale Konformitätssuiten bieten eine getestete Basis.
Design-Fehler, gegen die man sich wappnen muss
Die Fehler, gegen die eine Laboranbindung ausgelegt sein muss, sind Ergebnisse, die einem früheren Besuch zugeordnet werden, Patientenverschmelzungen, die nicht im LIS angewendet werden, Einheitenänderungen nach einem Analysegeräte-Upgrade, die Trends verschieben, korrigierte Ergebnisse, die ohne Alarm überschrieben werden, Mikrobiologie-Empfindlichkeiten, die dem falschen Organismus zugeordnet sind, und Ergebnisse für Tests, für die das KIS keinen Code hat und die in einer Fehlerwarteschlange verschwinden.
Ergebnisse, die einer früheren Begegnung zugeordnet wurden, weil PV1 veraltet war; eine Zusammenführung (ADT A40), die nicht im LIS angewendet wurde; eine Einheitenänderung nach einem Analysator-Upgrade, die Trends stillschweigend verschob; korrigierte Ergebnisse, die ohne Benachrichtigung überschrieben wurden; Mikrobiologie-Empfindlichkeiten, die dem falschen Organismus zugeordnet wurden; ein Labor, das Ergebnisse für einen Test sendet, für den das KIS keinen Code hat, die dann in einer Fehlerwarteschlange verschwinden.
In Anpheros
Der Anpheros Labor-Konnektor akzeptiert ORU^R01, CSV und JSON und erzeugt Observations unter einem DiagnosticReport mit LOINC und UCUM, wobei lokale Codes und die Originaldatei beibehalten werden; der Entwicklerleitfaden zum Import von Laborergebnissen führt Sie durch die kostenlose Sandbox.
Verwandte Seiten
- HL7 v2 ORM und OML Auftragsnachrichten
- HL7 v2 Nachrichten erklärt: ADT und ORU
- Lokale Laborcodes zu LOINC zuordnen
- FHIR DiagnosticReport erklärt
- Labor-Konnektor: HL7 v2, CSV oder JSON zu FHIR
- Interface Engines erklärt
- Laborergebnisse in FHIR importieren (Entwicklerseite)
Quellen
- HL7 v2.5.1 ORU_R01 Referenz (Caristix)
- HL7 v2.5.1 OBX Segment (Caristix)
- IHE Laboratory Technical Framework (LTW)
- HL7 v2-zu-FHIR Implementierungsleitfaden
- HL7 FHIR R4: DiagnosticReport
Häufige Fragen
Welche HL7-Version sollte eine neue Labor-Schnittstelle verwenden?
2.5.1, wenn beide Seiten es unterstützen: es hat SPM für Proben und eine klarere Statusbehandlung. Viele Labore verwenden immer noch 2.3.1, und die Schnittstelle passt sich der älteren Seite an.
Wie werden Ergebnisse mit Aufträgen abgeglichen?
Über die Placer-Auftragsnummer (vom KIS zugewiesen) und die Filler-Auftragsnummer (vom LIS zugewiesen), die in ORC-2/3 und OBR-2/3 sowohl der Auftragsbestätigung als auch des Ergebnisses übermittelt werden. Wenn das KIS die Filler-Nummer nie aufgezeichnet hat, greift der Abgleich auf die Placer-Nummer zurück.
Was ist, wenn das Labor keine LOINC-Codes senden kann?
Ordnen Sie deren lokale Codes auf Ihrer Seite, in der Engine oder im Konnektor, LOINC zu und behalten Sie beide bei. Bestehen Sie darauf, dass das lokale Codesystem stabil ist und neue Tests angekündigt werden.
Ist FHIR für Labor-Schnittstellen bereit?
Ja, für neue Verbindungen, insbesondere außerhalb des Krankenhauses: ServiceRequest, Observation und DiagnosticReport decken Aufträge und Ergebnisse vollständig ab, und nationale Leitfäden profilieren sie. Innerhalb des Krankenhauses werden LIS und Analysatoren noch jahrelang HL7 v2 sprechen.
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

