GDPR Lock EU

Data subject access rights and your medical practice: The UK Information Commissioner’s Office (ICO) issues advice.

Medical practices have reported a significant rise in subject access requests (SARs) since the GDPR came into effect in May last year, which is a similar trend in other sectors. Here are some points of advice from the ICO:

  • General Practitioners (GPs) cannot query the reason for requesting the information.
  • Providing a patient with online access to their health records may be sufficient.
  • SAR response may be provided electronically (subject to safeguards such as encryption).
  • GPs can ask the patient or their representative to clarify the information that would be acceptable to satisfy the SAR.

Where an SAR is made on behalf of a patient by their legal representative:

  • GPs may ask for evidence of clear, specific authority of the data subject to exercise their right of access
  • If a GP thinks that more information than is necessary is being requested, they can check that the patient is aware of the full extent of what is being sought
  • In cases where practices have genuine concerns about giving out excessive information, they can provide data directly to the patient

Details from the UK ICO.

Yesterday’s listserv announcement from the Office for Civil Rights (OCR) within the U.S. Department of Health and Human Services (HHS) brought to mind this question. The post announces the agreement by a Florida company, Advanced Care Hospitalists PL (ACH), to pay $500,000 and adopt a “substantial corrective action plan”. The first alleged HIPAA violation? Patient information, including name, date of birth, and social security number was viewable on the website of ACH’s medical billing vendor, and reported to ACH by a local hospital in 2014.

To add insult (and another alleged HIPAA violation) to injury, according to the HHS Press Release, ACH did not have a business associate agreement (BAA) in place with the vendor, Doctor’s First Choice Billings, Inc. (First Choice), during the period when medical billing services were rendered (an 8-month period running from November of 2011 to June of 2012). Based on the HHS Press Release, it appears that ACH only scrambled to sign a BAA with First Choice in 2014, likely after learning of the website issue. In addition, according to the HHS Press Release, the person hired by ACH to provide the medical billing services used “First Choice’s name and website, but allegedly without any knowledge or permission of First Choice’s owner.”

These allegations are head-spinning, starting with those implicating the “should’ve-been” business associate. First, how does a medical billing company allow an employee or any other individual access to its website without its knowledge or permission? Next, shouldn’t someone at First Choice have noticed that an unauthorized person was posting information on its website back in 2011-2012, or at some point prior to its discovery by an unrelated third party in 2014? Finally, how does a medical billing company (a company that should know, certainly by late 2011, that it’s most likely acting a business associate when it performs medical billing services), not realize that individually identifiable health information and social security numbers are viewable on its website by outsiders?

ACH’s apparent lackadaisical attitude about its HIPAA obligations is equally stunning. What health care provider engaged in electronic billing was not aware of the need to have a BAA in place with a medical billing vendor in 2011? While the Omnibus Rule wasn’t published until January of 2013 (at which point ACH had another chance to recognize its need for a BAA with First Choice), HHS has been publishing FAQs addressing all kinds of business associate-related issues and requirements since 2002.

It seems pretty obvious that ACH should have had a BAA with First Choice, but, in many instances, having a BAA is neither required by HIPAA nor prudent from the perspective of the covered entity. A BAA generally is not necessary if protected health information is not created, received, maintained or transmitted by or to the vendor in connection with the provision of services on behalf of a covered entity, business associate, or subcontractor, and having one in place may backfire. Consider the following scenario:

*          Health Plan (HP), thinking it is acting out of an abundance of HIPAA caution, requires all of its vendors to sign BAAs.

*          Small Law Firm (SLF) provides legal advice to HP, but does not create, receive, maintain or transmit protected health information in connection with the services it provides on behalf of HP.

*          However, SLF signs HP’s BAA at HP’s request and because SLF thinks it might, at some point, expand the scope of legal services it provides to HP to include matters that require it to receive protected health information from HP.

*          SLF suffers a ransomware attack that results in some of its data being encrypted, including data received from HP. It reviews HHS’s fact sheet on Ransomware and HIPAA, and realizes that a HIPAA breach may have occurred, since it cannot rule out the possibility that it received protected health information from HP at some point after it signed the BAA and prior to the attack.

*          SLF reports the attack to HP as per the BAA. Neither SLF nor HP can rule out the possibility that protected health information of individuals covered by HP was received by SLF at some point and affected by the attack.

