OID-Beispielszenario

Einleitung

Die von HL7 und anderen Organisationen erstellten Implementierungsleitfäden benutzen OIDs sehr intensiv. Hierbei wird zwar regelmäßig auf den sog. FAQ zu OIDs beim DIMDI oder auch auf as HL7-Wiki verwiesen, dennoch fehlt ein übergreifendes Verständnis und eine Vorstellung davon, wie die verschiedenen OIDs ineinandergreifen. Dieses Dokument soll beispielhaft erläutern, wie die OID-Konzepte und die Nutzung von OIDs funktionieren. Als Beispiel sollen spezielle Dokumenttypen, die von der Organisation „OO" definiert worden sind, von verschiedenen Systemen erstellt und kommuniziert werden.

Alle OIDs sind beispielhaft/fiktiv. Zum Verständnis ist die Root-OID „99.1.2.3" an die Zentralstelle vergeben worden, die die OIDs vergibt.

Beispielkonzepte

Grundlage des Szenarios sind Hersteller, die Anwendungen (=Systeme) herstellen und in Häusern (Krankenhäuser oder Arztpraxen) zum Einsatz bringen. Nachfolgend werden beispielhaft verschiedene Konzepte erstellt, die Anwendungen deployed/instanziiert, Arztbriefe von verschiedenen Anwendern erstellt und kommuniziert.

Zentralstelle

Diese Organisation verteilt die Root-OIDs and interessierte Organisation/Firmen.

OID	Beschreibung
99.1.2.3	Root der Zentralstelle
99.1.2.3.1	Interne Objekte
99.1.2.3.2	Interne Organisationstrukturen
99.1.2.3.3	Instanzidentifkatoren
99.1.2.3.3.1	..
..
99.1.2.3.3.11	Hersteller A
..
99.1.2.3.3.22	Hersteller B
..
99.1.2.3.3.33	Organisation OO

Hersteller A

Hersteller A hat seine Root-OiD von der Zentralstelle erhalten. Sein OID-Konzept sieht wie folgt aus:

OID	Beschreibung
99.1.2.3.3.11	Root-OID
99.1.2.3.3.11.1	Kunden
99.1.2.3.3.11.1.<nr>	Kunde <nr>
99.1.2.3.3.11.1.<nr>.1	Patienten Kunde <nr>
99.1.2.3.3.11.2.<nr>.2	Dokumente Kunde <nr>
99.1.2.3.3.11.2.<nr>.3	Diagnosen Kunde <nr>
99.1.2.3.3.11.2.<nr>.4	Maßnahmen Kunde <nr>

Nachfolgende eine Liste von Codes für die verschiedenen Kunden. Die Codes werden erstmal direkt selber nicht benötigt, jedoch die Namen der Kunden.

Code (gleichzeitig die Nummer)	Beschreibung
111	Adelshausen
222	Burgdorf
333	Conigsfeld
..

Die hier die Kundenliste für den Aufbau der OID verwendet wird und gleichzeitig ein Codesystem darstellt, muss der Code numerisch sein!

Hersteller B

Dieser Hersteller hat ein sehr einfaches OID-Konzept, das auf einer simplen Auflistung beruht:

OID	Beschreibung
99.1.2.3.3.22	Root-OID
99.1.2.3.3.22.1	Kunde Adelshausen
99.1.2.3.3.22.2	Patienten Kunde Adelshausen
99.1.2.3.3.22.3	Mitarbeiter Kunde Adelshausen
99.1.2.3.3.22.4	Kunde Dierdorf
99.1.2.3.3.22.5	Patienten Kunde Dierdorf
99.1.2.3.3.22.6	Dokumente Kunde Adelshausen
99.1.2.3.3.22.7	Mitarbeiter Kunde Dierdorf
99.1.2.3.3.22.8	Dokumente Kunde Adelshausen
99.1.2.3.3.22.9	Diagnosen Kunde Adelshausen
99.1.2.3.3.22.10	Diagnosen Kunde Dierdorf
99.1.2.3.3.22.11	Maßnahmen Kunde Dierdorf
99.1.2.3.3.22.12	Maßnahmen Kunde Adelshausen
..	..

Hersteller C

Dieser Hersteller hat seine Root-OID von der Organisation OO erhalten.

OID	Beschreibung
99.1.2.3.3.33.4.3	Root-OID

Hersteller C kann genau wie die beiden anderen Hersteller Daten austauschen. Er muss lediglich ein entsprechendes Konzept aufstellen.

Organisation OO

Diese Organisation hat verschiedene Dokumenttypen definiert. Nachfolgend ist die Identifikation aufgelistet. Diese Organisation hat einige OIDs vergeben, deren Einsatz hier nicht relevant ist und deshalb mit „??" dargestellt sind.

OID	Beschreibung
99.1.2.3.3.33	Root-OID
99.1.2.3.3.33.1	??
99.1.2.3.3.33.2	??
99.1.2.3.3.33.3	??
99.1.2.3.3.33.4	Root-OIDs für fremde Organisationen
99.1.2.3.3.33.4.1	??
99.1.2.3.3.33.4.2	??
99.1.2.3.3.33.4.3	Hersteller C
99.1.2.3.3.33.5	Dokumenttypen
99.1.2.3.3.33.6	Ärzte

Nachfolgend ist die Liste mit den fiktiven Dokumenttypen aufgelistet

Code	Beschreibung
A	Dokumenttyp 1
B	Dokumenttyp 2
C	Dokumenttyp 3

Instanzen

In diesem Abschnitt werden einige mögliche Instanzen aufgelistet, um die Verwendung von OIDs zu demonstrieren.

Patienten

