Test Scenario Team

DSTU – RPS 2 Test Scenario Team Remit

Objective: The objective of this team is to provide submission scenarios that allow for functionality testing of RPS R2. Test case scenarios will be developed in two phases. Phase 1 will present a basic/simple collection of sequences which represent a scenario of what is termed a “Regulatory Activity” for initial conceptual testing of an RPS message format to handle eCTD submissions. This will be followed by Phase 2, which will be a more complex and comprehensive set of submission scenarios which build on the Phase 1 Application.

Goals  Create a valid eCTD sequence which represents a complete NDA submission and exchange of information between an applicant and the FDA in eCTD format.

 Define testing parameters for initial sequence and for lifecycle sequences (tie in with Vocab Team)  Display of files by directory structure  Display of file by groups based on (a) sequence (b) metadata  Ability to send an RPS message to one party, and for that party send a message back to Applicant/Originator.  Ability to electronically reference leaf elements and entire messages outside of the application in question (eg, DMF – currently in eCTD we have to provide multiple leaf references instead of pointing back to entire module [see Questions]

Assumptions: This team will:  determine submission scenarios  determine modules to be included in each scenario  prepare documents for inclusion in those modules  define business success criteria for each test

Testing Assumptions:  Applicant and Agency will have the ability to uniquely identify previous submissions/submission units with the same identifier used by both sending and receiving parties to ensure clear communications  Applicant and Agency will have the ability to electronically relate single or multiple sequences to other single or multiple previous sequences.

Dependencies: Technology in place for uploading the test data May need to revisit scenario plan if Vocabulary team requires additional/specific testing

Risks: Delay if the technology is not ready Testing of lifecycle operations and handling of files is an implementation issue for software vendors. Timeline:

Co-leads create draft plan documentation: completion – prior to subteam meeting week of 3/15 Subteam meeting to review draft documentation: week of 3/29 Incorporate comments/finalize documentation: 4/21 Detailed listing of documents to be included in each sequence: 4/21 Completion of Dummy document creation for each module: 4/26 Upload documents to Gforge: 4/26 Completion for Phase I: 4/30

Phase 2 (complete complex submission scenarios) Co-leads create draft plan documentation: completion – prior to subteam meeting week of 5/10 Subteam meeting to review draft documentation: week of 5/10 Incorporate comments/finalize documentation: 5/17 Detailed listing of documents to be included in each sequence: 5/24 Completion of Dummy document creation for each module: 5/30 Completion for Phase 2: 5/30

Wish List  A viewing environment to work with test documents where we can also view lifecycle  DMF – We would like the ability to point to single leaf elements within the DMF and/or we would like to be able to easily point to the entire DMF application (R3 requirement?)  Hyperlink testing – Testing of basic hyperlinks, but this may be put off until RPS3.  Tools to automatically flag the documents as approved that are included within an ‘approved’ submission.  Logically group documents (eg, lifecycle on the section level; reference groups of files.)

Q&A:  Q: Will there be a handoff of the information to the technical team to build the submissions, or will the Test Scenario team perform the actual build in a centralized location? A: More of a partnership than a handoff. There will be "build teams".

 Q: How do we test the message functionality without testing the display/organization of files in a viewer? (ie, you can change eCTD metadata today and still create a valid sequence. It just also creates a new 3.2.S or 3.2.P to go along with the new metadata value). With RPS, we would want to physically change a piece of metadata, updating the current files and not creating new ones. (Add to testing Phase II?) A: It is important for the test team to be able to determine if the test goals are met. ie, to distinguish if the difference between functionality of the RPS message, or the application viewing the RPS message.

 Q: What are expectations for cross references? An electronic hyperlink within the word document that brings up a file that lives in the DMF application? Where does reviewer ‘click’ to reference the DMF? What is the reviewer hoping in terms of referencing an external application? A: Per Technical Walkthrough, it seems that for RPS2 there will only be the ability to cross reference to files, and not an overall external application. Anything that cannot be tested in R2 will be put into the R3 requirements for consideration.  Q: Is there specific information available on RPS2 above our current eCTD specifications (eg, extra/different metadata fields)? A: RPS Technical Walkthrough and implementation guide should provide us with the additional RPS requirements. Mark Gray has added controlled vocabulary to the spreadsheet.

 Q: How will current STF info be handled?  A: Info from STFs will be RPS keywords.

Outstanding Questions:

 How will Agency sequencing/numbers work? We know there is a unique ID (GUID or OID) on each document, but how will agency relate to a sequence, and what will this look like on Applicant end when received (incoming message for applicant)?

 How will agency enter the application number/NDA number? Make sure application number is visible; not just an ID.

 For Submission Metadata (at the Sequence Level) we have a contact name for the person sending the sequence. Will there be a field where a recipient can be identified (eg, a ‘To’ field that lists an individual or individuals that are to receive the message)? Note: RPS will allow more than one contact name to be entered.

 Will there be one set of testing information that FDA and applicants will pull from, then utilize RPS software that is available in each location?

 Should we point to leafs in a master file document or in the entire master file? Should Phase I include the entire master file and Phase II point to a specific document? (See Wish List above)

 How do we associate unique content to each application (eg, two FDA forms) in the same submission unit?

 For one submission unit for two different applications, how will the 2nd way communication come back in to the applicant and still apply to both sequences?

 Does the ‘submission type’ (eg, supplement) have to be the same for both applications? For example, If Application B is an NDA (supplement) and C is an IND (amendment), can one submission unit be delivered that is applicable to both?

 Withdrawal of supplement without having to delete each leaf – can a submission unit and all associated contents be withdrawn?  Is it possible to delete the submission unit to Application 1 and thus delete the new regulatory activity, without impacting the simultaneous submission to Application 2?  Is it a Delete of a regulatory activity?  Is it possible to delete the incorrect submission until in Application C without impacting the simultaneous submission to Application B, which is still valid?

Questions Related to Transitioning from ICH eCTD to RPS

 How to Reuse content in RPS previously submitted to Health Authority as part of ICH eCTDv3.2.2 sequences  How to add RPS submission units onto eCTD application started in ICH eCTD v3.2.2. Phase I Scenarios:

Regulatory Activity #1: Original NDA (with amendments) through to Approval

 Application A: Sequence 0000 – DMF Application Applicant to Agency (Action: Pam Cafiero) o Supply DMF information only; no further action on this application in Phase I.

 Application B: Sequence 0000 – Original NDA application Applicant to Agency (Action: Deanna Murden, Mary Padgett, Tracy Naughton)

Testing to include: o Study reports w/ Study Tagging Files o Display of multiple leaf elements under a single heading element o Creation basic metadata o Documents with hyperlinking/bookmarks o Reference to previously submitted information (DMF in Application A) o SPL files

 Application B: Sequence 0001 – Acknowledgement Letter/tracking number assigned Test of 2-way messaging Agency to Applicant (Action: FDA) Status = Submitted

 Application B: Sequence 0002 – Filing deficiencies letter Test of 2-way messaging Agency to Applicant (Action: FDA) Status = Filed

 Application B: Sequence 0003 – Applicant response to letter Applicant to Agency (Action: Debbie Sissons, Trina Trumpey, Ted Carpenter) o Testing to include: modifying documents, adding new documents, deleting documents

 Application B: Sequence 0004 – Approved letter Test of 2-way messaging Agency to Applicant (Action: FDA) Status = Approved

Phase 2 Scenarios:

Regulatory Activity #2: Supplemental NDA through to Approval

Tests to include:  Labeling negotiations/SPL  Changes to attributes in metadata (add complexities to metadata)  Additional manufacturing complexities – one submission unit referring to more than one product  Container closure elements – change product name, then have 2 NDAs  Add more messages from FDA to Applicant  Drug Master File from company other than Applicant (May be deferred to RPS3)  Related sequences - responding to Agency comments in multiple sequences  Add new formulation  Ordering of documents – sort key