DE102006050348A1

DE102006050348A1 - Abfragesystem für medizinische Daten

Info

Publication number: DE102006050348A1
Application number: DE102006050348A
Authority: DE
Inventors: Norbert Dürbeck; Maciej Knoxville Kojro
Original assignee: Siemens AG
Current assignee: Siemens Healthcare GmbH
Priority date: 2006-10-25
Filing date: 2006-10-25
Publication date: 2008-04-30
Anticipated expiration: 2026-10-26
Also published as: DE102006050348B4

Abstract

Die Erfindung betrifft ein Verfahren, ein System und ein Produkt zum Zugriff auf medizinische Dateneinheiten, insbesondere Bilddaten, einer medizinischen Einrichtung in einem Verbund aus rechnergestützten Knoten (K). Dabei generiert eine Applikation (A) eine Anfrage zur Suche bzw. zum Laden von Daten für einen Datenzugriff. Diese Anfrage wird automatisch in einer Query umgesetzt, wobei automatisch alle für die Anfrage relevanten Attribute und/oder deren Ausprägungen aus der Menge der Attribute ausgewählt und berücksichtigt werden. Daraufhin wird die Query an alle oder ausgewählte Empfänger (E) über ein Netzwerk (NW) weitergeleitet. Nach Abarbeiten der Query auf dem Empfänger (E) wird ein Ergebnis der Query an einen Sender (S) der Anfrage weitergeleitet, aufgrund dessen der Zugriff ausgeführt wird.

Description

Die Erfindung liegt auf dem Gebiet der Datenverarbeitung und betrifft insbesondere den Zugriff auf medizinische Datensätze, die in einem verteilten System abgelegt sind.
Die Erfindung bezieht sich insbesondere auf ein Verfahren zum Zugriff auf medizinische Daten in einer medizinischen Einrichtung, umfassend eine Vielzahl von rechnergestützten Knoten, die als DICOM-Knoten und als Nicht-DICOM-Knoten ausgebildet sind und zum Datenaustausch von (vorwiegend) Bilddaten bestimmt sind.
DICOM steht für Digital Imaging and Communication in Medicine und ist ein offener Standard zum Austausch von digitalen Bildern in der Medizin, wobei insbesondere das Format zur Speicherung der Bilddaten und das Kommunikationsprotokoll zum Datenaustausch der Bilddaten standardisiert sind. Derzeit ist der DICOM-Standard in der Version 3.0 verfügbar und wird jedoch permanent von mehreren Arbeitsgruppen erweitert. Ziel ist die Interoperabilität zwischen unterschiedlichen medizinischen Systemen von gegebenenfalls unterschiedlichen Herstellern. Nahezu alle medizinische Bildakquisitionsgeräte (z. B. digitale Röntgengeräte, Computer-Tomographen, Magnetresonanz-Tomographen etc.) implementieren diesen Standard.
Grundsätzlich gibt es mehrere Datenmodelle, nach denen die DICOM-Daten strukturiert sind. Unabhängig von dem jeweils verwendeten Datenmodell umfasst ein DICOM-Datensatz einen Header und die optionalen Pixel – bzw. Bilddaten, wie beispielsweise CT- und/oder MR-Bilddaten, andere PDF-Daten oder sonstige Binärdaten. Im Datei-Header sind Metadaten in Bezug auf die jeweiligen Bilddaten abgelegt. Diese Metadaten sind Informationen und Erklärungen in Bezug auf die jeweiligen Bilddaten und betreffen beispielsweise Patienten-Name, Zeitpunkt der jeweiligen Bildakquisition, Modalität der Akquisi tion etc. In der Regel sind sie hierarchisch strukturiert. Bei dem DICOM-Composite-Object-Modell wird die umfassende und in hierarchischer Hinsicht auf einer obersten Ebene angeordnete Entität "Studie" (Study) genannt. Eine Studie kann mehrere (Bild-)Serien umfassen. Jede Serie kann ihrerseits wieder unterschiedliche Instanzen umfassen, wie z. B. "Instance-No.", "Overlay-No.", etc. Unabhängig von der Hierarchie-Ebene sind jeder Entität (Studie, Serie, Instanz) so genannte Attribute zugeordnet, die unterschiedliche Ausprägungen annehmen können, wie z. B. das Attribut "Patienten-Name". Die Attribute sind bei DICOM-Dateien üblicherweise nicht nach den Entitäten geordnet, so dass eine Suche nach Datensätzen, die bestimmte Ausprägungen von Attributen aufweisen, eine mitunter komplexe Aufgabe werden kann.
Da die Anzahl der gespeicherten Dateneinheiten in einer medizinischen Einrichtung sehr umfangreich ist, ist die Suche nach bestimmten Dateneinheiten häufig nicht zufrieden stellend schnell genug.
Deshalb sind im Stand der Technik einige Ansätze entwickelt worden, um die Suche nach spezifischen Dateneinheiten in einer umfangreichen medizinischen Datenbank effizienter zu gestalten. Hierzu zählen ein Parsen jeder einzelner DICOM-Datei in Hinblick auf jede einzelne Quert. Nachteile dieses Verfahrens sind darin zu sehen, dass die Formulierung von komplexen Querys nicht möglich ist und die Performance dennoch nicht zufriedenstellend ist. Ein weiterer Ansatz besteht in einer standardisierten Abfragesprache, wie z. B. X-Path oder X-Query, mit XML als Indexdatei-Format. Darüber hinaus ist ein datenbank-basierter Index möglich, bei dem ein Datenbanksystem für eine Indizierung verwendet wird. Darüber hinaus sind Hybrid-Ansätze zu nennen, die weitere Vorteile bei einer Suche nach spezifischen Dateneinheiten in einem Dateisystem bringen sollen. In diesem Zusammenhang ist für das DICOM-basierte Informationsmodell der so genannte "DICOM DIR"-Ansatz zu nennen. Dabei ist es vorgesehen, eine Auswahl bzw. eine Menge von DICOM-Dateien durch eine Index-Datei, das so genannte DICOM-DIR, mit einem Attributsatz und der Referenz zu der jeweiligen DICOM-Datei zu referenzieren. Auch dieser Ansatz birgt den Nachteil, dass der Attributsatz festgelegt ist und die Möglichkeit fehlt, beliebig konfigurierbare und komplexe Querys bzw. Anfragen zu generieren.
Die vorliegende Erfindung hat sich deshalb zur Aufgabe gestellt, einen Weg aufzuzeigen, mit dem der Zugriff und insbesondere die Suche nach spezifischen Dateneinheiten eines medizinischen Systems verbessert und insbesondere effizienter und variabler gestaltet werden kann, ohne dass es notwendig ist, den Speicherort bzw. die Adresse der gesuchten Datensätze im Vorfeld zu kennen.
Diese Aufgabe wird durch die beiliegenden Hauptansprüche gelöst, insbesondere durch das Verfahren gemäß dem Hauptanspruch, durch ein System und ein Produkt gemäß den weiteren nebengeordneten Ansprüchen.
Die Aufgabe wird nachstehend in Bezug auf die verfahrensgemäße Lösung beschrieben. Hierbei erwähnte Vorteile, Merkmale und alternative Ausführungsformen sind ebenso auf die anderen Lösungen, insbesondere auf das System und das Produkt zu übertragen. Dementsprechend können auch das Produkt und das System mit Merkmalen weitergebildet sein, die in Zusammenhang mit dem Verfahren beansprucht oder beschrieben worden sind. Entsprechendes gilt auch umgekehrt.
Die Aufgabe wird insbesondere gelöst durch ein Verfahren zum Vorbereiten eines Zugriffs und/oder zum Zugriff auf medizinische Dateneinheiten einer medizinischen Einrichtung, umfassend eine Vielzahl von rechnergestützten Knoten, wobei die Dateneinheiten verteilt abgelegt sind und jeweils einer Dateneinheit eine Menge von Attributen in unterschiedlichen Ausprägungen zugeordnet ist, mit folgenden Verfahrensschritten:

