ONC-Certified EHR: What Certification Covers, and Why It Isn’t Integration-Ready

A scoping call I have more often than I’d like goes like this. A founder shares a screen with an EHR’s listing on the federal certified products list and says the integration should be quick, because the EHR is ONC-certified. Certification is real, and it’s useful. It just doesn’t mean what that screen is being used to say.

What is an ONC-certified EHR?

An ONC-certified EHR is software tested and certified under the federal ONC Health IT Certification Program, run by the Assistant Secretary for Technology Policy and Office of the National Coordinator for Health IT (ASTP/ONC) inside HHS. Certification confirms specific capabilities in testing. You can check any product on the Certified Health IT Product List (CHPL): look for § 170.315(g)(10) among its certified criteria and for the vendor’s published API documentation.

• Voluntary, and tested by third parties. Developers choose to certify. Accredited testing labs run the tests and certification bodies issue the certification (healthit.gov, checked October 2026).
• Why it matters to providers. CMS programs such as Promoting Interoperability require providers to use certified EHR technology (CMS, Certified EHR Technology).
• Getting certified yourself is a separate project with its own steps; healthit.gov’s certification pages are the place to start.

What certification guarantees your app: the (g)(10) API

The criterion that matters to a product team is § 170.315(g)(10), the standardized API for patient and population services. A certified EHR has shown it can serve patient data through a FHIR (Fast Healthcare Interoperability Resources) API built on these standards (healthit.gov test method, last updated May 15, 2026):

What the API must do is read data for one patient or many, and respond to searches for a single patient’s data. Then comes the line that matters most to a product team: “These services specifically exclude ‘write’ capabilities, where authenticated and authorized third-party applications would be able to create or modify EHI through a secure API.”

If you want the sign-in half explained, our SMART on FHIR guide walks through it.

What ONC certification doesn’t cover

Five things stand between a certified EHR and your app working inside a hospital. Passing (g)(10) shows a product’s API behaves correctly in testing; it doesn’t provision any app at any organization, and it doesn’t cover writes.

1. Writing back. The certified API reads and searches. If your product needs to file a note, update a medication list or book an appointment, that write runs on whatever the EHR vendor offers beyond certification, under its own terms.
2. Switching your app on at each organization. Each health system enables your app in its own environment. For Oracle Health (Cerner), the provisioning guide puts it plainly: “The developer provides a production application ID and client ID to the customer,” and “The customer logs an SR to Cerner Ignite APIs for Millennium for provisioning” (Oracle Health, FHIR Application Provisioning, July 2024).
3. Data your workflow needs beyond USCDI. USCDI v3 sets the floor: 94 data elements in 19 classes (USCDI v3). A booking product is a good test case. USCDI v3 carries an encounter’s scheduled appointment time, but not the open slots a patient can choose from, and booking one is a write.
4. The vendor’s developer program and review. Registration and app review run through each vendor’s program. For the certified API itself, federal rules set what the vendor must publish and what it may charge; the next section covers them. Services beyond the certified API are priced by the vendor; Oracle Health publishes its developer fees on its API Access and Fees page.
5. Production credentials and testing in that organization’s environment. Sandbox success doesn’t carry over automatically. Each organization’s environment, configuration and security review come next.

What federal rules require of the EHR vendor’s API program

The vendor’s program isn’t a free-for-all. If an EHR is certified to (g)(10), its developer is bound by the API Conditions of Certification in 45 CFR 170.404 (eCFR, current as of October 2026), and four of them matter when you plan an integration. The rule has its own names for the parties: the EHR vendor is the “Certified API Developer,” the hospital or practice is the “API Information Source,” and your product is the “API User.”

