HIPAA Blog

[ Thursday, September 29, 2016 ]

 

Filing PHI in Court Documents: It's OK for providers to sue patients who don't pay their bills; providers don't have to work for free, and they aren't slaves of their patients.  However, if you do so, make sure you don't include any PHI more than is necessary for the filing, and consider seeing a qualified protective order for any PHI you really need to disclose.  The disclosure is permitted as a disclosure for payment or healthcare operations purposes, but the "minimum necessary" rule applies.  So it's OK to state the debtor's name, and the name of the entity providing the care, but you probably don't need to include particular specifics such as the patient's social security number or birth date, the specific treatments provided, diagnosis, prognosis, or similar information that's not relevant to the debt.

WakeMed found out the hard way.  It wasn't a HIPAA ruling, but it was a $130,000 lesson.  Of course, OCR could still weigh in on it, too . . . . 

Jeff [2:27 PM]

[ Wednesday, September 28, 2016 ]

 

HHS' HIPAA guidance doesn't reach NIST standards: That's the GAO's conclusion, and they're right.  However, while NIST's CyberSecurity Framework (CSF) is a good place to get guidance and a worthy goal of any entity looking for data security, it's not really required.  HIPAA is for every covered entity, and the vast majority of HIPAA covered entities (think one-doctor practices) won't have the infrastructure, much less the potential risk of loss or breach, that would warrant a full-blown CSF-compliant security plan.

Expectations and requirements must both be reasonable.  HIPAA-covered entities should look at CSF, especially the crosswalk provided by OCR.  But don't feel inadequate if you can't hit every target; instead, try for the reasonable stuff.  Besides, your Privacy Rule compliance is going to give you a lot more comfort in meeting Security Rule requirements than fretting about technical compliance requirements that are beyond your organization's ability.

Jeff [1:09 PM]

[ Tuesday, September 27, 2016 ]

 

Why did Care New England Pay $400,000 for Failing to Update Internal BAAs? The healthcare system management entity is technically a business associate of the related providers, and thus there must be business associate agreements between the provider entities and the management entity.  They apparently entered into appropriate agreements in 2005, but failed to update them in 2013 after the Omnibus Rule was issued.

The management entity apparently lost 19 unencrypted backup tapes containing PHI on 14,000 individuals.  There is no evidence that the tapes have been acquired by any unauthorized individual or that the information in the tapes has been used in any way.  However, there's also no evidence that they haven't been acquired or used.

The State of Massachusetts fined Care New England $150,000 for the actual breach, so OCR did not fine them for the breach itself.  Instead, OCR fined them for failing to update their BAAs.  That is, they failed to update the BAA between the two related entities, the hospital whose data was lost and the closely-related management company.

