The Interoperability Mandate: What the Cures Act Requires of Your EHR System (45 CFR Part 170)

The 21st Century Cures Act did more than encourage interoperability. It turned interoperability into an ongoing mandate by updating the ONC Health IT Certification Program in 45 CFR Part 170 and pairing it with the information blocking framework in 45 CFR Part 171. Small practices may not interact directly with ONC, but they depend heavily on certified EHR technology whose capabilities and vendor behavior are governed by these rules.

Under Part 170, developers must design, certify, and maintain health IT that can exchange core clinical data, support standardized APIs, and keep pace with evolving standards like the USCDI. Clinics that continue using outdated or partially certified products risk being seen as unable to meet payer interoperability expectations or to support seamless patient access to electronic health information.

The interoperability mandate for a small practice can be summarized in three questions: Are you using products that actually meet current Part 170 criteria, are those features turned on and available in daily workflows, and do your business practices avoid undermining interoperability in ways that might be viewed as information blocking. This article explains the legal framework and offers a practical survival guide tailored to lean clinics.

For many years, “meaningful use” and “certified EHR technology” appeared to be abstract program terms aimed at hospitals and large health systems. The Cures Act changed that dynamic. By revising the ONC Certification Program in 45 CFR Part 170, HHS created a tighter link between certified health IT, patient access, and the ability of providers to exchange information without friction.

Small practices now sit in the middle of a policy triangle: certification rules in Part 170, information blocking rules in Part 171, and payer expectations in quality and interoperability programs. A clinic’s EHR system is the main tool that either supports or frustrates compliance with those expectations. If the product is not kept current under Part 170, or if key interoperability features are disabled by local configuration or policy, the practice may draw complaints from patients, referral partners, or plans.

The operational question is simple: what does the Cures Act, implemented through Part 170, realistically require of your EHR environment, and how can you manage those requirements without an IT department. The answer begins with understanding what Part 170 actually covers.

Understanding Legal Framework & Scope Under 45 CFR Part 170

45 CFR Part 170 is the backbone of the ONC Health IT Certification Program. Subpart C specifies certification criteria for health IT modules; Subpart D sets Conditions and Maintenance of Certification for developers; and Subpart E establishes procedures for certification, surveillance, and potential termination.

From a small practice perspective, several elements are especially important:

• Certification criteria: Part 170’s criteria describe what certified health IT must be able to do electronically, such as support clinical decision support, record and exchange core clinical data, enable patient access, and provide standardized APIs for patient and population services.

• Data standards: Part 170 adopts standards like the USCDI to define the minimum dataset systems must support and exchange, and HTI-1 updates move that baseline to USCDI v3 by a specified date.

• Conditions and Maintenance of Certification: Under Subpart D, developers must meet ongoing conditions, including not engaging in information blocking as developers, supporting real-world testing of certain criteria, and maintaining transparent and non-discriminatory API access practices.

Federal law focuses these obligations on health IT developers and their products, not directly on individual clinics. However, once a small practice represents that it uses certified health IT (for example, in payer attestations or network contracts), it implicitly relies on Part 170 as the standard for what its EHR can do.

States may add their own requirements related to health information exchange or data submission, but they generally do not change the core federal certification framework. Instead, state rules often assume that providers will use products conforming to federal criteria when sending data to immunization registries, all-payer claims databases, or health information exchanges.

By understanding Part 170, a practice gains two advantages. First, it can ask vendors targeted questions about whether the deployed version and configuration actually meet current criteria. Second, it can anticipate where broken interoperability might be seen not just as a technical nuisance but as a potential compliance issue linked to Cures Act expectations.

ONC administers the Health IT Certification Program authorized by the Public Health Service Act and codified in 45 CFR Part 170. ONC authorizes testing laboratories and certification bodies to evaluate products against Part 170 criteria and to conduct surveillance. It also retains “direct review” authority to investigate potential nonconformities, including noncompliance with Conditions and Maintenance of Certification.

