Häufig gestellte Fragen, Tipps und Tricks zum Thema OIDs

Einleitung

Die nachfolgenden Informationen dienen als Ergänzung der "FAQs zum Thema OID des DIMDI".

Die ersten beiden Teile der FAQs enthalten allgemeine Information zum Thema OID, mit Schwerpunkt auf Begriffsdefinitionen und Verwendung von ISO OID unter HL7 Version 3.

Der dritte Teil gibt eine Hilfestellung für OID-Vergabestellen im Gesundheitswesen, wie z.B. für Krankenhäuser oder medizinische Versorgungszentren, bei der Erstellung eigener OID-Konzepte. Besondere Aufmerksamkeit wird der Vergabe von Instanzenidentifikatoren gewidmet.

Grundlegendes über OIDs

Frage 1. Was ist eine OID?

Das Kürzel „OID“ steht für „Object Identifier“ und bezeichnet einen Identifikator für ein Objekt. Die ISO hat zur Vergabe und Verwaltung dieser weltweit eindeutigen und dauerhaften Identifikatoren ein Verfahren standardisiert. Ein konkreter Identifikator, der durch ein solches Verfahren entstanden ist, wird ebenfalls als „OID“ (Mehrzahl: „OIDs“) bezeichnet. Die Regeln für die Vergabe und Registrierung von OIDs sind in den Normen ISO/IEC 9834 und DIN 66334 festgelegt.

Frage 2. Was kann man alles mit einer ISO OID versehen?

Im Sinne der Norm ASN.1 ist ein Objekt “a well-defined piece of information, definition or specification which requires a name in order to identify its use in an instance of communication”. Da eine OID ein eindeutiger Identifikator ist, kann somit theoretisch alles, was in der Informationstechnik modelliert wird, mit einer OID verknüpft werden. Bei der Vergabe muss jedoch berücksichtigt werden, dass eine OID einem Objekt dauerhaft zugeordnet wird. Bei den Objekten, denen eine OID zugewiesen wird, kann es sich sowohl

• um konkrete Objekte wie einzelne Personen oder Gruppen von Personen als auch
• um abstrakte Objekte wie Kategorien, Klassen, Konzepte oder Typen handeln.

Eine OID kann entweder einem einzelnen Objekt zugeordnet werden, oder einer ganzen Gruppe von Objekten. Wird nur die Gruppe von Objekten eindeutig über eine OID identifiziert, werden die einzelnen Objekte innerhalb der Gruppe über einen anderen Identifizierungsmechanismus unterschieden. Nehmen wir das Beispiel des Diagnosenkatalogs: Der Diagnosenkatalog „ICD10 German Modification 2006“ wird über die OID "1.2.276.0.76.5.311" eindeutig identifiziert, nicht die einzelnen Diagnosen in diesem Katalog. Die Diagnose "Akute rheumatische Perikarditis" wird wiederum über die OID des Diagnosenkatalog „ICD10 German Modification 2006“ zusammen mit dem Code „I01.0“ global eindeutig identifiziert. In der XML-Notation von HL7 Version 3 wird die Diagnose wie folgt dargestellt:

<....
  codeSystem="1.2.276.0.76.5.311" 
  codeSystemName="icd10gm2006" 
  code="I01.0" 
  displayName="Akute rheumatische Perikarditis" />

Frage 3. Was ist ein OID-Baum?

ISO OIDs sind in einer hierarchischen Baumstruktur angeordnet. Diese Struktur wird von einem Netzwerk aus Vergabeorganisationen verwaltet. Wird eine Organisation für einen bestimmten Knoten des Baums zuständig, so ist sie anfangs auch für alle seine Unterknoten zuständig. Die Vergabeorganisation darf dann einen Knoten aus ihrem Zuständigkeitsbereich entweder mit einem Objekt verknüpfen (Definition der Bedeutung) oder aber in die Obhut einer anderen Vergabeorganisation übergeben (Delegation). Für die Wurzel der gesamten Baumstruktur („abstract root“) und die ersten zwei Ebenen gelten besondere Regeln. Knoten, welche keine Unterknoten besitzen, werden als Blattknoten („leaf node“) bezeichnet. Einen Ausschnitt des globalen OID-Baums zeigt die nachstehende Abbildung.

Frage 4. Wie sieht eine ISO OID aus?

