Numbering System

Progress Toward Standardization of Submissions with the Electronic Common Technical Document and the Evolving Standardization of Clinical Data Susan Bairnsfather, PharmaNet, Inc, Cary, NC ABSTRACT The FDA has posted the electronic Common Technical Document (eCTD) in parallel to their 1999 NDA electronic guidance on their website. The FDA indicated that the eCTD is a ‘strongly recommended’ guidance for submission by a proposed date of July, 2003. A common format will significantly reduce the time and resources needed to compile applications for registration of human pharmaceuticals and will ease the preparation of electronic submissions. Regulatory reviews and communication with the applicant will be facilitated by a standard document of common elements. In addition, exchange of regulatory information between Regulatory Authorities will be simplified. In parallel with the advent of the eCTD, evolving standards are reaching down to the specifics of datasets and variables, and linking up with submissions to the Agency. The basis for this detail is to improve efficiency for clinical research and to improve efficiency of evaluation of safety and efficacy of investigational treatments. The basic premise for standardization is to improve time to market for safe and effective treatments. This presentation presents an overview of the eCTD requirements, some of the standards for electronic transmission of the submission, and the evolving standards for datasets and variables supporting electronic data interchange.

INTRODUCTION The eCTD was submitted as a final draft to the International Conference on Harmonisation (ICH) in February, 2002 as a standard submission dossier for pharmaceutical products. The European Union (EU) and Japan have already mandated submission with the eCTD by July, 2003. Canada and Switzerland are also working toward implementing the eCTD. In June, 2002, FDA posted a draft guidance which is a specifications document for the eCTD. Essentially the eCTD is a transport format which is being moved into the Agency's review environment and will further facilitate electronic submissions. Open standards are the philosophy of the eCTD. These standards include proprietary standards, which through their widespread usage can be considered de facto standards. Specification by the eCTD is described down to the file-naming, the variable-naming, and hyperlinks. Considering the industry’s efforts to standardize clinical data, multiple organizations are harmonizing to enact standards including Clinical Data Interchange Standards Consortium (CDISC), Health Level 7 (HL7), and Electronic Standards for the Transfer of Regulatory Information (ESTRI) Expert Working Group (M2). This presentation will highlight the standardization accomplished by the eCTD and some of the developing clinical data standards.

Electronic Common Technical Document (eCTD) The CTD is not a path towards common review practices. It also does not define the studies required for the registration of a new drug. It is, instead, an agreed upon, common format for the presentation of summaries, reports and data. The sections of the eCTD have been made modular so that the common parts, module 2 through module 5, will be standardized for global submission. Module 1 is reserved for Regional Administrative Information and Prescribing Information.

Numbering System 1.0 Regional Administrative Information 1.1 ToC of Module 1 or overall ToC, Module 1

including Module 1

1.0

2.1 ToC of CTD (Mod 2,3,4,5) 2.2 Introduction 2.3 Quality Overall Summary 2.4 Nonclinical Overview 2.5 Clinical Overview 2.6 Nonclinical Written and Tabulated Summaries 2.7 Clinical Summary

2.1 Module 2

2.2 2.4

2.5

2.3 2.6 Module 3 Quality

2.7

Module 4

Module 5

Nonclinical

Clinical Study Reports

Last Update June 13 '02 Study Reports

Module 1 is thoroughly described within the FDA guidance, which is the administrative information specific to FDA. This includes the current cover form that is now used, FDA form 356h, a cover letter, patent information, debarment certification, field copy certification, user fee cover sheet, financial disclosure information, letters of authorization for reference to other applications or drug master files, patent certification, waiver requests, claimed exclusivity, and labeling. It has recently been proposed that the environmental assessment may be affixed as the last document for this module. These are items everyone is submitting already. For the eCTD, it will be in this order and it is “on the top of the pile”.

Comparison of eCTD with NDA by Sections eCTD I Regional Administrative Information (Not part of CTDFDA Form 356h, Index, Summary, Patent Certification, Claimed Exclusivity, Labeling…) II Overall CTD Table of Contents of Modules 2, 3, 4, and 5 Introduction Quality Overall Summary Appendices (facilities, equipment, excipients) Regional Information

NDA Application Form (FDA Form 356h)

Index (TOC) Introduction Labeling Summary Chemistry, Manufacturing & Control Summary

