TALK TO AN EXPERT TODAY
United States
2024 Hickory Road suite 208, Homewood, IL 60430, USA
United Kingdom
10 John Street, London WC1N 2EB, UK
Romania
Strada Republicii 87, Cluj-Napoca, Romania
Key Takeaways
According to Wikipedia, a general definition of Disaster Recovery (DR) is: “Disaster Recovery involves a set of policies, tools and procedures to enable the recovery or continuation of vital technology infrastructure and systems following a natural or human-induced disaster.”
Variations of this definition can be easily found around the Web but they do generally converge.
In our opinion, the key elements here are “recovery” and “continuation” of vital functions following a disaster. In other words, for an enterprise to be covered through a DR implementation, it is hard to decouple these two elements.
The Disaster Recovery plan includes all your business-critical systems and needs to be updated each time those systems are replaced. When talking about Healthcare IT and, especially, imaging – DR planning and implementation takes a particularly difficult turn.
From the end users’ perspective, what really matters in a disaster scenario is that it can execute the tasks it would normally do normally, to the greatest possible extent. Stated in general terms, functionality of an enterprise application is given by its ability to present and manipulate the data it manages in a useful way. Which leads to the necessity of including both the application AND its data into the DR implementation.
This is particularly true with respect to the EMR systems. The main selling point of most of the established EMR vendors is the ability of catering to the hospital’s needs. This leads to a tight integration of the data and the application managing it. Thus, a block-level approach to implementation of a DR plan is appropriate.
However, when talking about imaging, things are gaining in complexity. A lot of that complexity is driven by the sheer volume of the data.
This volume is often now far surpassing the hundreds of TB range as we witness a massive push through the petabyte (PB) limit, with many organizations gathering more and more PBs under their belt through mergers and acquisitions as well as organic growth. Also, the growth of imaging procedures and the data associated resulting is significant, almost tripling in the past 5 years, as this Health Data Management article shows.
Managing that volume on a day-to-day basis is a separate problem, requiring considerate amounts of operational planning. The complexity is then carried forward when talking about implementing a DR plan covering it.
One must plan for transfer of significant volumes of data between the primary and secondary storage, which has significant impact on the overall IT infrastructure. Anyone implementing a DR plan for a PACS or VNA system holding 10 petabytes of data – will have to secure and manage 10 additional petabytes of data, which yield in cost and overall burden on the IT department.
Further, you need to maintain your DR implementation. The planning changes each time a vendor that is part of that implementation changes. Which opens the gates to a whole new series of problems, which we will address in future posts (Hint: you have 10 PB of DRd data, you switched vendors which rewrite the entire 10PB of data in a new formatu2026 which requires you to redo your DR implementation from scratch, backing up once again 10PB of data!).
All in all, Disaster Recovery planning and implementation in Healthcare IT places significant burden on the hospital’s IT infrastructure and IT organizations.
Enter cloud.
And a new old and established way (call it Standard!?) of doing things.
Yes, we say. It is now possible, with a little help. The cloud, an abstract concept too good to be true a decade ago has become prevalent these days. Cloud infrastructure matured and the commercial availability of cloud solutions is now present from a plethora of vendors.
Overall, healthcare embraced the cloud. This article from zdnet does offer some good insights on that move. The Web abounds of such stories. As stated earlier, the focus seems to be EHR. There is very little on Medical Imaging.
The reason?
As you might guess – it’s the data volume. Radiologists operate a high-volume workflow and are keen on having the studies snap on their viewers in milliseconds. Productivity is key. Speed – drives that productivity.
Modern infrastructure does address that part. However – there is still an issue.
While reading studies from the cloud may be done seamlessly given adequate provisioning- how do you get into the cloud the petabytes of data that you already have to start with? Such a move requires significant amount of time and effort from all parties involved and so far, discouraged many from taking this road. The timelines needed to switch to a cloud system are punishing and traditional practices of performing such migrations will take you all the way into decades (yes, no kidding!) of implementations, time in which you will need to support at least two systems (your on-prem and your new cloud implementation).
In our following posts, we will show how implementing a smart Disaster Recovery plan is an excellent avenue to get to the cloud now, without disrupting your current clinical operations.
And, most importantly, once there, you can easily move your imaging solutions to the cloud, in your next software refresh cycle. How? The answer lies right in front of the industry and has been there for decades: standardization of stored data. It is not time to act. There is no more room, quite literally, to wait.
Until then, here are some of the key aspects of supporting such a forward move, from our colleague Harry Solomon:
Author Razvan Costea-Barlutiu MBA, is Laitek’s Chief Technical Officer and is responsible for software development, innovation, data migration technology and thought leadership. He leads Laitek’s development and system engineering teams with a focus on developing high-performance PACS components and overseeing the technical aspects of Laitek migrations. Razvan originally worked with Dr. Behlen in Rossman Labs at University of Chicago on the National Digital Mammography archive and developed the first tools that performed a full round-trip conversion from DICOM to XML.
2024 Hickory Road suite 208, Homewood, IL 60430, USA
10 John Street, London WC1N 2EB, UK
Strada Republicii 87, Cluj-Napoca, Romania