Warning: fopen(111data/log202007021920.log): failed to open stream: No space left on device in /home/pde321/public_html/header.php on line 107

Warning: flock() expects parameter 1 to be resource, boolean given in /home/pde321/public_html/header.php on line 108

Warning: fclose() expects parameter 1 to be resource, boolean given in /home/pde321/public_html/header.php on line 113
Verfahren zur Bearbeitung von Objekten eines standardisierten Kommunikationsprotokolls - Dokument DE10117685C2
 
PatentDe  


Dokumentenidentifikation DE10117685C2 27.02.2003
Titel Verfahren zur Bearbeitung von Objekten eines standardisierten Kommunikationsprotokolls
Anmelder Siemens AG, 80333 München, DE
Erfinder Ebén, Björn, 91052 Erlangen, DE
DE-Anmeldedatum 09.04.2001
DE-Aktenzeichen 10117685
Offenlegungstag 17.10.2002
Veröffentlichungstag der Patenterteilung 27.02.2003
Veröffentlichungstag im Patentblatt 27.02.2003
IPC-Hauptklasse G06F 13/42
IPC-Nebenklasse G06F 15/173   G06F 19/00   

Beschreibung[de]

Die Erfindung betrifft ein Verfahren zur Bearbeitung von Objekten eines standardisierten Kommunikationsprotokoll zum Bild- und Datenaustausch zwischen Vorrichtungen über ein Kommunikationsnetz mittels Bearbeitungsvorrichtungen. Dieser Bild- und Datenaustausch kann als Kommunikation zwischen medizinischen Geräten mit dem Kommunikationsprotokoll "Digital Imaging and Communication in Medicine" (DICOM) erfolgen.

Aus dem Buch "Bildgebende Systeme für die medizinische Diagnostik", herausgegeben von H. Morneburg, 3. Auflage, 1995, Seiten 684 ff sind medizinische Systemarchitekturen, sogenannte Picture Archival and Communication Systeme (PACS), bekannt, bei denen zum Abruf von Patientendaten und durch Modalitäten erzeugte Bilder Bildbetrachtungs- und Bildbearbeitungsplätze, sogenannte Workstations, über ein Bildkommunikationsnetz miteinander und mit den übrigen medizinischen Geräten verbunden sind.

Diese Kommunikation zwischen medizinischen Systemen und Geräten unterschiedlicher Hersteller über ein derartiges Bildkommunikationsnetz ist sehr wichtig geworden. Die treibenden Kräfte sind Kostenreduzierung, Qualitätssteigerung und Rückverfolgbarkeit bzw. Nachweisbarkeit von medizinischen Informationen. Während der letzten Jahre ist der in dem obengenannten Buch auf Seite 686 beschriebene medizinische Kommunikationsstandard DICOM 3.0 für Kommunikationsprotokolle ect. ausgereift und bei Herstellern von medizinischen Geräten und Systemen weit verbreitet, um digitale Bilder zu senden und zu empfangen, wie beispielsweise Magnetresonanz-, Röntgen- und Ultraschall-Bilder.

Laufend werden neue Arten von DICOM-Objekten dem Standard hinzugefügt und der Standard selbst wird periodisch überarbeitet.

Betroffen von der Erfindung ist beispielsweise jedes medizinische System und Gerät, das DICOM Nachrichten mit folgenden Merkmalen sendet und empfängt:

  • 1. Die Nachrichten enthalten einen Block oder mehrere Blöcke von Informationen.
  • 2. Jeder Block enthält einen oder mehrere Informations-Objekt-Deskriptoren (Information Object Descriptor (IOD)).
  • 3. Jeder IOD enthält eine oder mehrere Information-Einheiten (Information Entities (IE)).
  • 4. Jede IE enthält ein oder mehrere Module.
  • 5. Jedes Modul enthält ein oder mehrere Elemente.
  • 6. Elemente können Einfachelemente oder in einem Container gruppierte Elemente sein (Sequenz (SQ)).
  • 7. SQs können einfache Elemente oder verschachtelte SQs beliebiger Tiefe enthalten.

