To enable Vault Product Surveillance (VPS) to automate reportability decision-making, create Adverse Event Reports, generate XML reporting forms, and enable Vault to send eMDR submissions to the FDA Electronic Submissions Gateway (ESG), you must configure several Vault components.
Configuration Overview
Complete the following configuration steps:
- Define Reporting Decision Rules for each Country from which you may receive MedTech Complaints.
- Create Country Report Type records, associating Countries with Report Type picklist values.
- Set up eMDR: MFR Report # auto-generation.
- Configure user actions and entry actions.
- Configure Reportability Assessment lifecycles and workflows.
- Configure the FDA Gateway Profile and create a Transmission Profile record.
Defining Reporting Decision Rules
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 MedTech Complaint record is a reportable event, you must create Reporting Decision Rules records for each combination of Country and Severity for which you could receive a MedTech Complaint. If you do not create a Reporting Decision Rule for a particular Country/Severity combination, then Vault will determine that any MedTech Complaint with that combination is not reportable.
Example: Creating Decision Rules using Requirement Data
For example, 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 Medtech Complaint. If the Reporting Decision Rule includes a Global reportability requirement, Vault creates Adverse Event Reports as necessary to fill the appropriate countries’ requirements at the configured point in the Medtech Complaint’s lifecycle.
Creating Country Report Types
Each Country Report Type object record associates a Country object record with a Report Type picklist value. Create Country Report Type records for each applicable Country according to your needs. You can associate Country Report Type records with a Transmission Profile record to enable electronic transmission of adverse event reports to the relevant health authority.
Gateway Configuration
Vault Product Surveillance supports electronic submissions to the US FDA electronic gateway. See Configuring FDA Gateway Integration (VPS) for more information on availability and setup.
eMDR: MFR Report # Generation
The eMDR MFR Report # (G8) requires following a strict numbering system constructed as follows: [FEI/CFN Number]-[Current Year]-[Report Number]
You can set up Vault Product Surveillance to auto-generate these numbers during the Generate Adverse Event Report XML actions. To ensure the numbers generate correctly, perform the following steps for each manufacturer which could be the subject of a report:
- Navigate to Business Admin > Objects > Manufacturer Report Number or to a custom object tab.
- Click Create.
- Select an Organization and enter an FEI/CFN Number for the organization.
- Enter the Current Year. This is for sequence initialization only, and when a new year arrives, Vault Product Surveillance automatically starts generating numbers with the new year.
- Enter the FDA Mfg Report Starting #. This is the starting point for auto-generated numbers, and should be incremented from your last manually-generated number.
- Click Save.
The system will automatically generate the Mfg Report # field on Adverse Event Report for eMDR using the above setup, based on the Manufacturing Site selected on the Complaint record.
Configuring Adverse Event Reporting Actions
Several actions drive adverse event reporting automation, and you must add them to the relevant object lifecycles to fit your organization’s needs:
Adverse Event Report Lifecycle
In Admin > Objects > Adverse Event Report > Actions, click Create and add the following custom actions:
- VPS: Generate Adverse Event Report XML
- VPS: Generate Adverse Event Report PDF
- VPS: Change state of related documents
- VPS: Submit to Gateway
- VPS: Generate Follow-up Report
- VPS: Run Validation
Add the VPS: Generate Adverse Event Report XML and VPS: Generate Adverse Event Report PDF user actions to the Adverse Event Report object lifecycle in the state in which all field data has been confirmed to be complete and accurate. Add the VPS: Submit to Gateway user action to the state in which the Adverse Event Report is ready for transmission. This may be the same state for both actions, depending on your processes.
Add the VPS: Change state of related documents action in the state in which generation of submission forms has completed. This action changes the state of the generated forms, being related documents on the Adverse Event Report record, to the target state.
Alternatively, you can configure these actions as entry actions on Adverse Event Report lifecycle states, if you want Vault to automatically perform them upon entering the appropriate lifecycle states.
Add the VPS: Generate Follow-up Report user action to the state selected as the Closed state type. This action creates a copy of the Closed Adverse Event Report with a linked reference to its originating record.
Add the VPS: Run Validation user action to the state in which users are adding information to the Adverse Event Report fields. This action checks field values on the record to ensure they are acceptable input. Validation errors are stored as related Validation Error records.
The Adverse Event Report lifecycle includes the following state types:
- XML Generated Successfully
- XML Generation Failed
- PDF Generated Successfully
- PDF Generation Failed
Assign states to these types based on your processes. For example, you can assign the Draft state to the XML Generation Failed state type, so that corrections can be made after the failure.
Configuring Reportability Assessment Lifecycle & Workflows
In the VPS: 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 VPS: 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 VPS: 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 VPS: Determine Reportability and VPS: Process Reportability entry actions in the Reportability Assessment Lifecycle. The VPS: Determine Reportability entry action creates new Reportability Assessment Effects records for all the countries that may require reporting, while the VPS: Process Reportability entry action creates Adverse Event Report records if the complaint is reportable.