HL7-Systemkommunikation zwischen

HL7-Systemkommunikation zwischen und Fremdsystemen über Embedded Ensemble von Intersystems

1 ALLGEMEINES... 4 BUSINESS SERVICE UND BUSINESS OPERATION... 5 DATENTRANSFER: ENSEMBLE ANDOK LIVE... 5 DATENTRANSFER ANDOK LIVE ENSEMBLE... 5 2 ARCHITEKTURVARIANTEN... 6 2.1 KOMMUNIKATION MIT ANDOK LIVE UNTER MICROSOFT WINDOWS... 6 2.2 FREMDSYSTEME... 7 INTERPROZESSKOMMUNIKATION... 8 DATEI-AUSTAUSCH PER FTP... 9 DATEI-AUSTAUSCH PER NFS... 9 SZENARIEN UND INHALTE... 10 2.3 PATIENTENVERWALTUNG AN ANDOK LIVE... 10 2.4 OP-SYSTEM AN ANDOK LIVE... 11 2.5 ANDOK LIVE AN DIE LEISTUNGSABRECHNUNG... 11 3 ALLGEMEINE HL7 RICHTLINIEN... 12 3.1 ALLGEMEIN... 12 3.2 HL7-NACHRICHTEN... 12 NACHRICHTEN... 12 SEGMENTE... 12 FELDER... 12 BEGRENZERZEICHEN (SEPARATOREN)... 13 HL7 DATENTYPEN... 13 ZEICHENSATZ... 15 3.3 BOTSCHAFTENBESTÄTIGUNG... 15 EMPFANGSBESTÄTIGUNG... 15 CA - COMMIT ACCEPT... 16 CE - COMMIT ERROR... 16 CR - COMMIT REJECT... 16 4 HL7 NACHRICHTEN... 17 4.1 ÜBERSICHT... 17 NACHRICHTENTYPEN... 17 EREIGNISSE... 17 DARSTELLUNG DER EREIGNISSE... 19 DIE SEGMENTE... 20 DIE EREIGNISSE UND IHRE SEGMENTE... 20 4.2 DIE SEGMENTE UND IHRE FELDER... 22 ALLGEMEIN... 22 MSH - NACHRICHTENKOPF... 24 EVN - EREIGNISTYP... 26 PID PATIENTENIDENTIFIKATION... 26 PV1 FALLINFORMATION FÜR DEN DATENIMPORT... 27 IN1 KOSTENTRÄGER... 28 Druck 12.10.09 Seite 2 von 45

FT1 FINANZIELLE TRANSAKTION... 28 DG1 DIAGNOSEN... 29 PR1 - MAßNAHMEN / PROZEDUREN UND ZEITEN... 30 MRG - PATIENTENZUSAMMENFÜHRUNG... 31 ORC - ALLGEMEINE ANFORDERUNG... 32 MSA - NACHRICHTENBESTÄTIGUNG... 33 OBR - OBSERVATIONS REPORT... 34 OBX OBSERVATION / RESULTS... 35 TXA - TRANSCRIPTION DOCUMENT HEADER SEGMENT... 39 TEST - BOTSCHAFTEN... 40 ADT^A01... 40 ADT^A03... 40 BAR^P01... 40 ORU^R01... 41 ORU^R01... 43 4.3 TEST BOTSCHAFTEN DIE VON ANDOK LIVE EXPORTIERT WERDEN... 44 DFT^P03... 44 BAR^P01... 44 MDM^T02... 44 5 HARDWAREANFORDERUNGEN... 45 Druck 12.10.09 Seite 3 von 45

1 Allgemeines Die Integration von ANDOK live in die Systemlandschaft eines Klinikums erfolgt über den Kommunikationsserver ENSEMBLE als Embedded System. ENSEMBLE übermittelt die Botschaften, die zwischen ANDOK live und den weiteren innerhalb eines Klinikums eingesetzten Softwaresystemen ausgetauscht werden und hat damit die Funktion eines Gateway. Bei den Fremdsystemen kann es sich um einen zentralen Kommunikationsserver, ein KIS oder ein OP-System handeln. ENSEMBLE Datenimport Fremdsystem Datenexport Fremdsystem Fremdsystem Abbildung 1: Architektur der ANDOK live -Kommunikation Die Kommunikation zwischen ANDOK live und ENSEMBLE erfolgt über eine von ENSEMBLE bereit gestellte Business Operation bzw. über einen Business Service, der über eine ODBC- Verbindung direkt auf die ANDOK live -Datenbank zugreift. Die Kommunikation mit einem Fremdsystem erfolgt auf Applikations-Schicht unter Verwendung der HL7-Standards Version 2.2 Version 2.4. Druck 12.10.09 Seite 4 von 45

