EIN HL7 INTERFACE FÜR DAS IOP DBASE PROGRAMM ============================================ Die für ein Datum jeweils passenden Stellen in HL7 sind mit einem ``Pfad'' angegeben. Dieser hat die Form segment[.feld[.komponente]]. Während das Segment durch seinen dreistelligen Bezeichner angegeben wird, werden die Feld und Komponenten durch die Form: bezeichener(nummer) gegeben. Dabei ist der ``bezeichner'' eine Kontraktion aus der standardisierten Feldbeschreibung, welche folgendermaßen gebildet wird: 1. Jedes Wort beginnt mit einem Großbuchstaben, der Rest ist Kleinbuchstaben. 2. Alle Worte über fünf Buchstaben werden auf die ersten drei Buchstaben reduziert. 3. Leerstellen, sowie Hyphen und Klammern und andere Sonderzeichen werden getilgt. Auf diese Weise entstehen kurze Bezeichner, die immer noch einigermaßen aussagekräftig sind. Sie sind in den meisten Fällen in ihrem jeweiligen Geltungsbereich eindeutig (wo sie es nicht sind, greifen hier nicht näher ausgeführte Sonderregeln). Sie verweisen schließlich direkt (d.h. ohne Übersetzungstabelle) auf den Text des HL7 Standards. FELDNAME TYP HL7 PFAD CODE ANM ----------------------------------------------------------------------------- BETT Numerisch PV1.AssPatLoc(3).NurseUnit(1) IZAHL Zeichen PID.PatIdIntId(3).IdNum(1) AUFNR Zeichen PV1.VisitNum(19) AUFNR_EH Zeichen PV1.PreAdmitNum(5) NAME Zeichen PID.PatName(5).FamName(1) 2 GEBNAME Zeichen PID.MotMaiName(6) 1 VNAME Zeichen PID.PatName(5).GivenName(2) 2 UNBEK_NR Numerisch PID.PatName(5).FamName(1) 2,3 FAMSTAND Zeichen PID.MarSta(16) 0002 GEBDAT Datum PID.DateOfBirth(7) SEX Zeichen PID.Sex(8) 0001 ADRESSE_1 Zeichen PID.PatAdd(11) 4 ADRESSE_2 Zeichen ... TEL Zeichen PID.PhoneNumHome(13) 5 GROESSE Numerisch (OBX) 6 GEWICHT Numerisch (OBX) 6 KOF Numerisch (OBX) 6 NOTADR_1 Zeichen NK1.NextOfKinName(2) 7 NOTADR_2 Zeichen ... NOTADR_3 Zeichen ... NOTTEL Zeichen NK1.NextOfKinPhoneNum(5) HAUSARZT_1 Zeichen ??? 8 HAUSARZT_2 Zeichen ... HAUSARZT_3 Zeichen ... HA_TEL Zeichen ... APACHE Numerisch (DG1) 9 AUFDAT Datum PV1.AdmitDateTime(44) AUFZEIT Zeichen ... AUF_AUS Zeichen PV1.AdmitSource(14) 10 AUF_EXTERN Zeichen PV1.RefDoc(8) 10 ART_EXTERN Zeichen PV1.AdmitSource(14) 11 AUF_ART Zeichen PV1.AdmType(4) 0007 ABTLG_1 Zeichen PV1.ConDoc(9) 12 ABTLG_2 Zeichen ... ABTLG_3 Zeichen ... ABTLG_4 Zeichen ... AUFNEHMER Zeichen PV1.AdmDoc(17) ENTDAT Datum PV1.DisDateTime(45) ENTZEIT Zeichen ... ENT_NACH Zeichen PV1.DisToLoc(37) 10 ENT_EXTERN Zeichen ... ENT_ART Zeichen PV1.DisDis(36) ENTLASSER Zeichen EVN.OpeId(5) 13 BEATM_TAGE Numerisch (PR1) 14 TODESDATUM Datum (DG1.DiaDateTime(5)) 15 TODESZEIT Zeichen ... IOP_CHECK Zeichen (EV1.OpeId(5)) 13 Weiter: 1. Allergie (Freitext) AL1.AllCodeMneDes(3).Text(2) 2. Allergie ... ... (weitere AL1 Segmente) 3. Allergie ... ... ... ... ... ... ... ACHTUNG: Bei Verlegungen (ADT^A02) wird immer der neue (künftige) Aufenthaltsort des Patienten in PV1.AssPatLoc(3) eingetragen. Der bisherige (alte) Aufenthaltsort steht dagegen in PV1.PriorPatLoc(6). ANMERKUNGEN ----------- (1) Der offizielle Feldbezeichener heißt ``mother's maiden name'', ist also der Geburtsanme der Mutter. Sollte diese Information nicht gebraucht werden -- wird sie nicht gelegentlich erhoben? -- dann kann man mit der deutschen Übersetzung gehend die Bedeutung des Feldes zum einfachen Geburtsnahmen abändern. (2) Akademische Grade und Adelstitel sollten wenn möglich in die dafür reservierten Felder des PN-Typs geschrieben werden und nicht den Nachnamen begleiten oder gar durch Komma getrennt hinter dem Vornamen stehen. (3) Da die Unbekannten-Nummer als Ersatz für den Namen dient und nicht für die I-Zahl (?), sollte sie auch im Namen geführt werden. Wenn der richtige Name ermittelt wurde, könnte sie der Vollständigkeit wegen im PID.PatAlias(9)-Feld weiter geführt werden. (4) Die Felder des AD Typs sollten richtig genutzt werden. (5) Solange keine Unterscheidung zwischen ``dientlich'' und ``privat'' bei der Telephonnummer gemacht wird, sollte wohl immer ``privat'' (= ``Home'') benutzt werden (6) Diese klinischen Messgrößen sind im ADT Konzept von HL7 nicht enthalten. Muß man wohl per ORU message schicken, bzw. vorerst direkt per IDB nach CareVue. Später kann man mit v2.2 OBX Segmente in der ADT Nachricht mitführen, in die man solche Werte schreiben kann. (7) Das NK1 Segment bietet Platz für einen vollständigen Namen (PN), eine vollständige Adresse (AD), mehrere Telephonnummern (repeated TN) und den Verwandtschafts-/Beziehungs-Code. Es gilt, die drei ``NOTADR'' Felder richtig zu verteilen. Verschiedene Bezugspersonen sollen in verschiedene NK1 Segmente. (8) Den Hausarzt in HL7 unterzubringen ist ein Problem. Im PV1 Segment, wo er hingehören würde ist zwar Platz für allen möglichen Schnickschnack, der v.a. Abrechnungsfragen betrifft, aber kein ordentlicher Platz für den Hausarzt. Wärend die deutsche HL7 Gruppe die Plazierung in das wiederholbare Feld 9 ``consulting doctor'' vorsieht, hat die Adresse und Telephonnummer des Hausarztes immer noch keinen Platz. Somit müßte eine eigene Hausarzt-Datenbank her, in welche die ID Komponente des CN Typs verweist. Ein Problem bleibt immer noch zu markieren ob ein ``consulting doctor'' nun ein Hausarzt ist, oder ein stationär mitbehandelnder Arzt (bzw. Klinik). Ich sehe folgende Lösungsmöglichkeiten: 1. Einfügen eines Funktionsbezeichners im CN-Feld, eventuell als Sub-Komponente der ID-Komponente. 2. Verzicht auf die Unterbringung des Hausarztes im PV1 Segment. Stattdessen wird diese Information im NK1 Segment transportiert, wobei als Beziehungs/Verwandtschafts-Code ein ``HAUSARZT'' oder ``HA'' eingeführt wird. Ich halte die zweite Lösung für die sauberere. (9) Der APACHE Score ist ebenso ein Klinischer Befund (s. Anmerkung 6). Vielleicht könnte man ihn aber auch als eine Art von Diagnose behandeln, und damit im DG1 Feld unterbringen. Dort hat man einen großen Gestaltungsfreiraum. (10) Ein einweisendes Krankenhaus bzw. die Aufnahmeart muß hier in codierter Form eingetragen werden. In anderen Abteilungen als der IOP mag die Einweisende Quelle ein Hausarzt sein, der dann als ``refering doctor'' in Feld 8 untergebracht werden könnte. Das macht das in Anmerkung 8 genannte Hausarzt-Problem aber noch komplizierter. (11) Die Informationen ``Verlegung'' oder ``Weiterleitung'' aus ``Berlin'' oder ``Umland'' können ebenfalls per ``admit source'' übermittelt werden. Man sollte darüber nachdenken, den ``admission type'' Code zu erweitern, um zwischen ``Verlegung'' und ``Weiterleitung'' zu unterscheiden. (12) Es ist zumindest problematisch, ob man ein Feld, welches für Personennamen gedacht ist, dazu umfunktionieren sollte, Institutionen aufzunehmen. Es scheint mir aber kein Weg daran vorbei zu führen, da man die verschiedenen mitbehandelnden Ärzte wohl allenfalls bei Privatpatienten persönlich benennen kann. Gegebenefalls kann und sollte man alle vier Abteilungen in dem wiederholbaren Feld unterbringen. (13) Während es ein Feld für den aufnehmenden Arzt gibt, gibt es keines für den entlassenden. Man sollte wohl nicht das gleiche Feld nehmen, welches aber dann? Es ist doch so, daß, wenn jede gesendete Nachricht durch ein Ereignis ausgelöst wird, doch eben dieses seinerseits eine verantwortlich zeichnende Person zum Urheber haben muß. Damit ist diese Information so grundlegend, daß sie schon in den Nachrichtenkopf gehört (MSH.Sec(6) oder MSH.SenApp(1)/MSH.SenFac(2)). Im ADT-Bereich kann man auch die ``opeator id'' nehmen, die in v2.2 als 5. Feld im EVN-Segment genau zu diesem Zweck vorgesehen ist. (14) Ungenau erhobene Größe für die im HL7 ADT Bereich wohl kein Platz zu finden ist. Soll man einen einrichten? Allgemein kann die Statistik über Maßnahmen in das PR1 Segment, welches ursprünglich zur Finanz-Abteilung gehört. Seit v2.2 ist aber das PR1 Segment auch in der ADT Nachricht zu finden. (15) Wie wird der Tod eines Patienten erfaßt? Als Diagnose im DG1 Segment?