Soluții operaționale reale pentru calitatea în DCT – Dincolo de teorie, aproape de audit

În articolul anterior („Cum arată un sistem de calitate real într-un DCT”), am demontat mitul că tehnologia, de una singură, garantează calitatea. Am arătat de ce trasabilitatea nu înseamnă doar existența unui software, ci un mod de lucru construit și menținut constant. Am vorbit despre realitatea de pe teren: inconsistența surselor digitale, roluri neclare în echipă și pierderea controlului asupra datelor.

Acest articol continuă exact de acolo.

Nu vom relua principiile. Le considerăm deja înțelese.

Aici vorbim despre cum se face, în practică, un sistem de calitate care funcționează în studiile clinice descentralizate — și despre de ce atât de puțini îl aplică corect.

Pentru orice site clinic — fie că este parte dintr-un SMO, afiliat unui spital sau independent — calitatea nu mai este un ideal. Este un avantaj strategic într-un ecosistem descentralizat.

1. Elemente operaționale critice pentru un sistem de calitate funcțional în DCT

Toată lumea vorbește despre descentralizare, dar puțini recunosc adevărul de la firul ierbii: tehnologia nu rezolvă nimic dacă echipele nu știu cum s-o controleze. Iar în DCT, „controlul” nu înseamnă supraveghere — ci calibrare continuă. Fiecare sursă de date, fiecare aplicație și fiecare interacțiune cu pacientul poate deveni o vulnerabilitate dacă nu este integrată într-un sistem viu, verificabil, auditat în timp real.

1.1. Controlul surselor digitale multiple (ePRO, wearables, apps)

În studiile descentralizate, sursele de date nu mai intră toate prin investigator. Ele vin fragmentat: aplicații ePRO, senzori purtabili, platforme web, interfețe API. Dacă nu sunt mapate de la început, pot genera inconsistențe care scapă la audit sau chiar compromit integritatea datelor.

🔹 Cum se face corect maparea:
Înainte de startul studiului, toate sursele digitale trebuie identificate și integrate într-o diagramă operațională clară:

  • Ce tip de date furnizează fiecare (ex. simptome, pași, puls)?
  • În ce format sunt înregistrate?
  • Cine are responsabilitatea validării fiecărei surse?

Această mapare se include în SOP și trebuie să fie cunoscută și aplicată de întreaga echipă locală – nu doar de sponsor sau CRO.

🔹 Responsabilitate distribuită, nu delegată:
Nu este suficient ca sponsorul sau furnizorul de tehnologie să declare că platforma e validată. Site-ul trebuie să definească clar:

  • Cine verifică punctual datele din ePRO și când?
  • Cine verifică transmiterea corectă a datelor din wearables către EDC?
  • Ce se întâmplă dacă nu există conexiune internet? Cine verifică și când?

🔹 Erori frecvente care scapă la audit:

  • Date fără timestamp sincronizat cu serverul
  • Lipsa verificării umane a valorilor extreme
  • Backup local inexistent – ceea ce înseamnă că dacă serverul furnizorului cade, centrul nu mai poate dovedi nimic

⚠️ Recomandare critică:
Pentru toate sursele critice (ex: ePRO și dispozitive purtabile), trebuie implementată o redundanță minimă: date sincronizate în cloud + capturi locale (loguri automate, emailuri de confirmare, arhivare săptămânală offline).
Este una dintre cele mai simple metode de protecție într-un audit — și una dintre cele mai neglijate.

🔹 Cum se integrează maparea în SOP (Standard Operating Procedure)
Maparea surselor digitale nu este doar o referință generală într-un SOP. Ea trebuie integrată sub forma unei anexe vizuale (ex: diagramă de flux) care descrie:

  • sursa → ce tip de date transmite,
  • responsabil → cine verifică și validează,
  • frecvență → când și cum se face verificarea,
  • back-up → cum se păstrează dovada locală.

Această anexă trebuie revizuită la fiecare actualizare de protocol și aprobată formal de investigatorul principal sau coordonatorul de studiu. Centrele care nu au infrastructură IT pot folosi chiar și variante manuale (PDF-uri printate cu checkboxes sau versiuni Excel verificate și semnate).

