Prontuário Eletrônico do Paciente

a) O S-RES (conjunto de componentes principais) deve apresentar as informações de identificação do software desenvolvido pelo fornecedor, contendo minimamente o nome do software, nome do fornecedor, identificação completa da versão e/ou release e/ou build. Essas informações deverão corresponder à da versão certificada do produto, e será utilizada como referência em todos os documentos, selo, e outros documentos relacionados à certificação.

b) Essas informações deverão estar disponíveis minimamente:

• Na tela inicial do S-RES;
• Nas telas de cada módulo (por exemplo, cabeçalho, rodapé ou ainda em um item de um menu), de modo que quando o sistema esteja em uso essas informações estejam sempre acessíveis;
• Impressões geradas oriundas do S-RES. Neste caso, tais informações deverão ser exibidas minimamente na última página do documento impresso (em um cabeçalho ou rodapé, por exemplo);
• Arquivo de exportação da trilha de auditoria.

Condição: para a modalidade de Receita Digital, esse requisito se aplica apenas aos sistemas que podem operar de forma autônoma e independente (stand-alone).

a) Todo usuário do S-RES deve ser identificado e autenticado antes de qualquer acesso a dados ou funcionalidades do S-RES.

b) Utilizar, em todos os processos autenticação de pessoa, no mínimo um dos seguintes métodos de autenticação de pessoa:

• Digitação de um nome de usuário e senha secreta de acesso;
• Certificado digital e PIN (Personal Identifier Number);
• Validação biométrica associada ao PIN (Personal Identifier Number).

c) As credenciais para autenticação no S-RES devem ser validadas após a submissão das mesmas ao serviço de autenticação do sistema no lado do servidor, evitando que a validação ocorra somente no lado do cliente.

d) Em caso de aplicação móvel, a autenticação pode ser realizada no lado do cliente, caso haja uso do aplicativo de forma off-line. No momento da sincronização dos dados, deve haver a autenticação no lado servidor antes do registro dos dados no sistema.

Nota: quaisquer outras técnicas diferentes das exigidas acima, tais como OTP (one-time password) e Captcha, são considerados complementares, podendo ser utilizados apenas em conjunto com um dos métodos supracitados.

Condição: para a modalidade de Receita Digital, esse requisito se aplica apenas aos sistemas que podem operar de forma autônoma e independente (stand-alone). O S-RES deve armazenar de forma protegida todos os dados ou parâmetros utilizados no processo de autenticação de usuário.

Método: nome de usuário e senha
a) A senha deve ser armazenada em banco de dados, de forma codificada por algoritmo de hash aberto (público) de no mínimo 160 bits.
b) As codificações das senhas de acesso dos usuários devem ser protegidas contra acesso não autorizado. Apenas o usuário do banco de dados utilizado pela aplicação deve ter acesso às mesmas.

Método: Biometria (condição: somente para pessoas)
c) Os templates biométricos das pessoas devem ser protegidos contra acesso não autorizado. Apenas o usuário do banco de dados utilizado pela aplicação deve ter acesso aos mesmos.
d) As amostras biométricas coletadas e transmitidas durante o processo de autenticação devem ser protegidas contra acesso não autorizado.
e) Em caso de aplicação móvel, deve ser utilizada a biometria do sistema operacional.

Método: One-time password (OTP)
f) As sementes de geração dos valores numéricos devem ser protegidas contra acesso não autorizado. Apenas o usuário do banco de dados utilizado pela aplicação deve ter acesso às mesmas.

Condição 1: utilização de autenticação baseada no método de usuário e senha.

Condição 2: para a modalidade de Receita Digital, esse requisito se aplica apenas aos sistemas que podem operar de forma autônoma e independente (stand-alone).

O S-RES deve exigir que toda senha de usuário seja definida seguindo minimamente os seguintes critérios:

• Pelo menos 8 caracteres;
• Pelo menos um caractere alfabético;
• Pelo menos um caractere numérico.

-

-

Condição 1: utilização de autenticação baseada no método de usuário e senha.

Condição 2: para a modalidade Consultório Individual, esse requisito é aplicável apenas para S-RES oferecido como SaaS.

Condição 3: para a modalidade de Receita Digital, esse requisito se aplica apenas aos sistemas que podem operar de forma autônoma e independente (stand-alone).

a) O S-RES deve permitir a geração de uma senha para um usuário pelo administrador do sistema.

b) A senha pode ser definida de forma manual pelo administrador ou de forma automática pelo S-RES.

c) O S-RES deve forçar que o usuário realize a troca de senha caso a mesma tenha sido definida manualmente pelo administrador.

d) A troca deve ocorrer imediatamente após o usuário acessar o S-RES pela primeira vez após a geração da senha. Adicionalmente, nenhuma ação poderá ser efetuada pelo usuário no S-RES até que o mesmo efetue a troca de senha.

-

Condição 1: utilização de autenticação baseada no método de usuário e senha.

Condição 2: para a modalidade de Receita Digital, esse requisito se aplica apenas aos sistemas que podem operar de forma autônoma e independente (stand-alone).

O S-RES deve permitir que um usuário efetue a troca de sua senha no sistema, sendo que a mesma deve seguir as regras de parametrização da qualidade da senha.

Para mais informações sobre como este requisito é atendido, acesse o manual da Tecnologia, selecione sua respectiva versão do Gestão de Pessoas | HCM na seção Tecnologia | XT e, através do menu (na lateral esquerda), acesse:

• Ferramentas de Apoio > Gerenciamento de Usuários > SGU > Segurança > Políticas de Senha > SGU - Políticas de esquecimento de senhas; e
• Ferramentas de Apoio > Gerenciamento de Usuários > SGU > Segurança > Políticas de Senha > Duração das Senhas.

