# FHIR frente a una base de datos médica personalizada

> Sus propias tablas o HL7 FHIR R4 para datos médicos: la misma lectura almacenada de ambas maneras, las compensaciones lado a lado, cuándo cada una es correcta y la división habitual entre su base de datos y el registro FHIR.

Source: https://developers.anpheros.com/es/guides/fhir-vs-custom-database

**Un equipo que inicia un producto de salud generalmente se enfrenta a la misma elección desde el principio: diseñar sus propias tablas para pacientes, mediciones y diagnósticos en PostgreSQL u otra base de datos, o almacenar datos médicos como recursos HL7 FHIR R4 desde el principio.** Un esquema personalizado es más rápido desde el primer día y se adapta exactamente a su producto. FHIR cuesta más reflexión inicial y se amortiza cada vez que los datos tienen que salir de su sistema, ser auditados, compartidos con consentimiento o ser leídos por alguien que no sea usted. Esta página expone las compensaciones honestamente, con la misma lectura almacenada de ambas maneras, y dice cuándo cada opción es correcta.

Esta es una pregunta diferente a *qué* servidor FHIR usar. Para eso, consulte [Cómo Anpheros se compara con otros servidores FHIR](https://developers.anpheros.com/es/guides/fhir-server-comparison).

## La misma lectura, dos maneras

Una lectura de presión arterial en un esquema personalizado:

```sql
CREATE TABLE bp_readings (
  id          uuid PRIMARY KEY,
  user_id     uuid REFERENCES users(id),
  systolic    int,
  diastolic   int,
  measured_at timestamptz,
  created_at  timestamptz DEFAULT now()
);
```

Simple, rápido de consultar, exactamente lo que la aplicación necesita. Luego vienen las preguntas que la tabla no responde:

- ¿Qué dispositivo o persona produjo el valor? ¿Fue introducido por el paciente, medido por un manguito o ingresado por una enfermera?
- ¿Cuál era el valor antes de que alguien lo corrigiera y quién lo corrigió?
- ¿Cómo lo lee un sistema de clínica, un laboratorio o una aseguradora? ¿Qué significa `systolic` en su sistema?
- ¿Cómo lo comparte el paciente con la aplicación de su médico y deja de compartirlo el próximo mes?
- Cuando se agregan frecuencia cardíaca, peso, HbA1c y otras 200 mediciones, ¿son 200 tablas o una tabla genérica que diseña usted mismo?

La misma lectura como FHIR R4:

```json
{"resourceType": "Observation", "status": "final",
 "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "vital-signs"}]}],
 "code": {"coding": [{"system": "http://loinc.org", "code": "85354-9", "display": "Blood pressure panel"}]},
 "subject": {"reference": "Patient/d09e3942-…"}, "effectiveDateTime": "2026-10-10T08:30:00Z",
 "component": [
   {"code": {"coding": [{"system": "http://loinc.org", "code": "8480-6"}]}, "valueQuantity": {"value": 138, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]"}},
   {"code": {"coding": [{"system": "http://loinc.org", "code": "8462-4"}]}, "valueQuantity": {"value": 88, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]"}}],
 "meta": {"versionId": "1"}}
```

Más verboso, pero cada parte tiene un significado que cualquier sistema FHIR comparte: LOINC indica qué se midió, UCUM indica la unidad, `meta.versionId` inicia un historial y la misma forma `Observation` contiene las otras 200 mediciones. Con Anpheros, un recurso `Provenance` también registra quién lo escribió. [Cómo almacenar registros médicos usando FHIR R4](https://developers.anpheros.com/es/guides/store-medical-records-fhir) lo explica.

## Lado a lado

| | Esquema personalizado | FHIR R4 |
|---|---|---|
| Tiempo hasta la primera funcionalidad | horas | uno o dos días para aprender los recursos |
| Adaptación a su producto | exacto | general; la vista de su producto se sitúa encima |
| Añadir un nuevo tipo de datos | una migración por tipo | normalmente un nuevo código en un recurso existente |
| Significado fuera de su sistema | ninguno sin un mapeo | códigos compartidos (LOINC, ICD-10, ATC, UCUM) |
| Historial y correcciones | usted lo diseña | versiones y `_history` por diseño |
| Quién escribió qué | usted lo diseña | `Provenance` (automático en Anpheros) |
| Intercambio con clínicas, laboratorios, otras aplicaciones | integración personalizada cada vez | API FHIR R4, importación HL7 v2, International Patient Summary |
| Consentimiento del paciente por aplicación | usted lo diseña | ámbitos SMART on FHIR y OAuth |
| Consultas para análisis | SQL plano | búsqueda FHIR, o exportación a su almacén |
| Regulación (Artículo 9 del RGPD, EHDS) | usted documenta cada parte | formatos estándar a los que se refiere la regulación |

## Cuándo un esquema personalizado es la opción correcta

- **Los datos no son realmente médicos, o no son sobre una persona.** Planes de entrenamiento, contenido, un catálogo de productos: usa tus propias tablas.
- **Un prototipo de corta duración** para probar si alguien quiere el producto, con datos sintéticos y un plan para migrar.
- **Los datos no se ajustan bien a los modelos estándar**, por ejemplo, una nueva medición de investigación. FHIR aún puede transportarlos (`Observation` con tu propio sistema de códigos, o `Basic`), pero una tabla personalizada puede ser más clara.
- **Análisis intensivos.** Incluso con FHIR como sistema de registro, la mayoría de los equipos copian los datos a un almacén de datos con su propia estructura para la generación de informes.

## Cuándo FHIR es la llamada correcta

- Los datos son el historial médico de una persona: mediciones, diagnósticos, medicamentos, alergias, resultados de laboratorio, documentos.
- Saldrán de su sistema: al paciente, a un médico, a una clínica, a un laboratorio, a una aseguradora, a un modelo de IA o a un competidor cuando el paciente se mude.
- Necesita mostrar quién escribió qué y qué cambió: auditorías, seguridad clínica, disputas.
- Los pacientes concederán y revocarán el acceso por aplicación.
- Vende en la Unión Europea, donde el Espacio Europeo de Datos Sanitarios espera que los registros sean intercambiables en formatos estándar.

## El camino intermedio habitual

La mayoría de los productos terminan teniendo ambas opciones, divididas por tipo de datos:

```
your database                         FHIR record (Anpheros)
─────────────                         ──────────────────────
users, sessions, settings             Patient
subscriptions, billing                Observation, Condition, MedicationStatement
product content, feature flags        AllergyIntolerance, Immunization, DocumentReference
user id → patient id (one column)     Provenance, Consent, history
caches and analytics copies  ◄─────── webhooks
```

Tu base de datos se mantiene pequeña y con la forma del producto. El registro médico es estándar, versionado y compartible, y no tuviste que crearlo. [Backend y base de datos de aplicaciones médicas](https://developers.anpheros.com/es/guides/medical-app-backend) describe esta división en detalle, y [Cómo crear una API de atención médica con TypeScript](https://developers.anpheros.com/es/guides/healthcare-api-typescript) la implementa.

## Lo que se necesita para crear FHIR por su cuenta

Elegir FHIR no significa escribir un servidor FHIR. Sus opciones son un servidor de código abierto que usted ejecuta, el almacén FHIR de un proveedor de nube, una plataforma de atención médica de código abierto o una base de datos de atención médica administrada como Anpheros. Difieren en quién maneja el consentimiento, la auditoría, la procedencia, la residencia y las integraciones, lo cual se detalla en [Cómo se compara Anpheros con otros servidores FHIR](https://developers.anpheros.com/es/guides/fhir-server-comparison).

## Preguntas frecuentes

### ¿Es FHIR una base de datos?
No. FHIR es un estándar para la estructura e intercambio de datos de salud: recursos, códigos y una API REST. Un servidor FHIR o una base de datos FHIR administrada almacena los recursos e implementa la API sobre una base de datos real.

### ¿Puedo almacenar recursos FHIR en PostgreSQL yo mismo?
Sí, como columnas JSON con sus propios índices, y algunos servidores de código abierto hacen exactamente eso. El trabajo está en todo lo relacionado con el almacenamiento: parámetros de búsqueda, versionado, referencias, validación, control de acceso por paciente y procedencia.

### ¿Puedo empezar con un esquema personalizado y pasar a FHIR más tarde?
Puede hacerlo, y muchos equipos lo hacen, pero la migración es un proyecto de mapeo: cada tabla necesita códigos, unidades y autores que nunca registró. Almacenar datos médicos como FHIR desde la primera característica cuesta menos que convertirlos más tarde.

### ¿Necesito FHIR para cumplir con el GDPR?
No. El GDPR no requiere un formato particular. FHIR facilita el cumplimiento de varias obligaciones: portabilidad (el registro se exporta en un formato estándar), control de acceso por propósito y mostrar quién procesó qué datos.

## Relacionado

- [Esquema de base de datos FHIR](https://developers.anpheros.com/es/guides/fhir-database-schema): cómo se almacenan e indexan los recursos FHIR
- [Cómo almacenar registros médicos usando FHIR R4](https://developers.anpheros.com/es/guides/store-medical-records-fhir)
- [Plataforma FHIR](https://developers.anpheros.com/es/guides/fhir)
- [Cómo Anpheros se compara con otros servidores FHIR](https://developers.anpheros.com/es/guides/fhir-server-comparison)
- [Backend y base de datos de aplicaciones médicas](https://developers.anpheros.com/es/guides/medical-app-backend)
- [API de salud](https://developers.anpheros.com/es/guides/healthcare-api)