Healthcare
A patient portal that clinicians actually adopted
Placeholder case study. Appointments, results and secure messaging delivered against an immovable EHR, designed around clinician workload rather than around the feature list.
- Next.js
- TypeScript
- Node.js
- PostgreSQL
- FHIR
- React Native
- AWS
Sample case study — illustrative, not a delivered client engagement
Calder Health Network is an invented company used to demonstrate our case-study format and our approach to this kind of work. The technical detail reflects how we would genuinely deliver it; the client name is fictional and the figures under Results are design targets rather than measured outcomes.
Client
Calder Health Network
Illustrative multi-site outpatient provider — PLACEHOLDER CONTENT
- Industry
- Healthcare
- Services
- Web & MobileProduct Engineering
- Year
- 2026
The business challenge
PLACEHOLDER — replace with the real engagement narrative. The illustrative situation: patients booked and rescheduled by phone, which consumed most of the front-desk day, and results were posted by letter. A previous portal had been abandoned because it added clicks to the clinician workflow rather than removing them. The core clinical system could not be replaced, so anything new had to integrate with it.
Objectives
- PLACEHOLDER — Reduce inbound calls for booking and results
- PLACEHOLDER — Integrate with the existing EHR rather than replacing it
- PLACEHOLDER — Add no net clicks to the clinician workflow
- PLACEHOLDER — Meet accessibility obligations for patient-facing software
- PLACEHOLDER — Support HIPAA and GDPR requirements in the data design
Discovery and strategy
What we did before writing code
- PLACEHOLDER — Observed front-desk staff for a full week and counted call reasons
- PLACEHOLDER — Timed the existing clinician workflow to establish a click baseline
- PLACEHOLDER — Audited the EHR integration surface and available FHIR resources
- PLACEHOLDER — Ran usability sessions with patients across a range of digital confidence
- PLACEHOLDER — Agreed with the clinical safety officer what the portal would not do
Solution
What we built
PLACEHOLDER — Appointment self-service
Replace with real detail. Booking, rescheduling and cancellation written straight back to the source system, with slot rules mirrored rather than duplicated.
PLACEHOLDER — Results release workflow
Replace with real detail. Results published only after clinician sign-off, with plain-language context and an explicit route to ask a question.
PLACEHOLDER — Secure messaging
Replace with real detail. Threaded messaging routed to the right team with response expectations shown to the patient up front.
PLACEHOLDER — Integration layer
Replace with real detail. A FHIR-based layer between the portal and the EHR so the portal never talks to the clinical database directly.
PLACEHOLDER — Companion mobile app
Replace with real detail. Appointment reminders and document access on iOS and Android from the same API.
PLACEHOLDER — Operational dashboard
Replace with real detail. Adoption, deflection and message-response reporting for practice managers.
Architecture
How it fits together
PLACEHOLDER — Portal and integration architecture
Replace with the real architecture. The illustrative shape: a patient-facing application separated from the clinical system by an integration layer, so the EHR is never a direct dependency of the interface.
- Patient portalServer-rendered web app, WCAG 2.2 AA
- Companion appReact Native, shared API
- Portal APIIdentity, permissions and audit logging
- Integration layerFHIR resources mapped to EHR operations
- EHRSystem of record, unchanged
- ReportingAdoption and deflection analytics
Design approach
Decisions in the interface
- PLACEHOLDER — Designed the booking flow for one-handed mobile use
- PLACEHOLDER — Tested at 400% zoom and with screen readers before build
- PLACEHOLDER — Wrote results copy with clinicians to avoid alarming phrasing
- PLACEHOLDER — Kept the clinician surface to a single inbox rather than a new system
Development process
How the work ran
- PLACEHOLDER — Two-week cycles with a clinician review at the end of each
- PLACEHOLDER — Integration tested against an EHR sandbox before any live connection
- PLACEHOLDER — Automated accessibility checks in the pipeline from the first sprint
- PLACEHOLDER — Staged rollout by site, starting with a single clinic
Technology stack
What it runs on
- Next.js
- TypeScript
- Node.js
- PostgreSQL
- FHIR
- React Native
- AWS
Challenges resolved
What went wrong, and what we did
Every project has these. A case study that omits them is a brochure.
PLACEHOLDER — Slot rules lived only in the EHR
Replace with real detail. Duplicating booking rules would have guaranteed drift, so the portal queries availability live and never holds its own copy.
PLACEHOLDER — Clinicians would not adopt a second inbox
Replace with real detail. Messages surface inside the existing workflow rather than in a separate portal login.
PLACEHOLDER — Patient identity matching
Replace with real detail. Verification was designed with the practice to avoid both wrongly linking records and locking out legitimate patients.
Results
Objectives and design targets
Because this is a sample case study, these are the objectives and design targets agreed in scope — not measured business results.
PLACEHOLDER — Call volume
Target only
Placeholder. Replace with a measured, verifiable outcome or remove.
PLACEHOLDER — Clinician clicks
No net increase
Placeholder design target agreed during discovery, not a measured result.
PLACEHOLDER — Accessibility
WCAG 2.2 AA
Placeholder. Conformance target for the patient-facing surface.
Client feedback
In their words
Placeholder quote
This quote is sample content shown to demonstrate the layout. It is not attributable to a real person or organisation and will be replaced only with a genuine, approved testimonial.
“PLACEHOLDER — replace with a real, approved client quote. This text exists only to demonstrate the layout.”
Placeholder namePlaceholder role (illustrative)
Related services
The practices behind this work
Web & Mobile
Web applications, mobile apps, commerce experiences and product design — built for performance, accessibility and conversion.
Explore Web & MobileProduct Engineering
SaaS platforms, custom software and MVPs engineered for multi-tenancy, billing, security and the release cadence a growing product needs.
Explore Product Engineering
More work
Other case studies
- HRTechSample content
An applicant tracking platform with explainable candidate matching
A recruitment platform where structured CV parsing and explainable matching cut screening time without removing recruiter judgement.
- Next.js
- TypeScript
- Node.js
- PostgreSQL
- FinTechSample content
Multi-tenant billing and entitlements for a growing SaaS platform
Retrofitting organisations, entitlements and usage-based billing into a product originally built for individual users.
- Next.js
- TypeScript
- Node.js
- PostgreSQL
- LogisticsSample content
Modernizing a logistics portal without pausing operations
Incremental migration of a business-critical customer portal and driver workflow using the strangler pattern, with no cutover event.
- Next.js
- TypeScript
- Node.js
- PostgreSQL
- E-commerceSample content
Replatforming a storefront without losing a peak season
Placeholder case study. A headless storefront migrated page type by page type, with checkout instrumented before anything was redesigned.
- Next.js
- TypeScript
- Shopify Hydrogen
- Algolia
- EdTechSample content
An assessment platform that holds up on results day
Placeholder case study. Timed assessment delivery engineered for concentrated load, with integrity controls and accessibility treated as requirements rather than settings.
- Next.js
- TypeScript
- Node.js
- PostgreSQL
Similar situation?
Start a project like this one
Tell us where you are. We will tell you how we would approach it and what we would want to understand first.
Prefer email? contact@xalicon.co