FHIR Projects
summary
Compares four storage patterns and reports what actually worked: a HAPI JPA single-table approach simplifies schema but incurs many joins and search performance pain; a MongoDB per-resource collections Go server (used behind Synthea) reaches ~1M patients for simple searches but struggles with chain searches, aggregation paging and counts; a prototype Candle: Postgres per-resource JSON stores one table per resource, extracts a few indexed fields, uses JSON queries for the rest and hits million‑patient scale while keeping joins for complex queries.
AI-written summary · about
chapters (36)
- 0:00Introduction
- 0:25Gregorowicz Background
- 1:27Context
- 2:59Controller Layer
- 4:52Code Odyssey
- 5:43Traditional Data Models
- 6:58Single Resource Data
- 8:04Happy Fire
- 10:51MongoDB
- 11:40Fire Server
- 12:48Fire Buffers
- 14:02DocumentOriented Database
- 16:00Resource Per Table
- 17:09Candle
- 17:32Database
- 21:18FHIR API
- 21:35What are we working on
- 23:50Data Infrastructure
- 24:26Cloud
- 24:55MLP Adapter
- 25:45BigQuery
- 26:48DataLab
- 27:06Risk Assessment
- 27:33Demo
- 27:59Starting Point
- 28:27Python Script
- 29:09Observations
- 29:22Referential Integrity
- 29:52Fire
- 30:42Transactions
- 31:45Infinite Loop
- 32:01Docker
- 32:32Commands
- 32:44Quota
- 33:02Why did you do it
- 33:40Contact information
related talks
47mStoring data using FHIR - a good idea?
45mFHIR server scale and performance challenges
24mUnleashing the power of FHIR data with knowledge graphs
21mLessons learned with FHIR Paging and Plain/Façade FHIR/Load Balanced-Systems
16mThe story of FHIR data exchange and storage combined
26mExploring FHIR Performance Benchmarking
42mFHIR Projects
42mSQL on FHIR