Reporting Rule Parameter Reference

The Case's Report Type (report_type__v) classification.

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

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. The system evaluates this parameter for Study Types with the same E2B code.

Whether the case meets seriousness criteria.

The system evaluates this parameter using the method specified on the rule set:

• Primary (default): Whether a value is populated in the Case Seriousness (seriousness__v) field.
• Most Conservative: Whether a value is populated in the Seriousness (seriousness__v) field on the Case Adverse Event associated with the most conservative Case Product and Assessment.

Whether the case meets life-threatening seriousness criteria.

The system evaluates this parameter using the method specified on the rule set:

• Primary (default): Whether "Life threatening" is populated in the Case Seriousness (seriousness__v) field.
• Most Conservative: Whether "Life threatening" is populated in the Seriousness (seriousness__v) field on the Case Adverse Event associated with the most conservative Case Product and Assessment.

Whether the case meets fatal seriousness criteria.

The system evaluates this parameter using the method specified on the rule set:

• Primary (default): Whether "Results in death" is populated in the Case Seriousness (seriousness__v) field.
• Most Conservative: Whether "Results in death" is populated in the Seriousness (seriousness__v) field on the Case Adverse Event associated with the most conservative Case Product and Assessment.

When evaluating reporting obligations for Global Cases, the system locates the relevant Case Assessment Expectedness records based on the evaluation method specified on the rule set:

• Primary (default): The system evaluates the Expectedness records under the primary Case Assessment.
• Most Conservative: The system evaluates the Expectedness records under the most conservative Case Assessment.

The system uses logic to evaluate the appropriate Expectedness records for this parameter.

Expectedness Evaluation Logic

The system 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. The system 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 or more local Expectedness records are 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, the system uses the value from the Expected field on the relevant Case Assessment.
• Study Cases:
  1. The system 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, the system performs the evaluation based on the Study Core Datasheet to set the Expected value.
  2. For Clinical Trial Study Cases only, Expectedness evaluation considers Adverse Event Onset Date, which must fall within the Datasheet term's Active Start and End Dates to be considered Expected. 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 or End Date, the term is always considered Expected.
     If the Adverse Event Onset Date is not available, the system uses the Case Receipt Date for the evaluation.
  3. For Postmarket Study Cases only, if there is no Study Datasheet, the system 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, the system uses the value from the Expected field on the relevant Case Assessment.

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

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, the system also evaluates with this setting.
• If set to "Yes", the parameter is evaluated as "Yes" when the Drug Role is either Suspect or Interacting.

Evaluates whether the adverse event occurred in the agency's jurisdiction.

The system evaluates this parameter using the method specified on the rule set:

• Primary (default): Whether the Agency is assigned jurisdiction over the Event Country (event_country__v) selected on the primary Case Adverse Event.
• Most Conservative: 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.

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

This parameter accepts "Placebo" as an acceptable value.

Evaluates whether the Case meets SUSAR or SAE criteria.

The system evaluates this parameter using the method specified on the rule set:

• Primary (default): The value from the Case Tags (case_tags__v) field on the Case.
• Most Conservative: The value from the Assessment Tag (assessment_tag__v) field on the most conservative Case Assessment.

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.

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

The system evaluates this parameter using the method specified on the rule set:

• Primary (default): The system evaluates the primary Case Assessment.
• Most Conservative: The system evaluates the most conservative Case Assessment. The system only considers Case Assessment Results with a matching Source Type to find the most conservative Case Assessment.

The system evaluates this parameter using the Controlled Vocabulary E2B Code corresponding to the Source Type (source_type__v) on a Case Assessment.

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.

Evaluates whether the current Case's seriousness, expectedness, and relatedness are downgraded from the previous Case version.

The current Case's Most Conservative Product/Assessment (MCP/MCA) is compared against the previous Case version based on the following Seriousness/Expectedness/Relatedness priority list:

1. Fatal/Life Threatening/ Serious Unexpected Related (Fatal/LT SUSAR)
2. Serious Unexpected Related (SUSAR)
3. Serious Unexpected Unrelated (SU)
4. Serious Expected Related (SESAR)
5. Serious Expected Unrelated (SE)
6. Non-Serious Unexpected Related (NSUR)
7. Non-Serious Unexpected Unrelated (NSU)
8. Non-Serious Expected Related (NSER)
9. Non-Serious Expected Unrelated (NSE)

The following section shows the Most Conservative Product/Assessment (MCP/MCA) criteria that Vault Safety uses for this parameter.

Most Conservative Product/Assessment (MCP/MCA)

Most Conservative Product Criteria

The system 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, the system queries all Case Products with Case Assessments to identify the most conservative product and assessment.
• For cross reporting, the system considers only Case Products that are being cross reported to, rather than all Case Products.

Most Conservative Assessment Criteria

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

The system 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.

  The system uses logic to evaluate the appropriate Expectedness records for this parameter, as described below:

  The system 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. The system 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 or more local Expectedness records are 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, the system uses the value from the Expected field on the relevant Case Assessment.
  • Study Cases:
    1. The system 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, the system performs the evaluation based on the Study Core Datasheet to set the Expected value.
    2. For Clinical Trial Study Cases only, Expectedness evaluation considers Adverse Event Onset Date, which must fall within the Datasheet term's Active Start and End Dates to be considered Expected. 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 or End Date, the term is always considered Expected.
       If the Adverse Event Onset Date is not available, the system uses the Case Receipt Date for the evaluation.
    3. For Postmarket Study Cases only, if there is no Study Datasheet, the system 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, the system 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, the system only considers Case Assessment Results with a matching Source Type to find the most conservative Case Assessment.

