My parents always used to say, "If you can do it better, then go ahead and do it instead of complaining about it." With that in mind, I set out to write the Building a Better PACS series.
 |
| PACS consultant Michael J. Cannavo. |
So what does this entail? At the very least, this includes the following:
- Mandatory adoption and utilization of industry standards (DICOM, HL7, Integrating the Healthcare Enterprise [IHE], and the American College of Radiology's [ACR] Standards for Digital Image Management and Teleradiology)
- Eliminating anything considered "optional" in the standards as well as the overseeing of their adoption by the standards developer
- Eliminating any and all proprietary items in system designs, including the use of proprietary compression subroutines
- Standardized language to describe all system components and operation
- Avoiding marketing hype when describing system features and functions
- A fixed set of required image processing features common to all vendors
- Standardized vendor-neutral image archiving, including database management that does not require data migration
- Standardized quotes and warranty periods
- A standardized contract that allows vendors to "fill in the blanks" on areas such as uptime guarantees and penalties
- Eliminating flat-rate percentage pricing to determine project management, installation, training, and support cost
I'm sure there are many others that will become apparent and should be added to this list, but this will at least get us started. I also welcome input from end users on what else we need to do to get and keep PACS on the right path.
Many people might question why I have the adoption of standards on here. After all, doesn't everyone support DICOM, HL7, and IHE? Technically, one can say yes, but practically, one has to say no. Now don't get me wrong -- what has been accomplished since the standard was first developed back in 1985 is light-years better than we had before, but if it won't facilitate implementations, what good is it? Section 5 of the DICOM standard under "Goals" reads as follows:
Even though the DICOM Standard has the potential to facilitate implementations of PACS solutions, use of the Standard alone does not guarantee that all the goals of a PACS will be met. This Standard facilitates interoperability of systems claiming conformance in a multivendor environment, but does not, by itself, guarantee interoperability.
Even more telling is this statement on Page 1:
[National Electrical Manufacturers Association (NEMA)] has no power, nor does it undertake to police or enforce compliance with the contents of this document.
So if it can't facilitate interoperability and no one is really enforcing its use, why then do we call it a standard? Good question ... I would like to advance the hypothesis that having 26 vendors on the DICOM committee to develop the standard, about half of whom actually sell PACS products, hindered the standards adoption versus enhancing it.
Having it your way
DICOM became like Burger King -- you can have it "your way" by choosing what you do and do not wish to include in your conformance statement. The ACR's Technical Standard for Electronic Practice of Medical Imaging is no better, with the organization calling them "guidelines" and an "educational tool" in the preamble.
Living in a litigious society, it's obvious that no one wants to accept responsibility to say it has to be done this way or that way. Instead, they say nothing at all -- and let the wolf guard the hen house.
We need the Ten Commandments, not the Ten Suggestions, yet no one seems to stand up and say "you must"; they only say that "you should." The end result is end users buying products that can't easily or transparently be migrated from one vendor to another and that don't support what the customer thought it should.
Vendors will retort: "If the end users had read our DICOM conformance statement, they would know what we do and do not support." But should that really be necessary? It's easy to miss something in these statements; reading them is the cheapest and easiest cure for insomnia. So what is the solution?
- Make standards support mandatory. Products that do not support the standards should be unable to be sold. While this will require the U.S. Food and Drug Administration (FDA), the ACR, and the other agencies and committees to develop testing criteria against which the stated standards can be validated, it's high time we stopped allowing vendors to play the semantics game any longer.
- Eliminate the use of optional tags such as value representations (that are dependent on the negotiated transfer syntax) or even optional support of things like DICOM modality worklist or DICOM MPPS (Modality Performed Procedure Step). If they have it, you must support it. If not, then you are exempt.
- If DICOM attributes within the dataset are necessary, then make them mandatory; if not, then delete them.
- Eliminate the use of private tags if a public tag or object (such as annotation or graphic overlays) is available. If a public tag and private tag perform the same function, then the public tag must be used.
Once these steps are established, these very same committees must oversee their adoption to ensure that vendors strictly adhere to the standards. Failure to adhere to the standard should be treated just like a product recall. Bring it back and fix it, and don't sell any more until it's fixed.
Proprietary problems
It's also funny, in an unfunny way, that we spend so much time promoting standards, yet we still have proprietary hardware or software used in system designs. From video display cards to software compression subroutines, each vendor does things that are "one-off" from what the other guy does.
If you think that all vendors store images in a DICOM Part X file format, you are mistaken. Three of the top five leading PACS providers store images on the archive in their own way -- not in DICOM Part X -- because DICOM is too slow and they need to get images back faster to ostensibly increase their system performance.
Now keep in mind these are the very same vendors who were on the DICOM committee that developed this format, so if what they developed is so bad, why not just fix it instead of abandoning it altogether in favor of using their own proprietary solution?
The same holds true for actually storing data in a DICOM Part X file format and then using proprietary data compression to reduce the file size. In such situations, which are plentiful industry-wide, end users will be stuck indefinitely with that vendor. Again, this just isn't right, especially when we have standards-based compression subroutines like JPEG and JPEG 2000 that have both been incorporated into the DICOM standard.
So what is the solution? Use only off-the-shelf components within the computer and avoid anything proprietary. Also, use only standards-based data compression for image storage -- period.
Every vendor seems to call their system components something different, but in reality, a server is a server is a server. Or is it? When does a workstation become a diagnostic reading console or an archive become an image management storage solution? The answer is: When vendors get creative with what they call their components.
We need to have across-the-board industry-standard definitions for PACS components. If it captures and routes images, then it is a file server. If it disseminates images via the Web, then it's a Web server. If a radiologist interprets and dictates from the workstation, then it is a diagnostic viewing station. If a clinician reviews on a workstation a study that the radiologist has already interpreted, then it's a clinical workstation.
If a device stores images for longer than a predefined period of time (typically a year), then it is an archive (even if it also functions as a server, as it sometimes may do in smaller facilities). You can call it whatever you want, but you get my drift here.
You can even include the marketing hype if you wish, but make sure the customer understands what the heck they are buying, so they can make an apples-to-apples comparison of one vendor's offering to another.
Functionality
That leads me to my next two points -- marketing hype pertaining to functionality and having a fixed set of required image processing features that are common to all vendors. Let's deal with point two first.
Every vendor's product offering does window, level, zoom, roam, flip, rotate, inverse, and other basic image processing functions. Because everyone ostensibly has the same basic feature set, why not just make these feature sets mandatory; to be a PACS, you must provide the following feature sets ... and then list those features. Seems pretty black and white to me (no pun intended).
If maximum intensity projections (MIPs), multiplanar reconstruction (MPR), and 3D are standard, then the vendor should check off a box that indicates they are standard. If they are optional, check off a box as optional and provide the incremental cost related to integration and associated training.
Also, if a vendor offers multiple options from multiple vendors (say, two or three 3D application software choices, as many of the bigger vendors often do), they should clearly identify the third-party vendors, cost, and feature sets that the vendors being used offer, instead of just stating a global "3D" on the quotation.
Marketing hype needs to be avoided at all costs. My personal favorites are the extensive hype behind a Web-based versus Web-enabled PACS and RIS-driven PACS versus PACS-driven RIS. Are their advantages to each?
I would be drawn and quartered by the Three Marketeers if I said no, but the significance of these advantages often remains to be seen. Sure, a Web-based PACS offers a single operating system, user interface, database, and production server that also serves as the file server, but it also creates a single point of failure and can negatively affect radiologist throughput if the server isn't scaled properly and Web utilization is extensive.
It also limits you to doing load balancing if/as need be, eliminates redundancy, and a whole lot more. Most PACS now also provide a common graphical user interface (GUI) that is used in both its Web- and non-Web-based applications. So the bottom line is ... if it works, then it works. Users should factor in the practical applications, cost, and applications-related issues versus the marketing hype.
It's the same hype with integrated versus interfaced systems. Yes, integrated works more seamlessly, but then it also ties you to that vendor for life. And if you want a different system sometime down the road, you typically have to replace both the RIS and the PACS, not just one or the other.
Interfaced also allows you to select the best-of-breed for your facility, but it typically adds another piece of hardware and software into the mix. What is right for you? Whatever you decide is.
Part 2 of this series will address three of my biggest pet peeves: the use of standardized, vendor-neutral image archiving, including database management that does not require data migration; developing an industry-wide templated contract that includes uptime guarantees and associated penalties that most vendors avoid at all costs; and options to vendors using flat-rate percentage pricing to determine project management, installation, training, and support cost, among other things. So stay tuned.
By Michael J. Cannavo
AuntMinnie.com contributing writer
February 2, 2009
Michael J. Cannavo is a leading PACS consultant and has authored nearly 300 articles on PACS technology in the past 16 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
The 2008 PACSman Awards: I shaved my legs for this? December 4, 2008
The Anthology of PACS Secrets, September 9, 2008
Part XX: Exploring PACS Secrets -- Will PACS survive? July 22, 2008
Part XIX: Exploring PACS Secrets -- The truth about DRA and PACS, March 27, 2008
Part XVIII: Exploring PACS Secrets -- Hiding out in plain view: PACS at HIMSS, March 10, 2008
Copyright © 2009 AuntMinnie.com
