Will Your Organization Weather a Storm…or Other Catastrophe?

Superstorm Sandy has had major impact on the lives of large numbers of our fellow Americans and colleagues who live in the Northeast U.S. The loss of life, property, and access to conveniences like electricity, warm showers, and transportation has made clear how vulnerable we are to the impacts of catastrophic events.

Sandy has also given us the unfortunate opportunity to evaluate the policies and procedures we have in place for dealing with physical catastrophes.

The Health Insurance Portability and Accountability Act (HIPAA) requires that organizations have in place a Contingency Plan (STANDARD § 164.308(a)(7) Contingency Plan, see page 19):

The Contingency Plan standard requires that covered entities:

“Establish (and implement as needed) policies and procedures for
responding to an emergency or other occurrence (for example, fire,
vandalism, system failure, and natural disaster) that damages systems that
contain electronic protected health information.”

This requirement is not aimed at giving you one more thing to do. The purpose is to protect the health information of your patients and to make sure that they have access to continuing care. Hurricane Andrew in 1992 and Hurricane Katrina in 2005 demonstrated how poorly prepared we have been to maintain continuity of care for our patients. The requirements of HIPAA are designed to prevent such huge failures as happened previously.

FiercePracticeManagement newsletter suggests three key steps.

  1. Know how your remote data is stored and can be accessed. This assumes that you have your data stored offsite, as it should be. Knowing just where it is and how to access it so you can get your system back up and running without delay is crucial. 
  2. Duplicate needed paper and have it with you. Make sure you have a copy of your schedule with you. Assure that you have with you ways to contact your patients so you can let them know your alternative arrangements for meeting with them.
  3. Plan where you will relocate physical data. Know where that alternative location will be so you can get access to your data again quickly.

 

In HealthCare IT News, Benjamin Harris covers some of the same ground. He also suggests three basic processes, but starts at a more basic level.

  1. On-site safety. How is your hardware and software and record systems protected at your site? Is your server located in the building basement along with the generator? As demonstrated by Sandy, the basement is not the best location for such equipment or records in the case of flooding . . . something that had previously been an issue in hurricanes Andrew and Katrina.
  2. Off-site data. If you are relying on a remote (cloud) storage facility or you need to access your data by means of the Internet, what do you do if your ISP (internet service provider) is down? And if your EHR is an online product, what do you do if those remote computers are underwater and without electricity? Having your schedules for the next week and treatment summaries for each of those patients printed out gives you a week of buffer time to give your vendors a chance to get back up and running.
  3. Accessibility. If you are using such remote storage or providers and they are not in the affected area or can implement access to backups quickly, having the capability of connecting to them becomes your responsibility. You can tether your laptop to your cell phone to reach your service or data in an emergency, as long as you have prepared in advance.

 

Madeline Hyden of the Medical Group Management Association (MGMA) suggests a slightly different but very practical list of steps.

  1. Secure your electronic information.
  2. Get the support of your professional colleagues.
  3. Immediately start securing new office space.
  4. Establish authority: Make sure someone in your organization is responsible to and has the authority to activate your contingency plan.
  5. Communicate with your vendors (hardware, software, backup services, electrical company, landlord, billing service, answering service).
  6. Develop a notification protocol: decide who to contact and how and who does the contacting. Determine just what they will be told.
  7. Communicate honestly with your patients.
  8. Protect your records so you are sure you can have access even if your main system is not accessible.
  9. Practice your emergency plan. If you have not done so, it is possible you will be too traumatized to carry it out.

If you are not sure how to go about establishing a contingency plan, AHIMA has some suggestions for you. This does not need to be a complicated process, but it is a process you need to address if you have not already done so. After all, the U.S. northeast coast did not think they were susceptible to a hurricane-like storm that could cause such disruption.

Whether it is hurricanes, snowstorms, tornadoes, earthquakes, or fires, our electrical systems and business facilities are not impervious to disasters. We must be prepared so our patients can rely upon continued care.  Behavioral health clients are especially susceptible to negative consequences from disruptive events. After all, they are likely to have just experienced the same trauma you did.

We hope all our SOS customers and their patients are safe and recovering in the aftermath of Sandy. We hope any of you, our readers will share your experiences and how you have assured the security of your data.

 

Security and Backup: Yes…backup, again!

Once a month, on average, our technical support specialists are confronted with a customer whose database has become corrupted because of some hardware issue and who has no usable backup. After last week’s adventure, I decided I would again write about backup. Then, last night, I saw a discussion on a Psychology and Technology listserv that included some of our customers talking about full disk encryption of a Mac laptop. Encryption is something we recommend for every customer who uses our software or maintains any Protected Health Information (PHI) on a computer…especially on a laptop. To round out the clues that security and backup should be my topics of choice this week, I noticed an article in eweek of March 21, 2011 entitled ‘Remote access presents complexity, security issues.’

