Data Annotation Consent & Licensing: HIPAA, GDPR & IP

Here is the counterintuitive part of data annotation consent: a labeled clinical dataset can be more legally entangled than the raw data you started with. One de-identified interview transcript, tagged with severity ratings, can carry four separate sets of rights at once—the participant’s consent, the privacy law that governs the words, the license on whatever scale or scheme you coded against, and the intellectual-property claim of whoever created the labels. Get any one of them wrong and the dataset you spent months building may be one you cannot lawfully share, sell, or even keep.

This guide maps data annotation consent and the licensing questions that follow it, end to end: informed consent and lawful basis, HIPAA de-identification versus a Business Associate Agreement, GDPR special-category data, who owns the labels, and how to license the finished set. It is written for the people who actually have to answer these questions—pharma and digital-health teams, lab directors, and the annotators doing the work. It is not legal advice, and it says so clearly wherever the law is unsettled.

The fastest way to see the shape of the problem is to lay the two big regimes side by side. Most teams work under US rules, EU rules, or both, and the obligations map onto annotation work differently than they map onto ordinary clinical care.

Obligation	US: HIPAA + Common Rule	EU: GDPR	What it means for annotation
Is interview text regulated?	PHI if it holds any of the 18 identifiers (45 CFR 164.514)	Health data is special-category personal data (Art. 9)	Regulated until you de-identify or genuinely anonymise it
Lawful basis to process	Privacy Rule rules; research needs IRB plus consent or waiver (45 CFR 46)	An Art. 6 basis AND an Art. 9(2) condition	You need a basis before annotators ever see the data
De-identification standard	Safe Harbor (18 identifiers) or Expert Determination (164.514(b))	Anonymisation must be irreversible; pseudonymised data stays personal (Recital 26)	The GDPR bar is higher than HIPAA Safe Harbor
Secondary / research use	Broad-consent option for storage plus future research (45 CFR 46.116)	Research condition Art. 9(2)(j) with Art. 89 safeguards	Consent for care is not consent to annotate for AI
Cloud vendor handling data	Business Associate Agreement required (164.502(e), 164.308(b))	Data processing agreement required (Art. 28)	No BAA or DPA means no lawful cloud processing of identifiable data
Who owns the labels	Contract plus work-for-hire rules (17 U.S.C. 101)	Copyright plus sui generis database right (Dir. 96/9/EC)	Ownership is set by contract, not by who typed

Data annotation consent: the four rights that stack

Before you annotate sensitive data, four distinct rights have to clear, and each is governed by a different body of law. Consent and lawful basis decide whether you may process the data at all.

Privacy law—HIPAA in the US, the GDPR in the EU—decides how, and whether de-identification lets you step outside it. Licensing decides what you may do with the coding scheme and the finished dataset. Intellectual-property and labor rules decide who owns the labels themselves.

A failure in any one of the four can sink the project. Treating them as a single undifferentiated “privacy” problem is the most common and most expensive mistake, because the fixes are different: consent is solved with paperwork before collection, de-identification with process before upload, ownership with contracts before work starts, and licensing with a decision before release. Miss the order and you find out at the end, when the dataset is built and the flaw is baked in.

Do you have consent to annotate this data?

You have consent to annotate data when the participant agreed to this use, or when the law gives you another lawful basis for it. The trap is secondary use: consent to be recorded for clinical care, or for a single study, does not automatically cover re-coding that recording to build an AI training set. That is a new purpose, and purpose is what consent is measured against.

In the US, the 2018 revision of the Common Rule added a broad-consent option that lets participants agree up front to the storage, maintenance, and secondary research use of their identifiable data (45 CFR 46.116). An Institutional Review Board can also waive consent under defined conditions. Neither is a formality you can assume—both are decisions for your IRB, made before the annotation starts.

Under the GDPR, lawfulness has two layers for health data. You need an Article 6 lawful basis (consent, legitimate interests, and so on), and because health data is a special category, you also need a condition under Article 9(2)—most often the data subject’s explicit consent for a specified purpose, or the scientific-research condition in Article 9(2)(j), which comes with the safeguards of Article 89 (data minimisation, pseudonymisation, and organisational controls). When the original consent is silent on annotation, the honest position is that you may not have a basis yet. That is a call for an ethics committee or a data protection officer, not for the person running the labeling job.

