I learned to fly as a teenager. Before every flight, no matter how many times I had done it before, I walked the aircraft. I ran my hand along the propeller, feeling for nicks. I moved down each wing and checked the tail. I drained a small sample of fuel from the sump, held it up to the light to check for water contamination, then tossed it on the ground and moved on. Nobody required it of me in that moment. But my instructor had made one thing clear early: the habit is the discipline. You do not skip it because nothing went wrong last time. You do it because you respect what is at stake.
That lesson stayed with me through 25 years as an EMT and first responder. It shapes how I think about the technology I build today.
What I learned on that tarmac was not caution. It was readiness. There is a difference — and understanding that difference is what this article is about.
Healthcare is one of the most important and most complex environments human beings have ever tried to serve with software. The people who work in it — clinicians, coordinators, case managers, crisis responders — carry enormous responsibility, often with inadequate tools and not enough time. When we build technology for them, we are not shipping a feature. We are entering a clinical environment. That deserves a different kind of care than most development cultures currently give it.
And yet the dominant development culture our industry has inherited was not built for this environment. It was built for somewhere else entirely.
This is not a criticism of the people building healthcare technology. Most of them are talented, motivated, and genuinely trying to help. It is an observation about the framework many of us have inherited — and a proposal for a better one.
The habit is the discipline. You do not skip the walk-around because nothing went wrong last time. You do it because you respect what is at stake.
Two Phases, Two Different Standards
There is real value in the "move fast and break things" stage of development. Discovery, experimentation, proof-of-concept work — this is where creative risk-taking belongs. Build boldly. Test assumptions fast. Break things in controlled environments where the cost is learning time rather than patient outcomes. That energy is essential and should be protected.
But there is a line between that exploratory phase and the moment real people begin relying on what you have built. The moment a patient, a clinician, or a care coordinator touches your product in a live environment, you have crossed into different territory. You are no longer running an experiment. You are operating a system that carries real obligations — legal, ethical, and clinical.
The startup community has a useful shorthand for the product that bridges these phases: the Minimum Viable Product, or MVP. But somewhere along the way the most important word in that phrase got quietly set aside. Not minimum. Not product. Viable. A viable product is one that is genuinely ready for real-world use. In healthcare, that means it is secure, reliable, compliant with applicable regulations, honest about its limitations, and — most fundamentally — it does not introduce risk into the clinical environment it is meant to support.
Minimum viable is not minimum complete. It is minimum ready.
What the Evidence Shows Us
A note before the examples below: I have intentionally kept specific organization names out of the body of this article and placed them in the references section. That is a deliberate choice. The failures described here did not occur because the people involved lacked skill or commitment. They occurred because of systemic pressures — compressed timelines, scope that outpaced resources, and the very human difficulty of pausing when momentum is high. Those pressures exist in every organization, including mine. The purpose of citing these cases is to learn from the pattern, not to assign blame.
With that said, the evidence is important to understand.
One of the largest government healthcare technology programs in recent history — a federal EHR modernization initiative representing a $16 billion contract — became an unintended case study in what happens when deployment outpaces verification.[1] A software defect caused more than 11,000 orders for specialty care, lab work, and medical services to be silently routed to an undetectable location — disappearing from clinician view without any indication they had not been delivered.[2] A scheduling error in the same system was later linked by federal investigators to the death of a patient who missed an appointment and never received outreach to reschedule.[3]
I have been on the other end of that gap. As a first responder and a crisis line volunteer, I have seen what happens when the follow-up does not come — when someone needed the system to notice them and it did not. A missed appointment is not an administrative error. For some patients, it is the last opportunity the system had to reach them. When software fails to close that loop, the consequences are not logged in a bug report. They show up somewhere else entirely.
By the time the program was paused for reassessment, at least five patient deaths had been acknowledged, more than 150 documented cases of harm had been recorded, and over 70,000 patients had been exposed to potential harm.[4] Clinician productivity at affected facilities dropped by as much as 50%. In a user survey at one hospital, only 4% of clinicians reported that the system kept their patients safe — and 71% reported significant stress from having to use it.[4]
Between launch and early 2024, the system experienced 826 major performance incidents — outages, degradations, and incomplete functionality — totaling nearly 80 days of impaired operation.[5] The program's original contract value has since grown by estimates reaching an additional $34 billion, with years of additional timeline.[4]
These are not the outcomes anyone intended. They are the outcomes of a system that moved into production before the checklist was complete.
The broader numbers tell a similar story. Medication errors linked to healthcare IT compliance failures harm an estimated 1.5 million people annually in the United States at a cost of approximately $77 billion.[6] Studies examining healthcare IT failures broadly have found that software and system problems contribute to patient harm in 53% of reviewed cases.[6]
For historical perspective: software errors in a radiation therapy system in the 1980s caused multiple patient deaths through massive overdoses before the problem was identified.[7] That case has been taught in software engineering ethics programs for four decades. The lesson it carries — that removing hardware safeguards in favor of inadequately tested software controls is not progress, it is unverified risk transfer — remains directly applicable to decisions being made in healthcare technology today.
These were not failures of intent. They were failures of verification — what happens when the pressure to move forward becomes louder than the discipline to confirm you are ready.
If the Scope Is Too Large to Build Correctly, Reduce the Scope
This is the principle I have come to believe most deeply, and it is the one I apply most consistently in my own work: if the scope of a product cannot be executed correctly with the resources and skills currently available, the right response is not to proceed anyway. It is to build less — and build it right.
A smaller product built with integrity delivers more value than a larger product built under pressure. In healthcare this is not merely a quality preference. It is an obligation to the people the product is meant to serve.
Reducing scope is not retreat. It is the discipline of matching what you promise to what you can actually deliver. That discipline is particularly important in regulated environments — Medicare Advantage, behavioral health, any clinical setting where the consequences of system failure extend beyond inconvenience. You do not get a graceful rollback in a clinical workflow. You do not easily rebuild trust with a health system that experienced a failure on your platform.
The builders I have the most respect for in this space are the ones who have had the courage to say: we are not ready for this yet. That is a harder decision than it sounds when timelines are visible and expectations are set. But it is the decision that protects patients, protects the organization, and ultimately protects the mission.
A Practical Checklist
Before any real-world deployment in a healthcare context, I apply a straightforward set of questions — not as a formality, but as a genuine gate:
- Have we tested the failure modes, not just the expected path?
- Does the team have the skills to support this at the quality level it demands?
- Are regulatory and compliance requirements met — not approximated, not deferred?
- Is the scope honest about what this product can reliably deliver right now?
- If something breaks in production, do we have a tested, documented recovery path?
If the honest answer to any of these is no, the checklist is doing exactly what it is supposed to do: it is telling you not to fly today. Reduce the scope until every answer is yes. Then ship.
The outcome that consistently surprises people is that this approach tends to be faster in total elapsed time. When the rigor happens before deployment rather than during remediation, the full development arc compresses. The front-loaded discipline is not what slows programs down — it is what makes them sustainable.
The Model and Its Own Hard Lessons
I have built this entire argument on an aviation analogy, and I want to address that honestly — because aviation has had its own catastrophic failures, and anyone familiar with them deserves to see that acknowledged directly.
The most instructive failures in aviation are not the random mechanical events. They are the ones where commercial pressure, compressed timelines, and organizational dynamics caused the discipline to be bypassed.[8] A software system was deployed on a widely-used commercial aircraft to compensate for a flight handling change introduced by a new engine configuration. The system's existence was not prominently disclosed to pilots. Training was abbreviated. Two catastrophic crashes followed, killing 346 people. Investigators found that schedule pressure and competitive dynamics had influenced certification decisions in ways that compromised the very verification process the industry depends on.
I include this not to undermine the model but to complete it. The lesson from that tragedy is not that checklists fail. It is that checklists only work when the organizational culture genuinely protects them from the pressure to move faster than verification allows. When that culture erodes — in aviation, in healthcare, in any high-stakes domain — the consequences are not theoretical.
Aviation's strength is not that it has been perfect. It is that it has treated every failure as curriculum. Each tragedy produced a more rigorous protocol, a better simulation, a clearer line of accountability. The discipline deepened under pressure rather than collapsing beneath it. That is what a genuine safety culture looks like — and it is exactly what healthcare technology needs to build now, before the pressure to scale makes it harder to establish.
A Note on Innovation
I want to be clear about something, because the argument above can be misread as a case for caution over progress. It is not.
Healthcare desperately needs innovation. Patients need better tools. Clinicians need systems that actually support their work rather than adding to it. The current gaps in care coordination, outcome monitoring, and crisis response are real and consequential, and closing them requires builders who are willing to do hard things.
The discipline described in this article is not the enemy of that ambition. It is what makes the ambition trustworthy. The walk-around before every flight was never about doubt. It was about respect — for the aircraft, for the conditions, for the people who would be aboard. Nobody who has ever truly wanted to fly resents the pre-flight check. They understand that it is what makes the flight possible. That is the posture healthcare technology needs to adopt. Not hesitation. Readiness. The products that will matter most in this space — the ones that earn lasting trust from health systems, payers, and patients — will be the ones built by people who did the walk-around first.
References & Notes
Organization and program names have been placed in references rather than the article body. These cases are cited to illustrate systemic patterns that can arise in any program where deployment pressure outpaces verification discipline — the intent is to learn from them, not to assign fault.
[1]
The program referenced is the U.S. Department of Veterans Affairs Electronic Health Record Modernization (EHRM) initiative, a $16 billion contract awarded to Oracle Cerner (now Oracle Health) in 2018 to replace the VA's legacy VistA system. The contract value has since been estimated to potentially reach $50 billion with years of additional schedule. Source: Federal News Network; VA Office of Inspector General reports, 2022–2024.
[2]
VA Office of Inspector General inspection report on Mann-Grandstaff VA Medical Center, Spokane, Washington, 2022. The OIG found more than 11,000 orders routed to an unknown queue without clinician notification. Source: VA OIG; Fierce Healthcare, July 2022.
[3]
VA Office of Inspector General report, March 2024. A scheduling system error at VA Central Ohio Healthcare System was linked to a missed appointment and subsequent patient death. Senator Richard Blumenthal disclosed six incidents of catastrophic harm, including four deaths, at a Senate Veterans Affairs Committee hearing in March 2023. Source: FedScoop, March 2024.
[4]
At least five acknowledged veteran deaths, 150+ documented harm cases, and 70,000+ patients exposed to potential harm are attributed to the EHRM rollout. Clinician productivity fell up to 50% at affected facilities. In a June 2023 user survey at Columbus, Ohio VA Medical Center, only 4% of clinicians felt the system kept patients safe and 71% reported significant stress using it. Estimated completion cost: $50 billion; estimated additional timeline: six years from 2024. Source: Federal News Network commentary, May 2024; VA OIG reports.
[5]
826 major performance incidents between October 2020 and March 2024, totaling approximately 1,909 hours (nearly 80 days) of impaired operation. 447 of these incidents occurred after the VA had already paused future go-lives. Source: VA Office of Inspector General; Federal News Network, September 2024.
[6]
Medication errors linked to healthcare IT compliance failures harm approximately 1.5 million people annually in the U.S. at an estimated cost of $77 billion. Healthcare IT problems have been linked to patient harm in 53% of reviewed cases. Source: Censinet, citing WHO and Ponemon Institute data; PMC/NCBI digital health malpractice risk review, 2022.
[7]
The Therac-25 radiation therapy machine (manufactured by Atomic Energy of Canada Limited) caused at least six documented radiation overdose incidents between 1985 and 1987, resulting in patient deaths and serious injuries. The failures were caused by race conditions and the removal of hardware safety interlocks in favor of inadequately tested software controls. It remains one of the most studied cases in software engineering ethics. Source: Leveson & Turner, IEEE Computer, 1993; DeviceLab, 2024.
[8]
The Boeing 737 MAX was involved in two fatal crashes — Lion Air Flight 610 in October 2018 and Ethiopian Airlines Flight 302 in March 2019 — killing 346 people. Investigations found that a flight control software system (MCAS) was deployed without adequate pilot notification or training, and that schedule pressure and competitive dynamics influenced the certification process. The 737 MAX was grounded globally for 20 months. Source: U.S. House Committee on Transportation and Infrastructure final report, September 2020; NTSB and international investigation reports.
