QGenda's Complex Credentialing Systems
Creating a Clear Hierarchy for Complex
Credentialing Workflows
My Role: UX Designer | Duration: 1 Month | Project Status: Completed
Credentialing specialists manage large sets of clinical privileges that determine what procedures and responsibilities a healthcare provider is qualified to perform. Within QGenda, these privileges are organized into main privileges and individual privileges, with additional information such as qualifications, requirements, and competency criteria attached throughout the hierarchy.
The challenge was that this structure was not always straightforward. An individual privilege could belong to multiple main privileges, and the same privilege could have slightly different requirements depending on where it appeared. Credentialing specialists needed a way to customize this information for providers, while providers needed a clear and understandable view of the privileges they were being asked to request.
I worked on creating a more intuitive system that connected the credentialing specialist experience with the provider experience and made the underlying hierarchy easier to understand and manage.
Research and Discovery
I started by working closely with the product team and healthcare subject matter experts to understand how credentialing specialists think about privileges and how the underlying system was structured.
Because the privilege model was highly domain specific, understanding the terminology and relationships was an important part of the design process. I spent time breaking down the existing experience and identifying where information was being repeated, where relationships were unclear, and where the existing structure made it difficult to predict what a provider would see.
I also looked at the problem from both sides of the experience:
For the credentialing specialist, the system needed to provide enough control to configure the provider experience without requiring them to understand the technical structure behind the system.
For the provider, the resulting experience needed to communicate what privileges were available, what information was required, and what qualifications or competency requirements applied without overwhelming them with the complexity that existed behind the scenes.
This helped establish an important design principle for the project.
The system could remain complex, but the experience should not make users carry that complexity themselves.
Understanding the hierarchy
One of the biggest design challenges was determining how the hierarchy should be communicated.
The relationship between main privileges and individual privileges was not always a simple parent and child relationship. An individual privilege could appear under more than one main privilege, and the details associated with that privilege could be repeated or adjusted depending on its context.
That meant the UI needed to communicate hierarchy without suggesting relationships that did not actually exist.
I explored how the information could be grouped and progressively disclosed so users could understand the high level structure first and access additional details when they needed them.
Rather than presenting every qualification, requirement, and competency detail at once, the experience establishes a clear hierarchy and allows users to move from the broader privilege down into the more specific information. This made the system easier to scan while preserving access to the detailed information credentialing specialists need to manage.
Designing for two connected experiences
Another important consideration was that this was not an isolated configuration experience. What a credentialing specialist configured would directly affect what a provider saw. That meant every design decision had to account for both sides of the workflow.
On the credentialing specialist side, the UI needed to answer questions such as what information was being configured, where that information belonged, and how it related to other privileges.
On the provider side, the result needed to feel simple and intentional. Providers should not have to understand the underlying privilege architecture just to complete their credentialing process.
I treated the configuration experience as a way of shaping the provider experience rather than as a separate administrative tool.
The solution
I designed a clearer privilege management experience that gives credentialing specialists control over the information presented to providers while making the hierarchy easier to understand.
The interface organizes the experience around the main privilege and the individual privileges contained within it. Within that structure, credentialing specialists can review and configure the details associated with each privilege, including qualifications, requirements, and competency information.
The hierarchy provides a clear visual relationship between the different levels of information. Instead of presenting every detail with equal visual weight, the design establishes a progression from the main privilege to individual privileges and then to the supporting information associated with them. This creates a more digestible experience for users who are working with large and complicated privilege sets.
1
A high level view of the privilege hierarchy
From the Privileges tab, credentialing specialists first see a table of the main privilege sets. Each parent privilege can be expanded to reveal its individual privileges and associated details in a read only view.
This structure gives specialists an overview of what exists within each privilege set without immediately overwhelming them with every detail. It also creates a clear distinction between reviewing the existing structure and making changes to what providers will see.
2
The privilege drawer
Opening a parent privilege takes the credentialing specialist into a dedicated drawer where they can customize the information that will be shown to providers. This is where they can control which details, such as qualifications, requirements, and competency, are visible for the individual privileges within that set.
Because some privilege sets can contain hundreds of individual privileges, the experience uses interaction patterns to make the information more manageable. Features such as Show Only Active allow specialists to quickly narrow the list to the privileges that currently need their attention rather than scanning through the entire set.
3
Turning configuration into a clear provider experience
The provider experience translates the credentialing specialist's configuration into a more digestible view. At the top, providers see the key information for the overall privilege set, giving them context before they move into the individual privileges.
The individual privileges are then listed below, with the relevant qualifications, requirements, and competency details displayed based on the credentialing specialist's configuration. This allows providers to see the information they actually need without exposing the underlying complexity of how the privilege set is structured.
Making complexity easier to navigate
A major goal was to avoid solving the problem by simply adding more UI. Because the system contains a large amount of information, there was a natural temptation to expose everything at once. Instead, I focused on information hierarchy and progressive disclosure.
The design allows users to understand where they are within the privilege structure before asking them to make decisions about more detailed information. This is especially important when the same individual privilege appears in multiple contexts. The experience helps users understand the context in which they are making a change instead of forcing them to mentally connect repeated information across different areas of the system.
Creating a predictable provider experience
The other half of the solution was making the relationship between configuration and the provider experience more apparent.
Credentialing specialists are effectively creating the environment that providers will use to request their privileges. When configuring a privilege, they need confidence that the information they are setting up will translate into an understandable provider experience. The new structure makes that relationship more explicit.
The specialist can think about the configuration in terms of what the provider needs to see and understand, rather than having to reason about the underlying system architecture. For the provider, this results in a more focused experience where the relevant privilege, requirements, qualifications, and competency information are presented in a logical order.
Designing for scale
The system also needed to work beyond a single privilege or a small set of privileges.
Credentialing teams may manage many specialties, locations, providers, and privilege configurations. A solution that worked for one simple example would not be enough. I therefore approached the design as a scalable system rather than a single page.
The hierarchy, grouping, and information patterns needed to remain understandable as more privileges and more complex relationships were introduced. This meant thinking beyond the individual screen and considering how the interaction model could consistently support different privilege structures across the product.
The outcome
The result was a more intuitive way for credentialing specialists to manage the information associated with provider privileges while preserving the complexity required by the underlying credentialing system.
The design created a clearer connection between main privileges, individual privileges, and their supporting information. It also gave specialists greater control over the provider experience without requiring them to navigate an overly technical configuration model.
Most importantly, the project reinforced a broader design principle that I brought into my work at QGenda. Complex systems do not necessarily need to become simpler. The experience needs to make the complexity understandable.
By establishing a clearer hierarchy, separating levels of information, and designing the credentialing specialist and provider experiences as connected parts of the same workflow, I was able to turn a complicated privilege structure into an experience that was easier to understand, configure, and navigate.