Comparison of eCTD with NDA by Sections (cont) eCTD Non-clinical Overview (Pharm., Kinetics, Tox.) Clinical Overview Non-Clinical Summaries Clinical Summaries III Chemistry & Manufacturing IV Non-clinical Study Reports (Pharmacology, Kinetics, Toxicology)

V Clinical Study Reports Biopharmaceutic Pharmacokinetic Pharmcodynamic Efficacy Safety Post-Marketing Literature

• •

NDA

• •

One suggestion submitted to FDA concerns indexing the folders within each section. The suggestion is to prefix the folder names with the number of the CTD-numbered section. And, further, the files in the folders would be prefixed with ascending numbering. This is similar to the original NDA in one respect, but, in this case, the prefixes would effect a sort key for folders and files. This would also increase quality control and standardize files names independent of the company granularity. An example follows:

Non-clinical Summaries Microbiology Summary Clinical Summaries Risk-benefits Summary Chemistry, Manufacturing and Controls Non-clinical Pharmacology & Toxicology

Module 4 41_TOC 42_CSR o 421_Pharmacokinetics 1_Analytical Methods 2_Absorption 3_Distribution 4_Metabolism 5_Excretion 6_Interactions

Pharmacokinetics & Bioavalability Microbiology Clinical Data - Pharmacology - CSRs (controlled, …………….uncontrolled)

Therefore, it is understood that the future eCTD will change, whether by content, regional requirement, newly-adopted standards, or technology. Information technology capabilities and requirements will also evolve in the pharmaceutical industry and in the regulatory authorities. The change control process described in this section allows the eCTD specification to be updated to meet new requirements and to take advantage of technology improvements. Each section can be updated as needed, independent of the remainder of the document.

- Integrated Summary of Efficacy - Integrated Summary of Safety - Post-marketing - Literature Samples and Labeling CRFs CRTs Other (Refer to Previous Submissions) Patent Information, Certification Patents Claiming Drug Exclusivity

CRFs CRTs

XML-based eCTD The XML eCTD DTD (Document Type Definition) defines the overall structure of the submission. The purpose of the XML backbone is two-fold: (1) to manage meta-data for the entire submission and each document within the submission and (2) to constitute a comprehensive table of contents and provide corresponding navigation aids. Meta-data on submission level includes information about the submitting and receiving organization, manufacturer, publisher, identification of the submission, and related data items. Examples for meta-data on the document level are: versioning information, language, descriptive information such as document names, checksums, etc. Meta-data allows for management of the life-cycle of submissions and related documents throughout the life of the product.

eCTD Specification The specification is designed to support high-level functional requirements such as the following: • • • • • •

Updating of standards that are already in use within the eCTD Identification of new standards that provide additional value for the creation and/or usage of the eCTD Identification of new functional requirements Experience of use of the eCTD by all parties

Copy and paste Viewing and printing of documents Annotation of documentation Facilitate the exporting of information to databases Searching within and across applications Navigation throughout the eCTD and its subsequent amendments/variations

The XML eCTD DTD describes the hierarchical structure according to the CTD as defined by the ICH M4 expert working group. It includes multiple hierarchical levels depending on the specific module as defined in the CTD. The actual submission can include more hierarchical levels below those defined in the CTD. The XML eCTD instance covers the entire submission including all hierarchical levels and references to each individual file.

Change Control

The submission should include a style sheet that supports presentation of the XML instance, navigation according to the table of contents and access to all documents within the submission. A standard style sheet is defined and provided by the ICH M2 EWG. Presentation and navigation via other style sheets on the receiving side should be possible. The XML eCTD DTD includes attributes for descriptive names of folders and documents.

The specification for the eCTD is likely to change with time. Factors that could affect the content of the specification include, but are not limited to: • Change in the content of the CTD, either through the amendment of information, at the same level of detail, or by provision of more detailed definition of content and structure • Change to the regional requirements for applications that are outside the scope of the CTD

2

Lifecycle Management

links from the instance to leaf files in the eCTD submission as opposed to creating a single XML document that contains the entire eCTD submission. The instance should contain mostly linking facilities to the leaf files. The instance also contains metadata at the leaf level. Although the specification for the eCTD is very detailed, this does not mean that all eCTDs will be the same. Again, the eCTD is a common format; the content will be different according to the application and the nature of the submission. It was recommended by FDA in December, 2002 that, if a section is not populated by the submission information, the sponsor should not delete that section. Instead, the sponsor should insert a brief explanation why it is not applicable.

