HIPAA De-Identification for AI Training: Safe Harbor vs Expert Determination

40 min readAIData.Broker research17 Oct 202667 records, 45 sources

Health information is de-identified under HIPAA, and so outside the Privacy Rule and its ban on selling patient data, only when it passes one of two tests in 45 CFR 164.514. The first, Safe Harbor, removes eighteen kinds of identifier of the patient and of the patient's relatives, employers and household members, and requires that the organisation has no actual knowledge that what remains could identify anyone. The second, Expert Determination, has a qualified expert find that the risk of identification is "very small" for the anticipated recipient and document the methods and results.

For AI training the choice matters more than it does for a research extract. Safe Harbor keeps only the year of any date tied to a patient and treats a name buried in a clinical note exactly like a name in a column, so it strips much of what makes clinical records and support conversations useful to a model. Expert Determination can keep more, but only for a named kind of recipient, with written evidence, and an AI lab is a recipient with an unusual amount of outside data to link against. Two further rules decide whether a sale can happen at all: a business associate may de-identify a client's data only where its business associate agreement permits it, and a limited data set is still protected health information, so it cannot be licensed to a model developer for profit.

This guide is for the founder, CFO or counsel of a company that holds health-related records: a provider, a health plan, a vendor that serves them, a digital health app, or any company whose support tickets mention patients. It covers both methods in the regulation's own words, where each Safe Harbor identifier hides in ordinary company systems, the rules on codes, limited data sets, sales and business associates, free text, the state laws beyond HIPAA, and what health-data buyers publish.

AIData.Broker acts as the holder's agent: the holder licenses its data to the buyer itself, and we do not take ownership of it. We do not take health information from care, insurance or a health client to market, as our de-identification standard says; but many company archives carry health data nobody planned for, and a holder needs to find it before any buyer sees a sample.

This guide is research from public sources, not legal advice.

Contents

  1. What de-identified means under HIPAA
  2. The two methods side by side
  3. Safe Harbor: the eighteen identifiers
  4. The no actual knowledge condition
  5. Expert Determination: what the expert does
  6. Re-identification codes
  7. Limited data sets are not de-identified
  8. Selling health data: the ban, and why de-identified data falls outside it
  9. Business associates: only where the agreement allows it
  10. Free text: the hard case
  11. State laws beyond HIPAA
  12. What health-data buyers publish
  13. Worked example: a software vendor to clinics
  14. Questions people ask
  15. What this means for you

What de-identified means under HIPAA

The HIPAA Privacy Rule protects protected health information (PHI): individually identifiable health information held or sent by a covered entity or its business associates, in any form. The de-identification standard is one sentence long. Section 164.514(a) says that health information "that does not identify an individual and with respect to which there is no reasonable basis to believe that the information can be used to identify an individual is not individually identifiable health information." Information that is not individually identifiable is not PHI, and the Rule states plainly that its requirements "do not apply to information that has been de-identified in accordance with the applicable requirements" of that section.

That is the whole prize. Once data is properly de-identified, the Privacy Rule's limits on use, disclosure and sale stop applying to it, and a holder may license it as it would any other business record (subject to contracts, state law and the rest of the rights work in our guide to selling customer data). The catch is in the word "properly". The standard is not met by a holder's good intentions or a vendor's label: Section 164.514(b) says a covered entity "may determine that health information is not individually identifiable health information only if" it follows one of the two methods. There is no third route, and the two are not interchangeable halves of one test.

Who HIPAA binds, and what it does not reach

HIPAA binds three kinds of covered entity: a health plan, a health care clearinghouse, and a health care provider that transmits health information electronically in a standard transaction. It also binds their business associates, the vendors that handle PHI on their behalf. A company that is neither, such as a fitness app dealing directly with consumers, is not subject to the Privacy Rule however sensitive its data; state law, covered below, fills that gap.

Some health information is outside PHI even inside a covered entity. The definition excludes information "in employment records held by a covered entity in its role as employer," education records covered by FERPA, and information about a person "deceased for more than 50 years." A hospital's HR files are therefore not PHI, though the rules on employee data still apply. A closed clinic's patient records stay PHI: the protection follows the records, not the business.

Creating de-identified data is itself a permitted use

Before data is de-identified it is PHI, so the act of de-identifying it needs a legal basis. The Rule supplies one: a covered entity "may use protected health information to create information that is not individually identifiable health information or disclose protected health information only to a business associate for such purpose." Two consequences follow for anyone planning a sale. The covered entity may hire a vendor to do the work, but only one bound by a business associate agreement. And a buyer that wants the raw records so that it can de-identify them for itself is asking for a disclosure of PHI the Rule allows only to a business associate working for the holder. The de-identification happens on the holder's side, before anything moves.

The two methods side by side

Safe Harbor is a checklist: cheaper, no outside expert, but the same cuts for every dataset whatever the recipient. Expert Determination is a judgment: tailored and keeps more, but it costs an expert's time, is tied to the recipient assessed, and rests on a written report the regulator can ask for.

