Se você está criando software que toca dados de saúde de qualquer forma — uma plataforma de telemedicina, um portal de paciente, um SaaS de rastreamento de saúde, ou até mesmo um website de marketing para um provedor de saúde — conformidade HIPAA não é opcional. E em 2026, as regras ficaram mais rigorosas.

A Final Rule da Security Rule de 2026 removeu a margem de manobra em que muitos times confiavam. MFA agora é obrigatório, não endereçável. Criptografia em repouso e em trânsito agora é obrigatória, não endereçável. Se sua postura de conformidade foi construída em exceções documentadas para qualquer uma dessas, essa postura está morta.

Passei anos construindo aplicações web em conformidade com HIPAA, e o maior erro que vejo times cometendo é tratar conformidade como um exercício de burocracia. Não é. É um problema de engenharia com consequências legais. Esta lista de verificação é escrita a partir dessa perspectiva — menos jargão legal, mais orientação prática de implementação para desenvolvedores, CTOs e líderes de produto que precisam entregar software em conformidade.

Sumário

HIPAA Compliance Checklist 2026: Websites, SaaS & Software

Entendendo as Três Regras HIPAA Principais

HIPAA organiza obrigações de conformidade em regras distintas. Três delas são mais importantes para equipes de software e web:

A Privacy Rule

A Privacy Rule governa como Protected Health Information (PHI) pode ser usada e divulgada. PHI é qualquer informação relacionada à saúde vinculada a um indivíduo identificável — registros médicos, resultados de laboratório, detalhes de seguros, datas de compromissos, até endereços IP se coletados junto com dados de saúde.

Requisitos-chave:

  • Um Notice of Privacy Practices deve ser publicado e acessível
  • O padrão "mínimo necessário" se aplica: acesse e compartilhe apenas o PHI que você realmente precisa
  • Pacientes têm direitos de acessar, emendar e solicitar contabilidade de divulgações de seu PHI
  • Autorizações são necessárias para usos além de tratamento, pagamento e operações de saúde

A Security Rule

A Security Rule protege especificamente PHI eletrônico (ePHI). Ela exige três categorias de salvaguardas: administrativa, física e técnica. Para SaaS e aplicações web, as salvaguardas técnicas são onde a maioria do esforço de engenharia ocorre — controles de acesso, logging de auditoria, criptografia, controles de integridade e segurança de transmissão.

A Security Rule mapeia para 45 CFR Part 164, e cada salvaguarda tem uma seção específica: controles de acesso (164.312(a)), controles de auditoria (164.312(b)), controles de integridade (164.312(c)), autenticação (164.312(d)) e segurança de transmissão (164.312(e)).

A Breach Notification Rule

Quando PHI não seguro é exposto, você deve notificar indivíduos afetados, HHS e às vezes a mídia. O relógio começa quando você descobre a violação — não quando você termina de investigar. Mais sobre os prazos específicos abaixo.

Há também uma Enforcement Rule que governa como OCR investiga e penaliza violações, mas as três regras acima são onde seu programa de conformidade vive.

Quem Precisa Estar em Conformidade: Entidades Cobertas vs. Associados de Negócios

É aqui que muitos times de SaaS ficam confusos. Você não precisa ser um hospital para estar sujeito à HIPAA.

Covered Entities (Entidades Cobertas) são planos de saúde, câmaras de compensação de saúde e provedores de saúde que transmitem informações de saúde eletronicamente.

Business Associates (Associados de Negócios) são fornecedores que criam, recebem, mantêm ou transmitem PHI em nome de uma entidade coberta. Se seu produto SaaS processa dados de saúde para um cliente de saúde, você é um associado de negócios. Ponto final.

Desde a HIPAA Omnibus Rule, associados de negócios carregam obrigações de conformidade diretas. Você não pode se esconder sob o programa de conformidade de seu cliente. Você precisa do seu próprio.

Isso significa:

  • Você deve assinar um Business Associate Agreement (BAA) com cada entidade coberta que você serve
  • Você deve assinar BAAs com seus próprios sub-processadores (AWS, GCP, seu provedor de banco de dados, seu serviço de email)
  • Você deve implementar as salvaguardas da Security Rule independentemente
  • Você está sujeito a aplicação de OCR diretamente

A Final Rule da Security Rule de 2026: O Que Mudou

