Whitepaper: Korrigieren von Patientendaten

Aus Hl7wiki
Nachrichtenprofile
Wechseln zu: Navigation, Suche
(Übernahme aus hl7.de)
 
K
 
(3 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 20: Zeile 20:
  
 
{| class="hl7table"
 
{| class="hl7table"
!Version||06
+
|Version||06
 
|-
 
|-
!Stand:||25. März 2008
+
|Stand:||25. März 2008
 
|-
 
|-
!Dokumenten-OID:||n.a.
+
|Dokumenten-OID:||n.a.
 
|-
 
|-
 
|}
 
|}
Zeile 46: Zeile 46:
 
|06||25.03.09||FO, RS||Bewegungen||n.a.
 
|06||25.03.09||FO, RS||Bewegungen||n.a.
 
|-
 
|-
 +
|07||26.11.14||FO||Übernahme ins Wiki||n.a.
 
|}
 
|}
  
  
 
==Editor==
 
==Editor==
 
+
*Frank Oemig, AGFA HealthCare GmbH, Bonn
Frank Oemig, AGFA HealthCare GmbH, Bonn
 
 
 
  
 
==Autoren==
 
==Autoren==
 
+
*Frank Oemig, AGFA HealthCare GmbH, Bonn
Frank Oemig, AGFA HealthCare GmbH, Bonn
 
 
 
  
 
==Mit Beiträgen von==
 
==Mit Beiträgen von==
 +
*Verena Bayer, Agfa HealthCare, Trier (VB)
 +
*Bettina Lieske, SAP (BL)
 +
*Rene Spronk, Ringholm, Essen (RS)
  
Verena Bayer, Agfa HealthCare, Trier (VB)
 
 
Bettina Lieske, SAP (BL)
 
 
Rene Spronk, Ringholm, Essen (RS)
 
  
  
 
+
==Autoren und Copyright-Hinweis, Nutzungshinweise==
'''Autoren und Copyright-Hinweis, Nutzungs¬hinweise'''
 
  
 
{{BeginGreenBox|Nachnutzungs- bzw. Veröffentlichungsansprüche}}
 
{{BeginGreenBox|Nachnutzungs- bzw. Veröffentlichungsansprüche}}
Zeile 85: Zeile 79:
 
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.
 
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.
 
{{EndGreenBox}}
 
{{EndGreenBox}}
 
  
  
Zeile 91: Zeile 84:
 
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.
 
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.
 
{{EndGreenBox}}
 
{{EndGreenBox}}
 
 
 
 
  
 
=Einleitung=
 
=Einleitung=
Zeile 108: Zeile 97:
 
Im Prinzip muss von folgender Struktur ausgegangen werden:
 
Im Prinzip muss von folgender Struktur ausgegangen werden:
  
+
[[Datei:id-korrektur_01.gif]]
 +
 
 
Abbildung 1: grundlegende Beziehungen
 
Abbildung 1: grundlegende Beziehungen
  
Zeile 131: Zeile 121:
 
In diesem Szenario bekommt die Person eine neue Identifikation. Im Prinzip bleiben ansonsten alle Daten erhalten.
 
In diesem Szenario bekommt die Person eine neue Identifikation. Im Prinzip bleiben ansonsten alle Daten erhalten.
  
+
[[Datei:id-korrektur_02.gif]]
 +
 
 
Abbildung 2: Update der Personen-Identifikation
 
Abbildung 2: Update der Personen-Identifikation
  
 
====Details====
 
  
 
