Identity and Access Management (IAM)

To manage roles and permissions in Tendo’s identity and access system, you must be granted an appropriate role in the Tools app and the Admin app in Atrium. Contact Tendo Support for assistance.

When a user logs into Atrium, the identity system checks their credentials to see if they have permission to log in, and the access management system checks their permissions to determine which applications they can access in Atrium. Only the apps that they have permission to access will appear on the application dropdown menu in the top left corner.

Application pages are adjusted based on permissions.

Identity and Access Management Data

To enable user access, several pieces of data must be in the system to define the user record, link it to the user's login credentials in Identity, and link the user record to the permissions that they have been granted.

Every Tendo user has a User record that is central to Identity and Access Control. It links all of the other necessary data:

• Person record - This contains personally identifiable information (e.g. name, birthdate, address, etc.)
• Identity Account - Maintained separately in the identity system, this account links Auth0 accounts which maintain user login information including user name and password. The account also links other data that the identity system uses to track registration.
• Domain - Defines the set of resources to which users could possibly be granted access (e.g. Internal Domain or Patient Domain).
• Role Assignments - A user needs to be assigned one or more roles to have access permissions to use Tendo apps.

Some of this data is created by a system administrator, while some is delivered and maintained by Tendo.

• User, Person, and Identity system data are created either directly by the administrator or indirectly through actions that the administrator takes.
• Domains are created and maintained by Tendo and are associated with the User record by the system.
• Tendo delivers a set of base Roles for commonly used sets of permissions. Roles administrators also can define custom roles to alter users' access rights.

Tendo's Identity and Access Management (IAM) features serve as the security framework governing user access to Tendo’s system and its resources, including apps. Two primary systems work together to give users access:

• Identity system - This handles user authentication, maintaining and verifying user logins.
• Access control systems - These manage user access to specific applications and features, as well as restrictions on their actions within those applications.

Users of Tendo’s apps must be both authenticated users and have roles and permissions assigned to them. If a person tries to log into Tendo without a user or a role, access is denied. When a user enters the Tendo system, they are only able to access records that the system has determined they can access. All access points to Tendo’s apps use access control features which turn on parts of Tendo’s apps for users based on their assigned roles and permissions.

Terms and Concepts

These concepts help define and control who gets permission to what assets:

Authentication - The process of proving that someone is who they claim to be.

Authorization - The process of determining what resources a user can access and how they can interact with them. A resource is any application, object, API, UI, etc. that needs restrictions on access to it.

User - A person or system that will access resources.  A user is defined by an individual record in the User object in Tendo.

Action - Any well defined operation that a user can carry out on a resource.

Permission - A tuple (an ordered, immutable collection of elements) of an action and a resource that can be granted to a user.

Access control at Tendo works by:

• Defining roles and assigning them to users. When a user tries to carry out an action, the access control system checks to see whether any of their roles grant them the necessary permissions. If not, the action is denied.
• Some access control policies are based on rules with conditional logic that evaluate the attributes of the user, resource, action, and environment.
• Some resources access policies consisting of rules involving relationships between users.

Three Levels of Permissions

A user can be granted three levels of permissions:

Application Level Access

This gives users permission to access a particular application and the pages within. The degree of access can vary based on what the user needs to do in an app. For example, users with CDI Specialist and CDI Manager roles can both use the QDI app, but only CDI Managers have access to Reports in the app.

Object Level Access

Tendo’s system is based on the Tendo Object Model. Fields that appear in the apps are stored in Objects. For example, the Appointment object stores fields that pertain to appointments, such as the provider, the start and end date, and the type of appointment. Users need to have access not just to applications, but also specific objects.

Record Level Access

Object Records are individual records populated with actual data associated with an object. For example, an individual patient’s Appointment Object Record would include data in the object’s fields about a specific appointment. Access to this information would be restricted to clinical staff such as members of a provider’s team who need to access the patient’s clinical data to provide care. Record Level Access Controls also limit access to a user’s relationship to a record based on manual sharing, i.e. reports that are manually shared with individuals and groups.

In this scenario, everyone on both physicians teams has broad access to non-sensitive data, while sensitive data requires access control. Condition categories control sensitive data, and roles give access to data controlled by a condition category.

Physician A, the primary care provider, has a role that enables them to access non-sensitive clinical data of patients that is related to metabolic disorder conditions. However, this provider can’t access sensitive clinical data about this patient’s mental health conditions because of access restrictions that are tied to condition categories.

This primary care provider and team are responsible for initiating or responding to patient message threads on Message Thread A.

The second physician is a specialist with both Practitioner and Psych Practitioner roles, so they can access sensitive and non-sensitive clinical data of the patient that relates to both metabolic disorder conditions and mental health conditions. This provider and team are responsible for responding to patient messages on Message Thread B.

