Why Bi‑Directional Sync Matters Now

Payers and providers increasingly expect standardized, auditable diabetes outcomes—particularly Time‑in‑Range (TIR), Time‑Below‑Range (TBR), and Time‑Above‑Range (TAR)—to support risk sharing, quality reporting, and reimbursement. Clinicians, meanwhile, want to stay inside their EHR workflow.

Bi‑directional sync lets you:

• Read patient data to enrich your coaching and analytics; and
• Write back outcomes (e.g., TIR windows, hypoglycemia events, notes) so clinicians can act without switching tools.

The result: faster payer/provider deals, better clinician adoption, and measurable patient impact.

What Makes Diabetes Data Different

Diabetes streams aren’t just another vital sign. They combine dense time series (CGM), device‑specific quirks, and site‑specific EHR constraints. The most common traps:

• Unit mismatches (mg/dL vs mmol/L) and hidden conversions.
• Clock drift & time zones (device, user locale, EHR time).
• Warm‑up periods & gaps that can quietly inflate TIR.
• Event taxonomies that differ by vendor (warm‑up, calibration, sensor errors).
• Site variability in what an EHR lets you write.

Keep these in mind as you design ingestion → normalization → outcomes → EHR emission.

Integration Options at a Glance

Epic and Oracle Health (Cerner) both offer SMART‑on‑FHIR APIs for patient‑context apps and system‑to‑system exchange. Availability and behavior vary by site and context.

• Patient‑context (user‑launched) SMART on FHIR: Ideal for point‑of‑care workflows, reading clinical data, and—where permitted—writing Observations to flowsheets or notes.
• System‑to‑system (SMART Backend Services + Bulk FHIR): For nightly cohort jobs, payer dashboards, and historical backfills.
• Fallbacks: Where FHIR write coverage is partial, HL7 v2 ORU^R01 and CCD import may still be the shortest path to production. Plan for reconciliation to avoid duplicates.

Tip: Maintain a capability matrix per site (read‑only, partial write‑back, bulk export availability, throttling/quotas). Toggle behavior at runtime.

From CGM to EHR and Back

Below is a narrative you can hand to design/QA to create a diagram.

1. Ingestion — Pull CGM (Dexcom, Abbott, Medtronic), wearables (Apple Health, Fitbit), and app entries. Buffer, de‑duplicate, schema‑sniff, and order events.
2. Normalization — Convert units (mg/dL ↔ mmol/L) with explicit provenance. Align timestamps, detect/correct drift, and map vendor events to a unified taxonomy.
3. Outcomes — Compute TIR/TBR/TAR, hypoglycemia events, coefficient of variation; enforce warm‑up & long‑gap exclusions.
4. Emission — Create FHIR Observation resources for both raw series (where needed) and aggregated TIR windows with effectivePeriod, method, and Provenance references. Degrade gracefully to HL7 v2 where writes are blocked.
5. EHR UX — Render in flowsheets/cards; enable clinician annotations. If the site is read‑only, capture intent and queue for deferred write‑back.
6. Analytics — Store denormalized facts for cohorts, payer dashboards, and ROI reporting.

Common Go‑Live Pitfalls — And How to Prevent Them

1) Warm‑up inflates TIR
Excluding sensor warm‑up hours is non‑negotiable. Parameterize by sensor generation and vendor docs.

2) Unit mismatch (mg/dL vs mmol/L)
Use a canonical Quantity type with unit metadata and round‑trip tests. Alert if units switch mid‑stream.

3) Time zones & clock drift
Persist device timezone and offsets; normalize at ingest; regression‑test DST crossings.

4) Gaps & backfill
Define short‑gap interpolation and long‑gap exclusion. Mark recomputes with Provenance when late data arrives.

5) Patient‑context API quirks
Expect filtering and variations by deployment. Test in real clinician context, not only in sandboxes.

6) Write capability differs by site
Treat read‑only as a first‑class mode. Persist clinician intent; attempt asynchronous write‑back when the site permits.

7) Bulk vs single‑patient throttling
Use Bulk FHIR $export for cohorts. Implement retry/back‑off, pagination, and manifest integrity checks.

8) HL7 v2 reconciliation
If legacy feeds coexist with FHIR writes, deduplicate by patient+time+code+value hash and track source‑of‑truth.

9) Observation semantics
Post TIR as a proper Observation (not free text): include code, method, effective period, components for TIR/TBR/TAR, and link to Provenance.

10) Auditability gaps
Make lineage explorable: raw CGM → normalization → exclusions → TIR calc → posted Observation. Without this, payers will push back.

Validation Plan You Can Reuse

A) Environment & auth

• SMART (user‑launched): validate scopes, patient switch, and context propagation in Epic/Oracle clinician workflows.
• SMART Backend Services: JWT signing, scope grants, token lifetime, and key rotation.

B) Resource read tests

