Method for processing objects of a standardized communication protocol

[0001] 1. Field of the Invention

[0002] The present invention is directed to a method for processing objects of a standardized communication protocol for image and data exchange between devices via a communication network by means of processing devices. This image and data exchange can ensue as communication between medical devices with the communication protocol “Digital Imaging and Communication in Medicine” (DICOM).

[0003] 2. Description of the Prior Art

[0004] The book “Bildgebende Systeme für die medizinische Diagnostik”, edited by H. Morneburg, 3rd edition, 1995, pages 684ff, discloses medical system architectures, referred to as picture archival and communication systems (PACS), image viewing and image processing stations. These image processing stations, referred to as work stations, are connected to one another via an image communication network and to the remaining medical devices therein for calling patient data and images generated by imaging modalities.

[0005] This communication between medical systems and devices of different manufacturers via such an image communication network has become extremely important. The driving forces are cost reduction, quality enhancement and the ability to track and document medical information. In recent years, the medical communication standard DICOM 3.0 described in the aforementioned book on page 686 has become mature and widespread for manufacturers of medical devices and systems in order to send and receive digital images such as, for example, magnetic resonance, x-ray and ultrasound images.

[0006] New types of DICOM objects are continuously being added to the standard, and the standard itself is periodically reworked.

[0007] For example, every medical system and device that sends and receives DICOM messages has the following features:

• [0008] 1. The messages contain a block or a plurality of blocks of information.
• [0009] 2. Each block contains one or more information object descriptors (IOD).
• [0010] 3. Each IOD contains one or more information entities (IE).
• [0011] 4. Each IE contains one or more modules.
• [0012] 5. Each module contains one or more elements.
• [0013] 6. Elements can be simple elements or elements grouped in a container (sequence (SQ)).
• [0014] 7. SQs can contain simple elements or interleaved SQs of an arbitrary depth.

[0015] Simple elements are the smallest building blocks in DICOM. They are identifiable on the basis of a unique or (unambiguous) identification feature, what is referred to as an attribute tag.

[0016] Further, DICOM determines limitations of the messages: IODs have a one-time type identifier and a one-time event identifier. Newly developed IOD types are added to the standard. The IODs specify which modules must or can be contained in them. There is a global, expandable and overlapping set of modules from which the developers of the standard can select. A module specifies for each of its elements whether it can be empty or can have a zero value or can be omitted altogether. Dependencies between the elements within the modules exist. Mutual exclusions or inclusions are not unusual. Elements are also limited by virtue of a type defined in a type lexicon. Common types are coded strings or integer values. The standard also defines the multiplicity of the element values.

[0017] An object of the present invention is to provide a method of the type initially described that makes it possible to edit DICOM objects in a simple way and to construct artificial DICOM objects in order to be able to easily test medical systems or devices with new DICOM objects or in order to be able to easily test the readiness of the systems or devices with respect to modified or invalid DICOM objects.

[0018] This object is inventively achieved in a method wherein the objects are converted with a conversion routine into a pure text file (plain text), can be processed in a simple command language and are subsequently converted back into the objects, with the communication protocol being the medical communication protocol DICOM, and the objects of the communication protocol being DICOM objects, and wherein the conversion routine generates a respective binary file per tag with binary data in addition to the text file from the DICOM objects, and employs the binary files for tags with binary data in the re-conversion. Flexible editing, scripting and interactive communication possibilities in DICOM thus are obtained. As a result of the inventive method, an object can be optimally presented, for example an MR image can be edited in a simple way. By using a minimal language for describing each DICOM object to be represented, the inventive requirement for easy constructability is optimally met.

[0019] A tag with binary data can be a tag from the family OB, OW, OL, FL and/or FD tags that are converted into respective binary files, and the binary files for the OB, OW, OL, FL and/or FD tags are employed in the re-conversion.

