[ Friday, May 15, 2020 ]



Hello Mr. Drummond,

I've just read the COSMOS April Privacy Brief by Theresa Defino that cites comments from you regarding the press release issued March 24 on the OIG guidance allowing CEs to share lists of people exposed to or treated for covid with first responder dispatches.  Do you know how the recipients of this list will know when to take someone off the list, e.g. the person has been successfully treated for or otherwise cleared from covid?


The HIPAA rules and OCR’s guidance don’t address that at all (they also don’t require the disclosures to be made, just note that they are generally allowed in the current environment).  Thus, any removal or revisions to the list would likely come from the initial source of the list, whether it’s the governmental agency that compiles the overall list, usually a county health department in a large state or a state health department in a smaller or less populous state, but could be a hospital or health system that is the primary medical provider for a particular jurisdiction.

You make a good point, but it’s one that should be directed at the entities providing the lists or the dispatchers and first responders receiving and using the list – how do you know not to keep treating people who have recovered as if they were still sick?

As I noted in my comments to Theresa, it would be better if the list were kept by the covered entity (and available 24/7/365) and the dispatchers simply contacted the list creator and asked each time they were dispatched to deal with a particular person or a particular residential address.  That might not be practical.

Jeff [5:03 PM]

[ Tuesday, May 12, 2020 ]


In the right circumstances, yes.  The Faegere Drinker health law group has a good explainer here, but the key elements are:

  • Patient gives consent. At the time of service, health care providers can obtain written consent from the patient authorizing the release of COVID-19 testing results directly to his or her employer. Unlike other treatment situations, a health care provider may even condition the performance of an employee test on the employee’s provision of an authorization (i.e., the provider may refuse to perform the exam unless the patient executes a valid authorization). See 45 CFR § 164.508(b)(4)(iii).
  • Testing falls under HIPAA’s workplace medical surveillance exception. Health care providers may disclose health screening results directly to an individual’s employer when the service was provided at the employer’s request, and the employer needs the information to comply with legal obligations related to workplace health monitoring. The health care provider must provide the individual with written notice that the information will be disclosed to his employer at the time of the service and must limit the disclosure to the findings regarding the medical surveillance at issue. See 45 CFR 164.512(b)(1)(v).
  • Testing paid for by employer. If the employer subsidizes COVID-19 testing for its employees, the employer may be entitled to information regarding the specific employees the provider tested and when the testing was conducted. However, this would not entitle the employer to the results of the testing.

Jeff [2:10 PM]


I've been quoted several times by the media about the recent OCR guidance on allowing covered entities to provide Covid-19 infection information to first responders.  There was an article this morning about the state of Tennessee, and its efforts to notify law enforcement agencies of the identity of Covid-19 patients.

Given OCR's recent guidance, I would say that the governors program (providing names of all Covid-19 patients to police agencies that enter into a memorandum of understanding with the state) is likely permitted under HIPAA (I'm assuming the MoU requires some level of privacy protection, and the program is otherwise reasonable).

As I've stated elsewhere, I think a blanket sharing of PHI with first responders is too loose a standard.  In my opinion, if the whole list of individuals is shared, it should only be shared with dispatchers, who should use the information to inform first responders who are about to contact the infected individual.  I would prefer that the state health department, which keeps the list of reported positive tests, initiate a hotline for first responders (preferrably dispatchers, but possibly even officers themselves if necessary); that way, the information is filtered by a smaller universe of recipients.  That's not a cure in and of itself, but in my opinion it's more reasonable, and therefore the preferable option.

UPDATE: I said I was quoted several times, but in case you want a more fulsome explanation of how I think you should proceed, check out this article by the inestimable Theresa Defino.

Update 2: If I was a Knoxville cop, I'd be wondering if the mayor has my back.  How about, instead of taking good information away from your force, setting up a system within your force to make sure the information is only used for good?  It's one thing to say, "the state shouldn't be distributing the data the way it is because someone may misuse it," but this is basically saying "don't give it to us because WE will misuse it."

Jeff [1:26 PM]


I keep getting this question: during the course of the pandemic, hasn't OCR revised HIPAA to allow a lot of different uses and disclosures that were not permitted before?

The answer is No. 

What has OCR done?  Well . . . 