A Security Rule original (2003) dividiu especificações de implementação em "obrigatórias" e "endereçáveis". Obrigatório significava que você tinha que fazer. Endereçável significava que você tinha que implementar, documentar por que uma medida equivalente foi usada, ou documentar por que não era razoável. Na prática, muitas organizações trataram "endereçável" como "opcional".

A Final Rule de 2026 elimina essa ambiguidade em duas áreas críticas:

Controle Status Anterior Status 2026 Impacto
Autenticação Multifator Endereçável Obrigatório Todos os sistemas acessando ePHI devem aplicar MFA. Sem exceções.
Criptografia em Repouso Endereçável Obrigatório Todo armazenamento de ePHI deve ser criptografado. Controles compensatórios não são mais aceitos.
Criptografia em Trânsito Endereçável Obrigatório Toda transmissão de ePHI deve ser criptografada. TLS 1.2 mínimo.
Análise de Risco Obrigatório Obrigatório (expandido) Deve ser contínua, não anual. Monitoramento automatizado esperado.
Logging de Auditoria Obrigatório Obrigatório (expandido) Logs devem ser imutáveis e retidos conforme política documentada.

Se você foi confiando em exceções documentadas para MFA ou criptografia, você precisa remediar imediatamente. Essa postura não é mais defensável sob a regra atualizada.

HIPAA Compliance Checklist 2026: Websites, SaaS & Software - architecture

Lista de Verificação da Privacy Rule para Websites e SaaS

É aqui que websites especificamente tropeçam. Seu website de marketing para um produto de saúde tem obrigações da Privacy Rule que a maioria dos times web não pensa.

  • Publique um Notice of Privacy Practices (NPP) — Deve estar acessível de forma proeminente em seu website. Não enterrado em um labirinto de links de rodapé.
  • Implemente o padrão de mínimo necessário — Seus formulários devem coletar apenas o PHI que você realmente precisa. Aquele formulário de entrada de 15 campos? Audite cada campo.
  • Honre solicitações de acesso de pacientes — Se seu software armazena PHI, você deve fornecer aos pacientes uma maneira de acessar seus registros em 30 dias.
  • Implemente fluxos de autorização — Qualquer uso de PHI além de tratamento/pagamento/operações requer autorização explícita do paciente.
  • Rastreie divulgações — Mantenha uma contabilidade de toda divulgação de PHI por pelo menos seis anos.
  • Treine sua força de trabalho — Todos que tocam PHI precisam de treinamento em Privacy Rule. Documente.
  • Designe um Privacy Officer — Alguém tem que ser dono disso. Pode ser um papel compartilhado, mas deve ser documentado.
  • Revise rastreamento de terceiros — Este é o grande para websites. Google Analytics, Meta Pixel, rastreamento HubSpot — se essas ferramentas podem capturar PHI (e frequentemente podem), você tem um problema de Privacy Rule.

Lista de Verificação da Security Rule: Salvaguardas Administrativas

Salvaguardas administrativas são as políticas e procedimentos que governam seu programa de segurança. Frequentemente são a parte menos emocionante de conformidade, mas é o que OCR observa primeiro durante uma investigação.

  • Conduza uma análise de risco — Não um exercício único. A regra de 2026 espera avaliação contínua de risco. Mapeie cada sistema que toca ePHI, identifique ameaças, avalie vulnerabilidades e documente seu nível de risco.
  • Implemente um plano de gerenciamento de risco — Para cada risco identificado, documente como você está mitigando. Riscos aceitos devem ser formalmente documentados com lógica.
  • Atribua um Security Officer — Alguém detém o programa de segurança. Documente quem.
  • Implemente controles de acesso de força de trabalho — Políticas de acesso baseadas em função. Quem pode acessar qual ePHI e por quê.
  • Conduza treinamento de conscientização de segurança — Mínimo anual, mas trimestral é melhor. Documente participação.
  • Implemente política de sanções — O que acontece quando alguém viola política? Documente.
  • Revise atividade do sistema de informação — Revisão regular de logs de auditoria. Não apenas coletando-os — realmente revisando-os.
  • Desenvolva um plano de contingência — Backup de dados, recuperação de desastres, operações emergenciais. Teste pelo menos anualmente.
  • Avalie BAAs — Revise todos os acordos de associado de negócios. Todo fornecedor tocando ePHI precisa de um.

