HIPAA Compliance & Protecting Healthcare Data Using Private AI

Jun 8, 2023
Share this post
Sharing to FacebookSharing to LinkedInSharing to XSharing to Email

Healthcare organizations are required to perform a delicate balancing act between healthcare data protection and disclosure of high utility data to further research and innovation leading to better healthcare services. There will often be a trade-off between these two interests, as excluding or altering data in an effort to protect individuals’ privacy regularly comes at the expense of data utility.

Thankfully, the Health Insurance Portability and Accountability Act (HIPAA) provides guidance that prescribes what needs to be done to protect data privacy when disclosure of healthcare data is at issue. The legislation thus made a binding determination on what information must be excluded from a data set in order to sufficiently lower the risk of re-identification of individuals whose data is contained in the data set.

This blog post sets out the HIPAA Safe Harbour compliance requirements, presents Private AI’s approach to meet them, and illustrates this in a case study on how Private AI helped Providence to safely train conversational AI models on de-identified healthcare data. We conclude with an explanation of general non-technical principles that can be used to assess a data set from a re-identification risk perspective.

What is Considered Healthcare Data

Under HIPAA, protected health information (PHI) captures not only information that relates to an individual’s mental or physical health but also any personally identifiable information (PII) that appears alongside such health related information. For further details, refer to our blog post titled “What is PHI?

HIPAA Safe Harbour Compliance

In healthcare, mismanaged data can result in massive fines and long-lasting damage to a company’s reputation. One way to mitigate fines and protect the institution’s reputation is to comply with HIPAA’s Safe Harbour rule.

Despite the name, compliance with this rule does not entirely protect against audits by Health and Human Services (HHS) or financial penalties in case of data breaches. Audits are, however, reduced in length and extent, and fines are lowered. In addition, compliance will add considerable protection against security incidents and data breaches. You can read about the important cost factor of regulatory compliance in our recent blog post Cost of a Data Breach.

The Safe Harbour rule lists 18 entities that need to be removed in order to de-identify healthcare data which can then be shared with a third party.

  • - 164.514(2)(i) The following identifiers of the individual or of relatives, employers, or household members of the individual, are removed:

(A) Names

(B) All geographic subdivisions smaller than a state, including street address, city, county, precinct, ZIP code, and their equivalent geocodes, except for the initial three digits of the ZIP code if, according to the current publicly available data from the Bureau of the Census:

(1) The geographic unit formed by combining all ZIP codes with the same three initial digits contains more than 20,000 people; and

(2) The initial three digits of a ZIP code for all such geographic units containing 20,000 or fewer people is changed to 000

(C) All elements of dates (except year) for dates that are directly related to an individual, including birth date, admission date, discharge date, death date, and all ages over 89 and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age 90 or older

(D) Telephone numbers

(L) Vehicle identifiers and serial numbers, including license plate numbers

(E) Fax numbers

(M) Device identifiers and serial numbers

(F) Email addresses

(N) Web Universal Resource Locators (URLs)

(G) Social security numbers

(O) Internet Protocol (IP) addresses

(H) Medical record numbers

(P) Biometric identifiers, including finger and voice prints

(I) Health plan beneficiary numbers

(Q) Full-face photographs and any comparable images

(J) Account numbers

(R) Any other unique identifying number, characteristic, or code, except as permitted by paragraph (c) of this section [Paragraph (c) is presented below in the section “Re-identification”]; and

(K) Certificate/license numbers

Private AI identifies and redacts all 18 of these entities with higher than human accuracy and directly on premise, meaning that a healthcare organization’s data never leaves its environment. While building the system, Private AI recognized the need for robustness to optical character recognition (OCR) mistakes, grammar errors, and spelling mistakes. The following medical record displays these capabilities:

Case Study

To find out more about how Private AI has helped healthcare organizations become HIPAA compliant, download our healthcare case study.

Re-Identification Risk

Aside from the removal of the listed 18 entities from the data set, HIPAA’s Safe Harbour rule also requires that the regulated healthcare organization have no actual knowledge that the information, once disclosed, could be used alone or in combination with other information to identify an individual who is a subject of the information.

The HHS advises that the determination of actual knowledge has to be made with the particular anticipated information recipient in mind. For example, if the regulated entity knows that the data recipient has detailed information on an individual whose data is included in the data set, e.g., because he or she is a family member of the data recipient, and would be able to identify the individual despite all 18 entities having been removed from the data set, this would constitute actual knowledge under the Safe Harbour rule. Furthermore, if the regulated entity is made aware of the fact that the data recipient possesses technology that is able to re-identify individuals from the data set, this would likewise mean that the entity is not able to disclose the information to this recipient in a manner that is compliant with the Safe Harbour rule.

On the other hand, HHS also maintains that the general knowledge that such technology exists does not constitute actual knowledge in this sense. It must rather be assessed whether the particular data recipient has access to such technology.

