HIPAA Blog

[ Friday, August 27, 2004 ]

New FAQ on HIPAA applicability to State agencies: OCR has issued a new "frequently asked question" (actually, it's the answer that's important, natch) discussing the intersection of HIPAA and state "open records" requirements. This is a pretty interesting intersection, because it is overlaid by the preemption issue.

HIPAA says covered entities must keep PHI private. A governmental agency can be a covered entity, so it's obligated by HIPAA to keep PHI private. But most governmental agencies must be open and accountable to the public under "open records" or "sunshine" laws. What happens when HIPAA says keep quiet, but Open Records says make it public?

The general rule is that HIPAA says keep it quiet, but that general rule has exceptions. One exception is disclosures that are permitted or required by law. OCR focuses in on that exception, and settles the HIPAA/Open Records dispute on whether the Open Records law is a "permitted" or "required" disclosure. If the Open Records law is a required disclosure, a governmental covered entity must disclose the information. If it's a permitted disclosure, the governmental covered entity can disclose, but has the option not to disclose. Most Open Records issues involved required disclosures, so that's the answer in most cases.

However, there is one interesting aspect of this intersection that OCR doesn't address, and that's preemption. HIPAA preempts state laws that are less protective of privacy. But HIPAA also allows a covered entity to disclose if the disclosure is "required by [state] law." Well, if the state law requires the disclosure but, if the state law weren't there, HIPAA would prevent the disclosure, isn't HIPAA more protective of privacy, and doesn't that mean HIPAA preempts the state law? Wouldn't that analysis make the "required by law" component of HIPAA allowable disclosures nonsensical? Hmmm.

Jeff [11:19 AM]

Don't know much about OSHA . . . : But I know HIPAA when I see it. The AFL-CIO sent a letter to the Occupational Safety and Health Administration seeking guidance on an intersection of HIPAA and OSHA. OSHA requires employers to file injury and illness reports, apparently known as the OSHA 300 log, listing names of employees and the injuries and illnesses they suffer, I suspect from on-the-job accidents and conditions. This list has to be available to employers, former employers, and employee representatives (which I suppose is how the AFL-CIO came in). Some employers apparently were taking off the names of the employees, due to HIPAA concerns. OSHA said they have to keep names on the logs, since it's "required by law." I'm no expert on OSHA, but there is apparently an exception to putting or keeping the names on the logs if there are "privacy concern cases." I'm not sure what that means, but I'd guess it doesn't include a blanket HIPAA prohibition to disclosing any and all names.

Jeff [9:18 AM]

[ Friday, August 20, 2004 ]

BIG, BREAKING NEWS: The first criminal conviction and, as far as I can tell, first criminal charge of a violation of HIPAA has been entered in Washington state. Richard Gibson was an employee of the Seattle Cancer Care Alliance, and was able to get hold of the social security number and date of birth of a cancer patient. He used the information to get 4 credit cards, on which he charged about $9,000 worth of video games, jewelry, clothes, and, of course, porcelain figurines. He pleaded guilty as part of plea bargain yesterday, and agreed to a sentence of 10 to 16 months (which could be served in home confinement -- surrounded by the porcelain figurines), as well as restitution to the credit card companies as well as the identity theft victim. This all assumes that the judge accepts the plea, which I suspect he will.

Two lessons here: first, don't ever forget the criminal aspect of HIPAA. Keep it in mind for yourself when you're deciding whether to comply with the picky intricacies and banalaties of HIPAA, but also keep it in mind when you're trying to hammer on your staff the importance of keeping PHI private. Secondly, note that this is an identity theft case with a healthcare component. Gibson didn't steal medical information, but he did violate HIPAA, because PHI includes identifying information like birth dates and social security numbers. And he stole the social security number because therein lay the profit; while there may be some value in oncological medical information for a third party, the bigger risk is in the simpler identity theft opportunity. Keep that in mind when doing your risk analysis and implementing your HIPAA plans.

BNA report here (paid registration needed), US Attorney John McKay's press release here, copy of the plea bargain agreement here, Puget Sound Business Journal article here (free registration may be required).

One final point/issue (thanks, John Cody): was Gibson a covered entity? He was an employee of a covered entity, and not an actual covered entity. The issue of whether HIPAA can be enforced against a person who is not a covered entity has generated more heat than light, but here you have a likely non-covered entity admitting to guilt under HIPAA. Interesting.

Jeff [10:31 AM]

[ Wednesday, August 18, 2004 ]

