Category Archives: InForm

Data Management: Queries in Clinical Trials

When an item or variable has an error or a query raised against it, it is said to have a “discrepancy” or “query”.

All EDC systems have a discrepancy management tool or also refer to “edit check” or “validation check” that is programmed using any known programming language (i.e. PL/SQL, C# sharp, SQL, Python, etc).

So what is a ‘query’? A query is an error generated when a validation check detects a problem with the data. Validation checks are run automatically whenever a page is saved “submitted” and can identify problems with a single variable, between two or more variables on the same eCRF page, or between variables on different pages. A variable can have multiple validation checks associated with it.

Errors can be resolved in several ways:

  • by correcting the error – entering a new value for example or when the datapoint is updated
  • by marking the variable as correct – some EDC systems required additional response or you can raise a further query if you are not satisfied with the response

Dealing with queries
Queries can be issued and/or answered by a number of people involved in the trial. Some of the common setups are: CDM, CRA or monitors, Site or coordinators.

Types of Queries

  • Auto-Queries or Systems checks
  • Manual Queries
  • Coding Queries
  • SDV related Queries generated during a Monitor visit
  • External Queries – for external loaded data in SAS format

EDC Systems and Discrepancy Output Examples


Note: All queries are associated to a single data item relevant to that query.


Note: Users are only able to see / perform an action on a query based on their
role and the permissions via Core Config.


Note: Queries are highlighted by a red outline and a Warning icon.


Note: Extensive interfaces for data query.

Query Metrics – It is important to measure the performance of your clinical trials.
Metrics are the same for all clinical studies but not all EDC systems are the same. Standardized metrics encourage performance improvement, effectiveness, and efficiency. Some common metrics are:

  • Outstanding Query
  • Query Answer Time
  • Average Time to Query Resolution
  • Number of closed discrepancies on all ongoing studies

Data management’s experience with data queries in clinical trials

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

Trademarks: InForm is a trademark or registered trademark of Oracle Corporation. Rave is a trademark or registered trademark of Medidata. Timaeus is a trademark or registered trademark of Cmed Clinical Research.

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.

Standard Naming Conventions for InForm Trials

This document is intended to provide a common set of rules to apply to the naming of clinical trials build using InForm EDC system.

Why use naming conventions?

Naming objects consistently, logically and in a predictable way will distinguish similar records from one another at a glance, and by doing so will facilitate the storage and retrieval of records, which will enable users to browse clinical objects more effectively and efficiently. Naming records according to agreed conventions should also make object naming easier for colleagues because they will not have to ‘re-think’ the process each time.

It has been said that InForm follows the “Hungarian” notation because it is one of Microsoft’s “Best Practices” for .Net standards when defining objects (the code to support those objects use it).

Component Prefix
Form (e.g., frmDemo…) frm
Section sct
Itemset its
Radio Control rdc
Item itm
Pulldown Control pdc
Text box txt
Date and time dtm
Group Control grp
Checkbox chk
Calculated Control cal
Simples smp
Study Element elm
Codelist cl
Study Event evt
Codelist Item citm
Workflow Rule wr
Global Conditions gc
Data Entry Rules (e.g., rulDMConsDTCompare) rul
DataType Prefix
Boolean bln
Byte byt
Character chr
Date dtm
Decimal dec
Double Precision dbl
Integer int
Long Integer lng
Object obj
Short Integer sht
Single Precision sng
String str
User-defined Type udt
Object Prefix
Button btn
CheckBox chk
ComboBox cbo
Control ctr
DataSet ds
DataTable dt
Form frm
GroupBox grp
Label lbl
ListBox lst
PictureBox pic
RadioButton rdb
String str
TextBox txt

Remember keep it consistent. This means that you stick to one particular pattern through out your clinical project. This also includes the words you use for namespaces, classes, methods, interfaces, properties and variables. A prerequisite is that they should be meaningful, significant, descriptive and easily understood with respect to purpose and functionality by anyone who reads the source code.

Happy Programming!

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.

A New Way to Collect Data – CDASH

There is a general consensus that the old paper-based data management tools and processes were inefficient and should be optimized. Electronic Data Capture has transformed the process of clinical trials data collection from a paper-based Case Report Form (CRF) process (paper-based) to an electronic-based CRF process (edc process).

In an attempt to optimize the process of collecting and cleaning clinical data, the Clinical Data Interchange Standards Consortium (CDISC), has developed standards that span the research spectrum from preclinical through postmarketing studies, including regulatory submission. These standards primarily focus on definitions of electronic data, the mechanisms for transmitting them, and, to a limited degree, related documents, such as the protocol.

Clinical Data Acquisition Standards Harmonization (CDASH)

The newest CDISC standard, and the one that will have the most visible impact on investigative sites and data managers, is Clinical Data Acquisition Standards Harmonization (CDASH).

As its name suggests, CDASH defines the data in paper and electronic CRFs.

Although it is compatible with CDISC’s standard for regulatory submission (SDTM), CDASH is optimized for data captured from subject visits, so some mapping between the standards is required. In addition to standardizing questions, CDASH also references CDISC’s Controlled Terminology standard, a compilation of code lists that allows answers to be standardized as well.

Example: Demographics (DM)

Description/definition variable name Format
Date of Birth* BRTHDTC dd MMM yyyy
Sex** SEX $2
Race RACE 2
Country COUNTRY $3

*CDASH recommends collecting the complete date of birth, but recognizes that in some cases only BIRTHYR and BIRTHMO are feasible.

* *This document lists four options for the collection of Sex: Male, Female, Unknown and Undifferentiated (M|F|U|UN). CDASH allows for a subset of these codelists to be used, and it is typical to only add the options for Male or Female.

The common variables: STUDYID, SITEID or SITENO, SUBJID, USUBJID, and INVID that are all SDTM variables with the exception of SITEID which can be used to collect a Site ID for a particular study, then mapped to SITEID for SDTM.

Common timing variables are VISIT, VISITNUM, VISDAT and VISTIM where VISDAT and VISTIM are mapped to the SDTM –DTM variable.

Note: Certain variables are populated using the Controlled Terminology approach. The COUNTRY codes are populated using ISO3166 standards codes from country code list. This is typically not collected but populated using controlled terminology.

Each variable is defined as:

  • Highly Recommended: A data collection field that should be on the CRF (e.g., a regulatory requirement).
  • Recommended/Conditional: A data collection field that should be collected on the CRF for specific cases or to address TA requirements (may be recorded elsewhere in the CRF or from other data collection sources).
  • Optional: A data collection field that is available for use if needed

The CDASH and CDICS specifications are available on the CDICS website free of charge. There are several tool available to help you during the mapping process from CDASH to SDTM. For example, you could use Base SAS, SDTM-ETL or CDISC Express to easily map clinical data to SDTM.

In general you need to know CDISC standards and have a good knowledge of data collection, processing and analysis.

With the shift in focus of data entry, getting everyone comfortable with using a particular EDC system is a critical task for study sponsors looking to help improve the inefficiencies of the clinical trial data collection process. Certainly the tools are available that can be used to help clinical trial personnel adapt to new processes and enjoy better productivity.

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.

Central Designer aCRF Generation

aCRF casebook ;- PDF file

1. Project Explorer – click on the 2nd level study name

2. File ->; Annotated Study Book Options

3. Uncheck Time and Events table

4. Uncheck Study Object Description Tables
5. Change date variable format to match eCRF ;map, setting is not noted on aCRF output

6. File ->; View Annotated Study Book

7. Pop up screen, click Print in lower right

8. Select Printer – Adobe PDF (single click)
9. Click Preferences

10. Click on Layout tab
11. Change to Landscape

12. Click on Advance tab in lower right

13. Change Scaling as needed, check PDF output as needed

14. Select Print, wait for file name box, aCRF is done.

Time and Events Table – CSV file

1. File ->; Annotated Study Book Options

2. Check Time and Events Table

3. File ->; View Annotated Study Book

4. Click on Save Time & Events as button lower left

5. Give it a file name

Note: ;Steps 1-5 have to be repeated every time as aCRF defaults back to base settings after you close out the study.

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.

InForm Trial – Complete Trial Removal

Remove a Trial from InForm

1-Open the command promptCommand Prompt

2-if the InForm Service has not started yet, you can start it by entering the following command:

net start pfservice  

NOTE: If you are using InForm Architect, the service may has already be started.

3-Once the server or service is started (completed successfully), you will then remove the trial by entering:

pfadmin remove trial e.g. pfadmin remove trial proto999

NOTE:  InForm can not remove a running trial. 

4-    Enter the following command prior to the remove command above:

pfadmin stop server proto999 /trials

Removal of a trial from the system

It is necessary to remove trials off your system once you have completed the e-crfs to ensure that Architect is working efficiently as you develop more trial e-crfs. 

1- Open the  Data Sources (ODBC)
2- Click on the tab System DSN
3- Highlight the trial that you want to remove.
4- Click the Remove button.

A message will pop up that asks you if you are sure you want to remove the trial’s data source, click Yes button. Click OK button to close ODBC.

Remove a Trial from the Oracle Database

If you are doing trial development work in Architect, you may need to stop the InForm Service before doing these steps. Enter the following command:

net stop pfservice [enter]

sqlplus useruid/pwduid [enter]

SQL*Plus is running now

From here enter the following two commands:

 drop user trialuid cascade;


 To exit SQL*Plus enter:  exit

The trial has been completely removed from the system. Doing this can help keep the system ‘clean’ as well as gets the system ready to fully reinstall this trial again if you needed to fully remove it.

NOTE: If you wish, you may verify that the trial is really gone in Oracle by starting TOAD or PLSQL Developer and check the USER object/table.

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.