FHIR aims to create seamless healthcare interoperability, but what does it actually take to connect to 25,000+ healthcare providers? We analyzed Fasten Health's open source codebase to understand what healthcare integrations look like under the hood.
Fasten Health is a healthcare technology company building personal health record aggregation tools that help patients and businesses consolidate personal medical data from multiple providers. Their open-source platform represents one of the largest-scale FHIR implementations with publicly available code, making it a rare window into production healthcare integration challenges.
After speaking with several healthcare industry leaders about integration challenges, the gap between FHIR standards and implementation reality became clear. Here's what we found.
Challenge 1: Provider-Specific Workarounds Are The Rule, Not The Exception
The Idea: FHIR is a standard, so integrations should be consistent.
The Reality: Every major provider requires custom handling.
Unlike connecting to standardized APIs like Stripe or Quickbooks Online, healthcare providers (hospitals, clinics, doctor offices) operate as independent organizations with their own IT policies, security requirements, and regulatory constraints. This means that even when providers use identical EHR systems, they often require custom integration implementations.
Looking at Fasten's architecture, they handle the complexity of multiple healthcare providers through a layered client system that separates generic FHIR functionality from platform-specific and institution-specific customizations. This organizational approach reveals just how much variation exists even within "standardized" FHIR implementations.
Real examples from the code:
// Epic sites require special CORS handling
"cors_relay_required": true,
"custom_definition": trueEpic systems: Different CORS policies requiring provider-specific proxy configurations
Athena Health: Requires dedicated CORS relay with whitelisted endpoints only
OptumCare East: Misconfigured OAuth endpoints breaking standard flows (GitHub Issue #64)
Virginia Mason Franciscan: Uses both Epic and Cerner for different patients, requiring dual authentication flows (GitHub Issue #531)
Key insight: Even with FHIR standards, significant operational overhead is required to handle provider inconsistencies. Budget for relationship management, not just technical implementation.
Challenge 2: Healthcare OAuth2 Goes Far Beyond Standard Implementation
The Promise: SMART-on-FHIR provides standardized authentication.
The Reality: Healthcare OAuth2 requires specialized knowledge that catches many engineering teams off-guard.
When a team estimates "adding OAuth to connect to Epic," they're thinking about standard web OAuth flows. Healthcare authentication is fundamentally different due to regulatory requirements, legacy system constraints, and patient privacy protections.
Healthcare APIs don't behave like typical REST APIs. Instead of simple "read/write" permissions, developers must manage patient-specific scopes like patient/Encounter.read that vary by insurance coverage and provider policies. Major health systems still run Epic installations that predate modern OAuth standards, requiring completely different authentication flows.
In The Code:
Fasten Health had to build their own "Lighthouse Gateway" authentication proxy specifically because standard OAuth libraries couldn't handle healthcare provider inconsistencies reliably. According to their technical documentation, the Lighthouse server is required because healthcare providers have unique confidential client requirements and "in most environments, the Fasten Health application is running on a device that is not directly accessible from the internet".
This isn't optional infrastructure, it's essential for production healthcare integrations. Fasten's proxy handles fragment response modes, PKCE verification, and provider-specific authentication flows that standard OAuth implementations simply can't manage.
What this means for your roadmap: That "OAuth integration" your team scoped for two weeks? Plan for two months of healthcare-specific authentication development, plus ongoing maintenance for provider relationship changes.
Key insight: Healthcare OAuth2 isn't a just a technical implementation, it's a specialized domain requiring dedicated expertise and custom infrastructure.
Challenge 3: The Silent Failure Problem That Standard Monitoring Misses
The Promise: FHIR integrations can be monitored like any other API.
The Reality: Healthcare APIs fail in ways that look like successes to generic monitoring tools, requiring specialized observability.
Healthcare APIs often return a 200 OK status code even when the returned data is incomplete, stale, or incorrect. This creates a "silent failure" problem where standard application performance monitoring (APM) tools, which primarily check for HTTP status codes and response times, miss critical data quality issues.
The types of silent failures common in healthcare integrations include:
Empty Result Sets: An API call correctly returns a
200 OKbut provides an empty response when data should have been returned.Incomplete Resources: The API returns a valid FHIR resource, but it's missing critical fields or contains truncated data.
Stale Data: Caching issues at the provider's end can lead to an API returning outdated information.
Silent Authorization Failures: Authentication might succeed, but the system silently fails to authorize access to specific patient data, resulting in empty or incomplete responses.
This challenge highlights the need for specialized monitoring that goes beyond basic status checks. Instead of relying on generic monitoring tools, developers need to implement sophisticated logic to validate data completeness and integrity. For example, a robust system might track the number of resources returned over time, and alert when a provider's data flow consistently returns fewer resources than expected.
Key Insight: Healthcare integration failures often masquerade as successes. They require healthcare-specific observability, not just generic APM tools, to ensure data integrity and prevent downstream issues.
What This Means for Your Healthcare Integration Strategy
Three takeaways for engineering leaders:
Budget for operational complexity: The Fasten codebase shows that provider relationship management scales with the number of integrations. Plan for ongoing operational overhead, not just initial development.
Healthcare-specific monitoring is non-negotiable: Standard monitoring tools miss the failure patterns that matter most in healthcare. You need integration observability designed for FHIR.
Standards don't eliminate customization: Even with FHIR, you'll build provider-specific handling. Design your architecture to scale this operational complexity.
Building healthcare integrations for your product? The patterns revealed in production codebases like Fasten's can save months of discovery. If you're facing these challenges, we can help. Cohesion Labs specializes in healthcare integration implementations and monitoring, so you know when your data pipes break before your customers do.