Uma prática de ortopedia de médio porte no Sudeste chegou até nós com um problema que é dolorosamente comum na área de saúde: seu site WordPress era lento, o processo de admissão de pacientes era um pesadelo de downloads de PDF e devoluções por fax, e seu oficial de conformidade de TI estava perdendo o sono com exposição a HIPAA. Seis meses depois, eles tinham um frontend Next.js, backend Payload CMS, formulários de admissão de pacientes seguros para HIPAA, e pontuações Lighthouse que faziam os sites dos concorrentes parecerem estar rodando em conexões discadas. Aqui está exatamente como fizemos isso.

Índice

Healthcare Practice: WordPress to Next.js + Payload CMS Migration

O Ponto de Partida: Com O Que Estávamos Trabalhando

A prática—vamos chamá-la de Southeastern Ortho (NDA, você sabe como é)—estava rodando WordPress desde 2017. Sua configuração era típica de uma prática de saúde que cresceu organicamente sem muito acompanhamento técnico:

  • WordPress 6.2 com 34 plugins (11 dos quais não tinham sido atualizados há mais de um ano)
  • Hospedagem compartilhada em um plano que custava $29/mês
  • Contact Form 7 lidando com consultas de pacientes—sem encriptação, sem BAA com o provedor de hospedagem
  • Formulários de admissão em PDF que os pacientes precisavam baixar, imprimir, preencher manualmente e depois enviar por fax ou trazer para consultas
  • Tempos de carregamento de página em média 6.8 segundos em mobile
  • Pontuação Lighthouse mobile: 38

Aquela pontuação de Lighthouse não é um erro de digitação. Trinta e oito. O site tinha imagens hero não otimizadas (uma era um PNG de 4.2MB), CSS que bloqueava renderização de cinco plugins diferentes, e jQuery carregando três vezes por causa de conflitos entre plugins.

Mas o problema real não era performance. Era risco.

Seus formulários de contato estavam coletando nomes de pacientes, números de telefone e às vezes descrições de queixas médicas. Esses dados estavam fluindo através de um plugin de formulário não encriptado, armazenados em um banco de dados WordPress em hospedagem compartilhada, e com backup em um serviço sem Acordo de Associado de Negócios (BAA). Seu oficial de conformidade tinha sinalizado isto, e sua transportadora de seguro de responsabilidade civil profissional estava fazendo perguntas pertinentes.

O Briefing

A prática precisava de:

  1. Um site rápido e moderno que refletisse a qualidade de seu atendimento
  2. Formulários de admissão de pacientes seguros para HIPAA que substituíssem o processo em papel
  3. Um CMS que seu gerente de escritório pudesse atualizar sem chamar um desenvolvedor
  4. Melhor performance em SEO (eles estavam perdendo rankings de busca local para práticas mais novas)
  5. Tudo isto sem gastar uma fortuna—eles são uma prática médica, não uma startup de tecnologia

Por Que Next.js e Payload CMS

Avaliamos várias opções de arquitetura. Aqui está a comparação honesta que apresentamos ao cliente:

Opção Prós Contras Est. Custo
Reconstrução WordPress (novo tema + plugins) Familiar para a equipe, custo inicial mais baixo Mesmos riscos HIPAA, limitação de performance, dependência de plugins $15-25K
Webflow + formulários de terceiros Rápido de construir, boa performance Opções limitadas de conformidade HIPAA, custos contínuos por assento, bloqueio do fornecedor $20-30K
Next.js + Payload CMS Controle total, arquitetura segura para HIPAA, melhor performance Investimento inicial mais alto, requer gerenciamento de hospedagem $35-50K
Next.js + Sanity Excelente experiência de edição, bom ecossistema Preços do Sanity escalam com uso, preocupações com tratamento de PHI em CMS hospedado em nuvem $30-45K

Recomendamos Next.js com Payload CMS, e aqui está o porquê.

Next.js Era o Frontend Certo

