Tag Archives: clinical research

Are you Practicing GCP?

You probably heard news or stories such as Misconduct Delayed Drug Approval or Duke Settles Negligence Suit.

The Good Clinical Practice (GCP) is an international ethical and scientific quality standard for designing, conducting, recording and reporting trials that involve the participation of human subjects. Compliance with this standard provides public assurance that the rights, safety and well-being of trial subjects are protected, consistent with the principles that have their origin in the Declaration of Helsinki.

The first is to ensure the protection of the patient. The subject’s consent should have been obtained before any study procedure were performed. Each subject is monitor to ensure accuracy and completeness of the data generated.  If an SAE occurred, the monitor will confirm that the SAE has been reported promptly and completely.

The objective of the ICH GCP Guideline is to provide a unified standard practice for the United States, Japan and the European Union (EU) to facilitate the mutual acceptance of clinical data by the regulatory authorities in these jurisdictions.

So what are the essential documents during the conduct of a clinical trial?

1- Investigator Brochure documents relevant and current scientific information around the investigation product (IP) has been provided to the investigator.

2- Signed Protocol (including Amendments) and Case Report Forms (CRF) document investigator and sponsor agreements.

3- Informed Consent Form documents the information given to trial subjects.

4- Financial Aspects of the trial documents the financial agreement between the investigator/institution and the sponsor / research for the trial.

5- Signed agreement between involved parties. For example, sponsor and CRO.

6- Institutional Review Board (IRB) / Ethics committee (IEC) documents the trial has been subject to IRB/IEC review and given approval opinion. For example this includes but not limited to protocol and any amendments, CRF (if applicable), informed consent form, subject compensation.

7- Regulatory authority(ies) approval/notification of protocol documents approval/notification by the regulatory authority compliance with the applicable regulatory requirements(s).

8- Curriculum Vitae and/or other relevant document evidencing qualifications of investigator and sub-investigator as document eligibility to conduct trial and/or provide medical supervision of subjects.

9- Normal value(s)/range(s) for medical / laboratory technical procedures documents normal values of the tests.

10- Sample of label(s) attached to investigational product containers document compliance with applicable labeling regulations and appropriateness of instructions to the subjects.

11- Decoding procedures for blinded trials documents how, in case of an emergency, identify of blinded investigational product without breaking the blind for remaining subject’s treatment.

12- Master randomization list documents method for randomization of trial population.

13- Pre-trial monitoring report documents the site is suitable for the trial.

Note: Any or all documents listed in this guidelines may be subject to, and should be available for audit by the sponsor’s auditor and inspection by the regulatory authority(ies). Any revision to any of the above documents should be added to the files during the trial as evidence.

After completion of a trial, some other documents such as completed subject identification code list, audit certificate, clinical study report and final trial close-out monitoring report shall be available to document completion of the trial.

Research and practice may be carried on together when research is designed to evaluate the safety and efficacy of a therapy. Basic Ethical principles refers to those general judgements that serve as a basic justification for the many particular ethical evaluation of human actions. Respect for persons where persons are treated in an ethical manner not only by respecting their decisions and protecting them from harm, but also by making efforts to secure their well being.

Do not harm – hippocratic maxim

 Who ought to receive the benefits of research and bear its burdens?

An injustice occurs when some benefit to which a person is entitled to or when ought to be treated equally. This principle applies to the rights, safety and well-being of the trial subjects with most considerations and should prevail over interests of science and society.

Conducting clinical trials, in accordance with this principles of good clinical practice (GCP), makes it possible to test the effectiveness and safety of medicines, hence, it is important the understand the principles established in the guidelines.

Source:

http://www.ich.org/home.html and http://www.the-scientist.com/

Anayansi is an EDC Developer Consultant and clinical programmer for the Pharmaceutical and Biotech industry with more than 13 years of experience.

Available for short-term contracts or ad-hoc requests. See my specialties section (Oracle, SQL Server, EDC Inform, EDC Rave, OpenClinica, SAS and other CDM tools)

Fair Use Notice: This blog/article/video contains some copyrighted material whose use has not been authorized by the copyright owners. We believe that this not-for-profit, educational, and/or criticism or commentary use on the Web constitutes a fair use of the copyrighted material (as provided for in section 107 of the US Copyright Law).

