# Using MedTech Complaint Adverse Event Reporting (Product Surveillance)

Sometimes, during the course of a normal complaint process, a complaint may be found to be a reportable adverse event. This kind of event includes complaints about a severe incident, like a death or serious injury, associated with the complaint.

Health authorities may require that you report such events within a certain time window. The time window varies by the severity of the incident and the country of incident. Product Surveillance includes automated components which help you determine whether a complaint requires reporting, in which countries it needs to be reported, type of report, and the time period allowed for reporting.

Product Surveillance supports the _MedTech Complaint_ object type for both the _Quality Event_ and _Complaint_ objects. The term _MedTech Complaint_ in this article represents both of these options.

## Example Adverse Event Reporting Process

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

  1. User creates a _MedTech Complaint_ and adds the necessary data, including fields relevant to Vault's [reportability logic][3].
  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 _Medtech Complaint_ enters a particular lifecycle state.
  4. User is prompted to fill in details in the _VPS: Reportability Assessment_ dialog. Details provided in this dialog determine the reportability of the _Medtech Complaint_. The system creates, updates, or cancels _Adverse Event Reports_ based on the _Reportability Assessment_ result.

When a user creates a _Reportability Assessment_ record, Vault [checks to see][3] if the _MedTech Complaint_ is reportable via defined _Reporting Decision Rules_. If the _MedTech Complaint_ is not reportable, it continues on in its processes as normal. If the _MedTech Complaint_ is reportable, either Vault or the user creates an _Adverse Event Report_ record. The originating _MedTech Complaint_ may continue on in its own processes at the same time that users perform the remaining necessary steps for the _Adverse Event Report_. Regardless of the determination, Vault stores the results of the assessment as a _Reportability Assessment_ and _Reportability Assessment Effects_ related record on the _Medtech Complaint_.

The following steps apply only if an the _Medtech Complaint_ has resulted in an _Adverse Event Report_ record:

  1. User fills in all necessary information on the _Adverse Event Report_ record. If available, the user can select the **VPS: Run Validation** user action to ensure that the information provided is acceptable. For the FDA eMDR, EU MIR, and PMDA Form 8 XML forms, Vault highlights validation errors by displaying a red exclamation mark icon next to the relevant data fields, and the user can hover over the icon to view the specific error. Validation errors are stored as related _Validation Error_ records. Vault runs the validations in the background every time the form section on the _Adverse Event Report_ detail page is saved.
  2. User [makes any edits][1] necessary to complete or correct the _Adverse Event Report_.
  3. User performs the appropriate action to [create an XML payload][4] deliverable to the health authority.
  4. User performs the relevant action to [send the XML payload][5] to the appropriate health authority's electronic submissions gateway.

## About MedTech Complaint Reportability Logic {#reportability-logic}

The following fields on the _MedTech Complaint_ object drive Vault's event reportability logic, and must must be filled in for that logic to execute:

  * _Awareness Date_: This field is the date on which your organization became aware of the incident.
  * _Domestic Incidents_: This field indicates that the incident that generated the complaint occurred in-country.
  * _Foreign Incidents_: This field indicates that the incident that generated the complaint occurred out of the country.
  * _Product Variant_: This field provides the type of product involved in the complaint. The _Product Variant_ may have related _Product Marketed_ records, each indicating a country in which that variant is marketed.
  * _Latest Info Available_: This field updates the due date automatically when a complaint's reportability status changes during reassessment, but users can manually change the due date if needed.

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 _Domestic Incidents_, _Foreign Incidents_, _Global_, 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 Adverse Event Reports

If Vault determines that a _MedTech Complaint_ is reportable, the system may create a related _Adverse Event Report_ record at the configured point in the complaint's lifecycle. You can also create _Adverse Event Reports_ manually if, for example, your organization wants to voluntarily report a complaint even if the health authority does not require that you report it.

_Adverse Event Report_ records pull information from the _MedTech Complaint_ in which they originated, as well as associated data such as _Product_, _Organizations_, and _Contacts_ to fill out the appropriate health authority adverse event reporting form. For some fields, Vault combines field data from the source records to adhere to the health authority's form requirements. For example, Vault may combine several field values from a source _Contact Information_ object record such as _Unit_, _Street Number_, _Street Name_, _Address Details_, and _Additional Address Info_ to create a valid manufacturer street address on the resulting _Adverse Event Report_.

_Adverse Event Reports_ can also contain related object sections in which you can create and associate other records, such as _Relevant Tests_.

### Generating Follow-up Reports

