Build or buy EHR and PM integrations: a decision guide
Your first customer runs athenaOne. Your second runs eClinicalWorks. Your third asks for Epic and a payer portal. Each one wants the same patient list, the same eligibility result and the same remit in your product. The question lands on the engineering lead: build each connector, or pay someone who already did. This post lays out the work in each connector, the maintenance that follows, the partner program costs that vendors publish, and the cases where building is the right call.
What one connector contains
A connector has more parts than the HTTP client. For a certified FHIR API the list is: app registration with the vendor, OAuth 2.0 with the vendor's token endpoint, a mapping from the vendor's resources to your schema, paging and rate-limit handling, a test suite against the vendor sandbox, and a production enablement step per customer.
The last step is per customer, not per vendor. athenahealth's onboarding guide says production credentials are granted automatically for certified-only apps, but an athenaOne customer must enable the application in their practice settings before your credentials can read that practice. Oracle Health's FAQ says the vendor validates an application at each customer site for hospital-specific considerations, and that rate limits vary between customers based on agreed usage levels.
For a practice management system without a certified API, or for a payer portal, add a browser automation layer, a login state machine, a second-factor flow and a page-change detector. That layer is larger than the FHIR client and changes more often.
No vendor publishes an engineer-hour figure for this work, so this post gives none. Count the items above for each system on your roadmap and estimate from your own team's history.
The maintenance load
Vendors change their APIs on a schedule you do not control. athenahealth releases bug fixes and minor enhancements every two weeks, with production releases on Fridays and Preview releases on Saturdays. Its release notes mark some entries "This is a breaking change" and set a deadline for breaking-change testing before each large release.
Oracle Health retired its FHIR DSTU2 APIs. The announcement was June 3, 2024, new DSTU2 registrations ended September 3, 2025, and the deprecation date was December 1, 2025. Every app on DSTU2 had to move to R4 inside that window.
Portals change without release notes. Availity stopped new SMS and voice enrollments for multi-factor authentication on June 14, 2025 and moved users to authenticator apps. A connector that typed an SMS code stopped working on that date.
Multiply the release cadence by the number of connectors. One connector on a two-week cycle is a recurring task. Six connectors on different cycles is a team.
What partner programs cost
The certification rules limit what a vendor can charge for its certified API. Under 45 CFR 170.404, a certified API developer must publish all fees in plain language at a public link. It may charge an API user only for value-added services. It may not condition the right to use the certified API on a fee, a royalty or a revenue share. Anything beyond the certified API is a commercial agreement.
What vendors publish today:
| Vendor | Published terms |
|---|---|
| Epic | open.epic states that over 750 no-cost APIs and interfaces are available to app developers. Vendor Services is an optional program with support and an expanded testing sandbox; its public page states no fee. Epic's Vendor Services deck lists a Connection Hub listing at $500 per app per year, and it requires at least one live Epic connection. |
| athenahealth | Preview credentials are free on app creation. Production for non-certified APIs requires a contract for athenahealth Platform Services. A third-party vendor gets a Preview tablespace through a business associate agreement with a client or through the Marketplace Partner Program. The public documentation does not state the contract price. |
| NextGen Healthcare | The partner page states there is no charge to develop a Patient Access app, and that the API Distributor Program may have associated fees based on the scope of data needs. |
| eClinicalWorks | The developer portal says apps that need contract-required scopes must sign a pricing agreement with eClinicalWorks. The amount is not stated. |
| Oracle Health | The FAQ describes a developer program with a security validation step. The public pages fetched for this post do not state a fee. |
Read each program's terms before you plan. A fee that is not published is a negotiation, and a negotiation takes calendar time before the first line of code runs in production.
When building is the right call
Build when the connector is your product. If customers pay you for the depth of your athenaOne integration, you need engineers who know athenaOne.
Build when you need one system and expect to need one system. A single certified FHIR connector with OAuth 2.0 is bounded work, and the vendor sandboxes in the table carry no published fee.
Build when you need write operations the vendor exposes only under contract. A partner contract with the vendor puts you in their release notes and their support queue. An intermediary cannot pass all of that through.
Start from open source in either case. TheFhirStorm publishes connectors for eClinicalWorks in Python and TypeScript. Read one before you estimate your own, and count the files that handle authentication, paging and errors against the files that handle data.
When buying is the right call
Buy when your customers run several systems and your product is the layer above them. The maintenance load scales with the number of connectors, and it does not shrink as you grow.
Buy when you need payer portals. A portal connector has no sandbox, no release notes and no stability promise, and the login flow changes with the payer's security policy. One team that watches many portals every day sees a change before a team that watches one portal when a customer complains.
Buy when your deadline is a customer contract, not a roadmap. Partner contracting and per-customer enablement run on the vendor's calendar.
Whichever path you take, keep your own schema. Map every vendor into it at the edge, so a change of connector, built or bought, changes one adapter and nothing above it.