# Configuring Adverse Event Reporting (Product Surveillance)

To enable Product Surveillance to automate reportability decision-making, create _Adverse Event Reports_, generate XML reporting forms, and enable Vault to <a href="/en/gr/66495/">send eMDR submissions</a> to the FDA Electronic Submissions Gateway (ESG), you must configure several Vault components.

## Configuration Overview

Complete the following configuration steps:

  * Define [_Reporting Decision Rules_][2] for each _Country_ from which you may receive _MedTech Complaints_.
  * Optional: Configure your Vault to support [multiple decision trees][9].
  * Create [_Country Report Type_][3] records, associating _Countries_ with _Report Type_ picklist values.
  * Optional: Activate the _Other_ object type on the _Adverse Event Report_ object to create and manage reports for countries that are not yet supported in the standard product.
  * Set up [_eMDR: MFR Report #_][6] auto-generation.
  * Configure [user actions and entry actions][4].
  * Configure _Reportability Assessment_ [lifecycles and workflows][7].
  * Optional: If you are using multiple decision trees, assign the _Create Reportability Assessments_ action to the _Complaint_ object and configure it as a user or entry action on the desired state of the _Medtech Complaint_ lifecycle.
  * Configure page layouts and optionally make a copy from [standard page layouts][8].
  * Configure the [FDA Gateway Profile][5] and create a _Transmission Profile_ record.
  * Optional: Configure [bi-directional data exchange][13] for _Adverse Event Report_ records.
  * Optional: [Enable EU MIR 7.3.1][14].

## Defining Reporting Decision Rules {#defining-reporting-decision-rules}

The _Reporting Decision Rules_ object has special business logic that evaluates _Country_, _Severity_, _Days for Initial Due Date_, and _Reporting Requirement_ field values. In order for Vault to determine whether a _MedTech Complaint_ record is a reportable event, you must create _Reporting Decision Rules_ records for each combination of _Country_ and _Severity_ for which you could receive a _MedTech Complaint_. If you do not create a _Reporting Decision Rule_ for a particular _Country_/_Severity_ combination, then Vault will determine that any _MedTech Complaint_ with that combination is not reportable. If your organization requires more granular assessments, you can configure Vault to accommodate [multiple decision trees][9] for determining reportability.

To create _Reporting Decision Rules_ records:

  1. Navigate to **Business Admin > Objects > Reporting Decision Rule**.
  2. Click **Create**.
  3. Select a **Country**.
  4. Select a **Severity**.
  5. Populate the **Days for Initial Due Date**.
  6. Select the appropriate [**Reporting Requirement**][10].
  7. Click **Save**.

### Example: Creating Decision Rules using Requirement Data

For example, consider the following adverse event reporting date requirement and multi-country report requirement data for the fictional countries of Veevaland and Vaultopia:

#### Example Reporting Date Requirement Data

<table>
<tr>
<th></th>
<th colspan="5">Severity Outcome</th>
</tr>
<tr>
<th>Country</th>
<th>Public Health Threat</th>
<th>Death</th>
<th>Serious Injury</th>
<th>Product Problem</th>
<th>Trend</th>
</tr>
<tr>
<td>Veevaland</td>
<td>10 Calendar Days</td>
<td>5 Calendar Days</td>
<td>10 Calendar Days</td>
<td>30 Calendar Days</td>
<td>Not Required</td>
</tr>
<tr>
<td>Vaultopia</td>
<td>15 Calendar Days</td>
<td>7 Calendar Days</td>
<td>15 Calendar Days</td>
<td>30 Calendar Days</td>
<td>90 Calendar Days</td>
</tr>
</table>

#### Example Multi-Country Report Requirement Data

<table>
<tr>
<th></th>
<th colspan="5">Severity Outcome</th>
</tr>
<tr>
<th>Country</th>
<th>Public Health Threat</th>
<th>Death</th>
<th>Serious Injury</th>
<th>Product Problem</th>
<th>Trend</th>
</tr>
<tr>
<td>Veevaland</td>
<td>Domestic Incidents</td>
<td>Global</td>
<td>Domestic Incidents</td>
<td>Domestic Incidents</td>
<td>Not Required</td>
</tr>
<tr>
<td>Vaultopia</td>
<td>Global</td>
<td>Global</td>
<td>Global</td>
<td>Domestic Incidents</td>
<td>Domestic Incidents</td>
</tr>
</table>

#### Example Decision Rules for Veevaland

If your product could receive _MedTech Complaints_ from Veevaland, you would need to create four (4) _Reporting Decision Rules_ records to drive the reportability business logic:

|Record Name|Country Value|Severity Value|Days for Initial Due Date Value|Reportability Requirement|
|--- |--- |--- |--- |--- |
|RDR-0001|Veevaland|Public Health Threat|10|Domestic Incidents|
|RDR-0002|Veevaland|Death|5|Global|
|RDR-0003|Veevaland|Serious Injury|10|Domestic Incidents|
|RDR-0004|Veevaland|Product Problem|30|Domestic Incidents|
|RDR-0005|Veevaland|Product Problem|45|Foreign Incidents|

As the _Trend_ event in this example data is not a reportable adverse event for Veevaland, you do not need to create a _Reporting Decision Rule_ record for it. Without a corresponding decision rule, Vault will assign an _Is Reportable?_ value of _No_ to events with the _Country_ value of _Veevaland_ and _Severity Outcome_ value of _Trend_.

#### Example Decision Rules for Vaultopia

If your product could receive _Medtech Complaints_ from Vaultopia, you would need to create five (5) _Reporting Decision Rules_ records to drive the reportability business logic:

|Record Name|Country Value|Severity Value|Days for Initial Due Date Value|Reportability Requirement|
|--- |--- |--- |--- |--- |
|RDR-0006|Vaultopia|Public Health Threat|15|Global|
|RDR-0007|Vaultopia|Death|7|Global|
|RDR-0008|Vaultopia|Serious Injury|15|Global|
|RDR-0009|Vaultopia|Product Problem|30|Domestic Incidents|
|RDR-0010|Vaultopia|Product Problem|45|Foreign Incidents|
|RDR-0011|Vaultopia|Trend|90|Domestic Incidents|

Unlike Veevaland, Vaultopia includes the _Trend_ event as a reportable adverse event, and so it requires its own rule.

### Defining Rules for Multi-Country Adverse Event Reporting {#multi-country}

In the above examples, we created rules reflecting the country's reportability requirements for each type of incident. The _Reportability Requirement_ field has three (3) possible values:

- _Domestic Incidents_: Corresponds to a country's requirement to report an incident of that type if the incident occurred in that same country.
- _Foreign Incidents_: Corresponds to a country's requirement to report an incident of that type if the incident occurred outside the country.
_Global_: Corresponds to a country's requirement to report an incident of that type that occurred in any country in which the product is marketed.

When assessing reportability, Vault evaluates these requirements against the _Product Variant_'s _Product Marketed_ related records associated with the _Medtech Complaint_. If the _Reporting Decision Rule_ includes a _Global_ reportability requirement, Vault creates _Adverse Event Reports_ as necessary to fill the appropriate countries' requirements at the configured point in the _Medtech Complaint_'s lifecycle. If the _Reporting Decision Rule_ includes a _Domestic Incidents_ or _Foreign Incidents_ reportability requirement, Vault creates _Adverse Event Reports_ that support the different durations for how long an organization has to report _Incidents_ that happen in-country versus those that happen out of country. Organizations working with reportability requirements that leverage the same duration for _Domestic Incidents_ and _Foreign Incidents_ can continue to leverage the _Global_ option.

## Configuring Multiple Decision Trees {#multiple-decision-trees}

QMS allows you to define multiple decision trees to determine the reportability of _Medtech Complaints_. When configured alongside [decision rules][2], Vault decides which decision trees are applicable for a given _Complaint_ record, determines which countries require the incident to be reported, and provides the corresponding timeline for report submission.

To configure multiple decision trees, complete the following steps in your Vault:

  * [Enable][11] Vault to use multiple decision trees.
  * Create up to 15 object types for the _Reportability Assessment_ object.
  * Define [_Reportability Decision Tree_][12] configurations.

### Enabling Multiple Decision Trees {#enablement}

Navigate to **Admin > Settings > Application Settings** and ensure that the **Complaint Reportability: Use Global Decision Trees** setting is disabled. You can enable this setting at any time.

### Defining Reportability Decision Tree Configurations {#tree-configurations}

The _Reportability Decision Tree_ object exists to link _Reportability Assessment_ object types to a corresponding _Country_.

To define a _Reportability Decision Tree_ configuration:

  1. Navigate to **Admin > Configuration > Reportability Decision Trees**.
  2. Click **Create**.
  3. Populate a **Label**, **Description**, and **Status**.
  4. Select a **Reportability Assessment Type** from the drop-down. This list includes active standard and custom object types, excluding the _Global Reportability Assessment_ object type.
  5. Click **Save**.

Optionally, you can create a single qualifier for each _Reportability Decision Tree_ configuration. To add a _Decision Tree Qualifier_:

  1. Navigate to a _Reportability Decision Tree_ record.
  2. From the _Decision Tree Qualifiers_ section, click **Create**.
  3. In the dialog, provide a **Label** and **Description**.
  4. Select an **Object**. For example, _Country_.
  5. Select an **Object Field**. For example, _Reporting Region_.
  6. Select one (1) or more **Picklist Values**.
  7. Click **Save**.

## Creating Country Report Types {#creating-country-report-types}

Each _Country Report Type_ object record associates a _Country_ object record with a _Report Type_ picklist value. Create _Country Report Type_ records for each applicable _Country_ according to your needs, selecting the _Report Type_ corresponding to what's accepted by the health authority of that country. You can associate _Country Report Type_ records with a _Transmission Profile_ record to enable electronic transmission of adverse event reports to the relevant health authority. If you make the _Adverse Event Report_ object type of _Other_ active, Vault can automatically generate _Adverse Event Reports_ for countries that do not have a supported _Country Report Type_. Vault cannot directly submit the _Adverse Event Report_ if the country's health authority does not support electronic submission, but users can submit the reports manually as needed.

## Gateway Configuration {#gateway-configuration}

Product Surveillance supports electronic submissions to the US FDA electronic gateway. See <a href="/en/gr/66500/">Configuring FDA Gateway Integration (Product Surveillance)</a> for more information on availability and setup.

## Configuring Adverse Event Reporting for Japan (PMDA)

You can configure Product Surveillance to support adverse event reporting for Japan via PMDA Form 8. All fields and sections, including the form template and data on the form, are displayed in Japanese.

To configure PMDA Form 8 for submitting adverse events to the Japanese health authority, complete the following steps in your Vault:

- Ensure that a [_Country Report Type_][3] record exists for Japan.
- Set up [decision rules][2] for Japan.
- Activate the _PMDA_ picklist value on the _Report Type_ (`report_type__v`) picklist.
- Activate the _PMDA_-related standard fields on the following objects:
  - _Adverse Event Report_ (`adverse_event_report__v`)
  - _Codes_ (`code__v`)
  - _Complaint_ (`complaint__v`)
  - _MedTech Complaint Details_ (`mt_complaint_details__v`_)_
  - _Regional Product Attributes_ (`regional_product_attributes__v`)
  - _Product Identifier_ (`product_identifier__v`)
  - _Device Risk Classification_ (`device_risk_classification__v`)
  - _Concomitant Product and Therapy Date_ (`concomitant_therapy__v`)
  - _Problem Codes AE Report_ (`problem_codes_ae_report__v`)
- Activate the _PMDA_ object type on the _Adverse Event Report_ object, and configure the page layout for the _PMDA_ object type.
- Activate the _JMDN Codes_ object type on the _Codes_ object.
- Activate the _PMDA_-related standard picklists and picklist values:
  - _Classification of Incident_ (`classification_of_incident__v`)
  - _Classification of Incident - Type_ (`classification_of_incident_type__v`)
  - _Type of Incident_ (`type_of_incident__v`)
  - _Type of Report Urgency_ (`type_of_report_urgency__v`)
  - _Country Region_ (`country_region__v`)
  - _Device Class_ (`device_class__v`)
  - _Device Class - Level 2_ (`device_class_2__v`)
  - _Device Class - Level 3_ (`device_class_3__v`)
  - _Patient's Sex_ (`patient_sex__v`)
  - _Outcomes Attributed to Adverse Event_ (`outcomes__v`)
  - _Device available for evaluation?_ (`device_available_for_evaluation__v`)
  - _Reason for No Evaluation_ (`reason_no_evaluation__v`)
- Add the _Regional Product Attributes_ section to the _Product_ object page layout to capture details of a product, such as the brand name, generic name, and so on, in Japanese.
- Activate the _PMDA_ document types, which can include attachments, PDF, and XML files.

## eMDR: MFR Report # Generation {#mfr-generation}

The eMDR MFR Report # (G8) requires following a strict numbering system constructed as follows: `[FEI/CFN Number]-[Current Year]-[Report Number]`

You can set up Product Surveillance to auto-generate these numbers during the _Generate Adverse Event Report XML_ actions. To ensure the numbers generate correctly, perform the following steps for each manufacturer which could be the subject of a report:

1. Navigate to **Business Admin > Objects > Manufacturer Report Number** or to a custom object tab.
2. Click **Create**.
3. Select an **Organization** and enter an **FEI/CFN Number** for the organization.
4. Enter the **Current Year**. This is for sequence initialization only, and when a new year arrives, Product Surveillance automatically starts generating numbers with the new year.
5. Enter the **FDA Mfg Report Starting #**. This is the starting point for auto-generated numbers, and should be incremented from your last manually-generated number.
6. Click **Save**.

The system will automatically generate the _Mfg Report #_ field on _Adverse Event Report_ for eMDR using the above setup, based on the _Manufacturing Site_ selected on the _Complaint_ record.

## Configuring Adverse Event Reporting Actions {#configuring-adverse-event-reporting-actions}

Several actions drive adverse event reporting automation, and you must add them to the relevant object lifecycles to fit your organization's needs:

### Adverse Event Report Lifecycle

In **Admin** > **Objects** > **Adverse Event Report** > **Actions**, click **Create** and add the following custom actions:

 * _VPS: Generate Adverse Event Report XML_
 * _VPS: Generate Adverse Event Report PDF_
 * _VPS: Change state of related documents_
 * _VPS: Submit to Gateway_
 * _VPS: Generate Follow-up Report_
 * _VPS: Run Validation_

Add the _VPS: Generate Adverse Event Report XML_ and _VPS: Generate Adverse Event Report PDF_ user actions to the _Adverse Event Report_ object lifecycle in the state in which all field data has been confirmed to be complete and accurate. Add the _VPS: Submit to Gateway_ user action to the state in which the _Adverse Event Report_ is ready for transmission. This may be the same state for both actions, depending on your processes.

Add the _VPS: Change state of related documents_ action in the state in which generation of submission forms has completed. This action changes the state of the generated forms, being related documents on the _Adverse Event Report_ record, to the target state.

Alternatively, you can configure these actions as entry actions on _Adverse Event Report_ lifecycle states, if you want Vault to automatically perform them upon entering the appropriate lifecycle states.

Add the _VPS: Generate Follow-up Report_ user action to the state selected as the Closed state type. This action creates a copy of the _Closed Adverse Event Report_ with a linked reference to its originating record.

Add the _VPS: Run Validation_ user action to the state in which users are adding information to the _Adverse Event Report_ fields. This action checks field values on the record to ensure they are acceptable input. Validation errors are stored as related _Validation Error_ records.

The _Adverse Event Report_ lifecycle includes the following state types:

 * _XML Generated Successfully_
 * _XML Generation Failed_
 * _PDF Generated Successfully_
 * _PDF Generation Failed_

Assign states to these types based on your processes. For example, you can assign the _Draft_ state to the _XML Generation Failed_ state type, so that corrections can be made after the failure.

#### Generating Submission Documents

To generate both XML and PDF versions of the _Adverse Event Report_ at once, add the _VPS: Generate Submission Documents_ entry or user action to the _Adverse Event Report_ object lifecycle in the state in which all field data has been confirmed to be complete and accurate. 

The actions Vault performs when executing the _VPS: Generate Submission Documents_ action depend on the _Adverse Event Report_ type.

| Type of _Adverse Event Report_ | Action(s) Performed |
| --- | --- |
| eMDR | - _Generate the Manufacturer Report Number (G8) / Importer Report Number (F2)_ <br><br>- _Generate XML_ <br><br>- _Generate AER Snapshot_ <br><br>- _Generate PDF_ |
| EU MIR | - _Generate PDF_ <br><br>- _Generate XML_ |
| Health Canada | - _Generate PDF_ |
| PMDA | - _Generate XML_ |
| UK MHRA | - _Generate PDF_ <br><br>- _Generate XML_ |

In the event that any of the actions fails, Vault moves the _Adverse Event Report_ record to its configured failure state.

## Configuring Reportability Assessment Lifecycle & Workflows {#lifecycles-workflows}

In the _VPS: Reportability Assessment Lifecycle_, add any custom states necessary for your organization's processes, but ensure that you have a state selected as the _Closed_ state type, as this state type is used by Vault's assessment logic.

Users' answers to prompts in the _VPS: Reportability Assessment_ dialog cause fields on _Reportability Assessment_ records to be populated through workflow configuration. For example, this can allow users to respond to prompts such as _Was there a death?_, and Vault can then populate the _Severity Outcome_ field with the _Death_ value.

Configure a workflow for the _VPS: Reportability Assessment Lifecycle_ which includes _Decision_ steps with rules testing for each possible input and setting the relevant field value accordingly. The workflow should then change the _Reportability Assessment_ to a _Closed_ state.

Add the _VPS: Determine Reportability_ and _VPS: Process Reportability_ entry actions in the _Reportability Assessment Lifecycle_. The _VPS: Determine Reportability_ entry action creates new _Reportability Assessment Effects_ records for all the countries that may require reporting, while the _VPS: Process Reportability_ entry action creates _Adverse Event Report_ records if the complaint is reportable.

## Configuring Product Surveillance Layouts {#layouts}

All objects in Vault require a <a href="/en/gr/26387/">page layout</a> in order for users and Admins to understand and interact with the object records. To support Product Surveillance customers, there are standard page layouts for the following objects and object types. All delivered layouts have _Layout Names_ ending in `__v`.

  * _VPS: Reportability Assessment_
  * _Adverse Event Report_
    * _eMDR_
    * _EU MIR_
    * _Health Canada_
    * _MHRA_
    * _PMDA_

These layouts are inactive by default and cannot be activated or edited. To use them, create a copy of each, then configure the new layout according to your organization's requirements.

## Configuring Bi-directional Data Exchange for Adverse Event Reports {#bidirectional-data-exchange}

With the _VPS: Adverse Event Reports Configurations_ component, Admins can define how users update source records while working with _Adverse Event Reports_. Through this component, organizations can opt in or out of automatic data exchange, by report type, between an _Adverse Event Report_ record and the source record when users make changes to the _Adverse Event Reports_ record. If organizations opt out of bi-directional data exchange between records, users with the appropriate permissions granted must access the source record to make the necessary changes.

To define a _VPS: Adverse Event Reports Configuration_:

1. Navigate to **Admin > Configuration > VPS: Adverse Event Reports Configurations**.
2. Click **Create**.
3. Populate a **Label**, a **Name**, and a **Description**.
4. Select an **Adverse Event Report Type** from the drop-down.
5. Optional: Select the **Do Not allow Bi-directional Data Exchange for All fields** checkbox. If this checkbox is selected, users cannot edit information on _Adverse Event Report_ records but must make their updates on the source record, if they have the correct permissions granted. If the checkbox is not selected, users can edit _Adverse Event Report_ records directly, which also updates the source record.
6. Click **Save**.

## Enabling EU MIR 7.3.1 {#eumir}

You can opt to use the EU MIR 7.3.1 report structure by navigating to **Admin > Settings > Application Settings** and, under _Product Surveillance_, selecting the **Enable EU MIR 7.3.1 Update** checkbox. Once enabled, this feature cannot be disabled.

You must also activate the following object fields and picklist values:

  * _Reportability Awareness Date_ (`reportability_awareness_date__v`) on the _Adverse Event Report_ (`adverse_event_reports__v`) object
  * On the _Complaint_ (`complaint__v`) object:
    * _Initial Product and Incident Assessment_ (`initial_product_incident_assessment__v`)
    * _Final Product and Incident Assessment_ (`final_product_incident_assessment__v`) 
  * On the _Product_ (`product__v`) object:
    * _Basic UDI-DI/Eudamed-DI Issuing Entity_ (`udi_di_basic_issuing_entity__v`)
    * _UDI-DI Issuing Entity_ (`udi_di_issuing_entity__v`)
    * _Product Description / Intended Purpose_ (`product_description__v`)
  * _Unit of use UDI-DI Issuing Entity_ (`udi_di_unit_of_use_issuing_entity__v`) on the _Product Variant_ (`product_variant__v`) object
  * On the _Device Risk Classification_ (`device_risk_classification__v`) object:
    * _Marketed after MDR/IVDR Date of Application?_ (`device_marketed_after_mdr_ivdr__v`)
    * _Scientific Opinion Asked?_ (`scientific_opinion_asked__v`)
    * _Competent Authority Consulted Name_ (`competent_authority_name__v`)
    * _Associated Products_ (`associated_products__v`)
  * _Unknown_ (`unknown__v`) on the _Device Class_ (`device_class__v`) picklist
  * _EEA + TR + XI_ (`eea_tr_xi__v`) on the _Region_ (`region__v`) picklist

## Related Permissions

To manage _VPS: Adverse Event Reports Configurations_ and _Reportability Decision Trees_, Admins require _Create_, _Edit_, _Read_, and _Delete_ permissions under **Permission Sets > Admin > Configuration > VPS: Adverse Event Reports Configurations**.

 [2]: #defining-reporting-decision-rules
 [3]: #creating-country-report-types
 [4]: #configuring-adverse-event-reporting-actions
 [5]: #gateway-configuration
 [6]: #mfr-generation
 [7]: #lifecycles-workflows
 [8]: #layouts
 [9]: #multiple-decision-trees
 [10]: #multi-country
 [11]: #enablement
 [12]: #tree-configurations
 [13]: #bidirectional-data-exchange
 [14]: #eumir