Lista de Verificação da Security Rule: Salvaguardas Físicas

Para times de SaaS rodando em infraestrutura de nuvem, salvaguardas físicas principalmente mudam para seu provedor de nuvem — mas você ainda tem obrigações.

  • Controles de acesso de instalação — Se você tem escritórios onde ePHI é acessível, controle acesso físico. Leitores de crachá, logs de visitantes, salas de servidor bloqueadas.
  • Segurança de estação de trabalho — Laptops usados por desenvolvedores que acessam ePHI de produção devem ter criptografia de disco completo, políticas de bloqueio de tela e capacidade de limpeza remota.
  • Controles de dispositivo e mídia — Políticas para disposição de hardware que armazenou ePHI. Documente métodos de destruição.
  • Validação de provedor de nuvem — Verifique certificações de segurança física de seu provedor de nuvem. AWS, GCP e Azure todos publicam relatórios SOC 2 cobrindo controles físicos — solicite e revise.

Lista de Verificação da Security Rule: Salvaguardas Técnicas

É aqui que times de engenharia gastam a maioria de seus esforços. Cada salvaguarda mapeia para um controle testável.

Controles de Acesso (164.312(a))

  • Identificação única de usuário — Cada usuário recebe um ID único. Sem contas compartilhadas. Nunca.
  • Procedimento de acesso de emergência — Processo documentado para acessar ePHI durante emergências.
  • Logoff automático — Timeouts de sessão em todos os sistemas acessando ePHI. 15 minutos é um padrão razoável.
  • Criptografia e descriptografia — ePHI deve ser criptografado em repouso. AES-256 é o padrão.
# Exemplo: Verificando criptografia em repouso em AWS RDS
import boto3

def check_rds_encryption():
    rds = boto3.client('rds')
    instances = rds.describe_db_instances()
    for db in instances['DBInstances']:
        if not db['StorageEncrypted']:
            print(f"AVISO: {db['DBInstanceIdentifier']} NÃO está criptografado")
            # Isso agora é uma violação de conformidade sob regras de 2026
        else:
            print(f"OK: {db['DBInstanceIdentifier']} criptografado com {db['KmsKeyId']}")

Controles de Auditoria (164.312(b))

  • Registre todo acesso de ePHI — Toda leitura, escrita, atualização e exclusão.
  • Torne logs imutáveis — Use armazenamento append-only. CloudWatch Logs com políticas de retenção, ou envie para um SIEM imutável.
  • Retenha logs conforme política — Seis anos é o padrão seguro para corresponder ao requisito geral de retenção de HIPAA.
  • Automatize revisão de log — Configure alertas para padrões de acesso anômalos. Um desenvolvedor consultando 10.000 registros de pacientes às 3 da manhã deve disparar um alerta.
// Exemplo: Middleware Express para logging de acesso de ePHI
const logPhiAccess = (req, res, next) => {
  const logEntry = {
    timestamp: new Date().toISOString(),
    userId: req.user?.id,
    action: req.method,
    resource: req.originalUrl,
    sourceIp: req.ip,
    userAgent: req.get('User-Agent'),
    // Não registre o PHI real no log de auditoria
    resourceType: 'ePHI',
  };
  
  // Envie para armazenamento de log imutável
  auditLogger.write(logEntry);
  next();
};

app.use('/api/patients/*', logPhiAccess);

Controles de Integridade (164.312(c))

  • Implemente mecanismos para verificar que ePHI não foi alterado — Checksums, assinaturas digitais ou controles de integridade de nível de banco de dados.
  • Proteja contra modificação não autorizada — Acesso de escrita deve ser rigidamente escopo.

Autenticação (164.312(d))

  • Verifique identidade de qualquer pessoa acessando ePHI — Autenticação forte necessária.
  • Implemente MFA — Agora obrigatório sob a regra de 2026. TOTP, chaves de hardware ou MFA baseado em push. MFA baseado em SMS é tecnicamente compatível mas não recomendado devido a riscos de SIM-swapping.

Segurança de Transmissão (164.312(e))

  • Criptografe ePHI em trânsito — TLS 1.2 mínimo. TLS 1.3 preferido.
  • Aplique HTTPS em todos os lugares — Sem conteúdo misto. Headers HSTS necessários.
  • Comunicações seguras de API — Todas as chamadas de API transmitindo ePHI devem usar canais criptografados. TLS mútuo para comunicação de serviço para serviço é um padrão forte.