1.2. Sistemul de evidență și trasabilitate a interacțiunilor digitale

Unul dintre cele mai invocate concepte în DCT este „audit trail-ul complet”. Dar în lipsa unui sistem clar și distribuit de trasabilitate, acest ideal rămâne un mit periculos. Fără instrumente bine calibrate, datele pot fi colectate, dar nu pot fi demonstrate. Iar în studiile descentralizate, dovada procesului contează uneori mai mult decât rezultatul în sine.

🔹 Ce trebuie să probezi, concret:
Un sistem valid de evidență digitală trebuie să poată răspunde în orice moment la întrebările:

  • Cine a generat o anumită informație?
  • Când a fost aceasta înregistrată, verificată și sincronizată?
  • Ce platforme au fost implicate în transferul datelor?

Fără această reconstrucție clară, datele nu sunt „neconforme” — sunt pur și simplu necredibile.

🔹 Riscuri reale dacă lipsește trasabilitatea:

  • API-urile care transmit date automat din wearables în EDC nu păstrează întotdeauna loguri de activitate per utilizator.
  • Dacă nu se salvează dovada transmiterii, orice eroare de integrare duce la pierdere de date nerecuperabilă.
  • Centrul nu poate demonstra dacă un punct de date a fost introdus manual, preluat automat, sau dacă a fost modificat ulterior.

🔹 Cum construiești un sistem de audit trail eficient:

  1. Loguri digitale generate automat din fiecare platformă (ePRO, EDC, wearables) – exportate periodic și păstrate local.
  2. Checkpoint-uri de verificare setate în mod regulat de coordonatorul de studiu — de ex.: „verificarea completitudinii” săptămânală.
  3. Arhivare cross-platform sincronizată: un sistem în care datele din aplicații mobile, platforme online și fișiere locale pot fi corelate cu un minim de pași.

🔹 Criterii de auditabilitate reală:

  • Fiecare punct de date poate fi reconstruit de la sursă (nu doar vizualizat).
  • Orice modificare ulterioară este însoțită de user ID + timestamp.
  • Orice lipsă de informație este semnalată automat (ex: lipsă de sincronizare, timeout API, eroare de server).

⚠️ Recomandare operațională: Centrele trebuie să definească în SOP un „punct de control al trasabilității”, cu responsabilitate alocată și checkuri periodice. Nu presupune costuri, ci doar disciplină procedurală — dar este unul dintre cele mai importante semne că un centru înțelege calitatea în DCT.

🔹 Exemplu practic – Studiul ADAPTABLE (Medidata)

Unul dintre cele mai clare exemple de trasabilitate digitală reușită vine din studiul ADAPTABLE (cardiologie, SUA), unde audit trail-ul a fost construit pornind de la:

  • Integrarea surselor ePRO și wearables într-o arhitectură API cu loguri accesibile echipei de site,
  • Puncte de verificare validate în faza de pre-trial,
  • Confirmare automată a fiecărei interacțiuni pacient–platformă prin e-mail și log exportabil,
  • Training operațional dedicat pentru echipele de site — inclusiv în scenarii offline.

Acest model este frecvent citat ca referință de bune practici în trasabilitate digitală în DCT.

1.3. Rolul echipei în menținerea calității – nu doar PI-ul, ci întreg site-ul

Una dintre cele mai mari capcane în studiile descentralizate este presupunerea că responsabilitatea calității revine exclusiv PI-ului (principal investigator). În realitate, controlul calității într-un DCT este o funcție colectivă – iar centrele care reușesc să evite devieri sistemice sunt cele care distribuie responsabilitatea clar, activ și documentat.

🔹 Ce înseamnă calitate operațională în practică pentru un coordonator de studiu:

  • Crearea de checklist-uri funcționale, adaptate fiecărui protocol – nu doar template-uri generale.
  • Monitorizarea activă a punctelor critice prin flag-uri interne: întârzieri la transmiterea ePRO, lipsa sincronizării datelor, discrepanțe între surse.
  • Menținerea de loguri structurate pentru fiecare sursă digitală – cu notarea manuală a excepțiilor, backup-urilor și verificărilor făcute local.