Next.js 14 (este projeto começou no final de 2024, e desde então estamos rodando na versão 15) nos deu exatamente o que um site de saúde precisa:

  • Geração estática para páginas de conteúdo — biografias de médicos, descrições de serviços, informações de localização. Essas páginas raramente mudam, então as pré-renderizamos no momento da construção. Zero computação de servidor no momento da solicitação significa TTFB rápido.
  • Server Components para conteúdo dinâmico — disponibilidade de consultas, posts de blog e lógica de formulário de admissão se beneficiam da renderização do lado do servidor sem enviar JavaScript desnecessário para o cliente.
  • Otimização de imagens pronta para usar — next/image com conversão automática para WebP/AVIF substituiu aqueles PNGs de 4MB com imagens de tamanho apropriado e carregamento preguiçoso.
  • Middleware para cabeçalhos de segurança — usamos middleware do Next.js para definir cabeçalhos de CSP rigorosos, HSTS e outros cabeçalhos de segurança que auditores HIPAA adoram ver.

Se você está curioso sobre nossa abordagem, documentamos nossa capacidade de desenvolvimento Next.js em mais detalhes.

Payload CMS Era o Backend Certo

Escolhemos Payload CMS 3.0 em detrimento de outras opções headless por várias razões específicas da área de saúde:

Auto-hospedado por design. Payload roda em sua própria infraestrutura. Isto é inegociável para HIPAA. Quando você está tratando Informações Protegidas de Saúde (PHI), você precisa saber exatamente onde seus dados vivem, quem tem acesso e ser capaz de assinar um BAA com seu provedor de infraestrutura. Plataformas CMS hospedadas em nuvem como Contentful ou Sanity armazenam dados em seus servidores—e enquanto algumas oferecem conformidade HIPAA em níveis empresariais, o custo é tipicamente 3-5x o que você pagaria para auto-hospedar Payload em um provedor elegível para HIPAA.

Nativo em TypeScript. A configuração do Payload é apenas TypeScript. Isto significa que nossos modelos de conteúdo, respostas de API e tipos de frontend compartilham a mesma fonte de verdade. Quando o gerente de escritório adiciona um novo campo para "número de pré-autorização de seguro" ao formulário de admissão, seu frontend sabe sobre isto imediatamente através de tipos gerados.

Controle de acesso integrado. O controle de acesso em nível de campo do Payload significava que poderíamos criar funções onde a pessoa de marketing pudesse editar posts de blog e páginas de serviços, mas não pudesse tocar em dados de admissão de pacientes. O gerente de escritório poderia visualizar envios de admissão mas não poderia modificar a estrutura do formulário. Essa granularidade importa quando você está documentando controles de acesso para conformidade.

Rich text feito corretamente. Payload usa Lexical (anteriormente Slate) para rich text, e a experiência de edição é genuinamente boa. O gerente de escritório do nosso cliente, que usava WordPress há anos, estava confortável no painel admin do Payload dentro de uma única sessão de treinamento de 45 minutos.

Trabalhos regularmente com Payload e outras plataformas CMS headless—você pode ver mais sobre nossa abordagem de desenvolvimento de CMS headless.

Considerações HIPAA em uma Arquitetura Headless

Deixa eu ser claro sobre algo: nenhum stack de tecnologia é "compatível com HIPAA" por si próprio. A conformidade HIPAA é uma prática organizacional, não um recurso de software. O que um stack de tecnologia pode ser é "seguro para HIPAA"—significando que não introduz risco desnecessário e suporta os salvaguardas administrativos, físicos e técnicos que HIPAA requer.

Aqui está o que implementamos:

Infraestrutura

  • Hospedagem: AWS com um BAA assinado. Usamos ECS Fargate para o container Payload CMS e implantamos o frontend Next.js no Vercel (que não trata PHI—distinção importante).
  • Banco de dados: Amazon RDS PostgreSQL com encriptação em repouso (AES-256) e encriptação em trânsito (TLS 1.2+). Payload 3.0 suporta Postgres nativamente, o que foi uma grande razão para esperarmos pela v3.
  • Armazenamento de arquivos: S3 com encriptação no lado do servidor, políticas de bucket restringindo acesso, e versionamento habilitado para trilhas de auditoria.

Fluxo de Dados para Admissão de Pacientes

É aqui que a arquitetura fica interessante. O formulário de admissão de pacientes vive no frontend Next.js, mas nós nunca enviamos PHI através da infraestrutura do Vercel.

