There has always been need for DICOM Validation and there are many free DICOM validation tools available on the net. Having said that, here is my personal experience during this summer which should emphasize the need of using a proper DICOM Validation Tool in PACS environment. Please read through and give us your feedback on this subject by leaving your comments at the bottom.
I spent some time in Colorado this summer escaping the heat from Texas, and during our stay at the campground, our dog was rather badly bitten by another dog and had to get an X-ray done to make sure her lungs were not punctured. I was happy to see that they had a digital system and I obviously requested a CD of her images so I can keep it and share it back home with our regular Veterinarian. (where is our animal EHR so I could have uploaded this in her personal health record?) .
When I came back at our camper, I tried to view the images with a DICOM viewer on my laptop, but to my surprise and chagrin, the images would not display. I had to open the header with a DICOM simulator tool (OT-DICE) and found out that the patient ID was missing. After adding that information to the header, the image was displayable. Upon further investigation, it appeared that this was one of the most poor implementations of DICOM, and in particular, veterinary DICOM I have ever seen: The species information was filled in the study ID field, the breed in the accession number, the name in the study description filed, and so on. Very creative but very wrong as it uses fields that are allocated for other purposes.
When displaying the image in the proprietary embedded viewer on the CD, as one might expect, the information was displayed correctly on the screen as it knew where to look for what information. Obviously, the veterinary DICOM world appears to be light years behind human imaging with regard to standards implementations. This CD is totally incompatible with any common viewer and requires someone to go in and “hack” the image header. The images violate the DICOM standard and as soon as this veterinarian is going to upgrade their archive to another vendor, there will be a major migration and conversion effort ahead of him.
In the human medical imaging field, we are fortunately ahead of most of such problems. It is rare that an image misses a type 1 attribute such as a patient ID and most CD’s are pretty good with regard to standards compliance. We are already at the next level of interoperability by defining, within the IHE framework, a set of specifications for the CD viewer functionality and icons, triggered by complaints from physicians who are having trouble to figure out the plethora of different viewers out there. It is only too bad that the DICOM committee never has stepped up to promoting a set of validation and certification tools that vendors can use to certify as a minimum the compliance of their image header, and secondly their DICOM protocol implementation. This would have served the community a lot by avoiding the situations as I encountered personally. In the mean time, needless to say that I contacted the manufacturer and hopefully they felt compelled to take action and fix this.
In addition, I am sure that the veterinarian in Colorado, who has the digital system creating these poorly encoded images, did not have any idea of the problems she was creating. I told them they had an issue and urged them to contact their vendor and demand an upgrade, but who knows when or whether this will happen. My suggestion is that if you ever encounter a bad CD to contact the initiator and tell them about the problem, as they also often have no idea. Sometimes it takes only a configuration change and/or simple upgrade to make the images and CD’s compliant. Also, you might be creating poorly encoded CD’s and images as well, ask the vendor for IHE PDI compliance (which specifies how CD’s are to be properly encoded). If you are brave enough, you might even download one of the several freely available public domain DICOM validators and DICOM Validation Tools and check your compliance. It is definitely worth the effort!
Herman Oosterwijk, OTech Inc.