I am presently in Rome, Italy, following a cruise of a few Greek Islands, Split, Croatia, and Venice. It was actually a meeting cruise, with a number of lectures on CT by Elliot Fishman, M.D. and other radiological celebrities. I wonder if they realize that they were on the ship with the (in)famous Dr. Dalai… The cruise itself was OK, but I do have to give one warning: Unless you are clinically deaf, avoid the Royal Caribbean ship Splendour of the Seas like the plague. It is an older ship with absolutely no insulation between decks. We could rarely sleep due to the constant banging around and dragging of chairs on the deck above us. Not good. However, there was a great deal of CT knowledge imparted to the participants, and I'm going to try to apply at least some of what I learned to my daily practice. Although the meeting wasn't about PACS, I did acquire a few tidbits here and there. Several of the other participants have Agfa Impax 6 and hate it. One fellow replaced an old (2003) Amicas system with Dynamic Imaging and loves it. Dr. Fishman himself uses Emageon at Johns Hopkins, and complained numerous times that it chokes if they try to load a CT series that contains more than 100 images. That's 100, folks, not 1000. Their solution has been to use Siemens WebSpace, a remote client version of InSpace, for multislice CT studies of more than 100 slices, which is about everything they do there at Hopkins.
There is a thread on Aunt Minnie which was prompted by my recent article, Dalai’s Laws of PACS. This discussion has gone from hashing out what clinicians should expect out of PACS (a major point that I left out of the Laws) to a longer chat about vendor-neutral archives and databases. I don't claim to have all the answers on that one, nor do I begin to understand all the underlying DICOM issues involved. However, two experiences from this trip I'm on may provide some useful analogies.
The issue was rather well-stated by David Clunie (of course!) with this post toward the end of the long thread:
We have talked about the "vendor-neutral image archive", which could be the place in which images and other (standard) composite DICOM objects live; would it also be feasible to discuss a "vendor neutral image database" as a separate entity from the archive, which multiple PACS and/or "Image Manager" actors could access ? I say this, because it is useful to have central and accessible database of the images and various additional information that may not be strictly related to or extractable from the DICOM image headers and have no business in there (e.g., read status, legal name changes like getting married, etc.) - this information is needed by multiple production systems (e.g., different PACS, different RIS, web server, EMR, etc) in addition to the image locations, yet is perhaps separate from the "PACS" functionality per se. Also, during PACS migration, such a database might not need to be changed, or could be serialized in a "vendor neutral image database interchange format" that could be "read into" the next database. In the past various folks have proposed extensions to support PACS migration that serialized a snapshot of this information (even suggesting a huge DICOMDIR for this), but I am not sure that there has ever been a serious attempt to factor out a shared, live, standardized, database. In a sense, the VNIA and the VNIDB would to in-house PACS what the IHE XDS repository and XDS registry are to cross-enterprise document sharing; not that I am suggesting that XDS is necessarily the appropriate technical solution for this. Ordinary SQL access might be an option; another might be Grid Service based queries such as are being developed for caBIG imaging, which also have the benefit of a comprehensive security model.Early on in the discussion, I think I was mentally considering the archive and the database as one, which is not strictly accurate. For me, the bottom line is this: I want the ability to plug different tools, modalities, and especially workstation GUI's into my database. Simple concept, difficult execution, apparently. But here is where the first European example comes into play. You are all familiar with the Euro, the new currency used by the multiple countries of the European Union. Anywhere within the EU, a One Euro Coin looks like this on the back:
But on the front, the different member countries can display their own design. Here are the coins from Greece, Ireland, and Italy:
My point here is that all these coins are worth one Euro. They look slightly different, but they do exactly the same thing. Such would be my vision for a Vendor Neutral system. I want to be able to buy a database from Belgium, as it has the reputation to be the best. I want to plug in a scanner from Germany, and have it talk to my database from Belgium without any add-ons, extra interfaces, or especially extra charges. I want my interface from Greece, my 3D app from Ireland, and so on. Quite roughly, interchange DICOM for Euro, and you see where I'm going with this. DICOM needs to be the unit of currency for PACS. The only problem with this concept is the vendors' insistence on the use of Private Attributes, factors that make their systems different, but don't translate from PACS to PACS. WindowsPACSMaven proposes a possible solution:
To alleviate the above mentioned issue with Private Attributes I decided with a colleague in 1998 that we would design a PACS using "Native DICOM". Native DICOM is DICOM V3.0 with no Private Attributes! To do this we partnered with a major university to be sure that no vendor attributes got into our design...By using Native DICOM we would be guaranteeing viewability anywhere that DICOM V3.0 is present. So if we can get Radiology to start to use Native DICOM through vendor and/or open solutions the problems with storage and retrieval will be minimized going forward from here. Because the Native DICOM concept is so radical I actually lost my job for promoting this concept and am now an independent software developer for healthcare! Because of my job loss I still have to remain anonymous so that I don't affect my future income possibilities since I do consulting for healthcare vendors.
One would assume that the big boys have something to lose with this approach, eh? Therefore, it must be good! OK, OK, there is a lot more to the issue than I've presented, but the idea is clear, and I think it has a lot of merit.
So how did we get in this situation? The second lesson from my trip might explain it. On the island of Corfu, we were enticed by Royal Caribbean's shore excursion brochure to take a "4WD trip into the hills of the island, where you will see villages rarely visited by outsiders." We were intrigued and signed up for the journey. When we got to the staging area, we found 20 little 4WD vehicles. So far so good. But upon closer examination, there was one little problem: the cars all had manual transmissions! This was a problem because I've never driven a stick, and my wife hadn't done so in over 20 years! But she bravely took the wheel, and skillfully drove up and down the hills, through little passes and treacherous switchbacks like this:
It was worth it, however, to see some of the wonderful, isolated little villages. At least that's what we told my wife when we got back! She was too busy driving, and in particular trying to keep from rolling back into the car behind us in the caravan to see the sights! Here are some typical scenes:
The lesson here is that Royal Caribbean assumed that everyone was OK with their way of doing things, that no one would have a problem with manual transmissions. They were so unconcerned with the needs of their passengers in this venue that they didn't even bother to publish the fact that the cars were only of this persuasion in any of their literature. This is they way it is, kids, it would cost us money to change it, and we assume you will like it and be comfortable with it.
I'm sure you see where I'm going with this. Do I even have to say it? Oh, well, I'm not known for my subtlety. Many PACS companies have done things a certain way for quite a while, and they assume you and I will like it. The fact that we may NOT be comfortable with it, and that we may have to waste the brainpower that we should be using to view the road, I mean the image, on driving the stick instead. The DICOM currency standard would be one way to solve this problem. One could, in theory, use an "automatic" front end to a database that otherwise had a "stick shift" GUI.
Let me wrap this up before I get even further lost in weird car analogies. Ultimately, the only "vote" we have is with our dollars, (or Euros) or those that come from our hospitals. I WANT the ability to do what I have described above, and I expect the market to provide it eventually. Royal Caribbean made what could have been a very dangerous assumption (had I tried to drive myself), and the non-insulated Splendour of the Seas deprived me of valuable sleep. My vote will be to never cruise on one of their ships again. I'll be certain to exercise the same sort of thing with other big purchases as well. Hint, hint.....
Ciao!
1 comment :
Let's say I make a statement. "I know how to drive". Let's call that being "driving compliant". Vendor A makes a cars with a stick shift and says it's "driving compliant". Let's say vendor B makes a driver that can only drive automatic and calls that "driving compliant". In the US, this works quite well because every car tends to be of the automatic transmission type so vendor B becomes well known as a good vendor with a cheap solution because Vendor B skipped out on the work having to implement/test both. In europe, where many more cars are of the standard type, it is considered unthinkable that a driver would consider themselves "driving complient" without having implemented the "being able to drive standard" option. Net result: two DICOM compliant vendors with solutions that don't talk to one another.
The more options a standard, like DICOM, allows (more options equals more flexibility in the sorts of interfaces you can use), the less likely two vendors using the same standard will be able to talk to one another and/or the more expensive everything will be because us poor engineers have to do some of our development and all our testing twice..
Here's an entry from wikipedia you might find interesting:
http://en.wikipedia.org/wiki/Manual_transmission
"Conversely, manual transmissions are no longer popular in many classes of cars sold in North America and Japan, although they remain dominant in Europe. Nearly all cars are available with an automatic transmission option, and family cars and large trucks sold in the US are predominantly fitted with automatics. In Europe and Asia (except Japan) most cars are sold with manual transmissions. Most luxury cars are only available with an automatic transmission. In situations where automatics and manual transmissions are sold side-by-side, the manual transmission is the base equipment, and the automatic is optional—although the automatic is sometimes available at no extra cost. Some cars, such as rental cars and taxis, are nearly universally equipped with automatic transmissions in countries such as the US, but the opposite[dubious – discuss] is true in Europe."
Love your blog. See ya.
Post a Comment