Skip to main content
Xalicon

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
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.

  1. Patient portalServer-rendered web app, WCAG 2.2 AA
  2. Companion appReact Native, shared API
  3. Portal APIIdentity, permissions and audit logging
  4. Integration layerFHIR resources mapped to EHR operations
  5. EHRSystem of record, unchanged
  6. 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)

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