The$Clinical$Researcher’sGuide$to$Technology$ Penelope$K ...manarbm.com/userfiles/955/files/The-Clinical-Researchers-Guide-to... · MANARBMCopyright2016 ! Page 1 of 17! The$Clinical$Researcher’sGuide$to$Technology$

MANA RBM Copyright 2016 Page 1 of 17

The Clinical Researcher’s Guide to Technology Penelope K. Manasco, M.D.

CEO, MANA RBM [email protected]

919-556-9456 The future of clinical research lies with technology. Technology permeates every part of our lives. It has changed the way we do everything - communicating, shopping, taking pictures, and learning. The clinical research industry has been slow to adopt available technology that allows wide-ranging changes in processes. This paper provides key background information every clinical researcher should know regardless of their role as a Sponsor, a Clinical Research Associate, Medical Monitor, or Pharmaceutical Executive. It will help you better evaluate the software used for trials and the processes for designing, testing, and archiving data from the different software systems. Figure 1 shows the FDA’s model for achieving Quality Clinical Trial Data. The figure was slightly modified to include documents. Documents are a critical component to supporting correct trial conduct. 1

Quality(Clinical(Trial(Data(and(Documents(

Protocol(Design(

Modern,(Risk:Based(Approach(

Enhanced(Human(Subject(ProtecDon(

Variety(of(Monitoring(AcDviDes(

Improved((Efficiency(


Technology should be a key component of each activity identified by the FDA to support the collection of quality data and supporting documentation for the approval of medical products for marketing. Modern Risk-Based Approaches to Trial Oversight and Monitoring can be enhanced by efficiently using technology. For example, using electronic Source (eSource) as a method of data collection through EDC or a separate eSource system, sites enter the data at the time they see the subject. This enables central data review as soon as subjects are enrolled, rapidly identifying and correcting issues and enhancing trial conduct and subject safety. This reduces future protocol deviations, loss of evaluable subjects, and assures protocol adherence. While traditional recommendations have limited the amount of data to be collected to only those fields needed for analysis, with Risk Based Monitoring (RBM), it is useful to collect data that can support protocol compliance and GCP to enable remote trial oversight. Monitoring activities also include assuring adequate documentation of subject case histories and proper conduct of the research protocol. Using electronic Investigator Site Files (eISF) and electronic Source (eSource) assures full documentation is available and credible. Both systems can be managed remotely from any location with Internet access, reducing the frequency and duration of onsite visits while allowing the monitor’s onsite time to be focused on training, recruitment, and other site-specific issues. Enhanced Human Subject Protection can be supported using electronic Informed Consents or enabling the remote review of certified electronic copies of the subject’s informed consent. These reviews can be done immediately to assure rapid, complete informed consent review. Technology improves the entire efficiency and quality of a clinical trial. A well- designed clinical trial incorporates available technology accompanied by the appropriate process changes. This paper identifies and examines the tools Clinical Researchers must master to better use technology and to meet the industry and public health goals of delivering effective medical products to patients. I. Regulations 21 CFR Part 11 The key guiding regulation for software used in Clinical Research for medical products (drugs, biologics, and devices) is 21 CFR Part 11. This regulation guides the use of electronic records and electronic signatures. It was originally


released in 19972 The Agency released General Principles of Software Validation: Final Guidance for Industry and FDA Staff in 20023 and released its Guidance for Industry: Part 11, Electronic Records;; Electronic Signatures – Scope and Application in 20034. It released the Guidance for Industry Computerized Systems Used in Clinical Investigations in May, 20075. In April 1, 2012, the Agency released a revision to the requirements. The most recent version contained additional clarifications for electronic signatures and its link to documents. It also sets forth the criteria required to enable the FDA to consider electronic records the equivalent of paper records. Several important aspects to 21CFR Part 11 should be noted. In addition to electronic signatures, provisions for additional software controls include access control, training, electronic audit trails, and system validations are included. The regulations include software requirements as well as process requirements. This is an important point to remember - No software system can be considered completely 21 CFR Part 11 compliant without understanding the accompanying processes. The regulation allows for using both electronic and digital signatures. Table 1 illustrates the differences between Electronic and Digital signatures - both are acceptable to the FDA, based on the systems used. 21 CFR Part 11 differentiates between “Open Systems” where the content and access to an electronic system are not controlled by the software manufacturer (e.g. Wikipedia) and Closed Systems, where access control is maintained by the software system (e.g. Medidata EDC). Table 1: Difference in Electronic and Digital Signatures Electronic Signature Digital Signature

Definition An electronic signature can be either a typed signature or a picture of a written signature. It is usually associated with a specific software and requires both a login signature and password and then another login and password associated with the signature (i.e. two sets of identifiers—one to get into a system and one associated with the signature). For multiple signatures made during the same session, a single set of identifiers is needed for subsequent signatures.

Usually independent of software and can be used across different (but not all) systems. It includes an encryption or other biometric marker in addition to the standard two identifiers.


Electronic Signature Digital Signature

Acceptability by the FDA

Accepted for Closed Systems (where access is controlled by the persons responsible for the electronic records)

Accepted for all Systems including Open Systems (where access is not controlled by persons who are responsible for the content of the electronic records)

Required Components

• Printed name of the signer • Date and Time the signature was executed

• Meaning of the signature (e.g. review, approval, responsibility, authorship)

• Linked to the document • Under the same controls as required for closed systems.

• Must be in human readable format

• Printed name of the signer • Date and Time the signature was executed

• Meaning of the signature (e.g. review, approval, responsibility, authorship)

• Linked to the document • Under the same controls as required for open systems.

• Must be in human readable format

What this means to Clinical Research Staff

You want to assure the eSignature is linked to the document and you have access to all the information listed above.

You want to assure the digital signature is linked to the document and you have access to all the information listed above for any open system or if the closed system uses digital signatures.

The audit trail is another key component of 21 CFR Part 11. It documents exactly who does what during a trial. This key component differentiates electronic systems for clinical trials from most Electronic Health Records (EHR). A user logs on to the system and every action the user takes that affects the data is recorded, along with the time and date the action occurred. The audit trail must be available in human readable form. The robustness of the audit trail can support your review of how users perform within the electronic system. If the audit trail is searchable, you will be able to easily identify who did each action and how long that action took. In evaluating any electronic system, be sure to review the audit trail and ensure it meets the requirements listed above. Furthermore, when you sign a contract with an electronic system vendor, be sure the audit trail is included in the export. Finally, there is an expectation that all users are approved for use on the systems and they receive adequate training. Therefore documentation of approval of user roles and training should be part of the study documentation.


II. Guidance Documents: Risk Based Monitoring Guidance In August 2011, the FDA released its Guidance for Risk Based Monitoring which was finalized in 20136. This guidance signaled a fundamental change in the way the FDA recommended monitoring clinical trials. Scarce monitoring resources should now focus on reviewing key variables, human subjects protection, and problematic sites or protocol related risks. The EMA also released similar guidance and in 2015, ICH released draft changes to E6, the definition of Good Clinical Practice. The ICH guidance also focused on the need for good validation of software systems used for clinical trials. These changes resulted from a realization that the traditional approach of using 100 % Source Data Verification (SDV) as a method of trial oversight was insufficient. The new guidance allows for different methods, with a common expectation that more oversight be paid to high risk areas such as: Subject safety, key efficacy variables, protocol compliance, Good Clinical Practice, and Investigational Product oversight. The Regulators further discussed their expectation that more of the oversight be handled remotely with fewer onsite visits. They sited the advances in technology as enabling this expanded remote oversight. The Quality model used for the Clinical Monitoring guidance is based on Quality by Design. Pharma and Device Manufacturing have already adopted many of these principles. Figure 3 shows the model provided by the FDA for their expected oversight. The first step is risk assessment, which should ideally be part of protocol design.


Figure 3: ICH Q9 Quality Risk Assessment Model 9

Original FDA recommendations were based on the expectation Sponsors would send Clinical Monitors to the investigative site to review each subject’s data and compare the onsite records to confirm proper conduct of the clinical research protocol. The new guidance replaced that expectation with an approach encompassing a more comprehensive review of data not just at the subject level, but also at the site and country level. The FDA recommended conducting activities that can be done remotely to identify issues with the data, documentation, and study conduct. Time spent at the site should be focused on site training and solving site-specific issues.


Technology approaches are recommended to enable review of data more efficiently using approaches to identify data trends, overall performance, outliers, and protocol violations. The recommendations include recommendations reviewing documents remotely to enable onsite time to be focused on remediation. Figure 4 shows the model provided by the FDA as part of their Guidance Webinars1

Electronic Source Guidance—in November 2012, the FDA released its second Draft Guidance on Electronic Source Documents10. The Guidance states it is to be used together with the 21 CFR Part 11 Guidance and FDA’s Computerized Systems Used in Clinical Investigation. The EMEA (European Medicines Agency) had also previously released a Reflection paper in 2007 that was finalized in 201011. In the FDA Guidance, the following issues were covered:

• Identifying and specifying authorized source data originators • Creating data element identifiers to facilitate examination of the data audit trail by sponsors, FDA, and other authorized parties

• Capturing source data into the eCRF (electronic Case Report Form) using either manual or electronic capture methods

• Investigator responsibilities with respect to reviewing and retaining electronic data”

The goal of capturing source documents electronically was to:

Plan %%

Do%

Check%

Act%

• Condut%the%Study%• Measure/monitor%performance%

• Iden=fy%quality%objec=ves,%metrics,%and%risks%to%develop%quality%Management%Plans%

• Respond%to%Devia=ons%and%measure%outcome%of%response%

Act% Plan%

Do%Check%


• Eliminate unnecessary duplication of data • Reduce the possibility for transcription errors • Encourage entering source data during a subject’s visit • Eliminate transcribing source data before entering the data into an electronic data capture system

• Promote real-time data access for review • Ensure the accuracy and completeness of the data

The electronic Source Guidance clarifies the need to identify the authorized data originator for each data element. These data originators could be an investigator or site staff, automated laboratory reporting systems, or medical devices. The Guidance emphasizes the importance of proper controls for access to systems from the data originator. Data element identifiers are the metadata tags added by the electronic system. It includes the originators of the data element (e.g. Investigator, lab system, Electronic Health Records), the date and time of the entry of the data element, and the subject associated with that element. If a data element is changed, the amended metadata must include the change in value and the originator of the change. The original data must remain in the database and be accessible. If your electronic system has a robust audit trail, this requirement should be easily met. The FDA encourages the use of electronic edit checks and other notifications to the data originator to identify data not in alignment with the protocol or GCP. The eSource Guidance from the FDA also recommends the electronic signature of the electronic Source by the Investigator after he/she has reviewed the subject’s data to meet the requirements to maintain accurate case histories. There should be an audit trail that captures the date and time of the electronic signature showing review and approval of the data. After risk assessment is completed, designing the data collector (eSource or EDC) to any fields necessary to assure proper conduct of the trial (including assessor initials) can enable more comprehensive remote oversight of trial conduct. As with paper copies, the Investigator or a third party should maintain electronic copies of the electronic Source. The Data Management Plan should include a list of which users may review the data (role security matrix) and the details of the electronic system(s) that have been used. It should also include the security employed, the edits or electronic flags employed, and the details of the of all site staff training in the use of the electronic systems.


Software Development and Validation Software development and validation is not part of the core training for Clinical Researchers. It is critical for the Clinical Researcher to understand the process for software development and validation to better understand the process and documentation every software product must undergo. Figure 5 shows an example of the Software Development Life Cycle or SDLC.

While there are many different approaches to software development, certain steps must take place for every product used in clinical research. The components listed in the figure comprise the expected steps.


The Center for Device and Radiologic Health and the Center for Biologics Evaluation and Research issued final Guidance for software validation in January 200212. The Guidance was developed after finding 7.7% of device recalls between 1992 and 1998 were due to software failures. 79% of these defects were introduced when software changes were made after the product had been approved. The Guidance applies to:

• Software used as a component, part, or accessory of a medical device;; • Software that is itself a medical device (e.g., blood establishment software);;

• Software used in the production of a device (e.g., programmable logic controllers in manufacturing equipment);; and

• Software used in implementation of the device manufacturer's quality system (e.g., software that records and maintains the device history record).

It also applies to computer systems used to create or modify electronic records (including electronic signatures) and is also included in the validation requirement. The principles are based on generally recognized software development and validation and can be applied to any software development. The documentation required here is the same documentation you use to review and collect for your software systems. The first step is to develop your requirements for a software system. For instance, if you were planning to use your electronic site file to collect and review paper documents such as Informed consents you would have the following system requirements:

• Electronic signature capability for multiple system users and roles with flexibility in defining the signature wording applied to each signature.

• Robust roles and privileges so you can define which users can see the informed consent with personal identifying information. The monitors should be able to review the Informed Consents, but the Sponsor cannot.

• Robust archiving so the archive prepared for each site does not include the documents with personal identifying information in the Sponsor Archive.

When you evaluate different vendors, ask them to provide an estimate of the cost to build the functionality you require. This approach will help you to efficiently select the correct system for you. It is best to have a system that requires only configuration, not new development. This lowers the risk and cost of using an electronic system. If you use the system “off the shelf” then you can


continue to benefit form the development that the vendor completes as part of their development roadmap. How you plan to use the system will also affect which vendors you select. For instance, if you want to have your electronic system accessible to multiple outside CROs/vendors, you will want to have the system administration robust enough to easily generate many users for each trial. You will also want to be sure that where the system is housed (within the firewalls, in a secure cloud server environment) will enable use by multiple vendors and internal staff. When you purchase software as a service (SAAS) or using an Application Service Provider (ASP) model, there is core development the Vendor has completed. This development is the basic software you buy. If you purchase the software for a trial, you should also have a specifications document that reflects the exact set up of the electronic system for your specific trial. These specifications should include:

a) Exactly how the system will be set up b) Any edit checks that will be included in the system c) How the data or documents will be exported and archived. d) The roles and privileges matrix that will determine who has access to what functionality.

e) Any interfaces with other system (e.g. Interactive Voice Response system, electronic Patient Reported Outcomes)

f) Exports- format, frequency of export or access g) Reports- “canned” or pre-developed reports and custom reports h) Archiving must include the audit trail

The Sponsor or an agent of the Sponsor must first approve study Specific Specifications. Next, the Vendor builds and tests the system. The system must meet all the requirements or specifications you developed with the Vendor. Once the Vendor has completed its internal QC testing, the system will be released to the Sponsor or CRO to complete User Acceptance Testing (UAT). This is part of the validation process which the FDA defines as: “confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled.” During this process, the Sponsor or agent of the Sponsor tests the system to assure it meets the requirements defined for the system. Following completion of the UAT, the Sponsor or agent will approve the system for use in the Study. If you use a CRO or ARO to set up your electronic system, you should review the specifications to assure it meet your needs. The following documentation should be provided to you:

• Specifications Document with Approval by Sponsor or Agent. If changes are made as a result of the UAT, then a new, revised version


Specifications documents should be provided with approval. Specifications should also include specifications for the roles and privileges of the different users (what data they can see, whether they can query the data, etc.)

• UAT Plan and results (provided by CRO, Sponsor, or Agent) should include testing of the roles and privileges set up for the system.

• Approval documentation to show the system passed UAT and is approved to move to production.

The export of data is critical to the successful completion of the trial. This step often has a completely different set of specifications, testing, and approval. If it is separate, then you should expect all of the documents listed:

• Specifications for Export of data, which includes the output file type, frequency of export along with detailed descriptions of the variable names and field attributes

• UAT Test Plan and results • Approval Documents

Documentation is very important because regulators expect to recreate the study using the documentation provided. Validation is the process of testing the system to assure it meets all specifications and requirements. It is a critical component of software development. The Clinical Researcher must also address and implement three other critical components of software development and validation as follows: 1. Training - each user should be trained on the electronic systems. The training may be in two parts - first is training on the basic system, which is provided by the software vendor in many cases, but can also be provided by the CRO or another vendor. This training should follow an outline or script. You should receive a script or user manual for the training as well as documentation that every user identified by the Sponsor has been trained prior to accessing the system.

The second part of training is protocol-specific training. Assuring that the study team can use the technology for the protocol assessments quickly and correctly assures better site acceptance and efficient site performance. Training also plays another key role in software development. When auditing a software vendor, it is important to assure that the staff doing the development has adequate training to complete their roles. For instance, if they are working with a SQL database, there should be documentation that they have been trained in SQL. If the code is in FLASH or any other


programming language, you should ensure that the engineers have been trained in that language.

2. Change Control - of the recalls the FDA issued for devices between 1992 and 1998 software, 79% of the software had gone through changes from the original submission3. Change control is a critical activity. Any time a database changes after a study has started, there should be documentation that the change was designed and tested prior to implementation. The changes in the software should include changes in the version as well as an approval process. If the change results in changes in functionality, the users will need to go through training on the new functionality as well.

3. Managing users and accounts - most clinical trial systems are closed systems, which means that access is controlled. Sponsors should approve documentation of each user, their contact information and role. This will be the basis for developing the training process and confirming that each user has a bona fide reason to use the system. This must be maintained throughout the duration of the study. When study staff leave, their access must be revoked and when new study staff are added, training must be completed and their access granted and documented.

III. How do you get different systems to “talk” with each other? Many electronic systems only perform part of all the activities required for conduct of a clinical trial. This often results in a need for systems to “talk” with each other or undergo some sort of integration. Sponsors should use a team of vendors knowledgeable in integrating clinical research data into electronic systems to help solve this potential problem. Figure 5 shows some components of a data dictionary and how the components affect the different electronic systems. You can see that for each attribute, the length of the field, the type of the data (alpha, numeric, mixed), and any associated rules for the data are defined.


Figure 5: Components of a Data Dictionary

We recommend starting any project with a team meeting among all the different technology vendors. During this meeting, the team should define the Data Dictionary for the study that will be common to all technology systems. The Goals of the Meeting include: 1. Defining the Data Dictionary.

a. Format for subject numbers/ID (exactly how many fields, whether numeric or alphanumeric, whether the number will change after randomization, how the number will be generated, what checks need to be included to assure there is no duplication).

b. Format for Dates and Times - In general it is best to stay with the CDISC SDTM convention, but many systems are not able to manage this. In addition, remember that time zones can also play a role in subsequent analysis, if not addressed at the beginning of the study. Define how to handle partial dates or unknown dates consistently.

c. Define the format for fields to be used across different systems - for instance, should the field be a numeric field and how long should the field be and how many fields after the decimal should be included. This approach should also include the data table structure and any standard dictionaries to be used for naming conventions, use of long labels or short labels, etc.

2. Define timelines and dependencies a. If one system needs input from a second system, what will happen if the system is offline?

User Data

IVR Data

eSource Fields


b. Many different systems will take longer to develop and testing must include the interactions between systems.

3. Define deliverables a. Requirements Documents b. User Acceptance Test (UAT) Plan including how different systems will be tested as well as the integration

c. Export Requirements d. Approval Documents (for requirements, UAT Plan, Export requirements and testing, and UAT)

IV. Do Not Forget Process Understanding what systems should do and what documentation you must maintain represent key components of maximizing the value of any electronic system. Developing processes to use the complete capabilities of your electronic systems ensures you receive the maximum benefit from electronic systems. Simply adding a technology solution without modifying the work processes will often lead to higher costs and more inefficiency. An example of this approach involves the use of electronic Trial Master Files and electronic Investigator Site Files. In the traditional paper-based Clinical Trial process, the regulatory documents for each site are collected by the clinical monitor and reviewed and filed by a separate document management group. With the capabilities of electronic Site Files, the documents can be collected and reviewed remotely, limiting the cost of using an onsite-monitoring trip to collect regulatory documents. It is estimated that 25% of monitor’s time is spent on document management for the TMF. By using a different process that uses lower cost remote staff members, the document collection and oversight can be accomplished faster and at a lower cost. Process is also important when implementing paperless clinical trials. It is critical to avoid duplication of data collection since data may be collected from several systems. For instance, in a recent eSource trial, the date and time of symptom onset was collected from the subject in the IVR system and transferred into the eSource using web services. It was a critical training step to teach the coordinators not to collect that data since it was already collected elsewhere. Additionally, the coordinators needed to be trained not to take any paper when completing the subject visit. Minimizing the collection of duplicate data frees resources to focus on data review and trend analysis;; eliminating the need for reconciliation. When data and documents are available remotely, the timelines for review and


who reviews data and documents are key processes to be addressed. If there are no source documents to be collected at the site, the data review can take place immediately. It is also possible to do a combined clinical and data review and provide results to the sites almost immediately. This means the data review staff may need to have a different skill set and different training. The entire data process flow should be reevaluated and matched to the functionality of the electronic systems employed to gain the true efficiencies and quality benefits. The timing of onsite monitoring visits should also be included in the process redesign. If the data review is conducted remotely, feedback and retraining can occur much faster, eliminating many database errors. The monitor’s role also changes from simple SDV and document review to more site support and training. The monitor needs to be able to use the technology and use the rapid data review process to develop methods to train the site and evaluate the results of the training. Summary The role of technology in clinical research requires the Clinical Researcher to become well versed in the processes for developing, validating and utilizing software. Understanding the documentation, regulations, and software functionality helps to guide the interactions, evaluation, and employment of different software vendors. References 1. Cochran CJ, O’Connell, AM, Shapley, S. FDA Guidance Webinar: Oversight of Clinical Investigations—A Risk-Based Approach to Monitoring. http://www.fda.gov/Training/GuidanceWebinars/ucm277044.htm 2. Title 21—Food and Drugs Chapter 1 Food and Drug Administration Department of Health and Human Services Subchapter A- General Part 11 Electronic Records;; Electronic Signatures 1997 http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?CFRPart=11 3. Device Software: General Principles of Software Validation;; Final Guidance for Industry and FDA Staff. U.S. Department of Health and Human Services, Food and Drug Administration http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm085281.htm 4. Guidance for Industry: Part 11, Electronic Records;; Electronic Signatures—Scope and Application Final Guidance August 2003 U.S. Department of Health and Human Services, Food and Drug Administration


http://www.fda.gov/downloads/Drugs/GuidanceComplianceRegulatoryInformation/Guidances/UCM072322.pdf 5. Guidance for Industry: Computerized Systems Used in Clinical Investigations May 2007 U.S. Department of Health and Human Services, Food and Drug Administration http://www.fda.gov/downloads/Drugs/GuidanceComplianceRegulatoryInformation/Guidances/UCM070266.pdf

6. Oversight of Clinical Investigations: A Risk-‐‑Based Approach to Monitoring. U.S. Department of HHS, FDA, August 2013 OMB Control No. 0910-‐‑0733. 7.Reflection paper on risk based quality management in clinical trials. European Medicines Agency. 18 November 2013 EMA/269011/2013. 8. ICH, “Integrated addendum to ICH E6(R1): Guideline for Good Clinical Practice E6(R2)”. 11-June 2015. 9. ICH Q9 Quality Risk Management (http://www.ich.org/LOB/media/MEDIA1957.pdf 10. Guidance for Industry: Electronic Source Data in Clinical Investigations. Draft Guidance U.S. Department of Health and Human Services, Food and Drug Administration November, 2012 http://www.fda.gov/downloads/Drugs/GuidanceComplianceRegulatoryInformation/Guidances/UCM328691.pdf 11. Reflection Paper on Expectations for Electronic Source Documents Used in Clinical Trials European Medicines Agency GCP Inspectors Working Group 9 June 2010 Doc. Ref. EMA/INS/GCP/454280/2010. 12. Device Software: General Principles of Software Validation;; Final Guidance for Industry and FDA Staff. U.S. Department of Health and Human Services, Food and Drug Administration http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm085281.htm