Configuring E2B Studies

The safety integration between Veeva EDC and any third party safety system is based on the exchange of E2B XMLs (R3 version) via an AS2 Gateway. 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
• Reporter / Sender Comments by System

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 E2B R3 elements. 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.

The system accepts acknowledgements from the safety system (“ACK File”) to confirm that data was received and parsed correctly. This return information confirms the case status, message status, and provides error details, if any.

Summary information is available in the Safety Cases (V4) and Safety Messages - E2B (V4) reports to confirm integration status and health. Safety integrations also support automated nullification transmission, 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. See nullifications.

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. For Safety Integrations Type, select E2B - External.

4. Click Save.

For more information on safety integrations using the Safety-EDC Connection, see Configuring Safety-EDC Connection 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

After setting the appropriate Safety Integration Type in the main study settings of Studio, the next step is to configure the safety case settings. These settings will affect all safety cases in the study, and can vary study by study.

1. Navigate to your Study in Studio > Safety Settings.
2. Click Edit.

3. Choose the appropriate values, or accept default values.

4. Click Save.

Note: The additional settings at the bottom of the Safety Settings page are not managed within Studio. They are shown for a reminder on deployed studies, i.e. when navigating Studio in a production or other downstream environment. These study operational settings are managed at Tools → Safety Integrations by safety administrators. See Safety Settings in Managing Safety Integrations for details.

Available Settings

Setting	Default Value	Description
Subject ID E2B Location (D.1.-)	Patient Name or Initials	Choose the E2B location in which the Veeva EDC Subject ID will be transferred for the current study: Patient Name or Initials, D.1 GP Medical Record Number, D.1.1.1 Specialist Record Number, D.1.1.2 Hospital Record Number, D.1.1.3 Investigational Number, D.1.1.4
Subject ID Format in E2B	Subject Only	Choose in which format to transfer the Veeva EDC Subject ID to the safety system. Subject Only Site-Subject (Site Number-Subject ID) Country ISO-Site-Subject (2-letter Country Code-Site Number - Subject ID)
Sender Type E2B Value (C.3.1)	Pharmaceutical Company	Choose which type of organization is sending the safety case from Veeva EDC to the safety system. This value is passed via C.3.1. You can choose from the following organization types: Pharmaceutical Company Health Professional Patient/Consumer Other Organization
Primary Source Qualification E2B Value (C.2.r.4)	Physician	C.2.r.4 yields the Classification of the person assessing the study drug or treatment, as it relates to each Event of a Safety Case. You can choose from the following classification types: Physician Pharmacist Other Health Professional Lawyer Consumer or Other Non Health Professional
Study Drug Classify when ConMed Suspect (G.k.1)	Always Suspect	The available choices: Always Suspect Always Interacting 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’ (E2B value of ‘2’). 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.
Study Name Value (C.5.2)		Optional: Set the value for Study Name in the E2B file. When left blank, the entry is omitted from the E2B content.
Sponsor Study Number Value (C.5.3)		Optional: Enter a Study Number to override the value in the E2B file. When left blank, the existing Study Label is used.
Study Type (C.5.4)	Clinical trials	Select the Study Type (C.5.4). Select from the following: Clinical trials Individual patient use Other studies
Name or Initials E2B NullFlavor (D.1)	NASK	Use this setting for a null flavor value at E2B location D.1 (Name or Initials), provided it isn’t the location selected for the study setting Subject E2B Location (D.1.*). Choices include: MSK (‘Masked’) ASKU (‘Asked but Unknown’’) NASK (‘Not Asked’) UNK (‘Unknown’)
Reporter	Full Site Information	Select from choices: Full Site Information Principal Investigator Only None The reporter locations in E2B will populate based on the information setup for the Site in Veeva EDC.
Null Flavor for Coding	None	Select how to handle missing values for coding, when there is no MedDRA coding value. This setting only applies to locations in your Veeva EDC Study design where you are configuring to do coding and have applied an E2B location for the safety transfers. Choose from these options: None 10067482 (Medical Coding LLT for “No term”) 99999999 (requires configuration on the receiving safety system). The locations of coding in E2B are: Safety Type E2B ID E2B Element Safety Case Initiation Event E.i.2.1b Reaction / Event (MedDRA code) Medical History D.7.1.r.1b Medical History (disease / surgical procedure / etc.) (MedDRA code) In Case of Death D.9.2.r.1b Reported Cause(s) of Death (MedDRA code) In Case of Death D.9.4.r.1b Autopsy-determined Cause(s) of Death (MedDRA code) Drug History D.8.r.6b Indication (MedDRA code) Drug History D.8.r.7b Reaction (MedDRA code) Test Results F.r.2.2b Test Name (MedDRA code)
Mute Coding Follow-ups	No	When set to Yes, this setting stops Veeva EDC 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 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.
Action Taken with Study Drug Behavior	Use Primary SAE Answer	This setting only applies if the study design allows for multiple events in one safety case. The transfer of additional events with the primary event, which initiated the safety case, can be configured using the respective inclusion rules (see Study Drug Inclusion Criteria). In those situations, the safety case would comprise multiple answers for the action taken with the study drug. As such, a method for which answer is used in the E2B transfer is required. Select from choices: Use Primary SAE Answer (Action Taken with the Study Drug from the primary safety case initiating event) Use Rollup Answer When using the rollup answer, all answers of the events included in the safety case will be taken into account. The most severe action taken will be transferred via G.k.8 to the safety system. The order of precedence is: Drug Withdrawn Dose Reduced Dose Increased Dose Not Changed Not Applicable Unknown For example, with two events, one answer of Dose Reduced, the other Dose Not Changed, the overall answer is Dose Reduced.
Auto Set Medically Confirmed (E.i.8)	No	This setting determines the inclusion of “Medical Confirmation by Healthcare Professionals” (E.i.8) in the safety case, and for every case Veeva EDC transmits. Select Yes to include. If you select No, E.i.8 will be omitted from the E2B XML The most common use for this is Yes, since the safety cases are originating from a clinical site / investigator.
Source of Study Drug Assessment (G.k.9.i.2.r.1)		Optional: For Source of Study Drug Assessment (G.k.9.i.2.r.1) and Method of Study Drug Assessment (G.k.9.i.2.r.2), enter a static value to apply to all cases. The Result (G.k.9.i.2.r.3) of assessment is a field answered by site user, configured on the Study Drug type. The most commonly used value for this setting is Healthcare Professional.
Method of Study Drug Assessment (G.k.9.i.2.r.2)		Optional: For Method of Study Drug Assessment (G.k.9.i.2.r.2), enter a static value to apply to all cases. The most commonly used value for this setting is Global Introspection.
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 the main Safety Settings (previous section), the next step is to configure which specific forms of the full study design will participate in the safety integration. These are setup at Studio > Form Configurations:

Note that the “New Form Configuration” button will only become active after the configuration of the Safety Settings.

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

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:

Type	E2B (R3) Location	Notes
Safety Case Initiation Event	E.*	Forms of this type will initiate a safety case transfer Cases will receive a nullification should a previously sent case no longer satisfy the criteria for that initial send A safety case can include data from the primary event only or several additional event forms, even non-serious events, depending on the configured inclusion criteria In a safety system/case, these are referred to as Events Note: In previous releases of Veeva EDC, this type was referred to as Serious Adverse Event
Study Drug	G.*	Each EDC form slated to track dispensing of the study drug/product in the Study would use this type In a safety system/case, these are referred to as Products, with one or more Dispenses/Dosages grouped within Depending on the configuration of the Study Drug Type inclusion rules, Veeva EDC will include the study drug dispenses in relation to the the Events of the case. Site linking to important study drug dispenses is not supported to allow a comprehensive transfer of relevant study drug dispense occurrences independent of site user action.
Concomitant Medications	G.*	These forms in Veeva EDC track other medications / products given to a Subject, not specifically part of the Study’s protocol In a safety system/case, these are also referred to as Products, and will have just one Dispense/Dosage transferred from Veeva EDC
Medical History	D.7.*	Historical conditions or procedures of a Subject, typically before entry into the Study In a safety system/case, these are referred to as Medical History
Drug History	D.8.*	Historical medication usages of a Subject, typically before entry into the Study In a safety system/case, these are referred to as Drug History
Test Results	F.*	Specific lab results, diagnostic results about the Subject, deemed relevant to the event(s) they are experiencing In a safety system/case, these are referred to as Test Results Note: In previous releases of Veeva EDC, this type was referred to as the External Labs
Patient Characteristics	D.1 thru D.6	General characteristics of the Subject Examples: Date of Birth (D.2) Sex (D.5)
In Case of Death	D.9.*	In the event of death of the Subject, the tracking of that information Examples: Date of Death (D.9.1) Reported Causes of Death (D.9.2.r.*)
Reporter / Sender Comments by System	H.2 or H.4	Special type to allow standardized data transfer to the safety system of information that is collected in EDC, but has no location in E2B format The system will gather these values and show as system generated bullet list in the Reporter Comments (H.2) or Sender Comments (H.4) location of the transferred XML Examples: Toxicity Grade, Severity on the AE form Cohort or other general patient characteristics Answers to key study questions, where the site user links to a form that is relevant, from the event form that begins the case

