Jornal Oficial Eletrônico dos Municípios do Estado de Mato Grosso

ITEM	DESCRIÇÃO
1	SERVIÇO DE LOCAÇÃO DE SOFTWARE INTEGRADO PARA GESTÃO DE SAÚDE PÚBLICA MUNICIPAL NOS INSTRUMENTOS DE GESTÃO DE SAUDE PUBLICA, SENDO NA ATENÇÃO BÁSICA, SALA DE VACINA,MEDIA E ALTA, COMPLEXIDADE, GESTÃO HOSPITALAR, SALA DE RADIOLOGIA REGULAÇÃO, ASSISTENCIA FARMACÊUTICA,VIGILANCIA EM SAUDE, (CONTROLE E AVALIAÇÃO E VIGILANCIA EM SAÚDE, (VIGILANCIA SANITARIA), DENTRE OUTRAS NECESSIDADES INERENTES AO SUPORTE DA GESTÃO DE SAUDE DO MUNICIPIO DE JURUENA-MT DEVENDO POSSUIR MECANISMOS PARA INTEGRAR OS SISTEMAS DISPONIBILIZADOS PELO MINISTÉRIO DA SAÚDE (E-SUS/SISAB, CADWEB, BPA MAGNÉTICO, CNES, SIA, SI-PNI, BNDASAF, SIGTAP, RPOM, RAAS),(SIM,SINASC,SINON-NI,SINAN-DENGUE) E RODAR SOBRE SERVIDORES DE PAGINAS DE INTERNET (ON-LINE) E INTRANET (OFF-LINE)
	IMPLANTAÇÃO DO SISTEMA PARA GESTÃO DE SAÚDE PÚBLICA, SENDO NA ATENÇÃO BÁSICA, MEDIA E ALTA COMPLEXIDADE, GESTÃO HOSPITALAR, REGULAÇÃO, ASSISTENCIA FARMACÊUTICA, CONTROLE E AVALIAÇÃO E VIGILANCIA EM SAÚDE, DENTRE OUTRAS NECESSIDADES INERENTES AO SUPORTE DA GESTÃO DE SAUDE DO MUNICIPIO DE JUURENA-MT

4 DA DOTAÇÃO ORÇAMENTÁRIA 4.1 As despesas correrão à conta de dotação orçamentária, indicada no momento oportuno, nos processos administrativos de utilização de Ata; 5 CARACTERÍSTICAS GERAIS DO SISTEMA

ITEM	DESCRIÇÃO
1	A solução ofertada deverá ser capaz de rodar sobre o ambiente tecnológico existente na CONTRATANTE. O sistema de gestão de saúde ofertado deve ser desenvolvido para rodar sobre servidores de páginas de internet e ser acessado através de navegadores de internet e/ou intranet, não podendo ser instalado nenhum programa desktop nem a utilização de qualquer tipo de emulador. A ferramenta ofertada deve ser compatível com os navegadores Mozilla Firefox, Chrome e Ópera, em suas versões atuais
2	O sistema deverá ser multiplataforma, ou seja, deverá estar homologado minimamente para mais de um SGBD – Sistema Gerenciador de Banco de Dados, Oracle 11G ou superior, PostgreSQL 9.4, Firebird 2.5/3.0 ou superior. Caso a opção de uso de Gerenciamento de Banco de Dados seja licenciado, o custo de aquisição ficará por conta da CONTRATADA, sem ônus adicional para a CONTRATANTE
3	A solução deverá contar com DashBoards Gerenciais, vinculados a modulo de B.I, onde poderá ser efetuado consultas instantâneas quanto aos dados previamente armazenados do sistema, devendo inclusive mostrar em tempo real qualquer dado solicitado aos módulos do sistema
4	A solução, assim como seu (s) respectivos bancos de dados e demais demandas necessárias à sua plena operação, deverão estar implantados em nuvem, tendo que manter de forma automática suas rotinas de backup e atualizações, assegurando a disponibilidade e guarda das informações e sistemas envolvidos. Sendo que todo ambiente de Gerenciamento de Banco de Dados e Servidor (es) envolvidos, deverão estar devidamente licenciados quando necessários e o custo de aquisição e manutenção dos mesmos ficará por conta da CONTRATATADA, sem ônus adicional para a Contratante. Por se tratarem de dados sigilosos, a CONTRATADA, torna-se responsável legalmente pela guarda das informações
5	O sistema de gestão de saúde ofertado deve ser desenvolvido para rodar sobre servidores de páginas de internet e ser acessado através de navegadores de internet, sem a utilização de qualquer tipo de emulador ou plug-in. A solução ofertada deve ser compatível com os navegadores Mozilla Firefox, Chrome e Ópera, em suas versões atuais.
6	Devera possuir dicionário de dados completo e discriminatório de todos os bancos de dados e tabelas do respectivo sistema
7	O sistema WEB deverá estar homologado para operar através de navegadores como: Internet Explorer, Mozilla Firefox, Google Chrome etc., não sendo permitido a instalação de quaisquer outros aplicativos nas máquinas clientes, nem utilizado emuladores, exceto suas instalações nos servidores
8	O sistema deve realizar exclusão lógica de registros. Ao realizar uma ação de exclusão de um registro, este não deve ser removido fisicamente do banco de dados.
9	O Sistema deve possuir cadastro de cidadão compatível com modelo adotado pelo DATASUS padrão CNS (Cartão nacional do SUS)
10	Deverá permitir importação e atualização da Tabela SIGTAP, garantindo o faturamento dos procedimentos padrão Ministério da Saúde.
11	O Sistema deverá permitir interoperabilidade com os seguintes programas do Ministério da Saúde: faturamento do SIA-SUS/BPA (módulo consolidado e individualizado) com todas as informações necessárias para geração em meio magnético, CADWEB, APAC, SISAIH-01, SI-PNI, E-SUS, Hórus,BNDAF,CNS , SISAB, SISRG,SIM,SINASC,SINPN-NI,SINAN-DENGUE
12	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 a Saúde da Família (NASF), serviços, especialidades, etc.
13	Permitir cadastrar novas unidades de saúde, com todos as configurações padrão CNES
14	Armazenar registro de auditoria das transações, mantendo o histórico de inserção, alteração e exclusão (Exclusão Lógica)
15	Possuir tela para controle e armazenamento os logs de erro do sistema em tabela de banco de dados
16	Permitir realizar pesquisa fonética, facilitando na identificação do paciente em quaisquer módulos do sistema
17	Onde houver a necessidade da identificação do paciente dentro de um modulo do sistema, deve ser permitido a realização de busca por CNS, nome do paciente, nome social, data de nascimento e nome da mãe
18	O Sistema deverá possuir menu de acesso rápido através de botões padrão touchscreen para toque na tela
19	Deverá possuir campo de pesquisa para busca de módulos, relatórios, etc.
20	Deverá permitir adotar logotipo da CONTRATANTE na tela principal do sistema
21	Deverá exibir de forma clara a versão utilizada, diretamente na tela de início sem a necessidade de pesquisar em outras fontes, aplicativos, etc.
22	Possuir administração de configurações mínimas do CONTRATANTE: Parametrização de procedimentos de atendimento Parametrização de impressões de guias * Parametrização de configurações básicas para utilização do sistema
23	O sistema não deve liberar nenhum tipo de solicitação, requisição, inclusão em listas para pacientes inativos
24	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
25	Permitir controle de grupos de acesso, perfis e permissões para o usuário do sistema
26	Permitir vincular dados padrões para o perfil do usuário, gerando o preenchimento automático de informações em determinados módulos do sistema de acordo com seu nível de permissão
27	No momento em que o usuário realiza o login, ele terá a opção de escolher qual o perfil e estabelecimento será utilizado, os acessos devem respeitar o perfil definido para o usuário no estabelecimento selecionado
28	Permitir criar procedimento, desvinculado da tabela SIGTAP
29	O sistema deve dispor de rotina para realizar a importação do Cadastro de Ocupações – CBO, a partir da importação SIGTAP, deve ser possível realizar manutenção no cadastro
30	O sistema deverá atender a todos os estabelecimentos de saúde ligados a Secretaria Municipal de Saúde (próprios e contratados), caracterizando um sistema multi-estabelecimentos, onde as alterações de parâmetros e regras de um estabelecimento não influenciem no funcionamento do sistema para os demais
31	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
32	Possibilitar interoperabilidade com outros sistemas por meio de serviços baseados em API REST
33	Deverá possuir dicionário de dados com todas as tabelas do sistema
34	Permitir customizar cabeçalho e rodapé das guias
35	Sistema deverá disponibilizar cadastro de avisos, definindo período da notificação e armazenando o histórico dos avisos já expirados
36	Auditoria de uso do sistema, onde seja possível ver todas inclusões ou alterações feitas nos seguintes módulos: agendamento de consulta e exame, convênio, profissional, unidade de saúde, contrato de prestador e paciente, permitindo minimante visualizar a data da revisão, tipo de revisão e qual usuário alterou o item
37	Ao fim do contrato a empresa CONTRATADA deverá deixar o sistema funcionando para todo tipo de consulta aos dados nele já lançado, uma vez finalizado o contrato, todas as atualizações, suporte, chamados, ou qualquer outra coisa referente ao sistema será finalizado, ficando apenas o sistema na última versão do término do contrato, sem opções de acrescentar, excluir, alterar ou qualquer outro tipo de modificação nos dados existentes. Ficando somente a opção de consulta e visualização das informações
38	Os itens que não forem contemplados no descritivo deste sistema como funcionalidades e/ou relatórios serão solicitados a empresa contratada e a mesma deverá apresentar o cronograma para o desenvolvimento e execução dos itens, cabendo a contratante aprovar ou reprovar desde que a CONTRATADA nos forneça documento com motivos da reprovação da personalização. A CONTRATANTE fica na condição de avaliar os motivos da reprovação e de aceitá-los ou não
39	A CONTRATADA deverá manter um consultor ou equipe local durante a implantação e treinamento do sistema, posterior a este período o suporte será oferecido por demanda
40	O Backup do banco de dados é de propriedade exclusiva do município e sua extensão deverá ser SQL
41	A empresa participante deve atender 100% dos módulos aplicados neste Termo de Referência
42	A solução ofertada deve possuir certificação SBIS com nível mínimo de segurança NGS2, em conformidade aos requisitos mandatórios definidos na Certificação para Sistemas de Registro Eletrônico em Saúde (S-RES) fornecidos pela SBIS e pelo CFM (Sociedade Brasileira de Informática em Saúde e Conselho Federal de Medicina) e deve possuir mecanismo de assinatura digital de registro eletrônico em saúde em conformidade com os padrões de assinatura digital determinados pelo manual de certificação S-RES

6 MÓDULOS CADASTRAIS

PACIENTE
ITEM	DESCRIÇÃO
1	O sistema deve permitir o cadastro de pacientes minimamente com os seguintes campos (Nome, nome social, data de nascimento, sexo, telefone, raça e cor, nome da mãe, nome do pai, número CNS, CPF e endereço)
2	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
3	Permitir registrar o número do prontuário do paciente em diferentes estabelecimentos de saúde
4	Permitir armazenar o número do cartão nacional de saúde (CNS) definitivo e provisórios
5	Possibilitar anexar documentos do paciente, em formato de imagem JPG, JPEG, PNG ou arquivo PDF, para posterior visualização
6	Deve ser permitido o bloqueio de um cadastro de paciente informando o motivo do bloqueio
7	Para o paciente que já possua agendamentos de consultas e exames, o sistema de informar ao usuário sobre esses agendamentos futuros e permitir o cancelamento dos compromissos do paciente no ato do bloqueio
8	Exibir no próprio cadastro, as alergias do paciente
9	Permitir a localização geográfica do endereço do paciente
10	Deve permitir imprimir cartão do cidadão com opção de selecionar mais de um modelo de cartão
11	Possui menu para agendamento rápido de: consultas, exames, lista de espera e triagem
12	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
13	Deverá permitir 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)
14	A partir do resultado da busca do cartão SUS (PIX/PDQ), deverá permitir cadastrar ou atualizar um paciente no sistema
15	Permitir cadastro de biometria para identificação do paciente, possibilitando o registro dos 10 digitais
16	Permitir identificação/busca do paciente por meio de biometria para qualquer digital cadastrada
17	Emitir relatórios de pacientes Sintético e Analítico por: Localidade, Cadastros atualizados e Cadastros duplicados
18	Emitir relatórios sintético e analítico de pacientes por localidade
19	Emitir relatório de pacientes com dados cadastrais inconsistentes com o padrão e-sus
20	Emitir relatório de pacientes com informações de cadastro e/ou atualização
21	Emitir relatório de pacientes duplicados

CADASTROS BÁSICOS
ITEM	DESCRIÇÃO
1	Cadastro de Raça e Cor
2	Cadastro de Tipos de Bloqueio do Paciente. Deve possuir parametrização para permitir definir se o bloqueio acarretará o cancelamento dos agendamentos futuros
3	Cadastro de Religião
4	Cadastro de Grau de Instrução
5	Cadastro de Órgão Emissor RG
6	Cadastro de Etnia
7	Cadastro de Profissão/CBO
8	Cadastro de Comunidade Quilombola
9	Cadastro de Grau de Instrução
10	Cadastro de Vínculo Empregatício
11	Cadastro de Órgão de Classe
12	Permitir acesso a toda lista do CID10, pesquisando por código ou descrição e filtrando os ativos/inativos e aqueles de notificação obrigatória.
13	Permitir cadastrar um novo CID com código, abreviação, classificação, filtrar grupo de CID, tipo de notificação (24 horas, anotação), tempo de notificação, Sexo, reação adversa e campos para marcação de Notificação Obrigatória, DST, Obriga investigação e notificação única.
14	Permitir configurar protocolos de condutas por CID, anexando arquivo com protocolo do tipo .pdf. Permitir que este protocolo seja exibido no atendimento médico sempre que for prescrito o referido CID na hipótese diagnóstica.
15	Cadastro de alergias relacionado com o CID. Deve possuir campo de observação para descrição detalhada da alergia.
16	Permitir cadastrar de tipo de condição de posse ou uso da terra, imóveis e domicílios com filtros busca para área, microárea, risco familiar e condição (somente membros ativos, somente inativos, etc.) e visualização de colunas com: inscrição imobiliária, endereço com rua, complemento, quadra, lote, proprietário, nº da família e Risco (baseado na estratificação de Risco familiar SAVASSI/COELHO)
17	Permitir configurar protocolos com relação pré-determinada de listagem de medicamentos. Este protocolo servirá como plano receituário com produtos relacionados a uma condição de saúde, a partir da prescrição médica no prontuário Eletrônico. Ex.: Hipertenso (definir medicamentos pré-definidos para este tratamento)
18	Permitir configurar protocolos com relação pré-determinada de solicitação de exames (laboratoriais e de imagem). Este protocolo servirá como plano diagnóstico com os exames relacionados a uma condição de saúde, a partir da solicitação no prontuário Eletrônico. Ex.: Gestante (definir exames pré-definidos com finalidade diagnóstica)

UNIDADES DE SAÚDE
ITEM	DESCRIÇÃO
1	Permitir cadastrar de unidades com informações padrão CNES contendo informações: Número do CNES, nome, razão social, mantenedora, tipo do estabelecimento, situação, telefone, endereço, caracterizações, estruturas administrativas, serviços e habilitações
2	Deve permitir cadastrar os setores existentes dentro do estabelecimento de saúde
3	Deve permitir configurar os procedimentos que o estabelecimento pode realizar
4	Deve permitir gerenciar as equipes e os membros das equipes vinculadas ao estabelecimento de saúde
5	Deve permitir atualizar as equipes e membros manualmente, sem a necessidade de uma importação do arquivo CNES.xml

PROFISSIONAL
ITEM	DESCRIÇÃO
1	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 emissão e validade (gera alerta para motoristas cadastrados a realizar viagens no módulo de agendamento de viagens), se profissional aplicador de vacinas padrão SIPNI
2	Deve conter campo para cadastrar o nome do profissional que será exibido nas mensagens enviadas por SMS
3	Possibilitar anexar documentos do profissional, em formato de imagem JPG, JPEG, PNG ou arquivo PDF, para posterior visualização
4	Deve permitir gerenciar as agendas dos profissionais, podendo configurar as agendas por semana, período entre datas ou dia especifico e atribuir nome do turno
5	Deve permitir criar agendas por tipo de atendimento: primeira consulta, demanda espontânea e retorno
6	Deve permitir configurar nas agendas os intervalos entre os atendimentos do profissional
7	Permitir gerenciar a liberação das agendas dos profissionais por período e turno, podendo criar, excluir ou bloquear os turnos gerados
8	Permitir criar agendas por estabelecimentos de saúde e especialidade/CBO do profissional
9	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
10	Permitir gerenciar agendas do profissional com vínculo em unidades de atendimento social, com as mesmas configurações exigidas no item 5 a 9
11	Ao bloquear ou excluir uma agenda ou turno de um profissional, o sistema deve identificar a existência de agendamentos para a data e solicitar uma ação. Os agendamentos devem ser cancelados ou transferidos para outra data
12	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
13	Emitir relatório de profissionais com os vínculos de unidade
14	Emitir relatório de relação de profissionais com as equipes de atenção básica
15	Emitir relatório de relação de profissionais com inconsistências perante os padrões do E-SUS
16	Emitir relatório com relação de vagas disponíveis por turnos e especialidades
17	Emitir relatório com relação das vagas disponíveis por profissional

CONVÊNIOS
ITEM	DESCRIÇÃO
1	Deve permitir cadastrar os prestadores de serviço utilizados pela CONTRATANTE
2	Permitir alterar os valores dos procedimentos e consultas realizados pelo prestador de serviço
3	Permitir customizar as guias de consultas e exames que serão utilizadas para os agendamentos realizados para o Município
4	Permitir criar cotas de utilização de consultas e exames, podendo realizar controle de quantidade ou valores. A cota pode ser configurada conforme prestador ou especialidade
5	Ao realizar um agendamento de consulta ou exame, o valor do procedimento deve ser descontado da cota mensal
6	O sistema deve limitar o número de agendamentos baseado na quantidade estimada para a cota do prestador de serviço
7	O sistema deverá estar integrado com o setor de REGULAÇÃO DE VAGAS, CAED (CEM, CAISM) e as Clinicas particulares que credenciadas prestam serviços junto à Secretaria Municipal de Saúde

AGENDAMENTO DE CONSULTAS
ITEM	DESCRIÇÃO
1	Permitir o agendamento de consultas que deverá ser de auto completar, respeitando a regra de CBO x Procedimentos existentes no SIGTAP. Ao selecionar uma consulta do tipo básica, o sistema já deve indicar automaticamente o procedimento SIGTAP e quais CBO (Código Brasileiro de Ocupação) são permitidos para tal procedimento
2	Deve ser possível visualizar já na tela de agendamento de consulta, os pacientes agendados para o profissional de saúde, possibilitando a impressão da FAA (Ficha de Atendimento Ambulatorial)
3	Deve ser possível identificar o paciente também por meio de leitura biométrica
4	Durante o agendamento deve ser permitido ao usuário do sistema visualizar os últimos atendimentos do paciente (frequência), com indicador de absenteísmo, mostrando situação dos atendimentos anteriores com o status de cada agenda: agendado, solicitado, cancelada, faltante…
5	Ao selecionar o profissional e a unidade de atendimento, o sistema deve mostrar os turnos e os números de vagas disponíveis para o profissional na unidade
6	Permitir selecionar o convênio no qual será vinculado a consulta
7	Permitir controlar o número de agendamentos baseado em cotas distribuídas pelo convênio selecionado
8	Ao gravar um agendamento de consulta, o sistema deverá gerar automaticamente o faturamento dos procedimentos registrados no padrão SIA-SUS (BPA)
9	Permitir a confirmação da consulta através da autenticação da Guia de consultas e da biometria validando a consulta como atendida
10	Permitir a impressão de FAA (Ficha de atendimento Ambulatorial)
11	Permitir a impressão de guia de autorização de consultas com código de barras
12	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
13	Emitir relatório de consulta analítico e sintético com a relação de agendamentos por dia
14	Emitir relatório de consulta analítico e sintético por unidade solicitante
15	Emitir relatório de consulta analítico e sintético por profissionais de destino e origem
16	Emitir relatório de consulta analítico e sintético de atendimentos realizados localidade
17	Emitir relatório de consulta analítico e sintético por especialidades
18	Emitir relatório de consulta analítico e sintético por paciente
19	Emitir relatório de consulta analítico e sintético com encaminhamentos por especialidade
20	Emitir relatório de consulta analítico e sintético por profissional
21	Emitir relatório de consulta analítico e sintético de comparativo de consultas x atendimentos
22	Emitir relatório de consulta analítico e sintético de comparativo de consultas x realizadas
23	Emitir relatório de consulta analítico e sintético de consultas por município de residência do paciente
24	Emitir relatório de consulta analítico e sintético de profissional por dia
25	Emitir relatório de consulta analítico e sintético de agendamentos x encaminhamentos por profissional
26	Emitir relatório de consulta analítico e sintético de consultas agendadas/realizadas por profissional
27	Emitir relatório de consulta analítico e sintético de prescrições por período de tempo
28	Emitir relatório de consulta analítico e sintético por classificação de risco

AGENDAMENTO DE EXAMES
ITEM	DESCRIÇÃO
1	Permitir cadastrar os prestadores que realizam exames laboratoriais e não laboratoriais
2	Permitir configurar os exames laboratoriais e não laboratoriais de cada prestador, podendo ser configurado individualmente ou em lotes
3	Deve possibilitar a cópia dos exames configurados de um prestador para outro
4	Permitir criar as agendas para os prestadores, as agendas podem ser criadas por dia da semana, período de datas ou dia especifico
5	Permitir criar as agendas para os prestadores por procedimento (exame), as agendas podem ser criadas por dia da semana, período de datas ou dia especifico
6	Deve ser permitido buscar os exames agendados por diversos filtros, inclusive com a opção de leitura biométrica para identificar os exames do paciente
7	Deve ser permitido visualizar frequência de agendamentos de exames para o paciente e o índice de absenteísmo
8	Permitir selecionar o convênio para o agendamento do exame, deve-se também mostrar a quantidade atual de cotas disponíveis para o convênio selecionado
9	Possibilitar a impressão de guia de autorização de consultas com código de barras
10	Permitir registrar falta do paciente no comparecimento do exame
11	Permitir registrar o comparecimento do paciente no exame
12	Permitir anexar o resultado do exame (laudo), para futura visualização do mesmo dentro sistema
13	Permitir cancelar ou estornar faturamento um exame realizado
14	Emitir relatório analítico e sintético por exames agendados
15	Emitir relatório analítico e sintético de exames agendados por solicitante
16	Emitir relatório analítico e sintético de exames por prestador
17	Emitir relatório analítico e sintético de exames por paciente
18	Emitir relatório analítico e sintético de exames por convênio
19	Emitir relatório analítico e sintético de exames com frequência por pacientes
20	Emitir relatório analítico e sintético de exames x realizados
21	Emitir relatório dos exames configurados para o(s) prestador(es)
22	Emitir relatório de exames com prévia de faturamento dos procedimentos

LISTA DE ESPERA
ITEM	DESCRIÇÃO
1	Este módulo tem por finalidade gerir a fila expectante, onde deverá permitir a pesquisa de das solicitações realizadas por: número de protocolo, filtrar por tipo (consultas, exames, APAC, AIH), situação (em espera, confirmados, aguardando), Unidade solicitante, paciente, CBO, entrada na lista por data inicial e final
2	Deverá lista as solicitações por: tipo, gravidade, código do cidadão, nome do cidadão, idade, data de entrada, CBO
3	Permitir identificar pré-requisitos do agendamento, imprimir guia da solicitação ou agendar consulta a partir da lista de Espera, carregando automaticamente os dados da solicitação na tela do agendamento
4	O Protocolo de solicitação deverá trazer: código de barras, número do protocolo da Lista de espera, dados do paciente, CBO/Especialidade
5	O protocolo deverá permitir que o usuário possa acompanhar, inserindo o código através do site portal do cidadão sua posição na lista de espera e quando sua consulta, exames e ou cirurgias forem agendados
6	Deve permitir a inserção na lista de espera automaticamente através do atendimento da consulta na digitação do prontuário eletrônico, pela solicitação médica quando do encaminhamento para especialidade e/ou cirurgia ou solicitação de exames
7	Deverá permitir a inserção na lista de espera de forma manual, solicitando o tipo/grupo (Consulta, Exames, AIH, APAC), informar a unidade de origem, prestador e profissional responsável
8	Deverá permitir excluir o usuário da lista de espera, possuindo o campo para colocar motivo da exclusão Ex.: Falecimento, consultou particular, desistiu da consulta...
9	Deverá permitir acompanhar a lista de espera do serviço social - solicitação de benefício.
10	Deverá permitir pesquisar, a partir da lista de Espera, solicitações enviadas à Regulação de AIH e APAC
11	Deverá permitir configurar a escala de cores com grau de priorização do atendimento em até 5 níveis. Esta configuração permitirá classificação o grau de urgência nas solicitações a partir da solicitação na inclusão em Lista de Espera
12	Deverá possuir vários relatórios por Unidade, Demanda, Tempo de Espera, Especialidade, agendados por período, para:
13	Consultas Especializadas
14	Exame
15	AIH
16	Benefício

PROCEDIMENTO AMBULATORIAL
ITEM	DESCRIÇÃO
1	Deverá ser possível registrar os procedimentos ambulatoriais realizados pela equipe de saúde
2	Deve limitar o registro dos procedimentos baseados nas regras de CBO existentes na tabela SIGTAP
3	Para um procedimento citopatológico, o sistema deve permitir a digitação do resultado laboratorial de patologia clínica. Deve-se também possibilitar a impressão da “ficha da coleta do citopatológico do colo do útero” conforme padrão SISCAN
4	Deve possibilitar o registro de procedimentos coletivos, com a quantidade de cidadãos que participaram da atividade
5	Para procedimentos do tipo visita domiciliar, deve permitir o preenchimento da ficha de visita domiciliar no modelo E-SUS

PRONTUÁRIO ELETRÔNICO DO PACIENTE (PEP)
ITEM	DESCRIÇÃO
1	Prontuário Eletrônico do Paciente Integrado minimamente com os módulos assistenciais, tais como: regulação, vacinas, cadastro domiciliar padrão e-SUS AB
2	Deve permitir a visualização do Resumo Clínico do usuário contendo minimamente estrutura modular e em ordem cronológica, contendo informações cadastrais e foto do usuário e possíveis alergias. Referente aos atendimentos, deve trazer as informações de: unidade de atendimento, data, sinais vitais, profissional e possível classificação de risco. Destacando os possíveis absenteísmos
3	O Resumo Clínico deve apresentar todos os encaminhamentos especializados e hospitalares, consultas odontológicas, exames solicitados, procedimentos indiqueis e coletivos, solicitações de APAC, visitas do Agente Comunitário de Saúde e lista de medicamentos prescritos
4	A tela multidisciplinar deve possibilitar chamar o paciente em painel com contador de tempo, opção para cancelar, desmarcar e indicar faltante em um agendamento, mostrar seletor para acompanhamento da regulação, botão para acompanhar cadastros da ESF padrão e-SUS AB, agendamento de retorno, mostrar curva de crescimento para crianças
5	Possuir grid com todos os agendamentos com as seguintes informações: classificação de risco, hora prevista do atendimento, indicar acolhimento ou pré-consulta
6	Possuir acesso rápido ao Resumo Clínico, ao acolhimento e pré-consulta
7	A tela de atendimento de consulta deverá mostrar foto, código, nome e data de nascimento, idade do paciente
8	A tela de atendimento de consulta deverá ter, atalho para dados da pré consulta, campo da descrição de queixas e exame físico, com busca do CID-10; CIAP 2, podendo inserir mais de um CID/CIAP 2 por atendimento, permite colocar o paciente em observação
9	Os CID´s configurados devem abrir as fichas de notificação do SINAN
10	CID´s com protocolos de conduta pré configurados, deverão habilitar em tela.
11	Deverá ter um campo para descrever histórico familiar / antecedentes, com CIAP2, indicações de cirurgias, internações, lista de problemas envolvidos
12	Possibilitar registros no formato SOAP (Subjetivo, Objetivo, Avaliação e Plano)
13	Deverá possuir tela com lista de problemas: ativos, latentes e /ou resolvidos
14	A prescrição deverá possibilitar escolha do tipo do medicamento, nome do medicamento com saldo do estoque do item; indicar se uso contínuo, concentração, quantidade e posologias pré-definidas
15	Deverá alertar para as interações medicamentosas pré cadastradas
16	Possibilitar impressão de receituário comum em uma ou duas vias, e receituário especial para medicamentos controlados, indicando quais medicamentos devem ou não ser impressos
17	Possibilidade de indicar quantidades de receitas para a referida prescrição, os receituários devem ter intervalos de 30 dias
18	O sistema deverá possibilitar a visualização de prescrições anteriores, sendo do mesmo profissional em atendimento e dos demais profissionais, minimamente as últimas três prescrições, possibilitando selecionar os itens e inserindo-os numa nova prescrição.
19	O sistema deverá possibilitar lista de medicamentos pré-definidas de acordo com os protocolos de prescrição
20	Possuir tela para demais orientações, sendo texto livre com opção de impressão.
21	Deverá mostrar em tela o resultado dos exames, com filtro de período e tipo de exames, possibilitar a impressão de exames
22	Deverá possuir atalho para os protocolos pré cadastrados de solicitação de exames, podendo selecionar quaisquer exames, mostrando a frequência de solicitação, imprimindo a solicitação e enviando automaticamente para a lista de espera e regulador, conforme configuração
23	Exibir guia de solicitação de exames, que não estejam pré configurados nos protocolos, com justificativa obrigatória e gravidade da solicitação, minimamente em três níveis de classificação, mostrando a frequência de solicitação, imprimindo a solicitação e enviando automaticamente para a lista de espera e regulador, conforme configuração
24	Possibilitar encaminhamentos para consultas especializadas, indicando especialidade a ser encaminhado, tipo da solicitação com três níveis de classificação, com possibilidade de retorno, bem como protocolo de encaminhamento pré configurado, o encaminhamento deve conter motivo de referência e justificativa para o encaminhamento
25	O encaminhamento para consultas especializadas deverá possibilitar inclusão de CID que poderá ter protocolos de encaminhamentos exigindo a solicitação de exames obrigatórios para aquele encaminhamento, pré configurados pela regulação, é possível imprimir a solicitação
26	Possibilitar encaminhamento hospitalar, indicando hospital e /ou unidade de referência, apresentar minimamente três níveis de classificação, motivo de referência, justificativa, principais sintomas clínicos, condições que justificam a internação, principais resultados de provas de diagnóstico e CID obrigatório. Possibilita imprimir solicitação de AIH
27	Deverá possibilitar o registro de informações sigilosas em campo livre, podendo escolher o grupo que terá acesso a partir do cadastro de informações sigilosas. Deverá estar visível em tela as últimas informações registradas pelo usuário logado
28	No atendimento médico deverá ser possível anexar arquivos minimamente no formato JPEG, PDF. Os arquivos anexados devem ter a possibilidade de serem restritos para perfis de acesso pré configurados
29	No atendimento médio possibilitar emitir atestados, minimamente de comparecimento com ou sem presença de acompanhante, licença maternidade (com validação para o sexo feminino), atestado de afastamento com autorização para mostrar o CID do atendimento e atestado de sanidade físico-meta, mostrar em tela a frequência dos atestados do usuário
30	Deverá possuir no atendimento médico, folha de rosto, baseado nos padrões e-SUS AB, com dados cadastrais, escuta inicial, histórico e lista de problemas
31	No atendimento médico deverá possuir atalho para registro de procedimentos, podendo inserir a condição do paciente, minimamente DTS/AIDS, Hipertensão, Diabetes. Deverá mostrar a frequência do usuário
32	O atendimento médico deverá possibilitar o acesso rápido ao Resumo Clínico do paciente em atendimento, conforme descrito nos itens 1 e 2.
33	Possuir atalho no atendimento médico para a caderneta de vacinação, nos moldes do padrão SIPNI
34	Deverá permitir o registro da solicitação dos procedimentos elegíveis a autorização de APAC, emitindo a guia preenchida no padrão DATASUS
35	O atendimento médico deverá possibilitar o registro das informações do Risco Cardiovascular, baseado no padrão SAVASSI, possuir minimamente botões de ajuda / orientação nos itens idade, colesterol (HDL e LDL), pressão arterial. O score deve ser calculado automaticamente através do preenchimento da pesquisa, demais pontuações do referido manual conforme caderno da atenção básica número 37 - Estratégia para Cuidados da Pessoa com Doenças Crônicas, deverá manter histórico, minimamente dos últimos dois scores
36	O atendimento médico deverá possibilitar a finalização da consulta, esse atendimento não poderá ser editado