Einfache Elemente sind die kleinsten Bausteine in DICOM. Sie sind identifizierbar durch ein einzigartiges bzw. eindeutiges Identifizierungsmerkmal, ein sogenanntes attribute tag.

Weiterhin legt DICOM Beschränkungen der Nachrichten fest: IODs haben einen einmaligen Typen- und einen einmaligen Vorgangsidentifizierer. Neu entwickelte IOD-Typen werden dem Standard hinzugefügt. Die IOD spezifizieren, welche Module in ihnen enthalten sein können oder müssen. Es gibt ein globales, ausdehnbares und überlappendes Set von Modulen, aus dem die Entwickler des Standards wählen können. Ein Modul spezifiziert für jedes seiner Elemente, ob es leer sein kann oder einen Null-Wert aufweisen kann oder alle zusammen ausgelassen werden können. Es können Abhängigkeiten zwischen den Elementen innerhalb der Module bestehen. Gegenseitige Aus- oder Einschlüsse sind nicht ungewöhnlich. Elemente sind weiterhin dadurch beschränkt, dass sie einen in einem Typen-Lexikon definierten Typ aufweisen. Häufige Typen sind codierte Strings oder Integerwerte. Der Standard definiert auch die Vielfalt der Elementwerte.

Aus der DE 196 25 838 ist eine medizinische Systemarchitektur mit Komponenten-Navigation, bei der eine Vorrichtung zur Verarbeitung ein digitales Bildsystem mit einem Rechner aufweist, der nach einem Verfahren zum Datenaustausch zwischen verschiedenen Anwendungsprogrammen (OLE) mit grafischen Steuerelementen arbeitet, wobei ein Industriestandard zur Übertragung von Bildern und weiteren medizinischen Informationen zwischen Computern zur Ermöglichung der digitalen Kommunikation zwischen den Modalitäten unterschiedlicher Hersteller als Software-Komponente in Kombination mit einer Scripting- Language-Technologie zur Navigation implementiert ist.

In der US 5,881,290 ist ein Decompiler beschrieben, der mit einem Compiler für eine Industriesteuerung zusammenarbeitet, die nutzervariable Befehlstabellen enthält. Die Befehlstabellen enthalten Codefragmente, die die Befehle während der Compilierung ersetzen.

Die Erfindung geht von der Aufgabe aus, ein Verfahren der eingangs genannten Art zu schaffen, das es ermöglicht, auf einfache Weise DICOM-Objekte zu editieren und artifizielle DICOM-Objekte zu konstruieren, um medizinische Systeme oder Geräte mit neuen DICOM-Objekten oder um die Robustheit der Systeme oder Geräte gegenüber veränderten oder ungültigen DICOM-Objekten leicht testen zu können.

Die Aufgabe wird erfindungsgemäß dadurch gelöst, dass die Objekte mittels einer Umsetzungsroutine in einen reinen Textfile (Plaintext) konvertiert werden, in einer einfachen Befehlssprache bearbeitbar sind und anschließend in die Objekte zurückgewandelt werden, dass das Kommunikationsprotokoll das medizinische Kommunikationsprotokoll DICOM ist und die Objekte eines Kommunikationsprotokoll DICOM-Objekte sind und dass die Umsetzungsroutine (15) aus DICOM-Objekten neben dem Textfile je einen Binärfile pro Tag mit Binärdaten erzeugt und bei der Rückwandlung der Textfiles die Binärfiles für Tags mit Binärdaten verwendet. Dadurch ergeben sich flexible Editier-, Skripting- und interagierende Kommunikationsmöglichkeiten beispielsweise in DICOM. Durch das erfindungsgemäße Verfahren kann ein Objekt optimal dargestellt werden, wobei auf einfache Weise beispielsweise ein MR-Bild editierbar ist. Durch den Gebrauch einer minimalen Sprache zur Beschreibung jedes zu repräsentierenden DICOM-Objektes wird das erfindungsgemäße Erfordernis nach leichter Konstruierbarkeit optimal erfüllt.

In vorteilhafter Weise kann ein Tag mit Binärdaten ein OB-, OW- und/oder OL-Tag sein, die in je einen Binärfile umgesetzt werden, die für OB, OW und OL-Tags bei der Rückwandlung verwendet werden.

