Designing MedJourney: How to Build a Patient Support Program Ecosystem from Zero

Most of our case studies start with a product that exists — something broken, something aging, something that needs to be rethought.

MedJourney started with nothing.

No product. No screens. No wireframes. No design system. No name. No logo. No brand.

The client came to us with an RFP and a problem. The problem was real, complex, and genuinely important: pharmaceutical companies lose visibility into patients after medication is purchased. Patients start treatments, miss follow-ups, skip diagnostics, and quietly discontinue therapy — and nobody in the healthcare chain knows until it's too late.

Patient Support Programs (PSPs) exist to solve this. They're structured programs designed to keep patients engaged with treatment plans through follow-ups, reminders, diagnostic tracking, and therapy monitoring.

But most PSPs run on spreadsheets, disconnected CRMs, and manual telecaller workflows. The data is fragmented. The visibility is poor. The outcomes are unmeasured.

The client wanted a platform that could change that.

Not a patient database. Not a call center tool. Not a hospital management system.

A connected healthcare ecosystem that followed patients through their entire treatment journey — from diagnosis to purchase to follow-up to outcome — and gave every stakeholder in the chain the visibility they needed.

We were responsible for everything: naming it, branding it, designing it, and building it.

"The client didn't come with a product to fix. They came with a problem to solve. The product had to be invented."

Naming a healthcare platform

Before designing a single screen, we needed to answer a fundamental question: what is this product called?

This mattered more than it might seem. The name would shape how users, pharma companies, and healthcare organizations perceived the platform. It needed to communicate what the product was without sounding like another hospital administration tool.

We kept coming back to one idea: the patient journey.

Every feature in the platform — follow-ups, diagnostics, adherence tracking, program management — existed to support a continuous progression. Not isolated transactions. Not one-time events. A journey.

MedJourney.

The name captured the philosophy:

• Med — grounded in healthcare, clinical, trustworthy

• Journey — continuous, progressive, patient-centered

It positioned the platform away from the transactional language of healthcare IT ("management system," "admin portal," "operations dashboard") and toward something that felt human.

The name also worked as a design constraint — a constant reminder that every feature should answer the question: "Does this help us understand where the patient is in their journey?"

Building the brand from zero

The logo and visual identity were created alongside the product design — not before it, not after it.

This is unusual. Most branding projects happen in isolation and then get "applied" to a product. We built both simultaneously, which meant the brand identity was shaped by the same understanding of healthcare workflows, compliance constraints, and multi-stakeholder complexity that shaped the product itself.

The brand needed to feel:

• Trustworthy — healthcare demands credibility

• Modern — distinguishing it from legacy health IT systems

• Approachable — this wasn't just for doctors; telecallers, pharmacists, and program managers would use it daily

• Scalable — the identity had to work across enterprise presentations, mobile dashboards, and compliance documentation

The problem underneath the problem

The client's stated objective was clear: improve patient adherence through better follow-up management.

But the real challenge — the one we discovered during research — was far more structural.

The healthcare ecosystem is fragmented by design. Every stakeholder sees only their slice:

• Pharma companies see prescriptions and sales data

• Telecallers see call lists and follow-up schedules

• Hospitals see admissions and procedures

• Labs see diagnostic orders and test results

• Doctors see individual patient records

• Pharmacists see dispensing data

• Program managers see participation metrics

Nobody sees the whole picture.

A patient who purchases medication, misses a follow-up call, skips a diagnostic test, and quietly stops treatment creates no alarm in any single system. Each stakeholder sees silence — not a pattern.

MedJourney's job was to connect those slices into a single, continuous view of the patient journey. Not by replacing existing systems — hospitals and labs would keep their tools — but by creating a shared operational layer that gave every stakeholder contextual visibility into the parts of the journey that affected their work.

"Every stakeholder in the chain saw their slice clearly. Nobody saw the patient. MedJourney was designed to show the whole picture."

Nine products pretending to be one

This is where the project became genuinely difficult.

MedJourney wasn't one application. It was effectively nine different products sharing one system.

The platform supported:

Each role needed:

• A different dashboard

• Different data visibility

• Different actions

• Different workflows

• Different permissions

And each role needed to feel like the platform was built specifically for them — not like they were using someone else's tool with a few features hidden.

The RBAC challenge nobody talks about

Role-Based Access Control sounds like a technical feature. In practice, it's a design problem.

