Reporting Rule Parameter Reference

Learn about the rule parameters supported for Safety Rules.

About Safety Rules

The Safety Rules in a Safety Rule Set define the conditions for which a Transmission is generated. Each Safety Rule has a set of parameters. The parameters must evaluate successfully for the rule to pass.

A Safety Rule’s Priority defines the order in which Vault attempts to match each reporting rule, which are processed from lowest to highest. To prevent over-reporting, once Vault finds the first matching rule, further rules are not evaluated.

The following image shows an example of a Safety Rule:

The following sections describe the parameters Vault supports for Safety Rules.

Reporting Rule Parameters

The following table describes the reporting rule parameters that Vault evaluates. The Type column identifies whether a parameter is an input or output parameter. Input parameters evaluate Case criteria to find a matching rule. Output parameters control how the Transmission is generated.

Parameter Type (Input/Output) Description

Report Type

Input

The Case's Report Type (report_type__v) classification.

The value must be a Report Type that is configured in the Controlled Vocabulary. Vault evaluates this parameter for Report Types with the same E2B code.

Study Type

Input

The Case's Study Type (product_usage_reason__v) classification.

The EMA rule set uses the Study Type parameter to differentiate between clinical trials and other study types.

The value must be a Study Type that is configured in the Controlled Vocabulary. Vault evaluates this parameter for Study Types with the same E2B code.

Note: If the Study Type value on the Case is left blank, this parameter is regarded as a Clinical Trial.

Serious Input Whether a value is populated in the Seriousness (seriousness__v) field on the Case Adverse Event associated with the Most Reportable Case Product and Case Assessment being evaluated.

Life Threatening Input Whether "Life threatening" is populated in the Seriousness (seriousness__v) field on the Case Adverse Event associated with the Most Reportable Case Product and Case Assessment being evaluated.

Fatal Input Whether "Results in death" is populated in the Seriousness (seriousness__v) field on the Case Adverse Event associated with the Most Reportable Case Product and Case Assessment being evaluated.

Expected

Input

Note: The following text describes Vault behavior during general reporting. For information on cross reporting, see Cross Reporting Evaluation of Expectedness Rule Parameter.

When evaluating reporting obligations for Global Cases, Vault locates the relevant Case Assessment Expectedness records based on the Most Reportable Case Product and Case Assessment being evaluated.

Vault uses the following logic to evaluate the appropriate Expectedness records for this parameter.

Expectedness Evaluation Logic

Vault first looks for Expectedness records under the relevant Case Assessment, then executes the following logic depending on whether the Case is part of a Study:

Non-Study Cases:
1. Vault first evaluates all Local Datasheets for countries in the jurisdiction of the agency using the following logic:
  - Expected: If all local Expectedness records are Expected.
  - Unexpected: When one (1) or more local Expectedness records is Unexpected or blank.
2. If there are no Local Datasheets within the reporting jurisdiction, the Expected value corresponding to the Product's Core Datasheet is used.
3. If there are no Expectedness records, Vault uses the value from the Expected field on the relevant Case Assessment.
Study Cases:
1. Vault first evaluates all Study Product Datasheets for Study Products in the Case using the following logic:
  - Expected: If all Study Product Expectedness records are Expected.
  - Unexpected: When one or more Study Product Expectedness records are Unexpected or blank.
  If there are no Study Product Datasheets, Vault performs the evaluation based on the Study Core Datasheet to set the Expected value.
2. For Clinical Trial Study Cases only, expectedness evaluation considers Case Adverse Event Onset date by default. For a Case Adverse Event to be considered expected, the Onset date must fall within the active date range for the MedDRA Term on the Datasheet. Dates outside this range are considered unexpected. If there is no Active End Date, the term is considered to be expected to the present day. If there is no Active Start Date or Active End Date, the term is always considered expected. If the Onset date is not available, Vault uses the Receipt Date on the Case for the evaluation.
  
  If your Admin has enabled Agency-Based Auto-Expectedness for Clinical Trial Study Cases, Vault performs expectedness evaluations considering the New Info Date on the Case for Agencies with that configuration. In that scenario, if New Info Date is not available, Vault performs evaluations using the Onset date.
3. For Postmarket Study Cases only, if there is no Study Datasheet, Vault then looks at all Local Datasheets for countries in the jurisdiction of the agency using the following logic:
  - Expected: If all local Expectedness records are Expected.
  - Unexpected: When one or more local Expectedness records are Unexpected or blank.
  This step does not occur for Clinical Trial Study Cases.
4. Otherwise, the Expected value corresponding to the Product's Core Datasheet is used.
5. If there are no Expectedness records, Vault uses the value from the Expected field on the relevant Case Assessment.

When evaluating reporting obligations for Localized Cases, Vault first considers the Localized Case Assessment Expectedness. If the Expectedness is blank, the Global Case logic described above is applied.

Suspect

Input

The Drug Role (drug_role__v) field on the relevant Case Product. This parameter is evaluated as follows:

If set to "Suspect or Drug Not Administered", the parameter is evaluated as "Yes" when the Drug Role is either Suspect, Interacting, or Drug Not Administered.
If this parameter is blank, Vault also evaluates with this setting.
If set to "Yes", the parameter is evaluated as "Yes" when the Drug Role is either Suspect or Interacting.

Note: To use the “Suspect or Drug Not Administered” setting, your Admin must enable Extend Definition of Suspect to Drug Not Administered.

