 |
 |
 |
|
 |
FDA Home Page | CBER A-Z Index | CBER Search | Contact CBER | CBER Home Page  |
||||
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:
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
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 CBER3 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.
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.
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.
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.
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 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 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.
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.
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.
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 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.
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.
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 cvmdcu@cvm.fda.gov. 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.
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 esub@cder.fda.gov.
You can submit questions about electronic submissions via email to esub@cdrh.fda.gov. 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 esubprep@opa.fda.gov.
You can direct questions regarding the preparation of submissions in electronic format in CVM to the Electronic Submissions Coordinator, email cvmstars@cvm.fda.gov 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/guidance.html.
APPENDIX A: ADDITIONAL INFORMATION ON PROVIDING ELECTRONIC SUBMISSIONS ON PHYSICAL MEDIA CBER 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. Roadmap file 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.
Summary File 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. CDER 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. CDRH 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 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. CVM We are developing procedures for processing electronic submissions sent on physical media. See individual guidance for specific submission type for additional information.
1This 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.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
