OID-Beispielszenario

Aus Hl7wiki
Version vom 9. Januar 2017, 13:31 Uhr von Wikiadmin (Diskussion | Beiträge)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche

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 >