The rate at which users want to be able to access their work applications remotely has grown geometrically. Fifteen years ago, we were asked about remote access a couple of times a year. Five years ago, that increased to a couple of times a month as many more users wanted to be able to access their software from home. Now, everyone who carries a laptop, or even a smart phone, wants to be able to do everything they need to do for their jobs from wherever they are located with whatever device they have handy.

Whew! If only they realized what an expectation that is! And, all of these expectations complicate the issue of security in ways that those of us who are not very technically savvy cannot imagine. But imagine we must…if we plan to protect PHI, that is.

First, the issue of backup. This is the primary way in which you protect the security and integrity of client information. If you do not have a usable backup from which you could restore PHI in the event of a catastrophe, you are only one step away from having allowed the destruction of your client’s PHI.

Yes, the identifying demographics together with the diagnosis you use to file claims is PHI and is protected under HIPAA. Everything you have in an EMR is PHI. Yes, you are responsible to assure that this information is intact, safe from destruction, and secure from preying eyes (and hacks). Without a usable backup (preferably encrypted) stored in a secure location ready at a moment’s notice to replace data on your computer system, you are not even doing the most basic things necessary to provide protection to your patients. You could probably be demonstrated to be guilty of ‘willful neglect,’ the level of culpability that will generate the highest of fines from HHS and OCR under their HIPAA authority.

If you are not sure of what kind of backup strategy is minimally adequate, take a look at the backup recommendations and product suggestions we make to our customers.

The issue of remote access, especially from handheld devices like smart phones and iPads, is one that concerns me considerably. HIPAA requires that we must provide for the security of PHI while it is at rest (on a computer drive or CD or smart phone) and while it is in motion (being transmitted from one location or device to another).

Access tunnels like a secure VPN or MS Terminal Services are specifically designed to assure the safety and security of the data being transmitted through those tunnels. Those of us who are not very technically sophisticated may assume that the developers of the iPad and smart phones have already taken care of equivalent security for us. Not so, folks. While there are some products that will provide that security, they are not built into those hand held devices and we are on our own to find them.

Do you realize what that means? Do you understand that using your cell phone to access your desktop computer and patient information without adding specific protection assures that your data are vulnerable? There is not built-in security in your telephone or tablet. Even having your client names and phone numbers in your telephone contact list is potentially a breach of their privacy.

No one has volunteered to create a secure environment for your data…that is your job. You must do the research and determine which products will give your PHI the greatest protection.

Not being informed about a problem of insecurity is not considered an excuse by HIPAA. You must know what security your devices use to assure the safety of PHI. Do you have password protection on your phone? Do you have a way of wiping all data from the phone if you lose it or it is stolen? Have you initiated the services that are available to accomplish those purposes?

I know, this has started to sound like a rant. I do not mean to suggest that everyone is acting irresponsibly with client PHI. I do mean to suggest that we take a much too casual attitude toward protection of that PHI…especially when it comes to technologies about which we know little but assume much.

What policies does your organization have in place about use of portable devices and the protection of PHI? Have you found products that are wonderful to accomplish that protection? Will you share their names and your experiences with the rest of us?

Please enter your comments below.

It’ll Never Happen To Me…

This week one of our customers experienced a “happy ending” to a very unhappy story. We thought we would share it with you.

They were sure they had a good backup. When their server hard drive crashed, they were distressed but not terrified. Instead of dealing with the loss of all their data, it merely meant that they would need to get a new server and have someone spend time rebuilding the hard drive from installation CDs and all of the backed up data.

That’s when reality set in. Their consultant technician installed our software onto their new server from a CD and went to restore the data. The data folder was empty. He was unable to recreate his client’s practice management data from a usable backup. That is also when the customer’s panic started.

I don’t know if you have ever considered this scenario for your organization. After all, your IT specialist set up a tape or external drive backup for you and the system automatically backs up every day. Sometimes there is a strange error message on the monitor when you remove the tape or you get an email that says an error has occurred, but you don’t really have time to pursue it.

Have you ever tried restoring from one of your recent backups? Do you know that the data are usable? If someone in your organization has never restored one of your current backups to your system and made sure the restored data worked, then your backup process is incomplete and you are at risk for the same kind of upset our customer experienced this week.

Happy ending to this story. . . a hard drive retrieval company was able to pull data off the crashed drive. . . at a cost of $7500! Since that certainly played havoc with the budget, this happy ending is really a mixed one.

