DE60124946T2

DE60124946T2 - Verfahren und kommunikationsmodul zur übertragung von dicom objekten durch datenelementquellen

Info

Publication number: DE60124946T2
Application number: DE60124946T
Authority: DE
Inventors: Joseph P. Birmingham WORTMANN; Gary Birmingham YORK
Original assignee: Emageon Inc
Current assignee: Emageon Inc
Priority date: 2000-09-02
Filing date: 2001-09-04
Publication date: 2007-05-31
Anticipated expiration: 2021-09-05
Also published as: ATE347225T1; AU2002238152A1; JP2008178140A; US7426567B2; WO2002021822A2; US20030149680A9; JP2004523931A; WO2002021822A3; EP1338129B1; EP1338129A2; US20020052866A1; DE60124946D1

Description

Gebiet der Erfindung
Die vorliegende Erfindung betrifft allgemein die Bildübertragung und insbesondere Verfahren und Vorrichtungen zum Streamen (Echtzeitübertragen) von DICOM-Bildern durch Datenelementquellen und -aufnehmer.
Hintergrund der Erfindung
Medizinische Bilder können mittels einer Netzprotokollnorm namens Digital Imaging and Communications in Medicine (DICOM, etwa: digitale Bildkommunikation in der Medizin) zwischen Computern übertragen werden. Das DICOM-Netzprotokoll wurde geschaffen, um die Verteilung und Betrachtung medizinischer Bilder und Objekte wie z. B. EKG-Wellenformen, Computertomographie (CT), Magnetresonanz (MR) und Ultraschall zu unterstützen.
Das DICOM-Netzprotokoll definiert ein Format, das zum Speichern, Empfangen und Übertragen digitaler Bilddaten und Objekte verwendet wird. Das DICOM-Objektformat enthält typischerweise einen Kopf und Bilddaten. Der Kopf enthält Informationen über den Namen des Patienten, die Art des medizinischen Verfahrens oder der Abtastung, Bilddimensionen usw. Eine DICOM-Bilddatei enthält z. B. einen Kopf mit Daten, die die physikalischen Abmessungen eines medizinischen Bildes beschreiben. Der Kopf kann auch Daten mit Textinformationen über eine im Bild enthaltene Abtastung enthalten. Die Größe eines Kopfes kann je nach der im Bild gespeicherten Informationsmenge variieren. Die Daten in einem Kopf können als eine oder mehrere Gruppen zusammengestellt sein. Eine Gruppe kann eine Metadateiinformationengruppe sein, die eine oder mehrere Datenelemente wie z. B. eine Gruppenlänge, eine Dateiversion und eine Transfersyntax definiert. Die Anzahl der Datenelemente hängt vom Bildtyp und den Eigenschaften des betreffenden Bildtyps ab.
Typischerweise folgen den Kopfdaten Objektdaten. Die Objektdaten können Datenelemente haben, die Eigenschaften des betreffenden Objekttyps und der mit dem betreffenden Objekttyp verbundenen Objektdaten definieren. Die Objektdaten können Informationen enthalten, die bei einer in zwei und/oder drei Dimensionen ausgeführten medizinischen Abtastung erhalten werden. Ein Magnetresonanzbild (MRI) kann z. B. DICOM-Bilddaten haben, die ein speziell die MRI-Echozeit definierendes Datenelement enthalten. Außerdem können die Bilddaten komprimiert oder verkapselt sein, um die Bilddateigröße zu verringern.
Die meisten DICOM-Datenelemente sind klein und größenmäßig durch den Datentyp begrenzt, den sie enthalten können. Ganzzahl-Datenelemente können z. B. nur einige ganze Zahlen enthalten. Diese Datenelemente sind immer relativ klein und haben wegen ihrer relativ kleinen Größe keine wesentliche oder große Auswirkung auf die Leistung und Skalierbarkeit eines Netzes. Andere Typen von DICOM-Datenelementen wie z. B. Bilddaten können vergleichsweise relativ groß sein. Zwei Typen von DICOM-Datenelementen rechtfertigen besondere Aufmerksamkeit, da sie groß sein können: Sequenzen und Bildpunktdaten. Sequenzen sind in DICOM ein Datenelementtyp, der rekursiv andere Datensets (data sets) enthalten kann. Da sie andere Datensets enthalten können, könnten sie potentiell relativ groß sein, falls sie eine sehr große Zahl kleiner Datenelemente enthalten, oder falls sie Bildpunktdaten enthalten. Bildpunktdaten sind ein Datenelementtyp, der tatsächlichen Bilddaten entspricht. Bildpunktdaten sind ein Datenelementtyp, der relativ groß und in einigen Fällen extrem groß sein kann. Bildpunktdaten sind ein Datenelementtyp, der relativ groß und in einigen Fällen extrem groß sein kann. Die meisten anderen Datenelementtypen übertragen Informationen über das Bild (Metadaten), wie z. B. den Patientennamen, Bildtyp und Bilddatum und -zeit.
DICOM kommuniziert durch Übertragen von Datensets. Ein Datenset ist ein geordnetes Set Datenelemente wie z. B. Sequenzdaten, Bildpunktdaten oder anderen Datentypen. Jedes Datenele ment stellt Informationen dar, die übertragen werden. Jedes Datenelement hat einen bestimmten Typ und kann in seiner Größe je nach dem Datenelementtyp variieren. Zur Veranschaulichung des unterschiedlichen Größenbereichs einer Bilddatei kann die Dateigröße eines DICOM-Bildes z. B. ca. 128 Kilobytes (KB) bei einem einzigen DICOM-Bild oder bis zu ca. 600 Megabytes (MB) bei einem Zeitsequenz-(time-sequence) oder Mehrrahmen-(multi-frame)DICOM-Bild betragen.
DICOM-Datensets werden mittels einer oder mehreren Transfersyntaxen übertragen. Eine Transfersyntax spezifiziert einen Typ der Codierung der Daten für das betreffende Datenset. Das DICOM-Netzprotokoll kann mindestens drei Transfersyntaxtypen unterstützen: "big endian" (Speicherung des höchstwertigen Bytes zuerst), "little endian" (Speicherung des niedrigstwertigen Bytes zuerst) implizite Wertdarstellung und "big endian" explizite Wertdarstellung.
Ein spezifisches Merkmal des DICOM-Netzprotokolls ermöglicht die Umwandlung von Daten beim Transport in eine andere Form. Dieses spezifische Merkmal der DICOM-Datenumwandlung während der Übertragung von DICOM-Bildern über ein herkömmliches DICOM-Netz bringt einen relativ großen Bedarf an Speicherressourcen in einem DICOM-Netz mit sich.
Das DICOM-Netzprotokoll besteht aus mehreren Schichten. Das DICOM-Netzprotokoll kann auch auf einem TCP/IP-Standardprotokoll aufgebaut werden. Beim Übertragen von Daten über ein Kommunikationsnetz bricht das DICOM-Protokoll ein Datenset vor dem Senden über das Netz in ein oder mehrere Datenpakete auf. Jedes Datenpaket definiert eine oder mehrere Protokolldateneinheiten (protocol data units, PDUs). Wenn eine zu Grunde liegende Protokollschicht die Daten in Datenpakete umwandelt, wie beim TCP/IP-Protokoll, erfordert das DICOM-Protokoll, dass die über das Netz übertragenen Datensets auch als Protokolldateneinheiten (PDUs) verpackt werden. Läuft das DICOM-Netzprotokoll z. B. auf den TCP/IP-Protokoll, werden dadurch die Daten effektiv doppelt paketiert. Das heißt, DICOM paketiert die Datensets als Protokolldateneinheiten (PDUs) und TCP/IP paketiert die Datensets als Datenpakete. Dieser Typ der geschichteten DICOM/TCP/IP-Protokollstruktur bringt in einem herkömmlichen DICOM-Netz einen relativ großen Bedarf an Speicherressourcen mit sich. Überdies kann die Übertragung von DICOM-Bildern durch mehrere Schichten des DICOM-Netzprotokolls ebenfalls einen relativ großen Bedarf an Speicherressourcen in einem herkömmlichen DICOM-Netz erzeugen.
Das DICOM-Protokoll folgt einer strengen Reihenfolge zur Herstellung und Aufrechterhaltung von Kommunikation. Eine von der Dienstschicht obere Ebene (Upper Level Service Layer) betriebene Zustandsmaschine des DICOM-Protokolls spezifiziert eine strenge Reihenfolge zur Herstellung und Aufrechterhaltung von Kommunikation zwischen zwei Geräten in einem DICOM-Netz. Weil das DICOM-Protokoll verbindungsorientiert ist, kann z. B. keine Übertragung von DICOM-Daten erfolgen, bis eine DICOM-Zugehörigkeit oder -Verbindung zwischen den zwei Geräten hergestellt worden ist. Das heißt, mindestens zwei auf dem DICOM-Protokoll basierende Geräte müssen miteinander kommunizieren, um eine DICOM-Zugehörigkeit oder -Verbindung herzustellen. Nachdem eine DICOM-Zugehörigkeit oder -Verbindung hergestellt worden ist, muss die Kommunikation weiterhin einer strengen Reihenfolge folgen, und dann muss die DICOM-Zugehörigkeit oder -Verbindung auf eine geordnete Weise geschlossen werden. Eine solche vom DICOM-Netzprotokoll diktierte strenge Reihenfolge kann in einem herkömmlichen DICOM-Netz einen relativ großen Bedarf an Speicherressourcen schaffen.
Jede DICOM-Zugehörigkeit oder -Verbindung kann zur Ausführung von DICOM-Datenoperationen im DICOM-Netz verwendet werden. DICOM Operationen können sequentiell oder nacheinander oder gleichzeitig ausgeführt werden. Gleichzeitige Operationen werden als asynchrone Operationen pro Zugehörigkeit in DICOM bezeichnet. Herkömmliche DICOM-Netze wickeln typischerweise mehrere gleichzeitige oder asynchrone DICOM-Daten betreffende Operationen ab und große DICOM-Dateigrößen können in einem herkömmlichen DICOM-Netz einen relativ großen Bedarf an Speicherressourcen erzeugen.
Die rasche Abwicklung relativ großer Objekte durch herkömmliche DICOM-Kommunikationsnetze verlangt, dass DICOM-Protokolloperationen auf eine effiziente hochleistungsfähige Weise ausgeführt werden. Herkömmliche DICOM-Kommunikationsnetze erfahren bei der Abwicklung relativ großer DICOM-Objektdateien einen erheblichen Geschwindigkeits- und Leistungsabfall. Da DICOM-Objekte eher relativ groß sind, kann die Übertragung von DICOM-Objekten ein Kommunikationsnetz, das nicht zur Aufnahme solcher großer Bildobjekte ausgelegt ist, schnell überfluten. Herkömmliche DICOM-Kommunikationsnetze stützen sich zur Abwicklung mehrerer und gleichzeitiger DICOM-Operationen auf Server. In Fällen, in denen eine einzige DICOM-Datei oder Speicheroperation einen großen Teil der Ressourcen eines Servers wie z. B. Speicher und Verarbeitungszeit aufbrauchen könnte, kann ein DICOM-Server bei der Abwicklung solcher großer Objekte von schlechter Skalierbarkeit und Leistung behaftet sein. Die Netz- und Server- Leistungsprobleme können sich deutlich verschärfen, wenn mehrere Clients versuchen, simultan bzw. gleichzeitig das Netz zu nutzen.
Deshalb besteht ein Bedarf an Verfahren und Vorrichtungen zur Beschränkung des Verbrauchs von Speicherressourcen während der Abwicklung von DICOM-Objekten in einem Netz.
Weiterhin besteht ein Bedarf an Verfahren und Vorrichtungen, die es einer oder mehreren Anwendungen in einem DICOM-Kommunikationsnetz gestatten, den Speicherverbrauch unabhängig von der Größe von im Netz zu übertragenden DICOM-Objekten zu beschränken.
Weiterhin besteht ein Bedarf an verbesserten Verfahren und Vorrichtungen zur Übertragung digitaler Daten zwischen zwei Geräten in einem Kommunikationsnetz.
Weiterhin besteht ein Bedarf an verbesserten Verfahren und Vorrichtungen zur Übertragung von DICOM-Objekten in einem Netz, während die Leistung einer oder mehrerer im Netz operierenden Anwendungen aufrechterhalten oder verbessert wird.
Weiterhin besteht ein Bedarf an Verfahren und Vorrichtungen zum Streamen von DICOM-Objekten in einem Netz durch eine Datenelementquelle und einen Datenelementaufnehmer.
Zusammenfassung der Erfindung
Die Erfindung ist durch ein im beigefügten Anspruch 1 angegebenes Verfahren und ein im beigefügten Anspruch 2 angegebenes Kommunikationsmodul definiert. Die Erfindung geht die obigen Probleme durch Bereitstellung von Verfahren und Vorrichtungen zum Streamen von DICOM-Objekten in einem Netz durch Datenelementquellen und Datenelementaufnehmer an. Die Verfahren und Vorrichtungen gemäß der vorliegenden Erfindung beschränken den Verbrauch von Speicherressourcen während der Abwicklung von DICOM-Objekten in einem Netz. Außerdem ermöglichen die Verfahren und Vorrichtungen gemäß der vorliegenden Erfindung einer oder mehreren Anwendungen in einem DICOM-Kommunikationsnetz, den Speicherverbrauch unabhängig von der Größe von im Netz zu übertragenden DICOM-Objekten zu beschränken. Überdies ermöglichen die Verfahren und Vorrichtungen gemäß der vorliegenden Erfindung die Übertragung digitaler Daten zwischen zwei Geräten in einem Kommunikationsnetz. Schließlich ermöglichen Verfah ren und Vorrichtungen gemäß der vorliegenden Erfindung die Übertragung von DICOM-Objekten in einem Netz, während die Leistung einer oder mehrerer im Netz operierenden Anwendungen aufrechterhalten oder verbessert wird.
Die Verfahren und Vorrichtungen gemäß der vorliegenden Erfindung gestatten die Übertragung digitaler Daten zwischen zwei Geräten in einem Kommunikationsnetz unter Verwendung einer festen Speichergröße. Die Verfahren und Vorrichtungen gemäß der vorliegenden Erfindung ermöglichen z. B. Streamen von DICOM-Objekten mit einer relativ großen Dateigröße zwischen zwei Geräten in einem DICOM-Netz, wobei nur eine beschränkte feste Speichergröße verwendet wird. Zur Abwicklung eines DICOM-Objekts oder anderer digitaler Daten oder eines Objekts mit einer relativ großen Dateigröße teilen die Verfahren und Vorrichtungen gemäß der vorliegenden Erfindung das Objekt in kleine feste Portionen Datenelemente auf. Die Verfahren und Vorrichtungen gemäß der vorliegenden Erfindung begrenzen dann die Anzahl Datenelemente, die zu einem einzigen Zeitpunkt für eine einzige Operation im Speicher gespeichert werden können. Jedes Datenelement wird dann durch eine Datenelementquelle oder einen Datenelementaufnehmer inkrementell abgewickelt, um zu vermeiden, dass für eine einzige Operation zu viel Speicher verwendet wird. Somit ermöglichen die Verfahren und Vorrichtungen gemäß der vorliegenden Erfindung einem DICOM-Kommunikationsnetz Streamen eines DICOM-Objekts oder -Bildes unter Verwendung nur einer kleinen festen Speichergröße unabhängig von der Größe des übertragenen DICOM-Objekts oder -Bildes.
Bei einem ersten beispielhaften Verfahren zur Übertragung digitaler Daten von einem ersten Gerät zu einem zweiten Gerät unter Verwendung einer festen Speichergröße definiert das Verfahren anfangs eine begrenzte Anzahl Datenwerte, die in einem Datenstrom zu speichern sind. Als Nächstes liest das Verfahren ein Set Datenelemente aus einem ersten Gerät inkrementell aus, so alle Datenelemente nacheinander gelesen werden. Anschließend wird ein Datenwert aus jedem Datenelement extrahiert. Wenn ein Datenelement größer als eine Schwellengröße ist, können die Daten in relativ kleinen Datenportionen, die eine feste Größe aufweisen, übertragen werden. Schließlich übertägt das Verfahren den Datenstromn, der eine vordefinierte begrenzte Anzahl Datenwerte enthält, an ein zweites Gerät, so dass Datenwerte zum zweiten Gerät codiert werden können.
Bei einem anderen beispielhaften Verfahren zur Übertragung digitaler Daten von einem ersten Gerät zu einem zweiten Gerät unter Verwendung einer festen Speichergröße kann die vorliegende Er findung eine Datei empfangen, die digitale Daten von einem ersten Gerät enthält. Als Nächstes erzeugt das Verfahren einen Datenstrom, der Datenwerte für die digitale Daten enthaltende Datei enthält. Auf Basis des Datenstroms erzeugt die vorliegende Erfindung eine Datenelementquelle. Das Verfahren kann dann die Datenelemente vom Datenstrom durch die Datenelementquelle nacheinander inkrementell verarbeiten. Schließlich werden die Datenelemente an einen Datenelementaufnehmer übertragen, der die Datenelemente an ein zweites Gerät codiert.
Ein Beispiel für eine Vorrichtung der vorliegenden Erfindung enthält ein Kommunikationsmodul zum Streamen digitaler Daten zwischen zwei Geräten in einem Netz unter Verwendung einer festen Speichergröße. Das Kommunikationsmodul enthält eine Datenelementquelle und eine Kommunikationsmaschine. Die Datenelementquelle ist zum Empfangen eines Sets Datenelemente von einem ersten Gerät konfiguriert. Die Datenelementquelle ist auch zum inkrementellen Verarbeiten jeweils eines einzigen Datenelements vom Set Datenelemente konfiguriert. Die Kommunikationsmaschine ist zum Extrahieren von Datenwerten aus den Datenelementen und Erzeugen eines Datenstroms von den extrahierten Datenwerten durch Übergeben dieser an den Datenelementaufnehmer, der sie zum zweiten Gerät codiert, konfiguriert. Überdies ist die Kommunikationsmaschine außerdem zum Übertragen des Datenstroms, der die extrahierten Datenwerte enthält, an ein zweites Gerät konfiguriert.
Ein anderes Beispiel für eine Vorrichtung der vorliegenden Erfindung enthält ein Kommunikationsmodul zum Streamen digitaler Daten zwischen zwei Geräten in einem Netz unter Verwendung einer festen Speichergröße. Das Kommunikationsmodul enthält einen Datenelementaufnehmer und eine Kommunikationsmaschine. Der Datenelementaufnehmer ist zum Empfangen eines Sets Datenelemente von einem ersten Gerät konfiguriert. Der Datenelementaufnehmer ist auch zum inkrementellen Schreiben jeweils eines einzigen Datenelements von dem Set Datenelemente konfiguriert. Die Kommunikationsmaschine ist zum Extrahieren von Datenwerten aus den Datenelementen und Erzeugen eines Datenstroms von den extrahierten Datenwerten konfiguriert. Überdies ist die Kommunikationsmaschine außerdem zum Übertragen des Datenstroms, der die extrahierten Datenwerte enthält, an ein zweites Gerät konfiguriert.
Wie für die Verfahren und Vorrichtungen der vorliegenden Erfindung beschrieben worden ist, können daher in relativ großen DICOM-Objekten mit beliebiger Größe enthaltene digitale Daten zwischen Anwendungen, Geräten oder Speichermedien in einem Netz übertragen werden. Die Verwendung von Datenelementquellen und Datenelementaufnehmern, um Datenelemente und Datenwerte nacheinander inkrementell zu verarbeiten, minimiert die Speichergröße, die zur Ausführung einer DICOM-Operation benötigt wird. Die Verfahren und Vorrichtungen gemäß der vorliegenden Erfindung begrenzen den Verbrauch von Speicherressourcen, während sie eine relativ kleine feste Speichergröße zur Abwicklung eines relativ großen DICOM-Objekts bereitstellen und gleichzeitig die Leistung von im DICOM-Netz operierenden Anwendungen aufrechterhalten.
Kurzbeschreibung der Zeichnungen
1 ist ein Funktionsblockdiagramm eines Systems gemäß einer beispielhaften Ausführungsform der vorliegenden Erfindung.
2 ist ein Datenflussdiagramm einer beispielhaften Ausführungsform der vorliegenden Erfindung.
3a bis c stellen ein beispielhaftes Verfahren der vorliegenden Erfindung dar.
4a bis b stellen ein zweites beispielhaftes Verfahren der vorliegenden Erfindung dar.
5 stellt ein drittes beispielhaftes Verfahren der vorliegenden Erfindung dar.
6 stellt ein viertes beispielhaftes Verfahren der vorliegenden Erfindung dar.
7 ist eine repräsentative Darstellung von in einer DICOM-Bilddatei enthaltenen Daten.
8 stellt in einer DICOM-Bilddatei enthaltene Daten dar.
Detaillierte Beschreibung von Ausführungsformen der Erfindung
Bei einem ersten beispielhaften Verfahren zur Übertragung digitaler Daten von einem ersten Gerät zu einem zweiten Gerät unter Verwendung einer festen Speichergröße definiert das Verfahren anfangs eine begrenzte Anzahl Datenwerte, die in einem Datenstrom zu speichern sind. Als Nächstes liest das Verfahren ein Set Datenelemente aus einem ersten Gerät inkrementell aus, so dass jedes Datenelement jeweils einzeln gelesen wird. Anschließend wird ein Datenwert aus jedem Datenelement extrahiert. Wenn ein Datenelement größer als eine Schwellengröße ist, können die Daten in relativ kleinen Datenportionen, die eine feste Größe aufweisen, übertragen werden. Schließlich ü berträgt das Verfahren den Datenstrom, der eine vordefinierte begrenzte Anzahl Datenwerte enthält, an ein zweites Gerät, so dass Datenwerte zum zweiten Gerät codiert werden können.
Bei einem anderen beispielhaften Verfahren zur Übertragung digitaler Daten von einem ersten Gerät zu einem zweiten Gerät unter Verwendung einer festen Speichergröße kann die vorliegende Erfindung eine Datei empfangen, die digitale Daten von einem ersten Gerät enthält. Als Nächstes erzeugt das Verfahren einen Datenstrom, der Datenwerte für die digitale Daten enthaltende Datei enthält. Auf Basis des Datenstroms erzeugt die vorliegende Erfindung eine Datenelementquelle. Das Verfahren kann dann die Datenelemente vom Datenstrom durch die Datenelementquelle nacheinander inkrementell verarbeiten. Schließlich werden die Datenelemente an einen Datenelementaufnehmer übertragen, der die Datenelemente an ein zweites Gerät codiert.
Ein Beispiel für eine Vorrichtung der vorliegenden Erfindung enthält ein Kommunikationsmodul zum Streamen digitaler Daten zwischen zwei Geräten in einem Netz unter Verwendung einer festen Speichergröße. Das Kommunikationsmodul enthält eine Datenelementquelle und eine Kommunikationsmaschine. Die Datenelementquelle ist zum Empfangen eines Sets Datenelemente von einem ersten Gerät konfiguriert. Die Datenelementquelle ist auch zum inkrementellen Verarbeiten jeweils eines einzigen Datenelements von dem Set Datenelemente konfiguriert. Die Kommunikationsmaschine ist zum Extrahieren von Datenwerten aus den Datenelementen und Erzeugen eines Datenstroms von den extrahierten Datenwerten durch Übergeben derselben an den Datenelementaufnehmer, der sie zum zweiten Gerät codiert, konfiguriert. Überdies ist die Kommunikationsmaschine ferner zum Übertragen des Datenstroms, der die extrahierten Datenwerte enthält, an ein zweites Gerät konfiguriert.
Ein anderes Beispiel für eine Vorrichtung der vorliegenden Erfindung enthält ein Kommunikationsmodul zum Streamen digitaler Daten zwischen zwei Geräten in einem Netz unter Verwendung einer festen Speichergröße. Das Kommunikationsmodul enthält einen Datenelementaufnehmer und eine Kommunikationsmaschine. Der Datenelementaufnehmer ist zum Empfangen eines Sets Datenelemente von einem ersten Gerät konfiguriert. Der Datenelementaufnehmer ist auch zum inkrementellen Schreiben jeweils eines einzigen Datenelements von dem Set Datenelemente konfiguriert.
Die Kommunikationsmaschine ist zum Extrahieren von Datenwerten aus den Datenelementen und Erzeugen eines Datenstroms von den extrahierten Datenwerten konfiguriert. Überdies ist die Kommunikationsmaschine ferner zum Übertragen des Datenstroms, der die extrahierten Datenwerte enthält, an ein zweites Gerät konfiguriert.
1 ist ein Funktionsblockdiagramm eines Systems gemäß einer beispielhaften Ausführungsform der vorliegenden Erfindung. Das System weist ein Kommunikationsmodul 100 auf. Das Kommunikationsmodul 100 ist zum Übertragen oder Streamen von Objekten zwischen einem zugehörigen Anwendungsprogramm 101 und einem anderen Anwendungsprogramm über ein Netz konfiguriert. Ferner ist das Kommunikationsmodul 100 zum Übertragen oder Streamen von DICOM-Objekten, die DICOM-Bilddateien oder ähnliche Typen digitaler Bilder enthalten, zwischen einem zugehörigen Anwendungsprogramm 101 und einem anderen Anwendungsprogramm über ein Netz konfiguriert. Das Kommunikationsmodul 100 kann z. B. zwischen einem zugehörigen Anwendungsprogramm 101 und einem Anwendungsprogramm 130 über ein Kommunikationsnetz wie z. B. ein DICOM-Netz 102 kommunizieren, um DICOM-Bilddateien oder ähnliche Typen digitaler Objekte enthaltende DICOM-Objekte zu senden oder zu empfangen.
Es ist zu beachten, dass das Kommunikationsmodul 100 in Allgemeinen zwischen einem Service Class Provider (SCP, Dienstklassenanbieter) und einem Service Class User (SCU, Dienstklassen-Nutzer) kommuniziert. Ein SCP empfängt eine Anforderung für einen durch das DICOM-Netzprotokoll definierten Dienst, wohingegen ein SCU eine Anforderung für einen durch das DICOM-Netzprotokoll definierten Dienst initialisiert. Ein zugehöriges Anwendungsprogramm 101 kann z. B. ein SCU sein, und ein Server 128a bis n, der ein Anwendungsprogramm 130 ausführt, kann ein SCP sein.
Ein zugehöriges Anwendungsprogramm 101 kann ein DICOM-Anwendungsprogramm sein wie z. B. ein medizinisches Abbildungsprogramm oder ein Anwendungsprogramm, das mittels eines DICOM-Kommunikationsprotokolls oder einer DICOM-Norm mit dem Kommunikationsmodul 100 zu kommunizieren vermag. Das zugehörige Anwendungsprogramm 101 kann auf einem oder mehreren Clients, medizinischen Abbildungsgeräten, Speichergeräten, Informationssystemen, Datenbanken, Druckern, Arbeitsstationen, Erfassungsmodulen, Modalitäten, Betrachtungssystemen, DICOM-Medien, digitalen Archiven oder anderen Gerätetypen ausführen, die mittels eines DICOM-Kommunikationsprotokolls oder einer DICOM-Norm zu arbeiten vermögen. Repräsentati ve Beispiele für DICOM-Bilddateien und in einer DICOM-Bilddatei enthaltene zugehörige Informationen sind in den 7 bis 8 dargestellt.
Das Kommunikationsmodul 100 enthält eine Kommunikationsmaschine 104, eine Datenelementquelle 106, einen Datenelementaufnehmer 108, eine Zustandsmaschine 110, einen Puffer 112 und ein Mehrschichtenprotokoll wie z. B. ein DICOM-Protokoll 114. Eine Kommunikationsmaschine 104 ist zur Abwicklung von Daten und zugehörigen Datenelementen zwischen dem zugehörigen Anwendungsprogramm 101 und dem Kommunikationsmodul 100 sowie zwischen dem Kommunikationsmodul 100 und dem DICOM-Netz 102 konfiguriert. Die Kommunikationsmaschine 104 kann auch zum Übertragen von Daten und zugehörigen Datenelementen zwischen den verschiedenen Komponenten des Kommunikationsmoduls 100 sowie zwischen den mehreren Schichten des DICOM-Protokolls 114 konfiguriert sein. Ein Kommunikationsmodul kann eine geringere oder größere Anzahl Elemente haben, die ähnliche Merkmale bereitstellen.
Die Datenelementquelle 106 ist eine konzeptionelle Quelle für Datenelemente. Eine Datenelementquelle 106 kann als ein Vorwärts-Iterator über einen konzeptionellen Set Datenelemente agieren. Eine Datenelementquelle 106 kann einem Service Class User (SCU) oder einem Service Class Provider (SCP) wie z. B. einem Client oder Server 128a bis n Datenelemente nacheinander oder als ein Block bereitstellen. Eine Datenelementquelle 106 kann z. B. Sequenzdatenelemente (SQ) abwickeln.
Eine Datenelementquelle 106 kann auch einen Bildpunktdaten-Decodierer enthalten. Ein Bildpunktdaten-Decodierer wickelt Bildpunktdaten inkrementell oder nacheinander ab. Ein Bildpunktdaten-Decodierer wickelt z. B. Bildpunktdaten-(pixel data-, PD-)Elemente ab. Da ein einziges Bildpunktdatenelement mehrere Magabytes Daten enthalten kann, ermöglicht ein Bildpunktdaten-Decodierer das Lesen der Bildpunktdaten in relativ kleinen Informationspatikeln der Daten mit fester Größe. Wenn ein Bildpunktdatenelement angetroffen wild, liest der Bildpunktdaten-Decodierer nicht das gesamte Datenelement sofort, sondern liest statt dessen die Bildpunktdaten inkrementell in einen Puffer mit fester Größe ein, wie z. B. in den mit 112 gekennzeichneten Puffer.
Eine Datenelementquelle 106 kann Streaming-Datenelemente enthalten. Ähnlich können Streaming-Datenelemente inkrementell abgewickelt werden.
Der Datenelementaufnehmer 108 ist ein konzeptioneller Speicher für Datenelemente. Ein Datenelementaufnehmer 108 kann Datenelemente nacheinander oder als ein Block nach einem Service Class User (SCU) wie z. B. einen Client oder Server 128a bis n schreiben. Ein Datenelementaufnehmer 108 kann z. B. Sequenzdatenelemente (SQ-Elemente) abwickeln.
Ein Datenelementaufnehmer 108 kann auch einen Bildpunktdaten-Codierer enthalten. Ein Bildpunktdaten-Codierer wickelt Bildpunktdaten inkrementell oder nacheinander ab. Ein Bildpunktdaten-Codierer wickelt z. B. Bildpunktdatenelemente (PD-Elemente) ab. Da ein einziges Bildpunktdatenelement mehrere Magabytes Daten enthalten kann, gestattet ein Bildpunktdaten-Codierer das Schreiben der Bildpunktdaten in relativ kleinen Informationspartikeln der Daten mit fester Größe. Wenn ein Bildpunktdatenelement angetroffen wird, schreibt der Bildpunktdaten-Codierer nicht das gesamte Datenelement sofort, sondern schreibt statt dessen die Bildpunktdaten inkrementell in einen Puffer mit fester Größe, wie z. B. in den mit 112 gekennzeichneten Puffer.
Ein Datenelementaufnehmer 108 kann Streaming-Datenelemente enthalten. Ähnlich können Streaming-Datenelemente inkrementell abgewickelt werden.
Die Zustandsmaschine 110 dient zur Initialisierung, Überwachung und Abwicklung einer Zugehörigkeit oder Verbindung zwischen einem Service Class Provider (SCP) und einem Service Class User (SCU). Der Puffer 112 ist ein einen Speicher aufweisendes Speichergerät, das so konfiguriert ist, dass es Datenelemente, Datenwerte oder andere Typen von Daten speichert. Der Puffer 112 kann auch einen oder mehrere kleinere Puffer oder ähnliche Typen von einen Speicher aufweisenden Speichergeräten zum Speichern von Datenelementen, Datenwerten oder anderen Typen von Daten enthalten.
Das DICOM-Protokoll 114 enthält mehrere Schichten einschließlich einen Transportschicht (transport layer) 116, einer Dienstschicht obere Ebene (Upper Level Service Layer) 118, einer Datendienstschicht (Data Service Layer) 120 und einer Dienstklasseschicht (Service Class Layer) 122. Die Spezifikationen, Funktionalität und eine ausführlichere Beschreibung des DICOM-Protokolls und der zugehörigen Schichten 116 bis 122 sind im Standarddokument "Digital Imaging and Communications in Medicine (DICOM)", Standard-Ausgabe 1999, insbesondere in PS 3.5-1999 und PS 3.8-1999, dargelegt.
Das Kommunikationsmodul 100 kommuniziert mit dem zugehörigen Anwendungsprogramm 101. Das Kommunikationsmodul 100 kann über ein Kommunikationsnetz wie z. B. das DICOM-Netz 102 auch mit einem anderen Anwendungsprogramm 130 kommunizieren. Typischerweise kommuniziert ein anderes Anwendungsprogramm 130 über eine Schnittstelle wie z. B. eine Bitübertragungsschicht (physical layer) 124, d. h. ETHERNET, ATM, FDDI usw., über das DICOM-Netz mit dem Kommunikationsmodul 100. Außerdem erkennt der Fachmann, dass das DICOM-Netz 102 das Transmission Control Protocol/Internet Protocol (TCP/IP) 126 nutzen kann, um die Kommunikation mit anderen Netzen, Computern, Plattformen und Anwendungen weiter zu erleichtern. So kann das Kommunikationsmodul 100 mit der Transportschicht 112 neben dem TCP/IP 126 positioniert werden, wodurch eine Schnittstelle zwischen dem DICOM-Netz 102 und dem Kommunikationsmodul 100 geschaffen wird. Dem Fachmann sind die Verfahren und Systeme bekannt, die zur Ermöglichung dieser Konfiguration erforderlich sind.
Ein DICOM-Netz 102 kann einen oder mehrere Server 128a bis n, die in einer Netzkonfiguration wie gezeigt verbunden sind, enthalten. In einigen Fällen wird ein DICOM-Netz 102 zum Betrieb in einer lokalen Netz- oder LAN-Konfiguration eingerichtet.
Ein Server 128a bis n kann Plattformen wie z. B. Clients, medizinische Abbildungsgeräte, Speichergeräte, Informationssysteme, Datenbanken, Drucker, Arbeitsstationen, Erfassungsmodule, Modalitäten, Betrachtungssysteme, DICOM-Medien, digitale Archive oder andere Gerätetypen enthalten, die mittels eines DICOM-Kommunikationsprotokolls oder einer DICOM-Norm zu arbeiten vermögen. In einem DICOM-Netz 102 kann ein Server 128a bis n ein Service Class Provider (SCP) oder ein Service Class User (SCU) sein.
Dem Fachmann sind andere Konfigurationen von Kommunikationsnetzen vertraut, die ähnlich arbeiten wie das DICOM-Netz 102.
Ein Anwendungsprogramm 130 kann zur Ausführung auf einem Server 128a bis n konfiguriert sein. Allgemein kann ein Anwendungsprogramm 130 ein DICOM-Anwendungsprogramm sein, wie z. B. ein medizinisches Abbildungsprogramm oder ein Anwendungsprogramm, das mittels eines DICOM-Kommunikationsprotokolls oder einer DICOM-Norm mit dem Kommunikationsmodul 100 zu kommunizieren vermag. Ein Anwendungsprogramm 130 kann auf anderen Platt formen wie z. B. Clients, medizinischen Abbildungsgeräten, Speichergeräten, Informationssystemen, Datenbanken, Druckern, Arbeitsstationen, Erfassungsmodulen, Modalitäten und Betrachtungssystemen ausführen, die alle jeweils mit dem DICOM-Netz 102 verbunden sein können.
Das Kommunikationsmodul 100 kann auch mit einem Medienspeichermodul 132 und einem Metadatenbankmodul 134 kommunizieren. Das Medienspeichermodul 132 ist so konfiguriert, dass es mit dem Kommunikationsmodul 100 kommuniziert und digitale Bilddaten vorübergehend oder permanent speichert. Das Medienspeichermodul 132 kann ein Speichermedium wie z. B. ein Festplattenlaufwerk, ein magneto-optisches Plattenlaufwerk, ein CD-RW-Laufwerk, ein CD-ROM-Laufwerk oder einen anderen ähnlichen Typ von Speichermedium enthalten. Es ist zu beachten, dass das Anwendungsprogramm 130 auch so konfiguriert sein kann, dass es vom Medienspeichermodul 132 aus ausgeführt wird.
Das Metadatenbankmodul 134 ist auch so konfiguriert, dass es mit dem Kommunikationsmodul 100 kommuniziert und digitale Bilddaten vorübergehend oder permanent speichert. Das Metadatenbankmodul 134 kann ein Speichermedium wie z. B. eine herkömmliche Datenbank zum Speichern digitaler Daten enthalten.
2 zeigt ein verallgemeinertes Datenflussdiagramm einer beispielhaften Ausführungsform der vorliegenden Erfindung. Diese Figur zeigt eine beispielhafte Ausführungsform des Datenflusses 200 durch mehrere Schichten des DICOM-Protokolls während der Übertragung einer Objekt- oder Bilddatei zwischen einem Netz und einer Anwendung. In diesem Beispiel ist das Netz durch die Netzebene 202 dargestellt, und die Anwendung ist durch die Anwendungsebene 204 dargestellt. Wie anhand der Elemente in den 1 und 2 ersichtlich ist, kann die Netzebene 202 ein DICOM-Netz 102 mit einem Server 128a bis n enthalten. Die Anwendungsebene 204 kann ein zugehöriges Anwendungsprogramm 101 wie z. B. ein dem Kommunikationsmodul 100 zugehöriges medizinisches Abbildungsprogramm enthalten. Alternativ kann die Anwendungsebene ein Anwendungsprogramm 130 enthalten, das auf einem anderen Server 128a bis n, d. h. einem DICOM-Protokoll-fähigen Gerät wie z. B. einem Client-Computer im DICOM-Netz 102, ausführt. Das Kommunikationsmodul 100 erleichtert die Datenkommunikation zwischen einem zugehörigen Anwendungsprogramm 101 und dem Server 128a bis n durch Schaffung einer Zugehörigkeit oder Verbindung zwischen dem zugehörigen Anwendungsprogramm 101 und dem Server 128a bis n. Dann wickelt das Kommunikationsmodul 100 DICOM-Standardnetzprotokoll-Details ab wie z. B. Bestimmen, welche Dienstobjektpaar-Klassen (Service Object Pair (SOP) classes) verwendet werden, Definieren der Rollen des SCP und SCU, Abstimmen des Typs der zur Kommunikation zwischen den Protokollschichten verwendeten Transfersyntax und Bestimmend anderer Kommunikationsparameter gemäß einem DICOM-Netzprotokoll oder ähnlichem Typ von Protokollen zur Abwicklung von Objekten oder digitalen Bildern. Es ist zu beachten, dass bei alternativen Konfigurationen andere Geräte als ein SCP oder SCU fungieren oder als ein SCP und ein SCU fungieren können.
Überdies kann das Kommunikationsmodul 100 zum Übertragen oder Streamen digitaler Daten zwischen zwei Geräten wie z. B. einen Speicher aufweisenden Speichergeräten, Festplattenlaufwerken, CD-R, CD-RW oder beliebigen anderen Kombinationen von zwei verschiedenen einen Speicher aufweisenden Speichergeräten verwendet werden. Für den Fachmann versteht es sich, dass das Kommunikationsmodul 100 auch zum Übertragen digitaler Daten zwischen anderen Konfigurationen verwendet werden kann wie z. B. zwischen "Netz zum Gerät" oder "Gerät zum Netz", wobei das Gerät einen Speicher aufweisende Speichergeräte, Festplattenlaufwerke, CR-R, CD-RW oder beliebige andere ähnliche Typen von Geräten enthalten kann.
Außerdem stimmt sich das Kommunikationsmodul 100 mit dem zugehörigen Anwendungsprogramm 101 und dem Server 128a bis n ab, um eine maximale Größe von Protokolldateneinheiten (PDU) zu definieren, die zwischen dem zugehörigen Anwendungsprogramm 101 und Server 128a bis n übertragen werden. Die maximale Größe der PDU kann von der aktuellen Größe des verfügbaren Speicherplatzes und der Gesamtleistung des Kommunikationsnetzes abhängen.
Ferner kann das Kommunikationsmodul 100 eine Abstimmung durchführen, um eine vordefinierte oder begrenzte Anzahl Präsentationsdatenwerte (presentation data values, PDVs) zu definieren, die in einen Präsentationsdatenwerteingangsstrom eingelesen werden können. Die vordefinierte oder begrenzte Anzahl Präsentationsdatenwerte (PDVs) kann von der aktuellen Größe des verfügbaren Speicherplatzes und/oder der Gesamtleistung des Kommunikationsnetzes abhängen. Alternativ kann das Kommunikationsmodul 100 eine Abstimmung durchführen, um eine vordefinierte oder begrenzte Anzahl Datenelemente zu definieren, die in einen Dateneingangsstrom eingelesen werden können. Die vordefinierte oder begrenzte Größe von Datenelementen kann von der aktuellen Größe des verfügbaren Speicherplatzes und/oder der Gesamtleistung des Kommunikationsnetzes abhängen. Je nach dem Typ des Datenelements, das durch das Kommunikationsmodul 100 abge wickelt wird, können eine oder mehrere dieser Techniken verwendet werden, um den Verbrauch von Speicherressourcen während der Übertragung des betreffenden Datenelements durch die Erfindung auf eine relativ kleine feste Speichergröße zu begrenzen. Es ist zu beachten, dass ein Präsentationsdatenwert (PDV) einen Kopf und eine Nutzlast enthält, die eine Anordnung von Bytes sein kann.
Nachdem die oben beschriebenen Zugehörigkeits- oder Verbindungs-Details durch das Kommunikationsmodul 100 abgeschlossen worden sind, fährt das Kommunikationsmodul 100 mit der Übertragung von Daten 206 von der Netzebene 202 zur Anwendungsebene 204 fort. Das heißt, das Kommunikationsmodul 100 verarbeitet vom Server 128a bis n (der in diesem Beispiel als ein SCP fungiert) empfangene Daten 206 und sendet die verarbeiteten Daten zum zugehörigen Anwendungsprogramm 101 (das in diesem Beispiel als ein SCU fungiert). Typischerweise sind Daten 206 ein DICOM-Objekt oder eine DICOM-Bilddatei, die ein oder mehrere Datenelemente enthält. Die Daten 206 werden zuerst durch den Server 128a bis n auf der Netzebene 202 abgewickelt. Der Server 128a bis n überträgt die Daten 206 durch eine standardmäßige Netz-Bitübertragungsschicht 208 wie z. B. ETHERNET, ATM, FDDI usw.
Als Nächstes werden die Daten 206 durch das TCP/IP 210 von der standardmäßigen Netz-Bitübertragungsschicht in Form von einem oder mehreren Datenpaketen 212 übertragen. Das TCP/IP 210 wandelt die Daten 206 einschließlich des DICOM-Objekts oder der DICOM-Bilddatei in ein oder mehrere Datenpakete 212 um. Der Fachmann weiß, welche Verfahren und Systeme zur Ausführung dieser Umwandlung erforderlich sind.
Das TCP/IP 210 überträgt die Datenpakete 212 mittels Sockets 216 an eine DICOM-Protokollschicht 214. Die DICOM-Protokollschicht 214 enthält mehrere Schichten einschließlich Transport 218, Dienst obere Ebene (Upper Level Service), 220, Datendienst (Data Service) 222 und Dienstklasse (Service Class) 224. Sockets 216 ist eine Anwendungsprogramm-Schnittstelle (application program interface, API), die die Kommunikation zwischen dem TCP/IP 210 und anderen Netzprotokollen wie z. B. dem DICOM-Netzprotokoll erleichtert. Der Fachmann erkennt die Verfahren und Systeme, die zur Implementierung des TCP/IP 210, der DICOM-Protokollschicht 214 und Sockets 216 erforderlich sind.
Das TCP/IP 210 überträgt die Datenpakete 212 an die erste Schicht der DICOM-Protokollschicht 214, die als die Transportschicht 218 bekannt ist. Das Kommunikationsmodul 100 empfängt die Datenpakete 212 in der Transportschicht 218 und liest inkrementell jedes der Datenpakete 212 vom TCP/IP 210 aus. Das heißt, eine zum Kommunikationsmodul 100 gehörende Kommunikationsmaschine (in 1 als 104 bezeichnet) liest nacheinander die Datenpakete 212 unter Verwendung der Transportschicht 218 aus. Sobald die Datenpakete 212 verarbeitet sind, wandelt die Kommunikationsmaschine 104 die Datenpakete 212 in Protokolldateneinheiten 226 um. Protokolldateneinheiten (PDUs) 226 können einen Kopf 228 und einen oder mehrere Präsentationsdatenwerte (PDVs) 230 enthalten.
Jede PDU 226 wird dann durch die Kommunikationsmaschine 104 von der Transportschicht 218 an die Dienstschicht obere Ebene 220 weitergegeben. Die PDU kann dann an die Datendienstschicht 222 übertragen werden.
Dann extrahiert die Kommunikationsmaschine 104 die Präsentationsdatenwerte (PDVs) 230 aus jeder von der Datendienstschicht 222 empfangenen PDU 226. Im Allgemeinen erzeugt die Kommunikationsmaschine 104 aus den PDVs 230 einen Präsentationsdatenwerteingangsstrom (Presentation Data Value Input Stream, PDVIS). Die Kommunikationsmaschine 104 bildet unter Verwendung der PDVIS eine Nachricht 234.
Wie aus 2 ersichtlich ist, überträgt die Kommunikationsmaschine 104 die Nachricht 234 an die Dienstklasseschicht 224. Bei der Dienstklasseschicht 224 extrahiert eine Datenelementquelle 236 die Datenelemente aus jeder Nachricht. Die Datenelementquelle 236 wird die neue Eingangstransfersyntax (input transfer syntax, ITS) 238, die zum Analysieren (Parsen) der Daten verwendet werden kann.
Auf der Anwendungsebene 204 extrahiert die Eingangstransfersyntax 238 Datenelemente 240 aus dem Eingangsstrom von Bytes und verwendet die Datenelemente 240, wie sie vom zugehörigen Anwendungsprogramm 101 benötigt werden. Die Eingangstransfersyntax 238 hat ein Attribut, das als Streaming-Schwelle bezeichnet wird. Wenn das extrahierte Datenelement länger ist als die Streaming-Schwelle, ist das Datenelement 240 ein Streaming-Datenelement. Das Streaming-Datenelement ist ein Stellvertreter für das tatsächliche Datenelemente 240, das immer noch in der Eingangstransfersyntax 238 vorhanden ist. Das Streaming-Datenelement gestattet mittels der Ein gangstransfersyntax 238 einen inkrementellen Zugriff auf seinen Wert. Der inkrementelle Zugriff wird durch einen Block von Daten, den das Streaming-Datenelement füllt, bereitgestellt.
Für den abwärts gerichteten Datenfluss 242 von der Anwendungsebene 204 zur Netzebene 202 hin wird zuerst eine Datenelementquelle 236 durch die Dienstklasse (Service Class) 224 bewegt. Die Datenelementquelle 236 passiert dann zum Datendienst (Data Service) 222. Beim Datendienst 222 erzeugt ein Paketierer 244 mit der Datenelementquelle 236 eine Ausgangstransfersyntax 238. Die Ausgangstransfersyntax 238 verarbeitet jedes der Datenelemente von der Datenelementquelle 236 und gibt die codierten Datenelemente an den Paketierer 244 weiter. Dann nimmt der Paketierer 244 die codierten Datenelemente und erzeugt einen Präsentationsdatenwert (PDV).
Wenn der PDV erzeugt worden ist, wird der PDV an die DICOM-Zustandsmaschine 246 zur Verarbeitung weitergegeben. Dann wird der PDV von der DICOM-Zustandsmaschine 246 an die Transportebene 218 übergeben. Die Transportebene 218 schreibt den PDV über einen Ausgangsstrom von Bytes 248, der die Netzverbindung ist, an die TCP/IP-Schicht 210 aus.
Der oben unter Bezugnahme auf 2 beschriebene beispielhafte Datenfluss benutzt nur eine begrenzte feste Speichergröße zur Verarbeitung relativ großer DICOM-Objekte. Der verwendete Speicher kann hinsichtlich des Speichernutzungsszenarios wie folgt beschrieben werden. Ein von der Netzebene an die Anwendungsebene gesendetes DICOM-Objekt kann eine Größe von ca. 600 Megabytes (MB) haben, von denen ca. 599 MB Bildpunktdatenelemente (PD-Elemente) sein können. Eine maximale Größe der Protokolldateneinheit (PDU) wird während der Zugehörigkeit oder Verbindung für eine maximale Größe von ca. 20 Kilobytes (KB) abgestimmt. Außerdem kann die Zugehörigkeit oder Verbindung die maximale Anzahl Präsentationsdatenwerte (PDVs) im Präsentationsdatenwerteingangsstrom (PDVIS) als einen vordefinierte Grenzwert, d. h. eine maximale Anzahl fünf (5) definieren. Es ist zu beachten, dass der vordefinierte Grenzwert je nach der Größe eines zum Speichern von Präsentationsdatenwerten (PDVs) verwendeten Puffers oder einen Speicher aufweisenden Speichergeräts gewählt werden kann.
Wenn der PDVIS die Anzahl PDVs auf fünf (5) begrenzt, beträgt die maximale Speichergröße, die zum Lesen des DICOM-Objekts aus dem Netz erforderlich ist, (5 × 20 KB) + 20 KB oder 120 KB. Die "+20 KB" berücksichtigen die PDUs, die darauf warten, in den PDVIS gebracht zu werden. Das Anwendungsprogramm schreibt dann das eingehende DICOM-Objekt in eine Datei, wobei die Eingangstransfersyntax (ITS) als eine Datenelementquelle an die Ausgangstransfersyntax (output transfer syntax, OTS) für die Datei weitergegeben wird. Die OTS verwendet ca. 10 KB, um die Bildpunktdatenelemente zu codieren. Alle anderen Datenelemente außer Sequenzdatenelemente (SQ-Elemente) können einzeln als Ganzes codiert werden. Da alle anderen Datenelemente normalerweise relativ kleiner als 10 KB sind, sollte die zum Decodieren der Datenelemente in die Datei verwendete maximale Speichergröße 10 KB betragen.
Daher sollte die zum Decodieren aus dem Netz verwendete und zum Codieren der Datei verwendete gesamte Speichergröße ca. 120 KB zum Decodieren und 10 KB zum Codieren oder insgesamt 130 KB betragen.
Die 3 bis 6 sind Flussdiagramme beispielhafter Ausführungsformen von Verfahren, die von der vorliegenden Erfindung genutzt werden. Die 3a bis c und die 4a bis b zeigen Netzoperationen wie z. B. Lesen aus einem Netz und schreiben in dieses. Die 5 und 6 zeigen Dateioperationen wie z. B. Lesen aus einer Datei und schreiben in diese. Die Nutzung der in den 3 bis 6 gezeigten Verfahren gestattet die Abwicklung aller möglichen DICOM-Daten-Interaktionen unter Verwendung nur einer relativ kleinen festen Speichergröße. Diese DICOM-Daten-Interaktionen beinhalten DICOM-Netz-Interaktionen wie z. B. Lesen und Schreiben von Daten aus dem Netz aus einem bzw. in ein einen Speicher aufweisendes Speichergerät, Lesen und Schreiben von Daten aus einem einen Speicher aufweisenden Speichergerät in das Netz und Lesen und Schreiben von Netz zu Netz. Es ist zu beachten, dass andere Arten von DICOM-Daten-Interaktionen, die andere Konfigurationen von einen Speicher aufweisenden Speichergeräten und einem Netz verwenden, durch die Erfindung ausgeführt werden können.
Die 3a bis c zeigen ein Verfahren 300 zum Lesen digitaler Daten aus einem Netz in eine Anwendung. Im Allgemeinen sind die digitalen Daten eine DICOM-Objekt- oder -Bilddatei, das Netz ist ein DICOM-Kommunikationsnetz und die Anwendung ist ein medizinisches Abbildungs-Anwendungsprogramm, das mittels eines DICOM-Netzprotokolls zu kommunizieren vermag. Das Verfahren beginnt bei 302.
304 folgt auf 302. In 304 stimmt eine Kommunikationsmaschine 104 die Größe von Protokolldateneinheiten (PDUs) ab. Das Festlegen der Größe von PDUs gestattet der Kommunikationsmaschine 104 die Überwachung der Speichergröße im Puffer 112, die zur Verarbeitung der digi talen Daten benötigt oder gewünscht wird. Außerdem kann auch eine vordefinierte Anzahl, ein Grenzwert oder eine Größe der Präsentationsdatenwerte (PDVs) oder ein anderer Datenelement- oder Qualitätstyp durch die Kommunikationsmaschine 104 je nach der Größe des Speicherplatzes im Puffer 112, die zur Verarbeitung der digitalen Daten benötigt oder gewünscht wird, festgelegt werden. Typischerweise werden diese Schritte in Verbindung mit der Festlegung einer Zugehörigkeit oder Verbindung zwischen einem Service Class Provider (SCP) und einem Service Class User (SCU) durch die Zustandsmaschine 110 ausgeführt. Die Kommunikationsmaschine 104 überwacht und steuert die Zustandsmaschine 110 durch die Dienstschicht obere Ebene 118 während des gesamten Verfahrens 300.
Auf 304 folgt 306, wo die Kommunikationsmaschine 104 digitale Daten inkrementell aus einem Netz liest. Die Kommunikationsmaschine 104 fordert z. B. digitale Daten wie z. B. eine DICOM-Bilddatei von einem Server 128a bis n in einem DICOM-Netz 102 an. Die DICOM-Bilddatei kann einen oder mehrere Sets digitaler Bilddaten enthalten. Der Server 128a bis n überträgt die digitalen Bilddatensets über das TCP/IP 126 mittels Sockets, eine Anwendungsprogrammschnittstelle, an die Kommunikationsmaschine 104. Die Kommunikationsmaschine 104 empfängt die digitalen Bilddaten-Sets in der Form von DICOM-Paketen oder Protokolldateneinheiten (PDUs) vom Server 128a bis n.
Es ist zu beachten, dass der Fachmann weiß, welche die Verfahren und Systeme zur Erzeugung und Übertragung digitaler Daten über TCP/IP mittels Sockets erforderlich sind. Außerdem werden Protokolldateneinheiten (PDUs) und DICOM-Pakete unter dem vorher oben beschriebenen DICOM-Protokoll definiert.
Auf 306 folgt 308, wo die Kommunikationsmaschine 104 jede PDU oder jedes DICOM-Paket inkrementell liest. Das heißt, die Kommunikationsmaschine 104 initialisiert einen Lese-Thread ("Lesefaden") (nicht dargestellt) durch die Transportschicht 116 des DICOM-Protokolls 114. Durch den Lese-Thread werden alle PDUs oder DICOM-Pakete inkrementell einzeln gelesen und nacheinander über die Transportschicht 116 des DICOM-Protokolls 114 übertragen. Der Lese-Thread fährt mit der Verarbeitung der PDUs oder DICOM-Pakete fort, bis alle PDUs oder DICOM-Pakete der aus dem Netz zu übertragenden digitalen Daten abgewickelt worden sind.
Auf 308 folgt 310, wo die Kommunikationsmaschine 104 die PDUs an die Dienstschicht obere Ebene 118 überträgt. Wenn die PDUs während der Zugehörigkeit oder Verbindung zur passenden Zeit eintreffen, werden die PDUs dann durch die Kommunikationsmaschine 104 an die Datendienstschicht 120 übertragen.
Auf 310 folgt 312, wo die Kommunikationsmaschine 104 Präsentationsdatenwerte (PDVs) aus jeder Protokolldateneinheit (PDU) extrahiert. Das heißt, wenn die PDUs bei der Datendienstschicht 120 empfangen werden, extrahiert die Kommunikationsmaschine 104 die Präsentationsdatenwerte (PDVs) aus den PDUs. Jede Protokolldateneinheit enthält einen oder mehrere Präsentationsdatenwerte.
Auf 312 folgt das Unterprogramm 314, in dem ein Präsentationsdatenwerteingangsstrom für eine Operationsnachricht erzeugt wird. Das Unterprogramm 314 wird unter Bezugnahme auf 3b detaillierter beschrieben.
In 3b beginnt das Unterprogramm 314 bei 350. Bei 350 erzeugt die Kommunikationsmaschine 104 mittels Präsentationsdatenwerten einen Präsentationsdatenwerteingangsstrom. Für die anfänglichen oder ersten Protokolldateneinheiten (PDUs) werden durch die Kommunikationsmaschine 104 empfangene extrahierte Präsentationsdatenwerte (PDVs) zur Erzeugung eines Präsentationsdatenwerteingangsstroms (PDVIS) verwendet. Für nachfolgende PDUs können die extrahierten PDVs in einen bestehenden Präsentationsdatenwerteingangsstrom eingefügt oder ein neuer Präsentationsdatenwerteingangsstroms erzeugt werden, falls nötig. Ein Präsentationsdatenwerteingangsstrom ist im Wesentlichen eine Kette von Präsentationsdatenwerten (PDVs) von einer oder mehreren PDUs, die mittels einer relativ kleinen festen Speichergröße übertragen werden können. Der Präsentationsdatenwerteingangsstrom (PDVIS) bildet die Grundlage einer Operationsnachricht.
Die Kommunikationsmaschine 104 überträgt weiter jeden extrahierten PDV inkrementell oder nacheinander an die Datendienstschicht 120. Die Datendienstschicht 120 fügt jeden PDV in einen Präsentationsdatenwerteingangsstrom (PDVIS) ein, wie oben beschrieben. Der PDVIS kann auf Speichern einer vordefinierten oder begrenzten Anzahl PDVs zu jedem gegebenen Zeitpunkt begrenzt sein. Typischerweise ist der PDVIS auf das gleichzeitige Speichern von fünf (5) PDVs beschränkt. Es ist zu beachten, dass die vordefinierte oder begrenzte Anzahl gemäß der Größe eines Puffers oder eines anderen einen Speicher aufweisenden Speichergeräts festgelegt werden kann, um die PDVs und/oder PDVIS zu speichern.
Auf 350 folgt ein Entscheidungsblock 354, in dem die Datendienstschicht bestimmt, ob die vordefinierte oder begrenzte Anzahl PDVs erreicht worden ist. Auf diese Weise kann die Übertragung von Bilddaten inkrementell gesteuert werden, um die Speichergröße des zur Verarbeitung aller Bilddaten benötigten Speichers zu minimieren. Die Datenelementquelle 106 verarbeitet PDVs inkrementell oder nacheinander und überträgt jeden PDV an den PDVIS. Wenn eine vordefinierte oder begrenzte Anzahl PDVs erreicht worden ist, wird der Zweig "JA" zu 356 verfolgt. Wenn die vordefinierte oder begrenzte Anzahl PDVs z. B. vorher auf fünf (5) gesetzt worden ist und sich die vordefinierte oder begrenzte Anzahl PDVs bereits in einem bestimmten PDVIS befindet, ist der Grenzwert erreicht worden. Auf diese Weise kann die Erfindung die Nutzung von Speicher auf eine relativ kleine feste Speichergröße, die zur Übertragung digitaler Daten wie z. B. DICOM-Daten genutzt werden kann, begrenzen und überwachen. Es ist zu beachten, dass in einigen Fällen eine vordefinierte oder begrenzte Anzahl je nach der Größe des Puffers 112 oder des einen Speicher aufweisenden Speichergeräts festgelegt werden kann. Auf diese Weise können Bildpunktdatenelemente (PD-Elemente) und relativ größere DICOM-Objekte in relativ kleinen Datenportionen mit fester Größe abgewickelt werden.
Bei 356 verzögert die Kommunikationsmaschine 104 die weitere Verarbeitung von Präsentationsdatenwerten, bis ein Präsentationsdatenwert aus dem Präsentationsdatenwerteingangsstrom ausgelesen werden kann. Die Kommunikationsmaschine 104 weist die Datendienstschicht 120 an zu warten, bis ein Präsentationsdatenwert (PDV) aus dem Präsentationsdatenwerteingangsstrom (PDVIS) ausgelesen wird. Das heißt, die Kommunikationsmaschine 104 sendet einen Befehl an die Datendienstschicht 120, der die Transportschicht 116 vorübergehend daran hindert, weitere PDVs in den PDVIS einzulesen, bis ein PDV aus dem PDVIS ausgelesen wird. Wenn ein PDV aus dem PDVIS ausgelesen wird, weist die Kommunikationsmaschine 104 die Datendienstschicht 120 an, der Transportschicht 116 weiterhin die Weitergabe von PDVs an den PDVIS zu gestatten, bis die vordefinierte oder begrenzte Anzahl PDVs erreicht ist.
Nunmehr sei erneut auf den Entscheidungsblock 354 Bezug genommen, wonach – falls eine vordefinierte oder begrenzte Anzahl PDVs nicht erreicht worden ist – der Zweig "NEIN" verfolgt, bei dem das Unterprogramm 314 endet, und das Verfahren 300 geht bei 316 weiter.
Bei 316 bestimmt der Nachrichtendienst (Message Service), welcher Operation die Operationsnachricht entspricht. Sobald eine Operationsnachricht durch die Kommunikationsmaschine 104 im Unterprogramm 314 erzeugt ist, sendet die Kommunikationsmaschine typischerweise die Operationsnachricht einschließlich der PDVs und des PDVIS an einen Nachrichtendienst (nicht dargestellt). Der Nachrichtendienst ist eine Komponente der Datendienstschicht 120 des DICOM-Protokolls 114.
Im DICOM-Netzprotokoll wird eine Operation durch ein Dienstobjektpaar (Service Object Pair, SOP) definiert. Während der anfänglichen Zugehörigkeit oder Verbindung, die von der Zustandsmaschine 110 hergestellt wird, können ein oder mehrere SOPs identifiziert werden. Unter Verwendung der SOPs bestimmt der Nachrichtendienst, ob eine Nachricht eine übereinstimmende oder entsprechende Operation hat.
Auf 316 folgt 318, wo der Nachrichtendienst die Operationsnachricht an die entsprechende Operation überträgt. Wird ein SOP vom Nachrichtendienst als eine entsprechende Übereinstimmung für eine Nachricht identifiziert, wird die Operationsnachricht an die entsprechende Operation übertragen.
Auf 318 folgt 320, wo die Operationsnachricht durch die entsprechende Operation zur nachfolgenden Verarbeitung in eine Warteschlange eingereiht wird. Sobald die Nachricht in die Warteschlange eingereiht worden ist, geht das Verfahren 300 bei 320 in 3c weiter.
Auf 320 folgt 322, wo die in die Warteschlange eingereihten Nachrichten durch jede jeweilige Operation verarbeitet werden. Alle Operationen, die mindestens eine in die Warteschlange eingereihte Operationsnachricht erhalten, initialisieren einen Thread. Für jede Operation verarbeitet dann jeder Thread nacheinander jede in die Warteschlange eingereihte Operationsnachricht. Jede in die Warteschlange eingereihte Operationsnachricht wird dann an den entsprechenden Dienst weitergegeben, für den die Operationsnachricht erzeugt wurde. Es ist zu beachten, dass jede Operation einen entsprechenden Dienst oder ein entsprechendes SOP hat, wie durch das DICOM-Netzprotokoll definiert. Jeder Thread fährt mit der Verarbeitung jeder Operationsnachricht fort, bis jede in die Warteschlange eingereihte Nachricht für jede jeweilige Operation verarbeitet worden ist.
Auf 322 folgt 324, wo der Dienst Datenelemente aus dem Präsentationsdatenwerteingangsstrom (PDVIS) extrahiert.
Auf 324 folgt 326, wo der Dienst eine neue Eingangstransfersyntax (ITS) erzeugt. Der Dienst nutzt den Präsentationsdatenwerteingangsstrom (PDVIS) zur Erzeugung einer neuen ITS, die zum Analysieren der im PDVIS enthaltenen Daten verwendet werden kann. Die im PDVIS enthaltenen Daten sind eine Reihe von Präsentationsdatenwerten (PDVs). Die Datenwerte werden typischerweise codiert, und die Eingangstransfersyntax kann verwendet werden, um die Kodierung in eine Darstellung umzuwandeln, die als eine Standard-Speicherdarstellung für die Datenelemente verstanden werden kann. Die analysierten Daten können dann durch die Kommunikationsmaschine 104 an eine Datenelementquelle 106 gestreamt werden.
Auf 326 folgt 328, wo die Datenelementquelle 106 den analysierten Datenstrom inkrementell liest. Jeder Dienst nutzt die Datenelementquelle 106, um jeweils einen Block Datenelemente aus dem im Präsentationsdatenwerteingangsstrom (PDVIS) enthaltenen Datenstrom auszulesen. Die Eingangstransfersyntax (ITS) kann auch genutzt werden, um die Datenelemente durch die Datenelementquelle 106 inkrementell zu lesen.
Mindestens zwei Typen von Datenelementen können vom Dienst an der Datenelementquelle 106 abgewickelt werden: Sequenzdaten (SQ) und Bildpunktdaten (PD). Das SQ-Datenelemente kann ein Datenelement sein, das einen oder mehrere Sets Datenelemente enthält. SQ-Datenelemente können rekursiv verarbeitet werden. Das heißt, bei der Verarbeitung eines Sets Datenelemente wird nacheinander jeweils ein einziges Datenelement verarbeitet. Das PD-Element ist eines der größten Datenelemente in einem DICOM-Objekt oder einer Bilddatei. Die PD-Elemente können aus einer Rohdatenreihe von Bytes (8-Bit) oder Wörtern (16-Bit) zusammengesetzt sein. Dieser Datenelementtyp gestattet zusätzliche Streaming-Schichten. Der Dienst kann Bildpunktdaten inkrementell erhalten, wodurch die Notwenigkeit, alle PD-Werte im Speicher zu einem einzigen Zeitpunkt zu erhalten, minimiert wird. Es ist zu beachten, dass Bildpunktdatenelemente (PD-Elemente) und andere DICOM-Objekte relativ groß sein können. Die Erfindung ermöglicht die Abwicklung von Bildpunktdatenelementen (PD-Elementen) und DICOM-Objekten aller Größen im Lauf der Zeit in relativ kleinen Portionen.
Auf 328 folgt 330, wo das Verfahren 300 endet.
Die 4a bis b stellen ein zweites beispielhaftes Verfahren der vorliegenden Erfindung dar. Wie folgt, beschreiben die 4a bis b ein Verfahren 400 zum Schreiben von Daten aus einer Anwendung in ein Netz oder eine andere Anwendung. Im Allgemeinen sind die Daten eine DICOM-Objekt- oder -Bilddatei, das Netz ist ein DICOM-Kommunikationsnetz und die Anwendung ist ein medizinisches Abbildungs-Anwendungsprogramm, das mittels eines DICOM-Netzprotokolls zu kommunizieren vermag.
Das Verfahren 400 beginnt bei 402.
Auf 402 folgt 404, wo die Kommunikationsmaschine 104 ein Datenset aufruft. Wenn ein Benutzer mit einem zugehörigen Anwendungsprogramm 101 oder alternativ einem auf einem Server 128a bis n in einem DICOM-Netz 102 ausführenden Anwendungsprogramm 130 in Dialog tritt, kann der Benutzer typischerweise eine bestimmte Funktion auf ein bestimmtes DICOM-Objekt oder -Bild anwenden wollen. Der Benutzer kann eine entsprechende Befehlsfunktion im zugehörigen Anwendungsprogramm 101 oder Anwendungsprogramm 130 wählen, die einem bestimmten Dienst des Anwendungsprogramms 101, 130 oder Netzes 102 entspricht. Beim Empfang der Befehlsfunktion lokalisiert der Dienst ein entsprechendes Datenset für die Kommunikationsmaschine 104. Es ist zu beachten, dass ein Datenset ein oder mehrere Datensets aufweisen kann, wobei jedes Datenset ein oder mehrere Datenelemente umfasst. Das Datenset für ein DICOM-Objekt oder -Bild kann in einem zugehörigen Speichergerät wie z. B. einem Medienspeichermodul 132 oder Metadatenbankmodul 134 gespeichert werden.
Auf 404 folgt 406, wo der gewählte Dienst eine neue Ausgangstransfersyntax (OTS) für das Datenset erzeugt. Wenn ein Dienst eine Befehlsfunktion empfängt, erzeugt der Dienst eine neue Ausgangstransfersyntax (OTS) zur Abwicklung des Datensets. Die OTS kann ein Datenset formatieren und in einen Datenstrom wie z. B. einen Bytestrom umwandeln. Das Datenset kann eine Datenelementquelle sein. Die OTS kann auch eine Datenelementquelle formatieren und in einen Datenstrom wie z. B. einen Bytestrom umwandeln. Eine Datenelementquelle (data element source, DES) ist ein Vorwärts-Iterator über ein konzeptionelles Set Datenelemente. Eine Eingangstransfersyntax (ITS) kann z. B. eine Datenelementquelle (DES) für ein bestimmtes Set Präsentationsdatenwerte (PDVs) erzeugen.
Auf 406 folgt 408, wo der Dienst einen geregelten Datenseteingangsstrom (governed data set input stream, GDSIS) erzeugt. Der Dienst erzeugt mittels der Ausgangstransfersyntax einen geregelten Datenseteingangsstrom (GDSIS). Unter Verwendung seines eigenen Thread kann ein GDSIS dann mittels der Ausgangstransfersyntax ein Datenset oder eine Datenelementquelle in einen Datenstrom wie z. B. einen Bytestrom umwandeln. Der GDSIS kann unter Verwendung nur einer relativ kleinen festen Speichergröße das Datenset oder die Datenelementquelle in einen Datenstrom umwandeln.
Typischerweise nimmt die Ausgangstransfersyntax nacheinander jedes Datenelement aus dem Datenset oder der Datenelementquelle und codiert jedes Datenelement in eine Reihe Datenelemente oder einen Datenstrom. Mindestens zwei unterschiedliche Typen von Datenelementen können durch die Ausgangstransfersyntax verarbeitet werden: Sequenzdatenelemente (SQ-Elemente) und Bildpunktdatenelemente (PD-Elemente). Im Fall von Sequenzdatenelementen (SQ-Elementen) enthalten SQ-Elemente Datenelementsets. Werden SQ-Elemente durch die Ausgangstransfersyntax (OTS) gelesen, verarbeitet die OTS rekursiv jeweils ein Datenelement aus einem bestimmten Set Datenelemente. Im Fall von PD-Elementen enthalten PD-Elemente eine große Reihe von Bytes oder Wörtern. Wenn PD-Elemente durch die Ausgangstransfersyntax (OTS) gelesen werden, verarbeitet die OTS diese als Informationspartikel oder kleine Datenelemente mit festen Größen. In jedem Fall wird von der OTS nur eine relativ kleine feste Größe Speicher zur Verarbeitung der Datenelemente verwendet. Der Dienst kann Bildpunktdaten inkrementell erhalten, wodurch die Notwenigkeit, alle PD-Werte im Speicher zu einem einzigen Zeitpunkt zu erhalten, minimiert wird. Es ist zu beachten, dass Bildpunktdatenelemente (PD-Elemente) und andere DICOM-Objekte relativ groß sein können. Durch die Erfindung können Bildpunktdatenelemente (PD-Elementen) und andere DICOM-Objekte aller Größen im Lauf der Zeit in relativ kleinen Portionen abgewickelt werden.
Auf 408 folgt 410, wo der Dienst den geregelten Datenseteingangsstrom in einer Operationsnachricht verpackt.
Auf 410 folgt 412, wo der Dienst die Nachricht an einen Nachrichtendienst sendet.
Auf 414 folgt 416, wo der Nachrichtendienst die entsprechende Operation für die Nachricht bestimmt.
Auf 416 folgt 418, wo der Nachrichtendienst die Nachricht an die Datendienstschicht 120 weitergibt.
Auf 418 folgt 420, wo die Datendienstschicht 120 den geregelten Datenseteingangsstrom aus der Nachricht decodiert. Im Allgemeinen empfängt die Datendienstschicht 120 die Nachricht vom Nachrichtendienst. Der Nachrichtendienst extrahiert den geregelten Datenseteingangsstrom (GDSIS) aus der Nachricht und liest Bytes aus dem GDSIS. Der Nachrichtendienst liest so lange Bytes aus dem GDISIS, bis der Nachrichtendienst eine Protokolldateneinheit (PDU) aufbauen kann. Das Verfahren 400 wird dann in 420 in 4b fortgesetzt.
Auf 420 folgt 422, wo der Nachrichtendienst eine Protokolldateneinheit (PDU) an die Transportschicht 116 sendet. Wenn die Zugehörigkeit oder Verbindung offen ist, kann der Nachrichtendienst typischerweise die PDU durch die Dienstschicht obere Ebene 118 zur Transportschicht 116 senden.
Auf 422 folgt 424, wo die Transportschicht 116 die Protokolldateneinheit an eine empfangende Anwendung überträgt. Im Allgemeinen überträgt die Transportschicht 116 die Protokolldateneinheit (PDU) über die TCP/IP-Schicht 126 und dann über das DICOM-Netz 102 an das Anwendungsprogramm 130.
Auf 424 folgt der Entscheidungsblock 426, wo der Nachrichtendienst bestimmt, ob alle Datenelemente durch die Datenelementquelle 106 in einen Bytestream umgewandelt worden sind. Wenn alle Datenelemente umgewandelt worden sind, wird der Zweig "JA" zu 428 verfolgt.
Bei 428 endet das Verfahren 400.
Nunmehr sei erneut auf den Entscheidungsblock 426 Bezug genommen, wo der Zweig "NEIN" verfolgt wird, falls nicht alle übrigen Datenelemente umgewandelt worden sind. Das Verfahren 400 kehrt nach Bedarf zu 420 zurück, um die Verarbeitung des geregelten Datenseteingangsstroms (GDSIS) zu vervollständigen. 5 stellt ein drittes beispielhaftes Verfahren der vorliegenden Erfindung dar. 5 beschreibt ein Verfahren 500 zum Lesen von Daten aus einer Datei. Im Allgemeinen sind die Daten eine DICOM-Objekt- oder -Bilddatei und der Datei kann ein zugehöriges Anwendungsprogramm 101 oder Anwendungsprogramm 130 wie z. B. ein medizinisches Abbildungsprogramm, das mittels eines DICOM-Protokolls zu kommunizieren vermag, zugeordnet sein. Die Datei kann vorher auf einem Speichergerät oder -system wie z. B. einem in Verbindung mit einem Kommunikationsnetz wie z. B. DICOM-Netz 102 arbeitenden Server 128a bis n oder einem Medienspeichermodul 132 oder Metadatenbankmodul 134 gespeichert werden, wie zurvor beschrieben worden ist. In 5 beginnt das Verfahren 500 bei 502.
Auf 502 folgt 504, wo die Kommunikationsmaschine 104 einen Dateieingangsstrom für eine Bilddatei erzeugt. Ein Dateieingangsstrom kann ein Eingangsstrom von Bytes sein. Wenn ein Benutzer beschließt, Bilddaten oder Objekte aus einer Datei zu lesen, wählt der Benutzer typischerweise einen Anwendungsbefehl, um eine Objekt- oder -Bilddatei zu lesen. Ein zugehöriges Anwendungsprogramm 101 kann z. B. einem Benutzer die Auswahl eines Befehls gestatten, um eine Datei zu lesen, die eine DICOM-Objekt- oder Bilddatei enthält. Wenn der betreffende Befehl gewählt wird, erzeugt das zugehörige Anwendungsprogramm 101 einen Dateieingangsstrom für die zu lesende DICOM-Objekt- oder -Bilddatei in einem System, das die DICOM-Objekt- oder -Bilddatei enthält. Der Dateieingangsstrom ist ein Vorwärts-Iterator über einen Abschnitt von Bytes oder Datenelementen in einer Datei. Der Dateieingangsstrom kann vom Anfang bis zum Ende in einer einzigen Richtung gelesen werden. Das System kann ein Server 128a bis n, Medienspeichermodul 132 oder Metadatenbankmodul 134 sein, wie zuvor definiert worden ist.
Auf 504 folgt 506, wo die Kommunikationsmaschine 104 eine Eingangstransfersyntax (ITS) zum Lesen der Bilddatei erzeugt. Im Allgemeinen erzeugt die Kommunikationsmaschine 104 eine Eingangstransfersyntax (ITS) mittels des vorher erzeugten Dateieingangsstroms. Die Eingangstransfersyntax (ITS) kann dann zum Auslesen von Datenelementen aus der entsprechenden Objekt- oder Bilddatei verwendet werden.
Auf 506 folgt 508, wo die Datenelementquelle 106 jedes Datenelement inkrementell aus dem Dateieingangsstrom ausliest. Die Datenelementquelle 106 nutzt die Eingangstransfersyntax (ITS), um ein Datenelement oder einen Blocks aus Datenelementen auf einmal inkrementell aus dem Dateieingangsstrom auszulesen. Mindestens zwei unterschiedliche Typen von Datenelementen können verarbeitet werden: Sequenzdatenelemente (SQ-Elemente) und Bildpunktdatenelemente (PD-Elemente). Im Fall von Sequenzdatenelementen (SQ-Elementen) enthalten SQ-Elemente Datenelementsets. Wenn SQ-Elemente durch die Eingangstransfersyntax (ITS) gelesen werden, verarbei tet die ITS rekursiv jeweils ein Datenelement aus einem bestimmten Set Datenelemente. Im Fall von PD-Elementen enthalten PD-Elemente eine große Anordnung von Bytes oder Wörtern. Wenn PD-Elemente durch die Eingangstransfersyntax (ITS) gelesen werden, verarbeitet die ITS diese als Informationspartikel oder kleine Datenelemente mit festen Größen. In jedem Fall wird von der ITS nur eine relativ kleine feste Größe Speicher zur Verarbeitung der Datenelemente verwendet.
Auf 508 folgt 510, wo die Kommunikationsmaschine 104 die Eingangstransfersyntax (ITS) schließt. Das heißt, nachdem alle Datenelemente durch die Datenelementquelle gelesen worden sind, schließt die Kommunikationsmaschine die Eingangstransfersyntax, und es wird keine weitere Verarbeitung der Datenelemente durch die Datenelementquelle 106 ausgeführt.
Auf 510 folgt 512, wo das Verfahren 500 endet.
6 stellt ein viertes beispielhaftes Verfahren der vorliegenden Erfindung dar. 6 beschreibt ein Verfahren 600 zum Schreiben von Daten in eine Datei. Im Allgemeinen sind die Daten eine DICOM-Objekt- oder -Bilddatei, und der Datei kann eine Anwendung wie z. B. ein medizinisches Abbildungsprogramm, das mittels eines DICOM-Protokolls zu kommunizieren vermag, zugeordnet sein. Die Datei kann vorher auf einem Speichergerät oder -system wie z. B. einem in Verbindung mit einem Netz wie z. B. DICOM-Kommunikationsnetz arbeitendem Server gespeichert werden. In 6 beginnt das Verfahren 600 bei 602.
Auf 602 folgt 604, wo die Kommunikationsmaschine 104 einen Dateiausgangsstrom erzeugt. Ein Dateieingangsstrom kann ein Ausgangsstrom von Bytes sein. Wenn ein Benutzer beschließt, Bilddaten in eine Datei zu schreiben, wählt der Benutzer typischerweise einen Befehl von einem zugehörigen Anwendungsprogramm 101 oder einem Anwendungsprogramm 130, um Daten in eine Objekt- oder -Bilddatei zu schreiben. Ein zugehöriges Anwendungsprogramm 101 kann z. B. einem Benutzer die Auswahl eines Befehls gestatten, um Bilddaten in eine Datei zu schreiben, die zum Speichern eines DICOM-Objekts oder -Bildes konfiguriert ist. Wenn ein bestimmter Befehl gewählt wird, erzeugt das Anwendungsprogramm 130 einen Dateiausgangsstrom für die in ein System, das die DICOM-Objekt- oder -Bilddatei enthält, zu schreibenden Bilddaten. Das System kann ein Server 128a bis n, ein Medienspeichermodul 132 oder ein Metadatenbankmodul 134 sein, wie zuvor definiert worden ist.
Auf 604 folgt 606, wo das Anwendungsprogramm 130 eine Ausgangstransfersyntax (OTS) zum Schreiben der Bilddaten in die Objekt- oder Bilddatei erzeugt. Im Allgemeinen erzeugt das zugehörige Anwendungsprogramm 101 oder Anwendungsprogramm 130 eine Ausgangstransfersyntax (OTS) mittels des vorher erzeugten Dateiausgangsstroms. Wenn eine Ausgangstransfersyntax (OTS) erzeugt wird, ist der Dateiausgangsstrom ein Argument, das zur Erzeugung der Ausgangstransfersyntax verwendet wird. Die OTS kann dann zum Schreiben der Bilddaten in die entsprechende Objekt- oder Bilddatei verwendet werden.
Auf 606 folgt 608, wo ein Datenelementaufnehmer 108 jedes Datenelement inkrementell in den Dateiausgangsstrom schreibt. Das heißt, der Datenelementaufnehmer 108 nutzt die Ausgangstransfersyntax (OTS) zum inkrementellen Schreiben eines Datenelements oder eines Blocks von Datenelementen jeweils einzeln in den Dateiausgangsstrom. Wie oben bei 5 beschrieben, können mindestens zwei unterschiedliche Typen von Datenelementen verarbeitet werden: Sequenzdatenelemente (SQ-Elemente) und Bildpunktdatenelemente (PD-Elemente). Im Fall von Sequenzdatenelementen (SQ-Elementen) enthalten SQ-Elemente Datenelementsets. Werden SQ-Elemente durch die Ausgangstransfersyntax (OTS) geschrieben, verarbeitet die OTS rekursiv jeweils ein Datenelement aus einem bestimmten Set Datenelemente. Im Fall von PD-Elementen enthalten PD-Elemente eine große Reihe von Bytes oder Wörtern. Wenn PD-Elemente durch die Ausgangstransfersyntax (OTS) geschrieben werden, verarbeitet die OTS diese als Informationspartikel oder kleine Datenelemente mit festen Größen. In jedem Fall wird von der Ausgangstransfersyntax (OTS) nur eine relativ kleine feste Größe Speicher zur Verarbeitung der Datenelemente verwendet.
Auf 608 folgt 610, wo die Kommunikationsmaschine 104 die Ausgangstransfersyntax (OTS) schließt. Das heißt, nachdem alle Datenelemente durch den Datenelementaufnehmer 108 in den Dateiausgangsstrom geschrieben worden sind, wird die Ausgangstransfersyntax durch die Kommunikationsmaschine 104 geschlossen, wodurch die jetzt die Objekt- oder Bilddatei enthaltende Datei effektiv geschlossen wird.
Auf 610 folgt 612, wo das Verfahren 600 endet.
7 zeigt eine repräsentative Darstellung von in einer DICOM-Bilddatei enthaltenen Daten. Dieses spezielle Beispiel ist eine Magnetresonanzbild-(MRI-)DICOM-Bilddatei 700. In diesem Beispiel werden die ersten 794 Bytes für einen DICOM-Formatkopf 702 verwendet. Der Formatkopf 702 beschreibt die Bilddimensionen und enthält andere Textinformationen über die Abtastung. Die Größe dieses Kopfs 702 variiert je nachdem, wie viele Kopfinformationen gespeichert werden. Das Beispiel zeigt die Abmessungen des Bildes als 109 × 91 × 2 Bildpunkte mit einer Auflösung von 1 Byte pro Bildpunkt, daher beträgt die gesamte Bildgröße ca. 19.838 Bytes.
Die Bilddaten 704 werden in dem Dateiabschnitt gespeichert, der dem Kopf 702 folgt. Die Bilddaten werden auch in der gleichen Datei gespeichert wie der Kopf 702 und zugehörige Informationen. 8 stellt in einer DICOM-Bilddatei enthaltene Daten dar. In diesem Beispiel erfordert das DICOM-Kopfformat ein aus 128 Bytes bestehendes Vorwort. Typischerweise ist in einem DICOM-Kopfformat das aus 128 Bytes bestehende Vorwort gewöhnlich auf null gesetzt. Dem aus 128 Bytes bestehenden Vorwort folgen dann die Buchstaben D", "I", "C" und "M". Dem letzten Buchstaben "M" folgen dann Kopfinformationen. Die Kopfinformationen können in einem oder mehreren als "Gruppen" bezeichneten Abschnitten zusammengestellt sein. Eine Gruppe "0002hex" kann z. B. die Dateimetainformationengruppe bezeichnen. Diese Gruppe kann drei Elemente wie z. B. Gruppenlänge, Dateiversion und Transfersyntax definieren. Die in jeder Gruppe definierten DICOM-Datenelemente hängen vom Bildtyp ab. Ein repräsentatives Muster von Datenelementen, die definiert werden können, ist in Teil 3 der DICOM-Norm 2000 aufgeführt. Eine Magnetresonanz-(MR-)Bilddatei kann z. B. durch Element 0008,0060 bezeichnet werden. Dieser Bilddateityp kann ein oder mehrere Elemente zur Beschreibung der MRI-Echozeit enthalten.
Für den Fachmann auf dem Fachgebiet, auf das sich die Erfindung bezieht, sind alternative Ausführungsformen ohne Abweichung von ihrem Gültigkeitsbereich offensichtlich.

