Vault Objects are part of the application data model. You’re probably already familiar with objects: many standard objects have document fields that you use all the time, like Product, Study, and Country. The application data model is a critical part of what makes each Vault application unique. It provides context information that drives the business processes in each Vault application.
Each application has its own distinct application data model. For example, the structure of Study, Site, Location, Product, and Country in eTMF is part of the data model. Each of those items is an object. In PromoMats, the data model includes the Product and Country objects.
With this feature, Admins can easily customize and extend standard objects in the application data model (Product, Country, etc.) and create entirely new custom objects to meet their specific business needs.
The Vault Objects data model includes:
- Objects: Top-level in the data model; for example, Product, Country, and Study are all objects.
- Object Classes: Classification that applies to multiple objects; for example, User Role Setup and User Task are both object classes. An object with an object class applied has its own relationships, security settings, and custom attributes, but the object has a common set of standard fields and behaviors defined by the object class.
- Object Data Records: Items within an object; for example, United States and Canada are each object data records within the Country object.
- Object Fields: Fields that hold details associated with each object data record; for example, Indication and Product Code are fields associated with the Product object. Object fields support UTF-8 3-byte encoded characters.
- Object Types: Classification within an object that allows organizations to store data that is similar but not identical in a single object
- Object Relationships: Hierarchical (parent-child) or non-hierarchical (reference) relationships between objects and object data records; for example, a parent-child relationship exists between Study (parent) and Site (child), while a reference relationship exists between Site and Location. Reference relationships can also be self-referencing, for example, a Territory object where records can be individual countries or regions, with individual countries referencing a region to create a hierarchy within the object.
- Document Fields: Metadata fields associated with each document type; for an end user to select an object value/object data record for a field, Admins must configure a document field that corresponds to an object, for example, the Product document field corresponds to the Product object and is associated with all document types. Document fields support UTF-8 3-byte encoded characters.
Object Capabilities
There is a lot of functionality built around objects, including both basic functions like document field linking and more complex capabilities like Custom Sharing Rules and reporting.
Enhanced Object Record Selection Fields
When you click into an object-type document field, you’ll see a new picklist that shows the most recently selected data records first, then lists all records in alphabetical order. If you’re selecting a child object data record, each option is listed under its parent. For example, when selecting sites, they are grouped together by their parent study.
To use a more advanced search to find the correct data record, click the binoculars icon. From the Search dialog, you can search and filter to find a specific data record. You can hover over any field in the dialog record grid, and Vault will display a hovercard showing up to 1000 characters of the value of that field. If you’re selecting a record for a child object, Vault automatically applies a filter based on the parent data record. You can also click Select All to select all available data records or Unselect All to clear your selections if you accidentally clicked Select All. Note that Vault limits Select All functionality based on the maximum number of related records possible for a document.
Reporting
Admins can create custom report types to report on object records (products, departments, sites, etc). Using these report types, a user could view and export object metadata like:
- Listing of all products (with or without associated documents) that you can group by product details like Therapeutic Area or Product Family
- A listing of sites under each study country
- A listing of documents organized by Owning Department and showing the Department Code value for each department
Attachments
Using attachments allows you to upload and connect files to a specific object data record. For example, you could upload logos to each Product record. Admins can enable attachments individually by object, so they are available where relevant (for logos on Product records), but not where they are not needed.
Dynamic Access Control
Dynamic Access Control allows Admins to restrict which users can view, link to, edit, and delete specific object data records through Matching Sharing Rules and Custom Sharing Rules. This feature supports organizations that need to segregate access to individual records within an object, for example, individual products within the Product object or studies within the Study object. Admins enable this feature for specific objects, allowing organizations to provide a more granular level of security for one object without affecting others.
Object Types
An object type is a collection of fields that are grouped to capture similar but not identical data within a single object. For example, the Product object could include two types: Pharmaceutical and Medical Device. These object types share fields like Abbreviation and Internal Name, but each also has data specific to its business purpose like Dosage for Pharmaceutical and Model No for Medical Device.
Object Relationships
In addition to relationships with documents, objects and object records can have relationships to each other. For example, the standard eTMF data model provides a hierarchy of objects: Study to Study Country to Site, as well as a reference (non-hierarchical) relationship to the Location object.
Relationships can also exist between records within a single object. For example, in the custom Region object, an organization has an Asia-Pacific region, as well as regions for Southeast Asia, Central Asia, and Australasia, which have a hierarchical relationship to the Asia-Pacific region.
Configurable Object Record Page Layouts
Admins can modify the default page layout, by object, for data record detail pages. This feature allows Admins to organize the display of metadata in a way that makes sense for each object. For example, fields like Last Modified By and External ID are often not relevant to a user viewing a Product record, so an Admin may move those fields into a separate panel at the bottom of the product details page.
Field-Level Encryption
All Vault data today is stored securely. For sensitive information like Protected Health Information (PHI) and Personally Identifiable Information (PII), Vault offers a second level of protection that Admins can enable for field values.
Vault will provide additional security for values entered into fields where an Admin has enabled this option. They can only enable this option for a maximum of ten (10) fields per object.
Object Class
In the first release of DAC, Vaults included a single User Role Setup object to support access rules. Later, we introduced the concept of an “object class” and User Role Setup became a class of objects, rather than a single object. When using Matching Sharing Rules, each User Role Setup-class object can define matching fields for one or more objects.
An organization might use multiple User Role Setup objects if they use DAC in different contexts. For example, VeePharm’s eTMF Vault controls document access using the Study, Study Country, and Study Site fields to indicate a user’s context. In the same Vault, VeePharm uses Therapeutic Area to indicate a user’s context and control access to Product records. If VeePharm had a single User Role Setup object, it would need to include all of these fields. By using two objects with the User Role Setup class, each object needs fewer fields and record setup is easier for each object.
In V17R2, we expanded object classes for use outside of dynamic access control with the User Task object class. An organization can use User Task -class objects to plan, assign, and track units of work. For example, VeePharm uses a CTMS Vault to manage their clinical trials. VeePharm may use a User Task-class object to track ad hoc work needed to bring a site up to compliance.
Object classes can apply to multiple objects. Organizations can configure objects with a class. Those objects will have their own object relationships, security settings, and custom attributes, but those objects will also have a standard set of fields and behaviors defined by the object class.
Object Data Store Options
Vault offers both Standard and Raw data store options for Vault objects, with raw objects optimized for large or frequent transactions. The Raw data store option delivers fast write performance, but has a narrower feature set than standard Vault objects and requires technical knowledge to configure optimally. For this reason, we recommend thoroughly reviewing the documentation on raw objects before using this data store option.
Locked Objects
Some objects are only enabled in your Vault if specific applications are licensed. When not enabled, Vault locks these objects, ensuring users do not accidentally interact with functionality designed for unavailable applications. Locked objects are typically hidden in the UI, but Admins can view them in Admin > Configuration > Objects by clicking Show Locked. However, Admins cannot edit any details on locked objects.
Vault Objects in Multilingual Vaults
Currently, Admins are only able to add translations for field labels, not object data record values. For example, the Product Name and Country Name labels could be translated, but the product and country names (United States, Japan) could not.