{| class="hl7table"
 
{| class="hl7table"
 
!Feld!!Beschreibung!!Bedingung
 
!Feld!!Beschreibung!!Bedingung
 
|-
 
|-
|MRG-1||alte Personen-ID (\#P1)||MRG-1.5=PN
+
|MRG-1||alte Personen-ID (#P1)||MRG-1.5=PN
 
|-
 
|-
|PID-3||neue Personen-ID (\#P2)||PID-3.5=PN
+
|PID-3||neue Personen-ID (#P2)||PID-3.5=PN
 
|-
 
|-
 
|}
 
|}
Zeile 151: Zeile 140:
 
In diesem Szenario werden alle Daten (Patienten, Fälle) von einer Person zu einer anderen (bereits existenten Person) überführt. Es handelt sich in diesem Sinne um ein Merge der Informationen.
 
In diesem Szenario werden alle Daten (Patienten, Fälle) von einer Person zu einer anderen (bereits existenten Person) überführt. Es handelt sich in diesem Sinne um ein Merge der Informationen.
  
+
[[Datei:id-korrektur_03.gif]]
 +
 
 
Abbildung 3: Zusammenführen zweier Personen
 
Abbildung 3: Zusammenführen zweier Personen
 +
 
Diese Transaktion kann nicht mehr rückgängig gemacht werden. Einmal zusammengeführte Personendaten können nur über die anderen Transaktionen zu Personen/ Patienten/ Fälle/ etc. wieder entflechtet werden.
 
Diese Transaktion kann nicht mehr rückgängig gemacht werden. Einmal zusammengeführte Personendaten können nur über die anderen Transaktionen zu Personen/ Patienten/ Fälle/ etc. wieder entflechtet werden.
 
====Details====
 
  
 
{| class="hl7table"
 
{| class="hl7table"
 
!Feld!!Beschreibung!!Bedingung
 
!Feld!!Beschreibung!!Bedingung
 
|-
 
|-
|MRG-1||alte Personen-ID (\#P1)||MRG-1.5=PN
+
|MRG-1||alte Personen-ID (#P1)||MRG-1.5=PN
 
|-
 
|-
|PID-3||neue Personen-ID (\#P2)||PID-3.5=PN
+
|PID-3||neue Personen-ID (#P2)||PID-3.5=PN
 
|-
 
|-
 
|}
 
|}
Zeile 171: Zeile 160:
 
In diesem Szenario werden die Daten zweier Personen miteinander verknüpft, d.h. verlinkt. Beide Personen sind vor und nach der Transaktion existent.  
 
In diesem Szenario werden die Daten zweier Personen miteinander verknüpft, d.h. verlinkt. Beide Personen sind vor und nach der Transaktion existent.  
  
+
[[Datei:id-korrektur_04.gif]]
 +
 
 +
 
 
Abbildung 4: Verknüpfen zweier Personen
 
Abbildung 4: Verknüpfen zweier Personen
 
Anm.: Der Standard spricht explizit über „Patienten". Daher stellt sich die Frage, ob dieselbe Nachricht auch für „Personen" gilt?
 
Anm.: Der Standard spricht explizit über „Patienten". Daher stellt sich die Frage, ob dieselbe Nachricht auch für „Personen" gilt?
 
====Details====
 
  
 
{| class="hl7table"
 
{| class="hl7table"
 
!Feld!!Beschreibung!!Bedingung
 
!Feld!!Beschreibung!!Bedingung
 
|-
 
|-
|PID-3 (erstes PID)||alte Personen-ID (\#P1)||PID-3.5=PN
+
|PID-3 (erstes PID)||alte Personen-ID (#P1)||PID-3.5=PN
 
|-
 
|-
|PID-3 (zweites PID)||neue Personen-ID (\#P2)||PID-3.5=PN
+
|PID-3 (zweites PID)||neue Personen-ID (#P2)||PID-3.5=PN
 
|-
 
|-
 
|}
 
|}
Zeile 188: Zeile 177:
  
  
===13. „Entknüpfen" zweier Personen (Event A37)===
+
===„Entknüpfen" zweier Personen (Event A37)===
 
In diesem Szenario wird die Verknüpfung zwischen zwei Personen wieder aufgehoben. Beide Personen sind vor und nach der Transaktion existent.  
 
In diesem Szenario wird die Verknüpfung zwischen zwei Personen wieder aufgehoben. Beide Personen sind vor und nach der Transaktion existent.  
  
 +
[[Datei:id-korrektur_05.gif]]
 
   
 
   
 
Abbildung 5: Entknüpfen zweier Personen
 
Abbildung 5: Entknüpfen zweier Personen
 
====14. Details====
 
  
 
{| class="hl7table"
 
{| class="hl7table"
 
!Feld!!Beschreibung!!Bedingung
 
!Feld!!Beschreibung!!Bedingung
 
|-
 
|-
|PID-3 (erstes PID)||alte Personen-ID (\#P1)||PID-3.5=PN
+
|PID-3 (erstes PID)||alte Personen-ID (#P1)||PID-3.5=PN
 
|-
 
|-
|PID-3 (zweites PID)||neue Personen-ID (\#P2)||PID-3.5=PN
+
|PID-3 (zweites PID)||neue Personen-ID (#P2)||PID-3.5=PN
 
|-
 
|-
 
|}
 
|}
Zeile 207: Zeile 195:
  
  
==15. auf Patienten-Ebene==
+
==auf Patienten-Ebene==
  
  
===16. Update der Patienten-Identifikation (Event A47)===
+
===Update der Patienten-Identifikation (Event A47)===
 
In diesem Szenario bekommt der Patient eine neue Identifikation. Im Prinzip bleiben ansonsten alle Daten erhalten.
 
In diesem Szenario bekommt der Patient eine neue Identifikation. Im Prinzip bleiben ansonsten alle Daten erhalten.
  
+
[[Datei:id-korrektur_06.gif]]
 +
 
 
Abbildung 6: Update der Patienten-Identifikation
 
Abbildung 6: Update der Patienten-Identifikation
 
 
====17. Details====
 
  
 
{| class="hl7table"
 
{| class="hl7table"
 
!Feld!!Beschreibung!!Bedingung
 
!Feld!!Beschreibung!!Bedingung
 
|-
 
|-
|MRG-1||alte Patienten-ID (\#P1)||MRG-1.5=PI
+
|MRG-1||alte Patienten-ID (#P1)||MRG-1.5=PI
 
|-
 
|-
|PID-3||neue Patienten-ID (\#P2)||PID-3.5=PI
+
|PID-3||neue Patienten-ID (#P2)||PID-3.5=PI
 
|-
 
|-
 
|PID-3||Personen-ID||PID-3.5=PN
 
|PID-3||Personen-ID||PID-3.5=PN
Zeile 232: Zeile 218:
  
  
===18. Zusammenführen zweier Patienten (Event A40)===
+
===Zusammenführen zweier Patienten (Event A40)===
 
Hierbei wird ein Patient mit einem anderen zusammengeführt. Die übergeordneten Personen können dabei durchaus verschieden sein. Damit werden alle Fälle darunter automatisch verschoben, so dass diese in der Nachricht nicht explizit benannt werden müssen.
 
Hierbei wird ein Patient mit einem anderen zusammengeführt. Die übergeordneten Personen können dabei durchaus verschieden sein. Damit werden alle Fälle darunter automatisch verschoben, so dass diese in der Nachricht nicht explizit benannt werden müssen.
 
Im Gegensatz zu vorhergehendem Szenario wird hier die Information über den Patienten gelöscht. D. h. wird im MRG-1 eine frühere Patienten-ID angegeben, so wird der Patient bei der Aktion gelöscht (Kap. 3.2.2). Wird im MRG-1 keine frühere Patienten-ID angegeben, so existiert diese nach dem Verarbeiten der A40 weiter (Kap. 3.2.3).
 
Im Gegensatz zu vorhergehendem Szenario wird hier die Information über den Patienten gelöscht. D. h. wird im MRG-1 eine frühere Patienten-ID angegeben, so wird der Patient bei der Aktion gelöscht (Kap. 3.2.2). Wird im MRG-1 keine frühere Patienten-ID angegeben, so existiert diese nach dem Verarbeiten der A40 weiter (Kap. 3.2.3).
  
+
[[Datei:id-korrektur_07.gif]]
 +
 
 
Abbildung 7: Zusammenführen zweier Patienten
 
Abbildung 7: Zusammenführen zweier Patienten
 
 
====19. Details====
 
  
 
{| class="hl7table"
 
{| class="hl7table"
 
!Feld!!Beschreibung!!Bedingung
 
!Feld!!Beschreibung!!Bedingung
 
|-
 
|-
|MRG-1||frühere Personen-ID (\#P1)<br/>frühere Patienten-ID (\#Pat1)||MRG-1.5=PN<br/>MRG-1.5=PI
+
|MRG-1||frühere Personen-ID (#P1)<br/>frühere Patienten-ID (#Pat1)||MRG-1.5=PN<br/>MRG-1.5=PI
 
|-
 
|-
|PID-3||neue Personen-ID (\#P3)<br/>neue Patienten-ID (\#Pat3)||PID-3.5=PN<br/>PID-3.5=PI
+
|PID-3||neue Personen-ID (#P3)<br/>neue Patienten-ID (#Pat3)||PID-3.5=PN<br/>PID-3.5=PI
 
|-
 
|-
 
|}
 
|}
Zeile 253: Zeile 237:
  
  
===20. Patientendaten an andere Person umhängen (Event A40)===
+
===Patientendaten an andere Person umhängen (Event A40)===
 
Hierbei werden alle Daten für Patient 1 an eine andere Person angehängt.
 
Hierbei werden alle Daten für Patient 1 an eine andere Person angehängt.
  
+
[[Datei:id-korrektur_08.gif]]
 +
 
 
Abbildung 8: Patientendaten umhängen
 
Abbildung 8: Patientendaten umhängen
 
 
====21. Details====
 
  
 
{| class="hl7table"
 
{| class="hl7table"
 
!Feld!!Beschreibung!!Bedingung
 
!Feld!!Beschreibung!!Bedingung
 
|-
 
|-
|MRG-1||alte Personen-ID (\#P1)||MRG-1.5=PN
+
|MRG-1||alte Personen-ID (#P1)||MRG-1.5=PN
 
|-
 
|-
|PID-3||neue Personen-ID (\#P2)||PID-3.5=PN
+
|PID-3||neue Personen-ID (#P2)||PID-3.5=PN
 
|-
 
|-
|PID-3||Patienten-ID (\#Pat1)||PID-3.5=PI
+
|PID-3||Patienten-ID (#Pat1)||PID-3.5=PI
 
|-
 
|-
 
|}
 
|}
Zeile 276: Zeile 258:
 
Durch die Angabe mehrerer Patienten-IDs in PID-3 müssten sich auch mehrere Patienten gleichzeitig umhängen lassen. Das setzt aber voraus, dass die ID nicht geändert wird. Letzteres müsste dann über eine andere Nachricht realisiert werden.
 
Durch die Angabe mehrerer Patienten-IDs in PID-3 müssten sich auch mehrere Patienten gleichzeitig umhängen lassen. Das setzt aber voraus, dass die ID nicht geändert wird. Letzteres müsste dann über eine andere Nachricht realisiert werden.
  
===22. Verknüpfen zweier Patienten (Event A24)===
+
===Verknüpfen zweier Patienten (Event A24)===
 
In diesem Szenario werden die Daten zweier Patienten miteinander verknüpft, d.h. verlinkt. Beide Patienten sind vor und nach der Transaktion existent.  
 
In diesem Szenario werden die Daten zweier Patienten miteinander verknüpft, d.h. verlinkt. Beide Patienten sind vor und nach der Transaktion existent.  
  
+
[[Datei:id-korrektur_09.gif]]
 +
 
 
Abbildung 9: Verknüpfen zweier Patienten
 
Abbildung 9: Verknüpfen zweier Patienten
 
====23. Details====
 
  
 
{| class="hl7table"
 
{| class="hl7table"
 
!Feld!!Beschreibung!!Bedingung
 
!Feld!!Beschreibung!!Bedingung
 
|-
 
|-
|PID-3 (erstes PID)||alte Patienten-ID (\#P1)||PID-3.5=PI
+
|PID-3 (erstes PID)||alte Patienten-ID (#P1)||PID-3.5=PI
 
|-
 
|-
|PID-3 (zweites PID)||neue Patienten-ID (\#P2)||PID-3.5=PI
+
|PID-3 (zweites PID)||neue Patienten-ID (#P2)||PID-3.5=PI
 
|-
 
|-
 
|}
 
|}
Zeile 295: Zeile 276:
  
  
===24. „Entknüpfen" zweier Patienten (Event A37)===
+
===„Entknüpfen" zweier Patienten (Event A37)===
 
In diesem Szenario wird die Verknüpfung zwischen zwei Patienten wieder aufgehoben. Beide Patienten sind vor und nach der Transaktion existent.  
 
In diesem Szenario wird die Verknüpfung zwischen zwei Patienten wieder aufgehoben. Beide Patienten sind vor und nach der Transaktion existent.  
  
+
[[Datei:id-korrektur_10.gif]]
 +
 
 
Abbildung 10: Entknüpfen zweier Patienten
 
Abbildung 10: Entknüpfen zweier Patienten
 
 
====25. Details====
 
  
 
{| class="hl7table"
 
{| class="hl7table"
 
!Feld!!Beschreibung!!Bedingung
 
!Feld!!Beschreibung!!Bedingung
 
|-
 
|-
|PID-3 (erstes PID)||alte/frühere Patienten-ID (\#P1)||PID-3.5=PI
+
|PID-3 (erstes PID)||alte/frühere Patienten-ID (#P1)||PID-3.5=PI
 
|-
 
|-
|PID-3 (zweites PID)||neue Patienten-ID (\#P2)||PID-3.5=PI
+
|PID-3 (zweites PID)||neue Patienten-ID (#P2)||PID-3.5=PI
 
|-
 
|-
 
|}
 
|}
Zeile 315: Zeile 294:
  
  
==26. auf Fall-Ebene==
+
==auf Fall-Ebene==
  
  
===27. Update der Fall-Identifikation (Event A50)===
+
===Update der Fall-Identifikation (Event A50)===
 
In diesem Szenario bekommt der Fall zu einem Patienten eine neue Identifikation. Im Prinzip bleiben ansonsten alle Daten erhalten. Auch bleibt der Fall an demselben Patienten „hängen".
 
In diesem Szenario bekommt der Fall zu einem Patienten eine neue Identifikation. Im Prinzip bleiben ansonsten alle Daten erhalten. Auch bleibt der Fall an demselben Patienten „hängen".
  
+
[[Datei:id-korrektur_11.gif]]
 +
 
 
Abbildung 11: Update der Fall-Identifikation
 
Abbildung 11: Update der Fall-Identifikation
 
 
====28. Details====
 
  
 
{| class="hl7table"
 
{| class="hl7table"
 
!Feld!!Beschreibung!!Bedingung
 
!Feld!!Beschreibung!!Bedingung
 
|-
 
|-
|PID-3<br/>MRG-1||Patienten-ID (\#P1)||PID-3.5=PI<br/>MRG-1.5=PI
+
|PID-3<br/>MRG-1||Patienten-ID (#P1)||PID-3.5=PI<br/>MRG-1.5=PI
 
|-
 
|-
|MRG-5||alte/frühere Fallnummer (\#F1)||MRG-5.5=VN
+
|MRG-5||alte/frühere Fallnummer (#F1)||MRG-5.5=VN
 
|-
 
|-
|PV1-19||neue Fallnummer (\#F2)||PV1-19.5=VN
+
|PV1-19||neue Fallnummer (#F2)||PV1-19.5=VN
 
|-
 
|-
 
|}
 
|}
 
Tabelle 10: Update der Fall-Identifikation
 
Tabelle 10: Update der Fall-Identifikation
  
 +
===Fall an andere Person umhängen (Event A45)===
 +
Hier wird ein Fall komplett an einen anderen Patienten und damit auch an eine andere Person angehängt. Die Fall-Identifikation bleibt unverändert.
  
===29. Fall an andere Person umhängen (Event A45)===
+
[[Datei:id-korrektur_12.gif]]
Hier wird ein Fall komplett an einen anderen Patienten und damit auch an eine andere Person angehängt. Die Fall-Identifikation bleibt unverändert.
 
  
 
 
Abbildung 12: Fall umhängen
 
Abbildung 12: Fall umhängen
 
 
====30. Details====
 
  
 
{| class="hl7table"
 
{| class="hl7table"
 
!Feld!!Beschreibung!!Bedingung
 
!Feld!!Beschreibung!!Bedingung
 
|-
 
|-
|MRG-1||frühere Personen-ID (\#P1)<br/>frühere Patienten-ID (\#Pat1)||MRG-1.5=PN<br/>
+
|MRG-1||frühere Personen-ID (#P1)<br/>frühere Patienten-ID (#Pat1)||MRG-1.5=PN<br/>
 
MRG-1.5=PI
 
MRG-1.5=PI
 
|-
 
|-
|PID-3||neue Personen-ID (\#P2)<br/>neue Patienten-ID (\#Pat2)||PID-3.5=PN<br/>PID-3.5=PI
+
|PID-3||neue Personen-ID (#P2)<br/>neue Patienten-ID (#Pat2)||PID-3.5=PN<br/>PID-3.5=PI
 
|-
 
|-
|PV1-19||Fallnummer (\#F1)||PV1-19.5=VN
+
|PV1-19||Fallnummer (#F1)||PV1-19.5=VN
 
|}
 
|}
 
Tabelle 11: Fall umhängen
 
Tabelle 11: Fall umhängen
  
  
===31. einzelnen Fall an anderen Patienten umhängen (Event A45)===
+
===einzelnen Fall an anderen Patienten umhängen (Event A45)===
 
Hierbei werden die Daten von einem bestimmten Fall an einen anderen Patienten, der aber zu derselben oder einen anderen Person gehört, angehängt. Der Patient existiert danach weiter.
 
Hierbei werden die Daten von einem bestimmten Fall an einen anderen Patienten, der aber zu derselben oder einen anderen Person gehört, angehängt. Der Patient existiert danach weiter.
  
 +
[[Datei:id-korrektur_13.gif]]
 
   
 
   
 
Abbildung 13: Fall umhängen
 
Abbildung 13: Fall umhängen
 
 
====32. Details====
 
  
 
{| class="hl7table"
 
{| class="hl7table"
 
!Feld!!Beschreibung!!Bedingung
 
!Feld!!Beschreibung!!Bedingung
 
|-
 
|-
|MRG-1||frühere Patienten-ID (\#Pat1)<br/>frühere Personen-ID (\#P1)||MRG-1.5=PI<br/>MRG-1.5=PN
+
|MRG-1||frühere Patienten-ID (#Pat1)<br/>frühere Personen-ID (#P1)||MRG-1.5=PI<br/>MRG-1.5=PN
 
|-
 
|-
|PID-3||neue Personen-ID (\#P2)<br/>neue Patienten-ID (\#Pat4)||PID-3.5=PN<br/>PID-3.5=PI
+
|PID-3||neue Personen-ID (#P2)<br/>neue Patienten-ID (#Pat4)||PID-3.5=PN<br/>PID-3.5=PI
 
|-
 
|-
|PV1-19||Fallnummer (\#F1)||PV1-19.5=VN
+
|PV1-19||Fallnummer (#F1)||PV1-19.5=VN
 
|}
 
|}
 
Tabelle 12: Fall umhängen
 
Tabelle 12: Fall umhängen
  
  
===33. Zusammenführung zweier Fälle (Event A42)===
+
===Zusammenführung zweier Fälle (Event A42)===
 
Hierbei werden zwei Fälle zusammengeführt. Nach der Zusammenführung existiert der erste Fall nicht mehr, existierende Falldetails werden dabei auf den neuen Fall umgehängt.
 
Hierbei werden zwei Fälle zusammengeführt. Nach der Zusammenführung existiert der erste Fall nicht mehr, existierende Falldetails werden dabei auf den neuen Fall umgehängt.
 
In der Beschreibung ist allerdings unklar, ob diese Fälle zu demselben Patienten gehören müssen oder nicht.
 
In der Beschreibung ist allerdings unklar, ob diese Fälle zu demselben Patienten gehören müssen oder nicht.
  
 +
[[Datei:id-korrektur_14.gif]]
 
   
 
   
 
Abbildung 14: Zusammenführung zweier Fälle
 
Abbildung 14: Zusammenführung zweier Fälle
  
  
====34. Segmente====
+
====Segmente====
  
 
{| class="hl7table"
 
{| class="hl7table"
 
!Feld!!Beschreibung!!Bedingung
 
!Feld!!Beschreibung!!Bedingung
 
|-
 
|-
|PID-3||neue Personen-ID (\#P2)
+
|PID-3||neue Personen-ID (#P2)<br/>neue Patienten-ID (#Pat2)||PID-3.5=PN<br/>PID-3.5=PI
neue Patienten-ID (\#Pat2)||PID-3.5=PN
 
PID-3.5=PI
 
 
|-
 
|-
|MRG-1||frühere Personen-ID (\#P1)
+
|MRG-1||frühere Personen-ID (#P1)<br/>frühere Patienten-ID (#Pat1)||MRG-1.5=PN<br/>MRG-1.5=PI
frühere Patienten-ID (\#Pat1)||MRG-1.5=PN
 
MRG-1.5=PI
 
 
|-
 
|-
|MRG-5||frühere Fallnummer (\#F1)||MRG-5.5=VN
+
|MRG-5||frühere Fallnummer (#F1)||MRG-5.5=VN
|-
 
|PV1-19||neue Fallnummer (\#F2)||PV1-19.5=VN
 
 
|-
 
|-
 +
|PV1-19||neue Fallnummer (#F2)||PV1-19.5=VN
 
|}
 
|}
 
Tabelle 13: Zusammenführung zweier Fälle
 
Tabelle 13: Zusammenführung zweier Fälle
  
 
+
==auf Bewegungs-Ebene==
==35. auf Bewegungs-Ebene==
 
 
Unterhalb der Fall-Ebene werden über Verlegungen Bewegungen realisiert, die über das ZBE-Segment eindeutig identifiziert werden können.
 
Unterhalb der Fall-Ebene werden über Verlegungen Bewegungen realisiert, die über das ZBE-Segment eindeutig identifiziert werden können.
  
===36. Korrektur der Bewegungs-Identifikation (Event A08)===
+
===Korrektur der Bewegungs-Identifikation (Event A08)===
 
Eine direkte Korrektur einer Bewegung oder auch einer ID für eine Bewegung ist nicht möglich. Aus diesem Grund wurde das ZBE-Segment auf nationaler Ebene eingeführt, um wenigstens eine Bewegung eindeutig identifizieren zu können und so falsche Informationen auf dieser Ebene überhaupt korrigieren zu können. Eine Korrektur muss auf dieser Ebene über Löschen und eine Neuanlage erfolgen.
 
Eine direkte Korrektur einer Bewegung oder auch einer ID für eine Bewegung ist nicht möglich. Aus diesem Grund wurde das ZBE-Segment auf nationaler Ebene eingeführt, um wenigstens eine Bewegung eindeutig identifizieren zu können und so falsche Informationen auf dieser Ebene überhaupt korrigieren zu können. Eine Korrektur muss auf dieser Ebene über Löschen und eine Neuanlage erfolgen.
  
====37. Segmente====
+
====Segmente====
  
 
{| class="hl7table"
 
{| class="hl7table"
Zeile 431: Zeile 398:
  
  
==38. auf Falldetail-Ebene==
+
==auf Falldetail-Ebene==
 
Dieser Abschnitt behandelt, wie Detailinformationen zu einem Fall verschoben werden können.
 
Dieser Abschnitt behandelt, wie Detailinformationen zu einem Fall verschoben werden können.
  
===39. Detaildaten zu einem Fall umhängen===
+
===Detaildaten zu einem Fall umhängen===
 
In diesem Szenario sollen Details – wie bspw. Diagnosen, Maßnahmen, Leistungen oder Aufträge – von einem Fall zu einem anderen verschoben werden. Wie zu erwarten existiert hierfür kein Event und keine Nachricht. Die Daten sind also entsprechend zu stornieren/löschen und dann neu zu übermitteln.
 
In diesem Szenario sollen Details – wie bspw. Diagnosen, Maßnahmen, Leistungen oder Aufträge – von einem Fall zu einem anderen verschoben werden. Wie zu erwarten existiert hierfür kein Event und keine Nachricht. Die Daten sind also entsprechend zu stornieren/löschen und dann neu zu übermitteln.
  
+
[[Datei:id-korrektur_15.gif]]
 +
 
 
Abbildung 15: Detaildaten umhängen
 
Abbildung 15: Detaildaten umhängen
  
  
=40. Anmerkungen=
+
=Anmerkungen=
  
==41. Merge==
+
==Merge==
 
Bei einem Merge von Datenbeständen kann davon ausgegangen werden, dass nicht alle Systeme diese Veränderungen nachvollziehen. Daher ist es ratsam, Nachrichten, die sich auf die alte ID beziehen, entsprechend weiterzuleiten.
 
Bei einem Merge von Datenbeständen kann davon ausgegangen werden, dass nicht alle Systeme diese Veränderungen nachvollziehen. Daher ist es ratsam, Nachrichten, die sich auf die alte ID beziehen, entsprechend weiterzuleiten.
  
==42. Multiple IDs==
+
==Multiple IDs==
 
Es kann durchaus vorkommen, dass sich mehrere unterschiedliche IDs auf dasselbe Objekt beziehen. In einem solchen Fall sollen alle IDs angegeben bzw. verändert werden.
 
Es kann durchaus vorkommen, dass sich mehrere unterschiedliche IDs auf dasselbe Objekt beziehen. In einem solchen Fall sollen alle IDs angegeben bzw. verändert werden.
  
=43. Events=
+
=Events=
  
==44. Events==
+
==Events==
  
 
{| class="hl7table"
 
{| class="hl7table"
Zeile 473: Zeile 441:
 
Tabelle 15: Events
 
Tabelle 15: Events
  
 +
=Genutzte Nachrichtenstrukturen=
  
=45. Genutzte Nachrichtenstrukturen=
+
==genutzte Nachrichtenstrukturen==
 
 
==46. genutzte Nachrichtenstrukturen==
 
 
Gemäß obiger Liste werden dann folgende Nachrichtenstrukturen benötigt.
 
Gemäß obiger Liste werden dann folgende Nachrichtenstrukturen benötigt.
  
==47. ADT_A24==
+
==ADT_A24==
  
 
{| class="hl7table"
 
{| class="hl7table"
!Segment!!Kard.!!Ver¬wen¬dung!!Beschreibung!!Bemerkung
+
!Segment!!Kard.!!Verwendung!!Beschreibung!!Bemerkung
 
|-
 
|-
 
|MSH||[1..1]||R||Message Header||
 
|MSH||[1..1]||R||Message Header||
 
|-
 
|-
|[{ SFT }]|| bgcolor="3366ff" |[0..\*]|| bgcolor="3366ff" |C (O)||Software Segment||im Abgleich mit den bereits existenten Profilen.
+
|[{ SFT }]|| bgcolor="3366ff" |[0..*]|| bgcolor="3366ff" |C (O)||Software Segment||im Abgleich mit den bereits existenten Profilen.
 
|-
 
|-
 
|EVN||[1..1]||R||||
 
|EVN||[1..1]||R||||
Zeile 510: Zeile 477:
  
  
==48. ADT_A30==
+
==ADT_A30==
  
 
{| class="hl7table"
 
{| class="hl7table"
!Segment!!Kard.!!Ver¬wen¬dung!!Beschreibung!!Bemerkung
+
!Segment!!Kard.!!Verwendung!!Beschreibung!!Bemerkung
 
|-
 
|-
 
|MSH||[1..1]||R||Message Header||
 
|MSH||[1..1]||R||Message Header||
 
|-
 
|-
|[{ SFT }]|| bgcolor="3366ff" |[0..\*]|| bgcolor="3366ff" |C (O)||Software Segment||
+
|[{ SFT }]|| bgcolor="3366ff" |[0..*]|| bgcolor="3366ff" |C (O)||Software Segment||
 
|-
 
|-
 
|EVN||[1..1]||R||Event Type||
 
|EVN||[1..1]||R||Event Type||
Zeile 531: Zeile 498:
  
  
==49. ADT_A37==
+
==ADT_A37==
  
 
{| class="hl7table"
 
{| class="hl7table"
!Segment!!Kard.!!Ver¬wen¬dung!!Beschreibung!!Bemerkung
+
!Segment!!Kard.!!Verwendung!!Beschreibung!!Bemerkung
 
|-
 
|-
 
|MSH||[1..1]||R||Message Header||
 
|MSH||[1..1]||R||Message Header||
 
|-
 
|-
|[{ SFT }]|| bgcolor="3366ff" |[0..\*]|| bgcolor="3366ff" |C (O)||Software Segment||
+
|[{ SFT }]|| bgcolor="3366ff" |[0..*]|| bgcolor="3366ff" |C (O)||Software Segment||
 
|-
 
|-
 
|EVN||[1..1]||R||Event Type||
 
|EVN||[1..1]||R||Event Type||
Zeile 562: Zeile 529:
  
  
==50. ADT_A39==
+
==ADT_A39==
  
 
{| class="hl7table"
 
{| class="hl7table"
!Segment!!Kard.!!Ver¬wen¬dung!!Beschreibung!!Bemerkung
+
!Segment!!Kard.!!Verwendung!!Beschreibung!!Bemerkung
 
|-
 
|-
 
|MSH||[1..1]||R||Message Header||
 
|MSH||[1..1]||R||Message Header||
 
|-
 
|-
| [{ SFT }] || bgcolor="3366ff" |[0..\*]|| bgcolor="3366ff" |C (O)||Software Segment||
+
| [{ SFT }] || bgcolor="3366ff" |[0..*]|| bgcolor="3366ff" |C (O)||Software Segment||
 
|-
 
|-
 
|EVN||[1..1]||R||Event Type||
 
|EVN||[1..1]||R||Event Type||
Zeile 588: Zeile 555:
 
Tabelle 19: Nachrichtenstruktur ADT_A39
 
Tabelle 19: Nachrichtenstruktur ADT_A39
  
==51. ADT_A45==
+
==ADT_A45==
  
 
{| class="hl7table"
 
{| class="hl7table"
!Segment!!Kard.!!Ver¬wen¬dung!!Beschreibung!!Bemerkung
+
!Segment!!Kard.!!Verwendung!!Beschreibung!!Bemerkung
 
|-
 
|-
 
|MSH||[1..1]||R||Message Header||
 
|MSH||[1..1]||R||Message Header||
 
|-
 
|-
| [{ SFT }] || bgcolor="3366ff" |[1..\*]|| bgcolor="3366ff" |C (O)||Software Segment||
+
| [{ SFT }] || bgcolor="3366ff" |[1..*]|| bgcolor="3366ff" |C (O)||Software Segment||
 
|-
 
|-
 
|EVN||[1..1]||R||Event Type||
 
|EVN||[1..1]||R||Event Type||
Zeile 603: Zeile 570:
 
|[ PD1 ]|| bgcolor="3366ff" |[0..0]|| bgcolor="3366ff" |X (O)||Patient Additional Demographics||
 
|[ PD1 ]|| bgcolor="3366ff" |[0..0]|| bgcolor="3366ff" |X (O)||Patient Additional Demographics||
 
|-
 
|-
| { ||[1..\*]||R||||MERGE_INFO
+
| { ||[1..*]||R||||MERGE_INFO
 
|-
 
|-
 
|  MRG||[1..1]||R||Merge||
 
|  MRG||[1..1]||R||Merge||
Zeile 615: Zeile 582:
  
  
==52. ADT_A50==
+
==ADT_A50==
  
 
{| class="hl7table"
 
{| class="hl7table"
Zeile 622: Zeile 589:
 
|MSH||[1..1]||R||Message Header||
 
|MSH||[1..1]||R||Message Header||
 
|-
 
|-
|[{ SFT }]|| bgcolor="3366ff" |[0..\*]|| bgcolor="3366ff" |C (O)||Software Segment||
+
|[{ SFT }]|| bgcolor="3366ff" |[0..*]|| bgcolor="3366ff" |C (O)||Software Segment||
 
|-
 
|-
 
|EVN||[1..1]||R||Event Type||
 
|EVN||[1..1]||R||Event Type||
Zeile 638: Zeile 605:
  
  
=53. Abgleich mit IHE=
+
=Abgleich mit IHE=
  
==54. PAM-Profil==
+
==PAM-Profil==
 
In diesem Abschnitt werden die verschiedenen Nachrichten außerdem mit dem IHE ITI PAM-Profil (Patient Administration Management) abgeglichen. Hierfür werden alle Nachrichten in den beiden definierten Transaktionen aufgelistet. Dazu ist dann angegeben, ob es dazu bereits deutsche Profile gibt. Die sich daran anschließenden Spalten geben einen Bezug zu diesem Dokument bzw. zu den diversen Optionen an:
 
In diesem Abschnitt werden die verschiedenen Nachrichten außerdem mit dem IHE ITI PAM-Profil (Patient Administration Management) abgeglichen. Hierfür werden alle Nachrichten in den beiden definierten Transaktionen aufgelistet. Dazu ist dann angegeben, ob es dazu bereits deutsche Profile gibt. Die sich daran anschließenden Spalten geben einen Bezug zu diesem Dokument bzw. zu den diversen Optionen an:
  
==55. ITI-030: Patient Identity Management==
+
==ITI-030: Patient Identity Management==
  
 
{| class="hl7table"
 
{| class="hl7table"
!Ereig¬nis!!Beschreibung!!dt. Profile!!oben aufgelistet!!Merge Option!!Link/ Unlink
+
!Ereignis!!Beschreibung!!dt. Profile!!oben aufgelistet!!Merge Option!!Link/ Unlink
 
|-
 
|-
 
|A24||Verknüpfen von Patientendaten||X||X||||X
 
|A24||Verknüpfen von Patientendaten||X||X||||X
Zeile 664: Zeile 631:
  
  
==56. ITI-031: Patient Encounter Management==
+
==ITI-031: Patient Encounter Management==
  
 
{| class="hl7table"
 
{| class="hl7table"
!Ereig¬nis!!Beschreibung!!dt. Profile!!Basic Subset!!Enctr Mnmgt!!Pending Event!!adv. Enctr mngmt!!temporary patient transfer!!Historic Movemt
+
!Ereignis!!Beschreibung!!dt. Profile!!Basic Subset!!Enctr Mnmgt!!Pending Event!!adv. Enctr mngmt!!temporary patient transfer!!Historic Movemt
 
(+ZBE)
 
(+ZBE)
 
|-
 
|-
|A01||||X||X||X||X||X||X||X
+
|A01|| ||X||X||X||X||X||X||X
 
|-
 
|-
|A02||||X||||X||X||||||X
+
|A02|| ||X|| ||X||X|| || ||X
 
|-
 
|-
|A03||||X||X||X||X||X||X||X
+
|A03|| ||X||X||X||X||X||X||X
 
|-
 
|-
|A04||||X||X||X||X||X||X||X
+
|A04|| ||X||X||X||X||X||X||X
 
|-
 
|-
|A05||||X||||X||X||||||X
+
|A05|| ||X|| ||X||X|| || ||X
 
|-
 
|-
|A06||||X||||X||X||||||X
+
|A06|| ||X|| ||X||X|| || ||X
 
|-
 
|-
|A07||||X||||X||X||||||X
+
|A07|| ||X|| ||X||X|| || ||X
 
|-
 
|-
|A08||||X||X||X||X||X||X||
+
|A08|| ||X||X||X||X||X||X||
 
|-
 
|-
|A09||||X||||||||||X||
+
|A09|| ||X|| || || || ||X||
 
|-
 
|-
|A10||||X||||||||||X||
+
|A10|| ||X|| || || || ||X||
 
|-
 
|-
 
|A11||-> A01, A04||X||X||X||X||X||X||X
 
|A11||-> A01, A04||X||X||X||X||X||X||X
Zeile 696: Zeile 663:
 
|A13||-> A03||X||X||X||X||X||X||X
 
|A13||-> A03||X||X||X||X||X||X||X
 
|-
 
|-
|A14||||||||||X||||||X
+
|A14|| || || || ||X|| || ||X
 
|-
 
|-
|A15||||||||||X||||||X
+
|A15|| || || || ||X|| || ||X
 
|-
 
|-
|A16||||||||||X||||||X
+
|A16|| || || || ||X|| || ||X
 
|-
 
|-
|A21||||X||||||||X||||X
+
|A21|| ||X|| || || ||X|| ||X
 
|-
 
|-
|A22||||X||||||||X||||X
+
|A22|| ||X|| || || ||X|| ||X
 
|-
 
|-
|A25||-> A16||||||||X||||||X
+
|A25||-> A16|| || || ||X|| || ||X
 
|-
 
|-
|A26||-> A15||||||||X||||||X
+
|A26||-> A15|| || || ||X|| || ||X
 
|-
 
|-
|A27||-> A14||||||||X||||||X
+
|A27||-> A14|| || || ||X|| || ||X
 
|-
 
|-
|A32||-> A10||||||||||||X||
+
|A32||-> A10|| || || || || ||X||
 
|-
 
|-
|A33||-> A09||||||||||||X||
+
|A33||-> A09|| || || || || ||X||
 
|-
 
|-
|A38||-> A05||||||X||X||||||X
+
|A38||-> A05|| || ||X||X|| || ||X
 
|-
 
|-
|A40||||s.o.||X||X||X||X||X||
+
|A40|| ||s.o.||X||X||X||X||X||
 
|-
 
|-
|A44||||||||||||X||||
+
|A44|| || || || || ||X|| ||
 
|-
 
|-
|A52||-> A21||||||||||X||||X
+
|A52||-> A21|| || || || ||X|| ||X
 
|-
 
|-
|A53||-> A22||||||||||X||||X
+
|A53||-> A22|| || || || ||X|| ||X
 
|-
 
|-
|A54||||||||||||X||||X
+
|A54|| || || || || ||X||||X
 
|-
 
|-
|A55||-> A54||||||||||X||||X
+
|A55||-> A54|| || || || ||X|| ||X
 
|-
 
|-
|Z99||||||||||||||||X
+
|Z99|| || || || || || || ||X
 
|-
 
|-
 
|}
 
|}
Zeile 736: Zeile 703:
  
  
=57. Gegenüberstellung der Nachrichten und der gefüllten Segmente=
+
=Gegenüberstellung der Nachrichten und der gefüllten Segmente=
tbd.
 
  
 +
{{WorkBox|
 +
Muss noch erledigt werden...
 +
}}
  
  
 +
=Anhang A: Diverses=
  
=58. Anhang A: Diverses=
+
==Offene Fragen==
 
 
==59. Offene Fragen==
 
  
 
* Fehlen noch Szenarien?
 
* Fehlen noch Szenarien?
Zeile 756: Zeile 724:
 
* Wird ein Update der Konto-/Account-Nummern benötigt?
 
* Wird ein Update der Konto-/Account-Nummern benötigt?
  
{| class="hl7table"
 
! |!
 
  
 +
{{NoteBox|
 
Gibt es hierzu Meinungen?
 
Gibt es hierzu Meinungen?
|-
+
}}
|}
 
Abbildung 16: Offene Fragen
 
  
  
==60. Detaillierte Änderungshistorie==
+
==Detaillierte Änderungshistorie==
  
 
{| class="hl7table"
 
{| class="hl7table"
Zeile 783: Zeile 748:
 
|-
 
|-
 
|}
 
|}
 
 
  
  
 
[[Kategorie:Anfragen]]
 
[[Kategorie:Anfragen]]
 
[[Kategorie:Enzyklopädie]]
 
[[Kategorie:Enzyklopädie]]

Aktuelle Version vom 27. November 2014, 13:39 Uhr


Inhaltsverzeichnis

Whitepaper: Korrigieren von Patientendaten


Version 06
Stand: 25. März 2008
Dokumenten-OID: n.a.


Dokumentenhistorie

Version Stand Bearbeiter Beschreibung Dok.-OID
01 24.11.08 FO Erstellung n.a.
02 09.12.08 FO, VB Grundstruktur n.a.
03 23.02.09 FO weitere Details n.a.
04 24.02.09 FO, VB IHE n.a.
05 03.03.09 FO, BL IHE n.a.
06 25.03.09 FO, RS Bewegungen n.a.
07 26.11.14 FO Übernahme ins Wiki n.a.


Editor

  • Frank Oemig, AGFA HealthCare GmbH, Bonn

Autoren

  • Frank Oemig, AGFA HealthCare GmbH, Bonn

Mit Beiträgen von

  • Verena Bayer, Agfa HealthCare, Trier (VB)
  • Bettina Lieske, SAP (BL)
  • Rene Spronk, Ringholm, Essen (RS)


Autoren und Copyright-Hinweis, Nutzungshinweise

Nachnutzungs- bzw. Veröffentlichungsansprüche

Das vorliegende Dokument wurde von Agfa HealthCare GmbH in Kooperation mit der HL7-Benutzergruppe e.V. entwickelt. Die Nachnutzungs- bzw. Veröffentlichungs¬ansprü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.

Einleitung

Disclaimer

Es ist nicht berücksichtigt worden, dass es ebenso noch einen Abrechnungsfall geben muss, der über PID-18 sowie die dazugehörigen BAR-Nachrichten kommuniziert werden muss. Wenn dies als relevant erachtet wird, so muss das noch nachgeholt werden.

Szenario

Es kommt relativ häufig vor, dass Informationen falsch erfasst und korrigiert werden müssen. Die verschiedenen Kombinationen sollen in diesem Papier einmal näher erläutert werden. Hierbei interessieren insbesondere die Vor- und Nachbedingungen sowie die dafür zu ver¬wendenden Ereignisse sowie Segmente. In diesem Papier wird der Schwerpunkt auf die Identifikatoren gelegt. Inhaltliche Korrekturen wie bspw. Änderung von Namen werden hier nicht diskutiert.

Hintergrundinformation

Im Prinzip muss von folgender Struktur ausgegangen werden:

Id-korrektur 01.gif

Abbildung 1: grundlegende Beziehungen

Eine Person sollte nur einmal vorkommen, d.h. es sollte nur eine Personen-Identifikation geben. Systemtechnisch kann aber eine Person trotzdem mehrfach erfasst worden sein. Eine Person kann aber mehrmals als Patient in Erscheinung treten, d.h. es kann mehrere Patienten-Identifikationen geben. Des Weiteren kann es zu einem Patienten mehrere Fälle geben. Hierbei ist zu beachten, dass dasselbe Feld in PID (=PID-3) sowohl zur Identifikation der Person als auch des Patienten dient. Eine Unterscheidung wird über den Type-Code (=PID-3.7) vorgenommen. Ein Fall-Identifikation wird typischerweise über PV1-19 vorgenommen. Allerdings ist es auch möglich – insbesondere bei Fehlen von PV1 in einer Nachricht – eine Fallidentifikation ebenfalls über PID-3 mit dem dazugehörigen Type-Code (PID-3.7=VN) vorzunehmen.

Korrekturen

Einführung

Es besteht die Möglichkeit, Daten auf verschiedenen Ebenen zu korrigieren:

  • Person
  • Patient
  • Fall
  • Falldetails (Diagnosen, Prozeduren, ..)

Diese werden im nachfolgenden nun näher untersucht:

auf Person-Ebene

In diesem Unterabschnitt werden die Korrekturen an den Personendaten vorgenommen.

Update der Personen-Identifikation (Event A47)

In diesem Szenario bekommt die Person eine neue Identifikation. Im Prinzip bleiben ansonsten alle Daten erhalten.

Id-korrektur 02.gif

Abbildung 2: Update der Personen-Identifikation


Feld Beschreibung Bedingung
MRG-1 alte Personen-ID (#P1) MRG-1.5=PN
PID-3 neue Personen-ID (#P2) PID-3.5=PN

Tabelle 1: Update der Personen-Identifikation


Zusammenführen zweier Personen (Event A40)

In diesem Szenario werden alle Daten (Patienten, Fälle) von einer Person zu einer anderen (bereits existenten Person) überführt. Es handelt sich in diesem Sinne um ein Merge der Informationen.

Id-korrektur 03.gif

Abbildung 3: Zusammenführen zweier Personen

Diese Transaktion kann nicht mehr rückgängig gemacht werden. Einmal zusammengeführte Personendaten können nur über die anderen Transaktionen zu Personen/ Patienten/ Fälle/ etc. wieder entflechtet werden.

Feld Beschreibung Bedingung
MRG-1 alte Personen-ID (#P1) MRG-1.5=PN
PID-3 neue Personen-ID (#P2) PID-3.5=PN

Tabelle 2: Zusammenführen zweier Personen


Verknüpfen zweier Personen (Event A24)

In diesem Szenario werden die Daten zweier Personen miteinander verknüpft, d.h. verlinkt. Beide Personen sind vor und nach der Transaktion existent.

Id-korrektur 04.gif


Abbildung 4: Verknüpfen zweier Personen Anm.: Der Standard spricht explizit über „Patienten". Daher stellt sich die Frage, ob dieselbe Nachricht auch für „Personen" gilt?

Feld Beschreibung Bedingung
PID-3 (erstes PID) alte Personen-ID (#P1) PID-3.5=PN
PID-3 (zweites PID) neue Personen-ID (#P2) PID-3.5=PN

Tabelle 3: Verknüpfen zweier Personen


„Entknüpfen" zweier Personen (Event A37)

In diesem Szenario wird die Verknüpfung zwischen zwei Personen wieder aufgehoben. Beide Personen sind vor und nach der Transaktion existent.

Id-korrektur 05.gif

Abbildung 5: Entknüpfen zweier Personen

Feld Beschreibung Bedingung
PID-3 (erstes PID) alte Personen-ID (#P1) PID-3.5=PN
PID-3 (zweites PID) neue Personen-ID (#P2) PID-3.5=PN

Tabelle 4: Entknüfpen zweier Personen


auf Patienten-Ebene

Update der Patienten-Identifikation (Event A47)

In diesem Szenario bekommt der Patient eine neue Identifikation. Im Prinzip bleiben ansonsten alle Daten erhalten.

Id-korrektur 06.gif

Abbildung 6: Update der Patienten-Identifikation

Feld Beschreibung Bedingung
MRG-1 alte Patienten-ID (#P1) MRG-1.5=PI
PID-3 neue Patienten-ID (#P2) PID-3.5=PI
PID-3 Personen-ID PID-3.5=PN

Tabelle 5: Update der Patienten-Identifikation


Zusammenführen zweier Patienten (Event A40)

Hierbei wird ein Patient mit einem anderen zusammengeführt. Die übergeordneten Personen können dabei durchaus verschieden sein. Damit werden alle Fälle darunter automatisch verschoben, so dass diese in der Nachricht nicht explizit benannt werden müssen. Im Gegensatz zu vorhergehendem Szenario wird hier die Information über den Patienten gelöscht. D. h. wird im MRG-1 eine frühere Patienten-ID angegeben, so wird der Patient bei der Aktion gelöscht (Kap. 3.2.2). Wird im MRG-1 keine frühere Patienten-ID angegeben, so existiert diese nach dem Verarbeiten der A40 weiter (Kap. 3.2.3).

Id-korrektur 07.gif

Abbildung 7: Zusammenführen zweier Patienten

Feld Beschreibung Bedingung
MRG-1 frühere Personen-ID (#P1)
frühere Patienten-ID (#Pat1)
MRG-1.5=PN
MRG-1.5=PI
PID-3 neue Personen-ID (#P3)
neue Patienten-ID (#Pat3)
PID-3.5=PN
PID-3.5=PI

Tabelle 6: Zusammenführen zweier Patienten


Patientendaten an andere Person umhängen (Event A40)

Hierbei werden alle Daten für Patient 1 an eine andere Person angehängt.

Id-korrektur 08.gif

Abbildung 8: Patientendaten umhängen

Feld Beschreibung Bedingung
MRG-1 alte Personen-ID (#P1) MRG-1.5=PN
PID-3 neue Personen-ID (#P2) PID-3.5=PN
PID-3 Patienten-ID (#Pat1) PID-3.5=PI

Tabelle 7: Patientendaten umhängen

Durch die Angabe mehrerer Patienten-IDs in PID-3 müssten sich auch mehrere Patienten gleichzeitig umhängen lassen. Das setzt aber voraus, dass die ID nicht geändert wird. Letzteres müsste dann über eine andere Nachricht realisiert werden.

Verknüpfen zweier Patienten (Event A24)

In diesem Szenario werden die Daten zweier Patienten miteinander verknüpft, d.h. verlinkt. Beide Patienten sind vor und nach der Transaktion existent.

Id-korrektur 09.gif

Abbildung 9: Verknüpfen zweier Patienten

Feld Beschreibung Bedingung
PID-3 (erstes PID) alte Patienten-ID (#P1) PID-3.5=PI
PID-3 (zweites PID) neue Patienten-ID (#P2) PID-3.5=PI

Tabelle 8: Verknüpfen zweier Patienten


„Entknüpfen" zweier Patienten (Event A37)

In diesem Szenario wird die Verknüpfung zwischen zwei Patienten wieder aufgehoben. Beide Patienten sind vor und nach der Transaktion existent.

Id-korrektur 10.gif

Abbildung 10: Entknüpfen zweier Patienten

Feld Beschreibung Bedingung
PID-3 (erstes PID) alte/frühere Patienten-ID (#P1) PID-3.5=PI
PID-3 (zweites PID) neue Patienten-ID (#P2) PID-3.5=PI

Tabelle 9: Entknüpfen zweier Patienten


auf Fall-Ebene

Update der Fall-Identifikation (Event A50)

In diesem Szenario bekommt der Fall zu einem Patienten eine neue Identifikation. Im Prinzip bleiben ansonsten alle Daten erhalten. Auch bleibt der Fall an demselben Patienten „hängen".

Id-korrektur 11.gif

Abbildung 11: Update der Fall-Identifikation

Feld Beschreibung Bedingung
PID-3
MRG-1
Patienten-ID (#P1) PID-3.5=PI
MRG-1.5=PI
MRG-5 alte/frühere Fallnummer (#F1) MRG-5.5=VN
PV1-19 neue Fallnummer (#F2) PV1-19.5=VN

Tabelle 10: Update der Fall-Identifikation

Fall an andere Person umhängen (Event A45)

Hier wird ein Fall komplett an einen anderen Patienten und damit auch an eine andere Person angehängt. Die Fall-Identifikation bleibt unverändert.

Id-korrektur 12.gif

Abbildung 12: Fall umhängen

Feld Beschreibung Bedingung
MRG-1 frühere Personen-ID (#P1)
frühere Patienten-ID (#Pat1)
MRG-1.5=PN

MRG-1.5=PI

PID-3 neue Personen-ID (#P2)
neue Patienten-ID (#Pat2)
PID-3.5=PN
PID-3.5=PI
PV1-19 Fallnummer (#F1) PV1-19.5=VN

Tabelle 11: Fall umhängen


einzelnen Fall an anderen Patienten umhängen (Event A45)

Hierbei werden die Daten von einem bestimmten Fall an einen anderen Patienten, der aber zu derselben oder einen anderen Person gehört, angehängt. Der Patient existiert danach weiter.

Id-korrektur 13.gif

Abbildung 13: Fall umhängen

Feld Beschreibung Bedingung
MRG-1 frühere Patienten-ID (#Pat1)
frühere Personen-ID (#P1)
MRG-1.5=PI
MRG-1.5=PN
PID-3 neue Personen-ID (#P2)
neue Patienten-ID (#Pat4)
PID-3.5=PN
PID-3.5=PI
PV1-19 Fallnummer (#F1) PV1-19.5=VN

Tabelle 12: Fall umhängen


Zusammenführung zweier Fälle (Event A42)

Hierbei werden zwei Fälle zusammengeführt. Nach der Zusammenführung existiert der erste Fall nicht mehr, existierende Falldetails werden dabei auf den neuen Fall umgehängt. In der Beschreibung ist allerdings unklar, ob diese Fälle zu demselben Patienten gehören müssen oder nicht.

Id-korrektur 14.gif

Abbildung 14: Zusammenführung zweier Fälle


Segmente

Feld Beschreibung Bedingung
PID-3 neue Personen-ID (#P2)
neue Patienten-ID (#Pat2)
PID-3.5=PN
PID-3.5=PI
MRG-1 frühere Personen-ID (#P1)
frühere Patienten-ID (#Pat1)
MRG-1.5=PN
MRG-1.5=PI
MRG-5 frühere Fallnummer (#F1) MRG-5.5=VN
PV1-19 neue Fallnummer (#F2) PV1-19.5=VN

Tabelle 13: Zusammenführung zweier Fälle

auf Bewegungs-Ebene

Unterhalb der Fall-Ebene werden über Verlegungen Bewegungen realisiert, die über das ZBE-Segment eindeutig identifiziert werden können.

Korrektur der Bewegungs-Identifikation (Event A08)

Eine direkte Korrektur einer Bewegung oder auch einer ID für eine Bewegung ist nicht möglich. Aus diesem Grund wurde das ZBE-Segment auf nationaler Ebene eingeführt, um wenigstens eine Bewegung eindeutig identifizieren zu können und so falsche Informationen auf dieser Ebene überhaupt korrigieren zu können. Eine Korrektur muss auf dieser Ebene über Löschen und eine Neuanlage erfolgen.

Segmente

Feld Beschreibung Bedingung
ZBE-1 Bewegungs-ID
ZBE-4 Verarbeitungskennzeichen

Tabelle 14: Zusammenführung zweier Fälle


auf Falldetail-Ebene

Dieser Abschnitt behandelt, wie Detailinformationen zu einem Fall verschoben werden können.

Detaildaten zu einem Fall umhängen

In diesem Szenario sollen Details – wie bspw. Diagnosen, Maßnahmen, Leistungen oder Aufträge – von einem Fall zu einem anderen verschoben werden. Wie zu erwarten existiert hierfür kein Event und keine Nachricht. Die Daten sind also entsprechend zu stornieren/löschen und dann neu zu übermitteln.

Id-korrektur 15.gif

Abbildung 15: Detaildaten umhängen


Anmerkungen

Merge

Bei einem Merge von Datenbeständen kann davon ausgegangen werden, dass nicht alle Systeme diese Veränderungen nachvollziehen. Daher ist es ratsam, Nachrichten, die sich auf die alte ID beziehen, entsprechend weiterzuleiten.

Multiple IDs

Es kann durchaus vorkommen, dass sich mehrere unterschiedliche IDs auf dasselbe Objekt beziehen. In einem solchen Fall sollen alle IDs angegeben bzw. verändert werden.

Events

Events

Ereignis Beschreibung dt. Profil Nachrichtenstruktur
A24 Verknüpfen von Patientendaten X ADT_A24
A37 Auflösung einer Verknüpfung von Patienten¬daten X ADT_A37
A40 Zusammenführung v. Pat-Information über Patient-ID-Liste ADT_A39
A42 Zusammenführung v. Fall-Information über Fallnummer ADT_A39
A45 Korrekt. einer falschen Zuordnung bzgl. Fallnummer ADT_A45
A47 Änderung der Patient-ID-Liste (PID-3) ADT_A30
A50 Änderung der Fallnummer (PV1-19) ADT_A50

Tabelle 15: Events

Genutzte Nachrichtenstrukturen

genutzte Nachrichtenstrukturen

Gemäß obiger Liste werden dann folgende Nachrichtenstrukturen benötigt.

ADT_A24

Segment Kard. Verwendung Beschreibung Bemerkung
MSH [1..1] R Message Header
[{ SFT }] [0..*] C (O) Software Segment im Abgleich mit den bereits existenten Profilen.
EVN [1..1] R
PID [1..1] R
[ PD1 ] [0..0] X (O) im Abgleich mit den bereits existenten Profilen.
[ PV1 ] [0..1] CE (O)
[{ DB1 }] [0..0] X (O) im Abgleich mit den bereits existenten Profilen.
PID [1..1] R
[ PD1 ] [0..0] X (O)
[ PV1 ] [0..1] CE (O)
[{ DB1 }] [0..\*] X (O)

Tabelle 16: Nachrichtenstruktur ADT_A24


ADT_A30

Segment Kard. Verwendung Beschreibung Bemerkung
MSH [1..1] R Message Header
[{ SFT }] [0..*] C (O) Software Segment
EVN [1..1] R Event Type
PID [1..1] R Patient Identification
[ PD1 ] [0..0] X (O) Patient Additional Demographics
MRG [1..1] R Merge

Tabelle 17: Nachrichtenstruktur ADT_A30


ADT_A37

Segment Kard. Verwendung Beschreibung Bemerkung
MSH [1..1] R Message Header
[{ SFT }] [0..*] C (O) Software Segment
EVN [1..1] R Event Type
PID [1..1] R Patient Identification
[ PD1 ] [0..0] X (O) Patient Additional Demographics im Abgleich mit den bereits existenten Profilen.
[ PV1 ] [0..1] CE (O) Patient Visit
[{ DB1 }] [0..0] X (O) Disability
PID [1..1] R Patient Identification
[ PD1 ] [0..0] X (O) Patient Additional Demographics
[ PV1 ] [0..1] CE (O) Patient Visit
[{ DB1 }] [0..0] X (O) Disability

Tabelle 18: Nachrichtenstruktur ADT_A37


ADT_A39

Segment Kard. Verwendung Beschreibung Bemerkung
MSH [1..1] R Message Header
[{ SFT }] [0..*] C (O) Software Segment
EVN [1..1] R Event Type
{ [1..\*] R Event Type PATIENT
PID [1..1] R Patient Identification
[ PD1 ] [0..0] X (O) Patient Additional Demographics
MRG [1..1] R Merge
[ PV1 ] [1..0] Patient Visit
} PATIENT

Tabelle 19: Nachrichtenstruktur ADT_A39

ADT_A45

Segment Kard. Verwendung Beschreibung Bemerkung
MSH [1..1] R Message Header
[{ SFT }] [1..*] C (O) Software Segment
EVN [1..1] R Event Type
PID [1..1] R Patient Identification
[ PD1 ] [0..0] X (O) Patient Additional Demographics
{ [1..*] R MERGE_INFO
MRG [1..1] R Merge
PV1 [1..1] R Patient Visit
} MERGE_INFO

Tabelle 20: Nachrichtenstruktur ADT_A45


ADT_A50

Segment Kard. Ver¬wen¬dung Beschreibung Bemerkung
MSH [1..1] R Message Header
[{ SFT }] [0..*] C (O) Software Segment
EVN [1..1] R Event Type
PID [1..1] R Patient Identification
[ PD1 ] [0..0] X (O) Patient Additional Demographics
MRG [1..1] R Merge
PV1 [1..1] R Patient Visit

Tabelle 21: Nachrichtenstruktur ADT_A50


Abgleich mit IHE

PAM-Profil

In diesem Abschnitt werden die verschiedenen Nachrichten außerdem mit dem IHE ITI PAM-Profil (Patient Administration Management) abgeglichen. Hierfür werden alle Nachrichten in den beiden definierten Transaktionen aufgelistet. Dazu ist dann angegeben, ob es dazu bereits deutsche Profile gibt. Die sich daran anschließenden Spalten geben einen Bezug zu diesem Dokument bzw. zu den diversen Optionen an:

ITI-030: Patient Identity Management

Ereignis Beschreibung dt. Profile oben aufgelistet Merge Option Link/ Unlink
A24 Verknüpfen von Patientendaten X X X
A28 Personendaten hinzufügen ? X X
A31 Ändern personenbezogener Daten X X X
A47 Änderung der Pat.ID-Liste (PID-3) s.o. X X X
A37 Auflösung einer Verknüpfung von Patientendaten X X X
A40 Zusammenführung v. Pat-Information über patient ID-Liste s.o. X X

Tabelle 22: IHE PAM ITI-30


ITI-031: Patient Encounter Management

Ereignis Beschreibung dt. Profile Basic Subset Enctr Mnmgt Pending Event adv. Enctr mngmt temporary patient transfer Historic Movemt

(+ZBE)

A01 X X X X X X X
A02 X X X X
A03 X X X X X X X
A04 X X X X X X X
A05 X X X X
A06 X X X X
A07 X X X X
A08 X X X X X X
A09 X X
A10 X X
A11 -> A01, A04 X X X X X X X
A12 -> A02 X X X X
A13 -> A03 X X X X X X X
A14 X X
A15 X X
A16 X X
A21 X X X
A22 X X X
A25 -> A16 X X
A26 -> A15 X X
A27 -> A14 X X
A32 -> A10 X
A33 -> A09 X
A38 -> A05 X X X
A40 s.o. X X X X X
A44 X
A52 -> A21 X X
A53 -> A22 X X
A54 X X
A55 -> A54 X X
Z99 X

Tabelle 23: IHE PAM ITI-31


Gegenüberstellung der Nachrichten und der gefüllten Segmente


Anhang A: Diverses

Offene Fragen

  • Fehlen noch Szenarien?
  • Sind Szenarien überflüssig?
  • Werden alle diese Nachrichten wirklich benötigt?
  • Welche dieser Nachrichten sollten noch als Profil ausgearbeitet werden?

(Priorität sollten die von IHE geforderten haben)

  • Welche Optionen des PAM-Profils sollten unterstützt werden?
  • Welche Konflikte existieren zwischen IHE ITI und den deutschen Profilen?

(Bspw. EVN-7 ist bei uns optional, bei IHE "required but may be empty".)

  • Wird ein Update der Konto-/Account-Nummern benötigt?



Detaillierte Änderungshistorie

Version Änderungen gegenüber Vorversion Kapitel/Seitenzahl
01 Erstellung alle
02 Grundstruktur alle
03 weitere Details: Segmente, Bedingungen alle
04 IHE alle
05 IHE alle
06 Überarbeitung nach TC-Sitzung, Bewegungen, Layout alle