Electronic Submissions

3,072
-1

Published on

Published in: Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,072
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide

Electronic Submissions

  1. 1. Electronic Submissions Shakul Hameed
  2. 2. What are Electronic Submissions? A Regulatory application submitted via network or web directory to regulatory agencies.. Marketing Approval  IND, NDA, BLA, Correspondences, Safety Reports  MAA, CTA, 510ks, other marketing apps… Special formats for creating documents PDF, XML, SAS, MSWord, JPG
  3. 3. History of Electronic Submissions  1980s: Computer Assisted NDA (CANDA)  1995: CDER’s Submission Management and Review Tracking (SMART)  1997: CFR, Part 11 and PDUFA  1998 and 1999: Guidance Doc  2002: ICH Guidance M2  2006: Providing Electronic Submissions  NDA, IND, ANDA, DMF, 510K and PMA, etc  Amendment docs: Annual Reports, Labeling
  4. 4. Key Benefits  Paperless, or near paperless submissions for faster marketing approval  Seamless, fast exchange of information within and across agency centers and external to the agency.  Elimination of duplication.  Rigorous records management and document control tracking, and archiving.  Electronic data Interchange (EDI) capability for data exchange.  Standards-based infrastructure..  Standards-based information repositories and data dictionaries
  5. 5. e-Submission vs eCTD  Important distinction: eSubmission ≠ eCTD, NeeS  The eCTD and NeeS is a particular type of electronic submission (NeeS applicable only for Europe)  Moving now towards the implementation of the eCTD as the specific format for electronic submission  Moving also towards the acceptance of electronic- only submissions, with eCTD the preferred standard. No paper requirement.
  6. 6. eCTD  Electronic Common Technical Document  Method to electronically transfer product information and data collection of electronic files organized according to guidelines defining file format, folder/file naming conventions, document specifications, etc…..  Designed with considerations that facilitate  Creation  Review  Life Cycle Management  Archiving
  7. 7. Structure of eCTD  Building blocks:  PDF files for text*  SAS transport files for data*  Connected through XML backbone  Looks like a web page  Viewing  Links and bookmarks  Search keywords, metadata  Managing lifecycle (Append, Replace, Delete)
  8. 8. eCTD File Structure
  9. 9. eCTD File Structure Cont….
  10. 10. Example of XML Backbone
  11. 11. XML Mapping to Folders
  12. 12.  Submission + knowledge management  Technology driven  Project management  Business skills Paper to Electronic (R) evolution
  13. 13. Paper/e-submission Comparison Paper submissions Electronic No Specialized Software Specialized E-publishing software's Overall and Module TOCs XML Back bone = TOC Printed Documents and various formats Electronic document, PDF Format Tabs for Navigation Bookmarks and Hyperlinks for Navigation More Physical Storage Space Less Physical Storage Space More time to pack and ship Less time to pack and ship ESG available Less efficient access and review More efficient access and review Difficult to review entire submission lifecycle Easy to review entire submission lifecycle
  14. 14. Paper/Paper/e-submission cont….cont….
  15. 15. NeeS  This is a European-only specification  Initially developed as ‘interim’ as a lead in to eCTD–But will probably have a long duration of use  Should be an eCTD without the backbone but with PDF table(s) of content
  16. 16. NeeS/eCTD Comparison e-CTD EU-NeeS Format defined at ICH Harmonized European Format XML: <<backbone>> (TOC) - Lifecycle Management No XML ( Backbone / Envelope) No life Cycle Management PDF 1.4 Files (Including Application form and SPC) PDF 1.4, ICH ICH file Naming Conventions (Highly Recommended) File Naming Conventions Mandatory Hyperlinks One General TOC One Specific TOC per Module (m1-toc.pdf….) When Necessary MD5 Checksums No checksums
  17. 17. eCTD/NeeS Comparison
  18. 18. eCTD/NeeS Comparison Cont….
  19. 19. Encouraging the use of eCTD  Adapting to an international standard  Facilitating the management of MA- dossiers  Facilitating archiving of applications  Reduce the use of paper  Streamline the assessment process  Moving toward a more efficient system.
  20. 20. The Future of e-submissions • The FDA is steadily moving toward a fully electronic regulatory environment across ALL Divisions • As it works to achieve this goal, the FDA is seeking to help to develop and adopt more robust standards that promote increased review quality and organizational efficiency
  21. 21. The Future of eCTD will be RPS Regulated Product Submissions All FDA Divisions to be on the same platform for cost efficiencies ~2012 Based on XML similarities to eCTD Standards predicted to converge with eCTD 4.0
  22. 22. RPS vs. eCTD RPS eCTD FDA harmonized Divisions Global Standard Not EU, Global Rigid folder structure Improved metadata and life cycle Difficult Lifecycle tracking Better DM integration Limited concept of Submissions/RU Single XML file Multiple XML files Undefined folder structure FDA Divisions not satisfied/unified Two way communication Metadata problems (can’t be corrected, poor life cycle issues) Hyperlink content to content Limited “relative” hyperlinks Same tools as eCTD eCTD 4.0 may converge with RPS
  23. 23. eSubmission Advantages • Relieves resource burdens related to paper distribution & storage • Makes review process faster, more efficient • Ease of searching through data • Documents easily accessible for years to come • Facilitates life cycle management
  24. 24. eSubmission Challenges  Still new and unfamiliar to many reviewers  Full text search not fully implemented  Diversity of strategies,  e.g.Quality Overall Summary  Amendments  Supplements  INDs [don’t include all data here, use Module 3]  Diversity of data presentation  Diversity of “leaf” naming conventions
  25. 25. Life Before e-submissions
  26. 26. Conclusion  Send submissions electronically  Try to make submissions user-friendly  More efficient review work benefits all of us

×