HP is now in the position of having to provide breach notifications to individuals and HHS. Had it been more circumspect at the outset, deciding it would only ask SLF to sign a BAA if/when SLF needed protected health information in order to provide legal services on behalf of HP, it may have avoided these HIPAA implications completely.

So while it seems stunning that a health care provider entity such as ACH would have neglected to sign a BAA with First Choice before 2014, having a BAA in place when it is not necessary can create its own problems. Better to constantly ask (and carefully consider): to BAA or not to BAA?

The new Apple Watch Series 4® is one of the more recent and sophisticated consumer health engagement tools. It includes a sensor that lets wearers take an electrocardiogram (ECG) reading and detect irregular heart rhythms. The U.S. Food & Drug Administration (FDA) recently approved these functions as Class II medical devices, which generally means that they have a high to moderate risk to the user. The FDA approval letters describe the Apple Watch Series 4 functions as intended for over-the-counter use and not to replace traditional methods of diagnosis or treatment.

Tech developers and HIPAA lawyers often mean different things when describing a health app or medical device as HIPAA compliant. For example, a health app developer will likely focus on infrastructure, whereas the lawyer will likely focus on implementation. When asked about HIPAA, the app developer might rely on International Organization for Standardization (ISO) certification to demonstrate its data privacy and security controls and highlight how the infrastructure supports HIPAA compliance. The HIPAA lawyer, on the other hand, will likely focus on how (and by whom) data is created, received, maintained and transmitted and must look to the HIPAA regulations and guidance documents issued by the U.S. Department of Health and Human Services (HHS) to determine when and whether the data is subject to HIPAA protection. ISO certification does not equate to HIPAA certification; in fact, there is no HIPAA compliance certification process, and it is often difficult from the outset to determine if and when HIPAA applies.

As discussed in this prior blog post, HHS’s guidance on various “Health App Scenarios” underscores that fact that health data collected by an app may be HIPAA-protected in some circumstances and not in others, depending on the relationship between an app developer and a covered entity or business associate. The consumer (or app user) is unlikely to understand exactly when or whether HIPAA applies, particularly if the consumer has no idea whether such a relationship exists.

Back to the Apple Watch Series 4, and the many other consumer-facing medical devices or health apps in already on the market or in development. When do the nuances of HIPAA applicability begin to impede the potential health benefits of the device or app? If I connect my Apple Watch to Bluetooth and create a pdf file to share my ECG data with my physician, it becomes protected heath information (PHI) upon my physician’s receipt of the data. It likely was not PHI before then (unless my health care provider told me to buy the watch and has process in place to collect the data from me).

Yet the value of getting real-time ECG data lies not in immediate user access, but in immediate physician/provider access. If my device can immediately communicate with my provider, without my having to take the interim step of moving the data into a separate file or otherwise capturing it, my physician can let me know if something is of medical concern. I may not want my health plan or doctor getting detailed information from my Fitbit® or knowing whether I ate dessert every night last week, but if I’m at risk of experiencing a medical emergency or if my plan or provider gives me an incentive to engage in healthy behavior, I may be willing to allow real-time or ongoing access to my information.

The problem, particularly when it comes to health apps and consumer health devices, is that HIPAA is tricky when it comes to non-linear information flow or information that changes over time. It can be confusing when information shifts from being HIPAA-protected or not, depending on who has received it. As consumers become more engaged and active in managing health conditions, it is important that they realize when or whether HIPAA applies and how their personal data could be used (or misused) by recipients. Findings from Deloitte’s 2018 consumer health care survey suggest that many consumers are interested in using apps to help diagnose and treat their conditions. For example, 29% were interested in using voice recognition software to identify depression or anxiety, but perhaps not all of the 29% would be interested in using the software if they were told their information would not be protected by HIPAA (unless and until received by their provider, or if the app developer was acting as a business associate at the time of collection).

Perhaps certain HIPAA definitions or provisions can be tweaked to better fit today’s health data world, but, in the meantime, health app users beware.

Registration to the Privacy Summit is open.

Fox Rothschild’s Minneapolis Privacy Summit on November 8 will explore key cybersecurity issues and compliance questions facing company decision-makers. This free event will feature an impressive array of panelists drawn from cybersecurity leaders, experienced regulatory and compliance professionals and the Chief Division Counsel of the Minneapolis Division of the FBI.