The applicant creates a submission that is stored in a local repository. The applicant submits the initial submission to the agency, which imports the submission into another local repository. The nature and kind of the local repositories is not within the scope of the eCTD. The initial submission should be self-contained meaning that it includes all documents and no references to other submissions. Regional guidance should be consulted if references to other submissions are needed. Following the initial submission, the applicant can submit incremental updates such as amendments and variations. Updates can refer to documents in the previous submissions. Updates should be designed in a way that they can be loaded into the repository by fully preserving the initial or previous submission via version control. The XML backbone should include meta-data identifying the update and providing navigation aids to filter for different submission types.

Logical Documents and Files A logical document is comprised of one or more CTD table of contents sections that together contain the minimum amount of information to be exchanged. In general, the XML eCTD DTD maps explicitly to the CTD table of contents, but there are exceptions where the XML eCTD DTD maps to the level of use designated by the appropriate ICH CTD Implementation Working Group (IWG) instead. Ideally, a logical document consists of a single physical file. In the event the physical file exceeds the recommended maximum file size due to graphics, data content, scanned images, or other large format content, additional files may make up the logical document. Furthermore, if the logical document consists of multiple file formats, then more than one physical file would be needed. An example of such a case would be PDF and XML data that together represent the logical document.

It is preferred that when a Common Technical Document is submitted electronically, the entire submission should be in electronic form with the exception of certain regional forms that currently require written signatures. Regional requirements are listed in appendices of the guidance. A description of how to submit a CTD containing both paper and electronic components is explained in appendices.

eCTD Submission Generally, the eCTD Submission is a directory structure with files including the XML eCTD instance, reports, data and other submission information. One major benefit is expected when the eCTD Submission is loaded into an information system that supports the review process. One can view an eCTD Submission from the reviewer desktop with a web browser as it is web ready. It can be usable without processing in at least in stand-alone mode with the web browser or via network connected by a server. Another major benefit is that the entire submission has a life-cycle management structure. This structure facilitates the ability to append, replace, or delete any module, section, or document within a section. Its flexible infrastructure complements the content standards.

Formats Formats should be readable at least for as long as it is needed for the regulatory process. This process could be very long; e.g. 50 years. This points to neutral formats: formal standard, industrial standard, vendor independent, text-like, etc. The format should be adapted to the type of data. The list of agreed formats will be updated as technology evolves and new requirements arise. XML will be the preferred format for all types of data. The common formats that can currently be included in an eCTD Submission are:

The eCTD Submission is composed of the following: • Directory Structure • XML eCTD instance • Content files

• • •

Directory Structure The directory structure is a structure of directories and files. There should be a reasonable maximum number of entries (directories and files) per directory. The directory structure should follow the rules below. The files could be in several formats as specified below. The name of the files and directories are identifiers. They should be short. The file names are not intended to convey metadata, though some meaning in the names helps; i.e., no random names. Names for directories and files are recommended in an appendix. Any directory names and file names that are added to the eCTD submission by the applicant should be descriptive and logical.

•

Narrative: Portable Document Format (PDF) Structured: Extensible Markup Language (XML) Graphic: Whenever possible, use PDF. When appropriate or when PDF is not possible, use Joint Photographic Experts Group (JPEG), Portable Network Graphics (PNG), Scalable Vector Graphics (SVG) and Graphics Interchange Format (GIF). Special formats for very high resolutions may be appropriate on a case-by-case basis. SAS datasets: SAS XPT for transported SAS datasets

A pharmaceutical company has suggested to the FDA that SVG (scalable vector graphics) be used instead of PDF. PDF was approved by ESTRI in March 1997. However, it has been proposed that SVG should be used instead because 1) it is a W3C standard 2) it is text-based while PDF is binary. The company maintains that SVG would be better for archiving and it reminds that SVG is vendor neutral. While this company makes a strong case, no documentation could be found that this is being considered.

XML eCTD Instance

Links

The instance is in the submission sequence number directory. The submission sequence number directory should contain at least two files and one or more directories. One of the files in the submission sequence directory is the instance and the other is the MD5 checksum of the instance. The instance is the starting file for the processing by an XML processor. The intention is to have

Links among objects in the eCTD Submission should be relative. The intention is to make the eCTD submission self-contained. All literature references introduced by the applicant should be

3

included in the submission, for secondary references (references to a reference), absolute links to external objects can be used. The capacity to point to a specific location within a file depends on the linking technology. Different formats allow for the use of different linking technology.

