Reading and writing clinical data sounds like one feature. In practice it's FHIR, HL7, OAuth scopes, vendor sandboxes, and certification — a project of its own. We've shipped integrations real institutions trust, and we can make yours hold up in production.
The standards are mature, the implementations are not. Most teams underestimate the gap between a sandbox demo and a working production integration.
FHIR resources, HL7 v2 messages, and the way each vendor interprets them differ enough that 'standards-compliant' rarely means 'works out of the box.' Mapping your data model to theirs — and back — is detailed, error-prone work that generated code tends to hand-wave.
Epic, Cerner, and other majors gate production access behind sandboxes, app registration, and review. Getting from a working sandbox call to a live connection at a health system is a process with its own timeline, paperwork, and surprises.
SMART on FHIR auth flows, OAuth scopes, token refresh, retries, and reconciling mismatched data shapes determine whether an integration is reliable or quietly drops records. These are exactly the parts a prototype skips and production cannot.
EHR APIs version, vendors deprecate endpoints, and compliance expectations shift. An integration isn't done at launch — it needs monitoring and upkeep, or it degrades silently until something important stops syncing.
FHIR and HL7 are part of our default toolkit, not a first-time experiment on your timeline.
We work in FHIR resources and HL7 messaging day to day, and we know where the spec ends and vendor reality begins. We design the data mapping carefully so clinical data moves correctly in both directions.
From sandbox to production: app registration, SMART on FHIR auth, scope configuration, and navigating the certification and review steps the major EHRs require before they'll connect you to real data.
Proper auth and token handling, retries and idempotency, error handling, and reconciliation so records don't silently drop. We build the integration to be observable, so you know when something upstream changes.
EHR data is PHI — we handle it with the same HIPAA-grade safeguards as the rest of your app, and we can maintain the integration as vendor APIs and standards evolve.
We've built clinical-data software with UCSF and shipped 100+ apps.
A remote clinical-research platform built with UCSF — the kind of data-handling and integration work that academic medical centers hold to a high bar.
We've written extensively on EHR architecture and interoperability and built EHR-adjacent products end to end — this isn't our first integration.
HL7 v2 is the older, widely-deployed messaging standard for exchanging clinical data; FHIR is the modern, web-API-friendly standard built by HL7. Most real-world integrations touch both — legacy systems speak v2, newer APIs speak FHIR.
The major ones expose FHIR and/or HL7 interfaces — Epic, Cerner (Oracle Health), and others — plus app marketplaces like SMART on FHIR. We work with whatever your target health systems actually run.
The engineering is often weeks; the gating factor is vendor sandbox access, app registration, and certification, which run on the EHR vendor's and health system's timeline. We scope both so you're not surprised.
We handle the technical work and guide you through the registration, sandbox, and review steps these vendors require. The formal program steps are partly administrative and partly ours to build to — we cover the build.
Yes — clinical data is PHI, so the integration must meet the same HIPAA safeguards as the rest of your app: encryption, access controls, audit logging, and BAAs with every vendor in the path.
Tell us which systems you need to talk to. We'll scope the integration — engineering and vendor steps — and build it to hold up in production.
Build with us
