In many technology choices, compliance shows up last. A committee considers features, picks a favorite, and sends the contract for review. By that point, the decision has already been made in every way that matters.
This sequence is backward, and ends up producing a predictable set of problems. Organizations discover those after signing that the vendor’s data export costs extra, that the audit logging does not capture what they actually require. None of these are technical failures. They are procurement failures.
This article outlines the necessity of compliance when selecting healthcare technology and what each certification actually does and does not tell you.
The valuable reframing is to treat regulatory posture as a feature that gets considered alongside usability and price, because that is functionally what it is.
A system that cannot produce a complete access log is a system that will make a breach investigation a lot harder. A vendor with vague answers about subcontractors is a vendor whose risk is partly invisible. Those characteristics belong on the comparison grid next to workflow and cost, not in a separate document that gets noticed in week eleven.
Organizations that do this well ask compliance questions before the demonstrations begin instead of after, which also shortens the list.
Certification is usually one of the first things buyers check, but its significance can easily be overstated or misunderstood.
There are still clear reasons to choose certified EHR software. Certification under the federal health IT program displays that the product has been evaluated against specific requirements related to interoperability, data portability, and standardized APIs. It may also be required to participate in specific CMS programs. For practices and health systems with regulatory or reporting requirements, certification is therefore a core requirement rather than simply a nice-to-have.
Certification does not guarantee that a product is inherently secure, fits a specialty’s workflow, or that the vendor will be a reasonable partner. Certification tests specific criteria under specific conditions. It says nothing about how the product operates at scale, how quickly the vendor patches vulnerabilities, or what happens when an organization wants to leave.
The criteria themselves are also in motion. Federal rulemaking has completely trimmed older functionality-based certification requirements and pushed toward standardized, FHIR-based interfaces. A buyer evaluating products nowadays chooses something that will need to keep up with that, which makes a vendor’s track record on regulatory updates a legitimate selection criterion.
The BAA is often treated as a form to be signed. It allocates risk.
Worth confirming specifically: how fast the vendor commits to notifying the organization of a suspected breach, what subcontractors use the data and whether the organization gets told when that list changes, where data is hosted, whether encryption is applied at rest as well as in transit, and what the vendor’s obligations are for returning or destroying information at termination.
Vendors will usually provide a standard agreement and treat it as non-negotiable. Larger buyers frequently discover it is more negotiable than presented, particularly regarding breach notification timelines and audit rights.
Regulatory requirements change, and a system purchased today will operate under a different rulebook within its useful life.
The clearest current example is the proposed changes to the HIPAA Security Rule. The notice of proposed rulemaking published in early 2025 would remove the longstanding distinction between required and addressable safeguards, making measures such as encryption of electronic protected health information and multifactor authentication mandatory instead of optional, alongside stricter incident reporting, regular penetration testing, and expanded oversight of business associates. Federal regulators have pushed the final rule back, with the current timeline pointing toward 2027 rather than this year.
The practical implication is not that anyone should treat proposed requirements as binding today. It’s that a system selected now will very likely have to satisfy them. A product that already supports multifactor authentication, encrypts data at all times, and produces detailed audit trails is a product that will not need an expensive scramble later.
Two related issues get overlooked consistently.
The first is information blocking. Federal rules limit practices that unreasonably interfere with the access, exchange, or use of electronic health information, and a system that makes lawful data sharing tough exposes the organization using it, not just the developer.
The second is what happens at the end of the relationship. Every organization gradually replaces a system, and the terms governing that moment are set at signing. What formats are available for export. Whether historical records come across as usable information or as static documents. What the vendor charges for the extraction. A migration managed badly costs more than most of the differences that decide a selection in the first place.
None of this needs a large compliance function. It requires asking a defined set of questions early and documenting the answers.
A workable approach: a standard questionnaire sent before demonstrations, covering certification status, security attestations such as a recent SOC 2 Type II report, breach history, subcontractor disclosure, audit logging capacity, and data export terms. Vendors who answer swiftly are demonstrating something useful. Vendors who route the questions to sales are demonstrating something too.
The reason to front-load all of this is leverage. Every compliance concern is negotiable before a contract is signed and almost none of them are afterward. The organizations that end up with problems are rarely the ones that asked too much during selection.
Ans: The things that are worth confirming specifically are how fast the vendor commits to notifying the organization of a suspected breach, what subcontractors use the data, and whether the organization gets told when that list changes, and more.
Ans: Certification under the federal health IT program displays that the product has been evaluated against specific requirements related to interoperability, data portability, and standardized APIs.
Ans: A workable approach consists of a standard questionnaire sent before demonstrations, covering certification status, security attestations such as a recent SOC 2 Type II report, breach history, subcontractor disclosure, audit logging capacity, and data export terms.
