Case Level Visibility

Case level visibility is the mechanism by which Admins restrict row-level access to certain users depending on who they are and what groups they are affiliated with. This allows for protecting sensitive information such as PHI or individual clinician performance data. Case level visibility is enforced via an interplay between attribution identifiers, measures, provider affiliations, users, and reports.

Broadly speaking, case level visibility restrictions keep users from seeing detailed information that is outside of their purview. “Outside of their purview” means that having a restriction implies a particular filter (or set of filters, if the user has multiple attribution identifier values). The filter is that the measure’s attribution field equals the core or derived attribution identifier value for the user. Users can browse as they like within the confines of their filter, but their actions might be limited outside of these confines.

“Detailed information” is not the same as any or all information. Some exceptions are carved out for information that’s sufficiently vague that users are allowed to see it even if it violates their visibility purview, even for fully restrictive reports. For example:

• Users can see the headline value of the measure (as in the peer comparison for fully restrictive reports).
• Users are allowed to split by date field (as in the leadership dashboard).
• Users are allowed to split by attribution field only if the restriction level allows it (as in the peer comparison for reports with blinded restriction levels).
• Users are allowed to mix and match the splits above with any filters that are driven from a quick filter.

All of these rules are independently and securely verified on the server using a redundant set of business logic. If the browser ever makes a request that violates the case level visibility rules, the server will refuse to serve back data. This should never happen through the legitimate use of the application. 

There is one corner case exception: If an Admin has failed to identify the attribution fields on measure 001 but did identify them on 002, and then an end user brings up 001 in Measure Analyzer and adds 002 as a comparison measure, the browser will make the request using the rules for 001, case level visibility is not automatically applied. However, the server will rightly complain about the request for 002.

Attribution Identifier Profiling

In the Attribution Identifiers screen, Admins can create attribution fields, such as provider ID, clinic ID, etc. These can either be “core” or “derived,” although by convention the only core attribution identifier is PROVIDER. All the “derived” attribution identifiers can be computed for a user based on the user’s core attribution identifier plus their profiled affiliations. As we will see in user profiling, however, it’s possible to hand-enter more attribution identifier values into a derived attribution field, which will complement any derived values.

Attribution Identifiers have a key (by convention, uppercase), which should not be modified once in use. 

Derived attribution identifiers require the profiling of a cluster name and a cluster namespace, which is used in affiliation profiling to tie together the affiliation values.

Each attribution identifier can have any number of comma-delimited attribution fields. This allows for more fine-grained control of attribution identifiers in their measure context. For example, a measure might have a column for PCP ID and another for surgeon ID. These both tie up to the PROVIDER attribution identifier, but we might want to differentiate them in the measure metadata.

Measure Profiling

In Measure Workshop, an Admin can specify a field as being an attribution field and associate it with any of the available attribution fields from attribution identifier profiling. 

It is possible, as noted above, to have different columns with different attribution fields, even if those attribution fields roll up to the same attribution identifier key. For example, if a field in the report is the clinic ID, Measure Workshop can identify that field as being an attribution field, assigned to “Clinic Name” (if that’s been profiled as an attribution field). 

If a measure fails to have the appropriate attribution fields identified, the case level visibility feature will typically silently fail to do any enforcement, even if the report is set up to be restrictive.

Namespaces are not considered relevant for measure columns and do not need to be present in the columnar data or denoted in the metadata. 

Provider Affiliation Profiling

The main way to effectively assign a derived attribution identifier to a user is to include that user’s provider ID in a provider affiliation. If an affiliation contains a user’s ID and has a cluster namespace and name that match one of the attribution identifier profiles, then the user will inherit the namespace and name of the affiliation as its derived value at that attribution identifier level. 

Note that the namespace is tracked and displayed in Ursa Studio at these derived levels, as it’s not done at the core attribution identifier level. However, the namespace is never shown to the end user and is not actually used for filtering with the data itself.

Admins can bypass provider affiliation profiling and assign users derived attribution identifier values by entering in these values by hand in the user profile. However, the only values that can be hand-entered in the user profile are affiliation namespaces and names that have been profiled in the provider affiliation tabs, with appropriate cluster namespaces and names to link them to that attribution identifier level.

User Profiling

All users with a provider ID should have that value entered in their user profile screen. If that value puts them in an affiliation that’s clustered into an attribution identifier, then they will automatically receive that derived attribution identifier value. Admins will be able to see this immediately as a read-only field. 

Within each attribution identifier level, Admins can manually append more values, but only the names of affiliations that are also correctly clustered into the same attribution identifier. A user with more than one attribution identifier value will be authorized to see data from each of their groups within their reports, depending on the restriction level of the report and their attribution field on the report.