If a developer fails to meet Part 170 requirements, ONC can require corrective action, suspend certification, or terminate a product’s certification status. These enforcement actions hit vendors first, but they ripple down to providers who suddenly find that a system they depend on is no longer certified for certain criteria.

Parallel to Part 170, the Cures Act information blocking regulations in 45 CFR Part 171 create enforcement mechanisms for ONC-identified “actors,” including health IT developers and health care providers. The Office of Inspector General can impose civil monetary penalties on developers for information blocking, while providers can face disincentives in federal programs, with ONC publishing information about providers that have been subject to disincentives.

Common triggers that pull a small practice into this enforcement orbit include:

• Payer audits of Promoting Interoperability or other programs that assume use of certified health IT for specific measures tied to Part 170 criteria.

• Complaints that patients cannot access or transmit their electronic health information, which can raise both Part 170 capability questions and Part 171 information blocking concerns.

• Disputes with referral partners or health information exchanges claiming that the practice’s EHR will not connect or share data as expected under standardized formats.

Small practices cannot control vendor behavior, but they can control which products they select, how they configure them, and how they respond when interoperability problems arise. The next section treats interoperability as a routine audit topic, similar to HIPAA, and offers concrete controls suited to lean clinics.

To survive an audit that touches on interoperability, a small practice must show that it took reasonable steps to select, oversee, and use EHR technology aligned with Part 170. The following controls are structured like HIPAA safeguards: each has a practical implementation method, expected evidence, and a low-cost approach.

1. Confirm and document Part 170 certification status before and after go-live

The first control is to treat certification status like a required credential. Before contracting, the practice should verify that the proposed product and version are listed as certified under 45 CFR Part 170 for the criteria that matter to the clinic, such as those supporting patient access, clinical exchange, and quality reporting.

Implementation: During vendor selection and after each major upgrade, designate someone to confirm the product’s certification status and which criteria are covered. Capture copies of the vendor’s ONC certification listing and any statements tying the deployment to specific criteria.

Evidence: Keep a small “Part 170 file” containing dated screenshots or PDFs of certification listings and vendor attestations. Update the file when versions change, so you can show that your live environment aligns with current certification.

Low-cost method: A simple shared folder and a one-page summary in a word processor are sufficient. The key is clarity: product name, version, and certification references that point back to Part 170.

2. Build interoperability expectations into vendor contracts and renewals

Even though ONC regulates developers directly, your contract is where you protect your practice. Contracts and renewals should explicitly reference certified capabilities under Part 170 and outline what happens if certification is suspended, revoked, or allowed to lapse.

Implementation: For new or renewed contracts, ask for language that:

• Identifies the certified modules and relevant criteria under Part 170;

• Requires the vendor to maintain certification for those criteria or notify you promptly of any changes; and

• Addresses your options if certification is lost, including assistance migrating to another product.

Evidence: Store executed contracts and renewal amendments in your compliance repository, with key Part 170 references highlighted or summarized in a short cover memo.

Low-cost method: You do not need outside counsel for every renewal; start by using a simple internal checklist that prompts you to ask for Part 170-related protections and to confirm how the vendor will handle future ONC rule updates, such as HTI-1 changes.

3. Align EHR upgrade plans with federal certification timelines

Part 170 and ONC rulemaking establish dates by which new criteria, standards, or USCDI versions must be adopted. Developers are responsible for meeting those dates, but providers are the ones who live with the consequences if upgrades lag.

Implementation: At least once a year, ask your vendor which forthcoming ONC deadlines affect your deployment (for example, USCDI v3 adoption or updated criteria for decision support). Build those milestones into your internal upgrade calendar, so you know when your environment is expected to meet revised Part 170 requirements.

Evidence: Maintain an “interoperability calendar” that notes key ONC milestones and vendor-promised upgrade dates, along with confirmation emails or release notes when upgrades occur.

Low-cost method: A basic calendar tool or shared spreadsheet is enough. The important thing is to show that you were aware of upcoming Part 170 changes and relied on vendor commitments to stay current.

4. Integrate interoperability checks into HIPAA technical safeguard reviews

