Padrões de Conformidade de PHI/PII em Saúde

Padrões para proteger dados de pacientes, dados de médicos e dados financeiros em aplicações de saúde. Aplicável a HIPAA (EUA), DISHA (Índia), GDPR (UE) e proteção geral de dados em saúde.

Quando Usar

• Construir qualquer funcionalidade que toque em registros de pacientes
• Implementar controle de acesso ou autenticação para sistemas clínicos
• Projetar esquemas de banco de dados para dados de saúde
• Construir APIs que retornam dados de pacientes ou médicos
• Implementar trilhas de auditoria ou logs
• Revisar código em busca de vulnerabilidades de exposição de dados
• Configurar Segurança em Nível de Linha (RLS) para sistemas de saúde multi-inquilino

Como Funciona

A proteção de dados em saúde opera em três camadas: classificação (o que é sensível), controle de acesso (quem pode ver) e auditoria (quem viu).

Classificação de Dados

PHI (Informações de Saúde Protegidas) — quaisquer dados que possam identificar um paciente E se relacionem à sua saúde: nome do paciente, data de nascimento, endereço, telefone, e-mail, números de identificação nacional (SSN, Aadhaar, número NHS), números de registro médico, diagnósticos, medicamentos, resultados de exames, imagens, detalhes de apólices de seguro e sinistros, registros de consultas e internações, ou qualquer combinação dos itens acima.

PII (Dados não sensíveis ao paciente) em sistemas de saúde: detalhes pessoais de médicos/funcionários, estruturas de honorários médicos e valores de pagamento, salário de funcionários e detalhes bancários, informações de pagamento de fornecedores.

Controle de Acesso: Segurança em Nível de Linha

ALTER TABLE patients ENABLE ROW LEVEL SECURITY;

-- Scope access by facility
CREATE POLICY "staff_read_own_facility"
  ON patients FOR SELECT TO authenticated
  USING (facility_id IN (
    SELECT facility_id FROM staff_assignments
    WHERE user_id = auth.uid() AND role IN ('doctor','nurse','lab_tech','admin')
  ));

-- Audit log: insert-only (tamper-proof)
CREATE POLICY "audit_insert_only" ON audit_log FOR INSERT
  TO authenticated WITH CHECK (user_id = auth.uid());
CREATE POLICY "audit_no_modify" ON audit_log FOR UPDATE USING (false);
CREATE POLICY "audit_no_delete" ON audit_log FOR DELETE USING (false);

Trilha de Auditoria

Todo acesso ou modificação de PHI deve ser registrado:

interface AuditEntry {
  timestamp: string;
  user_id: string;
  patient_id: string;
  action: 'create' | 'read' | 'update' | 'delete' | 'print' | 'export';
  resource_type: string;
  resource_id: string;
  changes?: { before: object; after: object };
  ip_address: string;
  session_id: string;
}

Vetores Comuns de Vazamento

Mensagens de erro: Nunca inclua dados de identificação de pacientes em mensagens de erro exibidas ao cliente. Registre os detalhes apenas no lado do servidor.

Saída do console: Nunca registre objetos completos de pacientes. Use IDs de registro internos opacos (UUIDs) — não números de registro médico, IDs nacionais ou nomes.

Parâmetros de URL: Nunca coloque dados de identificação de pacientes em strings de consulta ou segmentos de caminho que possam aparecer em logs ou histórico do navegador. Use apenas UUIDs opacos.

Armazenamento do navegador: Nunca armazene PHI em localStorage ou sessionStorage. Mantenha o PHI apenas na memória, busque sob demanda.

Chaves de função de serviço: Nunca use a chave service_role em código do lado do cliente. Sempre use a chave anon/publishable e deixe o RLS impor o acesso.

Logs e monitoramento: Nunca registre registros completos de pacientes. Use apenas IDs de registro opacos (não números de registro médico). Limpe os rastros de pilha antes de enviar para serviços de rastreamento de erros.

Marcação de Esquema de Banco de Dados

Marque colunas PHI/PII no nível do esquema:

COMMENT ON COLUMN patients.name IS 'PHI: patient_name';
COMMENT ON COLUMN patients.dob IS 'PHI: date_of_birth';
COMMENT ON COLUMN patients.aadhaar IS 'PHI: national_id';
COMMENT ON COLUMN doctor_payouts.amount IS 'PII: financial';

Checklist de Implantação

Antes de cada implantação:

• Sem PHI em mensagens de erro ou rastros de pilha
• Sem PHI em console.log/console.error
• Sem PHI em parâmetros de URL
• Sem PHI em armazenamento do navegador
• Sem chave service_role em código do cliente
• RLS habilitado em todas as tabelas PHI/PII
• Trilha de auditoria para todas as modificações de dados
• Tempo limite de sessão configurado
• Autenticação de API em todos os endpoints de PHI
• Isolamento de dados entre instalações verificado

Exemplos

Exemplo 1: Tratamento de Erro Seguro vs. Inseguro

// BAD — leaks PHI in error
throw new Error(`Patient ${patient.name} not found in ${patient.facility}`);

// GOOD — generic error, details logged server-side with opaque IDs only
logger.error('Patient lookup failed', { recordId: patient.id, facilityId });
throw new Error('Record not found');

…