Why Your Small Practice Must Update Its EHR Before the Next Cures Act Deadline (45 CFR § 171.103)

The 21st Century Cures Act transformed how electronic health information must move, and 45 CFR 171.103 defines “information blocking” as any practice that unreasonably interferes with access, exchange, or use of electronic health information except where a regulatory exception applies.  For small practices, the practical question is simple: can your EHR actually do what the Cures Act now expects, and can you prove it when CMS, ONC, or OIG asks. Recent ONC rules require health IT developers to update certified health IT to new standards and provide those updates to customers by dates that include December 31, 2025, which means clinics that do not push vendors and update their systems may be left noncompliant. 

At the same time, HHS has finalized “appropriate disincentives” so that certain providers who commit information blocking can lose Medicare incentive payments, quality bonuses, or eligibility to participate in shared savings programs.  An outdated EHR is no longer just an IT frustration; it can be the root cause of an information blocking finding. For a small clinic operating on thin margins, the cost of ignoring the next Cures Act deadline can far exceed the cost of an orderly EHR upgrade.

Many small practices assume that information blocking and interoperability are problems for big health systems, not for a three-provider clinic with one EHR and a tight budget. The reality under 45 CFR 171.103 is that every health care provider is an “actor,” and the standard is whether your practice knows that a given behavior is unreasonable and likely to interfere with access, exchange, or use of electronic health information. 

If your EHR cannot send out a complete electronic health information export, if your patient portal cannot expose the data elements patients expect, or if your staff routinely tell patients and other clinicians “our system cannot do that,” regulators may decide that you are not just technologically behind, but that you are committing information blocking. At the same time, ONC’s health IT certification rules and the HTI-1 final rule have set specific dates by which health IT developers must update certified health IT to new data standards, FHIR API expectations, and EHI export capabilities.  Small practices do not have to become software experts, but they do need a minimal governance structure for asking the right questions, collecting proof from vendors, and updating internal workflows before these dates arrive.

Understanding Legal Framework & Scope Under 45 CFR 171.103

45 CFR 171.103 provides the operative definition of “information blocking” for all actors covered by the Cures Act. A practice is information blocking if it is likely to interfere with access, exchange, or use of electronic health information and is not required by another law or protected by an exception in subparts B, C, or D of part 171.  For health IT developers and health information exchanges or networks, the standard is “knows or should know”; for health care providers, the standard is “knows the practice is unreasonable and is likely to interfere” with access, exchange, or use of EHI. 

The underlying statute at 42 U.S.C. 300jj-52 directs HHS to identify activities that do and do not constitute information blocking and to establish penalties and disincentives for actors that interfere with the movement of electronic health information.  The Cures Act regulations in part 171 work alongside ONC’s certification rules in part 170, which require developers of certified health IT to support capabilities such as FHIR-based APIs, EHI export, and standardized data classes like the United States Core Data for Interoperability. 

Federally, the requirement is that actors must not engage in information blocking and that developers must deliver certified health IT that meets the updated criteria by specified compliance dates, including 2023 and 2025 milestones for EHI export and updated standards.  States retain flexibility to adopt additional data sharing obligations, privacy protections, or health information exchange programs, but they cannot authorize information blocking. In practice, that means a state law may require a specific consent form or data segmentation rule, but a provider cannot use state law as a pretext to deny or delay EHI when the law does not actually prohibit sharing.

Understanding this framework helps a small practice in three ways. First, it clarifies that “our vendor has not updated yet” will not excuse a pattern of unreasonable refusals to share EHI. Second, it helps you structure vendor contracts and support tickets around the specific federal capabilities that must be in place. Third, it reduces denials and administrative friction, because once your EHR can reliably export EHI and support FHIR APIs, payer interactions such as prior authorization, quality reporting, and risk adjustment become easier and more automated.

Several agencies share responsibility for enforcing the Cures Act information blocking rules. ONC writes the certification and information blocking regulations, CMS administers Medicare and related programs that now include information blocking disincentives, and the HHS Office of Inspector General investigates information blocking claims and can impose civil monetary penalties on certain actors. 

For health care providers, the latest enforcement shift is the HHS final rule on disincentives for providers that have committed information blocking. That rule ties information blocking determinations to existing Medicare programs, such as the Medicare Promoting Interoperability Program for hospitals, the MIPS Promoting Interoperability performance category for clinicians, and the Medicare Shared Savings Program for accountable care organizations. When OIG determines that a provider committed information blocking and refers the provider to CMS, CMS can treat the provider as not being a meaningful EHR user for the relevant period, reduce MIPS scores, or bar participation in shared savings for at least one year. 

Common triggers for an information blocking investigation include patient or clinician complaints that EHI is being blocked, repeated reports that a system cannot export data even though comparable systems can, failure to meet ONC certified capabilities after the compliance date, or public statements that contradict the provider’s obligations under 45 CFR 171.103.  For a small practice, the most likely path into this enforcement web is not a complex data sharing dispute; it is a straightforward complaint from a patient, referring provider, or vendor who believes your practice is refusing to share EHI for competitive, financial, or convenience reasons rather than for a legally valid reason.