🔹 Exemple din practică:

Studiile documentate de Medidata arată că site-urile care au desemnat un „Quality Anchor” intern — adică o persoană responsabilă zilnic de coerența operațională — au:

  • Timp mediu de răspuns la audit redus cu 47%
  • Rată de deviații sistemice cu 35% mai mică
  • Încadrarea în termenele de reconciliere a datelor (data lock) cu până la 2 săptămâni mai rapid

🔹 Rolul SMO-ului în calitate:

Un SMO nu este doar un furnizor de personal sau spații. Este gardianul sistemului de calitate, iar asta presupune:

  • Desemnarea formală și funcțională a unui rol activ în controlul calității
  • Implementarea unui ciclu intern de autoevaluare lunară: loguri, gap assessment, verificare de proceduri
  • Crearea de proceduri de escaladare clare și aplicate, nu doar teoretice

🔴 Fără acest sistem colectiv, DCT-ul devine o colecție de aplicații disparate, nu un proces clinic coerent.

📎 Surse utilizate pentru această secțiune:
Sursa 1 – Cambridge: A Maturity Model for Clinical Trials Management Ecosystem
Sursa 3 – Medidata: Case Study Collection on DCT (PDF)

2. Instrumente operaționale recomandate pentru centre și SMO-uri


Calitatea în DCT nu ține de câte aplicații folosești, ci de cât de bine poți controla ceea ce ai deja. Majoritatea centrelor și SMO-urilor nu au acces la infrastructură IT avansată – dar acest lucru nu este o scuză. Este o oportunitate de a construi sisteme de control simple, robuste și verificate. Un site de calitate nu este cel care are software sofisticat, ci cel care nu pierde niciodată un punct de date important.

2.1. Documente standardizate care funcționează în practică
• SOP-urile trebuie să fie mai mult decât un set de fișiere stocate pe server. Ele trebuie să reflecte realitatea de zi cu zi din site:
– Cine face ce, când, cu ce instrumente?
– Ce se întâmplă când apare o eroare într-o aplicație?
– Cum se face verificarea manuală a datelor în caz de întrerupere a conexiunii?

🔹 Ce trebuie să includă un SOP corect pentru DCT:
• Proceduri specifice pentru fluxuri descentralizate: verificare la distanță, erori de sincronizare, validarea datelor din wearables.
• Persoana responsabilă pentru fiecare tip de verificare — cu frecvență specifică.
• Fiecare SOP trebuie adaptat configurației reale a studiului (tipul de dispozitive, aplicații, căi de transfer al datelor).
• Trebuie evitate formularele generice. SOP-ul trebuie să descrie exact ce se face în acel centru.

• Toate aceste scenarii trebuie incluse în SOP-uri, validate de echipa locală și testate periodic.
• Log-urile operaționale trebuie să fie structurate clar (ex: date check log, device sync log, deviation log) și păstrate în format accesibil – digital sau tipărit.

🔹 Set minim de loguri operaționale recomandate:
• Loguri zilnice sau săptămânale cu datele digitale primite
• Checklisturi de completitudine a datelor pentru fiecare platformă
• Loguri ale deviațiilor apărute în sincronizare sau transmiterea cross-platform

• Audit trail-urile trebuie documentate și local, nu doar în platforma sponsorului – pentru a permite demonstrarea rapidă în caz de audit.
• Modificările asupra datelor trebuie însoțite de user ID + timestamp.
• Datele lipsă sau invalide trebuie marcate clar, cu justificare documentată (root cause analysis).

📌 Recomandare operațională:
Fiecare centru trebuie să definească un „pachet de documentație de calitate” — un set concret de SOP-uri, loguri și exporturi de trasabilitate, care să poată fi prezentat oricând la audit ca dovadă a controlului operațional. Este una dintre cele mai tangibile forme prin care un centru poate demonstra calitatea reală.

🔹 Nu este suficient ca logurile să fie păstrate — ele trebuie să fie ușor de accesat, structurate și validabile oricând, mai ales în cazul unui audit inopinat.

