Tag Archives: data standards

Case Study 3: Out-of-Box Solution

The Scenario:

The Sponsor required a solution to effectively manage and control users (internal and external).
RA eClinica Solution:

    • RA eClinica collaborated with the Sponsor to develop and implement a user management system that involved training tracking record (LMS), user access request, Role-based access control
    • Develop, deploy and host the clinical documentation service and provide customer support.

Ra eClinica Results:

    • Development of an electronic tool to manage the program and provide ongoing operational management support..
    • Reports are made accessible based on permission on a web browser CFR-Part 11 compliance is maintained on security and privacy of data.
    • Reports are XML-tagged for further integration with in-house systems and third party service providers,
    • Integrated Help desk support system

Anayansi gamboa - Out of the box solutions by RA eClinica

RA eClinica is a established consultancy company for all essential aspects of statistics, clinical data management and EDC solutions. Our services are targeted to clients in the pharmaceutical and biotech sector, health insurers and medical devices.

For discussion about our services and how you can benefit from our SMEs and cost-effective implementation CDISC SDTM clinical data click here.

Advertisements

Solving Data Collection Challenges

Cross-partnership between sponsors and CROs for the collection and analysis of clinical trial data are complex. As a result there are a number of issues encountered during the running of  trial.

As with many projects, standardization projects like CDISC is a huge undertake. It requires resources, technology and knowledge-transfer. The industry (FDA for example) has been working on standardization for years but on September 2013, it became official, in which the FDA released a ‘Position Statement‘.

 Data Collection

According to the WHO, data collection is defined as the ongoing systematic collection, analysis, and interpretation of health data necessary for designing, implementing, and evaluating public health prevention programs.

Sources of data: primarily case report books or (e)CRF forms, laboratory data and patient report data or diaries.

 Challenges of data collection

It is important for the CROs / service providers to be aware of the potential challenges they may face when using different data collection methods for partnership clinical studies. Having several clients does not mean having several standards or naming conventions. This is the main reason why CDISC is here. So why are many CROs or service providers not using CDISC standards?

Another challenge is time limitations. Some clinical trials run for just a few weeks / months.

It may be found difficult to understand the partnership in the amount of time they have. Hence, most CROs and service providers prefer to perform manual mapping at the end of the trial, hence, re-work and manual work.

Funding also plays a key challenge for CDISC-compliance data collection study. Small researchers or biotechnology companies that do not have the resources in-house, out-sourced this task to CROs or service providers and are not interested whether it is compliance as long as it is save them money. But would it save money now instead of later in the close-out phase?

Anayansi Gamboa - Data Status

 

 

 

 

 

If there is a shortage of funding this may not allow the CRO or service provider all the opportunities that would assist them in capturing the information they need as per CDISC standards.

We really don’t have the level of expertise or the person dedicated to this that would bring, you know, the whole thing to fruition on the scale in which it’s envisioned – Researcher

Role of the Library

There is a clear need for libraries (GL) to move beyond passively providing technology to embrace the changes within the industry. The librarian functions as one of the most important of medical educators. This role is frequently unrecognized, and for that reason, too little attention is given to this role. There has been too little attention paid to the research role that should be played by the librarian. With the development of new methods of information storage and dissemination, it is imperative that the persons primarily responsible for this function should be actively engaged in research. We have little information at the present time as to the relative effectiveness of these various media. We need research in this area. Librarians should assume an active role in incorporating into their area of responsibility the various types of storage media. [http://www.ncbi.nlm.nih.gov/pmc/articles/PMC232677/]

Review and Revise

At the review and revise stage it might be useful for the CRO or service provider to consider what the main issues are when collecting and organizing the data on the study. Some of these issues include: ensuring sponsors, partners and key stakeholders were engaged in the scoping phase and defining its purpose; the objectives have been considered; the appropriate data collection methods have been used; the data has been verified through the use of multiple sources and that sponsors have approved the data that is used in the final clinical data report.

Current data management systems must be fundamentally improved so that they can meet the capacity demand for secure storage and transmission of research data. And while there can be no definitive tools and guideline, it is certain that we must start using CDISC-standards from the data collection step to avoid re-inventing the wheel each time a new sponsor or clinical researcher ask you to run their clinical trial.

RA eClinica is a established consultancy company for all essential aspects of statistics, clinical data management and EDC solutions. Our services are targeted to clients in the pharmaceutical and biotech sector, health insurers and medical devices.

The company is headquarter in Panama City and representation offices with business partners in the United States, India and the European Union.  For discussion about our services and how you can benefit from our SMEs and cost-effective implementation CDISC SDTM clinical data click here.

Project Plan: CDISC Implementation

CDISC standards have been in development for many years. There are now methodologies and technologies that would make the transformation of non-standard data into CDISC-compliance with ease. Clinical trials have evolved and become more complex and this requires a new set of skills outside of clinical research – Project Management.

As with many projects, CDISC is a huge undertake. It requires resources, technology and knowledge-transfer. The industry (FDA for example) has been working on standardization for years but on September 2013, it became official, in which the FDA released a ‘Position Statement‘.

So what is CDISC? We can say that it is way of naming convention for XPT files, or field names naming conventions or rules for handling unusual data. Currently, there are two main components of CDISC: SDTM (Study Data Tabulation Model) and aDAM (Analysis Data Model).

As a project manager and with the right tool, you can look to a single source project information to manage the project through its life-cycle – from planning, through execution, to completion.

1) Define Scope: This is where you’re tested on everything that has to do with getting a project up and running: what’s in the charter, developing the preliminary scope, understanding what your stakeholders need, and how your organization handles projects.

