21 CFR Part 11 în practică: audit trail, semnături electronice, integritatea datelor

Când auzi prima dată „trebuie să fim conformi cu Part 11“, sună a task de documentație. Nu e. Part 11 se traduce în decizii de arhitectură pe care, dacă le iei greșit la început, le plătești printr-o rescriere.

Am lucrat pe sisteme unde asta conta efectiv — componente pentru un sistem de date de cromatografie la Waters și sisteme clinice la Cerner. Articolul ăsta e despre partea de inginerie, nu despre cum se completează formularele.

Ce cere de fapt 21 CFR Part 11?

Este reglementarea FDA pentru înregistrări electronice și semnături electronice. Ideea centrală: dacă înlocuiești hârtia și semnătura de mână cu un sistem informatic, sistemul trebuie să ofere cel puțin aceeași încredere.

Cerințele care ating direct codul:

• sistemul e validat (poți demonstra că face ce trebuie);
• poți genera copii exacte și complete ale înregistrărilor, într-o formă utilizabilă pentru inspecție;
• înregistrările sunt protejate și pot fi regăsite pe toată durata de păstrare;
• accesul e limitat la persoane autorizate;
• există un audit trail securizat, generat de calculator, cu marcaj de timp;
• verificări de autoritate — cine are voie să facă ce.

Observă ce nu scrie: nicio tehnologie anume. Poți fi conform cu tehnologii foarte diferite, dacă poți demonstra proprietățile de mai sus.

Și, mai important, nu se aplică peste tot. Part 11 vizează înregistrările cerute de o reglementare de fond (predicate rule) și pe care alegi să le ții electronic. Prin ghidul FDA din 2003 privind domeniul de aplicare, agenția și-a declarat intenția de a exercita discreție în aplicare pentru o parte din cerințe — inclusiv audit trail — și a legat decizia de o evaluare de risc justificată și documentată. Practic: nu auditezi tot pentru că „așa cere Part 11“, ci pentru că ai stabilit, argumentat, ce intră în domeniu.

Restul articolului presupune că ai făcut deja delimitarea asta.

Ce înseamnă „audit trail“ în cod?

Aici se împotmolesc cele mai multe echipe, pentru că un audit trail conform nu e un simplu tabel de log-uri.

Trebuie să fie:

• generat de sistem, nu de utilizator — nimeni nu-l scrie manual;
• cu marcaj de timp, înregistrat independent de operator — în practică, ora serverului, nu cea furnizată de client;
• să înregistreze crearea, modificarea și ștergerea înregistrărilor, cu cine și când;
• să nu ascundă informația anterioară — valoarea veche rămâne vizibilă, nu e suprascrisă;
• păstrat cel puțin cât înregistrarea la care se referă.

Consecința tehnică e mare: nu ai voie să pierzi valoarea anterioară la o modificare. Fie versionezi rândul, fie un trigger capturează starea veche înainte să fie suprascrisă — cerința e ca informația precedentă să rămână recuperabilă, nu ca rândul curent să nu fie niciodată actualizat. „Ștergerea“ devine, de regulă, o marcare logică. Iar audit trail-ul nu poate fi editabil din aplicație — dacă un admin îl poate modifica, nu mai are valoare probatorie.

O greșeală clasică: log-uri de aplicație folosite ca audit trail. Log-urile se rotesc, se pierd, se pot filtra și nu sunt structurate pe înregistrări. Nu sunt același lucru.

Cum arată o semnătură electronică conformă?

O semnătură electronică nu e o bifă „Sunt de acord“. Reglementarea cere ca semnătura să conțină explicit:

Componentă	Ce înseamnă practic
Numele semnatarului	tipărit, nu doar un ID intern
Data și ora semnării	marcaj de timp al sistemului
Semnificația semnării	ce înseamnă: revizuire, aprobare, responsabilitate, autor

În plus, semnătura trebuie legată de înregistrarea ei astfel încât să nu poată fi decupată, copiată sau transferată pe altă înregistrare pentru a falsifica ceva.

Pentru semnăturile care nu se bazează pe biometrie, se cer cel puțin două componente distincte de identificare — de exemplu un identificator de utilizator și o parolă. Într-o sesiune continuă, prima semnare le folosește pe amândouă, iar semnările următoare pot folosi cel puțin componenta privată persoanei. În afara unei sesiuni continue, fiecare semnare le cere pe toate.

Din perspectiva implementării, asta înseamnă că „semnătura“ e o entitate proprie în model, legată criptografic sau referențial de conținutul semnat — nu un câmp approved_by pe rândul respectiv.

Ce e integritatea datelor (ALCOA+)?

În jurul Part 11 gravitează un set de principii de integritate a datelor, cunoscute ca ALCOA+. Nu sunt textul reglementării, dar sunt limbajul comun în care inspectorii discută datele:

• Attributable — se știe cine a făcut acțiunea;
• Legible — se poate citi și interpreta;
• Contemporaneous — s-a înregistrat când s-a întâmplat, nu retroactiv;
• Original — sursa primară, nu o transcriere;
• Accurate — corectă;
• plus: completă, consistentă, durabilă, disponibilă.

Dacă îți proiectezi modelul de date ținând cont de ele, conformitatea devine o consecință, nu un efort separat. „Contemporaneous“, de exemplu, îți spune imediat că ora trebuie luată de la server, nu de la client.

Ce greșesc cel mai des echipele?

1. Tratează Part 11 ca pe un strat adăugat la final. Un audit trail corect schimbă modelul de date; nu se lipește peste o schemă cu UPDATE-uri distructive.
2. Confundă logging-ul cu audit trail-ul. Vezi mai sus — scopuri complet diferite.
3. Semnătura ca simplu boolean. Fără nume, moment și semnificație, nu e semnătură.
4. Ceasuri necontrolate. Marcaje de timp din surse diferite, fără fus orar clar, distrug credibilitatea întregii serii.
5. Uită partea de export. Cerința de „copii exacte și complete“ înseamnă că trebuie să poți scoate datele într-o formă inspectabilă — proiectat din start, nu improvizat sub presiune.

De unde începi dacă produsul tău intră sub Part 11?

Ordinea care mi s-a părut cea mai eficientă:

1. Stabilește ce înregistrări sunt reglementate. Rar e toată baza de date. Delimitarea reduce enorm munca.
2. Proiectează audit trail-ul înainte de feature-uri. E o decizie structurală.
3. Fă semnătura o entitate de prim rang în model.
4. Controlează timpul dintr-o singură sursă.
5. Construiește exportul devreme și testează-l ca pe un feature real.

Restul — politici, instruire, proceduri — există și contează, dar sunt în afara codului. Partea pe care o poți strica ireversibil ca inginer e cea de mai sus.

Dacă construiești ceva care intră în zona asta și vrei o discuție tehnică — nu una de conformitate — sunt deschis.