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


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


Dokumentinformation


Inhaltsverzeichnis

Ä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:


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. 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").


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).



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 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 Ver¬wen¬dung 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)

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 |- | bgcolor="3366ff" |[ZBE]|| bgcolor="3366ff" |[0..1]|| bgcolor="3366ff" |O|| bgcolor="3366ff" |Bewegung|| bgcolor="3366ff" |- |- |}


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 |- |}|||||||| |- | bgcolor="3366ff" |[ZBE]|| bgcolor="3366ff" |[0..1]|| bgcolor="3366ff" |O|| bgcolor="3366ff" |Bewegung|| bgcolor="3366ff" |- |- |}

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 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 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 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 59 <author> 60 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 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 97 <documentationOf> 98 <event> 99 <id root="$OID($MSH.4,Organization)" extension="$OBR.3?"/> 100 101 </event> 102 </documentationOf> 103 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 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 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 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 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 60 <author> 61 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 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 98 <documentationOf> 99 <event> 100 <id root="$OID($MSH.4,Organization)" extension="$OBR.3?"/> 101 102 </event> 103 </documentationOf> 104 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 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||bgcolor="ccffff" |XDS.b Attri¬bute||bgcolor="ccffff" |DT||bgcolor="ccffff" |Op¬tio-na¬lity||bgcolor="ccffff" |Example||bgcolor="ccffff" |Descrip¬tion||bgcolor="ccffff" |Data Item Origin

D, S Author \* R2/R2 <rim:Classification

classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" classifiedObject="theDocument" nodeRepresentation=""> <rim:Slot name="authorPerson"> <rim:ValueList> <rim:Value>name of author</rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="authorInstitution"> <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"> <rim:ValueList> <rim:Value>name of role</rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="authorSpecialty"> <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
Abgerufen von „https://wiki.hl7.de/index.php?title=HL7v2-Profile_MDM-Nachrichten&oldid=16776“