HL7 v2 Patienteneinwilligung: Unterschied zwischen den Versionen

Aus Hl7wiki
Wechseln zu: Navigation, Suche
(TXA)
(→‎Use Cases)
 
(7 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
−
== Patienteneinwilligung==
+
= Grundlagen=
 
Es liegt die Anforderung vor, die Informationen zu einer Patienteneinwilligung zu kommunizieren. Hierzu ist erst einmal festzulegen, was unter einer Patienteneinwilligung zu verstehen ist:
 
Es liegt die Anforderung vor, die Informationen zu einer Patienteneinwilligung zu kommunizieren. Hierzu ist erst einmal festzulegen, was unter einer Patienteneinwilligung zu verstehen ist:
  
Zeile 8: Zeile 8:
 
Dies kann auf verschiedene Art und Weise geschehen:
 
Dies kann auf verschiedene Art und Weise geschehen:
  
−
* CON-Segment
+
* Segmente: CON für die Einwilligungserklärung
−
* PMU Nachrichten
+
* Nachrichten: PMU für die Mitarbeiter
−
* BPPC Integration Profile
+
* HL7 V3 CDA Einwilligung: BPPC Integration Profile
 
* ...
 
* ...
  
−
===aktueller Status===
+
=aktueller Status=
−
Diese Spezifikation (=Teil eines Nachrichtenprofils) befindet sich in der Ausarbeitung und stellt derzeit noch nicht den finalen Stand dar!
 
  
−
===Use Cases===
+
{{WorkBox|
 +
Diese Spezifikation (d.h. als Teil eines Nachrichtenprofils) befindet sich in der Ausarbeitung und stellt derzeit noch nicht den finalen Stand dar!
 +
}}
 +
 
 +
==Use Cases==
 
Welche Szenarien gilt es zu unterstützen und welche Informationen sind dazu wichtig/relevant/zu kommunizieren?
 
Welche Szenarien gilt es zu unterstützen und welche Informationen sind dazu wichtig/relevant/zu kommunizieren?
  
 
Hintergrundinformationen dazu sind hier zu [[Hintergrund (Einwilligung)|hier]] finden.
 
Hintergrundinformationen dazu sind hier zu [[Hintergrund (Einwilligung)|hier]] finden.
 +
{{WorkBox|
 +
Eine Evaluierung der Möglichkeit, die Einwilligung zur Datenübermittlung an das Landeskrebsregister mit Hilfe von CON-Segmenten in ADT-Nachrichten abzubilden findet [[Patienteneinwilligung Landeskrebsregister| hier]] statt.
 +
}}
 +
 +
{{WorkBox|
 +
Eine Evaluierung der Möglichkeit, die Einwilligung zur Datenübermittlung an Zuweiserportale mit Hilfe von CON- und ROL-Segmenten in ADT-Nachrichten abzubilden findet [[Patienteneinwilligung Zuweiserpotale| hier]] statt.
 +
}}
  
−
===Informationen===
+
==Informationen==
 
Welche Informationen sind relevant?
 
Welche Informationen sind relevant?
  
Zeile 43: Zeile 53:
 
***per Telefon
 
***per Telefon
  
−
===Segmente für eine Einverständniserklärung===
+
=Mögliche Segmente für eine Einverständniserklärung=
 
Im nachfolgenden werden einige Segmente aufgelistet und beschrieben, die für eine Einverständniserklärung auf verschiedene Art und Weise verwendet werden können:
 
Im nachfolgenden werden einige Segmente aufgelistet und beschrieben, die für eine Einverständniserklärung auf verschiedene Art und Weise verwendet werden können:
  
−
*CON
+
{| class="hl7table"
−
*ARV
+
!Segment
−
*PRT
+
!Beschreibung
−
*ROL
+
!Anmerkung
−
*PRA
+
!Status
 +
 
 +
|-
 +
|PV1
 +
|Fallinformationen
 +
|Hier sind 2 Felder enthalten, die aber eine andere Bedeutung haben.
 +
|unzulässig
 +
 
 +
|-
 +
|CON
 +
|Consent
 +
|Einwilligungserklärung, d.h. zu was; die Beteiligten können nicht dediziert benannt werden; kommt in MDM bereits vor
 +
|möglich
 +
 
 +
|-
 +
|TXA
 +
|Header
 +
|
 +
|ungeeignet
 +
 
 +
|-
 +
|ARV
 +
|Access Restrictions
 +
|Zugriffsbeschränkungen
 +
|möglich
 +
 
 +
|-
 +
|PRT
 +
|Participation (löst ROL ab)
 +
|zur Festlegung der Beteiligten, also auch der Berechtigten; löst in Zukunft das ROL-Segment ab; kommt vor 2.7 nirgends vor
 +
|möglich
 +
 
 +
|-
 +
|ROL
 +
|Rolle
 +
|zur Festlegung der Beteiligten, also auch der Berechtigten; müsste bei MDM hinzudefiniert werden
 +
|möglich
 +
 
 +
|-
 +
|PRA
 +
|Practitioner (Arzt)
 +
|die Berechtigungen eines Arztes werden übermittelt; kommt nicht in MDM vor
 +
|in Abh.v. Nachricht
 +
 
 +
|}
 +
 
 +
==PV1-Segment==
  
−
====CON-Segment Details====
+
IM PV1-Segment sind drei Felder enthalten, die direkt die beteiligten Personen angeben. Das dritte Feld ist veraltet und darf nicht mehr genutzt werden (vgl. Nachrichtenprofile). Für dieses sollte das ROL-Segment genutzt werden.
 +
 
 +
{| class="hl7table"
 +
!Seq
 +
!Description
 +
!German Interpretation
 +
!Length
 +
!Table
 +
!r/o/c
 +
!Rep#
 +
!Item
 +
!Data Structure
 +
!Section
 +
 
 +
|-
 +
|...
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|3.4.3.x
 +
 
 +
|-
 +
|7
 +
|Attending Doctor
 +
|Behandelnder Arzt
 +
|..250
 +
|0010
 +
|O
 +
|Y
 +
|00137
 +
|XCN
 +
|3.4.3.7
 +
 
 +
|-
 +
|8
 +
|Referring Doctor
 +
|Einweisender Arzt
 +
|..250
 +
|0010
 +
|O
 +
|Y
 +
|00138
 +
|XCN
 +
|3.4.3.8
 +
 
 +
|-
 +
|9
 +
|Consulting Doctor
 +
|Mitbehandelnde Ärzte (1 = Hausarzt, 2..n = weitere Ärzte)
 +
|..250
 +
|0010
 +
|B
 +
|Y
 +
|00139
 +
|XCN
 +
|3.4.3.9
 +
 
 +
|-
 +
|...
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|3.4.3.x
 +
 
 +
|}
 +
 
 +
{{NoteBox|Aber auch die beiden anderen Felder sind für die behandelnden und einweisenden Ärzte vorgesehen.<br/>
 +
'''Das sind dann NICHT die BERECHTIGTEN behandelnden und einweisen Ärzte. Eine Nutzung dieser Felder in dieser Form ist NICHT zulässig.''' }}
 +
 
 +
{{AlertBox|
 +
Das Problem bei einer mißbräuchlichen Nutzung dieser Felder sind die bereits existierenden Schnittstellen. Um eine Kompatibilität zur bisherigen Nutzung zu gewährleisten, müsste dieses Segment in einer eigenen Nachricht untergebracht werden. (ITI PAM Z99 ist ein gutes Beispiel hierfür.)
 +
Daher sind diese Felder für diesen Zweck abzulehnen, obwohl es recht praktikabel wäre!
 +
}}
 +
 
 +
 
 +
 
 +
==CON-Segment==
  
 
This segment identifies patient consent information relating to a particular message. It can be used as part of existing messages to convey information about patient consent to procedures, admissions, information release/exchange or other events discussed by the message. It may also be used in messages focusing on recording or requesting consent and for consents related to employees or service providers.
 
This segment identifies patient consent information relating to a particular message. It can be used as part of existing messages to convey information about patient consent to procedures, admissions, information release/exchange or other events discussed by the message. It may also be used in messages focusing on recording or requesting consent and for consents related to employees or service providers.
Zeile 58: Zeile 200:
 
The segment will be used in conjunction with various other segments to identify the practitioner (PRA/STF) or patient (PID) the consent is for, the various individuals involved in the consent (ROL) as witnesses, consenting person (not always the patient), translators, consulting providers, etc., and the specific procedures being proposed (PR1).  
 
The segment will be used in conjunction with various other segments to identify the practitioner (PRA/STF) or patient (PID) the consent is for, the various individuals involved in the consent (ROL) as witnesses, consenting person (not always the patient), translators, consulting providers, etc., and the specific procedures being proposed (PR1).  
  
−
====CON-Segment====
 
  
 
The consent segment provides details about a specific consent by a patient or staff member.  
 
The consent segment provides details about a specific consent by a patient or staff member.  
Zeile 375: Zeile 516:
 
|}
 
