Skip to content

Product engineering

Talk to us Discuss a Project
Talk to us Discuss a Project

Case study · Healthcare scheduling

NEMS

A FHIR-compliant scheduling experience letting patients book and manage appointments for themselves and their dependents, built across a five-party delivery.

Production system

Engagement
Microservices and web application engineering
Platforms
Patient web application
Role
Development partner within a multi-team delivery
Market
United States Verify before publishing
The NEMS patient scheduling experience: appointment booking for a patient and their dependents, the geo-fenced check-in screen, and the insurance verification step.
Industry
Community healthcare
Users
Patients and their dependents
Standard
HL7 FHIR
Platforms
Web
Role
Microservices engineering
Status
Production

01The business situation

Scheduling is the front door to care.

North East Medical Services serves medically underserved populations across the San Francisco Bay Area. Its board set out to improve the patient experience by making scheduling something a patient could do themselves: for their own appointments and for those of the dependents in their care, against a FHIR repository that had to remain the system of record throughout.

Core challenge

Deliver a self-service scheduling experience on top of a clinical FHIR repository, across five organisations, without ever becoming a second source of truth.

Before

Scheduling mediated by staff, records held apart

  • Phone Scheduling
  • Front-desk Check-in
  • Manual Verification
  • Separate Records

After

Patients scheduling directly against the clinical record

  • Patient
  • Dependent
  • FHIR Repository
  • Clinic

NEMS Scheduling Platform

02The system at a glance

One patient experience. Four connected concerns.

  • Patient Web Application Book, manage and check in
  • Dependent Management Appointments for those in your care
  • Insurance & Eligibility Coverage checked before the visit
  • Registration & Identity MRN login and new-patient sign-up
Core PlatformMicroservices against a FHIR system of record
  • Appointment Scheduling
  • Geo-fenced Check-in
  • Insurance Verification
  • MRN Authentication
  • QR Registration
  • Notifications

03Workflow 01

Book for yourself, or for someone in your care.

A guardian holds appointments for dependents as well as their own. The platform treats that as the normal case rather than an edge case, so one login manages a household.

Image placeholder Appointment booking flow: patient or dependent selection, available slots by clinic and provider, and the confirmed appointment summary. assets/portfolio/nems/workflow-booking.png · 16 / 11
  • One login, a whole householdA guardian schedules and manages appointments for their dependents from the same account.
  • Slots from the clinical recordAvailability is read from the FHIR repository rather than from a separate calendar that could drift.
  • Manage after bookingRescheduling and cancellation are part of the patient experience, not a phone call.

04Workflow 02

Arriving is part of the appointment.

Existing patients log in with the medical record number they already have. New patients register and receive a QR code that makes the next visit quicker. Check-in itself is geo-fenced, so it happens when the patient is actually at the clinic.

  1. 1Log in with MRN

    Image placeholder Login screen accepting an existing medical record number, with the alternative path for new patient registration. assets/portfolio/nems/step-login.png · 1 / 2.04

  2. 2Verify coverage

    Image placeholder Health insurance availability check: the patient’s coverage details and the verification result before the appointment is confirmed. assets/portfolio/nems/step-insurance.png · 1 / 2.04

  3. 3Check in on arrival

    Image placeholder Geo-fenced check-in screen: the appointment, the clinic location and the check-in action enabled once the patient is on site. assets/portfolio/nems/step-checkin.png · 1 / 2.04

05Workflow 03

Five organisations, one product.

Quantfarm led design and development for NEMS, collaborating with us for engineering and with Apperbuilder for design; Smile CDR hosted the FHIR repository. What held five organisations together was a shared contract at the API boundary and a test-first route to production.

  • A contract at the FHIR boundaryIntegration was driven by the FHIR APIs Smile CDR exposed, held in a shared Postman collection to work past thin documentation.
  • Environments that prove portabilityProduction and staging were deliberately hosted on different clouds to demonstrate the deployment was not tied to one.
  • Tested before it shippedUnit, integration and regression testing preceded staging, and user acceptance testing gated production.
Image placeholder Architecture diagram: the patient web application, the microservices layer, the FHIR repository, and the third-party insurance, SMS and email integrations. assets/portfolio/nems/architecture.png · 16 / 10
Image placeholder New patient registration completing with a generated QR code for quick login on the next visit. assets/portfolio/nems/registration.png · 1 / 2.04

06Engineering behind the product

The system behind a FHIR-compliant booking.

The engineering problem here was less about the interface than about integrating cleanly with a clinical record standard owned by another team.

  • Microservice architecture

    The product was decomposed into services so parts of it could evolve and deploy independently of one another.

  • FHIR repository integration

    Appointments, patients and coverage are read from and written to the FHIR repository, which stays the system of record throughout.

  • MRN-based authentication

    Existing patients authenticate with the medical record number they already hold, avoiding a parallel identity system.

  • Dependent relationships

    A guardian and their dependents are modelled explicitly, which is what allows one account to manage several patients.

  • Geo-fenced check-in

    Check-in is gated on the patient being at the clinic, so the record reflects arrival rather than intent.

  • Insurance verification

    Coverage is checked through Experian eligibility verification as part of the booking flow.

  • Cloud-agnostic deployment

    Production ran in containers on one cloud while staging ran on another, deliberately proving the deployment was not tied to a single provider.

  • Async and websockets

    Redis and Celery handle queued and scheduled work, and uvicorn serves the application so it can hold the websocket connections the product needs.

  • SMS and notifications

    One-time passwords and transactional SMS run through Twilio, with email over SMTP.

07Technical architecture

Under the hood

A microservice product integrating a FHIR repository owned by another team, deployed across two clouds to prove portability.

Backend

  • Django
  • Django REST Framework
  • Microservices

Frontend

  • Vue.js
  • Bootstrap

Async & serving

  • Redis
  • Celery
  • Nginx
  • uvicorn (ASGI)

Cloud

  • Azure + Docker (production)
  • AWS VPC + load balancer (staging)

Integrations

  • Smile CDR (FHIR)
  • Experian (insurance eligibility)
  • Twilio (SMS & OTP)
  • SMTP email

Delivery tooling

  • Postman
  • Jira
  • Confluence

08Delivery journey

How the platform was delivered.

  1. Requirements

    Gather scope with the clinical team

  2. FHIR readiness

    Stand up the repository and resources

  3. Design

    Mock up and approve the patient experience

  4. Test cases

    Document and agree expected behaviour

  5. Engineering

    Build services and integrate the APIs

  6. UAT

    Acceptance testing before release

  7. Production

    Release and support Phase 1

Phase 1 scope is described above. Engagement dates, durations and adoption figures are withheld until confirmed. Verify before publishing

09What the system enabled

What the delivered platform enabled

  • Self-service scheduling against a FHIR system of record
  • Appointments managed for dependents as well as patients
  • Login with an existing medical record number
  • Geo-fenced check-in at the clinic
  • Insurance eligibility checked inside the booking flow
  • New patient registration with QR-code login

Related systems

Clunker Busters

Vehicle Inspection · Marketplace · Web + Mobile

A connected platform for customers, inspectors, operations, reporting and payments.

DocSwap

Healthcare · Workforce Scheduling · Mobile + Web

A hospital shift platform where residents set preferences, an algorithm builds the roster, and shifts can be swapped without a chain of phone calls.

View case study , DocSwap

Clinical standards are a constraint, not an obstacle.

We build against the record systems you already have to answer to, rather than around them.

Discuss your system