Medical Device & IEC 62304 — Technical Assessment

Is the RestartiX platform a medical device? What does that mean? And what do we need to do about it?

This page documents the regulatory landscape around Software as a Medical Device (SaMD) and how it applies to the platform. It is written for the team, future investors, and regulatory consultants who will eventually guide the formal certification process.

Updated March 2026 after formal regulatory consultation with a medical device certification specialist.

---

The Short Answer

We don't decide if we're a medical device. The regulatory authority does, based on our intended purpose.

The platform's clinical features — exercise prescription, treatment plan management, telerehabilitation with video guidance, patient progress tracking — are used for treatment and monitoring of patients. Under both EU MDR and FDA definitions, software with a medical intended purpose qualifies as a Software as a Medical Device (SaMD).

The features make us a medical device. The certification proves we built it properly.

---

Who Decides

Jurisdiction	Authority	Regulation
European Union	National competent authorities (e.g., ANMDMR in Romania, BfArM in Germany)	EU MDR 2017/745
United States	FDA	21 CFR Part 820, FDA SaMD guidance
International	IMDRF (guidance body, not enforcement)	IMDRF SaMD framework

The classification is triggered by how we describe and market the product. If the website says "telerehabilitation platform" or "exercise prescription for recovery" — those are medical claims. The software is a medical device.

---

Classification Analysis (March 2026)

MDR Rule 11 — the primary rule for medical device software

Rule 11 from Annex VIII of MDR 2017/745:

Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as Class IIa, except where such decisions have an impact that may cause: — death or an irreversible deterioration of a person's state of health, in which case it is classified as Class III; or — a serious deterioration of a person's state of health or a surgical intervention, in which case it is classified as Class IIb.

Software intended to monitor physiological processes is classified as Class IIa, except where it is intended for monitoring of vital physiological parameters, where variations of those parameters are of such a nature that could result in immediate danger to the patient, in which case it is classified as Class IIb.

All other software is classified as Class I.

MDCG 2019-11 Rev.1 clarification

The EU guidance document MDCG 2019-11 Rev.1 (Guidance on Qualification and Classification of Software) further clarifies:

Since software is defined as an active device, for the classification of active devices (hardware), which includes MDSW (medical device software) that provides information for patient management, Rules 9, 10, 11, 12, 13, 15, and 22 of Annex VIII to MDR 2017/745 should be considered. Therefore, in accordance with implementing rule 3.5, the most stringent rule or sub-rule should apply.

The wording "intended to provide information used to take decisions for diagnostic or therapeutic purposes" describes, in very general terms, the characteristic "mode of action" of all MDSW. Therefore, this sub-rule is generally applicable to all MDSW (except those MDSW which do not have a medical purpose).

This means Rule 11 applies to essentially all medical device software, making Class IIa the default classification.

Consultant's analysis of RestartiX

The regulatory consultant identified the following functions as each independently triggering Class IIa:

Platform Function	Why It Triggers Rule 11
Treatment plan management	Software is part of the therapeutic process — supports therapeutic decisions
Exercise library (with contraindications)	Not general educational content — medical content used in treatment
Progress tracking	Monitoring therapy implementation. Even "light" behavioral monitoring is therapy monitoring under MDR
Adherence tracking	Adherence is a medical element. Tracking it = monitoring treatment
Computer vision for exercise verification	A form of therapeutic behavior analysis = monitoring
Guided rehabilitation sessions	Patient follows a medically prescribed program through the software

Conclusion: The platform is Class IIa under Rule 11. This applies regardless of whether measurement tools (goniometer, posture analysis) are included — the core treatment and monitoring features alone are sufficient.

The consultant was explicit: "There is no realistic interpretation of MDR that allows Class I for software that manages a therapeutic plan, monitors its execution, tracks adherence, processes medical data, and is used in medical rehabilitation."

What would need to be removed for Class I

To genuinely qualify as Class I, the platform would need to strip all medical functions:

• No monitoring
• No computer vision
• No adherence tracking
• No medical data processing
• No therapeutic plan support
• Only teleconsultation + archiving

This would destroy the platform's core purpose.

---

The Class I Alternative: Rule 13

How it works

Rule 13 states: "All other active devices are Class I."