Die häufigste Schreibweise für eine ISO OID ist die sog. „Zahlen-Punkt-Notation“ („dot notation“) nach IETF RFC 1778. In dieser Repräsentation wird die OID als eine Folge von positiven Dezimalganzzahlen ohne führende Nullen dargestellt. Die Zahlen sind durch Punkte getrennt. So ist beispielweise „1.2.276.0.76“ eine syntaktisch zulässige ISO OID, „1.02.3X“ jedoch nicht. Die Zahlenfolge, von links nach rechts gelesen, entspricht dem Pfad im OID-Baum, mit der Root an der ersten Stelle. So wird z. B. die OID des DIMDI {iso(1) member-body(2) de(276) din-certco(0) gesundheitswesen(76)} in der Zahlen-Punkt-Notation durch „1.2.276.0.76“ dargestellt.

Frage 5.Was unterscheidet die ISO OID von anderen globalen Identifikatoren aus?

• Die ISO OID ist unabhängig von technischen „low-level“ Informationen, wie die Adresse der Netzwerkkarte (MAC-Adresse), Systemuhren oder Generatoren von Pseudozufallszahlen.
• Bei korrekter Anwendung ist die Wahrscheinlichkeit, eine ID zweimal zu generieren nicht nur „vernachlässigbar klein“, sondern gleich Null.
• In ihrem Zuständigkeitsbereich hat die Vergabeorganisation die Kontrolle über die Identifikatoren und damit die Möglichkeit, sie gemäß einer eigenen Semantik aufzubauen.
• Die Herkunft einer OID kann verfolgt werden, ohne dass die OID selbst datenschutzrelevante Information preisgibt.
• Durch die Registrierung von OIDs besteht die Möglichkeit, zu den vergebenen OIDs Metadaten zu erfassen und in OID-Registern zu veröffentlichen.

Die letzten beiden Eigenschaften helfen, Redundanzen in der OID-Vergabe zu vermeiden, d. h. sicherzustellen, dass jedes Objekt einen global eindeutigen Identifikator erhält. Sie stellen den wesentlichen Mehrwert der Verwendung von ISO OID dar.

Frage 6. Repräsentiert die OID eine Klassifikation?

Im Allgemeinen repräsentiert der OID-Baum keine Klassifikation im Sinne einer Terminologie. Einzelne Knoten können mit solchen Objekten verknüpft sein (z. B. steht 1.2.276.0.76.5.311 für die Klassifikation von Diagnosen im deutschen Gesundheitswesen), aber die OID-Hierarchie an sich besitzt keinerlei Semantik. Zur Erleichterung der OID-Verwaltung darf eine Vergabeorganisation für ihren Teil des OID-Baums eine (Semantik-basierte) Vergabekonvention festlegen. Diese ist jedoch ausschließlich intern und besitzt außerhalb der Vergabeorganisation keinerlei normative Verbindlichkeit.

Frage 7. Dürfen bei maschineller Verarbeitung Teile einer OID interpretiert werden, um daraus auf die Bedeutung der OID zu schließen?

Bei dieser Frage ist vorab zu klären,

• in welchem Anwendungsfall die OID verwendet wird und
• ob es sich um eine OID aus dem eigenen Zuständigkeitsbereich handelt.

Die nachstehende Tabelle führt die vier möglichen Kombinationen auf.

Anwendungsfall/ Ursprung der OID	OID aus fremdem Zuständigkeitsbereich	OID aus eigenem Zuständigkeitsbereich
Vergabe und Verwaltung einer OID	<kommt nicht vor>	Semantische Interpretation notwendig. Die verwaltende Anwendung (z. B. eine OID-Registry) muss die OID interpretieren, um die OIDs zu administrieren.
Verwendung einer freigegebenen OID	Semantische Interpretation nicht zulässig. Siehe auch HL7 Version 3, Data Types - Abstract Specification, 2.14.1.	Semantische Interpretation nicht zulässig. „Eigene“ OIDs sind auf die gleiche Weise zu nutzen wie „fremde“ OIDs.

Frage 8. Wo kommt ISO OID auf dem Gebiet der Healthcare-IT zum Einsatz?

