Data migrations

Missing records due to technical errors during data migration (see below)... 

With electronic medical records, multiple clinical records for the same patient may be treated as belonging to different patients during anonymization and migration of electronic medical records, tainting analytical conclusions. This problem may be difficult to untangle once the anonymized data migration takes place. 

Detailed deseription of use Authorized data entry Data maintenance User doeumentation Data migration Arehiving... 

Data migration must preserve the integrity and secnrity of original data. Processes and methods nsed to load data (manually and antomatically) mnst be defined and validated with snpporting documentation before they are nsed. 

This category defines software written entirely to meet the exclusive requirements of a single nser/company or a small group of users. Because of this, it is likely to be updated frequently. Examples of custom software development include code for data migration, code for reports, and code for interfaces. Software from another category that has been customized should also be managed as Category 5 software. 

Data mapping should consider any electronic record implications such as maintaining audit trails during data migration. Electronic record requirements are discussed in more detail in Chapter 15. 

New versions should be able to process data migrated from the previous version(s). 

Data maintenance is required throughout the data life cycle (see Figure 12.2, based on GERM ). Data may be captured by a manual or automated input. User procedures are required for manual data input and their effectiveness should be audited. Software supporting automated data input such as that used for data acquisition by instrumentation or data migration tools requires validation. Checks should include confirming any necessary calibration has been conducted and if interfaces are working correctly as validated. 

Validate data migration including any support programs used. 

Validate data migration including any programs used to generate output to archive media... 

Generic Data Migration and System Retirement Process.500... 

Step 5 System Decommissioning and Data Migration Plan.502... 

FIGURE 20.7 Overview of the Whole Mass Spectrometry Validation, Data Migration, and System Retirement Project. 

The existing environment was Macintosh with mass spectrometry being downloaded to a server after it had been acquired. Introduction of the Analyst has started a migration to an NT operating environment that will continue after the completion of the data migration oudined here. 

It is vitally important to understand the differences between the two environments before progressing further with any data migration. Covered here are the major differences between the two systems and their impact on the data migration. Essentially, the problem is that we have incompatible... 

These differences will be discussed below. However, the bottom line is that data file conversion is essential for the data migration to succeed. 

Over time, the instrument has been used more widely by chromatographers, and the Analyst software is a response to this as the operation of the application is simpler and uses chromatographic terms more than mass spectrometry ones. This difference in design philosophy is a complicating factor for the data migration as terms have to be mapped between the applications, which we will describe later in this chapter. 

This is simply a summary of the work that was undertaken with a description of any deviations from the plan and a discussion of their impact. The data migration together with any validation tests applied will be described, and management will sign off the report. 

The option for data migration is to assess if it is technically feasible to migrate data. The supplier of the mass spectrometry software systems (Applied Biosystems/MDS Sciex) provides conversion programs to allow a user to migrate electronic records from the Macintosh to the Analyst system. Conversion is necessary as the file formats are completely different between the Macintosh and Windows NT environments. 

A further limitation of the utilities became apparent during the data migration in that the original baselines were not transferred and new basehnes were redrawn with the new system. 

It is important to understand that a data migration project requires a full understanding of the problem. Therefore, this section of this chapter is intended to provide a measure of the evolution of the data migration project, as the understanding of the extent of the issues involved increases. 

Initially, a single test script under the Analyst validation was envisioned. However, as the complexity of the MassChrom software versions was understood, a data migration and system retirement test plan was required to explain the overall strategy with five test scripts. Further information gathering revealed more complexity, and the number of test scripts rose to 10. 

A complicating factor was that each combination of MassChrom software had been validated on its own but comparison of data across all combinations of the software had not been imdertaken as this is not normally considered as part of a normal validation stndy. Therefore, to ensure a comprehensive approach to the data migration, an evalnation of data aeqnired by all MassChrom software versions was required to ensure that no regnlatory qnestions remained with the data migration. This approach increased the number of test scripts to 16. 

As there was no systematic study of results from all MassChrom software eombinations, it was decided to evaluate results from all MassChrom software eombinations vs. Analyst. In addition, all future data acquisition and analysis configurations were also evalnated to give a eomprehensive approach to the data migration and to find out if there were any problems with the proposed approaeh. 

---