Healthcare AI's Data Privacy and Regulatory Essentials: Personal Data Protection, De-identification, Software as a Medical Device (SaMD), and Governance Checklist

A regional hospital deployed an AI-assisted diagnostic system for radiology. The model performed accurately, prototypes ran cleanly, and clinicians were prepared to adopt it. Implementation stalled when the IT director posed three questions in a project meeting: "We're sending these images to the cloud for training, does the patient consent form cover that scope? Is this actually a medical device? Who's liable if something goes wrong?"

Those three questions revealed a common inflection point: technical development is straightforward. Data privacy and regulatory compliance are what determine whether a healthcare AI project launches. This document addresses four areas, personal data protection, de-identification, SaMD classification, and internal governance, as concrete checklists for IT and compliance teams.

First, the part everyone skips: how data protection law applies

Taiwan's Personal Data Protection Act classifies medical records, healthcare information, health examination data, and genetic data as Article 6 special-category personal data. These categories are prohibited from collection, processing, and use except where statutory exceptions apply: written patient consent, healthcare providers acting for medical purposes, or government agencies using de-identified data for statistical research. Healthcare AI projects cannot reuse standard consumer-data consent workflows.

For IT teams, the key checkpoints are:

• Does the original consent form or privacy notice cover purposes like "AI analysis" and "model training"? If not, you must notify patients of new purposes, obtain updated consent, or establish another legal basis.
• Is data leaving the hospital (cloud APIs, external annotation services, model vendors)? Cross-border transfers require regulatory compliance review, a data processing agreement (DPA), and clear allocation of processor responsibilities.
• Does data collection follow the minimum necessary principle? If the model requires only images, exclude names, medical record numbers, and other identifiers.
• Document retention and deletion procedures: specify how long original training data persists after model development, whether patients can exercise deletion rights, and incorporate this into written procedures rather than relying on institutional memory.

De-identification: it's not just blacking out names

Legally, de-identification means data become "impossible to identify the specific individual and irreversible." Common implementation errors assume that pixelation and name removal accomplish de-identification. The actual risk is re-identification: a rare diagnosis, specific surgery date, hospital stay window, and postal code cross-referenced together can identify an individual.

Verification points for de-identification:

• Have direct identifiers (name, ID number, medical record number, contact information) been removed or irreversibly hashed?
• Have quasi-identifiers (birthdate, visit date, region, rare diagnosis codes) been generalized or suppressed? Has re-identification risk been formally assessed?
• Have DICOM image metadata containing patient information been stripped? Have text labels burned into images (burned-in annotations) been handled?
• Is a lookup table retained? If a reversible key exists, the data are pseudonymized, not de-identified, legal obligations differ. Document your actual data status.

Whenever a dataset is claimed de-identified, conduct third-party re-identification testing. Vendor assurance alone is insufficient.

SaMD classification: your AI might be a medical device

AI systems intended for diagnosis, treatment decisions, or patient monitoring fall under Software as a Medical Device (SaMD) regulation and require Taiwan FDA approval and registration. Classification depends on the claimed medical purpose and degree of clinical decision impact, not on technical sophistication.

Compliance teams should confirm the product's medical claims language, map it to the risk tier in the table above, verify vendor regulatory approval if SaMD classification applies, establish whether model updates require resubmission, and understand post-market performance monitoring obligations. Without this step, a purchased product may not be deployable within regulatory requirements.

Internal governance: making sure someone can own it after launch

Regulatory approval establishes eligibility but not sustainability. Whether an AI system continues in clinical use depends on internal governance: clear roles for model approval, performance monitoring, and error reporting.

Structure governance with the following elements: establish a cross-functional review group including clinical, IT, compliance, and security representatives; create documentation for each deployed model covering intended use, data sources, performance metrics, and known limitations; ensure clinicians retain override capability; conduct regular audits of usage logs and error reports; clarify the human-in-the-loop role explicitly, AI functions as a tool, final clinical responsibility remains with the physician.

At that hospital, work began not with code but with governance. Before any integration, the teams systematically addressed all four checklists: updating consent forms, verifying de-identification, confirming SaMD classification, and establishing review structures. Deployment success depended not on technical polish but on regulatory compliance paired with clinical adoption.