5 February 2026 · Medows · Dr. Soumyadeep Adhikari & Alapan Mondal
The DKA That Survived Because of One Note
A 45-year-old man, DKA, an 11 p.m. ABG, and a handover line that meant the receiving doctor caught a worsening at 3 a.m. instead of 8.
Dr. Soumyadeep Adhikari, Alapan Mondal
2 authors
A 45-year-old man, admitted with DKA at 9 p.m. Sugar 480, ketones 4+, pH 7.18. The on-call resident starts insulin at 6 U/h, sends an ABG at 11 p.m., orders hourly capillary blood glucose, and writes the orders into the patient's chart.
At 1 a.m. she is pulled into a code in the next ward. By the time she returns it is 2:14 a.m. and the night handover is starting.
The moment the system usually fails
This is the moment ward work usually fails. Twenty-eight patients to summarise in eight minutes. The DKA patient's 11 p.m. ABG hasn't returned yet. There is no field on paper to capture "pending lab — will return around 3 a.m. — alert me if pH falls further."
Notice what kind of failure that is. Nobody has forgotten anything, because nobody has yet had the chance to know it. The result does not exist. The doctor who ordered it — the only person in the building who knows why it was ordered and what she was worried about — is about to leave. The result will materialise at 3 a.m. into a system that has no record of anyone waiting for it.
Call it the orphaned investigation. It is the most under-counted failure mode on a ward, because it never produces a moment anyone can point at. There is no missed result to audit. There is only a result that got read four hours later than it should have, by someone who read it as a routine number rather than as the answer to a question.
What was actually at stake
A pH of 7.18 that is still falling three hours into an insulin infusion is not a number that waits politely. It means something in the plan is not working: the infusion rate is too low, or fluids are behind, or the potassium has crashed and the insulin is being held, or the precipitant — the infection, the missed dose, the infarct — has not been found yet.
The default alternative was not "someone checks in an hour." The default alternative was the 8 a.m. routine gas, because that is what exists when nothing else is scheduled. Five hours. In DKA at pH 7.09, five hours is the difference between a turn around the corner and an ICU transfer, and the intervening hours are the ones in which a patient who was talking at 3 a.m. stops being able to protect their airway.
What actually happened
In Medows the handover for that patient had auto-composed itself from the shift events:
Bed 16 · 45/M · DKA Now: Insulin infusion 6 U/h, hourly CBG, K+ replacement in IV fluids. Pending: 11 p.m. ABG awaiting result — alert if pH worsens. Repeat ketones at 03:00.
The receiving doctor saw the line at 2:14 a.m. The ABG returned at 3:08 a.m. with pH 7.09. He caught the worsening. By 3:30 the bicarbonate conversation had happened with the senior. By 5 a.m. the trend was reversing.
Why "Pending:" is a field and not a sentence
The outgoing resident did not write that line. That is the whole point — at 2:14 a.m., after a code, she would not have. It was composed from the state of the order: an ABG placed at 11 p.m. that had not yet resulted, which is a state the workspace already tracks because it tracks every order through the same lifecycle — active, awaiting result, resulted.
That structure is what makes the line survivable. A receiving doctor scanning twenty-eight patients is not reading; they are pattern-matching against a fixed shape. Now tells them what is running. Pending tells them what will arrive and what to do about it. Those two words carry more of the safety load than any amount of well-written prose, because prose has to be read from the beginning and a bolded field label can be found from across the page.
The same paragraph buried in free text as "…started on insulin, gas sent at 11, will need repeat ketones…" is not a worse sentence. It is an unfindable one at 2 a.m.
What has to be true for this to work
- Orders have a lifecycle, not a checkbox. A system that records "ABG ordered" and nothing else cannot tell the difference between a result that came back normal and a result that never came back at all.
- The handover composes itself from events, not from memory. Anything that depends on the outgoing doctor remembering to write it will be the first thing lost on the night it matters most, because the night it matters most is the night with the code in the next ward.
- The pending item survives the shift boundary. It has to belong to the patient, not to the doctor who ordered it — otherwise it walks out of the building at 8 a.m.
- The contingency travels with the result. "Alert if pH worsens" is what turns a number into an instruction. It is also, not coincidentally, the I-PASS element that decays first when handover is left to discipline rather than to structure.
The point
The point of writing this is not the heroism of catching it. The point is the automaticity of the catch. Nothing about the case required a hero. The handover had captured the pending lab because the system was holding the patient's state across the shift change. The receiving doctor noticed because the line was structured ("Pending: …"), not buried in free text.
This is what an automated handover looks like when it works: invisible until it's the thing that prevents the next mistake. There is no moment of drama, no save to write up, nothing to present at the morbidity meeting. There is just a patient whose gas got repeated at 3 a.m. instead of at 8, and a night that stayed boring.
Boring is the outcome. It is remarkably hard to build for, because it leaves no evidence behind.
Authors
Dr. Soumyadeep Adhikari, MBBS, MD
PGT General Medicine, RG Kar Medical College
MBBS from Calcutta Medical College. Currently a post-graduate trainee in General Medicine at RG Kar Medical College, Kolkata.
Alapan Mondal, B.Tech, M.Tech, IIT BBS
Founder, Medows
Founder of Medows. Building doctor-side AI workspaces.
Medows is a clinical AI workspace for the doctor on rounds. Learn more or write to alapan@medows.ai / alapanx@gmail.com.