My most recent engagement opened my eyes to the complexities that surround cloud implementation. It's far from "take the hardware away and host it in the cloud" like so many think. Implementing a cloud-based PACS or an enterprise imaging system (EIS) is intricate and complex.
The PACSman, Mike Cannavo.You can spend hours analyzing whether cloud native is better than cloud enabled, but the net result to be considered should be does it work and meet your requirements? This is especially important, as there are few true cloud-native systems in the marketplace.
Cloud native is generally better in several areas, including scalability, ease of use, cost, performance and reliability, implementation, and support. That said, cloud-native systems are not immune to their own issues, such as higher initial and ongoing costs, limited options for data migration, limited selections (and added costs) of cloud services providers (CSPs), and the need for a hybrid system in the event of a failure by the selected CSP, among other areas.
RFP process
When doing an evaluation of a replacement PACS (or implementing a full EIS that includes cardiology, pathology, and other areas), many facilities start by developing a request for proposal (RFP). This can take several months to develop followed by several more months to submit the RFP and then evaluate the vendor responses.
It has been my experience that this entire process just adds time and costs to the decision-making process and frankly isn't necessary in the vast majority of cases. Unfortunately, some facilities are required to go through the process to show they have done proper due diligence and justify any expenditures.
The reality -- and this statement is bound to be controversial -- is that most facilities already know the vendor they want to select before they even start the evaluation process. The evaluation process is often designed to fit the desired peg into the desired hole, although sometimes, the final decision happens to end up being the square peg in the round hole.
Unlike an RFP, a technical spec that outlines what you have and what you want is crucial to getting a properly designed system. However, telling a vendor how their system needs to operate serves no valuable purpose. Their system is going to work as it works. There may be some customization or tailoring available, but they aren't going to rewrite the core software code just to meet a facility's requirements.
Functionality over features
One of the biggest things to do when evaluating a system is to look at functionality, not the stated features. How the software works is what is important, not what it is called. Also, don't try to make a system do what it can't do either.
If one system can do what you need it to do in three keystrokes and another takes eight, the answer of which one does it best in that particular application is black and white. You then need to determine how important that application is to the overall system performance, the impact the additional keystrokes will have on radiologists' workflow, and what the long-term net effect/cost will be.
This might sound fairly minor, but if doing a complex and lengthy study like a PET exam doubles the time because the functionality needed isn't there, it can add up to significant added costs. This difference will also more closely level the playing field between the vendors being evaluated.
Project management
Outside of developing the technical spec, a project manager who knows the facility well -- and not just the evaluation and implementation process --- is crucial. Yes, a project management professional (PMP) certification is nice, as is having a Ninja Turtle Black Belt, but it certainly isn't necessary.
Above everything else, you need someone who knows the internal processes and political infrastructure, not just the basic project management process. In my most recent engagement, we unquestionably had the best project manager ever. He juggled so many balls in the air without missing a beat that it made your head spin. Above all, though, he knew the political infrastructure -- whom to contact for what and how to address their specific needs.
This is especially crucial in dealing with individuals within the C-suite who control the pursestrings -- providing them with what they need to know and avoiding what they do not care about or don't want or need to know. As a bonus, he kept both the vendors and internal staff in check as well.
Data migration
The process of implementing a cloud system involves many steps. One of these is data migration. Most companies will allow you to use one of the dozen or so vendors who offer these services, while others prefer to do the migration themselves or use a preferred partner.
Migration success rates vary from less than 1% data loss if done by the vendor to as much as 10% data loss, again depending on how the migration is done. The more information that is needed, such as DICOM private tag data, the longer it typically takes to migrate and the higher the costs, although this varies by vendor. Migration done by the vendor typically has the highest cost but is also the quickest and most accurate as well.
When you get a new system, you typically have to develop your own hanging protocols. This is no small task, easily taking several months and upwards of a year. Radiologists like to have studies displayed in a way that is most efficient for them to read, and most have their own preferences.
As you can imagine, customizing hanging protocols for every study and modality and tailored the way each radiologist likes to read them is a Herculean task. If you are lucky, the vendor might have some protocols from a few sites that developed them for their radiologists that can be tweaked so they don't have to start from scratch. But there is no guarantee.
AI options
Many companies have limited AI options, but until there is a current procedural terminology code to compensate for its use, you won't find many companies offering it, at least not extensively. AI is a wonderful adjunct to a radiologist's interpretation and can provide added value, but the cost of using it needs to be addressed by someone.
That is probably why AI has only been adopted by just 3% to 5% of the imaging community, if that, and mostly by academia and major institutions that have deep pockets. The same can be said of many other third-party software options as well.
System uptime is generally much better in a cloud environment than an on-premises installation due to hyperengineered systems used in the cloud, system redundancy, and continuous system monitoring. Software updates and upgrades can also be done in the background without a client even knowing it is being done.
Some on-premises hardware is still required in a cloud environment and often includes a DICOM router that forwards incoming requests and returns meaningful status and results (if there are any) to the client. These include DICOM commands like C-Find, C-Get, and C-Move. There also should be a redundant server with minimal (one-year) onsite storage in the event that the connection to the cloud gets interrupted. This will allow radiologists to continue to read and provide near seamless operation.
Costs
It is important to understand that in addition to the per-procedure costs, there are one-time upfront costs. These are typically equal to or even greater than the per-click costs. If a facility is doing 300,000 procedures per year at $2 per procedure annually (plus network costs), you can often expect an initial startup cost of $600,000 to $700,000 (or more).
Network costs can also add anywhere from 50¢ to $1.50 per procedure as well depending on network speed, the use of load balancing, and other areas. These network agreements are typically negotiated outside the PACS/EIS agreement with the cloud provider but can be included in the per-click charge as well.
The biggest challenge with the cloud is managing expectations with something that is unknown. As stated before, it is far from a simple implementation. Costs can be a bit higher in the cloud than with an on-premises system as well, but it tends to balance out by reduced support costs, higher system performance (uptime), and the ability to experience real-time software updates and upgrades, among others.
Cybersecurity
Cybersecurity is another major concern that IT needs to evaluate and address. Having a business associate agreement in place with both the PACS and network provider is crucial and will help avoid HIPAA penalties in the event of a data breach. As it's always much better to be proactive than reactive, having firewalls and other security devices in place is a plus, provided it doesn't significantly impact transmission speed.
Keep in mind, until you actually move to the cloud and do the cutover, your existing PACS needs to be fully operational. Be forewarned that it can take 18 to 24 months (or longer) from the start of the replacement evaluation process to the actual cutover from one system to another.
In theory, you can start the data migration process before a new contract is signed, but it is always best to wait. Ditto on signing the cloud services provider (CSP) contracts if they are not a part of the PACS/EIS contract. You can sometimes get a better deal by bundling the CSP contract with the main deal, but that is not always the case.
A viable option
The cloud is worth looking closely at and offers a viable option for on-premises deployments. Nearly every PACS/EIS vendor offers a cloud package, and many now are offering only cloud systems as well. That said, it is crucial to know what is involved before you take that jump. It would take a book to address all you need to know before making a well-informed decision, but this article should get you started and help you understand the complexities surrounding implementing a cloud-based PACS or EIS.
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.
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 to develop 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 are those of the author and do not necessarily reflect the opinions of AuntMinnie.com.
