High performance system-to-system synchronization
summary
IBM FHIR Server adds a sort parameter so whole‑system history can be returned in sort param (ascending|descending) order and supports Prefer: return=minimal to return only entry metadata (full URL plus version), letting a sync component enqueue parallel V‑reads into a thread pool and apply updates after checkpointing; implementation lives in the fireflow CLI and an experimental IBM FHIR Server feature, uses partition by resourceType+id for per‑resource ordering, offers a Kafka option, and demonstrates large throughput gains in the demo.
AI-written summary · about
chapters (19)
- 0:00Introduction
- 1:16Agenda
- 2:05History Interaction
- 5:01Return Content
- 7:15Consistency
- 9:05Implementation
- 11:27Parallel processing
- 13:05Prefer header
- 14:07History scanner
- 15:55Fireflow
- 17:14Concurrency
- 17:53Checkpoint tracking
- 21:04Partition strategy
- 23:21Scaling out
- 26:31Resources
- 27:30Summary
- 28:06Contact Robin
- 28:49QA
- 36:56Synthesis data
related talks
38mScaling FHIR with microservices
20mAdventures in FHIR Resource Syncing and Caching
26mExploring FHIR Performance Benchmarking
21mLessons learned with FHIR Paging and Plain/Façade FHIR/Load Balanced-Systems
34mFHIR Projects
21mEvents with FHIR: a Simplified Way to Unify Health Data
42mFHIR REST API
46mThe FHIR Bulk Data API and what's new in v2!