Point of Care

Designer, NextGen EMR

Point of Care

032018–2019

Two surfaces of TELUS Health’s NextGen mobile EMR, where a design decision carried life-safety consequences. A prescriber module that fed Canada’s national e-prescribing service — built across two acquired products with different data models; and a lab-report spec that fixed the position of a single result-dot with pixel precision. Every prescription, allergy, and drug-interaction flow was reviewed by clinicians before it shipped.

TELUS Health builds the software Canadian clinicians use to prescribe and review. I was the designer on two of its surfaces: the prescriber module of the NextGen mobile EMR, with its PrescribeIT® integration, and the Lab Reports module shipped across multiple EMR products. Different screens, one constant — the clinician’s decision was never far from the patient’s safety.

The product team was not a typical software team. The product managers were nurses who had practised clinically before moving into product. We held weekly co-design workshops, and every prescription flow, every allergy-interaction warning, every threshold setting was reviewed by clinicians before it shipped — not as a final check, but as an embedded part of the design loop.

That changed what each decision was. Shortening a path wasn’t a UX call in isolation; the question came back as — what does the clinician lose by not seeing the intermediate state? Sometimes the answer was nothing. Sometimes it was something I hadn’t anticipated. The interaction patterns came out of those conversations, and the rigour they demanded carried into every screen.

The work shipped and held. The prescriber module fed PrescribeIT®, Canada Health Infoway’s national e-prescribing service; in Prince Edward Island, roughly 70% of prescribers in the provincial EMR program and over half the province’s pharmacies had taken it up by 2023.

I — The Prescriber Module

NextGen was TELUS Health’s mobile EMR: one prescriber-facing UI built on top of two acquired products with different data models — Kinlogix in Quebec, PS Suite in Ontario — with three more in the integration pipeline, plus the PrescribeIT® national service. The architectural job was to surface the differences where they mattered to the clinician and hide the seam where they didn’t. The module shipped; these eleven specifications are the design record.

A hand-drawn “Pharmacy Ecosystem” diagram mapping manufacturer, wholesaler, pharmacy, warehouse/lab, pharmacist, physician, clinic, and patients, with a medication-code legend.
fig. 1 — 2019, the pharmacy ecosystem, mapped — how a medication moves from manufacturer and wholesaler through the pharmacy to the patient, and where physician, pharmacist, lab, and clinic sit between.
A multi-screen navigation diagram of the electronic-prescription flow.
fig. 2 — 2019, the Send-eRx flow, specified end to end — eighteen screens of prescribing with each use case labelled.
A grid of thirteen pharmacy-search result-list states.
fig. 3 — 2019, the rigor behind the pharmacy search — thirteen use cases enumerated as condition-to-outcome rules, each with its own result-list state.
A medication-search spec with annotations marking Quebec-only Kinlogix indicators across states.
fig. 4 — 2018, the data-model seam, surfaced where it mattered — Quebec drug-formulary indicators that appear only for Kinlogix users, annotated state by state.
A discontinuation screen prompting for a reason, the drug named above an empty reason field.
A prescription review with the discontinued medication struck through and its reason in red.
fig. 5 — 2019, discontinuing — the reason captured, then the medication shown struck through on review. Reviewed before the prescription is signed.
A printed-prescription template marked up with redlines and bilingual rules.
fig. 6 — 2019, the printed prescription template, redlined — bilingual rules for what may and may not appear on a paper Rx.

II — Lab Reports

A clinician opens a lab report on a phone: twenty rows of numbers, and the job is to notice which values are abnormal, fast. The eye reads patterns, not digits — so a column of dots along a normal range beats a column of numbers. That choice raised one precise question: where exactly should the dot go?

A spec page working out a result-dot position with a rule-of-three calculation.
fig. 7 — 2018, the position of a result-dot, solved as a rule of three — a WBC of 9.0 on a 4.0–11.0 range lands at pixel 51 of 72. The math first; the pixels follow.
A spec showing the abnormal-value dot offset left for low and right for high along an axis.
fig. 8 — 2018, the dot pulled 5dp off the axis — left for low, right for high — so the eye reads ‘off the normal range’ before it reads a number.
The lab-report detail laid out at two phone widths, 360dp and 551dp.
fig. 9 — 2018, one content, two layouts — the lab-report detail at 360dp and 551dp, nineteen footnotes fixing every width, padding, and state.