On this page
Published: · Updated:
Key Takeaways
- De-identification and anonymization are legally distinct, HIPAA permits the former, GDPR requires the latter to escape privacy-law scope.
- HIPAA offers two paths: Safe Harbor (remove 18 identifiers) or Expert Determination (statistical proof of low re-identification risk).
- Under GDPR, if re-identification is reasonably possible using means reasonably likely to be used, the data is still personal data, pseudonymization is not anonymization.
- Medical device telemetry (device serials, timestamps, IP addresses, waveform fingerprints) frequently defeats naive de-identification.
- For AI/ML training data, document data provenance and applicable privacy safeguards for the submission; a PCCP is not universally required.
- Choose the technique based on downstream use: internal analytics, external research, public release, or model training each carry different risk thresholds.
HIPAA de-identification requires Safe Harbor removal of specified identifiers plus no actual knowledge of remaining identifiability, or a documented Expert Determination of very small re-identification risk. Masking direct identifiers alone is insufficient. Under GDPR Recital 26, anonymity depends on all means reasonably likely to be used for identification; pseudonymized data remains personal data.
Medical device manufacturers routinely ship data off-device: infusion logs to the cloud, imaging studies to a research partner, waveforms to an AI training pipeline. The privacy law that governs that data depends on how thoroughly the identifiers are stripped, and the two terms most teams use interchangeably (de-identification and anonymization) mean very different things to HIPAA regulators, EU DPAs, and FDA reviewers.
Getting this wrong is expensive. Data you called "anonymized" that a regulator later classifies as "still personal data" pulls your entire cloud pipeline back into GDPR scope, retroactively. And AI training on improperly de-identified data can invalidate the training set your PCCP depends on.
This guide covers the legal distinction, the medical-device pitfalls that break naive de-identification, and how to pick the right technique for internal analytics, external research, public release, and model training.
Why this matters for medical devices
Connected medical devices generate a firehose of data that leaves the device: audit logs, telemetry, imaging, waveforms, event streams, and, increasingly, training data for on-device or cloud AI models. Assess each flow against applicable privacy laws. HIPAA depends on covered-entity or business-associate status; GDPR and state-law scope and exemptions require separate analysis.
The FDA's cybersecurity guidance is not a HIPAA de-identification standard. Document data provenance and data-management methods appropriate to the submission and any proposed PCCP, and separately assess applicable privacy law. ISO 14971 addresses risks related to safety; privacy compliance is not automatically equivalent to a safety risk analysis.
Treating "de-identified" and "anonymized" as synonyms hides that risk. Regulators do not.
What is de-identification under HIPAA?
HIPAA defines two paths to de-identify Protected Health Information (PHI). Under Safe Harbor (45 CFR § 164.514(b)(2)), a covered entity or business associate removes all 18 specified identifier categories, names, geographic subdivisions smaller than a state, most date elements, phone numbers, SSNs, medical record numbers, device identifiers and serial numbers, IP addresses, biometric identifiers, full-face photos, and any other unique identifying number, characteristic, or code, and has no actual knowledge that the remaining data could identify an individual.
The alternative is Expert Determination (§ 164.514(b)(1)): a person with appropriate statistical and scientific knowledge and experience applies accepted principles to conclude that the risk of re-identification is "very small" and documents the methodology.
HIPAA de-identification is a US regulatory safe harbor, not a mathematical guarantee. The data is no longer PHI, but a motivated attacker with auxiliary data can still sometimes re-identify individuals. That residual risk is legally acceptable under HIPAA; it may not be under GDPR.
Device identifiers and serial numbers are on the Safe Harbor list. That means the device UDI, MAC address, or serial you use to route telemetry in your cloud must be removed or replaced only in accordance with the applicable de-identification rules; hashing alone does not establish Safe Harbor compliance.
What is anonymization under GDPR?
GDPR Recital 26 sets a much higher bar. Data is anonymous, and therefore outside GDPR, only if the data subject is not or is no longer identifiable by "all the means reasonably likely to be used" by the controller or any other person. The test explicitly accounts for the cost of re-identification, available technology at the time of processing, and technological developments.
Two consequences follow. First, pseudonymization is not anonymization. Replacing MRNs with random tokens, or hashing device serials with a stored key, still leaves the data as personal data under GDPR, Article 4(5) says so explicitly. Second, the standard is dynamic: a dataset that was anonymous in 2020 may be personal data in 2026 as re-identification techniques and auxiliary datasets improve.
Do not assume that removing direct identifiers establishes GDPR anonymity. Assess reasonably likely means of identification, available auxiliary data, and the recipient context.
De-identification vs anonymization: side-by-side
| Dimension | De-identification (HIPAA) | Anonymization (GDPR) |
|---|---|---|
| Process | Strip or mask 18 identifier categories (Safe Harbor) or statistical proof of low risk (Expert Determination) | Irreversibly transform so no reasonable means can re-identify |
| Re-identification risk | "Very small", residual risk accepted | Not reasonably possible using means reasonably likely to be used |
| Data utility | High, preserves demographics, dates in year-only form, most clinical detail | Often low, generalization, suppression, or noise degrade utility |
| Reversibility | Permitted if a re-identification key exists and is separately protected | Not permitted, no key can exist |
| US legal effect | Data is no longer PHI; HIPAA no longer applies | N/A |
| EU legal effect | Assess separately under GDPR; HIPAA status alone does not establish anonymity | Outside GDPR scope if Recital 26 criteria are met |
| Typical use | Research, AI training, internal analytics, business associate flows | Public dataset release, statistical publication |
| Submission consideration | Document relevant data provenance and methods; a PCCP is not universally required | Document applicable data methods and separately assess GDPR transfer rules |
The single most important row is the last-but-one: HIPAA de-identified data is not GDPR-anonymous. If you have EU patients in your dataset, HIPAA Safe Harbor alone does not get you out of GDPR.
Why medical device data is uniquely hard to de-identify
See also: Medical Device Data Sovereignty: HIPAA, GDPR, and Hospital Reviews, CLIA Lab Cybersecurity: HIPAA & 21 CFR Part 11 (2026), and HIPAA and Medical Device Manufacturers.
Generic de-identification advice assumes tabular EHR data, remove name, remove MRN, generalize ZIP. Medical device data breaks that model in ways that Safe Harbor checklists miss:
- Device serials and UDIs are direct identifiers (Safe Harbor category 14). Every telemetry packet keyed by serial number carries a re-identification vector unless handled in accordance with the applicable de-identification method; hashing alone does not establish compliance.
- Timestamps in event logs can uniquely fingerprint a patient, sleep-apnea CPAP usage patterns, insulin pump bolus timing, or pacemaker interrogation cadence. Truncating to year (Safe Harbor's date rule) destroys most clinical utility.
- Waveform data (ECG, EEG, PPG) contains biometric identifiers under Safe Harbor category 17. Recent research shows short ECG segments can re-identify individuals against reference datasets with high accuracy.
- DICOM imaging carries identifiers in header tags (PatientName, PatientID, StudyDate, InstitutionName, sometimes burned into pixel data). Naive de-identification that only handles a subset of DICOM tags leaks PHI.
- IP addresses in device logs are Safe Harbor category 15, and geolocate to a household.
- Rare conditions create k-anonymity failures, a single patient in a ZIP with a rare device implant may be unique in the dataset even after identifier removal.
A defensible de-identification pipeline for medical devices addresses each of these explicitly, not just the tabular fields.
What FDA guidance recommends for AI/ML training data
The FDA's AI/ML lifecycle guidance and PCCP framework do not mandate a specific de-identification technique, but they do expect you to document:
- Data provenance, where the training and validation data came from, including consent basis and de-identification methodology.
- Representativeness, that de-identification did not distort the demographics or clinical distribution the model must generalize across.
- Data lineage into deployment, whether the deployed model can receive new data that is re-identifiable, and how that data is handled.
- Change-control impact, under a PCCP, if you plan to retrain on new data, the de-identification and consent basis for that future data must be described up front.
Describe the actual data handling and its limitations. An unsupported anonymity claim can prompt questions, but no particular request or review outcome is inevitable.
Which technique for which use case
| Use case | Recommended technique | Why |
|---|---|---|
| Internal analytics inside your covered-entity boundary | Pseudonymization with access controls | Data stays PHI but is minimized; supports incident investigation |
| External research partner (US-only patients) | HIPAA Safe Harbor de-identification + data-use agreement | Removes HIPAA obligations while preserving utility |
| Complex research needing dates or geography | HIPAA Expert Determination | Preserves utility Safe Harbor destroys |
| AI/ML training data (US) | HIPAA de-identification + documented residual risk assessment | Meets FDA provenance expectations |
| AI/ML training data including EU patients | Anonymization or explicit GDPR lawful basis (consent, research exemption) | HIPAA de-ID is not enough for GDPR |
| Public dataset release | True anonymization with k-anonymity / differential privacy | Highest bar, assume adversarial re-identification attempts |
| Postmarket telemetry to cloud | Pseudonymization with a separately protected key | Preserves ability to investigate device incidents |
Match the technique to the downstream use, then document the choice in your risk file and your submission.
How Blue Goat Cyber approaches de-identification for medical devices
We integrate de-identification into the security risk management flow required by ANSI/AAMI SW96:2023 and ISO 14971, not as a separate privacy checkbox. Our team, with CISSP, OSCP, and prior military red-team backgrounds, evaluates the specific device data flows (telemetry, logs, imaging, waveforms) against HIPAA Safe Harbor, HIPAA Expert Determination, and GDPR anonymization criteria, then documents the residual re-identification risk for the premarket submission and the PCCP.
Our commitment: if the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed.
Related reading: CLIA High-Complexity Lab Cybersecurity: HIPAA, 21 CFR Part 11, & LIMS Guide.
FAQ
Related reading
- AAMI TIR57 vs TIR97 vs SW96: Which Applies to Your Device?
- AI/ML PCCP cybersecurity: what to include
- FDA Section 524B subsections explained
- EU MDR vs FDA cybersecurity guide
Ready to lock down your data pipeline?
Talk to our team about a de-identification and privacy review scoped to your device's actual data flows, telemetry, imaging, and AI training pipelines, mapped to HIPAA, GDPR, and FDA expectations. Schedule an expert consultation.
Christian Espinosa, Founder & CEO, Blue Goat Cyber., former US Air Force cyber warfare officer. Two decades leading medical device cybersecurity, FDA submissions, and privacy risk assessments for connected health platforms. More about the author.
About the author
Christian Espinosa, MBA · Founder & CEO, Blue Goat Cyber
U.S. Air Force Academy graduate and veteran with 30+ years in cybersecurity. Founded Alpine Security in 2014 (acquired 2020), then Blue Goat Cyber in 2022. Blue Goat track record: 275+ FDA submissions supported, zero cybersecurity rejections. Author of three books including The Smartest Person in the Room. Ironman triathlete and mountaineer.
Sources & references
Primary sources cited in this article. Links open in a new tab.
- 1- hhs.gov
- FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)- U.S. FDA
- FDA, Postmarket Management of Cybersecurity in Medical Devices (2016)- U.S. FDA
- CISA Known Exploited Vulnerabilities Catalog- CISA
- FDA draft guidance, Artificial Intelligence-Enabled Device Software Functions (January 2025)- U.S. FDA
