Planuri și Abonamente

Cum câștigă RestartiX din relația cu clinicile și cum își monetizează clinicile pacienții pe platformă. Modelul de business pe înțelesul tuturor.

---

2 Tipuri de Model de Business

Banii circulă în două tipuri de relații comerciale distincte:

Tip	Cine plătește	Cine încasează	Pentru ce se plătește
Pachete Clinici	Clinica	RestartiX	Acces la platformă — funcționalități, capacitate, suport
Pachete Pacienți	Pacientul	Clinica	Acces la serviciile clinicii — îngrijire premium, telereabilitare, programări prioritare

Cele două tipuri sunt independente prin construcție. Pachetul clinicii determină ce instrumente și ce limite are clinica la dispoziție. În cadrul acelor limite, clinica decide cum își structurează și cum își prețuiește propria ofertă către pacienți.

Notă

„Pachet" în acest document înseamnă două lucruri distincte:

• Pachete Clinici (Free / Pro / White-Label) — nivelurile comerciale ale platformei, vândute de RestartiX clinicilor.
• Pachete Pacienți (Basic / Premium) — categoriile pe care fiecare clinică le definește pentru pacienții ei.

Niciunul nu se confundă cu planurile de servicii — pachetele terapeutice cu mai multe ședințe pe care clinicile le vând pacienților (de exemplu, „pachet de fizioterapie cu 10 ședințe"). Acelea sunt documentate în Catalog de Servicii. Sunt trei concepte distincte care sună similar; acest document acoperă primele două.

---

Pachete Clinici (clinici → RestartiX)

Ce vinde RestartiX clinicilor. Trei elemente de bază, combinabile.

Pachete de bază

Abonamentul principal al clinicii. Stabilește fundamentul: ce funcționalități sunt deblocate, câți pacienți și câți specialiști sunt permiși, ce nivel de suport face parte din relație.

Catalogul include trei niveluri ilustrative — denumirile și prețurile efective sunt configurabile, nu fixate în cod:

Nivel	Adresat	Include (exemple)	Limite (exemple)
Free	Pentru testare, practician unic	Programări, fișe de pacient, formulare de bază	50 de pacienți, 1 specialist, fără domeniu personalizat
Pro	Clinici stabilite	+ Domeniu personalizat, automatizări, webhook-uri, șabloane de documente	1.000 de pacienți, 10 specialiști, 50 GB stocare
White-Label	Clinici care cer izolare completă de brand; condiții negociate comercial	+ Suport prioritar, limite personalizate, fără atribuire către platformă, organizație dedicată la furnizorul de auth	Negociate prin contract

Pachetul White-Label este denumirea comercială a modului de izolare per tenant — brandul clinicii este singurul vizibil pentru pacienți, identitatea rulează într-un namespace dedicat, iar la încheierea contractului datele se exportă curat. Pachetele Free + Pro rulează pe modul partajat (named-tech); White-Label rulează pe modul tenant-isolation. Rețelele de spitale și nivelurile cu infrastructură dedicată sunt în mod permanent în afara scopului platformei (vezi CLAUDE.md → Project Overview).

Funcționalitățile clinice (telereabilitare, consultații video, măsurători cu camera) sunt controlate separat — vezi Întrebarea funcționalităților medicale.

Mai multe locații sunt parte din fundație, disponibile pe orice pachet

Lucrul cu mai multe locații este un element fundamental al platformei (Layer 1B.14, vezi foundation.md) — orice clinică, indiferent de nivel, poate opera cu mai multe locații fizice. Numărul de locații incluse pe nivel (și eventualele tarife per locație) este o limită de pachet din catalog, nu o restricție funcțională. Lucrul cu mai multe locații nu este restricționat la White-Label.

Add-on-uri

Se adaugă peste pachetul de bază. Clinica își păstrează pachetul de bază și adaugă funcționalitățile specifice de care are nevoie.

Exemple: Pachet Telereabilitare (deblochează planurile de tratament și prescripția exercițiilor), Pachet Video (deblochează consultațiile video integrate), Pachet Branding (deblochează domeniu personalizat și personalizare de brand pe pachetele cu mod partajat, fără să impună trecerea la White-Label).

O clinică pe Pro + Pachet Telereabilitare plătește pentru ambele, primește ambele și poate renunța la add-on fără să afecteze pachetul de bază.

Extra Usage

Achiziții punctuale care cresc o capacitate specifică. Utile pentru utilizare neuniformă, care nu justifică un upgrade de nivel.

Exemple: +1.000 de minute video (adăugate la luna curentă), +10 GB stocare, +500 de locuri pentru pacienți.

Pachetele Extra Usage se adaugă la contorul curent al perioadei de facturare sau până când sunt consumate. Sunt aditive, nu înlocuitoare.

Cum se compune factura unei clinici

Pachet de bază Pro            RON  490 / lună
Pachet Telereabilitare        RON  290 / lună
Extra minute video            RON   80 / plată unică (luna aceasta)
                              ──────────────
                              RON  860 luna aceasta

Intern, platforma suportă orice combinație. Prețurile ilustrative de mai sus sunt doar pentru explicație — prețurile efective se decid comercial și se actualizează prin catalog, nu prin cod.

---

Pachete Pacienți (pacienți → clinică)

Fiecare clinică își definește propriul catalog de pachete. Platforma nu impune o anumită structură — fiecare clinică decide cum (sau dacă) să își segmenteze pacienții comercial.

Exemple de utilizare a pachetelor

Stil de clinică	Pachet 1	Pachet 2	Pachet 3
Fizioterapie sportivă	Îngrijire standard	Premium (programări prioritare, rapoarte mai rapide)	—
Orientată spre telereabilitare	Evaluare gratuită	Abonament lunar (planuri de tratament + bibliotecă)	—
Multi-specialitate	Pacient ocazional	Calitate de membru (servicii cu reducere + telereabilitare)	Plan corporate (sponsorizat de angajator)
Practician unic	(fără pachete — toți pacienții sunt egali)	—	—

O clinică poate avea un singur pachet (toți la fel), două pachete (gratuit / premium) sau mai multe. Denumirile, prețurile și ce deblochează fiecare țin în întregime de decizia clinicii.

Ce poate include un pachet

Un pachet face două lucruri în același timp. Atribuie pacientului un rol (care determină ce poate face — să se programeze direct, să acceseze biblioteca, să vadă anumite tipuri de documente) și poate de asemenea să grupeze incluziuni contorizate (un număr fixat de servicii incluse, care se regenerează la fiecare perioadă).

Partea de rol nu este limitată de cote — „pacienții Premium pot să își atribuie singuri planuri de tratament" se aplică la oricâte planuri de tratament dorește pacientul, controlat doar de RBAC. Partea de incluziune contorizată este pentru lucrurile pe care clinica vrea să le contorizeze — „4 consultații gratuite incluse cu abonamentul anual", „4 planuri de tratament atribuite de specialist pe an", „10% reducere la următoarele 5 programări". Un pachet poate combina ambele liber.

Două politici implicite sunt încorporate în model, suprascrieabile per incluziune atunci când o clinică are nevoie de un comportament diferit:

• Folosește-le sau le pierzi la reînnoire. Atunci când anul se rotește și pacientul nu a folosit toate cele 4 consultații, restul nu se reportează. Contabilitate clară; corespunde așteptărilor pacienților față de formularea „X pe an".
• Acordare integrală la upgrade. Atunci când un pacient face upgrade de la Basic la Premium la mijloc de an, primește cele 4 consultații complete, nu prorate. Practică standard ca pârghie comercială; încurajează upgrade-urile la mijloc de ciclu.

Exemplu: Annual Premium

O clinică orientată spre telereabilitare pe Pro + Pachet Telereabilitare definește:

Pachet	Rol	Incluziuni contorizate
Free	Acces de pacient doar pentru citire	Niciuna
Annual Premium (200 RON / lună)	Acces la bibliotecă + auto-atribuire	4 consultații / an + 4 planuri de tratament atribuite de specialist / an

Când Maria se înscrie la Annual Premium:

• Primește rolul Premium imediat — poate să își atribuie singură din biblioteca de exerciții, să vadă datele de contact ale specialiștilor, să acceseze portalul de telereabilitare.
• Platforma îi acordă automat două înrolări de plan de servicii — 4 ședințe de consultație și 4 atribuiri de plan de tratament de specialist. Fiecare contorizează utilizarea.
• Când Maria rezervă o consultație, platforma decrementează automat contorul. Același flux de programare ca pentru un plan cumpărat direct.
• Un an mai târziu, perioada se rotește — ședințele rămase se pierd, se acordă 4+4 noi pentru noua perioadă.
• Dacă Maria face upgrade la un pachet superior la mijloc de perioadă, incluziunile vechi expiră și incluziunile complete ale noului pachet sunt acordate.

Clinica nu scrie cod și nu rulează cron-uri. Definește catalogul („iată pachetele pe care le oferim, iată ce include fiecare"), iar platforma se ocupă de ciclul de viață: provizionare la înscriere, decrementare la consum, expirare la anulare, reacordare la reînnoire.

Ce se schimbă atunci când un pacient trece între pachete

Fiecare pachet corespunde unui rol din interiorul clinicii. Rolurile determină ce poate face pacientul — să se programeze direct la specialiști, să acceseze biblioteca de telereabilitare, să vadă anumite tipuri de documente etc.

Atunci când pachetul unui pacient se schimbă (clinica îl trece de la Basic la Premium), platforma îi actualizează automat permisiunile și incluziunile. Clinica nu administrează permisiuni per pacient — administrează pachetele, iar platforma se ocupă de restul.

Asta înseamnă că o clinică poate schimba semnificația unui pachet (de exemplu, să adauge acces la bibliotecă pentru „Premium") fără să reatribuie fiecare pacient în parte: fiecare pacient Premium moștenește schimbarea.

Fluxul banilor: astăzi vs. mâine

Astăzi (Faza 1): clinica deține relația de facturare cu pacientul.

• Clinica facturează pacientul prin canalul pe care îl folosește deja — facturare clasică, casă de marcat, sistem contabil existent.
• Atunci când pacientul plătește pentru Premium, clinica (sau sistemul ei existent) îi comunică platformei: „acest pacient este acum Premium". Platforma actualizează pachetul pacientului, iar permisiunile și incluziunile decurg de aici.
• RestartiX nu vede niciodată banii pacienților. Nu suntem procesator de plăți și nu suntem marketplace în această etapă.

Mâine (etapă ulterioară): facturare opțională mediată de platformă (Stripe Connect sau echivalent).

• Pacientul plătește prin checkout-ul platformei. Banii circulă prin RestartiX, reținem un comision, iar restul se transferă către clinică.
• Clinicile aderă voluntar. Cele care au deja sisteme de facturare cu care sunt mulțumite pot rămâne pe modelul actual pe termen nedefinit.
• Asta deblochează un al doilea flux de venituri pentru RestartiX (comisioane de tranzacție pe abonamentele pacienților, în plus față de taxele pentru Pachetele Clinici).

Schema este construită să suporte ambele variante de pe prima zi — diferența constă în ce integrare de plată este conectată. Trecerea la modul marketplace este o decizie strategică, nu o re-architecture.

---

Cum interacționează cele două tipuri

Pachetul cumpărat de clinică stabilește posibilitățile la care clinica are acces. Clinica, în cadrul acelor posibilități, își proiectează propriile Pachete Pacienți.

Exemplu concret:

O clinică pe pachetul Pro cu add-on-ul Pachet Telereabilitare poate oferi pacienților săi:

• Un pachet Basic (gratuit sau cu cost redus): programări standard, formulare de admitere.
• Un pachet Premium (cu plată, de exemplu 200 RON/lună): programări standard plus planuri de tratament atribuite de specialist plus acces la biblioteca de exerciții.

Dacă aceeași clinică renunță la Pachetul Telereabilitare, pierde posibilitatea de a atribui planuri de tratament. Pacienții existenți pe Premium își păstrează pachetul — dar nu se mai atribuie planuri de tratament noi. Datele pacienților nu sunt niciodată șterse din cauza unei schimbări de facturare. Clinica decide dacă reînnoiește add-on-ul sau dacă restructurează pachetul Premium fără telereabilitare.

Dacă clinica trece la White-Label cu un contract personalizat, poate oferi câte pachete vrea — Bronze / Silver / Gold / Corporate / Insurance / Family — în limita capacității acordate prin contract.

---

Cinci principii care stau la baza modelului

Sunt alegeri de design deliberate, cu consecințe strategice care merită înțelese.

1. Pachetele nu acordă permisiuni; rolurile da

Un pachet deblochează funcționalități (de exemplu, platforma permite folosirea telereabilitării). Nu spune cine din clinică poate folosi telereabilitarea — asta ține de configurația de roluri a clinicii.

Consecința strategică: schimbarea nivelurilor de preț nu strică configurația de permisiuni internă a clinicii. Promovarea unei clinici de la Pro la White-Label nu îi dă brusc puteri de admin recepționerei. Trecerea de la Pro la Free nu lasă tot personalul fără acces. Rolurile sunt stabile; pachetele doar controlează ce funcționalități există.

Această separație susține și clinicile white-label care vor pachete de roluri non-standard („specialist-recepționer hibrid", „proprietar de clinică fără acces clinic"). Își pot defini propriile roluri fără modificări la logica noastră de prețuri.

2. Schimbările de preț nu afectează clienții existenți

Atunci când un client se abonează la Pro la 490 RON / lună cu o capacitate de 1.000 de pacienți, acele condiții sunt fixate pe abonamentul lui. Șase luni mai târziu, dacă urcăm Pro la 590 RON / lună cu o capacitate de 2.000 pentru noile abonamente, clientul existent este protejat — continuă la 490 cu 1.000.

Îi putem propune upgrade-ul la reînnoire sau printr-o intervenție comercială, dar nu modificăm fără înștiințare un contract pe care l-a acceptat deja.

Consecința strategică: experimentarea cu prețurile este sigură. Putem publica un nivel nou, putem urca prețuri, putem rula o promoție sau putem restructura catalogul fără risc juridic față de relațiile existente, și fără modificări de cod pentru protejarea clienților vechi — se face automat.

3. Excepțiile comerciale sunt parte integrantă a modelului

Atunci când o conversație comercială ajunge la „pachet Pro, dar cu capacitate de 5.000 de pacienți și automatizări deblocate" pentru că asta închide afacerea, nu trebuie să creăm un pachet personalizat unic. Acordăm o excepție per-clinică peste snapshot-ul pachetului Pro, cu motivul înregistrat și partea care a acordat-o.

Consecința strategică: vânzarea are flexibilitate fără efort suplimentar din partea echipei tehnice. Contractele negociate sunt date înregistrate, nu cod personalizat.

4. Mai multe abonamente se cumulează

O clinică poate deține un pachet de bază plus N add-on-uri plus M pachete Extra Usage simultan. Fiecare e propriul abonament, fiecare se poate anula independent. Funcționalitățile și limitele efective rezultă prin însumare.

Consecința strategică: putem vinde îngust (clinica ia doar ce-i trebuie), putem împacheta larg (White-Label cuprinde tot) și matematica iese mereu. Add-on-uri noi pot fi introduse fără să restructurăm pachetele de bază.

5. Funcționalitățile medicale sunt controlate separat de facturare

Telereabilitare, video integrat, măsurători cu camera — sunt funcționalități clinice care intră sub incidența reglementării dispozitivelor medicale (zona EU MDR Clasa IIa). Sunt controlate de un strat separat de capabilități, pe care platforma îl activează per-clinică atunci când sunt îndeplinite condițiile de reglementare.

Motorul de pachete acționează asupra capabilităților (o clinică pe Pro + Pachet Telereabilitare ar trebui să aibă capabilitatea de telereabilitare activă), dar software-ul clinic nu citește niciodată direct din sistemul de facturare — citește din stratul de capabilități.

Consecința strategică este dublă:

• Putem pune funcționalitățile clinice în spatele unui pachet plătit fără ca certificarea de dispozitiv medical să interfereze cu logica noastră de prețuri. Modificările de preț nu declanșează revalidare de reglementare.
• Putem dezactiva o funcționalitate clinică pentru o clinică anume din motive de reglementare — fără să afectăm facturarea ei și fără să rescriem contractul. Capabilitatea este poarta; facturarea este pârghia care de obicei o controlează.

Aceasta este formula care permite platformei să fie pregătită pentru certificarea de dispozitiv medical și, în același timp, flexibilă din punct de vedere comercial.

---

Întrebarea funcționalităților medicale

O consecință specifică a principiului #5, evidențiată separat pentru că este strategic importantă.

Funcționalitățile clinice ale platformei (atribuiri de telereabilitare, prescripția exercițiilor, măsurarea posturii și a amplitudinii articulare cu camera, consultații video integrate) intră în interiorul granițelor reglementării dispozitivelor medicale. EU MDR Clasa IIa este nivelul realist de încadrare; este documentat în Clasificare Dispozitiv Medical.

Implicația comercială: putem vinde aceste funcționalități prin pachete și add-on-uri, dar sunt în același timp supuse unei porți separate de tip „este această clinică autorizată din punct de vedere reglementar?" pe care platforma o controlează.

Trei tipare în care se manifestă acest lucru:

• Astăzi, înainte ca certificarea MDR Clasa IIa să fie obținută: capabilitățile clinice sunt OFF în mod implicit. Pachetele pot să le promoveze, dar platforma nu deblochează efectiv fluxurile clinice până când capabilitatea nu este activată. Este o stare fail-safe deliberată.
• Odată ce certificarea este obținută: pachetele acționează asupra capabilităților. O clinică pe Pro + Pachet Telereabilitare primește automat capabilitatea de telereabilitare activă la nivel de platformă, fără intervenție manuală.
• Excepție per-clinică: o problemă de reglementare, o îngrijorare jurisdicțională sau un incident pot scoate o capabilitate offline pentru o clinică anume fără anularea facturării. Clinica rămâne pe pachetul ei; capabilitatea este pusă pe pauză; comunicăm motivul și termenul estimat.

Acesta este un model neobișnuit pentru un SaaS — în majoritatea SaaS-urilor, „ai plătit, ai acces". Pentru software medical, „ai plătit ȘI granița de reglementare este deschisă" este modelul corect. Platforma este construită pentru asta de la prima zi.

---

Foaie de parcurs

Etapă	Ce există	Ce urmează
Acum (fundație)	Schemă pentru Pachete Clinici, add-on-uri, pachete Extra Usage, abonamente, Pachete Pacienți, incluziuni de pachet, excepții comerciale, control de capabilități. Provizionare manuală de către echipa RestartiX.	—
În curând	UI-ul de Console pentru administrarea abonamentelor și a Pachetelor Pacienți. Înregistrare self-service cu un pachet implicit. Proiecția capabilităților (automatizare pachet → capabilitate).	Pagină publică de prețuri; flux self-service de upgrade de pachet.
Mai târziu	Integrare externă de facturare (Stripe / Chargebee pentru facturarea Pachetelor Clinici). Portal comercial pentru contracte negociate.	Modul marketplace (Stripe Connect pentru facturarea clinică→pacient) — decizie strategică, nu o cale implicită.
Pe termen lung	Proiecția capabilităților reglementate din pachete (telereabilitare, video) odată ce certificarea MDR este obținută. Contorizare bazată pe consum pentru minute video / stocare.	Facturare multi-valută pentru expansiunea internațională.

---

Ce permite acest lucru pentru afacere

• Mai multe fluxuri de venituri. Pachetele Clinici sunt linia principală; comisioanele de tranzacție pe abonamentele pacienților devin a doua linie dacă și atunci când trecem în mod marketplace. Nu este nevoie de re-architecture în niciun caz.
• Flexibilitate comercială. Contractele negociate sunt date înregistrate, nu cod personalizat. Vânzările pot închide afaceri cu condiții non-standard în câteva ore, nu în săptămâni.
• Experimentare cu prețurile. Schimbările de niveluri, prețuri, împachetare nu afectează clienții existenți (protejarea este automată) și nu necesită efort de inginerie peste editări de catalog.
• Pregătire white-label. Clinicile își definesc propria structură de Pachete Pacienți, cu sau fără incluziuni contorizate. Modelul lor comercial intern nu este constrâns de al nostru.
• Postură de conformitate. Logica de pachete și software-ul clinic sunt decuplate. Modificările de preț nu declanșează revalidare de dispozitiv medical. Funcționalitățile clinice pot fi dezactivate prin reglementare per-clinică fără să afecteze factura.

---

Pentru dezvoltatori

Arhitectura tehnică — schema, semantica de snapshot, proiecția capabilităților, compoziția middleware-ului, incluziuni de pachet — este documentată în Architecture › Plans & Subscriptions, Architecture › Org-Level Settings și Architecture › Middleware Composition.