# Configuração Nginx aplicando TLS 1.2+ e HSTS
server {
    listen 443 ssl http2;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5:!RC4;
    ssl_prefer_server_ciphers on;
    
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
    add_header X-Content-Type-Options nosniff always;
    add_header X-Frame-Options DENY always;
}

Lista de Verificação da Regra de Notificação de Violação

Uma violação é qualquer uso ou divulgação não permitida que compromete a segurança ou privacidade de PHI. Aqui está o que você precisa ter em lugar antes de uma acontecer — porque se você está construindo durante um incidente, você já está atrasado.

  • Defina seu plano de resposta a incidentes — Quem faz o quê quando uma violação é descoberta? Documente papéis, caminhos de escalação e modelos de comunicação.
  • Estabeleça uma janela de notificação de 60 dias — Indivíduos afetados devem ser notificados em 60 dias do descobrimento da violação. Não 60 dias a partir de quando aconteceu — 60 dias a partir de quando você soube disso.
  • Notifique HHS — Se 500+ indivíduos são afetados, notifique HHS simultaneamente com notificações individuais. Para violações afetando menos de 500 indivíduos, você pode relatar anualmente (mas não adie investigação).
  • Notifique mídia — Violações afetando 500+ indivíduos em um único estado ou jurisdição requerem notificação de mídia.
  • Documente a avaliação de risco — Para cada violação potencial, execute uma avaliação de risco de quatro fatores: natureza e extensão de PHI envolvido, pessoa não autorizada que acessou, se PHI foi realmente adquirido ou visto, extensão de mitigação de risco.
  • Conheça o porto seguro de criptografia — Se dados violados foram criptografados com criptografia padrão NIST e a chave não foi comprometida, pode não constituir uma violação requerendo notificação. Isso é um dos argumentos mais fortes para criptografia em todos os lugares.
  • Conduza exercícios de tabletop — Execute simulações de violação pelo menos anualmente. Tempo de resposta de sua equipe. Identifique lacunas.

Preocupações Específicas com HIPAA em Websites que a Maioria dos Times Perde

Esta é a seção que gostaria que alguém tivesse escrito para mim cinco anos atrás. Websites têm pontos de exposição HIPAA que engenheiros de backend não sempre pensam.

Rastreamento e Analytics de Terceiros

Em dezembro de 2022, HHS emitiu orientação esclarecendo que tecnologias de rastreamento em websites de saúde podem criar violações de HIPAA. Isso não mudou — ficou mais rigoroso. Se seu website de saúde usa Google Analytics, Meta Pixel ou ferramentas similares, e essas ferramentas podem capturar PHI (incluindo endereços IP combinados com visitas a páginas relacionadas à saúde), você pode estar transmitindo PHI para terceiros sem um BAA.

O que fazer:

  • Audite cada script de terceiros rodando em seu site
  • Remova pixels de rastreamento de páginas que coletam ou exibem informações de saúde
  • Use analytics do lado do servidor onde possível
  • Se você deve usar analytics do lado do cliente, garanta que estejam configurados para excluir PHI
  • Considere alternativas focadas em privacidade como Plausible ou Fathom que não coletam PII

JavaScript do Lado do Cliente e Risco de Cadeia de Suprimentos

Cada pacote npm, cada script hospedado em CDN, cada widget de chat é um vetor potencial para exposição de ePHI. Um script de terceiros comprometido pode exfiltrar dados de formulário — incluindo PHI — para servidor de um atacante.

  • Implemente headers Content Security Policy (CSP)
  • Use Subresource Integrity (SRI) para ativos hospedados em CDN
  • Audite suas dependências do lado do cliente regularmente
  • Monitore seu Software Bill of Materials (SBOM)

Manipulação de Formulário

Formulários de contato, formulários de solicitação de compromisso, verificadores de sintomas — se eles coletam informações de saúde, eles estão manipulando PHI.

  • Criptografe submissões de formulário em trânsito (HTTPS)
  • Não armazene dados de formulário em plaintext
  • Não envie conteúdo de formulário por email não criptografado
  • Implemente CAPTCHA para prevenir extração automática de PHI
  • Defina políticas de retenção de dados apropriadas — não mantenha submissões de formulário para sempre

