	Dieses Dokument gibt wieder: Nachrichtenprofile deutsche Nachrichtenprofile: Dokumentenmanagement (01). Die Teilmaterialien gehören der Kategorie v2profile an.

{{{Title}}}

deutsche Nachrichtenprofile: Dokumentenmanagement

Nachrichtenprofile

vorgelegt von:
HL7-Deutschland

ballotiert

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

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

Kontributoren
	Agfa HealthCare GmbH	Bonn
\|100px]]	InterComponentWare	Walldorf
\|100px]]	Optimal Systems GmbH	Berlin

Grafiken fehlen! Formatierung noch nicht komplett

Version:	01
Ausgabe:	2013
HL7-Version:	2.5
Stand:	04. Dezember 2013
Dokumenten-OID:	2.16.840.1.113883.2.6.7.56
Profil-OID:	2.16.840.1.113883.2.6.9.69 (Profil A: mit Inhalt) 2.16.840.1.113883.2.6.9.70 (Profil B: ohne Inhalt) 2.16.840.1.113883.2.6.9.71 (Profil C: Anfragen) 2.16.840.1.113883.2.6.9.72 (Profil D: eFA)

Ansprechpartner:

Dr. Frank Oemig, Agfa HealthCare, Bonn

Inhaltsverzeichnis

1 Dokumentinformation
2 Autoren und Copyright-Hinweis, Nutzungs¬hinweise
3 1. Einleitung
- 3.1 2. Scope
- 3.2 3. Basis-Dokumente
4 4. Akteure + Transaktionen
5 9. Use Cases
6 14. Dokumentenmanagement
7 24. Interaktionen
8 31. Dokumenten-Management-Nachrichten
- 8.1 32. Nachrichtenstrukturen
- 8.2 36. Beispielnachrichten
9 49. Überarbeitete Segmente
- 9.1 50. EVN – Ereignisdaten (Event Type)
- 9.2 51. OBX – Observation/Result
10 58. Anhang A: Mapping auf HL7 V3
11 63. Anhang B: Mapping auf IHE XDS
- 11.1 64. Mapping der Transaktionen
- 11.2 65. Mapping der Elemente
12 66. Anhang C: Änderungsvorschläge für HL7 v2.7
13 67. Anhang D: sonstiges
- 13.1 68. Referenzen
- 13.2 69. Detaillierte Änderungshistorie

Dokumentinformation

Änderungshistorie

Release	Datum	Autor	Bemerkung	Dok.-OID
3.0	16.09.13	FO	Einarbeitung Kommmentare
3.0	07.03.13	FO	Freigabe zum PAM-Abgleich
1.2	10.09.11	RB	Ergänzung XDS.b
1.1	10.09.11	FO	Ergänzung wg. eFA
1.0	10.04.07	FO	Zusammenstellung und Veröffentlichung (Verschieben nach Dok. gemeinsame Nachrichtenelemente)\|\|2.16.840.1.113883.2.6.7.56
0.96	02.04.07	FO	Auflösung Ballotkommentare	n.a.
0.95	09.02.07	FO	Vorbereitung Ballot	n.a.
0.94	05.01.07	FO	Einarbeitung Kommentare	n.a.
0.93	23.12.06	CG		n.a.
0.92		CO		n.a.
0.91		CO		n.a.
0.9	30.11.06	FO	Kommentare von ICW	n.a.
0.8	14.11.06	FO	erweiterte Mapping-Informationen	n.a.
0.7	24.10.06	FO	Mapping auf RCMR-Nachricht	n.a.
0.6	09.10.06	FO	weitergehende Detailspezifikation Einarbeitung Kommentare neue Datentypen\|\|n.a.
0.5	26.09.06	FO	Use-Cases: Akteure + Transaktionen Scope-Statement\|\|n.a.
0.4	20.0906	FO	Erneute Überarbeitung mit Durchsicht de Kommentare verteilt auf der TC-Sitzung an interessierte Hersteller\|\|n.a.
0.3	08.09.06	RB +CG	Kommentare Christof Gessner + Ralf Brandner	n.a.
0.2	06.09.06	FO	Einfügung weiterer Nachrichten	n.a.
0.1	06.06.06	FO	Erstellung	n.a.

Editor

Dr. Frank Oemig (FO), Agfa HealthCare, Bonn

Autoren

Dr. Ralf Brandner (RB), InterComponentWare AG, Walldorf
Dr. Christof Gessner (CG), Optimal Systems, Berlin
Dr. Frank Oemig (FO), Agfa HealthCare, Bonn

Mit Beiträgen von

Christian Ohr (CO), InterComponentWare AG, Walldorf
Jan Klasser (JK), Agfa HealthCare, Trier
Rene Spronk (RS), Ringholm, Essen
Marek Václavik (MV), SER, Neustadt/Wied

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

Dieses Dokument dient der Definition von Nachrichtenprofilen zur Übermittlung von Dokument-Management-Nachrichten.

Bei der Erzeugung und Verwaltung von primär digitalen Dokumenten lassen sich drei Funktionsebenen unterscheiden:

die Erstellung von Dokumenten mit Steuerung und Kontrolle der Erstellungs- und Freigabeprozesse (z.B. in einem endoskopischen Befundungssystem oder bei der Arztbriefschreibung), ggf. verbunden mit der auto¬matischen Übernahme strukturiert vorliegender Daten in die Dokumentation. In modernen Systemen wird dieser Funktionsbereich häufig durch Workflowkomponenten unterstützt und in den Behandlungs- bzw. Untersuchungsprozess integriert.
die Verwaltung der erzeugten Dokumentation, die Aufzeichnung und Bewahrung des klinischen Kontextes und die Abbildung von Beziehungen zwischen Dokumenten (Folge¬dokumente, geänderte neue Versionen, Transformation eines Quelldokumentes in ein anderes Format).
die dauerhafte Speicherung und Verwaltung der physischen Datenobjekte und die langfristige Sicherung der Beweiskraft der Dokumente.

Diese drei Funktionalitäten können in einem einzigen System abgebildet werden oder auch in separaten Systemen. In jedem Fall sollten die logischen Ebenen klar voneinander abge¬grenzt sein, nicht zuletzt um auf zukünftige Systemmigrationen vorbereitet zu sein. Über MDM-Nachrichten können Dokumente in das System eingebracht und abgerufen werden. Die HL7-Schnittstellen ermöglichen überdies eine Statusverwaltung, so dass externe Systeme eine DMS-Infrastruktur bereits während der Erstellungsphase nutzen können. Die Ebene der physikalischen Archivierung ist üblicherweise in einer separaten Applikationsschicht untergebracht (storage layer), z.B. erfolgt die Speicherung auf optischen Jukeboxen oder mittels einer Ablage der Daten in einem unternehmensweiten SAN oder HSM-System.

Diesen logischen Funktionsbereichen entspricht die Implementierung einer Status¬verwaltung auf drei Ebenen:

Bearbeitungsstatus
Dokumentenstatus
Archivierungsstatus

2. Scope

In diversen Projekten wird eine Infrastruktur mit einem zentralen Dokumentenarchiv gefordert. Hierfür stehen die Spezifika¬tionen noch nicht vollständig fest. Der Kommunikation von Dokumenten dienen auch die aus HL7 v2.x bekannten MDM-Nachrichten, die Gegenstand dieses Profils sind.

Im Gegenzug muss an dieser Stelle auf die IHE-Integrationsprofile hingewiesen werden: Das XDS-Profil zum „Cross-Enterprise Document Sharing" hat sich zum Ziel gesetzt, Dokumente einrichtungsübergreifend auszutauschen und dafür diverse Standards (HL7, ebXML, SOAP, HTTPS, SQL) zu benutzen.

Ziel dieses Dokumentes ist es deshalb nicht, XDS abzulösen. Vielmehr soll es dazu dienen, für eine hausinterne Dokumentenverwaltung, für die XDS nicht in Frage kommt und die die MDM-Nachrichten als Alternative sehen, eine nationale Implementierungs¬grundlage zu schaffen, um eine gewisse Interoperabilität sicherzustellen.

In einem ersten Schritt wird deshalb auf die Registrierung und Hinterlegung der Dokumente in einer Registry/Repository fokussiert. Die Abfrage der Dokumente über die Meta-Informationen wird erst mal zurückgestellt.

3. Basis-Dokumente

Dieses Dokument benötigt folgende Dokumente:

gemeinsame Nachrichtenelemente (OID 2.16.840.1.113883.2.6.7.2)
Rahmendokument (OID 2.16.840.1.113883.2.6.7.1)
HL7 v2.5 in der deutschen Fassung für eine vollständige Dokumentation
OID-Konzept und OID-Registry beim DIMDI ([3])

4. Akteure + Transaktionen

Dazu werden - angelehnt an IHE - folgende Akteure mit den dazugehörigen Trans¬aktionen beschrieben:

Akteure	Transaktionen	Direction	Optionalität
Document Source	Provide&Register Document	send	R
Document Repository	Register Document	send	R
	Provide&Register Document	receive	O
	Retrieve Document	receive	O
Document Registry	Register Document	receive	R
	Query Registry	receive	O
Document Consumer	Query Registry	send	R
	Retrieve Document	send	R

Anmerkung: Die Festlegung der Optionalität erfolgt derzeit vor dem Hintergrund, dass die Abfrage (Query) noch nicht spezifiziert wird.

An diesem Szenario sind 4 Akteure beteiligt:

5. Document Source

Die Dokumentenquelle erzeugt Dokumente. Sie informiert ein Repository über das Erstellen und Verändern dieser Dokumente, wobei die entsprechen¬den Dokumente mit in der Nachricht verschickt werden.

6. Document Repository

Das Repository nimmt diese Dokumente entgegen und speichert diese. Darüber hinaus leitet es die Meta-Informationen an die Registry weiter. Ferner liefert das Repository Dokumente an den Konsumenten aus. Die Identifikation der Dokumente erfolgt hierbei über eindeutige IDs. (Dieser Vorgang ist nicht Bestandteil dieser Spezifiaktion.)

7. Document Registry

Die Registry besitzt lediglich die Meta-Informationen zu einem Dokument einschließlich eines Verweises, der das Dokument in dem Repository eindeutig indentifiziert. Die Registry beantwortet Anfragen nach bestimmten Dokumenten, indem es Verweise auf die Dokumente zurückliefert.

8. Document Consumer

Der Konsument der Dokumente kann die Registry anhand bestimmter Informationen befragen. Die zurück übermittelten Verweise kann er benutzen, um sich die Dokumente von dem Repository übermitteln zu lassen.

9. Use Cases

Die abzudeckenden Szenarien lauten wie folgt:

Benachrichtigung über die Anlage eines neuen Dokumentes
Benachrichtigung über Veränderungen an den Meta-Informationen: Status
Benachrichtigung über inhaltliche Veränderungen
Suche nach bestimmten Dokumenten
Anforderung von Dokumenten
Stornierung von Dokumenten

Die von o.g. Liste mit diesem Profil behandelten Use Cases werden nachfolgend beschrieben:

10. Anlage eines neuen Dokumentes

Dokumente werden von einem oder mehreren Autoren/Editoren erstellt und bearbeitet. Sobald „man" der Meinung ist, dass ein solches Dokument anderen zur Verfügung stehen sollte, so wird es mit Hilfe der Nachrichten MDM^T01 oder MDM^T02 bekannt gemacht. Hierbei ist es unerheblich, ob es sich um ein vorläufiges oder endgültiges Dokument handelt oder auch noch gar nicht im Zugriff ist, d.h. lediglich die Existenz bekannt gemacht werden soll.

11. Veränderungen an den Meta-Informationen

Neben dem eigentlichen Dokument spielen die Zusatzinformationen im Rahmen einer Recherche eine wichtige Rolle. Wenn sich inhaltlich an einem Dokument nichts ändert, so möchte man jedoch in einem Register die hinterlegten Meta-Informationen ändern können. Zu diesen gehören auch die ver¬schiedenen Statusangaben. Beispielsweise möchte man das Dokument freigeben oder archivieren:

Bearbeitungsstatus
Verfügbarkeitsstatus
Archivierungsstatus

12. Inhaltliche Veränderungen

Die wohl wichtigste Veränderung ist die Arbeit an dem Inhalt; so möchte man mehr oder weniger Informationen bereitstellen oder gar ein Zusatzdokument als Anhang erzeugen.

13. Stornierung von Dokumenten

Eine Stornierung eines Dokumentes ist eine Veränderung des Verfügbarkeitsstatus.

14. Dokumentenmanagement

Die in der Einleitung erwähnten Statusinformationen sowie die Beziehung zwischen Dokumenten sollen nun kurz näher erläutert werden.

15. Statusverwaltung von Dokumenten

Bei der Verwaltung von Dokumenten spielen verschiedene Statusinformationen eine Rolle. Die möglichen Übergänge werden nachfolgend vorgestellt. Statusänderungen eines Dokumentes (Bearbeitungsstatus, Verfügbarkeit, Archivierungsstatus, Vertraulichkeit) werden mit T03/T04 übermittelt (vgl. Kap.5.1. Ereignisse).

16. Bearbeitungsstatus (completion status)

Für die Erstellung, Änderung, Freigabe und Verteilung von Dokumenten gelten i.d.R. institutionsspezifische Geschäftsregeln. Diese Regeln können sich je nach Anwendungs¬fall, Abteilung und Art des Dokumentes unter¬scheiden. Beispielsweise könnten Dokumente bereits vor der endgültigen Autorisierung abteilungsintern als „vorläufige Befunde" freigegeben werden (pre-authenticated). Andere Dokumente werden erst nach einem mehrstufigen Freigabeverfahren abgeschlossen. Ein Dokument wird durch einen endgültigen Freigabeschritt „abgeschlossen" (authenticated, legally authenticated), dies schließt ggf. ein oder mehrere digitale Signaturvorgänge ein. Das Signieren selbst liegt im Verantwortungsbereich der Systeme und ist nicht in diesem Leitfaden spezifiziert.

Der Bearbeitungsstatus wird in TXA-17 übermittelt. Die für das Profil notwendigen Werte sind grau hinterlegt.

17. Dokumentenstatus/Verfügbarkeitsstatus (availability status)

Dieser Status bildet eine standardisierte Zustands¬verwaltung des Dokumentes ab. Unabhängig vom Bearbeitungszustand und von der individuellen Ausprägung der Dokumentenerzeugung wird auf dieser Ebene eine einheitliche Dokumentenverwaltung durchgeführt, hier wird das Versionsmanagement geregelt und ggf. werden Relationen zwischen verschiedenen Versionen erzeugt (replace, append, transform). „Neue" Dokumente stehen zunächst nicht für die Patienten¬versorgung zur Verfügung (unavailable). Sie können editiert, mehrfach geändert oder wieder gelöscht werden. Ist ein Dokument jedoch einmal verfügbar gemacht worden (available), so ändert sich seine rechtliche Bedeutung. Ein für die Patientenversorgung verfügbar gemachtes Dokument bleibt dauerhaft erhalten, es kann aber durch andere Dokumente ersetzt (replace-Relation), ergänzt (append-Relation) oder storniert werden. Die Transitionen dieses Statusnetzes sind also direkt mit den Änderungen der rechtlichen Bedeutung eines Dokumentes verbunden.

Der Verfügbarkeitsstatus wird in TXA-19 übermittelt.

18. Archivierungsstatus (storage status)

