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.

Looking for a PACS-neutral DICOM Archive?

In a news piece released today on auntminnie.com, it appears that PACS vendor Carestream Health and storage vendor Hitachi Data Systems have entered into a collaborative agreement to create a clinical information archive. The collaboration will combine Carestream’s Versatile Intelligent Patient Archive (VIParchive) and the newly enhanced Hitachi Content Archive Platform into a single footprint.

This means that three of the top storage solution vendors (Hitachi, HP, and IBM) now have “partnerships” that add the all-important DICOM layer to an otherwise basic storage solution. This latest Carestream/Hitachi storage solution will enable multiple application servers (Radiology PACS, Cardiology PACS) from different vendors to share a common storage solution.

Unlike the DeJarnette/HP and Acuo Technologies/IBM combo systems, this new Carestream/Hitachi entry does not appear capable of modifying the DICOM file formats to accommodate differences between the vendor’s use of the DICOM header. In this case the archive stores exactly what it is given and returns the same. If the requesting application server does not know how to interpret the DICOM header created by another vendor’s server, too bad! Both the DeJarnette and Acuo software packages are capable of DICOM Tag Morphing, which effectively translates one vendor’s DICOM header format into the other’s.

The PACS vendor Emageon is also marketing an Enterprise Content Manager (archive) that is capable of Tag Morphing to accommodate any differences that may exist between the way two vendors store metadata in the DICOM header. A plus for the Emageon approach is the fact that their ECM software is hardware agnostic and can be hosted by a variety of platforms and is validated with a variety of storage solutions.

Is the Carestream/Hitachi agreement an indication that the storage wars are taking a new turn?

PACS is about more than Pictures

In The Beginning…

Back in 1980, medical imaging departments attributed most of their problems to their dependence on film. As a result, early PACS were designed as replacement technology for film. Hence the name, Picture Archiving and Communications System.

In the 80’s and 90’s film was much more expensive and many figured they could pay for PACS based on film savings. “Going film-less” became the mantra for both vendors and the market.

Fast Forward 25 Years

We finally have the technology to replace film:
* Interfaces to connect modalities
* High-speed networks for moving massive amounts of image data
* Fail-safe servers for 99.9% availability and reliability
* A variety of standards-based compression schemes (including J-PEG 2000) to improve performance and reduce hardware costs
* Reasonably priced, “off-the-shelf” storage solutions
* High resolution displays that rival the image presentation quality of film

All of this has made it possible to replace the film-based process with an electronic process.

Lessons Learned

Based on our experience, we’ve made some surprising realizations. The first is that the economics of the medical imaging business have changed.

In response to the perceived threat of PACS, the film companies started dropping their prices. Using those lowered film prices, materials and labor savings alone would not produce a break-even or produce an operational profit. In fact, operational deficits with PACS often ran six figures year after year.

Over the past few years, it has dawned on us that film is not the only important piece of information in the film jacket. The other “P” in PACS is for paper. For example:
* Patient/exam history
* Print of the order or requisition
* Any and all clinical notes
* Release forms
* Technologist worksheets/reports
* Radiologist reports

This paper supports the internal workflow of the department that the traditional Radiology Information System (RIS) does not reach. It might also represent the workflow that the PACS will not reach unless the system is properly designed.

In order for the PACS to be successful, the radiology department needs to eliminate all of the study-related documents (1) because there will be no one to move it, nowhere to store it, and no way to find it when the Jacket goes away. That means replacing the paper exchanged between the Emergency Department and Radiology to note preliminary impressions, and the occasional discrepancy or incidental finding. That means eliminating the hardcopy of the requisition, simply because the radiologists use its bar code to open the dictation file. If you stop an d think about it, This means eliminating a lot of paper forms you have invented for good reasons and have gotten very used to using.

Lessons Learned Summary