How to Create a Form Configuration

To create a new safety form configuration:

1. Navigate to Studio > Form Configurations.

2. Click + New Form Configuration.

3. Proceed with the three steps (tabs) of configuration.

The options 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 of safety form configuration is the Form Properties. After selecting the Safety Type from the dropdown, general properties about the configuration are applied, with available properties differing by Safety Type:

Safety Data Type	Properties
	Form	Safety Key Item	Each Entry In	Product Info	System Comment Destination	Description
Safety Case Initiation Event	*	*	*
Study Drug	*	*	*	*
Concomitant Medications	*		*
Medical History	*		*
Drug History	*		*
Test Results	*		*
Patient Characteristics	*
In Case of Death	*
Reporter / Sender Comments by System	*				*
* Indicates that this property is present required for the Safety Data Type. Indicates that this property is present 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.
• System Comment Destination only applies to the transfer of EDC data via Reporter / Sender Comments by the system in a standardized way.
• Description is optional helpful text for the study designer.

Each Entry In - Design Considerations

Definition

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.

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 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: Related Safety Data Embedded in the Event form

For studies that have event related safety data embedded in the Safety Case Initiation Event form, the approach looks like this:

Item groups embedded in the Event form can cover, as repeating item groups, study drug dispenses, drug history, medical history or test results, and as non-repeating item groups, in case of death. In this case, no standalone form is set up in the study design for this embedded data.

To transfer safety related data for such study design where relevant information can be entered by a site user when an event will initiate a safety case, the EDC form already mapped to the Safety Case Initiation Event data type can be mapped to other safety data types, including Concomitant Medications, Medical History, Drug History, Study Drug, Test Results, or In Case of Death.

• Note that no embedded data can be configured for the Safety Case Initiation Event or Patient Characteristics safety data type. The Reporter / Sender Comments by System data type already support dual usage on the Safety Case Initiation Event data type.
• If an EDC form already mapped to the Safety Case Initiation Event data type is being mapped to another safety data type, the Each Entry In field automatically selects Repeating item group in form.
• Note that the Each Entry In field for the In Case of Death, Patient Characteristics, and Reporter / Sender Comments by System safety data types only allow the Form option for this field.

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 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 in the operations study settings - more information here.
  • Additionally, for the transfer to proceed, the E2B field E.i.1.1a (Reaction / Event as Reported by the Primary Source in Native Language) 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 E2B location E.i.3.1 (Term Highlighted by the Reporter)

Example 2:

• The first example used an E2B location (E.i.3.1) as the Safety Key Item. However, any field can be used for the purpose, even one not used to map to E2B fields.
• 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 choices of this codelist:

  • “New Safety Case” (its codelist code) is used for the Safety Key Item Value. 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 Studio rules would be used to ensure the site user links the current form to another event that initiated a safety case.
  • “No Longer..” - 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 E.i.1.1a becomes empty
• It will be noted as a nullification type E2B message
• 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.
• E2B 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

Safety Case Initiation Event

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

To create a new safety form configuration for this type:

1. Navigate to your Study in Studio > Form Configurations.
2. Click the New Form Configuration button.
3. Select Safety Case Initiation Event for Safety Data Type.
4. Select the Form to apply to this configuration type.
5. Choose an appropriate selection for Each Entry In. This selection depends on the design of your form. See Each Entry In Design Considerations for more information and examples.
6. Optionally indicate a Description.
7. Indicate the appropriate Safety Key Item / Safety Key Item Value. Note: For codelist item definitions, the codelist code must be specified.
8. Click Save or Save and Next.

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 / drugs section of a safety case. (G.* section of E2B). Multiple forms can be used with the type.

To create a new safety form configuration for this type:

1. Navigate to your Study in Studio > Form Configurations.
2. Click the New Form Configuration button.
3. Choose Study Drug for Safety Data Type.
4. Select the Form to apply this configuration type.
5. Choose an appropriate selection for Each Entry In. This selection depends on the design of your form. See Each Entry In Design Considerations for more information and examples.
   • Note: If the EDC form already mapped to the Safety Case Initiation Event has been selected, Each Entry In defaults to Repeating item group in form.
6. Indicate a Study Drug Name. IMPORTANT: This value should typically be a direct match to how the drug is named in the target safety system. Consult documentation of the target safety system for how it handles the transfer of a study drug for G.* locations in E2B.

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

8. Optionally choose a Subject Group in the study design that this study drug only applies to. With this set, any subject not in the group will have the study drug omitted from the safety transfer.

9. Optionally indicate Study Drug Indication to apply to all cases of a subject. There are two options:

   • Specify Value: This is a static value that will apply to all subjects / all cases

   • From an item value: This is a specific Item from the casebook, i.e. the indication can differ by subject. IMPORTANT: This value should be from a value recorded once across the casebook design, not the study drug form itself, e.g. a reason for enrollment and being on that study drug. Examples of the usage of each.

10. Optionally indicate a Description.
11. Indicate the appropriate Safety Key Item / Safety Key Item Value. For the study drug type, the evaluation is used to consider a form/dispense eligible for inclusion to the transfer. Additional inclusion criteria (see Study Drug Inclusion Criteria) are also evaluated to bring in the appropriate dispenses of the study drug to the safety case.
12. Click Save or Save and Next.

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. (G.* section of E2B) Multiple forms can be used with the type.

To create a new safety form configuration for this type:

1. Navigate to your Study in Studio > Form Configurations.
2. Click the New Form Configuration button.
3. Choose Concomitant Medications for Safety Data Type.
4. Select the Form to apply this configuration type.
5. Choose an appropriate selection for Each Entry In. This selection depends on the design of your form. See Each Entry In Design Considerations for more information and examples.
   • Note: If the EDC form already mapped to the Safety Case Initiation Event has been selected, Each Entry In defaults to Repeating item group in form.
6. Optionally indicate a Description.
7. Click Save or Save and Next.

Medical History

This type of safety configuration is applied to medical history forms of the study. The information will flow to the E2B D.7 section of a safety case. Multiple forms can be used with the type.

To create a new safety form configuration for this type:

1. Navigate to your Study in Studio > Form Configurations.
2. Click the New Form Configuration button.
3. Choose Medical History for Safety Data Type.
4. Select the Form to apply this configuration type.
5. Choose an appropriate selection for Each Entry In. This selection depends on the design of your form. See Each Entry In Design Considerations for more information and examples.
   • Note: If the EDC form already mapped to the Safety Case Initiation Event has been selected, Each Entry In defaults to Repeating item group in form.
6. Optionally indicate a Description.
7. Click Save or Save and Next.

Drug History

This type of safety configuration is applied to drug history forms of the study. The information will flow to the E2B D.8 section of a safety case.

To create a new safety form configuration for this type:

1. Navigate to your Study in Studio > Form Configurations.
2. Click the New Form Configuration button.
3. Choose Drug History for Safety Data Type.
4. Select the Form to apply this configuration type.
5. Choose an appropriate selection for Each Entry In. This selection depends on the design of your form. See Each Entry In Design Considerations for more information and examples.
   • Note: If the EDC form already mapped to the Safety Case Initiating Event has been selected, Each Entry In defaults to Repeating item group in form.
6. Optionally indicate a Description.
7. Click Save or Save and Next.

Test Results

This type of safety configuration is applied to lab / test result forms of the study. The information will flow to the E2B F.* section of a safety case. Multiple forms can be used with the type.

To create a new safety form configuration for this type:

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

