Decision support ends where the nurse can no longer check the reasoning

In September the FDA granted marketing authorisation to the heart-failure risk score that my team at Ardenwick spent three years building. The score combines a patient's daily weights, blood pressure, heart rate, symptom answers and recorded medication changes, and estimates the likelihood of a worsening episode in the following days. It tells a nurse which of her heart-failure patients to call first. Authorisation came about two years later than our sales plan once assumed, and it cost us customers along the way. I want to explain why I think it was the right route, and why many product teams in digital health ask the wrong question when they decide whether their software is a medical device.

The question they usually ask is whether the software can be made to fit the exclusion. The 21st Century Cures Act of 2016 removed certain clinical decision support software from the definition of a device, and the FDA's guidance describes when software qualifies. In general terms, the software must not analyse medical images or signals from devices, must support rather than replace a clinician's judgement, and must let the clinician independently review the basis for its recommendation, so that she is not relying mainly on the software to decide. The agency has revised its guidance on this more than once, and I expect it to move again. The structure of the question has stayed stable.

The exclusion is about the clinician, not the code

When our data scientists showed me the first version of the score in 2022, our commercial team saw an opportunity to release it within months as an insight panel. The proposal was careful. It listed the readings that contributed most to each patient's score, so that a nurse could, in principle, see why a patient had been flagged. With that list on the screen, the argument went, the software supported her decision and she could review its basis.

I did not believe it, and neither did our head of regulatory affairs, Lydia Habersham. The score was built from readings captured by connected devices, which placed it close to the kind of signal analysis the exclusion was never meant to cover. More importantly, the list of contributing readings did not let a nurse do what the guidance describes. It told her which inputs mattered, not how they had been weighed, how the model behaved in patients like hers or how often it was wrong. A monitoring nurse working through sixty patients before lunch cannot reconstruct a model's reasoning from five values in a sidebar. If she acts on the score, she is relying on it. That is the plain test, and our score failed it.

Product teams can design for the exclusion in good faith, and some decision-support tools genuinely belong outside device regulation. Order sets, reference information and rules a clinician has written and can read all seem to me to sit comfortably within it. My argument is narrower. When the value of the software lies precisely in a judgement the clinician cannot check, it is a device in substance, and dressing it in explanation does not change that. The question to ask is not whether the software can be presented as decision support. It is whether the clinician could reach the same view without it, in the time she actually has.

What the validation study changed

Treating the score as a device meant building it inside our quality management system, with design controls, risk analysis and a validation study before release. We ran that study across four health systems from 2023 into 2024, with 2,900 patients whose nurses could see the score alongside their usual worklist. It cost about US$4.9 million of the US$7.4 million the whole programme required.

The study changed the product in ways our retrospective analysis never would have. Performance was weaker in patients with advanced kidney disease, whose weights move for reasons that have little to do with their hearts. We could not fix that in time, so the labelling now states the limitation and the score carries a caution for those patients. Nurses in two of the four systems told us they wanted the score as a column in the worklist rather than in a separate panel, because a panel was one more place to look. We moved it. And the study showed that the score was most useful in the first ninety days after a hospital discharge, which changed how our customers decide whom to enrol.

We also proposed, and the agency accepted as part of the authorisation, a predetermined change control plan. It describes how we will retrain the model on new data, which performance measures each retrained version must meet and how we will tell customers about changes. That plan matters more to the product's future than the original authorisation does. A risk model that cannot be updated becomes stale, and one updated without discipline becomes something its users never agreed to.

Evidence before the sales calendar

The cost was real. Two customers did not renew in 2023 and 2024, together worth about US$3.6 million a year, partly because a competitor offered a risk feature sooner. Our sales team spent two years explaining a delay, and I twice told customers that the score would arrive later that year, a mistake I should not have made even once. Our chief revenue officer, Nathaniel Strathby, argued throughout that we were letting others define the category. In the short run he was right.

The other side of the ledger is already visible. The clinical committees at our customers approve the score faster than they approve our non-device features, because they can read the study, the labelling and the change plan. In its first two months, 22 customers have switched it on for about 5,800 heart-failure patients. The discipline has also spread inside the company. Every proposal that reaches my team now states, on its first page, whether the clinician can check the output in the time she has, and what evidence we will need if she cannot.

I would offer one test to any product leader, or any board, considering similar software. Ask a nurse to use it for a morning, then ask her to explain why the software ranked her third patient above her fourth. If she can, you may well be building decision support. If she cannot, you are building a device, and the patients relying on it deserve the evidence that comes with that.