# Configuring Adverse Event Reportability (QMS) You can configure QMS to help assess if a _Complaint_ must be reported to health authorities when a user completes a _Reportability Assessment_. Using the _Reportability Assessment_ object connected to either the _Pharma Complaint_ or _MedTech Complaint_ object types of the _Complaint_ object, Admins can set up questions to determine the _Severity_ of a complaint and thus determine the reportability of the _Adverse Event_ to health authorities. The severity and reportability are determined based on the answers in the _Reportability Assessment_ provided by _Complaint_-handling users. To enable QMS to automate reportability decision-making, you must configure several Vault components, as outlined in this article. QMS supports the _MedTech Complaint_ and _Pharma Complaint_ object types for both the _Quality Event_ and _Complaint_ objects. The term _Complaint_ in this article represents all of these options.
## Configuration Overview Complete the following steps: * Define [_Reporting Decision Rules_][1] for each _Country_ where you market or sell your product or countries for which you would want to assess reportability. * Optional: Configure your Vault to support [multiple decision trees][3]. * 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 _Complaint_ lifecycle. * Configure _Reportability Assessment_ [lifecycles and workflows][2]. ## Defining Reporting Decision Rules {#defining-r-d-r} 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 _Complaint_ record is a reportable event, you must create _Reporting Decision Rule_ records for each combination of _Country_ and _Severity_ for which you could receive a _Complaint_. If you do not create a _Reporting Decision Rule_ for a particular _Country_/_Severity_ combination, then Vault will determine that any _Complaint_ with that combination is not reportable. If your organization requires more granular assessments, you can configure Vault to accommodate [multiple decision trees][3] 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**][4]. 7. Click **Save**. ### Example: Creating Decision Rules using Requirement Data 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
Severity Outcome
Country Public Health Threat Death Serious Injury Product Problem Trend
Veevaland 10 Calendar Days 5 Calendar Days 10 Calendar Days 30 Calendar Days Not Required
Vaultopia 15 Calendar Days 7 Calendar Days 15 Calendar Days 30 Calendar Days 90 Calendar Days
#### Example Multi-Country Report Requirement Data
Severity Outcome
Country Public Health Threat Death Serious Injury Product Problem Trend
Veevaland Country of Incident Only Global Country of Incident Only Country of Incident Only Not Required
Vaultopia Global Global Global Country of Incident Only Country of Incident Only
#### 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|Country of Incident Only| |RDR-0002|Veevaland|Death|5|Global| |RDR-0003|Veevaland|Serious Injury|10|Country of Incident Only| |RDR-0004|Veevaland|Product Problem|30|Country of Incident Only| 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-0005|Vaultopia|Public Health Threat|15|Global| |RDR-0006|Vaultopia|Death|7|Global| |RDR-0007|Vaultopia|Serious Injury|15|Global| |RDR-0008|Vaultopia|Product Problem|30|Country of Incident Only| |RDR-0009|Vaultopia|Trend|90|Country of Incident Only| Unlike Veevaland, Vaultopia includes the _Trend_ event as a reportable adverse event, 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 two possible values: * _Country of Incident Only_: Corresponds to a country's requirement to only report an incident of that type if the incident occurred in that same 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 _Complaint_. If the _Reporting Decision Rule_ includes a _Global_ reportability requirement, Vault determines reportability and sends a notification to the user with all applicable countries' reportability. ## Configuring Multiple Decision Trees {#multiple-decision-trees} QMS allows you to define multiple decision trees to determine the reportability of _Complaints_. When configured alongside [decision rules][1], 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][5] Vault to use multiple decision trees. * Create up to 15 object types for the _Reportability Assessment_ object. * Define [_Reportability Decision Tree_][6] 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**. ## Configuring Reportability Assessment Lifecycle & Workflows {#lc-wf} In the _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 _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 _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 _Determine Reportability_ entry action in the _Reportability Assessment Lifecycle_. The _Determine Reportability_ entry action creates new _Reportability Assessment Effects_ records for all the countries that may require reporting. [1]: #defining-r-d-r [2]: #lc-wf [3]: #multiple-decision-trees [4]: #multi-country [5]: #enablement [6]: #tree-configurations