CONSULTA PÚBLICA DE PREÇOS Nº 057/2024

CONSULTA PÚBLICA DE PREÇOS: Contratação de empresa especializada em fornecimento de licença de uso do sistema de Gestão da Saúde.

1. Constitui objeto deste Termo de Referência, a Contratação de empresa especializada em fornecimento de Licença de Uso de Sistema de Gestão da Saúde modular destinada às unidades municipais de saúde do Município de Cajamar-SP, abrangendo os serviços de Implantação, conversão, migração de dados, projeto assistido, treinamento de usuário, hospedagem em datacenter, suporte, manutenção, por 12 meses de acordo com as especificações e condições deste Termo de Referência.

Período para apresentação da proposta: de 24/06/2024 a 28/06/2024.

A proposta poderá ser entregue pessoalmente no endereço: Xxxxx Xxxx Xxxxxxxxx xx Xxxxxxxxxx, 00

– Bairro Água Fria – Cajamar/SP (Secretaria Municipal de Fazenda e Gestão Estratégica – Departamento de Compras e Contratos) entre 08:00 e 17:00 horas ou enviar com papel timbrado da empresa para o e-mail: xxxxxxxxxxxxxxx@xxxxxxx.xx.xxx.xx, conforme modelo abaixo:

MODELO - FORMULÁRIO - COTAÇÃO DE PREÇOS

Nome da Empresa:
E-mail institucional:
E-mail pessoal:
Endereço:
Bairro:	CEP:
Cidade:	Estado:
CNPJ Nº:	Inscrição Estadual:
Fone:	Fax:

ANEXO I – TERMO DE REFERÊNCIA PROCESSOADMINISTRATIVO Nº 4958/2024

MODALIDADE: Pregão Eletrônico

TIPO DE LICITAÇÃO: Menor valor

FORMA DE CONTRATAÇÃO: Contratação

1. DO OBJETO

1.1. Constitui objeto deste Termo de Referência, a Contratação de empresa especializada em fornecimento de Licença de Uso de Sistema de Gestão da Saúde modular destinada às unidades municipais de saúde do Município de Cajamar-SP, abrangendo os serviços de Implantação, conversão, migração de dados, projeto assistido, treinamento de usuário, hospedagem em datacenter, suporte, manutenção, por 12 meses de acordo com as especificações e condições deste Termo de Referência .

1.2. Relação das unidades: Abaixo as unidades que serão contempladas pelo sistema informatizado:

1. Unidade Básica de Pronto Atendimento – UPA (00) 00000000

2. Unidade de Saúde Jordanésia (00) 00000000

3. Unidade de Saúde Polvilho (00) 00000000

4. Unidade de Saúde Parque São Roberto (00)00000000

5. Unidade de Saúde Cajamar Centro (00) 00000000

6. Unidade de Saúde Guaturinho (00)00000000

7. Unidade de Saúde Belo Planalto (00) 00000000

8. Unidade de Saúde Parque Xxxxx Xxxxxxxxx Xxxxxx Xxxxxx (00) 00000000

9. Unidade de Saúde Ponunduva (00) 00000000

10. Unidade de Saúde Km 00 (00)00000000

11. Unidade de Saúde Jardim Xxxxx Xxxxx (00) 00000000

12. Unidade de Saúde Portal dos Ipês (00)00000000

13. Zoonoses (00) 00000000

14. CTA – Centro de Testagem e Aconselhamento (00) 00000000

15. Vigilância Em Saúde – Vigilância Sanitária (00) 00000000

16. CAPS – Centro de Atenção Psicossocial Adulto (00) 00000000

17. CAPS – Centro de Atenção Psicossocial Infanto Juvenil (00) 00000000

18. Farmácia 24 Horas – (00) 00000000

19. Unidade Básica de Saúde Parque Panorama (00) 00000000

20. Central de Ambulâncias (00) 00000000

MODALIDADE: Pregão

TIPO DE LICITAÇÃO: Menor valor global

FORMA DE CONTRATAÇÃO: contratação

2. DA JUSTIFICATIVA

Esta contratação visa a administração completa e integrada de todas as áreas relacionadas à Saúde Pública, por meio de um sistema de tecnologia de gestão que fornecerá informações mais consistentes e precisas. Isso facilitará o planejamento e controle das atividades municipais, resultando em redução de custos e melhoria na eficiência, qualidade e segurança dos serviços de saúde prestados no âmbito municipal.

Além disso, será possível integrar os pontos de atendimento médico, centralizando as informações em uma base de dados. Isso permitirá que o gestor municipal elabore diversos relatórios necessários para o Sistema Único de Saúde (SUS), embasando ações de saúde, políticas e estruturas governamentais. A aplicação oferecida tem como objetivo qualificar a gestão dos processos técnicos e administrativos da saúde pública municipal, bem como a gestão urbana por meio do uso de informações georreferenciadas.

Em suma, a contratação tem como objetivo a Gestão Integrada de Saúde Pública, promovendo o controle, gestão e integração das informações por meio de uma ferramenta ágil, segura e moderna. Isso proporcionará transparência nas relações e confiabilidade nas ações desenvolvidas, além de eliminar tarefas e informações duplicadas, melhorar o planejamento e controlar melhor a destinação dos recursos públicos. Também trará agilidade e confiança nas prestações de contas, atendendo às exigências dos órgãos de controle e fiscalização, e resultando em maior transparência e eficiência na gestão pública.

Dessa forma, a contratação trará diversos benefícios, incluindo melhoria na gestão do tempo, na qualidade das atividades operacionais, redução de custos, aumento na qualidade e quantidade de atendimentos realizados pelos estabelecimentos de saúde, e um avanço expressivo na eficiência e eficácia dos serviços de saúde oferecidos pelo município.

3. DESCRIÇÃO DA SOLUÇÃO

Busca-se empresa especializada que atue junto a Secretaria Municipal de Saúde e da sua equipe

técnica, de acordo com as prioridades que serão estabelecidas pela Gestão, dentro da rotina estabelecida e planejada para sua execução.

Este documento apresenta o estudo técnico preliminar, de acordo com o art. 7º do Decreto nº 6.827 de 06 de outubro de 2022, que constitui primeira etapa do planejamento de uma contratação (planejamento preliminar) e serve essencialmente para assegurar a viabilidade técnica da contratação e embasar o termo de referência ou o projeto básico, conforme previsto na Lei 14.133/2021. Além disso, a estrutura deste documento baseia-se nas orientações constantes do Guia de Boas Práticas em Contratação de Soluções de Tecnologia da Informação, publicado pelo Tribunal de Contas da União, e por conseguinte encontra-se respaldo no arcabouço técnico legal acerca das contratações de bens e serviços de Tecnologia da Informação.

Diante do documento referente à solicitação apresentada, analisa-se a possibilidade de locação de um software integrado de Gestão da Saúde, com módulos específicos para administrar e gerenciar o sistema de saúde na cidade de Cajamar.

A modernização do sistema de saúde em Cajamar é uma iniciativa alinhada à Portaria nº 2.983, de 11 de novembro de 2019, que estabelece diretrizes para a informatização e uso de prontuários eletrônicos. Esta portaria, juntamente com o Decreto nº 8.789, de 29 de junho de 2016, que institui a Estratégia de Governo Digital no âmbito do Sistema Único de Saúde (SUS), e a Lei nº 13.787, de 27 de dezembro de 2018, que dispõe sobre a digitalização e o uso de sistemas informatizados para a guarda, o armazenamento e o manuseio de prontuários de pacientes, são fundamentais para a transformação digital da saúde em nosso município.

Os novos modelos de financiamento da saúde pública que vem sendo implementados pelo Ministério da Saúde, baseiam-se no controle de indicadores e no cumprimento de metas de produtividade por parte dos municípios, o que obriga a Secretaria de Saúde a adaptar a sua forma de trabalho a um modelo de gestão por indicadores e a necessidade de um suporte técnico especializado em gestão de saúde pública torna-se essencial. Muitos destes indicadores têm seus resultados apurados pelo ministério da saúde ao final de um quadrimestre, tornando inviável ao município corrigir desvios ao longo do exercício deste quadrimestre. A total integração dos serviços com o sistema de gestão garante que o município consiga realizar previsões em tempo real do resultado dos indicadores e tomar ações de correção de forma efetiva.

O sistema deve interligar, no âmbito da Secretaria Municipal de Saúde e em outros pontos de acesso, principalmente nas unidades de saúde. Essa interligação permitirá o funcionamento integrado e simultâneo de todos os setores, melhorando o fluxo e a integração das informações. Isso garantirá a disponibilidade das informações, além de reduzir os gastos com redundâncias de trabalhos. O sistema também deve possibilitar o processamento eficiente das informações e a integração de dados entre setores relacionados, como Unidades Básicas de Saúde, Atendimento na Atenção Básica, Atendimento Especializado em Saúde, e serviços de diagnóstico.

Espera-se obter uma base de dados completa e confiável sobre as informações de saúde do município

e sua população, melhorando assim o processo de tomada de decisão por meio do uso de ferramentas inteligentes. Essas ferramentas inteligentes, por sua vez, devem contribuir para aprimorar todos os aspectos dos indicadores de saúde do município.

A implementação de um sistema de saúde integrado em Cajamar é um passo significativo para alcançar uma saúde pública mais eficiente e humanizada, onde a tecnologia é uma ferramenta essencial para a promoção da saúde e bem-estar de todos os cidadãos.

Com o avanço da era tecnológica, principalmente do que diz respeito à área da saúde, há de se destacar que a Secretaria Municipal de Saúde de Cajamar vá ao encontro de novas tecnologias disponíveis no mercado.

Para isso, pretende-se contratar uma empresa especializada que forneça uma licença de uso da solução, abrangendo os serviços de Implantação, conversão, migração de dados, projeto assistido, treinamento de usuários, hospedagem em datacenter, suporte, manutenção, atualização, terminal de serviço e desenvolvimento de novas funcionalidades.

4. FUNDAMENTAÇÃO E DESCRIÇÃO DA NECESSIDADE DA CONTRATAÇÃO

A contratação de uma empresa especializada para atuar junto à Secretaria Municipal de Saúde de Cajamar é essencial para a modernização e eficiência dos serviços prestados. A empresa colaborará com a equipe técnica da Secretaria, seguindo as prioridades estabelecidas pela gestão municipal e dentro da rotina planejada para a execução das atividades.

A necessidade de modernização do sistema de saúde de Cajamar é uma iniciativa alinhada à Portaria nº 2.983, de 11 de novembro de 2019, que estabelece diretrizes para a informatização e uso de prontuários eletrônicos. Esta portaria, juntamente com o Decreto nº 8.789, de 29 de junho de 2016, que institui a Estratégia de Governo Digital no âmbito do Sistema Único de Saúde (SUS), e a Lei nº 13.787, de 27 de dezembro de 2018, que dispõe sobre a digitalização e o uso de sistemas informatizados para a guarda, o armazenamento e o manuseio de prontuários de pacientes, são fundamentais para a transformação digital da saúde em nosso município.

Com os novos modelos de financiamento da saúde pública implementados pelo Ministério da Saúde, que se baseiam no controle de indicadores e no cumprimento de metas de produtividade pelos municípios, torna-se imperativo que a Secretaria de Saúde adapte sua forma de trabalho a um modelo de gestão por indicadores. Neste contexto, o suporte técnico especializado em gestão de saúde pública é essencial. A integração total dos serviços com um sistema de gestão permite que o município realize previsões em tempo real dos resultados dos indicadores e tome ações corretivas de forma efetiva, evitando desvios ao longo do exercício quadrimestral.

O sistema deve interligar todos os pontos de acesso da Secretaria Municipal de Saúde, principalmente

as unidades de saúde, permitindo o funcionamento integrado e simultâneo de todos os setores. Isso melhorará o fluxo e a integração das informações, garantindo a disponibilidade das informações e reduzindo os gastos com redundâncias de trabalho. Além disso, o sistema deve possibilitar o processamento eficiente das informações e a integração de dados entre setores relacionados, como Unidades Básicas de Saúde, Atendimento na Atenção Básica, Atendimento Especializado em Saúde e serviços de diagnóstico.

Espera-se obter uma base de dados completa e confiável sobre as informações de saúde do município e sua população, melhorando o processo de tomada de decisão por meio do uso de ferramentas inteligentes. Essas ferramentas devem contribuir para aprimorar todos os aspectos dos indicadores de saúde do município, promovendo uma saúde pública mais eficiente e humanizada.

Com o avanço da era tecnológica, especialmente na área da saúde, é fundamental que a Secretaria Municipal de Saúde de Cajamar adote as novas tecnologias disponíveis no mercado. Para isso, pretende-se contratar uma empresa especializada que forneça uma licença de uso da solução, abrangendo serviços de implantação, conversão, migração de dados, projeto assistido, treinamento de usuários, hospedagem em datacenter, suporte, manutenção, atualização, terminal de serviço e desenvolvimento de novas funcionalidades.

A implementação de um sistema de saúde integrado em Cajamar representa um passo significativo para alcançar uma saúde pública mais eficiente e humanizada, utilizando a tecnologia como uma ferramenta essencial para a promoção da saúde e do bem-estar de todos os cidadãos.

5. SUSTENTABILIDADE

A contratação de uma empresa especializada para implementar um software integrado de Gestão da Saúde em Cajamar trará diversos benefícios de sustentabilidade. A digitalização dos prontuários e documentos de saúde elimina a necessidade de impressão, preservando recursos naturais e reduzindo o desmatamento. A centralização dos dados em datacenters modernos, eficientes em termos energéticos, diminui a pegada de carbono. A integração dos sistemas de saúde otimiza recursos, reduzindo a redundância de trabalhos e o desperdício de insumos médicos. Além disso, a digitalização minimiza a geração de resíduos sólidos e eletrônicos, promovendo uma gestão mais sustentável. A possibilidade de acesso remoto aos dados reduz a necessidade de deslocamentos, diminuindo as emissões de gases de efeito estufa. Em suma, a implementação do software promove práticas sustentáveis, beneficiando tanto o meio ambiente quanto a eficiência do sistema de saúde.

6. DO CRONOGRAMA DE EXECUÇÃO

A empresa Contratada deverá seguir o seguinte cronograma, durante a execução contratual:

ETAPAS DOS SERVIÇOS

MESES DE EXECUÇÃO

Licença de uso, Instalação de Software de Gestão de Saúde e Planejamento do Projeto

Implantação, conversão, migração de dados

Projeto assistido e Capacitação Continuada

Hospedagem em Datacenter

Atualização Mensal, Suporte e Manutenção

Desenvolvimento de customizações no sistema

7. DO PLANO DE GERENCIAMENTO DO PROJETO

Cada etapa da execução do processo de Implantação se dará por caráter documental entre as partes. Devendo sua execução prática e a documentação técnica estar orientada e aplicada através do PGP, tendo como fundamento documentar e garantir que todas as entregas contratadas sejam realizadas nos prazos firmados, sem se desprender da qualidade dos produtos, devendo estar estruturado em metodologia de boas práticas do mercado.

O Planejamento de Projeto não poderá ser superior a 30 (trinta) dias úteis, contados a partir da assinatura do contrato, devendo ser contemplado obrigatoriamente todos os requisitos constantes neste termo de referência.

A equipe destinada ao projeto deverá ser orientada pela metodologia de boas práticas do mercado, contemplando o modelo de gestão voltado ao conhecimento da Gestão Pública para gerir com eficácia o escopo, tempo, custo e qualidade do projeto a ser executado, resultando na gestão da qualidade desejado por este projeto, devendo ainda estabelecer comunicação transparente e objetiva com o coordenador de implantação bem como estar alinhado com a alta gestão desta municipalidade quanto ao andamento dos trabalhos.

Considerando a relevância dos serviços prestados ao cidadão, além de outras obrigações previstas no edital licitatório e seus anexos, a Contratante definirá gestor de contrato que ficará responsável pelo acompanhamento do Projeto de Implantação do sistema, com a observância de todas as cláusulas contratuais firmadas devendo estar em consonância com a equipe de gestão de projeto da Contratada. Dentre as atribuições do Gestor, destacam-se, mas não se limitam a:

• Planejar o projeto em conjunto com a CONTRATADA;

• Monitorar o andamento do projeto quanto ao escopo, tempo, qualidade, riscos, comunicação e controle integrado de mudanças do projeto;

• Atuar como principal elo de comunicação entre a CONTRATANTE e a CONTRATADA em assuntos relativos ao projeto;

• Ser responsável pela geração, coleta, distribuição e armazenamento das informações do projeto;

• Registrar, acompanhar e controlar as ações pendentes do projeto;

• Coordenar reuniões com as áreas envolvidas (para execução do projeto);

• Definir ações de contenção e/ou corretivas para desvios do projeto, dentro do seu limite de competência;

• Manter todos os envolvidos do projeto alinhados, tanto no âmbito técnico como no âmbito comportamental;

• Coordenar as ações para que os objetivos do projeto sejam alcançados;

• Aconselhar, apoiar e incentivar, técnica e comportamental, os demais profissionais das áreas envolvidas para cumprimento das atividades do projeto;

• Disponibilizar profissionais para a execução de atividades do projeto, conforme cronograma;

• Avaliar os resultados operacionais;

• Aprovar a realização de atividades do projeto, inclusive os relatórios produzidos no trabalho diário;

• Acompanhar e gerenciar atividades do projeto do ponto de vista da CONTRATANTE;

• Acompanhar e controlar as ações pendentes do projeto do ponto de vista do projeto;

• Definir o(s) responsável(is) pelos cadastros na Aplicação, bem como realizar as validações correspondentes;

• Garantir a disponibilidade de infraestrutura necessária para: 1) o serviço técnico, 2) a realização de treinamentos, 3) operação da Aplicação segundo a infraestrutura técnica apresentada pela CONTRATADA;

• Acompanhar e garantir a participação dos envolvidos em treinamentos a serem programados;

• Delegar situações para tomadas de decisão e aprovações de documentação do projeto, havendo a necessidade;

• Auxiliar o gerente de projetos da CONTRATADA e sua equipe no acesso às áreas envolvidas ao projeto;

• Aprovar os produtos/entregas do projeto;

• Manter todos os envolvidos do projeto alinhados, tanto no âmbito técnico como no âmbito comportamental.

8. DOS REQUISITOS DE GARANTIA E SEGURANÇA DA APLICAÇÃO

Deverá possuir minimamente na tela inicial do sistema, informações de versão, contendo obrigatoriamente o nome do software; nome do fornecedor; identificação da versão.

Possibilitar, a partir do número de versão do sistema, o resgate dos códigos-fonte correspondentes, possibilitando a rastreabilidade dos arquivos fontes que o geraram.

Deve ser possível efetuar operações de ‘reversões’ para versões anteriores. Indicações de eventual

incompatibilidade com versões anteriores devem ser exibidas em forma de aviso ao usuário antes da execução de atualizações e/ou correções e registradas em trilha de auditoria.

Manter um repositório estruturado com todas as versões do sistema (executáveis e códigos-fonte) que foram utilizadas em produção em algum momento, permitindo demonstrações, tais como, em auditorias, avaliações ou ações judiciais.

Identificar e autenticar a pessoa/usuária, antes de qualquer acesso à dados do sistema.

Utilizar, no mínimo, um dos seguintes métodos de autenticação: Usuário e senha e certificado digital e senha/PIN.

Armazenar de forma protegida, todos os dados ou parâmetros utilizados no processo de autenticação de pessoa.

Método: Usuário e senha:

A senha deve ser armazenada de forma codificada por algoritmo de hash aberto (público) de no mínimo 160 bits.

As codificações das senhas devem ser protegidas contra acesso não autorizado. Utilizar os seguintes controles de segurança:

a. Qualidade da senha: deve ser verificada a qualidade da senha no momento de sua definição pelo usuário obrigatoriamente utilizando, no mínimo, 8 caracteres dos quais, no mínimo 1 caractere deve ser alfabético e 1 numérico;

b. Periodicidade de troca de senhas: obrigatória a troca de senhas pelo usuário, em um período máximo configurável.

Os processos de troca de senha, devem exigir que a nova senha seja diferente da imediatamente anterior.

Quando da geração de senha que não seja definida pelo próprio usuário, tal processo deve impedir sua visualização por terceiros.

Possuir mecanismos para bloquear a conta do usuário após um número máximo configurável de tentativas inválidas de login, que não exceda a 10 tentativas.

Todo usuário do sistema deverá possuir um identificador único. Campos de identificação unívoca devem ser validados para garantir tal unicidade. Para isso, no momento da inclusão ou edição, o sistema deverá verificar a existência de duplicidade, comparando os identificadores unívocos deste usuário (ex: RG, CPF, número de identificação profissional etc.) com a base de usuários já existentes.

A sessão de usuário deve ser bloqueada ou encerrada após período de inatividade. O período máximo de inatividade deve ser configurável. Não deverá permitir usuário desativar ou desabilitar tais controles.

A sessão de comunicação remota deve possuir controles de segurança, a fim de não permitir o roubo

da sessão do usuário. Não deve ser permitido ao usuário desabilitar tais controles. Impedir acesso ao sistema, por pessoas não autorizadas.

Garantir que o acesso aos dados contidos na aplicação, seja somente possível por meio de canais de interação pré-definidos (ex.: web, console local, interface entre aplicativos), com atuação obrigatória de mecanismos de controle de acesso.

Permitir o gerenciamento (criação, inativação e modificação) de usuários e perfis, de forma a possibilitar o controle de acesso às funções, conforme os perfis aos quais o usuário possui. Um usuário pode possuir um ou mais perfis.

Disponibilizar mecanismos necessários para que seja possível implementar a política de controle de acesso através da configuração das permissões e restrições de acesso, considerando os perfis de usuário, funções e tipos de operação (consulta, inclusão e alteração). Cada perfil gerenciado deve permitir a associação com toda e qualquer função disponível na aplicação.

Garantir que haja ao menos um usuário responsável pela gestão de usuários, concessão de autorização e controle de acesso aos recursos de acordo com o escopo de atuação, a política organizacional e legislação.

Não permitir exclusão ou alteração de dados já existentes no sistema. Ações de correção ou edição devem preservar os dados previamente inseridos.

O Registro Eletrônico em Saúde, deve ser armazenado e protegido por um sistema de Gerenciamento de Banco de Dados (SGBD) ou sistema de Gerenciamento Eletrônico de Documentos (GED).

O acesso de usuários ao Registro Eletrônico em Saúde deve ser permitido somente por intermédio do componente de autenticação e controle de acesso à aplicação e, nunca diretamente pelo SGBD, exceto nas atividades de cópia de segurança. O SGBD não deve permitir acesso direto pelos usuários.

Componentes que manipulam dados do Registro Eletrônico em Saúde para fins de interoperabilidade, visualização, assinatura e outros, não devem manter tais dados fora do SGBD após o término da operação. Nota: como exemplos, pode-se citar o cache de arquivos PDF após a sua a visualização, e resquícios de arquivos XML ou DICOM (formato para armazenamento e transmissão de imagens médicas) após o seu processamento.

Os dados inseridos pelo usuário nos campos de entrada devem ser validados antes de serem processados, de forma a prevenir ataques de buffer overflow e injeção de dados. Nota: por exemplo, em aplicações baseadas em interface web, efetuar a validação de dados de forma a evitar os ataques descritos na seção de testes de segurança na aplicação web.

Gerar registros de auditoria de forma contínua e permanente, não sendo permitida a sua desativação ou interrupção, ainda que temporária.

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

Os registros de auditoria devem ser armazenados e protegidos por um SGBD.

A Aplicação deverá possuir manuais que apresentem minimamente as seguintes informações:

a) Instruções de uso do sistema para os usuários;

b) Visão geral do sistema de Gestão, incluindo formas de operação, requisitos do ambiente, papéis de usuários relevantes (por exemplo: administrador, operador, operador de backup etc.);

c) Instalação e configuração do sistema de Gestão de Saúde;

d) Instalação e configuração dos componentes complementares (ex: SGBD, sistema operacional etc.);

e) Recomendação sobre a forma de configuração segura e componentes complementares, e forma de operação segura do sistema.

Todos os manuais devem indicar claramente, no início do documento, seu versionamento e a versão a que se referem.

O manual deve informar como configurar o SGBD e todos os demais componentes do sistema, de forma a impedir o acesso de entidades (usuários ou outros sistemas) não autenticadas ou não autorizadas pelo controle de acesso.

Deve haver versão em português do Brasil para todos os manuais do sistema.

Os manuais devem conter informações e alertas sobre configurações inseguras do sistema.

Gerar e manter documento contendo o histórico descritivo das alterações realizadas em cada versão do sistema ("release notes"), contendo a data, modificações, impacto (módulos, funções, serviços afetados etc.), restrições de compatibilidade e o responsável pela alteração.

Basear todo registro de tempo em uma fonte de referência temporal sob controle do sistema, ou seja, utilizar a referência de tempo do servidor e não da estação do usuário.

A exportação de dados do sistema, incluindo sua impressão, deve ser permitida somente nas seguintes situações:

a) transmissão para um outro sistema;

b) cópia de segurança;

c) para o paciente, a pedido, podendo ser realizada de forma eletrônica ou impressa;

d) em processos nos quais seja necessária a impressão de parte ou todo do Registro Eletrônico em Saúde;

e) para atendimento ao requisito legal de manter documentação em papel, através da impressão. Todas as atividades de exportação de Registro Eletrônico em Saúde devem ser registradas.

9. DA ESTRUTURAÇÃO, MIGRAÇÃO, CONVERSÃO OU ALIMENTAÇÃO INICIAL DE BASES DE DADOS E TABELAS

A CONTRATANTE deverá após a assinatura do contrato, fornecer a base de dados existente à

CONTRATADA num prazo máximo de 5 dias para análise da conversão.

Os trabalhos operacionais de levantamento ou complementação dos dados cadastrais que forem necessários às implantações efetivas do sistema serão responsabilidade da prefeitura, sob orientação e suporte da empresa provedora do sistema.

A CONTRATADA deverá efetuar as devidas, estruturações, conversões e migração de dados. A comprovação da migração dos dados cadastrais será aceita pela equipe gestora da prefeitura devendo entregar a CONTRATADA o TERMO DE ACEITE DA CONVERSÃO E MIGRAÇÃO DE DADOS.

A instalação consiste na disponibilização online do sistema para a posterior preparação, cadastramento, parametrização e capacitação dos usuários finais, visando à operacionalização do sistema, compreendendo uma das fases de implantação do sistema de gestão informatizado.

O software aplicativo deverá ser disponibilizado para utilização dos usuários na plataforma 100% WEB. Deverá ser instalado em Data Center fornecido pela CONTRATADA, após a assinatura do termo de contrato, observando o prazo de instalação não superior a 30 (trinta) dias.

10. DO SERVIÇO DE HOSPEDAGEM DO SISTEMA EM DATACENTER

Centro de hospedagem de dados é caracterizado pela disponibilização de Data Center detentora de infraestrutura profissional com serviços especializados para prover a hospedagem da aplicação e banco de dados do sistema de gestão informatizado 24 horas por dia x 07 dias por semana devendo atender máxima garantia de segurança das transações executadas.

A CONTRATADA deverá administrar o(s) servidor(es) em que será(ão) instalado(s) o sistema, podendo estar alocada fisicamente em infraestrutura própria ou estar em infraestrutura subcontratada (sem prejuízo das responsabilidades contratuais e legais nos termos do artigo 122 da Lei nº 14.133/21).

Por meio da equipe da CONTRATADA, por profissional especialista, será responsável por gerenciar, instalar, configurar, atualizar e monitorar o SGDB - Sistema Gerenciador De Bancos De Dados, durante a vigência de contrato.

Nesta função, consistem nas seguintes atividades:

a) Criação e testes de backup para garantir a recuperabilidade dos dados no caso de falha de hardware ou outros problemas severos, devendo ser observados os seguintes procedimentos:

b) A configuração e programação dos backups das bases de dados para que sejam feitas cópias de segurança, com regularidade, de todos os dados utilizados pelo sistema;

c) Testes periódicos em conjunto com a CONTRATANTE referentes à restauração dos backups para validação do método utilizado para garantir a segurança na restauração em casos de desastre;

d) Realizar e modificar a estrutura do banco de dados quando necessário;

e) Verificar e zelar pela integridade do banco de dados;

f) Realizar controle de acesso ou privilégios aos dados, tais como: quem pode acessar, o que pode acessar e talvez, quando pode acessar;

g) Garantir o máximo de desempenho para as consultas ao banco de dados;

h) Realizar auxílio à equipe de suporte técnico em caso de certos problemas com o banco de dados;