For AI training, Safe Harbor's bluntness bites twice: its date rule destroys the sequence of events a model learns from, and every identifier inside a note or ticket must be found, which no tool does perfectly. Expert Determination does not escape the free-text problem, but it lets an expert keep dates shifted or coarsened, and weigh what a recipient could actually do with what is left.

Safe HarborExpert Determination
Legal text45 CFR 164.514(b)(2)45 CFR 164.514(b)(1)
Who decidesThe covered entity (or its business associate)A person with appropriate statistical and scientific knowledge and experience
The testEighteen kinds of identifier removed, and no actual knowledge that the rest could identify anyoneRisk that an anticipated recipient could identify anyone is "very small"
Dates tied to a patientYear only; ages over 89 grouped as 90 or olderWhatever the expert finds keeps the risk very small (often shifted or coarsened)
GeographyNothing smaller than a state, except a three-digit ZIP prefix covering enough peopleThe expert's call
Depends on the recipientNoYes: the analysis is for the anticipated recipients
Written evidenceNot required by the Rule (keep it anyway)Required: methods and results, available to the regulator on request
ExpiryNoneOften time-limited by the expert
Fit for AI trainingStructured fields where dates and places can goLongitudinal records, notes, tickets and anything where timing matters

Neither method requires the buyer to sign anything. HHS says the Rule "does not limit how a covered entity may disclose information that has been de-identified", but it adds that nothing prevents a holder from asking the recipient to sign a data use agreement that prohibits re-identification. For a licence to an AI developer, that clause is not optional in practice: California requires it for de-identified patient information whenever a party resides or does business in the state (see below), and an expert will usually make it one of the conditions the determination rests on.

Safe Harbor: the eighteen identifiers