If you want reminders about backup procedures and our best thinking about what to consider take a look here and here and here and here. We have not written about this as recently as I thought, but data backup is a subject that we try to remind ourselves and our customers about regularly. Please think about and take action about yours.

Also from the ‘It’ll Never Happen To Me’ department. . . I attended a webinar on the HIPAA and HITECH breach notification requirements a couple of weeks ago. This was done by a company named IDExperts that specializes in guiding companies through the risk assessment process after a breach has occurred. They also have a software product that will walk you through the post-breach risk assessment and track the histories of all breaches. Their take on data security and the risks involved are like this: if you were interested enough to attend the webinar, the question is not if you will experience a data breach, but when. Statements like that always jar me. Since we are not a Covered Entity and have no PHI of our own, I am not too concerned about us experiencing a breach; our procedures are solid and any electronic PHI temporarily in our possession only resides on encrypted computers. Obviously the worry is not small for health care providers, especially large ones.

The concern about security and privacy of PHI has recently been complicated by the fact that HHS has decided to reconsider the final rule on breach notification. After privacy and security groups were distressed and complained to HHS about the methods for deciding whether the release of data presents a risk to involved patients, HHS decided to reconsider the final rule. There is speculation that the rule will be made tougher than it was. Up to this time, the organization that experienced the breach has been responsible for determining the severity of the risk to patients caused by the data loss and whether HHS needed to be notified off the breach. HHS did not indicate when a new rule could be expected.

Who in your organization is responsible for verifying that your backups are usable? When was the last time a test restore of crucial data was done? Would you have any idea how to do this; if not, who does? What is your plan of action if protected health information is accidentally released when it should not have been? Are you convinced it’ll never happen to you?

Please share your comments and your experience so all our readers can benefit from best practices on data backup and protection.

Data Security, Backup, and the HITECH Law

A question on one of the psychology listservs I follow got me thinking, yet again, about data security…and backup. The writer asked about the proper procedures to follow when patient psychotherapy treatment records are permanently lost. The question pertained to how the counselor in question should respond to the loss of all of their patient data from a mental health clinical record software program. Since we provide one such program, my attention was immediately attracted.

The other listserv members addressed three issues: recovery of the data from the hard drive, backup of the data, and re-creation of the records from scratch. Because of our experience with customers losing data due to computer failure, I focused yet again on data backup and database recovery. Added to my thoughts this time are the HIPAA requirements for securing protected health information (PHI) and the increased penalties in the HITECH portion of the stimulus bill (ARRA) for breach of privacy and security of PHI.

It is likely that you all remember that HIPAA requires healthcare providers (including psychiatrists, psychologists, social workers, mental health counselors, and community behavioral health organizations) to have in place procedures for securing the PHI of their patients. Most mental health workers with whom I am familiar focus on the privacy aspect of this protection; they see it as their responsibility to assure that the consumer’s information remains private. HIPAA also mandates that providers and their organizations have in place plans to protect the security of their physical data.

The National Institute of Standards and Technology (NIST) has produced Special Publication 800-66-Revision 1, “An Introductory Resource Guide for Implementing the HIPAA Security Rule.” A quick search of this document finds that the words “loss of data” are mentioned on pages 38, 77 and 98. The first mention is in a table describing the necessary contents of the Contingency Plan for data security, including a Data Backup Plan. The sections of this document that focus on the Contingency Plan and the Disaster Recovery Plan are the ones most concerned with electronic data storage.

If your organization, including your private practice of psychology or psychiatry, does not have a Contingency Plan and a Disaster Recovery Plan, however brief, you are living dangerously. And, of course, you must implement your plan to secure your PHI, not just have a plan.

How does this pertain to you? Let’s start with your data backup plan. What is it? Who in your organization is responsible to implement it? What are the consequences if it is not implemented?

One of our customers,   W. E. (Bill) Benet, Ph.D., Psy.D., Clinical Psychologist, Gainesville, FL  WEBenet.com | Assessment Psychology.com describes his experience and current backup strategy.

“I mentioned Eco Data Recovery in my previous note because I had to use their service a number of years ago after the hard drive on my main office PC mechanically failed and became inaccessible while backing up to a tape drive, corrupting the data on the tape. Fortunately, Eco was able to recover all of the data from the hard drive, by disassembling it in a ‘clean room’ and scanning the data off the individual platters. Luckily, the data on the hard drive hadn’t been corrupted, but it very easily could have been, and I would have lost years of billing records and reports.”

“But what about data that has become insidiously corrupted without being immediately obvious?”