To create a follow-up _Adverse Event Report_ after the original report has been closed, select the **VPS: Generate Follow-up Report** user action on the report record. This action creates a copy with a linked reference to the originating _Adverse Event Report_ on the _Previous Report_ field.

For eMDR, the follow-up report includes an indicator that shows the changes between the original report and the new report. Values that have changed are marked with a delta (<i class="fal fa-triangle"></i>) icon. When you click the icon, Vault displays the current and previous values in a dialog. This allows you to track and compare report data, and allows Vault to identify and submit only the changes to the FDA. All changes display in the follow-up report regardless of your role permissions or security profile.

For all other health authorities, Vault submits all information, regardless of if it has been updated or submitted previously, as part of the follow-up report.

### Automating Product Master Data

You can select the **Use Regional Product Attributes** option to apply country-specific and region-specific product attributes, such as the _Brand Name_, _Common Device Name_, and _Device Description_, for FDA eMDR, EU MIR, Health Canada, Japan PMDA, and UK MHRA _Adverse Event Reports_. You can select this option by individual report type under **Configuration > Adverse Event Reports Configuration**.

When you select this option, new entries are added to the _Adverse Event Report_ representing the region-specific versions of metadata as sourced from the master data set established by your organization. This regional data is automatically selected from corresponding rows on the _Regional Product Attributes_ object based on the specified data in the underlying _Complaint_ record.

### Adding JMDN Codes

To support reporting adverse events to the Pharmaceuticals and Medical Devices Agency (PMDA) in Japan, you can include Japanese Medical Device Nomenclature (JMDN) codes, such as _Health Effect Codes, Device Problem Codes, Component Codes_, and _Investigation Codes_, on Sections 3 and 4 of PMDA Form 8. When you click the **Create** button, Vault opens a custom dialog where you can select a product-specific glossary or a generic coding glossary to filter and select the appropriate codes. For _Investigation Codes_, after you click **Create**, you must select a _Type of Investigation Code_, an _Investigation Finding Code_, and an _Investigation Conclusion Code_ to filter for the appropriate subset of codes for selection.

## About Reportability Assessments {#reportability-assessments}

The system 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.
  * _Medtech Complaint_: This field references the related _Medtech Complaint_.
  * _Is Reportable?_: This field contains the determination of Vault's reportability logic after being provided with the relevant information.
  * _Days for Initial Response_: This field is populated using the defined _Reporting Decision Rules_, and shows the calculated adverse event reporting date requirement.

### Reportability Assessment Effects

Details about Vault's reportability logic effects are stored as _Reportability Assessment Effects_ related records on the _Reportability Assessment_.

## Editing Adverse Event Report Data {#editing-aer-data}

Sections within the _Adverse Event Report_ object detail page contain an Edit <i class="fal fa-pencil-alt"></i> button which allows you to edit both the _Adverse Event Report_ and the target data's source record at the same time. Vault enforces any validation rules when you click **Save** after editing field data. Vault's behavior for these section-level edits is functionally the same as if you were to navigate to the source records and edit them directly. This approach allows you to fill out the form quickly without extra navigation in the Vault.

## Reassessing Reportability

As users add information or make updates to a _Medtech Complaint_, its reportability may change. Users can create new _Reportability Assessment_ records to perform additional assessments of the _Medtech 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_ state.

After Vault redetermines the reportability of the _Medtech Complaint_, the system determines if it should create a new _Adverse Event Report_ or take action with existing _Adverse Event Report_ records. For example, if a reassessment finds that a previously reportable adverse event is no longer reportable and if there are _Adverse Event Reports_ which have not yet been submitted to a health authority, Vault will change that related _Adverse Event Report_ record's state to _Cancelled_.

### Reassessment Logic

Vault follows this decision flow when deciding the correct action after a reassessment:

If an _Adverse Event Report_ does not exist:

  * If the _Medtech Complaint_ is determined to be reportable, Vault creates a new _Adverse Event Report_ record.
  * If the _Medtech Complaint_ is determined to be not reportable, Vault takes no action.

If an _Adverse Event Report_ exists, Vault checks to see if it is _Closed_ or _Completed_, then:

  *  If the _Adverse Event Report_ is not _Closed_ or _Completed_, then:
     * If the _Medtech Complaint_ is determined to be reportable, Vault moves the _Adverse Event Report_ record to the _Draft_ state and updates it with the current assessment information.
     * If the _Medtech Complaint_ is determined to be not reportable, Vault moves the _Adverse Event Report_ record to the _Cancelled_ state.
  * If the _Adverse Event Report_ is _Closed_, Vault checks to see if there is an active followup _Adverse Event Report_ that is not in the _Closed_ or _Completed_ states, then:
     * If there is an active followup report, Vault moves the _Adverse Event Report_ record to the _Draft_ state and updates it with the current assessment information.

