Configuring Custom Objects and Fields
IN THIS ARTICLE
Custom Fields on Standard Objects
Custom Objects With Custom Fields
Custom objects and fields give Tendo applications the flexibility to be extended, and enable Tendo customers to store, display, and report on information that may be:
- Unique to their specific needs
- Not included in Tendo's delivered applications
- Required to generate proactive notifications and other patient interactions
- Necessary to drive decision-making for providers
Tendo Customer Engagement works with customer healthcare organizations to design custom objects and fields as those organizations need them. This allows customers to extend Tendo's data model with data that is not currently available through Tendo.
Custom objects and fields function like standard Tendo objects, following the same rules, processes, and procedures. Custom object relationships can be created, access controls for custom objects can be set up based on roles, and basic Create, Read, Update, and Delete access to custom objects can be specified by role configuration within the system.
Custom object and field names are created with the suffix _c.
Examples of ways in which custom objects can be used:
- Social determinants of health not included in Tendo’s out-of-the-box Patient Care Journey model
- Next wellness visit and other key data sourced from non-Electronic Health Record (EHR) systems
- Flags, categories, and numeric scores populated by Tendo QSV or customer analytics systems
- ePro and other data that may be specific to a service line, and must be stored in a tabular format for aggregation into reports and charts
The following can be customized:
- Configuring relationship properties for custom reference fields
- Creating new Value sets and Value Set items for custom fields
Custom objects support the same Object APIs and events as standard objects and fields, including tenant-specific custom objects and fields that the user is allowed through their domain and role access controls:
- Describe
- Query
- Upsert
- Delete
- Configurable object actions
Tenant templates
Custom objects, fields, relationships, events, value sets, etc. can be seeded into a tenant template. These seeded definitions are created as tenant-owned when the tenant is provisioned from a template.
Custom objects and fields are removable, so broken references can be avoided by removing the reference or asking the user to resolve them and blocking deletion.
Tenanted custom objects and fields will handle template export, provision, and destroy calls.
Custom fields on Standard Objects
Changes to standard objects and standard field data aren’t allowed, but many Standard Objects can be extended by adding custom fields to them.
For example, a customer might want to add a custom field to a standard object such as the Patient object if they want to record data about the patient that Tendo doesn't provide out of the box such as some social determinants of health.
An Allow Custom Fields flag is on standard object definitions to limit which standard objects can be extended.
Two types of objects cannot be extended with custom fields. They are labeled in rose in the Objects list view.
- Abstract objects - These are a few broad generic objects such as Team and Case. These objects are used as a basis for creation of more specific objects. For example, the Team object can be used to create more specific team objects such as Provider Team or Organization Team which have the same attributes as the Team object, but also are customized for more specific uses. The Team object is used as the basis for those specific team objects to which custom objects then can be added.
- Detail Only objects - These are objects that are embedded in other objects, such as the Address object which has a dependent relationship with the Appointment object. In the lists of objects under the Objects tab in Tools > Data, detail objects are marked Detail Only.
See a list of Detail Objects in Confluence.
Custom objects with Custom Fields
Custom object and field definition records are linked to the Tenant as the owner.
Some object data can be updated including labels and descriptions.
All fields except system-defined fields are mutable. However, not all attributes of a field are mutable, including Field Type and API Name. In order to change field types, delete the existing custom field and create a new one with the new field type.
End-to-End User Experience Flow
This is a high-level view to create and edit a custom object:
Navigate to Atrium, and choose Tools from the main navigation menu in the upper left corner. Click on Data on the main left navigation side bar. Click on Object.
Steps:
- Create an object definition in the UI in the staging environment.
Create field definitions individually in the UI.
Test the schema in Staging.
Update object and field definitions individually in the UI in Staging.
- Object Edit
- Object Delete
- Field Edit
- Field Delete
- Upon completion of testing, use Change Sets to move objects and fields definitions to the production environment.
- Smoke test in production to verify proper completion of the uploaded schema.
Here is a diagram of the process:
Deleting Custom Objects and Fields
Deletes are a specific API call to delete an object definition. Custom field deletions are allowed, and are a separate API. The system checks whether any reference fields exist to the object. If a reference exists from another object, an error will be returned alerting the user that the object can’t be deleted until all references to the object are removed.
If there are no references, the system will delete all record data, then remove the field and object definitions from the system.
All data that resides in the field will be removed from the system. Then the field definition will be removed.