Eine besonders einfache Befehlssprache erhält man, wenn zur Bearbeitung der Objekte im Textfile mit einem Befehl s ein Wert aus einer Zeichenfolge (String), mit einem Befehl f ein Wert aus einem Binärfile gesetzt, mit einem Befehl o eine Sequenz von Identifizierungsmerkmalen (TAGs) geöffnet und/oder mit einem Befehl c eine Sequenz von TAGs geschlossen wird. Mit einem Befehl q kann die Befehlsfolge beendet werden.

Es hat sich als vorteilhaft erwiesen, wenn DICOM-Bilder als Objekte mittels einer CDF-Umsetzungsroutine in einen .cdf- File als reinen Textfile und je einen Binärfile pro OB-, OW- und OL-Tag konvertiert werden, in eine cdf-Befehlssprache bearbeitbar sind und anschließend in die DICOM-Bilder zurückgewandelt werden.

Die Erfindung ist nachfolgend anhand von in der Zeichnung dargestellten Ausführungsbeispielen näher erläutert. Es zeigen:

Fig. 1 ein Beispiel einer Systemarchitektur eines Krankenhausnetzes und

Fig. 2 ein Simulationskonzept für MR zur Erläuterung des erfindungsgemäßen Verfahrens.

In der Fig. 1 ist beispielhaft die Systemarchitektur eines Krankenhausnetzes dargestellt. Zur Erfassung medizinischer Bilder dienen die Modalitäten 1 bis 4, die als bilderzeugende Systeme beispielsweise eine CT-Einheit 1 für Computertomographie, eine MR-Einheit 2 für Magnetische Resonanz, eine DSA- Einheit 3 für digitale Subtraktionsangiographie und eine Röntgeneinheit 4 für die digitale Radiographie 4 aufweisen kann. An diese Modalitäten 1 bis 4 sind Bedienerkonsolen 5 bis 8 der Modalitäten oder Workstations angeschlossen, mit denen die erfassten medizinischen Bilder verarbeitet und lokal abgespeichert werden können. Auch lassen sich zu den Bildern gehörende Patientendaten eingeben.

Die Bedienerkonsolen 5 bis 8 sind mit einem Kommunikationsnetz 9 als LAN/WAN Backbone zur Verteilung der erzeugten Bilder und Kommunikation verbunden. So können beispielsweise die in den Modalitäten 1 bis 4 erzeugten Bilder und die in den Bedienerkonsolen 5 bis 8 weiter verarbeiteten Bilder in zentralen Bildspeicher- und Bildarchivierungssystemen 10 abgespeichert oder an andere Workstations weitergeleitet werden.

An dem Kommunikationsnetz 9 sind weitere Viewing-Workstations 11 als Befundungskonsolen angeschlossen, die lokale Bildspeicher aufweisen. Eine derartige Viewing-Workstation 11 ist beispielsweise ein sehr schneller Kleincomputer auf der Basis eines oder mehrerer schneller Prozessoren. In den Viewing- Workstations 11 können die erfassten und im Bildarchivierungssystem 10 abgelegten Bilder nachträglich zur Befundung abgerufen und in dem lokalen Bildspeicher abgelegt werden, von dem sie unmittelbar der an der Viewing-Workstation 11 arbeitenden Befundungsperson zur Verfügung stehen können.

Weiterhin sind an dem Kommunikationsnetz 9 Server 12, beispielsweise Patientendaten-Server (PDS), Fileserver, Programm-Server, EPR-Server und/oder RIS-Server zur Kommunikation mit den anderen Komponenten 5 bis 8, 11 und 13 über TCP/IP-Protokolle angeschlossen.

Der Bild- und Datenaustausch über das Kommunikationsnetz 9 erfolgt dabei nach dem DICOM-Standard, einem Industriestandard zur Übertragung von Bildern und weiteren medizinischen Informationen zwischen Computern, damit eine digitale Kommunikation zwischen Diagnose- und Therapiegeräten unterschiedlicher Hersteller möglich ist. An dem Kommunikationsnetz 9kann ein Netzwerk-Interface 13 angeschlossen sein, über das das interne Kommunikationsnetz 9 mit einem globalen Datennetz, beispielsweise dem World Wide Web verbunden ist, so dass die standardisierten Daten mit unterschiedlichen Netzwerken weltweit ausgetauscht werden können.