To avoid information blocking findings and to survive a combined HIPAA and Cures Act style audit, a small practice needs a compact set of documented controls tied directly to 45 CFR 171.103 and related certification obligations. The following controls are designed to be low cost and realistic for lean teams.

1. Build and maintain a Cures Act EHR capability inventory

• How to implement: Create a one-page list of required Cures Act and HTI-1 related EHR capabilities such as FHIR API access, individual and population-level EHI export, and support for the current USCDI version; confirm with your vendor which capabilities are live, in progress, or unavailable.

• Evidence to retain: Vendor product sheets, certification identifiers, emails confirming go-live dates, and screenshots showing configuration settings for EHI export and APIs.

• Low-cost approach: Use a shared spreadsheet or simple checklist stored with your HIPAA security documentation so that the same inventory supports both HIPAA security risk analysis and information blocking compliance under 45 CFR 171.103.

2. Test real-world EHI access and document the results

• How to implement: At least twice a year, choose a sample of patients and test whether you can export their EHI in a computable format, whether the patient portal shows key data elements, and whether a FHIR-enabled app or trading partner can retrieve EHI as expected.

• Evidence to retain: Test scripts, screenshots, error logs, and any vendor tickets opened to resolve failures.

• Low-cost approach: Assign a technically inclined staff member or external IT consultant a half-day every six months to perform and document these tests, treating them as part of your overall compliance program rather than a one-off project.

3. Create a written process for using information blocking exceptions

• How to implement: Draft a simple procedure that describes when the practice may decline or delay sharing EHI, mapping to the major information blocking exceptions such as preventing harm, privacy, security, infeasibility, and content and manner.

• Evidence to retain: Copies of the procedure, staff training records, and case files where you applied an exception, including rationale and legal references.

• Low-cost approach: Adapt ONC fact sheets and flowcharts into a one-page internal decision tree instead of purchasing a large policy library.

4. Align vendor contracts and support tickets with 45 CFR 171.103 language

• How to implement: When renewing contracts or opening support tickets, explicitly reference your obligation under 45 CFR 171.103 not to engage in information blocking and your expectation that the vendor will support EHI access, exchange, and use consistent with ONC certification criteria.

• Evidence to retain: Copies of contract clauses, emails, and ticket transcripts that show you requested capabilities that prevent information blocking.

• Low-cost approach: Use a short standard paragraph that your staff can paste into requests, rather than rewriting legal language each time.

5. Integrate information blocking risk into your HIPAA security risk analysis

• How to implement: When you perform or update your HIPAA security risk analysis, add a section that identifies risks where technical limitations or misconfigurations could lead to information blocking, such as disabled APIs, narrow export formats, or excessive portal restrictions.

• Evidence to retain: Risk analysis reports, risk register entries that mention information blocking, and mitigation plans that include EHR upgrade milestones.

• Low-cost approach: Use your existing HIPAA risk analysis template and simply add an “information blocking implications” column, which ties technical risks back to 45 CFR 171.103 and the Cures Act.

6. Establish a simple complaint-to-corrective-action loop

• How to implement: Set up a single intake path for patient and clinician complaints about access to EHI, track them in a log, and have a standing rule that recurring complaints about “the system” must result in a vendor ticket or internal fix.

• Evidence to retain: Complaint logs, responses, and documentation showing how you corrected any confirmed obstacles to EHI access.

• Low-cost approach: Use the same log you already use for HIPAA privacy complaints and simply add a column for “information blocking risk.”

Taken together, these controls show auditors that you do not treat EHR capabilities as a black box and that you actively work to avoid practices that could meet the 45 CFR 171.103 definition of information blocking. They also give you documentation to demonstrate good-faith efforts if a complaint ever reaches OIG or CMS.

Case Study

Consider a three-physician primary care clinic that adopted a cloud-based EHR several years ago. The practice participates in MIPS and has historically earned small positive payment adjustments based on its performance. After the Cures Act information blocking rules took effect, the clinic assumed that its vendor would handle everything related to interoperability. The practice did not review Cures Act updates, did not ask for an EHI export capability plan, and did not test the patient portal beyond basic appointment scheduling. 

Over time, patients began asking the clinic to connect their records to third-party apps that support FHIR APIs. The vendor’s FHIR API module was still in development, and the clinic’s staff responded with a generic statement that the practice did not support third-party apps and that patients had to request PDF copies instead. Meanwhile, a nearby health system repeatedly requested structured electronic summaries for referred patients, but the clinic’s EHR could only send limited CCD documents that did not include recent lab and imaging data.

One patient, frustrated after being denied FHIR-based app access and experiencing repeated delays getting records sent to a specialist, submitted an information blocking complaint through the ONC website. OIG investigated and found that the clinic’s vendor had certified to updated Cures Act criteria but that the clinic had not turned on the available FHIR API or EHI export features. The clinic had no policy on information blocking exceptions and no record of attempting to enable or test the tools. OIG concluded that the clinic knew its repeated refusals were unreasonable and likely to interfere with access and use of EHI in violation of 45 CFR 171.103. 

