Building a patient portal that unlocks clinical data

Engineering a secure, multi‑language portal connecting FutureLife patients to their care across ten countries.

Client

Bean

Services

Custom web application development, EMR integration & API design, Payment processing, Managed agile delivery

Industries

Healthcare, Patient engagement, Reproductive medicine, Medical technology

Overview

With over 60 clinics operating across 16 European countries, FutureLife is a leading pan-European fertility provider – yet patients had almost no digital access to their own clinical data.

Before Bean, patients depended on clinic staff for basic tasks such as checking appointments, accessing invoices, or reviewing treatment information. The EMR (eBase) contained everything, but it was locked behind internal systems and processes. This created friction for patients, constant interruptions for clinic teams, and made it harder to drive adherence in long treatment cycles.

Bean is a secure patient portal that brings this data to patients in a usable way. Through a mobile‑optimised web app, patients can manage appointments, view medications, download documents, review invoices and pay them online. The platform integrates directly with FutureLife’s eBase EMR, synchronising data in near real time across multiple clinics and countries. The first production rollout happened within six months, and the platform has been continuously evolving since then.

The Business  Challenge

Turn an internal EMR ecosystem into a patient‑centric service without compromising security or clinical workflows.

FutureLife had a mature EMR (eBase) holding appointments, invoices, medications, lab results and documents – but it was built for internal use, not patient consumption. The portal had to integrate with this without destabilising existing workflows, while delivering a modern, responsive experience.

Reliability was non‑negotiable. Patients need accurate information across devices and time zones. If an appointment changes in the EMR, it must reflect in the portal immediately. If a payment succeeds, both finance and the EMR must stay in sync.

Strategically, FutureLife wanted full ownership and independence. That meant transparent, documented architecture that their team could extend. It also required thinking ahead to internationalisation (including Czech language features), multi‑currency payments, and the ability to scale to new clinics by configuration – not re‑implementation.

Our Role

WDF designed and engineered Bean as a complete platform – from architecture and UX to EMR integration and payments.

Bean is built as an API‑first platform. The backend exposes RESTful services that abstract eBase into patient‑friendly concepts: appointments, documents, invoices, medications. A React frontend consumes these APIs and renders a responsive, component‑based interface designed to feel straightforward to patients.

Key design priorities were ownership and long‑term maintainability. Integrations like Stripe and eBase sit behind abstraction layers so they can evolve without rewriting the portal. Webhook‑based payment flows avoid brittle polling logic. A dedicated notification subsystem supports different event types with clear state transitions.

On the frontend, the team focused on patient‑centred simplicity. Core flows – login, appointment overview, invoice payment, document downloads – work seamlessly on mobile. A Storybook‑based component library keeps the UI consistent as features are added.

The Delivery Journey

The work on Bean followed the same pattern WDF uses for complex platform builds: establish foundations, validate core flows end‑to‑end, then harden and extend in production.

Phase 1

Foundations & architecture

The first phase focused on understanding eBase’s API surface, data structures and constraints. WDF designed the API‑first architecture, including domain models, endpoints and the security model. In parallel, the frontend system was set up with React and Storybook to define key layout and navigation patterns early.

Multi‑environment support was built from day one, allowing safe iteration on EMR and payment integrations without risking clinical data. Each environment has isolated credentials and endpoints while sharing the same codebase and deployment pipeline. The team also specified the internationalisation approach so that content and language handling would not become an afterthought.

Phase 2

Core flows & EMR integration

Once the foundation was in place, the team implemented the core patient flows end‑to‑end. That included account creation and login with email‑based OTP, pulling appointments and medications from eBase into the patient dashboard, and exposing invoices with the ability to download PDFs.

Stripe integration was wired via webhooks so that payment outcomes are pushed into the backend and reconciled with EMR data. The notification system was introduced to surface upcoming appointments, new documents and payment confirmations in a consistent way. Throughout this phase, the team iterated with FutureLife stakeholders on a staging environment, validating behaviours and edge cases before any production rollout.

Phase 3

Production & continuous evolution

Bean was then deployed to production for an initial cohort of clinics. Monitoring, logging and alerting were added so that issues could be identified before they became patient‑visible problems. A clinic‑side view (mirror portal) was introduced, allowing staff to see what patients see, support them more efficiently and maintain an auditable trace of actions.

Since launch, the work has shifted into an ongoing evolution model. New features – richer medication views, extended document types, improved calendar integrations, more languages – are added incrementally. WDF maintains the environments, CI/CD and observability stack, while FutureLife drives product priorities based on feedback from clinics and patients. The architecture has held up as additional clinics and countries have been added without major refactoring.

Why It Matters

Bean transformed how FutureLife thinks about patient relationships. The EMR is no longer just a tool for clinicians – it is now a window for patients into their own care, accessible from any device.

This matters because patient engagement directly impacts treatment outcomes. Patients feel more ownership over their care, clinic teams spend less time on routine inquiries, and FutureLife gained operational flexibility to scale internationally without rebuilding infrastructure each time.

Most importantly, Bean proves that healthcare platforms do not have to choose between security and usability, or between compliance and speed. That is what sets apart products patients actually trust and use.

‍

Now FutureLife has:

Real digital touchpoints for patients
The portal has become a default entry point for patients wanting to understand "what is happening next" in their treatment, increasing engagement across all clinic cohorts.
Operational relief for clinics
Staff spend less time answering simple questions about appointments or invoices and more time on clinical work that actually improves outcomes and patient satisfaction.
A platform it can own and extend
FutureLife is not locked into a vendor portal. The code, APIs and infrastructure are transparent and designed to be extended by the team without vendor dependency.
A template for future digital products
The patterns used in Bean – API-first design, EMR integration layer, multi-environment configuration – can be reused for other digital initiatives across the group as it continues to grow.

Technologies

Python

Used for complex data ingestion pipelines, emissions modeling algorithms, and valuation logic.

React

Building the data-rich dashboards and visualization tools used by analysts and decision-makers.

AWS

The secure, scalable foundation hosting the entire platform, from compute to managed databases.

PostgreSQL

Reliable primary storage for user data, fleets, and core application state.

TypeScript

Powering the core microservices architecture and API layer for high-performance data delivery.

Talk to
our team

Share how we can reach you, and we’ll arrange a brief call with both a product and engineering expert from WDF to walk through your situation and answer questions.

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form.

Prefer to reach out directly?

Vojta Strnad

Director at WDF

+420 732 777 791 vojtech.strnad@wdf.cz