In the latest installment of our ongoing series, PACS consultant Michael J. Cannavo explains how changing the way the DICOM standard is implemented in PACS is the key to making broader fixes in the industry.
As any parent of an adolescent knows, rules need to be established early and enforced consistently if you are to have any control of children as they develop. To the PACS market's credit, we started out establishing PACS "standards" back in the early 1980s, before filmless imaging was even ready for prime time. DICOM version 1.0 came out in 1985, version 2.0 in 1988, and the current version, 3.0, considered by most as the first successful version of the DICOM standard, in 1993, when the market was just taking off.
On the plus side, work was done very early on to establish some form of standards. On the minus side, DICOM has become, in my opinion, a Burger King standard at best, one that allows you to "Have It Your Way" and in doing so has become the most nonstandard standard ever created.
Anyone who has read or tried to read a vendor DICOM conformance statement knows you need both a Ph.D. and a bottle of NoDoz to get through it. And since DICOM adherence is critical to the success or failure of any PACS implementation, a client needs to either hire someone to make heads or tails of the PACS and modality vendor's DICOM conformance statements, or be diligent in holding both the modality and PACS vendors' hands to the fire together to make sure it all works as planned. This is why it is crucial to provide the PACS vendor with the manufacturer, model, and software revision number of each modality that will be connected to the PACS network prior to signing a contract, so everyone knows up front what they are dealing with.
A standard without teeth?
Why are DICOM conformance statements so complicated? To avoid having any one vendor enforce its "rules" on another, the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA), which jointly developed DICOM back in 1982, decided to make certain parts of the DICOM standard mandatory, other parts conditional, and others optional. This is what DICOM conformance statements address -- who addresses what how. (If you're interested, a great explanation of DICOM conformance statements is provided at: www.leadtools.com/sdk/medical/DICOM/dicomstnd.htm.)
While all radiologists know about the ACR, they may not know about NEMA. In a nutshell, NEMA represents, in this case, the PACS and modality vendors. What's interesting is that one of NEMA's stated goals is "to promote the competitiveness of its member companies by providing a forum for the development of technical standards that are in the best interests of the industry and the users of its products."
That said, did we do well by letting the wolf guard the hen house? The "best interests of the industry" seem to definitely have been addressed, but what about "the users of its products"? By having employees of each company on the "standards" development team, the participating companies ensured that the best interests of their companies were represented.
And the end users? Well … David Clunie, the preeminent standards guru in medical imaging and a genius when it comes to all things standards-related, summed it up well in a medical image format FAQ posting on the Web site www.faqs.org: "… DICOM conformance does not guarantee functionality, it only facilitates connectivity. In other words, don't get too carried away with espousing the virtues of DICOM, demanding it from vendors, and expecting it to be the panacea to create a useful multivendor environment."
So why don't all vendors get behind standards initiatives like DICOM, HL7, and now Integrating the Healthcare Enterprise (IHE) and support it 100%? Because they don't have to.
Constancy and consistently are key in raising a child, especially one in adolescence, yet end users have allowed vendors to dictate the rules to them, not the other way around. Vendors have become the parents and end users the children. This needs to be changed.
If you look at PACS archives alone, less than half in use today are fully DICOM-compliant, despite the fact that the DICOM Part 10 - Media Storage and File Format -- which addresses archive storage -- has been around since 1994. The problem we have with standards in PACS is that there is nothing standard about them. They are not mandatory -- they are voluntary. And end users simply aren't smart enough or haven't been properly educated on how to determine if the vendor supports DICOM in the manner that it should (nor frankly do they need to be either).
As I write this I'm dealing with "requesting" that my 13-year-old son Matt clean his room. To whose standard, he asks? To his standard it's clean. To the health department's standard, it's marginal at best. To my standards, it's a mine field waiting to explode and take out the entire right side of my house.
What's funny (but not) is that his room makes his older brother Nick's look like it belongs on the cover of Martha Stewart Living. Since he can navigate through it, though, he considers it clean. Vendors do the same with DICOM. Because they can claim they are DICOM-compliant that's simply enough for most of them. Unfortunately this doesn't mean they are DICOM-conformant. My room can look clean and even feel clean (to me), but it really isn't clean.
We need to make standards just that -- standards -- without the need to identify mandatory, conditional, or optional ways we adhere to them. I'll do this but I won't do that, and might do the other but only if you do this first. We have become our own worst enemies, creating standards that are not standards at all. The JPEG photo standard incorporates 57 different internal file formats (IFFs), yet when you click on any JPEG photo you can view it using a viewer that is a JPEG viewer without having to have a JPEG-compliance statement.
Now, I know I'm dramatically oversimplifying the situation by comparing medical images and the plethora of information that accompanies them with a simple photographic image, but the concept remains the same. Everyone should support DICOM, HL7, and IHE and be able to document the full extent of that support without relying on a 60-page document.
Most important, purchasers need to feel comfortable that the modalities and PACS they have bought in recent years are DICOM-compliant, not just DICOM-conformant, requiring a $20,000, $30,000, $50,000, or more "upgrade" to give them what they should have had all along. If we stop pussyfooting around and get some teeth into the standards, this won't be so hard to do. Comply or die -- it's just that simple.
The DICOM 'guidelines'?
The original ACR Technical Standard for Teleradiology was drafted in 1994 and has had only very minor changes to it since then, even though it was last "updated" in October 2005. In the early 1990s there were nearly 60 companies dedicated to teleradiology -- now there are virtually none. In the interim, though, a whole cottage industry has sprung up -- teleradiology overread services. This industry has very little, if any, regulation other than that mandated by the states relating to licensure, and even that is dubious at best.
The ACR Technical Standard for PACS (known officially as the ACR Standard for Digital Image Data Management) was first drafted in 1998 and hasn't even had a marginal upgrade since 2002. The problem is, while both of these call themselves standards, they are anything but, and instead couch themselves with language that would make the late Johnny "If the glove doesn't fit, we must acquit" Cochran proud.
While it looks like a duck, quacks like a duck, walks like duck, and even calls itself a duck, the standard isn't really a standard, but rather a "guideline" and an "educational tool to assist practitioners in providing appropriate radiologic care for patients." Right!! Bill Cosby was right in his monologue about Noah and the ark -- "Who's gonna clean up the bottom of this boat?"
The existing guidelines don't acknowledge the significant advancements made with display and networking technology in recent years, especially as they relate to network security. They also fail to address key medicolegal areas like the use of data compression, instead stating that compression needs to be only "selected and periodically reviewed by the responsible physician to ensure appropriate image quality." One man's acceptable is another's unacceptable. With virtually every vendor using a proprietary compression subroutine in conjunction with image distribution via the Web, this cannot be ignored any longer, especially since many radiologists make preliminary diagnoses from these same images.
This brings us to another area that needs to be addressed -- is there really such a thing as a preliminary diagnosis? If an ER physician treats a patient based on the interpretation of the radiologist using teleradiology, who is responsible if an interpretation is misdiagnosed due to what a prosecuting attorney or his or her expert witness might consider excessive data compression on a missed read? The ER doc? The radiologist? The hospital? The vendor?
The answer is E -- all of the above -- except that vendors typically couch their contracts with language that at least marginally insulates them from lawsuits related to the skill sets of the radiologist versus the ability of the software to compress data properly, although both are in play here. Every day I see compression ratios of up to 60:1 being used in Web scenarios, and frankly it scares the hell out of me. True, there is a requirement that the compression ratio be displayed on any compressed image, but what may or may not be acceptable remains to be seen.
Frankly, data compression was a very big deal in the days of low-speed dial-up Internet connections, and even moderate (128-512 Kb/sec) ISDN lines, but for $50 a month now most offices and homes use DSL or cable modems that provide speeds of between 1 and 3 Mb/sec downstream and upstream rates of nearly 1 Mb/sec. Virtual private networks (VPNs) are also used extensively, providing speeds of up to 100 Mb/sec. And newer streaming technologies provide diagnostic-quality data on demand by "painting" data in the background as you view it, even though this is technically a form of data compression (but it does give you access to the full uncompressed dataset, a huge advantage).
Do we still really need data compression? Not really, at least not in my opinion. If you compress with anything other than lossless JPEG or standards-based JPEG 2000 at the archive level, you lock yourself into the vendor for life. Just ask any of the facilities trying to perform data migration from their legacy PACS to a new PACS that didn't know this. It's an eye- and wallet-opener for sure.
How to fix it
So, what are the answers? If I were king of radiology, the first thing I would do would be to make DICOM support mandatory and abolish the three-tiered approach -- make what needs to be mandatory mandatory and eliminate conditional and optional. Getting two vendors to agree on this, let alone 50, is going to be a challenge, but it needs to be done.
Second, I would set a deadline to abolish the use of any non-DICOM components in a PAC system design, especially archives. It's been 12 %^$@!! years since DICOM part 10 was established -- let's get with the program! Even my son can get his room cleaned in less than 12 years. Give them a year and then….
Third, make IHE support mandatory. IHE is the future, and if we are going to make investments in the future IHE must be a part of it. Until IHE defined a set of IHE Radiology Integration Profiles, there was no agreed method for the various systems involved (i.e., HIS, RIS, PACS, modalities, printers, workstations, etc.) to work together to manage typical patient care situations. The IHE Scheduled Radiology Workflow integration profile combines ADT and order messages defined in HL7 with scheduling, worklist, status notification, storage commitment, and other services defined in DICOM.
Today there are 16 Radiology Integration Profiles, which are published in the IHE Radiology Technical Framework and available on the RSNA IHE Web site for download and review. Get familiar with them. While IHE does not create new standards, it drives the adoption of standards to address specific clinical needs, something that is desperately needed.
Finally, PACS has been around now long enough where we have some pretty good luminary users who can provide input on items like data compression, network security, etc. Set a finite limit for data compression use (20:1 for chests, 8:1 for MRI, 6:1 for ultrasound, etc.) and stick to it. Don't put the radiologist or clinician at risk wondering if he or she is next in line for the lawsuit from Hades. It's just not worth it. Use the knowledge and expertise that is out there, and let's set real standards that can be followed and adhered to easily that don't require a book to decipher.
Have I oversimplified an exceptionally complex situation? No question. I also don't mean to minimize the work done by those various individuals and committees who have dedicated their time and efforts in the past two decades trying to put some semblance of order to something that probably can't be given order. After all, we're not just dealing with a 13-year-old who will lose computer and TV privileges if his room isn't cleaned right, but multijillion-dollar companies who have vested interests trying to "have it their way."
To them I say what I tell my sons: let's compromise. Do it my way and when you are out on your own, then you can do it your way. After all, the last time I checked, PACS was a market developed to help radiologists and clinicians to improve patient care, not make life easier for the vendors.
Reading back at the last line I can only smile, hearing my parents telling me the same thing when I was 13: "I'm not here to make life easy for you but to help you become the man we know you have the potential to be." At age 50, with life all but behind me, I realize I've become my parents, not just with my own kids, but to an industry that has occupied nearly half my life as well. Becoming just like your own parents really isn't that bad … my only regret is that I never listened to them way back when.
By Michael J. Cannavo
AuntMinnie.com contributing writer
April 20, 2006
Michael J. Cannavo is a leading PACS consultant and has authored nearly 300 articles on PACS technology in the past 15 years. He can be reached via e-mail at [email protected].
The comments and observations expressed herein do not necessarily reflect the opinions of AuntMinnie.com, nor should they be construed as an endorsement or admonishment of any particular vendor, analyst, industry consultant, or consulting group. Rather, they should be taken as the personal observations of a guy who has, by his own account, been in this industry way too long.
Related Reading
Part VIII: Exploring PACS Secrets -- It's broke, fix it, April 6, 2006
The 2005 PACSman Awards: This PACS is your PACS, this PACS is my PACS, November 30, 2005
Part VII: Exploring PACS Secrets -- Pre-RSNA edition, November 28, 2005
Part VI: Exploring PACS Secrets -- State of the market, October 10, 2005
Part V: Exploring PACS Secrets -- Buyers and sellers, December 16, 2004
Copyright © 2006 AuntMinnie.com