2.2. Sisteme simple, dar eficiente – fără IT avansat
Site-urile care nu dispun de infrastructură digitală complexă pot implementa variante hibride:
• Tabele sincronizate cu acces controlat – pentru monitorizarea sarcinilor și verificărilor
• Capturi automate de ecran, exporturi PDF din platformele folosite, arhivate săptămânal
• Back-up manual al datelor critice în fișiere criptate, păstrate offline
• Verificări periodice tip checklist – tipărite sau digitale – pentru fiecare dispozitiv sau aplicație

🔹 Alte metode care funcționează în practică:
• Tabele centralizate cu actualizări zilnice ale evenimentelor de colectare a datelor (chiar și în format manual)
• Exporturi săptămânale ale datelor din ePRO sau wearables (CSV, PDF)
• Sisteme semi-automate de cross-check — ex: semnalare când un punct de date lipsește sau întârzie

🔹 Redundanță = reziliență:
• Confirmările critice (ex: date transmise prin API) trebuie stocate în două locuri: în platformă și într-o arhivă separată (ex: e-mail sau server local).
• Dacă se utilizează suport pe hârtie ca backup, trebuie definit clar: cât de des, cine îl completează, cine verifică și cum se reconciliază cu varianta digitală.

🔹 Instrumente utile chiar fără IT sofisticat:
• SOP-uri în versiuni controlate + loguri de semnătură/confirmare a citirii
• Foldere partajate cu acces restricționat + loguri de acces
• Capturi de ecran sau confirmări e-mail salvate în fișierul pacientului

📌 Aceste instrumente simple pot fi puse în aplicare în orice centru și sunt recunoscute pozitiv în audituri, atâta timp cât sunt folosite consecvent și documentate corect. Auditorii sunt mai interesați de consistență și control decât de nivelul de sofisticare tehnologică.

2.3. Procese care nu trebuie niciodată externalizate
Chiar dacă sponsorul sau CRO-ul oferă suport tehnologic, există procese esențiale care trebuie păstrate în interiorul centrului:
• Reconcilierea datelor din surse multiple (ePRO, EDC, wearables)
• Verificarea punctelor critice – ex: valori extreme, lipsă sincronizare, lipsă confirmare
• Instruirea echipei locale – nu doar inițial, ci recurent (training practic, role-play, revizuire de erori)

🔹 Procese care trebuie să rămână 100% în controlul centrului:
• Managementul deviațiilor și analiza cauzelor primare (root cause analysis)
• Actualizările și re-instruirea echipei după amendamente de protocol
• Explicarea modului în care se menține controlul asupra fiecărei platforme

📌 Centrele care externalizează aceste procese pierd controlul asupra calității reale – și vor fi primele penalizate la audit.
📌 Sponsorii urmăresc tot mai des ce centre își mențin controlul real asupra proceselor DCT — iar această metrică afectează direct alocările viitoare de studii.

📌 Calitatea nu poate fi delegată. Dacă un centru nu poate demonstra cum păstrează controlul asupra sistemelor digitale, va fi automat perceput ca un risc — indiferent de viteza de recrutare.

🔹 Exemplu practic – Studiul REACT-EU (Medidata)
Un exemplu excelent de implementare eficientă a proceselor DCT în condiții reale este studiul REACT-EU, desfășurat în centre fără infrastructură digitală avansată. Echipele locale au utilizat loguri manuale verificate săptămânal, capturi de ecran stocate local și checklisturi printate — toate documentate riguros și acceptate în audit. Acest model este o dovadă clară că, și în absența unor sisteme IT sofisticate, calitatea în DCT poate fi atinsă dacă există disciplină procedurală și control local.
📌 Este un precedent validat care contrazice ideea că descentralizarea necesită tehnologie complexă — și întărește rolul critic al echipelor locale în menținerea integrității datelor.
🟦 Fără această formă minimă de control intern, niciun centru nu poate dovedi calitatea datelor sale. Iar în DCT, ceea ce nu poate fi demonstrat — nu există.

2.4. Site-centricity – Filosofia operațională care separă centrele de încredere de centrele de risc