Navegador do Paciente → HTTPS → Rota de API (Next.js no Vercel) → NENHUM PHI armazenado aqui
                                             ↓
                                    AWS API Gateway (com WAF)
                                             ↓
                                    Função Lambda (valida, encripta)
                                             ↓
                                    API Payload CMS (em ECS Fargate)
                                             ↓
                                    RDS PostgreSQL (encriptado em repouso)

A rota de API Next.js atua como um proxy fino. Ela valida a estrutura da solicitação (token CSRF, rate limiting, validação básica de campo) mas não registra ou armazena nenhum PHI. O processamento real de dados acontece inteiramente dentro dos serviços elegíveis para HIPAA da AWS.

Detalhes de Encriptação

Implementamos encriptação em nível de campo para os dados mais sensíveis. Fragmentos de SSN do paciente (últimos 4 dígitos), IDs de seguro e descrições de queixas médicas são encriptados na camada de aplicação usando AES-256-GCM antes mesmo de chegar ao banco de dados. Isto significa que mesmo se alguém tivesse acesso ao banco de dados, veria blobs encriptados para campos sensíveis.

// Versão simplificada de nosso hook de encriptação em nível de campo no Payload
import { encrypt } from '../lib/crypto';

const PatientIntake: CollectionConfig = {
  slug: 'patient-intake',
  hooks: {
    beforeChange: [
      async ({ data }) => {
        if (data.ssnLastFour) {
          data.ssnLastFour = await encrypt(data.ssnLastFour);
        }
        if (data.medicalComplaint) {
          data.medicalComplaint = await encrypt(data.medicalComplaint);
        }
        return data;
      },
    ],
  },
  access: {
    read: ({ req: { user } }) => {
      return user?.role === 'office-admin' || user?.role === 'provider';
    },
    create: () => true, // Envio de formulário público
    update: ({ req: { user } }) => user?.role === 'office-admin',
    delete: () => false, // Política de retenção - sem deletions através do CMS
  },
  fields: [
    // ... definições de campo
  ],
};

Logging de Auditoria

Cada acesso aos dados de admissão de pacientes é registrado—quem visualizou, quando e de qual IP. Construímos um plugin customizado do Payload que escreve em uma tabela de log de auditoria separada. Esta tabela é append-only; nem mesmo usuários admin podem modificar ou deletar entradas. Durante a avaliação de risco HIPAA anual da prática, essa trilha de auditoria foi especificamente chamada de um ponto forte.

Healthcare Practice: WordPress to Next.js + Payload CMS Migration - architecture

O Redesign de Admissão de Pacientes

O processo antigo: Paciente baixa um PDF de 6 páginas, imprime, preenche com uma caneta (metade das vezes ilegível), traz para o escritório, e um membro da equipe o insere manualmente em seu sistema EHR. Tempo médio do download até inserção no EHR: 3-5 dias úteis.

O novo processo: Paciente recebe um link via SMS ou email 48 horas antes de sua consulta, completa o formulário multi-etapa em seu telefone em cerca de 8 minutos, e os dados estão disponíveis no sistema da prática antes de entrar pela porta.

Decisões de UX do Formulário

Dividimos o formulário de admissão em 7 etapas:

  1. Verificação de identidade (nome, data de nascimento, informações de contato)
  2. Informações de seguro (operadora, ID, número do grupo, upload de foto do cartão)
  3. Histórico médico (checklist de condições, histórico cirúrgico)
  4. Medicamentos atuais (com autocomplete de um banco de dados de formulário aberto)
  5. Motivo da visita (texto livre + diagrama corporal para localização de dor)
  6. Consentimento e acordos (captura de assinatura eletrônica)
  7. Revisão e envio

Alguns detalhes de UX que fizeram uma diferença real:

  • Indicador de progresso mostrando "Etapa 3 de 7" reduziu abandono em aproximadamente 40% em comparação com nosso protótipo inicial que mostrava todos os campos de uma vez. Fizemos A/B testing disto durante um lançamento suave.
  • Upload de foto de cartão de seguro com corte automático e preview. Pacientes fotografam a frente e o verso de seu cartão. Isto sozinho eliminou cerca de 60% da entrada de dados no balcão.
  • Autocomplete de medicamento usando a API RxNorm. Em vez de pacientes tentarem soletrar "hydroxychloroquine," eles digitam "hydro" e selecionam de uma lista filtrada. Isto reduziu significativamente erros de entrada de medicamento.
  • Persistência de sessão — se um paciente inicia o formulário e é interrompido, seu progresso é salvo (encriptado em sessionStorage, nunca localStorage) por 30 minutos. Eles podem retomar de onde pararam.
