deutsche Nachrichtenprofile
Fzain (Diskussion | Beiträge) (→Null-Werte vs. nicht vorhanden) |
Fzain (Diskussion | Beiträge) |
||
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 }} |
Version vom 15. Januar 2014, 10:00 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 Fzain (talk| contribs) 10 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 Fzain (talk| contribs) 10 years ago. (Purge) |
![]() |
Dieses Dokument gibt wieder:
Nachrichtenprofile deutsche Nachrichtenprofile (01). Die Teilmaterialien gehören der Kategorie v2profile an. |
HL7-Deutschland
Abstimmungsdokument | |||
---|---|---|---|
Version | Datum | Status | Realm |
01 | 15.08.2013 | ballotiert | ![]() |
![]() |
noch kein download verfügbar |
Kontributoren | ||
---|---|---|
![]() |
Agfa HealthCare GmbH | Bonn |
[[Datei:logo_cortex.gif|100px]] | Cortex Software GmbH | |
![]() |
InterComponentWare | Walldorf |
![]() |
SAP | Walldorf |
![]() |
SER HealthCare Solutions GmbH | |
![]() |
Zentrum für Telematik im Gesundheitswesen GmbH | Bochum |
![]() |
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, Nutzungs¬hinweise
- 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, 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.
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.
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.
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 nach¬gelesen 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 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.
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.
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 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.
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 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 Datenbestände der beteiligten Systeme nicht in¬konsistent 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 | ||
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 |
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 |
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 Nach¬richten 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 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.
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.
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 ein¬gesetztes 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 Kommunikations¬server 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 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.
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.
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]
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.
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.
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 |