For the tooling side of handling sensitive interviews, see the companion guide to clinical transcript annotation tools.

HIPAA: de-identify first, or sign a BAA

Under US law you have two clean paths for interview text that contains protected health information: take it out of HIPAA’s scope by de-identifying it, or keep it in scope and sign a Business Associate Agreement with every vendor that touches it. There is no third path where you upload identifiable patient interviews to a cloud tool that has not signed a BAA.

De-identification has two accepted methods. Safe Harbor removes the 18 listed identifiers—names, dates finer than a year, geographic detail below a state, record numbers, and the rest. Expert Determination has a qualified expert—someone with appropriate knowledge of generally accepted statistical and scientific principles, commonly a statistician—certify that the re-identification risk is very small (45 CFR 164.514(b)). Data that meets either standard is no longer protected health information, and the Privacy Rule’s restrictions no longer apply (45 CFR 164.514(a)).

De-identify the transcript first, and the BAA question largely disappears—which is why de-identification is the default for research annotation, as covered in the guide to preparing and de-identifying clinical data.

If you must keep data identifiable, the alternative is contractual. When a vendor creates, receives, maintains, or transmits PHI on your behalf, HIPAA requires a signed Business Associate Agreement (45 CFR 164.502(e); 164.308(b)). And there is no such thing as HIPAA-certified software: the HHS Office for Civil Rights warns explicitly that it does not endorse private HIPAA “certifications,” so a vendor page claiming to be “HIPAA compliant” is a self-description, not a regulator’s stamp.

GDPR: special-category data and the anonymisation bar

Under the GDPR, data concerning health is special-category personal data (Article 9): processing is prohibited unless you have both an Article 6 lawful basis and an Article 9(2) condition, such as explicit consent or the scientific-research condition with the safeguards of Article 89. De-identification helps, but the anonymisation bar is higher than HIPAA’s, and getting this wrong is where cross-border projects come unstuck.

Recital 26 draws the line: data-protection principles fall away only for information rendered anonymous so that the person is no longer identifiable, judged against “all the means reasonably likely to be used” to re-identify them, given current technology and cost. Anything short of that is still personal data. Pseudonymisation—replacing names with codes—reduces risk but does not reach anonymity, because the mapping still exists somewhere.

The practical consequence catches people out: stripping HIPAA’s 18 identifiers does not automatically make data GDPR-anonymous. A transcript scrubbed of names can still be identifiable through a rare diagnosis, an unusual life event, or a code that links back to a key. And when a processor handles that personal data for you, Article 28 requires a data processing agreement—the GDPR’s structural parallel to a BAA. The safe assumption for interview data is that it remains personal data under GDPR until a qualified assessment says otherwise.

Who owns the annotations?

Ownership of annotations is decided by contract and IP law, not by who did the labeling. Raw facts are generally not protected by copyright, but the annotation layer—your choice of scheme, the judgment encoded in each label, the selection and arrangement of the dataset—can attract copyright, and in the EU a database can attract a separate right entirely.

That EU right is the sui generis database right created by Directive 96/9/EC. It protects the maker of a database who made a substantial investment in obtaining, verifying, or presenting the contents, and it lets them prevent extraction or re-use of a substantial part—independent of whether the database qualifies for copyright, for fifteen years (Directive 96/9/EC, Article 7). So a carefully annotated dataset can be doubly protected in Europe: copyright in the creative labeling, plus the database right in the compiled whole.

Here is the distinction that trips teams up. Owning the labels and having the right to release the dataset are different questions. You can hold clear IP in your annotations and still be barred from publishing the set by the consent that governs the underlying records.

Ownership answers “can I stop others from copying this?”; release rights answer “am I allowed to share it at all?”—and privacy law, not IP law, controls the second. Whether your specific labels clear the originality bar for copyright is exactly the kind of fact-specific question to put to counsel.

Annotator IP and labor: who holds the rights to the labels?

Whether the annotator or the organization owns the labels turns on employment status and what the contract says. Under US law, a work made for hire is owned by the employer from the moment of creation—but the doctrine is narrower than most teams assume, and assuming it applies to contractors is a frequent, costly error.

