Ordering of Items in Source Image Sequence
Mathieu Malaterre
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'
2. Add a Derivation Description with a comment specifying the position
of the replaced region
3. Add an Item in Source Image Sequence
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.
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 ?
Thanks
-Mathieu
Marco Eichelberg
> 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.
This would be an appropriate approach. In some places the order in which
items are stored in a sequence is not significant, but I don't think this is
spelled out clearly in the standard. In ASN.1 (where I believe the concept
of a "Sequence" has been borrowed from), a Sequence structure has the properties
of a set in mathematical terms, i.e. there is no implicit order of members of
the set.
> 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 ?
Bad idea, because the behaviour of the PACS is undefined. Some PACSes might
reject the image, some PACSes might accept but silently discard the image,
some PACSes will put the image on the administrator's worklist as a conflict
that needs manual resolving and some might even silently delete the original
and replace it by your modified copy.
Regards,
Marco Eichelberg
Mathieu Malaterre
wrote:
> Mathieu Malaterre wrote:
> > 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.
>
> This would be an appropriate approach. In some places the order in which
> items are stored in a sequence is not significant, but I don't think this is
> spelled out clearly in the standard. In ASN.1 (where I believe the concept
> of a "Sequence" has been borrowed from), a Sequence structure has the properties
> of a set in mathematical terms, i.e. there is no implicit order of members of
> the set.
ok, thanks.
> > 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 ?
>
> Bad idea, because the behaviour of the PACS is undefined. Some PACSes might
> reject the image, some PACSes might accept but silently discard the image,
> some PACSes will put the image on the administrator's worklist as a conflict
> that needs manual resolving and some might even silently delete the original
> and replace it by your modified copy.
I am not sure I understand what you mean by 'bad idea', according to
my understanding of the standard, this is what is expected.
If I understood correctly C.7.6.1.1.2, I am required to change the SOP
Instance UID if the Pixel Data is significantly changed. Since I am
only removing burned-in annotation, I thought I could follow C.
7.6.1.1.3, which says:
...
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.
...
So having a DERIVED image with identical SOP Instance UID is a valid
case, right ? Or did I misunderstood something ?
Thanks
-Mathieu
Mathieu Malaterre
On Apr 25, 11:00 am, Mathieu Malaterre <mathieu.malate...@gmail.com>
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'
> 2. Add a Derivation Description with a comment specifying the position
> of the replaced region
> 3. Add an Item in Source Image Sequence
I was only referencing the SOP Class UID (0008,1150) and the SOP
Instance UID (0008,1155), but I forgot to add a Purpose Of Reference
Code Sequence data element (0040,a170) with value:
DCM 121322 Source image for image processing operation
-Mathieu
David Clunie
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.
David