1. Click the New Form Configuration button.
2. Choose Test Results for Safety Data Type.
3. Select the Form to apply this configuration type.
4. Choose an appropriate selection for Each Entry In. This selection depends on the design of your form. See Each Entry In Design Considerations for more information and examples.
   • Note: If the EDC form already mapped to the Safety Case Initiation Event has been selected, Each Entry In defaults to Repeating item group in form.
5. Optionally indicate a Description.
6. Click Save or Save and Next.

Patient Characteristics

This type of safety configuration is applied to general information about the subject. Only items from non repeating item groups can be mapped for this type. Further, these values are once per safety case, so should never occur more than once across the subject’s casebook. Multiple forms can be used with the type, e.g. Sex on one form, Date of Birth on another.

To create a new safety form configuration for this type:

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

1. Click the New Form Configuration button.
2. Choose Patient Characteristics for Safety Data Type.
3. Select the Form to apply this configuration type.
4. Optionally indicate a Description.
5. Click Save or Save and Next.

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). Multiple forms can be used with the type, e.g. Date of Death on one form, causes of death on another.

To create a new safety form configuration for this type:

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

1. Click the New Form Configuration button.
2. Choose In Case of Death for Safety Data Type.
3. Select the Form to apply this configuration type.
   • Note: If the EDC form already mapped to the Safety Case Initiation Event has been selected, Each Entry In defaults to Form.
4. Optionally indicate a Description.
5. Click Save or Save and Next.

Reporter / Sender Comments by System

This type of safety configuration can be applied to any form in the casebook. The Reporter / Sender Comments by System functionality is specifically designed for transfer of data that doesn’t fit anywhere in the E2B format.

To create a new safety form configuration for this type:

1. Navigate to your Study in Studio > Form Configurations.
2. Click the New Form Configuration button.
3. Choose Reporter / Sender Comments by System for Safety Data Type.
4. Select the Form to apply this configuration type.
5. Optionally indicate a Description.
6. Choose a Destination for Comments. The choice Reporter Comments will transmit the information to the E2B H.2 location. Sender Comments will transmit the information to the E2B H.4 location. H.2 and H.4 can also be configured to an item on the Safety Case Initiation Event form, in which case the site entered information will precede the system generated information, and can be clearly distinguished .
7. Click Save or Save and Next.

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 the Safety Case Initiation Event type:

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

Summary of the columns in the grid:

Column	Notes
E2B ID	Location in the E2B(R3) format
E2B Element	The E2B location label
E2B Item Type	The data type at that E2B location. The E2B Item Type is crucial information. The Item Definition data type chosen for that row / E2B location must conform to the destination in E2B. As one example, a date / datetime location in E2B cannot be mapped by an EDC field that is not also date or datetime. Non-conformant data to the E2B type will not be acted on by Veeva EDC, i.e. omitted from a transfer. The safety system’s ability to accept (with warnings / alerts) will be crucial in such situations. As another example: Suppose a lab EDC form records ‘Test Result’ using free text, but is mapped in E2B to the ‘Test Result (numeric)’ location. This is risky since technically the end user can enter numeric values which will flow to safety without issue. But, the ability to enter non-numeric, e.g. ‘less than 0.1’ as a result will likely be problematic. Be sure to end to end test your study design to the destination system with all mapped fields having values, and in many combinations.
Value Required for First Send	Indicate when a configured Item must have a value on the data entry form to start the initial transfer of a safety case The setting only applies to the the Safety Case Initiation Event type For E.i.1.1a (Event Term), the setting is checked and not configurable. A safety case cannot begin transfer / tracking without this verbatim field having a non-empty value.
Configured Item	Choose the Item Definition from the form design in this cell Choices for selection will generally depend on the Each Entry In setting saved on the Form Properties (previous step). Using Each Entry In = Form, choices reside in non repeating item groups. On the other hand, using Each Entry In = Repeating item group on form, choices are from repeating item groups. Some E2B IDs do allow for locations in either repeating or non repeating item groups, no matter the saved Each Entry In value. Those E2B locations are called out within the detail sections by type. When using the Repeating item group on form, ensure all item definitions that comprise an entry (e.g. Medical History, Lab, etc.) are in the same repeating item group. Some E2B locations can be outside that same repeating item group, but it is the rare exception. See the type by type details after this section for those outliers.
Value Translations	When the Item Definition is a codelist or check box type, configuration of the EDC answer to the proper E2B value is necessary. The Studio Validations job will indicate an error (preventing deployments) if any of these are missing or not valid for the target E2B locations. This is true where strict E2B values are known/required, with one exception - medication or test result units. These require special configuration/profiles in the destination safety system, even when industry standard units. The Studio Validation job will only report a warning as reminder of this risk.

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. Specify the Item Definition in the Configured Item column

2. Next to the Configured Item column click in the cell of the Value Translations column. If a value translation can be configured the cell will appear orange on hover over.

3. This opens the Translate Values for E2B XML dialog.

4. For each codelist or boolean type Item, enter a valid E2B XML Value in the free text field.
   • If the Codelist Code is already valid for the E2B location, there is no need to enter an E2B XML Value.
   • If more Codelist entries are in the study design than available E2B options, several Codelist entries can be mapped to the same E2B XML Value.
   • If an invalid Codelist Code is not translated to an E2B XML Value, the studio validation will show an error.
5. When finished, click Save.
6. Once value translations have been specified, the number of configured translations will be indicated in the cell.

By Safety Data Type

Safety Case Initiation Event

To save item configurations for this safety 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 where a mapping is intended, use the cell in the Configured Item column to select the appropriate Item Definition of the Form Definition. For example, choosing the AETERM item from the form for the E2B location E.i.1.1a.

4. For each item configured, indicate if Value Required for First Send. The E.i.1.1a is not editable (checked), as all safety systems require at least one event with a non-empty term/value. Other rows / E2B locations are not typically set with this property, their default is unchecked.

5. Depending on the Item Definition type for the selected item and the E2B ID of the row, Value Translations could be needed. Refer to the general overview for setting up value translations here.
6. Click Save (to remain on the page) or Save and Next (to advance to the next tab, Inclusion Criteria)

