Tag Archives: electronic data capture

Clinical Programmer Available for Consultancy projects.

Clinical Programmer Available for consultancy projects – Medidata Rave Certified.

Rate: Negotiable

Hours: part time or full time

Contracts: 1099 or Corp-2-corps only.


ClinCapture® Tutorial – How to enter a patient schedule a visit and start entering data

ClinCapture® Tutorial – How to enter a patient, schedule a visit and start entering data – YouTube.

ClinCapture® is the most advanced open-source electronic data capture (EDC) system designed to streamline your clinical trials. As an open-source solution, ClinCapture® is tailored to meet the needs of life science companies looking to run cost-effective clinical trials.

ClinCapture® can be rapidly deployed and easily adopted, customizable to specific study requirements. ClinCapture® is repeatedly chosen as a preferred EDC solution because it is intuitive, flexible, and proven.

Source: Clinovo

“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

Central Designer – Troubleshooting Tips

If an edit check or function fails to behave as expected, it is time to use your ‘troubleshooting’ skills. The following tips may help you when you are troubleshooting rules in InForm:


  • check if rules are running
  • check the rule logic
  • check Rule Dependencies: a rule on a form has access to items on that form, but not other forms or other visits
  • check InForm machine’s Application Event Log

Though some vendors will correct major problems with their products by releasing entirely new versions, other vendors may fix minor bugs by issuing patches, small software updates that address problems detected by users or developers.

Check the release notes for Central Designer for known problems. The release notes provide descriptions and workaround solutions for known problems.
Remember that there is a report available you can run “Data Entry Rule Actions Report”. This report outputs all data entry rules in CSV format and can be formatted into an edit check specification documentation for QA testing.
A rule can be written in more than one way, which makes it difficult to impose any restrictions:
Scenario: Route item has 3 choices. OP, SC and IV. Query should fire if the user does not choose either OP or SC. This rule could be written in many ways:

–Value = route.Value

If (value == 3)

–Value = route.Value == 3

If (value == true)

–Value = !(route.Value == 3)

If (value == false)

–Value = (route.Value == 1 || route.Value == 2)

If (value == false)

–Value = route.Value !=1 && route.Value != 2

If (value == true)

Keep it consistent across the trial. Do not overuse the conditional statements when a simple range check should be program.

Note: Be aware that if you want to reuse a rule that uses data from a logical schema in another study, the other study must also contain the logical schema.

If you have explored most of the obvious possibilities and still
cannot get your rule / edit check to work, ask someone in your team to peer review the build.


  • unit test your code
  • context available for defining test cases
  • Site name, date/time, locale; Form associations; Empty values; Unknown dates; Repeating objects
  • test case results: Pass or Fail based on expected results
  • perform formal QA / QT

Remember to check the Event log via Control Panel -> Administrative Tools -> Event Viewer

Reference Document : Central Designer – Rule Troubleshooting.pdf

Your comments and questions are valued and encouraged.
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.

Good Documentation Practice (GDP) for the EDC / SAS Developer

When writing programming codes for either validating the software or for validation checks, we often have to write comments to explain why we did something.

Since 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) – see my other article about 21 CFR Part 11 here, we need to make sure our codes and programs are documented. As you have heard before, if it is not documented, it never happened. Nevertheless, there is no mandatory regulatory agency mandating to have to do this.

GDP is an expected practice”

So how much documentation is needed? We could get into endless discussions of when we should comment, what we should comment, and how much we should comment. I have had plenty of discussions about comments with people with various opinions on the subject.

Here’s a good documentation practice for a SAS code:

The program header was written to validate Clintrial (Oracle).

  • Program name, version, programmer and purpose.
  • Modifications
  • Risk Assessments

The second section contains information about the

  • quality testing, user testing
  • Macros, global variables and any other code that is reusable.

The document must tell the entire story about your program and must be readable by internal or external staff. Two other important things to remember, your program must be accurate “error free” and each section of your program must be traceable, such as who updated it, what and why.

Most companies have SOPs that requires you to record certain information. But do we understand what it is we are recording? or when it was recorded?

Standardized Documentation is KEY”

Do you have a preference? Tell me about it in the comments!

To hire me for services, you may contact me via Contact Me OR Join me on LinkedIn

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

Got EDC?

Clinical trials play a key role in the pharmaceutical, biotechnology and medical device industry. With a large number of drugs coming off patent, companies are under pressure to develop and test new drugs as swiftly and efficiently as possible. This requires an increase in clinical trials and a reduction in the time cycle of those trials.

What is Electronic Data Capture?

Electronic Data Capture or EDC is the gathering of data collected by humans into computer systems without the need for manual data re-entry. EDC systems can speed time-to-market, reduce data entry errors, provide for early analysis and trend monitoring.

