FHIR import duration is not one number produced by one lever. It is a function of four dominant drivers, each measurable and each moving independently. Getting all four wrong produces estimates that miss by an order of magnitude. Getting two of them right cuts the miss to a factor of two. The site's Bulk import time estimator uses all four as inputs. For the wider FHIR framing, more FHIR notes for clinic operators has more.
Driver One: Resource Volume
- How many patients?
- Per patient, how many observations?
- Per patient, how many conditions, medications, procedures?
Multiply through and you get a raw resource count. That count is the base of every duration estimate. For a small outpatient clinic, 100 patients × 400 observations × 5 conditions × 3 medications = 400,000+ resources.
For the base pattern, predicting how long a FHIR data import will take is the entry.
Driver Two: Reference Density
Resources with more references cost more per write. The write path has to verify each reference (in strict-integrity servers) or record it in an index (in lax servers).
- Patient — 0-2 references (organization, primary care)
- Observation — 3-5 references (subject, encounter, performer, based-on)
- MedicationRequest — 4-6 references (subject, encounter, requester, reason)
- Encounter — 3-5 references (subject, participant, service provider)
Multiply the reference count by the per-reference cost. That is a real slice of the total write time.
For the parallelization implications, parallelizing an import without corrupting references is the entry.
Driver Three: Terminology Validation
Every coded value in an incoming resource can be validated against the bound value set. If validation is on, each write incurs a terminology lookup.
- Off — writes are fast, validation happens later
- On, with cached value sets — 30-60% slower than off
- On, with full value set expansion per write — 2-4× slower
The estimator asks which mode you are running. Turning off for the initial import and running a validation pass afterward is often the fastest path for large-volume imports.
Driver Four: Target Server Throughput
Every server has a sustained write rate. Some sustain 100 writes/second. Some sustain 5000. The ceiling depends on:
- Hardware
- Storage backend
- Index configuration
- Concurrency limits
- Other workloads sharing the server
Measure the sustained rate on your specific target before estimating. Do not use the vendor's benchmark; benchmarks describe optimal, not sustainable.
For monitoring the actual rate during the run, monitoring an in-flight import for the numbers that matter is the entry.
The Interaction Effect
The four drivers do not add linearly. They multiply:
Time ≈ (resources × ref_multiplier × terminology_multiplier) / throughput
A 5-million-resource import at 1000 writes/second with 1.5× reference multiplier and 1.4× terminology multiplier is not 5000 seconds. It is 5000 × 1.5 × 1.4 = 10,500 seconds — about 3 hours.
That is the difference between an estimate that lands and one that doesn't.
What The Estimator Does With The Drivers
- Resource count from your inputs
- Reference multiplier from a per-resource-type table
- Terminology multiplier from your validation mode
- Throughput from your target server's known sustained rate
The output is a range: fastest realistic (low reference density, no terminology validation, peak throughput) and slowest realistic (high density, full validation, degraded throughput).
Second-Order Drivers
- Concurrent writers (parallelism)
- Index rebuild strategies (batch vs incremental)
- Retry rates
- Auth/authz overhead per write
These matter but do not dominate. Model them as ±20% adjustments once the four-driver estimate is in place.
The Short Version
Four drivers. Multiply not add. Measure sustained throughput on your target. Emit ranges. Second-order effects come after. The estimator packages the arithmetic; the accuracy comes from feeding it real numbers.
Sources
- HTML - HTML, HL7 - FHIR Bulk Data Access Implementation Guide 2.0.0
