Did You Know?

Did You Know? »

SAS comments are represented in two ways:

**************************************************;
*Name runlst.sas                                 *;
* Version 1.0                                    *;
* Date  2011                                     *;
* Purpose:  CDM Listings                         *;
**************************************************;

OR this way /* This is my SAS Program */

You can comment out text in the Enhanced Editor in SAS by:

  • Position the cursor in, the line of code you wish to comment out, then press Ctrl + /.
  • If the text is already commented out (with /* and */), you can remove the commenting by highlighting, or positioning the cursor in the text and pressing Ctrl + Shift + /.
Advertisements

Did You Know?

Did You Know? »

The most common errors a SAS programmer makes are:

  • Omiting the semicolon (;).

e.g. proc print data=demog

Error Log message=syntax error, expecting one of the following…

  • Misspelling a word

e.g. data demog; set demog;… proc print data=demo;

Error Log message=File work.demo.data does not exist

  • Omitting the RUN statement (run;)

e.g. proc print data=demo;

Error Log message=no output appears in the output window until the next proc step is submitted.

And my favorite error..

  • Omitting required quotation marks (”)

e.g. title ‘EDC Status Report ;

Error Log message=the TITLE statement is ambiguous due to invalid options or unquoted text.

Remember, practice makes perfect!

Making Public Folders Hidden to Users in Cognos

As a BI Administrator, you might want to hide certain public folders to some users. You can do this by:

  1. In Public Folders > click the Create a Folder icon and create a folder called “eClinical Documents”.
  2. In Public Folders > click the Create a Folder icon and create a folder called “eClinical”.
  3. Within the “eClinical Documents” folder created in step 1, create a Page called “eClinical Portal”:
  • One Column 
  • Add Cognos Content – Cognos Navigator
  • Add Page as a “Portal tab”. 

4.  In “Directory”> Cognos namespace, edit the “Default User Profile”:

    • In the Default User profile, select Portal Tabs > delete Public Folders
    • In Portal Tabs > select Add Portal tab Page and add the “Your Company Portal” page created in step 3.
    • Modify the sequence so that “Your Company Portal” appears first in the list. 

5.  Copy this profile to existing Users (if necessary).

6.  Within the “eClinical” folder created in step 2, select Create Divisional/BU/Departmental folders as necessary.

7.  Add the necessary security (Execute & Traverse) to the folders.

Note: All Reports written against Packages need to be saved into the relevant folders created previously.

8.  Click on the new Portal Tab “eClinical Portal” and select “Edit” to change the Cognos Navigator Content:

    • Under the “Folder” option, select the “eClinical” folder created in step 2.
    • Choose to “Open Links” in the current window.
    • In the “Features to expose in the Navigator views” option, ensure that the only boxes selected are the “Additional Information – Normal Mode” and “Maximised Mode”.
    • Set the number of Columns as appropriate. 

Note: Individual users are still allowed, once logged in, to remove from their view the Portal Tab(s) that were created – and they can easily put them back using the Tab Menu.

it jobs, job employment, it recruitment, agencies

Why use JReview for your Clinical Trials?

Issues with existing database query tools:
– Limited resources for current database query tools (Crystal Report, SQLServer, etc.)
– Custom reports in SQL Servers required validation
– Reports are not globally accessible.

Why chose Integrated Review?

  • Offers flexibility to the users when viewing the data
  • Users can create their own reports without validation
  • Provides a way for Clinical Data Managers to have real-time access to query and browse clinical patient data in our databases
  • IReview/JReview can then reference the “nonnative” database object using the Foreign Panel and/or ImportSQL capabilities. The result is that the user can remain working in one environment and reference the data that is located in other environments.
  • Easy to setup – no programming, no data extraction or data manipulation required.
  • Generate PDFs directly – for all patients selected

“I-Review would be used solely for cleaning data – providing highest data integrity prior to stats analysis.”

