deutsche Nachrichtenprofile: Rahmen-Dokument

Aus Hl7wiki
Nachrichtenprofile
Wechseln zu: Navigation, Suche
 
(5 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 7: Zeile 7:
 
{{Infobox Dokument
 
{{Infobox Dokument
 
|Title    HL7 v2.5 Nachrichtenprofile, Ausgabe 2013: Rahmen-Dokument
 
|Title    HL7 v2.5 Nachrichtenprofile, Ausgabe 2013: Rahmen-Dokument
−
|Short    = deutsche Nachrichtenprofile
+
|Short    = deutsche Nachrichtenprofile: Rahmen-Dokument
 
|Namespace = v2profile
 
|Namespace = v2profile
 
|Type      = Nachrichtenprofile
 
|Type      = Nachrichtenprofile
Zeile 26: Zeile 26:
 
{{Infobox Contributors Begin}}
 
{{Infobox Contributors Begin}}
 
{{Contributor | Logo = Logo-Agfa.jpg | Name = Agfa HealthCare GmbH | Location = Bonn }}
 
{{Contributor | Logo = Logo-Agfa.jpg | Name = Agfa HealthCare GmbH | Location = Bonn }}
−
{{Contributor | Logo = logo_cortex.gif]] | Name = Cortex Software GmbH | Location = }}
+
{{Contributor | [[Logo = logo_cortex.gif]] | Name = Cortex Software GmbH | Location = }}
 
{{Contributor | Logo = Logo_icw.jpg]] | Name = InterComponentWare| Location =  Walldorf }}
 
{{Contributor | Logo = Logo_icw.jpg]] | Name = InterComponentWare| Location =  Walldorf }}
 
{{Contributor | Logo = logo_sap.jpg]] | Name = SAP| Location =  Walldorf }}
 
{{Contributor | Logo = logo_sap.jpg]] | Name = SAP| Location =  Walldorf }}
Zeile 105: Zeile 105:
  
  
−
=Autoren und Copyright-Hinweis, Nutzungs¬hinweise=
+
=Autoren und Copyright-Hinweis, Nutzungshinweise=
 +
 
 +
{{BeginGreenBox|Nachnutzungs- bzw. Veröffentlichungsansprüche}}
  
−
==Nachnutzungs- bzw. Veröffentlichungsansprüche==
 
 
Das vorliegende Dokument wurde von Agfa HealthCare in Kooperation mit InterComponentWare und optimal systems entwickelt. Die Nachnutzungs- bzw. Veröffentlichungsansprüche sind nicht beschränkt.
 
Das vorliegende Dokument wurde von Agfa HealthCare in Kooperation mit InterComponentWare und optimal systems entwickelt. Die Nachnutzungs- bzw. Veröffentlichungsansprüche sind nicht beschränkt.
  
Zeile 120: Zeile 121:
  
 
Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifkationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
 
Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifkationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
 +
{{EndGreenBox}}
  
  
  
−
 
+
{{BeginGreenBox|Disclaimer}}
−
Disclaimer
 
−
 
 
 
Obwohl diese Publikation mit größter Sorgfalt erstellt wurde, kann weder die HL7-Benutzergruppe in Deutschland e.V. noch die an der Erstellung beteiligten Firmen keinerlei Haftung für direkten oder indirekten Schaden übernehmen, die durch den Inhalt dieser Spezifikation entstehen könnten.
 
Obwohl diese Publikation mit größter Sorgfalt erstellt wurde, kann weder die HL7-Benutzergruppe in Deutschland e.V. noch die an der Erstellung beteiligten Firmen keinerlei Haftung für direkten oder indirekten Schaden übernehmen, die durch den Inhalt dieser Spezifikation entstehen könnten.
−
 
+
{{EndGreenBox}}
  
  
  
 
=Einleitung=
 
=Einleitung=
−
Diese Serie von Dokumenten dokumentiert den HL7-Standard, so wie er in Deutschland angewendet werden soll. Grundlage der Arbeiten ist die HL7-Version 2.5 in der deutschen Fassung. Hierbei sind gegenüber der internationalen Version Anpas¬sungen an die landes¬spezifischen Anforderungen vorgenommen worden. Hierzu zählen neben der Kenn¬zeich¬nung einzelner Teile als "nicht verwendet", insbesondere die Erweiterung von Daten¬tabellen sowie die Definition spezieller Z-Segmente. Mit diesen Doku¬menten sollen die Inhalte aus den Original¬dokumenten nicht wiederholt werden, so dass an dieser Stelle empfohlen sei, die Nachrichten¬profile zusammen mit den Originaldokumenten zu lesen. Es werden alle required-Felder sowie besondere optionale Felder erläutert.
+
Diese Serie von Dokumenten dokumentiert den HL7-Standard, so wie er in Deutschland angewendet werden soll. Grundlage der Arbeiten ist die HL7-Version 2.5 in der deutschen Fassung. Hierbei sind gegenüber der internationalen Version Anpassungen an die landesspezifischen Anforderungen vorgenommen worden. Hierzu zählen neben der Kennzeichnung einzelner Teile als "nicht verwendet", insbesondere die Erweiterung von Datentabellen sowie die Definition spezieller Z-Segmente. Mit diesen Dokumenten sollen die Inhalte aus den Originaldokumenten nicht wiederholt werden, so dass an dieser Stelle empfohlen sei, die Nachrichtenprofile zusammen mit den Originaldokumenten zu lesen. Es werden alle required-Felder sowie besondere optionale Felder erläutert.
  
 
==Scope==
 
==Scope==
−
Diese Nachrichtenprofile dienen zur konformen Entwicklung von Interfaces zu in Deutschland ein¬gesetzten Anwendungen. Dazu bedarf es der Verarbeitung einer Mindestmenge an Informationen, die über diese Profile ebenfalls festgelegt wird.
+
Diese Nachrichtenprofile dienen zur konformen Entwicklung von Interfaces zu in Deutschland eingesetzten Anwendungen. Dazu bedarf es der Verarbeitung einer Mindestmenge an Informationen, die über diese Profile ebenfalls festgelegt wird.
  
 
In diesem Dokument werden die Informationen beschrieben, die nicht-normativer Bestandteil der Profile sind.
 
In diesem Dokument werden die Informationen beschrieben, die nicht-normativer Bestandteil der Profile sind.
Zeile 143: Zeile 143:
  
 
==Konformanzprofile==
 
==Konformanzprofile==
−
Die hier beschriebenen Dokumente stellen eine Einschränkung des offiziellen Standards nach den vorgegebenen Regeln dar, die im Abschnitt 2.12 des Kapitels 2 nach¬gelesen werden können.
+
Die hier beschriebenen Dokumente stellen eine Einschränkung des offiziellen Standards nach den vorgegebenen Regeln dar, die im Abschnitt 2.12 des Kapitels 2 nachgelesen werden können.
  
 
=Kodierrichtlinien=
 
=Kodierrichtlinien=
Zeile 157: Zeile 157:
  
 
==Escape-Sequenzen==
 
