Um cliente me ligou numa quinta-feira à tarde no final de 2023 — uma startup de fintech que pivotava para healthtech, tinham acabado de contratar uma consultora de compliance que olhou para o codebase Next.js deles e devolveu uma lista de três páginas de problemas. "Achamos que colocar na AWS era o suficiente," disse o fundador. Ele realmente acreditava nisso. E honestamente? Eu tinha ouvido essa mesma frase de provavelmente seis times diferentes antes dele.
Conformidade HIPAA é uma daquelas áreas onde todo mundo pensa que entende a superfície — assine um BAA, escolha um provedor de nuvem em conformidade, pronto. Mas a Regra de Segurança HIPAA não se importa com a página de marketing do seu provedor de hospedagem. Ela se importa com como sua aplicação lida, armazena, transmite e audita Informações de Saúde Protegidas (PHI). Next.js — como framework — não é nem em conformidade nem em não-conformidade pronto para usar. O que você constrói sobre isso é tudo.thinksthey understand the surface — sign a BAA, pick a compliant cloud provider, done. But theHIPAA Security Ruledoesn'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.
---
O Que "Next.js em Conformidade 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ê. É um documento legal estabelecendo que eles vão proteger PHI na infraestrutura deles de acordo com as regras HIPAA. AWS tem uma lista de serviços elegíveis para HIPAA que vale a pena marcar. Mas um BAA da AWS não significa que seu app Next.js é compliant. Nem de perto.HIPAA-eligible services listthat'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 é só um veículo.yourresponsibility. Always. The framework is just a vehicle.
Aqui está o ponto — Next.js 14+ (e até 2026, o App Router está totalmente maduro) te dá server components, server actions, middleware e edge functions. Cada um desses tem implicações diferentes para o tratamento de PHI. Um server component que consulta um banco de dados de pacientes e passa dados para baixo para um client component — onde esses dados vivem? Por quanto tempo? Eles terminam em um cache do navegador? Essas não são preocupações hipotéticas.
---
O Problema da Superfície PHI
Antes de escrever uma linha de código, faço cada cliente de health-tech fazer um exercício: mapear todo lugar onde PHI poderia possivelmente tocar a aplicação. Não onde deveria tocar. Onde poderia.shouldtouch it. Where itcould.
Isso inclui:
- Parâmetros de URL (já vi IDs de pacientes em query strings — não façam)
- localStorage e sessionStorage do navegador
localStorageandsessionStorage - Gerenciamento de estado no lado do cliente (stores Zustand, Redux, até React context)
- Cache de fetch do Next.js e a camada Data Cache
- Saída 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 causam problemas para mais times do que quase qualquer outra coisa. No início de 2024, Seahawk tinha um cliente de telemedicina que havia configurado Sentry para monitoramento de erros. Movimento padrão. Exceto que seus error boundaries estavam capturando o objeto props completo no crash — que incluía detalhes de agendamentos e flags de saúde do usuário. Sentry não estava coberto sob seu BAA. Isso é uma violação esperando para acontecer.
Sanitizando Seu Rastreamento de Erros
Se você está usando Sentry com código adjacent a PHI, use o hook beforeSend para remover campos sensíveis antes deles saírem do navegador. Ponto final. Algo assim é inegociável:beforeSendhook 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; }``
Sentry tem um caminho de conformidade HIPAA — eles vão assinar um BAA — mas você ainda precisa configurar quais dados você envia para eles. O BAA não sanitiza suas 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 recorrem a NextAuth.js (agora Auth.js), conectam um provedor e acham que está pronto. 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 cookie de sessão por padrão, 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 de Logoff Automático 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 temporizador de inatividade no seu layout. Normalmente construo isso como um hook customizado que dispara uma ação de servidor 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 do OCR por que você não implementou depois de uma violação. Use TOTP via algo como otplib ou apoie-se em um provedor de identidade como Auth0 ou Clerk que tem MFA integrado e 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. - Auditoria de eventos de autenticação — Todo login, login falhado e logout precisa ser registrado com 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 está errado para este caso de uso — já o implementei em produção em projetos HIPAA. Mas você precisa camadas os requisitos de conformidade por cima deliberadamente.
---
Dados em Trânsito e em Repouso
Trânsito é a parte fácil. TLS 1.2 no mínimo, TLS 1.3preferido, em toda parte. Não só 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 rodando Next.js em um container Docker atrás de um reverse proxy NGINX, você precisa configurar isso você mesmo. Já revisei bases de código 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 na verdade 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, eu frequentemente adiciono uma segunda camada de criptografia no nível da aplicação usando uma biblioteca como @aws-sdk/client-kms para encapsular/desencapsular chaves. Overhead é real, mas o risco também é.— 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 — Esse pega as pessoas. O App Router faz cache de respostas fetch por padrão. Se você está buscando dados de pacientes em um server component com fetch(), você precisa { cache: 'no-store' } a menos que você esteja deliberadamente gerenciando revalidação. Uma resposta em cache contendo PHI sentada na memória ou sistema de arquivos 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 uma sequer vez.— 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 procedimentais que registrem e examinem atividades em sistemas de informação que contenham ou usem ePHI." Na prática, isso significa: você precisa de um log somente-adição de quem acessou quais dados 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 em Next.js. Para projetos com App Router, intercepto em middleware.ts para logging em nível de rota e adiciono um thin service wrapper em torno de qualquer função de query de banco de dados que toque em 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ê quiser garantias de imutabilidade) — nunca na mesma tabela que o PHI em si.middleware.tsfor 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 auditoria mínimo se parece com isso:
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 funciona)— 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 adicionar console.log(patientRecord) e chamar isso de trilha de auditoria. Eu já vi isso. 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 com HIPAA.
Vercel + PlanetScale/Neon + Clerk é a stack de experiência do desenvolvedor. Vercel assina um BAA (plano enterprise — sim, custa dinheiro). PlanetScale e Neon têm camadas elegíveis para HIPAA. Clerk gerencia autenticação e assina um BAA. É rápido para colocar em produção e razoável para operar. O tradeoff é custo em escala e alguma perda de controle da 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, ele provavelmente vai fazer perguntas detalhadas sobre sua arquitetura AWS.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 regulamentada. São excelentes ferramentas, mas sua história de conformidade com HIPAA é frágil.— 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 Edge Functions do Vercel não são cobertas por HIPAA sob seu BAA no início de 2026. Se você estiver 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.notHIPAA-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.
---
Integrações de Terceiros: Onde a Conformidade Vai Morrer
Todo terceiro que você integra que toca PHI precisa de um BAA. Isso soa óbvio. Aqui está a lista que realmente confunde times:
- Ferramentas de suporte ao cliente (Intercom, Zendesk) — se um paciente enviar mensagens 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 é obrigatório
- Ferramentas de feature flag (LaunchDarkly, Statsig) — geralmente ok, mas se você está passando atributos de usuário que incluem status de saúde para avaliar flags, isso é PHI
- CRMs (HubSpot, Salesforce) — muitos times de healthtech sincronizam dados de pacientes nesses 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 para BAA. Essas 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 conseguem assinar um BAA? Não integre em nenhum lugar perto de PHI. Tão simples quanto isso.
---
FAQ
Fazer deploy no Vercel torna meu app Next.js compatível com HIPAA?
Não. A Vercel pode assinar um Business Associate Agreement no plano enterprise, o que significa que assumem certas obrigações HIPAA para a infraestrutura que controlam. Mas o código da sua aplicação, o design do seu banco de dados, seus logs, suas integrações com terceiros — nada disso é coberto pelo BAA da Vercel. A conformidade é compartilhada entre todas as camadas da stack, e a camada de aplicação é sua responsabilidade.
Preciso criptografar dados em uma rota API do 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 é garantir 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" está embutido no HIPAA e deve moldar o design da sua resposta de API desde o início.
O cache integrado do App Router do Next.js é seguro para PHI?
Não por padrão. O Data Cache e o Full Route Cache no App Router podem cachear respostas que contêm PHI, o que é problemático. Para qualquer rota ou chamada fetch que toque em 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 da Vercel com cuidado — é densa mas importante.{ cache: 'no-store' }on fetch calls and addexport const dynamic = 'force-dynamic'to route segments. Review Vercel'scaching documentationcarefully — it's dense but important.
Qual é o logging mínimo 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 adulteração (append-only, não editáveis pelo código da aplicação) e retidos — a maioria dos frameworks de conformidade sugere seis anos, o que coincide com o 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. Defina staleTime: 0 e cacheTime: 0 (React Query) ou dedupingInterval: 0 (SWR) para consultas que retornam PHI. Também limpe o cache de consulta no logout explicitamente — não confie em component unmounting para lidar com isso.staleTime: 0andcacheTime: 0(React Query) ordedupingInterval: 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 uma coisa: conformidade HIPAA é genuinamente difícil de fazer certo, e nenhum framework — Next.js ou outro — torna isso fácil. Os times que vi fazer bem feito são aqueles que tratam isso como um problema de arquitetura desde o primeiro dia, não como uma checklist para cumprir antes do lançamento. O framework é ok. As lacunas estão quase sempre nas decisões tomadas ao redor dele.
Comece com o mapeamento da área de superfície de PHI. Tudo mais segue a partir disso.