Wednesday, February 27, 2008
Cost-effective Business Continuity Solutions - So much more than Data Back-up
Most Radiology PACS currently in use have some sort of data back-up in place. At the very least, the Directory database and the Data database are backed up daily to digital tape. In my opinion, digital tape is not reliable and the problem is you don't know what data you have lost until you try and retrieve it. My low opinion of digital tape is supported by a number of reports from the field. I suspect the vendors that continue to insert digital tape back-up solutions in their early round quotes, do so in order to keep the price of the system down, but a much better solution is worth a few dollars more.
The "tape-less" back-up is a much better back-up solution. Instead of digital tape on a shelf or in a mechanical jukebox, a far more reliable and performance-oriented solution is to store the back-up copy of the Directory and the Data on spinning disk. Thanks to today's pricing, a multi-processor, multi-core server coupled with a disk-based storage solution is only slightly more expensive than a digital tape library. I think the reliability is worth the additional investment.
Why stop there?
Instead of just writing a copy of the Directory on the back-up storage solution, why not install a second instance of the Directory application (Oracle, Sybase, DB2, SQL, etc.) on the back-up server? Now you have a reasonably cost-effective Disaster Recovery solution, depending on where you have physically placed that back-up system.
Why stop there?
Why not add a second instance of the PACS application to the back-up server? Now you have a reasonably cost-effective Business Continuity solution. Of course this complicates the PACS application considerably. The optimal software configuration would have the two Servers (Primary and Secondary) functioning in an "Active-Active"mode, and that would mean that the Directories are being automatically synchronized in near-real-time, and the study data is being copied from Primary to Secondary on a fairly regular basis.
Only the newest generation of PACS can support this configuration. Most of the PACS being sold today can support a "tape-less" back-up server, but they do not support a second instance of the Directory application on that back-up server. The few that do support a second Directory do not support a second instance of the PACS application. Fewer still that support a second instance of the Directory and the PACS application have the back-up system operating in a standby mode. The Back-up takes over only when the Primary is off-line for scheduled or unscheduled maintenance. While this version of back-up may not sound so bad, the fact is that the failover and eventual reconstitution processes are often manual and labor intensive.
The point in all of this is, with today's cost of hardware it doesn't make sense to settle for a back-up solution with questionable reliability, when a much more reliable Business Continuity solution is affordable. The problem is most PACS currently being sold are "old" generations of system architecture wrapped in pretty GUI and flashy 3D applications. While GUI and display applications are important, I believe that the system architecture that supports a solid Business Continuity solution is more important, and sooner or later those old generation PACS are going to be upgraded. You can tell a lot about the longevity of a PACS, by investigating the various back-up solutions that it can support. Why start a five year contract with an old PACS? Do you have room for a forklift in your data center?
Posted on 11:08:41 AM comment []
Wednesday, September 26, 2007
Is new Stark Exemption an Opportunity?
I came across an article in Imaging Economics titled "Surveys Show Paper Legacy Tough to Shake"
What caught my eye was the second paragraph statement "A new Stark exception allows hospitals to donate health information technology in the form of an EMR to private physicians."
I was wondering if the definition of "EMR" could be extended to radiology web viewer? Is this possibly a mechanism for providing the necessary hardware (PC), software and connectivity services to the referring physician office to get them to stop requesting paper and film?
The article is worth reading as it explains why "more than 50% (hospitals) continue to print and distribute paper lab and imaging reports." This does not come as a surprise to me, but it occurs to me that if so many hospitals are still printing paper radiology reports, a similarly large number must also be distributing hardcopy images.
Clearly the success of a Radiology PACS depends on turning off a large percentage of hardcopy and getting the referring physicians to access images and reports from their offices electronically. I have long argued that the cost of providing a suitable PC and basic connectivity services is more than paid for by the value of the hardcopy. Many clients were concerned about the Stark implication. Is this exception an opportunity?
The article goes on to explain that 62% of hospital executives surveyed in February said their organization had no plans to donate technology. "They're waiting to see how the government changes the landscape. How will it affect their nonprofit standing, that kind of thing." Once again, I think this is a shortsighted point of view. The continued printing of hardcopy films is certainly affecting their bottom line. Why not take advantage of this opportunity to legally equip their referring physicians with a much less expensive method to access images and reports?
Posted on 10:37:48 AM 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, August 8, 2005
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.
Posted on 9:45:45 AM comment []
Thursday, August 4, 2005
Time for a check-up?
There
are probably a few PACS out there that have yet to fulfill all of the
expectations.
So
how much time after "go-live" should it take to achieve the goals
that were originally set? Is it time for a check up?
There ís
probably nothing seriously wrong with the system, certainly not
enough to suggest it should be replaced. Maybe there are just little
things, details that can only come to light after you're up and
running. A year or more of run time is more than enough experience
with the system. By now you should be very close to achieving that
drop in film demand. You should know exactly what the problems are,
and how you're going to correct them. If not, maybe it's time
for a check-up.
Take
a look at these check-up questions and test yourself with the
answers.
Check-up
questions
How close are you to achieving the drop in film costs projected in those pre-PACS plans? Exactly what is keeping you from reaching that goal?
How many of the true image users in the referral community are still asking for film? What are your current plans for correcting that?
How close are you to eliminating the problems caused by paper in the workflow?
Have you thought of more than five ways to use the CD?
What can you do to reduce the report turnaround time even further?
Have you been successful establishing a "virtual seat" for the Emergency Department and high-value outpatient studies?
What features unique to PACS have your radiologists adopted in an effort to attract more referrals?
Besides sticking a display in the ED, what have you done to improve the workflow between the Emergency Department and Radiology?
Who spends more time per study on QC tasks, your technologists or the system administrator?
What is your long-term plan for the inevitable data migration?
Posted on 1:06:00 PM comment []
