Talk:DICOM

This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Medicine Low‑importance This article is within the scope of WikiProject Medicine, which recommends that medicine-related articles follow the Manual of Style for medicine-related articles and that biomedical information in any article use high-quality medical sources. Please visit the project page for details or ask questions at Wikipedia talk:WikiProject Medicine.MedicineWikipedia:WikiProject MedicineTemplate:WikiProject Medicinemedicine articles Low This article has been rated as Low-importance on the project's importance scale. Computing: Networking Low‑importance This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles Low This article has been rated as Low-importance on the project's importance scale. This article is supported by Networking task force (assessed as Low-importance).

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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. 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))[reply]
[I have marked the key concepts in bold to improve readability at a glance, and trust that ObjectForge will not mind. —DIV (137.111.13.4 (talk) 02:24, 7 May 2020 (UTC))][reply]

Over on [Medical Imaging], we found these four links that clearly fit your category better:

• Trial Wire - Free DICOM tool to transfer and anonymize DICOM files....
• MicroDicom - Free DICOM viewer for Windows
• SureVistaVision - Multi-platform DICOM viewer.
• OsiriX - OsiriX Open Source DICOM Viewer

If you guys want to keep, alter, or dump... be our guests.  :)

FreedomWorks! (talk) 15:06, 17 August 2009 (UTC)[reply]

Everything that's relevant is welcome (I think), but please talk about the relevance inline . Wikipedia is no external link collection, whatever the spammers might try (even here.) –Be..anyone (talk) 06:33, 2 March 2014 (UTC)[reply]

Paragraph "Off-line Media (DICOM Files)" states both that "DICOM restricts the filenames on DICOM media to 8 characters (some systems wrongly use 8.3, but this is not legal)." and "DICOM files typically have a .dcm file extension." This seems be a contradiction? Supermagle (talk) 07:50, 28 May 2010 (UTC)[reply]

This reflects the common practice to use files that comply with the DICOM media standard rules for encoding of files, in a file system structure that is not off-line media. The 8 character restriction deals with the vagaries of different offline media file system restrictions, patents, etc. Many operating systems use extensions to determine application binding. So while adding an extension violates the strict rules of the off-line media file structure, it has practical advantages for on-line use of the files. — Preceding unsigned comment added by 108.1.135.199 (talk) 20:49, 13 August 2011 (UTC)[reply]

Most modern CT scanners are capable of what is referred to as helical scanning, where the scanning system spins in a continuous circular motion, while the subject material advances through the scanner in a steady, continuous linear motion.

The smooth motions of helical scanning appear to prevent wobbling or shaking of the subject matter as would occur with stepper motors, which would require settling time between each step to bring the subject to rest.

The combined data from this circular and linear motion is referred to as a helical scan, and it has the general shape of a highly twisted continuous pasta noodle.

DICOM meanwhile appears to define simple planar scan surfaces or "slices".

Is imaging data being lost in the conversion between the helical scan and DICOM? Can helical scans be preserved in their original complex 3D twisted state using DICOM, or do helical scans need to be saved in their own custom data format to preserve the maximum detail from the scanning process?

DMahalko (talk) 16:25, 3 July 2011 (UTC)[reply]

DICOM is a format for reconstructed images. Helical cone beam CT data is usually stored in a proprietary format determined by the manufacturer and in my experience working in medical, materials science and airport baggage CT one needs to be fairly close to the manufacturer before they will tell you enough about the format to actually do the reconstruction. You also need to know loads of information about the geometry, helical pitch, calibration etc before you can do anything useful with it. Remember that reconstruction algorithms reconstruct volume data. The crudest FDK on transaxial slices do reconstruct slices which I suppose goes straight in to DICOM, but other algorithms reconstruct on tilted slices, surfaces or directly to a 3D volume. Are you really asking if DICOM can handle tilted slices? Billlion (talk) 08:36, 5 July 2011 (UTC)[reply]

So basically helical scan data is not preserved in DICOM, and the conversion may result in loss of scan data and generation of nonexistent averaged fill data.