In der Healthcare-IT wird ISO OID in den Standards HL7 2.x und in HL7 Version 3, inkl. CDA verwendet. Auf diese Kommunikationsstandards wird in mehreren Domains und mehreren Profilen der Interoperabilitätsinitiative IHE (Integrating Healthcare Enterprise) referenziert. Während in HL7 2.x eine OID nur als Kennzeichner eines Namensraumes (Assigning Authority) eingesetzt wird, ist die Verwendung unter HL7 Version 3 umfassender und wird dort zum Beispiel auch zur Identifikation von „internen“ Objekten des Standards genutzt.

Der DICOM-Standard zur Bildübertragung und -speicherung verwendet sog. UIDs (Unique Identifier), um Objekte eindeutig zu identifizieren. Eine UID enthält typischerweise eine OID als festes Präfix und ein „variables“ Suffix.

ISO OID und HL7 Version 3

Frage 9. Welche Rolle spielt ISO OID im Standard HL7 Version 3?

ISO OID ist in HL7 Version 3 als Basis-Datentyp „OID“ definiert und wird verwendet, um Instanzen über den Datentyp II (Instance Identifier) und Konzepte über den Datentyp CD (Concept Descriptor) zu identifizieren.

Für die Identifikation von Konzepten werden in HL7 Version 3 mehrere vom Datentyp CD abgeleitete Spezialisierungen definiert: CV (Coded Value), CWE (Coded With Exceptions) und CNE (Coded With No Exceptions).

Diese HL7 Version 3 Datentypen werden ebenfalls im Clinical Document Architecture Release 2 (CDA R2) verwendet und somit in CDA- und CCD-Dokumenten genutzt.

Frage 10. Was ist ein Instanzenidentifikator?

Ein Instanzenidentifikator bezeichnet eine konkrete Objektinstanz, wie eine Person, ein IT-System oder eine Organisation. In HL7 Version 3 besteht ein Instanzenidenfikator aus einer Root und einer optionalen Extension. Er wird auf eine der folgenden Weisen gebildet:

• Wird ein Instanzenidenfikator eindeutig durch eine OID definiert, so wird diese OID als Root angegeben. Ist in diesem Fall gibt es keine Extension. Beispiel für ein IT-System: <id root="2.16.840.1.113883.3.37.4.1.1.2.0"/>.
• Wird ein Instanzenidentifikator eindeutig durch die Kombination einer OID und einer Zusatzinformation definiert, so wird die OID als Root angegeben und die Zusatzinformation als Extension. Beispiel: Patientennummer <id root="1.3.6.1.4.1.21367.2005.1.1" extension="PDQ113XX05" />.

Frage 11. Was ist der Unterschied zwischen einem Konzept und einem Code?

Konzepte bezeichnen abstrakte Konstrukte wie Klassen, Zustände, Begriffe und Normen. Konzepte werden durch Codes abgebildet und identifiziert. Idealerweise wird ein Konzept nur durch einen Code abgebildet. In der Praxis wird jedoch ein und dasselbe Konzept durch Codes in verschiedenen Codesystemen definiert. So wird beispielsweise das Konzept „Weibliches Geschlecht“ in den Codesystem HL7 2.x, HL7 Version 3 und SNOMED CT durch die folgenden Codes definiert.

• HL7 2.x:

codeSystem="2.16.840.1.113883.12.1" 
codeSystemName="AdministrativeSex" 
code="F"

• HL7 Version 3:

codeSystem="1.2.276.0.76.5.1" 
codeSystemName="AdministrativeGenderCode" 
code="F"

• SNOMED CT:

codeSystem="2.16.840.1.113883.19.6.96" 
codeSystemName="SNOMED CT" 
code="248152002"

Damit ist der Code nur in Kombination mit der OID seines Codesystems eindeutig.

Frage 12. Wie entscheidet man bei einem Objekt, ob es als Instanz oder als Code abzubilden ist?

In den Domainmodellen innerhalb von HL7 Version 3 wurde die entsprechende Designentscheidung bereits getroffen. So wird der Benutzer des Standards mit der oben gestellten Frage nur bei der Erstellung völlig neuer Domainmodelle konfrontiert.

Objekte, die öffentlich bekannt, in ihrer Zahl begrenzt und von ihrer Lebensdauer langlebig bis dauerhaft sind, können grundsätzlich sowohl auf Instanzen als auch auf Konzepte abgebildet werden, z. B. Länder oder globale Organisationen.

