Modifying DICOM Header Data... - DICOM

This is a discussion on Modifying DICOM Header Data... - DICOM ; Hello cpd, 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 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Modifying DICOM Header Data...

  1. Modifying DICOM Header Data...

    Hello cpd,

    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

  2. Re: Modifying DICOM Header Data...

    Hi Peter

    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 wrote:
    > Hello cpd,
    >
    > 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


  3. Re: Re: Modifying DICOM Header Data...

    Hello David,

    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.7040408@dclunie.com>, David Clunie 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.

+ Reply to Thread