Cada ficha médica roubada custa até $20 – vinte vezes mais do que os dados do cartão de crédito. Para evitar roubo de identidade, fraude e chantagem, todos os aplicativos de saúde nos EUA têm que estar em conformidade com a Health Insurance Portability and Accountability Act (HIPAA). Este é o nosso guia simples para software compatível com a HIPAA.

entre outras coisas, a HIPAA protege as informações de saúde dos pacientes.

Anthem, a maior companhia de seguros dos EUA, aprendeu isso da maneira mais difícil.

O que começou com um simples e-mail de phishing, levou à maior violação de dados de saúde da história. Os hackers roubaram os dados de 79 milhões de pacientes. As informações incluíam seus nomes, números de seguridade social e IDs médicos.

Os pacientes furiosos processaram a Anthem e ganharam um acordo de $115 milhões. Embora a empresa tenha evitado as multas do regulador, teria que gastar até $260 milhões para melhorar sua segurança.

O Escritório de Direitos Civis (OCR) supervisiona o cumprimento da HIPAA. Só em 2017 multou os prestadores de cuidados de saúde norte-americanos em quase $20 milhões.

Aven se for uma pequena organização, negligenciar os requisitos HIPAA pode levar a sérios problemas.

Em 2013 a Fresenius Medical Care North America teve cinco violações de dados. Combinados, eles expuseram os dados de apenas 525 pacientes. Mas a empresa teve que pagar uma multa monstruosa de $3,5 milhões porque não analisou adequadamente os riscos de segurança.

De acordo com o grau de negligência, há quatro pneus de multas HIPAA:

>

HIPAA glossário

Você deve entender estes três termos-chave antes de abordar os requisitos HIPAA.

  • Informação de saúde protegida (PHI) – qualquer dado que possa ser usado para identificar um paciente.

PHI consiste em duas partes: informação de saúde e identificadores pessoais. Estes últimos incluem nomes de pacientes, moradas, datas de nascimento, números de segurança social, registos médicos, fotografias, etc. O fato de que um indivíduo tenha recebido serviços médicos é um DCC em si.

O que é considerado DCC? A lista completa.

  • Entidades Cobertas – organizações e indivíduos que oferecem serviços/operações de saúde ou aceitam pagamentos por eles.

Incluem todos os provedores de saúde (por exemplo, hospitais, médicos, dentistas, psicólogos), planos de saúde (por exemplo, provedores de seguros, HMOs, programas governamentais como Medicare e Medicaid) e clearinghouses (as organizações que atuam como intermediários entre os provedores de saúde e as companhias de seguros).

  • Business Associates – os terceiros que lidam com os PHI em nome das entidades cobertas.

Esta categoria inclui os desenvolvedores de aplicativos de saúde, provedores de hospedagem/armazenamento de dados, serviços de e-mail, etc.

De acordo com a HIPAA, você deve assinar um Business Associate Agreement (BAA) com cada parte que tenha acesso aos seus PHI. Decidir não assinar um BAA não o liberta dos requisitos HIPAA.

As Entidades Cobertas e os Associados Empresariais precisam de cumprir com o HIPAA. A lei não tem nenhuma cláusula de “porto seguro”, o que significa que você tem que estar em conformidade mesmo se lidar com PHI involuntariamente.

>

Pode haver muitas maneiras não intencionais nas quais os dados sensíveis podem entrar no seu sistema.

Take, por exemplo, um serviço que permite aos médicos diagnosticar condições de pele com base em fotos anônimas. O aplicativo não lida com PHI, pois você não consegue identificar seus usuários. Mas assim que você adicionar o nome ou endereço da pessoa às fotos, elas tornam-se PHI.

Se a sua aplicação recolher, armazenar, ou transmitir PHI às entidades abrangidas, você precisa de cumprir com HIPAA.

Como se tornar compatível com HIPAA?