The US Copyright Office sets out the two situations (Circular 30; 17 U.S.C. 101). The first is work prepared by an employee within the scope of employment. The second is a specially ordered or commissioned work that falls into one of nine enumerated categories and is covered by a signed written agreement stating it is work for hire. An independent contractor’s or crowd worker’s output usually fits neither, which means that, absent a written assignment, the contractor can retain copyright in the labels they produced.

The fix is simple and belongs in the contract, not the afterthought pile: an explicit IP-assignment clause with every contractor, vendor, and crowd worker, plus a read of the labeling platform’s own terms of service, which may claim or disclaim rights on your behalf. This is also where compliance meets labor ethics—clear terms and fair pay are part of treating annotators as the skilled contributors they are, a point examined in does pay improve annotation quality. The picture differs outside the US: many jurisdictions recognise inalienable moral rights and vary on employer ownership, so a clause that works in Delaware will not necessarily hold in Berlin. Treat cross-border annotator IP as counsel territory.

Licensing your annotated dataset: Creative Commons and DUAs

To share a labeled dataset, you pick a license that tells others what they may do with it—commonly a Creative Commons license or a bespoke data use agreement. But a license only governs the rights you actually hold; it cannot fix a consent or privacy defect in the underlying data. That single sentence prevents most licensing mistakes.

Creative Commons offers six license types plus a public-domain tool, differing along two axes: whether commercial use is allowed (NC = noncommercial only) and whether derivatives are (ND = no derivatives; SA = share-alike copyleft). CC0 is a public-domain dedication that waives rights entirely.

License	Commercial use?	Derivatives?	Fit for a labeled dataset
CC0	Yes	Yes (no conditions)	Maximum reuse; use only if you truly hold all rights and there is no privacy issue
CC BY	Yes	Yes, with attribution	Common open-data choice; requires credit
CC BY-SA	Yes	Yes, share-alike	Derivatives must carry the same license (copyleft)
CC BY-NC	No	Yes, noncommercial	Blocks commercial reuse, including some industry research
CC BY-ND	Yes	No	Poor fit—datasets exist to be built on
CC BY-NC-ND	No	No	Most restrictive; rarely appropriate for data

For sensitive or restricted data, the usual instrument is not an open license at all but a data use agreement (DUA): a contract that grants specific, limited access under conditions—permitted uses, access controls, a ban on re-identification, deletion terms. HIPAA itself contemplates this: a limited data set, which retains some indirect identifiers, may be shared for research only under a data use agreement (45 CFR 164.514(e)). When your data is too sensitive to open-license but too valuable to lock away, a DUA is how you thread it. Which route fits is a rights-and-sensitivity judgment worth making explicitly, alongside how you plan to adjudicate disputed labels before release.

A worked example (synthetic)

Consider a synthetic scenario. A lab has 200 therapy-session transcripts; participants consented to “this research study.” The team wants to publish a version annotated with MADRS depression ratings and TLC thought-and-language codes, as an open benchmark. Walk the four rights and the plan writes itself.

Interviewer: How has your mood been over the past week?

Subject: Flat, mostly. I keep starting things and then the thread just goes somewhere else and I lose it.

Consent: “this study” almost certainly does not cover an open-benchmark release for AI training—a new purpose. Escalate to the IRB: broad consent, re-consent, or a waiver decision, before anything else. Privacy: de-identify to Safe Harbor (US) and assess GDPR anonymisation separately if any participant is in the EU. IP: confirm the annotators signed IP assignments so the lab owns the labels. Licensing: even with clean ownership, an open CC license is only appropriate if the consent and privacy layers both clear; if they do not, a data use agreement with vetted researchers is the realistic path. Four rights, four checkpoints, in order.

A pre-release compliance checklist

Run this before any labeled dataset leaves your control. Each item maps to one of the four rights, and each is a decision to document, not merely to intend.

