Working with Submissions Publishing (RIM)

The Submissions Publishing application lets you prepare, finalize, and submit content within Vault in preparation for submitting content to a Health Authority. Content plans allow you to create a collection of documents when introducing a new product, or when changes occur on an existing product. You can then submit these documents to request approval to make changes to the product.

How Submissions Publishing Works

When introducing a new product or making changes to an existing product that requires a submission, you can create or update a content plan with a collection of documents that represent the changes made to the product. Once the documents are ready for submission, the continuous publishing and validation process begins. Vault will detect new and updated documents in the Published lifecycle state and publish these documents. Users can then view the documents in the Submissions Archive Viewer and send the documents for review, prior to submission.

The continuous publishing and validation process ensures changes to the source content are monitored and the published output is updated to reflect changes, such as additional links or new versions. Vault validates each document, providing feedback to the publisher. Publishers can then correct issues prior to sending content for final review.

You can also create link annotations and cross-document permalinks between documents within a submission. During the continuous publishing phase, Vault converts the link annotations to relative hyperlinks within the published document.

About Non-eCTD Submissions

Vault can publish and validate non-eCTD submissions when continuous publishing is enabled and the XML fields on the Submission record are set to N/A. When you set Enable Continuous Publishing to Yes, Vault:

• Publishes the submission content plan. Any Content Plan Items with the Node Type (xml_node_type__v) field set to Index-leaf or Regional-leaf should be made inactive before enabling continuous publishing.
• Publishes any Content Plan sections on which the XML Element Name field is blank, using the Content Plan record’s name as the section name in the published output
• Publishes the submission as non-eCTD, respecting the Dossier Format and its Parameter (when the DTD version is set to N/A), similar to importing a submission. See Defining the Submission Folder Hierarchy for more information on the parameter.

Creating & Publishing a Submission-Ready Dossier

To create a submission-ready dossier:

1. Navigate to Applications > Submissions and create a new Submission record or edit an existing one.
2. Fill in the Plan Template and Planned Submission Date fields. These field values determine which template to use when creating a Content Plan and the publishing priority for the submission.
3. To set a default overlay for this Submission record, select Set Default Overlay from the Actions menu. Vault only applies this overlay when no Publishing Elements exist on a content plan item.
4. From the Actions menu, choose Create Content Plan.
5. Match documents to Content Plan Item records. Depending on your configuration, Vault may automatically match documents. If you match a CrossLink document to a content plan item, Vault publishes the CrossLink’s source document or viewable rendition based upon the Source for Published Document field value as a standard document during publishing.
6. To allow Vault to generate a Table of Contents (TOC) document, open the appropriate Content Plan Item record and set the Node Type (xml_node_type__v) field to Table of Contents. In the Publishing Element field, select the TOC template. Repeat this step for each TOC that you want to include in your content plan.
7. To allow Vault to apply an overlay to your matched documents, open the appropriate Content Plan Item record and set the Node Type field to Leaf. In the Publishing Element field, select the Publishing Element that defines the overlay.
8. Create link annotations or dynamic links on your matched documents or Submissions Archive Content-type documents that were imported or published previously. During publishing, Vault gathers the link annotations from the documents and converts them to standard PDF links. Vault does not create links to any Submissions Archive Content documents that are currently being published. See also Working with Hyperlinks in RIM Submissions Publishing.
9. Review the applicable Content Plan Item records. For non-eCTD submissions, update the Status field to Inactive for any records where the Node Type is set to Index-leaf or Regional-leaf. Otherwise, you can set the Continuous Publishing and Continuous Validation fields to Yes on all applicable Content Plan Item records. Enabling continuous publishing and validation allows Vault to monitor, publish, and validate the associated Content Plan as needed. You should only enable continuous publishing when you are ready to publish.
10. Set your documents to Ready for Publishing.
11. Navigate to the Submission record and set the Enable Continuous Publishing field to Yes. This publishes the Submission to Submissions Archive.
12. Navigate to the Viewer tab to view your published output. Vault determines the submission dossier published output based on the Source for Published Document picklist.

In the Viewer tab, the Relative Filename section doesn’t appear in the published XML rendition for Study Tagging Files (STFs). This is caused by a defect in the stylesheet provided by the ICH.