Attendees receive complimentary breakfast and lunch, and can take advantage of networking opportunities and informative panel sessions:

GDPR and the California Consumer Privacy Act: Compliance in a Time of Change

The European Union’s General Data Protection Regulation has been in effect since May. Companies that process or control EU citizens’ personal data should understand how to maintain compliance and avoid costly fines. Health care businesses should also prepare for the next major privacy mandate: the California Consumer Privacy Act.

Risk Management – How Can Privacy Officers Ensure They Have the Correct Security Policies in Place?

Panelists offer best practices for internal policies, audits and training to help maintain protected health information (PHI), personally identifiable information (PII) or other sensitive data. Learn the cutting edge strategies to combat the technology threats of phishing and ransomware.

Fireside Chat

Jeffrey Van Nest, Chief Division Counsel of the Minneapolis Division of the FBI, speaks on the state of affairs in regulation and enforcement; including how to partner with the FBI, timelines of engagement and the latest on cyber threat schemes. His insights offer details on forming effective cyber incident response plans.

Keynote Speaker – Ken Barnhart

Ken is the former CEO of the Occam Group, a cybersecurity industry advisor and the founder and principal consultant for Highground Cyber – a spin-off of the Occam Group’s Cybersecurity Practice Group. For more than a decade, he has helped companies of all sizes design, host and secure environments in private, public and hybrid cloud models. Prior to his work in the corporate sector, Ken served as a non-commissioned officer in the United States Marine Corp and is a decorated combat veteran of Operation Desert Shield\Storm with the HQ Battalion of the 2nd Marine Division.

Geared toward an audience of corporate executives, in-house chief privacy officers and general counsel, the summit will provide important take-aways about the latest risks and threats facing the health care industry.

Stay tuned for more agenda details. Registration is open.

Filefax, Inc., a defunct Illinois medical records storage and management company, has been fined $100,000 for improperly handling medical data under an agreement with the court-appointed receiver managing the company’s assets on behalf of its creditors.  This settlement has implications for both service providers and their covered entity clients.  Fox Rothschild partners Elizabeth Litten and Michael Kline were quoted in an article by Marla Durben Hirsch entitled “Be prepared for HIPAA Issues if a business associate shuts down” in the August issue of Medical Practice Compliance Alert.

As the HHS press release stated, the consequences for HIPAA violations don’t stop when a business closes.  In this case, Filefax had been under investigation by state and federal authorities since 2015 for careless handling of medical records which had been abandoned at a shredding facility.   Medical Practice Compliance Alert notes:

This settlement shows that  a provider or business associate that has violated HIPAA can’t avoid the consequences by shutting down.  “OCR is saying that you’re still responsible if you close your doors.” Says attorney Elizabeth Litten with Fox Rothschild in Princeton, NJ.

But it also provides a cautionary tale for providers who work with business associates that go under because providers are ultimately responsible for their patients’ records.

The article suggests the following tips for a covered entity to reduce its risks when a business associate may be in shaky financial shape:

  1. Keep an inventory of your business associate relationships.
  2. Choose business associates carefully.
  3. Monitor your business associates’ compliance with HIPAA.
  4. Expect increased scrutiny if a business associate is already on the government’s radar.
  5. Watch for signs that the business associate may be running into financial trouble.
  6. Don’t sit idly if the business associate files for bankruptcy.

What should a covered entity do when it learns that a business associate may have violated its HIPAA responsibilities?  For starters, see our previous post entitled Ten Tips for Actions by a Covered Entity after a HIPAA Breach by a Business Associate.  And if that BA has ceased operations, be prepared to take control of the situation even if the BA may not have enough resources left to reimburse you for its mistakes. Remember, the buck always stops with the Covered Entity.

Harry S. Truman Library & Museum 2017

The recent criminal conviction of a Massachusetts physician provides a stark reminder that violating HIPAA can result in more than civil monetary penalties and the financial and reputational fall-out that results from a breach. In this case, perhaps the cover-up was worse than the crime, or maybe prosecutors decided that a conviction on other charges would have been harder to get. Either way, the case should alert covered entities and business associates to the fact that HIPAA violations can result in jail time and criminal fines.

