Patienteneinwilligung Zuweiserportale
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 Tidris (talk| contribs) 8 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 Tidris (talk| contribs) 8 years ago. (Purge) |
Proposal im Interoperabilitätsforum abgestimmt. Profilierung angedacht wenn sich mehr Implementierer finden. |
Platzhalter durch tatsächliche OIDs ersetzen |
Bei der Bereitstellung von Patienteninformationen für mitbehandelnde und zuweisende Ärzte mit Hilfe eines Zuweiserportals, ist die Einwilligung des Patienten erforderlich.
Diese Seite dient dem Versuch - mit möglichst einfachen Mitteln - die häufigsten UseCases zur Übermittlung der Patienteneinwilligung an ein Zuweiserportal darzustellen.
Die Akteure sind
- das KIS-System, in dem die administrative Aufnahme des Patienten erfolgt.
In der Regel werden dem Patienten bei der Aufnahme die Formulare zur Erteilung der Einwilligung bzw. des Widerspruchs ausgehändigt und Entscheidung des Patienten im KIS registriert.
- das Zuweiserportal, das den angeschlossenen Ärzten abhängig vom Behandlungskontext und der vorliegenden Patienteneinwilligung Informationen über den Behandlungsverlauf zur Verfügung stellt.
Inhaltsverzeichnis
HL7-Events
Für die Anlage und Aktualisierung der Patienteneinwilligung stehen die ADT-Events A01 (Anlage stationäre Aufnahme) A04 (Anlage ambulanter Besuch) und A08 (Änderung fallbezogener Daten) zur Verfügung.
HL7-Nachrichtenstrukturen
Für die Übermittlung von Art und Status der Einwilligung werden die Nachrichtenstrukturen der o.g. Events um das CON-Segment und bei Bedarf dazugehörige ROL-Segmente erweitert. Die Segment-Gruppe ist optional und wiederholbar und steht am Ende der Nachrichten.
MSH
[ { SFT } ]
EVN
PID
[ PD1 ]
[ { ROL } ]
[ { NK1 } ]
PV1
[ PV2 ]
[ { ROL } ]
[ { DB1 } ]
[ { OBX } ]
[ { AL1 } ]
[ { DG1 } ]
[ DRG ]
PROCEDURE
[{ PR1
[ { ROL } ]
}]
PROCEDURE
[ { GT1 } ]
INSURANCE
[{ IN1
[ IN2 ]
[ { IN3 } ]
[ { ROL } ]
}]
INSURANCE
[ ACC ]
[ UB1 ]
[ UB2 ]
[ PDA ]
PATIENTENEINWILLIGUNG ZUWEISERPORTALE
[{ CON
[ { ROL } ]
}]
CON-Segment
Um die Detailinformationen zur Patienteneinwilligung zu übermitteln dient das CON-Segment mit folgenden Wertebereichen:
Abgleich mit CON-Segment als Spezialisierung. |
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
Der Umfang und die Auswirkungen der Einverständniserklärung wird über eine OID bestimmt. Hierfür können (noch zu bestimmende) feste OIDs verwendet werden, die jeweils eine generische Zugriffsberechtigung für einen Hausarzt, einweisenden Arzt, aufnehmenden Arzt oder Nachsorger darstellen. Anstatt die generischen Zugriffsberechtigungen zu verwenden, können hier auch beliebige (projektspezifische) Policy OIDs verwendet werden, deren Semantik im Berechtigungssystem des Zuweiserportals festgelegt wird. Wenn CON Segmente mit diesen projektspezifischen Policy OIDs mit ROL Segmenten gruppiert werden, bezieht sich die Einverständniserklärung nur auf die im ROL Segment benannte Person oder Organisation. |
705 | 0496 | R | 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 (hier: "Erteilung einer Zugriffsberechtigung auf medizinische Informationen") | 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 | 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 | O | 01789 | DTM | 9.9.4.14 | ||
15 | Consent End Date/Time | Ende des Einverständniszeitraums | 24 | 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 |
Policy-OIDs
Gemäß der Implementierungsleitfäden von HL7 Deutschland, sollte die Übermittlung der im Behandlungskontext stehenden Ärzte mit Hilfe von ROL-Segmenten stattfinden (vgl. gemeinsame Elemente). Dabei sind verschiedene Rollen-Ausprägungen möglich. Da jede Einrichtung eigenständig entscheiden muss welche der bei ihnen verwendeten Dokumententypen mit welchen Rollen geteilt wird, sollte jede Einrichtung eigene Policy-OIDs definieren. Eine Policy-OID (z.B. 2.999.9.1.5.1) steht dann für die Berechtigung auf Dokumente mit Typ "Arztbrief", "vorläufiger Arztbrief", "Kardiologischer Arztbrief", "Arztbrief (kurz)" und auf "OP-Bericht" zuzugreifen. Bei Änderung des Umfangs der Zugriffsberechtigung sollte immer eine neue OID vergeben werden. Wenn z.B. die obige Liste um den "OP-Bericht" Eintrag gekürzt wird, sollte eine neue OID (z.B. 2.999.9.1.5.2) verwendet werden. Dadurch können für die gleiche Rolle unterschiedliche Berechtigungen abgebildet werden, je nach gültiger Regelung zum Zeitpunkt der Einwilligung (ohne das dabei das Einwilligungsdatum bei der Berechtigungsprüfung herangezogen werden müsste). Um einen sinnvollen Minimalstandard zu bieten und Umsetzungsprojekte zu unterstützen, die vor dem Aufwand für präzise, eigene Definitionen der Zugriffsrechte zurückschrecken, werden hier generische Policy OIDs vorgegeben, die von jeden Projekt frei verwendet werden können. Im Folgenden werden die generische Policy OIDs definiert.
Hausarzt
- Titel: Generische Policy für den Zugriff von Hausärztinnen auf Patientendaten in einem Zuweiserportal
- Policy OID (CON-2): 2.16.840.1.113883.2.6.99.1 (TODO durch finale OID ersetzen)
- Wer ist berechtigt: Die Hausärztin des Patienten - diese Policy spezifiert nicht über welchen Mechanismus die Identität der Ärztin übertragen wird (PV1-9; PD1-4; ROL Segment mit PP als ROL-3; out-of-band, z.B. eine explizite Konfiguration für jeden Patient)
- Worauf ist sie berechtigt: Zugriff auf medizinische Daten, die in dieser Policy nicht weiter spezifiziert sind, über ein Zuweiserportal
- Wie lange ist sie berechtigt: Von dem in <CON-14> ausgedrückten Zeitpunkt (falls vorhanden) bis ausschliesslich zum dem in <CON-15> ausgedrückten Zeitpunkt (falls vorhanden)
Einweisender Arzt
- Titel: Generische Policy für den Zugriff von einweisenden Ärztinnen auf Patientendaten in einem Zuweiserportal
- Policy OID (CON-2): 2.16.840.1.113883.2.6.99.2 (TODO durch finale OID ersetzen)
- Wer ist berechtigt: Die einweisende Ärztin des über die Nachricht übertragenen Falls - diese Policy spezifiert nicht über welchen Mechanismus die Identität der Ärztin übertragen wird (PV1-8; ROL Segment mit RP als ROL-3; out-of-band)
- Worauf ist sie berechtigt: Zugriff auf medizinische Daten, die in dieser Policy nicht weiter spezifiziert sind, über ein Zuweiserportal
- Wie lange ist sie berechtigt: Von dem in <CON-14> ausgedrückten Zeitpunkt (falls vorhanden) bis ausschliesslich zum dem in <CON-15> ausgedrückten Zeitpunkt (falls vorhanden)
Nachsorgender Arzt
- Titel: Generische Policy für den Zugriff von nachsorgenden Ärztinnen auf Patientendaten in einem Zuweiserportal
- Policy OID (CON-2): 2.16.840.1.113883.2.6.99.3 (TODO durch finale OID ersetzen)
- Wer ist berechtigt: Die nachsorgende Ärztin des über die Nachricht übertragenen Falls - diese Policy spezifiert nicht über welchen Mechanismus die Identität der Ärztin übertragen wird (PV1-9; ROL Segment mit RT als ROL-3; out-of-band)
- Worauf ist sie berechtigt: Zugriff auf medizinische Daten, die in dieser Policy nicht weiter spezifiziert sind, über ein Zuweiserportal
- Wie lange ist sie berechtigt: Von dem in <CON-14> ausgedrückten Zeitpunkt (falls vorhanden) bis ausschliesslich zum dem in <CON-15> ausgedrückten Zeitpunkt (falls vorhanden)
Aufnehmender Arzt
- Titel: Generische Policy für den Zugriff von aufnehmenden Ärztinnen auf Patientendaten in einem Zuweiserportal
- Policy OID (CON-2): 2.16.840.1.113883.2.6.99.4 (TODO durch finale OID ersetzen)
- Wer ist berechtigt: Die aufnehmende Ärztin (aus Sicht des Krankenhaus) des über die Nachricht übertragenen Falls - diese Policy spezifiert nicht über welchen Mechanismus die Identität der Ärztin übertragen wird (PV1-17; ROL Segment mit AD als ROL-3; out-of-band)
- Worauf ist sie berechtigt: Zugriff auf medizinische Daten, die in dieser Policy nicht weiter spezifiziert sind, über ein Zuweiserportal
- Wie lange ist sie berechtigt: Von dem in <CON-14> ausgedrückten Zeitpunkt (falls vorhanden) bis ausschliesslich zum dem in <CON-15> ausgedrückten Zeitpunkt (falls vorhanden)
Behandelnder Arzt
- Titel: Generische Policy für den Zugriff von behandelnden Ärztinnen auf Patientendaten in einem Zuweiserportal
- Policy OID (CON-2): 2.16.840.1.113883.2.6.99.5 (TODO durch finale OID ersetzen)
- Wer ist berechtigt: Die behandelnde Ärztin (aus Sicht des Krankenhaus) des über die Nachricht übertragenen Falls - diese Policy spezifiert nicht über welchen Mechanismus die Identität der Ärztin übertragen wird (PV1-7; ROL Segment mit AT als ROL-3; out-of-band)
- Worauf ist sie berechtigt: Zugriff auf medizinische Daten, die in dieser Policy nicht weiter spezifiziert sind, über ein Zuweiserportal
- Wie lange ist sie berechtigt: Von dem in <CON-14> ausgedrückten Zeitpunkt (falls vorhanden) bis ausschliesslich zum dem in <CON-15> ausgedrückten Zeitpunkt (falls vorhanden)
ROL-Segment
Das ROL Segment wird verwendet um die Berechtigung, die sich aus dem vorhergehenden CON Segment ergibt, einer bestimmten Person zuzuweisen. Diese explizite Zuweisung erlaubt die Verwendung von Policies die unabhängig von der Rolle der zugreifenden Person sind, da die zu berechtigende Person aufgeführt wird, anstatt sie über den Rollentyp zu identifizieren.
lfd. Nr. | Beschreibung | German Interpretation | Kard. | Verwendung | Tab. | Data Item | DT | Länge | Kapitel |
---|---|---|---|---|---|---|---|---|---|
1 | Role Instance ID | ID der individuellen Funktion | [0..1] | O (C) |
01206 | EI | 15.4.7.1 | ||
2 | Action Code | Aktionscode
|
[1..1] | R | 0287 | 00816 | ID | 12.4.1.1 | |
3 | Role-ROL | Funktion | [1..1] | R | 0443 | 01197 | CE | 15.4.7.3 | |
4 | Role Person | ausübende Person zu ROL-3 | [1..*] | R | 01198 | XCN | 15.4.7.4 | ||
5 | Role Begin Date/Time | Zeitpunkt des Beginns zu ROL-3 | [0..1] | O | 01199 | TS | 15.4.7.5 | ||
6 | Role End Date/Time | Zeitpunkt des Endes zu ROL-3 | [0..1] | O | 01200 | TS | 15.4.7.6 | ||
7 | Role Duration | Dauer der Funktion | [0..1] | O | 01201 | CE | 15.4.7.7 | ||
8 | Role Action Reason | Begründung der Funktion | [0..1] | O | 01205 | CE | 15.4.7.8 | ||
9 | Provider Type | Typ des Dienstleisters | [0..*] | O | 01510 | CE | 15.4.7.9 | ||
10 | Organization Unit Type | [0..1] | O | 0406 | 01461 | CE | 15.4.7.10 | ||
11 | Office/Home Address/ Birthplace | Dienst- / Privatadresse/ Geburtsadresse | [0..*] | O | 00679 | XAD | 15.4.7.11 | ||
12 | Phone | Telefonnummer | [0..*] | O | 00678 | XTN | 15.4.7.12 |
Tabelle 0443: Provider Role
Wert | Beschreibung | Interpretation |
---|---|---|
AD | Admitting | Einweisender Arzt |
AT | Attending | Behandelnder Arzt |
CP | Consulting Provider | Mitbehandelnder Arzt |
? | ||
PP | Primary Care Provider | Hausarzt |
RP | Referring Provider | überwiesen von |
RT | Referred To Provider | überwiesen nach |
Beispiele
Szenario 1
Patient stimmt in schriftlicher Form zu, dass dem Hausarzt Dr. Musterarzt (ID 9999) und der einweisenden Ärztin Dr. Musterärztin (ID 8888) eine Zugriffsberechtigung erteilt wird. Im Projekt wurde dafür keine eigene Policy OID definiert, stattdessen wird die generische Policy OID verwendet. Der Zugriff beschränkt sich auf bestimmte Dokumententypen, dies ist aber nicht in einer strukturierten Policy ausgedrückt sondern im Zuweiserportal über proprietäre Mittel abgebildet. Die einweisende Ärztin wird in diesem Beispiel per PV1-8 übertragen, beim Hausarzt nehmen wir in diesem Beispiel an, dass er einmal pro Patient in der Oberfläche des Zuweiserportals vom Klinikpersonal konfiguriert wird.
PV1|1|I|WCTR|R|||3333^Wasser^Ulrich^^^Dr. med.^^&2.999.1&ISO|8888^Musterärztin^Miriam^^^Dr. med.^^&2.999.1&ISO||MAM||||RP||N||W|5879758791|H|||||||||||||||||||KVHDIA|||^^^PHD||201504030953
CON|1|2.16.840.1.113883.2.6.99.1||||||||W|A||201512081533|201512081533|201503081533|Y|N||Y||F|||Musterpatient^Paul^^^^^^L|1
CON|2|2.16.840.1.113883.2.6.99.2||||||||W|A||201512081533|201512081533|201503081533|Y|N||Y||F|||Musterpatient^Paul^^^^^^L|1
Szenario 2
Patient ruft am nächsten Tag an und zieht seine Zustimmung zurück, so daß weder der Hausarzt noch die einweisende Ärztin eine Zugriffsberechtigung haben. Da in diesem Beispiel die generischen Policy OIDs verwendet werden, muss der Sender nicht die Identitäten der Ärzte erneut übetragen. Der Zugriff wird nun für alle Hausärzte und alle einweisenden Ärzte gesperrt.
CON|1|2.16.840.1.113883.2.6.99.1||||||||T|X||201512091240|||Y|N||Y||F|||Musterpatient^Paul^^^^^^L|1
CON|2|2.16.840.1.113883.2.6.99.2||||||||T|X||201512091240|||Y|N||Y||F|||Musterpatient^Paul^^^^^^L|1
Szenario 3
Patient stimmt in schriftlicher Form zu, dass dem Hausarzt Dr. Musterarzt (ID 9999) eine Zugriffsberechtigung erteilt wird, die durch die OID 2.999.9.1.5.1 ausgedrückt wird und Zugriff auf konkrete Dokumententypen der Einrichtung umfasst.
CON|1|2.999.9.1.5.1||||||||W|A
ROL|1|AD|PP|9999^Musterarzt^Max^^^Dr. med.^^&2.999.1&ISO
Alternative Umsetzung mittels PRT anstelle von ROL. Dies würde auch Berechtigungen auf Organisationsebene erlauben (die Organisation lässt sich in ROL nicht gut abbilden):
CON|1|2.999.9.1.5.1||||||||W|A
PRT|1|A||PP|9999^Musterarzt^Max^^^Dr. med.^^&2.999.1&ISO||O|Praxis Mustermann^^199991^^^&2.999.2&ISO
Szenario 4
Der Patient stimmt der Erteilung einer Zugriffsberechtigung für den nachbehandelnden Arzt (Dr. Musterärztin) zu, widerspricht jedoch ausdrücklich einer Zugriffsberechtigung für den Hausarzt (Dr. Musterarzt)
CON|1|2.999.9.1.5.2||||||||W|A
ROL|1|AD|PP|9999^Musterarzt^Max^^^Dr. med.^^&2.999.1&ISO
CON|2|2.999.9.1.5.1||||||||W|R
ROL|2|AD|RT|8888^Musterärztin^Miriam^^^Dr. med.^^&2.999.1&ISO
Szenario 5
Der Patient hat zunächst eine Zugriffsberechtigung für den Einweisenden Arzt erteilt, hat diese nun jedoch widerrufen.
CON|1|2.999.9.1.5.3||||||||W|X
ROL|1|AD|AD|8888^Musterärztin^Miriam^^^Dr. med.^^&2.999.1&ISO
Szenario 6
Der Patient stimmt der Zugriffsberechtigung für den Hausarzt weiterhin zu, aber der Hausarzt hat sich geändert.
CON|1|2.999.9.1.5.1||||||||W|A
ROL|1|DE|PP|9999^Musterarzt^Max^^^Dr. med.^^&2.999.1&ISO
ROL|2|AD|PP|8888^Musterärztin^Miriam^^^Dr. med.^^&2.999.1&ISO
Alternativ könnte man die Änderung des Hausarztes als "zurückziehen" der Einwilligung für Hausarzt "Alt" und Neu-Erteilung der Einwilligung für Hausarzt "Neu" betrachten. Dies würde die Verarbeitung auf Empfängerseite vereinfachen
CON|1|2.999.9.1.5.1||||||||W|R
ROL|1|AD|PP|9999^Musterarzt^Max^^^Dr. med.^^&2.999.1&ISO
CON|2|2.999.9.1.5.1||||||||W|A
ROL|2|AD|PP|8888^Musterärztin^Miriam^^^Dr. med.^^&2.999.1&ISO