HIPAA’s technical safeguards require access control, integrity, and transmission security for electronic protected health information. Interoperability features such as standardized APIs, patient portals, and data exchange services sit on top of these same technical safeguards.

Implementation: When you conduct your periodic HIPAA security risk analysis or technical review, include a small section specifically addressing interoperability-related features enabled under Part 170. Ask whether patient access tools, APIs, and exchange services are configured in a way that both supports interoperability and maintains reasonable security.

Evidence: Document in your risk analysis or technical review notes which interoperability-related features were reviewed, what risks were identified, and what mitigation steps were taken. Explicitly reference “certified EHR technology under 45 CFR Part 170” so auditors see the connection.

Low-cost method: Add one page to your existing HIPAA risk analysis template focused on interoperability settings and how they relate to both Part 170 capabilities and information blocking expectations in Part 171.

5. Prepare a basic response plan for vendor nonconformity or certification loss

ONC’s direct review and enforcement authority means that, in rare cases, a vendor may be found nonconformant with Part 170, leading to corrective action or termination of certification. While you cannot control that process, you can plan how your clinic would respond.

Implementation: Draft a short internal plan that outlines how you will monitor for vendor notices about certification issues, who will assess the impact on your programs, and how you will communicate with payers or networks if your EHR’s certification status changes.

Evidence: Keep the plan with your other compliance procedures and note any real-world incidents where you had to act on it, such as a vendor advisory about an ONC corrective action plan.

Low-cost method: A two-page procedure drafted by your compliance lead is sufficient. The goal is to show that you have thought about Part 170-related vendor risk and have a structured way to handle it.

Taken together, these controls allow a small practice to demonstrate that it takes the interoperability mandate seriously, even if it does not directly manage the certification process.

Case Study

A three-physician primary care clinic joined a regional clinically integrated network that required participants to use certified EHR technology capable of exchanging core clinical data and supporting app-based patient access. The clinic’s EHR vendor had historically maintained certification, but the practice had not tracked which criteria applied or when upgrades occurred.

After the Cures Act updates, ONC adopted new standardized API criteria and expanded data requirements under USCDI. The vendor delayed rolling out the relevant updates for the clinic’s hosted environment. While larger clients were upgraded early, small practices like this one remained on an older version that technically met older certification baselines but did not satisfy the network’s interoperability profile.

Patients began asking why they could not connect popular smartphone apps to their records when neighboring practices could. The network raised concerns that the clinic’s EHR was not ready for standardized API access and might threaten the network’s overall compliance posture. Payers also questioned the clinic’s ability to meet Promoting Interoperability measures tied to current certification criteria.

Because the clinic had no Part 170 file, no upgrade calendar, and no contractual language addressing certification lapses, it struggled to respond. It was unclear which version they were on, what the vendor had promised, and how quickly the environment would be brought into alignment with updated Part 170 requirements. The network considered placing the clinic on a corrective action plan and flagging it as “not interoperability ready” for new referrals.

In response, the clinic:

• Asked the vendor for written confirmation of current certification status and a firm upgrade schedule that would implement the newer Part 170 criteria, including standardized APIs.

• Amended its contract to require prompt notification of any future certification issues and to outline transitional support if certification were lost.

• Established a simple Part 170 readiness summary and tied it to its HIPAA risk analysis and annual payer attestations.

Within several months, the clinic’s environment was upgraded, app-based access went live, and the network removed the clinic from its watch list. The episode demonstrated that failing to monitor part 170-related expectations can quickly become a reputational and operational problem, even for a small practice.

Completing this checklist periodically gives leadership a concise picture of whether the practice’s EHR environment tracks the interoperability mandate embedded in Part 170.

Common Audit Pitfalls to Avoid Under 45 CFR Part 170

Audits and reviews that touch Part 170 often highlight recurring errors. Addressing these weaknesses in advance can significantly reduce risk.

• Treating “certified EHR” as a generic label without verifying actual Part 170 status. Error: assuming any modern EHR is certified without checking the product and version listing. Consequence: misalignment with payer and network expectations that explicitly rely on current certification under Part 170.