ODONTOLOGIA
ITEM	DESCRIÇÃO
1	Permitir visualizar a agenda de atendimento com calendário, resumo da agenda com quantidade de pacientes atendidos, faltantes, cancelados e não atendidos
2	Exibir botão para marcar chegou atestando a recepção do paciente na unidade, faltante, cancelar, demarcar ou imprimir o Mapa diário de Consulta
3	Permitir visualizar o resumo do prontuário ambulatorial do paciente
4	Permitir o Registro clínico odontológico do paciente com Odontograma
5	Possibilitar registro de atendimento padrão SOAP em atendimentos no âmbito da Atenção Básica;
6	Registro dos agendamentos de consultas e procedimentos realizados
7	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
8	Permite realizar anamnese e gravar histórico, sendo visível no próximo atendimento e permitindo alteração nas respostas
9	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
10	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
11	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
12	Permite criar mais de um plano de tratamento para o mesmo paciente
13	Permite inserir observação nos procedimentos realizados no odontograma
14	Permitir anexar arquivos de imagem do tipo .pdf ou .jpeg
15	Permitir imprimir prontuário odontológico com todos os dados do paciente, unidade de saúde, procedimentos realizados
16	Deverá exibir o nome e número do dente e face ao passar o cursor do mouse.
17	Permitir gerar relatórios de odontologia em:
18	Consultas Por Unidade
19	Consultas Por profissional
20	Consultas Por especialidade
21	Índices CPO-D
22	Prévia de Faturamento por CBO

ACOLHIMENTO E RECEPÇÃO
ITEM	DESCRIÇÃO
1	Permitir que os próprios usuários, através de terminais de autoatendimento (Totens), possam escolher qual o tipo de atendimento que procura
2	O aplicativo de autoatendimento deve possibilitar minimamente que o cidadão possa solicitar atendimento para os serviços de agendamento de consulta, autorização de exames, vacinas e procedimentos
3	Deve disponibilizar funcionalidade integrada para realização de chamada através do regime de senhas com sinal sonoro, as informações de fila de atendimento devem ser exibidas em monitor/televisão
4	Deve possibilitar a impressão da senha para retirada pelo usuário em impressora térmica não fiscal

