Migrating Data to Veeva Safety

This guide provides best practices on migrating data into Vaults with the Veeva Safety application. The general best practices and data transformation considerations for Vault migrations apply to all application families.

Use Case

The primary use case for a Safety migration is a legacy migration. This involves migrating safety Cases from a legacy system to Vault. This commonly includes migrating the most recent versions of Cases, but may include migrating previous versions as well.

Safety Migration Configuration

Safety Migration Configuration is a feature that allows a designated user to migrate safety data into Vault via ETL Vault Loader or Vault API, while ensuring performance and data integrity. This also allows Cases to be migrated into a live Vault without altering the migrated data by applying Case processing automation (such as calculations or record auto-creations).

Safety Migration User

The term Safety Migration User will be used consistently in this article, and it will always refer to the user selected as the Migration user in the Safety Migration Configuration.

Effects

Safety Migration Configuration bypasses most triggers and actions available only for the designated Safety Migration User. Only a small subset of key triggers continue to execute, required for creating object records. This improves the performance of loading in Case records. See the list of bypassed auto-calculations for more information.

If the user attempts to execute a trigger that is not allowed during migration, the following error message appears:

You do not have permission to modify {0} records. Contact your administrator if changes are required.

Enablement

To enable the Safety Migration Configuration feature in your Vault, create the Safety Migration Configuration (safety_migration_configuration__v) object record, change its lifecycle state to Active, and assign it to a Safety Migration User.

The Safety Migration Configuration object is not shown in Business Admin by default, therefore, you must create an object record using one of the following methods:

Recommended: Use the direct link to the object tab: Go to https://{vault_dns}/ui/#object/safety_migration_configuration__v
Use Vault Loader or the Create & Upsert Object Records endpoint to create a Safety Migration Configuration record.
To create a record in the UI, navigate to Configuration > Objects> Safety Migration Configuration and change the Show in Business Admin setting to Yes. Some customers may require a change control to modify what is shown in Business Admin.

Safety Migration Configuration records contain the following fields.

Name	Description	Type
`name__v`	The system automatically generates a name for the record.	System-managed
`user__sys` required	Select the User record that corresponds to the migration user.	(Unique) Object reference to `user__sys` object
`enabled__v`	To activate this configuration and allow this user to bypass triggers for migration, set to Yes.	Yes/No

Considerations

Safety Migration Users cannot import E2B files. When you import a Case record using E2B Case Migration, the resulting Case is an Imported Case. An Imported Case is a special type of Case, reserved for previously processed and migrated Cases. See Migrate External Cases for more information.
Because product triggers are bypassed, you must ensure that core functional elements (versioning, idates, etc.) are populated manually.
Only the following user groups have permission to create Safety Migration Configuration (safety_migration_configuration__v) records:
- Vault Owners
- App Owner
- System
A Safety Migration User must already have permission to create the types of records they are migrating.
Once data migration is complete, you must perform one of the following actions in your Vault to resume normal access for the migration user:
- Edit the Safety Migration Configuration record and set the enabled__v field to No.
- Delete the Safety Migration Configuration record.

Bypassing Custom SDK Code

Veeva Safety product triggers are bypassed by default when they are triggered by the Safety Migration User.

Additional code needs to be written for custom triggers to have the same behavior. Failure to do so will result in major performance issues during migrations.

The following Vault Java SDK code demonstrates how to bypass a trigger in migration mode:

@RecordTriggerInfo(object = "case_version__v", events = {RecordEvent.BEFORE_INSERT, RecordEvent.BEFORE_UPDATE})
public class SampleTrigger implements RecordTrigger {
    @Override
    public void execute(RecordTriggerContext recordTriggerContext) {
        final QueryService queryService = ServiceLocator.locate(QueryService.class);

        // Get the current user ID from the context
        final RequestContext context = RequestContext.get();
        final String currentUserId = context.getCurrentUserId();

        // Query safety migration configuration for enabled users
        final String queryMigrationUsers = "SELECT user__v FROM safety_migration_configuration__v WHERE enabled__v='true'";
        final QueryResponse queryResponse = queryService.query(queryMigrationUsers);
        final boolean isMigrationUser = queryResponse.streamResults()
                .anyMatch(queryResult -> Objects.equals(currentUserId, queryResult.getValue("user__v", ValueType.STRING)));

        if (isMigrationUser) {
            return;
        }

        // Perform remaining trigger logic
    }
}

Bypassed Auto-Calculations

The following auto-calculations do not calculate when using a Safety Migration Configuration:

Case Relatedness: Veeva Safety automatically populates the Relatedness field at the Case-level, for high visibility of the relatedness (causality) evaluation from the primary Case Assessment and its Case Assessment Results.
Case Expectedness: Veeva Safety assesses expectedness for each Case Assessment through system-generated Case Assessment Expectedness records.
Dose Latency: Veeva Safety automatically calculates the First Dose Latency and Last Dose Latency on Case Assessment records.
Cumulative Dose: Veeva Safety automatically calculates the Cumulative Dose field on the Case Product when the required data points are available.
Case SAE and SUSAR Tags: New and revised Cases that meet the appropriate seriousness criteria are automatically tagged with SUSAR or SAE Case Tags to aid in ad-hoc reports and data analysis.
Case Watchlist Tags and DME: Veeva Safety automatically determines whether a Case should be tagged as a Designated Medical Event (DME) or with a preconfigured watchlist tag.
Age Fields: Veeva Safety automatically calculates and populates the Age (normalized), Age at Onset, and Age Group fields.
- Imprecise dates (_idate__v) to Normalized Dates (_date__v)
- Patient Date of Birth
- Patient Date of Death
- Patient Last Menstrual Period Date
- Receipt Date
- New Info Date
- Adverse Event Onset
- Adverse Event Cessation
- Medical History Start Date
- Medical History End Date
- Drug History Start Date
- Drug History End Date
- Case Test Result Test Date
- Dosage First Admin Date
- Dosage Last Admin Date
Localized Cases must have all children present
Assessments must point to an Adverse Event and Product
Cases must have a primary Product and Adverse Event