Data entry can be achieved using a number of mechanisms. Users can enter data directly into an electronic device such as a laptop PC, handheld device, tablet PC, and touch screen or tone dialing system such as IVRS.

EDC has been around for more than 10 years and still only about a third of all studies use it – the rest using paper-based data collection process.

While EDC has many advantages, a barrier to success is the expectation that the system is ready at the time of the enrollment of the first subject (patient). In order to achieve this target, one must have agreement on the data to be collected during the trial. I have found that this requirement frequently changes between the finalization of the protocol and first subject in. When paper case report forms are used, these changes to data can be more easily accommodated.

For EDC to become increasingly used in the pharmaceutical industry, they need to address the challenges prior to implementation. However, while pilot studies have been successful, pharmaceutical companies have not yet implemented EDC across the majority of their clinical trials. They are constrained by a lack of strategic planning, the varying requirements of each trial, the relative immaturity and fragmentation of the EDC software market and the need to address both process and change management.


  • What data are you gathering?
  • Is the site and clinical personal fully trained? What hardware do they have available?
  • Validation – Is validation of input data required?
  • Workflow – Do the data need validating, reviewing, approving and releasing for general consumption locally and centrally?
  • Integration – Does the system need integrating with other computer systems? Regulations. Does the system have to conform to any externally imposed regulations, such as 21 CFR Part 11, Good Manufacturing Practice, or Good Laboratory Practice?

EDC eliminate the transcription error (paper-based errors) and therefore transcription errors.


  • Double-Data Entry – The manual re-entry of data recorded on paper is expensive and unreliable
  • Validation – Immediate validation of data entry
  • User Friendly Web Forms – Data entry is quick and efficient
  • Access to real time data – quick executive level decision and information

EDC helps reduce invalid data entries and speed up the availability of drug trial information.

While the EDC technology still faces some challenges, benefits will drive acceptance. A leading stimulation to growth will be the reduction in price and increased sophistication and power of small handheld devices. These developments are only useful if accepted by the users. Not all EDC systems are created equally, and one must carefully pick a system that best meets your need.

If a company changes from paper-based system to EDC system, this ‘innovation’ will have a human side. Successful implementation is not just a matter of installing the software and announcing the change. Stakeholders, who are responsible for collecting, processing and communicating clinical trial data must adopt and adapt to the new systems – ensuring that a technical innovation is actually successfully adopted.

With current standards CDISC initiatives, it is inevitable that the FDA will eventually demand all information be provided in this format — although no date has yet been set.

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”.

From Non-SAS Programmer to SAS Programmer

SAS Programmers come from many different educational backgrounds. Many has started their careers as a Data Manager in a CRO environment and grew to become a SAS programmer. Others have gone to college and pursued degrees in math, statistics or computer science degree.

Do you have SAS Skills? First, you need to find out more about statistical programming desire skills and start to slowly learn what SAS programmers and statisticians do in the pharmaceutical industry. It is also important to understand the Drug Development and Regulatory process so that you have a better understanding of the industry as a whole as well as the drug approval process.

In addition, I have personally attended several workshop on Statistics for Non-statistician provided by several of my past employers/clients (GSK, Sanofi-Aventis, etc) so I could have a greater understanding of statistics role. I am personally more inclined to the EDC development than becoming a biostatistician but these are just some of the few steps you could take to grow your career as a SAS programmer.

Practice, Practice, Practice!

To begin learning how to actually program in SAS, it would be a good idea to enroll to a SAS course provided by the SAS Institute near you or via eLearning. I have taken the course SAS Programming 1: Essentials, and I would recommended. You could also join SUGI conferences and other user groups near your city/country. Seek every opportunity to help you gain further understanding on how to efficiently program in the pharmaceutical industry. It could well land you a Junior SAS programming position.

Transitioning to a SAS Programming role: Now that you have gotten your first SAS programming job, you will need to continue your professional development and attend additional training, workshops, seminars and study workgroup meetings. The SAS Institute provide a second level, more advance course Programming II: Manipulating Data with the Data Step, SAS Macro Language and SAS macro Programming Advanced topics. There are also SAS certifications courses available to help you prepare to become a SAS certified programmer.

There is a light at the end of the tunnel: Advance!

Your ongoing development will be very exciting and challenging. Continued attending SAS classes as needed and attending industry related conferences such as PharmaSUG to gain additional knowledge and insight on how to perform your job more effectively and efficiently.

As you can see, it is possible to ‘grow’ a SAS programmer from a non-programming background to an experience programmer. All of the classes, training, and projects you will work on are crucial in expanding your SAS knowledge and will allow you to have a very exciting career opportunity ahead of you.

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.

SDTM Terminology

