MedFlow — Decision-Ready Clinical Data System
I designed a system that removes the need for physicians to reconstruct patient context under time pressure.
In most consultations, doctors don’t lack data —
they lack usable, structured context at the moment of decision-making.
Patient information is:
- fragmented across systems
- incomplete or outdated
- dependent on unreliable recall
The result?
Decisions are made with gaps.
What I changed
Instead of optimizing screens, I redesigned how information flows through the system:
- from raw patient input
- to structured, continuously updated context
- to decision-ready summaries for physicians
Outcome (what this enables)
- faster, more focused consultations
- higher completeness of patient data before the visit
- reduced cognitive load for both patients and doctors
- lower risk of missing critical medical information
System in action
This is not a UI problem. This is a decision-making problem.
Below is how the system behaves in real scenarios — from patient input to clinical decision support.
Patient Flow (Mobile)
From unreliable recall → to structured input
👉 Key shift: Patients are no longer responsible for structuring medical information.
Instead:
- the system guides input
- detects missing data
- maintains continuity over time
What’s happening here
- onboarding adapts to patient history
- returning users update only what changed
- data is structured in real-time instead of collected passively
Why this matters
Patients don’t fail to provide information.
The system fails to capture it properly.
This flow:
- removes reliance on memory
- eliminates repeated data collection
- builds a continuously evolving patient profile
See how patient input is structured
Physician Flow (Web)
From fragmented data → to decision-ready context
👉 Key shift: Doctors don’t need more data — they need the right data, instantly.
See how context is delivered during consultation
What’s happening here
- visit context (what changed) is separated from patient context (what persists)
- critical information is prioritized for fast scanning
- no need to reconstruct patient history manuall
Why this matters
Consultations are time-constrained.
This system enables doctors to:
- understand the situation immediately
- focus on decision-making instead of data gathering
- reduce risk caused by missing or overlooked information
System Design Logic
From sessions to continuity
Most healthcare systems treat visits as isolated events.
This system treats patient data as:
👉 a continuously evolving timeline
Core mechanisms
- structured intake before visits
- missing data detection
- incremental updates instead of full re-entry
- persistent patient context across consultations
Result
Every visit builds on previous knowledge —
instead of starting from zero.
Critical Design Decisions
1. Separate input from interpretation
Patients provide raw data.
The system structures it.
Doctors receive meaning.
2. Prioritize change over completeness
Doctors don’t need everything repeated.
They need to know what changed.
3. Design for decision speed
The interface is optimized for:
- scanning
- prioritization
- immediate understanding
Why this project matters
This is not about improving usability.
👉 It’s about reducing decision risk in a high-stakes environment.
My Role & Impact
I owned the problem framing, system logic, and interaction model across patient and physician experiences.
This was not a UI exercise.
It required defining how information flows through the system — from input to decision.
What I was responsible for
- defining the core problem and system-level opportunity
- designing the end-to-end experience across mobile (patient) and web (physician)
- structuring information architecture and data flow logic
- translating clinical needs into clear, executable interaction models
- ensuring consistency between data capture, system interpretation, and decision support
How I approached the problem
I didn’t start from screens.
I started from:
- where decision-making breaks
- what information is missing at that moment
- why existing systems fail to deliver it
From there, I designed:
- a structured intake model that reduces reliance on patient memory
- a system that detects gaps instead of passively collecting data
- a consultation interface optimized for fast understanding and prioritization
Key contributions
1. Reframed the problem from “data collection” to “decision readiness”
Shifted the focus from gathering more information
to delivering usable context at the moment of care.
2. Designed a continuous patient data model
Moved from session-based input to an evolving patient profile
that builds context over time.
3. Reduced cognitive load on both sides of the system
- patients are guided instead of questioned
- physicians receive structured, prioritized information
4. Defined interaction logic, not just UI
Every screen is a result of:
- information hierarchy
- decision needs
- system constraints
—not visual exploration.
Impact
This work demonstrates my ability to:
- operate at the system level, not just interface level
- translate complex domains into clear decision models
- design for real-world constraints, not ideal scenarios
- reduce complexity without oversimplifying critical information
In practice
I design systems where:
- information is structured before it becomes a problem
- decisions are supported, not improvised
- complexity is managed — not pushed onto the user
What this says about how I work
I don’t optimize screens.
I design:
- how systems behave
- how decisions are made
- how complexity is reduced at scale
Explore deeper
If you want to see how this system is structured in detail:
👉 Full problem framing & system architecture
👉 Interactive prototype (patient + physician flows)
© Zofia Szuca 2024
Brand and product designer