Maria isn’t a real patient, and the numbers in this piece are illustrative.
Maria’s heart failure dose went up on a Thursday, one day after a blood test showed it shouldn’t have. Nobody involved made a mistake.
She’s 68 and lives with three long-term conditions: heart failure with a weak pump, chronic kidney disease and type 2 diabetes. Two teams share her care. Her heart failure clinic is slowly raising her heart medicines toward the doses that do the most good, one step every two weeks. Her primary care doctor looks after her kidneys and her diabetes.
That week, the heart failure plan was simple. A nurse would call on Thursday, check Maria’s home blood pressure and heart rate, and if both looked fine, increase her sacubitril/valsartan. The drug protects the heart, but it can also push potassium up and put strain on the kidneys. Her last labs at the heart failure clinic, from two weeks earlier, had been normal.
On Monday Maria picked up a stomach bug, and for two days she could barely keep fluids down. On Wednesday she saw her primary care doctor. Her eGFR, a measure of how well the kidneys are filtering, had dropped from 48 to 36, and her potassium had gone from 4.6 to 5.4 mmol/L. Her doctor wrote it up as dehydration with an acute kidney injury, paused her metformin, told her to drink more, and booked a repeat blood test for the following week.
On Thursday the heart failure nurse rang. Maria was feeling better. Her blood pressure was 112/70 and her heart rate was 74, which met every condition in the plan, so her dose went up.
By the following Monday her potassium was 6.1, and she spent the night in the emergency department.
The lab that should have held the dose sat in another plan
Maria’s week, by who held each piece of information
Two pieces of paper, two different desks
If one clinician had been holding both the Wednesday lab result and the Thursday plan, I’m fairly confident the dose would have waited. This isn’t a close call. The drug’s US label tells prescribers to monitor kidney function and potassium, and it says the dose may need to be reduced or paused if they get worse. It also lists diabetes and kidney disease as risk factors for high potassium (FDA label, sections 5.4 and 5.5). Maria had both, plus a fresh kidney injury and a potassium level that was already high.
The sensible move was to wait until she’d rehydrated, check her bloods again and then decide. Pushing a titration back by a week costs very little.
So nobody got anything wrong. The decision that mattered just never reached anyone, because the result it depended on was sitting in somebody else’s plan.
Why software doesn’t catch this
I’ve spent most of my career on healthcare interoperability, getting lab systems, EHRs and devices to pass data to one another. Maria’s week is a good reminder of how much can still go wrong after the data has arrived.
Most care software is organized around conditions. The heart failure protocol checks the things heart failure protocols check: blood pressure, heart rate, symptoms. A kidney result belongs to another team. Even when both teams use the same EHR, a lab ordered by a different clinic is one result among hundreds. Nothing about it tells a heart failure protocol to stop.
You could write a rule for this particular case. Something like “if a heart failure titration is due and a kidney lab has worsened since the last one, hold it.” But you would need a rule like that for every combination of condition, medicine and result a patient with three chronic illnesses can run into, and the number of combinations grows far faster than anyone can write rules. So most never get written, and the connection depends on whoever happens to be holding both facts at the right moment.
My co-founder Keith Deutsch makes this point in his white paper, The Context Window and the Context Layer:
“Information that is semantically similar is not necessarily contextually relevant, and information that is critically related may exhibit little semantic similarity.”
On the surface, a kidney lab and a heart medicine dose have almost nothing in common. In Maria’s case they were tightly linked.
What would have caught it
The two plans need to share one picture of Maria, so that any new fact gets checked against everything it affects, and not only against the plan that ordered it. In practice, her heart failure plan, her kidney care, every result and every scheduled change would all live in the same continuously updated record of her. A lab result would stop belonging to the clinic that ordered it.
Heart failure clinicians would also write down, once, the things that shouldn’t happen. For example: don’t increase this class of drug while potassium is high or kidney function has recently dropped. That rule says nothing about stomach bugs or primary care visits. It just stays attached to Maria. When Wednesday’s lab comes in, the software sees that it touches that rule and the increase planned for Thursday. Nobody had to predict this particular chain of events.
Before making the call, Thursday’s nurse would see a suggestion like this:
Hold today’s dose increase? Potassium 5.4 and eGFR down from 48 to 36 on Wednesday (primary care). Recheck once she’s rehydrated.
The nurse and the heart failure doctor decide. The software never changes a dose on its own.
Keith calls this a context layer: shared infrastructure that keeps a living understanding of the patient, instead of rebuilding it every time someone asks a question. We haven’t built it yet. We’re specifying it carefully and building a prototype next, with clinicians writing the rules it works from.
The data was all there
Maria didn’t end up in the emergency department because data was missing. Every number was measured, recorded and correct. The two facts that mattered simply never met, and the more teams, programs and systems a patient’s care is spread across, the more often that will happen.
Sources
- ENTRESTO (sacubitril/valsartan) US prescribing information, US Food and Drug Administration, 2024. Sections 5.4 (impaired renal function) and 5.5 (hyperkalemia).
- Keith Deutsch. The Context Window and the Context Layer: An Architectural Distinction for Agentic AI. October 2026.
