DMPs can be life-savers, well probably not life-savers, but quite possibly sanity-savers. Consider the following nightmare, though admittedly hyperbolical.
John is the rising data manager in his office and has just returned from a well deserved vacation this morning. As he passes his manager’s office on the way to get coffee, his manager asks John if he’s ready for the FDA (or substitute applicable regulatory agency) inspection this morning. Now John’s manager is a bit of a prankster, so at first John laughs until he sees his manager is serious. Unbeknownst to John, the inspection was scheduled while he was on vacation and the invite is buried amongst 300 e-mails, all marked urgent. The question is just how panicked should John be?
Well the answer, like so many things, turns out to be a resounding ‘it depends’; however, one good indicator is just how well the DMP is put together. A well planned and executed DMP covers, or at least references, the vast majority of what a regulatory inspector would typically ask a CDM. If they ask questions about EDC and study validation, the DMP can easily reference applicable SOPs, and either point to, or contain, the validation plan and documentation that the plan was executed properly. If the inspectors want to see documentation regarding the UAT of the edit checks the DMP will often contain the edit check specification document and the UAT plan.
While you should never use simple expediency as the sole determining factor of how to assemble a DMP, it is important to note that the well known research adage applies: if it’s not documented, it didn’t happen. Hence, be sure that what you put in the DMP can be documented; few, if any, would want to manually record that a query was sent in the EDC system within a separate database for each and every query sent to a site. Routinely asking yourself “How would I prove this?” can be very helpful when considering what to add to a DMP.
The exact contents of a specific study’s DMP can vary significantly based on the data management needs of that study; however, there are some sections that arguably should be virtually universal in a modern study (Lebedys, et al, 2008).
- Document Approval and Revision History
- Abbreviations, Definitions and Document Scope
- External Documents Referenced (including SOPs)
- Data Sources and Data Flow
- Data Definition and/or Metadata
- Data Transformation
- System Access Privileges
- Privacy and Confidentiality
- Data Collection and Recording
- Quality Control and/or Assurance
- Database Lock, Unlock and Archival
There are several others that are often recommended across multiple sources, but may or may not be appropriate for a given study (Lebedys, et al, 2008; Prokscha, 2012).
- Protocol Summary
- Personnel
- CRFs and/or annotated CRFs
- Data Mapping
- Traceability
- Data Systems Used (with versions)
- Change Control Procedures
- System Interfaces
- System Security
- Back-up and Recovery
- Data Processing
- Issue/Incidence Reporting
While the following topics below could be included if the study warrants it, for example, if your company is responsible for any of the software development (Lebedys, et al, 2008).
- Risk Identification and Management/Mitigation Strategies: As risk-based monitoring becomes more of a norm in the world of clinical trials, the future is pointing to a risked-based approach to many clinical operations including clinical data management. This should only be approached in the DMP if you have organizational buy-in which is usually beyond the scope of the CDM or DMP author.
- Project Management: Of all the topics this one is perhaps the most discretionary. As the size of teams grow, project management becomes more needed, but for smaller teams it can often feel needlessly rigid and unwieldy.
- Software Development Lifecycle: A software development lifecycle is a key process for any company that develops their own software in house. While it is conceivable that a regulatory authority might ask about an SDL process for an external vendor this should be readily available from that vendor.
- Instrumentation, Calibration and Maintenance: If you have any instrumentation that is not maintained and inspected by either internal QA or an external validation process you should describe or reference the procedures utilized.
It is true that under current FDA regulations, and those of many equivalent agencies around the world, a DMP is not required; it is still an undeniably helpful document. The major exception to this rule is the Chinese FDA which does require a DMP and close-out report. While the full DMP is irreplaceable, just going through the exercise of planning and outlining one can illuminate aspects of a study that may slip through the cracks.
Now we pick back up with John. It turns out he wrote an incredible DMP at study start-up; he grabs it from the cabinet and helps keep his company in No Action Indicated (NAI) territory.
Tools and Resources
• GitHub (or other version control tool) – This is crucial if multiple people are working on the document at once. Ideally whatever tool you choose will keep a running history of document versions, easily be able to revert to previous versions and have a merge function.
• SCDM GCDMP – The GCDMP published by the SCDM (referenced below) is perhaps as close to required background knowledge for a modern CDM as anything.
• Finally feel free to browse online. While most sponsors and CROs consider their DMPs and DMP templates to be proprietary, many academic sponsor-investigators or their organizations will publish their DMPs.
References
Lebedys, E., Famatiga-Fay, C., Bhatkar, P., Johnson, D., Viswanathan, G., & Zozus, M. N. (2008, December). Data Management Plan. Retrieved February 25, 2021, from https://scdm.org/wp-content/uploads/2019/12/GCDMP-Data-Management-Plan-2019-Edition.pdf
Prokscha, S. (2012). Practical guide to clinical data management. In Practical guide to clinical data management (3rd ed., pp. 3-8). Boca Raton, FL: CRC Press.