Safe Harbor's list is short to read and long to apply. The rule requires that the following identifiers "of the individual or of relatives, employers, or household members of the individual" are removed. Here they are exactly as 45 CFR 164.514(b)(2)(i) lists them:

  • (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 a 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 directly related to an individual, including birth date, admission date, discharge date, date of death; 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;
  • (E) Fax numbers;
  • (F) Electronic mail addresses;
  • (G) Social security numbers;
  • (H) Medical record numbers;
  • (I) Health plan beneficiary numbers;
  • (J) Account numbers;
  • (K) Certificate/license numbers;
  • (L) Vehicle identifiers and serial numbers, including license plate numbers;
  • (M) Device identifiers and serial numbers;
  • (N) Web Universal Resource Locators (URLs);
  • (O) Internet Protocol (IP) address numbers;
  • (P) Biometric identifiers, including finger and voice prints;
  • (Q) Full face photographic images and any comparable images; and
  • (R) Any other unique identifying number, characteristic, or code, except as permitted by paragraph (c) of this section.

Then comes the second condition, which is easy to miss: the covered entity must not have actual knowledge "that the information could be used alone or in combination with other information to identify an individual who is a subject of the information." Removing the eighteen is necessary, not sufficient.

Where each identifier hides in company records

In a company archive the identifiers sit in email signatures, ticket fields, file names, log lines and attachments, written by people who never expected the text to leave the building. The table gives each identifier, what Safe Harbor requires, and where it commonly hides (illustrations from typical systems, not a complete inventory).

IdentifierSafe Harbor ruleWhere it commonly hides in company records
(A) NamesRemove the patient's, and relatives', employers' and household members'Ticket requester fields, email headers and signatures, chat mentions, call notes ("spoke with her daughter"), file names of scanned forms, CRM contacts
(B) GeographyNothing below state level; three-digit ZIP only for populous areas, else 000Shipping and billing addresses, clinic location fields, user profile city, time zone, IP geolocation in analytics, "patient lives near the depot" in notes
(C) DatesYear only for dates tied to the patient; ages over 89 grouped as 90 or olderAppointment, admission, claim and service dates; birth dates in forms; ticket and message timestamps on records about a patient; lab dates in attachments
(D) Telephone numbersRemoveCall logs, SMS reminders, voicemail transcripts, contact fields, signatures
(E) Fax numbersRemoveReferral faxes in e-fax inboxes, cover sheets, provider directories pasted into tickets
(F) Email addressesRemoveMessage headers, CC lists, forwarded threads, login and notification logs
(G) Social security numbersRemoveInsurance and enrolment forms, eligibility checks, identity-verification tickets, spreadsheets attached to email
(H) Medical record numbersRemoveIntegration logs and interface messages, support tickets quoting a patient's record, report exports
(I) Health plan beneficiary numbersRemoveEligibility and claims files, photos of insurance cards, billing disputes
(J) Account numbersRemovePatient billing accounts, payment processor references, collections notes
(K) Certificate/license numbersRemoveScans of driving licences used for identity checks, licence numbers typed into forms
(L) Vehicle identifiersRemoveTransport bookings, accident and injury claims, parking or mileage records
(M) Device identifiers and serial numbersRemoveMedical device telemetry, app installation and advertising IDs, device serials in support logs
(N) URLsRemovePatient portal links with tokens, personal websites, links to social profiles in notes
(O) IP addressesRemoveWeb and API server logs, login audit trails, product analytics events
(P) Biometric identifiersRemove, including voice printsRecorded calls and voicemails, video visits, fingerprint or face logins
(Q) Full face photosRemove, with comparable imagesProfile pictures, photos attached to tickets, identity document scans, wound or condition photos
(R) Any other unique number, characteristic or codeRemove, unless it is a code built under paragraph (c)Internal user and ticket IDs that map back, unkeyed hashes, barcodes, clinical trial record numbers, a unique job title or rare event

A few rows deserve a closer look, because they are where company archives fail Safe Harbor while looking clean.

The ZIP code and date rules

The geography rule allows the first three digits of a ZIP code only where all the ZIP codes sharing those digits together hold more than 20,000 people by current Census data; otherwise the prefix becomes 000. HHS published the list of prefixes that fail the test from 2000 Census data and warned not to rely on it "if more current data has been published." Our own standard turns 23 thinly populated prefixes into 000: the ones HHS listed plus those a recomputation from later Census data adds. City and county go too, so a ticket saying a patient "drove in from" a named town fails until the town is removed.

The date rule is stricter than most people expect. It covers every element of a date "directly related to an individual" except the year: the day and month of an appointment, an admission, a claim or a message about a patient. HHS gives the example that "January 1, 2009" may be reported only as 2009, and that dates of lab tests are PHI too. Ages over 89, and any date that would reveal one, collapse into one group of 90 or older; our standard groups ages from 90+ for the same reason. For a model learning how a case unfolds, every event lands in the same year-sized bucket.

Whose identifiers must go

The eighteen apply to the patient and to the patient's relatives, employers and household members. A note that names a patient's employer ("injured at the warehouse on Main Street") fails Safe Harbor through the employer even if the patient's own name is gone. The rule does not, however, require removing every name in a record. HHS says only the names of the subjects of the records and of their relatives, employers and household members must be suppressed, with no explicit requirement to remove clinicians' names. That is HIPAA's floor, not a buyer's: staff names are personal data under other laws and most buyers' terms, and our own standard replaces every mention of every person, staff included.

The catch-all: identifier (R)

The last item, "any other unique identifying number, characteristic, or code", is the one that turns Safe Harbor from a checklist back into a judgment. HHS explains that it covers codes derived from a non-secure encoding mechanism: "a code derived from a secure hash function without a secret key (e.g., 'salt') would be considered an identifying element." It also covers characteristics: HHS's example is a patient whose occupation is listed as "current President of State University." In company data, (R) catches the internal customer ID that a support agent can type into the admin panel, the ticket number that links back to an account, the device serial, and the unusual job title in a signature. The only codes that may stay are ones built under paragraph (c), covered below.

The no actual knowledge condition

The second limb of Safe Harbor is short but carries weight. HHS defines actual knowledge as "clear and direct knowledge" that the remaining information could identify someone: "a covered entity has actual knowledge if it concludes that the remaining information could be used to identify the individual." Its examples are concrete. A record that lists a patient's occupation as "former president of the State University" fails even with all eighteen identifiers gone, because almost any other fact would then identify the patient. A dataset fails if the holder knows the recipient is an employee with a relative in the data and enough context to recognise them. A record describing a rare, publicised clinical event fails because the event itself identifies the person.

The condition is not a duty to imagine every attack: HHS says a covered entity's "mere knowledge of these studies and methods, by itself, does not mean it has 'actual knowledge'". But a holder licensing to an AI buyer often knows its records describe a small, recognisable community (one clinic's patients, a niche app's users). Where it knows a passage would point to a particular person, Safe Harbor is not met until that passage goes. A holder who reads a sample and sees a recognisable story cannot later say it did not know.

Expert Determination: what the expert does

The first method, in 45 CFR 164.514(b)(1), has two parts. A person "with appropriate knowledge of and experience with generally accepted statistical and scientific principles and methods for rendering information not individually identifiable" must determine that "the risk is very small that the information could be used, alone or in combination with other reasonably available information, by an anticipated recipient to identify an individual," and must document "the methods and results of the analysis that justify such determination." Every phrase matters: the risk is assessed for an anticipated recipient, against reasonably available information, and the work is written down.

HHS's guidance of November 2012 fills in the practice, and it is the document an expert works from.

Who counts as an expert

There is no licence. HHS says "There is no specific professional degree or certification program for designating who is an expert at rendering health information de-identified", that experts "may be found in the statistical, mathematical, or other scientific domains," and that the regulator would look at the expert's professional experience, training and "actual experience of the expert using health information de-identification methodologies." In practice holders hire statisticians who specialise in disclosure risk, or firms that do nothing else. Picking someone without a track record in health data saves money at the point where the regulator will look hardest.

The four steps

HHS describes the work as a loop. "First, the expert will evaluate the extent to which the health information can (or cannot) be identified by the anticipated recipients. Second, the expert often will provide guidance" on statistical or scientific methods to reduce the risk. The expert then applies the methods the data managers accept, and finally evaluates the result "to confirm that the risk is no more than very small when disclosed to the anticipated recipients." HHS notes that the process "may require several iterations." The methods are the familiar ones: suppressing, generalising or perturbing values until "unique, identifiable elements no longer, or are not expected to, exist." Its principles for judging risk ask how stable a feature is, how available in outside sources, and how well it distinguishes one person.

What "very small" means

HHS sets no number. "There is no explicit numerical level of identification risk that is deemed to universally meet the 'very small' level", because the same dataset can be safe in one setting and unsafe in another. Experts therefore borrow thresholds from statistical practice and from other regulators. Our own standard uses the threshold the European Medicines Agency and Health Canada set for public clinical reports, which means no combination of quasi-identifiers shared by fewer than 11 people in a delivery. An expert may choose differently for a given recipient; the point is that a determination should state its threshold, and a holder should ask what it was.

Expiry, several recipients, and the paperwork

A determination is not forever. The Rule attaches no expiry, but HHS notes that "certain de-identification practitioners use the approach of time-limited certifications" because technology and the availability of outside data change. An expert may also prepare different versions of the same data for different recipients, and must then make sure that "the data sets cannot be combined to compromise the protections". That matters in this market, where the same records may be licensed to more than one buyer. And the documentation is not a courtesy: the Rule requires the methods and results to be documented and made available to OCR on request. Our standard requires the same of every release, with an evidence file that expires after a year or sooner when the data, the recipient or the known attacks change.

Why an AI buyer changes the analysis

For an AI developer, both the "reasonably available information" and the "anticipated recipient" are larger than for a research partner. A developer may hold web crawls and other companies' records, and may pass the data on: one buyer's published terms grant it rights "with the right to sublicense through multiple tiers", so the recipient is everyone downstream. The trained model is a recipient of sorts too. Research on language models has found that scrubbing "reduce [s] but do [es] not prevent the risk of PII leakage", because a model can memorise and repeat what a scrub missed.

A careful expert answers these points in the determination: naming permitted and onward recipients, requiring bans on re-identification and linking, requiring the buyer's controls on training and outputs, and setting an expiry. Our standard asks the same of every buyer ( the buyer's commitments) plus an independent test and certificate before each transfer.

