Telehealth API integrations look simple until production. Patient records sync inconsistently, webhook deliveries silently fail, clinical events get duplicated, and the on-call engineer at midnight learns that the dispensing partner's idempotency model is not quite what the documentation suggested. This piece is the engineering-side view of what actually matters when integrating UK telehealth infrastructure — written for the engineer at a clinic group, a brand, or a platform vendor.
What integrations actually matter — CRM, EMR, payments, dispensing partner
Four integration surfaces dominate UK telehealth tech architecture. CRM (Customer.io, HubSpot, Klaviyo) for lifecycle. EMR or clinical record (EMIS, SystmOne, or proprietary) for clinical continuity. Payments (Stripe, PayPal) for transactions and subscriptions. Dispensing partner — the platform that picks-packs-ships and exposes dispatch events. Each has its own failure modes, its own SLA, and its own idiomatic event schema. Each needs explicit modelling — not best-effort polling.
Webhooks vs polling — when each is the right answer
Webhooks are right for event-driven workflows: dispense status, prescription approval, payment captured. Polling is right for state reconciliation and back-fill after webhook gaps. Production-grade integrations use both. Webhooks for the happy path; polling for the recovery path. Brands that rely on webhooks alone get bitten by silent delivery failures. Brands that rely on polling alone burn rate limits and miss the real-time UX their patients now expect. The pragmatic pattern is webhook-first with a scheduled reconciliation job that catches drift.
Idempotency for clinical event streams
Clinical events are not retryable in the standard ecommerce sense. A duplicate dispense request cannot be silently ignored — it must be properly idempotency-keyed. A duplicate prescription submission must not produce two prescriptions. Idempotency keys, deduplication windows, and replay-safe handlers are not engineering polish — they are clinical safety. PExpo's REST API and signed webhooks expose explicit idempotency primitives; see our integrations page for the supported patterns.
Patient data sync patterns — the bidirectional problem
Bidirectional sync between clinic EMR and platform record creates the classic distributed-systems problems. Last-writer-wins is dangerous for clinical data — the wrong record can be authoritative for hours before anyone notices. Conflict resolution requires explicit clinical rules, not technical defaults. The pragmatic pattern: designate one system as the source of truth per data domain (clinical record → EMR, payments → Stripe, dispensing → platform). Treat all other systems as derived views that sync from source on schedule, with explicit conflict reporting when source and derivative disagree.
Handling failures gracefully — retries, alerts, fallbacks
Three failure modes dominate. Transient failures (network, rate limits, upstream timeout) — handle with exponential backoff and jitter. Persistent failures (authentication, configuration, schema mismatch) — handle with alerts and human escalation, not endless retry. Silent failures (data drift, missing events, untracked schema changes) — handle with reconciliation jobs that detect inconsistency before patients do. The integrations that survive production are the ones with explicit handling for all three classes.
Observability — what to log, what to alert on
Three categories of telemetry matter. Business-level events (dispenses created, payments captured, prescriptions approved) for product analytics. System-level events (webhook deliveries, retry counts, response times, error rates) for reliability. Compliance-level events (DSAR requests, audit-trail reads, role-based access denials) for regulatory readiness. Treat all three as first-class concerns. UK GDPR audit requirements alone justify the compliance-level investment — the others justify themselves on uptime.
Idempotency for clinical event streams is not engineering polish — it is clinical safety. A duplicate dispense request must not produce two dispenses. Design for it explicitly.
Webhooks for the happy path. Polling for the recovery path. The integrations that survive production use both.
Telehealth API integration is a discipline distinct from generic ecommerce or SaaS integration work. The data is regulated, the events are clinically significant, and the failure modes have patient-safety implications. The engineering teams that internalise this build integration layers that scale; the teams that treat telehealth as 'just another integration' learn the hard way. Our integrations page lists the supported platforms and event schemas if you want to evaluate what is available before designing your own, and our clinic model page shows what the operator surface looks like once the integration layer is in place.