So definiert z. B. das Dokument „Festlegung von OIDs“ der Gematik Berufsgruppen im Sinne von Kategorien als einzelne OIDs. Dagegen vergibt das „OID-Konzept“ von eFA OIDs für Code-Systeme und listet die zulässigen Werte einzelner Code-Systeme auf, z. B. für Therapie. Die Vertauschbarkeit beider Herangehensweisen zeigt sich auch in HL7 Version 3 selbst. HL7 3.0 weist historisch bedingte Unregelmäßigkeit bei „internen“ Artefakten wie interactionId oder templateId auf - sie entsprechen zwar semantisch einer Klasse, sind dennoch als Instanzen abgebildet.

Der formale Unterschied zwischen Code und Instanz zeigt sich bei der Veröffentlichung der betroffenen OID: Um einen Instanzenidentifikator bekannt zu machen, ist lediglich die entsprechende OID in eine öffentliche OID-Registry einzustellen. Um dagegen einen Code bekannt zu machen, muss man zum einen die OID des Codesystems in einer OID-Registry veröffentlichen, zum anderen den Code selbst einer Liste (Katalog) hinzufügen und den aktualisierten Katalog publizieren.

Frage 13. Wann muss für ein Kodiersystem eine neue ISO OID vergeben werden?

Eine ISO OID verfügt über keinen Versionierungsmechanismus. Wenn sich ein Codesystem ändert, ist zu prüfen, ob dieses Codesystem immer noch dasselbe Konzept darstellt. Ändert sich die Semantik oder handelt es sich um eine nicht „abwärts kompatible“ Änderungen (s. Tabelle), ist für das geänderte Codesystem eine neue OID zu vergeben. Ein Beispiel dafür ist die jährliche Überarbeitung der deutschen Diagnosenklassifikation. Da es möglich ist, Codes aus diesem Katalog zu löschen, wird vom DIMDI für den überarbeiteten Katalog jedes Jahr eine neue OID vergeben.

Art der Änderung	Neue OID für das Kodiersystem erforderlich?
Codes hinzufügen*	Nein
Redaktionelle Änderung in der Beschreibung von Codes	Nein
Codes als „veraltet“ markieren	Nein
Codes entfernen	Ja
Geänderte Semantik eines Codes	Ja

* Ausnahme: Einige Codesysteme enthalten einen Wert mit der Bedeutung „Sonstiges“, der alle anderen Werten des Codesystems komplementär ergänzt. Die Bedeutung dieses Codes wird durch das Hinzufügen eines neuen Wertes eingeschränkt, was dem Fall „Geänderte Semantik eines Codes“ gleich kommt und somit eine neue OID erfordert.

Identifikatoren mit ISO OID entwerfen und verwalten

Frage 14. Was ist ein OID-basierter Identifikator?

Ein OID-basierter Identifikator ist ein global eindeutiger Identifikator, welcher aus einer ISO OID und einer Zusatzinformation besteht.

In HL7 Version 3 erfolgt eine Differenzierung, ob es sich um die Identifikation eines Konzeptes oder einer Instanz handelt. Der Datentyp CD (Concept Descriptor) und davon abgeleitete Datentypen dienen zur Identifikation eines Konzeptes, der Datentyp II (Instance Identifier) zur Identifikation einer Instanz.

Werden diese Datentypen verwendet, werden sie wie folgt belegt:

• Datentyp „Concept Descriptor“:

codeSystem: OID,
code: Zusatzinformation

• Datentyp „Instance Identifier“:

root: OID, 
extension: optionale Zusatzinformation 

Je nach Kontext kann sich Wortverbindung „OID-basierter Identifikator“ entweder auf das identifikatorbildende Verfahren oder auf eine konkrete Identifikatorinstanz beziehen. Zur Betonung der ersten Bedeutung können auch Begriffe „OID-basiertes Identifikationsschema“ (für Instanzenidentifikatoren) oder „OID-basiertes Kodierschema“ (für Codes) genutzt werden.

Frage 15. Was ist ein OID-Konzept?

Bei Verwendung von OID-basierten Identifikatoren im Rahmen eines IT-Projekts sind die OIDs und deren Verwendung in einem selbständigen Dokument zu dokumentieren. Bekannte Bezeichnungen für diese Dokumentation sind z. B. „OID-Konzept“, „Festlegung von OIDs“, „Hinweise zur Vergabe von Object Identifiern“.