What to ask the expert for

A holder commissioning a determination for an AI licence should expect, at minimum:

  • the recipient and use the determination covers (the buyer, its permitted sublicensees, training and evaluation), and what happens if they change;
  • the threshold chosen for "very small" and why;
  • the transformations applied: which fields were suppressed, generalised or perturbed, how dates were handled, how free text was treated;
  • the measured result: the smallest groups in the structured data, the recall measured on a random sample of free text, and what a person reading records found;
  • the conditions: contract terms the determination assumes (no re-identification, no linking, onward recipients bound, deletion);
  • an expiry date and the events that end the determination early.

Re-identification codes

Holders often want a way back from a de-identified record to the original, to fix errors, deliver updates or honour a deletion request. HIPAA allows it on strict terms. Under 45 CFR 164.514(c), a covered entity may assign "a code or other means of record identification to allow information de-identified under this section to be re-identified by the covered entity," provided the code "is not derived from or related to information about the individual and is not otherwise capable of being translated so as to identify the individual," and the covered entity "does not use or disclose the code or other means of record identification for any other purpose, and does not disclose the mechanism for re-identification."

Two failures are common. The first is a code derived from the person's data: a plain hash of a name, an email address or a medical record number. HHS treats a hash without a secret key as an identifier, because anyone can hash every candidate value and compare ( the guidance on hashed codes). The second is leaking the key. The Rule says that disclosing a code or other means designed to enable re-identification is itself a disclosure of PHI, and that re-identified data is PHI again. Our standard builds stand-ins from a keyed hash under a secret key the holder keeps, with a fresh key for each delivery so that two buyers' copies cannot be joined, and the key never leaves the holder's computer ( the rule).

Limited data sets are not de-identified

A limited data set is a halfway house that HIPAA created for research, public health and health care operations. It removes sixteen direct identifiers but keeps dates, town or city, state and ZIP code. The Rule is explicit about what it is: "A limited data set is protected health information". It may be used or disclosed "only for the purposes of research, public health, or health care operations," and only under a data use agreement.

The agreement limits uses, binds the recipient's agents and forbids it to "identify the information or contact the individuals." Because a limited data set is still PHI, the sale prohibition applies to it. The Rule's exception for research disclosures under a data use agreement applies only where "the only remuneration received" is a reasonable cost-based fee to cover the cost to prepare and transmit the data. A licence fee from an AI developer is not a cost-based fee. A holder who offers a buyer "a limited data set under a DUA" is offering PHI, and cannot be paid for it beyond cost.

