Plano de conformidade regulatória

Mapeamento entre as normas relevantes para um sistema de chamados de emergência hospitalar e os controles concretos implementados neste projeto. Este documento é um ponto de partida técnico, não um parecer jurídico — validar com o setor de compliance/jurídico da Unimed Norte Fluminense antes de operar com pacientes reais.

ANS (Agência Nacional de Saúde Suplementar)

Correção em relação à especificação original: a ANS regula operadoras de planos de saúde (registro de ocorrências e auditoria no contexto de prestação de serviço ao beneficiário/plano), não infraestrutura predial ou sistemas internos de sinalização hospitalar. Não há uma norma ANS específica que este sistema precise cumprir diretamente. O que se aplica é indireto: se a Unimed NF, como operadora, precisar demonstrar à ANS processos de qualidade assistencial, os relatórios de SLA/tempo de resposta deste sistema (/dashboard/supervisor/relatorios) podem servir como evidência operacional — mas isso é benefício, não obrigação regulatória direta deste sistema.

ANVISA — RDC 50/2002

Norma: trata "sinalização de enfermagem" como sistema predial obrigatório em estabelecimentos de saúde.

Controle implementado:

• QR Code por quarto (/chamar/[numeroQuarto]) + botão físico de emergência cobrem os dois modos de acionamento exigidos em espírito pela norma (visual/manual e automático).
• Alarme visual e sonoro nos dashboards (useAlarmeSonoro, ChamadoCard com destaque visual para chamados urgentes/escalados).
• Registro de hora de chamada, hora de atendimento e hora de finalização (Chamado.criadoEm/atendidoEm/finalizadoEm) para auditoria de resposta.

Pendência: o hardware IoT (firmware ESP32 em firmware/esp32-botao-emergencia/) é um protótipo, não um dispositivo médico/predial certificado — ver "Homologação ANATEL" abaixo antes de qualquer instalação real.

NBR 9050 (Acessibilidade)

Norma: exige alarme audiovisual acionável em banheiros/quartos acessíveis.

Controle implementado:

• Botão físico de emergência com feedback local (LED + buzzer) além do alarme no dashboard central.
• Interface (/chamar/[numeroQuarto]) com alvos de toque grandes (≥44px), alto contraste, textos claros — ver docs/documentacao-tecnica.md seção de acessibilidade (WCAG 2.1) para os detalhes técnicos.

Pendência: a instalação física do botão/cordão (altura, alcance, localização) em banheiros/quartos acessíveis é responsabilidade da equipe de infraestrutura predial no momento da instalação, não algo que o software controla.

CFM — Resolução 1.821/2007 (Guarda e auditoria de prontuário eletrônico)

Norma: exige guarda permanente e log de acesso para prontuário eletrônico.

Controle implementado: este sistema não é um prontuário eletrônico (não armazena dados clínicos), mas aplica o mesmo padrão de auditoria imutável por analogia, já que registra atendimento a pacientes:

• EventoAuditoria é a trilha de auditoria: toda transição de um chamado (criado, atendido, finalizado, escalado, de-escalado, cancelado) gera um registro, escrito exclusivamente por src/lib/chamados/auditoria.ts#registrarEvento (único ponto de escrita, sempre INSERT).
• Aplicado a nível de banco, não só de convenção de código: a migração prisma/migrations/20260813000001_lockdown_auditoria/migration.sql revoga UPDATE/DELETE em EventoAuditoria da role de runtime do app (chamados_app). Mesmo um bug ou comprometimento da aplicação não consegue alterar/apagar um evento já gravado — só a role de migração (chamados_migrate, usada apenas por humanos rodando prisma migrate, nunca pelo processo do app em produção) tem esse privilégio.
• Nenhuma expiração/limpeza automática de EventoAuditoria.

LGPD (Lei Geral de Proteção de Dados)

Papéis: a Unimed Norte Fluminense é controladora dos dados tratados por este sistema; a equipe/fornecedor que opera a infraestrutura (se terceirizada) seria operadora.

Dados pessoais tratados: apenas o necessário para o fluxo de atendimento — número do quarto (não identifica o paciente por si só), nome de usuário e papel dos funcionários que atendem os chamados. Não há coleta de nome, CPF, prontuário ou qualquer outro dado pessoal do paciente.

Controles implementados:

• Minimização de dados: só o número do quarto identifica a origem do chamado, nunca o paciente.
• Controle de acesso por papel (RBAC): middleware.ts garante que cada setor (ENFERMARIA/COPA/ROUPARIA) só acessa o próprio dashboard; SUPERVISOR vê todos. Reforçado nas rotas de API por src/lib/chamados/acesso.ts#papelPodeAgirNoTipo.
• Senhas com hash (bcryptjs, nunca texto puro), nunca logadas.
• Criptografia em trânsito: HTTPS obrigatório em produção via proxy reverso Caddy (deploy/Caddyfile), com HSTS habilitado.
• Criptografia em repouso: depende da configuração de disco do servidor/volume do Postgres (responsabilidade de infraestrutura — ver docs/arquitetura.md); recomenda-se disco criptografado na VM/host de produção.
• Direito de acesso/retificação: como não há dados pessoais de pacientes armazenados, não há prontuário de paciente para acesso/portabilidade dentro deste sistema. Dados de funcionários (Usuario) podem ser consultados/corrigidos via acesso direto ao banco pela equipe de TI (não há tela de autoatendimento — volume de usuários é pequeno o suficiente para não justificar isso agora).

Boas práticas de auditoria hospitalar

• Relatórios gerenciais (/dashboard/supervisor/relatorios): chamados por setor, tempo médio de resposta, pendentes, % dentro do SLA configurado.
• Escalonamento automático (src/lib/escalonamento/job.ts): chamados que ultrapassam o limite do próprio tipo são sinalizados ao supervisor automaticamente — nenhum chamado "morre" por estação vazia.
• Ver docs/plano-de-backup-e-recuperacao.md para a política de backup que protege a integridade histórica dos dados de auditoria.

Resumo de pendências antes de operar com pacientes reais

1. Homologação ANATEL de qualquer hardware IoT de rádio instalado fisicamente (o firmware atual é protótipo — ver firmware/esp32-botao-emergencia/README.md).
2. Validação jurídica/compliance formal deste documento pela Unimed NF.
3. Teste de carga e revisão de segurança formais (não incluídos nesta reconstrução — ver docs/documentacao-tecnica.md).
4. Confirmar criptografia em repouso do volume do banco de dados em produção (depende do provedor/infra escolhido).