Publishing Details

Navigate to the Viewer tab to access your published documents and their details. From here, you can view an outline of all your documents that you set to Ready for Publishing. The Actions menu on each of your published documents provides various user actions for reviewing your content. Published document details are based on the following Content Plan Item fields:

• Published Output Location: This field defines the folder path and filename of where the published document will reside. Vault uses it to create standard PDF links with a relative path from Microsoft Word inter-document links and Vault link annotations.
  • When editing this field, you must include the folder path in addition to the filename. For example, use m1/1-2-cover/cover.pdf instead of cover.pdf.
  • Depending on your configuration, this field may already be populated and may not appear on your Content Plan Item page layouts.
  • The Published Output Location field has a 100-character limit. If it exceeds the character limit, Vault cannot publish or publish/merge. Additionally, characters cannot be controlled characters (non-printing characters). If such characters are present, Vault errors when the field is updated or when attempting to change the record’s lifecycle state.
  • This value should be unique when publishing to the Submissions Archive Viewer, unless the same document has been matched multiple times to a Submission Content Plan. In this scenario, Vault duplicates the Published Output Location for all Content Plan Items with the same matched documents.
• Published Document: Vault populates this field with a link to the published document based on the matched document. The published document is created from the matched document’s version at the time of publishing and always links to the latest version.
• Source for Published Document: This field defines the rendition or source document to be used as the published document. For example, if you specify Viewable Rendition as the source, Vault uses the viewable rendition of the matched document as the source to create the published document. Custom rendition types can be configured if needed. The source for the published document must correspond to the filename extension specified in the Published Output Location field. For example, if you specify Source Document as the source, and the matched document extension is .docx, the published output location filename should have .docx as the extension. In Vaults where a connection is configured, when you specify the source document as the Source for Published Document, Vault retrieves and publishes the file from the source Vault.

These fields are defined by your Admin’s Content Plan Item Template configuration. However, based on your permissions, you can use inline editing to modify the Published Output Location and Source for Published Document fields from the Content Plan Hierarchy Viewer or edit them directly from a Content Plan Item record.

Document Fields

During publishing, Vault also copies some field values from source documents to published documents. Vault can copy values when fields with the same Name and field type exist on both the source document type and the Submissions Archive document type. Vault does not copy values to the Ready for Publishing field, document type fields, Application or Submission fields, archive fields, or any fields that the publishing process populates, such as Title.

Working with Published Content

After your submission content is finalized, various user actions in Vault support the submissions publishing flow.

The following options are available from the Actions menu for documents published from Content Plans:

• Open Content Plan: Opens the associated Content Plan for the published document.
• Open Content Plan Item: Open the associated Content Plan Item for the published document.
• Open Source Document: Opens the source document used to create the published document.

The following options are available from the Actions menu of Content Plan and Content Plan Item records:

• Open in Submissions Archive: Opens the submission in the Viewer tab from a content plan
• Open Published Document: Opens the published document
• Run On-Demand Validation: Runs the validation process
• Run On-Demand Publishing & Validation: Allows users to publish in the event that there is an issue that stops publishing from running
• Select Leaf Operation: Allows users to target a leaf from a prior submission of the same application from within an eCTD Content Plan
• Generate Publishing Table of Contents: Generates or recreates a Table of Contents (TOC) document from the template referenced on the related Publishing Element record and matches it to the Content Plan Item

Continuous Publishing

Continuous publishing improves the submission delivery process by incorporating publishing activities throughout content development. This process allows you to continuously publish documents as they become associated with a Content Plan and as updates occur on related content.

When continuous publishing is enabled, Vault:

• Creates the Submissions Archive-type binder and checks all matched documents to verify which ones are set to Ready for Publishing.
• Monitors the source documents for version changes and annotation updates such as new, modified, or deleted links.
• Publishes the documents to Submissions Archive based on the selected source document setting.
• Creates a Source References relationship between the source document and the published Submissions Archive document.

Continuous Publishing Prioritization

Vault automatically prioritizes continuous publishing jobs based on the value in the Planned Submission Date field on the Submission record. Continuous publishing jobs where the Planned Submission Date is in the next two (2) days will receive the highest priority.

Continuous Validation