If the intended purpose is carefully worded to avoid declaring that the platform provides information for diagnostic/therapeutic decisions or monitors patients, Rule 13 can apply instead of Rule 11.

Competitor precedent

Six European telerehabilitation platforms have registered as Class I:

Herodikos (Germany) — Class I, registered in EUDAMED without detailed intended purpose or classification rule. User manual states: "The Herodikos app is not expressly intended for diagnosis or monitoring of disease or injury. This remains the sole responsibility of the physician or therapist." However, other sections of the manual and website contradict this by mentioning "monitoring patients", "adherence tracking", and "individualized therapy plans based on functional assessment."

eCovery (Germany) — Class I (MDR). Positioned as a back pain and recovery exercise app.

Bauerfeind Therapy App (Germany) — Class I (MDR). Orthopedic rehabilitation exercises associated with orthoses/bandages.

SilverFit (Netherlands — Newton, Mile, Flow, Rephagia) — Class I via Rule 13. Public Declaration of Conformity available. Intended purposes carefully worded as "motivational visualizations (games) for exercises" — avoiding therapeutic language entirely. The manufacturer did not declare that information managed by the software is used for diagnostic or therapeutic decisions.

HoloMoves (Netherlands) — CE certified as Class I. Rehabilitation including neurorehabilitation and exergaming.

Risks of the Rule 13 approach

The regulatory consultant was direct about this:

"You can follow the Herodikos model, but I want you to be aware that it's not exactly proper. It's an unorthodox way to avoid classification in a higher risk class."

Specific risks:

1. EUDAMED registration doesn't verify accuracy — no one checks whether the declared intended purpose matches the actual product
2. Market surveillance — ANMDMR or other authorities can audit at any time and challenge the classification
3. Competitor complaints — producers who properly certify their products can report non-compliant competitors to the competent authority
4. Marketing contradiction — the website and sales materials must not claim therapeutic monitoring, clinical decision support, or treatment management
5. Growing market — as of March 2026, no similar software is registered as Class IIa in EUDAMED, but this will change as the market matures

Current market state

As of March 2026: 1,515 Class IIa software products exist in EUDAMED, but none with an intended purpose matching telerehabilitation platforms. All comparable competitors operate under Class I. This creates a window where the pragmatic approach carries lower risk — but the window will close as the market matures and competitors begin proper certification.

---

IEC 62304: Software Safety Classification

IEC 62304 (Medical Device Software — Software Life Cycle Processes) is the international standard that defines requirements for developing and maintaining medical device software. It doesn't prescribe technology choices — it prescribes process and documentation.

Software Safety Classes

Class	Risk Level	What It Means	Likely for RestartiX?
Class A	No injury possible	Software failure cannot cause injury	No — clinical features have risk
Class B	Non-serious injury possible	Software failure could cause non-serious injury	Most likely classification
Class C	Death or serious injury possible	Software failure could cause death or serious injury	Unlikely for a rehab platform

IEC 62304 safety classification: Class B. A software bug could theoretically show the wrong exercise to a patient (e.g., one with a contraindication), which could cause non-serious injury. Death or serious injury from a telerehab platform is unlikely but not impossible in edge cases.

What IEC 62304 Requires (by class)

Requirement	Class A	Class B	Class C
Software Development Plan	Required	Required	Required
Requirements analysis	Required	Required	Required
Architectural design	Required	Required	Required
Detailed design	-	Required	Required
Unit testing	-	Required	Required
Integration testing	-	Required	Required
System testing	Required	Required	Required
Risk management (ISO 14971)	Required	Required	Required
SOUP management	Required	Required	Required
Configuration management	Required	Required	Required
Change control	Required	Required	Required

---

Which Features Are Regulated

Not every feature in the platform is a medical device function. IEC 62304 only applies within the regulatory boundary — the modules that serve a clinical purpose.

Inside the Regulatory Boundary (clinical)