Standards-Development Collaborating Organizations •

Checksums • The eCTD Submission should contain checksums for each individual file including a checksum file for the eCTD XML instance. Initially, the MD5 Message-Digest Algorithm (MD5) should be used for this purpose. Including a checksum for each individual file provides a number of benefits including: • The integrity of each file can be verified by comparing the checksum submitted with the file and the computed checksum. • The checksum can be used to verify that the file has not been altered in the historical archive of the regulatory authority. This is especially useful as the files are migrated from one storage medium to another, as in the case of backup to magnetic tape storage.

• •

• • • • • • •

Summary – the eCTD Standard By leveraging the use of XML and other current vendorindependent industry standards, the eCTD becomes the standard document that is both machine-readable—so it is easily parsed and processed electronically—and human-readable—so it can be easily retrieved and reviewed by FDA. Therefore, XML will be easier to document, validate, audit and archive; this, in turn, will expedite review and ease compliance. The standardization of the eCTD is portrayed down to the directory and file levels for the document. And, because of the very nature of the electronic submission, standards are also proposed for the structure and components of the electronic files.

Electronic Regulatory Submission & Review (ERSR) a joint initiative between CDER, CBER, Office of Regulatory Affairs (ORA), and Office of Information and Resource Management (OIRM ) Clinical Data Interchange Standards Consortium (CDISC) - Open group of vendors, pharmaceutical companies, government agencies FDA subgroup of Department of Health and Human Services (DHHS) Data Council - Coordinates data standards used by FDA Health Level Seven (HL7) - ANSI accredited standards development organization, Regulated Clinical Research Information Management Technical Committee (RCRIM) Center for Disease Control (CDC) National Cancer Institute (NCI) Veterans Health Administration (VHA) DataPharm Foundation PharmQuest PPD Informatics Lincoln Technology

For the year 2003, the FDA has standards for clinical data submissions among the items to be addressed. Below are the highlights of the goals of the some of the above organizations as they work toward “normalization” of clinical data and a brief description of each.

Benefits of Study data standards • • •

Evolving Standards

• •

“Normalizing” or standardizing can be related to the programming concept of macros. For example, instead of assigning variables named BPSYS, BPDIA, and PULSE then performing the Proc Univariate on each of the three variables, one can create a macro name of “BPRESULT”, call &BPRESULT, and pass it BPSYS, BPDIA, and PULSE. Even though one has to allow time for additional effort of creating the macro, the programming efficiency would be valued as a two- to three-fold increase. Moreover, when this macro is re-used, subsequent programming for this algorithm may be reduced. In general, this improves programming maintenance and ultimately improves time to market for safe and effective treatments. Extending this idea to the standardization of data, file, and document structure, work is currently ongoing to evolve standards in these areas. Extending to higher levels, standards initiatives are progressing in the areas of electronic document management (eg, eCTD), study data management, and medication information management. Standards are also developing internationally via Health Level Seven organization, inter-regulatory via International Conference on Harmonization, nationally via Department of Health and Human Services, and at FDA via the Information Management Program. Following is a discussion of the proposed standards to be included in electronic data transfer and some of the organizations that are working toward those standards.

•

Improve efficiency for clinical research Facilitates design and conduct of clinical trials Facilitates communication between researchers and study sponsor (e.g., between CRO and drug company) Improve efficiency of evaluation of safety and efficacy of investigational treatments Facilitates communication between regulatory authority and applicant Facilitates development of efficient review environment (e.g., training, analysis tools)

Study Data Standards Initiatives • • • • •

Study data information model/structure File format Controlled terminology Content standards Case report tabulations

Standard Descriptive Variables • •

4

Observations characterized by descriptive variables Types of descriptive variables o Topic identifier - the focus of the observation o Unique subject identifiers - the subject of the observation o Timing - describes the start and end of the observation o Qualifiers - describes the traits of the observation

Standard for Labeling – Bar Codes •

•

• •

Drug and Biological Products Drug listing Product ingredients and packaging Patient medication identification Medical devices

• CDISC

