Whitepaper: Korrigieren von Patientendaten

Aus Hl7wiki
Nachrichtenprofile
Wechseln zu: Navigation, Suche
(Übernahme aus hl7.de)
 
Zeile 91: Zeile 91:
 
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}}
−
 
−
 
−
 
  
  
Zeile 108: Zeile 105:
 
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 129:
 
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
  
Zeile 151: Zeile 150:
 
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.
  
Zeile 171: Zeile 172:
 
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?
Zeile 188: Zeile 191:
  
  
−
===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====
+
====Details====
  
 
{| class="hl7table"
 
{| class="hl7table"
Zeile 207: Zeile 211:
  
  
−
==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
  
−
 
+
====Details====
−
====17. Details====
 
  
 
{| class="hl7table"
 
{| class="hl7table"
Zeile 232: Zeile 236:
  
  
−
===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====
+
====Details====
  
 
{| class="hl7table"
 
{| class="hl7table"
Zeile 253: Zeile 258:
  
  
−
===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
  
−
 
+
====Details====
−
====21. Details====
 
  
 
{| class="hl7table"
 
{| class="hl7table"
Zeile 276: Zeile 281:
 
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====
+
====Details====
  
 
{| class="hl7table"
 
{| class="hl7table"
Zeile 295: Zeile 301:
  
  
−
===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====
+
====Details====
  
 
{| class="hl7table"
 
{| class="hl7table"
Zeile 315: Zeile 322:
  
  
−
==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
  
−
 
+
====Details====
−
====28. Details====
 
  
 
{| class="hl7table"
 
{| class="hl7table"
Zeile 339: Zeile 346:
 
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
  
−
 
+
====Details====
−
====30. Details====
 
  
 
{| class="hl7table"
 
{| class="hl7table"
Zeile 362: Zeile 368:
  
  
−
===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====
+
====Details====
  
 
{| class="hl7table"
 
{| class="hl7table"
Zeile 383: Zeile 390:
  
  
−
===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"
Zeile 412: Zeile 420:
  
  
−
==35. auf Bewegungs-Ebene==
+
==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 439:
  
  
−
==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=
 
=43. Events=
  
−
==44. Events==
+
==Events==
  
 
{| class="hl7table"
 
{| class="hl7table"
Zeile 474: Zeile 483:
  
  
−
=45. Genutzte Nachrichtenstrukturen=
+
=Genutzte Nachrichtenstrukturen=
  
−
==46. genutzte Nachrichtenstrukturen==
+
==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"
Zeile 510: Zeile 519:
  
  
−
==48. ADT_A30==
+
==ADT_A30==
  
 
{| class="hl7table"
 
{| class="hl7table"
Zeile 531: Zeile 540:
  
  
−
==49. ADT_A37==
+
==ADT_A37==
  
 
{| class="hl7table"
 
{| class="hl7table"
Zeile 562: Zeile 571:
  
  
−
==50. ADT_A39==
+
==ADT_A39==
  
 
{| class="hl7table"
 
{| class="hl7table"
Zeile 588: Zeile 597:
 
Tabelle 19: Nachrichtenstruktur ADT_A39
 
Tabelle 19: Nachrichtenstruktur ADT_A39
  
−
==51. ADT_A45==
+
==ADT_A45==
  
 
{| class="hl7table"
 
{| class="hl7table"
Zeile 615: Zeile 624:
  
  
−
==52. ADT_A50==
+
==ADT_A50==
  
 
{| class="hl7table"
 
{| class="hl7table"
Zeile 638: Zeile 647:
  
  
−
=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"
Zeile 664: Zeile 673:
  
  
−
==56. ITI-031: Patient Encounter Management==
+
==ITI-031: Patient Encounter Management==
  
 
{| class="hl7table"
 
{| class="hl7table"
Zeile 736: Zeile 745:
  
  
−
=57. Gegenüberstellung der Nachrichten und der gefüllten Segmente=
+
=Gegenüberstellung der Nachrichten und der gefüllten Segmente=
 
tbd.
 
tbd.
  
Zeile 742: Zeile 751:
  
  
−
=58. Anhang A: Diverses=
+
=Anhang A: Diverses=
  
−
==59. Offene Fragen==
+
==Offene Fragen==
  
 
* Fehlen noch Szenarien?
 
* Fehlen noch Szenarien?
Zeile 756: Zeile 765:
 
* Wird ein Update der Konto-/Account-Nummern benötigt?
 
* Wird ein Update der Konto-/Account-Nummern benötigt?
  
−
{| class="hl7table"
 
−
! |!
 
  
 +
{{FaqBox|
 
Gibt es hierzu Meinungen?
 
Gibt es hierzu Meinungen?
−
|-
+
}}
−
|}
 
−
Abbildung 16: Offene Fragen
 
  
  
−
==60. Detaillierte Änderungshistorie==
+
==Detaillierte Änderungshistorie==
  
 
{| class="hl7table"
 
{| class="hl7table"
Zeile 783: Zeile 789:
 
|-
 
|-
 
|}
 
|}
−
 
−
 
  
  
 
[[Kategorie:Anfragen]]
 
[[Kategorie:Anfragen]]
 
[[Kategorie:Enzyklopädie]]
 
[[Kategorie:Enzyklopädie]]

Version vom 25. November 2014, 14:58 Uhr

Under construction icon-blue.svg
 This article or section is in the middle of an expansion or major restructuring and is not yet ready for use. You are welcome to assist in its construction by editing it as well. If this article has not been edited in several days, please remove this template.
This article was last edited by Foemig (talk| contribs) 10 years ago. (Purge)
Diese Seite oder Abschnitt ist derzeit ein Entwurf und ist noch nicht fertiggestellt. Du bist eingeladen, bei der Fertigstellung mitzuwirken. Wenn dieser Beitrag länger als einige Tage nicht editiert wurde, entferne diese Vorlage.
This article was last edited by Foemig (talk| contribs) 10 years ago. (Purge)


Inhaltsverzeichnis

Whitepaper: Korrigieren von Patientendaten

Logo-hl720.jpg
{{{Title}}}
Whitepaper: Korrigieren von Patientendaten
Nachrichtenprofile
vorgelegt von:
HL7-Deutschland
in Arbeit
Version: 01
Datum: 2009
Status: Si-draft.svg Entwurf
Verfahren: {{{Verfahren}}}
Realm: Flag de.svg Deutschland
Copyright © 2009: HL7 Deutschland


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.


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, Nutzungs¬hinweise

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


Details

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.

Details

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?

Details

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

Details

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

Details

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


Details

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

Details

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

Details

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


Details

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

Details

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

Details

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


Details

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.

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

Tabelle 17: Nachrichtenstruktur ADT_A30


ADT_A37

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

Ereig¬nis 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

Ereig¬nis 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

tbd.



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?


Vorlage:FaqBox


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
Abgerufen von „https://wiki.hl7.de/index.php?title=Korrekturen_von_Identifikatoren&oldid=20871“