Writing DICOM

From GDCM Wiki
Jump to: navigation, search

When it comes to writting DICOM there are a couples of things to know:

Contents

Converting Acquired Image to DICOM

This is the easy case. You have a -let say- a raw volume that can not be easily read in other application, all you want to do is create the DICOM Series equivalent to this volume. In this case you can store the SOP Class and Modality to be the proper one. Then you need to make sure to fill in all the proper DICOM Tags needed for the SOP Class you are generating. Eg. Let say this is a CT:

# Dicom-Meta-Information-Header
# Used TransferSyntax: LittleEndianExplicit
(0002,0000) UL 194                                      #   4, 1 MetaElementGroupLength
(0002,0001) OB 00\01                                    #   2, 1 FileMetaInformationVersion
(0002,0002) UI =CTImageStorage                          #  26, 1 MediaStorageSOPClassUID
(0002,0003) UI [1.2.826.0.1.3680043.2.1125.1.75064541463040.2005072610204923341] #  64, 1 MediaStorageSOPInstanceUID
(0002,0010) UI =LittleEndianExplicit                    #  20, 1 TransferSyntaxUID
(0002,0012) UI =SecondaryCaptureImageStorage            #  26, 1 ImplementationClassUID
(0002,0016) AE [GDCM]                                   #   4, 1 SourceApplicationEntityTitle

