It Looks Like Procurement. It Is Architecture.
A decision framework for choosing between custom integration builds, licensed platforms, and managed integration services in healthcare.
Every healthcare integration strategy reaches the same question: should we build the integration ourselves, buy a platform, or rent a managed service?
It sounds like procurement. Compare products, review pricing, choose a vendor. But the real decision is architectural. You are deciding how much of your interoperability infrastructure you want to own, operate, maintain, and change over the next 3 to 5 years.
The cost of a bad decision rarely appears at go-live. It shows up later, when another EHR needs to be connected, an implementation guide changes, transaction volume increases, or the engineer who built the integration is no longer there.
FHIR has also changed the baseline. By 2024, about 9 in 10 U.S. hospitals enabled patient access to data through an API, and roughly 7 in 10 used standards-based FHIR APIs. FHIR R4 and US Core are now part of the expected interoperability stack. The differentiator is increasingly how well an organization can operate and evolve those connections.
The Three Models
Build: It means you own the code and the operational responsibility. That may include custom FHIR clients for individual EHRs, SMART-on-FHIR authorization, ETL pipelines, mappings, hosting, monitoring, and ongoing maintenance. You own the IP, but you also own upgrades, regression testing, certificate renewals, and production incidents.
Buy: It means licensing a FHIR-capable platform or integration engine and operating it yourself. It can accelerate infrastructure setup, but buying the platform does not automatically mean buying finished integrations. Your team still configures, builds, tests, monitors, and maintains the connections.
Rent: It means using a managed integration service, health data network, or integration-as-a-service model. The provider runs much of the plumbing, giving you speed and reach while reducing operational burden. The tradeoff is less control and greater dependence on the provider’s roadmap, pricing, and environment for handling PHI.
The important nuance is that the categories are not fixed. A self-hosted FHIR server may function as a build. A commercial platform deployed in your environment is a buy. The same platform operated for you becomes closer to rent. The underlying decision is how much of the integration stack you are willing to be accountable for.
The License Is Not the Cost
Healthcare organizations often compare the most visible numbers: license price, implementation fees, or the initial build estimate. Those figures matter, but they do not capture the full economics.
Custom software can carry roughly 20% of build costs annually in maintenance. Healthcare integration tends to sit toward the heavier end because connections are not finished when they go live.
EHR vendors release upgrades. OAuth scopes and endpoints can change. Certificates expire. Profiles and implementation guides evolve. Each change can trigger regression testing against live clinical workflows.
The cost also appears differently across the three models.
With build, the burden is people and operations: FHIR engineering expertise, endpoint-specific development, authentication, hosting, security, compliance, monitoring, and on-call support. There is also an opportunity cost when engineers maintain plumbing instead of product capabilities.
With buy, costs move toward platform licensing, connection fees, implementation work, upgrades, and the internal staff required to build and operate integrations on top of the platform.
With rent, economics can become variable. Per-query, per-message, egress, overage, or subscription charges may work well at lower volumes and become less attractive as usage grows.
Evaluate what it costs to operate and change, not only what it costs to launch.
Every Model Creates Technical Debt
Build Creates Custom-code Debt
Point-to-point links can become brittle, mappings can become difficult to understand, and critical knowledge may remain with individual engineers. When those people leave, the risk becomes a continuity problem.
Buy Creates Dependency Debt
Transformation logic may take on proprietary forms. Upgrades can be disruptive, configurations can spread, and teams may still accumulate connection debt inside the platform.
Rent Creates Coupling Debt
Your integration capability depends on another organization’s API, data model, availability, pricing, and roadmap. The provider’s outage becomes your operational issue, and leaving can require a costly migration.
All three models face another structural risk: point-to-point sprawl.
As systems multiply, the number of potential connections rises rapidly. Without an abstraction layer, the environment becomes difficult to govern and maintain.
A canonical data model can counter that problem. Instead of creating a unique mapping for every system pair, each source is normalized into a governed representation that downstream systems can consume.
Use the Year-Three Test
The most useful question is not, “What is cheapest to launch?” It is, “What will be cheapest to change three years from now?”
Consider three common events:
1. Add a second EHRA
A custom build may mean another major integration project unless reusable patterns and templates already exist. A commercial platform can accelerate the work when a connector is available. A managed service may be fastest, but ongoing usage costs become part of the decision.
2. Multiply transaction volume by ten
A build can scale on infrastructure you control, while a purchased platform may move you into a different license tier. A managed service may scale easily, but its transaction economics need to be modeled at the new volume.
3. Absorb a new implementation guide.
With build, your team owns the profile and delivery schedule. With buy, you depend on the vendor’s support and release cycle. With rent, the provider may absorb the change if it is within scope, but compliance responsibility still remains with you.
This is also why regulatory change belongs in the architecture conversation.
CMS-0057-F requires impacted payers to implement Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization FHIR APIs, with operational requirements beginning January 1, 2026 and API build requirements due January 1, 2027.
The rule relies on Da Vinci prior authorization guides including CRD, DTR, and PAS.
The lesson is that healthcare standards evolve continuously. Your integration model has to absorb that change without creating a new architecture crisis every time a profile or mandate moves.
The tradeoffs become clearer when the three models are compared across the factors that matter after go-live.
| Dimension | Build | Buy | Rent |
|---|---|---|---|
| Initial cost | High, front-loaded in engineering | Medium, license plus implementation | Low to start, subscription |
| Time to value | Slowest | Moderate | Fastest |
| Engineering burden | Highest and permanent | Moderate, you still build connections | Lowest |
| Operational burden | You run it around the clock | You operate the platform | Provider operates it |
| Control | Full | High, within platform limits | Limited to provider roadmap |
| Scalability | Scales on your infrastructure and effort | Scales by license tier | Scales on a meter |
| Standards evolution | You implement each profile on the deadline | You wait for a vendor upgrade | Vendor absorbs it, if in scope |
| Vendor dependency | None, you are the vendor | Platform lock-in | High, including pricing and continuity |
| Data governance | PHI stays fully yours | Yours if self-hosted | PHI often transits provider cloud |
| Technical debt | Custom-code and key-person | Proprietary config and version lag | Coupling and migration |
| Long-term change cost | Low only if well-architected | Medium, lock-in raises exit cost | Change means migrate off |
Build, Buy, Rent, or All Three
There is no reason an enterprise has to choose one model for every integration.
Mature architectures are often hybrid. Buy the platform and build only the logic that differentiates the product. Rent network reach when connecting to many organizations is the real challenge.
Keep strategic data flows under your own governance while using managed services for commodity connectivity.
Deploy infrastructure inside your own VPC when PHI residency and control require it, while using managed operations to reduce internal burden.
The key is coordination. A hybrid architecture without a canonical model can recreate the same point-to-point complexity across multiple vendors. The glue matters as much as the components.
A Practical Decision Framework
Before choosing a model, evaluate each integration across six dimensions: strategic differentiation, internal capability, time-to-value, three-to-five-year TCO, control and governance, and change agility.
| Dimension | What to assess | Points toward Build | Points toward Buy / Rent |
|---|---|---|---|
| Strategic differentiation | Is this integration core IP you sell, or plumbing under the product? | Core IP favors build | Plumbing favors buy or rent |
| Internal capability | Do you have, and can you retain, FHIR engineers with succession and docs? | Deep bench enables build | Thin team favors rent |
| Time-to-value | How fast must you be live? | Long horizon tolerates build | Urgency favors buy or rent |
| True 3-5 year TCO | Maintenance, upgrades, and change, not license price | Amortizes at scale | Watch rent’s meter at scale |
| Control and governance | Customization, IP ownership, PHI residency | Non-negotiable residency favors build or VPC | Residency risk in rent |
| Change agility and scale | Cost to add endpoints and absorb new profiles | Build only if well-architected | Rent adds fast, costs to run |
- Build when the integration itself is a strategic capability or part of the product, and you have the engineering depth to support it over time.
- Buy when the integrations are relatively standard, especially around FHIR, and you want to avoid rebuilding common infrastructure while retaining operational control.
- Rent when speed, network reach, or limited internal engineering capacity matters more than ownership, and the provider’s roadmap and economics fit the use case.
- Prefer ownership or VPC deployment when PHI residency, governance, or control are non-negotiable.
Do not build what you cannot explain how you will maintain in year three.
And when the same integration must be delivered repeatedly, templatize it or put a platform underneath it. Repeating bespoke integration work is rarely scalable.
The Question Healthcare Leaders Should Ask
The question is not, “Which integration product should we buy?”
Ask instead: which parts of our interoperability architecture should we own, which should we operate, and which should we hand to someone else?
That shift puts total cost of ownership, technical debt, data governance, standards evolution, and the cost of change on the table before a contract is signed.
In reality, the answer may span the full spectrum: custom FHIR development where integration is the differentiator, a FHIR-native platform where ownership matters but a from-scratch build does not make sense, managed operations where operational capacity is the constraint, and a canonical data layer underneath all of it.
Pegasus One’s Segue platform is positioned around that hybrid model, combining ownership, VPC deployment, and an optional managed operating model. The broader principle: architecture should determine the tool, not the other way around.
Conclusion
Build, buy, and rent are different ways of allocating ownership, operational responsibility, cost, and risk.
Maintenance, staffing, upgrades, standards changes, scalability, data governance, and migration costs determine what the decision looks like over time.
The real question is this: how much of your interoperability architecture do you want to own, how much operational weight are you willing to carry, and what will it cost to change course when healthcare standards move again?
Make that decision one data flow at a time, and the right technology choice becomes much easier to see.
Not sure whether to build, buy, or rent?
There is no one-size-fits-all approach to healthcare integration. We help you simplify interoperability, evaluate integration options, and build a scalable strategy. Connect with us today.