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.