Business Service und Business Operation Der Business Service und die Business Operation empfangen bzw. senden ANDOK live -Botschaften von oder zu ENSEMBLE. ENSEMBLE wandelt diese Botschaften von oder zu HL7-Botschaften. Die Datentransferrichtung sowie weitere konfigurationsspezifische Parameter werden im Ensemble Management Portal angepasst. Datentransfer: ENSEMBLE ANDOK live Ist das Fremdsystem z.b. die Patientenverwaltung eines KIS so liefert dieses mittels ADT-Botschaften (Admission, Discharge, Transfer) patientenrelevante Daten ( Name, Geburtsdatum,...). Ist das Fremdsystem ein OP-System so liefert dieses zusätzlich Informationen zu Operationen (Saal, Zeit,...). ENSEMBLE schreibt die für ANDOK live relevanten Daten in die ANDOK live -Systemdatenbank. Datentransfer ANDOK live ENSEMBLE Ein Business Service pollt in zyklischen Abständen die EXPORT Tabellen der ANDOK live -Datenbank und holt sich die relevanten Daten. Die ANDOK live -Daten werden an den Business Process weitergeleitet, der daraus eine HL7-Botschaft generiert. ENSEMBLE leitet die HL7-Botschaften dann an das Fremdsystem weiter. Ist das Fremdsystem z.b. ein Softwaresystem zur Kosten und Leistungsrechnung so werden die erbrachten Leistungen mittels DFT-Botschaften an dieses übergeben. ENSEMBLE kann aber auch Nachrichten in einem anderen Format für das Fremdsystem erzeugen. Druck 12.10.09 Seite 5 von 45

2 Architekturvarianten 2.1 Kommunikation mit ANDOK live unter Microsoft Windows Je nach Verfügbarkeit können zwei Varianten realisiert werden: Bei hohen Performance-Ansprüchen und/oder großem Datendurchsatz sollte ENSEMBLE auf einem separaten Rechner laufen. Alternativ dazu können sowohl die ANDOK live - Datenbanken und die Kommunikation auf einem Rechner laufen. Die am Ende des Dokuments genannten Hardwaremindestanforderungen sind hierbei zu beachten: Abbildung 2: ANDOK live unter Windows Sowohl ANDOK live als auch ENSEMBLE sind als 32-Bit-Applikationen für Windows realisiert. ENSEMBLE und ANDOK live unterstützen Windows 2000, Windows XP, Windows 2003 Server und Windows Vista. Druck 12.10.09 Seite 6 von 45

2.2 Fremdsysteme Die Fremdsysteme kommunizieren in jedem Fall direkt mit ENSEMBLE. Dabei ist es unerheblich, ob es sich bei dem Fremdsystem um ein KIS, ein OP-System oder einen globalen Kommunikationsserver handelt, der seinerseits andere Systeme integriert. Abbildung 3: Architektur mit OP-System oder KIS als Fremdsystemen KIS- System OP-System Kommunikationsserver HL7 ODBC Datenbank ENSEMBLE Abbildung 4: Architektur mit Kommunikationsserver als Fremdsystem Druck 12.10.09 Seite 7 von 45

Die Schnittstelle zwischen dem Fremdsystem und ENSEMBLE wird über Business Operations abgewickelt. Folgende Datentransferarten stehen zur Verfügung. Interprozeß-Kommunikation über IP-Sockets Datenträger-Kommunikation über direkten Datei-Zugriff Datenträger-Kommunikation mit Dateiaustausch per FTP Weitere Unterscheidungen betreffen das Bestätigungsverfahren Keine Bestätigung Proprietäre Bestätigung über einfachen ACK NACK Austausch zb über die Einbyter hex 06 und hex 15 HL7-Bestätigung ( unterstützt wird lediglich die Empfangsbestätigung ) Sowie den verwendeten Umschlag der Nachrichten Eine Botschaft pro Datei Mehrere Botschaften pro Datei Diverse Umschlagsarten bei der Socketkommunikation Interprozesskommunikation Verwendung des Business Services TCP oder der Business Operation TCP Folgende Umschläge wurden bisher eingesetzt. Beginn und Ende markiert Jede Botschaft wird in folgendes Lower-Layer-Protokoll (LLP) eingepackt: <SOB><... HL7-Botschaft... ><EOD><EOB> HL7-Botschaften werden normalerweise in folgendes Lower-Layer-Protokoll (LLP) eingepackt: SOB=VT vertical tab hex 0B EOD=FS file seperator hex 1C EOB=CR carriage return hex 0D Anderes häufig verwendetes Lower-Layer-Protokoll (LLP): SOB hex 01 EOD hex 02 EOB hex 0D n-byte-transportheader Jeder Botschaft geht eine n-stellige Zahl voraus, die die Länge der Data- Komponente angibt. Die Längenangabe wird mit führenden Nullen aufgefüllt <n-bytes><...data...> Druck 12.10.09 Seite 8 von 45