If you wish to use this copyrighted material for purposes that go beyond fair use, you must obtain permission from the copyright owner. Fair Use notwithstanding we will immediately comply with any copyright owner who wants their material removed or modified, wants us to link to their website or wants us to add their photo.

Disclaimer: The EDC Developer blog is “one man’s opinion”. Anything that is said on the report is either opinion, criticism, information or commentary. If making any type of investment or legal decision it would be wise to contact or consult a professional before making that decision.

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

Advertisements

7 questions to ask yourself before you choose to set up your own Clinical Data Management department

The arguments to set-up your own Clinical Data Management department are various. You want to learn something new. You can do Clinical Data Management yourself because you could allocate resources for it. Conducting Clinical Data Management in-house could get you more in control of your clinical study data. Clinical Data Management done in-house could cost you less. You could perform Clinical Data Management better yourself. You want to spend your Clinical Data Management budget internally. You see a chance to make (more) money. You see a chance to (better) serve your Customers. You want to complete the gap in your clinical service(s).

Before you make the final decision you could ask yourself 7 questions:
1. For what type of studies should I want to conduct clinical data management myself? For all the studies I conduct? For the first clinical trials in the market application process? For phase III/IV clinical trials? Or for clinical studies conducted post registry?

2. Does a Clinical Data Management group fit in, and does it add value to my company’s core business? Is dedication to the Clinical Data Management performance part of my daily business targets?

3. Do I have enough studies, enough workload for Clinical Data Management to return investments? Is the cost-benefit ratio in my advantage?

4. Can I allocate enough resources, e.g. time, capacity, knowledge and money to the Clinical Data Management department to get clinical data quality from it?

5. Is this the right moment? Right now, should I invest in setting up a new department in my company? Is my company ready for the next step; an own Clinical Data Management group?

6. What are the benefits for my organization when we can conduct Clinical Data Management ourselves? What will it bring us?

7. What are the requirements for this Clinical Data Management department regarding the type of studies and the amount of studies. What are our user requirements for a Clinical Data Management system(s)? What is the capacity we need to handle that Clinical Data Management system and what information do we need?

The number one question in my experience; is a Clinical Data Management department a logical fit within your companies core dedication? Logical like ‘clinical research to get your products accepted for marketing’ or ‘providing clinical research services’. Dedicated Clinical Data Management can start returning investments.

Source:

This is an ezine of Maritza Witteveen of ProCDM. For Clinical Research Directors who struggle with clinical data management to get reliable, quality clinical study data successfully. Receive tips and the free e-book ‘Five strategies to get reliable, quality clinical data’ by subscribing via http://www.procdm.nl/pages/knowledgebase.asp.

Comments? Join us at {EDC Developer}

Anayansi Gamboa, MPM, an EDC Developer Consultant and clinical programmer for the Pharmaceutical and Biotech industry with more than 13 years of experience.

Available for short-term contracts or ad-hoc requests. See my specialties section (Oracle, SQL Server, EDC Inform, EDC Rave, OpenClinica, SAS and other CDM tools)

As the 3 C’s of life states: Choices, Chances and Changes- you must make a choice to take a chance or your life will never change. I continually seek to implement means of improving processes to reduce cycle time and decrease work effort.

Subscribe to my blog’s RSS feed and email newsletter to get immediate updates on latest news, articles, and tips. I am available on LinkedIn. Connect with me there for technical discussions.