AE in Jurisdiction

Input

For Submissions: Whether the Agency is assigned jurisdiction over the Country (country_value__v) selected for the primary Reporter-type Case Contact.

You can view the countries in an agency's jurisdiction by going to the Agency-type Organization record in the Business Admin area.

For Distributions: Whether the Reporting Family based on the Distribution Jurisdiction is assigned for the Country (country_value__v) selected for the primary Reporter-type Case Contact.

AE in Jurisdiction Source

Input

Specifies how Vault evaluates the AE in Jurisdiction parameter.

Enter one of the following Parameter Values in the Value field to determine when Vault considers the Case to be in Jurisdiction:

Parameter Value	Criteria for Case to be in Jurisdiction
Primary Event Country	The Country of the Primary Case Adverse Event matches the jurisdiction Country. Vault extends the result of this evaluation to the other Adverse Events on the Case regardless of their countries.
Any Event Country	Any of the Case Adverse Events has a Country that matches the defined jurisdiction Country.
Primary Reporter Country	The Primary Case Contact with type Reporter has a Country that matches the jurisdiction Country.
Primary Reporter Country, Any Event Country	The Primary Reporter or any Adverse Event has a Country that matches the jurisdiction Country.
Primary Reporter Country, Primary Event Country	The Primary Reporter or the Primary Adverse Event has a Country that matches the jurisdiction Country.
Primary Reporter Country, Otherwise Primary Event Country¹	If the Primary Reporter Country is specified, Vault considers the Case to be in jurisdiction if the Primary Reporter Country matches the jurisdiction Country. If the Primary Reporter Country is not specified, Vault uses the Primary Event Country evaluation method.

Note: 1. Vault uses this method to evaluate the AE in Jurisdiction parameter in a rule if the rule does not specify an AE in Jurisdiction Source.

Exclude

Input

Evaluates whether Vault excludes placebos when evaluating suspect Case Products for a Study Case.

This parameter accepts "Placebo" as an acceptable value.

Note: Submission rules to not apply to Study Products with a Study Product Role of Placebo. Once unblinding is completed, if all Case Products are placebos, Submissions are not generated.

Assessment Criteria

Input

Vault evaluates this parameter using the Assessment Tag (assessment_tag__v) field value on the Most Reportable Case Product and Case Assessment being evaluated.

This parameter accepts "SUSAR" or "SAE" as acceptable values.

Vault Safety automatically assigns case and assessment tags. See How Case SAE and SUSAR Tags are Assigned for more information.

Assessment Source

Input

Evaluates the Case Assessment Source in relation to the Related rule parameter, to consider the source of a causality assessment. This parameter is evaluated as "True" when both Source Type matches this parameter and the Related parameter is evaluated as "Related".

Vault evaluates this parameter using the Controlled Vocabulary E2B Code corresponding to the Source Type (source_type__v) on the Most Reportable Case Product and Case Assessment being evaluated.

Device Report Type

Input

The Case Device Report Type (device_report_type__v) classification. This parameter is used in FDA device reporting rules.

This parameter accepts "Public Health Risk" or "Malfunction Only" as acceptable values.

Downgrade

Input and Output

Vault uses the Downgrade parameter value to determine whether the seriousness, expectedness, and relatedness of the current Case's Most Conservative Product/Assessment (MCP/MCA) are downgraded from the previous Case version. This parameter also determines whether this is an upgrade or downgrade based on the previous transmission's lifecycle state as shown in the following table.

Downgrade Parameter Value	Parameter Evaluation Logic
Yes	All of the following conditions must apply: The Case is in the ACK Accepted or Completed Transmission Lifecycle state. The Case was previously submitted to the same Destination and Transmission Profile. The Seriousness/Expectedness/Relatedness of the current Case's Most Conservative Product/Assessment (MCP/MCA) is lower on the priority list than the previous Case version submitted to the same Destination and Transmission Profile.
All Transmission States	All of the following conditions must apply: The Case is in any Transmission Lifecycle state except Inactive or the Transmission Deleted state type. The Case was previously submitted to the same Destination and Transmission Profile. The Seriousness/Expectedness/Relatedness of the current Case's Most Conservative Product/Assessment (MCP/MCA) is lower on the priority list than the previous Case version submitted to the same Destination and Transmission Profile.
No	The Seriousness/Expectedness/Relatedness of the current Case's Most Conservative Product/Assessment (MCP/MCA) is the same or higher on the priority list than that of the previous Case version submitted to the same Destination and Transmission Profile, regardless of Transmission Lifecycle state.

This parameter also controls whether the Downgraded field on the Transmission is populated.

Note: This parameter is not supported for Localized Case Assessment Due Date calculation.

Downgrade Scenario

Input and Output

Vault uses the Downgrade Scenario parameter value to determine whether the seriousness, expectedness, and relatedness of the current Case's Most Conservative Product/Assessment (MCP/MCA) are downgraded from the previous Case version. This parameter is similar to the Downgrade parameter with the addition that you specify which Most Conservative Assessment (MCA) ranking scenarios Vault considers a downgrade from the previous Case version.

How to Specify a Downgrade Scenario

Enter the Downgrade Scenario in the format R_p-R_c, where R_p and R_c are the MCA ranking of the previous and current Case versions respectively. You can define the current and previous MCA rankings as a single number or a range of numbers separated by a comma (,). You can also enter multiple scenarios separated by a semicolon (;). The following table provides an example of each of these options:

