GeriCare — un prototipo FHIR para centros geriátricos
Un ejercicio de exploración técnica sobre cómo se modela un ERP sanitario siguiendo el estándar HL7 FHIR R4, en un entorno —las residencias— donde la fragmentación de datos entre especialistas externos es la norma y no la excepción.
Por qué las residencias son el caso más difícil
Una residencia geriátrica media concentra a un tipo de paciente particularmente complejo: pluripatológico, polimedicado, con historia clínica repartida entre atención primaria, varios especialistas hospitalarios, servicios de rehabilitación externos y, a veces, un médico privado que el paciente ve desde hace décadas. Los datos viven en sitios distintos y no hablan entre sí.
El personal del centro gestiona medicación, constantes, ingresos y altas hospitalarias, evaluación funcional, incidencias. Pero el sistema informático habitual es un ERP generalista con una capa clínica añadida que no conoce estándares sanitarios. El resultado es que la información entra y sale del centro en PDF, emails y llamadas telefónicas.
Este proyecto exploró la pregunta conceptual: ¿cómo sería un ERP para residencias si se diseñara desde el estándar FHIR desde el primer día, en lugar de añadir una capa de interoperabilidad al final?
Modelado sobre recursos FHIR R4
El back-end en Django se construye sobre modelos que mapean 1:1 a recursos FHIR R4. Los pacientes no son una tabla personalizada; son un recurso Patientcon extensiones controladas para datos específicos del entorno residencial. Las constantes vitales son Observation con LOINC codes. La medicación es MedicationStatement con SNOMED-CT para principios activos.
La decisión de diseño era deliberada: cualquier dato que entre en GeriCare tiene que poder exportarse en un bundle FHIR válido sin transformación posterior. Eso significa que el sistema puede conversar nativamente con cualquier HIS hospitalario compatible con FHIR, con la historia clínica electrónica de atención primaria de la comunidad autónoma, o con un sistema central de gestión de residencias a nivel regional.
El prototipo no implementa toda la riqueza de FHIR —sería un proyecto de años—, sino un subconjunto mínimo funcional: perfiles de paciente, observaciones, medicación, y episodios asistenciales (Encounter) para registrar ingresos hospitalarios y altas. Suficiente para probar que el enfoque arquitectónico funciona.
Recursos FHIR R4 modelados en el prototipo: Patient, Observation, MedicationStatement y Encounter. El subconjunto mínimo para validar la portabilidad entre sistemas sanitarios europeos.
Qué es y qué no es este proyecto
GeriCare es un prototipo académico. No está desplegado en ningún centro, no se ha validado con datos reales y no pretende competir con los ERPs sanitarios comerciales existentes. Su valor está en haber recorrido el problema de diseño de punta a punta: entender qué implica modelar FHIR R4 en una capa de persistencia real, no como ejercicio de pizarra.
El aprendizaje principal es que empezar desde FHIR es muchísimo más barato que migrar después. Los ERPs sanitarios que hoy dicen tener compatibilidad FHIR suelen haber añadido una capa de traducción tardía, con todas las inconsistencias que eso implica. Un sistema que nace FHIR tiene esa compatibilidad como propiedad estructural, no como checkbox.
El aprendizaje secundario es regulatorio. El Espacio Europeo de Datos Sanitarios (EHDS) establece que los datos clínicos de pacientes europeos deben ser portables entre estados, y define FHIR como el estándar de intercambio por defecto. Cualquier sistema sanitario que se diseñe hoy sin FHIR nativo está condenado a una refactorización cara en los próximos cinco años.
Stack técnico
| Back-end | Python 3.11 · Django |
| Persistencia | PostgreSQL con modelos mapeados a FHIR R4 |
| Interoperabilidad | HL7 FHIR R4 · Recursos Patient, Observation, MedicationStatement, Encounter |
| Terminologías | LOINC (observaciones) · SNOMED-CT (medicación) |
| Estado | Prototipo académico · no desplegado en producción ni validado clínicamente |
¿Tu organización diseña un sistema sanitario desde cero?
Si estáis evaluando un ERP, una plataforma clínica o una capa de interoperabilidad, empezar desde FHIR es la diferencia entre un sistema que encaja con el EHDS y uno que tendréis que migrar en tres años. Puedo ayudar en el diseño conceptual y la auditoría del pliego técnico.