# Reporting Rule Parameter Reference 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: Sample FDA 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.

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

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.
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 or Any Event Country The Primary Reporter or any Adverse Event has a Country that matches the jurisdiction Country.
Primary Reporter Country or 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
  1. If the Primary Reporter has a specified Country, Vault considers the Case to be in jurisdiction if the Country of the Primary Reporter matches the jurisdiction Country.
  2. If the Primary Reporter does not have a specified Country, Vault uses the Primary Event Country evaluation method.
Exclude Input

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

This parameter accepts "Placebo" as an acceptable value.
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 assigns Case and Case Assessment tags. See How Vault Assigns Case SUSAR and SAE Tags 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 Vault populates the Downgraded field on the Transmission.

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 Rp-Rc, where Rp and Rc 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 (Rp-Rc) MCA Ranking
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.

Transmission Reason Input and Output

Vault evaluates this parameter 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.

When evaluating 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 destination1 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 the 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 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".
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."
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.
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 Rp-Rc, where Rp and Rc 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 (Rp-Rc) MCA Ranking
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.

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.

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.

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 include general reporting too.

This parameter accepts the following options:

  • Investigational to Marketing (same agency)
  • Investigational to Marketing (cross agency)
  • Investigational to Investigational (same agency)
  • Investigational to Investigational (cross agency)
  • Marketing to Marketing (cross agency)
  • Marketing to Investigational (cross agency)
  • General Reporting1
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.

Cross Reporting:

If your Admin has enabled the Substitute Product/Study for Cross Reporting application setting, then for X→M cross reporting scenarios, Vault evaluates this parameter as True when the substituted Product's Registration is evaluated for cross reporting. If the setting is not enabled, Vault evaluates this parameter 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.

Cross Reporting:

If your Admin has enabled the Substitute Product/Study for Cross Reporting application setting, then for X→M cross reporting scenarios, Vault evaluates the substituted Product's Product Family against this parameter. If the setting 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 your Admin has enabled the Substitute Product/Study for Cross Reporting application setting, then for X→I cross reporting scenarios, Vault evaluates this parameter as True when the provided Clinical Trial Study's Registration is evaluated for cross reporting. If the setting is not enabled, Vault evaluates this parameter 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.

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, Vault 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 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 For Submissions, this evaluates if the Case requires Personally Identifiable Information (PII) masking. When this parameter passes, Vault populates the Patient Content Protection field of Submissions based on the Value of the Rule Parameter as follows:
  • For All, Vault populates Mask PII.
  • For Foreign, if the AE in Jurisdiction parameter does not pass, Vault populates Mask PII.
  • For All (EU Guidance), Vault populates Mask PII (EU Guidance).
  • For Foreign (EU Guidance), if the AE in Jurisdiction parameter does not pass, Vault populates Mask PII (EU Guidance).
Exceptions to PII Masking Output

For Submissions, this evaluates if a Case requires exceptions to PII masking. 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.
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 a Case contains an unknown formulation Product, Vault evaluates all Product Registrations within the related Product Family.

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.

When evaluating a Distribution, Vault 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 a Vault-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 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, Vault evaluates this parameter using that record's Study Product Role Override value instead of the Study Product Role value on the Case record.

Use this parameter with the Auxiliary Medicinal Product Status parameter to configure the Rule Engine to consider AxMPs as eligible for reporting.

Auxiliary Medicinal Product Status Input

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

If a Study Product Country record for a Study Product exists, the value specified for AxMP Status Override overrides this parameter.

Use this parameter with the Study Product Role parameter to configure the Rule Engine to consider AxMPs as eligible for reporting.

Safety Data Expression Building Blocks Input

With this parameter, you can configure custom reporting rule parameters to evaluate Case data using Rule Engine expressions contained in one or more Safety Data Expression Building Blocks.

This parameter accepts a comma-separated list of the API Names of one or more Safety Data Expression Building Blocks.

If Vault evaluates each referenced building block as True, the rule passes. If Vault evaluates any referenced building block as False, the rule fails.

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.

Early Notification Output

This parameter accepts a value of Yes.

If set to Yes, Vault evaluates the rule when running the Evaluate Early Notification Obligations action on a Case.

For more information about sending Early Notifications for a Case, see ICSR Transmissions Overview.

Approval Due in Days Output

Enter a positive, whole number.

When the Rules Engine creates a non-OLT Transmission, Vault sets Approval Due in Days on the Transmission to the value specified in this parameter. If no Approval Due in Days parameter exists in the rule that triggered Transmission creation, Vault leaves Approval Due in Days on the Transmission blank. For a Vault-created OLT Transmission, Vault sets Approval Due in Days to the same value as the previous Transmission.

Vault also sets the Approval Due Date on the Case.

Individual Device Transmission Output

This parameter accepts a value of Yes.

Include this parameter in Safety Rules intended for the evaluation of individual device transmissions.

If included in a Safety Rule, Vault evaluates every device constituent of a Combination Product and every standalone device Case Product against the other Safety Rule Parameters in the rule.

A passing rule with Individual Device Transmission set to Yes links the passing Case Product to the generated outbound transmission.

To use this parameter, your Admin must configure your Vault to generate Case Assessments for device constituents.
### Write Custom Case Data Reporting Rule Parameters {#custom-case-data-reporting-rule-parameters} When writing the expression for a _[Case Data - Expression][1]_ 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 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
Eligible Case Assessment records1 eligible_case_assessments__v
Localized Case record case_version__v
localized_case_version__v
Eligible Case Assessment records1 eligible_case_assessments__v
eligible_localized_case_assessments__v
1. 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 Reporting 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 of the operators and functions in the Vault Formula Reference Guide and the Safety-specific functions described in Create Formula Expressions.
#### 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 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.
VS_LET(cv, case_version__v, NOT(VS_ANYOF(cv.transmissions_case_version__vr, LAMBDA(t, t.object_type__vr.api_name__v = 'inbound_transmission__v' && t.origin__vr.api_name__v = 'ema__v')))) This example illustrates how to reference an Inbound Transmission in an expression. The expression returns false if the Inbound Transmission on the Case originated from the EMA.
#### 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:
#### 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 Threatening1
 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:
### Specify AxMPs as Reportable Products By default, the Rule Engine does not evaluate AxMPs as eligible for general reporting, cross reporting, or _Distributions_. To configure the Rule Engine to consider AxMPs as eligible products, use the _Study Product Role_ and _Auxiliary Medicinal Product Status_ reporting rule parameters as follows:
AxMPs Considered Eligible Reporting Rule Parameter Configuration
Authorized and Unauthorized AxMPs
  • Study Product Role: Auxiliary
Authorized AxMPs
  • Study Product Role: Auxiliary
  • Auxiliary Medicinal Product Status: Authorized
Unauthorized AxMPs
  • Study Product Role: Auxiliary
  • Auxiliary Medicinal Product Status: Not Authorized
---- [0]: #custom-case-data-reporting-rule-parameters [1]: #case-data-expression