Writing DICOM
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:
- http://mri.radiology.uiowa.edu/VHDicom/ (used to be here)
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:
- Measurement and/or data collection, identified by Acquisition Datetime (0008,002A) in the Encapsulated Document Module.
- Creation of the original documentation of the data collection, identified by Content Date (0008,0023) and Content Time (0008,0033).
- 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.
- 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:
- http://groups.google.com/group/comp.protocols.dicom/browse_frm/thread/34a8b7c73d1791c9/0f9339168e1a3a17
- DICOM Part 16
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:
- Examples of Derived Images that would normally be expected to affect professional interpretation and would thus have a new UID include:
- images resulting from image processing of another image (e.g. unsharp masking),
- a multiplanar reformatted CT image,
- a DSA image derived by subtracting pixel values of one image from another.
- 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.
- 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:
- Video interfaces that convert an analog video signal into a digital image
- Digital interfaces that are commonly used to transfer non-DICOM digital images from an imaging device to a laser printer
- Film digitizers that convert an analog film image to digital data
- Workstations that construct images that are sent out as a screen dump
- Scanned documents and other bitmap images including hand-drawings
- 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:
- 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
- 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
- Modality Specific Characteristics
- 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)
- Value 1 shall identify the Pixel Data Characteristics; Enumerated Values for the Pixel Data Characteristics are:
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:
- http://www.ihe.net/Technical_Framework/
- http://www.ihe.net/Technical_Framework/upload/IHE_TF_Suppl_Teaching_File_Clinical_Trial_Export_TI_2005-04-22.pdf
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.