MedJourney's permission system included:

• 9 default roles

• 111 granular permissions

• 26 permission groups

The technical implementation is straightforward — check a user's role, show or hide features accordingly. The design challenge is far harder:

How do you make a platform with 111 permissions feel simple?

If each role sees a reduced version of the full platform — features removed, sections hidden, options disabled — it feels like a restricted product. Users sense they're missing things. The experience feels incomplete, like a trial version.

Our approach was different. Instead of removing features from a full product, we designed complete experiences for each role. The telecaller's dashboard wasn't the admin dashboard with things hidden. It was a dashboard designed for telecallers — with their metrics, their workflows, their actions, their priorities.

Same codebase. Same platform. Nine different products.

"111 permissions. 9 roles. One platform. The challenge wasn't access control — it was making every role feel like the product was built just for them."

The patient timeline: the feature that held everything together

If MedJourney had a single defining UX innovation, it was the patient timeline.

Healthcare data is naturally fragmented across time:

• January: Patient purchases medication

• February: Telecaller completes first follow-up call

• March: Patient misses a diagnostic appointment

• April: Doctor recommends therapy adjustment

• May: Patient purchases refill

• June: Second follow-up call — patient reports side effects

• July: Lab test completed

In the original workflow — spreadsheets, CRMs, disconnected systems — piecing together this history required checking multiple sources, cross-referencing dates, and building a mental picture from fragments.

The patient timeline consolidated everything into a single, chronological view:

• Calls

• Reminders

• Purchases

• Doctor interactions

• Therapy milestones

• Diagnostic results

• Program enrollment

• Adherence status changes

One screen. One scroll. The entire patient journey, visible.

This wasn't just a convenience feature. It was the operational difference between reactive and proactive healthcare support.

A telecaller looking at a patient timeline could immediately see: medication purchased three months ago, one follow-up completed, two missed, no diagnostic tests done. They didn't need to check multiple systems. They didn't need to ask the patient to repeat their history. They could have an informed conversation — and identify adherence risks — in seconds.

"The timeline didn't just show patient history. It showed patient momentum — whether someone was progressing through treatment or quietly falling away."

Designing for telecallers

Telecallers were the operational heart of the platform. They were the people on the phones, talking to patients, completing follow-ups, logging outcomes, and — most importantly — keeping patients engaged with their treatment plans.

Their experience needed to be optimized for one thing: throughput without sacrificing quality.

A telecaller might handle dozens of calls per day. Each call required:

1. Understanding the patient's current status

2. Knowing what to discuss (medication adherence, upcoming diagnostics, side effects)

3. Logging the call outcome

4. Scheduling the next follow-up

5. Moving to the next patient

If any of these steps required navigating away from the call screen, opening another module, or searching for information — multiply that friction by fifty calls a day and you have an operational nightmare.

We designed the telecaller experience as a focused workspace:

• Patient context visible before the call starts

• Call logging embedded in the conversation view

• Outcome capture as a one-step action

• Next follow-up scheduling integrated into call completion

• Automatic advancement to the next patient

The telecaller never left their workspace. Everything they needed — patient history, medication details, previous call notes, adherence status — was within the call context.

Follow-up tracking: the feature that defined success

Patient adherence — the entire reason MedJourney existed — depended on follow-ups happening consistently and on time.

A missed follow-up isn't just a missed call. It's a signal that a patient might be disengaging from treatment. If enough follow-ups are missed, the Patient Support Program fails — not because the medicine doesn't work, but because the support system lost contact.

Follow-up tracking became one of the most carefully designed workflows in the platform:

• Upcoming calls — clearly prioritized by urgency and patient risk

• Completed calls — with outcomes logged and next steps documented

• Missed follow-ups — flagged and escalated, not just recorded

• Reminders — automated but configurable

• Outcome tracking — did the call actually help? Did the patient recommit? Did they express concerns?

The design decision that mattered most: missed follow-ups were treated as alerts, not data.

In the original workflow, a missed call was a row in a spreadsheet. In MedJourney, a missed call was a visual escalation — something that demanded attention, appeared in dashboards, and triggered operational awareness.

Because in healthcare, silence isn't neutral. Silence is a risk signal.

Inventory as therapy continuity

Most people would look at an inventory module and see logistics. Stock levels. Suppliers. Batches. Reorder points.

