Case Study: UX User Empathy via Data-First Thinking
Case Study: Product Design
Industry: Healthcare, Financial
Author: Michael G Byrne
Goals and Drivers
At the highest level, the goal was for a healthcare system to roll out a brand new, standardized, organization-wide overhaul of their clinical billing system and processes. This particular healthcare organization was quite large, and included a number of facilities, providing all manner of traditional medical services, as well as medical research and clinical trials.
The desired outcome of this new process, and the business rules that supported it were clearly documented. A schema for the data required was defined, and the expectation for the types of reporting and a naming convention were all mapped out. Read, write and view-only rules were well thought out and permissions based on the org chart heirarchy were also clear. But as neatly conceived as it was, everything was all still concept on paper. There was no actual software or tools in place to help users adopt this new process and workflow. No chosen vendor that could meet these needs had been selected. So creating a single tool for the many different finance teams was the big task at hand. One tool that allowed them all to perform clinical billing tasks using these new rules, gather data in the manner required, and run reporting against the data collected needed to be built from the ground up.
If rolled out correctly, this new standardized model would benefit the organization as a whole, inform leadership with accurate financial reporting, and allow for heirachical transparency into each department and it's subdivision's finances, clarify benchmarks for all healthcare providers, and simplify the workflow for all financial analysts across the board. It was certainly a very ambitious endeavor, being the first attempt at a standard financial system roll-out at every level, from small clinics to large hospitals, and the many administrative groups they required.
Challenges
The primary challenge was allowing for a smooth migration to the new process. Metaphorically speaking, one cannot stop an airplane mid-flight to fix a problem. So a transition plan from the old to new was required to avoid quite a number of possible billing and financial inaccuracies, data corruption, and problems yet unseen. This was made even more complicated by the fact that each medical practice, clinic, hospital, and lab had their own separate finance teams in place, and they all had different processes and workflows.
Prior to this overdue standardization of all things related to clinical billing, each entity within this same organization had been using different workflows, billing processes, supporting software, vendors, home-grown applications, or any combination of the above to manage their individual finances. This included the business of billing for services, calculating the cost of health care, defining the cost of each healthcare provider, and providing accurate reporting of their financial data to analysts up the chain to inform the organization at the highest level. Since their inception, each health care entity had full autonomy in this area, and already had working systems in place to satisfy their existing needs.
Other challenges included the need to preserve and access historical data once this new Clinical Income Model was implemented, and any transition to any new system or process required many unique "workarounds" for almost every healthcare entity.
A predictable push-back from many people within these departments was expected, and would required managing. Especially for those large departments who had invested years in building and refining their own, customized organizational structure, workflows, and time spent learning and training staff on the tools they'd chosen and currently used. Not to mention that in general, most finance departments and their existing processes were already tightly knit to other internal and external departments, including human resources, recruitment, payroll, information services and many third party vendors. And many of these departments were not directly connected, because the same autonomy seen in their finance departments allowed them to build out other redundant departmental systems as well.
The Strategy: Leverage an Existing Data Reporting Solution
As we touched on above, finance was not the only non-centralized group within the organization. In fact, most of the organization's departments and entities ran their business using arguably redundant systems. And in solving this age-old reporting problem for leadership, an organizational-level data warehouse had already been created to address all of these parallel billing, financial and human resource systems. This purpose of this data warehouse was to reconcile all manner of data into a custom SQL Server solution that required a team of DBOs to maintain it. By either manually importing data, working with .NET programmers to connect to vendor APIs, or oversee nightly jobs that would perform any necessary calculations on the data it collected and provide a data structure where the finances of all the disarate entities could be directly queried.
This system was used primarily for reporting purposes, and reporting to leadership was achieved using a number of reports displayed in a legible Tableau format. But having an existing SQL Server that was already compiling much of data we needed to satisfy many new Clinical Income Model business rules was an enormous resource. Be it internal data, vendor data, excel files, or raw input from different healthcare locations, much of the data sought to implement the new Clinical Income schema was in fact already being calculated, mapped, converted, aggregated and organized daily using various SQL Server jobs, home-grown data layer applications, secure vendor APIs and other methods. Meaning much of the data required to support the new clinical billing model and it's effect on the pre-woven entities like payroll, recruiting and other currently "rouge" players was not only available to us, a naming convention was in place that could map to the new system's requirements. Metaphorically, we would not have to defy gravity. We could fix the plane in flight.
So the core strategy was fairly simple: when it came to designing a single product that all entities were required to use, we decided on the "less is more" approach. Any data that we could mine from the organization's existing data warehouse would be taken from there and used for our purposes. Any read only data was identified that could possibly inform the user of the new Clinical Income Tool to act in any way would appear in the tool for reference. All data entry fields that representent anything that was possibly known (based on any calculations from the SQL Server) would appear to the user as pre-populated, allowing them to simply confirm accuracy (or change if need be).
Once we identified all the data we could not attain, or could not calculate ourselves in the background using raw data, we were left with only a handful of inputs that required an end user to work with. While the unseen tiers of the application worked overtime using the data warehouse, the user interface required much less data entry than we ever expected from a change of this scope.
Much of the the UX and general product design centered on user empathy, and used well known, intuitive mobile and web controls. Users could ideally use it with almost no training. Help and tips were cleverly built into the front end in an elegant way, again using intuitive controls such as the unbiquitous information and question icons, to clarify new Clinical Income terminology and processes.
The fact that the data warehouse continued to perform as intended, while this new Clinical Income Model product could be conceived and built alongside it was ideal when it came to testing data integrity.
The User Experience
With the SQL Server database relying heavily on a monthly data import from a separate People Soft human resources solution, the decision was made to focus not on daily input, but on monthly input. A time window was defined in which users could complete any work within a reasonable deadline.
This gave apprehensive users the time they needed to incorporate use of the tool into their own schedules. And it allowed them to "play" with it for a month without any fear of making mistakes that they could not fix themselves. Giving them less options gave them confidence in both the app and their understanding of the new Clinical Income system.
The User Interface
What was originally envisioned as a daunting array of dynamic conditional-driven data entry screens became a single, easily digestible confirmation screen, with only a few input fields to adjust any data if required. Users also had the ability to quickly swipe through read-only historical months, and view input from these historical months. A feature allowing them to transfer historical data to their "working" month when appropriate made particularly quick work of the task at hand.
A full Tableau formatted report was included in the tool to allow users to look at the results of all the new clinical income data in the new standard format. They did not have to spend days entering, or worse, calculating input values themselves by referring to their legacy systems. The report contained all the "unseen" data that was mined and/or recalculated for them, using the new income model terminology, and it allowed them to see running totals that reprersented whether or not provider benchmarks were being met, NET income goals for their division or department were within expected ranges, and the cost of each healthcare provider versus the revenue they brought in was also displayed and could be drilled into for more details. If any data in a given working month seemed off, the user could simply correct whatever data that was either imported mistakenly, mistyped by another analyst or easily see that the data displayed was in fact correct and what exactly factored into the issue.
The Outcome
Users at the organizational level had access to the same tool, and the same detailed report. The difference being their access: department heads could see and modify any data as need be within their own department or subdivisions, while the leadership team could view the same running totals and benchmark data for every department and subdivision in the organization.
It's not often that a "data-first" approach to a software development project results in something elegant or easy to use. But by leveraging what may have been seen as a solution to existing problems reconciling data with other departments and many redundant systems (i.e. the a data warehouse for reporting), we were in fact able to deliver an intuitive application that considered the user's time, as well as affect their mind-set about the change itself.
More importantly, it made adherence to the new clinical income model easy and quick. It made users feel like it was a relatively non-disruptive change to their existing workflow. User adoption fears were put to rest, and the users themselves are now more open to the benefits of this much needed change within the organization.
The Next Iteration
While the initial tool and it's built-in reporting solved the problem of adherance to the new business model, the data itself still comes largely from assorted "rougue" players, outdated processes and legacy systems that are still very much in use. Future stragies for either replacing individual departmental legacy systems with an new features available in the version 1.0 of the the tool - built using the business logic strictly defined in the Clinical Income model, or a separate tool that does the same.
A best case scenario may look a bit like the following: As users adopt the new Clinical Income Model, and begin using the new terminology, new references to old benchmark types, and even the reporting labels, a common vocabulary should permeate the entire organization allowing financial analysts to more easily communicate across departments and entities. Hopefully this will serve to convert the autonomy they enjoyed in the past into a spirit of collaboration, as they are now stakeholders in the exact same system, and while their needs may vary, these details should not prevent them from consolidating efforts and contributing to the the UE of any futre development.