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:

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

(*) 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:

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.

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.

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:

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).

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.

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:

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.

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:

> 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.

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.

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().

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.