DE102007007326A1

DE102007007326A1 - Multisite-Szenarien beim Speichern und Archivieren von medizinischen Datenobjekten

Info

Publication number: DE102007007326A1
Application number: DE102007007326A
Authority: DE
Inventors: Thomas Haug; Achim Scheidl; Thomas Sagamore Hills Dechant
Original assignee: Siemens Corp
Current assignee: Siemens Healthcare GmbH
Priority date: 2007-02-14
Filing date: 2007-02-14
Publication date: 2008-09-04
Also published as: US20080215732A1

Abstract

Die vorliegende Erfindung betrifft ein Verfahren, ein Verwaltungssystem und ein Computerprogrammprodukt zum Speichern und Archivieren von medizinischen Bilddaten (BD) und Meta-Daten (MD) in einem verteilten System einer klinischen Einrichtung, mit einem zentralen Server (AS), einem zentralen Archiv (A) und einer Vielzahl von dezentralen Knoten (K), wobei die Bilddaten (BD) dezentral auf dem jeweiligen Knoten (K) gespeichert werden und wobei die Meta-Daten (MD) nur zentral auf dem zentralen Server (AS) gespeichert werden.

Description

Die Erfindung liegt auf dem Gebiet der Medizintechnik und der Datenverarbeitung. Sie betrifft insbesondere einen Ansatz zum Verwalten, insbesondere zum Speichern und zum Archivieren, von medizinischen Bilddatenobjekten in einer verteilten klinischen Einrichtung, umfassend mehrere Sites.
Der informationstechnologische Hintergrund der meisten heutigen klinischen Einrichtungen ist ein verteiltes System, was eine Vielzahl von unterschiedlichen Standorten mit unterschiedlichen computerbasierten Anwendungen umfasst. Neben einem oder mehreren zentralen Servern sind unterschiedliche Modalitäten (Computer-Tomographen, Magnetresonanz-Tomographen, Röntgen-Geräte etc.) und unterschiedliche Workstations angeschlossen. Ein Teil derselben kann einer Krankenhausabteilung oder einer Untereinheit einer klinischen Einrichtung zugeordnet werden. Weitere angeschlossene Sub-Systeme können niedergelassene Arztpraxen, Labors oder weitere Krankenhäuser umfassen. Die meisten Daten liegen heute in digitaler Form vor und sollen über alle Einheiten der klinischen Einrichtung ausgetauscht und transferiert werden können.
Geht man davon aus, dass es zumindest eine zentrale Hauptverwaltungseinheit (main site) und eine Vielzahl von daran angeschlossenen rechnerbasierten Knoten (satellite sites) gibt, so ist es im Stand der Technik bei den bekannten Systemen vorgesehen, die Daten sowohl verteilt zu speichern, als auch, diese verteilt zu archivieren. Bekannt ist also eine dezentrale Speicherung und eine dezentrale Archivierung. In Anbetracht der Tatsache, dass gerade im bildgebenden medizinischen Sektor ein enormes Datenvolumen zu speichern und zu archivieren ist, führt dieser Ansatz zwangsläufig zu einem sehr hohen Speicherplatzverbrauch, der sich nachteilig auf die Perfor mance und auf den Wartungsaufwand des Systems insgesamt auswirkt.
Im Folgenden soll exemplarisch ein bekanntes Datenverwaltungssystem beschrieben werden. Das SIENET MagicStore der Firma Siemens ist ein Beispiel eines bekannten Datenmanagement-Systems für verteilte Systeme. Eine zentrale Komponente ist dabei verantwortlich für die Administration, Speicherung und Archivierung von digitalen Röntgenbildern. Es können unterschiedliche Bilddatenbanken (Image Management System – IMS) an die zentrale Patienten-Datenbank angeschlossen werden. Dieses System basiert auf einer verteilten Datenspeicherung. Die Daten, die z. B. im Rahmen einer (Röntgen) Untersuchung erfasst werden, werden in zwei unterschiedlichen Datenbanken gespeichert und verwaltet. Zum Einen ist die Patientendatenmanagement-Datenbank (Patient Data Management Database; PDIR) vorgesehen, die zur Speicherung von allen Untersuchungsdatensätzen für alle Patienten bestimmt ist. Darüber hinaus sind darin bestimmte Daten-Charakteristika in Bezug auf jeden Patienten gespeichert, wie beispielsweise der Patienten-Name, das Geburtsdatum, das Geschlecht, die Station und eine Patienten-Identifikationsnummer gespeichert. Zum Anderen ist eine Bildmanagement-Systemdatenbank (Image Management System Database; IMS) vorgesehen, die zur Verwaltung von Bildern einer Untersuchung bestimmt ist, die in einem Bildspeichersystem abgelegt sind, wie beispielsweise einem RAID-System (Redundant Array of Independent Discs; RAID). In der IMS-Datenbank können beispielsweise Bilder von Patienten abgelegt sein, die aktuell gerade untersucht werden oder die unlängst untersucht worden sind.
Wenn nun von bestimmten Arbeitsplatzrechnern Abfragen in Bezug auf Patienten abgesetzt werden, so werden diese bei den vorstehend erwähnten Datenbanken (PDIR, IMS) durchsucht. Abhängig von den jeweils eingegebenen Suchkriterien kann beispielsweise nach allen Untersuchungen in Bezug auf einen bestimmten Patienten gesucht werden oder es ist möglich, die Untersuchungen aller Patienten anzeigen zu lassen, die inner halb einer bestimmten Zeitperiode untersucht worden sind. Die mittels der Suchanfrage aufgefundenen Datenobjekte bzw. Untersuchungen können dann in den Speicher des jeweiligen Arbeitsplatzes bzw. des Rechners (hier MagicView-Workstation) geladen werden, um dort, falls erforderlich, weiterverarbeitet zu werden. Es ist grundsätzlich auch möglich, mehr als ein SIENET-Magic-Store-System innerhalb eines SIENET-Netzwerkes zu verwenden. Die Bilder einer jeweiligen Modalität (CT, MR etc.) wurden stets auf einem spezifischen SIENET-Magic-Store-System gespeichert und archiviert.
Bisher wurde allerdings nicht zwischen den Bilddaten und den Meta-Daten in Hinblick auf ihre Speicherart unterschieden. Deshalb wurden sowohl die Bilder, als auch die Meta-Daten dezentral, mehrfach lokal auf den jeweiligen File-Servern abgelegt. In der Praxis hat sich das bisherige Vorgehen jedoch aus mehreren Gründen als nachteilig erwiesen. Zum einen besteht ein wesentlicher Nachteil darin, dass das bisherige System ein relativ hohes Fehlerpotential birgt, da bei Änderungen an einem Datensatz alle Instanzen des jeweiligen Datensatzes mit geändert werden müssen. Kann aufgrund eines lokalen Computerfehlers jedoch diese Änderung nur an einer Workstation nicht nachvollzogen werden, so besteht bereits eine Inkonsistenz in Bezug auf die Daten, was schwerwiegende Fehler nach sich ziehen kann. Ein anderer Nachteil ist in dem relativ hohen Wartungsaufwand zu sehen, da bei einer Änderung grundsätzlich alle Instanzen des jeweiligen Datensatzes und somit mehrfach lokal mitberücksichtigt und mitgeändert werden müssen.
Die vorliegende Erfindung hat sich deshalb zur Aufgabe gesetzt, einen Weg aufzuzeigen, mit dem ein Speichern und ein Archivieren von Datenobjekten, umfassend Bilddaten und Meta-Daten, in Bezug auf die Bilddaten verbessert, insbesondere effizienter und weniger fehleranfällig gestaltet werden kann.
Die vorliegende Erfindung wird durch die beiliegenden Hauptansprüche gelöst, insbesondere durch ein Verfahren, ein Ver waltungssystem und ein Computerprogrammprodukt gemäß der beiliegenden Patentansprüchen.
Im Folgenden wird die Erfindung anhand der verfahrensgemäßen Lösung beschrieben. Hierbei erwähnte Vorteile, Merkmale oder alternative Ausführungsformen sind ebenso auch auf die anderen beanspruchten Gegenstände zu übertragen, insbesondere auf das System und den Bestückungsapparat sowie auf das Produkt. Mit anderen Worten können auch die vorstehend genannten beanspruchten Gegenstände mit Merkmalen weitergebildet sein, die in Zusammenhang mit dem Verfahren beschrieben und/oder beansprucht worden sind und umgekehrt.
Die Erfindung wird insbesondere gelöst durch ein Verfahren zum Verwalten von medizinischen Daten, umfassend Bilddaten und diesen jeweils zugeordneten Meta-Daten, in einem verteilten Netzwerk-System einer klinischen Einrichtung, umfassend:

– zumindest einen zentralen Server und
– eine Vielzahl von dezentralen Knoten,

Unter dem Begriff "Verwalten" sollen erfindungsgemäß alle administrativen Aufgaben in Bezug auf medizinische Daten verstanden werden, was insbesondere ein Kurzzeit-Speichern, ein Langzeit-Speichern, ein Archivieren und/oder einen Zugriff auf gespeicherte und/oder archivierte Daten umfasst.
Bei den medizinischen Daten handelt es sich vorzugsweise um medizinische Untersuchungsdaten, die von beliebigen Modalitäten erfasst worden sind, wie beispielsweise mit einem Magnet resonanz-Tomographen, einem Computer-Tomographen, einem Röntgen-Gerät oder dergleichen. In der Regel handelt es sich um Bilddaten in dem DICOM-Format. Ein Datenobjekt besteht also aus Bilddaten (den eigentlichen Bildern einer Studie bzw. Untersuchung) und Meta-Daten in Bezug auf diese Bilddaten. Meta-Daten können in unterschiedlichsten Formaten vorliegen (beispielsweise vom Typ boolean, integer, string etc.). Bei den Meta-Daten kann es sich um patientenspezifische Daten handeln (beispielsweise Name, Alter, Adresse des Patienten etc.), um studienspezifische Daten (von welcher Modalität wurden die Daten erfasst, Art der Modalität und weitere Kennzeichen derselben, Zeitpunkt der Untersuchung etc.) oder um weitere Kennzeichnungen in Bezug auf die Bilddaten handeln.
Die klinische Einrichtung umfasst in der Regel mehrere Abteilungen (Krankenhausstationen, Labors, Rechenzentren etc.) und des Weiteren können beliebige externe Einrichtungen (externe Labors, Arztpraxen etc.) angeschlossen sein. Alle computergestützten Einrichtungen sind über ein Netzwerk verbunden und stehen miteinander in Datenaustausch. Der datentechnische Hintergrund des jeweiligen Netzwerkes kann unterschiedlich sein, so dass neben einem LAN (Local Area Network) auch ein WLAN (Wireless Local Area Network) oder eine Datenübertragung über das Internet oder über Satelliten, sowie über mobile Datenträger (USB-Stick etc.) möglich ist.
Der zentrale Server ist üblicherweise auf der "main site" angeordnet und umfasst ein Datenmanagement-System (z. B. ein SIRIUS-Datenmanagement-System), ein Archiv bzw. einen Langzeitspeicher (LTS, Long Time Storage) und ein Verwaltungssystem (OPM – Operation Management, administrativer Server, beispielsweise in COSMOS-Systemen). In alternativen Ausführungsformen kann der zentrale Server jedoch noch mit weiteren Modulen und Instanzen ausgebildet sein. Vorzugsweise ist jedoch nur ein Verwaltungssystem (OPM) innerhalb des gesamten Netzwerkes vorgesehen, was die Kosten und den Verwaltungsaufwand bei der erfindungsgemäßen Lösung deutlich verringert.
Bei den dezentralen Knoten handelt es sich um beliebige computergestützte Instanzen, Rechner, Arbeitsplätze, aber auch um komplexere Systeme und Teilsysteme wie z. B. Krankenhausabteilungen, Netzwerke von einzelnen oder zusammengeschlossenen Arztpraxen etc. Bei dem computergestützten Knoten kann es sich darüber hinaus um einzelne Modalitäten (MR, CT etc.) um Datenbanken oder um rechnergestützte Arbeitsplätze handeln.
Ein wesentliches Konzept der vorliegenden Erfindung ist darin zu sehen, dass die jeweiligen Datenobjekte (also einzelne Datensätze oder eine Zusammenfassung von mehreren Datensätzen) in zwei unterschiedliche Kategorien eingeteilt werden: nämlich in Bilddaten und in Meta-Daten und, dass diese unterschiedlichen Kategorien hinsichtlich ihrer Speicherung bzw. Archivierung unterschiedlich gehandhabt werden. So ist es erfindungsgemäß vorgesehen, dass die Bilddaten dezentral, also jeweils lokal und mehrfach redundant auf dem jeweiligen Knoten (in der Regel auf Speicherinstanzen, die der jeweiligen Modalität zugeordnet sind) abgelegt werden, während die Meta-Daten, die nur einen Bruchteil des Speicherplatzes der Bilddaten benötigen, zentral auf dem zentralen Server abgelegt werden. Dies hat den Vorteil, dass bei einer Änderung der Daten (in der Regel werden nur die Meta-Daten geändert) nur ein Änderungszugriff notwendig ist. Es müssen keine weiteren Datensätze behandelt werden. Damit kann sowohl der Verwaltungsaufwand deutlich minimiert werden, und es wird möglich, das Fehlerrisiko aufgrund inkonsistenter Datensätze deutlich zu verringern. Darüber hinaus können Zugriffskonflikte vermieden werden.
In einer bevorzugten Ausführungsform der vorliegenden Erfindung ist es vorgesehen, dass alle Objekte, die zu einer Studie bzw. zu einer Untersuchung gehören, auf ein- und demselben File-Server abgelegt werden. Bei dem File-Server handelt es sich um einen Computer bzw. um einen computergestütztes System einer angeschlossenen Site (Satellite Site) oder der main site, der für ein zentrales Speichern und Datenmanagement verantwortlich ist, so dass andere Computer (entfernte Knoten) desselben Netzwerkes auf die Daten des File-Servers zugreifen können. Darüber hinaus stellt der File-Server sicher, dass die Information über das Netzwerk auch anderen Nutzern (bzw. Knoten) zur Verfügung steht. Durch das Merkmal, dass grundsätzlich alle Datenobjekte einer Studie auf nur einem File-Server abgelegt werden, kann der Verwaltungsaufwand erfindungsgemäß weiter verringert werden.
Gemäß einer weiteren vorteilhaften Ausführungsform ist es vorgesehen, dass die Bilddaten jeweils immer nur auf einem Knoten, insbesondere auf einem File-Server, abgelegt sind. Damit kann der Speicherplatz minimiert werden und es werden Fehler ausgeschlossen, die bei einer redundanten Speicherung der Bilddaten entstehen könnten.
In einer weiteren vorteilhaften Ausführungsform umfasst das Verfahren einen Zugriffs-Mechanismus, der sicherstellt, dass auf einem ersten Knoten abgelegte Bilddaten auch von einem zweiten Knoten angefordert werden können und/oder von diesem zugreifbar sind. Damit wird sichergestellt, dass ein Datenaustausch im Hinblick auf die Bilddaten auch zwischen den dezentralen Knoten möglich ist. Vorteilhafterweise wird der Zugriff über den zentralen Server vermittelt. In der bevorzugten Ausführungsform geschieht dies, indem die auf dem zentralen Server abgelegten Meta-Daten hinsichtlich eines Speicherortes für die angefragten Bilddaten abgefragt werden.
In einer weiteren vorteilhaften Ausführungsform umfasst das Verfahren einen Synchronisations-Mechanismus, der sicherstellt, dass keine inkonsistenten Datenobjekte, insbesondere durch parallele Zugriffe, abgelegt werden. Damit kann die Sicherheit des Systems erhöht werden. Beispielsweise wird von vornherein ausgeschlossen, dass für ein und denselben Zeitpunkt ein und derselbe Patient mit unterschiedlichen Modalitäten untersucht wird. Sollte also ein solcher Datensatz im System gespeichert werden, obwohl bereits für diesen Zeitraum und den jeweiligen Patienten ein Datensatz existiert, wird eine Fehlermeldung ausgegeben. In einer komplexeren Ausfüh rungsform sind weitere Überprüfungsmechanismen vorgesehen, die zu einer Ausgabe von Fehlermeldungen führen, beispielsweise bei unerlaubten Löschaktionen oder dergleichen.
In einer vorteilhaften Ausführungsform basiert das erfindungsgemäße Verfahren darauf, dass innerhalb des verteilten Netzwerksystems der klinischen Einrichtung nur ein Verwaltungssystem (OPM – Operation Management System) vorgesehen ist. Damit kann der Verwaltungsaufwand deutlich gesenkt werden.
Weiterhin ist es möglich, dass das Verfahren neben einem Archivieren von Datenobjekten auch ein Dearchivieren umfasst, wobei Datenobjekte aus dem Archiv geladen werden.
Grundsätzlich ist es möglich, dass bei einem Zugriff auf die Bilddaten eine Wahlmöglichkeit für den Anwender besteht: Es kann ausgewählt werden, ob tatsächlich die originalen Bilddaten angezeigt werden sollen oder ob nur eine Miniaturdarstellung der jeweiligen Bilddaten (als Token oder Thumbnail) angezeigt werden soll. Damit entsteht der Vorteil, dass das Verfahren flexibler gestaltet werden kann und die Zugriffszeiten durch das Laden einer Miniaturdarstellung weiter verringert werden können. In alternativen Ausführungsformen wird dieses Konfigurationsmerkmal nicht vom Anwender ausgeführt, sondern von der zugrundeliegenden Anwendung (also automatisch vom System) oder von einem System-Administrator oder von anderen Instanzen des Netzwerkes.
Eine alternative Aufgabenlösung sieht ein Speichermedium vor, das zur Speicherung des vorstehend beschriebenen, computerimplementierten Verfahrens bestimmt ist und von einem Computer lesbar ist.
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 eine übersichtsartige schematische Darstellung eines klinischen Netzwerksystems zur Verwaltung von medizinischen Datensätzen;
2 eine Darstellung eines möglichen Arbeitsablaufes zum Laden von Tokens und Bildern an einen Arbeitsplatzrechner zwischen unterschiedlichen Knoten des Netzwerksystems gemäß einer bevorzugten Ausführungsform der Erfindung;
3 eine Darstellung eines möglichen Arbeitsablaufes zum Speichern von Bildern auf einem File-Server gemäß einer bevorzugten Ausführungsform der Erfindung;
4 eine schematische übersichtsartige Darstellung eines möglichen Funktionsablaufes zum Archivieren von Bildern gemäß einer bevorzugten Ausführungsform der Erfindung;
5 eine schematische übersichtsartige Darstellung eines möglichen Funktionsablaufes zum Dearchivieren gemäß einer bevorzugten Ausführungsform der Erfindung; und
6 eine schematische übersichtsartige Darstellung eines möglichen Funktionsablaufes zum Dearchivieren, falls die Datenobjekte auf unterschiedlichen File-Servern gespeichert sind.
Im Folgenden wird in Zusammenhang mit 1 der grundlegende Aufbau des erfindungsgemäßen Systems und der grundlegende Ablauf des erfindungsgemäßen Verfahrens geschildert.
Das erfindungsgemäße Verfahren ist zur Verwaltung von Datensätzen bzw. Datenobjekten ausgelegt, die neben Bilddaten BD auch Meta-Daten MD umfassen. Die Bilddaten BD stammen von Modalitäten unterschiedlicher Art (CT, MR, PET etc.), während die Meta-Daten MD in der Regel textuelle Daten sind, die Meta-Informationen in Bezug auf die Bildobjekte darstellen (patientenspezifische Daten, untersuchungsspezifische Daten, modalitätsspezifische Daten etc.). Ein Datenobjekt umfasst also Bilddaten BD und Meta-Daten MD.
Das erfindungsgemäße Verfahren zielt nun darauf ab, die Bilddaten BD dezentral und somit lokal auf dem jeweiligen Knoten K zu speichern, während die zugehörigen Meta-Daten MD nur zentral auf dem zentralen Server Z abgelegt werden.
In 1 ist eine zentrale Hauptinstanz – auch main site – Z in ein erfindungsgemäßes Netzwerk einer klinischen Einrichtung eingebettet, die als zentraler Server Z fungiert. An dem zentralen Server Z sind eine Vielzahl von Satelliten, auch satellite sites genannt, angeschlossen, die ebenso als Knoten K des Netzwerkes dienen. Zwischen den Satellitenknoten K und dem zentralen Server Z besteht eine datentechnische Verbindung in Form eines Netzwerkes. In der bevorzugten Ausführungsform handelt es sich bei den Satelliten-Knoten K beispielsweise um Laboratorien, Arztpraxen oder um Krankenhausabteilungen. Die main site wird in der Hauptinstanz der klinischen Einrichtung angeordnet sein und umfasst in der bevorzugten Ausführungsform einen Applikationsserver AS, in dem die Speicherorte bzw. Adressen für Datenobjekte verwaltet werden. In der bevorzugten Ausführungsform umfasst die main site Z folgende Instanzen:

– einen Applikationsserver AS,
– ein Datenmanagement-System, beispielsweise ein SIRIUS-Datenmanagement-System,
– einen zentralen File-Server FS,
– ein Archiv A bzw. einen Langzeitspeicher LTS (Long Time Storage – LTS),
– eine Verwaltungsinstanz, die auch als Operation Management-Instanz bezeichnet wird OPM und die für administrative Dienste und Aufgaben bestimmt ist.

In alternativen Ausführungsformen kann der zentrale Server Z noch weitere Instanzen umfassen oder er kann nur Ausschnitte der vorstehend erwähnten Instanzen beinhalten. Darüber hinaus ist es möglich, die Instanzen integral in den Server Z zu integrieren oder diese über datentechnische Verbindungen (bzw. über ein Netzwerk) an entfernten Stellen vorzusehen und diese an den Server Z anzubinden.
Der zentrale Server Z steht mit einer Vielzahl von satellite sites in Verbindung. Die Satelliten-Knoten K umfassen – wie ebenfalls in 1 schematisch dargestellt – einen lokalen File-Server FS, einen Webserver WS und vorzugsweise einen Kurzzeitspeicher (Short Time Storage) STS. Bei den Satelliten-Knoten K kann es sich um beliebige rechnergestützte Arbeitsplätze, insbesondere SIRIUS-Arbeitsplätze, SWP handeln. Ebenso sind als Satelliten-Knoten K die Modalitäten, Befundungsrechner, Laborrechner etc. an dem zentralen Server Z angebunden und stehen mit ihm in Datenaustausch.
Werden beispielsweise im Rahmen einer medizinischen Untersuchung Röntgenbilder an einem Röntgen-Gerät erfasst, der als Knoten K dem System angeschlossen ist, so ist es erfindungsgemäß vorgesehen, dass die jeweiligen Bilddaten BD der Röntgenbilder in dem jeweiligen lokalen File-Server FS der Modalität abgelegt werden. Möchte nun ein befundender Arzt, der an einem anderen Arbeitsplatz SWP arbeitet, auf diese Bilder zugreifen, so sendet er eine entsprechende Anfrage an die zentrale Instanz Z. Der Applikationsserver AS teilt dem anfragenden Arbeitsplatz SWP mit, auf welchem File-Server bzw. wo die angefragten Bilddaten BD abgelegt sind. Dies erfolgt unter Zugriff auf die jeweiligen Meta-Daten MD der angefragten Bilddaten BD. Daraufhin kann der anfragende Arbeitsplatz SWP unmittelbar und direkt auf den File-Server FS zugreifen, auf den die angefragten Bilddaten BD abgelegt sind. Ein Meta-Datensatz verweist also eineindeutig auf die ihm zugeordneten Bilddaten BD.
Die Bilddaten BD sind also stets auf dem lokalen File-Server FS gespeichert. Falls es notwendig ist, dass ein Client Meta-Daten (patientenspezifische Daten, demografische Daten oder Workflow-Daten etc.) abfragt, so muss er eine Anfrage an den zentralen Applikationsserver AS schicken, der auf der main site Z angeordnet ist. Der Bildtransfer von dem Datenmanagement-System wird durch eine Anfrage von dem jeweiligen Arbeitsplatz SWP an den zentralen Applikationsserver AS initiiert. Der Applikationsserver AS initiiert den Transfer von dem lokalen oder von einem entfernten File-Server FS, der die angefragten Bilddaten BD gespeichert hat, zu dem Arbeitsplatz SWP. Da die Bilddaten BD jeweils auf dem lokalen, der jeweiligen site zugeordneten File-Server FS gespeichert sind, und da es sehr wahrscheinlich ist, dass von dem jeweiligen Arbeitsplatz der site aus auf diese lokalen Bilddaten BD zugegriffen wird, erfolgt dieser Transfer innerhalb des LAN.
Es ist jedoch auch möglich, Bilddaten BD von einem entfernten Knoten K, also von einer remote site, anzufordern. In diesem Fall wird von dem jeweiligen Knoten K eine direkte Verbindung zu dem jeweiligen File-Server FS der remote site aufgebaut.
Da das hohe Datenvolumen hauptsächlich durch die Bilddaten BD entsteht, ist es erfindungsgemäß vorgesehen, dass lediglich die Bilddaten BD in ein Archiv A geladen werden, während die zugehörigen Meta-Daten MD (die lediglich ein deutlich geringeres und vergleichsweise zu vernachlässigendes Datenvolumen aufweisen) auf dem jeweiligen lokalen File-Server verbleiben und nicht archiviert werden. Die Meta-Daten MD dienen auch als Zeiger für den Zugriff auf die jeweiligen Bilddaten im Archiv A oder auf dem jeweiligen lokalen File-Server FS. Die Bilddaten BD werden in das Archiv A archiviert, das auf dem zentralen Server Z als Long-Time-Storage (LTS) angeordnet ist. Das zentrale Datenmanagement-System DMS verwendet die Meta-Daten MD sozusagen als Zeiger, also als Angabe, auf welchem File-Server FS die Bilddaten gespeichert sind, falls Bilddaten BD aus dem Archiv A geladen werden müssen. Dies wird auch als Dearchivierungsvorgang oder Prefetching be zeichnet. In der bevorzugten Ausführungsform ist es vorgesehen, dass das Archivieren und/oder das Dearchivieren konfigurierbar ist und/oder von der jeweiligen Krankenhausabteilung abhängt.
Vorzugsweise ist lediglich eine Verwaltungsinstanz OPM auf dem zentralen Server S vorgesehen. Alle Arbeitsplätze und alle Datenmanagement-Dienste greifen auf die Verwaltungsinstanz OPM zu, um Verwaltungsdaten bzw. sonstige administrative Daten zu erhalten.
Ein RIS-System (Radiology Information System – RIS) ist zur Planung und Verwaltung aller Patientenuntersuchungen von allen Abteilungen verantwortlich. Das zugrundeliegende Netzwerk zwischen den satellite sites und der main site verfügt vorzugsweise über eine ausreichende Bandbreite, um die jeweiligen Datenzugriffe in einer zufriedenstellenden Geschwindigkeit ausführen zu können. Ein wesentlicher Vorteil der erfindungsgemäßen Lösung ist darin zusehen, dass keine spezielle Synchronisation notwendig wird, da lediglich eine zentrale Datenbank erforderlich ist. Es ist lediglich ein Datenmanagement-System auf dem zentralen Server Z vorgesehen. Darüber hinaus müssen die jeweiligen Knoten (auch Hosts genannt) des verteilten File-Systems bezüglich ihrer computergestützten Infrastruktur weniger aufwendig ausgerüstet sein, da alle wesentlichen Instanzen zentralisiert auf dem zentralen Server Z bereitgestellt werden. Da nur eine Datenbank existiert, ist vorteilhafterweise auch nur eine Datenbank-Lizenz erforderlich. Darüber hinaus kann der Speicherplatz zur Speicherung der jeweiligen Datenobjekte deutlich verringert werden.
In 2 ist schematisch ein Arbeitsablauf vorgestellt, der beim Laden von Token oder von Bildern auf einem Arbeitsplatz SWP ausgeführt wird. Falls der Anwender die entsprechende Prozedur auf dem Arbeitsplatz SWP anklickt, wird eine "getPatientContext-Anfrage" und eine "loadToken-Anfrage" initiiert. Der zentrale Datenmanagement-Applikationsserver AS bestimmt daraufhin, auf welchen/welchem File-Servern) FS die jeweili gen Bilddaten bzw. Token gespeichert sind. Als Ergebnis der Anfrage wird eine Information bereitgestellt, wie der jeweilige File-Server FS angesprochen werden kann. Diese Information wird direkt und unmittelbar an den jeweiligen Arbeitsplatz SWP weitergeleitet, der daraufhin die jeweiligen File-Server kontaktiert. Die lokalen File-Server FS liefern daraufhin die entsprechenden Tokens bzw. Bilddaten BD zurück. Die Tokens befinden sich in einer bestimmten Reihenfolge (mit einer entsprechenden Nummerierung). Diese Reihenfolge bzw. Nummerierung dient dazu, dass die jeweiligen Tokens oder Bilddaten BD auf dem jeweiligen Arbeitsplatz SWP auch in der korrekten Reihenfolge angezeigt werden können. Falls vom Anwender ein Laden von Bilddaten BD veranlasst wird, so ist es vorgesehen, dass die jeweilige Anfrage lediglich die Datenobjekte umfasst, die exakt zu einer Studie gehören, da grundsätzlich nur Datenobjekte einer Studie auf einem File-Server FS abgelegt sind. Die von dem Applikationsserver AS bereitgestellte Information über den Speicherort (also über den/die involvierten. File-Server FS) wird als Anfrage des jeweiligen Clients, die vorzugsweise nach dem SOAP-Protokoll erfolgt, bereitgestellt. Nachdem dem Client die Information zur Verfügung gestellt werden kann, kann dieser den jeweiligen File-Server FS ansprechen und das Laden der Bilddaten BD starten.
Im Folgenden wird eine Kurzdarstellung der jeweiligen Verfahrensschritte in Bezug auf den in 2 dargestellten Arbeitsablauf gegeben, wobei in den Figuren der englische Fachbegriff beibehalten worden ist. So kennzeichnet in 2:
Schritt 1: Einloggen des Anwenders an dem Arbeitsplatz SWP
Schritt 2: Verbindungsaufbau mit dem zentralen Applikationsserver AS.
Schritt 3: Am Arbeitsplatz SWP wird der Patientenkontext von dem zentralen Applikationsserver AS aufgenommen.
Schritt 4: Arbeitsplatz SWP fragt den zentralen Applikationsserver AS nach den Tokens der Bilder des Patienten.
Schritt 5: Der zentrale Applikationsserver AS greift auf die jeweilige Datenbank zu um die Tokens zu lokalisieren.
Schritt 6: Zentraler Applikationsserver AS sendet dem lokalen File-Server FS eine Nachricht, dass eine Ladeanfrage stattfinden wird. Daraufhin wird an den jeweiligen lokalen File-Server FS eine Nachricht über die Adresse bzw. über den Verbindungsaufbau gesendet.
Schritt 7: Zentraler Applikationsserver AS sendet dem entfernten File-Server FS eine Nachricht, dass eine Ladeanfrage stattfinden wird. Daraufhin wird an den entfernten lokalen File-Server FS eine Nachricht über die Adresse bzw. über den Verbindungsaufbau gesendet.
Schritt 8: Die übermittelte Information für den Verbindungsaufbau wird verwendet, so dass der Arbeitsplatz auf die Token des lokalen File-Servers FS zugreifen kann.
Schritt 9: Verwendung der Information über den Verbindungsaufbau, so dass der Arbeitsplatz SWP den entfernten File-Server FS für die angefragten Token kontaktiert.
Schritt 10: Der Arbeitsplatz SWP erfragt bei dem zentralen Applikationsserver AS die Bilder des Patienten.
Schritt 11: Zentraler Applikationsserver greift auf die Datenbank zu, um die jeweiligen Bilder zu lokalisieren.
Schritt 12: Zentraler Applikationsserver AS sendet eine Nachricht an den lokalen File-Server FS, dass ein Ladeauftrag stattfinden wird. Daraufhin wird an den Arbeitsplatz SWP eine Information über den Verbindungsaufbau zu dem lokalen File-Server FS übermittelt.
Schritt 13: Verwendung der Information über die Verbindung, so dass der Arbeitsplatz SWP den lokalen File-Server FS für die Bilder befragt.
Schritt 14: Arbeitsplatz SWP kann darüber hinaus den zentralen Applikationsserver AS für frühere Bilder (von zurückliegenden Studien eines Patienten) befragen.
Schritt 15: Zentraler Applikationsserver greift auf die Datenbank zu, um die zurückliegenden Bilder zu lokalisieren.
Schritt 16: Zentraler Applikationsserver AS sendet eine Nachricht an den entfernten File-Server FS, dass ein Ladeauftrag stattfinden wird. Daraufhin wird eine Information über die Verbindung mit dem entfernten File-Server FS zurückgegeben.
Schritt 17: Diese Information über den Verbindungsaufbau wird verwendet, so dass der Arbeitsplatz SWP den entfernten File-Server FS in Hinblick auf die Bilder BD befragt.
Bei diesem Ladeablauf ist zu beachten, dass der Anwender keineswegs darauf beschränkt ist, stets umfassend alle Bilddaten BD zu laden. Er kann auch lediglich die Token als Kurzansichten für die Bilddaten BD laden.
In 3 soll der Ablauf für das Speichern von Bilddaten BD auf einem lokalen oder entfernten File-Server FS erläutert werden.
Schritt 1: Der Anwender sichert die Bilddaten BD auf seinem Arbeitsplatz SWP.
Schritt 2: Der Arbeitsplatz SWP sendet eine Speicheranfrage an den zentralen Applikationsserver AS.
Schritt 3: Der zentrale Applikationsserver AS überprüft mittels eines eineindeutigen Studien-Identifikators (UID), ob auch noch andere Datenobjekte der Studie auf anderen File-Servern FS abgelegt sind. Falls keine anderen Datenobjekte der Studie auf anderen File-Servern FS abgelegt sind, sendet der zentrale Applikationsserver AS die Information über den Verbindungsaufbau mit dem bevorzugten File-Server FS an den jeweiligen Arbeitsplatz SWP. Hier wird also der lokale (Satelliten-)File-Server FS angesprochen.
Schritt 4: Unter Verwendung der Information sichert der Arbeitsplatz SWP die Bilddaten BD auf dem lokalen File-Server FS.
Schritt 5: Die Bilddaten BD werden auf dem lokalen (Satelitten-)File-Server FS gespeichert.
Schritt 6: (als Variante der Schritte 3, 4, 5) Anderenfalls, falls also andere Datenobjekte der Studie auf weiteren File-Servern FS existieren, sendet der zentrale Applikationsserver AS eine Information an den Arbeitsplatz SWP über den jeweiligen Verbindungsaufbau mit dem entfernten File-Server FS, hier auf der main site. Die Bilddaten werden dann auf dem jewei ligen entfernten File-Server FS (remote file server at main site) gesichert.
In 4 ist ein Archivierungsvorgang von Bilddaten BD auf einem Langzeitspeicher LTS dargestellt, der hier als Archiv A fungiert.
Schritt 1: Ein Satelliten-File-Server FS sendet eine Anfrage an den zentralen Applikationsserver AS, dass bestimmte Datenobjekte archiviert werden müssen.
Schritt 2: Der zentrale Applikationsserver AS sucht nach möglichen Datenobjekten, die auf dem LTS archiviert werden sollen. Der zentrale Applikationsserver sendet die Information über die möglichen Datenobjekte an den Satelliten-File-Server FS.
Schritt 3: Unter Verwendung dieser Information sendet der Satelliten-File-Server FS die Dateien bzw. Datenobjekte an das Archiv A zum Zwecke der Archivierung.
Schritt 4: Der File-Server FS sendet eine Anfrage zum Update für Archivadressen bzw. von im Archiv A besetzten Speicherplätzen an den zentralen Applikationsserver AS.
In 5 ist schematisch ein Funktionsablauf für einen Dearchivierungsvorgang dargestellt. Um Wiederholungen zu vermeiden, wird an dieser Stelle für die Beschreibung dieses Verfahrensablaufs auf die bisher verwendeten Figurenbeschreibungen Bezug genommen. Es sei jedoch bemerkt, dass hier, insbesondere bei Schritt 4, eine Bindung der Studie an einen ausgewählten File-Server FS erfolgt. Dieser Bindungsvorgang erfolgt im Rahmen eines Synchronisations-Mechanismus. Es muss sichergestellt werden, dass es keine parallelen Anfragen gibt, um den jeweiligen Datensatz zu verändern (zu speichern, zu archivieren, zu dearchivieren, zu erzeugen oder zu löschen etc.). Um stets konsistente Daten zu gewährleisten, wird sichergestellt, dass die jeweiligen Anfragen in einer bestimmten Reihenfolge abgearbeitet werden.
In einer alternativen Ausführungsform zu der in 5 dargestellten Ausführungsform wird in Zusammenhang mit 6 das Szenario beschrieben, das entsteht, wenn der Applikationsserver AS Dearchivierungsanfragen an File-Server FS senden muss, der Datenobjekte von früheren Studien enthält. In 6 ist bei den Schritten 4 bis 7 gekennzeichnet, dass der Dearchivierungsauftrag aufgeteilt wird auf unterschiedliche Instanzen: Zum Einen wird eine Dearchivierungsanfrage an das zentrale Archiv A gesendet und zum Anderen wird die Dearchivierungsanfrage an einen anderen entfernten Satelitten-File-Server FS gesendet. Als Ergebnis dearchivieren die File-Server FS die angeforderten Datenobjekte von dem zentralen Archiv A.
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 sind. Für einen einschlägigen Fachmann ist es insbesondere offensichtlich, dass die Erfindung teilweise oder vollständig in Soft- und/oder Hardware und/oder auf mehrere physikalische Produkte – dabei insbesondere auch Computerprogrammprodukte – verteilt realisiert werden kann.