In der Fig. 2 ist ein Simulationskonzept für MR beschrieben, bei dem aus einer DICOM-Datenbank 14 DICOM Objekte, beispielsweise MR-Bilder, mittels einer CDF-Umsetzungsroutine 15 (create dicom file) Objekte in Plaintext erzeugt werden, die in einer CDF-Datenbank 16 zur Bearbeitung abgespeichert werden. Aus einer Termindatenbank 17 wird durch einen Patientenbrowser 18 eine Workliste ausgewählt und angezeigt, aus der ein Patient ausgewählt und durch Drücken eines Untersuchungs- Buttons in das Patientenregister 19 übernommen wird. Dabei werden die Daten des Patienten (SPS?) aus der Termindatenbank 17 ausgelesen. Neu erzeugte Objekte oder kopierte Objekte werden in eine Hauptdatenbank 20 abgelegt. Hiervon wird ein MPPS-Server 21 (Modality Performed Procedure Step) informiert. Anschließend wird die Akquisition 22 (ACQ) gestartet. Dabei werden aus der CDF-Datenbank 16 erforderliche durch die CDF-Umsetzungsroutine 15 gewandelte Bilder, sogenannte .cdf- Bilder, ausgelesen. In diese .cdf-Bilder werden beispielsweise die aktuellen Patientendaten eingebunden und in einem .cdf*-File 23 gespeichert. Nach Aufruf des Programmes .cdf.exe 24 werden die .cdf*-Files 23 zu .dicom-Files 25 konvertiert. Nun kann durch Starten des testTF-Programmes 26 der .dicom-File 25 zur Hauptdatenbank 20 importiert und abgespeichert werden.

Dieser DICOM-Editier-Service ermöglicht es als Internet/Intranet-Service also, DICOM-Bilder mittels einer Umsetzungsroutine 15 in Plaintext zu konvertieren. Nachdem man seine Textrepräsentation des Bildes mittels einer CDF-Befehlssprache editiert hat, konvertiert der DICOM-Editier-Service den Plaintext zurück in ein DICOM-Bild.

Der DICOM-Editier-Service weist folgende Eigenschaften auf:

  • - Er versteht die neueste MedCom DICOM Implementierung.
  • - Er arbeitet mit verschachtelten DICOM-Sequenzen.
  • - Er versteht private Gruppierungen.
  • - Er weist eine einfache (Kurze), jedoch starke Befehlssprache für maximale Editierungsfreiheit auf.
  • - Er ermöglicht die Kreation von nichtkonformen oder ganz artifiziellen DICOM-Bildern.
  • - Der DICOM-Editier-Service ist ein WEB-Interface, d. h. er benötigt keine Software oder Softwareverwaltung auf Client-Geräten.

Der erfindungsgemäße DICOM-Editier-Service ermöglicht einfaches Up- und Downloaden der Files vom Server. Die zum Server gesendeten Files (Upload) werden, falls möglich bzw. nötig, konvertiert. Nach dem Downloaden kann man die Files auf dem lokalen Gerät mit jedem bevorzugten Texteditor editieren.

  • - Falls der von dem Server geladene File mit einem ".dicom" endet, erzeugt der Service einen korrespondierenden ".cdf" File (create dicom file) und je einen Binärfile pro OB-, OW- und OL-Tag.

    mit

    OB = Other Byte (vom DICOM Standard), einem 8 bit Datentyp,

    OW = Other Word (vom DICOM Standard), einem 16 bit Datentyp und

    OL = Other Long (vom DICOM Standard), einem 32 bit Datentyp zur Speicherung jeglicher in DICOM definierter Daten.
  • - Falls der File mit ".cdf" endet, erzeugt der Service ein korrespondierendes DICOM-Bild. Die Binärfiles für OB, OW und OL-Tags müssen auf dem Server zur Verfügung stehen.
  • - Jeder File mit einer anderen Endung wird ohne weitere Aktionen geladen. Diese Möglichkeit kann dazu verwandt werden, die OB, OW und OL-Files zu editieren.

