EHR integration as the disqualifying constraint.

The dispositive constraint in healthcare technology sourcing is that every adjacent vendor has to bend to an electronic health record the operator did not build and cannot move. A 15-clinic cardiology group does not select its EHR to suit a contact center platform, a patient-communication tool, or a remote-monitoring vendor. The record is installed, the clinical workflows are wired around it, and the cost of replacing it dwarfs any savings on the contract in front of you. So the contract in front of you inherits a hard boundary: it either reads and writes the data your workflow needs, in the direction and at the timing the workflow needs, or it does not. That boundary settles the shortlist before commercial terms are on the table. Price is what you negotiate among the vendors that clear it, not a reason to relax it.

This is the second piece in the Healthcare series. The anchor named two constraints that disqualify vendors before price: the EHR boundary and the Business Associate Agreement. This piece goes deep on the first one, because it is the constraint mid-market operators most often mishandle. They treat "integrates with our EHR" as a checkbox a vendor either ticks or does not, when integration is a spectrum with a working real-time interface at one end and a file that lands overnight at the other. Both tick the box. Only one runs the clinic.

Start the healthcare shortlist at integration depth, not the demo.

Integration depth against your specific EHR build is the first filter, ahead of feature set and well ahead of price. The reason is structural. In most verticals a buyer can swap the surrounding systems around a workflow. In healthcare the record is the fixed point and everything else orbits it, so the question that decides deployability is not "what can this product do" but "what can this product do against the exact record system, and the exact version, we run today." A vendor that integrates deeply with one EHR may integrate shallowly with yours, because the two records expose data differently. The capability does not travel. It has to be verified per pairing.

That reframes the sourcing sequence. The competent operator does not build a shortlist on demo polish and discount, then discover in security and technical review that the preferred vendor connects through a nightly export. The competent operator disqualifies on integration first, so the demo and the price conversation only ever happen with vendors that can actually run in production against the installed record. Front-loading the constraint is cheaper than discovering it late, and in healthcare late discovery usually means restarting the procurement after the leverage is gone.

"Integrates with Epic" is a brand, not a capability — the resource and the interaction are.

The capability that matters is the named data resource plus the named interaction, and a vendor that answers with a logo has not described one. Modern EHR integration is built on HL7 FHIR, and the shared REST standard across the major records is FHIR Release 4. HL7 publishes the US Core Implementation Guide, which defines the profiles and the minimum RESTful interactions that establish the interoperability floor for US patient data. Underneath a claim of "we integrate," three separate questions decide whether the product runs your workflow, and they are routinely collapsed into one sentence.

The first is which resource. FHIR organizes data into discrete resources: a medication request, an observation such as a vital sign or a lab result, a document reference for a clinical note, an appointment, a condition on the problem list. A product that can read appointments is not therefore able to write a clinical note. The second is which interaction. A read or a search on a resource pulls data out. A create or an update writes data back. On Epic on FHIR, for example, most resources are exposed for read and search, while create and update are available for a narrower set, so "writes to the chart" is only true for the specific resources where write is actually supported. The third is timing. A live FHIR interface reflects the event when it happens. A batch interface reflects it after the file runs. For a scheduling tool that is a nuisance. For a workflow where a clinician expects the chart to show a patient message or a monitoring alert in the moment, it is a clinical failure that the demo will never reveal, because the demo uses a populated sandbox.

So the buyer-side translation is mechanical. Take the sentence "we integrate with your EHR" and require it to become "we perform a create on the DocumentReference resource over FHIR R4, in real time, certified against your build." A vendor that can speak in those terms has done the engineering. A vendor that repeats your EHR's brand name and shows a logo on a slide has told you nothing you can deploy.

Each major EHR exposes integration through its own program, and the access models differ.

The standard is shared, but every record wraps it in a different developer program with different access, and naming the vendors is how a buyer reads the terrain. This is factual capability description, not a ranking. Epic publishes its FHIR documentation, sandboxes, and app-registration flow through Epic on FHIR and open.epic, supports the SMART on FHIR launch framework, separately documents its older HL7 v2 interfaces, and lists third-party applications for its customer sites through Showroom, the successor to App Orchard. Epic's model is deep and mature, and its per-site configurability means the same app can behave differently across two Epic customers. Oracle Health, the platform formerly sold as Cerner, runs on the Millennium data model and has consolidated its developer program on FHIR R4 while participating in the national exchange networks. athenahealth operates a cloud-native platform and exposes REST and FHIR APIs through its Marketplace, which tends to shorten onboarding relative to on-premise records. eClinicalWorks, NextGen, Greenway, and MEDITECH each publish their own developer and interoperability programs with materially different access models and approval steps.

