Here is the number nobody wants to say out loud: most healthcare interoperability projects fail. Not because FHIR is broken. Not because the technology doesn't exist. They fail because the organizations running them solve the wrong problem with great precision — and spend years congratulating themselves on the technical achievement before noticing that nothing actually changed for patients or clinicians.
of health information exchange projects fail to achieve their stated data sharing goals within the first three years
Average sunk cost in failed interoperability projects before organizations acknowledge the project is not working
Median timeline before a clinical workflow change from interoperability is measurable — most projects are abandoned at month 18
Share of interoperability projects that explicitly defined a clinical outcome metric before writing the first line of integration code
01. You Started With Technology, Not With a Problem
The question "what FHIR resources do we need to implement?" is the wrong first question. The right first question is "which patient will not die if we build this?"
"We need to implement FHIR R4." Full stop. That is the project charter that launches most interoperability initiatives — and it explains why most of them fail. FHIR R4 is a standard. It is a means. The end — the actual clinical or operational outcome that justifies the investment — is frequently undefined, unstated, or assumed to be self-evident when it is not.
The organizations that succeed at interoperability start from the opposite direction. They identify a specific, measurable clinical failure — medication reconciliation errors in care transitions causing 27% of readmissions, diagnostic duplication at referral causing $380 average waste per patient, care gap closure rates stuck at 34% because the primary care team cannot see specialist recommendations in time. Then they ask: is data the problem? Is lack of timely data access what's preventing resolution? If yes — what data, from which system, to which clinician, at which moment in the workflow?
This inversion — from technology-first to outcome-first — is not a philosophical preference. It is an engineering requirement. The clinical use case determines which FHIR resources matter, which EHR systems need to be connected, what the latency tolerance is, and what "success" means. Without it, you build a technically correct integration that has no adoption because nobody changed their workflow to use the data that now theoretically flows.
Read More: FHIR Integration Architecture Guide
02. Your EHR Vendor's Incentive Is Not Your Incentive
The EHR vendor's business model depends on you needing them to access your own data. Interoperability, done properly, threatens that dependency.
This is not a conspiracy theory. It is basic economics. Epic, Cerner, Oracle Health — these are companies with shareholders, revenue targets, and product roadmaps. Their most profitable customers are deeply embedded — dependent on the vendor's proprietary interfaces, custom workflows, and data formats. A health system that can move data freely between any vendor's system is a health system that is easier to switch away from any vendor. That is not in the vendor's interest.
The ONC's 21st Century Cures Act and HTI-1 rule exist precisely because the market did not solve this problem organically. Information blocking was so pervasive and so well-documented that it took federal legislation with civil monetary penalty exposure to begin shifting vendor behavior. The regulations moved the needle — but they did not eliminate the incentive misalignment. They created a floor of required interoperability, not a ceiling of capability.
230 checks added one at a time over 18 months. No owner. No false positive tracking. Site staff answering 60% of queries with "value confirmed as entered." Protocol Amendment 4 invalidates 18 checks that nobody identifies until a monitoring visit. Database lock delayed 3 months to resolve check backlog.
The EHR vendor's integration team serves the vendor's interests, not yours. "Technically not feasible" frequently means "commercially not in our interest to enable." The ONC's information blocking rules have documentation of vendors delaying, complicating, and conditionally enabling API access that the FHIR standard requires. Negotiation leverage comes from regulatory knowledge and alternatives.
The practical implication: approach EHR vendor FHIR integrations as a negotiation informed by regulatory entitlement, not as a collaborative engineering exercise. Know your rights under the 21st Century Cures Act. Know what the ONC mandates. Know that the vendor's FHIR API is not a favor they are extending to you — it is a regulatory obligation they are fulfilling, and their CapabilityStatement must accurately represent what they support.
03. You Confused Complexity With Capability
The best FHIR integrations are simple. Not because the problem was simple — because the team had the discipline to resist scope creep and ship something physicians would actually use.
Healthcare organizations have a pathological relationship with scope. An interoperability project that begins as "let physicians see the last 90 days of lab results from the referring hospital before a consultation" inexorably expands to include medication reconciliation, care plan sharing, diagnostic imaging metadata, prior authorization status, social determinants of health data, and a patient-facing portal with real-time push notifications — all before the first integration goes to production. The project that would have succeeded in 6 months gets scheduled for 3 years and never ships.
Steve Jobs understood this about product development: the hardest discipline in building something is not adding features — it is deciding what to leave out. Interoperability is no different. A care transition data exchange that reliably delivers accurate medication lists to receiving clinicians at the moment of admission is worth more than a comprehensive health information exchange that delivers everything unreliably. Start with the smallest valuable exchange. Ship it. Measure it. Prove that data access actually changed clinical behavior. Then expand.
💡 The Minimum Viable Exchange
Define your Minimum Viable Exchange (MVE) as the smallest set of FHIR resources, from the fewest source systems, that produces a measurable clinical behavior change in a defined clinical workflow. Everything else is a subsequent iteration. A FHIR Patient resource, a MedicationRequest bundle, and a Condition list — pushed into an Epic InBasket 60 minutes before a care transition appointment — is a viable first exchange. A bidirectional, real-time, multi-system, multi-specialty health information hub is a five-year program that will consume your budget before it produces any benefit.
04. You Built the Integration. Nobody Changed Their Workflow.
Making data available is not the same as making it useful. The last mile of interoperability is always human.
Here is a scenario that plays out in health systems across the country. An interoperability team builds a technically excellent FHIR integration. Lab results from a referring hospital now populate in the receiving Epic system via FHIR Observation resources, timestamped correctly, attributed to the right patient. The integration team celebrates. They present metrics to the board: 28,000 lab results successfully exchanged in the first month. What the metrics don't show: physicians are not looking at them. The results appear in a tab that requires two extra clicks to reach. Most clinicians don't know the tab exists. The referring physician's results are there, but the emergency physician's workflow hasn't changed to incorporate checking them. Admission orders are still placed without reference to the transferred labs.
Data delivery is a technical problem. Clinical adoption is a workflow design problem. The second is harder, more expensive to fix, and more commonly ignored. A successful interoperability project embeds a clinical champion in the integration design process from week one. Not an informaticist translating physician preferences — an actual practicing clinician who uses the target workflow daily and can tell you whether the data will appear in the right place at the right moment to be actionable without adding friction.
05. No Governance. No Interoperability.
FHIR tells you how to format data. It says nothing about who owns it, who is responsible for its accuracy, who has the right to share it, and what happens when it's wrong.
The most technically sophisticated FHIR integration can be killed by a data governance dispute that was never resolved. Who is responsible for the accuracy of a medication list that has been exchanged from Hospital A to Hospital B to a community pharmacy? When Hospital B adds a medication that Hospital A's system doesn't receive, who owns the discrepancy? When a patient's allergy status differs between two connected systems, which one is authoritative? When HIPAA's Minimum Necessary standard requires limiting data access but the clinical use case requires comprehensive medication history — how is that tension resolved?
These are not edge cases. They are the routine operational questions of any production health information exchange, and they require answers from organizational leadership — not from engineers. A health system that commissions an interoperability project without first establishing a data governance council with decision-making authority over these questions will discover that every one of them becomes a project blocker at exactly the moment they are least expected.
-
Data stewardship ownership must be assigned before integration design begins. Every data element in scope needs an identified organizational owner who is accountable for its accuracy, update frequency, and permitted uses. "The EHR system" is not an owner. A named clinical department or data steward role is an owner.
-
Patient consent architecture must be decided at the policy level, not the engineering level. Which clinical data can be shared automatically under treatment authorization? Which requires patient opt-in? Which is governed by special protections (42 CFR Part 2 for SUD records, state mental health laws)? These are policy decisions that have engineering consequences — not the other way around.
-
Data quality accountability must be contractualized with trading partners. If Hospital B's admitting physician makes a clinical decision based on Hospital A's medication list, and that list is wrong, who bears liability? This is a legal question that must be answered in the data sharing agreement before a single patient record is exchanged.
06. Moving Data Is Not the Same as Moving Meaning
You can move FHIR resources between systems without moving clinical meaning. This is the most technically sophisticated form of wasted effort in healthcare IT.
Consider what happens when a potassium result from a reference lab arrives at a health system's FHIR server coded with the lab's internal item code rather than the required LOINC code. The FHIR resource is structurally valid. The HTTP exchange succeeds. The data is in the system. And it is completely unusable — because the receiving system's clinical decision support cannot match an unmapped local lab code against the LOINC-coded reference ranges in its knowledge base. The potassium value might as well not have arrived.
This is the terminology gap, and it is the most consistently underestimated technical challenge in clinical data exchange. Healthcare operates across five major code systems — SNOMED CT, LOINC, ICD-10-CM, RxNorm, and CPT — each with quarterly or annual updates, each with their own versioning, each with different licensing requirements. A FHIR integration that doesn't include a terminology service capable of real-time translation is shipping syntax, not semantics.
Read More: The Engineering Guide to FHIR Data Mapping Challenges & Solutions
07. You Never Solved Patient Identity
Connecting patient records that belong to different people is worse than not connecting them at all. Patient matching is not a feature — it is a patient safety requirement.
The same real-world patient exists in every connected system with a different identifier. MRN-A001 in Epic. PAT-99283 in the lab LIMS. MB-4421 in the payer system. 7823-XJ in the affiliated hospital's Cerner instance. These four records may represent the same person, or they may represent four different people who happen to share similar demographic characteristics. Patient matching is the process that determines which — and it is the most clinically consequential unsolved problem in health information exchange.
The consequences of wrong patient matching are catastrophic and not hypothetical: a patient's allergy record matched to the wrong person, their prior medication list containing another patient's controlled substances, their diagnostic history contaminated with unrelated clinical data. These are not system errors — they are patient safety events. And they happen with sufficient frequency in production health information exchanges that they have been documented in peer-reviewed literature and OIG reports.
A Master Patient Index (MPI) with deterministic and probabilistic matching, configured for your specific patient population demographics and identifier inventory, is not optional in a production interoperability deployment. It is the foundation without which everything built on top is clinically unsafe.
08. You Added Security as an Afterthought
Every FHIR endpoint you open is a PHI exposure surface. The question is not whether you will have a security incident — it is whether your architecture will contain it when you do.
The OAuth 2.0 token that authenticates a FHIR API call carries a patient context. The HTTP response body is a FHIR resource containing PHI. The log entry that records the API call is PHI. The error message that says "patient not found" is potentially PHI. In a healthcare interoperability context, data and security are inseparable — not because of regulatory preference, but because the data itself is protected health information under federal law, and every component of the system that touches it inherits that obligation.
HIPAA's Minimum Necessary rule, SMART on FHIR's scope authorization model, and the PHI controls required by 45 CFR Part 164 are not compliance checkboxes — they are the contractual terms under which your organization is permitted to operate a health information exchange. Violating them through poor security architecture is not a technical debt to be paid later. It is a reportable breach that triggers OCR investigation, potential civil monetary penalties, and mandatory patient notification.
Read More: HIPAA by Design: Engineering Blueprint for Compliant Healthcare Systems
09. You Measured the Wrong Things
Success metrics for interoperability projects are almost always proxy metrics for things nobody actually measured. "42,000 FHIR resources exchanged" means nothing if it didn't change one clinical decision.
Healthcare interoperability projects are measured in data volume — records exchanged, API calls served, systems connected. These are engineering metrics, not clinical metrics. The question that actually matters is: did a clinician see information they wouldn't otherwise have seen, at the moment they needed it, and did it change what they did? That question is rarely asked and almost never answered with data.
| What Teams Measure | What They Should Measure Instead | Why the Difference Matters |
|---|---|---|
| FHIR resources exchanged (volume) | Percentage of physicians accessing exchanged data within 24 hours of receipt. | Data delivered ≠ data consumed. |
| API uptime / availability % | Rate of clinical decisions that reference cross-institutional data. | Uptime doesn't measure clinical utility. |
| Number of systems connected | Duplicate diagnostic test rate in target patient population. | Connected systems ≠ meaningful exchange. |
| HL7 message throughput | Medication error rate at care transitions in enrolled patient cohort. | Messages sent ≠ errors prevented. |
| Project delivered on time / on budget | Change in 30-day readmission rate for patients with exchanged discharge summaries. | Project success ≠ clinical success. |
10. You Waited for Perfect and Got Nothing
Healthcare interoperability does not require every system to be connected. It requires the right system to be connected to the right clinician at the right moment in care. Start there.
The comprehensive healthcare interoperability vision — every system connected, every patient record accessible to every authorized clinician across every care setting, in real time, with perfect accuracy — is worth pursuing over a decade. It is not worth waiting for before doing anything. The organizations that have made the most progress on interoperability are not the ones that built the most comprehensive platform first. They are the ones that deployed something narrow, measured it, proved value, and expanded incrementally.
CommonWell and Carequality didn't launch with every health system. Direct messaging didn't launch with perfect deliverability. The ONC's USCDI didn't start with every clinically relevant data class. Every successful interoperability initiative has followed the same pattern: start narrow, prove value, expand deliberately. The organizations that waited for perfect conditions — every governance question resolved, every vendor integrated, every use case documented — are still waiting.
💡 The Sequencing Principle
Sequence your interoperability investments by impact-to-effort ratio, not by comprehensiveness. The first integration that reaches production — even if it covers only three FHIR resource types, between two systems, for one clinical workflow — is worth more than the perfect ten-system exchange that is still in design review. Delivered value compounds. Undelivered value is sunk cost.
"The organizations that win at interoperability don't have the most connections. They have the most clarity about which connections change patient outcomes — and the discipline to build those first."
— Peerbits Healthcare Interoperability Practice
What the Successful 40% Do Differently
1 They define a measurable clinical outcome before writing a line of code.
Not "improve interoperability" — "reduce medication errors at care transitions by 30% in 6 months." Specific, measurable, attributable to a defined patient population and clinical workflow.
2 They establish governance before engineers touch an API.
Data stewardship, patient matching policy, consent architecture, data quality accountability — all decided at the organizational level before the first integration design meeting.
3 They build a terminology service before building anything else.
LOINC, SNOMED, RxNorm, ICD-10 — a shared terminology service that every integration calls is the infrastructure without which every other exchange is syntactically correct and semantically meaningless.
4 They embed a practicing clinician in the integration design team — not as reviewer, as co-designer.
The physician who will use the exchanged data in a clinical workflow must co-design the moment, format, and context in which it appears. Informatics translation loses too much signal.
5 They ship narrow, measure clinical behavior change, then expand.
Minimum Viable Exchange first. Prove adoption. Measure whether clinicians use the data and whether it changes decisions. Every subsequent expansion is funded by demonstrated ROI, not by a business case document.
6 They treat HIPAA security as architecture, not compliance.
PHI-free logging, SMART on FHIR scope minimization, immutable audit trails, WORM storage — designed in from day one, not retrofitted after a breach notification letter.
Start With One Thing That Matters
Healthcare interoperability is not a technology problem that has been solved waiting for adoption. It is a human problem — misaligned incentives, diffuse governance, clinical workflows that weren't redesigned, metrics that measured the wrong thing — that technology can only solve when the human problems are resolved first. The organizations that get this right do not have better engineers. They have better clarity about what they are trying to achieve and the discipline to resist the gravity toward complexity before they have earned it.
Peerbits has worked on interoperability projects that succeeded and on ones that failed — and the difference has never been the quality of the FHIR implementation. It has always been whether the clinical use case was clear, whether governance was in place, whether clinicians were co-designers rather than recipients, and whether success was measured by clinical outcome rather than data volume. If you are starting an interoperability project or diagnosing why one is stalling, that is where we start — with the question you should have answered first.
Book Free Interoperability Strategy Review
