A Private Little (Tag) War

"Mugato" from the Star Trek Second Season episode, "A Private Little War"

Courtesy Paramount Pictures/CBS Television

OK, only PACS aficionados who are also Trekkies will get the reference, but I thought it was attention-grabbing.

We have recently upgraded our GE MRI, adding various bells, whistles, coils, software, and various and assundry other items. I myself have been scanned in this machine, and I can tell you that the new, improved version is louder than a freight train as heard from the track's perspective. However, the images are excellent. Well, I should say that the images as viewed on the MRI console are excellent, but once they make it to our Agfa PACS, they would rate as only "good". It seems there is much degredation in the display, and we have been asking about this for quite a while.

The fault appears to lie with DICOM, the communications protocol of digital imaging. Well, that's actually a mis-statement, as the real fault lies with the vendors and their use or misuse of the DICOM standard. In this case, the culprit is probably GE, although they aren't the only bad actors in this venue. I have also noted severe problems with Fuji CR in the past not displaying properly on an Amicas PACS. In both cases, the modality makers tried their best to indict the PACS for the situation. However, while the PACS does bear some responsibility, the lion's share of the blame probably goes back to the modality.

Now, you don't want a complete course in DICOM, and even if you did, I couldn't begin to do it justice. If you are truly interested, please consult David Clunie's website, http://www.dclunie.com/, for the most complete information possible. (God Himself consults David when He has a DICOM question.) For the purpose of this discussion, you need to know that a study, a group of images and associated data, is called an object, and it has a header, which is some alphanumerical data tacked onto it. Michael Gray, of Gray Consulting posted this link as an example of what the header looks like. The header contains "tags" which in turn have code for "attributes" And this is where the trouble starts. The even-numbered tags are Public, representing standard variables for PACS systems, archives, and modalities. Ah, but the odd numbered tags are Private, and therein lies the trouble.

There was a huge discussion on AuntMinnie.com, prompted by my article, "The Dalai's Laws of PACS" a few months ago, where many of the Great Ones of PACS, including David Clunie himself, Michael Gray, and of course Mike Cannavo, the One and Only PACSMan, as well as the phenomenal Digital Doctor, and several very, VERY wise folks hashed out the vagarities of vendor-neutral archives. The modalities were not really mentioned much, but as our experience reflects, they have this problem too.

It seems that the likely reason for our images degenerating to mugato-poop in their journey to PACS is the fact that modality vendors use these private tags to add various parameters that are not generally readable by a PACS from a different vendor! As described by Donald Peck, Ph.D., in a lecture for the American Association of Physics in Medicine,

. . .you can use them to display almost any tag as an annotation, also they include acquisition and processing parameters inside of the DICOM header. These processing parameters though are often stored in what’s called private tags, which are proprietary to the vendor and may or may not be visible inside of your PACS system.

This supposedly is a way to make you want to buy all your toys from the same company, but no one told the salespeople about this, or the service engineers for that matter. They subsequently flail around trying first to point fingers at the PACS involved, and when that doesn't work, they attempt to fix a problem that turns out to be intrinsic to their scanner. But it is the way it is. Does this interfere with the image enough to cause a miss? To answer that, we would have to compare each and every study as displayed on the MR console and on PACS, and that ain't going to happen. But we're still going to worry about it.

This situation dovetails into the larger discussion of proprietary fields/private tags in DICOM in general. Why are they even there? Michael Gray, on his website, describes the example of Presentation States and Key Image Notes as illustrative of the Proprietary Problem:

It has been at least four years since Presentation States and Key Image Notes were included in the DICOM standard, yet the majority of PACS vendors continue to treat these key work products as proprietary objects. The most consistent excuse is "There are many more features on our engineering schedule considered to be more important to our users."

I can almost believe that story, since I have found that most users are not aware of the implications of proprietary data objects. Since almost every PACS supports the creation and display of Presentation States and Key Image Notes, the fact that most PACS treat these as proprietary objects is lost on most buyers and eventual users. Provided that these objects are kept within a given PACS, there is no apparent negative to their being proprietary. The user may not experience a situation where the proprietary nature of these objects presents a problem.

The problem arises when the user of one of these proprietary PACS tries to forward study data to another Facility or Health System that is using a different PACS. Whether that other PACS is DICOM conformant or not, unless it is the same PACS, those presentation States and Key Image Notes cannot be transferred, accessed, or displayed. Physicians using the other PACS will not have the benefit of seeing exactly what the radiologist interpreting the study saw in the images or what he may have typed as a text message. The benefit of these "work products" is lost.

