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 Numbering System
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 1.0 Regional Administrative Information
human pharmaceuticals and will ease the preparation of
1.1 ToC of Module 1 or overall ToC,
electronic submissions. Regulatory reviews and communication
with the applicant will be facilitated by a standard document of Module 1 including Module 1
common elements. In addition, exchange of regulatory
information between Regulatory Authorities will be simplified. In 1.0 2.1 ToC of CTD (Mod 2,3,4,5)
parallel with the advent of the eCTD, evolving standards are
reaching down to the specifics of datasets and variables, and 2.1 2.2 Introduction
linking up with submissions to the Agency. The basis for this Module 2 2.3 Quality Overall Summary
detail is to improve efficiency for clinical research and to improve 2.2
efficiency of evaluation of safety and efficacy of investigational 2.4 Nonclinical Overview
treatments. The basic premise for standardization is to improve 2.4 2.5
time to market for safe and effective treatments. This 2.5 Clinical Overview
2.3
presentation presents an overview of the eCTD requirements, 2.6 2.7 2.6 Nonclinical Written and
some of the standards for electronic transmission of the
submission, and the evolving standards for datasets and variables Tabulated Summaries
supporting electronic data interchange. Module 3 Module 4 Module 5 2.7 Clinical Summary
Nonclinical Clinical
Quality
INTRODUCTION Last Update June 13 '02 Study Reports Study Reports

The eCTD was submitted as a final draft to the International

Conference on Harmonisation (ICH) in February, 2002 as a Module 1 is thoroughly described within the FDA guidance, which
standard submission dossier for pharmaceutical products. The is the administrative information specific to FDA. This includes
European Union (EU) and Japan have already mandated the current cover form that is now used, FDA form 356h, a cover
submission with the eCTD by July, 2003. Canada and letter, patent information, debarment certification, field copy
Switzerland are also working toward implementing the eCTD. In certification, user fee cover sheet, financial disclosure information,
June, 2002, FDA posted a draft guidance which is a specifications letters of authorization for reference to other applications or drug
document for the eCTD. Essentially the eCTD is a transport master files, patent certification, waiver requests, claimed
format which is being moved into the Agency's review exclusivity, and labeling. It has recently been proposed that the
environment and will further facilitate electronic submissions. environmental assessment may be affixed as the last document
Open standards are the philosophy of the eCTD. These for this module. These are items everyone is submitting already.
standards include proprietary standards, which through their For the eCTD, it will be in this order and it is “on the top of the
widespread usage can be considered de facto standards. pile”.
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 Comparison of eCTD with NDA by Sections
harmonizing to enact standards including Clinical Data
Interchange Standards Consortium (CDISC), Health Level 7 eCTD NDA
(HL7), and Electronic Standards for the Transfer of Regulatory I Regional Administrative Application Form (FDA Form
Information (ESTRI) Expert Working Group (M2). This Information (Not part of CTD- 356h)
presentation will highlight the standardization accomplished by
FDA Form 356h, Index,
the eCTD and some of the developing clinical data standards.
Summary, Patent Certification,
Claimed Exclusivity, Labeling…)
Electronic Common Technical Document (eCTD) II Overall CTD Table of Index (TOC)
Contents of
The CTD is not a path towards common review practices. It also Modules 2, 3, 4, and 5
does not define the studies required for the registration of a new
drug. It is, instead, an agreed upon, common format for the
Introduction Introduction
presentation of summaries, reports and data. The sections of the Labeling Summary
eCTD have been made modular so that the common parts, Quality Overall Summary Chemistry, Manufacturing &
module 2 through module 5, will be standardized for global Control Summary
submission. Module 1 is reserved for Regional Administrative Appendices (facilities,
Information and Prescribing Information. equipment, excipients)
Regional Information
Comparison of eCTD with NDA by Sections • Updating of standards that are already in use within the
(cont) eCTD
• Identification of new standards that provide additional
value for the creation and/or usage of the eCTD
eCTD NDA
• Identification of new functional requirements
Non-clinical Overview • Experience of use of the eCTD by all parties
(Pharm., Kinetics, Tox.)
Clinical Overview One suggestion submitted to FDA concerns indexing the folders
Non-Clinical Summaries Non-clinical Summaries within each section. The suggestion is to prefix the folder names
Microbiology Summary with the number of the CTD-numbered section. And, further, the
files in the folders would be prefixed with ascending numbering.
Clinical Summaries Clinical Summaries This is similar to the original NDA in one respect, but, in this case,
Risk-benefits Summary the prefixes would effect a sort key for folders and files. This
III Chemistry & Chemistry, Manufacturing and would also increase quality control and standardize files names
Manufacturing Controls independent of the company granularity. An example follows:
IV Non-clinical Study Non-clinical Pharmacology &
Module 4
Reports (Pharmacology, Toxicology
- 41_TOC
Kinetics, Toxicology) - 42_CSR
Pharmacokinetics & o 421_Pharmacokinetics
Bioavalability 1_Analytical Methods
Microbiology 2_Absorption
V Clinical Study Reports Clinical Data 3_Distribution
4_Metabolism
Biopharmaceutic - Pharmacology 5_Excretion
Pharmacokinetic - CSRs (controlled, 6_Interactions
…………….uncontrolled)
Pharmcodynamic Therefore, it is understood that the future eCTD will change,
Efficacy - Integrated Summary of whether by content, regional requirement, newly-adopted
Efficacy standards, or technology. Information technology capabilities and
requirements will also evolve in the pharmaceutical industry and
Safety - Integrated Summary of in the regulatory authorities. The change control process
Safety described in this section allows the eCTD specification to be
Post-Marketing - Post-marketing updated to meet new requirements and to take advantage of
Literature - Literature technology improvements. Each section can be updated as
needed, independent of the remainder of the document.
Samples and Labeling
CRFs CRFs XML-based eCTD
CRTs CRTs
Other (Refer to Previous The XML eCTD DTD (Document Type Definition) defines the
Submissions) overall structure of the submission. The purpose of the XML
Patent Information, Certification backbone is two-fold: (1) to manage meta-data for the entire
submission and each document within the submission and (2) to
Patents Claiming Drug constitute a comprehensive table of contents and provide
Exclusivity corresponding navigation aids. Meta-data on submission level
includes information about the submitting and receiving
organization, manufacturer, publisher, identification of the
eCTD Specification submission, and related data items. Examples for meta-data on
the document level are: versioning information, language,
The specification is designed to support high-level functional descriptive information such as document names, checksums,
requirements such as the following: etc. Meta-data allows for management of the life-cycle of
submissions and related documents throughout the life of the
• Copy and paste product.
• Viewing and printing of documents
• Annotation of documentation The XML eCTD DTD describes the hierarchical structure
• Facilitate the exporting of information to databases according to the CTD as defined by the ICH M4 expert working
• Searching within and across applications group. It includes multiple hierarchical levels depending on the
• Navigation throughout the eCTD and its subsequent specific module as defined in the CTD. The actual submission
amendments/variations 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
Change Control file.

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

