Goal
Help back-end devs understand how to organize the data they were warehousing in a way that allowed the system to report on the measures our customers (doctors) needed to report to the government and represent this data in our reporting module.
My Role
Lead UX Strategist and General Pain in the Next to Guys who Don’t Love Talking about Data as Much as I Do
Overview
We set out to create dashboards that combined data from medical providers' Electronic Health Record systems and Practice Management systems. Often, these data set were created and managed by different user type and then had to be analyzed by yet another user or even supervising agency.
These dashboards would measure and recorded how well the providers and individual doctors met specific Standard of Care measurements. When thresholds were reached, their visit pay rates increased.
The dashboards needed to displayed real-time data, progress visuals, and allowed providers to print performance reports.
As the leader of the project (in lieu of a data analytics reporting team!) I guided the understanding of the required data and how it was stored in our application’s database. I helped the developers of the back-end functionality understand what the tables were to users, and the business logic for querying and calculating the data sets that powered the dashboards.
I also helped Product, Development, and customer-facing User Guide writers understand the workings of the reports and reporting data as we shaped it.
Given the customization of many data capture UI fields by users, I assisted in enhancing the system to map user input to the required reporting data.
Goal: "Teach" the System to Build
This is a summary I wrote of the requirements laid out by the American Diabetes Association to help our developers understand the data points we would need and the various calculation variables possible.
*The wording I chose, like “Test” and diagnosis names were the words used in both the data capture field in our UI and corresponding database fields when they were standard to the application.
Check out the full manual for this type of measure (available at Diabetes.org) that I was consuming. It was a beautiful beast!
Use Cases
These were the users scenarios I wrote-up for the project management team to help the product team understand how the product could (should) behave to serve these dashboards and reports to the user. These were to help facilitate design workshops and to nail down the ultimate product requirements.
Data Journey Map
Task 1 Flow
Wireframe of Dashboard UI
* My delivery was a content flow and report creation logic rather than UI design as the product already had a basic report UI template.
Population Health Representation 1