Standards we build against
The messaging, coding, and compliance standards underneath every integration — the vocabulary two systems have to agree on before they can talk to each other.
Interoperability
- FHIR R4
- SMART on FHIR
- Bulk FHIR
- HL7v2
- DICOM
- CDA
Terminologies & coding
- ICD-10-CM
- CPT
- HCPCS
- SNOMED CT
- LOINC
- RxNorm
Compliance frameworks
- HIPAA Security Rule
- HIPAA Privacy Rule
- HITECH
- SOC 2 (readiness underway)
- GDPR (where applicable)
EHR systems we scope integrations against
Every one of these runs on standards we build against every day. None of them are a shipped integration for us yet — we'd rather tell you that up front than have it surface on a discovery call.
Epic
Not yet shippedNo completed Epic integration yet. Epic runs its own developer and partner programme with a real app-review gate — we'd scope sandbox access and that timeline honestly before committing to dates.
Oracle Cerner
Not yet shippedNo completed integration with Oracle Cerner yet. Oracle Health operates its own developer programme with its own requirements — we'd confirm access and scope before committing to a timeline, same as any system we haven't worked with.
athenahealth
Not yet shippedNo completed athenahealth integration yet. Same starting point as any system we haven't worked with: confirm API access and scopes directly with the vendor before scoping the build.
eClinicalWorks
Not yet shippedNo completed eClinicalWorks integration yet. We'd approach it the way we approach any new EHR — sandbox first, certification requirements confirmed early, not assumed from documentation.
NextGen
Not yet shippedNo completed NextGen integration yet. We'd approach it the same way as any EHR we haven't worked with — sandbox access and scoping first, and a date only after we've checked what's actually required.
DrChrono
Not yet shippedNo completed DrChrono integration yet. We'd scope it the same way as any EHR we haven't integrated with before: sandbox access, mapping, and a spike against the riskiest read/write path first.
Integration patterns, and when each one is right
Six shapes of integration cover almost everything a healthcare product needs. Picking the wrong one for the job is the fastest way to overbuild.
SMART on FHIR app launch
OAuth2-based launch from within the EHR, inheriting patient and encounter context. The path most digital health products take to get in front of clinicians without asking them to open a second tab. Each vendor runs its own app review, and that review is usually the schedule risk.
Backend services / system-to-system
Client-credentials authentication for server-side access to FHIR resources. Right for background sync, analytics pipelines, and anything that needs to run overnight.
Bulk FHIR export
Asynchronous NDJSON export for cohorts and whole populations. The right tool for analytics and reporting, and the wrong tool for anything that needs to be current to the minute.
HL7v2 interface engine
ADT, ORM, ORU, and SIU message handling over MLLP, with an engine handling acknowledgements, retries, and the per-site segment quirks that make every HL7v2 interface subtly its own. Unfashionable and still how a large share of US clinical data actually moves.
DICOM imaging
DICOMweb and traditional DIMSE for study retrieval and storage, plus the metadata handling that keeps studies matched to the right patient.
Terminology mapping
ICD-10, CPT, SNOMED CT, LOINC, and RxNorm mapping between your model and theirs. The step that looks trivial in planning and consumes the schedule in practice, because two systems rarely mean the same thing by the same code.
What an integration project actually looks like
- 01
Sandbox access & scoping
1-2 weeksRegister with the vendor's developer programme, get sandbox credentials, and confirm which resources and scopes are actually available to you — which is routinely narrower than the documentation suggests.
- 02
Mapping & spike
2-3 weeksMap their resource model to yours and build the riskiest read and write paths end to end against the sandbox. This is where unknowns surface, which is why it comes before the rest of the product.
- 03
Build & error handling
3-6 weeksThe full integration with retry logic, partial-failure handling, and reconciliation. Clinical systems go down, rate-limit, and return partial data; the integration has to stay correct when they do.
- 04
Vendor review & certification
2-8 weeks, vendor-dependentWhere the EHR requires app review before production access. Largely outside your control, which is why it gets started early rather than treated as a final step.
- 05
Production rollout
1-2 weeks per siteSite-by-site enablement with monitoring on message volumes and error rates. Each site has its own configuration, and assuming otherwise is how rollouts slip.
FHIR & EHR integration FAQs
How long does an EHR integration take?+
For a single system with a defined scope, plan on two to four months end to end. The engineering is rarely the long pole — sandbox access and the vendor's app review process usually are, and neither moves faster because you are in a hurry.
Do you integrate with Epic?+
Not yet on a shipped engagement. Epic runs its own developer and partner programme with a real app-review gate, and we would scope sandbox access and that timeline honestly before committing to dates — the same discipline we bring to every EHR, named or not. The FHIR and SMART on FHIR work itself is the same standards work we build against elsewhere; the vendor-specific review would be new ground for a specific project.
What is the difference between FHIR and HL7v2?+
HL7v2 is a pipe-delimited messaging standard from the late 1980s that still carries a large share of US clinical traffic — ADT admissions, lab orders and results, scheduling. FHIR is the modern REST and JSON successor, far easier to build against. In practice you need both, because the systems you integrate with were not all built in the same decade.
Can you build a single connector for every EHR?+
No, and treat anyone who says otherwise with suspicion. FHIR standardises the shape of the data, not which resources a vendor exposes, which scopes they grant, or how they handle writes. A shared abstraction layer with per-vendor adapters is achievable; a universal connector is not.
Do you handle terminology mapping?+
Yes — ICD-10, CPT, SNOMED CT, LOINC, and RxNorm. It is consistently the most underestimated part of an integration, because two systems using the same code standard still often disagree about what a given code means in context.
What happens when the EHR is down?+
The integration queues, retries with backoff, and reconciles when the system returns — and surfaces the degradation rather than failing silently. Designing for the unhappy path is most of what separates an integration that survives production from one that demos well.