// Autocomplete de medicamento usando API RxNorm
const useMedicationSearch = (query: string) => {
  return useQuery({
    queryKey: ['medications', query],
    queryFn: async () => {
      if (query.length < 3) return [];
      const res = await fetch(
        `/api/medications/search?q=${encodeURIComponent(query)}`
      );
      return res.json();
    },
    staleTime: 1000 * 60 * 5, // Cache por 5 minutos
    enabled: query.length >= 3,
  });
};

O endpoint de busca de medicamento do lado do servidor consulta RxNorm através do nosso backend AWS, mantendo a chamada de API externa longe do cliente e permitindo que armazenemos em cache os resultados.

Resultados de Performance e Pontuações Lighthouse

Aqui está o antes e depois:

Métrica WordPress (Antes) Next.js + Payload (Depois) Melhoria
Lighthouse Mobile 38 94 +147%
Lighthouse Desktop 61 99 +62%
First Contentful Paint (Mobile) 4.2s 0.8s -81%
Largest Contentful Paint (Mobile) 8.1s 1.4s -83%
Total Blocking Time 1,840ms 45ms -98%
Cumulative Layout Shift 0.34 0.01 -97%
Time to Interactive 9.3s 1.2s -87%
Page Weight (Homepage) 4.8MB 340KB -93%
Core Web Vitals Pass Não Sim (todos verde) —

A pontuação Lighthouse mobile de 94 (não 100, e vou explicar por quê em um momento) foi medida na página de admissão de pacientes, que é a página mais pesada em JavaScript no site. Páginas de conteúdo como homepage e páginas de serviços consistentemente pontuam 98-100 em mobile e desktop.

Por que não um perfeito 100 em mobile? Duas razões:

  1. O widget de autocomplete de medicamento requer JavaScript do lado do cliente que adiciona cerca de 12KB gzipped à página de formulário de admissão.
  2. Usamos reCAPTCHA v3 no formulário de admissão como uma camada de prevenção de bots, e o script do reCAPTCHA do Google não é exatamente leve. Carregamos ele com preguiça, mas ainda custa alguns pontos.

Consideramos remover reCAPTCHA para atingir 100, mas o benefício de segurança supera a métrica de vaidade. Um formulário de admissão de saúde sem proteção contra bots está pedindo envios de spam misturados com dados de pacientes reais.

Estratégia de Migração: Zero Downtime, Zero Rankings Perdidos

Migrar um site de prática de saúde é estressante porque downtime literalmente significa perder consultas de pacientes. Aqui está como lidamos com isto:

Migração de Conteúdo

Escrevemos um script de migração que puxou conteúdo da API REST do WordPress e o transformou em documentos Payload CMS. O script tratou:

  • 47 páginas de serviços
  • 12 perfis de médico/provedor
  • 89 posts de blog (com re-hospedagem de imagens)
  • 6 páginas de localização
  • Todos os metadados de SEO (títulos, descrições, URLs canônicas)

Mapeamento de URL

Cada URL do WordPress foi mapeada para seu equivalente em Next.js. Mantemos a mesma estrutura de URL onde possível e configuramos redirecionamentos 301 em next.config.js para o punhado de URLs que mudaram:

// next.config.js
const redirects = async () => [
  {
    source: '/services/:slug',
    destination: '/orthopedic-services/:slug',
    permanent: true,
  },
  {
    source: '/team/:slug',
    destination: '/providers/:slug',
    permanent: true,
  },
  // ... 23 redirecionamentos mais
];

Cutover de DNS

Usamos uma estratégia de implantação blue-green. O novo site rodou em paralelo por duas semanas enquanto testávamos. No dia do cutover, atualizamos registros de DNS durante uma janela de manutenção de domingo à noite. Downtime visível total: cerca de 3 minutos (propagação de DNS foi rápida porque havíamos pré-diminuído TTLs para 60 segundos uma semana antes).