GESTÃO DA PRODUÇÃO E-SUS - FICHAS
DOMICILIAR E TERRITORIAL/FICHA DE CADASTRO INDIVIDUAL
ITEM	DESCRIÇÃO
1	Deve possuir cadastros de equipe, cadastro de área e micro-área para vinculação/alocação dos profissionais e seu CBO que faram a composição da equipe mínima ESF de acordo com os respectivos vínculos do CNES
2	Deve possuir cadastro de imóveis e domicílios compatíveis 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
3	Deve permitir possuir o cadastro da família, ou composição familiar identificando com foto todos os indivíduos da família pelo nome, código de identificação no sistema, CNS, idade, organização familiar em relação ao responsável, indicação se é ou não responsável familiar (chefe família) bem como a respectiva ficha de cadastro individual e a situação de saúde padrão e-SUS/SISAB
4	Deve permitir a Inclusão/exclusão dos indivíduos componentes da família através do cadastro de usuários do serviço (Paciente) integrado dentro do módulo da composição familiar, bem como também possuir funcionalidade para a transferência remoção de todos os familiares de uma determinada família para outra, sendo que na respectiva confirmação da transferência o sistema deve atribuir o endereço do imóvel para onde os indivíduos foram transferidos para o seu respectivo cadastro de usuários do serviço (paciente) mantendo a integridade do cadastro
5	Cadastros de imóveis e domicílios: O Sistema deverá permitir buscar os imóveis já cadastrados, bem como cadastrar um imóvel novo, para busca de um imóvel já cadastrado será possível buscar o mesmo pelo nome do proprietário, inscrição imobiliária, membro da família, número da família, endereço, bairro, código do membro da família, quadra, lote e número do NIS do responsável além de ainda filtrarmos por área e micro área
6	Para um novo cadastro, o Sistema deverá possuir os seguintes dados do imóvel, onde será informado nome do proprietário ou responsável pelo imóvel, inscrição imobiliária, distrito, setor, quadra, lote, unidade domiciliar, pais, estado, cidade, endereço, bairro, número e CEP
FICHA DE ATENDIMENTO INDIVIDUAL
1	Permitir realizar o registro dos Atendimentos Individuais de acordo com o padrão de Ficha de Atendimento Individual padrão e-SUS 2.0, destinada aos registros das ações de promoção a saúde do indivíduo
2	Sistema deve possibilitar informar os respectivos campos informações: Unidade/Estabelecimento de Saúde executante, profissional, CBO, Local de Atendimento sendo necessário obrigatório informar pelo menos uma das seguintes opções: (01 – UBS, 02 - Unidade móvel, 03 – Rua, 04 – Domicílio, 05 - Escola/Creche, 06 – Outros, 07 - Polo (Academia da Saúde, 08 - Instituição/Abrigo, 09 - Unidade prisional ou congêneres, 10 - Unidade socioeducativa)). Equipe, data, usuário do serviço, possibilitando a busca do cadastro de paciente integrada a solução, exibindo em tela o nome do usuário, CNS, data nascimento e sexo, bem informar se a vacinação está em dia ou não, possibilitar informar o tipo de atendimento (Consulta programa / Cuidado continuado, Consulta agendada, dentro da Demanda espontânea se foi do tipo (Escuta inicial / Orientação, Consulta no dia ou Atendimento de urgência) referente ao turno (manhã, tarde ou noite), se foi na modalidade AD (AD1, AD2, AD3), possibilitar informar a Avaliação Antropométrica (Perímetro cefálico, peso, altura), possibilitar informa no caso de crianças se o Aleitamento materno é (01 – Exclusivo, 02 – Predominante, 03 – Complementado, 04 – Inexistente), possibilitar informar se o paciente ficou em Observação, sim ou não, possibilitar informar a Racionalidade em saúde (01 - Medicina Tradicional Chinesa, 02 - Antroposofia Aplicada à Saúde, 03 – Homeopatia, 04 – Fitoterapia, 05 – Ayurveda, 06 – Outra), bem esse campo não deve ser de preenchimento obrigatório, por causa da racionalidade utilizada seja a Alopatia/Convencional. Referente ao planejamento familiar, dados de mulheres gestantes quando for o caso, sistema possibilitar informar os seguintes campos, informações como a DUM, idade gestacional em semanas, gestas prévias, partos, referente aos atendimentos em NASF/Polo, deve ser possível informar (Avaliação/Diagnóstico, Procedimentos Clínicos/Terapêutico, Prescrição Terapêutica), deve possibilitar informar Problema/Condição(ões) avaliada(s) de acordo com a ficha padrão 2.0, caso contrário sistema deve permitir informar 1 ou 2 tipos de CIAP2 ou 1 ou 2 CID10, bem como sistema também de possibilitar informar Exames Avaliados ou Solicitados dentro os tipos padrões da ficha 2.0 respectiva, bem como informar se o exame foi Solicitado, Avaliado ou ambos, bem como possibilitar a Conduta/Desfecho de acordo com a ficha padrão e-SUS 2.0
3	Deve permitir informar o tipo de procedimento que será registrado (ambulatorial ou coletivo) identificar a unidade de saúde do profissional responsável pelo atendimento bem como o nome do profissional e o procedimento que foi realizado (sutura, aferição de preção, glicemia, etc.) no caso de registro de uma visita domiciliar ao selecionar o procedimento
4	Permitir o registro de atividades coletivas com campos para inserir:
5	a. código de atendimento,
6	b. data,
7	c. Unidade de Saúde,
8	d. Caráter do atendimento
9	e. Profissional responsável
10	f. CBO profissional destino
11	g. Procedimento
12	h. Quantidade de participantes
13	No registro da visita onde abrira uma tela com a ficha do modelo e-SUS para o registro do procedimento, onde deverá ser informado o turno da visita, desfecho da visita, motivo da visita, tipo de acompanhamento e ou busca ativa
14	Procedimentos coletivos e/ou PSE, indicará o procedimento que será realizado, (atividade educativa / orientação em grupo na atenção básica) ao selecionar este procedimento,(atividade coletiva) estar disponível uma ficha para registro nos padrões do E-SUS onde o usuário ira informar a data da atividade, hora de início e hora de fim da atividade, poderá vincular todos os profissionais envolvidos na atividade, e selecionar a atividade que foi realizada, lembrando que para atividades do programa saúde na escola é necessário informar o INEP do estabelecimento bem como informar o nome dos participantes das atividades que apresentarem avaliações alteradas
15	Deve permitir informar o tipo de procedimento que será registrado (ambulatorial ou coletivo) identificar a unidade de saúde do profissional responsável pelo atendimento bem como o nome do profissional e o procedimento que foi realizado (sutura, aferição de preção, glicemia, etc.) no caso de registro de uma visita domiciliar ao selecionar o procedimento
FICHA DE ATENDIMENTO ODONTOLÓGICO INDIVIDUAL
1	Deve informar a unidade de saúde do profissional responsável pelo atendimento bem como o nome do profissional, CBO, equipe, local de atendimento, data, turno e paciente, permitindo inserir número do prontuário
2	Permitir registrar: Tipo de atendimento (Consulta agendada, Demanda espontânea, Escuta/orientação, Consulta do dia, Atendimento de urgência); Tipo de Consulta (Primeira consulta odontológica programática, Consulta de retorno em odontologia, Consulta de manutenção em odontologia); vigilância em Saúde Bucal (Abscesso dento alveolar, Alteração em tecidos moles, Dor de dente, fendas ou fissuras labiopalatais, Fluorose dentária, moderada ou severa, Traumatismo dento alveolar, não identificado)
3	Permitir inserir procedimento odontológico (pesquisar a partir da tabela SIGTAP) com observação, dente e face
4	Fornecimento (Escova dental, Creme dental, Fio dental)
5	Conclusão (Retorno para consulta agendada, Agendamento para outros profissionais AB, Agendamento para NASF, Agendamento para grupos, Alta do episódio Tratamento concluído)
6	Encaminhamento (Atendimento a pacientes com necessidades especiais, Cirurgia BMF, Endodontia, Estomatologia, Implantodontia, Odontopediatria, Ortodontia / Ortopedia, Periodontia, Prótese dentária, Radiologia, Outros
MARCADOR ALIMENTAR
1	Permitir realizar o acompanhamento e registro de marcadores alimentar de acordo com a ficha padrão e-SUS 2.0
2	Sistema deve possibilitar informar os respectivos campos informações: Unidade/Estabelecimento de Saúde executante, profissional, CBO, Equipe, Local de Atendimento sendo necessário obrigatório marcar pelo menos uma das opções entre elas (01 – UBS, 02 - Unidade Móvel, 03 – Rua, 04 – Domicílio, 05 - Escola/Creche, 06 – Outros, 07 - Polo (Academia da Saúde), 08 - Instituição / Abrigo, 09 - Unidade prisional ou congêneres ou 10 - Unidade socioeducativa), identificação do usuário do serviço (Paciente) exibindo pelo menos a Data Nascimento e Idade detalhando os anos, meses e dias
3	Sistema deve exibir os campos de anamnese dos marcadores de consumo alimentar distinguindo entre três grupos de marcadores de acordo com as respectivas faixas etárias conforme preconizado na ficha padrão e-SUS 2.0:
4	1 – Crianças menores de seis meses o sistema deve obrigar a informação de todos os marcadores alimentares sendo eles: (A criança ontem tomou leite do peito? Ontem a criança consumiu: (Mingau, Água/chá, Leite de vaca, Fórmula Infantil, Suco de fruta, Fruta, Comida de sal (de panela, papa ou sopa), outros alimentos/bebidas), sendo necessário marcar entre uma das opções: (Sim, não ou Não sabe))
5	2 - Crianças de 6 a 23 meses o sistema deve obrigar a informação de todos os marcadores alimentares sendo eles: (Outro leite que não o leite do peito; Mingau com leite; Iogurte; Legumes (não considerar os utilizados como temperos, nem batata, mandioca/aipim/macaxeira, cará e inhame); Vegetal ou fruta de cor alaranjada (abóbora ou jerimum, cenoura, mamão, manga) ou folhas verdes escuras (couve, caruru, beldroega, bertalha, espinafre, mostarda); Verdura de folha (alface, acelga, repolho); Carne (boi, frango, peixe, porco, miúdos, outras) ou ovo; Fígado; Feijão; Arroz, batata, inhame, aipim/macaxeira/mandioca, farinha ou macarrão (sem ser instantâneo); Hambúrguer e/ou embutidos (presunto, mortadela, salame, linguiça, salsicha); Bebidas adoçadas (refrigerante, suco de caixinha, suco em pó, água de coco em caixinha, xaropes de guaraná/groselha, suco de fruta com adição de açúcar); Macarrão instantâneo, salgadinhos de pacote ou biscoitos salgados; Biscoito recheado, doces ou guloseimas (balas, pirulitos, chiclete, caramelo, gelatina)), sendo necessário marcar entre uma das opções: (Sim, Não ou Não sabe)).
FICHA DE AVALIAÇÃO DE ELEGIBILIDADE DE ADMISSÃO
1	Permitir realizar o registro dos Atendimentos Individuais de acordo com o padrão de Ficha de Atendimento Individual padrão e-SUS 2.0, destinada aos registros das ações de promoção a saúde do indivíduo
2	Sistema deve possibilitar informar os respectivos campos informações: Unidade/Estabelecimento de Saúde executante, profissional, CBO, Equipe, Origem sendo entre as opções (UBS, Outros, Hospital, Unidade de Pronto Atendimento, CACON/UNACON, Urgência/emergencial Hospital SOS, Hospital SOS demais setores), Data e identificação do usuário do serviço (Paciente) exibindo os seguintes campos e informações do cadastro integrado do sistema (Nome Social se houver, Sexo, Data Nascimento, Idade, Cartão SUS, Raça/Cor, Número Identificação Social – NIS, Nome completo da mãe, Nome completo do pai ou opção para marcar se for desconhecido, Nacionalidade, Cidade de Nascimento, e-mail) referente ao endereço atual do paciente deve trazer automaticamente do cadastro integrado do paciente os campos (Município, UF, Tipo Logradouro, Logradouro, Localidade (bairro), número, CEP, Complemento)), bem como referente aos telefones de contato trazer automaticamente pelo menos o telefone principal de contato mais outro número de telefone de contato de referência. Sistema deve possibilitar informar as Condições Avaliadas de acordo com a ficha padrão 2.0, bem permitir informar em caráter obrigatório o CID10 principal, bem como possibilitar informar pelo menos mais 2 CID10 secundários, bem como sistema deve possibilitar informar a Conclusão, sendo entre as opções (AD1, AD2, AD3 ou inelegível), caso a conclusão seja escolhido entre as opções AD1, AD2 ou AD3, sistema deve permitir informar em caráter obrigatório se elegível em alguma das seguintes opções (Admissão na própria EMAD, Encaminhado para outra EMAD, Encaminhado para Atenção Básica AD1 ou Outro encaminhamento) caso seja escolhido a opção Inelegível sistema deve possibilitar em caráter obrigatório pelo menos uma das seguintes opções ou todas elas sendo (Instabilidade clínica com necessidade de monitorização contínua, Necessidade de propedêutica complementar, com demanda potencial para a realização de vários procedimentos diagnósticos, com urgência, Outro motivo clínico, Ausência de cuidador(em casos de necessidade) ou Outras condições sociais e/ou familiares impeditivas do cuidado domiciliar), bem como possibilidade de informar o Cuidador entre as opções sendo (Não possui, Cônjuge/Companheiro(a), Filho(a)/Enteado(a), Pai/Mãe, Avô/Avó, Neto(a), Irmão(ã), Outro), sendo todo as informações possíveis de registrar de acordo com a ficha padrão e-SUS 2.0
3	Permitir realizar o registro dos Atendimentos Individuais de acordo com o padrão de Ficha de Atendimento Individual padrão e-SUS 2.0, destinada aos registros das ações de promoção a saúde do indivíduo
FICHA DE ATENDIMENTO DOMICILIAR
1	Permitir realizar o registro dos Atendimentos Domiciliares de acordo com o padrão de Ficha de Atendimento Domiciliar, destinada a usuários com dificuldade ou impossibilidade física de locomoção até uma unidade de saúde
2	AD 1: usuários que necessitam de cuidados de menor intensidade, devendo ser acompanhados regularmente pela equipe de atenção básica
3	AD 2: usuários que necessitam de cuidado intensivo, com visitas, no mínimo semanal
4	AD 3: usuário com os critérios de AD2 somados ao uso de suporte ventilatório não invasivo, ou paracentese, ou diálise peritoneal
5	Sistema deve permitir os registros de atendimentos, possibilitando informar os respectivos campos informações:
6	Unidade/Estabelecimento de Saúde executante, profissional, CBO, equipe, data, usuário do serviço, possibilitando a busca do cadastro de paciente integrada a solução, exibindo em tela o nome do usuário, CNS, data nascimento e sexo, bem como possibilitar informar o local de atendimento, turno, modalidade AD (AD1, AD2, AD3), tipo de atendimento (programado ou não), CID e CIAP, condições de avaliadas, possibilitar a informação dos procedimentos realizados com código e procedimento SIGTAP, bem com informar a Conduta/Desfecho de acordo com a ficha padrão e-SUS 2.0
EXPORTAR E-SUS
1	Obrigatoriedades sobre a exportação dos atendimentos realizados na Atenção Básica (CDS/RAS):
2	Para que seja possível a importação dos registros no E-SUS todos os dados cadastrais de Pacientes, Profissionais e Unidades de Saúde (Equipes) devem estar completos
3	Obrigatoriamente os Pacientes devem possuir no cadastro o número do CNS, evitando inconsistência no envio da produção
4	Obrigatoriamente os Profissionais devem possuir no cadastro o número do CNS, evitando inconsistência no envio da produção
5	Obrigatoriamente as Unidades de Saúde devem possuir no cadastro o número do CNES
6	Sistema deve disponibilizar uma tela que seja possível selecionar os módulos ou fichas de registros contendo os registros de dados alimentados no sistema que o operador deseje escolher para ser exportados para e-SUS:
7	Ficha de cadastros individuais, cadastros domiciliares, atendimentos individuais, procedimentos coletivos – PSE, procedimentos odontológicos, procedimentos ambulatoriais e visitas domiciliares
8	Todos os campos desta tela de exportação, devem conter um “help”, para auxiliar o melhor uso da ferramenta, com telas explicativas do processo e-SUS
9	Tela onde possa selecionar quais unidades serão extraídos os dados para exportação
10	Módulo que permita uma visualização em tela de competências do e-SUS já exportadas, com os seguintes filtros de buscas: Equipe/Unidade, Profissional, Data atendimento, usuário, Procedimento, Status do registro
11	Tela que separe os procedimentos por: Atividade Coletiva, Procedimentos, Visitas, Domicílios, Cadastro Individual, Procedimentos Odontologia e Atendimentos. Que tenha um painel que mostre a quantia de procedimentos por grupo de procedimento
12	Que o Sistema mostre nesta tela, as linhas com problemas de falta de campos obrigatórios do e-SUS
13	Gerar arquivo zipado com parâmetros do layout e-SUS, com lote, dia, mês, ano, horas e minutos que o arquivo foi criado
14	Relatórios e-SUS: Resumo da exportação, Procedimentos PEC, quantitativos por atendimento, Procedimentos Sintético, Procedimentos Analítico, Procedimentos PEC
15	Ambos com filtros de Unidade, Usuário, Profissional, Período, Idade, Sexo
16	Disponibilizar relatórios de contingência (para eventual necessidade de registro manual nas fichas do E-SUS): Atendimento Domiciliar Avaliação de Elegibilidade e Admissão Cadastro Domiciliar e Territorial Cadastro Individual Ficha Complementar Ficha de Atendimento Individual Ficha de Atendimento Odontológico Individual Ficha de Atividade Coletiva Ficha de Visita Domiciliar e Territorial Marcadores de Consumo Alimentar Manual do e-SUS
IMUNIZAÇÃO E VACINAS
1	Permitir importar arquivo do SI-PNI desktop (.pni) para assim carregar o histórico de vacinação do paciente no sistema
2	Permitir cadastro de lotes, vinculando-os à unidade de saúde
3	Mostrar em tela, qual a versão do BD (Banco de Dados) e da aplicação SI-PNI do governo que é compatível
4	Para o módulo de registro de vacinação, ao selecionar um paciente deverá indicar automaticamente em quais campanhas previamente cadastradas o mesmo se encaixa.
5	Ao selecionar a campanha, o sistema deve automaticamente preencher estratégia, imuno e dose, evitando assim, erros de digitação
6	Permitir o aprazamento automático das aplicações de imunobiológicos baseados nas regras do SI-PNI
7	Emitir carteirinha de vacinação de acordo com as necessidades do município ou mesmo utilizando os padrões do DATASUS
8	Deve permitir as movimentações de Imunobiológicos seguindo o padrão de layout do DATASUS SI-PNI
9	Permitir a emissão de arquivo de produção mensal de doses aplicadas de imunobiológico e permitir a exportação dos dados deste bole tim para o programa SI-PNI do DATASUS, automatizando o processo, sem necessitar da redigitarão
10	Deverá gerar arquivo de exportação com extensão PNI dentro do formato do layout oficial do ministério da saúde para o PNI
11	O módulo de exportação, deve ter a funcionalidade de exportar por competência, permitindo ao operador personalizar o período de cada competência antes da geração do arquivo
12	Deverá gerar os seguintes relatórios:
13	Quantitativo geral
14	Por Unidade - Sintético e Analítico
15	Movimentação de Imuno de Imunizados por vacina
16	Acompanhamento por doses aplicadas
17	Vacinas em Atraso Por Usuário - Sintético e Analítico
18	Vacinas em atraso por Vacina
19	Relatórios Esquema vacinal
REGISTRO DAS AÇÕES AMBULATORIAIS DE SAÚDE - RAAS
1	Deve ser possível registrar todas as informações do atendimento para o paciente referente a atenção psicossocial
2	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
3	Permitir inserir as quantidades das ações realizadas pelo profissional, informando o local da realização da atividade
4	As ações devem ser vinculadas aos procedimentos da tabela SIGTAP
5	Permitir vincular um CID à ação caso o procedimento esteja exija esse preenchimento em suas condicionalidades
6	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
7	Deve permitir imprimir os espelhos dos atendimentos
8	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 re-digitação
9	Deverá gerar os seguintes relatórios RAAS:
10	Por Procedimento
11	Por atendimento
12	Por origem e destino do paciente
13	Procedimentos por profissional
PRÉ NATAL
1	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, a partir da tela atendimento médico (SOAP)
2	No objetivo (O), permitir registrar: descrição do exame físico, DUM, Tipo de gravidez, DPP, Movimentação Fetal, Altura Uterina e Batimento cardíaco fetal
3	Registrar antecedentes obstétricos
4	Permitir excluir gestante cadastrada no SOAP.
5	Emitir relatórios de gestantes cadastradas por unidade
6	Emitir relatórios de gestante sem consulta
7	Emitir relatórios de gestação em aberto
8	Emitir relatórios de gestantes com risco
ACOMPANHAMENTO DE PACIENTES CRÔNICOS
1	Este módulo deverá permitir cadastrar todos os doentes crônicos com: 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)
2	Complicações, (Infarto Agudo do Miocárdio, Outras Coronariopatias, AVC, Pé Diabético, Amputações P/ Diabetes, Doenças Renais, Internamento Hospitalar Psiquiátrico, Internamento P/ Dependência Química, Angina)
3	Deve permitir criar esquemas terapêuticos integrados os produtos/suprimentos da rede
4	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
5	Emitir relatórios sintéticos e analíticos de pacientes crônicos por patologia
6	Emitir relatórios sintéticos e analíticos de pacientes crônicos por unidade de saúde
7	Emitir relatórios sintéticos e analíticos de medicamentos dispensados por patologia
8	Emitir relatórios sintéticos e analíticos de pacientes crônicos com esquema terapêutico pré-definido
9	Emitir relatórios sintéticos e analíticos de complicações por paciente
PROTOCOLO DE FRAMINGHAM
1	Este módulo deve permitir ao profissional fazer a avaliação do risco cardiovascular, coronárias, cerebrovascular, artéria periférica falha e doenças do coração:
2	Para realizar o escore de risco Framinghan o sistema deve contabilizando os seguintes marcadores:
3	Idade do paciente, colesterol total, HDL, glicemia, uso do tabaco e pressão arterial
4	Deverá manter um histórico das avaliações realizadas mostrando em na mesma tela a evolução dos marcadores
GESTÃO DE VEÍCULOS E AGENDAMENTO DE VIAGENS
1	O sistema deve permitir gerenciamento da frota de veículos da CONTRATANTE
2	Deve permitir cadastrar os motoristas / Profissionais
3	Deve permitir agendar viagens para consultas e exames, com possibilidade de informar o tipo do serviço que será realizado no paciente
4	Deve permitir indicar o sentido da rota, onde define-se se é ida/volta apenas ida ou apenas volta
5	Realizar registros das viagens, emitindo mapa da viagem para o motorista com nome e CPF ou RG dos passageiros e acompanhantes que viajarão e estabelecimentos de destino com o seu respectivo endereço
6	Emitir comprovante de viagens por motorista, itinerário, data
7	Emitir lista de passageiros no padrão do departamento de estradas de rodagem
8	Sistema deve possibilitar o registro de viagens ou deslocamentos dos veículos respeitando a data de ida e volta bem como horário de ida e volta dos veículos para que não ocorra duplo registro de agendamentos com horários e datas conflitantes
9	Sistema deve registrar os agendamentos ou registros de viagens gerando um código de identificação da viagem, identificação de veículo com descrição placa, nome do motorista informando a categoria da respectiva CNH do profissional e data de validade da mesma, bem como possibilitar informar a Cidade de Destino provenientes do cadastro básico integrado com o sistema em geral de Cidades, Estados, Localidades
10	Sistema deve possibilitar no registro da Viagem informar a Km estimada do deslocamento esse campo deve ser obrigatório a informação tendo em vista a necessidade de gerar se habilitado configuração no cliente específica, o sistema gerará os procedimentos padrão SIGTAP que se referem a produção ambulatorial proveniente de ajuda de custo com deslocamento dos pacientes e acompanhantes quando for o caso especificamente informado
11	Sistema deve permitir registrar para a viagem qual o ponto de saída do veículo, disponibilizando essa informação para o paciente por meio de impressão do ticket/passagem
12	Permitir marcar faltante nos passageiros que agendaram a viagem e não compareceram
13	Sistema deve permitir para cada viagem ou deslocamento agendando inserir os respectivos passageiros (pacientes) ou (acompanhantes) devidamente identificados om foto do indivíduo, nome e código de identificação do sistema, bem como indicar o sentido do deslocamento se é IDA ou VOLTA ou IDA/VOLTA, de acordo com a capacidade de lugares veículo do veículo definido para realizar a viagem, que é configurada no cadastro do mesmo
14	Emitir relatório de viagem com a escala de passageiros por agendamento com filtros de intervalo de datas, horário, sexo do paciente, unidade de origem, unidade destino, passageiro, veículo, motorista, cidade destino
15	Emitir relatório de viagem para emissão de passagens dos cidadãos, deve conter filtros de intervalo de datas, horário, sexo do paciente, unidade de origem, unidade destino, passageiro, veículo, motorista, cidade destino
16	Emitir relatório de mapa de viagem com filtros de intervalo de datas, horário, sexo do paciente, unidade de origem, unidade destino, passageiro, veículo, motorista, cidade destino
17	Emitir relatório de viagem com a escala de motoristas, contendo os filtros de intervalo de datas, horário, sexo do paciente, unidade de origem, unidade destino, passageiro, veículo, motorista, cidade destino
18	Emitir relatórios sintético e analítico de despesas do veículo
VIGILÂNCIA ALIMENTAR E NUTICIONAL
1	Permitir a partir do módulo Pré-Consulta/Acolhimento cadastrar o usuário para avaliação do estado nutricional, seguindo padrão DATASUS, permitindo a coleta de todos os dados como:
2	Data do atendimento, peso, estatura, vacinação, aleitamento, peso ao nascer, DUM, se é gestante, se está cadastrada no SISPRENATAL, unidade e profissional
3	O Sistema deverá permitir gerar o arquivo dos referidos atendimentos do módulo Marcadores de Consumo Alimentar e fazer através do exportador e-SUS o envio da produção das respectivas fichas de registro de acompanhamento alimentar e nutricional dos pacientes que substituiu o programa SISVAN e através do PEC, fazer exportação das fichas de marcadores alimentar, baseado no descrito na Nota Técnica Nº 51-SEI/2017-CGAA/DAB/SAS/MS
GESTÃO DE ESTOQUE-SUPRIMENTOS
1	Permitir o cadastramento de Grupo de Programação de produtos/materiais/medicamento, contendo, no mínimo: código, nome e situação (ativo ou inativo)
2	Permitir o cadastramento de Grupo de produtos/materiais/medicamentos, contendo, no mínimo: código, nome e situação (ativo ou inativo)
3	Permitir o cadastramento de Subgrupos de produtos/materiais/medicamentos, contendo, no mínimo: código, descrição, grupo e situação (ativo ou inativo)
4	Permitir o cadastramento de grupos de reposição de produtos/materiais, contendo, no mínimo: descrição e situação (ativo ou inativo)
5	Permitir o cadastramento de grupos de especificidade de produtos/materiais/medicamentos, contendo, no mínimo: código, descrição e situação (ativo ou inativo)
6	O sistema deve permitir o cadastramento de Apresentação de Produtos/Unidade (Unidade de Estocagem, Unidade de Compra, Unidade de fracionamento), contendo, no mínimo: descrição e situação (ativo ou inativo)
7	O sistema deve permitir o cadastramento de centros de custo, contendo, no mínimo: código, nome, situação (ativo ou inativo). e possibilidade de definir se o centro de custo é o padrão para carregamento automático nas telas em que for utilizado
8	O sistema deve permitir o cadastramento de estoques/subestoques
9	O sistema deve permitir o cadastramento de localização em níveis no estoque dos materiais/medicamentos
10	O sistema deve permitir o cadastramento de tipos de materiais/medicamentos
11	Permitir o cadastramento de materiais e medicamentos contendo, no mínimo, código, nome, descrição, classificação, grupo, subgrupo, grupo de faturamento, grupo de reposição, subgrupo de reposição, frações de compra e de faturamento, unidades de estocagem, compra e faturamento, antimicrobiano (sim ou não), sujeito a controle especial (sim ou não), uso restrito (sim ou não), exige lançamento de receita na dispensação (sim ou não), ponto de pedido, estoque máximo, estoque mínimo, localização, tipo, preço custo, preço médio, informações técnicas (para descrever especificações), controle de lote (sim ou não), cálculo na prescrição (sim ou não), possui registro na ANVISA (sim ou não) e situação (ativo ou inativo). Caso seja informado cálculo na prescrição sim, o sistema deve obrigar informar a fração de faturamento
12	Deve prover meios de visualizar junto ao cadastro de materiais/medicamentos a posição atual de seu estoque dentro do sistema de gestão da saúde a fim de otimizar o lançamento das dispensações através de consulta de saldos de estoque atuais detalhando quantidade de materiais e medicamentos, além dos lotes disponíveis. Deve trazer a posição atualizada do estoque, permitido selecionar o estoque, grupo de materiais/medicamentos ou individuais. Possibilidade de selecionar todos os itens ou somente com estoque maior que zero. Deve ter opção de ordenar as colunas que compõe a visualização
13	Deve permitir a emissão do relatório de reposição de estoque, onde apresenta a posição de estoque atual (disponível), estoque máximo cadastrado, o cálculo da diferença entre os dois (máximo e disponível), e a previsão de Consumo médio)
14	O sistema deve alertar automaticamente sobre medicamentos com data de vencimento próxima a fim de evitar desperdícios e perda de medicamentos por vencimento durante a saída
15	O sistema deve estar preparado para dispensação por código de barras, com configuração dos estabelecimentos de saúde (estoques) que utilizarão o recurso
16	O sistema deve automaticamente calcular a previsão de consumo, quantidade de dias que o paciente tem de disponibilidade de medicamento, cruzando a quantidade dispensada e a posologia recomendada. Informando as datas de início e término previstas do tratamento. No cálculo que envolvam medicamentos que o paciente já tenha recebido, deve considerar como data de início do tratamento apenas após a previsão de consumo da dispensação anterior ter finalizado. Deve permitir alterar os valores previamente calculados
17	O sistema deve permitir requisição de materiais/medicamentos, podendo informar um ou mais materiais/medicamentos em uma única requisição. Devendo permitir a impressão completa da requisição
18	O sistema deve contemplar rotina para balanço, prevendo mecanismos para abertura e fechamento de balanço
19	O sistema deve contemplar o registro das informações levantadas nos balanços por material/medicamento, podendo filtrar por grupo, subgrupo, descrição, código, visualizar lotes com validade vigente e todos os lotes com estoque maior que zero com possibilidade de alterar
20	O sistema deve permitir a emissão de relatório de listagem para balanço contemplando o código, a descrição, o lote e a validade do material/medicamento e quantidade registrada no sistema, conforme modelo a ser fornecido pelo setor responsável
21	O sistema deve permitir o lançamento de transferências entre estoques, contendo no mínimo: data, materiais/medicamentos com suas quantidades, lotes, validades, valores monetários vinculados (valor unitário, valor médio, etc.), valor total, estoque de origem e estoque destino. Deve haver recurso que permita confirmar a finalização do lançamento da transferência
22	O sistema deve permitir que durante o lançamento de transferências seja possível visualizar para cada item o histórico das transferências anteriores (com lote, validade, data e quantidade)
23	O sistema deve contemplar busca de transferências anteriores, onde deve ser possível filtrar pelo identificador da transferência, estoque de origem, estoque destino e data
24	O sistema deve contemplar rotina para confirmação da transferência entre estoques, contendo no mínimo estoque de origem, data, observação, usuário, código, material/medicamento, lote, validade e quantidade. Com possibilidade de selecionar os itens a serem confirmados, podendo rejeitar itens recebidos em desacordo (físico diferente do virtual)
25	O sistema deve possibilitar a impressão da transferência antes e depois de realizar a confirmação, com opção de listar apenas itens aceitos, rejeitados ou ambos
26	O sistema deve permitir o lançamento de saídas de materiais/medicamentos por centro de custo. Contendo no mínimo: data, material/medicamento, quantidade, lote, validade, valor unitário, valor total, estoque de origem (o que o usuário está logado) e centro de custo.
27	O sistema deve dispor de rotina que permita a busca de saídas por centro de custo. Deve ser possível filtrar no mínimo pelo identificador da saída, data e centro de custo
28	O sistema deve permitir o lançamento de saídas de materiais/medicamentos por paciente. A dispensação de medicamentos para pacientes pode ocorrer através de uma requisição eletrônica, prescrição de um profissional através de um atendimento, ou através de receita física apresentada pelo paciente no momento da retirada. Deve contemplar no mínimo as seguintes informações: estoque onde a saída foi realizada (preenchido automático através do login conectado), centro de custo, data, paciente, profissional prescritor. Deve registrar os itens de cada saída, registrando as seguintes informações: medicamento, forma de apresentação, dose, posologia, lote (apenas lotes cadastrados para o medicamento selecionado) e validade (automático a partir do lote), quantidade – selecionar dos itens em estoque através de uma consulta rápida pelo medicamento
29	Durante a dispensação de materiais/medicamentos deve permitir informar data início e término do tratamento e número de dias de tratamento, com cálculo automático da quantidade a ser fornecida e opção de informar a quantidade real fornecida
30	Para dispensação com requisição eletrônica, as informações devem vir preenchidas automaticamente, onde o profissional que dispensa apenas marca quais os itens da receita estão dispensando, o sistema deve lançar automaticamente quais os itens daquela requisição foram entregues, deixando em aberto os demais itens para que possam ser retirados em outro estabelecimento de saúde
31	Deve contemplar rotina para dispensar medicamentos das demandas especiais com autorização de dispensa emitida. O sistema deve solicitar que o usuário que estiver dispensando ajuste o cadastro do paciente da demanda (quando este for provisório) obrigando a informar a partir do cadastro único de pacientes qual o registro corresponde ao paciente relacionado na demanda (já deve vincular o cadastro provisório ao cadastro definitivo do paciente). Só deve permitir a dispensação dos itens relacionados na autorização das demandas que possuírem pacientes definitivos vinculados
32	Deve possibilitar alteração das quantidades no momento da dispensação
33	Caso o material/medicamento exija lançamento de receita na dispensação, o sistema deve exigir o registro desta informação para poder confirmar a dispensação
34	As funcionalidades de lançamento de saídas devem possuir mecanismos de facilitação de busca de pacientes e materiais/medicamentos prevendo busca combinada de campos
35	As funcionalidades de lançamento de saídas devem prever o registro de observações, sempre armazenando o registro do profissional que efetuou a movimentação
36	O sistema deve manter registrado todo o histórico de medicamentos fornecidos ao paciente, dentro de toda a rede de saúde
37	O sistema deverá permitir uma consulta a todas as saídas por paciente, com possibilidade de impressão, podendo filtrar por identificador da saída, paciente e período. Deve permitir detalhar os itens das saídas mostrando seus respectivos dados de quantidade, lote, validade, número do processo judicial (quando houver)
38	O sistema deve possibilitar gerar comprovante de requisição e do comprovante da dispensação, de acordo com modelo a ser fornecido pela CONTRATANTE
39	O sistema deve permitir a impressão do comprovante de requisição e do comprovante da dispensação prevendo espaço para assinatura do paciente e profissional dispensador
40	Nos lançamentos que envolvam movimentações de estoque o sistema deve selecionar automaticamente o lote a vencer primeiro, com possibilidade de alterar o lote
41	O sistema não deve contabilizar como consumo as devoluções, perdas registradas, vencidos e empréstimos
42	Deve ser possível emitir relatório de saídas, identificar as dispensações que ocorreram filtrando por tipo, período, profissional que prescreveu, material/medicamento, estoque e/ou login que dispensou, e listando os pacientes com seus respectivos itens
43	Deve ser possível emitir um relatório de utilização por profissional, onde será possível identificar os medicamentos/materiais mais receitados por profissional filtrando por período, estoque, profissional e listando todos os medicamentos/materiais, forma de apresentação e suas quantidades
44	Deve ser possível emitir um relatório de medi camentos a vencer: deve ser possível identificar os medicamentos que vencerão por período, grupo e estoque, informando a quantidade de dias a ser considerada para vencimento (padrão 30 dias). Deve permitir agrupar por grupo e/ou estoque
45	Deve ser possível emitir um relatório de lote por validade, onde relaciona os materiais/medicamentos em ordem cronológica de vencimento, com possibilidade de selecionar o grupo de materiais e medicamentos, o período de validade, e todos os lotes ou somente aqueles com estoque maior que zero
46	Deve ser possível emitir um extrato por material/medicamento, onde fornece a movimentação do material/medicamento por competência, com informações sobre saldo inicial, saldo final, relação das saídas e entradas, tipos de saídas e entradas, quantidades, preço médio. Permitir a emissão do relatório com possibilidade de seleção com lote ou sem lote e com ou sem validade
47	Deve ser possível emitir um extrato por paciente, onde deve ser possível identificar todos os medicamentos/materiais dispensados para o paciente num determinado período dentro de toda a rede de saúde, inclusive com os valores (custo) relacionados
48	Deve ser possível emitir o relatório de entrada por material/medicamento, onde fornece a relação de entradas de material/medicamento, contempla no mínimo as seguintes informações: data, material/medicamento, fornecedores, quantidades e valores
49	Deve ser possível emitir o relatório de transferência entre estoque, relaciona as transferências ocorridas em determinado período, estoque origem e estoque destino e relação de itens
50	Deve ser possível emitir o relatório de consumo por curva ABC, relaciona o consumo dos materiais/medicamentos de acordo com a curva ABC – valores ou quantidades, de determinado período e grupo de materiais/medicamentos, podendo ser obtido de cada estoque individual ou somatório de todos
51	Deve ser possível emitir o relatório de consumo por grupo de reposição, fornece o histórico de consumo de determinado grupo de material/medicamento, mês a mês, dos últimos seis ou doze meses e a média de consumo. Pode ser por estoque individual ou coletivo. Permitir cruzar as informações do onde o relatório está sendo gerado com o consumo dos demais estoques. Possibilidade de gerar o relatório com ou sem a informação do ponto de pedido, deve ser possível selecionar os centros de custo e saída por paciente a serem consideradas no consumo
52	Deve ser possível emitir o relatório de movimentação de controlados, o relatório deve contemplar as informações necessárias definidas pelas normas da ANVISA. Deve permitir filtrar por período ou por competência e por material/medicamento, trazendo no mínimo as seguintes informações: medicamento, relação de pacientes (com CNS), datas das saídas, número da notificação da receita, entradas, saídas, lote, profissional prescritor, saldo e estoque anterior
53	Deve ser possível emitir o relatório de balanço, relaciona as informações oriundas dos inventários, relação de materiais/medicamentos, quantidades, cálculo do erro e acuracidade
54	Deve ser possível emitir o relatório de demonstrativo saída x itens, relaciona o número de saídas por pacientes, por materiais/medicamentos, por centro de custo e o número médio de itens por saída, durante período de tempo selecionado. Podendo agrupar mensalmente as informações do relatório
55	Deve ser possível emitir o relatório de transferências podendo filtrar por situação (confirmadas, rejeitadas, pendentes, etc.) e período. Permite visualizar todas as transferências em toda a rede, contendo estoque de origem, estoque destino, período, número do documento, observação e usuário responsável pela requisição
56	Deve ser possível emitir o relatório de consumo por material/medicamento por centro de custo, onde permita visualizar o consumo histórico de 6 meses ou um ano (mês a mês) por serviço (com opção de visualizar todos os serviços no mesmo relatório) de determinado material/medicamento
57	Deve ser possível emitir o relatório de previsão de falta, com base na média de consumo histórico, discrimine os itens que provavelmente entrem em falta em período a ser selecionado (30, 60, 90 dias, etc.)
58	O sistema deve prever integração com o sistema Hórus do MS ou outro que venha a substituí-lo
59	O sistema deve permitir a impressão da receita após a dispensação do medicamento, já com registro da primeira dispensação e espaço para registro manual das seguintes, conforme modelo a ser fornecido pelo setor responsável
60	O sistema deve estar preparado para a possibilidade de configuração e impressão de informações sobre posologia/cuidados especiais em etiquetas, conforme modelo a ser fornecido pelo setor responsável
61	Deve dispor de rotina que permita consultar as autorizações de dispensação emitidas a partir das demandas especiais.
62	O sistema deve ter a opção de rastrear lotes, ou seja, poder identificar quais pacientes receberam os medicamentos do lote consultado, identificando pacientes (os dados que devem ser exibidos devem ser definidos em conjunto com o setor responsável), datas e locais
63	O sistema deve ter rotina para impedir a utilização de forma imediata de lotes, o operador do setor responsável, com permissão, bloqueia a utilização de determinado lote e informa o motivo do bloqueio, dessa forma o usuário que fará o lançamento da dispensação do medicamento deve ser alertado que não deve dispensar o lote bloqueado
64	O Sistema deverá permitir cadastrar produtos de acordo com os grupos, por exemplo: medicamentos, material médico-hospitalar, material odontológico, material de expediente, higiene e limpeza, etc
65	Deve possuir a opção de cadastro de Subgrupo e Subclasse para cada grupo ou produto.
66	Deve permitir informar se o produto tem perfil para Atenção Básica, Atenção Especializada ou Ordem Judicial e ainda permitir a inclusão de novos perfis
67	Deve permitir informar o estoque mínimo, estoque máximo e estoque de controle para cada produto em cada farmácia ou unidade que o mesmo se encontre para dispensação ou transferência
68	Deve possuir nome químico e marca do respectivo fabricante quando da entrada da nota fiscal
69	Cadastro da Apresentação (Comprimido, cápsulas, injetáveis, unidades, pasta, creme...)
70	Cadastro de Concentração (100 mg, 200 mg…)
71	Classificação terapêutica principal (Anti-hipertensos, hipoglicemiantes, antiácidos...)
72	Controlar lote e validade opcional de acordo com o tipo do produto no cadastro do produto
73	Controle do Tipo de distribuição (se saída por transferência ou pelo paciente na farmácia)
74	Cadastro da Logística do Estoque contendo: Observação, Rua, Quadra, Estante, Lado
75	No cadastro do produto conter o estoque mínimo para o período pré-determinado em dias
76	Cadastro de fornecedor completo com endereço, razão social, CNPJ
77	Cadastro de Fabricantes lotes e validades deverão ser atrelados à entrada da nota fiscal bem como o valor do produto
78	Classificação se psicotrópico ou antimicrobiano seu respectivo DCB e portaria
79	Toda categorização de psicotrópicos e suas descrições de acordo com o preconizado na SNGPC (Sistema Nacional de Gerenciamento de Produtos Controlados) ANVISA a saber: A1, A2, A3, B1, B2, C1, C2, C3, C4, C5, D1, D2, E e F
80	Posologia Padrão para medicamentos
81	Na saída de medicamentos, o sistema deve avisar:
82	Se o paciente tem alergia a medicamentos,
83	Campo de observação vinculada a saída do estoque,
84	Na saída de medicamentos psicotrópicos das categorias B1 e B2 deverá obrigatoriamente registrar o número da notificação (azul) de controle da vigilância sanitária
85	Permitir dar a saída de medicamentos automaticamente pela leitura do código de barras da receita médica, o sistema deve carregar os medicamentos receitados e escolher o mais próximo do vencimento na farmácia pelo ponto de acesso do operador
86	Permitir exportar as informações do conjunto de dados definido na Portaria GM/MS nº 271/2013, que instituí a Base Nacional de Dados de Ações e Serviços da Assistência Farmacêutica, no âmbito do Sistema Único de Saúde (SUS), estabelecendo o conjunto de dados, fluxo e o cronograma de envio referente ao Componente Básico da Assistência Farmacêutica, garantindo a interoperabilidade com o Serviço de webservice, disponibilizado pelo Ministério da Saúde no sistema HÓRUS
87	O sistema deverá possuir o recurso de solicitação dos pedidos através da web na seguinte forma: As solicitações deverão possuir o status de solicitação aberta e solicitação concluída desta forma as unidades integradas poderão começar suas solicitações e irem incluído os produtos no decorrer do período e quando concluírem então as solicitações aparecerão (serem visualizados) nas unidades distribuidoras
88	Na solicitação o sistema deverá permitir informar: unidade solicitante, setor, unidade distribuidora, data e produtos
89	Na distribuição origem do estoque deverão aparecer apenas os pedidos concluídos mostrando o estoque do respectivo produto na unidade solicitante, após a distribuição o sistema deverá gerar um guia com a relação dos produtos lotes e validades na forma de declaração de recebimento este guia deverá acompanhar o produto até o destino para conferência e assinatura pelo responsável
90	Quando da distribuição através do sistema ele deverá retirar o produto do estoque de origem e armazenar em forma de quarentena virtual para posterior Confirmação pela unidade de destino podendo o recebedor do produto fazer a confirmação parcial ou total estornando o produto a quarentena
91	O sistema deverá permitir padronizar produtos para cada unidade de forma que: uma unidade básica só visualize e possa pedir produtos padronizados para aquela unidade básica
92	Deverá permitir consulta ao registro do histórico de atendimento do paciente, assegurando a rastreabilidade do produto dispensado (registro de lote e validade)
93	Opção para impressão do recibo de retirada de medicamentos em impressora não fiscal
94	Permitir a saída dos medicamentos com leitora de código de barras, a partir da prescrição do profissional
95	Cadastrar medicamentos com código de barras, ponto de reposição, classificação, unidade de medida e componente ativo
96	Cadastrar múltiplos almoxarifados, unidades e setores dentro de uma unidade de saúde.
97	Exportador Hórus:
98	Deverá conter tela com data inicial, final, tipo de exportação (entrada de produtos, saída de produtos, dispensação de produtos por paciente) e destino.
99	Deverá exportar via Webservice o arquivo para o Hórus
100	Deverá constar os protocolos dos envios, com datas de produção.
101	Deverá mostrar inconsistências em cada envio, para possíveis correções
102	Deverá gerar os seguintes relatórios, podendo filtrar por Estoque, grupo, Subgrupo, Especificidade, Grupo Programação, Conta contábil:
103	Inventário de Estoque
104	Transferência entre setores
105	Saída por Grupo
106	Saída por Ação Terapêutica
107	Produtos por paciente
108	Saída de controlados por DCB
109	Entrada de produtos (por produto, unidade, fornecedor…)
110	Posição de Estoque por lote
111	Posição de Estoque por produto
112	Medicamento por ação terapêutica
113	Por nota fiscal de entrada
114	Histórico de consumo
115	Quantidade em Estoque x Consumo Médio Mensal x Previsão de Uso x Perda Prevista de Estoque (local de acondicionamento) por Produto
116	Por materiais/medicamentos.
117	Relatório financeiro mostrando qual valor gasto por unidade em um determinado período, sendo no mínimo 12 meses
118	Relatório de médias de consumo por unidade de cada item em um período solicitado. Sendo o período máximo de um ano. Contendo médias em quantidades de consumo e não em valores
119	No relatório Análise/Previsão de Média de Consumo deve possuir os filtros: Origem da informação, Saídas por paciente, Saída por centro de custo Todas as saídas, Transferências de Saída, Transferências e Saídas, Imprime zerados, Ambos como [Default], Sim e Não
120	O sistema deverá ter opção de saída para outras unidades de saúde. Com os seguintes tipos de saída: doação, empréstimos, por perda e por medicamentos vencidos
121	O sistema deve permitir entrada de doação, permuta e empréstimo
122	Relatório de saída de pacientes, por faixa etária, sexo e Unidade de Saúde
DEMANDA JUDICIAL
1	Este módulo deverá registrar as demandas de ordem judicial filtrando as ocorrências por: número do processo, réu, por data do processo, estado (pendente, cumprido, devolvido) e tipo de ação (ordem de tratamento, fornecimento de medicamentos)
2	No cadastro, além dos dados supracitados, deverá registrar:
3	Autores por tipo
4	Medicamento com quantidade solicitada
5	Histórico com dados da ocorrência - unidade, fórum, instância, advogado e juiz
6	Deverá gerar os seguintes relatórios:
7	Sintético por Valor Total
8	Sintético por Medicamentos
9	Analítico por Saída de Estoque
CORREIO INTERNO
1	Deve possuir modulo que permita a comunicação entre os operadores/usuários do sistema
2	Deverá permitir aos usuários do sistema enviar mensagens de texto livre para outros usuários e grupos
3	Deve possuir editor de texto para formatar a mensagem
4	Deverá permitir aos usuários anexar à mensagem arquivos do tipo PDF ou JPG no limite de tamanho do arquivo de até 2MB
5	Emitir alerta das mensagens do usuário com fácil acesso ao correio eletrônico
6	Permitir ao usuário/operador gerenciar as mensagens recebidas, enviadas e excluídas
HOSPITALAR
1	O Sistema deverá permitir a caracterização do Hospital com todos os setores, quartos e leitos, para proceder com o internamento do paciente (termo de responsabilidade pela internação e alta do paciente)
2	Deverá possuir toda parte de atendimento Médico no prontuário Hospitalar completo (prescrição de medicamentos, exames, evolução do paciente, dieta alimentar e demais cuidados Médicos) com a opção da visualização do Prontuário ambulatorial
3	O sistema deverá permitir o cadastro de AIH – modelo padrão DATASUS, com opção de impressão do laudo de solicitação de internação Hospitalar
4	Após cadastro da AIH, permitir pesquisar as AIHs emitidas, gerando sequência inicial de AIH, competência de apresentação e opção de confirmação e impressão do Laudo
5	Deve possuir Evolução de Enfermagem com todos os serviços de atendimento de Enfermagem
6	Deverá possuir os módulos: controle de estoque, procedimentos de enfermagem, imunização
7	Deverá permitir lançar todas as despesas e receitas do hospital
8	Deverá permitir ao médico indicar a dieta do paciente, gerando o mapa das dietas nutricionais solicitadas ao serviço de cozinha informando o setor, quarto, leito e paciente
9	Deverá permitir informar ao laboratório o setor, quarto, leito, exames solicitados e nome do paciente
10	Deverá emitir a conta do paciente com todos os custos da internação e tratamentos integrados com a assistência ambulatorial em um determinado tempo, dividindo por convênio
11	Controle do Número/código de Internação de acordo com o padrão do Ministério da Saúde tabela unificada
12	Impressão do laudo da AIH´s conforme layout DATASUS
13	Controle de AIH`s por prestadores e cotas a partir do módulo Autorizador de AIH`s
14	Importação de lotes de cobrança de AIH's e automação do SIHDD
15	Estatísticas por doenças, tempo médio de internação por profissionais/leitos, hospitais, períodos e etc
16	Importação da produção ambulatorial (hospitalar) com todas as informações contidas no BPA, para importação direto no SIASUS
LABORATÓRIO
1	O módulo laboratório de análises clínicas deverá permitir minimamente gerir as seguintes etapas da solicitação a entrega do resultado de exame: Recebimento do material biológico no laboratório (Coleta), Emissão de mapas de trabalho, Digitação do resultado dos exames, Confirmação eletrônica do resultado e a liberação ou entrega do exame para o destinatário
2	Deve ser integrado com o cadastro único de pacientes e profissionais de saúde
3	Permite o cadastro de todos os exames e itens de exames, bem como listar tipos de materiais de coleta e métodos
4	Permite controle de coleta de exames informando o nome do paciente e estabelecimento prestador, exibindo os exames da data, hora e local da coleta
5	Deve exibir na coleta de exames os registros ou agendamentos de exames para coleta, exibindo o código, descrição do exame, data do agendamento, data prevista para o exame, e o nome do estabelecimento solicitante
6	Emitir etiqueta de código de barras na coleta do exame, identificando na etiqueta o primeiro nome do paciente, código do agendamento, abreviação da descrição do exame para identificação
7	Permite emissão de folhas ou mapa de trabalhos para preenchimento manual com agrupamento de exames
8	Permitir a qualquer momento a inserção de exames na lista do prestador, bem como parametrizações de métodos, materiais de coleta, valores de referência na respectiva configuração dos laudos de exames
9	Permite a entrada de resultados manuais exibição bem como a exibição em destaque de valores de resultados digitados fora dos valores máximos e mínimos de referência.
10	Permite a visualização dos resultados autorizados em portal de acesso WEB para os pacientes com acesso restrito por usuário e senha ou dentro da solução de software para usuários operadores com privilégios de acesso à funcionalidade
11	Deve ser visível os respectivos resultados dos exames confirmados dentro do módulo Prontuário Eletrônico do Paciente-PEP; sendo possível ser acessado de qualquer setor/estabelecimento de saúde pelos usuários operadores com privilégios de acesso ao sistema
12	Sistema deve bloqueia a impressão dos resultados de exames ou exibir uma indicação de que os mesmos não estejam confirmados e liberados para entrega
13	Permite confirmação eletrônica do resultado, registrando data, hora e profissional que confirmou o exame
14	Sistema deve exibir no rodapé da página do resultado de exame a data e hora da confirmação bem como o usuário que gerar a impressão do resultado
15	Sistema deve gerar relatórios estatísticos de produção por Unidade e Profissional solicitante dos exames, bem como da unidade onde estes são realizados
16	Possuir módulo de consulta de resultados de exames restritos
17	Controle do processo de entrega de resultados dos exames aos pacientes, gerando um registro de controle de entrega registrando num campo de texto livre quem fez a retirada dos exames, ou escolhendo uma opção para registrar que o próprio paciente retirou ou foi entregue os respectivos exames
18	Relatório estatístico de produção identificando quantidades e valores dos exames, exibindo no mínimo a seguintes informações de quantidade de cada exame e valor, ou agrupando os mesmos dentro do grupo e subgrupo de procedimentos padrão SIGTAP
19	Permitir o agendamento de exames através da inserção manual dos dados para respectiva autorização de exame, com pelos menos os seguintes campos: Unidade Solicitante, Paciente, Profissional Solicitante, tipo de exame Laboratorial ou não Laboratorial, Unidade Prestadora/Executante, os itens de exames, quantidade, data e hora prevista da realização
20	Permitir o agendamento de exames através da guia de requisição de exames emitida no atendimento do prontuário eletrônico
21	Na guia de autorização ou registro dos exames deve ser possível a inserção de observações ou orientações de preparo para realização de cada exame, essas informações devem estar visíveis na guia de autorização dos exames para o paciente
22	Permitir o acesso dos exames solicitados ao paciente por meio de código de barras, ou número da solicitação ou apenas com o nome do paciente
23	Permitir a configuração de alertas de pânico e resultados fora do normal
24	Permitir o controle de interface de equipamentos através de módulo específico
25	Manter auditoria de resultados, informando quem autorizou, desautorizou, digitou e imprimiu o resultado
26	Emitir notificação compulsória para análise e controle da Diretoria de Vigilância Epidemiológica
27	Controle por usuário das diversas etapas de realização do exame, identificando o responsável de cada etapa
28	Controle de atendimento no laboratório de pacientes externos com pedidos de exames de fora da unidade
29	Possuir módulo de consulta de resultados, permitindo avaliar um determinado exame graficamente em sua evolução com, pelo menos, os três últimos resultados
30	O sistema deverá permitir interfaceamento com equipamentos de elaboração de exames, bem como garantir que o mesmo esteja sempre funcionando mesmo caso haja troca dos aparelhos utilizados;
31	No atendimento deverá estar disponível a emissão de preparo do paciente para realização dos exames
32	Possibilidade de edição/alteração dos modelos de laudos e emissão de laudos
33	Listar em Tela a situação dos exames, contendo no mínimo, exames sem laudo, com falta de coleta de material, Exames com os laudos emitidos, retirados, cancelados e liberados
34	Cadastro técnico de exames contendo setor de realização do exame, laboratório responsável pela realização do exame, método de realização, volume de coleta, frasco para coleta, material a ser coletado
35	Emissão de relatório de produção, por profissional, por usuário, por recurso, contendo no mínimo, quantidade executada, valor faturado dos exames e demais procedimentos realizados em conjunto
36	Permitir anexar documentos complementares ao laudo do exame de imagem
37	Permitir anexar resultados de exames terceirizados diretamente ao prontuário do paciente
38	Permitir que o médico ou enfermeira visualizem no prontuário se o paciente tem algum exame que tenha sido solicitado recoleta, e o motivo da mesma
PAINEL ELETRÔNICO DE CHAMADO
1	O Módulo WEB deverá permitir a visualização de Painel Eletrônico compatível browsers “navegadores de internet” mais comuns do mercado como Mozilla Firefox versão 84.0 ou superior bem como Google Chrome versão 72.0 ou superior, possibilitando a extensão do referido painel para um monitor ou TV visível para os usuários do serviço (pacientes) em formato de uma nova janela do browser/navegador que seja independente da janela principal de operação do usuário sistema
2	O módulo deve possibilitar o controle do fluxo de “Filas” de pacientes que estejam aguardando atendimento de serviços de saúde ofertados no respectivo estabelecimento, sejam eles por exemplo: Agendamento de Consultas, Agendamento de Exames, Entrega de Medicamentos na Farmácia, Procedimentos Ambulatoriais, Atendimento Odontológico entre outros
3	Sistema deve possibilitar um cadastro de Guichê ou setor para referenciar o tipo de atendimento realizado no respectivo Guichê ou setor
4	Sistema deve possibilitar um cadastro de Tipos de Atendimentos onde seja possível o cadastramento de uma abreviação ou sigla, a descrição do atendimento, e o vínculo com a unidade saúde que esse atendimento gerado pertence, bem como permitir definir se esse tipo de atendimento estará ou não vinculado ao painel do sistema visível pelo Totem de autoatendimento, sistema deve permitir gravar, editar e excluir tipos de atendimento quando necessário
5	Sistema deve possibilitar um cadastro para geração das senhas, referenciando qual o estabelecimento/unidade de saúde pertencem a respectiva geração das senhas, bem como o tipo de atendimento, a data da geração e validade das senhas, hora inicial e hora final de validade das senhas, bem como o número inicial e número final de senhas geradas, sistema deve possibilitar também a geração de senhas com nível de prioridade Normal, Senhas Prioritárias (Gestantes, Idosos até 79 anos, Pessoas com crianças de colo, Portadores de necessidades especiais) e Senhas Prioritárias + (Pacientes com mais de 80 anos), bem como permitir a exclusão das senhas geradas para reconfiguração se necessário
6	Deverá organizar as filas de espera de acordo com a retirada de senhas que pode ser pelo próprio paciente escolhendo a opção do atendimento através de totens de autoatendimento e ou distribuições manuais de fichas de controle de filas, que devem ser acompanhadas o chamamento das fichas através de um Painel Público de chamado, devidamente instalado e visível no local de espera das filas dos respectivos pacientes
7	O sistema deve permitir chamar a senha exibindo-a no Painel Público pelo número e ou código de abreviação do serviço referenciado, bem como permitir a emissão de sinal sonoro para chamado dos pacientes
8	Para o caso do atendimento médico o sistema deverá permitir ao profissional do consultório chamar o paciente através do botão de chamado presente na tela da agenda de atendimento de consulta do respectivo profissional
9	Quando o profissional executar o chamado selecionando o paciente escolhido na tela de agenda do profissional, o sistema deverá mostrar o nome do usuário (paciente), a sala ou consultório e nome do profissional que está chamando para atendimento, sendo essas informações exibidas no Painel de Chamado devidamente instalado nos locais de espera dos pacientes
10	O sistema deverá emitir um sinal sonoro e mostrar no mínimo as últimas 03 chamadas na tela do Painel de Chamado de Senha
REGULAÇÃO
1	Possibilita atribuir cotas de agendamento para cada especialidade ou procedimento para recursos externos pactuados
2	Possibilita implementar o conceito de central de marcação de consultas e procedimentos para as unidades de saúde
3	Permite registrar o nível de prioridade clínica (caracterizar como P1, P2, P3), podendo configurar até 5 escalas como exemplo: normal ou baixo, médio, prioritário, alto ou urgência, crítico ou emergência) podendo configurar a descrição e a cor de cada uma das escalas definidas
4	Permite cadastrar previamente a tabela de procedimentos ambulatoriais do SUS (SIA/SUS)
5	Permite acompanhar os atendimentos dos Usuários inscritos em Programas
6	Permite ao usuário consultar as informações das importadas da Tabela Unificada de Procedimentos e de suas tabelas auxiliares, bem como cadastrar os procedimentos não padronizados, ou seja, que não são regulados pelo Ministério da Saúde e, por isso, não são importados da tabela SIGTAP
7	Permite consultar os tipos de financiamento importados para o sistema, que consistem na origem do capital que financia a realização de um procedimento
8	Permite ao usuário efetuar a consulta das modalidades, ou seja, os tipos de utilização nos quais o procedimento pode ser realizado
9	Permite acompanhar as solicitações na fila de regulação do tipo: Consulta, Exame, APAC, AIH (Eletiva e Urgência)
10	Permite filtrar as solicitações por: usuário do serviço, unidade de saúde, gravidade, número de protocolo, por faixa de data e por status.
11	Os status devem ser classificados em: Autorizados, solicitados, devolvidos, em análise, cancelados e negados
12	No registro de nova solicitação para envio à regulação, deverá permitir filtro dinâmico por tipo (Consulta, exames, APAC, …) onde os campos devem corresponder a cada solicitação, bem como registrar a gravidade devidamente pré-configurável
13	Na solicitação de AIH, além dos dados básicos como nome do paciente, unidade, Profissional Solicitante, CID e procedimento; deverá carregar os campos para preenchimento na solicitação de internação como: Tipo do leito, anamnese (PA, Temperatura, Pulso, Frequência Respiratória e Saturação), motivo da referência, principais sintomas, justificativa de internação e campo de observação na justificativa de envio para regulação em vermelho acredito que possa tirar OBS: SOMENTE O CENTRO DE ESPECIALIDADES DEVERÁ GERAR AIH
14	Deverá possuir exibir o prontuário do paciente na mesma tela de solicitação.
15	Permitir anexar arquivos de imagem como documentos, resultados de exames, etc. do tipo .pdf, jpg…
16	Deverá possuir perfil regulador para análise das solicitações supracitadas enviadas pelas unidades de saúde, onde seja possível ao gestor da regulação: autorizar, manter solicitado, devolver, negar, manter em análise ou cancelar. Onde seja possível o regulador:
17	Para as ações de autorização, registrar justificativa, permitir ao regulador alterar a classificação, gravar em regulação, gravar enviando à lista de espera ou gravar enviando ao agendamento - neste caso deverá carregar automaticamente o módulo de agendamento de consultas ou exames
18	Permitir ao regulador, consultar em tela os resultados de exames, acesso ao prontuário do paciente e visualizar os arquivos anexados pela unidade solicitante
19	No campo justificativa, deverá carregar todo histórico dos registros de interação entre unidade solicitante e regulação, facilitando a avaliação do histórico de interação
20	Deverá disponibilizar relatório de convênio por:
21	Cotas de Consultas Especializada por Origem
22	Cotas de Exames por Origem
23	Valor de Exames por Convênio
24	Valor de CBO por Convênio
25	Relação de Prestadores por Convênio (Consultas e Exames
26	Serviços de prestadores
27	Relação de Conveniados
28	Deve bloquear as solicitações de Apac que constarem endereços (bairro cadastrado), que não seja compatível com a área a unidade de saúde solicitante
29	O Sistema deverá permitir migração de todos os dados do paciente
30	A empresa proprietária deverá ser a desenvolvedora do programa
31	Se o processo de conferência de dados pessoais existir, deverá constar um aviso de que a Apac foi liberada pelo setor de conferência (Setor de Controle e Avaliação), para quando chegar ao regulador o mesmo saber que a parte administrativa está correta ou em caso de discordância nos dados pessoais, ter a opção desse setor fazer a devolução a unidade de saúde solicitante, aparecendo alguma identificação para a unidade de saúde solicitante de que há pendência naquele encaminhamento
32	A empresa deverá prestar assistência técnica na cidade e em loco quando solicitado, com a maior brevidade possível
33	A tela de regulação de encaminhamentos deve possuir: Informação e contato” [Ícone]”, Tela criar/visualizar Informação e contato [Popup], Seção “Outros contatos” [Colapsavel mostrando últimos contatos], “Informação/Contato Nº:” “Situação no momento:” “Data/Hora:” “Usuário:” “Detalhes:” Seção “Dados do paciente”; “Nome:” [Informação], “Telefone:” [Informativo], “Telefone contato:” “Telefone celular:” Seção “Detalhes da informação/contato” [Campo texto] Data/Hora Agenda

A solução ofertada deverá rodar sobre o ambiente tecnológico existente na contratada. Os sistemas gerenciadores de bancos de dados, servidores web, sistemas operacionais ou aplicações que se façam necessárias para o pleno funcionamento da ferramenta, devem ser devidamente licenciados em nome da contratante, quando aplicável. Não serão admitidas licenças parciais ou que apresentem qualquer tipo de restrição de funcionalidade em relação a versão mais completa do produto licenciado. 7 DA APRESENTAÇÃO DOS SISTEMAS (PROVA DE CONCEITO) 10.1 .A apresentação poderá ser realizada pela licitante vencedora no dia do certame ou em até 05 (cinco) dias mediante agendamento do Pregoeiro para a comissão técnica nomeada pela contratante e todos os participantes da licitação interessados; 10.2. A licitante vencedora terá no máximo 4 (quatro) horas para realizar a sua apresentação, sendo que este prazo poderá ser prorrogado caso a comissão técnica julgue necessário; 10.3.É de responsabilidade da licitante levar o(s) equipamento(s) necessário(s) para realizar a sua apresentação; 10.4.A apresentação técnica (prova de conceito) é etapa da apresentação da proposta do procedimento licitatório necessária à aceitação da proposta melhor classificada; 10.5.Após terminada a apresentação dos sistemas, a comissão técnica elaborará Ata/Relatório informando se a licitante está apta ou não para fornecer a solução, sendo que este irá compor o processo licitatório; 10.6.Em caso da licitante vencedora ser considerada inapta pela comissão técnica será convocado a segunda colocada para realizar apresentação da sua solução, e assim sucessivamente; 8 DA CONDIÇÃO DE EXECUÇÃO 11.1.Para a operacionalização dos sistemas objeto deste certame e prestação de serviços técnicos de implantação, suporte técnico e manutenção deverão ser considerados as seguintes definições: 11.1.O serviço de implantação será composto pelos serviços de conversão, homologação, instalação e treinamento; 11.2.Fica estabelecido que melhorias da aplicação serão executadas posteriormente na fase de implantação seguindo cronograma estabelecidos e ajustados entre as partes; 9 DA IMPLANTAÇÃO 12.1.Todos os Sistemas licitados nesse certame deverão estar implantados no prazo máximo de 90 (noventa) dias contados da assinatura do contrato. Entende-se como implantados o conjunto de serviços necessários para instalar, migrar os dados ligados, colocar em funcionamento e deixar em condições de uso para os usuários executarem suas tarefas. O período de conversão, migração será executado pela Contratada e a análise e validação dos dados convertidos e migrados de bases de dados em operação será executada pela Contratante com apoio tecnológico da Contratada, nos 30 (trinta) primeiros dias do processo de implantação e em conformidade com o cronograma acordado entre as partes; 12.2.Os dados existentes tanto no sistema E-SUS quanto no sistema utilizado atualmente pela Secretaria Municipal de Saúde, deverão ser migrados para o sistema a ser contratado. Todo o processo de migração fica sob inteira responsabilidade da CONTRATADA; 12.3.Cronograma de implantação: a execução dos serviços deverá ser feita conforme Cronograma abaixo, iniciando em até cinco dias após a assinatura do contrato;

CRONOGRAMA
SERVIÇO(S)/ETAPA	DIAS CORRIDOS
Da instalação, configuração e parametrização dos Módulos do Sistema Informatizado de Gestão da Saúde Pública Configuração de Parâmetros e setup da aplicação (criação de Perfis e Usuários do Sistema Informatizado de Gestão da Saúde Pública	15
Importação de dados dos sistemas em uso (conversão) - Implantação/Carga dos dados Básicos (tabelas, questionários, documentos) do Sistema Informatizado de Gestão da Saúde Pública	45
Treinamento dos profissionais que executarão o Sistema Informatizado de Gestão da Saúde Pública nas Unidades de Saúde	30

10 TREINAMENTO 13.1. A licitante vencedora do certame deverá realizar treinamento, durante o processo de implantação, para os servidores municipais da Secretaria Municipal de Saúde que utilizarão os sistemas. Nesta etapa, a contratante deverá designar os profissionais responsáveis para os treinamentos futuros; 13.2. Para a execução do treinamento deverão ser consideradas as seguintes especificações: 13.3. A contratada deverá disponibilizar instrutor (es) qualificado (s) e com sólida experiência no assunto para ministrar os treinamentos. Devendo substituí-los a critério da Secretaria Municipal de Saúde, caso os mesmos não cumpram satisfatoriamente os objetivos do treinamento; 13.4. As capacitações ocorrerão por módulos (Sistemas) limitados a quantidade de 10 (dez) servidores por treinamento; 13.5.Todos os treinamentos deverão ser presenciais; 13.6 .A capacitação deverá ser realizada com carga horária mínima de 08 (oito) horas e máxima de 40 (quarenta) horas de acordo com a complexidade de cada sistema, cujo cronograma deverá ser acordado e homologado pela contratante; 13.7. As instalações físicas, equipamentos e materiais necessários para a aplicação dos treinamentos serão providenciados e disponibilizados pela contratante; 13.8. Deverá ser fornecido Certificado de Participação aos servidores que tiverem comparecido a mais de 85% (oitenta e cinco por cento) das atividades de cada curso; 13.9. Diariamente a Contratada deverá disponibilizar lista de presença dos servidores que compareceram as atividades e estas deverão ser assinadas pelos presentes; 13.10. Ao final de cada treinamento a Contratada deverá realizar processo de Avaliação sobre o treinamento realizado, objetivando a avaliação no mínimo do conteúdo treinado e do instrutor; 13.11. Os custos inerentes às despesas de hospedagem, alimentação e transporte serão arcados pela contratada; 13.12.Transcorrida a Etapa de implantação e expedido o Termo de Treinamento, caso a contratante requeira a realização de novos treinamentos in loco os mesmos serão acordados entre as partes; 11 SUPORTE TÉCNICO 14.1. A CONTRATADA deverá manter um consultor ou equipe local durante a implantação e treinamento do sistema, posterior a este período o suporte será oferecido por demanda; 14.2. A empresa contratada deverá disponibilizar uma central de atendimento, disponibilizado no mínimo 8 (oito) horas por dia de segunda a sexta-feira (dias úteis), sem limites de chamados mensais; 14.3. Novas implementações e melhorias, aprovadas entre as partes, deverão ser liberadas conforme cronograma de versões da Contratada planejados para o Sistema; 12 DAS OBRIGAÇÕES DA CONTRATANTE 15.1.Fiscalizar a execução do objeto, nos termos do disposto no artigo 67 da Lei 8.666/93, através do Fiscal do Contrato; 15.2.Solicitar, quando julgar conveniente, informações relativas ao fornecimento do objeto, sem que tal atividade implique em qualquer responsabilidade da Fiscalização sobre a ação da contratada; 15.3. Atuar da forma ampla e completa no acompanhamento do fornecimento do objeto, acompanhamento este que não eximirá a contratada das responsabilidades previstas quanto aos danos que forem causados à contratante ou a terceiros; 15.4.Proporcionar todas as facilidades para que a contratada possa desempenhar a plena execução do contrato; 15.5.Comunicar à empresa contratada todas e quaisquer ocorrências em desacordo com o cumprimento das obrigações pactuadas, qualquer anormalidade na entrega do objeto, podendo sustar ou recusar o recebimento, caso não esteja de acordo com as especificações e condições estabelecidas; 13 DAS OBRIGAÇÕES DA CONTRATADA 16.1. Executar os serviços conforme especificações do Termo de Referência dos seus anexos, do contrato decorrente e de sua proposta, com a alocação dos empregados necessários ao perfeito cumprimento das cláusulas contratuais; 16..2. Manter atualizada a versão do Sistema, esclarecer as suas alterações, mantendo-o em pleno funcionamento, dentro das características da concessão; 16.3.Corrigir eventuais defeitos nos programas em uso; 16.4.Alterar os Sistemas, quando solicitado pelo usuário, para adaptação a normas legais; 16.4.Esclarecer se consultada por via telefônica, correspondência, e-mail e comunicador interno, etc., dúvidas de operação do Sistema, excluindo os problemas relacionados com operação de equipamento ou dos utilitários quando a CONTRATANTE deverá recorrer a empresa vendedora; 16.5.Manter, durante a execução do contrato, em compatibilidade com as obrigações a serem assumidas, todas as condições de habilitação e qualificação exigidas neste Termo; 16.6.Solicitar por escrito a prorrogação do prazo de implantação, se ocorrer atrasos por motivos atribuíveis ao Município, pelo mesmo período do atraso, acompanhada da devida justificativa e sujeita à aprovação do mesmo; 16.7.Efetuar, quando necessário, alterações, melhorias e atualizações nos sistemas locados, que impliquem mudanças nos arquivos, novas funções/rotinas e relatórios, de forma a atender a legislação ou aperfeiçoamento gerencial; 16.8.Manter absoluto sigilo sobre quaisquer documentos, informações ou dados que tiver conhecimento ou acesso, em decorrência da execução dos serviços e não prestar declarações ou informações sem prévia autorização por escrito da CONTRATANTE a respeito do presente contrato e dos serviços a ele inerentes; 16.9. Responsabilizar-se pela orientação e treinamento aos usuários do Sistema; 16.10.Responsabilizar-se pela substituição dos Sistemas por versões mais atualizadas em função do aprimoramento técnico e/ou operacional; 16.11.Disponibilizar BANCO DE DADOS para conversão sempre que solicitado, sem ônus para a CONTRATANTE, principalmente no termino do contrato; 16.12. Apresentar Declaração que possui quadro técnico suficiente, tanto presencial como remoto, para atender toda a demanda do município, nos prazos estabelecidos no edital; 16.13. Apresentar pelo menos um atestado de capacidade técnica em referência ao objeto licitado; 14 DA DOTAÇÃO Projeto/Atividade: 2038 – MANUTENÇÃO DAS ATIVIDADES SERVIÇOS HOSPITALAR E AMBULATORIAL

Fonte de Recursos: 1.5.00.100.200 – Identificação das Despesas com Ações e Serviço Públicos de

Saude

225.10.302.0017.2038.3.3.90.39.00.00.00-OUTROS SERVIÇOS DE TERCEIROS

Projeto/Atividade:2040-GESTÃO SUS

Fonte de Recursos: 1.5.00.100.200 – Identificação das Despesas com Ações e Serviço Públicos de

Saude

235.10.30.0017.2040.3.3.90.39.00.00.00-OUTROS SERVIÇOS DE TERCEIROS

15 DA FISCALIZAÇÃO

Durante o período de Vigência da Ata de Registro de Preços os fornecimentos dos produtos serão fiscalização e

acompanhamento da execução do Contrato será realizada pela Fiscal de Contrato, Sra. MARIA LUIZA RUDNIK

DE OLIVEIRA, designada pela Portaria nº 027 de 05 de janeiro de 2021, observando-se as disposições contidas

no artigo 67 e parágrafos da Lei nº 8.666/93.

16 DO PAGAMENTO 19.1. O pagamento será efetuado em até 30 (trinta) dias úteis, contados da data de apresentação da Nota Fiscal/Fatura discriminativa, devidamente atestada pelo fiscal do contrato, onde a CONTRATANTE poderá deduzir do montante a pagar os valores correspondentes às multas ou indenizações devidas pela CONTRATADA, desde que não haja nenhum fato impeditivo; 17 DAS SANÇÕES ADMINISTRATIVAS 20.1.Pela inexecução total ou parcial do objeto licitado, a CONTRATANTE poderá, garantida a defesa prévia, aplicar à CONTRATADA as seguintes sanções: I – Multa administrativa no percentual de 01% (um por cento) por dia de atraso, a partir do primeiro dia útil subsequente à data limite fixada na programação da prestação do serviço, incidindo sobre o valor da obrigação inadimplida, até o percentual máximo de 20% (vinte por cento) calculado sobre o valor do contrato, o que não impede aplicação das demais sanções. II – Pela inexecução parcial ou total deste contrato, poderão ser aplicadas as seguintes sanções: a) Advertência; b) Multa indenizatória fixada em 20% (vinte por cento) do valor total do contrato, no caso de inexecução total, e de 1% (um por cento) até o limite de 20% (vinte por cento) sobre o valor da obrigação inadimplida, no caso de inexecução parcial do contrato; c) Suspensão temporária de participação em licitação e impedimento de contratar com a Prefeitura Municipal de Juruena-MT, nos termos da legislação vigente; d) Declaração de inidoneidade para licitar e contratar com a Administração Pública enquanto perdurarem os motivos determinantes da punição ou até que seja promovida a reabilitação, na forma da lei, perante a própria autoridade que aplicou a penalidade; 20.2.Se o CONTRATADO não proceder ao recolhimento da multa no prazo de 05 (cinco) dias úteis contados da intimação por parte da Prefeitura Municipal, o respectivo valor será descontado dos créditos que o CONTRATADO possuir com esta Prefeitura Municipal e, se estes não forem suficientes, o valor que sobejar será encaminhado para execução pela Procuradoria Jurídica. 20.3.As penalidades acima previstas só poderão ser relevadas nas hipóteses de caso fortuito ou força maior, devidamente justificado e comprovado, a juízo do Prefeito Municipal. 20.4.Do ato que aplicar a penalidade caberá recurso, no prazo de 05(cinco) dias úteis, a contar da ciência da informação, podendo a Administração reconsiderar sua decisão ou nesse prazo encaminhá-lo devidamente informados para a apreciação e decisão superior, dentro do mesmo prazo. 18 DA VIGÊNCIA

