Standalone Software as a Medical Device (SaMD): A Guide to MFDS Approval in South Korea

Key takeaway — The first question in a SaMD review is not about your code. It is "what is this software's intended use?" Whether it is a medical device at all, what class it lands in, and whether clinical evidence is required all follow from that answer. And the bottleneck almost always appears in the same place — when a team finishes development first and then tries to reconstruct IEC 62304 documentation after the fact.

No hardware, still a medical device

Standalone Software as a Medical Device (SaMD) is software that is not bundled with dedicated hardware and performs its medical purpose on its own, running on general-purpose computers, smartphones, and the like. Reading-assist programs that flag suspicious lesions on an image, apps that analyze biosignals and warn of possible arrhythmia, and digital therapeutics delivering cognitive therapy all fall in this category.

In South Korea, following the introduction of the Digital Medical Products Act, this kind of software is regulated under the designation "digital medical device software," and MFDS (Ministry of Food and Drug Safety, formerly KFDA) maintains separate approval and review guidance (civil petition guidelines) for it. The name has changed, but the skeleton of the review has not. What separates a medical device from a non-device is not the technology but the intended use you claim. An app that merely displays heart rate may be a wellness product; the moment it says it "alerts you to possible arrhythmia," it moves into medical device territory.

This boundary is contested often enough in practice that MFDS publishes a dedicated criteria document ("Criteria for Distinguishing Medical Devices from Personal Health Management (Wellness) Products"). A smartphone app that measures heart rate and does nothing more than record and display it may be treated as a wellness product for everyday health management; an app that uses the same measurement to tell the user there is "possible arrhythmia" or that they "should consult a physician" can be read as claiming disease monitoring or diagnostic support. In fact, before these criteria were consolidated, heart rate and oxygen saturation apps saw market entry delayed by months while their device status was disputed. Wording, not functionality, determines regulatory status — the first principle to internalize when planning a SaMD product.

Classification turns on the 'weight' of the information

A SaMD's class is assessed on the combination of how far the information the software produces intervenes in clinical decision-making and how serious the condition of the target patient is. The framework from the International Medical Device Regulators Forum (IMDRF) is reflected in Korean classification as well.

Role of the information	Examples	Typical direction of review
Display and management of information	Transmitting/viewing medical images, recording measurements	Lower class range
'Support' for diagnosis or treatment	Flagging suspicious lesions, suggesting reading priority	Class II–III range
Direct involvement in diagnostic or treatment decisions	Determining presence/severity of disease, predicting treatment response	Class III range

The same algorithm can be classified differently depending on whether it "provides reference information" or "diagnoses." Once the class is fixed, the overall procedure follows the same shape as any other medical device — typically about 3 to 4 months for Class II certification and about 6 to 8 months for Class III approval. The full structure is set out in our guide to notification, certification, and approval.

The full map of documents to prepare

SaMD technical documentation is a different animal from the "stack of test reports" that hardware devices generate. Rather than reports you obtain by sending a finished product to a laboratory, the bulk of the file consists of documents that evidence the development process itself.

Area	Applicable standard	Key deliverables
Software lifecycle	IEC 62304	Development plan, requirements specification, architectural design, verification & validation (V&V) reports
Risk management	ISO 14971	Risk analysis, risk control measures and residual risk evaluation
Usability	IEC 62366-1	Use-related risk analysis, formative and summative evaluation
Cybersecurity	MFDS guidance, with reference to IEC 81001-5-1	Security requirements, threat analysis, test evidence

Two forks in the road matter most here. First, IEC 62304 scales the depth of required documentation to the software safety class (A/B/C), and postponing that classification decision can force you to rebuild the entire document set. The differences between classes are concrete. Class A software, where malfunction cannot cause harm, may be covered at the level of a requirements specification and release documentation; from Class B onward, architectural design plus unit verification and integration test documentation are added; and Class C, where serious harm is possible, typically also requires detailed design down to algorithms and data structures, along with demonstrated traceability across every stage. Another frequently missed point is that the basis for your safety classification must interlock with the results of your risk management (ISO 14971) work. Second, cybersecurity evidence is effectively a baseline requirement for any software with network connectivity or data storage. What to prepare, and how far to go, is covered separately in our guide to software cybersecurity review. Together, these documents form the backbone of your technical documentation.

When performance or clinical evidence is required

Not every SaMD needs a clinical investigation. But if you want to make claims that intervene in clinical judgment — "diagnostic support," "prediction," "treatment" — you should expect to be asked for evidence supporting those claims: analytical performance such as sensitivity and specificity, and beyond that, clinical validity data. Whether existing literature and retrospective data will suffice, or whether a prospective study is needed, depends on how strong your claims are and on the nature of the product. Toning a claim down by one notch can substantially reduce the clinical burden, which is why designing your claims is, in effect, designing your development timeline.

What is different about AI-based SaMD

Once AI or machine learning is involved, two additional questions enter the review: "what was it trained on?" and "how are changes managed?" The core of the submission is the provenance and representativeness of training and validation data, and the separation of training data from performance evaluation data; for products whose performance can shift through retraining, a change control plan is reviewed alongside. Which changes trigger review is covered in our change approval guide. MFDS has issued approval and review guidance for AI-based medical devices and, more recently, for generative AI medical devices, so reference documents are relatively plentiful.

Procedure and timeline

The usual sequence runs: confirm product category and class → determine software safety class and design the document set → prepare technical documentation and secure performance evidence → file the approval (certification) application and respond to deficiency notices → KGMP (Korean Good Manufacturing Practice) assessment. Software is not exempt from KGMP; development and configuration management processes become the center of the quality system audit. Timelines typically run about 3 to 4 months for Class II certification and about 6 to 8 months for Class III approval, with additional time added separately where clinical data is required.

That said, the stages do not have to run strictly in series. Preparing technical documentation and generating performance evidence can largely proceed in parallel, and it is common practice to prepare for the KGMP audit during the deficiency response period after filing. In particular, when a software company approaches KGMP for the first time, connecting the records their development tools already produce — issue trackers, version control history — to formal quality records takes far more effort than expected. Organizing your record-keeping with the audit in mind from early in development visibly reduces the bottleneck later.

Common reasons for rejection or deficiency notices

• Mismatch between the claimed intended use and the performance evidence — claiming "diagnostic support" while submitting analytical performance data only
• Broken traceability across IEC 62304 documents — requirements, design, and test items not linked to one another
• No stated basis for the software safety classification, or an under-assigned class
• Missing cybersecurity evidence — network functionality present but no security threat analysis
• Failure to demonstrate separation of training data from performance evaluation data in AI products
• Signs that usability evaluation was performed only as a formality after development was complete

Checklist before you start

• Wording of the intended use you plan to claim, finalized — the starting point for device status and classification
• Product category and class confirmed; comparable approved products researched
• IEC 62304 safety class (A/B/C) determined and the scope of the document set designed
• Risk management (ISO 14971) and usability (IEC 62366-1) plans established
• Network and data functions inventoried → scope of cybersecurity evidence confirmed
• Level of performance and clinical evidence decided (literature, retrospective data, prospective study)
• For AI products, a training data specification and draft change control criteria prepared

---

SaMD is a category where a single phrase in your claims can change both the class and the clinical burden, even with an identical algorithm. Send us the product description and feature list you are already using, and our free pre-review will tell you whether it falls within the medical device definition and outline the document set you will need.