Claims

Verfahren zum Speichern von medizinischen Datenobjekten, umfassend Bilddaten (BD) und Meta-Daten (MD) in einem verteilten Netzwerksystem einer klinischen Einrichtung, umfassend: – einen zentralen Server (AS), – eine Vielzahl von dezentralen Knoten (K), wobei die Bilddaten (BD) dezentral auf dem jeweiligen Knoten (K) gespeichert oder in zumindest einem Archiv (A) archiviert werden und wobei die Meta-Daten (MD) zentral auf dem zentralen Server (AS) gespeichert werden, wobei ein Zugriff auf Bilddaten (BD) von lokalen oder von entfernten Knoten (K) über die Meta-Daten (MD) erfolgt, die als Zeiger auf einen Speicherort der Bilddaten (BD) fungieren.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass alle Datenobjekte, die zu einer Studie gehören, auf jeweils einem File-Server (FS) abgelegt werden.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Bilddaten (BD) jeweils immer auf einem Knoten (K), insbesondere auf einem File-Server (FS), abgelegt sind.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Verfahren einen Zugriffs-Mechanismus umfasst, der sicherstellt, dass auf einem ersten Knoten (K₁) abgelegte Bilddaten (BD) auch von einem zweiten Knoten (K₂) angefordert werden können und/oder zugreifbar sind.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Verfahren einen Synchronisations-Mechanismus bereitstellt, der sicherstellt, dass keine inkonsistenten Datenobjekte abgelegt werden.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Verfahren einen direkten Datenaustausch zwischen einem ersten Knoten (K₁) und einem zweiten Knoten (K₂) umfasst, wobei eine Adresse für den Zugriff von dem zentralen Server (AS) bereitgestellt wird.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Verfahren lediglich eine Verwaltungsinstanz (OPM) zur zentralen Verwaltung der Datenobjekte umfasst.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Verfahren auch ein Laden von Bilddaten (BD) aus einem Speicher (STS) oder aus einem Archiv (LTS, A) umfasst.
Verwaltungssystem zum Speichern von medizinischen Datenobjekten, umfassend Bilddaten (BD) und Meta-Daten (MD), in einem verteilten Netzwerksystem einer klinischen Einrichtung, mit: – einem zentralen Applikationsserver (AS), mit einem zentralen File-Server (FS) und einem zentralen Archiv (A), zur Archivierung von Bilddaten (BD), – einer Vielzahl von dezentralen Knoten (K), die jeweils mit einem zugehörigen, lokalen File-Server (FS) ausgestattet sind, wobei die dezentralen File-Server (FS), die den Knoten (K) zugeordnet sind, zum Speichern der Bilddaten (BD) bestimmt sind und wobei der zentrale File-Server (FS), der dem zentralen Applikationsserver (AS) zugeordnet ist, zum zentralen Speichern der Meta-Daten (MD) bestimmt ist, und wobei das Archiv (A) zum Archivieren von Bilddaten (BD) bestimmt ist, wobei jeweils ein Zugriff auf Bilddaten (BD), die in dem Archiv (A) oder in einem File-Server (FS) abgelegt sind, über die in dem zentralen Applikationsserver (AS) abgelegten Meta-Daten (MD) erfolgt.
Computerprogrammprodukt, welches direkt in einen Speicher eines Computers ladbar ist, mit Programm-Code-Mitteln, um alle Schritte eines Verfahrens nach zumindest einem der Verfahrensansprüche 1 bis 8 auszuführen, wenn das Programm in dem Computer ausgeführt wird.