CDISC is an open, multidisciplinary, non-profit organization committed to the development of worldwide standards. These standards support the electronic acquisition, exchange, submission and archiving of clinical trials data and metadata for medical and biopharmaceutical product development. The CDISC mission is to lead the development of global, vendor neutral, platform-independent standards to improve data quality and accelerate product development in the pharmaceutical industry. Global representation has evolved through the creation of a CDISC Coordinating Committee in Japan and also in Europe. CDISC is also working towards harmonizing standards with Health Level 7 (HL7), a Department of Health and Human Services (DHHS)-recognized standards development organization. Four standard models are described below. In the future, additional models will be provided for common analysis formats and to describe other types of data (eg, pharmacokinetics, pharmacodynamics, and efficacy data for certain therapeutic areas).

FDA's ESTRI Gateway The ERSR program is a joint initiative between the Center for Drug Evaluation and Research (CDER), Center for Biologics Evaluation Research (CBER), Office of Regulatory Affairs (ORA), and Office of Information Resources Management (OIRM) to define their strategic plans for implementing electronic submission and review systems. However, all centers are interested in pursuing technology to allow electronic acceptance and review of regulated information. The ESTRI Gateway allows the electronic filing of regulatory information. The purpose of the ESTRI Gateway is to place a centralized, Agency-wide gateway into dayto-day operations for receiving regulatory submissions securely. The ESTRI Gateway applies a core set of open standards, applies to regulatory bodies and to industry, and incorporates the International Conference on Harmonisation (ICH) M2 standardization efforts. The ESTRI gateway has provided a total solution for regulatory communications by recommending standards for physical media, networks, security, and data interchange format. The benefits of electronic submissions include: • • • • •

Submissions Data Standards (SDS) The CDISC Submissions Data Domain Models have been prepared by the CDISC Submissions Data Standards (SDS) team to guide the organization, content, and form of submission datasets for the 12 safety-related domains listed in the FDA guidance documents. The focus of the SDS Group has been on case report tabulation (CRT) datasets.

Leverages the Internet for faster, seamless reporting and standardizing data transmission between FDA, industry and other regulatory authorities eliminates data transcription errors reduces paper processing burden/cost on Industry and FDA stores industry participant information contained in the Trading Partner Agreement (TPA) complies with international standards and open technology solutions (ICH E2B/M2 EWG standards published March 8, 1999)

While the CDISC models are under consideration within the FDA as a reference standard, sponsors should always check with their review Division before making any electronic submissions of data. No attempt has been made to define all possible variables or data structures in the domain models. Rather, the SDS team has adopted an ‘80% rule’, identifying those variables commonly used by most sponsors. The proposed model places considerable emphasis on the importance of providing detailed examples to illustrate concepts, particularly when multiple approaches are possible. Each SDS domain model provides a description of variables in a CRT domain, including the following:

The first application of the ESTRI Gateway is the Adverse Events Reporting System (AERS), which accepts adverse event reports for CDER and CBER. The Gateway is able to receive and send data and conforms to the ICH M2 Expert Working Group standards, which include transmission of an application-level acknowledgment message to be transmitted from the FDA through the Gateway upon receipt of an adverse event report. As of January, 2003, submission of MEDDRA codes are required, ie, no longer will AERS text-identifiers be accepted. English is the world-wide standard. The specification still provides for text transmission when providing summary narratives. ESTRI is currently working on a world-wide unique case ID number. Knowledge gained from implementation and support of the ESTRI Gateway will be applied to new systems for electronic submissions of various types. The "transmission loop" works in the following manner:

• • •

AERS gets message from Gateway and processes AERS-level status message is generated and sent back to trading partner via the Gateway Trading partner's Gateway returns receipt for AERSlevel status message

• • • • •

Trading partner creates message (uses MedDRA as standard) Trading partner sends message to FDA through Templar-compatible Gateway If message is processed correctly, acknowledgment or transmission receipt sent from Templar to trading partner

• •

5

The CDISC-suggested variable name (which may be used as an alias by sponsors who choose other variable names) A sample variable label (which should be adjusted by sponsors to describe the data contents) Suggested values for data type (character, numeric) and decodes or formats The origin or source of the raw data (e.g., CRF or derived) An optional column for the role of the variable in the dataset A column for comments (provided by the sponsor) Two columns of “Data Preparation Comments” provided by the CDISC SDS team -- a set of Notes relevant to each variable and a column that indicates if a variable is a core CDISC variable (as defined below)

Sponsors should check with their review Divisions before deciding on whether to use the new Version 2.0 vertical format for ECG and/or Vitals or the original horizontal format. The vertical models led to some improvements in the respective horizontal models. Version 2.0 added a non-core variable for LOINC (Logical Observation Identifiers Names and Codes) codes for Lab, ECG, and Vitals measurements. LOINC codes are universal identifiers for laboratory and other clinical observations (vital signs, hemodynamics, intake/output, ECG, obstetric ultrasound, cardiac echo, urologic imaging, gastroendoscopic procedures, etc)