|}
  
−
=====CON-2=====
+
====CON-2====
 
Wem oder was wird - als Typ - zugestimmt. Dies ist eine user-defined table und kann somit an beliebige Bedürfnisse angepasst werden.
 
Wem oder was wird - als Typ - zugestimmt. Dies ist eine user-defined table und kann somit an beliebige Bedürfnisse angepasst werden.
 
Auch wenn die aufgeführten Tabellenwerte nicht ganz passen, so ist dies das Feld, in dem die Information eingetragen werden sollte.
 
Auch wenn die aufgeführten Tabellenwerte nicht ganz passen, so ist dies das Feld, in dem die Information eingetragen werden sollte.
Zeile 385: Zeile 526:
 
*..
 
*..
  
−
=====CON-10=====
+
====CON-10====
 
In  welcher Form wurde dem zugestimmt: verbal, schriftlich, per Telefon.
 
In  welcher Form wurde dem zugestimmt: verbal, schriftlich, per Telefon.
  
−
=====CON-11=====
+
====CON-11====
 
In welchem Status befindet sich die Einwilligung, d.h. ist sie noch gültig (aktiv) oder nicht.
 
In welchem Status befindet sich die Einwilligung, d.h. ist sie noch gültig (aktiv) oder nicht.
  
−
=====CON-14=====
+
====CON-14====
 
