# Assessing Adverse Event Reportability (QMS)

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 QMS companion application, <a href="/en/gr/65830/">Product Surveillance</a>.

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_][1] 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 {#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.

  [1]: #assessment-effects