Paragon's Michael Agard is an expert in the design implementation and optimization of eTMF and RIM applications. He shares his perspectives and expertise on best practices in managing eTMF content.
Problem: You can't be inspection ready without managing eTMF content dates. eTMF systems offer myriad date solutions.
Objective: Practical solutions for capturing meaningful and effective eTMF content dates. Identify the most meaningful dates and date calculations, without burdening the end user for entering or calculating the dates manually.
Approach: Just because you can get the dates doesn't mean you should or will get the dates. Carefully assess date field requirements; rigorously exclude those not required for GCP inspection surety.
- System populated date fields are your friend. Use system generated dates for most content dating to avoid end user entry.
- For the vast majority of content, only one user entered date fields is needed.
- For content types that require user entry, use a date field in combination with a pick list (e.g., IRB approval expiration, site visit date).
- The audit trail data (user ID and date) for the verification of a scanned document to the original document is something that has not been handled well by the eTMF vendors. Here a custom workflow could be created. However, many companies rely on business process and training or application of a watermark for documentation purposes. This is certainly an area to explore in order to support paper destruction and reduce the duplicate effort for paper and electronic TMF management.
- For managing document migrations from one system to another or from CRO to Sponsor, there are specific dates that must be included in the exchange.
System Generated Dates: These are usually configured in the eTMF system. These dates are easily generated behind the scene by the system and do not place a burden on the end-user to enter the date. In some cases, these dates may be generated by the completion of a workflow, change in status or completion of a task.
- Creation Date
- Scan / Upload Date
- Last Modified Date
- Approve / Sign / Final Date
- Workflow Start / End Date
- Version Date
- Expiration Date
- QC / Review / Confirmation Dates
If your eTMF doesn't offer the capabilities to autogenerate these dates, perhaps it's time for a new eTMF.
Irrespective of system capabilities, caution again to boil the ocean in the numbers of date fields planned for end-user entry.
Just because you can, doesn't mean success.
Document Specific Dates: These dates require human intervention to assess the document content and then apply the appropriate date. For these types of dates, it is helpful to configure the eTMF system with a picklist of the various types of dates for the end-user to select from. Having these dates as required fields for specific document types ensures the date will be applied. However, in some cases the date may not be known, and therefore it is helpful to assign a standard non-logical date such as 1/1/9999. In addition, it helps to have definitions of what these dates mean to ensure standard reporting and calculations.
Document Dates Picklists: The goal here is to have a short list of date types that are easily discernable for the end user during document classification. Remember that the artifact or content type provides context for the date, so the picklist values do not need to be explicit, unless they are needed for reporting purposes.
- Site Visit Date – Usually specified as the first or last date of a monitoring visit. This date is helpful to associate documents related to the monitoring visit report such as confirmation and follow-up letters.
- Date of Approval – This is typically the date the last signature or approval is obtained on a document. The goal here is to move towards a paperless TMF and using electronic workflows to provide the Approval Date. However, this picklist value can serve multiple purposes, especially for documents that are processed outside an eTMF or portal, such as IRB, Regulatory, and PI Protocol approvals.
- Certification Date – This date could be applied to a translation certification, or the date someone is certified to perform a task. In some cases, there could also be an expiration date associated with the certification
- Training Date – Date training is completed.
- Meeting Date – Start or end date that the meeting was held.
- Other – The use of an “Other” date designation allows the date field to be mandatory, but allows users to make a choice from the picklist when the existing values do not apply. The documents with the “Other” designation can be reviewed periodically to determine if the picklist values need to be updated.
Date Calculations for TMF Metrics: Most eTMF systems can be configured to calculate dates and cycle times. Again, these dates may be related to start and end of a workflow, or the dates between status changes. These metrics are often useful to identify bottlenecks in a process, limitations of resources, and quality of performance of an individual, site, vendor, agency or committee.
It is often not the quantity of metrics used, but the quality of the metrics and the associated oversight and accountability to improve under-performing activities, cycle times and project timelines.
- Number of days from start of document approval to approval.
- Number of days from sending a document to a site to the return from site date. These dates may be difficult to obtain and calculate without a portal or eTMF with extended access for site personnel.
- Number of days from document upload or creation to QC completion.
- Number of days from Regulatory or IRB/IEC submission to approval.
Legacy and Migrated Files: Legacy or migrated files represent a special case for document dates. These documents typically have some initial system dates that need to be carried forward into the eTMF system. These files could be from a legacy eTMF system, or could be transferred from a CRO to Sponsor, or from Sponsor to Sponsor. It is important to map out the date fields from one system to the other.
Often, the migration of legacy audit trails dates can present a problem due to the complexity of obtaining the data, or due to the volume of data available.
- Legacy Creation Date
- Legacy Approval Date
- Version Date
- Migration Date to eTMF
- Key audit trail dates
Date Formatting: Some eTMF system allows configuration of a standard date for all documents. In general, the format of dd-mmm-yyyy avoids ambiguity. The format of yyyy-mm-dd is most useful for sorting dates in chronological order. Some eTMF systems have the ability to record a universal date and time stamp in a standard format, but then display the date base on a user’s profile or locale.
Utilizing the TMF Reference Model
The configuration of date fields in an eTMF should be done using the TMF Reference Model list of artifacts and identifying which ones require date fields. The picklist used for the date fields can then be completed with a list of appropriate values.
- Ensure that there is end user feedback to ensure the ease of obtaining the date from the TMF document as well as the intuitiveness of the picklist values.
- Maximize the benefit of system generated dates in your eTMF to minimize the burden for end users when they classify a document.
- Allow the system to calculate dates and generate metrics for dashboards that show performance.
- Carefully plan any migration and map date fields between system to ensure all of the correct dates are captured and migrated as expected.
- Evaluate the tracking and reporting needs that can be fulfilled by the date fields and picklists.