-

-

Condição 1: utilização de autenticação baseada no método de usuário e senha.

Condição 2: para a modalidade de Receita Digital, esse requisito se aplica apenas aos sistemas que podem operar de forma autônoma e independente (stand-alone).

Em todos os processos de troca de senha, o S-RES deve exigir que a nova senha do usuário seja diferente da atual e da imediatamente anterior

Condição 1: utilização de autenticação baseada no método de usuário e senha.

Condição 2: para a modalidade de Receita Digital, esse requisito se aplica apenas aos sistemas que podem operar de forma autônoma e independente (stand-alone).

a) O S-RES deve permitir que, na tela inicial de login no sistema, o usuário possa obter uma nova senha (opção “esqueci a senha”).

b) No momento em que o usuário solicitar a recuperação de senha, o S-RES deve realizar uma das seguintes opções:

• Gerar uma nova senha automaticamente e enviá-la ao usuário; ou
• Encaminhar ao usuário instruções para que o mesmo possa definir uma nova senha.

c) A geração e envio da senha ou encaminhamento das instruções deve ser realizado por meio de um canal (SMS ou e-mail, por exemplo) cuja identificação tenha sido registrada previamente no cadastro do usuário.

Condição: para a modalidade de Receita Digital, esse requisito se aplica apenas aos sistemas que podem operar de forma autônoma e independente (stand-alone).

a) O S-RES deve possuir, em todos os processos de autenticação de usuário, independentemente do método utilizado, mecanismos para bloquear seu acesso após um número máximo configurável de tentativas consecutivas de login com autenticação inválida, que não exceda a 10 tentativas.

b) Após o bloqueio da conta de um usuário, o sistema só deve permitir login deste após o seu desbloqueio pelo administrador ou por algum método definido pelo sistema que impeça o acesso por pessoas não autorizadas.

Condição: para a modalidade de Receita Digital, esse requisito se aplica apenas aos sistemas que podem operar de forma autônoma e independente (stand-alone).

Em caso de autenticação inválida em tentativa de acesso, a mensagem de erro emitida pelo sistema para o usuário não deve informar qual o motivo da falha da autenticação. Por exemplo, pode-se emitir uma mensagem informando que os dados de autenticação estão incorretos, sem especificar que o usuário não existe ou que a senha está incorreta.

Condição 1: utilização de autenticação baseada no método de usuário e senha.

Condição 2: para a modalidade de Receita Digital, esse requisito se aplica apenas aos sistemas que podem operar de forma autônoma e independente (stand-alone).

a) O S-RES deve impedir que a interface de usuário utilizada para digitação de credenciais de acesso (nome de usuário e senha, por exemplo) permita a memorização ou visualização de dados anteriores (lista de logins já digitados, lembrança automática de senhas associadas a um login, etc.).

b) Toda e qualquer digitação direta de senhas deve ser feita por meio de máscara de caracteres que impeça sua visualização por outras pessoas.

a) A sessão de usuário deve ser automaticamente bloqueada ou encerrada forçadamente pelo sistema após um período de inatividade.

b) O período máximo de inatividade deve ser configurável e armazenado no banco de dados.

c) Caso o S-RES possibilite ao usuário o desbloqueio de sessão, essa operação deve ser permitida apenas quando o desbloqueio for realizado pelo mesmo usuário bloqueado. Para que o desbloqueio de sessão seja realizado, o sistema deve requerer novo processo de autenticação do usuário bloqueado. Outro usuário deve ter a possibilidade de encerrar a sessão bloqueada anteriormente (sem reativá-la) para que só então possa prosseguir com uma nova sessão.

d) Após o bloqueio ou encerramento da sessão de usuário, as informações em tela não deverão mais estar visíveis, sendo necessária uma nova autenticação para a retomada da atividade.

e) Não deve ser possível para qualquer usuário do sistema desativar ou desabilitar tais controles.

a) A sessão de comunicação remota entre cliente e servidor deve possuir controles de segurança que impeçam o roubo ou reuso da sessão do usuário.

b) As credenciais de acesso não devem ser transmitidas entre as partes na forma de texto claro.

c) Deve haver controles que impeçam o reuso de identificadores de sessão do usuário (ataques de replay e covert-channel) e roubo da sessão. d) Não deve ser possível para qualquer usuário do sistema desativar ou desabilitar tais controles.

Para mais informações sobre como este requisito é atendido, acesse o manual da Tecnologia, selecione sua respectiva versão do Gestão de Pessoas | HCM na seção Tecnologia | XT e, através do menu (na lateral esquerda), acesse:

• Manual de Instalação > Arquitetura; e
• Manual de Instalação > Middleware Senior > Arquitetura.

Condição: para a modalidade de Receita Digital, esse requisito se aplica apenas aos sistemas que podem operar de forma autônoma e independente (stand-alone).

O S-RES deve disponibilizar minimamente três perfis de usuário: administrador do sistema, profissional administrativo (sem acesso aos dados clínicos) e profissional de saúde.

a) O S-RES deve permitir o gerenciamento (cadastro, ativação/inativação e alteração) de perfis, por meio da aplicação.

b) O S-RES deve permitir a atribuição de permissões específicas a um determinado perfil. Tais permissões podem ser pré-definidas no S-RES de acordo com as suas funcionalidades ou telas oferecidas (por exemplo, permissão para realizar prescrição eletrônica, permissão para realização de agendamentos etc.).

Condição: para a modalidade de Receita Digital, esse requisito se aplica apenas aos sistemas que podem operar de forma autônoma e independente (stand-alone).

