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.

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.

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

Updating Settings

To set the main safety settings for the study design:

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.

Available Settings

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	Yes	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 the + New Form Configuration button will only become active after the configuration of the Safety 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 example 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 safety data 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 Data Types

Each form configured for safety integration includes a Safety Data 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.

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.

Delete a Form Configuration

You can delete a single Form Configuration or delete 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.

Copy Form Configurations

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 Copying Designs.

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 safety data type.

Safety Data 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 and required for the safety data type Indicates that this property is present and optional for the safety data 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.

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:

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 to be set to Repeating item group in form.

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-type 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

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.

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

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:

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.

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.

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.

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.

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.

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 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.

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 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.

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.

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.

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 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.

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 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.

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 an E2B location is of the codelist or boolean (checkbox) data types, and the E2B location requires very specific E2B 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-type Item, 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-type Items, 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.

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 safety data 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 safety data 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 safety data 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.

Item to Form Link Association

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. Events will appear in this section in Veeva Safety:

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

1. Navigate to your Study in Studio > Form Configurations.

2. Navigate into the safety form configuration, then to the Item Configurations tab.

3. 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 (pictured below). 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.
   

4. 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.

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:
   • Static Value
   • Paired Date
   • Study Drug
   • Item to Form Link
7. Click Save (to remain on the page) or Save and Next (to advance to the next tab, Inclusion Criteria).

