Editor’s note: Jason Rock served as Project Lead for the HL7 RCRIM Expert Working Group that developed the Regulated Product Submissions (RPS) standard. This post is the first in a series on the Next Major Version (NMV) of eCTD, eCTD 4, which is based on the RPS standard.
Much fanfare has surrounded the Next Major Version (NMV) of eCTD or eCTD 4 since the group I chaired formed in 2005 and developed initial requirements for the standard. You’ve likely sat in on eCTD v4.0 presentations at industry conferences and heard secondhand of the deliberations, ballots and revisions going on behind the scenes. In short, we’ve all been waiting for things to happen.
Well, things have happened. As a member of the Expert Working Group (EWG) first tasked with developing eCTD 4, I’m proud to report that agencies, vendors and sponsors in each ICH region can get started on implementation. ICH announced that it had reached Step 4 and adopted a harmonized guideline on the eCTD 4 Implementation Package for Modules 2 through 5.
Let’s review some of the key concepts of eCTD 4 to get an idea of what will change when this standard is implemented down the road.
1. If you’ve ever said, “eCTD 4 aka RPS” that doesn’t tell the complete story. eCTD 4 is based on the Health Level Seven (HL7) standard called RPS. The RPS standard is intended for broader use as compared to eCTD and beyond life sciences, it could potentially support submissions for medical devices, veterinary, and other regulated products, such as tobacco.
2. Life would be easier for regulatory operations professionals if they could simply refer to files in an investigational application when compiling a marketing application. That’s no longer an issue, as eCTD 4 allows for document reuse. Each document is now assigned a unique ID that can be referenced as long as it’s in an Agency’s system. The file path is not needed.
3. The unique IDs that make document reuse possible are called Universal Unique IDs (UUIDs). Think of the UUID as a document’s Social Security Number. A UUID is a string of 32 characters separated by hyphens. For example, 2563f23-a3a4-4ce0-9994-99c5f074960f, is a valid UUID. The benefit of UUIDs is that they do not require any central support or maintenance and can be created instantly.
4. Typos in metadata can be easily fixed in eCTD 4. Users will have the ability to revise metadata previously submitted, e.g., related sequences, submission type, operation attribute, manufacturer name, etc.
5. Presently, sponsors can only send an eCTD sequence to an Agency. eCTD v4.0 introduces two-way communication. Now, an Agency is able to send correspondence to a sponsor, such as a request for information, as an eCTD sequence. The US FDA already announced its intention to include two-way communication in its regional implementation guide. Japan does not plan to implement two-way communication as part of eCTD 4.
6. As compared to eCTD v3.2.2, the Table of Contents (TOC) or hierarchy in eCTD 4 is not defined. Files are delivered in a flat structured and the Context of Use and Keywords are used to determine placement in the TOC.
7. While the majority of professionals publishing eCTD sequences use software to create submissions, there are still individuals creating and editing XML by hand. Now that the XML stylesheet doesn’t display a hierarchy of documents, working with and reading XML manually will be incredibly difficult if not impossible. eCTD 4 is likely the death of editing eCTD XML by hand.
8. Study Tagging Files (STFs) were developed to identify all files associated with a study for Modules 4 and 5. STFs are required in the US, not required in Europe, and not accepted in Japan. In eCTD 4, the function of STFs falls to Document Groups. Eliminating the STF is a win for global harmonization.
9. Document Groups let eCTD users group files together based on the nature of their use (e.g., clinical study reports). One use of document groups includes replacing STFs in Modules 4 and 5 to organize multiple files relating to a single clinical study as noted in the eCTD specification v3.2.2.
10. Context of Use is similar to a leaf and indicates the type of document. The code for each Context of Use specifies where documents are to be inserted into the CTD/eCTD TOC when presenting a reviewable structure.
11. Another major achievement of eCTD 4 is functionality to replace one document with many and vice versa. As users perform lifecycle maintenance on submissions, they can now alter the granularity of documents.
12. The Append lifecycle operator, designed as a way for applicants to update content already submitted, is set for official elimination with the release of eCTD 4. The sunset shouldn’t have much of an impact at all as Agencies have previously stated their opposition to use of this lifecycle operator. eCTD 4 does support the existing “new”, “replace”, and “delete” eCTD v3.2.2 lifecycle operators.
13. A few notable concepts included in eCTD 4 were already introduced with FDA’s New eCTD Module 1 v2.3 (DTD 3.3). The concepts include grouped submissions (grouping applications for several products into a single submission) and the use of metadata to indicate document type.
14. The ICH eCTD 4 Implementation Guide stipulates a single way to transition from v3.2.2 to 4. This is an additional burden with no value to either the sponsor or the agency. The stated objectives below are realized with a transition sequence. Applicants must submit a “Current View” of each application to transition all current content to v4.0 using one transition mapping message. The data elements sent forward will be used to enable the following two objectives: a.) maintain Context of Use lifecycle in new submissions/regulatory activities; b.) enable the reuse of documents within and across applications.
15. Agencies such as the EMA and FDA have hinted at pilot programs in 2017 but have yet to announce any actionable dates. It’s worth noting that applications won’t be required to resubmit data that’s previously been submitted using the eCTD 3.2.2 specification. And while we’re years away from blanket adoption of eCTD 4, expect Agencies to hold to previous precedents – if you transition to eCTD 4, future applications must use the same version, and at some point, eCTD v3.2.2 will be retired and all active applications transitioned.
16. Metadata plays a more prominent role with eCTD 4 and will be used for everything from application type to review status to type of document.
17. Controlled vocabularies are one of the essential components of eCTD 4 and will enable interoperability – i.e., clear, unambiguous communications between systems sending and receiving XML messages. Controlled vocabularies will be governed by multiple entities – ICH, regional authorities such as FDA and other, designated external organizations.