a) O S-RES deve permitir que mais de um perfil possa ser atribuído a um usuário (por exemplo, profissional de saúde e administrador).

b) Tal atribuição deverá implicar na necessidade de escolha de um perfil pelo usuário no momento do login ou no acúmulo de permissões para o usuário de acordo com os perfis a ele atribuídos.

Condição: para a modalidade de Receita Digital, esse requisito se aplica apenas aos sistemas que podem operar de forma autônoma e independente (stand-alone).

O S-RES deve permitir o gerenciamento (cadastro, ativação/inativação e alteração de cadastro) de usuários, por meio da aplicação.

Tecnologia

Para mais informações sobre como este requisito é atendido, acesse o manual da Tecnologia, selecione sua respectiva versão do Gestão de Pessoas | HCM na seção Tecnologia | XT e, através do menu (na lateral esquerda), acesse Ferramentas de Apoio > Gerenciamento de Usuários > SGU.

Gestão de Pessoas | HCM

Para mais informações sobre como este requisito é atendido, acesse:

• Usuários;
• Assinalamentos de Usuários.

Condição: para a modalidade de Receita Digital, esse requisito se aplica apenas aos sistemas que podem operar de forma autônoma e independente (stand-alone).

a) Identidade única: toda pessoa usuária do S-RES deverá ser identificada individualmente.

b) Vinculação a número legal e único: toda pessoa usuária do S-RES deverá ser vinculada minimamente a um documento de identificação pessoal unívoco segundo a legislação brasileira vigente (por exemplo, Número de Cadastro de Pessoa Física - CPF). Qualquer alteração de cadastro nesse documento deverá exigir uma justificativa no usuário.

c) Unicidade de identificação de usuários: a informação de identificação de tal documento deverá ser validada em todos os processos de inclusão ou alteração de pessoas para garantir a unicidade, ou seja, o S-RES não deve permitir a associação de um mesmo documento de identificação a dois usuários no sistema.

d) Exclusão de usuários: Para fins de responsabilização, não deve ser possível remover o cadastro ou o vínculo de um usuário a um profissional, caso alguma operação tenha sido realizada pelo mesmo.

e) Unicidade em modalidade SaaS: caso o S-RES opere na modalidade SaaS, a unicidade do identificador da pessoa deve ser por organização.

Condição: para a modalidade de Receita Digital, esse requisito se aplica apenas aos sistemas que podem operar de forma autônoma e independente (stand-alone).

O S-RES deve garantir que haja ao menos um usuário ativo com perfil de administrador e/ou gestor de acessos (por exemplo, por meio da criação de um usuário administrador fixo que não pode ser inativado ou ter suas permissões alteradas).

O controle de usuários é realizado pelo SGU (Sistema Gerenciador de Usuários) e seu acesso é realizado pelo usuário e senha do banco de dados. Logo, apenas um administrador pode acessá-lo (de forma idêntica ao logon que é realizado no CBDS).

Para mais informações sobre como este requisito é atendido, acesse o manual da Tecnologia, selecione sua respectiva versão do Gestão de Pessoas | HCM na seção Tecnologia | XT e, através do menu (na lateral esquerda), acesse Ferramentas de Apoio > Gerenciamento de Usuários > SGU.

Condição: Para a modalidade de Receita Digital, esse requisito se aplica apenas aos sistemas que podem operar de forma autônoma e independente (stand-alone).

O S-RES não deve permitir que usuários com permissão de gerenciamento de usuários e perfis possam alterar permissões de acesso de seu próprio usuário no S-RES (autoconcessão).

A concessão de direitos a um usuário é realizada no Senior Gerenciador de Usuários (SGU), através da associação do usuário a um grupo que tenha determinados direitos.

Apenas um administrador com a senha do banco de dados pode acessar o SGU. Logo, não é possível realizar a autoconcessão de direitos.

a) O S-RES deve permitir a geração de cópia de segurança ("backup full"), pela aplicação ou SGBD, contendo informações suficientes para restauração.

b) A geração de cópia de segurança deve exportar os atributos de segurança e metadados em conjunto com os dados.

Nota: considera-se como atributos de segurança todos os parâmetros e configurações existentes.

Este grupo de requisitos é de responsabilidade do cliente, conforme:

• SGBD utilizado; e
• Sua política de Segurança da Informação.

Para mais informações sobre como este grupo de requisitos é atendido, acesse o manual da Tecnologia, selecione sua respectiva versão do Gestão de Pessoas | HCM na seção Tecnologia | XT e, através do menu (na lateral esquerda), acesse Ferramentas de Apoio > CBDS - Introdução.

Este grupo de requisitos é de responsabilidade do cliente, conforme:

• SGBD utilizado; e
• Sua política de Segurança da Informação.

Para mais informações sobre como este grupo de requisitos é atendido, acesse o manual da Tecnologia, selecione sua respectiva versão do Gestão de Pessoas | HCM na seção Tecnologia | XT e, através do menu (na lateral esquerda), acesse Ferramentas de Apoio > CBDS - Introdução.

a) O S-RES deve permitir a restauração da cópia de segurança, pela aplicação ou SGBD.

b) Na restauração de uma cópia de segurança os atributos de segurança e metadados devem ser automaticamente recuperados, sem a intervenção do administrador.

a) O S-RES deve possuir controle de integridade da cópia de segurança.

b) A verificação da integridade deverá ocorrer durante a restauração da cópia, gerando um alerta caso ocorra alguma falha. O processo de restauração deve garantir sua completude de forma que toda informação seja restaurada. Caso haja algum erro durante a restauração, nenhuma informação deverá então ser restaurada, retornando-se, portanto, ao estado anterior (rollback).