E2B ID	E2B Label	E2B Type	Notes
E.i.1.1a	Reaction / Event as Reported by the Primary Source in Native Language (Verbatim)	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.2.1a)	MedDRA Version for Reaction / Event		NOT mappable, instead tied to E.i.1.1a The MedDRA version will be transferred without explicit mapping if the Event verbatim is configured for coding by Veeva Coder and a code has been assigned
(E.i.2.1b)	Reaction / Event (MedDRA code)		NOT mappable, instead tied to E.i.1.1a The MedDRA code will be transferred without explicit mapping if the Event verbatim is configured for coding by Veeva Coder and a code has been assigned
E.i.1.2	Reaction / Event as Reported by the Primary Source for Translation	Text (250)	Some safety systems are configured to use this field in E2B as well as E.i.1.1a, the field for verbatim. The common use of this field is to map the same Item Definition as that which is mapped for E.i.1.1a.
E.i.4	Date of Start of Reaction/Event (value)	Datetime	This value will be key in any date based inclusion criteria E2B will allow for unknown parts (day / month / time) if the study is configured for such
E.i.5	Date of End of Reaction/Event (value)	Datetime	This value will also be key in any date based inclusion criteria E2B will allow for unknown parts (day / month / time) if the study is configured for such
E.i.3.1	Term Highlighted by the Reporter (Serious or Non Serious)	Number(1)	The E2B location for ‘Is the event serious?’ 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 above (Safety Key Item Value). E2B allowed values are listed below. Since it is a clinical study and the reporter is the site / principal investigator, use 3 (serious) and 1 (not serious) are the most appropriate values. Value Meaning 1 Yes, highlighted by the reporter, NOT serious 2 No, not highlighted by the reporter, NOT serious 3 Yes, highlighted by the reporter, SERIOUS 4 No, not highlighted by the reporter, SERIOUS
E.i.7	Outcome of Reaction/Event at the Time of Last Observation	Number (1)	Outcome of the event E2B allowed values are listed below: Value Meaning 1 Recovered / Resolved 2 Recovering / Resolving 3 Not Recovered / Not Resolved / Ongoing 4 Recovered / Resolved with Sequelae 5 Fatal 0 Unknown
E.i.9	Identification of the Country Where the 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 E2B 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.
D.2.2a	Age at time of onset of reaction/event (number)	Number (5)	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 E2B 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.2b	Age at time of onset of reaction/event (unit)	Text (50)	Only items from non-repeating item groups are choices for this location, since it is a single value for a safety case. When not mapped, Years (a) is assumed and used in the transfer E2B allowed values are listed below. Value Meaning a Years mo Months wk Weeks d Days h Hours {Decade} Decades
D.3	Body Weight (kg)	Number (6)	Only items from non-repeating item groups are choices for this location, since it is a single value for a safety case. For numeric Item Definitions, ensure the user knows to enter in kg. Otherwise, use a unit codelist field with a standard unit of kg. For multiple events in a safety case, the answer from the primary event is used.
D.4	Height (cm)	Number (3)	Only items from non-repeating item groups are choices for this location, since it is a single value for a safety case. When mapped to a numeric Item Definition, ensure the user knows to enter in cm. Otherwise, use a unit codelist field with a standard unit of cm. Any fractional portion is rounded, as this E2B location only allows whole numbers. For multiple events in a safety case, the answer from the primary event is used.
D.6	Last Menstrual Period Date	Datetime	Partial dates are allowed. Only items from non-repeating item groups are choices for this location, since it is a single value for a safety case. For multiple events in a safety case, the answer from the primary event is used.
E.i.3.2a	Results in Death (Seriousness Criteria)	Boolean	This is one of the six key seriousness criteria of E2B format. 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 true, and any other value to the Codelist set without a value translation. E2B does not accept false for this location.
E.i.3.2b	Life Threatening (Seriousness Criteria)	Boolean	This is one of the six key seriousness criteria of E2B format. 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 true, and any other value to the Codelist set without a value translation. E2B does not accept false for this location.
E.i.3.2c	Caused / Prolonged Hospitalisation (Seriousness Criteria)	Boolean	This is one of the six key seriousness criteria of E2B format. 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 true, and any other value to the Codelist set without a value translation. E2B does not accept false for this location.
E.i.3.2d	Disabling / Incapacitating (Seriousness Criteria)	Boolean	This is one of the six key seriousness criteria of E2B format. 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 true, and any other value to the Codelist set without a value translation. E2B does not accept false for this location.
E.i.3.2e	Congenital Anomaly / Birth Defect (Seriousness Criteria)	Boolean	This is one of the six key seriousness criteria of E2B format. 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 true, and any other value to the Codelist set without a value translation. E2B does not accept false for this location.
E.i.3.2f	Other Medically Important Condition (Seriousness Criteria)	Boolean	This is one of the six key seriousness criteria of E2B format. 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 true, and any other value to the Codelist set without a value translation. E2B does not accept false for this location.
H.1	Case Narrative Including Clinical Course, Therapeutic Measures, Outcome and Additional Relevant Information	Text (100000)	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	Reporter's 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. The field can be mapped for data entry and also contain system generated information using the Reporter / Sender Comments by System safety data type.
H.4	Sender's 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. The field can be mapped for data entry and also contain system generated information using the Reporter / Sender Comments by System safety data type.
C.1.11.2	Reason for Nullification / Amendment	Text (2000)	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.
E.i.6a	Duration of reaction/event (value)	Number (5)	This value is usually auto calculated and set in the target safety system
E.i.6b	Duration of reaction/event (unit)	Text (50)	This value is usually auto calculated and set in the target safety system WARNING: Units in EDC will need to be mapped to the safety system’s allowed unit values. This is generally those of the Unified Code of Measures, but even valid units can be rejected by a safety system without proper configuration there (allowing the unit in). The Studio Validations job will further warn about this, each run.

Study Drug

To save item configurations for this safety 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 where a mapping is intended, use the cell in the Configured Item column to select the appropriate Item Definition of the Form Definition. For example, choosing the DRG_STDT item from the form for the E2B location G.k.4.r.4.

4. Depending on the Item Definition type for the selected item and the E2B ID of the row, Value Translations might be needed. Refer to the general overview for setting up value translations here.
5. Click Save (to remain on the page) or Save and Next (to advance to the next tab, Inclusion Criteria)

E2B ID	E2B Label	E2B Type	Notes
G.k.4.r.4	Date and Time of Start of Drug	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 G.k.4.r.5 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.5	Date and Time of Last Administration	Datetime	If no item is mapped to this E2B 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.1a	Dose (number)	Number (8)	Avoid non-numeric Item Definition here, as the system will not point those out in Studio Validations job
G.k.4.r.1b	Dose (unit)	Text (50)	WARNING: Units in EDC will need to be mapped to the safety system’s allowed unit values, which are generally the Unified Code of Measures. However, valid units can be rejected by a safety system without proper configuration there, and lead to a rejection of the safety case E2B XML. For awareness and review, the Studio Validations job will always warn about any mapped units. The E2B identifier for ‘unknown unit’ {DF} (with the brackets) can be used as a last resort where the EDC answer will never fit the configured / standard units in safety
G.k.4.r.8	Dosage Text	Text (2000)	Often used for derived fields on the EDC form, to then pass on other information about the dispense that doesn’t fit into other E2B locations
G.k.4.r.2	Number of Units in the Interval (Frequency)	Number (4)	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 E2B locations (value and unit), likely via a derived rule on the form, below the site’s answer
G.k.4.r.3	Definition of the Time Interval Unit (Frequency Unit)	Text (50)	Refer to the comments on the previous line, this E2B location pairs with the value
G.k.2.4	Identification of the Country Where the Drug Was Obtained	Text (2)	The value here must be a valid 2 character ISO code for a country, e.g. US, UK, BE, etc. If this E2B location is not mapped, the country code of the site is used instead.
G.k.4.r.10.1	Route of Administration (free text)	Text (60)	If G.k.4.r.10.2b cannot be used for the form design, use this location instead
G.k.4.r.10.2a	Route of Administration TermID Version Date / Number	As per ISO IDMP
G.k.4.r.10.2b	Route of Administration TermID	Number (3)	Allowed values are from standard Routes of Administration (those codes) Examples: ‘048’ = Oral If value translations are used against an EDC codelist, also ensure the E2B value is a full THREE characters, i.e. padded zeros included.
G.k.8	Action(s) Taken with Drug	Number (1)	This is a special question related to the event of the case. The choices for mapping this answer are those from the Safety Case Initiation Form itself, not on any specific dispense form of the drug E2B allowed values are listed below. For safety cases with multiple events, there might be multiple answers to this question on those event forms. For behavior on which answer is used in the transfer, refer to the study safety setting Action Taken with Study Drug Behavior here. Value Meaning 1 Drug withdrawn 2 Dose reduced 3 Dose increased 4 Dose not changed 0 Unknown 9 Not applicable WARNING: Studio validation job will catch any missing or invalid mapping at this E2B location, and block deployments to other vaults. If your safety setting is specially set up to allow for an additional value at this location (e.g. ‘7’ = ‘Dose Interrupted’), contact Veeva to have the studio validation error relaxed to a warning on your Vaults.
G.k.9.i.2.r.3	Result of Assessment	Text (60)	This is a special question related to the event of the case. The choices for mapping this answer are those from the Safety Case Initiation Event form itself, not on any specific dispense form of the drug Refer to documentation in your safety system on this location. Free text is the data type for E2B, but often a safety system classifies this location as a structured codelist The E2B Method and Source of the assessment can be set at the safety settings.
G.k.9.i.4	Did Reaction Recur on Re-administration?	Number (1)	This is a special question related to the event of the case. The choices for mapping this answer are those from the Safety Case Initiation Event form itself, not on any specific dispense form of the drug E2B allowed values are listed below. Value Meaning 1 Yes, rechallenge done, event recurred 2 Yes, rechallenge done, event did not recur 3 Yes, rechallenge done, outcome unknown 4 No, not applicable
G.k.10.r	Additional Information on Drug (coded) (repeat as necessary)	Number (2)	This location can be mapped to an Item Definition in a non repeating or (more typically) repeating item group. Since there is often more than one answer, a repeating item group location (usually standalone) would be more preferred. E2B allowed values are listed below. Value Meaning 1 Counterfeit 2 Overdose 3 Drug taken by the father 4 Drug taken beyond expiry date 5 Batch and lot tested and found within specifications 6 Batch and lot tested and found not within specifications 7 Medication error 8 Misuse 9 Abuse 10 Occupational exposure 11 Off label use
G.k.11	Additional Information on Drug (free text)	Text (2000)	This E2B location allows for text longer than an item definition can support in Veeva EDC (1500). This location cannot be use a repeating item group to enter / derive more than 1500 characters (as H.1 / H.2 / H.4 locations allow)
G.k.7.r.1	Indication as Reported by the Primary Source	Text (250)	Configured if the indication can vary from dispense to dispense If multiple values are used across the subject casebook, all will be included in the E2B XML
G.k.2.3.r.3a	Strength (number)	Number (10)	Rarely mapped in EDC for site to answer Usually configuration in the safety system itself
G.k.2.3.r.3b	Strength (unit)	Text (50)	Rarely mapped in EDC for site to answer Usually configuration in the safety system itself
G.k.4.r.6a	Duration of Drug Administration (number)	Number (5)	Often not mapped on the EDC form, instead calculated in the safety system
G.k.4.r.6b	Duration of Drug Administration (unit)	Text (50)	Often not mapped on the EDC form, instead calculated in the safety system WARNING: Units in EDC will need to be mapped to the safety system’s allowed unit values, which are generally the Unified Code of Measures. However, valid units can be rejected by a safety system without proper configuration there, and lead to a rejection of the safety case E2B XML. For awareness and review, the Studio Validations job will always warnabout any mapped units. The E2B for ‘unknown unit’ {DF} (with the brackets) can be used as a last resort where the EDC answer will never fit the configured units in safety
G.k.4.r.7	Batch / Lot Number	Text (35)
G.k.4.r.9.2a	Pharmaceutical Dose Form TermID Version Date / Number	As per ISO IDMP
G.k.4.r.9.2b	Pharmaceutical Dose Form TermID	As per ISO IDMP
G.k.5a	Cumulative Dose to First Reaction (number)	Number (10)	Often not mapped on the EDC form, instead calculated in the safety system
G.k.5b	Cumulative Dose to First Reaction (unit)	Text (50)	Often not mapped on the EDC form, instead calculated in the safety system WARNING: Units in EDC will need to be mapped to the safety system’s allowed unit values, which are generally the Unified Code of Measures. However, valid units can be rejected by a safety system without proper configuration there, and lead to a rejection of the safety case E2B XML. For awareness and review, the Studio Validations job will always warn about any mapped units. The E2B for ‘unknown unit’ {DF} (with the brackets) can be used as a last resort where the EDC answer will never fit the configured units in safety
G.k.6a	Gestation Period at Time of Exposure (number)	Number (3)
G.k.6b	Gestation Period at Time of Exposure (unit)	Text (50)	E2B allowed values are listed below. Value Meaning mo Months wk Weeks d Days {Trimester} Trimester