• Time‑series glucose: verify LOINC codes, units, timestamp provenance, and sorting.
• Aggregated metrics: verify Observation shape: effectivePeriod, valueQuantity (or components), method, device, and Provenance link.

C) Resource write tests (site‑gated)

• Epic: exercise Observation create/update; assert flowsheet mapping; validate failure paths at read‑only sites.
• Oracle Health: confirm client registration, allowed resources, and venue‑specific constraints.
• Fallback: when blocked, confirm read‑only mode and deferred write‑back queueing.

D) Math & integrity tests (TIR engine)

• Warm‑up exclusion per device generation.
• Gap policy: short vs long; denominator correctness.
• Unit conversion: randomized mid‑day unit changes; thresholds at 70/180 mg/dL.
• Time: DST crossover; drift offsets; EHR timezone alignment.

E) Cohort & bulk tests

• $export on a 1k‑patient group; verify pagination, retries, and reassembly latency.
  

F) Legacy compatibility

• HL7 v2 ORU^R01 ↔ FHIR mapping tests; duplicate suppression; semantic parity checks.

Implementation Blueprint

7.1 Core services

• Ingestion gateway with circuit breakers and dead‑letter queues.
• Normalization service with unit/time canonicalization and event taxonomy mapping.
• Outcomes engine computing TIR/TBR/TAR, hypoglycemia events, CV.
• EHR broker supporting FHIR R4/R5, SMART auth, Bulk $export, and HL7 v2 fallbacks.
• Analytics warehouse for payer dashboards and cohort KPIs.

7.2 Patterns that save weeks

• Capability matrix per site (read/write flags, quotas, bulk availability) toggled at runtime.
• Idempotency & dedup across ingest → emit to survive retries.
• Two‑lane data flow: near‑real‑time for clinician UX, batch for payer reporting.
• Observability: API quotas, end‑to‑end latency, error budgets, back‑pressure.

7.3 Minimal resource shapes (example)

FHIR Observation — Aggregated TIR (illustrative):

{

  “resourceType”: “Observation”,

  “status”: “final”,

  “code”: { “coding”: [{ “system”: “http://loinc.org”, “code”: “TIR_CODE”, “display”: “Time in Range” }]},

  “subject”: { “reference”: “Patient/123” },

  “effectivePeriod”: { “start”: “2025-09-01T00:00:00Z”, “end”: “2025-09-07T23:59:59Z” },

  “valueQuantity”: { “value”: 72.3, “unit”: “%” },

  “method”: { “text”: “TIR v1.4; excludes warm‑up; long‑gap>60min” },

  “device”: { “reference”: “Device/cgm-abc” }

}

Prefer component structure if you want to include TBR and TAR in the same Observation.

Compliance and Audit, Built In

• Privacy & consent: PHI minimization, consent ledger, per‑tenant isolation.
• Security: TLS everywhere, at‑rest encryption, fine‑grained access control; pen‑tests on EHR apps.
• Provenance: transformation lineage attached to Observations; reproducible cohort queries for payers.
• Policy alignment: prepare for payer FHIR APIs and evolving U.S./EU guidance; keep unit tests that mirror consensus clinical definitions.

Go‑Live Demo Checklist

• Post a TIR Observation with effectivePeriod, method, and Provenance; verify EHR rendering.
  Run Bulk $export for a predefined cohort and rebuild TIR distribution charts.
• Negative tests: unit switch mid‑day; DST crossover; late backfill → show recompute with lineage.

KPIs That Move Contracts

• Clinical: % patients with TIR >70%; severe hypo rate; median CV.
• Engagement: weekly active patients; adherence to sensor wear; coach touchpoints per patient.
• Operational: time‑to‑go‑live per site; write‑back success rate; mean time to recover from EHR outages.
• Commercial: payer cohort coverage; SLA adherence; audit‑pass rate.

FAQs

Do we need both FHIR and HL7 v2?
Often yes—FHIR for modern sites, HL7 v2 for legacy or partial‑coverage deployments.

Can we compute TIR inside the EHR?
Usually no; compute in your platform, then post as Observation with clear method and Provenance.

What if a site blocks writes?
Ship read‑only mode, capture clinician intent, and queue for deferred write‑back.

Glossary

• TIR/TBR/TAR — Time in (Below/Above) Range, typically 70–180 mg/dL for adults unless otherwise specified.
• SMART on FHIR — Authorization & launch framework for EHR apps in user or system context.
• Bulk FHIR — $export for cohort‑level, server‑to‑server data exchange.
• ORU^R01 — HL7 v2 message type for unsolicited observation results.

Why Jelvix

We shorten go‑lives by packaging reusable FHIR/HL7 connectors, a standards‑compliant aggregation & outcomes layer, and a site capability matrix so your app behaves correctly in read‑only, partial‑write, and full‑write environments. The result: faster clinical adoption, payer‑ready reporting, and fewer surprises at audit time.

Need help shipping bi‑directional sync? Let’s review your current pipeline (ingest → normalize → compute → emit) and map the fastest path to a safe go‑live.