Medical Billing Blog

Preventing EHR Sabotage

Posted by Barry Shatzman on Wed, Aug, 22, 2012 @ 13:08 PM

How to Protect PHI in EMRsFor most practices, the process of adopting and implementing an Electronic Health Record System is daunting enough.  It can take as long as a year to fully integrate the EHR into the daily procedures of the practice, and most practices find themselves on a whirlwind roller coaster ride when it comes to devising and fine-tuning new routines to make using the EHR as effectively as possible.  In the long run, switching to electronic records is worth it in terms of time saved, errors reduced, and being able to offer the additional soft services available from those who use an electronic record system. 

When you finally do choose a program and go through the training and implementation process, there are still more safeguards to be considered.  While it may seem that the specifications and requirements set forth in HITECH and the HIPAA Security Final Rule are cumbersome, and possibly overreaching, a recent “breach” suffered by a small surgical practice in a Chicago suburb may illustrate the very sensible reasoning behind some provisions included in the final rule. 

In a recently reported case, a hacker attacked a surgical practice inLibertyville,Illinois, a suburb ofChicago.  The hacker was able to bypass security, accessing the practice’s EHR.  In this bizarre case the hackers didn’t secretly copy files but rather made their presence known by encrypting the entire server and posting a ransom note demanding payment for the new password to access their own information.  The surgeons turned off the server and called the authorities, refusing to pay any ransom. 

This brings me to my point.  When faced with a situation similar to what happened in Libertyville, one of two things will happen once the breach is discovered:  Either the practice has a backup copy held on another server and can practice medicine as usual by switching to the backup while the hijacked server is rebuilt, or the practice doesn’t have a backup server, and is forced to cease operations.  If there is no backup server, the practice can’t access patient history or the scheduling program; they won’t know who is scheduled for surgery, when, or for what reason.  Obviously this scenario could be catastrophic to any practice.  My point is that this type of business interruption is easily prevented by proper implementation and utilization of a remote backup server. 

The guidelines for Data Backup and Disaster Recovery are not new.  They have been public since February, 2003, and compliance has been mandatory since April 2005.  Nonetheless, most covered entities remain noncompliant, as explained by Bob Chaput, in his article, “The Truth about HIPAA-HITECH and Data Backup,” in the March/April issue of HBMA Billing Magazine.  Here is a brief recap of the guidelines as summarized by Mr. Chaput in his very enlightening article: 

  1. It's not optional – All CEs, including medical practices and BAs, must securely back up "retrievable exact copies of electronic protected health information" (CFR 164.308(7) (ii) (A)).
  2. Your data must be recoverable – You must be able to fully "restore any loss of data" (CFR 164.308(7) (ii) (B)).
  3. You must get your data offsite – as required by the HIPAA Security Final Rule (CFR 164.308(a) (1)).  How could one defend a data backup and disaster recovery plan that stored backup copies of ePHI in the same location as the original data store?
  4. You must back up your data frequently – as required by the HIPAA Security Final Rule (CFR 164.308(a) (1)). In today's real-time transactional world, a server crash, database corruption, or erasure of data by a disgruntled employee at 4:40 PM would result in a significant data loss event if one had to recover from yesterday's data backup.
  5. Safeguards must continue in recovery mode – The same set of security requirements that applies under normal business operations must also apply during emergency mode. CEs and BAs cannot let their guard down (CFR 164.308(7) (ii) (C)).
  6. Encrypt or Destroy – HITECH says to encrypt or destroy data at rest to secure it (Section 13402(h) of Title XIII HITECH Act). HIPAA Security Rule says that data being transmitted must be encrypted (CFR 164.312(e) (1) (B)). Many CEs and BAs fail in this area because tape- or disk-based backups are moved around freely, unencrypted.
  7. You must have written procedures related to your data backup and recovery plan – Policies and procedures (CFR 164.312(b)(1)) and documentation (CFR 164.312(b)(2)(i)) are a huge part of the HIPAA Security Final Rule.
  8. You must test your recovery – Backup is useless if your recovery fails, therefore the law requires that you "Implement procedures for periodic testing and revision of contingency plans." (CFR 164.308(7) (ii) (D)). Unfortunately, testing tape-based or disk-based recovery can be time-consuming, so most companies rarely do it.
  9. Non-compliance penalties are severe – Penalties are increased significantly in the new tiered Civil Monetary Penalty (CMP) System with a maximum penalty of $1.5 million for all violations of an identical provision.
  10. Now is the time to act – CEs have been subject to the HIPAA Security Final Rule since April 2005.  BAs were statutorily obligated to comply by February 2010.

Most small to medium practices focus on providing medical care, and have limited skills, knowledge, and experience when it comes to Information Technology (IT) in general, and information security matters in particular.  Covered Entities (CEs) are unaware these guidelines exist, even though they’re required.  Information security is about ensuring confidentiality, integrity, and availability of data.  In a nutshell, data backups are about securing Protected Health Information (PHI).  Every practice needs a secure IT system and a computer vendor responsible for it.  IT system backups are as important as the EHR itself and many EHR vendors will offer this service for an additional cost.  Losing data is one matter; not having "exact retrievable copies" as required by law is another.  As Mr. Chaput put it: “The ultimate embarrassment may be, however, trying to explain in a court of law following a data breach event that one has no way to notify affected individuals because one has no idea who they are…because there is no data backup copy.”