Consulta Pública

Descrição:

Consulta pública responsável pela apresentação de propostas sobre o sistema de gestão pública a ser contratado.

Contribuições:

Descrição:

A administração pública municipal demanda da contratação de sistema ou conjunto de sistemas para auxiliar atividades inerentes à Gestão Integrada de Atenção à Saúde, para informatizar o registro de atendimento ao usuário do sus (prontuário eletrônico do usuário do sus), ações de apoio à assistência à saúde, atendimento ambulatorial, assistência farmacêutica, regulação do acesso à saúde e controle e avaliação, ações de vigilâncias em saúde, assistência hospitalar, gestão de logística e patrimônio; serviços técnicos especializados (STE) de customização, de integração/interoperabilidade, de parametrização, de implantação, de treinamento, de operação assistida e de suporte técnico e manutenção. - Devido uma instabilidade no sistema no dia 24/01, a audiência que estava marcada para o mesmo dia foi remarcada para dia 01/02. As demais datas não sofreram alteração.

Contribuições:

Descrição:

Consulta Pública prévia à licitação, para a contratação de empresa prestadora de serviços de Tecnologia da Informação para o fornecimento de Sistema Estruturante Municipal (SEM) com a finalidade de suprir a demanda da Prefeitura do Município de Contagem, conforme requisitos funcionais e não funcionais e os módulos indicados no Estudo Técnico Preliminar anexo.

Contribuições:

Descrição:

A administração pública municipal, buscando a transparência e emprego de melhores práticas de mercado, busca abrir a discussão sobre o Projeto de Lei para a implantação e o compartilhamento de infraestrutura de telecomunicações para a implantação do 5G na esfera municipal.

Contribuições:

Descrição:

A Secretaria de Tecnologia da Informação (STI), torna público que realizará Consulta Pública, prévia à Licitação, para contratação de empresa prestadora de serviços de tecnologia da informação para o fornecimento de Sistema de Gestão Integrada de Atenção à Saúde, com a finalidade de suprir a demanda da Prefeitura do Município de Contagem, conforme requisitos funcionais e não funcionais e os módulos indicados no Termo de Referência.

Contribuições:

Descrição:

A Secretaria Municipal de Tecnologia da Informação (STI), torna público que realizará Consulta Pública, prévia à Licitação, para Contratação de serviços técnicos especializados de engenharia cartográfica para geração de produtos/serviços de levantamento aerofotogramétrico, levantamento altimétrico por perfilamento a laser, restituição aerofotogramétrica, ortofoto cartas digitais, cadastramento de imóveis urbanos e atualização de softwares específicos.

Contribuições:

Descrição:

A Secretaria Municipal de Tecnologia da Informação (STI), torna público que realizará Consulta Pública, prévia à Licitação, para Contratação de serviços técnicos especializados de engenharia cartográfica para geração de produtos/serviços de levantamento aerofotogramétrico, levantamento altimétrico por perfilamento a laser, restituição aerofotogramétrica, ortofoto cartas digitais, cadastramento de imóveis urbanos e atualização de softwares específicos.

Contribuições:

1 -

MANIFESTAÇÃO À CONSULTA PÚBLICA

À Secretaria Municipal de Tecnologia da Informação (STI) e Administração Pública do Município de Contagem.

A Helmert Engenharia e Aerolevantamentos, estabelecido à Av. T-63, n. 1206, Edifício Map Center, Salas 205/206 - St. Bueno, Goiânia - GO, CEP: 74230-100, por intermédio de seu representante legal abaixo qualificado, apresenta MANIFESTAÇÃO À CONSULTA PÚBLICA realizada objetivando a contratação do objeto abaixo.

OBJETO

Contratação de serviços técnicos especializados de engenharia cartográfica para geração de produtos/serviços de levantamento aerofotogramétrico, levantamento altimétrico por perfilamento a laser, restituição aerofotogramétrica, ortofoto cartas digitais, cadastramento de imóveis urbanos e atualização de softwares específicos.

JUSTIFICATIVA

Observa-se que Município de Contagem conta com diversas bases de dados que são utilizados frequentemente sem instrumentos modernos que dão mais dinamismo tanto ao servidor público quanto à população em geral que necessita do acesso a tais dados. Com um melhor planejamento, será evitado que a gestão do crescimento do espaço urbano fique tão dispendiosa e marcadas pelo improviso. Enxergamos que o município demanda urgentemente de uma ferramenta mais moderna, que junte todas as bases de dados da Prefeitura, com consequente redução nos custos de execuções dos serviços à população.

SUGETÕES DE ADEQUAÇÃO DO TERMO DE REFERÊNCIA

(SOBRE A NECESSIDADE DE PERFILAMENTO A LASER) - Quanto a obtenção de dados altimétricos do terreno por meio da tecnologia de perfilamento a LASER aerotransportado, entendemos que tal aquisição é dispensável já que o Município já detém deste produto adquirido em contratações anteriores e, a não ser que tenha havido uma mudança drástica na topografia de solo, o novo dado adquirido seria exatamente igual ao obtido anteriormente. Ocorre também que a extração das curvas de nível, podem ser obtidas através do MDT, a partir da interpolação dos dados coletados pois, após a aerotriangulação é gerado uma nuvem de pontos cobrindo toda superfície da área mapeada (MDS), e serão restituídas linhas de quebra onde houver mudanças abruptas do relevo e essas mesmas linhas podem ser utilizadas para interpolar uma nuvem de pontos para obtenção do MDT.

(SOBRE A MODALIDADE DA LICITAÇÃO) - Entendemos que para que a licitação tenha maior alcance entre as empresas de geoprocessamento e aerolevantamento, seria ideal que esta fosse realizada via PREGÃO, dando ar aos PRINCÍPIOS DA LEGALIDADE, IGUALDADE e da ISONOMIA. A mudança de modalidade serviria para que a administração pública conseguisse alcançar ao processo licitatório o melhor contrato através da promoção e ampliação do acesso das empresas aptas do setor.

(SOBRE A IMPLANTAÇÃO DE UM SISTEMA DE INFORMAÇÕES GEOGRÁFICAS MAIS SEGURO E MODERNO) - E Após fazermos leitura do termo de referência, é possível notar que o Município não dispõe de um sistema de informações geográficas integrado por um banco de dados entre as secretarias, contando apenas com uma base em formato digital e estático, acessada por um visualizador simples do ArcGIS que não tem inteligência de comunicação e integração implementada, atuando totalmente em desacordo com a atual Lei Geral de Proteção de Dados Pessoais (LGPD) e sujeitando o Município à multas que podem chegar à 50 milhões de reais. É inegável que estamos frente a uma ótima oportunidade para que o Município de Contagem consiga além da atualização de sua base cartográfica, implantar um sistema mais moderno e seguro gerando mais possibilidades à população e aos servidores da Prefeitura.

Com uma base centralizada e ocorrendo a devida comunicação, diversas informações poderão ser cruzadas com segurança de acesso gerando novos produtos como gráficos inteligentes, tabelas interativas, controle de processos das secretárias e principalmente a possibilidade de integração com o sistema de gestão atualmente implantado na Prefeitura o (GOVBR).

Um outro fator importante no SIGWEB almejado, deve ser a integração de dados das diversas secretarias pois com isso, uma série de recursos chamados no âmbito municipal de recursos públicos (como creches, escolas, postos de saúde, infraestrutura, segurança etc.), poderão ser mais bem alocados gerando economia de tempo, e de pessoal técnico.

Goiânia para Contagem, 12 de janeiro de 2023

SANTIAGO SILVA ROCHA – SÓCIO ADMINSITRATIVO

CPF 920.753.801-63

Autor: Helmert Engenharia e Aerolevantamentos

#	Arquivo
2	Manifesto Helmert

Descrição:

A Secretaria Municipal de Tecnologia da Informação (STI), torna público que realizará Consulta Pública, prévia à Licitação, para Contratação de serviços técnicos especializados de engenharia cartográfica para geração de produtos/serviços de levantamento aerofotogramétrico, levantamento altimétrico por perfilamento a laser, restituição aerofotogramétrica, ortofoto cartas digitais, cadastramento de imóveis urbanos e atualização de softwares específicos. Fica aberta a consulta público para minifestações para possiveis adequações, caso pertinentes.

Contribuições:

Descrição:

A Secretaria Municipal de Tecnologia da Informação (STI), torna público que realizará Consulta Pública, prévia à Licitação, para contratação de empresa especializada na cessão de direito de uso, por prazo determinado, com a respectiva documentação, de solução informatizada para padronização e integração da Rede Municipal de Educação de Contagem e a prestação de serviços de: implantação, customização, configuração, migração de dados, capacitação, manutenção, suporte técnico e hospedagem. Fica aberta a consulta público para minifestações para possiveis adequações, caso pertinentes.

Contribuições:

Descrição:

A Secretaria Municipal de Tecnologia da Informação (STI), torna público que realizará Consulta Pública, prévia à Licitação, para Registro de Preços, para contratação de empresa especializada na prestação de Serviços de links de Comunicação de Dados Simétricos filtro de conteúdo e funcionalidades SD-WAN, Serviços de Acesso à Internet dedicado com IPs fixos e Banda Larga, objetivando a interligação das redes locais de computadores das unidades da Prefeitura Municipal de Contagem com infraestrutura Datacenter Municipal, contemplando, de forma contínua, suporte à infraestrutura corporativa de comunicação de dados, voz e vídeo, com solução de segurança da informação, incluindo os serviços de operação, gerenciamento, manutenção e suporte técnico, conforme especificações constantes no Termo de Referência

Contribuições:

2 -

Questionamento 1:

Conforme mencionado em Audiência Pública, por inúmeros participantes, fica complicado o ganhador do lote 1 ter a responsabilidade por gerenciar e administrar o lote 2, uma vez que são necessárias algumas informações de acesso a rede do concorrente.

A ideia de separar lote 1 e 2, e criar um 3° lote com a solução de SD-WAN + Firewall + Gerenciamento, evitaria esse tipo de conflito, o que tornaria o gerenciamento mais transparente. Ressaltando que o ganhador do lote 1 não pode ganhar o lote 2 ou lote 3 e vice versa.

Questionamento 2:

ITENS 1, 2, 3, 4, 5 e 6;

Solicitamos a revisão dos throughputs solicitados na descrição dos appliances, pois os valores apresentados estão em divergência com os links a serem contratados para a utilização, fazendo assim com que o órgão disponibilize recursos financeiros além do necessário para cada localidade.

Além disso “todos” os throughput solicitados estão alinhados com um fabricante de firewall em específico, o que exclui qualquer tipo de competitividade no certame.

Compreendemos que o órgão pretende manter a disputa de valores aberta e com o maior número possível de participantes.

Questionamento 3:

2.6.4. O gerenciamento da solução deve suportar acesso via SSH, cliente ou WEB (HTTPS) e API aberta;

O fato da não oferta de uma API aberta na solução de Firewall/IPS não limita tecnicamente a qualidade de proteção ou do sistema de gerenciamento do produto.

Outro ponto importante é que o gerenciamento será feito por um “terceiro” no qual esse “terceiro” não necessita de uma API aberta para gerenciar a solução.

Compreendemos que o órgão pretende manter a disputa de valores aberta e com o maior número possível de participantes, por isso, o item de API aberta não será obrigatório.

Sugerimos o seguinte texto: O gerenciamento da solução deve suportar acesso via SSH, cliente ou WEB (HTTPS) ou API aberta;

Questionamento 4:

2.6.13. Deve suportar ao menos 30 tabelas independentes de roteamento, por contexto de firewall;

Entendemos que o projeto envolve 1 (um) equipamento por localidade, não fazendo assim a necessidade de tabelas independentes de roteamento. Todas as localidades poderão ser gerenciadas centralmente de um único local, facilitando a gestão do projeto.

Sugerimos a remoção do item

Questionamento 5:

2.6.27. Deve haver suporte ao protocolo ICAP, inclusive de forma segura (SSL);

Qual a necessidade de uso do protocolo ICAP? Possuem servidores web?

Questionamento 6:

2.6.33. A solução deve suportar integração nativa com Let’s Encrypt, para obtenção de certificados válidos, de forma automática;

A solução permite a importação de qualquer certificado ou autoridade certificadora válida de modo manual. Garantindo assim um melhor controle dos acessos e segurança das informações com utilização de certificados.

Sugerimos o seguinte texto: A solução deve suportar integração nativa com Let’s Encrypt, para obtenção de certificados válidos, de forma manual ou automática;

Questionamento 7:

2.6.36. A solução de firewall deve permitir integração com threat feeds externos.

A solução que comercializamos, possui um laboratório especializado em vulnerabilidades, threats gerando diariamente novas assinaturas para melhorar a segurança. Também possuímos bases externas internacionais, provendo uma maior varredura no transporte das informações. Essas assinaturas são disponibilizadas atualizações automáticas diariamente.

Entendemos que se a solução possuir uma base de assinaturas internas e externas, sendo atualizadas diariamente o item se dará por atendido.

Está correto nosso entendimento?

Questionamento 8:

2.6.37. Deve possuir recursos de automação, com a finalidade de facilitar a operação diária dos firewalls. Suportar, pelo menos, a tomada de ações como execução de scripts, envio de e-mails, notificações via Teams e APIs mediante hosts comprometidos, agendamentos, mudanças de configuração e ocorrência de eventos de rede e segurança pré-definidos;

A solução que representamos é focada em segurança, criasse um risco no ambiente de rede, onde um atacante pode se beneficiar deste recurso e iniciar um ataque no NGFW ao executar uma automação desconhecida que pode liberar um tráfego malicioso.

Sugerimos a remoção do item.

Questionamento 9:

2.6.38. Para agilizar a gerência remota do firewall, deve ser possível carregar conteúdo estático dela a partir de objetos em cache em CDNs;

A solução que representamos, possui armazenamento em cache do tráfego acessado, podendo este ser armazenado em disco, especificando o tamanho do armazenamento do cache.

Gostaríamos de esclarecimentos em relação ao uso de objeto em cache em CDNs.

Questionamento 10:

2.8.14. Permitir nativamente a criação de assinaturas personalizadas para reconhecimento de aplicações proprietárias na própria interface gráfica da solução, sem a necessidade de ação do fabricante;

O produto que representamos possui mais de 4.000 assinaturas em sua base de conhecimento e diariamente são disponibilizadas novas aplicações reconhecidas. Já cobrimos praticamente todas as aplicações possíveis que poderiam ser acessadas pelos usuários das empresas.

O nosso processo de customização é executado pelo próprio fabricante. Entendemos que se caso o controle de IPS baseado em assinaturas, suportar a criação de aplicações proprietária, o item se dará por atendido.

Autor: Leonardo J. Winter

#	Arquivo
3	Questionamentos
4	Questionamentos e sugestões
5	Sugestões e Questionamentos

3 -

Questionamento 11:

2.8.21. Deve ser possível a criação de grupos dinâmicos de aplicações baseados em características das aplicações como: tecnologia utilizada nas aplicações (Client-Server, Browse Based, Network Protocol, etc);

2.8.22. Deve ser possível a criação de grupos dinâmicos de aplicações baseados em características das aplicações como: nível de risco da aplicação, tecnologia, vendor e popularidade;

Entendemos que grupos estáticos de aplicações, mais assinaturas de IPS por risco atende integralmente a necessidade para a efetiva proteção do ambiente. A solicitação de controle de grupos dinâmicos de aplicações baseados em nível de risco e todo o texto referente a este é perfeitamente dispensável. Para o órgão público é importante permitir o máximo possível de participantes com o objetivo de existir uma disputa de preço para maior economia do ente público. Se manter esses itens acima a concorrência ficará bem limitada e por um item dispensável.

Está correto nosso entendimento?

Questionamento 12:

2.8.24. Deve permitir forçar o uso de portas específicas para determinadas aplicações;

A solução que representamos possui mais de 4.000 assinaturas em sua base de conhecimento e diariamente são disponibilizadas novas aplicações reconhecidas. Já cobrimos praticamente todas as aplicações possíveis que poderiam ser acessadas pelos usuários das empresas. O nosso processo de customização é executado pelo próprio fabricante.

Essa exigência limita o número de interessados em participar do pregão. Entendemos que o órgão se pauta nos princípios da transparência e economicidade e é interesse a ampla concorrência.

Sugerimos a remoção do item

Questionamento 13:

2.11.1. Deve incluir a capacidade de criação de políticas baseadas na visibilidade e controle de quem está utilizando quais aplicações através da integração com serviços de diretório, autenticação via LDAP, Active Directory, E-directory e base de dados local;

O item traz a exigência de que a solução deva possuir integração a diversos métodos de autenticação. O produto que representamos permite integração com LDAP, Active Directory, RADIUS, TACACS+ e base local. Entendemos que o E-directory é um produto desenvolvido pela empresa netiq. A utilização é muito restrita e não é encontrado no facilmente sua instalação nos clientes privado e governo.

https://www.netiq.com/documentation/edirectory-92/

Sugerimos a remoção do recurso E-directory

Questionamento 14:

2.11.10. Deve suportar SAML como método para autenticação na navegação de Internet e para VPN;

Possuímos autenticação via servidores remotos tais como AD, LDAP, TACACS + e RADIUS, também baseado em usuários locais. Entendemos que tais recursos suprem a necessidade de uso de SAML.

Essa exigência limita o número de interessados em participar do pregão. Entendemos que o órgão se pauta nos princípios da transparência e economicidade e é interesse a ampla concorrência.

Sugerimos a remoção do item

Questionamento 15:

2.12.4. Permitir identificar e opcionalmente prevenir a transferência de informações sensíveis, incluindo, mas não limitado a número de cartão de crédito, possibilitando a criação de novos tipos de dados via expressão regular.

Em relação ao item acima, a descrição é de uma solução de DLP. Existe no mercado produtos específicos para essa função e que solicitar tal funcionalidade irá apenas exigir do NGFW recursos que podem causar indisponibilidade no ambiente.

Sugerimos a remoção do Item

Questionamento 16:

2.14.6. Atribuição de DNS nos clientes remotos de VPN, inclusive com DNS split tunnel;

A solução que representamos, possui atribuição de DNS nos clientes de VPN forma de nativa. Faz se necessário o uso de DNS split tunnel?

Questionamento 17:

2.14.12. A VPN SSL deve permitir a customização da tela em sessões RDP;

Qual a necessidade da customização da tela em sessões RDP, tendo em vista que este tipo de acesso já criptografado, é a exibição de uma sessão em um host ou servidor (Ex: Windows AD), onde o mesmo não pode ser customizado.

Sugerimos a remoção do item.

Questionamento 18:

2.15.6. A solução deverá ser capaz de monitorar e identificar falhas mediante a associação de health check, permitindo testes de resposta por ping, http, tcp/udp echo, dns, tcp-connect e twamp;

O recurso executado para identificar falhas na disponibilidade do link utiliza um alvo de monitoramento e alguma tecnologia de conectividade. Caso a solução não tenha sucesso na resposta, o link é marcado como inativo e o SD-WAN não utiliza esta WAN para escoamento do tráfego. Os tipos de monitoramento que estão presentes em 100% dos produtos de SD-WAN são o ping e TCP-connect.

Incluir muitas opções apenas dificulta a ampla participação de interessados em participar do pregão.

Questionamento 19:

2.15.10. Deve possuir suporte ao MOS (Mean Opinion Score), para calcular a qualidade de chamadas de voz, considerando jitter, perda de pacote e codec utilizado;