Protected health informationLimited data setDe-identified data
Still PHI?YesYesNo
Dates and ZIP codeKeptKeptYear only and three-digit ZIP (Safe Harbor), or as the expert allows
Permitted purposesTreatment, payment, operations, and others the Rule listsResearch, public health, health care operationsAny, subject to contract and state law
Contract requiredBusiness associate agreement for vendorsData use agreementNone under HIPAA; advisable, and required in California for patient data
May be licensed for a feeOnly with each patient's authorizationResearch only, at costYes

Selling health data: the ban, and why de-identified data falls outside it

The Privacy Rule carries an express prohibition on selling PHI. Section 164.502(a)(5)(ii) says: "Except pursuant to and in compliance with ยง 164.508(a)(4), a covered entity or business associate may not sell protected health information." A sale is defined broadly as a disclosure of PHI "where the covered entity or business associate directly or indirectly receives remuneration from or on behalf of the recipient of the protected health information in exchange for the protected health information." The payment need not be cash, and it need not come straight from the recipient.

The exception is an authorization, and it is demanding. Section 164.508(a)(4) requires that "a covered entity must obtain an authorization for any disclosure of protected health information which is a sale," and that the authorization "must state that the disclosure will result in remuneration to the covered entity." That means a signed authorization from each patient, which for a training corpus is rarely practical. The Rule's list of disclosures that are not sales (public health, research at cost, treatment and payment, the sale or merger of the covered entity itself, payments to a business associate for its services) does not cover licensing patient records to a model developer.

Why de-identified data is outside the ban

The prohibition is a rule about PHI, and properly de-identified data is not PHI. Section 164.502(d)(2) says health information that meets the de-identification standard "is considered not to be individually identifiable health information, i.e., de-identified," and that "the requirements of this subpart do not apply" to it. So licensing de-identified data is not a sale of PHI and needs no authorization, which is also why the quality of the de-identification is the whole case: if the data is not in fact de-identified, every payment for it is a payment for PHI.

Three edges catch holders: a re-identification key that travels with the data is a disclosure of PHI; a buyer that re-identifies holds PHI again and, in California, breaks a statutory ban; and a business associate needs its contract's permission to create the de-identified set at all.

Business associates: only where the agreement allows it

Many holders of health data are vendors: scheduling and billing software, transcription, analytics, call centres, cloud hosts. Each is a business associate when it handles PHI on behalf of a covered entity, and its rights in the data are borrowed. The Rule says it "may use or disclose protected health information only as permitted or required by its business associate contract or other arrangement" or as required by law. And the contract itself must "establish the permitted and required uses and disclosures" of PHI by the business associate.

De-identifying a client's PHI is a use of PHI, so a business associate may do it for its own purposes only where its agreement permits, and may use the result only as the agreement allows. Many agreements say nothing, and silence is not permission; some allow it only to serve the client or with the client's written consent; others allow it "for any lawful purpose." A vendor with many clinic customers may have many templates to read. Our rights checklist puts the question first for any data from health care, health insurance or work done for a health client: confirmation that the business associate agreement permits de-identified use, alongside the choice of method and a data use agreement banning re-identification.

Reading a business associate agreement for an AI licence

Look for four things: whether it permits de-identification at all; whether it limits what may be done with de-identified data (some bar commercial use); which method it requires (some specify Safe Harbor, some want to approve the expert); and what happens at termination, since a duty to return or destroy PHI when the service ends can make a closing vendor's archive impossible to de-identify afterwards. Silent agreements can be amended; they cannot be read as a yes. For vendors that are closing, the timing questions are in our guide to customer data in bankruptcy.

Free text: the hard case

A labelled column is coarsened in one step. Notes, tickets, chats, emails and call recordings are where de-identification fails, and they are the records AI buyers value most, because they carry reasoning in natural language. HIPAA gives free text no discount. HHS says the standard "makes no distinction between data entered into standardized fields and information entered as free text" and that "an identifier listed in the Safe Harbor standard must be removed regardless of its location in a record if it is recognizable as an identifier."

HHS's examples show the line: a note that the patient "is the Executive Vice President of the state university" must go; a stand-alone "Newark, NJ," whose meaning is unclear, may stay. HHS also warns that "clinical narratives in which a physician documents the history and/or lifestyle of a patient are information rich and may provide context that readily allows for patient identification." Context is the danger: a note can identify someone with no name in it at all.

Company free text is harder than clinical free text

Company records follow no conventions. A support ticket at a health software vendor may quote a patient's name and appointment time pasted from a clinic's screen, a screenshot with a record number, and a family member's phone number in a forwarded chain. A chat may name a patient by first name only, which matches no list. A call recording carries the speaker's voice, and voice prints are a Safe Harbor identifier in their own right ( item (P)): the recording itself cannot be de-identified by removing words, which is why our standard sets voices and faces aside unless the people in them consented, and rewrites transcripts instead.