The scope document is a form of a requirement document which will help you identify the goals for this project. It can also be used as a communication method to other managers and team members to set the appropriate level of expectations.

The project scope management plan is a really important tool in your project. You need to make sure that what you’re delivering matches what you wrote down in the scope statement.

2) Define Tasks: we now need to document all the tasks that are required in implementing and transforming your data to CDISC.

Project Tasks  (Work packages) Estimates (work unit)
Initial data standards review 27
Data Integrity review 17
Create transformation models 35

The work breakdown structure (wbs) provides the foundation for defining work as it relates to project objectives. The scope of work in terms of deliverables and to facilitate communication between the project manager and stakeholders throughout the life of the project. Hence, even though, preliminary at first, it is a key input to other project management processes and deliverables.

3) Project Plan: Once we completed the initiation phase (preliminary estimates), we need to create a project plan assigning resources to project and schedule those tasks. Project schedules can be presented in many ways, including simple lists, bar charts with dates, and network logic diagrams with dates, to name just a few. A sample of the project plan is shown below:

project plan sample
image from Meta‐Xceed paper about CDISC

4) Validation Step: Remember 21 CFR Part 11 compliance for Computer Systems Validation? The risk management effort is not a one-time activity on the project. Uncertainty is directly associated with the change being produced by a project. The following lists some of the tasks that are performed as it pertains to validation.

  • Risk Assessment: Different organizations have different approaches towards validation of programs. This is partly due to varying interpretations of the regulations and also  due to how different managers and organizations function. Assess the level of validation that needs to take place.
  • Test Plan: In accordance with the project plan and, if not, to determine how to address any deviation. Test planning is essential in:  ensuring testing identifies and reveals as many errors as possible and to acceptable levels of quality.

test plan-cdisc

  • Summary Results: This is all the findings documented during testing.

An effective risk management process involves first identifying and defining risk factors that could affect the various stages of the CDISC implementation process as well as specific aspects of the project. riskplan

5) Transformation Specification: Dataset transformation is a process in which a set of source datasets and its variables are changed to  meet new standard requirements. Some changes will occur during this step: For example, variable name must be 8 chars long. The variable label must not be more than 40 chars in length. Combining values from multiple sources (datasets) into on variable.

6) Applying Transformation: This is done according to specification however, this document is active during the duration of a project and can change. There are now many tools available to help with this tasks as it could be time consuming and resource intensive to update the source code (SAS) manually. Transdata, CDISCXpres, SAS CDIDefine-it; just to name a few.

7) Verification Reports: The validation test plan will detail the specific test cases that need to be implemented  to ensure quality of the transformation. For example, a common report is the “Duplicate Variable” report.

8) Special Purpose Domain: CDISC has several special purpose domains: CO (comments), RELREC (related records or relationship between two datasets) and SUPPQUAL (supplemental qualifiers for non-standards variables).

9) Data Definition Documentation: In order to understand what all the variables are and how they are derived, we need a annotation document. This is the document that will be included during data submission. SAS PROC CONTENTS can help in the generation of this type of metadata documentation. The last step in the project plan for CDISC implementation is to generate the documentation in either PDF  or XML format.

