Octodoc: de la o cerință complexă la un produs de telemedicină activ

În 2025, am început colaborarea cu echipa Octodoc pornind de la un obiectiv clar, dar dificil: să contribuim la apropierea serviciilor medicale de oamenii din comunitățile în care accesul la un medic poate fi limitat de distanță.

Rezultatul este acum activ. Primele dispozitive Octodoc deservesc comunitățile pentru care au fost construite și susțin un parcurs care poate include programarea, etape ghidate de preconsult și consultația video cu un profesionist din domeniul medical.

Pentru Solandrix, proiectul a însemnat mai mult decât dezvoltarea unei aplicații. A fost dezvoltarea personalizată a unui ecosistem de produs conectat: portalul de back-office, software-ul utilizat prin intermediul dispozitivelor Octodoc și aplicația folosită de medici. Fiecare componentă deservește un alt tip de utilizator și un alt context, dar toate trebuie să funcționeze ca un singur produs.

Am pornit de la serviciul oferit, nu de la software

Scopul Octodoc este de a face serviciile medicale mai accesibile, aducând mai aproape de pacienți cât mai mult din experiența unui cabinet medical. Acest scop a orientat proiectul de la început.

Împreună cu echipa Octodoc, am clarificat cerințele de business, responsabilitatea fiecărei componente din ecosistem și calitățile tehnice pe care produsul trebuia să le susțină. Securitatea, scalabilitatea și performanța nu au fost tratate ca o listă de verificat la final. Au fost cerințe care au influențat deciziile de produs și de livrare pe tot parcursul proiectului.

Dezvoltarea produsului a inclus întregul context operațional al serviciului, nu doar componenta software. Fiecare categorie de utilizatori - pacient, medic sau echipă operațională - are nevoi și fluxuri distincte, care trebuie să funcționeze împreună într-o experiență coerentă și eficientă.

Un produs, mai multe experiențe conectate

Ecosistemul reunește trei zone principale:

• experiența oferită prin dispozitivul Octodoc pe parcursul interacțiunii pacientului;
• aplicația medicilor, folosită pentru pregătirea și desfășurarea consultațiilor la distanță;
• portalul de back-office, folosit pentru susținerea și operarea serviciului.

Complexitatea nu a constat doar în construirea a trei interfețe. A fost necesar să definim ce informații îi sunt necesare fiecărui utilizator, când trebuie acestea să devină disponibile și cum răspunde produsul atunci când o etapă nu poate fi finalizată conform așteptărilor.

Contextul fizic a adăugat un nivel suplimentar. Un kiosk nu este o aplicație web obișnuită, utilizată de la birou. Interfața trebuie să rămână clară pentru persoane cu niveluri diferite de familiaritate cu tehnologia. Instrucțiunile trebuie înțelese în momentul în care sunt necesare, acțiunile trebuie identificate ușor, iar parcursul trebuie să țină cont de dispozitivele care fac parte din experiența consultației.

Pentru medici, viteza și claritatea sunt importante dintr-un alt motiv. Aplicația trebuie să susțină consultația, nu să distragă atenția medicului. Pentru utilizatorii operaționali, produsul trebuie să facă starea serviciului ușor de înțeles și să susțină activitatea necesară în jurul acestuia.

Livrarea în etape ne-a permis să adaptăm produsul

Am împărțit proiectul în pași mici și utilizabili, pe care echipa Octodoc i-a putut evalua și testa intern pe tot parcursul proiectului.

Astfel, am creat un circuit practic de feedback:

1. agream cerința și rezultatul așteptat;
2. proiectăm și dezvoltăm o parte bine delimitată a parcursului;
3. o testăm în contextul serviciului complet;
4. ajustăm comportamentul sau experiența atunci când rezultatele indică această nevoie;
5. folosim ceea ce am învățat în următorul pas.

Această abordare a fost importantă deoarece unele decizii devin clare doar atunci când un flux real poate fi utilizat. Testarea internă ne-a ajutat să rafinăm funcționalitățile cât timp schimbarea era încă ușor de gestionat, în loc să descoperim târziu că o ipoteză nu se confirmă în practică.

De asemenea, a menținut conectate deciziile de business, de experiență a utilizatorului și cele tehnice. O schimbare într-o parte a ecosistemului putea fi analizată prin efectul asupra persoanelor și sistemelor din jur, nu ca un tichet izolat.

Dezvoltare pentru un produs care trebuie operat

Octodoc este un serviciu activ, nu o demonstrație. Prin urmare, activitatea de dezvoltare a trebuit să țină cont de operarea continuă și de evoluția viitoare.

Am folosit tehnologii enterprise și tipare de dezvoltare consacrate, potrivite cerințelor produsului. Principiile de lucru sunt clare: responsabilități bine delimitate, un sistem care poate fi observat și întreținut, protejarea informațiilor sensibile și proiectarea fiecărei componente astfel încât ecosistemul să poată evolua fără să își piardă coerența.

Performanța și scalabilitatea au fost luate în calcul în fluxurile în care viteza de răspuns contează pentru utilizatori și în care cererea se poate schimba în timp. Securitatea a fost abordată ca o responsabilitate la nivelul întregului produs, cu atât mai importantă într-un context medical. Aceste cerințe au fost echilibrate cu nevoia de a livra pași utili și de a învăța din testare.

De la un obiectiv comun la un serviciu utilizat

Cea mai importantă etapă a proiectului nu este finalizarea software-ului. Este faptul că produsul este folosit acum pentru scopul care a ghidat munca: să ajute echipa Octodoc să apropie profesioniștii din domeniul medical de oamenii care altfel ar trebui să parcurgă distanțe mai mari pentru a avea acces la servicii.

Pentru a ajunge aici a fost necesară o colaborare strânsă. Echipa Octodoc a adus viziunea serviciului și cunoașterea domeniului. Împreună, am transformat această viziune în cerințe de business, de utilizare și tehnice, am făcut compromisurile vizibile și am ajustat produsul pe măsură ce testarea a adus informații noi.

Suntem mândri că am contribuit la un produs cu un rol direct și practic în viața oamenilor și că vedem primele dispozitive Octodoc ajutând acum comunitățile lor.