What DICOM elements should I modify in a new DICOM dataset derived from an existing one?
r.h...@umontreal.ca
I have an application that reads DICOM data containing MRI scans,
performs some calculations, and generates a new dataset based on the
input. I need to write these output dataset to disk, and would like
to generate correct DICOM files. I am able to create files that can
be loaded by several DICOM viewers, but am trying to figure out the
'correct' way to propagate (and modify) the header information from
the original input.
So here are my specific questions:
) is it correct to copy all the elements from the input, and change
the small set needed to make the new series unique?
) what is the minimal set of elements that need to be changed to
indicate that this new series is distinct from the input series?
) how should I convey the fact that the new dataset is derived from
the input series?
) should the SeriesInstanceUID value be different for the input and
output?
Thank you in advance for any information you can provide -
Rick Hoge
Mathieu Malaterre
Hi Rick,
I wrote a couple of notes (+Eric Goodall comments) about DERVIED
DICOM datasets at:
http://gdcm.sourceforge.net/wiki/index.php/Writing_DICOM#Derived_DICOM_Images
HTH
-Mathieu
r.h...@umontreal.ca
> HTH
It does - thank you very much. R
r.h...@umontreal.ca
Hi Mathieu,
I saw in your notes (and it makes sense) that the Series Instance UID
should be changed for the derived dataset.
I realize this is an incredibly naive question, but what is the right
way to generate a new UID? I could imagine doing this by - say -
appending the computer serial number plus date and time of compuation
to the millisecond to the existing UID. Are there any recommended or
mandated approaches?
Thanks again!
Rick
Mathieu Malaterre
I would suggest you read this thread:
http://groups.google.com/group/comp.protocols.dicom/browse_frm/thread/1caaae92e256f0c1
There is a freely available (BSD-license) UID generator in GDCM if you
are not afraid of C++. But anyway keep in mind that is is a good UID
generator and definitely far from perfect since I will never be able
to claim uniqueness with this approach, only private vendor with
hardware solution or a way to centralize all UID can.
HTH
-Mathieu
eric.g...@gmail.com
wrote:
> On Feb 13, 12:03 am, r.h...@umontreal.ca wrote:
>
> > Hi Mathieu,
>
> > I saw in your notes (and it makes sense) that the Series Instance UID
> > should be changed for the derived dataset.
>
> > I realize this is an incredibly naive question, but what is the right
> > way to generate a new UID? I could imagine doing this by - say -
> > appending the computer serial number plus date and time of compuation
> > to the millisecond to the existing UID. Are there any recommended or
> > mandated approaches?
>
> I would suggest you read this thread:
>
>
> There is a freely available (BSD-license) UID generator in GDCM if you
> are not afraid of C++. But anyway keep in mind that is is a good UID
> generator and definitely far from perfect since I will never be able
> to claim uniqueness with this approach, only private vendor with
> hardware solution or a way to centralize all UID can.
>
> HTH
> -Mathieu
Couple points on this thread - first regarding unique UIDs. Generating
a unique UID value is not sufficient. It must be well formed relative
to the rules defined in DICOM part 5, section 9. Quoting from that
section
Each UID is composed of two parts, an <org root> and a <suffix>:
UID = <org root>.<suffix>
The <org root> portion of the UID uniquely identifies an organization,
(i.e., manufacturer, research organization, NEMA, etc.), and is
composed of a number of numeric components as defined by ISO 8824. The
<suffix> portion of the UID is also composed of a number of numeric
components, and shall be unique within the scope of the <org root>.
This implies that the organization identified in the <org root> is
responsible for guaranteeing <suffix> uniqueness by providing
registration policies. These policies shall guarantee <suffix>
uniqueness for all UID's created by that organization. Unlike the <org
root>, which may be common for UID's in an organization, the <suffix>
shall take different unique values between different UID's that
identify different objects.
Some time ago, a poster to this forum complained that a major vendor's
system was rejecting their images with an "invalid UID" message. While
one interpretation of the above rules says that you can be your own
<org root> as long as you guarantee uniqueness, another school of
thought, and codified by the OID rules in HL7 says that your <org
root> has to be derived from a registering authority - so for example
the DICOM standard <org root> of "1.2.840.10008" is actually derived
from NEMA having registered and licensed their 10008 identifier from
ANSI, who own the 1.2.840 <org root>.
Bottomline - don't simply generate UIDs. You need to base it off
somebody's root. There are several organizations out there who will
give you a piece of their UID namespace for free - Dave Harvey of
Medical Connections in the UK was handing them out for a while. I
believe I've seen others offering the same service in this group.
My second point has to do with the earlier string of the thread. The
information in Mathieu's wiki is accurate, but there is some
additional information you might want to consider putting into your
derived. DICOM Part 16 has two Context Groups CID 7202 and CID 7203
which contain a set of codes defining reason for a source image
reference (ie. reason code for referenced image sequence) and a coded
description of the deriation applied to the new image data from the
original. Both these context groups are extensible, so if you don't
see what you're doing here, add your own code but still identify the
context group that you're adding it into.
CID 7202 Source Image Purposes of Reference
Context ID 7202
Source Image Purposes of Reference
Type: Extensible Version: 20051101
Coding
Scheme Code
Designator Value Code Meaning
DCM 121320 Uncompressed predecessor
DCM 121321 Mask image for image processing operation
DCM 121322 Source image for image processing operation
DCM 121329 Source image for montage
DCM 121330 Lossy compressed predecessor
CID 7203 Image Derivation
Context ID 7203
Image Derivation
Type: Extensible Version: 20050822
Coding
Scheme
Designator Code Meaning
DCM 113040 Lossy Compression
DCM 113041 Apparent Diffusion Coefficient
DCM 113042 Pixel by pixel addition
DCM 113043 Diffusion weighted
DCM 113044 Diffusion Anisotropy
DCM 113045 Diffusion Attenuated
DCM 113046 Pixel by pixel division
DCM 113047 Pixel by pixel mask
DCM 113048 Pixel by pixel Maximum
DCM 113049 Pixel by pixel mean
DCM 113050 Metabolite Maps from spectroscopy data
DCM 113051 Pixel by pixel Minimum
DCM 113052 Mean Transit Time
DCM 113053 Pixel by pixel multiplication
DCM 113054 Negative Enhancement Integral
DCM 113055 Regional Cerebral Blood Flow
DCM 113056 Regional Cerebral Blood Volume
DCM 113057 R-Coefficient Map
DCM 113058 Proton Density map
DCM 113059 Signal Change Map
DCM 113060 Signal to Noise Map
DCM 113061 Standard Deviation
DCM 113062 Pixel by pixel subtraction
DCM 113063 T1 Map
DCM 113064 T2* Map
DCM 113065 T2 Map
DCM 113066 Time Course of Signal
DCM 113067 Temperature encoded
DCM 113068 Student's T-Test
DCM 113069 Time To Peak map
DCM 113070 Velocity encoded
DCM 113071 Z-Score Map
DCM 113072 Multiplanar reformatting
DCM 113073 Curved multiplanar reformatting
DCM 113074 Volume rendering
DCM 113075 Surface rendering
DCM 113076 Segmentation
DCM 113077 Volume editing
DCM 113078 Maximum intensity projection
DCM 113079 Minimum intensity projection
DCM 113085 Spatial resampling
DCM 113086 Edge enhancement
DCM 113087 Smoothing
DCM 113088 Gaussian blur
DCM 113089 Unsharp mask
DCM 113090 Image stitching