Transformación digital en entornos hospitalarios
De Access a
Arquitectura de Servicios
Cómo construir una capa de servicios que integra, reutiliza y escala
API First
FastAPI
REST / OpenAPI
IA Generativa
MySQL · PostgreSQL
Docker
Manuel Torres · Universidad de Almería · junio 2026
El punto de partida
La conversación que se repite
en todos los hospitales
— ¿Dónde están los datos del almacén de farmacia?
— En el Excel del turno de noche… o puede que en el Access que hizo Juan antes de jubilarse.
— ¿Y el de mantenimiento de equipos?
— Eso lo lleva otro Access. Creo que solo Marta sabe abrirlo.
Este intercambio resume uno de los problemas de gobernanza más extendidos en organizaciones grandes:
la proliferación de soluciones en silos.
El problema
El inventario invisible
💊
Farmacia
Caducidades y lotes de medicamentos
Crítico
🧪
Laboratorio
Muestras pendientes y alertas de valores
Crítico
🦠
Infección
Vigilancia epidemiológica y brotes
Crítico
🔧
Mantenimiento
Parque de equipos y revisiones
Alto
👩⚕️
RRHH
Turnos, guardias y vacaciones
Alto
♻️
Esterilización
Trazabilidad de material estéril
Alto
🍽️
Dietética
Dietas especiales por planta
Medio
📋
Calidad
Incidencias y no conformidades
Alto
Ninguna nació por capricho. Cada una resolvió una necesidad real que el HIS no cubría.
Los síntomas
Lo que ocurre cuando el parque
crece sin control
🚫
Datos que no se hablan
Farmacia no sabe que el frigorífico de mantenimiento tiene revisión pendiente. Nadie los conecta.
💾
Conocimiento en ficheros
Un .accdb en el escritorio. Si ese PC falla, los datos desaparecen con él.
🧑💼
"Eso lo sabe María"
Dependencia de personas, no de sistemas. La organización es frágil cuando María no está.
🔌
Integración imposible
Ningún Access tiene una API. Cada integración requiere exportar ficheros o construir puentes frágiles.
La lección clave
La arquitectura importa más
que la herramienta
❌ El patrón problemático
🗃️Datos encerrados en ficheros .accdb
🔒Lógica de negocio atrapada en VBA
👤Acceso solo desde el PC local
❓Sin auditoría, sin versiones, sin backups
🔗Integración manual vía Excel / ODBC
✅ El patrón objetivo
🌐Datos en BD relacional con backups
📋Lógica expuesta como servicio REST
🌍Accesible desde web, móvil, BI, otros servicios
📝Auditoría completa: quién, qué, cuándo
🔄Integración automática vía API estándar
La solución
Arquitectura API First
Los datos y la lógica de negocio son accesibles a través de servicios bien definidos,
independientemente de quién los consume.
CONSUMIDORES
🌐 Navegador
📱 App móvil
🔗 Otro servicio
📊 Excel / BI
↕ HTTP / REST / JSON
CAPA DE SERVICIOS (API)
📄 REST documentado con OpenAPI
🔐 Auth · Autorización · Auditoría
⚙️ Lógica de negocio · Validaciones
↕ SQL / ORM
CAPA DE DATOS
🗄️ MySQL · PostgreSQL · Oracle · SQL Server
🔒 Esquema limpio · Índices · Backups
El resultado
El mapa de servicios
del hospital
🖥️ PORTAL WEB / APP MÓVIL
↓ HTTP REST
💊 Farmacia API
🧪 Laboratorio API
🔧 Mantenimiento API
🦠 Infección API
👩⚕️ RRHH API
↓ SQL / ORDS
🗄️ MySQL / PostgreSQL
nuevos servicios
🏛️ Oracle / HIS / ERP
sistemas existentes
La arquitectura API First no obliga a desechar Oracle. Lo integra como un servicio más.
El acelerador
La IA generativa redistribuye
el trabajo técnico
El trabajo ya no consiste en escribir código,
sino en diseñar, dirigir y validar.
🔍
Analizar
Extraer el esquema, consultas, formularios y lógica VBA de la aplicación Access existente.
🏗️
Diseñar
Definir qué servicios existen, qué datos gestionan y cómo se relacionan entre sí.
💬
Formular
Redactar instrucciones precisas (prompts) para que el agente IA genere el código correcto.
✅
Validar
Comprobar que lo generado cumple los requisitos funcionales y de calidad esperados.
🔄
Iterar
Refinar con nuevos prompts hasta que el sistema se comporta exactamente como se espera.
🚀
Desplegar
Poner en producción con Docker Compose o la infraestructura corporativa existente.
El proceso de migración
De Access a servicio:
6 etapas
-
1
Análisis y extracción — Inventariar tablas, consultas, formularios, informes y módulos VBA. Validar que el inventario es completo.
-
2
Diseño del esquema (opcional) — Rediseñar la estructura de datos si es necesario para aprovechar las capacidades del nuevo motor.
-
3
Implementación del backend — Crear los endpoints REST con FastAPI, definir reglas de negocio y documentar con OpenAPI.
-
4
Implementación del frontend — Crear la SPA en React que consume el backend. Migrar formularios e informes existentes.
-
5
Entorno de desarrollo — Configurar Docker Compose con BD, backend y frontend para pruebas y validación local.
-
6
Migración de datos — Diseñar e implementar el proceso de traspaso desde Access, garantizando integridad y consistencia.
Etapa 1 · En la práctica
Prompt de análisis
Rol: Experto en Microsoft Access y desarrollo de sistemas de información,
backend y frontend
Contexto: Aplicación corporativa en Access para gestión de pacientes.
Objetivo: Migrar a arquitectura de servicios, con backend en MySQL,
servicios REST y frontend aparte.
Extrae: La estructura de la base de datos, código SQL de las consultas,
la lógica de los formularios y de los informes.
El agente IA genera scripts para interactuar con Access, extrae tablas, consultas, formularios
e informes y produce un inventario completo listo para la siguiente etapa.
Etapas 3-5 · En la práctica
Prompt de implementación
Adapta el plan de migración para crear un despliegue de desarrollo
con Docker Compose.
- Base de datos: MySQL
- Backend: FastAPI (con soporte OpenAPI)
- Frontend: SPA en React
Una vez adaptado, implementa el plan de migración
y comprueba que funcione todo.
El agente crea el docker-compose.yml, el esquema MySQL con datos migrados,
los endpoints FastAPI y la interfaz React. El profesional valida, no programa.
El resultado
Sistema completo,
listo para consumir
📄
API documentada (OpenAPI)
Swagger UI generado automáticamente. Cualquier consumidor puede explorar y probar los endpoints.
⚛️
Frontend React operativo
Interfaz web con los datos migrados desde Access. Formularios, listados e informes funcionales.
🐳
Entorno Docker Compose
BD MySQL + FastAPI + React levantados con un solo comando. Reproducible en cualquier máquina.
$ docker compose up
🌐 http://localhost:8000/docs → Swagger UI (OpenAPI)
🌐 http://localhost:3000 → Frontend React
Ejemplo · Caso real
De fichero Access a
API de Farmacia
GET /api/v1/medicamentos
GET /api/v1/lotes?caduca_antes=2026-07-01
POST /api/v1/lotes/{id}/asignar-planta
GET /api/v1/lotes/{id}/trazabilidad
GET /api/v1/reports/caducidades/pdf
🔄
Consume el sistema de pedidos
Consulta caducidades antes de generar una orden de compra. Automático.
📊
Alimenta el cuadro de mando
Stock próximo a caducar visible en tiempo real para dirección.
🔔
Notificaciones automáticas
Alertas enviadas por correo o al sistema de mensajería sin intervención manual.
Consideraciones críticas
Seguridad y cumplimiento
desde el diseño
📝
Auditoría completa
Cada operación queda registrada con usuario, fecha y hora. Trazabilidad total, algo imposible en Access.
🔐
Control de acceso granular
La API implementa autenticación y autorización: quién puede ver qué dato y realizar qué operación.
🔒
Cifrado en tránsito
Todas las comunicaciones por HTTPS, a diferencia de las conexiones ODBC en red local sin cifrar.
💾
Backups automatizados
La BD tiene políticas de backup gestionadas, no un fichero .accdb en un disco sin replicar.
⚠️ Regla de oro: ningún servicio de datos sanitarios debe desplegarse en producción sin revisión de seguridad que incluya autenticación, HTTPS y política de backups verificada.
El obstáculo real
La gestión del cambio:
el reto humano
El obstáculo más difícil en una migración no suele ser técnico. Es humano.
El profesional que lleva diez años usando Access tiene un flujo de trabajo construido alrededor de él.
-
✓
Involucrar a los usuarios clave en la definición de la nueva interfaz, no solo en la validación final.
-
✓
Mantener Access en modo solo lectura durante un período como red de seguridad mientras los usuarios se adaptan.
-
✓
Documentar los cambios en términos de flujo de trabajo, no de tecnología. El usuario no necesita saber qué es FastAPI.
Conclusión
Una oportunidad
estratégica
La diferencia entre el parque de Access de hoy y la arquitectura de servicios de mañana
no es que los usuarios dejen de tener herramientas a medida.
Es que esas herramientas estén construidas sobre cimientos sólidos:
datos accesibles, auditables, integrables y seguros.
La IA hace que un profesional técnico con capacidad analítica y conocimiento del negocio
pueda construir en días lo que antes requería semanas de programación.
Datos gobernados
Servicios interoperables
Integración real
El conocimiento no depende de que Marta esté disponible