Rehabilitation Robot Registration Guide for South Korea

Key takeaway — A rehabilitation robot brings mechanics, electronics, software, and human interaction together in one product, making it a multi-disciplinary review category. Classification typically falls somewhere in the Class II to Class III range, and the biggest variable is whether clinical data is required. The review dossier has five pillars, but only one principle: the electrical, mechanical, and software documents must all describe the same product, and they must be built alongside development.

Why the review is "multi-disciplinary"

Gait rehabilitation, upper-limb training, strength assistance — whatever the application, reviewers look at five pillars. Each pillar exists for other device categories too; what makes this category hard is that all five apply at once and interlock. Reduced to a single sentence, the reviewer's question is: "When a machine that exchanges force with a person moves according to software's judgement, does the patient stay unharmed?" The mechanical, electrical, software, usability, and clinical files each have to answer that question in their own language.

MFDS (Ministry of Food and Drug Safety, formerly KFDA) recognises this and maintains a separate Guideline on Approval and Review of Rehabilitation Robots (civil petitioner's guide). It covers product classification and sub-categorisation, basic safety, and essential performance, and is worth reading in full once at the start of development.

Classification: your intended-use wording is half the answer

The representative product code — robot-assisted orthopaedic exercise devices (robotic systems used for muscle reconstruction and recovery of joint motion) — is normally reviewed at the higher class, though some configurations fall into the Class II range depending on structure and intended use. As a rough sense of timing, Class II certification takes about 3–4 months and Class III approval about 6–8 months; if a clinical trial is required, that entire period is added on top. For the overall procedure, see the Class II certification guide.

Classification starts by matching the product definitions in the Regulation on Medical Device Items and Their Classes against the intended-use wording of your own device. Identical hardware can land in a different product code depending on how the intended use is written, so that wording should be shaped from a regulatory perspective first, not a marketing one.

Watch the promotional claims in particular. Even if a product was developed as "training or exercise equipment," the moment marketing copy implies rehabilitative or therapeutic effect, both medical device status and classification become live issues. Narrow the wording, and market appeal drops. Balancing claims, class, and marketability is a decision to make during design, not after.

The five pillars of the review dossier

1. Mechanical and electrical safety — Because the device exchanges force with a person, the design rationale for drive-unit safety (entrapment, overload, emergency stop) carries weight. 2. Software — Safety classification of the control software plus development documentation. If an algorithm determines therapy intensity, expectations rise; if there is wireless communication or remote management, cybersecurity review applies as well. 3. Performance — Verification data for the rehabilitation functions you claim (assistive force, range of motion, training modes). 4. Usability — Since patients and therapists both operate the device, use-error analysis gets substantial attention. 5. Clinical evaluation / clinical trial — Can equivalence or literature suffice, or is a Korean clinical trial needed? This is the fork in timeline and budget.

Clinical data: the project's biggest variable

Of the five pillars, clinical evidence is the one that governs the schedule. There are generally three routes.

First, comparison with a substantially equivalent approved device. You demonstrate that intended use, principle of operation, and performance specifications are essentially the same as an already-approved device. Where available, this is the fastest route. That said, rehabilitation robots differ from one another in drive mechanism, training algorithm, and assistive-force profile, so the equivalence argument has to be tighter here than in other categories.

Second, literature-based clinical evaluation. Safety and effectiveness are supported by clinical literature on identical or similar technology; the review then turns on how you bridge the gap between the devices in the literature and your own.

Third, a domestic clinical trial. If the device is substantially novel or is assessed as higher risk, the process starts with approval of the clinical trial protocol, and the overall timeline lengthens considerably. Which route applies depends on the product, so settling the question through regulatory review early in design is the iron rule for this category.

Testing at a glance

Area	Representative standards	What the review looks for
Electrical and mechanical safety	IEC 60601-1 + particular standard for rehabilitation robots (IEC 80601-2-78)	Drive-unit safety, emergency stop, behaviour on loss of power, structural strength
EMC	IEC 60601-1-2	Malfunction in hospital and home electromagnetic environments
Software	IEC 62304	Safety classification; traceability from requirements to design to testing
Performance	MFDS guidelines and in-house specifications	Assistive force and torque, joint range of motion, speed, behaviour in each training mode
Biological safety	ISO 10993 series	Biological evaluation of skin-contact materials such as cuffs and harnesses

For rehabilitation robots, a particular standard (IEC 80601-2-78) sits on top of the general requirements of IEC 60601-1, so confirming whether your device falls within its scope is the first step in getting the test plan right. Because recognised standards do not cover every performance item in this category, treat performance testing as also being a review of the validity of your in-house test specification — why this item, these conditions, this acceptance criterion.

One more point: "which tests you ran" matters less than which version and which configuration you ran them on. If the software version used in testing differs from the version in the application, the debate reopens no matter how good the test report is.

Risk management (ISO 14971): start with entrapment, falls, and overload

ISO 14971 risk management covers not only intended use but also reasonably foreseeable misuse. For a rehabilitation robot, that includes incorrect parameter entry, unsuitable patient selection, and fitting errors. In practice, risk analysis for this category is best anchored in three mechanical hazards.

Entrapment — The analysis has to reach clearances between moving parts and the body, joint behaviour on stop, and the release procedure after an emergency stop. An analysis that stops at "there is an emergency stop button" typically draws a deficiency.

Falls — The top hazard in gait rehabilitation. Expect to be asked for the design rationale behind the body-weight support and harness structure, and for the state the device settles into on power loss or software fault (locked, released, or held). "It stops" is not enough; the analysis must extend to which stopped posture is safe for the patient.

Overload — Evidence that torque beyond the joint's range of motion cannot be applied. If you rely on a single software limit, a software fault translates directly into injury, so redundancy such as a mechanical stop or an independent monitoring circuit is a standing question in review.

The hierarchy of risk control (eliminate by design → protective measures → information for safety) is itself a review point. A risk management file that pushes residual risk onto warning statements reads as having skipped the hierarchy.

Usability (IEC 62366-1): there are two users

What makes usability difficult for rehabilitation robots is that there are two user groups. Therapists set parameters, fit the patient, and supervise training; patients perform the training while wearing the device and must communicate when something is wrong. A fitting error (therapist) and unreported pain (patient) are entirely different use errors, so the scenarios should be separated and each evaluated on its own risk basis.

Sequence matters too. Run formative evaluation on prototypes during development so interface problems feed back into the design, then close out with summative evaluation at the verification stage — that is the flow of IEC 62366-1. Cramming only the summative evaluation in just before launch means that when a problem surfaces, the design can no longer change and the deficiency response drags on. The fact that MFDS issued a separate guideline on applying usability within GMP specifically for robot-assisted orthopaedic exercise devices shows how heavily use error weighs in this category.

Technical documentation: three sets of files must describe one product

Electrical, mechanical, and software documents are produced separately, but the reviewer reads them as one file. Three consistency tips that cut deficiencies —

• A single source for specifications: manage model name, ratings, maximum assistive force, and range of motion in one table, and have every document cite that table. Differing figures across documents are a deficiency reason in themselves.
• Make the risk management file the hub: cross-reference which test report or design document verifies each control measure for each hazard, and reviewer questions drop.
• State the software version freeze point: it builds credibility to declare up front how the version used in safety and performance testing relates to the version in the application (identical, or with a change history).
• Standardise terminology: if the same part is called different things in different documents (drive unit / actuator / motor assembly), the reviewer has little choice but to suspect they are different configurations. Build a glossary and apply it across the whole dossier.

Structure and drafting order are covered separately in technical documentation in practice.

Preparation map by development stage

Stage	What regulatory needs to do	What happens if you defer it
Early design	Fix product code and class, list applicable standards, settle whether clinical data is likely required	The most expensive misjudgement of all
Prototype	Build risk management and software documents alongside design; formative usability evaluation	Retroactive writing = redesign in practice
Verification	Safety and performance testing, summative usability evaluation	No room to change the design; drawn-out deficiency response
Registration	Technical documentation → clinical (if needed) → KGMP run in parallel	Several extra months if run sequentially

Common rejection and deficiency reasons

• Software version used in testing does not match the version in the application, with no explanation of the changes
• Risk analysis stays generic — no product-specific scenarios for entrapment, falls, or overload
• Overload protection relies solely on a software limit, with no evidence of a mechanical or independent safeguard
• Usability evaluation does not separate patient and therapist scenarios; only summative evaluation submitted, with no formative work
• Specifications inconsistent across documents (assistive force in the performance data ≠ instructions for use ≠ test report)
• Claims exceed the verified performance range (training assistance verified → therapeutic effect claimed)

Checklist before you start

• Product code and class confirmed; promotional claims and intended-use wording finalised
• List of applicable standards fixed (IEC 60601-1 series, including whether the particular standard applies)
• Clinical evaluation route decided — feasibility of equivalence or literature assessed
• Risk management file opened — entrapment, fall, and overload scenarios mapped to design controls
• User groups (patient, therapist) defined and use scenarios separated
• Single specification table drafted — model name, ratings, and performance figures every document will cite
• Software version freeze plan aligned with the testing schedule

---

Rehabilitation robots are a category where 30 minutes of review at the design stage saves months later. With just a product overview and the claims you intend to make, our free pre-review will draft the likely class, the probability of a clinical data requirement, and the list of applicable standards.