CDISC has established data standards to speed-up data review and FDA is now suggesting that soon this will become the norm. Pharmaceuticals, bio-technologies companies and many sponsors within clinical research are now better equipped to improve CDISC implementation.

Need SAS programmers? RA eClinica can help provide resources in-house / off-shore to facilitate FDA review by supporting CDISC mapping, SDTM validation tool, data conversion and CDASH compliant eCRFs.

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

CDISC Will Be Required by Kit Howard

Over the past decade or so, a tremendous amount of development work has gone into creating standards for data to be submitted electronically to the FDA. There are those, however, who question whether these standards will ever be required, and believe that unless the FDA requires them, the standards don’t have to be adopted. Indeed, in the absence of such a requirement, there is sometimes a good business case for not adopting the standards, for example, if the company already has their own robust standards, or when the exit strategy is to achieve proof of concept and then sell. The writing is on the wall, however. Standards will be required, at least for data submitted to FDA, and that includes CDER (drugs), CBER (biologics) and CDRH (devices). This article will present evidence of that, and cover sources for the agency’s expectations.

In February 2012, FDA issued a Notice of Proposed Rule Making called Electronic Submission of Data From Studies Evaluating Human Drugs and Biologics. This Notice outlined the FDA’s intention to require that all data submitted in support of clinical trials would have to be sent in “an electronic format that FDA can process, review, and archive.” This will cover new drug applications (NDAs, usually submitted to CDER), biologic license applications (BLAs, usually submitted to CBER and sometimes jointly to CDRH), and abbreviated NDAs (ANDAs, usually submitted to CDER and CBER, and sometimes jointly to CDRH), and all of the associated supplements and amendments. Later in the Notice, it states that “FDA’s proposed rule would address the submission of study data in a standardized electronic format.” While CDISC is not specifically mentioned, it is referenced in several other FDA documents.

There isn’t currently a rule specifically mentioning CDRH requiring standards, but there is a very strong commitment internally to adopting CDISC, so the probability is good that there will eventually be some kind of regulatory requirement.

Guidance
Providing Regulatory Submissions in Electronic Format — Standardized Study Data http://www.fda.gov/downloads/Drugs/ GuidanceComplianceRegulatoryInformation/ Guidances/UCM292334.pdf

FDA is issuing a series of guidances designed to help sponsors submit data electronically, and the most recent is a draft guidance titled Providing Regulatory Submissions in Electronic Format — Standardized Study Data. Its primary purpose is to state that data submitted to the agency must be submitted electronically and in a standardized structure. The draft was issued in February, and the comments period closed on April 23.

The guidance covers a much wider set of submissions than the proposed rule, including both clinical and nonclinical data submitted in investigational new drug applications (INDs), NDAs, ANDAs and BLAs, and also medical device data in investigational device exemptions (IDEs), pre‐ marketing notifications (510(k)s), and premarketing approval applications (PMAs). It also includes all supplements and amendments. It effectively means that all clinical and nonclinical data going to CDER, CBER and CDRH are covered.

The guidance describes the kinds of data the agency receives and why it will require that the data be standardized. The reasons are much as you’d expect ‐ they can receive, import, analyze and report on the data much more efficiently and spend much less time working out what data are where. The guidance then goes on to discuss processes for data that were captured in a standardized format and those that weren’t.

It is important to note that the guidance does not state that CDISC standards must be used, but rather says that standards must be used, and to see the FDA’s standards page for the specific standards that are currently required. This permits changes to the standards to happen without having to update the guidance. Most of the data‐specific examples use CDISC, and the strong hint is that this is what should be used.

Here are some key points:

  • The guidance clearly states that collecting data in the same standardized format in which they will be submitted is preferable to converting after collection, a practice that is discouraged.
  • For both clinical and nonclinical studies, the sponsor should outline their standards plan in the IND or IDE. This means that the standards strategy must be established before the clinical program starts. This has implications for companies that currently expect to do only a few studies and license the product out ‐ we should expect to see conformance to standards become a part of the assessment of quality of study data.
  • When study data are submitted, the cover letter should include a description of the standards used. The guidance specifically states that it does not define what should be collected, just that everything that is collected should be submitted in a standardized fashion.
  • Each submission should contain a Reviewers’ Guide that orients the user to the structure and content of the datasets. There is no guidance currently available as to the desired content of the guide at this time.
  • Controlled terminologies must be used, and the submission must note what ones were used. The guidance discusses the value of such terminologies.
  • In cases where non‐standard data are mapped to the standards, any variable that cannot be fully or exactly mapped must be documented and explained. Data validation as per the guidance is the process of making sure that the data conform to the standards rules. It is one aspect of data quality. There are 2 types of validation rules ‐ technical validation rules (e.g., is the variable name correct) and business validation rules (do the data make sense, e.g., is the heart rate compatible with life?).
  • The guidance notes that different parts of the FDA are adopting standards at different rates, and there‐ fore there may be exceptions to the requirements. Sponsors can request meetings with the review division to determine what the requirements will be for their studies/submissions.

