Woyce
The messaging, coding, and compliance standards underneath every integration — the vocabulary two systems have to agree on before they can talk to each other.
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.
No 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.
No 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.
No 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.
No 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.
No 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.
No 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.
Six shapes of integration cover almost everything a healthcare product needs. Picking the wrong one for the job is the fastest way to overbuild.
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.
Client-credentials authentication for server-side access to FHIR resources. Right for background sync, analytics pipelines, and anything that needs to run overnight.
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.
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.
DICOMweb and traditional DIMSE for study retrieval and storage, plus the metadata handling that keeps studies matched to the right patient.
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.
Register 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.
Map 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.
The 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.
Where 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.
Site-by-site enablement with monitoring on message volumes and error rates. Each site has its own configuration, and assuming otherwise is how rollouts slip.
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.
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.
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.
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.
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.
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.