FHIR integrations, every resource scoped to a consent, every read in the audit log.
FHIR is a standard everyone implements differently. Epic isn't Cerner isn't athenahealth isn't Veradigm. We build the integration layer that hides those differences from the rest of the product, treats consent as a first-class entity, and keeps every read and write inside an audit trail a clinical reviewer can defend.
What we build
SMART on FHIR launches, standalone and embedded
OAuth 2.0 + OpenID Connect against the EHR's authorization server. Standalone launches for patient-facing apps; embedded launches for clinician workflows inside the EHR. Both paths use the same access token resolution code; the UI differs.
Resource mapping to a typed internal model
FHIR Patient, Observation, Encounter, Condition, MedicationRequest, each maps to a typed internal model the rest of the product reads from. Vendor-specific quirks (different code systems, missing fields, custom extensions) get normalized at the boundary, not leaked into business logic.
Consent + audit on every read
Every FHIR fetch carries a consent ID and writes an audit row before returning the data. The audit log is itself FHIR-flavoured (AuditEvent resource) so existing compliance tooling can ingest it. Pulling a patient record without a consent trail is structurally impossible.
Bulk Data Access for population-level reads
Group-level exports via FHIR Bulk Data ($export). The async job pattern handles long-running EHR responses, polls the status endpoint, ingests the NDJSON, and pushes the resources through the same normalization layer as live reads.
Webhook + subscription handling
FHIR Subscriptions where the EHR supports them (R4B+). Where they don't, we poll on a sensible cadence with delta detection. Updates land in the same event bus internal services use, so a new Observation can trigger downstream workflow regardless of source.
EHR partner onboarding as a routine
New partner (new Epic install, new Cerner site) follows a checklist: register the app, capture client IDs, validate scopes, run the integration test suite against their sandbox, promote to production. Every onboarding feeds back into the suite.
Where this fits
You're building patient-facing software and need real EHR integration, not a screen-scraped CSV import.
You've integrated with one EHR and the second one is teaching you that 'FHIR-compliant' means different things at different vendors.
You're past the proof-of-concept and the clinical reviewer wants to see audit trails before the app goes near a real patient.
Tech stack
- TypeScript
- FHIR R4
- SMART on FHIR
- Postgres
- Drizzle
Want this for your team?
30 minutes with a founder or senior engineer. We'll scope what you need and tell you straight whether Stacklane fits.
Book a Free CallRelated capabilities