Vault QMS includes tools to help assess if a Complaint must be reported to health authorities by completing a Reportability Assessment. Using the Reportability Assessment object connected to either 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.

This feature allows you to determine if an event is reportable and to which health authorities based on the severity of the Complaint, Reporting Decision Rules, and where the Product is marketed.

If your organization is interested in automating the generation of adverse event documentation or in tools supporting adverse event submission, you may wish to review the Vault QMS companion application, Vault Product Surveillance.

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.

Example Adverse Event Reporting Process

While processes vary between organizations, many contain the following steps:

  1. User creates a Complaint and adds the necessary data, including fields relevant to Vault’s reportability logic.
  2. User saves the record.
  3. Optional: If you are using multiple decision trees, the user executes an action for Vault to create Reportability Assessment records. If configured by an Admin, Vault may automatically create Reportability Assessment records when the Complaint enters a particular lifecycle state.
  4. User completes each Reportability Assessment record associated with the Complaint.
  5. User receives a notification detailing the reportability of the Complaint.

About Complaint Reportability Logic

The following fields on the Complaint object drive Vault’s event reportability logic, and must be populated for that logic to execute:

  • Awareness Date: This field is the date on which your organization became aware of the incident.
  • Country of Incident: Where the incident which generated the complaint occurred.
  • Product Variant: The type of the product involved in the complaint. The Product Variant may have related Product Marketed records, each indicating a country in which that variant is marketed.

Vault automatically populates values for the following fields on the Reportability Assessment Effects object via event reportability logic when the record is saved:

  • Is Reportable?: Vault populates this Yes/No field according to Reporting Decision Rules as defined by an Admin, leveraging the values in the Country of Incident and Adverse Event Severity fields.
  • Days for Initial Report Due Date: If the incident is reportable, Vault populates this field according to Reporting Decision Rules.

About Reportability Assessments

Vault automatically populates Reportability Assessment records with relevant details:

  • Type of Assessment: This field lists the context of this particular assessment, such as Initial Assessment or Reassessment.
  • Prompted detail fields: Vault populates these fields with the users’ responses to the prompts in the VPS: Reportability Assessment dialog. Typical detail fields on a Reportability Assessment may include answers to prompts such as Was there a Death?.
  • Determined detail fields: Via a custom workflow, Vault populates these fields with data derived from the user’s answers to prompts. For example, the Severity Outcome field’s value may be derived from a user’s answer to the Was there a death? prompt in the VPS: Reportability Assessment dialog.
  • [object type] Complaint: This field references the related Complaint, either Pharma Complaint or MedTech Complaint.

Reportability Assessment Effects

Details about Vault’s reportability logic effects are stored as Reportability Assessment Effects related records on the Reportability Assessment.

Reassessing Reportability

As users add information or make updates to a Complaint, its reportability may change. Users can create new Reportability Assessment records to perform additional assessments of the Complaint’s reportability, as needed. This action creates a Reportability Assessment record with the results. Users can only conduct the reassessment if the previous Reportability Assessment records reach a Closed or Cancelled state.