When switching to the R3 database, one of the implementation phases consists not only in the simple migration of data in a new environment, but also in the conversion of the XML R2 file to the more recent HL7 R3 format. It is a delicate operation that requires a path with steps to be defined precisely in sharing with the customer. Below we explain how we approach the issue with SafetyDrugs 6.

Conversion plan

This is the second phase of the implementation of the native R3 database, immediately following the initial analysis of the project. After the signing of the contract, the dates and the timings for the transition to the new software are defined, in order to plan the entire project that will lead to the startup.

 

Depending on the R2 database of origin, the kind of approach to follow for data conversion is established:
• if the client has a database able to extract the ICSRs in XML R2 format, they will be upgraded to the HL7 R3 format using a special conversion tool. After that, it will be easy to import the data into the new database
• on the contrary, if the cases are stored in an Excel spreadsheet, every single column will have to be analyzed in order to normalize the contents and lead them to standard ICH E2B (R3) format. In this way, the information will be aligned to the new requirements making them perfectly acquirable from SafetyDrugs 6. After this analysis, a conversion map that defines the exact location of each data in the corresponding E2B and not-E2B fields contained in SafetyDrugs 6 will be drawn up. Then, the development of the migration scripts will follow.

 

After the evaluation of the data transfer modality, the Dry Run tests are performed. These are informal tests that aim is to ensure the successful outcome of the migration process. They are run in the client’s test environment, previously configured according to the agreed specifications, to allow its own internal verifications.

 

Once the migration has taken place, the quantitative validation is carried out. It consists in verifying the correspondence between the total number of cases counted in the original database and those contained in SafetyDrugs 6. A check is also performed on some subtotals, such as the subtotal of SERIOUS/NOT SERIOUS cases, of cases by PRIMARY SOURCE COUNTRY, of cases by REPORT TYPE, of events by MedDRA SOC, of events by OUTCOME and subtotal by DRUG.

 

To further prove the correctness of the conversion, the client can also request the qualitative validation: on a predefined sample of cases, the data between the old and the new database of each migrated field are compared.

 

Subsequently, upon the client’s approval, the test environment and all the data contained in it are fully copied in the production environment.