For a department considering its first PACS, PACS is a zero gain initiative – at best, costs will equal savings. The goal of PACS should be to “go jacketless” rather than “film-less”. And that means developing a new workflow that successfully eliminates the use of paper [1] to announce the readiness of a patient or study, [2] to communicate clinical information to the radiologist, [3] to communicate results to the referring physician.

In the process of determining this new paper-less workflow, it was also discovered that the technologists will have to play a larger role in preparing the study for interpretation. The technologists and not the system administrator will have to take responsibility for study QC. The Technologist must determine if all the clinical information needed by the radiologist for interpretation is present and accurate and attached to the electronic study.

Current Meaning of PACS

The epiphany that there is more to PACS than film clearly lead to a new goal: the delivery of clinical information (images and reports) in the most expeditious and cost-effective manner throughout the healthcare enterprise.

The term PACS has become an anachronism, pictures are no longer the only focus. The market has matured to become more centered on information management.

The advice is simply this, “don’t spend $2 million on a PACS only to realize that you need to spend more money to automate the other half of what’s in the film jacket”.

State of the Art PACS

The ideal PACS today is more than just a PACS. It must manage all forms of data prior to interpretation, enable the creation of multi-media reports and distribute the reports quickly at a cost-effective price. This ideal information system is comprised of:
* PACS as we knew it
* RIS as we know it
* Technologist workstations with PACS and RIS features
* Voice-to-text and multi-media reporting
* Workflow engine that directs operations
* An enterprise oriented data repository and distribution system

New Paradigm, Same Old Name

The next time you are talking to someone about PACS, be sure to find out which PACS they are talking about…

And as you review this web site, know that the PACS I’m talking about is the new PACS, not the old.

Time Lines

How long does it take to do it right?

Proper planning prevents poor performance

The process for mapping out an image and information management plan is rather involved.

It is appropriate to observe the current workflow in radiology and determine what changes will be affected by the PACS. That means observing how the Technologists, Clerical staff and Radiologists do what they do. How is the RIS used today, and how will that change? How should that change? How is study QC done today, and how will that change?

How will paper be used after the PACS, and how will its information be captured and managed by the PACS?

In order to determine the best data storage solution, it is necessary to collect study data and convert it to digital equivalents. What are the daily, weekly, yearly digital equivalents of the new studies, and what are the digital equivalents of the relevant priors? What is your projected growth in each of the imaging areas? What level of compression will you use for new studies, priors, and the legal archive?

How will you role out the digital display technology to the referring physicians? What kind of services will you provide them to help them with this major adaptation to your new system? Discussing the possibilities or pre-selling the intended solution is a necessary and touchy project.

The technology of PACS is still quite complicated, and that technology is constantly changing and evolving. Regardless how many individuals are responsible for selecting the system and the vendor, those making the decisions should have a reasonable level of knowledge on the subject. There are numerous ways to go about gaining this education. Requests For Proposal (RFP) projects have been used by many organizations to learn about PACS technology and to make a vendor selection. Each component of the project has its own Time Line.

Properly done, the process from planning through vendor selection can last 3 to 6 months.
* Planning – 2 months
* RFP – 3 months

That’s assuming of course that you are starting from scratch…that you have done little or no data collection, workflow mapping, physician interviewing, or investigation of the underlying PACS technology. Good preparation can significantly reduce the amount of time and effort required in the formal Planning and Vendor Selection projects.

So it is important to plan early, get started early and schedule the project before time has run out to do the job right.

Not for the faint of heart

Buying a PACS can be daunting – there is little room for error in such an expensive undertaking.

Challenges include:
• A working knowledge of rapidly changing technology
• An unbiased insight into the business strategies of potential suppliers
• Incorporating existing equipment
• Considering changes to current operations, especially the role of the radiology technologist
• Accounting for the various skills and apprehensions of a multitude of potential users
• Accommodating complex practice patterns of radiologists and referring physicians, especially in the Emergency Room, Operating Rooms, and Exam Rooms
• Impact of organizational changes within the enterprise
• Impact of changes in the health care industry
• Impact of the emerging PACS-Neutral Archive as a consolidated multi-media archive for he enterprise as well as the data repository for the image-enabled Electronic Medical Record.

