Guidance for Industry 1
This guidance document is being distributed for comment purposes only
Comments and suggestions regarding this draft document should be submitted within 60 days of publication in the Federal Register of the notice announcing the availability of the draft guidance. Submit comments to Dockets Management Branch (HFA-305), Food and Drug Administration, 5630 Fishers Lane, rm. 1061, Rockville, MD 20852. All comments should be identified with the docket number listed in the notice of availability that publishes in the Federal Register.
For questions regarding this draft document contact (CBER) Michael Fauntleroy 301-827-5132, (CDER) Randy Levin 301-594-5411, (CDRH) Stuart Carlow, (CFSAN) JoAnn Ziyad 202-418-3116**, (CVM) Elizabeth L. Parbuoni 301-827-4621.
U.S. Department of Health and Human Services
Food and Drug Administration
Center for Biologic Evaluation and Research (CBER)
Center for Drug Evaluation and Research (CDER)
Center for Devices and Radiological Health (CDRH)
Center for Food Safety and Applied Nutrition (CFSAN)
Center for Veterinary Medicine (CVM)
October 2003, Revision 1
This draft guidance, when finalized, will represent the Food and Drug Administration's (FDA's) current thinking on this topic. It does not create or confer any rights for or on any person and does not operate to bind FDA or the public. You can use an alternative approach if it satisfies the requirements of the applicable statutes and regulations. If you want to discuss an alternative approach, contact the FDA staff responsible for implementing this guidance. If you cannot identify the appropriate FDA staff, call the appropriate number listed on the title page of this guidance.
TABLE OF CONTENTS
- How Do Electronic Submissions Relate To 21 CFR Part 11?
- What File Formats Should I Use For Electronic Documents?
- Page Orientation
- Page Size and Margins
- Source of Electronic Document
- Methods for Creating PDF Documents and Images
- Hypertext Linking and Bookmarks
- Page Numbering
- Document Information Fields
- Open Dialog Box
- Naming PDF Files
- Indexing PDF Documents
- Plug Ins
- What File Formats Should I Use For Electronic Datasets?
- SAS System XPORT Transport Format (Version 5 SAS Transport Format)
- What Are The Procedures For Sending Electronic Submissions For Archive?
- Electronic Transmission
- Physical Media
- What If I Have A Question?
- Appendix A: Additional information on providing Electronic Submissions on Physical Media
This is one in a series of guidance documents intended to assist you when making regulatory submissions in electronic format to the Food and Drug Administration (FDA). This guidance discusses general issues common to all types of electronic regulatory submissions. This is a revision to the guidance of the same name that issued in January 1999. Once it has been finalized, this guidance will replace the January 1999 guidance.
This guidance is being revised to address electronic submissions coming into all centers of the Agency. Changes from the 1999 version of the guidance also include addition of a new section describing the relationship of electronic submissions to 21 CFR part 11. There are updates on the recommendations for creating PDF documents including specific guidance for the use of fonts. New file formats for data, specifically XML and SGML are introduced. The electronic transmission of files is discussed. In some cases, the guidance for one center differs some from that of another center because of differences in procedures and in the computer infrastructures in the centers. We will work to minimize these differences wherever possible.
Agency guidance documents on electronic regulatory submissions will be updated regularly to reflect the evolving nature of the technology involved and the experience of those using this technology.
FDA's guidance documents, including this guidance, do not establish legally enforceable responsibilities. Instead, guidances describe the Agency's current thinking on a topic and should be viewed only as recommendations, unless specific regulatory or statutory requirements are cited. The use of the word should in Agency guidances means that something is suggested or recommended, but not required.
In the Federal Register of March 20, 1997 (62 FR 13430), the FDA published the Electronic Records; Electronic Signatures regulation (21 CFR part 11). This regulation provides, among other things, for the voluntary submission of parts or all of records in electronic format without an accompanying paper copy under certain circumstances. In January 1999, the Center for Biologics Evaluation and Research (CBER) and the Center for Drug Evaluation and Research (CDER) finalized a joint guidance document on general considerations for electronic submissions. They also published guidance documents describing how to provide marketing applications to each center. Following publication of these guidance documents, a working group was formed with the CBER, CDER, Center for Devices and Radiological Health (CDRH), the Center for Food Safety and Applied Nutrition (CFSAN), and the Center for Veterinary Medicine (CVM) to coordinate electronic submission activity. The efforts of this working group have resulted in this draft guidance, which updates the 1999 general considerations guidance document.
The Agency envisions a series of guidance documents on electronic regulatory submissions. As individual documents are completed, they will be issued first in draft for comment, then finalized and added to the series. The guidances will be updated regularly to reflect the continuously evolving nature of the technology and experience of those using this technology.
FDA's part 11 regulations (21 cfr part 11), among other things, set forth the criteria under which records submitted to FDA may be submitted in electronic format in place of paper. Section 11.2(b) states that, for records submitted to the Agency, persons may use electronic records in lieu of paper records, in whole or part, provided the requirements of part 11 are met and the documents or parts of documents to be submitted have been identified by the Agency in public docket No. 92S-0251 as being the type of submission the Agency is prepared to accept in electronic format. (2)
Documents submitted in electronic format should:
- Enable the user to easily view a clear and legible copy of the information
- Enable the user to print each document page by page, as it would have been provided in paper, maintaining fonts, special orientations, table formats, and page numbers
- Include a well-structured table of contents and allow the user to navigate easily through the submission
- Allow the user to copy text, images and data electronically into other common software formats.
To achieve the above goals, you should submit all electronic documents in portable document format (PDF). We are prepared to archive documents provided as PDF files. PDF is an open, published format created by Adobe Systems Incorporated (http://www.adobe.com). You do not need to use a product from Adobe or from any specific company to produce your PDF documents. PDF has been accepted as a standard for providing documents in electronic format by the International Conference on Harmonisation (ICH).
The following will help you create PDF files that we can review and archive.
We should be able to read all PDF files with Acrobat Reader version 4.0, and above, with the search plug in. We should not need any additional software to read and navigate the PDF files.
PDF viewing software automatically substitutes a font to display text if the font used to create the text is unavailable on the reviewer's computer. In some cases, font substitution can occur even when the fonts are available. For example, Helvetica or Times are substituted even if available on the reviewer's computer. Font substitution can affect a document's appearance and structure, and in some cases it can affect the information conveyed by a document. We cannot guarantee the availability of any one font. Therefore, you should embed all fonts you are using in the PDF files to ensure that those fonts will always be available to the reviewer. When embedding fonts, all characters for the font should be embedded, not just a subset of the fonts being used in the document.
However, font embedding does not solve the problems that occur when a reviewer tries to paste text from a PDF document into another software format. If the font is not available on the reviewer's computer, font substitution results even if the fonts are embedded. For this reason, we ask that you restrict the fonts used in documents to one of the following fonts listed in Table 1. We still ask that you embed the fonts so they are available for printing older archival files.
Table 1: List of recommended fonts Font type Font name San Serif AdobeSansMM (Adobe Sans Multiple Master) Arial BolitaMT (Arial Bold Italic (From Monotype)) ArialBolMT (Arial Bold Monotype) ArialtaMT Arial Italic (Monotype) ArialMT Arial (Monotype) Non proportional Courir (Courier) CouriBol (Courier Bold) CourriBolObl (Courier Bold Oblique) Serif AdobeSerifMM (Adobe Serif Multiple Masters) TimesNewRomPSBolitaMT (Times New Roman Bold Italic) TimesNewRomPSBolMT (Times New Roman Bold) TimesNewRomPSItaMT (Times New Roman Italic) TimesNewRomPSMT (Times New Roman) TimesNewRoman Other Symbo (Symbol) ZapfDin (Zapf Dingbats)
Resizing a submitted document because the contents are too small to read is inefficient. We believe that Times New Roman, 11 or 12-point font (the font used for this document), is adequate in size for reading narrative text. When making point size larger, data comparisons could become problematic because data that normally might appear in one table would now appear in multiple tables. When choosing a point size for tables, a balance should be made between providing sufficient information on a single page that may facilitate data comparisons while still achieving a point size that remains legible. Generally, point sizes 9-10 are recommended for tables; smaller point sizes should be avoided. Ten point fonts are recommended for footnotes.
We recommend the use of a black font color. Blue font can be used for hypertext links (preferred for submissions to CBER (3) and CFSAN). If a font color other than black is used, you should avoid light colors that do not print well on grayscale printers. You can test the color reproduction prior to submission by printing sample pages from the document using a grayscale printer.
Pages should be properly oriented to reduce the effort of rotating pages. For example, you should set the page orientation of landscape pages to landscape prior to saving the PDF document in final form to ensure correct page presentation.
Page Size and Margins
The print area for pages should fit on a sheet of paper that is 8.5 inches by 11 inches. You should allow a margin of at least 1 inch on the left side of page (to avoid obscuring information when the pages are subsequently printed and bound) and 3/8 of an inch on the other sides. For pages in landscape orientation, you should allow 3/4 of an inch at the top to allow more information to be displayed legibly on the page. Header and footer information can appear within these margins as long as it is not within 3/8 of an inch of the edge of the 8.5 by 11 inch page, because the text may be lost upon printing or being bound.
Source of Electronic Document
PDF documents produced by scanning paper documents are usually inferior to those produced from an electronic source document. Scanned documents are more difficult to read and do not allow us to search or copy and paste text for editing in other documents. They should be avoided if at all possible. If you use optical character recognition software, you should verify that all imaged text converted by the software is accurate.
Methods for Creating PDF Documents and Images
You should choose a method for creating PDF documents that produces the best replication of a paper document. You can ensure that the paper and PDF version of the document are the same by printing the document from the PDF version.
Documents that are available only in paper should be scanned at resolutions that will ensure the pages are legible both on the computer screen and when printed. At the same time, you should also limit the file size. We recommend scanning at a resolution of 300 dots per inch (dpi) to balance legibility and file size. We discourage the use of grayscale or color because of file size. But, if you believe their use is necessary, the following paragraphs provide preliminary recommendations, and specific guidance documents provide additional details. After scanning, you should avoid resampling to a lower resolution.
The optimal image resolution and bit depth depends to a large part on the actual need for viewing the image. You should not provide images at high resolution and depth without determining the need. High resolution and depth images result in large files, taking up valuable storage space. It is better to provide samples to the appropriate center of the images at various resolutions and depths prior to sending in the actual submissions to determine the optimal image resolution and depth to meet the review need.
When creating PDF files containing images, you should not resample images. Resampling does not preserve all of the pixels in the original. For PDF images, you can use one of the following lossless compression techniques.
- For lossless compression of color and grayscale images, you should use Zip/Flate (one technique with two names). This is specified in Internet RFC 1950 and RFC 1951 (http://info.internet.isi.edu/in-notes/rfc/files/rfc1950.txt).
- For lossless compression of black and white images, you should use the CCITT Group 4 Faxcompression technique. It is specified as CCITT recommendations T.6 (1988) - Facsimile coding schemes and coding control functions for Group 4 facsimile apparatus.
When submitting medical images to CBER, such as X-ray, CT, ultra sound, PET, and SPECT, they should not be compressed.
Note. if you use lossless compression, there should not be a change in the label size and format.
Paper documents containing handwritten notes should be scanned at 300 dpi. Handwritten notes should be done in black ink for clarity.
For photographs, the image should be obtained with a resolution of 600 dpi. If black and white photos are submitted, consider 8-bit gray scale images. If color photos are submitted, consider 24-bit RGB images. A captured image should not be subjected to nonuniform scaling (i.e. , sizing).
Gels and karyotypes should be scanned directly, rather than from photographs. Scanning should be at 600 dpi and 8-bit grayscale depth.
Plotter output graphics should be scanned or captured digitally at 300 dpi.
High-pressure liquid chromatography or similar images should be scanned at 300 dpi.
When color is important in the review of a file, labeling for example, you should make sure that the colors are an accurate representation of the actual image. Since color varies from monitor to monitor, it is difficult to ensure that the reviewer will see exactly the same color as in the actual image. However, for printing, there is more control over the color if you use CMYK color model as opposed to the RGB model. Since PDF uses the color profile provided by CMYK, you can use Pantone Matching and this will ensure color consistency for printing. PDF also uses the ICC color profile specifications when PDF documents are printed.
Hypertext Linking and Bookmarks
Hypertext links and bookmarks are techniques used to improve navigation through PDF documents. Hypertext links can be designated by rectangles using thin lines or by blue text (the latter is preferred by CBER and CFSAN). We recommend you use invisible rectangles for hypertext links in a table of contents to avoid obscuring text. Recommendations for hypertext linking and bookmarks are provided in the guidance for the specific submission type.
In general, for documents with a table of contents, you should provide bookmarks and hypertext links for each item listed in the table of contents including all tables, figures, publications, other references, and appendices. These bookmarks and hypertext links are essential for the efficient navigation through documents. Bookmarks to the roadmap (when applicable), main table of contents, and item table of contents for the section of the application a reviewer has accessed, at the top of the bookmark hierarchy, are extremely helpful. The bookmark hierarchy should be identical to the table of contents with exceptions made for the following three bookmarks - the roadmap (when applicable), the main table of contents, and the item table of contents being accessed by a reviewer. You should avoid using bookmark levels in addition to those present in the table of contents. Each additional level increases the need for space to read the bookmarks. We recommend using no more than 4 levels in the hierarchy.
Hypertext links throughout the body of the document to supporting annotations, related sections, references, appendices, tables, or figures that are not located on the same page are helpful and these hypertext links improve navigation efficiency. You should use relative paths when creating hypertext linking to minimize the loss of hyperlink functionality when folders are moved between disk drives. Absolute links that reference specific drives and root directories will no longer work once the submission is loaded onto our network servers.
When creating bookmarks and hyperlinks, you should choose the magnification setting Inherit Zoom so that the destination page displays at the same magnification level that the reviewer is using for the rest of the document.
See guidance for the specific submission type for guidance on page numbering.
In general, it is easier to navigate through an electronic document if the page numbers for the document and the PDF file are the same. The initial page of the document should be numbered as page one, with two exceptions. One, when a document is split because of its size (e.g. , > 50 MB), the second or subsequent file should be numbered consecutively to that of the first or preceding file. Two, when several small documents with their own internal page numberings have been brought together into a single file, it is not necessary to renumber the documents into one page sequence, although you should provide a bookmark at the start of each subdocument. For example, if you are adding an original protocol as an appendix to a study report, you should not add page numbers to the original protocol so the page numbers are consecutive to the rest of the study report. You should provide a bookmark to the original protocol.
Document Information Fields
Document information fields are used to search for individual documents and to identify the document when found. Recommendations for the document information fields will be provided in the guidance for the specific submission type.
Open Dialog Box
The open dialog box sets the document view when the file is opened. The initial view of the PDF files should be set as Bookmarks and Page. If there are no bookmarks, we recommend that you set the initial view as Page only. You should set the Magnification and Page Layout to default.
Naming PDF Files
Recommendations on names to use for folders and selected files are provided in the individual guidances for specific submission types. For uniformity. you should use our specific naming conventions when they are provided. Reviewers are trained to look for these folders and files, and using the recommended names should help avoid misunderstandings, improve communication, and speed the review of a submission.
When we do not specify a file name, you can use file names up to 32 characters in length including PDF as the 3-character extension. We recommend that you avoid using punctuation, dashes, spaces, or other nonalphanumeric symbols (e.g. , \ / : * ? < > | " % # +) in file names. Underlines can be used.
You should not include any security settings or password protection for PDF files except when recommended in guidance for a specific submission type. You should allow printing, changes to the document, selecting text and graphics, and adding or changing notes and form fields. Our internal security and archival processes will maintain the integrity of the submitted files. A read-only copy of the files, generated from the submitted files, will be provided to the reviewer.
Indexing PDF Documents
We use full text indexes to help find specific documents and/or search for text within documents. When a document or group of documents is indexed, all words and numbers in the file and all information stored in the document information fields are stored in special index files that are functionally accessible using the search tools available in Acrobat. Portions of a document that are imaged are not indexed. Even if the document only contains images, the text in the Document Information fields of the file will be indexed.
These full text indexes should not be confused with a table of contents. Adobe Acrobat Catalog is one example of a tool that can be used to index PDF documents. Indexes should not require extensions or additions to the off-the-shelf Acrobat Reader.
With many submissions, we ask that you associate the table of contents file for a section with the corresponding full text index file. By associate, we mean that when the table of contents file is opened, the index file is automatically added to the available index list and is ready to be used.
Further recommendations for full text indexes will be provided in individual guidances for the specific submission types.
You can use plug ins to assist in the creation of a submission. However, the review of the submission should not require the use of any plug ins, in addition to those provided with the latest Acrobat Reader because we are not prepared to archive additional plug-in functionality.
You should provide data subsets in certain formats. Currently, we are able to accept and archive datasets in SAS System XPORT transport format (Version 5 SAS transport file). In circumstances when data are moved directly to a database or special review tool, tagged ASCII file, specifically, standard generalized markup language (SGML) and extensible markup language (XML), may be the appropriate file format. At times, delimited ASCII files are also acceptable. See the individual guidance for the specific submission type for the appropriate dataset format.
SAS System XPORT Transport Format (Version 5 SAS Transport Format)
SAS XPORT transport format, also called Version 5 SAS transport format, is an open format published by the SAS Institute. The description of this SAS transport file format is in the public domain. Data can be translated to and from this SAS transport format to other commonly used formats without the use of programs from SAS Institute or any specific vendor.
You should follow the recommendations in this section to create SAS transport files that we can review and archive.
In SAS, SAS XPORT transport files are created by PROC XCOPY in Version 5 of SAS software and by the XPORT engine in Version 6 and higher of SAS Software. We are unable to archive SAS Transport files processed by the CPORT engine.
You can find the record layout for SAS XPORT transport files in SAS technical support TS-140. This document and additional information about the SAS Transport file layout can be found on the SAS World Wide Web page at http://www.sas.com/fda-esub.
Transformation of Datasets
We use a variety of software tools to analyze the datasets. Stat/Transfer from Circle Systems and DBMS/copy from Conceptual Software Inc. , are two programs used to convert data to various formats used for analysis. SAS Viewer version 7 or higher is used to open SAS transport files directly.
Naming SAS Transport Files
All SAS transport files should use xpt as the file extension.
Compression of SAS Transport Files
SAS transport files should not be compressed. There should be one transport file per dataset.
Content of Datasets and Organization
You should provide a single transport file for each dataset. Many of the software tools used by the reviewers require datasets to be loaded into random access memory (RAM) prior to opening the file. Therefore, dataset files should be organized so that their size is generally less than 50 MB per file. Datasets divided to meet the maximum size restrictions should contain the same variable presentation so they can be easily merged, joined, and concatenated. The datasets should be accompanied by data definition tables that include metadata such as the variable name, a description of the variable, the type of variable (e.g. , number, character, date), and codes used in the dataset. Variable names should be limited to 8 characters. You should include a descriptive name up to 40 characters in the label header. Further recommendations for content of SAS Transport files are provided in guidance for each specific submission type.
We recommend that you discuss the content of the datasets with the review division prior to submission.
Extensible markup language (XML) was developed by a working group at the World Wide Web Consortium (W3C). It is a nonproprietary language developed to improve on previous mark up languages including standard generalized markup language (SGML) and hypertext markup language (HTML). XML is not as complicated to use as SGML and is more flexible than HTML.
Information in an XML file is divided into specific pieces. These pieces are called objects or elements types. The element type identifies the piece of information. For example, the
NDA application number might be identified with the element type <appNum>. All
element type names are bracketed using the special characters < >. Inside the XML document, the element type name is placed just prior to the piece of information and after the information. This is called tagging. So, in the XML file, the application number for
NDA 123456 would be tagged as follows <appNum>123456</appNum>. The / prior to the element type denotes that this is the end of the information about the appNum.
By using a hierarchial structure, XML allows you to relate two or more elements. This is accomplished by nesting one element within another.
Additional information about the element type is provided by attributes. Attributes are placed within the element types and are surrounded by " ". For example, if you wanted to identify the type of the application number as an NDA, you could add this piece of information as an attribute. This could be represented in the XML file as <appNum type="NDA">123456</appNum>.
Internet browsers read XML files. Style sheets provide the browser with the information necessary to create tables, fonts, and colors for display in the XML file.
The specific names of the element types and attributes as well as the valid syntax, structure and format for defining the XML elements are included in a file called document type declaration (DTD). If the XML document does not follow the DTD, the file might not be used properly.
We currently use XML version 1.0 recommended by the World Wide Web Consortium (W3C). We will be evaluating additional uses for XML as enhancements for data exchange evolve and extensions are developed. Additional information can be found at the W3C web site at www.w3c.org.
For specific tags and formats see the individual guidance document for the specific submission type.
A working group at the W3C developed standard generalized markup language (SGML). It is a nonproprietary language developed to organize and transmit information in digital format. It shares many of the features of XML described above. Additional information can be found at the W3C web site at www.w3c.org.
The file format called Molfile is in the public domain and was developed by Molecular Design Limited (MDL) in the late 1970's. Currently, the company, now named Molecular Design Limited Information Systems, is a wholly owned subsidiary of Elsevier Science. Technical information about the Molfile format can be found at the MDL web site at http://www.mdli.com/downloads/literature/ctfile.pdf.
Molfiles are generated by chemical structure drawing programs. The most common drawing programs, ISIS/Draw from MDL and ChemDraw Pro from Cambridge Soft. (http://www.cambridgesoft.com), create Molfiles. A free copy of ISIS/DRAW for your personal use may be obtained from the MDL Web site at http://www.mdli.com/downloads/isisdraw.html.
Molfiles can be viewed and reformatted using Chime, a free plug in to Microsoft Internet Explorer and Netscape Communicator from MDL. You can download the plug in at http://www.mdli.com/downloads/chime.html.
Molfiles can be searched using database programs such as ISIS Base. Additional Information about this database program can be found at the MDL web site at http://www.mdli.com.
VI. What Are The Procedures For Sending Electronic Submissions For Archive?
Electronic submissions should be provided in electronic format, either on physical media or by acceptable methods of electronic transport. You should refer to the individual guidance for the specific submission type for the appropriate procedures to use for sending electronic submissions for archive.
Currently, we have identified three methods for sending submissions electronically. Submissions using electronic data interchange (EDI), web-based transmissions, and secure email. We will provide additional information on these transmission methods as they are used for specific submission types. For example, CVM accepts electronic submission of certain types by attaching encrypted PDF files to e-mail to the Electronic Document Control Unit at email@example.com. You can get more information at www.fda.gov/cvm/fda/TOCs/guideline.html.
The following information is important when sending electronic submissions on physical media. See Appendix A. Additional information on providing Electronic Submissions on Physical Media for additional information.
Where do I send the electronic submission?
Electronic submissions should be sent directly to the appropriate center involved. See guidance for specific submission type for additional information.
You should provide a minimum of two copies of the submission. One copy will be used to load the submission into our electronic document room (EDR). This copy will be made available to the Agency's review community upon request. The second copy will be archived for disaster recovery. Additional copies of items of an application, bundled by review discipline, may be requested to facilitate the review offsite. All materials are received centrally within CBER and should be addressed as follows:
Center for Biologics Evaluation and Research
Document Control Center, HFM-99
Food and Drug Administration
1401 Rockville Pike
Rockville, MD 20852-1448
Submitting organizations should use the above address for regulatory documents and media in support of applications within CBER. This includes regulatory documents and media sent via U.S. Postal Service or via common or private carriers.
Unless otherwise specified in the specific submission guidance, send one copy of the electronic regulatory submission for archive to the CDER Central Document Room.
Contact the appropriate reviewing division prior to making an electronic submission. The division will inform you as to where and how to send submissions. Contacts can be found at http://www.fda.gov/cdrh/organize.html#ODE. See individual guidance for specific submission type for additional information.
CFSAN's Office of Nutritional Products, Labeling, and Dietary Supplements (ONPLDS) is working on procedures for submitting new dietary ingredient notifications and applications for temporary marketing permits. Unless otherwise specified in the specific submission guidance, send one copy of the electronic regulatory submission for ONPLDS to the following address:
Office of Nutritional Products, Labeling, and Dietary Supplements
Center for Food Safety and Applied Nutrition
5100 Paint Branch Parkway, HFS-800
College Park, MD 20740
Currently, CFSAN's Office of Food Additive Safety (OFAS) accepts a submission provided only on physical media. All submissions should be sent directly to OFAS. The procedure for handling paper submissions is unchanged from the past.
You should send electronic and paper submissions to:
Office of Food Additive Safety
Center for Food Safety and Applied Nutrition
Food and Drug Administration
5100 Paint Branch Parkway
College Park, MD 20740
You should communicate with OFAS prior to submitting an electronic document, notifying it of your intention to submit an electronic document in advance of the target date for the submission
OFAS will schedule a teleconference or meeting between petitioners and the appropriate OFAS staff. The objective of the teleconference is to convey information relating to the proposed electronic submission's management paradigm, content, format, and structure. Moreover, OFAS will discuss any issues specific to your submission that may not have been fully addressed in this general considerations guidance. The amount of time that will be needed to ensure that the document is ready for submission will depend on the complexity of the document and experience of the said submitter in preparing petitions and notifications.
We are working on procedures for accepting electronic submissions on physical media. See individual guidance for specific submission type for additional information.
What type of media should I use?
We are prepared to accept electronic submissions on CD-ROM and digital tape. In CDER and CFSAN, you can also use floppy disks. To optimize processing efficiency, we recommend choosing media with a capacity most appropriate to the size of the submission. Whenever possible, applicants should choose media capable of holding the submission on the fewest number of units.
Recommendations for Media Size of Submission Media and format Units Less than 10MB* 3.5 inch DOS Formatted Floppy Disks 1 to 10 Less than 3.25GB CD-ROM ISO 9660 1 to 5 CDs Greater than 3.25GB Digital Linear Tape (DLT) 35/70, 20/40 and 10/20 GB format using NT server 4.0 with NT backup or backup exec. No limit *This is not an option for CBER and CVM
How should I prepare the media for electronic submissions?
You should send all electronic media adequately secured in a standard binder marked clearly on the outside ELECTRONIC REGULATORY SUBMISSION FOR ARCHIVE. CDs should be packaged carefully to ensure that they arrive in a usable condition. Particularly vulnerable are diskettes and CD jewel cases shipped in envelopes without bubble-type protective material or stiff backing. We do not recommend the use of jiffy-type bags alone to ship media because they may not provide adequate protection.
You should provide the following identification information on the media, as appropriate:
- Sponsor, applicant or company name
- Name of the product, chemical, or ingredient
- Appropriate regulatory ID number (e.g. , Petition Notification number, NDA, IND, BLA number, petition or notification number)
- Application type (e.g. , IND amendment, BLA supplement, title of petition or notification)
- Submission date in the format of dd-mmm-yyyy
- Copy number (e.g. , original, copy 1, copy 2)
- Media series (e.g. , "1 of 1," "1 of 2")
- When sending CD-ROMs to OFAS, number them from 0.001 through 0.XXX for the original submission, and 1.001 through 1.XXX for subsequent submissions to the same files with additional information.
You should include the information directly on the DLT tape cover label. For CDROMs, you should include the information on the jewel case. The CDROM itself should include, at a minimum, sufficient identification information so that it can be paired with the jewel case bearing the complete identification information, in the event that they become separated. See the individual guidance for the specific submission type for additional information on labeling physical media.
You can submit questions pertaining to the preparation of submissions, in electronic format, for CBER to ESUBPREP@CBER.fda.gov.
We maintain a web site on electronic submissions at www.fda.gov/cder/regulatory/ersr/default.htm. You can direct questions regarding the preparation of submissions in electronic format in CDER to firstname.lastname@example.org.
You can submit questions about electronic submissions via email to email@example.com. We also maintain a web site on electronic submissions at www.fda.gov/cdrh/elecsub.html. In addition, you can sign up for email updates on the CDRH home page at www.fda.gov/cdrh.
You can direct questions regarding the preparation of submissions in electronic format in CFSAN to the Electronic Submissions Coordinator email to firstname.lastname@example.org.
You can direct questions regarding the preparation of submissions in electronic format in CVM to the Electronic Submissions Coordinator, email to email@example.com or you can call the Center Hot Line at 301-827-8277. Additional information on electronic submissions can be found at http://www.fda.gov/cvm/guidance.
Processing the electronic submission
The structure and content of electronic submissions to CBER should be based upon the application (e.g. , BLA and IND). Subsequent to the delivery of an electronic application, any additional electronic information (i.e. , amendments) will be added to the existing copy of the submission residing in the Electronic Document Room (EDR). BLA supplements are treated as separate submissions, not as continuations of the base application. They will be stored in their own EDR folder. The root directory of an electronic application should contain a roadmap.pdf file to orient the review team to the application as well as subsequent information amending the application.
CBER suggests that a roadmap.pdf file be used to establish hypertext links to an application's or amendment's main table of contents and to the application folders and files. If an application is submitted on multiple CDROMs or DLT tapes, each unit of media should contain the identical roadmap.pdf file, which links to folders and files on all of the media units. This roadmap file should be updated and resubmitted when additional information is submitted to amend an application.
The roadmap.pdf file should be placed in the root directory of a submission. This ensures that the outdated roadmap.pdf file is overwritten each time a new amendment is loaded into the EDR. The roadmap file should not contribute in any way to the content of the submission under review. It is a map, intended to facilitate navigation through the contents of an application. The application's roadmap.pdf file should be easily updated or modified, for example, using the Replace File command under the Document menu option in Adobe Exchange. This function will automatically replace the old hypertext links to previously submitted sections of the application, leaving only the task of creating the new links corresponding to newly submitted information.
In addition to providing a navigable guide to the application, the roadmap.pdf file should include the sponsor's submission date in the DD-MMM-YYYY format (e.g. , 01-Jan-1999). The contents of the original application and any subsequent amendments to that application should be briefly described in a roadmap.pdf table. The location of these files and folders on the submitted media should be indicated in the roadmap.pdf. Where portions of an application have been submitted only as a paper documents, they should be included in the roadmap and table of contents and tagged as paper only.
The following text is a representative example of a roadmap.pdf file.
Electronic Roadmap BLA Submission Submission Date Submission Content CD-ROM Hypertext link Destination Sponsor Name 15-Jan-99 FDA Form 356h 0.001 /blatoc.pdf cover.pdf 0.001 BLA Table of Contents 0.001 Item 01-Index 0.001 Item 02-Labeling 0.001 Item 03-Summary 0.001 Item 04-CMC 0.001 Item 05-Pharmtox 0.001 Item 06-Cpbio 0.001 Item 08-Clinical 0.002 Item 10-Statistical 0.002 Item 12-Crf 0.002 Item 15-Estab 0.002 Others (Items 13-16) 0.002 BLA 123456/5001/1 1-Apr-99 cover.pdf` 0.001 \ 123456/5001/1\ amendtoc.pdf confid.pdf 0.001 CMC 0.001 BLA 123456/5001/2 19-Jun-99 Cover.pdf 0.001 \ 123456/5001/2\amendtoc.pdf Clinstat 0.001 BLA 123456/5001/3 4-Jul-99 cover.pdf 0.001 \ 123456/5001/3 \amendtoc.pdf confid.pdf 0.001 Clinstat 0.001 Safety Update 0.001
A summation of the electronic document, using at least 40 key words from the main document, should be included with all electronic applications delivered to CBER. This summation should be located in the root directory on the CDROM or DLT tape. The file containing the key words should be an ASCII text file entitled Summary.txt.
In general, when an electronic submission arrives in CDER, we copy the electronic files to tape to create an archival copy of the submission. We also copy the files to a network server to create a read-only copy for the reviewer. See specific submission type guidance for additional details.
When an electronic submission arrives in OFAS one copy of the media is archived: the second copy of the submission's media is copied to a network server to create a read-only copy for the reviewer.
The structure and content of electronic submissions to OFAS should be based upon the application (e.g. , Petition, Notification). Subsequent to the delivery of the electronic application, any additional electronic and/or paper information will be added to the existing network copy of the submission and made available to appropriate managers and reviewers. The root directory of an electronic application should contain a roadmap.pdf file to orient the review team to the original application and to any and all subsequent information added to the application.
OFAS suggests that a roadmap.pdf file be used to establish hypertext links to the application's main table of contents and to the application folders and files. This roadmap or home page should be updated and resubmitted as additional information to the application.
The roadmap file should not contribute in any way to the content of what is under review. It is a map, intended to facilitate navigation through the contents of an application. The application's roadmap.pdf file should be easily updated or modified, for example, using the Replace File command under the Document menu option in Adobe Exchange. This function will automatically replace the old hypertext links to previously submitted sections of the application, leaving only the task of creating the new links corresponding to newly submitted information.
In addition to providing a navigable guide to the application, the roadmap.pdf file should include the sponsor's submission date in the DD-MMM-YYYY format.17 (e.g. , 01-Jan-2000). The contents of the original application and any subsequent amendments to that application should be briefly described in a roadmap.pdf table. The location of these files and folders on the submitted media should be indicated in the roadmap.pdf. Where portions of an application have been submitted only as paper documents, they should be included in the roadmap and table of contents and tagged as paper only.
A summation of the electronic document, using at least 40 key words from the main document should be included with all electronic applications delivered to OFAS. This summation should be located in the root directory on the CDROM or DLT tape. The file containing the key words should be an ASCII text file entitled Summary.txt.
We are developing procedures for processing electronic submissions sent on physical media. See individual guidance for specific submission type for additional information.
(1) This guidance has been prepared by the Center for Drug Evaluation and Research (CDER) in cooperation with the Center for Biologics Evaluation and Research (CBER), Center for Devices and Radiological Health (CDRH), Center for Food Safety and Applied Nutrition (CFSAN), and Center for Veterinary Medicine (CVM) at the Food and Drug Administration.
(2) For a discussion of the Agency's perspectives on 21 CFR part 11, see the guidance for industry Part 11, Electronic Records; Electronic Signatures -- Scope and Application, which issued in September 2003.
(3) The Commissioner has announced a consolidation of the CDER/CBER review functions for therapeutic products. Once the consolidation has been completed, we will review those guidances that have been affected by the transfer of functions for possible revision.
This document supercedes Draft Guidance: Providing Regulatory Submissions to Office of Food Additive Safety in Electronic Format -- General Considerations (July 2001)