No single detector handles this. The method that works combines several kinds of evidence: the people a system lists in its own structure (senders, requesters, users, contacts), found wherever they are mentioned; patterns checked against each identifier's format; dictionaries of names and places; and the holder's own lists of clients, codenames and terms ( the layered rule). A person must count as protected only when every mention of them is replaced, because one missed mention identifies them in all the others. Then a person reads records drawn at random: our standard reads 300 random records before a delivery, enough that, with nothing found, the share of records still holding an identifier is bounded below a stated level ( the review rule), and runs a second, independent check before anything can leave. Our de-identification tool scores an F1 of 86.8% on hand-annotated company Slack, email and document exports ( the published benchmark): good, not perfect, which is why the human reading and the expert's test sit on top of it.

The content itself

Health information also turns up where nobody filed it: an HR thread about medical leave, a complaint that mentions a diagnosis. It is not PHI outside a covered entity or business associate, but it is sensitive data under state law and most buyers' terms. Our standard flags records about health, children, beliefs and other special categories for the holder to read and leave out unless it may share them ( the content screen). A law firm advising holders on these sales has told them to exclude privileged, HR, payroll, health, union and customer-confidential material rather than rely on de-identification. For company archives that are mostly not about health, that is usually the right call: take the health material out whole, and sell the rest.

State laws beyond HIPAA

HIPAA is a floor that covers only covered entities and their business associates. Two state laws matter most to a holder of health-related data that falls outside it, or that wants to license HIPAA-de-identified data to a buyer with a presence in the state.

Washington: the My Health My Data Act

Washington's law, RCW 19.373, reaches the health data HIPAA leaves out. Consumer health data means "personal information that is linked or reasonably linkable to a consumer and that identifies the consumer's past, present, or future physical or mental health status," and it includes health facts "derived or extrapolated from nonhealth information" by means "including algorithms or machine learning." A shopping app that infers a pregnancy holds consumer health data. The Act protects Washington residents and anyone whose data is collected there, but not people acting in an employment context.

Its sale rule is strict. Since 31 March 2024, "it is unlawful for any person to sell or offer to sell consumer health data concerning a consumer without first obtaining valid authorization from the consumer." The authorization is a signed document naming the data, the seller, the purchaser and the purpose; no corpus can be built that way. De-identified data is outside the Act on its own terms: the holder must take reasonable measures, publicly commit not to re-identify, and bind recipients by contract ( the definitions). The Act also exempts PHI under HIPAA, and information de-identified under HIPAA that derives from the health care information the section lists. A violation is an unfair or deceptive act under the Consumer Protection Act, which consumers can enforce as well as the attorney general.

California: de-identified patient information

The CCPA carves out PHI and treats de-identified patient information separately. Under Civil Code 1798.146, information is outside the CCPA if it is "deidentified in accordance with the requirements for deidentification set forth in Section 164.514" of the HIPAA rules and derives from patient information originally held by an entity regulated by HIPAA, California's medical confidentiality law or the federal Common Rule. Re-identified information loses that status.

Civil Code 1798.148 then does two things a holder must build into the licence. It bars any "business or other person" from re-identifying, or attempting to re-identify, such information, outside a short list of purposes such as public health, Common Rule research and contracted testing of the de-identification. And it requires that "any contract for the sale or license of deidentified information" of this kind, "where one of the parties is a person residing or doing business in the state," include three provisions, or substantially similar ones: a statement that the data includes de-identified patient information; a statement that re-identification and attempted re-identification by the purchaser or licensee is prohibited; and a requirement that the purchaser or licensee may not disclose the data to a third party unless that party is bound by the same or stricter terms. Any licence to a developer doing business in California needs them, so in practice every licence of de-identified patient data should carry them.

For California consumer data that is not patient information, the CCPA's general definition of deidentified applies, which, like Washington's, requires reasonable measures, a public commitment not to re-identify, and contracts binding recipients ( the rights check and our commitment rule).

Federal: the bulk sensitive data rule

One more federal rule applies whatever the de-identification. The Justice Department's rule on bulk sensitive personal data restricts transfers of US persons' health and other sensitive data, above set volumes, to buyers owned by or located in countries of concern. Our checklist screens every buyer, and anyone it may pass the data to, against it ( the bulk data screening). A health dataset licensed to a buyer that sublicenses through several tiers needs that screening to run down the chain.

What health-data buyers publish

The table summarises what health-data buyers and intermediaries say on their own pages or in filings, as read by our research, with price signals where a party stated one.

Buyer or intermediaryWhat it does with health dataWhat it says about de-identificationPrice signal, as stated
ProtegeLicenses healthcare and media data to AI developers"de-identification, certification, and tokenization" before sharing, worked out with the partnerA revenue share, percentage not published; transaction volume reported by its CEO
Tempus AILicenses de-identified clinical and molecular records to drug developersDescribes the licensed records as de-identifiedAnnual licence fees in Recursion's annual report; committed payments in the 2026 extension
Gradient HealthConnects healthcare data partners with AI developersDe-identified multimodal medical data through its platformNot published
SegmedLicenses imaging exams from healthcare sites to AI developersHolds de-identified imaging exams at scaleNot published
OneMedNetSupplies de-identified imaging records and clinical reports for model developmentDescribes the records as de-identifiedAn initial contract reported by the trade press
Shfa.aiBrokers healthcare companies' data to AI buyersNot stated in our recordsIts own headline range per medical facility and one payout it claims
KledBuyer program for patient-shared conversationsPatients share their own conversationsA letter of intent it announced itself