Ein OID-Konzept enthält die folgende Information:

• eine Übersicht der Objekte relevant sind und ihre Eigenschaften – sowohl Klassen als auch Instanzen (Patienten, Organisationseinheiten, Dokumente...)
• eine Beschreibung der Objekte: Eigenschaften, Einschränkungen, Fachlogik
• Informationen, nach welcher Systematik diesen Objekten eine OID zugewiesen wurde oder wird
• Informationen, ob und wie die OIDs mit einer Zusatzinformation kombiniert werden. Zusätzlich können weitere Details wie z. B. der zulässige Wertebereich für codierte Attribute dokumentiert werden.

In seiner Gesamtheit dokumentiert das OID-Konzept ein System von aufeinander abgestimmten OID-basierten Identifikations- und Kodierschemata innerhalb einer Domain dar. Der Begriff „OID-Konzept“ darf nicht mit einem Terminologiekonzept verwechselt werden.

Frage 16. Inwiefern lässt sich ein OID-Konzept wiederverwenden? Braucht man innerhalb einer Organisation für jedes neue IT-Projekt ein neues OID-Konzept?

Es liegt im Interesse der Vergabeorganisation, den Aufwand zur Erstellung eines OID-Konzepts zu minimieren. Daher wird empfohlen, die Identifikations- und Kodierschemata bereits beim ersten Projekt so neutral zu konzipieren, dass sie in späteren Projekten wiederverwendet werden können. Dies kann sich durch künftige Anforderungen ändern, die bei der erstmaligen Erstellung des OID-Konzepts unbekannt sind.

Bleiben die betroffenen Objekte über die Zeit stabil, besteht die Möglichkeit, dass auch die entsprechenden Identifikations- bzw. Kodierschemata unverändert bleiben können. Ein Beispiel dafür ist die Organisationsstruktur oder Räume eines Krankenhauses. Die Gültigkeit des bestehenden OID-Konzepts ist jedoch bei jedem neuen Projekt gegen die aktuellen Anforderungen des Projektes erneut zu prüfen (siehe Frage 18). Der Einsatz bewährter Praktiken erleichtert die Wartung und Erweiterung von OID-Konzepten (siehe Frage 17).

Frage 17. Welche Praktiken helfen beim Erstellen eines OID-Konzepts?

Die folgende Tabelle fasst die Ansätze zusammen, die sich beim Entwurf eines OID-Konzepts für ein Krankenhauses oder ein medizinischen Versorgungszentrum bewährt haben. Weitere FAQs gehen auf die Details der aufgelisteten Practices näher ein.

Practice	Siehe Frage(n)
Relevanten technischen Anwendungskontext eingrenzen: HL7 2.x, HL7 3.0, DICOM, etc. Eine widerspruchlose Menge von Constraints auswählen, die als Vorgabe fürs entstehende OID-Konzept dienen.	19
Interne Konventionen einführen und konsequent einhalten – z. B. einheitliche Namensräume für Klassen	6, 7
Kein OID-Knoten darf gleichzeitig OID-Unterknoten besitzen und als Wurzel für Suffixe bzw. als Identifikation von Codesystemen verwendet werden.	20
Trennung von Zuständigkeiten bei der OID-Vergabe im voraus einplanen; bei Bedarf Knoten einbauen, die der Delegation dienen sollen	21
Anhand der Dauerhaftigkeit der Objekte die Identifikator-Information zwischen die root und extension verteilen - eventuell die Variante ohne extension verwenden.	22, 23
Leere Ebenen und Nummerierungslücken als Mittel für spätere Erweiterungen gezielt einsetzen	-
Für die Versionsnummer eines OID-Systems eine Hierarchieebene einziehen.	-
Zweckgerecht Dokumentieren.	24

Frage 18. Wie sind im Kontext eines OID-basierten Identifikators die Begriffe „root“ und „Wurzel“ zu verstehen?

Die Wörter „Wurzel“, und „root“ sind im Kontext der OID-Vergabe im Gesundheitswesen mehrfach belegt und erfordern somit im Sprachgebrauch eine genauere Differenzierung.