objectives. These guidelines discuss the variety of issues that should be considered when submitting information to aid the statistical review of the submission. One example presents guidelines for a familiar percent change from baseline analysis frequently used by industry statisticians.

Laboratory Standards Team (LAB) The CDISC Laboratory Data Interchange Standard has been developed over the past two years by the CDISC Lab Team, which includes representatives from pharmaceutical companies, central laboratories, contract research organizations (CROs) and technology application developers. The Laboratory Model has been developed by this team through multiple iterations and tested with representative laboratory data. The Model was then further revised to address comments provided by a 65 member Laboratory Review Committee of industry experts and a sixty day public review. Utilization of electronic data capture (EDC) technologies and standards is a major issue across the industry. The CDISC LAB Model Version 1.0 Final was released for implementation and comment in November 2002 and replaces an earlier public comment version that was released in June 2002.

Operational Data Modeling Team (ODM) The ODM is an XML-based clinical data model designed for data transfer and data archiving. (Details of added functionality in Version 1.1 Final released November, 2001; further detail described at PharmaSUG 2002 and at CDISC website.) • • • • • • • • • • • •

Ability to address changes to key data values Expanded transaction support for partial or incremental transfers and archives Expanded metadata descriptions of more complex event structures Support for including multiple studies and reusable metadata in one file Support for depicting non-patient reference data Support for vendor extensibility Increased compatibility with the CDISC Submissions Data Model Increase support for archiving of clinical data and metadata Elimination of support for the flat representation of clinical data included in version 1.0 Corrections to numerous bugs including those related to time-zones, locales and signatures Changes to the order of elements Changes to element names and attributes, including the item data element

FDA subgroup of HHS Data Council The purpose of the bar code regulation for labeling is to reduce the number of adverse drug events, including deaths, which occur every year due to medication errors. It is hoped that bar code labeling for human drug products can minimize errors due to drug mix-ups and also provide crucial information for prescribers. Barcoding may ultimately apply to biologicals, medical devices, and animal drugs. Electronic submissions of labeling will allow computer matching of labeling products and product-labeling changes that will greatly enhance the accuracy and speed of review.

Health Level 7 (HL7) “Level Seven" refers to the highest level of the International Standards Organization's (ISO) communications model for Open Systems Interconnection (OSI) - the application level. The application level addresses definition of the data to be exchanged, the timing of the interchange, and the communication of certain errors to the application. The seventh level supports such functions as security checks, participant identification, availability checks, exchange mechanism negotiations and, most importantly, data exchange structuring. While HL7 focuses on addressing immediate needs, the group continues to dedicate its efforts to ensuring concurrence with other United States and International standards development activities. A special interest group has been appointed to assist in the implementation of the Administrative Simplification provisions of HIPAA mandates, providing on-going support, and to represent HL7 in the HIPAA Designated Standards Maintenance Organization (DSMO) efforts. One of its constituent committees is the Working Group for Data Interchange (WEDI). The purpose of the DSMO is to encourage the use of HL7 for uniform implementation of this supplemental information. This group coordinates industry input to produce and maintain guides for HL7 electronic messaging. Another HL7 initiative is intended to be the basic unit of a document-oriented Electronic Patient Record (EPR). The Clinical Document Architecture (CDA), which was until recently known as the Patient Record Architecture (PRA), provides an exchange model for clinical documents (such as discharge summaries and progress notes)—and brings the healthcare industry closer to the realization of an electronic medical record. It is the first XMLbased standard for healthcare. Using XML ensures that PRA documents are readable using: a) widely-available and commonly deployed XML-aware browsers and b) a generic PRA style sheet

In December, 2002, CDISC submitted to FDA the following. We believe the FDA Guidance should directly reference use of the CDISC Operational Data Model (ODM) as a standard format for archiving operational clinical trial data at the investigator’s and/or sponsor's site for possible review by FDA auditors and other interested parties. ODM is a vendor neutral, platform independent open standard that is supported by CDISC and offered to all interested parties without cost. ODM recreates the original data collection environment experienced by the investigator or clinical data management operator, describes all CRFs with its questions and range checks, and produces a complete audit trail of all changes to the data. ODM supports the representation of electronic signatures with data, and provides for inclusion of an eCRF form similar to those commonly included with eSubmissions based on data collected by Electronic Data Capture (EDC) systems. ODM requires no proprietary software tools, which may become obsolete over time, so it is an ideal format for retaining electronic clinical data at investigator sites. CDISC is also working closely with HL7 to harmonize the ODM with HL7 standards. We hope the FDA will consider the applicability of the CDISC ODM XML standard as a platform and vendor independent solution for archive and maintenance of clinical trial data.

