In the Marine Corps, we had a concept called "commander's intent." Before any operation, the commanding officer would state the mission's purpose in plain language so that every Marine, from the squad leader to the rifleman, understood what success looked like. If the plan fell apart on contact, the intent remained. Everyone could adapt because everyone knew the objective.
Healthcare providers need to bring that same clarity to their software development engagements. Because right now, the industry's track record suggests that most don't. Studies indicate that failure rates for electronic health record system adoption range between 50% and 70% across different healthcare settings [1]. Research published in Procedia Computer Science puts the broader healthcare IT project failure rate at up to 70% when accounting for delays, cost overruns, and failure to meet stated goals [2]. And the U.S. federal government has invested over $25 billion in EHR adoption through the HITECH Act, an investment that risks being wasted without addressing the barriers to successful implementation [3].
These are not technology problems. They are accountability problems. Here is what providers should be demanding from the teams building their software.
Demand Clinician Involvement From Day One
The single most cited cause of healthcare IT failure is building systems that clinicians either cannot or will not use. Stanford University research found that 74% of clinicians reported increased work hours after EHR implementation, with 71% attributing burnout to the EHR itself [2]. A 2023 HIMSS survey found that 48% of clinicians said EHR systems slowed their tasks due to poor workflow fit [4]. And when Cedars-Sinai Medical Center launched a new computerized physician order entry system with a mandate that doctors learn it in a single day or lose admitting privileges, the resulting physician revolt became a cautionary tale for the entire industry [5].
These outcomes are predictable when the development team treats clinical input as a nice-to-have rather than a structural requirement. Robert Wood Johnson University Hospital experienced a disastrous EHR implementation precisely because front-line nursing staff were not included in the planning process [6]. NYC Health + Hospitals delayed the next phase of its $764 million Epic rollout after a rushed implementation that prioritized deadlines over patient safety drew public backlash [6].
What to demand: your development team should include a clinician champion in the planning process from the project's first week, not its last. Clinical workflows must be mapped by the people who actually perform them before any code is written. If your dev team is building clinical software without regular access to clinicians, they are guessing. And in healthcare, guessing costs lives.
Demand Architectural Security, Not Cosmetic Security
The 2024 HIMSS Healthcare Cybersecurity Survey found that 55% of organizations increased their cybersecurity budgets, but only 34% reported significant increases to security staff [7]. The Change Healthcare ransomware attack, which exposed the data of 190 million Americans and is projected to cost over $2.4 billion, succeeded because a critical system lacked multi-factor authentication [8]. That is not a sophisticated attack vector. That is a basic configuration failure.
Healthcare providers should not accept software that treats security as a presentation layer concern. Hiding a button in the user interface is not access control. If protected health information is accessible via an unauthenticated API call, the system has failed regardless of what the frontend shows.
What to demand: Row-Level Security enforced at the database layer, not the application layer. Encrypted data at rest and in transit using AES-256 and TLS 1.2 or higher. Audit logging on every operation that touches protected health information. Multi-factor authentication on all administrative and clinical access points. And a Business Associate Agreement with every third-party service that handles patient data. If your dev team cannot explain their security architecture in concrete technical terms, they do not have one.
Demand Realistic Timelines With Contractual Accountability
NYC Health + Hospitals' experience is instructive: when implementation timelines prioritize arbitrary deadlines over real-world conditions, the result is not just a bad rollout but potential patient harm [6]. Healthcare software is not a marketing website. It operates in a regulated environment where errors have clinical consequences, and it must integrate with existing systems that are often decades old.
The Guidehouse and HFMA survey of 144 provider executives found that digital and IT budgets increased by an average of 18.3% from 2019 to 2023, with one in five citing increases of more than 30% [9]. That spending is justified only if the outcomes match. Yet the industry's 50-70% failure rate suggests that much of it is wasted on projects that are scoped too aggressively, staffed too thinly, or managed without adequate oversight.
What to demand: milestone-based contracts with deliverables tied to functional demonstrations, not just code commits. Phased rollouts that allow problems to surface and be resolved before expanding to additional departments. Post-launch support agreements that extend at least 90 days beyond go-live, because that is when the real usability issues emerge. And penalty clauses for missed deadlines and unresolved defects, because accountability without consequences is just a suggestion.
Demand Interoperability as a Core Requirement
ONC data from 2023 shows that while 70% of hospitals engaged in interoperable exchange at least sometimes, significant gaps remain: 8% of hospitals did not send electronic health information, 18% could not find it, 14% could not receive it, and 22% could not integrate it [10]. These numbers represent broken handoffs in patient care.
The 21st Century Cures Act mandated that health IT developers adopt standards-based APIs, specifically FHIR (Fast Healthcare Interoperability Resources), to enable patients and providers to access and exchange health information [11]. But mandating a standard and implementing it correctly are different things. If your patient portal cannot exchange data with the hospital's EHR, or your scheduling system cannot communicate with the billing platform, you have purchased expensive islands of disconnected functionality.
What to demand: HL7 FHIR compliance for all data exchange interfaces. Demonstrated integration testing with your existing EHR, lab, pharmacy, and billing systems before go-live, not after. API documentation that your internal IT team can evaluate independently. And explicit contractual language that defines interoperability requirements with specific systems, not vague promises of "industry-standard compatibility."
Demand Transparent Testing and Documentation
The FDA's analysis of 3,140 medical device recalls between 1992 and 1998 found that 242 (7.7%) were attributable to software failures, and of those, 192 (79%) were caused by defects introduced when changes were made after initial production [12]. Software is not static. Every update, patch, and feature addition introduces the potential for regression. Without rigorous testing and documentation, the risk compounds with every release.
Healthcare software maintenance alone may constitute 70-80% of total development costs [13]. If your development team does not maintain clear documentation of the system architecture, change logs, and test coverage, you are locked into a dependency where only the original team can modify the software. And when that team becomes unavailable, or the relationship deteriorates, you inherit a system you cannot safely maintain.
What to demand: automated test suites that run before every deployment. Staging environments where updates are validated before reaching production. Comprehensive technical documentation that would allow a qualified third-party team to take over maintenance. And regular security audits conducted by an independent party, not just the team that built the system.
The Standard Should Be Higher
Healthcare providers are not buying commodity software. They are buying systems that handle protected health information, support clinical decisions, and directly affect patient outcomes. The fact that 50-70% of these projects fail is not a technology limitation. It is a failure of the procurement process to demand the engineering discipline that healthcare requires.
At Kortex Digital Labs, we build healthcare platforms the way the military builds mission systems: with documented requirements, phased delivery, security at every layer, and accountability at every milestone. Because when the software you build handles someone's medical records, "it mostly works" is not a standard. Zero defects is the standard.
Kortex Digital Labs builds HIPAA-compliant healthcare platforms with military-precision engineering. Start a project to discuss your requirements.
References
[1] Frontiers in Medicine, "Barriers to the Implementation of Large-Scale Electronic Health Record Systems in Primary Healthcare Centers: A Mixed-Methods Study," Frontiers in Medicine, vol. 12, Mar. 2025, doi: 10.3389/fmed.2025.1516714. [Online]. Available: https://www.frontiersin.org/journals/medicine/articles/10.3389/fmed.2025.1516714/full
[2] EHR in Practice, "10 EHR Failure Statistics: Why You Need to Get It Right First Time," 2024. [Online]. Available: https://www.ehrinpractice.com/ehr-failure-statistics.html
[3] U.S. Department of Health and Human Services, "Adoption of Electronic Health Records and Barriers," PMC, 2016, doi: 10.5811/westjem.2016.7.30710. [Online]. Available: https://pmc.ncbi.nlm.nih.gov/articles/PMC5089148/
[4] HelpSquad, "Overcoming EHR Implementation Challenges: A 2025 Comprehensive Guide," Oct. 2025. [Online]. Available: https://helpsquad.com/blog/overcoming-ehr-implementation-challenges/
[5] LinkedIn / Venice Group Consulting, "5 Healthcare Software Development Fails and What We Can Learn From Them," 2018. [Online]. Available: https://www.linkedin.com/pulse/5-healthcare-software-development-fails-what-we-can-jake-ryan
[6] EHR in Practice, "How to Turn Around an EHR Disaster: Three Case Studies," 2024. [Online]. Available: https://www.ehrinpractice.com/ehr-failure-case-studies.html
[7] Chief Healthcare Executive, "Some Hospitals Are Spending More on Cybersecurity, But Not Always on Staff," HIMSS 2025, Dec. 2025. [Online]. Available: https://www.chiefhealthcareexecutive.com/view/some-hospitals-are-spending-more-on-cybersecurity-but-not-always-on-staff-himss-2025
[8] IANS Research and Artico Search, "2025 Compensation and Budget for CISOs in Healthcare Benchmark Report," IANS Research, Mar. 2025. [Online]. Available: https://www.iansresearch.com/resources/all-blogs/post/security-blog/2025/03/27/healthcare-security-comp-and-budgets-decline--access-key-report-data-and-trends
[9] Healthcare IT News, "Providers Report Significant IT Budget Increases for 2024," Healthcare IT News, 2024. [Online]. Available: https://www.healthcareitnews.com/news/providers-report-significant-it-budget-increases-2024
[10] Office of the National Coordinator for Health IT, "ONC Data Brief No. 71: Interoperable Exchange of Patient Health Information Among U.S. Hospitals: 2023," May 2024. [Online]. Available: https://www.ahadata.com/system/files/media/file/2024/06/ONC-Brief-Interoperable-Exchange-of-Patient-Health-Information-Among-US-Hospitals-2023.pdf
[11] U.S. Congress, "H.R. 34, 21st Century Cures Act," Congress.gov, 2016. [Online]. Available: https://www.congress.gov/bill/114th-congress/house-bill/34
[12] PMC, "Healthcare Software Assurance," Biomedical Instrumentation & Technology, 2007. [Online]. Available: https://pmc.ncbi.nlm.nih.gov/articles/PMC1839424/
[13] PMC, "Assessing the Impact of Software Quality Models in Healthcare Software Systems," PeerJ Computer Science, 2023, doi: 10.7717/peerj-cs.1258. [Online]. Available: https://pmc.ncbi.nlm.nih.gov/articles/PMC10013535/