“Today, I employ a simulated RAID backup strategy involving nightly network backups to two external USB drives, as well as from one PC to the other, AND continuous 24/7 incremental offsite backups, using Carbonite. Hopefully, if corrupted files are discovered days or weeks later, those incremental backups will save the day, at least for a while.”

Here at SOS Software, we all too often run into an organization where the principals thought they had an excellent data security plan, only to find out that their plan had not been effective or had not been implemented by the person(s) who were responsible to do so.

One of the obstacles we run into is the common belief that “it can’t happen to us.” We all know this is magical thinking; of course, it can and does.

Another often-believed myth is “I don’t really need to worry about data on my PC; data can always be recovered from a hard drive if there is a problem.” While this belief is sometimes true, it often is not. If the files lost when a computer crashes are in a complex, proprietary relational database, they sometimes are totally irretrievable. They are not text files where parts can be grabbed and some sense made of the data.

Our product uses Sybase ASA as its engine because that database creates a transaction log that can allow us to completely recreate every keystroke the user made…if the log file is intact. In fact, we use Sybase because of this capability to completely recreate the database if it is necessary to do so. As long as we have a usable starting point, we can restore the entire database from the log file…if we have an intact log file.

Two problems can intervene. 1. With our products as with many others, if the backup is done while the database is running, certain of the files are not backed up because they cannot be accessed completely. Some backup software products will tell you they can back up even when the program is running. That is not true with SOS products. 2. Hard drives often fail gradually becoming literally “flaky” over time. If key sectors of the log file are lost, it is impossible to recreate the database from the log, even if there has been no overwriting of the database.

Also, sadly, even folks who believe they responsibly make backups, never test those backups to assure they can be restored properly, and they often use the same backup medium overwriting old backups. If the hard drive has been gradually failing, destroying parts of the files as it goes, then backups of those bad files become bad too…all of this over time with no noticeable degradation of performance of the database.

Then the catastrophe occurs…a power surge or some other event causes a crash of the hard drive and the database will not restart when the computer is rebooted!

As indicated by comments on my post of November 19, 2008, The Indispensable Data Backup, among my readers are many folks who are sophisticated computer users who are responsible enough to use multiple methods of backing up their patient data. Using a rotating system of backing up with permanent, non-incremental backups created periodically and stored off-site, is crucial. The strategy we recommend is in document 125 on our main web site.

If you have never tried restoring from one of your backups, you have not completed the process. Unverified backups are useless backups. Useless backups equal insecure PHI. How big a risk taker are you?

Please add your comments by clicking on the title of this article and typing in the box at the bottom of the page.

The Indispensible Data Backup

We were recently told by the IT person for an organization that had six weeks earlier lost all their data, that backing up was not a priority. Yes, they were having the same problem again. No, they did not have a good backup. They had needed to get up and running again and that took priority over getting a backup system in place. We were flabbergasted. They had just paid us to recover their database because they did not have a backup from which they could restore…yet backing up was not a priority.

On a regular basis, we are confronted by a customer organization that has a catastrophic event resulting in the loss of their entire SOS database including all of their practice management information…patient billing, clinical records, schedules. Some of the events have been a hurricane, a fire, or a crash of the computer causing irreversible corruption of the data. In the case where the customer has regularly been following our recommendations for data backup including verification and off-site storage, they merely retrieve their most recent backup, restore it to their computer in the appropriate folder, and pick up their work where they left off.

In all too many instances, that is not what happens. In some cases, the customer has not been creating backups of their data at all! In many others, they have been writing over the same single copy of their backup over and over again. If their hard drive fails in a progressive manner becoming flakier as it goes, their database becomes corrupted in the same gradual manner and their lone backup becomes as unusable as their corrupted database. Sometimes, they make their backup onto a partition of the drive on which their production database resides. When the main one goes, so does the backup. And quite often, they make backups regularly, one tape for each day, but they never verify that the backup can be restored. 

We have created documents, newsletter articles, email rants and verbal tirades trying to communicate the absolute necessity of having excellent backup procedures that are followed without fail and that produce reliable, verifiable backups of all necessary data. This information is certainly effectively used by many of our customers, but we do not seem to be successful at reaching others.

We need help understanding how folks think about data backup so we can more effectively assure that it occurs. How does an organization justify not making and verifying a backup of their mission critical data? What are the “reasons” that get used? If your company does not do data backup, what are the obstacles to doing so and how do you rationalize not removing the roadblocks? What can we and other software companies do to assure that backup happens? What have you done to assure that data backup works effectively in your organization? If you “got religion” about backup at some point, what triggered the change?

Talk to us, please. We need your assistance here.

Thanks!