-
Die
Zusammenarbeit in einem verteilten Radiologiesystem ist unter anderem
in dem internationalen Standard IHE (Integrating Healthcare Enterprise)
geregelt. Der Standard IHE setzt auf den Standards DICOM (Digital
Imaging and Communications in Medicine) und HL7 (Health Level 7)
auf und erweitert diese in Hinblick auf die für den Standard IHE einschlägigen Profile
bzw. Szenarien. Zur Beschreibung der Zusammenarbeit sind in dem
Standard IHE Aktoren, deren Rollen sowie deren Beteiligung an den
Szenarien definiert.
-
Beispielweise
sind in dem Standard IHE folgende Aktoren und Rollen definiert:
- – Order
Filler – wird üblicherweise
von einem so genannten Radiology Information System (RIS) gebildet. Das
RIS dient zur Registrierung von Patienten und zur Planung von Untersuchungen. Änderungen
an den zugehörigen
Daten werden am RIS durchgeführt
und von dort an andere Komponenten des verteilten Systems weitergegeben.
- – Image
Manager/Image Archive – wird üblicherweise
von einem so genannten Picture Archiving and Communication System
(PACS) gebildet. Hier werden Bilder gespeichert und zur Verfügung gestellt.
Weiterhin wird über
durchgeführte
Untersuchungsschritte benachrichtigt.
- – Acquisition
Modality: Bei diesem Aktor werden Bilder erstellt und an den Image
Manager verschickt.
-
Diese
Aktoren sind beispielsweise an folgenden Szenarien beteiligt:
- – Scheduled
Workflow: Der Scheduled Workflow ist das Standardszenario für die Zusammenarbeit
in einem verteilten Radiologiesystem. Es werden zunächst Untersuchungen
ordnungsgemäß am RIS
geplant. Die dabei generierten Patienten- und Untersuchungsdaten
werden an die Acquisition Modality in Form einer Modality Worklist
und an das PACS in Form eines Order Schedule gesendet, so dass alle
beteiligten Komponenten des Systems einen übereinstimmenden, konsistenten,
d.h. synchronen Datenbestand aufweisen. Zur einem späteren Zeitpunkt
werden an der Acquisition Modality Bilder akquiriert, den lokal
gespeicherten Daten zugeordnet und zusammen mit sie kennzeichnenden
Schlüsseldaten
an das PACS gesendet. Am PACS werden die Bilder gespeichert und
mit Hilfe der empfangenen, kennzeichnenden Schlüsseldaten den lokal gespeicherten
Patienten- und Untersuchungsdaten zugeordnet. Die lokalen Zuordnungen
werden in allen Komponenten des Systems identisch durchgeführt, weil
deren lokalen Datenbestände
aufgrund des definierten Ablaufs synchrone Schlüsseldaten aufweisen.
- – Patient
Information Reconciliation: Dieses Szenario tritt z.B. nach einer
Notfallaufnahme ein. Die Bilder werden zuerst akquiriert. Auch die
erforderlichen Patienten- und Untersuchungsdaten werden von Hand
an der Acquisition Modality eingegeben. Die Bilder und ggf. auch
die erfassten Daten werden an das PACS gesendet. Erst später wird
die Untersuchung am RIS nachgeplant. Durch einen definierten Nachrichtenaustausch
werden Dateninkonsistenzen zwischen RIS und PACS vermieden.
-
Die
Aktoren können
infolge der genormten Schnittstellen und Abläufe besonders leicht nicht
nur als integriertes Produkt realisiert und verkauft werden, sondern
auch als ein System mehrerer, von unterschiedlichen Herstellern
getrennt realisierter und verkaufter Produkte, die jeweils einen
Teil der genormten Gesamtfunktionalität durchführen und so zusammenwirken,
dass insgesamt die gleiche Funktionalität realisiert wird, wie bei
einer integrierten Realisierung der genormten Funktionalität.
-
Diese
Produkte können
auch als Computerprogrammprodukte ausgebildet sein, die von Hardware (z.B.
zumindest ein Prozessor) ausgeführt
werden, von der die sichtbare, gegenständliche Ausführungsumgebung
der Produkte gebildet wird. Diese Ausführung wird häufig von
Supportsoftware (z.B. Multitasking bzw. Multithreading Betriebssystem,
Datenbanksystem, Windows System) unterstützt.
-
Die
Umsetzung der beschriebenen Architektur in konkrete Lösungen ist
infolge der Verteiltheit des Systems und der Vielzahl an unterschiedlichen
Systemkomponenten und Anforderungen eine komplexe technische Problemstellung.
-
Es
ist Aufgabe der Erfindung, zumindest eines der bestehenden Probleme
zu erkennen und durch Angabe von zumindest einer Lehre zum technischen
Handeln zu lösen.
-
Die
Erfindung beruht auf folgenden Erkenntnissen:
- – Es gibt
unter den Daten zwei Schlüsselattribute,
die in dem Standard HL7 nicht berücksichtigt werden:
– Accession
Number (AccNo), die zur Identifizierung eines Order/Imaging Service
Request dient;
– Study
Instance UID (SIUid), mit deren Hilfe eine Requested Procedure identifiziert
wird.
- – Es
gibt Modalitäten,
die über
keine Modality Worklist Schnittstelle verfügen. Hier werden alle Patienten- und
Untersuchungsdaten manuell eingegeben und nicht automatisch über eine
Worklist eingespielt. Unter anderem werden dabei auch die Accession
Number oder die Study Instance UID erfasst. Hierbei können, z.B.
infolge von Tippfehlern, falsche, d.h. nicht synchrone Daten entstehen.
- – Es
gibt Produkte, bei denen eine manuelle Veränderung der lokalen Daten möglich ist.
Durch lokale Änderung
einer Accesssion Number oder einer Study Instance UID können somit
selbst bei korrekter Übermittlung
mit Hilfe einer Modality Worklist nachträglich falsche, d.h. nicht synchrone
Daten entstehen.
- – Der
Order Filler RIS und der Image Manager PACS sind real häufig separate
Systemkomponenten mit eigenen, lokalen Datenbeständen, die an einer der Komponenten
erfasst und über
die HL7 Nachrichten an die anderen Komponenten weitergegeben und
damit anfangs automatisch synchronisiert werden. Der dazu erforderliche
Datenaustausch ist in dem Erweiterungsstandard IHE des Standards
HL7 in den eingangs beschriebenen Szenarien "Scheduled Workflow" und "Patient Information Reconciliation" definiert. In dem Standard
IHE ist dabei beschrieben, wie die Accession Number und die Study
Instance UID von dem Order Filler RIS an den Image Manager PACS
in einer Order Nachricht zu schicken sind.
Offen ist aber,
wie diese Werte korrigiert werden sollen, falls sie, wie vorstehend
aufgezeigt, nicht mehr synchron sein sollten. Die genannten Szenarien
gehen davon aus, dass eine einmal zu Beginn hergestellte Synchronität dauerhaft
erhalten bleibt. Es finden sich keine Profile, wie während des
Betriebs falsche Schlüsseldaten
von Untersuchungen zentral korrigiert und wie diese Korrektur an
andere Systemkomponenten weitergegeben werden sollen, damit die
Datenbestände
der beteiligten Aktoren wieder konsistent, d.h. synchron werden. - – Wenn
falsche Daten mit den Bildern an das PACS gesendet werden, können die
Bilder entweder gar nicht zugeordnet werden, oder es kommt zu Fehlzuordnungen.
Dies kann zur Wiederholung von Untersuchungen, Datenverlust oder
Fehldi agnosen infolge von falsch zugeordneten Bildern führen.
-
Die
bekannten Techniken lösen
die erkannte Problematik nicht.
-
Die
vorstehend beschriebenen, erfindungsgemäßen Ausführungsformen des Verfahrens
können
auch als Computerprogrammprodukt ausgebildet sein, wobei der Computer
zur Durchführung
des oben beschriebenen, erfindungsgemäßen Verfahrens veranlasst wird
und dessen Programmcode durch einen Prozessor ausgeführt wird.
-
Eine
alternative Aufgabenlösung
sieht ein Speichermedium vor, das zur Speicherung des vorstehend beschriebenen,
computerimplementierten Verfahrens bestimmt ist und von einem Computer
lesbar ist.
-
Darüber hinaus
ist es möglich,
dass einzelne Komponenten des vorstehend beschriebenen Verfahrens
in einer verkaufsfähigen
Einheit und die restlichen Komponenten in einer anderen verkaufsfähigen Einheit ausgeführt werden
können.
Eine erfindungsgemäße weitere
Lösung
der Aufgabe liegt deshalb in einem Produkt, umfassend:
- – zumindest
einen Order Filler,
- – zumindest
ein ein Image Archive umfassender Image Manager und/oder
- – zumindest
eine Acquisition Modality eines verteilten Radiologiesystems, welches
Mittel umfasst, die zur Durchführung
derjenigen Schritte eines Verfahrens nach zumindest einem der vorstehend
beschriebenen Verfahrensaspekte eingerichtet sind, die von dem Produkt
bewirkt werden, wobei zumindest ein weiteres Produkt zur Durchführung der
restlichen Schritte des Verfahrens eingerichtet ist und durch Zusammenwirkung
der zumindest zwei Produkte alle Schritte des Verfahrens durchgeführt werden.
-
Weitere
vorteilhafte Ausführungsformen
ergeben sich aus den Unteransprüchen.
-
In
der folgenden detaillierten Figurenbeschreibung werden nicht einschränkend zu
verstehende Ausführungsbeispiele
mit deren Merkmalen und weiteren Vorteilen anhand der Zeichnung
besprochen. In dieser zeigen:
-
1 ein
beispielhaftes verteiltes Radiologiesystem RS, umfassend mehrere
Aktoren, die als Order Filler RIS, Image Manager PACS und Acquisition
Modality AM ausgebildet sind;
-
2 eine
beispielhafte Datenstruktur zur Verwaltung von Patienten- und Untersuchungsdaten
sowie von Untersuchungen und dabei erzeugten Bildern;
-
3 eine
Korrektur einer inkonsistenten Dateninstanz AccNo mit einer unbekannten
Dateninstanz AccNo;
-
4 eine
Korrektur einer inkonsistenten Dateninstanz AccNo mit einer bekannten
Dateninstanz AccNo;
-
5 eine
Korrektur einer inkonsistenten Dateninstanz SIUid mit einer unbekannten
Dateninstanz SIUid;
-
6 eine
Korrektur einer inkonsistenten Dateninstanz SIUid mit einer bekannten
Dateninstanz SIUid.
-
7 eine
Korrektur einer inkonsistenten Dateninstanz PatId;
-
8 eine
Korrektur von inkonsistenten Dateninstanzen PatId, SIUid;
-
9 eine
Korrektur von inkonsistenten Dateninstanzen PatId, AccNo;
-
10 eine
Korrektur von inkonsistenten Dateninstanzen PatId, AccNo, SIUid.
-
Als
eine Lösung
für die
erwünschte
Synchronisation eines verteilten Radiologiesystems RS wird vorgeschlagen,
falsche Schlüsseldaten
zu erkennen, vorzugsweise zentral zu korrigieren und die korrigierten
Daten an die von der erkannten Dateninkonsistenz betroffenen Aktoren
weiterzugeben, damit deren Datenbestände wieder konsistent, d.h.
synchron sind.
-
Besonders
schöne
Vorteile ergeben sich, wenn dazu die bereits bestehenden Standards
wie z.B. der Standard IHE oder die Standards HL7, DICOM erweitert
werden. Durch diese Erweiterung wird es möglich, Inkonsistenzen zwischen
den lokalen Datenbeständen
von Aktoren eines verteilten Radiologiesystems herstellerübergreifend
zu beseitigen. Diese Erweiterung ist auf alle Produkte anwendbar,
die als diese Aktoren agieren. Somit kann sie standardisiert werden.
-
In 1 ist
ein beispielhaftes verteiltes Radiologiesystem RS dargestellt. Es
umfasst einen Order Filler RIS zur Planung von Untersuchungen, eine
Acquisition Modality AM zur Erfassung von Bildern B, die im Rahmen
von Untersuchungen entstehen und einen Image Manager PACS zur Verwaltung
und Archivierung der Bilder B. Die drei Aktoren RIS, PACS, AM umfassen
jeweils einen lokalen Datenbestand mit lokalen Instanzen der Daten,
die so hinterlegt sind, dass Untersuchungen und Untersuchungsergebnisse
den richtigen Patienten und umgekehrt zugeordnet werden können. Von
dem Order Filler RIS werden erfasste Daten der Modality AM mit Hilfe
der eingangs beschriebenen Modality Worklists MW und dem Image Manager
PACS mit Hilfe der eingangs beschriebenen Order Schedules OS übermittelt.
Weiterhin werden an der Modality AM erfasste Bilder B von dort an
den Image Manager PACS übermittelt.
-
Zur
Verwaltung der Daten ist in dem Datenbestand eine hierarchisch organisierte
Struktur von Zuordnungen vorgesehen, die mit Hilfe von Schlüsseldaten
PadId, AccNo, SIUid realisiert ist, die zur Zuordnung von Untersuchungen
und Untersuchungsergebnissen zu Patienten und umgekehrt dienen.
Diese hierarchische Struktur ist in 2 exemplarisch
dargestellt. Danach ist eine Untersuchung, bezeichnet als Imaging
Service Request ISR, einem Patienten Pat über dessen Schlüssel PatId – auch Patientennummer
genannt – zugeordnet.
Die Untersuchung ISR ist durch einen als Accession Number AccNo
ausgebildeten Schlüssel
gekennzeichnet. Eine Untersuchung ISR umfasst einzelne Untersuchungsverfahren
bzw. -prozeduren, bezeichnet als Requested Procedure RP und gekennzeichnet
durch einen als Study Instance UID SIUid ausgebildeten Schlüssel, die
ihrerseits einzelne Untersuchungsschritte umfassen, die als Scheduled
Procedure Steps SPS bezeichnet werden. Die Untersuchungsprozeduren
RP sind den Untersuchungen ISR über
deren Schlüssel AccNo
und die Untersuchungsschritte SPS den Untersuchungsprozeduren RP über deren
Schlüssel
SIUid zugeordnet. An den Blättern
dieser baumartigen geordneten hierarchischen Datenstruktur sind
die Untersuchungsergebnisse wie z.B. Röntgenbilder angeordnet und
den Untersuchungsschritten zugeordnet. Durch diese Struktur ist
somit jedes Untersuchungsergebnis eines Untersuchungsschrittes durch
ein Datentupel {PatID; AccNo; SIUid} gekennzeichnet.
-
Dieses
Datentupel wird bei Übermittlung
eines Untersuchungsergebnisses im sendenden Aktor ermittelt und
zusammen mit dem Untersuchungsergebnis dem empfangenden Aktor geschickt.
Dort wird das empfangene Tupel analysiert und im lokalen Datenbestand
gesucht. Diese Suche kann fehlschlagen. Dies kann zwei Ursachen
haben: 1) Das empfangene Untersuchungsergebnis ist beim Empfänger noch
nicht bekannt. Dann kann es lediglich in bekannter Weise in den
lokalen Datenbestand erstmals eingefügt werden; 2) Das empfangene
Datentupel steht im Widerspruch zum lokalen Datenbestand und lässt sich
nicht in bekannter Weise in diesen einfügen. In diesem Fall liegt eine
erfindungsgemäße Dateninkonsistenz
vor.
-
Die
Dateninkonsistenz kann unterschiedliche Ursachen haben. Deshalb
ist in Abhängigkeit
von der Ursache eine dazu passende Korrekturprozedur zur Synchronisation
des inkonsistenten Datenbestands auszuwählen, die beispielsweise als
Ersetzen CHANGE, Verschiebung MOVE und/oder als Verschmelzung MERGE ausgebildet
ist. Erfindungsgemäß werden
zunächst
korrigierte Daten erfasst. Diese Erfassung erfolgt bevorzugt an
einem zentralen Aktor, beispielsweise dem Order Filler RIS. Im Anschluss
werden den von der Dateninkonsistenz betroffenen Aktoren zumindest
die korrigierten Daten mitgeteilt. Vorzugsweise wird die Mitteilung
mit Hilfe von genormten HL7 Transaktionen bewirkt, die gegebenenfalls
ein spezielles Feld ausweisen, in dem die korrigierten Daten hinterlegt
sind. Diese Transaktionen weisen beispielsweise folgende Syntax
auf:
MSH, PID, ZPA
-
Die
MSH und PID Segmente sind in dem Standard HL7 beschrieben. Das Segment
ZPA (Patient Administration Request) ist beispielsweise wie folgt
definiert:
-
Weiterhin
sind beispielsweise folgende HL7 Transaktionen vorgesehen, in denen
das Segment ZPA hinterlegt wird:
-
Die
Auswahl der passenden Korrekturprozedur(en) erfolgt unter Berücksichtigung
der korrigierten Daten. Verfeinert wird diese Auswahl, wenn auch
der aktuelle Datenbestand berücksichtigt
wird. Diese Auswahl kann im zentralen Aktor vor Mitteilung der korrigierten
Daten oder in den betroffenen Aktoren nach Mitteilung der korrigierten
Daten erfolgen.
-
Nachfolgend
wird beispielhaft an Hand einiger ausgewählter Szenarien ausgeführt, wie
die den Szenarien zu Grunde liegenden Inkonsistenzen erfindungsgemäß korrigiert
werden. Insbesondere wird die Auswahl der Korrekturprozeduren näher erläutert, wobei
betont sei, dass die angegebenen Korrekturprozeduren nicht zwingend
genau die beispielhaft ausgeführten
sein müssen,
sondern dass durch alternative Korrekturprozeduren mit entsprechend
angepasster Parametrisierung ebenfalls die erwünschte Korrektur bewirkt werden
kann.
-
Es
wird bei den ausgewählten
Szenarien davon ausgegangen, dass ein Untersuchungsergebnis eines Untersuchungsschrittes
empfangen wird, das durch ein Datentupel {PatID; AccNo; SIUid} gekennzeichnet
ist.
-
1) Correct Patient/Study – wrong
AccNo
-
Im
lokalen Datenbestand werden die Schlüssel PatId und SIUid gefunden.
Die beiden Schlüssel
sind einander zugeordnet. Der Schlüssel AccNo wird nicht gefunden.
Diese Informationen werden angezeigt. Als Folge wird ein korrigierter
Schlüssel
AccNo erfasst. Es wird nun geprüft,
ob der korrigierte Schlüssel
AccNo bereits bekannt ist.
-
Für den Fall,
dass der korrigierte Schlüssel
AccNo noch nicht bekannt ist, wird als Korrekturprozedur z.B. ein
Ersetzen CHANGE des bisherigen Schlüssels AccNo durch den korrigierten
Schlüssel
AccNo festgelegt. Die Auswirkungen der Korrektur auf den Datenbestand
sind in 3 dargestellt.
-
Für den Fall,
dass der korrigierte Schlüssel
AccNo bereits bekannt ist, wird als Korrekturprozedur z.B. eine
Verschmelzung MERGE des bisherigen Schlüssels AccNo mit dem bekannten
Schlüssel
AccNo festgelegt. Die Auswirkungen der Korrektur auf den Datenbestand
sind in 4 dargestellt.
-
Die
zugehörige
HL7 Transaktion zur Mitteilung der korrigierten Daten ist im Falle
eines Ersetzens CHANGE beispielsweise wie folgt ausgebildet:
MSH|^&~\|RIS||RIS|20041015142431||ZPA^I03|247|P|2.3.1
PID|1|PAT000084|Lastname^Firstname||19121212|M
ZPA||ACCNO12345^ACCNO54321
-
Damit
wird die Korrektur des bisherigen Schlüssel AccNo 'ACCN012345' auf den neuen Schlüssel AccNo 'ACCNO54321' mitgeteilt. Die Angaben zum Patienten
sind optional. Sie dienen zur Überprüfung, ob
die inkonsistente Untersuchung auch nach der Korrektur noch demselben
Patienten zugeordnet ist. Beide Schlüssel AccNo sollen bei diesem
Beispiel dem Patienten mit dem Schlüssel PatId 'PAT000084' zugeordnet bleiben. Dessen Name ist 'Lastname^Firstname', sein Geburtsdatum '12.12.1912', sein Geschlecht 'M' (= männlich).
-
2) Correct Patient/AccNo – unknown
Study
-
Im
lokalen Datenbestand werden die Schlüssel PatId und AccNo gefunden.
Die beiden Schlüssel
sind einander zugeordnet. Der Schlüssel SIUid wird nicht gefunden.
Diese Informationen werden angezeigt. Als Folge wird ein korrigierter
Schlüssel
SIU id erfasst. Es wird nun geprüft,
ob der korrigierte Schlüssel
SIUid bereits bekannt ist.
-
Für den Fall,
dass der korrigierte Schlüssel
SIUid noch nicht bekannt ist, wird als Korrekturprozedur z.B. ein
Ersetzen CHANGE des bisherigen Schlüssels SIUid durch den korrigierten
Schlüssel
SIUid festgelegt. Die Auswirkungen der Korrektur auf den Datenbestand
sind in 5 dargestellt.
-
Für den Fall,
dass der korrigierte Schlüssel
SIUid bereits bekannt ist, wird als Korrekturprozedur z.B. eine
eine Verschmelzung MERGE des bisherigen Schlüssels SIUid mit dem bekannten
Schlüssel
SIUid festgelegt. Die Auswirkungen der Korrektur auf den Datenbestand
sind in 6 dargestellt.
-
Die
zugehörige
HL7 Transaktion zur Mitteilung der korrigierten Daten ist im Falle
einer Verschmelzung MERGE beispielsweise wie folgt ausgebildet:
MSH|^&~\|RIS||RIS|20041015142431||ZPA^S04|247|P|2.3.1
PID|1|PAT000084||Lastname^Firstname||19121212|M
ZPA|1.2.5.354699234.5^1.2.5.354699234.6|ACCNO12345
-
Damit
wird eine Korrektur des bisherigen Schlüssel SIUid '1.2.5.354699234.5' auf den neuen Schlüssel SIUid '1.2.5.354699234.6' mitgeteilt. Die Angaben zum Patienten
sind wiederum optional und dienen demselben Zweck wie vorstehend
erläutert.
Dasselbe gilt für
die optionale Angabe des Schlüssels
AccNo.
-
3) Correct AccNo/Study – wrong
Patient
-
Im
lokalen Datenbestand werden die Schlüssel AccNo und SIUid gefunden.
Die beiden Schlüssel
sind einander zugeordnet. Der Schlüssel PatId wird nicht gefunden.
Diese Informationen werden angezeigt. Als Folge wird ein korrigierter
Schlüssel
Pa tId durch Auswahl aus einer Liste bereits bekannter Schlüssel PatId
erfasst.
-
Der
korrigierte Schlüssel
PatId ist infolge der vorstehenden Auswahlprozedur bereits bekannt,
so dass keine Überprüfung des
korrigierten Schlüssels
PatId erforderlich ist. Es wird als Korrekturprozedur z.B. eine Verschiebung
MOVE der Untersuchungsdaten zu dem bekannten Schlüssel PatId
festgelegt. Die Auswirkungen der Korrektur auf den Datenbestand
sind in 7 dargestellt.
-
Die
zugehörige
HL7 Transaktion zur Mitteilung der korrigierten Daten ist bei der
Verschiebung MOVE beispielsweise wie folgt ausgebildet:
MSH|^&~\|RIS||RIS|20041015142431||ZPA^I01|247|P|2.3.1
PID|1|PAT000084||Lastname^Firstname||19121212|M
ZPA||ACCNO12345
-
Damit
wird mitgeteilt, dass die mit dem Schlüssel AccNo 'ACCNO12345' gekennzeichneten Untersuchungen dem
mit dem Schlüssel
PatId 'PAT000084' gekennzeichneten
Patienten zugeordnet werden sollen. Die weiteren Angaben zum Patienten
dienen unter anderem zu dessen eindeutiger Identifikation.
-
4) Correct AccNo – wrong
Patient/unknown Study
-
Im
lokalen Datenbestand wird lediglich der Schlüssel AccNo gefunden. Die Schlüssel PatId
und SIUid werden nicht gefunden. Diese Informationen werden angezeigt.
Im Anschluss werden ein korrigierter Schlüssel PatId und ein korrigierter
Schlüssel
SIUid erfasst. Der korrigierte Schlüssel PatId ist bekannt, der
korrigierte Schlüssel
SIUid unbekannt.
-
Zur
Synchronisation wird z.B. eine zweistufige Korrekturprozedur festgelegt,
die zunächst
ein Ersetzen CHANGE des bisherigen Schlüssels SIUid durch den korrigierten
Schlüssel
SIUid und dann eine Verschiebung MOVE der mit dem Schlüssel AccNo
gekennzeichneten Untersuchungsdaten zu dem bekannten Schlüssel PatId
umfasst. Die Auswirkungen der Korrektur auf den Datenbestand sind
in 8 dargestellt.
-
Die
zugehörigen
HL7 Transaktionen zur Mitteilung der korrigierten Daten sind beispielsweise
wie folgt ausgebildet:
MSH|^&~\|RIS||RIS|RIS|20041015142431||ZPA^S04|247|P|2.3.1
ZPA|1.2.5.354699234.5^1.2.5.354699234.6|
MSH|^&~\|RIS||RIS|RIS|20041015142431||ZPA^I01|247|P|2.3.1
PID|1|PAT000084||Lastname^Firstname||19121212|M
ZPA||ACCNO12345
-
Mit
der ersten Transaktion eine Korrektur des bisherigen Schlüssel SIUid '1.2.5.354699234.5' auf den neuen Schlüssel SIUid '1.2.5.354699234.6' mitgeteilt. Die
optionalen Angaben zum Patienten sind nicht angegeben, da die Prüfung auf
einen korrekten Patienten zu diesem Zeitpunkt infolge der in diesem
Punkt noch bestehenden Dateninkonsistenz nicht möglich ist.
-
Mit
der zweiten Transaktion wird mitgeteilt, dass die mit dem Schlüssel AccNo 'ACCNO12345' gekennzeichneten
Untersuchungen dem mit dem Schlüssel
PatId 'PAT000084' gekennzeichneten
Patienten zugeordnet werden sollen. Die weiteren Angaben zum Patienten
dienen unter anderem zu dessen eindeutiger Identifikation.
-
5) Correct Study – wrong
Patient/AccNo
-
Im
lokalen Datenbestand wird lediglich der Schlüssel SIUid gefunden. Die Schlüssel PatId
und SIUid werden nicht gefunden. Diese Informationen werden angezeigt.
Im Anschluss wird ein korrigierter Schlüssel AccNo erfasst. Der korrigierte
Schlüssel
AccNo ist bekannt. Darüber
hinaus ist der korri gierte Schlüssel
AccNo bereits dem in dem Datentupel angegebenen Schlüssel PatId
zugeordnet.
-
Zur
Synchronisation ist eine einstufige Korrekturprozedur ausreichend,
die eine Verschiebung MOVE der mit dem Schlüssel SIUid gekennzeichneten
Untersuchungsprozeduren zu der mit dem korrigierten Schlüssel AccNo
gekennzeichneten Untersuchung umfasst. Die Auswirkungen der Korrektur
auf den Datenbestand sind in 9 dargestellt.
-
Die
zugehörige
HL7 Transaktionen zur Mitteilung der korrigierten Daten ist beispielsweise
wie folgt ausgebildet:
MSH|^&~\|RIS||RIS|RIS|20041015142431||ZPA^S01|247|P|2.3.1
PID|1|PAT000084||Lastname^Firstname||19121212|M
ZPA|1.2.5.354699234.5|ACCNO12345
-
Mit
der Transaktion wird mitgeteilt, dass die mit dem Schlüssel SIUid '1.2.5.354699234.5' gekennzeichneten
Untersuchungsprozeduren der mit dem Schlüssel AccNo 'ACCNO12345' gekennzeichneten Untersuchung zugeordnet
werden sollen. Die weiteren Angaben zum Patienten sind optional
und dienen zur Überprüfung, ob
der korrigierten Untersuchung der richtige Patient zugeordnet ist.
-
6) Wrong Patient/AccNo/Study
-
Im
lokalen Datenbestand wird keiner der Schlüssel SIUid, AccNo, PatId gefunden.
Diese Informationen werden angezeigt. Es wird zunächst ein
korrigierter Schlüssel
SIUid erfasst. Im Anschluss wird wie bei dem vorherigen Szenario
verfahren.
-
Zur
Synchronisation wird z.B. eine zweistufige Korrekturprozedur festgelegt,
die zunächst
ein Ersetzen CHANGE des bisherigen Schlüssels SIUid durch den korrigierten
Schlüssel
SIUid und dann eine Verschiebung MOVE der mit dem korrigierten Schlüssel SIUid
gekennzeichneten Untersuchungsprozeduren zu der mit dem korrigierten
Schlüssel
AccNo gekennzeichneten Untersuchung umfasst. Die Auswirkungen der
Korrektur auf den Datenbestand sind in 10 dargestellt.
-
Die
zugehörige
HL7 Transaktionen zur Mitteilung der korrigierten Daten ist beispielsweise
wie folgt ausgebildet:
MSH|^&~\|RIS||RIS|RIS|20041015142431||ZPA^S04|247|P|2.3.1
ZPA|1.2.5.354699234.5^1.2.5.354699234.6|
MSH|^&~\|RIS||RIS|RIS|20041015142431||ZPA^S01|247|P|2.3.1
PID|1|PAT000084||Lastname^Firstname||19121212|M
ZPA|1.2.5.354699234.6|ACCNO12345
-
Mit
der ersten Transaktion eine Korrektur des bisherigen Schlüssel SIUid '1.2.5.354699234.5' auf den neuen Schlüssel SIUid '1.2.5.354699234.6' mitgeteilt. Die
optionalen Angaben zum Patienten sind nicht angegeben, da die Prüfung auf
einen korrekten Patienten zu diesem Zeitpunkt infolge der in diesem
Punkt noch bestehenden Dateninkonsistenz nicht möglich ist.
-
Mit
der zweiten Transaktion wird mitgeteilt, dass die mit dem korrigierten
Schlüssel
SIUid '1.2.5.354699234.6' gekennzeichneten
Untersuchungsprozeduren der mit dem Schlüssel AccNo 'ACCNO12345' gekennzeichneten Untersuchung zugeordnet
werden sollen. Die optionalen Angaben zum Patienten sind nun hinzugefügt, da eine Überprüfung, ob
der korrigierten Untersuchung der richtige Patient zugeordnet ist,
nun möglich
ist.
-
Mit
der Erfindung ist eine Vielzahl von weiteren Vorteilen verbunden.
-
Eine
Exception Resolution für
nicht zugeordnete Bilder erhöht
die Systemstabilität
und mithin die Zufriedenheit von Kunden und Bedienpersonal, da weniger
Bilder infolge von Fehlzuordnungen verloren gehen und weniger Untersuchungen
wiederholt werden müssen.
-
Eine
Durchführung
der Synchronisation mit Hilfe von normkonform erweiterten HL7 Transaktionen
hat den Vorteil, dass mit diesen Nachrichten die bestehenden Normen
besonders leicht erweitert werden können. Auch ist eine normkonforme
Erweiterung der bestehenden Produkte besonders aufwandsarm, wenn
bereits existierende Realisierungen wegen der Konformität wieder
verwendet werden können.
Insellösungen,
die nicht herstellerübergreifend
funktionieren, können
somit sehr effizient vermieden werden.
-
Eine
Umsetzung der Erfindung erfordert keine prinzipiellen Änderungen
des bisherigen Standes der Technik, sondern lässt sich grundsätzlich nachträglich als
Baustein – insbesondere
als modifiziertes oder zusätzliches
Computerprogrammprodukt – einfügen.
-
Der
Zeitpunkt der Realisierung ist unabhängig von dem Zeitpunkt der
Realisierung anderer Funktionen.
-
Mit
der Erfindung wird sichergestellt, dass die einzelnen Komponenten
des Gesamtsystems nur in geringem Maße belastet werden und damit
die Stabilität
des Gesamtsystems erhöht
wird.
-
Abschließend sei
darauf hingewiesen, dass die Beschreibung der Erfindung und die
Ausführungsbeispiele
grundsätzlich
nicht einschränkend
in Hinblick auf eine bestimmte physikalische Realisierung der Erfindung
zu verstehen ist. Für
einen einschlägigen
Fachmann ist insbesondere offensichtlich, dass die Erfindung teilweise
oder vollständig
in Software und auf mehrere physikalische Produkte – dabei
insbesondere auch Computerprogrammprodukte – verteilt realisiert werden
kann.