Downgrade Scenario Example (`R_p-R_c`)	MCA Ranking
Downgrade Scenario Example (`R_p-R_c`)	Previous Case Version	Current Case Version
2-3	Serious Unexpected Related (SUSAR)	Serious Unexpected Unrelated (SU)
2,3-4,5	Serious Unexpected Related (SUSAR) or Serious Unexpected Unrelated (SU)	Serious Expected Related (SESAR) or Serious Expected Unrelated (SE)
2-3;4,5-6,7	Serious Unexpected Related (SUSAR)	Serious Unexpected Unrelated (SU)
	or
	Serious Expected Related (SESAR) or Serious Expected Unrelated (SE)	Non-Serious Unexpected Related (NSUR) or Non-Serious Unexpected Unrelated (NSU)

If the MCA rankings of the previous Case version and the current Case version match those specified in this parameter, Vault evaluates this parameter as True and sets the Downgraded field on the Transmission to True if the rule passes.

If you are using the Downgrade Scenario parameter, we strongly recommend you also include a Downgrade parameter to define which Transmission states are considered.

Note: This parameter is not supported for Localized Case Assessment Due Date calculation.

Transmission Reason

Input and Output

This parameter is evaluated using the previous Transmissions to the same reporting destination and sets the Reason (reason__v) field on the Transmission.

Depending on your Admin's configuration of the Transmission Reason Determination setting, Vault may evaluate Transmissions in all states or only in the E2B ACK Accepted or Completed states.

To evaluate this parameter, Vault uses the following logic:

Evaluates as Follow-Up if either of the following conditions are met:
- A previous Case version has a Transmission to the same reporting destination in an applicable state.
- A previous Case version is of the Imported Case object type and the Imported Case does not have a Transmission to same reporting destination.
In all other scenarios, evaluates as Initial.

Registration Type

Input

For Japan Localized Cases, Vault evaluates the Registration Type classification on the Case Product Registration section of the Localized Case Assessment. When evaluating this reporting rule parameter at the global Case level, Vault evaluates the Registration Type of all PMDA Product Registrations in the product library for the most conservative Product for that agency.

For Cases where the Product being evaluated is a component of a combination product, the Registration Type reporting rule parameter evaluates the registration of the constituent product.

The value must be a Registration Type that is configured in the Controlled Vocabulary.

This parameter is used in PMDA reporting rules only.

Rule Execution Level

Input

The Rule Execution Level (rule_execution_level__v) for the rule set. This may be set to one of the following values:

Global Case
Localized Case

If set to Global Case, the rule set is evaluated when the Evaluate Reporting Obligations action is run on the Global Case only.

If set to Localized Case, the rule set is evaluated when the Evaluate Reporting Obligations action is run on the Localized Case only.

If left blank, the rule set is evaluated when the Evaluate Reporting Obligations action is run on either the Global or Localized Case.

PMDA Reporting Category

Input

The PMDA Reporting Category (pmda_reporting_category__v) classification on the Local Reporting Details section of a Japan Localized Case.

This parameter accepts a comma separated-list of the active values from within the PMDA Reporting Category picklist.

This parameter applies only when using PMDA ICSR Reporting Rule Set Version 1.0.

Infection

Input

Evaluates whether the Localized Case includes a Special Adverse Event (special_adverse_event__v) that is set to Infection.

This parameter is used in PMDA reporting rules and is evaluated only when the rule is run on Localized Cases.

Special Report Classification

Input

The Special Report Classification (special_report_classification__v) on the Case. The Case may be classified as a Safety Measure Report or a Research Report.

This parameter is used in PMDA reporting rules. Special Report Classification is an optional field.

If this parameter is set to "No", the rule is evaluated when the Special Report Classification field is blank.

When evaluating reporting rules, Cases with Special Report Classification values are always excluded unless this parameter is specified in the Safety Rule Set.

Optionally, contact Veeva Managed Services to have additional options created for this field. This is useful in situations when Cases should be reported to certain destinations only.

Previously Localized

Input

If this parameter is set to "Yes", the rule evaluates whether a previous version of the Case has a Completed/ACK Accepted Submission to the same agency where the One Last Time (OLT) rule is not evaluated as "True".

If this parameter is set to "All Transmission States", the rule evaluates if a previous version of the Case has a Submission in any state (except Inactive or a Deleted state type) to the same agency where OLT is not evaluated as "True".

Note: Vault cannot automatically set OLT to True on Local Reporting Detail-based Localized Submission records. This is a known limitation that will be addressed in a future release.

Related

Input

Evaluates whether a causality assessment categorized the adverse event as related to the suspect product.

Vault evaluates this parameter as "Related" when the Most Reportable Case Product and Case Assessment being evaluated contains at least one Case Assessment Result with the Causality Established (causality_established__v) field set to "Yes" or blank.

Previously Submitted

Input

Evaluates whether previous Case versions have been submitted. The logic used by Vault is based on whether the parameter is set to "Yes" or "All Transmission States" as follows:

Yes:
- Vault evaluates all previous Case versions with a Transmission in the "E2B ACK Accepted" or "Completed" state for the same reporting Destination and Transmission Profile.
- Vault then checks that the Downgrade reporting rule parameter was not evaluated as "Yes".
- Finally, Vault checks that the most recent Transmission that meets the first two conditions has Submit one last time set to "No".
All Transmission States:
- Vault evaluates all previous Case versions with a Transmission in any lifecycle state, except for Inactive or Deleted, for the same reporting Destination and Transmission Profile.
- Vault checks that the most recent Transmission that meets the above conditions has Submit one last time set to "No."

Note: This parameter is not supported for Localized Case Assessment Due Date calculation. To use One Last Time Reporting for Japan, do not create a Rule with the Previously Submitted parameter. Instead, enable Japan One Last Time Reporting in your Vault.

Upgrade

Input

Vault determines whether the current Case's seriousness, expectedness, and relatedness are upgraded from the previous Case version depending on the Upgrade parameter value, as shown in the table below.

Upgrade Parameter Value	Parameter Evaluation Logic
Yes	All of the following conditions must apply: The Case is in the ACK Accepted or Completed Transmission Lifecycle state. The Case was previously submitted to the same Destination and Transmission Profile. The Seriousness/Expectedness/Relatedness of the current Case's Most Conservative Product/Assessment (MCP/MCA) is higher on the priority list than the previous Case version submitted to the same Destination and Transmission Profile.
All Transmission States	All of the following conditions must apply: The Case is in any Transmission Lifecycle state except Inactive or the Transmission Deleted state type. The Case was previously submitted to the same Destination and Transmission Profile. The Seriousness/Expectedness/Relatedness of the current Case's Most Conservative Product/Assessment (MCP/MCA) is higher on the priority list than the previous Case version submitted to the same Destination and Transmission Profile.
No	The Seriousness/Expectedness/Relatedness of the current Case's Most Conservative Product/Assessment (MCP/MCA) is the same or lower on the priority list than that of the previous Case version submitted to the same Destination and Transmission Profile, regardless of Transmission Lifecycle state.

Note: This parameter is not supported for Localized Case Assessment Due Date calculation.

Upgrade Scenario

Input

Vault uses the Upgrade Scenario parameter value to determine whether the seriousness, expectedness, and relatedness of the current Case's Most Conservative Product/Assessment (MCP/MCA) are upgraded from the previous Case version. This parameter is similar to the Upgrade parameter with the addition that you specify which Most Conservative Assessment (MCA) ranking scenarios Vault considers an upgrade from the previous Case version.

How to Specify an Upgrade Scenario

Enter the Upgrade Scenario in the format R_p-R_c, where R_p and R_c are the MCA ranking of the previous and current Case versions respectively. You can define the current and previous MCA rankings as a single number or a range of numbers separated by a comma (,). You can also enter multiple scenarios separated by a semicolon (;). The following table provides an example of each of these options:

Upgrade Scenario Example (`R_p-R_c`)	MCA Ranking
Upgrade Scenario Example (`R_p-R_c`)	Previous Case Version	Current Case Version
3-2	Serious Unexpected Unrelated (SU)	Serious Unexpected Related (SUSAR)
4,5-2,3	Serious Expected Related (SESAR) or Serious Expected Unrelated (SE)	Serious Unexpected Related (SUSAR) or Serious Unexpected Unrelated (SU)
3-2;6,7-4,5	Serious Unexpected Unrelated (SU)	Serious Unexpected Related (SUSAR)
	or
	Non-Serious Unexpected Related (NSUR) or Non-Serious Unexpected Unrelated (NSU)	Serious Expected Related (SESAR) or Serious Expected Unrelated (SE)

If the MCA rankings of the previous Case version and the current Case version match those specified in this parameter, Vault evaluates this parameter as True.

If you are using the Downgrade Scenario parameter, we strongly recommend you also include a Downgrade parameter to define which Transmission states are considered.

Note: This parameter is not supported for Localized Case Assessment Due Date calculation.

Exclude MedDRA Query

Input

Evaluates if a Case Adverse Event and its associated Assessments match with terms defined within a MedDRA Query (SMQ/CMQ). If an Adverse Event matches then Vault does not consider its Assessments for Reporting Rule evaluation. As a result, if all Case Adverse Events and their associated Assessments match, Vault does not generate a Transmission.

The value you enter for this parameter must correspond to an active meddra_query__v.

You can define the Submission Rule Scope on the referenced MedDRA query to constrain the search to either Broad or Narrow, as described in the Custom MedDRA Queries section of Use MedDRA Queries.

Include MedDRA Query

Input

Evaluates if a Case Adverse Event and its associated Assessments match with terms defined within a MedDRA Query (SMQ/CMQ). If an Adverse Event matches then Vault will consider its Assessments for Reporting Rule evaluation. As a result, if any Case Adverse Event and its associated Assessments match, Vault may generate a Transmission.

The value you enter entered for this parameter must correspond to an active meddra_query__v.

Reporting Scenario

N/A

Evaluates the reporting rule for potential cross reporting scenarios, if listed in this parameter.

If this parameter is left blank, Vault evaluates the Case for general reporting only.

To use cross reporting, specify one or more cross reporting scenarios. Specify "General Reporting" along with cross reporting scenarios if the rule should general reporting too. This parameter accepts the following options:

Investigational to Marketing (same agency)
Investigational to Marketing (cross agency)
Investigational to Investigational (cross agency)
Marketing to Marketing (cross agency)
Marketing to Investigational (cross agency)
General Reporting

