For Modality Worklist, the acquisition device must query for the following fields in addition to those specified in IHE transaction RAD-5:

Referring Physician’s Name (0008,0090)
Patient Birth Date (0010,0030)
Patient Sex (0010,0040)
Other Patient IDs (0010,1000)

The modality must be able to perform five different kinds of queries:

1) Broad query (no matching keys and by Scheduled Procedure Start Date)
2) Patient Name query (by name and short cut)
3) Patient ID query (by ID and short cut)
4) Accession Number query (by accession number and short cut)
5) Requested Procedure ID query

Our business rules use selection “short cuts” for the patient name, patient ID, and accession number. For example, the patient ID short cut is the first initial of the surname followed by the last four digits of the medical record number. We have implemented these short cuts in our modality worklist provider and expect the modalities to be able to support queries using them.

For Storage, the following DICOM data attributes are required in addition to those specified in IHE transaction Rad-8:

Accession Number (0008,0050)
Referring Physician’s Name (0008,0090)
Patient’s Name (0010,0010)
Patient ID (0010,0020)
Patient Birth Date (0010,0030)
Patient Sex (0010,0040)
Other Patient IDs (0010,1000)
Manufacturer (0008,0070)
Institution Name (0008,0080)
Manufacturer’s Model Name (0008,1090)
Station Name (0008,1010)
Software Version(s) (0018,1020)

The DICOM objects must conform to the DICOM standard. We also require that the modality use the Study Instance UID (0020,000D) obtained from the modality worklist query and generate the Series Instance UID (0020,000E) and SOP Instance UID (0008,0018) using the vendor’s own UID root.

We perform the validation testing using the DICOM Validation Toolkit[4] and our VistA hospital information system (HIS) and PACS (VistA Imaging and DICOM Gateway). The tests are performed over the Internet between the vendor’s lab and our development facility.

Validation testing has been a very fruitful endeavor, not only because it helps to insure interoperability, but also because it allows us to develop working relationships with vendors and influence the course standards while products are being developed.

In 2001, the dental modalities only supported DICOM CD exchange; none supported any networking capabilities. Six vendors developed Modality Worklist and Storage services over that summer and worked with us to validate their implementations.

In 2002, retinal camera system vendors were not specifying laterality (that is, from the DICOM header you could not tell the left eye from the right). They were using the Visible Light Image Storage SOP Class, which did not require laterality. We contacted the American Academy of Ophthalmology, and they funded development of the Ophthalmic Photography SOP Classes in DICOM Working Group 9. Now all retinal camera systems use this SOP Class and generate DICOM objects that contain the necessary information.

In 2006, several vendors were developing systems that passed computer generated graphical reports via DICOM (visual fields, bone densitometry, balance management, etc.). Rather than use bitmapped Secondary Capture images, we suggested that they generate Encapsulated PDF objects, which are particularly well suited for this purpose.

Most radiology and cardiology vendors have mature DICOM products at this time and validation can be done rather quickly. It requires more effort to work with vendors in the clinical specialties, however. First, some of those vendors are resource-limited and there is often not a lot of incentive to “do DICOM” (for them, DICOM is not yet the sine qua non, as it is in radiology and cardiology). As a result, sometimes their efforts to perform DICOM interoperability testing are rather intermittent, with long periods of inactivity. Second, they often have a limited working knowledge of DICOM. One vendor proposed using a different modality value for each of their products, starting with C3X9MP. (This is clearly legal, but contrary to the spirit.) We suggested that they use a value already defined in the Standard for modality. Third, they sometimes do not understand how to do things efficiently. One vendor included almost the entire DICOM element dictionary as return keys in their modality worklist query (“give me everything that you can”). We suggested they only request the data elements that they needed. Finally, there are vendors who allege to have products that support SOP Classes, but provide no way of obtaining values for required (Type 1) data elements. Instead, they ignore them and create non-compliant DICOM objects. We have them use a proper SOP Class. We find that it takes a lot of effort to educate new vendors and help them to make their products work properly.

The validation testing and the usage of the results in purchasing decisions are completely voluntary. However, from experience, the vendors and the VA purchasing and imaging support people have learned the benefits of this testing and use it. Without validation, it is much more difficult and takes a great deal more effort to make these products to become successful in the VA.

The list of the approved DICOM modalities is published on our website, www.va.gov/imaging, along with the complete federal DICOM modality requirements and our testing procedures[2,5,6].

2) Joint VA/DoD DICOM Modality Conformance Requirements (Rev 3.0). www.va.gov/imaging.

3) IHE Radiology Technical Framework, Volume II, Transactions, Revision 9.0, June 27, 2008, http://www.ihe.net/technical_framework.

4) DICOM Validation Toolkit, http://www.dvtk.org.

5) VistA Imaging Approved DICOM Modality Interfaces (August 2009), www.va.gov/imaging.

6) DICOM Modality Validation Test Procedure (July 2009), www.va.gov/imaging.