Datei-Austausch per FTP Verwendung des Business Services FTP oder der Business Operation FTP Ein FTP-Server wird nicht mitgeliefert. Datei-Austausch per NFS Verwendung des Business File Services oder der Business File Operation. Die Business Services und Operations werden über das Ensemble Management Portal konfiguriert. Neben den Verzeichnis- bzw. Datei-Namen werden folgende Einstellungen vorgenommen: Sonstige Konfigurationsmöglichkeiten Die sonstigen Konfigurations-Möglichkeiten sind von der Kombination des Business Services oder Business Operations und des Schnittstellen-Typs abhängig. ARBEITS_VERZEICHNIS: lokales Arbeitsverzeichnis der Transportagenten. Hier werden temporäre Dateien abgelegt. BOTSCHAFT_VERZEICHNIS: Transferverzeichnis für die auszutauschenden Botschafts-Dateien für Import und Export. BOTSCHAFT_DATEI: Name der Botschafts-Datei (z.b. patdata.dat) BOTSCHAFT_DATEI_PREFIX: Name des Prefixes der Botschaftsdatei ( bei fortlaufend numerierten Dateien z.b. ADTnnnnn.hl7 lautet der Prefix ADT) BOTSCHAFT_DATEI_EXTENSION: Name der Extension der Botschaftsdatei ( bei fortlaufend numerierten Dateien z.b. ADTnnnnn.hl7 lautet die Extension hl7) BOTSCHAFT_TRENNER: Trennzeichen zum Trennen der Botschaften, beim Datei-Export. VERBINDUNG_TIMER (in msec). Zeitspanne, die vergeht, bis bei nicht vorhandener Verbindung zum Subsystem erneut versucht wird, eine Verbindung herzustellen (z.b.-30000). TIMEOUT_IN_MSEK. Timeout-Einstellung des ENSEMBLE-Clients zum ENSEMBLE-Server.(z.B. 1000, oder NULL für unendlich beim Datei-Export) ARCHIV_VERZEICHNIS: Lokales Verzeichnis in dem schon verarbeitete Botschaften automatisch abgelegt werden können. ALERTOnERROR: Maßnahmen was bei einem ERROR geschehen soll Druck 12.10.09 Seite 9 von 45

Szenarien und Inhalte Die Kommunikation mit ANDOK live kennt mehrere Szenarien. Diese sind von der jeweiligen Architektur des Krankenhauses (Kommunikationsserver vorhanden, welches OP-System, welches KIS-System,...) und von den Szenarien der kommunizierenden Systeme abhängig. Einige Szenarien sind für eine sinnvolle Kommunikation notwendig und werden in allen Konstellationen wiedergefunden, andere treten seltener auf. Notwendig ist z.b. die Kommunikation von Patientendaten von der Patientenverwaltung des KIS-Systems zu ANDOK. Die Inhalte von Botschaften werden durch die jeweiligen Informationsmodelle der kommunizierenden Systeme vorgegeben. Um eine sinnvolle Kommunikation zu gewährleisten, müssen diese u.u. angepasst werden. Da das Informationsmodell (Datenmodell) von ANDOK live konfigurierbar ist können somit auch unterschiedlichste Anforderungen an eine Kommunikation erfüllt werden. So können z.b. unterschiedliche Anforderungen bezüglich der von ANDOK live gelieferten Leistungsdaten definiert werden. 2.3 Patientenverwaltung an ANDOK live Die Patientenverwaltung generiert patientenrelevante Ereignisse. Dazu zählen u.a. Aufnahme, Verlegung, Änderung und Entlassung eines Patienten. HL7 stellt dazu mehrere ADT (Admission, Discharge, Transfer) Botschaften bereit. Patienten- Verwaltung ENSEMBLE ANDOK live ADT^A01 NimmPatientAuf Ok ACK Abbildung 6: Kommunikation zwischen ANDOK live und KIS bei der Aufnahme eines Patienten Die Abbildung 6 zeigt die Aufnahme eines Patienten mittels einer ADT^A01 Botschaft. Die anderen Ereignisse laufen analog ab. Druck 12.10.09 Seite 10 von 45

2.4 OP-System an ANDOK live Das OP-System beauftragt ANDOK live mit der Durchführung einer Anästhesie und liefert dafür alle Informationen zur OP, z.b. OP-Nummer, OP-Datum und OP- Saal. OP- System ENSEMBLE ANDOK live ORM^O01 LegeOpAn Ok ACK Abbildung 7: Beauftragung einer Anästhesie Die Abbildung 7 zeigt wie mittels einer allgemeinen Anforderungsbotschaft ORM^O01 (Order Entry) die Beauftragung erfolgt. Zusätzlich oder alternativ kann auch die führende ICD- und OPS301 bzw. ICPM- Nummer beim Anlegen einer OP übergeben werden. Hierfür stellt HL7 eine BAR Botschaft (Anlegen eines Patientenkontos) bereit mit einem Diagnose- und einem Maßnahmen-Segment. 2.5 ANDOK live an die Leistungsabrechnung ANDOK live liefert Leistungen zu den erfassten Anästhesien. Es kommen mehrere mögliche HL7-Botschaften in Frage. Dazu zählen die BAR^P01 (Finance) und die DFT^P03 Botschaft (Finance). ANDOK live ENSEMBLE Leistungs Rechnung ExportiereLeistungen BAR^P01 ACK Ok Abbildung 8: Export von Leistungen Druck 12.10.09 Seite 11 von 45

