Sections in This Article
- About Datasheets
- Important Terms
- How Expectedness is Used in Safety Features
- Datasheet Types
- Configure Datasheets
- Case Assessment Expectedness Generation
- How Expectedness Rolls Up to Case Expectedness and Listedness
- Override Case Expectedness or Listedness
- Active Range for Expectedness in Aggregate Reports
About Datasheets
Use Datasheets to configure expected adverse events for a Study or Product. Datasheets enable Vault Safety to automatically determine expectedness of adverse events, based on the listed events.
To use auto-expectedness, an admin must set up a Core Datasheet at minimum for the Study or Product. Admins can optionally set up additional Local 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). Core datasheets are used to evaluate expectedness in some Aggregate Reports.
Important Terms
- Expectedness
- Expectedness refers to whether an adverse event is expected and listed on product labels and investigator brochures.
- Listedness
- Listedness refers to the expectedness defined in core datasheets (Product CCDS or Study IB/DCSI).
- 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 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 period for which a term was approved to be listed and considered expected for aggregate reporting (DSUR, PBRER, and PSUR).
- 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 primary (or most conservative) Case Assessment are used to evaluate whether the case is expected or unexpected in the relevant jurisdiction. This is evaluated through the Expected reporting rule parameter. |
| Case Expedited Flag | If a Case contains a Case Assessment for a serious adverse event that is determined to be unexpected, the Case Expedited field is enabled, 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. |
| Aggregate Reports | PADER and PSUR aggregate reports rely on Datasheets to identify labeled and listed terms. Also, aggregate reports can be configured to mark unexpected terms with an asterisk. |
Datasheet Types
There are three types of Datasheets admins can configure, which are described in the following sections:
- Product Core Datasheet
- Local Datasheets (Product Registration)
- Study Core Datasheet
Product Core Datasheet
A Core Datasheet is the central datasheet for a Product, corresponding to a Company Core Data Sheet (CCDS). You can add only one Core Datasheet per Product.
Study Core Datasheet
A Core Datasheet is the central datasheet for a Study, corresponding to a study’s Investigational Brochure (IB). You can add only one 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 the 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 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.
Configure Datasheets
To set up datasheets, first configure a Core Datasheet for the Study or Product, then set up additional Local Datasheets, if required. After creating a datasheet, you can add MedDRA Criteria records to list terms.
Prerequisites
- You must be an administrator to manage datasheets.
- Ensure your Vault has the following configuration to enable certain datasheet features:
- Before you create a Datasheet, upload the source product label or investigator's brochure document to the Library. Once you upload the source document, classify the document with the appropriate Datasheet document type.
- The MedDRA Criteria object must be configured so the Organization field is mandatory.
Certain vaults may not have this configuration by default. Ensure your vault has this setting configured, otherwise users may not have access to datasheets.
-
Read More...
Make the Organization Field Mandatory
- In Admin, go to Configuration > Objects > MedDRA Criteria.
- Go to the Object Types tab.
- Go to the Datasheet 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 datasheets were already added to your vault before enabling this setting, go to each datasheet and manually specify the Organization field in the System section.
Result
The system will automatically populate the Organization field for all new MedDRA Criteria object, using the default Criteria VQL.
Create a Core Datasheet (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
. - In the Search: Core Datasheet window, select Create.
- Complete the fields on the Create Datasheet page.
- Select Save.
How-To Video: Setting Up Core Datasheets
The following video provides an overview of setting Up Core Datasheets:
Create a Local Datasheet
- Go to Business Admin > Objects > Products
- Open the Product that contains the Product Registrations for which you want to add a Local Datasheet.
- Open the Product Registration for which you want to add a Local Datasheet.
- Select Edit.
- In the Local Datasheet field, select .
- In the Search: Local Datasheet window, select Create.
- Expand Local Datasheets, and then select Create.
- Complete the fields on the Create Datasheet page.
- Select Save.
How-To Video: Setting Up Local Datasheets
The following video provides an overview of setting Up Local Datasheets:
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 only appears for Local 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. |
| MedDRA Version | Select the version of MedDRA to use in coding expected adverse events (MedDRA Criteria). |
| Enable Precise Expectedness | Select this field to prevent the system 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, the system 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 or more seriousness criteria. When this field is defined, if Vault Safety evaluates Expectedness for a listed term with one or more matching values in the Case Adverse Event Seriousness field, the system populates Expectedness as "No" (Unexpected). Note that 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 section appears, which you can use to list expected adverse events by adding MedDRA Criteria records.
When a Case Adverse Event matches a MedDRA term listed on a Datasheet, the system automatically detects that the adverse event is expected in Cases with the associated Product or Study.
Add Expected Adverse Events (MedDRA Criteria)
Add each expected adverse event as a MedDRA Criteria record 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:
Field Description MedDRA Term (Required) Select the MedDRA Preferred Term (PT) or Lower Level Term (LLT) term for the adverse event. If you select a PT, consider turning on Include Lower Levels.
Code MedDRA Terms provides more information on coding with MedDRA.Include Lower Levels To include lower-levels when the system evaluates expectedness, select Yes. If an adverse event does not match a Preferred Term (PT) in the Datasheet, the system checks whether the adverse event matches a Lower Level Term (LLT). Medical Condition Enter the name of the medical condition to which the adverse event applies. The system 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 aggregate reports (DSUR, PBRER, and PSUR). 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 field is not displayed by default and must be added to the page layout to appear.
This setting impacts expectedness evaluation in aggregate reports (DSUR, PBRER, and PSUR). 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 or more seriousness criteria.
When this field is defined, if Vault Safety evaluates Expectedness for a Case Adverse Event with this term and one or more matching Seriousness values, the system populates Expectedness as "No" (Unexpected).
If you populate this field, the system ignores the Unexpected Seriousness Criteria setting on the Datasheet for this term.
- Select Save.
Case Assessment Expectedness Generation
Vault Safety assesses expectedness for each Case Assessment through system-generated Expectedness records.
An Expectedness record identifies whether the MedDRA term on a Case Adverse Event is considered expected on the corresponding Product or Study Datasheet.
Expectedness records are generated for each of the following Datasheet sources associated with the Case Product in the Case Assessment:
| Source | Expectedness Generation |
|---|---|
| Product Core Datasheet | If an assessment’s Case Product has a Core Datasheet, an Expectedness record is generated for the Core Datasheet. |
| Study Core Datasheet | When the assessment’s Case Product is of the type Study Product, and if the Study Product Role is Investigational, an Expectedness record is generated for the Study’s Core Datasheet. |
| Local Datasheets | Expectedness records are generated for each Case Product Registration with a Local Datasheet. Admins can configure Local Datasheets to inherit listed events from the Core Datasheet. |
All Expectedness records are linked to the source Datasheet and the latest version of the referenced datasheet document in Vault Library.
Note When assessing Combination Products, the Case expectedness is based on the drug or biologic constituent. The device constituent expectedness is not assessed.
How Expectedness is Evaluated
When evaluating whether a Case Adverse Event is expected in relation to a Case Product’s Datasheet, the system first checks whether the event MedDRA is listed on the Datasheet. Then, the system performs a number of checks based on the precise expectedness and conditional expectedness settings on the Datasheet.
The following flowchart illustrates how Vault Safety evaluates Case Assessment Expectedness. The green components show the precise expectedness evaluation evaluation, while the orange components show the conditional expectedness evaluation:
The following table outlines the different expectedness scenarios, based on the Datasheet settings and MedDRA Criteria settings for the event term:
| Term Listed on Datasheet? | Datasheet | MedDRA Criteria | Case Assessment Expectedness | ||
|---|---|---|---|---|---|
| Precise Expectedness Enabled? | Unexpected Seriousness Criteria | Expectedness | Seriousness Exclusion | ||
| Yes | n/a | Blank | Expected 1 | Blank | Yes |
| Yes | n/a | n/a 2 | Expected | Yes: not matching 3 | Yes |
| Yes | n/a | Yes: not matching 3 | Expected | Blank | Yes |
| Yes | n/a | n/a 2 | Expected | Yes: matching 3 | No |
| Yes | n/a | Yes: matching 3 | Expected | Blank | No |
| Yes | n/a | n/a | Unexpected | n/a | No |
| No | No | n/a | n/a | n/a | No |
| No | Yes | n/a | n/a | n/a | Blank |
| 1. If "Expectedness" is not defined, the value defaults to Expected. | |||||
| 2. When "Seriousness Exclusion" is defined on a MedDRA Criteria record, this setting takes precedence and the Datasheet's "Unexpected Seriousness Criteria" setting is ignored. | |||||
| 3. Matching refers to whether the Case Adverse Event has one or more Seriousness values that match a Seriousness condition defined on the Datasheet or MedDRA Criteria. | |||||
How-To Videos: Understanding Expectedness Evaluations
Watch our quick video tutorials on Understanding Expectedness Evaluations and Understanding Precise Expectedness Evaluations.
When is Expectedness Evaluated
Expectedness is evaluated upon Case creation, and re-evaluated when the related Case Assessment, Case Adverse Event, or Case Product are updated.
When re-evaluating expectedness, the system replaces the previous system-generated Case Assessment Expectedness records with new records.
Note Case Assessment Expectedness records with an Overridden status are not deleted and do not get re-created, unless an associated Product or Adverse Event is updated.
The following table provides more information:
| Object | Conditions |
|---|---|
| Case | Expectedness is evaluated upon Case promotion. For Follow-Up Cases, Case Assessment Expectedness records are copied from the previous Case version. Expectedness is not recalculated unless the Case Adverse Event Seriousness or MedDRA Term (Event MedDRA) changed in the new version. Note
|
| Case Assessment | Expectedness is evaluated when a Case Assessment is created or updated. |
| Case Adverse Event | Expectedness is evaluated when a Case Adverse Event related to a Case Assessment is created or either of the following fields are modified:
|
| Case Product | Expectedness is evaluated when a suspect or interacting Case Product related to a Case Assessment is created or the linked Product or Study Product are updated. |
| Case Product Indication | Expectedness is evaluated when an Indication under the Case Product related to a Case Assessment is created or the Indication (Reported) field is updated. |
How Expectedness Rolls Up to Case Expectedness and Listedness
The system uses Expectedness records to automatically populate the Expectedness and Listedness fields on a Case.
How the system populates these fields depends on the Datasheets available, and whether the Case is associated with a Study. The following section provide more information on the auto-calculation logic for Study and non-Study Cases.
The Listed (Status) and Expectedness (Status) fields become “Auto-Calculated” when Vault Safety automatically populates these fields. Users can override the field values manually.
Expectedness Roll Up Evaluation
The following illustrations show the auto-expectedness process for a Case using the Product or Study Datasheets:
-
Expectedness from Core Product Datasheet -
Expectedness from Study Datasheet
Expectedness Generation
Vault Safety generates Case Assessment Expectedness records for each relevant Datasheet:
- Non-Study Cases: An Expectedness record is generated for each Product Datasheet (Core or Local) related to the Case Product.
- Study Cases: An Expectedness record is generated for the Study Datasheet, if configured, as well as any Product Datasheets (Core or Local) related to the Case Product.
Case Assessment Listedness and Expectedness
To automatically populate the Expected and Listed fields on a Case Assessment, the system looks at the Case Assessment’s Expectedness records using the following logic:
- To populate the Listed field on the Case Assessment:
Case Report Type Auto-Population Logic Non-Study Case If there is an Expectedness record corresponding to the Product’s Core Datasheet, this rolls up to populate the Listed field on the Case Assessment.
If there is no Product Core Datasheet, the Listed field is not automatically populated.
Study Case If there is an Expectedness record corresponding to the Study’s Core Datasheet, this Expectedness rolls up to populate the Listed field on the Case Assessment.
If there is no Study Datasheet but there is an Expectedness record corresponding to the Product’s Core Datasheet, this value rolls up to the Listed field.
If there are no Core Datasheets, the Listed field is not automatically populated.
- To populate the Expected field on the Case Assessment:
Case Report Type Auto-Population Logic Non-Study Case The system evaluates all Expectedness records under the Case Assessment to set the Expected field, using the following logic:
- Unexpected: If one or more Expectedness records are set to No or blank
- Expected: If all Expectedness records are set to Yes
Study Case If there is an Expectedness record corresponding to the Study’s Core Datasheet, this Expectedness rolls up to populate the Expected field on the Case Assessment.
If there is no Study Datasheet, the system evaluates all Expectedness records under the Case Assessment to set the Expected field as follows:
- Unexpected: If one or more Expectedness records are set to No or blank
- Expected: If all Expectedness records are set to Yes
- To populate the Listed field on the Case Assessment:
Case Listedness and Expectedness
At the Case-level, both the Listedness and Expectedness fields are synced with the primary Case Assessment. Unless the Case fields are overridden, any time the primary Case Assessment changes, the associated Case-level fields are updated to match.
Override Case Expectedness or Listedness
There are two ways to update the Case Expectedness or Listedness fields:
- Edit the field on the primary Case Assessment to override the system-calculated expectedness. The associated (Status) field updates to "Overridden" on the Case Assessment but remains Auto Calculated on the Case.
This will automatically update the associated field at the Case-level, because the Case fields are synced with the primary Case Assessment.Note Overridden Case Assessment Expectedness records are not deleted or re-created, unless an associated Product or Adverse Event is updated.
- Edit the field directly on the Case to override the value, and prevent the system from syncing the value with the primary Case Assessment. The associated (Status) field updates to "Overridden" on the Case.
Note If you use this option, the system will not update the Case Expectedness or Listedness to match any future changes to the associated fields on the primary Case Assessment.
How-To Video: Overriding Auto-Expectedness Evaluations
Watch our quick video tutorial on Overriding Auto-Expectedness Evaluations.
Active Range for Expectedness in Aggregate Reports
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 End Date on a Core Datasheet. Outside of this active range, the term is considered unexpected in aggregate report tabulations.
Note When the Active Date End is unspecified, the term is considered actively approved and expected to the present day.
The system uses the reporting period on the aggregate report alongside the active dates on the datasheet to determine if a term is expected during the reporting period:
- Expected: When the aggregate reporting period1 is within the datasheet term’s active dates.
- Unexpected: When the aggregate reporting period1 is outside the datasheet term’s active dates.
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.
By default, the aggregate reporting period is taken from the Data Period Start on an Aggregate Report. However, you can configure PSUR reports to use the Data Period End.
Note If there is no active range specified on the datasheet, the system looks up if the term exists to consider the term as expected.
DSUR, PBRER, and PSUR tabulations consider the active dates when evaluating expectedness. PADER reports do not consider the active dates.
When you configure the Aggregate Report (DSUR, PBRER, or PSUR), 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 setting.
Note Aggregate Reports evaluate the Active Range on a product's Core Datasheet only. Local Datasheets are not evaluated.