Deployment Strategy

There’s an order to the deployment of a Radiology or Cardiology PACS. The expression, “the devil is in the details”, is very true in PACS deployments. Determining the optimal sequence and getting all of the potential users to accept a new way of doing things is the challenge.

A stable and long-lived infrastructure must be designed. This is especially true for the Storage Solution, if that storage will someday be separated from the PACS are reassigned to a PACS-Neutral Archive.

A successful deployment schedule must string “little successes”, simple but effective changes in the operations of the department whose very effectiveness builds acceptance and confidence.

To be successful, the system designer must
• Chose the right solutions to the right problem
• Gently nudge the professional staff just beyond the edge of their experience
• Bring a multi-phase project in under budget.
• Every enterprise is unique. Otherwise, everyone could buy the same thing with equally good results.

Two-Step Process

There is a basic two-step process to buying a PACS, planning and vendor selection.

Planning includes:

• Needs assessment
• Business case analysis
• System design
• Deployment Strategy

Vendor selection includes:

• Review and refine requirements
• Request For Proposal (RFP)
• Finalist’s evaluations via demos and site visits
• Final section and contract negotiation

Planning

Planning is a comprehensive study to make sure you don’t waste money on your PACS. You must consider:
• Organization dynamics
• Existing technology
• Lesson learned from the existing and possibly previous PACS
• Optimization of the new PACS configuration
• Phased implementation plan including the obligatory data migration

The planning process must meet the needs of:
• Imaging department’s customers
• Department professional, technical and clerical staff
• For both immediate needs and future

Planning is based on:
• Operation data and expenses
• User preferences and skill-sets

A resulting plan and system design must accommodate various constraints:
• Technical
• Organizational
• Political
• Operational
• Financial

Getting all the various stakeholders throughout the enterprise to all agree on the plan is also critical.

The Gray Consulting planning and design process includes:
• Current State Analysis
• Impact Study
• System Design and Implementation Strategy
• Cost Estimate
• Payback Analysis

The outcome of the planning process is a roadmap for implementing a new or replacement PACS.

Vendor Selection – Potential Pitfalls

RFPs for a Radiology PACS are very time consuming to prepare. Considerable effort is also required to prepare the PACS team to understand the responses. A good RFP must describe the design strategy and rationale in great detail. This will attract considerable debate and argument from the vendors, who will want to argue their strategy.

Many vendors today will not respond to a complex RFP unless they are already engaged in the selling process with the facility and believe that they have a good chance to win the deal. Since it is not unusual for a prospective PACS buyer to overlook a number of companies and products, the client may never discover just how good their PACS solutions may be, if those companies choose not to respond.

Gray Consulting has simplified the RFP process by creating a template. The RFP Template allows you to build your own comprehensive and precisely written RFP for PACS. The package includes the RFP on CD, Instructional Booklet, and one hour of telephone consultation. The technical section includes section after section of probing questions carefully written to expose the benefits or failures of the system. Asking for detailed information, this RFP template yields a level of detail the team will need to decide which components best fit the expectations of both the department and the enterprise.

All of the major PACS vendors have responded to the Gray Consulting RFP. Since 90% of the document remains the same with each publication (approximately 10% of the questions are new to address changes in technology or requirements), and the question numbering system remains the same, all of the major vendors have continued to respond to the invitation to submit responses. The client will not miss out on an opportunity to discover the best PACS solution.

The RFP is sent to numerous companies that the team believes has the right components. A careful analysis of the vendor Responses will weed out all but the best 2 or 3 finalists.

This RFP process gives the team much greater control over the system design and vendor compliance.