Note: You do not need to specify the general reporting scenario unless you are pairing it with additional cross reporting scenarios. The general reporting scenario is used by default if this parameter is empty.

Product

Input

Restricts the rule to only consider Case Products that contain the defined Product as eligible.

This parameter accepts a comma-separated list of active Product (product__v) API Names.

General Reporting:

This parameter evaluates as "True" when a Case contains a Case Product with a matching API Name and a Drug Role of Suspect, Interacting, or Drug Not Administered.

Note: To include Case Products with a Drug Role of Drug Not Administered in this parameter, your Admin must enable Extend Definition of Suspect to Drug Not Administered.

Cross Reporting:

If Substitute Product/Study for Cross Reporting¹ is enabled, then for X→M cross reporting scenarios, this parameter evaluates as "True" when the substituted Product's Registration is evaluated for cross reporting.

If Substitute Product/Study for Cross Reporting is not enabled, this parameter is evaluated as for General Reporting above.

Product Family

Input

Restricts the rule to only consider Case Products that contain a product in the defined Product Family as eligible.

This parameter accepts a comma-separated list of active Product Family API Names (product_family__v.api_name__v).

General Reporting:

This parameter evaluates as "True" when a Case contains a Case Product belonging to a Product Family with a matching API Name and a Drug Role of Suspect, Interacting, or Drug Not Administered.

Note: To include Case Products with a Drug Role of Drug Not Administered in this parameter, your Admin must enable Extend Definition of Suspect to Drug Not Administered.

Cross Reporting:

If Substitute Product/Study for Cross Reporting1 is enabled, then for X→M cross reporting scenarios, Vault evaluates the substituted Product's Product Family against this parameter.

If Substitute Product/Study for Cross Reporting is not enabled, Vault evaluates this parameter as for General Reporting above.

Study

Input

Evaluates whether a Case is associated with a specific Study.

This parameter accepts a comma-separated list of active Study API Names.

General Reporting:

This parameter evaluates as "True" when the Study (study__v) selected on the Case has a matching API Name.

Cross Reporting:

If Substitute Product/Study for Cross Reporting¹ is enabled, then for X→I cross reporting scenarios, this parameter evaluates as "True" when the provided Clinical Trial Study's Registration is evaluated for cross reporting.

If Substitute Product/Study for Cross Reporting is not enabled, this parameter is evaluated as for General Reporting above.

Identifiable Patient Definition

Input

Evaluates whether the Case has an identifiable patient.

The following list describes how Vault evaluates this parameter, depending on the value specified for a reporting rule set:

E2D: Evaluated as "True" when a patient is identified on a Case with an age, name, sex, or MRN. The following table shows the list of fields Vault evaluates to find an identifiable patient:

Field	Value
Age Group (`age_group__v`)	Any
Age (`age_value__v`) and Age Unit (`age_unit__v`)	Any
Sex (`gender_value__v`)	Any
Gender Reason Omitted (`gender_reason_omitted__v`)	MSK
Patient Initials (`patient_id_value__v`)	Any
Patient Initials Reason Omitted (`patient_id_reason_omitted__v`)	MSK
First Name (`patient_first_name__v`)	Any
First Name Reason Omitted (`patient_first_name_reason_omitted__v`)	MSK
Middle Name (`patient_middle_name__v`)	Any
Middle Name Reason Omitted (`patient_middle_name_reason_omitted__v`)	MSK
Last Name (`patient_last_name__v`)	Any
Last Name Reason Omitted (`patient_last_name_reason_omitted__v`)	MSK
Investigation MRN (`mrn_investigation_value__v`)	Any
Investigation MRN Reason Omitted (`mrn_investigation_reason_omitted__v`)	MSK
Specialist MRN (`mrn_specialist_value__v`)	Any
Specialist MRN Reason Omitted (`mrn_specialist_reason_omitted__v`)	MSK
Hospital MRN (`mrn_hospital_value__v`)	Any
Hospital MRN Reason Omitted (`mrn_hospital_reason_omitted__v`)	MSK
GP MRN (`mrn_gp_value__v`)	Any
GP MRN Reason Omitted (`mrn_gp_reason_omitted__v`)	MSK

E2D or Patient Known to Exist: Evaluated as "True" when the Patient Known to Exist (patient_known_to_exist__v) field or any of the above fields are populated on the Case.

Local Expedited Criteria

Output

Controls the Local Expedited Criteria field on the Transmission. This parameter accepts the following values:

Yes: Populates "Yes"
No: Populates "No"
Same as Previous: If there is a previous version of the Case with a Transmission to the same agency in the "Completed" or "E2B ACK Accepted" state, copies the value from the previous Transmission.

Note: We recommend that you contact Veeva Managed Services if you receive an error when using the Same as Previous option.

PMDA Localized Cases

For PMDA Localized Cases where the Localization record's Assessment Generation field is set to "Localized Assessments for Case Product Registrations", Vault processes the Local Expedited Criteria reporting rule parameter as follows:

Yes: Sets the Local Expedited Criteria field on the current Localized Case Assessment (LCA) record to Yes.
No: Sets the Local Expedited Criteria field on the current LCA record to No.
Same as Previous: The parameter is ignored and the Local Expedited Criteria field is not set on the current LCA record.

The Rule Engine then uses the value of the Localized Case Assessment Local Expedited Criteria field to set the same field on the related Case Product Registrations. For more information, see One Last Time Reporting for Japan (PMDA) in Report to the PMDA.

