Incomplete Q/R implementations - DICOM

This is a discussion on Incomplete Q/R implementations - DICOM ; I have recently encountered a number of DICOM implementations which claim to support the PATIENT or STUDY root Q/R models (in their conformance statements and by negotiation), yet fail to handle queries (C-FIND &/or C-MOVE) below the study level. When ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Incomplete Q/R implementations

  1. Incomplete Q/R implementations

    I have recently encountered a number of DICOM implementations which
    claim to support the PATIENT or STUDY root Q/R models (in their
    conformance statements and by negotiation), yet fail to handle queries
    (C-FIND &/or C-MOVE) below the study level. When I have challenged
    some of them on this, the response has been "we make it clear in out
    conformance statements that we don't support SERIES and IMAGE level
    queries, so we're legal."

    My immediate response to this is that support for the lower levels in
    the PATIENT and STUDY models is NOT optional, and therefore may not be
    "talked away" in a conformance statement, and in fact, vendors with
    deficient implementations like this should ONLY claim conformance to
    the PATIENT-STUDY ONLY model. However, some of the companies involved
    are major players in the industry, and therefore I would like to hear
    other peoples' thoughts on this before challenging further, by pointing
    out that such implementations do NOT conform to the DICOM Q/R roots
    claimed (and thereby also invalidating their IHE conformance).

    I am concerned that (like proprietary worklists) this seems to be
    creeping in as a means of giving "unfair advantage" to the PACS vendors
    own workstations (not using DICOM and able tro get just selected
    images) compared to 3rd party workstations which are being forced to
    retrieve whole studies...."well of course you could use DICOM if you
    wish, but our own mechanisms are a lot faster!"


  2. Re: Incomplete Q/R implementations

    Dave

    The Patient-Study model was put into place after the fact to provide a
    "legal" encoding for PACS who do just what you describe.

    Unfortunately, there aren't any DICOM police or legal restrictions on
    the DICOM name that would constrain vendors from claiming partial
    implementations are DICOM compliant. Even though few users ever query
    below the study level, I've seen very few implementation that actually
    use the Patient-Study SOP class for querying.

    >From the vendors point of view, having already provided a partial

    implementation under Study-Root or Patient-Root that gives the users of
    these systems basic interoperbility with 3rd party workstations, why
    should they sudden switch to Patient-Study root? Many of the
    applications using their interface would stop working if they did
    (because those applications haven't implemented P-S root SCU either).

    Without a penalty for partial/non-compliant implementations and a
    definite customer penalty for complying with the standard, there's no
    business case for the vendors to "come clean" and change their
    applications to use P-S Only.

    While we can understand your frustration, there's not really any good
    fix with the install base thats already working with these partially
    implementations. No one is going to make the vendors fix their systems.


    With regards to the IHE, most profiles don't specify building worklists
    based solely on information gleaned through Q/R. Instead worklist
    managers are supposed to receive HL7 messages, or PPS messages (with
    instance UIDs) or image availbility notifications, or the images
    themselves to build the specific lists. It would be a worthwhile
    activity to point out specific profiles where there is a clear
    dependence on getting series and image level information through
    query/retrieve. If you can make your case, you might be able to press
    for the IHE to spotlight non-compliant vendors.


  3. Re: Incomplete Q/R implementations

    Eric,

    Thanks for the feedback - I know well the issues regarding compliance
    etc. - it is of course up to the USERS to complain long and loud that
    they were misled by their vendors lies about DICOPM compliance. The
    IHE issue does however give a little more scope than you suggest for
    enforcement (or at least naming and shaming!), as IHE transaction 14
    (query Images) explicitly states:

    "The Image Display uses one or more matching keys as search criteria to
    obtain the list of matching entries in the Image Archive at the
    selected level (Patient & Study/Series/Image). Based on this list of
    entries, the Image Display may select relevant entries to be
    retrieved."

    Transaction 14 is mandatory for IM/IA in IHE Scheduled Workflow, so to
    put it bluntly, any vendor whose PACS can't be bothered to implement
    Q/R properly does NOT conform to the IHE Scheduled workflow
    profile.....

    Dave


  4. Re: Incomplete Q/R implementations

    PS,

    One thing I forgot to mention is that this sort of retrieval is likely
    to get much more important in the future, with large datasets
    (multi-slice CT etc.) combined with KON objects to define a usable
    sub-set. There's little point of course in having a defined sub-set
    (to reduce network usage amongst other things), if you need to pull a
    whole study anyway due to a defective PACS!

    Dave


+ Reply to Thread