Ab wann gilt die Erklärung.
 
Ab wann gilt die Erklärung.
  
−
=====CON-24=====
+
====CON-24====
 
Wer hat die Einwilligung erteilt.
 
Wer hat die Einwilligung erteilt.
  
−
====TXA-Segment====
+
==TXA-Segment==
 
Das TXA-Segment enthält die Metadaten zu einem Dokument in MDM-Nachrichten. Das TXA-Segment kommt nur einmal in MDM vor, d.h. es eine Nachricht referenziert nur ein Dokument.  
 
Das TXA-Segment enthält die Metadaten zu einem Dokument in MDM-Nachrichten. Das TXA-Segment kommt nur einmal in MDM vor, d.h. es eine Nachricht referenziert nur ein Dokument.  
  
 
Für Berechtigungen muss unterschieden werden, ob man eine genauere Spezifikation braucht, was eine bestimmte Person darf und was nicht. Beispielsweise ob ein Arzt ein Dokument nur lesen oder auch verändern darf. Für eine derartige Detailspezifikation wird (vermutlich) eine ROL/PRA-Kombination in der CON-Gruppe benötigt. (Gegenwärtig ist dort nur PRA als Erweiterung vorgesehen.)
 
Für Berechtigungen muss unterschieden werden, ob man eine genauere Spezifikation braucht, was eine bestimmte Person darf und was nicht. Beispielsweise ob ein Arzt ein Dokument nur lesen oder auch verändern darf. Für eine derartige Detailspezifikation wird (vermutlich) eine ROL/PRA-Kombination in der CON-Gruppe benötigt. (Gegenwärtig ist dort nur PRA als Erweiterung vorgesehen.)
  
−
Wenn es nun um die Adressierung geht, wer das Dokument grundsätzlich bekommen soll, so reicht das TXA-Segment mit der Bestätigung durch ein CON-Segment aus. In TXA-24 ("Distributed Copies") können mehrere Empfänger angegeben werden. Für eine einfache Berechtigungsfreischaltung dürfte dies ausreichen.
+
Wenn es nun um die Adressierung geht, wer das Dokument grundsätzlich bekommen soll, so reicht das TXA-Segment mit der Bestätigung durch ein CON-Segment aus. In TXA-23 ("Distributed Copies") können mehrere Empfänger angegeben werden. Für eine einfache Berechtigungsfreischaltung (ohne weitere Granulierung) dürfte dies ausreichen.
  
−
Problematisch mit TXA-24 ist jedoch die Identifizierung einer Person über den Datentyp XCN:
+
====TXA-23====
 +
Problematisch mit TXA-23 ist jedoch die Identifizierung einer Person über den Datentyp XCN:
  
−
* es gibt Wiederholungen und jede Person ist nur einmal aufgeführt (Einigung über die ID erfprderlich)
+
* es gibt Wiederholungen und jede Person ist nur einmal aufgeführt (Einigung über die ID erforderlich), d.h. jede Wiederholung bezieht sich auf eine andere Person (hier sollte eine bestimmte Art der Identifikation (typeCode) erfolgen.)
−
* es gibt Wiederholungen, allerdings ist nur eine Person genannt
+
* es gibt Wiederholungen, allerdings ist nur eine Person genannt (unterschiedliche IDs zu einer Person)
−
* es gibt Wiederholungen und Personen sind mehrfach mit unterschiedlichen Identifikatoren (bspw. LANR und BSNR oder krankenhausinterne IDs) aufgeführt.  
+
* es gibt Wiederholungen und Personen sind mehrfach mit unterschiedlichen Identifikatoren (bspw. LANR und BSNR oder krankenhausinterne IDs) aufgeführt. (Es gibt mehr als eine, aber weniger Personen als Anzahl dier Wiederholungen)
  
 
{{ConstraintBox|
 
{{ConstraintBox|
−
In einer Implementierung muss man sich dann auf eine der drei Varianten einigen!
+
In einer Implementierung muss man sich dann auf eine der drei Varianten einigen!<br/>
 +
Da TXA nur einmal in einer Nachricht vorkommt, man aber mehrere Personen angeben können sollte, so ist die erste Variante zu bevorzugen.
 
}}
 
}}
  
−
====ARV-Segment Details====
+
==ARV-Segment==
  
 
{{WorkBox|
 
{{WorkBox|
−
Das ist ein neues Segment, dass sich mit Zugangsbeschänkungen (access restrictions) beschäftigt.
+
Das ist ein neues Segment, das in v2.6 eingeführt wird und sich mit Zugangsbeschänkungen (access restrictions) beschäftigt.
 
}}
 
}}
  
