Skip to content

Healthcare

Healthcare frontend development for EMR product UI

At LockeBio, I led frontend work on clinical forms, patient intake, and configurable workflows. The code had to change without making those everyday tasks harder for the people using them, while respecting privacy and operational constraints.

Relevant experience

LockeBio

2024 - 2026

Senior Frontend Developer

Led frontend development for an EMR product, including clinical forms, patient intake, configurable workflows, and shared interfaces across multiple applications.

Worked with: React, TypeScript, Chakra UI, Redux Toolkit, PostgreSQL

St. Michael’s Hospital

2019 - 2020

Senior Web Developer

Worked on healthcare web properties and internal tooling with privacy and accessibility requirements.

Worked with: React, TypeScript, Healthcare APIs, Privacy-aware UI

What the work required

  • EMR product UI
  • Patient management screens
  • Provider dashboards
  • Multi-org interfaces
  • Privacy-aware UI patterns
  • Accessibility fixes
  • Healthcare API integration
  • Internal healthcare tooling

Building a healthcare product?

Send the product context and I’ll tell you where I can be useful.

What healthcare frontend work involves

Clinical forms carry product rules

A clinical form carries rules that change by organisation, by role, and by the state of the patient record. At LockeBio I built intake flows and configurable workflows where the same form had to behave differently for an administrator, a client, and a clinician, without forking the code for each one.

Privacy shapes the whole interface

Privacy-sensitive EMR interfaces decide what appears on screen, what is safe to log, what can sit in a URL, and what must never reach a client-side cache. At St. Michael’s Hospital, I maintained healthcare websites subject to PHIPA privacy requirements.

Two applications, one shared frontend

The EMR and the Core product needed shared form and table behaviour without sharing product rules. I established PNPM workspaces, shared packages, and reusable components that cut duplication across both, while each application kept its own clinical meaning close to the feature.

Shared components need migration boundaries

An order status and an encounter status can look identical in a table and mean completely different things. I package the mechanics and leave the healthcare rules inside the application that owns them, which is what keeps a component library from turning into an internal framework nobody wants to touch.

Changing a live clinical product

These products are in use during the working day, so the work is incremental by necessity. Replacing the router across admin and provider applications, for example, had to preserve authentication and deep links exactly, because a broken link in an EMR is somebody unable to do their job.

Keyboard access and readable state are part of the brief

Healthcare software is used all day, often at speed, sometimes by people who cannot use a mouse comfortably. Keyboard behaviour, focus handling, and readable state in forms and tables are part of the brief rather than a later pass.

Where to go next