OIG referred the clinic to CMS, which determined that the physicians would not be treated as meaningful EHR users for the performance year in question. Under the new disincentive rule, the clinic’s MIPS Promoting Interoperability score dropped to zero, resulting in a negative payment adjustment the following year.  Local media also reported that the clinic had been publicly listed on ONC’s information blocking webpage, creating reputational harm.

If the clinic had implemented the controls described in the survival guide, the outcome would likely have been very different. By keeping a Cures Act capability inventory and testing EHI access, the clinic would have discovered that FHIR APIs and EHI export were available but not configured. A written exception workflow would have guided staff to treat the temporary unavailability of features as an issue to fix, not as a permanent excuse to deny EHI access. Vendor contracts and tickets referencing 45 CFR 171.103 would have shown good-faith efforts to comply, potentially leading regulators to treat any gaps as implementation issues rather than information blocking.

Using this table as a working document helps you transform abstract Cures Act obligations into specific, trackable tasks that show regulators your practice is actively working to prevent information blocking rather than ignoring the issue.

Common Audit Pitfalls to Avoid Under 45 CFR 171.103

Regulators and auditors repeatedly see the same patterns leading to information blocking risk when they review small practices. Understanding these pitfalls helps your clinic avoid costly missteps.

• Treating Cures Act upgrades as a “vendor only” responsibility, with no internal tracking or testing, often results in outdated configurations that interfere with EHI access, which can be deemed an unreasonable practice under 45 CFR 171.103 and may trigger disincentives under Medicare programs.

• Telling patients or other providers that “we do not connect to outside apps or systems” when certified APIs or export functions exist can be interpreted as knowingly interfering with access and use of EHI, exposing the practice to information blocking findings.

• Using privacy or security as a blanket justification without tying the decision to a specific information blocking exception fails to meet the regulatory standard and can be viewed as a pretext rather than a legitimate protection.

• Failing to document complaint handling related to data access means the practice cannot demonstrate good-faith efforts to correct problems, which can weigh heavily against the provider during OIG and CMS assessments.

• Ignoring ONC and HTI-1 timelines for updated certification criteria can leave the practice on a version of the EHR that does not support required EHI export or API capabilities, increasing both the operational burden and the information blocking risk.

By explicitly designing your upgrade and complaint processes to avoid these pitfalls, you reduce the chance that ordinary system limitations will be recharacterized as information blocking under 45 CFR 171.103. You also improve efficiency, since the same steps that prevent information blocking often streamline data sharing with payers and other partners.

Technical upgrades alone will not keep your practice safe if nobody owns the process or understands why it matters. A simple culture and governance framework can make the difference between paper compliance and actual readiness.

Assign clear ownership for Cures Act and information blocking compliance, ideally pairing a clinical leader with a compliance or practice management lead so that decisions reflect both patient care and regulatory perspectives. Set a realistic staff training cadence that includes a short annual module on information blocking concepts, your internal exceptions procedure, and how to escalate patient or provider complaints about EHI access.

Build a basic dashboard of two or three metrics, such as the number of EHI access complaints received, the time to resolve them, and the status of key EHR capabilities relative to announced ONC deadlines. Review this dashboard at least twice a year in a brief leadership meeting and use it to decide when to escalate with your vendor or adjust internal workflows. By embedding these routines into regular operations, your practice signals that compliance with 45 CFR 171.103 is a shared responsibility, not an occasional IT project.

The Cures Act and 45 CFR 171.103 have moved information sharing from a best practice to an enforceable obligation with real financial stakes. For small practices, the most urgent risk is not a sophisticated cyber incident or a complex data sharing dispute; it is the combination of an aging EHR, missed Cures Act deadlines, and a pattern of telling patients or peers that your system “just cannot do that.” With disincentives now in place for certain Medicare-participating providers, ignoring EHR upgrades and information blocking risks can directly reduce revenue and damage your reputation. 

Three to five concrete next steps can put your practice on safer ground:

1. Create a one-page Cures Act EHR capability inventory and have your vendor confirm in writing which items are live, in progress, or missing.

2. Schedule and document a simple EHI access test cycle within the next 60 days, including portal review, EHI export, and at least one FHIR app or trading partner connection where feasible.

3. Draft or update a concise information blocking exceptions procedure that maps directly to the regulatory exceptions and train front-line staff on how to use it.

4. Add information blocking risk to your next HIPAA security risk analysis and mitigation plan so that EHR upgrade decisions are documented as risk treatments.

5. Set a recurring reminder, at least twice a year, to review ONC and CMS updates about Cures Act timelines and adjust your vendor roadmap and internal controls accordingly.

Recommended compliance tool: 

A combined “Information Blocking and EHR Upgrade” checklist kept with your HIPAA risk analysis file and updated whenever your vendor pushes a new release.

Advice:

Do not wait for your vendor to bring this up; initiate a written conversation this month about their Cures Act and HTI-1 roadmap and keep every response as evidence that your practice is actively working to avoid information blocking under 45 CFR 171.103.

• 45 CFR § 171.103 – Information blocking
  

• 45 CFR Part 171 – Information Blocking
  

• Information Blocking – HealthIT.gov
  

• 45 CFR § 171.103 – Information blocking (Cornell LII)