How roles work on both physicians' teams

A staff member of a physician’s team with an Admin role can access both sensitive and non-sensitive patient’s clinical data. They have a communication role that enables them to address patient messages on Message Thread A.

A staff member of a physician’s team who has Support and Receptionist roles cannot access any of the patient’s clinical data except for the patient’s insurance and scheduling details. As part of the physician’s team and with a Communicator role, they can address patient messages on Message Thread A on behalf of the physician.

A staff member with Lead Nurse and Psych Nurse roles can access a patient’s sensitive and non-sensitive clinical data. As part of both teams and with a Communicator role, they are responsible for addressing patient messages on both Message Thread A and Message Thread B on behalf of both physicians.

A staff member with a Nurse Role can access a patient’s non-sensitive clinical data. As part of Team B and with the Communicator Role, they can address patient messages on Message Thread B on behalf of Physician B.

Access Support Considerations

Google Auth

Access through Google Auth is tied to a user with a role:

After being authenticated by Google Auth during login, a user will be presented with a Select User modal which will have a dropdown to select a user from the tenant that they are logging into. This sets the user for all operations.

If the user is already set, it will return to the current state/user.

Users logged into Atrium through Google Auth have an option to switch users in the User menu at the bottom of the left navigation bar.

Audit logs include the Google Auth user’s Tendo employee account number and the assumed user’s user ID for the user that they are acting as when they:

• Log in/Log out
• The user is selected
• Switch to other users

Tendo Support Access to a User's Log In

Tendo Support or engineering occasionally needs to get access to customer environments for short periods to diagnose and resolve issues. This often means logging in as the customer user so that the issue can be reproduced. To gain this type of access, the user involved needs to grant login access to Tendo Support. This access is temporary (one month or less).

Only users who have granted this access are available to Tendo Support. Tendo Support uses Google Auth for access. This restriction allows the user to grant Support access only to data to which they have access.

The grant login access feature shifts the responsibility of giving access to the user, and assures that they are aware of the access being provided. With this feature, Tendo assures that the customer organization controls who in their organization can grant login access, the scope of the grant is limited to the scope of the grantor’s permissions, user credentials are not shared, access time is limited, and there is a timestamp on the access that the Tendo employee has.

Tendo employees accessing customer environments should be invited as full users with user records and role assignments, enabling their activities to be tracked as would the activities of any other user.

Temporary access typically is initiated through a customer support ticket, which may prompt a support or development engineer to access the environment. Access may be granted by the user to a Tendo employee through a grant to assume user, or an administrator could grant access to the employee to assume a specific user. These are the steps to grant Tendo Support access:

The user clicks on their avatar in Atrium and chooses Grant Tendo Access in the lower left menu that appears.

This brings up a modal in which the user selects the duration of the access and clicks Grant.

The Support employee will log into the customer tenant with Google Auth, and be allowed to select the user who granted access. Only users who have granted access and whose duration has not expired will be available to the Support employee. Only specific Tendo employees can access the users.

Audit logging includes which user granted access to the Tendo employee, when the Tendo employee logged in, and the user they assumed.

Customer Engagement Tenant Access

Tendo Customer Engagement personnel often work in customer tenants for extended durations configuring customer features, integrations, and setting up initial data. These employees should be set up as full users of the system with appropriate roles to complete their work.

New Tenant Setup

Contact Tendo engineering to get a new tenant set up. The typical process for setting up a new tenant is:

• Tendo Cloud Configurator (TCC) is used to create the new environment, and creates a first user as the Tenant Owner. This first user is a Tendo employee so that further setup can occur before the tenant is transferred to a customer.
• The Tenant Owner sets up other users who configure the environment.
• Once the environment is ready, the Tenant Owner role is transferred to a customer employee. Other Tendo employees (i.e. Customer Engagement) may remain in the environment for ongoing setup and support.

Emergency Recovery

At times, there may be critical issues that require a Tendo employee to access the environment to quickly fix it. This access is:

• Tightly guarded and secured so that few can access the environment.
• Points of access are isolated to a few people and can be changed when these employees leave Tendo.
• The head of engineering and Support are aware of and approve access, and it is communicated appropriately to customers.

 Disabling Employee Access

When an employee leaves Tendo, Support disables all access points. This includes:

• Tendo environments
• Customer environments
  • Stopping grants which have durations that have not ended.
  • Removing full user access to customer environments.

The expedient way to stop all access is through Tendo’s authentication service, Auth0, where all logins with variations of the employee email are disabled.

Contacting Tenant Owners and Administrators

Tendo at times needs to communicate with Tenant Owners and designated administrators, so Support must have the ability to send communications to Tenant Owners and designated administrators.