DM documents: the DVP and the DMP

How the portal writes the data validation plan and the data management plan, versions, signatures, TMF.

The data validation plan (DVP) lists every check of the study data: what is checked, which message the site sees and how to test it. It is usually written by hand in Word and Excel and soon drifts away from the database. In YouEDC the portal writes the DVP from the eCRF builder itself, so the plan always describes what really runs. Open DM documents in the study menu of YouEDC Capture.

The way of a DVP: the draft is built from the eCRF builder, issued for signature, signed by the author, approved by another person, and the PDF goes to the TMF. When the study changes, the portal warns and offers a new version.

What the portal writes itself

• Required fields (code FORM_FIELD_REQ): the form cannot be completed while the field is empty and not marked “no data”.
• Allowed range (_RNG): a hard check, the value is not saved. Expected range (_EXP): the value is saved and a query opens.
• If - then rules from the builder: each has a permanent code such as VS_R001. The code of a deleted rule is never given again, so references in older DVP versions and reports stay right. The code is shown in the form's rule list.
• Show-if conditions (_SHOW): the field is hidden and cleared while the condition is false.
• For every check the portal proposes a UAT test: a value that triggers the check and a value that passes. For example, “301 → refused; 300 → saved”. The tests go to Excel as separate columns, ready for the tester.
• A summary by form, critical data and a section of changes against the last approved version: what was added, changed and removed.

Colours in the document show where the text comes from: green from the portal's data, amber standard text, red written by the team. The team adds the purpose (if the standard one does not fit), notes and manual checks: cross-form checks, listings, medical review. They get codes MAN_001, MAN_002…

The live draft of study TST-01. On the left the document as it will be in the PDF, on the right issuing for signature, versions and the fields for the team's texts.

Versions and signatures

1. A project administrator or data manager clicks “Issue version 0.1”. The draft is frozen together with the checksum of the eCRF structure.
2. The author signs first by entering their password again. The portal records the name, role, date and time, the meaning of the signature and the hash of the version.
3. Another person (not the author) reviews or approves. On approval the version becomes 1.0, the PDF/A, Word and Excel files are kept exactly as signed, and the PDF goes to the inbox of the trial master file (TMF, data management zone).
4. The sponsor can sign with the “Sponsor / viewer” role.

If the study changed after the version was issued (say, the blood pressure range was edited), that version can no longer be approved: the portal shows what changed and offers to issue a new one. Later versions are numbered 1.1, 1.2…, and 2.0 after approval. Signatures cannot be changed or deleted, not even directly in the database; they can only be withdrawn with a reason. Every action goes to the audit trail.

Files

• PDF/A for the archive and the TMF: fonts embedded, the source data attached inside.
• Word when the sponsor wants its own template: the text can be moved over.
• Excel for testing: the checks with their tests, manual checks, summary, changes.

Data management plan (DMP)

The DMP describes how the study's data are collected, checked, coded, reconciled, locked and archived. Open Data management plan in the study menu (or the card on DM documents) and click “Start the DMP”, choosing the language of the document: Russian or English. The portal fills most of the plan from what it already knows about the study:

• the study profile and design, the roles of the team with the number of people, the sites;
• the eCRF versions with their release history, the counts of visits, forms, fields and checks, and a reference to the DVP;
• query management: who raises, answers and closes queries, and the deadlines from the data entry deadline settings;
• the SDV plan, the data manager's approval and the investigator's electronic signature;
• medical coding: only the dictionaries and their versions, never their content;
• reconciliations of serious adverse events, laboratory data and vendors; ePRO and consent; randomisation and blinding (without the list, its seed or parameters); imports and API keys (without the keys);
• data review and audit trail review, the database lock with a readiness checklist, the archive and data protection.

What the portal cannot know (agreements with vendors, the review plan, the lock arrangements, retention, the SOPs) the team writes on the screen, right where the text stands in the document. Each such text is marked as written by the team and kept with every version.

The live draft of the demo study: the document as it will be in Word on the left; on the right a new version is issued with its reason, below are the issued versions with the eCRF version each one describes.

1. A project administrator or data manager clicks “Issue version” and writes the reason, for example “eCRF amendment 1”. The plan is frozen with its SHA-256 and the number of the eCRF version it describes; the Word file is kept exactly as issued. Versions are numbered 1.0, 2.0…; the previous one becomes “superseded”.
2. The document lists its version history with the reasons, and what changed since the previous version.
3. When the eCRF gets a new version, the menu item and the screen show “The eCRF changed since DMP version 1.0”: time to issue a new one.
4. The Word file has a signature table to be signed on paper. Until signed, every page says it was generated by the portal and is a draft.

Monitors can read the issued versions and download their files; site roles do not see the plan. Starting the plan, every edit of a team text and every issued version are written to the audit trail with the reason. The data protection section names the requirements of Federal Law No. 152-FZ on a Russian installation; it describes the measures of the portal and does not claim compliance or certification.

Sources

• SCDM, Good Clinical Data Management Practices: the chapters on data validation and the data management plan.
• 21 CFR Part 11: requirements for electronic signatures (name, date, meaning, link to the record).

Also the portal writes the investigator guide the same way. In this prototype an electronic signature equals a handwritten one only where an agreement on electronic signatures says so.