Helping non-lawyers find and track changes in healthcare regulations
Product design, Visual design, and Experience design for Relias.
OOUX
UX Design
Visual Design
Web
Client Site:
I worked as part of an Insight consulting team to bring Relias's product visions to life while our developers kick started their implementation. As part of a feature 'pod', I focused on the Regulation Management feature while four other teams focused on parallel features and projects.
Client
Relias
Timeline
Q4 2022, 12 weeks
Role
Senior Product Designer
What I Did
Product Design, UX Design, UI Design
Tools
Project Overview
Challenge
Create the ability to import changes to regulations, review the content of the regulations, and quickly connect them to the relevant Policies & Procedures, with an ability to track the Org’s awareness of the changes.
Output
Understand product problem, generate v1 solution, document solution with wireframes, high fidelity designs, and prototypes as needed. Acquire v1 stakeholder acceptance.
Team
Our team was primarily a Product Owner who also functioned as a SME and representative of the client, as well as a Business Analyst, our Lead Dev/Architect and myself as UX all from Insight. We were one pod working on this one feature alongside three to four other pods working on other features.
Context
In each healthcare organization, a set of administrative staff is responsible for updating the Organization’s Policies & Procedures based on the changes that come from larger governmental bodies. Healthcare Org’s and individual employees can both be reprimanded and held accountable in different ways when there are incidents due to not following the correct regulations. Many regulations are updated by government bodies and tracking the changes and their implications is an important but complex task.
Regulations
All healthcare in the United States is governed and subject to the rules and regulations documented in a number of federal, state, and local documents and codes. These codes are updated regularly, but any specific HCO may be impacted by three to dozens of documents, and will therefore need to be aware of the changes happening in all of those documents. Each HCO has their own set of regulatory rules and documents. These documents serve as a source of truth and are used to train and evaluate employees for performance and safety. The HCO documents must be an accurate reflection of the set of applicable rules, regulations, and codes that apply to each location of each HCO.
Data Approach
Knowing that the final product will need to accommodate a large number of regulation sources, we selected one of the most complex documents to use as our primary use case.
Title 42 of the United States Code
Title 42 is one of the most important federal codes that applies to healthcare and public health in general. Currently, the best way to view the regulations is through the National Archives's eCFR system.
Title 42 can boast up to twelve nested tiers of regulations in some sections, which provides a significant challenge in terms of visual communication, organization, and discoverability.
The product will leverage some search functionality, but will also need to provide a fallback navigation method where users can click through each regulation section like book chapters.
Voice of Client
The employees that do the work of monitoring the changes to their set of regulations and codes, understanding the content of the changes, and translating those changes to updates to the HCO's internal policies & procedures are called Healthcare Compliance Officers, and they and their teams have their work cut out for them. Through discovery our team had access to a small set of comments from Compliance employees and learned a number of the challenges they face while doing their work.
Most governing bodies do not provide information about what changes are being published.
"Some regulatory bodies publish information about the changes they are making with detailed information about the specific sections and why the changes were made, however the bodies that do this are in the minority."
Compliance personnel often need to manuallysift through the full language of a section in order to even find what was changed before they can begin writing the new policies.
Core Needs
The product needs to:
Keep an up to date copy of each applicable regulation document.
Find and track changes to the regulation text as they are published (daily).
Notify key personnel of the change, and provide a link to the modified text.
Provide a way to view the previous version next to the current version in order to fully understand the changes.
Connect the published changes to resulting changes in internal policies & procedures if applicable.
Track the awareness of the changes, and the work being done to address them.
Provide a simple and intuitive way for non-compliance staff (both healthcare staff and support staff such as janitorial employees) to find and consume the policies & procedures as well as the source regulations & codes.
Basic Flow
The product will address many of the issues HCO's report at multiple steps of the process by providing information when and where it is needed, and providing a clear path where there currently is none.
Product Overview
Regulation Table
Purpose
The core of all of the regulation information lives within this format and is therefore one of the most important surfaces that people will use to interact with regulatory information. Based on the Title 42 hierarchy structure, we identified that we would need to provide designs for an expanding and collapsing table that could feasibly approach 12 layers deep.
Visual Design
I went through many iterations of this table to figure out how we could make it as visually navigable as possible. Early iterations focused on merely fitting the content into an average web width, and later iterations honed in on ensuring that progressively nested children were visually distinct from their parents and children. The most successful concept leveraged a complex color palette that is accessible to all color-blindness conditions and makes the whole table much easier to parse.
Regulation Table
In context view of an average visible chunk of the massive nested table that shows how important the colored indicators can be. When a window can only show a sliver of the full structure, it will be easy to become lost in the hierarch without extra anchors.
Secondary Iterations
I explored extensive color theory options to create an accessible palette of colors that could represent each nested tier without repeating colors. Based on Federal Title 42, the system would needto handle up to 11 tiers.
Regulation Table
In context view of an average visible chunk of the massive nested table that shows how important the colored indicators can be. When a window can only show a sliver of the full structure, it will be easy to become lost in the hierarch without extra anchors.
Regulation Text
Strategy
The core challenge of the Regulation Text screens is that this is where the work to determine the what the regulation changes are and tracking the status of the changes decisions happens.
Text Accomodations
Regulation Text has no standard length, and can therefore be any length and contain many types of typographic content. This challenge is basically covered by treating this area like a blog post.
Details
Regulation details: The value add of the product. The iterations here only cover the first version of the product roadmap for this tool, so I worked closely with the Product Owner here to refine the high level ideas down to a set of features feasible for an alpha release.
Status
When a daily script detects a change to the official regulation text, compared to the version currently available in the Reilas tool, this kicks off a series of workflows and status changes. Compliance Officers will receive notification of a regulation to review, the status of the regulation will change to Pending Review, and then the CO will manage the status based on the actual changes in the text.
Regulation Text
Finally, we display the actual text of the Regulation. This needs to support rich text formatting (bolding, italics, numbered bullets, etc), as well as inline links to other regulations referenced in the text. I worked with my devs to implement a minimal set of accomodations for these customizations for v1, and we added many ideas to a backlog for future development.
Metadata
The layer that connects the regulation to all of the Org's policies, procedures, and issues, plus extra information about when updates last occurred, and who owns the regulation.
Statuses
Some Reg. changes don't require any policy changes in an Org., but they still need to be able to track that they reviewed the change and made a decision. We introduced this status workflow as a v1, with a list of expansion options for future features.
Regulation Text
In contex view of the v1 Regulation Text screen. Metadata, text comparisons, and more robust tracking features were delayed to later releases, but this v1 covered all of the core requirements for basic useage.
Process
Inheriting from Discovery
Discovery Phase
In this engagement with Relias, my role began after the primary discovery engagement had completed. This set my peers and I up to absorb the discovery data, product sketches, and concepts so that we could begin solutioning right away. The Discovery team spent several weeks actively interviewing stakeholders and user representatives, running visioning workshops, documenting concepts and ideas, and creating project plans, roadmaps, and backlogs.
User Interviews
A crucial component of our team's discovery output was the artifacts generated by their work following the ORCA process of the OOUX approach. I was able to start my phase of the project with a detailed and expansive documentation of the various entities, relationships, and structures that make up the mental models of this product.
ORCA -> OOUX -> Wireframes
When first learning the problem space for this project, I jumped quickly into working with the object model for our features. Below, I show the grid of stickies that represent the primary object (the Regulation), the various attributes with a few tagged as highest priority, all of the metadata with some tagged by priority, and the CTAs connected to the object.
There is far more theory and background to what these represent, why they're important, and what we should do with them, but this is a case study. I encourage you to review some of Sophia Prater's Introduction to ORCA Or her OOUX website.
Effectively, I could use the information prioritized in these stickies to begin sketching out rough wireframes. This was a rapid low fidelity iteration that won over our Product Owner quickly. At this point, everyone has a shared understanding of roughly what we're trying to build, some of the crucial hierarchy, and we can identify any core misalignments between understanding and business intent.
OOUX Object Model
Regulation Object broken into sub objects (blue), Attributes (yellow), Metadata (red), and CTAs (green).
OOUX Wireframe
I began by organizing the objects, attributes, and metadata into rough groups, and ordered them lightly within the space our feature would live.
Progressively Higher Fidelity
Starting with more known variables from Title 42, I began attempting to create a series of nested tables, assuming that was developable. However, my Dev partner quickly found that nesting tables would explode page load times, and make the site unusable.
Tables & Accordions
I presented the above nested table concept to my Pod. Everyone believed in the concept. Unfortunately our Dev found that implementing this concept as a set of nesting tables would quickly baloon the page load time and make the site unusable. He experimented on the idea for a bit in code and found that he could create a solution that used accordion elements in a similar way as my mockups! We quickly pivoted to fully leveraging accordion components for the next iterations.
Early Iterations
My second attempts focused on moving toward the accordion based interaction, and figuring out if all levels of nested information could be included in one table, how to differentiate the different tiers, and how to keep columns aligned.
Secondary Iterations
We eliminated some columns, and found a nesting system that provided enough information at each tier. Only Reg. Text-level rows needed additional data columns. Color factored in as an important wayfinding indicator.
Prototyping
Why Prototype?
Other members of the Insight UX practice completed a Discovery engagement with Relias months before, and had a ton of documentation on the problem space, IA, roadmap, and design system.
Workshops
The Insight UX Discovery also pulled information from business stakeholders that helped prioritize work, and generated an OOUX analysis.
Project Conclusion
Next Steps
Integration with Policies module
Viewing regulations is only half of the task. We had begun work to bring the Regs experience and the Policies experience together when the contract was ended.
View for healthcare practicioners
The primary use case for this version was for policy writers, but regular doctors, nurses, and other healthcare staff need to be able to read the regulations as well.
Incidents view & integration
Another workflow that the Relias product was supposed to include was documenting and responding to incidents, and ensuring repeat offenders were taking effective training to avoid incidents in the future.
Successes
High satisfaction from PO & client team
The PO for the feature and her peers in the product strategy group above us were all very happy with the final design and the efficient process we used to get there.
Implementation of complex UI
Collaborating with our Dev to find the best way to implement the nesting mechanism of the Regulations table led to highly accurate implementation of designs
Mentoring a junior designer through project
I was able to bring Rochelle through our process of gathering additional information from our PO and figuring out an efficient screen design order, which allowed her to ask a ton of questions and use that experience immediately on her next client project.
Failures
Full A11y testing on Regulation table
The design system we were building on came with some built-in a11y functionality, but we did not have an opportunity to test the table with any screen readers or other non-visual interfaces within the contract timeline.
Usability & acceptance testing
We were unable to do any testing of our designs with users of any kind. I can’t truly claim these designs are successful until I know that they passed usability testing.