The Cures Act Documentation Trap: Proving Your Information System is Interoperable (45 CFR § 170.315)

The 21st Century Cures Act pushed health care toward interoperability by tying certified health IT to detailed criteria in 45 CFR 170.315. These criteria describe what certified electronic health record technology must be able to do, from e prescribing and summary of care exchange to standardized APIs for patient and population services.

Small practices usually rely on a vendor’s certification badge and assume that is enough. The documentation trap appears when regulators, payers, or business partners ask for proof that the installed system and the way staff use it actually meet those 170.315 capabilities. If the practice has no records, test cases, or configuration evidence, it is difficult to show that the system is interoperable in real life.

This is not just an abstract problem. The same infrastructure that proves interoperability under 170.315 also supports compliance with information blocking rules, Promoting Interoperability measures, and network participation requirements. A lean, well organized set of documents and screenshots can give a small clinic credible evidence that its health IT is interoperable, even without an IT department.

Most small practices hear “ONC certified EHR” and stop there. The assumption is that certification belongs to the vendor and the clinic’s only job is to pay the subscription. Under the Cures Act, that assumption is dangerous. Certification criteria in 45 CFR 170.315 apply to specific versions and modules, and the way those modules are configured can either support or frustrate interoperability.

Payers, health information exchanges, and referral partners increasingly expect proof that a practice can exchange records electronically, expose data through standardized APIs, and give patients electronic access without unnecessary delay. When something goes wrong, clinic leadership may be asked to show more than a marketing one pager from the vendor. They may need to demonstrate that their system supports the particular criteria relevant to the dispute and that those functions are turned on and used.

For a lean practice, the goal is not to become a software expert. The goal is to keep a minimal, disciplined documentation set that can answer three audit questions quickly: What 170.315 criteria does your system claim, how have you configured and tested those capabilities, and where is the proof that you actually use them in day to day care.

Understanding Legal Framework & Scope Under 45 CFR 170.315

45 CFR 170.315 lays out the ONC certification criteria for health IT. The regulation groups criteria into clinical, care coordination, clinical quality, patient engagement, public health, and general criteria, many of which have explicit interoperability components. Examples include:

• 170.315(b) criteria for transitions of care and clinical information reconciliation, which require systems to create and receive structured clinical summaries.

• 170.315(e)(1) patient access to view, download, and transmit their health information.

• 170.315(g)(7) to (g)(10) application access criteria, including the standardized API for patient and population services that must be based on HL7 FHIR standards.

These criteria are directed at health IT modules and developers, but their scope shapes what a provider can truthfully say about their system. When a practice claims that its EHR is certified, that claim refers to discrete criteria under 170.315 as implemented in a particular version. ONC’s Cures Act Final Rule and HTI 1 updates then layer on conditions and maintenance of certification, such as real world testing for certain criteria and API endpoint publication for 170.315(g)(10).

Federal law does not require every provider to understand the entire certification program. It does, however, require providers subject to information blocking rules to avoid practices that interfere with access, exchange, or use of electronic health information except as allowed by the rule. If a provider cannot show that its system is capable of exchanging data under the relevant 170.315 criteria, it becomes harder to demonstrate that any data sharing problem was a technical limitation rather than an avoidable barrier.

Understanding this framework helps reduce friction in several ways. First, it helps clinics ask vendors the right questions about which criteria their deployment actually meets. Second, it ensures that documentation aligns with the specific 170.315 capabilities at issue in payer programs, network agreements, and information blocking investigations. Finally, it reduces administrative disruption when outside parties request proof that the practice’s health IT is interoperable in real world use.

The ONC Health IT Certification Program is administered by ONC through accreditation and oversight of ONC authorized certification bodies. These bodies test health IT modules against the 170.315 criteria and issue certifications that are then listed on the Certified Health IT Product List. Developers must also comply with conditions and maintenance of certification, including real world testing and periodic attestations.

For small practices, the more immediate enforcement risks come from other corners of the Cures Act landscape. The Office of Inspector General enforces information blocking for health IT developers and certain other actors, and provider disincentives are being implemented through federal programs. CMS relies on certified health IT in its Promoting Interoperability and quality programs, many of which reference 170.315 criteria as the technical foundation for performance measures.

Common triggers that place a clinic’s interoperability documentation under scrutiny include:

• Patient complaints that they cannot access their electronic information through portals or apps, or that their data is not being shared with other providers despite requests.

• Referral partners or health information exchanges reporting that a clinic’s system refuses connections, cannot send summaries of care, or will not enable standardized APIs.

• CMS audits of Promoting Interoperability attestation data, where clinics must show that their certified health IT supported specific measures grounded in 170.315 capabilities.

In each of these situations, having clear documentation of how your EHR meets and uses 170.315 criteria can make the difference between a short review and a prolonged investigation.

Even though 45 CFR 170.315 targets health IT developers, small practices can prepare for interoperability questions in the same disciplined way they prepare for HIPAA security reviews. The following controls form a compact playbook for surviving an audit focused on whether your system is interoperable and whether you can prove it.

