Defining the Regulatory Design Strategy for Medication Administration

Context

Medication administration (MAR) is one of the highest stakes, highest frequency interactions in social care - and historically, the tools for recording it sit separately from the rest of a person's care record.

This separation is the core 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 led design on this work - defining the regulatory boundary it needed to operate within, and shaping the direction that followed from it.

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.

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 how we approached prototyping. Rather than designing a single linear medication journey, we started from the reality that context gets lost at handover, and treated closing that gap as the core design problem to solve for.

Outcome

Established a clear, regulation-safe boundary for the work: what the system can support directly versus where clinical judgement has to stay firmly with humans. That boundary reframed the whole approach, from a feature list to a model built around risk management.

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?