IEC 62304 pentru developeri: ce înseamnă de fapt în cod

Prima dată când am lucrat pe software care intra într-un dispozitiv medical, am făcut greșeala pe care o face aproape oricine vine din software „normal“: am crezut că IEC 62304 e un set de reguli despre cum să scriu cod. Nu e.

Standardul aproape că nu-ți spune nimic despre stilul codului. Îți spune ceva mult mai incomod: trebuie să poți dovedi, oricând, ce ai construit, de ce ai construit exact aia, și cum ai verificat că funcționează. Codul e doar unul dintre artefacte.

Articolul ăsta e ce mi-ar fi plăcut să citesc atunci — o explicație de inginer, nu de consultant de calitate.

Ce este de fapt IEC 62304?

IEC 62304 este standardul internațional pentru procesele din ciclul de viață al software-ului de dispozitiv medical. Se aplică atât software-ului care este un dispozitiv (software as a medical device), cât și software-ului dintr-un dispozitiv.

Ce definește el sunt procese, nu implementări:

• dezvoltare (planificare, cerințe, arhitectură, design detaliat, implementare, integrare, testare de sistem, release);
• management de risc al software-ului (legat de ISO 14971);
• management de configurație (știi exact ce versiune a ce ai livrat);
• rezolvarea problemelor (bug-urile se urmăresc, se analizează, se închid documentat);
• mentenanță (ce se întâmplă după release).

Nicăieri nu scrie „folosește X“ sau „acoperire de teste de 80%“. Scrie: decide, justifică, documentează, verifică.

De ce clasa de siguranță decide cât de mult muncești?

Aici e pârghia care schimbă tot. Înainte de orice, software-ul primește o clasă de siguranță, în funcție de ce se poate întâmpla în cel mai rău caz dacă cedează:

Clasa	Ce se poate întâmpla dacă software-ul cedează	Ce se cere în plus
A	Nu poate contribui la o situație periculoasă — sau contribuie, dar riscul rămâne acceptabil după măsurile de control externe software-ului	Minim — inclusiv identificarea componentelor terțe
B	Vătămare, dar nu gravă	Arhitectură + verificare la nivel de unitate software
C	Deces sau vătămare gravă	În plus: design detaliat per unitate și per interfață, plus criterii suplimentare de acceptare

Un detaliu important, adăugat prin amendamentul din 2015: clasificarea se face după ce iei în calcul măsurile de control al riscului din afara software-ului. Un interlock hardware sau un monitor independent pot coborî legitim clasa — ceea ce e exact pârghia din paragraful următor.

Clasificarea nu e o formalitate administrativă: ea determină ce activități ești obligat să faci. Un modul de clasă A poate trece cu documentație minimă. Același modul, dacă e clasificat C, îți cere design detaliat pe unități software și criterii suplimentare de acceptare.

De aici vine și strategia cu cel mai mare efect de pârghie pe care am văzut-o în domeniu: izolarea (segregarea) componentelor cu risc. Dacă poți demonstra arhitectural că partea periculoasă e izolată de restul, poți clasifica separat — și scazi drastic efortul pe restul sistemului. Asta e o decizie de arhitectură cu impact direct pe buget, nu doar pe conformitate.

Cum arată trasabilitatea în practică?

Trasabilitatea e cerința care surprinde cel mai tare developerii. Pe scurt: pentru orice bucată de funcționalitate, trebuie să poți urmări lanțul complet.

De la o cerință de sistem → la o cerință software → la elementul de arhitectură care o implementează → la testul care o verifică → înapoi la riscul pe care îl controlează.

În practică asta înseamnă că fiecare cerință are un identificator stabil, iar commit-urile, testele și documentele îl referențiază. Nu e nevoie de o unealtă scumpă ca să începi; e nevoie de disciplină și de un ID care nu se schimbă.

Ce am învățat: dacă lași trasabilitatea „pe la final“, e deja pierdută. Reconstituirea legăturilor după șase luni de dezvoltare e mult mai scumpă decât menținerea lor pe parcurs.

Ce e SOUP și de ce doare?

SOUP înseamnă Software Of Unknown Provenance — orice componentă pe care nu ai dezvoltat-o tu sub acest proces: biblioteci open-source, runtime-uri, drivere, chiar și părți din sistemul de operare.

Nu e interzis să folosești SOUP. Identificarea se cere la orice clasă; restul obligațiilor de mai jos apar de la clasa B în sus. Pentru fiecare componentă trebuie deci să:

• îl identifici precis — nume, versiune, producător (nu „ultima versiune“);
• specifici cerințele funcționale și de performanță pe care te bazezi;
• specifici cerințele de sistem pe care le impune;
• evaluezi listele publice de anomalii (bug-uri cunoscute) și analizezi dacă vreuna te afectează;
• incluzi componenta în analiza de risc.

Aici e diferența practică față de software-ul obișnuit: npm install sau adăugarea unui NuGet nu mai e o decizie de cinci secunde. Fiecare dependență nouă are un cost documentar real și trebuie reevaluată la fiecare actualizare.

Consecința sănătoasă: în proiectele reglementate, arborele de dependențe rămâne mic în mod deliberat. Nu din purism tehnic, ci pentru că fiecare dependență se plătește în hârtii.

Ce se schimbă concret în munca ta zilnică?

Dacă vii din software comercial, astea sunt schimbările pe care le simți imediat:

• Nu poți începe cu codul. Cerințele și designul vin înainte, și sunt artefacte reale, nu un ticket cu două rânduri.
• Schimbările nu sunt gratuite. O modificare „mică“ poate declanșa reevaluarea riscului, actualizarea designului și retestare. Nu e birocrație pură — e prețul faptului că cineva poate fi rănit.
• Versiunile contează absolut. Trebuie să poți reconstrui exact build-ul livrat, cu exact aceleași dependențe.
• Bug-urile au proces. Nu le repari doar; le înregistrezi, le analizezi impactul (inclusiv asupra riscului) și documentezi rezolvarea.
• Testele sunt dovezi, nu plasă de siguranță. Un test care trece dar nu e legat de o cerință nu-ți folosește la audit.

Care sunt greșelile frecvente?

Din ce am văzut, cele care costă cel mai mult:

1. Clasificare aleasă „ca să fie sigur“. Clasa C pe tot sistemul, din prudență, umflă considerabil efortul — și renunță la argumentul de segregare pe care oricum ar trebui să-l poți susține. Clasificarea argumentată corect e o economie mare, dar vine cu obligația de a o apăra.
2. Documentație scrisă la final. Documentele reconstituite retroactiv sunt vizibile de la o poștă la audit și adesea inconsistente cu codul.
3. Dependențe adăugate fără evidență SOUP. Se descoperă târziu și blochează release-ul.
4. Confuzia între verificare și validare. Verificarea = am construit corect produsul. Validarea = am construit produsul corect (cel de care e nevoie clinic). Sunt lucruri diferite.
5. Tratarea standardului ca pe un obstacol. Cea mai mare parte din el e, de fapt, inginerie bună scrisă formal.

Cum se leagă de cerințele FDA?

Pe scurt: nu sunt același lucru, dar se suprapun mult — iar FDA recunoaște IEC 62304 ca standard de consens, deci conformitatea cu el poate face parte din dovezile pe care le prezinți.

Două lucruri de știut, ca să nu pleci cu presupuneri greșite:

• FDA nu folosește clasele A/B/C. Pentru documentația din dosarul premarket, ghidul FDA lucrează cu două niveluri — Basic și Enhanced Documentation Level. Sunt criterii diferite de clasificarea din 62304 și se stabilesc separat.
• Cadrul din SUA s-a schimbat recent. Prin Quality Management System Regulation (QMSR), aplicabilă din februarie 2026, 21 CFR 820 încorporează prin referință ISO 13485:2016 — deci trimiterile mai vechi la „design controls“ din §820.30 trebuie citite în noul context.

În practică, o abordare des întâlnită e să-ți construiești procesul pe IEC 62304 (fiind mai clar structurat ca proces de inginerie) și apoi să adaugi ce mai cere specific autoritatea din piața ta. Dacă lucrezi și cu înregistrări electronice și semnături electronice, intri suplimentar în zona 21 CFR Part 11 — dar aia e o discuție separată, despre care scriu în alt articol.

Ce iei cu tine dacă vii din software „normal“

Partea care m-a surprins plăcut: după ce te obișnuiești, multe dintre practicile impuse aici sunt lucruri pe care oricum ar trebui să le faci. Cerințe explicite. Decizii de arhitectură scrise. Dependențe puține și cunoscute. Build-uri reproductibile. Bug-uri urmărite până la capăt.

Diferența nu e că lucrezi „mai birocratic“. E că nu ai voie să te bazezi pe memorie și pe noroc. Iar asta, sincer, e o disciplină care m-a făcut un inginer mai bun și în proiectele neregulamentate.

Dacă construiești ceva în zona asta și vrei o părere de inginer care a livrat sub aceste cerințe — nu de consultant de reglementare — hai să vorbim.