Concomitant Medications

To save item configurations for this safety 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 where a mapping is intended, use the cell in the Configured Item column to select the appropriate Item Definition of the Form Definition. For example, choosing the CMTRT item from the form for the E2B location G.k.2.2.

4. Depending on the Item Definition type for the selected item and the E2B ID of the row, Value Translations might be needed. Refer to the general overview for setting up value translations here.
5. Click Save (to remain on the page) or Save and Next (to advance to the next tab, Inclusion Criteria)

E2B ID	E2B Label	E2B Type	Notes
G.k.2.2	Medicinal Product Name as Reported by the Primary Source	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
G.k.4.r.4	Date and Time of Start of Drug	Datetime	If G.k.4.r.5 is not mapped on the EDC form, the value for start date is used when processing Inclusion Criteria
G.k.4.r.5	Date and Time of Last Administration	Datetime	If no item is mapped to this E2B 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.1	Characterization of Drug Role	Number (1)	This is a special question related to the event of the case. It allows for site opinion on a concomitant medication, that it might be involved in the event(s) of the case When not mapped, or mapped but unanswered by the site, the system will use value of 2 ( ‘Concomitant’) for the drug role The choices for mapping this answer are those from an item definition on the Safety Case Initiation Event form itself, not the concomitant medication form Further, the items that can map only reside in repeating item groups back on the event form, and where an ‘Item to Form Link’ Item Definition also exists The resulting behavior is then an answer ‘as you link’ to the specific medication, E2B allowed values are listed below. Value Meaning 1 Suspect 2 Concomitant 3 Interacting
G.k.8	Action(s) Taken with Drug	Number (1)	This is a special question related to the event of the case. The choices for mapping this answer are those from an item definition on the Safety Case Initiation Event form itself, not the concomitant medication form Further, the items that can map only reside in repeating item groups back on the event form, and where an ‘Item to Form Link’ Item Definition also exists The resulting behavior is then an answer ‘as you link’ to the specific medication E2B allowed values are listed below. Value Meaning 1 Drug withdrawn 2 Dose reduced 3 Dose increased 4 Dose not changed 0 Unknown 9 Not applicable WARNING: Studio validation job will catch any missing or invalid mapping at this E2B location, and block deployments to other vaults. If your safety setting is specially set up to allow for an additional value at this location (e.g. ‘7’ = ‘Dose Interrupted’), contact Veeva to have the studio validation error relaxed to a warning on your Vaults.
G.k.9.i.2.r.3	Result of Assessment	Text (60)	This is a special question related to the event of the case. The choices for mapping this answer are those from an item definition on the Safety Case Initiation Event form itself, not the concomitant medication form Further, the items that can map only reside in repeating item groups back on the event form, and where an ‘Item to Form Link’ Item Definition also exists. The resulting behavior is then an answer ‘as you link’ to the specific medication. Refer to documentation in your safety system on this location. Free text is the data type for E2B, but often a safety system classifies this location as a structured codelist. The E2B Method and Source of the assessment can be set at the safety settings.
G.k.9.i.4	Did Reaction Recur on Re-administration?	Number (1)	This is a special question related to the event of the case. The choices for mapping this answer are those from an item definition on the Safety Case Initiation Event form itself, not the concomitant medication form Further, the items that can map only reside in repeating item groups back on the event form, and where an ‘Item to Form Link’ Item Definition also exists The resulting behavior is then an answer ‘as you link’ to the specific medication E2B allowed values are listed below. Value Meaning 1 Yes, rechallenge done, event recurred 2 Yes, rechallenge done, event did not recur 3 Yes, rechallenge done, outcome unknown 4 No, not applicable
G.k.4.r.1a	Dose (number)	Number (8)	Avoid non-numeric Item Definition here, as the system will not point those out in Studio Validations job
G.k.4.r.1b	Dose (unit)	Text (50)	WARNING: Units in EDC will need to be mapped to the safety system’s allowed unit values, which are generally the Unified Code of Measures. However, valid units can be rejected by a safety system without proper configuration there, and lead to a rejection of the safety case E2B XML. For awareness and review, the Studio Validations job will always warn about any mapped units. The E2B for ‘unknown unit’ {DF} (with the brackets) can be used as a last resort where the EDC answer will never fit the configured / standard units in safety
G.k.4.r.8	Dosage Text	Text (2000)	Often used for derived fields on the EDC form, to then pass on other information about the dispense that doesn’t fit into other E2B locations
G.k.4.r.2	Number of Units in the Interval (Frequency)	Number (4)	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 E2B locations (value and unit), likely via a derived rule on the form, below the site’s answer
G.k.4.r.3	Definition of the Time Interval Unit (Frequency Unit)	Text (50)	Refer to the comments on the previous line, this E2B location pairs with the value
G.k.2.4	Identification of the Country Where the Drug Was Obtained	Text (2)	The value here must be a valid 2 character ISO code for a country, e.g. US, UK, BE, etc. If this E2B location is not mapped, the country code of the site is used instead.
G.k.4.r.10.1	Route of Administration (free text)	Text (60)	If G.k.4.r.10.2b cannot be used for the form design, use this location instead
G.k.4.r.10.2a	Route of Administration TermID Version Date / Number	As per ISO IDMP
G.k.4.r.10.2b	Route of Administration TermID	Number (3)	Allowed values are from standard Routes of Administration (those codes) Examples: ‘048’ = Oral If value translations are used against an EDC codelist, also ensure the E2B value is a full THREE characters, i.e. padded zeros included.
G.k.10.r	Additional Information on Drug (coded) (repeat as necessary)	Number (2)	This location can be mapped to an Item Definition in a non repeating or (more typically) repeating item group. Since there is often more than one answer, a repeating item group location (usually standalone) would be more preferred. E2B allowed values are listed below. Value Meaning 1 Counterfeit 2 Overdose 3 Drug taken by the father 4 Drug taken beyond expiry date 5 Batch and lot tested and found within specifications 6 Batch and lot tested and found not within specifications 7 Medication error 8 Misuse 9 Abuse 10 Occupational exposure 11 Off label use
G.k.11	Additional Information on Drug (free text)	Text (2000)	This E2B location allows for text longer than an item definition can support in Veeva EDC (1500). This location cannot be use a repeating item group to enter / derive more than 1500 characters (as H.1 / H.2 / H.4 locations allow)
G.k.7.r.1	Indication as Reported by the Primary Source	Text (250)
G.k.2.3.r.3a	Strength (number)	Number (10)	Rarely mapped in EDC for site to answer Usually configuration in the safety system itself
G.k.2.3.r.3b	Strength (unit)	Text (50)	Rarely mapped in EDC for site to answer Usually configuration in the safety system itself
G.k.4.r.6a	Duration of Drug Administration (number)	Number (5)	Often not mapped on the EDC form, instead calculated in the safety system
G.k.4.r.6b	Duration of Drug Administration (unit)	Text (50)	Often not mapped on the EDC form, instead calculated in the safety system WARNING: Units in EDC will need to be mapped to the safety system’s allowed unit values, which are generally the Unified Code of Measures. However, valid units can be rejected by a safety system without proper configuration there, and lead to a rejection of the safety case E2B XML. For awareness and review, the Studio Validations job will always warn about any mapped units.
G.k.4.r.7	Batch / Lot Number	Text (35)
G.k.4.r.9.1	Pharmaceutical Dose Form (free text)	Text (60)
G.k.5a	Cumulative Dose to First Reaction (number)	Number (10)	Often not mapped on the EDC form, instead calculated in the safety system
G.k.5b	Cumulative Dose to First Reaction (unit)	Text (50)	Often not mapped on the EDC form, instead calculated in the safety system WARNING: Units in EDC will need to be mapped to the safety system’s allowed unit values, which are generally the Unified Code of Measures. However, valid units can be rejected by a safety system without proper configuration there, and lead to a rejection of the safety case E2B XML. For awareness and review, the Studio Validations job will always warn about any mapped units. The E2B for ‘unknown unit’ {DF} (with the brackets) can be used as a last resort where the EDC answer will never fit the configured units in safety
G.k.6a	Gestation Period at Time of Exposure (number)	Number (3)
G.k.6b	Gestation Period at Time of Exposure (unit)	Text (50)	E2B allowed values are listed below. Value Meaning m Months w Weeks d Days {Trimester} Trimester