3 Allgemeine HL7 Richtlinien 3.1 Allgemein Mit HL7 ist in dieser Beschreibung die HL7-Version 2.2, 2.3. oder 2.4 gemeint. In dieser Beschreibung werden nur die Ereignisse (Nachrichten) aufgeführt, die für ANDOK live relevant sind. Dasselbe gilt für die Segmente und Felder der Nachrichten, d.h. optionale Segmente oder Felder, die ANDOK live nicht sendet (oder verarbeitet), werden in der Beschreibung nicht aufgeführt. 3.2 HL7-Nachrichten Nachrichten Eine Nachricht ist die kleinste zwischen Anwendungen übertragbare Dateneinheit. Sie besteht aus einer Gruppe von Segmenten in einer festgelegten Reihenfolge. Jede Nachricht hat einen Nachrichtentyp, der ihren Zweck kennzeichnet. Der ADT- Nachrichtentyp wird bspw. benutzt, um ADT-Daten (Aufnahme, Verlegung, Entlassung/Admission, Discharge, Transfer) von einer Anwendung zu einer anderen zu übertragen. Das tatsächlich stattfindende Ereignis der realen Welt, das einen Nachrichtenaustausch auslöst, wird trigger-event genannt. Die (modifizierte) Tabelle 0003 des HL7-Standards enthält die Codes aller definierten trigger-events. Die Codes der trigger events stehen für Werte wie Ein Patient wurde aufgenommen oder Eine Leistung wurde angefordert. Z-Ereignisse : Alle Nachrichtentypen und trigger-event-codes, die mit einem Z beginnen, sind nicht Bestandteil des HL7-Standards sondern auf lokaler Ebene (durch die Deutsche HL7-Benutzergruppe oder proprietär durch das jeweilige Krankenhaus) definiert. Segmente Ein Segment ist eine logische Aneinanderreihung von Datenfeldern. Segmente einer Nachricht können notwendig oder optional sein. Es gibt Segmente, die nur einmal in einer Nachricht vorkommen dürfen, und solche die wiederholt werden können. Jedes Segment hat einen Namen. Eine ADT-Nachricht kann bspw. aus den folgenden Segmenten bestehen: Nachrichtenkopf (MSH), Ereignistyp (EVN), Patientenidentifikation (PID) und Fallidentifikation (PV1). Jedes Segment wird durch einen aus drei Zeichen bestehenden Schlüssel identifiziert, der als Segment ID bezeichnet wird. Z-Segmente : Alle Segment ID Schlüssel, die mit einem Z beginnen, sind nicht Bestandteil des HL7-Standards sondern auf lokaler Ebene (durch die Deutsche HL7-Benutzergruppe oder proprietär durch das jeweilige Krankenhaus) definiert. Felder Ein Feld ist eine Aneinanderreihung von Zeichen. Für HL7 ist es uninteressant, wie Daten in einer Anwendung tatsächlich gespeichert werden. Felder werden in Form von Zeichenketten übertragen. Wo nicht anders angegeben, können HL7-Felder einen Null-Wert annehmen. Das Senden eines Null-Wertes, der in Form zweier Hochkommata ( ) übertragen wird, ist nicht mit dem Auslassen eines optionalen Feldes zu verwechseln. Der Unterschied wird deutlich, wenn eine Nachricht dazu benutzt wird, einen Satz in einer Datenbank zu ändern, anstatt einen Satz hinzuzufügen. Wird kein Inhalt übertragen (d.h. der Wert wird ausgelassen), sollte der bestehende Inhalt nicht Druck 12.10.09 Seite 12 von 45