A vigência do objeto deste Termo de Referência será de 12 (doze) meses contados da data da assinatura do

contrato, podendo ser prorrogado nos ternos do Artigo 57 da Le nº 8.666/93 e alterações posteriores.

A prorrogação de que trata o item anterior, somente poderá ser feita através de Termo Aditivo.

Patrícia de Oliveira Moreira

Secretária Municipal de Saúde

Portaria 081/2021

– (...)

PASSA A SE LER:

6 (...) - FINALIDADE:

Contratação de empresa especializada em informatização de unidades de saúde, com sistema de controle de gestão de saúde, integrado através de prontuário eletrônicos as unidades de saúde, visando o aperfeiçoamento dos serviços prestados à população, com controle dos gastos públicos e levar o suporte necessário ao eficiente desempenho das atividades gerencias desenvolvidas pela secretaria municipal de saúde.

7. DO AMBIENTE TECNOLÓGICO E OPERACIONAL:

8. DOS REQUISITOS MÍNIMOS OBRIGATÓRIOS DA SOLUÇÃO OFERTADA:

O sistema de gestão de saúde ofertado deve ser desenvolvido para rodar sobre servidores de páginas de internet e ser acessado através de navegadores de internet, sem a utilização de qualquer tipo de emulador ou plug-in.

A solução ofertada deve ser compatível com os navegadores Mozilla Firefox, Chrome e Ópera, em suas versões atuais.

O sistema deve possuir mecanismo para integrar os seguintes sistemas disponibilizados pelo Ministério da Saúde: E-SUS, CNS, BPA Magnético, CNES, SIA, SISCTA, SIPNI, BNDASAF, SIGTAP, RPOM, devendo ser encaminhado mensalmente relatório para a secretaria municipal de saúde, dados dos envios de produção ao ministério da saúde. A empresa contratada, deve comprometer-se em realizar as atualização necessárias para as versões dos programas do ministério da saúde e disponibilizar em tempo hábil as novas integrações que possam ocorrer com os Sistemas disponibilizados pelo Ministério da Saúde através do DATASUS e/ou outros órgãos, os quais atualmente ainda não possuem layout aberto tais como: SISREG e outros que forem exigidos, considerando ainda sistemas posteriores a assinatura do contrato com layout aberto, sem qualquer ônus ao município.

O sistema deverá permitir a realização de tarefas concorrentes, com acesso simultâneo ao banco de dados, sem perder a integridade referencial.

O sistema gerenciador de bancos de dados utilizado pela solução deve ser baseado no conceito de controle de transação de dados, mantendo a integridade do banco de dados em caso de queda de energia e falhas de software e/ou hardware.

O sistema deve permitir o cadastramento de usuários com controle de nível de acesso aos módulos através de senhas de segurança para cada nível de usuário, as quais deverão ser criptografadas no banco de dados, podendo ser configurado para inclusão, alteração, consulta e exclusão.

Permitir auditoria automática das operações efetuadas no sistema, através de logs de acesso, de modo que seja possível identificar claramente as atividades de consulta, inclusão, alteração e exclusão de qualquer informação, inclusive aquelas relativas a administração da solução, de qualquer usuário, indistintamente, inclusive administradores. O log registrado deve permitir a identificação completa do dado que foi acessado/atualizado.

O sistema deverá possibilitar a personalização dos relatórios existentes no sistema por funcionários responsáveis da contratante.

A solução deve possuir mecanismo ou funcionalidade que permita a gravação dos relatórios gerados em arquivos compatíveis com os formatos texto (TXT), Rich Text Format (RTF), OpenDocument Format (ODT/ODS), XML (EXtensible Markup Language) e em formato PDF (Portable Document Format), permitindo a disponibilização para usuários finais, bem como impressão dos dados consultados.

O sistema deverá estar em conformidade com padrão SUS, sem a necessidade de redundância/duplicação de tabelas ou aquisição de quaisquer outros programas/sistemas.

O sistema deverá possuir controle de medicamentos constantes das listas da Portaria SVS/MS/Nº344, de 12 de maio de 1998 /98 (ANVISA) e suas alterações.

O sistema deverá utilizar vocabulários de procedimentos SIGTAP e vocabulário de diagnóstico CID-10.

O sistema em todos os seus módulos, no que diz respeito a camada de apresentação, constituída de telas, documentação e ajuda (Help), deverá estar redigida em idioma português do Brasil.

O sistema deverá possuir padronização do uso de botões de forma a facilitar o seu aprendizado e operação;

Disponibilizar ao usuário recursos de informação sobre o que um botão, menu ou ícone faz ao posicionar o cursor sobre ele;

Exibir mensagens de advertência ou mensagem de aviso de erro informando ao usuário um determinado risco ao executar funções solicitando sua confirmação;

O sistema deverá possuir/disponibilizar documentação, em meio eletrônico, referente aos seguintes aspectos técnicos: manual do usuário e manual de instalação e configuração;

A solução ofertada deve possuir mecanismo de assinatura digital de registro eletrônico em saúde em conformidade com os padrões de assinatura digital determinados pelo SBIS (Sociedade Brasileira de Informática na Saúde) e CFM (Conselho Federal de Medicina).

O sistema deverá integrar com os sistemas sociais existentes e desta forma os gestores poderão efetuar em um único ambiente consultas online.

A empresa deverá realizar a prestação de serviços de sistema de informatização das unidades para a gestão da Secretaria Municipal de Saúde, visando oferecer ao município o suporte necessário ao eficiente desempenho das suas atividades, tanto no sistema quanto na compilação dos dados, confrontando o aperfeiçoamento da gestão e a organização do Fundo Municipal de Saúde. A empresa devera possuir software que possa permitir o Gestor abrir chamado para empresa e acompanhar em tempo real os andamentos das solicitações realizadas pela equipe, visando o maior controle da oferta da prestação dos serviços.

9. DO TESTE DE CONFORMIDADE:

O teste de conformidade (prova de conceito) do software será apresentado mediante aplicação de amostragem da solução dos módulos de gestão solicitados. Havendo a necessidade, deverá ser nomeada uma Comissão de Avaliação Técnica, composta por no mínimo 03 (três) profissionais da área que de fato conhecem os processos e serviços a serem atendidos pelo sistema no contexto das atividades de Saúde e Tecnologia da Informação. No caso de solicitação, à licitante melhor qualificada deverá apresentar um ambiente operacional com o(s) módulo/software (s) ofertado, no prazo máximo de até 07 (sete) dias úteis depois de notificada pelo condutor do certame. Ao final desse prazo, o sistema apresentado (software) deverá estar em plenas condições operacionais, atendendo no mínimo 85% (oitenta e cinco por cento) dos requisitos constantes ao Módulo de Gestão ofertado, e de acordo com as exigências constantes deste Termo de Referência. O prazo poderá ser prorrogado por igual período, desde que solicitado à Administração do Munícipio de Juruena com antecedência de até 02 (dois) dias da apresentação, devidamente justificado e aprovado pela Administração do Munícipio. Os itens de serviços a serem submetidos e avaliados na prova de conceito pela Comissão designada, devem ser definidos, observados os requisitos mínimos exigidos nos itens: 7,8 e do 15 ao 46 e seus subitens, constantes deste Termo de Referência. As provas de conceito e amostragem será realizada em local a ser definido pelo condutor do certame licitatório, em ambiente devidamente adequado a realização de todos os testes e ensaios necessários, e na presença da Comissão de Avaliação Técnica designada. A Comissão Técnica de Avaliação deverá no prazo de até 03 (três) dias úteis, emitir um Parecer Técnico da Avaliação de Aprovação e/ou Reprovação dos Softwares apresentados. O licitante melhor classificado que não atender no mínimo 85 % (oitenta e cinco por cento) dos requisitos analisados na prova de conceito será inabilitado no certame licitatório, ficando desde já autorizado ao condutor do certame, convocar a empresa qual ficou em 2º (segundo) lugar, e assim, sucessivamente na ordem de classificação, e fará, mediante convocação pelo chat do sistema eletrônico específico. Em caso que a solução atender o mínimo de 85%, a Comissão Técnica de Avaliação deverá estipulara o prazo para a licitante providenciar o(s) item(s) faltante(s), sendo o prazo conforme a complexidade da parametrização/customização e/ou criação.