A solução que representamos possui todo o monitoramento de links baseado em sua performance, tais como jitter, latência, perda de pacotes e utilização de banda. Entendemos que se a solução possuir a escolha do melhor link na utilização de aplicações tais como VOIP. O item se dará por atendido.

Sugerimos a remoção do item.

Autor: Leonardo J. Winter

#	Arquivo

4 -

Questionamento 20:

2.15.13. Deve permitir a segmentação de várias VRFs sobre um único túnel SD-WAN;

Entendemos que o projeto envolve 1 (um) equipamento por localidade, não fazendo assim a necessidade de uso de VRF. Todas as localidades poderão ser gerenciadas centralmente de um único local, facilitando a gestão do projeto.

Questionamento 21:

2.15.55. Deve possuir suporte e estar licenciamento para uso de VRFs, em IPv4 e IPv6;

Entendemos que o projeto envolve 1 (um) equipamento por localidade, não fazendo assim a necessidade de de uso de VRF. Todas as localidades poderão ser gerenciadas centralmente de um único local, facilitando a gestão do projeto.

Questionamento 22:

3.2.12. O hardware instalado em qualquer localidade deverá suportar a carga de usuários e links, com até 75% dos seus recursos (CPU e memória);

3.2.12.1. Caso estes valores estejam entre 75% e 90%, haverá um prazo de 60 (sessenta) dias para atualização/troca, sem ônus para a CONTRATANTE, visando restabelecer o limite de 75%;

Para um melhor diagnostico durante o uso do equipamento, pois o mesmo poderá atingir um uso de recurso acima de 75% durante um processo de atualização dos hosts da rede (Ex: Windows Update) ou através de um tentativa de ataque ( onde a solução necessitará de recursos para proteger o órgão), faz-se necessário estipular um período de tempo em que os recursos poderão estar acima do limite, sem obrigatoriedade da troca do equipamento. Ex: permanecer com valores acima por um período de 30 minutos.

Sugerimos o seguinte texto:

Caso estes valores permaneçam entre 75% e 90% dentre um período maior de que 30 minutos, haverá um prazo de 60 (sessenta) dias para atualização/troca, sem ônus para a CONTRATANTE, visando restabelecer o limite de 75%;

Questionamento 23:

3.6.21. Possuir "wizard" na solução de gerência para adicionar os dispositivos via interface gráfica utilizando IP, login e senha dos mesmos;

3.6.38. Deve conter um assistente gráfico para adicionar novos dispositivos, usando seu endereço IP, usuário e senha;

3.7.13. Possuir "wizard" na solução de gerência para adicionar os dispositivos via interface gráfica utilizando IP, login e senha;

A solução que representamos possui uma interface muito simples e amigável no qual não se faz necessário o uso de wizard ou assistente gráfico e não é necessário inserir endereço IP.

Na solução a adição de dispositivos se dá pelo número de série, tornando mais seguro o vínculo, pois mesmo o IP sendo alterado o dispositivo UTM manterá seu vínculo.

A simplificação do processo de adicionar dispositivos facilita a manutenção da solução.

Sugerimos os seguintes textos:

3.6.21. Possuir "wizard" na solução de gerência para adicionar os dispositivos via interface gráfica utilizando IP ou número de série, login e senha dos mesmos;

3.6.38. Deve conter um assistente gráfico para adicionar novos dispositivos, usando seu endereço utilizando IP ou número de série, usuário e senha;

3.7.13. Possuir "wizard" na solução de gerência para adicionar os dispositivos via interface gráfica utilizando IP ou número de série, login e senha;

Questionamento 24:

3.6.22. Permitir que eventuais políticas e objetos já presentes nos dispositivos sejam importados quando o mesmo for adicionado à solução de gerência;

Este item traz certa ambiguidade de possibilidades, de um lado facilita importar os objetos e políticas, mas do outro lado irá importar objetos não utilizados, deixando a lista de objetos com itens em demasia e poderá importar políticas que não são utilizadas.

Sugerimos a remoção do item

Questionamento 25:

3.6.26. Permitir criar scripts personalizados, que sejam executados de forma centralizada em um ou mais dispositivos gerenciados com comandos de CLI dos mesmos;

3.6.27. Possuir histórico dos scripts executados nos dispositivos gerenciados pela solução de gerência;

Suportar a execução de scripts, criasse um risco no ambiente de rede. Um atacante pode se beneficiar deste recurso e iniciar um ataque no NGFW ao executar um script que pode liberar um tráfego malicioso.

Entendemos que o órgão se pauta nos princípios da transparência e economicidade e é interesse a ampla concorrência.

Sugerimos a remoção dos itens acima citado

Questionamento 25:

3.6.30. Deve permitir criar regras de NAT64 e NAT46 de forma centralizada;

A solução que representamos, tais configurações são feitas diretamente nas soluções de segurança gerenciadas. Entendemos que devido a necessidade específica de cada unidade faz-se necessário a configuração local. Estas unidades de segurança podem ser acessadas diretamente da solução de gerenciamento centralizado.

Sugerimos o seguinte texto:

Deve permitir criar regras de NAT64 e NAT46 de forma centralizada ou local, desde que as unidades de segurança possam ser acessadas diretamente através da solução de gerenciamento centralizado.

Questionamento 26:

3.6.34. Deve permitir a correlação de eventos, provendo dashboards diversos, bem como possibilitar a criação de novas telas para visualizar os recursos de rede e segurança;

Compreendemos que se o produto possuir um dashboard fixo que contenha todas as informações essenciais para a coleta e visualização, ou seja, não customizável. Possuímos diversos painéis especializado, por exemplo, um painel para controle WEB outro para IPS e muitos outros baseados na análise do acesso do usuário final.

Essa exigência limita o número de interessados em participar do pregão. Entendemos que o órgão se pauta nos princípios da transparência e economicidade e é interesse a ampla concorrência.

Sugerimos a remoção do item

Questionamento 27:

3.6.41. Suporte a geração de relatórios de tráfego em tempo real, no formato de gráfico de bolhas;

A solução que representamos possui diversos relatórios em tempo real, que contenham todas as informações essenciais para análise do acesso do usuário final.

Entendemos que, se a solução possuir a capacidade de exportar os logs no formato CSV, no qual, o cliente poderá importar a informação em uma ferramenta que irá permitir que seja gerado diversos gráficos, como por exemplo, barra, linha, tabela, bolha e pizza, o item será considerado como atendido

Essa exigência limita o número de interessados em participar do pregão. Entendemos que o órgão se pauta nos princípios da transparência e economicidade e é interesse a ampla concorrência.

Sugerimos o seguinte texto:

Suporte a geração de relatórios de tráfego em tempo real;

Questionamento 28:

3.6.46. Deve ter a capacidade de criar relatórios no formato HTML, CSV, XML e PDF;

3.7.16. Deve ter a capacidade de criar relatórios no formato PDF e XML;

A solução que representamos tem a capacidade de criar relatórios no formato HTML, PDF e CSV, através destas opções é possível realizar a análise necessária, entendemos que a exportação no formato XML, não será obrigatória.

Entendemos que o órgão se pauta nos princípios da transparência e economicidade e é interesse a ampla concorrência.

Sugerimos os seguintes textos:

Deve ter a capacidade de criar relatórios no formato HTML, CSV, PDF ou XML ;

Deve ter a capacidade de criar relatórios no formato PDF ou XML;

Questionamento 28:

3.6.49. Os logs gerados pelos dispositivos gerenciados devem ser centralizados nos servidores da plataforma, mas a solução também deve oferecer a possibilidade de usar um servidor Syslog externo ou similar;

Visando o tamanho do projeto que hoje consta com mais de 300 caixas, observando também a LGPD que visa o armazenamento de logs por um período, faz-se necessário a especificação da quantidade de logs que o servidor de gerenciamento de logs deverá suportar, além da capacidade de armazenamento dia. (Ex: Quantidade de logs a serem armazenados 20tb, 30tb, quantidade de logs suportados por dia, 300Gb, 400GB).

Sugerimos o seguinte texto:

A contratada deve entregar uma loção de armazenamento de log, seja físico ou virtual, nas dependências do cliente, com capacidade de receber pelo menos 500GB dia de log de todos os ativos, além de ter a capacidade de armazenar no mínimo 50tb de logs, mas a solução também deve oferecer a possibilidade de usar um servidor Syslog externo ou similar;

Questionamento 29:

3.6.55. Deve ter a capacidade de personalizar gráficos em relatórios, como barras, linhas e tabelas;

Entendemos que, se a solução possuir a capacidade de exportar os logs no formato CSV, no qual, o cliente poderá importar a informação em uma ferramenta que irá permitir que seja gerado diversos gráficos, como por exemplo, barra, linha, tabela e pizza, o item será considerado como atendido.

Para o órgão público é importante permitir o máximo possível de participantes com o objetivo de existir uma disputa de preço para maior economia do ente público. Se manter esse item a concorrência ficará bem limitada e por um item dispensável.

Sugerimos a remoção do item.

Questionamento 30:

3.6.59. Permitir a personalização de qualquer relatório pré-estabelecido pela solução, exclusivamente pelo Administrador, para adotá-lo de acordo com suas necessidades;

Entendemos que, se a solução possuir a capacidade de exportar os logs no formato CSV, no qual, o cliente poderá importar a informação em uma ferramenta que irá permitir que seja gerado diversos gráficos, como por exemplo, barra, linha, tabela e pizza, o item será considerado como atendido.

Para o órgão público é importante permitir o máximo possível de participantes com o objetivo de existir uma disputa de preço para maior economia do ente público. Se manter esse item a concorrência ficará bem limitada e por um item dispensável.

Sugerimos a remoção do item.

Autor: Leonardo J. Winter

#	Arquivo

5 -

Questionamento 31:

3.6.61. Deve permitir que o relatório seja enviado por email para o destinatário específico;

A solução possui o envio de relatório ao administrador que gerencia determinados firewalls, fazendo assim um melhor controle na divulgação das informações de segurança da corporação.

Sugerimos o seguinte texto:

Deve permitir que o relatório seja enviado por email;

Questionamento 32:

3.6.65. Deve permitir definir o design dos relatórios, incluir gráficos, adicionar texto e imagens, alinhamento, quebras de página, fontes, cores, entre outros;

Entendemos que, se a solução possuir a capacidade de exportar os logs no formato CSV, no qual, o cliente poderá importar a informação em uma ferramenta que irá permitir que seja gerado diversos gráficos, como por exemplo, barra, linha, tabela e pizza, o item será considerado como atendido.

Para o órgão público é importante permitir o máximo possível de participantes com o objetivo de existir uma disputa de preço para maior economia do ente público. Se manter esse item a concorrência ficará bem limitada e por um item dispensável.

Sugerimos a remoção do item.

Questionamento 33:

3.6.70. Possibilidade de exibir nos relatórios da GUI as informações do sistema, como licenças, memória, disco rígido, uso da CPU, taxa de log por segundo recebido, total de logs diários recebidos, alertas do sistema, entre outros;

Todas as informações solicitadas no item, é possível realizar a coleta através de monitoramento SNMP, exibindo assim de forma regular e atualizada a informação.

Sugerimos o seguinte texto

Possibilidade de exibir nos relatórios da GUI ou através de traps de SNMP as informações do sistema, como licenças, memória, disco rígido, uso da CPU, taxa de log por segundo recebido, total de logs diários recebidos, alertas do sistema, entre outros;

Questionamento 34:

3.6.71. Deve fornecer as informações da quantidade de logs armazenados e as estatísticas do tempo restante armazenado;

Essa exigência limita o número de interessados em participar do pregão. Entendemos que o órgão se pauta nos princípios da transparência e economicidade e é interesse a ampla concorrência.

Sugerimos a remoção do item

Questionamento 35:

3.6.72. Deve permitir aplicar políticas para o uso de senhas para administradores de plataforma, como tamanho mínimo e caracteres permitidos;

Essa exigência limita o número de interessados em participar do pregão. Entendemos que o órgão se pauta nos princípios da transparência e economicidade e é interesse a ampla concorrência.

Sugerimos a remoção do item

Questionamento 36:

3.7.22. Deve permitir a alteração do formato dos relatórios: fontes, cores, imagens, gráficos, tabelas e o idioma;

Entendemos que, se a solução possuir a capacidade de exportar os logs no formato CSV, no qual, o cliente poderá importar a informação em uma ferramenta que irá permitir que seja gerado diversos gráficos, como por exemplo, barra, linha, tabela e pizza, o item será considerado como atendido.

Essa exigência limita o número de interessados em participar do pregão. Entendemos que o órgão se pauta nos princípios da transparência e economicidade e é interesse a ampla concorrência.

Sugerimos a remoção do item

Questionamento 37:

Na tabela que contem a descrição do item, com as quantidades, valores unitários, valores mensais, etc, existe um valor de performance para cada CPE:

“Link de Conectividade Simétrico de 30Mbps com CPE, CPE SDWAN Tipo 1 para locais até 50 usuários, mínimo de 700 Mbps de capacidade de firewall e 400 Mbps de Threat Protections de serviços de segurança e Gerência de Redes”

Ocorre que na descrição do CPE Tipo 1, página 34 do arquivo “Termo de Referência”, os valores estão completamente diferentes.

Qual valor devemos considerar?

Por fim gostaríamos de uma extensão de prazo de mais 5 dias para mitigarmos mais algumas informações a respeito do processo.

Autor: Leonardo J. Winter

#	Arquivo

6 -

Item 1 - Termo de referência SD-WAN:
Após análise do documento, compreendemos que a solução em questão está voltada para um fabricante específico, no caso, Fortinet. Contudo, levando em consideração a premissa da Prefeitura de Contagem de conduzir concorrências de maneira imparcial, sugerimos que sejam aceitas propostas que ampliem o leque de fabricantes elegíveis, de forma a manter a imparcialidade dos parâmetros estabelecidos para a solução de segurança e SD-WAN proposta inicialmente.

Item 2 - Sobre o desmembro dos links e SD-WAN:
Analisando esta parte do processo, o projeto em si beneficia apenas as operadoras de links, pois é exigido a entrega da solução de SD-WAN em conjunto com os links, deixando de fora outros players com condições competitivas técnicas e comerciais para a entrega do projeto de SD-WAN. Entendemos que desmembrar esse item em um terceiro lote abriria um cenário com mais competitividade, melhorando ainda mais a concorrência, o que por consequência impacta no valor final da solução, possivelmente a deixando mais barata e melhor qualificada, o que é um bem para administração pública, possibilitando outras empresas de tecnologia focadas na solução entregar este item de forma isolada dos links. Outro fato a ser considerado para a criação de um terceiro lote, apenas para SD-WAN, é o tempo de entrega da solução ser diferente dos links, onde o links podem ser implementados em 60 dias (até mesmo em menor tempo para algumas localidades) já o SD-WAN como exige a importação (e/ou fabricação) de hardware o prazo estimado seria de 90 dias. Mais um benefício da criação de um terceiro, é que a administração do SD-WAN ficará independente dos contratos do lote de link principal e do lote de link de backup, o que também é um benefício para esta Administração já que acreditamos que seguirá a ideia inicial do certame, de manter CONTRATADAS diferentes em todas as soluções, melhorando o trabalho/gestão da Administração Pública com o SLA direcionado para cada lote. Sendo assim, solicitamos sua avaliação quanto à possibilidade de alteração deste edital com a criação do terceiro lote.

Item 3 - Sobre o fabricante de SD-WAN v2:
Havendo a possibilidade de abrir um terceiro lote para entrega da solução de SD-WAN, seria interessante seguir com um equipamento compatível ao que já existe no Data Center, medida esta que visa economizar no ponto de vista da administração pública, não sobrepondo equipamento que porventura possa ter essa função. Seguindo essa lógica, podemos considerar como parte do projeto a utilização do equipamento que existe no Data Center, englobando-o na arquitetura de SD-WAN, onde a vencedora deverá assumir o suporte e renovação de licenças, inclusive cobrindo o período sem suporte e licenças futuras dos equipamentos do Data Center, caso estes itens tenham período de duração menor que o prazo de suporte/licença do presente certame. Faz sentido para a presente Administração deste certame essa sugestão, com esses critérios? 

Autor: Servix Informática Ltda.

#	Arquivo

Descrição:

A Secretaria Municipal de Tecnologia da Informação (STI), torna público que realizará Consulta Pública, prévia à Licitação, para Registro de Preços, para contratação de solução tecnológica de gestão integrada de atenção à saúde denominada de SOLUÇÃO INTEGRADA DE GESTÃO À SAÚDE DE CONTAGEM (SIGESC), compondo os módulos de Gestão Ambulatorial, Gestão Farmacêutica, Gestão de Vigilância em Saúde, Gestão de Regulação e Controle e Avaliação, Urgência e Emergência, Gestão de Logística e Patrimônio e Controle de Almoxarifado, sob a forma de licenciamento Software as a Service (SAAS), por tempo determinado, incluindo fornecimento de licenças sem limite de usuários, migração de dados, implantação, customização, treinamento e suporte técnico, nos termos, prazos e especificações contidas neste termo de referência e de acordo com a lei vigente 8.666/90.

Contribuições:

7 -

3. ESPECÍFICAÇÃO DOS SERVIÇOS
3.1 Contratação de solução tecnológica de gestão integrada de atenção à saúde, denominada neste edital como SOLUÇÃO INTEGRADA DE GESTÃO À SAÚDE DE CONTAGEM (SIGESC), para informatizar o registro de atendimento ao usuário do SUS-Contagem (Prontuário Eletrônico do Usuário do SUS), ações de apoio nos seguintes módulos

3.1.1 CADASTRO DE USUÁRIOS E DOMICÍLIOS

3.1.2 CADASTRO DOS ESTABELECIMENTOS DE SAÚDE

3.1.3 CADASTRO DOS PROFISSIONAIS DE SAÚDE

3.1.4 ORDEM DO DIA

3.1.5 ATENDIMENTO/PRONTUÁRIO DO CIDADÃO

3.1.6 ATENÇÃO PRIMÁRIA E ATENÇÃO DOMICILIAR – INTEGRAÇÃO COM SISTEMA eSUS

3.1.7 PROGRAMAS DE SAÚDE

3.1.8 URGÊNCIA/EMERGÊNCIA

3.1.9 PRESCRIÇÃO ELETRÔNICA

3.1.10 SERVIÇOS HOSPITALARES

3.1.11 MATERIAL ESTERILIZADO

3.1.12 CENTRO CIRÚRGICO

3.1.13 HOTELARIA / CCIH

3.1.14 CENTRO DE MATERIAL ESTERILIZADO

3.1.15 NUTRIÇÃO E DIETÉTICA

3.1.16 VACINA

3.1.17 VIGILÂNCIA EPIDEMIOLÓGICA

3.1.18 VIGILÂNCIA SANITÁRIA

3.1.19 VIGILÂNCIA AMBIENTAL - CONTROLE DE ENDEMIAS

3.1.20 FATURAMENTO AMBULATORIAL E HOSPITALAR

3.1.21 REGULAÇÃO

3.1.22 CONTROLE E AVALIAÇÃO

3.1.23 LABORATÓRIO

3.1.24 SOROTECA

3.1.25 TRATAMENTO FORA DO DOMICÍLIO

3.1.26 GESTÃO DE FROTA DE VEÍCULOS

3.1.27 GESTÃO DE MATERIAIS E MEDICAMENTOS – ALMOXARIFADO E FARMÁCIA

