-
Die
Erfindung bezieht sich auf ein Verfahren zur Bereitstellung eines
hierarchisch strukturierten Datensatzes, bei dem die hierarchische
Struktur einer Anzahl von Teildatensätzen, die jeweils ein Verwaltungsdatensegment
und gegebenenfalls ein Nutzdatensegment umfassen, in den Verwaltungsdatensegmenten
des Datensatzes wiedergegeben ist, für den Zugriff einer Applikation.
-
Beispielsweise
im Umfeld der medizinischen Bildbearbeitung fallen erhebliche Datenmengen
an, die in geeigneter Form einer nachgeordneten Bearbeitung in verschiedenartigen
Applikationen, beispielsweise zu Auswertungszwecken, zur Verfügung gestellt
werden. Bei bildgebenden medizinischen Verfahren wie beispielsweise
der Computertomographie (CT) oder der Magnet-Resonanzspektroskopie (MR) werden im
Rahmen von Untersuchungen möglicherweise
mehrere tausend Bilder erzeugt, die geeignet aufbereitet für die Weiterverarbeitung
bereitgestellt werden müssen.
Bereits für
die nahe Zukunft ist zudem noch mit einer drastischen Zunahme der Datenmengen
zu rechnen. Die dabei anfallenden Bilddaten werden als Nutzdaten
für die
Applikationen zur Verfügung
gestellt.
-
Um
die dabei anfallenden Datenmengen geeignet verarbeiten zu können, ist
in der Regel eine Vorstrukturierung der Daten erforderlich. Dazu
ist gerade im Bereich der medizinischen Bilddaten der so genannte
DICOM-Standard für
das Datenformat etabliert worden, in dem die Daten in Form von hierarchisch
strukturierten Datensätzen
vorgehalten werden, wobei die hierarchische Struktur einer logischen Strukturierung
der Dateninhalte, beispielsweise im Hinblick auf Korrelationen von
Teilbildern untereinander, medizinischen Profilen oder dergleichen,
entspricht. Der hierarchischen Struktur der Dateninhalte wird dabei
durch die Aufteilung des jeweiligen Daten satzes in eine Anzahl von
Teildatensätze
Rechnung getragen, die jeweils ein Verwaltungsdatensegment und gegebenenfalls
ein Nutzdatensegment umfassen. Die logische oder hierarchische Struktur
der Nutzdaten ist dabei in den Verwaltungsdatensegmenten des Datensatzes
wiedergegeben, wobei die Verwaltungsdatensegmente in der Art von
so genannten „Headers" Verwaltungsinformationen
wie beispielsweise Kennnamen, Zuordnungsinformationen, Informationen über die
Datenmenge, logische Verknüpfungen
zu anderen Teildatensätzen
oder dergleichen für
die zugeordneten Nutzdatensegmente umfassen.
-
Bei
der Auswertung von Informationen aus derartigen Datensätzen ist üblicherweise
der gezielte Zugriff von Applikationen auf ausgewählte Nutzdaten,
im DICOM-Standard auch als Attribute bezeichnet, erforderlich. Dazu
wird ein derartiger Datensatz üblicherweise
sequentiell so lange durchsucht (so genanntes „parsing"), bis die gewünschten Nutzdaten aufgefunden
und anhand der zugeordneten Verwaltungsdatensegmente identifiziert
worden sind. Ein Zugriff auf einzelne Attribute ist dabei nicht
direkt möglich.
Alternativ können
DICOM-Parser auch derart ausgelegt sein, dass ein vollständiger Objektbaum
im Speicher angelegt wird, was aber in unerwünschter Weise erheblichen Speicherbedarf
bedingt.
-
Aktuelle
Betriebssysteme sind in der Lage, ein so genanntes Multi-Tasking
zu ermöglichen,
d. h. mehrere Programme gleichzeitig abzurufen und deren Ablauf
zu kontrollieren. In diese Kontrollfunktionen integriert sind die
Darstellung des jeweiligen Betriebszustandes und/oder der Ergebnisse
auf einem mit dem Rechner verbundenen Monitor oder einer anderen
Ausgabeeinheit, der Abruf von benötigten Daten für das jeweils
ablaufende Programm, die Speicherung von Zwischen- und/oder Endergebnissen,
die Zuweisung von benötigten
Ressourcen sowie die Bekanntgabe von eventuellen Fehlermeldungen
an vorgegebene Ziele. Des Weiteren kann die Übertragung von Daten an ein
anderes Rechnersystem, an ein Netzwerk oder an einen Server im Rahmen
der Aufgabenstellung der jeweiligen Applikation notwendig werden
oder Bestandteil der Ursprungsfunktionen sein.
-
Üblicherweise
werden in komplexen Rechnersystemen mehrere Applikationen jeweils
in einem eigenen Datenbereich und mit eigenen Daten abgearbeitet,
ohne eine Wechselbeziehung zueinander einzugehen. Jede Applikation
hat einen eigenen, aus einer Aneinanderreihung einer Vielzahl von
Schritten bestehenden Ablauf, der für einen ordnungsgemäßen Verlauf
oder eine entsprechende Meldung über eine
Störung
dieses ordnungsgemäßen Verlaufs
und die Erfüllung
der jeweils der Applikation zugeordneten Aufgabe sorgt.
-
Das
Multi-Tasking-Betriebssystem verwaltet diese Applikationen getrennt
voneinander und stellt üblicherweise
keine Querverbindung zwischen den Applikationen und/oder den in
den jeweiligen Applikationen verwendeten Daten her.
-
Diese
zur Verwendung anstehenden Daten müssen, um der Applikation in
geeigneter Form zur Verfügung
zu stehen, in vielen Fällen
derart aufbereitet werden, dass sie von der jeweiligen Applikation eingelesen
und verarbeitet werden können.
Da die zu verwendenden Daten oftmals einer fremden Quelle entstammen,
die nicht der Applikation und ihren Anforderungen an das benötigte Datenformat
unterliegt, findet diese Aufbereitung üblicherweise bedarfsgerecht
genau dann statt, wenn die Daten benötigt werden. Dazu erstellt
die Applikation aus zur Verfügung stehenden
Daten einen Datensatz in einem Datenformat, welches besonders für die Verwendung
durch die jeweilige Applikation geeignet ist. Ebenso ist es möglich, die
benötigten
Daten in einem Preprocessing-Schritt aufzubereiten und für den Zeitpunkt
der Verwendung in der Applikation bereitzuhalten, wobei der Preprocessing-Schritt
nicht notwendigerweise alle relevanten Daten erfasst.
-
Eine
derartige Aufbereitung erfordert jedoch gerade im Zusammenhang mit
der Konvertierung von Datensätzen
mit großen
Datenmengen, wie beispielsweise der genannten DICOM-Daten, Ar beitsschritte,
die durch die Applikation oder ein anderes, für die Aufbereitung besonders
vorgesehenes Programm, geleistet werden müssen. Dazu werden Ressourcen
gebunden, die ansonsten der Applikation oder dem Betriebssystem
für andere
Anwendungen zur Verfügung
stünden.
In zeitkritischen Programmen kann jede Verzögerung des Ablaufs, verursacht
beispielsweise durch die notwendige Aufbereitung von zugelieferten,
benötigten
Daten, der rechtzeitigen Erfüllung
der Aufgabe im Wege stehen.
-
Der
Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren zur Bereitstellung
eines Datensatzes der oben genannten Art anzugeben, das einen besonders
bedarfsgerechten Zugriff auf einzelne Attribute auch von wechselnden
Applikationen oder Prozessen aus auf besonders einfache Weise ermöglicht.
-
Diese
Aufgabe wird erfindungsgemäß gelöst, indem
in einem zugeordneten Speicherbereich gemeinsam mit den Nutzdatensegmenten
die Verwaltungssegmente derart hinterlegt werden, dass hierarchische
Verknüpfungen
zwischen Verwaltungsdatensegmenten durch entsprechende Adressierungsverweise
auf die Speicheradressen der jeweiligen Verwaltungsdatensegmente
repräsentiert
werden, wobei für
eine zugreifende Applikation Adressierungsinformationen für die Verwaltungsdatensegmente
bereitgestellt werden.
-
Die
Erfindung geht dabei von der Überlegung aus,
dass für
einen besonders zielgerichteten und ressourcenschonenden Zugriff
auf ausgewählte
Attribute eines derart komplexen Datensatzes eine direkte Auswahl
der jeweiligen Attribute ermöglicht
werden sollte, ohne dass hierzu ein vollständiges sequentielles Durchsuchen
und Auswerten sämtlicher Attribute
(„parsing") erforderlich sein
sollte. Dazu sollte die Ablage und Bereitstellung des Datensatzes
im Speicherbereich entsprechend der hierarchischen Struktur der
Dateninhalte erfolgen. Dies ist auf besonders einfache Weise ermöglicht,
indem die hierarchische oder logische Verknüpfung der Dateninhalte oder
Attribute beim Abspeichern aufgegriffen und über eine entsprechende Verknüpfung der
Teildatensätze über Adressierungsverweise
berücksichtigt wird.
Damit ist eine Navigation innerhalb des abgespeicherten Datensatzes
anhand von dessen hierarchischer Struktur über die entsprechenden Adressierungsverweise
ermöglicht.
Die Adressierungsstruktur, die die hierarchische Struktur der Datenverknüpfungen
wiedergibt, kann sodann als geeignete Adressierungsinformation für eine zugreifende
Applikation bereitgestellt werden, so dass diese im Sinne einer zielgerichteten
Navigation durch geeignete Weiterleitung anhand der Verwaltungsdatensegmente
auf die gewünschten
Attribute zugreifen kann.
-
Vorteilhafte
Ausgestaltungen der Erfindung sind Gegenstand der Unteransprüche.
-
Vorteilhafterweise
wird dabei ein Datensatz im DICOM-Format entsprechend seiner hierarchischen
Struktur abgespeichert.
-
Eine
besonders ressourcenschonende Betriebsweise ist dabei erreichbar,
indem in besonders vorteilhafter Ausgestaltung ein solchermaßen aufbereitet
abgespeicherter Datensatz in der Art eines Sharing-Systems auch
verschiedenen Applikationen zur Verfügung gestellt wird. Daten sollten
dabei nur einmal aufbereitet werden müssen und anschließend in
aufbereiteter Form bereitgehalten werden, um einer Mehrzahl von
Applikationen, die diese Daten benötigen, zur Verfügung zu
stehen. Bei einem vorgesehenen Zugriff einer Applikation auf einen
Datensatz wird dabei vorteilhafterweise der zur Bereithaltung des
Datensatzes vorgesehene Speicherbereich auf Verfügbarkeit des angeforderten
Datensatzes überprüft wird,
wobei für
den Fall, dass der Datensatz im vorgesehenen Speicherbereich noch
nicht verfügbar
ist, der Datensatz aus zugeordneten Rohdaten erstellt und anschließend im
vorgesehenen Speicherbereich hinterlegt wird. Damit ist sichergestellt,
dass die jeweils zuerst auf den Datensatz zugreifende Applikation
dessen Aufbereitung und geeignete Abspeicherung veranlasst, so dass
später
erneut auf diesen Datensatz zugreifende Applikationen bereits den
aufbereiteten Datensatz nutzen können.
-
Vorteilhafterweise
ist dabei vorgesehen, dass die erste Applikation, die einen Datensatz
benötigt,
ihn aus den zugeordneten Rohdaten erstellt und aufbereitet. Ein
besonders hohes Maß an
betrieblicher Effizienz ist erreichbar, indem die Datenaufbereitung
gezielt darauf ausgerichtet ist, dass ein bereits aufbereiteter
Datensatz von möglichst
allen Applikationen, die ihn benötigen,
genutzt werden kann, ohne dass eine erneute Aufbereitung durch die
jeweilige Applikation erforderlich wäre. Dazu wird vorteilhafterweise
ein Speicherbereich eingerichtet, der ausschließlich für diese Datensätze vorgesehen
ist und auf den alle Applikationen zugreifen können.
-
In
vorteilhafter Weiterbildung wird die Verfügbarkeit des Datensatzes im
Speicherbereich anhand der Verfügbarkeit
der diesem Datensatz zugeordneten Adressierungsinformationen überprüft.
-
Um
eine Belastung der Ressourcen weitestgehend zu vermeiden und durch
das Betriebssystem jeweils nur einen Speicherplatz und einen Abrufbefehl
hinterlegen zu lassen, werden die Teildatensätze vorteilhafterweise durch
applikationsübergreifende, eindeutig
zugeordnete Kennnamen gekennzeichnet.
-
Der
Speicherbereich könnte
in einem flüchtigen
Speicher, d. h. insbesondere ohne ein Backup-File, zugewiesen werden,
insbesondere wenn von den Applikationen eine Suspend-Resume-Unterstützung nicht
benötigt
wird. Vorteilhafterweise wird der Speicherbereich aber in einem
nichtflüchtigen
Speicher zugewiesen. Dadurch ist für eine Applikation auch eine
vorübergehende
Unterbrechung der Bearbeitung der Daten („Suspend" und „Resume") mit anschließender Wiederaufnahme möglich. Bei
der Wiederaufnahme der Bearbeitung ist insbesondere ein Rückgriff
auf die aufbereitete Datenstruktur möglich, ohne dass erneut aus
den Rohdaten eingelesen werden müsste.
-
Die
mit der Erfindung erzielten Vorteile bestehen insbesondere darin,
dass durch die Hinterlegung der Datensätze mit einer Adressierungsstruktur,
in der anhand von Adressierungsverweisen die hierarchische Struktur
der Dateninhalte berücksichtigt
ist, im vorgesehenen, allen Applikationen und Prozessen zugänglichen
Speicherbereich Datensätze
lediglich einmal aufbereitet werden müssen und anschließend ohne
weitere Vorbereitungsschritte von einer Mehrzahl von Applikationen
und Prozessen besonders zielgerichtet genutzt werden können. Aufwendige
Redundanzen bei der Datenaufbereitung können somit reduziert werden.
Dabei ist insbesondere auch ein direkter Zugriff auf einzelne Attribute und
damit auch eine gezielte nachträgliche
Modifikation oder Änderung
einzelner Dateninhalte, also insbesondere ein Überschreiben oder Entfernen
einzelner Attribute oder Nutzdaten, möglich.
-
Durch
die Nutzung von Adressierungsverweisen zur Abbildung der hierarchischen
Struktur ist auf besonders einfache Weise auch eine Ausweitung des
vorgesehenen Speicherbereichs und somit eine bedarfsgerechte Anpassung
des Speicherbedarfs an variierende Datenmengen, nämlich insbesondere durch
bedarfsweise Weiteradressierung an bisher nicht genutzte Speicherbereiche,
möglich.
Durch derartige Ausweitungen („Extensions") können somit
auf besonders einfache Weise auch neue Datensätze oder Teildatensätze an die
hinterlegte Struktur angefügt
werden. Insbesondere können
dadurch auch weitere Attribute eingefügt werden, ohne dass der Datenstrom
insgesamt verschoben werden müsste.
-
Die
für die
Hinterlegung vorgesehene Datenstruktur ist darüber hinaus für die Applikation
transparent. Zudem kann für
den Fall, dass die bereits hinterlegten und gespeicherten Teildatensätze für den aktuellen
Bearbeitungsbedarf durch die Applikation nicht ausreichen sollten,
eine Ergänzung
der fehlenden Teile anhand der Rohdaten, also unter Rückgriff auf
den ursprünglichen
Datensatz, vorgenommen werden („late parsing"). Dadurch ist zudem
auch eine Konfigurationsmöglichkeit
gegeben, über
die eingestellt werden kann, bis zu welcher E benentiefe der Datenstrom
beim ersten Einlesen erfasst wird („initial parsing"). Dadurch kann ausgewählt werden,
bis zu welcher Ebenentiefe der Datensatz in die Speicherstruktur überführt wird,
da weitere Ebenen oder Attribute im Rahmen des „late parsing" über die jeweilige Applikation
nachträglich
ergänzt
werden können.
-
Ein
Ausführungsbeispiel
der Erfindung wird anhand einer Zeichnung näher erläutert. Darin zeigen:
-
1 schematisch
eine Datenverarbeitungsanlage, und
-
2 ein
Diagramm für
eine Speicherstruktur.
-
Gleiche
Teile sind in beiden Figuren mit denselben Bezugszeichen versehen.
-
In
dem Rechnersystem oder der Datenverarbeitungsanlage 1 gemäß der FIG
ist vorgesehen, dass eine Anzahl von Applikationen 2 von
einem Betriebssystem 3 aufgerufen und durchgeführt wird.
Die Applikation 2 benötigt
zur Durchführung
ihrer Aufgabe einen Datensatz 5, bei dem Nutzdaten in einer hierarchischen
Struktur von Teildatensätzen
vorliegen. Im Ausführungsbeispiel
ist die Applikation 2 zur Auswertung von Daten eines bildgebenden
medizinischen Verfahrens nach dem DICOM-Standard vorgesehen.
-
Um
zu überprüfen, ob
dieser Datensatz 5 bereits in dem vorgegebenen Datenformat
in dem für die
gemeinsame Nutzung der Applikationen 2 vorgesehenen Speicherbereich 7 des
Datenspeichers 9 vorhanden ist, fragt die Applikation 2 über das
Speichermanagementmodul 11 den Inhalt des für die Applikation 2 vorgesehenen
Speicherbereichs 7 ab.
-
Ist
das Ergebnis dieser Überprüfung positiv, wird
der Datensatz 5 oder benötigte Teile davon über das
Speichermanagementmodul 11 in die Applikation 2 eingelesen
und dort verarbeitet.
-
Ist
der benötigte
Datensatz 5 noch nicht im Speicherbereich 7 hinterlegt,
wird er zunächst
im vorgegebenen Datenformat aus den im Datenspeicher 9 gespeicherten
Rohdaten 13 erzeugt und anschließend im Speicherbereich 7 des
Datenspeichers 9 hinterlegt.
-
Von
dort wird der Datensatz 5 im vorgegebenen Datenformat über das
Speichermanagementmodul 11 eingespeichert und steht somit
der abfragenden Applikation 2 sowie weiteren Abfragen von
anderen Applikationen zur Verfügung.
-
Der
Zugriff auf Speicherinhalte erfolgt dabei nach folgenden Schritten:
- 1. Die Applikation 2 wird aufgefordert,
eine gegebene DICOM-Datei
zu analysieren und die analysierten Informationen für einen
späteren
Zugriff von derselben Applikation 2 sowie von anderen Applikationen 2 oder
Tasks zu cachen oder zu speichern. Zum schnellen Analysieren werden
dabei nur die als Offsets bezeichneten Verwaltungsdatensegmente
aus dem Datenstrom, in denen neben anderen Verwaltungsinformationen
die logische oder hierarchische Struktur der Teildatensätze wiedergegeben
ist, erfasst, die nachfolgend als geeignete Einsprungstellen für einen
Lesezugriff zu dem Wert eines Attributs innerhalb des DICOM-Datenstroms
verwendet werden sollen.
- 2. Die durch das Analysieren abgerufenen Offset-Informationen
werden in ein zugeordnetes Speicher-Layout geschrieben. Ein DICOM-Datensatz,
auch als DICOM-Stream oder Data Set bezeichnet, besteht dabei aus
den so genannten Data Elements, die ihrerseits aus einem Attributbezeichner
oder Tag, aus einer Datentypkennung (VR oder Value Representation),
oder Länge
des Werts und aus dem Wert oder Attribut an sich bestehen. Über die
Tag-Offset-Werte ist dabei insbesondere vorgesehen, sich beim Abspeichern
die Zuordnung von Tag zu Offset zu merken, um beim Einlesen direkt
an den Wert oder zum Attribut zu springen, ohne erst durch den Stream
zu parsen.
- 3. Die entsprechende DICOM-Datei wird unter Verwendung der Speicherzuordnung
in den zugeordneten Speicherbereich 7 abgebildet.
- 4. Zum späteren
Einfügen
oder Zugriff auf die Attribute wird unter Verwendung des Speichermanagementmoduls 11 geprüft, ob diese
im gemeinsam genutzten Speicherbereich 7 bereits vorhanden
ist. Die Erkennung des benötigten
Datenstücks
im gemeinsam genutzten Speicherbereich 7 erfolgt unter
Verwendung des gemeinsam genutzten Namens.
- 5. Daten, die durch Einfügung
einer DICOM-Datei gecacht werden, werden mit einer Zugriffsnummer
gekennzeichnet. Wenn eine zweite Applikation 2 (Task2)
diese Daten verarbeiten soll, muss lediglich diese Zugriffsnummer
an Task2 weitergegeben werden.
- 6. Wenn das Speichermanagementmodul 11 von Task2 ebenfalls
dieselbe Layout-Version wie die Version von Task1 verwendet, kann
Task2 die analysierten Daten aus dem gemeinsam genutzten Speicherbereich 7 extrahieren
und auswerten.
- 7. Auf den entsprechenden DICOM-Datenstrom wird zwecks Attributzugriff
von der Speicherzuordnung zugegriffen.
- 8. Falls die Layout-Version von Task2 eine andere als die von
Task1 ist, so kann sie die gemeinsam genutzten Daten nicht erkennen.
Dann nimmt sie die Analyse selbst vor und nutzt die Daten gemeinsam
unter Verwendung des Layouts ihrer eigenen Version, z. B. V2.
-
Um
einen besonders flexiblen und direkten Zugriff auf gespeicherte
Nutzdaten oder Attribute zu ermöglichen,
auch ohne dass in der Art eines sequentiellen Lesens („parsing") der genannte DICOM-Datensatz
durchsucht werden muss, ist vorgese hen, die Verwaltungsdatensegmente
gemeinsam mit den Nutzdatensegmenten derart zu hinterlegen, dass
hierarchische Verknüpfungen
zwischen Verwaltungsdatensegmenten durch entsprechende Adressierungsverweise
auf die Speicheradressen der entsprechenden Verwaltungsdatensegmente
repräsentiert
werden, wobei für
eine zugreifende Applikation 2 Adressierungsinformationen
für die
Verwaltungsdatensegmente bereitgestellt werden. Die hierzu vorgesehene
Speicherstruktur für
die Daten eines DICOM-Datensatzes (Memory Layout) ist in 2 dargestellt.
-
Der
DICOM-Datensatz wird dabei als Beispiel für die Erläuterung des Konzepts des Speicher-Layouts
herangezogen. Dieser Datenstrom besteht aus mehreren kleineren Einheiten,
so genannten Attributen, und diese Einheiten stehen in einer bestimmten
Hierarchie miteinander in Beziehung. Das vorgeschlagene Speicher-Layout
ist in der Lage, diese kleineren Einheiten in integrierter Weise
abzuwickeln. Dieses Layout behält
die Offsets oder Verwaltungsdatensegmente für jeden DICOM-Datenstrom bei,
und der ursprüngliche
Strom wird vom Speicher-Manager zur Verfügung gestellt, wann immer auf
ihn zugegriffen werden soll. Die folgenden Erläuterungen einzelner Datenkomponenten
oder -elemente führen
dabei auf die für
DICOM-Datensätze
verwendeten Bezeichnungen zurück.
-
Das
Diagramm in 2 ist ein schematischer Überblick über den
Datenzugriffs-Cache-Speicher, der von Datenverwaltungs-Anwendungen verwendet
wird.
-
Dieser
Cache-Speicher wird in mehreren Gruppen verwaltet. Jede Gruppe ist
für Speicherung und
Verwaltung der Offset-Informationen
aller Instanzen auf einer Serien-Ebene zuständig. Alle möglichen
Erweiterungen und Modifikationen werden so ausgeführt, dass
sie in derselben Gruppe gespeichert werden können, solange noch genügend Speicherplatz
frei ist. Falls die vorhandene Gruppe nicht groß genug ist, um die Änderungen
aufzunehmen, wird eine zusätzliche
Gruppe verwendet, und die Verknüpfung
zum Navigieren wird erstellt.
-
Zur
wirksamen Abwicklung von Modifikationen im DICOM-Datensatz kann jede DICOM-Datei basierend
auf dem Tag-Bereich (Markierungsbereich) in mehrere Datenströme untergeteilt
werden. Jeder Teil wird basierend auf dem Tag-Bereich gekennzeichnet.
Der Tag-Bereich in Bezug auf die Kennung für den jeweiligen Stromblock
aus dem DICOM-Datenstrom wird von einem Block namens „Index@Parts@DataInstance" verwaltet.
-
Die
Struktur des DICOM-Datensatzes entspricht einer hierarchischen Beziehung.
Attribute auf Stammebene heißen
Stammebenen-Attribute. Falls ein Attribut der Stammebene vom Typ
SQ ist, erweitert es sich weiter in the SQ-Elemente der nächstniedrigeren
Ebene. Auf diese Weise können
sich SQs in einer Schleife erweitern, bis Elemente mit Feldattributen
erreicht werden. Zur leichteren Beschreibung des Speicher-Layouts
werden Stammebenen-Attribute als Ebene-0 bezeichnet, die nächstniedrigere
Ebene wird als Ebene-1 bezeichnet, und so weiter bis zur Ebene-n.
-
Das
Ergebnis des Analysealgorithmuses wird zum späteren schnellen Zugriff so
im Layout angeordnet, wie in 2 dargestellt.
-
Jede
für die
Verwaltung der Daten auf einer Serien-Ebene zuständige Gruppe wird nochmals weiter
in mehrere Chunks (Datenblöcke
mit definierter Aufgabe) unterteilt, wobei jeder Chunk für eine spezielle
Aufgabe zuständig
ist.
-
Sobald
das Ergebnis des Analysealgorithmuses des Tag-Offsets im Speicher-Layout
zur Verfügung
gestellt wird, wie in obiger Abbildung dargestellt, erfolgt die
Navigation für
den Zugriff auf die Attribute wie folgt: Die jeweilige Gruppe für die gewünschte Serie
wird basierend auf dem gemeinsam genutzten Namen auf der Serien-Ebene
erkannt. Innerhalb dieser Gruppe ist der erste Chunk namens „Index@SeriesLevel" zuständig für die Erkennung der
Chunk-Nummer für
die gewünschte
Instanz namens „Index@Parts@DataInstance". Dieser Chunk enthält die Informa tionen über die
Abbildung des Tag-Bereichs in Bezug auf den jeweiligen Teil des
DICOM-Datenstroms. Von diesem Chunk kann auch die Verknüpfung festgestellt
werden, in der die Tag-Offset-Informationen
für die
jeweilige Ebene erkannt werden können.
Da der entsprechende Teil des Datenstrom bereits vom Chunk „Parts@DataInstance" erkannt wird, ist
es möglich,
die Daten aus dem Strom zu extrahieren.
-
Weitere
Einzelheiten zu den Chunks innerhalb der Gruppe werden im Folgenden
beschrieben.
-
Index@SeriesLevel
-
Dieser
Chunk enthält
Informationen über
alle Instanzen, die von dieser Seriengruppe verwaltet werden. Dieser
Chunk enthält
auch einen Schnellsuch-Algorithmus, um den Chunk "Index@Parts@DataInstance" für die gewünschte Instanz
zu erkennen.
-
Index@Parts@DataInstance
-
Dieser
Chunk bietet Informationen über
den Tag-Bereich (basierend auf der Stammebene) in Bezug auf den
Identifikationsnamen für
die jeweiligen Teile des DICOM-Datenstroms. Die Erkennung dieser
Teile ist notwendig, um die auf dem Offset basierenden Werte zu
lesen. Er liefert auch die Verknüpfung
mit dem Chunk, in dem die Tag-Offset-Informationen auf der jeweiligen
Ebene zu finden sind. Der Chunk, auf den Bezug genommen wird, heißt „Index@Levels@DataInstance".
-
Index@Levels@DataInstance
-
Dieser
Chunk liefert die Chunk-Nummern, in denen der Tag-Offset für die jeweilige
Ebene für
die gegebene Dateninstanz zu finden ist. Falls die Ebene der Stammebene
entspricht, liefert der entsprechende Chunk direkt die Informationen
des Tag-Offsets, und dieser Chunk heißt daher „Contents@Level-0@DataInstance". Falls die Ebene
eine von Ebene-0 verschie dene Ebene ist, hat sie weitere indirekte Bezugnahmen,
je nach Tiefe einer Ebene. Falls die Ebene zum Beispiel auf Ebene-1
liegt, nimmt sie Bezug auf den Chunk namens "Index@Level-1@DataInstancel", der intern endgültig Bezug
nimmt auf einen Chunk namens „Contents@Level-1@DataInstancel", in der die Tag-Offset-Informationen
für die SQA-Elemente
auf Ebene 1 zu finden sind. Die Abfolge der Navigation nimmt immer
Bezug auf das Stammebenen-Tag. Basierend auf diesem Stammebenen-Tag
und auf „Index@Parts" kann der entsprechende
Teil des Datenstroms geholt werden, um den Wert zu lesen.
-
Contents@Level-0@DataInstance
-
Dieser
Chunk bietet die Tag-Offset-Informationen für die Stammebenen-Tags. Basierend
auf diesem Tag-Offset und dem entsprechenden Teilstrom kann der
Wert des Attributs gelesen werden.
-
Index@Level-1@DataInstance
-
Dieser
Chunk enthält
die Informationen über die
Chunks, in denen die Tag-Offset-Informationen für jedes Folgeelement innerhalb
des SQ zu finden sind. Das bedeutet, dass er Bezug nimmt auf einen Chunk "Contents@Leve1-1@DataInstance", in dem die Tag-Offset-Informationen
für die
SQ-Elemente zu finden sind.
-
Contents@Level-1@DataInstance
-
Dieser
Chunk liefert die Tag-Offset-Daten für die SQ-Elemente von Ebene-1.
-
Erweiterungen
-
Erweiterungen
werden bei jedem Chunk und auch auf der Einheiten-Ebene geboten.
Erweiterungen beim Chunk helfen bei Operationen wie Addition von
Attributen, die entweder normale Attribute oder SQ-Typen sein können. Sie
bieten ferner die Mög lichkeit,
Elemente innerhalb einer Folge hinzuzufügen/zu entfernen. Hinzufügen kann
dabei insbesondere auch bedeuten, die Länge eines Werts zu verändern (kürzer oder
länger).
Die Veränderung
zu „länger" ist dabei insbesondere
ermöglicht
durch die Vergabe eines neuen Offsets (und damit eines neuen Adressierungsverweises)
für den
längeren
Wert.
-
Hintergrund
-
Daten
sollen prozessübergreifend
gemeinsam genutzt werden. Die hier zur gemeinsamen Nutzung vorgesehenen
Daten bestehen nicht aus einem einzigen großen Block zum Schreiben und
Zugreifen, sondern enthalten statt dessen mehrere kleinere Teile,
die in einer bestimmten Hierarchie miteinander in Beziehung stehen.
Im Folgenden werden die Vorteile dieses Layouts beschrieben.
-
Schneller Zugriff auf Daten (Attribute)
einer beliebigen Position
-
Zu
dem Zeitpunkt, da Daten in dieses Layout geschrieben werden, wird
auch der hierarchische Zusammenhang für alle Daten-Unterabschnitte zur
Verfügung
gestellt. Dies ermöglicht
einen sehr schnellen Zugriff auf die Daten (Attribute) einer beliebigen
Position. Dadurch kann der Anwender auch ein unnötiges Durchlaufen aller höheren Ebenen
der Hierarchie vermeiden, um die Daten auf einer niedrigeren Ebene
zu erreichen. Er kann direkt zur gewünschten Position springen.
-
Um
zum Beispiel bei einem DICOM-Datensatz auf ein Attribut des n-ten
Elements einer Folge „SQ", die in Ebene L
erscheint, zuzugreifen, ist es nicht erforderlich, alle Daten dieses
Hierarchiepfades durchzulesen. Dieser Speicher bietet einen Mechanismus,
um effizient direkt auf das benötigte
Stück Information
zuzugreifen.
-
Effiziente Verwendung von Speicher- und
System-Ressourcen
-
Es
gibt zwei Möglichkeiten,
die Daten gemeinsam zu nutzen.
- 1. Separate
Abbildung eines jeden kleineren Teils.
- 2. Effiziente Abbildung, um eine Speicherfragmentierung zu vermeiden.
-
Mit
diesem Layout ist es möglich,
alle Daten einer Serie mit einer einzigen Sicherungsdatei zusammenzuhalten
und die internen kleineren Objekte zu verwalten. Dadurch wird im
Gegensatz zu Option 1 eine Speicherfragmentierung vermieden. Das
bedeutet auch, dass weniger Dateien und auch weniger jeweilige Speicherabbildungsobjekte
erstellt werden müssen.
Mit anderen Worten, es wird eine geringere Zahl von Dateizugriffsnummern
und Speicherabbildungsobjekten verbraucht.
-
Konfigurierbare hierarchische Ebene für die Leistung der
gemeinsamen Nutzung und des Ladens
-
Das
Layout unterstützt
die Möglichkeit,
die Datenmenge der Quelle, die gemeinsam genutzt werden soll, zu
konfigurieren. Die Konfiguration kann in Bezug auf die Tiefe in
der Hierarchie der Datenstruktur spezifiziert werden. Dieses Merkmal
ist hilfreich bei Anwendungen zur Verbesserungen der Ladeleistung.
-
Schnelles Schreiben und effizienter
Zugriff
-
Da
dieses Layout die Verwaltung kleinerer Objekte innerhalb eines größeren Blocks
einer Speicherzuordnung unterstützt,
können
sehr viele Verwaltungsdaten bei der Erstellung von Dateien und deren
Abbildung vermieden werden. Durch diese Methode wird die Anzahl
der Speicherabbildungen erheblich verringert. Das trägt zu einem
schnelleren Schreiben in den Speicher bei.
-
Das
Layout bietet ferner einen schnellen Nachschlageblock innerhalb
des Chunks „Index@SeriesLevel", dessen Hauptzweck
darin besteht, ein schnelles Nachschlagen nach kleineren Datenteilen
zu ermöglichen.
-
Speicheroperationen
-
Das
Layout unterstützt
die Möglichkeit,
die Daten als Ergebnis von Operationen wie Lesen, Schreiben, Ändern, Hinzufügen und
Löschen
zu speichern.
-
Konfigurierbare Speicher-Installationsfläche
-
Ein
auf der Grundlage dieses Layouts erstellter Speicher-Manager bietet für die Anwendungen die
Möglichkeit,
die zulässige
Speicher-Installationsfläche
zu konfigurieren. Insbesondere kann dabei eine Obergrenze für den Speicherverbrauch
vorgesehen oder konfiguriert werden. Dadurch sind Applikationen
in der Lage, den Speicherverbrauch zu kontrollieren, der für die jeweiligen
Daten benötigt
wird. Dies ist insbesondere ermöglicht
in der Variante, in der nichtflüchtiger
Speicher verwendet wird.
-
Die
Erfindung wird bevorzugt angewendet für Datenströme nach dem DICOM-Standard,
ist allerdings auch anwendbar für
andere Datenformate wie beispielsweise JPEG- oder BMP-Dateien oder andere
Datenformate, die in einem Dateiformat vorliegen, eine Nutzdatenkomponente
und Verwaltungsdaten umfassen und geeignet gruppiert werden. Die Gruppierung
kann dabei durch datensatzinhärente Eigenschaften
oder auch anhand extern vorgesehener Kriterien erfolgen.