Healthcare AI data review: privacy, DICOM and intended use

Before giving healthcare data to an AI service, document the task, data, recipients and intended use of the output. An administrative summary, a research dataset and diagnostic support need different use descriptions.

These four checklists help IT, clinical, compliance and security teams prepare an assessment. Responsible specialists determine the applicable processing basis and device requirements for the actual use.

1. Data: identify the basis for the specific purpose

Taiwan's Personal Data Protection Act, Article 6 sets conditions for processing medical and health data. Written consent is one listed condition; a medical-purpose label or removed name does not establish a universal basis.

Questions to document:

• Purpose and output: administrative preparation, research or medical support? Will data also be used for training or supplier service improvement?
• Necessary fields: which fields are needed, including any patient, family or staff information?
• Processing authority: who confirms the basis for this use and recipient? Do existing notices, consent, institutional rules and applicable requirements cover it?
• Recipients and retention: which services, locations, logs and backups receive data? Who has access, for how long, and how is use stopped or data deleted?

For an illustrative summary from approved institutional documents, limit the data and users first. Do not add identifiers simply because a model might find them useful. Reassess the data flow and authority when a supplier, location or purpose changes.

2. De-identification: assess the whole object

Identifying information can appear in fields, free text, filenames, attachments, images and linked records. Removing a name still leaves questions about identification using other available information. If a mapping or recovery mechanism remains, document access restrictions without claiming absolute anonymity.

DICOM PS3.15 2026d Attribute Confidentiality Profiles explain that attribute handling does not guarantee whole-object de-identification. Pixels, annotations, private attributes and sharing context require assessment; unencrypted hashes can also be vulnerable to dictionary attacks.

Questions for images and documents:

• Have metadata, identifying image text, thumbnails, overlays and related attachments been checked?
• Which dates, locations, rare conditions or identifiers remain, and why? What identification risk do they create?
• Which processing settings and versions were used? Were outputs sampled and exceptions recorded?
• Who can access processed data, mappings and originals? Are these permissions separated?

Arrange testing and specialist support according to the data's risk. Supplier assurances, a tool or a single report do not provide permanent processing permission.

3. Devices: assess claims and intended use

TFDA's medical-device introduction describes assessment by function, intended use, operation and risk, with an attributes inquiry when uncertain. Hospital use or human review alone does not determine device status or classification.

This is a scoping table, not TFDA's classification scheme. TFDA's August 14, 2025 update to AI/ML detection and diagnosis device guidance also does not establish one approval process for all AI software.

For a device product, confirm the authorized product, version and intended use, together with applicable change and monitoring requirements. Research ethics and institutional approvals are separate assessments.

4. Ownership: arrange review and suspension

Document:

• Approval: who accepts the data scope, use and assessment evidence?
• Review: who verifies output, handles omissions and decides whether to use it?
• Maintenance: who checks changes to data, documents, models or settings and arranges reassessment?
• Incidents: how are errors reported, necessary evidence retained and access restricted or the service suspended?
• Takeover: how does the task return to the original process when the system cannot help?

A summary citing obsolete information needs an assigned reviewer and response, not an unattended warning. Logs can contain sensitive information too, so design collection, access and retention together.

Prepare the intended use, data flow, unresolved requirements and owners before deciding the next test or purchase. Content quality, data handling and applicable authorization are separate checks; active use cannot substitute for them.