Feature	Clinical Purpose	Risk Example
Exercise Library	Exercise content with contraindications	Wrong exercise shown (ignoring contraindication)
Treatment Plans	Prescribed rehabilitation programs	Wrong exercise sequence, incorrect parameters
Patient Sessions (telerehab)	Guided exercise execution with video	Patient performs exercise incorrectly due to wrong video
Progress Tracking	Monitoring patient recovery	Misleading progress data leads to wrong clinical decision
Adherence Tracking	Monitoring treatment compliance	Incomplete adherence data leads to incorrect treatment adjustment
Video Consultations	Clinical decision-making via video	Technical failure during critical clinical assessment
Computer Vision	Exercise execution verification	Incorrect form assessment leads to patient injury
Virtual Goniometer	ROM measurement in degrees via camera	Inaccurate measurement leads to wrong treatment decision
Posture Analysis	Clinical posture assessment via camera	Missed postural deviation leads to inadequate treatment
Movement Quality Assessment	Exercise form evaluation via pose detection	Incorrect form assessment leads to patient injury

Outside the Regulatory Boundary (administrative)

These features are not medical device functions and do not require IEC 62304 compliance:

• Appointment scheduling and booking
• Service plans and products
• Organization management and multi-tenancy
• User authentication and RBAC
• Forms (administrative — consent forms, intake forms) and custom fields
• PDF templates and document generation
• Webhooks and integrations
• Segments and patient cohorts
• Automations (workflow triggers)
• Audit logging (supports compliance but is not itself clinical)

Why This Separation Matters

Keeping regulated modules architecturally isolated makes compliance far easier. In the Go backend, clinical features live in dedicated domain packages under internal/core/domain/ (e.g., exercise/, treatment_plan/). This means the regulatory boundary maps cleanly to code boundaries.

---

Registration Process (Romania / EU)

Step 1: EUDAMED Registration

Register in the European Database on Medical Devices to obtain the manufacturer's Single Registration Number (SRN).

Required by OMS 3539/2022 (Romanian Order of the Minister of Health) for manufacturers based in Romania introducing medical devices to the market.

Resources:

• EUDAMED Actor Registration
• EUDAMED User Guide — Actor Module

Step 2: UDI Codes from GS1

After obtaining the SRN, obtain Basic UDI-DI and UDI-DI codes for each product. Four entities are designated by the European Commission to issue UDI codes:

1. GS1 AISBL (recommended)
2. Health Industry Business Communications Council (HIBCC)
3. International Council for Commonality in Blood Banking Automation (ICCBBA)
4. Informationsstelle für Arzneispezialitäten – IFA GmbH

More info: EU FAQ on UDI

Step 3: ANMDMR National Registration

Register in the Romanian national database. Required documents:

• Declaration of Conformity
• Certificate of Registration from the Trade Registry (Registrul Comerțului)
• Certificat Constatator
• Product label (model)
• Instructions for Use (IFU)

Registration Costs

Regulatory fees:

Item	Cost
ANMDMR — EUDAMED validation	276 RON (~55 EUR)
ANMDMR — national database registration	1,638 RON (~330 EUR)
GS1 — membership fee (one-time)	120 EUR
GS1 — annual license fee	120 EUR/year

Total regulatory fees: ~625 EUR + 120 EUR/year

---

Product Dossier & QMS

Product Dossier (MDR Technical Documentation)

Includes: risk analysis, essential requirements analysis, post-market surveillance planning.

Not mandatory at the time of ANMDMR registration, but:

• Can be requested by the ANMDMR evaluator if deemed necessary
• Can be the subject of a subsequent market surveillance inspection
• Can be prepared after registration, or when specifically requested

Recommendation: Prepare proactively. Having it ready demonstrates maturity and avoids scrambling during an inspection.

Quality Management System (QMS)

MDR 2017/745 Article 10(9) requires manufacturers to have a QMS. Two options:

Option 1 — Own QMS (non-certified)

• Develop internal quality management documentation
• Sufficient for legal compliance with MDR
• Adequate for Class I registration

Option 2 — ISO 13485 Certified QMS

• Certified by an accredited certification body
• May be required by:
  • CNAS (Romanian National Health Insurance House) for contracting
  • Large clinic networks and institutional clients
  • Large clinic chains with quality requirements
• Recommendation from consultant: If pursuing ISO 13485, contact the certification body directly and request help with QMS documentation development — more efficient than developing it independently

---

Who Cares About Certification (and When)

Nobody asks for certification until someone does. Then everyone asks at once.

Scenario 1: Selling to Large Clinic Networks

Large clinic networks and institutional clients require CE marking (EU) or FDA clearance (US) before purchasing software. No certification = no deal. This is the most common reason startups pursue certification — it's a sales blocker.