10. DO TREINAMENTO:

A empresa deverá levar treinamento e conhecimento para os operadores do programa de todas as funções do sistema pertencente a sua área de responsabilidade sem custos adicionais. Todos os recursos e material necessário para o treinamento deverá ser por conta da empresa contratada. As turmas devem ser dimensionadas por módulo, sendo que cada turma não poderá ter mais de 10 (dez) participantes para facilitar o entendimento e agilidade no aprendizado. A empresa deverá fornecer Certificado de Participação aos funcionários que tiverem comparecido a mais de 85% (oitenta e cinco por cento) das atividades de cada curso. As despesas relativas à participação dos instrutores e de pessoal próprio, tais como: hospedagem, transporte, diárias, etc. serão por conta da empresa contratada. A Contratante resguardar-se-á o direito de acompanhar, adequar e avaliar o treinamento contratado com instrumentos próprios, sendo que, se o treinamento for julgado insuficiente, caberá à Contratada, sem ônus para a Contratante, ministrar o devido reforço. A Contratante deverá fornecer um passo a passo dos módulos para cada profissional. Quando solicitado pela Contratante, a Contratada deverá providenciar alterações no programa de treinamento, incluindo recursos, instrutores, conteúdo, entre outros que se fizer necessário. A contratada deverá disponibilizar um técnico capacitado para acompanhamento da implantação e acompanhamento aos usuários. A empresa deverá fornecer uma central 0800 para atendimento 24 horas para tirar dúvidas sobre treinamentos realizados e outros assuntos pertinentes.

11. DOS LOCAIS DE IMPLANTAÇÃO:

LOCAL	ENDEREÇO	RESPONSAVEL PELA UNIDADE DE SAUDE	CONTATO
Hospital Municipal de Juruena Renilda de Fatima de Moraes	Travessa Lucinda Kniess, nº 17, Bairro Centro	Roseneide Souza Soares	66-3553 -1331 66 984324599
Hospital Municipal de Juruena Renilda de Fatima de Moraes – Setor de Raio X	Travessa Lucinda Kniess, nº 17, Bairro Centro	Edson Queiroz dos Santos	66-3553 -1331
Hospital Municipal de Juruena Renilda de Fatima de Moraes – Laboratório Municipal	Travessa Lucinda Kniess, nº 17, Bairro Centro	Angelita Maria Rodrigues	66-3553 -1331
Hospital Municipal de Juruena Renilda de Fatima de Moraes – Farmácia Interna Hospitalar	Travessa Lucinda Kniess, nº 17, Bairro Centro	Betiane Gaspari	66-3553 -1331
Estratégia de Saúde da Família Vila Nova Anelise Nazzato	Rua C2 – Bairro Vila Nova (próximo a Câmara Municipal dos Vereadores).	Zeli Cristina Rocha Dutra	66 3553 - 1932
Estratégia de Saúde da Família Neide Ubiali	Rua Belém, esquina com rua São Cristóvão, Bairro Vila Nova	Roseny Cesário	66 3553 1990
Estratégia de Saúde da Família Juruena Claudio Detz	Rua Paiaguas, Bairro Centro (próximo as Escola Municipal 7 de Maio)	Eder Moreira de Souza	66 3553 1943
Polo Academia da Saúde	Avenida da Independência (Praça Adirce Cortonezi)	Tatiana Rocha	66 3553 1593
Central de Imunização	Avenida da Independência (Praça Adirce Cortonezi)	Madalena Rocha dos Santos	66 3553 1593
Unidade de Reabilitação Juruena	Rua C2 – Bairro Vila Nova (próximo a Câmara Municipal dos Vereadores).	Danielly Borges da Silva	66 3553 1932
Farmácia Básica Municipal	Rua Paiaguas, Bairro Centro (próximo as Escola Municipal 7 de Maio)	Maykeli Wappler da Costa	66 3553 1943
Secretaria Municipal de Saúde	Avenida 04 de Julho – 811 – Centro	Maria Luiza Rudnik de Oliveira	66 3553 1593
Secretaria Municipal de Saúde – Setor de Faturamento, Processamento de Dados e Cartao SUS.	Avenida 04 de Julho – 811 – Centro	Cintia Lima Centurião
Secretaria Municipal de Saúde – Vigilância Ambiental	Avenida 04 de Julho – 811 – Centro	Edilson de Goes
Secretaria Municipal de Saúde – Vigilância Sanitária	Avenida 04 de Julho – 811 – Centro	Edilson Cardoso
Secretaria Municipal de Saúde – Vigilância Epidemiológica	Avenida 04 de Julho – 811 – Centro	Tatiana Rocha
Secretaria Municipal de Saúde – Setor de Compras	Avenida 04 de Julho – 811 – Centro	Maria Luiza Rudnik de Oliveira
Secretaria Municipal de Saúde – Central Municipal de Regulação	Avenida 04 de Julho – 811 – Centro	Alcione Valerio Dias
Secretaria Municipal de Saúde – Consorcio Intermunicipal Vale do Juruena	Avenida 04 de Julho – 811 – Centro	Alcione

12. DA VISITA TÉCNICA:

12.1 As empresas interessadas em participar do processo licitatório deverão efetuar visita técnica para conhecer as instalações e estrutura onde será implantado o sistema, a visita deverá ser marcada e efetuada até 03 (três) dias antes da abertura dos envelopes. 12.2 A visita será marcada com no período das 8:00 hs as 17:00 hs, havendo comprovante (certificado) da visita realizada o qual fará parte da documentação exigida na habilitação do processo licitatório. 12.3 A licitante receberá um comprovante (certificado) da visita realizada o qual fará parte da documentação exigida na habilitação do processo licitatório. 12.4 Caso a Licitante não possua interesse em realizar a visita técnica deverá apresentar declaração de que possui conhecimento das condições e locais das instalações, não podendo a mesma alegar desconhecimento ou impossibilidade de prestação do serviço futuramente, sendo de sua inteira responsabilidade atender aos requisitos do Termo Referência

13. DO SUPORTE TÉCNICO:

Durante o período contratual, a partir da parametrização do sistema e início das atividades de suporte, a contratada deverá garantir visitas técnicas no município quando necessário. Devendo atender a Contratante em horário de expediente: das 07:00 às 11:00 horas e das 13:00 às 17:00 horas, de segundas às sextas feiras. Conforme necessidade de: Esclarecer dúvidas que possam surgir durante a operação e utilização dos sistemas; Auxílio na recuperação da base de dados por problemas originados em erros de operação, queda de energia ou falha de equipamentos, desde que não exista backup adequado para satisfazer as necessidades de segurança; Treinamento de servidores na operação ou utilização do sistema em função de substituição de pessoal, tendo em vista demissões, licenças, mudanças de cargos, etc., Auxiliar o usuário, em caso de dúvidas, na elaboração de quaisquer atividades técnicas relacionadas à utilização dos sistemas, como: gerar/validar arquivos para Órgão Governamental, entre outros. Esclarecer dúvidas que possam surgir durante a operação e utilização dos sistemas; Auxílio na recuperação da base de dados por problemas originados em erros de operação, queda de energia ou falha de equipamentos. Treinamento de servidores na operação ou utilização do sistema em função de substituição de pessoal, tendo em vista demissões, licenças, mudanças de cargos, etc., Auxiliar o usuário, em caso de dúvidas, na elaboração de quaisquer atividades técnicas relacionadas à utilização dos sistemas, como: gerar/validar arquivos para Órgão Governamental, entre outros. No caso de parada do sistema, o atendimento de suporte deverá estar garantido durante o período necessário para reestabelecer suas funções normais, inclusive sábados, domingos e feriados. A Contratada deverá estar apta a acessar remotamente o sistema contratado em produção no cliente, de forma a poder verificar condições de erros que não possam ser reproduzidas em ambientes internos da empresa fornecedora do sistema. O prazo máximo para atender solicitações de suporte, deverá ser num prazo não superior a (uma) hora, viabilizando no caso da prioridade mais severa, em prazo não superior a (1) dia útil. Este prazo se inicia com a abertura do chamado técnico. A empresa deve fornecer o número 0800 para atendimento.

14. DO ATESTADO DE CAPACIDADE TÉCNICA:

As empresas interessadas em participar do processo licitatório deverão apresentar atestado (s) de capacidade técnica compatível com o objeto, podendo o mesmo ser emitido por pessoa jurídica de direito público ou privado; caso o atestado seja emitido por pessoa jurídica de direito privado, deverá, obrigatoriamente, ser apresentado com firma reconhecida em cartório;

Não serão aceitos atestados emitidos pela própria licitante.

TODOS OS MÓDULOS E SERVIÇOS DESCRITOS ABAIXO DEVEM ESTAR INTEGRADOS PARA ATENDER TODAS AS NECESSIDADES DA REDE MUNICIPAL DE SAUDE, GESTÃO, ESPECIALIDADES, HOSPITAL, ASSISTENCIAS FARMACEUTICAS, VIGILANCIAS, APLICATIVOS MÓVEIS E BI (CONTROLE DE AAVALIAÇÃO).

15. DOS CADASTROS E FUNCIONALIDADES GERAIS

Possuir cadastro de Bairros, Logradouros e Tipos de Logradouros.

Permitir vincular Bairros e Logradouros, a limitar os bairros que cada logradouro pode receber no cadastro dos usuários.

Possuir cadastro de Ceps.

Possuir cadastro de Motivos pelo qual o paciente não possui endereço fixo.

Possuir cadastro de UFs, Municípios e Localidades.

Possuir cadastro de Motivos de desativação dos Pacientes.

Possuir cadastro de Segmento, Área e Micro área.

Possuir cadastro de CBO (Código Brasileiro de Ocupações).

Possuir cadastro de Nacionalidades.

Possuir cadastro de Situações do Usuário.

Possuir cadastro de Órgão Emissor dos Documentos de Identidade

Possuir integração e funcionalidades para importar os dados do CARTAO SUS nacional.

Possuir cadastro de Programas de Saúde. 16. DO CADASTRO DE PACIENTES

Deve possuir cadastro de pacientes compatível com padrão SUS contendo no mínimo os seguintes campos: Nome, Data de Nascimento, Sexo, Número de Cartão SUS, Cor, Etnia, Nome do Pai e Mãe, Telefone, Celular, Telefone de Contato, Município, Logradouro, Número, Bairro, Complemento, Cep e Unidade de Saúde onde o mesmo foi cadastrado.

Deve possuir campos para informação de seu Nr. De CPF, Número de Identidade, Órgão Emissor e UF onde o documento foi emitido, Nr. de certidão de nascimento, Nome do Cartório, Tipo da Certidão Livro, Folha, Termo, Data de Emissão, Naturalidade, Religião, Carteira Profissional série.

Possuir campos para informação de dados da carteira de trabalho tais como: Número da Carteira Profissional, Série, UF, Data de Emissão.

Possuir campos para informação do Número PIS/PASEP

Possuir campos para registro do Número de Título de Eleitor, Zona e Seção do mesmo

Deve possuir campos para armazenamento da Latitude e Longitude da residência do paciente a ser utilizado em georreferenciamento.

Possuir campo para informar se o paciente é brasileiro (a) e caso não seja, qual sua nacionalidade.

Deve possuir no cadastro de pacientes campos para informação de escolaridade.

Campos para informar as pessoas com quem o mesmo divide a residência.

Deve possuir locais para informação de sua Altura, tipo Sanguíneo, e-mail.

Campo para informar se toma insulina e se possui algum tipo de alergia.

Deve possuir mecanismos para que os pacientes possam ser desativados, informando a data de sua desativação bem como o motivo pelo qual o mesmo foi desativado.

Possuir cadastro auxiliar para cadastramento de qualquer outro documento com a possibilidade de associação da Unidade de Saúde com o número do documento.

Possuir funcionalidade para registro das deficiências do paciente.

Possuir dentro do cadastro funcionalidade para emissão da ficha cadastral do paciente.

§ Possuir mecanismo para desativação de logradouros cadastrados incorretamente, migrando todos os pacientes do logradouro incorreto para o logradouro correto.

§ Possuir mecanismo para desativação de bairros cadastrados incorretamente migrando todos os pacientes cadastrados no bairro incorreto para o bairro correto.

§ Deve possuir funcionalidade para gerenciamento de emissão de cartões municipais de saúde, obedecendo o seguinte fluxo: solicitação, impressão de cartão provisório, envio para gráfica, retorno da gráfica e, entrega ao usuário ou cancelamento da solicitação.

§ Deve possibilitar personalização do modelo do cartão do munícipe.

§ Deve possuir funcionalidade para exportação dos dados necessários para emissão de cartões permanentes em formato CVS com os campos do cadastro de pacientes a serem definidos pela contratante.

§ Possuir cadastro de tipos de deficiências.

§ Possuir mecanismo ou funcionalidade para gerenciamento e emissão de DNV (Declaração de Nascidos Vivos) contendo as seguintes informações:

§ Código DNV, Ano, Código do Cartão, Número de Registro do Cartão, Data de Registro do Cartão, Código do Município do Cartão, Código do Estabelecimento de Saúde, local de nascimento (Hospital, Domicilio, Outros, Ignorado e Outro Estabelecimento de saúde), Logradouro, número, complemento, cep, bairro, município do nascimento, Nome da Mãe, número do CNS, Idade, Escolaridade (Nenhum,1 a 3, 4 a 7, 8 a 11, 12 ou mais e ignorado), ocupação, filhos vivos e filhos mortos, Dados do endereço da mãe contendo o logradouro, bairro, município, número e complemento, Informações sobre a gestação contendo: tempo gestacional em semanas (menos de 22, de 22 a 27, de 28 a 31, de 32 a 36, de 37 a 41, 42 ou mais ou ignorado), gravidez (Única, Dupla, Tripla ou ignorado), parto (vaginal, cesáreo ou ignorado) e número de consultas (Nenhuma, 1 a 3, 4 a 6, 7 ou mais e ignorado), Data e hora do nascimento, sexo do recém-nascido, peso ao nascer, raça/cor (Branca, Preta, Amarela, Parda ou Indígena), Número do lote, Código da Instituição, número de consultas, trimestre em que iniciou o pré-natal (Primeiro, Segundo, Terceiro ou ignorado), quantas consultas foram na rede pública e quantas na rede privada.

§ Possuir mecanismo de georreferenciamento utilizando servidores de mapas disponíveis na internet sem custos adicionais para mapear os pacientes utilizando como filtros o sexo, o paciente, o bairro, o logradouro, idade inicial e final e número do cartão SUS.

§ Possuir funcionalidade de registro das impressões digitais do paciente, através de leitura biométrica, permitindo ao operador identificar o dedo que está sendo registrado.

§ Permitir o registro do nome social do paciente, identificando ainda quando o paciente deseja ser tratado pelo nome social.

§ Deve possuir integração e funcionalidades para importar os dados do CARTAO SUS nacional.

§ Deve possuir integração e funcionalidades para registrar foto do paciente.

17. DO MÓDULO DE ENVIO DE SMS/E-MAIL:

Possuir mecanismo para parametrização do envio de mensagens contendo o tipo do envio (sms/e-mail), identificação do remetente, usuário e senha a serem utilizados e DDD padrão para o envio de mensagens e ainda possibilidade de configuração por unidade de saúde para envio automático de sms/e-mail.

Possuir cadastro de eventos para envio de mensagens, de modo que o sistema possa identificar através dos eventos, em que momento será realizado o envio de sms (dispensação de medicamentos, agendamento de consultas, agendamento de transportes, e outros).

Possuir mecanismo de envio de sms/e-mail em lotes através da utilização de filtros como tipo (sms/e-mail), evento para o qual se deseja enviar a mensagem, sexo, paciente, idade inicial e final, bairro, logradouro ou município, unidade de origem, unidade de destino, profissional, serviço procurado, tipo de consulta, status do agendamento, período da consulta e texto a ser enviado.

O sistema de SMS deve apresentar em seu relatório e auditoria o status dos envios da seguinte forma: sms enviado, sms entregue pela operadora, para que a equipe de saúde possa acompanhar todos os envios.

18. DO CONTROLE DE ESTOQUES:

A empresa deve possibilitar o cadastro de fornecedores contendo seu CNPJ, data do cadastro, razão social, logradouro, bairro, complemento, cidade, Cep, Uf, telefone, fax, e-mail, responsável e CNPJ. Deve ainda haver a possibilidade de indicar se o mesmo fornece medicamentos controlados, seu número de alvará, número da licença, número da licença especial e o tipo do fornecedor.

Deve possuir cadastro de Motivos de Acertos de Estoque.

Possuir cadastro de fabricantes.

Possuir cadastro de centros de custo.

Possuir cadastro de listas de entorpecentes, assim como de suas versões.

Possuir cadastro de grupos de materiais com seus respectivos subgrupos.

Deve possuir cadastro de materiais e medicamentos com campo para determinar se o item cadastrado é um material ou medicamento.

O sistema deve permitir que possam ser definidos os materiais e medicamentos onde se deseja realizar o controle por lote e validade.

Deve permitir que sejam cadastradas as diversas formas nas quais o medicamento pode estar disponível para consumo.

Deve possuir cadastro de DCB’s (Denominação Comum Brasileira).

Deve possuir mecanismo para informar os estoques mínimos para material, apresentação em cada ponto de distribuição de materiais/medicamentos em funcionamento na contratante.

Deve possuir cadastro de competências específicas para o gerenciamento de estoque.

Possuir parâmetro para informação do número máximo de dias com que se pode realizar movimentações no estoque.

Deve possuir mecanismo para controle patrimonial contendo os seguintes campos: número do patrimônio, data da garantia, número da nota fiscal, material, fornecedores, unidade de saúde, centro de custo, localização, indicação se o mesmo foi baixado, data da baixa e observações.

Deve possuir funcionalidade para gerenciamento de fornecimento de medicamentos de rotina, contendo o paciente, o medicamento, observação, forma de apresentação e quantidade a ser dispensada.

Possuir rotina para pesquisa da posição de estoque utilizando filtros como competência inicial e final, material/forma de apresentação e ponto de distribuição.

Deve possuir mecanismo para gerenciamento entrega parcial de medicamentos por licitação contento, pelo menos, os seguintes campos: Código, Data da Licitação, Observações, Material/Medicamento, Forma de Apresentação, Quantidade, Valor Unitário e Fornecedor.

Deve possuir entrada de Materiais e Medicamentos com base na nota de compra, contendo as seguintes informações: Data da Entrada, Ponto de Distribuição aonde está sendo realizada a entrada, Fornecedor, Licitação, Data da Compra, Número da Nota Fiscal, Série, Frete, Acréscimo, Desconto, Material, Forma de Apresentação, Centro de Custo, Fabricante

Deve possuir mecanismo para aceitar entrada de materiais e medicamentos recebidos através de doações

O sistema deve realizar checagem para que não sejam lançados valores e quantidades incorretas com base nas informações da nota fiscal de entrada.

Deve possuir funcionalidade para emissão do extrato da compra.

Deve possuir mecanismo para fechamento da compra e cálculo do custo médio de cada um dos itens que fazem parte da nota de compra.

Deve possuir mecanismo de requisição de materiais para que os pontos de distribuição possam solicitar os materiais e medicamentos que julgarem necessários.

A aplicação deve possuir funcionalidade para geração da transferência dos materiais e medicamentos solicitados pelos pontos de distribuição, com base na requisição de abastecimento, com o mínimo de retrabalho possível.

Deve possuir relatórios para abastecimento dos pontos de distribuição, mostrando seu consumo, seu estoque e estimativa do número de dias que o estoque atual conseguirá suprir com base no consumo.

O sistema deve possuir mecanismo de conferência das transferências realizadas, não permitindo que possam ser desviados materiais e medicamentos enviados para os pontos de distribuição.

O sistema deve conter mecanismo para que possam ser realizados acertos de estoque em cada ponto de distribuição contendo, no mínimo, os seguintes campos: Data do Acerto, Motivo, Material, Forma de Apresentação, unidade, Data da Validade, quando necessário e a quantidade real.

Deve possuir mecanismo para registro das dispensações de materiais e medicamentos para os pacientes onde possam ser registradas as seguintes informações: Ponto de Distribuição onde a saída foi realizada, data, competência, número da receita, Paciente, Centro de Custo, Profissional e Programa. Nos itens de cada saída deve ser possível que sejam registradas as seguintes informações: Material, Forma de Apresentação, Lote e Validade, Quantidade, Quantidade Prescrita, Duração.

Durante a saída o sistema deverá controlar e obrigar a alimentação dos campos necessários caso o medicamento seja controlado como a data da receita, número da receita, número da notificação, tudo isso de acordo a lista de entorpecentes a qual o medicamento controlado pertence.

Na tela de saída para pacientes, o sistema deve alertar quando o paciente estiver retirando um medicamento antes da data prevista para sua retirada.

Na tela de saída o sistema deve possuir mecanismo para que sejam consultadas as últimas dispensações de medicamentos realizadas para o paciente que está sendo atendido.

Na tela de saída de materiais e medicamentos, a aplicação deve permitir que o paciente seja pesquisado através de qualquer parte do seu nome, nome da sua mãe e data de nascimento pelo menos.

Deve possuir mecanismo para registro dos medicamentos e materiais procurados pelos pacientes e não disponíveis nos pontos de distribuição de materiais e medicamentos contendo os seguintes campos: Ponto de Distribuição, Data da Demanda, Data do Lançamento, Paciente, Centro de Custo, Material, Forma de Apresentação, Quantidade em Estoque, Quantidade a ser dispensada e Quantidade Reprimida.

Deve possuir parametrização para indicar quais os pontos de estoque podem realizar entradas através de notas de compra.

Possuir parametrização para informação do número máximo de dias em atraso que se pode realizar uma transferência e parâmetro para indicar o número máximo de dias em atraso que se pode realizar uma saída.

Deve possuir parâmetro para indicar se é possível que o ponto de distribuição possa inserir uma saída sem informar o paciente que retirou o medicamento.

Deve possuir parâmetro para indicar se é possível realizar saídas informando apenas o centro de custo.

Possuir parâmetro para indicar se é ou não obrigatória a informação do profissional que receitou o medicamento, durante a dispensação do mesmo.

Deve possuir parâmetro para indicar se o tempo de utilização do material deve ser obrigatoriamente informado no momento da saída do material/medicamento.

Possuir parâmetro para indicar se o operador poderá ou não lançar a demanda reprimida no momento da dispensação do material/medicamento.

Possuir parâmetro para indicar se o sistema deverá ou não aceitar acertos de estoque com datas retroativas.

Possuir parâmetro para indicar se o sistema permitirá ou não a transferência de medicamentos vencidos.

Possuir parâmetro para indicar se o ponto de distribuição trabalha com utilização de etiquetas de códigos de barra bem como o modelo de etiqueta a ser utilizado.

Possuir parâmetro para indicar se um aviso será dado ao operador assim que o material/medicamento atingir sua quantidade mínima.

O sistema deverá possuir rotina para acompanhamento de medicamentos vencidos.

Possuir rotina para acompanhamento dos medicamentos com estoque abaixo da quantidade mínima.

Possibilitar o controle dos antimicrobianos em conformidade com os padrões da ANVISA.

Deve possuir devolução para fornecedor, obtendo os dados da compra, tipo de movimentação do (BNDASAF) e itens para devolução.

Possuir mecanismo para devolução de saídas.

A aplicação deve possuir mecanismo ou funcionalidade para que novos medicamentos cadastrados possam ser relacionados a um determinado material.

A empresa obrigatoriamente deve ter a funcionalidade de integração com o BNDASAF - Base Nacional de Dados de Ações e Serviços da Assistência Farmacêutica

19. DA REGULAÇÃO/AGENDAMENTO DE CONSULTAS:

Possuir cadastro dos tipos de atendimento disponíveis na rede de saúde.

Possuir parâmetros para indicar para cada forma de atendimento se serão impressas fichas de atendimento ambulatorial no momento do atendimento.

Possuir parâmetro para indicar se a ficha de atendimento ambulatorial será impressa em tela ou enviada diretamente para a impressora para cada forma de atendimento.

Possuir parâmetro para indicar se serão impressas múltiplas fichas de atendimento ambulatorial para cada forma de atendimento.

Possuir parâmetro para indicar se serão gerados números de protocolos de atendimento para cada forma de atendimento, bem como se o protocolo será enviado diretamente para a impressora, se deve imprimir múltiplos números de protocolo, data da atualização do protocolo e ainda data de faturamento do protocolo para cada forma de atendimento.

Deve possuir parâmetro para indicar se existe integração com a autorização de exames, caso o tipo de atendimento seja para exames e não consultas, para cada forma de atendimento.

Deve possuir parâmetros para indicar se é possível inserir procedimentos extras, ou ser o operador poderá realizar o agendamento do exame para cada forma de atendimento.

A aplicação deve possuir parâmetros para indicar se a presença do paciente será realizada automaticamente após o agendamento, se será lançada a evolução da enfermagem, se utilizará prescrição médica, se será apresentada a tela de anamnese, se obriga o lançamento da causa alegada, se permite que não sejam informados procedimentos, se codifica causas externas, se obriga a informação do motivo do atendimento e se obriga a informação do médico solicitante para cada forma de atendimento.

Deve possuir cadastro de motivos de cancelamento de agendamentos.

Deve possuir mecanismo para informação dos procedimentos possíveis para cada CBO de profissional, se permite urgência para o procedimento em questão bem como a idade inicial, idade final e sexo que serão aceitos para o procedimento.

Deve permitir que sejam elaboradas agendas de atendimento para cada forma de atendimento, profissional e unidade de saúde, informando a data em que o mesmo entrará em funcionamento, data limite para sua utilização, número máximo de dias com que se poderá agendar para este cronograma com antecedência.

Deve permitir que sejam informados os dias da semana em que cada cronograma poderá ser utilizado, turno, número de consultas normais, número de consultas de urgências, número de consultas de retorno, tempo de consulta e faixas de horário em que o mesmo estará disponível.

Nos cronogramas, deve possuir mecanismo para indicar se poderão ser marcados todos os pacientes para o mesmo horário, se permite marcação de consultas de urgência com mais de 24 horas de antecedência e, ainda, se o mesmo está ativo.

A aplicação deve possuir mecanismo para gerenciamento de exceções que permita suspender, aumentar ou diminuir, mudar as faixas de horário de atendimento, ou ainda suspender os atendimentos de uma determinada unidade de saúde, profissional, forma de atendimento, período, datas esporádicas, horários ou unidade de origem do agendamento em um determinado turno, dia da semana ou período.

Deve possuir cadastros de causas de atendimento.

Deve possuir cadastro de classificação dos motivos de atendimento.

Deve possuir mecanismo para criação de fichas de anamnese permitindo especificar em quais CBO’s a mesma será utilizada. O mecanismo de criação de fichas deve permitir que sejam criados subtítulos dentro de cada anamnese aos quais ficaram atreladas todas as perguntas constantes na anamnese cujas respostas poderão ser dos tipos alfanumérico, data, numérico ou de múltipla escolha, neste caso determinando quais são as opções disponíveis para seleção. Deve ainda possuir campo que permita sua desativação, se sua resposta é obrigatória, a ordem da pergunta na anamnese e um campo para inserção de informações de ajuda, para o momento do preenchimento da mesma.

Deve possuir funcionalidade para permitir que sejam inseridas possibilidades de procedimentos para cada agenda de atendimento em funcionamento nas Unidades de Saúde.

Deve possuir mecanismo para criação de turmas para atendimento em grupo onde possam ser identificados o nome da turma, Unidade de Saúde, quantidade mínima e máxima de participantes de turma, programa de saúde e Informações gerais sobre a turma.

A aplicação deve permitir que sejam criados agendamentos para atendimentos em grupo informando a data, horário bem como seus participantes.

O sistema ofertado deve possuir mecanismos para que possam ser lançados procedimentos para todos os participantes de um atendimento em grupo informando o profissional, procedimento, CBO, características do atendimento, idade, CID e quantidade.

Ainda no agendamento em grupo, deve permitir que procedimentos extras possam ser lançados para cada participante do grupo.

O sistema deve possuir mecanismo para distribuição e controle de quotas sobre os números de vagas disponíveis em todas as formas de atendimento disponíveis na rede de saúde em percentual e quantidade, que poderão ser distribuídas para todos os locais onde as agendas estarão disponíveis para marcação.

A aplicação deverá filtrar as agendas de atendimento disponíveis de acordo com a forma de atendimento desejada pelo paciente, Unidade de Saúde onde o serviço está disponível, profissional, dia da semana, data e turno durante o processo da marcação de consulta.

A aplicação deve possuir um atalho através de calendário onde as datas de atendimento possam ser identificadas visualmente através de padrões de cores indicando se existem vagas para o dia, se a mesma já se encerrou ou ainda se não atendimento previsto para o dia.

Para cada agenda de atendimento selecionada, a aplicação deve mostrar informações com relação a sua cota de vagas normais, urgência e retorno.

O sistema deve ter uma clara distinção entre os pacientes agendados, em espera e atendidos para cada agenda disponível.

A solução ofertada deve possuir parâmetros para definir a ordenação da fila de atendimento com, pelo menos as seguintes opções: horário do agendamento, horário estimado para o atendimento, horário da confirmação de presença.

Independente da parametrização escolhida no item anterior, a solução deve exibir em tela as prioridades determinadas pela lei 10.048/2000.

A tela de agendamento de consultas deve possuir atalhos para reimpressões de fichas de atendimento ambulatorial, requisição de exames, impressão de protocolo, cadastro de pacientes e impressão de agendas

Durante o processo de agendamento o sistema deve alertar ao operador sobre consultas já marcadas para o mesmo paciente na mesma forma de atendimento, se o mesmo possui vacinas em atraso, se existe alguma informação a ser passada para o paciente.

Durante o processo de agendamento, a aplicação deve permitir que sejam marcadas consultas normais, de urgência ou retorno, obedecendo parametrização prévia e ainda, permitir que seja informado quando o paciente está em processo de gestação, quando for o caso, a causa alegada, a classificação do motivo do atendimento e ainda se o paciente não apresentou documentos no momento da marcação da consulta.

