Contradictions between IHE and VA requirements? - DICOM

This is a discussion on Contradictions between IHE and VA requirements? - DICOM ; Hello, I'm not sure whether this is the right forum to discuss my question, but I thought I would give it a try. In IHE it is required that if the information for type 2 attributes (e.g Patient Name or ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Contradictions between IHE and VA requirements?

  1. Contradictions between IHE and VA requirements?

    Hello,

    I'm not sure whether this is the right forum to discuss my question,
    but I thought I would give it a try.

    In IHE it is required that if the information for type 2 attributes
    (e.g Patient Name or Patient ID) is not known that they should be zero
    length, and no replacement values (like UNKNOWN) shall be used (IHE
    Vol 2 Section 2.2). However VA makes those attributes type 1
    attributes, meaning that they always have to have a value. This might
    end up being a problem for the unscheduled IHE case in an emergency
    scenario, when you don't know the patient name and you should not enter
    a value, based on the assumption that systems for the VA need to be IHE
    compliant as well.

    Thanks in advance for your clarifications
    Antje


  2. Re: Contradictions between IHE and VA requirements?


    Antje Schroeder wrote:
    > Hello,
    >
    > I'm not sure whether this is the right forum to discuss my question,
    > but I thought I would give it a try.
    >
    > In IHE it is required that if the information for type 2 attributes
    > (e.g Patient Name or Patient ID) is not known that they should be zero
    > length, and no replacement values (like UNKNOWN) shall be used (IHE
    > Vol 2 Section 2.2). However VA makes those attributes type 1
    > attributes, meaning that they always have to have a value. This might
    > end up being a problem for the unscheduled IHE case in an emergency
    > scenario, when you don't know the patient name and you should not enter
    > a value, based on the assumption that systems for the VA need to be IHE
    > compliant as well.
    >
    > Thanks in advance for your clarifications
    > Antje


    The VA has made the determination that certain flexibilities allowed or
    even mandated by the IHE integration profiles represent a risk to the
    integrity of their electronic patient record.

    For example Study UIDs in the Radiology Order ZDS segment, its use on
    the Modality worklist, and behavior mandated for both the modalities
    and PACS to "use the ZDS UID". When you delve into the detail of what
    they mean by "use", you'll find it is in contradiction to the IHE
    specification

    The IHE in its year one integration framework made a still somewhat
    controversial decision for modality handling of the Study UIDs
    provided on the modality worklist. That decision was to direct the
    modalities to generate and use their own Study UID rather than the MWL
    supplied Study UID in certain cases. The situation where the IHE
    directs this behavior is in cases where the one requested procedure to
    one DICOM study breaks down --ie the infamous group case. Not only does
    the modality generate its own Study UID, it also explicitly and
    deliberately leaves the Accession Number null in the resulting images.
    Both of these are indicators to the Image Manager that the image is
    part of a single imaging set which was acquired to satisfy the
    acquisition requirements for multiple requested procedures, whose
    identifiers are embedded elsewhere in the image.

    The VA has had bad experiences with various vendors or integration
    combinations which have resulted massive generation of non-unique Study
    UIDs. Papers published by their imaging development group estimate a
    frequency potentially as high as 1 in 1000 studies has a non-unique UID
    ( http://www.cis.upenn.edu/hcmdss/Pape...issions/14.doc )

    Personnally I think this estimate is overly high for the industry as a
    whole, but they also have their own data to draw from. Non-unique UIDs
    can have devastating effects, especially when the problem is
    systematic. The IHE itself encourages vendors to assume the Study UID
    carries a known patient context. Hence if one already knows the patient
    context for a specific Study UID, when you encounter that UID later on,
    you can assume the patient context is the same (or so the theory goes)
    Normally this would be true, except when its not. The VA has lived
    through large scale corruption of supposedly unique identifiers,
    whether they were DICOM or patient, and from those experiences has
    learned not to trust them to be unique.

    Commercial systems often, but not always, use methods and
    techninologies to identify and correct or stop these situations before
    they get out of control. The VA's internal imaging and informatics
    infrastructure is of a scale and uses older technologies such that it
    is in most cases impractical for them to detect these situations as
    they occur. As a result, the VA has articulated requirements on
    commercial vendors which are different from those currently agreed upon
    in the IHE.

    For Study UIDs, they have taken the tack that imaging data must
    conform to a VA generated Study UID in order to be ingested into the
    VA's imaging storage systems, and since the VA software cannot enforce
    this requirement itself, the commercial vendors are being mandated to
    do it for them, even though that mandate runs contrary to the IHE
    specification.

    I'm sure there is a similar story behind the patient Id and name, and
    the rejection of the unscheduled patient case. If you dig further I'm
    pretty sure you will find the rationale cited as being "business
    rules".

    One criticism I would level at the VA is they are attempting to mandate
    these requirements in stealth mode rather than being quite open and
    forthright as to what they are requiring, how it is different from the
    industry norms, and their rationale for bucking the IHE requirements.
    An open airing of the issues might avoid additional issues where
    functionality which works in an open industry standard integration
    environment fails when installed in the VA environment. It would might
    also convince the IHE that their standards are ignoring serious issues
    which will come to light electronic patient records begin to reach the
    scale which the VA has already achieved.


+ Reply to Thread