EDC Safety Data Type	EDC Field Label	Field Data Type	Notes	Relevant E2B (R3) Locations	Inbox Item / Case Object & Field	EDC Field Identifier
Safety Case Initiation Event	Event Reported	Text (250)	The verbatim / event ‘Term’, e.g. ‘Stroke’, ‘Severe Headaches’ Mapping is required Also, a value in data entry is required to initiate the first send of a safety case	E.i.1.1a, E.i.1.2	case_adverse_event__v, event_reported__v	AE_EVENT_REPORTED
Safety Case Initiation Event	Event Reported (Coding LLT)	Text (8)	The coding (LLT value) for the verbatim / event term If coding is configured on Event Reported, it will be automatically set at this location	E.i.2.1a, E.i.2.1b	case_adverse_event__v, event_meddra__v	AE_CODING_LLT
Safety Case Initiation Event	Start / Onset Date	Date/Datetime	This value will be key in any date based inclusion criteria Unknown parts (day / month / time) are supported	E.i.4	case_adverse_event__v, onset_idate__v	AE_START_DATE
Safety Case Initiation Event	End / Resolved Date	Date	This value will be key in any date based inclusion criteria Unknown parts (day / month / time) are supported	E.i.5	case_adverse_event__v, resolved_idate__v	AE_END_DATE
Safety Case Initiation Event	Outcome	Mapped Value	Outcome of the event	E.i.7	case_adverse_event__v, outcome__v	AE_OUTCOME
Safety Case Initiation Event	Serious	Mapped Value	Often, this is also the Safety Key Item on the Form Properties tab For studies sending both serious adverse events and “Adverse Events of Special Interest” (AESI; usually non-serious) to safety, one would use a different Item Definition for the Safety Key Item. See also the examples at:	E.i.3.1	case_adverse_event__v, highlighted_term__v	AE_SERIOUS
Safety Case Initiation Event	Adverse Event of Special Interest	Boolean	Field is part of ‘watch list’ concept in Veeva Safety		case_adverse_event__v, aesi_watchlist__v	AE_AESI
Safety Case Initiation Event	Seriousness Criteria	Mapped Value	Multiple value location in Veeva Safety For ‘select all that apply’ form design, configure a row for each of the Item Definitions to the appropriate safety value Veeva recommends usage of a codelist type Item Definition, as a checkbox type doesn’t require the very specific user action of answering the ‘No’. For value translations, you would map the Yes answer to the appropriate value of the Veeva Safety picklist	E.i.3.2a, E.i.3.2b, E.i.3.2c, E.i.3.2d, E.i.3.2e, E.i.3.2f	case_adverse_event__v, seriousness__v	AE_SERIOUSNESS_CRITERIA
Safety Case Initiation Event	CTCAE Grade	Mapped Value	Common important field in safety and on most EDC forms Not a standard E2B field, but standard in the Safety-EDC Connection		case_adverse_event__v, ctcae_grade__v	AE_CTCAE_GRADE
Safety Case Initiation Event	Severity	Mapped Value	Common important field in safety and on most EDC forms Not a standard E2B field, but standard in the Safety-EDC Connection		case_adverse_event__v, severity__v	AE_SEVERITY
Safety Case Initiation Event	Age at Onset	Numeric (3)	Only items of non repeating item groups are choices for this location, since it is a single value for a safety case. For study configuration allowing multiple events in a safety case, the answer from the primary event is used. This value is also mappable from the Patient Characteristics type. However, mapping on the event form will be more accurate for longer running trials	D.2.2a	case_version__v, age_value__v (with age_calculation_status__v set to “Yes”)	AE_AGE_AT_ONSET
Safety Case Initiation Event	Age at Onset Unit	Mapped Value	Only items from non repeating item groups are choices for this location, since it is a single value for a safety case. Static value configuration is allowed, e.g. years__v	D.2.2b	case_version__v, age_unit__v	AE_AGE_AT_ONSET_UNIT
Safety Case Initiation Event	Country Event Occurred	Text (2)	If mapped, the value here must be a valid 2 character ISO code for a country, e.g. US, UK, BE, etc. If this location is not mapped, the country code of the site is used instead. A common use of this field is to ask the data entry user “If the country where the event started is a different country than that of the site, enter the country where the event occurred.” This allows an override for out of country event occurrences	E.i.9	case_adverse_event__v, event_country__v	AE_EVENT_COUNTRY
Safety Case Initiation Event	Symptom / Diagnosis	Mapped Value	Not a standard E2B field, but standard in the Safety-EDC Connection		case_adverse_event__v, symptom_diagnosis__v	AE_SYMPTOM_DIAGNOSIS
Safety Case Initiation Event	Expedited Event	Boolean	Not a standard E2B field, but standard in the Safety-EDC Connection		case_adverse_event__v, expedited_flag__v	AE_EXPEDITED_FLAG
Safety Case Initiation Event	Healthcare Professional Confirmed	Boolean	This is typically a ‘Yes’ in a clinical trial safety case The study setting for Auto Set Medically Confirmed will also ensure a value here of true / “Yes”	E.i.8	case_adverse_event__v, hcp_confirmed__v	AE_HCP_CONFIRMED
Safety Case Initiation Event	Hospital Admission Date	Date	Common important field in safety and on most EDC forms Not a standard E2B field, but standard in the Safety-EDC Connection		case_adverse_event__v, hospital_admission_date__v	AE_HOSPITAL_ADM_DATE
Safety Case Initiation Event	Hospital Discharge Date	Date	Common important field in safety and on most EDC forms Not a standard E2B field, but standard in the Safety-EDC Connection		case_adverse_event__v, hospital_discharge_date__v	AE_HOSPITAL_DISCHARGE_DATE
Safety Case Initiation Event	Days Hospitalized	Numeric (4)	Can be auto calculated on the Veeva Safety Side Otherwise, could be an EDC asked question if admission / discharge dates are not collected		case_adverse_event__v, days_hospitalized__v	AE_DAYS_HOSPITALIZED
Safety Case Initiation Event	Hospital Name	Text (200)	Common important field in safety and on most EDC forms Not a standard E2B field, but standard in the Safety-EDC Connection		case_adverse_event__v, hospital_name__v	AE_HOSPITAL_NAME
Safety Case Initiation Event	Hospital City	Text (35)	Common important field in safety and on most EDC forms Not a standard E2B field, but standard in the Safety-EDC Connection		case_adverse_event__v, hospital_city__v	AE_HOSPITAL_CITY
Safety Case Initiation Event	Hospital State	Text (40)	Common important field in safety and on most EDC forms Not a standard E2B field, but standard in the Safety-EDC Connection		case_adverse_event__v, hospital_state__v	AE_HOSPITAL_STATE
Safety Case Initiation Event	Narrative	Text (30000)	In Veeva Safety the narrative from EDC will import to a dedicated field Tokens are then used to include this transferred text into the wider case narrative Use a repeating or non repeating item group with this field. The Each Entry In setting will not apply here for choices. The Veeva EDC text item definition allows 1500 characters per field. To allow for longer entries, use a repeating item group with a single item in the item group. Veeva EDC will automatically concatenate the entered text for transfer via the E2B XML	H.1 (as token from site narrative)	case_version__v, site_narrative__v	AE_NARRATIVE
Safety Case Initiation Event	Reporter Comments	Text (20000)	Use a repeating or non repeating item group with this field. The Each Entry In setting will not apply here for choices. The Veeva EDC text item definition allows 1500 characters per field. To allow for longer entries, use a repeating item group with a single item in the item group. Veeva EDC will automatically concatenate the entered text for transfer via the E2B XML	H.2	case_version__v, reporters_comments__v	AE_REPORTER_COMMENTS
Safety Case Initiation Event	Sender Comments	Text (20000)	Use a repeating or non repeating item group with this field. The Each Entry In setting will not apply here for choices. The Veeva EDC text item definition allows 1500 characters per field. To allow for longer entries, use a repeating item group with a single item in the item group. Veeva EDC will automatically concatenate the entered text for transfer via the E2B XML	H.4	case_version__v, sender_comments__v	AE_SENDER_COMMENTS
Safety Case Initiation Event	Nullification Reason	Text (200)	Only items from non repeating item groups are choices for this location, since it is a single value for a safety case. Mapping of this field allows the user to enter a reason for downgrade, reset of form, or other reason. Site users must enter that reason before the next follow-up job, as a nullification to safety is the final message. Lack of a value in data entry or not mapping this field results in a system generated reason sent with that last transfer/follow-up of the case.	C.1.11.2	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 Case data model.)	AE_NULLIFY_REASON
Safety Case Initiation Event	Reporter Qualification	Mapped Value	Field is often auto set in safety on the receiving side, not necessarily answered by the site user Static value configuration is allowed	C.2.r.4	case_contact__v, qualification__v	AE_REPORTER_QUALIFICATION
Safety Case Initiation Event	Reported Language	Text (20)	Typically not derivable from EDC, since a user entering the value may not be in a session or site that matches the language of entry	E.i.1.1b	case_adverse_event__v, event_reported_language__v	AE_REPORTER_LANGUAGE
Safety Case Initiation Event	Reporter Country	Text (2)	If not mapped and the study safety setting for Reporter is Full Site Information or Principal Investigator Only, the EDC site name will be transferred	C.2.r.3	case_contact__v, country_value__v (if valid 2 char ISO country)	AE_REPORTER_COUNTRY
Safety Case Initiation Event	Reporter First Name	Text (50)	If not mapped and the study safety setting for Reporter is Full Site Information or Principal Investigator Only, the EDC site name will be transferred An EDC item for this value would be used for rarer situations where a Sub PI is the reporter, i.e. not the same as the PI noted in site information	C.2.r.1.2	case_contact__v, firstname_value__v	AE_REPORTER_FIRST_NAME
Safety Case Initiation Event	Reporter Last Name	Text (50)	If not mapped and the study safety setting for Reporter is Full Site Information or Principal Investigator Only, the EDC site name will be transferred An EDC item for this value would be used for rarer situations where a Sub PI is the reporter, i.e. not the same as the PI noted in site information	C.2.r.1.4	case_contact__v, lastname_value__v	AE_REPORTER_LAST_NAME
Safety Case Initiation Event	Reporter Organization	Text (100)	If not mapped and the study safety setting for Reporter is Full Site Information, the EDC site name will be transferred	C.2.r.2.1	case_contact__v, organization_value__v	AE_REPORTER_ORGANIZATION
Safety Case Initiation Event	Reporter Email	Text (100)	If not mapped and the study safety setting for Reporter is Full Site Information, the EDC site’s investigator email will be transferred		case_contact__v, email_address__v	AE_REPORTER_EMAIL
Safety Case Initiation Event	Reporter Telephone	Text (33)	If not mapped and the study safety setting for Reporter is Full Site Information, the EDC site’s investigator phone will be transferred	C.2.r.2.7	case_contact__v, telephone_value__v	AE_REPORTER_TELEPHONE
Safety Case Initiation Event	Reporter Street 1	Text (100)	If not mapped and the study safety setting for Reporter is Full Site Information, the EDC site information value will be transferred	C.2.r.2.3	case_contact__v, street_value__v	AE_REPORTER_STREET
Safety Case Initiation Event	Reporter Street 2	Text (100)	If not mapped and the study safety setting for Reporter is Full Site Information, the EDC site information value will be transferred	C.2.r.2.3	case_contact__v, street_line_2_value__v	AE_REPORTER_STREET_2
Safety Case Initiation Event	Reporter City	Text (35)	If not mapped and the study safety setting for Reporter is Full Site Information, the EDC site information value will be transferred	C.2.r.2.4	case_contact__v, city_value__v	AE_REPORTER_CITY
Safety Case Initiation Event	Reporter State / Province	Text (40)	If not mapped and the study safety setting for Reporter is Full Site Information, the EDC site information value will be transferred	C.2.r.2.5	case_contact__v, state_province_value__v	AE_REPORTER_STATE_PROVINCE
Safety Case Initiation Event	Reporter Postal Code / Zip	Text (15)	If not mapped and the study safety setting for Reporter is Full Site Information, the EDC site information value will be transferred	C.2.r.2.6	case_contact__v, postalcode_value__v	AE_REPORTER_POSTAL_ZIP
Safety Case Initiation Event	Overall Action Taken	Mapped Value	Typically, an answer would be given for each study drug of the trial However, for an overall roll-up value (done via EDC Studio Rules), additionally map to this location	G.k.8	,	AE_ACTION_TAKEN
Safety Case Initiation Event	Concomitant Medication Drug Role	Mapped Value	Special mapping location that allows the site user to give an answer to for a concomitant medication drug role Without this mapped, the default value in safety will be Concomitant for any included products/medications via the Concomitant Medications safety data type Special situations can warrant the site opinion that a concomitant medication is instead the role Interacting or even Suspect for the safety case	G.k.1	case_product__v, drug_role__v
Safety Case Initiation Event	Action Taken with Study Product	Mapped Value	Static value configuration is allowed If mapping this location, map a for each Study Drug configured in the study	G.k.8	case_assessment_result__v, action_taken__v	AE_PRODUCT_ACTION_TAKEN
Safety Case Initiation Event	Did Reaction / Event Recur when Study Drug Resumed	Mapped Value	Static value configuration is allowed If mapping this location, map a for each Study Drug configured in the study	G.k.9.i.4	case_assessment__v, reaction_recurrence__v	AE_PRODUCT_ACTION_RECUR
Safety Case Initiation Event	Result of Assessment to Study Drug	Mapped Value	Static value configuration is allowed If mapping this location, map a for each Study Drug configured in the study Part of the important causality answer in safety cases, together with Method and Source	G.k.9.i.2.r.3	case_assessment_result__v, assessment_result__v or result_text__v	AE_PRODUCT_ASSESS_RESULT
Safety Case Initiation Event	Method of Assessment to Study Drug	Text (60)	Static value configuration is allowed If mapping this location, map a for each Study Drug configured in the study Part of the important causality answer in safety cases, together with Result and Source	G.k.9.i.2.r.2	case_assessment_result__v, method_of_assessment__v or method_text__v	AE_PRODUCT_ASSESS_METHOD
Safety Case Initiation Event	Source of Assessment to Study Drug	Text (60)	Static value configuration is allowed If mapping this location, map a for each Study Drug configured in the study Part of the important causality answer in safety cases, together with Result and Method	G.k.9.i.2.r.1	case_assessment_result__v, source_type__v or source_text__v	AE_PRODUCT_ASSESS_SOURCE
Safety Case Initiation Event	Pregnancy Case	Boolean	Field, when transferred as true, will turn on the pregnancy functionality of the safety case in Veeva Safety		case_version__v, pregnancy__v	AE_PREG_CASE
Safety Case Initiation Event	Pregnancy Occurrences	Numeric (2)	Map when a form should start a transfer due to unexpected pregnancy (instead of adverse event) The Patient Characteristics safety data type also has this as an available mapping, but there is would apply to ALL cases of a subject. Here, the information is only apart of the case that includes the pregnancy form		case_version__v, gravida_gravidity__v	AE_PREG_INFO_GRAV
Safety Case Initiation Event	Number Given Birth	Numeric (2)	Map when a form should start a transfer due to unexpected pregnancy (instead of adverse event) The Patient Characteristics safety data type also has this as an available mapping, but there is would apply to ALL cases of a subject. Here, the information is only apart of the case that includes the pregnancy form		case_version__v, para_parity__v	AE_PREG_INFO_PARA
Safety Case Initiation Event	Pregnant at Study Drug Exposure	Boolean	Map when a form should start a transfer due to unexpected pregnancy (instead of adverse event) The Patient Characteristics safety data type also has this as an available mapping, but there is would apply to ALL cases of a subject. Here, the information is only apart of the case that includes the pregnancy form		case_version__v, pregnancy_at_vaccination__v	AE_PREG_INFO_AT_VX
Safety Case Initiation Event	Last Menstrual Date (Pregnancy Case)	Date	Map when a form should start a transfer due to unexpected pregnancy (instead of adverse event) The Patient Characteristics safety data type also has this as an available mapping, but there is would apply to ALL cases of a subject. Here, the information is only apart of the case that includes the pregnancy form	D.6	case_version__v, last_menstrual_idate__v	AE_PREG_LAST_MENSTRUAL_DATE
Safety Case Initiation Event	Pregnancy Conception Date	Date	Map when a form should start a transfer due to unexpected pregnancy (instead of adverse event) The Patient Characteristics safety data type also has this as an available mapping, but there is would apply to ALL cases of a subject. Here, the information is only apart of the case that includes the pregnancy form		case_version__v, pregnancy_conception_idate__v	AE_PREG_INFO_CONC_DT
Safety Case Initiation Event	Pregnancy Due Date	Date	Map when a form should start a transfer due to unexpected pregnancy (instead of adverse event) The Patient Characteristics safety data type also has this as an available mapping, but there is would apply to ALL cases of a subject. Here, the information is only apart of the case that includes the pregnancy form		case_version__v, pregnancy_due_idate__v	AE_PREG_INFO_DUE_DT
Safety Case Initiation Event	Date of Pregnancy Outcome	Date	Map when a form should start a transfer due to unexpected pregnancy (instead of adverse event) The Patient Characteristics safety data type also has this as an available mapping, but there is would apply to ALL cases of a subject. Here, the information is only apart of the case that includes the pregnancy form		case_version__v, idate_of_pregnancy_outcome__v	AE_PREG_INFO_OUTCOME_DT
Safety Case Initiation Event	Pregnancy Outcome	Mapped Value	Multiple value location in Veeva Safety For ‘select all that apply’ form design, configure a row for each of the Item Definitions to the appropriate safety value Map when a form should start a transfer due to unexpected pregnancy (instead of adverse event) The Patient Characteristics safety data type also has this as an available mapping, but there is would apply to ALL cases of a subject. Here, the information is only apart of the case that includes the pregnancy form		case_version__v, pregnancy_outcome__v	AE_PREG_INFO_OUTCOME
Safety Case Initiation Event	Delivery Method	Mapped Value	Multiple value location in Veeva Safety For ‘select all that apply’ form design, configure a row for each of the Item Definitions to the appropriate safety value Map when a form should start a transfer due to unexpected pregnancy (instead of adverse event) The Patient Characteristics safety data type also has this as an available mapping, but there is would apply to ALL cases of a subject. Here, the information is only apart of the case that includes the pregnancy form		case_version__v, delivery_method__v	AE_PREG_INFO_DELV_METH

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.

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

