-
Die
vorliegende Erfindung bezieht sich allgemein auf ein optimiertes
Abspeichern von Bild-Objekten in computergestützten medizinischen Bild-Informationssystemen.
Dabei bezieht sich die vorliegende Erfindung insbesondere auf ein
spezielles ökonomischeres
und leistungsstärkeres
Adressierungs- und Zugriffsverfahren beispielsweise in Radiologie-Informationssystemen
oder anderen allgemeineren Bild- und Management-Informationssystemen
(z.B. PACS, RIS usw.) in der medizinischen Bild-Datenverwaltung.
-
Ursprünglich reine
Bild-Informationssysteme (PACS, Picture Archiving and Communication
System) verschmelzen heute mit administrativ orientierten Radiologie-Informationssystemen
(RIS) zu integrierten Informationssystemen. Ein modernes Systemkonzept
stellt sich derzeit wie folgt dar (1):
Die
bilderzeugenden Systeme geben die generierten Bilder als elektrische
Signale an ein Bildkommunikationsnetz ab. Die Bilder werden in einem
Bildspeicher- und -Archivierungssystem gesammelt. In der Regel ist
ein solches an einen oder mehrere Krankenhaus-spezifische Server
gekoppelt. Von einer Vielzahl von Bildarbeitsplätzen werden zu unterschiedlichen
Zeiten von unterschiedlichen Orten gespeicherte Bilder angefordert
und zur Befundung, zur Konsultation oder für Forschung und Lehre auf Bildmonitoren
dargestellt. Dabei können
sie untereinander und mit früheren
Untersuchungen, möglicherweise
aus anderen Abteilungen oder sogar anderen Krankenhäusern oder
Arztpraxen, verglichen und nachbearbeitet werden. PACS ermöglicht es,
den anfordernden Ärzten
fertige Bilder über
das digitale Kommunikationsnetz ggf. zusätzlich über ein Wide Area Network (WAN)
zuzusenden und diese auf den jeweiligen Bildarbeitsplätzen darzustellen.
Eine Verbindung zum Management- Informationssystem
RIS ermöglicht
den Austausch von Patienten- und radiologischen Leistungsdaten.
-
Einzelne
Subsysteme eines PACS können
von unterschiedlichen Herstellern kommen. Subsysteme sind die bilderzeugenden
Systeme, das Kommunikationsnetz, das Datenhaltungssystem, die Bildarbeitsplätze, der
Data-Management-Rechner, das Archivsystem usw. Um die Kompatibilität dieser
Subsysteme zu gewährleisten,
müssen
Hersteller-unabhängige
Standards geschaffen werden für
die Geräteschnittstellen,
für die Bildheader
und Bildformate, für
die Kommunikationsprotokolle, für
die Speicherformate sowie auch für
die Bedienelemente und die Syntax der Benutzeroberfläche. Nationale
und internationale Fachgremien arbeiten an der Festlegung von Standards.
Für radiologische
Informationssysteme ist insbesondere der DICOM-Standard von besonderer Bedeutung.
-
DICOM
3.0 (Digital Imaging and Communication) entstand aus der Zusammenarbeit
des American College of Radiology (ACR) und der National Electrical
Manufactures Association (NEMA). DICOM standardisiert die Struktur
der Formate und beschreibenden Parameter für radiologische Bilder und
Kommandos zum Austausch dieser Bilder, aber auch die Beschreibung
anderer Datenobjekte, wie Bildfolgen, Untersuchungsserien und Befunde.
Auch die Beschreibung unterschiedlicher Verfahren zur Bilddatenkompression
ist in DICOM festgelegt.
-
Entsprechend
dem DICOM-Standard besteht ein Bild-Objekt (engl.: Image-Object)
im DICOM-Format aus (Bild-)Header-Anteil und (Bild-)Pixel-Anteil. Der
Header-Anteil bechreibt administrative Informationen (wie z.B. Patienten-Name,
Modalität-Name,
Krankenhaus usw.) während
der Pixel-Anteil den tatsächlichen
Pixel-basierten Bild-Inhalt des von der jeweiligen Modalität aufgenommenen
(radiologischen) Bildes enthält.
-
Nachteilig
dabei ist, dass bei Headermodifikationen an Bild- oder Patienten-relevanten Parametern derzeit
das komplette Bild-Objekt (Header- und Pixel-Anteil) neu geschrieben
werden muss. Zumeist muss auch ein neuer Identifikator in die Datenbank
eingetragen werden in der das neue (geänderte) Bild-Objekt abgelegt wird.
Der Identifikator dient derzeit zum Wiederauffinden von getrennt
gespeicherten Bild-Objekten in PACS-Archivierungssystemen.
-
Durch
das Abspeichern mehrerer Bildobjekte und Identifikatoren entsteht
derzeit ein hoher Speicherplatz- und Ressourcen-Verbrauch, wobei damit sowohl CPU-Last
als auch Netzwerk-Belastung
(I/O) gemeint ist. Bild-Objekte können derzeit bis zu 300 MByte
groß sein,
wobei es durchaus auch mehrere tausend Bilder in einer Serie geben
kann. Ein Übertragen
und Verteilen solcher Bild-Objekte auf verschiedene Bildarbeitsplätze ist
derzeit ausgesprochen netzwerkintensiv, da bereits bei geringen
Abweichungen (z. B. aufgrund von Modifizierungen) von Header-Daten
des gleichen Bild-Objektes auch dessen gesamter Pixel-Anteil übertragen werden
muss.
-
Ferner
werden für
das Befunden und das einfache Betrachten (engl. Viewing) von radiologischen
Bildern unterschiedliche Repräsentationsformen
benötigt
(beispielsweise im unkomprimierten und im komprimierten Bildformat
JPEG2000, JPEGlossless, usw.) für
die derzeit eigene Datenbankeinträge generiert werden und die
somit aus technischer Sicht redundant abgespeichert werden.
-
Die
Notwendigkeit sämtliche
Bild-Objekte (in unterschiedlichen Repräsentationsformen), auch Langzeit,
zu archivieren, fordert zusätzlichen
enormen Speicherplatz.
-
Ausgehend
von dem oben genannten Stand der Technik ist es daher Aufgabe der
vorliegenden Erfindung, ein Adressierungs- und Zugriffsverfahren für Bild-Objekte
in medizinischen Bild-Informationssystemen bereitzustellen,
welches einerseits eine ökonomischere
und andererseits eine performantere Nutzung der Rechner-gebundenen
Datenspeicher (engl. Online-storage, z. B. RAID = Redundant Array
of Independent Disks) sowie der angebundenen Datenbanken des netzwerkbasierten
Verbundes ermöglicht.
-
Diese
Aufgabe wird gemäß der Erfindung
durch die Merkmale des unabhängigen
Anspruchs gelöst. Die
abhängigen
Ansprüche
bilden den zentralen Gedanken der Erfindung in besonders vorteilhafter
Weise weiter.
-
Erfindungsgemäß wird also
ein Adressierungs- und Zugriffsverfahren vorgeschlagen für Bild-Objekte in
computergestützten
medizinischen Bild-Informationssystemen im Rahmen eines netzwerkbasierten
Verbundes unter anderem bestehend aus Modalitätenrechnern bilderzeugender
Systeme, Bildarbeitsplätzen,
Daten-Management-Rechnern bildspeichernder- und archivierender Systeme,
dadurch gekennzeichnet, dass für jedes
Bild-Objekt eine logische Archivadresse generiert wird in der alle
Bild-Objekt-Teile
insbesondere deren spezifischen Attribute kodiert sind und aus der
jeweils eine eindeutige physikalische Archivadresse eines jeden Bild-Objekt-Teiles
berechnet wird unter der ein Bild-Objekt-Teil physikalisch abgespeichert
wird.
-
Erfindungsgemäß setzt
sich die logische Archivadresse zusammen aus einer Angabe des Protokolltyps,
einer hierarchischen Pfadangabe und einem Optionsteil.
-
Vorteilhafterweise
enthält
die hierarchische Pfadangabe Attribute, die Aufschluß geben über die
Separation von Daten auf Krankenhaus, Abteilungs- oder Mandantenebene
etc. sowie über
die Größe des Bild-Objekt-Teiles,
Anzahl der Datenträger,
Anzahl der Verzeichnisse und Bild-Objekt-Identifikations-Nummer.
-
Erfindungsgemäß enthält der Optionsteil
Attribute, die Aufschluß geben über den
Bild-Objekt-Typ, die jeweilige Bild-Objekt-Segment-Anzahl, die Versionsnummer
und das Bildkompressionsformat.
-
Unter
kleinen Bild-Objekt-Teilen wird erfindungsgemäß der Kopfteil (Header), der übergeordnete
Kopfteil (Metaheader), der Indexteil (Indexpart) und unter großen Bild-Objekt-Teilen
erfindungsgemäß der jeweilige Bildteil
(Pixelpart) verstanden.
-
Dabei
kann erfindungsgemäß der Bild-Objekt-Typ
ein einzelnes Bildobjekt (SINGLE), ein einzelnes Bildobjekt im DICOM-Format
(DCM) oder eine Bildsequenz im DICOM-Format (SEQ) darstellen.
-
Der
Bild-Objekt-Teil stellt abhängig
vom Bild-Objekttyp das einzelne Bildobjekt, den Kopfteil (Header), den übergeordneten
Kopfteil (Metaheader), den Indexteil (Indexpart) oder ein entsprechendes
Bild der Bildsequenz (Pixelpart) dar.
-
Erfindungsgemäß weist
die physikalische Archivadresse neben den spezifizierenden Attributen
der logischen Archivadresse die physikalische Pfadangabe auf.
-
Vorteilhafterweise
wird bei kleinen Bild-Objekt-Teilen eine kleine Blockung des Filesystems
auf dem Datenträger
eingestellt, bei großen
Bild-Objekt-Teilen ist es vorteilhaft eine große Blockung des Filesystems auf
dem Datenträger
einzustellen.
-
Ebenso
vorteilhaft ist es, den Pixelpart in unterschiedlichen Kompressionsformaten
zu speichern und zwar hauptsächlich
in jenen, die im Rahmen des netzwerkbasierten Verbundes eine gewisse
Häufigkeit
darstellen.
-
Erfindungsgemäß wird die
logische Archivadresse und damit die Attribute in einer konventionellen kommerziellen
Datenbank mittels einem Software-Modul (Businesslogik) abgelegt
und in Form einer Datenbank-Abfrage wieder ausgelesen, während die
physikalische Archivadresse und damit die Bild-Objekte selbst mittels
einem Software-Modul (Storage-Framework) auf einem OS-Filesystem
abgespeichert und ausgelesen werden.
-
Die
Schnittstelle zwischen beiden Softwaremodulen (Storage-Framework und Businesslogik)
besteht erfindungsgemäß in Form
eines weiteren Softwaremodul (DICOM-Adapter oder FastBLOB) welches
mit den Komponenten des netzwerkbasierten Verbundes kommuniziert.
-
Vorteilhaft
ist es große
und kleine Bild-Objekt-Teile physikalisch separat auf verschiedenen
Partitionen abzuspeichern.
-
Ebenfalls
vorteilhaft ist es, die Semantik der logischen sowie der physikalischen
Archivadresse der Semantik der konventionellen URL-Technologie zu
entnehmen.
-
Ferner
wird ein System beansprucht, welches zum Durchführen eines Verfahrens nach
einem der Ansprüche
1 bis 16 geeignet ist.
-
Weitere
Vorteile, Merkmale und Eigenschaften der vorliegenden Erfindung
werden nun anhand von Ausführungsbeispielen
bezugnehmend auf die begleitenden Zeichnungen näher erläutert.
-
1 zeigt
schematisch die Grundstruktur eines PACS-Systems,
-
2 zeigt
in graphischer Darstellung die hierarchische Verzeichnisstruktur,
-
3 zeigt
schematisch die adressenbasierte Zeigerarchitektur,
-
4 zeigt
schematisch den Vorgang des Empfangens eines Bild-Objektes über das
Netzwerk und
-
5 zeigt
schematisch den Vorgang des Versendens eines Bild-Objektes über das
Netzwerk.
-
Im
Folgenden werden die Merkmale des erfindungsgemäßen Verfahrens und die Funktionen
der in den Ausführungsbeispielen
genannten Systemkomponenten näher
erläutert.
-
Wie
bereits in der Beschreibungseinleitung erwähnt, dient die vorliegende
Erfindung einer ökonomischeren
und performanteren Nutzung von Online-Speichern sowie von Archiven
und Datenbanken (Daten-Management-Systemen), beispielsweise von
PACS-Archivsystemen.
-
Bild-Objekte
im PACS liegen üblicherweise
im DICOM-Format vor und bestehen standardmäßig aus Header- und Pixel-Anteilen.
Dabei enthält
der Pixel-Anteil den (Bild-)Inhalt des von der jeweiligen Modalität aufgenommenen
Bildes. Der Header-Anteil enthält
administrative Informationen wie Patientenname, Modalitäts-Bezeichnung,
Krankenhaus usw.
-
Trotz
dieser Aufteilung eines Bildes im DICOM-Format werden in Filesystemen
von beispielsweise PACS-Archiven derzeit DICOM-Bilder als einzelne
Objekte abgelegt und ein einzelner Objekt-spezifizierender Indentifikator
in eine Datenbank eingetragen. Werden Parameter des Header- oder
Bild-Anteiles geändert (engl.
Update), so muss das komplette Bild-Objekt neu abgespeichert und
ein neuer Identifikator generiert und eingetragen werden, wodurch
sehr hoher Speicher- und Rechnerresourcen(CPU/IO)-Verbrauch entsteht.
-
Die
vorliegende Erfindung besteht nun darin, Header-Anteile und Pixel-Anteile
eines Bild-Objektes nach ökonomischen
und leistungsorientierenden Gesichtspunkten bezüglich der Rechnerbasierten
Archivierung separat zu verwalten. Dies wird durch eine effizientere
Speicherung der das Bild-Objekt, die einzelnen Bild-Objekt-Teile
bzw. die jeweiligen Bild-Objekt-Segmente
spezifizierenden Attribute in einer Datenbank erreicht. Die Speicherung
erfolgt erfindungsgemäß durch
eine sogenannte logische Archivadresse, die durch eine Softwarekomponente
(Storage-Framework) auf einem Daten-Management-Server (Archivrechner) des jeweiligen
Archivs im PACS-System generiert wird.
-
In
der Regel ist dies ein zentraler Server in einem Krankenhaus, der
auf von Bildarbeitsplätzen
oder Modalitäten
aus initiierte Erweiterungen, Veränderungen und/oder Verteilungen
unterschiedlichster Bild-Objekte bzw. Bild-Objekt-Teile in verhältnismäßig kurzen
Zeiträumen
(Sekunden, Minuten) reagiert.
-
Die
logische Archivadresse ist erfindungsgemäß so aufgebaut, dass in ihr
die wichtigsten Merkmale von Bild-Objekten bzw. Bild-Objekt-Teilen
kodiert werden können.
Das einfachste Merkmal ist die Aussage, ob das Bild-Objekt-Teil
einen Header-Anteil oder einen Pixel-Anteil darstellt. Weitere Merkmale
sind Patienten- und Krankenhaus-spezifische Verwaltungsdaten, die
Strukturierung des zugrundeliegenden Filesystems (Größe des zu
benutzenden Datenträgers
(Volume), Anzahl der Verzeichnisse (Directory) auf dem Datenträger) die Bildobjekt-Identifikationsnummer,
der Bild-Objekt-Typ, das Bild-Objekt-Segment,
die Versionsidentifikation sowie das Kompressionsformat.
-
Die
Kodierung erfolgt erfindungsgemäß in Anlehnung
an die Standard URL-Technologie (engl. Unified Resource Locator),
welche eine standardisierte logische Adressierung in anderen Netzwerken,
speziell im Internet, beschreibt. Auf diese Weise ermöglicht der
spezifische Aufbau bzw. die Zusammensetzung der logischen Archivadresse
die Abspeicherung sämtlicher
Attribute in einer Datenbank, nach denen wiederum im Rahmen ei nes
Zugriffs mittels einer Zugriffslogik abgefragt werden kann.
-
Im
Folgenden wird die Architektur einer möglichen logischen Archivadresse
(im weiteren Verlauf mit LA abgekürzt) beschrieben.
-
Eine
LA gemäß der vorliegenden
Erfindung setzt sich grundsätzlich
zusammen aus einer Spezifizierung des Protokolltyps (URL Präfix), einer
hierarchischen Pfadangabe (Hierarchical Directory Path) sowie einem
Optionsteil (OptionPart).
-
-
Die
hierarchische Pfadangabe (Hierarchical Directory Path) enthält Attribute,
die Aufschluss geben über
Krankenhaus, Abteilung, Mandant (Volume Groups), sowie über die
Größe des Bild-Objekt-Teiles
(Part Type), Strukturierung des zugrunde liegenden File-Systems
(Volume, Directory) und die Bild-Objekt-Identifikations-Nummer
(OID).
-
-
Der
Optionsteil (Option Part) enthält
Attribute, die Aufschluss geben über
den Bildobjekttyp (Object Type), Anzahl der gesamten Bild-Objekt-Segmente
(Part Count), die Versionsnummer (Version Ident) und das Bildkompressionsformat
(Compression Type).
-
-
Im
Folgenden werden zur Veranschaulichung mögliche Attributeinträge angegeben:
| /g <Volume Groups> | Hier
können
beispielsweise Spezifizierungen der beteiligten Institutionen im
Sinne der Mandantenfähigkeit |
| | separat
abgelegt werden: |
| |
g0
= Krankenhaus 1 oder Abteilung 1 |
| |
g1
= Krankenhaus 2 oder Abteilung 2 |
| |
gn
= usw. |
| /p <Part Type> | Hiermit
erfolgt die Separation der |
| | Bildobjektteile
nach deren Größe; ein |
| | kleiner
Bild-Objekt-Teil ist üblicherweise
ein Header-Anteil, ein großer
Bild-Objekt-Teil ist ein Pixel-Anteil: |
| |
p0
= kleiner Bild-Objekt-Teil |
| | z.B.
DICOM-Header |
| |
p1
= großer
Bild-Objekt-Teil |
| | z.B.
Pixel-Anteil eines einzelnen Bildes oder einer Bild-Sequenz. |
| /v <Volume> | Hiermit
erfolgt eine Spezifizierung |
| | der
Volumeneinheiten als Erweiterungseinheiten in der Datenträger-Verwaltung (z. B.
der Partition eines Festplattenspeichers), die eine Speichergröße besitzen z.B.:
v3 : 500 GByte. |
-
| /d <Directory> |
Hiermit
erfolgt eine Untergliederung |
| |
der
Volumeneinheit, |
| |
d0–d99 entspricht
z. B. einer Un |
| |
terteilung
einer Volumeneinheit in |
| |
100
Unterverzeichnissen. |
| <OID> |
Stellt
eine Objektkennung dar, die |
| |
das
zu speichernde Bild-Objekt-Teil |
| |
identifiziert,
z. B. |
| |
test1_379066948.oid. |
| <Objekt Type> |
Hiermit
wird der Objekt-Typ des Bild- |
| |
Objekt-Teiles
benannt bzw. die Einteilung unter <PartType> (p0 oder p1) näher spezifiziert.
Eingetragen wird
SINGLE im Falle eines einelementigen großen Bildobjektes
(p1), z. B. eines Videos oder einer Videosequenz,
DCM im Falle
eines DICOM-Bild-Objektes
mit nur einem Pixel-Anteil,
SEQ im Falle eines DICOM-Bild-Objektes mit mehreren
Pixel-Anteilen, z. B. mehreren Schichten einer Bildsequenz |
| <Part Count> |
Anzahl
der gesamten Bild-Objekt-Teile |
| |
eines
Bild-Objektes |
| |
1
bei SINGLE |
| |
2
bei DCM, wobei ein p0 und ein p1 |
| |
existiert |
| |
3
bei DCM, wobei zwei p0 und ein p1 |
| |
existieren |
| |
3
bei SEQ, wobei ein p0 und zwei p1 |
| |
existieren |
-
| |
≥ 4 bei SEQ,
wobei zumindest ein p0 |
| |
und
zumindest zwei p1 existieren. |
| Part <Part Nr> (nur bei physikalischer
Archivadresse) |
Hiermit
erfolgt eine Nummerierung der |
| |
einzelnen
Bild-Objekt-Teile eines |
| |
Bild-Objekts
mit |
| |
part
0 im Falle p0 und Metaheader |
| |
part
1 im Falle p0 und Header |
| |
part
2 im Falle p1 und DCM (Pixel- |
| |
Anteil) |
| |
part
3 im Falle p0 und SEQ (Index) |
| |
part
2 im Falle p1 und SEQ (erstes |
| |
Bild) |
| |
part
4 im Falle p1 und SEQ (zweites |
| |
Bild) |
| <Version Ident> (nur bei logischer
Archivadresse) |
Hiermit
wird eine fünfstellige
Nummer |
| |
als
Versionsidentifikator für
das |
| |
Bild-Objekt übergeben,
z. B. |
| |
5.0.3.0.0,
wobei die erste Ziffer die Gesamtzahl aller modifizierten Versionen
bezüglich
der Bildobjekte angibt (in diesem Beispiel 5) und die Ziffern 2
bis 5 die aktuelle Version des entsprechenden Bild-Objekt-Teiles
darstellt (in diesem Beispiel part0 = 0, part1 = 3, ...) |
| v <Version Id> (nur bei physika lischer
Archiv-adresse) |
stellt
allein den Versionsidentifikator des entsprechenden Bild-ObjektTeiles
(entsprechend der partNummer) dar |
| <Compression Type> |
hiermit
erfolgt die Bezeichnung des entsprechenden Kompressionsformates, |
-
| |
in
dem der Pixel-Anteil vorliegt, kodiert mit einer DICOMspezifischen |
| |
Transfer
Syntax (z. B. im Falle einer |
| |
Kompression
im Format JPEG2000 : CPR |
| |
=
1.2.840.10008.1.2.1) |
-
Die
logische Archivadresse ist die Adresse eines Bild-Objektes (in der
Regel bestehend aus mehreren Bild-Objekt-Teilen), die in einem speziellen Attribut
der Datenbank des Data-Management-Rechners eines PACS-Archivsystems
abgespeichert wird. Da die logische Archivadresse für jedes
Bild-Objekt stets
eindeutig ist, werden Bild-Objekte auf der logischen Ebene (Datenbank)
als ein einziges Objekt adressiert. Die erfindungsgemäße Verwendung
einer einzigen logischen Archivadresse für alle Bild-Objekt-Teile und
deren unterschiedliche Darstellungsformen verringert das Speichervolumen
in der Datenbank.
-
Nichtsdestotrotz
muss ein Bild-Objekt im Archivsystem auch physikalisch abgespeichert
werden.
-
Erfindungsgemäß erfolgt
die Abspeicherung auf physikalischer Ebene (Filesystem des Data-Management-Rechners)
aus bereits genannten Gründen
der Performance- und Volumen-Optimierung getrennt nach den jeweiligen
Bild-Objekt-Teilen (Metaheader-, Header-, Index-, Pixel-Anteil usw.)
Die physikalische Adressierung des jeweiligen Bild-Objekt-Teiles
wird jeweils aus der logischen Archivadresse abgeleitet und stellt
als sogenannte physikalische Archivadresse (PhA) ein ebenso einheitliches
Adressierungsschema dar, wie das der logischen Archivadresse (LA).
-
Im
Unterschied zur logischen Archivadresse wird in der physikalischen
Archivadresse zu Beginn anstelle des Protokolltyps (file://) der
physikalische Zugriffspfad (rootpath) angegeben, der exakt auf den
Hardware-Speicherplatz verweist, auf den das adressierte Bild-Objekt-Teil
physikalisch abgespeichert wird.
-
-
Ferner
wird an drittletzter Stelle im Filenamen die sogenannte PartNummer
(<PartNr>) angegeben, durch
die ein konkretes Bild-Objekt-Teil bzw. Bild-Objekt-Segment adressiert
wird.
-
-
Schließlich wird
an vorletzter Stelle im Filenamen nur die Versionsnummer des entsprechenden Bild-Objekt-Teiles
(Part) angegeben, da in PhA-Darstellung auf die fünfstellige
LA-Darstellung verzichtet
werden kann.
<VersionId> = V5 (fünfte Version
dieses Parts)
-
Im
Folgenden werden LA und PhA gegenübergestellt und Beispiele angegeben:
Die
allgemeine Darstellungsform einer erfindungsgemäßen logischen Archivadresse
in der Datenbank lautet:
-
Die
allgemeine Darstellungsform einer erfindungsgemäßen physikalischen Archivadresse
im File-System lautet:
Beispiel
für LA
mit Headerversionen 5
Beispiel
für PhA
mit Headerversion 5
-
2 zeigt
schematisch die hierarchische Verzeichnisstruktur entsprechend der
hierarchischen Pfadangabe in einer LA sowie in einer PhA bis zur
Ebene der Bild-Objekt-Teile. Der File-Server ist mit der höchsten Hierarchieebene,
der Volume-Group-Ebene,
verbunden. In der Part-Type-Ebene erfolgt die Aufteilung in große und kleine
Bild-Objekt-Teile, im Prinzip also die Aufteilung in Header- und
Pixel-Anteil, die in der LA und PhA durch den Anteilstyp (<Part Type> = p0 oder p1) vorgenommen
wird.
-
Diese
Separation, sowie die verfeinerte Aufteilung des Bild-Objektes durch noch
weitere Attribute in der LA und PhA, ermöglicht es, das entsprechende
Bild-Objekt in viele verschiedene Bild-Objekt-Teile zu zerlegen,
die voneinander getrennt auf dem File-System des Archivrechners
abgespeichert werden.
-
Die
getrennte Abspeicherung der einzelnen Bild-Objekt-Teile eines Bild-Objektes
hat eine Reihe von Vorteilen gegenüber der Abspeicherung/Archivierung
eines nicht separierten Bild-Objektes.
-
Es
können
mehrere verschiedene Header-Anteile einem einzigen Pixel-Anteil
zugeordnet werden. Dies bedeutet, dass bei einer Modifizierung des
Header-(oder Metaheader-)Anteils eines Bild-Objektes nur der Header
selbst neu geschrieben werden muss; der Pixel-Anteil bleibt unverändert, lediglich
der Versionsidentifikator wird in der LA bzw. in der PhA angepasst.
-
Durch
die Separation ist es ferner möglich,
nur Headerupdates an Bildarbeitsplätze zu verschicken für dort bereits
geladene Bild-Objekte (Bild-Objekt-Teile). Im Gegensatz zu marktüblichen
Lösungen
werden hiermit unnötige
Speicher-Kapazitäten
und Netzwerkbelastungen vermieden.
-
Die
Separation der Bild-Objekt-Teile ermöglicht ein Anpassen der Filesystemblockgröße an das
jeweilige Bild-Objekt-Teil. Ein Filesystemblock ist die kleinste
Einheit auf einer Speichervorrichtung (engl. Storage-Device), die
bei einem Zugriff gelesen oder geschrieben werden kann. Bei großen Bild-Objekt-Teilen (z. B. Pixel-Anteilen
bis zu 300 MByte) machen daher große Blockungen Sinn (z. B. 128
KB), um schnell zu lesen, da insgesamt weniger Blöcke gelesen
werden müssen.
Bei kleinen Bild-Objekt-Teilen (z. B. Header-Anteilen mit 100 Byte)
stellt eine kleine Blockung (1 KB) die beste Lösung dar, um Verschnitt und
damit wertvolle Speicherplatzbelegung zu vermeiden. Verschnitt entsteht
dadurch, dass bei einer großen
Blockung und kleinen Objekten nur ein geringer Teil eines Blocks
mit dem Objekt belegt wird, der als Verschnitt bezeichnete Rest
stellt unbenutzbaren Speicherplatz dar.
-
Ein
weiterer Vorteil ergibt sich durch ein separates Ablegen der Bild-Objekt-Teile
(beispielsweise des Header-Anteils und des Pixel-Anteils) auf verschiedene
Partitionen, also auf physikalisch getrennten Geräten (Harddisks),
wodurch ein zeitlich paralleler Zugriff auf die Teilobjekte ermöglicht wird.
So können
auch bei mehrfachen Anfragen gleichzeitig Header- und Pixel-Anteile
gelesen und versendet werden.
-
Veranschaulicht
wird dies zum Beispiel in 3. Über ein
Auswerten der LA werden zwei PhA generiert, die einen gleichzeitigen
parallelen Zugriff auf ein großes
Bildobjekt-Teil (Pixel-Anteil, p1) sowie auf ein kleines Bild-Objekt-Teil
(Header-Anteil p0) ermöglichen.
Ein solcher Parallel-Zugriff auf Header- und Pixel-Anteil wirkt – wie die
File-Block-Größen-Anpassung
auch – Performance-erhöhend.
-
Durch
die Möglichkeit
unabhängig
vom Pixel-Anteil nur den Header-Anteil modifizieren zu können und somit
eine Header-Versionierung
erreichen zu können,
ist die Implementierung einer UNDO-Funktion und somit eine Überprüfung der
Bild-Objekt-Historie
im Fehlerfall ebenfalls möglich.
Hierdurch wird der radiologische Arbeitsablauf verbessert und der
medizinische Service-Prozess beschleunigt.
-
Einen
weiteren Vorteil bewirkt die Abspeicherung und damit auch die Möglichkeit
einer "Sofort-Verschickung" von Bild-Objekten bzw. Bild-Objekt-Teilen
(insbesondere der Pixel-Anteile)
in unterschiedlichen Kompressionsformaten (Repräsentationsformen). Diese sind
erfindungsgemäß durch
den jeweiligen Kompressionstyp (<Compression
Type>) in der LA sowie
in der PhA kodiert und können
bei einer Datenbankabfrage entsprechend berücksichtigt werden.
-
Die
Ablage bzw. Speicherung von Bild-Objekt-Teilen in unterschiedlichem
Kompressionsformat (z. B. JPEG2000, JPEGlossless) hat zum einen
den Vorteil, dass komprimierte Bild-Objekte eine schnellere Übertragung
ermöglichen,
zum anderen dass die anfordernden Bildarbeitplätze, die untereinander jeweils
unterschiedliche Repräsentationsformen
aufgrund von Anwender-spezifischen Fall-spezifischen Gesichtspunkten favorisieren,
keine ad-hoc Generierung auf dem Archiv-Rechner erforderlich machen.
Eine ad-hoc-Generierung (auch "on-the-fly- Generierung" genannt) bewirkt
eine Konvertierung in das gewünschte
(angefragte) Format des angeforderten Bild-Objektes (Bild-Objekt-Teiles)
unmittelbar vor dem Versenden des Bild-Objektes über das Netzwerk und vermindert
die Reaktionszeit des Archives aufgrund der außerordentlich hohen CPU-Belastung
des Servers während
der von ihm durchgeführten
Kompression.
-
Eine
Vorabkompression erfordert weniger CPU-Kapazitäten wie eine ad-hoc-Generierung
und entlastet die Performance des Archivsystems. Im Falle der Vorlage
einer gewünschten
Kompression verkürzen
sich somit nicht nur die Übertragungsszeiten,
sondern auch die Reaktionszeiten der Datenbankabfrage (engl. User-request).
-
Dennoch
werden Bild-Objekte nicht in allen möglichen Kompressionsformaten
archiviert, um einen ungerechtfertigten Verwaltungsaufwand von zu
vielen verschiedenen Kompressionen zu vermeiden.
-
Um
bei Datenbankanfragen das Kompressionsformat berücksichtigen zu können, wird
erfindungsgemäß ein spezieller
Kompressions-Identifikator in die LA sowie in die PhA aufgenommen.
Auf diese Weise können
Bild-Objekt- (insbesondere Pixel-)Daten in unterschiedlichen Kompressionen
und Auflösungen
aber auch unkomprimiert abgelegt werden. Die Identifizierung erfolgt über die
spezielle Transfersyntax des Kompressions-Codes. Ist keine komprimierte
Version eines Bild-Objektes im Archiv vorhanden, so ist die Angabe
eines Kompressions-Identifikators (<CPR>)
nicht notwendig.
-
Das
erfindungsgemäße Adressierungs-
und Zugriffsverfahren für
Bild-Objekte in medizinischen Bild-(Archiv-)Informationssystemen
auf Basis einer eindeutigen logischen Archivadresse sowie daraus
abgeleiteten eindeutigen physikalischen Archivadressen wird im folgenden
anhand zweier Ausführungsbeispiele (4 und 5)
veranschaulicht:
-
I. Empfangen von Bild-Objekten
einer Modalität
im Netz
-
Es
besteht die Aufgabe, ein auf einer Bildgebungs-Modalität erzeugtes
Bild-Objekt erfindungsgemäß in ein
Archiv aufzunehmen. Das Bild-Objekt liegt im DICOM-Format auf dem
Rechner der Bildgebungsmodalität
vor und wird über
eine Netzwerkverbindung (ähnlich
dem Internet) an einen Data-Management-Rechner (Archiv-Rechner) eines Archivs übertragen.
-
Die
Schnittstelle des Archiv-Rechners, über die der Archiv-Rechner mit dem Netz
kommuniziert, ist ein sogenannter DICOM-Adapter bzw. ein FAST-BLOB. Der Archiv-Rechner
besitzt ferner eine Datenbank, sowie ein OS-Filesystem zur Verwaltung
der Archivdaten auf Speichermedien. Der DICOM-Adapter kommuniziert
einerseits mit der Datenbank über
eine Businesslogik (Softwarekomponente), andererseits mit dem OS-Filesystem über ein
Storage Framework (weitere Softwarekomponente).
-
Das
DICOM-Bild-Objekt auf dem Modalitätenrechner wird vom DICOM-Adapter
des Archivrechners als DICOM-Objekt empfangen. Daraufhin fordert
der DICOM-Adapter vom Storage Framework eine erfindungsgemäße logische
Archivadresse an, die das Storage Framework auf Basis eines erfindungsgemäßen Mechanismusses/Algorithmusses
aus den DICOM-Daten des DICOM-Objektes generiert.
-
Das
Storage Framework leitet weiterhin aus der von ihm selbst generierten
logischen Archivadresse auf Basis eines weiteren erfindungsgemäßen Mechanismusses/Algorithmusses
eine Mehrzahl an physikalischen Archivadressen ab, mittels derer
das DICOM-Objekt
zergliedert und auf diese Weise partitioniert im OS-Filesystem abgespeichert
wird. Die Zergliederung erfolgt derart, dass das ursprünglich einheitliche Bild-Objekt
im DICOM-Format
weitestgehend in der Form einzelner Bild-Objekt-Teile (engl. Parts)
auf dem OS-Filesystem vorliegt und jeder Part durch eine eigene
physikalische Archivadresse lokalisiert werden kann. Parts sind
sämtliche
Header- und Pixel-Anteile in den verschiedensten Formaten, in die
ein DICOM-Bild-Objekt zerlegt und physikalisch abgespeichert werden
kann.
-
Ferner
speichert der DICOM-Adapter die logische Archivadresse über die
Businesslogik in der Datenbank. Ab diesem Zeitpunkt ist das von
der Modalität
erzeugte DICOM-Objekt im (medizinischen Informations-)System sichtbar
und kann von beliebigen Bildarbeitsplätzen aus abgefragt werden.
-
II. Abfragen eines archivierten
Bild-Objektes bzw. eines Bild-Objekt-Teiles von einem Bildarbeitsplatz
-
Es
besteht die Aufgabe, ein von einem Bildarbeitsplatz aus angefordertes,
in einem Archiv abgelegtes Bild-Objekt-Teil auszulesen und an den
Bildarbeitsplatz zu versenden. Der Anwender an dem besagten Bildarbeitsplatz
möchte
das Bild-Objekt-Teil
in einem speziellen Kompressionsformat cpr laden. Dem Anwender liegt
die OID (z. B. test1_379066948.oid) des Bild-Objektes vor.
-
Der
DICOM-Adapter des Archivs initiiert auf Basis der OID eine Suchanfrage
(engl. Query), wodurch die Businesslogik die entsprechende logische
Archivadresse ausliest und dem DICOM-Adapter übermittelt. Der DICOM-Adapter
wiederum übermittelt
diese logische Archivadresse dem Storage Framework, welches diese
auswertet und aus dem OS-Filesystem auf Basis der Auswertung (Generierung
bzw. Finden der physikalischen Archivadresse des entsprechenden
Bild-Objekt-Teiles bzw. eines Teils oder aller Bild-Objekt-Teile) das
Bild-Objekt(-Teil) im gewünschten
Kompressionsformat ausliest. Ist das Bild-Objekt(-Teil) nicht im gewünschten
Kompressionsformat vorhanden, muss eine entsprechende Kompression
ad hoc generiert werden. Eine solche Kompressions-Software (Compression-Framework)
wird üblicherweise
auf der Ebene des DICOM-Adapters angesteuert bzw. ist in diesem
enthalten.
-
Schließlich sendet
der DICOM-Adapter über
Standard-DICOM-Mechanismen
das Bild-Objekt(-Teil) an den anfordernden Bildarbeitsplatz.
-
Alternativ
lässt sich
diese Erfindung auch mit DICOMverschiedenen anderen proprietären Transportmechanismen
kombinieren.
-
Das
erfindungsgemäße Verfahren
sowie dessen Vorteile werden im folgenden kurz zusammengefasst:
Auf
der logischen Ebene (Datenbank) werden Bild-Objekte als ein einziges
Objekt adressiert (eindeutige logische Archivadresse je Bild-Objekt).
Auf der physikalischen Ebene (Filesystem) wird das Bild-Objekt in
unterschiedliche Bild-Objekt-Teile
aufgeteilt bzw. zergliedert und jeweils getrennt performance- und
volumenoptimiert abgespeichert (je eine physikalische Archivadresse
für jeden
Bild-Header-Anteil und jeden Bild-Pixel-Anteil). Eine einzige logische
Archivadresse für
alle Bild-Objekt-Teile und Darstellungsformen verringert das Speichervolumen
in der Datenbank. Das einheitliche Adressierungsschema, gegeben
durch die physikalische Archivadressierung, ermöglicht das Auffinden von Bild-Objekten
im Katastrophenfall (z. B. Verlust der Datenbank). Ist die physikalische
Archivadresse eines Bild-Header-Anteils bekannt, können auch
die anderen Bild-Objekt-Teile gefunden werden und umgekehrt. Durch
getrenntes Abspeichern der veränderlichen
Header-Anteile und
der konstanten Pixel-Anteile werden Redundanzen (im Sinne von Speicherbelegung)
vermieden.
-
Durch
eine Versionierung der Header-Anteile (Vergabe einer Versionsnummer
bei Veränderung
von Header-Anteilen) kann eine Undo-Funktion realisiert werden,
wodurch im Fehlerfall die Bild-Objekt-Historie nachvollzogen werden
kann. Eine an die Bild-Objekt-Teil-Größe angepasste Filesystem-Blockung
bewirkt einen geringeren (Speicher-)Volumenverbrauch und im Zusammenhang
mit der parallelen Zugriffsmöglichkeit auf
die einzelnen Bild-Objekt-Teile einen höheren Durchsatz. Durch das
Versenden des Bildes in einer vorkonfigurierten Auflösung (spezifisches
Kompressionsformat) wird die Netzwerkperformance erhöht und die CPU-Belastung
von Sender und Empfänger
verringert. Dazu werden Pixel-Anteile eines Bild-Objektes entweder
in verschiedenen (gebräuchlichen)
Kompressionsformaten gespeichert bzw. verwaltet oder sie werden
mit einer Kompressions-Software
vor dem Versenden erzeugt, wobei im letzteren Fall die Entlastung
der Server-CPU entfällt
(die Entscheidung zwischen beiden Fällen wird von der Server-Prozessor-Leistung
abhängig gemacht).
Beispiel für PhA mit Headerversion 5
