The California Consumer Privacy Act (CCPA) will take effect on January 1, 2020 and regulates most entities that collect personal information of California residents.  CCPA was patterned after the European Union’s General Data Protection Regulation (GDPR) which went online on May 28, 2018 and has been called “GDPR-Lite.”  In May, Fox Rothschild partner Odia Kagan described when CCPA applies in an Alert that listed the categories of entities who are affected: generally,  for-profit businesses who do business in California, collect California consumers’ personal information and determine the purposes and means of processing that information, and have at least $25 million in annual gross revenues, buy, sell, share and/or receive the personal information of at least 50,000 California consumers, households or devices, per year, or derive at least 50 percent of their annual revenue from selling California consumers’ personal information, as wells as entities that control or are controlled by such businesses and share common branding.  Each of those terms has a technical definition that should be carefully reviewed.   But isn’t there a HIPAA exception?

Yes, CCPA contains a carve-out for HIPAA covered entities, but it is not as broad as you may have heard.  In a recent alert entitled  Where HIPAA Stops, CCPA Begins – Why Covered Entities and Business Associates Cannot Ignore the New California Data Privacy Law, Fox Rothshchild partners Odia Kagen and Elizabeth Litten explain when information that appears to be exempt PHI may fall under the new CCPA:

Personal information created, received, maintained or transmitted by companies subject to HIPAA is likely subject to CCPA if it falls into one of the following five categories:

  1. It is not created or collected as part of the payment, treatment or health care operations trifecta
  2. It was never PHI (or is excluded from the definition of PHI) under HIPAA
  3. It was once PHI, but has been de-identified under HIPAA
  4. It is not PHI, but is derived from PHI
  5. It is PHI that is used for research purposes in accordance with HIPAA

The bottom line is that what you think is PHI and exempt from CCPA may not be covered by the carve-out after all. For details, see the Alert.

GDPR Lock EU

“The right to be forgotten does not apply in principle to medical records. However, as a patient, you may ask your health care provider to remove data from your medical record,” according to the Dutch Data Protection Authority, Autoriteit Persoonsgegevens (AG), which has issued a guidance on GDPR and medical records.

Key takeaways:

  • For medical data that are not covered by the Medical Treatment Agreement Act, such as nursing care and in-home care, personal data should not be kept longer than necessary.
  • The personal data that you have actively and consciously provided is covered by the right to data portability. This also applies to the data that you have provided indirectly through the use of a service or device. For example, the data that your pacemaker or blood pressure monitor generates.
  • The right to data portability does not apply to the conclusions, diagnoses, suspicions or treatment plans that your health care provider establishes on the basis of the information you provide.
  • As a health care provider, you must in any case use two-factor authentication. Such as logging in with DigiD in combination with SMS.

Read the full guidance.

“TMI” usually means “too much information”, but it was used aptly by the Office for Civil Rights (OCR) as an acronym for a covered entity that exposed protected health information (PHI) of more than 300,000 patients through an insecurely configured server. According to the April 5, 2019 Resolution Agreement, the covered entity, Touchstone Medical Imaging, Inc. (TMI), not only used an insecure file transfer protocol (FTP) that allowed visibility to patient information via google searches, but it seemingly dragged its HIPAA compliance feet upon learning of the PHI exposure.

TMI was notified of its insecure FTP on May 9, 2014 and apparently implemented technical safeguards to limit access rights to the FTP server that maintained PHI to approved persons and software programs, but TMI failed to provide notice to individuals and the media of the breach until October 3, 2014, 147 days after discovery of the breach. Adding insult to injury, TMI failed to enter into a business associate agreement with its IT vendor until June 2, 2016, and (as of the date of the Resolution Agreement) “continues” to engage another business associate “without the protections of a business associate agreement in place.”

It is not clear from the Resolution Agreement exactly how the insecurity of the FTP was initially discovered or by whom. The Resolution Agreement states that TMI conducted a HIPAA security risk assessment on April 3, 2014, but the Press Release states that TMI was notified by the FBI and OCR in May of 2014. The Press Release also says that TMI “initially claimed that no patient PHI was exposed,” and that OCR found that TMI did not thoroughly investigate the incident until several months after notice of the breach by both the FBI and OCR.