O sistema deve permitir que sejam realizadas pesquisa nas agendas através do nome do paciente.

A tela de agendamento deve atualizar-se automaticamente, sem a intervenção do operador, porém deve possuir mecanismo para que o operador possa interromper os processos de atualização automática se assim desejar.

A aplicação deve possuir mecanismo de filtro nas agendas para que possam ser visualizados apenas os pacientes que se encontram em observação.

O sistema ofertado deve possuir mecanismo para criação de centrais de agendamento, que poderão realizar agendamentos outros locais onde os serviços são disponibilizados.

O sistema deve possuir mecanismo para efetuar o cancelamento de paciente na espera.

Possuir parametrização para indicar o numero máximo de dias que pode realizar agendamento futuros.

O sistema deve possuir integração com as unidades permitindo que o profissional efetue a solicitação via sistema e consiga anexar todo e qualquer documento do paciente.

O sistema deve possuir aviso de prioridade de espera.

O sistema deve possuir mecanismo integrado para efetuar a realização da APAC e anexar aos documentos sem a necessidade de impressão em papel.

20. DA REGULAÇÃO/ AGENDAMENTO DE EXAMES:

O sistema deve possuir cadastro de convênios.

O sistema deve possuir cadastro de grupos de exames.

A aplicação deve possuir cadastro de exames contento seu código, descrição, pseudônimo, tempo de atendimento, quantidade de agendamentos por hora, indicação se está ativo, se é usado no módulo de gerenciamento de laboratório, se é utilizado no centro de testagem e aconselhamento.

Cada exame poderá ser atrelado a, pelo menos, cinco (05) grupos orçamentários.

A aplicação deverá permitir que sejam criados exames compostos mais de um procedimento SUS através da informação do procedimento e quantidade que compõe o valor do exame a ser criado.

Deve possuir mecanismo para definição de tetos orçamentários anuais por munícipio

Deve possuir mecanismo para definição de tetos orçamentários por município, prestador, unidade de saúde e profissional.

Durante o agendamento dos exames, a aplicação deve permitir que sejam informados o nome do paciente, a data da autorização, unidade de saúde solicitante, unidade autorizadora, profissional solicitante, indicação se a paciente está em gestação, tipo do agendamento (normal, urgência ou retorno), número da requisição, exame, data da realização, prestador, turno, horário, quantidade e observação.

Na tela de agendamento deve existir um atalho onde seja possível consultar as últimas autorizações realizadas para o paciente.

A solução ofertada deve possuir mecanismo para criação de cronogramas de atendimento para cada exame, determinando os dias e horários em que o mesmo poderá ser marcado para cada prestador.

Deve permitir que possam ser criadas exceções de atendimento para cada cronograma de atendimento disponível para agendamento de exames.

Durante o processo de agendamento a aplicação ofertada deverá obedecer rigorosamente aos tetos orçamentários definidos, não permitindo os mesmos sejam ultrapassados.

A aplicação deve possuir mecanismo de controle que obrigue os prestadores registrarem os exames realizados com opção para anexar o laudo eletrônico do exame realizado, permitindo o controle do pagamento de cada prestador com base nos exames realizados.

A aplicação deve permitir que sejam autorizados exames sem que seja indicado o prestador que irá realiza-los, de modo a garantir a livre escolha do paciente.

21. DO CONTROLE DE TRANSPORTES:

A aplicação deve possuir cadastro de tipos de veículos

Deve possuir cadastro de veículos contendo sua descrição, seu tipo, sua placa, sua marca, número do seu chassi, ano do veículo, sua capacidade/lotação, tipo do combustível e data da validade do extintor de incêndios

Deve permitir a criação de rotas contendo sua descrição, se a mesma está ativa e o município de saída.

Deve possuir cadastro para lançamento de dotações orçamentárias contendo seu código, descrição e número

Deve possuir cadastro de recursos contente seu código, descrição e número

A aplicação deve possuir cadastro de motoristas contento nome, endereço, CPF, telefone, CEP, município, complemento, tipo de veículo que está habilitado a conduzir, número da sua carteira de habilitação, categoria da carteira, data do vencimento da carteira e indicação se o mesmo encontra ativo.

A aplicação deve possuir cadastro de itens de consumo com sua descrição, unidade de apresentação e fornecedor padrão.

Deve possuir cadastro de eventos do veículo.

Deve possuir cadastro de tipos de viagem com indicação se o tipo da viagem deve ser utilizado nos processos de TFD.

Deve possuir cadastro de tipos de despesa e adiantamentos contendo sua descrição e seu valor unitário.

A solução deve possuir cadastro de destinos contendo seu nome, município onde se localiza e telefone.

Deve possuir mecanismo para lançamento de eventos para cada veículo contento sua data de criação/atualização, evento, data do vencimento, número de dias que o evento pode ser postergado, indicação se o evento foi realizado, data da realização, observações da realização e observações gerais do evento.

O sistema deverá emitir alertas quando o veículo for relacionado para algum tipo de viagem durante o período de vigência de um determinado evento a ele atrelado.

Deve permitir o lançamento de viagem informando código, data da saída, data prevista para retorno, tipo da viagem, auxiliar, motorista, veículo, local de destino, cidade de destino, rota, dotação orçamentária e recurso.

Ainda no lançamento da viagem, deve permitir que sejam atrelados a cada viagem os pacientes e acompanhantes com seus devidos locais de saída, locais de destino, telefones, documentos, tipo da viagem (ida, ida e volta), vagas consumidas na ida, vagas consumidas na volta, acompanhantes, horário da saída, horário da chegada, data do aviso ao paciente, horário do aviso e observação.

No lançamento da viagem, deve permitir que sejam relacionados Km inicial, km final, nome da empresa (no caso de terceira) valores adiantados e km rodados.

Deve permitir que sejam lançados um ou mais adiantamentos para cada viagem, contendo o tipo do adiantamento, valor, quantidade e valor total.

A solução deve possuir mecanismo para lançamentos das despesas de viagem contendo informações como horário de saída, horário de chegada, km inicial, km final, km rodado, número do documento da despesa, data da despesa, tipo da despesa, valor unitário, quantidade, total, local/fornecedor, um breve histórico e campo para indicar o lançamento de viagem em questão já foi finalizado.

Deve possuir funcionalidade para lançamento de manutenções com o veículo contento a data da solicitação, data programada, data previsão, veículo, quilometragem, nome do solicitante, local da manutenção, telefone, nome do contato na manutenção, descritivo do motivo pelo qual a manutenção está sendo requerida.

Ainda no lançamento da manutenção, o sistema deve permitir que sejam lançados todos os itens da manutenção contendo o nome do item, indicação se o era problema em peça original, data da próxima troca, km da próxima troca, número do documento, quantidade, valor unitário, valor total e campo para observações.

Possuir funcionalidade para lançamento de créditos ao fornecedor contendo a data, fornecedor, item para o qual o crédito é realizado, valor e quantidade.

A aplicação deve possuir mecanismo para lançamento de acertos de manutenção com o fornecedor contendo a data da entrega, indicação se o acerto foi finalizado, item, data da próxima troca, km da próxima troca, documento, quantidade, valor unitário, valor total e observações.

Deve possuir mecanismo para lançamento de gastos gerais com veículo contento a data da autorização, fornecedor, veículo, motorista, documento de referência, km, item, quantidade, valor e indicação se o mesmo foi autorizado ou cancelado.

A aplicação ofertada deve possuir mecanismo para acompanhamentos dos saldos com cada fornecedor, levando em consideração os valores creditados a ele e os gastos realizados com cada um em quantidade e valor.

O sistema deve possuir mecanismo para gerenciamento de solicitações de ambulância contento a data da solicitação, data da saída, horário da saída, cidade de destino, local de destino, veículo, motorista, pacientes na ida e pacientes no retorno.

A solução ofertada deve possuir mecanismo para publicação das listas de espera para transporte na internet através de consultas públicas ao sistema.

A solução deve possuir mecanismo ou funcionalidade para geração automática dos procedimentos de transporte do paciente e seu acompanhante, com base na quilometragem percorrida.

O sistema deve possuir mecanismo para lançamento de multa contendo a data, motorista e infração.

22. DO TFD - TRATAMENTO FORA DO DOMICILIO

O sistema deve permitir que sejam criados os processos de TFD contendo número do processamento, data da abertura, paciente, profissional responsável, cid10, tratamento solicitado, tipo do atendimento e justificativa.

Para cada processo de TFD deve haver indicação se o mesmo foi autorizado, cancelado enviado para o estado, negado ou se está inconcluso com uma justificativa para o estado do mesmo, observações gerais.

A cada processo TFD deve ser possível realizar se o lançamento de todas as viagens necessárias contendo a data da solicitação, local de destino, cidade de destino, transporte recomendado, veículo, motorista, data, hora, observação para ida, previsão de retorno e observação para a previsão de retorno.

Deve possuir mecanismo para criação de viagens para processos de TFD com base nos processos de TFD a serem atendidos.

A solução deve possuir funcionalidade para renovação de processos de TFD já concluídos.

A solução deve possuir mecanismo que informe o controle de avaliação em tempo real o total de viagens e suas localidades.

23. DO ACOLHIMENTO

A tela de acolhimento deve permitir que sejam registrados atendimentos sob demanda, sem a necessidade de haver uma consulta ou agendamento previamente realizado.

A solução deve permitir que os pacientes a sem acolhidos sejam pesquisados ao menos por: nome, data de nascimento, sexo, nome da mãe, CPF, CNS e nome social.

Deve ser possível realizar os filtros por ao menos três destas informações simultaneamente.

Deve possuir registro do peso, estatura, quadril, cintura, temperatura, pressão arterial, frequência respiratória, pulsação, saturação de O2, circunferência braquial e percentual de gordura cutânea, além de registrar o valor de glicemia, informando se o exame foi feito em jejum ou se é pós-prandial.

Deve gerar o IMC com base nas leituras realizadas considerando sexo e faixa etária do paciente conforme manual do SISVAN.

Quando paciente atendido for uma criança a solução deve permitir que sejam registrados perímetro cefálico, torácico, situação vacinal e tipo de aleitamento.

Caso o paciente em atendimento seja mulher em idade fértil, a aplicação deve registrar se a mulher está gestando, caso sim, registrar a data da última menstruação, peso pré-gestacional, altura uterina, toque vaginal, batimentos cardíacos do feto, posição do colo e data provável do parto.

Possuir funcionalidade para registro das anotações de enfermagem e das queixas do paciente.

Todas as informações que caracterizem realização de procedimento realizados durante o acolhimento deverão automaticamente gerar produção ambulatorial (BPA).

A aplicação deve possuir mecanismo para digitação de produção, de forma que o profissional possa pesquisar todos os procedimentos compatíveis segundo regras do SIGTAP, podendo registrar a execução de quaisquer procedimentos permitidos.

A solução ofertada deve possuir mecanismo para que sejam listados ao profissional, durante o atendimento, procedimentos previamente relacionados aos seu CBO, permitindo que o mesmo indique os procedimentos realizados de maneira ágil, clicando sobre o procedimento realizado.

A aplicação deve possuir gráfico para acompanhamento do perímetro cefálico e peso corporal de crianças, para adultos gráfico de acompanhamento de peso/altura, glicemia, pressão arterial, evolução do IMC, evolução da frequência respiratória/pulsação e para evolução cintura/quadril.

Deve permitir que o profissional realize a classificação de risco do paciente utilizando as cores do protocolo de Manchester

A solução deve possuir mecanismo ou funcionalidade para coletar todos os dados necessários para alimentação dos dados do e-sus durante o atendimento dos pacientes, sem que haja necessidade de nova alimentação de informações.

O atendimento do acolhimento deve permitir que seja registrado em destaque no prontuário dados relevantes a todos os atendimentos subsequentes, de modo que estas informações sejam exibidas em destaque a partir do momento do seu registro.

A solução ofertada deve possuir mecanismo para emissão de declaração de comparecimento, contendo, no mínimo, informações de data, horário inicial, horário final e observações, além de registrar se o paciente estava acompanhado.

Deve possuir desfecho do atendimento contendo data, horário, especialidade, profissional, posto de atendimento, tipo do desfecho e observações.

24. DO PRONTUÁRIO ELETRÔNICO MULTIPROFISSIONAL

Deve haver interoperabilidade com o painel de avisos e quando o profissional acessar o prontuário através da fila de atendimento o paciente deverá ser chamado na sala de espera e encaminhado para o consultório onde o profissional irá atendê-lo.

O prontuário multiprofissional deve permitir que as informações coletadas durante o atendimento sejam armazenadas no formato SOAP (Subjetivo, Objetivo, Avaliação e Plano), ou ainda no formato “Queixa / Serviço”, conforme definição de cada área específica.

A solução apresentada deve sugerir os CID’s para o atendimento com base na avaliação realizada pelo profissional.

Deve possuir funcionalidade para registro de resultados de qualquer exame realizado pelo paciente.

Deve permitir funcionalidade para acompanhamento de todos os gráficos constantes no acolhimento.

Todas as informações que caracterizem realização de procedimento realizados durante o acolhimento deverão automaticamente gerar produção ambulatorial (BPA).

O atendimento do prontuário deve permitir que seja registrado em destaque no prontuário dados relevantes a todos os atendimentos subsequentes, de modo que estas informações sejam exibidas em destaque a partir do momento do seu registro.

Possuir funcionalidade para impressão da ficha clínica do paciente, assim como de seu prontuário.

Deve possuir mecanismo para emissão do receituário médico, com modelo que atenda legislação vigente.

Deve possuir funcionalidade para cadastramento de receitas padrões, baseadas em protocolos assistenciais, agilizando o processo de criação do receituário.

O mecanismo de controle do receituário deve permitir que várias receitas sejam emitidas durante o atendimento do paciente.

A solução deve contar com funcionalidade que permita ao profissional criar uma nova receita, com base em receitas anteriores já emitidas para o mesmo paciente.

No receituário o profissional deve poder verificar quais medicamentos possui na rede de saúde, através de seu cadastro, porém deve haver a possibilidade do lançamento de medicamentos que não sejam encontrados na rede municipal de saúde.

Ainda na funcionalidade de emissão de receitas, caso o profissional prescreva medicamentos controlados e não controlados no mesmo receituário, o sistema deve emitir separadamente os impressos, sendo que cada medicamento deve sair em formulário específico.

A solução ofertada deve possuir funcionalidade que permita ao profissional indicar quando o paciente deve ficar em observação.

No prontuário médico multiprofissional deve haver a possibilidade de criação de prescrição médica para pacientes em observação, permitindo que sejam listados o medicamento, sua administração, posologia e horário da administração com campo para checagem de realização do mesmo.

Deve possuir funcionalidade para emissão de atestado contendo número de dias, data do atestado, observações e campo para indicação se o CID deverá ou não ser impresso no atestado.

Também no atestado, o sistema deve permitir que seja registrado acompanhante, caso haja, emitindo o nome deste acompanhante no atestado.

Deve possuir funcionalidade para emissão de declaração de comparecimento contendo data, horário inicial, horário final e campo para descrição da finalidade

Deve possuir funcionalidade para emissão de encaminhamentos com registro da especialidade, indicação de urgência, indicação para impressão ou não do CID e campo para descrição do motivo.

A solução deve possuir funcionalidade para emissão de solicitações de exames com registro do profissional solicitante, data, observações, dados clínicos, materiais a examinar e exames a serem realizados.

O mecanismo de solicitação de exames deve permitir que sejam criadas solicitações padrões de exames agilizando o processo de emissão da solicitação.

A aplicação deve conter funcionalidade que permita ao profissional a criação de novas solicitações de exames com base em solicitações de exames previamente realizadas para o mesmo paciente em atendimentos anteriores.

Deve possuir mecanismo para registro do final do atendimento, quando serão feitas as cobranças de produção ambulatorial, assim como se encerrará a edição dos dados do prontuário.

Na tela principal do prontuário, devem ser exibidas informações referentes as imunizações recebidas pelo paciente.

Havendo acolhimento registrado de forma vinculada ao atendimento, devem ser exibidas todas as informações em tela, de forma a tornar fácil a visualização dos dados. Caso não haja este acolhimento vinculado, deve-se exibir com mesmo destaque o último acolhimento realizado pelo paciente.

A solução deve estar adequada as regras do e-sus, coletando todas as informações necessárias para alimentação das fichas do e-sus durante os atendimentos dos pacientes.

A solução deve conter mecanismo ou funcionalidade que permita aos profissionais anexarem qualquer tipo de arquivo ao prontuário do paciente.

A aplicação ofertada deve estar totalmente integrada com o sistema laboratorial, permitindo aos profissionais acessarem os laudos dos exames já realizados no laboratório.

Deve possuir desfecho do atendimento contendo data, horário, especialidade, profissional, posto de atendimento, tipo do desfecho e observações

25. DO PRONTUÁRIO ODONTOLÓGICO

Permitir que o planejamento do atendimento seja realizado através da apresentação da arcada dentária em modo gráfico com cara distinção entre dentes permanentes e dentes decíduos.

Na arcada dentária deve usar distinção por cores entre procedimentos realizados e procedimentos a serem realizados em cada face de cada um dos dentes.

Deve permitir que o profissional clique sobre a face de cada dente e registre seu estado inicial bem como os procedimentos a serem realizados.

Deve possuir mecanismo para lançamento de procedimentos para todos os dentes.

Deve disponibilizar ao odontólogo todas as funcionalidades do prontuário do paciente e relatórios de atendimento integrado.

A aplicação deve permitir que sejam selecionados um ou mais dentes para o lançamento de um ou mais procedimentos.

A solução ofertada deve possuir mecanismo ou funcionalidade que permita a seleção de uma ou mais faces, pertencentes a um ou mais dentes, para informação de um ou mais procedimentos.

O sistema oferecido deve possuir campo para indicar para cada atendimento se o mesmo foi para: 1ª Consulta Odontológica Programática; Escovação Dental Supervisionada; Tratamento Concluído; Urgência; Atendimento a Gestantes; Instalações de Próteses Dentárias

A solução deve possuir funcionalidade para consulta do histórico de todos os atendimentos em um único odontograma ou ainda, cada tratamento realizado em um odontograma.

A solução deve possuir o relatório e envio para o RPOM estadual.

26. DA LISTA DE ESPERA

Deve possuir cadastro para os níveis de urgência a serem utilizados nas filas de espera.

Deve possuir cadastro de Tipos de Lista de Espera

Deve possuir mecanismo ou funcionalidade que permitam que as listas sejam alimentadas nos locais de atendimento à população.

Deve permitir que sejam elaboradas listas de espera para cada tipo de serviço disponível na rede de saúde.

Deve possuir mecanismo para marcação das consultas da lista de espera em lote, permitindo que o operador selecione uma ou mais pessoas da lista e determine em que agenda de atendimento as mesmas devem ser inseridas.

Deve alertar ao operador possíveis problemas na marcação de consultas em lote como em casos de falta de horários disponíveis.

A solução deve possuir mecanismo que permita a publicação das listas de espera para consultas públicas (sem necessidade de login) ao sistema.

Deve possuir mecanismo que permita parametrizar quais listas deverão estar abertas para consultas públicas

Deve possuir mecanismo de parametrização que permita configurar que campos devem ser listados nas consultas públicas contento, no mínimo, os seguintes campos: número do protocolo de atendimento; código do paciente; nome do paciente; nome social do paciente; nome da mãe; iniciais do nome do paciente; iniciais do nome social do paciente; iniciais do nome da mãe; data de nascimento; número do cartão nacional de saúde; número do cpf.

A rotina de trabalho da lista de espera deve permitir configuração, para que alguns tipos de lista exijam regulação, enquanto outros tipos permitam apenas o fluxo simples.

Quando a lista de espera usar regulação, deve permitir que seja parametrizado se a regulação é opcional ou obrigatória.

Quando se trabalhar em listas de espera de regulação obrigatória, o sistema deve permitir ao médico regulador reclassificar a prioridade do atendimento na lista de espera, além de autorizar ou negar o atendimento, mediante justificativa.

27. DAS AÇÕES PROGRAMÁTICAS EM SAÚDE

Deve possuir mecanismo para cadastramento de ações para cada programa existente na rede municipal de saúde.

Deve possuir funcionalidade para cadastramento dos pacientes, com seus programas, suas receitas de materiais e medicamentos com suas respectivas datas de validade.

Deve possuir mecanismo para gerenciamento de receitas, permitindo sua renovação por um período determinado.

Deve possuir mecanismo para geração de roteiros de entrega de medicamentos para os pacientes inseridos em ações programáticas por programa de saúde, bairro, rua, paciente e período de validade.

Deve possuir funcionalidade para geração dos kit’s a serem entregues para cada paciente contendo seus materiais e medicamentos.

Deve permitir que mais de um roteiro seja criado com os mesmos filtros, inserindo nele apenas as receitas ainda não atendidas por roteiros anteriores.

A aplicação deve possuir funcionalidade para emissão dos recibos de entrega para cada paciente contendo no mesmo informações sobre os medicamentos e materiais contidos no kit.

A solução deve possuir funcionalidade para baixa automática do estoque dos materiais e medicamentos contidos nos kit’s entregues

Deve possuir mecanismo para acompanhamento visual em formato de gráfico da evolução das dispensações por ano mês dentro de cada ano.

Deve possuir mecanismo para acompanhamento visual em formato gráfico, mostrando a os valores consumidos com materiais e medicamentos dispensados.

Deve possuir mecanismo para acompanhar através de mapas os locais onde são entregues os medicamentos.

Deve permitir que os pacientes em cada programa possam ser desativados e, desta forma, suas receitas desconsideradas de novas elaborações de roteiro e montagem de kits.

Deve possuir campos para identificar a data de cadastro dos pacientes em cada programa, a data de atualização dos seus dados em cada programa bem como a data da baixa de cada paciente em cada programa.

O sistema deve possuir locais para informação do número da renovação da receita em cada programa, competência da receita e competência da validade.

A montagem do kit deve ser feita através de um processo de linha de montagem, visando otimizar o fluxo de trabalho, de forma a atender ao menos as seguintes etapas: geração dos kits, confecção dos kits, conferência dos materiais, registro da dispensação do kit para o entregador, e registro da entrega do kit ao destinatário.

O sistema deve permitir que todas as etapas da montagem do kit sejam registradas com utilização de login e senha.

A solução ofertada deve permitir que todas as etapas da montagem os kit sejam registradas com uso e biometria para validação do usuário responsável pela mesma.

28. DO MODULO MEDICAMENTO JUDICIAL

A aplicação ofertada deve possuir mecanismo para controle de processos judiciais contendo número do processo, data de abertura, paciente, unidade de saúde da sua cobertura e observações.

Deve permitir que seja informada a patologia, se o despacho é para a União, Estado ou Município, número da regional para cada processo.

Deve permitir que os processos sejam classificados segundo sua situação em: Aberto, Único, Fora de Linha, Cumprido, Devolvido, Suspenso e em Andamento.

Deve permitir que seja informado para cada processo se o mesmo gera algum tipo de bloqueio, se gera algum tipo de multa, o valor da multa e a data do pedido.

A solução deve possuir ainda campos para informação da data de recebimento, advogado responsável, número na OAB e telefone do mesmo.

Deve possuir campo para indicar se o processo encontra-se ativo ou inativo, bem como o motivo do mesmo está inativo e a data de fechamento do mesmo.

Deve permitir que sejam atrelados a cada processo todos os materiais e medicamentos contidos no mesmo.

Deve possuir campos para que sejam informados para cada material ou medicamento sua quantidade, valor unitário, desconto, se o mesmo é para uso continuo, se pode ser um medicamento ou material genérico, por quem será fornecido e a situação.

Deve possuir mecanismo para gerenciamento das entregas de medicamentos judiciais contendo o material, data da última entrega, data da próxima entrega, quantidade do processo, saldo e quantidade atual em estoque, para cada item de material ou medicamento contido no processo.

Deve possuir mecanismo para impressão de comprovantes de entrega dos itens contendo os materiais e medicamentos dispensados.

29. DOS BENEFÍCIOS

Deve possuir cadastro de benefícios contendo sua descrição, valor e procedimento.

Deve possuir cadastro de locais para encaminhamentos.

Deve permitir configuração para cada benefício quando a obrigatoriedade do controle do seu saldo.

Deve possuir controle de tetos orçamentários por benefício em quantidade ou valor.

Deve possuir funcionalidade para identificação dos processos de concessão de benefícios segundo seu estado: Em Andamento, Autorizado e Negado.

Deve possuir mecanismo para emissão do Laudo Social contendo o gestor, número do laudo social, número da lei, identidade e CPF.

Deve possuir campo para informações do histórico da solicitação do benefício

Deve possuir campos para emissão de observações no recibo de entrega de cada benefício

A aplicação deve permitir que vários benefícios sejam atrelados a um mesmo processo de concessão de benefícios informando o benefício, a quantidade, o profissional, o local de retirada e observações.

Deve possuir link para acesso rápido a todo histórico de concessão de benefícios para o paciente que está sendo atendido.

Deve possuir mecanismo para gerenciamento e emissão de encaminhamentos para cada paciente contendo o paciente, o profissional, descrição do encaminhamento, trabalho do paciente, renda do paciente, observações, data, hora, dia da semana e valor do encaminhamento.

Deve possuir mecanismo para emissão de recibos de entrega de benefícios

30. DAS APACS

Deve possuir mecanismos para gerenciamento de autorizações para procedimento de alta complexidade.

Possuir local para informação das sequencias de números de APACS disponíveis para utilização contento ano, uf e tipo da APAC.

A aplicação deve possuir mecanismo para gerenciamento de solicitações de APAC contendo: Unidade de Saúde solicitante, profissional solicitante, data da solicitação, número do laudo, clínica para realização, identificação do paciente, CID Provisório/Principal, CID secundário e CID para Causas Associadas.

Cada autorização deve possuir campo para identificação de cada APAC segundo o tipo do seu laudo em: Laudo Geral, Medicamentos, Nefrologia, Quimioterapia, Radioterapia e Cirurgia Bariátrica.

Deve possuir campo para identificação da APAC através do seu tipo: Inicial, Continuidade e Sem Continuidade.

Deve possuir campos para identificação do número da APAC e do número da APAC Anterior.

Deve ainda possuir para cada APAC campos para informação do início da validade e final da validade, unidade de saúde solicitante e executante.

Deve possuir local para informação dos dados do paciente contendo o paciente, nome da mãe, número do CNS, data de nascimento, idade, sexo, raça/cor, responsável e número do prontuário para cada APAC.

Deve ter o mecanismo de ser emitida no prontuário ato da consulta com todos os dados já preenchidos e automáticos.

31. DO FATURAMENTO DA PRODUÇÃO AMBULATORIAL

Deve possuir mecanismo para importação das tabelas de procedimentos do CMD através do BPAMAG ou SIGTAP

A aplicação deve possuir funcionalidade para definição de competências para Produção Ambulatorial contendo a competência, data de início e data final da mesma.

Deve possuir mecanismo ou funcionalidade que permita bloquear competências impedindo que qualquer tipo de movimentação seja realizado na mesma.

A aplicação ofertada deve possuir mecanismo de configuração que impeça a geração do BPA com informações incorretas, que possam gerar glosa no pagamento dos procedimentos realizados pela contratante.

Deve permitir que sejam gerados arquivos de envio de cobrança do BPA, contendo procedimentos de competências passadas que ainda não foram enviados.

A aplicação deve gerar o arquivo de cobrança do BPA nos padrões determinados para importação pelos sistemas do ministério da saúde.

A contratada deve OBRIGATORIAMENTE implantar em sua solução mecanismos automáticos integrados ao sistema para demonstrar para onde foi sua produção (E-SUS/SISAB/FEDERAL/ESTADUAL).

A contratada deve OBRIGATORIAMENTE oferecer um setor de faturamento exclusivo para que os usuários deste setor possam ser atendidos.

32. DAS IMUNIZAÇÕES/VACINAS

Deve possuir funcionalidade para cadastro das doses de vacinas a serem fornecidas.

Deve possuir mecanismo ou funcionalidade para cadastramento dos calendários a serem utilizados no sistema de imunizações

Deve possuir cadastro de imunizações indicando a vacina, a dose, descrição, faixas etárias e sexo para cada imunização.

Deve possuir mecanismo ou funcionalidade para cadastro das faixas etárias a serem utilizadas na criação das imunizações

Deve possuir mecanismo para cadastro dos tipos de baixa a serem utilizados pela imunização

Deve possuir mecanismo para cadastro de grupos para imunização

Deve possuir funcionalidade para gerenciamento das salas de vacinação disponíveis da rede municipal de saúde contendo seu nome e a unidade de saúde onde está localizada.

Deve possuir cadastro detalhado de tempos para utilização nos calendários de vacinação contento a descrição, o calendário de vacinação onde será utilizado, idade inicial e final e anos, mês inicial e final, dia inicial e final

Deve controlar o estoque de imunizações por lote e validade.

Deve possuir cadastro de vacinas contendo seu nome, sua abreviatura e a ordem que o a mesma será impressa na carteira de vacinação do paciente

Deve possuir mecanismo de avisos a serem ativados sempre que um paciente, que já possua carteira de vacinação com alguma vacina em atraso, seja relacionado em qualquer operação dos demais módulos do sistema, alertando ao operador sobre para que o paciente seja encaminhado para a sala de vacinação.

Deve possuir mecanismo para gerenciamento e emissão das carteiras de vacinação utilizando cores para diferenciação entre vacinas em dia, atrasadas e futuras, contendo o número de dias restantes para aplicação e data das imunizações já realizadas

A carteira de vacinação deve permitir que sejam lançadas outras vacinas esporádicas que não fazem parte do calendário de vacinação normal dos pacientes

A aplicação deve possuir mecanismo que permita o lançamento de vacinas através de planilhas de digitação contendo o paciente, a carteira de vacinação, se a paciente estava em gestação, profissional que realizou a imunização, imunização, dose, lote/validade da imunização e quantidade.

Deve possuir mecanismo para registrar entradas de imunizações, alimentando automaticamente o estoque

Deve possuir mecanismo para gerenciar o processo de acertos de estoque em imunizações

Deve possuir rotina ou funcionalidade para registro de transferências de imunizações entre as salas de vacinação

Deve possuir rotina para gerenciamento de saídas de imunizações contendo a sala de vacinação a competência e da data de saída.