==Escape-Sequenzen==
−
Bedingt durch die Serialisierung der Daten über Trennzeichen dürfen letztere nicht in den eigentlichen Informationen vorkommen. Erreicht wird dies durch die Ersetzung mit sog. Escape-Sequenzen. Im Gegensatz zu herkömmlichen Pro¬grammier¬sprachen ist dies keine Ent¬wertung (wie in VB durch '""' für ein einfaches doppeltes Anführungszeichen in einer Zeichen¬kette oder in der printf-Anweisung in C mittels '%'), sondern ein Austausch des Zeichens selber:
+
Bedingt durch die Serialisierung der Daten über Trennzeichen dürfen letztere nicht in den eigentlichen Informationen vorkommen. Erreicht wird dies durch die Ersetzung mit sog. Escape-Sequenzen. Im Gegensatz zu herkömmlichen Programmiersprachen ist dies keine Entwertung (wie in VB durch '""' für ein einfaches doppeltes Anführungszeichen in einer Zeichenkette oder in der printf-Anweisung in C mittels '%'), sondern ein Austausch des Zeichens selber:
  
 
{| class="hl7table"
 
{| class="hl7table"
−
!Ver¬wen¬dung!!Escape-Sequenz!!Beispiel Escape-Symbol:!!‚a’'!!‚;’'
+
!Verwendung!!Escape-Sequenz!!Beispiel Escape-Symbol:!!‚a’'!!‚;’'
 
|-
 
|-
 
|R||\F\||field separator||aFa||;F;
 
|R||\F\||field separator||aFa||;F;
Zeile 186: Zeile 186:
  
 
==Carriage-Return==
 
==Carriage-Return==
−
Gemäß der Kodierrichtlinien sind die Trennzeichen (MSH-1 und MSH-2) variabel, d.h. erst in der eigent¬lichen Nachricht konkret definiert. Dies trifft allerdings für den Segment-Terminator nicht zu. Hier ist CR (Hex 0D) fest vorgegeben.
+
Gemäß der Kodierrichtlinien sind die Trennzeichen (MSH-1 und MSH-2) variabel, d.h. erst in der eigentlichen Nachricht konkret definiert. Dies trifft allerdings für den Segment-Terminator nicht zu. Hier ist CR (Hex 0D) fest vorgegeben.
−
Folglich darf CR an keiner Stelle in einem Datenfeld (Feld, Komponente oder Sub¬komponente) auf¬treten. Für Datenfelder vom Typ 'ST' sind nur druckbare Zeichen zugelassen.
+
Folglich darf CR an keiner Stelle in einem Datenfeld (Feld, Komponente oder Subkomponente) auftreten. Für Datenfelder vom Typ 'ST' sind nur druckbare Zeichen zugelassen.
  
 
==Textformatierung==
 
==Textformatierung==
Zeile 220: Zeile 220:
  
 
==Versionsabhängigkeiten==
 
==Versionsabhängigkeiten==
−
Bedingt durch Inkompatibilitäten zwischen den unterschiedlichen HL7-Versionen ins¬besondere in den allgemein relevanten Feldern wie Patienten-ID und Name des Patienten wird eine Verarbeitung nach der "Version Compatibility Definition" nicht gefordert. Statt dessen wird eine Erfüllung der in den Pro¬filen festgelegten Bedingungen verlangt.
+
Bedingt durch Inkompatibilitäten zwischen den unterschiedlichen HL7-Versionen insbesondere in den allgemein relevanten Feldern wie Patienten-ID und Name des Patienten wird eine Verarbeitung nach der "Version Compatibility Definition" nicht gefordert. Statt dessen wird eine Erfüllung der in den Profilen festgelegten Bedingungen verlangt.
 
Dies ist eine Vereinfachung der allgemeinen Verarbeitungslogik, da normalerweise eine Verarbeitung der Elemente auch für vorhergehende HL7-Definitionen gefordert wird.
 
Dies ist eine Vereinfachung der allgemeinen Verarbeitungslogik, da normalerweise eine Verarbeitung der Elemente auch für vorhergehende HL7-Definitionen gefordert wird.
  
 
==Null-Werte vs. nicht vorhanden==
 
==Null-Werte vs. nicht vorhanden==
−
Die in einer Umgebung eingesetzten Systeme unterscheiden sich grundsätzlich in Art und Umfang der gespeicherten Daten. Es wird problematisch, wenn es keine Regeln zur Hand¬habung von Feldern und deren Komponenten unter Berücksichtigung von Null-Werten  dargestellt durch zwei doppelte Anfüh¬rungs¬zeichen ("")  gibt. Dann können Informationen verloren gehen bzw. die geforderten Änderun¬gen werden nicht durch¬geführt.
+
Die in einer Umgebung eingesetzten Systeme unterscheiden sich grundsätzlich in Art und Umfang der gespeicherten Daten. Es wird problematisch, wenn es keine Regeln zur Handhabung von Feldern und deren Komponenten unter Berücksichtigung von Null-Werten  dargestellt durch zwei doppelte Anführungszeichen ("")  gibt. Dann können Informationen verloren gehen bzw. die geforderten Änderungen werden nicht durchgeführt.
  
−
HL7-Regeln besagen, dass grundsätzlich alle Felder mit Informationen gefüllt werden, wenn das sen¬den¬de System dafür Informationen vorhält. Das empfangende System wiederum ist gehalten, die über¬mittelte Information zu verarbeiten, damit die Daten¬bestände der beteiligten Systeme nicht in¬konsistent werden.
+
HL7-Regeln besagen, dass grundsätzlich alle Felder mit Informationen gefüllt werden, wenn das sendende System dafür Informationen vorhält. Das empfangende System wiederum ist gehalten, die übermittelte Information zu verarbeiten, damit die Datenbestände der beteiligten Systeme nicht inkonsistent werden.
−
Nur wenn eine Information explizit zu löschen ist oder bekannt ist, dass ein entspre¬chender Wert nicht vorhanden ist ("ich weiß, dass diese Information nicht bekannt|leer ist!"), sind die doppelten Anführungszeichen als Löschaufforderung zu verwen¬den. Letzteres darf aber nicht mit einer nicht vorhandenen Information ("Ich kenne diese Information nicht") verwechselt werden, dann muss das Feld/Komponente nur leer bleiben! Die doppelten Anführungszeichen dürfen nicht verwendet werden, wenn ein required-Feld einen Wert verlangt, aber keine Information vorhanden ist.
+
Nur wenn eine Information explizit zu löschen ist oder bekannt ist, dass ein entsprechender Wert nicht vorhanden ist ("ich weiß, dass diese Information nicht bekannt|leer ist!"), sind die doppelten Anführungszeichen als Löschaufforderung zu verwenden. Letzteres darf aber nicht mit einer nicht vorhandenen Information ("Ich kenne diese Information nicht") verwechselt werden, dann muss das Feld/Komponente nur leer bleiben! Die doppelten Anführungszeichen dürfen nicht verwendet werden, wenn ein required-Feld einen Wert verlangt, aber keine Information vorhanden ist.
  
 
==Konstruktionsregeln für das sendende System==
 
==Konstruktionsregeln für das sendende System==
Zeile 233: Zeile 233:
  
 
{| class="hl7table"
 
{| class="hl7table"
−
!die (Sub-)Komponente wird von dem sendenden System unterstützt!!
+
!colspan="3" | die (Sub-)Komponente wird von dem sendenden System unterstützt? !!
 
|-
 
|-
−
|Nein||||Ja
+
|'''Nein'''|| colspan="3"|'''Ja'''
 
|-
 
|-
−
|||es gibt für diese (Sub-)Komponente Daten||
+
|rowspan"3"|die (Sub-)Komponente nicht füllen || colspan="3"| Gibt es für diese (Sub-)Komponente Daten?
 
|-
 
|-
−
|||Ja||||Nein
+
|||Ja|| colspan="2" |Nein
 
|-
 
|-
−
|die (Sub-)Kom-||die (Sub-)Kom- ||vorhandene Daten sollen gelöscht werden
+
| ||die (Sub-)Komponente mit Daten füllen || colspan="2" | Sollen vorhandene Daten gelöscht werden?
 
|-
 
|-
−
|ponente nicht||ponente mit ||Ja||Nein
+
| || ||Ja||Nein
 
|-
 
|-
−
|füllen||Daten füllen||die (Sub-)Komponente mit ("") füllen||die (Sub-)Komponente leer lassen
+
| || ||die (Sub-)Komponente mit ("") füllen||die (Sub-)Komponente leer lassen
 
|-
 
|-
 
|}
 
|}
Zeile 251: Zeile 251:
  
 
==Parsingregeln für das empfangende System==
 
==Parsingregeln für das empfangende System==
−
Das empfangende System hat nach folgendem Regelwerk vorzugehen, um die Daten aus der Nach¬richt zu extrahieren.
+
Das empfangende System hat nach folgendem Regelwerk vorzugehen, um die Daten aus der Nachricht zu extrahieren.
  
 
{| class="hl7table"
 
{| class="hl7table"
−
!die (Sub-)Komponente wird unterstützt!!
+
!colspan="6"| Wird die (Sub-)Komponente unterstützt?
 
|-
 
|-
−
|Nein|| ||Ja
+
|'''Nein'''|| colspan="5" |'''Ja'''
 
|-
 
|-
−
|fertig||die (Sub-)Komponente ist vorhanden (||)||
+
|fertig|| colspan="5" | Ist die (Sub-)Komponente vorhanden ( | | )
 
|-
 
|-
−
|||Nein|| ||Ja
+
| ||'''Nein'''|| colspan="4" |'''Ja'''
 
|-
 
|-
−
|||fertig||die (Sub-)Komponente ist Null ("")||
+
| ||fertig||colspan="4" |Ist die (Sub-)Komponente Null ("")?
 
|-
 
|-
−
|||||Ja||||Nein
+
| || ||colspan="3"|Ja|| Nein
 
|-
 
|-
−
|||||die (Sub-)Komponente ist die einzig erforderliche||füllen der
+
| || ||colspan="3"| Ist die (Sub-)Komponente die einzig erforderliche? || füllen der Datenbank mit den Daten der (Sub)-Komponente
 
|-
 
|-
−
|||||Ja||Nein||Datenbank
+
| || ||Ja|| colspan="2"|Nein||
 
|-
 
|-
−
|||||löschen aller||alle erforderlichen (Sub-)Komponenten sind null||mit den Daten der
+
| || ||löschen aller (Sub-) Komponenten|| colspan="2"| Sind alle erforderlichen (Sub-)Komponenten null? ||
 
|-
 
|-
−
|||||(Sub-) Kom- ||Ja||Nein||(Sub)-
+
| || || ||Ja||Nein ||
−
Kom-
 
 
|-
 
|-
−
|||||ponenten||löschen aller (Sub-) Komponenten||füllend der Datenbank mit den Daten der (Sub-) Komponente||ponente
+
| || || ||löschen aller (Sub-) Komponenten||füllen der Datenbank mit den Daten der (Sub-) Komponente ||
 
|-
 
|-
 
|}
 
|}
Zeile 284: Zeile 283:
  
 
==Batch-Protokoll==
 
==Batch-Protokoll==
−
HL7 sieht vor, dass auch eine Reihe von HL7-Nachrichten auf einmal verarbeitet wird. Hierzu wurde das Batch-Protokoll mit den Segmenten FHS und FTS sowie BHS und BTS definiert. Die Verwendung des Batch-Protokolls ist nicht erlaubt. Stattdessen sind die Nach¬richten einzeln zu übertragen.
+
HL7 sieht vor, dass auch eine Reihe von HL7-Nachrichten auf einmal verarbeitet wird. Hierzu wurde das Batch-Protokoll mit den Segmenten FHS und FTS sowie BHS und BTS definiert. Die Verwendung des Batch-Protokolls ist nicht erlaubt. Stattdessen sind die Nachrichten einzeln zu übertragen.
  
 
=="Multi-Patient"-Messages==
 
=="Multi-Patient"-Messages==
Zeile 294: Zeile 293:
  
 
=Transport=
 
=Transport=
−
Der HL7-Nachrichtenstandard definiert Nachrichten auf Applikationsebene. Dies geschieht auf der ISO-Ebene 7 des ISO/OSI-Modells. Die darunter liegenden sechs Ebenen sind für den Austausch dieser Nachrichten vorgesehen und werden durch die sog. "Lower Layer Protocols" abgedeckt, so wie sie im HL7 Implementation Guide, Anhang C beschrieben sind. Der Standard selbst verlangt eine Kommuni¬kations¬umgebung, die
+
Der HL7-Nachrichtenstandard definiert Nachrichten auf Applikationsebene. Dies geschieht auf der ISO-Ebene 7 des ISO/OSI-Modells. Die darunter liegenden sechs Ebenen sind für den Austausch dieser Nachrichten vorgesehen und werden durch die sog. "Lower Layer Protocols" abgedeckt, so wie sie im HL7 Implementation Guide, Anhang C beschrieben sind. Der Standard selbst verlangt eine Kommunikationsumgebung, die
 
* eine fehlerfreie Übertragung,
 
* eine fehlerfreie Übertragung,
 
* eine Zeichensatzkonvertierung sowie
 
* eine Zeichensatzkonvertierung sowie
Zeile 320: Zeile 319:
 
darstellen.
 
darstellen.
  
−
Die HL7-Nachricht wird durch die Start- bzw. Endesequenz eingerahmt. Es ist nicht zulässig, außer¬halb dieser Gesamtsequenz Zeichen zu versenden. Auf Empfängerseite müssen diese Extra-Zeichen ignoriert werden. Ebenso haben die übertragenen Daten den Anforderungen an eine HL7-Nachricht zu genügen.
+
Die HL7-Nachricht wird durch die Start- bzw. Endesequenz eingerahmt. Es ist nicht zulässig, außerhalb dieser Gesamtsequenz Zeichen zu versenden. Auf Empfängerseite müssen diese Extra-Zeichen ignoriert werden. Ebenso haben die übertragenen Daten den Anforderungen an eine HL7-Nachricht zu genügen.
  
 
==HLLP==
 
==HLLP==
Zeile 326: Zeile 325:
  
 
==andere Transportmedien==
 
==andere Transportmedien==
−
Die Übertragung über andere Transportmedien wie bspw. per Dateien oder FTP wird nicht gefordert, obwohl anerkannt wird, dass dies ein häufig ein¬gesetztes Transportmedium ist.
+
Die Übertragung über andere Transportmedien wie bspw. per Dateien oder FTP wird nicht gefordert, obwohl anerkannt wird, dass dies ein häufig eingesetztes Transportmedium ist.
 
Die Übertragung über Dateien führt zu Zeitverzögerungen (Pollingverfahren) und birgt Restrisiken wie bspw. Verwaltung der Zugriffsrechte.
 
Die Übertragung über Dateien führt zu Zeitverzögerungen (Pollingverfahren) und birgt Restrisiken wie bspw. Verwaltung der Zugriffsrechte.
  
 
==Nachrichtenverteilung==
 
==Nachrichtenverteilung==
−
Die Verteilung der Nachrichten gestaltet sich unterschiedlich, je nachdem, ob ein Kommunikations¬server eingesetzt wird oder nicht.
+
Die Verteilung der Nachrichten gestaltet sich unterschiedlich, je nachdem, ob ein Kommunikationsserver eingesetzt wird oder nicht.
  
 
===mit Einsatz eines Kommunikationsservers===
 
===mit Einsatz eines Kommunikationsservers===
−
Wenn ein Kommunikationsserver eingesetzt wird, sind die Anwendungen weder für die Verteilung der Daten zu anderen Systemen noch für die Konvertierung in die Darstellung der anderen Systeme ver¬ant¬wortlich. Jedes System soll stattdessen ein allgemein verständliches Nachrichtenformat ver¬schicken, wobei die zugrundeliegenden Datentabellen vorher vereinbart wurden und die Nachricht soviel an Daten enthält, wie die sendende Applikation bereitstellen kann. Es liegt in der Verantwortung des weiterleitenden Systems (des Kommunikationsservers), dass die Nachrichten an die berechtigten Systeme mit einem geeig¬neten Datenkontext weitergeleitet werden.
+
Wenn ein Kommunikationsserver eingesetzt wird, sind die Anwendungen weder für die Verteilung der Daten zu anderen Systemen noch für die Konvertierung in die Darstellung der anderen Systeme verantwortlich. Jedes System soll stattdessen ein allgemein verständliches Nachrichtenformat verschicken, wobei die zugrundeliegenden Datentabellen vorher vereinbart wurden und die Nachricht soviel an Daten enthält, wie die sendende Applikation bereitstellen kann. Es liegt in der Verantwortung des weiterleitenden Systems (des Kommunikationsservers), dass die Nachrichten an die berechtigten Systeme mit einem geeigneten Datenkontext weitergeleitet werden.
 
Dazu müssen ein paar grundlegende Anforderungen erfüllt werden:
 
Dazu müssen ein paar grundlegende Anforderungen erfüllt werden:
  
Zeile 343: Zeile 342:
  
 
===ohne Einsatz eines Kommunikationsservers===
 
===ohne Einsatz eines Kommunikationsservers===
−
Wenn kein Kommunikationsserver eingesetzt wird, und man kann nicht immer von einem Einsatz ausgehen, so muss das sendende System in der Lage sein, die Nachrichten an verschiedene Ziel¬systeme weiterzuleiten. Hierzu gehört:
+
Wenn kein Kommunikationsserver eingesetzt wird, und man kann nicht immer von einem Einsatz ausgehen, so muss das sendende System in der Lage sein, die Nachrichten an verschiedene Zielsysteme weiterzuleiten. Hierzu gehört:
  
 
* Adressierung der Systeme im Nachrichtenkopf (evtl. über eine Broadcast-Kennung)
 
* Adressierung der Systeme im Nachrichtenkopf (evtl. über eine Broadcast-Kennung)
Zeile 354: Zeile 353:
  
 
=OIDs=
 
=OIDs=
−
Eine wichtige Grundlage für eine erfolgreiche Kommunikation ist die korrek¬te Identifikation der diversen Objekte. International hat sich dazu die sog. Objekt-Identi¬fikation – kurz OID – durchgesetzt.
+
Eine wichtige Grundlage für eine erfolgreiche Kommunikation ist die korrekte Identifikation der diversen Objekte. International hat sich dazu die sog. Objekt-Identifikation – kurz OID – durchgesetzt.
 
Die Verwaltung der OIDs für das deutsche Gesundheitswesen findet beim DIMDI statt. Dort gibt es auch nähere Informationen zu diesem Thema:
 
Die Verwaltung der OIDs für das deutsche Gesundheitswesen findet beim DIMDI statt. Dort gibt es auch nähere Informationen zu diesem Thema:
 
[http://www.dimdi.de/static/de/ehealth/oid/index.htm-http://www.dimdi.de/static/de/ehealth/oid/index.htm]  
 
[http://www.dimdi.de/static/de/ehealth/oid/index.htm-http://www.dimdi.de/static/de/ehealth/oid/index.htm]  
Zeile 364: Zeile 363:
 
c) Identifikation von Tabellen und den zulässigen Werten
 
c) Identifikation von Tabellen und den zulässigen Werten
  
−
Für den Nachrichtenaustausch sind die Profil-OIDs wichtig, da hierüber die Zuordnung und Einhaltung der entsprechenden Vorgaben geprüft werden kann. Jedes individuelle Profil (ob con¬strain¬able oder implementable) bekommt auf diese Weise seine eigene Identifikation. Derzeit wird nur geprüft, ob die vorgegebenen OIDs in den ausgetauschten Nachrichten über¬mittelt werden. Unabhängig davon sei den Herstellern angeraten, die Spezifikation zu ihren eigenen Profilen nicht nur zu veröffentlichen, sondern auch mit einer eindeutigen Identi¬fikation zu versehen. Letztere kann über die von HL7 zur Verfügung gestellten Methoden beantragt und auch registriert werden!
+
Für den Nachrichtenaustausch sind die Profil-OIDs wichtig, da hierüber die Zuordnung und Einhaltung der entsprechenden Vorgaben geprüft werden kann. Jedes individuelle Profil (ob constrainable oder implementable) bekommt auf diese Weise seine eigene Identifikation. Derzeit wird nur geprüft, ob die vorgegebenen OIDs in den ausgetauschten Nachrichten übermittelt werden. Unabhängig davon sei den Herstellern angeraten, die Spezifikation zu ihren eigenen Profilen nicht nur zu veröffentlichen, sondern auch mit einer eindeutigen Identifikation zu versehen. Letztere kann über die von HL7 zur Verfügung gestellten Methoden beantragt und auch registriert werden!
  
 
An dieser Stelle sei auf die entsprechende Stelle im Standard verwiesen (Kap.2 bzw. 2B) als auch auf die Webseite zur Registrierung von Nachrichtenprofilen.
 
An dieser Stelle sei auf die entsprechende Stelle im Standard verwiesen (Kap.2 bzw. 2B) als auch auf die Webseite zur Registrierung von Nachrichtenprofilen.
Zeile 371: Zeile 370:
 
Die Nachrichten in den aktuellen Profilen folgen einem einfachen Interaktionsschema:
 
Die Nachrichten in den aktuellen Profilen folgen einem einfachen Interaktionsschema:
 
 
−
+
[[file:Profile_transport.gif]]
  
−
Ein Ereignis der realen Welt löst eine Nachricht aus, auf die es (optional) eine synchrone Transport¬quittung gibt. Mit einer gewissen Verzögerung kann es auf die eigentliche Nachricht auch eine asynchrone Verarbeitungs¬quittung geben, die dann ebenfalls (optional) mit einer synchronen Transportquittung bestätigt wird. Die Anforderung von beiden Quittungsnachrichten wird in den entsprechenden Feldern im Nachrichten¬kopf der Ursprungsnachricht festgelegt.
+
Ein Ereignis der realen Welt löst eine Nachricht aus, auf die es (optional) eine synchrone Transportquittung gibt. Mit einer gewissen Verzögerung kann es auf die eigentliche Nachricht auch eine asynchrone Verarbeitungsquittung geben, die dann ebenfalls (optional) mit einer synchronen Transportquittung bestätigt wird. Die Anforderung von beiden Quittungsnachrichten wird in den entsprechenden Feldern im Nachrichtenkopf der Ursprungsnachricht festgelegt.
  
 
=Zeichensätze=
 
=Zeichensätze=
Zeile 406: Zeile 405:
  
 
{| class="hl7table"
 
{| class="hl7table"
−
!Code position!!ISO Latin 1!!ISO Latin 9
+
!colspan="3"| Code position!!colspan="3"| ISO Latin 1!!colspan="3"|ISO Latin 9
 
|-
 
|-
−
|dez||okt||hex||Zeichen||U+nnnn||Name||Zeichen||U+nnnn||Unicode name
+
!dez!!okt!!hex!!Zeichen!!U+nnnn!!Name!!Zeichen!!U+nnnn!!Unicode name
 
|-
 
|-
 
|164||244||A4||¤||U+00A4||currency symbol||€||U+20AC||euro sign
 
|164||244||A4||¤||U+00A4||currency symbol||€||U+20AC||euro sign
Zeile 442: Zeile 441:
  
 
{| class="hl7table"
 
{| class="hl7table"
−
|bgcolor="ccffff" |alpha-3 (terminologisch)||bgcolor="ccffff" |alpha-3 (bibliografisch)||bgcolor="ccffff" |alpha-2||bgcolor="ccffff" |English names||bgcolor="ccffff" |German Names
+
!alpha-3 (terminologisch)!!alpha-3 (bibliografisch)!!alpha-2!!English names!!German Names
 
|-
 
|-
−
|bgcolor="ccffff" |ara||bgcolor="ccffff" |ara||bgcolor="ccffff" |ar||bgcolor="ccffff" |Arabic||bgcolor="ccffff" |arabisch
+
|ara||ara||ar||Arabic||arabisch
 
|-
 
|-
−
|bgcolor="ccffff" |cat||bgcolor="ccffff" |cat||bgcolor="ccffff" |ca||bgcolor="ccffff" |Catalan||bgcolor="ccffff" |katalanisch
+
|cat||cat||ca||Catalan||katalanisch
 
|-
 
|-
−
|bgcolor="ccffff" |ces||bgcolor="ccffff" |cze||bgcolor="ccffff" |cs||bgcolor="ccffff" |Czech||bgcolor="ccffff" |tschechisch
+
|ces||cze||cs||Czech||tschechisch
 
|-
 
|-
−
|bgcolor="ccffff" |dan||bgcolor="ccffff" |dan||bgcolor="ccffff" |da||bgcolor="ccffff" |Danish||bgcolor="ccffff" |dänisch
+
|dan||dan||da||Danish||dänisch
 
|-
 
|-
−
|bgcolor="ccffff" |deu||bgcolor="ccffff" |ger||bgcolor="ccffff" |de||bgcolor="ccffff" |German||bgcolor="ccffff" |deutsch
+
|deu||ger||de||German||deutsch
 
|-
 
|-
−
|bgcolor="ccffff" |ell||bgcolor="ccffff" |gre||bgcolor="ccffff" |el||bgcolor="ccffff" |Modern Greek (post 1453)||bgcolor="ccffff" |griechisch
+
|ell||gre||el||Modern Greek (post 1453)||griechisch
 
|-
 
|-
−
|bgcolor="ccffff" |eng||bgcolor="ccffff" |eng||bgcolor="ccffff" |en||bgcolor="ccffff" |English||bgcolor="ccffff" |englisch
+
|eng||eng||en||English||englisch
 
|-
 
|-
−
|bgcolor="ccffff" |epo||bgcolor="ccffff" |epo||bgcolor="ccffff" |eo||bgcolor="ccffff" |Esperanto||bgcolor="ccffff" |Esperanto
+
|epo||epo||eo||Esperanto||Esperanto
 
|-
 
|-
−
|bgcolor="ccffff" |fin||bgcolor="ccffff" |fin||bgcolor="ccffff" |fi||bgcolor="ccffff" |Finnish||bgcolor="ccffff" |finnisch
+
|fin||fin||fi||Finnish||finnisch
 
|-
 
|-
−
|bgcolor="ccffff" |fra||bgcolor="ccffff" |fre||bgcolor="ccffff" |fr||bgcolor="ccffff" |French||bgcolor="ccffff" |französisch
+
|fra||fre||fr||French||französisch
 
|-
 
|-
−
|bgcolor="ccffff" |heb||bgcolor="ccffff" |heb||bgcolor="ccffff" |he||bgcolor="ccffff" |Hebrew||bgcolor="ccffff" |hebräisch
+
|heb||heb||he||Hebrew||hebräisch
 
|-
 
|-
−
|bgcolor="ccffff" |hun||bgcolor="ccffff" |hun||bgcolor="ccffff" |hu||bgcolor="ccffff" |Hungarian||bgcolor="ccffff" |ungarisch
+
|hun||hun||hu||Hungarian||ungarisch
 
|-
 
|-
−
|bgcolor="ccffff" |ita||bgcolor="ccffff" |ita||bgcolor="ccffff" |it||bgcolor="ccffff" |Italian||bgcolor="ccffff" |italienisch
+
|ita||ita||it||Italian||italienisch
 
|-
 
|-
−
|bgcolor="ccffff" |jpn||bgcolor="ccffff" |jpn||bgcolor="ccffff" |ja||bgcolor="ccffff" |Japanese||bgcolor="ccffff" |japanisch
+
|jpn||jpn||ja||Japanese||japanisch
 
|-
 
|-
−
|bgcolor="ccffff" |nld||bgcolor="ccffff" |dut||bgcolor="ccffff" |nl||bgcolor="ccffff" |Dutch||bgcolor="ccffff" |holländisch
+
|nld||dut||nl||Dutch||holländisch
 
|-
 
|-
−
|bgcolor="ccffff" |nor||bgcolor="ccffff" |nor||bgcolor="ccffff" |no||bgcolor="ccffff" |Norwegian||bgcolor="ccffff" |norwegisch
+
|nor||nor||no||Norwegian||norwegisch
 
|-
 
|-
−
|bgcolor="ccffff" |pol||bgcolor="ccffff" |pol||bgcolor="ccffff" |pl||bgcolor="ccffff" |Polish||bgcolor="ccffff" |polnisch
+
|pol||pol||pl||Polish||polnisch
 
|-
 
|-
−
|bgcolor="ccffff" |rus||bgcolor="ccffff" |rus||bgcolor="ccffff" |ru||bgcolor="ccffff" |Russian||bgcolor="ccffff" |russisch
+
|rus||rus||ru||Russian||russisch
 
|-
 
|-
−
|bgcolor="ccffff" |sgn||bgcolor="ccffff" |sgn||bgcolor="ccffff" | ||bgcolor="ccffff" |sign languages||bgcolor="ccffff" |Zeichensprache
+
|sgn||sgn|| ||sign languages||Zeichensprache
 
|-
 
|-
−
|bgcolor="ccffff" |spa||bgcolor="ccffff" |spa||bgcolor="ccffff" |es||bgcolor="ccffff" |Spanish; Castilian||bgcolor="ccffff" |spanisch (kastillian)
+
|spa||spa||es||Spanish; Castilian||spanisch (kastillian)
 
|-
 
|-
−
|bgcolor="ccffff" |swe||bgcolor="ccffff" |swe||bgcolor="ccffff" |sv||bgcolor="ccffff" |Swedish||bgcolor="ccffff" |schwedisch
+
|swe||swe||sv||Swedish||schwedisch
 
|-
 
|-
−
|bgcolor="ccffff" |tur||bgcolor="ccffff" |tur||bgcolor="ccffff" |tr||bgcolor="ccffff" |Turkish||bgcolor="ccffff" |türkisch
+
|tur||tur||tr||Turkish||türkisch
 
|-
 
|-
−
|bgcolor="ccffff" |zho||bgcolor="ccffff" |chi||bgcolor="ccffff" |zh||bgcolor="ccffff" |Chinese||bgcolor="ccffff" |chinesisch
+
|zho||chi||zh||Chinese||chinesisch
 
|-
 
|-
−
|bgcolor="ccffff" |...||bgcolor="ccffff" |...||bgcolor="ccffff" |...||bgcolor="ccffff" |...||bgcolor="ccffff" |...
+
|...||...||...|||...|||...
 
|-
 
|-
 
|}
 
|}

Aktuelle Version vom 2. Juni 2015, 10:35 Uhr

Under construction icon-blue.svg
 This article or section is in the middle of an expansion or major restructuring and is not yet ready for use. You are welcome to assist in its construction by editing it as well. If this article has not been edited in several days, please remove this template.
This article was last edited by Foemig (talk| contribs) 9 years ago. (Purge)
Diese Seite oder Abschnitt ist derzeit ein Entwurf und ist noch nicht fertiggestellt. Du bist eingeladen, bei der Fertigstellung mitzuwirken. Wenn dieser Beitrag länger als einige Tage nicht editiert wurde, entferne diese Vorlage.
This article was last edited by Foemig (talk| contribs) 9 years ago. (Purge)
Logo-hl720.jpg
{{{Title}}}
deutsche Nachrichtenprofile: Rahmen-Dokument
Nachrichtenprofile
vorgelegt von:
HL7-Deutschland
ballotiert
Version: 01
Datum: 20. Dezember 2013
Status: Si-draft.svg Entwurf
Verfahren: {{{Verfahren}}}
Realm: Flag de.svg Deutschland
Copyright © 2013: HL7 Deutschland


Abstimmungsdokument 
Version Datum Status Realm
01 15.08.2013 ballotiert Flag de.svg Deutschland
Document PDF.svg noch kein download verfügbar
Kontributoren 
Logo-Agfa.jpg Agfa HealthCare GmbH Bonn
Cortex Software GmbH
Logo icw.jpg|100px]] InterComponentWare Walldorf
Logo sap.jpg|100px]] SAP Walldorf
Logo ser.jpg|100px]] SER HealthCare Solutions GmbH
Logo ztg.gif|100px]] Zentrum für Telematik im Gesundheitswesen GmbH Bochum
Logo os.jpg|100px]] Optimal Systems GmbH Berlin
Information icon.svg Grafiken fehlen

