-
In
vielen Gebieten müssen
Benutzer auf Daten, die sich anderenorts auf ihren eigenen Computern oder
Workstations befinden, zugreifen und diese modifizieren. In bestimmten
Situationen kann das Volumen an Daten, das von einem Benutzer benötigt wird,
groß sein,
und deshalb kann es zeitaufwendig sein, die benötigten Informationen auf Bedarf
herunterzuladen. Ein Beispiel für
eine solche Situation liegt auf dem medizinischen Gebiet vor, wenn
Informationen über
Patienten in einer zentralen Datenbank gespeichert sind. Ein Patient
wird in der Regel verschiedenen Tests und Untersuchungsprozeduren
wie etwa Röntgen,
MRI usw. unterzogen, und die Ergebnisse dieser verschiedenen Prozeduren
werden in einer gemeinsamen oder verteilten Datenbank gespeichert.
Medizinisches Personal greift dann auf diese Informationen ("Patientenstudien") für diagnostische
und Auswertungszwecke zu.
-
Es
wurden Strategien konzipiert, durch die Benutzer, die solche Informationen
benötigen,
die Patientenstudien vor der Verwendung vorabrufen können, so
dass die Informationen ihnen sofort verfügbar sind, wenn sie benötigt werden.
Der Begriff „Vorabrufen" wir hier und im
Folgenden im Sinne des Fachterminus „Pre-fetching" verwendet.
-
Existierende
Vorabrufstrategien folgen zur Zeit festen Regeln. Zum Beispiel besteht
eine typische Regel darin, alle ungelesenen Studien von dem aktuellen
Tag über
die Nacht vorabzurufen, so dass am Morgen des nächsten Tages alle Studien in
der Workstation des Benutzers vorliegen. Die Benutzer müssen die
Studien von dem vorherigen Tag nicht laden, weil sie bereits in
ihre Workstation vorgeladen wurden, was zu einem Ladezeitvorteil
führt.
-
Dies
wurde auf mehrere Weisen implementiert. wie zum Beispiel von Rogan
in Rogan's "Everything On-line" gelehrt, wird das Vorabrufen
digitaler medizinischer Bilder durch Technologie überflüssig, http://www.hoise.com/vmw/00/articles/vmw/LV-VM-04-00-27.html (hiermit
durch Verweis in die Beschreibung aufgenommen), ein medizinischer
Spezialist präsentiert
eine Liste von Bildern, die er einen Tag später konsultieren möchte, im
voraus, um diese rechtzeitig in das System zu laden. Über Nacht
werden die erforderlichen Bilder dann im Batch-Modus aus einem Bildarchivierungs-
und Kommunikationssystem (PACS) abgerufen, um sie lokal in Standby
zu versetzen. Das Vorgehen auf diese Weise war notwendig, weil die
verfügbare
Bandbreite häufig
kein direktes Herunterladen sehr großer Bilder erlaubt. In den
meisten Fällen
besitzen lokale Workstations unzureichende Plattenkapazität, um eine
große
Anzahl großer
Bilddateien zu laden.
-
Die
von Rogan vorgeschlagene Strategie ist jedoch eine statische Vorabrufstrategie,
die keine dynamischen Änderungen
und das individuelle Benutzerverhalten sowie verschiedene individuelle
Krankenhausumgebungen berücksichtigt.
Dieser Brute-Force-Ansatz
erlaubt außerdem
keine feinen Einstellungen und/oder einen Transfer nur der relevanten
Bilder im Gegensatz zu dem Transfer der gesamten Studie.
-
Ein
anderer Ansatz wird von BRIT Systems' Roentgen Files bereitgestellt (siehe
BRIT Systems' Roentgen
Files, http://www.brit.com/html/roentgen_files_.html, hiermit durch
Verweis in die Beschreibung aufgenommen). Bei diesem System basiert
der Vorabruf auf der Körperregion,
dem Modalitätstyp
und dem Untersuchungsdatum. Diese heruntergeladenen Untersuchungen
können
gemäß tabellengesteuerter
Regeln zu dem Betrachter vorgeladen werden. Wie bei Rogan ist das
Vorabrufen tabellengesteuert, oder anders ausgedrückt, statisch
und nicht selbstanpassend und dynamisch.
-
Es
wird ein adaptives System benötigt,
das die Vorabrufstrategie z.B. auf der Basis einer individuellen Krankenhausumgebung
und des Benutzerverhaltens dynamisch aktualisiert. Ein solches adaptives/dynamisches
System könnte
zu einem höheren Optimierungspotential
als die einfache Verwendung statischer Regeln führen.
-
Die
vorliegende Erfindung betrifft eine Selbstoptimierungs-Cache-Strategie für Bilddaten,
bei der jeder Arbeitsplatz nicht direkt mit der Bilddatenverwaltung
verbunden ist, sondern stattdessen über einen Proxi-Dienst. Alle
existierenden Proxi-Dienste speichern ihre Meta-Daten (z.B. wer
auf welche Daten, wo und wann zugreift) in einer zentralisierten
Datenbank (dem "Metadaten-Repositorium"). Durch Verwenden
dieser Informationen kann man nach Regularitäten des Datenzugriffs suchen
(„mine", z.B. im Sinne des
Fachterminus „Data
Mining") und unter
Verwendung dieser eine Vorabrufstrategie konzipieren.
-
Gemäß verschiedenen
Ausführungsformen
der Erfindung wird ein Vorabruf-Cache-Dienst bereitgestellt, der
sich automatisch an das verhalten der Benutzer und die Umgebung
anpasst, und es wird ein selbstlernender Vorabrufmechanismus bereitgestellt,
der die Bildladezeit nach einem regelmäßigen Zugriff auf eine Menge ähnlicher
Bilder vorteilhafterweise reduziert.
-
Alle
Dienste, Workstations und Benutzer, die auf Bilddaten aus der Bilddatenverwaltung
und/oder anderen Workstations zugreifen bzw. diese laden, können aus
dieser erfindungsgemäßen Lösung Nutzen
ziehen, die kürzere
wahrgenommene Zugriffs-/Ladezeiten
für Bilder,
höhere
wahrgenommene Ladeleistungsfähigkeit
von Bildbetrachtungs-Workstations und selbstoptimierende Arbeitsablaufunterstützung erzeugt,
d.h. automatisierte Anpassung der Vorabrufstrategie an die Bedürfnisse
des Kunden/Benutzers und das Zugriffsverhalten des Kunden/Benutzers.
Ferner kann die Erfindung dabei helfen, Spitzen des Netzwerkverkehrs
zu vermeiden und ein effizientes Bildladen für das Lesen mit hohem Volumen
bereitstellen, was zu einem besser benutzbaren System führt.
-
Im
Folgenden wird eine Ausführungsform
der Erfindung mit Bezug auf die nachfolgend besprochenen Figuren
beschrieben.
-
1 ist
ein Blockschaltbild der Hauptkompomenten des Systems;
-
2 ist
ein Blockschaltbild eines vergrößerten Teils
des Metadatenrepositoriums; und
-
3 ist
ein Flussdiagramm der Umsetzung in Regeln und Strategien und des
Einsatzes der Vorabbruchstrategien.
-
1 zeigt
eine Ausführungsform
der Erfindung, wobei das Vorabrufen von Datensätzen verwendet wird. Die nachfolgend
beschriebene Ausführungsform
betrifft die Umgebung einer medizinischen Institution, bei der die
Datensätze
Bilddaten umfassen, obwohl die Erfindung auch auf eine beliebige
Art von Datenbanksystem verallgemeinert werden kann.
-
In
einer Anfangsphase arbeitet das System 10 gemäß einem
traditionellen Entwurf. Datensätze
in Bezug auf einen Patienten werden durch eine Entität gesammelt,
die als Datensatzquelle 12 dient. Bei einer solchen Datensatzquelle 12 könnte es
sich um Bildgebungseinrichtungen handeln, wie zum Beispiel eine
Röntgenmaschine,
MRI, CAT-Scan oder um andere bekannte Bildgebungseinrichtungen.
Zusätzlich
könnte
es sich bei der Datensatzquelle 12 um eine beliebige andere
Art von computergestütztem
System, wie zum Beispiel ein Dateneingabe-Terminal oder dergleichen,
handeln. In 1 ist die Datensatzquelle 12 in
Bilddatensätzen in
Bezug auf eine Modalität
der Bilder widergespiegelt. Gemäß dieser
Ausführungsform
werden patientenbezogene Datensätze 200 in
einem zentralen Datenlager 14 gespeichert, nachdem sie
eine Datensatz-Datenverwaltungsfunktion 102 durchlaufen.
Diese Datensätze 200 können Datensätze beliebiger
Art enthalten, gemäß einer
Ausführungsform
der Erfindung betreffen sie jedoch Bilddaten verschiedener Modalitäten, wie
zum Beispiel CT, MR usw.
-
Das
zentrale Datenlager 14 könnte als physisch zentralisierte
Datenbank implementiert werden, oder könnte als eine verteil te Datenbank
konstruiert werden; in jedem Fall dient das zentrale Datenlager 14 als
ein Ort, an dem Patentdatensätze
aggregiert werden. Die Datensätze
können
Informationen enthalten, wie etwa eine Patienten-ID, eine Kennung
für die
Art der in dem Datensatz repräsentierten
Daten, das mit dem Datensatz assoziierte medizinische Personal,
eine Stations- oder Ortskennung usw. Dieses zentrale Datenlager 14 könnte als
Teil des zuvor erwähnten
PACS-Systems in einer klinischen Umgebung implementiert werden.
-
Das
zentrale Datenlager 14 kann weiterhin in ein Kurzzeit-Datenlager STS 14a und
ein Langzeit-Datenlager LTS 14b unterteilt werden. Das
STS 14a könnte
durch einen Direktzugriffsspeicher (RAM), einen Cache, eine Festplatte
(die ein RAID-Speichersystem
enthalten könnte),
ein lokales Dateisystem, eine lokale Datenbank, implementiert werden,
die leicht und sofort verfügbar
ist, um einem Anforderer Daten zuzuführen. Das LTS 14b könnte in
einer beliebigen Form von Datenarchivierungssystem implementiert
werden und könnte eine
CD/DVD-Jukebox,
ein Bandarchiv oder eine beliebige Form von Archivspeicherung enthalten.
Das LTS 14b verwendet eine Speicherung, die relativ billig
ist, um große
Volumen von Daten zu speichern, und kann die Daten für lange
Zeiträume
ohne Verschlechterung halten – das
LTS 14b kann jedoch Benutzerintervention erfordern, wie
zum Beispiel das Laden von Bändern
oder Datenträgern,
oder kann bei Anforderung beträchtlich langsamer
bei der Bereitstellung von Daten sein, möglicherweise wegen der Verwendung
von Karussells oder dergleichen beim Abrufen der physischen Medien,
auf denen die Daten gespeichert sind, oder möglicherweise wegen der naturgemäßen Langsamheit
des Datentransfers des Medien-Lesemechanismus. Wenn das LTS 14b zur
Speicherung verwendet wird, kann man die Daten mit dem Vorabruf-/Vorlademechanismus
in das STS 14b laden.
-
Ein
Benutzer 40, der auf den Datensatz 200 eines Patienten
zugreifen möchte,
wird in einen Workstation-Client 30a-30d eingeloggt,
der auf eine Anwendung zugreift, die es dem Be nutzer 40 gestattet,
Bilddaten oder andere Datensätze 200,
die über
eine Anfrage oder Anforderung 202 erhalten werden, zu betrachten
oder zu modifizieren. Die Workstation-Clients 30a-30d können gemäß der Funktionalität klassifiziert
werden, die sie durchführen
können.
Die Workstation-Clients können
Fat-Clients 30a-30b, Thin- oder Thin-Rich-Clients 30c oder
Ultra-Thin-Clients 30d sein.
-
Abhängig von
ihrer Fähigkeit
kann ein Zentralverarbeitungsserver 32 in Verbindung mit
den Workstation-Clients 30c, 30d verwendet werden.
Ein Verarbeitungsserver 32 ist ein Server, der den Anzeigeinhalt
aus den Bilddaten aus der Bilddatenverwaltung 102 berechnet
und nur die Anzeigedaten zu einem oder mehreren Thin-Clients 30c, 30d sendet.
Im Fall von 3D-Bilddaten
berechnet der Verarbeitungsserver 32 das 3D-Volumen und
würde nur
die gewünschten
2D-Bilder zu dem Thin-Client 30c, 30d, nicht aber
das gesamte 3D-Volumen senden. Falls ein Zentralverarbeitungsserver 32 verwendet
wird, dient der Vorabruf-/Vorlagemechanismus zum Laden von Daten 200 in
den Verarbeitungsserver 32, und nicht in den physischen
lokalen Arbeitsplatz 30c, 30d des Benutzers 40.
Der Verarbeitungsserver 32 unterstützt diese Clients 30c, 30d,
indem er schwere Verarbeitungs-Jobs durchführt, wie zum Beispiel die Umsetzung
von 3D-Daten in 2D-Anzeigerepräsentationen wie
oben erwähnt.
-
Der
Zentralverarbeitungsserver
32 wird jedoch nicht benötigt, wenn
der Workstation-Client
30a,
30b seine eigene schwere
Verarbeitung durchführen
kann. Die folgende Liste identifiziert bestimmte Möglichkeiten des
Workstation-Client
30:
| • Fat-Client 30a, 30b: | verarbeitet
alle Jobs, einschließlich
der graphischen Benutzeroberfläche
(GUI) und erweiterter Graphikverarbeitung ohne Hilfe des Verarbeitungsservers 32 |
| • Thin-Rich-Client 30c: | die
GUI und bestimmte grundlegende Graphikverarbeitung läuft |
| | auf
dem Client 30c ab, wobei fortgeschrittenere Graphikverarbeitung
auf dem Verarbeitungsserver 32 abläuft. |
| • Thin-Client 30c: | die
GUI läuft
auf dem Client 30c ab, aber die Graphikverarbeitung läuft auf
dem Verarbeitungsserver 32 ab |
| • Ultra-Thin-Client 30d: | der
Großteil
der Verarbeitung (sogar die GUI) läuft auf dem Verarbeitungsserver 32 ab |
-
Wenn
der Benutzer 40 Datensätze 202 von
einer einzelnen der Workstations 30a-30d anfordert,
erfolgt diese Anforderung 202, indem der Benutzer 40 einen
Datensatz aus einer Arbeitsliste auswählt, die auf einem Monitor
der Workstation 30a-30d präsentiert wird. In bestimmten
Situationen, wie zum Beispiel in der Situation des Ultra-Thin-Client 30d,
kann die Anforderung 202 parallel zu dem Proxy-Server 20d und
zu dem Datensatz-Datenverwaltungsmodul 102 gesendet werden.
Als Alternative kann die Anforderung 202 in Reihe zuerst
zu dem Proxy-Server 20a-20c und
dann zu dem Datensatz-Datenverwaltungsmodul 102 gesendet
werden.
-
Der
Proxy-Server 20a-20d extrahiert die Metadaten 204 der
Anfrage (z.B. die ID des anfordernden Benutzers, der Ort, aus dem
die Anforderung 202 stammt, die Workstation 30a-30d,
aus der die Anforderung 202 stammt, die Zeit der Anforderung 202,
etwaige Anfrageeinschränkungen,
Patientennamen und möglicherweise
etwaige andere Informationen in Bezug auf die Anforderung 202 usw.)
aus der Anforderung 202 und speichert diese Informationen
(die Metadaten 204 der Anfrage) in dem lokalen Cache 22a-22d (es
sei angemerkt, dass ein Cache 22d und ein Proxy-Server 20d auch
mit dem Verarbeitungsserver 32 assoziiert sein können). Die
angeforderten Datensätze 200 (z.B.
Bilder) werden entweder durch den Proxy-Dienst 20a-20d oder
durch das Datensatz-Datenverwaltungsmodul 102 von dem zentra len
Datenlager 14 abgerufen, abhängig davon, ob die angeforderten
Datensätze 200 entweder
lokal in dem Proxy-Dienst 20a-20d Cache-gespeichert sind (22a-22d)
oder nicht. Der lokale Cache, d.h. das lokale Datensatz-/Datenlager 22a-22d,
kann ein Direktzugriffsspeicher (RAM), ein Cache, eine Festplatte,
ein lokales Dateisystem, eine lokale Datenbank usw. entweder auf
einem Client oder einem anderen Server (d.h. dem Verarbeitungsserver 32)
sein.
-
Der
angeforderte Datensatz 200 wird in einen lokalen Speicherbereich-Cache 22a-22d der
Workstation 30a-30d kopiert, indem der Benutzer 40 zur
Auswertung und möglicherweise
zur Durchführung
von Modifikationen darauf zugreifen kann.
-
Im
Gegensatz zu den bekannten Zugriffssystemen werden jedoch Metadaten 204 aus
den Datensatz-Anforderungen 202 zusätzlich durch die Proxy-Server 20a-20d auf
der Basis der Anforderung von Datensätzen 202 an ein Metadaten-Repositorium 50 (2)
bereitgestellt, das die Metadaten in dem Speicherbereich/-Cache 52 für unverarbeitete
Metadaten speichert, der die Ähnlichkeiten
von Anfrageergebnissen enthalten kann (z.B. ist das Attribut Station
gleich, das Datum ist heute usw.). Das Metadaten-Repositorium 50 sammelt
Metadaten 204 aus allen Proxy-Servern 20a-20d in
dem System und aggregiert alle Metadaten 204 in dem Speicherbereich 52 für unverarbeitete
Metadaten. Die Metadaten können
durch die Proxy-Server 20a-20d in den Metadaten-Speicherbereich 52 geschoben
werden oder können
aus den Proxy-Servern 20a-20d in den Metadaten-Speicherbereich 52 gezogen
werden, und dies kann als ein asynchroner (z.B. unterbrochener)
oder synchroner (z.B. abgefragter) Mechanismus implementiert werden.
-
Es
ist außerdem
möglich,
dass das Metadaten-Repositorium 50 einen Cache (möglicherweise
RAM, ein Dateisystem oder einen anderen bekannten Cache-Mechanismus)
zum Speichern der angeforderten Datensätze 200 enthält, um das
zentrale Datenlager von der Bereitstellung mehrerer Kopien desselben
Datensatzes 200 zu entlasten. Dieser Cache kann als Alternative
mit dem Datensatz-Datenverwaltungsmodul 102 assoziiert
sein.
-
Wie
in 2 dargestellt, enthält das Metadaten-Repositorium 50 eine
Umsetzungsroutine 150 (oder sie ist mit ihm assoziiert),
die die aggregierten unverarbeiteten Metadaten aus dem Datenlager 52 nimmt
und diese in Regeln und Strategien umsetzt, die in einer Datenbank 54 für Regeln
und Strategien gespeichert werden. Die Umsetzungsroutine 150 schürft die
Metadaten 204 und bestimmt Regularitäten auf der Basis von in den
Metadaten enthaltenen Informationen.
-
3 zeigt
den Prozess 300 zum Umsetzen der aggregierten unverarbeiteten
Metadaten in Regeln und Vorabrufstrategien. Folglich wird in einem
ersten Schritt 302 für
jedes Anforderungsobjekt in dem Repositorium eine Clusterung ähnlicher
Anforderungen durchgeführt.
Theoretisch kann man sowohl auf Dichte basierende, hierarchische
als auch partionierende (flache) Clusterungsalgorithmen verwenden,
um nach Regularitäten
in den unverarbeiteten Metadaten zu schürfen, um Gruppen von Anforderungen
zu finden, die starke Ähnlichkeiten
aufweisen oder ähnliche
Dokumente oder Datensätze
betreffen. Deshalb wird jede Anforderung als ein Objekt in der Datenbank 52 für unverarbeitete
Metadaten repräsentiert.
Bei einer bevorzugten Ausführungsform
besitzt jedes Anforderungsobjekt einen Vektor von k Eigenschaften,
wodurch die Charakteristika der Anforderung beschrieben werden,
wie etwa der anfordernde Benutzer 40, seine Rolle, die
Workstation 30a-30d, an der die Anforderung gestellt
wurde, die Abfrageanweisung selbst, Zeit und Wochentag usw. Auf der
Basis dieses Vektors können
die Anforderungsobjekte miteinander in Beziehung gesetzt werden,
und es kann eine "Distanz" zwischen zwei Anforderungsobjekten
zur Quantifizierung der Ähnlichkeit
unter Verwendung bekannter vektorbasierender Mathematik berechnet
werden.
-
Das
Finden von Ähnlichkeiten
und Regularitäten
in einer Menge aufgezeichneter Anforderungen erfolgt dann durch
Gruppierung ähnlicher,
nahe liegender Objekte zu Clustern. Sowohl die auf Dichte basierenden
Aufteilungsalgorithmen als auch die hybriden Clusterungsansätze (die
z.B. eine Kombination der oben erwähnten Ansätze verwenden) haben sich daher
als höchst
viel versprechend und geeignet erwiesen.
-
Auf
Dichte basierende Algorithmen verwenden wachsende Cluster, die erweitert
werden, solange die Dichte von Objekten in ihrer Umgebung eine vordefinierte
Schwelle übersteigt.
Ein beispielhafter Algorithmus für
den auf Dichte basierenden Ansatz ist der wohlbekannte DBSCAN-Algorithmus
(Ester M., Kriegel H.-P., Sander J., Xu X.: "A Density-Based Algorithm for Discovering
Clusters in Large Spatial Databases with Noise", Proc. 2nd int. Conf. on Knowledge
Discovery and Data Mining, Portland, Oregon, 1996, AAAI Press, 1996,
worauf hiermit ausdrücklich
Bezug genommen wird).
-
Die
hierarchischen Clusterungsalgorithmen aggregieren schrittweise Objekte
zu Gruppen (agglomerativer Ansatz) oder splitten/unterteilen größere Gruppen
in Untergruppen (divisiver Ansatz). Aufteilende Clusterungsverfahren
weisen die Objekte einer vordefinierten Anzahl von Clustern zu.
Der CHAMELEON-Algorithmus kann als ein geeignetes Beispiel für einen
hybriden Clusterungsansatz unter Verwendung einer Kombination von
Partitionierung und hierarchischem Vorgehen erwähnt werden (G.Karypis, E-H
Han und V. Kumar, "CHAMELEON:
A hierarchical clustering algorithm using dynamic modeling". IEEE Computer,
32(8):68-75, 1999, worauf hiermit ausdrücklich Bezug genommen wird).
-
Ein
zweiter Schritt 304 wird durchgeführt, um die Clustereigenschaften
zu extrahieren. Für
jedes zuvor identifizierte Cluster werden die charakteristischen
Clustereigenschaften extrahiert. Auf der Basis der Menge resultierender
Cluster, die z.B. durch den periodisch ausgeführten Clusterungsalgorithmus
abgerufen wurden, werden die Clustereigenschaften extrahiert. Deshalb
wird jedes Cluster verwandter Anforderungen darauf untersucht, welche
Eigenschaften der Anforderungen die Clusterung verursacht haben
und deshalb eine Auswirkung auf die Ähnlichkeiten dieser Anforderung
hatten. Als Beispiel könnte
eine Menge von Clustereigenschaften für ein spezifisches Cluster
darin bestehen, dass alle Anforderungen hauptsächlich Röntgenbilder betreffen, wovon
das Beschaffungsdatum gleich dem Datum der Anfrage/Anforderung ist
und die von einem Benutzer mit dem Namen "John Smith" und hauptsächlich von einer Workstation
mit dem Label "WS1264" angefordert/aufgegeben
wurden.
-
Der
dritte Schritt 306 ist das Ableiten/Erzeugen der Vorabrufstrategien
aus den Clustereigenschaften. Bei Verwendung des vorherigen Beispiels
würde dies
zu der folgenden Strategie führen: "Immer Bilder aus
der Röngtenstation
Vorabrufen/Spiegeln, die John Smith als einen Benutzer identifizieren,
und diese zu der Workstation WS1264 senden".
-
Der
vierte und letzte Schritt 308 ist das Implementieren der
abgeleiteten/erzeugten Strategie durch Senden der entsprechenden
Steuernachrichten zu (102, 14, 14a, 14b)
oder das Triggern der entsprechenden Subsysteme (102, 14, 14a, 14b).
Alle so entwickelten Regeln und Strategien werden in der Datenbank 54 für Regeln
und Strategien gespeichert.
-
Die
wie oben beschrieben entwickelten Regeln und Strategien müssen dann
implementiert werden. Ein Modul 104 zum Implementieren
von Vorabrufstrategien entnimmt die Strategien der Datenbank 54 für Regeln
und Strategien und beginnt mit dem Stellen von Steueranforderungen 206 aus
dem Datensatz-Datenverwaltungsmodul 102 auf
der Basis dieser Strategien 54. Diese Anforderungen 206 leiten
das Herunterladen der Datensätze 200 genauso
ein, als ob der Benutzer 40 tatsächlich die Anforderungen 202 von
der Workstation 30a-30d selbst ausgestellt hätte. Das
Modul 104 zum Implementieren von Vorabrufstrategien kann
verschiedene Einschränkungen
enthalten, die nicht Teil der Metadaten selbst sind, sondern stattdessen
zusätzliche Systemfaktoren
darstellen, die zu berücksichtigen
sind.
-
Zum
Beispiel kann es feststellen, dass reichlich Bandbreite für das Herunterladen
zwischen den Stunden von 0 Uhr und 5 Uhr morgens verfügbar ist
und deshalb das Herunterladen zwischen diesen Stunden konzentriert.
Als Alternative kann es erkennen, dass das zentrale Datenlager 14 zu
einer bestimmten Zeit eine abnorme Last erfährt, obwohl diese Zeit während eines
Zeitraums hoher verfügbarer
Bandbreite auftritt. Es kann deshalb entscheiden, die Anforderungen
von Datensätzen
zurückzustellen.
Zusätzliche
Systemfaktoren wären zum
Beispiel, dass ein bestimmter Benutzer 40 zwei Wochen lang
im Urlaub ist oder dass ein Benutzer für einen gegebenen Zeitraum
einen anderen ersetzen soll.
-
Bei
diesem System ist es somit zum Beispiel möglich, Regularitäten wie
die folgende zu erkennen: "Benutzer <A> greift immer während <11 Uhr morgens> bis <1 Uhr nachmittags> an dem Arbeitsplatz <X>, <Y> oder <Z> von einer <bestimmten Modalität> aus auf die Bilddaten
zu". Durch Verwenden
dieses Wissens können
die Aufzeichnungsdaten leicht in dem entsprechenden Proxy-Dienst
vorabgerufen werden. Diese Technik führt zu kürzeren Zugriffs-/Ladezeiten
für die
Bilddatensätze.
-
Es
ist wichtig, dass Datenstimmigkeit in allen Cache-Speichern und Datenbanken
sichergestellt werden muss. Dies kann durch Verwendung eines der
vielen verfügbaren
bekannten Replikations- und Synchronisationsalgorithmen und -strategien
für verteilte
Datensätze
erfolgen (siehe z.B. Baruch Awerbuch, Ciprian Tutu, "Maintaining Database
Consistency in Peer to Peer Networks" (2002), http://citeseer.ist.psu.edu/503365.html,
27.6.2005, worauf hiermit ausdrücklich
Bezug genommen wird).
-
Das
oben besprochene System kann mit Bezug auf die folgende hypothetische
Fallstudie erläutert werden.
-
Dr.
Smith liest seine CT- und MR-Untersuchungen immer von 11 Uhr morgens
bis 3 Uhr nachmittags an einer der drei Leseworkstations der Radiologieabteilung
A. Dieser Trend wird erkannt und das System ruft automatisch im
Voraus ungelesene Studien für
Dr. Smith an diesen drei Leseworkstations ab.
-
Wenn
sich Dr. Smith 11 Uhr morgens an seiner Workstation einloggt, sind
die Bilder bereits auf diesen drei Workstations geladen und er kann
sofort mit dem Lesen seiner Bilder beginnen. Am Nachmittag (nach
3 Uhr nachmittags) liest Dr. Smith jedoch in einer anderen Radiologieabteilung,
der Radiologieabteilung B. Das System weiß dies durch Analysieren des
Leseverhaltens von Dr. Smith (auf der Basis der Metadaten in Bezug auf
vergangene Anforderungen von Dr. Smith) und ruft die Nachmittag-Studien
im voraus zu der Radiologieabteilung B ab.
-
Im
Gegensatz zu Dr. Smith liest Dr. Gonzales nur an seiner Leseworkstation,
die sich in seinem Büro befindet.
Alle seine Studien werden deshalb immer nur zu einer Workstation
vorabgerufen.
-
Dieses
System kann unzählige
verschiedene Möglichkeiten
des Vorabrufens verwenden. Man ist nicht auf nur eine Vorabrufregel
beschränkt,
und die Regel muss auch nicht statisch sein – sie kann sich auf der Basis
der überwachten
Metadaten in Bezug auf Anforderungen von Datensätzen mit der Zeit ändern.
-
Die
folgende Tabelle zeigt beispielhafte Regeln 54, die durch
Erkennen der folgenden Trends aus den Metadaten 52 extrahiert
werden:
- a) gewöhnlich liest Dr. Meier CT-Brustkastenbilder
entweder an der Workstation A oder B zwischen 2 Uhr nachmittags
und 5 Uhr nachmittags;
- b) gewöhnlich
liest Dr. Müller
MR-Bilder an der Workstation C nicht zu einem festen Zeitpunkt während des Tages.
-
-
Tabelle Beispielhafte
Strategien
-
Um
die Bilddatenverwaltung nicht mit Vorabrufen zu überlasten, kann ein begrenztes
Vorabrufen implementiert werden, indem man den folgenden beispielhaften
Schwellenmechanismus anwendet. Es kann zum Beispiel eine Schwellengrenze
von N = 3 angewandt werden, um immer nur die drei letzten ungelesenen
Studien zu senden. In diesem Beispiel werden nur die drei letzten
ungelesenen CT-Brustkastenstudien zu Workstation A und B und nur
die letzten drei ungelesenen MR-Studien zu Workstation C gesendet.
-
Dr.
Meier wählt
die nächste
ungelesene CT-Brustkastenstudie "Frau
Schmidt" aus der
Arbeitsliste an der Workstation A. Diese Studie ist bereits in den
lokalen Cache der Workstation A vorabgerufen und die Studie wird
lokal geladen. Außerdem
werden über
einen Replikations- und Synchronisationsmechanismus wie dem oben
besprochenen Workstation B und die Bilddatenverwaltung darüber benachrichtigt,
dass Dr. Meier gerade die CT-Brustkastenstudie von "Frau Schmidt" liest. Die CT-Brustkastenstudie
von "Frau Schmidt" ist nun für Dr. Meier
reserviert.
-
Falls
Dr. Meier jedoch eine MR-Studie an der Workstation lesen möchte, wird
die entsprechende Studie nicht lokal Cachegespeichert und muss aus
der Datensatz-Datenverwaltung gela den werden. In diesem Fall folgt
Dr. Meier nicht seinem gewöhnlichen
Muster beim Lesen von Bildern und die Vorabrufregel hat dieses Verhalten
deshalb nicht berücksichtigt.
Immer dann, wenn ein Benutzer nicht seinem regulären Lesemuster folgt, werden
anders ausgedrückt
die Studien nicht vorabgerufen und müssen aus der Bilddatenverwaltung
geladen werden, was zu längeren
Ladezeiten führt.
Dennoch wird wiederholter Zugriff von dieser neuen Workstation aus über die
Metadaten, die jede Anforderung erzeugt, erkannt, und die Regeln
werden angepasst, um das neue Verhalten der Benutzer zu berücksichtigen.
-
Zur
Herstellung und Definition der Regeln und Strategien, die von dem
System implementiert werden, kann eine beliebige Anzahl von Kriterien
verwendet werden. Zusätzlich
können
beliebige Arten von Informationen vorabgerufen werden. Das System
ist nicht auf Bilddaten oder sogar medizinische Daten beschränkt.
-
Zum
Zwecke des Förderns
eines Verständnisses
der Prinzipien der Erfindung wurde auf die bevorzugten Ausführungsformen
Bezug genommen, die in den Zeichnungen dargestellt sind, und es
wurde spezifische Sprache zur Beschreibung dieser Ausführungsformen
benutzt. Durch diese spezifische Sprache ist jedoch keinerlei Einschränkung des
Schutzumfangs der Erfindung beabsichtigt und die Erfindung sollte
so aufgefasst werden, dass sie alle Ausführungsformen umfasst, die normalerweise
Durchschnittsfachleuten einfallen würden.
-
Die
vorliegende Erfindung kann im Hinblick auf Funktionsblockkomponenten
und verschiedene Verarbeitungsschritte beschrieben werden. Solche
Funktionsblöcke
können
durch eine beliebige Anzahl von Hardware- und/oder Softwarekomponenten
realisiert werden, die dafür
konfiguriert sind, die spezifizierten Funktionen auszuführen. Zum
Beispiel kann die vorliegende Erfindung verschiedene integrierte
Schaltungskomponenten benutzen, z.B. Speicherelemente, Verarbeitungselemente,
Logikelemente, Nachschlagetabellen und dergleichen, die vielfältige Funktionen
unter der Kontrolle eines oder mehrerer Mikroprozessoren oder anderer Steuereinrichtungen
ausführen
können.
Wo Elemente der vorliegenden Erfindung unter Verwendung von Softwareprogrammierung
oder Softwareelementen implementiert sind, kann die Erfindung ähnlich mit
beliebiger Programmierungs- oder Skript-Sprache wie etwa C, C++,
Java, Assembler oder dergleichen implementiert werden, wobei die
verschiedenen Algorithmen mit einer beliebigen Kombination von Datenstrukturen,
Objekten, Prozessen, Routinen oder anderen Programmierelementen
implementiert werden. Ferner könnte
die vorliegende Erfindung eine beliebige Anzahl herkömmlicher
Techniken für
Elektronikkonfiguration, Signalverarbeitung und/oder Steuerung,
Datenverarbeitung und dergleichen verwenden.
-
Die
hier gezeigten und beschriebenen konkreten Implementierungen sind
lediglich Anschauungsbeispiele der Erfindung und sollen den Schutzumfang
der Erfindung auf keinerlei Weise anderweitig begrenzen. Der Kürze halber
können
herkömmliche
Elektronik, Steuersysteme, Softwareentwicklung oder andere funktionale
Aspekte der Systeme (und Komponenten der einzelnen Betriebskomponenten
der Systeme) nicht im Detail beschrieben werden. Ferner sollen die
Verbindungslinien oder Verbinder, die in den verschiedenen Figuren gezeigt
sind, beispielhafte Funktionsbeziehungen und/oder physische oder
logische Kopplungen zwischen den verschiedenen Elementen repräsentieren.
Es sollte beachtet werden, dass viele alternative oder zusätzliche
Funktionsbeziehungen, physische Verbindungen oder logische Verbindungen
in einer praktischen Einrichtung vorhanden sein können. Darüber hinaus
ist kein Element oder keine Komponente für die Ausübung der Erfindung wesentlich,
wenn das Element nicht spezifisch als "wesentlich" oder "kritisch" beschrieben wird. Fachleuten werden
ohne weiteres zahlreiche Modifikationen und Anpassungen einfallen,
ohne vom Gedanken und Schutzumfang der vorliegenden Erfindung abzuweichen.
