FHIR storage design has predictable failure modes that surface under production CMS-0057-F load. The anti-patterns below produce systems that pass Inferno conformance and feel fine in pilot but slow to unacceptable speeds when real payer traffic arrives. Five anti-patterns appear consistently in 2026 deployments that struggle. For more on FHIR storage and hosting models decisions, these are the failure modes worth knowing.
1. Missing Indexes on FHIR Search Parameters
The most common anti-pattern. The FHIR platform stores resources but does not create database indexes on the search parameters that production queries hit. Patient lookup by identifier, Observation by subject, Condition by code, Encounter by date range. The platform passes conformance because the queries return correct results; performance is acceptable in pilot because the data volume is small.
In production, with millions of resources and realistic query volume, missing indexes produce queries that take seconds where they should take milliseconds. Bulk Data exports stall on full table scans. CDS Hooks responses time out.
The fix is to design the index strategy alongside the schema. PostgreSQL-based FHIR engines need indexes on JSONB paths for the search parameters that matter. Native FHIR engines need their equivalent.
2. Storing Source Data Instead of FHIR
A pattern where the platform stores the source data (X12 transactions, HL7 v2 messages, claims records) and translates to FHIR on each API call. The translation is computed every time, even for the same resource accessed multiple times.
This pattern is a compliance-gateway design choice. It is technically conformant but performs poorly under load because translation is repeated work. Production-grade FHIR-native platforms store the FHIR representation as the canonical form, with source data feeding the FHIR store rather than translation happening per-request.
3. No Resource Versioning or History Tracking
The FHIR spec includes versioning and history. Resources have versionId, lastUpdated timestamps, and history endpoints. Platforms that skip the history layer save storage but lose audit defensibility (cannot reconstruct who changed what when) and lose support for FHIR features that depend on history (_history operations, vread).
CMS-0057-F audit requirements include knowing what data was returned to whom and when. Platforms without resource history struggle to answer these questions during audit.
4. Synchronous Bulk Data Export
A pattern where Bulk Data exports run synchronously within an HTTP request rather than asynchronously through the Bulk Data IG's defined flow. The pattern violates the spec for large exports and produces timeouts when realistic volume arrives.
A correct Bulk Data implementation accepts the export request, returns 202 Accepted with a status URL, runs the export asynchronously, and exposes the resulting NDJSON files at the manifest URLs. Platforms that try to inline the export in the request fail when the export is non-trivial.
5. Single-Tenant Per Resource Type
A pattern where the platform stores all tenant data in shared tables without strong isolation. Multi-tenant deployments depend on application-layer enforcement of tenant boundaries. A bug in the application code or a misconfigured query can produce data leakage across tenants.
The pattern is fast and simple but unsafe at scale. Production-grade multi-tenant deployments enforce isolation at the data layer (schema-per-tenant, database-per-tenant, or PostgreSQL row-level security). The application code does not have to maintain isolation correctness.
How These Anti-Patterns Compound
The anti-patterns are not independent. A platform with missing indexes (Anti-Pattern 1) and synchronous Bulk Data (Anti-Pattern 4) produces exports that fail because the underlying queries are too slow. A platform without resource history (Anti-Pattern 3) and single-tenant-style multi-tenant (Anti-Pattern 5) has audit problems compounded by isolation risks.
Production-grade FHIR storage requires getting all of these right, not just the one or two that get attention in vendor demos.
How to Stress-Test Against These Anti-Patterns
A useful evaluation pattern is to load the candidate platform with realistic data volume (5-10 million FHIR resources for a mid-market payer, more for larger plans) and run representative query patterns at production rates. The platforms that pass this test cleanly are production-grade. The platforms that struggle reveal which anti-patterns are present.
For the data store patterns that avoid these failure modes, the Top 6 FHIR data store patterns for reusable compliance investment covers the production-grade approaches. For the PostgreSQL-based engines that handle indexing and history correctly, the Top 5 PostgreSQL-based FHIR engines for 2026 covers the engine layer.