3.1.28 APLICATIVO PARA AGENTES COMUNITÁRIOS DE SAÚDE

3.1.29 APLICATIVO PARA AGENTES DE ENDEMIAS

3.1.30 APLICATIVO MOBILE PARA CIDADÃO

3.1.31 PORTAL DO CIDADÃO/PORTAL DA TRANSPARÊNCIA

3.1.32 PAINEL ELETRÔNICO DE CHAMADA

3.1.33 TELEATENDIMENTO

3.1.34 INTELIGÊNCIA DE NEGÓCIOS (BI)

3.2 Sob a contratação de a) Implantação da solução; b) Customização; c) Suporte técnico; d) Manutenção; e)Treinamento, no âmbito das Unidades de Saúde da Rede Própria do SUS/ Contagem, conforme descrição detalhada neste instrumento e seus anexos.

Autor: VIVVER SISTEMAS LTDA

#	Arquivo
1	Requisitos

8 -

3.7 SUPORTE TÉCNICO

3.7.1 Representa a atividade de apoio operacional para esclarecimento de dúvidas dos usuários do sistema, realização de diagnóstico de ocorrências de mau funcionamento, atendimento aos usuários, monitoramento de funcionamento do sistema e da base de dados, ações preventivas que garantam o adequado funcionamento do sistema e da base de dados, demais ações que não incorrem na Manutenção Corretiva.

3.7.2 Em caso de problemas no acesso ao sistema, relacionados ao servidor, o suporte deverá ser prestado em escala 24x7, tendo em vista a existência de unidades de saúde no âmbito do município de Contagem, que trabalham na escala proposta.

3.7.3 A Contratada deverá manter equipe de atendimento central, disponível em horário comercial, de 08:00 às 18:00, de segunda a sexta, para auxílio aos funcionários da Contratante para sanar eventuais dúvidas na operação da solução.

3.7.4 A equipe técnica apresentada pela empresa deverá conter no mínimo os seguintes profissionais:

• Suporte Técnico: A Contratada deverá manter equipe com 4 (quatro) profissionais nas dependências da contratante em horário comercial, de 08:00 às 18:00, de segunda a sexta, para auxílio aos funcionários da Contratante para sanar eventuais dúvidas na operação da solução.

• 1 (um) Gerente de Projeto com nível superior completo e com experiência em serviços de Implantação, Treinamento e Disponibilização por licença de uso de Sistema Integrado de Gestão da Saúde em ambiente WEB contendo no mínimo os módulos constantes neste termo de referência.

A comprovação deste requisito deverá ser da seguinte forma:

• Apresentação de atestados de capacidade técnica fornecidos por pessoas jurídicas de direito público ou privado que comprovem a atuação de profissional com nível superior completo como Gerente de Projeto em serviços de Implantação, Treinamento e Disponibilização por licença de uso de Sistema Integrado de Gestão da Saúde em ambiente WEB contendo no mínimo os módulos constantes neste termo de referência.

• Apresentação de atestados de capacidade técnica fornecidos por pessoas jurídicas de direito público ou privado que comprovem a atuação de profissional nível superior completo com experiência em serviços de Análise e Modelagem de Processos.

• A formação acadêmica do Gerente de Projeto e do Profissional com experiência em serviços de Análise e Modelagem de Processos deverá ser comprovada através de cópia autenticada do diploma ou certificado reconhecido no órgão competente.

• O vínculo do Gerente de Projeto e do Profissional com experiência em serviços de Análise e Modelagem de Processos com a licitante, deverá ser comprovado através de cópia autenticada ou apresentação dos originais para autenticação de: Carteira de Trabalho/CTPS, no caso de funcionário do quadro permanente; Contrato Social, Estatuto Social ou Ato Constitutivo, no caso de sócio; Contrato de Prestação de Serviço, para contratados por tempo determinado, com data de assinatura anterior a data de abertura das propostas com firma reconhecida das partes e devidamente registrado em cartório.

• A comprovação de vínculo do Gerente de Projeto e do Profissional com experiência em serviços de Análise e Modelagem de Processos com a licitante poderá ser substituída por uma declaração firmada se comprometendo a executar os serviços licitados, quando o vínculo deverá ser efetivado, como condicionante par aassinatura do contrato administrativo decorrente do presente certame licitatório.

3.8 VISITA TÉCNICA

3.8.1 Eventuais visitas técnicas poderão ocorrer até 01(um) dia antes da data marcada para abertura das propostas, devendo ser agendadas com antecedência mínima de 02 dias úteis, junto à Secretaria Municipal de Saúde, em dia útil.

3.8.2 A secretaria disponibilizará um funcionário para acompanhar a visita, caso seja necessário, todavia o transporte ficará a encargo da empresa interessada, não sendo disponibilizado transporte pela Secretaria Municipal de Saúde.

3.8.3 A finalidade da visita técnica é a complementação de informações com o objetivo de sanar possíveis dúvidas de interpretação das especificações desse Termo de referência e o conhecimento das condições locais para o cumprimento das obrigações de execução do objeto da licitação.

3.8.4 A visita técnica não é obrigatória. Por outro lado, a declaração de conhecimento de todas as informações e das condições locais de infraestrutura da rede de dados e internet da CONTRATANTE para o cumprimento das obrigações de execução do objeto da licitação é obrigatória e indispensável, devendo ser apresentada junto a Documentação de Habilitação, conforme exigência do edital.

Autor: VIVVER SISTEMAS LTDA

#	Arquivo

9 -

3.9 TREINAMENTO

3.9.14 A CONTRATADA deverá entregar a solução em três ambientes sendo um de produção, outro de treinamento e um último de homologação.

Deverão ser entregues os seguintes módulos:

3.9.14.1 CADASTRO DE USUÁRIOS E DOMICÍLIOS

3.9.14.2 CADASTRO DOS ESTABELECIMENTOS DE SAÚDE

3.9.14.3 CADASTRO DOS PROFISSIONAIS DE SAÚDE

3.9.14.4 ORDEM DO DIA

3.9.14.5 ATENDIMENTO/PRONTUÁRIO DO CIDADÃO

3.9.14.6 ATENÇÃO PRIMÁRIA E ATENÇÃO DOMICILIAR – INTEGRAÇÃO COM SISTEMA eSUS

3.9.14.7 PROGRAMAS DE SAÚDE

3.9.14.8 URGÊNCIA/EMERGÊNCIA

3.9.14.9 PRESCRIÇÃO ELETRÔNICA

3.9.14.10 SERVIÇOS HOSPITALARES

3.9.14.11 MATERIAL ESTERILIZADO

3.9.14.12 CENTRO CIRÚRGICO

3.9.14.13 HOTELARIA / CCIH

3.9.14.14 CENTRO DE MATERIAL ESTERILIZADO

3.9.14.15 NUTRIÇÃO E DIETÉTICA

3.9.14.16 VACINA

3.9.14.17 VIGILÂNCIA EPIDEMIOLÓGICA

3.9.14.18 VIGILÂNCIA SANITÁRIA

3.9.14.19 VIGILÂNCIA AMBIENTAL - CONTROLE DE ENDEMIAS

3.9.14.20 FATURAMENTO AMBULATORIAL E HOSPITALAR

3.9.14.21 REGULAÇÃO

3.9.14.22 CONTROLE E AVALIAÇÃO

3.9.14.23 LABORATÓRIO

3.9.14.24 SOROTECA

3.9.14.25 TRATAMENTO FORA DO DOMICÍLIO

3.9.14.26 GESTÃO DE FROTA DE VEÍCULOS

3.9.14.27 GESTÃO DE MATERIAIS E MEDICAMENTOS – ALMOXARIFADO E FARMÁCIA

3.9.14.28 APLICATIVO PARA AGENTES COMUNITÁRIOS DE SAÚDE

3.9.14.29 APLICATIVO PARA AGENTES DE ENDEMIAS

3.9.14.30 APLICATIVO MOBILE PARA CIDADÃO

3.9.14.31 PORTAL DO CIDADÃO/PORTAL DA TRANSPARÊNCIA

3.9.14.38 PAINEL ELETRÔNICO DE CHAMADA

3.9.14.39 TELEATENDIMENTO

3.9.14.40 INTELIGÊNCIA DE NEGÓCIOS (BI)

3.36 CRONOGRAMA DE EXECUÇÃO DO CONTRATO

3.41.1 Será estabelecido cronograma de execução para o contrato conforme os seguintes termos:

3.41.2 O início da execução dos serviços se dará imediatamente após a assinatura do contrato, sem regras específicas.

3.42.3 A Implantação do sistema, que inclui migração dos dados e treinamento inicial dos usuários do sistema, terá início imediato, após a assinatura do contrato e finalização no prazo de 6 (seis) meses, após a assinatura do contrato, conforme cronograma de implantação.

3.41.4 Os treinamentos serão realizados sob demanda da contratante.

3.41.5 O suporte técnico terá início imediato, após assinatura do contrato, realizado sob demanda da contratante.

3.41.6 O período de transição contratual se iniciará 90 dias antes do final do contrato e sua finalização juntamente com o final do contrato.

3.41.7 A CONTRATADA deverá seguir o cronograma de implantação apresentado abaixo.

3.41.8 Os prazos serão contados em períodos de 30 (trinta) dias corridos.

3.41.9 O início da contagem dos prazos tem como referência o primeiro dia útil após a data de assinatura do Contrato Administrativo, representada no cronograma com "D".

3.41.10 Os prazos que compõem cada etapa compreendem as atividades, se houver, de planejamento, execução, testes, entre outras atividades necessárias à execução da etapa.

Fica definido um prazo total de 6 (seis) meses para a implantação do sistema.

Autor: VIVVER SISTEMAS LTDA

#	Arquivo

10 -

4. DA FORMA DE PRESTAÇÃO DE SERVIÇO

4.5 Para a atividade de Suporte Técnico, ficam estabelecidos os seguintes prazos para atendimento (Service Level Agreement - SLA)

4.6

ACORDO DE NÍVEL DE SERVIÇO (SLA)
TIPO DE OCORRÊNCIA	DESCRIÇÃO	PRAZO PARA SOLUÇÃO
CRÍTICA	Sistema parado; Sistema apresenta erro que compromete a observância de prazo inadiável; Número significativo de munícipes afetados pela paralisação.	Ação imediata a partir do momento da abertura do chamado com resolução em até 12 horas úteis. OBS: Caso o prazo de resolução do problema ultrapasse as 12 horas úteis previstas neste tópico, a CONTRATADA deverá informar a Secretaria de Saúde formalmente através de documentação o novo prazo necessário e apresentar o plano de contingência para a continuidade do atendimento ao público. O novo prazo não poderá ultrapassar 48 horas úteis.
ALTA	Funcionalidade com problema, mas sem comprometer a operação do sistema; Não há compromisso imediato e inadiável do usuário; Alguns munícipes precisam ter a solução dos seus interesses adiada.	Ação em até 4 horas úteis da abertura do chamado com resolução em até 72 horas.
MÉDIA	Erro ou mau funcionamento não enquadrado nas categorias anteriores e que não paralise o atendimento ao munícipe.	Ação dentro de 4 horas úteis da abertura do chamado e resolução em até 96 horas úteis.
BAIXA	O tempo para conclusão não é requerido e o trabalho normal pode continuar.	Ação em 4 horas úteis da abertura do chamado e resolução em prazo de comum acordo. OBS: Neste caso a CONTRATADA deverá informar a Secretaria de Saúde o prazo necessário para a resolução do problema.

4.7 A contagem do prazo para fins de atendimento a SLA terá início quando da comunicação formal da CONTRATADA sobre a ocorrência e compreenderá somente horas úteis considerando o município sede da CONTRATADA.
4.8 As comunicações feitas for a do horário descrito no item anterior serão contadas a partir do primeiro dia útil subsequente.
4.9 Entende-se como comunicação formal, a comunicação feita de forma documental, física ou eletrônica, contendo a descrição da falha aparente, enviadas à CONTRATADA, pelo Gestor do Contrato Administrativo ou pessoal por este definido, quando de sua ausência.
4.10 Os problemas de funcionamento informados via Suporte Técnico, deverão ser comunicados de imediato ao Gestor do Contrato Administrativo, pelo solicitante, para que acompanhe o processo de solução.
4.11 O nível de criticidade da ocorrência poderá ser alterado, para mais grave ou menos grave, após a realização do diagnóstico.
4.12 Considerar-se-á finalizado o atendimento à ocorrência quando da comunicação formal da CONTRATADA informando da solução desta, que deverá, por meio de teste, demonstrar que a falha foi devidamente sanada.
4.13 Os prazos poderão ser dilatados, a pedido da CONTRATADA, com apresentação de justificativa, que deverá ser aceita ou não pelo Gestor do Contrato Administrativo.

5. DO PAGAMENTO DOS SERVIÇOS

5.3 Customização do sistema: Os serviços de Customização serão realizados sob demanda, até o limite de 1000 pontos de função, conforme solicitação da contratante

10. DA PROVA DE CONCEITO

10.6 A amostragem deverá ser realizada utilizando-se o mesmo software acessado através de um único endereço e porta no navegador, exceto na demonstração dos aplicativos móveis, que poderão ser acessados através de outro endereço e/ou porta.

Autor: VIVVER SISTEMAS LTDA

#	Arquivo

11 -

ANEXO I – MODELO PROPOSTA COMERCIAL MODELO PROPOSTA COMERCIAL

(Papel timbrado do licitante)

Um

PREFEITURA DO MUNICÍPIO DE CONTAGEM

Proposta que faz a empresa , à prestação de serviços para sustentação do sistema

Cygnus.

Valor TOTAL GLOBAL (24 meses) = R$_________ (valor por extenso).

ITEM	DESCRIÇÃO	QDE	UNID	UNIDADE VALOR (R$)	VALOR TOTAL (R$)
1	LICENÇA TEMPORÁRIA DE USO DO SISTEMA DE GESTÃO DE SAÚDE, EM NUVEM.	24	Mês
2	TREINAMENTO, IMPLANTAÇÃO, CONVERSÃO DOS DADOS EXISTENTES / CONFIGURAÇÃO, PARAMETRIZAÇÃO.	6	Mês
3	MANUTENÇÃO LEGAL E CORRETIVA / SUPORTE TÉCNICO.	18	Mês
4	CUSTOMIZAÇÃO PARA ADAPTAR O SISTEMA.	1.000	Pontos de Função
TOTAL GERAL (R$)

Declaro que os preços contidos na proposta incluem todos os custos e despesas, tais como: custos diretos e indiretos, tributos incidentes, taxa de administração, materiais, serviços, encargos sociais, trabalhistas, seguros, frete, embalagens, lucro e outros necessários ao cumprimento integral do objeto deste Edital e seus Anexos.

DADOS DO PROPONENTE:

Nomo:

Razão Social:

Endereço Completo:

CNPJ:

Telefone:_____________ e-mail:______

Validade da Proposta (não inferior a 60 dias corridos):

LOCAL/DADOS:

----------------------------------------------------------------

Assinatura do responsável

Autor: VIVVER SISTEMAS LTDA

#	Arquivo

12 -

REQUISITOS:

CADASTRO DE USUÁRIOS E DOMICÍLIOS
81.	Possuir interoperabilidade com serviço do barramento DATASUS utilizando o perfil IHE PIX/PDQ de identificação de usuários do SUS no CADWEB, a fim de possibilitar pesquisa à base do Cartão SUS (CNS) com consulta on-line via WebService junto à base de dados CADWEB do DATASUS, através de busca por: Cartão SUS, CPF, RG e homônimos (validação por nome, nome da mãe, nascimento e sexo).
82	Permitir o cadastramento do indivíduo de acordo com as regras de cadastramento junto ao CADSUS e contendo os seguintes dados: nome completo, apelido/nome social, data de nascimento, nacionalidade, naturalidade, município/estado de nascimento, sexo, nome do pai, nome da mãe, estado civil, raça/cor, etnia, tipo sanguíneo, país de origem, naturalidade, telefones, documentos, deficiência, biometria digital, foto, número do CNS (Cartão Nacional de Saúde), ocupação, informações sobre domicílio (CEP, tipo de logradouro, nome do logradouro, número do endereço, complemento, bairro, cidade, UF), endereço adicional, município de trabalho, número do CPF, dados do título de eleitor (incluindo número, seção e zona eleitoral), dados da CTPS (incluindo número, série, data de emissão e UF), dados da certidão (incluindo tipo de certidão, nome do cartório, data de emissão, número do termo, número da folha, número do livro, nome da ocupação principal, informações complementares, documentos anexos.
83	No cadastro do cidadão, deverá constar a vinculação à equipe de saúde das unidades básicas por referência de território, e outro adicional para referência à outra equipe definida manualmente, bem como foto que possa ser visualizada por qualquer profissional, tanto nas filas de atendimento quanto internamente no prontuário.
84	Exibir no próprio cadastro, as alergias do paciente.
85	A partir do resultado da busca do cartão SUS (PIX/PDQ), deverá permitir cadastrar ou atualizar um paciente no sistema.
86	Permitir identificação/busca do paciente por meio de biometria para qualquer digital cadastrada.
87	Dispor que todos os cadastros básicos possam ser alterados e incluídos dados.
88	Possibilitar cadastrar usuários com geração do número do prontuário único, obrigando o preenchimento dos campos de acordo com o CADSUS.
89	Dispor de opção no sistema que unifique quando necessário o cadastro do paciente.
90	Permitir cadastro de biometria para identificação do paciente, possibilitando o registro das digitais.
91	Onde houver a necessidade da identificação do paciente dentro de um módulo do sistema, deve ser permitida a realização de busca por CNS, nome do paciente, nome social, CPF, data de nascimento e/ou nome da mãe.
92	O sistema deve validar cadastro de pacientes no ato da gravação as informações para não permitir duplicidade de cadastros, a validação deve ser baseada em checagem de homônimos, utilizando o nome do paciente, nome da mãe, data de nascimento e sexo como base desta validação.
93	Permitir a localização geográfica do endereço do paciente.
94	Permitir referenciamento a ser realizado através do CEP, rua e bairro.
95	Deverá haver "flag" para sinalizar pessoas em situação de rua, desde quando, informações sobre alimentação e higiene.
96	Emitir relatórios de cidadãos, Sintético e Analítico, por: Localidade, Cadastros atualizados e Cadastros duplicados.
97	Emitir relatório de cidadãos com dados cadastrais inconsistentes com o padrão eSUS.
98	Emitir relatório de cidadãos com informações de cadastro e/ou atualização.
99	Emitir relatório de cidadãos com cadastro duplicado.
100	Permitir o cadastramento dos cidadãos e dos domicílios de acordo com as regras de cadastramento junto ao Sistema eSUS.
101	Permitir inabilitar paciente por óbito inativando qualquer movimentação dele no sistema.
102	Permitir o cadastro de recém-nascido através do cadastro da mãe.
103	Permitir o cadastro de visitantes e acompanhante vinculados ao paciente.
104	Permitir alterar o cadastro de visitante e acompanhante.
105	Permitir excluir o cadastro de visitante e acompanhante.
106	Permitir a impressão de etiqueta de visitante/acompanhante com o nome do visitante, nome do paciente, local e leito.
107	Possuir relatório de registro de visitantes.
108	Deve possuir cadastro de imóveis e domicílios compatível com a ficha de cadastro domiciliar e territorial do padrão e-SUS/SISAB. e complementarmente indicar área, micro área e qual a profissional agente comunitário de saúde responsável pela cobertura do imóvel.
CADASTRO DOS ESTABELECIMENTOS DE SAÚDE
109	O sistema deve dispor de rotina para realizar a importação e atualização do CNES (Cadastro Nacional de Estabelecimentos de Saúde) do Município, permitindo a seleção do estabelecimento de saúde para importação. Este cadastro é obrigatório para o funcionamento do sistema, pois importa todos os estabelecimentos de saúde, além de seus respectivos profissionais, equipes (INE), Núcleos de Apoio à Saúde da Família (NASF), serviços, especialidades, etc. (Importar o arquivo XML do CNES. A definição dos campos de dados pode ser encontrada na própria estrutura do arquivo.)
110	Permitir cadastrar novas unidades de saúde, com todas as configurações padronizadas para o CNES.
111	Deve permitir cadastrar os setores existentes dentro do estabelecimento de saúde.
112	Deve permitir configurar os procedimentos que o estabelecimento pode realizar.
113	Deve permitir gerenciar as equipes e os membros das equipes vinculadas ao estabelecimento de saúde.
114	Deve permitir atualizar as equipes e membros manualmente, sem a necessidade de uma importação do arquivo CNES.
CADASTRO DE CONVÊNIOS/PRESTADORES DE SERVIÇOS
115	Deve permitir cadastrar os convênios/contratos com prestadores de serviços utilizados pela CONTRATANTE.
116	Permitir configurar os valores dos procedimentos realizados para o convênio/contrato.
117	Permitir configurar os valores das especialidades realizadas para o convênio/contrato.
118	Permitir customizar as guias de consulta e exame que serão utilizadas para os agendamentos realizados para o convênio/contrato.
119	Permitir criar cotas de utilização de consultas e exames para o convênio/contrato, podendo utilizar controle de quantidade ou valores.
120	A cota pode ser configurada por solicitante, prestador, profissional ou especialidade.
121	Ao realizar um agendamento de consulta ou exame, o valor do procedimento deve ser descontado da cota.
122	O sistema deve limitar o número de agendamentos baseado na quantidade estimada para a cota do convênio.
123	Deverá permitir adotar logotipo da CONTRATANTE na tela principal do sistema.
124	O sistema não deve permitir liberação de nenhum tipo de solicitação, requisição, inclusão em listas para cidadãos inativos.
125	Itens de cadastros que estejam desativados não devem estar disponíveis para lançamento de novos itens, apenas para visualização de registros que eles estejam vinculados.
126	O sistema não deverá exigir a instalação de plug-ins, emuladores ou runtimes para sua utilização, exceto nos casos em que seja necessário para o acesso a dispositivos como leitores biométricos, impressoras (cartão, etiqueta), leitoras/tokens de e-CPF/e-CNPJ, etc.
127	Possuir ferramenta web para construção de relatórios.
128	Deverá possuir dicionário de dados com todas as tabelas do sistema.
129	Possibilitar anexar documentos do paciente, em formato de imagem JPG, JPEG, PNG ou arquivo PDF, para posterior visualização.
130	Deverá carregar os avisos de histórico e/ou pendências do paciente para: vacinas, exames citopatológicos, antropometria, consumo alimentar e frequência de consulta.

Autor: VIVVER SISTEMAS LTDA

#	Arquivo

13 -

REQUISITOS

CADASTRO DOS PROFISSIONAIS DE SAÚDE

131.       Permitir cadastrar profissionais com informações padrão CNES contendo informações OBRIGATÓRIAS: Nome, Sexo, Nascimento, Raça/Cor, Telefone e tipo, OUTRAS INFORMAÇÕES: CNS, CPF, Nome da Mãe, Nome do Pai, Profissão, Grau de instrução, Cargo/Função, E-mail, Vínculo Empregatício, Detalhamento do Vínculo Empregatício, Órgão de Classe, Inscrição, UF Conselho. Cadastrar dados de documentos como RG com data de emissão, órgão emissor e UF. Carteira de Trabalho, Carteira de Habilitação com número do registro de emissão e validade (gera alerta para motoristas cadastrados a realizar viagens no módulo de agendamento de viagens).
132.       Deve conter campo para cadastrar o nome do profissional que será exibido nas mensagens enviadas por SMS.
133.       Possibilitar anexar documentos do profissional, em formato de imagem JPG, JPEG, PNG ou arquivo PDF, para posterior visualização.
134.       Deve permitir gerenciar as agenda dos profissionais, podendo configurar as agendas por semana, período entre datas ou dia específico.
135.       Deve permitir criar agendas por tipo de atendimento: primeira consulta, demanda espontânea e retorno.
136.       Deve permitir configurar nas agendas os intervalos entre os atendimentos do profissional.
137.       Permitir gerenciar a liberação das agendas dos profissionais por período e turno, podendo criar, excluir ou bloquear os turnos gerados.
138.       Permitir criar agendas por estabelecimentos de saúde e especialidade/CBO do profissional.
139.       Permitir selecionar a especialidade padrão do profissional, para os casos de mais de um vínculo numa mesma unidade e para mais de uma especialidade.
140.       Permitir a transferência de agendamentos de consultas e exames por unidade de saúde, profissional ou exames, de uma data ou horário para outro definido. Considerar os períodos de bloqueios de agendas de profissionais e consultas/exames.
141.       Emitir relatório de profissionais com os vínculos de unidade.
142.       Emitir relatório de relação de profissionais com as equipes de atenção básica.
143.       Emitir relatório com relação de vagas disponíveis por turnos e especialidades.
144.       Emitir relatório com relação das vagas disponíveis por profissional.

AGENDA

145.       Permitir cadastrar estruturas de agendas com flexibilidade para unidades x médicos x especialidade x tipo de atendimento, sendo a determinação de vagas por quantidade ou horário.
146.       Após o cancelamento de agendamento de consultas e/ou exames possibilitar o retorno de cota para utilização em novo agendamento.
147.       Controlar agendamentos de consultas determinando intervalo de idade para agendamentos de usuários por especialidade de cada profissional.
148.       Controlar feriados bloqueando agendamentos de consultas e exames para a data.
149.       Disponibilizar calendário mensal com identificação das disponibilidades diárias de agendamentos conforme capacidade e agendamentos já realizados por profissional.
150.       Disponibilizar a visualização do histórico na solicitação, com detalhamento de todas as etapas.
151.       Emitir comprovantes de agendamentos das consultas.
152.       Permitir a geração de chave individual para recepção de solicitação por prestador.
153.       Emitir comprovantes de agendamentos possibilitando a assinatura do profissional.
154.       Emitir relatório com agendamentos dos profissionais.
155.       Emitir relatórios com quantidades disponíveis de consultas por unidade de saúde, profissional, especialidade mostrando a capacidade de atendimento, agendamentos já realizados.
156.       Possibilitar a configuração de agendas de consultas por período, dias da semana e intervalo de horário.
157.       Possibilitar a configuração de consultas por horário (conforme tempo de atendimento) ou quantidade, por motivos de consultas específicos, todos ou exceto informados.
158.       Possibilitar definir horário de atendimento específico para unidade de saúde ou todas.
159.       Permitir definir agenda de consulta para agendamento.
160.       Possibilitar a configuração de agendas de exames por período, dias da semana e intervalo de horário.
161.       Possibilitar a configuração de exames por quantidade ou quantidade por tempo (conforme tempo de atendimento), para todos os exames ou específicos.
162.       Possibilitar a restrição de acesso ao sistema em horários e dias específicos por perfil.
163.       Possibilitar a configuração de cotas de consultas e exames por quantidade e/ou valor orçado para o período.
164.       Possibilitar configurar cotas de consultas e exames por unidade de saúde, CBO e motivos de consultas específicos.
165.       Possibilitar a exportação dos usuários da lista de espera nos agendamentos de consultas e exames, nos formatos: CSV, TXT, XLS e XML.
166.       Possibilitar a baixa ou exclusão dos usuários na lista de espera ao obter o agendamento ou autorização de consulta ou exame.
167.       Possibilitar a visualização e alteração nas listas de espera somente pela unidade de saúde de origem do usuário ou por unidade central de agendamento.
168.       Possibilitar agendamentos de consultas para unidade de saúde específica ou para todas as unidades de saúde como central de agendamentos.
169.       Possibilitar agendamentos de consultas selecionando especialidade, profissional ou unidade de saúde.
170.       Possibilitar informar o motivo da consulta e unidade de saúde de origem.
171.       Possibilitar a seleção de múltiplos usuários da lista de espera quanto a Agendamento e Autorização de Consultas.
172.       Possibilitar o bloqueio de horários de agendamentos de consultas por unidade de saúde de atendimento, profissional, especialidade, período e intervalo de horário.
173.       Possibilitar o cancelamento de agendamentos identificando motivo.
174.       Possibilitar o controle das listas de espera de consultas por especialidade, profissional e unidade de saúde identificando usuário, data e horário de inclusão, data de solicitação, unidade de saúde de origem, profissional solicitante, motivo da consulta e prioridade.
175.       Possibilitar o controle das listas de espera de exames por exame e unidade de saúde identificando usuário, data e horário de inclusão, data de solicitação, unidade de saúde de origem, profissional solicitante e prioridade.
176.       Todos os registros de modificação da agenda deverão ficar registrados na base de dados, sendo visível para o profissional que possuir permissão de pelo menos visualização da agenda o nome da última pessoa que realizou alteração na mesma para cada campo (vaga).
177.       Possuir relatórios com filtros de: data, intervalo em horas, tipo de consulta (básica, especializada), unidade de saúde, paciente, profissional, CBO (especialidade), convênio, procedimento, área, micro área, controle de presença (faltante, cancelado, desmarcado), idade e classificação por sexo.
178.       Emitir relatório de consulta analítico e sintético com a relação de agendamentos por dia.
179.       Emitir relatório de consulta analítico e sintético por unidade solicitante.
180.       Emitir relatório de consulta analítico e sintético por profissionais de destino e origem.
181.       Emitir relatório de consulta analítico e sintético de atendimentos realizados por localidade.
182.       Emitir relatório de consulta analítico e sintético por especialidades.
183.       Emitir relatório de consulta analítico e sintético por paciente.
184.       Emitir relatório de consulta analítico e sintético com encaminhamentos por especialidade.
185.       Emitir relatório de consulta analítico e sintético por profissional.
186.       Emitir relatório de consulta analítico e sintético de comparativo de consultas x atendimentos.
187.       Emitir relatório de consulta analítico e sintético de comparativo de consultas x realizadas.
188.       Emitir relatório de consulta analítico e sintético de consultas por município de residência do paciente.
189.       Emitir relatório de consulta analítico e sintético de profissional por dia.
190.       Emitir relatório de consulta analítico e sintético de agendamentos x encaminhamentos por profissional.
191.       Emitir relatório de consulta analítico e sintético de consultas agendadas/realizadas por profissional.
192.       Emitir relatório de consulta analítico e sintético de prescrições por período de tempo.
193.       Emitir relatório de consulta analítico e sintético por classificação de risco.
194.       Possuir relatórios para o gerenciamento da fila eletrônica de pacientes, como: Oferta de vagas, a relação de pacientes da fila e os comprovantes para serem entregues aos pacientes.
195.       Permitir fazer a gestão de todos os atendimentos, monitorando o tempo de espera, permitindo a consulta de todas as requisições, filtrando pela situação (em aberto, na fila de espera, parcialmente atendida e atendida).
196.       Deverá ser automática a gerência da ordem de filas de espera, de forma cronológica, conforme critérios para prioridade de acesso, normal ou preferencial, com a verbalização do nome/nome social/apelido/senha do paciente e sala que será atendido, com exibição da sua foto em equipamentos de exibição de sons e imagens.
197.       Permitir o controle das salas de atendimento de consultas e exames por horário, imprimindo nos comprovantes para orientação dos usuários no atendimento.
198.       Permitir mostrar profissionais disponibilizados na unidade de atendimento.
199.       Permitir recepção de pacientes pré-agendados com a possibilidade de inclusão de pacientes de procura espontânea e com seleção da ordem de atendimento.
200.       Permitir a recepção de pacientes por leitura de códigos de barras dos agendamentos.
201.       Permitir informar o protocolo e ocorrências classificando automaticamente o risco.
202.       Permitir identificar os pacientes através da respectiva cor e ordenando conforme a classificação de risco e tempo de espera.
203.       Permitir visualizar e manter confirmação online pelo usuário do SUS de procedimento previamente agendado.

Autor: VIVVER SISTEMAS LTDA

#	Arquivo

14 -

REQUISITOS:

ATENDIMENTO/PRONTUÁRIO DO CIDADÃO

204. Por meio do sistema, os profissionais de saúde deverão ser capazes de atender pessoas previamente agendadas ou fazer a abertura diretamente do prontuário (sem inserção prévia na agenda) para atendimentos de demanda espontânea.
205. Deverá possibilitar, principalmente no atendimento das Unidades de Pronto Atendimento (ou outras, se assim a gestão municipal solicitar), um painel de exibição de todos os cidadãos em observação na unidade de modo que o atendimento do cidadão esteja condicionado a nova autenticação (login) a partir dessa janela.
206. O sistema deve permitir o registro de atendimento de pacientes em turmas de atendimento, ou seja, mais de um paciente para um mesmo horário como ocorre na fisioterapia ou outros agendamentos em grupos.
207. Deverá calcular automaticamente o IMC – Índice de Massa Corporal, estado nutricional para criança, adolescente, adulto e idoso conforme idade do usuário.
208. Deverá emitir receita de medicamentos, atestado médico, declaração de comparecimento, orientações, requisição de exames.
209. Emitir receituário de medicamentos dentro do atendimento médico.
210. Permitir criar tabela de preços de medicamentos e materiais para efeito de apuração de custos de cada atendimento.
211. Permitir o registro de triagem ou preparo de consultas de cada usuário (peso, altura, pressão arterial, pulsação arterial, frequência respiratória, cintura, quadril, perímetro cefálico, glicemia capilar, saturação) durante a pré-consulta. Permitir registrar os procedimentos realizados pela triagem de consultas.
212. Permitir informar saída do atendimento com informação de encaminhamentos quando os usuários que não necessitam de atendimento médico.
213. Possibilitar a impressão da Ficha de Atendimento, Declaração de Comparecimento e Guias de Referência e Contrarreferência.
214. Permitir recepção de usuários pré-agendados com possibilidade de inclusão de usuários de procura espontânea, com seleção da ordem de atendimento.
215. Possibilitar a consulta de histórico de Atenção Domiciliar por usuário, unidade de saúde, período e situação apresentando informações das solicitações e atendimentos.
216. Possibilitar a digitação de atendimentos realizados pelas unidades de saúde com atendimento não informatizado, incluindo os procedimentos realizados.
217. Possibilitar a digitação de procedimentos simplificados realizados por setores especializados (EX.: inalação, enfermagem).
218. Possibilitar a digitação dos procedimentos em conformidade com a ficha de procedimentos do Sistema eSUS do Ministério da Saúde.
219. Possibilitar a restrição da visualização no prontuário de atendimentos realizados em unidades de saúde definidas.
220. Possibilitar ao médico acesso completo aos atendimentos anteriores do usuário por ordem cronológica de data possibilitando detalhar individualmente os atendimentos realizados.
221. Disponibilizar acesso minimamente às informações de: avaliação antropométrica, sinais vitais, classificações de riscos, queixas, anamnese, resultados de exames, diagnósticos, procedimentos realizados, prescrições de medicamentos, requisições de exames, encaminhamentos.
222. Ordenar pacientes para atendimento conforme classificação de risco identificando a respectiva cor. 223.
Possibilitar o controle de Tetos Financeiros de PPI - Programação Pactuada e Integrada sobre procedimentos realizados nos atendimentos ambulatoriais e internações.
224. Possibilitar prescrição de materiais.
225. Possibilitar o preenchimento do registro de atendimento médico com todas as informações sendo dispostas em ficha contínua.
226. Possibilitar o registro das informações completas de atendimentos retroativos de consultas médicas realizadas em atendimentos não informatizados.
227. Restringir os operadores concedendo acesso para registro dos atendimentos conforme profissional e período.
228. Possibilitar o registro de atividades coletivas informando data, horário de início, horário de encerramento, duração, participantes, população, profissionais, procedimentos realizados, usuários atendidos e estabelecimento, temas para reuniões, práticas e temas para a saúde, em conformidade com o requerido pelo sistema eSUS.
229. Possibilitar o registro de informações clínicas (alergias, doenças) dos usuários. No momento do atendimento de consulta, aplicação de vacinas deve ser automaticamente visualizadas as informações cadastradas para o usuário.
230. Possibilitar o registro de Marcadores de Consumo Alimentar em conformidade com a ficha do eSUS do Ministério da Saúde.
231. Possibilitar que no momento da prescrição do médico, seja possível identificar medicamentos de uso contínuo e/ou imediato, via de administração e se o medicamento está disponível no estoque da farmácia da unidade.
232. Possibilitar que o medicamento seja pesquisado pelo nome comercial.
233. Possuir o registro de atendimentos médicos complementando a triagem/preparo de consulta do usuário com informações de anamnese, queixas, exame físico, histórico clínico, procedimentos realizados pelo médico, prescrições de medicamentos, requisições de exames, diagnósticos e encaminhamentos.
234. Possuir prontuário eletrônico que atenda os seguintes estágios de atendimento: recepção de usuários, triagem/preparo de consultas e atendimento médico conforme estrutura das unidades de saúde.
235. Permitir a inserção direta da ficha de atendimento individual nos moldes do eSUS, em unidades de saúde que não possuírem estrutura para utilização de fluxo de atendimento.
236. Permitir a inserção direta da ficha de procedimentos nos moldes do eSUS, em unidades de saúde que não possuírem estrutura para utilização de fluxo de atendimento.
237. Permitir a inserção direta da ficha de procedimentos consolidados nos moldes do eSUS, em unidades de saúde que não possuírem estrutura para utilização de fluxo de atendimento.
238. Permitir a inserção direta da ficha de atendimento odontológico individual nos moldes do eSUS, em unidades de saúde que não possuírem estrutura para utilização de fluxo de atendimento.
239. Permitir o registro do código CIAP nos atendimentos realizados na Atenção Primária.
240. Deverá possibilitar o chamamento de cidadãos por painel eletrônico localizado dentro do mesmo ambiente físico.
241. Deverá conter sistemas de classificação a ser utilizado em quaisquer consultas (a obrigatoriedade ou não, obedecerá a definições nacionais e locais), minimamente CID e CIAP.
242. Deverá permitir o uso de classificação de risco para as Unidades de Pronto Atendimento com controle de tempo de espera e direcionamento para fila específica de atendimento (por especialidade ou profissional).
243. Deverá conter dentro do prontuário uma "lista de problemas" baseada em CID e CIAP na qual o problema poderá ser definido como "histórico", "latente" ou "ativo". Adicionalmente, esta mesma lista possibilitará a inclusão de outros problemas que não estejam contemplados por essas duas classificações em formato de texto livre, com a mesma sinalização, de maneira semelhante à definida pelo Ministério da Saúde por meio do eSUS PEC no momento da publicação deste edital.
244. Haverá campo específico para "prescrição interna" (a ser realizada na própria unidade) para medicamentos e demais condutas, distinguindo se este daqueles campos direcionados às condutas a serem realizadas pelo cidadão for a da unidade.
245. Ao finalizar o atendimento, o profissional de saúde poderá encaminhar o cidadão para outro profissional ou fila de atendimento dentro da mesma unidade, além dos encaminhamentos para as especialidades (for a da unidade).
246. No atendimento realizado pela equipe de enfermagem aos cidadãos em observação ou direcionado para filas de atendimentos dentro da unidade, todas as condutas orientadas pelo médico poderão ter sua realização confirmada por meio de seleção simples de campos (checkbox), sendo que, para os medicamentos, a baixa por consumo será automática neste ato e vinculada ao cidadão.
247. No campo destinado aos encaminhamentos, haverá padrão específico para encaminhamentos imediatos a serviços de urgência, como UPAs e emergências hospitalares, com marcação quando houver solicitação de veículo para remoção do cidadão.
248. Deverá possibilitar o uso de identificador biométrico tanto para os profissionais (no ato de login) quanto para os cidadãos (para busca do cadastro ou no ato de abertura de prontuário), sendo que estes podem ser definidos como condição necessária para o registro de procedimentos a serem definidos pela CONTRATANTE.
249. Todos os acessos a prontuário deverão ser feitos a partir de login com registro em base de dados de acesso (log), mesmo que somente leitura e registro histórico completo no caso de alterações, de modo a permitir auditoria do processo.
250. A prescrição de quaisquer medicamentos deverá seguir o formato fechado, onde a prescrição informará a quantidade de unidades, periodicidade (posologia diária) e tempo de tratamento, sendo que o sistema calculará automaticamente o total, exceto se expressamente sinalizado no cadastro do medicamento a desabilitação desta função, quando a prescrição deverá ser feita em campo texto (não estruturado).
251. Deverá possuir Laudo para Solicitação, Avaliação e Autorização de Medicamentos do Componente Especializado (LME) integrado ao prontuário eletrônico juntamente com a emissão de prescrição para os demais medicamentos, sendo que a impressão deverá seguir os padrões definidas pelas entidades de saúde responsáveis pelo Componente Especializado da Assistência Farmacêutica.
252. A plataforma deverá realizar a emissão de receitas separadas automaticamente (quando prescritos no mesmo atendimento) por tipo de medicamento, sendo o mínimo de "normais", "controlados" (com separação para psicotrópicos e outros tipos de receita especial) e "especializados" (LME), sendo todos sempre nos moldes definidos pelos protocolos clínicos e diretrizes terapêuticas do Ministério da Saúde e legislação específica.
253. A geração de receitas de medicamentos que exijam notificação (de acordo com a Portaria ANVISA 344/98) gerará um lembrete para emissão de notificação, a ser realizada manualmente pelo prescritor.
254. Quando da prescrição de medicamentos de componente especializado, deverá haver a funcionalidade de impressão do restante dos documentos necessários para abertura do processo (laudo, termo de consentimento, dentre outros exigidos nos Protocolos Clínicos e Diretrizes Terapêuticas - PCDT).
255. Haverá integração completa entre as funcionalidades "prescrição" e "dispensação", de modo que não seja necessário reinserir dados já informados corretamente na primeira e conter atalho para acesso ao prontuário eletrônico na tela de dispensação de medicamentos.
256. Deverá ser possível a criação de modelos alternativos de receita de medicamentos com o uso de gravuras (por exemplo, o desenho de uma pessoa ingerindo um comprimido em complementação à "comprimido via oral") em complementação a componentes textuais obrigatórios de modo a facilitar o entendimento do cidadão que tenha dificuldade ou impossibilidade de leitura textual.
257. A tabela de procedimentos interna do sistema deverá permitir a inclusão de outros procedimentos, além da SIGTAP, mas com possibilidade de vinculação a esta tabela nacional. De maneira semelhante, será possível estabelecer "máscaras" para quaisquer procedimentos da tabela (nome substitutivo visualizável pelo usuário do sistema em substituição ao SIGTAP), bem como vinculação entre estes, de modo que a inclusão de um procedimento possa gerar a inclusão de outros.
258. A plataforma permitirá que seja configurada a inclusão automática de procedimentos a partir de dados existentes na base, como CBO, CNES ou tipo de agenda, de modo que o profissional não precise inserir o código de procedimento obrigatoriamente para caracterizar aquele atendimento.
259. A exportação de dados para o SISAB ou qualquer outra base/sistema exigido por lei ou outra normativa deverá, sempre que possível, supor as informações a partir de outros registros realizados nos atendimentos a que se refere, evitando que o profissional (usuário do sistema) tenha que informar diretamente os dados mínimos para exportação em campos especificamente para este fim.
260. Deverá haver campos específicos para o preenchimento dos resultados de exames (inserção manual nos casos em que os mesmos não tenham sido realizados em laboratórios utilizando o Sistema ou que a comunicação direta não seja possível por algum motivo), devendo gerar gráficos nos casos em que os resultados forem numéricos para acompanhamento e alertas para a equipe (a partir de valores mínimos e máximos definidos no cadastro do exame).
261. Deverá possuir funcionalidades para uso racional dos medicamentos, sendo minimamente os seguintes: aviso para interações medicamentosas. posologia máxima diária. sugestão de tratamento a partir de CID ou CIAP preenchido no momento da consulta.
262. Deverá bloquear a reimpressão de requisições de exames que já tenham sido realizados (recebimento de resultado ou confirmação de realização pela regulação).
263. A agenda do sistema deverá permitir ampla flexibilidade, com intervalos de consultas variáveis inclusive dentro do mesmo período, repetição das predefinições por dia da semana, semana, dia do mês, dia e período, tudo isso a ser definido por tipo de unidade de saúde, equipe, CBO e profissional.
264. O prontuário deverá conter a capacidade de aglutinar os mesmos registros referentes aos livros oferecidos pelo Ministério da Saúde para o controle de sintomáticos respiratórios e pacientes diagnosticados com tuberculose (conhecidos como livros verdes).
265. Deverá haver a possibilidade de que os códigos de procedimentos (SIGTAP ou outros incluídos como códigos locais) a serem utilizados para caracterização da consulta sejam definidos a priori (antes da consulta, no momento da confecção de agenda) ou a posterior (no momento da finalização da consulta), a ser definido para cada tipo de unidade pela CONTRATANTE.
266. A janela/aba de encaminhamentos para especialidades deverá possuir botão vinculado à especialidade selecionada o qual possa demonstrar fluxo para encaminhamento a esta especialidade, definido pela CONTRATANTE e em documento disponibilizado pela mesma (na POC deverá ser demonstrada a possibilidade de abertura de um documento qualquer de exemplo por meio deste botão em pelos menos duas especialidades, demonstrando que o documento varia conforme a especialidade selecionada).
267. Tanto a ferramenta de encaminhamento para especialidades quanto a de solicitação de exames deverão possibilitar que estes, antes de serem encaminhados para a ferramenta de regulação, possam ser previamente classificados no sistema a partir do preenchimento, pelo profissional solicitante, de formulário personalizável pela CONTRATANTE para cada exame/especialidade, por meio de ferramenta administrativa, utilizando algoritmos de classificação com peso definido nesta mesma mesma ferramenta.
268. Deverá possuir campo dedicado ao registro de Projetos Terapêuticos Singulares/Individuais (PTS/PTI) que se manterá visível no prontuário eletrônico enquanto estiver vigente para os profissionais lotados nos Centros de Atenção Psicossocial, minimamente contendo campos textuais a serem escritos no formato de escala por período e dia da semana.
269. Deverá possuir alguma forma de vínculo entre pessoas residentes no mesmo endereço como membros de uma mesma família, de modo que por meio do prontuário de um desses membros haja acesso facilitado aos demais e seja possível realizar registros no prontuário da família.
270. O módulo PEP deverá ser customizável em confecções de composições de anamnese e evoluções (médicas, de enfermagem e multiprofissional), visando o máximo de aderência aos processos de trabalhos na assistência.
271. O sistema deve permitir ao médico fazer o registro da evolução em formulário eletrônico carregando o layout do documento de forma automática de acordo com o local de atendimento (setor) e a especialidade do profissional.
272. O sistema deve permitir o registro eletrônico da suspensão das medicações e procedimentos prescritos pelos médicos ou outros membros da equipe multidisciplinar que não foram executados, informando o motivo da suspensão ou cancelamento.
273. Permitir o acompanhamento de indicadores da Atenção Primária (Previne Brasil) de forma automática, geral e/ou por equipe.
274. Exibir alertas no momento do atendimento conforme grupo prioritário e/ou indicadores do Previne Brasil.
275. Estar de acordo com a PORTARIA Nº 2.979, DE 12 DE NOVEMBRO DE 2019, que institui o PREVINE BRASIL, com demonstração de relatórios que comprovem o atendimento aos seus indicadores.
276. Após o registro do atendimento, o sistema deverá permitir ao usuário fazer a emissão dos seguintes documentos:
277. Etiqueta de Identificação com Código de Barras.
278. Termo de Responsabilidade.
279. Ficha de Atendimento Ambulatorial e de Emergência.
280. Possibilitar registro de consumo de álcool e drogas.
281. Deve limitar o registro dos procedimentos baseados nas regras de CBO existentes na tabela SIGTAP.
282. Acompanhamento pré natal - deverá permitir o cadastro de pacientes com acompanhamento e lançamento de todas as informações padrão Pré-Natal Ministério da Saúde com, no mínimo, as seguintes informações e funcionalidades:
- Permitir registrar se é gestante.
- Permitir registrador DUM.
- Permitir registrador DPP.
- Permitir registrar IG Semanas.
- Permitir registrar o Batimento cardíaco fetal.
- Permitir registrar o Peso.
- Permitir registrar a Altura.
- Permitir registrar o IMC.
- Permitir registrar a Pressão Arterial.
- Permitir registrar a Vacina está em dia.- Permitir registrar se a gravidez foi planejada.

- Permitir registrar os Testes realizados.
- Permitir registrar o Tipo de Gravidez.
- Permitir registrar o Risco Gestacional.
- Permitir registrar o Edema.
- Permitir registrar a Contração Uterina.
- Permitir registrar a Perda de líquido via vaginal.
- Permitir registrar a Perda de sangue via Vaginal.
- Permitir registrar o Movimento Fetal.
- Permitir registrar a Queixa Urinária.
- Permitir registrar a Fita Urinária.
- Registrar antecedentes obstétricos.
- Emitir relatórios de gestantes cadastradas por unidade.
- Emitir relatórios de gestante sem consulta.
- Emitir relatórios de gestação em aberto.
- Emitir relatórios de gestantes com risco.
283. História pediátrico:
- Permitir registrar o Início do pré-natal.
- Permitir registrar Sorologia realizada no pré-natal.
- Permitir registrar a Imunização realizada no pré-natal.
- Permitir registrar as Doenças Maternas na gestação.
- Permitir registrar o Local de realização do parto.
- Permitir registrar o Tipo de parto.
- Permitir registrar a Indicação de tipo de parto.
- Permitir registrar o Nascimento.
- Permitir registrar a Idade gestacional.
- Permitir registrar os Dados antropométricos ao nascer.
- Permitir registrar o Apgar.
- Permitir registrar a Tipagem sanguínea do RN.
- Permitir registrar os Problemas neonatais.
- Permitir registrar a Manobra de Ortolani.
- Permitir registrar o Teste de reflexo vermelho.
- Permitir registrar o Teste do pezinho.
- Permitir registrar a Triagem Auditiva.
- Permitir registrar a Data da Alta.- Permitir registrar o Peso da Alta.- Permitir registrar o Aleitamento Materno na Alta.284.

ACOMPANHAMENTO DE PACIENTES CRÔNICOS - deverá permitir cadastrar todos os doentes crônicos com:
285. Doenças concomitantes (Diabetes 1 e 2, Hipertensão arterial, cardiopatias, transtornos mentais: Fatores de risco (alcoolismo, tabagismo, dependência química, sobrepeso, sedentarismo, antecedentes familiares).
286. Complicações, (Infarto Agudo do Miocárdio, Outras Coronariopatias, AVC, Pé Diabético, Amputação P/ Diabetes, Doenças Renais, Internamento Hospitalar Psiquiátrico, Internamento P/ Dependência Química, Angina).
287. Deve permitir criar esquemas terapêuticos integrados os produtos/suprimentos da rede
288. Deverá permitir dar saída automática dos medicamentos cadastrados no esquema terapêutico mostrando a validade da receita, caso a validade já tenha expirado o sistema não deverá permitir dar saída nos medicamentos.
289. Emitir relatórios sintéticos e analíticos de pacientes crônicos por patologia.
290. Emitir relatórios sintéticos e analíticos de pacientes crônicos por unidade de saúde.
291. Emitir relatórios sintéticos e analíticos de medicamentos dispensados por patologia.
292. Emitir relatórios sintéticos e analíticos de pacientes crônicos com esquema terapêutico pré definido.
293. Emitir relatórios sintéticos e analíticos de complicações por paciente.
294. Óbito:
- Permitir registrar Data do óbito.
- Permitir registrar o Número certidão de óbito.
- Permitir registrar uma Necropsia.
- Permitir registrar o Local óbito.
- Permitir registrar a Fonte de informação.
- Permitir registrar a Declaração da informação.
- Permitir registrar a Causa da morte.
295. Permitir acesso ao histórico do paciente.
296. Permitir salvar e/ou concluir o atendimento.
297. Odontologia:- O registro odontológico deverá ser feito conjuntamente no mesmo mecanismo de registro dos demais profissionais, com a adição de odontograma digital, contendo minimamente as seguintes funcionalidades:
visão parietal e lingual, visualização de dentição decídua e permanente, sinalização gráfica para eventos históricos, em realização e a serem realizados, sinalização gráfica para dentes perdidos, não eclodidos, restauração, procedimentos de endodontia, doenças gengivais, cáries, aparelhos ortodônticos, próteses e todos os demais que compõem os serviços odontológicos das unidades de atenção básica e Centros de Especialidades Odontológicas, conforme previsto em normativas ministeriais, devendo a ferramenta básica (definida como a existência de odontograma com sinalização de problemas bucais básicos – cárie, ausência, placa e tártaro – e sinalização de necessidade de serviços básicos – exodontia, profilaxia e restauração).
- Permitir ao profissional registrar os serviços realizados através do Odontograma com início e término do tratamento permitindo automaticamente colocar como abandono tratamentos não concluídos após a data prevista na primeira consulta programática.
- Permite criar odontograma de acordo com a idade, possibilitando carregar arcada para criança com dentes decíduos e dentição permanente no caso de adulto.
- Permite que o odontograma faça distinção por dentição sendo: permanente, decídua ou mista - neste caso alterando apenas a numeração do dente correspondente.
- Permite realizar exodontia parcial: caso o dente seja removido do odontograma, identificar que ainda possui estrutura do dente, fazer a re-inclusão do dente no odontograma.
- Permite criar mais de um plano de tratamento para o mesmo paciente.
298. Saúde Mental:
- Deve ser possível registrar todas as informações do atendimento para o paciente referente à atenção psicossocial.
- Permitir registrar as ações ambulatoriais para a atenção psicossocial, sendo que cada tipo de ação deverá ter campos distintos e regras diferenciadas, deverão ser personalizadas às suas necessidades de acordo com as normas do SUS.
299. Permitir inserir as quantidades das ações realizadas pelo profissional, informando o local da realização da atividade.
300. As ações devem ser vinculadas aos procedimentos da tabela SIGTAP.
301. Permitir vincular um CID à ação caso o procedimento esteja exija esse preenchimento em suas condicionalidades.
302. O sistema deverá validar diversas regras determinadas pelo Ministério da Saúde, para o preenchimento correto das ações para evitar rejeições ou glosas posteriores na importação, por exemplo: compatibilidade entre as ações, dados de preenchimento obrigatórios etc.
303. Deve permitir imprimir os espelhos dos atendimentos.
304. Permitir exportar uma remessa de atendimentos registrados de acordo com o layout oficial do RAAS- DATASUS, separando por competência e gerando campo controle evitando a redigitação.
305. Deverá gerar os seguintes relatórios RAAS: por procedimento, atendimento, profissional, origem e destino do paciente.
306. Visualizar, manter e imprimir senha em ordem numérica sequencial, por ação do usuário do SUS na entrada da unidade de saúde, com critérios de priorização predefinidos para o atendimento demandado, com registro dos horários de emissão da senha, de início e término deste primeiro atendimento de recepção realizado e do atendimento agendado.
307. Permitir o registro dos atendimentos de enfermagem informando orientações a pacientes pela metodologia CIPESC – Classificação Internacional das Práticas de Enfermagem em Saúde Coletiva.
308. Visualizar e manter lembrete vinculado ao profissional de saúde e ao Prontuário Eletrônico do Cidadão para o atendimento atual ou futuro.
309. Visualizar e manter justificativa inserida pelo responsável pela consulta ao histórico do usuário do SUS.
310. O sistema deverá possuir módulo que permita a enfermagem construir os planos de cuidados ao paciente, bem como a prescrição de enfermagem.
311. Emitir em um único relatório um extrato de pacientes e famílias detalhando os atendimentos realizados nas unidades de saúde, possibilitando visualizar: atendimentos realizados, medicamentos dispensados, encaminhamentos, aplicações de vacinas, exames realizados, procedimentos odontológicos, agendamentos e transportes.
312. Calcular automaticamente o IMC – Índice de Massa Corpórea, ICQ – Índice de Cintura Quadril, estado nutricional para criança, adolescente, adulto e idoso conforme a idade do paciente. (Ciclo de vida).
313. Permitir a consulta de histórico de RAAS-AD Atenção Domiciliar por paciente, unidade de saúde, período e situação apresentando informações das solicitações e atendimentos.
314. Permitir a consulta de histórico de RAAS-PSI Psicossocial por paciente, unidade de saúde, período e situação apresentando informações das solicitações e atendimentos.
315. Permitir a criação e formatação de modelos de atendimento no prontuário eletrônico criando protocolos de atendimento e possibilitando a montagem da estrutura de fichas de atendimento para cada especialidade ou tipo de atendimento.
316. O sistema deverá na composição das fichas de atendimento eletrônico possibilitar a ordenação da estrutura de dados inseridos nas montagens dos modelos, isso para facilitar a montagem e alteração das fichas.
317. Na formatação das fichas de atendimento eletrônico será necessária para cada item criado, a possibilidade de parametrizar a obrigatoriedade para preenchimento obrigatório.
318. Na formatação das fichas de atendimento eletrônico será necessário obter recurso de perguntas e respostas combinadas, ou seja, só deverão aparecer outras perguntas caso a resposta permita, caso não, estas perguntas não deverão aparecer, isto para não evitar o excesso de informações na tela.
319. Na formatação das fichas de atendimento eletrônico o sistema deverá permitir obter respostas automáticas, através de combinação de resultados para realização de classificação de risco.
320. Na formatação das fichas de atendimento eletrônico deverá ser possível inserir cores diferentes para as respostas automáticas, isto para melhor e facilitar a visualização.
321. Na formatação das fichas de atendimento eletrônico deverá ser possível a parametrização de dados que só deverão aparecer conforme o sexo do paciente.
322. Na formatação das fichas de atendimento eletrônico deverá ser possível a parametrização de dados que só deverão aparecer conforme idade delimitada.
323. Na formatação das fichas de atendimento eletrônico, para os campos numéricos o sistema deverá estabelecer um limite entre o valor mínimo e o valor máximo.
324. Trabalhar com o conceito de protocolos de atendimento, contendo no mínimo os protocolos de Acolhimento, Adulto, Mulher, Criança, Idoso, Pré Natal, Hipertensão, Diabetes, Dengue, Asma, Saúde Bucal, Saúde Mental e Urgência.
325. Permitir a padronização de exames de acordo com cada protocolo, sugerindo automaticamente ao médico os exames a serem solicitados no atendimento.
326. Permitir a padronização de CIDs de acordo com cada protocolo, sugerindo automaticamente ao médico os CIDs a serem inseridos no atendimento.
327. Permitir a padronização de medicamentos de acordo com cada protocolo, sugerindo automaticamente ao médico os medicamentos a serem solicitados no atendimento.
328. Disponibilizar os protocolos de atendimento de acordo com o perfil do médico e o perfil do paciente amarrando variáveis como idade e sexo para cada protocolo.
329. Visualizar a curva de crescimento baseado nos dados do paciente, a visualização deverá ocorrer de forma gráfica, podendo visualizar por estatura e idade ou por peso e idade.
330. Registro do uso de gases medicinais (com identificação de data, hora de início e fim do tratamento, tempo ou quantidade de uso, registro de regime de urgência e plantão, para fins de faturamento).
331. Registro do uso de equipamentos (com identificação de data, hora de início e fim do tratamento, tempo ou quantidade de uso, registro de regime de urgência e plantão, para fins de faturamento).
332. Permitir a criação de protocolos identificando os tipos de campos que irão compor cada protocolo a partir de dicionário de componentes.
333. Possibilitar a solicitação de medicamentos durante o atendimento de acordo com o estipulado pelo protocolo de atendimento e com os produtos padronizados pela farmácia.
334. Possibilidade de inserir alertas de forma automática, conciliando perguntas e respostas, sendo que, dependendo da resposta o sistema deverá emitir ou não o alerta para a visualização.
335. O sistema deverá conter em sua composição de dados o questionário de CAGE, sendo obrigatória a resposta automática deste questionário.
336. O sistema deverá permitir o controle e inserção de dados referente ao balanço hídrico dos pacientes, possibilitando a parametrização de tempo para execução conforme a prescrição, inserção também itens observáveis de ganhos e perdas com resultado final.
337. Visualizar, manter, imprimir e gerar arquivo com todas as fichas de notificação em conformidade ao Sistema de Informações sobre Agravos de Notificação (SINAN) do Ministério da Saúde, com preenchimento automático dos dados requeridos e já inseridos no Sistema.
338. Visualizar, manter e imprimir fichas de seguimento/acompanhamento em conformidade ao Sistema de Informações sobre Agravos de Notificação (SINAN) do Ministério da Saúde, com preenchimento automático dos dados requeridos e já inseridos no Sistema.
339. Visualizar e manter opções de condição funcional com utilização da Classificação Internacional de Funcionalidade, Incapacidade e Saúde (CIF), vinculada ao Prontuário Eletrônico do Cidadão.

Autor: VIVVER SISTEMAS LTDA

#	Arquivo

15 -

REQUISITOS:

ATENÇÃO PRIMÁRIA E ATENÇÃO DOMICILIAR – INTEGRAÇÃO COM SISTEMA eSUS

340. Permitir realizar integração com o sistema eSUS com exportação dos dados das fichas: Cadastro Individual, Cadastro Domiciliar, Atendimento Individual, Atendimento Odontológico Individual, Atividade Coletiva, Procedimentos, Visita domiciliar, Marcadores do Consumo Alimentar, Avaliação de Elegibilidade e Admissão, Atendimento Domiciliar e outras que porventura venham a existir.
341. Dispor de funcionalidade para registro das visitas domiciliares.
342. Permitir o registro e manutenção da ficha de cadastro domiciliar, nos moldes do eSUS.
343. Dispor do controle de permissão das informações por ACS, ou seja, apenas pode fazer manutenção das famílias da área e microárea da qual a ACS é responsável.
344. Permitir o registro e manutenção da ficha de cadastramento do usuário, cadastro individual e cidadão do eSUS.
345. Relatórios e estatísticas das famílias e domicílios cadastrados.
346. Permitir o registro do questionário de entrevista para o planejamento familiar.
347. Permite visualizar aos procedimentos e quantidade dos mesmos realizados através das fichas do eSUS, que foram realizados em determinado período.
348. Permite realizar o cadastro da ficha de atendimento domiciliar, informando os seguintes dados: Profissional, Unidade, Dados do Paciente, Dados do Atendimento Domiciliar do paciente.
349. Permite integrar a Ficha de Atendimento Domiciliar com o eSUS.
350. Possuir relatório de pacientes sem Cartão SUS, permitindo visualizar os pacientes que estão sem o CNS no sistema. Filtros mínimos: Paciente, Unidade, Profissional, Área, Micro área e Forma de Apresentação.
351. Possuir funcionalidade para registros da escuta inicial realizada pelos profissionais técnicos da unidade de saúde.
352. Deve gerar procedimento automático a cada registro de medição (pressão arterial, glicemia, dados antropométricos e outros) informado durante o registro da escuta inicial.
353. Possuir tela para cadastro de procedimentos para lançamento automático ou não durante o registro da escuta inicial.
354. Emitir relatórios que contemplem a produção das fichas de: Atendimento Individual e Procedimentos.
355. Emitir relatório de acompanhamento de visitas e seus motivos.
356. Emitir relatório que contemple a produção das Atividades Coletivas, exibindo seus temas e práticas em saúde.
357. Emitir relatório que contemple a produção dos Marcadores de Consumo Alimentar, exibindo por faixa etária, local e crianças menores de 6 (seis) meses.
358. Permitir o registro de agendamento de consultas e atendimentos programáticos, com gerenciamento local da unidade de saúde.
359. Permitir realizar o registro dos Atendimentos Domiciliares de acordo com o padrão de Ficha de Avaliação de Elegibilidade e Admissão padrão e-SUS, destinada aos registros das ações de promoção à saúde do indivíduo.
360. Permitir registrar atendimento a pacientes de microcefalia, padrão e-SUS com registro de: Unidade de Saúde, Profissional, CBO, data, equipe, usuário do serviço, responsável familiar e turno (manhã, tarde ou noite).
361. Permitir trabalhar de forma georreferenciada estruturando as áreas de abrangência de cada unidade de saúde.
362. Permitir a transferência de famílias de área e microárea.
363. Emitir relatórios e gráficos de Famílias com quantidade e percentual, totalizando por área, microárea, bairro, logradouro, situação de moradia e saneamento.
364. Emitir relatórios e gráficos de visitas de ACS do ESF/ACS de gestantes, crianças, diabete, hipertensão arterial, tuberculose, hanseníase, por quantidade e percentual, com totais por área, microárea, profissional, bairro, família, paciente, faixa etária.
365. Emitir relatórios comparativos de anos e meses anteriores, de visitas de ACS do ESF/ACS de gestantes, crianças, diabete, hipertensão arterial, tuberculose, hanseníase, por quantidade e percentual, com totais por área, microárea, profissional, bairro, família, paciente, faixa etária.
366. Possibilitar busca de famílias por CEP, listando todas as famílias relacionadas nesta busca.
367. Permitir ativar, bloquear, bloquear parcialmente e bloquear permanentemente em caso de óbito o cadastro dos munícipes, sendo que, para cada alteração destas situações cadastrais, o sistema deverá gravar o motivo da alteração.
368. Permitir trabalhar com endereçamento do CEP e georreferenciamento, possibilitando relacionar o endereço da família a uma microárea de atendimento.
369. Permitir gerenciar as informações georreferenciadas dos agravos de notificação compulsória, existentes em cada microárea.
370. Possuir mecanismos automatizados que tratem do cruzamento de informações a partir dos atributos que compõem o cadastro do munícipe, com o objetivo de minimizar a inserção de cadastros em duplicidade.
371. Visualizar e manter a validação do endereço do imóvel pelo profissional de saúde durante a execução da ação de saúde.
372. Permitir inserir informações sobre morte de animais na residência, causa da morte e data da ocorrência, para maior controle das equipes responsáveis.
373. O sistema deverá possibilitar a criação de roteiro de visitação.

PROGRAMAS DE SAÚDE

374. Permitir cadastrar as ações programáticas do Ministério da Saúde e as de interesse municipal, identificando os medicamentos e outros insumos utilizados nas ações programáticas.
375. Permitir a programação da frequência dos pacientes incluídos nas ações programáticas para fornecimento de medicamentos, consultas e exames conforme periodicidade definida pelo programa.
376. Permitir o cadastro e acompanhamento do programa saúde da criança obtendo informações de acompanhamento da saúde da criança, tais como: estado nutricional, peso, altura, perímetro cefálico, dieta, doenças, psicomotor.
377. Permitir o cadastro e o acompanhamento do programa planejamento familiar obtendo as informações de fatores de risco reprodutivo, complicações e método contraceptivo.
378. Permitir o cadastro e o acompanhamento do programa climatério e menopausa obtendo as informações de sintomas, doenças por falta de estrogênio e situação da reposição hormonal.
379. Permitir emissão de relatório dos pacientes programados nas ações programáticas com comparecimento em atraso para fornecimento de medicamentos, consultas e exames.
380. Permitir emissão de relatórios de pacientes e atendimentos realizados dos programas do Ministério da Saúde (HIPERDIA, SISPRÉNATAL e SISVAN) com as informações dos atendimentos de cada programa.
381. Permitir emissão de relatórios de pacientes e atendimentos realizados dos programas saúde da criança, planejamento familiar, climatério e menopausa com as informações dos atendimentos de cada programa.
382. Possuir ferramenta de busca ativa na base de dados do sistema possibilitando a parametrização e o consequente alerta de forma on-line para pacientes que tenham diagnósticos sugestivos, tenham realizado procedimentos indicados como sugestivos, tenham tomado medicamentos sugestivos, tenham tido passagem por UTI, reinternações ou outros indicadores determinados.
383. Permitir parametrizar plano de ação multiprofissional determinando as tarefas de cada tipo de profissional envolvido.
384. Permitir a criação de questionários de atendimento com perguntas e respostas, atribuindo pontuação a cada resposta, devendo o sistema automaticamente classificar o grau de risco do paciente.
385. Permitir atribuir pontuação positiva e negativa para cada resposta estipulada nos protocolos de atendimento a fim de apurar o grau de risco do paciente.

URGÊNCIA/EMERGÊNCIA

386. Recepcionar o usuário e informando o tipo de atendimento, sendo no mínimo os seguintes tipos: Urgência e Emergência, Triagem/Acolhimento, Procedimentos e Enfermaria.
387. Permitir a consultar a fila de usuários aguardando o acolhimento/triagem.
388. Permitir registrar os procedimentos executados durante o atendimento.
389. Permitir ao operador a digitação de laudos e a anexação de arquivos de resultados de exames ao registrar os procedimentos.
390. Permitir o encaminhamento para consultas médicas especializadas.
391. Permitir cadastrar dados de acolhimento tais como: Queixas iniciais, Dados vitais e antropométricos.
392. Permitir cadastrar dados antropométricos coletados durante o período de observação do usuário.
393. Permitir o cadastramento de receituário sendo possível selecionar qualquer medicamento presente na rede pública ou não.
394. Permitir cadastrar o registro de enfermagem, podendo o enfermeiro consultar as prescrições e informar as ações e procedimentos executados.
395. Permitir registrar a dispensação de medicamentos para usuário em atendimento.
396. Permitir consultar usuários que estão em observação.
397. Permitir o cadastramento de solicitação de procedimentos listados pela tabela unificada, para execução e faturamento futuros.
398. Permitir cadastrar alta do usuário para que o mesmo seja liberado e o atendimento finalizado, tendo obrigatoriamente que informar o motivo.
399. Permitir cadastrar condutas médicas e de enfermagem tais como: Registro de Alta, Receita Médica, Encaminhamento, Solicitação de Internação, Declarações e Atestados.
400. Permitir cadastrar pedido de internação informando: Identificação do proponente a internação, Laudo Técnico, Cid, Diagnósticos e demais informações exigidas pelo ministério da saúde.
401. O sistema deve permitir a impressão dos pedidos de procedimento.
402. Permitir a consulta dos usuários aguardando atendimento médico classificado pelo grau de urgência.
403. Permitir consultar o histórico dos últimos atendimentos realizados para o paciente.
404. Permitir controlar as escalas de plantões dos profissionais por especialidades.
405. Permitir o cadastramento de plantões futuros sem limite de tempo.
406. Disponibilizar informações dos plantões separados por especialidades com a possibilidade de disponibilizar em ambiente WEB ou Monitor (TV).
407. Emitir relatório de atendimentos com filtros: por data, por período, por tipo de atendimento, por profissional e por unidade.
408. Emitir gráfico de atendimentos por mês e acumulado no ano.
409. Emitir gráfico de atendimentos bairro.
410. Emitir gráfico de atendimentos por origem.
411. Emitir gráfico de atendimentos por profissionais.
412. Emitir gráfico de atendimentos por grupos de diagnóstico
413. Emitir gráfico de atendimentos por unidade.
414. Permitir a impressão da ficha de atendimento.
415. Permitir a emissão do boletim de atendimento médico.
416. Permitir controlar o protocolo de atendimento de urgência, determinando exames e medicamentos que podem ser solicitados aos pacientes.
417. Controlar o exame físico por protocolo pré-determinado, definindo as questões que devem ser indagadas aos pacientes e os exames físicos a serem realizados nos mesmos, com padrão de respostas pré-definidas nos protocolos.

Autor: VIVVER SISTEMAS LTDA

#	Arquivo

16 -

REQUISITOS:

PRESCRIÇÃO ELETRÔNICA

418. Permitir criar prescrições específicas correlacionando as principais síndromes previstas pelos serviços de saúde. Exemplo: Sepse abdominal/amoxilina-clavulanato, sepse abdominal/piperacilinatazobactan entre outros. Esses padrões somente podem ser editados por gerentes ou coordenadores.
419. Permitir prescrição de antibiótico ou outro medicamento controlado e emissão automática do formulário correspondente de justificativa (ou o envia de modo eletrônico).
420. Permitir, ao prescrever medicamento padronizado, verificar a disponibilidade do item no estoque da unidade, emitindo mensagem de alerta quando estiver indisponível no estoque.
421. Permitir ao realizar a prescrição de imunobiológicos (vacinas, imunoglobulinas humanas, soros), registrando via de administração, unidade de medida, dose, por especialidades médicas (CBO) solicitantes, necessidade de autorização prévia.
422. Permitir parametrizar prescrições de hemocomponentes, exigindo o preenchimento de itens como: unidade de medida, tempo de infusão, por especialidades médicas (CBO) solicitantes, duração do tratamento, regras para cálculo, dentre outros.
423. Permitir, ao prescrever suplementos nutricionais, nutrição enteral e nutrição parenteral, verificar a disponibilidade do item no estoque da unidade, emitindo mensagem de alerta quando estiver indisponível no estoque.
424. Permitir calcular a dose terapêutica, baseado em padrões previamente parametrizados.
425. Permitir realizar a prescrição de soluções, definindo dispositivo de infusão, quantidade de etapas, horário de início das etapas, velocidade de infusão, volume de soluções etc. Exemplo: esquema de soro.
426. Permitir parametrizar prescrições de soluções, exigindo o preenchimento de itens como: dispositivo de infusão, quantidade de etapas, horário de início das etapas, velocidade de infusão, volume de soluções etc.
427. Permitir pesquisar as prescrições por situação (status).
428. Permitir prescrever esquemas alimentares, por usuário do SUS, com check.
429. Permitir definição da lista dos alimentos que poderão ser selecionados.
430. Permitir tramitar solicitação de exame para autorização prévia.
431. Garantir a integração com as demais áreas (Farmácia, SADT, Posto Enfermagem, Agência Transfusional, Nutrição etc.) sob forma de solicitação dos itens prescritos.

SERVIÇOS HOSPITALARES

432. O sistema deve permitir o registro de admissão de internações eletivas e de urgência.
433. O sistema deve gerar automaticamente a pré-internação do paciente a partir do agendamento de uma cirurgia como também da solicitação de internação de pacientes da urgência e emergência.
434. O sistema deve permitir registrar o cadastro da pré-internação do paciente clínico eletivo, ou seja, dos pacientes que não possuem nenhum agendamento de cirurgia previsto como também oriundos da emergência.
435. O sistema deve estar totalmente integrado à agenda de cirurgias eletivas do centro cirúrgico e com as pré-internações clínicas.
436. O sistema deve disponibilizar tela que apresente lista de todos os pacientes com previsão de internação para a data selecionada, o sistema deve apresentar indicação em tela se o paciente possui pendências que podem impedir seu atendimento ou que sirvam de alerta para o setor de internação.
437. Ao registrar o atendimento do paciente, o sistema deverá abrir automaticamente a conta do atendimento no sistema de faturamento de AIH.
438. O sistema deve permitir fazer a emissão dos seguintes documentos:
- Etiqueta de Identificação com Código de Barras;
- Termo de Responsabilidade;
- Anamnese de Internação;
439. O sistema deve disponibilizar painel de leitos gerencial que apresente as taxas de ocupação da instituição em tempo real das unidades de internação e seus respectivos leitos. Nesta tela deve ser apresentada a taxa de disponibilidade, taxa de ocupação e taxa de indisponibilidade. O sistema deve ter uma apresentação gráfica intuitiva das informações dos leitos, com informações de ocupação por unidade de internação, tipo de acomodação, tempo de permanência, especialidade/serviço, médico e faturamento.
440. O sistema deve emitir declaração de paciente internado, declaração de internação e Termo e Alta a pedido.
441. O sistema deve permitir fazer o registro da solicitação e da transferência de leitos entre uma mesma unidade ou para outra unidade de internação.
442. O sistema deve permitir ao usuário fazer o registro de solicitação de dietas avulsas ao serviço de nutrição e dietética do hospital.
443. Permitir controle de dias de permanência de pacientes nas diversas unidades de internação, indicando a diferença de dias autorizados e de dias de internação.

MATERIAL ESTERILIZADO

444. Controlar os lotes dos conjuntos de materiais esterilizados utilizados em cada unidade de saúde.
445. Registrar as entradas dos conjuntos de materiais para esterilização.
446. Permitir o registro da esterilização dos materiais disponibilizando automaticamente para utilização.
447. Registrar as saídas de materiais esterilizados identificando o setor, profissional e lote de utilização.
448. Registrar em cada etapa da esterilização, o método e controle utilizado, o executante e data e horário de realização.

CENTRO CIRÚRGICO

449. O sistema deve permitir o registro do centro cirúrgico, associado ao centro de custo e o horário de funcionamento para todos os dias da semana.
450. Permitir a parametrização de agenda por sala cirúrgica.
451. Cadastro de equipamentos cirúrgicos utilizados no Centro Cirúrgico, com possibilidade de indicação se o equipamento poderá ou não ser compartilhado no mesmo período em duas cirurgias diferentes, visando sua reserva quando do agendamento de uma cirurgia.
452. O sistema deverá possibilitar a desativação/ativação do uso dos equipamentos (para fins de manutenção) e o vínculo da descrição conhecida pela equipe de enfermagem com a descrição constante da tabela de faturamento.
453. Cadastro de salas de cirurgia com determinação do período de utilização, visando o agendamento de cirurgias.
454. Cadastro de instrumentais e de kit instrumental para solicitações junto à Central de Material Esterilizado.
455. Permitir o cadastro:
- dos tipos de anestesias utilizadas pelos profissionais do bloco cirúrgico;
- dos tipos e motivos de partos;
- dos motivos de transferências de cirurgias, do cancelamento de agendamento de cirurgias e de interdição de sala de cirurgia;
- das equipes médicas;
456. Permitir a configuração das equipes médicas, das unidades de sangue e derivados.
457. Agendamento de cirurgias com o cadastro de todas as informações necessárias para realização da mesma: data e hora agendada, data e hora previstas para o término, sala, categoria da cirurgia (eletiva Urgência ou ambulatorial), além de dados do paciente contendo as informações que possibilitem a sua completa identificação, como nome completo, idade. O sistema deve permitir o agendamento para pacientes internados ou não, já cadastrados ou não no banco de dados do hospital.
458. Controle de kit cirúrgico, possibilitando criar kits por procedimento e por profissional.
459. Consulta de agenda de cirurgia, com possibilidade de busca por sala, médico, situação (agendada, realizada, atrasada, suspensa) e data pré-definida, sendo possível a visualização dos dados da agenda (data e hora de início e término da cirurgia, sala, procedimento a ser realizado, médico, paciente e status da cirurgia).
460. Bloqueio de salas de cirurgia com registro de data e hora do início e do término e o motivo do bloqueio.
461. Possuir integração entre o agendamento de cirurgia, a pré-internação e a efetiva recepção do paciente.
462. Permitir realizar pré-agendamento cirúrgico.
463. Permitir, a partir do mapa cirúrgico, lançar todos os materiais e medicamentos que serão utilizados em cirurgias agendadas para datas posteriores.
464. O sistema deve possibilitar no momento da confirmação do ato cirúrgico adicionar outros procedimentos e equipamentos cirúrgicos que não estavam previstos no agendamento, mas que foram necessários a sua realização e utilização no momento da cirurgia.
465. O sistema deve disponibilizar opção para lançar informações do parto tais como: horário do parto, tipo do parto, motivo de parto quando cesariana, motivo de morte do RN quando natimorto, Qtde de nascidos vivos, sexo, Nome do RN, Código da Pulseira, Apgar, Apgar 5 minutos, Exame Físico do RN, Perímetro Cefálico, Perímetro Abdominal, Peso, Altura, Nome da Mãe, Médico Pediatra, No. DNV, data e hora do nascimento.
466. Em caso de parto gemelar o sistema deve permitir o registro de todos os RN's de maneira individual.
467. O sistema deve disponibilizar todas as informações registradas no ato cirúrgico no prontuário eletrônico do paciente de forma automática.

HOTELARIA / CCIH

468.       O sistema deve estar integrado ao prontuário eletrônico do paciente.
469.       O sistema deverá permitir a visualização gráfica dos leitos existentes no hospital a o status de ocupação de cada um.
470.       O sistema deverá permitir controlar e visualizar os leitos disponíveis, ocupados, em manutenção, reservados e em higienização e os percentuais dos mesmos em relação aos leitos existentes.
471.       O sistema deverá permitir controlar o processo de higienização identificando os diversos tipos de higienização realizados no Hospital (terminal, rotina, chamados, etc.).
472.       O sistema deverá permitir controlar o histórico de ocupação de cada leito, indicando os pacientes e o período da ocupação.
473.       O sistema deverá permitir indicar e controlar o rol de roupas existentes em cada unidade.
474.       O sistema deverá permitir controlar o mapa de altas do Hospital, indicando as altas realizadas e as altas previstas.
475.       O sistema deverá permitir bloquear qualquer leito não ocupado, passando o mesmo a não computar para efeito de estatísticas do SAME.
476.       O sistema deverá permitir mudar o padrão da acomodação para enfermaria ou isolamento a qualquer momento.
477.       O sistema deverá possuir módulo de CCIH com conceito de busca ativa, gerando o monitoramento automático para o CCIH dos pacientes em atendimento de acordo com critérios de Diagnósticos sugestivos, uso de antibióticos, resultados de exames laboratoriais, internação em UTI, realização de procedimentos invasivos e pré-internação.
478.       O sistema deverá permitir a geração e o controle dos atendimentos de notificação compulsória gerados pelo CCIH, indicando os atendimentos que já foram notificados e os que se encontram pendentes.
479.       O sistema deverá permitir controlar separadamente os pacientes que estão em processo de vigilância e os que já tiveram sua infecção notificada.
480.       O sistema deverá permitir registrar o agente etiológico à topografia e tipo de infecção e o local de origem para cada paciente que tiver a infecção confirmada.
481.       O sistema deverá permitir acessar o resultado dos exames de antibiograma realizados para os pacientes.
482.       O sistema deverá calcular as taxas de infecção Hospitalar existentes demonstrando graficamente a evolução mensal das mesmas de acordo com parâmetros pré-definidos como unidade de atendimento, especialidades, médicos e topologia.
483.       O sistema deverá permitir criar parâmetros de identificação de notificação interna de diagnósticos que interessem ao CCIH, assim como identificar os diagnósticos de notificação compulsória.

CENTRO DE MATERIAL ESTERILIZADO

484.       Cadastro dos tipos de embalagens com código e descrição.
485.       Cadastro das máquinas esterilizadoras.
486.       Cadastro dos tipos de instrumentais com código, descrição, tempo de esterilização e temperatura.
487.       Cadastro dos tipos de caixas cirúrgicas com código, descrição, tempo médio de esterilização, tempo de volume de produção e quantidade de componentes.
488.       Cadastro dos tipos de esterilização.
489.       Cadastro das localidades do arsenal com código, corredor, prateleira, armário e box.
490.       Cadastro do Motivo de Cancelamento.
491.       Cadastro do Composição de Kits com descrição, tipo de embalagem, setor principal, tipo de instrumental, tipo de esterilização, instrumentais e fotos dos instrumentos de composição, localização do arsenal, quantidade de etiquetas para preparo e etiquetas para esterilização.
492.       Cadastro de Composição de Caixas Cirúrgicas.
493.       Cadastro dos instrumentais cirúrgicos.
494.       Registrar a entrada da caixa e os respectivos instrumentais no expurgo.
495.       Registrar a entrada da caixa e os respectivos instrumentais no processo de desinfecção.
496.       Registrar a entrada da caixa e os respectivos instrumentais no processo de preparo.
497.       Registrar a entrada da caixa e os respectivos instrumentais no processo de esterilização.
498.       Registrar a digitação dos testes físico, químico e biológico.
499.       Registrar a entrada das caixas e os respectivos instrumentais ou dos instrumentais no arsenal.
500.       Registrar a transferência das caixas e os respectivos instrumentais ou somente os instrumentais para o centro cirúrgico.

NUTRIÇÃO E DIETÉTICA

501.       Cadastro de Tipos de Dietas.
502.       Cadastro do Tipos de Refeições.
503.       Cadastro de Orientações de Dietas.
504.       Cadastros dos Pratos.
505.       Cadastro da Classificação dos Cardápios.
506.       Cadastro da opção dos cardápios.
507.       Cadastro dos bicos de mamadeira.
508.       Cadastro de manipuladores de mamadeiras.
509.       Cadastro de copas.
510.       Configuração de leitos por copas.
511.       Configuração de origens x copas.
512.       Cadastro da composição dos pratos.
513.       Registro da ficha nutricional do paciente com dados do atendimento, observações médicas, tipo de dieta, tipo de refeição e observações das refeições.
514.       Registro de Movimentação de cardápios com as informações do tipo de refeição, dados do atendimento, tipo de dieta, copa, observações da nutrição, opções e a quantidade das opções escolhidas do cardápio.
515.       Registro de movimentação de cardápios do lactário.
516.       Registro de solicitações de dietas avulsas para pacientes, médicos, setores, acompanhantes.
517.       Registro do Status da Refeição com horário de fechamento.
518.       Registro de Status do Lactário com horário de fechamento.
519.       Registro do Status de acompanhante com horário de fechamento.
520.       Registrar o planejamento do cardápio.
521.       O sistema deve gerar automaticamente a solicitação de dieta a partir da prescrição médica eletrônica e lançar no mapa com o leito, observações, diagnóstico e orientações da nutrição.
522.       O sistema deve lançar automaticamente no mapa de produção, todas as dietas prescritas pelos médicos.
523.       O sistema deve possibilitar a emissão do mapa de produção de dietas por unidade de internação e tipo de refeição.
524.       O sistema deve possibilitar a emissão de etiquetas das dietas para serem fixadas nas bandejas.

VACINA

525. Deverá ser capaz de registrar todas as imunizações administradas ao cidadão, contendo informações de fabricante, lote, validade, dose, tipo de imunobiológico, ficando estas informações registradas no prontuário do cidadão em campo dedicado a este tipo de registro.
526. Deverá conter ferramenta para registro facilitado de doses de campanha de modo que não seja necessário entrar no prontuário do cidadão para tal, selecionando previamente o imunobiológico a ser utilizado e digitando apenas o nome ou outra informação pessoal de identificação do usuário (como CNS) para o registro da aplicação, de modo a agilizar o registro em campanhas.
527. Deverá conter formas de registrar os eventos adversos pós vacinação e intercorrências com os imunobiológicos (como exposição à temperatura inadequada).
528. Deverá controlar o calendário de vacinação incluindo intervalo mínimo e recomendado entre as doses do mesmo imunobiológico, bem como idade mínima e máxima do cidadão que pode receber a dose, sendo que a plataforma utilizará estes valores para realizar o aprazamento das próximas doses no prontuário do cidadão.
529. Ao se registrar uma dose de campanha no período ideal para a realização de dose normal (rotina), o sistema deverá automaticamente realizar o registro no sistema como dose de rotina.
530. Deverá ser capaz de gerar monitoramento dos cidadãos que não receberam o imunobiológico na data correta (aprazada) minimamente por meio de relatório.
531. Deverá ser capaz de gerar alerta internamente no sistema, voltado ao profissional vacinador e equipe de vigilância sobre a existência de registros atrasados.
532. Deverá permitir a atualização do registro de vacinação do cidadão por meio de inserção manual de registros realizados for a da rede municipal, com destaque de que se trata de atualização manual e não aplicação de imunobiológico.
533. Deverá bloquear ações que não fazem parte do esquema vacinal padrão (doses for a da idade), ficando apenas o usuário com acesso de administrador a essa ferramenta com permissão de inserção de tais informações.
534. Possibilitar a exportação de aplicações e transcrições de vacinas e/ou movimentações de estoque dos imunobiológicos conforme especificações da integração.
535. Possibilitar o controle de frascos por dose ou quantidade definindo as diferentes composições de frascos existentes e respectiva validade.
536. Possibilitar definir a quantidade padrão de doses por ciclo de vida (criança, adolescente, adulto e idoso).
537. Possibilitar a definição das dosagens, respectivos critérios de intervalo mínimo e recomendado em relação à idade inicial e final.
538. Possibilitar a definição de critérios de restrição em relação a outras vacinas definindo intervalo mínimo para aplicação.
539. Possibilitar o descarte dos frascos vencidos calculando quantidade de perda, identificando a data, horário e motivo do descarte.
540. Disponibilizar processo automático para baixas de doses de quando as mesmas forem registradas.
541. Possibilitar a restrição de registro de aplicações de vacinas considerando sexo do usuário.
542. Emitir relatório de aplicações de vacinas realizadas.
543. Emitir relatório de aplicações de vacinas atrasadas, com intuito de busca ativa de pacientes em campanha de vacinação.
544. Realizar baixa automática da vacina no estoque quando integrado.
545. Emitir relatório para busca por usuário com vacinas pendentes, aplicadas e transcritas.
546. Possibilitar a visualização e impressão de carteirinhas de vacinação com aprazamentos e histórico de vacinas aplicadas.
547. Possibilitar o registro das aplicações de vacinas informando data, horário, profissional, especialidade, usuário, identificação de gestante, comunicante de hanseníase, usuário renal crônico, vacina, dosagem, operador e data e horário de inclusão.
548. Possibilitar informar o lote e data de validade.
549. Possibilitar vincular o lote a partir dos lotes existentes em estoque apresentando o saldo individualizado.
550. O sistema deverá permitir criar esquemas vacinais, possibilitando atender o calendário do Ministério da Saúde, estado e do município.
551. Realizar o cadastro das geladeiras para o controle da temperatura.
552. Gerenciar o estoque dos imunobiológicos por setor de forma integrada com o almoxarifado, avaliar consumo, registrar pedido, recebimento e perda.
553. Controlar as geladeiras com registro das variações de temperatura, limpezas e falhas.
554. Permitir o registro dos imunobiológicos visualizando cartão espelho de cada paciente de acordo com a idade.
555. Permitir visualizar, manter e imprimir o formulário de investigação de Eventos Adversos de imunobiológicos em conformidade ao formulário de investigação de Eventos Adversos Pós-Vacinação do Ministério da Saúde. Os dados solicitados na ficha devem ser carregados na mesma quando possuir no Sistema (Dados Usuário, Dados Profissionais, Dados Estabelecimento).
556. Permitir visualizar e manter inativação lógica do registro incorreto da vacina/dose registrada no atendimento ou histórico, para fins de impressão do cartão de vacina.

Autor: VIVVER SISTEMAS LTDA

#	Arquivo

17 -

REQUISITOS:

VIGILÂNCIA EPIDEMIOLÓGICA

557. A plataforma deverá possuir ferramenta para monitoramento dos agravos de notificação, contendo minimamente o agravo, a data dos primeiros sintomas, a data da notificação, sinalização de confirmação ou não, prazo para encerramento da investigação e situação da investigação, incluindo georreferenciamento com plotagem em mapa.
558. A lista de agravos de notificação poderá ser customizada localmente pela CONTRATANTE.
559. A plataforma deverá apresentar um sistema de alerta ao usuário para a notificação compulsória sempre que houver a digitação do CID ou CIAP, nos campos específicos, correspondente a agravos de notificação.
560. A plataforma deverá disponibilizar as fichas de notificação e investigação dos agravos de notificação, boletins de acompanhamento, anexos de monitoramento ou quaisquer outros documentos referentes ao acompanhamento de casos ou contatos de forma editáveis para preenchimento durante o atendimento (a função de notificação deverá estar disponível no momento da assinatura do contrato. as fichas de notificação deverão estar funcionando em até seis meses após a assinatura do contrato. as fichas de investigação e demais funcionalidades descritas neste tópico deverão estar funcionais em até um ano após a assinatura do contrato).
561. Deverá emitir alerta para atualização de endereço e telefone para cada notificação compulsória realizada, não sendo permitido o encerramento/fechamento do prontuário sem a atualização do mesmo ou confirmação de que o endereço e telefone existentes são os corretos.
562. Deverá haver campo específico de observações em texto livre para cada caso/cidadão para preenchimento pela equipe de vigilância no módulo destinado ao acompanhamento dos agravos.
563. Nesta mesma ferramenta supracitada deverá haver campos de interesse para cada um dos agravos (variável pelo agravo) e condizentes com os principais definidos na ficha de investigação (essa ferramenta deverá ser customizada junto à equipe de vigilância e poderá sofrer adaptações
564. O programa deverá emitir alerta para encerramento das investigações pendentes em prazos oportunos para determinado perfil de acesso (trabalhadores da vigilância epidemiológica, inicialmente. posteriormente poderá ser expandido para os trabalhadores de unidades assistenciais diretas no momento da abertura do prontuário. esta funcionalidade deverá estar disponível conforme definições nos sistemas de alerta deste mesmo termo de referência).
565. Permitir realizar o registro e acompanhamento e poder cadastrar novo registro para o paciente.
566. Permitir o georreferenciamento dos agravos dos pacientes no Google Maps.

VIGILÂNCIA SANITÁRIA

567. Deverá ser capaz de possibilitar que todo o processo de emissão de alvará sanitária aconteça sem comunicação direta ou por documento físico entre o solicitante e a vigilância sanitária, desde a solicitação inicial, contendo formulário autodeclarado e dados cadastrais, até a emissão do documento final, passando pelo acompanhamento do processo por ambas as partes.
568. Deverá permitir assinatura eletrônica por ambas as partes (solicitante e vigilância sanitária).
569. No perfil dos funcionários deverá ser configurável pelo menos a: realizar geração, acesso simplificado, consulta detalhada, inclusão de documentos/especificações, tramitação, parecer, assinatura, finalização/encerramento, geração de alertas e geração de laudos para os diversos serviços realizados pelos setores referidos.
570. Possuir estrutura compatível com o CNAE - Cadastro Nacional de Atividade Econômica.
571. O sistema deverá permitir o cadastro de modelos de inspeção sanitária definidos pelo operador.
572. Possibilitar o controle dos alvarás solicitados.
573. Realizar a busca dos estabelecimentos: por razão social, por nome fantasia, por nome do(s) proprietário(s), número do cadastro, número do alvará sanitário, data de validade do alvará sanitário, endereço comercial e telefone(s) de contato.
574. Emitir alvarás sanitários por estabelecimento.
575. Emitir relatório de estabelecimentos por status de alvarás sanitários.
576. Possibilitar controlar e registrar no boletim diário de visitas.
577. Emitir o relatório do boletim de visitas.
578. Possibilitar o registro do cadastro de ocorrências por estabelecimento.
579. Possibilitar realizar o cadastro de denúncias contendo informações do reclamante e do estabelecimento denunciado.
580. Emitir o alvará sanitário e de localização conforme moldes definidos pelo município.
581. Emitir o relatório de ocorrência.
582. Emitir relatório de visitas contemplando área, natureza e estabelecimento.

VIGILÂNCIA AMBIENTAL- CONTROLE DE ENDEMIAS

583. Permitir o reconhecimento geográfico - RG da área urbana do município, por localidades, quarteirões e zonas de trabalho (residências, comércios, terrenos baldios, outros), além dos pontos estratégicos com a possibilidade de atualização diária.
584. Permitir informar estabelecimento de itinerário diário do ACE.
585. Permitir registro da produção diária realizada contendo número do quarteirão, sequência, lado, nome do logradouro, tipo de imóvel (residência, comércio, terreno baldio, outros), hora da entrada, tipo da visita (normal ou resgate), pendência, n° de depósitos inspecionados (A1, A2, B, C, D1, D2, E), coleta de amostra (se houver) com número de tubitos, número de depósitos eliminados, tratamento focal (larvicida – tipo / quantidade em gramas / n° de depósitos tratados), tratamento perifocal (adulticida – tipo / quantidade de cargas).
586. Permitir realizar o resumo do trabalho diário de campo das informações listadas no item anterior.
587. Permitir realizar o roteiro de supervisão de campo.
588. Permitir a realização do Lira, conforme cronograma estabelecido pela SRS com a inclusão dos seguintes dados: sorteio dos quarteirões a serem inspecionados conforme a divisão dos estratos.
589. Incluir na pesquisa do Lira os dados referentes ao trabalho de campo: Número do quarteirão, logradouro, número de recipientes com foco por tipo de recipiente (A1, A2, B, C, D1, D2, E), número de amostras coletadas, número de tubitos.
590. Incluir na pesquisa do Lira os dados referentes ao trabalho de laboratório: número de tubitos examinados com A. aegypti / A. albopictus, número de recipientes positivos por tipo de recipiente (A1, A2, B, C, D1, D2, E).
591. Permitir que cada supervisor realize o consolidado parcial dos extratos do Liraa.
592. Incluir na ficha de solicitação de serviços com os seguintes dados: atendente, data, horário, nome do reclamante, endereço, telefone, referência, solicitação, retorno, ciência do supervisor, ciência do reclamante.
593. Permitir que o supervisor geral controle a frequência dos ACEs sob sua responsabilidade.
594. Permitir a inclusão dos boletins para acompanhamento das ovitrampas com os seguintes dados: Dados gerais: UF, município, ano, localidade, categoria, zona, atividade, semana epidemiológica, armadilha, Atividade realizada: número da armadilha, endereço, número do quarteirão, localização, datas de instalação e coleta, número de tubitos, ocorrência. Para o boletim da parte laboratorial: quantidade de ovos e larvas, espécies identificadas – Aedes aegypti / Aedes albopictus / outras.
595. Permitir realizar a inclusão de atividades educativas realizadas, com relatório da atividade e fotos.
596. Emitir relatórios dos casos de dengue notificados no município.
597. Emitir relatório dos focos de dengue encontrados no município.
598. Emitir relatório das ovitrampas positivas no município.

FATURAMENTO AMBULATORIAL E HOSPITALAR

599. Permitir a importação manual das definições da tabela SIGTAP do Ministério da Saúde, possibilitando selecionar os arquivos das competências a partir do repositório do DATASUS e realizar a importação das regras de faturamento de procedimentos do SUS.
600. Permitir a importação manual das definições da tabela SIA/SUS do Ministério da Saúde, possibilitando selecionar os arquivos das competências a partir do repositório do DATASUS e realizar a importação das regras de faturamento de procedimentos do SUS.
601. Gerar automaticamente com base nos atendimentos realizados o arquivo magnético para Boletim de Produção Ambulatorial conforme especificações do Ministério da Saúde, permitindo a seleção das unidades para geração.
602. Possibilitar na geração dos arquivos BPA que os mesmos possam ser incluídos de forma consolidada e individualizada.
603. Possibilitar a reapresentação da produção conforme portaria do Ministério da Saúde, em até 3(três) competências anteriores.
604. Possibilitar importar o arquivo gerado no programa BPA magnético para o sistema do município.
605. Possibilitar gerar produção do município, incluindo a produção dos prestadores.
606. Emitir relatório de toda produção gerada do município conforme SIA-SUS, com no mínimo os campos seguintes: tipo de registro do BPA, competência, unidade, grupo, subgrupo, forma de organização, procedimento, valor e quantidade.
607. Consistir procedimentos no momento da realização quanto aos critérios definidos pelo Ministério da Saúde: sexo, idade, especialidade das unidades de saúde.
608. Permitir o registro direto da produção BPA, por unidades de saúde de modo retroativo, devido a problemas na sua estrutura ou fluxo de atendimento.
609. Realizar o faturamento dos procedimentos de alto custo e hospitalares, nos moldes definidos pelo Ministério da Saúde.
610. O faturamento de internação hospitalar AIH deverá contemplar a criação de subcontas para uma determinada internação, devido à alta frequência de mudança de procedimentos que possam ocorrer na Média e Alta Complexidade.
611. O sistema deverá prever rotinas para realizar gestão de APAC – Autorização de Procedimentos de Alta Complexidade, permitindo acesso através de diferentes perfis parametrizáveis para: solicitante, autorizador, administrativo, executante e faturamento dos procedimentos ambulatoriais.
612. Gerar relatório relativo a prazos relacionados à reapresentação de AIH's.

REGULAÇÃO

613.       O módulo de regulação deverá ser capaz de receber os encaminhamentos automaticamente gerados a partir do prontuário eletrônico bem como por inserção direta no módulo, sendo primeiramente apenas classificados pela data de inserção, sem distinção da forma como foram inseridos (demonstrar essas duas formas – por prontuário e diretamente).
614.       Deverá obrigatoriamente conter duas formas de organização das agendas, de modo que vagas possam ser atribuídas de maneira distinta e não conexa a uma fila não regulada (agendamento automático pelo sistema conforme disponibilidade de vagas) e outra fila completamente regulada (agendamento pelo profissional regulador) para a mesma especialidade.
615.       Deverá possibilitar a inserção personalizada pela CONTRATANTE de critérios de classificação e subclassificação a partir de dados clínicos, sendo este último completamente vinculado em grau hierárquico inferior ao primeiro (demonstrar critérios de subclassificação em uma mesma fila, sendo, minimamente: classificação de risco e algum outro (gestante, idoso, etc.), sendo mantida a classificação de idade como critério último, nesse caso.
616.       Deverá permitir ao profissional regulador a classificação individualizada (ordenação de prioridade) de cada solicitação inserida na fila de regulação. A configuração da ferramenta de classificação deve conter minimamente os seguintes parâmetros:
617.       Classificação de risco por meio de dados clínicos.
618.       Profissional executante, no caso de usuários que já estejam em acompanhamento especializado.
619.       Período pretendido para agendamento, no caso de retornos de usuários em acompanhamento.
620.       Tipo de atendimento pretendido (consulta de primeira vez ou consulta de retorno).
621.       Deverá permitir que a liberação de vagas para a fila não regulada aconteça de forma automática (sem intervenção humana) e de forma individual (manual) ou por lote de vagas (em bloco) para a fila regulada.
622.       A visualização de agenda e o processo de agendamento automático de vagas devem permitir parametrização no tocante a “dias de visualização de vagas” (primeira vez, retorno, vagas reguladas e vagas de fila cronológica), “número mínimo de dias para agendamento” (primeira vez, retorno, vagas reguladas e vagas de fila cronológica), “número de dias para cancelamento antes da consulta” (com diferenciação para vagas utilizadas pelo próprio município e para outros) e “horário de utilização do sistema pelos operadores” (dias da semana e horário mínimo e máximo), de maneira semelhante às funcionalidades existentes no SISREG (Sistema Nacional de Regulação) à data da confecção deste termo de referência assim como outros parâmetros definidos pela contratante.
623.       O cancelamento do agendamento por aplicativo específico pelo cidadão acarretará na reintegração da vaga ao quantitativo de origem de cada serviço ofertado.
624.       O controle de disponibilidade de vagas para agendamento deverá estar submetido à configuração de teto físico (quantidade bruta), teto financeiro ou ambos conjuntamente, configuráveis por cada procedimento pela CONTRATANTE a qualquer momento.
625.       A nomenclatura das agendas a serem consumidas pelo módulo de regulação será plenamente configurável pela CONTRATANTE.
626.       Deverá permitir a configuração das escalas de agendamento pela CONTRATANTE com a inclusão de dados mínimos como: nome do profissional, local, horário do atendimento, sendo que este horário poderá ser com tempo pré-estabelecido e exato para a consulta (1 cidadão por vez) ou o mesmo para todos os cidadãos a serem atendidos no período.
627.       Deverá permitir a possibilidade de configuração das agendas para suspensão temporária personalizada para cada serviço ofertado, seja ele um estabelecimento de saúde e toda a sua oferta de serviços ou a agenda de um profissional específico.
628.       Deverá permitir a transferências de agendas completas para períodos diferentes do originalmente configurado.
629.       Deverá permitir a configuração individualizada e variável de teto físico e financeiro disponível a cada município solicitante conforme programação pactuada integrada regional, permitindo a emissão de relatórios mensais para controle desses agendamentos.
630.       Deverá permitir inclusão de cotas por unidade solicitante e por procedimento a ser configurada pela CONTRATANTE por meio de ferramenta administrativa.
631.       Todos os procedimentos e/ou grupos de procedimentos poderão ter suas disponibilidades habilitadas ou não para cada unidade e/ou grupo de unidades no momento da solicitação, a critério da CONTRATANTE.
632.       Deverá permitir a inclusão de observações individualizadas por procedimento como orientações de preparo ou endereços alternativos de estabelecimento cujo texto deve estar visível nas autorizações destes procedimentos, sejam elas físicas (impressas) ou digitais (aplicativo/portal).
633.       Deverá permitir na configuração das escalas dos profissionais que atenderão às agendas, a divisão entre vagas externas (a serem consumidas pelo sistema de regulação) e vagas internas (a serem consumidas pelo próprio serviço, sem passar novamente pela regulação).
634.       Deverá permitir a configuração de parâmetros de proximidade territorial entre cada unidade solicitante e prestadores de serviços (próprios ou contratualizados) de forma que as vagas disponíveis para agendamento automático sejam consumidas de acordo com a proximidade entre a solicitante e o prestador.
635.       Deverá possuir sistema de busca que contemple, minimamente, os filtros de código da solicitação (chave primária). cartão nacional de saúde (CNS). nome completo do cidadão. procedimento (código ou nome). status do procedimento: pendente, agendado (por tipo de fila), cancelados, com confirmação de execução, sem confirmação de execução. unidade executora, unidade solicitante, município e data da inserção, sempre com demonstração de listagem e totalizadores simplificados.
636.       Deverá permitir ao prestador de serviço (próprio ou contratualizado) a confirmação da execução do procedimento por meio de inserção de contra chave única gerada para o cidadão no momento do agendamento do procedimento, ou por meio de biometria.
637.       Quando o usuário não comparecer ao atendimento agendado pelo sistema, a não confirmação pelos meios descritos acima deverá constar como registro de texto no prontuário o horário e data previstos (agendado) para a execução do procedimento.
638.       Deverá disponibilizar painel para visualização simplificada do quantitativo de vagas configuradas por prestador de serviço, permitindo filtros de visualização para tipo de vagas disponíveis conforme configuração prévia da agenda (vagas de primeira vez, de reserva, de retorno ou para consumo interno) e situação de consumo de vagas por período (em tempo real ou para relatórios de monitoramento).
639.       Deverá permitir que as solicitações devolvidas à Unidade solicitante após análise do profissional regulador sejam encaminhadas internamente no sistema para o profissional solicitante quando o mesmo for usuário do módulo de prontuário eletrônico integrante do sistema. Neste caso, ele pode ser a equipe de referência do usuário ou o próprio profissional especialista focal no caso de procedimentos solicitados pelas policlínicas do município. No caso de encaminhamentos externos inseridos manualmente a devolução deverá ser encaminhada ao profissional responsável pela inserção no sistema (este último ponto não avaliado na POC).
640.       Deverá contemplar cálculo para estimativa de tempo médio de espera por procedimento, sendo que o algoritmo para tal será definido a posterior junto à contratante.
641.       Deverá ser capaz de expor publicamente, a partir de critério definidos pela contratante e adequados à legislação, a fila de espera para os procedimentos, com adição dos procedimentos devolvidos não contemplados, tanto na plataforma do usuário quanto pelo aplicativo, além dos acessos dos profissionais de saúde (regulação e profissionais da assistência) (visualização da exposição da fila em plataforma do usuário na POC, minimamente).
642.       Dispor de cadastramento de feriados e dias facultativos diferenciando a sua origem (municipal, estadual e nacional), alertando no cadastro da agenda.
643.       Dispor na montagem das agendas as definições e regras do gestor como: colisão de horários, colisão de locais e controle das cotas por estabelecimento.
644.       Possibilidade de informar o tipo de atendimento: consultas, retornos, reserva técnica, entre outros.
645.       Dispor de um processo de agendamento automatizado da fila de espera com base nas agendas cadastradas, respeitando as regras de prioridade e a posição do paciente.
646.       Permitir visualizar as listas de espera e realizar o agendamento com base nas agendas cadastradas para as consultas ou exames oferecidos dentro da rede.
647.       Permitir visualizar as listas de espera e realizar o agendamento para as consultas ou exames oferecidos fora da rede.
648.       Possibilidade de reimpressão de comprovantes do agendamento.
649.       Dispor de Lista de Espera de solicitações (exames e consultas) que devem ser regulados, tendo no mínimo as seguintes opções: (i) Encaminhar paciente para fila de espera com opção de alterar a prioridade com justificativa (ii) Possibilitar devolver informando a justificativa.
650.       Dispor de gestão dos agendamentos em todos os estabelecimentos de saúde.
651.       Permitir consultar a posição do usuário SUS na lista de espera por especialidades não agendadas.
652.       Possibilitar o controle de contratos dos prestadores por serviços realizados, permitindo selecionar os procedimentos que serão contratados.
653.       O sistema deverá possibilitar a criação das agendas dos serviços contratados, por horários fixo ou variados dos dias da semana.
654.       Permitir o agendamento da solicitação do serviço nas agendas criadas do município.
655.       Possibilitar regular as solicitações dos serviços de acordo com a justificativa informada, mantendo o histórico do fluxo, possibilitando alterar a prioridade da solicitação na fila de espera.
656.       Possibilitar o controle dos saldos financeiros dos municípios referenciados pela PPI.
657.       O sistema deverá ter um mecanismo de configuração de regras de agendamento, permitindo a parametrização das prioridades na hora do agendamento automático (ex: unidade mais perto do paciente, tipo de estabelecimento ”público ou prestador”, tipo de agenda, etc.).
658.       Possuir funcionalidade para cadastro de documentação por: profissional e/ou paciente.
659.       Permitir o registro de documentação necessária por procedimento solicitado.
660.       Deve possuir funcionalidade para cadastro de motivos: agendamento, avaliação de solicitação, bloqueio e cancelamento de agendamentos, finalização do atendimento e outros.
661.       Permitir controle físico de saldos da PPI.
662.       Possuir visualização simplificada de consumo dos saldos de contrato dos prestadores.
663.       Possuir parametrização que anteceda ao agendamento do tipo: obrigar endereço completo, obrigar CNS do paciente, obrigar telefone e obrigar primeira consulta para retorno.
664.       Permitir unificação de prontuários de pacientes em caso de pluralidade de registros.
665.       Deve contemplar diferentes perfis de acesso nos seguintes moldes: Administrativo CRL (interno) - realiza cadastro de pacientes e das solicitações de internação. Regulador CRL (interno) - regula as internações e movimentações (autoriza, nega, solicita complementação de informações, coloca em lista de espera, etc), Prestador (externo) - complementa informações solicitadas para regulação, realiza as internações, movimentações e altas dos pacientes autorizados e Municípios Pactuantes (externo) - realiza as solicitações de internação e complementa as informações solicitadas para regulação.
666.       Permitir o cadastramento de setores do estabelecimento de saúde, contendo no mínimo nome, situação (ativo ou inativo) e estabelecimento de saúde ao qual pertence - buscar a partir do cadastro do CNES, todos os campos são de preenchimento obrigatório. Deve permitir realizar manutenção neste cadastro.
667.       Permitir o cadastramento de tipo de leito, contendo no mínimo nome e situação (ativo ou inativo), ambos obrigatórios.
668.       O sistema deve trabalhar com a idéia de solicitação de leitos para internação, as solicitações poderão ser feitas internamente - pelo CRL ou externamente pelos estabelecimentos prestadores autorizados ou municípios pactuantes.
669.       Deve permitir registrar uma observação junto com a solicitação de leito.
670.       O sistema deve prover rotina para troca eletrônica de informações entre o solicitante e a CRL, para que a CRL possa iniciar o processo de regulação da internação dentro de cada solicitação, armazenando usuário, data e hora.
671.       O sistema deve fornecer rotinas para otimizar a regulação de solicitações de urgência/emergência e solicitações eletivas que já tenham se efetivado em internações.
672.       Todas as alterações feitas em uma solicitação devem ser registradas dentro da própria solicitação (Histórico da Solicitação), visto que faz parte do processo de trabalho o acompanhamento de tudo que ocorre com cada solicitação lançada no sistema.
673.       O sistema deve prever rotinas para realizar a regulação de solicitações de internação em leitos, possibilitando a apenas perfis previamente configurados (regulador) autorizar ou negar as solicitações conforme avaliação clínica, alterando o status da solicitação e informando o motivo de indeferimento (quando for o caso).
674.       O sistema deve permitir que uma solicitação regulada e autorizada, enquanto aguarda liberação de leito para internação, possa ser colocada e removida de uma lista de espera interna da CRL.
675.       Para as solicitações autorizadas é necessário um controle posterior que libere efetivamente a internação, estando a partir desse momento disponível para o estabelecimento prestador realizar a internação do paciente.
676.       A autorização de internação pode ser gerada por qualquer perfil interno (administrativo e regulador) depois que houve a regulação e prévia autorização de internação por parte do regulador.
677.       Cada autorização de internação só poderá ser utilizada uma única vez e no tipo de leito para o qual ela foi autorizada.
678.       Permitir identificar a realização de exames em gestantes e critério de urgência.
679.       Permitir manter protocolos clínicos específicos para cada procedimento, contendo informações que devem ser preenchidas pelo usuário do sistema quando da criação de uma solicitação para um determinado procedimento.
680.       Permitir manter protocolos de priorização específicos para solicitações ambulatoriais, internações eletivas e internações de urgência, parametrizados por procedimentos ou agrupamentos de procedimentos.
681.       Permitir parametrizar níveis de alerta para a quantidade de solicitações em determinada situação e permitir exibir alertas para usuários do sistema com perfis específicos em caso de os níveis de alerta serem atingidos.
682.       Permitir tramitar os processos de controle e avaliação hospitalar e ambulatorial a partir dos devidos instrumentos de cobrança (AIH para o hospitalar e BPA, APAC e RAAS para o ambulatorial, ou substituto conforme previsão), cujo ciclo de vida contenha desde o momento inicial da criação do instrumento de cobrança até a efetivação do processamento da mesma no sistema específico disponibilizado pelo Ministério da Saúde.
683.       Permitir importação de dados resultantes do processamento de AIH’s no sistema SIHD, refletindo o status de autorização do mesmo nas AIH’s no sistema.
684.       Permitir importação e exportação de dados de instrumentos de cobrança ambulatorial (BPA, APAC e RAAS) no formato dos respectivos sistemas de preenchimento disponibilizados pelo Ministério da Saúde.

CONTROLE E AVALIAÇÃO

685. Deverá permitir a gestão de contratos, desde o momento de cadastro do prestador e respectivo contrato, programação orçamentária, controle de saldos, até o registro do pagamento do mesmo, com competência padrão mensal.
686. Deverá permitir que seja feita a sinalização, para controle de produção e pagamento, de prestadores de serviço vinculados a uma unidade própria, como terceiro.
687. Deverá ser permitida a inclusão de valores complementares àqueles da tabela nacional de procedimentos, de modo que seja possível acompanhar ambos separadamente em todo o processo, incluindo o faturamento em separado.
688. Para fins de processamento e faturamento, a plataforma deverá possibilitar a sinalização manual de quais prestadores/serviços são próprios e quais são terceirizados (credenciados).
689. Deverá possuir internamente todo conjunto de regras definidas pela legislação vigente, regras internas dos sistemas governamentais e processos internos para críticas à produção (como tabela de procedimentos, registro de estabelecimentos e profissionais, teto físico e financeiro, etc.), de modo que, sempre que aplicável, o impedimento acontece já no momento do registro de atendimento (demonstrar na POC bloqueio de registro se o profissional não estiver com CBO correto, se a unidade não estiver com habilitação/classificação correta, e se o procedimento for registrado acima do teto físico ou financeiro).
690. Deverá ser permitida a correção manual das críticas diretamente no sistema, sempre que aplicável, de modo a liberar o processamento adequado para os casos em que a crítica não corresponder ao processo real.
691. Deverá permitir o redirecionamento de produção, de modo que os procedimentos registrados em determinada unidade possam ser direcionados antes do processamento final para outra unidade.
692. Permitir a baixa automática da programação hospitalar conforme autorização da AIH.