Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

Esquema de base de datos FHIR

Cómo almacenar recursos FHIR: tablas normalizadas vs. JSON con índices de búsqueda vs. grafo, el esquema PostgreSQL que ejecuta Anpheros (recursos, historial, índices tipados, proyecciones) y las reglas que importan.

Una base de datos FHIR almacena recursos HL7 FHIR para que puedan ser leídos, buscados y versionados a través de la API FHIR; el esquema más común mantiene cada recurso como JSON y rellena tablas de índice separadas para los parámetros de búsqueda, en lugar de distribuir cada elemento a través de tablas relacionales normalizadas. Esta página explica los tres diseños habituales, el esquema que Anpheros ejecuta en PostgreSQL y cuándo no debería crear uno usted mismo.

Tres formas de almacenar FHIR

Three ways to store FHIR data

	Normalised tables	JSON + search indexes	Graph database
Stores any valid resource unchanged	—	✓	✓
Standard FHIR search on any parameter	◐	✓	◐
New fields need a schema migration	✓	—	—
Easy SQL reporting	✓	◐	—
Used by mainstream FHIR servers	◐	✓	—

◐ = possible with extra work. HAPI FHIR and Anpheros both keep the resource as JSON and index search parameters separately.

Los recursos FHIR son profundos, opcionales y extensibles: una sola Observación tiene docenas de elementos, tipos de elección (value[x]), codificaciones repetidas y extensiones. Normalizar eso en columnas relacionales significa una migración cada vez que un perfil agrega un campo. Mantener el recurso como JSON almacena cualquier cosa válida sin cambios; las tablas de índice lo hacen buscable.

El esquema de Anpheros

How a FHIR database is laid out (the Anpheros design)

APIFHIR R4 REST and the simpler /v1 REST API
Current resourcesOne row per resource: type, id, patient, version, the full FHIR JSON (JSONB)
Search indexesTyped tables filled on every write: token, string, date, reference, quantity
HistoryEvery version of every resource, never overwritten
ProjectionsFlat tables for the common REST views: observations, conditions, medications
PostgreSQLOne database per environment; sandbox and production are separate

Tabla	Una fila por	Columnas clave
`fhir_resources`	versión actual de un recurso	`resource_type`, `id`, `patient_id`, `version`, `json` (el recurso completo), `last_updated`, `deleted`, más columnas de procedencia
`fhir_history`	cada versión escrita alguna vez	`resource_type`, `id`, `version`, `json`, `last_updated`
`idx_token`	valor de búsqueda codificado o de identificador	system, code — para `code`, `category`, `identifier`, `status`
`idx_string`	valor de búsqueda de texto	texto normalizado — para nombres y texto libre
`idx_date`	valor de búsqueda de fecha	inicio y fin del rango — para `date`, `onset-date`, `birthdate`
`idx_reference`	valor de búsqueda de referencia	tipo y id de destino — para `patient`, `subject`, `encounter`
`idx_quantity`	valor de búsqueda de cantidad	value, system, unit — para `value-quantity`
`proj_observations`, `proj_conditions`, `proj_medications`	recurso, aplanado	las columnas en las que se filtran las API REST simples

En cada escritura, la plataforma valida el recurso, escribe la nueva versión en fhir_resources y fhir_history, reemplaza sus filas de índice y proyecciones, y registra la Procedencia. Una búsqueda como Observation?patient=…&code=http://loinc.org|4548-4&date=ge2026-01-01 se convierte en uniones en idx_reference, idx_token y idx_date; el resultado devuelve el JSON almacenado tal como fue escrito.

Reglas de diseño importantes

Indexar solo los parámetros de búsqueda declarados, y rechazar los desconocidos con 400 en lugar de ignorarlos silenciosamente.
Nunca actualizar en el lugar sin historial: las correcciones deben conservar lo que se conocía anteriormente.
Eliminación lógica (soft delete): un recurso eliminado desaparece de las lecturas y búsquedas, pero sus versiones permanecen para auditoría.
Columna de compartimento del paciente: almacenar patient_id en cada recurso hace que $everything, los filtros de consentimiento y el aislamiento por paciente sean económicos.
Validar antes de almacenar: un JSON inválido en el almacén rompe a todos los lectores posteriormente.

Preguntas frecuentes

¿Cuál es la mejor base de datos para FHIR?

La mayoría de los servidores FHIR de producción utilizan una base de datos relacional como PostgreSQL con el recurso almacenado como JSON (JSONB) y los parámetros de búsqueda indexados en tablas separadas. Combina almacenamiento flexible con búsquedas rápidas y estándar.

¿Debo normalizar los recursos FHIR en tablas relacionales?

Generalmente no para el almacenamiento principal. Las tablas normalizadas son adecuadas para informes; manténgalas como proyecciones construidas a partir de los recursos almacenados, como hace Anpheros para su API REST más sencilla.

¿Cómo almacena HAPI FHIR los recursos?

El servidor JPA de HAPI FHIR también almacena cada versión de recurso como JSON serializado y mantiene los parámetros de búsqueda en tablas de índice separadas. El diseño de Anpheros sigue el mismo principio.

¿Necesito crear una base de datos FHIR yo mismo?

Solo si necesita control total sobre los perfiles y tipos de recursos. De lo contrario, una plataforma FHIR administrada le proporciona almacenamiento, búsqueda, historial, consentimiento y auditoría sin ejecutar el esquema.

Relacionado

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card