1. Navigate to your Study in Studio > Form Configurations.

2. Navigate into the safety form configuration, then to the Item Configurations tab.

3. 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 (pictured below). 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.
   

4. 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.
5. Depending on the Safety Field additional information may be required. Use the appropriate cell in the row to provide this information:
   • Static Value
   • Paired Date
6. Click Save (to remain on the page) or Save and Next (to advance to the next tab, Inclusion Criteria).

EDC Safety Data Type	EDC Field Label	Field Data Type	Notes	Relevant E2B (R3) Locations	Inbox Item / Case Object & Field	EDC Field Identifier
Study Drug	Start Date	Date/Datetime	Required mapping A value in EDC Data Entry must be set for the form / item group to be eligible for transfer Once a non-empty value is set in data entry, the entry is then processed against the configured Inclusion Criteria If End Date is not mapped on the EDC form, the value for start date is used for end date when evaluating inclusion criteria rules.	G.k.4.r.4	case_product_dosage__v, firstadmin_idate__v	SD_START_DATE
Study Drug	End Date	Date/Datetime	If no item is mapped to this location, Veeva EDC will use the start date value as the end date for inclusion criteria rules In either case, once a non-empty value is set in data entry, the entry is then processed against the configured Inclusion Criteria	G.k.4.r.5	case_product_dosage__v, lastadmin_idate__v	SD_END_DATE
Study Drug	Duration of Dispense Value	Numeric with Precision (5,3)	Often a calculated value in the destination safety system, i.e. not asked/answered on the EDC form	G.k.4.r.6a	case_product_dosage__v, duration_number__v	SD_DURATION_VALUE
Study Drug	Duration of Dispense Unit	Mapped Value	Static value configuration is allowed Often a calculated value in the destination safety system, i.e. not asked/answered on the EDC form	G.k.4.r.6b	case_product_dosage__v, duration_unit__v	SD_DURATION_UNIT
Study Drug	Dose Value (Number)	Numeric with Precision (9,3)	Avoid non-numeric Item Definition here If study design changes yield a non numeric value, Veeva Safety will move the value to the Dose Value (Text) location	G.k.4.r.1a	case_product_dosage__v, dose_number__v	SD_DOSE_VALUE_NUMBER
Study Drug	Dose Value (Text)	Text (2000)	Direct non structured data to this location Often used for derived fields on the EDC form, to then pass on other information about the dispense that doesn’t fit into other locations	G.k.4.r.8	case_product_dosage__v, dose_text_long_text__v	SD_DOSE_VALUE_TEXT
Study Drug	Dose Unit (Code)	Mapped Value	Static value configuration is allowed	G.k.4.r.1b	case_product_dosage__v, dose_unit__v	SD_DOSE_UNIT_CODE
Study Drug	Dose Unit (Text)	Text (50)	Used for dose units that do not have a standard mapping in Veeva safety Examples: Capsule, Tablet	G.k.4.r.8	case_product_dosage__v, dose_unit_text__v	SD_DOSE_UNIT_TEXT
Study Drug	Frequency Value	Numeric with Precision (4,8)	The value part of frequency, e.g. the ‘1’ if ‘once daily’	G.k.4.r.2	case_product_dosage__v, frequency_number__v	SD_FREQUENCY_VALUE
Study Drug	Frequency Unit	Mapped Value	Static value configuration is allowed Often an EDC field for frequency will be setup as one Item Definition, a codelist with common choices like QID (4 times a day), BID (twice a day), and so on If so, these answers must be split into two locations (value and unit), likely via a derived rule on the form, below the site’s answer	G.k.4.r.3	case_product_dosage__v, frequency_unit__v	SD_FREQUENCY_UNIT
Study Drug	Route (Code)	Mapped Value	The structured route value, e.g. 048 = oral__v	G.k.4.r.10.2b	case_product_dosage__v, patient_adminroute__v	SD_ROUTE_CODE
Study Drug	Route (Text)	Text (60)	For route values that are not a standard value	G.k.4.r.10.1	case_product_dosage__v, patient_adminroute_text__v	SD_ROUTE_TEXT
Study Drug	Route Term ID	Text (50)	Usually not answered on an EDC form by site user	G.k.4.r.10.2b	case_product_dosage__v, patient_adminroute_termid__v	SD_ROUTE_TERM_ID
Study Drug	Route Term ID Version	Text (50)	Usually not answered on an EDC form by site user Static value configuration is allowed	G.k.4.r.10.2a	case_product_dosage__v, patient_adminroute_termid_version__v	SD_ROUTE_TERM_ID_VERSION
Study Drug	Site of Dispense	Mapped Value	Not a standard E2B field, but standard in the Safety-EDC Connection		case_product_dosage__v, anatomical_site__v	SD_SITE_OF_DISPENSE
Study Drug	Batch / Lot Number	Text (35)	Common usage for this when not asked is ‘UNK’. Use an EDC derived rule to a hidden field or configure Veeva Safety to auto set the value when not present	G.k.4.r.7	case_product_dosage__v, batchlot_number__v	SD_BATCH_LOT_NUMBER
Study Drug	Dose Form Term ID	Text (50)	Usually not answered on an EDC form by site user	G.k.4.r.9.2b	case_product_dosage__v, dose_form_termid__v	SD_DOSE_FORM_TERM_ID
Study Drug	Dose Form Term ID Version	Text (50)	Usually not answered on an EDC form by site user Static value configuration is allowed	G.k.4.r.9.2a	case_product_dosage__v, dose_form_termid_version__v	SD_DOSE_FORM_TERM_ID_VERSION
Study Drug	Dose Form Text	Text (128)	Often used for derived fields on the EDC form, to then pass on other information about the dispense that doesn’t fit into other locations	G.k.4.r.9.1	case_product_dosage__v, dose_form_text__v	SD_DOSE_FORM_TEXT
Study Drug	Parent Route (Text)	Text (60)	Parent related dispense, e.g. parent-child/foetus reporting	G.k.4.r.11.1	case_product_dosage__v, parent_adminroute_text__v	SD_PARENT_ROUTE_TEXT
Study Drug	Parent Route (Code)	Mapped Value	Parent related dispense, e.g. parent-child/foetus reporting The structured route value, e.g. 048 = oral__v	G.k.4.r.11.2b	case_product_dosage__v, parent_adminroute__v	SD_PARENT_ROUTE_CODE
Study Drug	Parent Route Term ID	Text (50)	Parent related dispense, e.g. parent-child/foetus reporting	G.k.4.r.11.2b	case_product_dosage__v, parent_adminroute_termid__v	SD_PARENT_ROUTE_TERM_ID
Study Drug	Parent Route Term ID Version	Text (50)	Parent related dispense, e.g. parent-child/foetus reporting Static value configuration is allowed	G.k.4.r.11.2a	case_product_dosage__v, parent_adminroute_termid_version__v	SD_PARENT_ROUTE_TERM_ID_VERSION

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 Configurations step for this safety data type:

