One patient, five practitioners, zero shared context — designing an integrative care platform

Concept to high-fidelity prototype · 2019–2020

A platform designed for an integrative health clinic in Vilnius where multiple doctors work together on a single patient's treatment. The clinic opened with a care model that didn't exist in Lithuania — and no software to support it. This project was shelved when COVID hit, but the design work stands as a complete systems-design exercise across a complex, multi-user product.

The context

The clinic practised integrative, root-cause medicine — treating the whole patient across physical, psychological, and lifestyle dimensions rather than isolating symptoms. A patient would go through a comprehensive evaluation, then be assigned coordinated therapies across multiple in-house practitioners: family doctor, psychologist, osteopath, nutritionist, and others. After treatment, the body's own self-regulation mechanisms are given time to work before the patient returns for reassessment. Multiple doctors, one patient, one shared goal.

They ran everything on Google Calendar and Docs.

The research

We interviewed the head of the clinic, doctors, and administrative staff. Two core problems surfaced:

Patients didn't do the work — the treatment model required patients to actively participate — follow diet plans, adjust lifestyle, do prescribed exercises. But patients expected a pill. They wouldn't stick to plans between appointments, then return saying the treatment didn't work. Or worse — they'd forget how bad they felt before, and claim nothing had changed.

Doctors spent time on admin, not patients — appointments were consumed by filling documents, reviewing fragmented records, and re-explaining context to each other. No shared view of the patient existed across practitioners.

What I designed

A platform for both doctors (desktop) and patients (mobile) — where the hard part isn't any single feature, but how everything connects across user types, platforms, and time.

The accountability loop — doctors build therapy plans from reusable templates. Plans push directly to the patient's mobile app as daily tasks — exercise routines, meditation, diet adjustments. Patients complete tasks and report progress. That data feeds back into the doctor's view before the next appointment. The design problem: a workflow that spans two platforms, multiple user types, and weeks of elapsed time between touchpoints.

Same patient, six perspectives — one shared patient record — but family doctor, psychologist, osteopath, nutritionist, admin, and the patient all need to see different things. The information hierarchy shifts completely depending on who's looking. Doctors see clinical data, coordination notes, and what every other practitioner did. The patient sees their tasks, progress, and upcoming appointments. Same data, different architecture.

The treatment cycle as a temporal UI — the clinic's model moves through phases: evaluation → therapy → self-regulation → reassessment. Each phase changes what the UI shows, what actions are available, and what data matters. Outcome tracking — health scores broken down by category — closes the loop by measuring whether the diagnosis actually improved.

AI-assisted consultations — video calls modelled on Babylon Health's approach: the system catches medicine names and diagnoses from the conversation and surfaces them in structured summaries, so the doctor focuses on the patient, not on documentation.

The platform also covered the basics — telemedicine, scheduling across all practitioners, intake forms, calendar management, and team messaging — but the design challenge was in the connective tissue between all of it.

Why this project matters

This product was designed but never launched — COVID closed the window. I'm showing it for the systems design, not the outcome.

It demonstrates: complex multi-user workflows (patients, multiple doctor types, admin), sensitive data context (health records, treatment plans), cross-platform design (mobile + desktop as interconnected experiences), and the kind of information architecture that B2B and platform companies care about — where multiple user types need to see the same data differently.