Compliance and confusion: As this article in the Kansas City Business Journal indicates (free subscription may be required), many providers are still having some HIPAA teething troubles. The article also illustrates the difficulty in keeping all the moving parts straight. For example, it starts with a discussion of how EDI interfaces are causing more claims errors to occur; that's a "transactions and code sets" problem, and those regs were enforceable against providers in October of 2002 (at the latest), not April of 2003.

Reading between the lines, though, the article confirms that the biggest impacts of HIPAA are on patient interface and dealing with family members and others involved in care. Claims rejections have a bottom-line impact and will obviously get the attention of providers, but the rubber hits the road when the professional comes into contact with the personal: determining how to deal with patients' family members, and dealing with public contact (such as in the line at the pharmacy). Well thought-out policies and procedures, including physical layout of the public/professional workspace, are the key to compliance.

Jeff [9:32 AM]

HIPAA and Law Enforcement: Interesting article in the Minneapolis Star Tribune: Police take a suspect to the hospital ER early Sunday morning and request the doctor to take a blood sample. Suspect may have been drinking, and is accused of stabbing another man (who eventually died). Doctor refuses to take the blood, citing HIPAA and hospital policy against "invasive" or "intrusive" procedures without patient consent. Police wake up a judge, who calls the doctor and tells him he better take the blood sample, but he still refuses (hospital policy requires a "signed" court order to do the procedure without patient consent). Judge signs a court order, which is delivered at 9 Sunday morning, and blood is taken, 5 hours after the original request. Doctor is arrested, questioned, and released.

As the article points out, the police can demand and hospitals can take blood without consent if the life or death of a person may be involved, as was the case here. But the doctor does have a point; the law is unclear, the Supreme Court precedents were set before HIPAA became the law, and when in doubt, it's not unreasonable to err on the side of privacy. However, there was another step the doctor could've taken: take the blood sample, store it in a way that will preserve its evidentiary value (or test it as would be indicated), but don't deliver the sample and/or test results to the police until the court order arrives. That's not a completely square solution: you still have a potential claim for battery for taking the blood without an informed consent, and ordering the test may be considered a "use" of PHI that's not for treatment, payment, or healthcare operations (although that raises an interesting question itself: is the blood itself PHI, or is obtaining PHI by testing the blood a use?), but since there's virtually no risk in taking blood from a patient, it is SOP in emergency rooms to do so, and any treatment actually given to the patient in the ER might reasonably need the extraction and testing of the blood (although the testing for BAC might not be standard, that would still allow extraction and protective storage).

At the least, this case highlights the need to have clear policies if your operations ever involve police action or requests where time is of the essence. Even if time is not of the essence, you should have policies for disclosures to law enforcement officials, attorneys in litigation, and other reasonably anticipated legally-required or -requested disclosures.

UPDATE: According to the latest Strib story (which unfortunately calls the law HIPA), charges have been dropped against the doctor. Still no outing of the doctor's name, which is probably appropriate. There is a real confusion in the law between HIPAA's requirements and law enforcement standards. While it's not an unreasonable search or seizure for the police to obtain a blood sample from an unwilling suspect if there's probable cause and evidence spoilation issues, it just might be a HIPAA violation. Add to that the fact that the police probably can't force an unwilling doctor to take a blood sample if the doctor doesn't want to. This is definitely an area where HIPAA could have been better drafted.

Jeff [8:31 AM]

[ Tuesday, August 17, 2004 ]

Texas Attorney General Update: Back in February I noted that the Texas AG had issues an opinion on HIPAA and the state Public Information Act ("PIA"). I also noted that the AG didn't really answer too many questions. HIPAA only applies to covered entities, but also applies to PHI that a non-covered state entity (like a cop) gets from a covered entity. Also, the PIA itself has exceptions for personal, private information. So, generally, there's some way to keep the information secret if it's more than something like the general observations of the first responder reaching the scene of the accident.

Now, the lack of clarity in AG Abbott's opinion has come back to haunt him. His proclamation that HIPAA is preempted by the PIA has led two separate state agencies to sue him over whether they are required to release information or required to keep it secret. The Texas Department of Mental Health and Mental Retardation and the Texas Department of Human Services have sued the AG, seeking some judicial clarification of the issue. It is unfortunate, since HIPAA and the PIA are actually much more alike than they are different, and generally can be interpreted in a compatible fashion.

