Classification & Attribute Determination

Since the Medical Device Act took effect on 2021-05-01, medical devices in Taiwan have been governed by a dedicated statute (separated from the Pharmaceutical Affairs Act), built on three layers: firm licensing/registration, product registration (查驗登記), and a quality management system (QMS/QSD). The first step for any software vendor is to determine whether the product is a regulated medical device software at all.

Medical Device Act (parent statute)

The parent statute for medical devices in Taiwan, effective 2021-05-01 (promulgated 2020-01-15). A standalone act spun off from the Pharmaceutical Affairs Act; Article 3 defines "medical device," covering both hardware and software. Article 83 means device management no longer applies the Pharmaceutical Affairs Act. For software vendors, step one is determining whether the product meets the device definition; if so, the firm must obtain a medical-device-business license (manufacturer or distributor) before registering or listing the product. Manufacturing or importing unapproved devices carries criminal and administrative penalties.

Regulation Governing the Classification of Medical Devices

Devices are grouped into 16 functional categories by function/intended use/mechanism (clinical chemistry, radiology, neurology, general hospital and personal-use devices, etc.) and into Class I (low), Class II (medium), and Class III (high) by risk. For software, the class hinges on claimed intended use and the harm severity of an erroneous output.

Tie-breaking rules ensure the higher risk class always prevails:

  • If a device fits multiple classes, the highest class applies.
  • Accessories follow the main device's class.
  • Combination products take the higher class.
  • Drug-device combinations where the device action predominates default to Class III.

Medical Software Classification and Grading Reference Guideline

TFDA's core reference for deciding whether "medical software" is a regulated SaMD/MDSW and its risk class. "Medical software" broadly means software that collects, stores, analyzes, displays, or transforms health, physiological, or medical-record data; the subset regulated as devices is "medical device software." Determination factors include meeting the device definition, being listed in the classification annex, claiming a diagnostic/therapeutic (or assistive) function, and the contribution to and harm severity of diagnosis/treatment.

The 2020-12-24 revision excluded heart-rate and SpO2 measurement for everyday wellness (including wearables) from device regulation, treating them as health-promotion products; a 2022-09-15 revision (FDA No. 1111609211) added more non-device examples. The single most important step for software vendors is to run this attribute determination first.

Registration & the Compliance Path

Class II & III Medical Device Registration (查驗登記)

Class II/III devices (including most SaMD) need registration to obtain a "medical device license" before marketing, per the Review Regulations for Medical Device Registration. Required materials include application/review forms, a QMS manufacturing license or QSD, technical documentation (incl. conformity to IEC 62304/14971/62366), labeling and IFU, predicate comparison (1-2 closest predicates or a comparison table), and a clinical trial report where required. From 2025-07-01, many public applications moved fully to the e-submission system. Class I generally uses lighter "listing," while Class II/III use full registration.

AI/ML Medical Device Software Registration Technical Guidance

Guidance for preparing the technical dossier when registering AI/ML SaMD, announced 2020-09-11 (FDA No. 1091607253). Required technical content includes software overview and intended use, algorithm architecture, AI/ML data limitations (training/validation dataset scope and representativeness), output and use-environment/personnel constraints, and safety and performance evaluation (clinical/analytical performance). It is Taiwan's first AI-specific device guidance, making explicit that AI submissions must disclose data provenance, bias control, and validation methodology.

AI/ML CADe & CADx Device Registration Technical Guidance

Pathway-specific guidance for imaging AI (detection CADe / diagnosis CADx); latest revision FDA No. 1141617758 (2025-08-12), with an accompanying Q&A. It evolved from the 2021-07-07 "CADe review-key-points guidance" (FDA No. 1101607081). The guidance distinguishes CADe (lesion detection support) from CADx (classification/diagnosis support) and sets concrete expectations for annotation, dataset partitioning, independent test sets, clinical performance, and reader studies. It is the mainstream submission basis for medical-imaging AI (e.g., lung nodules, diabetic retinopathy, fracture detection); the 2025 revision reflects TFDA's latest expectations on performance validation and real-world data.

Compliance Path for Software Vendors (6 steps)

  • Attribute & class determination: use the Medical Software Classification guideline plus the Classification Regulation to decide if it is a regulated SaMD and its class; request a TFDA attribute query if unsure.
  • Build the QMS: implement an ISO 13485-based QMS embedding IEC 62304 (lifecycle), ISO 14971 (risk), IEC 62366 (usability), and a secure-development process; manufacturers obtain a manufacturing license, importers prepare QSD.
  • Obtain firm licensing: complete manufacturer/distributor licensing and registration.
  • Assemble technical & clinical evidence: software documentation, risk file, cybersecurity data, clinical evaluation report or trial (with IRB if needed); for AI devices, follow the AI/ML and CADe/CADx guidance on datasets and performance validation.
  • Register/list: Class I listing; Class II/III full registration to obtain the license (e-submission).
  • Post-market & reimbursement: set up UDI, adverse-event reporting, post-market performance monitoring (AI model drift), cybersecurity maintenance, and privacy compliance; plan NHI temporary payment/sandbox and RWE evidence to pursue reimbursement.