Para ser compatível com HIPAA, você terá de fazer avaliações técnicas e não técnicas regulares dos seus esforços para proteger a informação de saúde e documentá-las completamente. O regulador publicou um modelo de protocolo de auditoria que pode ajudá-lo a avaliar a sua conformidade com a HIPAA.

Você pode contratar um auditor independente para fazer a avaliação por você. Há muitas organizações como a HITRUST que são especializadas nesse tipo de coisas. Basta lembrar que o OCR não reconhece nenhum certificado de terceiros.

Desenvolvendo software compatível com HIPAA, você terá que lidar principalmente com as salvaguardas técnicas e físicas descritas na Regra de Segurança.

Salvaguardas Técnicas. Medidas de segurança como login, criptografia, acesso de emergência, registros de atividades, etc. A lei não especifica quais tecnologias você deve usar para proteger PHI.

Guardas Físicas são destinadas a proteger as instalações e dispositivos que armazenam PHI (servidores, centros de dados, PCs, laptops, etc.).

Com soluções modernas baseadas em nuvem, esta regra se aplica principalmente à hospedagem compatível com HIPAA.

As salvaguardas descritas na Regra de Segurança podem ser “necessárias” ou “endereçáveis”. Ambas são obrigatórias. Se você pular uma salvaguarda “endereçável”, você deve provar que esta é uma decisão suficientemente razoável para a sua situação.

A lei se aplica a uma ampla gama de softwares médicos. Um sistema de gestão hospitalar (HMS) difere radicalmente dos aplicativos de diagnóstico remoto. Mas há alguns recursos que são essenciais para todos os aplicativos compatíveis com HIPAA.

Então aqui está uma lista mínima de recursos necessários para um software compatível com HIPAA:

1. Controle de acesso

A qualquer sistema que armazene PHI deve limitar quem pode ver ou modificar os dados sensíveis. De acordo com a Regra de Privacidade HIPAA, ninguém deve ver mais informação do paciente do que a necessária para fazer o seu trabalho. A regra também especifica a desidentificação, os direitos do paciente de ver seus próprios dados e sua capacidade de dar ou restringir o acesso aos seus PHI.

Uma maneira de conseguir isto é atribuir a cada usuário uma identificação única. Isso permitiria identificar e rastrear a atividade das pessoas que acessam seu sistema.

Próximo, você terá que dar a cada usuário uma lista de privilégios que lhe permitam visualizar ou modificar certas informações. Você pode regular o acesso a entidades e URLs individuais das bases de dados.

Na sua forma mais simples, o controle de acesso baseado no usuário consiste em duas tabelas de bases de dados. Uma tabela contém a lista de todos os privilégios e seus IDs. A segunda tabela atribui estes privilégios a usuários individuais.

Neste exemplo, o médico (usuário ID 1) pode criar, visualizar e modificar os registros médicos, enquanto o radiologista (usuário ID 2) só pode atualizá-los.
Um controle de acesso baseado em funções é outra forma de implementar este requisito. Com ele, você pode atribuir privilégios a diferentes grupos de usuários dependendo de sua posição (por exemplo, médicos, técnicos de laboratório, administradores).

2. Autenticação de pessoa ou entidade

Depois de ter atribuído privilégios, seu sistema deve ser capaz de verificar se a pessoa que está tentando acessar PHI é aquela que ele diz ser. A lei oferece várias formas gerais para implementar esta salvaguarda:

Uma senha é um dos métodos mais simples de autenticação. Infelizmente, é também um dos métodos mais fáceis de quebrar. De acordo com Verizon, 63% das violações de dados acontecem devido a senhas fracas ou roubadas. Outro relatório afirma que um quinto dos usuários corporativos tem senhas facilmente comprometidas.

Por outro lado, uma senha verdadeiramente segura:

  • Consiste de pelo menos 8-12 caracteres que incluem letras maiúsculas, números e caracteres especiais;
  • Exclui as combinações comumente usadas (por exemplo palavras “password”, “123456”, “qwerty”, e por alguma razão inexplicável “monkey”) e vocabulário;
  • Desactiva qualquer variação do nome de utilizador;
  • Previne a reutilização da password.

