string(7) "English"

The Death and Rebirth of //Healthcare// Infrastructure

Note: these are my personal views.

This is a riff on a superb blog post by Ben Fathi — The Death and Rebirth of Infrastructure. Ben is the ex-CTO of VMware, ex-head of engineering at CloudFlare, and general technology bad-ass.

Ben says “We need to agree, as an industry, that the Enterprise-IT-owned-and-operated data center will also soon go the way of the Dodo.” He then ends with “Who do you think will be more agile five years from now? The enterprise companies who amassed their own data centers and spent their time being System Integrators for the old guard or the ones who bet on the next generation computing platform – the cloud?”

I have taken the liberty of building on Ben’s point of view, and propose that in Healthcare, we’re going to end up in a world where there are 2 types of infrastructure – one, local, on-premise, purpose-built, appliance-like, converged infrastructure; the other, in a healthcare cloud. Here’s why:

  • Part of the need for ongoing local infrastructure in Healthcare is on account of the, shall we say, more challenging application architectures and topologies that have perpetuated since the 1980’s when some of these applications (EMRs) were built. Note that I’m still calling these EMRs because simply renaming them to EHRs, as they have been in modern day and time, didn’t change the underlying architecture.
  • Part of this need will continue to be on the basis of control, compliance, security, data governance, data ownership, etc. – and some of these items may be more emotionally driven rather than being factual.
  • A large part of this need is on the basis of strict uptime and performance SLAs needed by these life-or-death, mission-critical applications. We cannot accept, for example, 99.5% uptime SLAs (or, said another way, 4:22:58.5 — that’s 4+ hours — of downtime annually) in our business. People die when these systems go offline. Performance SLAs are very important, too, on account of physician productivity and happiness (remember, happy physician = better patient care = better patient outcomes).
  • Part of this will be in the data-to-application-to-user interactivity and the nature, or modality, of the data (think imaging, etc. – and read more about this here).
  • Some of this depends on the continued dependency of fully digitized hospitals to be able to print tons of data – labels, orders, charts, etc. – and the network bandwidth optimization to keep the piggish spooling output close to the printers (ergo, on-premise) rather than over the WAN or Internet.
  • And, lastly, the economics of deploying a private network (think MetroE Layer3 dedicated long-haul circuits, with the myriad of interconnectivity needed across LECs, etc.) may not be sustainable for each organization. The bandwidth and latency profiles of most Healthcare applications are such that general-purpose internet backbone or public/shared MPLS clouds often just don’t cut it.

However, I do believe that there is a place for some healthcare data to reside in a special-purpose “healthcare cloud” (note, not “the cloud”). I point you back to some of the drivers above as to why I think we’ll end up with more than one of these purpose-built clouds for healthcare. Here are the kinds of things that I feel would end up residing in these sorts of healthcare clouds:

  • Data that’s archived for compliance reasons. This is a no-brainer. We love to hoard data in healthcare. Love to.
  • Older data – some of which can be big, unstructured data – that’s not likely to be referenced on a regular basis. This tends more towards the “caching” technique employed by several PACS and VNA vendors today, whereby data that’s active and likely to be accessed frequently will remain on-premise in a converged infrastructure deployment, but the other, older data will get pushed out to a healthcare cloud.
  • Latency-insensitive data – an example of this would be real-time or near-real-time telemetry data off of connected devices, which is analyzed for trends and patterns from a cognitive analytics standpoint (see work that’s being done by folks like Clearsense). The true value of this data is when it’s hot off the press – that’s when the cognitive analytics and trends are generated, used for alerting, etc. The utility of this data after the fact is still high – trend analysis implies that you’re able to go back and forth from a timeline perspective – but a majority of this data, or all of it, really, can reside in a healthcare cloud.
  • Things like Healthcare Content Management – read about it here: Musings from Chicago: RSNA 2016.
  • Backups and Disaster Recovery — this doesn’t make any sense to keep on-premise, so let’s shove it out to a healthcare cloud.
  • Bursting — now we’re getting into the sexy parts of cloud computing. Most, if not all, healthcare applications exhibit what I call a two-hump camel graph for active concurrent users over the course of the day — there are typically two ~1-hour periods during the day where peak concurrency is achieved (people logging in for the day, or logging out at the end of the day — each of which is the top of the two camel humps in the graph), and then there’s a steady-state for most of the day in between these two humps. Statistics show that the steady-state can be anywhere from 25% to 50% lower than the peak. Finally, there are the valleys at each end of the humps — for true outpatient (ambulatory-only) facilities, the valleys are near zero, but for inpatient sites, these valleys are typically around 50% – 75% lower than the peak. So, let’s think about this — today, we’re seeing healthcare organizations deploy many hundreds of CPUs to handle peak concurrent utilization which occurs for around 2 hours in a 24 hour period. The rest of the time, conservatively, they need somewhere between 25% – 50% less infrastructure to sustain ongoing operations. It’s time that we leverage the cloud to take advantage of one of the main pillars, which would be elasticity. Let’s burst the excess need out to the healthcare cloud. Let’s stop over-provisioning all of our infrastructure for the 2-hour peak.

Before my summary, I do want to give credit where credit is due, and to acknowledge all of the healthcare application providers who’ve already begun (and in some cases, Cerner, CloudWave, etc., for example, who’ve been at the cloud thing for a while) to embrace and build out Healthcare-Application-as-a-Service offerings. For example, here are some top-of-mind examples of superb healthcare cloud execution, albeit several others who aren’t represented here:  

logos for cloud post

In the end, I’ll leave you with one somewhat controversial thought. I think Ben’s 100% right on the money when he says:

“I fully recognize that the enterprise application market has a very long tail. There are still many companies out there benefiting from the IBM mainframe based market. Many others will continue to flourish for the next decade or two (at least) on the on-prem infrastructure hardware and software market. But its days are numbered and we all need to step up and rethink our Enterprise applications in the process. We might as well start with a platform (the cloud) that is twenty years newer and fresher in terms of architecture. As opposed to continuing to spend 80-90% of our budgets on perpetuating the legacy enterprise stacks that were designed and implemented in the eighties and nineties. Here’s the rub, though: To do so will require really sitting down and understanding the top requirements. As opposed to assuming that 100% backwards compatibility trumps all others.”

I think the time’s right for us in healthcare to band together and look at the new, fresh deployment architectures which I’ve outlined above — some of which will end up on-premise, and the rest in healthcare clouds. As Ben says, we need to step up and rethink our Enterprise (healthcare) applications in the process. We need a step-change breakthrough platform for healthcare.

Bravo, Ben!