
An innovative approach to fight viral pathogens has been discovered by researchers at the Massachusetts Institute of Technology (MIT). The new drug DRACO, an acronym for double-stranded RNA activated caspase oligomerizers, has the potential to fight many known viruses, including the common cold, flu, stomach viruses, polio, and many more. While the drug is still several years away from clinical trials, DRACO has seen early success in the laboratory. DRACO has demonstrated that it is nontoxic in 11 mammalian cell types, effective against 15 different viruses, and eradicates H1N1 in infected mice.
This groundbreaking treatment employs a novel approach to viral infection. While current therapies typically target a specific virus and often have undesirable side effects, DRACO covers a broad spectrum of viruses by targeting genetic material found only in infected cells. When a cell is infected, a virus reprograms the cell to make copies of the virus. While manufacturing new viruses, the cell creates double-stranded RNA (dsRNA) which is not normally found in healthy human and animal cells. DRACO is designed to enter cells that contain dsRNA and then deliver a message for the cell to self-destruct, a process called apoptosis. In doing so, cells that are infected are quickly destroyed and additional copies of the viruses cannot be made. Because DRACO is specifically designed to only enter cells with dsRNA, healthy cells are left alone.
Even though DRACO is still in the laboratory, the ingenuity of this novel approach to drug discovery is refreshing. As traditional drug discovery continues with its struggles, these types of groundbreaking ideas are critical to ensure new therapies are found in the future.
For more information, click here.
Today’s entry was provided by Rachel A. Wagner, LinkedIn Profile.
In Part 1 of this topic <hyperlink Part 1 blog>, I provided a framework for why companies out-license and in-license of products as well as the type of information that will be exchanged. In Part 2, I will discuss best practices, starategies, and the tools used during my experience.
MS Excel is a tool that I have found most reliable for developing the inventory listing. Excel can be used to inventory the documentation, export/import information to a database (in a tab delimited format), and then validate/verify the received inventory.
The spreadsheet will include such information as date of document/submission, submission number, document/submission type, description, and other data deemed valuable for the product history. Another suggestion is to keep an overall list of the products. This spreadsheet might include the product name and dosage, the type of submission (NDA, ANDA, IND, etc.), the status of the submission, the regulatory agency/division, etc.
Once the inventory is collected, inventoried, and ready for transfer, the next step is to find a good method for the interchange of the inventory. There are many good methods to choose from including eRooms, portable hard drives, CD/DVD, FTP/SFTP sites, and of course the legacy paper being shipped via courier.
Once the inventory of product documentation is received and verified electronic submissions must be quickly integrated into the corporation’s eCTD publishing tool. This can be challenging. I suggest utilizing the expertise of the vendor. Vendors know their software much better than most RegOps staff and can be quite useful in integrating the submissions quickly into the publishing system.
Hard copy documentation must be assessed for future use. A decision should be made to scan the documents or merely validate the inventory and store the documents. If the decision is made to scan the documents, do so in black and white to keep file size to a minimum (gray scale and color scanning usually results in a larger file size).
It is important, during the process of in/out-licensing, to include Information Technology staff in the process of collecting and receiving documents and data. Information Technology staff can be quite useful by ensuring the clean transfer and permanent storage of documents for out-licensing and smooth acceptance and storage of documents during in-licensing. Information Technology staff will ensure there is sufficient drive space and networks are not bogged down, important logistical requirements for the acceptance of a large inventory of documentation and data. Information Technology will also ensure that the security settings for folders are properly set.
Strategies for ensuring all of the above is done with little interference starts at the top. Executive management may consider creating a strategic plan for in/out-licensing and mergers and acquisitions. This strategic plan should include the technical aspects of such an undertaking. Such topics as systems to be used, network and security, and staff involvement (including when to involve staff) are important strategies to ensure success.
Additionally, it is recommended that RegOps and Information Technology collaborate to create a strategic plan for the necessary tasks they will have to perform during these activities. A full understanding of the corporate systems and processes is vital to the success of the integration and divesting of products. This information is important to ensuring the newly acquired information is quickly integrated into the corporate system and that information being sent during a divestiture is quickly gathered.
To ensure success a few high level recommendations are suggested:
Today’s entry was provided by Rachel A. Wagner – LinkedIn Profile
I had the great privilege of speaking at the DIA eCTD conference this past November. The subject of my talk was on the out-licensing and in-licensing of products. Many of you may have had to undertake these tasks in the recent past as this has become a frequent occurrence in our industry. This is the first entry of a two part post where I will share my experiences during the past year including the issues and lessons learned.
The purpose of out-licensing is to raise money for the corporation, or to divest a developed technology. During the out-licensing process it is necessary for the RegOps group to organize and transfer the information and documentation to the new company. This may include the submissions, labeling, correspondence, and other documentation for the product. Additionally a chronology of the product documents, whether that be hard copy, electronic, or both should be included as an “inventory” check.
In-licensing is accomplished to add new products to the corporate pipeline, and procure resources needed for final-stage development, clinical trials, manufacturing, and distribution of products. It should be noted that with any in-licensing there will be a large amount of incoming inventory (documentation) and there is normally an urgency to integrate and streamline the information being received. The documents must be added to the corporate network folders, the EDMS, the publishing system, or other storage methodologies. This must be done quickly and accurately.
The merger/acquisition of companies brings the same type of product on-boarding to a corporation along with the integration of staff and possibly the integration of divergent systems.
There are many tools and methods to make these challenges and opportunities less difficult. These tools will be used to transfer information, inventory documents, and validate the received inventory.
Transfer of Documents:
Transfer of documentation should be done in a logical structure. To this end it is important to create a folder structure that is logical to follow. One suggestion is to create a folder structure that includes such a format as:
Product
Country
Submission Type
Submissions
Correspondence
Labeling
Data
If the corporation does not already have a logical folder structure for storing the inventory of documents that are vital to a product portfolio, I suggest starting that procedure prior to in/out-licensing. Waiting until the critical moment to do this is time consuming and will delay the timeline for completion of the project.
In part two of this topic I will discuss best practices, strategies, and the tools used during my experience.
During the opening session of the recent DIA Electronic Submissions Conference in San Diego, Gary Gensinger, Deputy Director, Office of Business Informatics at CDER spoke about the not-too-distant future at the FDA when electronic submissions will become mandatory. Under the draft PDFUA V bill, electronic submissions will be mandated and Gary provided us a timeline for the implementation under the proposed mandate.
In December 2012, the FDA will release draft guidance for this new era, which, among other things, will require electronic submission. The draft guidance will be open to comment for a period of 6 months followed by the release of the final version. It will then be implemented 2 years after the final version, bringing us to mandated electronic submissions in Q2 2015.
There is another important take-away from this presentation. In the future, the FDA will use this same pattern for implementation of new requirements and guidance. We can expect when the FDA alters its requirements the following timeline will be used:
Draft guidance will release for public comment
Six-month comment period
Revision and release of the final version
Implementation of the changes 2 years later
With this pattern in place, the process of iterative improvement of FDA standards should be much more consistent going forward. For sponsors, this means greatly improved predictability which allows for greatly improved preparedness
As mentioned in an earlier blog from Rahul Mistry, the FDA currently accepts PDF 1.4 and will soon except PDF 1.7. Does this mean that you need to upgrade all of your PDF’s from 1.4 to 1.7?
There is a very simple answer – No.
The specifications for PDF are backward inclusive. This means that the PDF 1.7 specification includes all of the functionality previously documented in the Adobe PDF Specifications for versions 1.0 through 1.6. Below is a list of all of the new features that Adobe has implemented in the PDF specification. If you are not using any of the new features below, a PDF 1.7 file and PDF 1.1 file are identical, with the exception of the version number which is embedded in the metadata.
| Acrobat Reader Version | PDF Version | New Features |
|---|---|---|
| Carousel | 1 | Initial Version |
| 2 | 1.1 | Passwords, encryption (MD5, RC4 40bit), device-independent color, threads and links |
| 3 | 1.2 | Interactive page elements (radio buttons, checkboxes); interactive, fill-in forms (AcroForm); Forms Data Format (FDF) for interactive form data that can be imported, exported, transmitted and received from the Web; mouse events; external movie reproduction; external or embedded sound reproduction; zlib/deflate compression of text or binary data; Unicode; advanced color features and image proxying |
| 4 | 1.3 | Digital signatures; ICC and DeviceN color spaces; JavaScript actions; embedded file streams of any type (e.g. used for attachments); new annotation types; new features of the Adobe PostScript Language Level 3 imaging model; masked images; alternate representations for images; smooth shading; enhanced page numbering; Web capture — a facility for capturing information from World Wide Web and converting it to PDF; representation of logical structure independently of graphical structure; additional support for CIDFonts; data structures for mapping strings and numbers to PDF objects; information for prepress production workflows support; new functions for several function object types that represent parameterized classes of functions |
| 5 | 1.4 | JBIG2; transparency; RC4 encryption key lengths greater than 40?bits (40–128 bits); enhancements to interactive forms and Forms Data Format (FDF), XML form submissions, embedded FDF files, Unicode specification of field export values, remote collaboration and digital signatures in FDF files; accessibility to disabled users; metadata streams using XML — Extensible Metadata Platform (XMP); tagged PDF; inclusion of printer’s marks; display and preview of production-related page boundaries; new predefined CMaps; alternate presentations; importing content from one PDF document into another; Embedded Files entry in the PDF document’s name dictionary — a standard location for the embedded data; OCR text layer |
| 6 | 1.5 | JPEG 2000; enhanced support for embedding and playback of multimedia; object streams; cross reference streams; XML Forms Data Format (XFDF) for interactive form submission (replaced the XML format in PDF 1.4); support for forms, rich text elements and attributes based on Adobe’s XML Forms Architecture (XFA) 2.02; public-key security handlers using PKCS#7 (introduced in PDF 1.3 but not documented in the Reference until 1.5), public-key encryption, permissions — usage rights (UR) signatures (does not require document encryption), PKCS#7 with SHA-1, RSA up to 4096-bits; security handler can use its own encryption and decryption algorithms; document sections selectively viewed or hidden by authors or readers — for items such as CAD drawings, layered artwork, maps, and multi-language documents; Alternate Presentations — the only type is slideshow — invoked by means of JavaScript actions (Adobe Reader supports only SVG 1.0); support for MSWindows 98 dropped. To view and print newer version PDFs, such as those at the IRS, with older versions of Reader requires downloading in Google Docs “Quick View” simplified PDF format. |
| 7 | 1.6 | 3D artwork, e.g. support for Universal 3D file format; OpenType font embedding; support for XFA 2.2 rich text elements and attributes; AES encryption; PKCS#7 with SHA256, DSA up to 4096-bits; NChannel color spaces; additional support for embedded file attachments, including cross-document linking to and from embedded files; enhancements and clarifications to digital signatures related to usage rights and modification detection and prevention signatures |
| 8 | 1.7 (ISO 32000-1:2008) | Increased presentation of 3D artwork; XFA 2.4 rich text elements and attributes; multiple file attachments (portable collections); document requirements for a PDF consumer application; new string types: PDFDocEncoded string, ASCII string, byte string; PKCS#7 with SHA384, SHA512 and RIPEMD160 |
| 9 | 1.7 Extension Level 3 | 256-bit AES encryption; incorporation of XFA Datasets into a file conforming PDF/A-2; improved attachment of Flash applications, video (including Flash video with H.264), audio, and other multimedia, two-way scripting bridge between Flash and conforming applications; XFA 2.5 and 2.6 rich text conventions |
| 9.1 | 1.7 Extension Level 5 | XFA 3.0 |
| X (10) | 1.7 Extension Level 5 | XFA 3.0 |
I am often asked, “Which version of Adobe Acrobat is the FDA using?”. This question is usually followed by, “Which version of PDF can I submit to the FDA?”.
The answer to the first question is that the FDA currently uses Adobe Acrobat 8 with plans of upgrading to the new version, Adobe Acrobat X, in the near future.
The answer to the second question is a bit more complicated. Since the FDA uses Adobe Acrobat 8, they have the ability to view PDF versions 1.0 to 1.7. That being said, they do not support all of these versions.
As many of you know, the FDA issues eCTD Guidance and Specifications to clarify implementation of regulations. In the currently posted specification concerning PDFs dated June 4, 2008, the official PDF version is 1.4, which is supported in Adobe Acrobat 5 and later.
As new versions of the PDF specifications are released, they are evaluated for future acceptance. Therefore, the answer to the question “Which version of PDF can I submit?” changes as the PDF standards evolve. At the DIA Electronic Submissions Conference in San Diego held November 15th-17th, the FDA announced that it will now accept any PDF version between 1.4 and 1.7. While these are the acceptable versions stated by the FDA, earlier versions of PDF’s can still be submitted. See next week’s post.
I also learned that ICH members will also accept PDF versions 1.4 through 1.7 soon. Corresponding with this announcement, the FDA will update their PDF Specifications for the first time in over three years. The updated specification is scheduled to be posed by year end.
The following is a list of changes from the specification:
1. The date-of-submission element was removed.
2. Module 1 heading 1.9.5 “Proposal for written agreement” was removed.
3. An id element was added under applicant-info to provide the applicant’s or sponsor’s corporate DUNS number issued by Dunn & Bradstreet.
4. The submission-description element was added and is optional. The element is limited to 128 characters. It allows for an additional brief description of the purpose of the submission, but should not contain any reviewable information.
5. The applicant-contacts element was added to capture contact information. One or more contact names, telephone numbers, and emails may be submitted for each submission, and at least one contact name is required.
6. The application-set element can contain one or many applications (i.e., bundled submission). Each application needs to have its own submission information section. When a bundled submission is submitted, the submission content will reside under a single application, but is referenced by multiple eCTD applications. The application contains-files element was added to indicate which application contains the files in a bundled submission. This attribute will be used to identify the root application where the submission files will be stored.
7. The element cross-reference-application-number was added to provide the ability to list cross-referenced applications.
8. The sequence number element has been replaced with submission-information element. The submission-information element contains three elements (submission-id, submission-unit-id, and form).
9. Certain forms are provided under the submission-information element to allow each application’s form to be displayed within the appropriate application.
10. Submission type was changed from an element to be an attribute of the submission-id element. In addition, an attribute of supplement-effective-date-type was added and is also an attribute of the submission-id element. The supplement-effective-date-type is only applicable if the submission-type is a labeling or CMC supplement.
11. The submission-unit-id element was added under submission-information element and replaces what was formerly referred to as “sequence number.”
12. An attribute for submission-sub-type was added to more accurately reflect the nature of a submission unit and its relationship to the associated submission.
13. Submissions are grouped with their regulatory activity by using the submission-type, submission-id, and submission unit-id. This functionality replaces the related sequence element from earlier versions of the Module 1 DTD.
14. Certain admin and module 1 elements (m1-1-forms and the sections and subsections of m1-15-promotional-material) require an attribute.
15. Additional headings elements were added to 1.15 Promotional Materials to further define the submission of promotional materials.
16. Additional heading elements were added or revised. Please refer to the The Comprehensive Table of Contents Headings and Hierarchy for the complete set of changes.
17. The us-regional.xml refers to, and validates from, supporting and required files (DTD, stylesheet, and value-type lists) located at web site addresses instead of local file paths (previously required files were located in the util folder). The stylesheet (usregional.xsl) was updated to refer to the new value lists (XML files) and DTD for the purpose of validation and display.
18. The Heading Table was removed from the Heading Elements for Module 1 section.
The US FDA recently posted a draft version of a new “Specification for eCTD Validation Criteria,” outlining many of the new error conditions that the FDA will be checking for in the next version of its validation software. With the FDA getting tougher on technical issues, it is critical that your application is not only structured correctly, but also free of technical errors, especially high severity errors. Most importantly, it must be ready for review by the agency upon submission. Based on the current quality of the submissions the FDA receives, many can expect to receive a technical rejection. This can cost a sponsor anywhere from 4 days to 1 week of delayed approval time and tens of thousands of dollars (possibly much more depending on the expected product revenue), not to mention the man hours spent correcting the issue.
That’s why GlobalSubmit is offering a free educational webinar on Understanding the New FDA Validation Criteria on Thursday, October 20th at 11:00am EDT.
During this discussion, we will focus on some of the more important changes to the criteria, when the new validation criteria will go into effect, best practices for ensuring your application is free of technical errors, and more.
Top 3 Learning Objectives:
About Jason Rock, CTO, GlobalSubmit
Mr. Rock is a technology visionary and leader within the eCTD community at large. He has over 10 years of experience working with global life sciences companies and regulatory agencies to promote the adoption of the eCTD through the development of advanced applications. In his role as CTO, Mr. Rock provides strong leadership for the strategic and technical direction of GlobalSubmit’s product architecture and development. He is a frequent guest speaker at numerous industry forums such as DIA, RAPS and others. Mr. Rock chairs the HL7 Regulated Product (RPS) initiative and works closely with the U.S. FDA for their deployment of GlobalSubmit applications as well as various technology programs involving regulatory submissions.
Event Details:
When: Thursday, October 20th at 11am EDT
Where: Web & Teleconference
Who: Presenter, Jason Rock, CTO, GlobalSubmit; Moderator, Dan Clark, Senior Manager Regulatory Operations & Innovation, NovoNordisk
For more information and event details: GlobalSubmit Events
Today’s entry was provided by Matthew J. Neal, Director of Knowledge Management & Innovation in Global Regulatory Affairs & Safety at Amgen, Inc. in Thousand Oaks, CA. He led the Regulatory Operations group there for seven years and managed submissions for GSK in Philadelphia, PA for 7 years before that.
So, last time, I told you about assembling a team of believers. Those believers are the “customers” you serve on both sides of the fence in regulatory operations. Not only are you getting documents from all the different members of the extended filing team (Regulatory, CMC, Pre-Clinical, etc.), but you’re then serving a different master in your health authority. If you need to review, please read the previous post.
This time, I want to focus on getting the most out of the tools and process which drives your efficiency. Getting to the heart of the matter, operations functions of all shapes and sizes exist – and so do solutions to meet those needs. While it is true that you can create a valid eCTD with some very simple and inexpensive software tools, there is no way I would want to do it by those means.
You could certainly PDF all your documents one at a time from MS Word and then code the XML in notepad. But, using the PDFMaker plug-in for word will automatically link your TOCs and cross-references for you and any of the software packages out there made for eCTD will do all of your XML for you. Tools that help you do that work have many different price points, enterprise license options, hosted solutions, etc. Just Google “eCTD software solutions” and you’ll see what I mean.
The point is, you do not need a million dollar, validated system to build your eCTD’s. But, eCTD lifecycle is a serious commitment, so you have to be prepared to have an ongoing relationship with those tools. The maintenance submissions far outnumber the original filing, so getting to know and trust the software companies that make those tools will be crucial to your success. There are point solutions, desktop solutions, web-based systems, hosted systems – the choices are many and varied.
Certainly, outsourcing is trending these days. There are some extremely capable partners with extensive eCTD experience out there. Do your homework, ask colleagues at industry meetings, go to message boards online. No software is perfect, and no vendors are perfect…but, some are better than others. This is a long term relationship you’re entering into, so do not take it lightly.
Be sure that the tools you select maximize your talent pool at your disposal. There are very few MS Word experts out there – so if you have one, maximize that potential and give the authors a break. Medical Writers in Pharma and Biotech do not need to be MS Word experts, but many operations groups do try to force them to be just that. They should be experts on science and data. Keep that in mind as you start to pull your submissions together.
In summary, much like building the best team, choosing the right tools that fit your needs is a very strategic and important decision. Look at all your options and choose wisely. Consider budget, long-term implications, and what makes the most sense for your situation before jumping into anything this big and in order to maximize the efficiency of electronic submissions.