You can configure Vault 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 Vault QMS to automate reportability decision-making, you must configure several Vault components, as outlined in this article.
Vault 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.
Note: This article only applies to the QMS application. If you’re looking to configure Reportability Assessments with Adverse Event Report and health authority submission automation, consider Vault Product Surveillance for extended functionality beyond reportability assessments.
Configuration Overview
Complete the following steps:
- Define Reporting Decision Rules 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.
- 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.
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 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 for determining reportability.
To create Reporting Decision Rules records:
- Navigate to Business Admin > Objects > Reporting Decision Rule.
- Click Create.
- Select a Country.
- Select a Severity.
- Populate the Days for Initial Due Date.
- Select the appropriate Reporting Requirement.
- 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
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
Vault QMS allows you to define multiple decision trees to determine the reportability of Complaints. When configured alongside decision rules, 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 Vault to use multiple decision trees.
- Create up to 15 object types for the Reportability Assessment object.
- Define Reportability Decision Tree configurations.
Enabling Multiple Decision Trees
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
The Reportability Decision Tree object exists to link Reportability Assessment object types to a corresponding Country.
To define a Reportability Decision Tree configuration:
- Navigate to Admin > Configuration > Reportability Decision Trees.
- Click Create.
- Populate a Label, Description, and Status.
- 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.
- Click Save.
Optionally, you can create a single qualifier for each Reportability Decision Tree configuration. To add a Decision Tree Qualifier:
- Navigate to a Reportability Decision Tree record.
- From the Decision Tree Qualifiers section, click Create.
- In the dialog, provide a Label and Description.
- Select an Object. For example, Country.
- Select an Object Field. For example, Reporting Region.
- Select one (1) or more Picklist Values.
- Click Save.
Configuring Reportability Assessment Lifecycle & Workflows
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.