Condição: S-RES não dispõe de infraestrutura com espaço de armazenamento dinâmico.

a) S-RES deve permitir o gerenciamento do espaço de armazenamento de registros por meio da configuração de um limiar de ocupação.

b) O S-RES deve ainda permitir a configuração de um ou mais usuários com perfil de administrador do sistema que deverão receber uma notificação do S-RES no caso desse limite de ocupação ser atingido.

a) A sessão de comunicação entre o componente de interação com o usuário (ex.: browser ou executável cliente) e os outros componentes do S-RES (ex.: servidor de aplicação, banco de dados, etc.) deve oferecer os seguintes serviços de segurança: autenticação do servidor, integridade dos dados e confidencialidade dos dados.

b) O serviço de segurança empregado deve implementar criptografia dos dados em trânsito (por exemplo, uso de HTTPS).

Para mais informações sobre como este requisito é atendido, acesse o manual da Tecnologia, selecione sua respectiva versão do Gestão de Pessoas | HCM na seção Tecnologia | XT e, através do menu (na lateral esquerda), acesse:

• Manual de Instalação > Arquitetura; e
• Manual de Instalação > Middleware Senior > Arquitetura.

Condição: S-RES em arquitetura Web.

a) Todo processamento (modificação) de dados de RES deve ocorrer no lado do servidor. Todos os dados apresentados no lado do cliente devem ter sido gerados e processados no lado servidor.

b) Todos os processos de validação de dados devem ser realizados no lado do servidor.

Nota: opcionalmente, por questões de performance, poderá haver validação de dados inicialmente no lado cliente desde que seguida de validação no lado do servidor.

Condição: S-RES ser composto por componentes distribuídos.

A comunicação entre componentes distribuídos (como, por exemplo, entre a aplicação e o banco de dados) deve oferecer os seguintes serviços de segurança: autenticação dos parceiros (ambas as partes), integridade dos dados e confidencialidade dos dados (criptografia).

Nota: a segurança pode ser aplicada ao canal de comunicação ou às mensagens trocadas.

Condição: S-RES utilizar componentes que exijam download (descarregamento do servidor para o cliente) para sua execução (ex.: ActiveX, Applet, aplicações para tablet, etc.) por parte do usuário.

Possuir controle de integridade e possibilidade de verificação da origem/autoria (ex.: pelo uso de assinatura digital do componente) de componentes que exijam download para sua execução.

a) Todos os dados de RES em S-RES devem ser armazenados integral e exclusivamente por um Sistema de Gerenciamento de Banco de Dados (SGBD) que contemple minimamente o sigilo dos dados.

b) Arquivos e documentos anexados ou gerados pelo S-RES (por exemplo, laudos em PDF, áudios, vídeos, etc.) podem, opcionalmente, ser armazenados em estrutura de diretórios, desde que o S-RES garanta o sigilo desses documentos de forma que os mesmos somente possam ser visualizados por meio de seu acesso pelo S-RES. Adicionalmente, o nome dos arquivos e diretórios não podem conter qualquer informação que permita a identificação de seu conteúdo.

Item "b": o sistema armazena o tipo de informação mencionada de forma binária no banco de dados.

Para mais informações sobre como este requisito é atendido, acesse o manual da Tecnologia, selecione sua respectiva versão do Gestão de Pessoas | HCM na seção Tecnologia | XT e, através do menu (na lateral esquerda), acesse Ferramentas de Apoio > Bancos de Dados > Configuração de Storage nos aplicativos Senior Sistemas.

O sistema realiza validações em tela, de acordo com a necessidade do campo.

Exemplo

No caso do campo de CPF, o sistema verificará se o número informado é válido.

Para os demais casos (ataque de buffer, overflow e injeção de dados), a Senior considera que esta segurança somente seria necessária caso houvesse uma arquitetura web. Sendo assim, como é utilizada a arquitetura cliente/servidor, esses pontos do requisito não fazem parte do escopo Senior.

Para mais informações sobre como este requisito é atendido, acesse o manual da Tecnologia, selecione sua respectiva versão do Gestão de Pessoas | HCM na seção Tecnologia | XT e, através do menu (na lateral esquerda), acesse:

• Manual de Instalação > Arquitetura; e
• Manual de Instalação > Middleware Senior > Arquitetura.

Condição: S-RES ofertado na modalidade SaaS.

Todos os dados do RES devem ser segregados por organização, ou seja, nenhum dado do RES de uma organização pode ser acessado ou visualizado por usuário de outra organização, salvo quando consentido pelo paciente segundo acordo de privacidade.

Nota: a regra não se aplica obrigatoriamente para usuários de TI ou administrativos que sejam responsáveis pela gestão e controle centralizado (multi-organização).

A infraestrutura SaaS disponibilizada pela Senior já é segregada, e o produto também não oferece funcionalidade de compartilhamento de qualquer tipo de dados. Logo, não é possível que clientes acessem dados uns dos outros.

a) Os registros de auditoria devem ser protegidos contra acesso não autorizado e contra qualquer tipo de alteração.

b) Apenas usuários com perfil de auditor ou, na ausência deste, o administrador do sistema, podem ter acesso (consulta) a esses dados.

O S-RES deverá registrar em trilha de auditoria minimamente os seguintes tipos de eventos, quando contemplados pelo sistema:

a) Quanto ao RES:

• Criação, duplicação, consulta, inativação de registros do RES;
• Importação e exportação de dados;
• Impressão de registros do RES;
• Solicitação de acesso de emergência a um prontuário;
• Registro ou alteração de termos de consentimento;
• Criação, inativação e alterações de regras de apoio à decisão clínica (por exemplo, alteração de regra de sexo x diagnóstico, por exemplo).

