Sunday, September 20, 2009

Case Report Tabulations for The FDA Submission

The Case Report Tabulation (CRT) is the collection of the annotated case report form (CRF), SAS® datasets, metadata, and source programs that comprise a portion of the NDA package submitted to the FDA. The FDA uses it when reviewing submissions. Review starts with the Define document which contains metadata describing the datasets, variables, and values. It is all tied together using internal and external hyperlinks, bookmarks, and destinations to make it easily navigable1.

The CRT is essentially a collection of data and documentation for a study. It contains features such as bookmarks and links to allow reviewers to easily navigate the submission. For consistency, there are guidelines from FDA1 and CDISC defining the components though the guidelines are limited in scope.

We need to create Define Document (define.pdf or define.xml) as a part of CRT.
  • Each dataset is a single SAS transport file and, in general, includes a combination of raw and derived data.

  • Each CRF domain (e.g., demographics, vital signs, adverse events) should be provided as a single dataset.

  • In addition, datasets suitable for reproducing and confirming analyses may also be needed.

  • Patient profiles can also be provided as PDF files


    In 2003, FDA …. Interpreted….. 21 CFR 314.50(f) (1) as defining CRTs to include2:


  • Study Data Tabulations
    Statistical Analysis Datasets
    Data Listings
    Patient Profiles

    Draft eCTD Guidance: Case Report Tabulations

    Data tabulations ___Data tabulations datasets ___Data definitions

  • Data listings ___Data listing datasets ___Data definitions

  • Analysis datasets __Analysis datasets ___Analysis programs ___Data definitions

  • Subject profiles

  • IND safety reports

Data Tabulations:

  • Data tabulations are datasets in which each record is a single observation for a subject.”

  • Specifications are located in the Study Data Tabulation Model (SDTM) developed by CDISC at www.cdisc.org/models/sds/v3.1/index.html. *Each dataset is provided as a SAS Transport (XPORT) file.
Data Listings:

  • “Data listings are datasets in which each record is a series of observations collected for each subject during a study or for each subject for each visit during the study organized by domain.”


  • Currently, there are no further specifications for organizing data listing datasets.


  • General information about creating datasets can be found in the SDTM implementation guides referenced in the data tabulation dataset specifications.


  • Each dataset is provided as a SAS Transport (XPORT) file.
Analysis datasets:

  • “Analysis datasets are datasets created to support specific analyses. Programs are scripts used with selected software to produce reported analyses based on these datasets.”


  • Each dataset is provided as a SAS Transport (XPORT) file.


  • Programs should be provided as both ASCII text and PDF files and should include sufficient documentation to allow a reviewer to understand the submitted programs.


  • It is not necessary to provide analysis datasets and programs that will enable the reviewer to directly reproduce reported results using agency hardware and software. Currently, there are no other additional specifications for creating analysis datasets.
Subject Profiles:
  • “Subject profiles are displays of study data of various modalities collected for an individual subject and organized by time.”

  • Each individual patient’s complete patient profile is in a single PDF file or a book-marked section of a single PDF file for all patients.


References: http://www.lexjansen.com/pharmasug/2009/rs/rs08.pdf
http://www.amstat.org/meetings/fdaworkshop/presentations/2005/P07_Christiansen_CDISC.ppt http://www.cdisc.org/stuff/contentmgr/files/0/f56015f6c1c01e6aa55767d9d25bddb5/misc/officeofbusinessprocesssupport.pdf

DLP (Data LifeCycle Plan)


The DLP (Data LifeCycle Plan) guides an organization and serves as a blueprint for how to create every type of data across all therapeutic areas and functional specialties. Howard describes the DLP as "an overall document that says here are the things you need to think about." In some DLPs, there might be more than 15 chapters, each controlled by a group of domain experts.


Standard operating procedures (SOPs) typically cover process. DLPs, in contrast, are technical specifications about what happens to the data. Both SOPs and DLPs should be subject to similar governance. The DLP creates a framework for discussions that do occur on their own, but it forces them to an earlier stage of the process.



Here's a sample chapter of a DLP for demographic data from Kestrel Consultants, Inc.

The Future of ODM, SDTM and CDISC


Setting The Record Straight: The Future of ODM, SDTM and CDISC
November 05, 2008
By Rebecca Kush, Frank Newby, David Iberson-Hurst, & Amanda J de Montjoie, CDISC


When rumors increase, and when there is an abundance of noise and clamor, believe the second report. Alexander Pope, 1688–1744


In recent weeks, there have been a number of rumors about the Clinical Data Interchange Standards Consortium CDISC standards and their continued use by the Food and Drug Administration (FDA). These whispers suggest that the Study Data Tabulation Model (SDTM) standard is being replaced and that the Operational Data Model (ODM) should no longer be used. The rumors have caused confusion at best and fear of standards abandonment at worst. This is a second report—an attempt to clarify what’s happened and how the industry should move forward.


