flowchart TD
A["Bloco 1 — Ransomware e tríade CIA<br/>(10 min)"] --> B["Bloco 2 — Quatro categorias de ameaças<br/>(10 min)"]
B --> C["Bloco 3 — LGPD para dados de saúde<br/>(10 min)"]
C --> D["Bloco 4 — Padrões de interoperabilidade<br/>(10 min)"]
D --> E["Bloco 5 — Privacidade-desde-o-design<br/>(10 min)"]
E --> F["Estágio 1 — Análise CIA de incidentes<br/>(50 min)"]
F --> G["Estágio 2 — LGPD / Interoperabilidade<br/>(60 min)"]
G --> H["Estágio 3 — Design ou auditoria integrada<br/>(40 min)"]
A -.->|"Competência analítica"| F
C -.->|"Competência jurídico-prática"| G
E -.->|"Competência de design"| H
H --> I["Documento de requisitos<br/>Turma A — Módulo 14"]
H --> J["Relatório de auditoria<br/>Turma B — exercício"]
Plano de Aula — Módulo 11: Segurança da Informação em Saúde
Documento exclusivo para o professor | Módulo 11 | Formato: Teórico-Prático
Este plano de aula é o guia pedagógico completo para a condução do Módulo 11. Ele detalha a visão geral da sessão e seu posicionamento estratégico na sequência da disciplina, os objetivos de aprendizagem articulados em três competências mensuráveis, a preparação prévia do professor e dos estudantes, o sumário denso dos temas do material para revisão rápida, o roteiro dos 50 minutos de exposição dialogada dividido em cinco blocos de dez minutos, o roteiro dos 150 minutos de laboratório dividido em três estágios progressivos, as orientações específicas sobre as atividades das Turmas A e B com gabaritos comentados, e os pontos críticos de tutoria com os cinco erros conceituais mais frequentes e as estratégias de correção. Leia este documento integralmente com pelo menos dois dias de antecedência e mantenha-o acessível durante toda a sessão.
1. Visão geral do módulo
O Módulo 11 ocupa uma posição singular na arquitetura da disciplina. Ele está localizado entre dois módulos de design de startup — o Módulo 10, dedicado ao Mapa de Empatia e à Jornada do Usuário, e o Módulo 12, dedicado à Ideação (Brainstorm e Crazy 8s) —, e essa localização não é acidental. Nos módulos 9 e 10, os estudantes mergulharam profundamente nos problemas de seus usuários: conduziram entrevistas, mapearam as dores, identificaram as necessidades latentes, construíram personas e percorreram a jornada emocional do paciente ou do profissional de saúde que sua HealthTech pretende servir. No Módulo 12 eles darão um salto criativo e gerarão dezenas de ideias sobre como resolver aqueles problemas. O Módulo 11 é a pausa deliberada entre esses dois momentos — não para interromper o ímpeto criativo, mas para instalar nos estudantes um conjunto de restrições e responsabilidades que devem orientar toda a ideação subsequente.
A razão pela qual essa pausa é necessária é que o design de produtos digitais de saúde sem consciência de segurança e privacidade não é apenas tecnicamente ingênuo; é eticamente problemático. Os estudantes descobriram, no Módulo 10, que seus usuários compartilham informações profundamente sensíveis: diagnósticos de doenças estigmatizantes, histórico de saúde mental, dados de fertilidade, condições crônicas que afetam seguros e empregos. No Módulo 11 eles aprenderão que essas informações, uma vez coletadas por um produto digital, criam obrigações legais e responsabilidades éticas que o criador do produto — médico ou não — não pode ignorar. A Atividade 3 da Turma A, que pede a cada grupo que aplique os princípios de privacidade-desde-o-design ao próprio projeto de startup, é a ponte explícita entre os dois momentos: o que você aprendeu sobre seu usuário no Módulo 10 alimenta diretamente as decisões de design de privacidade que você toma agora.
O desafio pedagógico central deste módulo é reformular a percepção que os estudantes têm de segurança e privacidade. É muito provável que uma parte significativa da turma chegue ao Módulo 11 com a crença de que esses são temas para especialistas em TI ou para advogados. A segurança da informação, nessa visão, é uma camada técnica que vem depois do design, responsabilidade de um time que o estudante nunca integrará. A privacidade é um problema jurídico que a startup resolverá quando contratar um advogado de dados. Essa visão é não apenas incorreta, como é perigosa para os pacientes que o produto servirá.
O professor deve, desde os primeiros minutos da exposição, confrontar essa percepção com evidências clínicas concretas. O ataque de ransomware ao Hospital Universitário de Brasília em 2020 não foi um problema de TI: foi um evento de segurança do paciente que interrompeu cirurgias, impediu acesso a prontuários e obrigou um hospital universitário a operar por dias com registros em papel. O ataque ao NHS britânico em 2017 pelo WannaCry não apenas comprometeu dados: adiou mais de 19 mil consultas e cirurgias, afetou ao menos 81 das 236 organizações do NHS, e há evidência de que pacientes morreram por não ter recebido atendimento a tempo. A violação de confidencialidade que expõe o diagnóstico de HIV de um paciente não é um erro jurídico: é um ato com consequências sociais, profissionais e psicológicas gravíssimas para uma pessoa real. A corrupção de um resultado de exame por falha de integridade em um sistema sem validação de dados não é um bug de software: é um erro médico em potencial, com sequelas clínicas que podem incluir tratamento incorreto ou omissão de tratamento necessário.
O professor deve resistir à tentação de conduzir o Módulo 11 como uma aula de conformidade regulatória. A LGPD não é o objetivo; é o instrumento. O objetivo é que os estudantes construam HealthTechs que protejam seus usuários de forma genuína — e a LGPD, corretamente compreendida, oferece um framework de obrigações que materializa esse objetivo em requisitos concretos. Da mesma forma, a tríade CIA não é uma taxonomia acadêmica para ser decorada: é um instrumento de análise que o estudante deve ser capaz de mobilizar quando estiver projetando seu produto para perguntar, a respeito de cada tipo de dado que coletará, “o que aconteceria com meu usuário se a confidencialidade desse dado fosse violada? E se sua integridade fosse comprometida? E se ficasse inacessível num momento crítico?”
A conexão com o Módulo 10 deve ser retomada explicitamente em dois pontos: primeiro, na discussão sobre dados coletados em entrevistas de empatia — quem participou de entrevistas de pesquisa com usuários coletou dados pessoais, e esses dados já estão sob a égide da LGPD (o Módulo 10 deveria ter abordado isso, e se não abordou, o Módulo 11 é o momento de fazê-lo); segundo, no contexto das Atividades 3, que pedem um inventário dos dados que a HealthTech do grupo coletará — esse inventário é uma extensão direta do mapeamento de necessidades do usuário feito no Módulo 10.
A conexão com o Módulo 14 (Prototipação) é prospectiva e deve ser tornada explícita pelo professor: os requisitos de segurança e privacidade que os grupos identificarem neste módulo não são obstáculos ao design — são especificações de design. Quando um grupo descobre que seu produto precisará de autenticação multifatorial, de criptografia de dados em repouso, de um mecanismo de consentimento granular ou de um processo de portabilidade de dados, esses não são problemas para resolver depois; são funcionalidades para prototipar e testar. O documento de requisitos produzido na Atividade 3 da Turma A será explicitamente retomado no Módulo 14.
2. Objetivos, competências e habilidades
Objetivo central do módulo
Ao final desta sessão, o estudante deve ser capaz de identificar e classificar falhas de segurança em sistemas de informação em saúde usando a tríade CIA com articulação das consequências clínicas; determinar a base legal aplicável a cada situação de tratamento de dados de saúde segundo a LGPD, distinguindo as bases do Art. 11 com precisão suficiente para avaliar conformidade; e traduzir os princípios de privacidade-desde-o-design em decisões concretas de produto para a sua HealthTech, articulando como cada decisão de design reduz um risco real para um usuário real.
A primeira competência é analítica. Ela consiste na capacidade de decompor um incidente ou cenário de segurança em saúde usando os três pilares da tríade CIA — confidencialidade, integridade e disponibilidade —, identificar qual ou quais pilares foram violados, descrever a consequência clínica específica dessa violação para o paciente afetado, e propor a medida preventiva principal que teria impedido a violação. O indicador observável desta competência é a qualidade da análise nos exercícios do laboratório: não basta que o estudante nomeie o pilar violado corretamente; ele precisa articular por que a violação daquele pilar específico é uma ameaça à segurança do paciente — e não apenas à segurança do dado. Um estudante que escreve “a confidencialidade foi violada porque os dados foram expostos” não atingiu a competência; um estudante que escreve “a confidencialidade foi violada quando o diagnóstico de HIV foi exposto ao empregador, o que resultou na demissão do paciente e no abandono do tratamento antirretroviral” atingiu a competência.
A segunda competência é jurídico-prática. Ela consiste na capacidade de analisar uma situação concreta de tratamento de dados de saúde e determinar, com justificativa, se ela é ou não conforme à LGPD, identificando o artigo relevante e a base legal aplicável segundo o Art. 11. Essa competência não exige memorização de artigos; exige compreensão funcional das categorias. O indicador observável é a análise das situações da Atividade 2 da Turma A: um estudante que consegue distinguir por que a situação 1 é uma violação do Art. 46 (medidas de segurança inadequadas), por que a situação 5 é conforme pelo Art. 11 inciso II alínea e (obrigação legal de vigilância epidemiológica), e por que chamar a situação 4 de “consentida” é um erro (incompatibilidade de finalidade e insuficiência de anonimização) demonstra a competência em seu nível avançado.
A terceira competência é de design. Ela consiste na capacidade de mapear os dados que a HealthTech do grupo coletará, associar cada tipo de dado à base legal mais adequada sob a LGPD, aplicar pelo menos quatro princípios de privacidade-desde-o-design como decisões concretas de produto, e derivar ao menos três requisitos técnicos priorizados que o protótipo deverá satisfazer. O indicador observável é o documento produzido na Atividade 3 da Turma A: a diferença entre uma resposta de nível adequado e uma resposta de nível avançado está na especificidade. Uma resposta de nível adequado diz “o produto deve ter criptografia”. Uma resposta de nível avançado diz “os dados de diagnóstico armazenados localmente no dispositivo do profissional serão criptografados com AES-256, e a chave de criptografia não será armazenada no mesmo dispositivo, porque o modelo de ameaça inclui roubo ou perda do equipamento em ambiente hospitalar”.
3. Preparação prévia do professor e dos estudantes
Esta seção descreve a preparação necessária antes da sessão. A preparação do professor deve ser concluída com pelo menos dois dias de antecedência. A preparação dos estudantes consiste no estudo integral do material na semana anterior à aula.
Preparação do professor
O professor deve ter lido integralmente o material do módulo, as atividades da Turma A e as atividades da Turma [B] (modulos/11/11_atividades_b.html), e deve ter resolvido mentalmente cada atividade antes da sessão, identificando onde os grupos provavelmente emperrarão. Para as atividades da Turma A, o ponto mais frequente de dificuldade está na Atividade 2, especificamente nas situações 3 e 4: a situação 3 (banco de dados interno de pesquisa em oncologia) é potencialmente conforme, mas com condicionantes — a maioria dos estudantes não articulará espontaneamente a necessidade de RIPD nem a questão de minimização de dados; a situação 4 (startup de saúde mental compartilhando dados “anonimizados” com seguradora) concentra dois erros em um — a incompatibilidade de finalidade e a insuficiência da pseudoanonimização. Para as atividades da Turma B, o ponto crítico da Atividade 2 é a Integração D (wearables com API proprietária), onde os estudantes tendem a propor padrões de interoperabilidade em vez de reconhecer que a ausência de padrão aberto cria um problema jurídico sob a LGPD (dados transitando por via não auditável).
Em relação à legislação, o professor deve ter em mãos o texto dos seguintes dispositivos da LGPD, com leitura direta (não paráfrase): Art. 5º inciso XI (definição de dado pessoal sensível), Art. 8º (requisitos do consentimento), Art. 11 caput e incisos I e II com todas as alíneas (bases legais para tratamento de dados sensíveis), Art. 18 (direitos do titular), Art. 38 (relatório de impacto à proteção de dados — RIPD), Art. 41 (encarregado de dados — DPO), Art. 46 (medidas de segurança e boas práticas), e Art. 48 (comunicação de incidentes). O professor não precisa decorar esses artigos, mas precisa ser capaz de localizá-los rapidamente e de ler o texto original em voz alta quando um estudante perguntar “mas onde está escrito isso?” — porque essa pergunta surgirá, e responder com o texto original tem impacto pedagógico muito maior do que parafrasear.
Em relação às ameaças, o professor deve revisar as linhas gerais do caso WannaCry/NHS de maio de 2017: a vulnerabilidade EternalBlue no protocolo SMB do Windows, o número de organizações afetadas no NHS, os 19.494 atendimentos cancelados, a ausência de patches que já estavam disponíveis, e o papel do NHS Digital que identificou apenas uma semana antes do ataque que uma parcela significativa dos sistemas não tinha as atualizações instaladas. O professor deve também rever o incidente do Hospital Universitário de Brasília em outubro de 2020, que paralisou o sistema de prontuário eletrônico por mais de duas semanas. Recomenda-se fortemente que, antes de cada edição deste módulo, o professor pesquise se houve incidentes de segurança em saúde no Brasil nos últimos doze meses — o campo de ataques a hospitais e laboratórios brasileiros tem sido ativo, e um caso recente e próximo da realidade dos estudantes tem impacto pedagógico muito superior ao de casos históricos internacionais.
Em relação à interoperabilidade, o professor deve revisar o que é o FHIR R4, o que é a RNDS (Rede Nacional de Dados em Saúde) do Ministério da Saúde brasileiro, e em que ponto está o processo de implementação da RNDS quando este módulo for ministrado — porque esse é um campo em rápida evolução e as informações do material podem estar parcialmente desatualizadas.
Preparação dos estudantes
Os estudantes devem ter estudado integralmente o material na semana anterior à aula. O material cobre sete grandes temas: introdução com cenário de abertura de ransomware, tríade CIA com exemplos clínicos, quatro categorias de ameaças ao setor de saúde, LGPD para dados de saúde com tabela de bases legais, padrões de interoperabilidade (HL7/FHIR/TISS/DICOM), boas práticas de segurança operacional, e privacidade-desde-o-design. O professor deve calibrar a exposição assumindo que uma parcela da turma fez a leitura com atenção e outra parcela leu superficialmente: a exposição não deve reproduzir o que está no texto, mas deve ativar e aprofundar o que os estudantes já leram, usando perguntas, casos e conexões que o material não explicita.
4. Sumário do material para revisão rápida
Referência densa para revisão imediata antes da exposição
Esta seção condensa os temas centrais do material em síntese densa, destinada à revisão rápida do professor na preparação imediata da aula. Não substitui a leitura integral do material, mas funciona como mapa de orientação para os 50 minutos de exposição.
Tríade CIA e suas consequências clínicas
A tríade CIA estrutura a análise de segurança da informação em saúde em três pilares interdependentes. A confidencialidade é a garantia de que um dado só é acessível às pessoas autorizadas. No contexto clínico, a violação de confidencialidade não é um incidente administrativo: quando o diagnóstico de HIV de um paciente é exposto a seu empregador, a consequência pode ser demissão, ostracismo social e abandono do tratamento. Quando o histórico psiquiátrico de um estudante de medicina vaza para a coordenação do curso, a consequência pode ser exclusão do internato. A proteção da confidencialidade em saúde tem raízes no sigilo médico hipocrático e é hoje garantida por múltiplos instrumentos jurídicos, dos quais a LGPD é o mais abrangente. Os controles principais que protegem a confidencialidade são autenticação (verificar quem é o usuário), autorização (verificar o que esse usuário tem permissão de acessar), criptografia (tornar o dado ilegível para quem não tem a chave) e auditoria (registrar quem acessou o quê e quando).
A integridade é a garantia de que um dado não foi alterado ou corrompido de forma não autorizada ou não detectada. No contexto clínico, a violação de integridade pode ser mais perigosa do que a violação de confidencialidade: um resultado de exame que foi corrompido por um bug de software pode levar a um diagnóstico incorreto ou à omissão de um diagnóstico correto. Um laudo de patologia trocado por erro de indexação pode resultar em tratamento inadequado. Uma prescrição alterada em trânsito pode causar erro de medicação. Os controles principais que protegem a integridade são hashes criptográficos (somas de verificação que detectam qualquer alteração no dado), assinaturas digitais, controles de versão, validação de entrada (que impede que dados malformados ingressem no sistema) e backup verificável.
A disponibilidade é a garantia de que um dado ou sistema está acessível quando necessário. No contexto clínico, a indisponibilidade de um prontuário eletrônico durante um atendimento de urgência pode obrigar o médico a atender sem conhecer as alergias, as comorbidades ou os medicamentos em uso do paciente. A paralisação de um sistema de administração de medicamentos pode atrasar ou impedir a administração de doses críticas. Os ataques de ransomware são o exemplo mais dramático de ataque à disponibilidade: ao criptografar os dados do sistema e exigir resgate para restaurar o acesso, eles transformam um incidente de segurança em uma emergência de cuidado. O controle principal de disponibilidade é o backup regular, testado e armazenado em local separado do sistema principal.
As quatro categorias de ameaças ao setor de saúde
O material organiza as ameaças ao setor de saúde em quatro categorias. O ransomware é o ataque mais impactante em termos de paralisação operacional: o WannaCry de maio de 2017 explorou a vulnerabilidade EternalBlue no Windows, propagou-se lateralmente pela rede do NHS e afetou 81 organizações, cancelando mais de 19 mil atendimentos; o ataque ao HUB Brasília em 2020 paralisou o sistema de prontuário eletrônico por mais de duas semanas. O vetor de entrada mais comum para ransomware em saúde é o phishing — um e-mail com link ou anexo malicioso que instala o malware quando aberto por um funcionário.
O phishing é o vetor de ataque mais frequente e mais dependente de comportamento humano. O spear phishing é a variante direcionada: o atacante pesquisa previamente o alvo (nome do chefe imediato, nome de um projeto em andamento, linguagem interna da instituição) e cria um e-mail convincente que imita uma comunicação legítima. Em ambientes hospitalares, os alvos mais frequentes são funcionários administrativos e recepcionistas, não médicos — mas as credenciais roubadas frequentemente permitem acesso ao mesmo sistema de prontuário que o médico usa. A defesa mais eficaz contra phishing não é técnica: é treinamento contínuo e cultura de desconfiança saudável diante de e-mails urgentes com links ou pedidos de credenciais.
As ameaças internas são sistematicamente subestimadas em saúde. Elas se dividem em duas categorias com perfis muito diferentes: o insider malicioso (funcionário que acessa ou vende dados por motivação financeira ou pessoal) e o insider negligente (funcionário que não age com má intenção, mas cujo comportamento descuidado cria vulnerabilidades — compartilhamento de senha, acesso a redes Wi-Fi abertas com laptop institucional, uso de dispositivo pessoal sem criptografia para armazenar dados de pacientes). Estudos do setor indicam que ameaças internas representam entre 30% e 50% dos incidentes de dados em saúde, mas recebem proporcionalmente menos atenção do que ataques externos.
Os ataques a dispositivos de IoMT (Internet of Medical Things) exploram vulnerabilidades em equipamentos médicos conectados à rede — monitores de ECG, bombas de infusão, equipamentos de imagem, dispositivos de suporte à vida. Muitos desses dispositivos operam com sistemas operacionais sem suporte (Windows XP era comum em equipamentos médicos até meados da década de 2010) e não foram projetados com segurança em mente; a premissa de design era que estariam em redes físicas isoladas, premissa que a conectividade hospitalar moderna tornou obsoleta. A vulnerabilidade dos dispositivos ao final do ciclo de vida é o ponto crítico: fabricantes param de emitir patches de segurança para equipamentos mais antigos, mas os hospitais continuam operando esses equipamentos porque a substituição é cara e o processo de recertificação é longo.
LGPD para dados de saúde: os artigos essenciais
O Art. 5º inciso XI da LGPD define dado pessoal sensível como “dado pessoal sobre origem racial ou étnica, convicção religiosa, opinião política, filiação a sindicato ou a organização de caráter religioso, filosófico ou político, dado referente à saúde ou à vida sexual, dado genético ou biométrico, quando vinculado a uma pessoa natural.” Dados de saúde são, portanto, dados sensíveis por definição, o que aciona um regime de proteção mais rigoroso do que o aplicável a dados pessoais comuns.
O Art. 11 estabelece as bases legais para o tratamento de dados sensíveis. Para o contexto de startups de saúde, as bases mais relevantes são: o consentimento do titular, específico e destacado (inciso I), adequado para consultas individuais voluntárias; a tutela da saúde, exclusivamente por profissional de saúde, serviço de saúde ou autoridade sanitária (inciso II alínea f), que não pode ser invocada por uma startup cujos funcionários não são profissionais de saúde nem ela é um serviço de saúde nos termos legais; e a realização de estudos por órgão de pesquisa, garantido quando possível o anonimato (inciso II alínea c), aplicável a plataformas de pesquisa com aprovação ética. A base mais comum que estudantes invocam incorretamente é o consentimento: o consentimento do Art. 11 tem requisitos estritos — deve ser específico (não genérico), destacado dos demais termos, informado (o titular deve entender exatamente para que seus dados serão usados) e, por força do Art. 8º, facilmente revogável. Um termo de uso genérico que menciona “uso de dados para melhoria dos serviços” não constitui consentimento válido.
O Art. 18 garante ao titular de dados o direito de confirmação de existência de tratamento, acesso aos dados, correção, anonimização/bloqueio/eliminação, portabilidade, informação sobre compartilhamento, revogação do consentimento e revisão de decisões automatizadas. Em uma startup de saúde, cada um desses direitos precisa ser operacionalizável — o produto precisa ter uma interface ou mecanismo que permita ao paciente exercer cada um deles.
Os Arts. 38 e 41 estabelecem obrigações institucionais: o Art. 38 exige o Relatório de Impacto à Proteção de Dados (RIPD) quando o tratamento é de dados sensíveis ou pode gerar riscos a liberdades individuais; o Art. 41 prevê a nomeação de um encarregado de dados (Data Protection Officer — DPO), obrigatório para controladores de dados sensíveis de larga escala. O Art. 46 exige que o controlador adote medidas técnicas e administrativas aptas a proteger os dados pessoais de acessos não autorizados e de situações acidentais ou ilícitas. O Art. 48 obriga o controlador a comunicar à ANPD e ao titular a ocorrência de incidente de segurança que possa acarretar risco ou dano relevante, no prazo de até dois dias úteis.
Padrões de interoperabilidade em saúde
O HL7 v2 é o padrão de troca de mensagens clínicas mais disseminado no mundo, presente na maioria dos sistemas hospitalares legados. Opera com mensagens em texto estruturado (segmentos como MSH, PID, OBR), funciona bem para integrações ponto a ponto em ambientes controlados, mas é difícil de estender e não foi projetado para APIs web modernas. O FHIR R4 (Fast Healthcare Interoperability Resources) é o padrão de nova geração do HL7, baseado em recursos JSON/XML acessíveis via API REST, que se tornou o padrão estratégico do Ministério da Saúde brasileiro para a RNDS (Rede Nacional de Dados em Saúde). A RNDS é a infraestrutura nacional de interoperabilidade para compartilhamento de dados de imunização, atendimento ambulatorial e prescrições. O TISS (Troca de Informações em Saúde Suplementar) é o padrão da ANS para a comunicação entre operadoras de planos de saúde e prestadores, exigido para autorização de procedimentos e faturamento. O DICOM (Digital Imaging and Communications in Medicine) é o padrão universal para imagens médicas (radiografias, tomografias, ressonâncias), cobrindo tanto o formato do arquivo quanto o protocolo de transmissão.
Privacidade-desde-o-design e os sete princípios de Cavoukian
O framework de privacidade-desde-o-design, formalizado por Ann Cavoukian, propõe que a privacidade deve ser incorporada no design de sistemas desde o início, não adicionada depois como uma camada de conformidade. Os sete princípios são: (1) proativo, não reativo — antecipar e prevenir violações, não remediá-las; (2) privacidade como padrão — a configuração padrão do sistema deve ser a mais privativa possível; (3) privacidade incorporada no design — não é uma funcionalidade adicional, é parte da arquitetura; (4) funcionalidade plena — a privacidade não compromete a funcionalidade; (5) segurança de ponta a ponta — os dados são protegidos durante todo o ciclo de vida; (6) visibilidade e transparência — o titular sabe como seus dados são usados; (7) respeito pelo usuário — o sistema é projetado em torno dos interesses do titular. No contexto da LGPD, o Art. 46 §2º menciona explicitamente a adoção de medidas desde a fase de concepção do produto como boa prática.
5. Roteiro da exposição (50 minutos — 5 blocos de 10 minutos)
Estrutura da exposição dialogada
A exposição está estruturada em cinco blocos progressivos de dez minutos cada. Os blocos são integrados: cada um pressupõe o anterior e prepara o seguinte. O professor não deve se prender rigidamente ao tempo de cada bloco, mas deve completar os cinco antes de encerrar a exposição, ajustando a profundidade conforme a resposta da turma. O tom ao longo de toda a exposição deve ser o de análise crítica de um problema clínico real, não de revisão de política de conformidade.
Bloco 1 (10 min) — Abertura: ransomware mata pacientes
O professor inicia com uma descrição factual do ataque WannaCry ao NHS em maio de 2017 — não como curiosidade de tecnologia, mas como evento de segurança do paciente. Os números devem ser apresentados de forma objetiva: 81 das 236 organizações do NHS afetadas; 19.494 atendimentos cancelados; cirurgias adiadas; ambulâncias desviadas para unidades não afetadas; UTIs que voltaram a usar papel por dias. O professor então faz a pergunta direta à turma: “Isso é um problema de TI ou um problema clínico?”
Ao colher as respostas, o professor deve usar o que surgir para construir a tese central da exposição: a segurança da informação em saúde é uma questão de segurança do paciente, da mesma forma que esterilização de instrumentos cirúrgicos ou controle de infecção hospitalar. O vetor de entrada do WannaCry no NHS foi, em muitos casos, a ausência de patches de segurança que já estavam disponíveis — uma falha de processo, não de tecnologia. Isso significa que o conhecimento que os estudantes estão prestes a adquirir poderia, no limite, evitar que isso aconteça nas instituições onde trabalharão.
Após essa âncora, o professor introduz a tríade CIA como instrumento de análise, não como taxonomia. Para cada pilar, um exemplo clínico preciso: confidencialidade — o diagnóstico de HIV de um paciente exposto ao seu empregador; integridade — um resultado de exame corrompido por um bug de indexação que levou a um tratamento incorreto; disponibilidade — um prontuário eletrônico inacessível durante o atendimento de urgência de um paciente sem documento de identificação. O professor deve deixar claro que esses três pilares coexistem em tensão: maximizar a disponibilidade (deixar o sistema aberto para todo o hospital acessar) frequentemente compromete a confidencialidade; maximizar a confidencialidade (criptografar tudo com chaves complexas) pode comprometer a disponibilidade em emergências. A arte da segurança está em encontrar o equilíbrio adequado para cada contexto.
O bloco termina com a conexão explícita ao projeto dos estudantes: “Cada grupo já mapeou os dados que coletará de seus usuários no Módulo 10. Quais desses dados têm o maior impacto para o seu usuário se a confidencialidade for violada? Se a integridade for comprometida? Se o dado ficar indisponível no momento errado?” Esta pergunta não precisa de resposta imediata — ela funciona como gancho para a Atividade 3 da Turma A no laboratório.
Bloco 2 (10 min) — As quatro categorias de ameaças: o problema é humano
O professor apresenta as quatro categorias de ameaças — ransomware, phishing, ameaças internas e ataques a dispositivos de IoMT —, com ênfase deliberada nos dois vetores mais subestimados: phishing e ameaças internas.
Para o phishing, o professor deve ter preparado dois exemplos de e-mails de spear phishing que visaram organizações de saúde. Esses exemplos podem ser baseados nos que aparecem no material ou em casos documentados publicamente. A ação pedagógica é pedir à turma que identifique, nos exemplos exibidos, os marcadores de legitimidade falsa: o nome de domínio ligeiramente incorreto, o tom de urgência artificial, o pedido de credenciais que nenhuma organização legítima faria por e-mail, a inconsistência entre o nome do remetente exibido e o endereço real. O professor deve usar este exercício para desmistificar a ideia de que cair em phishing é sinal de ignorância tecnológica: os ataques de spear phishing bem elaborados enganam profissionais experientes, e a defesa eficaz começa por reconhecer que qualquer pessoa pode ser alvo.
A lição-chave do bloco é enunciada de forma direta: a maioria dos ataques bem-sucedidos a sistemas de saúde não começa por uma vulnerabilidade técnica sofisticada; começa por um comportamento humano — um clique num link suspeito, uma senha reutilizada, um dispositivo pessoal conectado à rede hospitalar sem autorização, um funcionário frustrado com a instituição que decide vender dados de pacientes. Controles técnicos como firewalls e antivírus interceptam ataques automáticos, mas não são suficientes contra ataques que passam por dentro do perímetro humano. Isso significa que a formação em segurança da informação é parte da formação clínica, não um complemento opcional.
Para os dispositivos de IoMT, o professor apresenta o cenário do material: equipamentos médicos com sistemas operacionais sem suporte, conectados à rede hospitalar, que se tornam pontos de entrada para atacantes que saltam deles para o restante da rede. O ponto crítico é o ciclo de vida do dispositivo: o fabricante garante patches de segurança por um período limitado, depois o qual o dispositivo continua operando clinicamente, mas torna-se um risco de segurança crescente. A decisão de continuar usando um equipamento cujo sistema operacional não recebe mais atualizações é, nesse sentido, uma decisão de gestão de risco clínico — não apenas de gestão de TI.
Bloco 3 (10 min) — LGPD para dados de saúde: não é memorização, é raciocínio jurídico
O professor inicia com uma declaração explícita de expectativa: “Não vou pedir que vocês memorizem artigos. Vou pedir que vocês sejam capazes de responder, diante de uma situação concreta, se ela está ou não em conformidade — e por quê.” Essa declaração tem impacto duplo: reduz a ansiedade dos estudantes que percebem a LGPD como uma lista interminável de artigos, e sinaliza o nível de análise esperado.
O professor apresenta três situações clínicas concretas e pede à turma que classifique, antes de qualquer explicação:
A situação 1 é a mais simples: “Uma médica fotografa o resultado de exame de um paciente com o celular pessoal e envia pelo WhatsApp para a mãe do paciente, que pediu o resultado porque o filho está em outra cidade.” O professor pergunta: “Há violação da LGPD aqui? Qual artigo seria mais relevante?” A situação ativa o conhecimento prévio (a maioria dos estudantes intuirá que algo está errado) e permite ao professor introduzir o Art. 46 (medidas de segurança inadequadas: canal não criptografado, dispositivo pessoal sem política de segurança) e o Art. 11 (o consentimento do paciente não está documentado para esse canal específico).
A situação 2 é mais complexa: “Uma startup de saúde coleta dados de frequência cardíaca, sono e atividade física de usuários pelo aplicativo. Os dados são compartilhados com uma seguradora de saúde parceira para cálculo de prêmios. O termo de uso menciona ‘compartilhamento com parceiros’.” O professor pergunta: “Isso é consentimento válido segundo a LGPD?” A maioria dos estudantes tenderá a dizer que sim, porque “o usuário concordou com o termo”. O professor usa a resposta para introduzir os requisitos do Art. 8º (consentimento específico, não genérico) e o princípio de finalidade (os dados não podem ser usados para finalidade incompatível com a que motivou a coleta).
A situação 3 é a que conecta ao projeto dos grupos: “O grupo X está desenvolvendo um aplicativo para médicos de família documentarem sintomas de pacientes de populações rurais sem prontuário eletrônico. Os dados são armazenados na nuvem sem criptografia. Qual é o risco jurídico?” O professor usa a resposta para introduzir o Art. 46 (medidas de segurança aptas a proteger os dados) e conectar à discussão de boas práticas do bloco 5.
Após as três situações, o professor apresenta a tabela de bases legais do Art. 11 em forma comentada, enfatizando as distinções que os estudantes precisarão mobilizar nas atividades: a diferença entre consentimento (Art. 11 I) e tutela da saúde por profissional de saúde (Art. 11 II f), e por que uma startup tecnológica sem profissionais de saúde no quadro não pode invocar a segunda base; a distinção entre pesquisa (Art. 11 II c) e uso comercial; e a base de obrigação legal para vigilância epidemiológica (Art. 11 II e), que é a mais frequentemente ignorada pelos estudantes.
Bloco 4 (10 min) — Interoperabilidade: qual padrão você usaria?
O professor apresenta um cenário simples: uma startup de saúde chamada “MedTrack” que precisa integrar três sistemas — um laboratório parceiro que usa HL7 v2, um hospital parceiro que tem prontuário eletrônico certificado FHIR R4, e uma operadora de plano de saúde para autorização de procedimentos. O professor pergunta à turma: “Qual padrão você usaria para cada integração? Por quê?”
A pergunta é deliberadamente simples para que os estudantes que estudaram o material consigam responder — HL7 v2 para o laboratório legado, FHIR R4 para o hospital moderno, TISS para a operadora. Mas o professor deve ir além das respostas corretas e introduzir as implicações que o material explora: cada ponto de integração é também um ponto de risco sob a LGPD, porque dados de saúde transitando entre sistemas são dados sendo processados, e cada processamento precisa de base legal, de medidas de segurança (Art. 46) e, se significativo, de RIPD (Art. 38). O estudante que entende que “integrar via HL7 v2 com o laboratório” é ao mesmo tempo uma decisão técnica e uma decisão de privacidade está pensando como um designer responsável de produto de saúde.
O professor apresenta brevemente o FHIR e a RNDS: o FHIR R4 é o padrão estratégico do Ministério da Saúde para a RNDS, que é a infraestrutura nacional de interoperabilidade. Para startups que pretendem se integrar ao sistema público de saúde ou compartilhar dados com a rede pública, a conformidade com FHIR não é opcional — é o requisito de entrada. Isso deve ser apresentado não como ônus, mas como oportunidade: uma startup que nasce conforme ao FHIR tem um mercado potencial muito maior do que uma que usa formatos proprietários.
O bloco termina com a conexão ao DICOM para o subconjunto de grupos cujas startups lidam com imagens médicas: se o produto coleta, processa ou exibe imagens de radiologia, dermatologia ou oftalmologia, o padrão DICOM é a língua franca que o equipamento de origem usa. Não conformar-se ao DICOM não é apenas uma questão de interoperabilidade; é uma questão de segurança do dado — exportar uma imagem de TC para fora do sistema em formato proprietário pode gerar perda de metadados clínicos que estão embutidos no arquivo DICOM.
Bloco 5 (10 min) — Privacidade-desde-o-design para a startup de cada grupo
Este bloco tem a função de fazer a transição da exposição para o laboratório e de tornar explícita a conexão entre o conteúdo do módulo e o projeto de cada grupo. O professor pede que um representante de cada grupo (ou, se a turma for grande, de três ou quatro grupos sorteados) enuncia em uma frase o tipo de dado de saúde mais sensível que o produto do grupo coletará ou processará.
Para cada resposta, o professor percorre duas perguntas de design de privacidade: “Vocês realmente precisam desse dado na forma mais granular que estão imaginando, ou seria possível atingir o mesmo objetivo com um dado menos sensível ou menos identificável?” (princípio de minimização de dados), e “Qual é a configuração padrão do seu produto em relação a esse dado — por padrão, quem pode ver isso?” (princípio de privacidade como padrão). Essas duas perguntas, aplicadas ao dado que o grupo mencionou, devem ser suficientes para mostrar que privacidade-desde-o-design não é uma lista de princípios abstratos: é um conjunto de perguntas concretas que o designer faz a respeito de cada dado, de cada funcionalidade, de cada ponto de integração do produto.
O professor anuncia a estrutura do laboratório: três estágios progressivos, com as Turmas A e B trabalhando em exercícios diferentes mas complementares. Para a Turma A, o estágio final (Atividade 3) é sobre o projeto de startup de cada grupo — o resultado será um documento de requisitos de segurança e privacidade que servirá de insumo para o Módulo 14. Para a Turma B, o estágio final é uma auditoria de segurança e conformidade da startup fictícia “PsychConnect”. O professor deve deixar claro que não há versão “fácil” ou “difícil” entre as turmas — há dois tipos diferentes de competência sendo exercitados.
6. Roteiro do laboratório (150 minutos — 3 estágios)
Roteiro dos 150 minutos de laboratório de informática
O laboratório está estruturado em três estágios progressivos. O primeiro estágio desenvolve a competência analítica (CIA), o segundo desenvolve a competência jurídico-prática (LGPD ou interoperabilidade) e o terceiro integra todas as competências em um exercício de design ou de auditoria. Os três estágios são independentes no sentido de que cada um pode ser iniciado mesmo que o grupo não tenha completado o anterior — mas são progressivos no sentido de que o terceiro estágio exige as competências construídas nos dois primeiros. O professor deve garantir que todos os grupos transitem para o terceiro estágio até, no máximo, os 110 minutos.
Estágio 1 — Análise de incidentes (0 a 50 min)
Turma A — Atividade 1 (CIA em três incidentes de saúde): Os grupos analisam três incidentes clínicos de segurança da informação — venda de dados por funcionário de laboratório, troca de resultados de exame por bug de software, e ataque de ransomware a um sistema regional de saúde — e identificam qual pilar da tríade CIA foi violado, descrevem a consequência clínica e propõem a medida preventiva principal.
Durante a circulação pelo laboratório neste estágio, o professor deve verificar especificamente se os grupos estão apenas nomeando o pilar violado ou se estão articulando a consequência clínica. Um grupo que escreve “o incidente 1 violou a confidencialidade” sem descrever o impacto sobre o paciente cujos dados foram vendidos não completou o exercício. O professor deve fazer a pergunta de aprofundamento: “E para o paciente, especificamente, o que isso significou? O que aconteceu com a vida daquela pessoa porque o dado ficou exposto?” Essa pergunta, feita com consistência, instala o hábito de pensar em consequências para pessoas reais, não em violações abstratas de pilares.
Para a medida preventiva, o erro mais comum é propor medidas genéricas (“implementar política de segurança”, “treinar funcionários”). O professor deve redirecionar para a especificidade: “Que medida específica, se estivesse implementada antes do incidente, o teria impedido ou detectado imediatamente? No caso do funcionário que vendeu dados: como o sistema poderia ter detectado que aquele usuário estava acessando registros fora de seu padrão de trabalho?” A resposta esperada inclui monitoramento de acesso e alertas de comportamento anômalo (SIEM — Security Information and Event Management), que o material discute na seção de boas práticas.
Turma B — Atividade 1 (Anatomia de dois ataques): Os grupos analisam dois cenários de ataque em detalhe — um spear phishing com keylogger e roubo de credenciais em hospital, e um ataque a dispositivos de ECG via Wi-Fi em clínica de cardiologia —, identificando a sequência de etapas do ataque (vetor inicial, propagação, comprometimento), os controles que falharam e os controles que teriam interrompido a cadeia de ataque.
Para o cenário A (spear phishing), o ponto crítico é que o MFA (autenticação multifatorial) teria interrompido o ataque mesmo após a captura das credenciais. O atacante que roba um nome de usuário e uma senha não consegue acessar o sistema se o segundo fator (um código enviado ao celular do usuário real) for exigido. O professor deve garantir que os grupos entendam esse ponto: a proteção não está apenas em evitar que as credenciais sejam roubadas, mas em tornar as credenciais roubadas inúteis sozinhas. “O que aconteceria se o hospital tivesse MFA implementado?” é a pergunta de aprofundamento adequada para grupos que completaram a análise superficial.
Para o cenário B (IoMT), o ponto crítico é a segmentação de rede: se os dispositivos de ECG estivessem em uma VLAN isolada (rede virtual separada) sem roteamento direto para o prontuário eletrônico, o comprometimento dos dispositivos não teria resultado em acesso aos dados de pacientes. O professor deve garantir que os grupos articulem essa distinção entre comprometer o dispositivo (que pode ser clinicamente inaceitável por razões de segurança do paciente) e comprometer os dados de prontuário (que é o objetivo do atacante, não o acidente do ataque).
Estágio 2 — Análise jurídica e de interoperabilidade (50 a 110 min)
Turma A — Atividade 2 (LGPD: conformidade de cinco situações médicas): Os grupos analisam cinco situações médicas concretas e determinam se cada uma está ou não em conformidade com a LGPD, identificando o artigo e a base legal relevantes.
Este é o estágio de maior densidade jurídica do módulo, e o professor deve prever mais intervenções aqui do que em qualquer outro estágio. O erro mais frequente e mais importante a corrigir é tratar toda situação como solucionável por consentimento. O professor deve fazer a pergunta de sondagem: “Você está dizendo que a situação X é conforme porque o paciente consentiu. Mas o que exatamente o paciente consentiu? Onde está documentado esse consentimento? Ele inclui especificamente essa finalidade de uso?” Na maioria dos casos, a resposta revelará que o estudante estava presumindo um consentimento que não existe ou que não atende aos requisitos do Art. 8º.
Um tutorial específico útil para este estágio é pedir ao grupo que, para cada situação, preencha mentalmente a seguinte estrutura antes de escrever a resposta: (1) Que dado foi tratado? É um dado sensível de saúde? (2) Qual é a finalidade do tratamento? (3) Existe base legal expressa para esse tratamento nessa finalidade específica? (4) As medidas de segurança adotadas são adequadas para dados sensíveis? Se o grupo consegue responder a estas quatro perguntas para cada situação, a análise de conformidade emerge naturalmente.
Turma B — Atividade 2 (Interoperabilidade: padrões para a startup MedTrack): Os grupos analisam quatro integrações de uma startup de saúde e determinam qual padrão de interoperabilidade seria mais adequado para cada uma, com justificativa técnica e análise das implicações para a LGPD.
O erro mais comum aqui, conforme antecipado na seção de preparação, é não abordar as implicações da LGPD para cada integração. O professor deve redirecionar: “Você escolheu FHIR R4 para a integração com o prontuário do hospital. Muito bem. Mas quando os dados de seus pacientes transitam para o sistema do hospital via essa API, quem é o controlador dos dados? Quem é o operador? Existe um contrato de processamento de dados entre as duas empresas, como exige o Art. 39 da LGPD?” A maioria dos estudantes não terá pensado nessa dimensão, e a pergunta abre um campo de análise que o exercício explora progressivamente.
Para a Integração D (wearables com API proprietária), o professor deve resistir à tentação de dar a resposta. A situação não tem um padrão “correto” a escolher porque o problema é justamente a ausência de padrão. O que o exercício avalia é se o grupo consegue identificar que a escolha real é entre (a) construir um middleware proprietário (com custo, com riscos de manutenção e com necessidade de auditoria LGPD do middleware), (b) negociar acesso à API com o fabricante do wearable sob contrato (que também precisa de análise LGPD), ou (c) substituir o wearable proprietário por um com suporte a padrões abertos. Grupos que escolhem uma das três opções com justificativa consistente chegaram ao nível esperado do exercício.
Estágio 3 — Design de privacidade e auditoria integrada (110 a 150 min)
Turma A — Atividade 3 (Privacidade-desde-o-design para a startup do grupo): Cada grupo aplica o framework de privacidade-desde-o-design ao próprio projeto de startup, produzindo um mapeamento de dados, a base legal aplicável a cada tipo de dado, pelo menos quatro decisões concretas de design baseadas nos princípios de Cavoukian, e três requisitos técnicos priorizados.
A função do professor neste estágio é garantir que os grupos não produzam respostas genéricas. A pergunta de aprofundamento mais eficaz é: “Você escreveu que o produto vai implementar criptografia. Criptografia de quê? Em trânsito, em repouso, ou os dois? Nos servidores, no dispositivo do usuário, ou nos dois? Para todos os dados ou apenas para os mais sensíveis?” Cada vez que o professor faz essa pergunta e o grupo não tem a resposta, ele está revelando uma lacuna de especificação que o grupo precisará endereçar no Módulo 14 — e é muito melhor descobrir essa lacuna agora, no nível conceitual, do que durante a prototipação.
O professor deve também verificar se o mapeamento de dados é realista. Grupos que listam apenas “dados de saúde do paciente” como uma categoria única não fizeram o exercício: um aplicativo de saúde coleta muitos tipos de dado diferentes (identificação, histórico clínico, dados de uso do aplicativo, localização se aplicável, dados de dispositivos conectados), e cada tipo tem um perfil de sensibilidade, uma base legal e uma estratégia de proteção diferentes. O professor deve perguntar: “Que dados especificamente o aplicativo coleta quando um usuário cadastra um novo paciente? E quando registra uma consulta? E quando o paciente usa a funcionalidade X que vocês imaginaram? Lista cada tipo de dado.”
O documento produzido neste estágio deve ser guardado pelo grupo: ele será o ponto de partida explícito da seção de segurança e privacidade do protótipo no Módulo 14. O professor deve anunciar isso ao início do estágio, não ao final — saber que o documento terá uso concreto aumenta a qualidade do que os grupos produzem.
Turma B — Atividade 3 (Auditoria de segurança e LGPD da PsychConnect): Os grupos auditam uma startup fictícia de telepsiquiatria chamada PsychConnect, identificando pelo menos quatro vulnerabilidades ou não conformidades, classificando cada uma pela tríade CIA e pelos artigos da LGPD relevantes, e propondo três ações prioritárias com justificativa baseada em risco e impacto.
A função do professor neste estágio é garantir que os grupos priorizem em vez de apenas listar. Uma auditoria que identifica 12 problemas sem hierarquizá-los é, na prática, inútil para o gestor que precisa decidir onde alocar recursos limitados. O professor deve perguntar: “Você identificou seis problemas. Se a PsychConnect só tivesse budget para resolver três deles neste trimestre, quais você escolheria? Por quê? Qual o raciocínio que prioriza um problema sobre outro?” A resposta esperada combina dois eixos: probabilidade de ocorrência e severidade do impacto (para o paciente, para a conformidade legal, para a continuidade do negócio).
O ponto mais rico da auditoria é a ausência de MFA combinada com ausência de criptografia em repouso em uma plataforma de telepsiquiatria: a combinação dessas duas lacunas significa que um atacante que obtém as credenciais de um terapeuta tem acesso irrestrito a transcrições de sessões de psicoterapia, diagnósticos psiquiátricos e notas de evolução — que são dados de saúde sensíveis e, dependendo do conteúdo, podem revelar também situações de violência doméstica, abuso de substâncias e outras informações que o paciente não divulgou nem aos familiares. O impacto de uma violação nesse contexto é ordens de magnitude maior do que na maioria dos tipos de dados de saúde. O professor deve usar esse ponto para conectar a análise técnica à consequência humana: não são “dados de sessão”, são as confissões mais íntimas de uma pessoa vulnerável que procurou ajuda.
7. Orientações sobre as atividades
Esta seção fornece ao professor os gabaritos comentados e as orientações de tutoria específicas para cada atividade das duas turmas. Os gabaritos não são respostas para serem distribuídas aos estudantes; são guias para o professor avaliar a qualidade das respostas e conduzir a discussão plenária ao final do laboratório.
Turma A — Atividade 1: CIA em três incidentes de saúde
O incidente 1 (venda de dados de pacientes por funcionário de laboratório) é uma violação de confidencialidade. A classificação correta é o piso: o teto da resposta inclui a articulação de que os dados vendidos incluíam diagnósticos de doenças que afetam o emprego (como tuberculose, HIV, hepatite), que a exposição a seguradoras ou empregadores pode resultar em demissão, recusa de cobertura ou discriminação, e que a medida preventiva é uma combinação de controle de acesso por mínimo privilégio (o funcionário de laboratório só deveria ter acesso aos registros dos pacientes cujos exames está ativamente processando) com monitoramento de comportamento anômalo (um funcionário que acessa centenas de registros fora do seu padrão de trabalho deve gerar um alerta automático). O professor deve questionar grupos que propõem “treinamento de ética” como medida preventiva principal: treinamento é necessário, mas insuficiente sem controles técnicos que limitem o acesso e detectem abuso.
O incidente 2 (bug de software que causa troca de resultados de exame entre pacientes) é uma violação de integridade. A articulação esperada é que a consequência clínica pode variar de um tratamento desnecessário e seus efeitos adversos (se o resultado trocado indicar uma doença que o paciente não tem) a omissão de diagnóstico e tratamento (se o resultado real indicar doença mas o resultado exibido ao médico for normal). A medida preventiva é hashing criptográfico de cada resultado no momento da geração (qualquer alteração subsequente seria detectada), validação cruzada na indexação (verificar que o ID do paciente no sistema de exames corresponde ao ID no prontuário antes de associar o resultado), e testes automatizados de integridade de dados em toda atualização de software.
O incidente 3 (ataque de ransomware a sistema regional de saúde) é uma violação de disponibilidade. A articulação esperada inclui a consequência de que médicos em unidades básicas de saúde perderam acesso a prontuários de pacientes com doenças crônicas (diabetes, hipertensão, insuficiência cardíaca), impossibilitando o acompanhamento adequado e potencialmente levando a erros de medicação. A medida preventiva central é o backup regular, testado e armazenado em local fisicamente e logicamente separado do sistema principal (especificamente, em storage desconectado da rede — air-gapped —, porque backups conectados à rede também são criptografados pelo ransomware). O professor deve questionar grupos que mencionam apenas antivírus: antivírus não protege contra ransomware sofisticado, que frequentemente opera meses antes de acionar a criptografia, durante os quais aprende a estrutura da rede e se move lateralmente.
Turma A — Atividade 2: LGPD — conformidade de cinco situações médicas
A situação 1 (foto de exame enviada pelo WhatsApp por médica a familiar do paciente) é uma violação do Art. 46 da LGPD. O canal (WhatsApp pessoal da médica) não oferece garantias técnicas adequadas para dados sensíveis: a mensagem transita por servidores de terceiros, o dispositivo pessoal da médica não necessariamente tem política de segurança institucional, e o backup automático do WhatsApp pode armazenar a imagem em nuvem sem criptografia. O professor deve questionar grupos que identificam apenas a ausência de consentimento: o problema não é apenas a ausência de consentimento do titular para esse canal específico — é a inadequação técnica do canal para dados de saúde, independentemente do consentimento. Um paciente pode consentir com o recebimento de seu exame pelo WhatsApp, mas isso não torna o canal tecnicamente adequado sob o Art. 46.
A situação 2 (envio de prontuário completo por e-mail não criptografado a familiar que solicitou por telefone, sem confirmação de identidade) é uma violação combinada: Art. 46 (canal não criptografado para dados sensíveis) e Art. 18 (o titular tem o direito de acessar seus dados, mas a identidade do solicitante deve ser verificada — um e-mail de voz não é forma adequada de verificação de identidade). O professor deve questionar grupos que focam apenas no canal: a ausência de verificação de identidade é igualmente importante. Enviar um prontuário completo para quem alega ser familiar, sem qualquer verificação, é uma violação de confidencialidade que o Art. 46 e o princípio de segurança exigem prevenir.
A situação 3 (banco de dados interno de pesquisa em oncologia com 50.000 registros com pseudoanonimização) é potencialmente conforme, mas com condições. A base legal é o Art. 11 inciso II alínea c (realização de estudos por órgão de pesquisa). Para ser plenamente conforme, a instituição precisaria: (a) ter aprovação do CEP (Comitê de Ética em Pesquisa), que é a materialização da base legal; (b) ter realizado o RIPD (Art. 38), dado que 50.000 registros de dados sensíveis representam tratamento de larga escala; (c) demonstrar que a pseudoanonimização adotada é robusta o suficiente para o contexto (base de pesquisa interna, não pública). O professor deve questionar grupos que dizem apenas “é conforme porque é pesquisa”: conformidade com a LGPD exige que a base legal seja aplicada com os requisitos que a lei especifica para ela.
A situação 4 (startup de saúde mental compartilhando dados “anonimizados” de pacientes com seguradora de saúde para cálculo de risco) é uma violação, por dois motivos independentes que podem coexistir. O primeiro motivo é a incompatibilidade de finalidade: os dados foram coletados para prestação de serviço de saúde mental ao paciente; o uso para cálculo de risco de seguro é uma finalidade distinta, que o paciente não autorizou e que o Art. 6º inciso I (princípio de finalidade) proíbe. O segundo motivo é a suficiência da anonimização: dados de diagnóstico psiquiátrico de uma população específica (usuários de um serviço de saúde mental) são notoriamente difíceis de anonimizar de forma irreversível, e a LGPD considera como dado pessoal qualquer informação que permita, mesmo por processo extraordinário, a identificação do titular. O professor deve questionar grupos que aceitam a anonimização como garantia suficiente sem avaliar a robustez do método.
A situação 5 (solicitação do Ministério da Saúde de dados de casos de tuberculose para vigilância epidemiológica) é conforme. A base legal é o Art. 11 inciso II alínea e: obrigação legal por autoridade sanitária. A tuberculose é doença de notificação compulsória pelo Decreto 49.974-A/1961 e suas atualizações, e a Lei 6.259/1975 estabelece obrigação de notificação. O tratamento dos dados para vigilância epidemiológica não depende de consentimento do paciente, porque a base legal é a obrigação legal, não o consentimento. O professor deve questionar grupos que dizem que é conforme “porque é para o governo”: a conformidade não decorre da identidade do solicitante, mas da existência de obrigação legal específica. Uma solicitação de dados de uma empresa privada, mesmo legítima, não poderia invocar essa base.
Turma A — Atividade 3: Privacidade-desde-o-design para a startup do grupo
Os critérios de avaliação para esta atividade são quatro, em ordem crescente de sofisticação. O primeiro critério é a completude do mapeamento de dados: o grupo identificou todos os tipos de dado que o produto coleta, incluindo dados de identificação, dados clínicos, dados de uso do aplicativo e dados derivados? Um mapeamento incompleto revela que o grupo não pensou sistematicamente sobre o que o produto faz. O segundo critério é a correção das bases legais: para cada tipo de dado, a base invocada é a mais adequada e atende aos requisitos que a LGPD estabelece para ela? O terceiro critério é a especificidade das decisões de privacidade-desde-o-design: cada decisão de design mencionada é uma decisão real de produto (“a tela de cadastro de paciente não pedirá nome completo por padrão; pedirá apenas o mínimo de dados necessários para o fluxo clínico específico”) ou uma generalidade (“o produto vai proteger a privacidade”)? O quarto critério é a viabilidade técnica dos requisitos: os três requisitos priorizados são suficientemente específicos para orientar o desenvolvimento (por exemplo, “o banco de dados de diagnósticos será criptografado com AES-256 em repouso, e os backups serão armazenados em storage desconectado da rede”) ou são princípios gerais sem conteúdo técnico?
Turma B — Atividade 1: Anatomia de dois ataques
O cenário A (spear phishing, keylogger, roubo de credenciais em hospital) tem como insight central o papel do MFA na interrupção da cadeia de ataque. A cadeia de ataque tem cinco elos: (1) reconhecimento — o atacante pesquisou a instituição e identificou um alvo; (2) envio do e-mail de spear phishing com anexo malicioso; (3) instalação do keylogger após abertura do anexo; (4) captura das credenciais digitadas pelo usuário; (5) acesso ao prontuário eletrônico com as credenciais capturadas. O MFA interrompe o elo 5: mesmo com as credenciais capturadas, o atacante não consegue o segundo fator. O controle que falhou no elo 2 é o filtro de e-mail (não detectou o e-mail de phishing); no elo 3, é o antivírus (não detectou o keylogger); no elo 4, é a segurança do endpoint (não havia EDR — Endpoint Detection and Response). Grupos que identificam apenas um controle falho não fizeram a análise completa.
O cenário B (ataque a dispositivos de ECG via Wi-Fi em clínica de cardiologia) tem como insight central o papel da segmentação de rede. Os dispositivos de ECG conectados à rede Wi-Fi compartilhada com computadores de prontuário não estavam em uma rede segmentada — estavam no mesmo domínio de rede que os computadores do médico e do secretário. O atacante que comprometeu um dispositivo de ECG com firmware vulnerável usou esse comprometimento como ponto de entrada para mover-se lateralmente pela rede e alcançar os sistemas de prontuário. A medida preventiva é criar uma VLAN separada para dispositivos de IoMT, com regras de firewall que proíbam roteamento direto entre essa VLAN e a rede de prontuário. O professor deve questionar grupos que propõem apenas “atualizar o firmware dos dispositivos”: atualizar o firmware resolve a vulnerabilidade específica explorada neste ataque, mas não resolve o problema estrutural da ausência de segmentação, que ficaria igualmente vulnerável a qualquer vulnerabilidade futura.
Turma B — Atividade 2: Interoperabilidade para a startup MedTrack
A Integração A (laboratório parceiro com sistema legado) é HL7 v2. A justificativa deve incluir: é o padrão que o sistema legado fala nativamente; tentar impor FHIR a um sistema legado requereria middleware de conversão que adiciona complexidade e potencialmente pontos de falha; o HL7 v2 é suficientemente robusto para a troca de resultados de exame, que é o caso de uso descrito. A implicação para a LGPD: cada mensagem HL7 v2 com resultado de exame é transferência de dados de saúde sensíveis, o que requer contrato de processamento de dados com o laboratório (Art. 39) e canal de transmissão criptografado (TLS).
A Integração B (prontuário eletrônico certificado de hospital parceiro moderno) é FHIR R4. A justificativa deve incluir: o sistema parceiro já está certificado FHIR R4, o que significa que a integração é nativa; a RNDS usa FHIR R4, o que torna essa integração estratégica para acesso futuro à infraestrutura nacional; a API REST do FHIR é mais fácil de manter e auditar do que a integração ponto a ponto do HL7 v2. A implicação para a LGPD: as mesmas que a Integração A, com a adição de que o FHIR R4 tem suporte nativo a auditoria de acesso (recurso AuditEvent), o que facilita a demonstração de conformidade.
A Integração C (operadora de plano de saúde para autorização de procedimentos) é TISS. A justificativa é simples: o TISS é o padrão exigido pela ANS para essa finalidade específica; não há alternativa legalmente adequada para integração com operadoras de plano de saúde no contexto de autorização de procedimentos e faturamento. A implicação para a LGPD: os dados enviados via TISS para a operadora passam a estar no âmbito de tratamento da operadora, que é controladora independente — a startup precisa informar ao paciente sobre esse compartilhamento e, dependendo da base legal usada, pode precisar de seu consentimento específico para esse fluxo.
A Integração D (wearable com API proprietária do fabricante) não tem uma resposta única correta. As três alternativas viáveis estão descritas no roteiro do laboratório acima. O que o professor avalia é a clareza do raciocínio e a consideração das implicações para a LGPD: a alternativa do middleware proprietário cria um processador de dados adicional; a alternativa de negociar acesso à API exige contrato e análise LGPD da API; a alternativa de substituir o wearable por um com padrão aberto resolve o problema técnico mas pode não ser viável clinicamente se o wearable proprietário tem funcionalidades que os com padrão aberto não têm. Grupos que escolhem uma alternativa e a justificam com consistência técnica e jurídica atingiram o nível avançado.
Turma B — Atividade 3: Auditoria da PsychConnect
As vulnerabilidades e não conformidades que os grupos devem identificar incluem, sem se limitar a: ausência de MFA (violação de confidencialidade; contrário ao Art. 46, que exige medidas técnicas adequadas para dados sensíveis; a ausência de MFA em uma plataforma de psicoterapia é um risco de alto impacto dado o grau de sensibilidade dos dados); ausência de criptografia em repouso nos dados de sessão (violação de confidencialidade; Art. 46); uso de plataforma de videoconferência de consumo sem garantias de conformidade para dados de saúde (violação do Art. 46 — a plataforma não foi avaliada para esse uso; potencial violação do Art. 39 — ausência de contrato de processamento com o fornecedor); consentimento genérico para “uso dos dados” sem especificidade de finalidade (violação do Art. 8º e Art. 11 I — consentimento inválido); ausência de DPO nomeado em organização que processa dados sensíveis de larga escala (violação do Art. 41); ausência de RIPD para uma plataforma de telepsiquiatria (violação do Art. 38).
As três ações prioritárias que os grupos devem propor com justificativa de risco-impacto são, no entendimento deste plano: (1) implementar MFA imediatamente, porque é a medida de maior impacto na redução do risco de acesso não autorizado com menor custo e menor prazo de implementação; (2) migrar para plataforma de videoconferência certificada para saúde (com DPA — Data Processing Agreement — e conformidade LGPD/HIPAA documentada), porque o uso da plataforma atual representa risco jurídico imediato e risco de confidencialidade continuado; (3) revisar e substituir o consentimento genérico por consentimento específico para cada finalidade de uso dos dados de sessão, porque o consentimento atual é inválido sob a LGPD e toda a base legal do tratamento de dados da plataforma está comprometida. O professor deve questionar grupos que priorizam criptografia em repouso acima do MFA ou do consentimento: embora a criptografia em repouso seja necessária, o MFA previne o acesso não autorizado que tornaria a criptografia em repouso irrelevante, e o consentimento inválido é uma não conformidade que expõe a empresa a sanções imediatas da ANPD independentemente das demais medidas.
8. Pontos críticos de tutoria e erros conceituais frequentes
Erros conceituais frequentes e estratégias de correção
Esta seção descreve os cinco erros conceituais mais recorrentes no Módulo 11 e as estratégias de tutoria para corrigi-los sem constranger o estudante. A identificação desses erros com antecedência permite que o professor prepare perguntas de aprofundamento que redirecionem o raciocínio do grupo sem fornecer a resposta diretamente.
Erro 1: Tratar toda situação de LGPD como solucionável por consentimento
Este é, sem dúvida, o erro mais frequente e com maior impacto prático. Os estudantes chegam ao módulo com a intuição de que privacidade é sobre consentimento — se o usuário concordou, tudo está permitido. Essa intuição é plausível, mas juridicamente incorreta em múltiplas dimensões.
O primeiro problema é que o consentimento do Art. 11 inciso I da LGPD tem requisitos estritos: deve ser específico (não pode ser um checkbox genérico de “aceito os termos”), destacado dos demais termos contratuais, informado (o titular entende exatamente para que finalidade seus dados serão usados) e facilmente revogável. Um termo de uso que menciona “compartilhamento de dados com parceiros para melhoria dos serviços” não constitui consentimento válido para compartilhamento com uma seguradora de saúde para cálculo de prêmios — as finalidades são incompatíveis, e o paciente não foi informado dessa finalidade específica.
O segundo problema é que para muitas situações de tratamento de dados de saúde, o consentimento não é a base legal mais adequada nem a mais robusta. Para a tutela da saúde em prontuário clínico, a base adequada é o Art. 11 inciso II alínea f — e essa base é, na prática, mais sólida do que o consentimento, porque não pode ser revogada pelo titular a qualquer momento. Para a vigilância epidemiológica, a base é a obrigação legal (Art. 11 inciso II alínea e), e invocar consentimento aqui seria juridicamente mais fraco. Para pesquisa acadêmica com aprovação ética, a base é o Art. 11 inciso II alínea c.
A estratégia de correção é a pergunta: “Você está dizendo que essa situação é conforme porque o paciente consentiu. Qual é o texto exato do consentimento dado? Esse texto descreve especificamente essa finalidade de uso?” Quando o estudante responde que não há um texto específico ou que o consentimento era genérico, ele mesmo reconhece o problema. O professor não precisa declarar o erro; precisa apenas fazer a pergunta que força a especificidade.
Erro 2: Confundir pseudoanonimização com anonimização
Este erro tem consequências jurídicas diretas: dados pseudoanonimizados continuam sendo dados pessoais sob a LGPD; apenas dados genuinamente anonimizados — de forma tecnicamente irreversível, considerando todos os meios razoavelmente disponíveis — deixam de ser dados pessoais e saem do escopo da LGPD.
A distinção técnica é fundamental: pseudoanonimização é a substituição de identificadores diretos (nome, CPF, data de nascimento) por um código ou token — mas o código pode ser revertido ao dado original por quem detém a tabela de correspondência. Se uma startup de saúde mental substitui o CPF do paciente por um código interno, os dados de diagnóstico continuam sendo dados de saúde pessoais, porque a startup pode re-identificar qualquer registro. Anonimização genuína implica que nem a organização que processou os dados consegue mais re-identificar o titular — o que é tecnicamente muito mais difícil de garantir, especialmente para dados de saúde, que têm alta capacidade de re-identificação por combinação de variáveis (diagnóstico + faixa etária + localização geográfica aproximada já é suficiente para identificar indivíduos em populações pequenas).
A estratégia de correção é o exemplo concreto: “Você disse que os dados foram anonimizados. Mas a empresa que os processou tem acesso a qual tabela de correspondência? Se a empresa precisasse saber quais pacientes específicos estão nessa base de dados — por uma auditoria, por um incidente, por uma solicitação judicial — ela conseguiria re-identificá-los? Se a resposta for sim, os dados são pseudoanonimizados, não anonimizados, e continuam sendo dados pessoais sob a LGPD.”
Erro 3: Não articular a consequência clínica na análise CIA
Estudantes que identificam corretamente o pilar da tríade CIA violado, mas descrevem apenas o incidente de segurança sem articula sua consequência para o paciente, completaram apenas a metade da análise. “A confidencialidade foi violada porque os dados foram expostos” é uma resposta tecnicamente correta, mas clinicamente vazia.
A consequência clínica não é um detalhe: é o ponto central. O que torna uma violação de confidencialidade relevante em saúde é o que ela faz à pessoa cujo dado foi exposto. Um histórico de saúde mental exposto ao empregador pode custar o emprego de uma pessoa e desencadear o abandono do tratamento. Um diagnóstico de doença sexualmente transmissível exposto ao parceiro sem o consentimento do titular viola a autonomia do paciente e pode precipitar violência doméstica. Um histórico de uso de substâncias exposto em um processo de guarda de menores pode alterar o resultado do processo judicial. A gravidade da violação não está no dado em si; está no que acontece com a vida da pessoa quando aquele dado sai do contexto de cuidado para o qual foi coletado.
A estratégia de correção é a pergunta direta: “Você identificou que a confidencialidade foi violada. Para o paciente cujos dados foram expostos — uma pessoa real com emprego, família, plano de saúde — o que isso significou? Qual é a consequência mais grave que poderia ter resultado dessa exposição?”
Erro 4: Tratar segurança como estado binário em vez de como gestão de risco
Muitos estudantes abordam as atividades com a expectativa de chegar a uma conclusão binária: o sistema é seguro ou não é seguro; a startup está conforme ou não está. Essa visão binária é inadequada tanto tecnicamente quanto juridicamente.
Tecnicamente, todo sistema de informação tem vulnerabilidades residuais. A questão não é eliminar o risco, mas reduzi-lo a um nível aceitável com medidas proporcionais à sensibilidade dos dados e à probabilidade e impacto das ameaças. Um hospital que usa Windows 7 em equipamentos de tomografia computadorizada tem um risco maior de ataque do que um hospital com sistemas atualizados — mas ambos têm risco. A diferença é que o primeiro tem risco desproporcionalmente alto para dados muito sensíveis, o que o Art. 46 da LGPD exige que ele endereça.
Juridicamente, a LGPD não exige segurança perfeita; exige “medidas técnicas e administrativas aptas a proteger os dados pessoais de acessos não autorizados” (Art. 46) — o que implica uma análise de proporcionalidade. A ANPD avalia violações levando em consideração se o controlador tinha medidas razoáveis para os dados que processava, não se era impossível que uma violação ocorresse.
A estratégia de correção é introduzir a matriz de risco como ferramenta de análise: probabilidade de ocorrência versus impacto da ocorrência. Perguntar ao grupo: “Se você tivesse que priorizar as medidas de segurança que essa organização deveria implementar, como você ordenaria? Qual é a ameaça com maior produto de probabilidade por impacto? É essa que precisa de atenção imediata.”
Erro 5: Produzir respostas genéricas na Atividade 3 da Turma A
A Atividade 3 da Turma A é a mais difícil precisamente porque não há um caso fictício para analisar: o exercício pede que o grupo aplique os conceitos ao próprio projeto, o que exige autoconhecimento sobre o produto que estão desenvolvendo e capacidade de traduzir princípios abstratos em decisões concretas. O risco é a resposta genérica: “o produto vai ter criptografia, vai pedir consentimento, vai implementar mínimo privilégio”. Essas respostas cumprem o formulário do exercício sem demonstrar a competência que o exercício avalia.
O indicador de uma resposta genérica é a intercambiabilidade: se a resposta que o grupo escreveu poderia ser aplicada a qualquer startup de saúde sem qualquer alteração, ela é genérica. Uma resposta de qualidade é específica ao produto do grupo: menciona os tipos concretos de dado que o produto coleta, as bases legais específicas para cada um, as funcionalidades específicas do produto onde cada princípio de privacidade seria implementado.
A estratégia de correção é pedir ao grupo que leia uma frase da resposta e explique como ela se manifesta concretamente no produto deles. “Você escreveu que o produto vai implementar mínimo privilégio. Mostre-me: no seu produto, quem é o usuário com menos privilégios? O que ele pode ver? O que ele não pode ver? Isso está refletido na forma como você está pensando nas telas do aplicativo?” Se o grupo não consegue responder, a resposta estava genérica e o professor pode redirecionar para o concreto com essa mesma série de perguntas.
9. Mapa de progressão da sessão
O diagrama abaixo representa a progressão pedagógica da sessão inteira — da exposição ao laboratório —, mostrando como cada bloco ou estágio contribui para as três competências centrais do módulo.
Nota final para o professor: O Módulo 11 é intencionalmente o mais denso do ponto de vista regulatório. Resistir à tentação de transformá-lo em uma aula de direito é um exercício constante. Cada vez que a discussão ameaçar tornar-se abstrata — “a LGPD exige que…” — o professor deve ancorá-la numa consequência clínica ou numa decisão de design concreta. Segurança da informação em saúde é, no fim, sobre proteger pessoas vulneráveis que confiaram ao sistema de saúde as informações mais íntimas de suas vidas. Quando os estudantes sentirem esse peso, a conformidade regulatória deixará de ser um ônus e passará a ser a articulação técnica de um compromisso ético.