Resultados de SEO

Três meses pós-lançamento:

  • Tráfego orgânico aumentou 34%
  • Posição média para "orthopedic doctor near me" melhorou da posição 14 para posição 5
  • Taxa de clique do Google aumentou 28% (melhores Core Web Vitals = melhor experiência mobile SERP)
  • Zero erros 404 no Search Console para URLs previamente indexadas

Mergulho Profundo na Arquitetura Técnica

Para aqueles que querem o quadro completo:

┌─────────────────────────────────────────────┐
│                  Vercel                       │
│  ┌─────────────────────────────────────────┐ │
│  │  Next.js 15 App Router                  │ │
│  │  - Páginas estáticas (ISR, revalidação) │ │
│  │  - Server Components                    │ │
│  │  - Rotas de API (proxy apenas, PHI não) │ │
│  └─────────────────────────────────────────┘ │
└──────────────────┬──────────────────────────┘
                   │ HTTPS
┌──────────────────▼──────────────────────────┐
│              AWS (HIPAA BAA)                 │
│  ┌──────────────┐  ┌─────────────────────┐  │
│  │  API Gateway  │  │  CloudFront (assets)│  │
│  │  + WAF        │  └─────────────────────┘  │
│  └──────┬───────┘                            │
│         │                                    │
│  ┌──────▼───────┐  ┌─────────────────────┐  │
│  │  ECS Fargate  │──│  RDS PostgreSQL     │  │
│  │  (Payload 3)  │  │  (encriptado)       │  │
│  └──────┬───────┘  └─────────────────────┘  │
│         │                                    │
│  ┌──────▼───────┐  ┌─────────────────────┐  │
│  │  S3 (uploads) │  │  CloudWatch (logs)  │  │
│  │  (encriptado) │  │  (trilha de audit)  │  │
│  └──────────────┘  └─────────────────────┘  │
└─────────────────────────────────────────────┘

Custo de infraestrutura mensal: aproximadamente $180-220/mês na AWS (ECS Fargate é surpreendentemente acessível nesta escala) mais $20/mês para Vercel Pro. Compare isto com a hospedagem compartilhada de $29/mês na qual estavam antes—sim, é mais caro, mas estão recebendo infraestrutura elegível para HIPAA, escala automática e segurança genuína.

Lições Aprendidas

1. Comece conversas HIPAA cedo. Gastamos três semanas no planejamento de arquitetura antes de escrever uma única linha de código. Isto nos salvou de pelo menos dois redesigns potenciais.

2. Payload CMS v3 valeu a pena esperar. Começamos este projeto quando Payload 3.0 estava em beta. Havia arestas ásperas—documentação de migração estava incompleta, e alguns plugins ainda não tinham sido atualizados. Mas suporte nativo a Postgres e a UI de admin melhorada fizeram da escolha certa.

3. Não sobre-engenharia o formulário de admissão. Nosso protótipo inicial tinha lógica condicional com seis níveis de profundidade. O gerente de escritório olhou e disse, "Não podemos apenas fazer as perguntas em ordem?" Ela estava certa. Simplificamos, e taxas de conclusão subiram.

4. Clientes de saúde precisam de auxílio no treinamento de CMS. Fornecemos três sessões de treinamento em vez de nossa usual, mais vídeos Loom gravados para tarefas comuns. O investimento em treinamento se pagou no primeiro mês quando o gerente de escritório foi capaz de adicionar uma nova página de provedor sem abrir um ticket de suporte.

5. Orçamentos de performance são inegociáveis. Definimos um orçamento de performance de <400KB de peso de página e <100ms Total Blocking Time no início do projeto. Cada PR foi verificado contra este orçamento em CI. A única vez que tentamos adicionar uma biblioteca de ilustração animada, explodiu o orçamento, e detectamos antes de ser enviado.

Se você está considerando uma migração similar para um site de saúde ou de indústria regulada, gostaríamos de conversar sobre os detalhes específicos. Você pode entrar em contato conosco diretamente ou verificar nossa página de preços para faixas de projeto.

FAQ

O uso de Next.js e Payload CMS automaticamente torna um site compatível com HIPAA?

