# CTMS Transfer CTMS Transfer automates the daily transfer of _Study_ data between CRO and Sponsor Vaults, assuming both organizations use Veeva CTMS. This is most useful in situations where Sponsors contract with CROs to fully manage their Studies. CTMS Transfer simplifies data transfers between the CRO and the Sponsor Vault CTMS system and gives Sponsors read-only access to their trial data and CROs read-only access to _Oversight Issue_ data, both updated daily. The CTMS Transfer includes the following objects: | Object | Sent From | Sent To | | ---------- | --------- | ------- | | _Study Country_ | CRO | Sponsor | | _Site_ | CRO | Sponsor | | _Subject_ | CRO | Sponsor | | _Subject Group_ | CRO | Sponsor | | _Study Country Subject Group_ | CRO | Sponsor | | _Study Site Subject Group_ | CRO | Sponsor | | _Metrics_ | CRO | Sponsor | | _Metrics Over Time_ | CRO | Sponsor | | _Enrollment Status Log_ | CRO | Sponsor | | _Issue_ | CRO | Sponsor | | _Milestone_ | CRO | Sponsor | | _Monitoring Event_ | CRO | Sponsor | | _Oversight Issue_ | Sponsor | CRO | During transfer, Vault creates and updates records regardless of whether the associated object type is _Active_ or _Inactive_ in the target Vault. Vault also creates and updates records when users leave required fields blank in the target Vault. Vault does not run entry actions, entry criteria, validation rules, or event actions during transfer to help prevent unintended triggers. Additionally, steady state, superseded, and obsolete _Monitoring Documents_ transfer to the target Vault using the _TMF Document_ document type. Obsolete documents only transfer if they were previously transferred as steady state or superseded. Vault sets the _External Transfer_ field of transferred records to **Yes**. These records are read-only and cannot be modified in the target Vault. Additionally, Vault only transfers standard fields and values. Records using custom picklist values, lifecycle states, or object types for in-scope fields must be [mapped accordingly][1] in the source Vault to transfer. Vault sets the _Deleted in Source System_ field to **Yes** on transferred documents and records that exist in the current Vault but have been deleted in the source Vault.
## Transfer Enablement To use CTMS Transfer capabilities, an Admin must perform the following: ### CRO Vault * For in-scope objects, [map any custom object types, lifecycle states, and picklist values to standard values][1] via the Outbound Clinical Mapping UI. After this is done once at a system level, mappings apply to all transfers to all Sponsors and partners. * Add the following fields to relevant page layouts: * _System ID_ - _Protocol Deviation Sub Categories_ * *Standard Sub Category Mapping* - _Protocol Deviation Sub Categories_ * Map custom _Protocol Deviation Sub Categories_ to standard by populating the _Standard Sub Category Mapping_ field on the custom record. * In **Admin > Connections**, move _Clinical Network Connection_ to the _Active_ state. * Establish an active [Vault-to-Vault Connection](/en/lr/53358/) with the Sponsor. * Set up any necessary _CDX Rule Overrides_ to filter out records from transfer. * Send an _Agreement_ to the Sponsor. ### Sponsor Vault * [Add the following fields](/en/lr/26387/#show-hide-move) to relevant page layouts: * _External Transfer_: All objects in scope of CTMS Transfer * _Deleted in Source System_: All objects in scope of CTMS Transfer * _Source CRA_ - _Monitoring Event_ * _Source Monitoring Event Type_ - _Monitoring Event_ * _Source Milestone Type_ - _Milestone_ * _Source Principal Investigator_ - _Study Site_ * _Source Organization_ - _Study Site_ * _Study Management Model_ - _Study_ * _Source Category_ - _Issue_ * _Source Subcategory_ - _Issue_ * For the _Oversight Issue_ objects, [map any custom object types, lifecycle states, and picklist values to standard values][1] via the Outbound Clinical Mapping UI. * Optional: Configure the Study Lifecycle so that entry actions do not execute for studies where _Study Management Model_ equals _Outsourced_. * Optional: Configure a _Template Milestone Master Set_ for use with outsourced studies. * In **Admin > Connections**, move _Clinical Network Connection_ to the _Active_ state. * Establish a [Connection](/en/lr/53358/) to the CRO. * Accept the _Agreement_. ### CTMS Transfer Rule Set The CTMS Transfer _Rule Set_ sets the scope for transfer and determines what objects, fields, and values Vault transfers as a part of the _Agreement_. Veeva controls the _Rule Set_. You cannot modify or expand them, but you can constrain the _Rule Set_ via _CDX Rule Overrides_. These allow CROs to specify additional criteria for a given rule which can be useful to prevent the transfer of records in a certain lifecycle state or with a specific field value. You can reuse _CDX Rule Overrides_ across _Agreements_. You must add _CDX Rule Overrides_ to an _Agreement_ via a _CDX Override Agreement_ before sending the _Agreement_ to the Sponsor. The CTMS Transfer _Rule Set_ can support the transfer of steady state TMF documents in addition to the standard CTMS documents by selecting the **Include TMF Documents** checkbox on the CTMS Transfer _Agreement_. This selection prevents two separate CTMS Transfer and TMF Transfer agreements from running at the same time and simplifies the agreements process for Admin.
### Outbound Clinical Mapping UI: Custom Field Mapping {#mapping} The transfer scope is restricted to standard fields and values. You can transfer custom values if desired, but must map those custom values to standard values first. To do so: 1. Navigate to **Admin > Configuration > Outbound Clinical Mappings**. 2. From the **Object Selection** drop-down, select the relevant object. 3. Expand the **Custom Object Types**, **Custom Lifecycle States**, or **Custom Picklist Values** section. 4. Locate the custom field you wish to map on the _Object_, _Lifecycle State_, or _Picklist_. 5. From the **Standard Value Label** drop-down, select the corresponding **Standard Value Label** to map to the **Custom Value Label**. Vault automatically fills the **Standard Value Name** field. Select the **Do Not Map** option if CTMS Transfer should ignore records using this custom value. 6. Repeat these steps as needed. Records using unmapped custom picklist values, lifecycle state, or object type will not transfer and a _CDX Issue_ will be raised. For detailed information about setting up connections between Vaults, see [Managing Connections](/en/lr/53358/#vault-to-vault). ### Accepting an Agreement Vault creates the _Approve Agreement_ workflow task in the target Vault and sends notifications to relevant users. Once a valid user clicks **Accept**, and then selects the **Complete** verdict on the task, Vault launches the _Agreement_ wizard. The wizard displays details about the agreement, including the requesting Vault and study. Clicking **Next** displays more detailed information about the study and allows the receiving user to map the study in the source Vault to an existing study in the target Vault. The receiving user must click **Complete** and approve the agreement to activate the connection. ## Transfer Maintenance The _Perform Clinical Transfer_ job initiates a transfer between CRO and Sponsor Vaults once per day. You must select the **Schedule Transfer** field in the _Details_ section of the CTMS Transfer _Agreement_ for the _Perform Clinical Transfer_ job to run daily. If you do not select the _Schedule Transfer_, a source Vault Admin must manually initiate the transfer. Only items updated since the last transfer are included. Each transfer generates an _Agreement Transfer_ record that logs the start and finish time of the transfer. * _CDX Issues - CRO & Sponsor_ * _Resolving CDX issues - CRO & Sponsor_ * _Deactivating agreement - CRO_ * _Pausing Agreement - CRO_ * _Activity log - CRO & Sponsor_
Vault times out _Agreement Transfer_ records that remain in the _Extracting_ state for more than 24 hours and transitions the record to the _Finished_ state. ### CDX Issues When an agreement is unable to process a rule, Vault creates a _CDX Issue_ record in the Vault where the error must be resolved. There are four _CDX Issue Types_ that Vault may create: * _Record Mapping Issue_: Vault creates this issue type when a required mapped record does not exist. * _Document Configuration Error_: Vault creates this issue type when a mapped document type is missing. * _Server Error_: Vault creates this issue type when there is an error not related to object record mapping, document type mapping, or Vault configuration. In addition to other details, each issue record has a detailed _Error Message_ field to inform you of what actions need to be taken. For example, if a required mapped record does not exist, the _Error Message_ field would read: "No record with mapping record or matching Link field exists." ### Resolving CDX Issues With every _Issue_ record that Vault creates, it also creates a workflow that allows you to resolve the issue. The workflow for resolving an issue depends on the issue type. ### Object Configuration Error Types Selecting **Run Associated Rule** from the **Actions** menu attempts to process the failed rule again. Before selecting the action, you must resolve any configuration discrepancies. ### Deactivating an Agreement You can deactivate an agreement in two ways: * As a user in the target Vault, select the **Reject** verdict on the _Approve Agreement_ workflow task. * For an _Active_ or _Pending_ agreement, select **Deactivate Agreement** from the **Actions** menu. You cannot reactivate a deactivated agreement. ### Pausing an Agreement If you need to suspend an agreement for any reason, you can do so with the **Pause Agreement** action available on active _Agreement_ records. Pausing an agreement moves the record to the _Paused_ lifecycle state in both Vaults. You can unpause an agreement with the **Unpause Agreement** action. This returns the agreement to the _Active_ lifecycle state. ### Activity Log Vault captures activities related to the transferring and receiving of object records and documents using the _Agreement Activity_ object. Vault marks the _Direction_ field on the _Agreement Activity_ record as _Outgoing_ or _Incoming_ depending on whether the object record or document was sent or received. [1]: #mapping