Data migration from CDISC ODM

An ODM 1.3.2 file from another EDC: the design, the mapping, a dry run, the load and the migration report.

The migration moves a study from another EDC by the CDISC ODM 1.3.2 standard: first the design (visits, forms, fields, answer lists, tables), then the patients with every visit and form. Before the load, a dry run shows what would be loaded and every value that fails a check. The load itself goes through the same save path as typing: edit checks, automatic queries and the audit trail. At the end you get a migration report for the Trial Master File.

Step 1. File

Open “Import” in the study menu and press “Load an ODM file” on the “Data migration from CDISC ODM” card. An .xml file up to 30 MB will do. The portal checks it against the official ODM 1.3.2 schema and checks the references inside the file. A file with a DOCTYPE or external entities is refused at once and never parsed, so a file cannot read other data from the server. A refused file is recorded in the audit trail too.

If you have no file at hand, press “Try it on an example”: an invented hypertension registry from an “old EDC” with two visits, an adverse event log, a table of medicines, the old system's audit records and a few values that fail the checks on purpose. You can download the example as well.

Step 1: an ODM file or the example (the screenshots show the Russian interface).

Step 2. Design and mapping

At the top you see how many patients are in the file (new and already in the study), how many forms and events, and the file's SHA-256 fingerprint. Values that do not fit their own definition in the file (a letter instead of a digit, say) do not stop the load: the dry run lists them and they are not loaded.

• eCRF from the file. If the study's eCRF has never been released and there are no patients, the draft can be built from the MetaDataVersion: StudyEventDefs become visits (a repeating event becomes an unscheduled visit, a common one a log), FormDefs and ItemDefs become forms and fields with types, units and ranges, CodeLists become answer lists and repeating groups become tables. Check the draft in the builder and release a version as usual, then come back to the file: it waits for 7 days.
• Events, forms and items are matched by OID first, then by name. For each form you see how many items were found and which ones the study does not have: their values are not loaded and are listed in the report.
• Sites. For each Location in the file choose a site of the study or “Add site”. Patients of sites you have no access to are hidden.
• Personal data are never imported. Items with names and initials are left out: patients are known only by their codes.

Step 2: events and forms found by OID, the initials left out, sites 02 and 07 will be added.

Step 3. Dry run

The “Dry run” writes nothing: it counts what the load would do with the study as it is now. For each form and site you see how many forms would be new, changed, unchanged, rejected or saved as drafts. Below it, every rejected value is listed with the patient, the visit, the OID and the reason. The Excel report holds all the rows.

• A value of the wrong type, a code not in its list or “no data” where it is not allowed is not loaded; the rest of the form is.
• If a form breaks a hard edit check, the whole form is rejected.
• A form that lacks required fields is saved as a draft.

Step 3: the dry run of the example.

Step 4. Load and the migration report

After the dry run tick “I have read the dry run report” and press “Load the data”. Each form is saved with the source “Migration”. The old audit records (AuditRecord) go into the reason for change: who changed the value in the old system, when, where and why. Users of the old system never become portal users; their logins stay only as text in the reason.

The load can be repeated with the same or a corrected file: unchanged forms are not saved again, and values that changed are updated with a reason in the audit trail. This is how you load corrected rows later.

The migration report (Excel and PDF) holds the counts per form and site, every rejected value, the file name and its SHA-256, who loaded it and when. After the load the PDF goes to the Trial Master File inbox by itself as a data transfer record.

Who can and when not

• Members with the import right can load data; a member limited to some sites sees and loads only those.
• Only someone who may change the design can build the eCRF from the file.
• A study under a lock (a freeze or the database lock) refuses the migration.
• The audit trail keeps the file upload, a refused file, the eCRF build, every run, every saved value and every report download.