b) Quanto às ações de usuário:

• Tentativas de autenticação de usuário, com ou sem sucesso;
• Troca de senha;
• Realização de assinatura digital;
• Validação de assinatura digital;
• Falha na realização ou validação de assinatura digital;
• Registro de solicitação de esquecimento.

c) Quanto às ações operacionais:

• Atividades de gerenciamento de usuários e perfis, incluindo inativação/bloqueio e ativação/desbloqueio de conta de usuário;
• Realização e restauração de cópia de segurança.

Todas as ações operacionais de inclusão, alteração ou exclusão de registros são continuamente monitoradas. Além disso, essa funcionalidade passa por manutenção constante para garantir que novas telas e funcionalidades também contem com a auditoria adequada.

O S-RES deve registrar, para cada registro de auditoria, minimamente as seguintes informações:

• Número de identificação unívoca do registro da trilha;
• Data e hora do evento;
• Tipo de evento (por exemplo: criação de atendimento, acesso ao prontuário, acesso a documento de sumário de alta, impressão de documento, troca de senha, etc.);
• Identificação do componente gerador do evento (endereço IP ou MAC address, por exemplo);
• Identificação do usuário gerador do evento, quando aplicável; • Identificador único e permanente do registro afetado pelo evento (por exemplo, identificador do paciente cujo prontuário foi acessado);
• Informações complementares relevantes sobre o evento (ex.: motivo da falha na validação de assinatura digital, descrição do erro relativo à execução de processos operacionais, etc.).

Por meio da tela de Consulta, é possível visualizar todas as operações realizadas no sistema.

a) O S-RES deve possuir uma interface na aplicação para visualização dos registros de auditoria em ordem cronológica.

b) Todos os registros da trilha de auditoria devem ser passíveis de visualização por meio dessa interface.

c) Tal interface deve permitir a filtragem de registros minimamente por data, evento, identificador único e permanente do usuário e identificador único e permanente do registro afetado (por exemplo, identificador do paciente).

a) O S-RES deve possuir manuais que apresentem minimamente as seguintes informações:

• Instruções de uso do S-RES para os usuários contemplando todos os perfis/papéis existentes (por exemplo: administrador, operador, operador de backup, etc.);
• Visão geral do S-RES, incluindo formas de operação, requisitos do ambiente computacional;
• Instalação e configuração do S-RES;
• Instalação e configuração dos componentes complementares e/ou distribuídos (ex: SGBD, sistema operacional, etc.);
• Recomendação sobre a forma de configuração segura do S-RES e componentes complementares e/ou distribuídos, e forma de operação segura do S-RES;
• Instruções explicitando quaisquer limitações e restrições relacionadas à compatibilidade do S-RES e/ou seu funcionamento (por exemplo, mídias compatíveis para uso do certificado digital);
• Compatibilidade com versões anteriores do S-RES.

b) Os manuais poderão ser apresentados em documentos separados ou em um mesmo documento dividido em diferentes capítulos, em suporte em papel e/ou eletrônico. Essa separação deve incluir minimamente os temas: instalação, operação, administração e recomendações de segurança.

Nota 1: os manuais podem ser disponibilizados em quaisquer formatos abertos e inteligíveis, tais como texto (impresso ou eletrônico), audiovisual, etc.

Nota 2: no caso de SaaS, os manuais dirigidos à instalação e configuração do S-RES e de seus componentes podem ficar restritos ao fornecedor (administrador da plataforma), sendo dispensada a sua disponibilização aos usuários finais.

O Gestão de Pessoas | HCM, assim como outras soluções da Senior, apresenta seu manual exclusivo, onde estão as documentações por telas, por processos e diversos outros conteúdos relacionados às funcionalidades do sistema. Além disso, mais detalhes técnicos também podem ser encontrados no manual da Tecnologia, selecionando sua respectiva versão do Gestão de Pessoas | HCM na seção Tecnologia | XT).

Condição: S-RES cuja operação de backup é realizada pelo próprio fornecedor do sistema ou pelo estabelecimento de saúde.

a) O manual de instalação deve informar como realizar a configuração de um usuário com permissão de operação de backup.

b) O manual de instalação deve informar como configurar o SGBD de forma que as atividades de exportação e restauração de uma cópia de segurança dos dados possa ser realizada somente pelo usuário com permissão de operação de backup.

c) Os manuais pertinentes devem conter indicações de cautela caso existam outros usuários com permissão de geração ou restauração de cópia de segurança (ex.: usuário 'sa' ou equivalente).

d) Caso o S-RES não possua a funcionalidade de exportação e restauração em sua interface diretamente, deve referenciar em seu manual procedimento ou link do fabricante do SGBD contendo informações pertinentes a execução destas tarefas.

Para mais informações sobre como este requisito é atendido, acesse o manual da Tecnologia, selecione sua respectiva versão do Gestão de Pessoas | HCM na seção Tecnologia | XT e, através do menu (na lateral esquerda), acesse:

• Manual de Instalação > Informações Técnicas > Plataformas homologadas; e
• Manual de Instalação > Central de Configuração > Central de Configurações - Banco de dados.

Condição: S-RES ser composto por componentes distribuídos.

O manual de instalação deve informar que a comunicação entre os componentes distribuídos do SRES deve implementar os serviços de segurança de autenticação de parceiro, integridade e sigilo dos dados, e dar orientações para tal configuração.

Condição: S-RES composto por componentes distribuídos.

