FELIX gehört nicht zum Standardlieferumfang von RheDAT und muss als Zusatzlizenz über ITC erworben werden. Ohne Aktivierung über einen gültigen Lizenzcode arbeitet die Schnittstelle nicht auf dem Server, kann aber dennoch konfiguriert und manuell getestet werden. Die Konfiguration von FELIX geschieht in einer eigenen Verwaltung, die Sie über Administration|ITC-FELIX öffnen.
FELIX ist ein Zusatzprodukt zu RheDAT, das die Verbindung mit Klinikinformationssystemen und Kliniklabors über HL7, HCM und xDT ermöglicht und folgende Verbindungstechniken zur Verfügung stellt:
•Dateibasierte Übertragung
•Übertragung per MLLP (Minimum Link Layer Protokoll, im HL7 Umfeld üblich) im Netzwerk
Es können Eingangskanäle definiert werden, die folgende Protokolle unterstützen:
•HL7 (V2 (ORU und ADT)
•HCM (z.B. SAP ISH*)
•xDT (z.B. BDT, LDT, GDT) für Sonderfälle
Daneben können Ausgangskanäle definiert werden.
•HL7 MDM Übertragung freigegebener Arztbriefe als embedded PDFs (Base64 kodiert) an das Archiv
•HL7 ORU Übertragung von im Dictionary gewählten Items
Die FELIX-Verwaltung
Sie öffnen die FELIX-Verwaltung in RheDAT über Administration|ITC-FELIX. Die Verwaltung erscheint mit einem eigenen Ribbon-Reiter FELIX (12) und gliedert sich in den Kanalbaum (1) auf der linken Seite und den Kanaleditor mit Script-Entwicklungsumgebung auf der rechten Seite.
•(1) Liste aller definierten Kommunikationskanäle, jeweils mit Name und Typ.
•(2) Editor für das Verarbeitungsscript des gewählten Kanals.
•(3) Inhalt der geladenen Test-Nachricht (HL7-Quelldaten) zum Testen des Scripts.
•(4) Variablen mit ihren Live-Werten während des Debuggens.
•(5) Ausgabe/Konsole mit Meldungen und dem Aufruf-Trace der Schnittstellenfunktionen.
•(6) Ribbon-Gruppe „Script-Debugger" (Ausführen, Script prüfen, Breakpoint setzen, Schritt hinein, Schritt über).
•(7) Roter Haltepunkt-Bullet im Editorrand; die gerade angehaltene Zeile ist blau markiert.
•(8) Grundeinstellungen des Kanals (Bezeichnung, Kanaltyp, Übergabepfad bzw. Bindung, Dateispezifikation).
•(9) Übertragungsart (dateibasiert oder Netzwerk/MLLP), Aktivierung, Zeichensatz und Acknowledge.
•(10) Globale, kanalübergreifende Optionen (Pufferdauer, automatische Bereinigung).
•(11) Ribbon-Gruppe „Schnittstellenkanal" (Neuer Kanal, Speichern, Kanal löschen, Testnachricht lesen, Standard-Script).
•(12) Ribbon-Reiter „FELIX".
Kanäle anlegen und bearbeiten
Über die Ribbon-Gruppe „Schnittstellenkanal" (11) legen Sie mit Neuer Kanal einen Kanal an, übernehmen Änderungen mit Speichern und entfernen den markierten Kanal mit Kanal löschen. Ein Klick auf einen Eintrag im Baum (1) lädt den Kanal in den Editor; im Baum werden Name und Typ angezeigt.
Geben Sie jedem Kanal unter (8) eine aussagekräftige Bezeichnung, über die er im Baum leicht zu finden ist. Darunter wählen Sie den Kanaltyp: Inbound-Kanäle lesen Daten aus externen Quellen in die RheDAT-Datenbank ein (z.B. HL7 aus KIS oder Labor), Outbound-Kanäle übergeben Daten aus RheDAT an externe Systeme (z.B. freigegebene Briefe als MDM-Nachricht ans Klinikarchiv).
Bei HL7 Inbound Nachrichten unterstützt FELIX
•ADT Nachrichten
•ORU Nachrichten für Zahlen- und Textbefunde
Bei HL7 Outbound-Nachrichten unterstützt FELIX
•MDM Nachricht mit Base64 eingebettetem PDF Dokument
•OUT Befundnachrichten (ORU) bei Änderung von im Dictionary dafür markierten Items. Diese müssen im Datendictionary entsprechend markiert werden:
Unter (9) entscheiden Sie, ob die Daten auf diesem Kanal dateibasiert oder über Netzwerk/MLLP übertragen werden. Abhängig davon geben Sie unter (8) entweder einen Dateipfad mit Dateispezifikation (z.B. *.hl7) oder eine IP-Bindung mit Port an.
Ebenfalls unter (9) aktivieren Sie den Kanal und schalten den Zeichensatz zwischen ANSI und UTF8 um. Bei MLLP-Übertragung wählen Sie, ob Nachrichten mit einer normalen MLLP-Acknowledge-Sequenz oder einer HL7-Acknowledge-Nachricht quittiert werden. Diese Informationen erhalten Sie aus der Konfiguration der Gegenstelle.
Globale Optionen
Die Optionen unter (10) gelten kanalübergreifend für alle Kanäle.
Mit Gepufferte Nachrichten nach … Tagen löschen legen Sie fest, wie lange FELIX eingelesene Nachrichten aufhebt. Hintergrund: FELIX übersetzt eingehende Nachrichten zunächst aus dem Quellformat (HL7, HCM oder xDT) in ein Zwischenformat und puffert sie in der Datenbank, sobald sie empfangen werden – so kann ohne Verzögerung empfangen werden. Anschließend erfolgt asynchron die Verarbeitung über die Kanal-Scripte; korrekt verarbeitete Nachrichten werden automatisch aus dem Puffer gelöscht. Lässt sich eine Nachricht nicht verarbeiten (z.B. weil Stammdaten zu einem gerade geöffneten Patienten gehören oder Befunde noch keinem Patienten zugeordnet werden können), bricht die Verarbeitung ab und belässt die Nachricht im Puffer. So werden Befunde auch dann noch zugeordnet, wenn der Patient erst nach Eintreffen der Nachrichten angelegt wird. Nachrichten, die länger als die angegebene Zeit im Puffer liegen, werden automatisch entfernt; der Wert 0 schaltet diese Bereinigung ab (nicht empfohlen).
Mit Nicht „angefasste" Akten nach … Tagen löschen bestimmen Sie, nach wie vielen Tagen von FELIX angelegte Patientenakten wieder entfernt werden, in denen über den RheDAT-Client keinerlei Eintragungen oder Änderungen vorgenommen wurden. Das ist sinnvoll, weil viele Sender nicht genau das gewünschte Patientenkollektiv ausfiltern und so Akten entstehen, die nie geöffnet werden. Vorgabe sind 30 Tage.
Ausgabe freigegebener Dokumente
Wenn die Übertragung ins Klinikarchiv in der Textverarbeitung konfiguriert ist, werden freigegebene Dokumente auf allen definierten MDM Ausgabekanälen ausgegeben!
Die MDM Nachrichten T02 (Versenden eines Dokuments ans Archiv) und T11 (Storno eines bereits versendeten Dokuments bei Rücknahme der Freigabe) werden basierend auf einem Template erstellt. Dieses enthält einen direkt nutzbaren Standard, kann aber komplett an eigene Bedürfnisse angepasst werden. Dabei werden in das Template einfach feste Texte (z.B. Quelle und Ziel im MSH-Segment) oder Variablen eingefügt.
Folgende Variablen stehen zur Verfügung:
Variable |
MDM |
OUT |
Inhalt |
$(now) |
x |
x |
Zeitpunkt der Nachrichtenerstellung im Format <Jahr vierstellig><Monat zweistellig><Tag zweistellig><Stunde (24h), zweistellig><Minute zweistellig><Sekunde zweistellig>. |
$(msgid) |
x |
x |
Eindeutige Nachrichten-ID. |
$(pid) |
x |
x |
KIS Patientennummer des Patienten [leer, wenn keine im Stammdatenblatt angegeben!]. |
$(lastname) |
x |
x |
Nachname des Patienten [leer, wenn keiner im Stammdatenblatt angegeben!]. |
$(firstname) |
x |
x |
Vorname des Patienten [leer, wenn keiner im Stammdatenblatt angegeben!]. |
$(birthdate) |
x |
x |
Geburtsdatum im Format <Jahr vierstellig><Monat zweistellig><Tag zweistellig> |
$(gender) |
x |
x |
Weiblich=F, Männlich=M, Divers=O, Unbekannt=U, Unbestimmt=A |
$(casenum) |
x |
x |
Fallnummer des Visit, zu dem das Dokument erzeugt wurde [leer, wenn keiner angegeben!]. |
$(dockind) |
x |
|
Dokumentenart, wie in RheDAT definiert, dient üblicherweise als Weiche im Archiv, um z.B. Befundbriefe und Bescheinigungen in verschiedene Archivbereiche abzulegen. |
$(visitdate) |
x |
x |
Zeitpunkt des Visits, zu dem das Dokument angelegt wurde. Format siehe $(now). |
$(docdate) |
x |
|
Erzeugungsdatum des Dokuments. Format siehe $(now). [Nur für T02 verfügbar!] |
$(docid) |
x |
|
Dokumentennummer. Diese besteht aus der RheDAT-Dokumentnummer und der Version, damit sie bei jeder freigegebenen Version eindeutig ist. |
$(docfilename) |
x |
|
Dokumentdateiname, gebildet aus <RheDAT> + $(docid) + ".pdf" |
$(content) |
x |
|
Inhalt des PDF Dokuments in Base64-Kodierung |
$(visitid) |
|
x |
Eindeutige Nummer des Visits, zu dem die Daten übertragen werden. Achtung: Wenn Daten in diesem Visit nachgetragen werden, wird die VisitID wiederverwendet, da diese zum Visit gehört. Das gilt auch dann, wenn der Visit zeitlich verlegt wurde! |
Bei der OUT (Outbound ORU) Nachricht kann der Nachrichtenbody als Template verändert werden. Die Items selbst werden als OBX Segmente ausgegeben. Dabei werden Zahlen als NM Typ mit Einheit, Kodierte Felder und einzeilige Texte als TX und Freitextfelder als FT Typ ausgegeben. Der Aufbau der OBX Records ist nicht modifizierbar:
OBX|1|NM|RHVASAKTIV^Aktivität (Patient)||100|mm|||||F
OBX|2|TX|BEHARZT^Behandler||Dr. Dulliöh||||||F
OBX|3|FT|DAUDIAG^Dauerdiagnosen||F34.- Anhaltende affektive Störungen\N\B25.2 Pankreatitis durch Zytomegalieviren\N\A46 Erysipel [Wundrose]\N\D64.2 Sekundäre sideroachrestische [sideroblastische] Anämie durch Arzneimittel oder Toxine\N\G63.3 Polyneuropathie bei sonstigen endokrinen und Stoffwechselkrankheiten||||||F
Verarbeitungsscript für Eingangskanäle
Die Verarbeitung von Eingangskanälen erfolgt über Scripts, da es trotz exakter Standards (HL7, HCM) in der Praxis viele einrichtungsspezifische Konfigurationen und Erweiterungen bis hin zur semantischen Redefinition von Feldern gibt. Bei Anlage eines Eingangskanals wird ein Vorgabescript geladen, das die meisten Fälle abdeckt und bei Bedarf angepasst werden kann. Der Script ist das Zwischenglied zwischen der vorverarbeiteten Nachricht und der RheDAT-Patientenakte. Halten sich Kliniksystem und -Labor sauber an den HL7-Standard, muss er meist nicht angepasst werden. Für Anpassungen sind Programmierkenntnisse in Pascal erforderlich; ein fehlerhafter Script führt zu einer Fehl- oder Nichtfunktion des Kanals. In komplexen Fällen können Sie den ITC-Service mit den Anpassungen beauftragen. Wie man diese Scripte erstellt, sowie eine Funktionsreferenz finden Sie unter Scripting in FELIX.
Der Script-Editor (2) ist der zentrale Bereich der Verwaltung. Rechts daneben zeigt (3) den Inhalt einer geladenen, bereits vorverarbeiteten HL7- oder HCM-Nachricht. Grundsätzlich sind Nachrichten in Segmente unterteilt, die teils mehrfach vorkommen. Die Verarbeitung geschieht segmentweise mit der Funktion NextSegment. Innerhalb eines Segments lesen Sie Werte bestimmter Positionen mit GetData, die bei HL7 folgenden Aufbau haben:
Feldposition - Wiederholung - Subfeldposition - SubSubfeldposition, z.B. 3-1-2-1
Um die Scripterstellung zu vereinfachen, können Sie aus den HL7-Quelldaten (3) per Ziehen und Ablegen passende GetData-Kommandos direkt in den Script ziehen.
Bei HCM sind die Positionsbezeichnungen mit den Feldnamen identisch. Da das HCM-Format starr ist, führen Erweiterungen dort zwangsläufig dazu, dass sich nachfolgende Positionen verschieben und die Vorverarbeitung fehlschlägt. Wurde Ihr HCM-Format erweitert, finden Sie bei HCM-Kanälen den zusätzlichen Reiter Strukturdaten für Parser, in dem Sie eigene Felddefinitionen einfügen können.
Script-Debugger
Sie entwickeln und testen den Script direkt in der Verwaltung – mit Haltepunkten (Breakpoints) und schrittweiser Ausführung. Laden Sie dazu zunächst über Testnachricht lesen (11) eine echte HL7- oder HCM-Datei; deren vorverarbeiteter Inhalt erscheint in (3) und dient als Testnachricht. Mit Standard-Script (11) laden Sie jederzeit das zum Kanaltyp passende Vorgabescript und verwerfen damit alle Änderungen.
Die Werkzeuge des Debuggers finden Sie in der Ribbon-Gruppe „Script-Debugger" (6):
•Script prüfen kompiliert den Script und meldet Syntaxfehler in der Ausgabe (5), ohne ihn auszuführen.
•Ausführen (F9) führt den Script gegen die geladene Testnachricht aus. An einem Haltepunkt hält der Lauf an; ein erneutes Ausführen (F9) setzt fort.
•Breakpoint setzen (F5) schaltet in der aktuellen Zeile einen Haltepunkt um. Sie können einen Haltepunkt auch direkt durch Klick in den linken Rand (Gutter) des Editors setzen. Es ist immer nur ein Haltepunkt aktiv – ein neuer ersetzt den vorherigen.
•Schritt hinein (F7) und Schritt über (F8) führen den Script zeilenweise weiter.
Ein gesetzter Haltepunkt erscheint als roter Bullet im linken Editorrand (7); die gerade angehaltene Zeile ist blau hervorgehoben. Während der Script angehalten ist, zeigt das Variablen-Panel (4) die aktuellen Werte aller Variablen (Name und Wert) an, sodass Sie den Programmablauf genau nachvollziehen können.
In der Ausgabe (5) erscheinen die Meldungen Ihres Scripts (WriteLn, Debug) und zusätzlich ein automatischer Aufruf-Trace der internen Schnittstellenfunktionen mit ihren Parametern. So sehen Sie genau, was der Script aus der Nachricht liest und an die Funktionen übergibt, z.B.:
> NextSegment -> 'pid'
> GetData('3-1-1-1') = '888888888'
> FindOrCreateSubject('888888888', 'Mustermann', 'Max', 15.06.1980)
Die Ausgabe wird bei jedem Lauf automatisch geleert. Ein typischer Test besteht also darin, eine Testnachricht zu laden, einen Haltepunkt an der interessierenden Stelle zu setzen, mit Ausführen (F9) bis dorthin zu laufen und dann über die Variablen (4) und den Aufruf-Trace (5) das Verhalten zu prüfen – bei Bedarf zeilenweise mit F7/F8. Testläufe schreiben keine Daten dauerhaft in die Akte; sie dienen ausschließlich der Entwicklung.