Tabellenstruktur (Schrägstriche)

Nummerierung
Version: 01
Ausgabe: 2013
HL7-Version: 2.5
Stand: 02. Oktober 2013
Dokumenten-OID: 2.16.840.1.113883.2.6.7.26

Ansprechpartner:

Frank Oemig, Agfa HealthCare GmbH, Bonn

Dokumentinformation

Änderungshistorie

Version Datum Bemerkung Dok.-OID
3.0 07.03.13 Vorbereitung Freigabe
2.2 14.12.11 Anpassung an IHE ITI PAM
2.0 01.02.06 Reconciliation 2.16.840.1.113883.2.6.7.26
1.9 23.09.05 Erweiterung um Hinweis auf Erstellung von Konformanzprofilen und OIDs
1.1 18.12.04 techn.Korrekturen 2.16.840.1.113883.2.6.7.13
1.0 14.10.04 Erstellung 2.16.840.1.113883.2.6.7.1


Editor

  • Frank Oemig (FO), Agfa HealthCare GmbH, Bonn


Review Release 2.1

  • Bernd Blobel, eHealth Competence Center, Regensburg
  • Dirk Engels, Health-Comm GmbH
  • Kai Heitmann, Universität Köln
  • Peter Kaufmann, MCS AG
  • Frank Oemig (FO), Agfa HealthCare GmbH, Bonn
  • Peter Scholz, OSM GmbH
  • René Spronk, Ringholm GmbH Integration Consulting