So, basically there have been 7 different announcements (addressing 6 topics) from HHS/OCR about HIPAA since the pandemic began.  [There was actually one earlier but it was very limited in scope (waiver of penalties against hospitals that don’t get NoPP’s out in time and other niceties because they are in emergency mode operations, but the relief is only good for 72 hours.  That one’s pretty useless and pretty much forgotten.]

Anyway, the announcements were:
  1.        Enforcement discretion for providers who use Skype/FaceTime during the pandemic
  2.       Guidance (FAQs) about the Skype/FaceTime enforcement discretion rules
  3.        Guidance to help first responders get PHI about infected individuals
  4.        Bulletin on existing Civil Rights Laws and HIPAA flexibilities
  5.        Enforcement discretion to allow BAs to directly disclose PHI to public health authorities
  6.        Enforcement discretion for community-based testing sites during the pandemic
  7.        Guidance on restrictions on providers granting media access to their facilities

The first 2 deal with providers being able to use non-public-facing apps to conduct remote audio-video patient treatment encounters. #3 clarifies how HIPAA allows covered entities to disclose PHI to first responders, and the data-sensitive ways to do so.  #4 makes clear that covered entities and others can’t discriminate in the provision of healthcare based on Covid-19 status.  #5 allows business associates to disclose PHI to public health authorities and health oversight agencies (covered entities can do so, but the pathway for doing so is less clear for business associates) and #6 states that OCR will not punish covered entities that run testing sites if those sites are not as data-protective as a regular office setting.  #7 is designed to remind covered entities of the several prior HIPAA enforcement actions against hospitals that allowed reality-TV film crews onto their premises; the pandemic is newsworthy, and video of crowded hospital hallways is compelling, but patients who might be identified in the video still have privacy rights.

Note that none of these are revisions to HIPAA, new regulations, or anything of the sort.  They are either enforcement discretion or guidance; the "guidance" is just explaining the rules, and the "enforcement discretion" is just saying that OCR will grant covered entities the benefit of the doubt if they act in good faith in a way that might have been questionable (but not necessarily illegal) in “ordinary” times.  For example, in ordinary times a healthcare clinic would not run a testing center in its parking lot, where the general public can see who is in the car and read license plate numbers, due to privacy concerns; however, it would not be a violation of HIPAA if doing so were otherwise reasonable, such as in an extreme situation, in a restricted-access area, or where other privacy protections could be put in place.  

None of this changes a single word of HIPAA.  Rather, all of these pronouncements are instances of OCR pointing out the flexibility and reasonableness of HIPAA, and how it allows for different levels of protection when circumstances change; what is not reasonable in ordinary times may be reasonable during a pandemic.  Because there may be confusion, and covered entities may put such a great (and unreasonable) emphasis on privacy that effective patient care is compromised, OCR is attempting to put minds at ease and allow less-protective actions in extraordinary conditions.

OCR would not call these actions a relaxation of standards or a change in the rules.  Rather, what OCR has offered is a clarification that the same standards as before apply (i.e., reasonableness), but that the current pandemic conditions present a different set of conditions, such that actions and operations that would be unreasonable in ordinary circumstances might be reasonable during these extraordinary circumstances.  HIPAA has not changed; it is exactly the same, and in fact was designed to remain the same in changing circumstances.  When the circumstances change, the definition of reasonable changes. 

Jeff [1:04 PM]

[ Wednesday, April 22, 2020 ]


New article on Zoom and HIPAA.  Fairly accurate but a little alarmist.  And once again, encryption is NOT REQUIRED to be HIPAA compliant; you should always consider encryption in every situation involving data in motion or at rest, but it's merely an addressable standard, not a required one.  

Jeff [8:33 AM]

[ Monday, April 20, 2020 ]


Actually, these are good ideas for everyone.  #3 is probably the most important -- the rest end up being part of your plan.

Jeff [2:55 PM]

[ Friday, April 03, 2020 ]


More OCR flexibility.  Again, it's enforcement discretion, which means there's no change in the law or regulations, but OCR is granting business associates the same flexibility that covered entities have to disclose for public health and health oversight activities.  Covered entities may disclose PHI without patient authorization to state epidemiology agencies for public health purposes, pursuant to 45 CFR 164.512(b)(1)(i); however, the regs don't give the same authority to business associates.

Instead, the business associate must abide by the terms of their business associate agreements, which may or may not allow such a disclosure.  Almost all BAAs will allow the BA to disclose where "required by law," but some epidemiological disclosures are not technically required: for example, many states require doctors, nurses, educators and certain others to disclose suspected abuse, and allow but do not require the general public to make similar disclosures.  If the disclosure to state infection control officials is permitted but not required, and the BAA allows only "required" disclosures, then the BA must refrain from making the disclosure.

Some BAAs say that the BA may disclose where "permitted or required;" in that case, the BA would be able to report to state health officials.

Ultimately, this is a small-potatoes fix, but it does point out two important things.  First, an interesting factoid to keep in mind about the HIPAA regs: while the HITECH act did incorporate BAs directly into HIPAA in many ways, there still are differences between CEs and BAs, and you have to read the specific language of the regulations carefully (obviously, OCR is reading it carefully).  Secondly, since BAs have fewer rights and less flexibility with respect to uses and disclosures of PHI, ultimately the BA can only do what the BAA allows.  So the language of the BAA really does make a difference.

Keep this in mind, and stay safe out there.

Jeff [12:12 PM]

[ Thursday, April 02, 2020 ]


While we're all focused on the novel coronavirus that causes Covid-19, do not lose focus on the general blocking and tackling of data security.  Microsoft has taken the remarkable step of actually warning some large hospital systems that they are severely at risk of a ransomware attack, mainly due to bad patching of vulnerabilities in gateways and access points such as VPN networks and VPN-connected devices. 

As more data use become remote, new data transmission highways develop, and whenever there is change, there are new and unknown vulnerabilities that could be exploited.

Do not fall down on the job of patching software ASAP, constant vigilance to data security needs and changing equipment or patters of use, regular backups, penetration and phish testing, and training of staff.  When staff change work patterns (like working from home), they may be less vigilant, and need more reminders.

Be safe out there.  Wash your hands and practice social distancing, but don't forget to keep up your defenses of the other viruses that were there before.

Jeff [12:36 PM]

[ Friday, March 27, 2020 ]


Zoom: Seems like everyone's using Zoom these days.  One thing to be aware of, though, with respect to the free Zoom service: as Consumer Reports points out, their terms of service allow them to use a lot of the information you transmit, particularly if you use the free or low-cost service.  (As always, if a service is free, the service isn't the product, you/your information is).

That doesn't mean they are doing so, just that they could use an attendee list, or even a video, powerpoint or document transmitted on the service to do targeted marketing, or potentially to sell to third parties.  Zoom hasn't responded to Consumer Reports, though.

This highlights two things: think about the services your are using that get to view your information and find out what they can do with it (especially find out if they are actually doing it or deny doing it, even though they have the right to).  And make sure you get a BAA if (i) you are a covered entity under HIPAA and (ii) any of the information that the service comes into contact with might be PHI.

I've looked at Zoom's BAA.  It's ok ("meh").  Doxy.me has a much better one.  But both are minimally sufficient.

UPDATE: one other thing: be the host, if you are the CE.  The host gets to keep data too; that's not a terrible idea, and if the host was in the meeting the host had access to that information, at least at the time of the meeting, so having it later isn't a whole new thing.  But it's like recording a call: don't be surprised later that the meeting host has what amounts to perfect memory.  And if you are the host, be aware of where the recording is stored and transmitted, and how it's used; if it's a telehealth visit, it's PHI, so it should be stored like any other medical record (encrypted at rest and in transit, hopefully).

Jeff [12:44 PM]

[ Friday, March 20, 2020 ]