The current version of the Study Data Tabulation Model Implementation Guide Version 3.1.2 (SDTMIG v3.1.2) answers to CDSH questions to comply with SDTM terminology.

Some key points to remember:

  • You need to define which codelists will be applied to which questions
  • Most data entry systems require a concise list of potential terms per variable/field
  • SDTM terminology codelists are big, e.g. C66786 – COUNTRY which covers all potential COUNTRYs for all clinical trials / site management
  • Controlled terminology gap – we need to develop new terms

So how SDTM terminology become possible?

In order to improve the efficiency of human drug review through required electronic submissions and standardization of electronic drug application data, FDA and industry leaders are working together in this initiative.

Format in EXCEL

SDTM controlled terminology is extracted from the NCit by an automated procedure that creates a report organized into terminology codelists. These codelists correspond to CDISC variables.

To access SDTM Controlled Terminology visit CDISC website and click on Standards & Innovations –>; Terminology

This is the superset of codelists that are used to both collect and submit SDTM data

Excel Format – Column descriptions in the Controlled Terminology (SDTM subset)

Column. Description
Code (column A) Unique numeric code randomly generated by NCI Thesaurus (NCIt) and assigned to individual CDISC controlled terms.
Codelist Code (Column B) Unique numeric code randomly generated by NCI Thesaurus (NCIt) and assigned to the SDTM parent codelist names. This code is repeated for each controlled term (aka permissible value) belonging to a codelist. As of 9/22/2008, this code was dropped for parent codelist entries, where it created confusion.
**NOTE – light blue highlighting is used to identify the beginning of a new SDTM codelist and its applicable term set.
Codelist Extensible (Yes/No) (Column C) Defines if controlled terms may be added to the codelist. New terms may be added to existing codelist values as long as they are not duplicates or synonyms of existing terms. The expectation is that sponsors will use the published controlled terminology as a standard baseline and codelists defined as “extensible” (or “Yes”) may have terms added by the sponsor internally.
Codelist Name (Column D) Contains the descriptive name of the codelist which is also referred to as the codelist label in the SDTM IG. As with the Codelist Code, the Codelist Name is repeated for each controlled term belonging to a codelist.
CDISC Submission Value (Column E) IMPORTANT COLUMN: Currently (as per SDTMIG 3.1.2) this is the specific value expected for submissions. Each value corresponds to a SDTM Codelist Name as indicated by light blue shading.
CDISC Synonym(s) (Column F) This identifies the applicable synonyms for a CDISC Preferred Term in Column F. **NOTE – this is especially important in instances where a Test name or Parameter Test name contains a corresponding Test Code or Parameter Test Code.
CDISC Definition (Column G) This identifies the CDISC definition for a particular term. In many cases an existing NCI definition has been used. The source for a definition is noted in parentheses (e.g. NCI, CDISC glossary, FDA).
NCI Preferred Term (Column H) This identifies the NCI preferred name for a term as identified in NCIt. **NOTE – This column designates the human readable, fully specified preferred term corresponding to the NCI c-code, and is especially helpful for searching NCIt to get the entire concept with links to all instances of the term.

Above example of the spreadsheet for the ‘Route of Administration‘ codelist.

Reference: Clinical Data Interchange Standards Consortium, Inc (CDISC) Representing Controlled Terminology in CDASH

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.

SAS Programmers Tools

Are you new to SAS and wondering how to write SAS programs?

Most SAS programmers use the built-in SAS enhanced editor for their daily works. Sometimes, this editor is replaced by the code editor of SAS Enterprise Guide which provide other features like the Log tab, Output data tab and Results tab. However, some SAS users like their text editor to be very customizable and full of features which may or may not be in the enhanced editor.

If you find that your current editor is insufficient in handling your work you are not alone. We have found some alternative editors and below are some of the text editors I have come across that you can use instead of the pre-built SAS editor:

TextPad: is a full-featured text editor offering a spelling checker, macros, and powerful formatting and file-storage options from Helios Software Solutions.

This is a great program – it’s a powerful text editing tool that’s really comfortable to use. Textpad has a very clean, simple interface that deals only with text – that is, it doesn’t let you change font halfway down the page, or make text underlined or italic; it’s built purely to deal with the content, and does that job EXTREMELY well.

These features are excellent for SAS macro programming and SCL programming. Besides these, Textpad has a built-in compiler for Java which allows for rapid switching to Java coding that is occasionally required.

Below is a screen shot of the editor:

Textpad has many macro features that allows for repetitive actions to be recorded and recycled easily.

Crimson Editor is a professional source editor for Windows Open source from Ingyu Kang and one of the most popular editor available for programmers to use.

This editor also allow programmers to install schematics (define tools) that will highlight sections of your SAS programs.