Autoren Ausgabe 2013

  • Ralf Brandner, InterComponentWare
  • Fakhri Zain Elabdin, CORTEX
  • Bettina Lieske, SAP
  • Frank Oemig (FO), Agfa HealthCare GmbH, Bonn
  • Marek Václavik, SER HealthCare Solutions GmbH


Autoren und Copyright-Hinweis, Nutzungshinweise

Nachnutzungs- bzw. Veröffentlichungsansprüche

Das vorliegende Dokument wurde von Agfa HealthCare in Kooperation mit InterComponentWare und optimal systems entwickelt. Die Nachnutzungs- bzw. Veröffentlichungsansprüche sind nicht beschränkt.


Der Inhalt dieser Spezifikation ist öffentlich.

Zu beachten ist, dass Teile dieses Dokuments auf dem HL7-Standard v2.5 beruhen, für die © Health Level Seven, Inc. gilt. Näheres unter [1] und [2].

Die Erweiterung oder Ablehnung der Spezifikation, ganz oder in Teilen, ist dem Vorstand der Benutzergruppe und den Editoren/Autoren schriftlich anzuzeigen.


Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifkationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.


Disclaimer

Obwohl diese Publikation mit größter Sorgfalt erstellt wurde, kann weder die HL7-Benutzergruppe in Deutschland e.V. noch die an der Erstellung beteiligten Firmen keinerlei Haftung für direkten oder indirekten Schaden übernehmen, die durch den Inhalt dieser Spezifikation entstehen könnten.


