rootwa sagar
Summary
A large hospital can have hundreds of roles, most of them needing different security access. Banyan’s security profiles carried more than 80 configuration points that needed to be managed individually. Roles in the system didn't map to security profiles, so mapping the right role to right security profile depended on knowledge held by a few people. Additionally, the permissions UI was not user friendly. All this lead to hiring a dedicated team for each hospital's implementation and hospitals admins having to depend on our teams to manage their setup.
The goal was to provide a scalable and reusable framework to control feature availability by client, location, and role. The key was to design something that runs parallel with real hospital systems so admins can manage provisioning confidently without needing a specialist.
My Role and Approach
I was the designer working with a PM and Engineer. My approach from design and strategy point of view was something like below:
- Learn what security really looks like inside a large hospital.
- See how competitors handle access and permissions.
- Bring our existing system in line with industry-standard models instead of inventing something new.
- Use Figma Make to try out ideas quickly before committing to one.
Research
Security levels in large hospital systems
I dug into the security layers a system the size of HCA needs: how access changes by clinical role, facility and department, which actions are riskier than others, and which rules come from governance instead of being decided locally. Those rules became the fixed edges of the design. In addition I learned about what moving number of moving pieces, how they affect each other and how they are controlled by the admins.
Competitive analysis
I went through how competing and adjacent products handle roles, permissions, inheritance and exceptions. I wanted to see which patterns admins already recognize, where products go their own way, and where everyone, us included, still struggles.
Internal audit of our existing system
I also mapped our own roles and permissions, along with every manual step an admin had to take to connect them. That made the hidden work visible: all the things an admin was juggling that the system should have been handling.
Existing UI of the varied access points
Exploring with Figma Make
The problem space was big, so I used Figma Make to try a lot of things fast. Working prototypes let me test different ways of structuring roles, assigning permissions and handling exceptions before I spent time on polished designs. It also got something in front of stakeholders much sooner than static mockups would have.
Security Profile Exploration
The purpose was to reduce the amount of cognitive load the admin user faces when configuring the profile. I broke down the decisions into parts so the each decision can drives the data for the next section of the profile.
View Prototype
Access Control Intelligence
When reviewing with admins, they expressed need to gain a bird’s eye view for the overall system to keep the system in check and perform troubleshooting. Another important aspect for them was keeping a tab on latest edits and having an audit trail of the system
Solution
In the end I folded the existing system into an industry-standard RBAC framework, so hospital admins manage permissions themselves, within guardrails set by the governing body. It comes down to four pieces:
- A role-based framework where roles tie directly to security and access, so admins stop managing variables by hand.
- Guardrails built in from the governing body's protocols. Admins have freedom inside the safe boundaries and can't step outside them. Notice how selecting the role condense the amount of security profile that admin can select from.
- A simpler permissions interface that a hospital admin can understand and change without special training. Notice how the permissions have been divided into which platform they affect. Additionally the linked permissions module explicitly shows the link to help understand the relation.
- A structured way to handle exceptions, for when someone needs access beyond their role, instead of ad hoc workarounds. Notice the security overrides that can be applied to users’ profiles. They come with an expiry so at the end of the expiry admin could analyze the exceptions to decide to either bake them into and existing profile or discard the overrides
Impact & Reflection
The project is currently in research and in validation cycles. My PM and myself are working across the board with tech leads to figure out feasibility and LOE; with the hospital admins and floor supervisors to test the robustness of the structure.
The biggest thing I took away is that this was never really a UI problem. The interface was hard to use because the model underneath it was undefined: roles that didn't mean anything, and rules that only existed in people's heads. Once the structure was fixed, a simpler experience became possible. I also learned to treat the guardrails as material to design with instead of something in my way.
rootwa sagar
Summary
A large hospital can have hundreds of roles, most of them needing different security access. Banyan’s security profiles carried more than 80 configuration points that needed to be managed individually. Roles in the system didn't map to security profiles, so mapping the right role to right security profile depended on knowledge held by a few people. Additionally, the permissions UI was not user friendly. All this lead to hiring a dedicated team for each hospital's implementation and hospitals admins having to depend on our teams to manage their setup.
The goal was to provide a scalable and reusable framework to control feature availability by client, location, and role. The key was to design something that runs parallel with real hospital systems so admins can manage provisioning confidently without needing a specialist.
My Role and Approach
I was the designer working with a PM and Engineer. My approach from design and strategy point of view was something like below:
- Learn what security really looks like inside a large hospital.
- See how competitors handle access and permissions.
- Bring our existing system in line with industry-standard models instead of inventing something new.
- Use Figma Make to try out ideas quickly before committing to one.
Research
Security levels in large hospital systems
I dug into the security layers a system the size of HCA needs: how access changes by clinical role, facility and department, which actions are riskier than others, and which rules come from governance instead of being decided locally. Those rules became the fixed edges of the design. In addition I learned about what moving number of moving pieces, how they affect each other and how they are controlled by the admins.
Competitive analysis
I went through how competing and adjacent products handle roles, permissions, inheritance and exceptions. I wanted to see which patterns admins already recognize, where products go their own way, and where everyone, us included, still struggles.
Internal audit of our existing system
I also mapped our own roles and permissions, along with every manual step an admin had to take to connect them. That made the hidden work visible: all the things an admin was juggling that the system should have been handling.
Existing UI of the varied access points
Exploring with Figma Make
The problem space was big, so I used Figma Make to try a lot of things fast. Working prototypes let me test different ways of structuring roles, assigning permissions and handling exceptions before I spent time on polished designs. It also got something in front of stakeholders much sooner than static mockups would have.
Security Profile Exploration
The purpose was to reduce the amount of cognitive load the admin user faces when configuring the profile. I broke down the decisions into parts so the each decision can drives the data for the next section of the profile.
View Prototype
Access Control Intelligence
When reviewing with admins, they expressed need to gain a bird’s eye view for the overall system to keep the system in check and perform troubleshooting. Another important aspect for them was keeping a tab on latest edits and having an audit trail of the system
Solution
In the end I folded the existing system into an industry-standard RBAC framework, so hospital admins manage permissions themselves, within guardrails set by the governing body. It comes down to four pieces:
- A role-based framework where roles tie directly to security and access, so admins stop managing variables by hand.
- Guardrails built in from the governing body's protocols. Admins have freedom inside the safe boundaries and can't step outside them. Notice how selecting the role condense the amount of security profile that admin can select from.
- A simpler permissions interface that a hospital admin can understand and change without special training. Notice how the permissions have been divided into which platform they affect. Additionally the linked permissions module explicitly shows the link to help understand the relation.
- A structured way to handle exceptions, for when someone needs access beyond their role, instead of ad hoc workarounds. Notice the security overrides that can be applied to users’ profiles. They come with an expiry so at the end of the expiry admin could analyze the exceptions to decide to either bake them into and existing profile or discard the overrides
Impact & Reflection
The project is currently in research and in validation cycles. My PM and myself are working across the board with tech leads to figure out feasibility and LOE; with the hospital admins and floor supervisors to test the robustness of the structure.
The biggest thing I took away is that this was never really a UI problem. The interface was hard to use because the model underneath it was undefined: roles that didn't mean anything, and rules that only existed in people's heads. Once the structure was fixed, a simpler experience became possible. I also learned to treat the guardrails as material to design with instead of something in my way.