geändert werden. Wenn der Null-Wert übertragen wird, sollte der bestehende Wert gelöscht werden. Begrenzerzeichen (Separatoren) Für den Aufbau einer Nachricht werden bestimmte spezielle Zeichen benutzt. Dabei handelt es sich um - den Segmentbegrenzer: immer ein Wagenrücklauf (Carriage return, in ASCII, Hexcode 0D). - das Feldtrennzeichen (normalerweise ) - das Komponententrennzeichen ( ^ ), - Subkomponententrennzeichen ( & ), - Wiederholungstrennzeichen ( ~ ) - das Fluchtzeichen ( \ ). Der Segmentbegrenzer ist fest (CR), die restlichen Begrenzer werden im MSH- Segment (Feld 2) definiert. HL7 Datentypen Im HL7 Standard sind für Datenfelder folgende Datentypen definiert: Typ Inhalt ST Stringdaten Zeichenkette mit optional abschließendem Leerzeichen sind erlaubt. Beispiel: Leerzeichen am Ende sind erlaubt TX Textdaten Führende Leerzeichen sollten eingefügt werden, abschließende Leerzeichen sollten entfernt werden. Beispiel: führende Leerzeichen sind erlaubt FT Formatierte Textdaten die Unterschiede zu Textdaten sind, daß Feld ist von willkürlicher Länge und enthält formatierende Elemente, die von Escapesequenzen eingeschlossen sind. Beispiel: \.sp\(hier kommt der Text) NM Numerische Daten sind eine Ziffernfolge, die optional ein Vorzeichen (+ oder -), einen oder keinem Dezimalpunkt haben können. Beispiel: 12345-6789.987 Führende Nullen oder Nullen nach einem Dezimalpunkt sind nicht signifikant. Die Werte 03.50 und 3.5 sind identisch DT Datum Immer im Format JJJJMMTT Beispiel: 19531216 TM Uhrzeit Immer im Format HHMM[SS][+/-ZZZZ] und in 24-Stunden- Notation. Die Sekundenangabe ist optional. Wenn nicht vorhanden, wird sie als 00 interpretiert. Die Zeitzone [+/-ZZZZ] ist optional, wenn diese nicht angegeben ist, wird die lokale Zeit des Senders verwendet. Mitternacht wird als 0000 dargestellt. Beispiel: 235959+1130 Eine Sekunde vor Mitternacht in einer Zeitzone elfeinhalb Stunden weiter als Greenwichzeit (im Osten). 0800 acht Uhr am Morgen lokale Zeit. TS Zeitstempel Immer im Format JJJJMMTTHHMM[SS][+/-ZZZZ]. Die Sekundenangabe ist optional. Wenn nicht vorhanden, wird sie als 00 interpretiert. Druck 12.10.09 Seite 13 von 45

Typ Inhalt Die Zeitzone [+/-ZZZZ] ist optional, wenn diese nicht angegeben ist, wird die lokale Zeit des Senders verwendet. Mitternacht wird als 0000 dargestellt, kombiniert mit dem Datum des gerade beginnenden Tages. Für Geburtstage wird der Zeitanteil nicht benötigt. Beispiele: 19980213155345-0600 = 15:53:45 am 13.02.1998 in einer Zeitzone sechs Stunden vor Greenwichzeit (im Westen). 199802130000 = Mitternacht in der Nacht vom 12.02. auf den 13.02.1998 in der lokalen Zeitzone. PN Personennamen Spezifiziert als mehrere freie Textkomponenten: Name, Vorname, sonstige Namen, Suffix (JR), Präfix (Dr.) und Titel (Dr. med.). Die maximale Länge eines PN Feldes ist 48 Zeichen einschließlich Komponententrenner. <Nachname>^<Vorname>^<Namenszusatz>^^<Namenspräfix>^<T itel> Beispiel: Müller^Fridolin^ ^Jr.^Chefarzt^Prof. Dr. TN Telefonnummer Für die Vereinigten Staaten und entsprechende Länder hat die Telefonnummer immer folgende Form: [NN][(999)]999-9999[X99999][B99999][C beliebiger Text] Die optionalen ersten beiden Ziffern geben den Ländercode an. Der optionalen X -Teil ermöglicht eine Erweiterung. Der optionale B -Teil enthält den Beeper-Code. Der optionale C -Teil kann für Kommentare wie nach 13:00 Uhr verwendet werden. AD Adresse Beschreibt die Adressfelder, wobei die einzelnen Komponenten durch Komponententrenner getrennt werden. Beispiel: Straße^Postfach^Ort^Bundesland^Postleitzahl^Land^Typ^anderer geographischen Ort ID Kodierter Wert In Form eines ST Feldes. SI Folgenummer In Form eines NM Feldes. CM Zusammengesetzte Felder: Beispiele für speziell definierte zusammengesetzte Felder: CK Zusammengesetztes ID mit Prüfziffer: 123456^8^C34 CN Zusammengesetzte ID mit Namen: ID^Familienname^Vorname^sonstige Namen^Suffix^Präfix^Titel^Quellentabelle. CQ Zusammengesetzte Menge mit Einheit: 112.3^ML CE Kodiertes Element: 54.21^Hypotension^I9C^42112^^AS4 Bitte beachten Sie auch die HL7-Beispielnachrichten im Abschnitt 5Fehler! Verweisquelle konnte nicht gefunden werden.. Zeichensatz Druck 12.10.09 Seite 14 von 45