a) O manual de instalação deve informar claramente se o S-RES possui uma segregação lógica e física, se for o caso, dos diferentes componentes do sistema, tais como servidor de banco de dados, servidor de aplicação, servidor de autenticação, servidor de backup, servidor de validação de certificados digitais, etc.

b) O manual deve exemplificar uma ou mais arquiteturas de configuração, propiciando o atendimento do cenário de componentes distribuídos.

c) O manual deve conter um diagrama que represente a comunicação entre componentes e seus respectivos métodos de comunicação segura.

Condição: possibilidade de importação automática de dados de dispositivos externos de saúde.

a) O manual deve indicar os procedimentos necessários para importação, incluindo parametrização quando aplicável.

b) O manual deve conter um aviso de que, em caso de importação de dados de dispositivos externos de saúde, é necessário que exista um termo de responsabilidade referente à aferição e calibração periódica desses dispositivos, ou que haja um profissional de saúde que valide essas informações antes de sua aceitação pelo S-RES.

a) Todo registro de tempo do S-RES deverá ser baseado em uma fonte de referência temporal configurável, ou seja, utilizar a referência de tempo do servidor e não da estação do usuário, exceto no caso de aplicação “desktop” (onde o sistema está em um único computador, sem servidor separado).

b) O registro de tempo deve ser contínuo, utilizando o protocolo de sincronismo de tempo NTP.

O NTP (Network Time Protocol) é um protocolo utilizado para sincronizar os relógios dos dispositivos em uma rede de computadores. Ele é empregado pelos sistemas operacionais para manter a hora sempre atualizada.

Para mais informações sobre como este requisito é atendido, acesse o manual da Tecnologia, selecione sua respectiva versão do Gestão de Pessoas | HCM na seção Tecnologia | XT e, através do menu (na lateral esquerda), acesse Tecnologia > Manual de Instalação > Central de Configuração > Banco de dados > Banco de dados por sistema > Fuso horário.

Sempre que o horário é definido de forma automática, como na auditoria ou no rodapé dos relatórios que exibem data e hora de impressão, a referência utilizada é o banco de dados. Há situações em que o horário é informado manualmente pelo usuário, como no agendamento, para permitir a definição do horário desejado.

O fuso horário e o horário de verão podem ser configurados por meio do Senior Config Center.

a) Toda entrada de data completa deve respeitar a sequência dia seguido do mês seguido do ano.

b) Toda entrada de horário deve respeitar a sequência hora seguida dos minutos.

a) Toda exibição (em tela ou impressão) de data completa deve respeitar a sequência dia seguido do mês seguido do ano.

b) Toda exibição (em tela ou impressão) de horário deve respeitar a sequência hora seguida dos minutos. Opcionalmente, pode-se exibir ainda o fuso horário (UTC), segundos e milissegundos.

Condição: S-RES permite que o servidor de aplicação e/ou banco de dados esteja em uma localidade diferente daquela em que o S-RES é utilizado por seus usuários.

a) O S-RES deve permitir a parametrização da time zone e local onde se encontra a instituição de saúde.

b) A exibição de registro de tempo, tanto em tela quanto em impressão, deve respeitar a UTC indicada na parametrização, independentemente da localização do servidor. Ou seja, caso o registro de tempo tenha sido registrado no banco de dados de acordo com a UTC da localização do servidor, o S-RES deverá converter automaticamente tal registro de acordo com a time zone da instituição.

a) O S-RES deverá alertar o usuário quando da programação de qualquer atividade (ex.: aprazamento de medicação, agendamento de exames, etc.) que seja afetada pela mudança de fuso horário decorrente do início ou término de horário de verão.

b) O sistema deve permitir o ajuste automático dos horários afetados pela mudança por meio de uma parametrização que indique se tal ajuste deverá ou não ocorrer. Por exemplo, há um medicamento a ser administrado às 02h00 da manhã. Ao entrar no horário de verão, o S-RES ajustaria o horário para 01h00 da manhã.

Condição: para a modalidade de Receita Digital, esse requisito se aplica apenas aos sistemas que podem operar de forma autônoma e independente (stand-alone).

a) O S-RES deve exibir imediatamente após o primeiro acesso do usuário no sistema, um termo de concordância sobre o uso do sistema e as políticas de privacidade sobre o tratamento apropriado das informações pessoais e de saúde, alertando para o devido cuidado visando a confidencialidade dos dados e as consequências do uso inadequado dos mesmos.

b) O usuário só deve poder prosseguir após aceitar explicitamente as condições ali dispostas.

c) A concordância com os termos deverá ser repetida obrigatoriamente a cada alteração nas políticas de uso.

a) O S-RES deve permitir o registro de um ou mais consentimentos do paciente referentes ao propósito de uso de suas informações pessoais de saúde e profissionais autorizados a acessá-las.

b) O S-RES deve permitir o upload de consentimentos assinados e digitalizados.

c) O S-RES deve permitir indicar o status do consentimento (autorizado, não autorizado ou revogado).

d) O S-RES deve permitir indicar se o consentimento foi assinado pelo próprio paciente ou por seu representante legal, permitindo ainda registrar, para o segundo caso, a identificação do representante (nome, CPF e CNS) e seu grau de relacionamento com o paciente.

a) O S-RES deve permitir efetuar a revogação de um consentimento para acesso a dados pessoais previamente registrado.

b) A revogação do consentimento deve ser registrada e visualizada, tanto em tela quanto impressão, indicando, minimamente, o registro de tempo da mudança, profissional responsável e status anterior e posterior à mudança.

c) Uma vez que um consentimento foi autorizado pelo paciente e registrado no S-RES, esse não poderá ter seu registro ou conteúdo alterado (por exemplo, alteração do texto do consentimento ou do documento anexado durante upload). Qualquer necessidade de alteração deverá implicar na revogação do consentimento e registro de um novo.

