Configuring Safety-EDC Connection Studies

The safety integration between Veeva EDC and Veeva Safety is based on the exchange of proprietary communication of the Veeva Vault platform. Appropriate integration configuration will send all required and complimentary safety-relevant EDC data to the safety system as safety cases. Examples which can result in the transfer include serious adverse events, adverse events of special interest as well as an unexpected pregnancy in a trial.

With the integration setup against a study design, any time a site creates an event that meets the criteria for a safety case initiation, Veeva EDC automatically generates a first-send and transmits the data to the safety system.

Related data can also be inserted into a safety case, by classifying those locations as one of these safety data types:

  • Study Drug (product, or products under test in the clinical trial)
  • Concomitant Medications
  • Medical History
  • Drug History
  • Test Results
  • Patient Characteristics
  • In Case of Death

Any updates to the safety case initiating or related data will automatically generate a follow-up send to be transmitted to the safety system in the given time interval.

Study designers configure this integration by mapping EDC study design Items to the appropriate Veeva Safety location. The inclusion of the mapped casebook elements into the safety case is additionally dependent on the configured inclusion rules, which give the option to include the mapped Items on all casebook Forms of a subject, those linked by the site to the safety case initiating form or that fall into a selected date range in relation to the initiating event.

The safety case can be created due to a single event or can be composed of multiple events. This is configured using site linking and/or date base inclusion rules.

Safety integrations also support nullifications, which happens if the criteria that initiated the initial transfer are no longer true. Examples include form reset (mistaken entry), or downgrade of an event.

Key differentiators between Safety-EDC Connection and E2B Link:

  • Safety-EDC Connection does not wait for an Acknowledgement file from the remote system on each send. Instead, an arrival in Vault Safety - its Inbox - is noted in Veeva EDC regardless of any further promotion to a case. Later, if promoted to a formal safety case through normal triage process, the case location will be noted in Veeva EDC.
  • Additionally to the actual data transferred as part of the safety case, all safety-relevant data of a trial participant mapped to the standard Safety Data Types is sent to Veeva Safety, once the first safety event occurs. This data can be displayed as required for the safety case processing in Veeva Safety as Additional Subject Information. Changes to data in EDC will result in updates to both safety case data as well as additional subject information in Veeva Safety. While “in case” data changes will create a follow-up Inbox item, updates to additional subject information will be performed in the background without alterations to the case The Veeva Safety user has easy access to anything mapped to the standard Safety Data Types ‘not in case’ through the Additional Subject Information user interface in Veeva Safety and can select / de-select content as per any medical decision, without ever having to leave that system, which consequently will be honoured in the follow-up transfers by Veeva EDC.
  • Actions in Veeva Safety are communicated back to Veeva EDC. Particularly the case status to show to sites and CRA as well the safety decisions taken in Veeva Safety. In Veeva Safety, additional subject information can be added to a safety case by simple selection. Similarly, subject information can also be removed from the case. In another scenario, a safety case can contain several events when sent from Veeva EDC, which can be split into individual cases on the Safety side, or individual safety cases can be merged into one. Veeva EDC is now aware of those decisions taken in Veeva Safety. While the EDC clinical data and site linking decisions remain unchanged, the decision taken in Veeva Safety about adding, removing, spitting or merging will be honored when compiling the next Follow-Up Send.

Safety administrators set the timing of the first-send and the frequency of any follow-ups, plus other operational settings for the integration. See Safety Settings in Managing Safety Integrations for details.

Prerequisites

A user with the Vault Owner security profile must create a connection between Veeva EDC and Veeva Safety.


Users with the standard CDMS Safety Administrator study role can perform the actions described below. If your vault uses custom study roles, your role must grant the following permissions:

Type Permission Label Controls
Standard Tab Studio Tab

Ability to access the Studio tab

Functional Permission Manage Safety Configuration

Ability to setup the mapping of Items in the study design to specific locations in Veeva Safety

If your Study contains restricted data, you must have the Restricted Data Access permission to view it.

Learn more about Study Roles.


Safety Integration Type

The first step in configuring safety integrations for Veeva EDC is the Safety Integration Type value in your study settings.

  1. Navigate to your Study in Studio > Study Settings.

  2. Click Edit in the middle (“General”) section:

  3. Select Vault Safety-EDC Connection.

  4. Click Save.

The Safety Integrations Type setting will be read only once it has a non-empty value. This is due to the nature of Safety-EDC Connection style integration versus the E2B Link. Should you need to toggle between the two, contact a Veeva representative for assistance and planning.

For more information on safety integrations using E2B, see Configuring E2B Studies.

Once the overall integration type is saved, additional options will appear in the Studio navigation menu: Safety Settings and Form Configurations:

Safety Settings

To set the integration type:

  1. Navigate to Studio > Safety Settings for your Study.
  2. Click Edit.
  3. Make your changes. The table below lists the available case settings.
  4. Click Save.

The following settings are available:

Setting Default Value Description
Subject ID Location Patient Name or Initials

Select the location in which the Veeva EDC Subject ID will be transferred for the current study:

  • Patient Name or Initials
  • GP Medical Record Number
  • Specialist Record Number
  • Hospital Record Number
  • Investigational Number
Subject ID Format Subject Only

Select the format for the Subject ID from the following:

  • Subject Only
  • Site-Subject (Site Number-Subject ID)
  • Country ISO-Site-Subject (2-letter Country Code-Site Number - Subject ID)
Primary Source Qualification Value Physician

The Classification is of the person assessing the study drug or treatment, as it relates to each Event of a Safety Case. You can select from the following classification types:

  • Physician
  • Pharmacist
  • Other Health Professional
  • Lawyer
  • Consumer or Other Non Health Professional
Study Drug Classify when ConMed Suspect Always Suspect

This setting is only applicable when the study is configured to allow the data entry user to link forms classified Concomitant Medications to the Safety Case Initiation Event and override the default classification of “Concomitant”.

Example: If the user chooses SUSPECT as they link the medication, the use of Always Interacting will override all study drugs in the transfer to Interacting, where they were otherwise deemed Suspect by the system.

The available choices:

  • Always Suspect
  • Always Interacting
Study Name Value

Optional: You can define a Study Name to use in the transfer. When left blank, Vault sends the Study Label.

Sponsor Study Number Value

Optional: You can define a Sponsor Study Number to use in the transfer. When left blank, Vault sends the Study Label.

Study Type Clinical trials

Select the Study Type of the Reaction (C.5.4) from the following options:

  • Clinical trials
  • Individual patient use
  • Other studies
Reporter Full Site Information

This is the value for the Reporter field on the Safety Case. The reporter locations will populate based on the information defined for the Site in Veeva EDC. Select from the following options:

  • Full Site Information
  • Principal Investigator (Vault uses the Principal Investigator assigned to the Site.)
  • None
NullFlavor for Coding