i) Os dados armazenados em banco deverão estar criptografados, a fim de dificultar a identificação de qualquer registro, em caso de vazamentos.

Fica a CONTRATADA obrigada a fornecer, mediante solicitação da CONTRATANTE ou ao término do contrato, realizar a migração do banco de dados em sua integra para servidor da Contratante e validado pela mesma.

11. DA METODOLOGIA DE IMPLANTAÇÃO DO SISTEMA DE GESTÃO DA SAÚDE

A implantação do sistema se iniciará após a emissão do Termo de Aceite da Conversão e migração dos dados do Cliente. A CONTRATANTE se compromete a entregar cada unidade a ser informatizada com todas as condições de infraestrutura, seja de hardware, conectividade e pessoal com conhecimento de informática para o início da implantação e treinamentos conforme cronograma definido.

Entende-se como implantados o conjunto de serviços necessários para instalar, migrar os dados legados e do treinamento da equipe de profissionais por parte da CONTRATANTE, visando sua entrada em produção para uso nas unidades de saúde.

A empresa fornecedora deve possuir e usar metodologia própria para orientar e controlar o processo de implantação do sistema. Devendo após a assinatura do contrato efetuar um levantamento de infraestrutura, profissionais e fluxo de trabalho de todas as unidades elencadas neste documento.

Deverá possibilitar aos usuários obter informações operacionais e gerenciais, em tempo real, através de consultas e relatórios, visando a sustentação de ações rápidas e decisões estratégicas e eficazes. Os módulos e funcionalidades do sistema deverão ser totalmente integrados, ou seja, todas as informações deverão ser atualizadas em tempo real, no momento de sua inserção.

O SGBD deverá conter ferramentas que garantam a segurança e proteção das informações, que permitam a recuperação de dados de transações equivocadas realizadas por usuário do sistema, devendo este processo ser automático e seguro.

Possuir rotinas gerenciadas de backups dos dados e aplicativos, e procedimentos de recuperação com possibilidade de recuperação até momentos antes da parada em caso de paradas inesperadas do banco de dados.

Sempre que julgar necessário, a CONTRATANTE poderá solicitar o Backup completo de todos dados armazenados pela Contratante com Dicionário de Dados, ou qualquer outro artefato necessário para

a correta interpretação e utilização do banco de dados.

12. DO SERVIÇO DE ATUALIZAÇÃO MENSAL, SUPORTE E MANUTENÇÃO

O suporte técnico remoto deverá ser prestado pela empresa contratada mediante a disponibilização de uma central de atendimento ao cliente, sendo o mesmo disponibilizado, no mínimo, 08 (oito) horas por dia de segunda a sexta-feira (dias úteis), sem limites de chamados mensais.

O suporte técnico deverá ser realizado por: contato telefônico, pela web, através de sistema específico de atendimento técnico próprio ou terceirizado, ferramenta de conversação on-line, acesso remoto e e-mail.

Não estão compreendidos como serviços de suporte técnico: diagnósticos de infraestrutura, serviços de rede, serviços em servidores, serviços em aplicativos ou sistemas de terceiros e geração de informações para sistemas de terceiro.

A empresa vencedora deverá oferecer a garantia de atualização dos serviços propostos pelo período de vigência do Contrato, que corresponde a 12 (doze) meses ou até seu encerramento.

O suporte técnico remoto e manutenção do sistema deverá, minimamente, contemplar: Manutenção e atualização do sistema, correção de erros e bugs; Manutenção preventiva e de segurança da informação; Manutenção e suporte de backups de dados; Suporte remoto ao usuário.

SLA - ACORDO DE NÍVEIS DE SERVIÇOS: Os serviços de Suporte, deverão atender o Acordo de Níveis de Serviços para a solução de problemas reportados pela Contratante.

Os problemas serão categorizados por nível de criticidade, segundo a tabela a seguir:

ÍVEL

DESCRIÇÃO

EMPO

ÍTICA

tema está fora de operação ou há um impacto crítico nas operações dos negócios. Plataforma de serviço parada impactando diretamente grande parte dos serviços. A SECRETARIA DE SAÚDE e a CONTRATADA irão dispor de todos os recursos necessários para solução do problema, em período integral, para que o problema

seja resolvido.

horas

ALTA

ndo o problema impacta, sem paralisar, uma função ou atividade vital do negócio, sem prejuízos imediatos;

horas

ÉDIA

tema está funcionando com pequenos problemas sem impacto direto na operação. Prioridade dada ao problema que tem pouco impacto na operação do sistema, sem quebra de funcionalidade ou de operação.

1 a 5 dias úteis

AIXA

erformance operacional do sistema está prejudicada, mas todos os serviços continuam em funcionamento. O problema tem pouco ou nenhum impacto na

operação do sistema, sem quebra de funcionalidade ou de operação.

a 20 dias úteis

As manutenções de baixa complexidade, consideradas como parametrizações ou customizações, deverão ser atendidas sem custos adicionais para a CONTRATANTE, e deverão possuir prioridade menor que as manutenções legais e corretivas.

A CONTRATADA deverá disponibilizar um Portal de Atendimento em domínio público na internet para abertura de chamado, disponibilizando interface com campos adequados para preenchimento de informações com intuito de detalhar o problema enfrentado, e-mail de contato.

O Portal de Atendimento da CONTRATADA deve estar à disposição da CONTRATANTE em para recebimento de reclamações e solicitações de serviços no período de 24 horas por dia, 7 dias por semana, 365 dias.

O acompanhamento deve ser on-line para os chamados abertos e através de relatórios gerados sob demanda para os chamados encerrados e, deve fornecer todas as informações de um chamado ou de um conjunto de chamados. Os relatórios devem apresentar informações históricas em base anual.

Os registros dos chamados deverão conter todas as informações relativas ao chamado aberto, como tempo de início e fim de atendimento, identificação do elemento (equipamento, enlace ou serviço) afetado, nome, fone e e-mail do contato da CONTRATANTE que foi posicionado acerca do reparo e restabelecimento do serviço com a descrição detalhada da resolução do chamado.

Deve ser realizada a análise de causa raiz para incidentes críticos e elaborado plano de ações para correção definitiva do problema.

13. DO SERVIÇO DE DESENVOLVIMENTO DE CUSTOMIZAÇÃO NO SISTEMA

Este serviço destina-se ao atendimento específico a novos processos não contemplados neste descritivo, objetivando implementar customizações no sistema, a fim de, adequar, melhorar funcionalidades e particularidades do município.

O serviço de desenvolvimento a serem demandado, somente será executado pela CONTRATADA mediante escopo de levantamento de requisitos aprovado e assinado pelo representante da CONTRATANTE, que solicitou o serviço.

Os serviços de desenvolvimento serão executados de modo remoto nas dependências da CONTRATADA, devendo, serem apresentadas as evidências das atividades realizadas sempre que envolvam a aprovação da CONTRATANTE.

O desenvolvimento será calculado pela quantidade de horas empreendidas na realização da atividade concluída, conforme perfis dos profissionais envolvidos constantes da tabela apresentada na proposta da Contratada.

14. DOS SERVIÇOS DE PROJETO ASSISTIDO E CAPACITAÇÃO CONTINUADA

A licitante vencedora deverá realizar treinamento, durante o processo de implantação, para os servidores da Contratante que utilizarão o sistema. Para a execução do treinamento deverão ser consideradas as seguintes especificações:

• Disponibilizar instrutor(es) qualificado(s) para ministrar os treinamentos, com sólida experiência no assunto. Devendo substituí-los a critério da Secretaria Municipal de Saúde, caso os mesmos não cumprirem satisfatoriamente os objetivos do treinamento.

• As capacitações ocorrerão por módulos limitados a quantidade de 20 (vinte) servidores.

• Todos os treinamentos deverão ser presenciais.

• A capacitação deverá ser realizada com carga horária mínima de 08 (oito) horas e máxima de 40 (quarenta) horas de acordo com a complexidade de cada sistema, cujo cronograma deverá ser acordado e homologado pela Contratante.

• As instalações físicas, equipamentos e materiais necessários para a aplicação dos treinamentos serão providenciados e disponibilizados pela contratante.

• Diariamente a Contratada deverá disponibilizar lista de presença dos servidores que compareceram as atividades, as quais deverão ser assinadas pelos presentes.

• Ao final de cada treinamento a Contratada deverá realizar processo de avaliação sobre o treinamento realizado, objetivando a avaliação no mínimo do conteúdo treinado e do instrutor.

• Os custos inerentes às despesas de hospedagem, alimentação e transporte serão arcados pela contratada.

• Estima-se 210 funcionários a serem inicialmente treinados.

Transcorrida a etapa de implantação e expedido o Termo de Treinamento, caso a contratante requeira a realização de novos treinamentos in-loco os mesmos serão deveram ser solicitados pelo gestor do contrato.

Os treinamentos ocorrerão na própria unidade de saúde ou em local indicado pela Contratante, à medida que forem sendo concluídas as implantações nas unidades contempladas e, sempre que houver necessidade, novos treinamentos podem ser solicitados pela Contratante.

Os treinamentos deverão conter: escopo previamente definido, carga horária definida e serem suportados por material didático com conteúdo específico, equipamentos, instrutores, métodos suficientes e adequados para cada módulo/processo abrangendo os níveis funcionais e gerenciais.

Projeto Assistido: O fornecedor deverá proceder não somente à capacitação no uso do sistema, como também o acompanhamento (Projeto Assistido) dos servidores usuários no uso do sistema.

O projeto compreende auxílio da equipe da Contratada na operação e administração do sistema, levantamento de requisitos para formalização e desenho de escopo para o desenvolvimento de novas funcionalidades, relatórios ou parametrizações que sejam necessários ao longo do contrato.

A CONTRATADA deverá manter equipe técnica necessária nas dependências da CONTRATANTE de forma a atender in-loco os usuários das Unidades e da Secretaria, para atendimento das demandas internas da secretaria, de segunda à sexta-feira das 8H00 às 17H00 diariamente, e sobreaviso das 17:01 às 07H59 de segunda à sexta-feira. Nos sábados, domingos e feriados deverá ser disponibilizado atendimento a nível de plantão 24hs.

A equipe local deverá realizar serviços como:

• Garantir uma solução rápida para questões técnicas relativas à equipamentos de hardwares, como: totens, painéis de senha, terminal de informática e terminal leitor de dados.

• Auditar os processos de atendimentos nas unidades, apontando o que pode ser melhorado, através de treinamentos, orientações e o suporte.

• Elaboração de escopos/requisitos de solicitações efetuadas pelo cliente.

• Elaboração de requisitos para novas modificações/ ou novas funcionalidades.

• Visitas as unidades para verificar a usabilidade do sistema in loco.

• Homologações e testes de novas versões e funcionalidades.

• Definição e manutenção do controle de acesso aos recursos.

• Configurar as contas de correio eletrônico (E-mail).

• Auxílio administrativo para atendimento às demandas internas da rede.

• Suporte ao paciente para realizar a consulta, (teste de áudio, vídeo e imagens), passar todas as orientações para a realização da consulta.

• Impressão de resultados de exames, guias e documentos pertinentes a realização da consulta.

• Apoio na gestão do atendimento aos pacientes para o médico.

• Suporte técnico ao médico, para usabilidade dos sistemas/processos e problemas técnicos.

• Imprimir documentos.

• Assistir aos clientes internos nos assuntos referentes ao funcionamento dos sistemas de Tecnologia da Informação.

• Administrar a “fila” de solicitações de suporte e disponibilizar recursos de TI para atendimento condizente com as prioridades acordadas com as áreas usuárias.

• Implementar e executar processos, procedimentos e controles internos necessários para gestão eficiente dos sistemas, compatível com as metas da empresa.

• Garantir alinhamento das funcionalidades e disponibilidade do sistema de acordo com os requisitos de operação.

• Garantir desenvolvimento e retenção de conhecimento técnico visando minimizar os tempos de solução de incidentes e problemas.

• Conduzir a equipe de suporte na identificação de causas raiz, e na busca por soluções definitivas.

• Aplicar medições de satisfação dos clientes visando melhoria contínua.

• Acompanhamento diário da equipe dos analistas de suporte.

• Responsável pela distribuição dos chamados entre a equipe.

• Monitoramento do sistema em sua usabilidade, no que diz respeito a rotina mensal estipulado pelo cliente aos módulos de faturamento, módulo atendimento, módulo de cadastro e relatórios.

• Realizar reunião semanal com a equipe de analistas para planejamento e execução de ações que forem necessárias.

15. DO SIGILO E DA CONFIDENCIALIDADE – APLICAÇÃO DA LEI GERAL DE PROTEÇÃO DE DADOS – LGPD (Nº 13.709/2018)

A futura CONTRATADA, seus administradores, empregados, prepostos e contratados obrigam-se a manter o mais completo e absoluto sigilo em relação a toda e qualquer informação a que tenham acesso, não podendo, sob qualquer pretexto, utilizá-las para si, divulgar, reproduzir ou delas dar conhecimento a terceiros, inclusive após o término da prestação de serviços. Considerando que de acordo com o art. 5º, II da Lei Geral de Proteção de Dados (LGPD) – Lei 13.709/2018, os dados a que a futura contratada terá acesso são considerados dados sensíveis, a contratada deverá atender e seguir os preceitos vigentes.

16. DOS ASPECTOS TECNOLÓGICOS DO SISTEMA DE GESTÃO INFORMATIZADO

Consiste no detalhamento tecnológico em que o sistema de gestão informatizado deverá se apresentar para pleno atendimento da rotina de trabalho operante nas unidades de saúde do município.

O Detalhamento Tecnológico integra, obrigatoriamente, os seguintes aspectos e requisitos:

O sistema deverá ser disponibilizado em sua totalidade, em idioma português brasileiro e conter os recursos necessários para que a Contratante obtenha a gestão completa dos processos administrativos, operacionais e estratégicos inerentes ao objeto, devendo ser atualizado conforme a necessidade de atendimento as legislações vigentes e exportações de informações ao Ministério da Saúde e à Secretaria de Estado de Saúde.

O sistema deve obrigatoriamente ser desenvolvido de maneira modular, integrados a um único banco de dados, visando ter melhor desempenho na consolidação de informações e maior agilidade em manutenções.

O compartilhamento dos dados dos pacientes com secretarias e ministério da saúde se dará através de integração com e-SUS e faturamento de produção, em conformidade com as normas de regulação e segurança do e-SUS.

Deverá utilizar sistema gerenciador de banco de dados relacional padrão ANSI/SQL, PostgreSQL sendo que em caso de Banco de Dados proprietário, o mesmo deverá ser fornecido junto ao sistema.

Deve ser totalmente desenvolvido em tecnologia 100% compatível para utilização em ambiente WEB, acessados utilizando-se os principais navegadores de acesso à internet do mercado como Internet Explorer, Mozzila Firefox, Google Chrome, Safari, nas suas versões mais recentes.

Não serão aceitas soluções desenvolvidas no modelo cliente-servidor, ou baseadas em servidor tipo mainframe com acesso por emuladores de terminal.

O sistema deverá manter a integridade referencial entre as tabelas que compõem a base de dados em nível do SGBD.

O sistema deverá estar em conformidade com leis Municipais, Estaduais ou Federais no que regem a proteção de dados e a segurança da informação, como a LGPD (Lei Geral de Proteção de Dados) e a Política de Segurança da Informação do Município, ficando a CONTRATADA responsável por se enquadrar nas regras, enquanto estas estiverem em vigor.

Os dados pessoais tratados por este Termo de Referência e seus anexos estão em conformidade com as políticas de tratamento da Lei Geral de Proteção de Dados – LGPD - Lei Federal 13.709/2018. O envio de dados pessoais, por este sistema integrado ou outro meio, tem como base legal a execução do contrato, podendo assim o Município de Cajamar/SP tratar os dados pessoais recebidos, bem como compartilhar esses dados com as secretarias e órgãos governamentais competentes, com a finalidade específica de atender as necessidades do envio de informações e índices de produtividade.

Deverá garantir a integridade referencial, consistência, atualidade e inviolabilidade dos dados.

Deverá ser integralmente baseado no conceito de controle de transações, mantendo a integridade do banco de dados, em caso de quedas de energia e falhas de software/hardware.

Deverá garantir a atualização on-line dos dados de entrada, permitindo o acesso às informações atualizadas imediatamente após o término da transação.

O sistema deverá permitir rastreabilidade das operações realizadas pelos usuários do sistema, através da auditoria dos registros de dados – Log.

O Sistema deverá controlar senhas de acesso que garanta armazenamento destas de forma criptografada em nível do banco de dados.

17. DAS ESPECIFICAÇÕES MÍNIMAS FUNCIONAIS DO SISTEMA

Segue a estrutura mínima e obrigatória dos requisitos funcionais em que o sistema de gestão

informatizado deve conter.

A funcionalidades e suas respectivas subfunções exigidas neste Termo de Referência deverão estar contidas em um único banco de dados, visando ter melhor desempenho na consolidação de informações e maior agilidade em manutenções, não sendo aceito uma ou várias macro funcionalidades e/ou subfuncionalidades de trabalho e/ou parte do sistema tenha seu funcionamento em banco de dados desagregados.

As funcionalidades deverão ser acessíveis somente aos usuários autorizados especificamente a cada uma delas. Para cada funcionalidade autorizada, o administrador de segurança poderá alterar o perfil de acesso, modificando as ações que estão disponíveis para cada funcionalidade. Exemplo: Consulta, Inclusão.

Organizar os dados e informações do Registro Eletrônico em Saúde em diferentes seções para facilitar a navegação e consultas em tela, segundo os papéis do usuário e suas necessidades e expectativas.

Garantir que todo dado apresentado em mais de um lugar ou mais de uma maneira, seja sempre referenciado ao mesmo rótulo, evitando ambiguidade de interpretação. Exemplo: garantir que “pulsos pediosos: não” tem o mesmo significado que “pulsos pediosos: ausentes”.

Garantir o compartilhamento do Registro Eletrônico em Saúde com independência de hardware, software (aplicativos, sistemas operacionais, linguagens de programação), bancos de dados, redes, sistemas de codificação e linguagens naturais. Exemplo: parâmetros de regras de validação no banco de dados e não embutidos no código dos aplicativos.

Possibilitar que os dados e informações estejam organizados e passíveis de recuperação de tal forma que facilite os usos secundários do Registro Eletrônico em Saúde, tais como: gestão de processos, auditoria de processos, faturamento de procedimentos e pesquisa científica, entre outros.

Armazenar em listas todos os dados, que possuam registro de tempo, de tal forma que a ordem cronológica esteja preservada sempre que os dados forem apresentados, como por exemplo em uma consulta em tela ou impressão em PDF.

Registrar o código, a descrição do sistema de classificação/codificação utilizado, a versão, o idioma original e a descrição original no registro de um código de um sistema de classificação/codificação.

Registrar dados em tabelas representando matrizes, quando aplicável, de tal forma que os relacionamentos dos dados com as linhas e colunas estejam preservados no banco de dados, com total independência dos aplicativos. Exemplo: audiograma; registros de pressões arteriais de membros superiores e inferiores com paciente em pé, sentado e deitado.

Registrar dados simples, preservando a associação entre nome do dado e respectivo valor. Exemplo: a pressão sistólica deve estar associada ao campo correspondente.

Armazenar parâmetros, configurações e classificações/codificações em banco de dados e não em linhas de código da aplicação. Exemplos: período máximo de validade de senha; período máximo de

inatividade para bloqueio de sessão; e limites de temperatura axilar para validação.

Registrar os episódios de atenção e os seus processos, preservando a associação dos dados registrados a cada um destes episódios. Exemplo: associação de uma prescrição medicamentosa a uma consulta; evolução clínica específica; resultado de exame complementar a uma sua solicitação específica; execução de procedimento cirúrgico; internação hospitalar; e realização de exame invasivo de imagiologia ou avaliação de risco ambiental.

Armazenar dados clínicos estruturados e não estruturados.

Registrar com acurácia o tempo associado a um determinado evento. O registro do tempo do momento de registro no banco de dados deverá ser automático. O registro do tempo do evento poderá ser editável, possibilitando, por exemplo, o registro retroativo de ações passadas. Exemplo: registro de uma consulta ocorrida em momento de falha no fornecimento de energia elétrica às unidades prestadora de serviços.

FUNCIONALIDADES:

1. O sistema deverá permitir a integração por API ao Sistema de Telesaúde utilizado no município, a qual deverá ocorrer pelas parametrizações de agenda e por tipo de vaga.

2. O sistema deverá permitir ao usuário o disparo manual da rotina de reserva de vagas de regulação, das solicitações em fila de espera.

3. O sistema deverá possuir parâmetros para definição das buscas dos munícipes em telas de atendimentos e filtros para localização dos cadastros, podendo ser por informações especificas, ou sem critérios, trazendo a partir de informações associadas.

4. O sistema deverá permitir configurar o cabeçalho dos arquivos de faturamento BPA e RAAS. Possuir campos necessários para validação do cabeçalho do arquivo.

5. O sistema deverá permitir configurar o número de dias para visualização de agendamentos.

6. Possuir parâmetros para apontamento do período máximo de visualização e lançamentos dos registros retroativos.

7. O sistema deverá permitir a inclusão e alteração do brasão do município.

8. Deverá permitir a inclusão de campo comentário/observação na configuração de horários, podendo ser utilizado em agendas com ou sem procedimento.

9. Deverá permitir parametrizar agendas com horários flutuantes.

10. Deverá permitir desfazer reservas de pré-agendamentos, efetuadas através da rotina de reserva de vagas.

11. O sistema deverá exibir a data/hora e usuário da última inicialização, manual de execução da fila de espera de regulação.

12. O sistema deverá exibir a data/hora e usuário do último processo desfeito da rotina de pré- agendamento de vagas da regulação.

13. O sistema deverá permitir habilitar obrigatoriedade de CID por Especialidade e por Procedimento nas solicitações de regulação.

14. O sistema deverá permitir configurar dias para exibição para regulação.

15. O sistema deverá permitir configurar a obrigatoriedade da inclusão do profissional solicitante da solicitação inclusa na fila de regulação.

16. O sistema deverá dispor de parâmetro que permita incluir solicitações com a especialidade ou procedimento, sem a necessidade de haver agendas ativas para estes.

17. O sistema deverá possuir campo para definir qual a unidade principal reguladora, utilizada como central de regulação.

18. O sistema deverá possuir parâmetro para desativação das rotinas automáticas de regulação.

19. Deverá possuir parâmetros de cotas por procedimento, limitando a uma determinada quantidade máxima de inclusões.

20. Deverá possibilitar a definição da unidade de centralização dos almoxarifados, para uso dos processos de estoque.

21. Deverá possibilitar a definição do centro de custo para balancete.

22. Deverá possibilitar a configuração do fornecedor de envio de SMS.

23. Deverá possibilitar a configuração em dias, do tempo de expiração da senha dos usuários.

24. Deverá permitir configurar o usuário e senha do Webservice do CNES.

25. Possuir parâmetro para acionar a consolidação automática de munícipes com cadastros duplicados.

26. Permitir a configuração das impressoras que serão utilizadas.

27. Permitir a configuração dos leitores de código de barras e leitores biométricos.

28. Possuir parâmetros para definir previamente o que será exibido no campo de “tipo de atendimento”, presente na ficha de atendimento individual e-SUS.

29. O sistema deverá permitir configurar a fila e a categoria para chamada de senha no serviço de Urgência e Emergência.

30. Permitir configurar as opções de segurança da aplicação, sendo elas: Tempo de Inatividade para expiração de sessão; tempo para expiração de senhas; tamanho mínimo de senhas; tentativas de login; tempo para inativação de usuário por unidade.

31. O sistema deverá permitir configurar as unidades de saúde, que farão uso do aplicativo de

agendamento de consultas e de vacinação.

32. O sistema deverá permitir configurar as unidades de saúde, que farão uso do portal de agendamento de consultas e de vacinação.

33. O sistema deverá permitir liberar as especialidades disponíveis, para atendimento por unidade de saúde.

34. O sistema deverá permitir configurar a periodicidade de agendamentos, no portal e/ou aplicativo por especialidade e unidade de saúde.

35. Possibilitar o envio de SMS das consultas agendadas.

36. Permitir a customização do SMS a ser enviado.

37. Permitir que seja configurado o tempo (intervalo) em que o SMS será enviado.

38. Deverá permitir a configuração de mais de um tipo de texto/lembrete, referentes aos agendamentos, que são enviados através de SMS (quantidade ilimitada).

39. Deverá permitir a configuração de envio de SMS por unidade, permitindo que cada unidade tenha configurações e mensagens customizadas.

40. Deverá permitir a configuração do envio de SMS de acordo com as seguintes situações: Pedido de Confirmação, Confirmação de Agendamento, Cancelamento de Agendamento, Lembrete, Alerta de Cancelamento e Aviso de Cancelamento.

41. Deverá permitir o cadastro dos termos de uso, informando o título do termo e o texto.

42. Deverá possibilitar a formatação do texto do termo, dispondo de caixa de ferramentas.

43. Deverá armazenar e exibir histórico de criação e alteração de termos de uso.

44. Deverá permitir a edição de um termo de uso anterior.

45. Deverá exibir em tela de cadastro pop-up com o termo cadastrado.

46. Deverá dispor de botão para aceite do termo de uso, “Li e concordo com os Termos Apresentados acima!”.

47. Deverá dispor de botão de recusa “não aceito”.

48. Deverá dispor de botão “continuar” para seguir para uma tela de seleção da unidade após aceitar o termo de uso.

49. O termo de uso deverá estar disponível para login do aplicativo “Atenção Primária”.

50. Deverá armazenar informações de usuário que aceitaram ou não o termo de uso, para definir se o mesmo deve ser exibido novamente no próximo login.

51. O sistema deverá permitir a configuração dos grupos de procedimentos que serão disponibilizados nas guias SADTs.

52. O sistema deverá permitir a configuração dos grupos de procedimentos que serão disponibilizados nas guias de encaminhamentos, a partir dos tipos de acesso.

53. O sistema deverá permitir a configuração das especialidades que poderão ter inclusão duplicadas, no momento da inserção de solicitações em fila de espera.

54. O sistema deverá permitir a configuração dos procedimentos que poderão ter inclusão duplicadas, no momento da inserção de solicitações em fila de espera.

55. O sistema deverá permitir a configuração dos procedimentos disponíveis para solicitação de regulação.

56. O sistema deverá permitir configurar os documentos que serão assinados digitalmente.

57. O sistema deverá permitir a configuração de documentos assinados por unidade de saúde e tipo de documento, sendo eles: Atestado; Encaminhamento para Especialidade; Ficha de Atendimento; Guia SADT; Receituário e Receituário Especial.

58. Deverá possuir rotina que permita realizar a unificação de cadastros de munícipes duplicados, de forma manual ou automática.

59. Deverá possuir rotina que permita realizar a unificação de cadastros duplicados de munícipe de forma manual, podendo ser utilizado como critério Cartão provisório, Cartão social, CNS e nome, bem como, comparação por nome, nome da mãe e data de nascimento.

60. Deverá possuir rotina que permita realizar a unificação de cadastros duplicados de profissional de forma manual, podendo ser utilizado como critério CNS, nome e nome da mãe, bem como, comparação por nome, nome da mãe e data de nascimento.

61. O sistema deverá permitir que os dados do CNES sejam importados através de interoperabilidade com webservice.

62. Deverá permitir importar os Arquivos XML do CNES; Arquivos do SIA-SUS; Arquivos do SIGTAP.

63. O sistema deverá possuir opções para alteração da disposição dos menus.

64. Deverá permitir a personalização dos Menus, no qual o administrador do sistema poderá mudar os nomes dos Menus e suas funcionalidades, bem como, alterar a posição dos itens dos Menus.

65. Deverá possuir opções para novas inclusões de funcionalidades nos menus, permitindo ajuste da rotina, adequado ao uso da CONTRATANTE.

66. O sistema deverá permitir o cadastro de campanhas da prefeitura, para comunicação aos usuários do aplicativo.

67. O sistema deverá permitir a definição de vigência da campanha cadastrada; a descrição da campanha, o tipo de conteúdo, podendo ser esse em formato HTML, URL para link externo, ou um bloco de texto aberto para digitação de acordo com a preferência do usuário.

68. Deverá ser obrigatória a seleção de imagem, para ilustrar a campanha no aplicativo.

69. Permitir a criação de campanhas de vacinação para agendamento via APP.

70. Apresentar interface para criação de perfis de usuários.

71. Deverá permitir que os perfis criados, sejam vinculados aos cadastros dos usuários.

