# 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).