Modifying DICOM Header Data...
Peter B Schmidt
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...
Any help is highly appreciated!
Have a nice day,
Peter
David Clunie
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.
>> Any Attribute from the main data set that was modified or removed
David
Peter B. Schmidt
please excuse me for answering so late, I am trying to find a method of accessing cpd while I am "on tour".
In message <45D32DEF...@dclunie.com>, David Clunie <dcl...@dclunie.com> wrote:
>Hi Peter
> Is
>there something about it that does not meet your needs ?
No, this is perfect! I would never have found this, and never as fast - I suspect you know each and every chapter of the Standard by heart! Thank you very much.
If you heard a Sound when I read your posting, this was the sound of a dying "Shodow Group", I am positive that my client will adapt the standard way and throw away the existing "Private Tag Workaround".
Thank you very much,
Peter
This article is posted by A4Pocket Newsreader from Pocket PC. View http://www.a4pocket.com for detail.