Se você está trabalhando com uma arquitetura de CMS headless, certifique-se de que seu pipeline de manipulação de formulário é compatível com HIPAA de ponta a ponta. Na Social Animal, construímos soluções de CMS headless com esses requisitos de segurança integrados desde o início, não aparafusados depois.

Comparação de Conformidade HIPAA: Provedores de Nuvem

Sua escolha de infraestrutura importa. Aqui está como os principais provedores de nuvem se equiparam para workloads de HIPAA em 2026:

Feature AWS Google Cloud Azure Vercel Netlify
Oferece BAA Sim Sim Sim Sim (Enterprise) Não
Serviços elegíveis para HIPAA documentados 150+ 100+ 130+ Limitado N/A
Criptografia padrão em repouso Sim (maioria dos serviços) Sim Sim Parcial N/A
Certificado HITRUST CSF Sim Sim Sim Não Não
Documentação dedicada de conformidade Extensa Extensa Extensa Mínima N/A
FedRAMP autorizado Sim (GovCloud) Sim Sim (Gov) Não Não

Uma nota crítica sobre plataformas de hospedagem estática: Se você está implantando um site Next.js ou Astro que manipula ePHI, tenha muito cuidado com sua escolha de hospedagem. Vercel assinará um BAA em planos enterprise, mas você precisa verificar quais serviços específicos estão cobertos. Netlify atualmente não oferece um BAA, tornando-a inadequada para workloads de HIPAA.

Para times construindo com frameworks como Next.js ou Astro, as decisões de arquitetura que você faz desde o início — onde os dados são processados, quais APIs manipulam PHI, como server-side rendering interage com estado do lado do cliente — todos têm implicações de HIPAA.

Documentação e Prontidão para Auditoria

HIPAA requer que você retenha documentação por seis anos. Isso inclui políticas, procedimentos, avaliações de risco, registros de treinamento, BAAs e relatórios de incidentes. Aqui está como se manter pronto para auditoria sem perder a cabeça:

  • Automatize coleta de evidência — Use ferramentas como Vanta, Drata ou Secureframe para coletar continuamente evidência de conformidade. Planilhas manuais não escalam.
  • Controle de versão suas políticas — Armazene documentos de conformidade em Git. Cada mudança é rastreada com autor, timestamp e contexto.
  • Automatize varredura de segurança — Execute scanners de infrastructure-as-code (Checkov, tfsec) em seu pipeline de CI/CD para pegar configurações erradas antes de chegarem a produção.
  • Agende revisões de acesso trimestrais — Quem tem acesso a quê? Ainda é apropriado? Documente a revisão.
  • Mantenha um registro de risco vivo — Sua avaliação de risco não é um PDF que você atualiza anualmente. É um documento vivo que muda conforme sua infraestrutura evolui.
# Exemplo: Passo do GitHub Actions para varredura de segurança de HIPAA
- name: Run Checkov security scan
  uses: bridgecrewio/checkov-action@v12
  with:
    directory: ./terraform
    framework: terraform
    check: CKV_AWS_17,CKV_AWS_19,CKV_AWS_145  # RDS encryption, S3 encryption, etc.
    soft_fail: false  # Falhe o pipeline em violações

Nenhuma certificação oficial de HIPAA governamental existe. HHS e OCR não emitem certificações. Se alguém diz que são "HIPAA certificados", pergunte o que eles realmente querem dizer. Frameworks de terceiros como HITRUST CSF e SOC 2 Type II podem demonstrar maturidade de conformidade para clientes, mas não substituem supervisão de OCR ou fornecem porto seguro.

Tiers de Penalidade: O Que Está em Risco

Vamos ser concreto sobre as consequências:

Tier Nível de Conhecimento Penalidade Por Violação Máximo Anual
Tier 1 Não sabia (e não podia) $137 – $68.928 $2.067.813
Tier 2 Causa razoável, não negligência intencional $1.379 – $68.928 $2.067.813
Tier 3 Negligência intencional, corrigida em 30 dias $13.785 – $68.928 $2.067.813
Tier 4 Negligência intencional, não corrigida $68.928 $2.067.813

Montantes de penalidade ajustados pela inflação a partir de 2026. Penalidades criminais podem incluir até 10 anos de prisão por ofensas cometidas com intenção de vender PHI.

