Using MedTech Complaint Adverse Event Reporting (VPS)

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. Vault 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.

Vault 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.
  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 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. 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 necessary to complete or correct the Adverse Event Report.
  3. User performs the appropriate action to create an XML payload deliverable to the health authority.
  4. User performs the relevant action to send the XML payload to the appropriate health authority’s electronic submissions gateway.

About MedTech Complaint 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.
  • 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 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.

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.

About 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

Sections within the Adverse Event Report object detail page contain an Edit 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

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 object audit trail, users receive notifications of the error, or Vault may create an error report and attach it to the Adverse Event Report record. 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.

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.

Submitting XML Reporting Documents to a Health Authority

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 by by performing the VPS: Submit to Gateway action on the Adverse Event Report record. This action creates a Transmission record and transmits the latest version of the XML document to the health authority.

Vault sends the selected document file to the health authority’s gateway when the Transmission record enters the Sending state. Vault Product Surveillance supports submissions to the FDA Electronic Submissions Gateway.

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

Vault 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

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.