deutsche Nachrichtenprofile

Aus Hl7wiki
Nachrichtenprofile
Wechseln zu: Navigation, Suche
Under construction icon-blue.svg
 This article or section is in the middle of an expansion or major restructuring and is not yet ready for use. You are welcome to assist in its construction by editing it as well. If this article has not been edited in several days, please remove this template.
This article was last edited by Foemig (talk| contribs) 10 years ago. (Purge)
Diese Seite oder Abschnitt ist derzeit ein Entwurf und ist noch nicht fertiggestellt. Du bist eingeladen, bei der Fertigstellung mitzuwirken. Wenn dieser Beitrag länger als einige Tage nicht editiert wurde, entferne diese Vorlage.
This article was last edited by Foemig (talk| contribs) 10 years ago. (Purge)
Logo-hl720.jpg
{{{Title}}}
deutsche Nachrichtenprofile
Nachrichtenprofile
vorgelegt von:
HL7-Deutschland
ballotiert
Version: 01
Datum: 20. Dezember 2013
Status: Si-draft.svg Entwurf
Verfahren: {{{Verfahren}}}
Realm: Flag de.svg Deutschland
Copyright © 2013: HL7 Deutschland


Abstimmungsdokument 
Version Datum Status Realm
01 15.08.2013 ballotiert Flag de.svg Deutschland
Document PDF.svg noch kein download verfügbar
Kontributoren 
Logo-Agfa.jpg Agfa HealthCare GmbH Bonn
Logo icw.jpg|100px]] InterComponentWare Walldorf
Logo os.jpg|100px]] Optimal Systems GmbH Berlin
Information icon.svg 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

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:

  1. 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.
  2. 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).
  3. 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:

Mdm akteure.gif

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.

Mdm bearbeitungsstatus.gif

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.

Mdm verfuegbarkeitsstatus.gif

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. Beispiels¬weise 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 Ent¬lassung durch¬gefü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 (storage¬Code = "purged").

Mdm archivierungsstatus.gif

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:

Mdm edit.gif

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:

Mdm addendum.gif

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.

Mdm transform.gif

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 nach¬folgenden 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 Neu¬anlage 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)

Mdm profil a.gif

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.

Mdm profil b.gif

29. Profil C: Interaktionsdiagramm (Anfragen)

Dieses Profil wird derzeit nicht weiter ausgearbeitet.


Mdm profil c.gif

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="3366ff" |[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 Kard. Tab. Data Item DT Länge 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^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;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
Abgerufen von „https://wiki.hl7.de/index.php?title=HL7v2-Profile_MDM-Nachrichten&oldid=16908“