Determining the re-identification risk is difficult enough when there is only one data recipient and the risk can be mitigated with data use or restricted access agreements. The task becomes that much harder when the data set is to be disclosed semi-publicly, i.e., to anyone with the requirement to register with the healthcare organization and to abide by certain terms of use, or publicly without any restriction. These three different release models need to be considered when assessing the risk of re-identification before disclosing a data set.

There are many more factors that need to be considered when determining the risk of re-identification of individuals whose information is to be disclosed in a data set. From a non-technical perspective, and without an attempt to be exhaustive, here are three general principles to be mindful of when evaluating a data set’s re-identification risk exposure:

1. Replicability

Information about an individual that is unlikely or impossible to change exposes the individual to a higher risk of re-identification if disclosed. Since information such as date of birth, blood type, or health card number are stable, they will consistently appear in records along with other information about the individual. This makes it possible to map different records about the individual on top of each other, combining different pieces of information about the individual and thus elevating the risk that a health record can be matched with directly identifiable information.

A person’s ZIP code, or blood pressure, on the other hand, are variable and hence may differ across different records containing information about the individual. Hence, such information is less risky to maintain in a health record that is supposed to be disclosed.

2. Date source availability

When considering the risk of re-identification, it is paramount not to only consider whether there is no identifiable information inadvertently left in the health data that is to be disclosed. It must also be determined what other data sources exist and are accessible to the data recipient which may be containing further information on the individuals whose information appear in the data set at issue. If these external data sources contain replicable information, it must be ensured that the data that is to be disclosed cannot be enriched with this information in a way that identifies the individuals.

Commonly available data sources containing replicable information are voter records, birth, and marriage registries. And you may have heard of this huge data repository called social media.

3. Distinguishability

The third principle under which to assess the re-identification risk is the distinguishability of the individual by means of the available data. Determining the distinguishing characteristics of an individual is not as straightforward as it may seem. The combination of 5-digit ZIP code, gender, and date of birth can uniquely identify 87 percent of the U.S. population, and features such as scars or rare diseases can also distinguish an individual fairly straightforwardly.

Conclusion

It will require considerable technical and statistical expertise to determine with certainty whether a data set is sufficiently de-identified for its disclosure to entail a low risk of re-identification. However, the identification and removal of PHI need not be difficult. Private AI can make this part of the task quick and effortless. To see the tech in action, try our web demo, or request an API key to try it yourself on your own data.

Data Left Behind: AI Scribes’ Promises in Healthcare

Data Left Behind: Healthcare’s Untapped Goldmine

The Future of Health Data: How New Tech is Changing the Game

Why is linguistics essential when dealing with healthcare data?

Why Health Data Strategies Fail Before They Start

Private AI to Redefine Enterprise Data Privacy and Compliance with NVIDIA

EDPB’s Pseudonymization Guideline and the Challenge of Unstructured Data

HHS’ proposed HIPAA Amendment to Strengthen Cybersecurity in Healthcare and how Private AI can Support Compliance

Japan's Health Data Anonymization Act: Enabling Large-Scale Health Research

What the International AI Safety Report 2025 has to say about Privacy Risks from General Purpose AI

Private AI 4.0: Your Data’s Potential, Protected and Unlocked

How Private AI Facilitates GDPR Compliance for AI Models: Insights from the EDPB's Latest Opinion

Navigating the New Frontier of Data Privacy: Protecting Confidential Company Information in the Age of AI

Belgium’s Data Protection Authority on the Interplay of the EU AI Act and the GDPR

Enhancing Compliance with US Privacy Regulations for the Insurance Industry Using Private AI

Navigating Compliance with Quebec’s Act Respecting Health and Social Services Information Through Private AI’s De-identification Technology

Unlocking New Levels of Accuracy in Privacy-Preserving AI with Co-Reference Resolution

Strengthened Data Protection Enforcement on the Horizon in Japan

How Private AI Can Help to Comply with Thailand's PDPA

How Private AI Can Help Financial Institutions Comply with OSFI Guidelines

The American Privacy Rights Act – The Next Generation of Privacy Laws

How Private AI Can Help with Compliance under China’s Personal Information Protection Law (PIPL)

PII Redaction for Reviews Data: Ensuring Privacy Compliance when Using Review APIs

Independent Review Certifies Private AI’s PII Identification Model as Secure and Reliable

To Use or Not to Use AI: A Delicate Balance Between Productivity and Privacy

To Use or Not to Use AI: A Delicate Balance Between Productivity and Privacy

News from NIST: Dioptra, AI Risk Management Framework (AI RMF) Generative AI Profile, and How PII Identification and Redaction can Support Suggested Best Practices

Handling Personal Information by Financial Institutions in Japan – The Strict Requirements of the FSA Guidelines

日本における金融機関の個人情報の取り扱い - 金融庁ガイドラインの要件

Leveraging Private AI to Meet the EDPB’s AI Audit Checklist for GDPR-Compliant AI Systems

Who is Responsible for Protecting PII?

