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.