Three patterns stand out. First, none of these sources states the method (Safe Harbor or Expert Determination), the threshold or a measured result; ask each buyer, and put the answer in the licence. Second, most price signals here are a party's own claims or press reports; Recursion's annual report is the exception, a filing stating what one drug developer agreed to pay for de-identified oncology records. Third, the strongest public precedent on how a sale should be structured comes from outside health care: in the Spirit Airlines bankruptcy sale, payment was due only on delivery of de-identified data certified by an independent agent, to the CCPA standard and to the HIPAA standard for any health data ( the payment gate), and the estate preferred that structure to a higher bid that would have de-identified in-house ( who controls de-identification is worth money).

Healthcare companies are also among the holders whose records are on offer through brokers: 6 of the brokered company-record lots in our lot index come from healthcare. For the wider buyer landscape, see the buyers page and our guide to the companies that buy training data.

Worked example: a software vendor to clinics

Example. A 60-person company sells scheduling and patient messaging software to physical therapy and dental clinics, each under a business associate agreement. An AI buyer asks for "all of your support and messaging data." Its systems: a ticketing tool, a team chat workspace, a product database of appointments and messages, call recordings from its support line, and its own source code and engineering wiki.

Step 1: Sort what is PHI. The appointments and patient messages are PHI held as a business associate, and so are the parts of tickets, chats and calls where clinic staff pasted patient details. The source code and engineering wiki are not, provided nobody pasted patient data into them, which the company must check rather than assume.

Step 2: Read every business associate agreement. The company finds three templates: one permits de-identification "for any lawful purpose," one only to serve the clinic, one is silent. Only data from clinics on the first template can be de-identified for an outside licence; for the rest it must get amendments or leave the data out, because silence is not permission ( the business associate rule). Where agreements require destruction at termination, the work must happen before shutdown or not at all.

Step 3: Choose the method. Safe Harbor would leave each appointment with a year and a three-digit ZIP prefix, useless for learning how scheduling works over weeks, and voices cannot stay in call recordings. The company commissions an expert determination scoped to the buyer and its permitted sublicensees, which keeps shifted dates, and replaces call audio with rewritten transcripts.

Step 4: Handle the free text. It de-identifies tickets and chats on its own systems, links each person's mentions to one stand-in under a key it keeps, reads a random sample, and has the expert test the result. Threads that tell a recognisable story about a patient come out whole. Staff names are replaced too, because the buyer's terms and other privacy laws require it even where Safe Harbor does not.

Step 5: Write the licence. Because a party does business in California, the licence states that the data includes de-identified patient information, bans re-identification and attempted re-identification, and binds onward recipients to the same terms ( Civil Code 1798.148). It adds the expert's conditions, a ban on linking with other data, deletion of the copy, the buyer's controls on training and outputs, and bulk data screening of the buyer and its sublicensees.

Step 6: Sell what is clean. The code and engineering records, once checked, are a separate and simpler lot ( our guide to selling a codebase), and the kind AIData.Broker takes to market. The PHI-bearing records, if they go at all, go through a specialist health-data licensor with the expert determination attached.

Questions people ask

What are the 18 HIPAA identifiers? They are listed in 45 CFR 164.514(b)(2)(i), items (A) to (R): names; geographic subdivisions smaller than a state; elements of dates except the year; telephone and fax numbers; email addresses; social security, medical record, health plan beneficiary, account and certificate or licence numbers; vehicle and device identifiers; URLs; IP addresses; biometric identifiers; full-face photos; and any other unique identifying number, characteristic or code. They must be removed for the patient and for relatives, employers and household members.

Is de-identified data still PHI? No. Health information that meets the de-identification standard by either method is not individually identifiable, and the Privacy Rule does not apply to it. It becomes PHI again if it is re-identified, and disclosing the re-identification key is a disclosure of PHI.

Can a hospital or health plan sell de-identified data to an AI company? HIPAA does not forbid it, because the sale prohibition applies only to PHI. The data must genuinely meet one of the two methods, and state law may add conditions, such as California's contract terms.

What is the difference between Safe Harbor and Expert Determination? Safe Harbor removes a fixed list of eighteen identifiers and requires no actual knowledge that the rest identifies anyone; it is the same for every recipient. Expert Determination has a qualified expert find a very small risk for the anticipated recipient and document it; it keeps more detail but applies only to the recipient and conditions it was made for.

Who can do an expert determination? Anyone with the right knowledge and experience: HHS says there is no degree or certification that designates an expert, and the regulator would look at the expert's training and actual experience de-identifying health information. Statisticians who specialise in disclosure risk are the usual choice.

