Build vs. Buy: Why Health Systems Should Stop Reinventing the Wheel on Care Coordination
By Dr. Peter Tippett, Physician, CEO & Founder, careMESH
The Decision That Keeps Health System Leaders Up at Night
Every few years, a health system reaches a breaking point. The oncology navigation team is tracking patients in spreadsheets. The structural heart program is losing referrals from outside providers. The transplant coordinator is managing a caseload that has doubled in three years, still using sticky notes and email. A new VBC initiative, or HRRP penalty scheme, or discovery showing quality benefits from longitudinal initiatives surfaces….
Leadership convenes. Someone asks: Should we build something in our EHR or buy a solution?
I've sat on both sides of that table; first as a physician watching care coordination and many other longitudinal initiatives break down in real time, and now as a founder who has spent years building tools designed to prevent exactly that. I can tell you that the build-vs-buy debate in healthcare is rarely about capability. It's about time, risk, cost, quality, and where you want your best people focused.
The stakes are real. When coordination fails, patients fall through the cracks. Referrals stall. Time-to-treatment stretches. And the clinical and financial consequences compound quickly.
So let's work through this decision honestly.
"The question for health system leaders is not whether to integrate external tools, but how."
Understanding the Build Option: What It Actually Requires
The appeal of building internally is understandable. Your team knows your workflows. Your IT department knows your EHR. And there's a certain confidence that comes with owning the solution end to end.
But here's what the research consistently shows: nowadays, building is slower, more costly, less capable, harder to maintain, and is only the beginning. Just as with DIY in nearly every other case, self-built code in the EHR is much less robust and capable than mature solutions from quality 3rd parties.
The foundational argument now favors the EHR-as-platform. The idea that health systems could run third-party applications within their clinical workflows without the expense of custom integration was articulated over a decade ago, and the industry has been working toward that vision ever since. Now, FHIR, related HL7, and other interfaces are mature, reliable, and working at scale in nearly every EHR.
The problem is that most internal builds don't start from the EHR-as-platform model. They start from scratch or from clunky EHR primitives (like checklists), or from prior customization work within a proprietary EHR environment. Internal builds tend to be relatively simplistic, hard-coded, difficult to modify, maintain, and extend, and often fail. And they are often extraordinarily expensive.
A 2025 scoping review published in the Journal of Medical Internet Research identified four recurring cost categories in EHR-related development: compliance, collaboration, competence-building, and direct financial cost. Most hospitals report substantial financial challenges in EHR implementation and use, including implementation costs and the limited availability of grants and loans to support those efforts. And that's before you factor in the ongoing burden of maintenance, updates, extending the code to new use cases, and staff training/retraining.
The Six Decision Criteria That Actually Matter
Push past the surface-level question of "can we build it?" and toward six criteria that determine whether a build will actually succeed and which pathway truly has the stronger ROI.
1. Fit-for-Purpose
Is the EHR fundamentally designed to do the job? If the planned internal job is a simple configuration of an already-existing EHR function, or a few days of coding to add minor tweaks to already existing workflows, tools, or capabilities, then, of course, doing it in the EHR is the best decision.
But many other “asks” are actually out of scope for the EHR itself, even if extended with new code. For example, most care coordination/navigation/population management/VBC programs, and even inbound referral patient throughput programs, are fundamentally about longitudinal tracking, management, and measurement of a cohort of patients over the long term (weeks to years) through a workflow. They are about BOTH improving the patient tracking and improving the health system team’s work, efficiency, and throughput.
EHRs are fundamentally about episodic events and data management. Think about managing - as a group - a health system’s entire population of patients with Heart Failure, or cancer, or any other chronic disease to improve quality, hospital efficiency, and revenue. Or imagine tools that manage everyone who has positive results from a screening program, or figuring out what to do with the daily results of an AI tool that mines your current EHR data every day, and produces a list of patients (all with different doctors, some or many of whom don't work for your health system) who would benefit from a workup, an intervention, a drug change, or entry into a program. Popup EHR reminders and alerts to providers have always been a contentious experience and have long since been proven not to work. And what do you do about the outside doctors and care teams?
Some programs like those above need some of the data and data storage, login, and many of the other capabilities of the EHR, but also need new, extensive functionality, including new communication, with sophisticated code and capabilities—not with patchwork, piecemeal, DIY EHR coding.
2. Time-to-Value
How long can your patients (and revenue and efficiency improvements) wait? In oncology, every week between diagnosis and treatment initiation matters, clinically and emotionally. In structural heart, a delayed TAVR referral can mean a patient deteriorates before they ever reach the table -- not to mention lost or delayed high-margin revenue.
Internal builds take time. There is constant pressure to optimize EHRs, but pre-existing day-to-day pressures may limit the pace of implementation. Your IT team is already managing upgrades, security patches, and competing priorities. Adding a net-new care or team coordination function to that queue means months, often over a year, before clinical staff sees working capability -- and much longer before comprehensive capabilities emerge, if ever. A good 3rd-party solution, by contrast, can be configured and deployed in weeks or months, not quarters or years.
3. EHR Integration Complexity
This is where internal builds most frequently underestimate the challenge. Connecting a home-built tool to your EHR, pulling patient data, pushing tasks, and avoiding duplicate entries requires deep technical work against proprietary data structures.
Early EHR vendors were not receptive to third-party integration, and even as standards like HL7 FHIR emerged, implementation complexity led to incompatible systems and inconsistent data payloads. The SMART on FHIR framework was developed specifically to address this, creating a standards-based way for apps to connect to EHR systems with appropriate security guarantees, enabling substitutable applications that work across institutions rather than requiring custom builds at every site.
The practical implication: building internally creates repeated, custom effort at every organization, while standards-based apps can scale across multiple EHR environments. Every internal build reinvents the integration layer. Every 3rd party solution that runs on FHIR, HL7, and similar standards benefits from work that has already been done and validated across many other health systems.
4. Ongoing Maintenance Burden
Launching a tool is not the same as sustaining one. Clinical programs evolve. Regulatory requirements change. Staff turns over. Workflows need to be updated. Programs need to be modified, made more comprehensive, more capable, and more aligned with other processes.
Who owns that work after go-live? In most health systems, the answer is unclear, and that ambiguity is where internally built tools quietly die. Too often, they launch, provide minimal or acceptable functionality, work “ok” for 18 months, and then stagnate as clinical needs continue to evolve.
Another drawback of internally developed tools is that an internal department may not have the bandwidth to troubleshoot or update them frequently or quickly. Taking the same internally built tool and repurposing it for another department or use case is often harder than starting from scratch. A vendor whose entire business depends on keeping the product current, flexible, easy to use, and feature-rich doesn't have these problems.
5. Clinical Customization Needs
Here's where the "build here at our hospital" argument has its strongest internal supporters: clinical programs are not generic. An oncology navigation workflow looks nothing like a transplant coordination workflow. A structural heart program has distinct task sequences, external communication needs, and reporting requirements compared to a dialysis program or long-term tracking and programmatic intervention for thousands of patients with heart failure.
But customization and custom-built are not the same thing. If the underlying problem is universal and shared across health systems, an externally developed tool that has been validated elsewhere is likely to be better, more feature-rich, and easier to deploy than an internally developed one. The question isn't whether your program has unique needs. It's whether those needs are so unique that no 3rd-party solution has been designed to accommodate them.
In my experience, the answer almost always favors a serious evaluation of 3rd party software. The structure of complex care coordination, adaptive pathways, task sequencing, cross-team communication, and real-time metrics is consistent across programs. What varies is the clinical content inside that structure. A well-designed platform accommodates both.
6. Staff Bandwidth
This is the criterion that receives the least attention and often causes significant damage.
Building a care coordination tool requires clinical informatics expertise, project management, EHR development resources, and sustained clinical stakeholder engagement, all simultaneously, on top of existing operational responsibilities. The need for sufficiently trained personnel is felt at all stages of the implementation process, and untrained staff can hinder it.
Your navigators, coordinators, and program directors are already stretched. Asking them to co-design, test, and validate a new internal tool while continuing to manage patient caseloads is a recipe for burnout and a half-finished product.
By contrast, 3rd-party software developed by strong teams with strong clinical staff has full-time product managers, QA engineers, processes, implementation staff, support staff, and much more.
What the Data Says About Where Healthcare Is Already Heading
The EHR-native "build" versus third-party "buy" debate has already been partially resolved by the market, which has moved decisively toward buy-and-integrate.
In 2024, 9 in 10 hospitals enabled patient access to their health information via an API, and 7 in 10 did so via a standards-based API. More directly relevant to care coordination: in 2024, 9 in 10 hospitals integrated data from third-party technology into their EHR for at least one clinical purpose, and 83% of hospitals provided data from their EHR to third-party technology for at least one clinical purpose.
Third-party solutions are not "outside" the hospital environment. They are already embedded in it. The question is no longer whether to integrate external tools; it's which tools to integrate and how.
The national policy environment reinforces this direction. The 21st Century Cures Act requires that EHRs enable data to be accessed and exchanged without special effort through standardized APIs. ONC's Cures Act Final Rule finalized a new certification criterion requiring the implementation of standardized APIs for patient and population services. Since January 1, 2023, all certified EHR users have been required to have standardized FHIR APIs available to exchange information with authorized business partners.
The ecosystem has moved toward open, connected platforms rather than closed, custom-built systems. Health systems that build internally are swimming against a very strong current.
Introducing careMESH NAVIGATE: Built for the Decision Criteria That Matter
We didn't build NAVIGATE to compete with EHRs. We built it because EHRs, as powerful as they are, were never designed to manage the longitudinal, multi-step, multi-team complexity of highly specialized care and care team coordination. EHRs are built for the encounter. Navigation, coordination, disease surveillance, chronic disease management, and much more… are about everything that happens between encounters…. and are wired to also drive improved quality, better patient and care team member experience, and greater efficiency and revenue for the organization.
NAVIGATE is a care coordination, patient navigation, and care-team management platform that guides patients through personalized care pathways, from referral through treatment to long-term follow-up. It was designed from the ground up to delight every hospital stakeholder and to address every criterion in the build-vs-buy decision:
Time to value: Rapid implementation and configuration with total IT effort measured in hours, not quarters or years. Programs in oncology, structural heart, neurology, transplant, chronic disease management, and others can be up and running and productive in a month or two.
EHR integration: NAVIGATE gets data via APIs with any EHR and launches fully within Epic as a native Epic app. Either way, it pulls patient data directly, eliminating duplicate entries, while improving the care team’s productivity through ever-improving versions of the workflows they already use.
Maintenance: Configuration, updates, regulatory alignment, and product evolution are handled by careMESH, not your IT department.
Customization: Adaptive workflows are built around patient data and clinical program needs, not forced into a one-size-fits-all template.
Staff bandwidth: Implementation is designed to minimize burden on clinical staff, with configuration support from careMESH's team.
Communications: Significantly improved automation and reach to enable EHR-native, digital team-to-team communications abilities, providing a foundation that empowers everything else.
What NAVIGATE Delivers
Adaptive Patient Pathways: Individualized care plans built from EHR data or direct entry, with tasks that automatically activate, close, and reassign as patients move through the care journey, so no step is missed, and no patient falls through the cracks.
Intelligent, Dynamic Task Management: Sequenced worklists that surface overdue and urgent items first, providing ways for coordinators to assign entirely new tasks to themselves, or others, including leaders… giving navigators and coordinators a clear, prioritized view of what needs to happen today, across every patient in their panel.
Cross-Team and Cross-Organization Communication: Seamless messaging across departments and external organizations for discharge support, medical record requests, referrals, and screenings, and actual clinician-to-clinician coordination -- without leaving the EHR environment.
Real-Time Program Metrics: Live dashboards showing transition times, patient volumes by stage, and workload and performance data, giving program leaders the visibility they need to manage capacity, demonstrate outcomes, document efficiencies, and even new revenue.
Deep EHR Integration: Launches with or within the EHR, including a dedicated Epic app, with minimal duplicate data entry and no context switching. Clinicians work in one environment.
Rapid Customization Across Clinical Domains: Pre-built and configurable pathways for oncology, structural heart/interventional cardiology, neurology, transplant, AI, and screening program inputs, and others, with the flexibility to adapt to almost any program's specific clinical protocols.
Why This Matters for Care Teams and Program Leaders
The downstream impact of getting this decision right, choosing a 3rd party, EHR-integrated solution over a custom internal build, is measurable and meaningful.
A growing number of digital health tools are being built to directly connect to EHRs and use standards-based APIs such as FHIR, and it is integration into workflow, not ownership of the software, that drives clinical outcomes. The research is consistent on this point: tools that fit into existing clinical workflows get used. Tools that enable or require workarounds get abandoned.
For navigators, team coordinators, and staff members, NAVIGATE means a daily worklist that actually reflects clinical priority, not a spreadsheet that has to be manually updated. For program directors, it means real-time visibility into where patients are in the pathway, which tasks are overdue, and how the team's capacity is growing. For health system leaders, it means faster time to treatment, improved referral capture with reduced referral leakage, and other metrics that go straight to the bottom line, along with a platform that can scale across service lines without a new IT project for each one.
The adoption and implementation of digital health tools at an enterprise level are challenging; few enterprise-scale strategies exist to help successfully cross the gap from validation to operational deployment. NAVIGATE was designed to close that gap: clinically validated, EHR-integrated, and operationally deployable at scale.
The Bottom Line: Stop Reinventing the Wheel
I've watched health systems spend 18 months and significant capital on building tools with minimal capabilities that are already behind where the clinical program needs them to be. The world moved. The tool didn't.
The healthcare interoperability landscape has fundamentally changed. Standards such as FHIR and HL7, combined with national policy mandates under the 21st Century Cures Act, have enabled 3rd party solutions to integrate deeply into EHR environments, not as bolt-ons but as embedded clinical tools. The vision of EHR-as-platform, where third-party applications run within clinical workflows without expensive custom integration, is no longer theoretical; it is the direction the entire industry has committed to.
The question for health system leaders is not whether to integrate external tools, but how. It's a choice between spending the next two years building something that already exists or deploying a proven solution and redirecting that energy toward what actually moves the needle: quality patient care, delighted staff, improved throughput, efficiency, and potentially even revenue.
Your coordinators, nurses, and navigators didn't go into healthcare to manage spreadsheets. Your program directors didn't build specialty programs to spend their time in IT governance meetings. And your patients can't afford to wait while your team reinvents the wheel.
Now is the right time to buy smart, integrate deeply, and focus your people on what they do best.
References
Mandel JC, et al. SMART on FHIR: a standards-based, interoperable apps platform for electronic health records. Journal of the American Medical Informatics Association.https://academic.oup.com/jamia/article/23/5/899/2379865
Journal of Medical Internet Research. Electronic Health Record Implementation: A Scoping Review (2025).https://www.jmir.org/2025/1/e60077
Barker W, Johnson C. Clinical and implementation characteristics of real-world FHIR apps.https://pmc.ncbi.nlm.nih.gov/articles/PMC9555876/
Marwaha JS, et al. Deployment of digital health tools within large health systems. npj Digital Medicine.https://www.nature.com/articles/s41746-022-00557-1
Office of the National Coordinator for Health IT. Hospital Use of APIs to Enable Data Sharing Between EHRs and Third-Party Technology.https://www.healthit.gov/data/data-briefs/hospital-use-of-apis-to-enable-data-sharing-between-ehrs-and-third-party-technology
ONC Interoperability & 21st Century Cures Act Resources.https://www.healthit.gov/interoperability/
Journal of Medical Systems. EHR-Integrated Digital Technologies and Clinical Outcomes (2024).https://link.springer.com/article/10.1007/s10916-024-02097-5
Marwaha JS, et al. Enterprise adoption and implementation of digital health tools. npj Digital Medicine.https://www.nature.com/articles/s41746-022-00557-1
Contact careMESH today to learn how careMESH can accelerate your product's interoperability strategy.
