How mid-market healthcare operators should source technology contracts in 2026.

The structural fact of healthcare technology procurement is that the regulated workload sits on top of an electronic health record the operator did not build and cannot move, and every vendor that touches patient data inherits the operator's legal exposure. That is what separates healthcare sourcing from sourcing in any other vertical. A retailer evaluating a contact center platform is buying a feature set. A 12-clinic orthopedic group evaluating the same platform is buying a co-signer on its HIPAA liability, software that has to read and write against Epic or athenahealth without breaking a referral, and a counterparty whose own subcontractors now sit inside the group's breach perimeter. Price is the last of those four questions, not the first.

Most mid-market operators run the sequence backward. They build a shortlist on price and demo polish, then discover during security review that the preferred vendor integrates with their EHR through a flat nightly file export rather than a live interface, or that its Business Associate Agreement omits sub-processor flow-down, or that it stores protected health information in a shared tenant without encryption at rest. By then the operator has spent its negotiating leverage on a vendor it cannot use and has to restart. The fix is not better diligence at the end. It is moving the disqualifying constraints to the front.

Start sourcing from the EHR boundary, not the price sheet.

The EHR is the dispositive constraint, so the first filter on any healthcare technology shortlist is integration depth against the specific record system the operator already runs. A mid-market healthcare operator does not get to choose its EHR for the convenience of a phone-system vendor. The record is installed, the clinical workflows are built around it, and the cost of changing it dwarfs any savings on an adjacent contract. So the adjacent contract has to bend to the EHR, which means the integration question is settled before the commercial one.

Integration depth is not a yes-or-no field. Epic exposes third-party connectivity through FHIR-based APIs and its vendor connection programs. Oracle Health, the platform formerly sold as Cerner, runs on the Millennium data model and participates in the CommonWell and Carequality networks. athenahealth operates a cloud-native network with a partner marketplace. eClinicalWorks, NextGen, Greenway, and MEDITECH each publish their own developer and interoperability programs with materially different access models. The 21st Century Cures Act information-blocking rule and the maturing TEFCA framework have pushed all of them toward standardized FHIR R4 and USCDI data classes, but standardization at the spec level does not equalize what a given vendor's integration actually does in production. A claim that a product "writes back to the chart" can mean a real-time HL7 or FHIR interface, or it can mean a batch file that lands in the morning. Those are different products sold with the same sentence.

The buyer-side move is to convert the integration claim into a verifiable specification before the demo, not after. Ask which named interface standard the integration uses against your specific EHR build, who certifies it, whether it is bidirectional, and what the latency is. A vendor that can answer in those terms has done the work. A vendor that answers with the brand name of your EHR and a logo on a slide has not.

Treat the Business Associate Agreement as a security control, not paperwork.

The Business Associate Agreement is the second dispositive constraint, and the prudent operator reads it as an operational document rather than legal boilerplate. Under the HIPAA Rules, any vendor that creates, receives, maintains, or transmits protected health information on the operator's behalf is a business associate and must be under a contract that meets specific requirements. HHS publishes sample provisions setting the floor: permitted uses and disclosures, a safeguards obligation, a duty to report unauthorized uses and breaches, return or destruction of PHI at termination, and the right to terminate for a material violation. Those provisions are the minimum. The minimum is not where a mid-market operator wants to live.

The clause that does the most work, and is most often left thin, is sub-processor flow-down. A business associate that engages its own subcontractors to handle PHI must, under 45 CFR 164.502(e)(1)(ii), bind those subcontractors to the same restrictions and conditions it agreed to. In practice that means the operator's data protection is only as strong as the weakest contract several parties down the chain. When the operator cannot see who the sub-processors are, it cannot price the risk. The 2024 Change Healthcare incident, reported to the HHS Office for Civil Rights as affecting roughly 192.7 million individuals and now the largest healthcare data breach on the federal breach portal, was a business-associate event: a clearinghouse that thousands of providers depended on, several layers removed from most of the patients whose data moved through it. The lesson for a mid-market buyer is concentration. A single business associate sitting under many of your workflows is a single point of failure you signed for.

Price the regulation you will live under, not just today's floor.

The third constraint is the regulatory baseline the operator will have to meet over the life of the contract, and it is moving. On December 27, 2024, the HHS Office for Civil Rights issued a Notice of Proposed Rulemaking to modernize the HIPAA Security Rule, the first significant proposed overhaul since 2013. As of June 2026 it has not been finalized, and the current Security Rule remains in effect. But the direction is clear, and a multi-year contract signed today will likely run into the finalized version. A buyer who sources only to today's floor is buying a re-sourcing project.