A more immediate and robust breach response may very well have saved this covered entity millions, let alone negative publicity. The PHI exposure was significant (especially when combined with the delayed and seemingly insufficient security risk assessment), but the combination of TMI (as in too much information) and not enough in terms of response activity is the perfect recipe for a HIPAA settlement.

Illustration of stethoscope and mobile phone, symbolizing telemedicine

A study shows that “92 percent of 36 mental health apps shared data with at least one third party — mostly services that help with marketing, advertising, or data analytics.”

“About half of those apps did not disclose that third-party data sharing, for a few different reasons: nine apps didn’t have a privacy policy at all; five apps did but didn’t say the data would be shared this way; and three apps actively said that this kind of data sharing wouldn’t happen.”

While some of this information is not immediately identifying, that could soon change.

“We live in an age where, with enough breadcrumbs, it’s possible to reidentify people” says John Torous, director of digital psychiatry at Beth Israel Deaconess Medical Center. “Advertisers could use this to compromise someone’s privacy … For example, if an advertiser discovers someone is trying to quit smoking … would they be interested in electronic cigarettes … Or other similar products, like alcohol?” says Steven Chan, a physician at Veterans Affairs Palo Alto Health Care System.

Details from The Verge.

A two-physician practice in Battle Creek, Michigan is reportedly the first health care provider to cease operations as a result of a ransomware attack.  The Minneapolis Star Tribune reports that Brookside ENT experienced a malware attack that deleted and overwrote every medical record, bill and appointment in the practice’s system, including backups, and created encrypted duplicates.  The attacker then attempted to extort $6,500 from the group, to be wired to an anonymous account, in order to decrypt the files.

Facing the expense and uncertainty of recovering from this attack, the two physicians, Dr. William Scalf, 64, and Dr. John Bizon, 66 (who also serves as a Republican Michigan state senator), decided to close their practice and accelerate their planned retirement by a year.  Unfortunately, with all their records wiped clean, they did not even have a list of patients and their contact information to allow them to communicate the closure of the practice.  Instead, Dr. Scalf said, “… what I did was just sort of sat in the office and saw whoever showed up. For the next couple of weeks.”  Patients were given referrals to other otolaryngologists in the area, but their records, including test results, remained unavailable.

The doctors had decided against paying the ransom because there was no way to ensure they would get a valid code to unlock the files in return, and no way to prevent being extorted again in the future. The Star-Tribune cited Brian Stevenson, president of Roseville cyber security firm FocusPoint Technologies, who reported that only about one-third of ransomware victims who pay the ransoms end up getting their data back. Symantec reports a little better average, with 47% of those who pay receiving a valid unlock code.

The group consulted an IT expert who verified that the attack did not grant the hackers access to any protected health information, so no HIPAA breach needed to be reported.   Note that the HHS Office of Civil Rights Fact Sheet on Ransomware and HIPAA states:

When electronic protected health information (ePHI) is encrypted as the result of a ransomware attack, a breach has occurred because the ePHI encrypted by the ransomware was acquired (i.e., unauthorized individuals have taken possession or control of the information), and thus is a “disclosure” not permitted under the HIPAA Privacy Rule. Unless the covered entity or business associate can demonstrate that there is a “…low probability that the PHI has been compromised,” based on the factors set forth in the Breach Notification Rule, a breach of PHI is presumed to have occurred. The entity must then comply with the applicable breach notification provisions, including notification to affected individuals without unreasonable delay, to the Secretary of HHS, and to the media (for breaches affecting over 500 individuals) in accordance with HIPAA breach notification requirements. See 45 C.F.R. 164.400-414.

In some states physicians can be sanctioned by their medical boards and/or held civilly liable for “patient abandonment,” which is defined in Pennsylvania as “when a physician withdraws his services after a physician-patient relationship has been established, by failing to give notice to the patient of the physician’s intention to withdraw in sufficient time to allow the patient to obtain necessary medical care.”  It is unclear what responsibilities a physician would have in a situation where due to a malicious attack they no longer have access to records that would allow them to provide notice to patients.