If there is not an active followup report, Vault creates a new followup _Adverse Event Report_ record.

## Generating XML Reporting Documents {#generating-xml}

To create an XML form suitable for submission to a health authority, use the relevant action on the _Adverse Event Report_ record. For the action to function correctly, all necessary fields on the _Adverse Event Report_ must contain data. Depending on your Vault's configuration, Vault may create the XML form automatically when the _Adverse Event Report_ enters the appropriate lifecycle state.

In the event that fields are missing data or other problems occur, errors are listed in the _Adverse Event Report Validation_ object records for the FDA eMDR, EU MIR, and PMDA Form 8 XML forms. Users receive notifications of the error, and the _Adverse Event Report_ record is moved to a lifecycle state corresponding with the _XML Generation Failed_ state type. You will see this action only when the _Adverse Event Report_ is in an appropriate lifecycle state. Once you perform the action, the _Adverse Event Report_'s state will change depending on whether the XML document was successfully generated or not. If the XML document is generated successfully, you can find it in the _Document_ section on the _Adverse Event Report_ object record. If you regenerate the XML document, the document is saved as a new version.

### Generating FDA eMDR XML

To create an FDA eMDR XML form, use the **Generate Adverse Event Report** action. Vault embeds any associated documents into the resulting XML file that meet the following criteria:

* The document has the _Attachment_ document classification.
* The document references the _Adverse Event Report_ record.
* The document has an _Include in XML?_ value of _Yes_.

### Generating EU MIR XML

To create an EU MIR XML form, use the **Generate Adverse Event Report XML** action.

### Generating PMDA Form 8 XML

To create a PMDA Form 8 XML form, use the **Generate Adverse Event Report XML** action. The picklist values and number fields are translated in Japanese to match the PMDA accepted values. The date formats are also updated to match the PMDA format. The information from the text fields is not automatically translated.

### Generating UK MHRA XML

To create a UK MHRA XML form, use the **Generate Adverse Event Report XML** action.

## Submitting XML Reporting Documents to a Health Authority {#submitting}

Once you have generated an XML document containing all the information required by the health authority, you can submit the document to the health authority's electronic submissions gateway.

The following health authorities support direct submissions from Vault:

- FDA (eMDR)

You can complete an electronic submission from the _Adverse Event Report_ record via the **VPS: Submit to Gateway** action. This action creates a _Transmission_ record and transmits the latest version of the XML document to the <a href="/en/gr/66495/">FDA Electronic Submissions Gateway</a>. Vault sends the selected document file to the gateway when the _Transmission_ record enters the _Sending_ state.

The following health authorities support manual submission from Vault to the health authority:

- EU (EU MIR)
- Japan (PMDA Form 8)
- UK (MHRA)

You can submit EU MIR XML files to the appropriate NCA or notified body via email. You can submit PMDA Form 8 XML files to the Pharmaceuticals and Medical Devices Agency (PMDA) in Japan by downloading the XML file and uploading it to the PMDA web portal. You also can manually capture the acknowledgement for the receipt of the file from the health authority on the _Adverse Event Report_ object record.

## Generating PDF Reporting Documents

To create a PDF version of the adverse event reporting form, use the **Generate Adverse Event Report** action from the _Adverse Event Report_ record **Actions** menu. Depending on your Vault's configuration, Vault may automatically generate the PDF when the _Adverse Event Report_ enters the appropriate lifecycle state.

Once generated, Vault adds the PDF to the _Documents_ section of the _Adverse Event Report_ record.

### Supported PDF Formats

Product Surveillance supports PDF form generation for the following adverse event reporting formats:

* US FDA eMDR
* EU MIR
* Health Canada Mandatory Medical Device Problem Reporting Form
* UK MHRA

## Related Permissions

The following permissions control aspects of adverse event reporting:

|**Type**|**Permission Label**|**Controls**|
|Security Profile|Object: Complaint: MedTech Complaint|Ability to edit the _Is Reportable?_ field value.|

To utilize _Health Effect Codes_, _Device Problem Codes_, _Component Codes_, and _Investigation Codes_ on PMDA Form 8, users require _View_ and _Edit_ permissions on the _Problem Codes AE Report_ (`problem_codes_ae_report__v`) object and _View_ permission on the _Codes_ (`code__v`) object.

To delete codes on PMDA Form 8, users require _Delete_ permissions on the _AER - Code_ join object.

 [1]: #editing-aer-data
 [3]: #reportability-logic
 [4]: #generating-xml
 [5]: #submitting