Online Resources for FDA’s Standards Expectations

The FDA is developing a robust set of online resources to help organizations understand and adopt standards in the way that is most useful for all parties involved. Most can be found via the primary data standards page, which is FDA Resources for Data Standards, http://www.fda.gov/ForIndustry/DataStandards/ default.htm, and can be accessed from the main FDA page by clicking on For Industry, and scrolling down to the For Industry Topics to Data Standards. Note that the FDA websites are reorganized periodically, so this may change in time. Among other things, this includes links to the pages for the Structured Product Labeling and Individual Case Safety Report (terminology below), the Study Data Standards page (discussed below), and a link to the FDA’s Data Council, which has overall responsibility for FDA standards. Be aware that there are no links back to the Data Standards page from any of the linked pages, which is rather annoying.

This part of this article lists and describes some of the resources that are available on this page a number of them that may be of particular use.

The Study Data Standards page has the largest number of standards resources. Its url is: http://www.fda.gov/ForIndustry/DataStandards/StudyDataStandards/default.htm. Here are some of the resources you can find there.

Study Data Specifications: a highly technical description of the software format the datasets should use (SAS XPORT), the file naming conventions, conventions for splitting large files, the format for the data tabulations (CDISC SDTM (human trials) or SEND (animal trials)), and the structure for data listings and patients profiles (this is quite limited). While CDISC ADaM is not specified, there are a number of rules for structuring the analysis datasets, including the need to provide both text and numeric versions of coded variables, and dates should be numeric rather than ISO8601. A define.xml is required that describes the dataset structures, an annotated CRF must be included, and a folder structure for the files is defined.

Study Data File Format Standards: a list of the file for‐ mats and what can be used to send what to whom (e.g., send study datasets to CDER, CBER and CDRH using SAS XPORT, send SDTM and ADaM define.xml to CBER and CDER using XML v1.0)

Study Data Exchange and Analysis Standards: speci‐ fies SDTM versions 1.1 and 1.2, the SDTM IG v3.1.1 and 3.1.2, SEND IG v3.0, and ADaM v2.1.

Study Data Terminology Standards: these are the code lists and dictionaries that should be used, including CDISC Terminology v 2011‐06‐10 or later, MedDRA v8 or later, CDRH Device Problem codes, and others.

Study Data Validation Rules: this is a list of rules to which submission data must conform, or it will be rejected by the agency’s data uploader.
There are also center‐specific pages that may be useful.

CBER: http://www.fda.gov/BiologicsBloodVaccines/ DevelopmentApprovalProcess/ucm209137.htm. This page has a very specific list of the steps you need to take to be ready to submit data to CBER in electronic format. It is critical that sponsors review and follow this list, as it is the first thing that the CBER contact (Amy Malla) will ask you. CBER started accepting CDISC‐formatted data in December 2010.

CDER: http://www.fda.gov/Drugs/DevelopmentApprovalProcess/FormsSubmissionRequirements/ElectronicSubmissions/ ucm248635.htm. The webpage starts with the following statement:

CDER strongly encourages IND sponsors and NDA applicants to consider the implementation and use of data standards for the submission of applications. Such implementation should occur as early as possible in the product development lifecycle, so that data standards are accounted for in the design, conduct, and analysis of studies.

It can’t get much blunter than that. It then references the Study Data Specifications document discussed above, the CDISC SDTM, SEND and ADaM, and includes a list of Data Standards Common Issues that lists the problems that CDER most commonly sees with respect to the standardization of submissions. Sponsors can use this to ensure they do not commit these errors. This document also suggests that CDASH‐style CRFs are best for simplifying the process of creating SDTM domains.

