Joseph isn’t a real patient.
Joseph sent in the same readings on a Monday in September and on a Monday in October. The right response was completely different each time, and the only people who could have known why were Joseph and his doctors.
Joseph is 81, has advanced heart failure and is monitored at home. In September his cardiologist’s aim was the usual one for someone like him: catch fluid building up early and treat it firmly, before it turns into another hospital stay.
At the start of October, after his third admission that year, Joseph sat down with his daughter, his cardiologist and the palliative care team. He was clear about what he wanted. He wanted to stay at home. He was happy to have treatment that kept him comfortable there, but he didn’t want to go back into hospital unless they couldn’t make him comfortable at home.
On both Mondays the reading was the same. His weight was up 3 lb over two days, and he was more breathless on the stairs.
In September the right plan was to escalate. That meant a same-day review at the heart failure clinic, stepping up his treatment, and a low bar for sending him to hospital if he didn’t improve.
In October the right plan looked very different. A nurse would visit him at home that day, he would take the extra diuretic dose his cardiologist had already agreed for this kind of situation, and someone would call the palliative care team. Suggesting a hospital transfer would have gone against what he’d asked for.
Same reading, different concerns, different plan
Monday: weight up 3 lb in two days
and more breathless on the stairs
September · concerns
Watch for early fluid build-up.
Escalate early.
Constraints
None added.
Proposed plan
Same-day heart failure clinic review
Step up treatment
Low threshold for hospital
October · concerns
Watch for breathlessness and fluid build-up.
Aim for comfort at home.
Constraints
No hospital transfer unless comfort can’t be achieved at home.
Proposed plan
Home nurse visit today
Pre-agreed extra diuretic dose
Call the palliative care team
Between the two months, nothing changed in the reading or in his medical record. The only thing that changed was what his clinicians had written down about what mattered for him.
Connecting the dots isn’t the whole job
A lot of the conversation about remote monitoring is about connecting facts: spotting a slow trend, or pulling in a lab result from another clinic. That work matters, but Joseph’s case shows it isn’t enough on its own. His facts were identical in both months, and what they meant was not.
What a reading means depends on what a patient’s care is trying to achieve. That’s a clinical judgment, made together with the patient, and it moves. The same weight gain can be urgent for one person and expected for another. Goals shift after a new diagnosis, an honest conversation or a hard month. And two good cardiologists can reasonably draw different lines for the same frail patient.
A system that decided by itself what mattered, however clever, would have sent Joseph back to hospital in October. On paper that would have been a correct response. For Joseph it would have been the wrong one.
Why most systems can’t do this today
In many monitoring programs, the alert rules are set once and applied to everyone. They often belong to the program or the device vendor rather than to the patient, so changing them for one person means raising a ticket or getting an exception approved. Sometimes it just means a nurse who learns to ignore that patient’s alerts.
Joseph’s wishes were written down carefully, but in a free-text note that no alert rule ever reads. And even a well-tuned alert can only tell you that something crossed a line. It can’t tell you what to do for this particular patient, given what everyone agreed.
You end up with software that behaves the same way for every patient, in a field where good care looks different for each one.
Letting the clinician set what matters
To handle Joseph well, a system has to let his clinician say what matters for him in plain clinical terms, and change it when his plan changes.
In September his cardiologist might write: watch for early fluid build-up and escalate early. In October that becomes: watch for breathlessness and fluid build-up, and aim to keep him comfortable at home. The cardiologist would also add a limit in October: don’t suggest a hospital transfer unless comfort can’t be managed at home. That limit then applies to every suggestion the system makes for Joseph, whatever set it off.
When Monday’s reading arrives, the suggestion should show its working. It should name the reading, the concern it relates to and the limit it respected, so a nurse can see quickly whether it makes sense for the person in front of them. The system only ever suggests. A clinician confirms, and the system never decides by itself what matters.
If you change what the clinician has written, the same reading should lead to a different plan. For me that’s the clearest test of whether the clinician or the software is really in charge.
My co-founder Keith Deutsch calls this kind of system a context layer, meaning shared infrastructure that keeps a living picture of the patient. His white paper, The Context Window and the Context Layer, puts the principle in one line:
“The Context Layer must be accountable to the domain it serves, not merely responsive to the information sources it observes.”
We haven’t built this yet. Showing that a change in what the clinician writes leads to a different but still sensible plan is one of the first things our prototype has to demonstrate.
Goals change, and software has to keep up
Joseph isn’t an unusual case. Every patient’s care has goals, and those goals move over time. Software that watches people at home needs to hear what those goals are from the people who set them, and it needs to keep up when they change.
Sources
- Keith Deutsch. The Context Window and the Context Layer: An Architectural Distinction for Agentic AI. October 2026.