Medical History

To save item configurations for this safety 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 where a mapping is intended, use the cell in the Configured Item column to select the appropriate Item Definition of the Form Definition. For example, choosing the MHTERM item from the form for the E2B location D.7.r.1.5.

4. Depending on the Item Definition type for the selected item and the E2B ID of the row, Value Translations might be needed. Refer to the general overview of setting up these value translations.
5. Click Save (to remain on the page) or Save and Next (to advance to the next tab, Inclusion Criteria).

E2B ID	E2B Label	E2B Type	Notes
D.7.1.r.1a / D.7.1.r.1b	Medical History MedDRA Coding and Version	(Coding / Version)	To transfer the coded value for a verbatim, map the verbatim field here. If no coding is configured for this field, the E2B location will not be inserted into the E2B XML. If the verbatim is not coded yet, the nullFlavor will be inserted (see Safety Settings). The MedDRA version will be automatically inserted from the Veeva Coder setup of this form. Common practice is to map the verbatim for Medical History in the Comments field (D.7.1.r.5) to transfer the verbatim, particularly if the value is not yet medically coded.
D.7.1.r.5	Comments	Text (2000)	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 this field is mapped to the same verbatim field as D.7.r.1a/b, the coded term and the dictionary version will be transferred in D.7.r.1a/b, whereas the actual verbatim will be transferred with D.7.1.r.5.
D.7.1.r.2	Start Date	Datetime	Partial dates are allowed
D.7.1.r.3	Continuing	Boolean (or NullFlavor)	The destination safety system would normally set this based on the “End Date” being present (or not). If so, then there is no need for an Item Definition on the form, with mapping to this location. E2B allowed values are listed below. Value Meaning false No true Yes UNK Unknown ASKU Asked But Unknown NASK Not Asked
D.7.1.r.4	End Date (value)	Datetime	Partial dates are allowed
D.7.1.r.6	Family History	Boolean
D.7.2	Text for Relevant Medical History and Concurrent Conditions (not including reaction / event) (Singular Case Field Only)	Text (10000)	This E2B location is only ONCE for a safety case, i.e. a medical history narrative. Best practice is to not group this field on the same form as the D.7.1.* fields, which represent a medical history entry, each form.

Drug History

To save item configurations for this safety 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 where a mapping is intended, use the cell in the Configured Item column to select the appropriate Item Definition of the Form Definition. For example, choosing the HIST_DRG_NAME item from the form for the E2B location D.8.r.1.

4. Depending on the Item Definition type for the selected item and the E2B ID of the row, Value Translations might be needed. Refer to the general overview of setting up these value translations.
5. Click Save (to remain on the page) or Save and Next (to advance to the next tab, Inclusion Criteria)

E2B ID	E2B Label	E2B Type	Notes
D.8.r.1	Name of Drug as 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.4	Start Date	Datetime	Partial dates are allowed
D.8.r.5	End Date	Datetime	Partial dates are allowed
D.8.r.6a / D.8.r.6b	MedDRA Coding and Version (Indication)	(Coding / Version)	Medical Coding on the Item Definition must be setup for values to flow There is no verbatim location for this E2B location, only the coding
D.8.r.7a / D.8.r.7b	MedDRA Coding and Version (Reaction)	(Coding / Version)	Medical Coding on the Item Definition must be setup for values to flow There is no verbatim location for this E2B location, only the coding

Test Results

To save item configurations for this safety 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 where a mapping is intended, use the cell in the Configured Item column to select the appropriate Item Definition of the Form Definition. For example, choosing the LBDT item from the form for the E2B location F.r.1.

4. Depending on the Item Definition type for the selected item and the E2B ID of the row, Value Translations might be needed. Refer to the general overview of setting up these value translations.
5. Click Save (to remain on the page) or Save and Next (to advance to the next tab, Inclusion Criteria).

E2B ID	E2B Label	E2B Type	Notes
F.r.1	Test 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.2.1	Test Name (free text)	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
(F.r.2.2a)	MedDRA Version for Test Name		NOT mappable, instead tied to F.r.2.1 The MedDRA version will be transferred without explicit mapping if the Test Name is: configured for coding by Veeva Coder and a code has been assigned
(F.r.2.2b)	Test Name (MedDRA code)		NOT mappable, instead tied to F.r.2.1 The MedDRA version will be transferred without explicit mapping if the Test Name is: configured for coding by Veeva Coder and a code has been assigned
F.r.3.1	Test Result (code)	Number (1)	For test results that use codelist type Item Definition E2B allowed values are listed below. If your EDC codelist does not align with these, use F.r.3.4 instead Value Meaning 1 Positive 2 Negative 3 Borderline 4 Inconclusive
F.r.3.2	Test Result (value / qualifier)	Number (50)	Numeric value only If the result and unit values cannot be separated, use F.r.3.4 instead
F.r.3.3	Test Result (unit)	Text (50)	The paired unit with the numeric test result (F.3.2) If the result and unit values cannot be separated, use F.r.3.4 instead WARNING: Units in EDC will need to be mapped to the safety system’s allowed unit values, which are generally the Unified Code of Measures. However, valid units can be rejected by a safety system without proper configuration there, and lead to a rejection of the safety case E2B XML. For awareness and review, the Studio Validations job will always warn about any mapped units. The E2B for ‘unknown unit’ {DF} (with the brackets) can be used as a last resort where the EDC answer will never fit the configured units in safety
F.r.3.4	Result Unstructured Data (free text)	Text (2000)	Test results that cannot fit into F.r.3.1 (codelist), F.r.3.2 / F.r.3.3 (value + unit) should instead use this location
F.r.4	Normal Low Value	Text (50)
F.r.5	Normal High Value	Text (50)
F.r.6	Comments (free text)	Text (2000)
F.r.7	More Information Available	Boolean	E2B values allowed: true false