How Private AI can help the Public Sector to Comply with the Strengthening Cyber Security and Building Trust in the Public Sector Act, 2024

A Comparison of the Approaches to Generative AI in Japan and China

Updated OECD AI Principles to keep up with novel and increased risks from general purpose and generative AI

Is Consent Required for Processing Personal Data via LLMs?

The evolving landscape of data privacy legislation in healthcare in Germany

The CIO’s and CISO’s Guide for Proactive Reporting and DLP with Private AI and Elastic

The Evolving Landscape of Health Data Protection Laws in the United States

Comparing Privacy and Safety Concerns Around Llama 2, GPT4, and Gemini

How to Safely Redact PII from Segment Events using Destination Insert Functions and Private AI API

WHO’s AI Ethics and Governance Guidance for Large Multi-Modal Models operating in the Health Sector – Data Protection Considerations

How to Protect Confidential Corporate Information in the ChatGPT Era

Unlocking the Power of Retrieval Augmented Generation with Added Privacy: A Comprehensive Guide

Leveraging ChatGPT and other AI Tools for Legal Services

Leveraging ChatGPT and other AI tools for HR

Leveraging ChatGPT in the Banking Industry

Law 25 and Data Transfers Outside of Quebec

The Colorado and Connecticut Data Privacy Acts

Unlocking Compliance with the Japanese Data Privacy Act (APPI) using Private AI

Tokenization and Its Benefits for Data Protection

Private AI Launches Cloud API to Streamline Data Privacy

Processing of Special Categories of Data in Germany

End-to-end Privacy Management

Privacy Breach Reporting Requirements under Law25

Migrating Your Privacy Workflows from Amazon Comprehend to Private AI

A Comparison of the Approaches to Generative AI in the US and EU

Benefits of AI in Healthcare and Data Sources (Part 1)

Privacy Attacks against Data and AI Models (Part 3)

Risks of Noncompliance and Challenges around Privacy-Preserving Techniques (Part 2)

Enhancing Data Lake Security: A Guide to PII Scanning in S3 buckets

The Costs of a Data Breach in the Healthcare Sector and its Privacy Compliance Implications

Navigating GDPR Compliance in the Life Cycle of LLM-Based Solutions

What’s New in Version 3.8

How to Protect Your Business from Data Leaks: Lessons from Toyota and the Department of Home Affairs

New York's Acceptable Use of AI Policy: A Focus on Privacy Obligations

Safeguarding Personal Data in Sentiment Analysis: A Guide to PII Anonymization

Changes to South Korea’s Personal Information Protection Act to Take Effect on March 15, 2024

Australia’s Plan to Regulate High-Risk AI

How Private AI can help comply with the EU AI Act

Comment la Loi 25 Impacte l'Utilisation de ChatGPT et de l'IA en Général

Endgültiger Entwurf des Gesetzes über Künstliche Intelligenz – Datenschutzpflichten der KI-Modelle mit Allgemeinem Verwendungszweck

How Law25 Impacts the Use of ChatGPT and AI in General

Is Salesforce Law25 Compliant?

Creating De-Identified Embeddings

Exciting Updates in 3.7

EU AI Act Final Draft – Obligations of General-Purpose AI Systems relating to Data Privacy

FTC Privacy Enforcement Actions Against AI Companies

The CCPA, CPRA, and California's Evolving Data Protection Landscape

HIPAA Compliance – Expert Determination Aided by Private AI

Private AI Software As a Service Agreement

EU's Review of Canada's Data Protection Adequacy: Implications for Ongoing Privacy Reform

Acceptable Use Policy

ISO/IEC 42001: A New Standard for Ethical and Responsible AI Management

Reviewing OpenAI's 31st Jan 2024 Privacy and Business Terms Updates

Comparing OpenAI vs. Azure OpenAI Services

Quebec’s Draft Regulation Respecting the Anonymization of Personal Information

Version 3.6 Release: Enhanced Streaming, Auto Model Selection, and More in Our Data Privacy Platform

Brazil's LGPD: Anonymization, Pseudonymization, and Access Requests

LGPD do Brasil: Anonimização, Pseudonimização e Solicitações de Acesso à Informação

Canada’s Principles for Responsible, Trustworthy and Privacy-Protective Generative AI Technologies and How to Comply Using Private AI

Private AI Named One of The Most Innovative RegTech Companies by RegTech100

Data Integrity, Data Security, and the New NIST Cybersecurity Framework

Safeguarding Privacy with Commercial LLMs

Cybersecurity in the Public Sector: Protecting Vital Services

Privacy Impact Assessment (PIA) Requirements under Law25

Elevate Your Experience with Version 3.5

Fine-Tuning LLMs with a Focus on Privacy

GDPR in Germany: Challenges of German Data Privacy (Part 2)

Comply with US Executive Order on Safe, Secure, and Trustworthy Artificial Intelligence using Private AI

How to Comply with EU AI Act using PrivateGPT