Condição: S-RES permite a alteração de registros clínicos já finalizados.

a) A correção de um dado do prontuário e/ou registro clínico só poderá ser feita pelo próprio autor.

b) Qualquer correção de um dado do prontuário e/ou registro clínico já finalizado deve implicar na geração de uma nova versão para o mesmo.

c) Toda correção de um dado do prontuário e/ou registro clínico deve exigir justificativa do usuário.

d) A versão anterior à correção deve ser mantida no prontuário do paciente com status de inativa.

e) Ao acessar a versão atual do registro, o S-RES deve indicar que o mesmo possui versões anteriores e deve permitir que tais versões sejam facilmente acessadas.

Nota: consideram-se como finalizados os registros que foram concluídos e liberados pelo profissional.

No campo Justificativa Reabertura é possível registrar detalhadamente o motivo da reabertura de um atendimento.

a) O S-RES deve permitir a inativação de registros de dados clínicos e atendimentos previamente armazenados e finalizados (liberados) no sistema. Tais registros incluem, mas não se limitam a: prescrições, sinais vitais, diagnósticos, alergias e documentos clínicos (anamnese e sumário de alta, por exemplo).

b) Toda inativação de registros de dados clínicos ou atendimentos deve exigir uma justificativa ao usuário. A inativação só poderá ser concluída após indicação da justificativa.

c) A inativação de um registro deve alterar seu respectivo status para inativo (ou outro termo de mesmo significado) e registrar a data/hora e usuário responsável pela inativação.

d) Todos os dados registrados no S-RES e considerados como finalizados/definitivos/liberados devem ser mantidos permanentemente. Dessa forma, registros inativos devem continuar vinculados ao prontuário do respectivo paciente e ser passíveis de visualização tanto em tela quanto exportação, incluindo data/hora, profissional responsável e justificativa da inativação.

e) Qualquer registro que tenha sido inativado deve ter seu status de inativo apresentado de forma clara e destacada tanto em tela quanto exportação, de forma a deixar evidente o conteúdo que está inativo (tachando o texto, por exemplo).

O S-RES deverá permitir o uso de um certificado digital (assinatura digital e autenticação no S-RES) por um usuário apenas se o CPF informado no cadastro deste usuário for idêntico ao identificado no certificado digital utilizado. Dessa forma, a cada processo de uso do certificado digital deverá ser verificado se o CPF do usuário executando o processo corresponde ao CPF contido no certificado digital utilizado, e o processo só será finalizado com sucesso em caso de igualdade dos CPFs.

Nota: opcionalmente, o S-RES poderá exigir que no momento do cadastro do usuário faça-se uma restrição a um ou mais certificados digitais específicos, por exemplo fornecendo o número serial dos mesmos

a) O S-RES deve validar o certificado digital e sua cadeia de certificação antes de sua utilização ou imediatamente após sua utilização. A validação do certificado digital envolve a validação criptográfica, verificação de validade e revogação, inclusive dos certificados da sua cadeia de certificação.

b) A validação deve ocorrer no lado do servidor utilizando-se os certificados raiz de confiança configurados no servidor. Dessa forma, apenas certificados raiz existentes no repositório gerenciado podem ser utilizados para atividades de autenticação e/ou assinatura.

Nota: em caso de S-RES local, não existe segregação entre servidor e cliente.

O S-RES deve incluir em toda assinatura realizada:

• no caso do formato CMS/CAdES, o atributo id-signingTime;
• no caso do formato XMLDSIG/XAdES, a propriedade SigningTime;
• no caso do formato PAdES, a entrada no dicionário de assinatura chamada de “M”.

Este atributo representa o instante de assinatura (signingTime ou “M”) adotado pelo signatário.

a) O S-RES deve permitir a visualização das informações a serem assinadas antes da sua assinatura.

b) O sistema deverá exibir apenas as informações que realmente serão assinadas, excluindo-se quaisquer informações de outras telas adjacentes ou aspectos relacionados à interface (como botões ou menus).

Condição: S-RES permite a existência de pendência de assinatura digital.

a) Caso um determinado profissional deixe um registro sem assinatura digital, o S-RES deve notificá-lo no momento em que o mesmo sair da tela em que o registro está sendo apresentado, mesmo em caso de logoff ou fechamento da aplicação.

b) Após o login por um profissional de saúde, o S-RES deve apresentar uma lista com todos os registros pendentes de assinatura existentes no sistema e que são de responsabilidade deste profissional, possibilitando a abertura e posterior assinatura do documento a partir da lista apresentada. O sistema deve ainda permitir o acesso à essa lista por vontade do profissional a qualquer momento.

a) O S-RES deve exibir uma indicação de que um determinado documento foi assinado digitalmente (por exemplo, exibindo um status de “assinado”).

b) O S-RES deve ainda permitir que o usuário possa visualizar por meio da aplicação as informações sobre a assinatura (minimamente quais profissionais assinaram e registro de tempo).

a) O S-RES deverá realizar a validação da assinatura minimamente nas seguintes situações:

• Antes da inclusão do objeto digital contendo a assinatura digital no RES;
• Imediatamente após a geração da assinatura digital do documento eletrônico;
• Ao ser solicitada a impressão de documentos previamente assinados digitalmente;
• Na importação de registro eletrônico assinado digitalmente: a assinatura deve ser validada antes de iniciar sua inclusão no RES;
• Na exportação de registro eletrônico assinado digitalmente: a assinatura deve ser validada antes de iniciar sua exportação no RES;
• Por vontade e ação do usuário, ao ter acesso a todo e qualquer documento assinado, durante pesquisa ou consulta.