Zeichensatz Im HL7 Standard bestehen Zeichenketten ausschließlich aus Zeichen, die im 7-bit ASCII Zeichensatz darstellbar sind. Dadurch wird beliebigen Sender- /Empfängersystemen die Möglichkeit gegeben, alle möglichen Zeichenketten verarbeiten zu können. Gleichzeitig stellt sich damit das Problem der Darstellung von Zeichen aus nationalen Zeichensätzen (ä,ö,ü,...). Die ISO 8859-1 Norm stellt eine ausreichende Ergänzung des 7-bit ASCII Zeichensatzes dar. Alle druckbaren Zeichen des ASCII-Zeichensatzes im Bereich von 20 bis 7F (hexadezimal) werden als ASCII-Zeichen übertragen. Alle weiteren Zeichen werden (HL7-gemäß) als Escape-Sequenz in der Form \Xyyyy\ übertragen, wobei yyyy für den ISO 8859-1 Code (hexadezimal) des zu übertragenden Zeichens steht. Beispiel: Ä=\X00C4\. Folgende Tabelle gilt als Übertragungsstandard für nationale Sonderzeichen: A_ B_ C_ D_ E_ F 0 À Ð à ð _1 ± Á Ñ á ñ _2 ² Â Ò â ò _3 ³ Ã Ó ã ó _4 Ä Ô ä ô _5 µ Å Õ å õ _6 Æ Ö æ ö _7 Ç ç _8 È Ø è ø _9 ¹ É Ù é ù _A ª º Ê Ú ê ú _B Ë Û ë û _C ¼ Ì Ü ì ü _D - ½ Í Ý í ý _E ¾ Î Þ î þ _F Ï ß ï ÿ Tabelle 3-1. ISO 8859-1 Zeichensatz 3.3 Botschaftenbestätigung Derzeit wird das erweiterte Bestätigungsverfahren (enhanced Acknowledgement rules) unterstützt. HL7 unterscheidet dabei zwischen einer Empfangsbestätigung (accept acknowledge) und einer Verarbeitungsbestätigung (application acknowledge). Derzeit ist eine einfache Empfangsbestätigung vorgesehen. Das Fremdsystem kann die Anforderungen an die Empfangsbestätigung in dem entsprechenden Feld (MSH-15) des MSH-Segments angeben. Eine vollständige Verarbeitungsbestätigung ist derzeit nicht vorgesehen. Empfangsbestätigung Empfangsbestätigungsmeldungen zeigen die erfolgreiche Entgegennahme und Speicherung von Botschaften zur späteren Verarbeitung an. Empfangsbestätigungen werden zwischen direkt miteinander kommunizierenden Systemen (z.b. DG_ANDOK_IMPORT und Fremdsystem) ausgetauscht. Druck 12.10.09 Seite 15 von 45

CA - Commit accept Der Empfang einer Bestätigungsbotschaft mit dem Bestätigungscode CA bedeutet den Erhalt, die erfolgreiche Erkennung und die erfolgreiche Speicherung der Botschaft. CE - Commit error Der Empfang einer Bestätigungsbotschaft mit dem Bestätigungscode CE bedeutet, dass die Botschaft vom kommunizierenden System nicht erfolgreich angenommen werden konnte. Der Grund dafür ist im Feld MSA-6 (ggf. als Freitext in MSA-3) spezifiziert. CR - Commit reject Anwendungen dürfen auf empfangene Botschaften mit dem Bestätigungscode CR gemäß den Vorgaben des HL7-Standards bzgl. der erweiterten Bestätigungsregeln reagieren. Der Grund für die Ablehnung ist in Feld MSA-3 zu erläutern. Die Ablehnung einer Botschaft mit CR stellt keinen Fehler im engeren Sinne dar und wird im Regelfall allenfalls zu einer Protokollierung der abgelehnten Botschaft führen. Sinnvoll einsetzbar normalerweise nur im Rahmen einer Verarbeitungsbestätigung. Druck 12.10.09 Seite 16 von 45

4 HL7 Nachrichten 4.1 Übersicht Nachrichtentypen Die von ANDOK benützten Ereignisse werden folgenden Bereichen zugeordnet: - ADT = Admission, Discharge, Transfer (Aufnahme, Entlassung, Verlegung) - DFT = Detailed Financial Transaction (Finanzwesen) - BAR = Add, Change Billing Account (Abrechnung) - ORM = Observation Request (Auftragswesen) - ORU = Unsolicited Observation Reporting (Befundübertragung ohne Auftrag) - MDM = Document managment section ( Dokumentübertragungs Botschaften) Ereignisse Als empfangendes und sendendes System unterstützen TO_ANDOK und FROM_ANDOK die in der Tabelle aufgeführten Ereignisse: Ereignis Beschreibungen ANDOK live ANDOK live ADT^A01 Patientenaufnahme X ADT^A02 Patientenverlegung X ADT^A03 Patientenentlassung X ADT^A04 Ambulanter Besuch X ADT^A05 Voraufnahme eines Patienten X ADT^A06 Änderung von ambulant in stationär X ADT^A07 Änderung von stationär in ambulant X ADT^A08 Patientenänderung X ADT^A11 Stornieren einer Aufnahme X ADT^A12 Stornieren einer Verlegung X ADT^A13 Stornieren einer Entlassung X ADT^A29 Patient Löschen X ADT^A34 Zusammenführung von X Patientendaten BAR^P01 Anlegen eines Patientenkontos X (Diagnosen und Maßnahmen zu einer OP werden übernommen) BAR^P02 1 Löschen eines Patientenkontos X BAR^P05 2 Update eines Patientenkontos X ORU^R01 Automatische Befundübertragung X ORM^O01 Auftrag (OP-Beauftragung) X DFT^P03 Leistungen X BAR^P01 3 Zeiten X BAR^P01 4 Personal X DFT^P03 Material X 1 Bei Verwendung von HL7-Version 2.3 2 Bei Verwendung von HL7-Version 2.3 3 Wenn HL7 Version 2.3 zum Einsatz kommt, wird BAR^P05 oder DFT^P03 verwendet 4 Wenn HL7 Version 2.3 zum Einsatz kommt, wird BAR^P05 oder DFT^P03 verwendet Druck 12.10.09 Seite 17 von 45