Das OID-Konzept für das deutsche Gesundheitswesen versteht unter „Wurzel“ den OID-Teil eines OID-basierten Identifikators - das entspricht in HL7 Version 3 dem „root“ bzw. dem „codesystem“. Den nicht ISO-konformen Teil („Zusatzinformation“), bezeichnet das genannte OID-Konzept dagegen als „Suffix“ – dies entspricht in HL7 Version 3 der „extension“ bzw. dem „code“. Somit ist der Begriff „Wurzel“ aus dem OID-Konzept, der auch Codesysteme einschließt, weiter gefasst als das Attribut „root“ für Instanzenidentifikatoren, Zum besseren Verständnis sind die Begriffe in der nachstehenden Tabelle zusammengefasst.

OID-basierter Identifikator	OID-Konzept für das deutsche Gesundheitswesen	HL7v3
OID	Wurzel	Datentyp II: root Datentyp CD und abgeleitet: codeSystem
Zusatzinformation	Suffix	Datentyp II: extension Datentyp CD und abgeleitet: code

Wenn ein OID-Knoten als Namensraum für „Suffixe“ (also „code“ oder „extensions“) dient, sind unter diesem OID-Knoten keine weiteren Unterknoten im OID-Baum erlaubt. Somit ist die Wurzel von Suffixen immer automatisch ein Blatt der OID-Baumhierarchie. Die Begriffe „Wurzel“ und „Blatt“ beziehen sich hier auf zwei unterschiedliche Hierarchien und stehen deshalb nicht im gegenseitigen Widerspruch.

Um Missverständnisse zu meiden, ist im Sprachgebrauch die Ersetzung der Begriffe „Wurzel“ und „Suffix“ durch andere Synonyme empfehlenswert, für “Wurzel“ beispielsweise „OID“, „Root“, „Codesystem“, für das “Suffix“ „Zusatzinformation“, „Extension“ oder „Code“.

Frage 19. Was ist beim Verfassen eines OID-Konzepts zu beachten?

Um OID-basierte Identifikatoren zwischen verschiedenen Systemen auszutauschen, muss die Nutzung dieser Identifikatoren in einer Datennachricht gemäß deren technischen Spezifikation möglich sein. Da jede Spezifikation (HL7 Version 3, HL7 2.x, IHE-Profile, DICOM) spezifische Anforderungen hat, ist bereits beim Entwurf des OID-Konzepts zu bedenken, in welchem technologischen Kontext die gebildeten Identifikatoren zum Einsatz kommen werden.

Zeichenketten der Identifikatoren müssen diversen Vorgaben bzgl. Länge und Zeichenzusammensetzung entsprechen. Der Verbindlichkeitsgrad dieser Einschränkungen (Constraints) reicht von normativen Pflichtvorgaben über Empfehlungen bis hin zu informellen „Best Practices“. Bekannte Einschränkungen sind in der folgenden Tabelle zusammengefasst.

Einschränkung	Kontext/Ursprung	Verbindlichkeitsgrad
Syntax: Die OID darf sich nur aus Ziffern und dem Punkt zusammensetzen. Zahlen enthalten keine führenden Nullen.	ISO 9834-1, RFC 3061	Pflicht
Länge der OID auf 64 Zeichen beschränkt	DICOM.OID länger als 64 Zeichen kann nicht als DICOM UID abgebildet werden.	Pflicht
Keine Leerzeichen in der Zusatzinformation verwenden.	HL7 V3, XML Implementation Technology Specification; Datentyp II; Attribut „extension“ ist als Typ „st“ definiert, was keine Whitespace-Zeichen zulässt.	Pflicht
Länge der OID auf 199 Zeichen beschränkt	HL7 2.5, IHE; Datentyp HD	Pflicht
Länge der Zusatzinformation auf 199 Zeichen beschränkt	HL7 2.5, IHE; Datentyp EI	Pflicht
Länge der Zusatzinformation auf 19 Zeichen beschränkt	HL7 2.5; nur wenn Namespace ID im Datentyp HD per „Site Agreement“ für die „Zusatzinformation“ verwendet wird (HL7 2.5, Section 2.A.33)	Pflicht – im Sonderfall
Länge der OID auf 64 Zeichen beschränkt	HL7 V3 (Data Types - Abstract Specification, 2.14.2)	Empfehlung
Zusatzinformation bei Instanzenidentifikatoren rein alphanumerisch	HL7v3; XML Implementation Technology Specification - Data Types, Fußnote 33	Empfehlung
Zusatzinformation bei Instanzenidentifikatoren ohne führende Nullen	HL7v3; XML Implementation Technology Specification - Data Types, Fußnote 33	Empfehlung
Keine Verwendung der Zusatzinformation bei Instanzenidentifikatoren	HL7 V3 (Data Types - Abstract Specification, 2.17.2)	Empfehlung
Keine Verwendung der Zeichen „|“, „^“, „\“, „&“ in der Zusatzinformation	HL7 2.x; um Aufwände und Probleme mit Umkodierung (Escaping/De-escaping) auszuschließen	„Best Practice“

