Set up Product and Study Datasheets so Vault 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 allow Vault 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. When you configure expectedness rationales for adverse events on Datasheets, Vault maps the text to applicable Case Assessment Expectedness and Localized Case Assessment records.
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 types of 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.
In Vaults configured to isolate blinded clinical trial information, Vault can generate Expectedness records for blinded Study Products on blinded Cases. This requires you to associate Datasheets with Study Product Placeholders when configuring double-blinded Studies without Study Arms.
Note: Vault does not currently support Expectedness evaluations for blinded Study Products on double-blinded Studies with Study Arms.
Prerequisites
To use all of the features described on this page, your Vault must be configured for:
- Listedness and Expectedness From Core Datasheets
- Conditional Expectedness
- Study Product Expectedness
- Product Family Datasheets
- MedDRA Query Building Blocks
- Datasheet Expectedness by Age and Sex
- Expectedness in Aggregate Reports
- Copy Datasheet Expectedness Justification to Case Assessments
- Datasheet Expectedness for Blinded Study Products
Before you create a Datasheet, upload the source product label or investigator’s brochure document to your Vault Library. Source documents must be classified with the Datasheet document type.
To ensure access to Datasheets, the Organization field on the MedDRA Criteria object must be required.
Make the Organization Field Required
- Navigate to Admin > Configuration > Objects > MedDRA Criteria > Object Types > Watchlist Field Criteria.
- Select the Organization field.
- Ensure the User must always enter a value (required) checkbox 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 populate the Organization field in the System section.
Note: If you don’t see the Watchlist Criteria object type, add this object type for the MedDRA Criteria object. Contact your Veeva Services representative for assistance.
Result
Vault automatically populates the Organization field for all new MedDRA Criteria records, using the default Criteria VQL.
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 the following 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 the following 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 Onset date of the Case Adverse Event and the Date of Birth in the Patient section. If those values are not available, Vault maps from the manually populated Age at Onset in the Patient section.
If the Age at Onset value uses Decades as the unit, Vault considers both the lower and upper bounds of the decade when evaluating expectedness. For example, if the patient’s age is entered using2
in the Number field and Decade in the Unit field, indicating they are between 10–20 years old, and the adverse event on the Datasheet is expected only for patients with an age range of 2–12 years old, Vault considers this adverse event unexpected since the upper bound of the decade (age 20) is outside the expected age range. - 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 calculated using the Onset date of the Case Adverse Event and the Date of Birth in the Patient section. If those values are not available, Vault maps from the manually populated Age at Onset in the Patient section.
- Primary Case Assessment: The primary Case Assessment is the assessment assigned a value of
1
in the Rank 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:
- Reporting Rules: When Vault 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 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
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 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 froduct 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 Datasheet are configured, Vault 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 Query 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.
In Vaults configured to isolate blinded clinical trial information, you can associate all Datasheets on a double-blinded clinical trial Study with a Study Product Placeholder. This allows Vault to generate expectedness for blinded Study Products on blinded Cases.
Add a Product Family Datasheet
Complete the following steps to add a Datasheet to a Product Family:
- Navigate to Business Admin > Objects > Product Families > [Product Family].
- Select Edit.
- In the Family Datasheet field, select an existing product core Datasheet.
- Select Save.
Create a Core Datasheet (Study or Product)
Complete the following steps to add a core Datasheet to a Study or Product:
- Navigate to Business Admin > Objects > [Object].
- Open the Study or Product record for which you want to add a core Datasheet.
- Select Edit.
- In the Core Datasheet field, select an existing Datasheet or select 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:
- Navigate to Business Admin > Objects > Products.
- Open the applicable 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 or select 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:
- Navigate 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 or select 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 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 and study product Datasheets. |
MedDRA Version | Select the version to use in coding expected adverse events (MedDRA Criteria). |
Enable Precise Expectedness | Select this field to prevent Vault from assigning an Expectedness value of When this field is selected, if Vault 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 evaluates Expectedness for a listed term with one (1) or more matching values in the Case Adverse Event Seriousness field, Vault populates Expectedness as 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.
- Navigate to Business Admin > Objects > Datasheets.
- In the Expected Adverse Events section, select Create.
- Complete the fields in 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, Vault 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 Vault 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 Vault 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 evaluates Expectedness for a Case Adverse Event with this term and one (1) or more matching Seriousness values, Vault populates Expectedness as 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. |
Expectedness Justification | Enter a rationale for the adverse event's expectedness value. Vault copies the text to applicable Case Assessment Expectedness and Localized Case Assessment records. This field supports up to 1,000 characters. |
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 thebuilding 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. |
Scope | Select the Scope. 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 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 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 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. |
Associate Datasheets with Study Product Placeholders
On a double-blinded clinical trial Study without Study Arms, use the Study Product Placeholder section to associate all of the related Datasheets with a blinded product. When this Study Product Placeholder is on a blinded study Case, Vault generates Expectedness records for each Datasheet associated with that Study Product Placeholder. For more information, see How Case Assessment Expectedness is Generated.
To associate Datasheets with a Study Product Placeholder:
- Navigate to the Study Product Placeholder to which you want to associate Datasheets. You can find Study Product Placeholders in the Study Product Placeholders section of the applicable Study or by navigating to Business Admin > Objects > Study Product Placeholders.
- From the All Actions menu, select Generate Study Product Datasheets.
In the Datasheets section of the Study Product Placeholder, Vault populates links to each Datasheet associated with the Study. If multiple Registrations on the Study have the same Datasheet, Vault adds a single link to that Datasheet. If you add or remove Datasheets on the Study or Study Products, you must run the Generate Study Product Datasheets action again to update the list of associated Datasheets for the Study Product Placeholder.
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.