1. Build a simple 170.315 criteria inventory

The first control is to make the invisible visible. Many clinics have no written list of which 170.315 criteria their installed EHR version is certified to meet.

Create a one-page table that lists: the EHR product and version you use, its ONC certification number, and the specific 170.315 criteria included in your deployment, such as 170.315(b)(1) for transitions of care, 170.315(e)(1) for patient access, and 170.315(g)(7) to (g)(10) for application access and standardized APIs. For each criterion, include a short description of where the capability appears in your system, for example “patient portal menu” or “FHIR API settings page.”

Evidence to retain includes vendor certification documentation, screenshots of the Certified Health IT Product List entry, and the completed inventory itself. A free spreadsheet or word processing template is enough. This simple inventory anchors all other documentation by tying it directly to the language of 170.315.

2. Capture real workflows as interoperability use cases

Interoperability is proven in use, not in marketing brochures. For each major interoperability criterion in your inventory, identify one or two routine workflows that exercise that capability. Examples include sending a summary of care to an outside specialist using 170.315(b)(1) functionality or a patient downloading their record or using an app that connects through a 170.315(g)(10) standardized API.

For each use case, document three things: the trigger event, such as a referral; the exact steps staff take in the EHR; and the evidence the system produces, like confirmation messages, logs, or screenshots. Store these as short narratives with labeled images in a shared folder.

A small library of use cases shows that your system does more than technically meet a criterion. It demonstrates that your staff can and do use 170.315 capabilities in predictable ways, which is powerful evidence in any review.

3. Maintain an interoperability configuration record

Many interoperability failures are not about missing features but about settings. For example, API endpoints might be disabled by default, a patient portal might not be activated for all providers, or connection settings for a health information exchange might be incomplete. ONC’s HTI 1 and Cures updates emphasize the importance of making standardized APIs available and publishing certain endpoint information for 170.315(g)(10) modules.

Create a brief configuration document for your environment. It should identify whether the patient portal is live, whether the FHIR API is enabled, what authentication methods are used, and which external networks or exchanges are connected. Whenever a new interface goes live or a setting is changed, update this document and keep a copy of the related change ticket or email.

Retaining this configuration record gives you a timeline that shows the system was capable of interoperable exchange under 170.315 at specific points in time and that the clinic made reasonable efforts to keep those capabilities operational.

4. Log difficult or failed data exchange requests

Not every data sharing request goes smoothly. Some are technically impossible or fall under lawful exceptions in the information blocking rule. Keeping a short, structured log of problematic interoperability requests helps distinguish between system limitations and potential documentation gaps.

For each difficult request, record who asked for what data, which 170.315 related capability would normally support that exchange, why it failed or was delayed, and what workaround was used. Where applicable, note whether an information blocking exception applied.

Over time, this log shows both that you are using the system’s interoperable features and that any persistent barriers are being tracked and addressed rather than ignored, which supports a good faith posture under the Cures Act framework.

5. Align interoperability evidence with HIPAA security documentation

Interoperability and security must coexist. 45 CFR 170.315 includes privacy and security criteria that health IT modules must meet, and these line up with provider responsibilities under the HIPAA Security Rule.

Map each major interoperable function to the corresponding HIPAA safeguards you have already documented. For example, tie your patient portal and API access controls to your access management policies, and tie your summary of care exchange workflows to your transmission security and integrity controls.

This crosswalk reassures auditors that your drive for interoperability under 170.315 is balanced by reasonable protections and that your documentation sets are integrated rather than siloed.

Taken together, these controls create a practical playbook. They do not require new software or consultants, only disciplined use of screenshots, short narratives, and simple tables tied explicitly to 170.315 language.

Case Study

A multi-specialty clinic with two locations used an EHR that had been updated to the 2015 Edition Cures Update and was certified for multiple 170.315 criteria, including summary of care exchange and standardized APIs. When a regional hospital attempted to connect via FHIR to receive discharge summaries, the clinic’s vendor said the functionality was available and pointed to the ONC certification listing.

In practice, the API was never fully configured. User roles lacked permissions to manage application registrations, and the endpoint was not published anywhere partners could see it, even though the certification criterion 170.315(g)(10) assumed a discoverable, standards based API. The hospital complained that the clinic was refusing to share data. Patients echoed that they could not use third party apps to access their information. The situation attracted attention from the clinic’s ACO and raised concerns about information blocking.

When asked to show that their system was interoperable, the clinic had only a vendor brochure and a generic certification statement. There were no screenshots of the API configuration pages, no record of test connections, and no documentation of failed requests. The ACO pushed the clinic to correct the problem and warned that future participation might depend on demonstrable interoperability.

To recover, the clinic:

• Built a criteria inventory listing each 170.315 capability their EHR version supported.

• Worked with the vendor to enable and test the FHIR API, capturing screenshots and saving a simple configuration record.

• Created a small use case library showing real examples of patients connecting apps and external partners querying the API.

• Started a log of any API related access problems, noting whether they arose from technical limitations or external factors.

