Clinformatix is my independent clinical informatics practice, run through Clinformatix Ltd. I take fractional and consulting engagements with teams building, deploying, and adopting clinical AI. I take on a piece of work independently and deliver it back to you, or embed within your team and work alongside your engineers and product people as they build.
I am a surgeon by training who now spends most of my time building with AI. I like demanding problems that need careful thinking, the kind where getting it wrong carries a real cost. I am a systems thinker, and I can talk to clinical, technical, operations, and commercial teams without losing any of them. I am no longer patient-facing, but I keep my GMC registration and licence to practise. Client engagement and clinical operations run right through my career: leading consulting engagements with NHS organisations, then working directly with NHS and US clients to take AI into live clinical pathways.
I trained in ENT and practised on the frontline for five years full-time, then went part-time once I pivoted into clinical informatics. Technology drew me in early: I went to medical school in Newcastle, where even in 2011 the hospital ran on an electronic health record. I assumed that was normal, until I rotated through other hospitals and found most had nothing like it. There was a lot to fix, from connecting care across services to helping clinicians communicate and getting the small day-to-day details right, the kind you only see from the inside.
After an MSc in Health Informatics at UCL, I moved into informatics for good. I was programme lead for the NHS Digital Academy in its first two years, working with many of the country's leading CIOs and CCIOs, and then spent five years as an executive health consultant at a management consultancy firm, working on NHS digital programmes alongside advisory work with UK health-tech start-ups.
Most recently I spent a year as Clinical Lead at a voice-native AI start-up deploying generative AI inside NHS patient pathways. I joined to immerse myself in a fast-moving field and build hands-on skills, and a start-up gave me the steepest learning curve, in at the sharp end from day one. I owned the clinical perspective across product, safety, and compliance, developed the evaluation and validation frameworks, built AI workflows, and learned to prompt engineer, all as a non-coder, working alongside NHS and US clients.
That year settled something I had been circling for a while. The clinical perspective belongs inside the build, in the workflows and the safety thinking, not in a review at the end. Clinformatix is where I take that conviction and turn it outward again.
Clinical AI is becoming more autonomous. As these systems move up the levels of autonomy, the clinician sits further from each decision. The human stays in the loop, but oversight shifts from checking individual outputs to the design of the system itself. That is why safety and clinical product have to be built in from the design phase, not tacked on at different points in the build. Organisations building, deploying, or adopting these tools will need a particular blend of skills held close to the work, and often in a single person. I have started calling that role a Clinical AI Architect. It draws on five things that rarely sit together:
The substrate. Knowing when "a bit of chest pain" needs escalating and when it doesn't. Pattern recognition from years of practice that tells you something is off before you can fully articulate why. You can't build safe clinical AI without people who have that, sitting inside the work, not reviewing it from the outside.
How clinical reasoning becomes a system. Workflows, data structures, variable extraction, evaluation criteria, governance. Not just on paper, but built, iterated, broken, fixed. The work is in the platform, not in a doc.
Prompt engineering, agentic workflow design, iterative testing, AI tooling. Not coding, but genuine technical engagement with how the systems actually behave. Every team building clinical AI needs at least one clinician who thrives in this space, sitting close to the build with their hands on the tools.
Translating clinical need into something engineering can build. Determining when a feature is safe enough to ship, and how to safeguard the end user without slowing the release. Models change, regulation shifts, use cases multiply, and you have to keep up.
Hazards, controls, evidence, residual risk. DCB0129 and DCB0160 compliance. The frameworks aren't new, but the technology is, and the goalposts move every quarter. Without that structure, risks stay unsurfaced, and that can harm patients, damage your reputation, and slow the whole build down in a sector that waits for no one.
Whether you need embedded clinical AI expertise, a safety case for a new deployment, or a pathway template your team can actually implement, get in touch. The first call is free.
Get in Touch →