Cele mai multe discuții despre descentralizare se concentrează pe pacient. Dar din perspectiva calității operaționale, întrebarea critică este alta: „Cât de pregătit este centrul să funcționeze ca un nod activ într-un ecosistem digital?”

IQVIA propune un cadru esențial pentru evaluarea maturității site-urilor în DCT – numit „site-centricity”. Nu este vorba despre autonomie completă, ci despre capacitatea unui centru de a demonstra control real asupra proceselor digitale care îl implică.

🔹 Site-centricity înseamnă:

  • Să poți arăta, oricând, cum sunt verificate și reconciliate datele din platforme digitale.
  • Să ai persoane desemnate, proceduri și dovezi că ești în controlul sistemului – nu doar utilizatorul lui.
  • Să menții o documentație vie, care reflectă ce se întâmplă în fiecare zi, nu doar ce scrie în SOP-uri.

📌 Site-centricity nu e despre cât de multe aplicații folosești – ci despre cât de ușor poți demonstra că ceea ce folosești funcționează și e controlat de tine.

🔹 Trei indicatori care definesc un centru „site-centric”:

  1. Control demonstrabil: existența unor mecanisme de verificare internă, nu doar dependența de platformele sponsorului.
  2. Evidență clară a responsabilităților: fiecare interacțiune digitală este asociată cu un responsabil desemnat local.
  3. Procese decizionale autonome: centrul are libertatea și capacitatea de a interveni în timp real când apar erori operaționale sau neconcordanțe în fluxul de date.

🔹 Diferența dintre „participant-centric” și „site-centric”
Deși multe inițiative se concentrează pe experiența pacientului, nicio experiență pozitivă nu poate compensa lipsa de calitate a datelor. Calitatea DCT se susține pe ambele axe:

  • o experiență sigură și fluidă pentru pacient,
  • și o arhitectură robustă de control în centrul de studiu.

📌 Centrele care înțeleg și aplică filosofia „site-centrică” sunt cele care devin partenere strategice pentru sponsori, nu doar executanți de sarcini.

🔴 Fără această schimbare de mentalitate, niciun audit favorabil și nicio rată bună de recrutare nu pot garanta continuitatea în alocarea viitoarelor studii.

📎 Surse utilizate pentru această secțiune:

  • Sursa 1 – Cambridge: A Maturity Model for Clinical Trials Management Ecosystem
  • Sursa 3 – Medidata: Case Study Collection on DCT (PDF)
  • Sursa 6 – FDA: Conducting Clinical Trials With Decentralized Elements (Guidance 2023)

3. Cum recunosc sponsorii centrele de încredere în DCT: semnale concrete, nu impresii

Într-un studiu descentralizat, nu numărul de pacienți recrutați sau viteza de randomizare determină continuitatea colaborării – ci capacitatea centrului de a controla ceea ce nu poate fi văzut direct.

📌 Pentru sponsori, un centru de încredere nu este cel care spune că respectă procedurile, ci cel care poate dovedi asta oricând – cu date, loguri și acțiuni.

🔹 Iată ce diferențiază centrele „de încredere” de cele „de risc” în ochii sponsorilor:

3.1. Capacitatea de a răspunde la audit, oricând, cu documente clare

• Centrele de încredere au deja pregătit un „audit kit”: loguri, exporturi, confirmări de transmitere, back-up-uri și devieri înregistrate local.
• Centrele de risc cer timp, caută documente în mai multe locuri sau trimit fișiere incomplete.
💡 Exemplu real: într-un DCT derulat de Medidata, centrele care aveau loguri validate săptămânal au primit 2 studii suplimentare fără audit fizic.

3.2. Răspuns operațional la erori, nu doar notificări către sponsor

• Centrele de încredere detectează devieri înainte să fie observate de CRO.
• Mențin un jurnal al erorilor recurente și propun soluții operaționale.
💡 Exemplu: într-un alt DCT de fază II, centrele care au raportat discrepanțe între ePRO și wearables înainte de detectarea centrală au fost incluse în steering committee-ul studiului.

3.3. Coerență între SOP și realitate