One lesson from this catastrophe is to take steps to properly insulate your backup system from external infection. Use multiple backups including a cloud-based system for redundancy. If practical, keep any local backup servers disconnected from the Internet.  The Office of Civil Rights of the Department of Health and Human Services reminds covered entities that “Implementing a data backup plan is a Security Rule requirement for HIPAA covered entities and business associates as part of maintaining an overall contingency plan. Additional activities that must be included as part of an entity’s contingency plan include: disaster recovery planning, emergency operations planning, analyzing the criticality of applications and data to ensure all necessary applications and data are accounted for, and periodic testing of contingency plans to ensure organizational readiness to execute such plans and provide confidence they will be effective. See 45 C.F.R. 164.308(a)(7).”

This attack may have caused an unusually comprehensive loss of data including all patient contact information.  Maintaining a separate patient contact list and printing out appointment schedules may have helped this group reach out to affected patients.  In today’s wired environment it is too easy to assume that our electronic resources will always be available, and when they are suddenly vaporized, the consequences can be severe to providers and patients alike.

If you are a covered entity health plan or clearinghouse, you may be among the nine (un)lucky entities randomly chosen this month for review into compliance with HIPAA’s Administrative Simplification rules governing electronic transactions, code sets, and unique identifiers.  According to an FAQ published in March, the Centers for Medicare & Medicaid Services (CMS), acting on behalf of the U.S. Department of Health and Human Services (HHS) will select five health plans and four clearinghouses for this new compliance review.

CMS has been actively investigating complaints (which can be filed here) related to the Administrative Simplification Rules for some time, publishing summary reports covering complaints submitted beginning in January of 2017.

What will happen if any of these nine selected entities is determined to be non-compliant?

According to CMS,

If an organization isn’t compliant, HHS will work with the entity to resolve any issues. Corrective Action Plans are commonly used to address non-compliance. In cases of willful and egregious noncompliance, monetary penalties may be assessed and calculated on a case by case basis.

Although covered entity health care providers will not be a part of this 2019 compliance review, health care providers may avoid random selection in a future compliance review if they participate in the voluntary compliance program for providers expected to be rolled out this year.  Participants in the 2018 voluntary compliance program (the “Optimization Pilot Program”) for health plans and clearinghouses are exempt from the 2019 random selection process.  Then again, CMS reported that nine of the ten entities participating in the Optimization Pilot Program were required to undergo a Corrective Action Plan.

Covered entity health care providers may decide to play the odds and forego participation in the voluntary program, but this new round of compliance reviews is another reminder to HIPAA covered entities that HIPAA compliance isn’t solely about privacy and data security.

HHS Office for Civil Rights (OCR)’s April 3, 2019 cybersecurity newsletter highlights one of the more challenging cybersecurity vulnerabilities faced by covered entities and business associates.  OCR reminds covered entities (CEs) and business associates (BAs) that compliance with the HIPAA Security Rule can help, but stops a bit short of providing concrete guidance as to how best to minimize risk.  OCR warns:

One of the most dangerous tools in a hacker’s arsenal is the “zero day” exploit or attack which takes advantage of a previously unknown hardware, firmware, or software vulnerability.  Hackers may discover zero day exploits by their own research or probing or may take advantage of the lag between when an exploit is discovered and when a relevant patch or anti-virus update is made available to the public.”

What exactly is a “zero day” attack?  OCR summed it up pretty well.  According to the National Institute of Standards and Technology (NIST), it’s an “attack that exploits a previously unknown hardware, firmware, or software vulnerability.”

The problem is the time that elapses between the discovery of the vulnerability (day zero) and the creation and implementation of the patch for it.  If there’s a “lag between when an exploit is discovered and when a relevant patch or anti-virus update is made available to the public”, what can a CE or BA do?  OCR suggests that an entity “consider adopting other protective measures such as additional access controls or network access limitations” to mitigate liability until a patch is available.

OCR’s June 2019 cybersecurity newsletter provides a more thorough description as to how CEs and BAs can mitigate risks associated with unpatched vulnerabilities.   This newsletter also cross-references a useful resource for staying abreast of new vulnerabilities – the U.S. Computer Emergency Readiness Team (US-CERT).   The US-CERT “Current Activity” web page provides updates on identified security incidents and patches, and subscribers can sign up for email alerts.

Smaller CEs and BAs may still find it difficult to stay abreast of Zero Day attacks and necessary patches.  The NIST Small Business Cybersecurity Act may help (see here for resources made available as a result of the Act), and smaller entities can also make use of HHS’s recently published “Voluntary Cybersecurity Practices for the Health Care Industry.”

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.