The U.S. Department of Health and Human Services (HHS), Office for Civil Rights (OCR) investigates complaints and may impose civil monetary penalties (CMPs) for violations of HIPAA.   The U.S. Department of Justice (DOJ) handles criminal investigations and penalties.  This may not provide much comfort, but a CMP will not be imposed if the HIPAA violation is determined to constitute a criminal offense.

OCR will refer matters to DOJ for criminal enforcement in some cases or will work cooperatively with DOJ where a DOJ investigation on other grounds reveals a potential HIPAA violation.  HHS reported that OCR had referred 688 cases to the DOJ for criminal investigation as of June 30, 2018.

The criminal enforcement of HIPAA was described in a Memorandum Opinion issued in 2005 jointly to HHS and the Senior Counsel to the Deputy Attorney General by Steven Bradbury, then-acting Assistant Attorney General of the Office of Legal Counsel within DOJ (the DOJ Memo). The DOJ Memo explains that HIPAA allows for criminal penalties only for violations that involve the disclosure of “unique health identifiers” or “individually identifiable health information” (IIHI) that are made “knowingly” and in violation of HIPAA.   Specifically, a person may be subject to criminal penalties if he or she knowingly (and in violation of HIPAA):  (i) uses or causes to be used a unique health identifier; (ii) obtains IIHI; or (iii) discloses IIHI to another person.  Criminal penalties range from misdemeanors to felonies.  The maximum criminal penalty (a fine of up to $250,000 and imprisonment of up to 10 years) can be imposed if one of these offenses is committed “with intent to sell, transfer, or use [IIHI] for commercial advantage, personal gain, or malicious harm.”  The DOJ Memo explains that “knowingly” refers to knowledge of the facts that constitute the offense, not knowledge of the law being violated (HIPAA).

The DOJ Memo emphasizes the fact that criminal penalties are reserved for limited and specific violations of HIPAA:  “Such punishment is reserved for violations involving `unique health identifiers’ and [IIHI]…  Thus, the statute reflects a heightened concern for violations that intrude upon the medical privacy of individuals.”  The DOJ Memo focuses on violations by covered entities. It notes that when a covered entity is not an individual, but is a corporate entity, the conduct of agents may be imputed to the entity when the agents act within the scope of employment, and the criminal liability of a corporate entity may be attributed to individuals in managerial roles.

DOJ might decide to seek a conviction for a violation of HIPAA when it believes such a conviction would be easier to get than a conviction for a violation of other federal laws governing health care providers (such as the anti-kickback statute).   After all, the DOJ Memo makes it clear that “knowing” refers to the conduct, not the state of the law.  However, it should be noted, as per the DOJ Memo, that the DOJ’s interpretation of “`knowingly’ does not dispense with the mens rea requirement of section 1320d-6 [HIPAA] and create a strict liability offense; satisfaction of the ‘knowing’ element will still require proof that the defendant knew the facts that constitute the offense.”

When a health care entity (like a large hospital system or health plan) has deep pockets, the OCR may decide to pursue very high civil monetary penalties and rely on the financial and reputational implications of the civil monetary penalties to act as a deterrence.  On the other hand, the DOJ may seek to deter behavior associated with a wider range of criminal activities by pursuing jail time for a HIPAA violation.

In the case of the Massachusetts physician, it is also likely that the DOJ pursued the criminal charge because she lied about her relationship with the third party to which she disclosed patient information. My law partner Charles DeMonaco, a white collar defense attorney and former DOJ prosecutor, agrees:

It is understandable why this doctor was indicted and convicted for these offenses.  She was accused of lying to the agents, which is always a major hurdle in a criminal case.  Even if an underlying crime cannot be established, a lie of a material fact to a government agent is a stand-alone false-statement felony.  It also establishes consciousness of guilt. The doctor could have asserted her Fifth Amendment privilege against self-incrimination to avoid talking to the government agents.  It is never a good thing for a doctor to speak with agents who are investigating the doctor’s conduct without counsel and without proper protection of limited use immunity being sought prior to the interview.  The government also proved that she accepted fees from the pharma company after providing the [IIHI] in violation of HIPAA.  Under these facts, it is not surprising that this case was brought as a criminal prosecution and that a guilty verdict was returned.

