# XEVMPD Data Review & Validation (RIM) Vault can aggregate eXtended EudraVigilance Medicinal Product Dictionary (XEVMPD) data for you, offering a simple way to compile product data before submitting it to the European Medicines Agency (EMA). Vault parses data from _Medicinal Product_ and other objects and organizes it according to the Article 57 guidance defined by the EMA. Data displays in a hierarchical report for easy review. When generating the report structure, Vault performs validation to verify that the data adheres to business rules based on the XEVMPD validation criteria. Vault can also aggregate XEVMPD data into the Extended Eudravigilance Product Report Messages (XEVPRM) format. Organizations can then electronically submit medicinal product data to the XEVMPD through the EMA gateway directly from Vault. Admins must perform configurations before you can work with XEVMPD data. See [XEVMPD Configuration](/en/lr/58680/) for details.
## XEVMPD Objects {#objects} Vault uses several objects to track, compile, and organize product data: * **Product Data Submissions** track product reports. * **Product Reports** gather data from various other RIM objects (_Medicinal Product_, _Registration_, _Classification_, etc.) and display it in a hierarchical report. * **Product Report Items** house product information such as labels and attachments. * **Ingredient Product Report Items** track data related to the ingredients of an authorised product. * **Medicinal Product Registrations** link the registration and packaging information to medicinal products. * **Controlled Vocabularies** store lists of industry terms owned by and sourced from various global health authorities. * **Publishing Validation Criteria** stores the XEVMPD business validation rules as defined in Article 57 guidance. * **Product Report Validation Result** is a child object of _Product Data Submission_ and tracks the number of validation results discovered per _Product Report Item_ section. * **Validation Result Detail** tracks the detailed validation rules violated in the product report data. * **Product Data Message** is a child object of _Product Data Submission_ and captures the message specific details. This object also serves as a location to attach the generated XEVPRM ZIP file and contains fields for tracking progress and EMA responses after submitting XEVMPD data to the EMA gateway. * **XEVMPD Acknowledgement** allows you to see all acknowledgement responses in the same place after submitting XEVMPD data to the EMA gateway. ## Working with Medicinal Products Before you generate a product report, you'll need to do the following: * Relate the _Medicinal Product_ record you want to report on to at least one _Registration_ record using the _Medicinal Product Registration_ join object, as well as _Packaging_ information if your _EV Codes_ exist at the packaging level. * If your product is centrally authorised, create one _Medicinal Product_ record for each licensed product and one _Medicinal Product Registration_ record for each combination of _Registration_ and _Packaging_ for the European Union, Iceland, Norway, and Liechtenstein, as well as one _Medicinal Product Registration_ record for each combination of _Registration_ and _Packaging_ for each of these countries. A centrally authorised product with one packaging configuration should have four _Medicinal Product Registration_ records. * If your product is authorised through a mutual recognition procedure (MRP), decentralised procedure (DCP), or national procedure, create one _Medicinal Product_ record for each authorised product in each country, and related _Medicinal Product Registration_ records for each packaging configuration and local language. For example, a product registered in Belgium through DCP with two packaging configurations should have six _Medicinal Product Registration_ records, one for each combination of packaging configuration and language (Dutch, French, German) required for Belgium. * Relate at least one _Administered Product_ record and at least one _Medicinal Product Full Name_ record to the target _Medicinal Product_ record. ## Working with Product Reports A _Product Report_ consists of two levels of detail: _Product Report_ records are the structural elements that make up the sections of the report, while _Product Report Item_ records house detailed data. ### Creating a Product Report To generate a product report: 1. Create a _Product Data Submission_ record from the target _Medicinal Product_ record detail page. 2. Enter required information. Vault uses _Controlled Vocabulary_ records to populate the default _Operation Type_ for all product reports generated from this _Product Data Submission_ record. You can override this information on the _Product Report Item_ records if needed, for example, if withdrawing or nullifying one packaging configuration. 3. From the _Product Data Submission_ record's **Actions** menu, click **Create Product Report**. This action may have a different name depending on your Vault's configuration. This process is asynchronous, allowing you to perform other tasks while Vault generates your report. Vault sends you a success or failure notification after generating your product report, including a detailed CSV file that indicates which elements have missing or incorrect data. Note that this is simply a set of warnings, and some missing fields may be expected for your specific product. Vault also validates the aggregated data against Article 57 business validation rules while generating your product report. See [validation details][3] below. ### Viewing a Product Report Click **View Product Report** from the _Product Data Submission_ record's **Actions** menu to view your report. This action may have a different name depending on your Vault configuration.
### Product Report Values This table shows a summary of the values Vault uses in a product report:
Product Report Record Label Action upon Report Generation
Attachment Element Vault creates a Product Report record and one Product Report Item record within that record for each document that should be attached to the message.
Authorised Product Element Vault creates a Product Report record and one Product Report Item record of this type for each registration and packaging combination, as well as each language associated with the medicinal product.
Authorisation Element Vault creates a Product Report record and one Product Report Item record of this type for each registration and packaging combination associated with the medicinal product.
Presentation Name Element Vault creates a Product Report record and one Product Report Item record of this type for each registration and packaging combination, as well as each language combination associated with the medicinal product.
Pharmaceutical Product Element Vault creates a Product Report record for each Administered Product.
Active Substance Element* Vault creates a Product Report record of this type and one Product Report Item record within that record for each active substance referenced by Product Variant (product_detail__v)* or Administered Product.
Adjuvant Element* Vault creates a Product Report record of this type and one Product Report Item record within that record for each active substance related to Product Variant (product_detail__v)* or Administered Product and marked for adjuvant use.
Excipient Element* Vault creates a Product Report record of this type and one Product Report Item record within that record for each inactive ingredient referenced by Product Variant (product_detail__v)* or Administered Product.
Administration Route Element* Vault creates a Product Report record of this type and one Product Report Item within that record for each route of administration referenced by Administered Product.
Therapeutic Indication Element Vault creates a Product Report record and one Product Report Item record within that record for each Coded Indication record related to Medicinal Product.
Classification Element Vault creates a Product Report record and one Product Report Item record within that record for each Classification System record related to Medicinal Product.
Previous EV Code Element Vault creates a Product Report record and one Product Report Item record within that record for each previous EV code listed on Medicinal Product Registration. Vault repeats this for each unique combination of Registration, Packaging, Country, Language, and previous EV Code records.
*Vault creates these records within the _Pharmaceutical Product Element_ record. See the XEVMPD Field Mapping file for additional information about how Vault creates product reports. You'll need to ensure that you populate all necessary fields on the objects indicated above. Vault notifies you of which areas are missing information when you generate the report. ## Product Report Validation {#product-report-validation} When generating a product report, Vault performs validation to verify that the data adheres to business rules based on the XEVMPD validation criteria and Article 57 guidance defined by the EMA. If you or your Admin haven't [loaded validation terms](/en/lr/58680/#controlled-vocabulary), Vault generates the product report structure but does not perform validation.
### Validation Process When validating product report data, Vault creates a _Product Report Validation Result_ record, which acts as a summary record of all validation failures for the related _Product Data Submission_ record. Within the _Product Report Validation Result_, Vault creates one _Validation Result Detail_ record for each _Product Report Item_ record within a product report that violated a validation rule. Each _Validation Result Detail_ record lists the exact validation criteria violated for that _Product Report Item_ record. Vault also increments the number of validation rule failures in the _Count_ field on the _Product Report Validation Result_ record. If no rules were violated, Vault doesn't create records. Each time validation runs, Vault deletes the existing _Product Report Validation Result_ record and its child _Validation Result Details_ records before creating new records. ### Validating Product Report Data Vault performs validation immediately after creating the product report, as part of the product report generation process. You can also choose to validate product report data after Vault has generated the product report tree. This allows you to make changes to the product report data to close out initial validation errors without needing to re-generate the product report tree structure. To validate a product report on demand: 1. Navigate to the _Product Data Submission_ record. 2. From the **Actions** menu, select **Validate Product Report Structure**. 3. Vault performs validation and sends you a notification when complete. ### Viewing Validation Results To view the most recent validation results, navigate to the _Product Data Submission_ record and expand the **Product Report Validation Result** section. Click a result name to view the individual _Validation Result Detail_ record. Vault also includes links to the _Product Report Validation Result_ records in the product report email notification. ## XEVPRM Message Generation {#xevprm} Vault can display product data and create discrete XEVPRM messages in the form of a ZIP file with an XML and attachments. Vault transposes the aggregated XEVMPD product report and product report item data into one or more XML files and validates each XML against XSD schema. The XEVPRM comprises field values provided by RIM Registrations users as well as values from controlled vocabularies that are maintained by the EMA, such as terms and EV codes. Vault pulls data from the _Product Report Item_ record text fields to create one new _Product Data Message_ record and one XEVPRM message for each selected _EV Code_ or _Local Number_ related to the product report structure. Vault validates all data in the product report tree structure against the XEVMPD validation rules in the _Publishing Validation Criteria_ records during XML message generation to log any validation data errors. ### Creating the XEVPRM for a Product Data Submission To generate the XEVPRM: 1. Navigate to the _Product Data Submission_ record. 2. Select **Generate XEVPRM** from the **Actions** menu. 3. On the **Refine Selection** page, use the checkboxes to select all **EV Codes** or **Local Numbers** for which you want to generate the XML. Vault lists all _EV Codes_ or _Local Numbers_ from the related _Authorised Product_ type _Product Report Item_ records. 4. Click **Next**. 5. On the **Verify Information** page, select the **PPI Attachment Format**, and set the checkbox below to confirm that the attached PPI is the latest version. 6. Click **Next**. 7. On the **Confirmation** page, review and click **Finish**. When complete, Vault generates the XML, creates _Product Data Message_ records, and sends a success notification with links to the technical validation results. Vault only creates a technical validation results file when the generated XML contains errors. Vault only sends a failure notification if XML generation fails. ### XEVPRM Generation {#xevprm-generation} Vault generates the XEVPRM as one ZIP file, with the naming structure `{EVCode/Local Number}-{Operation}`, for example, `65738-Update.zip`. The ZIP file contains the XML file for the generated XEVPRM and includes viewable renditions for all new attachment files in the format you selected. Vault attempts to attach PDF renditions of attachments first. If a PDF isn't available, Vault uses the source format. You can view the XEVPRM ZIP file and, if available, the XSD validation file from the _Product Data Message_ record. You cannot generate the XEVPRM if the _Product Data Submission_ record has a related _Product Data Message_ record that is part of an [active submission to the EMA Gateway][7].
### XML Validation {#xml-validation} Vault stops running XML technical validation if an error occurs, and includes a line item indicating where the error occurred for each failure. If an XML element is missing, Vault links the error to the next available element. You must ensure that fields associated with that element are populated before re-generating the XML. Subsequent elements may also be missing values. We recommend reviewing the list of missing values after Vault generates the product report structure to ensure successful XML technical validation. ### Multi-Language Handling In some scenarios, the attachment to the XEVPRM should be provided in multiple languages. Attachment _Product Report Item_ records are created for a _Product Data Submission_ when the document fields reference the _Medicinal Product_. The _Language_ field on the Attachment _Product Report Item_ record is based on the _Language_ field assigned to the document. Vault uses the Attachment _Product Report Item_ records to determine which documents to include in the XEVPRM ZIP file. For example, in a Centralised procedure, the English language attachments should always be provided along with the EEA country local language attachments. Vault handles attachment languages as follows: **Centralised Procedure** * Vault always includes the attachment in English. * Vault also includes attachments in the languages referenced on the _Medicinal Product Registration_ records (Norwegian, Icelandic, and German). * Vault also includes attachments in any languages related to the _Country_ record through a _Country Language_ join record. **MRP/DCP Procedure** * Vault includes attachments in the languages specified on the _Medicinal Product Registration_ records. * Vault also includes attachments in any languages related to the _Country_ record through a _Country Language_ join record. * If no Attachment _Product Report Item_ record is found for the language on the _Medicinal Product Registration_ records, Vault looks for and includes an Attachment _Product Report Item_ record in English, if available. **National Procedure**: Vault includes attachments in the languages referenced on the _Medicinal Product Registration_ records. ## XEVPRM Message Generation for Attachments When an XEVMPD attachment document reaches an approved state, Vault can generate and submit the XEVPRM message for only that document. Attachment-only submissions to the EMA ensure that a document is only assigned a single EV code and prevents you from needing to maintain multiple EV codes for the same attachment document. You can then include this document as an attachment on a _Medicinal Product_ record to include it in full XEVMPD submissions from a _Product Data Submission_ record, with the document's EV code already applied. See [XEVMPD Gateway Submission for Attachments](/en/lr/71609/) for more information. ## XEVMPD Gateway Submission {#gateway-submission} After you finish compiling medicinal product data, Vault's integration with the EMA Gateway allows you to submit the generated XEVPRM to the Health Authority electronically and receive gateway responses. See [XEVMPD Gateway Submission](/en/lr/57152/) for detailed instructions. ## Bulk XEVMPD Update & Submission When you need to make XEVMPD updates that impact a large number of medicinal products, you can select and update the impacted medicinal products in bulk. You can then submit the updated XML to the EMA. See [XEVMPD Bulk Update & Submission](/en/lr/60423/) for detailed instructions. ## Related Permissions {#permissions} You must have the following permissions to work with XEVMPD data and generate a product report: |Type|Permission Label|Controls| |--- |--- |--- | |Security Profile|Objects: Ingredient Product Report Item: Create, Edit|Ability to edit _Ingredient Product Report Item_ records.| |Security Profile|Objects: Medicinal Product: Create, Edit|Ability to create and edit _Medicinal Product_ records and relate _Medicinal Products_ to _Registrations_.| |Security Profile|Objects: Product Data Message: Read|Ability to view and access the XEVPRM message and ZIP file.| |Security Profile|Objects: Product Data Submission: Create, Edit|Ability to create and edit _Product Data Submission_ records.| |Security Profile|Objects: Product Report: Create, Edit|Ability to access the Create Product Report action on a _Product Data Submission_ record and edit the _Product Report_ record.| |Security Profile|Objects: Product Report Item: Create, Edit|Ability to edit _Product Report Item_ records. If your Vault uses field-level security, you'll also need at least _Read_ permission on the _EV Code Text_ field to generate the XEVPRM XML.| |Security Profile|Objects: Product Report Validation Results: Read|Ability to view _Product Report Validation Result_ records from a _Product Data Submission_ record.| |Security Profile|Objects: Validation Results Detail: Read|Ability to view _Validation Results Detail_ records to see the exact validation criteria violated for a _Product Report Item_ record.| |Security Profile|Objects: XEVMPD Acknowledgement: Read|Ability to see the acknowledgement details from the EMA.|

*In Vaults created after the 19R1 release, the following objects are relabeled to support medical devices:

  • The Product (product__v) object is now Product Family.
  • The Drug Product (drug_product__v) object is now Product.
  • The Product Detail (product_detail__v) object is now Product Variant.

In existing Vaults, Admins can [update these objects manually](/en/lr/15057/#customizestandardobjects).

[3]: #product-report-validation [7]: #gateway-submission [comment]: # Pre-Action UI screenshot removed from Working with Product Reports (above Creating a Product Report): file="xEVPMD_Product_Report_18r34.png". Will be replaced in future. [comment]: # Pre-Action UI screenshot removed from Validation Process (end of section): file="xEVMPD_Validation_Result_18r34.png". Will be replaced in future.