2
Lifecycle Management
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.
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.
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 meta-
data, 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.
XML eCTD Instance
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
3
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 meta-
data 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.
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.
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:
• 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.
Links
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
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.
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 vendor-
independent 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.
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.
4
Standards-Development Collaborating
Organizations
• 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
• 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
• 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
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 day-
to-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:
• 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)
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:
• 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
• 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 AERS-
level status message
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).
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.
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 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)
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
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 e-
CRF 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
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.
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. Bar-
coding 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 XML-
based 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
written in a standard style sheet language. The Clinical Document
Architecture was approved as an ANSI standard November 2000. S ta n d a r d s
Although the CDA has been approved, it has, and is creating
much controversy over its potential for breech of patient
C o n verg en ce
information confidentiality.

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 92S-
0251, listing the type of submissions the Agency can accept in D a ta S u b m is s io n
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 C lin ic a l S tu d y D a ta
"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.
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) REFERENCES
(CDER & CBER-Jun, 2002)
o Biologic Licensing applications (BLA) (CBER
- 1999) FDA, 21 CFR Part 314, Applications for FDA to
o Post-marketing individual case safety reports Market a New Drug or an Antibiotic Drug.
(ICSR) (CDER &CBER-Jan, 2001)
o Drug advertising material (CDER -2000&
CBER – July, 2002) FDA, 21 CFR Part 11, Electronic Records, Electronic
o Investigational drug applications (IND) Signatures, Final Rule, Federal Register Vol. 62, No.
(CDER-Sep, 2002, CBER – Mar, 2002) 54, 13249, Mar 20, 1997.

• Impending candidate Computer Assisted New Drug Application (CANDA)

o Drug master files (DMF) Guidance Manual, Second Edition, October, 1994.

Conclusion Providing Regulatory Submissions in Electronic

Format – NDAs, CDER, CBER, January, 1999.
In conclusion, the Food and Drug Administration is aggressively
moving towards an electronic regulatory submissions
environment. The eCTD guidance presents the established
Guidance for Industry Providing Regulatory
standard common format for the preparation of a well-structured Submissions to the Center for Biologics Evaluation
Common Technical Document for applications that will be and Research (CBER) in Electronic Format,
submitted to regulatory authorities. A common format for the November, 1999, Revised.
technical documentation will significantly reduce the time and
resources needed to compile applications for registration of
human pharmaceuticals. Regulatory reviews and communication www.fda.gov/cder/
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, www.fda.gov/cber/
several groups are diligently ferreting out patient and clinical study
standards, data standards, analysis standards, and electronic
transmission standards. These standards facilitate electronic www.fda.gov/oc/
submissions to regulatory authorities and other electronic
exchange of clinical data. The basis for standardization is to www.hl7.org/
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 www.cdisc.org/
document, data, and electronic standards are converging to a
more efficient, global approval for marketed products and
management of medical data. 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
sbairnsfather@pharmanet.com

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.