OCR issues the FAQs to flesh out its bulletin on enforcement discretion for uses of Skype and related apps.  One thing to keep in mind: OCR isn't saying use of these apps doesn't violate HIPAA (they're also not saying it does, and people who categorically say that using Skype and FaceTime in any situation violates HIPAA, no matter what, are incorrect); use of those less-than-perfectly-secure apps, when there are safer, more secure apps that could be used without any adverse effect, may well violate HIPAA in most cases, even now.  What they are saying is that OCR won't levy fines if you use those apps during this time of crisis.

Other high points:

Jeff [10:31 PM]

[ Tuesday, March 17, 2020 ]


This news came via email from the Office for Civil Rights, the HIPAA enforcement agency, to the OS OCR PrivacyList email group, and is not in the form of posted guidance yet (as far as I can tell). But providers may use "Apple FaceTime, Facebook Messenger video chat, Google Hangouts video, or Skype to provide telehealth without risk that OCR might seek to impose a penalty for noncompliance . . . related to the good faith provision of telehealth during the COVID-19 nationwide public health emergency."

Providers should:

Full text of the email follows.  And watch this blog for further discussion and analysis of HIPAA in times of Coronavirus.

March 17, 2020
Notification of Enforcement Discretion for Telehealth Remote Communications during the COVID-19 Nationwide Public Health Emergency

We are empowering medical providers to serve patients wherever they are during this national public health emergency. We are especially concerned about reaching those most at risk, including older persons and persons with disabilities. – Roger Severino, OCR Director.
The Office for Civil Rights (OCR) at the Department of Health and Human Services (HHS) is responsible for enforcing certain regulations issued under the Health Insurance Portability and Accountability Act of 1996 (HIPAA), as amended by the Health Information Technology for Economic and Clinical Health (HITECH) Act, to protect the privacy and security of protected health information, namely the HIPAA Privacy, Security and Breach Notification Rules (the HIPAA Rules). 
During the COVID-19 national emergency, which also constitutes a nationwide public health emergency, covered health care providers subject to the HIPAA Rules may seek to communicate with patients, and provide telehealth services, through remote communications technologies.  Some of these technologies, and the manner in which they are used by HIPAA covered health care providers, may not fully comply with the requirements of the HIPAA Rules. 
OCR will exercise its enforcement discretion and will not impose penalties for noncompliance with the regulatory requirements under the HIPAA Rules against covered health care providers in connection with the good faith provision of telehealth during the COVID-19 nationwide public health emergency.  This notification is effective immediately. 
A covered health care provider that wants to use audio or video communication technology to provide telehealth to patients during the COVID-19 nationwide public health emergency can use any non-public facing remote communication product that is available to communicate with patients.  OCR is exercising its enforcement discretion to not impose penalties for noncompliance with the HIPAA Rules in connection with the good faith provision of telehealth using such non-public facing audio or video communication products during the COVID-19 nationwide public health emergency.  This exercise of discretion applies to telehealth provided for any reason, regardless of whether the telehealth service is related to the diagnosis and treatment of health conditions related to COVID-19.
For example, a covered health care provider in the exercise of their professional judgement may request to examine a patient exhibiting COVID- 19 symptoms, using a video chat application connecting the provider’s or patient’s phone or desktop computer in order to assess a greater number of patients while limiting the risk of infection of other persons who would be exposed from an in-person consultation.  Likewise, a covered health care provider may provide similar telehealth services in the exercise of their professional judgment to assess or treat any other medical condition, even if not related to COVID-19, such as a sprained ankle, dental consultation or psychological evaluation, or other conditions. 
Under this Notice, covered health care providers may use popular applications that allow for video chats, including Apple FaceTime, Facebook Messenger video chat, Google Hangouts video, or Skype, to provide telehealth without risk that OCR might seek to impose a penalty for noncompliance with the HIPAA Rules related to the good faith provision of telehealth during the COVID-19 nationwide public health emergency.  Providers are encouraged to notify patients that these third-party applications potentially introduce privacy risks, and providers should enable all available encryption and privacy modes when using such applications. 
Under this Notice, however, Facebook Live, Twitch, TikTok, and similar video communication applications are public facing, and should not be used in the provision of telehealth by covered health care providers.
Covered health care providers that seek additional privacy protections for telehealth while using video communication products should provide such services through technology vendors that are HIPAA compliant and will enter into HIPAA business associate agreements (BAAs) in connection with the provision of their video communication products.  The list below includes some vendors that represent that they provide HIPAA-compliant video communication products and that they will enter into a HIPAA BAA.
  • Skype for Business
  • Updox
  • VSee
  • Zoom for Healthcare
  • Doxy.me
  • Google G Suite Hangouts Meet
Note: OCR has not reviewed the BAAs offered by these vendors, and this list does not constitute an endorsement, certification, or recommendation of specific technology, software, applications, or products. There may be other technology vendors that offer HIPAA-compliant video communication products that will enter into a HIPAA BAA with a covered entity.  Further, OCR does not endorse any of the applications that allow for video chats listed above.
Under this Notice, however, OCR will not impose penalties against covered health care providers for the lack of a BAA with video communication vendors or any other noncompliance with the HIPAA Rules that relates to the good faith provision of telehealth services during the COVID-19 nationwide public health emergency. 
OCR has published a bulletin advising covered entities of further flexibilities available to them as well as obligations that remain in effect under HIPAA as they respond to crises or emergencies at https://www.hhs.gov/sites/default/files/february-2020-hipaa-and-novel-coronavirus.pdf - PDF.
Additional information about HIPAA Security Rule safeguards is available at https://www.hhs.gov/hipaa/for-professionals/security/guidance/index.html.
HealthIT.gov has technical assistance on telehealth at https://www.healthit.gov/telehealth. 

UPDATE: Here's a link to the actual announcement

Jeff [7:22 PM]


So, you've probably heard that HHS was hit by a cyber-attack intended to disrupt and slow down its operations; if it can happen to them, it can certainly happen to you.

It's extremely likely that your organization has implemented at least some unusual operating conditions.  Even if you are business as usual, your employees and workforce are more worried, and may not be as focused as they usually are on privacy and security.  Specifically, your workforce members are probably receiving more emails than usual, and are definitely more likely now to open an email or click on a link that sounds important or scary than they were a couple of months ago.  Hackers know that, and they don't care that there's an epidemic (they never let a crisis go to waste).  So now would be a good time to remind your staff to be extra vigilant to phishing efforts.  But it's not just ransomware; remind them to practice all of your data privacy and security hygiene measures.

Risks and threats are elevated in unusual times, and clearly we are in unusual times.  We are living through a "Black Swan" event.  Be extra careful out there.

Jeff [12:20 PM]

[ Monday, March 16, 2020 ]


Specifically, the Secretary of HHS will:
"waive sanctions and penalties arising from noncompliance with the following provisions of the HIPAA privacy regulations:  (a) the requirements to obtain a patient’s agreement to speak with family members or friends or to honor a patient’s request to opt out of the facility directory (as set forth in 45 C.F.R. § 164.510); (b) the requirement to distribute a notice of privacy practices (as set forth in 45 C.F.R. § 164.520); and (c) the patient’s right to request privacy restrictions or confidential communications (as set forth in 45 C.F.R. § 164.522); but in each case, only with respect to hospitals in the designated geographic area that have hospital disaster protocols in operation during the time the waiver is in effect."

Basically, HIPAA is still fully operational during this emergency.  However, there's a little flexibility with respect to issues involving notifying friends and family members (in an emergency, you don't want sick people unaccounted for because the provider is afraid to reach out to family and friends of the ill individual), and if a covered entity fails to deliver a Notice of Privacy Practices in the frantic rush to care for people in an epidemic, OCR will forgive that sin. 

