DICOM STATUS TAG

50 views
Skip to first unread message

Micke

unread,
Sep 25, 2008, 5:09:10 PM9/25/08
to
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

David Clunie

unread,
Sep 26, 2008, 9:00:30 AM9/26/08
to
Hi Mike

Micke wrote:

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 all
Reply to author
Forward
0 new messages