Integrations
Fire Arrow Integrations
Most digital health products talk to other healthcare systems. The integrations Fire Arrow supports cluster around a small set of well-defined surfaces: standard FHIR REST and GraphQL on the Fire Arrow side, OAuth 2.0 / OpenID Connect for authentication, FHIR Bulk Data for dataset exchange, and converter components for non-FHIR formats (CDA, HL7 v2). For EHR connectivity, Fire Arrow pairs with apps that launch in Epic, Oracle Health, and similar systems via SMART; the SMART launch happens at the EHR, and the app uses Fire Arrow as its own OAuth-protected FHIR backend alongside.
Who this is for
Integration architects, EHR connectivity leads, and product teams planning the connection points between Fire Arrow and the rest of the healthcare data ecosystem.
How integrations are structured
Each integration is either inbound (other systems write into Fire Arrow), outbound (Fire Arrow data flows into other systems), or bidirectional. The access model is the same across all three: a service or user identity for the integration, rules that scope what it can do, and audit per call.
Standards-based integrations (FHIR REST, GraphQL, FHIR Bulk Data) work directly with OAuth 2.0 / OIDC tokens. Format-bridging integrations (CDA-to-FHIR, HL7 v2) use a converter component that writes the resulting FHIR resources into Fire Arrow through the standard write path.
EHR connectivity
Epic, Cerner (Oracle Health), Allscripts/Veradigm, MEDITECH, and other major EHRs expose FHIR R4 surfaces with SMART on FHIR for clinician app launch. The typical integration is a SMART app that launches inside the EHR's container, reads and writes the EHR's FHIR endpoint with the EHR's token, and pairs with Fire Arrow as its own FHIR backend through a separate OAuth/OIDC flow against the customer's identity provider. Fire Arrow itself does not implement the SMART app launch profile; the SMART page covers the rationale and the integration shape.
For legacy HL7 v2 messaging, an HL7 v2 listener converts incoming messages to FHIR and writes them to Fire Arrow through the standard write path.
Document and dataset exchange
CDA documents (continuity of care, discharge summaries) convert to FHIR through a converter component. The converted resources land in Fire Arrow with a Provenance record pointing back to the source document.
FHIR Bulk Data export and import handle larger dataset transfers: cohort exports for analytics, full-tenant exports for migration, and import for backfill from a source system.
Related docs
FAQ
Does Fire Arrow ship with EHR integrations out of the box?
Fire Arrow speaks FHIR R4 and accepts OAuth 2.0 / OpenID Connect tokens from any compliant provider. The major EHRs (Epic, Cerner/Oracle Health, Allscripts/Veradigm, MEDITECH) expose FHIR R4 endpoints with SMART on FHIR for app launch on their side. The typical integration is a SMART app that launches in the EHR, talks to the EHR's FHIR endpoint with the EHR's token, and uses Fire Arrow as its own backend through a separate OAuth/OIDC flow. EHR-specific quirks (extension namespaces, vendor-specific search parameters) are handled by the integration layer.
What about non-FHIR systems?
HL7 v2 and CDA integrations use converter components that translate to FHIR and write through the standard FHIR API. Custom legacy systems can write FHIR resources directly through a service identity.
Is there an integration platform component?
Fire Arrow is the destination/source for FHIR data; the orchestration (when to fetch, when to push, how to handle retries) typically lives in an iPaaS or a custom integration service. Both fit alongside Fire Arrow without changing the access model.
