🏥 El Tesoro del Dr. Arteaga

17 años de historia clínica de un consultorio ORL, guardados en una base de datos de 1996. Vamos a explorarla con calma y decidir cómo mudarla a CIMA sin perder nada.

💎 ¿Qué tenemos?

17 años de práctica médica (mayo 2008 → febrero 2026), un archivo de 28 MB, 27 cuartos con datos.

📖 La metáfora que vamos a usar

La base de datos es como una casa. Cada tabla es un cuarto. En cada cuarto hay muchas cosas guardadas (las filas) y cada cosa tiene varias etiquetas (las columnas). Las puertas entre cuartos son los joins: cómo se conectan los datos. Hay dos casas: la Casa Vieja del Dr. Arteaga (sistema PowerBuilder + SQL Anywhere 5.0 de 1996) y la Casa Nueva CIMA (Cloudflare D1, 2026). Hay que mudar todo de una a la otra.

📦 Lo que destapamos

  • ✅ Identificamos el formato: SQL Anywhere 5.0 (Watcom 1994), no encriptada
  • ✅ Encontramos el motor original en F:\proyecto hcc223\sqlany50\ — coincidencia exacta de versión
  • ✅ Default password DBA/SQL funcionó al primer intento
  • ✅ Extraídas las 27 tablas con datos → 86,259 filas
  • ✅ SQL completo generado: 02-export/otorrino-arteaga.sql (15 MB)
  • ✅ Base SQLite navegable: 02-export/otorrino-arteaga.sqlite (14.6 MB)
  • 📌 La DB es de hace ~1.5 meses → faltan ~40 pacientes recientes (a sincronizar después)

🏘️ Las Dos Casas

Vista de planta de cada casa. Cada cuarto tiene tamaño proporcional a cuántas cosas guarda. Pasa el mouse para ver el nombre.

🏚️ Casa Vieja — Sistema del Dr. Arteaga

SQL Anywhere 5.0 · 27 cuartos con datos · 86,259 cosas guardadas

🏢 Casa Nueva — CIMA

Cloudflare D1 · 24+ cuartos · cuartos vacíos esperando a mudarse

Clínico (lo más importante)
Estudios específicos
Catálogos / listas
Financiero
Metadata / sin valor
Tablas CIMA

🚪 Cuarto por Cuarto

Cada tarjeta es una tabla del sistema viejo. Haz click para ver todas sus columnas, una muestra real, y a qué tabla CIMA mapea.

🌉 Los Puentes — Mapeo Casa Vieja → Casa Nueva

Cada fila es una tabla del Dr. Arteaga y a qué tabla(s) de CIMA va. El color de la flecha dice qué tan fácil es el traslado.

DIRECTO mapea 1:1 sin pérdida ADAPTAR requiere transformación NUEVO hay que extender CIMA SKIP sin valor migrable

⚖️ FODA — ¿Vale la pena agrandar CIMA?

Análisis estratégico de mudarse ahora (CIMA solo tiene <20 pacientes — momento ideal para cambios).

💪 Fortalezas

Lo que YA tenemos a favor

  • 17 años de data real validada — no es un dataset hipotético, son 7,804 pacientes reales con 16,494 consultas reales
  • CIMA aún es joven (<20 pacientes) — costo de cambios al schema es bajo, no hay deuda técnica acumulada
  • El schema CIMA cubre 95% del modelo viejo sin cambios
  • Cero encriptación en el .db viejo — exportación limpia
  • Texto libre en sub-tablas clínicas de CIMA (consultation_*) → migración 1:1 del texto plano del viejo
  • Modelo ORL específico (s001) en CIMA ya está alineado con la especialidad del Dr.

🚀 Oportunidades

Lo que ganamos haciéndolo

  • Validar CIMA con un caso real complejo — un consultorio activo de 17 años descubre todos los edge cases
  • Tener un primer cliente "Plan Piloto" con data masiva → testimonio + caso de uso
  • Enriquecer catálogos CIMA con 1,291 dx + 1,067 motivos + 823 medicamentos validados por un especialista activo
  • Activar features financieras con 15,246 cobros reales históricos → reportes con peso
  • Banco de docs reales (4,380 informes) para diseñar mejor plantillas y export PDF
  • Definir un workflow de migración estándar que sirva para futuros clientes con sistemas viejos

⚠️ Debilidades

Limitaciones que tenemos que aceptar

  • Examen de oídos sin lateralidad — el sistema viejo no separa oído derecho/izquierdo. Hay que mapear texto único a las dos regiones de CIMA
  • Encoding cp1252 con caracteres torcidos — sueñño, D'SOUSA aparecen como sueòo, DµSOUSA. Limpiables con regex pero hay edge cases
  • 3 fechas de nacimiento basura (años 3016, 9009, 9730) — typos viejos, limpiables a null
  • 132 doctores referentes sin tabla en CIMA — hay que crear referring_doctor table
  • Sin acceso a las imágenes endoscópicas (en disco del PC viejo del Dr., no en el .db)
  • Faltan los ~40 pacientes del último mes y medio (DB de hace 1.5 meses)

🔥 Amenazas

Riesgos a vigilar durante la migración

  • Volumen 4000× mayor que CIMA actual — 7,804 pacientes vs <20. Performance D1 en queries cross-table puede degradarse
  • R2 storage costs si generamos 4,380 PDFs + imágenes endoscópicas → calcular antes
  • 4 cambios al schema CIMA tocan código del Worker y la SPA — riesgo de regresión si no se hace ordenado
  • Rollback complejo si algo sale mal con 86,259 filas insertadas → backup obligatorio del D1 antes
  • Dependencia del PC viejo si necesitamos re-extraer (la DB no está en cloud, sólo USB)
  • Curva de aprendizaje del Dr. al pasar a un nuevo sistema con su data familiar — UX tiene que sentirse natural

📊 Veredicto del FODA

Fortalezas + Oportunidades dominan claramente. Las Debilidades son técnicas y resolubles. Las Amenazas son operacionales (mitigables con backups, fases, y verificación).

Recomendación FODA: sí extender CIMA. El momento es óptimo (poco tráfico real) y la ganancia (caso piloto validado + cliente real) supera el costo.

🛠️ Plan de Extensión CIMA

4 cambios mínimos al schema CIMA D1 para que toda la data del Dr. quepa sin perder nada. Son aditivos: no rompen nada existente.

1 Nueva tabla referring_doctor

El Dr. tiene 132 referentes con clínica, consultorio, teléfono, especialidad. Hoy CIMA solo guarda patient.referred_by como texto libre — pierde estructura.

CREATE TABLE referring_doctor (
    id TEXT PRIMARY KEY,        -- rd_NNNNNNNN
    tenant_id TEXT NOT NULL,
    firstname TEXT,
    lastname TEXT,
    institution TEXT,           -- HCC, etc.
    office TEXT,                -- "PISO 4 CONS 410"
    phone TEXT,
    city TEXT,
    specialty TEXT,
    legacy_id TEXT,             -- id en sistema viejo
    notes TEXT,
    created_at TEXT,
    updated_at TEXT
);
ALTER TABLE patient ADD COLUMN referring_doctor_id TEXT;

2 Nueva región cavidad_oral en el modelo s001

El Dr. examina cavidad oral aparte de orofaringe (prótesis dentales, edéntula, etc.). Es estándar ORL. CIMA tiene 6 regiones: cara, oido_der, oido_izq, nariz, orofaringe, cuello. Agregamos una.

-- No requiere cambio de schema (region es un valor en columna existente).
-- Solo poblar el catálogo de chips:
INSERT INTO model_chip_category (id, model_id, section, code, name, order_num)
VALUES ('mc_s001_exam_cavoral', 's001', 'exam', 'cavidad_oral', 'Cavidad Oral', 6);

-- Y actualizar app/modules/consultation/exam.js para incluir la nueva pestaña.

3 Columnas legacy_id + legacy_source para trazabilidad

Para saber qué viene de dónde y poder rollback selectivo. Aplicar a las 3 tablas que reciben mucha data migrada.

ALTER TABLE patient       ADD COLUMN legacy_source TEXT;  -- 'otorrino_arteaga'
ALTER TABLE patient       ADD COLUMN legacy_id     TEXT;  -- id_paciente original
ALTER TABLE consultation  ADD COLUMN legacy_source TEXT;
ALTER TABLE consultation  ADD COLUMN legacy_id     TEXT;  -- "id_pac:N_consulta"
ALTER TABLE planner       ADD COLUMN legacy_source TEXT;
ALTER TABLE planner       ADD COLUMN legacy_id     TEXT;

4 Poblar catálogos del tenant del Dr.

Las tablas ya existen en CIMA. Solo insertamos data del Dr. bajo su tenant_id para que use SUS catálogos al consultar.

-- model_chip ← motivos_consulta (1067 motivos)
-- diagnosis ← diagnosticos (1291 dx)
-- medication + medication_dosage ← vademecum (823 meds)
-- study_type + study_option ← radiologias (85) + examenes (58)
-- service ← motivo_factura (33) + intervension (5)

-- Total filas a insertar en catálogos: ~3,400
-- Tamaño D1 esperado: insignificante (D1 free tier soporta 5GB)

✅ Tamaño total de los cambios

1 tabla nueva · 1 columna nueva en patient · 6 columnas legacy_* en 3 tablas · ~3,400 filas de catálogos

Ningún cambio rompe código existente. Todos son aditivos. Tiempo estimado de implementación: 1 sesión de 2-3 horas incluyendo testing.

🎯 Conclusión y Recomendación

Síntesis de todo el análisis. Para decidir cuándo, cómo y si proceder.

📋 Mi recomendación

Sí extender CIMA y migrar todo. La cobertura del schema actual es del 95%, los 4 cambios propuestos son aditivos (nada se rompe), y el momento es ideal (poca data viva en CIMA).

Orden propuesto:

  1. Backup D1 completo antes de tocar nada (5 min)
  2. Aplicar los 4 cambios al schema CIMA via wrangler d1 execute (30 min)
  3. Fase 1: Migrar 7,804 pacientes + 7,802 historias (30 min)
  4. Validar en la SPA con el Dr. — ver pacientes, abrir fichas (1 sesión con él)
  5. Fase 2: Cargar catálogos del tenant (motivos, dx, meds, estudios — 30 min)
  6. Fase 3: Migrar 15,246 citas + montos (45 min)
  7. Fase 4: Migrar 16,494 consultas a consultation_* (2-3 horas — el grande)
  8. Fase 5: Generar 4,380 PDFs de informes + subir a R2 (1-2 horas)
  9. Fase 6 (opcional): Si se accede al PC viejo, subir imágenes endoscópicas
  10. Sincronizar los ~40 pacientes faltantes del último mes y medio (manual o nuevo dump)
✅ Ventajas: 0% pérdida de data, cliente real productivo en CIMA, caso piloto validado, catálogos enriquecidos, features financieras activadas con data histórica.
⚠️ Riesgos: volumen 4000× mayor → testear performance D1, R2 costs por PDFs (calcular antes), curva del Dr. al cambiar sistema. Mitigables con fases.

⏱️ Tiempo total estimado

~10h

divididas en 6 fases, con validación entre cada una.

💰 Costo Cloudflare extra

< $2/mes

7,804 pacientes + 4,380 PDFs cabe holgado en planes Paid existentes.

📉 Riesgo

BAJO

cambios aditivos, backup previo, fases con verificación. La data original sigue intacta en el .db.

🎬 Próximo paso sugerido

Cuando me digas "Adelante", ejecuto en orden:

  1. Crear el script de migración del schema CIMA (4 cambios) — primero genero el SQL, lo revisas, luego ejecuto contra D1 remoto.
  2. Verificar con consultas que el schema queda como esperamos.
  3. Ejecutar Fase 1 (pacientes) y parar para validar contigo en la SPA.

Mientras tanto la data del Dr. sigue en D:\AI\cima_recover\arteaga\ y CIMA producción no se toca.

← Cueva Cap 2/3