Due in Days

Output

The Transmission due date, in days. The earliest Transmission due date is also populated in the Case Due Date field.

For PMDA transmissions, system behavior depends on your Admin's configuration of the Japan Localization record. See the following considerations:

If Assessment Generation is set to Localized Assessments for Case Product Registrations, Due in Days is calculated for and populated on each Localized Case Assessment. For more information on Due in Days and Due Date calculations, see Evaluate Reporting Obligations for Localized Case Assessments in Complete Intake and Process Cases for the PMDA.
If Assessment Generation is blank, the following considerations apply:
- If there is a Previously Submitted version of a Case, the due date is calculated by adding the value of the Local Awareness Date on the Japan local Case and the Due in Days value, and then populated on the Transmission.
- If there is no Local Awareness Date, the due date is calculated by adding the New Info Date and the Due in Days value, and then populated on the Transmission.
- The Due in Days field value is also used to determine Due in Days for PMDA downgrade reports. If the Due in Days field value in the previous Transmission record is deleted or not entered when the Transmission record is manually generated, Vault will use 15 days as default.
To avoid deleting or missing an entry in the Due in Days field, we recommend that your Admin configures a validation rule for the Due in Days field to be mandatory.

This parameter accepts a positive whole number value.

Due in Days Override

Output

For inherited rules, you can override the due date from the parent rule.

For example, if a parent rule calculates Due in Days as 15 days, enter "7" in this field to override the Due in Days value to seven (7) days.

This parameter accepts a positive whole number value.

Due in Days Adjustment

Output

For inherited rules, you can adjust the due date from the parent rule.

For example, if a parent rule calculates Due in Days as 15 days, enter "-3" in this field to override the Due in Days value to 12 days.

This parameter accepts a positive or negative whole number value.

Mask PII

Output

Evaluates whether the Case requires Personal Identifiable Information (PII) masking for Submissions.

The following list describes how Vault evaluates this parameter, depending on the value specified for a reporting rule:

All: The Patient Content Protection (patient_content_protection__v) field is set to "Mask PII" on the Submission.
Foreign: If the AE in Jurisdiction parameter is evaluated as "No", then the Patient Content Protection (patient_content_protection__v) field is set to "Mask PII" on the Submission.

Note: This parameter applies only to Submissions. Distributions snapshot masking options from the Reporting Family.

Exceptions to PII Masking

Output

Evaluates whether a Case requires exceptions to PII masking for Submissions. This parameter is evaluated only if the Mask PII parameter is in use.

This parameter accepts a comma-separated list of any of the following picklist values:

blank_fields__v, parent_sex__v, patient_sex__v, null_flavors__v

If a reporting rule specifies this parameter, the Exceptions to Patient Content Protection field is set to the specified values on the Submission.

Note: This parameter applies only to Submissions. Distributions snapshot masking options from the Reporting Family.

Transmission Profile Override

Output

If a reporting rule specifies this parameter and the rule executes resulting in a Submission/Distribution, the Transmission record will have the Transmission Profile populated from the value in the rule parameter. This value will override any defaults selected on Product/Study Registrations or any defaulting logic based on the type of the products selected in the Case.

The parameter accepts the API Name of the appropriate Transmission Profile. The value entered must correspond to an active transmission_profile__v.

Suppress File Generation Input If this parameter is set to "Yes", when a Transmission record is created that uses this rule, initial file generation is suppressed.

Product Registration Type

Input

Evaluates whether a Case contains a Product of the specified Product Registration Type.

This parameter accepts a comma-separated list of active Product Type (product_type__v) names.

The acceptable Product Types include the following:

Drug (drug__v)
Biologic (biologic__v)
Device (device__v)
Vaccine (vaccine__v)
Combination Product (combination_product__v)
Cosmetic (cosmetic__v)
Nutritional (nutritional__v)
OTC Drug (otc_drug__v)
OTC Device (otc_device__v)

If your Vault contains custom Product Types, these can be added to the Product Registration Type parameter if required.

The rule will pass if any Product on the Case has a Product Registration whose Registered As field matches one of the specified Product Registration Types within the jurisdiction of the agency destination being evaluated.

If this field is left blank, the rule will pass if the Case contains a Product with one of the following Product Types:

Drugs
Biologics
Vaccines
Combination Products

In addition, for Cross Reporting (X→M Scenarios), the parameter will evaluate the Transmission Product Type of the registration which is generating a cross reporting obligation.

Note: For Cross Reporting (X→I Scenarios), the Product Registration Type parameter is not supported and so will always pass.

When evaluating a Distribution, Vault Safety obtains the Transmission Product Type as follows:

If the Distribution is based on a Product, Vault uses the Transmission Product Type from within the Product Reporting Family Member.
If the Distribution is based on a Product Registration, Vault uses the Transmission Product Type from the linked Registration within the Product Registration Reporting Family Member.
If the Distribution is based on a Study or Study Registration, the parameter is ignored.

Auto-Submit Override

Output

Overrides the value of the Transmission's Auto-Submit field.

If a rule containing this parameter passes, Vault overrides the Auto-Submit value set by the Transmission Profile and sets the Transmission's Auto-Submit field according to the setting of this parameter, as follows:

Auto-Submit Override Setting	Auto-Submit Field Value on Transmission
Yes	Yes
Null	The field is left blank