Einleitung

Diese Serie von Dokumenten dokumentiert den HL7-Standard, so wie er in Deutschland angewendet werden soll. Grundlage der Arbeiten ist die HL7-Version 2.5 in der deutschen Fassung. Hierbei sind gegenüber der internationalen Version Anpassungen an die landesspezifischen Anforderungen vorgenommen worden. Hierzu zählen neben der Kennzeichnung einzelner Teile als "nicht verwendet", insbesondere die Erweiterung von Datentabellen sowie die Definition spezieller Z-Segmente. Mit diesen Dokumenten sollen die Inhalte aus den Originaldokumenten nicht wiederholt werden, so dass an dieser Stelle empfohlen sei, die Nachrichtenprofile zusammen mit den Originaldokumenten zu lesen. Es werden alle required-Felder sowie besondere optionale Felder erläutert.

Scope

Diese Nachrichtenprofile dienen zur konformen Entwicklung von Interfaces zu in Deutschland eingesetzten Anwendungen. Dazu bedarf es der Verarbeitung einer Mindestmenge an Informationen, die über diese Profile ebenfalls festgelegt wird.

In diesem Dokument werden die Informationen beschrieben, die nicht-normativer Bestandteil der Profile sind.

Dokumentenstruktur

Die Struktur der Dokumente ist in einem separaten Dokument beschrieben.