The proposal removes the long-standing distinction between "required" and "addressable" implementation specifications and would make essentially all of them required. It would mandate encryption of ePHI at rest and in transit, multi-factor authentication, a technology asset inventory and network map reviewed at least every twelve months, vulnerability scanning at least every six months, penetration testing at least annually, and network segmentation. It would also require business associates to verify, through a subject-matter expert's written analysis at least once every twelve months, that they have deployed the technical safeguards the rule demands. NIST's companion guidance, SP 800-66 Revision 2, published February 2024, translates these obligations into concrete risk-management activities and is the reference a competent security reviewer will already be using.

For procurement, this reframes a roadmap question into a present one. A vendor that already encrypts at rest, enforces MFA, segments tenants, and can produce a current penetration test is selling against the proposed baseline, not the 2013 one. A vendor that treats those as future enhancements is asking the operator to absorb the cost of compliance drift. Sourcing to the proposed rule rather than the current one is not gold-plating. It is buying a contract that does not expire on a regulator's timeline.

Run the pre-commercial disqualification gate before any pricing call.

The decision a competent operator faces here is narrow and answerable: should the shortlist be built on price and demo, or filtered by the two dispositive constraints first? The answer is to disqualify on integration and BAA before commercial terms are discussed. The six questions below are the gate we run at the front of every healthcare sourcing engagement. Each is a gate, not a scoring factor: a vendor that cannot answer in these terms does not advance, regardless of price. The judgment is in the thresholds, not the topics. Paste them into your RFP.

What breaks is structural, and it is not the vendor's brand.

The failure modes in healthcare sourcing are architectural and contractual, not the fault of any named product. Three recur. The first is the shallow-integration trap: a vendor whose connection to the EHR is a one-directional batch export rather than a live interface, which works in the demo and falls apart when clinicians expect the chart to reflect a call or message in real time. This is a function of how the integration was built, and the same vendor may offer deep integration to one EHR and shallow integration to another, because the access models differ. It is the operator's job to verify the specific pairing, not the category.

The second is the thin BAA: an agreement that meets the HHS minimum but omits sub-processor enumeration, leaves the breach-notification window undefined, or fails to specify return or destruction of PHI at termination. None of that shows up in pricing. All of it shows up in an OCR investigation. The third is concentration risk: routing too many PHI-touching workflows through a single business associate, which optimizes for procurement simplicity and maximizes blast radius. The Change Healthcare event is the reference case, and the structural cause was dependency concentration, not a single company's failing.

In every one of these, the fix is a buyer-side discipline rather than a vendor choice. Verify the integration against your build. Negotiate the BAA past the floor. Distribute dependency. None of those requires picking a "better" vendor, and none is solved by the brand on the contract.

What this means for procurement.

For a mid-market healthcare operator, the procurement decision closes when the field has been filtered by the two dispositive constraints before commercial terms are discussed, not after. Build the shortlist by running the disqualification gate first. The vendors that clear it are the only ones whose pricing is worth comparing, because a cheaper contract that fails the EHR or BAA test is not cheaper. It is a deferred cost with a regulator's name on it.

The technology layer underneath these decisions is covered in where AI fits in your tech stack, and the specialty-level patterns we are seeing in the field, including the multi-location veterinary case, sit in the Healthcare library. The next pieces in this series go deeper on each constraint in turn, starting with EHR integration as the disqualifying filter, then the BAA audit a vendor should be able to pass. The constraint set does not change. The detail does.

How Cardinal handles a healthcare sourcing decision.

When a buyer engages us on a healthcare technology decision, we calibrate the supplier pool to the operator's actual EHR and compliance posture, run the technical and contractual disqualification before the commercial stage, and present only the vendors that survive it. The integration is verified against the specific record build, the BAA is negotiated past the HHS floor, and dependency is distributed so no single business associate becomes the blast radius. Then price is compared only among vendors that already clear the constraints.

Cardinal is buyer-side. Supplier-paid. Buyers pay zero. Compensation has zero weight in the Cardinal Index scoring. The specific commission terms for any engagement are disclosed to the buyer in writing in the Decision Memo before signature, never on this page. See the Cardinal Method →  ·  How we get paid →  ·  Healthcare coverage →