Everyone subject to HIPAA should be aware that a HIPAA violation involving disclosure or breach of IIHI may be the low-hanging fruit for criminal prosecutors originally focused on other violations of law.   In particular, covered entities should carefully evaluate arrangements with third parties that involve the sharing of IIHI with those parties for commercial/personal gain or commercial harm. If the sharing of IIHI is not permitted under HIPAA and commercial gain or harm is involved, these violations could result in the most severe level of criminal penalties, including significant jail time.

The European Union’s General Data Protection Regulation (GDPR) went into effect on May 25, 2018. Whereas HIPAA applies to particular types or classes of data creators, recipients, maintainers or transmitters (U.S. covered entities and their business associates and subcontractors), GDPR applies much more generally – it applies to personal data itself. Granted, it doesn’t apply to personal data that has absolutely no nexus to the EU, but assuming it doesn’t apply to your U.S.-based entity simply because you don’t have a physical location in the EU is a mistake.

So when does GDPR apply to a U.S.-based covered entity, business associate, or subcontractor? As with HIPAA, the devil is in the definitions, so I’ve capitalized certain GDPR-defined terms below. GDPR is comprised of 99 articles set forth in 11 chapters, and 173 “Recitals” explain the rationales for adoption. Similar to the way regulatory preambles and guidance published by the U.S. Department of Health and Human Services (HHS) can be helpful to understanding HIPAA compliance, the Recitals offer insight into GDPR applicability and scope.

Under Article 3, GDPR applies:

(1) To the Processing of Personal Data in the context of the activities of an establishment of a Controller or Processor in the EU, regardless of whether the Processing takes place in the EU;

(2) To the Processing of Personal Data of data subjects who are in the EU by a Controller or Processor not established in the EU, where the Processing activities are related to:

(a) the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the EU; or

(b) the monitoring of their behavior as far as their behavior takes place within the EU; and

(3) To the Processing of Personal Data by a Controller not established in the EU, but in a place where EU member state law applies by virtue of public international law.

It is paragraph (2) that seems most likely to capture unwitting U.S.-based covered entities, business associates, and subcontractors that are not established in the EU (though Recital 22 offers further explanation of what it means to be Processing data in the context of the activities of an establishment).

Notably, paragraph (2) makes it clear that while the entity need not be located within the EU for GDPR to apply, the data subject must be. If the U.S. entity offers goods or services to, or monitors the behavior of, data subjects who are “in” the EU, GDPR likely applies. It is the location of the data subject, not his or her citizenship, residency or nationality, that matters. GDPR does not follow the data subject outside the EU, but it does follow the data subject (even an American) into the EU – so long as the Processing of the Personal Data takes place in the EU.

So what does this mean for the U.S.-based covered entity, business associate, or subcontractor not established in the EU? It should carefully review its website, marketing activities, discharge or post-service follow-up procedures, and any other activities that might involve the offering goods or services to, or monitoring the behavior of, individuals in EU. If GDPR applies, the company will need to analyze how its HIPAA privacy and data security policies are inconsistent with and fall short of GDPR requirements. The company, whether a covered entity, business associate, or subcontractor, should also make sure that none of its vendors process data on its behalf in the EU.

In addition to understanding where data subjects are located and where Processing takes place in order to determine GDPR applicability, covered entities, business associates and subcontractors must determine whether they are acting as Controllers or Processors in order to understand their GDPR compliance obligations.

This can create particular challenges for a business associate.  If a covered entity is subject to GDPR, a business associate that creates, receives, maintains or transmits Personal Data on behalf of the covered entity will either be acting as a Processor (for example, where the covered entity simply uses the business associates tools or services to conduct its business), or a Controller (for example, where the business associate reaches out directly to plan members or patients, such as by an email campaign).  If the business associate’s services agreement or business associate agreement makes no mention of the fact that the covered entity is subject to GDPR, the business associate may not know whether it is also subject to GDPR, let alone whether it is a Controller or Processor.

The bottom line is that focusing on compliance with HIPAA and other federal and state laws pertaining to privacy and security of personal information is not enough, even for companies that view themselves as operating solely within the U.S.  A thorough risk assessment should include not only careful consideration of HIPAA requirements, but of the potential applicability and compliance requirements of GDPR.

