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 | Assessment 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.

One thought on “Data Security, Backup, and the HITECH Law

  • The one aspect of data security that I had not considered until recently was maintaining a permanent copy on DVD of all my backups. In particular I learned from Seth that keeping copies of all log files before SOS program updates is a major piece to being totally protected and prepared for any sort of audit or data disaster. Fortunately I was able to find and save all my log files going back six years or so. On the data protection side, several times a week I restore my SOS data file back-up to a computer at home and check the integrity of the files by opening up another copy of my SOS programs for which I have an additional license. On several occasions over the years, doing this off-site restore, I have found that for whatever reason some “gremlin” caused a problem with the back-up requiring a fix. As Kathy pointed out it is ESSENTIAL to regularly check the integrity of the backup you have made by restoring the data and running the program to be sure all the “bits and pieces” are where they should be.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This site uses Akismet to reduce spam. Learn how your comment data is processed.