Quality Management & Software Standards

Quality Management System Regulation (ISO 13485-based)

Taiwan's QMS Regulation is modeled on ISO 13485:2016, covering facilities, equipment, organization/personnel, production, quality control, storage/distribution, and complaint handling. Domestic manufacturers must build a QMS, pass TFDA inspection, and obtain a 3-year manufacturing license (renewal filed 6-12 months before expiry) before producing. Even SaMD vendors with no physical line must implement a conformant QMS for software development, change, configuration, and nonconformity management.

QSD - Quality System Documentation Review (for importers)

QSD (Quality System Documentation) review is one route for importers to prove a foreign manufacturer's conformity to Taiwan GMP, allowing a documentary review (leveraging MDSAP, ISO 13485 certificates, etc.) in lieu of an on-site audit. For Taiwanese firms importing foreign SaMD, QSD is prerequisite quality evidence for market entry.

IEC 62304 - Medical Device Software Life Cycle Processes

IEC 62304 covers software development planning, requirements analysis, architectural/detailed design, implementation and verification, integration and system testing, release, maintenance, and problem resolution, plus configuration management and software risk management. Process depth scales with software safety class: A (no injury), B (non-serious injury), and C (death/serious injury), linked to ISO 14971. It is the backbone of the registration technical file, recognized by both TFDA and FDA/MDR; SOUP (third-party/legacy components) require an inventory and risk assessment.

ISO 14971 - Medical Device Risk Management

ISO 14971 sets the foundational whole-lifecycle risk-management process: risk analysis, evaluation, control, residual-risk evaluation, overall benefit-risk judgment, and post-production information feedback. IEC 62304 normatively references ISO 14971. For SaMD, vendors must identify hazard scenarios arising from software faults, erroneous output, cybersecurity, and use errors, feeding into the software safety class and post-market surveillance.

IEC 62366-1 - Usability Engineering (Human Factors)

IEC 62366-1 requires identifying use-related risks, defining use scenarios and hazardous situations, and conducting formative and summative usability evaluations so the user interface reduces use errors. It matters greatly for SaMD (especially clinical decision support, mobile apps, and AI result presentation): UI misreads can directly cause clinical errors, so usability validation is commonly required in the registration and risk file.

Clinical Evaluation & Trials

Safety and efficacy can be shown via a clinical evaluation report (literature, predicate comparison, or existing clinical data) or via a clinical trial. Trials are applied to TFDA per the clinical-trial application guidance and must clear an IRB/REC. Except where the central competent authority mandates local trials, Class II no-predicate devices may be exempt from a trial report if they fully meet specified criteria.

For AI SaMD, validation typically uses retrospective datasets plus prospective clinical validation where needed. Dataset representativeness and an external test set are review focal points.

A registration license is not NHI coverage - the evidence you build for clinical evaluation also seeds the health-economics and real-world evidence needed later for reimbursement.

Reimbursement: NHI, Temporary Payment & DTx

NHI AI Device Reimbursement & Temporary Payment

The NHIA is assessing digital health and AI-assisted diagnosis tools under "temporary payment," weighing cost-effectiveness and budget impact as a precedent for formal coverage; it also plans a "regulatory sandbox" to evaluate smart-device clinical benefit and reimbursement. The MOHW's smart-device incubation and value-chain program is slated to run 2026-2029, helping collect real-world data to speed adoption. Even after registration, reimbursement is a separate gate, so vendors should plan health-economics/RWE evidence early. (Specific covered items and fee schedules: TBD.)

Digital Therapeutics (DTx) Reimbursement Status

In 2024 the NHIA piloted a "digital care incentive" sandbox (Health2Sync, WaCare, Jubo, FET), using a base fee plus performance bonuses tied to health improvement. Taiwan lacks a full prescription-DTx reimbursement scheme like Germany's DiGA; most DTx are currently self-pay or pilot-based. Germany's DiGA "provisional listing then performance-linked" model is a useful reference, and the sandbox is a way to accumulate clinical/real-world evidence. (Formal DTx coverage list and fees: TBD.)

Cybersecurity & Personal Data Protection

Medical Device Cybersecurity Guidance (for Manufacturers)