Since DICOM is a grid and helical scan is a pasta noodle (that's a technical term), apparently there can be locations on a DICOM grid where a helical scan contains no data. In such a case, it sounds like the helical data from nearby samples is averaged into a 3D voxel that wasn't recorded and isn't actual valid sample data.

Can DICOM handle "no data" locations in its dot matrix grid? DMahalko (talk) 21:23, 14 April 2012 (UTC)[reply]

DMahalko, the reconstruction is done in three dimensions to produce a solid three dimensional volume, whose typical intersection with perpendicular plane is a two-dimensional solid disc (or solid ellipse for a tilted plane), so there is no relevance to the mathematical intersection between a helical 'pasta' spiral and a plane (which would be a one-dimensional straight line in the plane).

Handling 'missing' data should not be a problem. For example, for dates if the day or month is not known, then NULL is entered [1]. For entire attributes, if there is no data, where appropriate they can be left empty (zero-length) [2]. For portions of an array, as you were primarily interested in, it can be encoded any way that one wants (not specified by the DICOM standard), such as with "0" or "-9999" or "" (empty), AFAIK.

—DIV (137.111.13.4 (talk) 02:44, 7 May 2020 (UTC))[reply]

This article covered most aspects of DICOM, however, it did not mentioned the market and users to demonstrate the trend of usage.

users

• American Academy of Ophthalmology
• American Academy of Oral and
• Maxillofacial Radiology
• American Association of Orthodontists
• American Association of Physicists in
• Medicine (AAPM)
• American College of Cardiology
• American College of Radiology
• American College of Veterinary Radiology
• American Dental Association
• Brazilian College of Radiology (CBR)
• College of American Pathologists
• Deutsche Roentgengesellschaft
• European Federation of Organizations for Medical Physics (EFOMP)
• European Society of Cardiology
• European Society of Radiology
• Medical Image Standards Association of Taiwan
• RadiologicalSociety of North America
• Société Française de Radiologie
• Society for Imaging Informatics in Medicine
• Spanish Health Informatics Society
• Institute of Materials Malaysia — Preceding unsigned comment added by 121.121.9.29 (talk) 08:40, 30 September 2014 (UTC)[reply]

manufacturers

• AGFA Healthcare
• Bayer Radiological and Interventional
• Boston Scientific
• Carestream Health
• Carl Zeiss Meditec
• CoreLab Partners
• Corista
• DatCard Systems
• DeJarnette Research Systems
• ETIAM
• FUJIFILM Medical Systems U.S.A., Inc.
• GE Healthcare
• Harris HealthcareSolutions
• Hologic
• Konica Minolta Medical Corporation
• McKesson Medical Imaging Company
• MEDIS
• Merge Healthcare
• Microsoft
• Panasonic Healthcare
• Philips Healthcare
• Sectra Imtec AB
• Siemens Healthcare
• Sony
• SuperSonic Imagine
• Toshiba America Medical Systems
• Topcon Healthcare — Preceding unsigned comment added by 188.127.218.214 (talk) 09:54, 26 February 2024 (UTC)[reply]
• Varian Medical Systems

reference http://medical.nema.org/members.pdf — Preceding unsigned comment added by X22yang (talk • contribs) 07:15, 31 March 2013 (UTC)[reply]

This article is the subject of an educational assignment at La Trobe University supported by the Wikipedia Ambassador Program during the 2013 Q1 term. Further details are available on the course page.

Above message substituted from {{WAP assignment}} on 14:03, 7 January 2023 (UTC)

Hi Enzo, I think you touch on some really nice ideas in your part. The idea of comparing DICOM and HL7 is brilliant. The title summarises the key points of this section. The structure is clear, but maybe you can try to put some of your ideas in dot points. For example, the third paragraph of DICOM and HL7, try to put your points into dot points rather than listing with numbers would be better. Plenty of footnotes and the references are from reliable sources. One more suggestion, maybe you can try to put [[ ]] for the terms that wiki has an article on, so that people can click it and easily go to that article. For example, HL7. Also, try to make your article title consistent with the whole wiki page: DICOM and HL7. — Preceding unsigned comment added by ChaoDOU (talk • contribs) 10:48, 19 May 2013 (UTC)[reply]

This article is the subject of an educational assignment at La Trobe University supported by the Wikipedia Ambassador Program during the 2013 Q1 term. Further details are available on the course page.

Above message substituted from {{WAP assignment}} on 14:03, 7 January 2023 (UTC)

Hi Enzo, Thanks for your contribution to DICOM. You added a great part, and provide readers really valuable information from another angle. Personally, you use very clear and simple language to explain a complex theory to a variety of different readers. However, as for me, it is better to add more information to explain their differences and relations. I am also interested in interfaces between them. This would be one of relations between them. If you explain the comparison or relationships between them by using a application instance in health services, that would be perfect! Above all, this part integrates my knowledge of DICOM. Thanks for you contribution. Fan Zhang-IHC (talk) 12:43, 19 May 2013 (UTC)[reply]

"Parts of the standard" is its own section? Could it go into the external links section? Hza a 9 (talk) 20:04, 10 February 2015 (UTC)[reply]

"It is not a framework or architecture for achieving a useful clinical workflow. RSNA's Integrating the Healthcare Enterprise (IHE) initiative layered on top of DICOM (and HL-7) provides this final piece of the medical imaging interoperability puzzle." This is not the only available library or application providing a clinical workflow layer on top of DICOM. Should it say one option, or better yet, not mention IHE at all? 204.187.11.131 (talk) 10:49, 7 April 2015 (UTC)[reply]

The latest DICOM specs are in 2015. The article still links to 2007 and 2011 specs.

I like Irfanview, so I tried to look at Dicom images with Irfanview. I couldn’t get it to work. The standard Irfanview needs extra extensions to see Dicom, and do not mix 32 and 64 bit versions. Even with installed extensions, apparently including Dicom, Irfanview won’t recognize a Dicom file or directory, as no file extension (like .jpg) is used. A Sam Zen https://irfanview-forum.de/showthread.php?t=2960 repeates: “DICOM.DLL - This PlugIn allows IrfanView to read Dicom medical files. … Note: DICOM/ACR/IMA format hasn't a specific header and IrfanView can't recognize all such images. If you want to read Dicom/ACR/IMA images with IrfanView, the file extension MUST BE ".dcm", ".acr" or ".ima"!” – Fritz Jörn (talk) 04:44, 15 September 2018 (UTC)[reply]

The article currently says " for VRs that are not OB, OW, OF, SQ, UT, or UN,", but none of the latter should be assumed to be known by all readers, and none are explained in the article. —DIV (137.111.13.4 (talk) 02:14, 7 May 2020 (UTC))[reply]