Soluții · Clinici stomatologice
Un site de clinică stomatologică se judecă după un singur lucru: dacă omul găsește serviciul de care are nevoie, cu prețul și cu unitatea lui — pe dinte, pe maxilar, pe ședință — și dacă știe dacă intră sau nu în asigurare. Restul e decor. Construim structura care ține asta și panoul din care personalul o schimbă singur.
Construit dejaLucrarea se poate verifica din exterior chiar acum: datele publice ale unui centru stomatologic raional pe care îl administrăm sunt servite ca fișier structurat — 89 de servicii, fiecare cu categorie, subcategorie, denumire, preț, unitate de măsură și un indicator de eligibilitate pentru asigurarea obligatorie, dintre care 27 marcate ca eligibile; 7 categorii și 10 subcategorii, verificate de noi pe 06.09.2026. A doua parte a dovezii e securizarea, cu diff în istoric: la preluare, parola de administrator era comparată în browser și ajungea în pachetul JavaScript public, iar scrierile pe interfața de programare se puteau face de oricine de pe internet. Precizarea corectă, ca să nu ne atribuim mai mult decât e al nostru: prima variantă a site-ului nu e a noastră. Contribuția care se poate arăta cu diff e preluarea, securizarea, tipurile, integrarea continuă și igiena dependințelor.
O clinică stomatologică nu vinde „servicii”. Vinde o listă foarte lungă de poziții tarifare cu unități care nu seamănă cu nimic din alt domeniu: pe dinte, pe maxilar, pe extracție, pe caz tratat, pe ședință, pe vizită, pe intervenție. Omul care caută pe internet nu caută clinica, ci poziția lui: cât costă o extracție, se plătește pe dinte sau pe vizită, e acoperită de asigurare. Un site care răspunde la asta e util; unul care are o pagină „Prețuri” cu un PDF atașat nu e.
Al doilea lucru pe care îl cere realitatea unei clinici e ca lista să fie schimbabilă fără programator. Tarifele se modifică, medicii se schimbă, programul de urgențe se anunță altfel iarna. Dacă fiecare modificare trece printr-un dezvoltator, lista rămâne veche și, în câteva luni, pacienții vin cu prețul de anul trecut. Structura pe care o construim ține datele publice — servicii și echipă — în fișiere structurate citite atât de interfața de programare, cât și direct de partea vizibilă a site-ului, iar personalul le editează dintr-un panou.
Al treilea lucru, pe care nimeni nu îl cere în brief și care contează cel mai mult, e cine poate scrie în acea listă. La preluarea proiectului despre care scriem aici, oricine de pe internet putea trimite o scriere către interfața de programare, iar parola panoului ajungea în pachetul JavaScript servit browserului — pentru că verificarea ei se făcea în browser. Am mutat verificarea pe server: parola nu mai părăsește serverul, se întoarce un jeton semnat valabil douăsprezece ore, cu limită de opt încercări la cincisprezece minute pe adresă IP și comparații în timp constant; interfața ascultă doar pe adresa locală, deci serverul web e singura cale publică.
Marcajul de acoperire prin asigurarea obligatorie merită o propoziție separată, pentru că e câmpul cu cea mai mare valoare pentru pacient și cel mai mare risc pentru clinică: e o afirmație cu consecințe. De aceea el trăiește ca dată editată de instituție, nu ca text scris de noi într-o pagină; noi construim câmpul, afișarea și posibilitatea de a-l corecta într-un minut.
Ce cuprinde
Structura de date a fiecărui serviciu are categorie, subcategorie, denumire, preț, unitate de măsură și indicator de eligibilitate pentru asigurarea obligatorie. Unitățile sunt cele reale ale domeniului — dinte, maxilar, extracție, caz tratat, ședință, vizită, consultație, anestezie, procedură, investigație, intervenție — pentru că un preț fără unitate produce exact conversația pe care recepția vrea să o evite.
Categorie și subcategorie, nu o listă plată. În lucrarea despre care scriem: 7 categorii și 10 subcategorii peste 89 de servicii. Ordinea de mărime contează — la sub o sută de poziții, o taxonomie pe două niveluri e suficientă; peste câteva sute, structura devine altă discuție și o spunem înainte, nu după.
Indicatorul de eligibilitate stă pe fiecare serviciu, în datele publice, și e editabil de clinică. În lucrarea citată, 27 din 89 de servicii sunt marcate ca eligibile. Nu scriem noi ce intră în asigurare și nu îl deducem: e o afirmație a instituției, cu consecințe pentru pacient, și trebuie să poată fi corectată de ea în orice moment.
Nu o singură pagină „Servicii”. Site-ul are 22 de ecrane, de la servicii și prețuri până la urgențe, ortodonție, implanturi, pedodonție, transparență și feedback. Motivul e practic: cine caută „urgență stomatologică” duminică seara nu vrea o pagină generală, iar o pagină de secțiune are ce spune despre program și despre ce se face în ea.
Serviciile și echipa se editează dintr-un panou, iar scrierile cer un jeton valabil; citirile rămân publice, ca site-ul să funcționeze fără autentificare. Consecința pentru clinică: o modificare de tarif intră în aceeași zi, nu în următoarea iterație de dezvoltare.
Autentificarea se face pe server și întoarce un jeton semnat cu HMAC-SHA256, valabil 12 ore, cu maximum 8 încercări la 15 minute pe adresă IP și comparații în timp constant. Secretul de semnare se generează singur, într-un fișier cu drepturi restrânse, ținut în afara depozitului. Sunt cifre din cod, nu principii generale — se pot citi și contesta.
Ascultă doar pe adresa locală, deci serverul web din față e singura cale publică; lista de domenii permise e explicită, iar corpul cererilor e plafonat la 1 MB. Scrierile cer jeton, citirile nu. E o configurație obișnuită — problema e că, atunci când lipsește, nu se vede din exterior până în ziua în care cineva o găsește.
Verificarea care compilează și verifică tipurile face și un lucru pe care puține proiecte îl fac: caută secrete în pachetul construit și cade dacă găsește. E direct legat de defectul reparat la preluare — o parolă ajunsese în pachetul public tocmai pentru că nimic nu verifica asta. Peste ea, actualizări de dependințe cu ritm săptămânal.
Nu confirmă o programare de unul singur: colectează cererea, iar confirmarea cere fie o persoană, fie o conexiune la sistemul de programări al clinicii — lucrare separată, cu propriile ei condiții. Nu publică informație clinică scrisă de noi: conținutul despre tratamente e responsabilitatea specialiștilor. Și nu decide ce intră în asigurare.
Traseul
Prima livrare e lista de poziții tarifare cu unitatea fiecăreia și cu marcajul de acoperire, în forma în care o ține clinica. Dacă lista nu există într-o formă structurată — și de obicei există ca fișier de calcul sau ca document — o structurăm noi, iar clinica o confirmă. Designul vine după, pentru că el depinde de câte poziții sunt.
Ecranele publice și panoul din care se editează nu se fac separat, pentru că altfel apar câmpuri afișate care nu se pot edita. Livrăm site-ul cu datele reale încărcate, nu cu conținut de umplutură — un site de clinică plin de text provizoriu nu poate fi evaluat de nimeni.
Autentificare pe server, jeton semnat, limită de încercări, interfața de programare doar pe adresa locală, listă de domenii permise, plafon pe corpul cererilor. Livrăm rezultatul unei verificări făcute din afară: ce se poate citi fără autentificare și ce nu se poate scrie.
Predăm accesele, documentul de punere în funcțiune și o instruire scurtă pentru persoana care va schimba tarifele și echipa. Livrarea nu se consideră încheiată până când cineva din clinică nu a făcut, singur, o modificare care apare pe site.
Datele
Regulile diferă de la o industrie la alta. Acestea sunt cele care se aplică în clinici stomatologice.
Un caz
Situația
La preluarea unui site de centru stomatologic, panoul de administrare avea două probleme care se vedeau numai din interior. Prima: parola era comparată în browser, deci ajungea în pachetul JavaScript public. A doua: cererile de scriere către interfața de programare se puteau face de oricine de pe internet, iar portul era expus direct.
Ce am construit
Am mutat verificarea pe server: autentificarea întoarce un jeton semnat cu HMAC-SHA256, valabil 12 ore, cu limită de 8 încercări la 15 minute pe adresă IP și comparații în timp constant; secretul de semnare se generează singur, cu drepturi restrânse, în afara depozitului. Interfața de programare a rămas să asculte doar pe adresa locală, cu serverul web în față, listă de domenii permise și corp de cerere plafonat la 1 MB. Scrierile pe servicii și pe echipă cer jeton; citirile au rămas publice. Peste toate, integrare continuă care compilează, verifică tipurile și refuză pachetul dacă găsește un secret în el.
Ce a ieșit
Datele publice ale clinicii se pot verifica din exterior și azi: 89 de servicii, fiecare cu categorie, subcategorie, preț, unitate și indicator de acoperire prin asigurare, dintre care 27 marcate ca eligibile. Ce s-a schimbat e cine poate scrie în ele.
Ce nu spune cazul
Nu noi am construit prima variantă a site-ului. Din istoricul depozitului, o parte dintre commituri sunt ale unor dezvoltatori externi. Contribuția pe care o putem arăta cu diff e preluarea: securitate, integrare continuă, tipuri, dependințe.
Întrebări
Da — asta e jumătate din lucrare. Serviciile și echipa se editează dintr-un panou; scrierile cer autentificare, citirile rămân publice. Recomandarea noastră: la predare, persoana care se va ocupa face modificarea în fața noastră, ca să știm că merge din mâna ei, nu din a noastră.
Ca indicator pe fiecare serviciu, în aceleași date pe care le editați. În lucrarea pe care o cităm, 27 din 89 de servicii sunt marcate ca eligibile. Noi construim câmpul și afișarea; ce anume e eligibil e afirmația instituției, pentru că are consecințe pentru pacient și pentru clinică.
Pentru că în stomatologie prețul nu e per vizită. E per dinte, per maxilar, per extracție, per caz tratat, per ședință. Un preț afișat fără unitate produce fix conversația pe care recepția o are de zece ori pe zi și, mai rău, senzația pacientului că i s-a spus altceva la telefon.
Poate colecta cererea. Confirmarea unei ore cere fie o persoană care se uită în agendă, fie o conexiune la sistemul de programări al clinicii — e o lucrare separată, cu verificare de compatibilitate înainte. Nu numim „programare online” un formular care trimite un e-mail.
Specialiștii clinicii. Noi nu scriem informație clinică și nu o „optimizăm” pentru căutare, pentru că ar însemna să formulăm afirmații medicale în numele unei instituții medicale. Structurăm, punem întrebările la care textul trebuie să răspundă și îl publicăm după ce e confirmat.
Da, și lucrarea despre care scriem aici e exact asta. Ce facem întâi într-o preluare: ne uităm ce se poate scrie din exterior, unde stau parolele și ce ajunge în pachetul servit browserului. În cazul citat, parola de administrator ajungea în pachetul public, iar scrierile se puteau face de oricine. Am mutat verificarea pe server și am închis scrierile.
Imediat ce e salvată, pentru că datele publice se citesc din aceeași sursă pe care o editați. Ce nu promitem e viteza cu care se actualizează rezultatele din motoarele de căutare — asta nu depinde de noi și nu avem cum să o garantăm.
Se stabilește la implementare: unde ajung, cine le vede, cât se păstrează și ce nu se cere niciodată în formular. Într-o clinică, mesajul conține de multe ori o descriere a unei probleme de sănătate, deci nu e „un lead”, e o categorie de date cu regim strict — și tratarea ei se scrie în politica publicată a clinicii.
Numai dacă vreți. Unele dintre lucrările noastre poartă atribuire în subsol, altele nu — depinde de client. Menționăm asta pentru că e o întrebare pe care o pun clinicile și pentru că, atunci când site-ul nu poartă nicio atribuire, nici noi nu ne prezentăm ca autori fără acordul lor.
Povestește-ne despre procesul tău. Împreună stabilim ce merită construit, ce putem conecta și cum verificăm rezultatul.