Select how to handle null values for coding (when there is no MedDRA coding value. This setting only applies to locations in your Veeva EDC study design where the form is enabled for coding and you have assigned a location for the safety transfer. Select from the following options:

  • None
  • 10067482
  • 99999999

Coding for the connection is located in each of the following locations, by safety data type:

  • Safety Case Initiation Event: Event Reported
  • Medical History: Medical History Reported
  • In Case of Death: Cause of Death - Reported (Autopsy reported or other reported use the same field name for mapping.)
  • Test Results: Test Name
  • Concomitant Medications: Indication Reported

Note: It isn’t necessary to map the tandem field for each of the above (each below the Safety Field List, and noted with “…(Coding LLT)”). Those mapping rows are only used in special cases. For more information, see the relevant Item Configurations section later in this reference.

Mute Coding Follow-ups No

When set to Yes, this setting stops Vault from sending follow-ups when the only change is the assignment of a new or different code to a medical term coded in Veeva EDC (Events, Medical History, Death Causes). Any other change to the data that is part of the safety case will still initiate a follow-up send.

When set to No, Veeva EDC sends follow-ups for safety cases for any change to data that is part of the safety case, including any changes to coding of medical terms.

If you primarily perform coding in the safety system, it is recommended to set this option to Yes to prevent unnecessary follow-ups for changed coding assignments to the safety system.

Datetime Value Behavior Use Screen / Entered Value

When configuring safety data against datetime fields on an EDC form, this option indicates which value to send. You can choose from Use Screen / Entered Value to use the value as entered by the site, or you can choose Use Normalized (UTC) Value to use the datetime normalized to UTC using the site time zone, offsetting the screen value.

Days Before SAE Start for Local Lab Test

This setting is only applicable when the study is using the Local Labs module (enabled in Studio’s study settings).

Enter the number of days before the Start Date for the Safety Case Initiating Event to search for lab tests. When set, this implies that local lab tests (all forms) should be searched and the tests sent to the safety system for review. These tests don’t appear in any case upon transfer, instead, they are reviewed for medical decisions to include in specific cases.

This field allows a number value (as days) from 0 to 21.

Days After SAE Start for Local Lab Tests

This setting is only applicable when the study is using the Local Labs module (enabled in Studio’s study settings).

Enter the number of days after the Start Date for the Safety Case Initiating Event to search for lab tests. When set, this implies that local lab tests (all forms) should be searched and the tests sent to the safety system for review. These tests don’t appear in any case upon transfer, instead, they are reviewed for medical decisions to include in specific cases.

This field allows a number value (as days) from 0 to 7.

Auto Set Medically Confirmed No

This setting determines the inclusion of “Medical Confirmation by Healthcare Professionals” in the safety case, and for every case Veeva EDC transmits. Select Yes to include. If you select No, a value is omitted from the transfer. The most common use for this is Yes, since the safety cases are originating from a clinical site / investigator.

Include Secondary Event Site Links to Case

Using Yes for this setting will include related data linked to secondary events of the case, not just the primary safety case initiating event.

Form Configurations

After updating your main Safety Settings, the next step is to configure which forms from your study’s design will participate in the safety integration. These are set up in Studio > Form Configurations. Note that this area only becomes available after you configure your settings.

You must create a Form Configuration for your Serious Adverse Event (Safety Case Initiation Event) form and any other Form that you want to use to send data to the safety system. Create Form Configurations from Studio > Form Configurations.

An exmaple of a study’s summary list of configured forms:

For each Form Configuration, there are three steps:

  1. Form Properties: Define the Form Properties, including the form type and the key item.
  2. Item Configurations: map safety fields to their corresponding Items.
  3. Inclusion Criteria: Define the inclusion criteria Vault will use to determine the form data included in the send to the safety system.

Safety Form Types

Each form configured for safety integration includes a Safety Form Type. These types represent the standard data model/type in any safety system.

The safety configuration types for Veeva EDC are summarized as follows. For those familiar with E2B format (R3), the relevant section is noted:

EDC Type Relevant E2B (R3) Location Veeva Safety Notes
Safety Case Initiation Event E.* Adverse Events

Forms of this type (formerly known as Serious Adverse Event) initiate the transfer of a Safety Case. Cases will receive a nullification if a previously sent case no longer satisfies the criteria for initial send.

A Safety Case can include data only from the primary event or from several different event forms, even non-serious events, depending on the configured inclusion criteria.

In a safety system and safety case, these are referred to as Events.

Study Drug G.* Products / Product Dosages

Use this type for each EDC form tracking the dispense of the study drug or product in your Study. In the safety system, these are referred to as Products, with one or more Dispenses/Dosages grouped within.

Depending on the inclusion criteria for the Study Drug, EDC will include study drug dispenses in relation to the Events of the case. Site linking to important study drug dispenses is not supported, in order to allow a comprehensive transfer of relevant study drug dispense occurrences, independent of site user action.

Concomitant Medications G.* Products / Product Dosages

These forms track other medications or products given to a Subject that aren’t necessarily a part of the study’s protocol.

In the safety system and case, these are also referred to as Products, with one or more Dispenses/Dosages grouped within.

Medical History D.7.* Medical History & Concurrent Conditions

These forms track historical conditions or procedures for a Subject, typically before entry into the Study.

Drug History D.8.* Drug History

These forms track historical medication use by a Subject, typically before entry into the Study.

Test Results F.* Test Results

These forms track specific lab and diagnostic results for the Subject that are deemed relevant to the events they are experiencing.

Patient Characteristics D.1 through D.6 Patient

This form tracks the general characteristics of the Subject, such as date of birth or sex.

In Case of Death D.9.* Patient or Causes of Death

In the event of the subject’s death, this form tracks information related, such as date of death or cause of death - reported.

How to Create a Form Configuration

To create a new Form Configuration:

  1. Navigate to Studio > Form Configurations for your Study.
  2. Click + New Form Configuration.

  3. Proceed with the three steps (tabs) of configuration, clicking Save and Next to progress through the steps.

  4. When finished, click Save and Close.

Missing Button: If you have the required permissions, but you don’t see the + New Form Configuration button, ensure that your Safety Settings are saved first.

The options for Form Properties, Item Configurations, and Inclusion Criteria are described in detail in the later sections of this documentation by safety type.

At each step, the Save button will save that information without advancing to the next step. The Save and Next button will save the information and move forward to the next step.

Remove Form Configurations

You can remove a single Form Configuration or remove all Form Configurations at once to start over. If you have Safety Cases associated with a Form Configuration, Vault disables the delete option.

To remove a single Form Configuration:

  1. Navigate to Studio > Form Configurations for your Study.
  2. Hover over the Form Configuration Name to show the Actions menu.
  3. Select Delete.
  4. In the confirmation dialog, click Delete.

Form Properties

The first step in your Form Configuration is Form Properties. Once you select your Safety Type from the drop-down menu, general properties are available for configuration. These vary by form type.

Safety Form Type Properties
Form Safety Key Item Each Entry In Product Info Description
Safety Case Initiation Event * * *  
Study Drug * * * *
Concomitant Medications *   *  
Medical History *   *  
Drug History *   *  
Test Results *   *  
Patient Characteristics *      
In Case of Death *      

* Indicates that this property is present required for the form type.

Indicates that this property is present optional for the form type.

  • Form requires the selection of the EDC form for mapping to the safety-relevant items.
  • Safety Key Item is a special property that evaluates whether the form is considered for case initiation or inclusion before any other criteria. For the Safety Case Initiation Event type, it drives the initial send (or later nullification) of the overall case. For the Study Drug type, it’s the initial criteria for inclusion before other date based criteria are evaluated.
  • Each Entry In is a setting to indicate how to group information into the various safety data types based on how the EDC form is designed. Examples and further details can be found in the next section. This is crucial to understand for proper safety configurations.
  • Product Info is information about the known study drug of the trial, name, blinding (or not), indication, which study group it applies.
  • Description is optional helpful text for the study designer.

Safety Key Item / Value

The Form Properties settings Safety Key Item and Safety Key Item Value evaluate the initiation of a case or the form inclusion into a case. They apply to these safety types:

  • Safety Case Initiation Event - when the system evaluation is true, the first transfer to a safety system is being initiated. Conversely, when the system deems the evaluation false and a previous safety case was transmitted, a nullification will be sent to the safety system
  • Study Drug - when the system evaluation is true, the dispense information on the form is deemed eligible for inclusion into the case. Further evaluation of the study drug inclusion criteria will finally determine the data transfer with the safety case.

Note that for the reference of the Safety Key Item Value to a Codelist will require the specification of the codelist code, not codelist label.

Here are several common examples for the Safety Case Initiation Event type:

Example 1

The Safety Key Item refers to the Codelist Item “AESER” and expects the Codelist Code “Y” to initiate the safety case:

The Safety Key Item refers to the following item on the AE form. Note that the Safety Key Item Value requires the Codelist code whereas the site user will choose from the Codelist labels:

  • The first submit of such a form with this prescribed answer will make the form eligible for a safety transfer of the form, plus any related data.
    • The transfer will happen at the timing configured. See Safety Settings in Managing Safety Integrations for details.
    • Additionally, for the transfer to proceed, the safety field Event Reported must also have a non-empty value on the form.
  • This example uses the serious question on the adverse event form to drive sending a safety case (or not). This field - in any study/form design - is also usually mapped to the safety field Serious

At some time after the first send to safety, either of these conditions could no longer be fulfilled. (e.g. Serious = No, or lack of Event Reported value). If so, the system will automatically send a Nullification follow-up to the safety system indicating it is no longer qualified as a safety case. No specific site action is necessary, regarding the safety integration, once the site user modifies the form data.

Example 2

Example 1 used the serious question as the Safety Key Item. However, any field can be used for the purpose, even one not used to map to a safety transfer location.

In this example, we instead use a more general more general question from the AE form:

While this is not the main serious question on the form, it allows to initiate a safety case for both a serious adverse event as well as an ‘Adverse Events of Special Interest’ (AESI), which might be non-serious, but still require data to be sent to the safety system.

Example 3

In the following example, the safety case initiation, and nullification, is more transparent for the site user, while still using one Safety Key Item value:

The following options are available in the codelist item:

  • New Safety Case (its codelist code): This is used for the Safety Key Item. Consequently, only this selection will initiate a safety case.
  • Link to an Existing Case: When answered, this code will evaluate the Safety Key Item Value to false. Thus, the form won’t initiate a standalone / additional case. Instead design rules would be used to ensure the site user links the current form to another event that initiated a safety case.
  • No Longer..: This would be used for an event that did qualify previously for a safety case and was transferred. While the site user indicates a downgrade or nullification, the EDC system will evaluate the codelist code of this selection to false. This will result in a nullification follow-up for the previously initiated safety case.

Each Entry In - Design Considerations

The Each Entry In concept on the Form Properties of a safety form configuration is key to the configuration for the data transfer. It specifically tells Veeva EDC to either consider the data on a (repeating) form or the data on a repeating item group on a form. The option has two choices:

  • Form: Data entered on a form in non-repeating item groups is considered for transfer. The form can be repeating to e.g. allow for multiple events in a study, however, the item groups on the form must not be repeating.
  • Repeating item group in form: Data entered in a repeating item group on a form is considered for transfer. In this case, multiple events would be represented by each repeat of the item group rather than a form repeat.

Some item configurations on the form will have different available choices, from the from Each Entry In form property. Most item configurations of the type are meant as a ‘single entry’, but some outliers are required to be non-repeating only, or, no restriction (repeating or non-repeating items). Refer to the sub-sections by type, later in this page, for detailed information on the outliers.

Each Entry In: Form

Veeva best practice for study design with a safety integration recommends using repeating forms throughout the different safety types:

In the example:

  • Adverse Event form - whether non-serious or serious - uses the same form design. This avoids the upgrade / downgrade issue for site users, having to move it from one location (non serious AE form) to another (serious, SAE form), and vice versa.
  • If multiple event safety cases are to be managed by EDC users, use inclusion of other serious or non-serious events to a primary event via date rule and/or specific site linking.
  • The other safety data types are each repeating forms, except for singular answer information (Patient Characteristics and In Case of Death). Note that ‘repeating forms’ in this sense is either:
    • The form is defined as repeating (e.g. a log form)
    • Or, its a non-repeating form that occurs across the study visit schedule (e.g. Study Drug in Visit 1, then Visit 2, and so on)
  • Depending on the study need, site opinion (linking) and/or date based inclusion rules can include the appropriate related data across the different types.

An example study using this configuration, and the safety data types applied to forms of the study design:

Custom Fields: With the Safety-EDC Connection, custom / configured fields in Veeva Safety can be used to extend the possible forms / data for transfer.

Each Entry In: Repeating Item Group vs. Form

Consider this study as example of using both options for Each Entry In:

  • The form Subject History / Therapies asks a few non-repeating questions in the first item group:
    • When answering Yes to Specific Medical History Detail to Report?, a dynamic rule (on form submit) opens up the next form in the schedule - Medical History Details. Forms entered there comprise a medical history entry, per form.
    • When answering Yes to Concomitant Therapies if Enrolled?, progressive display is used to show a repeating item group on the same form. Entries for medical history are entered as - each - a repeating item group in that same form, as necessary.
  • The form Medical History Details repeats, but has all non-repeating item groups / questions contained in its design, thus Each Entry In = Form
  • In the pictured example above, the safety configuration that would consider there to be four (4) medical histories for the safety case is:
    • Form CTHERAPY (Subject History / Therapies):
      • Type = Medical History
      • Each Entry In = Repeating item group in form
    • Form MH (Medical History Details):
      • Type = Medical History
      • Each Entry In = Form

Each Entry In: Repeating Item Groups for Events

For studies that will track multiple events in a safety case in one EDC form design, the approach looks like this:

  • The safety case would initiate per just the existence of the form with the events.
  • This study design will require Each Entry In = Repeating Item Groups, and tracks only serious events. The serious question being answered (usually) Yes initiates the transfer to safety.

Nullifications

Follow-ups are sent by Veeva EDC whenever data changes happen that reside in a safety case. Nullification is a special kind of follow-up that has these properties:

  • It happens when either of these is the case:
    1. The Safety Key Item and Safety Key Item Value evaluation becomes false
    2. Or, the value of the item on the EDC form for Event Reported safety field location becomes empty
  • It will be noted as a nullification type in the next message to Veeva Safety
  • It is the last send for a safety case to the safety system
  • Note: The first send for the case occurred previously. Veeva EDC will re-evaluate the two conditions above at first send (i.e. after the initial send timer) and do an immediate nullification of the safety case without a send to the safety system. This will happen most commonly when the site user makes a mistake, resets the form, etc before the timer for the first send ends.
  • Safety reporting generally requires a nullification reason on such a transfer. The study can be configured to ask the site user. If it is not configured for site answer or the site fails to answer, the system will use a default reason: “The case no longer satisfies conditions from when it was initially sent. This can include events now downgraded to non serious, or user action removing all events.”

Common examples of nullification:

  • Reset of EDC form
  • Intentionally Left Blank on the EDC form after previous form submission
  • “Downgrade”, e.g. what used to satisfy a safety case via Safety Key Item/Value, is no longer the situation, but the event still persists

Once a nullification occurs for a safety case in Veeva EDC, it will not revert back to an active safety case. Should that same form be changed to make the Safety Key Item / Value true and Event Reporter safety field non-empty in value once more, a new safety case is created and sent. The original safety case does not resume.

Form Properties by Safety Data Type

These sections describe the Form Configuration step for each Safety Data Type.

Safety Case Initiation Event

The form configuration of this safety data type is critical to initiate the process of transferring a safety case. All other safety data types are then brought into the case per their configured rules. Events will appear in this section in Veeva Safety:

The Veeva Safety EDC Connection allows you to have multiple Forms configured as Safety Case Initiation Events. This allows for increased flexibility in the design of your adverse event forms. With this feature, you can have separate forms for a Serious Adverse Event and other circumstances that must be reported to the safety system, such as a pregnancy.

To configure your Safety Case Initiation Event form:

  1. Navigate to Studio > Form Configurations for your Study.
  2. Click + New Form Configuration.
  3. Select Safety Case Initiation Event for Safety Data Type.
  4. Select the Form.
  5. For Each Entry In, select which method to determine individual cases:
    • Form: Select this option to treat each instance of the Form as its own case.
    • Repeating item group in form: Select this option to treat each instance of the repeating Item Group as its own case.
  6. Optional: Enter a Description.
  7. Select the Safety Key Item. This is typically the Item that indicates seriousness.
  8. Define the Safety Key Item Value. Select from one of the following:
    • Specify value: With this option, you must enter a specific value to match on. Note that for codelist-type Items, you must provide the Code for the codelist item, not the Label.
    • Any non empty value: This option considers any non-empty value a match.
  9. Click Save or Save and Next to proceed to the Item Configuration step.

The Safety Form Type, Form, and Each Entry In settings will be read only once initially saved. Additional configuration at the Item Configurations and Inclusion Criteria tabs rely on these settings. To change any of these settings, the form configuration must be deleted and created again.

Study Drug

This safety data type is used to track dosing / dispensing information of a study drug, i.e. those the clinical study is testing against subjects. The information will flow to the Products / Product Dosages section of Veeva Safety. The example below shows two drugs.

Multiple Forms: You can configure multiple Form Definitions with the Study Drug safety data type.

To include data from a Study Drug form (formerly labeled Treatment):

  1. Navigate to Studio > Form Configurations for your Study.
  2. Click + New Form Configuration.
  3. Select Study Drug for Safety Data Type.
  4. For Each Entry In, select which method to determine individual study drugs:
    • Form: Select this option to treat each instance of the Form as its own study drug.
    • Repeating item group in form: Select this option to treat each instance of the repeating Item Group as its own study drug.
  5. Enter the Study Drug Name. This value should be a match to how the drug is named in Veeva Safety. Mismatches will not stop the transfer / flow, but synchronization will eventually be necessary
  6. Select Yes or No for Blinding. Indicate whether the study drug is considered Blinded (or not) in the trial. This property is only an indication and used for reporting purposes only. All data is transferred unblinded to the safety system, even if a restriction applied to the data in EDC.

  7. Optional: You can choose to only include this form in the case when the Subject is in a certain Subject Group. Select a Group for Only Include When Subject Group Is to do so. Any subject not in the selected group will not have the study drug form in their transfer. When this field is blank, Vault includes the form for all subjects when the inclusion criteria are met.

  8. Optional: Enter a Description.
  9. Select the Safety Key Item. This is typically the Item indicating that the dispense was performed. For the study drug type, the evaluation is used to consider a form/dispense eligible for inclusion in the transfer. Any additional inclusion criteria are also evaluated to include the appropriate dispenses of the study drug in the safety case.
  10. Define the Safety Key Item Value. Select from one of the following:
    • Specify value: With this option, you must enter a specific value to match on.
    • Any non empty value: This option considers any non-empty value a match.
  11. Click Save or Save and Next to proceed to the Item Configuration step.

The Safety Form Type, Form, and Each Entry In settings will be read only once initially saved. Additional configuration at the Item Configurations and Inclusion Criteria tabs rely on these settings. To change any of these settings, the form configuration must be deleted and created again.

Concomitant Medications

This type of safety configuration is applied to concomitant medication forms of the study. The information will flow to the Products / Product Dosages sections of Veeva Safety. The example below shows Aspirin and Advil.

Multiple Forms: You can configure multiple Form Definitions with the Concomitant Medication safety data type.

To include Concomitant Medications:

  1. Navigate to Studio > Form Configurations for your Study.
  2. Click + New Form Configuration.
  3. Select Concomitant Medication for Safety Data Type.
  4. For Each Entry In, select which method to determine individual ConMeds:
    • Form: Select this option to treat each instance of the Form as its own ConMed.
    • Repeating item group in form: Select this option to treat each instance of the repeating Item Group as its own ConMed.
  5. Optional: Enter a Description.
  6. Click Save or Save and Next to proceed to the Item Configuration step.

The Safety Form Type, Form, and Each Entry In settings will be read only once initially saved. Additional configuration at the Item Configurations and Inclusion Criteria tabs rely on these settings. To change any of these settings, the form configuration must be deleted and created again.

Medical History

This type of safety configuration is applied to medical history forms of the study. The information will flow to the Medical History & Concurrent Conditions section of Veeva Safety.

Multiple Forms: You can configure multiple Form Definitions with the Medical History safety data type.

To include Medical History:

  1. Navigate to Studio > Form Configurations for your Study.
  2. Click + New Form Configuration.
  3. Select Medical History for Safety Data Type.
  4. For Each Entry In, select which method to determine individual medical history events:
    • Form: Select this option to treat each instance of the Form as its own history
    • Repeating item group in form: Select this option to treat each instance of the repeating Item Group as its own history.
  5. Optional: Enter a Description.
  6. Click Save or Save and Next to proceed to the Item Configuration step.

The Safety Form Type, Form, and Each Entry In settings will be read only once initially saved. Additional configuration at the Item Configurations and Inclusion Criteria tabs rely on these settings. To change any of these settings, the form configuration must be deleted and created again.

Drug History

This type of safety configuration is applied to drug history forms of the study. The information will flow to the Drug History section of Veeva Safety.

Multiple Forms: You can configure multiple Form Definitions with the Drug History safety data type.

To include data from a Drug History form:

  1. Navigate to Studio > Form Configurations for your Study.
  2. Click + New Form Configuration.
  3. Select Drug History for Safety Data Type.
  4. For Each Entry In, select which method to determine individual drug histories:
    • Form: Select this option to treat each instance of the Form as its own drug history.
    • Repeating item group in form: Select this option to treat each instance of the repeating Item Group as its own drug history.
  5. Optional: Enter a Description.
  6. Click Save or Save and Next to proceed to the Item Configuration step.

The Safety Form Type, Form, and Each Entry In settings will be read only once initially saved. Additional configuration at the Item Configurations and Inclusion Criteria tabs rely on these settings. To change any of these settings, the form configuration must be deleted and created again.

Test Results

This type of safety configuration is applied to lab / test result forms of the study. The information will flow to the Test Results section of Veeva Safety.

Multiple Forms: You can configure multiple Form Definitions with the Test Results safety data type.

When using the local lab module module (lab panels) in Veeva EDC, forms are not specifically set up with additional safety configuration. Instead, all tests where the lab date is near the safety case’s start are sent to Veeva Safety for review. There, Veeva Safety users can include specific tests into cases per medical review. The range of days around the case is configured in your study safety settings.

To include data from Test Results:

  1. Click Edit if you aren’t already in Edit mode.
  2. Click Test Results to expand that section.
  3. For Include Test Results, select Yes.
  4. Select the Test Results Form.
  5. Select the Item for each field that you include in your form. Note that the Item must have the correct data type. See the table below for a list of Items and their expected Data Type.
  6. Click Save or Save and Next to proceed to the Item Configuration step.

The Safety Form Type, Form, and Each Entry In settings will be read only once initially saved. Additional configuration at the Item Configurations and Inclusion Criteria tabs rely on these settings. To change any of these settings, the form configuration must be deleted and created again.

Patient Characteristics

This type of safety configuration is applied to general information about the subject. The information will flow to the Patient section of Veeva Safety.

Multiple Forms: You can configure multiple Form Definitions with the Patient Characteristics safety data type. For example, you may collect a Sex item on one form and a Date of Birth item on another.

To include Patient Characteristics:

  1. Navigate to Studio > Form Configurations for your Study.
  2. Click + New Form Configuration.
  3. Select Patient Characteristics for Safety Data Type.
  4. Optional: Enter a Description.
  5. Click Save or Save and Next to proceed to the Item Configuration step.

The Safety Form Type, Form, and Each Entry In settings will be read only once initially saved. Additional configuration at the Item Configurations and Inclusion Criteria tabs rely on these settings. To change any of these settings, the form configuration must be deleted and created again.

In Case of Death

This type of safety configuration is applied to forms involving death details about the subject. Some fields for this type must be non-repeating (e.g. Date of Death), others can be repeating or non-repeating (causes of death). Information will flow to two places in Veeva Safety, Patient or Causes of Death.

Multiple Forms: You can configure multiple Form Definitions with the In Case of Death safety data type.

To include data from an In Case of Death form:

  1. Navigate to Studio > Form Configurations for your Study.
  2. Click + New Form Configuration.
  3. Select In Case of Death for Safety Data Type.
  4. Optional: Enter a Description.
  5. Click Save or Save and Next to proceed to the Item Configuration step.

The Safety Form Type, Form, and Each Entry In settings will be read only once initially saved. Additional configuration at the Item Configurations and Inclusion Criteria tabs rely on these settings. To change any of these settings, the form configuration must be deleted and created again.

Item Configurations

The second step in a safety form configuration is the Item Configurations tab. As an example, this AE (Adverse Events) form design has been classified as the Safety Case Initiation Event.

The purpose of this grid is to assign answers from the form design (Item Definitions) to the appropriate location of Veeva Safety.

This table summarizes the columns in the grid:

Column Notes
Safety Field Label of the field. This generally matches the label of the destination field in Veeva Safety.
Type The data type at that location. This column may also list a character limit in parentheses.
Value Required for First Send

This column only applies to forms with the Safety Case Initiation Event safety data type.

This column’s checkbox indicates whether a configured Item must have an entered value on the data entry form to start the initial transfer of the Safety Case If the checkbox is selected, the item is required.

For the Event Reported row, the checkbox is automatically selected and isn’t editable. A Safety Case can’t begin the transfer or be tracked without this verbatim field having a non-empty value.

Configured Item

Select the Item (Item Definition) from the form design that you want to map to this Safety Field.

The available options will generally depend on the selection for Each Entry In in the Form Properties step.

  • If you selected Form for Each Entry In, the available items are those not in a repeating item group.
  • If you selected Repeating item group on form for Each Entry In, the available items are those items within a repeating item group.

Some safety fields do allow for locations in both repeating and non-repeating item groups, no matter the value for Each Entry In. Those locations are identified in the detail section for each safety data type below.

When using a repeating item group, ensure that all Item Definitions that comprise an entry (e.g. Medical History, Lab, etc.) are in the same repeating item group. Some safety fields may be outside that same repeating item group, but it is the rare exception. Those outliers are identified in the detail section for each safety data type below.

Value Translations When the Item Definition data type is Codelist or Boolean (checkbox), configuration of the EDC value to the value expected by Veeva Safety is required. If you don’t set this for those data types, Studio validation will indicate an error, preventing deployment.
Static Value

Many safety field locations allow for the inclusion of a static value in the transfer. This is indicated in the form data type / field by field sections.

Allowing static values eliminates the need to include additional items on a form that otherwise are derived to static values, just to have the value in the safety transfer.

Paired Date

Some safety field definitions will transfer every non-empty value across the Subject Casebook. Veeva Safety figures the closest on or before across those values for the value in the Safety Case. Examples include Weight, Height, and Last Menstrual Date.

The date paired with the values is either a date-type item on the form, or an indication of the Event Date for the event the form resides in. For example, if the Weight safety field is mapped on the Vitals form, then the Event Date and the Vitals Date item from the Vitals form would be available for Paired Date.

Study Drug

This column only applies to forms with the Safety Case Initiation Event safety data type.

For any Item where answer value relates to the study drug instead of the event, an Item Definition can be paired with the specific Study Drug to which the answer applies. This applies to the following safety fields:

  • Action Taken with Study Product
  • Did Reaction / Event Recur when Study Drug Resumed
  • Result of Assessment to Study Drug
  • Source of Assessment to Study Drug
  • Method of Assessment to Study Drug
Item to Form Link

This column only applies to forms with the Safety Case Initiation Event safety data type.

When the row is mapped to an Item Definition, the Item must reside in a repeating Item Group where an Item to Form Link item also resides. The selection is the specific Item to Form Link that the main item configuration pairs with.

The intent of this field is to answer questions while one links to a remote form (each) from the Safety Case Initiation Event form.

Currently, the only form with this behavior is Concomitant Medication Drug Role.

Value Translations

Whenever the Item Definition being mapped to safety is Codelist or Boolean (Checkbox) and the location requires very specific values, Value Translations must be set up to ensure the transfer works correctly.

  1. Select the Item Definition in the Configured Item column.
  2. Click into the cell of the Value Translations column. If a value translation can be configured, the cell will appear orange on hover over. This opens the Value Translations dialog.

  3. For each Codelist select the appropriate value in Veeva Safety.
    • Valid choices will be shown from that safety field/location.
    • If more Codelist entries are in the study design than available options, several Codelist entries can be mapped to the same value.
    • If any mapping is missing, the studio validations will show an error.
    • When a choice/label at the Veeva Safety location has an exact match (including capitalization) with the EDC Codelist Label, that selection will be pre-selected.
  4. For a Boolean safety location, the choices will be true / false, and at least one must be selected:

  5. For Boolean EDC Item Definitions one of the (checked) or (not checked) is mapped. For example,
    • The Seriousness Criteria location in safety is multi-value.
    • On the EDC form, a series of checkboxes can be used with ‘check all that apply’.
    • Below, if the ‘Results in Death’ checkbox is checked, this will be mapped to that value in Veeva Safety:
  6. When finished, click Save.
  7. Once value translations have been specified, the number of configured translations will be indicated in the cell.
  8. Repeat these steps for all locations that require specific values, per their own standards. The Studio validations job will indicate an error and prevent deployment if any of these are missing.

The translation values are only temporarily saved after this action. Subsequent use of Save or Save and Next at the tab level will save the translations.

Static Value

Some safety fields allow for a static value, instead of using a specific Item Definition of the EDC Form Definition. Refer to the form type sections below for field by field details, specifically which fields allow for configuration of a static value.

Examples:

  • Method of Study Drug Assessment: (free text value)

  • Age Unit: (safety controlled vocabulary as choices)

Paired Date

Some safety fields allow for the transfer of a series of values to Veeva Safety. Each value is paired with a date of that value. As an example, weight might exist on a Vitals form across the EDC study design. The connection will transfer all of the values for reference. For the case creation, Veeva Safety will automatically determine the value closest on/before the beginning of the case. Other values will be made available as additional subject information and are reviewable in Veeva Safety. The date paired with such values can either be the Event Date or value from another date-type Item Definition on that same form.

Refer to the item configuration by form type for field by field detail, specifically which fields allow for configuration in this manner.

Examples:

  • Vitals form, Field WEIGHT, uses the Event Date of where the form resides for the paired value:

  • A different Vitals form, Field HEIGHT, uses a date value on that same form (VSDT):

Study Drug Association

Safety fields on the form classified as Safety Case Initiation Event that ask questions about Study Drug must also indicate the specific Study Drug the answer applies.

Refer to the item configuration by form type for field by field detail, specifically which fields must be answered ‘for each study drug’.

Example:

  • For a study that has two study drugs defined:

  • Answers to important event vs. study drug questions - Action Taken with Study Product, Result of Assessment to Study Drug, Did Reaction / Event Recur when Study Drug Resumed - are configured, answer for each of the study drugs:

  • The static value above is also set for each (instead of an item on the form) for Source of Assessment to Study Drug.

Currently, just one Item Configuration involves the relationship between an Item to Form Link type of Item Definition and answer given ‘with the link’. Specifically, the field on the Safety Case Initiation Event data type, Concomitant Medication Drug Role:

The answer given on the EDC form involves site opinion on a concomitant medication. For a specific safety case / event, the site would link to it, but give a different opinion/answer (from concomitant), Interacting or Suspect. Above, the Item Definition AE_CM_LINK_DRUG_ROLE is that question, with value translations:

Because multiple Item to Form Links could be present on the Safety Case Initiation Event form design, the specific Item to Form link must be selected. In this example, an Item Definition named AE_TO_CM_LINK:

By Safety Data Type

Safety Case Initiation Event

The form configuration of this safety data type is critical to initiate the process of transferring a safety case. All other safety data types are then brought into the case per their configured rules.

To perform the Item Configuration step for this safety data type:

  1. Navigate to the Form Configuration that you want to configure items for.
  2. Click the Form Name in the row to open it.
  3. Click Save and Next to open the Item Configuration step.
  4. For each row that you want to map, use the cell in the Configured Item column to select the appropriate Item Definition. For example, select the AETERM item from the form for the Event Reported in Veeva Safety field. The choices for item selection will usually depend on the Form Properties > Each Entry In setting previously saved. Some safety locations have special rules that indicate they can be done in only repeating or non-repeating item groups, or sometimes either. Refer to the table at the end of these steps for those outliers, plus important notes regarding all safety locations of this type.

  5. For each row that you want to map, select the Value Required for First Send checkbox to require this Item to have a value for first send. Otherwise, leave this checkbox clear.

  6. Depending on the data type of the Configured Item and the Safety Field, you may need to provide Value Translations. See the Value Translations section above for instructions.
  7. Depending on the Safety Field additional information may be required. Use the appropriate cell in the row to provide this information:
  8. When finished, click Save or click Save and Next to proceed to the Inclusion Criteria step.

CDMS Form Type Safety Field Safety Field Name Data Type Inbox Item/Case Object Inbox Item/Case Field
Serious Adverse Event Event Reported AE_EVENT_REPORTED Text (250) case_adverse_event__v

event_reported__v

Serious Adverse Event Event Reported (Coding LLT) AE_CODING_LLT Text (8) case_adverse_event__v

event_meddra__v

Serious Adverse Event Start / Onset Date AE_START_DATE Date/Datetime case_adverse_event__v

onset_idate__v

Serious Adverse Event End / Resolved Date AE_END_DATE Date case_adverse_event__v

resolved_idate__v

Serious Adverse Event Outcome AE_OUTCOME Mapped Value case_adverse_event__v

outcome__v

Serious Adverse Event Serious AE_SERIOUS Mapped Value case_adverse_event__v

highlighted_term__v

Serious Adverse Event Adverse Event of Special Interest N/A Boolean N/A

N/A

Serious Adverse Event Seriousness Criteria AE_SERIOUSNESS_CRITERIA Mapped Value case_adverse_event__v

seriousness__v

Serious Adverse Event CTCAE Grade AE_CTCAE_GRADE Mapped Value case_adverse_event__v

ctcae_grade__v

Serious Adverse Event Severity AE_SEVERITY Mapped Value case_adverse_event__v

severity__v

Serious Adverse Event Age at Onset AE_AGE_AT_ONSET Numeric (3) case_version__v

age_value__v (with age_calculation_status__v set to “Yes”)

Serious Adverse Event Age at Onset Unit AE_AGE_AT_ONSET_UNIT Mapped Value case_version__v

age_unit__v

Serious Adverse Event Country Event Occurred AE_EVENT_COUNTRY Text (2) case_adverse_event__v

event_country__v

Serious Adverse Event Symptom / Diagnosis AE_SYMPTOM_DIAGNOSIS Mapped Value case_adverse_event__v

symptom_diagnosis__v

Serious Adverse Event Expedited Event AE_EXPEDITED_FLAG Boolean case_adverse_event__v

expedited_flag__v

Serious Adverse Event Healthcare Professional Confirmed AE_HCP_CONFIRMED Boolean case_adverse_event__v

hcp_confirmed

Serious Adverse Event Hospital Admission Date AE_HOSPITAL_ADM_DATE Date case_adverse_event__v

hospital_admission_date__v

Serious Adverse Event Hospital Discharge Date AE_HOSPITAL_DISCHARGE_DATE Date case_adverse_event__v

hospital_discharge_date__v

Serious Adverse Event Days Hospitalized AE_DAYS_HOSPITALIZED Numeric (4) case_adverse_event__v

days_hospitalized__v

Serious Adverse Event Hospital Name AE_HOSPITAL_NAME Text (200) case_adverse_event__v

hospital_name__v

Serious Adverse Event Hospital City AE_HOSPITAL_CITY Text (35) case_adverse_event__v

hospital_city__v

Serious Adverse Event Hospital State AE_HOSPITAL_STATE Text (40) case_adverse_event__v

hospital_state__v

Serious Adverse Event Narrative AE_NARRATIVE Text (30000) case_version__v

narrative_text__v

Serious Adverse Event Reporter Comments AE_REPORTER_COMMENTS Text (20000) case_version__v

reporters_comments__v

Serious Adverse Event Sender Comments AE_SENDER_COMMENTS Text (20000) case_version__v

sender_comments__v

Serious Adverse Event Nullification Reason AE_NULLIFY_REASON Text (200) inbox_item__v

edc_reason__v (This only is available in the Inbox Item to indicate to the user that this is a nullification case and why. There’s no impact on the Case data model.)

Serious Adverse Event Reporter Qualification AE_REPORTER_QUALIFICATION Mapped Value case_contact__v

qualificiation__v

Serious Adverse Event Reported Language AE_REPORTER_LANGUAGE Text (20) case_adverse_event__v

event_reported_language__v

Serious Adverse Event Reporter First Name AE_REPORTER_FIRST_NAME Text (50) case_contact__v

firstname_value__v

Serious Adverse Event Reporter Last Name AE_REPORTER_LAST_NAME Text (50) case_contact__v

lastname_value__v

Serious Adverse Event Overall Action Taken N/A Mapped Value N/A

N/A

Serious Adverse Event Concomitant Medication Drug Role N/A Mapped Value N/A

N/A

Serious Adverse Event Action Taken with Study Product AE_PRODUCT_ACTION_TAKEN Mapped Value case_assessment_result__v

action_taken__v

Serious Adverse Event Did Reaction / Event Recur when Study Drug Resumed AE_PRODUCT_ACTION_RECUR Mapped Value case_assessment__v

reaction_recurrence__v

Serious Adverse Event Method of Assessment to Study Drug AE_PRODUCT_ASSESS_METHOD Text (60) case_assessment_result__v

method_of_assessment__v or method_text__v

Serious Adverse Event Result of Assessment to Study Drug AE_PRODUCT_ASSESS_RESULT Mapped Value case_assessment_result__v

assessment_result__v or result_text__v

Serious Adverse Event Source of Assessment to Study Drug AE_PRODUCT_ASSESS_SOURCE Text (60) case_assessment_result__v

source_type__v or source_text__v

Serious Adverse Event Pregnancy Case AE_PREG_CASE Boolean case_adverse_event__v

pregnancy__v

Serious Adverse Event Pregnancy Occurrences AE_PREG_INFO_GRAV Numeric (2) case_adverse_event__v

gravida_gravidity__v

Serious Adverse Event Number Given Birth AE_PREG_INFO_PARA Numeric (2) case_adverse_event__v

para_parity__v

Serious Adverse Event Pregnant at Study Drug Exposure AE_PREG_INFO_AT_VX Boolean case_adverse_event__v

pregnancy_at_vaccination__v

Serious Adverse Event Last Menstrual Date (Pregnancy Case) Date case_adverse_event__v

last_menstrual_idate__v

Serious Adverse Event Pregnancy Conception Date AE_PREG_INFO_CONC_DT Date case_adverse_event__v

pregnancy_conception_idate__v

Serious Adverse Event Pregnancy Due Date AE_PREG_INFO_DUE_DT Date case_adverse_event__v

pregnancy_due_idate__v

Serious Adverse Event Date of Pregnancy Outcome AE_PREG_INFO_OUTCOME_DT Date case_adverse_event__v

idate_of_pregnancy_outcome__v

Serious Adverse Event Pregnancy Outcome AE_PREG_INFO_OUTCOME Mapped Value case_adverse_event__v

pregnancy_outcome__v

Serious Adverse Event Delivery Method AE_PREG_INFO_DELV_METH Mapped Value case_adverse_event__v

delivery_method__v

Study Drug

This safety data type is used to track dosing / dispensing information of a study drug, i.e. those the clinical study is testing against subjects.

  • Currently the name of a study drug is configured in Studio at the Form Properties tab. An item configuration for drug name will be available in a future release
  • The important “Classification of Drug” is not an item mapped on the EDC form for this type. Instead, “Suspect” is set by the system when there is at least one dispense form on or before the event start date. If there are no dispenses, “Not Administered” is used by the system.

To perform the Item Configuration step for this safety data type:

  1. Navigate to the Form Configuration that you want to configure items for.
  2. Click the Form Name in the row to open it.
  3. Click Save and Next to open the Item Configuration step.
  4. For each row that you want to map, use the cell in the Configured Item column to select the appropriate Item Definition. For example, select the SD_START_DATE item from the form for the location Start Date. The choices for item selection will usually depend on the Form Properties > Each Entry In setting previously saved. Some safety locations have special rules that indicate they can be done in only repeating or non-repeating item groups, or sometimes either. Refer to the table at the end of these steps for those outliers, plus important notes regarding all safety locations of this type.

  5. Depending on the data type of the Configured Item and the Safety Field, you may need to provide Value Translations. See the Value Translations section above for instructions.
  6. Depending on the Safety Field additional information may be required. Use the appropriate cell in the row to provide this information:
  7. When finished, click Save or click Save and Next to proceed to the Inclusion Criteria step.
CDMS Form Type Safety Field Safety Field Name Data Type Inbox Item/Case Object Inbox Item/Case Field
Study Drug Start Date SD_START_DATE Date/Datetime case_product_dosage__v firstadmin_idate__v
Study Drug End Date SD_END_DATE Date/Datetime case_product_dosage__v lastadmin_idate__v
Study Drug Duration of Dispense Value SD_DURATION_VALUE Numeric with Precision (5,3) case_product_dosage__v duration_number__v
Study Drug Duration of Dispense Unit SD_DURATION_UNIT Mapped Value case_product_dosage__v duration_unit__v
Study Drug Dose Value (Number) SD_DOSE_VALUE_NUMBER Numeric with Precision (9,3) case_product_dosage__v dose_number__v
Study Drug Dose Value (Text) SD_DOSE_VALUE_TEXT Text (2000) case_product_dosage__v dose_text_long_text__v
Study Drug Dose Unit (Code) SD_DOSE_UNIT_CODE Mapped Value case_product_dosage__v dose_unit__v
Study Drug Dose Unit (Text) SD_DOSE_UNIT_TEXT Text (50) case_product_dosage__v dose_unit_text__v
Study Drug Frequency Value SD_FREQUENCY_VALUE Numeric with Precision (4,8) case_product_dosage__v frequency_number__v
Study Drug Frequency Unit SD_FREQUENCY_UNIT Mapped Value case_product_dosage__v frequency_unit__v
Study Drug Route (Code) SD_ROUTE_CODE Mapped Value case_product_dosage__v patient_adminroute__v
Study Drug Route (Text) SD_ROUTE_TEXT Text (60) case_product_dosage__v patient_adminroute_text__v
Study Drug Route Term ID SD_ROUTE_TERM_ID Text (50) case_product_dosage__v patient_adminroute_termid__v
Study Drug Route Term ID Version SD_ROUTE_TERM_ID_VERSION Text (50) case_product_dosage__v patient_adminroute_termid_version__v
Study Drug Site of Dispense SD_SITE_OF_DISPENSE Mapped Value case_product_dosage__v anatomical_site__v
Study Drug Batch / Lot Number SD_BATCH_LOT_NUMBER Text (35) case_product_dosage__v batchlot_number__v
Study Drug Dose Form Term ID SD_DOSE_FORM_TERM_ID Text (50) case_product_dosage__v dose_form_termid__v
Study Drug Dose Form Term ID Version SD_DOSE_FORM_TERM_ID_VERSION Text (50) case_product_dosage__v dose_form_termid_version__v
Study Drug Dose Form Text SD_DOSE_FORM_TEXT Text (128) case_product_dosage__v dose_form_text__v
Study Drug Parent Route (Text) SD_PARENT_ROUTE_TEXT Text (60) case_product_dosage__v parent_adminroute_text__v
Study Drug Parent Route (Code) SD_PARENT_ROUTE_CODE Mapped Value case_product_dosage__v parent_adminroute__v
Study Drug Parent Route Term ID SD_PARENT_ROUTE_TERM_ID Text (50) case_product_dosage__v parent_adminroute_termid__v
Study Drug Parent Route Term ID Version SD_PARENT_ROUTE_TERM_ID_VERSION Text (50) case_product_dosage__v parent_adminroute_termid_version__v

Concomitant Medication

This type of safety configuration is applied to concomitant medication forms of the study. The information will flow to the Products / Product Dosages sections of Veeva Safety.

To perform the Item Configuration step for this safety data type:

  1. Navigate to the Form Configuration that you want to configure items for.
  2. Click the Form Name in the row to open it.
  3. Click Save and Next to open the Item Configuration step.
  4. For each row that you want to map, use the cell in the Configured Item column to select the appropriate Item Definition. For example, select the CMTRT item from the form for the location Product / Medication Reported. The choices for item selection will usually depend on the Form Properties > Each Entry In setting previously saved. Some safety locations have special rules that indicate they can be done in only repeating or non-repeating item groups, or sometimes either. Refer to the table at the end of these steps for those outliers, plus important notes regarding all safety locations of this type.

  5. Depending on the data type of the Configured Item and the Safety Field, you may need to provide Value Translations. See the Value Translations section above for instructions.
  6. When finished, click Save or click Save and Next to proceed to the Inclusion Criteria step.
CDMS Form Type Safety Field Safety Field Name Data Type Inbox Item/Case Object Inbox Item/Case Field
Concomitant Medication Product / Medication Reported CM_REPORTED Text (250) case_product__v product_reported__v
Concomitant Medication Country Obtained CM_COUNTRY_OBTAINED Text (2) case_product__v country_obtained__v
Concomitant Medication Gestation Exposure Number CM_GESTATION Numeric with Precision (3,3) case_product__v gestation_exposure_number__v
Concomitant Medication Gestation Exposure Unit CM_GESTATION_UNIT Mapped Value case_product__v gestation_exposure_unit__v
Concomitant Medication Device Name CM_DEVICE_NAME Text (1000) case_product__v device_name_part__v
Concomitant Medication Device Evaluated CM_DEVICE_EVALUATED Mapped Value case_product__v device_evaluated__v
Concomitant Medication Device Usage Type CM_DEVICE_USAGE_TYPE Mapped Value case_product__v device_usage_type__v
Concomitant Medication Device Implanted Date CM_IMPLANTED_DATE Date/Datetime case_product__v date_implanted_idate__v
Concomitant Medication Device Explanted Date CM_DEVICE_EXPLANTED_DATE Date/Datetime case_product__v date_explanted_idate__v
Concomitant Medication Device Age CM_DEVICE_AGE Numeric with Precision (5,4) case_product__v date_age__v
Concomitant Medication Device Age Unit CM_DEVICE_AGE_UNIT Mapped Value case_product__v device_age_unit__v
Concomitant Medication Additional Information Coded CM_ADDITIONAL_INFO_CODED Mapped Value N/A N/A
Concomitant Medication Start Date CM_START_DATE Date/Datetime case_product_dosage__v firstadmin_idate__v
Concomitant Medication End Date CM_END_DATE Date/Datetime case_product_dosage__v lastadmin_idate__v
Concomitant Medication Duration of Dispense Value CM_DURATION_VALUE Numeric with Precision (5,3) case_product_dosage__v duration_number__v
Concomitant Medication Duration of Dispense Unit CM_DURATION_UNIT Mapped Value case_product_dosage__v duration_unit__v
Concomitant Medication Dose Value (Number) CM_DOSE_VALUE_NUMBER Numeric with Precision (9,3) case_product_dosage__v dose_number__v
Concomitant Medication Dose Value (Text) CM_DOSE_VALUE_TEXT Text (2000) case_product_dosage__v dose_text__v
Concomitant Medication Dose Unit (Code) CM_DOSE_UNIT_CODE Mapped Value case_product_dosage__v dose_unit__v
Concomitant Medication Dose Unit (Text) CM_DOSE_UNIT_TEXT Text (50) case_product_dosage__v dose_unit_text__v
Concomitant Medication Frequency Value CM_FREQUENCY_VALUE Numeric with Precision (4,8) case_product_dosage__v frequency_number__v
Concomitant Medication Frequency Unit CM_FREQUENCY_UNIT Mapped Value case_product_dosage__v frequency_unit__v
Concomitant Medication Route (Code) CM_ROUTE_CODE Mapped Value case_product_dosage__v patient_adminroute__v
Concomitant Medication Route (Text) CM_ROUTE_TEXT Text (60) case_product_dosage__v patient_adminroute_text__v
Concomitant Medication Route Term ID CM_ROUTE_TERM_ID Text (50) case_product_dosage__v patient_adminroute_termid__v
Concomitant Medication Route Term ID Version CM_ROUTE_TERM_ID_VERSION Text (50) case_product_dosage__v patient_adminroute_termid_version__v
Concomitant Medication Site of Dispense CM_SITE_OF_DISPENSE Mapped Value case_product_dosage__v anatomical_site__v
Concomitant Medication Batch / Lot Number CM_BATCH_LOT_NUMBER Text (35) case_product_dosage__v batchlot_number__v
Concomitant Medication Dose Form (Text) CM_DOSE_FORM_TEXT Text (50) case_product_dosage__v dose_form_text__v
Concomitant Medication Dose Form Term ID CM_DOSE_FORM_TERM_ID Text (50) case_product_dosage__v dose_form_termid__v
Concomitant Medication Dose Form Term ID Version CM_DOSE_FORM_TERM_ID_VERSION Text (50) case_product_dosage__v dose_form_termid_version__v
Concomitant Medication Parent Route (Text) CM_PARENT_ROUTE_TEXT Text (60) case_product_dosage__v parent_adminroute_text__v
Concomitant Medication Parent Route (Code) CM_PARENT_ROUTE_CODE Mapped Value case_product_dosage__v parent_adminroute__v
Concomitant Medication Parent Route Term ID CM_PARENT_ROUTE_TERM_ID Text (50) case_product_dosage__v parent_adminroute_termid__v
Concomitant Medication Parent Route Term ID Version CM_PARENT_ROUTE_TERM_ID_VERSION Text (50) case_product_dosage__v parent_adminroute_termid_version__v

Medical History

This type of safety configuration is applied to medical history forms of the study. The information will flow to the Medical History & Concurrent Conditions section of Veeva Safety.

To perform the Item Configuration step for this safety data type:

  1. Navigate to the Form Configuration that you want to configure items for.
  2. Click the Form Name in the row to open it.
  3. Click Save and Next to open the Item Configuration step.
  4. For each row that you want to map, use the cell in the Configured Item column to select the appropriate Item Definition. For example, select the MHTERM item from the form for the location Medical History Reported. The choices for item selection will usually depend on the Form Properties > Each Entry In setting previously saved. Some safety locations have special rules that indicate they can be done in only repeating or non-repeating item groups, or sometimes either. Refer to the table at the end of these steps for those outliers, plus important notes regarding all safety locations of this type.

  5. Depending on the data type of the Configured Item and the Safety Field, you may need to provide Value Translations. See the Value Translations section above for instructions.
  6. When finished, click Save or click Save and Next to proceed to the Inclusion Criteria step.
CDMS Form Type Safety Field Safety Field Name Data Type Inbox Item/Case Object Inbox Item/Case Field
Medical History Medical History Reported MH_REPORTED Text (250) case_medical_history__v name_reported__v
Medical History Medical History Reported (Coding LLT) MH_REPORTED_LLT Text (8) case_medical_history__v name_meddra__v
Medical History Start Date MH_START_DATE Date/Datetime case_medical_history__v startdate_idate__v
Medical History Continuing MH_CONTINUING Boolean case_medical_history__v continuing_value__v
Medical History End Date MH_END_DATE Date/Datetime case_medical_history__v enddate_idate__v
Medical History Comments MH_COMMENTS Text (2000) case_medical_history__v comments__v
Medical History Family History MH_FAMILY_HISTORY Boolean case_medical_history__v family_history__v
Medical History Illness at Vaccination MH_ILLNESS_AT_VACCINATION Boolean case_medical_history__v illness_at_vaccination__v

Drug History

This type of safety configuration is applied to drug history forms of the study. The information will flow to the Drug History section of Veeva Safety.

To perform the Item Configuration step for this safety data type:

  1. Navigate to the Form Configuration that you want to configure items for.
  2. Click the Form Name in the row to open it.
  3. Click Save and Next to open the Item Configuration step.
  4. For each row that you want to map, use the cell in the Configured Item column to select the appropriate Item Definition. For example, select the DH_REPORTED item from the form for the location Drug History Reported. The choices for item selection will usually depend on the Form Properties > Each Entry In setting previously saved. Some safety locations have special rules that indicate they can be done in only repeating or non-repeating item groups, or sometimes either. Refer to the table at the end of these steps for those outliers, plus important notes regarding all safety locations of this type.

  5. Depending on the data type of the Configured Item and the Safety Field, you may need to provide Value Translations. See the Value Translations section above for instructions.
  6. When finished, click Save or click Save and Next to proceed to the Inclusion Criteria step.
CDMS Form Type Safety Field Safety Field Name Data Type Inbox Item/Case Object Inbox Item/Case Field
Drug History Drug History Reported DH_REPORTED Text (250) case_drug_history__v name_reported__v
Drug History Start Date DH_START_DATE Date/Datetime case_drug_history__v startdate_idate__v
Drug History End Date DH_END_DATE Date/Datetime case_drug_history__v enddate_idate__v
Drug History Age at Vaccination / Use DH_AGE_AT_USE Numeric (3) case_drug_history__v age_at_vaccination_number__v
Drug History Age At Vaccination / Use Unit DH_AGE_AT_USE_UNIT Mapped Value case_drug_history__v age_at_vaccination_unit__v
Drug History Product Type DH_PRODUCT_TYPE Mapped Value case_drug_history__v product_type__v
Drug History Indication Reported DH_INDICATION Text (250) case_drug_history__v indication_reported__v
Drug History Reaction Reported DH_REACTION Text (250) case_drug_history__v reaction_reported__v

Test Results

This type of safety configuration is applied to lab / test result forms of the study. The information will flow to Test Results section of Veeva Safety.

To perform the Item Configuration step for this safety data type:

  1. Navigate to the Form Configuration that you want to configure items for.
  2. Click the Form Name in the row to open it.
  3. Click Save and Next to open the Item Configuration step.
  4. For each row that you want to map, use the cell in the Configured Item column to select the appropriate Item Definition. For example, select the LBDT item from the form for the location Test Date. The choices for item selection will usually depend on the Form Properties > Each Entry In setting previously saved. Some safety locations have special rules that indicate they can be done in only repeating or non-repeating item groups, or sometimes either. Refer to the table at the end of these steps for those outliers, plus important notes regarding all safety locations of this type.

  5. Depending on the data type of the Configured Item and the Safety Field, you may need to provide Value Translations. See the Value Translations section above for instructions.
  6. When finished, click Save or click Save and Next to proceed to the Inclusion Criteria step.
CDMS Form Type Safety Field Safety Field Name Data Type Inbox Item/Case Object Inbox Item/Case Field
External Labs Test Date LAB_DATE Date/Datetime case_test_result__v date_idate__v
External Labs Test Name LAB_TEST_NAME Text (250) case_test_result__v name_reported__v
External Labs Test Name (Coding LLT) LAB_TEST_NAME_MEDDRA Text (8) case_test_result__v name_meddra__v
External Labs Test Result (Numeric) LAB_RESULT_NUMERIC Numeric with Precision (14,3) case_test_result__v result_value__v
External Labs Test Result (Code) LAB_TEST_RESULT_CODE Mapped Value case_test_result__v result_code__v
External Labs Test Unit LAB_RESULT_UNIT Mapped Value case_test_result__v result_unit__v
External Labs Test Result (Text) LAB_RESULT_TEXT Text (2000) case_test_result__v restult_text__v
External Labs Test Result (Qualifier) LAB_RESULT_QUALIFIER Mapped Value case_test_result__v result_qualifier__v
External Labs Test Normal Low Value LAB_LOW_VALUE Text (50) case_test_result__v normal_low_value__v
External Labs Test Normal High Value LAB_HIGH_VALUE Text (50) case_test_result__v normal_high_value__v
External Labs Test Comments LAB_COMMENTS Text (2000) case_test_result__v comments__v
External Labs More Information Available LAB_MORE_INFO_AVAILABLE Boolean case_test_result__v more_information_available__v

Patient Characteristics

This type of safety configuration is applied to general information about the subject. The information will flow to the Patient section of Veeva Safety.

To perform the Item Configuration step for this safety data type:

  1. Navigate to the Form Configuration that you want to configure items for.
  2. Click the Form Name in the row to open it.
  3. Click Save and Next to open the Item Configuration step.
  4. For each row that you want to map, use the cell in the Configured Item column to select the appropriate Item Definition. For example, select the DOB item from the form for the location Date of Birth. The choices for item selection will usually depend on the Form Properties > Each Entry In setting previously saved. Some safety locations have special rules that indicate they can be done in only repeating or non-repeating item groups, or sometimes either. Refer to the table at the end of these steps for those outliers, plus important notes regarding all safety locations of this type.

  5. Depending on the data type of the Configured Item and the Safety Field, you may need to provide Value Translations. See the Value Translations section above for instructions.
  6. When finished, click Save or click Save and Next to proceed to the Inclusion Criteria step.
CDMS Form Type Safety Field Safety Field Name Data Type Inbox Item/Case Object Inbox Item/Case Field
Patient Characteristics Gender N/A Mapped Value case_version__v gender_value__v
Patient Characteristics Date of Birth PC_DOB Date / Numeric / Text case_version__v dob_idate__v
Patient Characteristics Race PC_RACE Mapped Value case_version__v race__v
Patient Characteristics Ethnicity PC_ETHNICITY Mapped Value case_version__v ethnicity__v
Patient Characteristics Age Group PC_AGE_GROUP Mapped Value case_version__v age_group__v
Patient Characteristics Age at SAE PC_AGE_VALUE Numeric (3) case_version__v age_value__v
Patient Characteristics Age at SAE Unit PC_AGE_UNIT Mapped Value case_version__v age_unit__v
Patient Characteristics Age at Vaccination PC_AGE_AT_VX Numeric (3) case_version__v age_at_vaccination_number__v
Patient Characteristics Age Unit at Vaccination PC_AGE_AT_VX_UNIT Mapped Value case_version__v age_at_vaccination_unit__v
Patient Characteristics Gestation Value PC_GESTATION Numeric (3) case_version__v gestation_value__v
Patient Characteristics Gestation Unit PC_GESTATION_UNIT Mapped Value case_version__v gestation_unit__v
Patient Characteristics Weight (kg) PC_WEIGHT_KG Numeric with Precision (4,4) case_version__v weight_normalized__kg__v
Patient Characteristics Height (cm) PC_HEIGHT_CM Numeric with Precision (4,3) case_version__v height_normalized__cm__v
Patient Characteristics Patient Name or Initials PC_NAME_OR_INITIALS Text (60) case_version__v patient_id_value__v
Patient Characteristics GP Medical Record Number PC_GPRN Text (20) case_version__v mrn_gp_value__v
Patient Characteristics Hospital Record Number PC_HRN Text (20) case_version__v mrn_hospital_value__v
Patient Characteristics Investigational Record Number PC_IRN Text (20) case_version__v mrn_investigation_value__v
Patient Characteristics Specialist Record Number PC_SRN Text (20) case_version__v mrn_specialist__value
Patient Characteristics Randomization Number PC_RAND_NUM Text (20) case_version__v patient_randomization_number__v
Patient Characteristics Last Menstrual Date PC_LAST_MENSTRUAL_DATE Date case_version__v last_menstrual_date
Patient Characteristics Pregnancy Occurrences N/A Numeric (2) case_version__v gravida_gravidity__v
Patient Characteristics Number Given Birth AE_PREG_INFO_PARA Numeric (2) case_version__v para_parity__v
Patient Characteristics Pregnant at SAE PC_PREG_CASE Boolean case_version__v pregnancy_case__v
Patient Characteristics Pregnant at Vaccination PC_PREG_AT_VX Boolean case_version__v pregnant_at_vaccination__v
Patient Characteristics Pregnancy Conception Date AE_PREG_INFO_CON_DT Date case_version__v pregnancy_conception_date__v
Patient Characteristics Pregnancy Due Date AE_PREG_INFO_DUE_DT Date case_version__v pregnancy_due_date__v
Patient Characteristics Pregnancy Outcome AE_PREG_INFO_OUTCOME Mapped Value case_version__v pregnancy_outcome__v
Patient Characteristics Delivery Method AE_PREG_INFO_DELV_METH Mapped Value case_version__v delivery_method__v
Patient Characteristics Date of Pregnancy Outcome AE_PREG_INFO_OUTCOME_DT Date case_version__v date_of_pregnancy_outcome__v
Patient Characteristics Parent Subject Number PC_PARENT_SUBNUM Text (128) case_version__v parent_subject_number__v
Patient Characteristics General Medical History PC_MH_TEXT Text (10000) case_version__v medical_history_text__v
Patient Characteristics Subject had Concomitant Therapies PC_CON_THERAPY Boolean N/A N/A

In Case of Death

This type of safety configuration is applied to forms involving death details about the subject. Some fields for this type must be non-repeating (e.g. Date of Death), others can be repeating or non-repeating (causes of death). Information will flow to two places in Veeva Safety, Patient or Causes of Death.

To perform the Item Configuration step for this safety data type:

  1. Navigate to the Form Configuration that you want to configure items for.
  2. Click the Form Name in the row to open it.
  3. Click Save and Next to open the Item Configuration step.
  4. For each row that you want to map, use the cell in the Configured Item column to select the appropriate Item Definition. For example, select the DTHDT item from the form for the location Date of Death. The choices for item selection will usually depend on the Form Properties > Each Entry In setting previously saved. Some safety locations have special rules that indicate they can be done in only repeating or non-repeating item groups, or sometimes either. Refer to the table at the end of these steps for those outliers, plus important notes regarding all safety locations of this type.

  5. Depending on the data type of the Configured Item and the Safety Field, you may need to provide Value Translations. See the Value Translations section above for instructions.
  6. When finished, click Save or click Save and Next to proceed to the Inclusion Criteria step.
CDMS Form Type Safety Field Safety Field Name Data Type Inbox Item/Case Object Inbox Item/Case Field
In Case of Death Date of Death ICD_DEATH_DT Date case_version__v dod_idate__v
In Case of Death Autopsy Result Available ICD_AUTOPSY_RES Boolean case_version__v autopsy_value__v
In Case of Death Reason Autopsy Result Omitted ICD_AUTOPSY_REAS_OMIT Mapped Value case_version__v autopsy_reason_omitted__v
In Case of Death Cause of Death - Type ICD_CASE_TYPE Mapped Value case_cause_of_death__v type__v
In Case of Death Cause of Death - Reported ICD_CAUSE_REPORTED Text (250) case_cause_of_death__v name_reported__v
In Case of Death Cause of Death - Reported (Coding LLT) ICD_CAUSE_LLT Text (8) case_cause_of_death__v name_meddra__v

Inclusion Criteria

Inclusion criteria are evaluated to determine the inclusion of the mapped item values into a safety case beyond the primary event initiating the safety case data transfer.

Notes / concepts:

  • Inclusion criteria will only be evaluated, if
    • On the Form Properties tab, all inclusion criteria evaluate to true, particularly the Key Safety Item
      • (AND)
    • On the Item Configurations tab, the required items have non-empty values on the EDC form
  • The additional criteria can either include all forms of a type, be based on a site user action (linking) and/or date comparison based. These configurations can differ by type, specific form, and/or study.
  • Conditions on the Inclusion Criteria tab are considered “OR” as they evaluate. That is, if any one of a series of applicable criteria is true, then the evaluation is “In”, regardless of others evaluating as false (“Out”).
  • When a comparison with the safety case initiation event End Date for inclusion into a case is configured, but the date is not set on the data entry screen, the Events end date is used for evaluation as open ended. Once an end date is entered on the primary event (or related form), the system will re-evaluate the inclusion criteria, and send a corrective follow-up, if appropriate.
  • Inclusion Criteria are applicable for all the related safety types:
    • Safety Case Initiation Event
    • Study Drug
    • Concomitant Medication
    • Medical History
    • Drug History
    • Test Results

X = ‘Can be used in the section’

Options Safety Case Initiation Event CM MH Labs Study Drug Notes
All X X X X X Disables any other option in that section
Linked by Site User X X X X When this option is used, Form to Form or Item to Form linking must be configured and site must perform the link
Duration overlaps any part of safety event X X X X X The start to end range of the related form overlaps the start to end date range of the Safety Case Initiation Event
Duration overlaps X days on/before safety event start X X X X X The start to end range of the related form overlaps the following range: Safety Event Start - X days → Safety Event Start
Duration overlaps X days on/after safety event start X X X X X The start to end range of the related form overlaps the following range: Safety Event Start → Safety Event Start + X days
Duration overlaps any X days on/before safety event end X X X X X The start to end range of the related form overlaps the following range: Safety Event End - X days → End Start
Duration overlaps any X days on/after safety event end X X X X X The start to end range of the related form overlaps the following range: Safety Event End → Safety Event End + X days
Duration ends before the Safety Event start X X X X X The end date of the related form is before the Safety Event start
Study drug start date prior to the Safety Event start X The start date of the study drug form is before the Safety Event start
Closest On Before Safety Event Start X This is a special option only for Study Drug. When set, no other option can be used. This option includes one dispense of the study drug that is closest to the Safety Event start (on/before)
  • X = available for that type
  • *: Cannot modify this criteria yet for these two types. Information is included in all safety cases for a subject where mapped / used
  • Abbreviations for types: “Conc Meds” = Concomitant Medications, “Med Hist” = Medical History, “Drug Hist“ = Drug History, “Test Res“ = Test Results, “Pat Chars“ = Patient Characteristics

Option Meaning / Examples

All criteria options are summarized below. With each date-based option, a series of examples are included to illustrate its usage.

Option Notes / Studio Interface
All Selecting this option disables all other options.
  • For Study Drug forms:
  • For all other form types:
Linked by Site User When this option is used, Form-to-Form or Item-to-Form linking must be configured on the main form design
  • For Safety Case Initiation Event forms:
  • For all other form types:
Start to End Overlaps Safety Event Start to End

Select this option when the related event's start to end date range overlaps with the start to end date range of the safety case initiating event. This is commonly referred to as "ongoing at event start". That is, the related event has a start date on or before the end date of the initiating event, and the related event doesn't end before the start date of the initiating event.

For Vault to compare the date and time of two events, both must collect the date and time for the comparison to evaluate the entire date and time. If one of the two is date only, then the comparison will only evaluate the dates.

If unknown parts are allowed on either side, the comparison will compare as many known values are shared between the two dates. For example, if one side has an unknown month, the comparison will only compare the years from each date. If one side has an unknown day, the comparison will only compare the month and year from each date.

Example: Include all concomitant medications being taken (ongoing) at SAE start

Event Start Event End Related Data Start Related Data End Related Data - In or Out? Notes
11-Mar   12-Mar 13-Mar In initiating Event End is empty (it's ongoing), so includes the related event range March 12th to 13th
11-Mar 12-Mar 12-Mar 13-Mar In The two ranges touch
11-Mar 11-Mar 12-Mar 13-Mar Out The two ranges don't touch
11-Mar 11-Mar 10-Mar 10-Mar Out The two ranges don't touch
11-Mar 11-Mar 10-Mar   In Related End Date is empty (the event is ongoing, and it's in the future), so includes March 11th
Start to End Overlaps X Days Before Safety Event Start

Select this option when the related event start to end date range overlaps with the initiating event's start date or start date minus (before) the specified number of days.

For Vault to compare the date and time of two events, both must collect the date and time for the comparison to evaluate the entire date and time. If one of the two is date only, then the comparison will only evaluate the dates.

If unknown parts are allowed on either side, the comparison will compare as many known values are shared between the two dates. For example, if one side has an unknown month, the comparison will only compare the years from each date. If one side has an unknown day, the comparison will only compare the month and year from each date.

For this option, Days On/Before will only accept whole numbers.

Example: Include all concomitant medications who may have ended prior to the SAE start, but were taken within 7 days of the event.

Event Start Event End Related Data Start Related Data End Related Data - In or Out? Notes
11-Mar   12-Mar 13-Mar In SCIE End is empty (thus far in future), so includes 12-Mar to 13-Mar. In this case the 7 days on/before doesn’t factor in.
11-Mar 12-Mar 12-Mar 13-Mar Out Related form’s range doesn’t touch March 4th to 11th (the 7 days before the SCIE)
11-Mar 11-Mar 08-Mar 09-Mar In Related form range does touch March 4th to 11th
11-Mar 11-Mar 08-Mar 12-Mar In Related form range does touch March 4th to 11th
11-Mar 11-Mar 02-Mar 03-Mar Out Related form range does not touch March 4th to 11th
Start to End Overlaps X Days After Safety Event Start

Select this option when the related form start to end range "touches" the primary event’s end date minus (before) a specific number of days.

For Vault to compare the date and time of two events, both must collect the date and time for the comparison to evaluate the entire date and time. If one of the two is date only, then the comparison will only evaluate the dates.

If unknown parts are allowed on either side, the comparison will compare as many known values are shared between the two dates. For example, if one side has an unknown month, the comparison will only compare the years from each date. If one side has an unknown day, the comparison will only compare the month and year from each date.

For this option, Days On/After will only accept whole numbers.

Example: Include concomitant medications started within 3 days of the start, even if the event has ended.

Event Start Event End Related Data Start Related Data End Related Data - In or Out? Notes
11-Mar   16-Mar 17-Mar In SCIE End is empty (thus far in future), so includes March 15th to 17th range of the related form
11-Mar 12-Mar 12-Mar 13-Mar Out Related form’s range doesn’t touch March 4th to 11th (the 7 days before the SCIE)
11-Mar 11-Mar 08-Mar 09-Mar In Related form range does touch March 4th to 11th
11-Mar 11-Mar 08-Mar 12-Mar In Related form range does touch March 4th to 11th
11-Mar 11-Mar 02-Mar 03-Mar Out Related form range does not touch March 4th to 11th
Start to End Overlaps X Days Before Safety Event End

Select this option when the related form start to end range "touches" the primary event’s end date minus (before) a specific number of days.

This value can be redundant with the Days On/Before (start) value for events that start and end quickly. But, for longer duration primary events, bringing in those occurring during the duration, but strictly after the primary event start date.

For Vault to compare the date and time of two events, both must collect the date and time for the comparison to evaluate the entire date and time. If one of the two is date only, then the comparison will only evaluate the dates.

If unknown parts are allowed on either side, the comparison will compare as many known values are shared between the two dates. For example, if one side has an unknown month, the comparison will only compare the years from each date. If one side has an unknown day, the comparison will only compare the month and year from each date.

For this option, Days On/Before will only accept whole numbers.

Example: Include concomitant medications started within 3 days of the end, even if the event started before the medication started.

SCIE Start SCIE End Related Data Start Related Data End Related Data - In or Out? Notes
11-Mar 12-Mar 01-Mar   In Related End is empty (thus far in future), so includes March 5th to 12th (the 7 days before SCIE End)
11-Mar 12-Mar 01-Mar 04-Mar Out Related form’s range doesn’t touch March 4th to 11th (the 7 days before the SCIE)
11-Mar 11-Mar 01-Mar 05-Mar In Related form range does touch March 5th to 12th range
Start to End Overlaps X Days After Safety Event End

Select this option when the related form start to end range "touches" the primary event’s end date plus (after) a specific number of days, for example, further events (serious or not) that occur after the initial serious event (created the safety case) has ended, but close in days.

For Vault to compare the date and time of two events, both must collect the date and time for the comparison to evaluate the entire date and time. If one of the two is date only, then the comparison will only evaluate the dates.

If unknown parts are allowed on either side, the comparison will compare as many known values are shared between the two dates. For example, if one side has an unknown month, the comparison will only compare the years from each date. If one side has an unknown day, the comparison will only compare the month and year from each date.

For this option, Days On/After will only accept whole numbers.

Example: Include concomitant medications started within 3 days after the end of the event.

SCIE Start SCIE End Related Data Start Related Data End Related Data - In or Out? Notes
11-Mar   16-Mar 17-Mar In SCIE End is empty (thus far in future), so includes March 15th to 17th range of the related form
11-Mar 12-Mar 16-Mar 17-Mar Out Related form range does not touch March 12th to 15th (the 3 days after the SCIE end)
11-Mar 12-Mar 15-Mar 16-Mar In Related form range does touch March 5th to 12th range
11-Mar 12-Mar 10-Mar   In Related End is empty (thus far in the future), so includes the March 12th to March 15th range
11-Mar 12-Mar 10-Mar 10-Mar Out Related form range does not touch the March 12th to March 15th range
First Dispense

*Applies only to the Study Drug safety form data type.

Select the First Dispense checkbox to use the first dispense - chronological order - across all dispense forms.

If the date and time are involved in the study drug start/end, the comparison for on/before will honor the full datetime.

SCIE Start SCIE End Study Drug (Starts to Ends) Study Drug Data In or Out? Notes
11-Mar 11-Mar
  • 05-Mar to 05-Mar
  • 08-Mar to 08-Mar
  • 10-Mar to 10-Mar
  • 12-Mar to 12-Mar
  • 15-Mar to 15-Mar
In (1) Specifically, the March 10th data
11-Mar 11-Mar
  • 05-Mar to 05-Mar
  • 06-Mar to 06-Mar
  • 10-Mar to 10-Mar
  • 10-Mar to 10-Mar
  • 13-Mar to 13-Mar
In (1) Specifically, one of the March 10th dispense forms, not both
11-Mar 11-Mar
  • 05-Mar to 05-Mar
  • 06-Mar to 06-Mar
  • 10-Mar to 10-Mar
  • 11-Mar to 11-Mar
  • 13-Mar to 13-Mar
In (1) Specifically, one of the March 11th dispense forms, not both
11-Mar 11-Mar
  • 13-Mar to 13-Mar
  • 15-Mar to 15-Mar
  • 17-Mar to 17-Mar
Out With no study drug dispenses at the SCIE Start, none are included and the Drug Role is Not Administered in the safety case
Closest On/After Safety Event Start

*Applies only to the Study Drug safety form data type.

Select the Closest On/After checkbox to use the “restart” dispense, i.e. if the subject restarts the study drug on/after the event start, it will be included

If the date and time are involved in the study drug start/end, the comparison for on/before will honor the full datetime.

SCIE Start SCIE End Study Drug (Starts to Ends) Study Drug Data In or Out? Notes
11-Mar 11-Mar
  • 05-Mar to 05-Mar
  • 10-Mar to 10-Mar
  • 12-Mar to 12-Mar
  • 15-Mar to 15-Mar
In (1) Specifically, the March 12th data
11-Mar 11-Mar
  • 05-Mar to 05-Mar
  • 10-Mar to 10-Mar
  • 12-Mar to 12-Mar
  • 12-Mar to 12-Mar
In (1) Specifically, one of the March 12th dispense forms, not both
11-Mar 11-Mar
  • 05-Mar to 05-Mar
  • 08-Mar to 08-Mar
  • 10-Mar to 10-Mar
Out In this situation, there is no dispense that qualifies as "On/After" the SCIE Start. As such, no additional dispense information is included, outside of what is very likely the use of "First Dispense" and "Closest On/Before" in conjunction with this option. Should there eventually be a dispense on/after March 11th, the system will send an appropriate follow-up to safety.
Closest On/Before Safety Event (One Only)

*Applies only to the Study Drug safety form data type.

This option works just like the First Dispense option, but once selected, no other option can be used. This option includes one dispense of the study drug, that which is closes to the event start date (on/before).

See the examples above for Closest On/Before. The same holds true for this option.

Drug Dispense Start Before Safety Event Start

*Applies only to the Study Drug safety form data type.

Select this option when the start date of the study drug form is strictly before the event starts.

For Vault to compare the date and time of two events, both must collect the date and time for the comparison to evaluate the entire date and time. If one of the two is date only, then the comparison will only evaluate the dates.

If unknown parts are allowed on either side, the comparison will compare as many known values are shared between the two dates. For example, if one side has an unknown month, the comparison will only compare the years from each date. If one side has an unknown day, the comparison will only compare the month and year from each date.

SCIE Start SCIE End Study Drug (Starts to Ends) Study Drug Data In or Out? Notes
11-Mar 11-Mar
  • 05-Mar to 05-Mar
  • 10-Mar to 10-Mar
  • 11-Mar to 11-Mar
  • 12-Mar to 12-Mar
  • 15-Mar to 15-Mar
In (2) Specifically, the March 5th and March 10th data
11-Mar 11-Mar
  • 13-Mar to 13-Mar
  • 15-Mar to 15-Mar
  • 17-Mar to 17-Mar
Out With no study drug dispenses at the SCIE Start, none are included and the Drug Role is Not Administered in the safety case
Ended Before Safety Event Start

*Applies only to the Study Drug safety form data type.

Select this option when the end date of study drug dispensing is strictly before the primary event start date.

For Vault to compare the date and time of two events, both must collect the date and time for the comparison to evaluate the entire date and time. If one of the two is date only, then the comparison will only evaluate the dates.

If unknown parts are allowed on either side, the comparison will compare as many known values are shared between the two dates. For example, if one side has an unknown month, the comparison will only compare the years from each date. If one side has an unknown day, the comparison will only compare the month and year from each date.

SCIE Start SCIE End Study Drug (Starts to Ends) Study Drug Data In or Out? Notes
11-Mar 11-Mar
  • 05-Mar to 05-Mar
  • 10-Mar to 10-Mar
  • 11-Mar to 11-Mar
  • 12-Mar to 12-Mar
  • 15-Mar to 15-Mar
In (2) Specifically, the March 5th and March 10th data. The March 11th dispense "touches" the SCIE date range, so is not included
11-Mar 11-Mar
  • 13-Mar to 13-Mar
  • 15-Mar to 15-Mar
  • 17-Mar to 17-Mar
Out With no study drug dispenses strictly ended before the SCIE Start, none are included and the Drug Role is Not Administered in the safety case
Always

* Applies only to the Patient Characteristics or In Case of Death safety form data types.

This option indicates that the data should always be included in the safety case from those classified EDC forms. It isn't editable.

Inclusion Criteria by Safety Data Type

Safety Case Initiation Event

The Safety Case Initiation Event will be the primary event to begin the process of transferring a safety case. All other related events are then brought into the case per their configured criteria. Depending on preference and study design, the initiating event can include other data from the initiating form, or be related to other events/forms of the same type, which themselves, however, don’t constitute their own safety case (e.g. other non-serious events linked to the initiating serious event).

Common practical example:

  • On Monday, the subject experiences a non-serious adverse event “Headaches” (AE form #1)
  • On Wednesday, the subject experiences a serious adverse event “Dizziness” (AE form #2)
  • The system sends a safety case for the Tuesday event (“Dizziness”) as the primary initiating event of the new safety case. The system also adds the data of the Monday event as a 2nd event in the same safety case based on inclusion criteria configured. This happens due to the use of Days On/Before = 2 (or more)

To save inclusion criteria for this safety type:

  1. Navigate to your Study in Studio > Form Configurations
  2. Navigate into the safety form configuration, then to the Inclusion Criteria tab:

  3. Include Related Event Forms in Safety Case:
    1. If your study does not intend to bring other events into the safety case (secondary events), leave the default of No, and next use Save and Close to finish.
    2. If, on the other hand, your study does need to include other events (secondary) to the safety case based on criteria, select Yes:
  4. Include Related Forms Linked by Site Users: Choose Yes if events linked by the site to the primary initiating event are to be included in the case. Warning: with Yes, the form must also have Form to Form or Item to Form linking configured.
  5. Include Related Event Forms by Date Matching: Choose Yes if data from related events are to be evaluated for inclusion based on one or more date based criteria.

    • Check an option, or set specific Days value(s). At least one of these options must be selected / set.
  6. Click Save and Close to finish.

For more detail and examples on each inclusion criteria option, see Option Meanings & Examples above.

Study Drug

This type of safety configuration is used to track dosing / dispensing information of a study drug in relation to the initiating event, i.e. those the clinical study is testing against subjects. The information will flow to the Products / Drugs section of a safety case.

Practical example:

  • On March 1st, the subject receives the first dispense of a study drug Active vs Placebo (blinded study drug)
  • On March 3rd, the subject receives another dispense
  • On March 5th, the subject receives another dispense
  • On March 6th, the subject experiences a serious adverse event (“Dizziness”) and the site enters into the AE form
  • The system creates and transfers a safety case using “Dizziness” as the primary event
  • The study is configured to include in the safety case a subset of dispenses. As one configuration example, March 1st (first overall) and March 5th (closest on/before). Other dispenses are not included, per the criteria configured.

To save inclusion criteria for this safety type:

  1. Navigate to your Study in Studio > Form Configurations
  2. Navigate into the safety form configuration, then to the Inclusion Criteria tab:

  3. Include Forms in Safety Case:
    1. All: Include all current study drug dispenses into the case
    2. Closest dispense on/before event (default): Include the nearest single dose/dispense for the subject across all forms into the case. The study drug dispensed with the date closest before the start of the primary initiating event will be included.
    3. Advanced date matching: Display and configure advanced selections in relation to the primary initiating events start and end date. Check one or more options, or set specific Days value(s). At least one of these options must be selected / set.
  4. Click Save and Close to finish.

For more detail and examples on each inclusion criteria option, see Option Meanings & Examples above.

Concomitant Medications

This type of safety configuration is applied to concomitant medication forms of the study. The information will flow to the Products / Drugs section of a safety case.

Multiple forms can be used with the type.

Practical example:

  • On March 1st, the subject starts Aspirin, taken once a day, but stops on March 3rd
  • On March 3rd, the subject starts Ibuprofen, taken once a day, and has no end date (still taking)
  • On March 5th, the subject takes one dose of Alleve (end date March 5th also)
  • On March 7th, the subject experiences a serious adverse event (“Dizziness”) and the site enters into the AE form
  • The system creates and transfers a safety case using “Dizziness” as the primary event
  • The study design prescribes to pull in concomitant medications using these two rules:
    • “Anything ongoing at the SAE start”
    • “Anything stopped, but stopped within 3 days of the SAE start”
  • The result: March 3rd Ibuprofen (ongoing) and March 5th Alleve (ended, but only 2 days ago) are both in case. The other - March 1st Aspirin - is not the case (it ended more than 3 days ago)

To save inclusion criteria for this safety type:

  1. Navigate to your Study in Studio > Form Configurations
  2. Navigate into the safety form configuration, then to the Inclusion Criteria tab:

  3. Select from these options:
    • *Include All Forms in Safety Case (Defaults to No): Select Yes, to include all current concomitant medications into the case, which will disable all other options.
    • Include Related Forms Linked by Site Users: Choose Yes if concomitant medications linked by the site to the primary initiating event are to be included in the case. Warning: with Yes, the form must also have Form to Form or Item to Form linking configured.
    • Include Forms in Safety Case Linked by Site Users: Choose Yes or No for Warning: with Yes, the form must also have Form to Form or Item to Form linking configured.
  4. Choose Yes or No for Include Forms to Safety Case by Date Matching. With Yes, this means the system will use one or more criteria to compare the Start to End ranges of the safety case event (primary) and the related data (the form actively being configured, it’s start and end end range):

  5. Check an option, or set specific Days value(s). At least one of these options must be selected / set.
  6. Click Save and Close to finish.

For more detail and examples on each inclusion criteria option, see Option Meanings & Examples above.

Medical History

This type of safety configuration is applied to medical history forms of the study.

Practical example:

  • In January of 2024, the subject first started having “Minor Dizziness”. The medical history is deemed ongoing (no end date)
  • A second medical history indicates “Back Pain”, with start April 2024 and end May 2024
  • A third medical history indicates “Migraines” with start of June 2024 and end of Nov 2024
  • On March 7th 2025, the subject experiences a serious adverse event (“Dizziness”) and the site enters into the AE form
  • The system creates and transfers a safety case using “Dizziness” as the primary event
  • The study design prescribes to pull in medical history using these two rules:
    • “Anything ongoing at the SAE start”
    • “Anything stopped, but stopped within 182 days of the SAE start”
  • The result: “Minor Dizziness” (ongoing) and “Migraines” (ended, but within a year) are both in case. The other - “Back Pain” - is not in case (it ended more than 180 days ago)

To save inclusion criteria for this safety type:

  1. Navigate to your Study in Studio > Form Configurations
  2. Navigate into the safety form configuration, then to the Inclusion Criteria tab:

  3. Select from these options:
    • Include All Forms in Safety Case (Defaults to No): Select Yes, to include all current concomitant medications into the case, which will disable all other options.
    • Include Related Forms Linked by Site Users: Choose Yes if concomitant medications linked by the site to the primary initiating event are to be included in the case. Warning: with Yes, the form must also have Form to Form or Item to Form linking configured.
    • Include Forms in Safety Case Linked by Site Users: Choose Yes or No for Warning: with Yes, the form must also have Form to Form or Item to Form linking configured.
  4. Choose Yes or No for Include Forms to Safety Case by Date Matching. With Yes, this means the system will use one or more criteria to compare the Start to End ranges of the safety case event (primary) and the related data (the form actively being configured, it’s start and end end range):

  5. Check an option, or set specific Days value(s). At least one of these options must be selected / set.
  6. Click Save and Close to finish.

For more detail and examples on each inclusion criteria option, see Option Meanings & Examples above.

Drug History

This type of safety configuration is applied to drug history forms of the study.

Practical example:

  • The study design collects drug history information - at the screening visit - that the investigator deems appropriate and/or is per protocol. These are specifically drugs/products taken (and ended) before the subject is in the trial.
  • On March 7th 2025, the subject experiences a serious adverse event (“Dizziness”) and the site enters into the AE form.
  • The system creates and transfers a safety case using “Dizziness” as the primary event
  • Per the study configuration for this type of safety data, all are to be included in every safety case the subject experiences.
  • Alternatively, date based and/or site linking options can be used.

To save inclusion criteria for this safety type:

  1. Navigate to your Study in Studio > Form Configurations
  2. Navigate into the safety form configuration, then to the Inclusion Criteria tab:

  3. Select from these options:
    • Include All Forms in Safety Case (Defaults to No): Select Yes, to include all current concomitant medications into the case, which will disable all other options.
    • Include Related Forms Linked by Site Users: Choose Yes if concomitant medications linked by the site to the primary initiating event are to be included in the case. Warning: with Yes, the form must also have Form to Form or Item to Form linking configured.
    • Include Forms in Safety Case Linked by Site Users: Choose Yes or No for Warning: with Yes, the form must also have Form to Form or Item to Form linking configured.
  4. Choose Yes or No for Include Forms to Safety Case by Date Matching. With Yes, this means the system will use one or more criteria to compare the Start to End ranges of the safety case event (primary) and the related data (the form actively being configured, it’s start and end end range):

  5. Check an option, or set specific Days value(s). At least one of these options must be selected / set.
  6. Click Save and Close to finish.

For more detail and examples on each inclusion criteria option, see Option Meanings & Examples above.

Test Results

This type of safety configuration is applied to lab / test result forms of the study.

Practical example:

  • The study design collects additional labs / test results on a log form, as needed by the investigator / site. That is, tests they deem relevant to a serious adverse event.
  • On March 7th 2025, the subject experiences a serious adverse event (“Dizziness”) and the site enters into the AE form.
  • Additionally, the site adds two out of range lab tests and performs a link to the AE form for each.
  • The system creates and transfers a safety case using “Dizziness” as the primary event
  • Since the study has safety configuration that indicates to include whatever the site links to the event, the two test results are included in the case.
  • Additionally (or instead of), date based options can be used.

To save inclusion criteria for this safety type:

  1. Navigate to your Study in Studio > Form Configurations
  2. Navigate into the safety form configuration, then to the Inclusion Criteria tab:

  3. Select from these options:
    • Include All Forms in Safety Case (Defaults to No): Select Yes, to include all current concomitant medications into the case, which will disable all other options.
    • Include Related Forms Linked by Site Users: Choose Yes if concomitant medications linked by the site to the primary initiating event are to be included in the case. Warning: with Yes, the form must also have Form to Form or Item to Form linking configured.
    • Include Forms in Safety Case Linked by Site Users: Choose Yes or No for Warning: with Yes, the form must also have Form to Form or Item to Form linking configured.
  4. Choose Yes or No for Include Forms to Safety Case by Date Matching. With Yes, this means the system will use one or more criteria to compare the Start to End ranges of the safety case event (primary) and the related data (the form actively being configured, it’s start and end end range):

  5. Check an option, or set specific Days value(s). At least one of these options must be selected / set.
  6. Click Save and Close to finish.

For more detail and examples on each inclusion criteria option, see Option Meanings & Examples above.

Patient Characteristics

This type of safety configuration is applied to general information about the patient. There are no criteria for this type. Instead, information classified to this type is included in all safety cases of a subject.

When arriving at the Inclusion Criteria tab from the Item Configurations tab click Save and Next, which returns you to the Form Configurations list.

In Case of Death

This type of safety configuration is applied to forms involving death details about the subject. There are no criteria for this type. Instead, information classified to this type is included in all safety cases of a subject.

Currently, every case will receive this information, even those where no event in the case has an outcome Fatal.

When arriving at the Inclusion Criteria tab from the Item Configurations tab click Save and Next, which returns you to the Form Configurations list.

Copy Form Configurations into Other Studies

In the current release, the only way to copy safety form configuration information is via Copy Forms. The other copying levels, Copy Event Groups and Copy Events, don’t support the copying of form level safety configuration.

If an Event Group or Event is copied (Forms within) from a source library/study, and those Forms contain safety form configuration information, simply use Copy Forms with the Use Existing / Update with Changes options as a subsequent action.

Copying safety form configurations while performing core copy of Forms is optional.

In the Include section, you must select Safety Configuration to copy previously configured configurations.

Scenarios to bring in existing safety configuration while copying:

  • Copy while copying new forms: Here, the AE form design does not yet exist in the target study:

  • Copy later: This is done when you have previously copied in Forms, perhaps through Copy Event Groups or Copy Events, or used Copy Forms without the safety configuration included initially. Update with Changes must be checked. This sequence will copy “what fits”, i.e. in cases of form adjustments. Here, the AE form already exists in the target study:

To copy safety configuration for a form:

  1. Navigate to Studio > Forms.
  2. Click Copy From Study.
  3. Select Create a copy or Use existing / Update with Changes as appropriate (see the examples above)
  4. Select the Safety Configuration checkbox to also copy any safety configuration associated with the form. Vault indicates which forms have safety configurations in the dialog’s Has Safety Configuration column. Note that this requires a Study Role with the Manage Safety Configuration permission. The Safety Configuration checkbox will be disabled if the source study and target study do not match regarding safety configuration. They must both have it set up, and be using the same Safety Integrations Type.
  5. Select a Vault.
  6. For Copy From Study, choose where you want to copy from (From Another Study or From Library.)
  7. Select a Study Environment to copy from.
  8. Search or scroll to locate the Form Definition(s) you want to copy.
  9. Select the Form(s) you want to copy.
  10. Click Copy Forms. Vault begins copying the Form Definition into your Study.
  11. Optional: In the Copy from Study dialog:
    • Click View Summary to see a list of the copied forms and the status of the copy.
    • If you copied 20 or fewer Forms, click View Log to see detailed status information for each object record copied.
    • If you copied more than 20 Forms, Vault will send you an email notification with a link to download the log file when finished.
  12. When finished, click Close. Once you click Close, you can no longer access the summary or log file.
  13. Always visit the safety form configuration for copied forms after the copy. Adjustments to mappings / value translations might be necessary.

For more information on copy forms see here.

Delete All Safety Configuration

Use great care when removing all safety configurations for a study design. This action will return the study to a state where no configuration exists, and you would need to start again.

To perform this action, there must be zero Safety Cases in the development study. If you have already created Safety Cases in your development environment, you can delete non-production test data.

Deleting Post Go-Live: If your downstream environments (Test, Training, Production) have safety configurations and safety cases, this operation should never be performed. Even though the development study could delete its safety cases, and then the safety configuration, a later deployment to Test/Training/Production would fail.

To remove all safety configuration for a study:

  1. Navigate to Studio > Safety Settings for your Study.
  2. From the Actions menu, select Delete All Safety Configurations.

  3. In the confirmation dialog, type “DELETE” as instructed.
  4. Click Delete.

Download Specifications

You can download your safety configuration via the Study Design Specification or the All CRFs PDF export.

Deploying your Safety Configuration

Once you finish your configuration in your study’s DEV environment, you can deploy it to TST for testing, then onward into your training and production environments.

Your safety configuration, except for the Integration Setup and Connection, is automatically included in your study’s deployment package. When you deploy your study, Vault includes the current configuration in the package.

Because this configuration is managed as part of study deployments, you can only make changes in DEV type environments. To make changes, make them in the DEV environment and then deploy those changes to your other environments. This configuration is validated as part of casebook version publication. While validation is in progress, editing is disabled. A list of possible errors and warnings is available here.

Learn how to deploy a study.

Custom Safety Fields

The Safety-EDC Connection provides the most common safety-related fields, E2B and non-E2B, as Standard Safety Fields for mapping. Further flexibility of information transfer from EDC to Veeva Safety, additional Custom Safety Fields can be configured. The custom fields will appear alongside other standard fields on the Item Configurations menu of the safety data type that it applies.

  • In Veeva Safety, a Safety Case has several subsections, including Adverse Event, Cause of Death, Assessments, etc. This structure is represented in a hierarchical object structure. The Case object is the parent to all relevant case section objects, representing the safety case subsections in the UI, including Case Adverse Event, Case Cause of Death, Case Assessments etc.
  • The individual subsections of a Case can therefore be amended with Custom Safety Fields in Veeva Safety by adding entries into the respective Case child object. For more details, please refer to Veeva Safety Help.
  • When amending a Case child object in Veeva Safety, the most critical information for the following configuration in Veeva EDC is:
    • The child object (e.g. case_medical_history__v)
    • The exact custom field name (e.g. for a new custom field Chronic Condition, the field name could be chronic_condition__c).
  • To create a Custom Safety Field in Veeva EDC, a new Safety Connector Field Definitions entry must be created. To configure the correct location on one of the Safety Data Types for mapping, particularly the Grouping Property (i.e. which Safety Data Type to display the item on) and Display Order are relevant (details see below).
  • The data transfer from Veeva EDC to Veeva Safety is based on JSON. To allow the correct transfer to Veeva Safety, additionally, the JSON structure must be understood and configured in the new Safety Connector Field Definition, where the JSON Node Name must be identical to the custom field name in Veeva Safety for data matching (details see below).
  • Custom Safety Fields are configured on Vault level and will be available for mapping for both existing and new studies.
  • While the new Custom Safety Field is not mapped for existing studies, existing cases will remain unaffected and the configuration will not result in any Follow-Up messages.

Example 1

  • The Adverse Event subsection of a Safety Case in Veeva Safety houses the events of a safety case The Case Adverse Events object (case_adverse_event__v) provides the fields displayed in this subsection. The data found in this subsection is mostly found on the AE/SAE form of an EDC study. The fields transferred from Veeva EDC to Veeva Safety correspond to the fields on the Safety Case Initiation Event data type. In the Safety user interface, these appear here:

  • Below, we have added two additional Custom Safety Fields in the Veeva Safety object. Note that these fields have a trailing “__c”, Pain Score (pain_rating__c) and Occurrence per Day (occur_per_day__c):

  • Once the fields are set up on the corresponding Safety Data Type, the fields are then available alongside the Standard Safety Fields for mapping:

Example 2

  • The Test Results subsection in Veeva Safety displays all fields configured for the test results of a safety case on the Case Test Results object (case_test_result__v). These records are usually configured in EDC lab results forms and are mapped to the Test Results data type.
  • In the Safety user interface, these appear here:

  • Below, we have added a custom field in the Veeva Safety object, Re-collection Date (recollection_date__c):

  • Once accounted for on the EDC side, the fields are available alongside the Standard Safety Fields:

Add Custom Safety Field in EDC

The configuration of a Custom Safety Field in Veeva EDC is performed at the vault level. The new field will be available for mapping in all existing and new studies.

There are important considerations for custom safety fields:

  • Consult a Veeva representative regarding the planning and steps necessary to successfully configure and best utilize this functionality.
  • The creation or update of Custom Safety Fields requires careful coordination between the Veeva EDC and Veeva Safety configuration.
  • Misconfiguration of a Custom Safety Field can lead to the corruption of the data transfer from Veeva EDC to Veeva Safety.
  • Also consider program level decisions, involving EDC design teams, Safety users, even possibly members using other Veeva applications.
  • The configuration of Custom Safety Fields in Veeva Safety is recommended to precede the configuration in Veeva EDC.
  • An account with the Vault Owner security profile is required in both Veeva Safety and Veeva EDC for configuration.
  • Configuration on the EDC side of the connection is performed once in the Development vault / ‘control center’. To move the configuration from Development vaults to Test, Production, or Training, use a vault-level deployment from System Tools, with safety option checked.

Vault Owner Required: A user with the Vault Owner security profile must configure custom safety fields.

To configure a Custom Safety Field corresponding with Veeva Safety in Veeva EDC:

  1. Navigate to Business Admin > Objects > Safety Connector Field Definitions.

  2. Click Create to add a new record
  3. Fill out the new record with the following field level information guidelines below.
  4. Click Save.
Vault Field Value Notes
Name (text) The naming is recommended to be consistent with other standard/field names, by safety data type, already in the list. For example MH_CHRONIC_CONDITION for a field collecting whether the medical history is ‘Chronic Condition’ or not. The ‘MH_’ text prepended mirrors other MH fields.
Cross Vault Unique ID (::Name) Must be prepended with two colons. Recommended is to use the same value as Name with a ‘::’ prepended. For example ::MH_CHRONIC_CONDITION
Grouping Property (Picklist) This field is the Safety Data Type (area) and is recommended to match the destination subsection of the safety case in Veeva Safety. For example, information for the Adverse Event section should be located on the Safety Case Initiation Event.
  • Safety Case Initiation Event
  • Concomitant Medications
  • Drug History
  • In Case of Death
  • Medical History
  • Patient Characteristics
  • Study Drug
  • Test Results
Display Order (Integer value) Typically this is a value greater than all other existing values already of that safety data type (grouping property). It will dictate the position, reading down, the row appears on the Item Configurations list for that safety data type. In case an existing value is chosen, the order of appearance in relation to the duplicated entry is not deterministic.
Label (text) The label displayed for the Custom Safety Field on the Safety Data Type in Studio for mapping (e.g. Re-collection Date)
Hover Text (text) Optionally indicate any text to appear in an ‘i’ hover icon, next to the label
JSON Parent (text) Note: Veeva Consultant support is recommended for the configuration of this field. If an invalid value is inserted, the data transfer from EDC to Safety will be corrupted. No system validation for a misconfiguration is in place.

The value corresponds to the JSON file exchanged between the two systems. Only use a value based on the location in safety and EDC safety data type of the field:

Value to Use EDC Safety Data Types Location in Veeva Safety
event Safety Case Initiation Event case_adverse_event__v
medical_history Medical History case_medical_history__v
drug_history Drug History case_drug_history__v
test_results Test Results case_test_results__v
products Study Drug (or Concomitant Medications) case_product__v
products/dispense Study Drug (or Concomitant Medications) case_product_dosage__v
(no value) Patient Characteristics case_version__v
JSON Node Name (text) This value must match the exact field name in Veeva Safety. For example, if the field MH_CHRONIC_CONDITION is located in Veeva Safety case_medical_history__v.chronic_condition__c, then use chronic_condition__c.
System Only Field Always set No Only No is supported
System Managed Record Always set No Only No is supported
Needs Value for Related Eligible Always set No Only No is supported
Allow Static Value Yes or No With Yes selected, the row in the Item Configurations UI will allow a static value in the flow to safety, instead of a value from an Item Configuration / field on the EDC Form in Data Entry.
Multiple Values with Date Always set No Only No is supported
Safety Field Data Type See notes. The type of field, e.g. Date, Numeric, Text. Depending on the type, additional configuration is required in other fields of the record:
Type Other Fields Needing Values
Text Safety Max Length
Numeric Safety Max Length
Number with Precision Safety Max Length, Safety Max Precision
Boolean
Mapped Value
Date
Date / Datetime
Date / Numeric / Text
Safety Max Length Integer value Indicate the value configured on the field in safety. Refer to Safety Field Data Type.
Safety Max Precision Integer value For fields that allow precision, indicate that value here. Refer to Safety Field Data Type.
Definition Status Always leave blank Only blank for this field means “Active”. The status Archived will make the field no longer visible in Studio.
Vocabulary Synch Type See notes. Value here only applies when the Safety Field Data Type is Mapped Value. Depending on the selection the next field - Vocabulary Synch Record Information - requires additional information.
Vocabulary Synch Record Information See notes. Based on the Vocabulary Synch Type selected, this field instructs EDC where to find those choices.
  • For Picklist - indicate that exact picklist name name in Veeva Safety
  • For Controlled Vocabulary - indicate the subset of records from that object in Veeva Safety by its Type value.
  • For Static List - a specific JSON format is required, contact Veeva for any assistance needed. This choice is only used when a master picklist in Veeva Safety would offer non-applicable choices for the field in EDC.
Common Field Always set No Only No is supported
Multi Picklist Yes or No
  • Only applicable when the Safety Field Data Type is Mapped Value, and Vocabulary Synch Type is Picklist.
  • With Yes selected, the Safety Field in Studio will allow for multiple Item Definitions configured. This should only be done if the field in Veeva Safety is configured to accept multiple values.
Answer for Each Study Drug Always set No Only No is supported
Paired to an Item to Form Link Always set No Only No is supported

From Example 2 in the examples section previously, the Re-collection Date custom field properly configured appears as:

Deploying Custom Fields

  • The configuration of Custom Safety Fields in Veeva EDC is performed once in the EDC vault containing your development environment (“control center”).
  • To move the configuration from Development vaults to other vaults (Test/UAT, Production, Training), do not re-perform the steps in the downstream vaults.
  • Instead use the Vault Deployment option at Tools > System Tools, with Safety Connector Definitions checked:

  • For more information on Vault level deployments in Veeva EDC, see Deploying Vault-level Configuration in System Tools.

Custom Safety Values for Standard & Custom Fields

In Veeva Safety, Vault Picklists or the records of a Controlled Vocabulary object are used to define the available values for specific Standard and Custom Safety Fields (e.g. the available options for Action Taken with drug). The available options can be configured with additional choices beyond the standard set (e.g. adding “Dose interrupted” to Action Taken with drug).

In Veeva EDC, if a field is mapped to a Standard or Custom Field with specified available options on the Veeva Safety side, it will require Value Translations in the Item configuration step.

A field on a Safety Data Type requiring Value Translations can be identified by its Safety Connector Field Definition having the Safety Field Data Type set to Mapped Value. To make newly configured or updated options available in Veeva EDC, the Connection Safety Scan job has to be re-executed. In EDC, Item Definitions of type Codelists or Boolean are usually mapped to these Safety Fields.

Safety Field value updates are configured on Vault level and will apply to both existing and new studies. Implications on existing studies have to be considered.

Example 1

The Action Taken with Study Drug safety field on the Safety Case Initiation Event is an important answer regarding a safety event and the study drugs of the study. Choices for that in Veeva Safety can be supplemented with an additional custom choice, Drug Temporarily Discontinued / Interrupted:

Once the EDC Vault is synchronized with Veeva Safety (next section) the additional choice will appear as a choice in Value Translations of the EDC Item Configurations of study design.

Example 2

The safety field Delivery Method available for Safety Case Initiation Event and Patient Characteristics has three standard choices. A fourth custom choice on that Picklist for Unknown would be configured in Veeva Safety as:

In the same way as example 1, once the EDC Vault is synchronized with Veeva Safety, the fourth choice appears for configuring Value Translations.

Synchronize Custom Safety Values to EDC

There are important considerations regarding custom values:

  • Similar to Custom Safety Fields, consult a Veeva representative regarding the planning and steps necessary to successfully configure and best utilize this functionality.
  • Implications to existing studies have to be considered.
  • Missing synchronization Safety Field choices can lead to the corruption of the data transfer from Veeva EDC to Veeva Safety.
  • Updating Custom Safety Field Values might result in validation errors for existing studies, if the values remain without Value Translation in EDC. Updated Value Translations in EDC might result in Follow-Up messages to existing cases.
  • For the custom fields, carefully planning the addition or adjustment of Safety Field choices requires careful coordination between the Veeva EDC and Veeva Safety configuration. Also consider program level decisions, involving EDC design teams, Safety users, even possibly members using other Veeva Vault applications (RIM, CTMS, ..).
  • The configuration of Custom Safety Fields in Veeva Safety is recommended to precede the configuration in Veeva EDC.
  • In Veeva Safety, Vault Owner access is necessary to configure the choices.
  • In Veeva EDC, choices are synchronized using a Vocabulary Scan Job at the System Tools > Connections > Safety location
  • Configuration on the EDC side of the connection is performed once in the EDC vault containing your development-type environments (“control center”). To move the configuration from Development vaults to Test/UAT, Production, Training , use a vault-level deployment from System Tools, with safety option checked.

To synchronize newly created / updated choices from Veeva Safety to the Veeva EDC Studio screens:

  1. Navigate to your Connection in System Tools > Connections > Safety.
  2. Hover over the connection’s Name to show the Scan button.
  3. Click Scan.

  4. In the Scan Vault Safety dialog, click Run Job.

When Vault finishes the job, you will receive an email notification and the value translations choices of all safety fields in EDC study configuration will reflect those from the paired Veeva Safety.

Deploying Custom Values

  • Configuration on the EDC side of the connection for custom values is performed once in the EDC vault containing your development environment (“control center”).
  • To move the configuration from Development vaults to other vaults (Test/UAT, Production, Training), do not re-perform the steps in the downstream vaults.
  • Instead use the Vault Deployment option at Tools > System Tools, with Safety Connector Definitions checked:

  • For more information on Vault level deployments in Veeva EDC, see Deploying Vault-level Configuration in System Tools.

Safety Field Reference (System Generated)

This page lists static and system-generated elements that are sent to Veeva Safety in the Safety Case.

Safety Field Data Type Source Explanation
Study Label Text Static The Study Label in Veeva EDC. It can be specially overridden using a safety setting.
Study Number Text Static The Study Label in Veeva EDC. It can be specially overridden using a safety setting.
Date Report Was First Received from Source Datetime System Generated This field captures the date and time when all required fields (Items) are captured for an event.
Date of Most Recent Information for This Report Datetime System Generated Indicates the first change made on a given date by a data entry user involving data in the safety case, after the last safety message was sent. For example, if on the same date a user first changes data on a Medical History form at 8 AM, then changes data on the SAE form at 10 AM, and finally links two Concomitant Medication forms at 11 AM, with all changes made to data in the same safety case, the value will be 8 AM on that date in the next scheduled transfer.
Reporter's Information Text From Site or User Entered Depending on the study’s option for Reporter (Safety Settings) this will be from the site’s principal investigator. In the Safety-EDC Connection specific EDC form items can be mapped to each piece of the reporter information. When filled out, they override the base site / PI information
Identification of the Country Where the Reaction/Event Occurred Text (2) From Site or User 2 character country code for the site’s Study Country. Or, can be mapped on the data entry form for the site to override. (e.g. event occurs when the subject is out of country)