Set up Product and Study Datasheets so Vault Safety automatically determines expectedness.
About Datasheets
Use Datasheets to configure expected adverse events for any of the following:
- Product Family
- Product
- Product Registration
- Study
- Study Product
Datasheets enable Vault Safety to automatically determine the expectedness of adverse events based on the listed events. For Case processing and some aggregate reports (CIOMS II, DSUR, PBRER, and PSUR), Vault considers Datasheet criteria, including medical conditions, high-level MedDRA terms, and age and sex demographics when calculating expectedness. You can also define an active range for expectedness in certain aggregate reports.
To use auto-expectedness, your Admin must set up at least one (1) Core Datasheet for the Study or Product. Admins can optionally set up additional Local Datasheets and Study Product Datasheets for more precise reporting rules evaluation.
Local Datasheets allow the reporting rules engine to evaluate expectedness specific to a country in which the product is registered (for non-Study Cases only). For Studies with multiple products, Study Product Datasheets allow the reporting rules engine to evaluate expectedness at the Study Product level.
To simplify Datasheet management for large groups of products, your Admin can create Product Family Datasheets. Upon creation, Product Family Datasheets are inherited by all Products within the family that do not have a specified Datasheet.
Important Terms
- Expectedness: Expectedness refers to whether an adverse event is expected and listed on product labels and investigator brochures. When coding Adverse Events on Cases, any MedDRA Lower Level Term (LLT) is considered a match if it is listed on or falls under the hierarchy of the term on the Datasheet.
- Listedness: Listedness refers to the expectedness defined in core Datasheets. For Products, this includes Company Core Data Sheets (CCDSs) and for Studies and Study Products this includes Investigational Brochures (IBs) and Development Core Safety Information (DCSIs).
- Conditional Expectedness: Conditional expectedness is a level of configuration where you can define seriousness criteria for which listed adverse events are unexpected. There are two (2) related fields:
- Unexpected Seriousness Criteria on a Datasheet
- Seriousness Exclusion on a MedDRA Criteria
- Precise Expectedness: Precise expectedness is a level of configuration where you can define the expectedness of individual terms on the Datasheet. There are two related fields:
- Enable Precise Expectedness on a Datasheet
- Expectedness on a MedDRA Criteria
- Active Range: The active range defines the start and end dates for which a term was approved to be listed and considered expected for some aggregate reports and Clinical Trial Study Cases. For more information, see Active Range for Expectedness in Aggregate Reports.
- Age Range: The age range defines the start and end patient ages for which an adverse event is expected or unexpected. The age range entered on the Datasheet is matched to the patient age on the Case using the following priority order:
- Age at Onset
- Calculated using the Case Adverse Event Onset date and the Patient Date of Birth value
- If the above is not available, mapped from the manually populated Age at Onset on the Case
- Age Group based on the Age Group Controlled Vocabulary type. When matching is based on Age Group, the Patient Age Group must fall entirely within the Age Range on the Datasheet. For more details on expectedness evaluations With demographics, see How Case Assessment Expectedness is Generated.
- Age at Onset
- Primary Case Assessment: The primary Case Assessment is the assessment assigned a value of “1” in the Rank (
rank__v
) field. Typically, this is the assessment that links the primary Case Adverse Event with the primary Case Product.
How Expectedness is Used in Safety Features
Expectedness is a component in many Vault Safety features, which includes the following functionalities:
Functionality | Relationship |
---|---|
Reporting Rules | When Vault Safety evaluates reporting rules, the Case Assessment Expectedness records for the most reportable Case Assessment being evaluated are used to evaluate whether the case is expected or unexpected in the relevant jurisdiction. This is evaluated through the Expected reporting rule parameter. Depending on your Admin's configuration, Vault may also apply Agency-based expectedness evaluation rules when generating Transmissions. For more information, see Generate a Regulatory Report. |
Case Expedited Flag | If a Case contains a Case Assessment for a serious adverse event that is determined to be unexpected, the Expedited field on the Case is set to "Yes", which identifies that the Case requires expedited reporting. |
Case and Assessment and Tagging | When assigning Case tags, Vault Safety evaluates the Expectedness field on Case Assessments. For example, when a Study Case includes a serious and unexpected adverse event, it is assigned the SUSAR tag. For more information on how Vault evaluates expectedness, see How Case Assessment Expectedness is Generated. |
Aggregate Reports | CIOMS II, DSUR, PBRER, and PSUR aggregate reports rely on Datasheets to identify labeled and listed terms. You can configure these aggregate reports to mark unexpected terms with an asterisk. |
Datasheet Types
Admins can configure the following types of Datasheets:
- Product Family Datasheet
- Product Core Datasheet
- Study Core Datasheet
- Local Datasheets (Product Registration)
- Study Product Datasheet
Product Family Datasheet
A Product Family Datasheet is a central Datasheet for a group of Products configured within a Product Family in your Product Library. Product Family Datasheets are applied to Products within the Product Family that do not have specified Datasheets. When the list of expected and unexpected Adverse Events is updated on the Product Family Datasheet, the changes are automatically carried to the Products using that Datasheet. You can add only one (1) Datasheet per Product Family.
Product Core Datasheet
A Product Core Datasheet is the central Datasheet for a Product, corresponding to a Company Core Data Sheet (CCDS). You can add only one (1) Core Datasheet per Product.
Study Core Datasheet
A Study Core Datasheet is the central Datasheet for a Study, corresponding to a study’s Investigational Brochure (IB). You can add only one (1) Core Datasheet per Study.
For Study Cases, Vault Safety uses the Study Core Datasheet to drive reporting rules for the Expected parameter reporting rules evaluation. This way, Study Datasheets can list expected adverse events that are different from Product Datasheets.
Local Datasheets (Product Registration)
A Local Datasheet is specific to a country or region to which a product is registered. For example, a Local Datasheet may correspond to a United States Prescribing Information (USPI) sheet for FDA reporting or a Summary of Product Characteristics (SmPC) for EMA reporting.
Local Expectedness allows for more precise reporting rules evaluation. When Local Datasheets are configured, Vault Safety looks at all Local Datasheets in the jurisdiction of the agency for precise expectedness evaluation for that region when matching the Case to a reporting rule. You can configure Local Datasheets to inherit the adverse events listed on the Core Datasheet.
Study Product Datasheet
For Studies involving multiple Study Products, Datasheets can be created at the Study Product level. This supports identifying expected adverse events for each Study Product. When evaluating Expectedness, Vault generates records based on both the Study Product Datasheets and the Study Core Datasheet. You can add only one (1) Datasheet per Study Product. You can configure Study Product Datasheets to inherit listed events from the Study Core Datasheet.
Configure Datasheets
To set up Datasheets, you can first configure a Core Datasheet for the Product or Study, then set up additional Local or Study Product Datasheets, if required. When managing a large group of Products that are within a Product Family you can configure a Product Family Datasheet, which is applied to any of the related Products that do not have a specified Datasheet. After creating a Datasheet, you add MedDRA Criteria and MedDRA Building Block records to list expected and unexpected terms.
You can create and apply Datasheets in the following ways:
- Create the Datasheet, and then apply it to a Product Family, Product, Product Registration, Study, or Study Product.
- Go to the Product Family record and add an existing Product Core Datasheet.
- Go to the Product, Product Registration, Study, or Study Product record and select an existing Datasheet or create the Datasheet to immediately link it to that record.
Prerequisites
Configure the following Datasheet features in your Vault:
- Enable Listedness and Expectedness From Core Datasheets
- Enable Conditional Expectedness
- Enable Study Product Expectedness
- Enable Product Family Datasheets
- Enable MedDRA Query Building Blocks
- Enable Datasheet Expectedness by Age and Sex
- Enable Expectedness in Aggregate Reports
Before you create a Datasheet, upload the source product label or investigator’s brochure document to the Library. Source documents must be classified with the Datasheet document type.
To ensure access to Datasheets, the MedDRA Criteria object must be configured so the Organization field is mandatory.
Make the Organization Field Mandatory
- Go to Admin > Configuration > Objects > MedDRA Criteria > Object Types.
- Go to the Watchlist Field Criteria object type, and then select the Organization field.
- In the Organization field, ensure User must always enter a value (required) is selected. Do not modify the Criteria VQL.
- If watchlists were already added to your Vault before enabling this setting, go to each watchlist and manually specify the Organization field in the System section.
Note: If you don’t see the Watchlist Criteria object type, add this object type under the MedDRA Criteria object. Contact your Veeva Services representative for assistance.
Result
The system will automatically populate the Organization field for all new MedDRA Criteria records, using the default Criteria VQL.
Add a Product Family Datasheet
Complete the following steps to add a Datasheet to a Product Family:
- Go to the Product Family record for which you want to add a Product Family Datasheet. Find Product Families in Business Admin > Objects > Product Families.
- Open the Product Family and then select Edit.
- In the Family Datasheet field, select an existing Product Core Datasheet from the dropdown list. If you do not see the Datasheet you want to select, you must create a Datasheet.
- Select Save.
Create a Core Datasheet (Study or Product)
Complete the following steps to add a Core Datasheet to a Study or Product:
- Go to the Study or Product record for which you want to add a Core Datasheet:
- Find Products in Business Admin > Objects > Products.
- Find Studies in Business Admin > Objects > Studies.
- Select Edit.
- In the Core Datasheet field, select an existing Datasheet from the dropdown list or Create Datasheet.
- For new Datasheets, complete the fields on the Create Datasheet page, and then select Save.
- On the Product record, select Save.
How-To Video: Setting Up Core Datasheets
Watch our quick video tutorial on Setting Up Core Datasheets.
Create a Local Datasheet
Complete the following steps to add a Local Datasheet at the Product Registration level:
- Go to Business Admin > Objects > Products.
- Open the Product, and then open the Product Registration for which you want to add a Local Datasheet.
- Select Edit.
- In the Local Datasheet field, select an existing Datasheet from the dropdown list or Create Datasheet.
- For new Datasheets, complete the fields on the Create Datasheet page, and then select Save.
- On the Product Registration record, select Save.
How-To Video: Setting Up Local Datasheets
Watch our quick video tutorial on Setting Up Local Datasheets.
Create a Study Product Datasheet
Complete the following steps to add a Datasheet to a Study Product:
- Go to Business Admin > Objects > Studies.
- Open the Study, and then open the Study Product for which you want to add a Study Product Datasheet.
- Select Edit.
- In the Study Product Datasheet field, select an existing Datasheet from the dropdown list or Create Datasheet.
- For new Datasheets, complete the fields on the Create Datasheet page, and then select Save.
- On the Study Product record, select Save.
Create a Datasheet
Complete the following steps to create a Datasheet to apply to a Product Family, Product, Product Registration, Study, or Study Product:
- Go to Business Admin > Objects > Datasheets.
- Select Create.
- Complete the fields on the Create Datasheet page.
- Select Save.
Datasheet Fields
Field | Description |
---|---|
Name | Enter a name for the Datasheet. |
Organization | Select the organization to which the Datasheet belongs. |
Label/Brochure | Select the document corresponding to the Datasheet from the Library. |
Core | Identify whether this Datasheet is a core Datasheet:
|
Core Datasheet | (Optional) To inherit expected adverse events from a Core Datasheet, select the Core Datasheet. This field appears only for Local Datasheets and Study Product Datasheets. |
Country | Select the country for which the datasheet applies. Submissions for agencies with jurisdiction over this country will evaluate expectedness using this datasheet. This field only appears for Local Datasheets and Study Product Datasheets. |
MedDRA Version | Select the version of MedDRA to use in coding expected adverse events (MedDRA Criteria). |
Enable Precise Expectedness | Select this field to prevent Vault from assigning an Expectedness value of "No" (Unexpected) for terms that are not listed on the Datasheet. When this field is selected, if Vault Safety evaluates Expectedness for an unlisted term, Vault leaves the Expectedness blank. You can define which terms are unexpected using the Expectedness field on the Datasheet's MedDRA Criteria. |
Unexpected Seriousness Criteria | To define conditions for which events are always unexpected, select one (1) or more seriousness criteria. When this field is defined, if Vault Safety evaluates Expectedness for a listed term with one (1) or more matching values in the Case Adverse Event Seriousness field, Vault populates Expectedness as "No" (Unexpected). If Seriousness Exclusion is defined at the MedDRA Criteria level, the MedDRA Criteria setting takes precedence and this field is ignored for that term. |
Manage Expected Adverse Events on a Datasheet
Once you create and save a Datasheet, the Expected Adverse Events and Datasheet MedDRA Queries sections appear. These sections enable you to list expected adverse events by adding MedDRA Criteria and MedDRA Query records.
To support hierarchical browsing of MedDRA Terms, we recommend making some criteria VQL updates in your Vault. Contact your Admin to enable MedDRA UI Enhancements for Non-Case Coding. To use MedDRA Queries to add a large group of adverse events from a combination of SMQs, CMQs, and MedDRA Terms at once, your Admin must enable MedDRA Query Building Blocks.
Add Expected Adverse Events (MedDRA Criteria)
Adverse events can be added to Datasheets at any level of the MedDRA hierarchy. When Case Processors code adverse events on Cases, any MedDRA LLT is considered a match if it is listed on or falls under the hierarchy of the term on the Datasheet. For example, if the Datasheet includes the HLGT “Allergic conditions” as an unexpected adverse event, then the Case-level LLT “Drug-cross-reactivity” would be considered unexpected because it falls under the Datasheet-coded HLGT.
Add individual expected adverse events as MedDRA Criteria records under the Datasheet.
- Go to the Datasheet record page. Find Datasheets on the Business Admin > Objects > Datasheets page.
- Under Expected Adverse Events, select Create.
- Complete the fields on the Create MedDRA Criteria window.
- Select Save.
Create MedDRA Criteria Fields
Field | Description |
---|---|
MedDRA Term | Enter a search term for any level of the MedDRA hierarchy and then select Auto-code or the Advanced Search () icon to search in the MedDRA Browser. Note: To use a term during aggregate reporting, terms must be added at the PT or LLT level. Auto-Code When you select Auto-code, the system attempts to match the term to the least specific level of the hierarchy, searching in priority order of SOC, HLGT, HLT, PT, and then LLT. When the system finds an exact match, the term is populated in the field. Below the field, the matched term and level appear in bold and any less specific hierarchical levels are listed below. If the system does not find an exact match, a notification appears. You can enter a different search term to auto-code or search using the MedDRA Browser. If you have entered a term in the MedDRA Term field, it appears in the MedDRA Browser Search bar. Advanced Search To search for a term using the MedDRA Browser, complete the following steps:
Result The term is populated in the field. Below the field, the matched term and level appear in bold and all of the less specific hierarchical levels are listed below. Note: When you hover over the hovercard for the MedDRA Term, the Primary SOC is listed only if the field is coded at the LLT or PT level. The Primary SOC is not listed if the field is coded at the HLT, HLGT, or SOC level of the hierarchy. |
Include Lower Levels | (Optional) This field determines whether lower-level terms are included when evaluating expectedness during aggregate reporting (CIOMS II, DSUR, PBRER, and PSUR). If an adverse event does not match a Preferred Term (PT) in the Datasheet, Vault checks whether the adverse event matches a Lower Level Term (LLT). |
MedDRA Condition | Enter the name of the medical condition to which the adverse event applies and then select Auto-code or the Advanced Search () icon to select the MedDRA LLT from the MedDRA Browser. Vault matches the medical condition with the Product Indications on a Case to determine whether an adverse event is expected. |
Active Date Start | To specify when a term was approved to be listed on the datasheet, enter the date of approval. The date is inclusive. This setting impacts expectedness evaluation in some aggregate reports. Active Range for Expectedness in Aggregate Reports provides more information. |
Active Date End | Optionally, to specify the last day when a term was approved to be listed on the datasheet, enter the end date. The date is inclusive. The day after the Active Date End is the first day the term is considered unlisted and unexpected.If you don't specify an end date, the term is considered actively approved and expected. This setting impacts expectedness evaluation in some aggregate reports. Active Range for Expectedness in Aggregate Reports provides more information. |
Description | Enter a description of the expected adverse event. |
Expectedness | By default, all terms on the datasheet are considered expected. However, you can use this field to specify whether terms on the sheet are unexpected. If unspecified, this field defaults to Yes (expected). |
Seriousness Exclusion | To define conditions for which this event is always unexpected, select one (1) or more seriousness criteria. When this field is defined, if Vault Safety evaluates Expectedness for a Case Adverse Event with this term and one (1) or more matching Seriousness values, Vault populates Expectedness as "No" (Unexpected). If you populate this field, Vault ignores the Unexpected Seriousness Criteria setting on the Datasheet for this term. |
Age Range Start | Specify the earliest patient age for which a term is expected or unexpected. Enter a number and unit. The date is inclusive. Specifying an Age Range Start, but not an Age Range End, means the term applies to patients of a minimum age. |
Age Range End | Specify the latest patient age for which a term is expected or unexpected. Enter a number and unit. The date is inclusive. Specifying an Age Range End, but not an Age Range Start, means the term applies to patients up to a maximum age. |
Sex | Specify the sex for which a term is expected or unexpected. Select an option from the picklist or leave blank to include all sexes. |
Add Datasheet MedDRA Queries (MedDRA Query Building Blocks)
MedDRA Query Building Blocks offer a way to combine existing Standard MedDRA Queries (SMQs), hierarchical MedDRA terms, and Custom MedDRA Queries (CMQs) in a MedDRA Query record. The MedDRA Query with the building blocks can then be applied to multiple Datasheets and Watchlists, and all of the MedDRA Terms within the building blocks are added to those records. Vault considers only SMQ terms with the same MedDRA Version value of the Datasheet or Watchlist. Admins control when to push MedDRA Query record changes to all Datasheets and Watchlists using it.
Add each MedDRA Query record under the Datasheet.
- Navigate to Business Admin > Objects > Datasheets.
- In the MedDRA Queries section, select Create and then complete the fields.
- Select Save. Select Save + Create to add immediately another MedDRA Query record to your Datasheet.
- In the All Actions menu, select Update from MedDRA Queries.
Result
All of the MedDRA LLTs that fall under the MedDRA Query records are listed in the Expected/Unexpected Event Terms section.
MedDRA Query Fields
Field | Description |
---|---|
MedDRA Query | Select a MedDRA Query record from the dropdown list. |
Scope | Select whether the terms in the MedDRA Query record are Narrow, Broad, or both. Select Narrow or Broad to pull in values with the corresponding scope applied on the SMQ or CMQ term. Leave blank to pull in all values. |
Expectedness | Select whether all the terms in the MedDRA Query are Expected or Unexpected. |
Seriousness Exclusion | To define conditions for which the listed events are always Unexpected, select one (1) or more seriousness criteria. When this field is defined, if Vault Safety evaluates Expectedness for a Case Adverse Event with any of the MedDRA Query record terms and one (1) or more matching Seriousness values, Vault populates Expectedness as "No" (Unexpected). If you populate this field, Vault ignores the Unexpected Seriousness Criteria setting on the Datasheet for these terms. |
Active Date Start | To specify when the terms were approved to be listed on the Datasheet, enter the date of approval. The date is inclusive. This field applies only to Clinical Trial Study Cases. This setting impacts expectedness evaluation in some aggregate reports. Active Range for Expectedness in Aggregate Reports provides more information. |
Active Date End | Optionally, to specify the last day when the terms were approved to be listed on the Datasheet, enter the end date. The date is inclusive. This field applies only to Clinical Trial Study Cases. The day after the Active Date End is the first day the terms are considered unlisted and unexpected. If you don't specify an end date, the term is considered actively approved and expected. This setting impacts expectedness evaluation in some aggregate reports. Active Range for Expectedness in Aggregate Reports provides more information. |
Description | Enter a description of the expected adverse event. |
Age Range Start | Specify the earliest patient age for which a term is expected or unexpected. Enter a number and unit. The date is inclusive. Specifying an Age Range Start, but not an Age Range End, means the term applies to patients of a minimum age. |
Age Range End | Specify the latest patient age for which a term is expected or unexpected. Enter a number and unit. The date is inclusive. Specifying an Age Range End, but not an Age Range Start, means the term applies to patients up to a maximum age. |
Sex | Specify the sex for which a term is expected or unexpected. Select an option from the picklist or leave blank to include all sexes. |
Active Range for Expectedness in Aggregate Reports
CIOMS II, DSUR, PBRER, and PSUR tabulations consider active dates when evaluating expectedness. You can define a range when a Datasheet term is approved to be listed and considered expected for aggregate reports using the Active Date Start, and optionally the Active Date End on a core or product family Datasheet. Outside of this active range, the term is considered unexpected in aggregate report tabulations.
Note: If there is no active range specified for a term on the Datasheet, Vault considers the term approved and expected for all timeframes. When the Active Date End is unspecified, the term is considered actively approved and expected to the present day.
By default, Vault calculates expectedness against the Data Period Start on an Aggregate Report. However, you can configure PSUR reports to use the Data Period End. Vault uses the start or end date alongside the active dates on the Datasheet to determine if a term is expected during the reporting period:
- Expected: When the Data Period Start or Data Period End date is within the Datasheet term’s active dates or if the term on the Datasheet has no active dates.
- Unexpected: When the Data Period Start or Data Period End date is outside the Datasheet term’s active dates.
Note: If Expectedness is not defined, the value defaults to Expected. If a term does not appear on the Datasheet, aggregate reports consider it Unexpected.
When a term is referenced by multiple MedDRA Criteria on the same Datasheet (being unlisted and later relisted), the term is considered expected when the aggregate reporting period is within the active dates on any matching term.
When you configure the Aggregate Report, you can configure the report to identify unexpected terms using the Indicate Unexpected Term field. The PSUR Summary Tabulations consider a Datasheet term’s active date, regardless of the Indicate Unexpected Term value.
Note: Aggregate Reports evaluate the Active Range on a product’s core Datasheet only. Local Datasheets are not evaluated.