Moving from YouEDC 0.2

How studies and their data move from YouEDC 0.2, and the three checks.

Studies from YouEDC 0.2 move into YouEDC Capture whole: with the team, the eCRF, the patients, the data, the queries and the audit trail. The server administrator does the move with one command. Users have nothing to do: they sign in at youedc.com with the same email and password and find their studies in place.

What moves

• Accounts move with the same email and password. When an account with that email is already in the portal, it stays as it is, with its portal password. Accounts switched off in 0.2 stay switched off.
• Studies move with their sites, team, roles and site restrictions. Invitations that are not accepted yet move too.
• The eCRF: visits, forms, fields with their ranges and show-if conditions, edit-check rules.
• Patients move with their statuses and personal ePRO links. Links handed to patients in 0.2 keep working.
• Data: every form with its status (draft, complete, SDV), the values and the “no data” marks.
• Queries move with their conversation and status, and automatic queries stay tied to their rules.
• The import history and the export history are kept.
• The audit trail moves whole, with the original time and IP address of every record. Each study’s audit trail gets one more, last record “Import · YouEDC 0.2” saying what was moved and how much.

The three checks

1. The 0.2 audit trail before the move. First the hash chain of the 0.2 audit trail is checked on the database copy. If the chain is broken, the move does not start.
2. Row counts. Every 0.2 table must have as many rows after the move: accounts, studies, sites, patients, forms, values, queries, audit records.
3. Cell by cell. Every study is exported the way 0.2 would export it, and with the portal’s export. This is done twice, with answer codes and with answer texts. The files are compared cell by cell.

The moved audit records are also compared with the 0.2 records, and the portal’s audit chains are verified. The check command fails if it finds even one difference. It shows each difference by its address “study / sheet / row / column”, without the values. So its output is safe to forward: it holds no patient data.

The move and the check of a test copy of the 0.2 database: everything matches.

Example: a test copy of 0.2

The screenshot above shows the move of a test 0.2 database with invented people. It holds two studies: the heart failure registry CARD-01 (2 sites, 4 patients, 11 entered forms, 5 queries) and the quality-of-life survey EPRO-2, whose database was already locked. The output reads as follows:

• YouEDC 0.2 audit chain: 99 records, OK: the 0.2 audit trail is intact, with 99 records.
• Accounts: 6 added, 0 already here: 6 accounts moved, with no matches by email.
• Study 1 of 2 (CARD-01): new study; sites 2, …: what moved for each study.
• Moved: studies 2, patients 5, …: the total.
• In the check every table shows match, and so do the exports of CARD-01 (7 sheets, 888 cells) and EPRO-2. The last line is RESULT: everything matches.

After the move, CARD-01 keeps its export history from 0.2, marked “YouEDC 0.2”, and its audit trail holds the 0.2 records with their original times.

The export history of CARD-01: exports made back in 0.2.

The audit trail of CARD-01: the move record at the top, the 0.2 records with their original times below.

Running again, and codes already taken

• Running the move again duplicates nothing: what has already moved is skipped. If something was changed in 0.2 after the move, the check shows a difference.
• If a 0.2 study code is already used by another portal project, the move stops before changing anything and names those codes. Rename the portal project, or run the move with --rename-conflicts; the study then gets a code ending in -2 (for example CARD-01-2).
• A trial run with --dry-run does the same work and prints the numbers, then undoes everything.

Commands for the Portal Owner

The commands run on the portal server, on a copy of the 0.2 database (the SQLite file from a 0.2 backup):

• flask --app wsgi import-v02 --dry-run /tmp/v02.db makes a trial run that saves nothing;
• flask --app wsgi import-v02 /tmp/v02.db moves the data;
• flask --app wsgi import-v02 --verify /tmp/v02.db or flask --app wsgi verify-v02 /tmp/v02.db runs the check and changes nothing.

Everything is first rehearsed in a temporary copy of the portal database on the server itself. The real move is made only after a clean rehearsal. After the move, 0.2 stays at old.youedc.com read-only, as a safety net, and data entry goes on in YouEDC Capture.