Handling of electronic data in Clinical Trials part II - Practical Considerations and Implementation Anders Åkesson, Director Clinical Data Management Michael Seest, Associate Director, Development Compliance 23 May 2013
Two documents will be dealt with
Implementation of new requirements How do you perform the surveillance? Are allocated people assigned? Do you have a process in place?
EMA Reflection Paper Based upon the requirements in the CDISC publication (dated 20 November 2006) Provide a good basis for the acceptability of source data Internationally applicable principles Scope of Reflection paper is electronic systems, including ecrfs, patient data capture devices, blood pressure recording instruments and electronic health records Same quality when using an electronic system instead of a paper system (Golden Standard) (accurate, legible, contemporaneous, original, attributable, complete, consistent, enduring, available when needed).
1. Statement (Creation, modification and transfer of data) A detailed diagram and description of the transmission of electronic data should be provided in the protocol (page 9) Challenges and considerations: Often not decided in detail at the time of protocol finalisation Many data sources and data streams (much more than ecrf) Scope? In reality becomes quite complex and burdening / de-focusing in the protocol and considered as not relevant by protocol writers. Practical implementation: Described in high-level in the protocol and referencing further data management documentation. However, this documentation is not available to sites and investigators or part of submission. [Example: Real case flowchart]
2. Statement (Control) To this end all data generated in a clinical trial relevant to patient care must be made available to the investigator at all times during and after the trial and all data held by the sponsor that has been generated in a clinical trial should be verifiable to a copy not held (or that has been held) by the sponsor (page 10) Challenges and considerations: Availability and sustainability of electronic records from sites. (Internet availability, user credentials, file formats, hardware etc) Consider all sources. Even if all also data not generated by the investigator. Practical solution: ecrf, epro etc are hosted by 3rd party and not controlled by Ferring. Vendors are audited for technical platform requirements (security, availability, backup/restore etc) After the trials, CDs are distributed with all data in pdf-format (including meta data for the data elements, audit trail etc)
3. Statement (Copying) It is a fundamental requirement that a source document and data can be copied and that there is a practical method of copying that is complete and accurate, including relevant metadata (page 11) Challenges and considerations: How is a copy of a dynamic screen at a certain time and on a certain PC defined? Practical solution: Save/print and post-trial generation of pdf-files in the ecrf screen layout and including metadata [Example: CRF pdf]
FDA Guidance for Industry (draft) Intended to assist in ensuring the reliability, quality, integrity, and traceability of electronic source data Covers source data from clinical investigations used to fill the predefined filedas in an ecrf To be used together with the FDA guidance for industry on Computerized Systems Used in Clinical Investigations and the FDA regulations on Elctronic Records and Electronic Signatures (21 CRF part 11)
3. Statement (Copying)
1. Statement (Electronic Source Data) For each protocol, a list of authorized data originators (i.e., persons, systems, devices, and instruments) should be co-developed and maintained by the sponsor and the investigator for each site. The list should include unique identifiers (e.g., user name or in the case of study subjects, a unique subject identification number) and the period of time for which data originator authorization was given (page 4) Challenges and considerations: The step before the ecrf/epro is very site specific and often changing. Detail level? BP machines, analogues, stetoscope? Practical solution: Currently do not automatically transmit from instruments or devices. For ecrf and epro data is always entered by a user. ecrf/epro: Users are considered as originators/authors. Full history of users are kept in the system and part of TMF. Extention of location of source data document needed?
2. Statement (Electronic Source Data). the ecrf system should include a functionality that enables the reviewer to reveal or access the data element identifiers related to each data element (page 5) Challenges and consideration: Considerations for granting an auditor access to the ecrf without training? Procedure for this? Increasing number of systems used (ecrf, epro, elab, Others) Practical solution: Grant auditor access to ecrf or generate pdfs/prints of the CRF, including metadata. [ecrf: http://demo11.targetecrf.com]
2. Statement (Electronic Source Data)
3. Statement (Description and use of electronic Case Report Form) A description of the security measures employed to protect the data and a description of the flow of electronic data should be prepared (page 8) Challenges and consideration: Security measures are very vague/wide and multidimensional. Technical/manual system/pc/process/physical/behaviour etc? Similar to EMEA requirements on detailed flowchart. Practical solution: Standard technical security (secure connection, password rules and change, timeouts) High level description in protocol. Details in data management and system documentation.
Conclusion In general good and practical guidance Disagree on paper as golden standard to achieve accurate, legible, contemporaneous, original, attributable, complete, consistent, enduring, available when needed, but agree on the objective. Challenge with timing and complexity for describing details in protocol. Scope for expected descriptions is unclear
Thank you! Questions?