DICOM STATUS TAG - DICOM

This is a discussion on DICOM STATUS TAG - DICOM ; Hi! We are doing a cross enterprise infrastructure combined of several different PACS and different RIS-systems. What we now found out when we want to interact between these systems that we are lack of a DICOM tag where we can ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: DICOM STATUS TAG

  1. DICOM STATUS TAG

    Hi!
    We are doing a cross enterprise infrastructure combined of several
    different PACS and different RIS-systems. What we now found out when
    we want to interact between these systems that we are lack of a DICOM
    tag where we can set the status for the report.
    To create the report we generate SR from both HL7 ver 2.x as HL7
    Ver3.x but when we want to add a status for that report we canīt find
    a DICOM tag to put the status in. In this tag we want to put 3
    different levels of status, unsigned, prel signed and def signed.
    We also wants to put this outside the SR container due to update
    requests from the RIS-systems

    Anyone have some suggestions?

    Br
    Mike

  2. Verification status of Structured Reports, was Re: DICOM STATUS TAG

    Hi Mike

    Micke wrote:

    > We are doing a cross enterprise infrastructure combined of several
    > different PACS and different RIS-systems. What we now found out when
    > we want to interact between these systems that we are lack of a DICOM
    > tag where we can set the status for the report.
    > To create the report we generate SR from both HL7 ver 2.x as HL7
    > Ver3.x but when we want to add a status for that report we canīt find
    > a DICOM tag to put the status in. In this tag we want to put 3
    > different levels of status, unsigned, prel signed and def signed.
    > We also wants to put this outside the SR container due to update
    > requests from the RIS-systems


    There are two attributes in the "header" (not the SR content tree)
    of a DICOM SR that are related to its status with respect to
    "completion" and "verification".

    The Completion Flag (0040,A491) is defined to be "the estimated
    degree of completeness of this SR Document with respect to
    externally defined criteria in a manner specified in the
    Conformance Statement."

    It has enumerated values of PARTIAL and COMPLETE.

    The Verification Flag (0040,A493) "indicates whether this SR Document is
    Verified" and has enumerated values of UNVERIFIED and VERIFIED.

    Though it is not explicitly stated, the usual expectation is that
    a document should be flagged as COMPLETE before it is verified,
    which means that there are really three states possible:

    - PARTIAL and UNVERIFIED
    - COMPLETE and UNVERIFIED
    - COMPLETE and VERIFIED

    I mention this in case you are tempted to use PARTIAL UNVERIFIED
    to indicate a "preliminary signed" report, which would probably
    be a bad idea.

    So, for your purposes:

    - "unsigned" is easy - COMPLETE and UNVERIFIED
    - "def(initively ?) signed" is easy - COMPLETE and VERIFIED

    Flagging that something is a "preliminary signed" report is not
    currently defined.

    Now, one could consider adding some sort of modifier attribute to
    the verification attributes to indicated "preliminary" versus
    "not preliminary", but then we get onto the slippery slope of
    trying to deal with other variants, like "amended" reports
    after it is supposedly final but a problem is found, as well
    as the difference between senior staff signing off after review
    of junior staff reports as distinct from a single person's
    preliminary read versus their final report, etc. Not that one
    could not construct a model of this behavior but rather can
    one get two implementors (or sites) to agree to use the same
    model.

    In the absence of such a model or additional attributes, one
    could consider trying:

    - "unsigned" - PARTIAL and UNVERIFIED
    - "preliminary signed" - PARTIAL and VERIFIED (cringe)
    - "def(initively ?) signed" - COMPLETE and VERIFIED

    but as I said before, this violates the assumption that
    you can't verify something that is not complete - probably to
    the point that even thinking about this is likely to lead to
    a DICOM CP forbidding it explicitly.

    There is also an important note that says "that the 'prevailing final
    version' ... is the version having the most recent Verification
    DateTime (0040,A030), Completion Flag (0040,A491) of COMPLETE
    and Verification Flag (0040,A493) of VERIFIED."

    This anticipates that reports may be finalized and amended
    repeatedly, and that the recipient should always be checking
    the Verification DateTime.

    David

+ Reply to Thread