Estas não são teóricas. OCR tem sido cada vez mais ativo em aplicação. O custo médio de uma violação de dados de saúde em 2025 foi $10,93 milhões de acordo com o Cost of a Data Breach Report da IBM. Conformidade é mais barata que a alternativa.

FAQ

Meu produto SaaS precisa estar em conformidade com HIPAA se não armazenarmos dados de saúde diretamente?

Se seu software cria, recebe, mantém ou transmite PHI em nome de uma entidade coberta, você é um associado de negócios e deve estar em conformidade. Até passar por ePHI sem armazenar desencadeia requisitos de conformidade. A pergunta-chave é se PHI toca seus sistemas em algum ponto.

Existe uma certificação oficial de HIPAA que posso obter?

Não. HHS e OCR não emitem ou endossam qualquer certificação de HIPAA. Frameworks de terceiros como HITRUST CSF, SOC 2 Type II ou ISO 27001 podem demonstrar sua postura de segurança para clientes e parceiros, mas não constituem certificação de HIPAA. Seja cético de qualquer fornecedor alegando ser "certificado HIPAA".

Qual é a diferença entre especificações obrigatórias e endereçáveis em 2026?

A Final Rule da Security Rule de 2026 tornou MFA e criptografia explicitamente obrigatórios, removendo seu status anterior "endereçável". Para especificações endereçáveis remanescentes, você deve implementar a especificação, implementar uma alternativa equivalente e documentar por quê, ou documentar por que não é razoável e apropriada. "Endereçável" nunca significou "opcional" — a atualização de 2026 apenas tornou isso inegável para os dois controles que mais importam.

Preciso de um BAA com meu provedor de hospedagem em nuvem?

Sim. Se seu provedor de nuvem processa, armazena ou transmite ePHI em seu nome, você precisa de um BAA. AWS, Google Cloud e Azure todos oferecem BAAs. Certifique-se de que você está apenas usando serviços que são explicitamente listados como compatíveis com HIPAA por seu provedor — nem todos os serviços dentro de uma plataforma de nuvem estão cobertos.

Posso usar Google Analytics em um website de saúde?

É arriscado. Orientação de HHS de 2022 (e reforçada desde) deixa claro que tecnologias de rastreamento que podem combinar endereços IP com visitas a páginas relacionadas à saúde podem constituir transmissão de PHI para terceiros sem um BAA. Google não assina um BAA para Google Analytics. Analytics do lado do servidor ou alternativas focadas em privacidade são escolhas mais seguras para websites de saúde.

Com que frequência preciso executar uma análise de risco de HIPAA?

A regra de 2026 enfatiza avaliação contínua de risco em vez de um exercício periódico. No mínimo, conduza uma análise de risco formal anualmente e sempre que houver uma mudança significativa em seus sistemas, ambiente ou operações. Muitas organizações estão se movimentando para monitoramento automatizado e contínuo de risco usando plataformas de conformidade.

O que conta como uma violação sob HIPAA?

Uma violação é qualquer uso ou divulgação não permitida de PHI que compromete sua segurança ou privacidade. Porém, há três exceções: aquisição não intencional por um membro da força de trabalho agindo de boa fé, divulgação inadvertida entre pessoas autorizadas dentro da organização, e situações onde você tem boa fé crença que o receptor não autorizado não pôde reter a informação. Dados criptografados que são violados podem se qualificar para porto seguro se a criptografia atender padrões NIST e a chave não foi comprometida.

O que devo fazer nas primeiras 24 horas após descobrir uma violação potencial?

Ative seu plano de resposta a incidentes. Contenha a violação — isole sistemas afetados se necessário. Comece a documentar tudo: o que aconteceu, quando foi descoberto, quem estava envolvido, quais dados foram afetados. Comece a avaliação de risco de quatro fatores. Notifique seu aconselhamento legal e seus oficiais de Privacy e Security de HIPAA. Não espere para investigar completamente antes de tomar ações de contenção. O relógio de notificação de 60 dias começa no descobrimento, então cada hora conta.

Se você está construindo software de saúde e precisa de ajuda para acertar a arquitetura desde o início, trabalhamos com times de engenharia para projetar aplicações web em conformidade com HIPAA. Confira nossas capacidades de desenvolvimento ou entre em contato para discutir seu projeto.