To enable Vault QMS to automate reportability decision-making, you must configure several Vault components.
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 from which you may receive MedTech Complaints.
- 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.
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
| 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
| 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, and 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 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.