• Centrele de încredere au SOP-uri care corespund exact cu procedurile observabile în activitatea zilnică.
• Nu se bazează pe template-uri venite de la sponsor – ci își personalizează procedurile și le actualizează după fiecare amendament.
💡 Indicator: sponsorii solicită tot mai des exemplare de SOP-uri reale și verifică dacă ele sunt aplicate în logurile centrului.

3.4. Instruire continuă și autoevaluare internă

• Centrele de încredere pot demonstra că echipa locală a fost re-instruită de fiecare dată când s-a schimbat ceva în fluxul digital.
• Instruirea nu înseamnă doar semnături pe foi – ci role-play-uri, exemple reale și sesiuni de reconciliere practică a datelor.
📌 Centrele care documentează aceste sesiuni au rate de eroare cu 30–50% mai mici în primele luni de studiu.

3.5. Autonomie operațională (dar documentată)

• Centrele care pot lua decizii locale, în cazuri-limită (ex: lipsă internet, date întârziate, confirmări lipsă), fără să blocheze studiul, sunt cele care câștigă încrederea sponsorilor.
• Dar această autonomie trebuie să fie documentată – cu rationale, excepții notate, acțiuni confirmate.
💡 Fără această capacitate, centrul devine un punct vulnerabil în rețeaua descentralizată.

🔚 Un centru de încredere nu este cel care funcționează fără greșeli, ci cel care poate demonstra – în orice moment – cum identifică, controlează și corectează acele greșeli.

📌 Pentru sponsori, încrederea în DCT se câștigă pe bază de dovezi. Iar aceste dovezi nu sunt în platforme – ci în mâinile echipei locale.

4. Ce înseamnă, concret, un sistem de calitate real în DCT

Un sistem de calitate real nu începe cu tehnologie, ci cu o întrebare fundamentală: Poate centrul tău dovedi, oricând și oricui, că datele generate sunt corecte, complete și recuperabile?

📌 Într-un studiu descentralizat, ce nu poate fi dovedit – nu există. Fiecare platformă, fiecare interacțiune digitală, fiecare deviere necontrolată devine un potențial punct de risc care se răsfrânge asupra întregului centru.

🧩 Calitatea nu este un SOP. Nu este un software. Nu este un audit trecut acum 2 ani.
Este un mod de lucru zilnic, în care:

  • echipa înțelege ce trebuie să verifice și când,
  • fiecare pas este documentat într-un mod auditabil,
  • iar procesele sunt suficient de robuste pentru a funcționa și în lipsa tehnologiei.

Un centru care reușește asta nu mai este un simplu „executor de sarcini”.
Este un partener strategic de încredere, capabil să asigure continuitate, siguranță și valoare într-un ecosistem de cercetare tot mai descentralizat.

📌 În era DCT, centrele care pot demonstra controlul local asupra calității vor fi cele care rămân în joc. Celelalte vor fi, inevitabil, înlocuite.

🟦 Cât din ceea ce numești ‘calitate’ în DCT-ul tău poate fi demonstrat, nu doar afirmat?
În era descentralizării, documentația nu e suficientă. Trebuie să dovedești că fiecare punct de date contează – și că știi de ce.

Sursa 1 – Cambridge: A Maturity Model for Clinical Trials Management Ecosystem
🔗 https://www.cambridge.org/core/journals/journal-of-clinical-and-translational-science/article/maturity-model-for-clinical-trials-management-ecosystem/CBD72518D2D8EBD079BAF3477A4827B4

Sursa 2 – IQVIA: Empowering Clinical Research Sites and Sponsors in the Patient-centric Era
🔗 https://www.iqvia.com/-/media/iqvia/pdfs/library/white-papers/bcs2024-1062-04apr-pscs-site-whitepaper-tankersley.pdf

Sursa 3 – Medidata: Case Study Collection on DCT
🔗 https://www.medidata.com/en/life-science-resources/medidata-blog/decentralized-clinical-trials-case-study-collection/

Sursa 4 – FDA: Conducting Clinical Trials with Decentralized Elements (Guidance 2023)
🔗 https://www.fda.gov/media/167696/download