• Ignoring Conditions and Maintenance of Certification obligations that affect provider experience. Error: not asking vendors how they comply with real-world testing, API practices, or information blocking-related conditions in Subpart D. Consequence: being surprised by functionality changes, new access policies, or disruptions triggered by ONC enforcement.

• Allowing contracts to remain silent on certification loss. Error: having no contractual remedy if an EHR’s certification is suspended or terminated. Consequence: being stuck on a non-certified product that undermines participation in federal programs and makes interoperability commitments difficult to meet.

• Failing to align upgrades with ONC timelines. Error: running an outdated version that does not meet new criteria or USCDI versions while assuming you are “up to date.” Consequence: being unable to support new interoperability requirements while payers and partners move ahead.

• Keeping interoperability isolated from HIPAA and security governance. Error: Treating Part 170 features as purely technical, unrelated to security safeguards or information blocking compliance. Consequence: inconsistent configurations that either over-restrict data exchange or expose security gaps.

By recognizing and correcting these pitfalls, a small practice shows regulators, payers, and partners that it takes the interoperability mandate seriously and uses Part 170 as a concrete guide for managing its EHR relationship.

Interoperability cannot be outsourced completely to vendors. It must be part of the clinic’s governance rhythm. Designating a small “interoperability committee” even if it is just the practice manager, a clinician champion, and the compliance lead ensures that Part 170-related issues have an owner.

This group can meet briefly two or three times a year to review the certification file, upgrade calendar, key contracts, and any complaints or incidents related to electronic information sharing. By treating these topics alongside HIPAA, privacy, and billing compliance, the practice reinforces that interoperability is not optional or purely technical; it is a regulatory expectation tied to the Cures Act.

Simple metrics such as “date of last certification check,” “number of upcoming ONC-related milestones,” and “open interoperability issues with vendors or partners” can be tracked on a single page. Leaders then have an at-a-glance view of where the practice stands against the interoperability mandate.

The Cures Act reframed certified EHR technology from a static requirement to a moving target under 45 CFR Part 170. Products and developers must evolve with new criteria, standards, and conditions, and small practices that depend on those products must pay attention to the downstream effects. The interoperability mandate is not about mastering regulatory text; it is about making deliberate choices in vendor selection, contracting, upgrades, and governance so that your EHR supports safe, secure, and timely information sharing.

For a lean clinic, the path forward is manageable. By confirming certification status, insisting on basic contractual protections, aligning upgrades with ONC timelines, and integrating interoperability into existing HIPAA governance, you can show that you are doing your part to meet federal expectations.

Immediate next steps for a small clinic:

1. Assemble a brief Part 170 file with current certification listings, key contract excerpts, and a simple summary of which interoperability features your EHR supports.

2. Add two questions to your next vendor call: what upcoming ONC or HTI-1 deadlines affect your environment, and how will the vendor ensure your deployment remains certified.

3. Update your HIPAA risk analysis template to include one page on interoperability-related settings and how they balance access and security.

4. Review major payer and network agreements to confirm that they do not assume capabilities your current EHR version cannot provide.

5. Schedule a short annual “interoperability check-in” where leadership reviews this file and confirms that the practice still meets its self-imposed standards.

Recommended compliance tool:

A consolidated “Part 170 readiness summary” that you update annually and attach to your broader compliance binder.

Advice: 

Do not wait for a complaint or audit; pick one hour this quarter to confirm your EHR’s certification status and document how you will stay aligned with evolving Part 170 requirements.

• 45 CFR Part 170 – Health Information Technology Standards, Implementation Specifications, and Certification Criteria

• 45 CFR Part 170 Subpart E – ONC Health IT Certification Program

• 45 CFR Part 170 Subpart D – Conditions and Maintenance of Certification

• HTI-1 Final Rule Overview (ONC)

• ONC Health IT Certification Program – Test Method and Overview

• Information Blocking Regulations – Overview (ONC)

• 45 CFR Part 171 – Information Blocking Exceptions (eCFR)