Why use a Patient Profile

  • When you want to review data from multiple Tables for a single subject Describe the factors or characteristics that are deemed critical to the success of a project, such that, in their absence the project will fail.
  • Very powerful when used with a Cross Tab report to provide the detail needed to investigate a finding.
  • Special case review such as SAEs or event adjudication.
  • Provides data to support the narrative writing team.

Advantages

  • Easy to build
  • Excel exportable file
  • Multiple subjects in a single report

Limitations

  • Poor readability
  • Output limited to 13 columns of data per row
  • Can’t edit column headers
  • Page header data is limited to 3 items
  • There is no option to use free text in the header or footer

Formatted Style
Advantages

  • High readability PDF style output which also prevents the manipulation of data
  • Free text entry for page header and footer can be used to add key notations to the report
  • Column header text can be edited to enable use of intuitive labels instead of database codes
  • Scheduling feature allows for running batches of patients and exporting outputs as a group
  • Bookmarks in output allow for quick navigation to data
  • Limitations
  • Creation of profile can be slow in the tool use scheduler
  • Can be very time consuming to develop (use a global template)

Object Storage

  • Private (local accessible by the user only) vs Public (accessible by all users)
  • Usergroup (i.e. CDS, CDM, Clinical, biostat, etc)

Object Level

  • Study (at least one view (object) at the study level)
  • Project (a mixture of project and global level and available across the entire project)
  • StudyGroup
  • Global

Keys to Success

  • Think about your audience – Clinical or Data Managers
  • The goal is to provide a report which is easy to read
  • Develop a “template” using standard modules and data items
  • Establish standard formats all parts of the report
  • Font size
  • Text alignment
  • Page margins
  • Use the same formatting for protocol specific elements


Anayansi Gamboa has an extensive background in clinical data management as well as experience with different EDC systems including Oracle InForm, InForm Architect, Central Designer, CIS, Clintrial, Medidata Rave, Central Coding, OpenClinica Open Source and Oracle Clinical.

Oracle Clinical – How to Use Study Design

Study Design in OC is the process of setting up the protocol for the study. This includes:

  •  creating a record for the study
  • creating patient positions or placeholders
  • creating events or study visits
  • assigning sites or locations where data is collected
  • assigning patient positions to the site

Remember that the required study planning objects, sites and investigators must be created prior to the Design Process being completed.

It is a good idea to review all protocol and study related documentation prior to creating the study to make sure you have all of the necessary information but you can always change the Design elements at any time except for the study name.

Once the Study Design is completed, you can move to the next module: The Study Definition (creating CRFs) and develop Procedures (Edit Checks, derivations).

Tips:

  •  Records for the new studies are created in the Easy Design module (Design, Studies, Easy Design)
  • Verify that the required Planning Objects exist for the study
  • In the Easy Design form create the study. Enter the study name or number, version and study description/title. Some parameters are optional. Once you click save, the system will prompt you to choose whether the study requires Pass 2 Data Entry.
  • Most Study Design parameters may be changed except fr the Study Name

Study Design Key Terms:

  • Program: Code (name) for the compound being investigated
  • Protocol: Document describing the plan of action for a study
  • Project: Code (name) for the indication under investigation
  • Study: The name for the Clinical Study
  • Organizational Unit: Code (name) for the unit responsible for the study
  • Event: Clinical Planned Event or Visits
  • Region: Code (name) of the location where the study is managed
  • Patient Positions: Identifier for a participant in a study
  • Site: A location where all or part of the study is conducted
  • Investigator: Primary researcher/clinician for the study at a site

Study Design – Events

• Study timeline is used to identify when data is collected or for tracking purposes (missing or overdue DCMs)

• Consists of one or more intervals and one or more events (visits)

• Timeline consists of intervals that are subdivided into events. By default each study is pre-populated with two defaults intervals that can be used in creating events.

• To create intervals, select the study in the Easy Design module and click on Intervals. Intervals are defined by a Phase Name, Short Name, Phase Type, Blind type (single, double, etc) and a minimum and maximum duration. The duration is used to calculate when the interval is expected to take place within the study.

