# Working with JP Regulatory Submissions (RIM)

When working with Japanese regulatory submissions, Vault can generate JP eCTD XSD 1.0 compliant XMLs for submission to the Pharmaceuticals and Medical Devices Agency (PMDA). Submissions Publishing also provides additional functionality to continuously update the cumulative submission XML to contain the complete snapshot of all documents from all submission versions. Vault validates these submissions in accordance with the JP PMDA 1.0 Validation Criteria Version.

Japanese eCTD 1.0 submissions must be queued for import in the order in which they are published and submitted to the Health Authority. This ensures that leaf lifecycle operations display properly and cross-document navigation functions as expected. If you remove and re-import submissions, you must also remove and re-import subsequent submissions in the application. This is only applicable for eCTD submissions.

Vault currently supports publishing and validation for the Japan (JP) 1.6 eCTD 4.0 regional specification versions.

  <div class="note-border alert-info">
  <div class="alert alert-info" role="alert">
    <div><i class="far fa-info-circle"></i></div>
    <div class="alert-text">
      <p><strong>Note</strong>: This feature is only available on RIM Submissions Publishing Vaults.</p>
    </div>
  </div>
</div>



## About Node Extensions & Study Tagging Files

The Japanese eCTD specification prohibits Study Tagging Files (STFs) and highly discourages node extensions.

<div class="note-border alert-info">
  <div class="alert alert-info" role="alert">
    <div><i class="far fa-info-circle"></i></div>
    <div class="alert-text">
      <p><strong>Note</strong>: The title of a node extension or STF is controlled by the <em>Content Plan Title</em> field. The title field has a limit of 1500 characters. However, for publishing of STF and node extensions a hard limit of 255 characters is enforced.</p>
    </div>
  </div>
</div>



## About Content Plans for Japanese Submissions

After the initial submission is published, users can create subsequent submission content plans that contain new nodes or content plan items to make corrections and updates to the original version. Each time an update to the submission is published, Vault regenerates the cumulative XML backbone to contain all content plan leaves and documents from the previous submissions as well as the current submission.

### Working with Content Plans

Because Japanese submissions are sequential and publishing assumes that past submissions are no longer subject to change, you must set the _Enable Continuous Publishing_ field to _No_ on any _Submission_ records that have already been submitted.

The Japanese regional XML also requires that you include all nodes in the initial submission, even if there are no underlying documents. When you create the initial submission, it is important that the root content plan contains all of the relevant content plan sections within Module 1. This will ensure that Vault generates a regional XML that includes the content plan sections, even without underlying content plan items.

Note that you should not include a content plan item for the _cover.pdf_ file in the Module 1 content plan section. The _cover.pdf_ file contains an MD5 checksum for the Index XML, and you cannot include it in advance. Instead, you must add this file to the published output manually.

### Copying a Content Plan

When [copying a content plan](/en/lr/37472/#copy-from-content-plan) from a submission for another country, Vault removes all country-specific data, including STFs.

## eCTD 4.0 Support

### Generating Table of Contents

Publishing supports the creation of a Table of Contents document with the heading _jp\_m1.1_ for Japan eCTD 4.0. Vault allows a _Content Plan Item Node Type_ (`node_type__v`) value of `table_of_contents__v` for a _Context of Use_, and generates a _Priority Number_. A checksum (_sha-256_) is included for the Table of Contents on the _submissionunit.xml_. The Table of Contents is automatically generated and handled as a replace operation if a previous Table of Content exists.

### Automated Sequence ID Generation

Automated Sequence ID generation for eCTD 4.0 submissions looks at previous eCTD 3.2 sequences and increments the next sequence by 1 (dropping any leading zeros). For example, the last submission in an application that was submitted with eCTD 3.2 was "0045". When creating the first eCTD 4.0 submission for the same application, the automatically generated Sequence ID will be set to "46" (instead of 0045). In an eCTD 4.0 application, the automatically generated Sequence ID is set to "1" if there are no previous sequences.

### Cover Letter Handling

When publishing eCTD 4.0 submissions, Vault supports the _XML Element Name_ \= unreferenced-files. The Japan eCTD 4.0 Content Plan includes a Content Plan Item in Module 1 for the Cover Letter (Published Output Location \= m1/jp/cover.pdf). The unreferenced-files are not included in the submissionunit XML upon publishing, but are included in an unreferenced files section under Module 1 in the Submissions Archive Viewer.

## Viewing & Managing Submission Administrative Information

Vault supports viewing and managing Submission Administrative Information for JP 1.0 XSDs. See [Managing Submission Administrative Information](/en/lr/52665/) for details.

### Additional Submission Types

Japanese applications often include multiple submissions. After the first submission, subsequent submission updates are used to correct or add information to the original submission version.

In the Submission Administrative Information viewer, Vault automatically populates the _Primary Submission Type_. Vault also supports additional submission types. Open the Submission Administrative Information viewer and update the _Additional Submission Types_ field to apply these types.