Whitepaper: Korrigieren von Patientendaten

Aus Hl7wiki
Nachrichtenprofile
Wechseln zu: Navigation, Suche


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.


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