-
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.
-
Die
US 6 721 780 B1 offenbart Verfahren und Systeme, um Netzinhalte von einem Server zu laden. Insbesondere werden dazu Informationen darüber bereitgestellt, welche Webseiten von Nutzern am wahrscheinlichsten angefordert werden, um diese dann bereits vor der eigentlichen Anforderung „vorabzurufen“. Die
US 6 085 193 A offenbart Verfahren und Systeme, um Daten für Clients unter Verwendung einer Proxy-Server Hierarchie „vorzuladen“.
-
Die
US 2004 / 0 024 812 A1 offenbart ein Veröffentlichungssystem, welches eine Integration und Verarbeitung von Inhalten in Echtzeit gestattet und dynamische Datengenerierung unterstütz.
-
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. Zum Beispiel wird das Vorabrufen digitaler medizinischer Bilder durch Technologie überflüssig, wenn ein medizinischer Spezialist eine Lis- te von Bildern, die er einen Tag später konsultieren möchte, im voraus präsentiert, 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 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.
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 ein Verfahren nach Anspruch 1. Insbesondere können verschiedenen Ausführungsformen eine Selbstoptimierungs-Cache-Strategie für Bilddaten betreffen, bei der jeder Arbeitsplatz nicht direkt mit der Bilddatenverwaltung verbunden ist, sondern stattdessen über einen Proxy-Dienst. Alle existierenden Proxy-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 kann insbesondere ein Vorabruf-Cache-Dienst bereitgestellt werden, 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 werden eine Ausführungsformen mit Bezug auf die nachfolgend besprochenen Figuren beschrieben.
- 1 ist ein Blockschaltbild der Hauptkomponenten 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, 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 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 verteilte 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 Langsamkeit 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 Benutzer 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 zentralen 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), 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 | | Benutzer A: Dr. Meier | Benutzer B: Dr. Müller |
| Workstation A | sendet letzte N ungelesene CT-Brustkastenstudien zu Workstation A | |
| Workstation B | sendet letzte N ungelesene CT-Brustkastenstudien zu Workstation B | |
| Workstation C | | sendet letzte N ungelesene MR-Studien zu Workstation C |
-
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 Cache-gespeichert und muss aus der Datensatz-Datenverwaltung geladen 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.
