**Source URL:** https://safety.veevavault.help/en/gr/1118845/ # Create Workbench PMDA Postmarket Aggregate Reports Safety Workbench provides Pharmaceuticals and Medical Devices Agency (PMDA) Postmarket report authoring and table generation capabilities. The Vault Safety PMDA Postmarket report adheres to the PMDA Guide to Electronic Reporting of Adverse Drug Reactions and Infectious Diseases. The following table summarizes the Workbench PMDA Postmarket tabulations that Safety Workbench generates: |Tabulation|Masking Support?| |--- |--- | |[_J-NUPR Line Listing Form 7-2_][26]|No| |[_J-PSR Cumulative Tabulation of Adverse Events Form 3_][27]|No| |[_J-PSR Line Listing of Adverse Events Form 4_][28]|No| |[_Case Series Report_][19]|No| |[_Open Cases Report_][20]|No| ## Prerequisites To generate Workbench PMDA aggregate reports: * Your Admin must configure the [PMDA Postmarket Workbench Report Set][1] * Your Admin must grant you permissions to view and prepare aggregate reports * Depending on your business process, your Admin may: * Configure a _Datasheet_ for each _Study Product_, _Study_, or _Product_ with a list of expected adverse events in order to classify adverse events as _Listed_ or _Unlisted_ in Workbench PMDA reports * Configure custom Workbench PMDA Postmarket Workbench Report Set templates for your organization ## Overview To generate a Workbench PMDA aggregate report: 1. [Create a _Workbench Report Set_][1] to combine the desired PMDA _Workbench Report Definitions_ into a single record. 2. [Specify the required PMDA filters][3] on the _Workbench Report Set_. 3. [Generate then run the PMDA _Workbench Reports_][4] from the _Workbench Report Set_. To learn how Vault maps data to each Workbench PMDA report, see [PMDA Table Generation Data Mapping][5]. ## Create a PMDA Postmarket Workbench Report Set {#create-workbench-report-set} To create a PMDA _Workbench Report Set_: 1. Navigate to **Workbench > Report Sets**. 2. Select **Create**. 3. On the _Create Workbench Report Set_ page, enter a name for the report. 4. Select **Save** or **Save + Create** to save the _Workbench Report Set_ and create another. 5. In the _Reports to Generate_ section, add a _Workbench Report Definition_ to the _Workbench Report Set_ for each PMDA report you want to include. **Note**: When your Admin configures Workbench PMDA Aggregate Reports, they create a Workbench Report Definition for each unmasked report. If your Workbench Report Set does not contain the expected PMDA reports, contact your Admin for assistance. **Result** Vault sets the lifecycle state of the _Workbench Report Set_ to _Draft_. ### PMDA Postmarket Filter Section Fields {#filter-section-fields} You can specify the following fields for a PMDA Postmarket Workbench Report Set:
Field Description
Date Filter You can run reports with individual date filters, as well as in a report set. Select the date filter(s) from the following: J-PSR Previous Interval 1 (earliest) J-PSR Previous Interval 2 J-PSR Previous Interval 3 J-PSR Previous Interval 4 J-PSR Previous Interval 5 J-PSR Previous Interval 6 J-PSR Previous Interval 7 J-PSR Previous Interval 8 J-PSR Previous Interval 9 J-NUPR / J-PSR Current Interval
Case Completed Select whether the Case is open or completed from the drop-down menu to filter the report. Consider the following: The Completed option includes Cases in the following states: Approved (approved_state__v) Closed (closed_state__v) Superseded (superseded_state__v) The Open option includes any Case in a state not defined as completed, including any custom lifecycle states. If you leave this field blank, the report filters for all Cases regardless of their state.
Aggregate Reporting Group Select an Aggregate Reporting Group from the drop-down, or use the Advanced Search (Binoculars Icon) icon to use filters and refine your search. Vault considers the following Cases eligible for inclusion in the generated reports: Cases with a Product in the Aggregate Reporting Group Cases with a Product Registration in the Aggregate Reporting Group ## Generate Workbench PMDA Postmarket Tabulations {#generate-run-workbench-tabulations} Review and verify the report settings. Once you have confirmed the report details are correct, use the Generate Aggregate Report Tabulations action to generate PMDA Postmarket report tables. ## PMDA Postmarket Table Generation Data Mapping {#table-generation-data-mapping} Safety Workbench populates aggregate report tables using Cases within the reporting period specified on the PMDA Postmarket report, and the aggregate reporting group configured on the associated Aggregate Reporting Group. The following sections describe how Safety Workbench generates PMDA Postmarket tabulations: * [J-NUPR Line Listing Form 7-2][26] * [J-PSR Cumulative Tabulation of Adverse Events Form 3][27] * [J-PSR Line Listing of Adverse Events Form 4][28] ### J-NUPR Line Listing Form 7-2 {#nupr-form-7-2} Vault generates the J-NUPR Line Listing Form 7-2 by default for PMDA Postmarket aggregate reports. #### Table Constraints Vault filters Cases to include in the J-NUPR Line Listing Form 7-2 using the following constraints: ##### Case Not Suppressed The Case Suppress Submission field must be set to No or blank (not suppressed). `case_version__v.suppress_submission__v ≠ Yes` ##### Case Product or Product Registration in Aggregate Reporting Group A _Case_ must have a _Product_ or _Product Registration_ that is a member of the _Aggregate Reporting Group_. * `case_version__vr.case_product__v IN aggregate_reporting_group__vr.aggregate_reporting_group_join__vr.product__v` * `case_version__vr.case_product__v.product_registration__v.registration_number__v IN aggregate_reporting_group__vr.aggregate_reporting_group_join__vr.product_registration__v` ##### Case Data in Interval Reporting Period The date of a _Case_ must be within the _J-NUPR / J-PSR Current Interval Range_. `DATE ≥ nupr_jpsr_current_report_interval__v.data_period_start__v` **AND** `DATE ≤ nupr_jpsr_current_report_interval__v.data_period_end__v` **WHERE** `DATE` selected is the _Local Awareness Date_. If there are multiple versions of the _Case_ within the reporting period, only the most recent _Case_ version within the reporting period is listed. ##### Case Lifecycle State The latest _Case_ version within the reporting period must be in a state specified in the _Case Completed_ filter. `case_version__v.state__v CONTAINS pmda_post_market__v.states_to_include__v` Consider the following: * _Cases_ in the following states are always omitted and cannot be selected in the _States to Include_ field: * Nullified (`nullified_state__v`) * Voided (`voided_state__v`) * The **Completed** option includes *Cases* in the following states: * Approved (`approved_state__v`) * Closed (`closed_state__v`) * Superseded (`superseded_state__v`) * The **Open** option includes any _Case_ in a state not defined as completed, including any custom lifecycle states. * If you leave this field blank, the report filters for all _Cases_ regardless of their state. ##### Localized Case A Case must have a Japan localized version to be included. `case_version__v.reporter_country__v = Japan` ##### Case Product in Drug Roles to Include Only include Case Products in the listing where **Drug Role** is "Suspect" or "Interacting". ##### Postmarket Cases Only include Cases that are considered postmarket. The `case_product_registration__v.registration_type_cv__v` E2B code is one of the following: (1, 2, 5, 6, 7) ##### Special Report Classification Exclude Cases with a **Special Report Classification** of "Research Report" or "Safety Measure". `case_version__v.special_report_classification__v IN (safety_measure_report__v, research_report__v)` ##### Unexpected Adverse Events Include only events that meet all of the following criteria: * The event is non-serious (`localized_case_adverse_event__v.seriousness__v = Blank`) * The event is Unexpected (`localized_case_assessment__v.expected__v != yes`) * The event is related to the product in the report (**Causality Established** is set to Yes or Blank for at least one Assessment Result) * The event is reportable (`localized_case_adverse_event__v. special_adverse_event__v != "Non-reportable Event"`) #### Table Mapping **Sorting**: Rows are in order of Event (PT) alphabetically, then by Adverse Event Onset Date (earliest first). Events with a blank Onset Date are listed last.
Number Name Description
1 Case # (番号) The Case Number case_version__v.case_number__v
2 Event (PT) (基本語) The Localized MedDRA Preferred Term Event in Japanese (from the local MedDRA version)
3 MedDRA Code (MedDRAコード) The MedDRA Preferred Term Code
4 Gender (性別) The sex on the Case If the field is blank, "不明" (Unknown in Japanese) is displayed.
5 Age (年齢) The normalized Age (in years) on the Case If age is not populated on the case, the report will display Age Group. If Age Group is not populated, it will display "不明" (Unknown in Japanese).
6 Onset Date (副作用等発現 年月日) The Onset Date of the Case Adverse Event, as entered in the Date of Onset field on the Case Adverse Event in the format "YYYY年MM月DD日" If the field is blank, "不明" (Unknown in Japanese) is displayed.
7 Outcome (転帰) The Outcome of the Case Adverse Event The value selected in the Case Adverse Event Outcome field.
8 Report Type (報告の 種類) The Case Report Type The value selected in the Case Report Type field.
9 Remarks (備考) Up to three items are displayed in this column: The Product Name (case_product__v.product_registration__v.trade_name__v) or Product Registration (case_product_registration__v. product_registration__v) The Destination Case ID, if it exists, for the Product Registration (transmission__v.destination_case_id__v for the product_registration__v) ### J-PSR Cumulative Tabulation of Adverse Events Form 3 {#j-psr-form-3} The following image map shows how Vault generates the J-PSR Cumulative Tabulation of Adverse Events Form 3 table. #### Table Constraints Vault filters Cases to include in the J-PSR Cumulative Tabulation of Adverse Events Form 3 using the following constraints: ##### Case Not Suppressed The Case Suppress Submission field must be set to No or blank (not suppressed). `case_version__v.suppress_submission__v ≠ Yes` ##### Case Product or Product Registration in Aggregate Reporting Group A _Case_ must have a _Product_ or _Product Registration_ that is a member of the _Aggregate Reporting Group_. * `case_version__vr.case_product__v IN aggregate_reporting_group__vr.aggregate_reporting_group_join__vr.product__v` * `case_version__vr.case_product__v.product_registration__v.registration_number__v IN aggregate_reporting_group__vr.aggregate_reporting_group_join__vr.product_registration__v` ##### Case Data in Interval Reporting Period The _Case_ date must fall within the defined aggregate report interval reporting periods. earliest(aggregate_report_intervals__v) ≤ DATE ≤ aggregate_report_intervals__v.latest(interval_end_date__v) Where DATE Local Awareness Date: Data Period Start Date ≤ localized_case__v.local_awareness_date__v ≤ Data Period End Date ##### Configuring Report Intervals When defining reporting periods, Vault evaluates the interval records based on the following rules: **Required Current Interval:** You must enter at least one interval in the _J-NUPR / J-PSR Current Interval Range_ field. Vault always treats this entry as the latest (most recent) interval. **Optional Historical Intervals:** If the report requires a broader data window, you can configure up to nine additional historical intervals using the _Previous J-PSR Interval 1_ through _Previous J-PSR Interval 9_ fields. **Sequential Entry:** Interval dates must be entered sequentially based on the total number of periods being reported. **Example:** If you are running a report across three total intervals, you must populate dates in _Previous J-PSR Interval 1_, _Previous J-PSR Interval 2_, and the _J-NUPR / J-PSR Current Interval Range_. If there are multiple versions of the _Case_ among all the reporting intervals, Vault lists only the most recent _Case_ version. ##### Case Lifecycle State The latest _Case_ version within the reporting period must be in a state specified in the _Case Completed_ filter. `case_version__v.state__v CONTAINS pmda_post_market__v.states_to_include__v` Consider the following: * _Cases_ in the following states are always omitted and cannot be selected in the _States to Include_ field: * Nullified (`nullified_state__v`) * Voided (`voided_state__v`) * The **Completed** option includes *Cases* in the following states: * Approved (`approved_state__v`) * Closed (`closed_state__v`) * Superseded (`superseded_state__v`) * The **Open** option includes any _Case_ in a state not defined as completed, including any custom lifecycle states. * If you leave this field blank, the report filters for all _Cases_ regardless of their state. ##### Localized Case A Case must have a Japan localized version to be included. `case_version__v.reporter_country__v = Japan` ##### Case Product in Drug Roles to Include Only include Case Products in the listing where **Drug Role** is "Suspect" or "Interacting". ##### Postmarket Cases Only include Cases that are considered postmarket. The `case_product_registration__v.registration_type_cv__v` E2B code is one of the following: (1, 2, 5, 6, 7) ##### Special Report Classification Exclude Cases with a **Special Report Classification** of "Research Report" or "Safety Measure". `case_version__v.special_report_classification__v IN (safety_measure_report__v, research_report__v)` ##### Blind Setting For Study Cases, only unblinded data is included in the report. If your Admin has configured your Vault to isolate blinded clinical trial information, the Blinding Type on the Japan Case Product Registration must be set to Unblinded, Open, or blank. `case_product_registration__v.blinding_type__v != Blinded` ##### Serious, Related Adverse Events All _Adverse Events_ that are Serious and Related are included. In addition, events that meet all of the following criteria are included: * The _Localized Case Adverse Event_ is Serious (localized_case_adverse_event__v.seriousness__v = !Blank) * The event is related to the _Product_ in the report (_Causality Established_ is set to Yes or Blank for at least one _Assessment Result_) * The event is reportable (localized_case_adverse_event__v.special_adverse_event__v != "Non-reportable Event") A _Case_ must have a _Product_ or _Product Registration_ that is a member of the _Aggregate Reporting Group_: * case_version__vr.case_product__v IN aggregate_reporting_group__vr.aggregate_reporting_group_join__vr.product__v * case_version__vr.case_product__v.product_registration__v.registration_number__v IN aggregate_reporting_group__vr.aggregate_reporting_group_join__vr.product_registration__v Vault excludes _Adverse Events_ with no _Assessment_ or _Assessment Result_ records. ##### Reporting Interval Assignments Vault includes _Cases_ within a reporting interval when the applicable _Case_ date (_Local Awareness Date_) is on or between the _Interval Start Date_ and _Interval End Date_ on the _Interval Dates_ filter. For example, the PMDA allows three different methods for handling cases with multiple versions. The following example is the method where only the latest version is reported: * **Interval 1:** January 1 – March 31 * **Interval 2:** April 1 – June 30 If a _Case_ has two versions with different _Local Awareness Dates_: * Version 1 falls into Interval 1 * Version 2 falls into Interval 2 **Result:** Only Version 2 will be included, and it will only appear in Interval 2. Version 1 is excluded so the case is not counted twice. _Cases_ that do not fall into any reporting intervals will be dropped. #### Table Mapping **Sorting**: Rows are in order of Event (SOC) alphabetically, then Event (PT) alphabetically. Each reporting interval appears in a separate column.
Number Name Description
1 Event (SOC) (器官別大分類) The Localized MedDRA System Organ Class (SOC) affected by the Adverse Event in Japanese (from the local MedDRA version)
2 Event (PT) (基本語) The Localized MedDRA Preferred Term Event in Japanese (from the local MedDRA version)
3 The Number of Adverse Events Reported (副作用・感染症の症例報告を行った症例数) The number of reported Adverse Events for that reporting interval. A report can include mulitple reporting intervals. The reporting interval dates are included in the column headers of the report.
4 Unknown (不明 ) The number of reported Cases that do not fall within the dates of any reporting interval on the report. This column appears only when the report interval dates have been set up incorrectly.
5 Total During Reexamination Period (再審査期間中の合計) The total number of Cases for the reexamination period for each row on the report.
6 Remarks (備考) Up to two items are displayed in this column: The Product Name (case_product__v.product_registration__v.trade_name__v) or Product Registration (case_product_registration__v. product_registration__v) The Destination ID, if it exists (transmission__v.destination_case_id__v) ### J-PSR Line Listing of Adverse Events Form 4 {#j-psr-form-4} The following image map shows how Vault generates the J-PSR Line Listing of Adverse Events Form 4 table. #### Table Constraints Vault filters Cases to include in the J-PSR Cumulative Tabulation of Adverse Events Form 4 using the following constraints: ##### Case Not Suppressed The Case Suppress Submission field must be set to No or blank (not suppressed). `case_version__v.suppress_submission__v ≠ Yes` ##### Case Product or Product Registration in Aggregate Reporting Group A _Case_ must have a _Product_ or _Product Registration_ that is a member of the _Aggregate Reporting Group_. * `case_version__vr.case_product__v IN aggregate_reporting_group__vr.aggregate_reporting_group_join__vr.product__v` * `case_version__vr.case_product__v.product_registration__v.registration_number__v IN aggregate_reporting_group__vr.aggregate_reporting_group_join__vr.product_registration__v` ##### Case Data in Interval Reporting Period The _Case_ date must fall within the defined aggregate report interval reporting periods. earliest(aggregate_report_intervals__v) ≤ DATE ≤ aggregate_report_intervals__v.latest(interval_end_date__v) Where DATE Local Awareness Date: Data Period Start Date ≤ localized_case__v.local_awareness_date__v ≤ Data Period End Date ##### Configuring Report Intervals When defining reporting periods, Vault evaluates the interval records based on the following rules: **Required Current Interval:** You must enter at least one interval in the _J-NUPR / J-PSR Current Interval Range_ field. Vault always treats this entry as the latest (most recent) interval. **Optional Historical Intervals:** If the report requires a broader data window, you can configure up to nine additional historical intervals using the _Previous J-PSR Interval 1_ through _Previous J-PSR Interval 9_ fields. **Sequential Entry:** Interval dates must be entered sequentially based on the total number of periods being reported. **Example:** If you are running a report across three total intervals, you must populate dates in _Previous J-PSR Interval 1_, _Previous J-PSR Interval 2_, and the _J-NUPR / J-PSR Current Interval Range_. If there are multiple versions of the _Case_ among all the reporting intervals, Vault lists only the most recent _Case_ version. ##### Case Lifecycle State The latest _Case_ version within the reporting period must be in a state specified in the _Case Completed_ filter. `case_version__v.state__v CONTAINS pmda_post_market__v.states_to_include__v` Consider the following: * _Cases_ in the following states are always omitted and cannot be selected in the _States to Include_ field: * Nullified (`nullified_state__v`) * Voided (`voided_state__v`) * The **Completed** option includes *Cases* in the following states: * Approved (`approved_state__v`) * Closed (`closed_state__v`) * Superseded (`superseded_state__v`) * The **Open** option includes any _Case_ in a state not defined as completed, including any custom lifecycle states. * If you leave this field blank, the report filters for all _Cases_ regardless of their state. ##### Localized Case A Case must have a Japan localized version to be included. `case_version__v.reporter_country__v = Japan` ##### Case Product in Drug Roles to Include Only include Case Products in the listing where **Drug Role** is "Suspect" or "Interacting". ##### Postmarket Cases Only include Cases that are considered postmarket. The `case_product_registration__v.registration_type_cv__v` E2B code is one of the following: (1, 2, 5, 6, 7) ##### Special Report Classification Exclude Cases with a **Special Report Classification** of "Research Report" or "Safety Measure". `case_version__v.special_report_classification__v IN (safety_measure_report__v, research_report__v)` ##### Blind Setting For Study Cases, only unblinded data is included in the report. If your Admin has configured your Vault to isolate blinded clinical trial information, the Blinding Type on the Japan Case Product Registration must be set to Unblinded, Open, or blank. `case_product_registration__v.blinding_type__v != Blinded` ##### Serious, Related Adverse Events All _Adverse Events_ that are Serious and Related are included. In addition, events that meet all of the following criteria are included: * The _Localized Case Adverse Event_ is Serious (localized_case_adverse_event__v.seriousness__v = !Blank) * The event is related to the _Product_ in the report (_Causality Established_ is set to Yes or Blank for at least one _Assessment Result_) * The event is reportable (localized_case_adverse_event__v.special_adverse_event__v != "Non-reportable Event") A _Case_ must have a _Product_ or _Product Registration_ that is a member of the _Aggregate Reporting Group_: * case_version__vr.case_product__v IN aggregate_reporting_group__vr.aggregate_reporting_group_join__vr.product__v * case_version__vr.case_product__v.product_registration__v.registration_number__v IN aggregate_reporting_group__vr.aggregate_reporting_group_join__vr.product_registration__v Vault excludes _Adverse Events_ with no _Assessment_ or _Assessment Result_ records. ##### Reporting Interval Assignments Vault includes _Cases_ within a reporting interval when the applicable _Case_ date (_Local Awareness Date_) is on or between the _Interval Start Date_ and _Interval End Date_ on the _Interval Dates_ filter. For example, the PMDA allows three different methods for handling cases with multiple versions. The following example is the method where only the latest version is reported: * **Interval 1:** January 1 – March 31 * **Interval 2:** April 1 – June 30 If a _Case_ has two versions with different _Local Awareness Dates_: * Version 1 falls into Interval 1 * Version 2 falls into Interval 2 **Result:** Only Version 2 will be included, and it will only appear in Interval 2. Version 1 is excluded so the case is not counted twice. _Cases_ that do not fall into any reporting intervals will be dropped. #### Table Mapping **Sorting**: Rows are in order of reporting interval (earliest first), Event (SOC) alphabetically, Event (PT) alphabetically, New Info Date (earliest first), and then Case Number. If the New Info Date is blank, Vault references the Case Receipt Date (earliest first). Each Reporting Interval heading appears on a separate line. If an interval has no Event PTs, Vault adds the following note:「該当なし」("N/A" in Japanese).
Number Name Description
1 Reporting Cycle # (番号) The name of the reporting interval on the Interval Dates record. aggregate_intervals__vr.name__v
2 Event (SOC) (器官別大分類) The Localized MedDRA System Organ Class (SOC) affected by the Adverse Event in Japanese (from the local MedDRA version).
3 Event (PT) (基本語) The Localized MedDRA Preferred Term Event in Japanese (from the local MedDRA version). An asterisk (*) is prepended to unexpected Adverse Events.
4 Gender (性別) The sex on the Case. If the field is blank, Vault populates "不明" (Unknown in Japanese).
5 Age (年齢) The normalized Age (in years) on the Case. If age is not populated on the Case, the report displays Age Group. If the field is blank, Vault populates "不明" (Unknown in Japanese).
6 Onset Date (副作用等発現 年月日) The Onset Date of the Case Adverse Event, as entered in the Date of Onset field on the Case Adverse Event in the format "YYYY年MM月DD日". If the field is blank, Vault populates "不明" (Unknown in Japanese).
7 Outcome (転帰) The Outcome of the Case Adverse Event. The value in the Case Adverse Event Outcome field. If the field is blank, Vault populates "不明" (Unknown in Japanese).
8 Infection or Adverse Event (副作用・感染症の区分) Vault references the Localized Case Adverse Event to populate this data. If the Special Adverse Event field is set to "Infection", Vault populates 感染症 (Infection in Japanese). Otherwise, Vault populates 副作用 (Adverse Event in Japanese).
9 Report Type (報告の 種類) The Case Report Type. The value in the Report Type field.
10 PMDA ACK # (識別番号) The Destination ID on the Transmission. ### Case Series Report {#case-series-report} The Case Series Report acts as a log file for all of the Cases included across all PMDA line listings and tabulations. Vault generates the Case Series Report in the following structure: **Note**: To aid in understanding how Vault maps Case Series Report data to PMDA files, the following table includes both descriptions and Vault object and field names.
Reference Image Number PMDA Report Field Name Description
Reference Image 1 Case Number Vault maps the Case Number on the Case. case_number__v.id
Reference Image 2 Case Name Vault maps the Name on the Case. case_version__v.name__v
Reference Image 3 Report Type Vault maps the Report Type on the Case. case_version__v.report_type__v > localized_controlled_vocabulary__v.name__v
Reference Image 4 Local Awareness Date Vault maps the Local Awareness Date on the Case. localized_case__v > local_awareness_date__v
Reference Image 5 Case Completed Vault maps whether the Case is Open or Completed on the Case. If completed__v then 'Completed' else 'Open'
Reference Image 6 Eligible for J-NUPR Vault maps if the Case has a valid event for J-NUPR.
Reference Image 7 Eligible for J-PSR Vault maps if the Case has a valid event for J-PSR. **Note**: Vault excludes Cases that contain the following field values: A Lifecycle State value of Nullified or Voided A Suppress Submission value of Yes ### Open Cases Report {#open-cases-report} The Open Cases Report is an operational report intended to help you identify open _Cases_ that may need to be closed before PMDA submission. It contains a log of all _Cases_ that would be included in at least one PMDA tabulation were they in the _Closed_, _Approved_, or _Superseded_ lifecycle state. Vault generates the Open Cases Report in the following structure: **Note**: To aid in understanding how Vault maps Open Cases Report data to PMDA files, the following table includes both descriptions and Vault object and field names.
Reference Image Number PMDA Report Field Name Description
Reference Image 1 Case Number Vault maps the Case Number on the Case. case_number__v.id
Reference Image 2 Case Name Vault maps the Name on the Case. case_version__v.name__v
Reference Image 3 Eligible for J-NUPR Vault maps if the Case has a valid event for J-NUPR.
Reference Image 4 Eligible for J-PSR Vault maps if the Case has a valid event for J-PSR.
Reference Image 5 Local Awareness Date Vault maps the Local Awareness Date on the Case. localized_case__v > local_awareness_date__v
Reference Image 6 Locked By Department Vault maps the Department value of the Locked By user on the Case. case_version__v.locked_by_department__v.name__v
Reference Image 7 Locked By User Vault maps the Name value of the Locked By user on the Case. case_version__v.locked_by_user__v.name__v
Reference Image 8 Report Type Vault maps the Report Type on the Case. case_version__v.report_type__v > localized_controlled_vocabulary__v.name__v [1]: #create-workbench-report-set [2]: #specify-workbench-report-set-filters [3]: #filter-section-fields [4]: #generate-run-workbench-tabulations [5]: #table-generation-data-mapping [6]: #inclusion-criteria-for-all [7]: #report-study-type-inclusion-scenarios [8]: #cumulative-tabulation-sae [9]: #tabulation-sae-inclusion-criteria [10]: #interval-line-listing-sar [11]: #line-listing-sar-inclusion-criteria [12]: #line-listing-sar-investigational-relatedness [13]: #cumulative-tabulation-sar [14]: #tabulation-sar-inclusion-criteria [15]: #tabulation-sar-investigational-relatedness [16]: #list-subjects-who-died [17]: #list-subjects-inclusion-criteria [18]: #death-occurred [19]: #case-series-report [20]: #open-cases-report [21]: #open-cases-inclusion-criteria [22]: #data-period-start [23]: #datasheet-active-date [24]: #aggregate-reporting-group [25]: #sae-tab-count [26]: #nupr-form-7-2 [27]: #j-psr-form-3 [28]: #j-psr-form-4