1. Navigate to your Study in Studio > Form Configurations.

2. Navigate into the safety form configuration, then to the Item Configurations tab.

3. 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 (pictured below). 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.
   

4. 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.
5. Click Save (to remain on the page) or Save and Next (to advance to the next tab, Inclusion Criteria).

EDC Safety Data Type	EDC Field Label	Field Data Type	Notes	Relevant E2B (R3) Locations	Inbox Item / Case Object & Field	EDC Field Identifier
Concomitant Medication	Product / Medication Reported	Text (250)	The name of the product / medication, e.g. Aspirin Required mapping A value in EDC Data Entry must be set for the form / item group to be eligible for transfer Once a non-empty value is set in data entry, the entry is then processed against the configured Inclusion Criteria	G.k.2.2	case_product__v, product_reported__v	CM_REPORTED
Concomitant Medication	Country Obtained	Text (2)	If not mapped to an item on the EDC form, this value will be automatically set to the study country of the subject’s site	G.k.2.4	case_product__v, country_obtained__v	CM_COUNTRY_OBTAINED
Concomitant Medication	Gestation Exposure Number	Numeric with Precision (3,3)	The value part, e.g. ‘3’ of third trimester	G.k.6a	case_product__v, gestation_exposure_number__v	CM_GESTATION
Concomitant Medication	Gestation Exposure Unit	Mapped Value	Static value configuration is allowed	G.k.6b	case_product__v, gestation_exposure_unit__v	CM_GESTATION_UNIT
Concomitant Medication	Device Name	Text (1000)	Not a standard E2B field, but standard in the Safety-EDC Connection		case_product__v, device_name_part__v	CM_DEVICE_NAME
Concomitant Medication	Device Evaluated	Mapped Value	Not a standard E2B field, but standard in the Safety-EDC Connection		case_product__v, device_evaluated__v	CM_DEVICE_EVALUATED
Concomitant Medication	Device Usage Type	Mapped Value	Not a standard E2B field, but standard in the Safety-EDC Connection Static value configuration is allowed		case_product__v, device_usage_type__v	CM_DEVICE_USAGE_TYPE
Concomitant Medication	Device Implanted Date	Date/Datetime	Not a standard E2B field, but standard in the Safety-EDC Connection		case_product__v, date_implanted_idate__v	CM_IMPLANTED_DATE
Concomitant Medication	Device Explanted Date	Date/Datetime	Not a standard E2B field, but standard in the Safety-EDC Connection		case_product__v, date_explanted_idate__v	CM_DEVICE_EXPLANTED_DATE
Concomitant Medication	Device Age	Numeric with Precision (5,4)	Not a standard E2B field, but standard in the Safety-EDC Connection		case_product__v, date_age__v	CM_DEVICE_AGE
Concomitant Medication	Device Age Unit	Mapped Value	Not a standard E2B field, but standard in the Safety-EDC Connection Static value configuration is allowed		case_product__v, device_age_unit__v	CM_DEVICE_AGE_UNIT
Concomitant Medication	Additional Information Coded	Mapped Value	Multiple value location in Veeva Safety Can be mapped to a repeating or non-repeating EDC item Field is used for reporting of Misuse, Overdose, etc.	G.k.10.r	case_product__v, additional_information_coded__v	CM_ADDITIONAL_INFO_CODED
Concomitant Medication	Start Date	Date/Datetime	If End Date is not mapped on the EDC form, the value for start date is used when processing Inclusion Criteria	G.k.4.r.4	case_product_dosage__v, firstadmin_idate__v	CM_START_DATE
Concomitant Medication	End Date	Date/Datetime	If no item is mapped to this location, Veeva EDC will use the start date value as the end date for inclusion criteria rules In either case, once a non-empty value is set in data entry, the entry is then processed against the configured Inclusion Criteria	G.k.4.r.5	case_product_dosage__v, lastadmin_idate__v	CM_END_DATE
Concomitant Medication	Duration of Dispense Value	Numeric with Precision (5,3)	Often a calculated value in the destination safety system, i.e. not asked/answered on the EDC form	G.k.4.r.6a	case_product_dosage__v, duration_number__v	CM_DURATION_VALUE
Concomitant Medication	Duration of Dispense Unit	Mapped Value	Static value configuration is allowed Often a calculated value in the destination safety system, i.e. not asked/answered on the EDC form	G.k.4.r.6b	case_product_dosage__v, duration_unit__v	CM_DURATION_UNIT
Concomitant Medication	Dose Value (Number)	Numeric with Precision (9,3)	Avoid non-numeric Item Definition here If study design changes yield a non numeric value, Veeva Safety will move the value to the Dose Value (Text) location	G.k.4.r.1a	case_product_dosage__v, dose_number__v	CM_DOSE_VALUE_NUMBER
Concomitant Medication	Dose Value (Text)	Text (2000)	Direct non structured data to this location Often used for derived fields on the EDC form, to then pass on other information about the dispense that doesn’t fit into other locations	G.k.4.r.8	case_product_dosage__v, dose_text__v	CM_DOSE_VALUE_TEXT
Concomitant Medication	Dose Unit (Code)	Mapped Value	Static value configuration is allowed	G.k.4.r.1b	case_product_dosage__v, dose_unit__v	CM_DOSE_UNIT_CODE
Concomitant Medication	Dose Unit (Text)	Text (50)	Used for dose units that do not have a standard mapping in Veeva safety Examples: Capsule, Tablet	G.k.4.r.8	case_product_dosage__v, dose_unit_text__v	CM_DOSE_UNIT_TEXT
Concomitant Medication	Frequency Value	Numeric with Precision (4,8)	The value part of frequency, e.g. the ‘1’ if ‘once daily’	G.k.4.r.2	case_product_dosage__v, frequency_number__v	CM_FREQUENCY_VALUE
Concomitant Medication	Frequency Unit	Mapped Value	Static value configuration is allowed Often an EDC field for frequency will be setup as one Item Definition, a codelist with common choices like QID (4 times a day), BID (twice a day), and so on If so, these answers must be split into two locations (value and unit), likely via a derived rule on the form, below the site’s answer	G.k.4.r.3	case_product_dosage__v, frequency_unit__v	CM_FREQUENCY_UNIT
Concomitant Medication	Route (Code)	Mapped Value	The structured route value, e.g. 048 = oral__v	G.k.4.r.10.2b	case_product_dosage__v, patient_adminroute__v	CM_ROUTE_CODE
Concomitant Medication	Route (Text)	Text (60)	For route values that are not a standard value	G.k.4.r.10.1	case_product_dosage__v, patient_adminroute_text__v	CM_ROUTE_TEXT
Concomitant Medication	Route Term ID	Text (50)	Usually not answered on an EDC form by site user	G.k.4.r.10.2b	case_product_dosage__v, patient_adminroute_termid__v	CM_ROUTE_TERM_ID
Concomitant Medication	Route Term ID Version	Text (50)	Usually not answered on an EDC form by site user Static value configuration is allowed	G.k.4.r.10.2a	case_product_dosage__v, patient_adminroute_termid_version__v	CM_ROUTE_TERM_ID_VERSION
Concomitant Medication	Site of Dispense	Mapped Value	Not a standard E2B field, but standard in the Safety-EDC Connection		case_product_dosage__v, anatomical_site__v	CM_SITE_OF_DISPENSE
Concomitant Medication	Batch / Lot Number	Text (35)	Common usage for this when not asked is ‘UNK’. Use an EDC derived rule to a hidden field or configure Veeva Safety to auto set the value when not present	G.k.4.r.7	case_product_dosage__v, batchlot_number__v	CM_BATCH_LOT_NUMBER
Concomitant Medication	Dose Form Term ID	Text (50)	Usually not answered on an EDC form by site user	G.k.4.r.9.2a	case_product_dosage__v, dose_form_termid__v	CM_DOSE_FORM_TERM_ID
Concomitant Medication	Dose Form Term ID Version	Text (50)	Usually not answered on an EDC form by site user Static value configuration is allowed	G.k.4.r.9.1	case_product_dosage__v, dose_form_termid_version__v	CM_DOSE_FORM_TERM_ID_VERSION
Concomitant Medication	Dose Form (Text)	Text (50)	Often used for derived fields on the EDC form, to then pass on other information about the dispense that doesn’t fit into other locations	G.k.4.r.9.2b	case_product_dosage__v, dose_form_text__v	CM_DOSE_FORM_TEXT
Concomitant Medication	Parent Route (Text)	Text (60)	Parent related dispense, e.g. parent-child/foetus reporting	G.k.4.r.11.1	case_product_dosage__v, parent_adminroute_text__v	CM_PARENT_ROUTE_TEXT
Concomitant Medication	Parent Route (Code)	Mapped Value	Parent related dispense, e.g. parent-child/foetus reporting The structured route value, e.g. 048 = oral__v	G.k.4.r.11.2b	case_product_dosage__v, parent_adminroute__v	CM_PARENT_ROUTE_CODE
Concomitant Medication	Parent Route Term ID	Text (50)	Parent related dispense, e.g. parent-child/foetus reporting	G.k.4.r.11.2b	case_product_dosage__v, parent_adminroute_termid__v	CM_PARENT_ROUTE_TERM_ID
Concomitant Medication	Parent Route Term ID Version	Text (50)	Parent related dispense, e.g. parent-child/foetus reporting Static value configuration is allowed	G.k.4.r.11.2a	case_product_dosage__v, parent_adminroute_termid_version__v	CM_PARENT_ROUTE_TERM_ID_VERSION

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 Configurations step for this safety data type:

