Security & Compliance
How the RestartiX platform protects patient data, meets regulatory requirements, and maintains trust.
The platform handles sensitive health information for every patient and clinic on the system. Security and compliance are not add-ons — they are built into the architecture from day one.
At a Glance
| Area | What We Do | Learn More |
|---|---|---|
| How Patient Data Is Protected | The full picture — controller/processor split, consent surface, privacy notices, break-glass access, DSAR routing | Start here for the complete model |
| Data Isolation | Each clinic's data is separated at the database level — no application bug can cross boundaries | How clinic data stays separate |
| Encryption | Data encrypted in transit and at rest, with application-level encryption for the most sensitive fields | What's encrypted and how |
| Audit Trail | Every data mutation is logged — who did what, when, from where — immutable and retained for 6 years | What's logged and for how long |
| GDPR | Full compliance with European data protection law — consent management, data portability, right to erasure | EU data protection |
| HIPAA | Ready for US healthcare market — PHI protection, audit controls, breach notification | US healthcare compliance |
| Patient Rights | Patients control their data — access, correct, delete, export, and withdraw consent at any time | What patients can do |
Medical Device Regulation
The platform's clinical features — exercise prescription, treatment plan management, progress tracking, adherence monitoring, and camera-based clinical measurement tools — qualify it as a Software as a Medical Device (SaMD) under EU MDR.
Following a regulatory consultation (March 2026), the platform's clinical features classify as Class IIa (moderate risk) under MDR Rule 11 — even without the measurement tools, because treatment plan management, progress tracking, and adherence monitoring each independently constitute therapy monitoring under MDR. The recommended strategy is to register as Class I initially (via Rule 13, as competitors do) and pursue proper Class IIa certification as the business grows. This is separate from data protection (GDPR/HIPAA) but equally important for operating legally in the EU healthcare market.
| Regulatory area | What it covers | Learn more |
|---|---|---|
| Data protection (GDPR, HIPAA) | How patient data is collected, stored, shared, and protected | This section |
| Medical device (EU MDR, IEC 62304) | How clinical software is developed, tested, validated, and maintained | Medical Device Classification |
Both are required. GDPR compliance does not satisfy medical device requirements, and vice versa.
Our Roles
| Role | Who | Responsibility |
|---|---|---|
| Data Controller | Each clinic | Owns the patient relationship. Decides what data is collected and how it is used. Publishes the privacy notice. Responds to patient rights requests. |
| Data Processor | RestartiX (the platform) | Provides the platform under a Data Processing Agreement. Processes patient data only as the clinic instructs. Does not browse identifiable patient data outside the documented break-glass exception path. |
| Data Subject | The patient | Holds enforceable rights over their data. Exercises those rights against the clinic, with the platform helping route the request. |
This is the same model Stripe uses with merchants — the clinic owns the substantive relationship; the platform provides the technical scaffolding under contract. RestartiX signs a Data Processing Agreement (DPA) with every clinic, and is the controller only for the thin slice of account-level data needed to keep the platform running (login credentials, security telemetry on the account, fraud prevention).
For the full picture — including the two-tier consent surface, how privacy notices are clinic-owned-but-platform-scaffolded, what platform staff can and cannot see, and how DSARs are routed — read How Patient Data Is Protected.
Compliance Status
The full compliance checklist covers every legal document and requirement for launch — organized by party (platform, clinic, patient) and phase (day-one EU launch vs. future US expansion).
View the full Compliance Checklist →
See Medical Device Classification for the regulatory assessment of the platform's clinical features.
For developers
Technical implementation details — RLS policies, encryption algorithms, audit middleware, RBAC configuration — are available in the Technical Reference section of the Development Documentation.