72. Deverá permitir configurações de temas, para modificar o layout, onde é possível alterar a cor, incluir imagem e incluir frases.

73. Deverá permitir configurações de temas, com intervalos definidos (período de dias), para utilização deste, onde os temas são substituídos de forma automática, de acordo com cada período definido.

74. O sistema deve dispor de um tema padrão, para quando não houver um tema habilitado para o dia ou período atual, este será fixado sob os menus.

75. Deverá permitir a inclusão e edição das informações referentes as versões do sistema.

76. Deverá permitir inclusão de guias de utilização de cada versão disponível em base de produção.

77. Deverá exibir as informações das versões na tela inicial do sistema.

78. Deverá permitir a inclusão de documentos como manuais, guias, portarias etc. para uso dos usuários do sistema.

79. Deverá deixar disponível para download todos os documentos anexados ao sistema.

⮚ TELESAÚDE:

80. O sistema deverá conter plataforma de chat online, entre os usuários do sistema e o suporte de TI contratado.

81. O sistema deverá exibir na tela principal: número de pacientes cadastrados; número de unidades de saúde cadastradas; número de profissionais cadastrados e número de usuários cadastrados na plataforma.

82. O sistema deverá exibir por usuário o histórico de acessos, contendo: Usuário; data e hora do acesso e/ou tentativa de acesso; status (Sucesso ou Falha) e mensagem informativa de login ou falha no acesso.

83. O sistema deverá permitir ao usuário logado, a confirmação e edição dos dados cadastrais: nome completo; data de nascimento; CPF; Celular, E-mail.

84. O sistema deverá permitir ao usuário logado a alteração da senha de acesso.

85. O sistema deverá permitir o cadastro de novos pacientes, contendo os campos: nome; nome social; CPF; cartão nacional de saúde; celular; data de nascimento; CEP; logradouro; número; bairro; cidade; estado, complemento; e-mail.

86. O sistema deverá conter como campos mínimos e obrigatórios as informações de: nome, celular, data de nascimento, CEP e e-mail.

87. O sistema deverá permitir a busca por pacientes.

88. Permitir a edição dos dados cadastrais do paciente.

89. Permitir agendar uma Teleconsulta para o paciente.

90. Permitir visualizar o histórico de registros de documentos preenchidos para o paciente, exibindo as informações: Profissional responsável pelo preenchimento; procedimento agendado de Tele Saúde; data e hora da criação do documento. Permitir efetuar download dos documentos preenchidos.

91. Listar os SMS enviados para o paciente, exibindo as informações: status do SMS; data e hora de agendamento; data e hora do envio do SMS; conteúdo do SMS e o número (celular) receptor do SMS enviado.

92. O sistema deverá permitir o cadastro de novo usuário.

93. O sistema deverá conter os campos mínimos para cadastro: nome completo; login; senha; confirmação de senha; data de nascimento; CPF; celular; e-mail e perfil de acesso.

94. Deverá permitir a edição dos dados cadastrais do(s) usuário(s) cadastrados.

95. Deverá permitir o bloqueio de acesso do(s) usuário(s) cadastrados.

96. Para os profissionais de saúde, O sistema deverá possuir campos de preenchimento obrigatório para registro, contendo: tipo de conselho do profissional; número do conselho do profissional; UF do conselho e a situação.

97. Deverá permitir aos profissionais de saúde a importação do certificado digital formato A1, para assinatura dos documentos eletrônicos.

98. O sistema deverá permitir a configuração da URL, com o domínio para a página de videoconferência.

99. Deverá permitir a configuração da URL, com o domínio para a página de documentos do paciente.

100. Deverá permitir a configuração da URL, com o domínio para página de recuperação de senha do usuário.

101. Deverá permitir ao usuário a parametrização da mensagem exibida para preenchimento da pesquisa de satisfação do atendimento de Teleconsulta.

102. Deverá permitir a configuração do fornecedor de envio de SMS.

103. Permitir a configuração do fornecedor de envio de mensagens via WhatsApp.

104. Permitir ao usuário a parametrização da mensagem de SMS enviada através do sistema, para os agendamentos nos status: Agendado, Cancelado, Reagendamento e Lembretes.

105. Deverá permitir ao usuário a parametrização da mensagem de SMS encaminhada ao paciente no término de sua consulta, para visualização dos documentos preenchidos durante o teleatendimento.

106. Deverá possuir segurança de acesso controlado por senha, e tempo de disponibilização na URL de visualização do(s) documento(s) preenchidos durante o teleatendimento.

107. Deverá permitir ao usuário a configuração do tempo para envio das mensagens enviadas via SMS e WhatsApp.

108. Permitir ao usuário a configuração do servidor de e-mail.

109. Permitir ao usuário as configurações de segurança na autenticação por: número de tentativas consecutivas de login; tempo de sessão do usuário e validade da senha.

110. O sistema deverá permitir o cadastro de novas unidades de saúde, contendo os campos mínimos e obrigatórios: Nome; CNES e Tipo de unidade.

111. Deverá permitir a edição do cadastro das unidades de saúde cadastradas.

112. Deverá permitir a inativação das unidades de saúde cadastradas.

113. O sistema deverá permitir o cadastro dos documentos utilizados pelo Município, a partir de: nome de utilização e tipo de documento.

114. Deverá permitir a configuração do layout e formatação do documento para utilização.

115. Deverá possuir TAGS (etiquetas), sendo pré-formatadas ou pré-carregadas do cadastro do paciente, para composição do documento e layout do mesmo para formatação.

116. Deverá possuir TAGS carregadas como default (configuração padrão): primeiro nome do paciente; nome completo do paciente; data de nascimento do paciente; idade do paciente; CPF do paciente; CNS do paciente; nome do prestador; conselho; número do conselho; UF do conselho; nome da unidade de saúde; data da criação e hora de criação.

117. Deverá permitir a criação de campos personalizáveis, oferecendo ao usuário a autonomia de cadastrar o nome do campo e o controle de preenchimento, sendo ele obrigatório: Sim ou Não.

118. Deverá permitir a edição de um documento cadastrado.

119. Permitir a criação de tipos de documentos.

120. Permitir no cadastro e/ou edição do tipo de documento, a parametrização do tipo de assinatura digital: PADES, CADES e/ou XADES.

121. Deverá permitir no cadastro e/ou edição a parametrização do tipo de finalização do documento, a qual definirá se os documentos do tipo vinculados, serão assinados eletronicamente ou não.

122. Permitir parametrizar o tipo de documento, diferenciando por documentos pertencentes ao

prontuário ou não. Os documentos pertencentes ao prontuário, deverão ser disponibilizados ao paciente no término da consulta, através de mensagem SMS e/ou WhatsApp, com controle de acesso por senha e período de disponibilidade.

123. O sistema deverá permitir ao usuário, a configuração do layout e formatação do e-mail para recuperação de ‘senha’.

124. Deverá permitir ao usuário, a configuração do layout e formatação do e-mail para recuperação de ‘usuário’.

125. O sistema deverá permitir o cadastro do Termo de Uso do Município, seus usuários.

126. O sistema deverá permitir o cadastro do Termo de Uso do paciente do município, para que o mesmo aceite a consulta médica por vídeo.

127. A cada nova versão do Termo de Uso do usuário, o sistema deverá exibir aos usuários do sistema o Termo atualizado para um novo aceite.

128. O sistema deverá permitir o cadastro da política de privacidade do Município, para aceite dos usuários e utilização da ferramenta informatizada.

129. Deverá possuir controle de versão para as políticas de privacidade cadastradas.

130. Gerar uma nova versão para a política de privacidade, a partir da edição da política cadastrada.

131. Manter o histórico com todo o conteúdo da política cadastrada, exibindo a versão, o usuário que criou e a data da criação.

132. Manter o histórico e o controle da versão da política de privacidade aceita pelo usuário e/ou paciente da consulta médica por vídeo.

133. O sistema deverá permitir criar agenda por profissional.

134. Permitir parametrizar agenda por período, data inicial e final.

135. Permitir parametrizar agenda por tipo de escala.

136. Permitir cadastrar observações para a agenda.

137. Deverá permitir configurar agenda por: dia da semana (domingo, segunda-feira, terça-feira, quarta-feira, quinta-feira, sexta-feira e sábado).

138. Permitir configurar agenda por horário inicial e final.

139. Permitir configurar a duração da consulta.

140. Permitir a configuração do procedimento da consulta.

141. Deverá permitir a manutenção da agenda, pelo usuário responsável da unidade de saúde.

142. Deverá permitir a visualização e manutenção da agenda, pelo profissional de saúde da

agenda.

143. O sistema deverá permitir o agendamento de consulta.

144. No agendamento de consulta, deverá realizar a busca dinâmica pelo paciente ao informar o os primeiros dígitos de seu nome.

145. Através da busca dinâmica pelo nome do paciente, O sistema deverá preencher de forma automática, os campos obrigatórios para agendamento de consulta, sendo eles: Nome, CPF, CNS, celular, data de nascimento, CEP e e-mail.

146. Permitir informar o profissional; data; hora e procedimento agendado.

147. Deverá possuir tela para visualização dos agendamentos, em formato de calendário, exibindo todas as datas por mês e ano.

148. Possuir legenda no calendário, diferenciando as datas que possuem agendamento e as datas sem agendamentos.

149. Listar os agendamentos por: data e hora; nome; nome social (se houver); médico; número de telefone celular; status do agendamento (Agendado, Cancelado e Confirmado); opção de exclusão do agendamento e acesso para a consulta médica por vídeo.

150. Permitir ao profissional, a mudança de status do agendamento.

151. Para a consulta por vídeo, o sistema deverá exibir ao paciente o Termo de Uso para aceite.

152. Deverá exibir ao paciente, para a consulta por vídeo, as orientações de acesso.

153. Deverá exibir ao profissional de saúde, no atendimento, o nome completo do paciente atendido; nome social (se houver); data de nascimento e idade do paciente.

154. Deverá exibir o histórico dos documentos preenchidos para o paciente, permitindo a visualização dos documentos e download.

155. Deverá permitir a criação de um novo documento, sendo ele parametrizado pela unidade e Município, de acordo com os layouts e padrões utilizados.

156. Deverá permitir ao paciente, no momento da consulta, o envio de documentos nos formatos JPEG, JPG, PNG, GIF e PDF no tamanho máximo de 20mb por arquivo para visualização do profissional em atendimento.

157. O sistema deverá manter a linha do tempo do histórico no prontuário do paciente, de todos os documentos preenchidos para o mesmo.

158. Deverá manter a linha do tempo do histórico de todos os anexos enviados pelo paciente, no momento da consulta por vídeo.

159. No término da consulta, o sistema deverá exibir a pesquisa de satisfação para preenchimento do paciente atendido.

160. No término da consulta, o sistema deverá enviar por SMS e/ou WhatsApp o link de acesso aos documentos preenchidos e assinados digitalmente. Para acesso ao link, a aplicação deverá dispor de senha de acesso única e tempo de disponibilidade do link.

161. O(s) documento(s) assinado(s) digitalmente, deve(m) possuir QRCODE para verificação de validade do(s) mesmo(s).

162. O(s) documento(s) assinado(s) digitalmente, deve(m) possuir certificados digitais ICP-Brasil modelo A1.

⮚ CERTIFICAÇÃO DIGITAL:

163. O sistema deverá permitir ao usuário logado na aplicação, realizar o upload do certificado digital no modelo A1.

164. O sistema deverá solicitar a inclusão do PIN para o certificado.

165. Permitir o certificado digital funcionar sem a dependência de instalação de dispositivos ou serviços, na máquina local do usuário.

166. O serviço do certificado digital deverá validar junto ao órgão regulador no momento da assinatura digital, a validade do certificado assinado e, não deverá permitir a assinatura de documentos e/ou upload de certificados inválidos (vencidos ou revogados).

167. O sistema deverá permitir ao usuário detentor do certificado digital, a exclusão e/ou a atualização do certificado inserido no sistema.

168. Não deverá permitir a manipulação do certificado digital por qualquer outro usuário do sistema, sendo ele administrador ou não. O acesso e a manipulação do certificado e PIN do usuário deverão ser seguros únicos e intransferíveis.

169. Possuir tela para consulta e assinatura de documentos preenchidos pelo profissional logado, possibilitando a busca dos registros preenchidos do profissional por: paciente; Tipo de documento; Status do documento e período.

170. O sistema deverá possibilitar a assinatura; download ou visualização dos documentos preenchidos pelo profissional, podendo selecionar um único documento ou múltiplos para assinatura em lote.

171. O sistema deverá possuir tela para fins administrativos a possibilidade de consulta, visualização e download de documentos gerados por profissionais e não assinados digitalmente, permitindo a busca por paciente, tipo de documento, status do documento e período.

172. O sistema deverá possibilitar o download ou visualização de documentos pendentes de assinatura em tela para fins administrativos.

173. O sistema deverá permitir que sejam parametrizados quais documentos serão passiveis de assinatura digital nas unidades de saúde.

174. O sistema deverá permitir que sejam parametrizadas quais unidades de saúde ficarão habilitadas para assinatura digital de documentos para cada tipo de documento.

⮚ CADASTROS AGENDA:

175. O sistema deverá permitir a configuração e manutenção de agendas, permitindo que seja configurada por tipo de atendimento, unidade de saúde, profissional de saúde, por perfil de agenda.

176. Deverá permitir a associação opcional da agenda com uma campanha de vacinação.

177. O sistema deverá permitir a busca por procedimentos baseado na tabela do SIGTAP.

178. O sistema deverá permitir incluir um equipamento previamente cadastrado à uma configuração de agenda.

179. O sistema deverá permitir o cadastro de Grupos de atendimento informando o nome do grupo, profissional responsável e quantidade de participantes.

180. O sistema deverá permitir atrelar um grupo de atendimento à uma agenda.

181. Deverá permitir visualizar: Horários de atendimento; impedimentos, parâmetros, orientações e histórico (logs) de alterações.

182. O sistema deverá permitir informar a vigência da agenda.

183. Deverá permitir informar a quantidade de vagas por cada tipo de vaga.

184. O sistema deverá permitir a inativação e reativação de uma configuração de agenda.

185. O sistema deverá fazer a inativação automática de uma agenda, sempre que sua vigência expirar.

186. Deverá permitir a inclusão de dia da semana em que a agenda funcionará, podendo selecionar dias específicos da semana.

187. Permitir a inclusão de horários de atendimento na configuração de agenda, informando horário de início e fim dos atendimentos para o dia selecionado.

188. Disponibilizar a soma do total de vagas configuradas na agenda, levando em consideração todos os tipos de vagas.

189. Permitir a remoção dos dias e horários da configuração da agenda.

190. Permitir a inclusão de observação em texto livre em cada range de horário em configurações de novas agendas.

191. Permitir o cadastro de tipos de impedimentos que uma agenda pode sofrer, sendo livre para inclusão de cursos, congressos, falta justificada, palestras, confraternizações, treinamentos etc.

192. O sistema deverá permitir a configuração de um impedimento para a agenda, informando a

vigência, um motivo e observação em texto livre.

193. O sistema deverá permitir a inclusão de mais de um período de impedimento para a agenda.

194. Permitir a replicação do período de bloqueio configurado para as demais agendas do profissional.

195. Permitir a exclusão dos períodos de impedimento configurados.

196. Deverá permitir a inclusão de uma nova configuração dentro de uma agenda já vigente, selecionando data específica, horário de início e fim e quantidade de vagas por tipo de vaga.

197. Permitir a exclusão da configuração de agenda específica.

198. Permitir a inativação e ativação de agenda específica.

199. Permitir a configuração da agenda especifica marcando como horário distribuído.

200. Deverá permitir definir se a agenda deverá ter encaixes ilimitados, restrição de agendamento por idade e por sexo.

201. Permitir o cadastro de outras informações, onde deverá ser possível cadastrar informações que serão impressas no comprovante de agendamento.

202. Permitir que seja parametrizado quais “Outras informações” previamente cadastradas deverão ser impressas no comprovante de agendamento.

203. Permitir o cadastro de Preparos para orientação ao munícipe sobre preparos necessários para exames e/ou procedimentos.

204. Permitir a impressão do preparo no comprovante de agendamento quando o procedimento da agenda estiver associado a um preparo cadastrado.

205. Permitir que seja definido o período de visualização dos agendamentos em dias.

206. Deverá permitir o cadastro de condições ou situações de saúde, sendo livre para cadastro de condições neurológicas, ortopédicas, hipertensão, diabetes, gestação etc.

207. Deverá permitir a restrição de agendamento para condições de saúde previamente cadastradas.

208. Deverá permitir que seja definido quais unidades são permitidas para agendamento de outros tipos de vaga. (Primeira vez, Retorno, Reserva técnica).

209. Deverá permitir que seja definido quais unidades são permitidas para agendamento de vagas de regulação.

210. Possibilitar que seja habilitada a integração com serviço de teleconsulta para que a agenda seja disponibilizada no sistema para atendimento virtual.

211. O sistema deverá exibir o log de alterações da agenda, contendo data e hora da operação,

qual operação foi realizada e o usuário responsável pela operação.

212. Deverá permitir o cadastro de feriados e pontos facultativos informando o nome do feriado e a data com a finalidade de bloqueio automático das agendas da unidade nas datas cadastradas.

213. Permitir informar se o cadastro se refere a um feriado fixo (que se repetira todos os anos), com a opção marcada o sistema deverá bloquear as agendas da unidade todos os anos na mesma data; caso a opção não seja marcada, o sistema realizará o bloqueio somente na data específica.

214. Permitir a busca de agendas configuradas no sistema com filtros por nome, por agendas ativas, inativas e sem período.

215. Deverá permitir a visualização da configuração de agenda, edição da agenda e exclusão da agenda.

216. Ao editar uma agenda, o sistema não deverá permitir a edição do tipo de atendimento, unidade e saúde e profissional.

217. Permitir o cadastro de ações de saúde. Ação essa que posteriormente poderá ser vinculada ao cadastro de munícipe.

⮚ CADASTRO MUNÍCIPES:

218. O sistema deverá possibilitar a busca de munícipes em barra de pesquisa, informando: nome, CNS, CPF, nome da mãe ou data de nascimento.

219. O sistema deverá dispor de filtro de munícipes, por: indivíduos atualizados no período; indivíduos não atualizados no período e indivíduo sem atualização.

220. O sistema deverá dispor de filtro de munícipes, por indivíduos com saída do cadastro: mudança de território ou óbito.

221. O sistema deverá dispor de filtro de munícipes, por profissional, equipe ou excluídos.

222. Possuir todos os campos necessários para o cadastramento dos munícipes.

223. O sistema deverá possibilitar a visualização de foto do munícipe.

224. Deverá dispor de validação de similaridade, onde é sinalizada a tentativa de realizar um cadastro com dados similares ao de outro munícipe existente no cadastro, fazendo a combinação entre nome completo, data de nascimento e nome da mãe.

225. Deverá dispor de validação para impedir cadastro duplicado, sinalizando quando CPF e CNS já estivem em uso.

226. O sistema deverá dispor de interoperabilidade com o cadweb, para busca de CNS definitivo dos munícipes.

227. Deverá realizar a busca de munícipes no CADSUS, sempre que informado o CPF ou CNS do

munícipe.

228. Possibilitar a importação dos dados do munícipe, pesquisado para a base do sistema.