Zuerst einmal brauchen wir Patienten. In unserem Beispiel werden 2 Personen als Patienten in den beiden Systemen beim Kunden in Adelshausen angelegt – allerdings unabhängig voneinander, so dass diese verschiedene Instanzidentifikatoren bekommen:

Patient	Hersteller A	Hersteller B
Müller, Hugo	99.1.2.3.3.11.1.111.1 + 345	99.1.2.3.3.22.2 + 223
Meier, Klaus	99.1.2.3.3.11.1.111.1 + 666	99.1.2.3.3.22.2 + 445

Wenn die beiden Systeme in einem Haus gekoppelt werden und nur eines das führende System ist, so übernimmt das andere die Identifikation aus dem führenden System, d.h. die OID inklusive der Extension!

Ärzte in Adelshausen

Die Organisation OO hat einigen Ärzten eine eigene Identifikation zugewiesen, die nachfolgend dann auch genutzt werden soll. Hersteller B wiederum hat für die Ärzte (Mitarbeiter) ebenfalls eine Tabelle spendiert.

Arzt	Id von Hersteller B	Id von Zentralstelle
Dr. Blickfeld	99.1.2.3.3.22.3 + aaa
Dr. Sehfeld	99.1.2.3.3.22.3 + bbb	99.1.2.3.3.33.6 + 222
Dr. Nahfeld	99.1.2.3.3.22.3 + ccc	99.1.2.3.3.33.6 + 333
Dr. Kurzfeld	99.1.2.3.3.22.3 + ggg	99.1.2.3.3.33.6 + 111

Wie aus der Tabelle ersichtlich ist, haben die Ärzte zum Teil Identifikationen von mehreren Institutionen bekommen.

Dokumentinstanzen

Zuerst sollen einige Dokumente erzeugt werden, in denen OIDs vorkommen. Angegeben ist jeweils die Root mit Extension.

Adelshausen: Hersteller A

Dieser Kunde hat die Nummer 111, die in der OID verwendet wird.

Patient	Dokument-ID	Dokumenttyp (Codesystem + Code)
99.1.2.3.3.11.1.111.1 + 345	99.1.2.3.3.11.2.111.2 + 213324	99.1.2.3.3.33.5 + A
99.1.2.3.3.11.1.111.1 + 345	99.1.2.3.3.11.2.111.2 + 213325	99.1.2.3.3.33.5 + A
99.1.2.3.3.11.1.111.1 + 666	99.1.2.3.3.11.2.111.2 + 213326	99.1.2.3.3.33.5 + B
99.1.2.3.3.11.1.111.1 + 666	99.1.2.3.3.11.2.111.2 + 213327	99.1.2.3.3.33.5 + A

Adelshausen: Hersteller B

Dieser Kunde hat hier ebenfalls eine eigene OID, die allerdings hierfür nicht genutzt wird, da sowohl die Patienten (99.1.2.3.3.22.2) als auch Dokumente eine eigene OID (99.1.2.3.3.22.6) vom Hersteller B für diesen Kunden bekommen haben. Zur Demonstration wird hier die gleiche Anzahl von Dokumenten von demselben Typ erstellt:

Patient	Dokument-ID	Dokumenttyp (Codesystem + Code)
99.1.2.3.3.22.2 + 223	99.1.2.3.3.22.6 + 1115	99.1.2.3.3.33.5 + A
99.1.2.3.3.22.2 + 223	99.1.2.3.3.22.6 + 1116	99.1.2.3.3.33.5 + A
99.1.2.3.3.22.2 + 445	99.1.2.3.3.22.6 + 1117	99.1.2.3.3.33.5 + B
99.1.2.3.3.22.2 + 445	99.1.2.3.3.22.6 + 1118	99.1.2.3.3.33.5 + A

An der Erstellung der o.g. Dokumente haben jeweils mehrere Ärzte mitgewirkt. Deren Identifikation ist nachfolgend aufgelistet.

Dokument-ID	Autor(en)	Unterzeichner
99.1.2.3.3.22.6 + 1115	99.1.2.3.3.22.3 + aaa 99.1.2.3.3.33.6 + 111	99.1.2.3.3.22.3 + aaa
99.1.2.3.3.22.6 + 1116	99.1.2.3.3.22.3 + bbb 99.1.2.3.3.33.6 + 333	99.1.2.3.3.22.3 + ggg
99.1.2.3.3.22.6 + 1117	99.1.2.3.3.22.3 + ccc	99.1.2.3.3.33.6 + 111
99.1.2.3.3.22.6 + 1118	99.1.2.3.3.33.6 + 111	99.1.2.3.3.33.6 + 222

Hieraus wird bspw. deutlich, dass ein Arzt (Mitarbeiter) durchaus über unterschiedliche IDs identifiziert werden kann.

Damit würde bspw. das erste Dokument in XML wie folgt dargestellt, wobei irrelevante Attribute und Elemente weggelassen worden sind:

<?xml version="1.0" encoding="iso-8859-1"?>
<ClinicalDocument >
	<typeId root="2.16.840.1.113883.1.3" 
		   extension="POCD_HD000040" />
	<id root="99.1.2.3.3.22.6" extension="1115" />
	<code code="A" codeSystem="99.1.2.3.3.33.5" />
	<recordTarget>
		<patientRole>
			<id extension="223" root="99.1.2.3.3.22.2" />
		</patientRole>
	</recordTarget>
	<author>
		<assignedAuthor>
			<id extension="aaa" root="99.1.2.3.3.22.3" />
			<id extension="111" root="99.1.2.3.3.33.6" />
		</assignedAuthor>
	</author>
	<legalAuthenticator>
		<assignedAuthor>
			<id extension="aaa" root="99.1.2.3.3.22.3" />
		</assignedAuthor>
	</legalAuthenticator>
...
</ClinicalDocument >