The Report to Congressional Committees of the U.S. Government Accountability Office (“GAO Report”), required under the 21st Century Cures Act, came out about a month earlier than required, but this early bird failed to catch what continues to be a wriggling worm – what can a covered entity charge for these copies?

As discussed in our February 2017 blog post, the Office for Civil Rights issued guidance (“OCR Guidance”) over 2 years ago attempting to clarify that HIPAA charge limits (to a “reasonable, cost-based fee”) apply when an individual (or a third party) requests access to the individual’s medical records. The HIPAA charge limits applicable to access requests apply even if state law permits higher charges for the copies. The OCR Guidance includes a table illustrating the differences between a HIPAA authorization and an access request and notes that the “primary difference” between the two being that one (the authorization) is a “permitted disclosure” and one (the access request) is a “required disclosure”.

In another of our posts on this topic (back in May of 2016), we highlighted the difficulty faced by a covered entity in knowing what amounts may be charged for medical records copies, particularly when a third party requests the copy. We noted HHS’s suggestion that the covered entity ask the individual “whether the request was a direction of the individual or a request from the third party.” The former would be an access request subject to charge limits and other HIPAA requirements, whereas the latter would be “merely a HIPAA authorization”. A wriggling worm, indeed.

The GAO Report attempts to pin down the worm. It describes three types of medical record requests:

*          a patient request, whereby the patient or former patient requests access to or a copy of medical records

*          a patient-directed request, whereby the patient or former patient requests that a copy of the patient’s medical records be sent directly to another person or entity (“For example, a patient might request that her medical records be forwarded to another provider because the patient is moving or wants a second opinion.”)

*          a third-party request, whereby a third party, such as an attorney, obtains permission from the patient (via a HIPAA authorization) to access the patient’s medical records

An explanatory footnote suggests that the first two types of requests are access requests under HIPAA (meaning that charge limits and other HIPAA requirements apply), while the third type of request is an authorization under HIPAA (meaning that the provider is not required to disclose the records and the access request charge limits do not apply). Later, the GAO Report states: “In contrast with patient and patient-directed requests, the fees for third-party requests are not limited by HIPAA’s reasonable, cost-based standard for access requests and are instead governed by state laws.”

Unfortunately, this is where the worm has a chance to get away. First, the example used to describe a patient-directed request implies that a patient access request is required for the provider to forward the medical records to another treating provider. In fact, HIPAA permits disclosure of medical records for treatment purposes without the need for a HIPAA authorization or access request (see OCR Guidance language following table), and, thus, charging even a “reasonable, cost-based” fee for such disclosures may be frowned upon by OCR. Second, these three examples overlook the possibility that a patient-directed request may come from a third party. An access request must be in writing, be signed by the individual, and clearly identify where the medical record copies should be sent, but HIPAA does not prohibit the individual from directing that a third party (such as the individual’s attorney) transmit the individual’s access request to the provider.

Moreover, a recent court decision further muddies this issue. In a February 2018 U.S. district court decision from Alabama, Bocage v. Acton Corp., the court rejected plaintiffs’ claim that they were overcharged search and retrieval fees in violation of HIPAA. The plaintiffs’ attorneys had requested medical records by way of HIPAA authorizations, so the court determined that the fee limitations associated with individual access requests did not apply. Unfortunately, while the decision quotes the OCR Guidance (“The [access request] fee limits apply … regardless of whether the access request was submitted to the covered entity by the individual directly or forwarded to the covered entity by a third party on behalf and at the direction of the individual (such as by an app being used by the individual)… ”), the decision incorrectly suggests that the individual’s attorney cannot be the third party making an access request on behalf of and at the direction of the individual.

The short-term fix for patients hoping to avoid high fees when requesting medical records? Make sure the request is not identified as a HIPAA authorization and, if you are requesting the records in connection with litigation, consider sending it yourself rather than directing your attorney to send it.

In 1973, President Richard Nixon’s Chief of Staff H.R. Haldeman warned White House Counsel John Dean against talking to prosecutors investigating the growing Watergate scandal, telling him “Once the toothpaste is out of the tube, it’s going to be very hard to get it back in,” and a useful idiom was born. Personal electronic data, including protected health information, once disclosed, can be equally difficult to recapture and contain.

