Quando si passa al database R3, una delle fasi dell’implementazione consiste non solo nella semplice migrazione dei dati nel un nuovo ambiente, ma anche nella conversione del file XML R2 al più recente formato HL7 R3. È un’operazione delicata che richiede un percorso con step da definire in modo preciso in condivisione con il cliente. Di seguito spieghiamo come affrontiamo la questione con SafetyDrugs 6.

È la seconda fase dell’implementazione del database nativo R3, subito successiva all’analisi iniziale del progetto. In seguito alla firma del contratto, vengono definite le date e le tempistiche per il passaggio al nuovo software, in modo da pianificare l’intero progetto che porterà allo start up.

Dipendendo dal database R2 di provenienza si stabilisce il tipo di approccio da seguire per la conversione dati:

  • nel caso in cui il cliente sia in possesso di un database in grado di estrarre gli ICSR in formato XML R2, si procederà all’upgrade degli stessi al formato HL7 R3 attraverso un apposito tool di conversione. Dopodiché sarà facile importare i dati nel nuovo database
  • al contrario, qualora i casi siano conservati in un foglio Excel, si dovrà analizzare ogni singola colonna per normalizzarne i contenuti e ricondurli ai formati standard ICH E2B (R3). In questo modo le informazioni saranno allineate ai nuovi requisiti rendendole perfettamente acquisibili da SafetyDrugs 6.

Successivamente a questa analisi, si procederà alla stesura di una conversion map che definisca l’esatta collocazione di ogni dato nei corrispondenti campi E2B e non E2B contenuti in SafetyDrugs 6 e a cui seguirà lo sviluppo degli script per la migrazione.

Dopo la valutazione della modalità di trasferimento dati, seguono i Dry Run test, ovvero test informali il cui obiettivo è quello di accertarsi del buon esito del processo di migrazione. Questi sono eseguiti nell’ambiente di test del cliente, precedentemente configurato secondo le specifiche concordate, per consentire le proprie verifiche interne.

A migrazione avvenuta, si esegue la validazione quantitativa che consiste nella verifica della corrispondenza tra il totale dei casi conteggiati nel database originario e quelli contenuti in SafetyDrugs 6. Si esegue, inoltre, un controllo anche su alcuni subtotali, quali ad esempio il subtotale dei casi SERIOUS/NOT SERIOUS, dei casi per PRIMARY SOURCE COUNTRY, dei casi per REPORT TYPE, degli eventi per MedDRA SOC, degli eventi per OUTCOME e del subtotale per DRUG.

A ulteriore prova della correttezza della conversione, il cliente può richiedere anche la validazione qualitativa: su un campione predefinito di casi vengono confrontati i dati tra il vecchio e il nuovo database di ogni singolo campo migrato.

Successivamente, previa approvazione del cliente, si eseguirà la copia integrale dell’ambiente di test con i dati in esso contenuti nell’ambiente di produzione.