Patient Characteristics

To save item configurations for this safety 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 where a mapping is intended, use the cell in the Configured Item column to select the appropriate Item Definition of the Form Definition. For example, choosing the DOB item from the form for the E2B location D.2.1.

4. Depending on the Item Definition type for the selected item and the E2B ID of the row, Value Translations might be needed. Refer to the general overview of setting up these value translations.
5. Click Save (to remain on the page) or Save and Next (to advance to the next tab, Inclusion Criteria)

E2B ID	E2B Label	E2B Type	Notes
D.2.1	Date of Birth (value)	Datetime	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 location and work
D.2.2a	Age at time of onset of reaction/event (number)	Number (5)	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.2b	Age at time of onset of reaction/event (unit)	Text (50)	If mapped, this age unit (and age value) will be used for ALL safety cases of a subject When not mapped, but the value (D.2.2a) is mapped, Years (a) will be used 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. E2B allowed values are listed below. Value Meaning a Years mo Months wk Weeks d Days h Hours {Decade} Decades
D.5	Sex	Number (1) (or NullFlavor)	E2B allowed values are listed below. Value Meaning 1 Male 2 Female MSK Masked UNK Unknown ASKU Asked But Unknown NASK Not Asked

In Case of Death

To save item configurations for this safety 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 where a mapping is intended, use the cell in the Configured Item column to select the appropriate Item Definition of the Form Definition. For example, choosing the DTHDT item from the form for the E2B location D.9.1.

4. Depending on the Item Definition type for the selected item and the E2B ID of the row, Value Translations might be needed. Refer to the general overview of setting up these value translations.
5. Click Save (to remain on the page) or Save and Next (to advance to the next tab, Inclusion Criteria).

E2B ID	E2B Label	E2B Type	Notes
D.9.1	Date of Death	Datetime	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.2.r.2	Reported Cause(s) of Death	Text (250)	Use a repeating or non repeating item group for this mapping, since multiple answers are allowed for the E2B location Medical coding - if configured - will also be transferred for the cause (MedDRA LLT value)
(D.9.2.r.1a)	MedDRA Version for Reported Cause(s) of Death		NOT mappable, instead tied to D.9.2.r.2 The MedDRA version will be transferred without explicit mapping if the Reported Cause of Death is: configured for coding by Veeva Coder and a code has been assigned
(D.9.2.r.1b)	Reported Cause(s) of Death (MedDRA code)		NOT mappable, instead tied to D.9.2.r.2 The MedDRA version will be transferred without explicit mapping if the Reported Cause of Death is: configured for coding by Veeva Coder and a code has been assigned
D.9.3	Was Autopsy Done?	Boolean (or NullFlavor)	E2B allowed values are listed below. Value Meaning false No true Yes UNK Unknown ASKU Asked But Unknown NASK Not Asked
D.9.4.r.2	Autopsy - determined Cause(s) of Death	Text (250)	Use a repeating or non repeating item group for this mapping, since multiple answers are allowed for the E2B location Medical coding - if configured - will also be transferred for the cause (MedDRA LLT value)
(D.9.4.r.1a)	MedDRA Version for Autopsy determined Cause(s) of Death		NOT mappable, instead tied to D.9.2.r.2 The MedDRA version will be transferred without explicit mapping if the Reported Cause of Death is: configured for coding by Veeva Coder and a code has been assigned
(D.9.4.r.1b)	Autopsy - determined Cause(s) of Death (MedDRA code)		NOT mappable, instead tied to D.9.2.r.2 The MedDRA version will be transferred without explicit mapping if the Reported Cause of Death is: configured for coding by Veeva Coder and a code has been assigned

Reporter / Sender Comments by System

Reporter / Sender Comment by System supports the configuration of non-E2B link EDC item values to appear in the Reporter Comments (H.2) or Sender Comments (H.4) for transfer via the E2B XML. The mapped item values will be listed as standardized notes in the Comment fields, and the values will be appended to any actual Reporter or Sender Comment text.

To configure the standardized notes, one (or more) items from a form are selected to be listed and appended to either the Reporter Comments (H.2) or Sender Comments (H.4).

Also repeating item groups, forms or events can be selected for inclusion. When repeating information is prepared for transfer via the Reporter or Sender Comments, each list item will indicate the sequence numbers to allow the unique tracing of the transferred data.

Forms and items mapped to other Safety Data Types can additionally be mapped to either the Reporter or Sender Comment.

The following example, key lab values, cohort, toxicity grade, and changes in toxicity grade were selected for transfer.

Note that the additional bulleted information is appended to the actual Reporter Comments, which have been mapped to H.2.

Note:

• Codelist labels are listed
• Date/Datetime is shown as entered by the site
• “no value” is listed if the item has not been entered

Example 1:

An adverse event form often tracks data which are not compliant, and transferable, with the E2B format. This CTCAE Grade field appears on the on the adverse event form:

It can be included in either the Reporter or Sender Comment field using this type by simple selection:

Each inclusion will result in a formatted bullet to the Reporter (or Sender) Comments in the E2B file.

Example 2:

The form for including such fields can also be a form that is not in use by another type. Key enrollment details might be useful in the safety system. The Enrollment form might be selected to include the randomization number, reason for enrollment, cohort, etc. in either the Reporter or Sender Comment field:

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 both of the following conditions are met:
  • On the Form Properties tab, all inclusion criteria evaluate to true, particularly the Key Safety Item
  • On the Item Configuration 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.
• 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 Medications
  • Medical History
  • Drug History
  • Test Results
  • Reporter / Sender Comments by System

Option Summary by Safety Type

Inclusion Criteria	Safety Data Types
	SCIE	Study Drug	Con Meds	Med Hist	Drug Hist	Test Res	Pat Chars	Death	Rep/Sen Comm
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
Automatically, due to being part of a safety case initiation event form
Filtered - in case already or linked by site user
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
• Death: In Case of Death
• Rep/Sen Comm: Reporter / Sender Comments by System

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	This option disables any other option For Study Drug: For all other 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: For all other types:
Start to end overlaps safety event start to end	The related event start to end date range overlaps with the start to end date range of the case initiating event. Commonly referred to as ‘ongoing at event start’. That is, the related event has a start date on/before the initiating event’s end date, and does not end before the initiating event’s start date. If date and time are involved in a comparison, both events have to have date and time configured. In this case, the comparison for on/before/after will honor the full date/time. If one of the two is ‘date only’, then the comparison is done ‘Date vs. Date’ 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) Example: “Include all concomitant medications being taken (ongoing) at the 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 (thus open ended), 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 is empty (thus so far in future), so includes 11-Mar
Start to end overlaps X days before safety event start	Whole number only The related event start to end date range overlaps with the initiating event’s start date or the start date minus (before) the specified number of days 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’ 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) 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 11-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	Whole number only The related event start to end date range ‘touches’ the primary event’s start date plus (after) a specific number of days Used when wanting to pull in subsequent events after the initial (primary) event that created the case. Example: “Include concomitant medications started within 3 days of the start, even if the event has ended.” SCIE Start SCIE End Related Data Start Related Data End Related Data In or Out? Notes 11-Mar 15-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 11-Mar 15-Mar 17-Mar Out Related form range does not touch March 11th to 14th (the 3 days after the SCIE start) 11-Mar 11-Mar 13-Mar 14-Mar In Related form range does touch the March 11th to 14th range 11-Mar 11-Mar 10-Mar In Related End is empty (thus far in the future), so includes the March 11th to March 14th range 11-Mar 11-Mar 10-Mar 10-Mar Out Related form range does not touch the March 11th to 14th range
Start to end overlaps X days before safety event end	Whole number only 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. 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’ 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) 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 5th to 12th range (the 7 days before the SCIE End) 11-Mar 12-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	Whole number only 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. 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’ 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) 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 the March 12th to 15th 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 15th range
First dispense	Applies only to the type Study Drug The first dispense - chronological order - across all dispense forms If date and time are involved in the study drug start/end the comparison for on/before will honor the full date/time. SCIE Start SCIE End Study Drug (Starts to Ends) Study Drug Data In or Out? Notes 11-Mar 11-Mar 01-Mar to 01-Mar 04-Mar to 04-Mar 07-Mar to 07-Mar 09-Mar to 09-Mar In (1) Specifically, the March 1st data 11-Mar 11-Mar 14-Mar to 14-Mar 15-Mar to 15-Mar 16-Mar to 16-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 11-Mar 11-Mar 11-Mar to 11-Mar 13-Mar to 13-Mar 15-Mar to 15-Mar In (1) Specifically, the March 11th data
Closest on/before safety event start	Applies only to the type Study Drug The closest dispense to the primary event start date, on/before. This option is the same as the “Closest on/before safety event (one only)” below, except with this option, other options can also be used 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’ 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/after safety event start	Applies only to the type Study Drug 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’ 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 type Study Drug The option works just like the Closest On/Before option However, when set, no other option can be used. This option includes one dispense of the study drug, that which is closest to the event start (on/before) See the examples above on the Closest on/before line. The same holds true with this option.
Drug dispense start before safety event start	Applies only to the type Study Drug The start date of the study drug form is strictly before the event start 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’ 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 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 type Study Drug The end date of study drug dispensing is strictly before the primary event start date. 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’ 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 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 11-Mar to 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
Automatically, due to being part of a safety case initiation event form	This option applies where both the Safety Case Initiation Event and other related data types use the same form design. Applies to the types: Study Drug Concomitant Medications Medical History Drug History Test Results In Case of Death
Filtered - in case already or linked by site user	Applies only to the type Reporter/Sender Comments by System The option has two meanings: if the selected EDC form is already included into the case due to the inclusion configuration through another Safety Type, the data on the form will be included Or, if the form is NOT already included in the case, but linked to the initiating event, the data on the form will be included in the appended Reporter / Sender comments listings
Always	The option means data is always included to the safety case from those classified EDC forms For Reporter/Sender Comments by System. For Patient Characteristics or In Case of Deathh types: (not 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)

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

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. For more detail and examples on each inclusion criteria option, see Option Meanings / Examples above.

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