Mit einem Link auf diese Files im Server findet man upgeloadete und generierte Files. Man kann jeden File auf seinen PC durch Klicken auf den Link zurückholen. Nach der lokalen Editierung des Files kann dieser zurück auf den Server zur weiteren Verarbeitung geladen werden.

Erfindungsgemäß ist die sogenannte cdf-Sprache (cdf = create dicom file) eine einfache Befehlssprache, bei der lediglich ein Buchstabe den gewünschten Befehl bestimmt:

  • - mit dem Befehl s (setContentFromString) wird ein Wert aus einer Zeichenfolge (String) gesetzt,
  • - mit dem Befehl f (setContentFromFile) wird ein Wert aus einem Binärfile gesetzt,
  • - der Befehl o (openSQ) öffnet eine Sequenz von TAGs,
  • - der Befehl c (closeSQ) schließt eine Sequenz von TAGs,
  • - beginnt eine Zeile mit #, ist sie ein Kommentar,
  • - mit dem optionalen Befehl q werden keine Befehle mehr angezeigt.

Ein Ausführungsbeispiel ist im Anhang 2 angegeben.

Die vorliegende Erfindung erkennt und separiert die duale Natur des Standards, des Beschränkungsteils und des strukturellen Teils von DICOM. Auch ist der Standard weiterhin kompliziert wegen Irregularitäten, wie beispielsweise regressive Schachtelung von SQs, leeren SQs und vom Hersteller privat definierter Elemente.

Der Gegenstand vorliegender Erfindung erfordert lediglich eine Minimalsprache, um die Struktur und jede mögliche DICOM- Nachricht zu beschreiben. Sie besteht lediglich aus vier Basis-Sprachelementen [o, c, s, f]: openSQ, closeSQ, setContentFromString and setContentFromFile. Jedes Sprachmerkmal oder jeder Befehl nimmt einen TAG und, falls benötigt, einen Wert als Parameter. Die Sprache ist vollständig und flexibel genug, um jede DICOM-Message zu handhaben.

Die vorliegende Erfindung ist anwendbar auf verschiedene Gebiete in der Entstehung und Entwicklung von medizinischen Ausrüstungen und Systemen. Unter anderem sind dies DICOM-Editoren, Aquisationssimulatoren und Software-basierte Agenten oder Proxis, die DICOM-Nachrichten zum Kommunizieren oder Konvertieren zwischen Systemen mit verschiedenen Herstellern oder Systemen verschiedener Generationen, alten Systemen, benötigen.

Erfindungsgemäß lässt sich die Robustheit von DICOM-Implementierungen in medizinischen Geräten besonders leicht testen, da die Separation des Zwanges und der Struktur es möglich macht, beliebig komplizierte oder gar teilweise invalide DICOM-Nachrichten zu erzeugen.

Es ist weiterhin festzustellen, dass die vorliegende Erfindung lediglich zwei Wege benötigt, um Werte zu darzustellen:

  • 1. Der normale Weg verwendet Strings.

    Dies ist mit gemeinsamen Texteditoren kompatibel und ist der gemeinsamste Nenner für die meisten aller in DICOM definierten Datentypen.
  • 2. Der indirekte Weg führt die Sprache dazu, die Datenwerte von einem Fall zu lesen, einen Bit-Stream oder jeden anderen Datenwert zu handhaben, der nicht einfach durch einen String repräsentiert werden kann.

Weitere Primitive, wie Lösch- und Wiederhol-Befehle sind ausgelassen, da sie durch den Gebrauch der vier Basisprimitive implementiert werden können. Andere Befehle wie Debugging oder Kommentieren werden ebenfalls ausgelassen, da sie gewöhnlicherweise Teil einer Implementierung sind.

Im Anhang 2 ist ein Beispiel einer in dem DICOM Standard beschriebenen Waveform in der erfindungsgemäßen cdf-Befehlssprache angegeben.

Der Anhang 3 enthält einen example Code, der beschreibt, wie man eine ASCII-Repräsentation (CDF) in ein DICOM binär Format umwandeln kann.

Anhang 1 In der Beschreibung verwendete Abkürzungen CDF create dicom file