Alternativamente, pode ser uma cadeia de palavras aleatórias esmagadas como um picolé concreto.

A sua aplicação poderia verificar estes requisitos na tela de inscrição e negar acesso a usuários com senhas fracas.

Não há muita segurança. Fonte: mailbox.org

Algumas organizações forçam seus funcionários a mudar as senhas a cada 90 dias ou mais. Fazer isso com muita freqüência pode realmente prejudicar seus esforços de segurança. Quando feitas para mudar as senhas, as pessoas muitas vezes vêm com combinações não originais (por exemplo, senha ⇒ pa$$word).

Além disso, os hackers podem descobrir uma senha ruim em segundos e usá-la imediatamente.

É por isso que você deve considerar o uso de uma autenticação de dois fatores. Tais sistemas combinam uma senha segura com um segundo método de verificação. Isto pode ser qualquer coisa desde um scanner biométrico até um código de segurança de uso único recebido via SMS.

A idéia é simples: mesmo se os hackers de alguma forma obtivessem sua senha, eles precisariam roubar seu dispositivo ou suas impressões digitais para acessar PHI.

Mas autenticação segura não é suficiente. Alguns atacantes podem ficar entre o dispositivo do usuário e seus servidores. Desta forma, os hackers poderiam acessar o PHI sem comprometer a conta. Isto é conhecido como hijacking de sessão, uma espécie de ataque de man-in-the-middle.

Uma das formas possíveis de seqüestrar uma sessão. Fonte: Heimdal Security

Uma assinatura digital é uma das formas de se defender contra tais ataques. Reinserir a senha ao assinar um documento provaria a identidade do usuário.

Como os papéis em seu sistema ficam mais complexos, a autorização HIPAA pode atrapalhar a ajuda aos pacientes. Faz sentido implementar o acesso de emergência. Tais procedimentos permitem aos usuários autorizados visualizar quaisquer dados que eles precisem quando a situação assim o exigir.

Um médico poderia, por exemplo, acessar os PHI de qualquer paciente em uma emergência. Ao mesmo tempo, o sistema notificaria automaticamente várias outras pessoas e iniciaria um procedimento de revisão.

3. Segurança de transmissão

Você deve proteger os PHI que você envia pela rede e entre os diferentes níveis do seu sistema.

É por isso que você deve forçar HTTPS para todas as suas comunicações (ou pelo menos para as telas de inscrição, todas as páginas contendo PHI e cookies de autorização). Este protocolo de comunicação seguro encripta os dados com SSL/TLS. Usando um algoritmo especial, ele transforma PHI em uma seqüência de caracteres sem sentido sem chaves de decriptação.

Um arquivo chamado certificado SSL vincula a chave à sua identidade digital.

Ao estabelecer uma conexão HTTP com a sua aplicação, o navegador solicita o seu certificado. O cliente então verifica a sua credibilidade e inicia o chamado aperto de mão SSL. O resultado é um canal de comunicação criptografado entre o usuário e sua aplicação.

Para habilitar HTTPS para sua aplicação, obtenha um certificado SSL de um dos provedores confiáveis e instale-o corretamente.

Ainda isso, certifique-se de usar um protocolo SSH ou FTPS seguro para enviar os arquivos contendo PHI ao invés do FTP regular.

SSL handshake; fonte: a loja SSL

Email não é uma maneira segura de enviar PHI.

Serviços populares como o Gmail não fornecem a proteção necessária. Se você enviar e-mails contendo PHI além do seu servidor firewalled, você deve encriptá-los. Existem muitos serviços e extensões de browser que podem fazer isto por si. Alternativamente, você pode usar um serviço de e-mail compatível com HIPAA como Paubox.

Você também deve implementar políticas que limitem quais informações podem ser compartilhadas via e-mails.

4. Criptografia/descriptografia

A criptografia é a melhor maneira de garantir a integridade dos PHI. Mesmo se os hackers conseguissem roubar seus dados, pareceria uma algaraviada sem as chaves de decriptação.

