De Disquetes a Edge Computing: 25 Años de Datos Sanitarios

Empecé a trabajar en informática sanitaria en 1997. Mi primera tarea fue mantener servidores HP 9000 ejecutando Micronetics MSM — una base de datos clave-valor multidimensional con su propio lenguaje llamado MUMPS. Todo funcionaba en terminales vía Telnet y Xterm. La red era Ethernet coaxial. TCP/IP era "eso de internet". Para mover datos de pacientes entre un centro de atención primaria y el hospital, un técnico conducía físicamente con un disquete cada mañana.

Hoy, nuestra plataforma Cadences ejecuta módulos sanitarios en Cloudflare Workers — distribuidos globalmente, serverless, con consultas que devuelven resultados en menos de 2ms. La base de datos es SQLite en el edge. El coste total de infraestructura es 5$/mes.

Esta es la historia de todo lo que pasó entre medias. No sacada de un libro de texto — sino de las trincheras.

1997-2001: La Era del Terminal

Cuando digo "informática sanitaria a finales de los 90", la mayoría imagina aplicaciones Windows y bases de datos SQL. La realidad era mucho más interesante — y mucho más alienígena para los desarrolladores actuales.

La Base de Datos que También Era un Sistema Operativo

Micronetics MSM (posteriormente adquirido por InterSystems y evolucionado hasta convertirse en Caché) no era solo una base de datos. Era un entorno de ejecución completo: motor de base de datos, servidor de aplicaciones y lenguaje de programación, todo en uno. El lenguaje era MUMPS (Massachusetts General Hospital Utility Multi-Programming System), diseñado en 1966 para datos sanitarios. En 1998 ya tenía 32 años de antigüedad — y ejecutaba la mayoría de los sistemas de información hospitalaria en España.

MUMPS almacenaba datos en globals — estructuras clave-valor jerárquicas y multidimensionales. Piensa en ellos como árboles profundamente anidados donde cada nodo es a la vez un valor y un punto de ramificación:

^PACIENTE("12345","NOMBRE") = "García López, María"
^PACIENTE("12345","ALERGIAS",1) = "Penicilina"
^PACIENTE("12345","ALERGIAS",2) = "Ibuprofeno"
^PACIENTE("12345","VISITAS","20000115","LAB","GLUCOSA") = "95"

Sin esquema. Sin tablas. Sin SQL. Solo árboles de claves y valores que podían recorrerse programáticamente usando $ORDER — una primitiva que devolvía la siguiente clave hermana en cualquier nivel. Esto era NoSQL treinta años antes de que nadie acuñara el término.

La Infraestructura

La instalación física de un hospital catalán típico en 1998:

• Servidores HP 9000 ejecutando Unix con MSM/MUMPS como capa de base de datos y aplicación
• Ethernet coaxial — no TCP/IP; aquellos protocolos de LAN anteriores que precedieron al dominio de internet en redes corporativas
• Acceso por terminal vía Telnet y Xterm — pantallas verdes sobre negro, navegación solo con teclado, cero interfaz gráfica
• Servidores espejo (mirror) con replicación por journaling — cada transacción se registraba y se reproducía en un servidor de respaldo. Conceptualmente es lo mismo que el WAL streaming de PostgreSQL, pero funcionando a mediados de los 90 sobre hardware propietario
• Conexiones DDP (Distributed Data Processing) entre servidores de la misma red — algo así como comunicación interprocesos, pero entre máquinas
• Servidores de archivos Novell NetWare + Windows NT para las pocas aplicaciones Windows que empezaban a aparecer (mayoritariamente administrativas)

32 Puertos, 25 Analizadores y Mucho RS-232

El laboratorio del hospital era donde ocurría la ingeniería de verdad. Teníamos una tarjeta RS-232/paralelo de 32 puertos instalada en el servidor, conectando aproximadamente 25 analizadores de laboratorio diferentes — hematología, bioquímica, análisis de orina, inmunología — cada uno hablando su propio protocolo serie.

Cada resultado de análisis de sangre viajaba desde el analizador por un cable serie, a través de la tarjeta RS-232, hasta una rutina MUMPS que parseaba el protocolo específico del fabricante, validaba los valores y los almacenaba en el global correspondiente. Si un resultado de glucosa volvía a 450 mg/dL, la rutina lo marcaba y el sistema alertaba al médico en su terminal — en tiempo real, al estilo de 1998.

Esto era IoT antes de que existiera IoT. Sin HTTP, sin JSON, sin MQTT. Solo puertos serie, flujos de bytes y parsers artesanales para cada modelo de dispositivo.

El Expreso del Disquete

Esta es la parte que hace reír — o llorar — a los desarrolladores modernos.