Diese Statusvariable beschreibt den physika¬lischen Speicherzustand des Dokumentes. Die Bedeutung dieses Feldes ist abhängig von der in einer bestimmten Implementierung gewählten Archivierungs¬strategie. Beispielsweise ist ein Dokument zwar ins Archivsystem eingestellt und wird dort revisionssicher verwaltet (storageCode = "active"), es ist aber noch nicht in das Langzeitarchiv eingestellt worden (storageCode = "archived"), da diese Transition nach den Geschäftsregeln dieser Klinik einheitlich erst zum Zeitpunkt der Entlassung durchgeführt wird. Ein Dokument, das zwar im Langzeitarchiv eingestellt aber nicht im direkten Zugriff ist, wird als archiviert bezeichnet (storageCode = „archived"). Die logische Entfernung aus dem Archiv nach Ablauf der Archivierungszeit wird ebenfalls über diesen Statuswert abgedeckt (storageCode = "purged").

Der Archivierungsstatus wird in TXA-20 übermittelt.

19. Beziehung zwischen den Dokumenten

20. Überarbeitung von Dokumenten

Solange das Dokument noch nicht freigegeben ist (Verfügbarkeitsstatus = „UN") kann es noch überarbeitet werden. Dies wird mit T07/T08 kommuniziert:

Nachdem ein Dokument freigegeben wurde (Verfügbarkeitsstatus = „AV") kann es nur noch ersetzt werden. Das neue Dokument hat den Status „AV" und das Originaldokument ändert seinen Status in „OB". Das neue Dokument wird mit T09/T10 kommuniziert, gleichzeitig ändert das alte Dokument seinen Status (vgl. HL7 v2.5 Kap.9.5.9).

Datei:Mdm repleacement.gif

21. Addendum (Anhänge)

Zu einem bereits existierenden Dokument kann als Ergänzung oder Fortschreibung ein Addendum erstellt werden, das als separates Dokument gilt. Alternativ oder zusätzlich entsteht dabei eine neue Version des Originaldokuments, das beide Inhalte vereint. Diese neue Version wird ebenfalls als separates Dokument behandelt. Ob dies so realisiert werden muss, ist nicht Bestandteil dieses Profils:

22. Transform (Transformation)

Eine weitere Möglichkeit ist die Erzeugung einer neuen Repräsentation aus einem bereits vorhandenen Dokument, d.h. aus dem originären Inhalt (=Quelldokument) wird ein Extrakt oder eine andere Sicht/Darstellung (=Zieldokument) erzeugt, ohne neue Informationen hinzuzufügen.

Diese Art der Umwandlung wird derzeit in v2.5 nicht abgedeckt. Für v2.7 wird deshalb ein entsprechender Vorschlag eingereicht.

23. Zuordnung von Dokumenten zum Patient, Fall und Bewegung

Dokumente werden i.d.R. zu einem Behandlungsfall des Patienten erstellt. Die Patientennummer (PID-3) muss in jeder MDM Nachricht mitgegeben werden, so dass die Zuordnung zu einem Patient immer möglich ist.

In Abhängigkeit vom Anwendungsfall, der Art des Dokumentes und den Anwendungs¬systemen kann es vorkommen, dass Dokumente direkt zum Patienten erstellt werden, zu einem Behandlungsfall oder zur Bewegung innerhalb eines Behandlungsfalles. Die Fallnummer (PV1-19) und die zusätzliche Fallnummer (PV1-50) können in der MDM Nachricht mitgegeben werden, d.h. wenn sie übermittelt werden, ist die Zuordnung des Dokumentes zum Behandlungsfall möglich.

Optional kann die Bewegungsnummer (ZBE-1) ebenfalls über die MDM Nachrichten übermittelt werden.

24. Interaktionen

25. Ereignisse

Folgende Ereignisse können auftreten:

Beschreibung	Ereignis
Ein Dokument wird neu gemeldet. Anm.: Jedes Dokument – mit einer bestimmten ID kann nur einmal gemeldet werden.\|\|T01, T02
Der Status eines Dokumentes ändert sich, d.h. mindestens einer der folgenden Statuswerte ändert sich: Der Bearbeitungsstatus (TXA-17) Der Vertraulichkeitsstatus (TXA-18) Der Verfügbarkeitsstatus (TXA-19) Der Archivierungsstatus (TXA-20)\|\|T03, T04
Zu einem Dokument werden Informationen als Addendum hinzugefügt. Dadurch entsteht ein neues Dokument, das auf das vorhergehende über die Nummer des Bezugsdokuments (TXA-13) verweist.	T05, T06
Solange ein Dokument noch nicht für die Behandlung eines Patienten verfügbar ist (Verfügbarkeitsstatus = „UN") kann es geändert werden.	T07, T08
Sobald ein Dokument verfügbar gemacht wurde darf es nicht mehr geändert werden. Es wird dann durch ein neues Dokument ersetzt.	T09, T10
Stornierung eines nicht verfügbaren Dokumentes	T11
Anfragen nach bestimmten Dokumenten	T12

26. Profile

Die Nachrichten können in vier Gruppen zusammengefasst werden, die in der nachfolgenden Tabelle als Profile A, B, C und D deklariert sind. Die in dem jeweiligen Profil spezifizierten Nachrichten sind entsprechend der Verwendung in einer Implementierung zu unterstützen.

Profil	Bezeichnung	OID
A	Dokumenten-Management-Nachrichten mit Inhalt	2.16.840.1.113883.2.6.9.69
B	Dokumenten-Management-Nachrichten ohne Inhalt	2.16.840.1.113883.2.6.9.70
C	Dokumenten-Management-Nachrichten (Anfragen)	2.16.840.1.113883.2.6.9.71
D	Dokumenten-Management-Nachrichten (für eFA)	2.16.840.1.113883.2.6.9.72

Event	Beschreibung	Verwendung				Struktur	Ant¬wort
	Profil	A	B	C	D
T01: MDM/ACK	Original document notification/ Benachrichtigung über die Neuanlage eines Dokuments ohne Inhalt		R		C	MDM_T01	ACK
T02: MDM/ACK	Original document notification and content/ Benachrichtigung über die Neuanlage eines Dokuments mit Inhalts¬übermittlung	R			C	MDM_T02	ACK
T03: MDM/ACK	Document status change notification/ Benachrichtigung über die Statusänderung eines Dokuments (ohne Inhalt)		RE		R	MDM_T01	ACK
T04: MDM/ACK	Document status change notification and content/ Benachrichtigung über die Statusänderung eines Dokuments (mit Inhalt)	RE				MDM_T02	ACK
T05: MDM/ACK	Document addendum notification/ Benachrichtigung über die Ergänzung eines Dokuments (ohne Inhalt)		O			MDM_T01	ACK
T06: MDM/ACK	Document addendum notification and content/ Benachrichtigung über die Ergänzung eines Dokuments (mit Inhalt)	O				MDM_T02	ACK
T07: MDM/ACK	Document edit notification/ Benachrichtigung über die Änderung eines Dokuments (Dok. nicht beigefügt)		O			MDM_T01	ACK
T08: MDM/ACK	Document edit notification and content/ Benachrichtigung über die Änderung eines Dokuments (Dok. beigefügt)	O				MDM_T02	ACK
T09: MDM/ACK	Document replacement notification/ Benachrichtigung über den Austausch eines Dokuments (Dok. nicht beigefügt)		RE		R	MDM_T01	ACK
T10: MDM/ACK	Document replacement notification and content/ Benachrichtigung über den Austausch eines Dokuments (mit Inhalt)	RE				MDM_T02	ACK
T11: MDM/ACK	Document cancel notification/ Benachrichtigung über die Löschung eines Dokuments	RE	RE		R	MDM_T01	ACK
T12: QRY/DOC	Document Query/ Dokumentanfrage			R	X	QRY	DOC_T12

27. Profil A: Interaktionsdiagramm (mit Inhalt)

28. Profil B: Interaktionsdiagramm (ohne Inhalt)

Das Interaktionsdiagramm für die Nachrichten ohne Inhalt ist im Prinzip äquivalent zu dem mit den Nachrichten mit Inhalt, nur dass das OBX-Segment fehlt und die Eventcodes differieren.

29. Profil C: Interaktionsdiagramm (Anfragen)

Dieses Profil wird derzeit nicht weiter ausgearbeitet.

Dazu würden folgende Nachrichten und Segmente benötigt werden: Nachrichten:

DOC_T12

In diesem Nachrichtenpaar werden folgende Segmente genutzt, die noch im Detail zu spezifizieren wären:

QAK - Query Acknowledgement
QRD – Original-style Query Definition
QRF – Original-style Query Filter

Anmerkung: Die Segmente QRD und QRF sind in v2.5 als „for backward compatibility only" deklariert. Damit kann diese Nachricht ab v2.6 eigentlich nicht mehr unterstützt werden. Für die Anforderung von Dokumenten beim Repository werden in diesem Profil ebenfalls keine weiteren Festlegungen getroffen. Üblicherweise wird diese Interaktion über die Benutzeroberfläche ausgelöst; dabei kommen in der Regel typische transportorientierte Verfahren zum Einsatz (z.B. HTTP(GET)-Requests).

30. Profil D: Interaktionsdiagramm (eFA)

31. Dokumenten-Management-Nachrichten

32. Nachrichtenstrukturen

Für die Übermittlung der Informationen werden zwei Nachrichtenstrukturen genutzt, die zueinander äquivalent sind und sich nur am Ende in dem Vorhandensein des OBX-Segmentes zur Übermittlung des Nachrichteninhalts unterscheiden.

33. Sending Message: MDM_T01

Struktur der Nachricht ohne das Dokument:

Segmente	Kard.	Ver¬wen¬dung	Beschreibung	Kapitel
MSH	[1..1]	R	Message Header	2.15.9
{[SFT]}	[0..1]	C	Software Segment	2.15.12
EVN	[1..1]	R	Event Type	3.4.1
PID	[1..1]	R	Patient Identification	3.4.2
PV1	[1..1]	R	Patient Visit	3.4.3
[{	[0..\*]	O	-- COMMON_ORDER
ORC	[1..1]	R	Common Order	4.5.1
[{	[0..\*]	O	-- TIMING
TQ1	[1..1]	R	Timing/Quantity	4.5.4
{[TQ2]}	[0..\*]	O	Timing/Quantity Relationship	4.5.5
}]
OBR	[1..1]	R	Observation Request	4.5.3
{[NTE]}	[0..\*]	O	Notes and Comments	2.15.10
}]
TXA	[1..1]	R	Transcription Document Header	9.6.1
[ZBE]	[0..1]	O	Bewegung	-

34. Sending Message: MDM_T02

Struktur der Nachricht mit dem Dokument:

Segmente	Kard.	Ver¬wen¬dung	Beschreibung	Kapitel
MSH	[1..1]	R	Message Header	2.15.9
{[SFT]}	[0..1]	C	Software Segment	2.15.12
EVN	[1..1]	R	Event Type	3.4.1
PID	[1..1]	R	Patient Identification	3.4.2
PV1	[1..1]	R	Patient Visit	3.4.3
[{		O	-- COMMON_ORDER
ORC	[1..1]	R	Common Order	4.5.1
[{		O	-- TIMING
TQ1	[1..1]	R	Timing/Quantità	4.5.4
{[TQ2]}	[0..\*]	O	Timing/Quantity Relationship	4.5.5
}]
OBR	[1..1]	R	Observation Request	4.5.3
{[NTE]}	[0..\*]	O	Notes and Comments	2.15.10
}]
TXA	[1..1]	R	Transcription Document Header	9.6.1
\| bgcolor="BBFFFF" \|[1..1]	R	--- OBSERVATION
OBX	[1..1]	R	Observation/Result	7.4.2
{[NTE]}	[0..\*]	O	Notes and Comments	2.15.10
}
[ZBE]	[0..1]	O	Bewegung	-

Durch die Einschränkung wird die Anzahl an Wiederholungen für das OBX-Segment zur Übermittlung der Dokumente auf genau eines beschränkt.

35. Receiving Message: ACK

Segmente	Kard.	Ver¬wen¬dung	Beschreibung	Kapitel
MSH	[1..1]	R	Message Header	2.15.9
[ { SFT } ]	[0..1]	C	Software Segment	2.15.12
MSA	[1..1]	R	Message Acknowledgment	2.15.8
[ { ERR } ]	[0..\*]	RE	Error	2.15.5

36. Beispielnachrichten

37. T02

MSH|...<cr>
EVN|T02|19960215154405||04|097220^Smith^Frederick^A^Jr^Dr^MD^| <cr>
PID|…<cr>
PR1|…<cr>
TXA|0001|HP^history & physical|TX^text|19960213213000|099919^Tracy^Wayne^R^III^Mr^MS^|
    19960213153000|19960215134500||099919^Tracy^Wayne^R^III^Mr^MS^|097220^Smith^Frederick^A^Jr^Dr^MD^|
    01234567^Baxter^Catherine^S^Ms|1996021500001^transA|||example.doc|LA|UC|AV||AC|||||097220^Smith^Frederick^A^Jr^Dr^MD^| <cr>
OBX|1|RP|2000.40^CHIEF COMPLAINT|| ... <cr>

.

and so on.

38. T02

MSH|^~\&|HOSPAT|ADT|DATAGATE|ADT|20000516180000||MDM^T02^MDM_T02|102000|D|2.5^DEU&&HL70399|||AL|NE|DEU|
    8859/1|||2.16.840.1.113883.2.6.9.69^^2.16.840.1.1.13883.2.6^ISO
EVN||20000516180000
PID|||107000726^^^Alpha-Krankenhaus^PI||Essenbringer^Bernd^^^^^L ||19630402|M|||
    Postweg 4^^Weilheim^^82362^DEU^H|09190157|0881-4179455|08085-170|DEU||EVC||||||München|||D
PV1||I|C1^^^CH|N|9705582||||||||||||||9705582^^^Alpha-Krankenhaus^VN ||K|||||||||||||||
    E|||9411|||||20000222155500|20001113174000|||423||9705582
TXA|1|CN|application/word|||20000516142700|20000516142700||||heggli|45232||||45232.doc^HOSPAT|DI
OBX|1|ED|^Document Content|1|^text/plain^^Base64^VGhpcyBpcyBhbiBleGFtcGxlIERvY3VtZW50Lg==||||||F...

39. T04

MSH|^~\&|HOSPAT|ADT|DATAGATE|ADT|20000516180500||MDM^T04^MDM_T02|102001|D|2.5^DEU&&HL70399|||AL|NE|DEU|
    8859/1|||2.16.840.1.113883.2.6.9.69^^2.16.840.1.1.13883.2.6^ISO
EVN||20000516180500
PID|||107000726^^^Alpha-Krankenhaus^PI ||Essenbringer^Bernd^^^^^L ||19630402|M|||
    Postweg 4^^Weilheim^^82362^DEU^H|09190157|0881-4179455|08085-170|DEU||EVC||||||München|||D
PV1||I|C1^^^CH|N|9705582||||||||||||||9705582^^^Alpha-Krankenhaus^VN ||K|||||||||||||||E|||9411|||||
    20000222155500|20001113174000|||423||9705582
TXA|1|CN|application/word|||20000516142700|20000516142700|20000516170000|||heggli|45232||||45232.doc^HOSPAT|DI
OBX|1|ED|^Document Content|1|^text/plain^^Base64^VGhpcyBpcyBhbiBleGFtcGxlIERvY3VtZW50Lg==||||||F...

MSH|^~\&|HOSPAT|ADT|DATAGATE|ADT|20000516181000||MDM^T08^MDM_T02|102001|D|2.5^DEU&&HL70399|||AL|NE|DEU|
    8859/1|||2.16.840.1.113883.2.6.9.69^^2.16.840.1.1.13883.2.6^ISO
EVN||20000516181000
PID|||107000726^^^Alpha-Krankenhaus^PI ||Essenbringer^Bernd^^^^^L ||19630402|M|||
    Postweg 4^^Weilheim^^82362^DEU^H|09190157|0881-4179455|08085-170|DEU||EVC||||||München|||D
PV1||I|C1^^^CH|N|9705582||||||||||||||9705582^^^Alpha-Krankenhaus^VN ||K|||||||||||||||E|||9411|||||20000222155500|20001113174000|||423||9705582
TXA|1|CN|application/word|||20000516142700|20000516142700|20000516170000|||heggli|45232||||45232.doc^HOSPAT|AU
OBX|1|ED|^Document Content|1|^text/plain^^Base64^VGhpcyBpcyBhbiBleGFtcGxlIERvY3VtZW50Lg==||||||F...

40. T11

MSH|^~\&|HOSPAT|ADT|DATAGATE|ADT|20000516190000||MDM^T11^MDM_T01|102001|D|2.5^DEU&&HL70399|||AL|NE|DEU|
    8859/1|||2.16.840.1.113883.2.6.9.69^^2.16.840.1.1.13883.2.6^ISO
EVN||20000516190000
PID|||107000726^^^Alpha-Krankenhaus^PI ||Essenbringer^Bernd^^^^^L ||19630402|M|||
    Postweg 4^^Weilheim^^82362^DEU^H|09190157|0881-4179455|08085-170|DEU||EVC||||||München|||D
PV1||I|C1^^^CH|N|9705582||||||||||||||9705582^^^Alpha-Krankenhaus^VN ||K|||||||||||||||E|||9411|||||20000222155500|20001113174000|||423||9705582
TXA|1|CN|application/word|||20000516142700|20000516142700|20000516170000|||heggli|45232||||45232.doc^HOSPAT|AU

41. T01

MSH|^~\&|ORBIS|TEST KH 01|RECAPP|TEST KH 01|200411261036||MDM^T01^MDM_T01|167912|P|2.5^DEU&&HL70399|||AL|NE|DEU|
    8859/1|DE||2.16.840.1.113883.2.6.9.70^^2.16.840.1.1.13883.2.6^ISO
EVN||200411261036|200411261036|
PID|1||237686^^^Alpha-Krankenhaus^PI ||Meier^Sepp^^^^^L ||19221122|M|||Eurener Str. 11^^Trier^^54294^DEU^H|||||||||||||||D||
PV1|1|I|ST02^^^ABT01^^1974|01^Normalfall^301||^^^^^||||N||||||N|||2610075^^^Alpha-Krankenhaus^VN |||||||||||||||||||2400||||||200601101000||
TXA|1|Anforderung Pathologie|application/pdf|||||20041126103606||||583698^ORBIS PRIMITIVUMNUMMER||KLTSTS900002863465^MEDIS_KLTSTS90|PATH-2004-001241^ORBIS AUFTRAGSNUMMER|1082408_2876353_583698_20041126103606.PDF^ORBIS|AU|||||||

42. T01

MSH|^~\&|CARDDAS|HZL|DOC|ADT|20050524163405||MDM^T01^MDM_T01|123456|T|2.5^DEU&&HL70399|||AL|NE|DEU|
    8859/1|||2.16.840.1.113883.2.6.9.70^^2.16.840.1.1.13883.2.6^ISO
EVN||20050524163405|||||B1
PID|||79471^^^Alpha-Krankenhaus^PI ||Müller^Hans^^^^^L
PV1|||||||||||||||||||79237645^^^Alpha-Krankenhaus^VN |||||||||||||||||||||||||20040805
TXA||transferReport|application/pdf|||20040806|||37542341^Wohlfart^Peter^^^Dr.^^^^^^^L^HZL|||
    7952871424^^37459732765491768364593264738293^SHA-1||||7952871424.pdf^CARDDAS|AU|U|AV|||^Herzog^Reinhold^^^Prof.^^^^^^^L^HZL^20040807200200

43. T02

MSH|^~\&|CARDDAS|HZL|DOC|ADT|20050524163405||MDM^T02^MDM_T02|123456|T|2.5^DEU&&HL70399|||AL|NE|DEU|
    8859/1|||v70^^2.16.840.1.1.13883.2.6^ISO
EVN||20050524163405|||||B1
PID|||79471^^^Alpha-Krankenhaus^PI ||Müller^Hans^^^^^L
PV1|||||||||||||||||||79237645^^^Alpha-Krankenhaus^VN |||||||||||||||||||||||||20040805
TXA||transferReport|text/plain|||20040806|||37542341^Wohlfart^Peter^^^Dr.^^^^^^^L^HZL|||
    7952871424^^37459732765491768364593264738293^SHA-1||||Note01.txt^CARDDAS|AU|U|AV|||^Herzog^Reinhold^^^Prof.^^^^^^^L^HZL^20040807200200
OBX|1|ED|^Document Content|1|^text/plain^^Base64^VGhpcyBpcyBhbiBleGFtcGxlIERvY3VtZW50Lg==||||||F

44. T03

MSH|^~\&|CARDDAS|HZL|DOC|ADT|20050525163405||MDM^T03^MDM_T01|123457|T|2.5^DEU&&HL70399|||AL|NE|DEU|
    8859/1|||2.16.840.1.113883.2.6.9.70^^2.16.840.1.1.13883.2.6^ISO
EVN||20050525163405|||||B1
PID|||79471^^^Alpha-Krankenhaus^PI ||Müller^Hans^^^^^L
PV1|||||||||||||||||||79237645^^^Alpha-Krankenhaus^VN |||||||||||||||||||||||||20040805
TXA||transferReport|application/pdf|||20040806|||37542341^Wohlfart^Peter^^^Dr.^^^^^^^L^HZL|||
    7952871424^^37459732765491768364593264738293^SHA-1||||7952871424.pdf^CARDDAS|AU|U|OB|||^Herzog^Reinhold^^^Prof.^^^^^^^L^HZL^20040807200200

45. T04

MSH|^~\&|CARDDAS|HZL|DOC|ADT|20050524163405||MDM^T04^MDM_T02|123456|T|2.5^DEU&&HL70399|||AL|NE|DEU|
    8859/1|||2.16.840.1.113883.2.6.9.69^^2.16.840.1.1.13883.2.6^ISO
EVN||20050524163405|||||B1
PID|||79471^^^Alpha-Krankenhaus^PI ||Müller^Hans^^^^^L
PV1|||||||||||||||||||79237645^^^Alpha-Krankenhaus^VN |||||||||||||||||||||||||20040805
TXA||transferReport|text/plain|||20040806|||37542341^Wohlfart^Peter^^^Dr.^^^^^^^L^HZL|||
    7952871424^^37459732765491768364593264738293^SHA-1||||Note01.txt^CARDDAS|AU|U|AV|||^Herzog^Reinhold^^^Prof.^^^^^^^L^HZL^20040807200200
OBX|1|ED|^Document Content|1|^text/plain^^Base64^VGhpcyBpcyBhbiBleGFtcGxlIERvY3VtZW50Lg==||||||F

46. T09

MSH|^~\&|CARDDAS|HZL|DOC|ADT|20050526163405||MDM^T09^MDM_T01|123458|T|2.5^DEU&&HL70399|||AL|NE|DEU|
    8859/1|||2.16.840.1.113883.2.6.9.70^^2.16.840.1.1.13883.2.6^ISO
EVN||20050525163405|||||B1
PID|||79471^^^Alpha-Krankenhaus^PI ||Müller^Hans^^^^^L
PV1|||||||||||||||||||79237645^^^Alpha-Krankenhaus^VN |||||||||||||||||||||||||20040805
TXA||transferReport|application/pdf|||20040806|||37542341^Wohlfart^Peter^^^Dr.^^^^^^^L^HZL|||
    7952871425^^37459732765491768123493264738291^SHA-1|7952871424|||7952871425.pdf^CARDDAS|AU|U|AV|||
    ^Herzog^Reinhold^^^Prof.^^^^^^^L^HZL^20040807200200

47. T10

MSH|^~\&|CARDDAS|HZL|DOC|ADT|20050524163405||MDM^T10^MDM_T02|123456|T|2.5^DEU&&HL70399|||AL|NE|DEU|
    UNICODE UTF-8|||2.16.840.1.113883.2.6.9.69^^2.16.840.1.1.13883.2.6^ISO
EVN||20050524163405|||||B1
PID|||79471^^^Alpha-Krankenhaus^PI ||Müller^Hans^^^^^L
PV1|||||||||||||||||||79237645^^^Alpha-Krankenhaus^VN |||||||||||||||||||||||||20040805
TXA||transferReport|text/plain|||20040806|||37542341^Wohlfart^Peter^^^Dr.^^^^^^^L^HZL|||
    7952871424^^37459732765491768364593264738293^SHA-1||||Note01.txt^CARDDAS|AU|U|AV|||^Herzog^Reinhold^^^Prof.^^^^^^^L^HZL^20040807200200
OBX|1|ED|^Document Content|1|^text/plain^^Base64^VGhpcyBpcyBhbiBleGFtcGxlIERvY3VtZW50Lg==|

48. T11

MSH|^~\&|CARDDAS|HZL|DOC|ADT|20050524163405||MDM^T11^MDM_T01|123456|T|2.5^DEU&&HL70399|||AL|NE|DEU|
    8859/1|||2.16.840.1.113883.2.6.9.69^^2.16.840.1.1.13883.2.6^ISO
EVN||20050524163405|||||B1
PID|||79471^^^Alpha-Krankenhaus^PI ||Müller^Hans^^^^^L
PV1|||||||||||||||||||79237645^^^Alpha-Krankenhaus^VN |||||||||||||||||||||||||20040805
TXA||transferReport|text/plain|||20040806|||37542341^Wohlfart^Peter^^^Dr.^^^^^^^L^HZL|||
    7952871424^^37459732765491768364593264738293^SHA-1||||Note01.txt^CARDDAS|AU|U|AV|||^Herzog^Reinhold^^^Prof.^^^^^^^L^HZL^20040807200200

49. Überarbeitete Segmente

50. EVN – Ereignisdaten (Event Type)

Lfd. Nr.	Bechreibung	Ver¬wen¬dung	DT	Kap.
1
...
7	Event Facility/ Einrichtung, in der das Ereignis aufgetreten ist	R (RE)	HD	3.4.1.7

51. OBX – Observation/Result

Das OBX-Segment dient der Übermittlung des Dokumenten¬inhalts. Damit ist gemeint, dass das Dokument selbst mit übermittelt wird. Je nach zugrunde liegendem Format kann dies in unterschiedlicher Weise geschehen. Für Binärformate ist eine Base64-Kodierung zu wählen.

Dieses Segment kommt nur in den MDM-Nachrichten mit der Struktur MDM_T02 vor und ist dort – von der Standarddefinition her wiederholbar. Für die Übermittlung von Dokumentinhalten wird lediglich der Datentyp „ED" zugelassen, so dass der Inhalt des Dokumentes in einer einzigen Wiederholung erfolgt.

Anmerkung: Grundsätzlich können OBX-Segmente sonst auch für die folgenden Zwecke verwendet werden:

Übermittlung des Dokumenteninhaltes oder einer Kurzform als Freitext in OBX-5
Übermittlung einzelner Bestandteile (Sektionen, Textteile, Abschnitte) mit Kodierung in OBX-3 / OBX-4 und Text in OBX-5. Kodierung möglichst nach LOINC (hier sei auf den VHitG-Arztbrief verwiesen)
Übergabe zusätzlicher strukturierter Daten mit entsprechender Kodierung

Für derartige Informationen sind dann aber andere Nachrichten wie bspw. Befund¬nachrichten zu verwenden.

Lfd. Nr.	Beschreibung	Kard.	Ver¬wen¬dung	Table	Data Item	DT	Länge	Kap.
1	Set ID – OBX/ OBX-Segment¬nummer	[1..1]	R (O)		00569	SI	4	7.4.2.1
2	Value Type/ Ergebnisformat (Datentyp von Feld OBX-5)	[1..1]	R (C)	0125	00570	ID	2	7.4.2.2
3	Observation Identifier/ Bezeich¬nung der Unter¬suchung	[1..1]	R		00571	CE	250	7.4.2.3
4	Observation Sub-ID/ Differenzierung von Ergeb¬nissen einer Untersuchung	[0..1]	O (C)		00572	ST	20	7.4.2.4
5	Observation Value/ (Teil-) Ergebnis / Messwert	[1..\*]	R (C)		00573	varies	99999	7.4.2.5
6	Units/ Maßeinheit	[0..1]	RE (O)		00574	CE	250	7.4.2.6
7	References Range/ Referenz¬bereich/ Normal¬bereich	[0..1]	RE (O)		00575	ST	60	7.4.2.7
8	Abnormal Flags/ Bewertung des Ergebnisses / Meßwerts	[0..\*]	O	0078	00576	IS	5	7.4.2.8
9	Probability/ Wahrscheinlich¬keit/ Zuverlässigkeit des Ergeb¬nisses bzw. Meßwerts	[0..1]	O		00577	NM	5	7.4.2.9
10	Nature of Abnormal Test/ Art des Referenzbereiches	[0..\*]	O	0080	00578	ID	2	7.4.2.10
11	Observation Result Status/ Ergebnisstatus	[1..1]	R	0085	00579	ID	1	7.4.2.11
12	Effective Date of Reference Range/ Datum der letzten Referenzbereichsfestlegung im System	[0..1]	O		00580	TS	26	7.4.2.12
13	User Defined Access Checks/ benutzerdefinierte Zugriffs¬berechtigung (für dieses Ergebnis)	[0..1]	O		00581	ST	20	7.4.2.13
14	Date/Time of the Observation/ Zeitpunkt der Untersuchung / Probenentnahme	[0..1]	RE (O)		00582	TS	26	7.4.2.14
15	Producer's ID/ Kennzeichen der Untersuchungsstelle	[0..1]	O		00583	CE	250	7.4.2.15
16	Responsible Observer/ Verantwortlicher Untersucher	Y[0..1]	O		00584	XCN	250	7.4.2.16
17	Observation Method/ Untersuchungsmethode	[0..\*]	O		00936	CE	250	7.4.2.17
18	Equipment Instance Identifier/ ID des Gerätes	[0..\*]	O		01479	EI	22	7.4.2.18
19	Date/Time of the Analysis/ Zeitpunkt der Analyse	[0..1]	O		01480	TS	26	7.4.2.19

52. OBX-1 Segmentnummer

In diesem Feld wird fest eine „1" übermittelt, da Wiederholungen nicht zugelassen sind.

53. OBX-2 Ergebnisformat

In diesem Feld wird angegeben, in welchem Format das Ergebnis übermittelt wird.

54. Tabelle 0125

Wert	Beschreibung	Interpretation
ED	Encapsulated Data	In dieser Form kann das komplette Dokument – egal in welchem Format es vorliegt – übermittelt werden.
RP	Reference Pointer

55. OBX-3 Bezeichnung der Untersuchung

In diesem Kontext (Nutzung des OBX-Segmentes) ist mit Untersuchung das Dokument gemeint. Deshalb wird dieses Feld fix mit „DOKUMENT" gefüllt.

56. OBX-5 Ergebnis/Meßwert

In diesem Feld wird das Dokument oder ein Verweis darauf übermittelt.

57. OBX-14 Zeitpunkt der Untersuchung

In diesem Feld wird angegeben, wann das Dokument erstellt wurde.

58. Anhang A: Mapping auf HL7 V3

Dieser Leitfaden spezifiziert Nachrichtenprofile für den „Inhouse-Einsatz", d.h. zwischen Systemen innerhalb eines Krankenhauses. Um eine Kommunikation mit externen Systemen gemäß HL7 V3 zu ermöglichen, wird in diesem Anhang ein Mapping angegeben.

Dieser Abschnitt ist nicht normativ.

59. Beispielnachricht mit Mapping (T01)

Nachfolgend ist eine HL7 V3-Nachricht aufgeführt, die anstelle der Werte Informationen zum Mapping auf HL7 v2.5 (T01) enthält:

1	<?xml version="1.0" encoding="UTF-8"?>
2	<!--Sample XML file generated by XMLSpy v2005 rel. 3 U (http://www.altova.com)-->
3	<RCMR_IN000001UV01 xmlns="urn:hl7-org:v3" 
		xmlns:mif="urn:hl7-org:v3/mif" 
		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
		xsi:schemaLocation="urn:hl7-org:v3 ..\xsd\RCMR_IN000001UV01.xsd" 
		ITSVersion="XML_1.0">
4		<id root="'''$OID($MSH.3,$MSH.4,Message)'''" 
			  extension="'''$MSH.10'''" />
5		<creationTime value="'''$MSH.7'''"/>	
6		<versionCode code="V3-2006-06"/>
7		<interactionId root="2.16.840.1.113883" extension="'''$MSH.9 [1]'''"/>
8		<processingCode code="'''$MSH.11 [2]'''"/>	
9		<processingModeCode code="T"/>	
10		<acceptAckCode code="'''$MSH.15 [3]'''"/>	
11		<receiver>
12			<device>
13				<id root="'''$OID(const)'''" />
14			</device>
15		</receiver>	
16		<sender>
17			<device>
18				<id root="'''$OID($MSH.3,$MSH.4,Device)'''"/>
19				<agencyFor>		
20					<representedOrganization>
21						<id root="'''$OID($MSH.4,Organization)'''"/>
22					</representedOrganization>
23				</agencyFor>
24			</device>
25		</sender>
26		<controlActProcess moodCode="EVN">
27			<subject>
28				<clinicalDocument>
29					<id root="'''$OID($MSH.3,$MSH.4,Document)'''" 
						  extension="'''$TXA.12.1'''"/>
30					<code code="'''$TXA.2 [16]'''" codeSystem="'''$OID(const)'''"/>
31					<text mediaType="'''$TXA.3'''" 
							 encoding="'''$MSH.18 [34]'''" 
							 integrityCheck="'''$TXA.12.3'''" 
							 integrityCheckAlgorithm="'''$TXA.12.4'''">
32						<reference value="'''$TXA.16'''"/>
33					</text>	
34					<statusCode code="'''$TXA.19 [17]'''" 
									   codeSystem="2.16.840.1.113883.5.14"/>
35					<effectiveTime value="'''$TXA.6'''"/>
36					<availabilityTime value="'''$TXA.22.15'''"/>
37					<!-- Required for status change, replace and nullify. 
							Use nullFlavor if not present anyway -->
38					<reasonCode>
39						<text>'''$TXA.21'''</text>
40					</reasonCode>
41					<confidentialityCode code="'''$TXA.18 [18]'''" 
									codeSystem="2.16.840.1.113883.5.25"/>
42					<completionCode code="'''$TXA.17 [19]'''"/>
43					<storageCode code="'''$TXA.20 [20]'''"/>
44					<recordTarget>
45						<patient>
46							<id root="'''$OID($MSH.3,$MSH.4,Patient)'''" 
								  extension="'''$PID.3'''"/>
47							<statusCode code="normal"/>
48							<patientPerson>
49								<name use="'''$PID.5.7 [9]'''">
50									<family qualifier="'''$PID.5.7 [10]'''">'''$PID.5.1'''</family>
51									<given>'''$PID.5.2'''</given>
52									<prefix>'''$PID.5.5'''</prefix>
53									<suffix>'''$PID.5.4'''</suffix>
54								</name>	
55							</patientPerson>
56						</patient>
57					</recordTarget>
58					<!-- Author is required in HL7 v3. 
							Use nullFlavor if not present in $TXA.9, 
							otherwise at least the ID should be included  -->
59					<author>
60						<time value="'''$TXA.6'''"/>
61						<assignedAuthor>	
62							<id root="'''$OID($MSH.4,Person)'''" extension="'''$TXA.9.1'''"/>
63							<assignedPerson>
64								<name>	
65									<family>'''$TXA.9.2'''</family>
66									<given>'''$TXA.9.3'''</given>
67									<prefix>'''$TXA.9.6'''</prefix>
68									<suffix>'''$TXA.9.5'''</suffix>
69								</name>
70							</assignedPerson>
71							<representedOrganization>
72								<id root="'''$OID($MSH.4,Organization)'''" 
									  extension="'''$TXA.9.14'''"/>
73							</representedOrganization>
74						</assignedAuthor>
75					</author>	
76					<custodian>
77						<assignedCustodian>
78							<representedOrganization>
79								<id root="'''$OID($MSH.4,Organization)'''" 
									  extension="'''$EVN.7.1'''"/>
80							</representedOrganization>
81						</assignedCustodian>
82					</custodian>
83					<authenticator>
84						<time value="'''$TXA.22.15'''"/>
85						<assignedPerson>	
86							<assignedPerson>
87								<name>	
88									<family>'''$TXA.22.2'''</family>
89									<given>'''$TXA.22.3'''</given>
90									<prefix>'''$TXA.22.6'''</prefix>
91									<suffix>'''$TXA.22.5'''</suffix>
92								</name>
93							</assignedPerson>
94						</assignedPerson>
95					</authenticator>
96					<!-- Optional, Skip if no OBR segment is given -->
97					<documentationOf>
98						<event>
99							<id root="$'''OID($MSH.4,Organization)'''" 
								  extension="'''$OBR.3?'''"/>
100							<code code="'''$OBR.4'''" codeSystem="$OID(const)" />
101						</event>
102					</documentationOf>
103					<!-- Conditional: only with RPLC, APND interaction -->
104						<relatedDocument typeCode="'''$MSH.9 [35]'''">
105							<parentDocument>
106								<id root="$'''OID($MSH.3,$MSH.4,Document)'''" 
										extension="'''$TXA.13'''"/>
107								<statusCode code="obsolete"/>
108							</parentDocument>
109						</relatedDocument> 
110					<!-- Optional: use if document can be associated 
							with an encounter -->
111					<componentOf>
112						<encounterEvent>
113							<id root="'''$OID($MSH.3,$MSH.4,Encounter)'''" 
									extension="'''$PV1.19'''"/>
114							<effectiveTime>
115								<low value="'''$PV1.44'''"/>
116							</effectiveTime>
117							<encounterPerformer>
118								<assignedPerson>
119									<representedOrganization>
120										<id root="'''$OID($MSH.4,Organization)'''" 
											extension="'''$EVN.7.1'''"/>
121									</representedOrganization>
122								</assignedPerson>
123							</encounterPerformer>
124						</encounterEvent>
125					</componentOf>
126				</clinicalDocument>
127			</subject>
128		</controlActProcess>
129	</RCMR_IN000001UV01>

60. Beispielnachricht mit Mapping (T02)

Nachfolgend ist eine HL7 V3-Nachricht aufgeführt, die anstelle der Werte Informationen zum Mapping auf HL7 v2.5 (T02) enthält:

1	<?xml version="1.0" encoding="UTF-8"?>
2	<!--Sample XML file generated by XMLSpy v2005 rel. 3 U (http://www.altova.com)-->
3	<RCMR_IN000002UV01 
					xmlns="urn:hl7-org:v3" 
					xmlns:mif="urn:hl7-org:v3/mif" 
					xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
			xsi:schemaLocation="urn:hl7-org:v3 ..\xsd\RCMR_IN000002UV01.xsd" 
					ITSVersion="XML_1.0">
4		<id root="'''$OID($MSH.3,$MSH.4,Message)'''" extension="'''$MSH.10'''" />
5		<creationTime value="'''$MSH.7'''"/>
6		<versionCode code="V3-2006-06"/>
7		<interactionId root="2.16.840.1.113883" extension="'''$MSH.9 [1]'''"/>
8		<processingCode code="'''$MSH.11 [2]'''"/>
9		<processingModeCode code="T"/>
10		<acceptAckCode code="'''$MSH.15 [3]'''"/>
11		<receiver>
12			<device>
13				<id root="'''$OID(const)'''" />
14			</device>
15		</receiver>
16		<sender>
17			<device>
18				<id root="'''$OID($MSH.3,$MSH.4,Device)'''"/>
19				<agencyFor>
20					<representedOrganization>
21						<id root="'''$OID($MSH.4,Organization)'''"/>
22					</representedOrganization>
23				</agencyFor>
24			</device>
25		</sender>
26		<controlActProcess moodCode="EVN">
27			<subject>
28				<clinicalDocument>
29					<id root="'''$OID($MSH.3,$MSH.4,Document)'''" 
							extension="'''$TXA.12.1'''"/>
30					<code code="'''$TXA.2 [16]'''" codeSystem="'''$OID(const)'''"/>
31					<text representation="$OBX.5.4 [33]" 
								mediaType="'''$TXA.3'''" 
								encoding="'''$MSH.18 [34]'''" 
								integrityCheck="'''$TXA.12.3'''" 
								integrityCheckAlgorithm="'''$TXA.12.4'''">
32						<reference value="'''$TXA.16'''"/>
33						'''$OBX.5.5'''
34					</text>
35					<statusCode code="'''$TXA.19 [17]'''"
									  codeSystem="2.16.840.1.113883.5.14"/>
36					<effectiveTime value="'''$TXA.6'''"/>
37					<availabilityTime value="'''$TXA.22.15'''"/>
38					<!-- Required for status change, replace and nullify. 
							Use nullFlavor if not present anyway -->
39					<reasonCode>
40						<text>'''$TXA.21'''</text>
41					</reasonCode>
42					<confidentialityCode code="'''$TXA.18 [18]'''" 
											codeSystem="2.16.840.1.113883.5.25"/>
43					<completionCode code="'''$TXA.17 [19]'''"/>
44					<storageCode code="'''$TXA.20 [20]'''"/>
45					<recordTarget>
46						<patient>
47							<id root="'''$OID($MSH.3,$MSH.4,Patient)'''" 
									extension="'''$PID.3'''"/>
48							<statusCode code="normal"/>
49							<patientPerson>
50								<name use="'''$PID.5.7 [9]'''">
51									<family qualifier="'''$PID.5.7 [10]'''">'''$PID.5.1'''</family>
52									<given>'''$PID.5.2'''</given>
53									<prefix>'''$PID.5.5'''</prefix>
54									<suffix>'''$PID.5.4'''</suffix>
55								</name>
56							</patientPerson>
57						</patient>
58					</recordTarget>
59					<!-- Author is required in HL7 v3. 
							Use nullFlavor if not present in $TXA.9, 
							otherwise at least the ID should be included  -->
60					<author>
61						<time value="'''$TXA.6'''"/>
62						<assignedAuthor>
63							<id root="'''$OID($MSH.4,Person)'''" extension="'''$TXA.9.1'''"/>
64							<assignedPerson>
65								<name>	
66									<family>'''$TXA.9.2'''</family>
67									<given>'''$TXA.9.3'''</given>
68									<prefix>'''$TXA.9.6'''</prefix>
69									<suffix>'''$TXA.9.5'''</suffix>
70								</name>
71							</assignedPerson>
72							<representedOrganization>
73								<id root="'''$OID($MSH.4,Organization)'''" 
											extension="'''$TXA.9.14'''"/>
74							</representedOrganization>
75						</assignedAuthor>
76					</author>
77					<custodian>
78						<assignedCustodian>
79							<representedOrganization>
80								<id root="'''$OID($MSH.4,Organization)'''" 
										extension="'''$EVN.7.1'''"/>
81							</representedOrganization>
82						</assignedCustodian>
83					</custodian>
84					<authenticator>
85						<time value="'''$TXA.22.15'''"/>
86						<assignedPerson>
87							<assignedPerson>
88								<name>
89									<family>'''$TXA.22.2'''</family>
90									<given>'''$TXA.22.3'''</given>
91									<prefix>'''$TXA.22.6'''</prefix>
92									<suffix>'''$TXA.22.5'''</suffix>
93								</name>
94							</assignedPerson>
95						</assignedPerson>
96					</authenticator>
97					<!-- Optional, Skip if no OBR segment is given -->
98					<documentationOf>
99						<event>
100							<id root="$'''OID($MSH.4,Organization)'''" 
									extension="'''$OBR.3?'''"/>
101							<code code="'''$OBR.4'''" codeSystem="$OID(const)" />
102						</event>
103					</documentationOf>
104					<!-- Conditional: only with RPLC, APND interaction -->
105					<relatedDocument typeCode="'''$MSH.9 [35]'''">
106						<parentDocument>
107							<id root="$'''OID($MSH.3,$MSH.4,Document)'''" 
									extension="'''$TXA.13'''"/>
108							<statusCode code="obsolete"/>
109						</parentDocument>
110					</relatedDocument> 
111					<!-- Optional: use if document can be associated with an 
							encounter -->
112					<componentOf>
113						<encounterEvent>
114							<id root="'''$OID($MSH.3,$MSH.4,Encounter)'''" 
								  extension="'''$PV1.19'''"/>
115							<effectiveTime>
116								<low value="'''$PV1.44'''"/>
117							</effectiveTime>
118							<encounterPerformer>
119								<assignedPerson>
120									<representedOrganization>
121										<id root="'''$OID($MSH.4,Organization)'''" 
											extension="'''$EVN.7.1'''"/>
122									</representedOrganization>
123								</assignedPerson>
124							</encounterPerformer>
125						</encounterEvent>
126					</componentOf>
127				</clinicalDocument>
128			</subject>
129		</controlActProcess>
130	</RCMR_IN000002UV01>

61. XPath-Mapping

Die XPath-Ausdrücke adressieren ein einzelnes Element innerhalb der XML-Nachricht. Die Ziffern in der dritten Spalte weisen auf ein Mapping hin, da die Werte nicht direkt übernommen werden können. Die entsprechenden Informationen befinden sich in der nachfolgend aufgelisteten Tabelle.

HL7v2	HL7v3 (XPath)	Mapping/Table
MSH-3	/\*/id/@root	$OID($MSH.3,$MSH.4, Message)
	/\*/sender/device/id/@root	$OID($MSH.3,$MSH.4, Device)
	//clinicalDocument/id/@root	$OID($MSH.3,$MSH.4, Document)
	//clinicalDocument/recordTarget/patient/ id/@root	$OID($MSH.3,$MSH.4, Patient)
	//clinicalDocument/relatedDocument/ parentDocument/id/@root	$OID($MSH.3,$MSH.4, Document)
	//encounterEvent/id/@root	$OID($MSH.3,$MSH.4, Encounter)
MSH-4	/\*/id/@root	$OID($MSH.3,$MSH.4, Message)
	/\*/sender/device/id/@root	$OID($MSH.3,$MSH.4, Device)
	/\*/sender/device/representedOrganization/ id/@root	$OID($MSH.4, Organization)
	//clinicalDocument/id/@root	$OID($MSH.3,$MSH.4, Document)
	//clinicalDocument/recordTarget/patient/ id/@root	$OID($MSH.3,$MSH.4, Patient)
	//clinicalDocument/author/assignedAuthor/ id/@root	$OID($MSH.4, Person)
	//clinicalDocument/author/assignedAuthor/ representedOrganization/id/@root	$OID($MSH.4, Organization)
	//clinicalDocument/custodian/assignedCustodian/ representedOrganization/id/@root	$OID($MSH.4, Organization)
	//clinicalDocument/documentationOf/event/ id/@root	$OID($MSH.4, Organization)
	//clinicalDocument/relatedDocument/ parentDocument/id/@root	$OID($MSH.3,$MSH.4, Document)
	//encounterEvent/id/@root	$OID($MSH.3,$MSH.4, Encounter)
	//encounterEvent/encounterPerformer/ assignedPerson/representedOrganization/id/@root	$OID($MSH.4, Organization)
MSH-7	/\*/creationTime/@value
MSH-9	/\*/interactionId/@extension
	//clinicalDocument/relatedDocument/@typeCode	35
MSH-10	/\*/id/@extension	1
MSH-11	/\*/processingCode/@code	2
MSH-15	/\*/acceptAckCode/@code	3
MSH-18	//clinicalDocument/text/@encoding	34
EVN-7.1	//clinicalDocument/custodian/assignedCustodian/ representedOrganization/id/@extension
	//encounterEvent/encounterPerformer/ assignedPerson/representedOrganization/ id@extension
PID-3	//clinicalDocument/recordTarget/patient/ id/@extension
PID-5.1	//patientPerson/name/family
PID-5.2	//patientPerson/name/given
PID-5.4	//patientPerson/name/suffix
PID-5.5	//patientPerson/name/prefix
PID-5.7	//patientPerson/name/@use	9
PID-5.7	//patientPerson/name/@qualifier	10
PID-7	//patientPerson/birthTime
PID-8	//patientPerson/person/ administrativeGenderCode
PID-11	//recordTarget/patient/addr
PV1-3	//encounterEvent/location/healthCareFacility/id
PV1-19	//encounterEvent/id/@extension
PV1-44	//encounterEvent/effectiveTime/low/@value
PV1-45	//encounterEvent/effectiveTime/high/@value
TXA-2	//clinicalDocument/code
TXA-3	//clinicalDocument/text/@mediaType
TXA-4
TXA-5
TXA-6	//clinicalDocument/effectiveTime/@value
	//clinicalDocument/author/time/@value
TXA-9.1	//clinicalDocument/author/assignedAuthor/id/ @extension
TXA-9.2	//clinicalDocument/author/assignedAuthor/ assignedPerson/name/family
TXA-9.3	//clinicalDocument/author/assignedAuthor/ assignedPerson/name/given
TXA-9.5	//clinicalDocument/author/assignedAuthor/ assignedPerson/name/suffix
TXA-9.6	//clinicalDocument/author/assignedAuthor/ assignedPerson/name/prefix
TXA-9.10	//clinicalDocument/author/assignedAuthor/ assignedPerson/name/@use	9
TXA-9.10	//clinicalDocument/author/assignedAuthor/ assignedPerson/name/@qualifier	9
TXA-9.14	//clinicalDocument/author/assignedAuthor/ representedOrganization/id/@extension
TXA-12.1	//clinicalDocument/id
TXA-12.3	//clinicalDocument/text/@integrityCheck
TXA-12.4	//clinicalDocument/text/ @integrityCheckAlgorithm
TXA-13	//clinicalDocument/relatedDocument/ parentDocument/ id@extension
TXA-16	//clinicalDocument/text/reference/@value
TXA-17	//clinicalDocument/completionCode/@code	19
TXA-18	//clinicalDocument/confidentialityCode/@code	18
TXA-19	//clinicalDocument/statusCode/@code	17
TXA-20	//clinicalDocument/storageCode/@code	20
TXA-21	//clinicalDocument/reasonCode/@text
TXA-22.2	//clinicalDocument/authenticator/ assignedPerson/assignedPerson/name/family
TXA-22.3	//clinicalDocument/authenticator/ assignedPerson/assignedPerson/name/given
TXA-22.5	//clinicalDocument/authenticator/ assignedPerson/assignedPerson/name/suffix
TXA-22.6	//clinicalDocument/authenticator/ assignedPerson/assignedPerson/name/prefix
TXA-22.10	//clinicalDocument/authenticator/ assignedPerson/assignedPerson/name/@use	9
TXA-22.10	//clinicalDocument/authenticator/ assignedPerson/assignedPerson/name/@qualifier	9
TXA-22.15	//clinicalDocument/availabilityTime/@value
	//clinicalDocument/authenticator/time/@value
OBX-5.4	//clinicalDocument/text/@representation	33 (RCMR_MT000002 only)
OBX-5.5	//clinicalDocument/text	(RCMR_MT000002 only)
OBR-3	//clinicalDocument/documentationOf/event/id/ @extension
OBR-4	//clinicalDocument/documentationOf/event/code/ @code

Functions

$OID(Field, Field, …, Domain)	Look up an OID for a specific domain based on the given fields. Can be an OID for an organization of a device, or an OID for IDs issued by a device

62. Mapping-Tabellen

Nicht jede Information lässt sich direkt umsetzen. Teilweise ist eine wert- und kontextabhängige Umsetzung vorzunehmen.

[1]
Tabelle HL70076	Tabelle HL70003	InteractionID	Description
MDM	T01	RCMR_IN000001	Document Registration
MDM	T02	RCMR_IN000002	Document Registration with Content
MDM	T03	RCMR_IN000005	Document Status Change
MDM	T04	RCMR_IN000006	Document Status Change with Content
MDM	T05	RCMR_IN000007	Document Addendum
MDM	T06	RCMR_IN000008	Document Addendum with Content
MDM	T07	RCMR_IN000011	Document Edit
MDM	T08	RCMR_IN000012	Document Edit with Content
MDM	T09	RCMR_IN000015	Document Replacement
MDM	T10	RCMR_IN000016	Document Replacement with Content
MDM	T11	RCMR_IN000019	Document Cancel

[2]
Tabelle HL70103		ProcessingCode	Description
D		D	Debugging (Test)
P		P	Production (Betrieb)
T		T	Training (Schulung)

[3]
Tabelle HL70155		AcceptAckCode	Description
AL		AL	Always (immer)
ER		ER	Error/reject conditions only (nur im Fehlerfall)
NE		NE	Never (nie)

[9]
Tabelle HL70200		Domain EntityNameUse	Description
L		L	Legal Name
K		A	Künstlername
O		R	Ordensname
I		C	Licensing

[10]
Tabelle HL70200		DomainEntityName PartQualifier	Description
N		CL	Spitzname
B		BR	Geburtsname
C		AD	angenommener Name
M		SP	Mädchenname (Name vor Hochzeit)
A			Alias Name
U			nicht näher spezifiziert
S			beliebiger Name zur Anonymisierung
D			Display Name


[16]
Tabelle HL70270		LOINC
…			Die Umsetzung von Dokumenttypen auf ein externes Codesystem wie z.B. LOINC ist nicht Gegenstand dieses Leitfadens, sondern muss im Rahmen des konkreten Einsatzes des Profils abgestimmt werden.

[17]
Tabelle HL70273		x_DocumentStatus	Description
UN		new	Unavailable/Preparatory stages (Noch nicht freigegeben für die Patienten¬behandlung)
AV		active	Available for patient care (Freigegeben für die Patientenbehandlung)
CA		nullified	Deleted (gelöscht)
OB		obsolete	Obsolete (veraltet)

[18]
Tabelle HL70272		x_Basic Confidentiality Kind	Description
R		R	Restricted (Zugriff beschränkt)
U		N	Usual control (normale Zugriffskontrolle)
V		V	Very restricted (Zugriff sehr beschränkt)

[19]
Tabelle HL70271		Document Completion	Description
IP		IP	In Progress
PA		PA	Pre-Authenticated (Vorabfreigabe)
AU		AU	Authenticated (Bestätigt)
LA		LA	Legally authenticated (Rechtlich bestätigt)

[20]
Tabelle HL70275		DocumentStorage	Description
AC		AC	Active (Das Dokument ist nicht persistent gespeichert.)
AR		AR	Archived (Das Dokument ist persistent gespeichert.)
AA		AA	Active and Archived
PU		PU	Purged

[33]
Tabelle HL70301		Value	Description
text/plain		text/plain	MIME type text, Subtype plain text, default character set will be used
text/plain; charset=ASCII		text/plain	MIME type text, Subtype plain text, Character set 7 bit US ASCII (ANSI X3.4)
text/plain; charset=ISO-8859-1		text/plain	MIME type text, Subtype plain text, Character set Latin Alphabet No. 1, ISO 8859-1:1998, 1st ed.
text/plain; charset=UTF-8		text/plain	MIME type text, Subtype plain text, Character set Unicode UTF-8 (backwards compatible to US-ASCII)
text/html		text/html	MIME type text, Subtype HTML
text/xml		text/xml	MIME type text, Subtype XML
image/gif		image/gif	MIME type image, Subtype GIF
image/jpeg		image/jpeg	MIME type image, Subtype JPEG
image/png		image/png	MIME type image, Subtype PNG
application/pdf		application/pdf	MIME type application, Subtype PDF

[34]
Tabelle HL70299		Value	Description
Base64		B64	Character Encoding with Base64

[35]
Tabelle HL70076	Tabelle HL70003	Value	Description
MDM	T05	APND	Append
MDM	T06	APND	Append
MDM	T09	RPLC	Replace
MDM	T10	RPLC	Replace

63. Anhang B: Mapping auf IHE XDS

Dieser Anhang ist nicht normativ.

Für den Austausch klinischer Dokumente beschreibt die Initiative "Integrating the Healthcare Enterprise" (IHE) im Rahmen ihres "IT Infrastructure Technical Framework" (ITI) das Integrationsprofil "Cross-Enterprise Document Sharing" (XDS.b). Dieses Profil setzt auf dem Standard ebXML Registry auf und verwendet u.a. SOAP für den Datenaustausch. Das Profil zielt insbesondere auf den Dokumentenaustausch außerhalb der Bereiche, in denen bisher HL7-v2 zur Kommunikation eingesetzt wurde – etwa für die intersektorale Kommunikation oder für das Dokumentenmanagement im Rahmen der integrierten Versorgung. Akteure und Transaktionen sind den im vorliegenden Profil beschriebenen eng verwandt (vgl. Kap. 2).

Wie oben bei HL7 v3 / CDA beschrieben, kann auch hier ein Mapping definiert werden zwischen XDS.b und HL7 v2 MDM für die Metadaten zur einheitlichen Beschreibung und Indexierung von Dokumenten. Ein entsprechendes Mapping zwischen XDS und CDA Header Daten findet sich im Dokument "IHE IT Infrastructure Technical Framework, vol. 2x (ITI TF-2x): Volume 2 Appendices, Revision 8.0, August 19, 2011" im Appendix L, S. 54.

Ebenso wie die im vorliegenden Profil beschriebenen Transaktionen ist auch XDS inhaltsneutral ("content neutral"), d.h. es findet keine Validierung der übermittelten Dokumente statt. Die Transaktionen verwenden nur die zu einem Dokument übermittelten Metadaten.

64. Mapping der Transaktionen

HL7 Event	IHE Transaktion	Kommentar
T01: Original document notification	ITI-42 Register document set .b
T02: Original document notification and content	ITI-41 Provide and register document set .b
T03: Document status change notification	ITI-57 Update Document Set
T04: Document status change notification and content	-
T05: Document addendum notification	ITI-42 Register document set .b w/ APND
T06: Document addendum notification and content	ITI-41 Provide and register document set .b w/ APND
T07: Document edit notification	-
T08: Document edit notification and content	-
T09: Document replacement notification	ITI-42 Register document set .b w/ RPLC
T10: Document replacement notification and content	ITI-41 Provide and register document set .b w/ RPLC
T11: Document cancel notification	ITI-62 Delete Document Set
T12: Document Query	???

65. Mapping der Elemente

Entry Type: D=document, S=submission set, F=folder
XDS.b Attribute:
DataType:
Optionality: R = Required, R2= Required if Known, O = Optional, P= Registry not required to support this in a query, Cp = Computed/Assigned by Repository, required in register transaction., Cg = Computed/Assigned by Registry, Cx= Optionally Computed/Assigned by a Document Registry. See ITI-TF, Rev. 6, Vol. 3, Table 4.1-4.
Example: example of the request payload (ebXML)
Data Item Origin: <in/out>.<path> (<usage>), e. g. „in.TXA-9 (RE)" means that the data item originates from the field „TXA-9" of the input, having usage „RE" (required but may be empty)

Entry Type	XDS.b Attri¬bute	DT	Op¬tio-na¬lity	Example	Descrip¬tion	Data Item Origin
D, S	Author	\*	R2/R2	<rim:Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" classifiedObject="theDocument" nodeRepresentation=""> <!-- nodeRepresentation intentionally left blank --> <rim:Slot name="authorPerson"> <!-- shall be single valued --> <rim:ValueList> <rim:Value>name of author</rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="authorInstitution"> <!-- may be multivalued --> <rim:ValueList> <rim:Value> Some Hospital^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45</rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="authorRole"> <!-- may be multivalued --> <rim:ValueList> <rim:Value>name of role</rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="authorSpecialty"> <!-- may be multivalued --> <rim:ValueList> <rim:Value>specialty of author</rim:Value> </rim:ValueList> </rim:Slot> </rim:Classification>		in.TXA-9 (R), see also below
D, S	authorInstitution	XON	R2/R	<see above>	XON-1, XON-10	in.TXA-9-14-1 (RE), in.TXA-9-14-2 (RE), in.TXA-9-14-3 (RE); see parameter mdm.originator.assigningFacility.firstComponentAsAssigningAuthority
D, S	authorPerson	XCN	R2/R	<see above>	XCN-1, XCN-2 , XCN-3 , XCN-4 , XCN-5, XCN-6, XCN-9-2 XCN-9-3	in.TXA-9-1 (RE), in.TXA-9-2 (RE), in.TXA-9-3 (RE), in.TXA-9-4 (RE), in.TXA-9-5 (RE), in.TXA-9-6 (RE), in.TXA-9-9-2(RE), in.TXA-9-9-3 (RE)
D,S	authorRole	-	R2/O	<see above>		Parameter xdsb.authorRole.default
D, S	authorSpecialty	-	R2/O	<see above>		Parameter xdsb.authorSpecialty.default
D	availabilityStatus	-	Cg/R	Deprecated Approved\|\|\|\|in.TXA-19 w/ mapping „availabilityStatus-availabilityStatus"; see also Table HL70273
S, F	availabilityStatus	-	Cg/R	Submitted Approved\|\|\|\|<automatically assigned>
D	classCode	-	R/R	<rim:Classification classificationScheme= "urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" classifiedObject="theDocument" nodeRepresentation="classCode" > <rim:Name> <rim:LocalizedString value="classCodeDisplayName"/> </rim:Name> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>XDS Affinity Domain Specific Value</rim:Value> </rim:ValueList> </rim:Slot> </rim:Classification>	Domain specific Vocab. Mapping	in.TXA-2 (R) w/ mapping „documentType-classCode"; see also Table HL70270
D	classCode DisplayName	-	R/P	<see above>	Domain specific	out.classCode w/ mapping „classCode-classCodeDisplayName"
F	codeList		R/R	<rim:Classification classificationScheme= "urn:uuid:1ba97051-7806-41a8-a48b-8fce7af683c5" classifiedObject="Folder" nodeRepresentation="codeList" > <rim:Name> <rim:LocalizedString value="codeListCodeDisplayName" /> </rim:Name> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>XDS Affinity Domain Specific Value</rim:Value> </rim:ValueList> </rim:Slot> </rim:Classification>	Multi valued Domain specific; list of codes specifying the type of clinical activity that resulted in placing these XDS Documents in this XDSFolder. These values are to be drawn for a vocabulary or coding scheme defined by the Clinical XDS Affinity Domain. When a new submission request associates XDS Documents (new submission or previously submitted) to an XDS Folder, the Code included in the codeList is appended to the existing list of codes for this Folder (if any) unless this code is already present in the list managed by the Registry for the same XDS-Folder\|\|in.PV1-2 w/ mapping „patientClass-CodeList"; see also Table HL70004
F	codeList DisplayName		R/P	<see above>		out.codeList w/ mapping „codeList-codeListDisplayName"
D, F	comments	-	O/P	<rim:Description> <rim:LocalizedString value = "comments"/> </rim:Description>	Domain specific	N/A
S	comments	-	O/P	<rim:Description> <rim:LocalizedString value = "comments"/> </rim:Description>	Domain specific	N/A
D	confidentialityCode	-	R/P	<rim:Classification classificationScheme= "urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="theDocument" nodeRepresentation="confidentialityCode"> <rim:Name> <rim:LocalizedString value="displayName"/> </rim:Name> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>XDS Affinity Domain Specific Value</rim:Value> </rim:ValueList> </rim:Slot> </rim:Classification>	Domain specific	in.TXA-18-1 (R) w/ mapping „documentConfidentialityStatus-confidentialityCode"; see also Table HL70272
S	contentTypeCode		R/R	<rim:Classification classificationScheme= "urn:uuid:aa543740-bdda-424e-8c96-df4873be8500" classifiedObject="submissionSet" nodeRepresentation="contentTypeCode" > <rim:Name> <rim:LocalizedString value="contentTypeCodeDisplayName" /> </rim:Name> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>XDS Affinity Domain Specific Value </rim:Value> </rim:ValueList> </rim:Slot> </rim:Classification>	Domain specific; code specifying the type of clinical activity that resulted in placing these XDS Documents in this XDS-Submission Set	in.EVN-4 w/ mapping „eventReasonCode-contentTypeCode"; See also Table HL70062.
S	contentTypeCode DisplayName		R/P	<see above>	Domain specific;	out.contentTypeCode w/ mapping „contentTypeCode- contentTypeCodeDisplayName"
D, F	entryUUID	UUID	Cg/P	<rim:ExtrinsicObject mimeType="application/pdf" id="urn:uuid:a6e06ca8-0c75-4064-9e5c-88b9045a96f6" objectType= "urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" > ...		<automatically assigned>
S	entryUUID	UUID	Cg/O	<rim:ExtrinsicObject mimeType="application/pdf" id="urn:uuid:a6e06ca8-0c75-4064-9e5c-88b9045a96f6" objectType= "urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" > …\|\|\|\|<automatically assigned>
D	eventCodeList	-	O/R	<rim:Classification classificationScheme= "urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4" classifiedObject="theDocument" nodeRepresentation="eventCode" > <rim:Name> <rim:LocalizedString value="eventCodeDisplayName"/> </rim:Name> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>XDS Affinity Domain Specific Value</rim:Value> </rim:ValueList> </rim:Slot> </rim:Classification>	Domain specific; represents the main clinical acts, such as a colonoscopy or an appendectomy, being documented. In some cases, the event is inherent in the typeCode, such as a "History and Physical Report" in which the procedure being documented is necessarily a "History and Physical" act. An event can further specialize the act inherent in the typeCode, such as where it is simply "Procedure Report" and the procedure was a "colonoscopy". If one or more eventCodes are included, they shall not conflict with the values inherent in the classCode, practiceSettingCode or typeCode, as such a conflict would create an ambiguous situation.\|\|in.TXA-2 (R) w/ mapping „documentType-eventCodeList"; see also Table HL70270
D	eventCodeList DisplayName		O/P	<see above>	Domain specific	out.eventCodeListw/ mapping „eventCodeList-eventCodeListDisplayName"
D	formatCode		R/R	<rim:Classification classificationScheme= "urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" classifiedObject="theDocument" nodeRepresentation="formatCode" > <rim:Name> <rim:LocalizedString value="name"/> </rim:Name> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>XDS Affinity Domain Specific Value</rim:Value> </rim:ValueList> </rim:Slot> </rim:Classification>	ITI or Domain specific\|\|(TXA-2 (R) + OBX-5-2 (R) + OBX-5-3 (R) ) w/ mapping „documentType_typeOfDate_dataSubtype-formatCode"
D	hash	SHA1	Cp/P	<rim:Slot name="hash"> <rim:ValueList> <rim:Value> da39a3ee5e6b4b0d3255bfef95601890afd80709 </rim:Value> </rim:ValueList> </rim:Slot>		<automaticall assigned>
D	healthcareFacility TypeCode		R/R	<rim:Classification classificationScheme= "urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" classifiedObject="theDocument" nodeRepresentation="healthcareFacilityTypeCode" > <rim:Name> <rim:LocalizedString value="healthcareFacilityTypeCodeDisplayName"/> </rim:Name> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>XDS Affinity Domain Specific Value</rim:Value> </rim:ValueList> </rim:Slot> </rim:Classification>	Domain specific; the type of organizational setting of the clinical encounter during which the documented act occurred\|\|(EVN-7 transformed using mdm.eventFacility. firstComponentAsAssigningAuthority) w/ mapping „eventFacility-healthcareFacilityTypeCode"
D	healthcareFacility TypeCode DisplayName		R/P	<see above>	Domain specific	out. healthcareFacility TypeCode w/ mapping „healthcareFacility TypeCode- healthcareFacility TypeCodeDisplayName"
D, S	homeCommunityId	64 char OID as URI	Cx/O			<automatically assigned>
S	intendedRecipient	XON/ XCN	O/O	<rim:Slot name="intendedRecipient"> <rim:ValueList> <rim:Value> Some Hospital^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45\|^Wel^Marcus^^^Dr^MD</rim:Value> <rim:Value> Some Hospital^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45\|^Al^Peter^^^Dr^MD</rim:Value> <rim:Value>\|12345^John^Smith^^^Dr^MD</rim:Value> <rim:Value>Main Hospital^^^^^^^^^1.2.3.4.5.6.7.8.9.	organization(s) or person(s) for whom the Submission set is intended	<N/A>
D, S, F	languageCode		R/P	<rim:Slot name="languageCode"> <rim:ValueList> <rim:Value>en-us</rim:Value> </rim:ValueList> </rim:Slot>		parameter xdsb.languageCode.default
F	lastUpdateTime	DTM	Cg/R	<rim:Slot name="lastUpdateTime"> <rim:ValueList> <rim:Value>20041225212010</rim:Value> </rim:ValueList> </rim:Slot>		<automatically assigned>
D, S, F	legalAuthenticator	XCN	O/O	<rim:Slot name="legalAuthenticator"> <rim:ValueList> <rim:Value>^Welby^Marcus^^^Dr^MD</rim:Value> </rim:ValueList> </rim:Slot>	XCN-1, XCN-2 , XCN-3 , XCN-4 , XCN-5, XCN-6, XCN-9-2 XCN-9-3\|\|in.TXA-22-1 (RE), in.TXA-22-2 (CE), in.TXA-22-3 (CE), in.TXA-22-4 (CE), in.TXA-22-5 (CE), in.TXA-22-6 (CE), in.TXA-22-9-2 (CE), in.TXA-22-9-3 (CE)
L	parentDocument ReationshipCode		O/P	urn:ihe:iti:2007:AssociationType:RPLC urn:ihe:iti:2007:AssociationType:XFRM urn:ihe:iti:2007:AssociationType:APND urn:ihe:iti:2007:AssociationType:XFRM_RPLC \|\| \|\|input.MSH-9-2, hardcoded mapping T06 -> APND T08 -> RPLC
D	mimeType		R/P	<rim:ExtrinsicObject mimeType="application/pdf" id="theDocument" objectType= "urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" > ...		(OBX-5-2 (R) w/ mapping „typeOfData-mimeTypePrefix") + (OBX-5-3 (R) in lower case and prepended with „/"); see also Table HL70191; see also Table HL70291
D, S, F	patientId	CX	R/R			PID-3 (R)
D	practiceSetting Code		R/R	<rim:Classification classificationScheme= "urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" classifiedObject="theDocument" nodeRepresentation="practiceSettingCode" > <rim:Name> <rim:LocalizedString value="practiceSettingCodeDisplayName" /> </rim:Name> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>XDS Affinity Domain Specific Value</rim:Value> </rim:ValueList> </rim:Slot> </rim:Classification>	Domain specific; clinical specialty where the act that resulted in the document was performed (e.g. Familly Practice, Laboratory, Radiology). It is suggested that the XDS Affinity Domain draws these values from a coding scheme providing a coarse level of granularity (about 10 to 100 entries); single value.	(EVN-7 transformed using mdm.eventFacility. firstComponentAsAssigningAuthority) + mapping „eventFacility-practiceSettingCode"
D	practiceSetting CodeDisplayName		R/P	<rim:Classification classificationScheme= "urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" classifiedObject="theDocument" nodeRepresentation="practiceSettingCode" > <rim:Name> <rim:LocalizedString value="practiceSettingCodeDisplayName" /> </rim:Name> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>XDS Affinity Domain Specific Value</rim:Value> </rim:ValueList> </rim:Slot> </rim:Classification>	Domain specific;	out.practiceSetting w/ mapping „practiceSetting-practiceSettingDisplayName"
D	repositoryUniqueId		Cp/P	<rim:Slot name="repositoryUniqueId"> <rim:ValueList> <rim:Value>1.3.6.1.4…</rim:Value> </rim:ValueList> </rim:Slot>		<automatically assigned>
D	serviceStartTime	DTM	R2/R	<rim:Slot name="serviceStartTime"> <rim:ValueList> <rim:Value>20041225212010</rim:Value> </rim:ValueList> </rim:Slot>		if (useEncounterDataForServiceTime) in.PV1-44 (RE) else in.TXA-4 (R)
D	serviceStopTime	DTM	R2/R	<rim:Slot name="serviceStopTime"> <rim:ValueList> <rim:Value>20041225232010</rim:Value> </rim:ValueList> </rim:Slot>		if (useEncounterDataForServiceTime) in. PV1-45 (RE) else <nothing>
D, S, F	size	Integer	Cp/P	<rim:Slot name="size"> <rim:ValueList> <rim:Value>3654</rim:Value> </rim:ValueList> </rim:Slot>		<automatically assigned>
S	sourceId	OID	R/R	<rim:ExternalIdentifier identificationScheme= "urn:uuid:554ac39e-e3fe-47fe-b233-965d2a147832" value="1.3.6.1.4.1.21367.2005.3.7" > <rim:Name> <rim:LocalizedString value = "XDSSubmissionSet.sourceId"/>	OID identifying the instance of the Document Source that contributed the Submission Set. When a "broker" is involved in sending submission sets from a collection of client systems, it should use a different source ID for submissions from each separate system to allow for tracking; single value.\|\|(in.EVN-7 transformed using mdm.eventFacility. firstComponentAsAssigningAuthority) w/ mapping „eventFacility-sourceId"
D	sourcePatientId	CX	R/P	<rim:Slot name="sourcePatientId"> <rim:ValueList> <rim:Value>j98789^^^id.domain</rim:Value> </rim:ValueList> </rim:Slot>		in.PID-3 (R)
D	sourcePatientInfo		O/P	<rim:Slot name="sourcePatientInfo"> <rim:ValueList> <rim:Value>PID-3\|DTP-1^^^&1.3.6.1.4.1.21367.2005.3.7&ISO</rim:Value> <rim:Value>PID-5\|DICTAPHONE^ONE^^^</rim:Value> <rim:Value>PID-7\|19650120</rim:Value> <rim:Value>PID-8\|M</rim:Value> <rim:Value>PID-11\|100 Main St^^BURLINGTON^MA^01803^USA</rim:Value> </rim:ValueList> </rim:Slot>	PID-3 should include the source patient identifier. PID-5 should include the patient name. PID-8 should code the patient gender as M – Male F – Female O – Other U – Unknown. PID-7 should include the patient date of birth. PID-11 should include the patient address. PID-2, PID-4, PID-12 and PID-19 should not be used. \|\|in.PID-2 (X), in.PID-3 (RE), in.PID-4 (X), in.PID-5 (RE), in.PID-8 (RE), in.PID-7 (RE), in.PID-11 (RE), in.PID-12 (X), in.PID-19 (X)
S	submissionTime	DTM	R/R	<rim:Slot name="submissionTime"> <rim:ValueList> <rim:Value>20041225212010</rim:Value> </rim:ValueList> </rim:Slot>	no explicit submission sets => identical with document creation time	if xdsb.submissionTime.useSystemTime == true then <use system time> else in.TXA-6;
D, S	title		O/P	<rim:ExtrinsicObject id="theDocument" objectType= "urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" mimeType="application/pdf" > <rim:Name> <rim:LocalizedString value="title"/> </rim:Name> … </rim:ExtrinsicObject>		<N/A>
D	typeCode		R/R	<rim:Classification classificationScheme= "urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" classifiedObject="theDocument" nodeRepresentation="typeCode" > <rim:Name> <rim:LocalizedString value="typeCodeDisplayName" /> </rim:Name> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>XDS Affinity Domain Specific Value</rim:Value> </rim:ValueList> </rim:Slot> </rim:Classification>	Domain specific; precise kind of document (e.g. Pulmonary History and Physical, Discharge Summary, Ultrasound Report); single value\|\|in.TXA-2 (R) w/ mapping „documentType-typeCode"; see also Table HL70270
D	typeCode DisplayName		R/P	<see above>	Domain specific	out.typeCode w/ mapping „typeCode-typeCodeDisplayName"
D	uniqueId	OID	R/R	<rim:ExternalIdentifier identificationScheme= "urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" value="1.3.6.1.4.1.21367.2005.3.7^11379" > <rim:Name> <rim:LocalizedString value="XDSDocumentEntry.uniqueId"/> </rim:Name> </rim:ExternalIdentifier>		if in.TXA-12-1 is a valid OID, then: in.TXA-12-1 (R); else if in.TXA-12-4 equals „ISO" then: in.TXA-12-3 (R) + "^" + in.TXA-12-1 (R); else raise error
F	uniqueId	OID	R/R	<rim:ExternalIdentifier identificationScheme= „urn:uuid:75df8f67-9973-4fbe-a900-df66cefecc5a" value="1.3.6.1.4.1.21367.2005.3.7.3670984664"> <rim:Name> <rim:LocalizedString value = „XDSFolder.uniqueId"/> </rim:Name> </rim:ExternalIdentifier>		implement strategy "prefixed number to oid""
S	uniqueId	OID	R/R			implement strategy "prefixed number to oid""
D	URI	URI	Cp/P	<rim:Slot name="URI"> <rim:ValueList> <rim:Value>1\\|http://www.ihe.net/IHERetrieveDocument? </rim:Value> <rim:Value>2\\|requestType=DOCUMENT&documentUID=1.2.3 </rim:Value> <rim:Value>3\\|&preferredContentType=application%2fpdf </rim:Value> </rim:ValueList> </rim:Slot>		<N/A>

66. Anhang C: Änderungsvorschläge für HL7 v2.7

In diesem Abschnitt werden die Änderungsvorschläge für die nächste HL7 2er Version aufgelistet:

Für die Transformation von Dokumenten (Kap.4.2.3; kompatibel mit HL7 V3 CDA) wird ein neues Eventpaar (T13/T14) benötigt!

(HL7 v2.7 Proposal \#487)

CDA unterstützt die Gruppierung von Dokumenten (set). Dafür haben wir kein passendes Feld in TXA.
TXA-2: Datentyp IS => CWE!

(HL7 v2.7 Proposal \#488)

Dokumenttitel in TXA? => lt. TC nicht notwendig

67. Anhang D: sonstiges

68. Referenzen

HL7 v2.5 Standarddokumente
bisherige Nachrichtenprofile für HL7 v2.5 (Release 2.0)
OID-Konzept
OID-Register: [4]
Spezifikation XPath 1.0: http://www.w3.org/TR/xpath

69. Detaillierte Änderungshistorie

Release	Änderungen gegenüber Vorversion
1.2	Mapping zu XDS.b
1.1	Weiteres Interaktionsprofil wg. eFA
1.0	Vorbereitung Veröffentlichung Zuordnung von OIDs
0.96	Einarbeitung Ballotkommentare
0.95	Vorbereitung Ballot
0.94	Formatierung korrigiert Einarbeitung Kommentare
0.93
0.92
0.91	Überarbeitung Text Korrektur HL7v3 Mapping Überschriftennummerierung
0.9	Einbringung Kommentare aus TC-Sitzung Retrieve Dokument => Profil C Dok. Repository „speichert Dokumente" Stornierung von Dokumenten TXA-12: 2.Komponente in Beispielnachrichten füllen Löschung Nichtkonformanzinformationen
0.8	erweiterte Mapping-Informationen zwischen v2.5 und V3 Mapping zu IHE XDS Prüfung der HL7-Nachrichten diverse kleinere Korrekturen MS-Word als Dokumentenformat zugelassen
0.7	HL7 V3 Nachricht mit Mapping zu v2.5 Use Cases
0.6	Einbau von Kommentaren (CO) Übernahme der Kommentare (keine Markierung über Edit Mode) Datentyp ED, PPN Zuordnung Akteure im Interaktionsdiagramm
0.5	Use-Case: Akteure + Transaktionen Scope-Statement
0.4	Umsetzung der Kommentare in Form einer weiteren Ausarbeitung: Verfeinerung der Felddefinition Erweiterung des Anhanges ...
0.3	Einarbeitung der Kommentare von CG und RB
0.2	Ergänzung um weitere Nachrichten Grobabstimmung mit ICW: Inhalt, Struktur, Vorgehensweise Ausarbeitung der Zuständsübergänge Erste Beispielnachrichten
0.1	Erstellung