deutsche Nachrichtenprofile: Rahmen-Dokument

Aus Hl7wiki
Nachrichtenprofile
Wechseln zu: Navigation, Suche


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
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