Claims

Verfahren zur Übertragung von Digital Imaging and Communications in Medicine (etwa: digitale Bildkommunikation in der Medizin) DICOM-Objekten (206) zwischen zwei Geräten (128a–n) in einem DICOM-Netz (102; 202): I) Abwickeln von DICOM-Objekten (206) und zugehörigen Datenelementen (240) durch eine Kommunikationsmaschine (104), die in einem Kommunikationsmodul (100) enthalten ist, zwischen einem zugehörigen Anwendungsprogramm (101) und dem Kommunikationsmodul (100); II) Abwickeln von DICOM-Objekten und zugehörigen Datenelementen durch eine Kommunikationsmaschine (104), die in einem Kommunikationsmodul (100) enthalten ist, zwischen dem Kommunikationsmodul und dem DICOM-Netz; III) Übertragen von DICOM-Objekten und zugehörigen Datenelementen durch eine Kommunikationsmaschine (104), die in einem Kommunikationsmodul (100) enthalten ist, zwischen Komponenten (104, 106, 108, 110, 112) des Kommunikationsmoduls; IV) Übertragen von DICOM-Objekten und zugehörigen Datenelementen durch eine Kommunikationsmaschine (104), die in einem Kommunikationsmodul (100) enthalten ist, zwischen Schichten (122, 120, 118, 116) eines DICOM-Protokolls (114); und/oder V) Übertragen von DICOM-Objekten durch ein Kommunikationsmodul (100) zwischen dem zugehörigen Anwendungsprogramm und einem Anwendungsprogramm (130) über das DICOM-Netz; VI) Abstimmen durch das Kommunikationsmodul (100): a) mit dem zugehörigen Anwendungsprogramm (101) und den Geräten (128a–n), um eine maximale Größe der DICOM-Dateneinheit (226) zu definieren, die zwischen dem zugehörigen Anwendungsprogramm und den Geräten übertragen wird; und b) um eine maximale Anzahl DICOM-Präsentationsdatenwerte (230) im DICOM-Präsentationsdatenwerteingangsstrom als einen vorgegebenen Grenzwert zu definieren; VII) Erzeugen des DICOM-Präsentationsdatenwerteingangsstroms, der DICOM-Präsentationsdatenwerte aufweist, die aus einer oder mehreren DICOM- Protokolldateneinheiten extrahiert worden sind, durch die Kommunikationsmaschine; VIII) Verarbeiten der DICOM-Präsentationsdatenwerte durch eine Datenelementquelle (106; 206), die im Kommunikationsmodul enthalten ist, auf inkrementelle Weise oder einzeln nacheinander und Übertragen jedes DICOM-Präsentationsdatenwertes an den DICOM-Präsentationsdatenwerteingangsstrom; und IX) Speichern des DICOM-Präsentationsdatenwerteingangsstroms in einem Puffer (112) mit fester Größe.
Kommunikationsmodul (100) mit einer Kommunikationsmaschine (104) und einer Datenelementquelle (106) und zum Übertragen oder Streamen (Echtzeitübertragen) von Digital Imaging and Communications in Medicine DICOM-Objekten (206) zwischen zwei Geräten (128a–n) in einem DICOM-Netz (102; 202) gemäß dem Verfahren von Anspruch 1 eingerichtet.
Kommunikationsmodul nach Anspruch 2, bei dem: I) die Datenelementquelle (106; 206) einen Bildpunktdaten-Decodierer enthält, der so konfiguriert ist, dass er Bildpunktdaten aus einem Datenelement (240) in relativ kleinen Informationspartikeln der Daten mit fester Größe inkrementell in den Puffer (112) mit fester Größe einliest, und wenn ein Bildpunktdatenelement angetroffen wird, liest der Bildpunktdaten-Decodierer nicht das gesamte Datenelement sofort, sondern liest statt dessen die Bildpunktdaten inkrementell in den Puffer (112) mit fester Größe ein; II) das Kommunikationsmodul (100) einen Datenelementaufnehmer (108) hat, um Datenelemente nacheinander oder als ein Block nach einem Client oder Server (128a–n) zu schreiben, und einen Bildpunktdaten-Codierer enthält, der das Schreiben der Bildpunktdaten in relativ kleinen Informationspartikeln der Daten mit fester Größe gestattet, wodurch dann, wenn ein Bildpunktdatenelement angetroffen wird, der Bildpunktdaten-Codierer nicht das gesamte Datenelement sofort schreibt, sondern statt dessen die Bildpunktdaten inkrementell in den Puffer (112) mit fester Größe geschrieben werden.
Kommunikationsmodul nach Anspruch 2 oder 3, bei dem eine Gesamtspeichergröße zum Decodieren aus dem DICOM-Netz (102; 202) und zum Codieren einer Datei (206) 120 KB zum Decodieren und 10 KB zum Codieren beträgt.
Kommunikationsmodul nach einem der Ansprüche 2 bis 4, bei dem das Kommunikationsmodul (100) eine Zustandsmaschine (110) enthält, um eine Zugehörigkeit oder Verbindung zwischen einem DICOM-Service Class Provider (128n) und einem DICOM-Service Class-Nutzer (128a–c) zu initialisieren, zu überwachen und abzuwickeln.