Case study · Consolidate Health
Consolidate Health
Making fragmented healthcare data operationally accessible.
Try it · clickable prototype
Healthcare systems often force users to navigate disconnected records, inconsistent terminology, and operational friction just to access essential information. I worked on improving how healthcare data was surfaced, structured, and accessed — reducing friction while preserving clarity and trust.
The opening: healthcare's fragmentation problem
Healthcare data lives in silos. Records scatter across providers, labs, pharmacies, and insurance systems. Terminology differs between systems. Format changes. Timestamps disagree. For patients and practitioners navigating this landscape, the friction isn't just inconvenient — it's a clinical risk.
The core challenge: how do you surface data that's inherently fragmented in a way that's trustworthy, clear, and actionable? How do you make something coherent when the source material is deliberately compartmentalized?
Designing for trust, not just usability
Trade-off #1 — Density vs. comprehension
Healthcare data is inherently dense. A patient record contains labs, diagnoses, medications, allergies, procedures, and scan results — all clinically important, all of which users need access to, none of which can safely be hidden.
The challenge: avoid overwhelming users without hiding information that matters. The solution lived in:
- Hierarchy. Not all data is equally urgent. Recent labs matter more than historical trends (though trends matter when they matter). Primary diagnoses take precedence over secondary flags. Priority is determined by clinical recency and relevance.
- Grouping. Rather than a flat list, data is organized by system: cardiovascular, endocrine, lab results, medications. This mirrors how clinicians think about health and reduces cognitive load.
- Contextual visibility. Related data appears together — a medication with its indication, a lab result with reference ranges and the patient's previous values for comparison.
- Progressive disclosure. The default view shows what's most critical. Expanding sections reveals detail without forcing it upfront. Trend data, historical context, and edge cases are there when needed, not interrupting the primary view.
Constraint #2 — Cross-system inconsistency
Healthcare data rarely arrives cleanly. The real work happened in handling the mess:
- Inconsistent structures. Different providers format the same data differently. Lab results come as PDFs from some systems, as structured HL7 messages from others, as web-scraped text from legacy systems. The design had to normalize this without losing information.
- Incomplete information. A medication record might have dosage but no indication. A lab result might have the value but no reference range. Rather than demand perfection upstream, the interface gracefully handles incomplete data — showing what's known, clearly indicating what's missing, and explaining why.
- Terminology alignment. Healthcare uses multiple naming conventions for the same thing. A "urinalysis" is sometimes a "UA," sometimes a "urine test," sometimes something else entirely. The design layer normalizes this into a consistent, patient-friendly vocabulary while preserving the source terminology where clinicians need it.
- Edge cases. Conflicting information. Duplicate records. Data that doesn't fit neatly into categories. The system handles these transparently, flagging inconsistencies for the user rather than silently choosing one version and discarding the rest.
My direct contribution
I owned
- Information architecture for healthcare records (organizing complexity without oversimplifying)
- Workflow simplification (making retrieval and review intuitive despite data density)
- UX strategy for complex data accessibility (progressive disclosure, contextual grouping, comprehensibility)
- Cross-functional collaboration across product and engineering (translating clinical needs into technical requirements and design patterns)
- User-flow optimization around retrieval and readability (making it fast to find what matters, easy to understand what you found)
Team contributions
- Healthcare system integrations (API contracts with multiple EHRs, HL7 parsing, data normalization)
- Compliance and security (HIPAA, encryption, audit logging, access controls)
- Backend infrastructure (data federation, caching, real-time sync)
- Clinical validation with advisors on real workflows and terminology
Outcomes & deployment
The product shipped within a controlled, highly sensitive environment — real patient data from the start, demanding rigor around privacy, security, and accuracy. That constraint shaped every decision; there was no room for "we'll fix UX later."
Early results in the deployed environment:
- Faster information retrieval. Users found what they needed significantly faster than navigating source systems individually.
- Reduced operational friction. The normalized interface meant fewer manual lookups, fewer "where is this value" moments, less back-and-forth between systems.
- Improved accessibility of critical healthcare data. Information that was scattered across systems was now coherent and findable — reducing the barrier to safe, informed decision-making.
- Increased user confidence and usability. Transparent handling of incomplete or inconsistent data built trust. Users understood what they were seeing and why, rather than wondering about hidden complexity.
Reflection
Healthcare data is inherently scattered — that's a feature of the system, not a bug to be eliminated. The design work wasn't about forcing coherence where it doesn't exist. It was about making scattered data navigable, building trust through transparency, and designing interfaces that respect both the complexity and the stakes of healthcare information.
The validation work — founder expertise supplemented by surveys to test assumptions — proved invaluable. In regulated domains, assumption-driven design is risky. Talking to actual users, even in a small, controlled group, shaped every detail of how data was surfaced and organized.