Talk:Digital Imaging and Communications in Medicine

From Wikipedia, the free encyclopedia

Looking at the log it seems the image is coming from:

 http://www.dicom-solutions.com/sample/

Is it ok not to referenced the orginal file.

Also the jpg is extracted from the DICOM file, why not referenced directly the original file, which would make more sense.

I am changing "set of standards" to "standard" since the DICOM committee itself refers to it as the "DICOM standard" (see the DICOM Strategic Document.) MrSerif 15:33, 29 December 2006 (UTC)

Contents 1 DICOM Data Format 2 Service Classes 3 Application protocol? 4 List of modalities 5 General Comments

[edit] DICOM Data Format

Is it strictly correct to say "DICOM files consist of a header with standardized and free-form fields, and a body of image data"? That is, I thought that there isn't really a header -- just a collection of attributes, some of which contain data that would normally appear in a header and typically one notable one (!) that contains the image data.

Agreed and now done Medconn 13:20, 31 December 2006 (UTC)

[edit] Service Classes

I think this is totally wrong: "DICOM is categorized into two different transmissions; DICOM Store and DICOM Print."

Why just two? Aren't there lots of service classes:

• Verification Service Class
• Storage Service Class
• Query/Retrieve Service Class
• Study Content Notification Service Class
• Patient Management Service Class
• Study Management Service Class
• Results Management Service Class
• Print Management Service Class
• Media Storage Service Class
• Storage Commitment Service Class
• Basic Worklist Management Service Class
• Queue Management Service Class

Yes, though many have never beed used - the major ones are now listed on the main page Medconn 13:20, 31 December 2006 (UTC)

Are they? I only find the very confusing section heading "DICOM Services". When I hear DICOM Services I only think of DIMSE Service (like C-STORE and N-GET). I think we should rename this section "DICOM Service Classes" and give each subsection it proper Service Class name. Alternively we should replace "services" in the heading with something else, like "features". Kr-val 13:30, 4 January 2007 (UTC)

[edit] Application protocol?

Is it true that: "This protocol is an application protocol, it uses TCP/IP to communicate between systems."

Doesn't DICOM specify all of the upper-layer protocols, including application layer, presentation layer, and session layer?

In TCP/IP, there is only an application layer. Application, presentation, & session are in the OSI model, not TCP/IP. Cburnett 02:14, 27 April 2006 (UTC)

And the OSI model has now been officialy retired (at last!) Medconn 14:21, 13 July 2006 (UTC)

[edit] List of modalities

The list of modalities takes up a very large proportion of the article, and adds very little ot the value - should it be removed? Medconn 12:21, 31 December 2006 (UTC)

I gives some insight in what areas DICOM can be applied, but I definitely agree that it is way too long. And it definitely does not fit into the history section. Maybe we could pic only a few? Btw, I plan to add some more info into the history section. Kr-val 13:09, 4 January 2007 (UTC)

[edit] General Comments