For an automatically created One Last Time (OLT) Transmission, Vault sets the Auto-Submit field value to the same value as the previous Transmission (instead of from the Transmission Profile).

For more information about the Auto-Submit feature, see Auto-Submissions.

Transmission Output Template

Output

Specifies the Transmissions that Vault generates if the rule passes in addition to the standard Transmission.

This parameter accepts a comma-separated list of active Transmission Output Template API Names (transmission_output_template__v.api_name__v).

For more information on configuring Vault to send multiple Transmissions per passing reporting rule, see Manage Transmission Output Templates

Study Product Role

Input

This parameter accepts a comma-separated list of the active values from within the Study Product Roles picklist and applies to Clinical Trial Study Cases with specified Products.

If you specify one (1) or more Study Product Roles with this parameter, Vault considers only Case Products based on a Study Product with a matching Study Product Role as eligible products.

If a Study Product Country record for a Study Product exists, that overrides this parameter.

Note: For Distribution, Partner, and MAH evaluation, Vault applies this parameter only when evaluation is based on a Study Registration in the Reporting Family.

Case Data - Expression

Input

With this parameter, you can configure custom reporting rule parameters to evaluate Case data using a Rule Engine expression.

For the parameter Value, enter an expression that describes how Vault evaluates the record data of the Case or any of its eligible Case Assessments.

If Vault evaluates the expression as True, the rule passes. If Vault evaluates the expression as False, the rule fails.

1. The Substitute Product/Study for Cross Reporting setting is located under Admin > Settings > ICSR Settings.

Write Custom Case Data Reporting Rule Parameters

When writing the expression for a Case Data - Expression reporting rule parameter, use the following format:

VS_LET(var, path_to_validating_records, expression)

The path_to_validating_records tells the Rule Engine where to find the set of records to evaluate relative to the top-level object. The Rule Engine performs the expression on each record to obtain a set of pass and fail results.

See the sections below for more details on both parts of the expression.

Path to Validating Records

When writing the path_to_validating_records, select either the Case record or the Case’s eligible Case Assessment records as the beginning of the path to the validating records (the top-level object).

For a Case Data - Expression reporting rule parameter, use one (1) of the following as the top-level object for the path_to_validating_records depending on whether the evaluation is for a global or localized Case, and whether Vault should perform the expression on Case-related data or the eligible Case Assessment-related data:

Global or Localized Case Evaluation	Top-Level Object	Top-Level Object for `path_to_validating_records`
Global	Case record	`case_version__v`
Global	Eligible Case Assessment records¹	`eligible_case_assessments__v`
Localized	Case record	`localized_case_version__v`
Localized	Eligible Case Assessment records¹	`eligible_localized_case_assessments__v`

Note: The eligible_case_assessments__v and eligible_localized_case_assessments__v top-level objects are special instances of the Case Assessment (case_assessment__v) and Localized Case Assessment (localized_case_assessment__v) objects respectively. They contain a list of the eligible Case Assessment records for the Case, as determined by the Safety Rule Engine.

From the top-level object, you can specify the path to the validating records. It is important to use the correct Vault object relationship names when specifying this path. To obtain the relationship names for an object, navigate to Admin > Configuration > Objects > [object] > Relationships. To obtain the relationship names for the eligible_case_assessments__v and eligible_localized_case_assessments__v top-level objects, refer to the Case Assessment (case_assessment__v) and Localized Case Assessment (localized_case_assessment__v) object relationships respectively.

If the Safety Rule concerns Case Assessments, use either eligible_case_assessments__v or eligible_localized_case_assessments__v as the top-level object, otherwise use either case_version__v or localized_case_version__v as the top-level object.

The following are example paths to validating records:

case_version__v.case_products_case_version__vr returns all of the Case Products associated with the Case.
eligible_case_assessments__v.expectedness__vr returns the value in the Expectedness field of each eligible Case Assessment.

Case Data Expression

When writing the expression for your custom Case data Reporting Rule Parameters, you can use any functions and operators in the Vault Formula Reference Guide and any functions described in Configure Custom Validation Criteria, which are specific to Vault Safety.

Note: For Vault to evaluate the rule as either a pass or a fail, the result of the expression must evaluate as either true (the rule passes) or false (the rule fails).

Custom Case Data Reporting Rule Parameter Examples

The following table describes example expressions using Case record data and data from eligible Case Assessment records:

Example Case Data Expression	Description
`VS_LET(ca, eligible_case_assessments__v, ca.expectedness__vr=false)`	Returns true (the rule passes) if the Expectedness field of each eligible Case Assessment is set to false.
`VS_LET(ca, eligible_case_assessments__v, VS_ANYOF(ca.case_assessment_results_case_prod_assmt__vr.causality_established__v, LAMBDA(e, e=true)))`	Returns true if any of the eligible Case Assessments has at least one (1) linked Case Assessment Result where Causality Established is Yes.
`VS_LET(cp, case_version__v.case_products_case_version__vr, cp.action_taken__vr.api_name__v != "dose_unchanged__v")`	Returns true if all of the Case Product records on the Case have an Action Taken value other than Dose Not Changed.
`VS_LET(lrd, localized_case__v.local_reporting_details__vr, lrd.completeness__v != "incomplete__v")`	Returns true if the Local Reporting Details on the Localized Case has a Completeness value other than Incomplete.

Troubleshoot Custom Case Data Reporting Rule Parameters

