How to solve scaling pains with FHIR and data streaming?
summary
A central FHIR server becomes a bottleneck so the engineering team shifts to event-driven design: services publish compact dFHIR templates (dehydrated FHIR) to Kafka, a hydrator converts them to FHIR, and a materialized, search‑optimized FHIR cache serves reads via a GraphQL gateway. Protobuf schemas and a schema registry prevent breaking changes, the outbox pattern ensures transactional writes to streams, streams are replayable for recovery, and the plain FHIR server remains only for external interoperability. The change reduces coupling, speeds development, and enables real‑time alerts and AI on millions of device events.
AI-written summary · about
chapters (8)
- 0:00Start
- 4:29Simple Solution
- 5:04Problems Solved?
- 7:23Complaints
- 15:47How does it work? Domain Ownership
- 16:25How do we ensure domain ownership? Where do we draw lines between domains?
- 18:51Application Friendly API GraphQL
- 21:54Summary
related talks
44mTransforming FHIR Data for horizontally scalable analytics
19mFrom Zero to Production FHIR Server in 6 Months at a Large Northeast Healthsystem
42mBuilding a Streaming (E-health) Data Pipeline: When and How?
35mMix, Match, Merge
35mScalable Data Science with FHIR
27mStorage and analytics
30mInfrastructure scale issues
52mBeyond Microservices: Streams, State and Scalability