New Source Connector: FHIR (R4) - Azure Health Data Services & other OAuth2-protected FHIR servers

[NiranjanK03]

Connector

FHIR R4 (Fast Healthcare Interoperability Resources): a source connector for any FHIR R4-compliant API, with first-class support for Azure Health Data Services and other OAuth2-protected endpoints (e.g. Epic via SMART Backend Services).

Why this connector

FHIR is the standard API for healthcare data exchange (EHRs, health information exchanges, payer/provider APIs under US interoperability mandates). There's currently no FHIR source connector in the registry. This lets teams sync clinical data (Patient, Encounter, Observation, Condition, etc.) from any FHIR R4 server into their warehouse.

Why custom Python CDK (not Connector Builder)

Two things fall outside what Connector Builder currently supports:

1. SMART Backend Services auth - RFC 7523 JWT client-assertion flow (self-signed JWT signed with an RS384 private key, exchanged for a bearer token). This is required by Epic and other SMART-on-FHIR-compliant EHRs.
2. Incremental state with same-timestamp dedup - FHIR's meta.lastUpdated cursor is only second-precision, so a page boundary can split records that share a timestamp. The connector tracks (last_updated_fallback, ids_at_last_updated) in stream state to avoid re-emitting or dropping those records across syncs.

What's implemented

• Streams: one per configured resource_types /
  additional_resource_types entry (e.g. Patient, Encounter, Observation,
  Condition, ...), each emitting {"data": [<FHIR resources>]} from one
  Bundle page.
• Sync modes: full refresh and incremental (via meta.lastUpdated).
• Auth (credentials.auth_type oneOf, 5 options):
  • Azure AD client-credentials (Azure Health Data Services)
  • Generic OAuth2 client-credentials
  • Bearer Token
  • No Auth
  • SMART Backend Services (asymmetric JWT client assertion, e.g. Epic)
• Status: code-complete, 91 unit tests passing, CAT-verified against the
  public HAPI FHIR R4 test server (https://hapi.fhir.org/baseR4).

Request

Filing this discussion per the contribution guide for custom Python CDK connectors — looking for confirmation this doesn't overlap with in-flight work and fits the current connector roadmap before I open the PR. Happy to adjust scope/streams/auth methods based on feedback.

[Airbyte Support Bot (airbyte-support-bot)]

Hi NiranjanK03, thank you for this detailed proposal and for the work you've already put into building the FHIR R4 source connector!

This is a well-structured request — the healthcare data space is an important domain, and having a connector for FHIR R4-compliant APIs (with support for Azure Health Data Services and SMART Backend Services auth) would be a valuable addition to the ecosystem.

We've escalated this to our internal team so they can confirm there's no overlap with in-flight work and review the scope before you open a PR.

Internal Tracking: https://github.com/airbytehq/oncall/issues/12875

---

Need more help? Join Airbyte Community Slack for peer support, or if you're a Cloud customer, open a support ticket referencing this URL.

[NiranjanK03]

Hello Airbyte Support (@Airbyte-Support), following up on the request. Could you please provide an update on this?