– Erfassen einer Anfrage für einen Datenzugriff von einem Sender,
– Umsetzen der erfassten Anfrage in eine Query, bei der die für die Anfrage jeweils relevanten Attribute gegebenenfalls mit deren Ausprägungen aus der Menge aller möglichen Attribute konfigurierbar sind,
– Weiterleiten der Query an zumindest einen Empfänger,
– Abarbeiten der Query durch zumindest einen Empfänger und Generieren eines Ergebnisses in Form einer Speicherortangabe oder einer Adresse für die angefragten Dateneinheiten an einen Knoten, insbesondere an den Sender, und
– gegebenenfalls Ausführen des Zugriffs anhand des Ergebnisses, wobei ein Zeitpunkt des Zugriffs und weitere Parameter des Zugriffs konfigurierbar sind.

Im Folgenden werden die Begrifflichkeiten, wie sie in der vorliegenden Erfindung verstanden werden sollen, kurz erläutert.
Der Zugriff umfasst grundsätzlich alle unterschiedlichen Zugriffsarten, wie insbesondere einen Schreibzugriff, einen Lesezugriff und einen ausführenden Zugriff. Es umfasst darüber hinaus ein Laden von Bilddaten, ein Darstellen von Bilddaten auf einem Anzeigegerät, eine Suche in bekannten oder unbekannten Archiven, insbesondere DICOM-Archiven.
Parameter des Zugriffs können – je nach Implementierung – eingestellt bzw. konfiguriert werden. So kann beispielsweise eingestellt werden, dass der Zugriff grundsätzlich auf der schnellsten Datenquelle (basierend auf der Antwortzeit der Query) ausgeführt werden soll, dass er auf alle Datenquellen parallel unter anschließendem Transfer und/oder dass er auf alle Datenquellen parallel erfolgen soll, wobei der langsamste Transfer abgebrochen wird. Alternativ können hier noch weitere Konfigurationen eingestellt werden.
In der bevorzugten Ausführungsform handelt es sich bei den Dateneinheiten um Datenobjekte oder medizinische Daten, insbesondere Bilddaten, die auf dem DICOM-Format basieren. Für die Erfindung ist es unerheblich, welches Informationsmodell für die Repräsentation der DICOM-Daten verwendet wird (z. B. ein Composite-Object-Modell oder ein Hanging-Protocol-Modell). Wird das DICOM-Composite-Object-Modell verwendet, so umfasst eine Dateneinheit eine Studie (study), die ihrerseits mehrere Serien umfasst und wobei jeweils eine Serie mehrere Instanzen beinhalten kann. Jeder der vorstehend genannten Dateneinheiten ist eine Menge von Attributen zugeordnet, die für die jeweilige Dateneinheit unterschiedliche Ausprägungen annehmen können. Beispiele für Attribute der Dateneinheit "Studie" sind: Studiendatum, Zeitdauer der Studie, Beschreibung der Studie, Alter der betreffenden Patienten, Gewicht der betreffenden Patienten, Nennung vergleichbarer Studien etc. Als Beispiel der Ausprägung für das Attribut "Patienten-Name" und "Patienten-Alter" können beispielsweise die Werte "Maier, Hans; 48", genannt werden.
Bei dem Knoten handelt es sich um rechnergestützte Knoten, die als Workstations, einfache Clients, als Server oder als Sub-Systeme eines computer-gestützten Systems, als Datenbank, als Transferservice, als Applikation, als Netzwerkinstanz ausgebildet sein können.
Der Begriff "Anfrage" umfasst alle Arten von Aufrufen, wie Befehle, Aufträge oder dergleichen für einen Datenzugriff. Sie werden in der Regel von einer Applikation abgesetzt, die als Senderknoten in dem verteilten System ausgebildet ist. Der Sender ist dazu bestimmt, eine Anfrage abzusetzen, um einen Speicherort und/oder eine Adresse von abzufragenden bzw. zu ladenden Daten zu erhalten, die ihm in der Regel nicht bekannt sein werden, so dass er aufgrund dieser Angabe einen Zugriff ausführen kann. Dabei ist die Art des Zugriffs unerheblich. Es kann sich um einen externen Zugriff (auf einem anderen Client, auf dem Server oder generell auf anderen Knoten und/oder auf externen Datenträgern, wie CD oder Memory-Stick) oder um einen lokalen Datenzugriff (auf der lokalen Festplatte) handeln.
Das Umsetzen der erfassten Anfrage in eine Query erfolgt vorzugsweise automatisch und umfasst ein Analysieren der erfassten Anfrage, insbesondere ein Parsen der Anfrage und ein Generieren der Query. Bei der Query handelt es sich z.B. um eine XML-Query oder um eine DB-Query. Ein wesentlicher Aspekt der vorliegenden Erfindung ist darin zu sehen, dass die erfindungsgemäß generierte Query mit beliebig konfigurierbaren Attributen versehen ist. Dies stellt einen wesentlichen Unterschied zu den Verfahren nach dem Stand der Technik dar, denn erfindungsgemäß wird es möglich, die für die jeweilige Anfrage relevanten Attribute und/oder deren Ausprägungen beim Generieren der Query zu berücksichtigen. Damit kann die Query eine gezielte Suche nach den relevanten Dateneinheiten ausführen, was wiederum die Effizienz des Zugriffs und insgesamt die Performance des Systems erhöht bzw. verbessert. Bei den bisherigen Systemen aus dem Stand der Technik war die Menge der Attribute der Query nicht konfigurierbar, sondern vordefiniert. Die nach statistischen Gesetzmäßigkeiten am meisten abgesetzten Abfragen wurden in einem fest definierten Index definiert. Es war aber nicht möglich, den Index variabel zu konfigurieren. Diesen Nachteil überwindet die erfindungsgemäße Lösung. Darüber hinaus können durch das Umsetzen der Anfrage in eine Query auch Nicht-DICOM-Knoten bzw. Nicht-DICOM-Objekte bei der Suche mit einbezogen werden.
Erfindungsgemäß werden die Query und/oder das Ergebnis der Query weitergeleitet bzw. digital an andere Knoten weitergeleitet. Das Weiterleiten erfolgt auf einem vordefinierten Kanal eines Messaging-Systems. Es ist dabei nicht notwendigerweise erforderlich, dass der jeweilige Empfänger bzw. die jeweiligen Empfänger bei einem Versenden der Nachricht (Query oder Ergebnis) bereits feststehen. In diesem Fall (falls also die Empfänger nicht feststehen) und somit eine Peer-to-Peer-Verbindung nicht möglich ist, erfolgt vorzugsweise ein Streuen der Nachricht an alle oder an eine konfigurierbare Auswahl von Knoten, z. B. über ein Multicast-Verfahren. Für das Weiterleiten ist die Art des jeweiligen Protokolls unerheblich. So kann es sich um einen DICOM-Standard oder um ein anderes (z.B. auch proprietäres) Protokoll handeln. Auch können unterschiedliche Knoten, die als Sender und/oder Empfänger agieren, eingebunden sein, die jeweils mit unterschiedlichen kommunikationstechnischen Funktionalitäten ausgebildet sind.
Wie vorstehend erwähnt, umfassen die Knoten einen Sender einer Anfrage und einem Empfänger einer Query. Sie können DICOM-basiert sein oder nach einem anderen Informationsmodell ausgebildet sein, wie z. B. HL7 (HL: Health-Level, Format für nachrichten-basierte Kommunikation zwischen verschiedenen Klinik-Informationssystemen), AVI (Audio Video Interleaved – ein von der Firma Microsoft eingeführtes Containerformat für Videos) etc. oder auf anderen äquivalenten Formaten basieren. Durch die flexible Einbindung von Knoten unterschiedlicher Ausprägung und informationstechnischer "Bauart" kann ein Zugriff bzw. eine Suche in einem heterogenen System bereitgestellt werden, bei dem neue Knoten flexibel eingebunden werden können, ohne dass die Grundlagen für eine Suche in dem Knoten-Netzwerk verändert werden müssen. Dies stellt einen wesentlichen Vorteil der erfindungsgemäßen Lösung dar.
In einer bevorzugten Ausführungsform werden alle oder zumindest einzelne Schritte des vorstehend beschriebenen Verfahrens automatisch ausgeführt. Insbesondere werden das Erfassen der Anfrage und das Umsetzen der Anfrage in eine Query, das Weiterleiten der Query von einem Sender an einen Empfänger, der zur Abarbeitung der Query bestimmt ist und das Weiterleiten des Ergebnisses automatisch ausgeführt. Damit können Fehler vermieden werden, die durch fehlerhaftes Definieren einer manuell generierten Query entstehen können. Das Risiko von Fehlzugriffen kann damit deutlich minimiert werden.
In der bevorzugten Ausführungsform handelt es sich darüber hinaus um so genannte "transparente" Zugriffe, die sich dadurch definieren, dass der Ort, an dem die Daten abgelegt sind, im Vorfeld nicht explizit bekannt sein muss. Mit anderen Worten kennt der Sender der Anfrage den Empfänger der Query nicht. Üblicherweise wird hier auf das so genannte Mul ticast-Verfahren zugegriffen, bei dem die Query über den bereitgestellten Kanal an eine Vielzahl von Empfängern verteilt wird die alle den Kanal auf eingehende Nachrichten "abhören". Der Empfänger, der die Query abarbeiten kann, bestimmt sich daraufhin automatisch als Beantwortungseinheit und benachrichtigt entsprechend den Sender und gegebenenfalls alle weiteren Empfänger des Systems. Es ist möglich, dass sich auch mehrere Empfänger als "Beantworter" bestellen. In diesem Fall generiert jeder Beantworter gegebenenfalls sich teilweise überlappende Teilergebnisse, die in einem nachfolgenden Verfahrensschritt zu einem Gesamtergebnis zusammengesetzt werden und ebenfalls über den bereitgestellten Kanal an den Sender zurückgegeben werden. In einer vorteilhaften Weiterbildung ist es vorgesehen, dass die Antwortzeit erfasst wird, mit der sich ein Empfängerknoten als Beantworter bestellen kann, also die Zeit, die zwischen dem Versenden einer Anfrage und dem Versenden einer Benachrichtigungsnachricht eines Empfängerknotens verstreicht. Falls die vorstehend erwähnte Zeit ein vorkonfigurierbares Zeitintervall übersteigt, kann es vorgesehen sein, dass das Ergebnis des Empfängerknotens nicht mehr berücksichtigt wird. Damit kann die Sicherheit des Systems zusätzlich gesteigert werden. Dadurch, dass mit dem erfindungsgemäßen System auch transparente Zugriffe abgehandelt werden können, bei denen der Speicherort bzw. die Adresse der angefragten Daten nicht explizit bekannt ist, werden alle Knoten des rechnergestützten Systems in einer losen Kopplung in den Verbund eingebunden. Es entsteht somit eine variable Zuordnung zwischen Senderknoten und Empfängerknoten und umgekehrt, was einen völlig variablen Datenaustausch und insbesondere Zugriff ermöglicht.
In einer alternativen und einfacheren Weiterbildung der Erfindung kann es jedoch auch möglich sein, den Speicherort und/oder die Adresse der angeforderten Dateneinheiten im Vorfeld festzulegen. Dann wird bereits bei der Anfrage ein Hinweis auf Speicherort/Adresse spezifiziert, der dann automatisch beim Umsetzen in die Query berücksichtigt wird (in der Regel eine DICOM-Query mit exakter Angabe der jeweiligen Lo cation. Damit kann ein schnellerer und direkter Zugriff erreicht werden, was insgesamt die Performance des Systems erhöht.
Ein weiterer Vorteil der erfindungsgemäßen Lösung ist darin zu sehen, dass sie "skalierbar" ist, das heißt, dass die Anzahl der Kommunikationspartner (Knoten) variabel ist und somit auch Ergebnisse einer Suchanfrage generiert werden können, falls neue Knoten in den Verbund eingebunden werden. Das Verfahren wird insgesamt dynamisch einstellbar.
Das Verfahren basiert auf einer modulartigen bzw. komponentenartigen Architektur, die insbesondere einen so genannten lokalen Index (für lokale Zugriffe), einen Message-Query-Mechanismus bzw. Messaging Mechanismus (für remote Anfragen) und einen Transferservice als separate Komponenten umfasst. Der lokale Index dient dazu, eine Abfrage auf lokal (z. B. auf der jeweiligen Festplatte) abgelegten DICOM-Daten unter Zugriff auf deren Attribute zu ermöglichen.
Der Transferservice dient dazu, externe Medien, wie z. B. die Festplatte von externen Knoten, unter Einhaltung von Sicherheitsvorschriften abzufragen oder sonstige Zugriffe über ein Netzwerk oder auf tragbaren Datenträgern auszuführen.
Das Ergebnis der Anfrage umfasst einen so genannten Locator, der den Speicherort und/oder die Adresse der angefragten Dateneinheiten referenziert. Neben dem Locator üblicherweise auch werden auch die in der Abfrage spezifizierten Daten zurückgegeben. Falls nicht direkt der Speicherort als Ergebnis ausgegeben wird, sondern nur die Adresse, so ist es erfindungsgemäß vorgesehen, dass aufgrund der zurückgegebenen Adresse automatisch auf den eigentlichen Speicherort der Daten zurückgeschlossen werden kann, da aus der Adresse der jeweilige Pfad anhand des zugrunde liegenden Datenmodells einfach rekonstruiert werden kann.
In einer ersten Ausführungsform der Erfindung ist es vorgesehen, dass die jeweiligen (anfragbaren) DICOM-Daten und/oder ein indiziertes Verzeichnis (das ein Hinweis bzw. ein Zeiger auf die jeweiligen Daten darstellt) immer an demselben Speicherort innerhalb des Systems (z. B. unter dem gleichen Pfadnamen) abgelegt werden. Der Speicherort ist somit konstant. In einer zweiten alternativen Ausführungsform kann dieser Speicherort auch variabel sein. In diesem Fall ist das Ergebnis zusätzlich mit einem Hinweis ausgebildet (z. B. in Form eines Präfixes), der einen "Hint" auf die Adresse liefern soll.
Aufgrund des erfindungsgemäß und vorstehend beschriebenen Adressenkonzeptes kann vorteilhafterweise eine einheitliche Schnittstelle zum Laden von Daten realisiert werden, unabhängig davon, ob die Daten lokal oder remote zugreifbar sind. Je nach dem Verweis (Hint) auf die Adresse werden die Daten entweder direkt geladen oder zuvor über den Transferservice übertragen.
Durch die Erfindung ergeben sich die im Folgenden geschilderten Vorteile. Aufgrund der komponentenartigen Architektur und durch ein Messaging-System, bei dem ein anfragender Client den Empfänger der Query-Anfrage nicht explizit kennen muss, ist es möglich, sowohl neue DICOM-Knoten flexibel und unmittelbar in das System einzubinden und somit das System leicht zu erweitern. Darüber hinaus sind Zugriffe einfach durchführbar, die auch über Maschinengrenzen hinweg erfolgen sollen. Aufgrund des Transferservices wird es möglich, auch mehrere Archive (z. B. auch externe PACS-Archive) in das System zu integrieren. Darüber hinaus können auch neu eingeführte Attribute bei der Suche berücksichtigt werden, was die Performance der Anfrage wesentlich erhöht.
Weitere Aufgabenlösungen bestehen in einem System zum Zugriff auf medizinische Dateneinheiten und in einem Produkt gemäß den beiliegenden Hauptansprüchen.
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 Darstellung von wesentlichen Modulen gemäß einer bevorzugten Ausführungsform der Erfindung und
2 eine übersichtsartige Darstellung des Informationsflusses zwischen unterschiedlichen Knoten eines rechner-basierten Systems gemäß einer bevorzugten Ausführungsform der Erfindung, bei der der Informationsfluss von unterschiedlichen Zeitphasen zusammengefasst ist.
Die vorliegende Erfindung hat das Ziel in einem verteilten System gespeicherte medizinische Bilddaten zum Zwecke des Zugriffs zu lokalisieren. Erfindungsgemäß ist es vorgesehen, vor den eigentlichen Zugriff eine Suche vorzuschalten, die aufgrund gezielt konfigurierbarer Suchkriterien ein Suchergebnis in Form einer Adresse und/oder in Form eines Speicherortes generiert, so dass der eigentliche Zugriff wesentlich effizienter ausgeführt werden kann.
In der Regel handelt es sich um DICOM-Knoten, um Knoten mit einer DICOM-Schnittstelle und/oder es werden Daten aus DICOM-Archiven geladen. Die DICOM-Daten basieren auf dem DICOM-spezifischen Informationsmodell, das eine Hierarchie von Daten-Entitäten umfasst, insbesondere eine Studie (Untersuchung) bei der obersten Hierarchie-Ebene, die eine Anzahl von Bildserien umfasst, die ihrerseits wieder unterschiedliche Instanzen umfassen können. All den drei vorstehend erwähnten Entitäten sind unterschiedliche Attribute zugeordnet. Das Attribut gehört zu einer Gruppe und hat eine Identifikationsnummer (z. B. das Attribut "Patienten- Name" hat die hexadezimale Codierung "0×001000010"). Gemäß dem DICOM-Standard repräsentieren die ersten vier Ziffern dieser achtstelligen hexadezimalen Codierung jeweils die Gruppe und die zweiten vier Ziffern repräsentieren die Identifikationsnummer. Die Suche nach einer bestimmten Entität bzw. nach einem bestimmten Datenelement wird dadurch erschwert, dass die Entität nicht als zusammenhängende Struktur, sondern als eine Gruppierung von unterschiedlichen Attributen ohne bestimmte Reihenfolge repräsentiert ist. Die Attribute in DICOM-Dateien sind normalerweise in der Reihenfolge "Gruppe; Identifikationsnummer" gespeichert und sind nicht nach Entitäten geordnet. Zur eineindeutigen Identifizierung einer Identität ist in dem DICOM-Modell ein Schlüssel (Unique Identifier UID) vorgesehen, der aus 64 Ziffern besteht und jede Dateneinheit bzw. jedes Informationsobjekt eindeutig identifiziert.
Ein DICOM-Datensatz kann als Behälter bezeichnet werden und umfasst grundsätzlich zwei Kategorien von Daten: Zum einen enthält der Behälter die eigentlichen Bilddaten und zum anderen umfasst er einen Header, in dem Metainformationen abgelegt sind.
Applikationen, die auf diesem DICOM-Datensätzen arbeiten, setzen nun Anfragen ab, um auf bestimmte DICOM-Datenobjekte zugreifen zu können. Beispiele für solche Zugriffsanfragen sind: "Suche alle unterschiedlichen Patienten-Namen", "Suche alle Studien eines bestimmten Patienten/alle Serien einer Studie/alle Instanzen einer Serie", "Suche alle Seriennummern von einer bestimmten Modalität und einem bestimmten Patienten", "Suche alle Serien von Patienten mit demselben Alter wie der aktuelle Patient", etc. Mit dem erfindungsgemäßen Verfahren können solche Anfragen effizienter ausgeführt wer den, indem diese Anfrage in eine Query umgesetzt wird, die dem eigentlichen Zugriff vorgeschaltet ist. Durch das automatische Generieren einer Query ist es nicht mehr notwendig, für jede Anfrage separat alle lokalen DICOM-Dateien zu Parsen, die in der Regel ein sehr großes Datenvolumen umfassen.
In 1 ist in einer übersichtsartigen Darstellung der komponentenhafte Aufbau der erfindungsgemäßen Lösung skizziert. Eine Applikation A bzw. deren Backend setzt eine Anfrage oder eine Reihe von Anfragen ab, die einer erfindungsgemäßen Komponente, nämlich einem Datenzugriffsmanagement 10 zugeführt werden. Diese Managementschicht kann auch als Common-Data-Management-Access bezeichnet werden und setzt die Anfrage automatisch in eine Query um, die dann einen lokalen Index L zum Ausführen eines lokalen Zugriffs oder einen Transferservice T zum Ausführen eines remoten Zugriffs, z. B. über ein Netzwerk NW, beauftragt. Über das Netzwerk NW sind alle Knoten K des rechnerbasierten Verbundes mit zugeordneten Archiven und Datenbanken DB zu erreichen.
Die Anfrage wird von der Applikation A über eine vordefinierte Schnittstelle abgesetzt. Die Daten der Anfrage werden automatisch analysiert und auf die Relevanz von bestimmten Attributen und deren Ausprägung hin analysiert. Dabei wird aus der Menge der grundsätzlich möglichen Attribute ein Subset ausgewählt, das für die Beantwortung der jeweiligen Anfrage relevant ist. Diese Zwischenform wird dann an einen so genannten Query-Request-Builder weitergeleitet, der dazu bestimmt ist, die Query aufgrund der erfassten Daten automatisch zu generieren und in ein vorbestimmtes Format zu transformieren, insbesondere in ein XML-Format. Die Query wird dann an einen oder an mehrere Empfängerknoten über eine Query-Multicast-Queue gesendet.
Eingehende Querys werden von dem jeweiligen Knoten über eine Query-Multicast-Queue empfangen und durch einen Request-Executer extrahiert und gegebenenfalls in ein anderes Datenformat transformiert (z. B. in IData, einer Schlüsselwort- Datenstruktur) und lokal zur Ausführung gebracht. Über eine Command-Queue teilt ein Empfängerknoten dem Senderknoten (also dem Sender der Anfrage) mit, dass er die Query beantworten wird. Dies erfolgt, indem der jeweilige Empfängerknoten eine Bestätigungsnachricht an den Sender über das Netzwerk NW schickt. Der Empfängerknoten muss dann innerhalb eines vorkonfigurierbaren Zeitintervalls antworten, damit seine Ergebnisse von dem Sender der Anfrage auch berücksichtigt werden. Es können hier auch mehrere Empfängerknoten vorgesehen sein, die die jeweilige Query abarbeiten und Ergebnisse bzw. Teilergebnisse senden. Sobald das letzte Query-Ergebnis an den abfragenden Knoten K übermittelt worden ist, wird eine Fertig-Meldung versendet. In der Regel umfasst ein Ergebnis einer Query eine Vielzahl von Teilergebnissen, die über eine Result-Queue versendet und/oder empfangen werden. Das Ergebnis umfasst auch einen eindeutigen Identifikator, eine UID, mit einem Verweis auf den jeweiligen entfernten (remote) Rechner.
In der bevorzugten Ausführungsform umfasst die erfindungsgemäße Lösung zwei Queues: eine so genannte Befehls- oder auch Command-Queue und eine Ergebnis- oder auch Result-Queue. Alternativ ist es auch möglich, diese beiden Queues zusammen zu fassen.
Kernpunkt der Erfindung ist es, dass die automatisch generierte Query flexibel auf die jeweilige Anfrage hin formuliert werden kann, was insgesamt die Performance des Systems deutlich erhöht. Darüber hinaus ist es möglich, neue Knoten K flexibel in den Verbunden einbinden zu können.
Im Folgenden sei in Zusammenhang mit 2 das grundsätzliche Vorgehen gemäß einer bevorzugten Ausführungsform der Erfindung erläutert.
Von der Applikation A oder einem sonstigen Client wird eine Anfrage auf ein medizinisches Bilddatenobjekt bzw. auf eine solche Dateneinheit generiert und automatisch in eine Query umgesetzt, die von einem Sender bzw. einem Sendeknoten S unter Verwendung einer Multicast-Queue über das Netzwerk NW an alle beteiligten Systeme bzw. Knoten K versendet wird. In der Regel kennt der Client den Empfänger der Query nicht explizit (dies stellt einen so genannten transparenten Zugriff dar). Eine Duplizierung und Weiterleitung der generierten Query an beteiligte Empfänger E wird automatisch von einem Messaging-System übernommen. In 2 ist dieser Verfahrensschritt durch den Pfeil gekennzeichnet, der von dem mittleren Knoten hier: Sender S, nach unten auf das Netzwerk NW verweist und mit "Sende Query" gekennzeichnet ist.
Alle beteiligten Knoten K, insbesondere auch der ursprüngliche Sender S, empfangen die Query über das Netzwerk NW. In 2 sei dieser Verfahrensschritt durch den Pfeil gekennzeichnet, der von dem Netzwerk NW ausgeht und auf den linken Knoten K verweist und mit "Empfange Query" gekennzeichnet ist. Als Optimierung kann der Sender S die Query auch ohne Verwendung des Netzwerkes ausführen.
Alle Knoten K, die die Query erhalten haben und diese abarbeiten bzw. beantworten werden, senden eine Bestätigungsnachricht über das Netzwerk NW an den ursprünglichen Sender S. Nur wenn die Bestätigungsnachricht innerhalb einer bestimmten Zeit eintrifft, wird das Ergebnis des jeweiligen Knotens K berücksichtigt. In 2 ist dieser Verfahrensschritt mit dem auf der rechten Seite der Figur abgebildeten Pfeil repräsentiert, der von dem Knoten K nach unten auf das Netzwerk verweist und mit "Sende Bestätigungsnachricht" gekennzeichnet ist.
Alle beteiligten Knoten K führen die Query aus und senden das Ergebnis, je nach Anfrageart als Ganzes oder stückweise zurück. Dies erfolgt üblicherweise über eine gezielte Nachricht, die an den Sender S gerichtet ist. In 2 sind diese Verfahrensschritte im mittleren Bereich wieder durch die Pfeile dargestellt, die von dem Netzwerk NW nach oben auf den Sender S verweisen und einmal mit "Empfange Bestätigungs nachricht" und mit "Empfange (Teil-)Ergebnis" gekennzeichnet sind.
Nachdem das letzte Teilergebnis an den Senderknoten S übermittelt worden ist, wird die Kommunikation in Bezug auf die von der Applikation A abgesetzte Anfrage mit einer Komplettnachricht abgeschlossen. In diesem Zusammenhang sei nochmals darauf hingewiesen, dass in 2 die zeitliche Abfolge der jeweiligen Verfahrensschritte in ein und derselben Figur zusammengefasst dargestellt sind. Durch die erfindungsgemäße Transformation einer von einer Applikation A abgesetzten Anfrage in eine Query ist es möglich, sowohl DICOM-basierte Knoten, als auch Nicht-DICOM-Knoten abzufragen bzw. auch Nicht-DICOM-basierte Querys abzusetzen.
Neben den vorstehend erwähnten Vorteilen ist es dennoch möglich, auch die Vorteile einer Index-Verarbeitung zu nutzen.
Im Folgenden soll nochmals ein Beispiel für eine erfindungsgemäße Anfrage, eine Query und ein Ergebnis dargestellt werden.
Bei einer Anfrage an den lokalen Index L nach einer DICOM-Studie von dem Patienten "Maier" kann folgende Query generiert werden:
"SELECT 0×00081030 CONDITION 0×00100010 = 'Maier'"
Diese Query wird von dem jeweiligen Empfängerknoten E abgearbeitet und liefert zwei Ergebnisse:
Ergebnis 1: 0×00081030 = "Study 1", und
Locator = "Stu = l.3.12.19981170042000.908::Hint = Local"
Ergebnis 2: 0×00081030 = "Important Study 4711", und
Locator = "Stu = 999.4.0.30004816174165::Hint = Local".
Bei einer vorgegebenen DICOM-Struktur kann der Zugriffspfad sehr schnell und einfach aus der zurückgegebenen Adresse rekonstruiert werden. In diesem Fall ist der rekonstruierte Pfad: "C:\Storage\999.4.0.3000481617".
Für das Transformieren der Anfrage in die Query wird die erfindungsgemäße Komponente stets über die aktuelle Menge von Attributen und/oder deren Ausprägungen informiert. Diese Menge ist somit stets auf dem neuesten Stand und kann bei dem Generieren einer Query und bei der Auswahl der relevanten Attribute berücksichtigt werden.
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 Vorbereiten eines Zugriffes auf medizinische Dateneinheiten einer medizinischen Einrichtung, umfassend eine Vielzahl von rechnergestützten Knoten (K), wobei jeweils einer Dateneinheit mehrere Attribute zugeordnet sind, die jeweils unterschiedliche Ausprägungen annehmen können, mit folgenden Verfahrensschritten: – Erfassen einer Anfrage für einen Datenzugriff von einem Sender (S), – Umsetzen der erfassten Anfrage in eine Query, bei der die für die Anfrage relevanten Attribute und/oder deren Ausprägungen aus einer Menge aller Attribute konfigurierbar sind, – Weiterleiten der Query an zumindest einen Empfänger (E), – Abarbeiten der Query durch zumindest einen Empfänger (E) und Generieren eines Ergebnisses in Form einer Speicherortangabe oder einer Adresse für die angefragte Dateneinheit an einen Knoten (K), insbesondere an den Sender (S).
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Knoten (K) DICOM-basierte Knoten oder solche Knoten sind, die nach einem standardisierten Informationsmodell ausgebildet sind.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass alle oder ausgewählte Verfahrensschritte automatisch ausgeführt werden.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass eine Anzahl der Knoten (K), insbesondere der Sender (S) und/oder der Empfänger (E), dynamisch einstellbar ist.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Zugriff lokal oder remote erfolgt, wobei die Anfrage parallel an einen lokalen Index (L) für lokale Anfragen und an einen Message-Query-Mechanismus für remote Anfragen weitergeleitet wird, wobei ein remoter Zugriff über einen Transferservice (T) ausgeführt wird.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass bei der Anfrage der Speicherort und/oder die Adresse der angeforderten Dateneinheiten spezifiziert und beim Umsetzen in die Query berücksichtigt wird.
Verfahren nach zumindest einem der vorhergehenden Ansprüche 1–5, dadurch gekennzeichnet, dass der Empfänger (E) der Query dem Sender (S) der Anfrage nicht bekannt ist und variabel sein kann.
Verfahren nach zumindest einem der vorhergehenden Ansprüche 1, 2, 3, 4, 5, oder 7, dadurch gekennzeichnet, dass bei einem Generieren und/oder beim Erfassen der Anfrage für einen Datenzugriff ein Speicherort und/oder eine Adresse der jeweils angefragten Dateneinheiten nicht bekannt und/oder nicht spezifiziert sein muss.
Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass die Query unter Verwendung einer Multicast-Queue oder eines ähnlichen Messaging Mechanismus an alle oder ausgewählte Empfänger (E) weitergeleitet wird.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Ergebnis Teil-Ergebnisse umfasst, die gegebenenfalls von verschiedenen Knoten (K) generiert werden und als Ganzes oder in Teilen an einen Knoten (K), insbesondere an den Sender (S), weitergeleitet wird.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Dateneinheiten in einem DICOM-Format oder in einem anderen standardisierten Format vorliegen.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Query über einen reservierten Kanal in einem Messaging-System an alle oder ausgewählte Empfänger weitergeleitet wird, wobei alle Empfänger (E) den Kanal abhören und bei Erhalt einer Query, die sie abarbeiten können, eine entsprechende Bestätigungsnachricht an alle Knoten (K), an ausgewählte Knoten oder zumindest an den Sender (S) der Anfrage geschickt wird.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Ergebnis für die angefragten Dateneinheiten über denselben oder einen anderen Kanal gesendet wird, wobei das Ergebnis nach konfigurierbaren Kriterien, insbesondere nach zeitabhängigen Kriterien, berücksichtigt wird.
System zum Zugriff auf medizinische Dateneinheiten einer medizinischen Einrichtung, mit: – einer Vielzahl von rechnergestützten Knoten (K), wobei die Dateneinheiten verteilt auf den rechnergestützten Knoten (K) abgelegt sind und wobei jeweils einer Dateneinheit eine Menge von Attributen zugeordnet ist, die jeweils unterschiedliche Ausprägungen annehmen können, – einen Query-Generator, der dazu bestimmt ist, eine Anfrage für einen Datenzugriff von einem Sender (S) zu erfassen und in eine Query umzusetzen, wobei bei der Query die für die Anfrage relevanten Attribute und/oder deren Ausprägungen aus der Menge aller möglichen Attribute konfigurierbar sind, – zumindest einem Kommunikationskanal, über den die Query an zumindest einen Empfänger (E) gesendet wird, – einen Empfänger, der zum Abarbeiten der Query bestimmt ist und ein Ergebnis auf die Query generiert in Form einer Speicherortangabe und/oder einer Adresse für die angefragte Dateneinheit, wobei das Ergebnis über den Kommunikationskanal an einen Knoten (K), insbesondere an den Sender (S), weitergeleitet wird und – mit einer Zugriffseinheit, die – falls gewünscht – zum Ausführen des Zugriffs anhand des Ergebnisses bestimmt ist, wobei ein Zeitpunkt und Parameter des Zugriffs konfigurierbar sind.
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 13 auszuführen, wenn das Programm in dem Computer ausgeführt wird.