In this edition of our regular roundup on legislative initiatives related to artificial intelligence (AI), cybersecurity, the Internet of Things (IoT), and connected and autonomous vehicles (CAVs), we focus on key developments in the European Union (EU).
Throughout September, the Department of Health and Human Services, Office for Civil Rights (“OCR”), announced eight different settlements to resolve a variety of alleged violations of the Privacy and Security Rules promulgated under the Health Insurance Portability and Accountability Act of 1996 (“HIPAA”). Notably, three settlements stem from data breaches in which hackers were able to access and obtain individuals’ protected health information (“PHI”). In a press release for one of these settlements, OCR Director Roger Severino noted that “[h]acking is the number one source of large health care data breaches,” and failure to comply with the HIPAA Rules may render “health data a tempting target for hackers.” In addition, OCR announced settlements with five separate providers to address potential violations of the Privacy Rule’s right of access provision.
OCR previously issued guidance waiving enforcement of certain HIPAA provisions in response to the COVID-19 pandemic, as we have discussed in earlier posts. However, these recent settlements may indicate that OCR is starting to return to “business as usual” in the area of HIPAA enforcement.
Premera Blue Cross
On September 25, OCR announced that Premera Blue Cross (“PBC”) — the largest health plan in the Pacific Northwest, operating in Washington and Alaska — agreed to pay $6.85 million and take corrective actions as part of a settlement to resolve potential HIPAA violations arising from a data breach that affected more than 10.4 million individuals. According to OCR, PBC’s settlement “represents the second-largest payment to resolve a HIPAA investigation in OCR history.”
PBC’s settlement relates to an incident in which hackers gained access to PBC’s IT system in May 2014 by using a phishing email to install malware. The unauthorized access was not discovered until January 2015, almost nine months later, during which time the hackers were able to obtain the PHI of over 10.4 million individuals, including their names, addresses, dates of birth, email addresses, Social Security numbers, bank account information, and health plan clinical information.
OCR launched an investigation after PBC reported the breach in March 2015, which revealed “systemic noncompliance with the HIPAA Rules including failure to conduct an enterprise-wide risk analysis, and failures to implement risk management, and audit controls.” According to Director Severino, PBC’s breach “vividly demonstrates the damage that results when hackers are allowed to roam undetected in a computer system for nearly nine months.” In addition to paying $6.85 million, PBC also entered into a Corrective Action Plan (“CAP”) that requires PBC, among other things, to conduct a risk analysis to identify potential risks and vulnerabilities to its electronic PHI and to develop and implement an enterprise-wide risk management plan to mitigate any identified risks and vulnerabilities.
On September 23, OCR announced that it had entered into an agreement with CHSPSC LLC (“CHSPSC”), in which the company agreed to pay $2.3 million to resolve alleged HIPAA violations resulting from a 2014 data breach. In April 2014, CHSPSC — a business associate for hospitals and clinics indirectly owned by Community Health Systems, Inc., in Tennessee — was notified by the Federal Bureau of Investigations (“FBI”) that a cyber-hacking group had been able to gain access to CHSPSC’s information systems using compromised administrative credentials. Notwithstanding the FBI’s warning, the hackers were able to access CHSPSC’s systems and obtain the PHI of over six million individuals (including their name, sex, date of birth, phone number, Social Security number, email, ethnicity, and emergency contact information) until August 2014.
OCR’s investigation following the breach uncovered “longstanding, systemic noncompliance with the HIPAA Security Rule including failure to conduct a risk analysis, and failures to implement information system activity review, security incident procedures, and access controls.” Director Severino stated that “[t]he failure to implement the security protections required by the HIPAA Rules, especially after being notified by the FBI of a potential breach, is inexcusable.” Along with the monetary settlement, CHSPSC also entered into a two-year CAP.
Athens Orthopedic Clinic PA
On September 21, OCR announced that it had reached a settlement with Athens Orthopedic Clinic PA (“AOC”), in which AOC agreed to pay $1.5 million to resolve potential violations of the HIPAA Privacy and Security Rules related to a 2016 data breach. On June 26, 2016, AOC was informed by a journalist that a database of patient records possibly belonging to AOC had been posted for sale online. Two days later, a hacker group contacted AOC, demanding payment in return for the stolen database. A forensic analysis ascertained that the hackers used a vendor’s credentials to access AOC’s systems. The compromised credentials were terminated on June 27, 2016, but the hackers were not effectively blocked for almost another month.
On July 29, 2016, AOC reported that the PHI of more than 200,000 individuals (including names, dates of birth, Social Security numbers, medical procedures, test results, and health insurance information) had been disclosed through the breach. OCR’s subsequent investigation revealed AOC’s “longstanding, systemic noncompliance with the HIPAA Privacy and Security Rules including failures to conduct a risk analysis, implement risk management and audit controls, maintain HIPAA policies and procedures, secure business associate agreements with multiple business associates, and provide HIPAA Privacy Rule training to workforce members.” As part of the settlement agreement, AOC entered into a two-year CAP that requires revisions to its policies and procedures, particularly those related to business associates, and training for its workforce members.
HIPAA Right of Access Settlements
Additionally, OCR announced settlements of five separate investigations as part of its HIPAA Right of Access Initiative (the “Initiative”). These settlements stem from allegations that healthcare providers failed to grant individuals access to their health records, as required by the HIPAA Privacy Rule. See 45 C.F.R. § 164.524. In all five cases, the providers agreed to pay various penalty amounts, ranging from $3,500 to $70,000, and take corrective actions in order to resolve allegations that they had failed to comply with the Privacy Rule’s right of access provisions.
In 2019, OCR established the Initiative as an enforcement priority focusing on individuals’ right to access their health records in a timely manner and at a reasonable cost. According to OCR, enforcement actions under the Initiative “are designed to send a message to the health care industry about the importance and necessity of compliance with the HIPAA Rules.” Settlement terms and monetary payments are based on numerous factors, including “the nature and extent of the potential HIPAA violation; the nature and extent of the harm resulting from the potential HIPAA violation; the entity’s history with respect to compliance with the HIPAA Rules; the financial condition of the entity, including its size and the impact of the COVID-19 public health emergency; and other matters as justice may require.” OCR has completed seven enforcement actions, including the five September settlements, under the Initiative since it was introduced.
In a new post on the Covington Inside Privacy blog, our colleagues discuss the passage of California’s AB 713, a bill that creates a new healthcare-related exemption under the California Consumer Privacy Act of 2018 (“CCPA”) for certain information that has been deidentified in accordance with the Health Insurance Portability and Accountability Act of 1996 (“HIPAA”). Importantly, this new patient-specific exemption is in addition to, and separate from, the CCPA’s current language that excludes from the scope of “personal information” certain “deidentified” information. (As a refresh, under the CCPA, deidentified information is information that cannot reasonably identify a particular consumer, provided that the business has put in places certain safeguards and processes identified in the statute to limit risk of reidentification.) Thus, there is now an alternative basis to argue that patient information that has been deidentified for purposes of HIPAA is also exempt from the CCPA’s obligations. To read the post, please click here.
On September 2, 2020, the U.S. Department of Health and Human Services Office for Civil Rights (“OCR”) announced a new “Health Apps” feature on the HHS.gov website. The new website, which replaces the OCR’s Health App Developer Portal, highlights existing guidance for mobile health (“mHealth”) apps regarding the Health Insurance Portability and Accountability Act (“HIPAA”) regulations.
The new website features OCR’s guidance for mHealth app developers and others who may be “interested in the intersection of health information technology and HIPAA privacy and security protections,” including:
- Mobile Health Apps Interactive Tool – A web-based tool created by OCR, in conjunction with the Federal Trade Commission and the Food and Drug Administration, to help health-related mobile app developers understand which federal laws and regulations may be applicable.
- Health App Use Scenarios & HIPAA – Guidance illustrating when a mHealth developer may be acting as a business associate under HIPAA.
- Access Rights, Apps, and APIs – FAQs on the HIPAA right of access, mobile apps, and application programming interfaces (APIs).
- Health Information Technology – FAQs relating to HIPAA and various aspects of health information technology.
- Guidance on HIPAA & Cloud Computing – Guidance to help covered entities and their business associates, including cloud services providers (“CSPs”), understand how to comply with the HIPAA requirements while using cloud computing technologies.
These new resources are OCR’s latest attempt to make the HIPAA regulations more relevant to rapidly evolving areas of health information technology.
The FTC has recently provided new guidance on the use of AI and algorithms, including a blog post that focuses on the benefits and risks of AI in the “Health AI” space. Former FTC Commissioner Terrell McSweeny, AI Initiative Co-Chair Lee Tiedrich, and Jadzia Pierce discuss the post, along with other AI-focused guidance from the FTC, in The Journal of Robotics, Artificial Intelligence and Law.
The National Institute of Standards and Technology (“NIST”) is seeking comments on the first draft of the Four Principles of Explainable Artificial Intelligence (NISTIR 8312), a white paper that seeks to define the principles that capture the fundamental properties of explainable AI systems. NIST will be accepting comments until October 15, 2020.
In February 2019, the Executive Order on Maintaining American Leadership in Artificial Intelligence directed NIST to develop a plan that would, among other objectives, “ensure that technical standards minimize vulnerability to attacks from malicious actors and reflect Federal priorities for innovation, public trust, and public confidence in systems that use AI technologies; and develop international standards to promote and protect those priorities.” In response, NIST issued a plan in August 2019 for prioritizing federal agency engagement in the development of AI standards, identifying seven properties that characterize trustworthy AI—accuracy, explainability, resiliency, safety, reliability, objectivity, and security.
NIST’s white paper focuses on explainability and identifies four principles underlying explainable AI.
- Explanation. AI systems must supply evidence, support, or reasoning for their outputs. Researchers have developed different models to explain AI systems, such as self-explainable models where the models themselves are the provided explanation.
- Meaningful. The recipient must understand the AI system’s explanation. This principle is a contextual requirement—for example, different types of user groups may require different explanations, or a particular user’s prior knowledge, experiences, and mental processes may affect meaningfulness. Hence, tailoring is necessary for effective communication.
- Explanation Accuracy. The explanation must correctly reflect the AI system’s process for generating its output. In contrast to decision accuracy, explanation accuracy is not concerned with whether or not the system’s judgment is correct. It is referencing how the system came to its conclusion. The principle is also contextual—there may be different explanation accuracy metrics for different types of groups and users.
- Knowledge Limits. The AI system must identify cases it was not designed or approved to operate, or where its answers are not reliable. This ensures that reliance on AI system’s decision processes occurs only where it is appropriate.
The white paper states that explanations generally can be described along two dimensions: the amount of time the consumer has to respond to the information and the level of detail in the explanation. Although flexibility in the range and types of explanations will be necessary, NIST provides a non-exhaustive list of explanation categories, drawing from academic literature:
- User Benefit. This type of explanation is designed to inform a user about an AI system output, such as providing the reason a loan application was approved or denied to the applicant.
- Societal Acceptance. This type of explanation is designed to generate trust and acceptance by society, to provide an increased sense of comfort in the system.
- Regulatory and Compliance. This type of explanation assists with audits for compliance with regulations, standards, and legal requirements, such as providing detailed explanation to a safety regulator to evaluate the output of self-driving cars.
- System Development. This type of explanation assists with developing, improving, debugging, or maintaining an AI system by technical staff and product managers.
- Owner Benefit. This type of explanation benefits the operator of a system, such as a recommendation system that lists movies to watch and explains the selection based on previously viewed items.
After explaining the core concepts of explainable AI systems, NIST explores the explainability of human decision processes. NIST states that humans demonstrate only a limited ability to meet the four principles described above, which provides a benchmark to evaluate explainable AI systems and informs the development of reasonable metrics. According to NIST, evaluating explainability in context of human decision-making also may lead to better understanding of human-machine collaboration and interfaces.
Although the white paper does not provide detailed guidance for organizations implementing AI systems, it represents an important step by NIST to develop trustworthy AI tools. Documents from other jurisdictions on explaining AI provide more detailed guidance aimed at helping organizations operationalize the concept of explainable AI. The UK Information Commissioner’s Office (“ICO”), for example, issued on May 20, 2020 its final guidance on explaining decisions made with AI. Similar to the NIST white paper, the ICO recognizes that there are different underlying principles to be followed and different models of AI explanation. The ICO takes these principles one step further, however, and provides more detailed guidance on how to explain AI in practice, depending on the type of AI system used.
Some Legislative Developments Relating to NIST
Efforts to advance the development of AI standards through NIST has been a topic of increasing focus in Congress. Recent bills include Sen. Cory Gardner’s (R-CO) Advancing Artificial Intelligence Research Act of 2020, which would appropriate $250 million to NIST for each of fiscal years 2021 through 2025 for the creation of a national program to advance AI research, and Rep. Eddie Bernice Johnson’s (D-TX-30) National Artificial Intelligence Initiative Act of 2020, which would appropriate over $50 million to NIST for each of fiscal years 2021 through 2025 for the research and development of voluntary standards for trustworthy AI systems, among other activities. The House Appropriations Committee also released the draft fiscal year 2021 Commerce, Justice, Science, and Related Agencies funding bill, where $789 million is included for core NIST research activities, an increase of $35 million above the FY 2020 enacted level.
To learn more about AI, please access our AI Toolkit.
On July 28, 2020, FDA announced the publication of a final guidance on Multiple Function Device Products: Policy and Considerations that outlines FDA’s evolving approach to the regulation of multiple function device products, including software.
The concept of “multiple function” products was introduced by the 21st Century Cures Act (“Cures Act”) of 2016, which added section 520(o) to the FD&C Act. Multiple function device products are those with multiple functions that each have a distinct purpose in the product (e.g., collection, storage, analysis) where only certain functions are actively regulated by FDA. With regard to software, section 520(o) of the FD&C Act gives FDA the authority to review the non-device function(s) of a multiple function device product to assess the impact of the non-device function(s) on the device function(s).
Here are the key takeaways on FDA’s newly-issued final guidance:
- While the Cures Act language distinguishes device functions from non-device functions, FDA adopts a final policy that distinguishes between device functions and other FDA says that “other functions” include not only non-device functions, but also device functions that are exempt from premarket review (i.e., 510(k)-exempt), as well as device functions that fall within FDA’s exercise of enforcement discretion.
- The same approach should apply to FDA’s assessment of all multiple function device products, whether software, hardware or both.
- For multiple function device products, manufacturers should perform impact assessments for all “other functions” to assess any effects of the other functions on the device functions of the product – reaching a conclusion of no impact, positive impact, or negative impact. These assessments should be documented as part of the device’s design validation process. In the event that an impact is found, the extent of the impact should be evaluated and included in the manufacturer’s hazard analysis.
- FDA expects that impact assessments be included as part of a premarket submission when there is a (i) negative impact or (ii) positive impact that the manufacturer seeks to include in the product’s labeling. For a finding of no impact or a positive impact that the manufacturer does not seek to include in the product’s labeling, FDA does not expect to see the impact assessment as part of the premarket submission, although FDA may review the documentation as part of an inspection.
- FDA broadly defines a potential “negative” impact of an “other function” on the device function(s). Thus, as a practical matter, it is likely that it will be difficult for a manufacturer to conclude that the “other functions” have no impact on the device function. We anticipate that manufacturers will need to submit impact assessments for a large number of multiple function device products.
- One open question is the possible impact of FDA determining that a company failed to submit an impact assessment that, in FDA’s view, was required as a part of the premarket review of a multiple function device product. For example, if a company makes a good faith determination that a non-device function has no impact on the device functions of a multiple function device product, and submits a 510(k) or PMA without an impact assessment, but FDA later disagrees with that determination, would the agency take the position that the 510(k)/PMA was ineffective and not properly obtained? Similarly, would FDA exercise enforcement discretion in such a situation to allow the company to keep the product on the market while it submits the impact assessment and other documentation associated with the non-device functions?
To help companies navigate these issues, FDA’s guidance provides several case studies of multiple function device products and what FDA would expect to see as part of a premarket submission for the device functions. Companies developing multiple function device products will want to ensure that they consider all aspects of the FDA’s final guidance.
On July 30, 2020, the UK Information Commissioner’s Office (“ICO”) published its final guidance on Artificial Intelligence (the “Guidance”). The Guidance sets out a framework for auditing AI systems for compliance with data protection obligations under the GDPR and the UK Data Protection Act 2018. The Guidance builds on the ICO’s earlier commitment to enable good data protection practice in AI, and on previous guidance and blogs issued on specific issues relating to AI (for example, on explaining decisions on AI, trade-offs, and bias and discrimination, all covered in Covington blogs).
Our colleagues at the Inside Privacy blog have summarized a proposed bill in California (the Genetic Information Privacy Act) that would impose certain privacy obligations on direct-to-consumer genetic testing companies that go beyond the California Consumer Privacy Act. This summary may be of interest to entities that process genetic data in California.
Software development can teach us a lot about streamlining the research and development (R&D) process in other industries. “Agile development”, or the process of dividing up an R&D project into smaller, more iterative segments instead of planning the entire project at its inception, is a hallmark of the software development process. In a recently published article in Food and Beverage Insider entitled “The ‘Agile’ Path to Market: An Alternative Approach to Food Industry R&D”, Nigel Howard and Chase Brennick show how agile development can be valuable for R&D in many different contexts. The article focuses on the suitability of agile development for R&D within the food industry, but illustrates the benefits of an agile R&D process for industries that are subject to evolving consumer preferences and rapidly changing regulatory landscapes – characteristics that are also present for companies in the digital-health space. As described in the article, agile development could be a powerful tool to help digital health companies make their R&D more nimble and maintain greater oversight of the development process on a near-real-time basis.