openEHR + FHIR Bidirectional Sync for Cancer Care: Building Reliable Health Data Exchange with Temporal

Executive Summary

A cancer care network operating across 5 clinical facilities needed to synchronize patient data between their local openEHR Clinical Data Repositories and a central FHIR R4 server. The challenge: bidirectional sync with zero data loss, complete audit trails, and automatic retry for failed operations — across systems that speak fundamentally different data languages.

We built a Temporal-powered workflow engine that translates between openEHR archetypes and FHIR R4 resources, handles bidirectional sync with conflict resolution, and guarantees delivery through exponential backoff retries and dead-letter queuing. The result: 99.97% sync success rate with sub-2-second latency across all 5 sites.

The Problem: Two Standards, Five Sites, One Patient

openEHR and FHIR R4 are both healthcare data standards — but they solve different problems. openEHR excels at clinical data modeling with rich archetypes and templates. FHIR R4 excels at interoperability and API access with standardized RESTful resources.

This cancer care network used openEHR at each local facility for clinical documentation — capturing detailed oncology data using domain-specific archetypes. But they needed FHIR R4 at the central level for:

• Cross-site analytics: Population health metrics, treatment outcome comparison across facilities
• External integrations: Lab systems, imaging platforms, and referring providers that speak FHIR
• Regulatory reporting: Quality measures and cancer registry submissions that require FHIR format
• Research: Clinical trial eligibility screening and cohort identification

What Made This Hard

• Data model mismatch: openEHR uses deeply nested archetypes with rich clinical semantics. FHIR uses flat resources with extensions. Mapping between them is non-trivial and lossy if done carelessly.
• Bidirectional requirement: Data flows both ways. A new lab result at a local site pushes to central FHIR. A treatment plan created centrally pushes back to local openEHR. Conflict resolution is critical.
• Zero tolerance for data loss: This is oncology. A lost lab result or treatment update could directly impact patient care. Every sync must be guaranteed.
• Network reliability: Five sites across different geographic locations with varying network quality. Sync must handle disconnections, timeouts, and partial failures gracefully.

System Architecture

Architecture Components

Local Clinical Sites (HIP — Health Information Provider): Each of the 5 facilities runs an openEHR Clinical Data Repository (CDR). Clinicians document patient encounters using openEHR templates designed for oncology — tumor staging, treatment protocols, adverse events, follow-up assessments.

Change Detection Layer: Each local CDR emits change events when clinical data is created or updated. These events trigger sync workflows. We implemented polling-based change detection with timestamps (openEHR doesn't have native webhooks) — checking for changes every 30 seconds.

Temporal Workflow Engine: The brain of the sync system. Temporal orchestrates every sync operation as a durable workflow that survives crashes, retries on failure, and maintains complete execution history. Each sync is a workflow with defined steps, timeouts, and failure handling.

Transform Layer: Bidirectional mapping between openEHR archetypes and FHIR R4 resources. This is where the hard work happens — preserving clinical semantics while converting between fundamentally different data models.

Central FHIR R4 Server (HAPI FHIR): Stores the canonical, aggregated view of all patient data across 5 sites. Exposes standard FHIR APIs for external integrations, analytics, and research.

Audit Logger: Every sync operation — success, failure, retry, conflict resolution — is logged with timestamps, source/destination, data hashes, and the user/system that triggered it. Complete chain of custody for every piece of clinical data.

Data Mapping: openEHR Archetypes to FHIR Resources

Mapping Rules

Handling Lossy Conversions

openEHR archetypes often contain richer clinical detail than FHIR resources can represent natively. Our approach:

• FHIR Extensions: For clinically significant data that doesn't fit standard FHIR resources, we defined custom FHIR extensions. These are documented and published for downstream consumers.
• Provenance tracking: Every FHIR resource includes a Provenance resource linking back to the original openEHR composition. If downstream systems need the full clinical detail, they can request the source archetype.
• Round-trip fidelity testing: Automated tests that sync data openEHR → FHIR → openEHR and verify no clinical information is lost. Any mapping that fails round-trip testing is flagged for manual review.

Temporal Workflows: Guaranteed Delivery

Why Temporal

We chose Temporal over alternatives (message queues, cron jobs, custom retry logic) because:

• Durable execution: Workflows survive process crashes, server restarts, and network failures. If a sync is interrupted, it resumes exactly where it left off.
• Built-in retry: Exponential backoff with configurable max retries. No custom retry logic needed.
• Execution history: Complete, queryable history of every workflow execution — when it started, what steps ran, what failed, how it was resolved. Critical for healthcare audit requirements.
• Visibility: Temporal's UI shows real-time workflow status across all 5 sites. Operations team can see sync health at a glance.

Sync Workflow Steps

1. Detect change — polling layer identifies new/updated data at a local site
2. Validate archetype — ensure the openEHR data conforms to expected template structure
3. Transform — convert openEHR archetype to FHIR R4 resource(s) using mapping rules
4. Validate FHIR — run FHIR profile validation on the output resource
5. Check conflicts — compare with existing data on destination. If conflict detected, apply resolution strategy
6. Write to destination — create or update the FHIR resource on the central server
7. Log audit trail — record the complete sync event with timestamps, hashes, and provenance
8. Acknowledge — mark the source change as synced to prevent re-processing

Failure Handling

• Transient failures (network timeout, server 503): automatic retry with exponential backoff (1s → 2s → 4s → 8s → 16s → 32s), max 6 retries
• Validation failures (malformed data): routed to dead-letter queue for manual review. Clinical staff notified via email.
• Conflict failures (same record updated at two sites): flagged for clinical review with both versions preserved. No auto-resolution for clinical data.

Results

Technology Stack

Timeline

Lessons Learned

• Temporal changed everything. Before Temporal, we had custom retry logic, cron-based sync jobs, and manual dead-letter processing. Temporal replaced all of it with a single, observable, durable workflow engine.
• Mapping is the hardest part. The sync engine itself was straightforward. The archetype-to-FHIR mapping consumed 60% of the engineering effort. Rich clinical archetypes don't flatten cleanly into FHIR resources.
• Audit logging is not optional. In healthcare, you must prove that every piece of data arrived, when it arrived, and that it wasn't modified in transit. The audit log was as important as the sync engine itself.
• Clinical conflicts need humans. We tried automated conflict resolution. Oncologists rejected it. When two sites update the same patient record, a clinician must review both versions and decide. The system's job is to surface the conflict immediately, not resolve it.