Whitepaper: Korrigieren von Patientendaten

Whitepaper: Korrigieren von Patientendaten

{{{Title}}}

Whitepaper: Korrigieren von Patientendaten

Nachrichtenprofile

vorgelegt von:
HL7-Deutschland

in Arbeit

Version:	01
Datum:	2009
Status:	Entwurf
Verfahren:	{{{Verfahren}}}
Realm:	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.
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:

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.

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.

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.

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.

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.

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).

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.

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.

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.

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".

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.

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.

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.

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.

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

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