Um cliente me ligou numa quinta-feira à tarde no final de 2023 -- fintech que virou healthtech, eles tinham acabado de contratar um consultor de compliance que olhou para o codebase Next.js deles e devolveu uma lista de três páginas de problemas. "A gente pensava que colocar na AWS era suficiente," disse o founder. Ele acreditava genuinamente nisso. E honestamente? Eu tinha ouvido essa mesma frase de provavelmente seis times diferentes antes dele.
Compliance HIPAA é uma daquelas áreas onde todo mundo acha que entende a superfície -- assina um BAA, escolhe um provedor de nuvem compliant, pronto. Mas a HIPAA Security Rule não se importa com a página de marketing do seu provedor de hospedagem. Ela se importa com como sua aplicação manipula, armazena, transmite e faz auditoria de Protected Health Information (PHI). Next.js -- como framework -- não é nem compliant nem não-compliant de fábrica. O que você constrói em cima disso é tudo.thinks they understand the surface -- sign a BAA, pick a compliant cloud provider, done. But the HIPAA Security Rule doesn't care about your hosting provider's marketing page. It cares about how your application handles, stores, transmits, and audits Protected Health Information (PHI). Next.js -- as a framework -- is neither compliant nor non-compliant out of the box. What you build on top of it is everything.
Então deixe-me percorrer com você o que realmente importa em 2026, baseado em arquiteturas reais que construí e erros reais que vi times cometendo.
---
Os três caminhos HIPAA reais em 2026 -- escolha o seu antes de escolher uma stack
Se você está construindo qualquer coisa com formato de saúde este ano, você tem três caminhos que realmente se compilam para um Business Associate Agreement assinado e uma trilha de auditoria defensável. A maioria dos blogs de engenharia cobre apenas o primeiro. Os outros dois são mais baratos, mais rápidos, e a resposta correta mais frequentemente do que a multidão Next.js admite.
- Path 1 -- Next.js + Vercel BAA: a chamada certa quando seu produto tem dashboards autenticados, workflows customizados, dados em tempo real, features de IA, ou qualquer coisa além de conteúdo estático. A Vercel finalmente abriu BAAs HIPAA para times Pro em 2025 por um add-on de $350/mês, então você não precisa mais de um contrato Enterprise para fazer ship.Vercel BAA: the right call when your product has authenticated dashboards, custom workflows, real-time data, AI features, or anything past static content. Vercel finally opened HIPAA BAAs to Pro teams in 2025 at a $350/month add-on, so you no longer need an Enterprise contract to ship.
- Path 2 -- WordPress em um host HIPAA-eligible: a chamada certa quando seu site de healthcare é um site de marketing mais formulários de intake mais um time editorial que já conhece wp-admin. Atlantic.Net assina um BAA a partir de $350/mês, Liquid Web a partir de $600/mês, HIPAA Vault para fully managed. O caminho que a maioria dos sites de clínicas de healthcare deveria tomar.WordPress on a HIPAA-eligible host: the right call when your healthcare site is a marketing site plus intake forms plus an editorial team that already knows wp-admin. Atlantic.Net signs a BAA from $350/month, Liquid Web from $600/month, HIPAA Vault for fully managed. The path most healthcare clinic sites should take.
- Path 3 -- JotForm Gold a $99/mês: a chamada certa quando o único PHI que você manipula é de formulários -- intake de pacientes, check-in de sintomas, feedback. JotForm inclui HIPAA no plano Gold sem add-on. PHI nunca toca sua infraestrutura. Embed o formulário, assina o BAA, faz ship numa tarde.
O resto do post cobre as decisões de arquitetura para o caminho 1 em profundidade, mas a seção Vercel BAA, a seção WordPress, e a seção JotForm explicam quando cada caminho é o correto. Se você está prestes a ler 2.000 palavras sobre logging de auditoria Next.js quando JotForm teria resolvido seu escopo atual em uma hora, os próximos três minutos são os mais valiosos nesta página.
O que "Next.js Compatível com HIPAA" Realmente Significa
As pessoas confundem conformidade de infraestrutura com conformidade de aplicação. Não são a mesma coisa.
Seu provedor de nuvem (AWS, GCP, Azure -- escolha um) pode assinar um Business Associate Agreement com você. Esse é um documento legal que estabelece que eles vão proteger PHI na infraestrutura deles de acordo com as regras HIPAA. AWS tem uma lista de serviços HIPAA-eligible que vale a pena bookmarcar. Mas um BAA da AWS não significa que seu app Next.js é compliant. Nem de longe.HIPAA-eligible services list that's worth bookmarking. But a BAA from AWS doesn't mean your Next.js app is compliant. Not even close.
A camada de aplicação é responsabilidade sua. Sempre. O framework é apenas um veículo.your responsibility. Always. The framework is just a vehicle.
Aqui está a questão -- Next.js 14+ (e dentro de 2026, o App Router está totalmente maduro) te dá server components, server actions, middleware, e edge functions. Cada um desses tem implicações diferentes no tratamento de PHI. Um server component que faz query num banco de dados de pacientes e passa dados para um client component -- onde esse dado fica? Por quanto tempo? Ele acaba no cache do navegador? Essas não são preocupações hipotéticas.
---
O Problema da Superfície de PHI
Antes de escrever uma linha de código, faço cada cliente de health-tech fazer um exercício: mapear cada lugar onde PHI poderia possivelmente tocar a aplicação. Não onde deveria tocar. Onde poderia.should touch it. Where it could.
Isso inclui:
- URL parameters (já vi IDs de pacientes em query strings -- não faça isso)
- localStorage e sessionStorage do navegador
localStorageandsessionStorage - Gerenciamento de estado client-side (stores Zustand, Redux, até mesmo React context)
- Next.js fetch cache e a camada Data Cache
- Output de log do console.log durante desenvolvimento que vaza para produção
console.logduring development that sneaks into production - Ferramentas de rastreamento de erros como Sentry (mais sobre isso em breve)
- Pipelines de analytics -- GA4, Segment, Amplitude
Os dois últimos pegam mais equipes do que quase qualquer outra coisa. No início de 2024, a Seahawk tinha um cliente de telemedicina que tinha configurado o Sentry para monitoramento de erros. Movimento padrão. Exceto que seus error boundaries estavam capturando o objeto completo de props no crash -- o que incluía detalhes de consultas e flags de saúde do usuário. O Sentry não estava coberto sob seu BAA. Esse é um vazamento esperando para acontecer.
Sanitizando Seu Rastreamento de Erros
Se você está usando Sentry com código adjacente a PHI, use o hook beforeSend para limpar campos sensíveis antes deles saírem do navegador. Sem questão. Algo assim é inegociável:beforeSend hook to scrub sensitive fields before they leave the browser. Full stop. Something like this is non-negotiable:
``beforeSend(event) { if (event.user) { delete event.user.email; delete event.user.ip_address; } return event; }``beforeSend(event) { if (event.user) { delete event.user.email; delete event.user.ip_address; } return event; }``
O Sentry tem um caminho de conformidade com HIPAA -- eles vão assinar um BAA -- mas você ainda precisa configurar quais dados você envia para eles. O BAA não sanitiza seus payloads automaticamente.HIPAA compliance path -- they'll sign a BAA -- but you still need to configure what data you send them. The BAA doesn't sanitise your payloads automatically.
---
Autenticação e Gerenciamento de Sessão
É aqui que vejo mais atalhos. Times pegam NextAuth.js (agora Auth.js), conectam um provedor e acham que terminaram. Auth.js é uma biblioteca sólida. Mas os padrões não são padrões HIPAA.
Alguns detalhes específicos:
- Armazenamento de token de sessão -- Auth.js usa por padrão uma sessão baseada em cookie, o que é aceitável, mas você precisa definir explicitamente httpOnly, secure e sameSite: 'strict'. Não assuma. -- Auth.js defaults to a cookie-based session, which is fine, but you need
httpOnly,secure, andsameSite: 'strict'explicitly set. Don't assume. - Expiração de sessão -- O padrão Automatic Logoff do HIPAA (§164.312(a)(2)(iii)) exige que as sessões terminem após um período definido de inatividade. O número não é prescrito, mas 15 minutos é o padrão da indústria para aplicações clínicas. Configure um timer de inatividade em seu layout. Normalmente construo isso como um hook customizado que dispara uma server action para invalidar a sessão. -- HIPAA's Automatic Logoff standard (§164.312(a)(2)(iii)) requires that sessions terminate after a defined period of inactivity. The number isn't prescribed, but 15 minutes is the industry standard for clinical applications. Wire up an inactivity timer in your layout. I usually build this as a custom hook that fires a server action to invalidate the session.
- MFA -- Não é estritamente obrigatório pelo texto do HIPAA, mas tente explicar a um auditor da OCR por que você não implementou após um vazamento. Use TOTP via algo como otplib ou confie em um provedor de identidade como Auth0 ou Clerk que tem MFA integrado e vai assinar um BAA. -- Not strictly mandated by HIPAA's text, but try explaining to an OCR auditor why you didn't implement it after a breach. Use TOTP via something like
otplibor lean on an identity provider like Auth0 or Clerk that has MFA baked in and will sign a BAA. - Log de auditoria de eventos de autenticação -- Cada login, login falhado e logout precisa ser registrado com um timestamp e identificador de usuário. Cada um deles. -- Every login, failed login, and logout needs to be logged with a timestamp and user identifier. Every single one.
Não vou dizer que Auth.js é inadequado para este caso de uso -- já o enviei em produção em projetos HIPAA. Mas você tem que adicionar propositalmente os requisitos de conformidade por cima.
---
Dados em Trânsito e em Repouso
Trânsito é a parte fácil. TLS 1.2 no mínimo, TLS 1.3 preferido, em todo lugar. Não apenas seu domínio principal -- suas rotas de API, suas edge functions, qualquer webhook. Se você está no Vercel, isso é tratado. Se você está auto-hospedando em EC2 ou executando Next.js em um container Docker atrás de um reverse proxy NGINX, você precisa configurar isso você mesmo. Revisei codebases onde as chamadas internas de serviço para serviço ainda estavam em HTTP porque "está dentro da VPC." Essa não é uma posição aceitável.
Em repouso é mais difícil. Alguns detalhes que importam:
- Criptografia de banco de dados -- AWS RDS com criptografia habilitada (usa AES-256 via AWS KMS). Isso é uma caixa de seleção, mas você precisa realmente marcá-la e documentá-la. -- AWS RDS with encryption enabled (uses AES-256 via AWS KMS). This is a checkbox, but you need to actually check it and document it.
- Criptografia em nível de campo para dados altamente sensíveis -- Para coisas como SSNs, diagnósticos ou listas de medicamentos, frequentemente adiciono uma segunda camada de criptografia em nível de aplicação usando uma biblioteca como @aws-sdk/client-kms para envolver/desembrulhar chaves. O overhead é real, mas também é o risco. -- For things like SSNs, diagnoses, or medication lists, I often add a second layer of encryption at the application level using a library like
@aws-sdk/client-kmsto wrap/unwrap keys. Overhead is real, but so is the risk. - Next.js Data Cache -- Isso pega muita gente. O App Router faz cache das respostas de fetch por padrão. Se você está buscando dados de pacientes em um server component com fetch(), você precisa de { cache: 'no-store' } a menos que você esteja deliberadamente gerenciando revalidação. Uma resposta em cache contendo PHI sentada na memória ou filesystem do servidor é um problema. -- This one catches people out. The App Router caches fetch responses by default. If you're fetching patient data in a server component with
fetch(), you need{ cache: 'no-store' }unless you're very deliberately managing revalidation. A cached response containing PHI sitting in the server's memory or filesystem is a problem. - Backups -- Criptografados. Testados. Documentados. Óbvio, mas já auditei sistemas onde os backups existiam mas nunca tinham sido restaurados. -- Encrypted. Tested. Documented. Obvious, but I've audited systems where the backups existed but had never been restored once.
---
Audit Logging: A Parte que Ninguém Quer Construir
Aqui está algo que vou dizer claramente -- audit logging é a coisa mais chata e mais importante que você vai construir em um app de health-tech. Todo acesso a PHI precisa ser registrado. Não só escritas. Leituras também.
O padrão HIPAA Audit Controls (§164.312(b)) exige "mecanismos de hardware, software e/ou procedimentos que registrem e examinem a atividade em sistemas de informação que contenham ou usem ePHI". Na prática, significa isto: você precisa de um log append-only de quem acessou qual dado de paciente, quando e de onde.HIPAA Audit Controls standard(§164.312(b)) requires "hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI." What that means practically: you need an append-only log of who accessed what patient data, when, and from where.
Eu construo isso como uma camada middleware no Next.js. Para projetos App Router, eu intercepto em middleware.ts para logging em nível de rota e adiciono um wrapper de serviço fino ao redor de qualquer função de query de banco de dados que toca tabelas de PHI. Os registros de log são escritos em uma tabela de banco de dados separada (ou um serviço como AWS CloudTrail se você quer garantias de imutabilidade) -- nunca a mesma tabela que o próprio PHI.middleware.ts for route-level logging and add a thin service wrapper around any database query function that touches PHI tables. The log records get written to a separate database table (or a service like AWS CloudTrail if you want immutability guarantees) -- never the same table as the PHI itself.
Um registro de audit mínimo se parece com isto:
user_id -- quem-- whoresource_type+resource_id -- o quê+resource_id-- whataction -- read / write / delete-- read / write / deleteip_address -- onde (anonimizado na camada de rede é aceitável)-- where (anonymised at the network layer is fine)timestamp (UTC, sempre UTC)(UTC, always UTC)request_id -- para correlacionar com seus logs de aplicação-- to correlate with your application logs
Não deixe desenvolvedores adicionarem console.log(patientRecord) e chamarem isso de trilha de auditoria. Já vi isso acontecer. Não é.console.log(patientRecord)and call it an audit trail. I've seen this. It's not.
---
Escolhendo Sua Stack de Infraestrutura
A resposta honesta é que em 2026 há um punhado de stacks que eu realmente recomendaria para uma aplicação Next.js em produção compatível com HIPAA.
Vercel + PlanetScale/Neon + Clerk é a stack de developer experience. Vercel vai assinar um BAA (plano enterprise -- sim, custa dinheiro). PlanetScale e Neon ambos têm tiers HIPAA-eligible. Clerk cuida de auth e vai assinar um BAA. Isso é rápido para lançar e razoável de operar. O tradeoff é custo em escala e alguma perda de controle de infraestrutura. is the developer-experience stack. Vercel will sign a BAA (enterprise plan -- yes, it costs money). PlanetScale and Neon both have HIPAA-eligible tiers. Clerk handles auth and will sign a BAA. This is fast to ship and reasonable to operate. The tradeoff is cost at scale and some loss of infrastructure control.
AWS (ECS/EKS para a aplicação Next.js) + RDS Aurora + Cognito é a stack enterprise. Mais overhead operacional. Muito mais controle. O modelo de responsabilidade compartilhada da AWS é bem documentado e a cobertura do BAA é ampla. Se seu cliente é um sistema hospitalar ou uma seguradora, provavelmente vão perguntar sobre sua arquitetura AWS em detalhe. is the enterprise stack. More operational overhead. Much more control. AWS's shared responsibility model is well-documented and the BAA coverage is broad. If your client is a hospital system or an insurer, they're probably going to ask about your AWS architecture in detail.
Render ou Railway -- eu evitaria para qualquer coisa seriamente regulada. São excelentes ferramentas, mas o histórico delas em conformidade HIPAA é fraco. -- I'd steer clear for anything seriously regulated. They're great tools, but their HIPAA compliance story is thin.
Uma coisa que quero destacar: a Edge Network e as Edge Functions da Vercel não são cobertas por HIPAA sob seu BAA a partir do início de 2026. Se você está executando lógica que toca PHI em middleware de edge, isso é uma lacuna. Execute essa lógica em funções serverless (runtime Node.js) em vez disso.not HIPAA-covered under their BAA as of early 2026. If you're running logic that touches PHI in edge middleware, that's a gap. Run that logic in serverless functions (Node.js runtime) instead.
---
BAA HIPAA da Vercel -- o que $350/mês realmente compra para você
Até 2025, assinar um BAA da Vercel exigia um contrato Enterprise -- tipicamente em torno de $45.000 por ano no gasto mediano. Isso tirava do alcance a maioria das equipes de health-tech pré-Series-A e as empurrava para AWS ou Cloudflare. Em 2025 a Vercel mudou isso: BAAs HIPAA agora estão disponíveis como um add-on de self-serve de $350/mês no plano Pro.
O BAA Pro é um acordo de click-through, assinado via dashboard da Vercel. Não há negociação, sem commit mínimo, sem ligação de vendas Enterprise. Se você está no Pro a $20/seat/mês e adiciona o add-on HIPAA, sua equipe-de-três healthcare app sai a $410/mês all-in para a camada de plataforma.
O que o BAA Pro cobre
- A Vercel atua como seu associado de negócios para fins HIPAA -- ela tem as salvaguardas técnicas e organizacionais que uma entidade coberta precisa em um fornecedor.
- Auditorias anuais de terceiros, notificação de breach dentro dos prazos HIPAA, e o conjunto padrão de salvaguardas administrativas.
- Edge runtime, Functions, ISR, image optimisation, e o resto da plataforma Vercel estão dentro do escopo do BAA.
O que o BAA do Pro NÃO cobre -- leia isso antes de se comprometer
O recurso de segurança aprimorado da Vercel -- Secure Compute -- é apenas para Enterprise. Secure Compute oferece redes de nuvem isoladas, endereços IP dedicados e peering de VPC. Se sua arquitetura de segurança exige isolamento de rede entre sua app e a infraestrutura pública da Vercel (uma solicitação justa se seu auditor se importa com defesa em profundidade), o BAA Pro não é suficiente. Você precisa de Enterprise.
Tradução prática: o BAA Pro a $350/mês funciona para a maioria dos healthcare apps em estágio inicial onde a postura de auditoria é baseada em controles apropriados. Se você está vendendo para hospital systems ou tem um compliance officer que leu NIST SP 800-66 de capa a capa, você estará no plano Enterprise de qualquer forma.
Se você também precisa de SSO
SAML SSO no Vercel Pro é um add-on separado de $300/mês. Combinado com o BAA HIPAA, você fica em $650/mês em add-ons de conformidade. Esse é aproximadamente o limite onde a cotação Enterprise começa a parecer comparável em TCO -- em $45K/ano mediano, Enterprise sai a cerca de $3.750/mês, mas inclui BAA, SSO, Secure Compute, suporte dedicado e vários outros recursos. A matemática se equilibra no segundo ano para a maioria das equipes.
O caminho WordPress que a maioria dos engenheiros nunca considera
Se você passou as últimas seis semanas decidindo qual biblioteca de autenticação Next.js tem a melhor história de HIPAA, aqui vai uma pergunta para interromper esse raciocínio: seu produto realmente precisa de autenticação? Ou o briefing é um site de marketing, um blog editorial e um formulário de entrada em conformidade com HIPAA?
Se a resposta é a segunda -- e para a maioria das clínicas de saúde, consultórios dentários, provedores de saúde mental e clínicas de fisioterapia, a resposta é a segunda -- WordPress em um host elegível para HIPAA é o caminho que você deveria estar seguindo. O custo é menor, o fluxo de trabalho editorial está resolvido, e o modelo de segurança é genuinamente mais simples. Plugins continuam sendo a superfície de ataque que sempre foram, mas você pode lançar com um conjunto pequeno de plugins e um host HIPAA gerenciado que audita o resto.
Hosts que assinam um BAA para WordPress
- Atlantic.Net -- hospedagem WordPress HIPAA gerenciada a partir de $350/mês com um BAA assinado, acesso VPN criptografado, backups diários, MFA e garantia de 100% de tempo de atividade. Duas décadas de TI em saúde. A escolha padrão para clínicas.
- Liquid Web -- servidores dedicados, VPS ou nuvem totalmente gerenciados a partir de $600/mês com configurações alinhadas a HIPAA e um BAA assinado. Suporte forte, operações maduras.
- HIPAA Vault -- construído especificamente para HIPAA desde o primeiro dia. Preço mais alto, postura de conformidade mais profunda, utilizado por organizações maiores de saúde.
- ScalaHosting -- VPS gerenciado a partir de $29.95/mês com BAA assinado, backups diários, transferência criptografada. O final mais barato da curva; adequado para tráfego inicial e menor.
- AWS / Azure / GCP com WordPress gerenciado no topo -- toda nuvem de grande porte assinará um BAA, mas você é responsável pela configuração, hardening e postura contínua. Resposta certa se você já tem um time de nuvem.
Onde o caminho do WordPress para de funcionar
- Painéis de pacientes autenticados -- possível em WordPress, doloroso, e a lacuna de plugins é real. Migre para Next.js + Vercel BAA.
- Dados em tempo real, recursos de IA, fluxos de trabalho personalizados -- WordPress vai dificultar. Next.js + Supabase + Vercel BAA é a chamada certa.Supabase + Vercel BAA is the right call.
- Qualquer coisa além de 100 plugins ou um sistema de associação complexo -- a superfície de ataque de plugin sozinha é um risco HIPAA que vale a pena projetar para fora.
Se seu briefing se situa na lane do WordPress, o caminho de migração prático é a opção WordPress headless -- wp-admin para editores, um front end Next.js ou Astro do lado público, WPGraphQL conectando os dois. Você mantém o fluxo de trabalho editorial, o site público é rápido, e a superfície pública obtém a história de hosting moderna. Antes de se comprometer de qualquer forma, o WordPress Stack Advisor pega sua URL e diz qual caminho realmente se encaixa.headless WordPress option -- wp-admin for editors, a Next.js or Astro front end on the public side, WPGraphQL bridging the two. You keep the editorial workflow, the public site is fast, and the public surface gets the modern hosting story. Before you commit either way, the WordPress Stack Advisor takes your URL and tells you which path actually fits.
JotForm Gold a $99/mês: quando o atalho é a chamada correta
Se o único PHI que seu produto toca é o que vem através de um formulário -- admissão de paciente, check-in de sintomas, feedback pós-visita, solicitações de agendamento -- você não precisa construir formulários compatíveis com HIPAA em sua aplicação. JotForm Gold a $99/mês por usuário inclui HIPAA sem custo adicional. PHI é coletado na infraestrutura auditada por HIPAA do JotForm e nunca toca seus servidores.
O que JotForm Gold realmente inclui
- Conformidade HIPAA incorporada -- BAA assinado via dashboard do JotForm, sem sobrecarga.
- 100 formulários, 10.000 envios mensais, 100 GB de armazenamento. Mais do que suficiente para uma clínica multi-localização.
- Tipos de campo elegíveis para HIPAA: captura de assinatura, upload de arquivo (criptografado), lógica condicional, preenchimento automático, integrações de pagamento com processadores em conformidade com HIPAA.
- Incorpore via iframe no seu site WordPress, no seu aplicativo Next.js, na sua página Webflow, em qualquer lugar. O formulário é executado na infraestrutura do JotForm; seu site nunca vê o PHI.
- Integrações de fluxo de trabalho com CRMs, EHRs e plataformas farmacêuticas elegíveis para HIPAA. A lista é menor do que no modo não-HIPAA, mas cobre os pontos comuns.
Quando o JotForm vence no TCO
Construir um formulário de admissão em conformidade com HIPAA nativamente em Next.js é um engajamento de 2 a 3 semanas: coluna de banco de dados criptografada em repouso, registro de auditoria, BAA com seu provedor de armazenamento, revisão de segurança, documentação de modelo de ameaça e a manutenção contínua que acompanha um pipeline de formulário personalizado. JotForm por $99/mês faz isso em uma tarde. Se seu formulário é o único ponto de contato com PHI, o cálculo sempre favorece o JotForm.
Onde o JotForm deixa de ser suficiente
- Seu portal de pacientes -- qualquer coisa que precise ler PHI de interações anteriores, renderizar uma linha do tempo de paciente, ou integrar profundamente com seus dados de aplicação. Construa em sua app.
- Restrições de marca que exigem UX de formulário perfeito em pixels. A personalização do JotForm é boa, não perfeita.
- Fluxos clínicos multi-etapa que vão além do preenchimento de formulários -- lógica de triagem, chat de clínico em tempo real, árvores de suporte à decisão. Build customizado.
- Se seu auditor quer que cada byte de PHI viva dentro do seu VPC. JotForm é a escolha certa quando delegar a um fornecedor auditado por HIPAA é aceitável; é a escolha errada quando seu modelo de segurança exige isolamento.
Integrações de Terceiros: Onde a Conformidade vai Morrer
Todo terceiro que você integra e que toca em PHI precisa de um BAA. Isso soa óbvio. Aqui está a lista que realmente confunde os times:
- Ferramentas de suporte ao cliente (Intercom, Zendesk) -- se um paciente mensageia sobre sua saúde, isso é PHI na sua plataforma de suporte
- Ferramentas de formulários (Typeform, Jotform) -- formulários de admissão de pacientes são PHI
- Provedores de email (SendGrid, Postmark) -- se o corpo do email contém informações de saúde, BAA é necessário
- Ferramentas de feature flag (LaunchDarkly, Statsig) -- geralmente ok, mas se você está passando atributos do usuário que incluem status de saúde para avaliar flags, isso é PHI
- CRMs (HubSpot, Salesforce) -- muitos times de healthtech sincronizam dados de pacientes nestes sem pensar
Postmark vai assinar um BAA. SendGrid (via Twilio) também vai, em planos pagos. Twilio para SMS também. LaunchDarkly tem um caminho BAA. Estas não são opções obscuras -- o processo de BAA é geralmente um envio de formulário e alguns dias úteis.
Os que não vão ou não podem assinar um BAA? Não integre em lugar nenhum perto de PHI. Simples assim.
---
FAQ
Quanto custa realmente o HIPAA BAA do Vercel?
O Vercel Business Associate Agreement para HIPAA está disponível no plano Pro como um add-on de $350/mês, assinado via self-serve no dashboard. SAML SSO no Pro é um add-on separado de $300/mês, colocando uma configuração de compliance típica em $650/mês combinados. O plano Enterprise, que fica em torno de $45.000/ano na mediana, inclui o BAA, SSO e Secure Compute (redes isoladas, IPs dedicados, VPC peering).
Consigo rodar um site WordPress em conformidade com HIPAA?
Sim, em um host elegível para HIPAA que assine um BAA. As quatro opções comuns em 2026 são Atlantic.Net (a partir de $350/mês), Liquid Web (a partir de $600/mês), HIPAA Vault (construída especificamente para saúde) e ScalaHosting managed VPS (a partir de $29.95/mês). O caminho WordPress é o certo para sites de marketing de saúde, sites de clínicas e conteúdo com peso editorial. Para de funcionar quando você precisa de dashboards autenticados de pacientes, dados em tempo real ou qualquer coisa acima de 100 plugins de superfície de ataque.
JotForm é suficiente para formulários em conformidade com HIPAA?
Se formulários são o único ponto de contato com PHI, sim. JotForm Gold a $99/mês inclui HIPAA sem custo extra -- BAA assinado, 100 formulários, 10.000 submissões, 100 GB de armazenamento. PHI é coletado na infraestrutura auditada por HIPAA do JotForm, incorporado via iframe no seu site. JotForm deixa de ser suficiente quando seu produto precisa ler PHI de volta entre sessões, renderizar linhas do tempo de pacientes, ou executar fluxos clínicos multi-etapa.
Quando o caminho WordPress vence o caminho Next.js para HIPAA?
Quando seu produto de saúde é um site de marketing mais um blog mais um formulário de entrada. WordPress é mais rápido de colocar em produção, mais barato de hospedar, e o fluxo editorial já está resolvido para staff não-técnico. O caminho Next.js vence quando você precisa de autenticação, dashboards customizados, dados em tempo real, features de IA ou qualquer coisa que se beneficie de uma arquitetura de aplicação moderna. Um híbrido comum: WordPress em um host HIPAA gerenciado para o site público, Next.js no Vercel BAA para o app autenticado, JotForm para o formulário de entrada.
Fazer deploy no Vercel torna meu app Next.js em conformidade com HIPAA?
Não. Vercel pode assinar um Business Associate Agreement no seu plano enterprise, o que significa que eles assumem certas obrigações de HIPAA pela infraestrutura que controlam. Mas seu código de aplicação, seu design de banco de dados, seu logging, suas integrações de terceiros -- nada disso é coberto pelo BAA da Vercel. Conformidade é compartilhada em cada camada da stack, e a camada de aplicação é sua responsabilidade.
Preciso criptografar dados em uma rota de API Next.js antes de enviar para o cliente?
TLS cuida da criptografia em trânsito, então você não precisa criptografar manualmente o corpo da resposta HTTP. O que você precisa fazer é se certificar de que está retornando apenas o mínimo necessário de PHI para a operação -- não registros completos de pacientes quando você só precisa de um nome, por exemplo. O princípio do "mínimo necessário" é integrado ao HIPAA e deve moldar o design da sua resposta de API desde o primeiro dia.
O caching integrado do App Router do Next.js é seguro para PHI?
Não por padrão. O Data Cache e Full Route Cache no App Router podem cachear respostas que contêm PHI, o que é problemático. Para qualquer rota ou chamada fetch que acesse dados de pacientes, use { cache: 'no-store' } em chamadas fetch e adicione export const dynamic = 'force-dynamic' aos segmentos de rota. Revise a documentação de caching do Vercel com cuidado -- é densa mas importante.{ cache: 'no-store' }on fetch calls and add export const dynamic = 'force-dynamic'to route segments. Review Vercel's caching documentation carefully -- it's dense but important.
Qual é o mínimo de logging que preciso para uma trilha de auditoria HIPAA?
No mínimo: quem acessou o quê, quando e de onde. Isso é ID do usuário, identificador do recurso, tipo de ação, timestamp e endereço IP. Logs precisam ser à prova de manipulação (append-only, não editáveis pelo código da aplicação) e retidos -- a maioria dos frameworks de compliance sugere seis anos, o que corresponde ao requisito de retenção de documentação do HIPAA.
Posso usar React Query ou SWR para busca de dados em um app HIPAA?
Sim, mas com cuidado. Ambas as bibliotecas cacheiam respostas no lado do cliente, o que significa que PHI pode ficar na memória do navegador. Configure staleTime: 0 e cacheTime: 0 (React Query) ou dedupingInterval: 0 (SWR) para queries que retornam PHI. Também limpe o query cache no logout explicitamente -- não confie no unmounting de componentes para lidar com isso.staleTime: 0 and cacheTime: 0(React Query) or dedupingInterval: 0(SWR) for queries that return PHI. Also clear the query cache on logout explicitly -- don't rely on component unmounting to handle this.
---
Quero ser honesto sobre algo: conformidade HIPAA é genuinamente difícil de acertar, e nenhum framework -- Next.js ou outro -- torna fácil. Os times que vi fazê-lo bem são aqueles que tratam isso como um problema de arquitetura desde o primeiro dia, não um checklist para executar antes do lançamento. O framework é fine. As lacunas estão quase sempre nas decisões tomadas em torno dele.
Comece com o mapeamento da superfície de PHI. Tudo mais segue disso.
Leitura relacionada
Stacks de hosting que realmente assinam um HIPAA BAA em 2026 -- o post de comparação de hosting mais aprofundado, com faixas de custo anual e notas de escopo BAA para cada provedor. -- the deeper hosting comparison post, with annual cost ranges and BAA scope notes for each provider.
WordPress vs Next.js: quando cada um é a escolha certa -- a decisão de framework sem o framing HIPAA, útil como o prelúdio. -- the framework decision without the HIPAA framing, useful as the prequel.
Headless WordPress + Astro: uma configuração funcional -- se você escolher o caminho WordPress mas quiser um front end público moderno. -- if you take the WordPress path but want a modern public front end.
WordPress Stack Advisor -- cole sua URL, obtenha uma recomendação personalizada que inclui o caminho HIPAA que se encaixa no seu brief em 30 segundos. -- paste your URL, get a tailored recommendation that includes the HIPAA path that fits your brief in 30 seconds.
Se você está prestes a lançar um produto de healthcare e não consegue dizer qual dos três caminhos acima é o correto para seu brief, os próximos trinta minutos resolverão isso.
Marque uma chamada HIPAA stack de 30 minutos -- você descreve o produto, eu digo se a resposta é Next.js + Vercel BAA, WordPress em um host HIPAA gerenciado, JotForm, ou um híbrido. Ao final da chamada você tem uma escolha de stack, uma faixa de preço e um caminho de migração se você já estiver na stack errada. -- you describe the product, I tell you whether the answer is Next.js + Vercel BAA, WordPress on a managed HIPAA host, JotForm, or a hybrid. By the end of the call you have a stack pick, a price range, and a migration path if you are already on the wrong stack.