Month: June 2007

You need a well-written RFP to mine the truth

In a recent special report I wrote for Imaging Technology News (June 2007), I argued that a well-written RFP was still the best way to chose a replacement PACS. Today’s Radiology PACS is not a commodity, as many vendor’s would have you believe. And just because you have the experience of that first PACS behind you, the choice of the best PACS for the Health System is still tricky. Frankly, the PACS vendors have gotten very good at obfuscating the truth about their technology. They have become very good at word smithing, creating a dazzling array of acronyms and techno-speak to avoid answering the hard questions with the truth. Only a well-written RFP can break through all the marketing and sales blather and get to the truth about the features supported and their underlying technology.

Take DICOM conformity for example. If there is so much conformity to the standard in today’s PACS, as the vendors would have you believe, then why is it so difficult to exchange the complete set of study data between different PACS? Why is building a multi-PACS Enterprise Archive such a difficult undertaking?

In the ITC article, I have suggested 10 key issues that a PACS selection committee should understand completely if they are going to select a “good” PACS that will be the “best” fit to the radiology department.

If you insist on writing your own RFP, I offer three suggestions. Create a list of questions that focus on the issues, features and functions that are truly important. Think differentiation. Write the questions in such a way as to evoke responses that will differentiate products, not confirm the obvious. Lastly, think well-written. Write the RFP questions using concise and unambiguous wording, so the respondee cannot possible misinterpret. Better yet, provide your own multiple choice responses and instruct the vendor to pick the one that most closely resembles their response.

Today’s PACS may look straightforward from the radiologist’s perspective, but the devil is in the details. A well-written RFP is the only way to mine the truth.

DICOM Tag Morphing – Essential Ingredient in Enterprise PACS Archive

Herman Oosterwijk, principal of Otech Inc., reported his observations of the recent Society of Imaging Informatics in Medicine (SIIM, formerly SCAR) conference that was held in Providence, Rhode Island. In Herman’s article, he laments that it was hard to find anything “new”. I have heard much of the same, from several colleagues that were also in attendance.

I stopped attending the SCAR meetings several years ago, believing that many of the presentations either focused on updates of old subjects, or introduced concepts that were too impractical for commercial implementation. I decided to break my personal embargo in 2006 and attended the meeting in Austin, Texas. I came away with the same feelings that Herman expressed this year: “nothing new”. To me it seems as if there is a major disconnect between the subject matter of the papers in the meeting hall and the subject matter of the vendor booths in the exhibit hall. Perhaps I’m growing jaded, but if an idea is not compelling enough to quickly make its way into a commercial offering, is it worth looking at? At the 2006 meeting, one of the presenters suggested the time was right to replace the mouse with wireless video gamer gloves, sort of creating the diagnostic play station. Well the creators of the Nintendo Wii thought that was a good idea, but…

Actually I did mine some nuggets in Austin, but they were found on the other side of the street. I spent enough time in the Exhibitor’s Hall to discover several technologies that would prove to be the next new thing; “The PACS-neutral Enterprise Archive”.

In Herman’s June 15 story, he reported on an interesting paper presented by representatives from the Mayo Clinic. I’d love to give them credit here, but the SIIM papers are not yet available on-line.

Mayo has apparently constructed a massive central image archive that uses “16 servers for image archiving and provides access to more than 100 million images for tens of thousand of users”.

According to the paper, the Mayo Clinic uses “a commercial PACS only for short-term archiving (less than 3 months)”. Herman points out that this dual-tier storage strategy underscores “how much information goes back and forth between the image manager and long-term archive”. Actually it underscores how little data is going back and forth. Sizing the short-term cache on the PACS is all about matching the age of the priors. In this case, the heaviest recall is obviously within three months.

At any rate, the interesting point made in this article is;

“The presenters commented that the lack of standardization between the PACS image manager and the image archive could definitely be improved.”

Well, good luck. There are numerous reasons why even the current PACS do not “play well” with standalone DICOM archives, and I don’t believe for a minute that those reasons are technology challenges. I don’t see the PACS vendors giving up the Archive any time soon. Proprietary data objects or use of Private Tags simply locks the archive (and the data) to the PACS.

Therefore, the more practical strategy for anyone wishing to pair a PACS from one vendor with an Enterprise Archive from another is to expect that the PACS will continue to store some key meta data objects as proprietary objects, or store them as DICOM objects in Private Tags, or use proprietary Value Representations (the text that describes the encoding of the Tag).

The only way to defeat this particular marketing strategy is to deploy an Enterprise Archive that is capable of Tag Morphing. When confronted with a PACS that does not treat all key meta data objects as DICOM objects stored in Public Tags, the vendor can simply program the Archive to extract a copy of the meta data and convert it to a DICOM object and place it in a Public Tag, before committing it to the Archive’s long-term storage solution. The Image Header now contains the original PACS meta data and a copy placed by the Archive in a Public DICOM tag. When the originating PACS requests the data back, the original meta data objects (in their original format) are still where the originating PACS expects them to be.

