Designing eMAR (Medication Administration)

Context

Nourish is building a native eMAR (electronic Medication Administration Record), launching within the year. Medication is one of the highest-stakes, highest-frequency interactions in social care - and historically, the tools for managing it have lived as a separate system from everything else a care record already captures about a person.

This separation is the whole design problem. The moment medication administration lives apart from the rest of someone's care record, you lose context exactly when it matters most.

My role

I'm leading design through discovery into build - setting the direction, defining the regulatory design boundary the whole team works within, and now shaping the prototyping brief that will guide my team's next phase of work.

Constraints

This isn't a typical product build, and it doesn't have typical design freedom. Certain categories of feature - automated interaction checks, allergy alerts that make a clinical judgement, dose calculators - would push the product into formal medical device classification under UK regulation. That's the line between software that supports a human decision and software that makes one.

The design boundary for v1 is deliberately conservative: the product supports recording and workflow, with no autonomous clinical interpretation. As a team, we’re cautious not to slip into "the system tells you what to do". Instead, the system only guides, with explicit regulatory decision-making, not by accident through feature design.

What we did

We ran structured discovery across multiple customer types, rather than starting from an assumed feature list. That meant sitting with the actual moment of medication administration as it happens today, mapping the real journey: how a medication decision gets made, prescribed, dispensed, and finally administered, and everywhere that chain currently breaks down or loses information.

Journey mapping the administration round itself was the most valuable exercise. Laid out end to end, it made visible how much of the risk in medication administration isn't a software gap at all - it's a handover gap: information that exists somewhere in the system but isn't present at the exact moment a care worker needs it. That reframing came directly out of walking the journey step by step rather than working from a feature request list.

This research reshaped the flows my team and I then took into prototyping: rather than designing one linear medication journey, the architecture has to treat care-setting context as a first-class input from the start, not a configuration option layered on afterwards.

Outcome

Established the clinical-regulatory design boundary that allows for rapid v1 delivery while maintaining patient safety. The findings are strong enough that the product direction is no longer vague, and the current phase is translating that evidence into a scoped v1 brief.

Reflection

This is an excellent case study for understanding how constraints can often be clarifying. In this case, it forced the most difficult, most valuable design questions to the front: how do you make good information visible at the right moment, without the system pretending to decide anything for the user?