CDISC, to state the obvious, is a global standards organization. While the FDA plays a vital role in the drug development industry in the U.S., there are other global stakeholders that use CDISC standards. CDISC’s influence extends as far east as Japan, Australia and China—and is well established in Europe.


An International Agenda

Just as biopharmaceutical communities are expanding globally, CDISC is being asked to meet with regulatory authorities in China and with academic representatives in Singapore, India and Brazil. CDISC has Liaison A status with the International Standards Organization Technical Committee 215 and works closely on global standards harmonization with CEN, ISO and HL7 as a member of the Joint Initiative Council.


Friday, September 18, 2009

Define.XML

Define.xml which generally describes what are we submitting to FDA .. like case Report Tabulations ( SAS datasets in XPT format, annotated CRF’s and the variables (metadata)) in a machine readable format….. In simple words it is .....Data and Metadata in Machine-Readable Format. It is considered as the standard process for submitting metadata to FDA and other regulatory bodies….



























Monday, August 31, 2009

MedDRA and WHODrug Coding

Though there are other Coding dictionaries available along with MedDRA (ex: COSTART and WHOART), MedDRA dictionary is typically used in the US for Adverse Events coding.

AE\MedDRA coding is not the SAS programmers work; it is usually done by medical coder or database programmer. Coding basically involves a process of finding a dictionary term that matches the verbatim term reported on the CRF, and getting the other related dictionary derived variables useful for the analysis like System Organ Class (SOC), Preferred Term (PT) and Lowest Level Term (LLT), etc.

Some times this process may take more time than expected, because Misspellings and other differences would delay the process of coding. In that case, person responsible for coding has to look for the dictionary term that which is the best possible match from the MedDRA dictionary.

So the question here comes is what SAS programmer can do in this process.

Here is the Answer….

SAS programmer has to work hard to make this process successful. In other words he is also a key player in this game.

SAS Programmer provides a list of reported AE terms on the CRF to the medical coder in a flat file/excel file, who then search for a best possible match and related terms for AE term of CRF in the MedDRA dictionary. He then enters them in the supplied flat/excel file and returns back to the SAS programmer.

The next SAS programmer duty is to assign the Dictionary derived Term, SOC, LLT and PT to the AE Terms in the AE dataset by merging. (Use Proc SQL or Simple Merge)

MedDRA dictionary gets updated twice a year, so it is important to be aware of the version used for the coding.

If the data is clean (Assuming that there are no misspelling of AE terms or other problems then MedDRA coding is easy…. What you have to do is locate the MedDRA SAS dataset and then merge the MedDRA dataset with the AE dataset using the preferred term.
















Making Code Review Painless

ABSTRACT:
Code review is an essential step in the development of concise and accurate SAS® programs. It is a required verification step in performing validation in a regulated environment. This paper will present techniques and a macro that can be freely downloaded to automate this task. The %coderev macro will perform many of the common tasks during a code review including:

1. Spell checking headers and comments
2. Reviewing all input and output datasets of the program
3. Comparing defined macro variables versus macro variable usage
4. Checking for multiple macro calls that are not in a macro library
5. Evaluating hard code logic
6. Evaluating sort order of all datasets

These tasks are normally performed by an independent reviewer instead of the original programmer. By automating the tasks, the code review process will ensure that the smallest mistake can be captured through reports to ensure the highest quality and integrity. What normally is a dreaded task can now be done with ease.
Thanks to Sy Truong, Meta-Xceed, Inc, Fremont, CA

Monday, August 24, 2009

SAS Instructor Tips: Programming

SAS Instructor Tip: Programming

Featured Instructor: Cynthia Johnson

How do I combine my SAS data sets and eliminate duplicate rows at the same time?

SAS Instructor Cynthia Johnson responds ...




SAS Instructor Tip: Programming

Featured Instructor: Kent Reeve

What happens when you forget the period on an informat when using formatted input?




SAS Programming Tips[1]



SAS/GRAPH Tip: Controlling the Graph Axis

SAS Instructor Cynthia Zender shows you how to control the graph axis through a feature of using the AXIS statement.



SAS ODS Tip: Creating Page X of Y Page Numbers
SAS Instructor Cynthia Zender shows you how to use the SAS ODS ESCAPECHAR to create a "Page X of Y Page Numbers"



SAS ODS Tip: Creating a Table of Contents

SAS Instructor Cynthia Zender shows you how to create a table of contents using the CONTENTS= Option with ODS RTF and ODS PDF destinations.



SAS ODS Tip: Controlling the Width of Cells

SAS Instructor Cynthia Zender shows you how to control the width and spacing of cells using STYLE=Overrides that have been designed for the ODS destinations that support STYLE.



SAS Programming Tip: Subsetting Data with a WHERE Statement

SAS Instructor David Ghan shows you how to to use a WHERE statement to subset your data.




Learn how to view SAS dataset labels without opening the dataset directly in a SAS session. Easy methods and examples included!

Quick Tip: See SAS Dataset Labels Without Opening the Data Quick Tip: See SAS Dataset Labels With...