Turning complex federal healthcare requirements into usable enterprise workflows.
Federal healthcare reporting systems often begin with regulations, policy language, deadlines, data requirements, and multiple stakeholder groups rather than a neatly defined product brief. At Evolver Federal, supporting CMS.gov / HIOS, my role was to translate those complex requirements into understandable, accessible workflows that insurers, employers, healthcare administrators, and federal stakeholders could actually use.
Role
Senior UX & UI Designer
Client
Evolver Federal · CMS.gov / HIOS
Contribution
Reporting Dashboard — Program Overview
A federal program team's view of submission activity, operational status, and reporting progress across the platform.
Federal healthcare initiatives can begin with legislation, regulatory interpretation, compliance deadlines, reporting requirements, data definitions, and operational constraints. Those inputs are necessary, but they are not yet a usable experience.
The design challenge was to translate that complexity into workflows people could understand and complete accurately.
Policy defines the requirement. Product design defines how people experience it.
In regulated federal work, several things can be true at once:
What We Know
The regulatory requirement, its reporting deadline, and the audience required to submit.
What We Assume
How a specific edge case should be handled, or which validation rule applies, until confirmed.
What Is Still Open
How a policy question will ultimately be interpreted, or which team owns a specific exception path.
Rather than waiting for perfect requirements, I created enough structure to let stakeholders react to something concrete. That helped expose missing decisions earlier and reduced the risk of discovering major workflow problems only after development.
Ambiguity isn’t a reason to stop designing. It’s a reason to make the questions visible.
Federal / CMS Program Stakeholders
Regulatory intent, completeness, reporting accuracy, and deadlines.
Submitting Organizations
Insurers, employers, and healthcare administrators who needed to know what to provide, what came next, what was missing, and whether a submission was complete.
Developers
Implementable workflows, validation rules, states, and dependencies.
Accessibility Stakeholders
Whether the experience could be used equitably, regardless of ability or assistive technology.
One regulatory process. Multiple mental models.
The design challenge was not to force all four modules into identical flows. Instead, the goal was to identify what could be shared — navigation, page structure, status, validation, submission patterns, accessibility, feedback — while allowing module-specific requirements to remain specific.
RxDC
Prescription Drug Data Collection
Complex healthcare reporting workflows for submitting organizations and CMS administrators reviewing and managing submitted information.
GCPCA
Gag Clause Prohibition Compliance Attestation
Two distinct sides of the workflow: organizations submitting attestations and CMS administrators reviewing and managing those submissions.
AADC
Air Ambulance Data Collection
First-time submitters, returning organizations, and dashboard states that help users understand progress, status, and next actions.
CRAB
Agent & Broker Compensation Reporting (Section 202)
Detailed submissions from reporting organizations and CMS reviewers managing multi-issuer, exception, and review workflows.
Consistency where it helps. Specialization where it matters.
A policy statement might imply several user decisions, required fields, validation rules, error states, dependencies, or submission states. The design responsibility was to convert those invisible rules into an experience users could navigate without needing to think like policy analysts.
Regulation
The policy text or statutory requirement.
Business Rule
What the regulation implies an organization must do, and by when.
User Task
The specific action a person needs to complete to satisfy the rule.
System State
Where a submission or record stands at any given point.
Interface
What the user actually sees, decides, and enters.
Submission
The completed, validated record CMS receives.
Where the Translation Lands: GCPCA Submitter Experience
The organization-facing side of the Gag Clause Prohibition Compliance Attestation workflow.
Enterprise UX Concerns
The key principle was to reduce cognitive load without oversimplifying the regulatory work itself.
Data Completeness
vs.
User Clarity
Federal reporting requirements do not shrink to fit a simpler interface. The underlying data and validation requirements had to remain intact.
Resolution
Present the right amount of information at the moment it is needed, while preserving the underlying reporting requirements.
Reporting Dashboard — Enhanced Reporting View
Program activity, status, and submission progress made legible at a glance.
Federal digital products required accessibility to influence the design specifications themselves, across:
Design Specification
Accessibility was part of the specification, not audited after.
Prototypes, workflows, and design specifications became shared artifacts for resolving uncertainty with federal analysts, product managers, developers, and business stakeholders. Design was not a downstream handoff function. It helped the broader team:
What Design Collaboration Enabled
The prototype wasn’t just a design deliverable. It was a decision-making tool.
CRAB Administrator and Reviewer Experience
Multi-issuer, exception, and review workflows for CMS reviewers managing Section 202 compensation reporting.
Regulatory Completeness
vs.
Usability
Every required field and validation rule reflected an actual reporting obligation. None of it could simply be dropped for the sake of a simpler screen.
Resolution
Preserve required information and validation while organizing the experience around understandable tasks and decisions.
Consistency
vs.
Module-Specific Requirements
RxDC, GCPCA, AADC, and CRAB shared a submitter/administrator structure, but each program had its own data, timelines, and review logic.
Resolution
Reuse platform patterns where they genuinely reduced cognitive load without forcing unrelated reporting programs into identical workflows.
Speed
vs.
Incomplete Requirements
Waiting for fully resolved requirements before designing anything would have stalled every program against a fixed regulatory deadline.
Resolution
Move forward with explicit assumptions and prototypes, then refine as regulatory and business decisions became clearer.
Guidance
vs.
Information Overload
Submitters needed to understand complex reporting rules without being handed the full regulatory text at every step.
Resolution
Provide contextual instructions and feedback where users need them instead of exposing every rule at once.
Accessibility
vs.
Delivery Pressure
Federal deadlines do not move. Accessibility gaps found late are the most expensive kind to fix.
Resolution
Treat accessibility as a product requirement from the start so it does not become expensive rework late in development.
Identify Known Requirements
Establish what the regulation and stakeholders have already confirmed.
Document Assumptions
State explicitly what is being treated as true until proven otherwise.
Identify Unresolved Questions
Name what is genuinely still undecided, rather than guessing silently.
Build a Workflow / Prototype
Give stakeholders something concrete enough to react to.
Review With Stakeholders
Surface disagreement and missing decisions while they are still cheap to resolve.
Update the Model
Fold confirmed answers back into the workflow.
Revalidate With Engineering
Confirm the updated model is still implementable.
Continue Iterating
Repeat as remaining questions resolve.
Progress did not require pretending uncertainty didn’t exist.
I remained involved through stakeholder review, design iteration, developer collaboration, usability review, and accessibility review as programs moved toward engineering delivery.
Requirement
A regulatory or business requirement enters the process.
Workflow
The requirement is structured into a sequence of user tasks and system states.
Prototype
The workflow becomes something stakeholders and engineering can react to directly.
Alignment
Federal, product, and engineering stakeholders confirm the workflow reflects the actual requirement.
Implementation
The aligned design moves into development.
Review
The built experience is checked against the original requirement and against usability and accessibility expectations.
Refinement
Gaps found in review are resolved without losing the original intent.
I did not own federal policy or regulatory interpretation. My responsibility was to understand those inputs deeply enough to turn them into coherent user experiences and help the broader team identify where additional decisions were still required.
This distinction is important.
The project resulted in enterprise reporting experiences supporting major federal healthcare compliance initiatives: RxDC, GCPCA, AADC, and CRAB each required submitters to complete legally mandatory reporting with confidence, and CMS teams to review it clearly.
The design work was the same across all four programs: reduce ambiguity, scope each role to what it needed, and make compliance achievable.
The best enterprise UX doesn’t remove complexity that has to exist. It puts that complexity in the right place.
The project reinforced that ambiguity, regulation, and accessibility are not obstacles to design. They are constraints that make clear product thinking more important.
An enterprise white-label, multi-tenant pharmacy platform. One system, three applications, one designer.
Another enterprise healthcare system built around multi-role workflows and WCAG 2.1 AA accessibility, this one for pharmacy operations rather than federal compliance reporting.