Software security issues and HIPAA
Posted by: Robert Markette
July 28, 2006

I read an interesting story about a security issue in e-prescribing.  It seems that a company that writes medical office suite software that includes an ?e-prescribing? component recently discovered a security flaw that allowed a computer consultant to access a file that contained a demographic information on a large number of patients from Georgetown University hospital.

In this case, the individual who discovered the problem was attempting to install the company?s software on a client?s computer.  When he could not get software updates to install, he ?poked around? in the software and discovered a web address, log in name, and password, in the software.  The consultant used this information to manually log onto the company?s file server to try to find the updates he needed.  When he could not quickly determine what he needed, he downloaded the entire contents of the directory (about 2 gigabytes of information).  As the consultant reviewed what he had found, he discovered the patient data.  Oops.

The consultant was able to access the server, because the software had security information ?hard coded? into the software.  (To allow the program to connect to the server one would suppose.)  The software company?s position is that the consultant should not have been poking around in the software that way, but according to a number writers, this was not an inappropriate practice.  In fact, one security expert offered the opinion that the software company was at fault, because they should never have included that information directly in the software.

The troubling part of the story is that the consultant was concerned about coming forward with what he learned, because the software industry accuse the individual who discover and reports the problem.  According to the article, the consultant was concerned he might be charged with wrongdoing.  For covered entities, who contract with software companies, this is not a good thing to see.  If you are entrusting your PHI to third parties, you should want them to be grateful if somebody comes forward and helps them to keep your data more secure.  This encourages individuals like the consultant in this case to come forward.  This is an attitude that should be encouraged.  I would analogize it this way, if your neighbor or some one else noticed your house was on fire, you would want them to come tell you and you sure wouldn?t turn around and accuse them of setting the fire.

One might also ask why a file full of patient data was placed on a server that any copy of the company?s software could access.  Or at least on a server that apparently was accessed by copies of the software to download software updates.  Shouldn?t your information be stored in a separate location from the software updates?

Another point that came up in the story was another cry for ?more HIPAA enforcement.?  However, HIPAA enforcement wouldn?t really matter in this kind of case.  The software company is most likely not a covered entity.  If it is not a covered entity, the Office of Civil Rights (aka the HIPAA Police) has not authority to enforce HIPAA against the company.  The company?s compliance is solely a matter of the terms of its business associate agreement.  As for the covered entity whose information was at risk, they were not even aware of the problem until after the fact.  

Furthermore, the covered entity was under no obligation to police its business associate.  This is a good thing, because there is not practical way for the business associate to police this kind of thing.  As it is, the circumstances that led to the discovery of the potential security problem were, at best, unique.  Placing a heavier burden on providers to police business associates would place the covered entities at risk for enforcement actions for things over which they have little or no control.  How would covered entities police these things?  Hire consultants to review the code of every piece of software?  Review the business associate?s internal security policies and procedures?  As it is , health care providers have enough to do to meet their regulatory burdens, the answer to this problem is not more enforcement.

Permalink

HIPAA Emergency Prepardness Tool on OCR's Website
Posted by: Robert Markette
July 05, 2006

Last week, the Department of Health and Human Services Office of Civil Rights (?OCR?) published a ?Privacy Rule Emergency Preparedness Tool.? This is not a tool to help you with overall disaster planning. It is, instead, a tool to help covered entities determine what information they may disclose in responding to requests for PHI as part of disaster preparedness. You can download the flowchart from OCR?s website.

This tool does not address disclosures that may be necessary in responding to a disaster. This tool address the question ?What PHI can I disclose as part of efforts to prepare for a disaster.? This issue has come up as federal, state and local governments have been engaging in disaster planning over the last year. After hurricane Katrina and with the growing concern of the Bird Flu, more federal, state, and local agencies have begun to engage in disaster planning efforts, for example, efforts related to evacuation planning. As a result, many state and local governments are seeking information on individuals to identify those, for example, who would need to be evacuated in advance of a disaster.

This tool was developed in response to specific issues that arose when disaster planning for persons with disabilities. Covered entities needed to know what information they could disclose and to whom they could make the disclosures. However, the tool works for any PHI. The tool is not designed to help you with your own disaster planning, but simply to help you make the correct choices when disclosing PHI as part of disaster planning efforts.

The tool covers not only disclosures to public health authorities, but also to other providers. The tool states that disclosing PHI to another provider in advance can be a treatment disclosure, if it is for purposes of ensuring continuity of care. The tool uses the example of a group home disclosing PHI to another facility to which the group home residents would be evacuated in the event of an emergency. This may not be as important to home health agencies or home health hospices, as you will not be evacuating your clients. An inpatient hospice, on the other hand, may very well need to consider this kind of effort. (For those of us in the Midwest, evacuations may not be necessary, but you may need a place to move patients if your building is damaged by floods, etc.)

You should also know that this tool is not designed to assist you with disclosures related to responding to an actual disaster. OCR offered some guidance in that area in the wake of Katrina. There are a number of additional avenues to disclose PHI in responding to an actual disaster. For example, you may disclose PHI for treatment purposes and for certain notification purposes.

Permalink