In MedJourney, inventory was directly connected to patient outcomes.

Here's why: Patient Support Programs only succeed when medicines remain available throughout the treatment lifecycle. If a patient is enrolled in an adherence program but their medication is out of stock at the local pharmacy, the program fails — not because of telecaller quality or patient engagement, but because of supply.

We designed inventory management around healthcare program continuity, not warehouse operations:

• Medicine catalogue — organized by therapy program, not just product category

• Batch management — with expiry tracking that flagged batches approaching end-of-life

• Low stock alerts — connected to active patient counts, not just reorder thresholds

• Expiring medicine warnings — proactive alerts before stock becomes unusable

• Daily stock movements — visibility into distribution patterns that might signal supply issues

The inventory dashboard gave managers immediate visibility into:

• Total medicines available

• Active supplier count

• Batch health

• Inventory value

• Expired and expiring stock

• Low stock warnings

This wasn't inventory management. This was treatment continuity management — making sure the physical supply chain supported the patient journey the rest of the platform was tracking.

"Inventory in a healthcare platform isn't about stock levels. It's about whether patients can continue their treatment tomorrow."

Unifying medicine orders and lab tests

One of the more interesting discoveries during product planning: orders existed in two completely different healthcare contexts that nobody was connecting.

Medicine orders — patients purchasing medications through the healthcare ecosystem.

Lab test orders — patients booking and completing diagnostic tests through participating laboratories.

Traditional healthcare systems treat these as entirely separate workflows. Different modules. Different teams. Different tracking.

But from the patient journey perspective, they're deeply related. A patient who purchases medication but skips their follow-up blood work isn't fully adherent — even though the pharmacy sees a completed transaction.

We brought both order types under a single Orders experience:

• Unified order tracking with clear type differentiation

• Patient-linked orders showing the connection between medication and diagnostics

• Status tracking across both order types

• Timeline integration — orders appearing in the patient journey alongside calls, reminders, and milestones

The result was a more complete picture of adherence. Not just "are they taking their medicine?" but "are they completing the full treatment protocol?"

The compliance layer you don't see

Healthcare introduces design constraints that most SaaS products never encounter.

MedJourney handled patient data — real medical information, personal health records, treatment histories, diagnostic results. This wasn't a CRM with customer names and email addresses. This was Protected Health Information.

The platform needed to comply with:

• HIPAA — U.S. healthcare data protection standards

• GDPR — European data privacy regulations

• PII restrictions — personally identifiable information handling

• Consent management — documented patient authorization for data collection and contact

• Activity tracking — auditability of every data access and modification

• Data encryption — at rest and in transit

These weren't features we could add later. They were design requirements that shaped every decision from the beginning.

How compliance shaped the design

Consent management wasn't a checkbox in settings. It was a workflow — visible during patient onboarding, documented in the patient timeline, and referenced before every telecaller interaction. "Does this patient have active consent for contact?" wasn't a question telecallers should have to ask themselves. The system answered it before they picked up the phone.

Activity tracking meant every screen needed to be designed with auditability in mind. Who accessed this patient record? When? What did they change? This influenced how we structured data displays, edit flows, and access logs.

Permission granularity — those 111 permissions — wasn't over-engineering. It was compliance architecture. In healthcare, "who can see what" isn't a preference. It's a legal requirement.

The compliance layer was invisible to most users. They never saw HIPAA requirements or encryption settings. But every interaction they had was shaped by regulations working quietly underneath.

"In most SaaS products, compliance is a section in settings. In healthcare, compliance is the foundation everything else is built on."

Programs as first-class citizens

Patient Support Programs were the entire reason MedJourney existed. But in most healthcare tools, programs are afterthoughts — metadata tags applied to patients, not operational entities in their own right.

We designed programs as first-class objects in the platform:

• Programs could be created, configured, and managed independently

• Patients were enrolled in programs, not just tagged

• Program managers had dedicated dashboards showing participation, completion rates, and outcomes

• Performance metrics were measured per-program, enabling comparison and optimization

• Programs had lifecycles — active, paused, completed — with different operational behaviors in each state

This elevated PSPs from administrative categories to operational ecosystems. A program wasn't a label. It was a living entity with patients, telecallers, follow-ups, medicines, diagnostics, and outcomes flowing through it.

Doctor, hospital, and lab management