−
====ROL-Segment Details====
+
{| class="hl7table"
 +
!Seq
 +
!Description
 +
!German Interpretation
 +
!Length
 +
!Table
 +
!r/o/c
 +
!Rep#
 +
!Item
 +
!Data Structure
 +
!Section
 +
 
 +
|-
 +
|1
 +
|Set ID
 +
|ARV-Segmentnummer
 +
|..4
 +
|
 +
|O
 +
|
 +
|02143
 +
|SI
 +
|3.4.13.1
 +
 
 +
|-
 +
|2
 +
|Access Restriction Action Code
 +
|Aktionscode
 +
|..705
 +
|0206
 +
|R
 +
|
 +
|02144
 +
|CNE
 +
|3.4.13.2
 +
 
 +
|-
 +
|3
 +
|Access Restriction Value
 +
|Zugriffsbeschränkung auf
 +
|..705
 +
|0717
 +
|R
 +
|
 +
|02145
 +
|CWE
 +
|3.4.13.3
 +
 
 +
|-
 +
|4
 +
|Access Restriction Reason
 +
|Grund für Zugriffsbeschränkung
 +
|..705
 +
|0719
 +
|O
 +
|Y
 +
|02146
 +
|CWE
 +
|3.4.13.4
 +
 
 +
|-
 +
|5
 +
|Special Access Restriction Instructions
 +
|Spezielle Handlungsanweisungen für Zugriffsbeschränkung
 +
|..250
 +
|
 +
|O
 +
|Y
 +
|02147
 +
|ST
 +
|3.4.13.5
 +
 
 +
|-
 +
|6
 +
|Access Restriction Date Range
 +
|Gültigkeit Zugriffsbeschränkung
 +
|..49
 +
|
 +
|O
 +
|
 +
|02148
 +
|DR
 +
|3.4.13.6
 +
 
 +
|}
 +
 
 +
==ROL-Segment==
 
In dem CON-Segment gibt es keine Möglichkeit, eine Festlegung für eine andere Person als dem Patienten selbst zu treffen. Das heißt, wenn einer Gruppe von Ärzten eine Berechtigung erteilt werden soll, so ist dies über das ROL-Segment zu treffen. Damit ist für jeden Arzt oder Rolle ein eigenes ROL-Segment zu füllen.
 
In dem CON-Segment gibt es keine Möglichkeit, eine Festlegung für eine andere Person als dem Patienten selbst zu treffen. Das heißt, wenn einer Gruppe von Ärzten eine Berechtigung erteilt werden soll, so ist dies über das ROL-Segment zu treffen. Damit ist für jeden Arzt oder Rolle ein eigenes ROL-Segment zu füllen.
  
Zeile 592: Zeile 821:
 
|}
 
|}
  
−
====PRT-Segment?====
+
==PRT-Segment==
 
Das ROL-Segment befindet sich derzeit in der Ablösung durch das PRT-Segment. Daher stellt sich die Frage, ob nicht besser direkt das PRT-Segment in der Definition der Patienteneinwilligung verwendet werden soll?
 
Das ROL-Segment befindet sich derzeit in der Ablösung durch das PRT-Segment. Daher stellt sich die Frage, ob nicht besser direkt das PRT-Segment in der Definition der Patienteneinwilligung verwendet werden soll?
  
−
====PRA-Segment Details====
+
==PRA-Segment==
−
 
 
  
 
{| class="hl7table"
 
{| class="hl7table"
Zeile 755: Zeile 983:
 
|}
 
|}
  
−
====Nachrichtenstruktur====
+
===PRA-7===
 +
Welche Berechtigungen hat der jeweilige Arzt?
 +
 
 +
Dies wird über den Datentyp PIP realisiert:
 +
 
 +
{| class="hl7table"
 +
 
 +
|-
 +
!Seq.
 +
!Index
 +
!German Interpretation
 +
!Table (Comp.)
 +
!Opt.
 +
!Length
 +
!C.LEN
 +
!Data Type
 +
 
 +
|-
 +
|1
 +
|Privilege
 +
|
 +
|0525
 +
|R
 +
|
 +
|
 +
|CWE
 +
 
 +
|-
 +
|2
 +
|Privilege Class
 +
|
 +
|0526
 +
|O
 +
|
 +
|
 +
|CWE
 +
 +
|-
 +
|3
 +
|Expiration Date
 +
|
 +
|
 +
|O
 +
|
 +
|8=
 +
|DT
 +
 
 +
|-
 +
|4
 +
|Activation Date
 +
|
 +
|
 +
|O
 +
|
 +
|8=
 +
|DT
 +
 
 +
|-
 +
|5
 +
|Facility
 +
|
 +
|
 +
|O
 +
|
 +
|
 +
|EI
 +
 
 +
|}
 +
 
 +
 
 +
 
 +
==Nachrichtenstruktur==
 
Das CON-Segment ist optional und wiederholbar in den Nachrichten einzusetzen.
 
Das CON-Segment ist optional und wiederholbar in den Nachrichten einzusetzen.
  
Zeile 771: Zeile 1.070:
 
   }]      CONSENT_GROUP end
 
   }]      CONSENT_GROUP end
  
−
===Nachrichten===
+
Das CON-Segment kommt in der Grundstruktur bereits in MDM-Nachrichten vor:
 +
 
 +
  MSH
 +
  ...
 +
  PID
 +
  [PV1]
 +
  ...
 +
  TXA
 +
  [{ CON  }]
 +
 
 +
