RIM Migrations

The following guides provide best practices for migrating Veeva RIM data into Vault. RIM migrations vary depending on which Veeva RIM application or combination of applications are affected. In each instance, the primary use case for a RIM Migration is a legacy migration. For all applications, there is a common element of both reference data and documents which gets migrated, in addition to application-specific elements. The general best practices and data transformation considerations for Vault migrations apply to all application families.

RIM Objects

RIM contains a set of objects that customers may choose to migrate from a legacy system into Vault via ETL Vault Loader or Vault API, while ensuring performance and data integrity. These objects can be grouped into three distinct categories:

Product Hierarchy
Study Data
Application Specific Objects

Product Hierarchy Objects

The reference product hierarchy data is typically not “owned” by RIM but consumed from other data sources within the organization, which can be populated either manually, via custom integrations or via migrations from legacy systems. Once in RIM, product hierarchy data can be synced to other Vault application families via Vault Connections. This data is a prerequisite for transactional application specific data and documents that reference them.

These product hierarchy objects consist of:

Product Family (product__v)
Product (drug_product__v)
Product Variant (product_detail__v)
Active Substance (drug_substance__v)
Inactive Ingredient (excipient__v)
Manufacturer (manufacturer__v)
Organization (organization__rim)
Contact (contact__rim)

Study Data Objects

Like product hierarchy data, the reference study data is not typically owned by RIM, but consumed from other data sources within the organization, which can be populated either manually, via custom integrations, or for customers with Veeva Clinical Operations via the RIM-Clinical Operations Connection.

These objects consist of:

Clinical Study (clinical_study__v)
Nonclinical Study (nonclinical_study__v)

Application-Specific Objects

The application data objects are the transactional objects owned by the business, and are typically updated during their day-to-day operations. Application objects can either span across RIM applications or be application specific. These objects often reference product hierarchy or study data and are also typically referenced by application specific functionality and documentation.

These objects consist of:

Application (application__v)
Submission (submission__v)
Regulatory Objective (regulatory_objective__rim)
Commitment (commitment__rim)
Health Authority Question (health_authority_question__rim)

Documents

Veeva RIM contains a number of common document types you may choose to migrate in from a legacy system. You must upload each document and assign it to a particular document hierarchy (Type > Subtype > Classification) in Veeva RIM. These will vary by application.

Considerations

For each document type it’s important to consider any fields that are mandatory as these must be populated during the migration. Certain document type fields are also object lookups that need to point to object data already within Vault. Therefore, you must populate the RIM object data first.

Preparations

We recommend transforming and cleansing the document data prior to loading it, by deduping the data in the source system, deciding what doctype it maps to, and ensuring any mandatory set format fields (such as picklists or related objects) are correctly populated.

If document states were available in the legacy system these can be migrated too. You should not migrate documents that are currently in active states (such as In Review, In Approval).

Renditions

Depending on the number of documents to migrate, the time it takes to generate renditions can affect time and performance. To improve performance, you can suppress renditions when creating documents until a user views the document in the Vault UI.

Versioned Documents

You should consider whether different versions or renditions of documents need to be included in the migration.

When updating previous document versions, you cannot update lifecycle states using Vault API. For example, if a previous document version was migrated to Vault in the wrong lifecycle state, you must delete and re-upload the previous versions.

Permissions

Permissions should also be considered for migrated documents to ensure only the correct users can access the appropriate documents.