1. The terms have to be public. The vendor must publish “complete business and technical documentation … via a publicly accessible hyperlink that allows any person to directly access the information without any preconditions or additional steps” (§ 170.404(a)(2)). Find that page before you scope anything. It’s where the vendor’s terms of use, fees and technical documentation live.
2. Most fees fall on the health system, not on you. Any fee related to the certified API that the rule doesn’t permit is prohibited. The vendor may charge the health system to recover what it costs to develop, deploy and upgrade the API, and for usage costs when it hosts the API on the health system’s behalf. The one fee it may charge your company is for “value-added services … so long as such services are not necessary to efficiently and effectively develop and deploy production-ready software” (§ 170.404(a)(3)). When I go through a vendor’s fee page with a founder, that sentence is the test we hold each line to.
3. Your terms can’t be worse than a partner’s. The vendor must offer the certified API “on terms that are no less favorable than it provides to itself and its own customers, suppliers, partners,” and it can’t change terms because you compete with it or because of the revenue your app would earn (§ 170.404(a)(4)).
4. Registration runs on the vendor’s clock, and each health system still decides. A vendor may verify that an app developer is who it says it is, but that check must be “completed within ten business days” of your request, and the vendor must then “register and enable all applications for production use within five business days of completing its verification” (§ 170.404(b)(1)). Those windows cover the vendor’s own steps. The same rule requires vendors to give each health system “the independent ability to permit an API User” to connect, so switching your app on at each organization, item 2 above, stays that organization’s call.
5. The endpoints are published for free. For every customer, whether the vendor hosts the EHR or the customer runs it on site, the vendor must “publish, at no charge, the service base URLs and related organization details” patients use to reach their records, a requirement in force since December 31, 2024 (§ 170.404(b)(2)). That list is where you find each customer’s FHIR endpoint.

These rules cover the certified (g)(10) API. Writes, and any service the vendor offers beyond that API, run on the vendor’s own terms, which is item 1 above.

From certified to live: a checklist before you write code

The question to answer before development starts is what it will take to get your integration live at your first customer. These are the gates, in the order they usually come. None of them has a fixed duration; each depends on the vendor and the organization.

• Pick the first organization. The specific health system or practice, and its EHR instance.
• Confirm what you can read and write there. Certified read and search is the floor. Anything you write depends on the vendor’s own APIs and approvals.
• Register in the vendor’s developer program. Know whose name the registration is in, and who owns the app record.
• Build and test in the sandbox, including the failures. Plan for missing patients, expired tokens and rejected requests from the start.
• Pass the organization’s security review. Expect a questionnaire before anyone talks about go-live.
• Get provisioned and receive production credentials. The organization switches your app on in its environment.
• Monitor from day one. Know when a message fails before a clinician does.

What’s changing: HTI-5 and the certification program

As of October 2026, HTI-5 is still a proposed rule. ASTP/ONC published it in the Federal Register on December 29, 2025 and took comments until February 27, 2026 (healthit.gov, HTI-5 proposed rule, last updated March 31, 2026).

• What it proposes. ASTP/ONC’s overview lists 34 certification criteria to remove and 7 to revise, and names “a new foundation of Fast Healthcare Interoperability Resources (FHIR)-based application programming interfaces” as one of its three goals (HTI-5 overview presentation, February 2026).
• What it leaves alone. § 170.315(g)(10) isn’t on the proposed list of removals or revisions. Two older app-access criteria, (g)(7) and (g)(9), are proposed for removal from January 1, 2027.
• What it doesn’t change for your launch. Provisioning at each organization and the vendor’s developer program sit outside certification either way.
• What to watch. A final rule in the Federal Register. We’ll update this section when one is published.

Where ConnectHealth and Mindbowser fit

ConnectHealth is the integration layer that runs in your own cloud account. It handles each EHR’s sign-in and token work and supports full FHIR read and write (create, read, search, update, delete) where the EHR allows it. What each EHR allows is listed on FHIR capabilities, and every connection on ConnectHealth integrations. It doesn’t remove vendor registration or the hospital’s approval chain; it takes the protocol and token work off your team before those gates.

If you’d rather not run it yourself, Mindbowser engineers build the integration on ConnectHealth for you. Mindbowser is an Epic Vendor Services member, if your first customer runs Epic. For how patient data is handled in your account, see HIPAA-compliant integration.

Before you pick your first EHR

Certification tells you an EHR can serve a standard set of data through a tested API. It doesn’t tell you whether your product can write what it needs, or how your first customer will switch it on. Answer those two questions for one named organization before you build, and the certified API becomes a dependable starting point. For how EHR data moves between systems more broadly, see healthcare interoperability solutions.