Por qué importa el rendimiento
El rendimiento afecta directamente tanto a la experiencia del usuario como a los costes operativos. Los usuarios finales necesitan acceso rápido a los datos durante su recorrido sanitario: cada milisegundo de retraso se multiplica a lo largo de miles de interacciones diarias, afectando a la eficiencia clínica y a los resultados de los pacientes. Más allá de la experiencia de usuario, el rendimiento determina los costes de infraestructura: el tamaño de la base de datos y las copias de seguridad, los recursos de cómputo y los gastos de mantenimiento escalan con el volumen de datos.
A la hora de elegir un servidor FHIR, el rendimiento es uno de los factores más importantes. Cada sistema construido sobre FHIR —soluciones EHR/PHR, CDR, plataformas de analítica— tiene patrones de carga de trabajo distintos y requiere características de rendimiento diferentes. Sin embargo, para un servidor FHIR de uso general, existen tres cargas de trabajo fundamentales y universales:
- CRUD — creación, lectura, actualización y eliminación de recursos individuales
- Procesamiento por lotes — importación masiva, intercambio de datos y escenarios de integración
- Búsqueda — consulta de recursos mediante diversos parámetros
Las API de procesamiento por lotes de FHIR se utilizan habitualmente en el intercambio e integración de datos —por ejemplo, para migrar datos de sistemas heredados a un servidor FHIR. Las operaciones CRUD y de búsqueda impulsan las cargas de trabajo OLTP: construcción de sistemas EHR/PHR, aplicaciones orientadas al paciente y herramientas de apoyo a la decisión clínica.
Qué estamos evaluando
Realizaremos pruebas comparativas de varios servidores FHIR de código abierto populares y los compararemos con Aidbox.
Para cada servidor mediremos:
- Rendimiento — operaciones por segundo bajo carga sostenida
- Latencia — tiempos de respuesta p99
- Consumo de recursos — utilización de CPU, memoria y E/S
- Uso de disco — cuánto almacenamiento requiere cada servidor para el mismo conjunto de datos
Hemos diseñado el conjunto de pruebas para capturar cómo se comporta el rendimiento tanto en una base de datos vacía como tras un volumen de datos considerable. Esto es fundamental: muchos servidores funcionan bien con conjuntos de datos pequeños, pero se degradan a medida que los datos crecen.
Fase 1: base de datos vacía
Partiendo de una instalación nueva:
- Medir la línea base de rendimiento de las operaciones CRUD
- Importar por lotes 1.000 registros sintéticos de pacientes (generados con Synthea)
- Evaluar el rendimiento de distintas operaciones de búsqueda
Esto establece la línea base: el mejor escenario posible para cada servidor.
Fase 2: carga de 100.000 pacientes
Importar 100.000 registros sintéticos de pacientes y medir:
- Duración total de la importación
- Tamaño de la base de datos en disco
- Consumo de recursos durante la importación
Esto simula un despliegue de tamaño medio realista y revela cómo gestiona cada servidor una presión de escritura sostenida.
Fase 3: pruebas de carga incremental
Con 100.000 pacientes ya en la base de datos:
- Volver a ejecutar las operaciones CRUD y comparar con la línea base de la base de datos vacía
- Importar 1.000 registros adicionales de pacientes sobre los 100.000 existentes
- Volver a ejecutar las operaciones de búsqueda y medir cómo varía el rendimiento de las consultas con el volumen de datos
La diferencia entre la Fase 1 y la Fase 3 revela la realidad: ¿hasta qué punto se mantiene el rendimiento a medida que crecen los datos?
Próximamente
Publicaremos todos los resultados comparativos, los scripts de prueba y los datos brutos en próximas entradas. Síganos en LinkedIn para no perderse las actualizaciones.
¿Tiene preguntas sobre el rendimiento de los servidores FHIR? Contáctenos: llevamos más de una década optimizando Aidbox para despliegues a gran escala.
