Migrando de um PACS odontológico local para a nuvem: uma abordagem em fases com a API do CBCTHub

O PACS odontológico local que está no canto da sua sala de TI é mais caro do que parece. A nota fiscal inicial foi pequena comparada com o que você já gastou em reconstruções de RAID, contratos de suporte fora do horário, rotações de fita de backup e aquele dia e meio que você perdeu em 2023 quando o ar-condicionado falhou. Some os custos indiretos — os estudos que você não consegue compartilhar remotamente, o técnico que passa a manhã gravando CDs, os dentistas que migram quietinhos para um concorrente mais rápido — e a conta da nuvem fica direta.

Este post é o playbook que entregamos a diretores de TI de centros radiológicos que planejam uma migração para a nuvem. Assume que você tem um PACS funcionando hoje (Carestream, Sectra, Romexis, MediaDent, build sob medida, tanto faz) e quer ir para o CBCTHub sem tirar o centro do ar por uma semana.

O custo real de um PACS odontológico on-prem

Para um centro de porte médio com 50.000 estudos no arquivo e 200 novos por dia, um orçamento anual típico fica assim:

• Hardware do servidor: entre USD 4.000 e USD 8.000 amortizados por ano em ciclo de 5 anos.
• Armazenamento e RAID: entre USD 3.000 e USD 10.000 por ano em discos enterprise e substituições.
• Software e mídia de backup: entre USD 2.000 e USD 5.000 por ano, mais a mão de obra para validar restores.
• UPS, ar-condicionado e espaço em rack: entre USD 1.500 e USD 4.000 por ano.
• Contrato de suporte de TI: entre USD 6.000 e USD 15.000 por ano para cobertura fora do horário.
• Tempo de TI interno: facilmente 4-6 horas por semana com patches, monitoramento e resposta a incidentes.

É um item de orçamento de USD 25.000 a USD 50.000 todo ano, e não inclui o custo de downtime nem as indicações perdidas quando o compartilhamento remoto falha. Um PACS em nuvem no mesmo volume custa uma fração disso com faturamento mensal previsível.

Sinais de que é hora de migrar

• Seu array de armazenamento está em mais de 80% e a próxima expansão exige chassi novo.
• Sua estratégia de backup não foi testada com um restore real nos últimos seis meses.
• Metade dos seus solicitantes reclama de receber estudos remotamente.
• Sua equipe de TI não consegue tirar férias de verdade sem cobertura de plantão.
• Nos últimos 12 meses houve pelo menos um incidente em que os estudos ficaram inacessíveis por mais de duas horas.

Se três ou mais desses te pegarem, a nuvem deixou de ser o upgrade opcional — passou a ser a opção mais barata.

O plano de migração em quatro fases

Fase 1: Auditoria e preparação (semanas 1-2)

Antes de mover um único byte, faça o inventário:

• Volume: contagem total de estudos, tamanho total em armazenamento, taxa de crescimento mensal.
• Modalidades: qual mix de CBCT, panorâmicas, intraorais, cefalometrias, STL.
• Política de retenção: o que você precisa manter por lei, por quanto tempo, e o que pode ir para storage frio ou ser descartado.
• Dependências de solicitantes: quais sistemas externos hoje leem do seu PACS. Atualizar esses fluxos faz parte da migração.
• Prontidão do time: quem conduz o cutover, quem responde ao suporte técnico durante a transição, quem treina a recepção no fluxo novo.

Esta fase termina com um runbook escrito, um orçamento alvo de armazenamento e um líder interno designado.

Fase 2: Bulk import via API (semanas 3-6)

O backfill é a parte mais pesada. O endpoint /v1/exams do CBCTHub com upload_mode: "zip" e o follow-up /process-zip foi feito para isso — você envia um ZIP por estudo e o servidor descompacta, sem overhead de PUTs arquivo a arquivo.

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

    # Compacta a pasta DICOM
    zip_path = zip_study(study_folder)

    # 1. Criar o exame
    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,  # arquivar para sempre
            'upload_mode': 'zip',
            'zip_size_bytes': os.path.getsize(zip_path),
        },
    ).json()

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

    # 3. Dispara a descompactação no servidor
    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)

Rode o backfill em ordem cronológica, do mais antigo para o mais novo. Assim, se precisar pausar e retomar, você sabe exatamente onde parou. Limite a taxa ao que sua banda de saída aguenta confortavelmente no horário de trabalho, ou rode à noite na velocidade total.

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

Por 30 a 60 dias, todo estudo novo é gravado tanto no PACS local quanto no CBCTHub. É a rede de segurança — se algo estiver errado no fluxo da nuvem, você detecta sem perder dados. Use esta fase para:

• Treinar todo técnico no novo fluxo de compartilhamento.
• Migrar bookmarks e integrações de PMS dos solicitantes para as URLs da nuvem.
• Verificar que audit logs, política de retenção e controles de acesso batem com o que o PACS local entregava.
• Fazer testes de carga em um dia de pico para confirmar que o pipeline de upload não enfileira sob pressão.

Fase 4: Cutover (semana 11)

Quando o dual-run ficar entediante por duas semanas seguidas, corte as escritas para o PACS local. Mantenha o equipamento acessível como arquivo somente leitura por 12 meses, por garantia, mas pare de gravar nele. Desconecte a rotação de fita, cancele o contrato de suporte fora do horário e devolva as horas de TI para trabalho de maior valor.

Calculadora de custo aproximada

Para o mesmo centro de porte médio (50.000 estudos no arquivo, 200 novos por dia):

• TCO on-prem em 5 anos: entre USD 150.000 e USD 250.000 (hardware + storage + TI + downtime).
• TCO em nuvem com CBCTHub em 5 anos: cerca de um terço disso, dependendo do plano de storage e volume de API.
• Esforço único de migração: 4-6 semanas de tempo de equipe mais o custo de API do próprio backfill.

A maioria dos centros com os quais trabalhamos recupera o investimento da migração nos meses 6-9 e fica positivo todo trimestre depois.

Riscos comuns e como lidar

• DICOM corrompido no arquivo legado. Coloque um validador no agente de backfill. Registre cada estudo com falha em uma fila à parte e revise semanalmente — alguns por cento de um arquivo antigo costumam ter problemas que ficavam invisíveis enquanto o PACS só guardava os bytes.
• Nomes de paciente inconsistentes. Arquivos antigos misturam maiúsculas, minúsculas, acentos e erros em datas de nascimento. Faça uma passada de normalização durante o backfill (usando o DICOM SpecificCharacterSet para nomes com caracteres não ASCII) para que dentistas consigam de fato pesquisar no sistema novo.
• Downtime no cutover. A fase de dual-run faz o downtime ser estruturalmente zero. Se pular, planeje uma janela de manutenção.
• Pânico do solicitante. Mande uma atualização de uma página antes do cutover. A maior origem de tickets pós-migração são dentistas que não sabiam que o link mudou.
• Revisão de compliance. Tenha BAA, exportações de audit log e processo de notificação de brecha aprovados pelo jurídico antes da fase 3, não depois.

Conclusão

Migração para nuvem intimida de fora, mas um plano em fases — auditoria, backfill, dual-run, cutover — transforma tudo em uma série de sprints rotineiros. O estado final é menor custo, sem plantão para storage e uma experiência ao solicitante que seus concorrentes não conseguem igualar sem um projeto multi-anual próprio. A parte difícil não é a tecnologia — é decidir começar.

Fale com um especialista em migração · Leia a documentação da API