• To create events, select the study in the Easy Design module and click on Events. Create all the events (visits) in which data will be collected during the course of the study. Events are defined by Event Name, Interval, Visit Number (the order o f the event is expected to occur) and minimum and maximum Offsets from the Interval Start.

• Time calculations (event offsets and interval durations) are useful only for descriptive purposes and for determining if expected CRFs are Missing or Overdue.

If this functionality is not required then this information is not useful in the execution of the study.

Study Design – Patient Positions

• Patient Positions are the placeholders for the actual partaker in the study. Each patient for whom data will be collected must have a unique patient position within that study.

• Can be crated in blocks or one-by-one.

• Patients can be of several types: Screening, Normal or Replacement.

For general patients, use NORMAL.

Replacements are used in Randomization.

• To create patient positions, select the study in the Easy Design module; click on Create PP. Create the required patient position for the study by entering starting and ending numbers.

• Duplicates numbers are not allowed within a study.

Study Design – Sites and Investigators

• Sites are the locations where the data is collected and investigators represent the medical researcher at the site responsible for the patients. It can be used in multiple studies.

• Each study requires a minimum of one site assigned to it with an investigator assigned to that site.

• Create Sites in the Sites module. A site is defined by a Code, Name, Phone Number, Address, City, State, Country, and Postal Code. Site code must be unique.

Design ->Investigators and Sites -> Sites

Create Investigators in the Investigators module. An Investigator is defined by a Investigator Code, First Name, Last Name, and Phone Number. Other information is optional. Investigator code must be unique.

Design -> Investigators and Sites ->Investigators

• Assign an Investigator to each site. There can only be one active Investigator assigned to a site at any time. If a second Investigator is assigned to the same Site, the system automatically enters a Termination Date for the current Investigator.

• Assign Patient Positions to the Study Sites. Patients may be optionally enrolled in the study. Enrolling patients can be performed in the Enrollment module.

Tip: The system only requires the enrollment date to consider a patient “Enrolled”, however, the lab range system will not work without the entry of the patient’s birth date and sex.


Anayansi Gamboa has an extensive background in clinical data management as well as experience with different EDC systems including Oracle InForm, InForm Architect, Central Designer, CIS, Clintrial, Medidata Rave, Central Coding, OpenClinica Open Source and Oracle Clinical.

Disclaimer: The legal entity on this blog is registered as Doing Business As (DBA) – Trade Name – Fictitious Name – Assumed Name as “GAMBOA”.

A QC Plan for A Quality Clinical Database

Before a clinical database can be locked, data management run a set of qualify control checklists to ensure that quality is built into the clinical database.

This process is also known as ″estimated error rate″ which is a calculation of an error occurred during the course of the clinical trial, from the data management point of view.

The formula is:

Percentage error rate = # of errors detected/total #’s of items checked x 100

Depending upon the tool you are using, i.e. OC or Clintrial, you will need to count and determine the number of items for a particular dataset. 80% of the time, SAS tool is used for this step. Other times, a manual count is required.

Not every issue or discrepancy found is considered an error. This is described in a section of the QC plan. Each Sponsor or CRO is different. For example, misspelling mistakes or changes in punctuation are not considered an error. Also, your statistical team member should be able to identified those items considered ‘critical’ for the statistical analysis.

Common panels/items are: Demography (date of birth, sex, race), lab data, randomization data, Study Conclusion/final status table.

When a clinical database is considered 80-90% clean, the data manager will randomly select a set of patients, as discussed with the statistical leader for the study, to be included in the final QC.

Sample size = √n + 1 where n=the number of patients in the study.

If a study has 34 patients and 1 study site then √34 = 5.83, 5.83 + 1= 6.83. We also determined that only 20% of the patient enrolled will be QC’d therefore, 7 case report forms will be included in the final review.

In order for a clinical data to be considered acceptable, the error rate must be below 0.1% or less.

In conclusion, a good QC plan identify what quality control tasks are needed and that all activities are completed in the most effective way through out the project.


Anayansi Gamboa has an extensive background in clinical data management as well as experience with different EDC systems including Oracle InForm, InForm Architect, Central Designer, CIS, Clintrial, Medidata Rave, Central Coding, OpenClinica Open Source and Oracle Clinical.