The platform didn't just track patients. It tracked the entire network supporting them.

Doctor management connected physicians to programs, patients, and outcomes:

• Specialist profiles with expertise and affiliations

• Patient assignment tracking

• Participation metrics showing engagement with support programs

• Referral pathways visible within the patient journey

Hospital management linked facilities to the broader ecosystem:

• Hospital-program connections

• Doctor affiliations

• Patient flow tracking

• Outcome correlation

Lab management brought diagnostics into the operational picture:

• Lab capabilities and test menus

• Diagnostic order tracking

• Testing volume and turnaround metrics

• Patient participation in recommended diagnostics

None of these modules existed in isolation. Each one fed data into the patient timeline, contributed to program metrics, and informed telecaller conversations.

The platform wasn't a collection of management tools. It was a network — and every node in that network connected back to the patient journey.

The dashboard philosophy

MedJourney had multiple dashboards — each tailored to a specific role — but they all shared one design philosophy:

Show signals, not data.

Healthcare operations generate enormous volumes of data. Call counts, patient numbers, adherence percentages, follow-up completion rates, revenue figures, program metrics. The temptation is to display everything.

We resisted that.

Each dashboard was designed around the questions that specific role asks at the start of their day:

Organization Admin: "How are our programs performing? Where are we losing patients?"

Telecaller Manager: "Which telecallers are behind? Which patients are at risk?"

Inventory Manager: "What's running low? What's expiring?"

Program Manager: "How is enrollment trending? What's our completion rate?"

The metrics shown weren't comprehensive. They were actionable. Each number on the dashboard connected to a workflow — something the user could do about it, not just observe.

The design system for healthcare

MedJourney's design system was built for an environment where people spend hours looking at screens — and where misreading a data point could affect patient care.

Color with purpose