If a different PACS were to request this data from the Enterprise Archive, there are two possibilities. If the second PACS is capable of reading Public DICOM Tags, the vendor of the second PACS can be given the Group and Element numbers of all the Public Tags where the meta data can be found in the Archived version of the image data file. If the second PACS cannot read the Public Tags, the Enterprise Archive can Morph the Image Header once again and transfer the copy of the meta data from its Public Tag to any Public or Private Tag that is utilized by the second PACS to store this meta data.

DICOM Tag Morphing is an intriguing example of “reverse engineering”, but it is not new or a stretch of the imagination.  It has been perfected over time by those individuals and companies that have been doing the dirty work of DICOM data migrations.   The library of their morphing experience is simply being put to use in the Archiving application.  Tag Morphing in the Enterprise Archive is the only practical solution today to deal with the inconsistencies in the way meta data is treated by many of the current PACS. You cannot hold your breath waiting for the PACS vendors to truly standardize.

I’ve found only three vendors that have deployed Enterprise Archives capable of Tag Morphing: Acuo Technologies, DeJarnette Research Systems, Emageon Inc. If there are others, they haven’t made this capability apparent.

I’ve written a few other pieces on this subject that can be found on this web site.

PACS-neutral Enterprise Archive – Who will build it?
Looking for a PACS-neutral DICOM Archive?
An Enhanced DICOM Archive would be the ticket!
PACS Vendors think PACS-neutral Archive is crazy idea
SCAR ’06 Update

PACS-neutral Enterprise Archive – Who will build it?

I was rummaging through some search returns on Google today, when I caught an article written back in October 2006 by Nadim Daher, a Medical Imaging Market Analyst for Frost & Sullivan. What caught my eye was his observation about the makeup of a PACS.

“While the front-end clinical applications, already fairly uniform across PACS vendors, continue to evolve slowly to incorporate more features and integrate information from more systems, the back-end infrastructure of PACS is increasingly being shared across the enterprise. This growing ‘disconnect’ between the front-end clinical application and the back-end infrastructure creates room for an improved layer of middleware to manage enterprise data including, but not limited to PACS.”

The article, well worth reading, goes on to discuss the advantages of building a single shared Enterprise Archive that is capable of managing both DICOM and non-DICOM data objects and therefore capable of being the archive for radiology, cardiology, and other medical imaging modalities.

“Aggregating or better yet, integrating data on a patient-centric basis can constitute a sure first-step towards developing a comprehensive EMR.”

While I’m all for looking ahead to the data repository for the EMR, forgive me if I am presently more concerned about building an Enterprise Archive that can exchange data between different PACS. The ability to dynamically translate DICOM header tags in order to accommodate dissimilarities between PACS, would eliminate the need for costly and time-consuming data migrations required every time a PACS is replaced.

There are a number of Enterprise Archives currently in the market that can share their data between different PACS, but most of these systems can only share DICOM data objects, and they assume that each of the PACS are capable of interpreting all of the essential meta data that is stored in the DICOM header. Unfortunately, too many PACS in operation today treat one or more key meta data objects associated with the study data as proprietary objects, or they store these objects in private tags. Few PACS systems can actually interpret all of the data transferred from another PACS, and no matter how DICOM-conformant the archive may be, if it simply accepts, stores, and returns whatever DICOM objects it is given, that archive can not solve the interpretation problem.

Nadim talks about “enterprise archive management middleware”, that special software that would “fill in this new-found gap in the structure of the modern-day information system”. In my view that middleware has to go beyond DICOM object management and Information Lifecycle Management strategies triggered by patient and study specific information stored in the header. What must be included in this middleware is the tag morphing software that would dynamically translate header information is such a way as to make the data created in PACS A become completely understandable to PACS B, and vice versa. Not only would this make it possible for disparate PACS to simultaneously share a common enterprise archive, it would also eliminate the need for future data migrations.

I have come to believe that what we now think of as a Picture Archiving and Communications System is going to bifurcate into two distinct subsystems, each evolving as they become more specialized. The front-end or clinical part of the PACS would focus on work list management, display functions, and clinical information distribution, becoming the Picture Communications System (PCS). In this new paradigm, the “A” or Archive in PACS is removed and upgraded to become the Enterprise Archive subsystem.

There is considerable speculation on which companies will be drawn to which path. It is perhaps easy to see the bigger established PACS vendors, especially those with modality product lines, continuing to develop the clinical subsystem. They have the army of software engineers required to implement and support the clinical applications. But which companies will be drawn to the evolving Enterprise Archive path? Open systems is rarely seen as an admirable quality to either the big PACS vendors or the big Storage Hardware vendors, and the concept of an Enterprise Archive absolutely demands an open system approach. There are a few specialized medical archive software vendors out there, and I think the time has come for them to step forward. There are early adopters ready to take the right steps towards building the PACS-neutral Enterprise Archive.