Fair Use Notice: This article/video contains some copyrighted material whose use has not been authorized by the copyright owners. We believe that this not-for-profit, educational, and/or criticism or commentary use on the Web constitutes a fair use of the copyrighted material (as provided for in section 107 of the US Copyright Law. If you wish to use this copyrighted material for purposes that go beyond fair use, you must obtain permission from the copyright owner. Fair Use notwithstanding we will immediately comply with any copyright owner who wants their material removed or modified, wants us to link to their website or wants us to add their photo.

Disclaimer: The EDC Developer blog is “one man’s opinion”. Anything that is said on the report is either opinion, criticism, information or commentary. If making any type of investment or legal decision it would be wise to contact or consult a professional before making that decision.

Disclaimer:De inhoud van deze columns weerspiegelen niet per definitie de mening van {EDC Developer}.

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

For Once, in the Right Place at the Right Time?

Dutch Windmills
Learning a Language – Courtesy of Babbel

One of the hardest obstacles I have had to overcome since actually ‘levende’ here as opposed to having a ‘vakantiehuis’ is having a broaden my use of Dutch. Let’s face it, the vocabulary used for shopping, restaurants, the weather and other public places isn’t much use when trying to sort out business professionals, government officials and the like. Your neighbours also expect a little more variety of conversation than ‘goedemorgen, dag, tot ziens’ when they are seeing you on a regular basis.
Learning is a very personal thing dependent on what suits you best and what kind of learner you are. Let’s just say that my memory is not what it used to be!

As far as how these experiences applied to the clinical work or projects, you need to have certain things in place:

  • Discipline and deadlines. Do not confuse this with ‘time management’. I am sort of a person who works better under pressure. Consistency is key to language learning. You can make progress in any language or technology with just a few minutes a day.

Time Management is an illusion. Time cannot be managed. All we are able to manage are activities. Bob Proctor

    • Revision. Being able to speak multiple languages in Europe is common. Most Europeans citizens speak on average two (2) languages some even three or four. Even though I can speak three (3) languages with ease, I really need so much learning with the Dutch. It is not use assuming that I have mastered one verb and then moving onto the next because I won’t have. Same, when you learn a new EDC tool,  you need to practice and revisit all what you have learned. As they say, practice makes perfect!
Map of Europe - Blank Map (summer style)
EU Map – AVG Languages Spoken
  • Writing things down. I am a visual/show me first kind of learner so I take in information better once I have written it down and even better if I use my mind to map and draw it. So find what suits you best to improve your EDC learning experiences.
  • Speaking. I need to use the new material immediately for it to go into my memory. Learn to speak the EDC programming language.
  • Reading. This will improve your vocabulary and help you with the grammar and spelling. Spend time reading online blogs, biotechnology magazines, youtube technology channels and even your own company’s WPs / SOPs as they will help you be a better EDC developer.

The knowledge that my horizons can be so much wider than I thought, that you can communicate and connect with people and make a home in a different place. I have come to embody a very different mentality. Being here has given me many opportunities, but one of the biggest changes has been having the time and money to travel, and of course, learn to speak a new language.

I hope this helps. I have found some useful resources and they are listed all over this blog. In the future, I plan to add more resources and training materials. Remember that learning and development are lifetime activities—there’s no finish line.

Amazingly, I think I can be sure for once I was in the right place at the right time.

Anayansi Gamboa, MPM, an EDC Developer Consultant and clinical programmer for the Pharmaceutical and Biotech industry with more than 13 years of experience.

Available for short-term contracts or ad-hoc requests. See my specialties section (Oracle, SQL Server, EDC Inform, EDC Rave, OpenClinica, SAS and other CDM tools)

As the 3 C’s of life states: Choices, Chances and Changes- you must make a choice to take a chance or your life will never change. I continually seek to implement means of improving processes to reduce cycle time and decrease work effort.

Subscribe to my blog’s RSS feed and email newsletter to get immediate updates on latest news, articles, and tips. I am available on LinkedIn. Connect with me there for technical discussions.

Disclaimer: The EDC Developer blog is “one man’s opinion”. Anything that is said on the report is either opinion, criticism, information or commentary. If making any type of investment or legal decision it would be wise to contact or consult a professional before making that decision.

Disclaimer:De inhoud van deze columns weerspiegelen niet per definitie de mening van {EDC Developer}.

Where in the World is Ana?

First, I want to say thank you for reading my blog, connecting with me on LinkedIn or following whenever I go [thank you NSA].

Many of you, for months, have asked me if I was going to write more articles related to clinical trials. For sometime now, I have taking time-off from this EDC blog and concentrated on some other projects of equal importance. I will share some new insights and information as I get myself back on track.

So what is a girl who has a master’s degree in project management and computer networks doing as a programmer? It’s not that I didn’t like project management, per se. And entering in the IT network business years ago was quite difficult for girls like me in a world dominated by men. It’s basically that I didn’t find myself with the same passion for project management or computer networks that I have for programming and technology in general.

Because I am so interested in technology and programming, I tend to spend a lot more time than my peers in learning new technologies, and enhancing my existing skills. Many of my co-workers and ex-collega (Dutch) have commented on their admiration that my skill level is as high as it is, and that I am able to learn new technologies so quickly. But beyond just learning new technologies and APIs, I’m passionate about becoming a better overall programmer. Reason why in the last few months, I spent time learning IOs development (iPhone and Android apps). I am actually working on an app to ‘hack’ into my own car. 🙂 Well, not exactly. I want to be able to open my car and do some other basic command (like opening the garage door) using an APP.

Given my degree in project management, it should be clear that I have useful skills beyond the programming world. In fact, having a project management background has helped me interface with various groups in various organizations in which I’ve worked.

I have installed, maintained, and designed numerous relational databases and small networks. As a freelancer, I have worked in projects doing data analysis, project support and computer training.

Now you know a little about me personally. If you think I might be the type of developer you’re looking for, feel free to browse my resume and contact me.

Anayansi Gamboa
Resume / CV .

Comments? Join us at {EDC Developer}

P.S. I will be releasing some training videos / training material for several EDC tools in the near future including tips and best practices. Price has not been setup yet. All training will be web-based, password protected. If you wish to consult with me for a face-to-face training or on-site training, please contact me to discuss further.

Fair Use Notice: This video contains some copyrighted material whose use has not been authorized by the copyright owners. We believe that this not-for-profit, educational, and/or criticism or commentary use on the Web constitutes a fair use of the copyrighted material (as provided for in section 107 of the US Copyright Law. If you wish to use this copyrighted material for purposes that go beyond fair use, you must obtain permission from the copyright owner. Fair Use notwithstanding we will immediately comply with any copyright owner who wants their material removed or modified, wants us to link to their website or wants us to add their photo.

Disclaimer: The EDC Developer blog is “one man’s opinion”. Anything that is said on the report is either opinion, criticism, information or commentary, If making any type of investment or legal decision it would be wise to contact or consult a professional before making that decision.

Disclaimer:De inhoud van deze columns weerspiegelen niet per definitie de mening van {EDC Developer}.

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

Clinical Trials 101

Clinical trials are research studies that involve people and test new ways to prevent, detect, diagnose, or treat cancer and other diseases. At the conclusion of this webinar, you will be able to demonstrate a basic understanding of the basics of clinical trials, including how they work, protections for participants and factors related to participation.

Source: NCI Events

FAIR USE-
“Copyright Disclaimer Under Section 107 of the Copyright Act 1976, allowance is made for “fair use” for purposes such as criticism, comment, news reporting, teaching, scholarship, and research. Fair use is a use permitted by copyright statute that might otherwise be infringing. Non-profit, educational or personal use tips the balance in favor of fair use.”

 

anayansi gamboa

Professional Timeline – Clinical Programmer

Professional Timeline

Curriculum Vitae
CV

 

anayansi gamboa

Good Programming Practice for Clinical Trials by Sunil Gupta

The following are draft recommendations a Good Programming Practice for analysis, reporting and data manipulation in Clinical Trials and the Healthcare industries.

The purpose is to encourage contributions from across companies, non-profit organizations and regulators in an attempt to create a consensus recommendation. The ambition is that this page becomes recognized by the Pharmaceutical Industry, Clinical Research and Health Care Organizations as well as Regulatory Authorities.

The hope is that the Practice can be reviewed and endorsedby the relevant management teams of several Pharmaceutical companies and major Contract Research Organizations and promoted through relevant professional organizations such as PharmaSUG, PhUSE, PSI, CDISC.

Introduction

The Good Programming Practices are defined in order to:

  • Ensure the clarity of the code and facilitate code review;
  • Save time in case of maintenance, and ease the transfer of code among programmers or companies;
  • Minimize the need for code maintenance by robust programming;
  • Minimize the development effort by development and re-use of standard code and by use of dynamic (easily adaptable) code;
  • Minimize the resources needed at execution time (improve the efficiency of the code);
  • Reduce the risk of logical errors.
  • Meet regulatory requirements regarding validation and 21CFRPart11 compliance

Note: As often, the various guidelines provided hereafter may conflict with one another if applied in too rigorous a way. Clarity, efficiency, re-usability, adaptability and robustness of the code are all important, and must be balanced in the programming practice.

Regulatory Requirements

Validation

21CFRPart11 compliance

Readability and Maintainability

Language

English is an international language and study protocols, study reports for practical reasons (regulatory authorities, inlicensing, outlicensing, partnerships, mergers) are mostly written in English, therefore it is recommended to write the SAS code and comments in English.

Header and Revision History

  • Include a header for every program (template below).
**********************************************************;* Program name      :** Author            :** Date created      :** Study             : (Study number)*                     (Study title)** Purpose           :** Template          :** Inputs            :** Outputs           :** Program completed : Yes/No** Updated by        : (Name) – (Date): *                            (Modification and Reason)**********************************************************;
  • In addition to your name or initials, use your login ID to identify yourself in the header. This is so there is no ambiguity on the identify of each programmer.
  • Update the revision history at each code modification made after the finalization of the first version of a program.

Note: When you copy a program from another study, you became the author of this program, and you should clear the revision history. You can specify the origin of the program under the “Template” section of the header.

Below is an example with comments of an alternative comment block that I think is more useful for Open Source programming. PaulOldenKamp 16:54, 5 April 2009 (UTC)

/** ---------------------------------------------------------------------------------------- $Id: os3a_autoexec.sas 152 2008-11-17 01:48:40Z Paul_ok01 $ <== Id info automatically inserted with each commit to Subversion version control Application: OS3A - Common Programs Description: OS3A session initialization program. Previous Program: None Saved as: c:\os3a\trunk\os3a_autoexec.sas <== locations, local and web, where the pgm http://os3a.svn.sourceforge.net/viewvc/os3a/trunk/os3a_autoexec.sas can be found Change History: Date Prog Ref Description 04/26/2008 PMO [1] Initial programming for os3a <== date, programmer initials, ref number [1] to link to specific location of change Copyright: Copyright (c) 2008 OS3A Program. All rights reserved. <== Always tell who owns the program so one Copyright Contact: paul_ok01@users.sourceforge.net can ask permission from the copyright holder License: Eclipse Public License v1.0 <== Tell folks how they are licenced to use This program and the accompanying materials are made available under the program. the terms of the Eclipse Public License v1.0 which accompanies this distribution, and is available at www.eclipse.org/legal/epl-v10.html Contributors: Paul OldenKamp, POK_Programming@OldenKamp.org - Develop initial pgm. <== Identify significant contributors <== tag identifies start of info @purpose OS3A system initialization program. used by the Codedoc Perl script to Set up initial options and global macro variables. produce external HTML documentation @param SYSPARM - input provided from program initiation call; default: main_FORE for production. @symbol sysRoot - system root location; Windows - C:/, UNIX - / @symbol remove_cmd - system command to remove file; Windows - erase, UNIX - rm @symbol os3aRoot - directory location of os3a root @symbol futsRoot - directory location of FUTS top level macros. @symbol Root - directory location of sub-project identified with Four Letter Acronym ----------------------------------------------------------------------------------------- */

The results from encoding the header and comments in a SAS program can be seen on the CodeDoc web page. See http://www.thotwave.com/products/codedoc.jsp.
CodeDoc Download Page

Comments

  • Include a comment before each major DATA/PROC step, especially when you are doing something complex or non-standard. Comments should be comprehensive, and should describe the rationale and not simply the action. For example, do not comment “Access demography data”; instead explain which data elements and why they are needed.
  • Organize the comments into a hierarchy.
  • Do not include numbers in comments.

Reason: It avoids heavy update when removing or inserting sections.

Naming Conventions

  • Use explicit and meaningful names for variables and datasets, with a maximum length of 8.
  • For permanent datasets, use a meaningful dataset label and variable labels.
  • When possible, never use the same name for a dataset more than once in the program.

Note: However, keep in mind that large intermediate files take a lot of SAS Workspace.

  • Name IN variable using “in” plus a meaningful reference to the dataset.

Example:

data aelst;   merge aesaes (in=inae) patpat (in=inpat);   by patno;   if inae and inpat;run;
  • Labels must have a maximum length of 40 characters.

Code Structure

  • It is mandatory to include libnames, options and formats in a separate setup program unless these are temporary formats or temporary options that are reset after being used.

Reason: It will guarantee that changes of the environment are taken into account in all programs run afterwards.

  • Use standard company macros to read in libnames and settings, to write out datasets, and for standard calculating and reporting.
  • One statement per line, but several are allowed if small and repeated or related. Long statements should be split across multiple lines.
  • Control system settings to show all executed code in the log as the default, in as clear manner as possible. The log should not be so lengthy that the programmer cannot easily navigate (if so, use highly visible comments with sufficient white space). System settings should be able to be easily changed in order for a user to debug a section of code or a macro, in order to temporarily display the %included code, resolved macro names, and logic.
  • Use a standard sequence for placing statements and group like statements together.
  1. Within a program:
    1. %LET statements and macro definitions
    2. Input steps
    3. Calculations
    4. Save final (permanent) datasets and created outputs
  2. Within a DATA step:
    1. All non-executable statements first (e.g. ATTRIB, LENGTH, KEEP…)
    2. All executable statements next

Reason: It increases the readability of the program.

  • Left-justify DATA, PROC, OPTIONS statements, indent all statements within.

Example:

proc means data=osevit;   var prmres;   by prmcod treat;run;
  • End every DATA/PROC step with a left-aligned RUN statement.

Reason: It explicitly defines the step boundary.

  • Insert at least one blank line after each RUN statement in DATA/PROC steps.
  • Indent statements within a DO loop, align END with DO.
  • Avoid having too many nested DO loop and IF-ELSE statements.
  • In case of interlinked DO loop, add a comment at the start (DO) and end (END) of each loop.

Example:

data test01;  do patno=1 to 40; * cycle thru patients;    do visit=1 to 3; * cycle thru visits;      output;     end; * cycle thru visits;  end; * cycle thru patients;run;
  • Insert parentheses in meaningful places in order to clarify the sequence in which mathematical or logical operations are performed.

Example:

data test02;  set test01;  if (visit=0  and vdate lt adate1)   or (visit=99 and vdate gt adate2) then delete;run;

Style conventions

Draft section : this may not be specific to clinical programming, but may be of use when considering a general standard for sharing programs.

Use of analysis datasets

For discussion of why programming output directly from raw data is generally avoided.

Efficiency

  • When you input or output a SAS dataset, use a KEEP (preferred to DROP) statement to keep only the needed variables.

Reason: The SAS system loads only the specified variables into the Program Data Vector, eliminating all other variables from being loaded.

  • When subsetting a SAS dataset, use a WHERE statement rather than IF, if possible.

Reason: WHERE subsets the data before entering it into the Program Data Vector, whereas IF subsets the data after inputting the entire dataset.

  • When using IF condition, use IF/ELSE for mutually exclusive conditions, and check the most likely condition first.

Reason: The ELSE/IF will check only those observations that fail the first IF condition. With the IF/IF, all observations will be checked twice. Also, consider the use of a SELECT statement instead of IF/ELSE, as it may be more readable.

  • Avoid unnecessary sorting. CLASS statement can be used in some procedure to perform by-group processing without sorting the data.

Example:

proc means data=osevit;  var prmres;  class treat;run;
  • If possible (i.e. not a sorting variable), use character values for categorical variables or flags instead of numeric values.

Reason: It saves space. A character “1” uses one byte (if length is set to one), whereas a numeric 1 uses eight bytes.

  • Use the LENGTH statement to reduce variable size.

Reason: Storage space can be reduced significantly.
Note: Keep in mind that a too limited variable length could reduce the robustness of the code (lead to truncation with different sets of data).

  • Use simple macros for repeating code.

Robustness

  • Use the MSGLEVEL=I option in order to have all informational, note, warning, and error messages sent to the LOG.
  • In the final code, there should be no dead code that does not work or that is not used. This must be removed from the program.
  • Code to allow checking of the program or of the data (on all data or on a subset of patients such as clean patients, discontinued patients, patients with SAE or patients with odd data) is encouraged and should be built throughout the program. This code can be easily activated during the development phase or commented out during a production run using the piece of code detailed in Section 6.
  • It is not acceptable to have avoidable notes or warnings in the log (mandatory).

Reason: They can often lead to ambiguities, confusion, or actual error (e.g. erroneous merging, uninitialized variables, automatic numeric/character conversions, automatic formatting, operation on missing data…).
Note: If such a warning message is unavoidable, an explanation has to be given in the program (mandatory).

  • Always use DATA= in a PROC statement (mandatory).

Reason: It ensures correct dataset referencing, makes program easy to follow, and provides internal documentation.

  • Be careful when merging datasets. Erroneous merging may occur when:
  1. No BY statement is specified (set system option MERGENOBY=WARN or ERROR).
  2. Some variables, other than BY variables, exist in the two datasets (set system option MSGLEVEL=I), S writes a warning to the SAS log whenever a MERGE statement would cause variables to be overwritten at which the values of the last dataset on the MERGE statement are kept).
  3. More than one dataset contain repeats of BY values. A WARNING though not an ERROR is produced in the LOG. If you really need, PROC SQL is the only way to perform such many-to-many merges.

Reason: One has to routinely carefully check the SASLOG as the above leads to WARNING messages rather ERROR messages yet the resulting dataset is rarely correct.

  • When coding IF-THEN-ELSE constructs use a final ELSE statement to trap any observations that do not meet the conditions in the IF-THEN clauses.

Reason: You can only be sure that all possible combinations of data are covered if there is a final ELSE statement.

  • When coding a user-defined FORMAT, include the keyword ‘other’ on the left side of the equals sign so that all possible values have an entry in the format.

Reason: A missing entry in a user-defined FORMAT can be difficult to detect. The simplest way to identify this potential problem is to ensure that all values are assigned a format.
Note: This does not apply to INFORMATs. It could be more helpful to get a WARNING message when trying to INPUT data of unexpected format.

  • Try to produce code that will operate correctly with unusual data in unexpected situations (e.g. missing data).

Code for Data Checks

Build checks so that their purpose is clear, so that they can be toggled on or off, and remove them once they are no longer needed.

Activate/Deactivate Pieces of Code

In the beginning of the program, define a macro variable that you set to blank during the development phase or that you set equal to * for the production run:

%let c=;  or  %let c=*;

For the pieces of code that check the data/program, start each line with the macro variable defined above:

&c title “Check the visits for each patient”;&c proc freq data=patvis01;&c    table patno*visit;&c run;

This code will be executed if &c is blank (development), but will be commented out when &c=* (production).

Perform Checks on a Subset of Patients

In a separate code that you store under the study MACRO folder, list the subset of patients (clean patients, discontinued patients, patients with SAE or patients with odd data) that you want to look at:

%macro select;2076 2162 2271 2449%mend;

In the beginning of the program, define a second macro variable that you set equal to * when you want to perform checks on all data or to blank when you are interested in a subset of patients:

%let s=*;  or  %let s=;

For each checking code, add a piece of code that allows subsetting the data, and start each line of this piece of code with the 2 macro variables defined above:

&c title “Check the visits for each patient”;&c proc freq data=patvis01;&c    table patno*visit;&c &s where patno in (%select);&c run;

The check will be performed only if &c is blank, and it will be applied to all patients if &s=* or on the subset of patients if &s is blank.
Better still: input the list of check case IDs as a dataset.

Floating Point Error

Consider the real number system that we are familiar with. This decimal system (0 → ± ∞) is obviously infinite. Most computers use floating point representation, in which, a finite set of numbers is used to represent the infinite real number system. Thus, we can deduce that we will have some sort of error appearing from time to time. This is more generally termed Floating Point Error and occurs in computers due to hardware limitations.

The following paper goes someway in explaining why and how this happens and also possible solutions in how to approach this issue.

Paper reference:- http://www.lexjansen.com/phuse/2008/cs/cs08.pdf

Data Imputation versus Hardcoding

Please contribute

  • Definitions
    • Data Imputation
    • Hardcoding
  • Issues
  • Recommendation

Integrity of a data transfer

At a minimum, all data transfers should be validated by checking the observation counts for each SAS dataset
or the record counts in other formats, against counts provided by the sender. It is also helpful if the sender
can provide a checksum for each file transferred since this also ensures all content made it’s way to you
without transmission errors. There are many freeware programs available to calculate checksums for any file at websites such as http://sourceforge.net/ .

Macros

Draft section : recommendations particularly relevant for the development and use of macros and macro libraries.

Macros are particularly useful under the following circumstances:

  • Program code is used repeatedly
  • A number of steps must be taken conditionally, and the logic for these is clearly fixed (no need to think of all the steps that should be included in a program under a specific situation: the macro will deduce them for you and generate the appropriate data step or proc step code)
  • There is no trivial solution via “ordinary” SAS code
  • Their application must be easier as to program the code itself!
  • The usage helps users avoiding errors and omissions.

If used appropriately the following benefits can be achieved:

  • Increase in quality by avoiding programming bugs and errors
  • Savings in time and resources
  • Enforcement of standards, e.g. standard methods and standard outputs
  • Work can be more enjoyable as programmers can focus on the non-routine work

Ideally Macro development should follow a few rules:

  • Macro headers should clearly state all changes to environment and data that result from execution. Changes should be limited to those necessary for the focused purpose of the macro:
    • strictly controlled changes to input data and creation of output data
    • clear temporary data set clutter
    • no unexpected changes to system settings (options, titles, footnotes, etc)
    • no unexpected changes to external symbol tables
  • Scope of macro variables should be explicitly controlled using %global and %local statements.
  • Method of macro variable creation should demonstrate awareness of default scope:
  • The log matters:
    • Use Base SAS techniques whenever possible to avoid excessive code generation (log bloat). For example, macro definition should use DATA step array and DO loop processing rather than Macro %DO looping.
    • But use pure Macro Language for routine utility macros (see details, below).
    • Use appropriate comment style in macro definitions to properly annotate the SAS log when MPRINT in on. For example, use %* style commenting to explain macro logic, but /* style commenting to explain resulting code. (Or * style or PUT statement commenting as appropriate.)
    • Allow the users to control the appearance of the log via MPRINT, SYMBOLGEN, and MLOGIC.
  • Code within a macro definition should be germane, limited to the specific purpose of the macro. The use of a central repository for macros (“Macro library”) is suggested.
  • Macro Library: Code for routine tasks (eg, parameter checking, system and environment checking, messaging, etc.) should be handled by dedicated utility macros. Code for such routine tasks should not overwhelm the current macro definition, obscuring the purpose, and creating unnecessary maintenance overhead and lack of consistency within a library.
  • Macro Library: Parameter naming conventions should be used for common parameters such as input/output libnames and data sets. Explicit and transparent control of macro variable scope again becomes crucial to avoid accidental change of external symbol tables
  • Macro Library: Use pure Macro Language definitions whenever possible to improve program flow and avoid producing unnecessary Base SAS code. Returning a list of data set variable, checking for macro var existence, returning data set obs count can all be achieved without BASE SAS code. Such macros can be called “inline” without unnecessary overhead or interruption of program flow.

For example, instead of %count_ds_obs definition that uses DATA Step code and interrupts program flow like

%let n_obs = %count_ds_obs(DSIN=myData);%if &n_obs > 0 %then %do;  ... more statements ...%end;

an inline, pure Macro Language implemetation allows streamlined code:

%if %inline_ds_obs(DSIN=myData) > 0 %then %do;  ... more statements ...%end;

Source: Sunil Gupta, Senior SAS Consultant, Gupta Programming http://www.sascommunity.org/wiki/Good_Programming_Practice_for_Clinical_Trials

Safety Reporting in Clinical Trials – (Sample pages)

FAIR USE-
“Copyright Disclaimer Under Section 107 of the Copyright Act 1976, allowance is made for “fair use” for purposes such as criticism, comment, news reporting, teaching, scholarship, and research. Fair use is a use permitted by copyright statute that might otherwise be infringing. Non-profit, educational or personal use tips the balance in favor of fair use.”

Source: ClinfoSource

Informed Consent Content and Process Requirements

FAIR USE-
“Copyright Disclaimer Under Section 107 of the Copyright Act 1976, allowance is made for “fair use” for purposes such as criticism, comment, news reporting, teaching, scholarship, and research. Fair use is a use permitted by copyright statute that might otherwise be infringing. Non-profit, educational or personal use tips the balance in favor of fair use.”

Source:Cambridge Health Technology

What is a clinical protocol?

FAIR USE-
“Copyright Disclaimer Under Section 107 of the Copyright Act 1976, allowance is made for “fair use” for purposes such as criticism, comment, news reporting, teaching, scholarship, and research. Fair use is a use permitted by copyright statute that might otherwise be infringing. Non-profit, educational or personal use tips the balance in favor of fair use.”

Source:Advance Health