Neben den Anforderungen der Standards sind auch die spezifischen Anforderungen der beteiligten Anwendungen zu berücksichtigen.

Frage 20. Unter welchen Voraussetzungen darf ein Knoten der OID-Hierarchie als Namensraum dienen?

Nur Blätter des OID-Baums dürfen als Namensraum für Extensions bzw. Codes dienen. Im Umkehrschluss: Ein OID-Knoten, der im OID-Baum einen oder mehrere Unterknoten besitzt, darf weder als „root“ für „extension“ noch als „codesystem“ für Codes verwendet werden. Siehe auch Frage 18.

Frage 21.Wie tief soll eine OID-Hierarchie sein?

Eine OID-Hierarchie kann von einer Vergabeorganisation in der Bandbreite von einer extrem flachen bis zu einer extrem tiefen Hierarchie aufgebaut werden. Vor- und Nachteile der einzelnen Varianten sind auf der Abbildung 1 zusammengefasst.

Es ist zu berücksichtigen, dass ein OID-Knoten nicht nur als Identifikator sondern auch als Verwaltungsschnittstelle dient. Wenn zum Zeitpunkt des Entwurfs eine spätere Weitergabe der Verwaltungszuständigkeit für einen Teilbaum des OID-Baumes feststeht oder nicht ausgeschlossen ist, sind für dafür entsprechende Knoten in der OID-Hierarchie vorzusehen.

Es ist nicht notwendig, alle OIDs für eine Vergabeorganisation unter einer einzigen Root zusammenzuführen. Es vereinfacht die Delegation jedoch erheblich, wenn die „delegierten“ Teile des OID-Baums von den „selbstverwalteten“ Teilen des OID-Baums klar getrennt sind.

„Semantik“ bezieht sich hier ausschließlich auf die Sicht des Administrators, der die OIDs verwaltet. Aus der Sicht des Nutzers einer bereits vergebenen OID sind alle drei Ansätze frei von Semantik (siehe Frage 7).

Frage 22. Wie soll bei Instanzenidentifikatoren die Information zwischen „root“ und „extension“ aufgeteilt sein?

Wie bereits beschrieben, kann ein Instanzenidentifikator durch die OID allein definiert werden oder durch die Kombination einer OID als Namensraum mit einer Extension. Wird der Instanzenidentifikator durch root und extension identifiziert, so ist es ausreichend, für alle Instanzen der entsprechenden Klasse eine Root zu definieren. Wird der Instanzenidentifikator eindeutig durch die OID ohne Extension definiert, so ist für jeden Instanzenidentifikator eine OID zu registrieren.

Wenn die Menge der zu identifizierenden Objekte nicht endlich definiert ist oder wenn diese einen kurzen Lebenszyklus haben, so ist für eine Gruppe von Objekten (Typ) eine OID zu definieren und für jedes Objekt eine Extension zu generieren (extension-orientiert). Ist die Anzahl der Objekte begrenzt oder haben diese einen langen Lebenszyklus, so ist für jedes Objekt eine eigene OID zu registrieren (root-orientiert).

Ein Instanzenidentifikator ohne Extension ist sinnvoll, wenn „root“ und „extension“ als verkettete Zeichenketten verwendet wird, weil sie z. B. als DICOM UIDs genutzt werden. Dagegen ist in anderen Fällen die Verwendung der Extension ausdrücklich zu empfehlen.

