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.

0 thoughts on “It’ll Never Happen To Me…

  • We have tested data restores a number of times and it has worked well. For the test, I redirect the restore of c:\SOS\DATA to another test (virtual) server which has the SOS client already installed and configured to open the local database. The restore just overwrites the stand-alone database. Then I start up the db engine manually on the test server and watch the messages for warnings or errors. I use this process on a quarterly basis to refresh the test server with more recent data since we use it for testing custom reports and other development work.

    • Thanks for stating the steps you follow, Mike. I think one of the things that gets in the way for some people is not having a procedure outlined in advance. Take the following text paragraph from our document on backing up, and make itemized steps out of it:

      Have a disaster recovery drill on a regular basis.
      1. Start by renaming your \SOS\DATA folder to something else, such as DATASAVE.
      2. Now try to restore your backup, following the appropriate restore procedure for your backup software.
      3. When the restore is complete, open OMWin [or CM] to be sure the database is intact and contains all the data that you believe it should.
      4. If you cannot open the database, something is wrong with your backup procedure and you must correct it. If the program starts fine and you can access all your data, you know your backup procedure is working.
      5. You can now delete the DATA folder, including the files you just restored, and rename DATASAVE back to DATA.

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.