The real problem will manifest itself only after the user has decided to replace the proprietary PACS with the next PACS. Data migration services will typically migrate the study pixel data to the next PACS, but few of these services currently migrate any proprietary study-related data objects. To do so would require knowing where these objects were stored in the PACS, how to extract them and how to convert them to their DICOM counterparts. This extraction, conversion, migration is not being performed and as a result, those proprietary data objects are lost forever. The images are available for historical comparison in the next PACS, but none of the proprietary work products are available. Now imagine the implication of having to window and level all of these priors again, when they are recalled for viewing with the new images. Imagine not having the spine labels, and not having any other annotation or overlay graphics created when the prior was first interpreted. That's working without benefit of prior information, or a possible expenditure of time redoing all that work.

. . .Lack of DICOM conformance is a type of vendor lock. I believe that the PACS vendors still believe that anything that complicates moving to another vendor's PACS may persuade the organization to stay with the incumbent. It's time to make them pay for that strategy.

Amen. Sadly, it is next to impossible to find a scanner OR a PACS that doesn't dabble in this unfortunate practice. Maybe if we users started demanding such products, the vendors would provide them. OK, I'm demanding it. And so should you. Let's start a private, little war on Private Tags.

Addendum

Our GE rep (who is NOT pictured above, by the way) sent in these responses to our complaints. Our notes are in black, the GE responses are in green (of course!):

Issue #1:
"In my (Dalai's note--PACS IT expert) experience, GE as well as some other vendors, are notorious for placing key information in proprietary fields outside the DICOM standards. This creates a marketable advantage for the vendor to sell other related products in their product line."

When the original DICOM standard was developed for the MR image object, there were few fields defined. As MR has evolved these standard fields have become insufficient to contain the data necessary to annotate our images to the level we currently support. The enhanced MR image object has defined many more standard fields to better align the image object with current technology. At this time GE only supports the original MR image object. At this time no date has been set to support the new MR DICOM object. However, GE provides details on each of the private fields for our MR object in our DICOM conformance statement. When requested, additional details are provided on how the private data maps to annotation fields on the image. As far as selling related products, the only GE products which interpret MR private data fields is the CT system and the Advantage Windows. The GE PACS does not interpret private GE fields any better than it interprets competitors private data.

Issue #2:
"Why do the MRs on the GE scanner look so much better on the MR console than they do the Agfa PACS?"
In general I would expect a PACS viewer (which is designed specifically for displaying images) to have a better display then the MR scanner. I suspect that there is a calibration difference between the Agfa PACS monitor and the GE MR system monitor. I would suggest you take a representative image on the MR and set its window & level to optimum display on the scanner. Record the WW/WL values. Then send the image to the PACS and re-adjust for optimum viewing on that display station. Record the WW/WL values again. What are the differences? When adjusted for optimum display on each station, is the MR monitors image still better?

Well, the answer to Issue #1 is pretty clear, and makes sense to GE, I'm sure. It's easier to stick to an old standard and the software band-aides that have evolved over the years to deal with the limitations of the OLD standard, than to migrate to the new standard that would handle the problem. Maybe. I'm encouraged to know that Centricity wouldn't deal with this any better than any other PACS. Actually, I'm pretty discouraged. The implication is that the internal standards are available to the PACS vendors via the DICOM statement, and they should feel free to rewrite their viewing software to accommodate this, um, individuality of GE's private tags. I guess the PACS vendors could take a Microsoft Windows Plug-and-Play approach, gathering all parameters on all possible scanners to create a brute-force, comprehensive compilation that would let their PACS read all private tags of all vendors. Sounds pretty daunting to me. Why not just create a standard that all scanners could follow? Wait, we already have one.....

As for monitor calibration, I'm not buying that one. Why would the images from various CR's, sonograms, scintigrams, R&F rooms look OK, and the MR's not? I'm guessing that we are to adjust some sort of mapping of window and level settings between the scanner and the PACS, but that sounds sort of kludgy to me. Maybe DR's Catapult system is the answer here, wherein the technologist has to adjust the image within PACS for optimum viewing before sending it on to the docs. But frankly, this still sounds like finger-pointing, when the real problem is those pesky private tags.

It's still time for a private little war on Private Tags.