Medical Data in the Internet “cloud” (part 1) – Data safety

The question of data security in a “brave new world” of cloud-based Electronic Health Records (EHRs), Personal Health Records, and iPhone and other smartphone apps that could transmit personal health information, has attracted the attention of many. Web-based services – so-called “cloud computing” – are not inherently secure. Such technology is focused more on widespread reach and interconnectedness rather than on making sure that the connections and the data are foolproof. Yet much of our personal information, such as banking information, is housed electronically and accessed through the web – we have become so accustomed to it that we seldom think very much about it. Personal health information, moreover, is protected by law: HIPAA, which is focused around physician and hospital-centered recordkeeping, and now ARRA, which extends HIPAA-like protection to patient-centered Personal Health Records as well.

In a previous blog post, we reviewed (at a high level) the ways in which special attention to security and privacy can create what is needed to house personal health information in a hosted, “cloud”-based setting. In this series of posts, we will dig a little deeper into these questions. This first part addresses the issues of data safety, and protection against loss and “down-time.” The second part will address the question of security between connections (making sure “the pipes don’t leak”). The third part will focus on privacy and ensuring that only the right people can access the right data.


DATA SAFETY

Medical records – a physician’s charts – are critical and central in a physician practice. It is both a medico-legal record that documents the advice given by the physician to the patient, and is also the core work-flow tool that allows the physician to function. These records must be available on-demand, at all times. Given that only 13% of physicians have any kind of electronic recordkeeping, the majority of medical data is housed in paper charts.

With paper charts, what kind of safety is there? Charts are usually housed in chart racks, and also pile up in various locations around the office (e.g. the physician desk). There is little or no backup of these records in case of some mishap – individual charts can be lost, or some disaster (e.g. fire, water damage, weather events and the like) can wipe out such charts wholesale. When this happens, there is little a physician can do other than start over, and piece together previous data where possible, as if everyone was a “new patient” again.

Migration to EHRs has resulted in an improvement in medical record availability and back-up, when compared to paper. Historically, most EHRs have been locally installed, as client/server systems. There is often a data-backup plan, so that the locally-housed database is backed up somewhere – on tape, disk, or secure offsite backup hosting service. When backed up locally (onto tapes or disks), these backups should be housed off-site (in the event of fire) – in reality, however, adherence to such a plan is hit-and-miss (though still better than with paper).

In a client/server EHR scenario, the bigger question is how to avoid server down-time. As stated, medical record access is a critical core business function for a physician practice (and also for a hospital). Hardware redundancy in the server has become routine – such as arrays of mirrored hard drives which avoid crashes if a hard drive fails. But again, given that these steps involve cost on the server-end, such precautions are hit-and-miss across the landscape. Further, what happens when there is a power outage? Is there battery backup of the server, and at least one workstation in the office? Good safety planning would recommend that these steps be done.

Other local issues have to do with viral infestations and system lock-ups or crashes in the local server. Good IT support is needed when such calamities occur, and often are done via outside vendors, as many smaller practices are not able to hire their own IT support staff. The result can be that down-time of the server can last for hours, even days.

Moving the server-end of EHRs off-site, and onto the Internet “cloud,” reduces these kinds of risks significantly, compared to locally-installed client/server systems. When data and server hosting is taken on by a vendor (such as Practice Fusion), commercial enterprise-level server farms can be used. Biometric security within hosting facilities, multi-geography co-location, and mirrored servers with automatic fail-over in case of server crashes, are all technologies that can be leveraged and offered to all users, even the smallest practices – and would be beyond the reach of what smaller practices could afford were they to do it themselves. Down times are rare, and at worst, are short-lived.

The recent reports of “denial of service” attacks on high-visibility web sites is not so much a “hacking” attack that attempts to penetrate a database and steal information – it is an intentionally simultaneous flooding of a web site in order to cause it to freeze up. Vulnerability of hosted EHR systems to these kinds of attacks has been raised by some observers, and should therefore be mentioned in this “data safety” segment (rather than the “data security” segment, next). There are a number of steps vendors can take to protect against such events, and creation of internal security protocols about this type of attack (done vendor-by-vendor) minimizes the risk to physician end-users.

Of course, the more centralized the data becomes, the bigger the target it becomes (“why do you rob banks? – because that’s where the money is!”). Creating good “locks” to secure the data becomes a focus of “cloud”-based vendors. Data security – making sure that data exchange across the Internet is safe, and that data storage is sufficiently fragmented and encrypted to minimize the risk of hacking – is the focus of HIPAA and ARRA regulation, and is the focus of the next installment in this series.


Robert Rowley, MD – Chief Medical Officer, Practice Fusion Inc.