CDER began accepting CDISC‐formatted data some number of years ago.

  • CDRH: there isn’t a standards‐specific page for CDRH but they started accepting CDISC‐formatted data in May 2011. The same person (Amy Malla) is the contact for submitting data electronically to CDRH, and the list of steps on the CBER page is intended for use for CDRH data as well. CDRH has some standards terminologies defined that sponsors are ex‐ pected to use.

Some other resources that may be helpful are as follows.

  • A consolidated list of guidances (both draft and final) relating to electronic submissions http://www.fda.gov/Drugs/GuidanceComplianceRegulatoryInformation/Guidances/ucm064994.htm
  • FDA terminology hosted by the National Cancer Institute’s Enterprise Vocabulary Services (the same organization that hosts CDISC’s controlled terms) http://www.cancer.gov/cancertopics/cancerlibrary/ terminologyresources/fda
  • Structured product labeling terms, in‐ cluding Mechanism of Action, Physiologic Effect, Structural Class and Problem List Subset
  • Unique Ingredient Identifier (UNII)
  • Individual Case Safety Report
  • CDRH’s terminology, including Event Problem Codes that cover Patient Prob‐ lem Codes, Device Component Codes and Device Problem Codes. Note that these are listed with the link of Center for Devices and Radiological Health, rather than by the name of the code lists.

For the sake of completeness, here are the links for the CDISC standards

These are currently available resources, but of course this will grow as the agency develops more.

Kit Howard is a Clinical Data Standards, Quality and Management consultant for Kestrel Consultants.

Reference: The Proposed Rule

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

What is Clinical Reviewer?

Clinical Review on iPad

  1. CRF Images View CRF (Case Report Form) data with pinch zoom.
  2. SAS Datasets Search and view data exported from SAS datasets.
  3. DEFINE.XML Import meta data directly from DEFINE.XML.
  4. Control Terminology View all metadata including coded terms defined in DEFINE.XML
  5. Secure Data – Data transferred to local memory viewed in “Airplane” mode with self deleting expiration.

Clinical data can be imported from standard CDISC DEFINE.XML format directly onto Clinical Reviewer app on iPad. Take advantage of the multi-touch interface to view Case Report Form or SAS datasets directly. Metadata including variable and value level metadata is viewable as defined in DEFINE.XML.

Watch this tutorial and see for yourself…

-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: Meta-x

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.

Assigning Libraries to Access and Store SAS® Data

Use SAS learning software to learn how to assign libraries to access and store SAS data.

-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: http://support.sas.com/learn/ondemand/professionals

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.

CDER Common Data Standards Issues Document

 Source: FDA (Version 1.1/December 2011)

 The Center for Drug Evaluation and Research (CDER) is strongly encouraging sponsors to submit data in standard form as a key part of its efforts to continue with advancement of review efficiency and quality. CDER has been collaborating with CDISC, a standards development organization (SDO), in the development of standards to represent study data submitted in support of regulatory applications. Study data standards are vendor-neutral, platform-independent, and freely available via the CDISC website (http://www.CDISC.org). CDISC study data standards include SDTM (Study Data Tabulation Model) for representation of clinical trial tabulations, ADaM (Analysis Data Model) for clinical trial analysis files, and SEND (Standard for Exchange of Non-clinical Data) for representation of nonclinical animal toxicology studies tabulations.

CDER has accepted SDTM datasets since 2004; however, due to differences in sponsor implementation of the standard, CDER has observed significant variability in submissions containing “standardized” electronic clinical trial data. CDER has received numerous “SDTM-like” applications over the past several years in which sponsors have not followed the SDTM Implementation Guide. Furthermore, aspects of particular sponsor implementations have actually resulted in increased review difficulty for CDER reviewers. In addition, some sponsors have wrongly believed that the submission of SDTM datasets obviates the need for the submission of analysis datasets, resulting in the delay in review due to the need to request these datasets. The goal of this document is to communicate general CDER preferences and experiences regarding the submission of standardized data in order to aid sponsors in the creation of standardized datasets for both tabulation datasets and analysis datasets. .

This document is not intended to replace the need for sponsors to communicate with review divisions regarding data standards implementation approaches or issues, but instead, it is designed to complement and facilitate the interaction between sponsors and divisions. Because of specialized needs in different divisions, it is likely that divisions may have additional requests or preferences. When uncertainty exists regarding a particular data standards implementation or submission issue, the sponsor should contact the review division to discuss further.

The complete documentation on CDER data standards in .pdf version can be found at the following link: CDER

 


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.