For help troubleshooting Case data expressions, use the Rule Engine Troubleshooting Report as described in Troubleshoot Safety Rules.

Most Conservative Product/Assessment (MCP/MCA) for Upgrades and Downgrades

When evaluating the Downgrade, Downgrade Scenario, Upgrade, and Upgrade Scenario reporting rule parameters, Vault determines the Most Conservative Product (MCP) and Most Conservative Assessment (MCA) for the current and previous Case versions using the criteria described in the following sections.

Most Conservative Product Criteria

Vault finds the most conservative Case Product for a region using the following criteria:

For a non-clinical trial Case: Contains a Product Registration for a Country within the jurisdiction of the Agency being evaluated by the rule set.
For a clinical trial Case: Contains a Study Product for a Study registered for a Country within the jurisdiction of the Agency being evaluated by the rule set.
Contains a Drug Role set to Suspect or Interacting.
Is associated with the most conservative Case Assessment for the region. If one or more Case Products for the region are not associated with a Case Assessment, Vault queries all Case Products with Case Assessments to identify the most conservative product and assessment.
For cross reporting, Vault considers only Case Products that are being cross reported to, rather than all Case Products.

Note: If multiple Case Products match the above criteria, Vault uses the product with the highest value in the Rank field.

Note: Device constituents cannot be considered the most conservative product.

Most Conservative Assessment Criteria

The following table outlines how Vault ranks Case Assessments using the above data in the Most Conservative Product Criteria section, from most to least conservative:

Summary	Seriousness	Expectedness	Relatedness	Ranking
Fatal/LT SUSAR	Fatal Life Threatening¹	Unexpected	Related	1 (Most Conservative)
SUSAR	Serious	Unexpected	Related	2
SU	Serious	Unexpected	Unrelated	3
SESAR	Serious	Expected	Related	4
SE	Serious	Expected	Unrelated	5
NSUR	Non-Serious	Unexpected	Related	6
NSU	Non-Serious	Unexpected	Unrelated	7
NSER	Non-Serious	Expected	Related	8
NSE	Non-Serious	Expected	Unrelated	9 (Least Conservative)
1. If a case contains both a Life Threatening SUSAR and a Fatal SUSAR, the tiebreaker for Most Conservative Assessment will be the Fatal SUSAR.

Vault considers the most conservative Case Assessment for a region using the following data:

Seriousness: The Seriousness of the Case Adverse Event associated with the Case Assessment.
Expectedness: The Expectedness associated with the Case Assessment. Case Assessment Expectedness are automatically calculated using Datasheets.
Vault uses logic to evaluate the appropriate Expectedness records for this parameter, as described below:

Vault first looks for Expectedness records under the relevant Case Assessment, then executes the following logic depending on whether the Case is part of a Study:
- Non-Study Cases:
  1. Vault first evaluates all Local Datasheets for countries in the jurisdiction of the agency using the following logic:
    - Expected: If all local Expectedness records are Expected.
    - Unexpected: When one (1) or more local Expectedness records is Unexpected or blank.
  2. If there are no Local Datasheets within the reporting jurisdiction, the Expected value corresponding to the Product's Core Datasheet is used.
  3. If there are no Expectedness records, Vault uses the value from the Expected field on the relevant Case Assessment.
- Study Cases:
  1. Vault first evaluates all Study Product Datasheets for Study Products in the Case using the following logic:
    - Expected: If all Study Product Expectedness records are Expected.
    - Unexpected: When one or more Study Product Expectedness records are Unexpected or blank.
    If there are no Study Product Datasheets, Vault performs the evaluation based on the Study Core Datasheet to set the Expected value.
  2. For Clinical Trial Study Cases only, expectedness evaluation considers Case Adverse Event Onset date by default. For a Case Adverse Event to be considered expected, the Onset date must fall within the active date range for the MedDRA Term on the Datasheet. Dates outside this range are considered unexpected. If there is no Active End Date, the term is considered to be expected to the present day. If there is no Active Start Date or Active End Date, the term is always considered expected. If the Onset date is not available, Vault uses the Receipt Date on the Case for the evaluation.
    
    If your Admin has enabled Agency-Based Auto-Expectedness for Clinical Trial Study Cases, Vault performs expectedness evaluations considering the New Info Date on the Case for Agencies with that configuration. In that scenario, if New Info Date is not available, Vault performs evaluations using the Onset date.
  3. For Postmarket Study Cases only, if there is no Study Datasheet, Vault then looks at all Local Datasheets for countries in the jurisdiction of the agency using the following logic:
    - Expected: If all local Expectedness records are Expected.
    - Unexpected: When one or more local Expectedness records are Unexpected or blank.
    This step does not occur for Clinical Trial Study Cases.
  4. Otherwise, the Expected value corresponding to the Product's Core Datasheet is used.
  5. If there are no Expectedness records, Vault uses the value from the Expected field on the relevant Case Assessment.
Relatedness: The Causality Established field on Assessment Results under the Case Assessment. A product and event are considered Related when one or more Case Assessment Results have the Causality Established field set to Yes or Blank.

Note: For rules that use the Assessment Source parameter, such as FDA SUSAR reporting rules, to evaluate relatedness, Vault only considers Case Assessment Results with a matching Source Type to find the most conservative Case Assessment.

Note: Assessments for device constituents cannot be considered the most conservative assessment.