Getty Images
With over five years of presence in the rapidly expanding enterprise imaging (EI) community through organizations such as the Healthcare Information and Management Systems Society (HIMSS) and Society for Imaging Informatics (SIIM), it became clear that large integrated delivery networks (IDN) are serious about planning to adopt or are already implementing an EI strategy across all their hospitals and clinics. The information technology (IT) departments of these organizations are aware that the sum of all digital data of all the imaging studies generated in their IDN will completely overwhelm the existing storage capacity in their data centers and vendor neutral archives (VNA). In many cases their VNA is currently only serving the radiology and cardiovascular service lines and does not include digital imaging data of any of the many other departments that are intensive users of imaging, such as GI, dermatology, OR, emergency rooms, and so on.
With the advent of EI, chief information officers (CIO) are now thinking as follows: “I probably could calculate the total volume of storage space I will need today to start an EI strategy, but how to calculate what exactly I will need five years from now? Even in case I could do that, what would be my choice of storage technology? It’s pretty much clear that if I purchase and implement this technology today, that same technology will be obsolete in five years. What happens then? I will have to decommission the obsolete storage technology, which is a costly endeavor, and migrate all the data, another costly exercise, to a new, to-be-purchased, technology. Then, four or five years later I will have to run this replacement cycle all over again. This is clearly a no-win situation. I need to find a more flexible alternative.”
The Cloud Comes to the Rescue
CIOs quickly came to the conclusion that a capital expenditures approach, or CapEX, with storage infrastructure on-premise did not make sense for large, continuously evolving EI projects. Many are now exploring the feasibility of running the EI applications in the cloud. Some of the resources will still reside in the data center, but only to avoid internet latency issues.
Many vendors today are providing data centers “in the cloud.” Among those are Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform, IBM Cloud, Oracle Cloud and SalesForce, just to name a few. In other words, the storage and computing resources that would be traditionally located in the datacenters of the IDN can now be securely located in the datacenters of the cloud vendor, connected to the IDN over the internet. To mitigate possible issues with the speed of data access when working with applications in the cloud, limited local IT resources are made available in the IDN’s data center for short time storage and computing. The cloud vendor will bill the IDN with an operational expense charge model (aka Opex), based on the dynamically evolving storage and image processing demand and the amount of service level (e.g.: response time, uptime objective) the IDN requested, based on a mutual vendor-client service level agreement. The customer can even outsource the task of running the EI applications in the cloud and contract the EI applications vendor for “hosting” these operations. The EI vendor will advise the IDN when expanding the cloud storage and computing capacity is needed. Obviously, this cloud-based hosting approach is a safe and effective way for addressing the technical and operational challenges that the IT department would have faced with managing on-premise storage and computing infrastructure. But wait, there is more.
Cloud-native Architecture: A Must for Enterprise Imaging
For many years, IDN IT departments have moved away from running specific software (SW) applications on dedicated hardware (HW) servers in the datacenter. Instead these applications are now running on a pool of virtualized machines, which can be scaled up as needed. A SW “hypervisor” allocates the virtualized computing resources as needed to the different applications. IT departments can simply add server resources (“blades”) when required by new applications. Virtualization offers several advantages such as easy scalability to meet growing computing demands, and maximum uptime and performance. On top of that, there are also important cost savings such as decreasing upfront capital costs and improving operational expenses by eliminating the need to manage dedicated HW servers for each application.
What happened with hardware virtualization is now coming quickly to software. Many IT departments and imaging service lines have experienced imaging software upgrades with systems such as PACS, and are very aware of what the issues are. Sometimes upgrades go smooth, more often they are painful or worse. Vendors often issue yearly upgrades, but IDNs are seldomly updating their enterprise PACS on a yearly basis. It can take them often three, four or even five years before upgrading because of the scarce resources in IT departments and the limited training capabilities in imaging service lines to familiarize all users with the new PACS features. EI upgrades will make things even more complex. Imagine the difficulties that could emerge in an IDN-wide enterprise imaging rollout when a SW upgrade becomes necessary for a specific department, but the upgrade will not benefit all other departments? Will an IDN-wide upgrade be acceptable when only dermatology is the beneficiary? How will other departments react on upgrading “when there’s nothing in there for them?” A more modular approach would certainly make sense; upgrades should be provided for a certain department without any impact on the operations of other departments. But how could this be done? That is where a cloud-native architecture of EI SW comes to the rescue. In contrast with a lift-and-shift cloud approach, in which traditionally developed SW applications are running in the cloud instead of on-premise, cloud-native architecture allows developers to create modular SW applications called microservices which are built to live in SW containers. These microservices provide a single function and have limited dependence on other services. All the services needed for an efficient imaging informatics workflow in a service line, such as dermatology, are located in a container. Other containers with different microservices can provide other functions: user login, patient/study selection, image mark-up, clinical notes, HIPAA enabling, viewing, storing and archiving, advanced image processing, -ology specific toolsets and much more. The containers provide these services on-demand and are called by the orchestration management software at the time these functions are wanted by the user. Resources, such as computing power and storage capacity, are provided dynamically on-demand. When more is needed, more resources become available, when less is needed the online computing power scales back, and all this within milliseconds. The industry realized quickly that cloud-native is the way of the future for building nimble SW. The Cloud-Native Computing Foundation was created in 2015 and became a huge organization with participation of best-in-class IT companies. Visit https://landscape.cncf.io/ for details. This organization is expanding fast.
What Does This Mean for an IDN With EI Plans?
I described already upgrade requirements in a specific service line in order not to impact other departments. In a cloud-native architecture, the upgrade will be performed with the specific department-only microservices, neatly organized in the well-orchestrated specific container. As mentioned before, an upgrade for dermatology-only will absolutely have zero effect on the EI applications in other departments.
As an additional benefit, the upgrade can first be performed in a cloud-based test-environment, without having to install a test-server on-premise.
Finally, the COVID-19 financial impact drives IDNs to look for ways to cut capital expense and IT overheads due to the rapid drop in revenues and pressures to improve operations. Cloud-native, all-inclusive SaaS is an ideal solution and a no-brainer.
Cloud-native Computing
The nimble cloud-native architecture is taking full advantage of numerous cloud benefits. In contrast, the “lift and shift” approach is just hosting the legacy EI applications and data storage in the cloud. Lift and shift applications have the same issues as on-premise solutions when new software upgrades and updates are needed. With products based on a cloud-native architecture, IT can drive down cost because EI applications and storage will be virtualized in the cloud. IDNs will benefit from increasing reliability, security, privacy and scalability. You can quickly expand your EI system in lock-step with growing requirements. Clinical users will benefit from ease of access from anywhere an internet connection is available. “Evergreen” software will have all users on the latest release. You will be able to upgrade departmental SW more frequently, as will be required by artificial intelligence applications, among others. Smaller hospitals can benefit from the economies of scale and have access to functionality, which is traditionally reserved for “whales.”
Many major companies in the imaging informatics and EI business are already building products today based on cloud-native architectures and some companies have these products already commercially available. One can expect that many vendors will soon follow suit to stay competitive. IDNs who want to experience the greatest cloud benefits should look for EI vendors that are promoting cloud-native architectures in their offerings and roadmaps. EI RFPs should include cloud-native architecture requirements. Lift and shift concepts are rapidly becoming obsolete. Cloud-native computing is the future for computing solutions in EI applications.
Henri “Rik” Primo has more than 40 years’ experience in healthcare IT and imaging informatics in both healthcare and manufacturers organizations. In 2018 Primo retired from his strategic relationships director position at Siemens Medical Solutions USA Inc. where he was responsible for the effective coordination and participation in standards and regulatory activities for imaging informatics and for the relationships with analysts, consultants, media and luminary users in the domain of imaging informatics. After retiring from Siemens, he founded a consulting company, Primo Medical Imaging Informatics Inc., based in Chicago.
April 25, 2024 