Deve possuir relatório de balanço físico de imunizações por sala de imunização

Deve possuir relatório para emissão do Boletim de Imunizações

Deve possuir relatório de imunizações por bairro

Deve possuir relatórios que permitam a visualização do estoque de imunizações em outras competências.

Deve possuir relatórios para acompanhamentos das imunizações por lote e validade.

Deve possuir mecanismo ou funcionalidade que permita o acompanhamento da movimentação do estoque de imunizações por sala de imunização, imunização e motivo de baixa

Deve estar integrado com o sistema SPNI do Ministério da Saúde.

33. DO PAINEL MULTIMÍDIA

A aplicação deve possuir mecanismo de Painel para utilização nas salas de espera dos pontos de atendimento da contratante.

O painel multimídia deverá chamar o paciente através do seu nome indicando para qual consultório ou sala que deverá se deslocar para ser atendido.

O painel deve permitir que sejam inseridas informações ou vídeos a serem exibidos nas salas de espera entre um atendimento e outro.

A alimentação das informações da fila de atendimento deverá ser realizada automaticamente pelo sistema, com base no processo da recepção do paciente e da definição de grau de risco realizado na triagem, sem que seja necessária a intervenção de qualquer operador.

Deve possuir no momento da implantação informações visuais relacionados com o formato de atendimento e triagem (baseado no protocolo de Manchester) com objetivo de orientar aos pacientes na maneira como as filas de atendimento serão estabelecidas, para serem exibidos nas salas de espera onde o painel será utilizado.

Deve possuir mecanismo de alerta em módulo VERMELHO e aviso aos pacientes das recepções quando a equipe médica estiver envolvida no atendimento de emergência de equipes de SAMU e outros.

34. BUSINESS INTELIGENTE – CONTROLE DE AVALIAÇÃO EM TEMPO REAL

Todos os itens deste módulo CONTROLE DE AVALIAÇÃO deve ser em tempo real para que a gestão possa acompanhar todas as informações diárias.

Deve possuir avaliação individual por unidade, por profissional, por atividade e por atendimento.

Deve possuir os indicadores da portaria 2.979 de 12 de novembro de 2019.

Deve possuir GEO PROCESSAMENTO online integração com a mobilidade para aplicativo moveis dos agentes de saúde e permitir a localização.

Deve possuir controle da ATENÇÂO FARMACEUTICA apresentando em tempo real a relação de pacientes que retiraram medicamento.

Deve possuir controle da ATENÇÂO FARMACEUTICA apresentando em tempo real a relação de medicamento retirados.

Deve possuir controle da ATENÇÂO FARMACEUTICA apresentando em tempo real os pacientes cadastrados nos programas.

Deve possuir controle da ATENÇÂO BASICA apresentando em tempo real os pacientes agendados para o atendimento diário e qual unidade pertence

Deve possuir controle da ATENÇÂO BASICA apresentando em tempo real os pacientes atendidos e qual unidade pertence.

Deve possuir controle da ATENÇÂO BASICA apresentando em tempo real os pacientes em aguardando atendimento e qual unidade pertence.

Deve possuir controle da MEDIA ALTA COMPLEXIDADE apresentando em tempo real os pacientes agendados, atendidos, em espera e qual unidade pertence.

Deve possuir controle do ESUS apresentando em tempo real todas atividades dos agentes de saúde, por micro área, por função, por família e indicadores relativos aos atendimentos realizados no dia, no mês e no ano.

Deve possuir controle do LABORATORIO em tempo real dos pacientes atendidos, aguardando atendimento e total de requisições realizadas no dia, na semana, no mês e no ano.

Deve possuir controle da REGULAÇÃO em tempo real sobre os exames, consultas, dos pacientes no dia, na semana, no mês e no ano.

Deve possuir controle de Tempo de Atendimento por Turno médico descrevendo cada profissional.

Deve possuir controle de Tempo de Espera por paciente nas unidades de Saúde.

A solução de BI ofertada deve permitir a conectividade com sistema gerenciador de qualquer banco de dados online.

Deve permitir a integração de dados e informações de múltiplas fontes heterogêneas ou não.

Deve possuir mecanismo para controle de conteúdo e de acesso.

A solução deve permitir o gerenciamento das fontes de dados, dos módulos analíticos, dos metadados e das estruturas informacionais (Cubos).

Deve possuir repositório de metadados centralizado e único.

Deve possuir mecanismo ou funcionalidade para a geração de scripts de extração para múltiplos sistemas gerenciados de bancos de dados.

Deve possuir mecanismo ou funcionalidade para criação dos processos de ETL (extração, transformação e carga).

Deve possuir funcionalidade ou ferramenta para gerenciamentos dos modelos de informação

Deve permitir a integração de bases de dados heterogêneas

Possuir funcionalidade ou mecanismo para construção e gerenciamento dos metadados

Deve permitir a execução de mais de um processo simultâneo

Deve permitir a criação de gráficos em formatos variados

Deve apresentar em tempo real todos os indicadores da saúde da família descrito neste termo.

Deve possuir relatório integrados demonstrando o atendimento de cada profissional, incluindo tempo de atendimento médico para cada paciente.

Deve possuir relatório integrado demonstrando o atendimento e aplicação de cada vacina aplicada.

Deve possuir o controle de transporte para pacientes TFD demonstrando a localidade e o número de pacientes em viagem. Em tempo real.

Deve possuir controle de avaliação do atendimento com possibilidade de descrever em tempo real a avaliação realizada com o paciente.

Deve possuir tópicos com a quantidade de pessoas cadastrada, família cadastrada, Domicilio Ativos, Profissionais ativo.

35. DA PLATAFORMA DE APLICATIVOS MÓVEIS AMBIENTE DE DESENVOLVIMENTO Os aplicativos móveis criados no Ambiente de Desenvolvimento devem poder ser executados, sem a necessidade de qualquer tipo de adaptação, no mínimo sobre as seguintes plataformas:

a) Google Android versão 2.1 ou superior;

b) Apple iOS versão 4 ou superior;

c) RIM Blackberry 4.6.1 ou superior; e

d) Java Micro Edition (JME) com MIDP 2.x ou superior e CLDC 1.1 ou superior.

A empresa de possibilitar as informações a serem coletadas, no mínimo, como campos dos seguintes tipos básicos de dados:

a) Alfanumérico (restrição de tamanho);

b) Numérico (restrição de número de dígitos inteiros e decimais);

c) Lista de valores de seleção única (definição dos códigos de retorno e descrições dos itens da lista);

d) Lista de valores de seleção múltipla (definição dos códigos de retorno e descrições dos itens da lista);

e) Lógico (definição do valor de retorno se verdadeiro ou e se falso);

f) Data;

g) Hora;

h) Fotos capturadas;

I) Desenhos manuscritos; e

j) Qualificação (avaliação).

Deve ser possível definir, no mínimo, as seguintes restrições adicionais sobre os campos:

a) Preenchimento obrigatório ou opcional;

b) Editável ou não editável;

c) Visível ou não visível; e

d) limites máximos de tamanho / conteúdo.

Deve ser possível a criação de um número ilimitado de campos relacionados:

a) ao formulário;

b) ao local em que está sendo realizada a atividade;

c) ao usuário que está executando a atividade; e

d) aos itens, quando se tratar de coleta de informações por itens.

Deve ser possível a definição de fórmulas de cálculo de valores derivados, de forma que, a partir de um ou mais campos, pode ser calculado automaticamente o valor de outro campo. Os operandos das fórmulas de cálculo devem incluir:

a) Campos do formulário;

b) Campos do local em que está sendo realizada a atividade;

c) Campos do usuário que está executando a atividade; e

d) Campos dos itens, quando se tratar de coleta de informações por itens.

Devem ser suportados, no mínimo, os seguintes operadores aritméticos:

a) Adição, subtração, multiplicação e divisão;

b) Somatório; e

c) Junção de textos (concatenação) e quebra de linha.

Deve ser possível a definição de expressões condicionais, de forma que a partir da avaliação da expressão, definida sobre valores de um ou mais campos, seja possível definir as seguintes restrições:

a) Impedir o encerramento do preenchimento do formulário; ou

b) Exibir uma mensagem, mas permitir o encerramento do preenchimento do formulário.

Devem ser suportados, no mínimo, os seguintes operadores lógicos:

a) Igual, diferente, maior, menor, maior ou igual, menor ou igual; e

b) E (and), Ou (or).

Deve permitir a captura de imagens (fotos) com a câmera do dispositivo móvel. Deve permitir a captura de anotações livres (desenhos) em dispositivos com tela sensível ao toque. Deve permitir a captura de coordenadas de GPS (Global Positioning System) do dispositivo móvel, se houver, para registro georreferenciado no momento da execução da tarefa de campo. 36. DO AMBIENTE DE EXECUÇÃO DE APLICATIVOS MÓVEIS Deve suportar a execução dos aplicativos criados no Ambiente de Desenvolvimento sem a necessidade de qualquer tipo de adaptação, sobre dispositivos móveis operando, no mínimo, as seguintes plataformas:

a) Google Android versão 2.1 ou superior;

b) Apple iOS versão 4 ou superior;

c) RIM Blackberry 4.6.1 ou superior; e

d) Java Micro Edition (JME) com MIDP 2.x ou superior e CLDC 1.1 ou superior.

A execução dos aplicativos deverá ocorrer através de código nativo de cada uma das plataformas, não sendo permitida a execução através de navegador internet do dispositivo móvel. Deve ser um aplicativo instalado no dispositivo móvel e não acessar através de navegadores de internet. Não deve permitir simulação de aplicativo através de páginas de internet ou do navegador do dispositivo móvel. A interface gráfica dos aplicativos móveis deverá respeitar o padrão de usabilidade de cada umas das plataformas suportadas. A instalação do Ambiente de Execução nos dispositivos móveis deve poder ser realizada das seguintes formas:

a) Via download a partir da própria Infraestrutura Operacional da Plataforma, deve estar disponível para download nas lojas do sistema operacional respectivamente instalado no dispositivo.

b) Via remessa de mensagem de texto para o dispositivo móvel do usuário com link para download.

c) Via transferência de arquivo por cabo USB.

Deve apresentar para o usuário do aplicativo móvel as tarefas de campo que deve executar. Deve permitir que o usuário execute tarefas de campo não previamente programadas ou previstas em rotas. A sincronização de dados entre os aplicativos móveis e a Infraestrutura Central da Plataforma deve se dar alternativamente de forma automática ou manual, permitindo sua operação on-line ou off-line, quando, por exemplo, o usuário estiver fora de áreas de cobertura das operadoras de telefonia móvel ou rede wi-fi. Deve possuir opção para realização de sincronização manual de dados com a Infraestrutura Central da Plataforma. Caso a sincronização não seja possível em determinado momento, por falta de cobertura de telecomunicação, os dados devem ser mantidos no repositório do dispositivo móvel para sincronização posterior. A sincronização deve ser bidirecional, ou seja, durante sua realização todos os dados coletados no dispositivo móvel são transmitidos para a Infraestrutura Central da Plataforma, e desta são recebidos os dados sobre novas atividades de campo a cargo do usuário, entre outras informações. Novos aplicativos, bem como as customizações executadas em aplicativos já existentes, empregando o Ambiente de Desenvolvimento, devem ser disponibilizadas para os usuários em campo, automaticamente através da sincronização, sem a necessidade de intervenção dos mesmos. 37. DO AMBIENTE DO ACS – MOBILIDADE Deve possuir os formulários do E-SUS integrados com o sistema de gestão. Formulário de Cadastro Individual – E-SUS. Formulário de Visita Domiciliar– E-SUS. Formulário de Cadastro Domiciliar– E-SUS. 38. DA VIGILÂNCIA SANITÁRIA O Sistema deverá permitir o cadastro, edição, consulta e exclusão de um roteiro. O formulário para cadastro do roteiro deverá conter no mínimo os seguintes campos:

Nome do Roteiro

Tipo ou natureza do estabelecimento

Tipo de atividade exercida

Ativo/Inativo.

Tipo de Prestador

Nível de Atenção

Grau Complexidade

O Sistema deverá organizar o questionário em capítulos e categorias.

O Sistema deverá permitir que os questionários sejam bloqueados para edição, não permitindo assim a sua alteração.

O Sistema deverá permitir o cadastro, edição, consulta e exclusão de perguntas, sem limite ao seu número. O formulário para cadastro das perguntas deverá conter no mínimo os seguintes campos:

Descrição

Tipo de Comprovação

Nível

Obrigar ou não anexos de documentos

Aceitar ou não a opção de inaplicável

Referência

Tipo de Pergunta (Sim, Não, NA)

Comentário

§ O Sistema deverá fornecer uma forma de comunicação bidirecional entre a Vigilância Sanitária e os Estabelecimentos, no mínimo com as seguintes funcionalidades:

Envio de mensagem única da Vigilância Sanitária para todos os estabelecimentos

Envio de mensagem da Vigilância Sanitária para um ou mais Estabelecimentos, ficando visível para todos os usuários dos Estabelecimentos selecionados.

Envio de mensagem da Vigilância Sanitária para usuários específicos de um Estabelecimento

Envio de mensagem do Estabelecimento para um ou mais usuários da Vigilância Sanitária

A aplicação deve possuir mecanismo ou funcionalidade que permita a inclusão de novo comunicados contendo, no mínimo, os seguintes campos:

Titulo

Texto (com possibilidade de formatação HTML)

Data da tramitação

Usuários remetente

O Sistema deverá apresentar um formulário para a inclusão de denúncias. O formulário deverá possuir no mínimo os seguintes campos: Tipo do denunciante Nome Contato Recebimento do andamento da denúncia por e-mail

Data da Denúncia

Hora da denúncia

Descrição

Tipo da denúncia

Estabelecimento

Anexos

O Sistema deverá exibir uma relação com as denúncias cadastradas e um formulário para pesquisa de denúncias. A listagem deverá conter no mínimo as seguintes informações:

Número do protocolo da denúncia

Data da denúncia

Situação

Meio de entrada da denúncia

Denunciado / Nome O Sistema deverá exibir formulário que permita filtrar os estabelecimentos no mínimo pelos seguintes campos:

Tipo de Estabelecimento/Pessoa

CNAE principal

Endereço

CNPJ ou CPF

Razão Social

Nome Fantasia

Contabilidade gerenciadora do estabelecimento.

§ O Sistema deverá possibilitar a visualização de todas as operações realizadas pelos usuários, contendo no mínimo a data e horário de todas as operações.

O Sistema deverá permitir que um usuário com perfil de administrador possa cadastrar a relação de documentos necessárias baseada no tipo de estabelecimento. Deverá definir se o documento é obrigatório ou não. O Sistema deverá permitir que o administrador faça a manutenção das tabelas de dados do Sistema. O Sistema deverá permitir que o administrador faça a criação das contas de usuários para os membros da vigilância sanitária e estabelecimentos. O sistema deverá possibilitar que qualquer usuário seja capaz de acessá-lo através da inserção do tipo, identificação e senha do usuário através de uma página de entrada. O sistema deverá possuir procedimento para recuperação da senha caso um usuário a tenha esquecido O sistema deverá restringir o acesso do usuário às suas funcionalidades de acordo com seus papéis O sistema deverá permitir que o administrador atribua os papéis dos usuários.

§ O sistema deverá exibir os serviços que o estabelecimento pode solicitar perante a Vigilância, entre eles:

Solicitação de Alvará Sanitário

Alteração de dados do Alvará

Solicitação de Baixa de Alvará Sanitário

Solicitação de Revalidação de Alvará Sanitário

Solicitação de Alvará para eventos.

Solicitação de alteração de Responsável Técnico

Solicitação de Licença de Transporte

Solicitação de licença de transportes

Solicitação de alteração do responsável lega

§ O sistema deverá disponibilizar um acesso de acompanhamento e liberação de solicitações para os estabelecimentos.

§ O sistema deverá disponibilizar uma forma de emissão de documentos (Alvará Sanitário, auto de infração, auto de intimação, auto de notificação, dispensa de alvará e gerar DAM/DARE).

§ O sistema deverá gerar indicadores ou relatórios os quais poderão contribuir para a otimização da produtividade da Vigilância.

O sistema deverá possuir um local o qual os seguintes dados da própria vigilância podem ser exibidos e editados: Razão Social Instituição / Órgão Superior Secretário(a) Municipal de Saúde Responsável de Vigilância Sanitária Cargo do Responsável Portaria do cargo do responsável Telefone Celular E-mail Dados Bancários Denominação Tipo da Conta Bancária CPF/CNPJ Banco Agência Digito da Agência Conta Corrente Digito da Conta Corrente Carteira Tipo Modalidade Carteira Modalidade Carteira Dados de Endereçamento CEP Logradouro Complemento Bairro Estado Cidade Nome E-mail CPF Nascimento Telefone Informações para geração do BPA Órgão de origem Sigla do órgão CGC/CPF do prestador Nome do órgão destino Indicador do órgão destino CNES Funcionalidade que permite a vigilância sanitária informar quais as atividades são de responsabilidades municipais e quais são do Estado. Opções de cadastro de usuário contador que deseja gerenciar um ou mais de seus estabelecimentos, contendo:

§ Tipo de Pessoa: Física ou Jurídica

CPF/CNPJ

Inscrição Estadual

Inscrição Municipal

Razão Social

Nome Fantasia

E-mail

Telefone

Celular

Site

Conselho Regional de Contabilidade

Nº CRC

§ Dados dos Profissionais

Cargo

Nome Completo

CPF

Conselho Regional de Contabilidade

Nº CRC

Telefone

Endereço do Estabelecimento

CEP

Logradouro

Número

Complemento

Bairro

Estado

Cidade

§ Cadastro de Estabelecimentos

§ Vinculação de Estabelecimento

Deve possuir mecanismo ou funcionalidade que permita o gerenciamento das solicitações dos estabelecimentos vinculados com, no mínimo, as seguintes operações:

Gerar Solicitações

Acompanhar andamento das solicitações

A solução ofertada deve possuir mecanismo ou funcionalidade que permita que os próprios estabelecimentos iniciem os processos de qualificação, com a realização de seu cadastro, contendo, no mínimo os seguintes campos:

CNPJ

Inscrição Estadual

Inscrição municipal

CPF

CNAE

Razão Social

Nome Fantasia

Telefone

Endereço eletrônico

E-mail Principal

Nome da Pessoa de Contato

Função da Pessoa de Contato

E-mail da Pessoa do Contato

Telefone da Pessoa de Contato

Tipo de Endereço

Logradouro

Número

Complemento

Bairro

CEP

UF (Lista de Estados)

Localização

Cidade (Lista baseada na UF selecionada)

O sistema deve exibir a lista de documentos necessários para o estabelecimento em processo de cadastramento. A lista deve possuir, no mínimo, as seguintes informações:

Tipo de Documento (Lista de opções).

Descrição do Documento.

Vincular documentos (Lista de opções)

No sistema, associado à lista de documentos necessários, a aplicação deverá permitir o cadastro, edição e exclusão das informações para cada documento. No login de cada estabelecimento, associado a lista de documentos necessários, a aplicação deve permitir que o estabelecimento anexe os documentos. A aplicação deve possuir mecanismo para os administradores do sistema possam cadastrar a lista de documentos necessários para cada tipo de estabelecimento, identificando quando determinado documento é ou não obrigatório. A cada estabelecimento, a aplicação deve permitir que sejam cadastrados, editados e excluídos equipamentos, com, no mínimo, as seguintes informações para cada equipamento:

Nome do Equipamento.

Modelo.

Descrição.

Empresa Manutenção

Última Manutenção

Ano de Fabricação

A solução deverá enviar um e-mail ao estabelecimento quando algum dado ou documento tenha sido rejeitado. A aplicação deve permitir que os estabelecimentos preencham formulários de solicitação de alvará com um número de protocolo. O sistema deve permitir que os próprios estabelecimentos emitam suas guias de pagamento de alvarás. A aplicação deve possuir mecanismo para o agendamento manual de eventos com, no mínimo, as seguintes informações:

Título.

Descrição.

Data de início.

Data de término

Endereço.

Tipo de evento

Arquivos anexados (opcional)

participantes

O Sistema deverá possibilitar a visualização dos compromissos agendados, em formato de calendário, com visualizações em formato diário, semanal e mensal. A aplicação deve permitir que os estabelecimentos possam acessar o sistema e consultar todas as inspeções atreladas ao estabelecimento. 39. DA VIGILÂNCIA EPIDEMIOLÓGICA Possuir funcionalidade ou mecanismo para criação das fichas de investigação da vigilância epidemiológica contendo descrição, CID’s 10 compatíveis Deve possuir mecanismo para cadastramento das perguntas que irão compor as fichas de investigação de cada notificação Deve possuir mecanismo ou funcionalidade que permita a criação das perguntas que que compões cada ficha de investigação contendo:

campo para o questionamento a ser realizado

tipo da resposta a ser aceito para cada pergunta podendo variar entre campos descritivos, numéricos, campos para datas e múltipla escolha, neste caso permitindo que sejam informadas as opções para cada pergunta, assim como a seleção de um ou mais itens de acordo com a necessidade no momento da identificação das respostas.

campo para inserção de ajuda para cada pergunta e campo de observação a ser utilizado nos questionamentos pertinentes

Deve possuir mecanismo para gerenciamento de notificações contendo os campos:

número da notificação, tipo da notificação (negativa, individual, surto ou Inquérito Tracoma), agravo ou doença, data da notificação, uf, município, unidade de saúde notificadora, data dos primeiros sintomas, paciente, data de nascimento, idade (em Anos, Meses, Dias e Horas), sexo, gestante, raça/cor, escolaridade, número do cartão SUS e nome da mãe

Dados detalhados da residência do notificado contendo bairro, cep, latitude, longitude, logradouro, número, complemento, pontos de referência, ddd, telefone e zona (rural ou urbana).

Informações cobre o surto como data do primeiro caso suspeito, número de casos suspeitos, local inicial da ocorrência do surto (residência, hospital/unidade de saúde, creche/escola, outras instituições, restaurante/padaria, casos dispersos no bairro ou município, casos dispersos em mais de um município e outros), permitindo ainda a identificação de outros locais iniciais de ocorrência.

Unidade de saúde da notificação, nome do responsável, função e situação (registrado, avaliando, investigando, providenciado, cancelado e rejeitado)

Deve possuir funcionalidade ou mecanismo que permita que sejam listados na vigilância epidemiológica todos os CID’s relacionados nos atendimentos médicos em locais informatizados, que forem notificáveis. Deve possuir mecanismo ou funcionalidade que permita o envio de e-mails para os responsáveis pelo setor de epidemiologia em intervalos pré-definidos, listando todos os CID’s notificáveis relacionados em atendimentos médicos nos locais informatizados. 40. DO MÓDULO DE CERTIFICAÇÃO DIGITAL

Os componentes do módulo devem estar aderentes ao DOC-ICP-15 e demais documentos relacionados (DOC-ICP-15.01, DOC-ICP-15.02 e DOC-ICP-15.03), que trata dos requisitos técnicos para solução de assinatura digital no âmbito da ICP-Brasil.

Todas as funcionalidades do módulo devem ser disponibilizadas em componentes modulares distintos, que permitam assinar, validar as assinaturas digitais, verificar certificados, manipular e gerenciar LCRs, requisitar e anexar carimbo do tempo.

Todos os componentes do módulo devem ser acessíveis por meio de web-services que suportem implementação de segurança para autenticação e autorização de serviços através de canal SSL duplamente autenticado com uso de certificado digital.

Todos os componentes do módulo devem ser capazes de permitir a geração, visualização e armazenamento de registro eletrônico (LOG) dos procedimentos executados bem como das informações pertinentes a usuário e rede, para fins de auditoria.

A solução deverá ser fornecida com a última versão no momento da implantação e deverá possuir as seguintes características técnicas:

Suportar os Sistemas Operacionais Linux SuSe, RedHat, Debian e Ubuntu e Windows XP, 2000, 2003, Vista e Windows 7.

Suportar os navegadores Internet Explorer 7 e superiores e Firefox 2.x e superiores.

Permitir integração com sistemas já existentes, incluindo as aplicações nas linguagens PHP e Java.

Suporte a dispositivos criptográficos nos padrões PKCS#11 e Microsoft CAPI.

Suporte ao uso de Repositórios Criptográficos do Windows (CryptoApi) e Mozilla (NSS).

No caso de Applet para assinatura em ambiente Web, a mesma deve ser assinada digitalmente por certificado reconhecido como confiável em ambiente operacional Windows e Linux.

Deve permitir o reconhecimento automático do modelo de token e smartcard conectado do slot de hardware e carregar automaticamente o driver PKCS#11 específico.

O componente deve possuir interface gráfica de administração web. A interface não deverá ser requerida para uso dos serviços do módulo, estando todas as funcionalidades dos componentes disponíveis via web services.

A plataforma deverá suportar o cadastramento de certificados digitais de usuários, que passarão a ter sua validade monitorada. O sistema deverá enviar alerta via e-mail sempre que um certificado digital estiver prestes a expirar ou que tiverem sido revogados.

A plataforma deverá contar com componente capaz de gerenciar listas de políticas de assinatura, baixando-as automaticamente a partir do ponto de distribuição definido pela ICP-Brasil e configurando os processos de validação de acordo com as novas definições.

Autenticação (Login) em Aplicações Web com Certificado Digital.

A Solução deverá ser composta por um conjunto de web-services organizados da seguinte forma:

Componente Assinador para geração de assinatura digital em documento eletrônico;

Componente Verificador para verificar validade de assinatura digital em documento eletrônico;

Componente Carimbador para requisitar carimbo de tempo;

Componente Validador para verificar validade de certificado digital e sua correspondente cadeia de certificação;

Componente Gerenciador de Lista de Certificados Revogados - LCR para gerência e consulta de listas de certificados revogados.

41. DO COMPONENTE PARA ASSINATURA DIGITAL

Deve gerar assinaturas simples, coassinaturas e contra-assinaturas no padrão CMS Advanced Eletronic Signature - CAdES de acordo com o DOC-ICP 15.03, permitindo as representações attached e detached por meio da codificação DER.

Deve gerar assinaturas simples, coassinaturas e contra-assinaturas no padrão XMLdSIG Advanced Eletronic Signature – XAdES de acordo com o DOC-ICP 15.03, permitindo as representações enveloped, enveloping e detached.

Deve gerar assinaturas simples, coassinaturas e assinatura de autoria no formato PDF Signature de acordo com o padrão ISO 32000-1.

Para assinaturas digitais dos formatos CAdES e XAdES a Solução deve gerar assinatura digital seguindo todas as políticas de assinatura definidas pela ICP-Brasil no DOC-ICP 15.03:

Assinatura Digital com Referência Básica (AD-RB);

Assinatura Digital com Referência do Tempo (AD-RT);

Assinatura Digital com Referências para Validação (AD-RV);

Assinatura Digital com Referências Completas (AD-RC);

Assinatura Digital com Referências para Arquivamento (AD-RA).

Deve anexar ou conectar logicamente à assinatura digital o Carimbo do Tempo seguindo os padrões da DOC-ICP 15 e RFC 3161.

Para assinaturas digitais do formato PDF Signature a Solução deve permitir a inclusão de carimbos do tempo nas assinaturas digitais geradas. O perfil do carimbo do tempo utilizado deve seguir as regulamentações da ICP-Brasil:

Resolução 78 de 06 de Abril de 2010 (DOC-ICP-11);

Resolução 59 de 28 de novembro de 2008 (DOC-ICP-12);

Resolução 60 de 28 de novembro de 2008 (DOC-ICP-13).

A Solução deve verificar a validade do certificado digital do signatário e sua correspondente cadeia de certificação no momento da geração da assinatura digital.

A Solução deve ser configurável de modo a permitir a continuação ou não da assinatura caso o certificado esteja inválido.

A Solução deverá ter a funcionalidade de gerar assinatura digital em lote de documentos de acordo com as definições da resolução nº. 76 de 31 de março de 2010 do ITI e com a segurança necessária de acordo com as definições do documento DOC-ICP-15.01 da ICP-Brasil.

É obrigatório que a Solução realize a assinatura digital sem requerer a exportação da chave privada do signatário do repositório seguro onde ela estiver armazenada.

No processo de assinatura digital, no mínimo, as seguintes funcionalidades deverão ser executadas pelo módulo cliente:

Cifragem do resumo criptográfico (Assinatura Digital);

Envio das configurações de assinatura que deverão ser geradas: padrão de assinatura e política de assinatura;

No processo de assinatura digital, no mínimo, as seguintes funcionalidades deverão ser executadas pelo módulo servidor:

Montagem da assinatura digital de acordo com o padrão e política de assinatura selecionada;

A empresa deve disponibilizar sem nenhum custo adicional assinatura digital para todos os médicos do PAM.

Comunicação com WebService de carimbo do tempo, validação de certificados digitais e de gerenciamento da lista de certificados revogados;

42. DO COMPONENTE PARA CARIMBO DO TEMPO

Deve estar preparado para o uso de Carimbo de Tempo por meio de integração com Solução externa, via TimeStamp Protocol – TSP, de acordo com as definições da Resolução nº. 78 de 06 de Abril de 2010 do ITI.

Deve estar preparado para gerar requisições de carimbo do tempo que permitam o controle de acesso ao servidor do carimbo do tempo, conforme as especificações do Servidor do Carimbo do Tempo.

Deve emitir requisições TSQ (TimeStampReq) para envio ao SCT e processar respostas do tipo TSR (TimeStampResp), por meio do protocolo TSP (Time-stamp Protocol) compatível com as definições da resolução nº 78 de 06 Abril de 2010 do ITI.

Deve decodificar Carimbo do Tempo e extrair todas as informações presentes no carimbo do tempo conforme resolução nº 78 de 06 Abril de 2010 do ITI.

Deve validar Carimbo do Tempo (Integridade da assinatura do carimbo, status do certificado que assinou o carimbo).

Deve gerar carimbo do tempo de documentos não assinados digitalmente (carimbo do tempo de conteúdo).

Deve possuir opção para gerar carimbo do tempo baseado no resumo criptográfico (hash) de um conteúdo.

Deve permitir a obtenção de carimbo do tempo de Servidor de Carimbo do Tempo e Autoridade de Carimbo do Tempo externa.