Continuous validation provides the ability to verify an eCTD submission, based on the Health Authority acceptance criteria, during submission assembly in Vault. While validation typically occurs after fully publishing a document, continuous validation allows you to validate and make corrections during submission assembly and as content becomes available. This provides the necessary information regarding validation errors and warnings earlier in the process.

Setting Validation Conditions

Continuous validation conditions are dependent on a regional DTD/XSD version and a corresponding validation criteria version. The validation version determines which rules are applicable for the corresponding submission. You can set these conditions by specifying a regional DTD/XSD version in the Validation Criteria Version field on a Submission record. Note that your Admin determines the corresponding validation criteria for the specified regional DTD/XSD version.

Validation Process

Vault performs continuous validation when the Continuous Validation field is set to Yes on a Content Plan Item, and whenever the published document and/or related metadata is updated, including metadata affecting the published XML files.

Submission Validation Results

After performing validation, Vault creates a Submission Validation Result record for each validation criterion on each Content Plan Item. You can view these from the Submission Validation Results section on the Content Plan Item record details page. If you turn off Enable Continuous Publishing and then enable it again, Vault deletes and recreates all Submission Validation Results records. This allows you to update the validation conditions for a submission.

Vault also archives all Submission Validation Result records into a single XML file 365 days after the submission is complete so you can reference validation results without cluttering your Vault with unnecessary object records.

See Working with Submission Validation Results for complete details about validation results.

On-Demand Publishing & Validation

On-demand publishing allows you to publish documents after continuous publishing has been disabled or force publishing for a specific content plan section or item. In most cases, we recommend that you allow Vault to handle all publishing jobs via continuous publishing.

Using On-Demand Publishing & Validation

When you use the On-Demand Publishing & Validation action, Vault runs publishing and validation on any documents that contain hyperlinks to the published document. This allows Vault to keep all document links current throughout the on-demand publishing process.

Running on-demand publishing from the content plan’s root deletes all of the published output and recreates it. Starting on-demand publishing from a content plan item runs the publishing job on the related documents, regardless of the values in the Continuous Publishing and Continuous Validation fields on the record or the Ready for Publishing field on the document.

Link Publishing

During publishing, Vault compiles the link annotations and dynamic links within the document and converts them to standard PDF links with relative paths to the target documents, determined by the Published Output Location (xml_xlinkhref__v) field within the same submission and application.

See Working with Hyperlinks in RIM Submissions Publishing for more information.

Working with Tables of Contents (TOCs)

Publishing a Table of Contents

When you first publish a content plan, Vault automatically performs the following actions for any Content Plan Item records with the Node Type (xml_node_type__v) field set to Table of Contents:

• Generates and publishes a TOC document, using the related Publishing Element record to determine the TOC template. When applying the overlay, Vault currently only selects the viewable rendition, regardless of the Source for Published Document value.
• Classifies the TOC document based on the value in the Document Type Detail field on the Content Plan Item
• Sets the Ready for Publishing field to Yes on the TOC document
• Matches the TOC document to the Content Plan Item; if a document is already matched, Vault versions it

If a Table of Contents is placed at the top, in the middle, or at the bottom of a Content Plan section with Content Plan Items that are merged, Vault accurately reflects the overall page numbering of the Table of Contents on the top level Content Plan section row of the Table of Contents.

During continuous publishing, on-demand publishing, or when you select the Generate Publishing Table of Contents action, Vault regenerates, versions, and, if continuous publishing is enabled, publishes the TOC document. Continuous publishing occurs any time a document referenced by the TOC document is published, versioned, matched to a Content Plan Item record, or when the Published Output Location, Publishing Element, or document metadata are updated.

If you update the Node Type (xml_node_type__v) field on the Content Plan Item, Vault deletes or generates the TOC document accordingly. If you update the TOC template, you’ll need to use the Generate Publishing Table of Contents action to regenerate the TOC.

Editing a Table of Contents

You can update the elements that make up the TOC from the content plan viewer without editing any matched documents by using the Edit Table of Contents action.

When you execute the action from the content plan viewer or Content Plan Item Actions menu, Vault displays a hierarchical outline of the table of contents structure. The hierarchical outline shows the TOC’s Content Plan, Content Plan Item, and PDF bookmark components for viewing, filtering, and updating within the TOC editor.

