Let's be honest — sometimes FDA guidance documents can be clear as, well, mud. And one of the quickest ways to find yourself a technical rejection from FDA's ESG is by getting your Module 1 Metadata wrong. But today we're going to help shed some light on how to get your metadata right and past that first validation hurdle.
The Purpose of FDA's Module 1 Metadata
Certain elements within FDA's Module 1 Metadata are designed to help keep submissions that are related to one another organized. Think of the metadata as a map to help FDA know where to look if they need historical information on your current submission.
Applicant Information
The first three items below are pretty cut and dry: ID element, company-name element, and applicant-contacts elements.
ID Element: This is the DUNS number assigned to your company by Dun & Bradstreet, and it should match the number you use in the User Fee system. Getting a DUNS number is free (unless you need it expedited). You can find out more on the Dun & Bradstreet website.
Company-Name Element: This is exactly what it sounds like -- your company's name. It should match what you use on the 1571 or 356h.
Applicant-Contacts Element: This is where you include information for regulatory, U.S. Agent, technical, and/or advertising & promotional contacts. You only need to include the contacts applicable to the submission. For instance, you may or may not have a U.S. Agent, depending on whether your company is located in the United States, and you'll only have advertising & promotional contact if you're submitting an advertising & promotional submission (typically only after approval of an NDA or BLA).
The last element in the Applicant Information might seem a little confusing, but hopefully this clears it up.
Submission-Description Element: This is an optional field allowing up to 128 characters that you can use to briefly describe the contents of the submission. Per FDA's guidance, it should be a high-level description of the purpose of the submission and also help differentiate between similar types of submissions. Because this information is optional, make sure you're not including info here that is not available elsewhere. Think of the submission description as an added courtesy, not as vital communication to the agency.
Application Information
Next up, you've got information about the application itself, and this is pretty straightforward too.
Application-Number Element: This is your six-digit application number, including any leading zeroes. You'll also choose the application-type attribute alongside inputting the application number (e.g., IND, BLA, NDA, DMF).
Cross-Reference-Application-Number Element: If your application is cross-referencing other applications that have already been submitted to FDA, you will input those six-digit application numbers here. Similar to the application-number element, you'll also choose the application-type attribute here for each application you're cross-referencing.
Submission Information
Now this is where things tend to get a little bit tricky. The information provided in the Submission-Information section determines how submissions get organized (or disorganized), and a misstep here can sometimes result in an immediate technical rejection. But once you understand how these three elements work together, you'll be set up for success.
Submission-ID Element: Back in the olden days of DTD 2.2, this was called the Related Sequence, and it was rarely used the way it was intended. The key here is understanding that the FIRST sequence for a given submission type (i.e., the start of a new Regulatory Activity) will typically be the submission-id going forward every time there's another submission of the same type. More on this in a minute.
Submission-Type Element: This is the overall category for your submission. The most common ones for an IND are Original Application, Annual Report, Product Correspondence, and IND Safety Reports. (You can see a complete list in Table 2 of the Module 1 Metadata guidance.) Each one of these marks the start of a new Regulatory Activity. (See where we're going with the submission-id element?) When you have a submission in one of these categories for the first time, the submission-id element will match the sequence number.
Submission-Sub-Type Element: Think of this as the sub-category to your Submission-Type's category. Your choices for Submission-Sub-Type will depend on the Submission-Type. For instance, for Original Application, the most common Sub-Types will be Presubmission, Original Application, and Amendment.
Let's look at a real-world example of how these three elements work together.
0001: PreIND Meeting Request
Submission-ID Element: 0001
Submission-Type Element: Original Application
Submission-Sub-Type Element: Presubmission
0002: PreIND Meeting Briefing Book
Submission-ID Element: 0001
Submission-Type Element: Original Application
Submission-Sub-Type Element: Presubmission
0003: Initial Application
Submission-ID Element: 0001
Submission-Type Element: Original Application
Submission-Sub-Type Element: Application
0004: IND Safety Report
Submission-ID Element: 0004
Submission-Type Element: IND Safety Report
Submission-Sub-Type Element: Report
0005: Protocol Amendment
Submission-ID Element: 0001
Submission-Type Element: Original Application
Submission-Sub-Type Element: Amendment
0006: IND Safety Report
Submission-ID Element: 0004
Submission-Type Element: IND Safety Report
Submission-Sub-Type Element: Amendment
0007: Annual Report (or DSUR)
Submission-ID Element: 0007
Submission-Type Element: Annual Report
Submission Sub-Type Element: Report
Note: Because you always need exceptions to prove the rule, and because each annual report is its own regulatory activity, each annual report's submission-id element will match its sequence number. You would only use Amendment if you were amending a previously submitted annual report (and your submission-id element would match the sequence number of the original annual report submission).
Conclusion
Getting a sequence's module 1 metadata correct is extremely important for the lifecycle of your application — as well as avoiding technical rejections. Spending some time looking through the descriptions and examples in the guidance (Tables 5 and 6 are a great resource) will be extremely helpful.
If you're looking for expert guidance on eCTD applications, The Sugar Water Operations Team is here to help. With 20 years of regulatory publishing experience, we can ensure you have the knowledge and expertise you need to achieve success with your submissions. Contact us for more information.