# Working with EU Regulatory Submissions (RIM)

When working with EU regulatory submissions, Submissions Publishing allows you to generate EU eCTD v3.0.1 DTD compliant XMLs for submission to the European Medicines Agency (EMA).

<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 Brexit

The United Kingdom (UK) formally withdrew from the European Union (EU) on January 31, 2020. The transition period began on February 1, 2020 and will end on December 31, 2020. As of January 1, 2021, Great Britain will be considered a third country to the EU. See [Brexit Impact in RIM Vaults](/en/lr/64524/) for more information, including some actions you can take in your Vault to continue licensing or to license new products in either the UK or the EU.

## About Procedure Types

When creating an EU _Application_, you must select a _Procedure Type_. Depending on the _Procedure Type_ selected, different countries are applicable for that _Application_:

  * **National**: A single country is selected for the _Application_ and _Submission_.
  * **Mutual Recognition Procedure (MRP)**: Two or more countries are selected on the _Application_, and the product is authorized in at least one country. In this case, you'll also need to select the _Common_ country.
  * **Decentralised Procedure (DCP)**: Two or more countries are selected on the _Application_, and the product is not authorized in any country. In this case, you'll also need to select the _Common_ country.
  * **Centralised Procedure (CP)**: The European Union or the European Directorate for the Quality of Medicines is selected as the country on the _Application_ and _Submission_.

## About Node Extensions

EU Submissions require node extensions instead of Study Tagging Files (STFs). To publish node extensions, you'll need to do the following:

  * Set the _Create Node Extensions_ field on the _Submission_ record to **Yes**
  * Define node extensions on the _Content Plan_ by setting the _XML Element Name_ field to **node-extension**
  * Enter a value in the _XML Title_ field on the _Content Plan_

<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>



### Copying a Content Plan for EU Submissions {#copy}

When [copying a content plan](/en/lr/37472/#copy-from-content-plan) from a US submission to an EU submission, Vault removes all US-specific data with the exception of the STF _Content Plan Item_ record to support other regions that accept STFs.

In order for the publishing process to work correctly for copied EU submissions, you must delete the STF _Content Plan Item_. You'll also need to set the _Continuous Publishing_ and _Continuous Validation_ fields **Yes** on all _Content Plan Items_.

## Submissions with Unreferenced Files {#unreferenced-files}

Submissions for EU eCTDs often include unreferenced files, also known as working documents. Working documents support the submission but aren't referenced within the XML. Organizations can import submissions into Vault containing working documents in the submission structure. See [Preparing Submissions for Import](/en/lr/64129/#how-vault-imports) for information about importing eCTD submissions with unreferenced files to RIM Submissions Archive.

### Content Plan Configuration

Vault includes an _Other_ (`other__v`) object type for all content plan objects (_Content Plan Template_, _Content Plan Item Template_, _Content Plan_, and _Content Plan Item_) to allow users to capture working documents within a child _Content Plan_ record under the root _Content Plan_.

An Admin must set the _Other_ object type to _Active_ on all content plan objects.

### Including Working Documents in Submissions

To include working documents in the submission structure, first navigate to the _Content Plan_ record:

  1. Set the **Name** to `${submission__v.xml_submission_id__v}` `working documents`.
  2. Scroll to the _Publishing Details_ section.
  3. Set the **XML Element Name** field to **unreferenced-files**. This indicates that all child _Content Plan Item_ records of this _Content Plan_ are working documents.
  4. In the **Title** (`xml_title__v`) field, enter `${submission__v.xml_submission_id__v}-workingdocuments` to set the _Content Plan Title_ to the name of the working documents section as it will appear in Submissions Archive.

Next, navigate to _Publishing Details_ section on the _Content Plan Item_ record and set the _Published Output Location_ field to `../${submission__v.xml_submission_id__v}-workingdocuments`.

You can also create additional unreferenced _Content Plans_ containing _Content Plan Items_ under the 'working documents' _Content Plan_. These must also have the _XML Element Name_ field set as defined above and the _Title_ field populated.

### About the Publishing Process for Submissions with Unreferenced Files

During the publishing process, for any _Content Plan Item_ record within the _Content Plan_ that has the _XML Element Name_ field set to **unreferenced-files**:

  * Vault excludes these _Content Plan Item_ records from the published XML
  * Vault does not apply validation criteria to these _Content Plan Item_ records

For each _Content Plan_ record that has the _XML Element Name_ field set to **unreferenced-files**, Vault also creates a section within the Submissions Archive binder using the _XML Title_ field value.

Upon publishing, these files appear within the Submissions Archive Binder structure. Any links from the submission to the working documents do not work. When you export the submission, Vault respects the _Source for Published Output Location_ field.