The system determines whether the current Case's seriousness, expectedness, and relatedness are downgraded from the previous Case version depending on the Downgrade parameter value, as shown in the table below.

This parameter also controls whether the Downgraded flag on the Transmission is turned on.

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

• Evaluates as Follow-up if either of the following conditions are met:
  • If a previous Case version has a Transmission to the same reporting destination in either of the following states:
    • Completed
    • E2B ACK Accepted
  • If a previous Case version is of the Imported Case object type and the Imported Case does not have Transmission to same reporting destination
• In all other scenarios, evaluates as Initial

The Registration Type (registration_type_cv__v) classification on the Case Product Registration section of the Localized Case Assessment.

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

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

This parameter is used in PMDA reporting rules only.

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.

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.

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.

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.

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

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

The system evaluates this parameter using the method specified on the rule set:

• Primary (default): Evaluates Case Assessment Results under the primary Case Assessment.
• Most Conservative: Evaluates Case Assessment Results under the most conservative Case Assessment.

This parameter is evaluated as "Related" when the relevant Case Assessment contains at least one Case Assessment Result with the Causality Established (causality_established__v) field set to "Yes" or blank.

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

• Yes:
  • The system evaluates all previous Case versions with a Transmission in the "E2B ACK Accepted" or "Completed" state for the same reporting Destination and Transmission Profile.
  • The system then checks that the Downgrade reporting rule parameter was not evaluated as "Yes".
  • Finally, the system checks that the most recent Transmission that meets the first two conditions has Submit one last time set to "No".
• All Transmission States:
  • The system 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.
  • The system checks that the most recent Transmission that meets the above conditions has Submit one last time set to "No."

Evaluates whether the current Case's seriousness, expectedness, and relatedness are upgraded from the previous Case version.

The current Case's Most Conservative Product/Assessment (MCP/MCA) is compared against the previous Case version based on the following Seriousness/Expectedness/Relatedness priority list:

1. Fatal/Life Threatening/ Serious Unexpected Related (Fatal/LT SUSAR)
2. Serious Unexpected Related (SUSAR)
3. Serious Unexpected Unrelated (SU)
4. Serious Expected Related (SESAR)
5. Serious Expected Unrelated (SE)
6. Non-Serious Unexpected Related (NSUR)
7. Non-Serious Unexpected Unrelated (NSU)
8. Non-Serious Expected Related (NSER)
9. Non-Serious Expected Unrelated (NSE)

View the following section to see the Most Conservative Product/Assessment (MCP/MCA) criteria that Vault Safety uses for this parameter.

Most Conservative Product/Assessment (MCP/MCA)

Most Conservative Product Criteria

The system 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, the system queries all Case Products with Case Assessments to identify the most conservative product and assessment.
• For cross reporting, the system considers only Case Products that are being cross reported to, rather than all Case Products.

Most Conservative Assessment Criteria

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

The system 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.

  The system uses logic to evaluate the appropriate Expectedness records for this parameter, as described below:

  The system 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. The system 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 or more local Expectedness records are 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, the system uses the value from the Expected field on the relevant Case Assessment.
  • Study Cases:
    1. The system 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, the system performs the evaluation based on the Study Core Datasheet to set the Expected value.
    2. For Clinical Trial Study Cases only, Expectedness evaluation considers Adverse Event Onset Date, which must fall within the Datasheet term's Active Start and End Dates to be considered Expected. 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 or End Date, the term is always considered Expected.
       If the Adverse Event Onset Date is not available, the system uses the Case Receipt Date for the evaluation.
    3. For Postmarket Study Cases only, if there is no Study Datasheet, the system 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, the system 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, the system only considers Case Assessment Results with a matching Source Type to find the most conservative Case Assessment.

The system 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.

Evaluates if all Case Adverse Events match with terms defined within a MedDRA Query (SMQ/CMQ). If all Case Adverse Events match, a Transmission is not generated.

Any value entered for this parameter must correspond to an active meddra_query__v.

Evaluates whether at least one Case Adverse Event matches a term defined within a MedDRA Query (SMQ/CMQ). If there is a match, a Transmission is generated.

Any value entered for this parameter must correspond to an active meddra_query__v.

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

If this parameter is left blank, the system 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.

Evaluates whether a Case contains a specific Product.

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 Substitute Product/Study for Cross Reporting¹ is enabled, then for X→M cross reporting scenarios, this parameter evaluates as "True" when the provided 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.

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.

Evaluates whether the Case has an identifiable patient.

The following list describes how the system 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, gender, or MRN. The following table shows the list of fields the system 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
  Gender (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.

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", the system 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.

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, the system 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.

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.

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.

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

The following list describes how the system 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.

Evaluates whether the Case requires exceptions to PII masking for Submissions. This parameter is only evaluated 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

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

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.

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.

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

• If the Distribution is based on a Product, the system uses the Transmission Product Type from within the Product Reporting Family Member.
• If the Distribution is based on a Product Registration, the system 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.