Não. Nenhum stack de tecnologia é inerentemente compatível com HIPAA. A conformidade HIPAA requer salvaguardas administrativos (políticas, treinamento, avaliações de risco), salvaguardas físicos (controles de acesso a instalações) e salvaguardas técnicos (encriptação, controles de acesso, logs de auditoria). O que Next.js e Payload CMS lhe dão é uma arquitetura flexível onde você pode implementar adequadamente os salvaguardas técnicos—especialmente a natureza auto-hospedada do Payload, que permite que você controle onde PHI vive.

Por que não apenas usar um serviço de formulário compatível com HIPAA como Jotform ou FormStack?

Você absolutamente pode, e para casos de uso mais simples, é uma escolha razoável. Avaliamos plano HIPAA do Jotform ($99/mês) e FormStack ($83/mês). O problema para este cliente era profundidade de integração—eles queriam que os dados de admissão fluissem para um fluxo de trabalho customizado que verificasse elegibilidade de seguro em tempo real e pré-populasse seu sistema EHR. Ferramentas de formulário off-the-shelf não conseguiam lidar com isto sem middleware significativo, ponto em qual você está construindo infraestrutura customizada de qualquer jeito.

Qual foi o custo total do projeto e cronograma?

O projeto chegou a aproximadamente $42,000 em 14 semanas. Isto incluiu descoberta e planejamento de arquitetura (3 semanas), design (2 semanas), desenvolvimento (7 semanas) e testing/migração (2 semanas). Hospedagem contínua e manutenção roda cerca de $250/mês incluindo custos de infraestrutura e uma pequena retainer de suporte.

Payload CMS consegue lidar com múltiplas localizações para um grupo de saúde?

Sim. Construímos uma coleção "Locations" no Payload com campos para endereço, horas, provedores, seguro aceito e conteúdo específico de localização. Cada localização recebe sua própria página gerada por Next.js com markup de dados estruturados (schema LocalBusiness) para SEO local. Adicionar uma nova localização é tão simples quanto criar uma nova entrada no painel admin do Payload.

Como você lida com retenção de dados de pacientes e requisitos de deletamento?

Implementamos políticas automatizadas de ciclo de vida de dados. Envios de formulário de admissão são retidos por 7 anos (combinando com o requisito de retenção de registros médicos do estado da prática), após o qual são automaticamente arquivados para S3 Glacier e eventualmente deletados. Pacientes também podem requisitar acesso de dados ou deletamento sob leis de privacidade estaduais—construímos um fluxo de trabalho de admin no Payload onde equipe pode processar essas requisições com trilha de auditoria completa.

O que acontece se o servidor Payload CMS cai?

O frontend Next.js serve páginas estaticamente geradas do CDN do Vercel, então o site principal fica de pé mesmo se o backend Payload está completamente offline. O formulário de admissão de pacientes não estaria disponível durante uma interrupção de backend, mas configuramos ECS com políticas de auto-restart, verificações de saúde a cada 30 segundos, e alarmes CloudWatch que alertam tanto nossa equipe quanto o contato de TI da prática. Em 6 meses de produção, tivemos zero downtime não planejado.

Esta arquitetura é exagerada para uma pequena prática com uma localização?

Depende do que você está fazendo com dados de pacientes. Se você apenas precisa de um site de brochura com número de telefone e endereço, WordPress com um bom tema está bem—você não precisa de nenhum disto. Mas no momento que você está coletando PHI através de seu website (formulários de admissão, questionários médicos, requisições de consulta com detalhes médicos), você precisa de infraestrutura que suporte controles de segurança adequados. A arquitetura que construímos escala bem para baixo—uma prática de uma localização custaria menos em infraestrutura por causa de tráfego menor.

Como a migração afetou rankings no Google?

Vimos uma breve (cerca de 10 dias) flutuação de ranking imediatamente após migração, o que é normal. Pela semana três, rankings tinham estabilizado e estavam tendendo para cima. Pelo mês três, tráfego orgânico era 34% maior e as palavras-chave primárias da prática tinham melhorado uma média de 4 posições. A melhoria de Core Web Vitals foi o maior fator—Google tinha estado penalizando seu site antigo pela pobre performance mobile em resultados de busca.