Disclaimer: The legal entity on this blog is registered as Doing Business As (DBA) – Trade Name – Fictitious Name – Assumed Name as “GAMBOA”.

21 CFR Part 11 Cheat Sheet for the EDC Developer

The FDA regulates computerized systems used in clinical trials under the authority of Title 21 the Code of Federal Regulations Part 11 (21 CFR Part 11). These regulations apply only to use of systems in trials the results of which will be submitted to the FDA as part of the drug development/approval process.
This document serves as a brief ‘cheat sheet’ of some critical aspects of the 21 CFR Part 11 rules and regulations. While it is not a substitute for a thorough understanding of the law and related FDA Guidance, it may aid in understanding and reference.

I. General Principles
FDA Guidance Documents (http://www.fda.gov/downloads/Drugs/GuidanceComplianceRegulatoryInformation/Guidances/UCM072322.pdf) explain that the key principle behind regulations on computerized systems used in clinical trials is that the data should be attributable, original, accurate, contemporaneous, and legible.

· Attribution & Originality:
o Data entry allows freehand annotations/notes that are attributable and time-stamped
o User Authentication is required as part of a closed system, using biometrics or userid/password
o Passwords must be changed at established intervals
o The system must log users off or timeout after a specified period of inactivity
o The system should keep secure time-stamped audit trails that can’t be modified by system users
o External applications w/o the same authentication & audit protections as the main system should not modify any records in the system
· Accuracy:
o A change to a record should not obscure original record info
o Procedures should be in place to make sure system date/time are accurate
o Training is necessary for users of the system and should be documented
o Study protocols should define usage of a system to create, modify, transmit, maintain, archive, and retrieve data. The system should enforce requirements defined in protocol (eg use of metric units) and check for errors in data entry, modification, retrieval, and transmission.
o The system should have SOPs for setup/install, data collection, system maintenance, backup and recovery, security, and change control
o Vendor should provide design-level validation of software (incl design spec, test plan, test results, and write-up) as well as documentation of software. For each install, trial sponsor and/or site should validate with test data
o The system should have documented processes for change control & revalidation upon modification/upgrade, and modifications/upgrades should be documented
· Contemporaneousness
o The system should be able to display cumulative record of system users and privileges at any given time, incl. user’s name, title, and access privileges
During an audit, the FDA may inspect everything (records and systems). FDA should be able to read all audit trails and the system should generate in human-readable and electronic form accurate and complete copies of records and audit trails.

II. FDA Guidance on Enforcement and Discretion (or, What Types of Activities and Records Does 21CFR Part 11 Apply To?)
From Guidance for Industry Part 11, Electronic Records; Electronic Signatures — Scope and
Application, August 2003 – (http://www.fda.gov/downloads/Drugs/GuidanceComplianceRegulatoryInformation/Guidances/UCM072322.pdf):
We intend to enforce all other provisions of part 11 including, but not limited to, certain controls for closed systems in § 11.10. For example, we intend to enforce provisions related to the following controls and requirements:
• limiting system access to authorized individuals
• use of operational system checks
• use of authority checks
• use of device checks
• determination that persons who develop, maintain, or use electronic systems have the education, training, and experience to perform their assigned tasks
• establishment of and adherence to written policies that hold individuals accountable for actions initiated under their electronic signatures
• appropriate controls over systems documentation
• controls for open systems corresponding to controls for closed systems bulleted above (§11.30)
• requirements related to electronic signatures (e.g., §§ 11.50, 11.70, 11.100, 11.200, and 11.300)

Everyone working in clinical trials must comply with applicable predicate rules, and records that are required to be maintained or submitted must remain secure and reliable in accordance with the predicate rules.

III. Use of Electronic Signatures
Electronic signatures are used to ensure that actions/records are attributable in a legally binding manner. Following is a summary relevant excerpts from the regulation 21 CFR Part 11 (See http://www.fda.gov/ora/compliance_ref/part11/FRs/background/pt11finr.pdf p.36). The summary covers the controls and procedures that should be in place to ensure that the electronic signature can be considered binding and verifiable. Three important sections define system controls, signature controls, and password controls:
– System Controls include controls in workflows, procedures, and system design to ensure that attribution and electronic signatures can be verified. Most important are:
o System validation (discussed above)
o Audit trails (also discussed above)
o Operational system checks – enforcing permitted sequencing of events (workflow management)
o Authority checks – ensuring that only authorized individuals can use the system
o Device (e.g., terminal) checks to determine, as appropriate, the validity of the
source of data input or operational instruction (IP Address logging)
o Documentation of adequate user education, training, and experience.
o Policies for individual accountability for actions initiated under their electronic
signatures
o Controls over distribution of, access to, and use of system documentation
o Change control procedures documenting time-sequenced modification of system documentation.
– Signature Controls (for signatures based on passwords) include:
o Use of at least two distinct id components such as an user id and password.
o Signature Verification:
§ When an individual executes a series of signings during a single, continuous period of controlled system access, the first signing shall be executed using all electronic signature components; subsequent signings shall be executed using at least one electronic signature component that is only executable by, and designed to be used only by, the individual.
§ When an individual executes one or more signings not performed during a single, continuous period of controlled system access, each signing shall be executed using all of the electronic signature components.
– Password Controls include:
o Password expiration
o Rigid and rigorous password de-activation and temporary generation protocols
o Encryption and transaction safeguards to prevent sniffing (SSL, JavaScript MD5)

Appendix
Excerpts from the Regulation 21 CFR Part 11 Related to Electronic Signatures
(See http://www.fda.gov/RegulatoryInformation/Guidances/ucm125067.htm).
§ 11.3 Definitions.
(4) Closed system means an environment in which system access is controlled by persons who are responsible for the content of electronic records that are on the system.
(5) Digital signature means an electronic signature based upon cryptographic methods of originator authentication, computed by using a set of rules and a set of parameters such that the identity of the signer and the integrity of the data can be verified.
(6) Electronic record means any combination of text, graphics, data, audio, pictorial, or other information representation in digital form that is created, modified, maintained, archived, retrieved, or distributed by a computer system.
(7) Electronic signature means a computer data compilation of any symbol or series of symbols executed, adopted, or authorized by an individual to be the legally binding equivalent of the individual’s handwritten signature.
(9) Open system means an environment in which system access is not controlled by persons who are responsible for the content of electronic records that are on the system.

Subpart B—Electronic Records
§ 11.10 Controls for closed systems.
Persons who use closed systems to create, modify, maintain, or transmit electronic records shall employ procedures and controls designed to ensure the authenticity, integrity, and, when appropriate, the confidentiality of electronic records, and to ensure that the signer cannot readily repudiate the signed record as not genuine. Such procedures and controls shall include the following:
(a) Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.
(b) The ability to generate accurate and complete copies of records in both human readable and electronic form suitable for inspection, review, and copying by the agency.
(c) Protection of records to enable their accurate and ready retrieval throughout the records retention period.
(d) Limiting system access to authorized individuals.
(e) Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records.
Record changes shall not obscure previously recorded information. Such audit trail documentation shall be retained for a period at least as long as that required for the subject electronic records and shall be available for agency review and copying.
(f) Use of operational system checks to enforce permitted sequencing of steps and events, as appropriate.
(g) Use of authority checks to ensure that only authorized individuals can use the system, electronically sign a record, access the operation or computer system input or output device, alter a record, or perform the operation at hand.
(h) Use of device (e.g., terminal) checks to determine, as appropriate, the validity of the source of data input or operational instruction.
(i) Determination that persons who develop, maintain, or use electronic record/electronic signature systems have the education, training, and experience to perform their assigned tasks.
(j) The establishment of, and adherence to, written policies that hold individuals accountable and responsible for actions initiated under their electronic signatures, in order to deter record and signature falsification.
(k) Use of appropriate controls over systems documentation including:
(1) Adequate controls over the distribution of, access to, and use of documentation for system operation and maintenance.
(2) Revision and change control procedures to maintain an audit trail that documents time-sequenced development and modification of systems documentation.
§ 11.30 Controls for open systems.
Persons who use open systems to create, modify, maintain, or transmit electronic records shall employ procedures and controls designed to ensure the authenticity, integrity, and, as appropriate, the confidentiality of electronic records from the point of their creation to the point of their receipt. Such procedures and controls shall include those identified in § 11.10, as appropriate, and additional measures such as document encryption and use of appropriate digital signature standards to ensure, as necessary under the circumstances, record authenticity, integrity, and confidentiality.
§ 11.200 Electronic signature components and controls.
(a) Electronic signatures that are not based upon biometrics shall:
(1) Employ at least two distinct identification components such as an identification code and password.
(i) When an individual executes a series of signings during a single, continuous
period of controlled system access, the first signing shall be executed using all
electronic signature components; subsequent signings shall be executed using at least one electronic signature component that is only executable by, and
designed to be used only by, the individual.
(ii) When an individual executes one or more signings not performed during a
single, continuous period of controlled system access, each signing shall be
executed using all of the electronic signature components.
(2) Be used only by their genuine owners; and
(3) Be administered and executed to ensure that attempted use of an individual’s electronic signature by anyone other than its genuine owner requires collaboration of two or more individuals.
(b) Electronic signatures based upon biometrics shall be designed to ensure that they cannot be used by anyone other than their genuine owners.
§ 11.300 Controls for identification codes/passwords.
Persons who use electronic signatures based upon use of identification codes in combination with passwords shall employ controls to ensure their security and integrity. Such controls shall include:
(a) Maintaining the uniqueness of each combined identification code and password, such that no two individuals have the same combination of identification code and password.
(b) Ensuring that identification code and password issuances are periodically checked, recalled, or revised (e.g., to cover such events as password aging).
(c) Following loss management procedures to electronically deauthorize lost, stolen, missing, or otherwise potentially compromised tokens, cards, and other devices that bear or generate identification code or password information, and to issue temporary or permanent replacements using suitable, rigorous controls.
(d) Use of transaction safeguards to prevent unauthorized use of passwords and/or identification codes, and to detect and report in an immediate and urgent manner any attempts at their unauthorized use to the system security unit, and, as appropriate, to organizational management.
(e) Initial and periodic testing of devices, such as tokens or cards, that bear or generate identification code or password information to ensure that they function properly and have not been altered in an unauthorized manner.


Anayansi Gamboa has an extensive background in clinical data management as well as experience with different EDC systems including Oracle InForm, InForm Architect, Central Designer, CIS, Clintrial, Medidata Rave, Central Coding, OpenClinica Open Source and Oracle Clinical.

Disclaimer: The legal entity on this blog is registered as Doing Business As (DBA) – Trade Name – Fictitious Name – Assumed Name as “GAMBOA”.

Audit Record Status in Clintrial

Did you ever wonder what the various status designations used for records in the audit table mean?

Audit table record status is contingent on:

  • The record’s status at the time it was modified or deleted.
  • The database table where the record was stored (update or data).

Audit Table
Status prior to change: Table location prior to change: Audit table code if modified: Audit table code if deleted:
Entered Update -60 -61
Verification Error Update -50 -51
Verified Update -40 -41
Validation Error Update -30 -31
Validated Update -20 -21
Validated Data -10 -11

Did You Know?

Did You Know? »

You can hide temporary SAS datasets by adding a prefix of “_to” and your temporary datasets will not show up in the Work folder in the Explorer window.

e.g. work._toEDC

Remember, temporary datasets are removed at the end of your SAS session.

data work._toPK;
set pk;
rename pkcolt=tm01;
where pkhrs=0.1 ;
run;


Anayansi Gamboa has an extensive background in clinical data management as well as experience with different EDC systems including Oracle InForm, InForm Architect, Central Designer, CIS, Clintrial, Medidata Rave, Central Coding, OpenClinica Open Source and Oracle Clinical.