That said, what the MHMR is trying to avoid disclosing is fairly ridiculous. A TV station wanted a breakdown of sexual assault charges by MHMR location. MHMR would give state-wide statistics, but not facility-by-facility information. Even though no information was sought on any individuals at any particular facility, MHMR feels that because the location of the facility is also the address of the residents at that facility, disclosing that information would be disclosing a part of the PHI of those residents. If that's the case, disclosing the location of the facilities in a state directory or any other fashion would be a HIPAA violation. That's preposterous. If the information requested doesn't relate to specific individuals, or is not tied to those individuals by anything more than the coincidence of the individual living at that facility, the disclosure isn't even PHI. HIPAA is hard enough; they shouldn't work so hard to make it harder.

Jeff [10:56 PM]

A little late summer spring cleaning: I've got a bunch of stuff in my e-mail inbox that I've been holding until I got the chance to blog on it.

Electronic Medical Records: Here's an article from the NY Times on hospitals going paper-less. Obviously there are some benefits, such as reduction in errors and streamlining of information processing, making the same information available to all care providers across the enterprise, etc. Obviously there are some downfalls, such as the risk of a system crash taking all medical records off-line, greater privacy and security risks, etc. Not quite so obviously, there are some hurdles to making this type of thing work, not the least of which is physicians who are used to doing things on paper or their way, or those who have migrated to electronic records but using a different platform than the hospital. Hat tip: Alan Goldberg.

Risk Analysis: Here's a WEDI (Workinggroup for Electronic Data Interchange) white paper on HIPAA Security Rule risk analysis, including examples of how some covered entities have approached the process. Hat tip: Gordon Apple.

HIPAA Security: As part of your risk analysis, you do need to figure out which of your systems need to be audited, and keep audit logs. In making those determinations, look at systems, look at applications, and look at data to determine what needs auditing. Make it realistic, based on what you think you can catch, what you can analyze and deal with, and what you really need to worry about. Don't try to look at everything, and definitely don't capture more information than you'll be able to review and deal with effectively. Don't make your logs so big you can't easily store them. And most importantly, don't make the auditing process negatively impact the delivery of care. It needs to be effective, but if it hinders care, or slows down the nurses or physicians, they you'll get push-back (and rightfully so).

Thinking about going wireless? First, identify your risks: is PHI stored on mobile devices, is it encrypted, and is access protected? Wireless systems don't come in HIPAA-compliant and non-compliant; compliance depends on your usage and protections. Secondly, train your staff. Make sure your tech people know that they must play be the rules, and make the rules simple and clean. And make sure you teach your doctors, and if they're likely to leave their PDAs sitting around, make sure there's some access protection built into the system. Encrypt if you need to. And document what you've done and why. If you make a bad choice but you can prove it was for a good reason, you're much less likely to find yourself in hot HIPAA water. Hat tip: Hospital Compliance Wire's e-mail service.

Jeff [10:56 PM]

Encryption issues: When you're e-mailing PHI, when do you need to encrypt it? That's the question that the AHLA health information technology listserv has been wrestling with over the last few days. The ultimate answer is that it depends. Encryption is not a required element under the Security Rule, but it is an addressable one, so if you e-mail PHI, you need to have considered whether you need to encrypt, and document your decision.

Obviously, the specifics of your situation will dictate whether you need to encrypt. Sending PHI over an insecure network, especially generally e-mailing over the internet, is a lot different than sending e-mail over a closed network within a healthcare provider like a hospital. In addition to the level of security of the network, the level of confidence that no one but the intended recipient will receive the e-mail will impact the decision to encrypt.

Many HIPAAcrats believe that encryption is required if PHI is sent over the internet. Not so, says one of the Security Rule's original drafters, John Parmigiani. Encryption is an addressable issue, so deciding not to encrypt isn't necessarily a wrong decision, if you've done your risk analysis and (reasonably) determined that, given the circumstances, encryption isn't a necessary part of your risk management scheme. John gave as an example provider-patient e-mail communication where the patient has agreed to receive unencrypted e-mail because of lack of technical expertise or lack of concern over the risk of improper access. Obviously, where the patient-physician relationship is close and the patient is informed of but not particularly concerned about the security risks of over-the-internet e-mail, let 'er rip!

Two things worth emphasizing: even though most HIPAAcrats will say you must use encryption for internet transmissions, encryption is still an addressable item and just because everyone says it's so doesn't mean it's so; and the key to Security Rule compliance is still going through your processes and systems and checking off how you will comply with the required elements and how you will address the addressable ones (i.e., risk analysis and risk management).

