Medical Device Classification
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.
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.
What Standard Applies: IEC 62304
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
IEC 62304 defines three safety classes based on the risk of harm from software failure:
| 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.
EU MDR Classification: Class IIa
The platform includes camera-based clinical measurement tools (virtual goniometer, posture analysis, movement quality assessment) that are intended to replace physical instruments. Specialists use these measurements to make treatment decisions. Under EU MDR Rule 11, software that provides information used for diagnosis or treatment decisions classifies as Class IIa (moderate risk).
This is higher than Class I and requires:
- Independent Notified Body audit (not self-declaration)
- Full Quality Management System (ISO 13485)
- Clinical validation (accuracy testing against physical goniometers)
- Full ISO 14971 risk management file
- Active post-market surveillance
Two-tier strategy option: Tier 1 features (treatment assistance — exercise library, treatment plans, guided sessions) could pursue Class I certification first. Tier 2 features (measurement tools — goniometer, posture, movement quality) require Class IIa and could be certified separately or together. See the platform-facing Medical Device page for strategy options.
Phase 2 risk: When the platform adds autonomous patient feedback during exercises ("straighten your back", "bend deeper"), the software begins making clinical assessments without a specialist in the loop. This could push classification further depending on the nature of the feedback.
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)
These features have a medical intended purpose and would be subject to IEC 62304:
| Feature | Clinical Purpose | Risk Example | EU MDR Tier |
|---|---|---|---|
| Exercise Library | Exercise content with contraindications | Wrong exercise shown (ignoring contraindication) | Tier 1 (Class I) |
| Treatment Plans | Prescribed rehabilitation programs | Wrong exercise sequence, incorrect parameters | Tier 1 (Class I) |
| Patient Sessions (telerehab) | Guided exercise execution with video | Patient performs exercise incorrectly due to wrong video | Tier 1 (Class I) |
| Progress Tracking | Monitoring patient recovery | Misleading progress data leads to wrong clinical decision | Tier 1 (Class I) |
| Video Consultations | Clinical decision-making via video | Technical failure during critical clinical assessment | Tier 1 (Class I) |
| Virtual Goniometer | ROM measurement in degrees via camera | Inaccurate measurement leads to wrong treatment decision | Tier 2 (Class IIa) |
| Posture Analysis | Clinical posture assessment via camera | Missed postural deviation leads to inadequate treatment | Tier 2 (Class IIa) |
| Movement Quality Assessment | Exercise form evaluation via pose detection | Incorrect form assessment leads to patient injury | Tier 2 (Class IIa) |
| Patient Form Feedback (Phase 2) | Autonomous real-time corrective guidance | Incorrect guidance leads to patient injury | Tier 2+ (TBD) |
Outside the Regulatory Boundary (administrative)
These features are not medical device functions and do not require IEC 62304 compliance:
- Appointment scheduling and booking
- Billing, service plans, and products
- Organization management and multi-tenancy
- User authentication and RBAC
- Forms (administrative — consent forms, intake forms)
- 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.
Who Cares About Certification (and When)
Nobody asks for certification until someone does. Then everyone asks at once.
Scenario 1: Selling to Hospitals or Large Clinics
Large healthcare organizations 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
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.
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.
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.
Clean domain separation. The repository pattern with dedicated domain packages means the regulatory boundary can map to code boundaries without refactoring.
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
These are the gaps between current state and Class I certification readiness:
1. Requirement IDs and Traceability
Feature docs describe requirements in prose ("Patients follow their program with video guidance") but don't assign IDs. For IEC 62304, each requirement needs an identifier (e.g., REQ-TP-003) that links to a design element and a test case.
Effort: Low — this is a labeling exercise on existing content, not a rewrite.
2. Software Development Plan (SDP)
The implementation plan covers what to build and in what order, but isn't framed as an IEC 62304 SDP. It needs sections for: lifecycle model, tools and infrastructure, deliverables per phase, verification strategy, and references to risk management.
Effort: Medium — restructure and expand the existing plan.
3. Risk Analysis
No formal hazard analysis exists. For Class B, this means a document that identifies: what could go wrong with each clinical feature, how likely it is, how severe, and what controls are in place. Not a full ISO 14971 risk management file (that's for Class II), but a basic risk table.
Effort: Medium — new document, but bounded to clinical features only.
4. SOUP List
Every third-party dependency needs to be cataloged with: name, version, purpose, known anomalies, and risk assessment. This covers go.mod, pnpm-lock.yaml, and significant transitive dependencies.
Effort: Low-Medium — can be partially automated with SBOM tooling.
5. Formal Testing
Test strategy is documented as a gap. IEC 62304 Class B requires integration and system testing with traceability to requirements. Tests don't need to be exhaustive — they need to be traceable.
Effort: High — this is real engineering work, not just documentation.
Path to Certification
Recommended Timeline
| Phase | When | What to Do |
|---|---|---|
| Now | During active development | Keep current documentation quality. Start adding requirement IDs to feature specs. Don't delete git history. |
| Pre-revenue | Before first paying clinic | Add basic risk table for clinical features. Generate SOUP list. |
| First serious client | When a hospital or large clinic asks "are you certified?" | Hire a regulatory consultant for formal gap analysis. |
| 6-12 months before certification | After gap analysis | Formalize SDP, complete traceability matrix, build test suite with evidence, prepare Technical Documentation (EU MDR) or 510(k) submission (FDA). |
| Certification | When ready | Notified Body audit (EU) or FDA review (US). |
Class I vs Class II
Start with Class I. It requires the least documentation overhead and covers the most likely classification for a telerehab platform where the specialist makes the clinical decisions (the software assists but doesn't decide).
Class II becomes relevant if the platform starts making autonomous clinical recommendations — e.g., AI-driven exercise suggestions, automated treatment adjustments, or clinical decision support that goes beyond displaying specialist-prescribed content.
What We Can Do Right Now (Low Cost, High Value)
These habits cost almost nothing during active development but save significant time later:
Add requirement IDs to feature specs — e.g.,
REQ-TP-001: System shall display prescribed exercises with correct parameters. Do this as features are built, not retroactively.Note safety implications in feature docs — even informally: "If this breaks, the risk is: patient sees wrong exercise." This becomes the seed for the formal risk analysis later.
Don't delete git history — it proves the development process was controlled and traceable.
Keep the audit log immutable — it's already designed this way. Don't compromise on this.
When writing tests, reference the requirement — even as a comment:
// Verifies REQ-TP-003: version snapshot is immutable. This makes traceability trivial later.
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 |
| EU MDR | European Union Medical Device Regulation (2017/745) |
| CE Marking | Certification mark indicating conformity with EU health, safety, and environmental standards |
| 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 |
| 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
- 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)