FHIR adoption is widening faster than production expertise. In the 2026 State of FHIR survey, 81% of respondents said FHIR was used for at least some national health-data exchange use cases — but 75% named lack of FHIR knowledge as a barrier, the most common answer for four years running (Source: Firely/HL7 2026 State of FHIR Report). That survey reflects 101 experts across 63 countries, not a census of every implementation — but the signal holds for a healthtech founder choosing who builds their integration layer: the risk is rarely whether a partner can say “FHIR.” It’s whether they can design, secure, validate, operate, and hand over an integration that works against the EHRs and workflows you actually need. Eight things to look for, why each matters, and the red flag that says they haven’t actually done this before.
Why Does FHIR Knowledge Matter More Than a Certification?
Certifications tell you someone studied the spec. They don’t tell you someone has shipped against it. 75% of respondents to the 2026 State of FHIR survey named “lack of FHIR knowledge” as their top barrier — the same answer for four years running, even as adoption grows (Source: Firely/HL7, 2026). Real experience shows up a level above the mechanics, too: a partner who’s done this before can tell you why a workflow needs FHIR at all, and which pattern fits — SMART app launch, backend service, Bulk Data, subscriptions, document exchange, or a hybrid — and what they ruled out. “We’ll build a FHIR API for that” is applying FHIR to the problem, not solving it.
Do They Actually Understand SMART on FHIR Authorization?
SMART on FHIR isn’t “FHIR with login.” It defines OAuth 2.0-based authorization patterns for user-facing apps — whether launched from an EHR or used standalone — and for backend services that connect without a user in the loop at all (Source: HL7 SMART App Launch IG). SMART scopes define what an app may access; launch context can carry information like the active patient. Get the model wrong and the app ends up with broader access than the workflow needs, unclear user-versus-system permissions, or an authorization approach your target EHR doesn’t actually support.
Can They Deliver Interoperability in Production, Not Just a Demo?
A sandbox demo and a production integration are different skills. If your use case involves population-scale retrieval, ask about the FHIR Bulk Data ($export) operation and asynchronous processing — REST calls built for single-patient lookups tend to fall over at scale (Source: HL7 Bulk Data Access IG). Not every project needs Bulk Data — a single-record patient app may never touch it, and a partner who insists on it anyway is padding their resume, not designing your architecture. What every project needs is a real answer on deployment, monitoring, and scaling.
Do They Treat Terminology and Profiles as Infrastructure, Not an Afterthought?
FHIR resources are only interoperable if the codes inside them are. Hardcoding SNOMED, LOINC, ICD-10, or CPT mappings into application logic isn’t automatically wrong — a small, bounded mapping can live in the integration layer if it’s governed properly. “We’ll figure it out as we go” is not governance. The same goes for profiles: a base Patient or Observation resource without the applicable implementation guide (US Core is often the U.S. baseline; a payer-facing project may also need Da Vinci, CARIN, or another applicable IG) technically validates and still won’t interoperate with the systems you need it to (Source: HL7 US Core IG).
Is Privacy and Consent Architecture Built In, or Bolted On Later?
FHIR integrations that handle protected health information for a HIPAA-covered entity can place both your product and your development partner inside HIPAA’s covered-entity/business-associate framework — that’s a legal classification, not something that follows automatically just because a system touches patient data. If substance use disorder records are in scope, 42 CFR Part 2 may add its own, stricter confidentiality and consent requirements on top (Source: HHS, 42 CFR Part 2 Final Rule Fact Sheet). Be precise here: FHIR’s Consent and Provenance resources support consent management and auditability; they don’t establish compliance on their own. Actual compliance also depends on policies, role-based access controls, security safeguards, consent/authorization workflows, audit logging, data-use agreements, and — where applicable — a business associate agreement. What you’re evaluating is whether that whole picture was part of the architecture from day one, or something a security review found later.
Do They Validate Data, or Just Pass It Through?
Production integrations regularly encounter incomplete, unexpected, or nonconformant FHIR resources — it’s not an edge case you can design around later. A resource can be structurally valid JSON and still be clinically wrong — which is why profile and terminology checks matter alongside schema validation. A partner who’s done this has a pipeline covering structure, profile conformance, terminology, semantics, and business rules, with a defined answer for what happens to a resource that fails: quarantined, logged, reconciled, retried, visible to operations — not silently dropped.
Do They Understand Your Actual Workflow, or Just the Generic Connector?
This is what separates a build from a shrink-wrapped integration. Packaged connectors work where your workflow matches the one they were built for — the question is how much of your actual process falls outside that overlap, and what it costs in engineering hours to close the gap manually every month. A partner worth hiring maps your users, handoffs, exceptions, and source systems before proposing architecture, not after.
Who Owns and Supports What You Build, After Launch?
The last question is ownership, and it’s bigger than “who owns the code.” Some engagements end with you owning a platform built against your systems — changeable, extensible, yours, with the source, docs, and deployment credentials to prove it. Others end with you licensed into a product you didn’t build and can’t modify, without the access to run it yourself or move it elsewhere. You can own the code and still be stuck without the cloud credentials, CI/CD access, runbooks, and monitoring that go with it. Know which one you’re buying, in writing, before you sign — not after the first change request arrives as a new line item.
FHIR compatibility doesn’t guarantee interoperability — actual results depend on the EHR, the implementation guides, data availability, workflow design, and who owns the system after launch. That’s why these questions matter more than the standard’s name on a resume.
Frequently Asked Questions
How long does a typical FHIR integration project take for a healthtech startup?
Scope drives it — a single-EHR, read-only integration is a different project than a multi-EHR, bidirectional one with write-back. A credible partner breaks the timeline into discovery, EHR/vendor onboarding, authorization, mapping and profile work, validation, security review, production testing, and post-launch monitoring — rather than naming one number. The bigger driver of overruns isn’t scope, though. It’s versioning and validation decisions left undefined too long, forcing rework mid-project.
Is SMART on FHIR required for my app, or optional?
For many EHR-launched and patient-authorized FHIR app workflows, SMART on FHIR is the widely used authorization pattern. But the right approach depends on the target EHR, your app’s user model, and whether the workflow is user-facing or backend-to-backend. A partner should tell you which pattern your use case needs, and why — not assume SMART is the only option.
What’s the difference between FHIR R4 and R5, and does it matter which one my partner uses?
It matters. R4 is still the more common primary standard (36% of the Firely/HL7 2026 survey’s respondents, vs. 8% on R5) — but that reflects survey respondents’ national/system-level standard, not a guarantee of what every U.S. EHR supports. Version choice should follow the target EHRs, payer APIs, and implementation guides your product actually needs to support.
Do I need a HIPAA-compliant development partner, or just a HIPAA-compliant hosting environment?
A HIPAA-aligned cloud environment is necessary but not sufficient. If your partner will handle PHI on behalf of a covered entity, evaluate their security practices, access controls, incident-response process, data handling, and willingness to enter a business associate agreement where one applies — hosting compliance alone doesn’t cover any of that.
What’s a fair way to evaluate multiple FHIR development partners against each other?
Score them against the same fixed criteria instead of comparing pitches directly — proposals are easy to make sound similar. That’s why we built the FHIR Partner Evaluation Scorecard.
Let’s Talk About Your Project
Itirra builds the EHR-integration layer — FHIR architecture, SMART authorization, terminology governance, validation, and the operational support that comes after launch — for healthtech teams who need it to hold up in production, not just in a demo.
Let’s talk about your project.
Building for Epic or another major EHR? The right FHIR partner should be able to explain your SMART authorization model, target EHR workflow, implementation-guide requirements, and path from sandbox to production — not just show an API demo.
Talk to Itirra about your EHR-integrated product.
Sources
- “2026 State of FHIR Report” — Firely & HL7 (101 experts, 63 countries — read as directional signal, not a census of every implementation)
- “The State of FHIR in 2026: Analyzing Global Adoption and the Emerging Role of AI” — Firely
- “SMART App Launch Implementation Guide” — HL7
- “Bulk Data Access Implementation Guide” — HL7
- “US Core Implementation Guide” — HL7
- “42 CFR Part 2 Final Rule Fact Sheet” — HHS
- “Business Associate Contracts / HIPAA Privacy Rule Guidance” — HHS OCR