The point of naming them is not to grade them. It is that the integration question has a different answer for each, and often a different answer across two sites running the same product. The mid-market operator's job is to verify the specific pairing between the vendor and the installed record, at the version and build in production, rather than accept a category-level claim. The same logic reaches into specialty records, too: a multi-location veterinary group evaluating a communication platform against a practice-management system such as IDEXX Cornerstone faces the identical structural question, which is why the field pattern shows up in our veterinary tech-stack note as well. The record is the constraint regardless of the specialty over it.

The regulatory floor is standardized, but certification and version drift move under a multi-year contract.

The interoperability baseline is set by federal certification, and it advances on a schedule that will pass under any multi-year integration you sign today. ASTP/ONC's HTI-1 final rule adopted the United States Core Data for Interoperability, USCDI Version 3, as the baseline standard in the ONC Health IT Certification Program as of January 1, 2026, and it revised the information-blocking framework that discourages a record holder from unreasonably interfering with a standards-based exchange. HL7's US Core guide, which implements those data classes in FHIR, moves on an annual release cycle, so the certified profile a vendor built against is a moving reference, not a fixed one. ONC-certified health IT sits under the care delivered by more than 96 percent of hospitals and roughly 78 percent of office-based physicians, which is why the certified baseline, not a vendor's marketing, is the right yardstick.

For procurement this converts a technical detail into a contract term. A vendor still leaning on a deprecated FHIR release or an older US Core profile is carrying a re-certification cost that surfaces later as a change order, on your timeline and your budget. The buyer-side move is to source to the current certified baseline and to write down who absorbs the cost when the baseline moves again. It is also worth knowing the alternative path: for query-and-retrieve of records across organizations, the Trusted Exchange Framework and Common Agreement, TEFCA, now provides a national network-of-networks that HHS reported crossed one billion records exchanged in June 2026. TEFCA does not replace a real-time write-back interface into your own EHR, but it changes the build-versus-connect calculus for cross-provider data pulls, and a vendor that assumes point-to-point interfaces for everything may be quoting you integration work the network already does.

Verify the integration before the shortlist with a fixed question set.

The decision a competent operator faces here is concrete: should "integrates with our EHR" be accepted as a shortlist qualifier, or verified as a specification first? The answer is to verify first, because the claim spans products that are not interchangeable. The set below is the integration gate we run at the front of a healthcare engagement, before feature comparison and well before price. Each item is a disqualifier, not a scoring nicety: a vendor that cannot answer in these terms does not advance against the record you actually run. Paste it into your RFP.

What breaks is the integration architecture, not the EHR brand.

The failure modes here are architectural and contractual, and none of them is the fault of a named product. Three recur. The first is the batch masquerade: a connection built as a one-directional overnight export but described as an integration, which passes the demo and fails the moment a clinician expects the record to reflect an event in real time. The cause is how the interface was built, not which record it points at. The second is the direction mismatch: a read-only integration bought for a workflow that needs write-back, so the product can see the chart but cannot update it, and the gap only appears once staff are keying data twice. The third is per-site variance: the same product integrating deeply at one location and shallowly at another because the underlying EHR builds differ, which turns a clean pilot into an uneven rollout.

In each case the remedy is a buyer-side discipline rather than a different logo. Verify the resource and interaction against your build. Confirm the direction of data flow before signing. Test against unpopulated data instead of the vendor's sandbox. Pin the FHIR and certification version and assign the cost of drift. None of that requires declaring a vendor good or bad. It requires refusing to let a brand name stand in for a specification.

What this means for procurement.

What closes the procurement decision in healthcare is a shortlist filtered by integration depth against the installed record before any pricing call, not after. Run the verification set first. The vendors that clear it are the only ones whose commercial terms are worth comparing, because a cheaper contract that connects through the wrong resource, the wrong direction, or the wrong timing is not cheaper. It is a workflow failure and a re-certification liability with a discount attached. The prudent operator treats the integration answer as the gate and the price as the negotiation that happens behind it.

The category-level mechanics of the surrounding systems sit in our contact center vendor selection hub, the vertical view is in the Healthcare library, and the technology layer underneath these decisions is mapped in where AI fits in your tech stack. The next piece in this series turns to the Business Associate Agreement and the vendor-side audit that keeps a signed BAA from being paperwork. The constraint set does not change across the series. The resolution of each constraint is where the work is.

How Cardinal handles an EHR integration decision.

When a buyer engages us on a healthcare technology decision, we start by mapping the workflows to the exact FHIR resources and interactions they require, then verify each shortlisted vendor against the operator's installed record at its production version before the commercial stage. The Cardinal Method runs the technical disqualification first, tests against unpopulated data rather than a vendor sandbox, and pins the certification and version terms in the contract so that drift does not become a surprise change order. Only the vendors that clear the integration constraint reach a pricing comparison.

See the Cardinal Method →  ·  Healthcare coverage →  ·  Contact center selection →