Look up the product on the Certified Health IT Product List and confirm it holds the § 170.315(g)(10) criterion — "Standardized API for patient and population services." That criterion is the one that requires a FHIR-based API supporting both single-patient access and multi-patient data response, including bulk export. If the listing does not hold (g)(10), the vendor's "open API" is whatever they decide it is. If it does hold (g)(10), your next job is to test whether the capability is genuinely usable, because certification proves conformance in a lab, not convenience in production.
The short answer
Two checks, in order. Check one is free and takes ten minutes: find the product and version on CHPL, confirm (g)(10) is present, note the CHPL Product Number. Check two takes a demo session: make the vendor perform an actual multi-patient export in front of you, and time it. Practices that do only the first end up owning a certified API they cannot practically use. Practices that skip both end up staring at an interface quote three years later.
Start with the CHPL listing
Certification in the ONC Health IT Certification Program is granted per product, per version, and per criterion. "We're certified" tells you nothing; "this version holds these criteria" tells you everything. Ask the vendor for the exact product name, developer name, and version you would be running at go-live, then look it up yourself on CHPL rather than accepting a screenshot.
What to confirm on the listing:
- The developer name matches the company selling to you. Resellers and private-label arrangements are common.
- The version matches the one in your quote, not an older certified one.
- § 170.315(g)(10) is among the certified criteria.
- Status is active, not suspended or withdrawn.
- There is published API documentation and a service base URL you can actually reach.
- Any open surveillance activity or non-conformities — these are public, and reading them is free diligence.
What the (g)(10) criterion actually requires
The (g)(10) test method is published by ONC and is worth reading in the original, but the shape of it is this. A certified module must respond to requests for a single patient's data and to requests for multiple patients' data as a group, according to adopted standards. The adopted standards include HL7 FHIR Release 4.0.1, the US Core Implementation Guide, the SMART App Launch Implementation Guide, and — for the multi-patient case — the FHIR Bulk Data Access (Flat FHIR) specification, with mandatory support for the "group-export" operation.
Some specifics that matter commercially:
| Requirement | Why a buyer should care |
|---|---|
| Multi-patient data response via bulk export | This is your population-health, analytics, and quality-reporting path. It is also, in practice, a portability path. |
| Mandatory "group-export" operation | You can export a defined cohort, not just one chart at a time. |
| SMART App Launch support | Third-party apps can be launched against the EHR without a bespoke integration project. |
| Refresh tokens valid at least three months | Connected applications do not silently break every few weeks — a real operational cost if they do. |
| SMART Backend Services authorization | System-to-system access (your analytics platform, your registry) works without a human in the loop. |
| Published API documentation | Your future vendor can read the docs without signing an NDA with your incumbent. |
ONC's Standards Version Advancement Process also lets developers certify against newer approved versions of these standards. So "which version of US Core do you support?" is a legitimate and revealing question.
Single-patient access vs. bulk export
Buyers routinely conflate these, and vendors are happy to let them. Single-patient API access powers the patient-facing app ecosystem: a patient authorizes an app, the app retrieves that patient's record. It is valuable, and it is the part most vendors demo.
Bulk export is a different capability with different plumbing. It is asynchronous, produces files rather than a live response, is authorized system-to-system rather than by a patient, and is what you need to run quality measures, feed a registry, populate an analytics warehouse, or leave. It is the harder one and the one with commercial consequences — so it is the one to test.
Certified does not mean usable
Certification is a conformance test: it confirms the product did specified things correctly in a test environment against test data. It does not confirm that the API is fast, that it is documented well enough for your analytics vendor to use, that it is included in your price, or that the export completes in a useful window on a database the size of yours. All of those are separately evaluable, and none appear on the CHPL listing — which is why the certification check is step one and never step two.
A practical test plan for the demo
- Before the demo: confirm (g)(10) on CHPL and pull the vendor's published API documentation. Read it, or have whoever will build against it read it.
- Ask for the service base URL and confirm it resolves.
- Ask which FHIR / US Core / Bulk Data versions the certified module supports, and whether they have advanced to newer approved versions.
- Watch a single-patient retrieval through a third-party app using SMART App Launch.
- Watch a group export. Time it. Ask what the largest cohort a customer has successfully exported is.
- Ask about throttling and rate limits. An API with an undisclosed rate limit is an API you cannot plan against.
- Ask what it costs. Per connection, per app, per transaction, per year. Get it in writing.
- Ask who is allowed to connect. Does the vendor gate which third parties may register an app?
Fees, access, and who is allowed to connect
This is where a technical evaluation turns commercial. A vendor can hold (g)(10), publish the docs, and still make API access practically unavailable through pricing or an approval process for third-party apps. If that happens, the relevant framework is the information blocking regulation — in particular the Fees exception at 45 CFR 171.302, which sets conditions on fees charged for accessing, exchanging, or using electronic health information.
The practical move is not to threaten anyone. It is to ask, before signature, exactly what API access costs and who decides which applications may connect — and to get the answer in the contract. A vendor who intends to be reasonable loses nothing by writing it down.
Contract language worth asking for
- The vendor will maintain active certification for § 170.315(g)(10) for the full term, and loss of it is a material breach with a termination right.
- API access, including bulk export, is included at the stated price, with any fees enumerated now rather than determined later.
- The practice may authorize third-party applications of its choosing, subject only to defined, non-discriminatory security requirements.
- On termination, the vendor will provide a complete export of practice data in the standards-based format, within a defined number of days, at a price stated in the contract.
- Published API documentation will remain publicly available for the term.
The takeaway
The API section decides the difference between a system you own and a system that owns you — and it is almost always evaluated last, briefly, by someone who is tired. Do it early. Confirm (g)(10) on CHPL: free, public, ten minutes. Then make the vendor run a real group export in front of you, and get the price of API access in writing. Interoperability that exists only on a certificate is interoperability you will pay for twice: once in the subscription, and again on the way out.
Common questions
What is the (g)(10) certification criterion?
§ 170.315(g)(10), "Standardized API for patient and population services," is the ONC certification criterion requiring a FHIR-based API that supports both single-patient data requests and multi-patient data responses, the latter via the FHIR Bulk Data Access specification with mandatory group-export support.
Does every certified EMR support bulk export?
Not automatically — it depends on which criteria the specific product and version are certified to. Check the CHPL listing for the exact version you will be running and confirm (g)(10) is present rather than assuming it.
Can a vendor charge for API access?
Fees are possible but constrained. The information blocking Fees exception at 45 CFR 171.302 sets conditions on charging for access to, exchange of, or use of electronic health information. Ask for all API fees in writing before you sign, including at termination.
Is a FHIR API the same as a data migration?
No. A standards-based bulk export gives you structured clinical data in a defined format; a migration is a project that maps that data into a new system's model, with reconciliation and acceptance testing. The API makes the migration possible, not automatic.
Common questions
What is the (g)(10) certification criterion?
Section 170.315(g)(10), "Standardized API for patient and population services," is the ONC certification criterion requiring a FHIR-based API that supports both single-patient data requests and multi-patient data responses, the latter via the FHIR Bulk Data Access specification with mandatory group-export support.
Does every certified EMR support bulk export?
Not automatically — it depends on which criteria the specific product and version are certified to. Check the CHPL listing for the exact version you will be running and confirm (g)(10) is present rather than assuming it.
Can a vendor charge for API access?
Fees are possible but constrained. The information blocking Fees exception at 45 CFR 171.302 sets conditions on charging for access to, exchange of, or use of electronic health information. Ask for all API fees in writing before you sign, including at termination.
Is a FHIR API the same as a data migration?
No. A standards-based bulk export gives you structured clinical data in a defined format; a migration is a project that maps that data into a new system's model, with reconciliation and acceptance testing. The API makes the migration possible, not automatic.