Portáteis com criptografia e outros dispositivos portáteis são uma fonte comum de violações de HIPAA. Para estar no lado seguro, encripte os discos rígidos de todos os dispositivos que contêm PHI. Você pode fazer isso com ferramentas livres de criptografia como BitLocker para Windows ou FileVault para Mac OS.

5. Eliminação de PHI

Você deve destruir PHI permanentemente quando não for mais necessário. Enquanto sua cópia permanecer em um de seus backups, os dados não são considerados “descartados”.

Em 2010 o Affinity Health Plan devolveu suas fotocopiadoras para a empresa de leasing. Não apagou, no entanto, os seus discos rígidos. A violação resultante expôs as informações pessoais de mais de 344.000 pacientes.

A afinidade teve que pagar $1,2 milhões por este incidente.

PHI pode se esconder em muitos lugares inesperados: fotocopiadoras, scanners, equipamentos biomédicos (por exemplo, máquinas de ressonância magnética ou ultra-som), dispositivos portáteis (por exemplo, aparelhos de ultra-som).por exemplo, computadores portáteis), disquetes antigos, unidades flash USB, DVDs/CDs, cartões de memória, memória flash em placas-mãe e cartões de rede, memória ROM/RAM, etc.

Além de apagar os dados, você também deve destruir corretamente os suportes que contêm PHI antes de jogá-los ou entregá-los. Dependendo da situação, você pode apagá-los magneticamente (por exemplo, usando um desmagnetizador), sobrescrever os dados usando software como DBAN, ou destruir fisicamente a unidade (por exemplo, esmagá-la com um martelo).

Em unidades de memória baseadas em flash (por exemplo, pendrives), os dados são espalhados por toda a mídia para evitar o desgaste. Devido a isso, é difícil apagar completamente a informação sensível com software de destruição de dados regular. Você pode, no entanto, usar utilitários do fabricante como o Samsung Magician Software para eliminar as suas unidades flash (ou apenas usar um martelo).

6. Backups e armazenamento de dados

Backups são essenciais para a integridade dos dados. Uma corrupção da base de dados ou uma falha do servidor pode facilmente danificar os seus PHI. Assim como um incêndio em um centro de dados ou um terremoto.

Por isso é importante ter múltiplas cópias de seus PHI armazenadas em vários locais diferentes.

Seu plano de backup de PHI deve determinar a probabilidade de comprometimento dos dados. Todas as informações de alto e médio risco devem ser copiadas diariamente e armazenadas em um local seguro. Você também deve assinar um BAA com seus provedores de backup.

Um backup é inútil se você não puder restaurá-lo.

Em agosto de 2016, Martin Medical Practice Concepts foi vítima de um ataque de resgate. A empresa pagou aos hackers para decifrar os PHI. Mas devido a uma falha de backup, os hospitais locais perderam informações sobre 5.000 pacientes.

Teste seu sistema regularmente para evitar falhas de recuperação. Você também deve registrar o tempo de inatividade do sistema e quaisquer falhas para fazer backup dos PHI.

E lembre-se, os backups em si devem estar de acordo com as normas de segurança HIPAA.

7. Controles de auditoria

A ausência de controles de auditoria pode levar a multas mais altas.

Você deve monitorar o que é feito com os PHI armazenados no seu sistema. Registre cada vez que um usuário entrar e sair do seu sistema. Você deve saber quem, quando e onde os dados sensíveis foram acessados, atualizados, modificados ou excluídos.

Monitoramento pode ser feito via software, hardware ou meios processuais. Uma solução simples seria usar uma tabela em um banco de dados ou um arquivo de log para registrar todas as interações com as informações do paciente.

Tal tabela deve consistir de cinco colunas:

  • user_id. O identificador único do usuário que interagiu com PHI;
  • nome_da_entidade. A entidade com a qual o usuário interagiu (Uma entidade é uma representação de algum conceito do mundo real em seu banco de dados, por exemplo, um registro de saúde);
  • record_id. O identificador da entidade;
  • action_type. A natureza da interação (criar, ler, atualizar ou excluir);
  • action_time. O tempo preciso de interação.