Below is a screen shot of the editor:

In summary, there are many options to help a SAS programmer increase efficiency, write cleaner code, or make SAS life easier. There are other popular editors such as Emacs but I don’t have a lot of experience using it thus I cannot comment on it properly. Your style of programming will influence the type of editor you will use.

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.

CDISC Clinical Research “A” Terminology

acronym: A word formed from the beginning letters (e.g., ANSI) or
a combination of syllables and letters (e.g., MedDRA) of a name or phrase.
admission criteria:Basis for selecting target population for a clinical trial.
Subjects must be screened to ensure that their characteristics match a list of admission criteria and that none of their characteristics match any single one of the exclusion criteria set up for the study.
algorithm: Step-by-step procedure
for solving a mathematical problem;
also used to describe step-by-step
procedures for making a series of
choices among alternative decisions to
reach a calculated result or decision.
amendment: A written description
of a change(s) to, or formal clarification
of, a protocol.
analysis dataset:An organized collection of data or
information with a common theme arranged in rows and columns and
represented as a single file; comparable to a database table.
analysis variables: Variables used
to test the statistical hypotheses
identified in the protocol and analysis
plan; variables to be analyzed.
approvable letter:An official communication from FDA to an
NDA/BLA sponsor that lists issues to be resolved before an approval can be issued.
[Modified from 21 CFR 314.3;Guidance to Industry and FDA Staff

arm: A planned sequence of elements,
typically equivalent to a treatment

attribute (n): In data modeling,
refers to specific items of data that can
be collected for a class.
audit:A systematic and independent
examination of trial-related activities
and documents to determine whether
the evaluated trial-related activities were
conducted and the data were recorded,
analyzed, and accurately reported
according to the protocol, sponsor’s
standard operating procedures (SOPs),
good clinical practice (GCP), and the
applicable regulatory requirement(s).
[ICH E6 Glossary]
audit report: A written evaluation by
the auditor of the results of the audit.
[Modified from ICH E6 Glossary]
audit trail. A process that captures
details such as additions, deletions,
or alterations of information in an
electronic record without obliterating the original record. An audit trail
facilitates the reconstruction of the
history of such actions relating to the
electronic record.

Source:Applied Clinical Trials

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.

Clinical Trials Terminology for SAS Programmers

Entry Level SAS Programmers

Statistical Programmer:requires him to program using the SAS language to analyze clinical data and produce reports for the FDA

Bioanalyst, Clinical Data Analyst, Statistical Programmer Analyst and SAS Programmer: same as Statistical programmer.

Biotechnology:companies which is a general term used to explain a technique of using living organisms within biological systems to develop micro-organisms for a particular purpose.

protocol:outlined all the procedures and contained detailed plans of the study.

controlled experiment: the clinical trial had patients grouped into different groups such as those in the placebo controlled group which had no active drug. This is how comparisons are made within the controlled clinical trial CFR Part 11:Code of Federal Regulations set by the FDA to regulate food, drug, biologics and device industries. The part 11 specifically deals with the creation and maintenance of electronic records.
Case Report Form or CRF:forms to collect information such as demographic and adverse events. Source Data or the information collected:which include important documents because they contain the core information required to reconstruct the essential capital of the study.
sponsor:company who is responsible for the management, financing and conduct of the entire trial. randomized: subjects that are randomly assigned to groups so that each subject has an equal chance to be assigned to the placebo control
baseline: subjects are assigned to their drug change from baseline:analyses that measure differences between baseline and current visit
placebo or sugar pill:is an inactive substance designed to look like the drug being tested. blinded:they do not know if the drug that they are taking contains the active ingredient.
open-label study:all was out in the open, the drug the subject is assigned to. Pharmacokinetics or PK:analysis of that study showed that with that dosing level, there were high levels of toxicity in the subject.
informed consent: described all the potential benefits and risks involved. TLGs: Tables, Listings and Graphs
trade name:drug name that is collected from the patient and recorded into the source data. For example: Tylenol generic name: refers to its chemical compound. For example: Acetaminophen.
WHO-DRUG: list all the drug names and how they matched to the generic drug names.This dictionary is managed by the World Health Organization MedDRA:This is short for Med (Medical), D (Dictionary), R (Regulatory), and A (Activities).
SAP: Statistical Analysis Plan ANOVA: analysis of variable
confidence interval:gives an estimated range of values being calculated from the sample of patient data that is currently in the study. null hypothesis:lack of difference between the groups in a report
pilot study:perform the same analysis upon an older. DIA: Drug Information Association
CBER: Center for Biologics Evaluation and Research (medical device) CDER: Center for Drug Evaluation and Research (drug)

Source:CDER Acronym List

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.