Report Profiling

Users might have several different attribution identifier values at different attribution identifier levels. For example, a user might have a provider ID of 12345, but a specialty of CARDIOLOGISTS. When an Admin creates a report, he or she decides which, if any, attribution field will bind each user. The attribution fields do not need to be the same for each user; they are profiled on a report-user basis. 

The default restriction level is “Access All Cases,” which is the absence of an attribution field. Users with this restriction level will not have any case level visibility restrictions applied to them.

In the users panel on the report setup screen, Admins will also be able to designate a user as being a “leader” on the report. “Leadership” means that this user can see details for other users in the peer comparison screen and has unrestricted access to report data, even for restrictive reports.Being a leader is compatible with any attribution field designation and independent from case level visibility. 

Attribution fields can also be assigned by user group, in which case the application will behave just as if those users had been added individually with that attribution field. If the user is granted access both individually and via a group, then the individual attribution field wins out.

Admins can designate three different case level visibility settings for a report, which determine how case level visibility operates.

• Transparent: Do not enforce restrictions on attribution field. This is similar as far as data access authorization to simply setting every user to the “Access All Cases” level, with two differences: 1) Users who have attribution fields on the report can only see their own attribution field PHI-level case detail unless they are designated as being a “leader,” and 2) any user that has a profiled attribution field on the report will still be able to access features such as peer comparison and the quick filter buttons.
• Blinded: This is similar to transparent, but users are not allowed to filter for the performance of their peers and will be shown anonymized results (for all attributees except themselves) when slicing by the attribution field. Note that “peer” is considered in the context of an attribution field. If a user is profiled at the clinic level, the pertinent attribution field is the clinic field. They will see each clinic as a bar. They will not be able to see their individual peers. 
• Restrictive: A filter limiting the measure’s pertinent attribution field to the user’s attribution field will always be enforced. Peer comparison will only show the user’s attribution field against the average for all users.

Note that even fully restricted reports will fail to enforce restrictions in several instances. If a user does not have a derived or hand-entered value profiled at the level indicated in the report user, then they will be able to see everything. If the measure does not have the attribution field indicated in the report-user, then all users will be able to see everything for that measure, even as their access might be restricted for other appropriately profiled measures on the report. On the other hand, if these items are set up correctly but the data itself for a particular row has a null value for the attribution field, the case level restriction is applied, and these values are filtered out.

End-User Experience

The front-end user experience strives to be as transparent as possible about case level visibility restrictions. Every use-case shows attribution fields as a quick filter in the filter control. These options are adjacent to the quick filter options but can be distinguished because they always have a “headshot” icon, and they always show the-attribution-field:the-value. 

Attribution field quick filter buttons will exist for any attribution field that’s available to the user on the report, even if the user is not assigned to that attribution field. An exception to this rule is for users assigned to an attribution field for restrictive reports: These users will only have an attribution field quick filter button for their assigned attribution field. For all restriction levels, if the user has more than one attribution identifier value for an attribution field, each value will have its own button. 

Not all the measures on a report are guaranteed to have the same attribution fields profiled. This means that there might be an attribution field that’s relevant for a user for some measures on a report and not others. In the leadership dashboard, attribution field quick filter buttons will be present if any measure supports them. In other use cases, only the attribution fields relevant to the active measure will be listed.

Only one attribution field quick filter button can be selected at a time. Depending on the circumstance, the attribution field quick filter button might be disabled-and-off, disabled-and-on, or enabled for user toggling. Disabled buttons are not responsive to user toggling.

• The attribution field quick filter button will be disabled-and-off for those use cases that do not support attribution field filters, such as the driver diagram and opportunity discovery.
• The attribution field quick filter button will be disabled-and-on if the report’s restriction level is restrictive and there’s an applicable attribution field. This gets a little tricky if there are multiple attribution field quick filter buttons. At least one of these needs to be depressed, so by convention if none are selected, the first will be selected (disabled-and-on). If you press another attribution field quick filter button, then the first button will become togglable-and-off, while the newly selected button will become togglable-and-on. 
• The attribution field quick filter button can be toggled by the user if the report has a permissive or blinded restriction level, or in the leadership dashboard.

For use cases that support filter controls, the filter corresponding to the selected view will be shown in read-only mode. This is always redundant with the attribution field quick filter buttons and just helps reinforce the fact that a filter is being applied.

Peer comparison allows leaders (as designated in the report specification screen) to see the performance of every attributee regardless of the report’s restriction level. They are also able to choose among all the available levels of case level visibility.