Ereignis Beschreibungen ANDOK live ANDOK live BAR^P01 5 Diagnosen und Maßnahmen X ORU^R01 Automatische Befundübertragung X MDM^T02 Dokumentübertragung X ANDOK live : Ereignisse, die vom Fremdsystem an ANDOK geschickt werden können (und die von ANDOK verarbeitet werden). ANDOK live : Ereignisse, die ANDOK versenden kann. In der Spalte Ereignis steht der Nachrichtentyp (ADT, BAR, DFT, ORM) und der Ereigniscode (A01, P03,...). 5 Wenn HL7 2.3 zum Einsatz kommt, wird diese Botschaft als BAR^P05 übertragen Druck 12.10.09 Seite 18 von 45

Darstellung der Ereignisse Im HL7 Handbuch finden Sie folgende Notation für den Aufbau der Ereignisse (am Beispiel des ADT^A01): Segmente Bedeutung MSH Nachrichtenkopf EVN Ereignistyp PID Patienten-ID Information [ { NK1 } ] Nächster Angehöriger PV1 Patientenvisite [PV2] Patientenvisite zusätzliche Informationen [{OBX}] Beobachtung / Ergebnis [{AL1}] Allergie-Information [{DG1}] Diagnosen [{PR1}] Maßnahmen [{GT1}] Bürge [ { IN1 Versicherung [IN2] Versicherung zusätzliche Information [IN3] Versicherung zusätzliche Information Bescheinigung } ] [ACC] Unfallinformationen [UB1] Universelle Rechnungsinformationen [UB2] Universelle Rechnungsinformationen Erläuterungen: [... ] = optionales Segment {... } = Segment kann wiederholt werden [ {... } ] = optionales Segment kann wiederholt werden Für ANDOK gilt: Empfang von Nachrichten: ANDOK live kann alle Segmente empfangen, verarbeitet aber nur bestimmte (benötigte) Segmente. - Versand von Nachrichten: ANDOK live versendete nur die Segmente, die es befüllen kann. Daher werden in der Darstellung nur die von ANDOK live benützten Segmente angezeigt und erläutert. Beim ADT^A01 für ANDOK live sieht das so aus: Segmente Bedeutung MSH Nachrichtenkopf EVN Ereignistyp PID Patienten-ID Information PV1 Patientenvisite [ { IN1 } ] Versicherung Druck 12.10.09 Seite 19 von 45

Die Segmente Anbei eine Übersicht der (für ANDOK) möglichen Segmente: Segment Bedeutung DG1 Diagnosen EVN Ereignistyp FT1 Leistungen / Kosten IN1 Versicherung MRG Zusammenführung MSA Nachricht für Bestätigung MSH Nachrichtenkopf OBR Beobachtung / Befund OBX Beobachtung / Ergebnis ORC Auftrag / Anfrage PID Patienten-ID Information PR1 Maßnahmen PV1 Patientenvisite Die Ereignisse und ihre Segmente Um die Darstellung übersichtlicher zu machen, enthalten die folgenden Tabellen alle Segmente für alle ANDOK-relevanten Ereignisse: Erläuterungen: [... ] = optionales Segment {... } = Segment kann wiederholt werden Segmente Ereignis Beschreibung MSH EVN PID PV1 IN1 DG1 MRG ADT^A01 Patientenaufnahme [ ] {[ ] } ADT^A02 Patientenverlegung ADT^A03 Patientenentlassung ADT^A04 Ambulanter Besuch [ ] {[ ] } ADT^A05 Voraufnahme [ ] {[ ] } ADT^A06 ambulant stationär ADT^A07 stationär ambulant ADT^A08 Patientenänderung [ ] {[ ] } ADT^A11 Storno Aufnahme ADT^A12 Storno Verlegung ADT^A13 Storno Entlassung ADT^A29 Patient Löschen ADT^A34 Zusammenführung von Patientendaten Kommentare: 1. Bei einer Entlassung (ADT^A03) werden die Falldaten nicht gelöscht, sondern nur das Entlassungsdatum gesetzt. 2. Ein ambulanter Besuch (ADT^A04) wird wie eine Aufnahme (ADT^A01) behandelt. Druck 12.10.09 Seite 20 von 45