# Dicom-Data-Set
# Used TransferSyntax: LittleEndianExplicit
(0008,0008) CS [ORIGINAL\PRIMARY\AXIAL]                 #  22, 3 ImageType
(0008,0012) DA [20050726]                               #   8, 1 InstanceCreationDate
(0008,0013) TM [102049]                                 #   6, 1 InstanceCreationTime
(0008,0016) UI =CTImageStorage                          #  26, 1 SOPClassUID
(0008,0018) UI [1.2.826.0.1.3680043.2.1125.1.75064541463040.2005072610204923341] #  64, 1 SOPInstanceUID
(0008,0020) DA [20050101]                               #   8, 1 StudyDate
(0008,0030) TM [010100.000000]                          #  14, 1 StudyTime
(0008,0050) SH [1]                                      #   2, 1 AccessionNumber
(0008,0060) CS [CT]                                     #   2, 1 Modality
(0008,0070) LO [GDCM]                                   #   4, 1 Manufacturer
(0008,0080) LO [National Library of Medicine]           #  28, 1 InstitutionName
(0008,0081) ST [http://www-creatis.insa-lyon.fr/Public/Gdcm] #  44, 1 InstitutionAddress
(0008,0090) PN [Unk^own]                                #   8, 1 ReferringPhysiciansName
(0008,1030) LO [Visible Human Male]                     #  18, 1 StudyDescription
(0008,103e) LO [Resampled to 1mm voxels]                #  24, 1 SeriesDescription
(0010,0010) PN [Ad^m]                                   #   4, 1 PatientsName
(0010,0020) LO [000-000-002]                            #  12, 1 PatientID
(0010,0030) DA [20050101]                               #   8, 1 PatientsBirthDate
(0010,0032) TM [010100.000000]                          #  14, 1 PatientsBirthTime
(0010,0040) CS [M]                                      #   2, 1 PatientsSex
(0018,0050) DS [1.0]                                    #   4, 1 SliceThickness
(0018,0060) DS [1.0]                                    #   4, 1 kVp
(0018,5100) CS [HFS]                                    #   4, 1 PatientPosition
(0020,000d) UI [1.2.826.0.1.3680043.2.1125.1.75064541463040.2005072610175534421] #  64, 1 StudyInstanceUID
(0020,000e) UI [1.2.826.0.1.3680043.2.1125.1.75064541463040.2005072610175534453] #  64, 1 SeriesInstanceUID
(0020,0010) SH [1]                                      #   2, 1 StudyID
(0020,0011) IS [1]                                      #   2, 1 SeriesNumber
(0020,0012) IS [1]                                      #   2, 1 Acquisition Number
(0020,0013) IS [1001]                                   #   4, 1 InstanceNumber
(0020,0032) DS [0\0\1000]                               #   8, 3 ImagePositionPatient
(0020,0037) DS [1.000000\0.000000\0.000000\0.000000\1.000000\0.000000] #  54, 6 ImageOrientationPatient
(0020,0052) UI [1.2.826.0.1.3680043.2.1125.1.75064541463040.2005072610175534419] #  64, 1 FrameOfReferenceUID
(0020,1040) LO [SN]                                     #   2, 1 PositionReferenceIndicator
(0028,0002) US 1                                        #   2, 1 SamplesPerPixel
(0028,0004) CS [MONOCHROME2]                            #  12, 1 PhotometricInterpretation
(0028,0010) US 512                                      #   2, 1 Rows
(0028,0011) US 512                                      #   2, 1 Columns
(0028,0030) DS [1.000000\1.000000]                      #  18, 2 PixelSpacing
(0028,0100) US 16                                       #   2, 1 BitsAllocated
(0028,0101) US 16                                       #   2, 1 BitsStored
(0028,0102) US 15                                       #   2, 1 HighBit
(0028,0103) US 1                                        #   2, 1 PixelRepresentation
(0028,1052) DS [-1024]                                  #   6, 1 RescaleIntercept
(0028,1053) DS [1]                                      #   2, 1 RescaleSlope
(7fe0,0000) UL 524300                                   #   4, 1 PixelDataGroupLength
(7fe0,0010) OW 0000\0000\0000\0000\0000\0000\0000\0000\0000\0000\0000\0000\0000... # 524288, 1 PixelData

Taken from the Visible Human CT datasets, Series generated by GDCM. Available at:

As of today (02/22/2006), there are still errors in those datasets (reported by D. Clunie dciodvfy):

Warning - Value dubious for this VR - (0x0008,0x0090) PN Referring Physician's Name  PN [0] = <Unknown> - Retired Person Name form
Warning - Value dubious for this VR - (0x0010,0x0010) PN Patient's Name  PN [0] = <Adam> - Retired Person Name form
CTImage
Error - Missing attribute Type 2 Required Element=<KVP> Module=<CTImage>
Error - Missing attribute Type 2 Required Element=<AcquisitionNumber> Module=<CTImage>

Derived DICOM Images

Your input is let say a DICOM serie, and your mathematical operation is a gaussian blur/resampling (which affect interpretation). Then you need to respect:

"If the pixel data of the derived Image is different from
the pixel data of the source images and this difference is
expected to affect professional interpretation of the image,
the Derived Image shall have a UID different than all the
source images." PS 3.3 C.7.6.1.1.2 

What need to be changed from the ORIGINAL images is:

(0008,0008) Image Type (*)
(0008,0012) Instance Creation Date (definitely!)
(0008,0013) Instance Creation Time (definitely!)
(0008,0018) SOP Instance UID
(0008,0070) Manufacturer
(0008,1090) Manufacturer's Model Name
(0008,2111) Derivation Description
(0008,2112) Source Image Sequence
(0020,000e) Series Instance UID
(7fe0,0010) Pixel Data (obviously)

(*) Should be changed from "ORIGINAL" to "DERIVED". Derivation Description and Source Image Sequence be set appropriately (See References). Ref:

Also this is wise to remove any private tags.


What need to be kept the same:

(0002,0002) Media Storage SOP Class UID
(0008,0016) SOP Class UID (*)
(0008,0022) Acquisition Date (definitely!)
(0008,0023) Content Date (probalby?)
(0008,0032) Acquisition Time (definitely!)
(0008,0033) Content Time (probably?)
(0008,0060) Modality
(0020,000d) Study Instance UID (you can retain the same as original)
(0020,0012) Acquisition Number (??)

(*) I would avoid using the Secondary Capture SOP Class for the derived image if it is at all possible to use CR, since you will loose support for CR-specific features.

What to do with the equipment description is now spelled out in detail in the Contributing Equipment Sequence description in the SOP Common Module (PS 3.3 C.12.1.1.5) which was added in CP 270; as Steve points out at the very least the Series Instance UID needs to be changed.


What need to be recomputed from the ORIGINAL images is:

Let's say I have some DICOM data with uncompressed image data in it, BitsAllocated = 8, then I modify some of the image data and convert it to 16-bit. What all do I need to update to keep everything "correct"? Here's what I've come up with:

  • BitsAllocated, BitsStored, HighBit, of course.
  • Image group length size.
  • Pick a new padding value if one was defined originally.
  • Recalculate min/max pixel values.

Am I missing anything? None of the data I am working with has any color LUTs in it so I don't need to worry about that. What about window width/center and rescale slope/intercept? How should I handle those?

Comments

Comment 1

Regarding date, time, and datetime attributes for dicom objects derived from other, original acquisition objects, the subject came up in the specification of the DICOM Encapsulation SOP Class last year, which is in the same "family" of SOP classes as secondary capture. The following clarifying note was provided after following the table specifying the attributes in the Encapsulated Document Module

Note: One could distinguish four stages in the creation of the Encapsulated Document Object, identified by the following Attributes:

  1. Measurement and/or data collection, identified by Acquisition Datetime (0008,002A) in the Encapsulated Document Module.
  2. Creation of the original documentation of the data collection, identified by Content Date (0008,0023) and Content Time (0008,0033).
  3. Rendering of the original documentation into the format that will be encapsulated, e.g. a PDF document. The rendering time is not captured by any DICOM Attribute, but may be encoded in the rendering.
  4. Encapsulation of the rendering into a DICOM Object, identified by Instance Creation Date (0008,0012) and Instance Creation Time (0008,0013) in the SOP Common Module.

Although the note is specific to the Encapsulated Document Module attributes, the clarification can be applied to many derived objects such as the ones you are discussing creating.

The above indicates you should retain the Acquisition DateTime (0008,002A) from the original images. In my opinions, the new derived image is new content, and so would have its own Content Date and Content Time attributes (0008,0023) and (0008,0033) respectively, assigned with the date & time at the moment of derivation (some might argue the content is original pixel data tho). Instance Creation Date and Time should be at the time of generation of the DICOM object. In most cases this would be the same as the Content Date and Time, but one can image some cases where its not. For example if a derived image was generated on a workstation but maintained in some proprietary format for some period until being transferred to an external system via DICOM, then the instance creation time might differ, be later than the content date/time

Comment 2

...

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
Designator
(0008,0102)
Code Value
(0008,0100)
Code Meaning
(0008,0104)
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


Ref:

Comment 3

Making the attributes related to the image display pipeline
work is just one part of the problem.

A better way to think of this than as what attributes need to
be changed is what information entities need to be changed.

Is it the same Patient and Study ? Yes, so none of the
attributes of the Patient and Study modules need to be
changed.

Is it the same Equipment ? No. Therefore all the Equipment
and Series Module attributes need to be changed.

Is it a new "procedure step" ? Yes, therefore old procedure
step related attributes may need to be removed and a new
procedure step created, or not depending on how the new
objects are expected to be managed in the PACS. These are
generally in the Series level modules.

Is it the same spatial or temporal Frame of Reference ? This
depends on what you are doing to the image, and if not then
all the orientation, position and frame of reference attributes
in appropriate modules may need to be changed, and exactly
what depends on what SOP Class the image is.

Is it the same instance ? By definition not in this case,
so you have to consider all the Image and Instance level
module attributes. Do acquisition technique attributes
(like Echo Time of kVP) still apply ? Possibly not if you
have merged two images. What about relationship to X-Ray
intensity ? Not if you have inverted the image somehow,
etc. Have you added burned in annotation ? If so that
attribute should be set if it wasn't before, etc.

What about private attributes ? Probably need to remove them
all if you don't know exactly what they mean and whether or
not they still apply.

I.e., there is no simple, general answer to this question,
since it depends on what you are doing to the images, and
what SOP Class they are.

Another way to look at this is as a "pull" rather than a
"push" problem ... are you "pushing" all the original
entities and their attributes to the new object and
removing or replacing what no longer applies, or are
you creating a new object from scratch and only "pulling"
those attributes of those entities from the original
that are the same entity (typically Patient, Study and
Frame of Reference). 

Open questions:

Then what should I do about all those Type 3 attributes from, say the CT Image module; e.g. reconstruction diameter, distance source to patient, gantry detector tilt, etc etc.

Same with MR image module: scanning sequence (Type 1!), echo time, etc.

References

Derivation Description

If an Image is identified to be a derived image (see C.7.6.1.1.2 Image Type), Derivation Description (0008,2111) and Derivation Code Sequence (0008,9215) describe the way in which the image was derived. They may be used whether or not the Source Image Sequence (0008,2112) is provided. They may also be used in cases when the Derived Image pixel data is not significantly changed from one of the source images and the SOP Instance UID of the Derived Image is the same as the one used for the source image.

Notes:

  1. Examples of Derived Images that would normally be expected to affect professional interpretation and would thus have a new UID include:
    1. images resulting from image processing of another image (e.g. unsharp masking),
    2. a multiplanar reformatted CT image,
    3. a DSA image derived by subtracting pixel values of one image from another.
    4. an image that has been decompressed after having been compressed with a lossy compression algorithm. To ensure that the user has the necessary information about the lossy compression, the approximate compression ratio may be included in Derivation Description (0008,2111). An example of a Derived Image that would normally not be expected to affect professional interpretation and thus would not require a new UID is an image that has been padded with additional rows and columns for more display purposes.
  2. An image may be lossy compressed, e.g., for long term archive purposes, and its SOP Instance UID changed. PS3.4 provides a mechanism by which a query for the original image Instance may return a reference to the UID of the lossy compressed version of the image using the Alternate Representation Sequence (0008,3001). This allows an application processing a SOP Instance that references the original image UID, e.g., a Structured Report, to obtain a reference to an accessible version of the image even if the original SOP Instance is no longer available.

Source image sequence

If an Image is identified to be a Derived image (see C.7.6.1.1.2 Image Type), Source Image Sequence (0008,2112) is an optional list of Referenced SOP Class UID (0008,1150)/ Referenced SOP Instance UID (0008,1150) pairs that identify the source images used to create the Derived image. It may be used whether or not there is a description of the way the image was derived in Derivation Description (0008,2111) or Derivation Code Sequence (0008,9215).

Secondary Capture Images

Basically something that does not comes from a scanner (Modality independant).

Warning: these objects are not multi-frames:

Modifying DICOM Header Data

consulting a customer that is setting up requirements for a new product, I ran into an interesting discussion I could not find an easy answer to (neither did google (-; ).

The customers wish is to have a means to correct certain Header fields, that wold render the objects received unusable if left in original formatting or with original content. This could be breaches of conformance, or user misoperations (unsupported characters, e.g.) or missing Information that may be produced either by a user entry (e. g. message: "Information missing: Please enter the Patient's birth date"), by the system itself (very simple example: by calculating the Patient's Age), by Patient Information Reconciliation - whatever.

As Legislation in some countries is very touchy about having to provide the original evidence objects on request, I wonder which is the best way to _document_ changes and make them reversible. I am not a great supporter of creating a new SOPInstance wherever possible - the original but flawy objects may be already referenced somewhere, and storage may explode...

So I wonder if there is any other use of (0400,0550)Modified Attributes Sequence than depersonalization that may match our needs, or if the changes better go to a Presentation state (which are still not broadly supported, at least in the Installation I have visited the past months, so I would take this just with a grain of salt).

Which way would be the best to match the scenario "We have to change something, but we want to keep it reversibly inside a Standard Object"? I already started to unsell my client the idea of using private groups for this purpose, if I only could imagine a better way that is broadly accepted...

Answer

That is what Original Attributes sequence is designed for. Is
there something about it that does not meet your needs ?

Specifically:

Original Attributes Sequence (0400,0561)
        Sequence of Items containing all attributes that were
        removed or replaced by other values in the main dataset.
        One or more Items may be permitted in this sequence.

  > Source of Previous Values (0400,0564)
        The source that provided the SOP Instance prior to the
        removal or replacement of the  values. For example, this
        might be the Institution from which imported SOP Instances
        were received.

  > Attribute Modification Datetime (0400,0562)
        Date and time the attributes were removed and/or replaced.

  > Modifying System (0400,0563)
        Identification of the system which removed and/or replaced
        the attributes.

  > Reason for the Attribute Modification (0400,0565)
        Reason for the attribute modification. Defined terms are:
                COERCE = Replace values of attributes such as Patient
                Name, ID, Accession Number, for example, during import
                of media from an external institution, or reconciliation
                against a master patient index.
                CORRECT = Replace incorrect values, such as Patient
                Name or ID, for example, when incorrect worklist item
                was chosen or operator input error.

  > Modified Attributes Sequence (0400,0550)
        Sequence containing a single item that contains all the Attributes
        that were modified or removed from the main data set. 

Ref:

Notes:

DICOM Spec

A.8 SECONDARY CAPTURE IMAGE INFORMATION OBJECT DEFINITION

The Secondary Image (SC) Image Information Object Definition (IOD) specifies images that are converted from a non-DICOM format to a modality independent DICOM format. Examples of types of equipment that create Secondary Capture Images include:

  1. Video interfaces that convert an analog video signal into a digital image
  2. Digital interfaces that are commonly used to transfer non-DICOM digital images from an imaging device to a laser printer
  3. Film digitizers that convert an analog film image to digital data
  4. Workstations that construct images that are sent out as a screen dump
  5. Scanned documents and other bitmap images including hand-drawings
  6. Synthesized images that are not modality-specific, such as cine-loops of 3D reconstructions

C.7.6.1.1.2 Image Type

The Image Type (0008,0008) Attribute identifies important image identification characteristics. These characteristics are:

  1. Pixel Data Characteristics
    • is the image an ORIGINAL Image; an image whose pixel values are based on original or source data
    • is the image a DERIVED Image; an image whose pixel values have been derived in some manner from the pixel value of one or more other images
  2. Patient Examination Characteristics
    • is the image a PRIMARY Image; an image created as a direct result of the Patient examination
    • is the image a SECONDARY Image; an image created after the initial Patient examination
  3. Modality Specific Characteristics
  4. Implementation specific identifiers; other implementation specific identifiers shall be documented in an implementation's conformance statement. The Image Type attribute is multi-valued and shall be provided in the following manner:
    • Value 1 shall identify the Pixel Data Characteristics; Enumerated Values for the Pixel Data Characteristics are:
      • ORIGINAL identifies an Original Image
      • DERIVED identifies a Derived Image
    • Value 2 shall identify the Patient Examination Characteristics; Enumerated Values for the Patient Examination Characteristics are:
      • PRIMARY identifies a Primary Image
      • SECONDARY identifies a Secondary Image
    • Value 3 shall identify any Image IOD specific specialization (optional)
    • Other Values which are implementation specific (optional)

If the pixel data of the derived Image is different from the pixel data of the source images and this difference is expected to affect professional interpretation of the image, the Derived Image shall have a UID different than all the source images.

DICOM newsgroup

SOP classes are defined in terms of what information you can provide about an image, rather than their true "source" (that is what 0008,0008 is for), so irrespective of the source of the data, if it contains pixel data, and is valid DICOM, you can never be faulted for creating a secondary capture image. Of course, if it happens that you have enough other data to make a valid CT, MR etc. image, then great, but if not, you are right to go for SC.


Ref:

Subject: Review of Draft Supplement 57- Revised Secondary Capture Objects

Comments are being solicited from interested groups and individuals outside NEMA and the DICOM Committee on the Draft Supplement 57- Revised Secondary Capture Objects. The latest draft is dated September 27, 2000. It may be obtained from the NEMA ftp site at:

The filename is "sup57_pc.pdf". Please provide any comments you may wish to make on the draft.

Update (21 January 2007):



Ref:

> I have a couple of questions about Multi-Frame images.

> 1. Can a Secondary Capture image contain multiple frames? If it is a
> possibility as far a the standard is concerned, how common is it?

There is a whole new family of multi-frame SC image SOP Classes which can be used for this purpose. They are just new, so they are not yet in common use. One of the first major applications is likely to be by the cardiac NM vendors who want to be able to capture the results of processing.

The original SC SOP Class is absolutely single frame and under no circumstances should you try to squeeze a multi-frame image in there.

> 2. What is the correct way to determine if an image is multiframe? I'm using
> tag 0028, 0008 (Number of Frames). If it is in the DICOM I assume the image
> is multi-frame. I have run into a couple of cases where the DICOM is sent
> with only the 0028, 0008 of the multi-frame module set to 1. In one case I
> found the tag in a single frame US SOP. Is that legal DICOM?

One way is to check the SOP Class ... some SOP Classes contain the appropriate attributes and others don't.

Expediently however, if Number Of Frames is present and not 1, then obviously there is more than one frame; if Number of Frames is 1 or is absent, then there is exactly one frame (whether it be the only frame of a single-frame SOP class, or the one frame of a multi-frame SOP class can only be determined by also looking at the SOP Class UID).

Clearly it is quite legal to have a one-frame image of a multi-frame SOP class; NM and XRF are typical examples; even XA images are sometimes just one frame. In the US case, one could have just one frame of the US Multi-frame SOP Class.

Even for a single frame object, there is no prohibition on (0028,0008) being present (as a 'standard extended SOP class'), but clearly it could only have a value of 1. One could imagine a US implementation for example, the built US SF and MF objects with the same set of attributes, using the SF SOP Class UID if and only if (0028,0008) was 1, but not removing the (0028,0008) and other related attributes.



If you want to create a DICOM image, for interchange on DICOM media or via the DICOM network protocols, then yes, the Secondary Capture object is the one intended for frame grabs and scans, where identifying information is available, but not modality specific positioning or technique information.

It is a single frame object.



Ref:

I'm looking for a guideline regarding creation of derived images, e.g. a reformat, that will be sent back to the PACS. I could not find anything in DICOM or IHE, but perhaps I missed something.

Basically, the question boils down to: which attributes should I copy from the original series and which should I create anew.

There are some obvious ones: new series instance UID, new SOP instance UIDs, image type, manufacturer info and all the image position and orientation stuff that has changed.

I found an old posting here that listed a few more attributes: http://groups.google.com/group/comp.protocols.dicom/tree/browse_frm/thread/9ce1edda141a067f/1a6ca9dd6dfaf942

I'm currently assuming that everything from the Patient, General Study, Patient Study modules should be copied. It's the attributes in the image modules that are unclear to me.

Things like acquisition number, date, and time. In David Clunie's contribution to the thread above he says that acquisition date and time should definitely remain the same. Ditto for acquisition number?

I presume it's standard to retain the modality and SOP Class from the original. Then what should I do about all those Type 3 attributes from, say the CT Image module; e.g. reconstruction diameter, distance source to patient, gantry detector tilt, etc etc. Same with MR image module: scanning sequence (Type 1!), echo time, etc.

Do people expect to see such attributes in the reconstruction or not?

Anonymization

Ref [1]

Hi Sébastien

"Sébastien Barré" wrote:
> I have established such a list, which is quite long. Do you really think
> that we have to remove every elements related to the patient ? For
> example :

> // pat_id = Patient Identification

>     {0x0010, 0x0010},       // PN 1    Patient's Name
>     {0x0010, 0x0020},       // LO 1    Patient's ID
>     {0x0010, 0x1000},       // LO 1-n  Other Patient's IDs
>     {0x0010, 0x1001},       // PN 1-n  Other Patient's Names
>     {0x0010, 0x1005},       // PN 1    Patient's Birth Name
>     {0x0010, 0x1060},       // PN 1    Patient's Mother's Birth Name

> // pat_demo = Patient Demographic

>     {0x0010, 0x0030},       // DA 1    Patient's Birth Date
>     {0x0010, 0x0032},       // TM 1    Patient's Birth Time
>     {0x0010, 0x0040},       // CS 1    Patient's Sex
>     {0x0010, 0x1040},       // LO 1    Patient's Address
>     {0x0010, 0x2150},       // LO 1    Country of Residence
>     {0x0010, 0x2152},       // LO 1    Region of Residence
>     {0x0010, 0x2154},       // SH 1-n  Patient's Telephone Numbers
>     {0x0010, 0x2160},       // SH 1    Ethnic Group
>     {0x0010, 0x21F0},       // LO 1    Patient's Religious Preference
>     {0x0010, 0x4000},       // LT 1    Patient Comments

> Even if the birth date is present, it is not sufficient to recognize the
> patient, or the one able to do that should be someone from the hospital,
> and therefore may already have access to all informations (but that
> could be problematic if the Patient's adress or telephone numbers are
> present).

I would remove (and replace with dummies for mandatory attributes) at the very least:

  • everything in group 0x0010 (since in future someone may add more patient related attributes and they would probably go here, even though there are no semantics attached to group numbers any more)
  • all private attributes (i.e. all odd groups)
  • all overlays and curves
  • all comment fields at study/series/image levels
  • all study identifiers, accession numbers etc.
  • generate all new UIDs

An alternative approach is to reconstruct an appropriate IOD copying only what is needed, and anonymizing what should be changed, dropping all other attributes.

One still has to examine the image pixel data to be sure there is no burned in annotation (as you point out).

A Textual Information Detection and Elimination System for Secure Medical Image Distribution

Some people have done work on detecting and removing burned in text. See for example:

TODO


Here is an example of poorly anonymized DICOM:

gdcmSampleData/images_of_interest/i32.XADC.7.215MegaBytes.dcm
(0019,0010) LO [XXXXXXXXX_xx]                           #  12, 1 PrivateCreator
(0019,0011) LO [XXXXXXXXXXXXXX]                         #  14, 1 PrivateCreator
(0019,1001) DS [0]                                      #   2, 1 Unknown Tag & Data
(0019,1002) DS [-89.7]                                  #   6, 1 Unknown Tag & Data
(0019,1003) DS [0]                                      #   2, 1 Unknown Tag & Data
(0019,1017) IS [4]                                      #   2, 1 Unknown Tag & Data
(0019,1018) IS [1]                                      #   2, 1 Unknown Tag & Data
(0019,1019) IS [0]                                      #   2, 1 Unknown Tag & Data
(0019,101a) IS [0]                                      #   2, 1 Unknown Tag & Data
(0019,1021) DS [100]                                    #   4, 1 Unknown Tag & Data
(0019,1022) DS [629]                                    #   4, 1 Unknown Tag & Data
(0019,1023) DS [-29]                                    #   4, 1 Unknown Tag & Data
(0019,1024) DS [0]                                      #   2, 1 Unknown Tag & Data
(0019,1025) DS [0.85]                                   #   4, 1 Unknown Tag & Data
(0019,1026) DS [4.72]                                   #   4, 1 Unknown Tag & Data
(0019,110b) DS [200\200]                                #   8, 2 Unknown Tag & Data
(0019,1131) IS [2]                                      #   2, 1 Unknown Tag & Data
(0019,1132) IS [4]                                      #   2, 1 Unknown Tag & Data
(0019,114e) DS [50\50]                                  #   6, 2 Unknown Tag & Data
(0019,114f) DS [50\50]                                  #   6, 2 Unknown Tag & Data
(0019,1192) DS [0]                                      #   2, 1 Unknown Tag & Data
(0019,1195) CS [NO\NO]                                  #   6, 2 Unknown Tag & Data
(0019,1197) DS [0.0\0.0\0.0\0.0\0.0\0.0\0.0\0.0\0.0\0.0\0.0\0.0\0.0\0.0\0.0\0.0\0.... # 860,215 Unknown Tag & Data
(0019,1198) DS [0.0\0.1\0.1\0.2\0.2\0.3\0.3\0.4\0.4\0.5\0.5\0.6\0.6\0.7\0.7\0.8\0.... # 1124,215 Unknown Tag & Data
(0019,1199) DS [0.0\0.0\0.0\0.0\0.0\0.0\0.0\0.0\0.0\0.0\0.0\0.0\0.0\0.0\0.0\0.0\0.... # 860,215 Unknown Tag & Data

Clearly this is a GEMS_DL_IMG_01

(0025,100a) SQ (Sequence with explicit length #=1)      # 244, 1 Unknown Tag & Data
  (fffe,e000) na (Item with explicit length #=17)         # 236, 1 Item
    (0025,0010) LO [XXXXXXXXXXXXXXXX]                       #  16, 1 PrivateCreator
    (0025,1002) IS [1]                                      #   2, 1 Unknown Tag & Data
    (0025,1003) DS [1014]                                   #   4, 1 Unknown Tag & Data
    (0025,1004) DS [705]                                    #   4, 1 Unknown Tag & Data
    (0025,1005) DS [661]                                    #   4, 1 Unknown Tag & Data
    (0025,101b) DS [100]                                    #   4, 1 Unknown Tag & Data
    (0025,101c) DS [629]                                    #   4, 1 Unknown Tag & Data
    (0025,101d) DS [-29]                                    #   4, 1 Unknown Tag & Data
    (0025,101f) DS [60]                                     #   2, 1 Unknown Tag & Data
    (0025,1020) DS [0.0913511]                              #  10, 1 Unknown Tag & Data
    (0025,1021) DS [1]                                      #   2, 1 Unknown Tag & Data
    (0025,1027) DS [78.5467]                                #   8, 1 Unknown Tag & Data
    (0025,1028) DS [1.29213]                                #   8, 1 Unknown Tag & Data
    (0025,1029) DS [20.7448]                                #   8, 1 Unknown Tag & Data
    (0025,102a) DS [0.733398]                               #   8, 1 Unknown Tag & Data
    (0025,102b) IS [1853182511]                             #  10, 1 Unknown Tag & Data
    (0025,103b) CS [NO]                                     #   2, 1 Unknown Tag & Data
  (fffe,e00d) na (ItemDelimitationItem for re-encoding)   #   0, 0 ItemDelimitationItem
(fffe,e0dd) na (SequenceDelimitationItem for re-encod.) #   0, 0 SequenceDelimitationItem

It make it completely impossible to see that PrivateCreator should have been GEMS_DL_FRAME_01

TODO 2

And declared winner for worse anonymizer ever: ImageJ:

ref:

$ dcmdump 1.2.840.113619.2.5.1762392445.1923.1038232784.971
DcmItem: Length of attribute (0008,0020) is odd
DcmItem: Length of attribute (0008,0021) is odd
DcmItem: Length of attribute (0008,0022) is odd
DcmItem: Length of attribute (0008,0023) is odd
DcmItem: Length of attribute (0008,0030) is odd
DcmItem: Length of attribute (0008,0031) is odd
DcmItem: Length of attribute (0008,0032) is odd
DcmItem: Length of attribute (0008,0033) is odd
DcmItem: Length of attribute (0008,0080) is odd
DcmItem: Length of attribute (0008,0090) is odd
DcmItem: Length of attribute (0008,1010) is odd
DcmItem: Length of attribute (0008,1070) is odd
DcmItem: Length of attribute (0010,0030) is odd
DcmItem: Length of attribute (0010,0040) is odd
DcmItem: Length of attribute (0010,1010) is odd
DcmItem: Length of attribute (0010,1030) is odd
DcmItem: Length of attribute (0010,21b0) is odd

# Dicom-File-Format

# Dicom-Meta-Information-Header
# Used TransferSyntax: LittleEndianExplicit
(0002,0000) UL 194                                      #   4, 1 MetaElementGroupLength
(0002,0001) OB 01\00                                    #   2, 1 FileMetaInformationVersion
(0002,0002) UI =MRImageStorage                          #  26, 1 MediaStorageSOPClassUID
(0002,0003) UI [1.2.840.113619.2.5.1762392445.1923.1038232784.971] #  50, 1 MediaStorageSOPInstanceUID
(0002,0010) UI =LittleEndianImplicit                    #  18, 1 TransferSyntaxUID
(0002,0012) UI [1.2.804.114118.3]                       #  16, 1 ImplementationClassUID
(0002,0013) SH [eFilm]                                  #   6, 1 ImplementationVersionName
(0002,0016) AE []                                       #  16, 1 SourceApplicationEntityTitle

# Dicom-Data-Set
# Used TransferSyntax: LittleEndianImplicit
(0008,0005) CS [ISO_IR 100]                             #  10, 1 SpecificCharacterSet
(0008,0008) CS [ORIGINAL\PRIMARY\OTHER]                 #  22, 3 ImageType
(0008,0016) UI =MRImageStorage                          #  26, 1 SOPClassUID
(0008,0018) UI [1.2.840.113619.2.5.1762392445.1923.1038232784.971] #  50, 1 SOPInstanceUID
(0008,0020) DA [???]                                    #   4, 1 StudyDate
(0008,0021) DA [???]                                    #   4, 1 SeriesDate
(0008,0022) DA [???]                                    #   4, 1 AcquisitionDate
(0008,0023) DA [???]                                    #   4, 1 ContentDate
(0008,0030) TM [???]                                    #   4, 1 StudyTime
(0008,0031) TM [???]                                    #   4, 1 SeriesTime
(0008,0032) TM [???]                                    #   4, 1 AcquisitionTime
(0008,0033) TM [???]                                    #   4, 1 ContentTime
(0008,0050) SH (no value available)                     #   0, 0 AccessionNumber
(0008,0060) CS [MR]                                     #   2, 1 Modality
(0008,0070) LO [GE MEDICAL SYSTEMS]                     #  18, 1 Manufacturer
(0008,0080) LO [???]                                    #   4, 1 InstitutionName
(0008,0090) PN [???]                                    #   4, 1 ReferringPhysiciansName
(0008,1010) SH [???]                                    #   4, 1 StationName
(0008,1030) LO [BRAIN  W/WO]                            #  12, 1 StudyDescription
(0008,103e) LO [O-Ax PD&T2 FSE-V S]                     #  18, 1 SeriesDescription
(0008,1070) PN [???]                                    #   4, 1 OperatorsName
(0008,1090) LO [GENESIS_SIGNA]                          #  14, 1 ManufacturersModelName
(0009,0000) UL 182                                      #   4, 1 PrivateGroupLength
(0009,0010) LO [GEMS_IDEN_01]                           #  12, 1 PrivateCreator
(0009,1001) LO [GE_GENESIS_FF]                          #  14, 1 FullFidelity
(0009,1002) SH [mrs1]                                   #   4, 1 SuiteId
(0009,1004) SH [SIGNA]                                  #   6, 1 ProductId
(0009,1027) SL 1038223774                               #   4, 1 ImageActualDate
(0009,1030) SH [04352SMR]                               #   8, 1 ServiceId
(0009,1031) SH [999]                                    #   4, 1 MobileLocationNumber
(0009,10e3) UI [1.2.840.113619.1.1.4.1762392445]        #  32, 1 EquipmentUID
(0009,10e6) SH [09]                                     #   2, 1 GenesisVersionNow
(0009,10e7) UL 762795966                                #   4, 1 ExamRecordChecksum
(0009,10e9) SL 1038223773                               #   4, 1 ActualSeriesDataTimeStamp
(0010,0000) UL 96                                       #   4, 1 PatientGroupLength
(0010,0010) PN [Anonymized-J..]                         #  14, 1 PatientsName
(0010,0020) LO [20030516172509]                         #  14, 1 PatientID
(0010,0030) DA [???]                                    #   4, 1 PatientsBirthDate
(0010,0040) CS [???]                                    #   4, 1 PatientsSex
(0010,1010) AS [???]                                    #   4, 1 PatientsAge
(0010,1030) DS [???]                                    #   4, 1 PatientsWeight
(0010,21b0) LT [???]                                    #   4, 1 AdditionalPatientHistory
(0011,0000) UL 30                                       #   4, 1 PrivateGroupLength
(0011,0010) LO [GEMS_PATI_01]                           #  12, 1 PrivateCreator
(0011,1010) SS 0                                        #   2, 1 PatientStatus
(0018,0000) UL 512                                      #   4, 1 AcquisitionGroupLength
(0018,0020) CS [RM]                                     #   2, 1 ScanningSequence
(0018,0021) CS [NONE]                                   #   4, 1 SequenceVariant
(0018,0022) CS [FC_SLICE_AX_GEMS\FC\SAT_GEMS\VB_GEMS \SP] #  40, 5 ScanOptions
(0018,0023) CS [2D]                                     #   2, 1 MRAcquisitionType
(0018,0025) CS [N]                                      #   2, 1 AngioFlag
(0018,0050) DS [3.000000]                               #   8, 1 SliceThickness
(0018,0080) DS [ 3000.000000]                           #  12, 1 RepetitionTime
(0018,0081) DS [ 85.959999]                             #  10, 1 EchoTime
(0018,0082) DS [0.000000]                               #   8, 1 InversionTime
(0018,0083) DS [1.000000]                               #   8, 1 NumberOfAverages
(0018,0084) DS [ 638936740.00000]                       #  16, 1 ImagingFrequency
(0018,0085) SH [H1]                                     #   2, 1 ImagedNucleus
(0018,0086) IS [ 2]                                     #   2, 1 EchoNumbers
(0018,0087) DS [15000]                                  #   6, 1 MagneticFieldStrength
(0018,0088) DS [3.000000]                               #   8, 1 SpacingBetweenSlices
(0018,0091) IS [10]                                     #   2, 1 EchoTrainLength
(0018,0093) DS [100.000000]                             #  10, 1 PercentSampling
(0018,0094) DS [ 75.000000]                             #  10, 1 PercentPhaseFieldOfView
(0018,0095) DS [122.070312]                             #  10, 1 PixelBandwidth
(0018,1000) LO [000000000303210]                        #  16, 1 DeviceSerialNumber
(0018,1020) LO [09]                                     #   2, 1 SoftwareVersions
(0018,1050) DS [0.937500]                               #   8, 1 SpatialResolution
(0018,1088) IS [0]                                      #   2, 1 HeartRate
(0018,1090) IS [0]                                      #   2, 1 CardiacNumberOfImages
(0018,1094) IS [0]                                      #   2, 1 TriggerWindow
(0018,1100) DS [240.000000]                             #  10, 1 ReconstructionDiameter
(0018,1250) SH [HEAD]                                   #   4, 1 ReceiveCoilName
(0018,1251) SH [HEAD]                                   #   4, 1 TransmitCoilName
(0018,1310) US 0\256\256\0                              #   8, 4 AcquisitionMatrix
(0018,1312) CS [ROW]                                    #   4, 1 InPlanePhaseEncodingDirection
(0018,1314) DS [90]                                     #   2, 1 FlipAngle
(0018,1315) CS [N]                                      #   2, 1 VariableFlipAngleFlag
(0018,1316) DS [0.095900]                               #   8, 1 SAR
(0018,5100) CS [HFS]                                    #   4, 1 PatientPosition
(0019,0000) UL 1206                                     #   4, 1 PrivateGroupLength
(0019,0010) LO [GEMS_ACQU_01]                           #  12, 1 PrivateCreator
(0019,100f) DS [409.299988]                             #  10, 1 HorizontalFrameOfReference
(0019,1011) SS 0                                        #   2, 1 SeriesContrast
(0019,1012) SS 56                                       #   2, 1 LastPseq
(0019,1017) SS 16                                       #   2, 1 SeriesPlane
(0019,1018) LO [I]                                      #   2, 1 FirstScanRAS
(0019,1019) DS [-56.400002]                             #  10, 1 FirstScanLocation
(0019,101a) LO [S]                                      #   2, 1 LastScanRAS
(0019,101b) DS [105.599998]                             #  10, 1 LastScanLocation
(0019,101e) DS [180.000000]                             #  10, 1 DisplayFieldOfView
(0019,105a) FL 3.786e+08                                #   4, 1 AcquisitionDuration
(0019,107d) DS [85960]                                  #   6, 1 SecondEcho
(0019,107e) SS 2                                        #   2, 1 NumberOfEchos
(0019,107f) DS [0.000000]                               #   8, 1 TableDelta
(0019,1081) SS 1                                        #   2, 1 Contiguous
(0019,1084) DS [4.613270]                               #   8, 1 PeakSAR
(0019,1085) SS 1                                        #   2, 1 MonitorSAR
(0019,1087) DS [0.000000]                               #   8, 1 CardiacRepetitionTime
(0019,1088) SS 0                                        #   2, 1 ImagesPerCardiacCycle
(0019,108a) SS 11                                       #   2, 1 ActualReceiveGainAnalog
(0019,108b) SS 14                                       #   2, 1 ActualReceiveGainDigital
(0019,108d) DS [0]                                      #   2, 1 DelayAfterTrigger
(0019,108f) SS 0                                        #   2, 1 SwapPhaseFrequency
(0019,1090) SS 0                                        #   2, 1 PauseInterval
(0019,1091) DS [0.000000]                               #   8, 1 PulseTime
(0019,1092) SL 0                                        #   4, 1 SliceOffsetOnFrequencyAxis
(0019,1093) DS [638936740]                              #  10, 1 CenterFrequency
(0019,1094) SS 128                                      #   2, 1 TransmitGain
(0019,1095) SS 11                                       #   2, 1 AnalogReceiverGain
(0019,1096) SS 14                                       #   2, 1 DigitalReceiverGain
(0019,1097) SL 64                                       #   4, 1 BitmapDefiningCVs
(0019,1098) SS 2                                        #   2, 1 CenterFrequencyMethod
(0019,109b) SS 1                                        #   2, 1 PulseSequenceMode
(0019,109c) LO [fse-xl]                                 #   6, 1 PulseSequenceName
(0019,109d) DT [20021112051948]                         #  14, 1 PulseSequenceDate
(0019,109e) LO [FSE-XL]                                 #   6, 1 InternalPulseSequenceName
(0019,109f) SS 1                                        #   2, 1 TransmittingCoil
(0019,10a0) SS 0                                        #   2, 1 SurfaceCoilType
(0019,10a1) SS 0                                        #   2, 1 ExtremityCoilFlag
(0019,10a2) SL 6706                                     #   4, 1 RawDataRunNumber
(0019,10a3) UL 0                                        #   4, 1 CalibratedFieldStrength
(0019,10a4) SS 0                                        #   2, 1 SATFatWaterBone
(0019,10a7) DS [0.000000]                               #   8, 1 UserData
(0019,10a8) DS [0.000000]                               #   8, 1 UserData
(0019,10a9) DS [0.000000]                               #   8, 1 UserData
(0019,10aa) DS [0.000000]                               #   8, 1 UserData
(0019,10ab) DS [0.000000]                               #   8, 1 UserData
(0019,10ac) DS [0.000000]                               #   8, 1 UserData
(0019,10ad) DS [0.000000]                               #   8, 1 UserData
(0019,10ae) DS [0.000000]                               #   8, 1 UserData
(0019,10af) DS [0.000000]                               #   8, 1 UserData
(0019,10b0) DS [0.000000]                               #   8, 1 UserData
(0019,10b1) DS [0.000000]                               #   8, 1 UserData
(0019,10b2) DS [0.000000]                               #   8, 1 UserData
(0019,10b3) DS [0.000000]                               #   8, 1 UserData
(0019,10b4) DS [0.000000]                               #   8, 1 UserData
(0019,10b5) DS [0.000000]                               #   8, 1 UserData
(0019,10b6) DS [0.000000]                               #   8, 1 UserData
(0019,10b7) DS [0.000000]                               #   8, 1 UserData
(0019,10b8) DS [0.000000]                               #   8, 1 UserData
(0019,10b9) DS [0.000000]                               #   8, 1 UserData
(0019,10ba) DS [0.000000]                               #   8, 1 UserData
(0019,10bb) DS [0.000000]                               #   8, 1 UserData
(0019,10bc) DS [0.000000]                               #   8, 1 UserData
(0019,10bd) DS [0.000000]                               #   8, 1 UserData
(0019,10be) DS [0.000000]                               #   8, 1 ProjectionAngle
(0019,10c0) SS 2                                        #   2, 1 SaturationPlanes
(0019,10c1) SS 0                                        #   2, 1 SurfaceCoilIntensityCorrectionFlag
(0019,10c2) SS 9990                                     #   2, 1 SATLocationR
(0019,10c3) SS 9990                                     #   2, 1 SATLocationL
(0019,10c4) SS 9990                                     #   2, 1 SATLocationA
(0019,10c5) SS 9990                                     #   2, 1 SATLocationP
(0019,10c6) SS 9990                                     #   2, 1 SATLocationH
(0019,10c7) SS 9990                                     #   2, 1 SATLocationF
(0019,10c8) SS 0                                        #   2, 1 SATThicknessRL
(0019,10c9) SS 0                                        #   2, 1 SATThicknessAP
(0019,10ca) SS 0                                        #   2, 1 SATThicknessHF
(0019,10cb) SS 0                                        #   2, 1 PrescribedFlowAxis
(0019,10cc) SS 0                                        #   2, 1 VelocityEncoding
(0019,10cd) SS 0                                        #   2, 1 ThicknessDisclaimer
(0019,10ce) SS 2                                        #   2, 1 PrescanType
(0019,10cf) SS 0                                        #   2, 1 PrescanStatus
(0019,10d2) SS 0                                        #   2, 1 ProjectionAlgorithm
(0019,10d3) SH (no value available)                     #   0, 0 ProjectionAlgorithm
(0019,10d5) SS 2                                        #   2, 1 FractionalEcho
(0019,10d7) SS 0                                        #   2, 1 CardiacPhases
(0019,10d8) SS 1                                        #   2, 1 VariableEchoFlag
(0019,10d9) DS [0.000000]                               #   8, 1 ConcatenatedSAT
(0019,10df) DS [0.000000]                               #   8, 1 UserData
(0019,10e0) DS [0.000000]                               #   8, 1 UserData
(0019,10e2) DS [0.000000]                               #   8, 1 VelocityEncodeScale
(0019,10f2) SS 0                                        #   2, 1 FastPhases
(0019,10f9) DS [128]                                    #   4, 1 TransmissionGain
(0020,0000) UL 374                                      #   4, 1 ImageGroupLength
(0020,000d) UI [1.2.840.113619.2.5.1762392445.1923.1038232784.784] #  50, 1 StudyInstanceUID
(0020,000e) UI [1.2.840.113619.2.5.1762392445.1923.1038232784.863] #  50, 1 SeriesInstanceUID
(0020,0010) SH [6705]                                   #   4, 1 StudyID
(0020,0011) IS [ 3]                                     #   2, 1 SeriesNumber
(0020,0012) IS [ 0]                                     #   2, 1 AcquisitionNumber
(0020,0013) IS [ 102]                                   #   4, 1 InstanceNumber
(0020,0032) DS [ -126.000000\ -110.281693\ 95.654503]   #  36, 3 ImagePositionPatient
(0020,0037) DS [ 1.000000\0.000000\0.000000\0.000000\0.999853\ -0.017121] #  56, 6 ImageOrientationPatient
(0020,0052) UI [1.2.840.113619.2.5.1762392445.1945.1038232314.22] #  48, 1 FrameOfReferenceUID
(0020,0060) CS (no value available)                     #   0, 0 Laterality
(0020,0110) DS [ 0]                                     #   2, 1 TemporalResolution
(0020,1040) LO [NA]                                     #   2, 1 PositionReferenceIndicator
(0020,1041) DS [ 93.5999984741]                         #  14, 1 SliceLocation
(0021,0000) UL 372                                      #   4, 1 PrivateGroupLength
(0021,0010) LO [GEMS_RELA_01]                           #  12, 1 PrivateCreator
(0021,1003) SS 0                                        #   2, 1 SeriesFromWhichPrescribed
(0021,1005) SH [09]                                     #   2, 1 GenesisVersionNow
(0021,1007) UL 1253001874                               #   4, 1 SeriesRecordChecksum
(0021,1018) SH [09]                                     #   2, 1 GenesisVersionNow
(0021,1019) UL 167274679                                #   4, 1 AcqReconRecordChecksum
(0021,1035) SS 1                                        #   2, 1 SeriesFromWhichPrescribed
(0021,1036) SS 13                                       #   2, 1 ImageFromWhichPrescribed
(0021,1037) SS 16                                       #   2, 1 ScreenFormat
(0021,104f) SS 55                                       #   2, 1 LocationsInAcquisition
(0021,1050) SS 0                                        #   2, 1 GraphicallyPrescribed
(0021,1051) DS [0.000000]                               #   8, 1 RotationFromSourceXRot
(0021,1052) DS [0.000000]                               #   8, 1 RotationFromSourceYRot
(0021,1053) DS [0.000000]                               #   8, 1 RotationFromSourceZRot
(0021,1056) SL 0                                        #   4, 1 IntegerSlop
(0021,1057) SL 0                                        #   4, 1 IntegerSlop
(0021,1058) SL 0                                        #   4, 1 IntegerSlop
(0021,1059) SL 0                                        #   4, 1 IntegerSlop
(0021,105a) SL 0                                        #   4, 1 IntegerSlop
(0021,105b) DS [180.000000]                             #  10, 1 FloatSlop
(0021,105c) DS [45.000000]                              #  10, 1 FloatSlop
(0021,105d) DS [50000.000000]                           #  12, 1 FloatSlop
(0021,105e) DS [0.000000]                               #   8, 1 FloatSlop
(0021,105f) DS [0.000000]                               #   8, 1 FloatSlop
(0021,1081) DS [0.000000]                               #   8, 1 AutoWindowLevelAlpha
(0021,1082) DS [0.000000]                               #   8, 1 AutoWindowLevelBeta
(0021,1083) DS [0]                                      #   2, 1 AutoWindowLevelWindow
(0021,1084) DS [0]                                      #   2, 1 AutoWindowLevelLevel
(0023,0000) UL 58                                       #   4, 1 PrivateGroupLength
(0023,0010) LO [GEMS_STDY_01]                           #  12, 1 PrivateCreator
(0023,1070) FD 0                                        #   8, 1 StartTimeSecsInFirstAxial
(0023,1074) SL 0                                        #   4, 1 NumberOfUpdatesToHeader
(0023,107d) SS 0                                        #   2, 1 IndicatesIfStudyHasCompleteInfo
(0025,0000) UL 128                                      #   4, 1 PrivateGroupLength
(0025,0010) LO [GEMS_SERS_01]                           #  12, 1 PrivateCreator
(0025,1006) SS 56                                       #   2, 1 LastPulseSequenceUsed
(0025,1007) SL 110                                      #   4, 1 ImagesInSeries
(0025,1010) SL 0                                        #   4, 1 LandmarkCounter
(0025,1011) SS 3                                        #   2, 1 NumberOfAcquisitions
(0025,1014) SL 0                                        #   4, 1 IndicatesNumberOfUpdatesToHeader
(0025,1017) SL 0                                        #   4, 1 SeriesCompleteFlag
(0025,1018) SL 0                                        #   4, 1 NumberOfImagesArchived
(0025,1019) SL 110                                      #   4, 1 LastImageNumberUsed
(0025,101a) SH [mrs1OW0]                                #   8, 1 PrimaryReceiverSuiteAndHost
(0027,0000) UL 306                                      #   4, 1 PrivateGroupLength
(0027,0010) LO [GEMS_IMAG_01]                           #  12, 1 PrivateCreator
(0027,1006) SL 0                                        #   4, 1 ImageArchiveFlag
(0027,1010) SS 0                                        #   2, 1 ScoutType
(0027,1030) SH (no value available)                     #   0, 0 ForeignImageRevision
(0027,1031) SS 1                                        #   2, 1 ImagingMode
(0027,1032) SS 56                                       #   2, 1 PulseSequence
(0027,1033) SL 33555496                                 #   4, 1 ImagingOptions
(0027,1035) SS 16                                       #   2, 1 PlaneType
(0027,1036) SL 18                                       #   4, 1 ObliquePlane
(0027,1040) SH [S]                                      #   2, 1 RASLetterOfImageLocation
(0027,1041) FL 93.6                                     #   4, 1 ImageLocation
(0027,1042) FL 6                                        #   4, 1 CenterRCoordOfPlaneImage
(0027,1043) FL -9.7                                     #   4, 1 CenterACoordOfPlaneImage
(0027,1044) FL 93.6                                     #   4, 1 CenterSCoordOfPlaneImage
(0027,1045) FL 0                                        #   4, 1 NormalRCoord
(0027,1046) FL -0.0171123                               #   4, 1 NormalACoord
(0027,1047) FL 0.999854                                 #   4, 1 NormalSCoord
(0027,1048) FL -114                                     #   4, 1 RCoordOfTopRightCorner
(0027,1049) FL 110.282                                  #   4, 1 ACoordOfTopRightCorner
(0027,104a) FL 95.6545                                  #   4, 1 SCoordOfTopRightCorner
(0027,104b) FL -114                                     #   4, 1 RCoordOfBottomRightCorner
(0027,104c) FL -129.682                                 #   4, 1 ACoordOfBottomRightCorner
(0027,104d) FL 91.5455                                  #   4, 1 SCoordOfBottomRightCorner
(0027,1060) FL 256                                      #   4, 1 ImageDimensionX
(0027,1061) FL 256                                      #   4, 1 ImageDimensionY
(0027,1062) FL 1                                        #   4, 1 NumberOfExcitations
(0028,0000) UL 150                                      #   4, 1 ImagePresentationGroupLength
(0028,0002) US 1                                        #   2, 1 SamplesPerPixel
(0028,0004) CS [MONOCHROME2]                            #  12, 1 PhotometricInterpretation
(0028,0010) US 256                                      #   2, 1 Rows
(0028,0011) US 256                                      #   2, 1 Columns
(0028,0030) DS [ 0.937494\0.937500]                     #  18, 2 PixelSpacing
(0028,0100) US 16                                       #   2, 1 BitsAllocated
(0028,0101) US 16                                       #   2, 1 BitsStored
(0028,0102) US 15                                       #   2, 1 HighBit
(0028,0103) US 1                                        #   2, 1 PixelRepresentation
(0028,0120) xs 0                                        #   2, 1 PixelPaddingValue
(0028,1050) DS [ 262]                                   #   4, 1 WindowCenter
(0028,1051) DS [ 524]                                   #   4, 1 WindowWidth
(0029,0000) UL 102                                      #   4, 1 PrivateGroupLength
(0029,0010) LO [GEMS_IMPS_01]                           #  12, 1 PrivateCreator
(0029,1015) SL 0                                        #   4, 1 LowerRangeOfPixels
(0029,1016) SL 0                                        #   4, 1 LowerRangeOfPixels
(0029,1017) SL 0                                        #   4, 1 LowerRangeOfPixels
(0029,1018) SL 0                                        #   4, 1 UpperRangeOfPixels
(0029,1026) SS 2                                        #   2, 1 VersionOfHeaderStructure
(0029,1034) SL 16384                                    #   4, 1 AdvantageCompOverflow
(0029,1035) SL 0                                        #   4, 1 AdvantageCompUnderflow
(0043,0000) UL 5056                                     #   4, 1 PrivateGroupLength
(0043,0010) LO [GEMS_PARM_01]                           #  12, 1 PrivateCreator
(0043,1001) SS 1                                        #   2, 1 BitmapOfPrescanOptions
(0043,1002) SS 0                                        #   2, 1 GradientOffsetInX
(0043,1003) SS 0                                        #   2, 1 GradientOffsetInY
(0043,1004) SS 0                                        #   2, 1 GradientOffsetInZ
(0043,1006) SS 0                                        #   2, 1 NumberOfEPIShots
(0043,1007) SS 0                                        #   2, 1 ViewsPerSegment
(0043,1008) SS 0                                        #   2, 1 RespiratoryRateInBPM
(0043,1009) SS 0                                        #   2, 1 RespiratoryTriggerPoint
(0043,100a) SS 1                                        #   2, 1 TypeOfReceiverUsed
(0043,100b) DS [0.000000]                               #   8, 1 PeakRateOfChangeOfGradientField
(0043,100c) DS [66.000000]                              #  10, 1 LimitsInUnitsOfPercent
(0043,100d) DS [64.111206]                              #  10, 1 PSDEstimatedLimit
(0043,100e) DS [0.000000]                               #   8, 1 PSDEstimatedLimitInTeslaPerSecond
(0043,100f) DS [1.845308]                               #   8, 1 SARAvgHead
(0043,1010) US 0                                        #   2, 1 WindowValue
(0043,101c) SS 0                                        #   2, 1 GEImageIntegrity
(0043,101d) SS 0                                        #   2, 1 LevelValue
(0043,1028) OB 55\41\00\00\00\00\00\2c\00\02\00\00\00\00\00\2c\00\00\01\40\00\01... #  80, 1 UniqueImageIdentifier
(0043,1029) OB 00\00\00\01\42\85\10\fb\00\1b\00\00\02\0c\00\00\00\00\03\fe\3f\14... # 2068, 1 HistogramTables
(0043,102a) OB 55\41\00\00\00\00\00\2c\00\02\00\00\00\00\00\2c\00\00\01\40\00\01... # 2420, 1 UserDefinedData
(0043,102c) SS 0                                        #   2, 1 EffectiveEchoSpacing
(0043,102d) SH (no value available)                     #   0, 0 StringSlopField1
(0043,102e) SH (no value available)                     #   0, 0 StringSlopField2
(0043,102f) SS 0                                        #   2, 1 RawDataType
(0043,1030) SS 0                                        #   2, 1 RawDataType
(0043,1032) SS 2                                        #   2, 1 RawDataType
(0043,1033) FL 0                                        #   4, 1 NegScanSpacing
(0043,1034) IS [1200]                                   #   4, 1 OffsetFrequency
(0043,1035) UL 0                                        #   4, 1 UserUsageTag
(0043,1036) UL 0                                        #   4, 1 UserFillMapMSW
(0043,1037) UL 0                                        #   4, 1 UserFillMapLSW
(0043,1038) FL 0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 #  96,24 User25ToUser48
(0043,1039) IS [  0\ 0\ 0\ 7]                           #  12, 4 SlopInteger6ToSlopInteger9
(7fe0,0000) UL 131080                                   #   4, 1 PixelDataGroupLength
(7fe0,0010) OW 0000\0000\0000\0000\0000\0000\0000\0000\0000\0000\0000\0000\0000... # 131072, 1 PixelData
(fffc,0000) UL 274                                      #   4, 1 GenericGroupLength
(fffc,fffc) OB 0f\00\00\01\04\00\01\00\00\00\00\01\00\00\01\01\04\00\01\00\00\00... # 266, 1 DataSetTrailingPadding

MRI (pseudo-)anonymisation and UIDs

D.Clunie note:

There is a description of de-identification strategies in the IHE
Teaching File and Clinical Trial Export (TCE) profile.

As far as UIDs are concerned, if you are going to do it, you need to
do it "right". Specifically, quoting from the IHE profile:

"In some de-identification scenarios, the UIDs need to be replaced.
This transaction does not require that UIDs be replaced, but does
require that if UIDs are replaced, internal consistency within the
exported set of instances be maintained; the implementation shall be
configurable to support both. This entails adherence to the following
rules:
· The same replacement UID is used for all composite instances of the
same entity within the set, e.g., the same Study Instance UID for all
instances within the same original study.
· References by UID to other instances or entities within the set are
updated, e.g., references to the SOP Instance UIDs of predecessor
documents, reference images and source images.
· References by UID to other instances or entities not included within
the set are removed or replaced with consistent, well-formed, dummy
references.
If the same instances are exported multiple times on different
occasions, the identifying attributes and UIDs therein may or may not
be replaced with the same values on each occasion."

The easiest way to do that is to maintain a map old old UIDs to new
UIDs ... as new objects are encountered, consult that map ... if
present, use the replacement, if not, generate a new UID, add it to
the map, and use it. This strategy was first shown to me by John Perry
who wrote the MIRC FieldCenter tool that does this, and there are
examples in dcuidchg in my dicom3tools and
com.pixelmed.dicom.ClinicalTrialsAttributes.removeOrRemapUIDAttributes()
in my pixelmed toolkit. Of course you need to distinguish transient
UIDs that need to be re-mapped versus persistent UIDs that must not be
(like the SOP Class). See for example
com.pixelmed.dicom.UniqueIdentifierAttribute.isTransient().

Ref:

deindentifcation typical profile

Mathieu Malaterre wrote:
> Hello,

>   I am in the process of removing any patient information burned in
> the image. I made the following changes:

> 1. Replace Value #1 of Image Type by 'DERIVED'

Don't do that ... leave Image Type alone (unless you are changing
the UID ... vide infra).

> 2. Add a Derivation Description with a comment specifying the position
> of the replaced region

Don't do that either, since it is not a derived image ... you could use
the De-identification Method (0012,0063) attribute instead to say
something generic about what you are doing; but it is a Patient level
attribute so it can't contain image-specific information like regions.

Why do you want to retain the region information, by the way ? If you
do need it, you should probably find a standard attribute to encode
it in (rather than a flattened string).

> 3. Add an Item in Source Image Sequence

Don't do that, since this sequence is only used for derived images,
and the reference is to the SOP Instance UID, which you say you
are not going to change. An image can't reference itself in Source
Image Sequence, obviously (I should perhaps add a validator check
for that).

>   The question is: I need to *append* any new Item in the Source Image
> Sequence, right ? that is to say my new item should be the last item
> of the sequence at the end of the process.

Whilst Sequence items are defined to be an "ordered set" (PS 3.5 7.5),
the order is not strictly defined to have meaning for this attribute,
since it may either contain multiple references that were combined to
a single image, multiple successive steps, or both (see the notes in
PS 3.3 C.7.6.1.1.4)

But in this use case, that is irrelevant anyway since you are not
changing the UIDs (vide supra).

If you were, you still can't depend on the order as a receiver, but
should add to the end of it, or remove previous content (or keep
previous content but of course re-map the UIDs to their de-identified
versions).

>   BTW since my new instance will have the exact same Instance UID, how
> do PACS system handle when both the original and the new instance are
> sent ?

Undefined and unpredictable, so you have to be sure that any PACS never
gets these two "versions" of the same SOP Instance UID.

Note that it is debatable whether or not you should change the UIDs when
de-identifying; for very thorough de-identification you can, as long as
and make sure that they are consistently changed within a set of objects
you reference each other; but there may be cases when it is desirable
to retain the UIDs (e.g. to provide a trace back to the original
modality), or harmless (e.g., a threat to recover identity would require
access to a PACS database to match UIDs to identities anyway).

If you want to maintain both "versions" in conventional PACS, you have to
change the UIDs (and then you could make it derived and use the Source
Image Sequence and Derivation Description).

We are doing some more work on "profiles" for specific de-identification
purposes in DICOM WG 18 to add to PS 3.15, so you may want to be involved
in that activity. 

Overlays

Overlays does not seems to be supported in Secondary Capture.

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox