Migrar de un PACS dental local a la nube: un enfoque por fases con la API de CBCTHub

El PACS dental local que está en el rincón de tu sala de TI es más caro de lo que parece. La factura inicial fue chica comparada con lo que has gastado en reconstrucciones de RAID, contratos de soporte fuera de horario, rotaciones de cinta de backup y el día y medio que perdiste en 2023 cuando falló el aire acondicionado. Suma los costos blandos — los estudios que no logras compartir remotamente, el técnico que se pasa la mañana grabando CDs, los dentistas que migran calladitos a un competidor más rápido — y la cuenta de la nube se vuelve directa.

Este post es el playbook que entregamos a directores de TI de centros radiológicos que planifican una migración a la nube. Asume que hoy tienes un PACS funcionando (Carestream, Sectra, Romexis, MediaDent, build custom, da lo mismo) y quieres pasar a CBCTHub sin dejar al centro fuera de línea una semana.

El costo real de un PACS dental on-prem

Para un centro mediano con 50.000 estudios en archivo y 200 nuevos al día, un presupuesto anual típico se ve así:

• Hardware del servidor: entre USD 4.000 y USD 8.000 amortizados por año en un ciclo de 5 años.
• Almacenamiento y RAID: entre USD 3.000 y USD 10.000 al año en discos empresariales y reemplazos.
• Software y medios de backup: entre USD 2.000 y USD 5.000 al año, más el costo de mano de obra de verificar restores.
• UPS, aire y espacio en rack: entre USD 1.500 y USD 4.000 al año.
• Contrato de soporte TI: entre USD 6.000 y USD 15.000 al año por cobertura fuera de horario.
• Tiempo del equipo TI interno: entre 4 y 6 horas a la semana en parches, monitoreo y respuesta a incidentes.

Eso son USD 25.000 a USD 50.000 cada año, y no incluye el costo del downtime ni las derivaciones perdidas cuando el compartir remoto falla. Un PACS en la nube al mismo volumen cuesta una fracción de eso con facturación mensual predecible.

Señales de que es momento de migrar

• Tu arreglo de almacenamiento está al 80% de capacidad y la siguiente expansión requiere chasis nuevo.
• Tu estrategia de backup no se ha probado con un restore real en más de seis meses.
• La mitad de tus derivadores se queja de recibir los estudios remotamente.
• Tu equipo de TI no puede tomarse vacaciones reales sin cobertura de guardia.
• En los últimos 12 meses tuviste al menos un incidente donde los estudios estuvieron inaccesibles más de dos horas.

Si tres o más de esos resuenan, la nube ya no es el upgrade opcional — es la opción más barata.

El plan de migración en cuatro fases

Fase 1: Auditoría y preparación (semanas 1-2)

Antes de mover un solo byte, inventaría lo que tienes:

• Volumen: conteo total de estudios, tamaño total de almacenamiento, tasa de crecimiento mensual.
• Modalidades: qué mezcla de CBCT, panorámicas, intraorales, cefalometrías, STL.
• Política de retención: qué necesitas conservar legalmente, por cuánto tiempo, y qué se puede archivar a almacenamiento frío o eliminar.
• Dependencias de derivadores: qué sistemas externos hoy leen de tu PACS. Actualizar esos flujos es parte de la migración.
• Preparación del equipo: quién corre el cutover, quién responde al soporte técnico durante el cambio, quién entrena a la recepción en el flujo nuevo.

Esta fase termina con un runbook escrito, un presupuesto objetivo de almacenamiento y un líder interno asignado.

Fase 2: Bulk import vía API (semanas 3-6)

El backfill es la parte más pesada. El endpoint /v1/exams de CBCTHub con upload_mode: "zip" y el follow-up /process-zip está construido para esto — envías un ZIP por estudio y el servidor lo descomprime, sin el overhead de PUTs uno por archivo.