Root-orientierter Ansatz	Gemischter Ansatz	Extension-orientierter Ansatz
Vorteil: Verwaltungsrechte können granular vergeben werden	Vorteil: Der Ansatz bietet eine ausgewogene Baumstruktur im OID-Baum.	Vorteil: Übersichtlich, da nur wenige Knoten existieren. Auch für nicht numerische Daten geeignet.
Nachteil: Ansatz ist nur für numerische Datentypen geeignet. Für andere Datentypen ist ein Mapping erforderlich.	Nachteil: Es besteht die Notwendigkeit, rein strukturelle Knoten als „Container“ hinzuzufügen.	Nachteil: Durch die große Anzahl an Extensions erhöht sich der Verwaltungsaufwand in der Anwendung.

23. Wann wird die Nutzung von Extensions bei der Vergabe von Instanzenidentifikatoren empfohlen?

Unabhängig von den in Frage 18 diskutierten Richtlinien, kann es sinnvolle Szenarien geben, bei denen ein Objekt durch die Kombination von Root und Extension identifiziert wird. Im Unterschied zum Root-Teil kann die Extension auch andere Information als positive Ganzzahlen enthalten. Dies ist besonders in den folgenden Fällen von Nutzen:

1) Kompatibilität mit einem bisherigen Identifikationsschema erforderlich. Der OID-basierte Identifikator soll den Bezug zu einem bereits etablierten Identifikator aufrechterhalten. Z. B. wird die Krankenhausstation „Augenheilkunde 1“ als „AUGE1“ geführt und genau dieser Identifikator soll auch bei der Kommunikation über HL7 Version 3 erhalten bleiben. Als Lösung würde man den OID-basierten Identifikator wie folgt bilden: „root“ = OID mit der Bedeutung „Stationen des Krankenhauses“, „extension“=“AUGE1“.

2) Lesbarkeit für den menschlichen Benutzer gewünscht. Instance Identifier (II) unter HL7 Version 3 sind grundsätzlich für maschinelle Verarbeitung gedacht. Wenn ein Instanzenidentifikator auch manuell verarbeitet werden kann (z.B. diktiert, abgeschrieben), ist es vom Vorteil, die für den Menschen bestimmte Information getrennt zu repräsentieren. Eine Behandlungsfallnummer wäre z. B. in der Form <id root =“1.2.276.0.76.3.1.78.1.0.10.1.101.2“ extension=“12345678“> anstatt in der Form <id root =“1.2.276.0.76.3.1.78.1.0.10.1.101.2.12345678“> abzubilden.

Beide Anforderungen sind auch durch andere Implementierungsmittel, wie Umkodierung oder Mapping, zu erfüllen. Die Benutzung von Extensions erweist sich jedoch oft als der einfachste Weg. Obwohl HL7 Version 3 „extension“ nur als übergangsweises Hilfsmittel betrachtet („mainly provided to accommodate legacy alphanumeric identifier schemes“) (Data Types - Abstract Specification, 2.17.2), ist das Ende alphanumerischer Identifikationsschemata in der Praxis nicht abzusehen.

24. In welcher Form sind die OID-Identifikatoren zu dokumentieren?

Mangels spezialisierter Werkzeuge muss die Verwaltung eines OID-Knotens mit Hilfe von marktüblichen Standardanwendungen erfolgen. Die Identifikationsschemata eines OID-Konzepts können bequem in einer Tabelle gepflegt werden, z:B. als Textdokument, ein Spreadsheet oder in einer relationalen Datenbank). Die folgende Tabelle gibt Beispiele einer möglichen Tabellenstruktur (mit fiktiven Inhalten) an.

OID	Zusatzinformation	Bedeutung	Letzte Änderung	OID-Knoten delegiert an...
1.2.276.0.76.3.1.99999	(keine)	Klinikum Münchhausen	Müller, 01.02.2009
1.2.276.0.76.3.1.99999.1.1.0	AUGE	Abteilung Augenheilkunde	Meier, 03.02.2009
1.2.276.0.76.3.1.99999.1.2	(keine)	Abteilung Unfallchirurgie	Schmidt, 04.02.2009	EDV-Beauftragter der Unfallchirurgie Hr. Kümmerer, Tel. ...

Künftig sind diese Informationen in einer OID Registry zu dokumentieren.

OID-Registries

Weitere Informationen zur Registrierung und Suche von OIDs befinden sich unter: http://www.dimdi.de/static/de/ehealth/oid.