229. Deverá permitir a inserção de documentos diversos (NIS, PIS, PASEP, Título de eleitor, Identidade, Certidões e Prontuários, no menu “Documentos e Prontuários”.

230. O sistema deverá dispor de validação em tempo real para campos de preenchimento obrigatório, sendo eles: CPF; Nome completo; Data de nascimento; Sexo; Raça/cor; Nome do pai; Nome da mãe (podendo marcar como sem informação); Nacionalidade; Estado de nascimento; Município de nascimento; Telefone celular; CEP; Tipo logradouro; logradouro; número; Bairro; Unidade; Profissional e ocupação.

231. Deverá dispor de auditoria de alterações nos cadastros de munícipe, exibindo data de criação do cadastro, data de atualização do cadastro e operador.

232. Deverá carregar as informações do usuário logado, nos campos: Unidade, Profissional e Ocupação (podendo ser editado), sendo possível informar a equipe e microárea responsável pelo munícipe, equipe essa previamente cadastrada no sistema.

233. O sistema deverá possuir menu de Informações Sociodemográficas e Condições/Situações de Saúde, para as unidades que possuem a exportação e-SUS.

234. O sistema deverá possibilitar que seja atrelada ao munícipe uma ou mais ações de saúde, exibindo uma lista para selecionar a condição de saúde.

235. O sistema deverá disponibilizar botão para excluir a ação de saúde do cadastro do munícipe.

236. O sistema deverá dispor de sincronização que possibilite a edição de cadastro de munícipe que reflita no cadastro individual sem a necessidade de mudança de tela para edição.

237. O sistema deverá permitir o agendamento de consultas através do cadastro de munícipe.

238. O sistema deverá permitir a abertura de ficha de pronto atendimento através do cadastro de munícipe.

239. O sistema deverá permitir a impressão da ficha do munícipe.

⮚ CADASTRO PROFISSIONAIS:

240. O sistema deverá permitir o cadastro dos profissionais/usuário de acordo com três tipos: PADRÃO, CNES e SUPORTE/TI.

241. O sistema deverá validar no tipo de cadastro PADRÃO, os seguintes campos como obrigatórios: Nome, Tipo de profissional, CPF, Data de admissão, Cartão Nacional de Saúde, Telefone.

242. O sistema deverá validar no tipo de cadastro CNES, os seguintes campos como obrigatórios: Dados Pessoais: Matrícula; Cartão Nacional de Saúde; Nome; Apelido; Data de Nascimento; Nome

da Mãe; Nome do Pai; Sexo; Grau de escolaridade; Raça/Cor; Nacionalidade; Telefone residencial; Telefone celular. Documentos Gerais: Identidade; Órgão Emissor; Estado do órgão emissor; Data de emissão da identidade; CPF; Endereço residencial; CEP; Estado Residência; Município residência; Tipo de logradouro; Logradouro; Número; Bairro. Dados profissionais: Data da posse; Data de admissão; Carga horaria semanal; Número do conselho; Órgão classe; Estado do órgão classe; Tipo de profissional; Relação profissional (com vínculo ou autônomo).

243. O sistema deverá validar no tipo de cadastro SUPORTE/TI, os seguintes campos como obrigatórios: Nome, Tipo de profissional, CPF, E-mail e Telefone.

244. Deverá permitir no cadastro de profissionais, independentemente do tipo a vinculação do profissional, a uma ou mais unidades de saúde, informando Ocupação e Unidade.

245. O sistema deverá permitir na configuração do usuário definir a situação cadastral (ativo ou inativo).

246. Deverá configurar autenticação informando login (usuário), e-mail para recuperação de senha, senha, confirmação da senha.

247. O sistema deverá dispor de botão que ao clicar, requer ao usuário a troca da senha no próximo login.

248. Deverá permitir a definição de acesso de profissional aprovador de requisições.

249. Deverá permitir definir o profissional como farmacêutico responsável pela unidade.

250. Deverá permitir definir por quais unidades o farmacêutico é responsável.

251. No “controle de acesso de usuários cadastrados”, O sistema deverá permitir definir perfis de utilização individuais.

252. O sistema deverá permitir que se vincule ao profissional os tipos de acesso necessários aos processos do sistema, onde estes podem ser ajustados conforme as necessidades, abaixo seguem os principais tipos de acessos:

▪ Administrativo;

▪ Médico;

▪ Enfermeiro;

▪ Dentista;

▪ Outros Profissionais de Nível Superior;

▪ Auxiliar/Técnico de Enfermagem;

▪ Auxiliar/Técnico de Saúde Bucal;

▪ Médico AD;

▪ Enfermeiro AD;

▪ Outros Profissionais de Nível Superior AD;

▪ Auxiliar/Técnico de Enfermagem AD;

▪ Farmacêutico.

253. Deverá permitir a parametrização do tipo de acesso que o usuário terá ao estoque através

do sistema.

254. O sistema deverá permitir que seja informado: se o profissional é regulador; se permite editar solicitações de regulação, administrador de arquivo BPA.

255. Deverá permitir que o usuário tenha seu acesso liberado para funcionalidade de acordo com 2 (dois) tipos de permissão, por perfil ou personalizado onde deverá ser possível compor o perfil por módulos do sistema.

256. No tipo de permissão por perfil, permitir que se vincule ao profissional os Perfis necessários para acesso ao sistema, onde estes podem ser ajustados conforme as necessidades de acesso, podendo incluir ou excluir funcionalidades. Lista dos perfis principais:

▪ Administrador Sistema;

▪ Administrador Unidade;

▪ Administrador Vacinas;

▪ Agente Comunitário;

▪ Almoxarife;

▪ Aplicação Vacinas;

▪ Atendente/Recepção;

▪ Atendente/Primeira Vez;

▪ Atendente/Regulação;

▪ Atendente/Reserva Técnica;

▪ Atendente/Retorno;

▪ Auxiliar de Farmácia;

▪ Cadastra Preparos;

▪ Diretor Unidade;

▪ Enfermeiro(a);

▪ Faturamento;

▪ Gestor de Acesso;

▪ Médico(a);

▪ Médico Executante;

▪ Médico Regulador;

▪ Médico Solicitante;

▪ Prontuário Eletrônico – Recepção;

▪ Prontuário Eletrônico - Escuta Inicial;

▪ Prontuário Eletrônico – Atendimento;

▪ Recepcionista Geral;

▪ SAME;

▪ Secretaria da Saúde;

▪ Secretário/Assessor

257. Os usuários deverão possuir logins de acesso e senha com métrica mínima e criptografada, permitindo que possam trocar a senha sem a necessidade de intervenção do Administrador do Sistema.

258. Permitir o bloqueio de acesso dos usuários, mediante configuração de horário inicial e final.

259. O sistema deverá registrar em auditoria, todas as tentativas bem-sucedidas de login, registrando os ‘logofs’, data, hora, e o usuário. Deverá registrar o endereço IP do equipamento do qual originou o acesso.

⮚ CADASTRO UNIDADES DE SAÚDE:

260. O sistema deverá possuir as seguintes guias no cadastro das Unidades de Saúde: Básico, Parametrização, Identificação complementar, Endereço Complementar, Caracterização, Infraestrutura, Comissões/Avaliações, Conjunto, Dialise, Químio e Rádio e Hemoterapia seguindo o padrão do CNES.

261. Deverá permitir que na guia “BÁSICO” sejam cadastradas as informações da unidade, preenchendo os campos: Pessoa; Física ou Jurídica, Situação; Individual ou Mantido; Tipo de unidade, CNES, Mantenedora, Nome, Razão social, CEP, estado, município, Tipo de logradouro, Logradouro, Número, Bairro, Complemento, IBGE, Região de Saúde, Microrregião, Distrito Sanitário, Módulo assistencial, Telefone, Fax, E-mail, URL, Referência do Local.

262. Deverá possibilitar a configuração de Horários de funcionamento, Procedimentos, Especialidades, Vacinas, Almoxarifados e Centro de custos no cadastro de unidades de saúde.

263. Deverá permitir a configuração de quais procedimentos são os permitidos para utilização nos processos de atendimento da unidade, informando o código do procedimento SIGTAP.

264. Deverá permitir a configuração de quais especialidades são permitidas para atendimento na unidade de saúde, informando a especialidade (CBO), se a especialidade se restringe a atendimento por idade e atrelando à especialidade quais procedimentos são permitidos para atendimento. Dispondo também de parâmetro para bloqueio da especialidade naquela unidade.

265. Deverá permitir que sejam configurados parâmetros necessários para criação de agendas de vacinação, informando horário inicial e final de aplicação, dias de agendamento e qual a vacina a ser aplicada.

266. O sistema deverá permitir a configuração de quais procedimentos devem ser apresentados por padrão no Acolhimento, informando a SIGLA a ser apresentada, o procedimento SIGTAP, parâmetro de exibição do procedimento na Ficha de atendimento e parâmetro de obrigatoriedade de preenchimento dos procedimentos no acolhimento.

267. Deverá permitir associar um procedimento a determinados CBOS para restrição de uso nos processos de atendimento.

268. Deverá permitir que sejam informados quais almoxarifados estarão disponíveis para os processos de estoque da unidade, informando quantos almoxarifados forem necessários e podendo definir qual é o principal.

269. Deverá permitir que sejam informados quais centros de custo estarão disponíveis para os processos de estoque da unidade, informando quantos centros de custo forem necessários e

podendo definir qual é o principal.

270. O sistema deverá permitir na “Parametrização” como serão gerenciados os processos ou como funcionarão determinadas funcionalidades, como:

▪ permitir ativar o gerenciamento de filas por unidade de saúde para utilização da chamada de senhas;

▪ permitir ativar a exibição do odontograma

▪ permitir ativar a expansão dos blocos (campos) no prontuário eletrônico

▪ permitir a ativação e inativação de uma unidade de saúde cadastrada;

▪ permitir configurar o preenchimento obrigatório do procedimento SIGTAP nas configurações de agenda, por unidade de saúde.

271. O sistema deverá permitir configurar a obrigatoriedade do preenchimento da conduta final nos atendimentos de pronto Atendimento por unidade de saúde.

272. O sistema deverá possuir alerta que impeça lançamento de atendimento duplicado para o mesmo munícipe na mesma data, sendo esse configurado por unidade de saúde e ativado se necessário.

273. Deverá permitir parametrizar as unidades de saúde que exportam informações ao e-SUS. A configuração deve ocorrer por unidade de saúde.

274. Deverá permitir parametrizar as unidades de saúde que utilizarão o prontuário eletrônico. A configuração deve ocorrer por unidade de saúde.

275. Deverá permitir parametrizar o tipo de Atendimento:

▪ Pronto atendimento (unidades que atendem urgência e emergência, tais como UPA, PA e PSM);

▪ Com agendamento (unidades que atendem somente com agendamento);

▪ Misto (unidades que atendem tanto com hora marcada como casos de urgência e emergência).

276. Permitir ativar a validação de dados do munícipe na escuta inicial.

277. Permitir a escolha do modelo de receituário entre completo e simplificado.

278. Permitir parametrizar o tipo de Validação: preenchimento dos dados de munícipe no momento do agendamento.

279. Permitir parametrizar o processo de atendimento ambulatorial, permitindo a escolha de passagem pela triagem ou não. A configuração deve ocorrer por unidade de saúde.

280. Deverá permitir parametrizar o modelo da ficha de atendimento utilizado, sendo: Tradicional, modelo UPA ou modelo SAE, (define qual o modelo de impresso que será gerado ao fim do atendimento). A configuração deve ocorrer por unidade de saúde.

281. Permitir a ativação de impressão unificada de Ficha de acolhimento e Ficha de atendimento.

282. O sistema deverá permitir parametrizar a obrigatoriedade da informação do acompanhante

na abertura de ficha do atendimento no pronto socorro. A configuração deve ocorrer por unidade de saúde.

283. Deverá permitir parametrizar o tipo de validação de cadastro de munícipe, definindo os campos obrigatórios para preenchimento de um cadastro de munícipe.

284. Permitir parametrizar a verificação de fila de espera no agendamento, verificando se o munícipe tem agendamentos de regulação em aberto.

285. Permitir parametrizar para atendimentos em Pronto Socorro, se existirá restrição por faixa etária e especialidade nos atendimentos.

286. Parametrizar o período de visualização de agendamento, define quantos dias de agenda ficam visíveis para busca.

287. Parametrizar a data fechamento do faturamento.

288. Permitir parametrizar a data de fechamento em todas as unidades.

289. Deverá permitir parametrizar o tipo de separação da requisição de estoque, podendo ser: simplificada ou detalhada e a configuração da quantidade de requisições por página.

290. Deverá permitir parametrizar o lançamento BPA: Procedimentos com registro em BPA-C e BPA-I, definindo qual a forma de registro dos procedimentos.

291. Deverá permitir a ativação dos pop-ups de alerta do Previne Brasil.

292. Deverá permitir a ativação de salvamento automático das fichas e-SUS.

293. Deverá permitir a escolha de qual prontuário eletrônico a unidade irá utilizar, optando entre SOAP e Simplificado.

294. O sistema deverá permitir definir a ocultação do step de faturamento e-SUS no prontuário eletrônico.

295. O sistema deverá permitir definir a ocultação do step de faturamento BPA no prontuário eletrônico.

296. Deverá permitir parametrizar o Lançamento BPA automático para agendamento.

297. Deverá permitir configurar na Regulação: Cotas por unidade, Agenda regulada, permitir consultar outras unidades, permitir alterar origem da regulação, unidades de saúde bloqueadas para regulação (define quais unidade não podem visualizar as vagas de agenda regulada).

298. Deverá permitir o preenchimento complementar de informações no cadastro de unidades de saúde, tais como: Vigilância Sanitária, Banco / agência e conta, Representante legal, gerência/ administração (terceiros).

299. Deverá permitir que seja informado um ou mais endereços complementares para a unidade de saúde.

300. Deverá permitir que sejam informadas Esfera Administrativa, Atividade de Ensino e Pesquisa, Natureza Jurídica, Natureza da Organização, Retenção de Tributos, Tipo de Prestador, Atividade, Atendimento prestado, Fluxo de clientela e turno de atendimento.

301. O sistema deverá permitir que seja informado se a unidade possui conexão com a internet, se possui telefonia fixa e telefonia móvel.

302. Permitir que sejam informadas comissões, avaliações e se a unidade aderiu ao Programa de Reestruturação de Hospital Filantrópico.

303. Deverá permitir que sejam informados os serviços de apoio e especializados.

304. Deverá permitir que sejam informadas as quantidades de salas de diálise, quantidade de salas de reuso, quantidade de máquinas, tratamento d’água, serviço de referência/ manutenção e formalização.

305. Deverá permitir que sejam informadas as quantidades de salas de radioterapia, quantidade de equipamentos de radioterapia, acelerador linear, ortovoltagem, braquiterapia, outros, quantidade de salas/ equipamentos de quimioterapia, serviços de referência/manutenção, formalização.

306. Deverá permitir que sejam informados os números de salas de coleta na hemoterapia, número de salas de processamentos, números de salas de laboratório, número de salas de atendimento, equipamentos/ procedimentos especiais, serviços de referência/manutenção, formalização.

307. Deverá permitir que sejam exibidos os equipamentos previamente cadastrados no CNES.

308. O sistema deverá permitir o cadastro de locais e recursos externos.

309. O sistema deverá permitir o controle as cotas por prestador de serviços externos, no qual deverá tratar cotas de exames por mês, cota de internação por mês e cotas de procedimentos.

310. Permitir que se configure qual o Tipo de Local para regulação do Prestador Externo.

311. Permitir que se configure exames e quantidades.

312. Permitir que se configure os dias e horários de início e fim de atendimento dos Locais Externos.

313. Permitir que sejam Cadastradas Emendas, tratando o Nome do Projeto, Descritivo do Projeto, Tipo de Esfera, Nome do Parlamentar, data de aprovação, valor, parcelas, se possui medicação e período de utilização dos recursos.

314. O sistema deverá permitir que se configure a data de fechamento do período de Faturamento para alterações/inclusões/exclusões por Unidade e para todas as unidades.

315. O sistema deverá permitir realizara busca por recursos externos cadastrados.

316. O sistema deverá permitir a exclusão de recursos externos cadastrados.

317. O sistema deverá permitir cadastrar equipamentos, contendo no mínimo: Nome do equipamento, Fabricante e Número de série.

318. O sistema deverá possuir campo de busca por nome de equipamento cadastrado.

319. O sistema deverá apresentar a listagem com todos os procedimentos presentes na tabela SIGTAP, exibindo Competência, Código do procedimento, Código reduzido e nome.

320. Deverá apresentar opção para visualização detalhada das informações presentes para os procedimentos.

⮚ CADASTRO EMENDAS:

321. O sistema deverá permitir o cadastro de uma nova emenda, possibilitando informar:

▪ nome do projeto de emenda

▪ o descritivo

▪ tipo de esfera, se Estadual, Federal ou Municipal

▪ nome do parlamentar

▪ data da aprovação

▪ valor, número de parcelas

▪ se possui medicamento e período de utilização dos recursos.

322. Deverá permitir a consulta por emendas cadastradas.

323. Deverá permitir a edição e a exclusão de uma emenda cadastrada.

⮚ CADASTRO AÇÕES DE SAÚDE:

324. O sistema deverá permitir o cadastro de novas ações em saúde, contendo:

▪ código

▪ nome e descrição de saúde que são operacionalizadas em todos os níveis de atenção à saúde.

⮚ ATENDIMENTO AMBULATORIAL:

325. O sistema deverá permitir consultar em tela específica de Atendimento Ambulatorial, todos atendimentos ambulatoriais agendados e os encaixes por demanda espontânea, exibindo por abas os profissionais com agendamentos em aberto e uma aba com atendimentos em aberto de todos os profissionais com agendamentos em aberto.

326. O sistema deve permitir que o usuário indique a presença, ou ausência do paciente.

327. O sistema deve permitir que o usuário indique a ausência do profissional.

328. O sistema deverá exibir no impresso de agendamentos do profissional a unidade de saúde, profissional, especialidade, data início e data fim para identificação da ficha e unidade de saúde,

local, profissional especialidade, procedimento, módulo, data/hora, atendimento, prontuário e se o atendimento está cancelado ou não.

329. O sistema deve permitir que os atendimentos confirmados também sejam confirmados automaticamente no Lançamento BPA.

330. O sistema deverá permitir que em tela específica do prontuário eletrônico do atendimento ambulatorial o médico informe os dados para evolução clínica como, Motivo do atendimento e descrição do exame clínico, hipótese diagnostica.

331. Deverá permitir no prontuário eletrônico, o lançamento de notificação compulsória e o status (confirmado ou suspeito e negativo).

332. O sistema deverá permitir que em tela de prontuário eletrônico do atendimento ambulatorial o Médico informe os exames a serem realizados pelo nome ou procedimento SIGTAP, podendo ser quantos exames forem necessários.

333. O sistema deverá permitir que em tela de prontuário eletrônico o Médico informe os procedimentos e seus CID´s a serem realizados, podendo ser quantos procedimentos forem necessários, informando o procedimento por nome ou código SIGTAP, quantidade de procedimentos realizados e o CID associado.

334. O sistema deverá permitir que em tela de prontuário eletrônico o Médico informe os Medicamentos a serem ministrados, podendo ser quantos Medicamentos forem necessários, devendo ser informado ainda a posologia e observações de cada medicamento.

335. O sistema deverá permitir que em tela de prontuário eletrônico o Médico faça a prescrição do receituário de medicamentos ao paciente no qual poderá ser impresso pelo Médico a partir da própria tela de prontuário eletrônico, informando no receituário o medicamento, via de administração, dose, se é dose única, se é de uso contínuo, início do tratamento, quantidade receitada, unidade de fornecimento, duração do tratamento e justificativa/observação.

336. O sistema deverá permitir em tela de prontuário eletrônico, que possa ser apontada a conduta médica para o atendimento.

337. O sistema deverá permitir a emissão de atestado médico, informando XXX, data início e fim do afastamento e observações pertinentes.

338. O sistema deverá permitir a emissão de declaração de comparecimento, informando hora início e hora fim de permanência do munícipe na unidade e RG.

339. O sistema deverá permitir a emissão de declaração de comparecimento para o acompanhante, informando hora início e hora fim de permanência do acompanhante na unidade, nome e RG.

340. O sistema deverá permitir que sejam registrados atendimentos ambulatoriais retroativos, em tela específica.

341. O sistema deverá permitir que os registros retroativos, se fixem automaticamente com a presença confirmada para o atendimento.

342. O sistema deverá validar os dados obrigatórios necessários para o e-SUS e BPA no momento do registro retroativo, sendo eles CNS ou CPF, nome, data de nascimento, nome da mãe, celular e endereço.

343. O sistema deverá direcionar os atendimentos inseridos como registro retroativo, para o faturamento, na data informada na inclusão deste.

344. O sistema deverá permitir que sejam confirmados os atendimentos de forma retroativa, em tela específica, na qual o usuário poderá pesquisar por data e especialidade.

345. O sistema deverá apresentar apenas os atendimentos pendentes de confirmação de presença e, após esse apontamento no processo de confirmação de presença retroativa, não deverá ser possível editar o mesmo.

346. O sistema deverá direcionar os atendimentos confirmados no processo de confirmação de presença retroativa, para o faturamento, na data correspondente ao atendimento.

347. O sistema deverá permitir a emissão de atestado médico, informando XXX, data início e fim do afastamento, bem como, observações pertinentes.

348. O sistema deverá permitir a emissão de declaração de comparecimento, informando hora início e hora fim de permanência do munícipe na unidade e RG.

349. O sistema deverá permitir a emissão de declaração de comparecimento para o acompanhante, informando hora início e hora fim de permanência do acompanhante na unidade, nome e RG.

⮚ ATENDIMENTO PRÉ-NATAL:

350. O sistema deverá permitir o controle de Pré-Natal das Pacientes em tela específica.

351. O sistema deverá permitir que o usuário possa informar em tela específica de Pré-Natal, o Número do SIS.

352. O sistema deverá permitir que o usuário possa informar em tela específica de Pré-Natal alguns dados de antecedentes familiares.

353. O sistema deverá permitir que o usuário possa informar em tela específica de Pré-Natal alguns dados de antecedentes pessoais.

354. O sistema deverá permitir que o usuário possa informar em tela específica de Pré-Natal alguns dados de antecedentes obstétricos.

355. O sistema deverá permitir que o usuário possa informar em tela específica de Pré-Natal dados da Gestão atual, como: DUM, DPP, ABO, RH e se a paciente é fumante e/ou ingere bebida

alcoólica.

356. O sistema deverá trazer em tela específica de Pré-Natal a informação, se a Paciente possui a Vacina Antitetânica em dia, cuja informação deverá ser automática com vínculo ao Módulo de Vacinação.

⮚ PROGRAMA DE SAÚDE:

357. O sistema deverá permitir, em tela específica, que o usuário possa vincular os Pacientes a um ou mais Programa social específico.

358. O sistema deverá permitir o vínculo do munícipe com os programas de saúde ou social, já cadastrados no sistema.

359. O sistema deverá exibir quais os programas de saúde ou programas sociais o munícipe está participando.

360. O sistema deverá permitir a emissão de prescrições de receitas para os munícipes, sem agendamento.

361. O sistema deverá permitir incluir o medicamento que será prescrito.

362. O sistema deverá permitir informar a via de administração e tipo de dose.

363. O sistema deverá permitir informar se o medicamento é de uso contínuo.

364. O sistema deverá permitir informar o tipo de frequência em que o medicamento deve ser tomado, sendo categorizado em turno, frequência ou intervalo.

365. Deverá permitir que ao selecionar o tipo de Frequência, seja possível informar em qual período do dia ou noite a medicação será ministrada.

366. Deverá permitir que ao selecionar o tipo de frequência, seja possível informar quantas vezes por dia a medicação deverá ser ministrada.

367. Permitir informar a data de início do tratamento e a duração podendo ser definida em dias, semanas, meses, anos ou indeterminado.

368. Permitir informar a quantidade receitada e unidade de fornecimento.

369. Permitir a inserção de justificativa/observação para o medicamento receitado.

370. Permitir a impressão dos receituários emitidos no processo de prescrições de receitas sem agendamento.

371. O sistema deverá permitir a emissão de guias de exames para os munícipes, sem agendamento.

372. O sistema deverá permitir que no formulário de solicitação de exame, seja possível informar a prioridade.

373. O sistema deverá permitir a inclusão do CID, na solicitação.

374. O sistema deverá permitir a inclusão de justificativa, na solicitação.

375. O sistema deverá permitir a solicitação por grupo de exames.

376. O sistema deverá permitir a impressão das guias de encaminhamentos emitidos no processo de solicitação, de exames sem agendamento.

377. O sistema deverá permitir que seja incluso 1 ou mais procedimentos de exames na solicitação.

⮚ DEMANDA ESPONTÂNEA:

378. O sistema deverá permitir a busca e seleção do munícipe informando: nome, CPF, CNS, nome da mãe ou data de nascimento, para que sejam inseridos atendimentos.

379. O sistema deverá permitir a seleção da Especialidade, Profissional e Procedimento.

380. O sistema deverá fixar o agendamento para o dia e horário atuais.

381. O sistema não poderá permitir alteração dos campos de data e horário.

⮚ PRONTO ATENDIMENTO:

382. O sistema deverá permitir a abertura da ficha a partir da seleção do munícipe, realizando a busca por: nome, CPF, CNS, nome da mãe ou data de nascimento.

383. O sistema deverá permitir edição dos dados do munícipe a partir do processo de Ficha de atendimento.

384. O sistema deverá permitir informar se o atendimento está relacionado a síndrome gripal.

385. O sistema deverá permitir informar a SENHA, na abertura de ficha de atendimento, em unidades que utilizem painel de senhas.

386. O sistema deverá permitir que o usuário informe se o paciente possui convênio.

387. O sistema deverá permitir que o usuário informe o meio de transporte utilizado pelo munícipe para chegar à unidade.

388. O sistema deverá permitir que o usuário informe se o atendimento é por motivo de acidente de trabalho.

389. O sistema deverá permitir que o usuário informe se o atendimento é por motivo do paciente ter sofrido violência.

390. O sistema deverá permitir o registro do acompanhante, se houver, informando: nome, RG, parentesco com o paciente e telefone.

391. O sistema deverá possuir campo para apontamento e direcionamento, se o munícipe passará ou não por Acolhimento.

392. O sistema deverá possibilitar a emissão da ficha de atendimento para Acolhimento.

393. O sistema deverá permitir que se inclua atendimentos PA retroativos, no qual o usuário poderá incluir a Data e hora destes atendimentos.

394. Ao registrar um novo atendimento PA o sistema deverá emitir alerta caso paciente possua Fichas de Atendimento em aberto, ou seja, para a qual não foi definida uma conduta final.

395. O sistema deverá permitir a busca e seleção de munícipe, informando o nome, CPF, CNS, Nome da mãe ou data de nascimento para exibição de atendimentos PA realizados.

396. O sistema deverá listar todos os atendimentos PA do munícipe, exibindo: data do atendimento; hora; especialidade; ficha; profissional e unidade de saúde.

397. O sistema deverá dispor de opção para impressão de segunda via da ficha do atendimento.

398. O sistema deverá permitir o cancelamento de uma ficha de atendimento, informando a justificativa para essa ação.

399. O sistema deverá sinalizar os atendimentos PA do munícipe que foram cancelados, exibindo ícone diferenciado com a informação “item cancelado”.

400. O sistema deverá fixar a justificativa informada, o usuário, data e horário da ação de cancelamento do atendimento PA (log da operação).

401. O sistema deverá apresentar opção para visualização da listagem das fichas de atendimentos, que estão pendentes para o atendimento no processo de classificação de risco (Acolhimento).

402. Deverá permitir filtrar as fichas em aberto por especialidade.

403. A listagem disponível com as fichas de atendimentos, deverá apresentar inicialmente, as informações de: CNS, Nome do munícipe, Nome da Mãe, Data de nascimento, Idade e data e hora do atendimento.

404. O sistema deverá possibilitar o registro das informações necessárias referente aos procedimentos realizados no Acolhimento.

405. O sistema deverá possibilitar o registro de antecedentes pessoais e hábitos; registro de avaliação física; registro de medicamentos em uso; registro de alergias e registro do descritivo do atendimento.

406. O sistema deverá disponibilizar os campos para apontamento da classificação de risco, podendo ser: Vermelho, Amarelo, Verde ou Azul.

407. O sistema deverá realizar o faturamento automático dos procedimentos preenchidos durante a classificação de risco.

408. Deverá dispor de opção para impressão das fichas de atendimentos, com os apontamentos

feitos no processo de classificação de risco (Acolhimento).

409. Apresentar opção para direcionar a ficha para a listagem de ausentes, caso o paciente não responda à chamada para o atendimento.

410. Apresentar uma listagem específica para os registros identificados como ausentes.

411. Deverá dispor de opção para retornar a ficha ausente, para a listagem de atendimento na listagem de fila de acolhimento.

412. O sistema deverá possibilitar vincular o profissional a um atendimento realizado.

413. O sistema deverá possibilitar a busca do munícipe e seus atendimentos disponíveis para vinculação.

414. Possibilitar a seleção e vinculação do profissional ao atendimento informando o nome do profissional.

415. O sistema deverá apresentar uma listagem com as fichas de atendimento.

416. O sistema deverá permitir filtrar as fichas em aberto para atendimento, por especialidade.

417. Permitir que as fichas somente sejam visualizadas por usuários habilitados, e com o CBO correspondente ao informado como especialidade na emissão da ficha de atendimento.

418. Possuir todos os campos necessários para o atendimento por meio do prontuário eletrônico, para unidades de urgência e emergência.

419. O sistema deverá dispor, no processo de atendimento, exibição de informações da qualificação do munícipe.

420. O sistema deverá dispor, no processo de atendimento, exibição de informações preenchidas no Acolhimento.

421. O sistema deverá dispor, no processo de atendimento, exibição de informações de histórico de atendimento, sendo: Prontuário, data, hora, profissional, especialidade e visualização do detalhe do atendimento.

422. O sistema deverá dispor, no histórico de atendimento, exibição das informações preenchidas no atendimento selecionado.

423. O sistema deverá dispor, no processo de atendimento, campos para registro de evolução clínica.

424. O sistema deverá dispor, no processo de atendimento, campos necessários para lançamento de notificação compulsória, sendo: Doença/Agravo e confirmação.

425. O sistema deverá dispor, no processo de atendimento, campo que possibilite informar exames solicitados.

426. O sistema deverá dispor, no processo de atendimento, possibilidade de se associar um

procedimento realizado no atendimento a um CID.

427. O sistema deverá dispor, no processo de atendimento, possibilidade de receitar medicamento para ser aplicado no local, informando os campos: medicamento, posologia e observação.

428. O sistema deverá dispor no processo, que possibilite informar se o paciente retornará com o médico após aplicação de medicação.

429. O sistema deverá dispor, no processo de atendimento, possibilidade de prescrever medicações para retirada externa, dispondo de todos os campos necessários para esse processo.

430. O sistema deverá dispor, no processo de atendimento, campo para registro da conduta médica no atendimento.

431. O sistema deverá dispor no processo de atendimento a possibilidade de emissão de atestado, declaração de comparecimento e declaração para o acompanhante.

432. O sistema deverá possuir opção para a emissão de receituários, com as informações de nome do medicamento, via de administração, posologia e observações.

433. O sistema deverá possuir opção para emissão de encaminhamento externos para especialidades.

434. Possuir opção de emitir formulário de encaminhamento para internação.

435. Possuir opção de encaminhamento do paciente para terapia, informando a unidade de saúde, quantidade de sessões, ocupação e observação pertinente.

436. Possuir opção para impressão da ficha de atendimento, com os dados inseridos no processo de atendimento.

437. O sistema deve permitir informar a conduta final do atendimento em tela específica selecionando uma das seguintes opções: Alta médica; Atendimento cancelado; Evasão; Óbito e Transferência.

438. O sistema deverá permitir a emissão de relatório com as condutas finais informadas.

439. O sistema deverá permitir a emissão de declarações de comparecimento para o paciente exibindo data e hora e entrada e saída da unidade.

440. O sistema deverá permitir a emissão de declarações de comparecimento para acompanhantes, demostrando exatamente o tempo de permanência do acompanhante na unidade, exibindo data e hora de entrada e saída da unidade.

441. O sistema deverá permitir a emissão de atestados médicos, para o paciente, este documento deve ser de uso apenas de profissionais habilitados.

442. O sistema deverá utilizar como horário inicial das declarações o horário identificado para a

emissão das senhas aos atendimentos.

443. O sistema deverá considerar como horário final, o horário fixado na emissão das declarações.

444. O sistema deverá possuir impressão das declarações de comparecimento dos pacientes e de acompanhantes, com o campo para assinatura e carimbo do profissional responsável.

445. O sistema deverá possuir impressão dos atestados médicos dos pacientes, com o campo para assinatura e carimbo do profissional responsável.

⮚ CLASSIFICAÇÃO DE RISCO:

446. O sistema deverá permitir a identificação das fichas de atendimento emitidas e direcionadas para o processo de classificação de risco (Acolhimento).

447. A listagem disponível com as fichas de atendimentos, deverá apresentar inicialmente, as informações de: CNS, Nome do munícipe, Nome da Mãe, Data de nascimento, Idade, data e hora do atendimento.

448. O sistema deverá possibilitar o registro das informações necessárias referente aos procedimentos realizados no acolhimento.

449. Deverá possibilitar o registro de antecedentes pessoais e hábitos.

450. Deverá possibilitar o registro de avaliação física.

451. Deverá possibilitar o registro de medicamentos em uso.

452. Deverá possibilitar o registro de alergias.

453. Deverá possibilitar o registro do descritivo do atendimento.

454. Deverá disponibilizar os campos para apontamento da classificação de risco, podendo ser: Vermelho, Amarelo, Verde ou Azul.

455. O sistema deverá dispor de opção para impressão das fichas de atendimentos, com os apontamentos feitos no processo de classificação de risco (Acolhimento).

456. O sistema deverá apresentar opção para direcionar a ficha de atendimento para a listagem de ausentes, caso o paciente não responda à chamada para o atendimento.

457. Deverá apresentar uma listagem específica para os registros identificados como ausentes.

458. Deverá dispor de opção para retornar a ficha ‘ausente’, para a listagem de atendimento em fila de acolhimento.

459. O sistema deverá permitir o faturamento automático dos procedimentos realizados na classificação de risco.

460. O sistema deverá apresentar listagem com as fichas disponíveis para atendimento.

461. Deverá permitir filtrar a lista de atendimento por especialidade.

462. O sistema deverá permitir que as fichas somente sejam visualizadas por usuários habilitados e, com o CBO correspondente ao informado como especialidade na emissão da ficha de atendimento.

463. O sistema deverá possuir todos os campos necessários para o atendimento por meio do prontuário eletrônico, para unidades de urgência e emergência.

464. Deverá dispor, no processo de atendimento, exibição de informações dos dados de qualificação do munícipe.

465. Deverá dispor, no processo de atendimento, exibição de informações preenchidas no Acolhimento.

466. Deverá dispor, no processo de atendimento, exibição de informações de histórico do atendimento.

467. Deverá dispor, no histórico de atendimento, exibição das informações preenchidas no atendimento selecionado.

468. Deverá dispor, no processo de atendimento, campos para registro de evolução clínica.

469. Deverá dispor, no processo de atendimento, campos necessários para lançamento de notificação compulsória, sendo eles: Doença/Agravo e confirmação.

470. O sistema deverá dispor, no processo de atendimento, campo que possibilite informar exames solicitados.

471. O sistema deverá dispor, no processo de atendimento, possibilidade de se associar um procedimento realizado no atendimento a um CID.

472. O sistema deverá possibilitar indicar no atendimento procedimentos a serem realizados por equipe de enfermagem.

473. O sistema deverá possibilitar a solicitação de exames para serem coletados internamente.

474. O sistema deverá possibilitar a solicitação de exames para serem realizados fora do estabelecimento.

475. O sistema deverá dispor, no processo de atendimento, possibilidade de receitar medicamento para ser aplicado no local, informando os campos: medicamento; posologia e observação.

476. O sistema deverá dispor, no processo de atendimento, possibilidade te informar se o paciente retornará com o médico após aplicação de medicação.

477. O sistema deverá dispor, no processo de atendimento, possibilidade de prescrever medicações para retirada externa, dispondo de todos os campos necessários para o processo.

478. O sistema deverá dispor, no processo de atendimento, campo para registro da conduta médica no atendimento.

479. O sistema deverá gerar o faturamento automático dos procedimentos realizados durante o atendimento.

480. O sistema deverá dispor, no processo de atendimento, a possibilidade de emissão de atestado, declaração de comparecimento e declaração para o acompanhante.

481. Deverá possuir opção para a emissão de receituários, trazendo as informações: nome do medicamento; via de administração; posologia e observações.

482. O sistema deverá possuir opção para emissão de encaminhamento externo para especialidades.

483. O sistema deverá possuir opção de emitir formulário para encaminhamento de internação.

484. O sistema deverá possuir opção de encaminhamento do paciente para Terapia, informando a unidade de saúde; quantidade de sessões; ocupação e observação pertinente.

485. O sistema deverá possuir opção para impressão da ficha de atendimento, com os dados inseridos no processo de atendimento.

486. O sistema deverá permitir o registro de pacientes não identificados civilmente.

487. Para cadastro de pacientes não identificados, o sistema deverá conter os seguintes campos de preenchimento obrigatório: Nome ou pseudônimo; Idade estimada; Sexo e Raça/Cor.

488. O sistema deverá permitir anexar foto do indivíduo não identificado civilmente no cadastro.

489. O sistema deverá permitir atualizar os dados de paciente não identificado civilmente, cadastrados no sistema.

490. O sistema deverá permitir excluir o cadastro de paciente não identificado civilmente.

491. O sistema deverá registrar a data de criação, data de atualização e o usuário operador responsável por estas operações.

492. Deverá permitir a impressão da ficha do paciente não identificado, para registro manual do atendimento, contendo os campos: Motivo de atendimento; Hipótese diagnóstica; Exames Complementares e Conduta.

493. O sistema deverá permitir a visualização de todos os pacientes encaminhados para medicação, através do prontuário eletrônico evidenciando seu status.

494. O sistema deverá dispor de opção, para iniciar o atendimento de medicação ou editar atendimentos em andamento.

495. Deverá exibir no atendimento de medicação, os dados do munícipe e posologia do medicamento.

496. Deverá permitir que seja registrada a aplicação da medicação.

497. Deverá permitir que seja cancelada uma aplicação de medicação.

498. Deverá permitir que seja dada baixa em estoque, no momento da aplicação da medicação.

499. O sistema deverá permitir o registro de anotação referente à checagem de medicação.

500. Deverá permitir a impressão do registro de aplicação da medicação.

⮚ URGÊNCIA E EMERGÊNCIA:

501. O sistema deverá possibilitar a seleção dos guichês, no momento da abertura de ficha.

502. O sistema deverá apresentar as senhas correspondentes ao serviço que está efetuando o atendimento.

503. O sistema deverá apresentar todas as senhas emitidas e a frente de cada senha, deve ser identificado o tempo de espera de cada uma.

504. O sistema deverá apresentar as senhas, divididas pela categoria e divididas por atendimento normal ou atendimento preferencial.

505. Deverá possuir opção para escolha e seleção da senha.

506. Deverá permitir, após a seleção da xxxxx, efetuar a busca pelo munícipe que passará por atendimento.

507. O sistema deverá possibilitar informar na abertura da ficha, se o munícipe passará por acolhimento; por qual especialidade; como chegou à unidade de saúde; se possui convênio médico; acompanhantes e se sofreu acidente de trabalho ou agressão.

508. O sistema deverá permitir edição dos dados do munícipe, a partir do processo de Ficha de atendimento.

509. O sistema deverá permitir que ao criar a ficha de atendimento, seja possível direcionar o munícipe para o setor ou consultório desejado.

510. O sistema deverá permitir que seja realizada abertura de ficha, com data e hora retroativa.

511. O sistema deverá dispor dos mesmos campos apresentados na abertura de ficha, para abertura de ficha retroativa.

512. O sistema deverá permitir que seja possível imprimir segunda via de atendimentos.

513. O sistema deverá permitir que seja possível cancelar atendimentos.

514. O sistema deverá permitir que os processos de impressão de segunda via e cancelamento de atendimento, passe primeiro pela seleção do munícipe.

515. O sistema deverá trazer a lista de atendimentos do munícipe, para que seja possível selecionar qual atendimento será cancelado ou impresso a segunda via.

516. O sistema deverá permitir a emissão de declarações de comparecimento para o paciente, demostrando exatamente o tempo de permanência do munícipe na unidade, exibindo horário de entrada e horário de saída do munícipe da unidade.

517. O sistema deverá permitir a emissão de declarações de comparecimento para acompanhantes, demostrando exatamente o tempo de permanência do acompanhante na unidade, exibindo horário de entrada e horário de saída do munícipe da unidade.

518. Deverá permitir a emissão de atestados médicos para o paciente.

519. O atestado deverá conter as informações de tempo de permanência na unidade com data, horário de entrada e saída e quantidade de dias de afastamento.

520. Deverá possuir impressão dos atestados médicos dos pacientes, com o campo para assinatura e carimbo do profissional responsável.

521. Deverá utilizar como horário inicial das declarações o horário identificado para a emissão das senhas aos atendimentos.

522. Deverá considerar como horário final, o horário fixado na emissão das declarações.

523. Deverá possuir impressão das declarações de comparecimento dos pacientes e de acompanhantes, com o campo para assinatura e carimbo do profissional responsável.

⮚ PAINEL DE SENHA E GERENCIAMENTO DE FILAS:

524. O sistema deverá permitir a configuração de painéis de senhas, para chamada de recepções, consultórios, farmácias, e demais serviços de atendimento.

525. O sistema deverá permitir a parametrização dos painéis de senha, por cor, além de exibir a senha, nome do munícipe e o histórico das últimas seleções para os atendimentos.

526. O sistema deverá dispor do Painel com a possibilidade de chamadas das senhas, de forma sequencial ou de acordo com a seleção dos usuários.

527. O sistema deverá permitir parametrização das senhas, conforme uso de cada unidade de saúde, podendo ser válida até a 00:00 do dia emitido ou por 24horas.

528. O sistema deverá dispor de senhas comuns ou prioritárias, para cada serviço ofertado.

529. O sistema deverá possuir todos os parâmetros necessários para emissão das senhas.

530. O sistema poderá estabelecer a emissão das senhas por setor, e contendo quantas categoria forem necessárias.

531. No cadastro das categorias, deve conter campos para fixação do local do atendimento (onde o munícipe deverá se dirigir após a chamada da senha), os tipos de senhas, com as siglas e definições de atendimento comum ou prioritário.

532. O sistema deverá permitir que cada categoria seja exibida com imagens, e cores primarias e segundarias, facilitando a identificação no painel.

533. O sistema deverá permitir a configuração de totens para o autoatendimento e ou auto agendamento do munícipe na chegada a unidade.

534. O sistema deverá permitir a configuração dos grupos de painéis, sendo possível centralizar as chamadas das senhas em um painel ou configurar um painel para cada tipo de serviço.

535. O Módulo deverá possuir 02 Perfis, sendo: Administrador e Atendente.

536. O Perfil Administrativo, deverá permitir a configuração de usuários, grupos, categorias, Totens, tipos de serviço e possuir acesso a uma opção manual de emissão de senhas.

537. O perfil atendente, deverá acessar as senhas já emitidas, conforme estabelecido e efetuar a chamada das senhas para os locais de atendimento.

538. O perfil de atendente, visualizará as quantidades das senhas que estão aguardando chamadas, para cada categoria.

539. Todos os guichês e salas poderão ser configurados com quantidades infinitas de nomes, podendo conter letras e números.

540. O sistema deverá disponibilizar opção de senha Normal e senha Preferencial, sendo que no console da recepcionista, esta poderá optar por chamar quaisquer delas, primeiramente.

541. O sistema deverá vincular a categoria da senha, com o tipo de serviço onde este poderá ser parametrizado, definindo: o tempo de validade da senha para a chamada nos painéis; onde inicialmente serão válidas até às 00:00 do dia atual ou validas por 24 horas a partir da emissão.

542. O sistema deverá permitir Chamar Novamente uma mesma senha.

543. O sistema deverá permitir Cancelar/Finalizar o atendimento de uma senha.

544. O sistema deverá permitir chamar uma senha anterior ou posterior a qualquer momento.

545. O sistema deverá exibir para os usuários com perfil de Atendentes, o tempo de espera de cada senha emitida, que estão no aguardo do chamado através do painel.

546. O sistema deverá permitir as chamadas das senhas de forma sequencial ou de forma aleatória, conforme seleção dos operadores.

547. O sistema deverá apresentar em tela de Painel de Senha, as seguintes informações para a chamada dos Munícipes:

548. Próxima senha e para qual Xxxxxx/Sala

549. Últimas Senhas chamadas e para qual Guichê/Sala

550. O sistema deverá apresentar painéis eletrônicos para indicar senha e local de atendimento dentro da UBS.

551. Com o Gerenciamento de Filas, deverá ser possível configurar quais filas estarão disponíveis e quais filas serão apresentadas nos Totens de Autoatendimento. Sendo possível, a configuração exclusiva por Xxxxx, permitindo o trabalho por serviços individualizados, dentre eles, por exemplo: Totem de Autoatendimento e Totem de Auto agendamento de Consultas.

552. As filas poderão ser diferenciadas por cores e ícones, facilitando a identificação do fluxo de forma visual na unidade de saúde.

553. Os painéis contemplarão chamada sonora, melhorando o ruído interno da unidade de saúde, não se fazendo necessário a chamada por voz para atendimento.

554. O sistema deverá permitir vínculo de usuário por unidade de saúde, ou seja, cada usuário visualizará o painel de senhas da unidade de saúde liberada em seu acesso.

555. Cadastro de grupo de painéis: Deverá ser possível configurar uma ou mais exibições de painéis para a mesma unidade. Os painéis poderão ser configurados para exibir chamadas de senhas de serviços diferentes.

556. Cadastro de categorias: Cadastro de serviços utilizados pela unidade. No cadastro de categoria será possível cadastrar e vincular:

▪ Tipo de Fila: Parametrização de serviço Check-In automático ou offline (apenas emissão de senha)

▪ Cor primária e secundária: Identificação visual do serviço.

▪ Ícone de referência: Identificação visual do serviço.

▪ Locais de atendimento: Guichês, Salas, Consultórios (nomenclatura definida pelo usuário). Sistema parametrizado de acordo com a necessidade, podendo ser definida uma ou mais descrições de locais de atendimento para o mesmo serviço.

557. O Totem deverá possuir identificação do munícipe com leitor biométrico e para retirada de senha.

558. Deverá possuir identificação do munícipe através das informações de CPF e CNS.

559. Deverá permitir visualização da lista de serviços configurados.

560. O Totem deverá possuir a função de leitura biométrica.

561. No Totem deverá ser possível visualizar os dados do munícipe quando identificado com o leitor biométrico.

562. Deverá permitir a seleção automática da consulta agendada na data atual.

563. O Totem deverá possuir a Impressão de senha.

564. O Totem deverá possuir Auto Agendamento (acesso ao Portal de agendamento de consultas online)

565. O Totem deverá permitir impressão de comprovante de agendamento realizado pelo Totem.

566. O sistema deverá permitir que o cidadão realize seu agendamento de consultas na unidade de saúde.

567. O sistema deverá possuir opção para definir se será ou não habilitado o auto agendamento pela unidade, para apresentação no Totem de Atendimento.

568. O sistema deverá possuir a identificação por leitura biométrica do cidadão ou CPF previamente cadastrado na unidade de saúde.

569. O sistema deverá realizar a impressão de comprovante de agendamento.

570. O sistema deverá dispor de possibilidades para o autoatendimento, quando o munícipe efetua entrada na unidade.

571. O serviço de check-in deverá ser disponibilizado no Totem de Autoatendimento, onde permite que o próprio cidadão realize o seu atendimento, sem a necessidade e ir até o balcão da unidade de saúde.

572. O check-in deverá ser destinado para munícipes que tenham consulta agendada para o dia atual.

573. Possibilitar a configuração do tempo máximo de antecedência para realização de check-in.

574. Para as confirmações de atendimento (Check-In) na unidade, através do Totem, deve ser disponibilizada a identificação do munícipe através da biometria ou CPF.

575. Para as confirmações de atendimento (Check-In) na unidade, através do Totem, quando ocorrer algum problema na identificação do munícipe, deverá ser emitida uma senha para atendimento na recepção.

576. Após o Check-In, o munícipe deverá ter sua presença automaticamente confirmada no sistema, não havendo a necessidade de passar pelo serviço de atendimento.

577. O munícipe deverá ser chamado para consulta médica de forma automática, respeitando o horário agendado.

578. Não deverá ser possível realizar Check-in Aplicativo ou Totem, após 30 minutos de atraso, relação horário agendado e horário atual.

579. O sistema deverá possuir todos os parâmetros necessários para configurar as opções destinadas a uma pesquisa de satisfação.

580. Os usuários do sistema, deverão ter acesso para cadastramento e configuração, das seguintes funções: Categoria, Serviço, Avaliação, sistema e totem.

581. Deverá permitir que cada serviço seja exibido com uma imagem e cores, facilitando a identificação no totem ou equipamento utilizado.

582. Deverá permitir que cada avaliação seja exibida com uma imagem e cores, facilitando a identificação no totem ou equipamento utilizado.

583. Deverá permitir que cada categoria seja exibida com imagens e cores, facilitando a identificação no totem ou equipamento utilizado.

584. Permitir que os usuários dos serviços, que efetuaram os apontamentos sob as pesquisas, possam ser identificados a partir da informação do CNS, Biometria, ou de forma anônima.

585. Após identificação, deverá ser exibida a listagem dos serviços e as opções para as avaliações.

586. O sistema deverá exibir opção para detalhamento da avaliação, permitindo que o usuário do serviço, digite sua opinião, reclamação, elogio e outros.

587. Após a conclusão da pesquisa, deverá retornar automaticamente para a tela inicial, disponibilizando a pesquisa para um novo usuário do serviço.

588. Os resultados, deverão estar disponíveis posteriormente para as consultas e avaliações, conforme for necessário.

⮚ AGENDAMENTO:

589. O sistema deverá permitir localizar o paciente a ser agendado por: CNS, Nome, Nome Social, Nome da Mãe, Data de Nascimento, Número de Prontuário e/ou Prontuário Familiar.

590. O sistema deverá permitir a alteração de telefones e endereço do paciente sem sair da tela de agendamento.

591. Deverá permitir a seleção das vagas por Tipo de atendimento e especialidade ou procedimento.

592. Deverá permitir visualizar a agenda por profissional ou por unidade, possibilitando ao usuário selecionar o dia e horário desejado dentre os disponíveis.

593. Deverá permitir a inclusão de solicitações em fila de espera, caso não possuam vagas disponíveis para a especialidade ou procedimentos informados no momento dos agendamentos.

594. Deverá permitir o controle de pacientes na fila de espera, agendando automaticamente estes pacientes quando houver abertura de novas vagas.

595. Deverá permitir informar o profissional solicitante ao incluir um paciente na fila de espera, possibilitando também a inclusão de laudos e anexos.

596. Deverá possibilitar a indicação de alta prioridade na inclusão de munícipes na fila de espera.

597. Deverá permitir a impressão do comprovante de agendamento.

598. O sistema deverá permitir o Encaixe do Munícipe, filtrando as vagas por tipo, profissional, especialidade ou procedimento.

599. Deverá permitir a alteração de telefones e endereço do paciente sem sair do agendamento.

600. Deverá apresentar ao usuário de forma clara os próximos horários para encaixe, exibindo data e horários disponíveis.

601. O sistema deverá permitir o cancelamento dos agendamentos, caso seja necessário, possibilitando fixação das informações de Justificativa do cancelamento.

602. O sistema deverá disponibilizar automaticamente as vagas para novos agendamentos, quando houver cancelamento destes.

603. O sistema deverá apresentar filtros para localização específica de cada agendamento podendo filtrar por data, módulo, cancelados ou não, situação de presença, tipo de agenda, unidade de saúde, profissional, especialidade, procedimento e grupo de atendimento.

604. Ao consultar agendamentos, o sistema deverá exibir as informações do agendamento como: Unidade de saúde, Profissional, Munícipe, Especialidade, Módulo, Data/Hora, Atendimento, Prontuário, Grupo de atendimento, Telefones, Cancelado, Situação e Específica (tipo de agenda).

605. Deverá possibilitar realizar download do arquivo em formato pdf para impressão.

606. O sistema deverá permitir a transferência dos agendamentos de um mesmo profissional de uma determinada data para outra data escolhida.

607. Deverá permitir a transferência dos agendamentos de um mesmo profissional para outras datas, de forma aleatórias, conforme disponibilidade dos tipos de vagas.

608. Deverá permitir a transferência dos agendamentos de um mesmo profissional para datas anteriores a data do agendamento, desde que esta seja maior que a data atual.

609. Deverá permitir a transferência de uma agenda de um profissional para outro profissional, desde que compreendem na mesma unidade, especialidade e forma de atendimento.

610. O sistema deverá permitir a transferência, para outro tipo de vagas.

611. O sistema deverá permitir a transferência, para outro tipo de vagas, porém estes agendamentos, não podem possuir o tipo de vaga igual a primeira vez.

612. O sistema deverá permitir a transferência de agendamento com datas retroativas, desde que estes agendamentos, não tenham recebido a confirmação de presença.

⮚ APP ATENÇÃO PRIMÁRIA:

613. Possuir aplicativo para utilização dos ACS.

614. O aplicativo deve dispor de termo de uso e privacidade.

615. O aplicativo deverá funcionar de forma offline (sem acesso à internet). 616. O aplicativo deverá funcionar de forma online (com acesso à internet).

617. O aplicativo deve sincronizar automaticamente os dados da base de dados do Sistema de Gestão para a base do aplicativo. Tais dados como: Cadastros de Indivíduos; Cadastros de Famílias e Domicílios, visitas domiciliares.

618. O aplicativo deverá exibir o histórico de sincronizações efetuadas. Permitindo ao usuário realizar a sincronização manual.

619. O aplicativo deverá permitir a alteração de senha do usuário logado.

620. O aplicativo deverá dispor no cadastro individual, a opção de busca por: Nome; CNS; Nome da Mãe ou Data de Nascimento.

621. O aplicativo deverá apresentar a foto de cadastro do munícipe e permitir a atualização da foto existente.

622. O aplicativo deverá permitir a atualização do cadastro individual.

623. O aplicativo deverá permitir o registro de notificação de saída de cadastro.

624. O aplicativo deverá exibir o status da sincronização dos dados no histórico de sincronização.

Permitindo ao usuário a visualizar possíveis inconsistências e a realizar a correção dos dados.

625. O aplicativo deverá permitir a pesquisa de família, por: Nome do Responsável ou Prontuário. 626. O aplicativo deverá permitir acesso a composição do cadastro família, para atualização dos

dados.

627. O aplicativo deverá permitir vincular um novo membro familiar, na composição do cadastro de família.

628. O aplicativo deverá permitir a busca por domicílio, informando: Endereço; Unidade de Saúde e Nome do Responsável.

629. O aplicativo deverá permitir no cadastro de domicílio a visualização, inclusão e atualização da foto do domicílio.

630. O aplicativo deverá permitir a atualização dos dados de domicílio. 631. O aplicativo deverá permitir vincular família ao domicílio.

632. O aplicativo deverá permitir realizar o registro da visita domiciliar e territorial realizada pelo ACS, por família ou membro familiar.

633. O aplicativo deverá sincronizar de forma manual ou automática os dados preenchidos ou atualizados no aplicativo do sistema de Gestão. Sendo o app utilizado de forma online ou offline.

⮚ APP SAÚDE:

634. Deverá dispor de aplicativo disponível para smartphones (Androide e iOS), permitindo que o próprio cidadão faça seu agendamento em consultas na saúde básica e campanhas de saúde.

635. Com o uso do aplicativo o cidadão deverá receber em seu smartphone pushs (alertas) para confirmação de consultas agendadas e lembrete das consultas previamente confirmadas.

636. Deverá ser possível consultar agendamentos, consultas realizadas e a realização do cancelamento de consultas agendadas.

637. O login deverá ser feito utilizando o CNS ou CPF e a Data de Nascimento.

638. As agendas serão disponibilizadas por especialidade (Pediatria, Clínico, Ginecologia e Campanhas de saúde).

639. O aplicativo deverá exibir ao usuário todas as agendas disponíveis para o seu perfil. 640. O aplicativo deverá dispor da consulta/apresentação dos agendamentos.

641. O aplicativo deverá dispor do agendamento de Consultas.

642. O aplicativo deverá dispor da opção de cancelamento de consulta agendada.

643. O aplicativo deverá dispor da opção de confirmação de presença na consulta agendada.

644. O aplicativo deverá dispor do recebimento de SMS e/ou Push (alertas) de Confirmação de presença para as consultas agendadas.

645. O aplicativo deverá dispor do recebimento de SMS e/ou Push (alertas) de lembretes das consultas com presença confirmadas.

646. O sistema deverá apresentar uma página na Internet disponibilizada a partir do site da Prefeitura, permitindo que o próprio cidadão faça seu agendamento em consultas na saúde básica.

647. Utilizando o agendamento online, o cidadão deverá receber em seu smartphone SMS e/ou Push para confirmação de consultas agendadas e lembrete das consultas previamente confirmadas.

648. O Portal deverá ser disponibilizado em plataforma WEB.

649. O login deverá ser feito utilizando o CNS ou CPF e a Data de Nascimento. 650. As agendas deverão ser disponibilizadas por especialidade.

651. O portal deverá exibir ao usuário, todas as agendas disponíveis para o seu perfil.

652. O portal deverá exibir os agendamentos de Consulta/atendimentos e campanhas de saúde. 653. O portal deverá dispor de opção para cancelamento de consulta agendada.

654. O portal deverá dispor de opção para confirmação de presença na consulta agendada.

655. O sistema deverá apresentar serviço de envio de SMS, para confirmação da consulta agendada.

656. Deverá apresentar serviço de envio de Push (alertas), para confirmação da consulta agendada. Importante: O alerta deverá ser enviado para o celular que possuir o aplicativo de Saúde instado e devidamente autenticado com CNS ou CPF e Data de Nascimento.

657. Apresentar serviço de confirmação de agendamento, que contemplará para todas as consultas agendadas, nas duas formas de confirmação de consulta, ou seja, o munícipe deverá receber SMS e Push.

658. Pedido de Confirmação: Deverá ser encaminhado a todos os munícipes com agendamentos em aberto (não confirmados), seguindo os parâmetros de envio configurados no sistema.

659. Confirmação de Agendamento: Deverá ser encaminhada mensagem ao usuário, com a confirmação da consulta agendada.

660. Cancelamento de Agendamento: Deverá ser encaminhada mensagem ao usuário, com a confirmação do cancelamento da consulta agendada.

661. Lembrete: Deverá ser encaminhado a todos os munícipes com consulta e presença confirmada, seguindo os parâmetros de envio configurados no sistema.

⮚ NOTIFICAÇÃO COMPULSÓRIA:

662. O sistema deverá dispor de funcionalidade para registro de notificações compulsórias.

663. Deverá dispor de lista de munícipes para seleção e registro das notificações compulsórias, considerando para busca os dados: nome, CPF, CNS, nome da mãe ou data de nascimento.

664. Deverá quantificar por munícipe, a quantidade de notificações compulsórias registradas.

665. Deverá dispor de histórico de notificações por munícipe, exibindo doença ou agravo, data da notificação, situação e profissional.

666. Deverá possibilitar a edição ou exclusão de notificações compulsórias registradas. 667. Possibilitar o registro da doença ou agravo e data dos primeiros sintomas.

668. Dispor de campos complementares para registro de comorbidades e/ou antecedentes pessoais de saúde.

669. Possibilitar a impressão da ficha de notificação compulsória no modelo XXXXX.

⮚ PRONTUÁRIO ELETRÔNICO:

670. O sistema deverá permitir localizar o paciente para o atendimento por: CNS, nome, nome social, nome da mãe, data de nascimento, número de prontuário e prontuário familiar

671. O sistema deverá dispor do processo de recepção, onde neste é possível identificar os agendamentos para o dia atual, e opções para inclusões de encaixes.

672. O sistema deverá permitir apontamentos referentes ao comparecimento ao atendimento, no processo de recepção, podendo ser Paciente Presente, Paciente Ausente e/ou Profissional ausente.

673. O sistema deverá permitir o direcionamento para o processo de Acolhimento/Escuta Inicial.

674. O sistema deverá exibir lista dos munícipes que estão aguardando passar pela escuta inicial. 675. Deverá permitir que ao selecionar o munícipe para escuta inicial, seja informada a

especialidade do profissional que realizará o acolhimento.

676. Deverá possibilitar o apontamento referente ao motivo da consulta com código CIAP. 677. Permitir o apontamento de observações referente ao motivo da consulta.

678. Possibilitar apontamentos referentes ao exame físico, podendo ser informada pressão arterial, temperatura, frequência cardíaca, frequência respiratória e glicemia capilar e saturação.

679. Possibilitar apontamentos de observação referente ao exame físico. 680. Possibilitar apontamentos referentes a avaliação antropométrica.

681. Permitir apontamentos se possui ou não medicações em uso. 682. Permitir apontamentos referentes a possíveis alergias.

683. Permitir o apontamento de classificação de Risco, podendo ser: Vermelha, Amarelo, Verde e azul.

684. Deverá disponibilizar menu para registro e lançamento da ficha e-SUS, apresentando a ficha de procedimentos e-SUS.

685. Deverá permitir que na ficha de procedimentos e-SUS seja possível lançar procedimentos consolidados, sendo eles total de: aferição arterial; aferição de temperatura; curativo simples; coletas para exames laboratoriais; aferições de glicemia capilar; medições de altura e medições de peso.

686. O sistema deverá disponibilizar no processo de escuta inicial, menu para registro e lançamento dos procedimentos BPA, apresentando os procedimentos efetuados no atendimento em andamento.

687. O sistema deverá possibilitar ao usuário da unidade definir se os campos da tela de consulta do prontuário eletrônico deverão vir abertos ou fechados.

688. O sistema deverá permitir registrar em prontuário eletrônico os atendimentos, agendados e/ou encaixes, realizados pelos profissionais de acordo com o perfil de acesso: Médico; Enfermeiro; Dentista; Outros Profissionais de Nível Superior; Auxiliar/Técnico de Enfermagem; Auxiliar/Técnico de Saúde Bucal; Médico AD; Enfermeiro AD; Outros Profissionais de Nível Superior AD; Auxiliar/Técnico de Enfermagem AD.

689. Deverá permitir indicar ausência/evasão do paciente.

690. Para todos os perfis, na tela inicial (folha de rosto) de atendimento o sistema deverá apresentar minimamente as seguintes informações: Card fixo com nome, data de nascimento, idade e sexo do munícipe; Histórico e Atendimentos pendentes; Lista de Problemas; Antecedentes; Alergias/Reações Adversas; Deficiências; Medicamentos Ativos; Medicamento(s) Prescrito (s); Histórico de Vacinação; Lembretes; Consulta Específica.

691. Para o perfil Médico, o sistema deverá possuir bloco de Dados da Consulta, permitindo o registro das seguintes informações: Subjetivo; Objetivo; Avaliação; Plano; Antecedentes familiares; Antecedentes Pessoais; Alergias/Reações Adversas; Pressão Arterial; Temperatura; Glicemia Capilar; Altura; Peso; IMC – Deve ser calculado automaticamente; Perímetro Cefálico; Gráficos comparativos – para atendimentos de puericultura; Campos para informações do nascimento– para atendimentos de puericultura; Campos para apontamentos do DUM, DPP, Idade Gestacional, Tipo de gravides, Gestações anteriores, Nº de Partos e outros – para atendimentos de pré-natal; Vacinação em dia; Prescrição de Medicamentos; Prescrição de Medicamentos Controlados; Observações; CID – Deve permitir incluir na lista de problemas; CIAP

– Deve permitir incluir na lista de problemas; Deficiências – Deve permitir incluir quais deficiências o paciente possui; Lembretes – Deve permitir incluir lembretes para a próxima consulta.

692. Deverá emitir alertas de indicador conforme o CID selecionado.

693. Para o perfil Médico, o sistema deverá permitir preencher, no prontuário eletrônico, as seguintes fichas do e-SUS: Ficha de Atendimento Individual; Ficha de Procedimentos; Ficha de Marcadores de Consumo Alimentar; Ficha Complementar; Ficha de Vacinação.

694. O sistema deverá refletir na ficha de atendimento individual do e-SUS todos os exames solicitados ou avaliados.

695. Para o perfil Médico, o sistema deverá permitir preencher e confirmar, no prontuário eletrônico, as informações do Lançamento BPA.

696. Para o perfil Médico, o sistema deverá permitir preencher e imprimir, no prontuário eletrônico, solicitações de exame em Guia SADT.

697. Para o perfil Médico, o sistema deverá permitir preencher e imprimir, no prontuário eletrônico, a Guia de Encaminhamento para Especialidade.

698. Para o perfil Médico, o sistema deverá permitir, no prontuário eletrônico, imprimir: Ficha de Atendimento; Receituário; Atestado; Declaração e Declaração de Acompanhante.

699. Para o perfil Médico, o sistema deverá permitir, no prontuário eletrônico, assinar digitalmente os documentos: Atestado; Encaminhamento para especialidade; Ficha de Atendimento; Guia SADT; Receituário e Receituário Especial.

700. Para o perfil Enfermeiro, o sistema deverá possuir bloco de Dados da Consulta, permitindo o registro das seguintes informações: Subjetivo; Objetivo; Avaliação; Plano; Antecedentes familiares; Antecedentes familiares; Alergias/Reações Adversas; Pressão Arterial; Temperatura; Glicemia Capilar; Altura; Peso; IMC – Deve ser calculado automaticamente; Prescrição de Medicamentos; Observações; CIPESC – Deve permitir incluir na lista de problemas; CIAP – Deve permitir incluir na lista de problemas; Deficiências – Deve permitir incluir quais deficiências o paciente possui; Lembretes – Deve permitir incluir lembretes para a próxima consulta.

701. Para o perfil Enfermeiro, o sistema deverá permitir preencher, no prontuário eletrônico, as seguintes fichas do e-SUS: Ficha de Atendimento Individual; Ficha de Procedimentos; Ficha de Marcadores de Consumo Alimentar; Ficha Complementar e Ficha de Vacinação.

702. Para o perfil Enfermeiro, o sistema deverá permitir preencher e confirmar, no prontuário eletrônico, as informações do Lançamento BPA.

703. Para o perfil Enfermeiro, o sistema deverá permitir preencher e imprimir, no prontuário eletrônico, solicitações de exame em Guia SADT.

704. Para o perfil Enfermeiro, o sistema deverá permitir preencher e imprimir, no prontuário eletrônico, Guia de Encaminhamento.

705. Para o perfil Enfermeiro, o sistema deverá permitir, no prontuário eletrônico, imprimir: Ficha de Atendimento e Declaração.

706. Para o perfil Cirurgião Dentista, o sistema deverá possuir bloco de Dados da Consulta, permitindo o registro das seguintes informações: Anamnese; Exame Físico; Pressão Arterial; Temperatura; Glicemia Capilar; Altura; Peso; IMC – Deve ser calculado automaticamente; Plano de Tratamento; Prescrição de Medicamentos; Prescrição de Medicamentos Controlados; Evolução e Intercorrências do Tratamento; Exames Complementares; Observações; CID – Deve permitir incluir na lista de problemas; CIAP – Deve permitir incluir na lista de problemas; Deficiências – Deve permitir incluir quais deficiências o paciente possui; Lembretes – Deve permitir incluir lembretes para a próxima consulta.

707. Para o perfil Cirurgião Dentista, o sistema deverá permitir preencher, no prontuário eletrônico, as seguintes fichas do e-SUS: Ficha de Atendimento Odontológico Individual; Ficha de Marcadores de Consumo Alimentar; Ficha Complementar.

708. Para o perfil Cirurgião Dentista, o sistema deverá permitir preencher e confirmar, no prontuário eletrônico, as informações do Lançamento BPA.

709. Para o perfil Cirurgião Dentista, o sistema deverá permitir preencher e imprimir, no prontuário eletrônico, solicitações de exame em Guia SADT.

710. Para o perfil Cirurgião Dentista, o sistema deverá permitir preencher e imprimir, no prontuário eletrônico, Guia de Encaminhamento.

711. Para o perfil Cirurgião Dentista o sistema deverá permitir, no prontuário eletrônico, imprimir: Ficha de Atendimento; Atestado; Declaração e Declaração de Acompanhante.

712. Para o perfil Outros Profissionais de Nível Superior, O sistema deverá possuir bloco de Dados da Consulta, permitindo o registro das seguintes informações: Subjetivo; Objetivo; Avaliação; Plano; Pressão Arterial; Temperatura; Glicemia Capilar; Altura; Peso; IMC – Deve ser calculado automaticamente; Prescrição de Medicamentos; Prescrição de Medicamentos Controlados; Observações; CIAP – Deve permitir incluir na lista de problemas; Deficiências que o paciente possui; Lembretes – Deve permitir incluir lembretes para a próxima consulta.

713. Para o perfil Outros Profissionais de Nível Superior, o sistema deverá permitir preencher e confirmar, no prontuário eletrônico, as informações do Lançamento BPA.

714. Para o perfil Outros Profissionais de Nível Superior, o sistema deverá permitir preencher e imprimir, no prontuário eletrônico, solicitações de exame em Guia SADT.

715. Para o perfil Outros Profissionais de Nível Superior, o sistema deverá permitir preencher e imprimir, no prontuário eletrônico, a Guia de Encaminhamento para Especialidade.

716. Para o perfil Outros Profissionais de Nível Superior, o sistema deverá permitir, no prontuário eletrônico, imprimir: Ficha de Atendimento e Declaração.

717. Para o perfil Auxiliar/Técnico de Enfermagem, o sistema deverá possuir bloco de Dados da Consulta, permitindo o registro das seguintes informações: Anotações de Enfermagem; Observações; Deficiências que o paciente possui.

718. Para o perfil Auxiliar/Técnico de Enfermagem deverá permitir preencher, no prontuário eletrônico, as seguintes fichas do e-SUS: Ficha de Procedimentos; Ficha de Marcadores de Consumo Alimentar; Ficha de Vacinação.

719. Para o perfil Auxiliar/Técnico de Enfermagem, o sistema deverá permitir preencher e confirmar, no prontuário eletrônico, as informações do Lançamento BPA.

720. Para o perfil Auxiliar/Técnico de Enfermagem, o sistema deverá permitir preencher e imprimir, no prontuário eletrônico, solicitações de exame em Guia SADT.

721. Para o perfil Auxiliar/Técnico de Enfermagem, o sistema deverá permitir preencher e imprimir, no prontuário eletrônico, Guia de Encaminhamento.

722. Para o perfil Auxiliar/Técnico de Enfermagem, o sistema deverá permitir, no prontuário eletrônico, imprimir: Ficha de Atendimento; Declaração.

723. Para o perfil Auxiliar/Técnico em Saúde Bucal, o sistema deverá possuir bloco de Dados da Consulta, permitindo o registro das seguintes informações: Anotações Relacionadas ao Atendimento; Observações e Deficiências que o paciente possui.

724. Para o perfil Auxiliar/Técnico em Saúde Bucal, o sistema deverá permitir preencher, no prontuário eletrônico, as seguintes fichas do e-SUS: Ficha de Procedimentos e Ficha de Marcadores de Consumo Alimentar

725. Para o perfil Auxiliar/Técnico em Saúde Bucal, o sistema deverá permitir preencher e confirmar, no prontuário eletrônico, as informações do Lançamento BPA.

726. Para o perfil Auxiliar/Técnico de Enfermagem, o sistema deverá permitir preencher e imprimir, no prontuário eletrônico, solicitações de exame em Guia SADT.

727. Para o perfil Auxiliar/Técnico de Enfermagem, o sistema deverá permitir preencher e imprimir, no prontuário eletrônico, Guia de Encaminhamento.

728. Para o perfil Auxiliar/Técnico de Enfermagem, o sistema deverá permitir, no prontuário eletrônico, imprimir: Ficha de Atendimento

729. O sistema deverá disponibilizar relatório/tela para acompanhamento dos atendimentos efetuados no modulo de prontuário eletrônico.

730. O sistema deverá possibilitar busca dos prontuários.

731. Deverá ser possível visualizar os atendimentos e seu conteúdo, criando divisão entre prontuários digitalizados e prontuários eletrônicos.

732. Para prontuários digitalizados, o sistema deverá exibir: data, munícipe, unidade de saúde e profissional.

733. Ao selecionar o prontuário digitalizado, o sistema deverá exibir a imagem anexada.

734. Para prontuário eletrônico, o sistema deverá exibir: data, munícipe, profissional, especialidade, unidade de saúde.

735. Para prontuário eletrônico, o sistema deverá exibir os dados do atendimento.

736. O sistema deverá permitir que se vincule Imagens digitalizadas ao Prontuário do Munícipe, por meio de funcionalidade específica informando data do atendimento, unidade de saúde, munícipe e o arquivo de imagem.

⮚ AMBULÂNCIAS / GESTÃO DE FROTAS:

737. O sistema deverá permitir ao usuário cadastrar e gerenciar diferentes informações relacionadas a veículos, incluindo ambulâncias e outros tipos de transporte.

738. Deverá permitir o cadastro das informações relacionadas aos departamentos que utilizarão o sistema, para posteriormente serem vinculados em outras rotinas.

739. Deverá apresentar lista de departamentos cadastrados no sistema, com a opção das ações: edição e exclusão.

740. No âmbito do gerenciamento das informações da frota dos veículos, deverá ser possível cadastrar todos os transportes e veículos utilizados pelo departamento.

741. O cadastro incluirá tipo do transporte, código, placa, chassi, ano de fabricação, modelo, cor predominante, data de licenciamento, tipo de combustível e departamento pertencente.

742. Deverá permitir a inclusão de equipamentos presentes nos veículos.

743. Realizar vinculação de profissionais responsáveis pelos transportes e o cadastro de informações sobre unidades disponíveis e períodos de atendimento relacionados a esses veículos.

744. Deverá possibilitar cadastrar veículos adaptados no sistema.

745. Cadastrar informações relacionadas a passageiros, como capacidade de passageiros, quantidade de assentos especiais e tipo de acessibilidade.

746. Para facilitar a gestão desses transportes, o sistema deverá permitir o cadastramento de oficinas e postos de combustível, fornecendo endereços e dados de contato.

747. Deverá possibilitar cadastrar no sistema, características da carga (altura, comprimento, peso, tipo de transporte, capacidade e quantidade de eixos do transporte/veículo). Também serão registradas informações de combustível, tais como unidade de medida (litro/m³), capacidade do tanque de combustível, consumo e cálculo de autonomia por tanque.

748. O sistema deverá permitir vincular o plano de pedágio ao veículo, bem como cadastrar a TAG de identificação do pedágio.

749. Deverá disponibilizar lista dos veículos cadastrados no sistema, com opções para edição e exclusão, permitindo ainda a alteração do status do veículo (ativo, em manutenção e inativo) e a visualização da agenda de uso do veículo.

750. No que se refere aos agendamentos, o sistema deverá possibilitar agendamento de veículos para transporte de pacientes.

751. Quando selecionada agenda, em ações, deverá apresentar as informações do transporte/veículo e calendário para seleção dos dias e visualização das agendas cadastradas para aquele determinado transporte/veículo.

752. Permitir que os usuários registrem requisições para resgate ou agendamento de transporte. 753. Deverá haver a opção de informar o acompanhante na requisição de transporte.

754. O sistema deverá contemplar funcionalidades relacionadas ao abastecimento de combustível, permitindo que os usuários registrem requisições nesse sentido.

755. Permitir que os usuários registrem solicitações de manutenção dos transportes.

756. Cadastrar dados dos fornecedores, informações padrões de endereço e categorias que deverão ser vinculadas a produtos ou serviços.

757. Possibilitar cadastrar e gerenciar informações de estoque, incluindo controle de estoque, validade dos produtos, estoque mínimo e máximo, além do último custo.

758. Deverá ser disponibilizada lista dos produtos cadastrados no sistema, com opções de edição, exclusão, ativar/desativar e movimentar estoque.

759. Permitir o cadastro dos produtos, possibilitando o registro e vínculo das informações pertinentes ao produto.

760. Deverá permitir registrar as informações de estoque: controle de estoque e validade do produto, estoque mínimo e máximo, último custo.

761. Deverá apresentar lista de produtos cadastrados no sistema, com ações de: editar, excluir, ativar/desativar e movimentar estoque.

762. Permitir movimentação do saldo do produto, sendo de entrada ou saída de saldo. Permitindo registrar a operação da movimentação, quantidade movimentada, número da nota fiscal, empenho e observações.

763. Permitir o cadastro dos serviços, possibilitando o registro e vínculo das informações.

764. Deverá apresentar lista dos serviços cadastrados no módulo, com ações de: editar, excluir, ativar/desativar e movimentar estoque.

765. O sistema deverá apresentar as movimentações do produto ou serviço, quantidade anterior do saldo, tipo de operação (entrada/saída), quantidade movimentada, saldo atual após a movimentação e opção de ações de visualização da movimentação ou ordem de serviço.

766. O sistema deverá realizar o registro das informações dos serviços que serão executados, que conste saldo no estoque, no mínimo:

▪ quantidade do serviço a ser executado no veículo;

▪ prestador que irá realizar o serviço;

▪ departamento responsável pelo veículo;

▪ identificação do veículo;

▪ resumo do serviço a ser realizado;

▪ observações gerais;

▪ opção para adicionar os produtos que conste saldo no estoque e que serão utilizados nesse serviço.

767. O sistema deverá emitir lista das ordens de serviços cadastradas e, opção para: editar, excluir e alterar status da ordem de serviço.

768. Após o cadastro da OS, o sistema deverá apresentar ‘status aberto’, demostrando que a ordem de serviço foi cadastrada para uma futura manutenção no transporte/veículo.

769. Permitir a qualquer momento que, o usuário altere o status da OS para ‘pendente’. Ao selecionar esse status, deverá automaticamente ser alterado para ‘veículo em manutenção’.

770. Permitir que o usuário altere o status da OS para ‘fechada’, demostrando que o serviço no transporte/veículo foi realizado. Ao selecionar esse status, permitir informar a nota fiscal do serviço realizado. O status do transporte/veículo retorna para ‘ativo’ e as quantidades de serviços e produtos informados na OS deverão ser devidamente debitados no saldo de estoque.

771. Deverá permitir cadastrar as rotas que os transportes/veículos realizam, utilizando o georeferenciamento como uma ferramenta para visualização e planejamento da rota a ser registrada.

772. Deverá permitir registro das informações pertinentes a rota do transporte/veículo.

773. Permitir adicionar diversos pontos, seguindo ordem lógica de um ponto de origem inicial da rota, paradas diversas e destino final da rota. Para adicionar os pontos, o módulo deverá permitir que seja identificada a localização por CEP, ou movimentação manual do usuário através do mapa.

774. Após cadastro da rota, o sistema deverá apresentar o ponto de origem com horário de início da rota, os pontos de paradas e destino final da rota com o horário marcado.

775. Permitir que o usuário calcule a rota exata, ou por menor percurso. 776. Permitir vincular passageiros aos pontos de parada da rota.

777. Deverá apresentar as informações geoespaciais com o trajeto da rota desenhado no mapa. 778. Deverá emitir a lista de rotas cadastradas, como permissão para editar e remover.

779. O dashboard deverá apresentar as principais informações deste módulo, como:

▪ Total de passageiros atendidos;

▪ Total de unidades atendidas;

▪ Transportes/Veículos ativos;

▪ Transportes/Veículos em manutenção;

▪ Datas de licenciamentos e regularizações dos transportes/veículos com 60 (sessenta) e 30 (trinta) dias para vencimento;

▪ Total de rotas cadastradas;

▪ Quilometragem total das rotas;

▪ Saldo de produtos e serviços.

⮚ ATENÇÃO PRIMÁRIA:

780. Possibilitar a busca de munícipes em barra de pesquisa, informando: nome; CNS; CPF; nome da mãe ou data de nascimento.

781. Deverá dispor de filtro de munícipes, por atualização cadastral.

782. Deverá dispor de filtro de munícipes, por indivíduos com saída do cadastro: mudança de território ou óbito.

783. Deverá dispor de filtro de munícipes, por profissional e equipe.

784. Deverá permitir que sejam criados Cadastros Individuais em formulário, compatível com a Ficha de Xxxxxxxx Individual do e-SUS.

785. Deverá possibilitar no cadastro individual, o apontamento de dados da unidade responsável.

786. Deverá possibilitar no cadastro individual, o apontamento de dados do profissional responsável.

787. O sistema deverá possibilitar no cadastro individual, o apontamento de dados de identificação do munícipe.

788. Deverá ter interoperabilidade com o CADSUS, onde ao informar o CPF ou CNS do munícipe.

Deverá fazer a busca na base do CADSUS.

789. Deverá possibilitar a importação dos munícipes pesquisados e encontrados na base do CADSUS trazendo sempre o CNS definitivo do munícipe para a base do sistema.

790. Deverá dispor de validação que não permita cadastros duplicados, comparando pelo CPF e CNS do munícipe.

791. Deverá dispor de sincronização entre o cadastro individual e o cadastro de munícipes (simplificado) onde toda alteração que ocorrer em um reflita no outro automaticamente.

792. Deverá possibilitar no cadastro individual, o apontamento do questionário de Informações Sociodemográficas.

793. Deverá possibilitar no cadastro individual, o apontamento do Questionário de Condições e Situações de Saúde.

794. Deverá possibilitar o apontamento de motivo de saída do cadastro.

795. Deverá possibilitar o apontamento do termo de recusa do cadastro individual por parte do munícipe.

796. Deverá permitir que seja inserida uma foto no cadastro individual.

797. Deverá apresentar no processo de Cadastro Individual, opções para edição do cadastro individual, informações familiares, visitas domiciliares e saída do cadastro.

798. Deverá permitir que sejam criados Cadastros Domiciliar e territorial em formulário compatível com a ficha de Cadastro Domiciliar e Territorial do e-SUS.

799. Deverá permitir que seja inserida uma foto do domicílio, terreno, comércio etc., no cadastro domiciliar e territorial.

800. Deverá permitir o apontamento de dados da unidade responsável.

801. Deverá permitir o apontamento de dados do profissional responsável.

802. O sistema deverá permitir o apontamento do endereço e local de permanência. 803. Deverá dispor de mapa para georreferenciamento do endereço do munícipe.

804. Deverá permitir o apontamento de informações de condições de moradia.

805. Deverá permitir o apontamento de informações instituição de permanência, bem como informações do responsável técnico pela instituição.

806. Deverá permitir o apontamento do termo de recusa do cadastro domiciliar e territorial.

807. O sistema deverá apresentar no processo de Cadastro Domiciliar e Territorial, opções para cadastro individual; editar o domicílio; visitas domiciliares e remoção do domicílio.

808. O sistema deverá possibilitar o cadastro de famílias com os campos de preenchimento: unidade de saúde, profissional responsável, equipe, prontuário familiar, responsável familiar, renda familiar e campo para informar mudança de residência.

809. O sistema deverá possibilitar que um ou mais famílias sejam vinculadas ao domicílio.

810. Após criar a família, deve ser possível incluir os membros da família e o seu grau de parentesco com o responsável familiar.

811. Deverá dispor de validação, que não permita que o responsável familiar seja responsável ou membro de outra família.

812. Deverá dispor de validação, que não permita a alteração do responsável familiar no cadastro individual ou de munícipes, caso este tenha sido informado pelo cadastro de famílias.

813. Deverá permitir em tela específica de famílias, que seja possível editar as famílias, alterando e incluindo membros, podendo ser alterado o responsável familiar ou sinalizar que a família se mudou.

814. Deverá possibilitar o cadastro das equipes, permitindo informar os profissionais vinculados, microáreas e data de entrada.

815. Deverá permitir a busca de uma família cadastrada, por prontuário, responsável ou membro. Deverá também, possuir filtro de busca avançado por: Responsável familiar; Unidade de saúde; Profissional; Equipe e prontuário familiar.

816. Deverá exibir no cabeçalho da ficha de cadastro individual, a versão de compatibilidade e-SUS. 817. Deverá permitir vincular foto no cadastro domiciliar.

818. O sistema deverá permitir acessar o cadastro individual do munícipe, vinculado ao domicílio, editar o cadastro domiciliar e remover domicílio.

819. O sistema deverá permitir o cadastro e a composição da família, em tela específica de cadastro domiciliar.

820. Deverá exibir no cabeçalho da ficha de cadastro domiciliar a versão de compatibilidade e-SUS.

821. Deverá permitir vincular uma ou mais famílias no cadastro domiciliar, validando a duplicidade e informando ao operador caso exista.

822. Deverá permitir o lançamento da visita domiciliar a partir do cadastro domiciliar.

823. Deverá exibir no cabeçalho da ficha de visita domiciliar a versão de compatibilidade e-SUS. 824. Deverá permitir o lançamento da ficha de visita domiciliar retroativa.

825. Deverá permitir a inclusão de membros na equipe informando profissional, ocupação, microárea e data de entrada.

⮚ VISITA DOMICILIAR:

826. O sistema deverá possibilitar o registro das visitas realizadas pelos agentes comunitários de Saúde em formulário compatível com a Ficha de Visita Domiciliar do e-SUS.

827. Deverá permitir a realização da visita para munícipes devidamente cadastrados no cadastro individual, que tenham sido vinculados à uma família e que essa família tenha sido vinculada à um domicílio.

828. Deverá exibir um bloco com as informações do munícipe visitado.

829. Deverá exibir um bloco com informações do atendimento, sendo elas a identificação do profissional, da unidade, equipe, especialidade e data e hora de atendimento.

830. Deverá possibilitar lançar as informações da visita domiciliar, informando se a visita foi realizada, turno de atendimento, tipo de visita, acompanhamento e avaliação antropométrica.

831. Deverá possibilitar informar se a visita foi compartilhada com outro profissional. 832. Deverá possibilitar informar o tipo de imóvel visitado.

833. Deverá possibilitar que a visita seja realizada para membros específicos da família.

⮚ CONTROLE DE VACINAÇÃO:

834. O sistema deverá permitir que seja efetuado o cadastro de fabricantes.

835. O sistema deverá permitir a associação de um fabricante a um cadastro de vacina. 836. O sistema deverá permitir que seja efetuado o cadastro de vacinas.

837. O sistema deverá permitir que no cadastro de vacinas seja associado a um imunobiológico do e-SUS para compatibilidade com a ficha de vacinação do próprio e-SUS.

838. O sistema deverá permitir que ao selecionar o imunobiológico, traga lista com opções de estratégia pertinentes ao imunobiológico selecionado.

839. O sistema deverá permitir nomear nome e nome popular para a vacina. 840. O sistema deverá permitir que a vacina seja restrita por sexo.

841. O sistema deverá permitir que as doses da vacina sejam restritas por faixa etária.

842. O sistema deverá permitir que seja informado o intervalo entre doses, duração da imunidade, doença evitada e informações da vacina.

843. O sistema deverá permitir o cadastro de Campanhas de Vacinação informando nome da campanha, público-alvo, início da divulgação, término da divulgação, início da aplicação, término da aplicação, meta e o nome da vacina.

844. O sistema deverá permitir que sejam inclusos diferentes locais para aplicações de campanha.

845. O sistema deverá permitir a inclusão de saldo em estoque para vacinas previamente cadastradas, informando qual a vacina, quantidade e lote.

846. O sistema deverá trazer em tela específica as informações da vacina, conforme seu cadastro. 847. O sistema deverá permitir a seleção do lote a ser dada a saída de estoque.

848. O sistema deverá permitir informar a quantidade de vacinas a ser dada a saída de estoque. 849. O sistema deverá permitir informar um motivo de acerto para a saída de estoque.

850. O sistema deverá permitir a visualização do saldo em estoque do imunobiológico. 851. O sistema deverá permitir o agendamento das vacinas.

852. O sistema deverá permitir que, em agendamento de vacinas, ao selecionar o munícipe sejam exibidas as vacinas consideradas em atraso.

853. O sistema deverá permitir que sejam exibidas as opções “já tomou” para registro de vacinas externas e selecionar vacina para prosseguir para o agendamento.

854. O sistema deverá listar as unidades de saúde disponíveis para agendamento de vacinas.

855. O sistema deverá ao selecionar a unidade exibir as datas e horários disponíveis para agendamento.

856. O sistema deverá permitir que seja dada a presença para o paciente, na data da aplicação.

857. O sistema deverá permitir efetuar o lançamento da aplicação da vacina agendada, em formulário de vacinação compatível com a Ficha de Vacinação do e-SUS.

858. O sistema deverá exibir as informações cadastrais do munícipe.

859. O sistema deverá exibir as informações do agendamento, como unidade, especialidade, data e hora.

860. O sistema deverá permitir informar a equipe do profissional.

861. O sistema deverá permitir informar data inicial e hora inicial, data final e hora final. 862. O sistema deverá permitir informar turno de atendimento e local de atendimento. 863. O sistema deverá permitir informar o grupo de atendimento.

864. O sistema deverá permitir a inclusão das vacinas a serem aplicadas, informando imunobiológico, estratégia, dose, lote e fabricante.

865. O sistema deverá permitir que sejam criadas fichas de vacinação compatíveis com a Ficha de Vacinação e-SUS.

866. O sistema deverá exibir as informações cadastrais do munícipe.

867. O sistema deverá exibir as informações do atendimento, como unidade, especialidade, data e hora.

868. O sistema deverá permitir informar a equipe do profissional.

869. O sistema deverá permitir informar data inicial e hora inicial, data final e hora final. 870. O sistema deverá permitir informar turno de atendimento e local de atendimento. 871. O sistema deverá permitir informar o grupo de atendimento.

872. O sistema deverá permitir a inclusão das vacinas a serem aplicadas, informando imunobiológico, estratégia, dose, lote e fabricante.

873. O sistema deverá permitir o registro de aplicações realizadas em campanhas.

874. O sistema deverá permitir a seleção da campanha a qual pertence a aplicação a ser registrada. 875. O sistema deverá permitir a seleção do local de aplicação.

876. O sistema deverá permitir a seleção do munícipe a ser vacinado. 877. O sistema deverá permitir a seleção da dose de vacina a ser aplicada.

878. O sistema deverá permitir informar data, hora, profissional e especialidade.

879. O sistema deverá permitir o registro de aplicações realizadas em campanha em ficha de vacinação compatível com e-SUS.

880. O sistema deverá exibir as informações cadastrais do munícipe.

881. O sistema deverá exibir as informações do atendimento, como unidade, especialidade, data e hora.

882. O sistema deverá permitir informar a equipe do profissional.

883. O sistema deverá permitir informar data inicial e hora inicial, data final e hora final. 884. O sistema deverá permitir informar turno de atendimento e local de atendimento. 885. O sistema deverá permitir informar o grupo de atendimento.

886. O sistema deverá permitir a inclusão das vacinas a serem aplicadas, informando imunobiológico, estratégia, dose, lote e fabricante.

⮚ REGULAÇÃO:

887. O sistema deverá permitir a inclusão das solicitações em fila de espera, CID e data de solicitação, podendo ser anexado laudos, resultado de exames etc.

888. Deverá permitir o apontamento de restrição por condição de saúde, no momento de inclusão em fila de espera, conforme parâmetro pré-estabelecido nas configurações de agendas.

889. Deverá permitir apontamento de alta prioridade de atendimento da solicitação, podendo escolher entre urgente, alta, normal e baixa.

890. Deverá permitir a descrição de anamnese/exame físico na inclusão do paciente em fila de espera.

891. Deverá dispor de opção para anexo de laudos, para que seja possível demostrar/especificar os encaminhamentos definidos como prioritários.

892. Deverá permitir identificar as solicitações que não possuem agenda ativas no sistema. 893. Deverá possibilitar a impressão do protocolo da solicitação.

894. O sistema deverá possuir ambiente destinado à consulta da fila de espera para agendamentos de Regulação.

895. O sistema deverá possibilitar a exportação das solicitações filtradas.

896. O sistema deverá permitir visualizar os detalhes da solicitação, possibilitando a edição da solicitação, podendo editar a unidade e a data de solicitação.

897. O sistema deverá permitir o cancelamento da solicitação, onde o usuário deve inserir uma justificativa para a ação.

898. O sistema deverá permitir a impressão da solicitação, trazendo no impresso protocolo, nome, CNS, prontuário, endereço, telefone, tipo de atendimento, estado da solicitação, unidade solicitante, usuário solicitante, procedimento, prioridade, ocupação solicitada, condição/situação de saúde e data da solicitação.

899. O sistema deverá dispor de lista que exiba as solicitações pendentes de regulação, separando por solicitações devolvidas e pendentes.

900. Deverá exibir para as solicitações devolvidas, o protocolo, nome, ocupação procedimento e a opção de visualizar a solicitação.

901. Deverá exibir para as solicitações pendentes a unidade de saúde, protocolo, nome, ocupação, procedimento e a opção de visualizar a solicitação.

902. Deverá permitir apontamento e definição sob as solicitações inseridas como alta prioridade, podendo o usuário aprovar a solicitação, mantendo assim na fila como prioridade entre os primeiros lugares na fila de espera.

903. Deverá dispor de opção que sinalize que a solicitação não possui prioridade inserindo justificativa para a ação, assim a solicitação volta a rotina da fila eletiva.

904. Deverá permitir o cadastro dos motivos de desistência para os agendamentos da Regulação.

905. Deverá disponibilizar as opções cadastradas como motivos de desistência para apontamento no processo de cancelamento das solicitações.

906. O sistema deverá efetuar as reservas das vagas de Regulação automaticamente todos os dias, sempre obedecendo a ordem da Fila de Espera.

907. Deverá permitir o filtro de solicitação em fila de espera por unidade de saúde, especialidade, procedimento, protocolo e se a solicitação é de retorno.

908. Deverá listar as solicitações por posição na fila de espera.

909. Deverá permitir a confirmação do agendamento para solicitação de fila de espera. 910. Deverá permitir o cancelamento da solicitação informando o motivo da desistência.

911. Deverá possibilitar a impressão do protocolo de agendamento, após fixação, e confirmação da vaga para o atendimento informado na solicitação.

912. Deverá exibir no impresso de confirmação de agendamento os dados do usuário.

913. Deverá possibilitar o controle de vagas externas, ofertadas para determinadas demandas de agendamentos, permitindo inclusão de pedidos para atendimentos em unidades fora da regulação municipal.

914. Deverá permitir o acompanhamento dos agendamentos sob os pedidos/solicitações externas, criando uma fila de espera para estes.

915. Dispor de filtros para consultar as solicitações externas. 916. Deverá listar as solicitações exibindo posição na fila.

917. Deverá possibilitar visualização dos detalhes das solicitações para atendimentos externos. 918. Deverá permitir que o usuário registre o agendamento da solicitação.

919. Deverá permitir o cancelamento da solicitação.

⮚ COTAS DE VAGAS REGULAÇÃO:

920. O sistema deverá permitir o cadastro de nova cota, informando: unidade de saúde; tipo de cota sendo recorrente ou período definido; data; período de vigência com data início e data fim

e opção para determinar a habilitação de bolsão de vagas, informando a partir de qual data as vagas não utilizadas das cotas poderão ser agendadas.

921. Deverá permitir configurar cotas para as equipes de saúde, incluindo as equipes podendo buscar por INE.

922. O sistema deverá permitir configurar cotas, por: especialidade/procedimentos, informando se é ilimitada ou não, e a quantidade de cotas.

923. O sistema deverá permitir configurar cotas por profissionais, informando a especialidade ou procedimento e incluindo os profissionais.

924. Deverá permitir que seja definida uma data para liberação de todas as vagas disponíveis das cotas não utilizadas.

⮚ CADASTROS BÁSICOS / ESTOQUE:

925. O sistema deverá permitir o cadastro de categorias de produtos, informando o código da categoria e o nome.

926. O sistema deverá permitir o cadastro de famílias de produtos, informando o código da família e o nome.

927. O sistema deverá permitir o cadastro de grupos de produtos, informando o código do grupo e o nome.

928. O sistema deverá permitir o cadastro de princípios ativos, informando o código do princípio ativo e o nome.

929. O sistema deverá permitir o cadastro de tipos de produtos, informando o código do tipo e o nome.

930. O sistema deverá permitir o cadastro de unidades de medidas de produtos, informando o código da unidade de medida, o nome e a abreviatura.

931. O sistema deverá permitir o cadastro de motivos de acerto, informando: código, nome e o tipo de movimentação ao qual o motivo de acerto se encaixa, podendo ser entrada, transferência, saída e perda.

932. O sistema deverá permitir a alteração dos lotes dos produtos recebidos, podendo alterar o lote, data de vencimento, programa de saúde, CNPJ do fabricante, nome do fabricante internacional, CNPJ do distribuidor e nota fiscal.

933. O sistema deverá permitir a emissão de etiquetas com código de barras, dispondo das informações dos produtos.

⮚ DISPENSAÇÃO:

934. O sistema deverá dispor de todas as opções necessárias, para dispensação de produtos/medicamentos aos munícipes.

935. Deverá controlar a dispensação de medicamentos, sugerindo ao operador, os lotes com datas de vencimento mais próximas.

936. Deverá apresentar o histórico de medicamentos dispensados ao paciente.

937. Deverá exigir para profissionais prescritores externos que seja informado nome, número de registro, órgão de classe e estado do órgão classe.

938. Deverá exigir que o usuário informe o nome da unidade de saúde para dispensação com receitas, que não pertencem a unidade que está dispensando o produto/medicamento, se a unidade não estiver cadastrada no sistema, deverá ser informado o nome da unidade e CNES.

939. Deverá possuir cálculo para dispensação de medicamentos, sugerindo a quantidade necessária para dispensação.

940. O sistema deverá permitir registrar as prescrições e dispensações dos medicamentos. 941. O sistema deverá permitir exibição das dispensações anteriores.

942. Deverá apresentar mensagem de alerta informando se o munícipe, já possui em uso, o medicamento que está sendo dispensado, de acordo com dispensações anteriores identificadas para o mesmo munícipe, dispondo de opção para prosseguir ou não com a entrega do medicamento.

943. O sistema deverá exibir dentre o produto selecionado, as informações de lote, data de validade e quantidade do item em estoque. Exibindo em ordem cronológica o produto com a menor data de validade.

⮚ ALMOXARIFADOS:

944. O sistema deverá permitir o cadastro e edições de almoxarifados.

945. O sistema deverá disponibilizar os almoxarifados cadastrados, para utilização nos processos disponíveis para entradas e saídas de saldos.

946. O sistema deverá permitir o vínculo dos almoxarifados, com as unidades de saúde.

947. O sistema deverá permitir apontamento de um determinado almoxarifado como sendo o principal.

948. O sistema deverá permitir o cadastro e edições de Centro de Custos.

949. O sistema deverá disponibilizar os centros de custos cadastrados, para utilização nos processos disponíveis para entradas e saídas de saldos.

950. O sistema deverá permitir o vínculo dos centros de custos com as unidades de saúde.

951. O sistema deverá permitir apontamento de um determinado centro de custo como sendo o principal.

952. O sistema deverá permitir o cadastro e a características dos produtos.

953. O sistema deverá permitir a associação do produto em estoque na aplicação com itens da tabela CATMAT.

954. O sistema deverá permitir a associação do produto em estoque na aplicação com produtos Hórus.

955. O sistema deverá dispor de opção/parâmetro que defina se o produto poderá ter o saldo visualizado via aplicativo.

956. O sistema deverá disponibilizar os produtos cadastrados, para utilização nos processos disponíveis para entradas, saídas e transferências.

957. O sistema deverá permitir cadastrar fornecedores, dispondo de todos os campos necessários, como: CNPJ, nome e dados de contato.

958. O sistema deverá disponibilizar os fornecedores cadastrados, para utilização no processo disponível para entradas por recebimento físico (nota fiscal).

959. O sistema deverá disponibilizar opção que permita a consulta dos produtos com saldos e lotes vencidos, informando o código do lote.

960. O sistema deverá disponibilizar opção que possibilite a exclusão/remoção dos saldos vencidos, exibindo os lotes vencidos.

961. O sistema deverá dispor de opção para inativação dos lotes listados.

962. Permitir na inativação de lotes que o usuário visualize a quantidade de produtos disponíveis e se essas quantidades estão sendo requisitadas em algum processo.

963. O sistema deverá possibilitar a entrada de saldos para os produtos, através de movimentações especificas, como Entrada direta e Entrada por recebimento físico.

964. O sistema deverá dispor dos campos número do pedido, centro de custo, fornecedor, número da nota fiscal, custo total da nota e data de emissão da nota fiscal no processo de recebimento físico.

965. O sistema deverá permitir a baixa de saldos de forma direta, com o intuito de realizar ajustes no estoque.

966. O sistema deverá permitir registrar doações, perdas, empréstimos e devoluções.

967. Deverá permitir a retirada dos saldos dos produtos por requisições (podendo ser de Consumo ou transferência).

968. O sistema deverá permitir o cadastro de novas requisições de transferência para que o almoxarifado central consiga realizar as transferências de produtos para as unidades, farmácias e afins.

969. O sistema deverá permitir controlar os pedidos de produtos pelos tipos de Requisição de Transferência por unidade de saúde e/ou setor. Podendo buscar requisições filtrando por data inicial, data final, código da requisição, situação, almoxarifado origem, centro de custo origem, almoxarifado destino, centro de custo destino e produto.

970. O sistema deverá listar como resultado de busca, as informações: requisição (código), data/hora da inclusão, usuário da inclusão, almoxarifado de destino e situação.

971. O sistema deverá possibilitar a liberação ou cancelamento da requisição.

972. O sistema a deverá permitir que sejam inclusos os produtos que farão parte da requisição, informando o produto e a quantidade requisitada.

973. O sistema deverá permitir que a requisição escolhida e seus produtos sejam liberados. 974. O sistema deverá permitir que a requisição escolhida seja cancelada.

975. O sistema deverá dispor de filtros para busca das requisições de transferência.

976. O sistema deverá listar após filtro os dados das requisições, exibindo: código da requisição, data/hora da inclusão, usuário da inclusão, produto, almoxarifado de destino, quantidade requisitada e quantidade separada.

977. O sistema deverá permitir a separação dos produtos, da requisição, finalização da requisição ou cancelamento.

978. O sistema deverá dispor de filtros para busca das requisições de transferência para atendimento.

979. O sistema deverá listar após filtro os dados das requisições, exibindo código da requisição, data/hora da inclusão, usuário da inclusão, produto, almoxarifado de origem, almoxarifado de destino, quantidade reparada e quantidade atendida.

980. O sistema deverá permitir o atendimento da requisição, informando a quantidade atendida para o produto e a data de atendimento.

981. O sistema deverá permitir o cancelamento de requisições que não foram atendidas.

982. O sistema deverá dispor de filtros para busca das requisições de transferência para entrega. 983. O sistema deverá listar após filtro os dados das requisições, exibindo código da requisição,

data/hora da inclusão, usuário do atendimento, produto, almoxarifado de origem, almoxarifado de destino, quantidade atendida e quantidade entregue.

984. O sistema deverá permitir a entrega da requisição selecionada, informando a quantidade entregue.

985. O sistema deverá permitir o cadastro de novas requisições de consumo para que os almoxarifados possam realizar a baixa de produtos consumidos localmente.

986. O sistema deverá dispor de filtros para busca das requisições, podendo filtrar por data inicial e final, código da requisição, situação, almoxarifado, centro de custo e produtos.

987. O sistema deverá listar as requisições filtradas, exibindo código da requisição, data/hora da inclusão, usuário da inclusão, centro de custo e situação.

988. O sistema a deverá permitir incluir os produtos nas requisições, informando o produto, quantidade, lotes disponíveis em estoque e quantidade de cada lote.

989. O sistema deverá permitir a liberação das requisições para separação.

⮚ FATURAMENTO BPA E RAAS:

990. O sistema deverá permitir efetuar a confirmação do BPA-C e BPA-I em tela única.

991. Deverá permitir efetuar, em tela específica, o lançamento de ações consolidadas realizadas a um número grande de participantes.

992. Deverá permitir, em tela específica, o lançamento de procedimentos de enfermagem de forma quantitativa.

993. O sistema deverá permitir coletar todas as informações necessárias para exportação do arquivo BPA.

994. Deverá permitir efetuar a validação do arquivo consolidado para importações do BPA (Boletim Produção Ambulatorial).

995. Disponibilizar opção que permita a alteração da especialidade, para os faturamentos de unidades de Pronto Atendimento, assim, possibilitando o ajuste de especialidades que foram inseridas nas fichas de atendimentos de forma incorreta.

996. Deverá permitir a geração de arquivo para importações do BPA (Boletim Produção Ambulatorial), bem como, permitir selecionar uma ou mais unidades para geração do arquivo.

997. Deverá exibir em tela específica a quantidade de procedimentos gerados no arquivo BPA por especialidade.

998. Deverá permitir a emissão de relatório de consistência do arquivo BPA.

999. Deverá permitir a emissão de relatório de consulta dos procedimentos por período, por especialidade e por profissional.

1000. O sistema deverá permitir efetuar o lançamento RAAS.

1001. Deverá permitir coletar todas as informações necessárias para exportação do arquivo RAAS.

1002. Deverá memorizar as informações registradas no último lançamento RAAS do paciente e transmitir essas informações para o lançamento atual.

1003. Deverá permitir a geração de arquivo para importações do RAAS.

1004. Deverá efetuar validação dos dados na própria tela específica de lançamento RAAS.

⮚ FATURAMENTO E-SUS:

1005. O sistema deverá permitir o registro de todas as informações da Ficha de Atendimento Domiciliar do e-SUS.

1006. Deverá permitir o registro de todas as informações da Ficha de Atendimento Individual do e- SUS.

1007. Deverá permitir o registro de todas as informações da Ficha de Atividade Coletiva do e-SUS.

1008. Deverá permitir o registro de todas as informações da Ficha de Avaliação de Elegibilidade e Admissão do e-SUS.

1009.	Deverá permitir o registro de todas as informações da Ficha de Cadastro Domiciliar do e-SUS.
1010.	Deverá permitir o registro de todas as informações da Ficha de Xxxxxxxx Individual do e-SUS.
1011.	Deverá permitir o registro de todas as informações da Ficha de Procedimentos do e-SUS.
1012.	Deverá permitir o registro de todas as informações da Ficha de Visita Domiciliar do e-SUS.
1013.	Deverá permitir o registro de todas as informações da Ficha de Atendimento Odontológico

Individual do e-SUS.

1014. Permitir o registro de todas as informações da Ficha de Marcadores de Consumo Alimentar do e-SUS.

1015. Permitir o registro de todas as informações da Ficha Complementar (Síndrome Neurológica) do e-SUS.

1016. Permitir o registro de todas as informações da Ficha de Vacinação do e-SUS.

1017. O sistema deverá dispor de validação sob os registros das fichas do e-SUS que alerte a falta de preenchimento de campos obrigatórios.

1018. O sistema deverá dispor de validação sob as fichas e-SUS já registradas, alertando inconsistências encontradas para que o usuário tenha a possibilidade de correção antes do envio.

1019. O sistema deverá dispor de validação dos dados dos munícipes, informados nas fichas de cadastro individual e-SUS.

1020. O sistema deverá permitir dentro do processo de faturamento e-SUS do prontuário eletrônico e na Ficha de Atendimento Individual Odontológico, o cadastro de odontograma.

1021. O sistema deverá possibilitar o cadastro de novos odontogramas e edição de odontogramas ora cadastrados.

1022. O sistema deverá exibir em tela, a imagem do odontograma contendo os 52 dentes da arcada dentária do paciente e, as 5 faces de cada dente.

1023. O sistema deverá permitir que seja selecionada uma ou mais faces de cada dente, para indicação de procedimentos realizados ou problemas encontrados.

1024. O sistema deverá permitir que seja atribuída uma cor à cada face do dente editado, sendo as cores vermelho, azul e preto.

1025. O sistema deverá permitir adicionar observações para cada face tratada.

1026. O sistema deverá exibir ao lado do odontograma todos os dentes que receberam algum tipo de tratamento, com a sua devida numeração e procedimento realizado/ problema encontrado.

1027. O sistema deverá permitir que ao clicar sob a imagem de um dente específico o usuário, possa informar a ausência de um dente ou extração do mesmo, deixando-o desabilitado para receber tratamentos.

1028. O sistema deverá permitir o salvamento do odontograma, gerando uma cópia em pdf para impressão. Essa cópia também deverá ficar disponível para posterior visualização por outros profissionais.

1029. O sistema deverá sempre permitir a edição de um odontograma, preservando seu histórico e criando um odontograma a partir daquele.

⮚ VALIDAÇÕES / EXPORTAÇÕES:

1030. O sistema deverá dispor de tela específica, onde seja possível visualizar todas as fichas e-SUS com inconsistências encontradas no momento da exportação do arquivo, exibindo: data da ficha, tipo da ficha, unidade de saúde, profissional, especialidade, munícipe, as mensagens de erro e a data de verificação.

1031. Deverá permitir a correção das inconsistências das fichas.

1032. O sistema deverá permitir facilmente ajuste sob possíveis inconsistências identificadas nas validações, podendo localizar a ficha inconsistente pelo UUID, em tela específica.

1033. O sistema deverá possuir parâmetro de busca da ficha, por: data de início e data término, tipo de ficha, UUID da ficha e unidade de saúde (identificação da ficha).

1034. O sistema deverá permitir a geração do arquivo para exportação ao e-SUS com todas as fichas produzidas.

1035. O sistema deverá exibir a quantidade de fichas prontas para exportação, por tipo de ficha e o total das fichas geradas.

1036. O sistema deverá dispor de validação que ao gerar o arquivo do e-SUS O sistema não permita a exportação, se houver fichas deste lote com inconsistências.

1037. O sistema deverá permitir o download do arquivo de exportação gerado com sucesso, devendo constar todas as fichas geradas para importação no e-SUS.

⮚ SADT – EXAMES:

1038.	O sistema deverá possibilitar a solicitação de exames para munícipes fora do atendimento.
1039.	O sistema deverá dispor de resumo da solicitação.
1040.	O sistema deverá possibilitar o agendamento dos exames em unidades com agenda

configurada com tipo de atendimento SADT.

1041. Deverá permitir informar a classificação de risco do paciente e o profissional solicitante do exame.

1042. Deverá possuir fácil cadastramento/inclusão de encaminhamentos SADT, para os encaminhamentos necessários dos exames/procedimentos.

1043. Permitir consultar os exames a serem realizados, por: Paciente, Unidade Solicitante, Exame Solicitado, Status da Solicitação, situação, e data solicitação.

1044. Possibilitar a digitação dos resultados de cada exame via atendimento em prontuário eletrônico.

1045. Permitir a configuração das Agendas de forma individualizada por unidade de, considerando os dias da semana x médico executante.

1046.	Possibilitar a geração automática das solicitações de exames a partir do prontuário eletrônico.
1047.	Possibilitar a recepção informar os pacientes os exames a serem realizados.
1048.	Possibilitar o acompanhamento visual do trâmite dos exames incluídos para realização.
1049.	Possibilitar confirmar todos os exames realizados.

⮚ VIGILÂNCIA EM SAÚDE:

1050. Deverá dispor da possibilidade de cadastramento dos tipos de ações informando o nome do tipo de ação.

1051. Deverá apresentar os tipos de ações cadastradas, no processo de Agendamento/Inspeção.

1052. Deverá possibilitar o cadastramento dos estabelecimentos que serão vistoriados informando os dados do estabelecimento, endereço, telefones, funcionários, responsável legal e responsável técnico.

1053. Deverá permitir filtrar, em tela específica, os estabelecimentos, apresentando o nome, telefone e CNAE.

1054. O sistema deverá possuir funcionalidade que possibilite a gestão das atividades dos fiscais da Vigilância, através de consulta dos agendamentos de visitas, no qual pode possibilitar que o supervisor verifique as visitas a serem realizas por fiscais, e acompanhe a situação de cada atividade possibilitando a atualização das informações e a situação dos estabelecimentos vistoriados.

1055.	Deverá permitir o agendamento das visitas/inspeções.
1056.	Deverá permitir que se controle o agendamento das visitas.
1057.	Deverá possibilitar no ambiente do fiscal preenchimento das Considerações, Condição de

Risco do Estabelecimento, Situação Conclusiva do Local.

1058. Deverá permitir registrar as tarefas da vigilância sanitária como visitas, vistorias, acompanhamentos por estabelecimentos, possibilitando a atualização da área e situação do estabelecimento.

⮚ OUVIDORIA:

1059. O sistema deverá possibilitar à todos os usuários acesso aos dados informativos da Ouvidoria e Disque-Saúde do SUS, de forma que possam passar o máximo de informações ao Paciente, rapidamente.

1060. O sistema deverá permitir controlar atendimentos ao cidadão: sugestões, reclamações, solicitações e ocorrências.

1061.	O sistema deverá permitir tramitação da ocorrência entre o Ouvidor e outros operadores.
1062.	O sistema deverá permitir informações sobre a situação/andamento da ocorrência.
1063.	O sistema deverá permitir priorização de ocorrências, entre prioridade baixa, média ou alta.
1064.	O sistema deverá permitir informações de Reclamações por Xxxxx, Equipe, Profissional.
1065.	O sistema deverá dispor de pop-up que alerte e acumule notificações não lidas e ou em

aberto.

1066. O sistema deverá dispor de lista que exiba as notificações não lidas. 1067. O sistema deverá dispor de lista que exiba as notificações lidas.

1068. O sistema deverá dispor de filtro de notificações, podendo filtrar por: Tipo, data ou prioridade da ocorrência.

⮚ DASHBOARDS:

1069. O sistema deverá dispor de painel de exposição de dashboards em power BI.

1070. Os dashboards devem ser disponibilizados dentro do próprio sistema, sem que o usuário precise sair da mesma para visualizar.

1071. Os dashboards devem ser disponibilizados de forma intuitiva e de fácil utilização.

1072. O sistema deverá dispor de prévia dos indicadores do previne Brasil em dashboards no power BI.

⮚ GESTÃO DE LEITOS:

1073. O sistema deverá dispor de todos os campos necessários, para o cadastro e gestão dos leitos. 1074. O sistema deverá permitir cadastrar:

▪ Leito

▪ Andar do Leito

▪ Ala do Leito

▪ Sala/Quarto do Leito

1075. O sistema deverá permitir vincular:

▪ Andar, Ala, Sala/Quarto e Leitos

▪ Equipamentos aos Leitos

1076. O sistema deverá permitir o registro:

▪ de medicamentos para o paciente internado.

▪ de limpeza dos Leitos

▪ de manutenções dos Leitos

▪ de alta para o paciente internado

1077. O sistema deverá permitir a abertura de prontuário de atendimento para o paciente internado.

1078.	O sistema deverá demonstrar os leitos e o status que cada um possui atualmente.
1079.	O sistema deverá permitir a reserva do leito para manutenção ou limpeza
1080.	O sistema deverá permitir o filtro de agendamentos futuros.
1081.	O sistema deverá permitir o agendamento ou internação imediata do paciente.
1082.	O sistema deverá permitir para agendamentos futuros, a opção de excluir, assim removendo

o agendamento sob o leito.

1083. O sistema deverá permitir, a partir da busca e seleção do munícipe, que seja efetuado internação ou agendamento.

1084. O sistema deverá permitir a seleção do procedimento principal, associado a utilização do leito.

1085. O sistema deverá permitir a seleção do CID, correspondente a doença ou problema de saúde do munícipe.

1086. O sistema deverá permitir a seleção do profissional responsável pela internação ou agendamento.

1087. Conforme houver disponibilidade, o sistema deverá permitir selecionar:

▪ o andar do leito

▪ ala do leito

▪ quarto/sala

▪ escolha do leito

O sistema deverá apresentar a opção de internação, quando o leito estiver disponível para o dia e horário atuais.

1088. O sistema deverá apresentar para a opção de internação, os campos para apontamento da previsão de saída.

1089. O sistema deverá permitir inclusão de internações ou agendamento sem o apontamento de previsão de saída.

1090. O sistema deverá apresentar a opção de agendamento, assim permitindo reservas futuras.

1091. O sistema deverá apresentar para a opção de agendamento, os campos para seleção da previsão de Entrada.

1092. O sistema deverá apresentar para a opção de agendamento, os campos para apontamento da previsão de saída.

1093. O sistema, após salvar a Internação ou agendamento, deverá demostrar os registros nas consultas efetuadas no processo de visualização.

1094. O sistema deverá permitir o cancelamento de agendamentos futuros, na própria tela específica de agendamento de leitos, onde quando for selecionado um leito que já possui agendamento, este será demostrado em um pop-up dando a opção para o usuário, remover este agendamento e incluir um outro agendamento ou internação.

1095. O sistema deverá demonstrar todos os registros de pacientes internados.

1096. O sistema deverá apresentar os dados do paciente, ao selecionar o mesmo na opção de prontuário.

1097. O sistema deverá apresentar todos os campos necessários para as inserções das informações referentes a internação do munícipe.

1098. O sistema deverá apresentar o histórico de atendimento do paciente no módulo de gestão de leitos.

1099. O sistema deverá possuir opção para impressão do prontuário.

⮚ NOTIFICAÇÕES:

1100. O sistema deverá dispor da possibilidade de criação e envio de notificações para os usuários. 1101. O sistema deverá permitir que seja informado para quais unidades, perfis ou profissionais o

aviso será entregue.

1102. O sistema deverá permitir que seja informado o período de exibição do aviso, bem como os horários em que os mesmos deverão ser exibidos.

1103. O sistema deverá dispor de opção que permita ao administrador obter ou não respostas referentes às visualizações de avisos.

1104. O sistema deverá dispor de campo para descrição do aviso.

1105. O sistema deverá dispor de opção que permita ao administrador definir a quantidade máxima de avisos a serem exibidos em tela.

1106. O sistema deverá dispor de mecanismo de busca para avisos criados, podendo filtrar por título do aviso, período e status.

1107. O sistema deverá dispor de possibilidade de visualização da quantidade de visualizações do aviso, quantidade de respostas e o detalhamento do que foi respondido.

1108. O sistema deverá dispor de possibilidade de visualização do período de vigência dos avisos e horários de exibição.

⮚ TERAPIA:

1109. Deverá permitir a inclusão de solicitação de terapia, informando munícipe, grupo atendimento, unidade de saúde, quantidade de sessões, prontuário, ocupação, observação, e profissional solicitante.

1110. Deverá permitir o agendamento das sessões de terapia após inclusão da solicitação, informando tipo de vaga podendo ser primeira vez, retorno, reserva técnica e regulação, profissional e unidade de saúde. Caso haja vagas, o sistema deverá disponibilizar calendário com as datas e horários disponíveis para agendamento.

1111. Deverá disponibilizar de filtros para busca de solicitações, podendo filtrar por munícipe, unidade solicitante, médico solicitante, ficha atendimento, especialidade e situação.

1112. Possibilitar a visualização dos detalhes da solicitação, editar solicitação ou excluir.

1113. Possibilitar o agendamento por múltiplas sessões, no qual o sistema deverá controlar automaticamente os agendamentos, de forma que bloqueie mais sessões que o solicitado e, faça a consistência das solicitações com menor número de sessões do que o solicitado.

1114. Deverá filtrar as Consultas a serem realizados, por: Paciente, Unidade Solicitante, Especialidade, Status da Solicitação, Solicitante e data solicitação.

1115. Aos usuários com acesso a Terapia, deverá possibilitar a abertura da solicitação das sessões a partir do prontuário eletrônico.

1116. Deverá dispor de agendamentos para atendimento individual ou agendamentos para atendimento em grupo.

1117. Deverá possibilitar reagendar as sessões e obrigar a inclusão do motivo do reagendamento.

1118. Deverá possibilitar que o usuário consulte os pacientes com sessões a serem realizadas, informando nome, CNS, CPF, nome da mãe ou data de nascimento.

1119. Apresentar todos os atendimentos existentes para o dia atual, separado em abas por profissional e dispondo de uma aba com todos os registros exibindo hora, munícipe e procedimento principal, possibilitando a confirmação da presença ou apontamento de ausência do munícipe ou do profissional.

1120. Permitir a inclusão de encaixes, caso haja necessidade, apresentando para este processo as vagas disponíveis para o dia, consultada por especialidade, procedimento ou profissionais.

1121. Possibilitar o lançamento de atendimentos retroativos, sob a vagas destinadas as rotinas de terapia.

1122. Permitir a confirmação de presença em dias retroativos, para os casos que por algum motivo, não tiveram a confirmação no dia exato do atendimento/sessão, sob a rotina de terapia informando especialidade, profissional, procedimento, data e hora.

1123. Deverá dispor de filtros para busca de pacientes agendados para sessões de terapia, podendo filtrar por munícipe, especialidade, situação, data início, data fim e hora.

1124. Deverá permitir o cancelamento dos agendamentos/sessões, informando se o cancelamento é somente para a sessão atual ou para todas as sessões da, e fixando o motivo (informado no campo de justificativa), usuário, data e horário da ação de cancelamento.

1125. Deverá permitir a finalização das solicitações, encerrando as sessões nesta contidas que ainda não foram atendidas.

1126. Deverá permitir a impressão de declaração de comparecimento para os pacientes, informando: RG e declaração de comparecimento para acompanhantes informando hora início, hora fim, RG do acompanhante, Nome do acompanhante, sob a rotina de terapia.

1127. Deverá permitir a emissão de atestados, informando CID, data início e fim do afastamento e observações, por profissionais habilitados para esta ação, sob a rotina de terapia.

⮚ INTEGRAÇÃO COM SISTEMA HÓRUS - Sistema Nacional de Gestão da Assistência Farmacêutica

1128. O sistema licitado deverá possuir integração com o Hórus via WebService que relaciona os produtos do estoque interno do sistema e envia as movimentações de produtos de farmácia para o ministério da saúde.

1129. Deverá exibir os detalhes da exportação dos produtos, trazendo data e hora do envio, situação, número do protocolo, código externo e observações.

1130. Deverá listar os itens exportados para o sistema Hórus, exibindo data e hora do envio, almoxarifado, produto, lote, tipo e situação.

⮚ GERAÇÃO DE RELATÓRIOS:

1131. O sistema deverá gerar relatório para consulta de configuração das agendas, contendo filtros de ano, mês, modelo de relatório (analítico ou sintético), unidade de saúde, profissional, especialidade.

1132. Na visão analítica, deverá exibir no detalhe, o nome da unidade de saúde, profissional, especialidade, procedimento, dia da semana, hora inicial e final, tipo de vaga.

1133. Na visão sintética, deverá exibir no detalhe o nome da unidade de saúde, profissional, CBO, procedimento, horas na semana, tipo de vaga e total, com possibilidade de imprimir em PDF e exportação para os formatos CSV, XLS, DOCX, PPTX.

1134. O sistema deverá gerar relatório de Transferência de Agendas, contendo filtros de data inicial e final. Exibindo no detalhe a data de origem, o profissional, o motivo da transferência, a data de transferência, operador (usuário), data da operação, com possibilidade de impressão em PDF do registro da agenda detalhada dos agendamentos transferidos, exibindo a especialidade, profissional de origem, unidade de saúde, operador (usuário), data da operação, data de origem, motivo da transferência, horário, prontuário, CNS, munícipe, data de nascimento, telefone, tipo de regulação, data de destino, profissional de destino.

1135. Gerar relatório para consulta dos Motivos de Bloqueio de agendas, contendo filtros de data inicial e final, motivo de bloqueio, unidade de saúde, especialidade, procedimento, profissional. Exibindo no detalhe o nome do profissional, unidade de saúde, especialidade, procedimento, data início e fim, motivo e observação. Com possibilidade de impressão em PDF do relatório.

1136. Gerar relatório para consulta de Outras Informações cadastradas na agenda, contendo filtro da informação e de preparo. Exibindo no detalhe o nome, os procedimentos associados e a descrição. Com possibilidade de impressão em PDF e exportação em Excel.

1137. O sistema deverá gerar relatório de Preparos ou procedimento com a possibilidade de visualizar ou imprimir o item.

1138. O sistema deverá gerar relatório de análise de vagas, possibilitando visualizar a quantidade de absenteísmo, perda primária e agendamentos por tipo de vaga.

1139. O sistema deverá gerar relatório de absenteísmo.

1140. O sistema deverá gerar relatório de ambulâncias agendadas.

1141. O sistema deverá gerar relatório de munícipes agendados, exibindo no detalhe a data e hora do agendamento.

1142. O sistema deverá gerar relatório de saída de veículos.

1143. O sistema deverá gerar relatório de Atendimento e-Sus, para geração de lista de:

▪ Atendimento Individual

▪ Atendimento Odontológico

▪ Lista de Atividade Coletiva

▪ Lista de Visitas Domiciliares

1144. Possuir filtros por data, profissional e especialidade. Exibindo no detalhe o prontuário do paciente, nome do paciente, data de nascimento e procedimento principal, com possibilidade de impressão por PDF.

1145. O sistema deverá em Atendimento Ambulatorial gerar relatório de produtividade por profissional, com filtros por data de início e fim, profissional, procedimento, ocupação. Exibir no detalhe agrupando por profissional e especialidade o procedimento a quantidade de atendimentos, a porcentagem da produtividade por profissional e o total de procedimentos, com possibilidade de impressão em PDF e exportação em Excel.

1146. O sistema deverá gerar relatório de vagas mensais, com filtros por data inicial e data final, tipo de relatório (analítico ou sintético), procedimento, unidade de saúde, profissional, especialidade. Exibir no detalhe a data, profissional, observação, especialidade, procedimento, tipo de atendimento, tipo de agenda, quantidade configurada, agendada, disponível e encaixe, com possibilidade de impressão por PDF e exportação em Excel.

1147. O sistema deverá gerar relatório de consulta de atendimentos versus agendamentos, contendo filtros de data inicial e final, unidade de saúde, profissional e especialidade. Exibindo no detalhe a especialidade, o profissional a quantidade de agendamentos e atendimentos e o percentual. Possibilitando a impressão em PDF e a exportação em Excel.

1148. O sistema deverá gerar relatório para consulta de agendamentos versus quantidade de vagas, contendo filtros de data inicial e final e nome do profissional. Exibindo no detalhe a data, o nome do profissional, especialidade, procedimento, tipo de agenda, quantidade configurada, agendada,

disponível e excedentes, com possibilidade de exibir somente os excedentes. A impressão deverá ocorrer no formato PDF e XLS.

1149. O sistema deverá possuir listagem de atendimentos médicos, para consulta de atendimentos, com filtros por data, profissional e especialidade. Exibir no detalhe as informações de hora do agendamento, número do prontuário, paciente e nome social, data de nascimento, matrícula, prontuário familiar e procedimento, possibilitando a impressão em PDF ou exportação em XLS.

1150. O sistema deverá gerar relatório para consulta e transferência dos agendamentos, contendo filtros de data, nome do profissional e especialidade. Exibir no detalhe para transferência as informações (horário; prontuário; sus; paciente e nome social; data de nascimento; telefone, matrícula; prontuário familiar; tipo de consumo da vaga). Permitir através dos agendamentos filtrados a realização da transferência por tipo de agendamento (automático; retorno; primeira vez; reserva técnica; regulação; regulação retorno), seleção de transferência para outro profissional, tipo de agenda e o método de transferência.

1151. O sistema deverá gerar relatório de atendimento unificado, contendo filtros de data inicial e final, tipo de relatório (analítico e sintético), unidade de saúde e profissional. Exibindo no detalhe do formato analítico as informações: Data, Profissional, Especialidade, Procedimento, Tipo de agenda, quantidades configurada, agendada, disponível e encaixes. No detalhe do formato sintético as informações: Data, Profissional, Especialidade, quantidades configurada, agendada, disponível e encaixes. Possibilitando a impressão no formato PDF e exportação para os formatos CSV, XLS, DOCX, PPTX.

1152. O sistema deverá gerar relatório de consulta de horários de atendimento PA, contendo filtros de data de início e data final, unidade de saúde, profissional e especialidade. Exibindo no detalhe separando por data o nome do profissional, especialidade, procedimento principal, horário inicial da FA, horário final da FA, número de fichas emitidas, fichas canceladas, fichas atendidas. Com possibilidade de imprimir em PDF e exportar em XLS.

1153. O sistema deverá gerar relatório de produtividade do atendimento PA, contendo filtros por data inicial e final, unidade de saúde, profissional e procedimento. Exibindo no detalhe a unidade de saúde, profissional, data, hora, quantidade de FA abertas, acolhimentos, atendimentos e faturamento. Possibilitando a impressão em PDF e a exportação nos formatos CSV, XLS, DOCX, PPTX.

1154. O sistema deverá gerar relatório de produtividade por profissional, contendo filtros de data inicial e final, nome do profissional, procedimento, ocupação. Possibilitando a impressão em PDF e a exportação em XLS.

1155. O sistema deverá gerar relatório de produção de atendimentos por especialidade, permitindo filtrar por data inicial e final e horário inicial e final. Exibir no detalhe a especialidade e o número de atendimentos. Permitindo a impressão em PDF e a exportação em XLS.

1156. O sistema deverá gerar relatório de atendimentos por municípios e bairros, possuindo filtros de busca por data inicial e final do atendimento, unidade de saúde, estado, município e bairro. Permitir ao operador a geração do relatório nos formatos: analítico e sintético.

1157. No formato analítico exibir no detalhe os municípios, bairros, quantidade de atendimento e porcentagem.

1158. No formato sintético exibir no detalhe o município, a quantidade de atendimentos e porcentagem.

1159. Com possibilidade de impressão em PDF e exportação em XLS.

1160. O sistema deverá gerar relatório de volume de ficha de atendimento (FA) por usuário, contendo filtros de data inicial e final, opção de tipos de relatório (analítico e sintético), unidade de saúde e profissional. Exibir no detalhe a data, o nome do atendente e a quantidade de FA. Possibilitando impressão por PDF e exportação em XLS.

1161. O sistema deverá gerar relatório de produtividade do pronto atendimento (PA), contendo filtros de data inicial e final, opção de visualização por dias do mês ou dias de semana, unidade de saúde, profissional e dias da semana. Exibir no detalhe os horários da faixa de atendimento, os dias do mês ou os dias de semana. Possuir impressão por PDF e exportação em XLS.

1162. O sistema deverá gerar relatório de acidentes / violência, contendo filtros de data de início e término e tipo (acidente de trabalho; violência)

1163. O sistema deverá gerar relatório para consulta dos atendimentos e o grau de risco registrado. Permitir gerar em dois modelos (analítico e sintético) e filtrar por grau de risco. Exibir no detalhe o grau de risco, a data e hora, o nome do munícipe, ficha, com possibilidade de impressão em formato PDF e exportação em XLS.

1164. O sistema deverá gerar relatório de atendimento PA versus dias da semana, contendo filtros de data inicial e final, nome do profissional e ocupação. Exibir no detalhe a especialidade médica, o dia e o dia da semana com as respectivas quantidades. Deverá permitir impressão em PDF e exportação para o Excel.

1165. O sistema deverá gerar relatório de fichas de atendimentos canceladas, contendo filtros de data inicial e final, unidade de saúde, munícipe, número FA e opção de tipo de relatório (analítico e sintético).

1166. Exibir no formato analítico todas a unidades de saúde, data e hora do atendimento, número da FA, munícipe, data e hora do cancelamento, quantidade geral.

1167. Exibir no formato sintético a quantidade por unidade de saúde e a quantidade geral.

Possibilitar a impressão em PDF ou exportação para o Excel.

1168. O sistema deverá gerar relatório de conduta final, contendo filtros por data, unidade de saúde e consulta. Exibir no detalhe o nome da unidade de saúde, a conduta e a quantidade.

1169. O sistema deverá permitir gerar a lista munícipes ausentes no acolhimento. Realizando filtros com os critérios (CNS; nome e senha) e data, possibilitando reverter uma ausência.

1170. O sistema deverá gerar relatório de auditoria, de média de atendimento por hora, contendo filtros de data, tipo de atendimento, unidade de saúde, profissional, especialidade, procedimento. Exibindo no detalhe o nome da unidade de saúde, o profissional, a especialidade, procedimento, tipo de atendimento, o valor mínimo hora, média hora, máxima hora. Permitindo imprimir por PDF e exportar em XLS.

1171. O sistema deverá gerar relatório de agendamento por usuário, contendo filtro de data, unidade de saúde e profissional. Exibindo no detalhe, o usuário, a data, o horário, o tipo de agendamento, o tipo de atividade, profissional, procedimento, unidade agendada. Possibilitando a exportação por XLS e a impressão em PDF.

1172. O sistema deverá gerar relatório de produtividade por profissional, contendo filtros de data, profissional, procedimento e ocupação. Possibilitando a exportação por XLS e a impressão em PDF.

1173. O sistema deverá gerar relatório de agenda duplicada, contendo filtros por unidade de saúde, ocupação, procedimento, profissional e tipo de duplicidade. Possibilitando a exportação por XLS e a impressão em PDF.

1174. O sistema deverá gerar relatório de cotas de vagas por especialidade, com filtros de data, situação da agenda, e unidade de saúde. Possibilitar a impressão em PDF.

1175.	O sistema deverá gerar relatório de cotas de vagas. Possibilitar a impressão em PDF.
1176.	O sistema deverá gerar relatório de fila de espera – Reservas
1177.	O sistema deverá gerar relatório de regulações agendadas.
1178.	O sistema deverá gerar relatório de solicitações sem agendamento.
1179.	Deverá gerar relatório da atenção primária, acerca de saneamento básico com base nas

informações cadastradas nos domicílios. Possibilitar a impressão em PDF e a exportação para os formatos CSV, XLS, DOCX, PPTX.

1180. Deverá gerar relatório de população residente. O relatório deverá ser impresso no formato PDF e exportado para os formatos CSV, XLS, DOCX, PPTX.

1181. O sistema deverá gerar relatório de usuários com ou sem plano de saúde privado. O relatório deverá ser impresso no formato PDF e exportado para os formatos CSV, XLS, DOCX, PPTX.

1182. O sistema deverá gerar relatório de produção geral de fichas e-SUS. O relatório deverá ser impresso no formato PDF e exportado para os formatos CSV, XLS, DOCX, PPTX.

1183. O sistema deverá gerar relatório de acompanhamento de gestantes e puérperas. O relatório deverá ser impresso no formato PDF e exportado para os formatos CSV, XLS, DOCX, PPTX.

1184. Deverá gerar relatório de consultas agendadas e/ou demanda espontâneas. O relatório deverá ser impresso no formato PDF e exportado para os formatos CSV, XLS, DOCX, PPTX.

1185. Deverá gerar relatório para consulta das informações do indivíduo, cadastradas na ficha de cadastro individual. O relatório deverá ser impresso no formato PDF e exportado para os formatos CSV, XLS, DOCX, PPTX.

1186. Deverá gerar relatório de localização dos domicílios. O relatório deverá ser impresso no formato PDF e exportado para os formatos CSV, XLS, DOCX, PPTX.

1187. Relatório – Estoque:

1188. Deverá gerar relatório de saldos de estoque disponível, com filtros de data inicial e final da validade dos produtos, almoxarifado, lote, família, produto, grupo, tipo, categoria, unidade de medida e opção para exibição de produtos com saldos zerados. Exibir no detalhe, almoxarifado, lote, data de validade, grupo, produto, unidade de medida, saldo reservado, saldo em trânsito, saldo disponível, estoque físico com possibilidade de exportação do relatório.

1189. Deverá gerar relatório de saldos agrupados de todos os almoxarifados, com filtros de data de validade, data do saldo, lote, almoxarifado, tipo de produto, categoria, grupo, família, produto e centro de custo. Exibir no detalhe, nome do produto, unidade de medida, saldo reservado, saldo disponível, custo unitário, custo total com possibilidade de imprimir relação e exportar para o Excel.

1190. Deverá gerar relatório de produtos vencidos e a vencer, com filtros por almoxarifado, lote, data de validade inicial e final, família, produto, categoria, grupo. Exibir no detalhe, nome do produto, unidade de medida, lote, almoxarifado, quantidade e data de validade com possibilidade de impressão em PDF ou exportação em Excel.

1191. Deverá gerar relatório de produtos com saldos reservados, com filtros para consulta por almoxarifado, lote, data de validade, família, produto, categoria, grupo. Exibir no detalhe, nome do produto, unidade de medida, lote, almoxarifado, quantidade, número da requisição, unidade de saúde solicitante com possibilidade de impressão em PDF ou exportação em Excel.

1192. Deverá gerar relatório de produtos no estoque agrupado por almoxarifado, com filtros de data de validade, data do saldo, lote, almoxarifado, tipo de produto, categoria, grupo, família, tipo de produto, categoria, centro de custo. Exibir no detalhe o nome do almoxarifado, produto, unidade de medida, saldo reservado, saldo disponível com possibilidade de imprimir a relação em PDF ou exportar os dados em Excel.

1193. Gerar relatório de saídas de produtos do estoque, com filtros de almoxarifado, centro de custo, produto, data de início e final. Exibir no detalhe o nome do almoxarifado, código do produto, nome do produto, quantidade de saída, lote, validade, documento e centro de custo com possibilidade de imprimir a relação em PDF ou exportar os dados em Excel.

1194. Gerar relatório de histórico de movimentação, com filtros de data inicial e final, data de validade, almoxarifado de origem, almoxarifado de destino, centro de custo, produto, lote, tipo de movimentação, motivo de acerto, grupo do produto, tipo do produto, categoria do produto. Exibir de forma agrupada por almoxarifado de origem as informações de data e hora da movimentação, grupo, produto, validade, almoxarifado de destino, lote, usuário, tipo de movimentação, motivo de acerto, quantidade em estoque (anterior; movimentada e posterior a movimentação) com possibilidade de impressão do relatório em PDF ou exportação para os formatos CSV, XLS, DOCX, PPTX.

1195. Devera gerar relatório de dispensação munícipe, com filtros de data inicial e final, munícipe, almoxarifado, produto. Exibir no detalhe por almoxarifado a data da dispensação, telefones do munícipe, nome do munícipe, produto, unidade de medida e as quantidades (dispensada; dias; diária) com possibilidade de impressão do relatório em PDF ou exportação para os formatos CSV, XLS, DOCX, PPTX.

1196. Deverá gerar relatório de saídas por unidade e nota fiscal, com filtros de unidade de saúde, fornecedor, almoxarifado, centro de custo, nota fiscal, produto, data de início e final. Exibir no detalhe o código do produto, nome do produto, lote, almoxarifado, centro de custo, quantidade e nota fiscal com possibilidade de impressão do relatório em PDF ou exportação em Excel.

1197. Deverá gerar relatório de comparativo de consumo por unidade de saúde, com filtros de data inicial e final, produto, centro de custo. Exibir no detalhe por almoxarifado, nome do produto e quantidade com possibilidade de impressão do relatório em PDF ou exportação para os formatos CSV, XLS, DOCX, PPTX.

1198. O sistema deverá gerar relatório produção de atendimento por munícipe, contendo filtros por data inicial e final, tipo de consulta (agendamentos futuros; atendimentos realizados; absenteísmo munícipe), unidade de saúde, munícipe, especialidade, procedimento, profissional. Exibir no detalhe o nome do munícipe, especialidade, procedimento e quantidade. Possibilitar a impressão em PDF e a exportação em Excel.

1199. O sistema deverá gerar relatório de faturamento BPA-C e BPA-I, contendo filtros por data e unidade de saúde. Exibir no detalhe a unidade de saúde, subgrupo, forma de organização, CBO, procedimento, quantidade, total por unidade e total BPA C + BPA I. Possibilitar a impressão em PDF e a exportação em Excel.

1200. O sistema deverá gerar relatório de faturamento versus atendimento, contendo filtros de data inicial, final, unidade de saúde, especialidade, procedimento e profissional. Exibir de forma detalhada por unidade de saúde, atendimentos por especialidade, presença, faturado, não faturado, retornos. Possibilitar a impressão em PDF e a exportação em Excel.

1201. O sistema deverá gerar relatório de acompanhamento de produção, contendo filtros por data inicial, final, tipo de atendimento e unidade de saúde. Exibir no detalhe a unidade de saúde, data,

número de atendimento PA, número de atendimento faturado. Possibilitar a impressão em PDF e a exportação em Excel.

1202. O sistema deverá gerar relatório de faturamento por CBO, contendo filtros por data, tipos de lançamento (BPA-I e BPA-C), unidades de saúde, especialidade, procedimento, profissional. Exibir no detalhe as unidades de saúde, CBO, procedimento, quantidade e total geral. Possibilitar a impressão em PDF e a exportação em Excel.

1203. O sistema deverá gerar relatório de produção mensal, contendo filtros por data e unidade de saúde. Exibir no detalhe a unidade de saúde, CNES, a quantidade de fichas em aberto, quantidade da produção de enfermagem, produção total, produção RAAS e total CBO. Com possibilidade de impressão do relatório em PDF ou exportação para os formatos CSV, XLS, DOCX, PPTX.

1204. O sistema deverá gerar relatório de quantidade de atendimentos, contendo filtros de data, unidade de saúde e munícipe. Com possibilidade de impressão do relatório em PDF ou exportação para os formatos CSV, XLS, DOCX, PPTX.

1205. O sistema deverá gerar relatório de mapa de doença, contendo filtros por data, CID, quantidade.

1206. O sistema deverá gerar relatório de histórico de atendimento por paciente. Permitindo filtrar por paciente os dados de histórico PA, histórico de atendimento ambulatorial, histórico de solicitações de regulação, histórico de terapia, histórico de atendimentos.

1207. O sistema deverá gerar relatório de consulta de prontuários, digitalizados e eletrônicos.

1208. O sistema deverá gerar relatório de doadores de sangue por tipo sanguíneo. Possibilitar a impressão por PDF e a exportação no formato XLS.

1209. O sistema deverá gerar relatório de registros de notificação compulsória para consulta e controle das doenças de agravo notificadas. Com filtro por data, doença ou agravo e munícipe. O sistema deverá possibilitar a exportação no formato XLS e a impressão em PDF.

1210. O sistema deverá gerar relatório de agendamentos pendentes de terapia. Com filtro por munícipe e grupo de atendimento. Permitir a impressão do relatório em PDF.

1211. O sistema deverá gerar relatório de vacinas atrasadas, com filtros de vacina e inicial do nome do munícipe.

1212. O sistema deverá gerar relatório estatístico de campanha de vacinação, permitindo filtrar por campanha para retorno das informações de período de divulgação, vacina, meta, total de aplicação.

1213. O sistema deverá gerar relatório de carteirinhas de vacinação, permitindo consultar por munícipe o histórico da carteira de vacinação e realizar a impressão dos registros.

1214. O sistema deverá gerar relatório de estoque de vacina, com filtro por unidade de saúde e possibilidade de impressão em PDF.

18. DA SUBCONTRATAÇÃO

Será permitida a subcontratação, apenas e tão somente dos serviços do servidor em nuvem.

19. DA DEMONSTRACÃO TÉCNICA DO SISTEMA

A licitante classificada em primeiro lugar na fase de lances e classificada na fase de habilitação, será convocada pela Prefeitura Municipal de Cajamar para realizar demonstração técnica dos itens especificados para aprovação pelo órgão fiscalizador.

A demonstração deverá ser apresentada em um prazo máximo de 05 (cinco) dias úteis, contados a partir do momento que foi declarado vencedor por data e horário estipulado pela Prefeitura.

A fiscalização da Prefeitura terá um prazo máximo de 3 (três) dias úteis para fazer a análise da demonstração do sistema e emitir o parecer técnico de aprovação ou não da licitante nesta fase.

A demonstração técnica deverá ser realizada na sede da Secretaria Municipal de Cajamar - PRAÇA XXXX XXXXXXXXX XX XXXXXXXXXX, 30 - CENTRO – CAJAMAR; sendo que todo material necessário a demonstração é por conta da licitante.

A análise se processará por Comissão Técnica a ser indicada na publicação da convocação, de acordo com as condições e critérios estabelecidos a seguir.

A Demonstração se dará na apresentação dos itens elencados na tabela a seguir, os quais são considerados essenciais na operação do sistema, representando 25% do sistema como um todo. Os respectivos itens deverão estar em pleno funcionamento no momento da apresentação.

Se a licitante deixar de comprovar a funcionalidade prática de qualquer item selecionado para a demonstração, será imediatamente desclassificada, face ao desatendimento ao desempenho e qualidade dos itens definidos no edital. Será convocada a licitante vencedora subsequente para apresentar as funcionalidades, observando-se o procedimento ora indicado, bem como demais dispositivos previstos deste Edital e assim sucessivamente, até que uma licitante seja declarada vencedora definitivamente.

Concluída a apresentação da DEMONSTRAÇÃO do licitante habilitado, verificada a comprovação ao atendimento das especificações obrigatórias e aceita a sua demonstração pela Equipe Técnica, será realizada a adjudicação do objeto.

Itens das especificações técnicas mínimas, OBRIGATÓRIAS do sistema, para demonstração prática estão presentes no Anexo II - DESCRIÇÃO TÉCNICA DOS REQUISITOS FUNCIONAIS E OBRIGATÓRIOS DA SOLUÇÃO.

20. DA VISITA TÉCNICA – FACULTATIVA

A visita técnica é FACULTATIVA, podendo as empresas interessadas em participar desta licitação, comparecer à Prefeitura Municipal de Cajamar, localizada na Xxxxx Xxxx Xxxxxxxxx xx Xxxxxxxxxx, 00 - Xxxxxx, Xxxxxxx, para conhecimento de todas as informações e condições locais para o cumprimento das obrigações.

Para o correto dimensionamento e elaboração de sua proposta poderá o licitante realizar vistoria no local de execução dos serviços, acompanhado por representante da Prefeitura, de segunda à sexta- feira, das 08:00 às 11:00 e das 13:00 às 17:00 horas, mediante agendamento prévio a ser realizado junto ao setor de licitações da Prefeitura, por meio de solicitação dirigida ao endereço eletrônico xx@xxxxxxx.xx.xxx.xx ou pelo telefone (00) 0000-0000.

O prazo para vistoria iniciar-se-á no dia útil seguinte ao da publicação do Edital, estendendo-se até o dia útil anterior à data prevista para abertura da sessão pública. Para a realização da visita técnica, o licitante, ou o seu representante, deverá estar devidamente identificado.

Considera-se de grande relevância a realização da vistoria visto que propicia ao proponente o exame, a conferência e a constatação prévia de todos os detalhes e características técnicas do objeto, para que o mesmo tome conhecimento de tudo àquilo que possa de alguma forma, influir sobre o custo, preparação da proposta e execução do objeto.

A LICITANTE deverá apresentar DECLARAÇÃO DE VISITA TÉCNICA expedida pela Secretaria Municipal da Saúde, cujo documento deverá ser entregue junto com a apresentação da proposta de preços, o pregão.

A licitante que optar pela não realização da Vistoria Técnica deverá entregar juntamente com a documentação da habilitação, DECLARAÇÃO DE DISPENSA DE VISTORIA, de que a mesma não participou da visita técnica disponível no referido processo licitatório, sendo de sua total responsabilidade e conhecimento as condições de realização dos serviços, não recaindo em nenhuma hipótese qualquer responsabilidade sobre o Município ou alegação de desconhecimento das condições existentes para elaboração do orçamento e das planilhas, bem como para a execução do contrato e cumprimento das obrigações assumidas.

As empresas interessadas deverão ter pleno conhecimento dos termos constantes deste Edital e das condições gerais e particulares do objeto da licitação, não podendo invocar qualquer desconhecimento como elemento impeditivo da correta formulação da proposta e do integral cumprimento do contrato.

21. DA PROPOSTA

A proposta deverá ser apresentada conforme Xxxxx XXX deste Termo de Referencia.

Document Metadata

Table of Contents

CONSULTA PÚBLICA DE PREÇOS Nº 057/2024

Document Metadata

CONSULTA PÚBLICA DE PREÇOS Nº 057/2024

Período para apresentação da proposta: de 24/06/2024 a 28/06/2024.

ANEXO I – TERMO DE REFERÊNCIA PROCESSOADMINISTRATIVO Nº 4958/2024

MODALIDADE: Pregão Eletrônico

TIPO DE LICITAÇÃO: Menor valor

FORMA DE CONTRATAÇÃO: Contratação

1. DO OBJETO

MODALIDADE: Pregão

TIPO DE LICITAÇÃO: Menor valor global

FORMA DE CONTRATAÇÃO: contratação

2. DA JUSTIFICATIVA

3. DESCRIÇÃO DA SOLUÇÃO

4. FUNDAMENTAÇÃO E DESCRIÇÃO DA NECESSIDADE DA CONTRATAÇÃO

5. SUSTENTABILIDADE

6. DO CRONOGRAMA DE EXECUÇÃO

7. DO PLANO DE GERENCIAMENTO DO PROJETO

8. DOS REQUISITOS DE GARANTIA E SEGURANÇA DA APLICAÇÃO

9. DA ESTRUTURAÇÃO, MIGRAÇÃO, CONVERSÃO OU ALIMENTAÇÃO INICIAL DE BASES DE DADOS E TABELAS

10. DO SERVIÇO DE HOSPEDAGEM DO SISTEMA EM DATACENTER

Por meio da equipe da CONTRATADA, por profissional especialista, será responsável por gerenciar, instalar, configurar, atualizar e monitorar o SGDB - Sistema Gerenciador De Bancos De Dados, durante a vigência de contrato.

11. DA METODOLOGIA DE IMPLANTAÇÃO DO SISTEMA DE GESTÃO DA SAÚDE

12. DO SERVIÇO DE ATUALIZAÇÃO MENSAL, SUPORTE E MANUTENÇÃO

13. DO SERVIÇO DE DESENVOLVIMENTO DE CUSTOMIZAÇÃO NO SISTEMA

14. DOS SERVIÇOS DE PROJETO ASSISTIDO E CAPACITAÇÃO CONTINUADA

15. DO SIGILO E DA CONFIDENCIALIDADE – APLICAÇÃO DA LEI GERAL DE PROTEÇÃO DE DADOS – LGPD (Nº 13.709/2018)

16. DOS ASPECTOS TECNOLÓGICOS DO SISTEMA DE GESTÃO INFORMATIZADO

17. DAS ESPECIFICAÇÕES MÍNIMAS FUNCIONAIS DO SISTEMA

18. DA SUBCONTRATAÇÃO

19. DA DEMONSTRACÃO TÉCNICA DO SISTEMA

20. DA VISITA TÉCNICA – FACULTATIVA

21. DA PROPOSTA

22. DAS OBRIGAÇÕES DA CONTRATADA

Document Metadata