How long is an expert determination valid? The Rule sets no expiry, but HHS notes that many experts issue time-limited certifications. A determination also stops covering a release if the recipient or the use changes from what the expert assessed.

Is a limited data set de-identified? No. A limited data set is still PHI: it keeps dates and ZIP codes, may be used only for research, public health or health care operations under a data use agreement, and cannot be licensed for more than a cost-based fee.

What this means for you

The order of work is fixed by the law: whether HIPAA applies, then whether you may de-identify, then how, and only then whether to license. A buyer who asks for raw records first is asking you to skip the steps that make the sale lawful.

  1. Map where health data sits. Not only the product database: tickets, chats, email, call recordings and attachments. Our readiness check walks through the systems, and the pages on Zendesk, Intercom and Slack cover each system's own export and AI terms.
  2. Decide whether HIPAA applies. A covered entity or business associate holds PHI; a direct-to-consumer app usually does not, but Washington and California may reach it.
  3. Read every business associate agreement before touching client data. No express permission to de-identify, no outside licence. The full checklist is in our rights check on health data and on the rights hub.
  4. Pick the method per dataset: Safe Harbor where dates and places can go, an expert's determination for longitudinal records and free text.
  5. Do the work on your side. De-identify before anything leaves, keep any re-identification key yourself, and never send a buyer an unreviewed sample. Our de-identification tool runs on your own computer and follows our standard; for PHI it is a first pass, not a substitute for the expert.
  6. Write the protections into the licence. No re-identification, no linking, onward recipients bound, deletion of the copy, and California's patient-data clauses. Our guide to data licensing agreements and the licence terms page set out the rest.
  7. Document it. Write a datasheet for the lot and keep the expert's report, the sample review and the agreements in the rights file: buyers increasingly ask for that record, as our guide to training data provenance explains.

If most of your archive is not health data, the cleanest path is often to take the health material out whole and license the rest. For how the rest sells, start with the guide to selling company data to AI labs and what different records are worth.

This guide is research from public sources, not legal advice.

The evidence

What this guide rests on

Every number above links to its record, and every record to the page it was read from, with that page's own words. This guide cites 67 records and 6 derived figures, read from 45 sources. How we source and check them.

3 buyer contract clauses
1 vendor's stated offering
37 laws and rulings
6 derived figures
  • 23 thinly populated ZIP prefixes written as 000
  • 90+ age from which ages are grouped
  • 11 smallest group a delivery may contain
  • 300 random records read before a delivery
  • 86.8% F1 on company Slack, email and documents
  • 6 companies' records on offer from healthcare

In this topic

Rights and law

  1. Start hereCan this data legally be sold or licensed for AI training?Privacy law, copyright and fair use, software vendors' terms, de-identification, bankruptcy sales and what a licence agreement holds.
  2. GuideIs It Legal to Sell Customer Data? A US Guide for AI TrainingOften yes, but through layers: your privacy policy, the FTC Act, state and sector laws, and customer contracts. De-identified records are the main lawful path.
  3. GuideFair Use and AI Training: What US Courts Have RuledUS courts are split: training was fair use in Bartz v. Anthropic and Kadrey v. Meta, not in Thomson Reuters v. Ross, and pirated copies lost. Where each stands.
  4. GuideIs It Legal to Scrape Data for AI Training? (US Law, 2026)Scraping public pages is rarely a federal crime after Van Buren and hiQ, but contract, copyright, anti-circumvention and privacy law apply. Resale is hard.
  5. GuideCan a Company License Employee Emails and Slack for AI Training?Usually yes for business records the company controls, but only after it handles monitoring notices, third parties in the messages, privilege and vendor terms.
  6. GuideSelling Customer Data in Bankruptcy: Section 363 ExplainedA bankrupt company can sell customer data only if the sale fits its privacy policy, or a court-appointed privacy ombudsman reports and the judge approves it.
  7. GuideWhat Is a Data Licensing Agreement? The Terms for AI TrainingA data licensing agreement lets a buyer use data for set purposes while the holder keeps ownership. Each clause AI buyers ask for, and where holders stand.
  8. GuideHIPAA De-Identification for AI Training: Safe Harbor vs Expert DeterminationHealth data leaves HIPAA only through Safe Harbor (remove 18 identifiers) or an expert's determination of very small risk. How each works for AI training.
  9. RegisterLawsuits and rulingsEvery case, ruling and settlement over training data.
  10. RegisterLicence termsWhat buyers ask for in a licence, and where holders stand.
  11. PageDe-identification standardOur rules for removing people from records, each with its source.
  12. RegisterAI crawler censusA daily census of robots.txt across the most visited sites.

The AI data market, weekly

Issues go out on Mondays: the prices, deals, buyers and rulings that moved in the market for AI training data, each with its source.

Free. Issues go out on Mondays, and every one has a link to leave. Subscribing means you accept our terms and privacy policy.

HIPAA De-Identification for AI Training: Safe Harbor vs Expert Determination | AIData.Broker