=Nachrichten=
  
−
====PMU Nachrichten====
+
==PMU Nachrichten==
 
Eine Möglichkeit wäre die Nutzung der B07/B08-Nachrichten für "grant/revoke certificate/permission". Dies wird hier aber erstmal nicht weiter verfolgt.
 
Eine Möglichkeit wäre die Nutzung der B07/B08-Nachrichten für "grant/revoke certificate/permission". Dies wird hier aber erstmal nicht weiter verfolgt.
  
−
===BPPC Integration Profile===
+
=BPPC Integration Profile=
−
Das Integrationsprofil BPPC (Basic Patient Privacy Consent) ist bei IHE ITI beschrieben. Es wird hier erst einmal aber nicht weiter verfolgt.
+
Das Integrationsprofil BPPC (Basic Patient Privacy Consent) ist bei IHE ITI beschrieben. Es wird hier erst einmal aber nicht weiter verfolgt, zumal es zu HL7 V3 gehört.
  
−
===Offene Punkte===
+
=Offene Punkte=
 
{{OIBox|Soll nicht besser direkt das neue PRT-Segment (Participation) verwendet werden?}}
 
{{OIBox|Soll nicht besser direkt das neue PRT-Segment (Participation) verwendet werden?}}
  
−
===Referenzen===
+
=Referenzen=
 
s.a. Orientierungshilfe Krankenhausinformationssysteme
 
s.a. Orientierungshilfe Krankenhausinformationssysteme
  
 +
[[Kategorie:Segmente|PV1]]
 
[[Kategorie:Segmente|CON]]
 
[[Kategorie:Segmente|CON]]
 
[[Kategorie:Segmente|ROL]]
 
[[Kategorie:Segmente|ROL]]

Aktuelle Version vom 3. Juni 2014, 12:02 Uhr

Grundlagen

Es liegt die Anforderung vor, die Informationen zu einer Patienteneinwilligung zu kommunizieren. Hierzu ist erst einmal festzulegen, was unter einer Patienteneinwilligung zu verstehen ist:

  • Ein Patient willigt in eine Behandlung ein. Im allgemeinen wird dies schon während der Aufnahme festgehalten und vom Patienten mit dem Behandlungsvertrag unterschrieben. Im speziellen gehört dazu aber auch die Einwilligung in eine bestimmte OP (Eingriff), wozu es konkret eine gesonderte Vereinbarung gibt, die typischerweise unmittelbar vor dem Eingriff noch einmal separat bestätigt wird. Dazu gehört dann auch die Bestätigung, dass eine Aufklärung über die Risiken etc. stattgefunden hat.
  • Ein Patient willigt ein, dass seine Daten übermittelt werden.
  • Ein Patient willigt ein, dass auf seine Daten von bestimmten Personen (oder Personen in einer bestimmten Rolle) zugegriffen werden darf.

Dies kann auf verschiedene Art und Weise geschehen:

  • Segmente: CON für die Einwilligungserklärung
  • Nachrichten: PMU für die Mitarbeiter
  • HL7 V3 CDA Einwilligung: BPPC Integration Profile
  • ...

aktueller Status

Under construction icon-blue.svg Diese Spezifikation (d.h. als Teil eines Nachrichtenprofils) befindet sich in der Ausarbeitung und stellt derzeit noch nicht den finalen Stand dar!

Use Cases

Welche Szenarien gilt es zu unterstützen und welche Informationen sind dazu wichtig/relevant/zu kommunizieren?

Hintergrundinformationen dazu sind hier zu hier finden.

Under construction icon-blue.svg Eine Evaluierung der Möglichkeit, die Einwilligung zur Datenübermittlung an das Landeskrebsregister mit Hilfe von CON-Segmenten in ADT-Nachrichten abzubilden findet hier statt.
Under construction icon-blue.svg Eine Evaluierung der Möglichkeit, die Einwilligung zur Datenübermittlung an Zuweiserportale mit Hilfe von CON- und ROL-Segmenten in ADT-Nachrichten abzubilden findet hier statt.

Informationen

Welche Informationen sind relevant?

  • wer willigt ein? (Patient oder Vormund)
  • wozu willigt er ein?
    • Datenzugriff
      • Dokumente
        • Dokumenttypen
    • ...
    • Behandlung
      • Medikation
      • Eingriff
      • ...
  • wann willigt er ein?
  • von wann bis wann gilt die Einwilligung?
  • in welcher Richtung erfolgt die Ermächtigung? (gestatten/verbieten)
  • wer ist davon betroffen? (Arzt als Person oder in einer bestimmten Rolle)
  • wie hat er eingewilligt?
    • schriftlich
    • mündlich
      • per Telefon

Mögliche Segmente für eine Einverständniserklärung

Im nachfolgenden werden einige Segmente aufgelistet und beschrieben, die für eine Einverständniserklärung auf verschiedene Art und Weise verwendet werden können:

Segment Beschreibung Anmerkung Status
PV1 Fallinformationen Hier sind 2 Felder enthalten, die aber eine andere Bedeutung haben. unzulässig
CON Consent Einwilligungserklärung, d.h. zu was; die Beteiligten können nicht dediziert benannt werden; kommt in MDM bereits vor möglich
TXA Header ungeeignet
ARV Access Restrictions Zugriffsbeschränkungen möglich
PRT Participation (löst ROL ab) zur Festlegung der Beteiligten, also auch der Berechtigten; löst in Zukunft das ROL-Segment ab; kommt vor 2.7 nirgends vor möglich
ROL Rolle zur Festlegung der Beteiligten, also auch der Berechtigten; müsste bei MDM hinzudefiniert werden möglich
PRA Practitioner (Arzt) die Berechtigungen eines Arztes werden übermittelt; kommt nicht in MDM vor in Abh.v. Nachricht

PV1-Segment

IM PV1-Segment sind drei Felder enthalten, die direkt die beteiligten Personen angeben. Das dritte Feld ist veraltet und darf nicht mehr genutzt werden (vgl. Nachrichtenprofile). Für dieses sollte das ROL-Segment genutzt werden.

Seq Description German Interpretation Length Table r/o/c Rep# Item Data Structure Section
... 3.4.3.x
7 Attending Doctor Behandelnder Arzt ..250 0010 O Y 00137 XCN 3.4.3.7
8 Referring Doctor Einweisender Arzt ..250 0010 O Y 00138 XCN 3.4.3.8
9 Consulting Doctor Mitbehandelnde Ärzte (1 = Hausarzt, 2..n = weitere Ärzte) ..250 0010 B Y 00139 XCN 3.4.3.9
... 3.4.3.x
Information icon.svg Aber auch die beiden anderen Felder sind für die behandelnden und einweisenden Ärzte vorgesehen.
Das sind dann NICHT die BERECHTIGTEN behandelnden und einweisen Ärzte. Eine Nutzung dieser Felder in dieser Form ist NICHT zulässig.
Attention icon.svg Das Problem bei einer mißbräuchlichen Nutzung dieser Felder sind die bereits existierenden Schnittstellen. Um eine Kompatibilität zur bisherigen Nutzung zu gewährleisten, müsste dieses Segment in einer eigenen Nachricht untergebracht werden. (ITI PAM Z99 ist ein gutes Beispiel hierfür.) Daher sind diese Felder für diesen Zweck abzulehnen, obwohl es recht praktikabel wäre!


CON-Segment

This segment identifies patient consent information relating to a particular message. It can be used as part of existing messages to convey information about patient consent to procedures, admissions, information release/exchange or other events discussed by the message. It may also be used in messages focusing on recording or requesting consent and for consents related to employees or service providers.

The segment will be used in conjunction with various other segments to identify the practitioner (PRA/STF) or patient (PID) the consent is for, the various individuals involved in the consent (ROL) as witnesses, consenting person (not always the patient), translators, consulting providers, etc., and the specific procedures being proposed (PR1).


The consent segment provides details about a specific consent by a patient or staff member.

Seq Description German Interpretation Length Table r/o/c Rep# Item Data Structure Section
1 Set ID - CON CON-Segmentnummer 4 R 01776 SI 9.9.4.1
2 Consent Type Art der Einverständniserklärung 705 0496 RE (O) 01777 CWE 9.9.4.2
3 Consent Form ID and Version verwendetes Formular der Einverständniserklärung 40 O 01778 ST 9.9.4.3
4 Consent Form Number eindeutige Identifikation der Einverständniserklärung 427 O 01779 EI 9.9.4.4
5 Consent Text Einverständnis - Text 65536 O Y 01780 FT 9.9.4.5
6 Subject-specific Consent Text Spezifische Einverständnisse 65536 O Y 01781 FT 9.9.4.6
7 Consent Background Information zusätzliche Informationen 65536 O Y 01782 FT 9.9.4.7
8 Subject-specific Consent Background Text spezifische Zusatzinformationen 65536 O Y 01783 FT 9.9.4.8
9 Consenter-imposed limitations Einschränkungen durch den Einwilligenden 65536 O Y 01784 FT 9.9.4.9
10 Consent Mode Form der Einverständniserklärung 2 0497 R (O) 01785 CNE 9.9.4.10
11 Consent Status Status der Einverständniserklärung 2 0498 R 01786 CNE 9.9.4.11
12 Consent Discussion Date/Time Zeitpunkt des Patientengesprächs 24 O 01787 DTM 9.9.4.12
13 Consent Decision Date/Time Zeitpunkt der Patientenentscheidung 24 O 01788 DTM 9.9.4.13
14 Consent Effective Date/Time Beginn des Einverständniszeitraums 24 R (O) 01789 DTM 9.9.4.14
15 Consent End Date/Time Ende des Einverständniszeitraums 24 RE (O) 01790 DTM 9.9.4.15
16 Subject Competence Indicator Merkmal Patientenverständnis vorhanden 1 0136 O 01791 ID 9.9.4.16
17 Translator Assistance Indicator Merkmal Dolmetscher benötigt 1 0136 O 01792 ID 9.9.4.17
18 Language Translated To übersetzt nach 250 0296 O 01793 CWE 9.9.4.18
19 Informational Material Supplied Indicator Merkmal zusätzliches Informationsmaterial ausgehändigt 1 0136 O 01794 ID 9.9.4.19
20 Consent Bypass Reason Grund für Nichteinholung eines Einverständnisses 705 0499 O 01795 CWE 9.9.4.20
21 Consent Disclosure Level Umfang der Patientenaufklärung 1 0500 O 01796 ID 9.9.4.21
22 Consent Non-disclosure Reason Grund für eingeschränkte Patientenaufklärung 705 0501 O 01797 CWE 9.9.4.22
23 Non-subject Consenter Reason Grund für die Einwilligung durch Dritte 705 0502 O 01798 CWE 9.9.4.23
24 Consenter ID Einwilligende Person 250 R Y 01909 XPN 9.9.4.24
25 Relationship to Subject Beziehung des Einwilligenden zum Patienten 100 0548 R Y 01898 IS 9.9.4.25