Navigating the TOC Editor

By default, Vault displays all Active and Inactive TOC components. Click the Hide Inactive button to remove any Inactive components from the view, and Show Inactive to display them again. This action is useful for activating and inactivating items in bulk during your editing session.

You can Expand hierarchy items with child items below it by selecting the option from the item’s Actions menu. You can also filter and search within all displayed columns.

Editing the TOC

You can apply changes to hierarchy items through each item’s Actions menu. You can also use inline editing to modify an item’s name as it appears in the TOC. Some actions may be unavailable for the indicated TOC components.

• Select Activate to include or Inactivate to exclude an item from the generated and published TOC. You can also select Activate all below to perform the action on the item and all its descendants. Selecting Inactivate will automatically inactivate all items below it. Selecting Activate will automatically activate all inactive items in the parental hierarchy.
• Select Reset all below to remove edits from the item where you selected the action, in addition to any child items within the selected section. This action is not available for bookmarks.
• Select Include bookmarks to defined level within any item (except bookmarks) and enter the number for the Level at which to activate document bookmarks. All other bookmarks are inactivated.
• Select Include all to defined level from the root of the hierarchy and enter the number for the Level at which to activate items. All other items outside the level range are inactivated.

Reordering PDF Bookmarks

You can rearrange PDF bookmark TOC items using bookmark-specific actions.

When you Promote or Demote an item, Vault relocates it up or down one level in the hierarchy:

• Promote moves the item and its children to the left and up one level in the hierarchy, but in the same position.
• Demote moves the item and its children to the right and down one level in the hierarchy, but in the same position. This option is available only when there is a sibling directly above the item to be demoted.

When you select Move Up or Move Down, Vault relocates it above or below the adjacent TOC item:

• Move Up moves the item and its children above the item directly above it, within the same level in the hierarchy. Siblings directly above the item are unaffected.
• Move Down moves the item and its children below the item directly below it, within the same level in the hierarchy. Siblings directly below the item are unaffected.

Ending the Editing Session

While the TOC is open for editing, Vault records overrides made during the editing session. When you conclude an editing session, Vault returns you to the viewer or Content Plan Item from which you launched the editor, then handles overrides based upon the option selected:

• When you select Close, Vault discards all changes made during the session.
• When you select Reset, Vault discards all changes made during this session and all other sessions, then generates and up-versions the TOC document. Following the update, Vault also triggers on-demand publishing to re-publish the TOC for Submissions in Submissions Publishing where continuous publishing is not enabled.
• When you select Generate, Vault applies all changes made during the session, then generates and up-versions the TOC document. If the TOC was previously published and its related Submission does not have continuous publishing enabled, Vault also triggers on-demand publishing to re-publish the TOC.

Overlay Publishing

When a PDF document is published as part of a submission content plan publish request, Vault applies the overlay defined in the content plan item’s Publishing Element record. If no Publishing Element exists on the content plan item, Vault applies the default overlay. If the Publishing Element exists but does not define an overlay, Vault does not apply an overlay.

You can also use the Source of Published Overlay picklist field on the Publishing Element record to populate Overlay token values based on Source Document values rather than Published document values. When merging published output, this resolves the Overlay tokens with different values per Source matched to the Content Plan Item(s). By default, if no Source of Published Overlay picklist is defined on the Publishing Element record, Vault assumes the overlay token values are taken from the Source matched document on the Content Plan Item.

To prevent unnecessary continuous publishing operations, Vault updates overlays on previously published documents only when you do one of the following:

• Update the Default Overlay field on the Submission record. This only re-publishes content plan items that don’t reference a Publishing Element.
• Update the Publishing Element field of a Content Plan Item record.

Updating the Overlay field on a Publishing Element record does not re-apply the overlay to previously published documents and only affects future documents. To apply the new overlay, you must re-publish the Content Plan Item using the On-Demand Publishing action.

eSignature Publishing

By default, Vault does not include eSignatures in published content plans. To include eSignatures, set the Content Plan Item object field Include eSignatures to Yes.

Selecting a Leaf Operation Target

You can use the Set Leaf Operation action to select a leaf node to lifecycle from a prior submission in the same Application (Replace, Delete, Append). If a document has been replaced more than once, only the current submitted version may be selected for additional lifecycle operations.

