deutsche Nachrichtenprofile

{{{Title}}}

deutsche Nachrichtenprofile

Nachrichtenprofile

vorgelegt von:
HL7-Deutschland

ballotiert

Version:	01
Datum:	20. Dezember 2013
Status:	Entwurf
Verfahren:	{{{Verfahren}}}
Realm:	Deutschland

Copyright © 2013: HL7 Deutschland

Abstimmungsdokument
Version	Datum	Status	Realm
01	15.08.2013	ballotiert	Deutschland
		noch kein download verfügbar

Kontributoren
	Agfa HealthCare GmbH	Bonn
|100px]]	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

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, Nutzungs¬hinweise

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.

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

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

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

3. Dokumentenstruktur

Die Struktur der Dokumente ist in einem separaten Dokument beschrieben.

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

5. Kodierrichtlinien

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

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

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

Ver¬wen¬dung	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.

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

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

10. 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. Dies ist eine Vereinfachung der allgemeinen Verarbeitungslogik, da normalerweise eine Verarbeitung der Elemente auch für vorhergehende HL7-Definitionen gefordert wird.

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

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

12. 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
	es gibt für diese (Sub-)Komponente Daten
	Ja		Nein
die (Sub-)Kom-	die (Sub-)Kom-	vorhandene Daten sollen gelöscht werden
ponente nicht	ponente mit	Ja	Nein
füllen	Daten füllen	die (Sub-)Komponente mit ("") füllen	die (Sub-)Komponente leer lassen

13. Parsingregeln für das empfangende System

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

die (Sub-)Komponente wird unterstützt
Nein		Ja
fertig	die (Sub-)Komponente ist vorhanden (	)
	Nein		Ja
	fertig	die (Sub-)Komponente ist Null ("")
		Ja		Nein
		die (Sub-)Komponente ist die einzig erforderliche	füllen der
		Ja	Nein	Datenbank
		löschen aller	alle erforderlichen (Sub-)Komponenten sind null	mit den Daten der
		(Sub-) Kom-	Ja	Nein	(Sub)- Kom-
		ponenten	löschen aller (Sub-) Komponenten	füllend der Datenbank mit den Daten der (Sub-) Komponente	ponente

14. Fortsetzung von Nachrichten

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

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

16. "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.

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

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

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

19. 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ß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.

20. HLLP

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

21. 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 Dateien führt zu Zeitverzögerungen (Pollingverfahren) und birgt Restrisiken wie bspw. Verwaltung der Zugriffsrechte.

22. Nachrichtenverteilung

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

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

24. 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:

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

25. 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. Die Verwaltung der OIDs für das deutsche Gesundheitswesen findet beim DIMDI statt. Dort gibt es auch nähere Informationen zu diesem Thema: [3]

26. 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 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!

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

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

28. Zeichensätze

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

29. 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 { | } ~ 

30. ISO 8859/1 alias ISO Latin 1

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

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

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

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

33. Tabellen

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

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

36. Anhang

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

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