Konformanzprofile

Die hier beschriebenen Dokumente stellen eine Einschränkung des offiziellen Standards nach den vorgegebenen Regeln dar, die im Abschnitt 2.12 des Kapitels 2 nachgelesen werden können.

Kodierrichtlinien

Die Kodierrichtlinien geben an, wie die Daten in Nachrichten zu "verpacken" sind.

Konditionale Elemente

Diese Spezifikation nutzt die relativ neue Darstellung von Bedingungen. Hierbei wird unter „Verwendung" folgende Notation genutzt:

C(a/b)

Hiebei steht „a" bzw. „b" für die Optionalität, die im TRUE bzw. FALSE Fall gilt. Die Bedingung muss sich dabei an den Nachrichteninhalten ermitteln lassen.

Escape-Sequenzen

Bedingt durch die Serialisierung der Daten über Trennzeichen dürfen letztere nicht in den eigentlichen Informationen vorkommen. Erreicht wird dies durch die Ersetzung mit sog. Escape-Sequenzen. Im Gegensatz zu herkömmlichen Programmiersprachen ist dies keine Entwertung (wie in VB durch '""' für ein einfaches doppeltes Anführungszeichen in einer Zeichenkette oder in der printf-Anweisung in C mittels '%'), sondern ein Austausch des Zeichens selber:

Verwendung Escape-Sequenz Beispiel Escape-Symbol: ‚a’' ‚;’'
R \F\ field separator aFa ;F;
R \S\ component separator aSa ;S;
R \T\ subcomponent separator aTa ;T;
R \R\ repetition separator aRa ;R;
R \E\ escape character aEa ;E;
X \H\ start highlighting aHa ;H;
X \N\ normal text (end highlighting) aNa ;N;
O \Xdddd...\ hexadecimal data aXdddd…a ;Xdddd…;
X \Zdddd...\ locally defined escape sequence aZdddd…a ;Zddd…;

Für eine korrekte Umsetzung dieser Entwertung ist die Prüfung dieser Escape-Sequenzen auf Subkomponentenebene vorzunehmen. Da für eine Übertragung eine reine ASCII-7-Bit-Kodierung zugelassen ist, sind hier alle Zeichen oberhalb von 127 durch entsprechende Escape-Sequenzen zu darzustellen.

Carriage-Return

Gemäß der Kodierrichtlinien sind die Trennzeichen (MSH-1 und MSH-2) variabel, d.h. erst in der eigentlichen Nachricht konkret definiert. Dies trifft allerdings für den Segment-Terminator nicht zu. Hier ist CR (Hex 0D) fest vorgegeben. Folglich darf CR an keiner Stelle in einem Datenfeld (Feld, Komponente oder Subkomponente) auftreten. Für Datenfelder vom Typ 'ST' sind nur druckbare Zeichen zugelassen.

Textformatierung

In Datenfeldern vom Typ 'TX' können evtl. Zeilenumbrüche über eine Wiederholung realisiert werden, welches für jedes Datenfeld individuell festgelegt ist.

Für formatierten Text gelten folgende Format-Befehle, von denen nur die mit 'R' markierten unterstützt werden müssen:

Verw. Befehl Beschreibung
O .sp <number> Aktuelle Zeile beenden und <number> Leerzeilen einfügen. <number> ist eine positive Ganzzahl. Wenn <number> fehlt, gilt der Standardwert "1". Die horizontale Position bleibt erhalten.

Zur Erhaltung der Kompatibilität mit früheren Versionen wird "^\.sp\" als "\.br\" verstanden.

R .br Aktuelle Zeile beenden und neue beginnen. Die horizontale Position wird auf "1" gesetzt.
O .fi Beginn Blocksatz (Default)
O .nf Ende Blocksatz
O .in <number> Ab hier alle Absätze um <number> Zeichen einrücken, wobei <number> eine positive oder negative Ganzzahl ist.

Dieser Befehl darf nur am Anfang einer Zeile verwendet werden.

O .ti <number> Diesen Absatz um <number> Zeichen ein- oder ausrücken.

Dieser Befehl darf nur am Anfang einer Zeile verwendet werden.

O .sk < number> <number> Leerzeichen einfügen.
O .ce Aktuelle Zeile beenden und die nächste zentrieren.


Versionsabhängigkeiten

Bedingt durch Inkompatibilitäten zwischen den unterschiedlichen HL7-Versionen insbesondere in den allgemein relevanten Feldern wie Patienten-ID und Name des Patienten wird eine Verarbeitung nach der "Version Compatibility Definition" nicht gefordert. Statt dessen wird eine Erfüllung der in den Profilen festgelegten Bedingungen verlangt. Dies ist eine Vereinfachung der allgemeinen Verarbeitungslogik, da normalerweise eine Verarbeitung der Elemente auch für vorhergehende HL7-Definitionen gefordert wird.

Null-Werte vs. nicht vorhanden

Die in einer Umgebung eingesetzten Systeme unterscheiden sich grundsätzlich in Art und Umfang der gespeicherten Daten. Es wird problematisch, wenn es keine Regeln zur Handhabung von Feldern und deren Komponenten unter Berücksichtigung von Null-Werten dargestellt durch zwei doppelte Anführungszeichen ("") gibt. Dann können Informationen verloren gehen bzw. die geforderten Änderungen werden nicht durchgeführt.

HL7-Regeln besagen, dass grundsätzlich alle Felder mit Informationen gefüllt werden, wenn das sendende System dafür Informationen vorhält. Das empfangende System wiederum ist gehalten, die übermittelte Information zu verarbeiten, damit die Datenbestände der beteiligten Systeme nicht inkonsistent werden. Nur wenn eine Information explizit zu löschen ist oder bekannt ist, dass ein entsprechender Wert nicht vorhanden ist ("ich weiß, dass diese Information nicht bekannt|leer ist!"), sind die doppelten Anführungszeichen als Löschaufforderung zu verwenden. Letzteres darf aber nicht mit einer nicht vorhandenen Information ("Ich kenne diese Information nicht") verwechselt werden, dann muss das Feld/Komponente nur leer bleiben! Die doppelten Anführungszeichen dürfen nicht verwendet werden, wenn ein required-Feld einen Wert verlangt, aber keine Information vorhanden ist.

Konstruktionsregeln für das sendende System

Das sendende System hat die Felder gemäß folgendem Regelwerk mit Daten zu füllen:

die (Sub-)Komponente wird von dem sendenden System unterstützt?
Nein Ja
die (Sub-)Komponente nicht füllen Gibt es für diese (Sub-)Komponente Daten?
Ja Nein
die (Sub-)Komponente mit Daten füllen Sollen vorhandene Daten gelöscht werden?
Ja Nein
die (Sub-)Komponente mit ("") füllen die (Sub-)Komponente leer lassen


Parsingregeln für das empfangende System

Das empfangende System hat nach folgendem Regelwerk vorzugehen, um die Daten aus der Nachricht zu extrahieren.

Wird die (Sub-)Komponente unterstützt?
Nein Ja
fertig Ist die (Sub-)Komponente vorhanden ( | | )
Nein Ja
fertig Ist die (Sub-)Komponente Null ("")?
Ja Nein
Ist die (Sub-)Komponente die einzig erforderliche? füllen der Datenbank mit den Daten der (Sub)-Komponente
Ja Nein
löschen aller (Sub-) Komponenten Sind alle erforderlichen (Sub-)Komponenten null?
Ja Nein
löschen aller (Sub-) Komponenten füllen der Datenbank mit den Daten der (Sub-) Komponente


Fortsetzung von Nachrichten

Die Fortsetzung von Nachrichten durch partielle Übermittlung wird nicht unterstützt, da diese Technik veraltet ist und nie verwendet wurde.

Batch-Protokoll

HL7 sieht vor, dass auch eine Reihe von HL7-Nachrichten auf einmal verarbeitet wird. Hierzu wurde das Batch-Protokoll mit den Segmenten FHS und FTS sowie BHS und BTS definiert. Die Verwendung des Batch-Protokolls ist nicht erlaubt. Stattdessen sind die Nachrichten einzeln zu übertragen.

"Multi-Patient"-Messages

Die meisten HL7-Nachrichten sehen vor, dass innerhalb einer Nachricht mehrere Patienten adressiert werden dürfen. Dies wird nicht gestattet. In einer Nachricht darf immer nur ein Patient referenziert werden. Ausgenommen sind die Nachrichten, in denen zwangsweise zwei Patienten referenziert werden müssen, wie bspw. bei der Link- oder Merge-Nachricht. Umgekehrt ist ein PID-Segment bzw. PV1-Segment zu übermitteln (RE), wenn die Nachrichtenstruktur dies erlaubt und es eine patientenbezogene Nachricht ist.

Tabellenwerte

Für einige Feldwerte sind Tabellen vorgesehen. In vielen Fällen lassen sich konkrete Werte exakt vorschreiben. In den Fällen, wo dies nicht möglich ist, enthält die Tabelle als letzten Eintrag "...". Dann sind auch weitere Werte zulässig.

Transport

Der HL7-Nachrichtenstandard definiert Nachrichten auf Applikationsebene. Dies geschieht auf der ISO-Ebene 7 des ISO/OSI-Modells. Die darunter liegenden sechs Ebenen sind für den Austausch dieser Nachrichten vorgesehen und werden durch die sog. "Lower Layer Protocols" abgedeckt, so wie sie im HL7 Implementation Guide, Anhang C beschrieben sind. Der Standard selbst verlangt eine Kommunikationsumgebung, die

  • eine fehlerfreie Übertragung,
  • eine Zeichensatzkonvertierung sowie
  • eine unbegrenzte Nachrichtenlänge

vorsieht. Für einen Konformanztest wird eine Transportumgebung vorausgesetzt, um den Nachrichtenaustausch überhaupt überprüfen zu können. Hier ist noch zu überlegen, ob dies Bestandteil des Zertifikats oder der Testumgebung sein soll. Letztere wird in einem separaten Dokument beschrieben. Zur Erhöhung der Qualität der Systemintegration wird die Transportinfrastruktur als Bestandteil des Basis-Profils definiert.

MLLP

HL7-konforme Implementierungen sollen das Minimal Lower Layer Protocol (MLLP) auf Basis von TCP/IP unterstützen.

Der Nachrichtenumschlag gemäß MLLP hat folgendes Format: <SB>dddd<EB><CR> wobei:

<SB> start block character (ASCII <VT>, d.h. x0B)
dddd Daten, die eigentliche HL7-Nachricht
<EB> end block character (ASCII <FS>, d.h. x1C)
<CR> carriage return (ASCII <CR>, d.h. x0D)

darstellen.

Die HL7-Nachricht wird durch die Start- bzw. Endesequenz eingerahmt. Es ist nicht zulässig, außerhalb dieser Gesamtsequenz Zeichen zu versenden. Auf Empfängerseite müssen diese Extra-Zeichen ignoriert werden. Ebenso haben die übertragenen Daten den Anforderungen an eine HL7-Nachricht zu genügen.

HLLP

Das Hybrid Lower Layer Protocol (HLLP) wird nicht unterstützt.

andere Transportmedien

Die Übertragung über andere Transportmedien wie bspw. per Dateien oder FTP wird nicht gefordert, obwohl anerkannt wird, dass dies ein häufig eingesetztes Transportmedium ist. Die Übertragung über Dateien führt zu Zeitverzögerungen (Pollingverfahren) und birgt Restrisiken wie bspw. Verwaltung der Zugriffsrechte.

Nachrichtenverteilung

Die Verteilung der Nachrichten gestaltet sich unterschiedlich, je nachdem, ob ein Kommunikationsserver eingesetzt wird oder nicht.

mit Einsatz eines Kommunikationsservers

Wenn ein Kommunikationsserver eingesetzt wird, sind die Anwendungen weder für die Verteilung der Daten zu anderen Systemen noch für die Konvertierung in die Darstellung der anderen Systeme verantwortlich. Jedes System soll stattdessen ein allgemein verständliches Nachrichtenformat verschicken, wobei die zugrundeliegenden Datentabellen vorher vereinbart wurden und die Nachricht soviel an Daten enthält, wie die sendende Applikation bereitstellen kann. Es liegt in der Verantwortung des weiterleitenden Systems (des Kommunikationsservers), dass die Nachrichten an die berechtigten Systeme mit einem geeigneten Datenkontext weitergeleitet werden. Dazu müssen ein paar grundlegende Anforderungen erfüllt werden:

  • Weiterleitung einer Nachricht an mehrere Systeme abhängig von dem sendenden System und dem Nachrichtentyp/Ereigniscode
  • Quittierung der Nachrichten einschließlich der Nachrichtenkontrollnummer
  • explizite Adressierung an ein Zielsystem oder Adressierung mit einer Broadcast-Kennung

Es wird empfohlen, dass die sendenden Anwendungen ausgehende Nachrichten zwischenspeichern können, falls das annehmende System gerade nicht verfügbar ist.

ohne Einsatz eines Kommunikationsservers

Wenn kein Kommunikationsserver eingesetzt wird, und man kann nicht immer von einem Einsatz ausgehen, so muss das sendende System in der Lage sein, die Nachrichten an verschiedene Zielsysteme weiterzuleiten. Hierzu gehört:

  • Adressierung der Systeme im Nachrichtenkopf (evtl. über eine Broadcast-Kennung)
  • Versand der Nachrichten in Abhängigkeit des Nachrichtentyps/Ereigniscodes
  • Aufbau einer Kommunikationsbeziehung zu mehreren Anwendungen
  • Zwischenspeicherung der Nachrichten, falls der Kommunikationspartner nicht verfügbar ist
  • Empfang der Nachrichtenquittungen

Inwieweit eine Verteilung der Nachrichten implementiert werden muss, hängt von der jeweiligen Natur der Nachrichten ab. Dies wird in den jeweiligen Profilen genauer geregelt.

OIDs

Eine wichtige Grundlage für eine erfolgreiche Kommunikation ist die korrekte Identifikation der diversen Objekte. International hat sich dazu die sog. Objekt-Identifikation – kurz OID – durchgesetzt. Die Verwaltung der OIDs für das deutsche Gesundheitswesen findet beim DIMDI statt. Dort gibt es auch nähere Informationen zu diesem Thema: [3]

Einsatz von OIDs bei Nachrichtenprofilen

Die Nachrichtenprofile machen an drei Stellen gebrauch von OIDs: a) Identifikation der Spezifikation (Dokumenten-OIDs) b) Identifikation der Nachrichtenprofile (Profil-OID) c) Identifikation von Tabellen und den zulässigen Werten