When a Content Plan Item record does not have an XML Operation field value, you can set the operation as New. Upon saving, Vault sets the record’s XML Operation value to New.

When you select the Delete operation, Vault sets the record’s XML Operation value to Delete upon saving, then clears the Published Output Location field during publishing. Vault also publishes a placeholder in Submissions Archive to indicate the lifecycle operation.

For any leaf with an XML Operation of Delete, Vault clears the Published Output Location upon publishing.

How to Select a Leaf Operation Target

1. From the Content Plan Item’s Actions menu, select Set Leaf Operation. This opens a dialog to the current view of the application and section based on your current location within the Content Plan. This dialog is similar to the Submissions Archive Viewer tab and allows you to use filters to refine the list of submissions.
2. In the Select Leaf Operation Target dialog, choose the desired XML Operation and leaf. Vault populates the selected leaf below the Leaf Operation Target heading in the dialog.
3. Click Save.
4. Vault populates the XML Modified File field with the selected leaf node. You can edit this field if necessary.

To undo a mistaken selection in an in-progress submission, repeat the above steps.

To view and lifecycle STFs, launch the Set Leaf Operation action from an STF node, or filter to a single Submission.

Related Permissions

To allow users to set a leaf operation, your Vault’s permission sets and field security configuration must include the below.

Permission Set

Users must be assigned to a security profile containing a permission set with Read access to the following objects:

• Application
• Submission
• Content Plan
• Content Plan Item
• Submission Metadata

Field Permissions

Users must have Edit or Read access to the following Content Plan Item object fields:

• Primary Application
• Primary Submission
• XML Modified File
• XML Operation

Optional Object Permissions

When a user opens the Set Leaf Operation dialog, Vault auto-expands the view to the documents they are most likely to choose, based on their object permissions.

Including Read and Edit access to the below objects in users’ permission sets allows Vault to be more precise when auto-expanding in all scenarios:

• Active Substance
• Clinical Study
• Country
• Inactive Ingredient
• Nonclinical Study
• Pharmaceutical Form
• Product
• Submission Clinical Study
• Submission Nonclinical Study
• Therapeutic Indication

Setting a Reference Leaf

A reference leaf is a file that has already been submitted but needs to appear in the XML backbone to indicate it is part of the current submission. You can use a previously-submitted and reviewed Submissions Archive document as a reference leaf, reducing the review time at the relevant Health Authority. Vault supports reference leafs to documents in previous submissions within the same application or to documents in separate applications with the same Lead Market.

See Setting a Reference Leaf for detailed instructions.

Publishing Progress

Vault automatically updates the status indicator icon (or harvey ball) in the Publishing Status field to inform you if there are outstanding publishing or validation jobs as part of continuous publishing. This ensures that you only review and submit content after it has been published and validated.

You can see publishing status for the entire content plan, content plan sections, or individual content plan items. See Viewing Publishing Progress for details.

About the System User & Published Content Owner

Vault determines a published document’s Owner based on the Published Content Owner on the Content Plan’s related Submission record.

Additionally, Vault sets other roles on the published document based on roles assigned to the source document. If the Published Content Owner is assigned to other roles on the source document, those roles are added to the published document and assigned to the Published Content Owner. If the source document has other roles on it and there is no Published Content Owner on the Submission record, the users assigned to the roles on the source document are copied to the roles on the published document.

Example: Same Published Content Owner & Reviewer

If the Published Content Owner is set to Jane Doe, and Jane Doe is also the Reviewer on the source document, Jane Doe is added to both the Owner and Reviewer roles on the published document.

Example: Different Published Content Owner & Reviewer

If the Published Content Owner is set to Jane Doe, and John Smith is a Reviewer on the source document, Jane Doe is added to both the Owner and Reviewer roles on the published document.

Example: Blank Published Content Owner

If the Published Content Owner is not set and Jane Doe and John Smith are both Reviewers on the source document, Jane Doe and John Smith are Reviewers on the published document.

If you don’t select a user (the value is blank), Vault executes the submission publishing process as System User instead of the user who initiated the action.

To prevent job failures, users selected as the Published Content Owner must be licensed for the RIM Publishing application and be permitted to create documents of the Submissions Archive document type.