Analysis Dataset Model (ADaM) This document provides guidelines for the creation of analysis data sets and associated documentation that are submitted to the FDA statistical reviewer in support of the primary and important secondary study

6

written in a standard style sheet language. The Clinical Document Architecture was approved as an ANSI standard November 2000. Although the CDA has been approved, it has, and is creating much controversy over its potential for breech of patient information confidentiality.

S ta n d a r d s C o n verg en ce

Public Docket 92s-0251

E le c tr o n ic D a ta

In the Federal Register of March 20, 1997 (62 FR 13467), the Agency announced the establishment of a docket, number 92S0251, listing the type of submissions the Agency can accept in electronic format. When certain criteria are met, 21 CFR part 11 provides for both the submission of electronic records in lieu of paper records and the substitution of electronic signatures for "handwritten signatures…or general signings" in connection with such submissions. However, original paper signatures are still required under certain circumstances. Below is current to September, 2002.

•

•

D a ta S u b m is s io n C lin ic a l S tu d y D a ta X M L -b a s e d D o c u m e n ts

Currently in public docket 92s-0251 o New drug applications (NDA) (CDER - 1999) o Abbreviated new drug applications (ANDA) (CDER & CBER-Jun, 2002) o Biologic Licensing applications (BLA) (CBER - 1999) o Post-marketing individual case safety reports (ICSR) (CDER &CBER-Jan, 2001) o Drug advertising material (CDER -2000& CBER – July, 2002) o Investigational drug applications (IND) (CDER-Sep, 2002, CBER – Mar, 2002)

REFERENCES FDA, 21 CFR Part 314, Applications for FDA to Market a New Drug or an Antibiotic Drug. FDA, 21 CFR Part 11, Electronic Records, Electronic Signatures, Final Rule, Federal Register Vol. 62, No. 54, 13249, Mar 20, 1997.

Impending candidate o Drug master files (DMF)

Computer Assisted New Drug Application (CANDA) Guidance Manual, Second Edition, October, 1994. Providing Regulatory Submissions in Electronic Format – NDAs, CDER, CBER, January, 1999.

Conclusion In conclusion, the Food and Drug Administration is aggressively moving towards an electronic regulatory submissions environment. The eCTD guidance presents the established standard common format for the preparation of a well-structured Common Technical Document for applications that will be submitted to regulatory authorities. A common format for the technical documentation will significantly reduce the time and resources needed to compile applications for registration of human pharmaceuticals. Regulatory reviews and communication with the applicant will be facilitated by a standard document of common elements. Further, exchange of regulatory information between Regulatory Authorities will be simplified. Additionally, several groups are diligently ferreting out patient and clinical study standards, data standards, analysis standards, and electronic transmission standards. These standards facilitate electronic submissions to regulatory authorities and other electronic exchange of clinical data. The basis for standardization is to improve efficiency for clinical research, to improve efficiency of evaluation of safety and efficacy of investigational treatments, and to improve time-to-market for safe and effective treatments. The document, data, and electronic standards are converging to a more efficient, global approval for marketed products and management of medical data.

Guidance for Industry Providing Regulatory Submissions to the Center for Biologics Evaluation and Research (CBER) in Electronic Format, November, 1999, Revised. www.fda.gov/cder/ www.fda.gov/cber/ www.fda.gov/oc/ www.hl7.org/ www.cdisc.org/ www.ich.org/ www.fda.gov/ohrms/ www.phrma.org/

7

ACKNOWLEDGMENTS I would like to thank Matt Becker and Monte Jarvis for their support.

CONTACT INFORMATION Your comments are very welcomed. Please contact the author: Susan Bairnsfather PharmaNet, Inc. Cary, NC 27513 (609) 951-6583 [email protected] SAS and all other SAS Institute Inc. product or service names are registered trademarks or trademarks of SAS Institute Inc. in the USA and other countries. ® indicates USA registration. Other brand and product names are trademarks of their respective companies.

8