The Gray Consulting vendor selection process includes:
• Design Review of any existing system plan and strategy
• Refinement of System Specs
• Description of required vendor services to support the proposed system
• Development of RFP
• Evaluation and summary of RFP responses
• Site visit preparation
• Vendor or system integrator selection
• Negotiations

The latest buzz in the PACS world

The latest buzz in the PACS world, especially in a few Discussion Threads on AuntMinnie.com, is the “web-enabled” PACS. Two of the more significant features of a PACS that would qualify it as web-enabled are communications between client displays and server based on http:// or http(s):// and the image objects are all assigned their own URL. The merits of a web-enabled PACS aside, I have a concern about the assignment of a URL to all of the image objects.

The implication is that all study data objects would be treated as URL objects. This is in fact the way Fuji treats the study objects in Synapse. While I would agree that there are some distinct advantages to “organizing” a database using URL, the problem is when the use of URL supercedes the use of DICOM.

Web tools like http:// and URL are effectively standards, but there is only one universally recognized standard in medical imaging communications and that is DICOM. A lot of effort continues to be poured into defining DICOM objects and DICOM communication SOP Classes. The vendors are being pushed hard to keep up with the advancements in the DICOM standard and nowhere is this more evident than in the area of IHE-inspired DICOM objects and SOP classes like Presentation States and Key Image Notes. To this day there are a number of major PACS systems that still treat key data objects associated with the study as proprietary objects. It’s very difficult to extract and migrate non-DICOM data objects to another DICOM-conformant PACS.

My fear is that the adoption of URL as the primary method of managing study related data will de-emphasize the importance of first making all study-related data DICOM objects. There is no way to predict how many PACS systems will be able to exchange URL data objects five years from now. However there is a very good chance that most PACS systems will be able to exchange DICOM objects five years from now.

There may be a number of good arguments for tagging all study related data objects with a URL, but let’s keep the pressure on the PACS vendors to make all of those data objects DICOM objects first.

Test Server Shortfalls

I started reading a discussion thread last week on AuntMinnie.com dealing with downtime during PACS software upgrades. While reading comment after comment, I’m thinking about how test servers are intended to minimize that downtime. Then it occurs to me that there are very few PACS systems out there with Test Servers. First of all they are expensive if they are configured to test more than a few modalities and more than a few display stations, Secondly, there are some PACS vendors that do not even offer a Test Server.

A properly configured Test Server will be configured to accept all of the modality inputs and have a small Directory database and sufficient local storage to accommodate the studies that are acquired during the testing. You don’t want to add test studies to the primary PACS database. It will have two network interfaces, so it can be used when the primary network in undergoing periodic scheduled maintenance. It will include a HIS/RIS interface component, so that functionality can be tested. It will include all of the display applications. In short, the real Test Server is as close to being a mirror of the production server’s interfaces and applications as you can make it. That’s the point of it being a Test Server. On the other hand, the vendors should realize that a Test Server is just that, a Test Server. Placing it in service once a year to test a new release does not warrant pricing the software anywhere near that of the production server.

Even though a true Test Server is configured as close to a Production Server as possible, that does not necessarily make it a back-up server. The Test Server is typically configured on a much smaller, less robust server platform than the Production Server. A Test Server configured with sufficient horsepower to be a Business Continuity Sever would be considerably more expensive. A true Test Server and a Business Continuity Server differ primarily in the server hardware. While the concept of a Business Continuity Server is very valid in parts of the country that are at greater risk for natural disasters, most facilities would consider it a luxury. The true Test Server however, should be a requisite in every system.

Tackling the Exam Room Display

Consider marketing the use of CDís as the means of transferring study data from radiology to the referring physicianís office. All studies required for a dayís worth of office visits are ordered in advance and placed on one CD. The referring physicianís office staff transfers the studies from the CD to specific desktop or lap top computers in the offices and exam rooms. This strategy minimizes network complexity, eliminates time-consuming steps required to access studies, utilizes existing office workflow by assigning all time consuming tasks to the office staff.