Guides

Role-Based Permission Mapping for Connect Access

This page outlines the approach for implementing role-based permission mapping within the z-PAX platform to control access to Connect features across corporate, segment, and facility levels. Permissions are derived from role claims provided in the SAML assertion, enabling flexible integration with external identity providers. By mapping configurable role names to structured permission sets within the database, z-PAX can ensure that users receive the appropriate access controls based on their organizational scope, whether they belong to a corporation, a regional segment, or a specific facility. The following sections detail the required role configurations, example mappings, and the information needed from integrating vendors to support this model.

There are three permission types:

  • Corporation
  • Segment
  • Facility

Mapping Corporate and Segment Roles to Permissions

For both Corporate and Segment users, z-PAX permissions are mapped directly within the database and are assigned based on the role claim provided in the SAML assertion. The specific role names used in the assertion are configurable and can be aligned with the naming conventions of the integrating company. For example,

A role named "Corp" would be mapped to the following permission set:

<Permission>
    <org_code>org_code</org_code>
    <access_type>CORPORATION</access_type>
    <is_admin>true</is_admin>
    <activity_log_summary>true</activity_log_summary>
    <activity_log_details>true</activity_log_details>
    <restrict_alert_snooze>false</restrict_alert_snooze>
    <restrict_alert_resolution>false</restrict_alert_resolution>
    <mi_connect_access>true</mi_connect_access>
    <pdpm_connect_access>false</pdpm_connect_access>
    <rehab_connect_access>true</rehab_connect_access>
    <custom_connect_access>true</custom_connect_access>
    <quality_connect_access>true</quality_connect_access>
</Permission>

A role named "SouthwestUser" would be mapped to a separate permission configuration:

<Permission>
<org_code>org_code</org_code>
<access_type>SEGMENT</access_type>
<region>Southwest</region>
<is_admin>false</is_admin>
<activity_log_summary>true</activity_log_summary>
<activity_log_details>false</activity_log_details>
<restrict_alert_snooze>true</restrict_alert_snooze>
<restrict_alert_resolution>false</restrict_alert_resolution>
<cmi_connect_access>false</cmi_connect_access>
<pdpm_connect_access>true</pdpm_connect_access>
<rehab_connect_access>false</rehab_connect_access>
<custom_connect_access>false</custom_connect_access>
<quality_connect_access>true</quality_connect_access>
</Permission>

Facility-Level Role Mapping and Permission Generation

For facility-level access, a role such as “FacilityUser” (or another agreed-upon name) should be included in the SAML assertion. This role is configured to retrieve facility identifiers from a separate claim. In most implementations, these facility names or identifiers are provided through the OrgSiteNames claim. The identifiers must be shared with z-PAX in advance so they can be mapped to the corresponding CCNs (CMS Certification Numbers) in the database.

For example, a SAML assertion containing a "FacilityUser" role along with multiple OrgSiteNames values, such as villa-mv and beacon-hill:

<Attribute Name="role">
  <AttributeValue>FacilityUser</AttributeValue>
</Attribute>
<Attribute Name="OrgSiteNames">
  <AttributeValue>villa-mv</AttributeValue>
  <AttributeValue>beacon-hill</AttributeValue>
</Attribute>

will be recognized and translated into their mapped CCNs (for example, villa-mv = 675783, beacon-hill = 675503). Based on these mappings, z-PAX generates a corresponding permission set for each facility, similar to:

<Permission>
<org_code>org_code</org_code>
<access_type>FACILITY</access_type>
<ccn>675783</ccn>
<is_admin>true</is_admin>
<activity_log_summary>true</activity_log_summary>
<activity_log_details>false</activity_log_details>
<restrict_alert_snooze>false</restrict_alert_snooze>
<restrict_alert_resolution>false</restrict_alert_resolution>
<cmi_connect_access>false</cmi_connect_access>
<pdpm_connect_access>true</pdpm_connect_access>
<rehab_connect_access>false</rehab_connect_access>
<custom_connect_access>true</custom_connect_access>
<quality_connect_access>true</quality_connect_access>
</Permission>
<Permission>
<org_code>org_code</org_code>
<access_type>FACILITY</access_type>
<ccn>675503</ccn>
<is_admin>true</is_admin>
<activity_log_summary>true</activity_log_summary>
<activity_log_details>false</activity_log_details>
<restrict_alert_snooze>false</restrict_alert_snooze>
<restrict_alert_resolution>false</restrict_alert_resolution>
<cmi_connect_access>true</cmi_connect_access>
<pdpm_connect_access>false</pdpm_connect_access>
<rehab_connect_access>true</rehab_connect_access>
<custom_connect_access>true</custom_connect_access>
<quality_connect_access>true</quality_connect_access>
</Permission>

Information Required from Integrating Vendor

The integrating vendor must provide the following information:

  • A list of role names to be used for corporate users, segment users, and facility users.
  • A list of facility names or identifiers that will be included in the Facility identifier claim (OrgSiteNames).