1. Navigate to your Study in Studio > Form Configurations.

2. Navigate into the safety form configuration, then to the Item Configurations tab.

3. 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 (pictured below). 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.
   

4. 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.
5. Click Save (to remain on the page) or Save and Next (to advance to the next tab, Inclusion Criteria).

EDC Safety Data Type	EDC Field Label	Field Data Type	Notes	Relevant E2B (R3) Locations	Inbox Item / Case Object & Field	EDC Field Identifier
Medical History	Medical History Reported	Text (250)	Required mapping When the item configured at this location is setup for coding, the coding value will flow to safety A value in EDC Data Entry must be set for the form / item group to be eligible for transfer Once a non-empty value is set in data entry, the entry is then processed against the configured Inclusion Criteria	D.7.1.r.5 (term often reported from comments)	case_medical_history__v, name_reported__v	MH_REPORTED
Medical History	Medical History Reported (Coding LLT)	Text (8)	If coding is configured on Medical History Reported, it will be automatically set at this location	D.7.1.r.1a / D.7.1.r.1b	case_medical_history__v, name_meddra__v	MH_REPORTED_LLT
Medical History	Start Date	Date/Datetime	Partial dates are allowed	D.7.1.r.2	case_medical_history__v, startdate_idate__v	MH_START_DATE
Medical History	Continuing	Boolean	Partial dates are allowed	D.7.1.r.3	case_medical_history__v, continuing_value__v	MH_CONTINUING
Medical History	End Date	Date/Datetime	Partial dates are allowed	D.7.1.r.4	case_medical_history__v, enddate_idate__v	MH_END_DATE
Medical History	Comments	Text (2000)	For E2B style studies, this field is often used for the verbatim / reported text For the Safety-EDC Connection, the separate field exists for the reported text, in which case this field can be used for commentary purposes	D.7.1.r.5	case_medical_history__v, comments__v	MH_COMMENTS
Medical History	Family History	Boolean	Not a standard E2B field, but standard in the Safety-EDC Connection	D.7.1.r.6	case_medical_history__v, family_history__v	MH_FAMILY_HISTORY
Medical History	Illness at Vaccination	Boolean	Not a standard E2B field, but standard in the Safety-EDC Connection		case_medical_history__v, illness_at_vaccination__v	MH_ILLNESS_AT_VACCINATION

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 Configurations step for this safety data type:

1. Navigate to your Study in Studio > Form Configurations.

2. Navigate into the safety form configuration, then to the Item Configurations tab.

3. 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 (pictured below). 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.
   

4. 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.
5. Click Save (to remain on the page) or Save and Next (to advance to the next tab, Inclusion Criteria).

EDC Safety Data Type	EDC Field Label	Field Data Type	Notes	Relevant E2B (R3) Locations	Inbox Item / Case Object & Field	EDC Field Identifier
Drug History	Drug History Reported	Text (250)	Required mapping A value in EDC Data Entry must be set for the form / item group to be eligible for transfer Once a non-empty value is set in data entry, the entry is then processed against the configured Inclusion Criteria	D.8.r.1	case_drug_history__v, name_reported__v	DH_REPORTED
Drug History	Start Date	Date/Datetime	Partial dates are allowed	D.8.r.4	case_drug_history__v, startdate_idate__v	DH_START_DATE
Drug History	End Date	Date/Datetime	Partial dates are allowed	D.8.r.5	case_drug_history__v, enddate_idate__v	DH_END_DATE
Drug History	Age at Vaccination / Use	Numeric (3)	Not a standard E2B field, but standard in the Safety-EDC Connection		case_drug_history__v, age_at_vaccination_number__v	DH_AGE_AT_USE
Drug History	Age At Vaccination / Use Unit	Mapped Value	Not a standard E2B field, but standard in the Safety-EDC Connection Static value configuration is allowed		case_drug_history__v, age_at_vaccination_unit__v	DH_AGE_AT_USE_UNIT
Drug History	Product Type	Mapped Value	Not a standard E2B field, but standard in the Safety-EDC Connection		case_drug_history__v, product_type__v	DH_PRODUCT_TYPE
Drug History	Indication Reported	Text (250)	For indication, E2B studies this location is the coding only (no verbatim) For the Safety-EDC Connection, this is the verbatim, and the value is coded in Veeva Safety	D.8.r.6a, D.8.r.6b	case_drug_history__v, indication_reported__v	DH_INDICATION
Drug History	Reaction Reported	Text (250)	For indication, E2B studies this location is the coding only (no verbatim) For the Safety-EDC Connection, this is the verbatim, and the value is coded in Veeva Safety	D.8.r.7a, D.8.r.7b	case_drug_history__v, reaction_reported__v	DH_REACTION

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 Configurations step for this safety data type:

1. Navigate to your Study in Studio > Form Configurations.

2. Navigate into the safety form configuration, then to the Item Configurations tab.

3. 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 (pictured below). 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.
   

4. 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.
5. Click Save (to remain on the page) or Save and Next (to advance to the next tab, Inclusion Criteria).

EDC Safety Data Type	EDC Field Label	Field Data Type	Notes	Relevant E2B (R3) Locations	Inbox Item / Case Object & Field	EDC Field Identifier
Test Results	Test Date	Date/Datetime	Required mapping A value in EDC Data Entry must be set for the form / item group to be eligible for transfer Once a non-empty value is set in data entry, the entry is then processed against the configured Inclusion Criteria	F.r.1	case_test_result__v, date_idate__v	LAB_DATE
Test Results	Test Name	Text (250)	Required mapping A value in EDC Data Entry must be set for the form / item group to be eligible for transfer Once a non-empty value is set in data entry, the entry is then processed against the configured Inclusion Criteria If the item is setup for coding, coding will flow to the Test Name (Coding LLT) field automatically	F.r.2.1	case_test_result__v, name_reported__v	LAB_TEST_NAME
Test Results	Test Name (Coding LLT)	Text (8)	If coding is configured on Test Name, it will be automatically set at this location	F.r.2.2a, F.r.2.2b	case_test_result__v, name_meddra__v	LAB_TEST_NAME_MEDDRA
Test Results	Test Result (Numeric)	Numeric with Precision (14,3)	Numeric value only If the result and unit values cannot be separated, use Test Result (Text) instead	F.r.3.2	case_test_result__v, result_value__v	LAB_RESULT_NUMERIC
Test Results	Test Unit	Mapped Value	The paired unit with the numeric value in Test Result (Numeric) If the result and unit values cannot be separated, use Test Result (Text)	F.r.3.3	case_test_result__v, result_unit__v	LAB_RESULT_UNIT
Test Results	Test Result (Code)	Mapped Value	For test results that use Codelist type Item Definition	F.r.3.1	case_test_result__v, result_code__v	LAB_TEST_RESULT_CODE
Test Results	Test Result (Text)	Text (2000)	For test results that do not fit in the other result style field, use this field	F.r.3.4	case_test_result__v, restult_text__v	LAB_RESULT_TEXT
Test Results	Test Result (Qualifier)	Mapped Value	For Test Result (Numeric) accompanied by less than, greater than, etc., indicate that in this field	F.r.3.2	case_test_result__v, result_qualifier__v	LAB_RESULT_QUALIFIER
Test Results	Test Normal Low Value	Text (50)		F.r.4	case_test_result__v, normal_low_value__v	LAB_LOW_VALUE
Test Results	Test Normal High Value	Text (50)		F.r.5	case_test_result__v, normal_high_value__v	LAB_HIGH_VALUE
Test Results	Test Comments	Text (2000)	General comments on the test	F.r.6	case_test_result__v, comments__v	LAB_COMMENTS
Test Results	More Information Available	Boolean		F.r.7	case_test_result__v, more_information_available__v	LAB_MORE_INFO_AVAILABLE

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 Configurations step for this safety data type:

1. Navigate to your Study in Studio > Form Configurations.

2. Navigate into the safety form configuration, then to the Item Configurations tab.

3. 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 (pictured below). 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.
   

4. 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.
5. Click Save (to remain on the page) or Save and Next (to advance to the next tab, Inclusion Criteria).

EDC Safety Data Type	EDC Field Label	Field Data Type	Notes	Relevant E2B (R3) Locations	Inbox Item / Case Object & Field	EDC Field Identifier
Patient Characteristics	Gender	Mapped Value	Static value configuration is allowed	D.5	case_version__v, gender_value__v
Patient Characteristics	Date of Birth	Date / Numeric / Text	Partial dates are allowed Most clinical studies no longer allow full date of birth, instead just the year. An Item Definition for 4 digit year will comply with this safety field	D.2.1	case_version__v, dob_idate__v	PC_DOB
Patient Characteristics	Race	Mapped Value	Not a standard E2B field, but standard in the Safety-EDC Connection Multiple value location in Veeva Safety For ‘select all that apply’ form design, configure a row for each of the Item Definitions to the appropriate safety value		case_version__v, race__v	PC_RACE
Patient Characteristics	Ethnicity	Mapped Value	Not a standard E2B field, but standard in the Safety-EDC Connection		case_version__v, ethnicity__v	PC_ETHNICITY
Patient Characteristics	Age Group	Mapped Value	Static value configuration is allowed	D.2.3	case_version__v, age_group__v	PC_AGE_GROUP
Patient Characteristics	Age at SAE	Numeric (3)	If mapped, this age (and unit) will be used for ALL safety cases of a subject Consider instead using the same mapping on the Safety Case Initiation Event classified form. There, it would be the most accurate at the onset of the event.	D.2.2a	case_version__v, age_value__v	PC_AGE_VALUE
Patient Characteristics	Age at SAE Unit	Mapped Value	If mapped, this age (and unit) will be used for ALL safety cases of a subject Consider instead using the same mapping on the Safety Case Initiation Event classified form. There, it would be the most accurate at the onset of the event. Static value configuration is allowed	D.2.2b	case_version__v, age_unit__v	PC_AGE_UNIT
Patient Characteristics	Age at Vaccination	Numeric (3)	Not a standard E2B field, but standard in the Safety-EDC Connection		case_version__v, age_at_vaccination_number__v	PC_AGE_AT_VX
Patient Characteristics	Age Unit at Vaccination	Mapped Value	Not a standard E2B field, but standard in the Safety-EDC Connection Static value configuration is allowed		case_version__v, age_at_vaccination_unit__v	PC_AGE_AT_VX_UNIT
Patient Characteristics	Gestation Value	Numeric (3)		D.2.2.1a	case_version__v, gestation_value__v	PC_GESTATION
Patient Characteristics	Gestation Unit	Mapped Value	Static value configuration is allowed	D.2.2.1b	case_version__v, gestation_unit__v	PC_GESTATION_UNIT
Patient Characteristics	Weight (kg)	Numeric with Precision (4,4)	For numeric Item Definitions, ensure the user knows to enter in kg. Otherwise, use a unit definition field with a standard unit of kg. The Paired Date concept applies to this field. EDC will transfer ALL values, with a date to Safety. Safety will select the one closest to the case start for the case’s value. Other values will be available for review in Safety.	D.3	case_version__v, weight_normalized__kg__v	PC_WEIGHT_KG
Patient Characteristics	Height (cm)	Numeric with Precision (4,3)	For numeric Item Definitions, ensure the user knows to enter in cm. Otherwise, use a unit definition field with a standard unit of cm. The Paired Date concept applies to this field. EDC will transfer ALL values, with a date to Safety. Safety will select the one closest to the case start for the case’s value. Other values will be available for review in Safety.	D.4	case_version__v, height_normalized__cm__v	PC_HEIGHT_CM
Patient Characteristics	Patient Name or Initials	Text (60)	Usually not specifically mapped to an item in EDC Instead, the study setting for Subject ID Location is instead used to direct the EDC subject number to the appropriate / preferred location	D.1	case_version__v, patient_id_value__v	PC_NAME_OR_INITIALS
Patient Characteristics	GP Medical Record Number	Text (20)	Usually not specifically mapped to an item in EDC Instead, the study setting for Subject ID Location is instead used to direct the EDC subject number to the appropriate / preferred location	D.1.1.1	case_version__v, mrn_gp_value__v	PC_GPRN
Patient Characteristics	Hospital Record Number	Text (20)	Usually not specifically mapped to an item in EDC Instead, the study setting for Subject ID Location is instead used to direct the EDC subject number to the appropriate / preferred location	D.1.1.3	case_version__v, mrn_hospital_value__v	PC_HRN
Patient Characteristics	Investigational Record Number	Text (20)	Usually not specifically mapped to an item in EDC Instead, the study setting for Subject ID Location is instead used to direct the EDC subject number to the appropriate / preferred location	D.1.1.4	case_version__v, mrn_investigation_value__v	PC_IRN
Patient Characteristics	Specialist Record Number	Text (20)	Usually not specifically mapped to an item in EDC Instead, the study setting for Subject ID Location is instead used to direct the EDC subject number to the appropriate / preferred location	D.1.1.2	case_version__v, mrn_specialist__value	PC_SRN
Patient Characteristics	Randomization Number	Text (20)	Not a standard E2B field, but standard in the Safety-EDC Connection		case_version__v, patient_randomization_number__v	PC_RAND_NUM
Patient Characteristics	Last Menstrual Date	Date	The Paired Date concept applies to this field. EDC will transfer ALL values, with a date to Safety. Safety will select the one closest to the case start for the case’s value. Other values will be available for review in Safety. Partial dates are allowed	D.6	case_version__v, last_menstrual_date	PC_LAST_MENSTRUAL_DATE
Patient Characteristics	Pregnancy Occurrences	Numeric (2)	For unexpected pregnancy tracking (as a safety case) do not use this location. Instead the Safety Case Initiation Event mapping is used Values entered in EDC for this would flow to ALL cases of the subject		case_version__v, gravida_gravidity__v
Patient Characteristics	Number Given Birth	Numeric (2)	For unexpected pregnancy tracking (as a safety case) do not use this location. Instead the Safety Case Initiation Event mapping is used Values entered in EDC for this would flow to ALL cases of the subject		case_version__v, para_parity__v	AE_PREG_INFO_PARA
Patient Characteristics	Pregnant at SAE	Boolean	For unexpected pregnancy tracking (as a safety case) do not use this location. Instead the Safety Case Initiation Event mapping is used Values entered in EDC for this would flow to ALL cases of the subject		case_version__v, pregnancy_case__v	PC_PREG_CASE
Patient Characteristics	Pregnant at Vaccination	Boolean	For unexpected pregnancy tracking (as a safety case) do not use this location. Instead the Safety Case Initiation Event mapping is used Values entered in EDC for this would flow to ALL cases of the subject		case_version__v, pregnant_at_vaccination__v	PC_PREG_AT_VX
Patient Characteristics	Pregnancy Conception Date	Date	Repeating form / item group can be used for this, i.e. historical pregnancy information For unexpected pregnancy tracking (as a safety case) do not use this location. Instead the Safety Case Initiation Event mapping is used Values entered in EDC for this would flow to ALL cases of the subject Partial dates are supported		case_version__v, pregnancy_conception_date__v	AE_PREG_INFO_CON_DT
Patient Characteristics	Pregnancy Due Date	Date	Repeating form / item group can be used for this, i.e. historical pregnancy information For unexpected pregnancy tracking (as a safety case) do not use this location. Instead the Safety Case Initiation Event mapping is used Values entered in EDC for this would flow to ALL cases of the subject Partial dates are supported		case_version__v, pregnancy_due_date__v	AE_PREG_INFO_DUE_DT
Patient Characteristics	Pregnancy Outcome	Mapped Value	Repeating form / item group can be used for this, i.e. historical pregnancy information For unexpected pregnancy tracking (as a safety case) do not use this location. Instead the Safety Case Initiation Event mapping is used Values entered in EDC for this would flow to ALL cases of the subject		case_version__v, pregnancy_outcome__v	AE_PREG_INFO_OUTCOME
Patient Characteristics	Delivery Method	Mapped Value	Repeating form / item group can be used for this, i.e. historical pregnancy information For unexpected pregnancy tracking (as a safety case) do not use this location. Instead the Safety Case Initiation Event mapping is used Values entered in EDC for this would flow to ALL cases of the subject		case_version__v, delivery_method__v	AE_PREG_INFO_DELV_METH
Patient Characteristics	Date of Pregnancy Outcome	Date	Repeating form / item group can be used for this, i.e. historical pregnancy information For unexpected pregnancy tracking (as a safety case) do not use this location. Instead the Safety Case Initiation Event mapping is used Values entered in EDC for this would flow to ALL cases of the subject Partial dates are supported		case_version__v, date_of_pregnancy_outcome__v	AE_PREG_INFO_OUTCOME_DT
Patient Characteristics	Parent Subject Number	Text (128)	For EDC study design that has one subject refer to another (e.g. Mother / Infant), map this field to indicate the parent subject of the infant		case_version__v, parent_subject_number__v	PC_PARENT_SUBNUM
Patient Characteristics	General Medical History	Text (10000)	This location /value is only ONCE per safety case, i.e. a medical history narrative. For specific tracking of medical history entries, use the Medical History safety data type	D.7.2	case_version__v, medical_history_text__v	PC_MH_TEXT
Patient Characteristics	Subject had Concomitant Therapies	Boolean	Not a standard E2B field, but standard in the Safety-EDC Connection		,	PC_CON_THERAPY

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 Configurations step for this safety data type:

1. Navigate to your Study in Studio > Form Configurations.

2. Navigate into the safety form configuration, then to the Item Configurations tab.

3. 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 (pictured below). 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.

4. 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.
5. When finished, click Save or click Save and Next to proceed to the Inclusion Criteria step.

EDC Safety Data Type	EDC Field Label	Field Data Type	Notes	Relevant E2B (R3) Locations	Inbox Item / Case Object & Field	EDC Field Identifier
In Case of Death	Date of Death	Date	Partial dates are allowed Currently, when mapped, the value will flow to all safety cases of a subject once a value is entered in data entry. This includes safety cases where fatal is not indicated	D.9.1	case_version__v, dod_idate__v	ICD_DEATH_DT
In Case of Death	Autopsy Result Available	Boolean		D.9.3	case_version__v, autopsy_value__v	ICD_AUTOPSY_RES
In Case of Death	Reason Autopsy Result Omitted	Mapped Value	Static value configuration is allowed		case_version__v, autopsy_reason_omitted__v	ICD_AUTOPSY_REAS_OMIT
In Case of Death	Cause of Death - Type	Mapped Value	Static value configuration is allowed WARNING: For death causes to flow to safety, both a type and non-empty reported value must be mapped and provided	D.9.2.r, D.9.4.r	case_cause_of_death__v, type__v	ICD_CASE_TYPE
In Case of Death	Cause of Death - Reported	Text (250)	WARNING: For death causes to flow to safety, both a type and non-empty reported value must be mapped and provided	D.9.2.r, D.9.4.r	case_cause_of_death__v, name_reported__v	ICD_CAUSE_REPORTED
In Case of Death	Cause of Death - Reported (Coding LLT)	Text (8)	Should the Cause Of Death - Reported be setup for coding, the coding will flow to this location	D.9.2.r, D.9.4.r	case_cause_of_death__v, name_meddra__v	ICD_CAUSE_LLT

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

Option Summary by Data Type

Inclusion Criteria	Safety Data Types
	SCIE	Study Drug	Con Meds	Med Hist	Drug Hist	Test Res	Pat Chars	In Case of Death
All
Linked by site user
Start to end overlaps safety event start to end
Start to end overlaps X days before safety event start
Start to end overlaps X days after safety event start
Start to end overlaps X days before safety event end
Start to end overlaps X days after safety event end
First dispense
Closest on/before safety event start
Closest on/after safety event start
Closest on/before safety event (one only)
Drug dispense start before safety event start
Ended before safety event start
Always							*	*
Indicates that this inclusion criterion is available for the safety data type * Indicates that this inclusion criteria can't be modified for the safety data type

The table header abbreviates the safety data types:

• SCIE: Safety Case Initiation Event
• ConMeds: 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 safety data 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 safety data 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/before 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/after safety event start	*Applies only to the Study Drug safety form data type. The ‘restart’ dispense, i.e. if the subject restarts the study drug on/after the event start, it will be included. If date and time are involved in a comparison (both sides, SCIE and Study Drug), then the comparison for on/before will honor the full date/time. If one of the two is ‘date only’, then the comparison is done ‘Date vs. Date’.</td> <p markdown="span">If ‘Unknown Parts’ are allowed on either side, the comparison could be ‘year vs year’ (one side has an unknown month), or ‘month/year vs month/year’ (one side has an unknown day). 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 Closest On/Before 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.

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:
   • 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.
   • 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:
   • All: Include all current study drug dispenses into the case
   • 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.
   • Advanced date matching: Display and configure advanced selections in relation to the primary initiating event’s 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. To exclude study drug information from the Safety Case when the drug isn’t administered (the Drug Role is set to “Drug Not Administered”), leave this set to Yes for Exclude When Classified Not Administered. Otherwise, select No.
5. 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 Veeofen, taken once a day, but stops on March 3rd
• On March 3rd, the subject starts Natevba, taken once a day, and has no end date (still taking)
• On March 5th, the subject takes one dose of Deetoza (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 Natevba (ongoing) and March 5th Deetoza (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. The information will flow to the Drug History section of Veeva Safety.

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. The information will flow to the Test Results section of Veeva Safety.

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.

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.

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. Two additional tabs will be generated when you have configured for a safety integration: Safety Settings and Safety Form Configurations.

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.

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)