CON-2

Wem oder was wird - als Typ - zugestimmt. Dies ist eine user-defined table und kann somit an beliebige Bedürfnisse angepasst werden. Auch wenn die aufgeführten Tabellenwerte nicht ganz passen, so ist dies das Feld, in dem die Information eingetragen werden sollte.

Mögliche Tabellenwerte:

  • Zugriff auf Dokumente
    • Zugriff auf Arztbrief
    • Zugriff auf Bilder
  • ..

CON-10

In welcher Form wurde dem zugestimmt: verbal, schriftlich, per Telefon.

CON-11

In welchem Status befindet sich die Einwilligung, d.h. ist sie noch gültig (aktiv) oder nicht.

CON-14

Ab wann gilt die Erklärung.

CON-24

Wer hat die Einwilligung erteilt.

TXA-Segment

Das TXA-Segment enthält die Metadaten zu einem Dokument in MDM-Nachrichten. Das TXA-Segment kommt nur einmal in MDM vor, d.h. es eine Nachricht referenziert nur ein Dokument.

Für Berechtigungen muss unterschieden werden, ob man eine genauere Spezifikation braucht, was eine bestimmte Person darf und was nicht. Beispielsweise ob ein Arzt ein Dokument nur lesen oder auch verändern darf. Für eine derartige Detailspezifikation wird (vermutlich) eine ROL/PRA-Kombination in der CON-Gruppe benötigt. (Gegenwärtig ist dort nur PRA als Erweiterung vorgesehen.)

Wenn es nun um die Adressierung geht, wer das Dokument grundsätzlich bekommen soll, so reicht das TXA-Segment mit der Bestätigung durch ein CON-Segment aus. In TXA-23 ("Distributed Copies") können mehrere Empfänger angegeben werden. Für eine einfache Berechtigungsfreischaltung (ohne weitere Granulierung) dürfte dies ausreichen.

TXA-23

Problematisch mit TXA-23 ist jedoch die Identifizierung einer Person über den Datentyp XCN:

  • es gibt Wiederholungen und jede Person ist nur einmal aufgeführt (Einigung über die ID erforderlich), d.h. jede Wiederholung bezieht sich auf eine andere Person (hier sollte eine bestimmte Art der Identifikation (typeCode) erfolgen.)
  • es gibt Wiederholungen, allerdings ist nur eine Person genannt (unterschiedliche IDs zu einer Person)
  • es gibt Wiederholungen und Personen sind mehrfach mit unterschiedlichen Identifikatoren (bspw. LANR und BSNR oder krankenhausinterne IDs) aufgeführt. (Es gibt mehr als eine, aber weniger Personen als Anzahl dier Wiederholungen)
Conformance.svg In einer Implementierung muss man sich dann auf eine der drei Varianten einigen!
Da TXA nur einmal in einer Nachricht vorkommt, man aber mehrere Personen angeben können sollte, so ist die erste Variante zu bevorzugen.

ARV-Segment

Under construction icon-blue.svg Das ist ein neues Segment, das in v2.6 eingeführt wird und sich mit Zugangsbeschänkungen (access restrictions) beschäftigt.
Seq Description German Interpretation Length Table r/o/c Rep# Item Data Structure Section
1 Set ID ARV-Segmentnummer ..4 O 02143 SI 3.4.13.1
2 Access Restriction Action Code Aktionscode ..705 0206 R 02144 CNE 3.4.13.2
3 Access Restriction Value Zugriffsbeschränkung auf ..705 0717 R 02145 CWE 3.4.13.3
4 Access Restriction Reason Grund für Zugriffsbeschränkung ..705 0719 O Y 02146 CWE 3.4.13.4
5 Special Access Restriction Instructions Spezielle Handlungsanweisungen für Zugriffsbeschränkung ..250 O Y 02147 ST 3.4.13.5
6 Access Restriction Date Range Gültigkeit Zugriffsbeschränkung ..49 O 02148 DR 3.4.13.6

ROL-Segment