DICOM Digital Imaging and Communications in Medicine DICOM-Standard ist ein Industriestandard zur Übertragung von Bildern und weiteren medizinischen Informationen zwischen Computern zur Ermöglichung der digitalen Kommunikation zwischen Diagnose- und Theraphiegeräten unterschiedlicher Hersteller

EPR Electronic-Patient-Record (Elektronische Patienten Akte)

IE Information Entities (aus DICOM)

IOD Information Object Descriptor (aus DICOM)

MPPS Modality Performed Procedure Step

PACS Picture Archival and Communication System

RIS Radiologie Informationssystem (Radiology Information System):

Information System zum Daten-Management innerhalb der Radiologie Abteilung, das beispielsweise den Patienten Zugang, die Kreation von Worklisten, das Berichtswesen, Report Management, die Buchhaltung und das Rechnungswesen usw. unterstützt.

SQ Sequenz (aus DICOM). In der Beschreibung verwendete Befehle o openSQ,

c closeSQ,

s setContentFromString

f setContentFromFile

# Kommentarzeile

q Programmende Anhang 2



































Anhang 3
























































































Anspruch[de]
  1. 1. Verfahren zur Bearbeitung von Objekten eines standardisierten Kommunikationsprotokolls zum Bild- und Datenaustausch zwischen Vorrichtungen (1 bis 8, 11) über ein Kommunikationsnetz (9) mittels Bearbeitungsvorrichtungen (5 bis 8, 11), dadurch gekennzeichnet, dass die Objekte mittels einer Umsetzungsroutine (15) in einen reinen Textfile (Plaintext) konvertiert werden, in einer einfachen Befehlssprache bearbeitbar sind und anschließend in die Objekte zurückgewandelt werden,

    dass das Kommunikationsprotokoll das medizinische Kommunikationsprotokoll DICOM ist und die Objekte eines Kommunikationsprotokoll DICOM-Objekte sind und

    dass die Umsetzungsroutine (15) aus DICOM-Objekten neben dem Textfile je einen Binärfile pro Tag mit Binärdaten erzeugt und bei der Rückwandlung der Textfiles die Binärfiles für Tags mit Binärdaten verwendet.
  2. 2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass ein Tag mit Binärdaten ein OB-, OW- und/oder OL-Tag ist, die in je einen Binärfile umgesetzt werden, und dass die Binärfiles für OB, OW und OL-Tags bei der Rückwandlung verwendet werden.
  3. 3. Verfahren nach einem der Ansprüche 1 bis 2, dadurch gekennzeichnet, dass zur Bearbeitung der Objekte im Textfile mit einem Befehl s ein Wert aus einer Zeichenfolge (String) gesetzt wird.
  4. 4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass zur Bearbeitung der Objekte im Textfile mit einem Befehl f ein Wert aus einem Binärfile gesetzt wird.
  5. 5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass zur Bearbeitung der Objekte im Textfile mit einem Befehl o eine Sequenz von Identifizierungsmerkmalen (TAGs) geöffnet wird.
  6. 6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass zur Bearbeitung der Objekte im Textfile mit einem Befehl c eine Sequenz von TAGs geschlossen wird.
  7. 7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass zur Bearbeitung der Objekte im Textfile mit einem Befehl q die Befehlsfolge beendet wird.
  8. 8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass DICOM- Bilder als Objekte mittels einer CDF-Umsetzungsroutine (15) in einen .cdf-File als reinen Textfile und je einen Binärfile pro OB-, OW- und OL-Tag konvertiert werden, in eine cdf- Befehlssprache bearbeitbar sind und anschließend in die DICOM-Bilder zurückgewandelt werden.






IPC
A Täglicher Lebensbedarf
B Arbeitsverfahren; Transportieren
C Chemie; Hüttenwesen
D Textilien; Papier
E Bauwesen; Erdbohren; Bergbau
F Maschinenbau; Beleuchtung; Heizung; Waffen; Sprengen
G Physik
H Elektrotechnik

Anmelder
Datum

Patentrecherche

Patent Zeichnungen (PDF)

Copyright © 2008 Patent-De Alle Rechte vorbehalten. eMail: info@patent-de.com