Neste exemplo, um médico (user_id 1) criou o registro de um paciente, um radiologista o visualizou, e mais tarde o mesmo médico alterou o registro.

Você terá que auditar periodicamente os registros de atividades para descobrir se alguns usuários abusam de seus privilégios para acessar PHI.

8. Logoff automático

Um sistema com PHI deve encerrar automaticamente qualquer sessão após um período definido de inatividade. Para continuar, o usuário teria que digitar novamente sua senha ou autorizar de alguma outra forma.

Isso protegeria as PHI se alguém perdesse seu dispositivo enquanto estava logado em seu aplicativo.

O período exato de inatividade que aciona o logout deve depender das especificidades de seu sistema.

Com uma estação de trabalho segura em um ambiente altamente protegido, você pode definir o temporizador por 10-15 minutos. Para soluções baseadas na web, este período não deve exceder 10 minutos. E para um aplicativo móvel, você pode definir o tempo limite para 2-3 minutos.

Diferentes linguagens de programação implementam logoff automático de diferentes maneiras.

Source: MailChimp

9. Aplicativo móvel de segurança extra

Dispositivos móveis apresentam muitos riscos adicionais. Um smartphone pode facilmente ser roubado ou perdido em uma área de alto tráfego comprometendo as informações sensíveis.

Para prevenir isso, você pode usar:

  • Fechadura de tela (Android/iOS);
  • Criptografia completa do dispositivo (Android/iOS);
  • Apagamento de dados remoto (Android/iOs).

Você não pode forçar esses recursos nos usuários, mas você pode encorajar as pessoas a usá-los. Você pode incluir as instruções em seu onboarding ou enviar e-mails descrevendo como habilitá-las.

Tip: Você pode armazenar os PHI em um recipiente seguro separadamente dos dados pessoais. Desta forma, você pode apagar remotamente as informações de saúde sem afetar nada mais.

Muitos médicos usam smartphones pessoais para enviar informações de saúde. Você pode neutralizar esta ameaça com plataformas seguras de mensagens.

Estas aplicações hospedam os dados sensíveis em um banco de dados seguro. Para acessar PHI, os usuários têm que baixar o messenger e entrar em suas contas.

Outra solução é portais de saúde criptografados protegidos por senha, onde os pacientes podem ler mensagens de seus médicos. Tais portais enviam notificações sem PHI neles (por exemplo: “Caro Usuário, você tem uma nova mensagem de “).

Remember, notificações push não são seguras por padrão. Elas podem aparecer na tela, mesmo que esteja bloqueada. Portanto, certifique-se de não enviar nenhuma notificação de PHI através de notificações push. O mesmo se aplica a SMS e quaisquer mensagens automáticas.

Source: Bridge Patient Portal

Outra coisa a considerar é que a FDA pode classificar alguns aplicativos mHealth como dispositivos médicos (software que influencia o processo de tomada de decisão dos profissionais de saúde).

Então lembre-se de verificar se o seu aplicativo tem que cumprir com outros regulamentos de saúde antes de iniciar o desenvolvimento. Você pode verificar este teste da Federal Trade Commission para obter uma resposta rápida.

Aplicações de embrulho

Agora você tem uma lista mínima de recursos para software compatível com HIPAA.

Sozinho eles não vão garantir a sua segurança. Eles não vão protegê-lo contra phishing ou engenharia social.

Mas ter essas características deve convencer um auditor de que você fez o suficiente para proteger os dados de seus clientes.

Para tornar as auditorias menos dolorosas, documente todos os seus esforços de conformidade com a HIPAA. Para cada lançamento de seu aplicativo, forneça as especificações escritas, os planos para testar sua segurança e seus resultados. E não se esqueça de verificar se você precisa cumprir outras regulamentações antes de iniciar o desenvolvimento.

Deixe uma resposta

O seu endereço de email não será publicado.