Los hospitales catalanes a finales de los 90 tenían una red de CAPs (Centres d'Atenció Primària — centros de atención primaria) dispersos por su territorio. Estos centros tenían sus propias instalaciones MSM pequeñas, pero no había conexión de red fiable con el hospital. Algunos tenían líneas dedicadas con módem, pero muchos no.

¿La solución? Un técnico, un coche y un disquete.

Cada mañana, un técnico conducía una ruta por los centros de atención primaria. En cada parada, ejecutaba una rutina de exportación que volcaba las visitas del día en un disquete de 3,5" — 1,44 MB de encuentros con pacientes, comprimidos en un formato propietario. Luego conducía al hospital y cargaba los datos en el sistema central, que los usaba para organizar el movimiento de los historiales físicos de pacientes (carpetas de papel reales con historias clínicas) y coordinar las derivaciones.

Cuando el módem fallaba — y los módems siempre fallaban — el disquete era el plan B. El sneakernet era la CDN de los 90.

La Capa Humana: Lo Que Perdimos

Algo que nunca aparece en las retrospectivas técnicas es el modelo de relación de aquella época. Cada semana íbamos físicamente a cada hospital para mantenimiento. Cuatro horas, ocho horas, a veces dos o tres días en los centros más grandes.

Durante esas visitas, no solo arreglábamos servidores. Nos sentábamos con:

• El coordinador de informática — a menudo un administrativo reconvertido que había aprendido MUMPS por necesidad
• Jefes de servicio médico — desde cirugía hasta urgencias, diálisis o medicina interna
• El gerente del hospital — que necesitaba informes y sabía qué quería el consejo
• Personal administrativo — que usaban los terminales 8 horas al día y conocían cada atajo, cada bug, cada workaround

Entendíamos el negocio porque estábamos físicamente incrustados en él. Cuando urgencias decía "la pantalla de triaje va lenta", podíamos observarlos trabajar, contar los segundos, y entender que "lenta" significaba "una enfermera tiene que esperar 3 segundos con un paciente sangrando delante."

Ese contexto es irremplazable. El soporte IT remoto moderno es eficiente, escalable, y completamente ciego al coste humano de un retraso de 3 segundos en un box de trauma.

2001-2006: El Desvío Industrial (Y el SCADA Escrito en Lisp)

Entre 2001 y 2006, dirigí mi propia empresa con hasta 20 empleados, trabajando en automatización industrial — programación de PLCs, robótica de almacenes para SEAT Martorell y sistemas de cronometraje deportivo para AMB-IT/MyLaps. Pero el proyecto técnicamente más fascinante fue el sistema SCADA para Aguas de Reus (la empresa de aguas de Reus, Tarragona).

Aquel SCADA funcionaba sobre estaciones de trabajo HP-UX conectadas a PLCs Sixnet (programados en C) comunicándose vía packet radio. El software de supervisión estaba escrito en C, Lisp y TCL/TK — sí, un sistema de control industrial en tiempo real con la interfaz construida en TCL/TK y la lógica de negocio en Lisp. Los PLCs Sixnet solo tenían cuatro hilos de ejecución, pero podían coordinarse entre sí y reportar a la central SCADA casi en tiempo real.

En 2008 sustituí aquel SCADA original por Schneider Vijeo Citect, pero con un giro: la base de datos subyacente había sido migrada de HP-UX con MSM a InterSystems Caché, y construí conectores ODBC propios para que Vijeo Citect pudiera acceder a las mismas estructuras de datos que usaba MSM — sin cambiar nada de la capa de comunicación con PLCs. El mismo patrón que aplicaría después en sanidad: reemplaza la interfaz, preserva la capa de datos, no rompas lo que ya funciona.

2006-2012: La Era Caché y la Maratón de 250 Clientes

Simultáneamente con el trabajo industrial, volví a sanidad en 2006. El panorama había evolucionado — MSM se había convertido en InterSystems Caché, el mismo motor multidimensional pero con una capa ObjectScript, un servidor web y soporte SQL tentativo atornillado encima.

Mi rol: dar soporte a aproximadamente 250 clientes — clínicas y hospitales — en rotación 24/7. Cuando una corrupción de Caché golpeaba un global en producción a las 3 de la madrugada y el hospital no podía acceder a los historiales de pacientes en urgencias, yo era el que estaba al teléfono.

Construyendo Dashboards SQL Sobre Datos Clave-Valor

Los clientes necesitaban inteligencia de negocio, pero sus datos vivían en globals MUMPS — sin esquema, sin tablas, sin claves foráneas. Dos consultoras reputadas de Barcelona habían intentado previamente construir soluciones de BI para la red hospitalaria y habían fracasado. Intentaron conectarse vía ODBC y ejecutar consultas complejas como si Caché fuera una base de datos SQL estándar. No lo era. El rendimiento era catastrófico y los resultados eran basura por la estructura de datos multidimensional.

Mi enfoque fue diferente: extraer directamente de los globals, transformar en tránsito, y aterrizar en SQL Server. Usé Pentaho Data Integration (Spoon/PDI) como motor ETL — la mejor opción open-source de la época. Cientos de diagramas de transformación, cada uno mapeando una estructura global específica a un esquema relacional.

Sobre SQL Server, construí una interfaz de BI operativa usando Backbone.js (el abuelo de los frameworks MV* modernos) y Java. No era un dashboard estático — los usuarios podían lanzar sus propias recargas de datos a través de la UI, impulsadas por tablas de trigger que arrancaban trabajos ETL. BI self-service en 2013, antes de que el término estuviera de moda.

La Migración: Una Higuera Estranguladora que Duró 4 Años

En 2013, me contrataron directamente desde la red hospitalaria — el mismo cliente al que había dado soporte desde el lado del proveedor. La misión: migrar el Sistema de Información Hospitalaria (HIS) completo de Caché/MUMPS a un stack moderno.

Conocía ambos lados íntimamente. Había hecho la migración del Y2K para muchos de estos hospitales. Había mantenido Caché durante años. Sabía por qué cada dato estaba almacenado como estaba — porque yo había ayudado a ponerlo ahí una década antes.

Construyendo un Puente Entre Dos Mundos

La estrategia de migración fue lo que Martin Fowler popularizó más tarde como el patrón Strangler Fig (Higuera Estranguladora) — reemplazar funcionalidad gradualmente mientras ambos sistemas coexisten. Excepto que los libros de texto lo describen en abstracto. Yo tuve que hacerlo funcionar con datos de pacientes en vivo en 8 servidores hospitalarios.

Paso 1: Replicar primitivas MUMPS en Python. Implementé las mismas operaciones de recorrido ($ORDER, $GET, $DATA) como funciones Python que llamaban a clases de Caché a través del puente C++ de InterSystems. Esto me daba acceso a velocidad nativa a los globals con la flexibilidad de Python para construir APIs.

Paso 2: Construir una capa de API REST. Usando Bottle (un framework web Python ligero), expuse endpoints REST limpios — /api/pacientes, /api/visitas, /api/resultados — que traducían entre el mundo moderno y los datos multidimensionales debajo. Esto convirtió un monolito legacy sellado en una arquitectura orientada a servicios.

Paso 3: Captura de Cambios de Datos (CDC) Bidireccional. Esta fue la pieza más difícil y crítica. Necesitaba que ambos sistemas reflejaran los cambios del otro en tiempo casi-real:

• Legacy → Nuevo: "Pinché" en el mecanismo de replicación mirror de Caché — el mismo sistema de journaling usado para la redundancia de servidores — para leer un flujo de eventos de todas las operaciones de datos. Un proceso Python consumía este flujo y replicaba los cambios en SQL Server, donde el nuevo HIS basado en Angular podía leerlos.
• Nuevo → Legacy: Triggers de SQL Server alimentaban una tabla de eventos separada. Otro proceso Python consumía esos eventos y, usando mis mapeos de primitivas MUMPS, escribía los cambios de vuelta en Caché — exactamente como lo habría hecho la aplicación legacy.

¿La latencia? 100 milisegundos.

Con 100ms de ida y vuelta, un médico podía modificar un registro de paciente en el viejo sistema de terminales y verlo instantáneamente en la nueva interfaz Angular — y viceversa. La probabilidad de un conflicto de datos (dos personas modificando el mismo campo en menos de 100ms) era estadísticamente cero en un flujo de trabajo clínico.

Los Números

• 8 servidores Caché en diferentes centros hospitalarios, todos migrados progresivamente
• 40 TB de datos no estructurados limpiados, transformados y migrados — notas clínicas, PDFs mal formados, imágenes codificadas en base64, décadas de registros médicos acumulados
• 4 años de coexistencia — ambos sistemas funcionando en paralelo, sincronizados bidireccionalmente a 100ms
• Integraciones HL7 y DICOM reconstruidas a través de Mirth Connect y Python
• 3,5 años de guardia 24/7 — porque nadie más entendía tanto el legacy como el nuevo sistema al nivel necesario para mantenerlos sincronizados

Un día, los 8 servidores Caché se apagaron definitivamente. La higuera estranguladora había consumido el árbol. La migración estaba completa.

El Patrón que se Repite

Después de la migración hospitalaria, pasé a Werfen (división SysteLab) — líder mundial en diagnóstico in vitro — donde me enfrenté a otro desafío legacy: un sistema de hemodinámica (MediVector) construido en Delphi con un modelo extremo de Entity-Attribute-Value (EAV). Sin tabla de "pacientes", sin tabla de "visitas" — solo tablas de "objetos", "atributos", "valores" y "relaciones". Un Modelo de Datos Universal diseñado por ingenieros aeroespaciales (el software provenía de una empresa que fabricó componentes para el Transbordador Espacial).

Construí el mismo tipo de puente: funciones SQL que desnormalizaban el modelo EAV en tiempo real, expuestas a través de una API REST en .NET Core, con la lógica de negocio de Delphi preservada vía interoperabilidad DLL para las escrituras. El patrón CQRS — lecturas vía SQL, escrituras vía el motor legacy — surgió naturalmente de la restricción. Ese sistema sigue funcionando hoy en más de 40 hospitales de España, incluyendo Vall d'Hebron, La Paz y la red del SAS.

El patrón es siempre el mismo: entiende las primitivas del legacy, construye una capa de traducción, expón APIs modernas, coexiste hasta que el sistema viejo pueda retirarse.

2024-2026: La Era del Edge

Hoy en Cadences Lab, nuestro módulo sanitario (Heartbeat) funciona sobre Cloudflare Workers con D1 (SQLite en el edge). Comparemos las arquitecturas a lo largo de 25 años:

Aspecto	1998	2013	2025
Base de datos	Globals MUMPS (clave-valor)	SQL Server + Caché (híbrido)	D1/SQLite (edge)
Transporte de datos	Disquete / módem	TCP/IP + eventos CDC	HTTP/2 al PoP más cercano
Latencia de consulta	~50ms (terminal local)	~100ms (sync CDC)	~2ms (query en edge)
Integración de dispositivos	RS-232 serie (parsers custom)	HL7/DICOM vía Mirth	FHIR REST + webhooks
Servidores	HP 9000 (físicos, on-prem)	8 Caché + clúster SQL Server	0 (serverless)
Coste mensual	~50.000$/mes (hardware + personal)	~15.000$/mes (infra + licencias)	5$ (D1 + Workers)
Mantenimiento	2 técnicos, media semana in situ	1 arquitecto, guardia 24/7	Deploy and forget
Backup	Cinta + journaling mirror	Backup SQL Server + scripts	D1 time travel (30 días)

¿La parte más llamativa? El modelo de datos ha dado la vuelta completa. Los globals MUMPS en 1998 eran clave-valor. D1 en 2025 es SQLite — en su núcleo, un almacén clave-valor B-tree con sintaxis SQL encima. Fuimos de clave-valor, a través de relacional, y de vuelta a clave-valor con una interfaz SQL. Los ingenieros de 1998 no estaban equivocados sobre el modelo de datos. Simplemente iban 25 años adelantados en el modelo de despliegue.

Lo que 25 Años de Datos Sanitarios Me Enseñaron

1. Los fundamentos nunca cambian. En 1998 necesitaba baja latencia, integridad de datos, sincronización en tiempo real y tolerancia a fallos. En 2025 necesito exactamente lo mismo. Las herramientas evolucionan — de RS-232 a WebSockets, de journaling a WAL, de sneakernet a CDN — pero los principios de ingeniería son idénticos.

2. Los sistemas legacy no son estúpidos — son supervivientes. MUMPS sigue funcionando en grandes hospitales y bancos de todo el mundo porque funciona. Ese "feo" recorrido $ORDER es algorítmicamente idéntico a un SCAN de Redis. Los ingenieros que diseñaron estos sistemas en los años 60 entendieron patrones de acceso a datos que los desarrolladores modernos están redescubriendo a través de NoSQL y almacenes clave-valor.

3. Cada migración exitosa que he hecho siguió el mismo patrón: aprender las primitivas del legacy en profundidad, construir una capa de interoperabilidad que hable ambos idiomas, coexistir el tiempo que sea necesario, y retirar el sistema viejo solo cuando el nuevo haya demostrado su valía bajo carga de producción. No hay atajos. Las consultoras que intentan una reescritura "big bang" siempre fracasan — lo vi ocurrir dos veces antes de que me trajeran para arreglar el desastre.

4. La capa humana importa más que la capa técnica. Las visitas semanales de mantenimiento presencial de los 90 nos daban algo irremplazable: contexto. Entendíamos que un retraso de 3 segundos no era una métrica de rendimiento — era una enfermera de pie frente a un paciente sangrando. El IT moderno remote-first es eficiente y escalable, pero hemos perdido algo en la transición. En Cadences Lab lo compensamos manteniéndonos radicalmente cerca del flujo de trabajo del usuario — no mediante visitas a la oficina, sino mediante telemetría en tiempo real y canales de comunicación directos.

5. La curva de costes es la revolución real. De 50.000$/mes en hardware y personal a 5$/mes en el edge, con mejor rendimiento, disponibilidad global y backups automáticos. Esto no es mejora incremental — es un cambio fundamental en lo que es posible. Un desarrollador en solitario hoy puede desplegar infraestructura sanitaria que habría requerido un equipo de 10 personas y 600.000$/año en los 90. Esa es la verdadera historia de los últimos 25 años.