If you've ever been through a real hurricane, you realize that preparation is key. You also realize that regardless of how well you plan and prepare, nothing ever goes as expected. That's also what it's like to face Hurricane PACS -- a virtual storm you can weather with careful planning and no shortage of resiliency.
With each hurricane I've been through, I've learned more about what I need to do to prepare. I've also learned, after the fact, how fate tends to throw me a curveball each time. I felt I couldn't have been more prepared for Hurricane Irma, spending three days getting my house ready for anything. When Irma finally hit central Florida Sunday night, it was barely at hurricane strength, exhibiting peak winds of 75 miles per hour. In contrast, Hurricane Charley back in 2004 had peak winds nearly twice that speed (140 miles per hour).
PACS consultant Michael J. Cannavo.Logically, you would have expected minimal impact with Irma. Instead, the same number of people who lost power with Charley (1 million) also lost power with Irma. I never lost power with Charley, so why even bother to bring out the generators, I thought? A week of no power and $800 worth of food in the garbage would provide me with my answer. We all prepared well -- yet food, sleep, patience, and power were all in short supply by week's end.
One of the major frustrations I have faced as a PACS consultant is hearing the words, "We've already implemented a PACS, so we know what to expect." That's like saying you've already been through a storm or you have one kid so you know what to expect with the others. As anyone with kids knows, no two kids are the same, and any expectations you have about similarities tend to go out the window soon after they say, "Hello, world!"
As Irma made its way through Orlando Sunday night, though, I felt confident. My subdivision has underground utilities, and while the winds howled outside, I had power and even access to the internet. I went to bed shortly thereafter, confident that I dodged the bullet again. At 3 a.m. I woke up and it was darker than usual. Hmmmm, I thought. Power outage. No biggie.
The next day I visited friends in the neighborhood next to ours. Their power came back on 11 a.m. Other friends half a mile away got their power back on at 1 p.m. "We're next!" I thought confidently. At 6 p.m. on Friday -- a week later -- I was finally able to quote Genesis 1:3, saying, "Let there be light." And it was good.
How could I have been so wrong? Technically, I wasn't. I used all of the information available to me, and I thought I had enough and knew enough to make an informed decision. But it turns out the information I had was limited, and I didn't or couldn't take into account variables that I had no knowledge of or control over.
No two PACS are the same
My experience is no different than PACS end users who have used one vendor's system for years and base their implementation plans for a replacement system, upgrade, or expansion only on their prior experiences or those of others they know. But just as no two kids are the same even from the same parents, no two PACS are the same either. Time and again people base decisions on what they know or feel they know, not what they really need to know. That can be a catastrophic mistake.
Now luck always plays some part in the end result as well -- as it does with everything -- but luck should not be counted on to help in the end result, except as an adjunct to solid planning. Nearly all of those using a PACS today are working on their second-, third-, and even fourth-generation PACS. Nearly all performed the requisite online demos, site visits, and all sorts of other goodies before they signed the contract to replace their existing PACS, even if they are just upgrading their existing one.
But buying a PACS is like entering into a marriage: You never really know what you are getting into until you are in it. And a lot of times what you thought you saw or felt you saw wasn't the reality. Making matters worse, a lot of facilities have limited knowledge of the available technologies that will either solve problems and/or generate additional revenue. While sites may be content with what they have, or at least what they have seen and think they need, in actuality they may be missing out on more efficient or cost-effective solutions. Knowing their requirements and examining all of the options available is crucial to getting optimum performance from the department and those they serve.
Define your needs
Sites need to clearly define what they want and need, but this has to be very specific and leave little, if anything, to interpretation. Do most sites do this? No.
Ideally, sites should perform three tasks: technical, operational, and workflow assessments. These should look at the big picture and not just address immediate needs. Importantly, these assessments should also be completed before they begin looking for a new system or component.
Key to all of this is looking closely at how things are done now and how they can be done better with any upgrades that may be considered. The facility's network, HVAC, and other areas also need to be reviewed to ensure they meet the new proposed PACS requirements. Lastly, make sure you have adequate people to support the required system's administrative tasks.
Rarely are these assessments done, and even if they are, they're often completed after the fact -- once a contract has been signed. Why? Vendors often do not feel a responsibility to do anything more than a simple baseline assessment, while end users often feel that they've have had PACS for years and know how it works. That is like saying I've been married before so I know how it works.
Most vendors will do a very limited baseline site assessment -- not to be confused with a workflow or operational assessment -- to help them prepare their quote. Unfortunately, this is often incomplete. The end result is a system design that the vendor thinks will work but really won't, or at least won't work as desired by the end user. This is because numerous questions are often left out or the information obtained doesn't completely or accurately reflect how the site operates. Most of the "analysis" done is merely "fill in the blank" answers to questions in a spreadsheet format. These questions were often put together well over a decade ago with the data input without any regard to the uniqueness of each site.
This creates situations where a site is sold a cloud solution to archive digital breast tomosynthesis (DBT) studies, for example, over a wide area network (WAN) with a 1 MB upload speed. Regardless of how hard you try, this simply isn't going to work. This also leaves the customer having to deal with unbudgeted expenses to upgrade the network and probably the routers, firewall, and other network components as well. Changing network providers can also be a significant cost, especially if you are on a contract.
Even vendors who do have dedicated presales consultants who perform more detailed assessments don't always ask the right questions. If a site does 25,000 mammography studies a year, for example, it makes a huge difference on both the archive and the network if these are 2D or 3D (DBT) studies. Most models just ask about the number of mammography studies performed, period. The same can be said for CT and other modalities where different facilities have different study types with slice counts.
Site assessment and preparation
Who is responsible for site assessment and preparation is an oft-debated topic. While both sides have merit to their arguments, I favor the vendor ensuring its solution will work. Selling a site a cloud solution, for example, typically requires -- at a minimum -- checking the upload and download speeds of the existing network to ensure that the uploads won't time out. It's all about logic.
While there are costs associated with doing a more detailed site assessment, most sites have no issue with it if they feel they are getting value for their investment. This is important for both parties -- and especially for the vendors -- because nearly all of the profit in PACS these days comes from these professional services. These include implementation, training, site assessments (technical, operational, and workflow assessments), and service contracts. There is almost no margin in the system software, which is why you often see discounts of 75% to 80% or more from the software list price.
Very few vendors offer turnkey solutions anymore because the efforts required to support hardware exceed the 5% to 10% (if that) margins they can get on hardware. End users who wind up buying their own hardware can benefit from much longer warranties as well -- three to five years versus one year with a turnkey solution. Many sites are also evaluating and implementing virtual machines, with all or most of the hardware hosted in the cloud. Also popular are hybrid packages, which include limited onsite hardware (mainly for redundancy) with the rest hosted in the cloud.
So why are the costs relating to professional services sometimes higher than the cost of the actual PACS itself? Professional services costs carry with them a host of unknowns going into an implementation. The vendor needs to not only cover the costs for the specialists required to implement a PACS (interfaces alone can be extremely complex and time-consuming), but also needs to show a profit while doing it. Unfortunately, with more complex projects even the initially high margins for professional services can get eaten up if a project isn't managed properly.
Software as a service
To avoid having to support hardware where the margins are razor thin to nonexistent, many vendors have stopped offering hardware-based solutions and are going to cloud-based solutions using a software-as-a-service (SaaS) model. In this case, the end user provides and supports all required hardware while the vendors provide the software.
Software and service is often combined into a subscription model. This is also known in the industry as "per click": The cost equals the number of procedures times a fixed rate. Most of the facilities hosting their disaster-recovery services in the cloud use a SaaS model as well, although this is typically a separate charge.
Many companies are taking this a step further and implementing PACS with an infrastructure-as-a-service (IaaS) model, hosting hardware, software, servers, storage, and other infrastructure components on behalf of their users. IaaS providers also host users' applications and handle tasks such as system maintenance and backup and resiliency planning -- something that typically isn't done with SaaS. IaaS platforms offer highly scalable resources that can be adjusted on demand, which makes this model well suited for workloads that are temporary, are experimental, or change unexpectedly, or in a situation where a large organization expands and brings on additional facilities.
Lessons learned
So what did we all learn going though yet another hurricane in Florida? Planning is key, but being prepared for the unexpected is equally important. In the 13 years since the last hurricane, the power company has yet to learn that it needs to be more proactive in tree cutting and, above all, that it needs to have redundancy in its feeder lines.
Just as with PACS, where it's not only about the hardware and software, the power company is now including proactive training of emergency crew forces and coordination with municipal public works as well.
And what did I personally learn? Fill the gas cans and take the generators out even if it doesn't look like you'll need them (I needed them and didn't have them available). Have the rain suit available in case you go outside (I had to drain the pool in the middle of the storm three times with 60-mile-per-hour winds whipping around so the pool didn't overflow and flood the house). And take absolutely nothing for granted. Learn as much as you can and never, ever assume you have it all covered. There is no such thing as being overprepared.
Just as no two storms are the same, no two PACS implementations or the preparations for them are the same either. You can weather just about any storm by asking the right questions and using all available resources to get the information you need. Of course, a little luck on your side never hurt either.
Michael J. Cannavo is known industry-wide as the PACSman. After several decades as an independent PACS consultant, he worked as both a strategic accounts manager and solutions architect with two major PACS vendors. He has now made it back safely from the dark side and is sharing his observations in this Straight Talk From the PACSman series.
His healthcare consulting services for end users include PACS optimization services, system upgrade and proposal reviews, contract reviews, and other areas. The PACSman is also working with imaging and IT vendors developing market-focused messaging as well as sales training programs. He can be reached at [email protected] or by phone at 407-359-0191.
The comments and observations expressed herein are those of the author and do not necessarily reflect the opinions of AuntMinnie.com.