It should be noted that the required updates from the Omnibus Rule (specific reference to subcontractors, specific reference to BA's obligations under the Security Rule, and a specific statement relating to BA's performance of CE's obligations under the Privacy Rule) have absolutely nothing to do with the breach that occurred and the potential damages.  

Yes, that's right: if Care New England had done what they're paying $400,000 for failing to do, they would be in the exact same position they are now.  Fixing that glitch would have had absolutely no impact on the loss of data (which actually occurred in 2012, before the Omnibus Rule was even published).

Quite curious.  

Jeff [11:03 AM]

[ Friday, September 23, 2016 ]

 

Magical Incantations of Blockchain: I must confess: I was a liberal arts major, and I've never written a line of code in my life.  So maybe I'm just an idiot (a real possibility), but I just don't see how Blockchain works, and how it's going to be the next great thing in healthcare.  My understanding is that the benefit of Blockchain is that there's no intermediary in transactions, and no central location for storing transaction information.  Rather, multiple parties can view the chain links so as to ensure that the links are correct, and that's why no intermediary is needed to ensure that both parties to the transaction are presenting it identically.  However, that seems to allow a lot of additional people to view a transaction, including people who aren't connected to it, and that would cause HIPAA problems if there's PHI in the transaction.  This article indicates that only authorized persons can view the transactions; who authorizes them?  And if they're interested parties, what's to prevent them from tampering with the transaction information (in a way that an intermediary would prevent)?

I just don't get it.  Anyone got a good explainer for this?

Jeff [5:29 PM]

[ Thursday, September 22, 2016 ]

 

Want Some Free HIPAA Advice? Are you a North Texas healthcare provider looking for help and ideas on how to conduct a good risk analysis for your organization?  How would you like the assistance of a dozen Masters of Healthcare Management graduate students in analyzing your business operations and HIPAA risks, to help determine if your HIPAA policies and procedures are up to snuff?  If you're available on October 6th from 7-9:30 pm, I've got a deal for you.  Contact me at jdrummond-at-jw.com for details.

Jeff [3:18 PM]

 

Providers Must Understand [and Practice] Cybersecurity: Ft. Worth's own Theresa Meadows serves on HHS' Health Care Industry Cybersecurity Task Force and has some good points to make.  Like understanding your risks.  

Jeff [11:09 AM]

[ Tuesday, September 20, 2016 ]

 

YouTube broadcasts of plastic surgery procedures?  Yes, they can do that, as long as they have sufficient patient consent.  It's the patient's PHI, and if they agree, it's OK.  But if you're the provider, make sure their consent is sufficient.  

Jeff [12:44 AM]

[ Friday, September 02, 2016 ]

 

Q from @JShafer817:  We do not encrypt SMS messages and they are absolutely not secure enough for PHI in general, whether or not we encrypted them for out part of the journey.  In other words Jeff.. SMS sucks.. and once it leaves the server it isn't encrypted anyways...  So.. should SMS be used for... appt confirmations???

A: HIPAA requires reasonable safeguards to protect the confidentiality, integrity and availability of PHI.  It does not require or expect perfection.

Covered entities are required to do a risk analysis of their operations, determine what safeguards are appropriate, and adopt those reasonable safeguards.  A covered entity may determine that the increased benefits of a particular modality over a second modality outweigh the increase in safety the second modality provides.  For example, a covered entity may determine that the lower costs of a postcard reminder notice (versus an enclosed letter) outweigh the increased risk of postcard versus letter, given the minimal nature of the PHI that is or could be exposed.  While a provider like a dentist might make that decision (“who cares if everyone knows I go to the dentist?”), a provider who deals with much more sensitive information, such as an infertility specialist or oncologist, might determine that the increased risk is not worth the cost savings.  Likewise, a provider might determine that postcards are good for certain communications (annual appointment reminders) but not others (transmitting lab results), and should always insure that the minimum necessary information is included, regardless of the transmission mechanism.  Those are legitimate choices, and in proper circumstances would be reasonable under HIPAA.

The question regarding texting is similar.  Unencrypted texting is less secure than encrypted texting, and much less secure than communication via a patient portal.  But using an encrypted texting solution or patient portal adds complexity that might be sufficient to cause the patient to not utilize the service, and therefore entirely lose the benefit of good communications with his/her provider.  In that case, the benefit of ensuring increased and effective communication might outweigh the risks of using unencrypted texting instead of a more secure means of communication.  In either case, secure email or insecure texting, the minimum necessary information should be included.


Thus, as long as the provider has done a proper risk analysis of the issue (and I would recommend documenting the determination), SMS texting could be allowed under HIPAA, in the right circumstances.



PS: please remember this is not legal advice; consult your own attorney; your mileage may vary.

Jeff [9:44 AM]

[ Tuesday, August 30, 2016 ]

 

SCAN Health Plan (CA) and Appalachian Regional Healthcare (KY and WV) get breached.  The former sounds like an insider breach, the latter a ransomware or malware attack.

Jeff [2:18 PM]

 

Wanna see a pacemaker get hacked?  Not sure how legit this is, and there's still no documented evidence of an actual hacked medical device, but the possibility will keep mystery and thriller writers going for a while. . . .

Jeff [11:31 AM]

 

Cybersecurity continues to be a big concern for healthcare providers. 

Jeff [11:27 AM]

[ Saturday, August 27, 2016 ]

 

Beer Science: Beer IS science.  Seriously, I know more about chemistry, and specifically enzymatic reactions, because of homebrewing than I ever learned in school.  Then again, I was a liberal arts major. . . .

Jeff [10:54 AM]

 

Let's try this again, again:

OCR to investigate smaller breaches. This makes sense if they want to look at entities with lots of small breaches, breaches involving the exact same fact scenario, or breaches that cause a lot of damage even though there are only a relative few victims (i.e., less than 500 affected individuals).  Timing of notifications matters: OCR will find out that a big breach has occurred when the individuals find out, but won't hear about small breaches until January-February of the next year.  And OCR will investigate small breaches if there's a complaint, but not necessarily if there's not.

However, this initiative really only makes sense if OCR has extra investigator time on their hands, which I'd guess they don't.  Thus, what's the real rationale for a public announcement of this kind?  Probably to keep people on their toes.  If someone thinks they're in the clear and able to fly under the radar when the breach is less than 500 people, maybe this is intended to give them a little fear-factor and make them think twice, at least about doing a good breach risk analysis and maintaining good documentation.


PS: an earlier version of this post was garbled because I used the "less than" sign rather than the words, which triggered a weird HTML effect.  Thanks to Theresa Defino for the heads up.

Jeff [10:36 AM]

[ Friday, August 26, 2016 ]

 

Jason Pierre-Paul: this is sort of insider-baseball stuff (can you say that about a case involving a football player?), but a court is allowing the suit to go forward.  Pierre-Paul is suing ESPN for violating his privacy and Florida medical confidentiality laws.  The network certainly did not directly violate HIPAA (because the network is not a "covered entity" under HIPAA), but query whether ESPN aided/abetted the hospital to do so, or whether ESPN could be held liable anyway under the HITECH provisions that theoretically allow HIPAA prosecutions against employees or agents of covered entities.  Interesting possibilities (well, interesting to me, at least).

Jeff [1:13 PM]

[ Thursday, August 11, 2016 ]

 

Reminder: Just because you're a healthcare provider does not mean HIPAA is applicable to you.

I was having a conversation just last night regarding this issue: HIPAA only applies to health plans, health care clearinghouses, and health care providers "who transmit any health information in electronic form in connection with a transaction covered by" HIPAA.  The 8 HIPAA-covered transactions are:
  1. Health claims and equivalent encounter information.
  2. Enrollment and disenrollment in a health plan.
  3. Eligibility for a health plan.
  4. Health care payment and remittance advice.
  5. Health plan premium payments.
  6. Health claim status.
  7. Referral certification and authorization.
  8. Coordination of benefits.
If you are a health plan but don't undertake any of the above transactions in electronic form, then you are not covered by HIPAA.  That does not mean you are entirely in the clear.  If you suffer a breach, you may have state law reporting obligations you must still clear.  And if you serve as a business associate for a covered entity, you may become subject to HIPAA via that back-door route.  However, the potential for big HIPAA fines are not there if you are not a HIPAA covered entity.

This was illustrated by a New Jersey case last year, which I also blogged about (albeit in a different, more esoteric context).

Jeff [12:25 PM]

[ Monday, August 08, 2016 ]

 

Are Ransomware Attacks Per Se HIPAA breaches?  "Not Necessarily," says this National Law Review article.  Of course, I agree.  But this is just plain wrong: "If, however, the ePHI is encrypted by the ransomware attack, a breach has occurred because the ePHI encrypted by the ransomware was acquired (i.e., unauthorized individuals have taken possession or control of the information), and thus is a “disclosure” not permitted under the HIPAA Privacy Rule."  In most ransomware situations, the malware is injected into the affected system; there is no possession, and certainly no disclosure; there is only "control" in the context of preventing the rightful owner from controlling the data, since the hacker has no control either, and can't even decrypt the data.  Preventing someone else from using their data is not "controlling" the data, it's controlling the victim and rightful owner of the data.

Jeff [5:57 PM]

 

Newkirk, BCBS-KS breaches: Newkirk is a business associate of a lot of health plans, printing insurance cards for plan members (not too sure what happened there, since the article is behind the WSJ paywall).  Blue Cross Blue Shield of Kansas is one of Newkirk's customers, apparently, and about 800,000 of their customers are impacted.  No SSNs or financial information, but insurance information like group numbers and the like, which would be helpful for medical identity theft.  

Jeff [10:11 AM]

 

Yes, Healthcare Data is Attractive to Hackers: For a number of reasons, as reflected in the value of health information on the "Dark Web."  But is the healthcare industry reacting appropriately and increasing defenses?  There sure seem to be a lot of breaches being reported, but don't mix in the settlements of old cases with new breaches.  In fact, so far, 2016 is experiencing substantially fewer people affected by healthcare breaches.  Maybe we are moving in the right direction. . . .

Jeff [10:03 AM]

 

Yes, it is a Big Year for HIPAA Fines: but is it proof of more enforcement (or more strict enforcement), or just bigger fines?  Personally, I've had several clients avoid fines where I thought OCR would levy something, but that might be my expectations changing, not the underlying enforcement environment.  (For the record, none of those clients deserved a fine, nor could they really afford one, but given the current enforcement trend, I was worried.)

Jeff [9:58 AM]

[ Friday, August 05, 2016 ]

 

Threat-Sharing: It's a big deal these days, whether it's the proposed federal Cybersecurity Information Sharing Act ("CISA"), Presidential policy on Cyber Incident Coordination, or private industry-specific activities like HITRUST's cyber threat exchange (CTX).  Now HHS is getting into the act.  These are all nascent, but I think some good intelligence might come from all of this.

Jeff [11:32 AM]

[ Thursday, August 04, 2016 ]

 

Biggest Fine Yet (IIRC): Illinois' Advocate Health has been fined $5.55 million by OCR for a series of HIPAA failings.  Looks like a lack of a good risk assessment, lack of physical access controls, and BAA failures are part of the mix.

Jeff [4:42 PM]

[ Wednesday, August 03, 2016 ]

 

It's a Banner Day for Breaches. Banner Health suffers a huge one: 3.7 million patients.  Actually, it looks like 2 breaches in one for the huge western-US healthcare provider.  One went after payment card data from food and drink locations at Banner facilities, and the second one went after patient records.  

Jeff [1:54 PM]

 

Hacker World Problems: a Ukrainian hacker stole 100,000 documents from Central Ohio Urology Group (mostly internal documents, like surgery schedule spreadsheets) and posted them online.

Was he trying to sell the data on the Dark Web?  Engaging in identity theft?  Extorting payments from the group?

No, he's trying to bring public awareness to the "fact" that the Pentagon is poisoning people in the Caucasus with secret injections.

Huh?

Here's more on the story.

Jeff [1:54 PM]

[ Monday, July 25, 2016 ]

 

Medical Device Security: I still think this is in the realm of TV shows and movies (I've been binge-watching Mr. Robot lately), but while the likelihood is slim, the possibility of hacking a medical device should certainly concern the healthcare IT crowd.

Here's an interesting graphic I got from Arxan Technologies that is certainly food for thought.


Jeff [10:04 AM]

[ Friday, July 22, 2016 ]

 

No, No, No.  No, @HealthPrivacy, you cannot draft regulations via guidance.  This is just plain wrong.  If a covered entity has, in the course of a reasonable risk analysis, determined that emailing of unencrypted PHI is not secure, then the covered entity is not required to email unencrypted PHI to individuals exercising their access rights.  The regulations do not say that, and you can't change the regulations by issuing guidance.  If the covered entity has no such policy, or if it allows unencrypted emailing in other situations, if it has the policy but doesn't follow it, or if the policy is unreasonable, then the covered entity may have to email PHI to the patient.  The access regulations (which carry the force of law) say that, if the covered entity maintains the PHI electronically, then it must provide the PHI in electronic format; they do not say that the covered entity must provide the PHI via electronic transmission.

Follow the rules, OCR. You can certainly change the regulations.  If this is important enough for guidance, it's important enough for a regulation.  Propose a new rule revising 45 CFR 164.524, publish it, request/receive/review public comments, and finalize it.  That is how it works.  And don't try to enforce "guidance" as if it's a law or regulation.  It's not.

Jeff [10:38 AM]

[ Thursday, July 21, 2016 ]

 

Ransomeware: 4 steps for fighting it.  I'd add my own 4 steps, if I haven't already:


  1. Patch management and current virus software: whenever vulnerabilities are discovered in software, the developers usually send out patches.  Make sure your organization is signed up to get those patches and promptly applies them.  It's extremely unlikely you'll be attacked between the time the vulnerability is discovered and the time the patch has been provided; usually, however, businesses don't apply the patches, or don't sign up to get them, and it's a relatively old vulnerability (for which a patch is available) that is ultimately exploited.  Same with virus protection software.
  2. Limit connectivity.  Computers that aren't connected to the internet can't get infected by the internet, at least not directly.  Don't connect computers unless you have to, and if you do, make sure your connectivity architecture is simple, logical, and traceable.  If there's only one gate into the city, there's only one place to focus your protection efforts.
  3. Have good backups.  Ransomware is designed to scramble your eggs.  If you can just throw those eggs out and replace them, then you won't need to pay the ransom.  Dealing with a ransomware attack is still enough hassle that you want to take all other other steps, but worse case scenario, good backups thwart any ransomware attack.  Delete the infected files, scrub the system, and reinsert the backups.
  4. Train your staff and be prepared.  Most ransomware comes from phishing or other social engineering.  Most attacks are pretty clumsy, too, if you have the slightest clue what to look for.  Make sure you staff has the slightest clue; better yet, make sure they have some pretty good clues.  And make sure your organization is ready for any hack, whether it's ransomware, DDoS, or date theft.  Who ya gonna call (when something looks funny in the system)?  If your team doesn't know the answer, you aren't ready.

Jeff [11:13 AM]

 

Breaking News: Entities not covered by HIPAA have privacy and security gaps.  Well, duh.

HIPAA isn't intended to be some European-style data rights law that grants everyone specific rights in their own data and the right to demand that third parties, with which they may have no direct relationship and which otherwise owe them no specific duties, either limit their uses/disclosures of that data or provide minimum levels of security and protection to that data.  Frankly, that's not how the data rights structure of American law works, and not how it should work.  Have you seen what lawyers have done with the Illinois biometric privacy law so far?  Imagine what they would do if every person entity who might legitimately come across personal information had a duty to protect it?  Consider this: if you have a phone book in your house and it's not locked up, you aren't protecting the identifiable information in it; if there was a law applicable to you that required you to protect it, anyone whose name is in that phone book could sue you.  That's crazy; and that's why you have no general obligation to protect that data, and only have an obligation if there's some specific contractual or other relationship, duty, or applicable law.

So it's understandable that, while HIPAA requires certain restrictions and levels of protection from covered entities (and, both directly and indirectly, from business associates), it doesn't require the same level from "non-covered entities."

Update: Here's another article, and here's a copy of the HHS report on NCEs.

Jeff [10:40 AM]

[ Wednesday, July 20, 2016 ]

 

I think we knew this: cyber attacks increasing in the health care industry.  Interesting take on the article: the ACA pushed medical practices to adopt EMRs before they were technologically proficient enough, and now cyber attacks are the price we pay for not really being shovel-ready.

I call bullshit.  Plenty of tech-savvy companies have been hacked.  It's not a "not ready for prime time" issue of the targets.  If they were more ready, they'd still be getting hacked.  

Jeff [6:02 PM]

[ Tuesday, July 19, 2016 ]

 

Providence Health, Oregon: A bad employee apparently snooped on 5,400 patients' demographic info, including SSNs.  But Providence doesn't think the employee kept or used the information.  Not sure this is necessarily a reportable breach (or breech), but perhaps they were just notifying out of an abundance of caution?

Jeff [3:44 PM]

[ Friday, July 15, 2016 ]

 

Oregon Health & Science University: I reported back in 2013 regarding OHSU's multiple breach incidents.  It seems OCR has finished its investigation and levied fines of $2.7 million for the breaches. That's a lot of cash when there was no harm done to patients. . . .

Jeff [2:35 PM]

[ Thursday, July 14, 2016 ]

 

Data Breach Costs: Healthcare breaches cost the most.  Some interesting findings in the latest Ponemon study.

Jeff [10:42 AM]

[ Wednesday, July 13, 2016 ]

 

Asking for HIPAA and FDA medical app reform on Capital Hill.  I know some of these guys.  This deserves a good Fisking; I'm just too tired right now.  

Jeff [5:13 PM]

[ Tuesday, July 12, 2016 ]

 

Cybersecurity made somewhat simple: a podcast from Tech Policy.  Obviously there's more than this, but it's a good place to start thinking about some of the low-hanging cybersecurity fruit.

Jeff [4:26 PM]

 

OCR Issues Ransomware Guidance: While I couldn't disagree more with the assertion that ransomware attacks "usually" result in a Breach, I do applaud OCR for issuing this timely and pertinent guidance to covered entities.  Clearly, regardless of the specifics of your business, you should take these steps to help prevent or minimize the impact of a ransomware attack:


Also a good idea to have a security incident response plan (including a staffed incident response team) in place and ready to respond.

Jeff [12:24 PM]

 

HIPAA Criminal Case: Here's a good article on the HIPAA criminal case brought against Jamie Knapp in Ohio I discussed earlier.  

Jeff [9:23 AM]

[ Thursday, July 07, 2016 ]

 

Bitcoin: a little backgrounder from ID Experts.

Jeff [11:15 AM]

[ Thursday, June 30, 2016 ]

 

Mass General Dental Data Breach: a dental vendor to the hospital, Patterson Dental Supply, suffered a breach of its servers hosting the Mass General dental patient data.

Jeff [12:52 PM]

[ Wednesday, June 29, 2016 ]

 

Jamie Knapp: Analysis Update: A couple of folks (@LaClason and @PogoWasRight) pointed out that, in regard to my earlier post this morning,  HITECH did add a change to the actual HIPAA statute that is intended to be used (and has been used) to prosecute employees or third parties for acts that would be violations if they were covered entities, mainly to avoid the anomaly that rogue employees or other bad actors are free from HIPAA criminal liabilities because they aren't the actual covered entity.

Prior to HITECH, Section 1320d-6(a) had one sentence, that says: "A person who knowingly and in violation of this part (1) uses or causes to be used a unique health identifier; (2) obtains individually identifiable health information relating to an individual; or (3) discloses individually identifiable health information to another person, shall be punished as provided in subsection (b) of this section."  HITECH added a second sentence: "For purposes of the previous sentence, a person (including an employee or other individual) shall be considered to have obtained or disclosed individually identifiable health information in violation of this part if the information is maintained by a covered entity (as defined in the HIPAA privacy regulation described in section 1320d–9 (b)(3) of this title) and the individual obtained or disclosed such information without authorization." The copy of 42 USC 1320d-6 that I pulled up online didn't have the added language, which explains my miss of it.

However, it did give me an opportunity to re-review the new statutory language, and in fact I maintain my opinion: Knapp (and Chelsea Stewart in an earlier case) should not have been convicted, because their acts were not in violation of HIPAA.  That's because the HITECH-added language, which is intended to make them criminally liable (and pursuant to which they were held criminally liable), is deficient from a statutory construction standpoint.

The added language says “for purposes of the previous sentence,” which would be fine to change something within the construct of the previous sentence.  (Example: "It is a violation of fashion law to wear white after Labor Day.  For purposes of the preceding sentence, white shall include bone, ecru, ivory, eggshell, and taupe.")  But the preceding sentence still says the obtaining or disclosing must be “in violation of this part.”  It doesn’t change the definition of a covered entity or put obligations onto anyone other than a covered entity.

And you can’t change the meaning of “in violation of this part” by such a passing reference.  In other words, you can’t change the definition of “in violation of this part” to simply mean any obtaining or disclosing of IIHI “if the information is maintained by a covered entity . . . and the individual obtained or disclosed such information without authorization.”  If that’s the case, then any obtaining or disclosing of IIHI that is (i) “maintained by a covered entity” and (ii) “without authorization” would be a violation.  And if that’s the case, every obtaining or disclosing of hospital-held PHI for treatment, payment, or healthcare operations (i.e., uses and disclosures for which an authorization is not required) would be a HIPAA violation.

HITECH was a hastily- and sloppily-written statute.  But it’s also another example of the pure lawlessness of the current federal government.  If we are to live under the rule of law, laws must apply equally to all.  They must be clearly written so citizens can know exactly what conduct is prohibited and what is allowed.  Words have meaning, and the meaning of words has consequences.  When it comes to criminal law, where one’s property or liberty can be removed by the state, there cannot be a “well, you know what I mean” quality to it.  Criminal statutes in particular MUST be clearly and precisely written.  If there is any ambiguity (and there certainly is here), the benefit of the doubt must go to the accused.  

Congress had the opportunity to fix this loophole by changing the definition of Covered Entity or by specifying a new and separate violation (i.e., “a person violates this part if . . . “ or “It is a violation of this part if a person . . . “), but they didn’t do so.

I hope the next person who is charged under this provision challenges it on these grounds.  I don’t object at all to holding employees and other non-covered-entities criminally liable for these types of breaches.  I think this is a loophole that should be and needs to be closed.  But the law should be written to make these types of breaches actual violations of the law, and what is written doesn't do that.  Have some respect for the rule of law.

Jeff [3:24 PM]

 

Jamie Knapp: another HIPAA criminal conviction: a respiratory therapist who accessed PHI of patients she was not seeing has been convicted, apparently of violating HIPAA, by an Ohio federal jury.  I'm still trying to figure out how a respiratory therapist employee of a hospital, who by herself is not a covered entity, was convicted of violating HIPAA.  Not every health care provider is a covered entity; you must also conduct electronic transactions that are HIPAA regulated.  Generally, an employee will not be conducting those transactions. And while the officers and directors of a company may be held liable for their activities as decision-makers of their companies (in other words, they can't hide behind the company for their own acts if the company is responsible as well), I don't see how a low-level employee is bootstrapped into being the covered entity itself.

Jeff [8:32 AM]

[ Tuesday, June 28, 2016 ]

 

Tex. Health & Human Services Commission Breach: The HHSC's records vendor, Iron Mountain, lost some boxes with records of 600 people who applied for benefits with HHSC.

In case you didn't know, the HITECH and Omnibus Rule changes to HIPAA's definition of "business associate" make clear that anyone who "creates, receives, maintains or transmits" PHI for a covered entity is a business associate.  "Maintains" includes storage, so wherever a covered entity stores its PHI, whether it's a cloud-based server or Uncle Bob's Self Storage, the storage company is a business associate.  Of course, self-storage places, that never intend to access the records in storage and don't even know what people keep in their storage lockers, really don't want to be BAs, and they sure don't want to sign BAAs.  But have you ever seen the TV show Storage Wars?  Stuff in self-storage facilities sometimes gets disclosed to the general public.  Unfortunately, if you are a covered entity and you're using a self-storage facility, you must get them to sign a BAA, or find another facility.

There are facilities that will sign BAAs, and Iron Mountain is one of them.  This is the first breach I've heard of involving Iron Mountain; hopefully it will be the last.

Hat tip: Virginia Mimmack

Jeff [4:00 PM]

[ Monday, June 27, 2016 ]

 

Is the theft of NFL Players' medical records from a Redskins' trainer a HIPAA violation?  Almost certainly not.  But it is likely a violation of some state data protection laws, and almost certainly raises a data breach notification obligation.

A Redskins trainer left a backpack containing paper medical records, as well as a laptop with electronic medical records, of current and former NFL players in a locked car; the car was burgled and the backpack (and its contents) stolen.  The laptop was password-protected, but the electronic data was not encrypted. This is not good.  But it's also unlikely to be a HIPAA violation, mainly because it's unlikely there is a HIPAA covered entity involved.

No breach without a CE or BA: The NFL itself, and the Washington Redskins specifically, are not health plans, health care providers, or health care clearinghouses.   Therefore, they are not "covered entities" (or CEs) under HIPAA.  The trainer is most likely a health care provider, which would make him/her a CE if he/she engages in electronic transactions of the sort regulated by HIPAA.  These would be submitting billing to insurance, checking for insurance coverage and benefits, tracking payments, etc.  I would be extremely surprised if he/she did so, since I assume he/she is paid by the Redskins for services provided.

It also does not seem likely that the NFL, the Washington Redskins, or the trainer were acting as a "business associate" (or BA) of some other CE in connection with the lost data.  Without a CE or a BA, there can't be a HIPAA breach.

One possible caveat: the Players Association is all over this story.  It is possible that the Players Association is structured in such a way that it (or a component of it) is a CE by virtue of being a health plan.  I doubt that, since I doubt the PA pays or provides for medical care; I assume the teams pay for their own players' medical care.  But that unlikely event is the only way I see HIPAA being involved here.

Employment records aren't PHI: Even if there was a BA or CE involved here somehow, there's still the question of whether the data lost was "protected health information" (or PHI) under HIPAA's definition.  The definition of PHI is extremely broad, and it's likely that this information could be PHI, but the definition does have an exception that might be applicable here.  Namely, "employment records held by a covered entity in its role as employer" are specifically excluded from the definition of PHI.  We don't know for sure, but it seems like the lost data might be "employment records."

Encryption is not required: The article states, "Storage of data on unencrypted devices does not adhere to both local and federal medical privacy standards, including HIPAA, making the breach a potentially costly one for the NFL."  Not true.  Don't get me wrong; encryption is best practice, and I highly recommend it, not the least because HIPAA's breach notification provisions are inapplicable if the lost data is encrypted.  But encryption is not required, and therefore storing data on unencrypted does not fail to meet a standard under HIPAA.  Some states (MA for sure) have state-level encryption requirements, but it's impossible to tell from the article whether those state statutes would be implicated, or if the state regulators would be able to commence an enforcement action.

State laws may apply: Depending on where the theft occurred, the states of residents of the affected individuals, the location of the responsible parties (are the Redskins actually in DC or in Maryland or Virginia?), and the location of the theft (Indianapolis), various state laws may be impacted.  Some states have laws requiring reasonable security for personally-identifiable information; most have laws requiring the notification of individuals whose data has been breached.  Those laws vary greatly, but it's pretty safe to say some would be implicated by this situation.  Some do not require notification if there is little or no risk of harm from the breach, and it's possible that the NFL and the Redskins could come to that conclusion based on the fact that the data was password-protected; that wouldn't cure the problem with the paper data, though.  Regardless, that's a fact-specific matter based on the reasonable conclusion of the parties involved.  I would expect the NFL and/or the Redskins to notify all individuals involved, regardless of whether it's legally required or not.

Jeff [5:50 PM]

[ Monday, June 06, 2016 ]

 

(wrote this back in April, don't know why it didn't post): NY Med HIPAA Fine: NY Med was a reality TV show filmed in NY hospitals.  It's relatively famous because NY Presbyterian Hospital and ABC are being sued by the family of a man who was hit by a garbage truck and was dying in the hospital; the film crew filmed his plight, without his authorization.  The show pixilated the man's face and included no identifying information, but some family members were able to determine that it was him, and they're now suing the hospital and ABC.  It's unlikely that anyone would have been able to determine who the dying man was if not for his family's publicizing the case by filing suit.  I believe that ABC has been released from the suit, but the suit goes on against the hospital.

OCR has now fined NY Presbyterian 2.2 million dollars for this case and for a similar issue involving another individual.  

Jeff [11:30 AM]

 

University of New Mexico Hospital breach: A change in software led to invoice information on about 3,000 patients being sent to 18 incorrect addresses.  Definitely PHI included in the improper disclosures, but none of the traditional identity theft markers like social security numbers.

Jeff [11:17 AM]

 

ProMedica Michigan breaches: Two hospitals in Michigan operated by ProMedica are under investigation by HHS for breaches apparently involving employee snooping.  Seven employees were involved; 3 were fired, the other 4 disciplined.  About 3500 patients were impacted.  None of the files were printed, which makes large-scale identity theft less likely (of course they could've been saved to a flash drive, but I'm assuming they ruled that out too).  That makes it more likely to either be pure nosy snooping (although the number is pretty high -- can't imagine that each snooper would know 500 people in the hospital), improperly-restrained curiosity, or some less-nefarious intend, such as wanting to see if hospital policies are being applied evenly.

Jeff [10:57 AM]

 

Abortion: HIPAA makes its way into the Planned Parenthood fetal tissue sales story.

Jeff [10:47 AM]

[ Tuesday, May 31, 2016 ]

 

Yelp: HIPAA covered entities must be careful in responding to Yelp reviews, good or bad (but especially bad).  Just because the patient has posted his/her own PHI, doesn't mean the doctor, dentist, or other provider can.

You can, however, respond in a way that doesn't bring up a specific patient or discuss an individual's specific PHI.  If a Yelp poster complains that "this provider did X," the provider can post that "my office policy is to never do X, and that I looked at all my files for all patient visits in the last year and could not find an instance of anyone doing X."  But you shouldn't say you looked into that patient's files and didn't find X; in fact, you shouldn't even acknowledge that the poster is your patient.

Yes, it's unfair.  Yes, the provider's hands are tied.  But that's the way it goes.

Jeff [3:32 PM]

[ Tuesday, May 24, 2016 ]

 

Symantec's Tactical Cyber Security Checklist: this is good advice and easy to do.

Jeff [11:05 AM]

 

Good News for Data Breach Defendants: a Pennsylvania appeals court has upheld a trial court's determination that the class action route is inappropriate for litigation regarding data breaches.  The claims are too individual, particularly where damages are so uncertain and hard to define.  

Jeff [9:56 AM]

[ Monday, May 23, 2016 ]

 

Often mentioned possibility comes to fruition: Kansas Heart Hospital got hit by a ransomware attack last week and paid the ransom to get their data back.  The hackers returned for a second bite, but this time the hospital is not paying.  Presumably "baby got backups."

Actually, this is not a re-encryption, but rather a refusal to give up the full decryption in response to the payment of the ransom

I've heard of this as a possibility, but this is the first time I've heard of a healthcare provider getting hit with a second ransom demand.  In every other incident I'm aware of, the hackers did provide the encryption key.  Of course, in some instances, not all of the data is recoverable; the process of encryption might overflow usable memory, so that the decrypted data is corrupted or incomplete, so even if the hackers give the correct key (or all the correct keys), it's possible some data would be lost. In this case, it sounds like the hackers intended to go for a second bite.

This is the example, though, that should make you think long and hard about paying the ransom, even if it's relatively small.

Jeff [1:27 PM]

[ Wednesday, April 27, 2016 ]

 


FAQ: WTF? Sorry, @HHSOCR, this FAQ is a thousand times wrong.  NOTHING in HIPAA prevents a covered entity from allowing a media company from accessing PHI, as long as the use or disclosure in connection with that access is permitted by HIPAA.  And nothing at all prohibits a covered entity (or a media company working on its behalf) from disclosing truly de-identified PHI (which, by definition, IS NOT PHI!!).

You can argue about whether it's truly de-identified; that's a fair argument.  But there is no such blanket prohibition in HIPAA to support the statements in the FAQ.

Of course, you could draft a regulation to just that.  But that requires actually following the law and the Administrative Procedures Act, publishing a proposed regulation, soliciting, receiving, and considering public comment, and publishing a final regulation.  Sure, it's more work than firing off an FAQ.  But it's the law.  It's the way law is made.

Executive fiat is anathema to the American concept of government.  Stop it.

Jeff [3:15 PM]

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