Scenario 2: Legal Market Access in the EU

Under EU MDR, if the software qualifies as a medical device, CE marking is required to legally place it on the EU market. Operating without it is technically illegal. Enforcement is inconsistent for small companies, but the liability is real.

Scenario 3: A Patient Gets Injured

If a patient is harmed due to a software defect (e.g., wrong exercise prescribed, contraindication ignored), the regulatory authority investigates. They ask:

• "Show us your risk analysis."
• "Show us your testing evidence."
• "Show us your change control process."

With documentation: It's a product defect — handled through the corrective action process. Without documentation: It's gross negligence — you knew you were building a clinical tool and had no safety process. Massive difference in legal liability.

Scenario 4: Someone Reports You

Anyone — a competitor, a disgruntled client, an employee — can report to the competent authority that an unregistered medical device is on the market. The authority then asks you to prove compliance or cease operations.

What Auditors Check

During certification, a Notified Body (EU) or FDA reviewer checks documentation, not code. They don't read Go files. They verify:

Document	What They Check
Software Development Plan	"Do you have a defined lifecycle? Tools? Standards?"
Requirements + Traceability	"Can you trace every requirement to a test that verifies it?"
Risk Analysis (ISO 14971)	"Did you identify hazards? Are there controls? Are controls verified?"
Change Control	"How do you ensure changes don't break safety?"
SOUP List	"What third-party code runs in your device? What are the risks?"
Test Reports	"Proof that tests passed for the released version"

---

Current State: Gap Assessment

An honest assessment of where the platform stands today relative to IEC 62304 requirements.

What We Already Have

IEC 62304 Requirement	What Exists Today	Status
Software Development Plan	Implementation Plan — phased build plan with milestones and status tracking	Exists, needs reframing as SDP
Architecture Documentation	Architecture section — decisions with rationale, project layout, AWS infrastructure, scaling plan	Strong
Requirements Documentation	Features section — 18 feature specs with workflows, schemas, APIs	Strong content, no requirement IDs
Compliance Documentation	Security & Compliance + Compliance Checklist + Audit Compliance — HIPAA/GDPR mapping, retention, breach procedures	Strong for HIPAA/GDPR, not ISO 14971
Configuration Management	Git with structured commits, documented conventions in CLAUDE.md	Good, needs formal change control doc
Risk Management	Not yet formalized	Gap
SOUP Management	Dependencies tracked in go.mod and pnpm-lock.yaml	No risk assessment per dependency
Traceability	Not yet implemented	Gap
Testing	Planned (see gaps/01-testing-strategy)	Gap

What's Genuinely Strong

1. Documentation culture. 18 feature specs, architecture decisions with rationale, compliance docs, a phased implementation plan. This is 70% of the IEC 62304 content — it exists, it just needs restructuring.

2. Technical foundations. Row-Level Security, AES-256-GCM encryption at rest, append-only audit log, RBAC — these are things that are painful to add retroactively. Having them from day one is a significant advantage.

3. Architecture decisions are documented with rationale. The Key Decisions page explains why each technology was chosen. This is exactly what auditors want to see — evidence of deliberate, informed choices.

4. Clean domain separation. The repository pattern with dedicated domain packages means the regulatory boundary can map to code boundaries without refactoring.

5. Audit trail. Tamper-evident, append-only, 6-year retention, HIPAA-mapped. This is the hardest thing to add later and it's already designed.

What's Missing

For Class I registration (minimum):

Gap	What's Needed	Effort
Declaration of Conformity	Formal document declaring MDR compliance	Low — template-based
Instructions for Use (IFU)	User-facing documentation of intended purpose, warnings, contraindications	Medium
Product Label	CE mark, manufacturer info, UDI, intended purpose	Low
EUDAMED + GS1 Registration	Administrative process	Low (with consultant)

For full IEC 62304 compliance (Class IIa path):