# Pseudocódigo del agente de backfill
for study_folder in os.listdir(PACS_ROOT):
    if already_imported(study_folder):
        continue

    # Comprime la carpeta DICOM
    zip_path = zip_study(study_folder)

    # 1. Crear el examen
    res = requests.post(
        'https://cbcthub.com/api/v1/exams',
        headers={'Authorization': f'Bearer {KEY}'},
        json={
            'name': read_patient_label(study_folder),
            'patient_name': read_patient_name(study_folder),
            'birth_date': read_birth_date(study_folder),
            'exam_type': detect_modality(study_folder),
            'expiration_days': None,  # archivar para siempre
            'upload_mode': 'zip',
            'zip_size_bytes': os.path.getsize(zip_path),
        },
    ).json()

    # 2. Sube el ZIP
    with open(zip_path, 'rb') as f:
        requests.put(res['upload_urls'][0]['url'], data=f)

    # 3. Dispara la descompresión server-side
    requests.post(
        f"https://cbcthub.com/api/v1/exams/{res['exam_id']}/process-zip",
        headers={'Authorization': f'Bearer {KEY}'},
    )

    mark_imported(study_folder)
    os.remove(zip_path)

Corre el backfill en orden cronológico, del más antiguo al más nuevo. Así, si tienes que pausar y reanudar, siempre sabes exactamente dónde te quedaste. Limita la tasa a lo que tu ancho de banda saliente soporte cómodamente en horario de trabajo, o córrelo de noche a velocidad completa.

Fase 3: Dual-run (semanas 7-10)

Durante 30 a 60 días, cada estudio nuevo se escribe tanto al PACS local como a CBCTHub. Esta es la red de seguridad — si algo está mal en el flujo de la nube, lo detectas sin perder datos. Usa esta fase para:

• Entrenar a cada técnico en el nuevo flujo de compartir.
• Migrar los marcadores y las integraciones PMS de los derivadores a las URLs de la nube.
• Verificar que los audit logs, la política de retención y los controles de acceso coincidan con lo que daba el PACS local.
• Hacer pruebas de carga en un día pico para confirmar que el pipeline de subida no se encola bajo presión.

Fase 4: Cutover (semana 11)

Cuando el dual-run sea aburrido durante dos semanas consecutivas, corta las escrituras al PACS local. Mantén el equipo accesible como archivo de solo lectura durante 12 meses, por si acaso, pero deja de agregarle datos. Desconecta la rotación de cintas de backup, cancela el contrato de soporte fuera de horario y recupera las horas de TI para trabajo de mayor valor.

Calculadora de costo aproximada

Para el mismo centro mediano (50.000 estudios en archivo, 200 nuevos al día):

• TCO on-prem a 5 años: entre USD 150.000 y USD 250.000 (hardware + storage + TI + downtime).
• TCO en la nube con CBCTHub a 5 años: aproximadamente un tercio de eso, dependiendo del plan de storage y volumen de API.
• Esfuerzo de migración inicial: 4-6 semanas de trabajo de personal más los costos de API del backfill.

La mayoría de los centros con los que trabajamos recupera la inversión en los meses 6-9 y queda en positivo cada trimestre después.

Riesgos comunes y cómo manejarlos

• DICOM corrupto en el archivo legacy. Construye un validador dentro del agente de backfill. Registra cada estudio fallido en una cola aparte y revísala semanalmente — un par por ciento de un archivo viejo suele tener problemas que eran invisibles mientras el PACS solo guardaba bytes.
• Naming inconsistente de pacientes. Los archivos viejos mezclan mayúsculas, minúsculas, acentos y typos en fechas de nacimiento. Pasa una normalización durante el backfill (usando el DICOM SpecificCharacterSet para nombres con caracteres no ASCII) para que los dentistas puedan buscar en el sistema nuevo.
• Downtime en el cutover. La fase de dual-run hace que el downtime sea estructuralmente cero. Si la saltas, planea una ventana de mantenimiento.
• Pánico del derivador. Envía una actualización de una página antes del cutover. La fuente más grande de tickets post-migración son dentistas que no sabían que el link cambió.
• Revisión de cumplimiento. Consigue tu BAA, las exportaciones de audit log y el proceso de notificación de brecha aprobados por el área legal antes de la fase 3, no después.

Conclusión

La migración a la nube intimida desde afuera, pero un plan por fases — auditoría, backfill, dual-run, cutover — la convierte en una serie de sprints rutinarios. El estado final es menor costo, sin guardias de almacenamiento y una experiencia para el derivador que tus competidores no pueden igualar sin su propio proyecto multianual. La parte dura no es la tecnología — es decidir empezar.

Habla con un especialista en migración · Lee la documentación de la API