At this year’s HIMSS conference, there was a growing buzz about “Collaborative Care”.  And much of today’s frenzied rush to automate healthcare via Electronic Health Records (EHR) and Health Information Exchanges (HIE) is in reality to put Joe Consumer on the doorstep of Collaborative Care.  It’s not possible in fact to achieve collaborative care without  a comprehensive deployment of EHR, along with transparent and federated but secure access and exchange of health information among those needing it.

So what is this collaborative care thing, what does it mean to me, and why does Stratus care?

Collaborative care is a shift towards focusing on the whole consumer and providing levels of care which are appropriate, accurate, and cost effective.  The concept involves the consumer interacting with a network of doctors, hospitals and specialists where health information is integrated and analyzed to direct which services are appropriate to that consumer and who provides them.  The consumer plays an important role too – collaborative care is proactive, involving the consumer in health maintenance such as reminders to check sugar levels for a diabetic or monitor weight.  The consumer can interact with their health profile and provide input as necessary.  In many cases, consumers will receive care in the form of recommendations or scheduling a visit well before the possibility of a health condition.

Consumers care – cost efficiency aside, this approach reduces errors, increases the chance to prevent or capture a health situation before it becomes more serious, and increases the probability the right level of care and practitioner is on the scene when a health situation arises.

Why Stratus then?  Simple.  None of this is possible if the systems in this chain experience downtime.  If the EHR fails  the chance is high there’s information lost or being written down which can create errors or delays.  If the HIE isn’t working, there’s no information being exchanged with practitioners at the point of care.  It can be a black hole if the HIE system is down.  Think about the risk of inaccurate or incomplete information, or data not being available, and yet attempting to offer collaborative care?  It just doesn’t fly.

Stratus solves these problems with uptime assurance solutions that reduce system downtime and increase patient care effectively and efficiently.  And we’re seeing more investments in EHR and HIE including high availability requirements as ambulatory and in patient deployments realize just how important system uptime is to the overall success of their deployments and the overarching goals of healthcare reform.

What causes computer systems to go down?  Is it mostly hardware failures, software crashes, or other factors like user error or environmental problems?  Lots of studies have been conducted over the years, but many of them suffer from small sample sizes, both in systems and in runtime.  Researchers at Carnegie Mellon University wanted to really dig into the problem and have analyzed a set of system failure data spanning nine years (although most of the data seems to be between 2001 and 2005), almost 5,000 systems, over 100 million system hours of runtime, and a whopping 23,000 distinct failures from Los Alamos National Laboratories!  This analysis produced a paper by Bianca Schroeder and Garth A. Gibson entitled A Large-Scale Study of Failures in High-Performance Computing Systems (http://www.pdl.cmu.edu/PDL-FTP/stray/dsn06.pdf).  Best of all, every single failure, its date, its root cause (if known), and the amount of downtime it induced is publically available and downloadable on the Los Alamos website (http://institutes.lanl.gov/data/fdata/).

I recently downloaded the raw data, and it is quite impressive.  Their study included several different types of servers — everything from SMP 2-way and 4-way systems to NUMA systems containing as many as 256 processors per node.  But, what was really striking was the detail surrounding the failures.  Not only was the amount of node downtime resultant from the failures charted to the minute, but each failure’s root cause (if known) was recorded to the component level.  For example, hardware failures were isolated to the failing component (e.g. DIMM, CPU, PCI card, disk drive) and software failures to that piece of software that failed (e.g. kernel/OS, file system).

The following is a graph presented in their report (Schroeder and Gibson, pg. 3, Figure 1) on the data showing the breakdown of all failures across different system architectures (each letter, D through H, represents a unique system architecture):

A senior person at a Regional Extension Center (REC) summed up their primary goal with healthcare practices recently by saying “Make them amongst the willing”, in describing the fundamental push to get healthcare practitioners to select an EHR system.  In other words, keep the decision as simple as possible.    The saying that “Every journey begins with the first step” seems to hold true here.  And certainly, other factors can be addressed over time as the installation matures on the road towards meaningful use.

But a report just issued by Mark Anderson and the AC Group raises some important decisions that should be addressed when purchasing and deploying an EHR system. What is the cost to a healthcare practice when their EHR system is down?  What is the expected uptime of the system that will run the EHR software ?  This new report is based upon studies conducted with live EHR deployments, and analyzes the impact on productivity and costs when the system was not available.     

For example, ten hours of electronic healthcare record (EHR) system downtime in a year could cost the average 20-physician practice nearly $100,000, yet 87% of medical practices ignore vendor service level agreements and uptime requirements when purchasing EHR system software.   

AC Group suggests that EMR systems meet today’s requirements for high availability – less than one hour of unplanned downtime per year – which raises the table stakes for most decisions being made by healthcare practitioners.   It requires that the decision process also focus on the uptime for systems that will run the EHR application.  Healthcare practictioners should ask for a solution that’s architected to provide high availability – that’s understood to be 99.99% or greater system availability.  Traditional servers, even clustered servers, fall short of this mark, while Stratus meets or exceeds this benchmark for EHR system uptime.

The full report on “The Costs and Implications of EHR System Downtime on Physician Practices”, by Mark Anderson of AC Group, is available at http://go.stratus.com/ACgroup_Paper .

• How much Downtime is acceptable?

Customers need to evaluate how much downtime are they experiencing today and how much is acceptable to their business. Downtime occurs due to planned activities (e.g. hardware maintenance and software upgrades etc.) and unplanned activities (e.g. power failure). Customers should consider how much the proposed solution reduces the downtime or even eliminates key types of planned and unplanned downtime.  What is the payoff versus the payout?

• Is it simple?

SMB customers have very small IT departments -in some case it is just one person. Also, maintenance is mainly done by reseller. Customers must be able to easily understand how to install, maintain and use the proposed uptime solution. How much initial training is required? Does it require application customization for each application? Does it have remote management capabilities so that IT person doesn’t need to be on-site every time there is a fault?

• Is it affordable?

Considering the initial acquisition cost and long term cost (or total cost of ownership) is also important for comparison with the total cost of downtime within that time period. What all hardware and software is required for the uptime solution? For hardware, how many servers are required? Does it require an external storage? For software, does it require additional management software to manage on top of uptime software? Also should customers consider annual maintenance costs they are paying for the software and also to reseller? If the uptime solution has built-in features that reduces your other costs e.g. built-in virtualization, those features should factor into the equation.

I have been talking to a lot of SMB customers and partner and these are the top three things they consider prior to purchasing an uptime solution. Finding the cost of downtime can be tricky, and creating an equation for the cost of an uptime solution can be just as complicated. What are you doing for an uptime solution, and how did you come up with answers to these questions?