Gap	What's Needed	Effort
Requirement IDs and Traceability	Assign IDs (e.g., REQ-TP-003) linking requirements → design → tests	Low — labeling exercise on existing content
Software Development Plan (SDP)	Reframe implementation plan as IEC 62304 SDP with lifecycle model, tools, deliverables, verification strategy	Medium
Risk Analysis	Hazard identification for each clinical feature: what can go wrong, likelihood, severity, controls	Medium — new document, bounded to clinical features
SOUP List	Catalog every third-party dependency with: name, version, purpose, known anomalies, risk assessment	Low-Medium — partially automatable with SBOM tooling
Formal Testing	Integration and system testing with traceability to requirements	High — real engineering work
Clinical Validation	Test measurement tools against physical instruments on real patients	High — requires controlled testing conditions
ISO 13485 QMS	Full quality management system documentation	High (if certified)
ISO 14971 Risk Management File	Complete risk management documentation	Medium-High

---

Recommended Path

Phase 1 — Class I Registration (target: before first paying client)

1. Engage regulatory consultant for EUDAMED registration
2. Carefully define intended purpose (Rule 13-compatible wording)
3. Obtain SRN, UDI codes from GS1
4. Prepare Declaration of Conformity, IFU, label
5. Register with ANMDMR
6. Prepare product dossier (risk analysis, essential requirements, post-market surveillance)
7. Establish own QMS (non-certified)

Phase 2 — Build toward Class IIa (ongoing during development)

1. Add requirement IDs to feature specs as features are built
2. Note safety implications in feature docs (seeds for formal risk analysis)
3. When writing tests, reference requirements (e.g., // Verifies REQ-TP-003)
4. Don't delete git history — it proves controlled development
5. Keep the audit log immutable
6. Maintain SOUP awareness as dependencies change

Phase 3 — Class IIa Certification (when business requires it)

1. Hire regulatory consultant for formal gap analysis
2. Formalize SDP, complete traceability matrix
3. Build test suite with evidence and traceability
4. Conduct clinical validation for measurement tools
5. Prepare Technical Documentation (EU MDR) for Notified Body
6. Pursue ISO 13485 certification if required by target clients
7. Notified Body audit

---

Glossary

Term	Definition
SaMD	Software as a Medical Device — software that is itself a medical device (not embedded in hardware)
IEC 62304	International standard for medical device software lifecycle processes
ISO 14971	International standard for risk management of medical devices
ISO 13485	Quality management system standard for medical device manufacturers
EU MDR	European Union Medical Device Regulation (2017/745)
CE Marking	Certification mark indicating conformity with EU health, safety, and environmental standards
ANMDMR	Agenția Națională a Medicamentului și a Dispozitivelor Medicale din România — Romanian national authority for medicines and medical devices
EUDAMED	European Database on Medical Devices — central EU registration and information system
Notified Body	Organization designated by an EU country to assess conformity of medical devices
SOUP	Software of Unknown Provenance — any third-party software component (libraries, frameworks, OS)
SDP	Software Development Plan — documented plan for the software development lifecycle
DHF	Design History File — complete record of a medical device's design process
UDI	Unique Device Identification — standardized system for identifying medical devices
UDI-DI	UDI Device Identifier — unique numeric/alphanumeric code for a specific medical device model
Basic UDI-DI	Primary identifier for a device model in EUDAMED — the main key for the device in the database
SRN	Single Registration Number — unique identifier for economic operators (manufacturers, importers, etc.) in EUDAMED
GS1	International organization designated by the EU to issue UDI codes
OMS 3539/2022	Romanian Order of the Minister of Health governing medical device market placement and EUDAMED registration
CNAS	Casa Națională de Asigurări de Sănătate — Romanian National Health Insurance House
Rule 11	MDR Annex VIII classification rule for software providing information for diagnostic/therapeutic decisions → Class IIa+
Rule 13	MDR Annex VIII classification rule for "all other active devices" → Class I
MDCG 2019-11	EU guidance document on qualification and classification of software under MDR/IVDR
Traceability Matrix	Document linking requirements to design, implementation, and tests
Regulatory Boundary	The line separating regulated (clinical) features from non-regulated (administrative) features
SBOM	Software Bill of Materials — inventory of all software components and dependencies

---

Related Documentation

• Medical Device Classification (overview) — Stakeholder-facing classification summary
• Security & Compliance — HIPAA, GDPR, and data protection requirements
• Audit Compliance — Audit trail implementation for HIPAA/GDPR
• Key Decisions — Technology choices with rationale
• Implementation Plan — Current build plan (future SDP candidate)