Tag: Privacy Rule

It’ll Never Happen To Me…

Posted on | by SOS Blog | 2 Comments on 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.

The Devil and Database Encryption

Posted on | by SOS Blog | Leave a Comment on The Devil and Database Encryption

Most every week I have a call from my credit card company’s security department to see if the recent activity on our account is actually ours. We used to get these calls maybe a couple of times a year, but now it is literally weekly.

A while back our credit card processor for SOS transactions notified us of new, stricter, security measures that we must follow or face the possibility of very substantial penalties. As a result, our customer credit card transactions now live in an encrypted database on a standalone computer that is not connected to our network or the Internet, and authorizes charges through a quaint dial-up modem connection directly to the processor’s system.

Arguably, financial data is a more tempting target for bad guys than most healthcare information, but there is little question that any data stored and moved around via electronic means is vulnerable. HIPAA requires that covered entities, and soon, business associates, take steps to determine the potential risk to the data that is in their systems, and to address the risk through a variety of security measures. These measures run the gamut from locked doors, user access passwords and workstation timeouts, through military-grade data encryption.

I have been thinking a good bit about the last of these: encryption. From CMS’s summary in HIPAA Security Series, Security Standards – Technical Safeguards (page 6-7):

4. ENCRYTION AND DECRYPTION (A) – § 164.312(a)(2)(iv)
Where this implementation specification is a reasonable and appropriate safeguard for a covered entity, the covered entity must:
“Implement a mechanism to encrypt and decrypt electronic protected health information.” (EPHI)

Encryption is a method of converting an original message of regular text into encoded text. The text is encrypted by means of an algorithm (i.e., type of procedure or formula). If information is encrypted, there would be a low probability that anyone other than the receiving party who has the key to the code or access to another confidential process would be able to decrypt (i.e., translate) the text and convert it into plain, comprehensible text.

There are many different encryption methods and technologies to protect  data from being accessed and viewed by unauthorized users.

  • Sample questions for covered entities to consider:
    Which EPHI should be encrypted and decrypted to prevent access by persons or software programs that have not been granted access rights?
  • What encryption and decryption mechanisms are reasonable and  appropriate to implement to prevent access to EPHI by persons or software programs that have not been granted access rights?

Generally, the safeguards you are expected to implement scale proportionately to the risk and the size of your organization. Thinking about the data stored in your billing and EMR systems, you would have to judge the risk to your data as very high if you have the database installed on a notebook computer that is routinely carried around by a staff member. Likewise, data moved across a network over a wi-fi connection would have to be considered as high risk. Even a solo practitioner or two person practice in either of these scenarios would probably be seen as negligent if the data were not protected by available encryption technology.

In the case of the notebook computer, I would think that whole-disk encryption should be in force, as there are likely to be letters, emails, and other sensitive data on the system that would not be protected if just your practice management/EMR database were encrypted.  Microsoft includes its BitLocker encryption system in Windows Server 2008 and the high-end versions of Windows Vista and Windows 7, but there also are many third party disk encryption products that one could use.

Wi-Fi protection means that you should use the best possible wi-fi encryption technology, at this moment, WPA2, coupled with a truly random password. Doing so would prevent virtually anyone “eavesdropping” on your wireless traffic from extracting meaningful information.

The correct path is not so obvious when it comes to encryption of primary databases, especially in the offices of small providers without dedicated IT personnel. Encryption is seeded by a string of characters, similar to a password or passphrase, called an encryption key. It is analogous to the key to your home or office, except that you can’t just break a window or call a locksmith if you lose the key. Good encryption is, for all practical purposes, impossible to crack. So, although the conscientious provider or practice owner’s first impulse probably would be to strongly encrypt, the risk analysis should include the risk of losing the encryption key, and therefore access to all the data stored in the database! The end result would be the same as a catastrophic hard drive failure with no backup — complete data loss and a very serious HIPAA violation.

Database encryption is only workable, therefore, in the presence of a formal, well-considered, bullet-proof procedure for encryption key management. Google that last phrase (“encryption key management”) and you will see that there are government documents several hundred pages in length that describe the procedures that must be followed to assure that  keys are both secure, and also readily available to those who need them.

To encrypt or not to encrypt? Devil or deep blue sea? What do you think? There are simple, keyless encryption schemes that are not terribly secure. Do you use something like that? Do you have a proven procedure for key management that you would be willing to share? You could lock your server in a bank rated vault, but then what if you forget the combination? We are back where we started! Anyone have any answers? Please click the title of this entry and leave us your comments.

HIPAA Privacy Rule: Communicating with Family and Friends

Posted on | by SOS Blog | 10 Comments on HIPAA Privacy Rule: Communicating with Family and Friends

New guidance about communicating with a patient’s family, friends or caretakers was released by the U.S. Department of Health and Human Services, Office of Civil Rights. This is the office entrusted with education about and enforcement of the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Privacy Rule. They have created two documents which lay out details about sharing information about a patient, one for providers of care and one for patients or consumers of care.

 

As I read these two documents, I found myself recalling my internship training in a Community Mental Health Center. We were clearly instructed that we were not even to acknowledge that a person was a client of the Center if someone telephoned about them. Family or friends accompanying them to their visit were not invited into the session unless the patient asked that they be included. Even minor adolescents and children were granted the privacy of the therapy session unless a clear agreement including parents or caretakers was reached. Obviously, the therapeutic relationship in the behavioral health field is a more sensitive matter than in many physical health settings. My experience is that mental health providers have always been more concerned and responsible about securing a patient/client/consumer’s privacy than anyone providing physical health care I have ever met.

 

In this electronic world in which we live, I have seen some of that care diminished; and we have begun to bump into this matter in technical support at SOS. HIPAA provides that a Covered Entity (a health care provider who electronically transmits certain transactions including electronic claims) must assure the security and privacy of their patient information. It also requires that Covered Entities educate people and organizations who provide services to them about the necessity of protecting the health information of their patients. In fact, it requires that Covered Entities maintain a Business Associate Agreement (BAA) with each person or organization with whom they do business who might in the course of doing business be exposed to the Protected Health Information (PHI) of their clients. If you have any doubt about whether you are, or are not, a Covered Entity, it would seem prudent to assume that you are and to execute a BAA with anyone to whom you reveal PHI.

 

When implementation of the Privacy Rule was first mandated in April 2003, we were asked to execute BAA’s by a very small proportion of our customers. During the five years since then, we have almost never been asked to sign such a document. Since service to our customers is a big part of who we are, we have made available a BAA that makes it very easy for a Covered Entity to assure that SOS is handling their data in an appropriate fashion if we ever have access to it (http://www.sosoft.com/fod/doc105-sosbaa.pdf ). Even given the ease of accomplishing this agreement, we still have difficulty getting provider organizations to do so.

 

What is your take on the HIPAA Privacy Rule and how it is implemented in your organization? Were you on top of this in 2003 and 2004 but not as likely to educate staff and your computer and software vendors in 2008? Do you see a difference between how psychology, psychiatry and other behavioral health organizations handle the Privacy Rule and how physical health providers do so? Has the rule kept you from filing your claims electronically so you would not become a Covered Entity?