Compliance Checklist
Everything the platform and each clinic need to operate legally. The initial launch is Romania / EU only, so GDPR and Romanian law are the day-one requirements. HIPAA becomes relevant only when expanding to serve US-based clinics.
Day One — Romania / EU Launch
RestartiX (platform) must have
| Requirement | What it is | Regulation |
|---|---|---|
| Data Processing Agreement (DPA) template | Standard contract between RestartiX and each clinic. Defines what data is processed, how, and under what instructions. Every clinic signs one before going live. | GDPR Art. 28 |
| Sub-processor list | Public list of all third parties that process data on RestartiX's behalf (Clerk, AWS, Daily.co). Must be kept current and clinics notified of changes. | GDPR Art. 28 |
| Data Protection Impact Assessment (DPIA) | A formal risk assessment for processing health data. GDPR makes this mandatory for any high-risk processing — healthcare always qualifies. Must be completed before processing begins, not after. | GDPR Art. 35 |
| Data Protection Officer (DPO) designation | A named person responsible for overseeing data protection. Required when processing health data at scale. Can be internal or external. Must be independent and report directly to management. | GDPR Art. 37–39 |
| Record of Processing Activities (ROPA) | A formal inventory of: what data the platform processes, for what purpose, on what legal basis, how long it's retained, and who has access. Must be available to regulators on request. | GDPR Art. 30 |
| Cross-border data transfer documentation | If any sub-processor moves data outside the EU (AWS, Clerk, Daily.co likely do), RestartiX must have Standard Contractual Clauses (SCCs) or rely on an adequacy decision for each transfer. Post-Schrems II, this is heavily scrutinized. | GDPR Arts. 44–49 |
| Data residency policy | Explicit documentation of where data is stored geographically (e.g., AWS EU-Central-1 Frankfurt) and a commitment that it won't move without notice. | GDPR Chapter V |
| Breach notification procedure | A documented procedure for detecting, classifying, and reporting breaches — to clinics within 72 hours, and supporting clinics in their notification to the ANSPDCP (Romanian supervisory authority). | GDPR Art. 33 |
| Incident response plan | Goes beyond breach notification. Covers all security incidents: DDoS, credential compromise, ransomware, insider threats. Includes escalation, containment, forensics, and post-incident review. | Best practice / GDPR Art. 32 |
| Terms of Service / Master Service Agreement (MSA) | The commercial contract between RestartiX and each clinic. Covers service levels, liability, termination, and data return procedures. The DPA is usually an annex to this. | Commercial / contractual |
| Medical device assessment | A formal assessment of whether the software qualifies as a medical device under EU MDR. See Medical Device Classification for the full assessment. Even if the answer were "no", the documented assessment is required. | EU MDR 2017/745 |
| Specialist licensing verification | A mechanism to verify that rehabilitation specialists (physiotherapists, kinesitherapists, etc.) are licensed to practice, with expiration tracking. The clinic is ultimately responsible for their specialists' licenses, but the platform should support this. | Romanian Medical Law (Lege 95/2006) |
| Romania-specific compliance review | A review against Romanian Data Protection Law, ANSPDCP requirements, and Romanian healthcare regulations. Romanian law implements GDPR but has additional requirements (e.g., digital consent age is 16). | Romanian national law |
| Cookie consent / ePrivacy | If the platform uses any cookies or client-side analytics, a cookie consent mechanism is required under the ePrivacy Directive. Must allow granular opt-in before non-essential cookies are set. | ePrivacy Directive 2002/58 |
Each clinic (organization) must have
| Requirement | What it is | Regulation |
|---|---|---|
| Privacy Policy | Public document explaining what data the clinic collects, why, how long it's kept, and patient rights. Must be specific to the clinic, not generic. Presented to patients during onboarding as a blocking consent form. | GDPR Arts. 13–14 |
| Terms of Service | Contract between the clinic and the patient covering the telerehabilitation service. Establishes the "performance of contract" lawful basis for core rehabilitation data processing. | GDPR Art. 6(1)(b) |
| Telerehabilitation informed consent | Patients must give specific informed consent for receiving rehabilitation services remotely. This is separate from the general privacy consent — it covers the nature, limitations, and risks of remote treatment. | EU Directive 2011/24, Romanian telemedicine law |
| Signed DPA with RestartiX | The clinic's copy of the Data Processing Agreement. Signed during clinic onboarding to the platform. | GDPR Art. 28 |
| Consent forms (configured in-platform) | Disclaimer-type forms for specific processing activities: profile sharing, video recording, biometric data. Created as form templates in the platform. | GDPR Art. 7 |
| Lawful basis documentation | The clinic must be able to explain, for every type of data they collect, why they are legally allowed to collect it (contract, consent, or legal obligation). RestartiX can provide a template. | GDPR Art. 6 |
Patients receive
| Document | When | How |
|---|---|---|
| Clinic's Privacy Policy | During onboarding at each clinic | Presented as a blocking disclaimer form — must sign before proceeding |
| Telerehabilitation informed consent | During onboarding at each clinic | Blocking form — covers the nature, limitations, and risks of receiving remote rehabilitation services |
| Profile Sharing Consent | During onboarding at each clinic | Blocking form — clinic staff see only the patient's name until this is signed |
| Activity-specific consents (video recording, biometric tracking, etc.) | Before the relevant activity | Presented as blocking disclaimer forms tied to specific appointment types or services |
| Preference consents (marketing, SMS reminders, analytics) | During or after onboarding | Toggle in settings UI — no form or signature required |
Important but Not Day-One Blockers
| Requirement | Who | What it is | Regulation |
|---|---|---|---|
| NIS2 compliance assessment | Platform (only if in scope) | NIS2 classifies "healthcare providers" as essential entities — but that means the clinics, not the SaaS platform. RestartiX is a software vendor / data processor, not a healthcare provider. Additionally, NIS2 exempts small enterprises (fewer than 50 employees and under 10M turnover). As a startup, RestartiX is almost certainly exempt. Revisit if: the company grows past the size thresholds, or if Romania's DNSC specifically designates the platform as in-scope. Note: larger clinics (50+ employees) may need NIS2 compliance themselves — that's their responsibility. Romania transposed NIS2 via GEO 155/2024 and Law 124/2025. | EU Directive 2022/2555 |
| Workforce security training program | Platform + Clinic | GDPR expects data protection awareness training for anyone who handles personal data. Should be documented with completion records. | GDPR Art. 39 |
| Cyber liability insurance | Platform | Not legally required, but practically expected by clinic customers and investors. Should cover data breach costs, regulatory fines (where insurable), and legal defense. | Industry standard |
| Digital prescription regulations | Platform + Clinic | If prescriptions are issued through the platform, Romanian law has specific e-prescription format and digital signature requirements. | Romanian Order 900/2006 |
| Data retention configuration per clinic | Platform | Allow each clinic to configure retention periods. Automated cleanup jobs enforce these. Romanian medical record retention laws may set minimum periods. | GDPR Art. 5(1)(e) |
| ROPA template for clinics | Platform | Provide clinics with a pre-filled Record of Processing Activities template they can adapt. Makes it easier for small clinics to meet their GDPR Art. 30 obligations. | GDPR Art. 30 |
When Expanding to the US Market — HIPAA Requirements
HIPAA is a US-only law. It applies to RestartiX only when a US-based clinic uses the platform. See HIPAA Compliance for the full overview of what HIPAA is and how the platform already supports it.
RestartiX (platform) must add
| Requirement | What it is | Regulation |
|---|---|---|
| Business Associate Agreements (BAAs) with sub-processors | Signed contracts with every vendor that touches PHI: Clerk (auth), AWS (infrastructure), Daily.co (video). | HIPAA |
| Security Officer designation | A named person responsible for the security of PHI. Can be the same person as the DPO. | HIPAA Security Rule |
| HIPAA Security Risk Assessment | An annual formal risk analysis of all systems that touch PHI. Identifies vulnerabilities, assesses likelihood and impact, and documents mitigation plans. Required annually, not just once. | HIPAA 164.308(a)(1) |
| HIPAA workforce training | Regular staff training on PHI handling, specific to HIPAA requirements. Must be documented with completion records. | HIPAA 164.308(a)(5) |
Each US clinic must add
| Requirement | What it is | Regulation |
|---|---|---|
| Signed BAA with RestartiX | A Business Associate Agreement. Required before the clinic can use the platform to process US patient PHI. | HIPAA |
| Privacy Officer designation | A named person responsible for the clinic's HIPAA privacy program. | HIPAA Privacy Rule |
| Staff PHI training | All clinic staff who access the platform must be trained on HIPAA rules for handling PHI. | HIPAA 164.308(a)(5) |
| Own HIPAA compliance program | The clinic must maintain their own HIPAA policies, risk assessments, and breach reporting procedures — independent of what RestartiX provides. | HIPAA |
For developers
Technical implementation details — GDPR anonymization logic, consent tracking schema, audit middleware, encryption algorithms — are available in the Technical Reference section of the Development Documentation.