Creating audit dashboards and validation flows for medical exam requests

Operations visibility problem

UNIMED Fortaleza (one of Brazil's largest health cooperatives) needed visibility into medical exam request workflows. Audit teams reviewed thousands of exam authorizations: X-rays, blood tests, MRIs, specialist consultations. Requests came from multiple channels, required validation against policy rules, needed fraud detection, and demanded approval tracking. Scattered data across systems created blind spots: Where are approval bottlenecks? Which exams show unusual patterns? How long until decisions?

Simplifying ops workflows

Consolidated fragmented information into unified operations dashboard. Operators could see pending requests requiring review, flag potential anomalies (unusual exam frequency, uncommon procedures, cost outliers), track approval cycle progression (submitted → under review → approved/denied → notified), and monitor queue aging (requests awaiting attention for 24h+, 48h+, week+).

Reduced manual cross-referencing between systems. Previously: check request details in one system, verify patient history in another, confirm policy coverage in third, document decision in fourth. New interface: consolidated view showing all relevant information in context. Decision quality improved, processing time decreased. The dashboard interface below demonstrates the comprehensive view operators used for exam request management.

Data visualization for auditors

Built analytical views surfacing patterns requiring investigation:

Exam Type Frequency - Which procedures requested most often? Unexpected spikes in certain exam types (possible fraud indicators, coding errors, or legitimate medical trends).

Outlier Detection — Requests significantly above typical cost ranges. Multiple expensive exams for single patient. Providers with unusual approval rates.

Approval Timing Analysis — Average time from submission to decision by exam type. Bottlenecks in approval process. Requests exceeding SLA thresholds.

Provider Patterns — Requesting patterns by medical facility. Facilities with higher denial rates. Unusual authorization requests that need deeper investigation.

Auditors could spot anomalies visually (chart spikes, color-coded alerts) rather than sifting through spreadsheets. Enabled proactive fraud detection and process improvement identification. The analytical interface below demonstrates the visualization tools used to surface patterns and anomalies.

Information architecture for complex data tables

Exam request tables showed: patient identifier, exam type, requesting provider, submission date, current status, assigned reviewer, priority level, cost estimate, and policy coverage. Designed tables with progressive disclosure: essential info visible by default, detailed view expandable. Filterable by multiple criteria simultaneously (status + exam type + date range + provider). Sortable by any column. Bulk actions for common operations (assign reviewer, update status, export subset).

Included empty states explaining what data would appear and what actions users should take. Loading states with estimated wait times. Error states with recovery guidance.

Interaction patterns for operational efficiency

Designed quick actions for common workflows:

One-click approval/denial for straightforward cases meeting clear criteria. Confirmation dialogs with requirement checklists prevented accidental approvals.

Batch operations for similar requests (approve all blood tests for patient, deny duplicative requests, reassign pending reviews to different reviewer).

Request details modal overlaying main view rather than navigating away. Operators maintained workflow context while reviewing specifics.

Status filters with counts showing exactly how many requests in each state. Operators prioritized by urgency and workload distribution. The filtering interface below demonstrates the comprehensive controls available for data management.

Handoff for production parity

Delivered high-fidelity Figma specifications documenting every component state: default, hover, active, disabled, error, loading. Created detailed annotations for complex table interactions: sort behaviors, filter logic, pagination requirements, and empty state conditions. Used Figma Dev Mode to generate precise spacing, typography, and color specifications.

Collaborated directly with engineering during implementation sprints: reviewed coded components against designs, identified discrepancies in table behaviors and filter interactions, validated production matched design especially for complex states (loading spinners, empty states, error messages, bulk action confirmations). Conducted QA testing on staging environment before production deployment.

Design decisions and trade-offs

Density vs. Scannability — Auditors needed information density (many rows visible simultaneously) but also scannability (distinguish important data quickly). Used strategic bold/regular weight, color coding for status, and row highlighting on hover. Tested with actual users to find optimal balance.

Real-time vs. Batch Updates — Real-time data updates provide accuracy but can disorient users when lists reorder mid-work. Implemented refresh indicators showing new data available with manual refresh control. Users decided when to update their view.

Comprehensive Filtering vs. Simplicity - Powerful filters enable precise data queries but complex filter UIs intimidate users. Designed progressive filter disclosure: common filters visible by default, advanced filters tucked behind "More filters" expansion. Saved filter presets for frequent queries.