[0020] An especially simple command language is obtained by setting a value from a string for processing the objects in the text file with a command s, setting a value from a binary file with a command f, opening a sequence of identification features (TAGs) with a command o and/or closing a sequence of TAGs with a command q. The command sequence can be ended with a command q.

[0021] It has proven advantageous when DICOM images are converted with a CDF conversion routine into a .cdf file as the pure text file and a respective binary file per OB, OW and OL tag. This allows the images to be processed in a cdf command language and subsequently converted back into the DICOM images.

[0024] FIG. 1 shows the system architecture of a hospital network as an example. The modalities 1 through 4 serve for acquiring medical images (image-generating systems) for example, a CT unit 1 for computed tomography, an MR unit 2 for magnetic resonance, a DSA unit 3 for digital subtraction angiography and an x-ray unit 4 for digital radiography. Control panels 5 through 8 of the modalities or workstations are connected to these modalities 1 through 4, the acquired medical images being processed and being able to be locally stored therewith. Patient data belonging to the images can also be entered.

[0025] The control panels 5 through 8 are connected to a communication network 9 as a LAN/WAN backbone for the distribution of the generated images and for communication. Thus, for example, the image is generated in the modalities 1 through 4 and the images further processed in the control panels 5 through 8 can be deposited in the central image store and image archiving system 10 or can be forwarded to other workstations.

[0026] Further viewing workstations 11 as diagnostic consoles are connected to the communication network 9, having local image stores. Such a viewing workstation 11 is, for example, a very fast mini-computer on the basis of one or more fast processors. The acquired images that are deposited in the image archiving system 10 can be subsequently called in the viewing workstations such as a workstation 11 for diagnosis and can be deposited in the local image store, from which they are immediately available to the diagnostician working at the viewing workstation 11.

[0027] Further, servers 12, for example patient data servers (PDS), file servers, program servers, EPR servers and/or RIS servers, are connected to the communication network 9 for communication with other components 5 through 8, 11 and 13 via TCP/IP protocols.

[0028] The image and data exchange via the communication network 9 thereby ensues according to the DICOM standard, a standard for the transmission of images and other medical information between computers, so that digital communication is possible between diagnostic and therapy devices of different manufacturers. A network interface 13 can be connected to the communication network 9, the internal communication network 9 being connected via the network interface 13 to a global data network, for example the worldwide web, so that the standardized data can be exchanged worldwide with different networks.

[0029] FIG. 2 shows a simulation concept for MR, wherein objects in plain text (DICOM objects) for example MR images, from a DICOM data bank 14 are generated with a CDF conversion routine 15 (create DICOM file), said objects being stored in a CDF data bank 16 for processing. A work list schedule from a deadline data bank 17 is selected and displayed by a patient browser 18, a patient being selected therefrom and being transferred into the patient register 19 by pressing an examination button. The data of the patient are thereby read out from the deadline databank 17. Newly generated objects or copied objects are deposited in a main databank 20. An MPPS server 21 (Modality Performed Procedure Step) is informed of this. Subsequently, the acquisition 22 (ACQ) is started. Required images converted by the CDF conversion routine 15, what are referred to as .cdf images, are thereby readout from the CDF databank 16. For example, the current patient data are linked into these .cdf images and are stored in a .cdf* file 23. After calling the program .cdf.exe 24, the .cdf* files 23 are converted into .dicom files 25. By starting the test TF program 26, the .dicom file 25 can be imported to the main databank 20 and stored.

[0030] This DICOM editing service, as an Internet/Intranet service, thus makes it possible to convert DICOM images into plane text with a conversion routine 15. After the text representation of the images has been edited with a CDF command language, the DICOM editing service converts the plane text back into a DICOM image.

[0031] The DICOM editing service has the following properties:

• • [0032] It understands the newest MedCom DICOM implementation.
  • [0033] It works with interleaved DICOM sequences.
  • [0034] It understands private groupings.
  • [0035] It comprises a simple (short) but strong command language for maximum editing freedom.
  • [0036] It enables the creation of non-conforming or entirely artificial DICOM images.
  • [0037] The DICOM editing service is a WEB interface, i.e. it requires no software or software administration on client devices.