The "Medical Device Cybersecurity Guidance for Manufacturers" was announced 2021-05-03 (110/05/03), traceable to a first version dated 2018-12-20, and revised through a 7th version dated 2023 - a living document. It covers design-phase security requirements, interface/communication-path/component inventories (the SBOM concept), references AAMI TIR57 and ISO 14971, and aligns with international IEC 81001-5-1 (secure software development lifecycle). Pre-market submissions must include cybersecurity design and risk-management documents; post-market requires ongoing vulnerability monitoring, patching, and updates. For SaMD and connected devices, cybersecurity is now a mandatory registration section.

UDI - Unique Device Identification (TUDID)

Per the "UDI Labeling Rule" (effective 2021-05-01 / 110/05/01), Class II/III devices must carry a UDI on the device body or unit package and upload it to the TUDID national platform, phased in from higher-risk products first. UDI accelerates adverse-event reporting, recalls, and supply-chain traceability. For SaMD, pure software also needs a UDI (including version identifiers), and software version changes may trigger UDI and registration updates.

Adverse Event Reporting & Post-Market Surveillance

The Medical Device Act requires firms to report serious adverse events within set deadlines (the specific day-count is TBD) and to cooperate on recalls and CAPA. For SaMD, vendors must run software-defect tracking, post-market performance monitoring (especially AI model drift/performance decay), user-feedback handling, and cybersecurity incident response, integrated with ISO 13485 post-market surveillance and ISO 14971 post-production information.

Personal Data Protection Act (PDPA) & the PDPC

PDPA Article 6 lists medical records, health, genetic, and health-exam data as sensitive personal data, generally barred from processing except with consent, an explicit legal basis, or de-identified academic research. De-identified data that still permits indirect re-identification remains personal data. The Legislative Yuan passed amendments on 2025-10-17, promulgated by the President on 2025-11-11 (effective date set by the Executive Yuan - TBD): establishing an independent supervisory authority (the PDPC), mandating breach reporting, strengthening administrative inspection and penalties, and requiring a Data Protection Officer. For SaMD, processing clinical data needs a lawful basis, robust de-identification and a security-maintenance plan, and a prepared incident-reporting workflow.

Healthcare Institution & Device Cybersecurity (sectoral)

Major healthcare institutions are typically designated critical infrastructure or specified non-government agencies under the Cyber Security Management Act and must maintain a security plan, tiered protection, and incident reporting. The MOHW also issues healthcare-sector cybersecurity guidance and hospital protection baselines (exact titles and versions TBD). For SaMD vendors, products must clear hospital security review (encryption, access control, audit trails, and secure HIS/PACS integration) and meet hospitals' supply-chain security requirements.

International Comparison: FDA, CE/MDR & PCCP

US FDA SaMD Pathways - 510(k) / De Novo / PMA

The US risk-classifies into three classes; most SaMD use 510(k) or De Novo, and a few high-risk products use PMA. 510(k) demonstrates substantial equivalence to a marketed predicate - the most common route. De Novo covers a novel low-to-moderate-risk device lacking a suitable predicate, creating a new classification. PMA is for high-risk Class III and requires full clinical evidence. By end-2024 the FDA had cleared roughly 95,000 devices via 510(k)/De Novo and about 1,678 via PMA; AI/ML tools are mostly SaMD. FDA's predicate-comparison logic resembles Taiwan's predicate concept in registration, though evidence thresholds and review culture differ.

US FDA Predetermined Change Control Plan (PCCP)

A PCCP lets AI/ML devices pre-authorize future model changes at submission, avoiding new filings for each change. It has three elements: Description of Modifications, Modification Protocol, and Impact Assessment. In Aug 2024 the FDA extended it to all 510(k)/De Novo/PMA devices, and in Dec 2024 finalized the marketing-submission guidance for PCCPs in AI device software functions, aligned with the Good Machine Learning Practice (GMLP) framework. Change management for AI devices in Taiwan still relies on change registration; PCCP is an international reference, and whether TFDA will adopt a similar mechanism is worth watching (TBD).

EU CE / MDR & MDSW Rule 11

Under EU MDR (Regulation (EU) 2017/745), software is classified by Annex VIII Rule 11: software providing information for diagnostic/therapeutic decisions is generally Class IIa; if an erroneous decision could cause death or irreversible deterioration it is Class III; software monitoring vital physiological parameters can reach Class IIb. MDCG 2019-11 provides MDSW qualification and classification decision trees. Most medical-purpose software under MDR requires a Notified Body for conformity assessment, clinical evaluation, and PMS/PMCF. MDR classification is often stricter than Taiwan's (Rule 11 frequently pushes software up to IIa/IIb), so EU entry needs extra Notified Body and clinical-evaluation resourcing.