Jeff [10:56 PM]

Great Logos in history: Check out this one from the District of Columbia Department of Health. They could've been DCDH, but decided on Homer Simpson's favorite, DOH!

Jeff [5:21 PM]

It's Pete Stark's Fault! I just knew it: according to this GAO report (abstract here), the adoption of new healthcare IT advancements like electronic medical records has been hindered by a hodge-podge of laws and other legal issues, including Stark and Anti-Kickback laws. Doctors are afraid to take IT services offered by hospitals (and hospitals may be wary about offering them) because of the fear that the provision of services would trigger a payment-for-referrals claim. Antitrust laws, tax laws, state licensing laws, intellectual property and malpractice concerns, and other laws also hinder the IT revolution. The GAO faults HHS for not removing thses barriers and uncertainties.

Apparently, HHS disagrees with the GAO, stating that the GAO didn't take into account all HHS has done with regard to privacy and security. Several articles on the issue are here and here, as well as in BNA and Modern Healthcare (subscriptions required).

Jeff [4:15 PM]

[ Wednesday, August 11, 2004 ]

Top 5 Drivers of EMR/EHRs: This week's Modern Healthcare (Aug 2, page 32) includes a Medical Records Institute survey of the top factors driving the need for electronic medical/health records:

Need to improve quality of care (87.4%)
Need to improve clinical processes/workflow efficiency (84.9%)
Need to improve clinical documentation in support of billing (74.8%)
Need to reduce medical errors (73.1)
Need to share patient information among providers (70.6%)

Jeff [3:48 PM]

E-Prescribing Gets a Shot in the Arm: A consortium of vendors, producers and service providers in the electronic prescription industry has initiated a new project to push e-prescribing. Called CafeRx, their mission is to remove the technical and legal barriers to the growth of electronic prescribing and prescription filling. Obviously, the use of electronic prescribing could speed up prescription filling, streamline the supply process, get drugs where they are needed faster, and reduce errors that can come from pharmacists trying to decipher physician handwriting. Some very big players are involved (Microsoft, for example), but the consortium is pretty much open to any IT companies who want to push the e-prescribing bandwagon forward.

Jeff [3:41 PM]

[ Tuesday, August 10, 2004 ]

Security Tip for the Day: Scramble your static information. As this interesting article from InfoWorld magazine points out, access control systems and other efforts to address the protection of PHI at input, output, and transmission are the primary focus of folks looking at HIPAA compliance from the security side. However, stop for a second and look at your static information: data bases that simply sit there with tons of PHI, waiting for someone to access them. Sure, you have access controls to make sure you keep out improper eyes. But what if someone defeats that system? Wouldn't it make sense if the information sitting there was actually encrypted*?

The analog is a locked filing cabinet or medical records room. The lock on the door is a good first-line of security. But if the records themselves were all mixed up? For example, what if there were no names on the files, only numbers, and the key for correlating numbers to names was elsewhere? Or what if the information on a particular patient was actually in several different files, and each file had information on several different patients? Or what if the information in the files was scrambled so that an intruder would not be able to make sense of it without a correlating key?

That's the idea: work hard on making sure you control access to your employees with need-to-access the particular file. That will help keep an unauthorized employee from accessing information on your systems. But you should also encrypt your static information. That won't keep out the hackers and other outsiders who might get around your access control system (and who your access control systems don't focus on), but it will keep them from being able to use any information they get.

*(nota bene: the article actually discusses various ways to manipulate information in ways that make it unviewable or unusable without decoding. I use the word "encryption" to describe all of that, but more technophilic folks like the the article author use encryption to describe just one of these procedures.)

One last tip: The author makes a pretty good point on the last page of the article: you've got to audit your systems for security problems, but while you want to keep secret the tricks you use to encrypt the data, you want your audit procedures to be very, very visible. Have you ever noticed how people pick their noses when they're alone in their cars, but not when they're in equally visible places like eating in a restaurant? The closed doors and windows, the radio playing, they all give the driver an illusion of privacy, and people will act differently when they think they're not being watched than they will when they think they're in public. It doesn't matter how often you audit your system, or even which system you audit, if your employees think you audit everything all the time. If they never think they're in the privacy of their own car, they'll never pick their nose.

Hat tip (on the article, not the nose-picking analogy): Megan Charlesworth at Cook Group.

Jeff [10:03 AM]

http://www.blogger.com/template-edit.g?blogID=3380636 Blogger: HIPAA Blog - Edit your Template