In dem CON-Segment gibt es keine Möglichkeit, eine Festlegung für eine andere Person als dem Patienten selbst zu treffen. Das heißt, wenn einer Gruppe von Ärzten eine Berechtigung erteilt werden soll, so ist dies über das ROL-Segment zu treffen. Damit ist für jeden Arzt oder Rolle ein eigenes ROL-Segment zu füllen.

Seq Description German Interpretation Length Table r/o/c Rep# Item Data Structure Section
1 Role Instance ID ID der individuellen Funktion 60 C 01206 EI 15.4.7.1
2 Action Code Aktionscode 2 0287 R 00816 ID 15.4.7.2
3 Role-ROL Funktion 250 0443 R 01197 CWE 15.4.7.3
4 Role Person ausübende Person zu ROL-3 250 R Y 01198 XCN 15.4.7.4
5 Role Begin Date/Time Zeitpunkt des Beginns zu ROL-3 24 RE (O) 01199 DTM 15.4.7.5
6 Role End Date/Time Zeitpunkt des Endes zu ROL-3 24 RE (O) 01200 DTM 15.4.7.6
7 Role Duration Dauer der Funktion 250 O 01201 CWE 15.4.7.7
8 Role Action Reason Begründung der Funktion 250 O 01205 CWE 15.4.7.8
9 Provider Type Typ des Dienstleisters 250 O Y 01510 CWE 15.4.7.9
10 Organization Unit Type Art der Organisationseinheit 250 0406 O 01461 CWE 15.4.7.10
11 Office/Home Address/Birthplace Dienst- / Privatadresse/Geburtsadresse 250 O Y 00679 XAD 15.4.7.11
12 Phone Telefonnummer 250 O Y 00678 XTN 15.4.7.12
13 Person's Location 1230 O 02183 PL 15.4.7.13

PRT-Segment

Das ROL-Segment befindet sich derzeit in der Ablösung durch das PRT-Segment. Daher stellt sich die Frage, ob nicht besser direkt das PRT-Segment in der Definition der Patienteneinwilligung verwendet werden soll?

PRA-Segment

Seq Description German Interpretation Length Table r/o/c Rep# Item Data Structure Section
1 Primary Key Value - PRA Primärschlüssel 250 9999 C 00685 CWE 15.4.6.1
2 Practitioner Group Gruppenzugehörigkeit (Ärzte / Pflegepersonal) 250 0358 O Y 00686 CWE 15.4.6.2
3 Practitioner Category berufliche Qualifikation 3 0186 O Y 00687 IS 15.4.6.3
4 Provider Billing Art der Privatliquidation 1 0187 O 00688 ID 15.4.6.4
5 Specialty Spezialisierung 112 0337 O Y 00689 SPD 15.4.6.5
6 Practitioner ID Numbers Arztnummer 0 0338 B Y 00690 PLN 15.4.6.6
7 Privileges Berechtigungen 770 O Y 00691 PIP 15.4.6.7
8 Date Entered Practice Datum der Tätigkeitsaufnahme 8 O 01296 DT 15.4.6.8
9 Institution Institution 250 0537 O 01613 CWE 15.4.6.9
10 Date Left Practice Datum der Beendigung der Tatigkeit 8 O 01348 DT 15.4.6.10
11 Government Reimbursement Billing Eligibility Ermächtigende/zulassende Institution 250 0401 O Y 01388 CWE 15.4.6.11
12 Set ID - PRA PRA-Segmentnummer 60 C 01616 SI 15.4.6.12

PRA-7

Welche Berechtigungen hat der jeweilige Arzt?

Dies wird über den Datentyp PIP realisiert:

Seq. Index German Interpretation Table (Comp.) Opt. Length C.LEN Data Type
1 Privilege 0525 R CWE
2 Privilege Class 0526 O CWE
3 Expiration Date O 8= DT
4 Activation Date O 8= DT
5 Facility O EI


Nachrichtenstruktur

Das CON-Segment ist optional und wiederholbar in den Nachrichten einzusetzen. 

 MSH
 ...
 PID
 [PV1]
 ...
 [{      CONSENT_GROUP begin
   CON 
   [{ 
     ROL 
     [PRA]
   }]
 }]      CONSENT_GROUP end

Das CON-Segment kommt in der Grundstruktur bereits in MDM-Nachrichten vor: 

 MSH
 ...
 PID
 [PV1]
 ...
 TXA
 [{ CON  }]

Nachrichten

PMU Nachrichten

Eine Möglichkeit wäre die Nutzung der B07/B08-Nachrichten für "grant/revoke certificate/permission". Dies wird hier aber erstmal nicht weiter verfolgt.

BPPC Integration Profile

Das Integrationsprofil BPPC (Basic Patient Privacy Consent) ist bei IHE ITI beschrieben. Es wird hier erst einmal aber nicht weiter verfolgt, zumal es zu HL7 V3 gehört.

Offene Punkte

Issue.svg Soll nicht besser direkt das neue PRT-Segment (Participation) verwendet werden?

Referenzen

s.a. Orientierungshilfe Krankenhausinformationssysteme

Abgerufen von „https://wiki.hl7.de/index.php?title=HL7_v2_Patienteneinwilligung&oldid=18022“