However, the rest of HIPAA is still in effect as before.  But that's OK, because, as you'll learn more from me soon (watch this space), one of the beauties of HIPAA is that is operationally flexible and based on a rule of reason, so that it works equally well in fair weather or foul.

Like I said, more to come.

UPDATE: HHS has now issued a bulletin specific to HIPAA (the prior one referenced EMTALA and several other federal laws and regulations).  Again they note the same provisions (splitting the first and third into 2 parts):
• the requirements to obtain a patient's agreement to speak with family members or friends involved in the patient’s care. See 45 CFR 164.510(b).
• the requirement to honor a request to opt out of the facility directory. See 45 CFR 164.510(a).
• the requirement to distribute a notice of privacy practices. See 45 CFR 164.520.
• the patient's right to request privacy restrictions. See 45 CFR 164.522(a).
• the patient's right to request confidential communications. See 45 CFR 164.522(b)

The bulletin also adds specific limited circumstances when the provisions are waived: "only (1) in the emergency area identified in the public health emergency declaration; (2) to hospitals that have instituted a disaster protocol; and (3) for up to 72 hours from the time the hospital implements its disaster protocol."

More importantly, they point out a lot of the ways HIPAA continues to work, and how to make it work in these unique times (more specifically, they point out when HIPAA otherwise permits covered entities and business associates to disclose PHI).  Read the bulletin for more information.

Jeff [7:52 PM]

[ Friday, March 13, 2020 ]


Slightly off-topic, but HIPAA (the healthcare privacy silo) occasionally runs up against FERPA (the education privacy silo), so I thought some of you might be interested in seeing how the US Department of Education is advising stakeholders about student privacy in the age of Coronavirus.  

Jeff [3:45 PM]

[ Wednesday, March 04, 2020 ]


Quest settled a class action lawsuit against them for a data breach caused by an outside bad actor.  The settlement was less than $200,000, so I'm sure it made financial sense to settle.  But I think this will help feed the class action breach business, which is just bad law when there are no actual damages.  Nobody could show how the accessed data was improperly used, much less any damage anyone actually suffered.  Lots of class action cases are solely about attorneys' fees.

Jeff [8:56 AM]


This has nothing to do with HIPAA.  Drug companies are using NON-MEDICAL information to target people who MIGHT be the appropriate target market for their drugs.  HIPAA is not implicated, not in the least.  Get a grip.  

Jeff [8:48 AM]

[ Monday, March 02, 2020 ]


Harris Health System, the Houston-area public health system, can't find a couple pages of paper documents with patient information on them.  No telling what happened -- the pages disappeared while in route from one facility to another.  This happens from time to time.

Harris did the right thing -- notified everyone potentially affected, all 2,300.

This is also why you shouldn't freak out about every reported breach.  Some are out of an abundance of caution.  There's a 99.9% chance that no PHI got out to the "bad guys," but reporting requirements are such that, that's still considered a breach. 

Jeff [8:59 AM]

[ Wednesday, February 19, 2020 ]


Adding Insult to Injury: As @PogoWasRight noted over the weekend at databreaches.net, class action lawsuits have been filed against Hackensack Meridian Health due to the fact that HMH got hit by ransomware.  The hospitals had to delay and reschedule non-emergency procedures.  No emergency patients were denied care, and no inpatients were harmed by the attack.  It's not even clear if the ransomware event resulted in data exfiltration; the fact that the hospital system has not reported the incident to HHS or notified patients leads me to believe there was no exfiltration.

