“FHIR expertise” is now easy to claim. It appears in sales decks, partner pages, and healthcare software development proposals as if it were a single skill. It is not. In production, FHIR sits at the intersection of backend engineering, healthcare data modeling, identity, compliance, clinical workflow, vendor-specific EHR behavior, and operational discipline. A team can know what a Patient resource is and still be a poor choice for a serious integration.
That distinction matters because healthcare software failures tend to be predictable. They are rarely just “bugs.” They usually come from known patterns: weak ownership across vendors, late integration testing, underestimating workflow change, poor data mapping, insufficient observability, and treating security as a paperwork problem rather than a system design problem.
The failed launch of HealthCare.gov is still a useful warning because the GAO pointed to ineffective planning and oversight across core contracts and system capability changes, not merely a bad front end. (GAO),The UK’s National Programme for IT in the NHS is another: the National Audit Office found that the rollout of detailed electronic care records was far below expectations and that the core aim of a universal electronic care record would not be achieved. National Audit Office (NAO). More recently, the VA’s Oracle Cerner EHR modernization has shown how hard it is to align configuration, workflow, reliability, and patient safety at scale; GAO reported in March 2025 that VA had made improvements but still had about 1,800 unresolved configuration change requests as of February 2025. (GAO)
The 2024 Change Healthcare ransomware incident added a different lesson: a third-party healthcare technology vendor can become nationally consequential infrastructure, and weak resilience can disrupt care, claims, eligibility, and cash flow across the system. (HHS.gov).
So the question is not simply, “Does this partner know FHIR?” The better question is: “Can this partner avoid the failure modes that have already hurt healthcare technology projects?”
A CTO evaluating a FHIR integration partner should treat the process more like a backend systems interview than a marketing qualification exercise. Ask concrete questions. Ask for examples. Ask what they would do when Epic, Oracle Health, athenahealth, a regional HIE, and a lab interface all behave differently. Ask where they expect the integration to fail first.
Lets dive deep into what expertise really means:
Table of Contents
- Start with the basics: what FHIR is, and why it matters in 2026
- FHIR R4 is not HL7 v2 with a newer name
- The evaluation method: ask questions that expose predictable failure
- The strongest signal: how they talk about failure
- Red flags in a FHIR development partner
- What a good answer sounds like
- Conclusion
Start with the basics: what FHIR is, and why it matters in 2026
FHIR, or Fast Healthcare Interoperability Resources, is an HL7 standard for exchanging healthcare data. The key idea is that clinical and administrative concepts are represented as modular “resources,” such as Patient, Observation, Condition, MedicationRequest, Encounter, and DocumentReference. FHIR is designed to work with modern web patterns: REST APIs, JSON, XML, OAuth-based authorization, and implementation guides that constrain broad resources into practical rules for a specific market or use case. HL7 describes FHIR as a standard for healthcare data exchange, and FHIR R4 remains one of the most important production baselines in the U.S. market. (FHIR Build)
FHIR matters for digital health startups in 2026 because it is now part of the expected access layer for EHR data. The 21st Century Cures Act Final Rule pushed the industry toward standardized API access and implemented information blocking provisions intended to support access, exchange, and use of electronic health information. (ONC) ONC’s FHIR resources also frame FHIR as part of the federal strategy for health data interoperability, and US Core continues to define practical constraints on FHIR R4 resources for U.S. patient data access. (ONC)
That does not mean FHIR has made healthcare integration easy. It means the industry has a more standardized surface area for some integration use cases. Underneath that surface are still vendor-specific constraints, local configuration, incomplete data, inconsistent terminology, patient matching problems, access-control complexity, legacy HL7 v2 feeds, CDA documents, and operational requirements that do not disappear because an endpoint returns JSON.
FHIR R4 is not HL7 v2 with a newer name
A serious partner should be able to explain the difference between FHIR R4 and HL7 v2 without turning it into a slogan.
HL7 v2 is the older and still widely used messaging standard. It is event-driven: systems send messages such as admissions, discharges, transfers, orders, results, and billing-related events. HL7 itself describes v2 as a standardized protocol for exchanging healthcare-related data between systems through defined message interactions. (HL7 V2) The National Library of Medicine notes that HL7 v2 remains the most used health information exchange standard in the United States. (National Library of Medicine)
FHIR R4 is more resource- and API-oriented. Instead of only pushing event messages from one system to another, a client can request, search, create, or update resources through a FHIR API, depending on permissions and server capabilities. US Core then narrows the broad FHIR specification into a U.S.-specific implementation guide, defining minimum constraints, required elements, vocabulary expectations, and RESTful interactions for patient data access. (FHIR Build)
The practical difference is this: HL7 v2 often behaves like a stream of operational events, while FHIR often behaves like a structured data access layer. A qualified integration partner knows when each is appropriate. For example, HL7 v2 may still be the right mechanism for real-time ADT feeds or lab result workflows. FHIR may be the right choice for patient-facing apps, provider-facing apps, structured record access, SMART on FHIR launch, or data retrieval aligned with US Core. CDA and C-CDA documents may still matter when the workflow depends on document exchange rather than granular resource access.
A partner who says “we’ll just use FHIR” without asking about the actual workflow is not being efficient. They are skipping the system design step.
The strongest signal: how they talk about failure
The best interview questions are not trivia questions. They should reveal whether the partner has actually delivered production integrations and whether they understand where healthcare projects break.
1. Which FHIR version, implementation guide, and profiles are you assuming?
A weak answer is: “FHIR is standardized, so it should work across systems.”
A better answer starts with versioning and constraints. In the U.S., many integrations still center on FHIR R4, US Core profiles, SMART on FHIR, and vendor-specific implementation details. US Core is based on FHIR R4 and defines minimum constraints on FHIR resources, required vocabularies, and minimum RESTful interactions. (FHIR Build) SMART App Launch defines OAuth-based patterns for authorization, authentication, and integration with FHIR-based systems. (FHIR Build)
The partner should ask which resources are needed, which profiles apply, which EHRs are in scope, which USCDI data classes matter, whether write-back is required, and whether the product must support patient launch, provider launch, backend services, or bulk export. They should also ask whether the integration must support Epic, Oracle Health/Cerner Ignite APIs, Athenahealth FHIR APIs, HIE exchange, custom HL7 v2 interfaces, or some combination of these.
Epic, Oracle Health, and athenahealth all expose developer documentation and FHIR-related access patterns, but each ecosystem has its own onboarding, scopes, app registration, sandbox behavior, and production approval path. (Epic on FHIR) A partner who treats them as interchangeable is likely to underestimate the work.
2. How do you validate against real implementation guides, not just example payloads?
FHIR examples are useful, but they are not enough. A real integration must validate resources against the applicable profiles, handle required bindings, tolerate missing optional data, and fail gracefully when the EHR returns partial or locally coded information.
The partner should be comfortable discussing CapabilityStatement, profile validation, terminology bindings, cardinality, extensions, search parameters, pagination, _include, _revinclude, history, conditional operations, and error responses such as OperationOutcome. They do not need to recite the specification from memory. They do need to sound like they have debugged it.
A useful follow-up is: “Show us how you would ingest an Observation resource and decide whether it is a lab result, vital sign, social history item, or something else.” The answer should involve profile, category, code system, value type, effective time, performer, reference ranges, units, and provenance. If the answer is just “we map the JSON fields,” that is not enough.
3. What is your strategy for terminology and semantic drift?
A FHIR API can return syntactically valid data that is still semantically hard to use. A blood pressure observation, a hemoglobin A1c result, a medication, or a problem-list item may be encoded differently across systems. The team needs a terminology strategy involving code systems such as LOINC, SNOMED CT, RxNorm, ICD-10-CM, CPT, and local codes, depending on the domain.
This is where many integrations become quietly dangerous. The UI appears to work, but analytics are wrong. A care-gap engine misses patients. A medication list looks complete but is not reconciled. A patient-facing app displays a clinical value without enough context.
A qualified partner should be able to explain how they normalize codes, preserve original source codes, version mappings, handle unmapped values, and separate clinical interpretation from raw data transport. They should also know when not to normalize too aggressively. In healthcare data, losing provenance can be worse than leaving the data messy.
4. How do you handle identity, authorization, and SMART on FHIR launch?
SMART on FHIR is not just “OAuth for healthcare,” though OAuth is central to it. The SMART App Launch Framework defines patterns that let apps launch from inside or outside an EHR or patient portal and connect to FHIR-based data systems for clinician, patient, and other workflows. (FHIR Build)
The partner should understand launch context, scopes, patient context, encounter context, public versus confidential clients, refresh-token behavior, backend services, and how authorization differs between patient-facing and provider-facing applications. Epic’s documentation, for example, includes OAuth guidance, client IDs, and app design expectations. (Epic on FHIR) Athenahealth’s FHIR API documentation likewise ties API access to accepted OAuth scopes. (Athenahealth Document Portal)
A weak partner will say, “We’ll get a token and call the API.” A strong partner will ask who the user is, what they are allowed to see, whether the app is launched in context, how consent is represented, what happens when the authorization expires, how audit logs are captured, and how the system behaves when the EHR grants narrower scopes than expected.
5. What is your patient matching and record-linking approach?
FHIR does not solve patient identity by itself. It can represent identifiers, demographics, links, and references, but the hard part is determining whether two records belong to the same person and what confidence is required before combining them.
A partner should ask about enterprise master patient indexes, local MRNs, payer member IDs, probabilistic matching, deterministic matching, duplicate records, merged patients, and cross-organization exchange. They should also distinguish between matching for display and matching for clinical action. A false positive can be more dangerous than a missed match, depending on the use case.
If the product pulls data through TEFCA, a QHIN, an HIE, or multiple EHRs, patient matching becomes a core architecture issue rather than a downstream cleanup task. TEFCA is intended to establish a common floor for nationwide exchange, and QHINs are part of that shared exchange model. (ONC) That broader exchange model is useful, but it does not remove the need for careful identity and consent design.
6. What do you do when the EHR behaves differently from the sandbox?
This may be the most important practical question.
Sandboxes are necessary, but they are not production. They often have clean example data, predictable patients, and simplified workflows. Production EHR environments have custom configuration, local terminology, missing fields, old data, duplicate records, unexpected permissions, throttling, and operational constraints.
A qualified partner should have a production-readiness checklist. It should include test patients, app registration, endpoint discovery, environment-specific scopes, rate limits, error handling, monitoring, audit logging, rollback procedures, support escalation, and stakeholder signoff from clinical, security, compliance, and IT teams.
For Epic integration, Oracle Health/Cerner Ignite APIs, and athenahealth integration, the partner should already expect that documentation and sandbox behavior are only part of the job. The actual implementation depends on the customer’s configuration and approval path. (Epic on FHIR)
7. How long will the FHIR integration take?
There is no honest universal answer. A qualified partner should refuse to give a single estimate before understanding the scope.
As a planning heuristic, a read-only SMART on FHIR prototype against a sandbox might take a few weeks. A production single-EHR integration with patient or provider launch, security review, app registration, QA, and go-live support is more often measured in a few months. A multi-EHR integration, write-back workflow, bulk data export, payer-provider exchange, HIE/QHIN connectivity, or hybrid FHIR plus HL7 v2 implementation can take several months or longer.
The estimate should depend on at least these variables: number of EHRs, number of data domains, read versus write requirements, patient-facing versus clinician-facing launch, need for bulk export, terminology normalization, patient matching, security review, legal review, BAA execution, vendor approval, and clinical workflow validation.
A partner who gives a fast estimate without asking those questions may still be able to build a demo. The risk is that they are not estimating the integration. They are estimating the happy path.
8. What compliance posture should the partner have?
For healthcare software, compliance posture is not the same as having a HIPAA slide in the sales deck.
At minimum, the partner should understand when they are acting as a business associate and be willing to sign a Business Associate Agreement when their work involves creating, receiving, maintaining, or transmitting PHI on behalf of a covered entity or another business associate. HHS states that HIPAA generally requires covered entities and business associates to enter contracts ensuring that business associates appropriately safeguard protected health information. (HHS.gov)
They should also have a practical HIPAA Security Rule posture. That means administrative, physical, and technical safeguards to protect electronic protected health information, including confidentiality, integrity, and availability. (HHS.gov) In engineering terms, this should show up as access control, least privilege, encryption, audit logging, secure SDLC, incident response, backup and disaster recovery, vulnerability management, vendor risk management, and workforce training.
SOC 2 Type II can be useful evidence because it examines controls over time, typically around security and, where relevant, availability, processing integrity, confidentiality, and privacy. AICPA’s Trust Services Criteria define those control categories for SOC 2 examination contexts. (AICPA & CIMA) HITRUST CSF can also matter for healthcare organizations that want a more healthcare-specific control framework; HITRUST describes its CSF as a threat-adaptive control library harmonizing many frameworks and standards. (HITRUST Alliance)
None of these labels automatically proves that the partner can implement FHIR well. But the absence of a serious security and compliance posture is a strong negative signal.
The strongest signal: how they talk about failure
A good FHIR partner does not pretend implementation is clean. They can tell you where the edge cases are.
They should talk about retries, idempotency, dead-letter queues, audit trails, partial failures, rate limiting, schema drift, stale tokens, patient merges, missing references, deleted or entered-in-error resources, provenance, backfills, and alerting. They should be able to explain how they know the integration is healthy after go-live. They should know which failures are safe to retry and which need human review.
They should also be able to explain what they will not do. For example: they should not write back clinical data without a workflow owner, they should not flatten every clinical object into a lossy internal schema, they should not assume US Core support means every field is populated, and they should not treat EHR certification requirements as proof that a specific customer environment will behave exactly like the documentation.
Red flags in a FHIR development partner
There are a few predictable warning signs.
The first is demo-first thinking. If the partner wants to show a slick UI before asking about data quality, launch context, profiles, scopes, and workflow, they may be optimizing for the sales process rather than the implementation.
The second is standard-only thinking. Standards matter, but real deployments involve local variation. Anyone who says “FHIR solves interoperability” without qualification is not being serious about interoperability in healthcare.
The third is compliance minimalism. If the partner treats HIPAA, BAA, SOC 2 Type II, HITRUST CSF, audit logging, and incident response as administrative chores rather than engineering constraints, they are likely to create risk that appears only after procurement is finished.
The fourth is no migration or fallback plan. Many digital health products still need HL7 v2.x, CDA, flat files, SFTP, payer APIs, or manual reconciliation somewhere in the implementation. A partner who cannot work across old and new integration patterns may force the product into a technically elegant but operationally fragile architecture.
The fifth is no ownership model. Healthcare integration crosses product, engineering, security, legal, clinical operations, customer IT, and EHR vendor teams. If the partner cannot say who owns each dependency, they are likely to lose time in handoffs.
What a good answer sounds like
A strong partner might say something like this:
“We need to start by identifying the workflow and data domains, then map those to FHIR resources, US Core profiles, SMART launch requirements, and vendor-specific constraints. We will validate against the relevant implementation guides, inspect the EHR capability statements, confirm scopes, and define how we handle missing data, terminology mapping, patient identity, and audit logs. We should expect sandbox data to be cleaner than production, so we will plan a staged rollout with test patients, monitoring, rollback, and clinical validation. If the workflow requires real-time eventing or operational messages, we may need HL7 v2 in addition to FHIR. If it requires document exchange, CDA may still be relevant. Before production, we need BAA coverage, security review, incident response alignment, and evidence of controls.”
That answer is not exciting. That is the point. The right partner should make the implementation feel less mysterious and more inspectable.
Conclusion
FHIR expertise is not a claim. It is a set of engineering behaviors.
A capable healthcare software development partner should understand FHIR R4, US Core, SMART on FHIR, HL7 v2, CDA, Epic integration, Oracle Health/Cerner Ignite APIs, athenahealth integration, TEFCA, QHINs, HIPAA, BAA obligations, SOC 2 Type II, and HITRUST CSF well enough to explain how those pieces affect the actual system being built. More importantly, they should know where standards stop and implementation begins.
The safest way to evaluate them is to ask questions that expose predictable failure: versioning, profiles, terminology, authorization, patient matching, production variance, security, observability, rollout planning, and ownership. The goal is not to find a partner who says FHIR is easy. The goal is to find one who can make a difficult integration boring in production.
