Monday, February 11, 2008
The Problem with Proprietary Data/Object Formats - their Impact long after Data Migration
This is another take on a long-standing problem with most of today's Radiology PACS: proprietary Data/Object Formats. 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 problem also arises when a user of one of these proprietary PACS tries to copy study data to a CD/DVD. The proprietary work products either cannot be copied, or they cannot be accessed and displayed by another PACS. This is one of the reasons why there is so much consternation over the current CD/DVD copying solutions on the market. The vendors of these proprietary PACS typically have to place a copy of their own viewing software on these CD/DVDs, because their proprietary viewer is the only way to view their proprietary study data.
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.
A PACS should treat Presentation States, Key Image Notes, .wav files, Technologist Notes, Scanned Documents, even the Radiology Report as DICOM Objects, not only so they can be shared with other systems today, but also so they can easily be migrated and used in the next PACS. DICOM-conformance is always in the user's best interest.
Now if a prospective buyer knew the negatives associated with proprietary data objects, would they choose a proprietary PACS anyway? Logic suggests that they should think twice. At the very least, if an organization goes ahead with the purchase of a PACS that still creates any proprietary data/object formats, that organization should negotiate a "no-cost" data migration clause in their contract that pins the cost of moving these proprietary objects to the next PACS on the vendor who has continued to choose NOT to conform to the standard.
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.
Posted on 5:29:47 PM comment []
Thursday, September 27, 2007
Take the Archive Out of PACS
Those of you that have been following my recent posts on the subject of PACS-Neutral Archive might find it useful to visit the HIMSS or Emageon web sites to access a webinar delivered today to an audience of 70+ members of HIMSS.
Check it out.
Posted on 3:13:19 PM comment []
Thursday, July 19, 2007
GC's Major Guidelines for Picking the Best PACS
Several interesting posts popped up on Auntminnie's PACS Forum today. Two were related to display software for referring physicians, and two others were related to the log-term archive. In my first response , I spoke about the importance of picking a PACS that featured a single display package that allowed system managers to create individual user profiles by assigning display features through user privileges. I also suggested that the Health System should consider providing the display hardware and IT support for their high volume users, because it would be cheaper in the long run than producing and managing film. In a follow-up response, I flat out stated that as much or more attention should be paid to the display software that is going to be used by the referring physicians as is paid to the display software being used by the radiologists. Failure to win over the referring physicians, especially the surgeons, will surely doom a PACS project.
The first of my responses to the archive issue focuses on using a spinning disk solution for the Disaster Recovery subsystem, and the need for some sophisticated Information Lifecycle Management software in the archive that would make it possible to migrate data from media to media and delete data based on information about the study contained in the DICOM header. In the same article, I couldn't help but ask the question why anyone would create an exact duplicate of the original image data, if the PACS utilized any proprietary formats. It seems to me that if you are going to invest good money in a DR solution, the second copy should be 100% DICOM and 100% inter-changeable with another PACS. This would eliminate future data migration costs. In a second response, I suggested once again that the time has come to separate the Archive from the PACS. The PACS vendors insistence on using Private Tags and proprietary encoding is blatant vendor lock. It is expensive (data migrations) and it should be stopped.
So here is my simple Guideline for picking the best PACS
1) Distributed server architecture. Each facility gets its own Directory and Data database servers and there is one shared long-term archive. Each facility is self-sufficient, yet there is one consolidated patient folder. The central shared server "aggregates" all of the information from the facility servers. The user doesn't have to know where to look for any study on any patient in the system.
2) Single master copy of display software, one common GUI, fat client for performance, web-delivered for zero administration. Each user can be granted access to whatever display features and tools they think they need.
3) Software license fee is based on the number of studies under management, NOT the number of users, or the mix of features/tools being assigned.
4) PACS-neutral Archive: guaranteed universal connectivity, ability to morph DICOM Header Tags in order to copy any meta data in Private Tags to Public Tags, no future data migration necessary. If the PACS vendor that ranks the highest in every other category cannot provide this kind of archive, buy the archive from the vendor who can and configure the PACS with a small working cache.
5) Make sure the archive supports a sophisticated ILM strategy, one that migrates data from media to media or deletes data based on information in the DICOM Tags, data transfers have zero impact on the PACS or Archive application server.
There are other important issues and features to be sure, but they pale in significance to these five.
Posted on 4:32:48 PM comment []
Thursday, July 12, 2007
What was the Department of Veteran Affairs Thinking?
I came across a news article today announcing the VA's plan to establish a Disaster Recovery program for all of their Radiology Departments that had already installed the Philips iSite PACS.
It is well known that the Philips iSite PACS stores the image data in a proprietary (iSyntax) format. The Philips PACS is not the first PACS to be deployed by the VA and it probably will not be the last. When the time comes to replace the iSite PACS with something else, all of that study data accumulated over the years will have to be migrated to that next system. That is going to cost both time and money.
A shared Disaster Recovery program is a great idea, but why deploy a DR solution that stores another copy of the study data in a proprietary format? It seems to me that the deployment of a Disaster Recovery solution is an excellent opportunity to create a second copy of the data in a PACS-neutral format. Start copying the historical data already stored in the iSite PACS to a Vendor-neutral Enterprise DR (archive) solution. Call it a "pro-active" data migration. Then continue to store all new study data accumulated by iSite to this Vendor-neutral DR solution.
When the time comes for any of the sites to move on to their next PACS, there would be no need to migrate that site's study data over to the new PACS. A Vendor-neutral archive (server and storage) would be built and loaded with that site's historical data (in a Vendor-neutral format) and then shipped to the site. This local facility server would interface to whatever new PACS is being deployed. The new PACS would not have to be configured with a long-term archive. There would be no need for the time-consuming and expensive data migration.
A Vendor-neutral Enterprise DR solution could also be shared with all those other VA facilities that do not have Philips iSite PACS. What are those sites suppose to do for their DR solution? How many different DR solutions does the VA want to support? Could it be that all VA facilities will be encouraged to upgrade to the iSite PACS? No doubt that's the Philips plan.
Don't misunderstand, I think that iSite is one of the better PACS in the market, but data migration is an inherent problem with changing PACS, in some cases with the next generation PACS of the same vendor (Siemens Magic to Siemens Syngo). It simply doesn't make sense to build a DR strategy that doesn't take into account the high probability that some other PACS will be deployed somewhere downstream, and thus require a sizeable data migration project. A sensible plan would take reasonable steps to avoid that problem.
It should not be a matter of money. Hardware is hardware. Granted, the Philips software license for that second copy of the data is probably less than what the Vendor-neutral Enterprise DR software will cost. But the cost of all those future data migration projects would more than likely cover the premium charged for a Vendor-neutral Enterprise DR solution that could be shared by every VA site today.
I've written a few other posts on this subject that you might find interesting.
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
If you would like to have a tool to help you estimate the cost and time associated with your future data migration projects, just email me at graycons@well.com and ask for the Migration Prognosticator.
Posted on 12:29:38 PM comment []
Monday, July 9, 2007
Pay Close Attention to DICOM Conformance
The typical PACS includes its own long-term archive subsystem. While the all-inclusive package will present few if any data compatibility issues with its own components, there may be serious problems when the time comes to exchange data with other systems. The archive that it totally owned by the PACS application is usually only marginally DICOM-conformant. The assumption of the self-contained PACS is that there is very little sharing of study data with other systems. The PACS may respond to a remote DICOM query with minimal data, i.e. the original image pixel data and little else. Presentation States, Key Image Notes, and other key meta data objects associated with the images and created by the radiologist during interpretation may not be forwarded, because the PACS doesn't treat these as DICOM objects, or it places them in Private Tags, or it uses a proprietary Value Representation (in the tag) to encode the information. Self-contained Radiology PACS are typically very stingy when it comes time to give up their data in a data migration process. The vendors really think of it as their data, and now that the radiology department has decided to leave them for another PACS vendor, the jilted vendor may be reluctant to help in the retrieval and migration of all of the data that really belongs to the health system. This translates to expensive and time consuming data migrations. Study the Archive's DICOM Conformance statement very carefully. Anything less than full conformance for all data objects and SOP Classes should be addressed in the Contract. Build a technically sound, workable exit strategy in advance.
Posted on 10:02:53 AM comment []
Tuesday, June 26, 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.
Posted on 11:53:57 AM comment []
Monday, June 18, 2007
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
Posted on 2:55:48 PM comment []
Tuesday, June 5, 2007
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.
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.
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.
Posted on 5:29:58 PM comment []
Tuesday, May 29, 2007
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?
Posted on 2:40:39 PM comment []
Tuesday, May 22, 2007
An Enhanced DICOM Archive would be the ticket!
I felt compelled to create a response to a post on auntminnie.com regarding DICOM Archives. The author of the original post thought it impossible to combine a DICOM Archive with a PACS and make it work.
"You can't just take a DICOM archive and slam a new front end on it and
expect it to work. Each of the PACS has many, many, many database and
workstation features beyond the DICOM storage of images that make them
work."
I agree, if the term "DICOM Archive" simply means an archive that stores what it is given and returns the same when it is requested.
But an Enhanced DICOM Archive, one that is additionally equipped to perform customized Tag Morphing, would not only work with any given PACS, it would also be able to exchange study data between different PACS. That alone would make such an archive very useful to a Health System that owns multiple PACS from different vendors. If that archive were also capable of triggering a pre-fetch of relevant priors based on the new Order, and an auto-route of the priors to the PACS, such an archive would be invaluable at the time any of those PACS is replaced, because it would not be necessary to migrate the study data. Now we're talking!
Posted on 9:56:29 AM comment []
Wednesday, May 16, 2007
Another reason to use an RFP
An interesting post appeared May 15 on the auntminnie.com PACS Forum. In short the writer said "most hospitals are understaffed and very often don't recognize all the elements involved in getting the PACS (installed)". I couldn't agree more. That is just another argument in favor of writing and using an RFP. The process brings discipline to the team that is responsible for making sure that everything has been considered, that all the requirements have been listed, and that the winning vendor is able to meet all of the expectations.
I encourage you to read each of the other posts in this thread, as the main theme relates to a disturbing trend in the PACS market. Too many PACS companies are marketing PACS as a commodity and trying to deliver it as a commodity. A good PACS is a custom system that requires a customized deployment strategy. Until this position is fully appreciated, the one-size-fits-all approach is going to continue to fail and leave many of today's first-time PACS buyers wondering what went wrong.
Posted on 1:48:15 PM comment []
Wednesday, May 9, 2007
What is your Disaster Recovery Solution?
Exactly what disaster do you want to recover from? The most common concern is the loss of a RAID cache. Most medical imaging departments have a plan in place to recover lost image data. At the very least, they have written a copy of the data to a Digital Tape cartridge and stashed that copy off-site in a relatively secure location. Taken one step further, they are managing the second copy on a separate remote storage solution; near-line tape, MOD, CD/DVD; or even on-line RAID. That's great, they have the means to replace their primary copy of the image data, should their primary system suffer a "disaster".
But that second copy of their data is most likely an exact duplicate of the same file format stored on their primary PACS archive. They have two copies of the exact same file. At first glance that seems like a solid plan. But is it?
Most current PACS, radiology or cardiology, are less than 100% pure DICOM-conformant. There is always something special, unique, proprietary about how they create or store the data objects. Just enough to make it difficult to change vendors. In effect, this is the essence of vendor lock.
Somewhere in the future, a Health System is going to want to replace an incumbent PACS with a different PACS. That is going to require an expensive and time-consuming data migration. Even if you know this, and actually have the wherewithal to plan for this and accurately budget for this, this could be considered something of a Disaster.
So here is something to consider. Given that you are mandated by HIPAA to create a reasonable Disaster Recovery solution, why make that second copy a duplicate of the semi, not really 100% DICOM-compliant version of the study data created by your existing PACS? Why not avoid the "disaster" of data migration and make that second copy a 100% DICOM-conformant copy of your study data? What I am suggesting is that you redirect your Disaster Recovery dollars into an second, standalone "archive" solution, most likely from a different vendor, who can demonstrate/guarantee that this second copy is accessible to both the current PACS and the next PACS, and the one after that. There would be no need to migrate the data, when you change PACS!
Make your Disaster Recovery solution a PACS-neutral solution, and avoid the very predictable disaster of data migration.
Posted on 9:51:10 PM comment []
Thursday, September 14, 2006
Why struggle with creating your own RFP for PACS?
The art of crafting an RFP for PACS, especially one that is customized for a specific Health System, requires both the ability to match the technology to user expectations and the experienced command of the English language. It's a daunting task for all but the few of us who write RFP's for PACS and read the responses numerous times a year. Practice makes perfect.
I understand the reluctance to pay a consultant to write a customized RFP. Those are precious dollars that could be spent on that second display in the ED. So a lot of today's RFP's for PACS are being written by someone in Radiology and/or someone in Information Technology. A solid effort would require a minimum of thirty hours just to draft the document, and that assumes that the author has a sample RFP or a template to start from. No wonder there is so much interest these days in "borrowed RFP's". Just be advised that the quality of the final document and therefore the value of the responses are only as good as the template that the author starts with and his or her skills with the language.
If you ask any of the PACS vendors their opinion of today's RFP's, they will tell you how truly dreadful many of them are. The questions are poorly written, leaving so much room for interpretation that it is isn't clear what the customer is seeking. Other questions are no longer relevant because the technology is no longer in use. Still other questions are so basic that every single vendor in the market could respond with a "yes", meaning the question was not a differentiator and therefore was a complete waste of time. And nobody gains from a waste of time!
A poorly written RFP requires an enormous expenditure of valuable time on the part of the vendor, much more time than that required to respond to a well-written RFP. A poorly written RFP that the vendor has never seen before requires even more time to study and prepare a response. Given the volume of RFP's for PACS being received these days, it shouldn't surprise you to hear that the busiest vendors cannot respond to all of them. Unless vendors have good reason to believe that they have a very good chance to win the business, they have to decide which to respond to based on the quality of the RFP and the estimated amount of effort required in preparing a response. The poorly written RFP is almost always tossed in the can. That means the Health System loses an opportunity to learn about a particular system, and the value of the RFP in differentiating various solutions is diminished. A poorly written RFP doesn't confirm the best solution, it guarantees the success of the front runner, and the truly deserving competition is encouraged to drop out. You never know what you missed.
Rather than present an array of arguments in favor of using professional help to create an RFP for PACS, I decided that it was time to take a different tack. What's the point in making RFP's too tedious to answer and too expensive to afford? I decided it was time to create an inexpensive RFP generator that anyone can use to create their own very good RFP, one that any vendor will be willing to answer.
Why struggle with creating your own RFP for PACS? The most comprehensive and precisely written RFP for PACS in the industry can now be yours. Create your own RFP from an inexpensive template available from Gray Consulting. The $495 package includes Template, Instructions booklet and one-hour phone assistance. Contact me by phone or by email for more information.
Posted on 10:02:46 AM comment []
Thursday, August 4, 2005
Middle-life crisis
Strategic Planning is not just for those looking ahead to acquiring a new PACS. The few hundred Philips PACS customers that find themselves wondering about their systemís future, should probably start some Strategic Planning. Those users with systems that are five or more years old, are probably already planning for their next system. But everyone else with systems somewhere from brand new to four years old, considered the middle-life of a PACS life expectancy, should start some Strategic Planning. What could you do in the short term to smooth the waters ahead? Just how far outside of radiology should you push the current web viewer solution? Should you continue to store image data on the PACS-attached storage solution, or consider migrating it to a vendor-neutral solution? You could probably start preparing the department for the next system (whatever it might be) with fewer dollars than that required to purchase a new system. My recommendation to all those departments in middle-life crisis is to start working on some Strategic Planning right now.
Posted on 1:09:46 PM comment []