I think there are several holes in the history, there were at least two other companies that produced and successfully marketed the 50 PIN interface (I used to work for one of them). And if we are in the space of naming contributors one needs to mention the two CTN implementations for the 1993 RSNA demonstration. One built by Mallinckrodt institute (http://erl.wustl.edu/research/dicom/ctn.html)and the other by Oldenburg university (http://dicom.offis.de/dcmtk). If you want to be charitable you also should mention Steve More and Dr. Marco Eichelberg. The rest is history.

The extensions developed by Philips and Siemens diverged very quickly, and SPI implementations between the companies were not compatible, I would not even bother mentioning them because they were just as inbreed as ODINA developed by GE. BTW ODINA was a forerunner of DICOM, it was the CT to console protocol used internally by GE.

I would also like to point out that the DICOM SDO does not operate like most SDOs. WG6 is sort of a technical oversight committee that manages the release and editing of the entire standard. Usually a working group is created to cover a particular aspect of the standard, a new SOP class, or in case of Structured reporting a new set of templates.

Concerning the DICOM Data format…. I think it is partially misleading to characterize DICOM data sets as just data sets. The DICOM data fall into one of two categories, composite objects and normalized objects. Composite objects are invariant objects identifiable by embedded UIDs that locate the object in the DICOM real world model. Normalized objects are more like HL7 messages used to communicate a particular state of the object repositories, or connect composite objects to other domains like HL7. When we talk about composite objects we need to look at them as structured documents more like an HL7 CDA document, but with tighter controls on the content. Each DICOM object (composite and normalized) is controlled by the IOD definitions detailed in Parts 3 and 4. One could look part 3 and 4 as the DTD in XML except not in a computable format. (In reality there is a current work item of transcoding DICOM SR into CDA which would effectively put the DICOM IOD definitions into a DTD, but that would be an entirely different discussion.)

So in more accessible terms the DICOM data format is a database on a wire. The encoding is pretty arcane and binary, and it also is dependent on the transfer syntax, but in general it follows the

<tag><[Value Representation(VR)]><length><data>

pattern. The VR is optional because it only appears in explicit VR transfer syntaxes.

The DICOM header is also split into modules; each IOD may contain mandatory or optional modules, within the modules tags may be required, optional or conditionally required. (And we refer to the header as the information preceding the pixel data, not the command group or the file metaheader.) When a DICOM message is written to disk or media the entire header and the pixel data is written to the disk. Depending of the level of a DICOM archive the original image may be preserved bit for bit and retrieved, or attributes may be coerced as needed, but in that case for a level 2 archive it is required that the source of the image is notified of this action.

I am confused as to what you mean that a DICOM object contains no header. When transmitted over a DICOM association there is a command group (tags 0000xxxx) that precede the actual object. BTW there might be more attributes that contain pixel data like the Icon Image Sequence. There is nothing special about the pixel attribute other than it can be big, so is any other tag with a value representation of Unlimited Text (UT).

I also find your distinction of frame and image a bit hard to get. So let me see if I can get it. If I use a single frame CT object to encode a CT study I have say 50 IODs and in your nomenclature 50 images, if I use the new multiframe CT object to send the same CT study I somehow lost 49 of those images because they became frames of the object? That is how I read it; in essence you did a semantic conversion between frames and images. I am not following you. In my vocabulary frames and images are the same concepts just encoded differently.

DICOM has specified compressed transfer syntaxes from its very early versions. Nothing but the pixel data gets compressed and it can be lossy or lossless compression. The encoding uses encapsulation. Using LZW on DICOM images is a bad idea. RLE can be used as the final encoding as opposed to Huffman encoding as part of standard JPEG where the data is first moved into the frequency domain using DCT. But there is no prescribed transfer syntax using RLE as the only compression method. Lossless compression reduces DICOM image sizes on average by a factor 2 to 3. Some SOP classes compress better because of the large collimation regularly used in those images. Compressing DICOM headers is not very important they are very small compared to most DICOM images.

On DICOM services:

You are missing the General Purpose Worklist and General Purpose Performed Procedure Step services. They are becoming very important tools to manage scheduled workflow for specialty devices, such as 3D workstations, image guided surgery, or radiation therapy devices.

As far as offline storage: it would be more important to concentrate on Part 11: Media Storage Application Profiles. It not only uses part 10 as the underlying mechanism to specify file system creator and reader behavior but also defines what information is required for a specific application of the exchange media.

And since you dragged IHE into this, there is very little or nothing about that in the Wikipedia.

Applications:

I do not think that the list of enumerated value of the modality attribute is it. I think it deserves a serious discussion of the field of medical imaging and how DICOM is used.

The sample would be a better if you had a DICOM header dump….

So much for now…I will think of other stuff, maybe get David Clunie to look at your page as well. I do not think one can put DICOM in a nutshell, it is way too big :-)

dee

-D

(ObjectForge 14:14, 25 April 2007 (UTC))