1. Consent covers the use. Confirm the participant consent covers annotation and secondary research use, or get an IRB/ethics decision (broad consent, re-consent, or waiver).
2. Lawful basis established. US: Privacy Rule plus Common Rule. EU: an Article 6 basis and an Article 9(2) condition.
3. De-identify before annotation. Safe Harbor or Expert Determination (US); assess genuine anonymisation separately (EU) where feasible.
4. Agreements in place for identifiable data. A BAA (US) or a data processing agreement (EU, Article 28) with every vendor that touches identifiable data.
5. IP assigned in writing. An IP-assignment clause from every employee, contractor, and crowd worker; check the platform’s terms.
6. Ownership vs. release rights separated. Confirm not just that you own the labels but that you are permitted to share the dataset.
7. License matched to rights and sensitivity. An open CC license only when both rights and privacy clear; otherwise a data use agreement.
8. Chain documented. Record consent, de-identification method, agreements, and license so the dataset is auditable end to end.

Where Tagaroo fits, and how it handles data

Full disclosure applies here as much as anywhere: Tagaroo makes annotation software, so treat what follows as posture, not a compliance verdict for your project. On data handling, Tagaroo takes the de-identify-first path this guide argues for, rather than positioning itself as a PHI processor. Its terms require you to strip direct identifiers before upload; its anonymous trial mode runs entirely in the browser, so trial transcripts never leave your machine; and the stack is EU-hosted and GDPR-oriented.

It is not a medical device, and any AI pre-label is a first pass for a qualified human to review, never a substitute for clinical judgment. Tagaroo does not advertise a Business Associate Agreement, so if your workflow must process raw PHI in the cloud under a signed BAA, that is a question to settle with any vendor—including this one—before uploading identifiable data. The specifics of data handling are set out in Tagaroo’s privacy policy. For a wider view of clinical data preparation, the medical image annotation guide covers the same de-identify-first discipline for imaging.

The practical upshot

Data annotation consent and licensing is not one problem but four, and they resolve in order: consent before collection, de-identification before upload, ownership before work starts, licensing before release. The teams that get burned are the ones who treat it as a single “privacy” checkbox at the end, then discover the dataset they built cannot be shared. The teams that ship treat each right as its own gate, document the decision, and escalate the genuinely legal questions to people qualified to answer them.

If you change one thing, change the order: decide the compliance path first, then choose tools and schemes that fit it. When you are ready to code against validated instruments with the evidence trail these audits require, explore the Scale Library or start a browser-side trial where your data never leaves your machine.

References

• U.S. Department of Health & Human Services, Office for Civil Rights. Guidance Regarding Methods for De-identification of PHI (45 CFR 164.514(a)-(b): Safe Harbor and Expert Determination). HHS.gov: De-identification guidance
• U.S. Department of Health & Human Services. Business Associate Contracts (45 CFR 164.502(e), 164.504(e), 164.308(b)). HHS.gov: Business Associates
• U.S. Department of Health & Human Services, Office for Civil Rights. Be Aware of Misleading Marketing Claims (no HHS-recognized HIPAA “certification”). HHS.gov: Misleading Marketing Claims
• U.S. Department of Health & Human Services, Office for Human Research Protections. Federal Policy for the Protection of Human Subjects (the Common Rule), 45 CFR part 46, incl. 46.116 informed consent and broad consent. HHS.gov: 45 CFR 46
• Regulation (EU) 2016/679 (GDPR), Article 6: Lawfulness of processing. gdpr-info.eu: Article 6
• Regulation (EU) 2016/679 (GDPR), Article 9: Processing of special categories of personal data. gdpr-info.eu: Article 9
• Regulation (EU) 2016/679 (GDPR), Article 28: Processor (data processing agreement). gdpr-info.eu: Article 28
• Regulation (EU) 2016/679 (GDPR), Article 89: Safeguards for research processing. gdpr-info.eu: Article 89
• Regulation (EU) 2016/679 (GDPR), Recital 26: Anonymous information and pseudonymisation. gdpr-info.eu: Recital 26
• Creative Commons. About CC Licenses (CC BY, BY-SA, BY-NC, BY-NC-SA, BY-ND, BY-NC-ND) and CC0. creativecommons.org: CC licenses
• Directive 96/9/EC on the legal protection of databases, Article 7 (the sui generis right). EUR-Lex: Directive 96/9/EC
• U.S. Copyright Office. Circular 30: Works Made for Hire (17 U.S.C. 101). copyright.gov: Circular 30