Primary Blue (#3A8DFF) Trust, reliability, clarity. The backbone of the interface. Used for primary actions, navigation, and data emphasis. Blue is the default language of healthcare software — and for good reason. It communicates clinical confidence without emotional weight.

Secondary Teal (#3CB4A6) Warmth, care, patient-centricity. Used to distinguish patient-facing elements, success states, and wellness indicators. The teal balanced enterprise functionality with the human dimension of healthcare.

The combination — blue for operations, teal for patients — created a subtle but consistent visual language. Users never thought about it consciously, but their eyes learned that blue meant "system" and teal meant "person."

Typography: Open Sans

Chosen for one reason above all others: speed of reading.

Healthcare dashboards contain dense information. Telecallers scanning patient records between calls need to absorb data in seconds. Inventory managers checking stock levels need numbers that pop. Program managers reviewing metrics need clean, unambiguous text.

Open Sans provided readability at every size, in every density, across every module. No flourishes. No personality. Just clarity.

Icons: Phosphor Icons

Consistent, scalable, and immediately legible. In a platform with this many modules and actions, every icon needed to be recognizable at a glance — in navigation, in tables, in dashboards, and in inline actions.

Components built for healthcare operations

Patient cards — compact summaries showing name, program, adherence status, last interaction, and next action. Designed for telecaller lists and search results.

Timeline entries — consistent event components used across the patient timeline. Each type (call, purchase, diagnostic, milestone) had a distinct visual treatment while sharing the same structural format.

Status chips — a unified language for status across every entity. Active, pending, missed, completed, expired, at-risk. Color-coded, icon-supported, and consistent everywhere.

Data tables — sortable, filterable, bulk-actionable. Designed for high-density operational contexts where users manage hundreds of records daily.

Dashboard cards — metric containers with clear hierarchy: number, label, trend indicator, action link. Each card was a miniature decision tool.

Form components — optimized for data entry speed. Tab ordering, inline validation, smart defaults, and clear error states.

Designing and building simultaneously

MedJourney wasn't a design project that ended with a handoff.

We designed the platform and built the frontend — in Angular — as a single, continuous process.

This changed everything about how we worked:

Design decisions were tested in code, not just prototypes. When we designed the patient timeline, we built it. When the scroll performance with 200+ entries was poor, we redesigned the rendering approach. That feedback loop — design, build, discover, adjust — happened in days, not weeks.

Edge cases surfaced during development, not after launch. What happens when a patient has no follow-up history? What does the telecaller dashboard look like with zero assigned patients? What happens when an inventory batch expires during a stock count? These questions were answered by the same team that designed the interactions.

The design system was born from real components. Every element in the design system existed as both a Figma component and an Angular component. Consistency wasn't aspirational — it was enforced by shared code.

"Building what we designed forced a kind of honesty that handoff-based projects rarely achieve. You can't hide complexity in a mockup when you're the one writing the code."

What was harder than we expected

Healthcare regulations shaped more decisions than user research.

In most projects, user research drives design direction. In MedJourney, compliance requirements had equal — sometimes greater — influence. We couldn't design the ideal telecaller workflow and then add consent checks later. Consent was the first thing the workflow had to address. Regulations didn't constrain the design. They were the design requirements.

Nine roles meant nine first impressions.

Every role had a different entry point, a different dashboard, a different set of priorities. Designing one great first impression is hard. Designing nine — each coherent, each useful, each feeling purpose-built — was an ongoing calibration exercise throughout the project.

The patient timeline almost became unusable.

Our first version of the patient timeline displayed every event with equal visual weight. For a patient with a year of history — dozens of calls, purchases, diagnostics, reminders — the timeline became an unreadable wall of entries. We redesigned it with visual hierarchy: major events (medication changes, missed follow-ups, therapy milestones) received full treatment, while routine events (completed calls, automated reminders) were visually compressed. The timeline needed to show everything without treating everything as equally important.

Inventory management seemed boring until it wasn't.

We underestimated the inventory module initially. Stock levels and batch tracking felt like commodity features. Then we understood: if a patient's medication is unavailable, the entire support program fails. Inventory wasn't logistics — it was the physical infrastructure that made everything else possible. That realization elevated the module from "standard CRUD" to one of the most carefully designed areas of the platform.

Naming things in healthcare is a minefield.

Every term we used had to be precise. "Patient" vs. "customer." "Follow-up" vs. "check-in." "Adherence" vs. "compliance." Healthcare terminology carries clinical, regulatory, and cultural weight. A word that sounds natural in tech — "user," "engagement," "conversion" — can feel inappropriate in a healthcare context. We spent more time on nomenclature than we expected, and it mattered.

Reflection

MedJourney was our first major healthcare platform. It was also one of the most rewarding projects we've worked on — not because the design was flashy, but because the problem was genuine.

Patients discontinuing treatment isn't an abstract business metric. It's a health outcome. Building a platform that helps keep people on their medication, connected to their healthcare providers, and progressing through their treatment — that felt meaningful in a way that most SaaS projects don't.

A few things this project taught us:

Building from zero is freedom and terror in equal measure.

No legacy constraints. No existing patterns. No "we've always done it this way." But also: no guardrails. No validation. No existing user behavior to learn from. Every decision was a bet. The freedom to invent was exhilarating. The responsibility of having no precedent was sobering.

The patient journey is the product strategy.

The name wasn't just branding. It was a design principle. Every time we debated a feature, a layout, a workflow — we asked: "Does this help us see the patient's journey more clearly?" Features that didn't connect back to the journey were questioned. Features that illuminated the journey were prioritized. The metaphor drove the architecture.

Healthcare design is compliance-first design.

You cannot design healthcare software and add compliance later. HIPAA, GDPR, consent management, auditability — these aren't layers applied on top. They're the soil everything else grows from. Understanding regulations before understanding users wasn't backwards. It was necessary.

Making nine products feel like one is the hardest kind of design.

Any team can build nine separate dashboards. Making nine different role-based experiences feel like they belong to the same product — sharing visual language, interaction patterns, and design philosophy while serving completely different operational needs — is a design challenge that doesn't get enough respect.

The best healthcare design is invisible.

Nobody using MedJourney should think about the design. Telecallers should think about patients. Inventory managers should think about stock. Program managers should think about outcomes. The design succeeds when it disappears — when the platform feels like a natural extension of the work people already do, not a system they have to learn.

What MedJourney became

MedJourney became a connected healthcare operating system — a single platform where pharmaceutical companies, telecallers, hospitals, labs, pharmacists, inventory teams, and program managers could all see the parts of the patient journey that mattered to their work.

Not a call center tool.

Not a patient database.

Not a pharmacy system.

An ecosystem.

Built from a problem. Named around a philosophy. Designed for nine different users. Developed into production. Compliant with healthcare regulations we'd never worked with before.

A product that started as an RFP and ended as something that helps patients stay on their medication.