A TI em saúde não pode mover imagens para a nuvem. Veja como manter os sistemas locais em conformidade.

Por que alguns sistemas não estão indo a lugar nenhum

Todo sistema de saúde está olhando para a nuvem agora. O armazenamento custa menos, a escalabilidade é mais fácil, e os fornecedores continuam perguntando por que o PRM ainda não está lá. Mas entre em qualquer departamento de radiologia e a resposta é óbvia: esses arquivos de imagem são enormes, e os clínicos precisam deles rapidamente. A maioria dos hospitais já executa um cache local em cada site apenas para manter a latência baixa para imagens. Essa carga de trabalho não vai a lugar nenhum.

O EMR é uma decisão mais difícil. Algumas organizações o migraram para a nuvem. Muitas não, porque as integrações construídas em torno dele (sistemas de laboratório, farmácia, agendamento, interfaces de dispositivos) dependem de baixa latência que um EMR hospedado na nuvem nem sempre pode garantir quando os dados precisam fazer uma viagem de ida e volta em tempo real. Remover uma integração e você corre o risco de um clínico ficar olhando para um indicador de carregamento durante um atendimento ao paciente ao vivo.

E enquanto os sistemas clínicos principais permanecerem no local, Active Directory também permanece. É a camada de identidade contra a qual tudo o mais se autentica. Movê-lo antes do resto do ambiente estar pronto apenas adiciona risco sem remover nenhum.

Manter-se no local também significa que ficar estático não é uma opção. Não há nenhum fornecedor de nuvem que silenciosamente faça patch no sistema operacional ou endureça a configuração em segundo plano. Se um hospital mantém um sistema internamente, todo o ciclo de vida para manter esse sistema atualizado e seguro também permanece interno, e provar que isso realmente está acontecendo torna-se responsabilidade da organização, não do fornecedor.

Então, a realidade prática para muitas equipes de TI em saúde: a migração para a nuvem é real, mas parcial. Servidores de radiologia, pontos de integração EMR e AD permanecerão no local no futuro previsível. E esses sistemas ainda precisam atender ao mesmo padrão de conformidade que todo o resto.

O que a HIPAA espera quando algo dá errado

A Regra de Notificação de Violação da HIPAA presume o pior por padrão. Se informações de saúde protegidas forem usadas ou divulgadas de uma forma que a HIPAA não permite, a lei presume que isso é uma violação, a menos que a organização possa documentar uma avaliação de risco mostrando uma baixa probabilidade de que as PHI foram realmente comprometidas. Essa avaliação deve considerar fatores como o tipo de PHI envolvida, quem acessou, se ela foi realmente visualizada ou adquirida e se o risco foi mitigado.

Uma vez confirmada uma violação, o relógio começa a contar. As pessoas afetadas precisam ser notificadas sem atraso injustificado e no máximo 60 dias após a descoberta. Violações que afetam 500 ou mais pessoas também exigem notificação ao HHS dentro de 60 dias, além de notificação à mídia em alguns casos. Violações menores são incluídas em um relatório anual ao HHS.

Aqui está a parte que mais importa para um servidor de radiologia local ou uma caixa de integração EMR: a organização precisa ser capaz de reconstruir o que aconteceu. Quem tocou o arquivo. Quando. Se a mudança era esperada. Sem isso, a avaliação de risco padrão é "não sabemos", e "não sabemos" padrão é uma violação que deve ser reportada.

Apenas os registros não resistirão a uma auditoria

Sistemas locais mudam constantemente: patches, edições de configuração, novas contas, um engenheiro do fornecedor acessando remotamente uma interface PACS às 2 da manhã para consertar uma fila de impressão. A maior parte disso está bem. Parte não é autorizada de forma alguma, e os logs nativos do sistema operacional não dizem qual é qual. Eles dizem que uma chave de registro mudou. Eles não dizem se essa mudança correspondeu a um ticket aprovado ou veio de alguém que não deveria ter tido acesso.

Então, quando a OCR ou um auditor pergunta se um servidor específico da interface EMR foi acessado no último trimestre, a resposta honesta para muitas equipes é "teríamos que verificar." Não é um bom lugar para estar quando o relógio para determinar uma violação já está correndo.

Construindo evidências de auditoria sem aumentar o quadro de pessoal

Netwrix Change Tracker oferece à TI de saúde uma forma de manter a integridade dos sistemas que precisam permanecer no local, incluindo os servidores de radiologia, pontos de integração EMR e a infraestrutura do Active Directory que não vão a lugar algum.

Ele cria uma linha de base conhecida e confiável para esses sistemas, depois monitora a integridade dos arquivos e o estado da configuração em tempo real no Windows, Linux e nos dispositivos de rede entre eles. Quando algo muda, seja uma chave de registro, um arquivo de configuração ou uma conta local, o Change Tracker verifica isso em relação às Mudanças Planejadas aprovadas. Se corresponder a uma janela de mudança aprovada, é registrado como atividade esperada. Se não, é sinalizado imediatamente, e o TI sabe em minutos em vez de descobrir durante uma auditoria ou revisão de incidente.

Isso significa que "teríamos que ir verificar" se transforma em "aqui está." O registro já mostra o que mudou, quando e se foi autorizado, e esse é a maior parte do trabalho por trás de uma avaliação de risco defensável de quatro fatores.

Change Tracker também vem com mais de 250 relatórios de conformidade pré-construídos mapeados para frameworks como HIPAA, NIST, e PCI DSS, então provar que o controle estava em vigor não significa construir um relatório do zero a cada ciclo de auditoria. A evidência já está estruturada da maneira que um auditor espera ver.

A conversa sobre nuvem em TI de saúde não terminou, e não deveria terminar. Mas os sistemas que permanecem no local ainda precisam provar que estão sob controle. O Change Tracker oferece às equipes de TI e conformidade uma maneira de fazer isso sem esperar que o restante da infraestrutura acompanhe.