A recent article in Slate entitled You Can’t Clean Up a Data Spill describes the obstacles to effectively remediating a data breach or improper disclosure in the wake of revelations about the breach involving Facebook data and Cambridge Analytica. As author April Glaser stated, “There’s no such thing as a cleanup site for data spills. That’s because when data leaks, it can be duplicated far faster than anyone can mop it up.”

Cambridge Analytica, a British political consulting firm, provided research, data mining and communication services to campaigns including those of Ted Cruz and Donald Trump. The firm claimed to have developed “psychographic” profiles of voters that could predict their personality traits and political leanings. The New York Times reported that the firm had harvested information from the Facebook profiles of over 50 million users without their permission, and a subsequent CNN report estimates the breach may have affected up to 87 million users. The firm’s chief executive has claimed that the data had been deleted when the improper acquisition was brought to their attention two years prior to the Times article. But how much toothpaste is still in circulation, and can anything be done to recover it?

Facebook founder Mark Zuckerberg has told CNN that Cambridge Analytica provided them with a formal certification from the firm that it had deleted all user data acquired through improper means. Unfortunately, even if that is accurate, it cannot address whether the data had been copied or further disclosed prior to such deletion. According to Slate:

Tracking down and searching where that data has gone will be incredibly difficult,” says Sarah Aoun, a digital security specialist and open web fellow at the Mozilla Foundation. “I’m not even sure it would be realistic.” Maybe it would be easier if the data was “watermarked,” meaning there was some tag on the data to indicate it was the Cambridge Analytica–obtained Facebook data. But Facebook didn’t do that, as Zuckerberg explained to Wired, and even if it had, Aoun says that “any identifiable trace relating it back to Facebook can be altered and then changed and could exist in 10 different shapes and forms online or in the hands of anyone.”

The Facebook/Cambridge Analytica breach is a sobering cautionary tale for covered entities and business associates subject to HIPAA who routinely handle large amounts of PHI. Once a breach occurs and is discovered, it may be impossible to definitively account for all data that may have been copied or transmitted. All the more reason to secure the cap on your EHR tube.

Many employers who have had it drilled into them that HIPAA applies to protected health information (PHI) of employees are often surprised to learn that the applicability of HIPAA to employee health information (EHI) is actually quite narrow.  HIPAA only applies to EHI related to the employer’s group health plans (such as medical, dental, employee assistance program (EAP) and health flexible spending arrangement (FSA)).  Employer-sponsored group health plans are HIPAA covered entities. Further, although this is true regardless of whether the group health plan is insured by an insurance company or self-insured by the employer, the employer will not generally have HIPAA compliance responsibilities for an insured group health plan if it does not receive any EHI other than for the limited purpose of enrollment activities, or summary health information for amending or terminating the plan or obtaining premium bids. Instead, for a fully-insured group health plan, HIPAA compliance will generally be handled by the insurance company, which is also subject to HIPAA as a covered entity.

HIPAA doesn’t apply to EHI that the employer obtains from a source other than its group health plans, such as medical information related to employment (including pre-employment physicals, drug testing results, medical leave or workers’ compensation) and information from other employment-related benefits that are not group health plans (such as life or disability insurance). This result does not change merely because the employee’s health information is PHI when held by a HIPAA-covered entity health care provider who tested or treated the employee before the information was transferred to the employer via a HIPAA-compliant authorization.

Even though EHI obtained by an employer for employment-related reasons or relating to non-group health plan benefits isn’t subject to HIPAA, this doesn’t mean the employer can throw caution to the wind.  Other federal and state laws (such as the Family and Medical Leave Act (FMLA), Americans with Disabilities Act (ADA) and state workers’ compensation laws) impose restrictions on the employer’s access to and use and disclosure of this EHI and impose obligations to maintain confidentiality of the EHI. These restrictions and obligations apply regardless of how the employer obtains the EHI (for example, even if obtained pursuant to an authorization signed by the employee or directly from the employee).

Because other laws protect EHI even when HIPAA does not, it’s often helpful for the employer to apply the same or similar safeguards to all EHI, even if HIPAA does not apply.  Applying HIPAA-like safeguards to EHI that isn’t subject to HIPAA not only will often bring the employer a long way towards complying with other federal and state laws that may apply; it may also avoid the necessity of categorizing types of EHI to determine what level of safeguards should be imposed.