# Label Concept & Deviation Tracking (RIM) When regulatory events and activities have labeling impact, Label Concept and Deviation Tracking in RIM Registrations allows for detailed tracking and management of the resulting labeling concept updates and deviations. Organizations enter proposed changes and send them to affiliate teams to provide local disposition and capture deviations in local labeling; Vault makes the changes and timelines globally and locally visible while the label content is approved, updated, and submitted.
## How Label Concept & Deviation Tracking Works ### Labeling Events and Labeling Concepts When creating an _Event_ record related to drug product labeling (a _Labeling Event_), you can use the _Labeling Impact_ field to indicate it as such. If _Labeling Impact_ is _Yes,_ Vault presents additional labeling-related fields to capture: * _CCDS to be Updated_ and _CCDS with Changes Reflected_: Impacted versions of the Company Core Data Sheet (CCDS) * _Safety Category_: The risk class to which it belongs * _Trigger Date_: Clock start date for completing the labeling update * _Due Date_: Based on the _Trigger Date_ and risk class Additionally, when _Labeling Impact_ is _Yes_, the _Labeling Concepts_ section allows you to create and associate _Labeling Concept_ records corresponding to section level changes proposed for the CCDS. ### Activities and Labeling Deviations Following impact assessment based upon the event's related _Products_, you can create _Activity_ records, either manually or in bulk, to provide detail of the new _Label Concepts_ to local affiliates. Referencing the _Activity_ and _Label Concept_ data, local affiliates submit the proposed changes to the local Health Authority. Should the local Health Authority reject or otherwise require updates to the proposed changes, the _Labeling Deviations_ object relationship with _Activity_ allows for tracking and management of instances where the local market's label differs from what was proposed in the event's _Label Concept_. ### Regulatory Objective Label Concept Tracking When label changes are locally-initiated, you can set the _Labeling Impact_ field on the _Regulatory Objective_ record to _Yes_, displaying additional labeling-related fields to capture _Corresponding CCDS_ and _Resulting Local Label_, the _Safety Category_, _Trigger Date_, and _Due Date_. ### Labeling Concepts in the Create & Manage Event Details Wizard When enabled for the Create & Manage Event Details wizard, you can include the _Event_'s related _Change Items_ and, optionally, any _Labeling Concepts_ related to those items. When gathering an event's details in the wizard, add any new **Labeling Concepts** as an **Optional Relationship**. ## Automatic Record Creation & Automation {#automatic-record-creation} When configured by an Admin, Vault can automatically copy _Labeling Concept_ records to underlying _Activity_ records, create _Labeling Deviation_ records based upon the outcome of an _Activity_ lifecycle, and calculate _Safety Category_ and _Due Date_ based upon labeling records. For Vault to successfully create and auto-name these records, the _CCDS Section_ (`ccds_section__v`) field is required. ### Labeling Concepts When you manually or bulk create an _Activity_ related to an _Event_, Vault copies the _Event_'s _Labeling Concept_ records to the created _Activity_. Additionally, as _Labeling Concepts_ are created, edited, or deleted, Vault maintains the related _Event_ and _Activity_ records' _Safety Category_ based upon the corresponding field within the associated _Labeling Concept_ record as follows: * When there are multiple _Labeling Concepts_ with varying safety categories, Vault compares the value across the records and selects the highest-value category (for example, _Class I_) to set within the _Event_ or _Activity_. * When a _Labeling Concept_ record is deleted, Vault assesses the value across the remaining _Activity_-related concepts. If no other records exist, Vault clears the _Event_ and _Activity_ records' _Safety Category_ field. ### Labeling Deviations When an _Activity_'s associated _Labeling Deviation_ is _Accepted for Dependent Countries_ (as indicated by the _Deviation Review Disposition_ field), Vault: * Copies the _Labeling Deviation_ record to any related dependent _Activities_ and sets _Deviation Review Disposition_ to _Accepted for Dependent Countries_. * Creates corresponding _Labeling Deviation_ and _Activity-Labeling Deviation_ records for any related dependent _Activities_. When the Labeling Deviation object lifecycle is configured to use the _Reviewed_ state type, Vault also defaults certain fields and creates these records in the mapped lifecycle state. Additionally, Vault can automatically create _Labeling Deviations_ based on the outcome of the _Activity_ and _Activity_ _Labeling Concept_ lifecycles as follows: * When an _Activity_ record reaches the lifecycle state configured as the _Filing Rejected_ lifecycle state type, for example _Not Approved_. * When an _Activity_ _Labeling Concept_ reaches the lifecycle state configured as the _Concept Rejected_ state type, for example _Rejected_. Vault only creates new records when there are no existing records with the same _Activity_ and _Labeling Concept_ field values. #### Labeling Deviations for All Dependent Markets Depending on your Vault's configuration, Vault may cascade deviation information to dependent markets. To do this, Vault skips the check which prevents the creation of more than one _Labeling Deviation_ per _Activity_ and _Labeling Concept_. This can be useful for organizations where a single labeling concept is associated with multiple deviations. ### _Lead Reference Market_ Due Date & _Activity_ Due Date Vault can maintain an _Activity_ record's _Due Date_ based upon its dependent activities' _Lead Reference Market Due Date_: When an _Activity Dependency_ record is indicated as a lead dependency (its _Lead Dependency_ field is set to _Yes_), Vault sets the _Activity_ field _Lead Reference Market Due Date_ with the dependency record's _Due Date_. Vault allows only one _Activity Dependency_ record to be indicated as the _Lead Dependency_. Then, an Admin can optionally configure a custom formula referencing the _Lead Reference Market Due Date_, in the _Activity_'s _Due Date_ field to calculate the _Activity_ based upon its dependent activities. ### Splitting Activities & Labeling Concepts During the splitting process, you can select _Labeling Concepts_ to split from an existing _Activity_. ## Related Permissions See Configuring Label Concept & Deviation Tracking (RIM) to learn about required permissions for working with the object records described here.