3. Bisher kann nur ein IN1 Segment verarbeitet werden (laut HL7 Standard kann das IN1 Segment mehrfach vorkommen). Ereignis Beschreibung MSH EVN PID PV1 FT1 DG1 PR1 [ ] [{ } [{ }] ] BAR^P01 Anlegen eines Patientenkontos mit Diagnosen und Maßnahmen. (Ausnahmevariante zur Übertragung von Leistungen mit Zeiten und Personal) BAR^P02 Löschen eines Patientenkontos [ ] BAR^P05 Aktualisieren eines Patientenkontos mit Diagnosen und Maßnahmen. (Ausnahmevariante zur Übertragung von Leistungen mit Zeiten und Personal) [ ] [{ } ] [{ }] DFT^P03 Leistungen [ ] { } DFT^P03 ϑ [ ] { } [{ }] Übertragung von Leistungen, Zeiten und Personal Kommentare: 4. DFT^P03 ist der Standard für den Leistungsexport. Abrechnungsrelevante Daten werden im HL7-Protokoll mit dem DFT^P03 übertragen. Die BAR^P01 ist die Ausnahmevariante für den Leistungsexport. 5. Wenn eine Zeitdauer übermittelt wird, verwendet man BAR^P01, da diese Botschaft ein PR1 Segment enthält, in welchem Zeitdauern übermittelt werden. Ab Version HL7 2.3 enthält auch die DFT^P03 ein PR1-Segment, so daß die DFT^P03 als einzige Leistungsbotschaft ausreicht (siehe auch Fußnote ϑ ). 6. Für den Export von Diagnosen und Maßnahmen kann an Version HL7 2.3 die Botschaft BAR^P05 verwendet werden. 7. Wenn ANDOK live eine OP-Nummer erhält, kann die OP-Nummer im Feld PV1-50 übertragen werden. Ereignis Beschreibung MSH PID PV1 ORC OBR DG1 OBX ORM^O0 Allgemeine Anforderung / OP- [{ } [{ } Beauftragung 1 ] ] ORU^R01 Automatische Befundübertragung { { } } Kommentare: 8. Bei der Beauftragung einer OP kann ab Verion HL7 2.3 die OP-Diagnose und die Maßnahme ( im OBX-Segment) übergeben werden. Segmente Ereignis Beschreibung MSH MSA ERR ACK Bestätigung ϑ Ab HL7 Version 2.3 ist in einer DFT^P03 Botschaft neben dem FT1-Segment auch das PR1-Segment enthalten, so dass Zeiten und Leistungen in einer Botschaft übertragen werden können. Druck 12.10.09 Seite 21 von 45

4.2 Die Segmente und ihre Felder Allgemein Die Felder der Segmente für ADT-Botschaften werden unten aufgeführt. Kursive Einträge bedeuten vorgesehene, aber zur Zeit noch nicht unterstützte Felder. Fett gedruckte Felder bedeuten eine Abweichung vom HL7-Standard. Nicht aufgeführte Felder werden nicht benutzt! Segmentbeschreibungen In den Tabellen zur Segmentbeschreibung werden folgende Abkürzungen und Begriffe benutzt: Spalte SEQ LEN DT R/O ANDOK RP# TBL Deutsche Bezeichnung In ANDOK live [ Defaults ] Inhalt Laufende Nummer des Feldes im Segment Länge vorgeschlagene Feldlänge (nicht zwingend) Datentyp des Feldes (nach HL7-Konvention). Übersicht siehe Anhang. Handelt es sich um ein Pflichtfeld oder ein optionales Feld: R = Required = Feld muß vorhanden (=gefüllt) sein O = Optional = Feld muß nicht kann vorhanden sein C = Conditional = Vorhandensein abhängig vom Ereignis N = Nicht benutzt Analog R/O-Spalte, aber für ANDOK erweitert: R / Required = Feld muß vorhanden (=gefüllt) sein O / Optional = Feld muß nicht kann vorhanden sein N = Feld wird von ANDOK nicht benutzt. Für ANDOK kann diese Spalte von der HL7 Festlegung in R/O abweichen. Zeigt an, ob das Feld wiederholbar ist: N = keine Wiederholung Y = das Feld kann sich unbestimmt häufig wiederholen Anzahl n = Das Feld kann sich bis zu n-mal wiederholen Nummer der Verschlüsselungstabelle, die für dieses Feld angewandt werden muß. Nach jeder Segmentbeschreibung werden die dafür relevanten Tabellen aufgeführt (siehe 0) Alle Tabellen, die in der Segmentbeschreibung erwähnt aber nicht aufgeführt werden, sind entweder anwenderdefiniert ( user defined values ), d.h. es gibt keinen Vorschlag vom HL7 Standard oder sie spielen keine Rolle, weil des Feld nicht verwandt wird. Bezeichnung des Feldes laut der Übersetzung der deutschen HL7-Gruppe (HL7 Version 2.2, 2.3, 2.4). Präzisierung der Spalte Deutsche Bezeichnung für ANDOK live : - die Bezeichnung/Bedeutung des Feldes in ANDOK live - Standardmäßige Vorbelegung des Feldes (Default) in [..]. Druck 12.10.09 Seite 22 von 45