(Despite OCR's claim that any ransomware attack is a reportable breach, the regulations do not support that interpretation.  Unless there is "an acquisition, access, use or disclosure of protected health information in a manner not permitted" by HIPAA, there is no breach.  A third party encrypting your data isn't what you want to have happen, but data encryption is, in fact, permitted by HIPAA (in fact, it's encouraged).  So the fact of the encryption is not a breach; it's only a breach if, in addition to the encryption, there's an acquisition, access, use or disclosure that's not permitted, which basically means it has to get out.  Some current ransomware versions to take data outside the attacked system, so the hackers can also sell the data in addition to collecting the ransom for decrypting it; in those cases, the ransomware attack is a breach because it meets the definition.  Where there is no exfiltration, the incident likely doesn't.

This is idiotic, and these lawyers really should be ashamed of themselves.  Third-party bad actors attacked HMH's network and caused a huge disruption.  There's no evidence at all of any fault or blame on the part of HMH; ransomware attacks are pretty common, some phishing techniques are pretty clever, and there's no such thing as perfect data security.  But more importantly, nobody was hurt.  What damages did these plaintiffs suffer? 

Jeff [8:25 AM]

[ Wednesday, February 05, 2020 ]


United Healthcare announced a breach into a patient portal that exposed name, plan information, and health data; however, only 36 people affected (I'm surprised this made the news, given the low numbers).  

Jeff [6:16 PM]


1. Ransomware: Many companies who are hit by ransomware don't pay the ransom and their data is deleted.  In the old days, that was the end of the story.  Now, some ransomware variants (the currently popular Maze, for example) will actually steal the data, not just encrypt it.  It seems that some of those ransomware hackers are punishing the non-ransom-paying victims by publishing and/or selling the data they have stolen. Of course, there are some healthcare entities in the mix; obviously, they might have some HIPAA reporting obligations. . . .

2. More Ransomware: Of course, even if your ransomware attack doesn't steal your data, if you don't pay the ransom (and sometimes even when you do) by the deadline and the decryption key is deleted, the data is lost forever.  That's apparently the case with Fondren Orthopedic in Houston, and some others as well.

3. Texting and HIPAA: This isn't a good mix from a HIPAA perspective for a couple of reasons, but it's not actually prohibited.  And for some patients, texting is their preferred, if not only, effective means of receiving communications from their providers.  When the rules aren't clear, what's a provider to do?  One option is to ask HHS to provide some guidance, and that's what some are doing. We will see if there's a response. . . .

Jeff [1:31 PM]

[ Tuesday, January 14, 2020 ]


Buck, a HR/benefits consultancy, has just completed a survey of HIPAA compliance among company health plans, and the results are not surprising to those of us in the space.  Big problems with conducting risk assessments, ensuring business associate agreements are in place, regular employee training, and adopting and reviewing policies and procedures keep popping up.  There's a solid one half to two thirds that show good, consistent compliance; and this is employee health plans, not entities that are HIPAA covered entities by virtue of being in the healthcare business, so some slippage is to be expected (at least I hope the healthcare industry participants are better than this).  But given that compliance really isn't that hard, it's still distressing. 

Jeff [12:05 PM]

[ Thursday, January 02, 2020 ]


Sinai Health System in Chicago apparently suffered an email system compromise that exposed PHI of about 13,000 people.  Probably a phishing exercise that got through.  

Jeff [12:54 PM]


OCR has fined West Georgia Ambulance $65,000 for a breach involving a lost unencrypted laptop.  Of course, the real reason for the fine is that the company had failed to do a risk analysis and take other basic HIPAA hygiene steps (which, had they done so, might've led them to encrypt the laptop, which would have mooted this entire episode).

Of particular interest here is the relatively small size of the fine; I suspect that West Georgia couldn't afford more, so this probably stings pretty badly.  But that's the point, and I applaud OCR for the apparent reasonableness of the fine.  In my opinion, they should issue more smaller fines, rather than just a few big ones.  That's more likely to get people into compliance.  

Jeff [12:51 PM]

[ Friday, December 27, 2019 ]


This includes both healthcare and non-healthcare breaches, but it's . . . extensive.  More than just the wall of shame.

Jeff [2:42 PM]

[ Monday, December 23, 2019 ]


I'm cleaning out some old emails this morning, and don't think I posted these things previously:

Elite Dental: this Dallas dental practice responded to Yelp reviews in a way that exposed PHI.  The fact that the patient already posted, or that the PHI is already public knowledge, does not relieve the provider of his/her/its HIPAA obligations, and posting on Yelp, even truthfully and even if the original poster was lying, is still a HIPAA violation.  Thus, be very careful with your social media activities.

Korunda Medical: OCR's second fine for failure to respect the patient's right to access PHI.  The big problem for Korunda is that when first contacted, OCR provided them with assistance to fix the problem, but Korunda kept failing to transfer this patient's records.  This follows the Bayfront case back in September. Like Bayfront, the fine is small; access failures aren't an endemic problem, but in egregious cases they do deserve to be made into an example. 

Sentara: Failure to notify of a breach.

Jeff [8:48 AM]

[ Thursday, December 19, 2019 ]


Obviously, HIPAA and FERPA intersect: they are both privacy laws, but one applies to educational entities and the other to healthcare entities.  But, perhaps obviously, there's an overlap.  Well, both OCR and the Department of Education occasionally release joint guidelines about how to deal with that intersection, and they did so today.  You can view it here.  Nothing earth-shattering, but if you regularly deal with the intersection of medical records and educational records, you'll find this of interest.  

Jeff [9:38 PM]

[ Thursday, December 12, 2019 ]


November saw 29 HIPAA breaches affecting a little over half a million individuals, which is the lowest month this year.  Are we getting better, or just happenstance?  Are the outside threats focusing more on ransomware, due to its higher profit potential, or are health industry participants getting better?

Jeff [10:16 AM]

[ Monday, November 25, 2019 ]


HIPAA Fine for Lack of Prompt Access.  While cleaning out my email inbox I realized that I never blogged about this case.  Bayfront Health failed to grant a mother timely access to PHI about her unborn child (hmm, this is interesting -- I would've thought prenatal records would be the mother's records, not the child's . . . ), and in fact only provided the records 9 months after the request, rather than within the 30 days required by HIPAA.  

One of the rights HIPAA explicitly grants to individuals is the right to access their own data; in this case, the mother, as personal representative of her child, could exercise that right.  

The press release doesn't state why Bayfront was slow to provide access, but it couldn't have been too bad a reason, since the fine was only $85,000, which is pretty small by OCR standards.

Jeff [11:32 AM]

[ Thursday, November 21, 2019 ]


Ransomware.  It's not just the US health system under attack -- everyone can be hit with ransomware.  This time it was a French hospital.  

Jeff [8:40 AM]

[ Sunday, November 10, 2019 ]


Governmental Entities Aren't Immune from HIPAA Violations and Fines: OCR has just fined the Texas Health and Human Services Commission $1,600,000 because the Department of Aging and Disability Services failed to conduct an enterprise-wide risk analysis, which OCR believes would have prevented DADS from exporting data to a public server that, because of a software flaw, allowed the general public to see the PHI of about 7,000 people receiving services from DADS.  

Jeff [2:24 PM]

[ Wednesday, November 06, 2019 ]


URMC: University of Rochester Medical Center fined $3,000,000 for failure to encrypt a laptop that was stolen in 2017 and a flash drive that was lost in 2013.  That seems like an extreme fine, but there's more to the story.  In 2010, URMC also lost an unencrypted flash drive.  OCR did an investigation and, instead of fining them, gave them technical assistance, which undoubtedly included a plan to encrypt all portable devices.  Obviously, URMC didn't take the assistance and the encryption plan to heart.  The settlement agreement is here

Encryption is an addressable Security Rule standard, not a required one.  However, encryption is close to being an industry standard; if you aren't using it, at least for portable devices, you better have a good explanation of why.  Not just for the regulators, but for your constituents, your principals, and your patients: if URMC had encrypted that flash drive and laptop, they never would have to have reported the losses to OCR, there would have been no investigation, and there would have been no fine.  

Jeff [7:36 AM]

[ Saturday, October 26, 2019 ]


Jackson Health gets popped for $2.15 million.  OCR report is here.  

Jeff [2:43 PM]

[ Wednesday, October 23, 2019 ]


Looks like a phishing scheme attacking the email network at Kalispell Regional system in Montana might've exposed 130,000 patients' data.

Jeff [1:45 PM]

[ Wednesday, October 02, 2019 ]


Ransomware Attack on Alabama Hospital: DHC Health System facilities in Tuscaloosa, Northport and Fayette all diverting new patients while EMR and other systems were down. 

Jeff [8:32 AM]

[ Monday, September 23, 2019 ]


The following is a guest post by Liam Johnson, who is Editor-in-Chief of the website ComplianceHome.com.  Feel free to comment*, or discuss among yourselves.

*Comments are moderated and may not appear instantly.

Getting HIPAA Compliant in Google Cloud Platform

Is Google’s Cloud Platform HIPAA compliant? Likewise, is Google’s Cloud Platform ideal as an alternative to AWS and Azure for healthcare organizations? In this post, we are going to determine if Google’s Cloud Platform is HIPAA compliant, plus whether healthcare organizations can make use of it to host infrastructure, build applications and store files that contain protected health information.

Presently, the use of cloud platforms by healthcare organizations has increased tremendously, with the value of the healthcare cloud computing market being estimated to be $4.65 billion in 2016. This figure is expected to increase by 2022 to more than $14.76 billion.

Will Google Sign a Business Associate Agreement that covers its Cloud Platform?
The Omnibus Rule came into effect on September 2013, and ever since, Google started signing Business Associate Agreements (BAAs) with HIPAA covered entities for G-Suite. Consequently, Google expanded its BAA to include the Google Cloud Platform.

Currently, Google’s BAA covers majority of the cloud services such as Cloud Storage, Compute Engine, Cloud SQL for PostgreSQL, Cloud SQL for MySQL, Container Registry, Kubernetes Engine, BigQuery, Cloud Dataproc, Cloud Translation API, Cloud Pub/Sub, Cloud Bigtable, Cloud Dataflow, Stackdriver Logging, Cloud Speech API, Genomics, Cloud Machine Learning Engine, Cloud Datalab, Stackdriver Debugger, Stackdriver Trace, Stackdriver Error Reporting, Cloud Data Loss Prevention API, Cloud Natural Language, Cloud Load Balancing, Google App Engine, Cloud Vision API, Cloud Spanner and Cloud VPN.

In 2016, Google partnered with the backend mobile service provider Kinvey, subsequently leading to the availability of mBaaS on Google Cloud. Connectors to electronic health record systems that support healthcare apps are integrated into mBaaS.

Is the Google Cloud Platform HIPAA Complaint?
Since Google will sign a BAA with all HIPAA covered entities, does this mean that its Google Cloud Platform is HIPAA compliant?

HIPAA has one overarching requirement, and that is the BAA. It usually means that the data and security protection mechanisms of Google have been assessed and deemed to have surpassed the minimum requirement of the HIPAA Security Rule. Additionally, it means the cloud services Google offers meet the Privacy Rule requirements, and Google understands its responsibilities as HIPAA’s business associate. Thus, it agrees to offer HIPAA-compliant and secure infrastructure for the processing and storage of Personal Health Information (PHI).
Nevertheless, it is the mandate of the healthcare establishments to safeguard all the HIPAA rules when using the Google Cloud Platform is being followed. Likewise, they should ensure their cloud-based applications and infrastructure are configured and secured correctly.

The covered entities are given the duty to disable any Google services which the business associate agreement does not cover, control the set up to avoid accidental deletion of data, ensure access controls are implemented carefully, audit logs are checked regularly and all audit log export destinations are set. Moreover, care must be taken when uploading any PHI to the cloud to safeguard it is adequately secured, plus the PHI is not shared with unauthorized persons accidentally.

Jeff [4:34 PM]


A friend at Stroz Friedberg (a part of Aon) let me know a few months ago that they are seeing a particular uptick in ransomware affecting law practices, but really it's a problem across all industries.  As noted from the news out of Wyoming earlier today, ransomware is a particularly big problem in the healthcare industry. 

I thought I'd post through what my friend sent, with her permission.  But I'd also like to point out the "big 4" words of advice to prevent ransomware or minimize its impact.
1. Patch software regularly.  Most malware exploits a vulnerability that has been reported and for which a patch is available.  You can't always patch immediately, but do so on a regular basis.
2. Practice good backup management.  Having a perfect backup is the golden ticket for defeating ransomware: simply remove the encrypted content and replace with the backup.  Modern ransomware variants typically seek-and-encrypt backup files, as well as data files.  If your backup files are accessible on the same system, you could lose them too.  Multiple serial backup versions, stored offsite, will speed recovery and save you the ransom payment.
3. Map your systems and remove unnecessary connectivity. It's better if an isolated portion of your computing environment is encrypted and not the whole thing.  And you need to be able to find how the incident started to clean it up effectively.
4. Train and test your staff to recognize phishing attempts. The phishing attempt that isn't opened is the ransomware event you don't have and don't have to fix.

Anyway, here's the Aon report:


Over the past two weeks we have seen a significant uptick in ransomware attacks across all industries involving the Ryuk ransomware. The initial foothold is typically flagged as Emotet malware, and is usually delivered through a phishing email. The Emotet attacker then sells its deployment/footholds to a group using the Trickbot banking trojan. The "trick" refers to the various modules the malware can dynamically load to augment its abilities. It uses common vulnerabilities, such as EternalBlue, to spread rapidly throughout the victim’s environment. The Trickbot group then sells its wide access to a ransomware group, currently Ryuk (we have also observed Trickbot working with Bitpaymer). Once the Ryuk group gains access, they interactively move through the environment, spreading ransomware to encrypt files. They typically also go after backups in order to block recovery efforts, forcing the victim to pay the often sizeable ransom in order to restore mission-critical files and systems.

Mitigating Business Interruption

Clients should pay close attention to any anti-virus alerts from their endpoints, with particular sensitivity to alerts for Emotet/Trickbot since Ryuk or a similar ransomware is typically a fast follow to these.  In order to minimize the business impact of a ransomware infection, we recommend the following preventative measures:
§  Notify employees to be aware of suspicious emails.
§  Secure email platform account access - MFA, continual log review, etc.
§  Activate malware detection capabilities within mail gateways.
§  Remove the users’ ability to enable document macros.
§  Ensure AV is deployed to every machine and all alerts are being collected.
§  Follow-up on AV alerts.
§  Verify that network logs are being aggregated and reviewed for suspicious connections; Trickbot downloads its payload as a ".png" file.
§  Limit access and closely monitor admin and domain admin account usage.
§  Do not use shared local admin accounts and passwords across machines -- this is an easy way for Trickbot to spread.
§  Have a robust backup process for business critical servers and files such that back-ups occur regularly, are tested for efficacy, and are stored offline.

Getting Back to Business: Response and Recovery

§  Do not power down or reimage infected systems.  DO disconnect them from the network.
§  Preserve machines/logs and contact an IR provider.
§  Ensure the AV solution does not delete the accompanying "ransom notes" (usually .txt or .hta files) as these are typically used to store a unique code that is necessary to decrypt the files if payment is made.
§  Be on the lookout for other malicious software and persistence mechanisms as the Ryuk group may install their own malicious backdoors into the environment as their approach evolves.
§  Make a copy of online backups and store offline.  Alternatively, segregate online backups to prevent them from becoming encrypted or deleted by the attacker.
§  Do not discuss the ability or appetite to pay the ransom via email.

Jeff [4:19 PM]


Campbell County Health has been hit by a ransomware attack, resulting in diversion from the hospital's ER and cancelling of services.  

Jeff [3:08 PM]

[ Friday, September 20, 2019 ]


Privacy Rights of Minors.  Interested in knowing a little more about the privacy rights of minors?  Here's a webinar.  I might even be able to get you a discount. . . .

Jeff [8:22 AM]

[ Wednesday, August 28, 2019 ]


A concerted effort: Minnesota healthcare providers band together for cybersecurity protection.

Jeff [5:46 PM]


Mass General: apparently, some improper person got access to a Mass General research database containing information on 10,000 patients.  No SSN or other ID Theft treasure trove, but still a reportable HIPAA breach.  

Jeff [2:18 PM]


Presbyterian Healthcare (New Mexico) Data Breach: Looks like another email phishing attack, where an employee clicked a link on a phishing email and let an intruder into the hospital systems' data.  It does not look like EMRs were accessed, just email.  However, there can be a lot of PHI in an email system.

Jeff [2:14 PM]

[ Tuesday, August 27, 2019 ]


NY Dept of Health Issues Breach Notification Rules:  The Department has issued a letter to all licensed hospitals and other facilities outlining a new protocol that requires the facilities to notify the Department, along with other required notifications, of a potential cybersecurity incident.  So, in addition to OCR reporting (soon after the incident if it involves 500 or more persons, after year end for smaller breaches), reporting to affected individuals, and possibly reporting to credit reporting agencies and attorneys general, add a new recipient of the notice. 

Hmm.  OK, the Department argues that notifying them helps them spread the word and provide assistance to the victimized organization; that makes sense.

However, notification is required for cybersecurity incidents.  The notice says, "A cybersecurity incident is the attempted or successful unauthorized access, use, disclosure, modification, or destruction of data or interference with an information system operations."  Attempted?  That's problematic.  Must every port scan and firewall ping, which are "attempted" access to an information system, be reported?  That looks like the Security Incident definition in HIPAA, which is equally overbroad.

Hat tip: Jackson Lewis.

Jeff [11:23 AM]

[ Friday, August 23, 2019 ]


Part 2 Rule Changes Are Coming.  HHS issued a press release yesterday, along with a fact sheet, outlining some textual changes to 42 CFR Part 2.  The proposed rule was issued yesterday, but has not yet been published in the Federal Register; the rule will be open for comment for 60 days.  I was not able to locate a copy of the actual text of the rule; guess I'll have to wait for the Federal Register publication.

The Part 2 rules serve as a sort of "super-HIPAA" for federally-assisted substance abuse treatment centers.  Unlike HIPAA, which allows a HIPAA covered entity to disclose patient information for treatment, payment, or healthcare operations without the consent of the patient, Part 2 required the patient to specifically consent to the specific disclosure.  The rules currently indicate that the consent must indicate the exact recipient; stating that the recipients will be "healthcare providers involved in the patient's care" is insufficient, the Part 2 provider must say "Dr. Jones" or Dr. Smith."  The new rules will loosen up this requirements somewhat.

Part 2 also require that any disclosure contain an instruction to the recipient that the information remains subject to Part 2 and cannot be further disclosed.  HIPAA, on the other hand, operates under a "horse is out of the barn" structure, where once a disclosure is made to a non-HIPAA-covered entity, it may be further disclosed.  This concept in Part 2 isn't really changing, except that it's now clear that if a non-Part 2 provider develops medical records relating to a Part 2 patient that includes information from the Part 2 provider, as long as the non-Part 2 provider keeps the records separate, the Part 2 records don't subject all of the non-Part 2 provider's records to Part 2 restrictions. 

The new rules also expand the "emergency" exception to disclosure of Part 2 medical records.  As originally drafted, it was a medical emergency involving the patient that triggered the exception; now, if there's a declared emergency (like a hurricane), disclosure restrictions are loosened.  Other changes involve the ability of providers to disclose information to state prescription drug monitoring plans and looser rules for disclosures for research.

The AP article has a pretty good explanation of the impetus for the revisions, including an explanation of why Part 2 exists in the first place.  These changes are really nibbling at the edges and fixing specific issues.

Jeff [12:01 PM]

[ Monday, August 12, 2019 ]


Interesting article this morning out of Pennsylvania.  A patient has sued Lehigh Valley Memorial Hospital Network (LVHN, which is not LVMH, the luxury brand aggregator), alleging that a doctor on the staff who was not treating him, but with whom he had a business dispute, improperly accessed his medical records.  He's suing the hospital for failing to prevent the doctor from accessing his records.

This raises a number of issues and possible teaching points.

Access Restriction is Required Hospitals do have an obligation to restrict access to PHI to only those persons with a need to access it.  Sometimes this is easy -- an orderly or a maintenance worker shouldn't have access to PHI.  But sometimes it's tricky; a nurse should only have access to PHI of patients he/she sees and treats, but if the hospital prohibits access to patients' PHI other than those assigned to the nurse, and there's an emergency in another department and the nurse must fill in there, the nurse might not be able to access necessary PHI and the patient's health might suffer.  Likewise, doctors on staff should only access the PHI of their patients, but sometimes an emergency consult might be necessary.  A pediatrician would probably never provide care to a geriatric patient, but in many cases lines aren't easy to draw.

Thus, providers must consider whether they can restrict access up front via hard-wired solutions like permitting access only to a set list of patients (or classes of patients).  Often times, they can't, so they then need to set up some other sort of solution.  Usually, this involved a two-part solution: first, the parties seeking access (workforce members like nurses and schedulers, as well as non-employees such as staff physicians at a hospital) must be instructed and trained to only access the PHI of their own patients and never access PHI for which they don't have a permitted need (usually treatment, but possibly payment for accounts receivable or finance employees, and healthcare operations for QA/UR staff).  Secondly, the hospital or clinic then needs to have some mechanism to make sure people are doing what they are supposed to be doing, and not improperly accessing PHI.  This may involve random checks, regular checks, or the use of artificial intelligence or machine learning algorithms to identify potential problem access issues.  The hospital or clinic should then follow up with those whose access seems excessive, and determine if there is a legitimate need.  If not, they need to take follow-up actions with the access abusers -- more training, restricted access, or some sanction, up to and including termination for abusive snoopers.

In this case, the hospital may have been doing the right thing; many hospitals need to allow open access to all physician staff members, and if the hospital had proper training up front and post-access audit controls, it's not impossible that this improper access might have slipped through the cracks.  On the other hand, if the hospital did not train its employees, did not have policies in place regarding access by staff physicians, and did not reasonably audit to look for abusers and fix improper access problems, it may have violated HIPAA Privacy Rule requirement to restrict access.  If the access was to an electronic medical record, the hospital might also have violated the HIPAA Security Rule.

Improper Access May Be a Breach.  Once the hospital knew that the access was improper, it then knew there was a "breach of unsecured PHI," and then had an obligation to notify the patient.  If it did not do so without unreasonable delay (and in all cases withing 60 days of knowing of the breach), it violated the HIPAA Breach Notification Rule.

The doctor accused of improper access might also be liable here.  He apparently claims that he had a patient-provider relationship with the patient, in which case his access to the PHI might have been proper.  Even if he had a patient-provider relationship, that does not give him carte blanche to access the patient's PHI -- the access must still be for a permitted purpose such as treatment or payment (and if it's for payment, it must be limited to the reasonably necessary amount).

Don't Disclose PHI to the Press, Even if it is Already Disclosed I'd also note that both the hospital and the physician have (appropriately) not commented to the press on the matter, but their comments (acknowledging the patient was a patient is, in itself, a disclosure of PHI) were taken out of court filings; generally, disclosing PHI in a court record, where the disclosure is relevant to the litigation, is a permitted disclosure; it appears that the reporter pieced the case together from the court records.  The fact that the PHI is already out in the public record is irrelevant -- just ask Memorial Hermann in Houston. 

Even Unidentified Information Can Sometimes Be Used to Identify Someone It's not central to this particular story, but another interesting point here is that this case shows how de-identifying information is sometimes ineffective, if there are other sources of information that might be leveraged to cross-check and add in identifiers.  The Health Department didn't say who the patient was, but included the date of discharge, which the reporter was able to connect to the court filings.  It's not absolutely certain that the specific patient mentioned in the Health Department report is the plaintiff patient in the lawsuit, but it's pretty likely.

In Litigation, a QPO is Always an Option.  Often, when PHI is used in litigation, the individual who is subject of the PHI will seek to prevent his/her PHI from being in a public record, in order to keep his personal medical issues private.  This can be done with a Qualified Protective Order or QPO, as specifically mentioned in the HIPAA regulations relating to information disclosed subject to a subpoena.  Here, the information in the legal proceeding actually ended up being used by the press to the detriment of the hospital and physician.  I'm guessing that LVHN, and possibly Dr. Chung, are wishing they had used a QPO to protect some of that PHI.

Jeff [1:06 PM]

[ Friday, July 19, 2019 ]


As you should know, while HIPAA has pretty strict rules for most covered entities, those that provide services in the substance abuse arena are often subject to even more strict rules. Called the "Part 2 Rules" since they come from 42 CFR Part 2, they basically prohibit the disclosure of patient information by federally-supported substance abuse centers unless the patient gives specific consent for the particular disclosure. 

As with any privacy rules, the stricter the rules, the worse the utility of the data.  And in the substance abuse arena, allowing patient privacy serves a great good (patients won't be afraid to seek care due to the fear their addiction will be disclosed), but that same privacy can prevent programs from providing the help that patients need.  This can be particularly troubling in the face of the opioid epidemic.

HHS is proposing to revise those rules somewhat to allow better sharing of data between providers.  It will be interesting to see how it plays out; parties from both sides will be likely to weigh in.

Jeff [3:39 PM]

[ Wednesday, July 03, 2019 ]


Here are 6 things small providers could do better to get to better cybersecurity compliance.

Jeff [6:20 PM]

[ Monday, July 01, 2019 ]


Those "obsessed" with privacy (hey, obsession is in the eye of the beholder; one person's reasonable caution is another's obsession) know that if a digital service is "free," the service isn't the product to you; you are the service to the product's developer.  Google Maps is a free product, so it seems; actually, though, you are the product: when you use Google Maps, Google gathers data on you that is uses to sell other products to its customers.  If you don't care about privacy, it's a great deal: you give up privacy you don't want for a free map program.

But if you do care about privacy, what should you do?  Find less intrusive programs.  Some are free but some cost money, but that's what you have to do if you want to protect yourself. 

Anyway, if you're looking for alternatives to the non-private Google products, here's a list.  Think about it. . . . 

Jeff [2:42 PM]

[ Thursday, June 27, 2019 ]


OCR has published 2 new FAQs relating to when and how health plans may share PHI for care coordination with other plans serving the same individuals.  The first question actually alludes to one of the tricky elements of uses/disclosures that are for "health care operations" of a different covered entity: not all "operations" elements are acceptable in those situations.  Care coordination is one of the acceptable elements, though, so that's good.  The second question delves into when an entity can use PHI that it received for a different purpose to tell the individual about other products and services, without the communication being "marketing" (in which case the individual must authorize that use/disclosure).  

Jeff [10:14 AM]

[ Monday, June 24, 2019 ]


Two New York (Southern Tier, Allegany area) health care providers were hit by Ransomware last week.  No word on how the attacks occurred, but I'd guess both started with email phishing schemes.

Jeff [11:36 AM]

[ Wednesday, June 05, 2019 ]


Now, it's LabCorp.  Just days after Quest announces a breach of 12 million patients, LabCorp announces a 7 million patient breach of its own.  Well, not really it's own: like the Quest breach, LabCorp is announcing a breach of its billing vendor, who is the same billing vendor that Quest uses.  

Jeff [2:14 PM]

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