Study Drug

This type of safety configuration is used to track dosing / dispensing information of a study drug in relation to the initiating events of the, i.e. those the clinical study is testing against subjects. The information will flow to the products / drugs section of a safety case. (G.* section of E2B).

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.

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

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 (For more detail and examples on each inclusion criteria option, see Option Meanings / Examples above):
   • 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 events start and end date. Check one or more options, or set specific Days value(s). At least one of these options must be selected / set.
4. Click Save and Close to finish.

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. (G.* section of E2B) 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)

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

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 (default: 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 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. The information will flow to the E2B D.7 section of a safety case. Multiple forms can be used with the type.

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)

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

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 (default: 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 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 E2B D.8 section of a safety case.

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.

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

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 (default: 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 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 E2B F.* section of a safety case. Multiple forms can be used with the type.

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.

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

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 (default: 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 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.

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

Reporter / Sender Comments by System

This type of safety configuration is applied to forms from any location in the casebook. For data that doesn’t fit anywhere in the E2B structure, this type is 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. Choose the appropriate of the two options listed in the table below.
4. Click Save and Close.

Option	Meaning / Notes
Filtered - in case already or linked by site user	The option has two possible meanings: If the form is also classified as another safety type, then only those forms that contain ‘In’ entries will have the additional data values generated to Reporter / Sender comments. Examples: CTCAE on Adverse Event form Severity on Adverse Event form More granular information (which doesn’t fit in E2B) for Study Drug / dispensing forms Or, if the form is not also classified as another safety type, then only those forms who are linked by site users to the primary event will have the additional values generated to Reporter / Sender comments. Examples: Answers from a Questionnaire CRF Any other form that is repeating, but an event only applies to some of the forms per site opinion
Always included	Values from the form will be included as system generated bullets in Reporter (or Sender) Comments for all forms in data entry using that form design. This option is most often used for data collected once per subject. Examples: Arm / Cohort Race Ethnicity

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 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 integration configuration 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 environment. 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.

E2B Elements Reference (System Generated)

The following table summarizes system-generated E2B elements that are additionally sent to the safety system in the Safety Case, together with the configured Item Configurations.

E2B ID	E2B Element	Data Type	Source	Explanation
N.1.1	Type of Messages in Batch	Number (2)	Static	This is always set to “1” for ICH ICSR.
N.1.2	Batch Number	Number (100)	System Generated	This value is a concatenation of the Site for the Subject (ISO two letter code), the unique identifier for your EDC system (unique to all Studies in that vault), the vault’s ID, the object record’s ID, a dash (“-“), and the numeric value for the Nth message of the case (for example, “US-VAULTCDMS-110377V6800000000L003-1”). The EDC system identifier has “TEST” appended to it when in non-production environments. For the message number, “0” is the first send, “1” is the first follow up, and so on.
N.1.3	Batch Sender Identifier	Text (60)	System Generated	This is the Batch Sender Identifier specified in the study’s Transmission Profile. This matches up with the sender profile configured in the safety system.
N.1.4	Batch Receiver Identifier	Text (60)	System Generated	This is the Batch Receiver Identifier specified in the study’s Transmission Profile. This matches up with the receiver profile configured in the safety system.
N.1.5	Date of Batch Transmission	Datetime	System Generated	The full date and time (in UTC) of when Vault creates the Safety Message and its XML file.
N.2.r.1	Message Identifier	Text (100)	System Generated	This is the same as “N.1.2”.
N.2.r.2	Message Sender Identifier	Text (60)	System Generated	This is the same as “N.1.3”.
N.2.r.3	Message Receiver Identifier	Text (60)	System Generated	This is the same as “N.1.4”.
N.2.r.4	Date of Message Creation	Datetime	System Generated	This is the same as “N.1.5”.
C.1.1	Sender's (case) Safety Report Unique Identifier	Text (100)	System Generated	This value is a concatenation of the Site for the Subject (ISO two letter code), the unique identifier for your EDC system (unique to all Studies in that vault), the vault’s ID, and the object record’s ID (for example, “US-VAULTCDMS-110377V6800000000L003”). The EDC system identifier has “TEST” appended to it when in non-production environments.
C.1.2	Date of Creation	Datetime	System Generated	Vault creates the Safety Message right before transmitting it. This field captures the date of creation to the second. It acts as a message identifier.
C.1.3	Type of Report	Number (1)	Static	This is set to “2” for “Report from Study”.
C.1.4	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 SAE.
C.1.5	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 C.1.5 value will be 8 AM on that date in the next scheduled transfer.
C.1.6.1	Are Additional Documents Available?	Boolean	Static	This value is always false’
C.1.7	Does This Case Fulfill the Local Criteria for an Expedited Report?	Boolean	Static	This value is always ‘NI’ (“No Information”)
C.1.8.1	Worldwide Unique Case Identification Number	Text (100)	System Generated	This is the same as “C.1.1”.
C.1.8.2	First Sender of This Case	Number (1)	Static	This is always set to “2” for “Other”.
C.1.11.1	Report Nullification / Amendment	Number (1)	System Generated	If the Message Type is “Amendment”, Vault sets this field to “2”. If the Message Type is “Nullification”, Vault sets this field to “1”.
C.2.r.1.2	Reporter's Given Name	Text (60)	From Site	Depending on the study’s option for Reporter (Safety Settings) this will be from the site’s principal investigator.
C.2.r.1.4	Reporter's Family Name	Text (60)	From Site	Depending on the study’s option for Reporter (Safety Settings) this will be from the site’s principal investigator.
C.2.r.3	Reporter's Country Code	Text (2)	From Site
C.2.r.5	Primary Source for Regulatory Purposes	Number (1)	Static	This value is always a ‘1’
C.3.2	Sender's Organization	Text (100)	From Site	This is the Name of the study’s Organization (in EDC, the sender).
C.5.3	Sponsor Study Number	Text (50)	Looked Up	This is the study’s name/label, if not set with a specific value in the Study Safety Settings section
E.i.9	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)
D.7.1.r.1a	MedDRA Version for Medical History	Text (4)	Looked Up	“MedDRA” is removed from the string. This field is only sent once it is Coded or Autocoded, because there’s no place for the Medical History Term in the E2B, only the coded values.
D.7.1.r.1b	Medical History (disease / surgical / procedure / etc.) (MedDRA Code)	Number (8)	Looked Up