You may notice some degree of stagnation on the blog, as I have not posted in several weeks. I’ll try to remedy that situation.
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:
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.
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…..