Für den Nachrichtenaustausch sind die Profil-OIDs wichtig, da hierüber die Zuordnung und Einhaltung der entsprechenden Vorgaben geprüft werden kann. Jedes individuelle Profil (ob constrainable oder implementable) bekommt auf diese Weise seine eigene Identifikation. Derzeit wird nur geprüft, ob die vorgegebenen OIDs in den ausgetauschten Nachrichten übermittelt werden. Unabhängig davon sei den Herstellern angeraten, die Spezifikation zu ihren eigenen Profilen nicht nur zu veröffentlichen, sondern auch mit einer eindeutigen Identifikation zu versehen. Letztere kann über die von HL7 zur Verfügung gestellten Methoden beantragt und auch registriert werden!

An dieser Stelle sei auf die entsprechende Stelle im Standard verwiesen (Kap.2 bzw. 2B) als auch auf die Webseite zur Registrierung von Nachrichtenprofilen.

Interaktionsdiagramm

Die Nachrichten in den aktuellen Profilen folgen einem einfachen Interaktionsschema:

Profile transport.gif

Ein Ereignis der realen Welt löst eine Nachricht aus, auf die es (optional) eine synchrone Transportquittung gibt. Mit einer gewissen Verzögerung kann es auf die eigentliche Nachricht auch eine asynchrone Verarbeitungsquittung geben, die dann ebenfalls (optional) mit einer synchronen Transportquittung bestätigt wird. Die Anforderung von beiden Quittungsnachrichten wird in den entsprechenden Feldern im Nachrichtenkopf der Ursprungsnachricht festgelegt.

Zeichensätze

Die im Segment MSH angesprochenen Zeichensätze können wie folgt zusammengefasst werden. Genaueres dazu ist auf diversen Websites verfügbar:

ASCII: American Standard Code for Information Interchange

Dieser Zeichensatz umfasst Zeichen beginnend mit dem Code 32 (Leerzeichen) und endend mit 255 (Tilde). Die Positionen 0 bis 31 und 127 sind nicht-druckbare Zeichen, deren Darstellung nicht definiert ist. Die Codes von 128 bis 255 sind nicht genutzt:

Die ASCII Code von 32 bis 126 (dezimal): 

  ! " \# $ % & ' ( ) \* + , - . /
0 1 2 3 4 5 6 7 8 9 : ; < = > ?
@ A B C D E F G H I J K L M N O
P Q R S T U V W X Y Z [ \ ] ^ _
` a b c d e f g h i j k l m n o
p q r s t u v w x y z { | } ~


ISO 8859/1 alias ISO Latin 1

Dieser Zeichensatz für Westeuropa belegt auf den Positionen 160 bis 255 folgende Zeichen: 

  ¡ ¢ £ ¤ ¥ ¦ § ¨ © ª « ¬ ¬ ® ¯
° ± ² ³ ´ µ ¶ • ¸ ¹ º » ¼ ½ ¾ ¿
À Á Â Ã Ä Å Æ Ç È É Ê Ë Ì Í Î Ï
Ð Ñ Ò Ó Ô Õ Ö × Ø Ù Ú Û Ü Ý Þ ß
à á â ã ä å æ ç è é ê ë ì í î ï
ð ñ ò ó ô õ ö ÷ ø ù ú û ü ý þ ÿ


ISO 8859/15 alias ISO Latin 9

Der Zeichensatz 8859/15 unterscheidet sich von 8859/1 nur an einigen Stellen:

Code position ISO Latin 1 ISO Latin 9
dez okt hex Zeichen U+nnnn Name Zeichen U+nnnn Unicode name
164 244 A4 ¤ U+00A4 currency symbol € U+20AC euro sign
166 246 A6 ¦ U+00A6 broken bar Š U+0160 latin capital letter
s with caron
168 250 A8 ¨ U+00A8 diaeresis š U+0161 latin small letter
s with caron
180 264 B4 ´ U+00B4 acute accent Ž U+017D latin capital letter
z with caron
184 270 B8 ¸ U+00B8 cedilla ž U+017E latin small letter
z with caron
188 274 BC ¼ U+00BC vulgar fraction
one quarter		 ΠU+0152 latin capital

ligature oe

189 275 BD ½ U+00BD vulgar fraction
one half		 œ U+0153 latin small
ligature oe
190 276 BE ¾ U+00BE vulgar fraction three quarters Ϋ U+0178 latin capital letter
y with diaeresis


Unicode UTF-8

Alle Zeichencodes kleiner als 128 werden durch ein Byte (ASCII) dargestellt. Alle anderen werden nach einer relativ komplizierten Methode dargestellt, so dass ein Zeichen durch 2 bis 6 Bytes jedes davon im Bereich von 128 bis 255 übermittelt wird. Das heißt, dass in einem Bytestrom Bytes mit einem Code von 0 bis 127 (höchstwertiges Bit ist "0") direkt als ASCII-Zeichen verstanden werden, alle anderen aber als kodierte Zeichen zu verstehen sind.

Genauere Informationen und Beispiele über diese Erklärung hinaus dazu finden sich zuhauf im Internet.

Tabellen

ISO-Tabelle 639 – Sprachen

Der nachfolgende Ausschnitt aus der ISO-Tabelle 639 listet die am häufigsten der in Deutschland verwendeten Sprachen auf. Eine Nutzung von nicht gelisteten Einträgen ist deshalb zulässig. Die terminologischen Codes sind zu benutzen:

alpha-3 (terminologisch) alpha-3 (bibliografisch) alpha-2 English names German Names
ara ara ar Arabic arabisch
cat cat ca Catalan katalanisch
ces cze cs Czech tschechisch
dan dan da Danish dänisch
deu ger de German deutsch
ell gre el Modern Greek (post 1453) griechisch
eng eng en English englisch
epo epo eo Esperanto Esperanto
fin fin fi Finnish finnisch
fra fre fr French französisch
heb heb he Hebrew hebräisch
hun hun hu Hungarian ungarisch
ita ita it Italian italienisch
jpn jpn ja Japanese japanisch
nld dut nl Dutch holländisch
nor nor no Norwegian norwegisch
pol pol pl Polish polnisch
rus rus ru Russian russisch
sgn sgn sign languages Zeichensprache
spa spa es Spanish; Castilian spanisch (kastillian)
swe swe sv Swedish schwedisch
tur tur tr Turkish türkisch
zho chi zh Chinese chinesisch
... ... ... ... ...


Tabelle 0171: Staatsangehörigkeit

In der Tabelle 0171 stehen folgende Werte aus der ISO-Tabelle 3166 zur Verfügung. Weitere sind zulässig, sofern diese vorher vereinbart wurden. Die ISO Tabelle stellt sowohl zwei- als auch dreistellige Codes zur Verfügung. In den Nachrichten sind die dreistelligen Codes zu verwenden:

Land Country 2stellig 3stellig Nummer
Österreich AUSTRIA AT AUT 040
Belgien BELGIUM BE BEL 056
Dänemark DENMARK DK DNK 208
Frankreich FRANCE FR FRA 250
Deutschland GERMANY DE DEU 276
Luxemburg LUXEMBOURG LU LUX 442
Holland NETHERLANDS NL NLD 528
Schweden SWEDEN SE SWE 752
Schweiz SWITZERLAND CH CHE 756
Türkei TURKEY TR TUR 792
England UNITED KINGDOM GB GBR 826
Vereinigte Staaten von Amerika UNITED STATES US USA 840
... ...



Anhang

Referenzen

  • HL7 Version 2.5, [4] und [5]
  • IHE: Laboratory Technical Framework, [www.himss.org-http://www.himss.org/], und Radiology Technical Framework, [6]
  • OID: Objekt-Identifikation beim DIMDI:

[7]

  • ISO-Tabelle 639:

http://www.rtt.org/ISO/TC37/SC2/WG1/639/ISO639-identifiers.html und http://www.loc.gov/standards/iso639-2/englangn.html\#two

Detaillierte Änderungshistorie

Version Änderungen gegenüber Vorversion
2.0 Reconciliation
1.9 2.3: Konformanzprofile

neuer Absatz 5 über OIDs Nutzung von OIDs

1.1 5: Formulierung verbessert

7.2: Formulierung verbessert

1.0 Erstellung
Abgerufen von „https://wiki.hl7.de/index.php?title=HL7v2-Profile_Rahmen&oldid=23461“