Deve permitir a obtenção de carimbo do tempo de Autoridade de Carimbo do Tempo com requisição autenticada de acordo com a RFC 3161.

Deve utilizar carimbo do tempo de autoridade de carimbo do tempo credenciada junto ao observatório nacional ou junto à ICP-Brasil.

43. DO COMPONENTE PARA VERIFICAÇÃO DE ASSINATURA DIGITAL

Deve seguir as definições do documento DOC-ICP-15.01 da ICP-Brasil para validação de assinaturas digitais nos padrões CAdES e XAdES.

Deve disponibilizar funções de verificação de assinatura digital no formato PDF Signature. Quando a assinatura possuir carimbo do tempo associado, a referência temporal para as validações necessárias deve utilizar a data presente no carimbo do tempo.

Deve permitir o envio de um lote de assinaturas digitais para verificação.

Deve retornar os valores de modo a permitir a visualização dos dados das assinaturas digitais e os atributos do certificado de cada signatário do documento.

O formato para devolução dos valores deve utilizar o formato XML e, no mínimo, as seguintes informações deverão ser retornadas:

Status da Verificação (Integridade da assinatura);

Status dos Certificados Digitais (válido, inválido, revogado, expirado, ainda não válido, não confiável);

Tipo de Política de Assinatura Utilizada;

Hash do Documento Assinado;

Dados dos Assinantes (no mínimo: nome, RG, CPF, data de nascimento, email, título de eleitor);

Dados dos Carimbos do Tempo (para as políticas que exijam carimbo: AD-RT, AD-RV, AD-RC, AD-RA, no mínimo: data do carimbo, número serial, emissor);

Informações sobre LCRs e Cadeia de Certificados (para as políticas que exijam estas informações);

Dados das LCRs e Cadeia de Certificados (para as políticas que exijam estas informações);

Deve validar o certificado digital do signatário (válido, inválido revogado, expirado) no ato da conferência da assinatura e permitir que, para cada assinatura digital, seja visualizada a situação da verificação ou a descrição do erro caso a assinatura digital seja inválida.

Deve possuir API nas linguagens Java, C++ Linux e COM Windows para facilitar a integração com o webservice de verificação de assinatura digital, incluindo um conjunto de funções para configuração de parâmetros da conexão SSL com a Solução e definição de dados para verificação da assinatura digital (no mínimo: assinatura, documento).

44. DO COMPONENTE PARA VALIDAÇÃO DE CERTIFICADO DIGITAL

Deve ser capaz de validar qualquer tipo de certificado digital e sua correspondente cadeia de certificação, padrão ICP-Brasil.

Deve ser capaz de validar lotes de certificados digitais, incluindo certificados de cadeias de certificação diferentes no mesmo lote.

Para validação do certificado digital devem ser consultadas as LCRs disponíveis na Solução (componente de gerenciamento de LCR) ou diretamente no endereço de publicação da LCR de cada certificado.

Deve possuir mecanismo de cache das respostas obtidas desde que observado o tempo de validade de cada LCR.

Deverá possuir interface de cadastramento de cadeias de certificação confiáveis;

O cadastro de certificado de Autoridade Certificadora Raiz deve possuir controle duplo de autorização de cadastro, isto é, autorização de dois usuários com perfil Administrador.

Deverá utilizar o atributo AIA (Authority Information Access) conforme previsto no DOC-ICP-04 da ICP Brasil para realizar o download automático da cadeia de certificação quando da execução da validação de um certificado digital cuja cadeia não esteja cadastrada na Solução.

Deve verificar se a AC Raiz da nova cadeia de certificação já está cadastrada e habilitada na Solução, caso contrário o processo deve ser interrompido.

Deve verificar a validade e o estado de revogação da nova cadeia de certificação, interrompendo o processo caso exista alguma inconformidade.

Em resposta a uma consulta, o componente validador deve informar o status do certificado e da cadeia de certificação.

A consulta deve possuir opção para solicitar a decodificação e retorno de todos os dados presentes no certificado validado conforme DOC-ICP-04 da ICP Brasil.

A consulta deve possuir opção para solicitar a decodificação e retorno de todos os dados presentes nos certificados da cadeia de certificação conforme DOC-ICP-04 da ICP Brasil.

A consulta deve possuir opção para retornar a cadeia de certificação completa do certificado validado no formato Base64.

Deve permitir o cadastro de certificados, cujas validades serão monitoradas, ao longo de seu ciclo de vida. O sistema deverá alertar administradores e responsáveis pelos certificados, via e-mail, da proximidade de sua expiração. O tempo de antecedência e textos de alerta das mensagens devem poder ser configurados, via interface administrativa.5.5 Componente para Gerenciamento de LCR.

Deve ser capaz de capturar (fazer download da Internet), periodicamente, as LCRs de todas as Autoridades Certificadoras (AC) configuradas como confiáveis no componente de validação de certificado digital, armazenando o histórico completo de publicações em seu repositório interno.

Deve armazenar o histórico de LCRs de forma compactada, com vista a preservar o espaço interno do repositório.

Nenhuma LCR deve ser removida da base de dados do módulo para que o histórico de todas as LCRs fique armazenado com tempo de atraso de disponibilização da LCR se for o caso.

Essa base de dados deve estar disponível para uso pelos demais componentes do módulo.

Deve permitir a consulta de LCR através do certificado que será validado, através da chave de autoridade do certificado que emitiu a LCR e através do ponto de distribuição onde a LCR é publicada pela Autoridade Certificadora.

Deve ser capaz de identificar e manipular todos os tipos de certificados digitais padrão ICP-Brasil.

Deve ser capaz de manipular listas de certificados revogados que implementam a versão 2, ou versão atual, do padrão ITU-T X.509.

Deve ser capaz de verificar a validade de cada LCR armazenada na base dados específica, de modo a capturar automaticamente uma nova versão na Autoridade Certificadora - AC emissora, mantendo essa base sempre atualizada.

Deve ser capaz de validar a assinatura de cada LCR obtida junto às AC, conferindo se realmente a LCR foi emitida pela Autoridade Certificadora indicada.

Em termos de gerência das listas mantidas na base de dados, o componente gerenciador de LCR deve:

Permitir a inclusão e exclusão de Autoridades Certificadoras das quais as LCR devem ser capturadas;

Ter suporte para utilização de múltiplos endereços de Ponto de Distribuição de LCR para uma mesma AC;

Prover um mecanismo de alerta por e-mail que dê ciência ao administrador do sistema sobre problemas com a atualização de cada LCR tratada.

45. DO COMPONENTE PARA O GERENCIAMENTO DE POLÍTICAS DE ASSINATURA

A empresa deve seguir o padrão brasileiro de assinatura digital utiliza políticas de assinatura, que garantem diferentes níveis de proteção aos documentos, de acordo com a necessidade (AD-RB a AD-RA). Essas políticas de assinatura evoluem ao longo do tempo, entre outros motivos, pela própria evolução dos algoritmos criptográficos. Mediante uma alteração dessa natureza, entra em vigor uma nova regulamentação da ICP-Brasil, que atualiza a versão da política. Para permitir o registro dessas diferentes revisões, o órgão normativo publica, periodicamente, uma lista contendo as políticas existentes e suas diferentes versões, bem como seu status atual (se ainda continuam vigentes). Com vista a permitir o suporte à evolução do padrão brasileiro, em conformidade com as políticas de assinatura vigentes, bem como as vindouras, o componente de assinatura digital deverá suportar o gerenciamento automático de Listas de Políticas de Assinatura (LPAs). Dessa forma, o sistema deverá permitir:

O cadastramento de endereços, dos quais serão obtidos, de forma automática e periódica, novas versões da lista de políticas de assinatura aprovadas;

Com base nas informações obtidas com a interpretação automática das listas cadastradas, a solução deverá desabilitar as políticas de assinatura revogadas ou expiradas, atendendo apenas às requisições de assinatura sob versões de políticas em vigência, orientando assim os usuários dos serviços a estarem sempre atualizados com relação às normativas da ICP-Brasil;

O componente Gerenciador de Políticas de Assinatura deve permitir o gerenciamento das políticas de assinatura dos padrões CADES e XAdES de acordo com o DOC-ICP 15.03 da ICP Brasil.

O componente Gerenciador de Políticas deve possuir interface gráfica para visualização dos dados de cada política de assinatura como OID da política, versão, período de assinatura, hash da política e estado (válida, expirada, revogada).

O componente Gerenciador de Políticas através de sua interface gráfica deve permitir habilitar ou desabilitar uma determinada política de assinatura e definir qual a versão padrão de cada política.

O componente Gerenciador de Políticas deve possuir mecanismo para verificação da assinatura digital da LPA.

O componente Gerenciador de Políticas deve possuir um webservice que permita consultar as políticas de assinatura adequadas para um determinado certificado de acordo com as recomendações e restrições dispostas no DOC-ICP 15.03 da ICP Brasil.

O componente deve prover mecanismo de alerta por e-mail aos administradores do sistema sobre problemas com a atualização da LPA.

46. OS MÓDULOS DO HOSPITAL MUNICIPAL E APLICATIVOS OBRIGATORIOS E INTEGRADOS COM A REDE MUNICIPAL DE SAUDE INTEGRADA O CONTROLE DE AVALIAÇÃO EM TEMPO REAL.

PORTARIA E CONTROLE DE VISITAS

Permitir o controle de visitas a pacientes internados no hospital. Permitir o cadastro de acompanhantes. Controlar o fluxo de visitas aos leitos, de modo que após o horário da visita possa identificar-se os leitos que ainda possuem visitantes. Permitir consultar e imprimir relatórios por período de visitantes por leito e por dia identificando a hora da visita. Permitir controle integrado com o aplicativo móvel.

RECEPÇÃO E INTERNAÇÃO

Permitir a configuração de alas, quartos e leitos do hospital. Permitir cadastro de pacientes integrado ao CADSUS Permitir a identificação de quartos e leitos apresentando os ocupados e os disponíveis por ala Permitir cadastros de profissionais integrados ao SCNES Permitir a emissão d FAA (Ficha de Atendimento Ambulatorial) com todos os dados do atendimento de urgência Identificar a data e a hora da internação, data provável de alta, ala, quarto, leito, acompanhante, médico responsável, tipo de tratamento e motivo de internação. Controlar a taxa de ocupação de leitos por ala Identificar a data e hora da internação Permitir o cálculo de diversos índices hospitalares Permitir o controle de cotas por município. Atender o modelo de guias TISS Atender os padrões de fichas exigidas pelo SUS, além de customização e criação de novas fichas Permitir relatórios diversos, tais como estatísticas de ocupação por ala, pacientes internados, previsão de altas, altas confirmadas por motivo (alta, evasão, internação cancelada, transferência ou óbito) Permitir emissão de relatórios e consultas de histórico de internações por paciente (por origem, por médico e por patologia) Gerenciar o prontuário único, considerando todos os atendimentos do paciente na rede municipal de Saúde Permitir georeferenciamento na base cartográfica digital oficial do município indicando a localização da residência de cada paciente atendido, permitindo o mapeamento por tipo de atendimento, por CID diagnosticado, por procedimento realizado, por faixa etária, por sexo, por origem, por Bairro Permitir o cadastro de turnos e escala dos profissionais por turno, para posterior verificação de faltas e troca de profissionais nas escalas

AGENDAMENTO CIRÚRGICO

Permitir cadastrar e identificar os pacientes cirúrgicos. Permitir cadastrar as salas cirúrgicas e aparelhos cirúrgicos. Permitir agendar cirurgias por paciente, por sala ou por médico. Permitir controle de agenda. Controlar as salas já ocupadas e as disponíveis considerando horário de inicio e previsão de término. Permitir consultas acerca das salas cirúrgicas por período, informando o paciente, o médico responsável e o tipo de cirurgia realizada bem como os procedimentos. Permitir o controle de acesso a informações consideradas confidenciais. Permitir o cadastro de cirurgias por classificação, por procedimento e por porte. Permitir o controle de execução das cirurgias, informando se foi realmente realizada ou não, e os profissionais que participaram da mesma. Integrar com o módulo de faturamento.

PRESCRIÇÃO ELETRÔNICA

Permitir integração com o módulo de estoque de modo que seja efetuada a baixa do medicamento prescrito. Permitir ao médico a realização e o total acompanhamento da evolução do paciente. Permitir a solicitação de exames. Permitir o acompanhamento de medicações prescritas e a data e hora da prescrição. Permitir que observações possam ser digitadas acerca da prescrição realizada. Permitir a emissão e/ou visualização do prontuário do paciente de todos atendimentos já realizados na rede pública de saúde. Permitir que o médico inicie o atendimento somente após o reconhecimento biométrico e, em caso de falha na leitura biométrica, permitir a liberação de acesso através de login e senha. Permitir a configuração de tempo para que o sistema exija reconhecimento biométrico do profissional para liberação de acesso, e, em caso de falha na leitura biométrica, permitir a liberação de acesso através de login e senha. Permitir a realização de evolução médica e emissão de resumo de alta . Permitir o histórico clínico dos sinais vitais e evolução de enfermeiros e outros profissionais assistenciais.

FATURAMENTO (AIH).

Permitir a digitação das AIH’S com a integração da recepção dos pacientes e dos dados da internação, agilizando o faturamento das contas; Permitir a consolidação de contas com as checagens de acordo com o SISAIH01 e o SIGTAP; Permitir a impressão dos espelhos para conferência e também para serem anexados aos prontuários com mesma base dos impressos pelo ministério. Permitir a digitação de Aih´s sem número. Permitir a transferência de Aih´s entre apresentações; Permitir a digitação do CIH reaproveitando os dados que já foram digitados na recepção; Permitir a emissão de relatórios com várias seleções para facilitar na busca dos dados que foram digitados. Permitir a exportação do faturamento nos padrões do SISRCA

ALMOXARIFADO / ESTOQUE / FARMÁCIA

Possuir controle por centros de custos de almoxarifados. Integrar ao Sistema Financeiro-Orçamentário já utilizado pelo hospital, permitindo controle de pedidos realizados. Possuir curva ABC. Emitir relatórios, por período, de itens distribuídos nos setores do hospital. Possuir dispositivos para disparar avisos quando determinado item atingir o ponto de pedido, o qual deve ser configurável para cada item. Permitir transferências e devoluções entre almoxarifados. Permitir o controle de itens entregues nos setores, através de recibos ou aceite do setor no próprio sistema. Permitir utilização de código de barra. Controlar perdas indicando o motivo. Permitir o controle de lote e validade dos produtos. Permitir a montagem de kits. Permitir o controle, de acordo com as normas da ANVISA, dos medicamentosa controlados. Permitir a certificação digital dos documentos que necessitam da assinatura digital do profissional. Permitir a entrada e dispensação de medicamentos considerando a menor unidade possível. Permitir o controle de custo de medicamentos dispensados por pacientes e por Unidade. Permitir o balanço físico e financeiro. Permitir integração com o controle de medicamento da atenção básica do Município. Permitir integração ao Controle de avaliação denominado BI.

NUTRIÇÃO

Permitir o controle de dietas e refeições por paciente. Permitir o cadastro de refeições e dietas. Permitir consultas e emissão de relatórios por período de refeições e dietas por paciente. Permitir a certificação digital dos documentos que necessitam da assinatura digital do profissional.

SAME

Permitir o controle de movimento de prontuários Permitir a localização de prontuários arquivados Emitir recibo de entrega quando o prontuário for retirado deste setor Permitir a emissão de relatórios por local de arquivamento, por paciente e por período Permitir a certificação digital dos documentos que necessitam da assinatura digital do profissional

RADIODIAGNÓSTICOS

Permitir a digitação de raio-x , tomografias , ECG , EEG. Permitir a requisição integrada com o atendimento do paciente na internação; Permitir a impressão de requisições, laudos e resultados de acordo com o lay-out do cliente; Permitir o cadastro de procedimentos genéricos com a ligação das tabelas dos convênio AMB , CBHPM e PAM, gerando o consumo automático dos procedimentos para os devidos faturamentos; Permitir a configuração dos resultados padrões para os procedimentos, facilitando a inclusão nos resultados. Permitir a agenda de exames com impressão de comprovante por unidade, e digitação de exames dos terceiros. Permitir o controle dos filmes utilizados e cobrados.

CONTROLE PRONTUÁRIOS

Permitir o controle do fluxo dos prontuários nos diversos setores pelo qual ele passar; Permitir obter informações como por exemplo, quanto tempo cada prontuário esta permanecendo em cada setor, ou em que setor ele encontra-se atualmente. Permitir o acesso aos profissionais da rede municipal de saúde. 47- DA APRESENTAÇÃO DOS SISTEMAS (PROVA DE CONCEITO) 47.1 .A apresentação poderá ser realizada pela licitante vencedora no dia do certame ou em até 05 (cinco) dias mediante agendamento do Pregoeiro para a comissão técnica nomeada pela contratante e todos os participantes da licitação interessados; 47.2. A licitante vencedora terá no máximo 4 (quatro) horas para realizar a sua apresentação, sendo que este prazo poderá ser prorrogado caso a comissão técnica julgue necessário; 47.3.É de responsabilidade da licitante levar o(s) equipamento(s) necessário(s) para realizar a sua apresentação; 47.4.A apresentação técnica (prova de conceito) é etapa da apresentação da proposta do procedimento licitatório necessária à aceitação da proposta melhor classificada; 47.5.Após terminada a apresentação dos sistemas, a comissão técnica elaborará Ata/Relatório informando se a licitante está apta ou não para fornecer a solução, sendo que este irá compor o processo licitatório; 47.6.Em caso da licitante vencedora ser considerada inapta pela comissão técnica será convocado a segunda colocada para realizar apresentação da sua solução, e assim sucessivamente; 48 DA CONDIÇÃO DE EXECUÇÃO 48.1 Para a operacionalização dos sistemas objeto deste certame e prestação de serviços técnicos de implantação, suporte técnico e manutenção deverão ser considerados as seguintes definições: 48.2 O serviço de implantação será composto pelos serviços de conversão, homologação, instalação e treinamento; 48.3 Fica estabelecido que melhorias da aplicação serão executadas posteriormente na fase de implantação seguindo cronograma estabelecidos e ajustados entre as partes; 49 DA IMPLANTAÇÃO 49.1 Todos os Sistemas licitados nesse certame deverão estar implantados no prazo máximo de 90 (noventa) dias contados da assinatura do contrato. Entende-se como implantados o conjunto de serviços necessários para instalar, migrar os dados ligados, colocar em funcionamento e deixar em condições de uso para os usuários executarem suas tarefas. O período de conversão, migração será executado pela Contratada e a análise e validação dos dados convertidos e migrados de bases de dados em operação será executada pela Contratante com apoio tecnológico da Contratada, nos 30 (trinta) primeiros dias do processo de implantação e em conformidade com o cronograma acordado entre as partes; 49.2.Os dados existentes tanto no sistema E-SUS quanto no sistema utilizado atualmente pela Secretaria Municipal de Saúde, deverão ser migrados para o sistema a ser contratado. Todo o processo de migração fica sob inteira responsabilidade da CONTRATADA; 49.3.Cronograma de implantação: a execução dos serviços deverá ser feita conforme Cronograma abaixo, iniciando em até cinco dias após a assinatura do contrato;

CRONOGRAMA
SERVIÇO(S)/ETAPA	DIAS CORRIDOS
Da instalação, configuração e parametrização dos Módulos do Sistema Informatizado de Gestão da Saúde Pública Configuração de Parâmetros e setup da aplicação (criação de Perfis e Usuários do Sistema Informatizado de Gestão da Saúde Pública	15
Importação de dados dos sistemas em uso (conversão) - Implantação/Carga dos dados Básicos (tabelas, questionários, documentos) do Sistema Informatizado de Gestão da Saúde Pública	45
Treinamento dos profissionais que executarão o Sistema Informatizado de Gestão da Saúde Pública nas Unidades de Saúde	30

50 TREINAMENTO 50.1. A licitante vencedora do certame deverá realizar treinamento, durante o processo de implantação, para os servidores municipais da Secretaria Municipal de Saúde que utilizarão os sistemas. Nesta etapa, a contratante deverá designar os profissionais responsáveis para os treinamentos futuros; 50.2. Para a execução do treinamento deverão ser consideradas as seguintes especificações: 50.3. A contratada deverá disponibilizar instrutor (es) qualificado (s) e com sólida experiência no assunto para ministrar os treinamentos. Devendo substituí-los a critério da Secretaria Municipal de Saúde, caso os mesmos não cumpram satisfatoriamente os objetivos do treinamento; 50.4. As capacitações ocorrerão por módulos (Sistemas) limitados a quantidade de 10 (dez) servidores por treinamento; 50.5.Todos os treinamentos deverão ser presenciais; 50.6 .A capacitação deverá ser realizada com carga horária mínima de 08 (oito) horas e máxima de 40 (quarenta) horas de acordo com a complexidade de cada sistema, cujo cronograma deverá ser acordado e homologado pela contratante; 50.7. As instalações físicas, equipamentos e materiais necessários para a aplicação dos treinamentos serão providenciados e disponibilizados pela contratante; 50.8. Deverá ser fornecido Certificado de Participação aos servidores que tiverem comparecido a mais de 85% (oitenta e cinco por cento) das atividades de cada curso; 50.9. Diariamente a Contratada deverá disponibilizar lista de presença dos servidores que compareceram as atividades e estas deverão ser assinadas pelos presentes; 50.10. Ao final de cada treinamento a Contratada deverá realizar processo de Avaliação sobre o treinamento realizado, objetivando a avaliação no mínimo do conteúdo treinado e do instrutor; 50.11. Os custos inerentes às despesas de hospedagem, alimentação e transporte serão arcados pela contratada; 50.12.Transcorrida a Etapa de implantação e expedido o Termo de Treinamento, caso a contratante requeira a realização de novos treinamentos in loco os mesmos serão acordados entre as partes; 51 SUPORTE TÉCNICO 51.1. A CONTRATADA deverá manter um consultor ou equipe local durante a implantação e treinamento do sistema, posterior a este período o suporte será oferecido por demanda; 51.2. A empresa contratada deverá disponibilizar uma central de atendimento, disponibilizado no mínimo 8 (oito) horas por dia de segunda a sexta-feira (dias úteis), sem limites de chamados mensais; 51.3. Novas implementações e melhorias, aprovadas entre as partes, deverão ser liberadas conforme cronograma de versões da Contratada planejados para o Sistema; 52 DAS OBRIGAÇÕES DA CONTRATANTE 52.1.Fiscalizar a execução do objeto, nos termos do disposto no artigo 67 da Lei 8.666/93, através do Fiscal do Contrato; 52.2.Solicitar, quando julgar conveniente, informações relativas ao fornecimento do objeto, sem que tal atividade implique em qualquer responsabilidade da Fiscalização sobre a ação da contratada; 52.3. Atuar da forma ampla e completa no acompanhamento do fornecimento do objeto, acompanhamento este que não eximirá a contratada das responsabilidades previstas quanto aos danos que forem causados à contratante ou a terceiros; 52.4.Proporcionar todas as facilidades para que a contratada possa desempenhar a plena execução do contrato; 52.5.Comunicar à empresa contratada todas e quaisquer ocorrências em desacordo com o cumprimento das obrigações pactuadas, qualquer anormalidade na entrega do objeto, podendo sustar ou recusar o recebimento, caso não esteja de acordo com as especificações e condições estabelecidas; 53 DAS OBRIGAÇÕES DA CONTRATADA 53.1 Executar os serviços conforme especificações do Termo de Referência dos seus anexos, do contrato decorrente e de sua proposta, com a alocação dos empregados necessários ao perfeito cumprimento das cláusulas contratuais; 53.2 Manter atualizada a versão do Sistema, esclarecer as suas alterações, mantendo-o em pleno funcionamento, dentro das características da concessão; 53.3.Corrigir eventuais defeitos nos programas em uso; 53.4.Alterar os Sistemas, quando solicitado pelo usuário, para adaptação a normas legais; 53.5.Esclarecer se consultada por via telefônica, correspondência, e-mail e comunicador interno, etc., dúvidas de operação do Sistema, excluindo os problemas relacionados com operação de equipamento ou dos utilitários quando a CONTRATANTE deverá recorrer a empresa vendedora; 53.5.Manter, durante a execução do contrato, em compatibilidade com as obrigações a serem assumidas, todas as condições de habilitação e qualificação exigidas neste Termo; 53.6.Solicitar por escrito a prorrogação do prazo de implantação, se ocorrer atrasos por motivos atribuíveis ao Município, pelo mesmo período do atraso, acompanhada da devida justificativa e sujeita à aprovação do mesmo; 53.7.Efetuar, quando necessário, alterações, melhorias e atualizações nos sistemas locados, que impliquem mudanças nos arquivos, novas funções/rotinas e relatórios, de forma a atender a legislação ou aperfeiçoamento gerencial; 53.8.Manter absoluto sigilo sobre quaisquer documentos, informações ou dados que tiver conhecimento ou acesso, em decorrência da execução dos serviços e não prestar declarações ou informações sem prévia autorização por escrito da CONTRATANTE a respeito do presente contrato e dos serviços a ele inerentes; 53.9. Responsabilizar-se pela orientação e treinamento aos usuários do Sistema; 53.10.Responsabilizar-se pela substituição dos Sistemas por versões mais atualizadas em função do aprimoramento técnico e/ou operacional; 53.11.Disponibilizar BANCO DE DADOS para conversão sempre que solicitado, sem ônus para a CONTRATANTE, principalmente no termino do contrato; 53.12. Apresentar Declaração que possui quadro técnico suficiente, tanto presencial como remoto, para atender toda a demanda do município, nos prazos estabelecidos no edital; 53.13. Apresentar pelo menos um atestado de capacidade técnica em referência ao objeto licitado; 54 DA DOTAÇÃO Projeto/Atividade: 2038 – MANUTENÇÃO DAS ATIVIDADES SERVIÇOS HOSPITALAR E AMBULATORIAL

Fonte de Recursos: 1.5.00.100.200 – Identificação das Despesas com Ações e Serviço Públicos de

Saude

225.10.302.0017.2038.3.3.90.39.00.00.00-OUTROS SERVIÇOS DE TERCEIROS

Projeto/Atividade:2040-GESTÃO SUS

Fonte de Recursos: 1.5.00.100.200 – Identificação das Despesas com Ações e Serviço Públicos de

Saude

235.10.30.0017.2040.3.3.90.39.00.00.00-OUTROS SERVIÇOS DE TERCEIROS

55 DA FISCALIZAÇÃO

Durante o período de Vigência da Ata de Registro de Preços os fornecimentos dos produtos serão fiscalização e

acompanhamento da execução do Contrato será realizada pela Fiscal de Contrato, Sra. SUELLEN FAUST MATTEI DORIGON, Portaria 021/2022, observando-se as disposições contidas no artigo 67 e parágrafos da Lei nº 8.666/93.

56 DO PAGAMENTO a. O pagamento será efetuado em até 30 (trinta) dias úteis, contados da data de apresentação da Nota Fiscal/Fatura discriminativa, devidamente atestada pelo fiscal do contrato, onde a CONTRATANTE poderá deduzir do montante a pagar os valores correspondentes às multas ou indenizações devidas pela CONTRATADA, desde que não haja nenhum fato impeditivo; 57 DAS SANÇÕES ADMINISTRATIVAS 55.1.Pela inexecução total ou parcial do objeto licitado, a CONTRATANTE poderá, garantida a defesa prévia, aplicar à CONTRATADA as seguintes sanções: I – Multa administrativa no percentual de 01% (um por cento) por dia de atraso, a partir do primeiro dia útil subsequente à data limite fixada na programação da prestação do serviço, incidindo sobre o valor da obrigação inadimplida, até o percentual máximo de 20% (vinte por cento) calculado sobre o valor do contrato, o que não impede aplicação das demais sanções. II – Pela inexecução parcial ou total deste contrato, poderão ser aplicadas as seguintes sanções: e) Advertência; f) Multa indenizatória fixada em 20% (vinte por cento) do valor total do contrato, no caso de inexecução total, e de 1% (um por cento) até o limite de 20% (vinte por cento) sobre o valor da obrigação inadimplida, no caso de inexecução parcial do contrato; g) Suspensão temporária de participação em licitação e impedimento de contratar com a Prefeitura Municipal de Juruena-MT, nos termos da legislação vigente; h) Declaração de inidoneidade para licitar e contratar com a Administração Pública enquanto perdurarem os motivos determinantes da punição ou até que seja promovida a reabilitação, na forma da lei, perante a própria autoridade que aplicou a penalidade; 55.2. Se o CONTRATADO não proceder ao recolhimento da multa no prazo de 05 (cinco) dias úteis contados da intimação por parte da Prefeitura Municipal, o respectivo valor será descontado dos créditos que o CONTRATADO possuir com esta Prefeitura Municipal e, se estes não forem suficientes, o valor que sobejar será encaminhado para execução pela Procuradoria Jurídica. 55.3. As penalidades acima previstas só poderão ser relevadas nas hipóteses de caso fortuito ou força maior, devidamente justificado e comprovado, a juízo do Prefeito Municipal. 55.4 Do ato que aplicar a penalidade caberá recurso, no prazo de 05(cinco) dias úteis, a contar da ciência da informação, podendo a Administração reconsiderar sua decisão ou nesse prazo encaminhá-lo devidamente informados para a apreciação e decisão superior, dentro do mesmo prazo. 58 DA VIGÊNCIA

A vigência do objeto deste Termo de Referência será de 12 (doze) meses contados da data da assinatura do contrato, podendo ser prorrogado nos ternos do Artigo 57 da Le nº 8.666/93 e alterações posteriores.

A prorrogação de que trata o item anterior, somente poderá ser feita através de Termo Aditivo.

Patrícia de Oliveira Moreira

Secretária Municipal de Saúde

Portaria 081/2021

- (...),

Ficando o restante do conteúdo do documento Editalíssimo passando sua data para o dia 24/02/2022.

Juruena-MT, 11 de fevereiro de 2022.

ROBSON GOMES DIAS Pregoeiro Oficial

Jornal Oficial Eletrônico dos Municípios - Mato Grosso

Associação Mato-Grossense
dos Municípios - AMM

Todas edições

Todas publicações

Covid-19

TERMO DE RETIFICAÇÃO PREGÃO PRESENCIAL Nº 08/2022

Sugestões de pesquisa