b) A validação de um documento eletrônico assinado deve exibir o status (resultado) da validação da assinatura ao usuário e permitir sua revalidação a qualquer tempo (vide NGS2.02.11).

c) Em caso de mais de uma assinatura no documento eletrônico (co-assinaturas), todas estas deverão ser validadas.

d) A validação de uma assinatura deve incluir:

• A validação do carimbo de tempo, quando presente: verificação da assinatura do carimbo de tempo, do certificado da autoridade de carimbo de tempo e dos certificados da cadeia de certificação, conforme requisitos da ICP-Brasil e da RFC 3161;
• A verificação do certificado do signatário e dos certificados da cadeia de certificação;
• A verificação do estado de revogação do certificado do signatário e dos certificados da cadeia de certificação, utilizando como referência temporal o instante presente no carimbo de tempo, e utilizando LCR (Lista de Certificados Revogados) [RFC 5280] ou Resposta OCSP (Online Certificate Status Protocol) [RFC 2560]. Caso o objeto de revogação (LCR ou resposta OCSP) não esteja presente, obtêlo e incluí-lo na assinatura no momento da validação.

Nota: na validação da assinatura de documentos/registros antigos do S-RES sem a presença de carimbo de tempo, a referência temporal a ser utilizada para verificação de revogação é o instante presente no atributo “momento de assinatura” (signingTime).

a) O S-RES deve, a qualquer tempo, prover meios para validação e exibição do estado de validade de uma assinatura digital.

b) O resultado da validação de uma assinatura digital deve retornar um dos seguintes estados:

• Válida: assinatura válida;
• Inválida: assinatura inválida;
• Indeterminada: quando não é possível determinar se a assinatura está válida ou inválida, geralmente devido à falta de objetos críticos (ex: certificado, objeto de revogação, carimbo de tempo, certificado da cadeia, atributos obrigatórios, etc.).

c) Exceto para o estado válido, a causa deverá ser indicada.

d) Na impressão de um documento assinado, deverá constar o estado da assinatura (resultado da validação).

Condição: S-RES ser capaz de importar registros externos assinados digitalmente.

No momento da importação de um registro externo assinado digitalmente, o S-RES deve validar as assinatura(s) digital(is):

• Em caso de impossibilidade de validação, o S-RES deverá gerar uma pendência para validação do registro;
• Caso o resultado aponte que a assinatura digital é “inválida” ou “indeterminada”, o S-RES deverá registrar este resultado, informando ao usuário em consultas futuras;
• O S-RES deve ser capaz de validar assinaturas geradas por certificados digitais emitidos por qualquer AC da cadeia ICP-Brasil.

O S-RES deve permitir a impressão de registros assinados digitalmente utilizando ao menos uma das seguintes opções:

• Mensagem de rodapé: impressa em cada registro assinado digitalmente; e/ou
• Relatório de assinaturas: impresso para um conjunto de registros assinados digitalmente.

Condição: impressão de mensagem de rodapé.

a) Em caso de impressão de mensagem de rodapé (em cada registro assinado digitalmente), as assinaturas dos registros devem ser validadas no momento da impressão e deve ser adicionada a seguinte mensagem na parte inferior de cada página.

“Documento assinado digitalmente de acordo com a ICP-Brasil, MP 2.200-2/2001, no sistema certificado SBIS nº XXX-Y, por <nome do signatário>, às <HH:MM+-UTC de DIA/MÊS/ANO>. Estado da assinatura: <estado>”.

b) Os dados variáveis (nome, data e hora) deverão ser extraídos da assinatura. As informações de hora e a data devem ser obtidas a partir do atributo signingTime, ou entrada no dicionário de assinatura, chamada de “M”.

c) Caso haja mais de uma assinatura, os mesmos dados devem ser apresentados para os outros signatários na sequência.

Nota 1: a exibição das figuras é opcional.

Nota 2: a “MP 2.200-2/2001” deverá ser substituída na mensagem caso tenham sido utilizadas legislações mais recentes.

Condição: impressão de relatório de assinaturas.

a) Em caso de impressão de relatório de assinaturas (para um conjunto de registros assinados digitalmente), todos os registros assinados devem ser validados no momento da geração do relatório e da impressão dos registros, e a seguinte mensagem deve ser impressa:

“Os documentos a seguir foram assinados digitalmente de acordo com a ICP-Brasil, MP 2.200-2/2001, no sistema certificado SBIS nº XXX-Y. A lista abaixo indica o número do documento e seus signatários.”

b) Em seguida, deverá vir a lista dos documentos assinados digitalmente, numerados e paginados sequencialmente, e para cada registro, indicar:

• Seu número sequencial;
• As páginas a que se referem;
• Assinado por: <nome do signatário>, às <HH:MM+-UTC de DIA/MÊS/ANO>. Estado da assinatura: <estado>.

c) Caso haja mais de uma assinatura, os mesmos dados devem ser apresentados para os outros signatários na sequência.

Nota 1: a exibição das figuras é opcional.

Nota 2: a “MP 2.200-2/2001” deverá ser substituída na mensagem caso tenham sido utilizadas legislações mais recentes.

Condição: utilizar certificado digital como método de autenticação.

Para o processo de autenticação por meio do uso de certificado digital, o S-RES deve validar:

• Instante atual dentro da vigência do certificado digital;
• Confiança da cadeia de certificação;
• Revogação;
• Correspondência dos valores CPF do usuário e do certificado;
• Emissão com propósito de autenticação, por meio do extensão Extended Key Usage, deve possuir ao menos o valor Client Authentication (1.3.6.1.5.5.7.3.2).