Search "HL7 FHIR certification" and you’ll find courses that promise to certify you, your staff, or your organization. But that framing misleads most practices evaluating an electronic health record (EHR) or health information exchange (HIE) vendor. FHIR certification, as HL7 International defines it, is a credential earned by an individual — a developer, integration engineer, or informaticist — not a stamp your practice or your software vendor can simply buy. What actually governs whether a vendor’s product meets federal interoperability requirements is a different, more consequential set of criteria under ONC and CMS rules. Confusing the two can leave a practice signing a contract with a vendor that checks the wrong box.
What "FHIR Certified" Actually Means
HL7 FHIR certification is a professional credential for individuals who demonstrate competency implementing the FHIR specification — the ability to build, troubleshoot, and work with FHIR-based data exchange. A vendor can employ certified developers without that translating into a compliant product, and a vendor can ship a fully compliant, ONC-certified FHIR API without a single individually-credentialed staff member. These are separate axes entirely, and vendor sales materials sometimes blur them on purpose.
What actually matters for a practice is whether the EHR or health IT product itself appears on the ONC’s Certified Health IT Product List, with its certified APIs and supporting documentation published for review. That listing — not an individual’s resume line — is the artifact a practice should ask to see.
The Compliance Bar That Actually Applies to Your Practice
Under the 21st Century Cures Act, healthcare providers, health information networks, and certified health IT developers are all classified as "Actors" subject to information blocking rules. In practice, that means your organization — not just your software vendor — carries obligations around how electronic health information (EHI) is accessed, exchanged, and used. Since January 1, 2023, certified EHR technology has been required to expose standardized FHIR APIs for patient and population-level data services. A vendor telling you FHIR support is "on the roadmap" is telling you it is currently out of compliance with a requirement that has been in force for years.
| What people confuse it with | What it actually verifies | Who holds it |
|---|---|---|
| "HL7 FHIR Certification" | An individual’s competency implementing FHIR | A developer or IT staff member |
| ONC Certified Health IT Product List entry | The vendor’s product meets Cures Act API and USCDI criteria | The EHR/HIE vendor |
| Information blocking compliance | Your organization’s actual data-sharing practices and contracts | Your practice, as a regulated "Actor" |
A Buyer’s Checklist Before You Sign
When evaluating an EHR, HIE connection, or any health IT product that claims FHIR support, ask the vendor to answer — in writing — each of the following:
- Is the product on the ONC Certified Health IT Product List, and can you confirm the certification covers a FHIR Release 4 (R4)-based API specifically, not an older or proprietary interface marketed as "FHIR-like"?
- Does the API support United States Core Data for Interoperability (USCDI) content, or only a narrow subset of clinical data types?
- Can data be accessed and exchanged "without special effort" — the actual regulatory standard — or does the vendor require a lengthy custom integration project, additional licensing fees, or a separate contract amendment to activate API access?
- Are patients able to access their own EHI at no cost through a patient-facing app of their choice, without the vendor charging the patient or the practice a per-connection fee?
- Does the vendor publish its API documentation publicly, or does access require an NDA and a sales call — a pattern regulators have flagged as a potential information-blocking practice?
- How does the vendor handle the eight recognized exceptions to information blocking (such as privacy, security, and infeasibility exceptions), and can it point to specific contract language rather than a verbal assurance?
- Who is responsible for audit logging of data access and exchange — the vendor, your practice, or both — and can those logs be produced if a patient or auditor requests them?
A vendor that answers all seven cleanly, with references to its Certified Health IT Product List entry rather than marketing language, has done the harder work already. A vendor that answers with reassurance instead of documentation is asking your practice to absorb the compliance risk on its behalf.
Why This Gets Confusing for Small and Mid-Size Practices
Larger health systems typically have a dedicated informatics or compliance function that reads ONC rulemaking directly. A solo or small-group practice usually doesn’t, and vendors know it. The result is a sales conversation where "FHIR-enabled" gets used as a blanket reassurance rather than a specific, verifiable claim. The distinction matters because the practice — not the vendor — is the regulated Actor when a patient or another provider organization complains that data access was blocked or delayed.
This is precisely the kind of evaluation gap a neutral, non-selling intermediary is positioned to close: someone whose only job is helping a practice match against vendors that can actually document compliance, rather than a vendor whose job is closing the sale regardless of documentation.
The Bottom Line
Don’t ask a vendor whether their staff is "HL7 FHIR certified" — that credential belongs to individuals, not products, and it says nothing about regulatory compliance. Ask instead whether the product itself is on the ONC Certified Health IT Product List with a documented FHIR R4 API, whether USCDI data is supported, and whether access is genuinely available without special effort or added fees. Practices that get this distinction backwards risk signing with a vendor that sounds compliant in a sales deck and isn’t compliant in the contract — a gap that becomes the practice’s problem, not the vendor’s, the moment a patient or auditor asks.