Within a few months, the clinic could produce a concise evidence packet that showed both that its system met the relevant 170.315 criteria and that staff were actively using those capabilities. The ACO accepted this documentation, and the hospital and patients confirmed that connections were now working. The clinic avoided formal enforcement, but the episode made clear how risky it had been to rely on vendor certification without local proof.

Reviewing this table a few times a year helps a small clinic stay ahead of documentation gaps and prepares it to respond quickly if any party questions the interoperability of its systems.

Common Audit Pitfalls to Avoid Under 45 CFR 170.315

Audits and investigations around interoperability often reveal the same underlying mistakes. Addressing them proactively reduces risk and saves time.

• Assuming that vendor certification alone proves your environment is interoperable. Error: treating 45 CFR 170.315 as a vendor only concern with no local documentation. Consequence: when challenged, the clinic cannot show that its particular configuration and workflows actually use the certified capabilities.

• Not knowing which criteria your EHR is certified for or which version is deployed. Error: relying on outdated or generic certification statements unrelated to your installed build. Consequence: misstatements in payer attestations or network agreements and confusion when external partners reference specific 170.315 criteria.

• Leaving key interoperability features disabled or partially configured. Error: failing to turn on patient portals, standardized APIs, or summary of care exchange options even though the module is certified for them. Consequence: accusations of information blocking or failure of Promoting Interoperability measures.

• Lacking any record of how common interoperability workflows are executed. Error: having no documented use cases or screenshots for data exchange, app access, or patient downloads. Consequence: difficulty proving that staff are trained and that the system functions as advertised under 170.315.

• Ignoring problematic data exchange episodes. Error: treating repeated connection failures or partner complaints as isolated incidents without logging them. Consequence: patterns of failure go unaddressed, and the clinic cannot demonstrate good faith efforts to use its certified capabilities.

By recognizing these pitfalls and correcting them early, a small practice can show that it understands how 45 CFR 170.315 shapes its technology environment and that it has taken reasonable, documented steps to make interoperability real, not just theoretical.

Proving interoperability is not purely a technical task. It depends on people who understand the clinic’s technology enough to keep basic documentation in order. Designating an interoperability champion, even if that person wears multiple hats, creates a focal point for responsibilities tied to 170.315 criteria.

Short internal briefings can keep the topic alive. For example, once a quarter, the champion can pick one criterion from the inventory and walk staff through how it works in practice, using the stored use case library. This keeps front line teams aware that interoperability is a real requirement grounded in federal rules, not just a vendor sales term.

Simple metrics such as the number of documented use cases, the freshness of the configuration record, and the count of unresolved data exchange issues can give leadership a quick view of where the clinic stands. When combined with HIPAA and security reviews, this governance approach helps a small practice show that it takes both access and protection of electronic health information seriously.

The Cures Act’s push for interoperability made 45 CFR 170.315 more than a developer facing regulation. It became the technical backbone for how providers prove that their systems can exchange data, support patient access, and interoperate with partners. For small practices, the documentation trap is real. Relying on vendor labels without local proof of capabilities, configuration, and use exposes the clinic to unnecessary risk.

A lean, criteria based documentation set can close this gap. By knowing which 170.315 criteria apply, showing how workflows exercise them, and tracking configurations and problem cases, a clinic can respond confidently when asked to prove that its health IT is interoperable. That proof supports better relationships with patients, payers, and regulators while reinforcing a culture of transparency and accountability.

Immediate next steps for a small clinic:

1. Create a one-page inventory listing your EHR products, versions, ONC certification identifiers, and the specific 170.315 criteria you rely on for interoperability.

2. For at least three key criteria, document a real use case with screenshots or logs that show how staff send, receive, or expose data in normal operations.

3. Draft a short configuration record for your portal, APIs, and primary exchange connections and update it whenever settings change.

4. Start an interoperability issue log so that failed or difficult data exchanges are recorded and reviewed, not forgotten.

5. Fold these artifacts into your broader compliance binder so that interoperability documentation sits alongside HIPAA and security evidence rather than in a forgotten folder.

Recommended compliance tool: 

A combined “interoperability binder” that contains your 170.315 inventory, use case narratives, configuration record, and issue log in one place.

Advice: Before your next contract renewal or payer audit, pull one interoperability scenario end to end and verify that you can produce clear evidence for every step without calling your vendor.

• 45 CFR 170.315 Certification Criteria for Health IT (eCFR) (ecfr.gov)

• 45 CFR Part 170 Health Information Technology Standards, Implementation Specifications, and Certification Criteria (eCFR) (ecfr.gov)

• 2015 Edition Cures Update Fact Sheet (ONC) (healthit.gov)

• Standardized API for Patient and Population Services Certification Companion Guide (ONC) (healthit.gov)

• Medicare Promoting Interoperability Program Criteria and Related 170.315 References (CMS) (cms.gov)

• Information Blocking Guidance and Resources (ONC) (healthit.gov)

• Interoperability and Information Blocking Regulations Overview (ACP) (acponline.org)