[0038] The inventive DICOM editing service enables simple uploading and downloading of the files from the server. The files sent to the server (upload) are converted if possible or, respectively, necessary. After the downloading, the files can be edited on the local device with any preferred text editor.

• • [0039] When the file loaded from the server ends with a “.dicom”, the service generates a corresponding “.cdf” file (create dicom file) and a respective binary file per OB,
  • [0040] OW and OL tag.
    • [0041] with
  • [0042] OB=other byte (from the DICOM Standard), an 8-bit data type,
  • [0043] OW=Other word (from DICOM standard), a 16-bit data type, and
  • [0044] OL=Other long (from DICOM standard), a 32-bit data type for storing any data defined in DICOM.
  • [0045] When the file ends with “.cdf”, the service generates a corresponding DICOM image. The binary files for OB, OW and OL tags must be available on the server.
  • [0046] Each file having a different extension is loaded without further actions. This possibility can be employed for editing the OB, OW and OL files.

[0047] Uploaded and generated files are found with a link onto these files in the server. Any file can be brought back to the PC by clicking onto the link. After the local editing of the file, this can be loaded back onto the server for further processing.

[0048] Inventively, the cdf language (cdf=create dicom file) is a simple command language, whereby only a single letter determines the desired command:

• • [0049] with the command s (setContentFromString), a value is set from a string,
  • [0050] with the command f (setContentFromFile), a value from a binary file is set,
  • [0051] the command o (openSQ) opens a sequence of tags,
  • [0052] the command c (closeSQ) closes a sequence of tags,
  • [0053] when a line begins with #, it is a commentary,
  • [0054] no further commands are displayed with the optional command q.
    An exemplary embodiment is set forth in Appendix 2.

[0055] The present invention recognizes and separates the dual nature of standard, the limitation part and the structural part of DICOM. The standard is also complicated by irregularities such as, for example, regressive nesting of SQs, empty SQs and elements privately defined by the manufacturer.

[0056] The method of the invention merely requires a minimum language in order to describe the structure at every possible DICOM message. It is composed only of four basic language elements [o, c, s, f]: openSQ, closeSQ, setContentFromString and setContentFromFile. Each language feature or each command takes a tag and, if required, a value as parameter. The language is complete and flexible enough in order to handle any DICOM message.

[0057] The present invention can be applied to different fields in the creation and development of medical equipment and systems. Among other things, these are DICOM editors, acquisition simulators and software-based agents or proxies that require DICOM messages for communication or conversion between systems having different manufacturers or systems of different generations, old systems.

[0058] Inventively, the readiness of DICOM implementations in medical devices can be tested in an especially easy way, since the separation of the compulsion and the structure makes it possible to generate DICOM messages that are arbitrarily complex or are even partially invalid.

[0059] It should also be noted that the present invention requires only two ways of presenting values:

• [0060] 1. The normal way employs strings.

[0061] This is compatible with common text editors and is the most common denominator 4 most of all data types defined in DICOM.

• [0062] 2. The indirect way leads the language to read the data values from a case, to be handled a bit stream or any other data value that cannot be simply represented by a string.

[0063] Further primitives such as delete and repeat commands are omitted since they can be implemented by using the four basic primitives. Other commands such as debugging or commenting are likewise omitted since they are usually part of an implementation.

[0064] Appendix 2 is an example of a waveform described in the DICOM standard in the inventive cdf command language.

[0065] Appendix 3 shows an example code that describes how an ASCII representation (CDF) can be converted into a DICOM binary format.

[0066] Although modifications and changes may be suggested by those skilled in the art, it is in the intention of the inventor to embody within the patent warranted hereon all changes and modifications as reasonably and properly come within the scope of his contribution to the art.