deutsche Nachrichtenprofile: Rahmen-Dokument
Foemig (Diskussion | Beiträge) |
Foemig (Diskussion | Beiträge) |
||
| (6 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, | + | =Autoren und Copyright-Hinweis, Nutzungshinweise= |
| + | |||
| + | {{BeginGreenBox|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= | ||
| + | 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. | |
| − | |||
| − | |||
| − | Diese Nachrichtenprofile dienen zur konformen Entwicklung von Interfaces zu in Deutschland | ||
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. | ||
| − | == | + | ==Dokumentenstruktur== |
Die Struktur der Dokumente ist in einem separaten Dokument beschrieben. | 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 | + | 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. | 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: | Diese Spezifikation nutzt die relativ neue Darstellung von Bedingungen. Hierbei wird unter „Verwendung" folgende Notation genutzt: | ||
| Zeile 156: | Zeile 156: | ||
Die Bedingung muss sich dabei an den Nachrichteninhalten ermitteln lassen. | 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 | + | 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" | ||
| − | ! | + | !Verwendung!!Escape-Sequenz!!Beispiel Escape-Symbol:!!‚a’'!!‚;’' |
|- | |- | ||
|R||\F\||field separator||aFa||;F; | |R||\F\||field separator||aFa||;F; | ||
| Zeile 185: | Zeile 185: | ||
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. | 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 | + | 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 | + | 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. | In Datenfeldern vom Typ 'TX' können evtl. Zeilenumbrüche über eine Wiederholung realisiert werden, welches für jedes Datenfeld individuell festgelegt ist. | ||
| Zeile 219: | Zeile 219: | ||
| − | == | + | ==Versionsabhängigkeiten== |
| − | Bedingt durch Inkompatibilitäten zwischen den unterschiedlichen HL7-Versionen | + | 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== |
| − | 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 | + | 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 | + | 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 | + | 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: | Das sendende System hat die Felder gemäß folgendem Regelwerk mit Daten zu füllen: | ||
{| 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||| | + | |'''Nein'''|| colspan="3"|'''Ja''' |
|- | |- | ||
| − | |||es | + | |rowspan"3"|die (Sub-)Komponente nicht füllen || colspan="3"| Gibt es für diese (Sub-)Komponente Daten? |
|- | |- | ||
| − | |||Ja|| | + | |||Ja|| colspan="2" |Nein |
|- | |- | ||
| − | | | + | | ||die (Sub-)Komponente mit Daten füllen || colspan="2" | 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 | + | Das empfangende System hat nach folgendem Regelwerk vorzugehen, um die Daten aus der Nachricht zu extrahieren. |
{| class="hl7table" | {| class="hl7table" | ||
| − | !die (Sub-)Komponente | + | !colspan="6"| Wird die (Sub-)Komponente unterstützt? |
|- | |- | ||
| − | |Nein|| | | + | |'''Nein'''|| colspan="5" |'''Ja''' |
|- | |- | ||
| − | |fertig||die (Sub-)Komponente | + | |fertig|| colspan="5" | Ist die (Sub-)Komponente vorhanden ( | | ) |
|- | |- | ||
| − | |||Nein|| | | + | | ||'''Nein'''|| colspan="4" |'''Ja''' |
|- | |- | ||
| − | |||fertig||die (Sub-)Komponente | + | | ||fertig||colspan="4" |Ist die (Sub-)Komponente Null ("")? |
|- | |- | ||
| − | |||||Ja | + | | || ||colspan="3"|Ja|| Nein |
|- | |- | ||
| − | |||||die (Sub-)Komponente | + | | || ||colspan="3"| Ist die (Sub-)Komponente die einzig erforderliche? || füllen der Datenbank mit den Daten der (Sub)-Komponente |
|- | |- | ||
| − | |||||Ja||Nein|| | + | | || ||Ja|| colspan="2"|Nein|| |
|- | |- | ||
| − | |||||löschen aller||alle erforderlichen (Sub-)Komponenten | + | | || ||löschen aller (Sub-) Komponenten|| colspan="2"| 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. | 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 | + | 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. | 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. | 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. | 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 | + | 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 302: | Zeile 301: | ||
Zur Erhöhung der Qualität der Systemintegration wird die Transportinfrastruktur als Bestandteil des Basis-Profils definiert. | 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. | HL7-konforme Implementierungen sollen das Minimal Lower Layer Protocol (MLLP) auf Basis von TCP/IP unterstützen. | ||
| Zeile 320: | Zeile 319: | ||
darstellen. | darstellen. | ||
| − | Die HL7-Nachricht wird durch die Start- bzw. Endesequenz eingerahmt. Es ist nicht zulässig, | + | 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. | 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 | + | 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== |
| − | Die Verteilung der Nachrichten gestaltet sich unterschiedlich, je nachdem, ob ein | + | 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 | + | 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 342: | Zeile 341: | ||
Es wird empfohlen, dass die sendenden Anwendungen ausgehende Nachrichten zwischenspeichern können, falls das annehmende System gerade nicht verfügbar ist. | 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 | + | 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 353: | Zeile 352: | ||
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. | 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 | + | 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] | ||
| − | == | + | ==Einsatz von OIDs bei Nachrichtenprofilen== |
Die Nachrichtenprofile machen an drei Stellen gebrauch von OIDs: | Die Nachrichtenprofile machen an drei Stellen gebrauch von OIDs: | ||
a) Identifikation der Spezifikation (Dokumenten-OIDs) | a) Identifikation der Spezifikation (Dokumenten-OIDs) | ||
| 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 | + | 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. | ||
| − | = | + | =Interaktionsdiagramm= |
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 | + | 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: | 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: | 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: | ||
| Zeile 391: | Zeile 390: | ||
| − | == | + | ==ISO 8859/1 alias ISO Latin 1== |
Dieser Zeichensatz für Westeuropa belegt auf den Positionen 160 bis 255 folgende Zeichen: | Dieser Zeichensatz für Westeuropa belegt auf den Positionen 160 bis 255 folgende Zeichen: | ||
| Zeile 402: | Zeile 401: | ||
| − | == | + | ==ISO 8859/15 alias ISO Latin 9== |
Der Zeichensatz 8859/15 unterscheidet sich von 8859/1 nur an einigen Stellen: | Der Zeichensatz 8859/15 unterscheidet sich von 8859/1 nur an einigen Stellen: | ||
{| 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 | |
|- | |- | ||
|164||244||A4||¤||U+00A4||currency symbol||€||U+20AC||euro sign | |164||244||A4||¤||U+00A4||currency symbol||€||U+20AC||euro sign | ||
| Zeile 430: | Zeile 429: | ||
| − | == | + | ==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. | 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. | 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: | 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: | ||
{| class="hl7table" | {| class="hl7table" | ||
| − | + | !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: | 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: | ||
| Zeile 532: | Zeile 531: | ||
| − | = | + | =Anhang= |
| − | == | + | ==Referenzen== |
* HL7 Version 2.5, [http://www.hl7.org-http://www.hl7.org/] und [http://www.hl7.de-http://www.hl7.de/] | * HL7 Version 2.5, [http://www.hl7.org-http://www.hl7.org/] und [http://www.hl7.de-http://www.hl7.de/] | ||
* IHE: Laboratory Technical Framework, [www.himss.org-http://www.himss.org/], und Radiology Technical Framework, [http://www.rsna.org-http://www.rsna.org/] | * IHE: Laboratory Technical Framework, [www.himss.org-http://www.himss.org/], und Radiology Technical Framework, [http://www.rsna.org-http://www.rsna.org/] | ||
| Zeile 542: | Zeile 541: | ||
http://www.rtt.org/ISO/TC37/SC2/WG1/639/ISO639-identifiers.html und http://www.loc.gov/standards/iso639-2/englangn.html\#two | 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== |
{| class="hl7table" | {| class="hl7table" | ||
Aktuelle Version vom 2. Juni 2015, 10:35 Uhr
 |
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) |
 |
Dieses Dokument gibt wieder:
Nachrichtenprofile deutsche Nachrichtenprofile: Rahmen-Dokument (01). Die Teilmaterialien gehören der Kategorie v2profile an. |
HL7-Deutschland
| Version: | 01 |
| Datum: | 20. Dezember 2013 |
| Status: |  Entwurf
|
| Verfahren: | {{{Verfahren}}} |
| Realm: |  Deutschland
|
| Abstimmungsdokument | |||
|---|---|---|---|
| Version | Datum | Status | Realm |
| 01 | 15.08.2013 | ballotiert | Deutschland
|
 |
noch kein download verfügbar | ||
| Kontributoren | ||
|---|---|---|
|
Agfa HealthCare GmbH | Bonn |
| Cortex Software GmbH | ||
 |100px]]
|
InterComponentWare | Walldorf |
 |100px]]
|
SAP | Walldorf |
 |100px]]
|
SER HealthCare Solutions GmbH | |
 |100px]]
|
Zentrum für Telematik im Gesundheitswesen GmbH | Bochum |
 |100px]]
|
Optimal Systems GmbH | Berlin |
 |
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
Inhaltsverzeichnis
- 1 Dokumentinformation
- 2 Autoren und Copyright-Hinweis, Nutzungshinweise
- 3 Einleitung
- 4 Kodierrichtlinien
- 4.1 Konditionale Elemente
- 4.2 Escape-Sequenzen
- 4.3 Carriage-Return
- 4.4 Textformatierung
- 4.5 Versionsabhängigkeiten
- 4.6 Null-Werte vs. nicht vorhanden
- 4.7 Konstruktionsregeln für das sendende System
- 4.8 Parsingregeln für das empfangende System
- 4.9 Fortsetzung von Nachrichten
- 4.10 Batch-Protokoll
- 4.11 "Multi-Patient"-Messages
- 4.12 Tabellenwerte
- 5 Transport
- 6 OIDs
- 7 Interaktionsdiagramm
- 8 Zeichensätze
- 9 Tabellen
- 10 Anhang
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
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.
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:
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:
- 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 |
