EDITAL DE PREGÃO PRESENCIAL Nº 81/2011

EDITAL DE PREGÃO PRESENCIAL Nº 81/2011

Município de Tapejara/RS

Secretaria Municipal da Administração Edital de Pregão nº 81/2021

Tipo de julgamento: MENOR PREÇO POR ITEM Data: 29/12/2021 Horário: 09 horas

Contratação de empresa especializada no fornecimento de Licenças de uso de software para a área de gestão da Saúde, com execução de serviços técnicos em manutenção, atualização, suporte e assessoria operacional, customização, implantação e migração de base de dados, incluindo a capacitação dos usuários em todos os módulos do sistema e com o acompanhamento presencial na fase inicial de utilização e acompanhamento presencial e/ou on-line pós implantação.

O PREFEITO MUNICIPAL DE TAPEJARA, no uso de suas atribuições, torna público, para o conhecimento dos interessados, que em 29 de dezembro de 2021, às 09:00, na sala de licitações, localizada na Prefeitura se reunirão o pregoeiro e a equipe de apoio, designados pela Portaria nº 1394/2021, com a finalidade de receber propostas e documentos de habilitação, objetivando a contratação de empresa para a prestação de serviços descritos no item 1, processando-se essa licitação nos termos da Lei Federal n.º 10.520, de 17-07-2002, e do Decreto Municipal nº 3.183, de 06 de novembro de 2006, com aplicação subsidiária da Lei Federal nº 8.666-93.

1 - DO OBJETO:

Constitui objeto da presente licitação: Contratação de empresa especializada no fornecimento de Licenças de uso de software para a área de gestão da Saúde, com exe- cução de serviços técnicos em manutenção, atualização, suporte e assessoria operacional,

customização, implantação e migração de base de dados, incluindo a capacitação dos usuá- rios em todos os módulos do sistema e com o acompanhamento presencial na fase inicial de utilização.

Item	Descrição	Un	Qtd	Vlr Uni	Total
1	DESLOCAMENTO DIÁRIO PARA ATENDIMENTO E TREINAMENTO NA SEDE DO MUNICÍPIO	HRS	100	150,00	15.000,00
2	HORA DE TREINAMENTO	HRS	100	150,00	15.000,00
3	HORA PARA CUSTOMIZAÇÃO SISTEMA PARA ADEQUAR AS NECESSIDADES ESPECIFICAS DO MUNICÍPIO.	HRS	100	150,00	15.000,00
4	HOSPEDAGEM DO BANCO DE DADOS EM NUVE	MES	48	1.500,00	72.000,00
5	LICENÇA DE SOFTWARE LICENÇA DE USO, IMPLANTAÇÃO DO SISTEMA DE GESTÃO DA SAÚDE; CONVERSÃO DOS DADOS EXISTENTES; E CONFIGURAÇÃO, PARAMETRIZAÇÃO E CUSTOMIZAÇÃO PARA ADAPTAR O SISTEMA AS NECESSIDADES DA SECRETARIA.	UN	1	9.000,00	9.000,00
6	LOCAÇÃO MENSAL POR MOBILIDADE LOCAÇÃO MENSAL POR MOBILIDADE PARA AGENTES DE SAÚDE E ENDEMIAS.	MES	48	150,00	7.200,00
7	LOCAÇÃO/MANUNTENÇÃO MENSAL DO SOFTWARE DE GESTÃO	MES	48	600,00	28.800,00
8	VISITA TÉCNICA MENSAL	MES	48	400,00	19.200,00
	TOTAL DO LOTE	R$

Obs: Deverá estar incluída na proposta a LICENÇA DE BI (BUSINESS INTELLIGENCE), sistema para apuração de indicadores para metas do Ministério da Saúde e para geração de relatórios de gestão.

2 - DA APRESENTAÇÃO DOS ENVELOPES:

2.1. Para participação no certame, a licitante, além de atender ao disposto no item 7 deste edital, deverá apresentar a sua proposta de preço e documentos de habilitação em Envelopes distintos, lacrados, não transparentes, identificados, respectivamente, como de n° 1 e n° 2, para o que se sugere a seguinte inscrição:

AO MUNICÍPIO DE TAPEJARA EDITAL DE PREGÃO N.º 81/2021 ENVELOPE N.º 01 - PROPOSTA PROPONENTE (NOME COMPLETO) XXXX E E-MAIL

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

AO MUNICÍPIO DE TAPEJARA EDITAL DE PREGÃO N.º 81/2021 ENVELOPE N.º 02 - DOCUMENTAÇÃO

PROPONENTE (NOME COMPLETO DA EMPRESA) XXXX E E-MAIL

3 - DA REPRESENTAÇÃO E DO CREDENCIAMENTO:

3.1. A licitante deverá apresentar-se para credenciamento junto ao pregoeiro, diretamente, por meio de seu representante legal, ou através de procurador regularmente constituído, que devidamente identificado e credenciado, será o único admitido a intervir no procedimento licitatório, no interesse da representada.

3.1.1. A identificação será realizada, exclusivamente, através da apresentação de documento de identidade.

3.2. A documentação referente ao credenciamento de que trata o item 3.1 deverá ser apresentada fora dos envelopes.

3.3. O credenciamento será efetuado da seguinte forma:

a) se representada diretamente, por meio de dirigente, proprietário, sócio ou assemelhado, deverá apresentar:

a.1) cópia do respectivo Estatuto ou Contrato Social em vigor, devidamente registrado;

a.2) documento de eleição de seus administradores, em se tratando de sociedade comercial ou de sociedade por ações;

a.3) inscrição do ato constitutivo, acompanhado de prova de diretoria em exercício, no caso de sociedade civil;

a.4) decreto de autorização, no qual estejam expressos seus poderes para exercer direitos e assumir obrigações em decorrência de tal investidura e para prática de todos os demais atos inerentes ao certame, em se tratando de empresa ou sociedade estrangeira em funcionamento no País;

a.5) registro comercial, se empresa individual.

b) se representada por procurador, deverá apresentar:

b.1) instrumento público ou particular de procuração, este com a firma do outorgante reconhecida, em que conste os requisitos mínimos previstos no art. 654, § 1º, do Código Civil, em especial o nome da empresa outorgante e de todas as pessoas com poderes para

a outorga de procuração, o nome do outorgado e a indicação de amplos poderes para dar lance(s) em licitação pública; ou

b.2) carta de credenciamento outorgado pelos representantes legais da licitante, comprovando a existência dos necessários poderes para formulação de propostas e para prática de todos os demais atos inerentes ao certame.

Observação 1: Em ambos os casos (b.1 e b.2), o instrumento de mandato deverá estar acompanhado do ato de investidura do outorgante como representante legal da empresa. Observação 2: Caso o contrato social ou o estatuto determinem que mais de uma pessoa deva assinar a carta de credenciamento para o representante da empresa, a falta de qualquer uma invalida o documento para os fins deste procedimento licitatório.

3.4. Para exercer os direitos de ofertar lances e/ou manifestar intenção de recorrer, é obrigatória a licitante fazer-se representar em todas as sessões públicas referentes à licitação.

3.5. A empresa que pretender se utilizar dos benefícios previstos nos art. 42 à 45 da Lei Complementar 123, de 14 de dezembro de 2006, disciplinados nos itens 6.15 à 6.18 e 7.3, deste edital, deverão apresentar, fora dos envelopes, no momento do credenciamento, declaração, firmada por xxxxxxxx, de que se enquadra como microempresa ou empresa de pequeno porte.

3.5.1. As cooperativas que tenham auferido, no ano calendário anterior, receita bruta até o limite de 2.400.000,00 (dois milhões e quatrocentos mil reais), gozarão dos benefícios previstos nos art. 42 à 45 da Lei Complementar 123, de 14 de dezembro de 2006, disciplinados nos itens 6.15 à 6.18 e 7.3, deste edital, conforme o disposto no art. 34, da Lei 11.488, de 15 de junho de 2007, desde que também apresentem, fora dos envelopes, no momento do credenciamento, declaração, firmada por xxxxxxxx, de que se enquadram no limite de receita referido acima.

4 - DO CREDENCIAMENTO, RECEBIMENTO E ABERTURA DOS ENVELOPES:

4.1. No dia, hora e local, mencionados no preâmbulo deste edital, na presença das licitantes e demais pessoas presentes à sessão pública do pregão, o pregoeiro, inicialmente, receberá os envelopes nºs 01 - PROPOSTA e 02 - DOCUMENTAÇÃO.

4.2. Uma vez encerrado o prazo para a entrega dos envelopes acima referidos, não será aceita a participação de nenhuma licitante retardatária.

4.3. O pregoeiro realizará o credenciamento das interessadas, as quais deverão:

a) comprovar, por meio de instrumento próprio, poderes para formulação de ofertas e lances verbais, bem como para a prática dos demais atos do certame;

b) apresentar, ainda, declaração de que cumprem plenamente os requisitos de habilitação.

5 - PROPOSTA DE PREÇO:

5.1. A proposta, cujo prazo de validade é fixado pela Administração em 60 dias, deverá ser apresentada em folhas sequencialmente numeradas e rubricadas, sendo a última datada e assinada pelo representante legal da empresa, ser redigida em linguagem clara, sem rasuras, ressalvas ou entrelinhas, e deverá conter:

a) razão social da empresa;

b) validade da proposta;

Observação: Serão considerados, para fins de julgamento, os valores constantes no preço até no máximo, duas casas decimais após a vírgula, sendo desprezadas as demais, se houver, também em eventual contratação.

6 - DO JULGAMENTO DAS PROPOSTAS:

6.1. Verificada a conformidade com os requisitos estabelecidos neste edital, a autora da oferta de valor mais baixo e as das ofertas com preços até 10% (dez por cento) superiores àquela poderão fazer novos lances, verbais e sucessivos, na forma dos itens subseqüentes, até a proclamação da vencedora.

6.2. Não havendo, pelo menos, 03 (três) ofertas nas condições definidas no subitem anterior, poderão as autoras das melhores propostas, até o máximo de 03 (três), oferecer novos lances, verbais e sucessivos, quaisquer que sejam os preços oferecidos em suas propostas escritas.

6.3. No curso da sessão, as autoras das propostas que atenderem aos requisitos dos itens anteriores serão convidadas, individualmente, a apresentarem novos lances, verbais e sucessivos, em valores distintos e decrescentes, a partir do autor da proposta classificada em segundo lugar, até a proclamação da vencedora.

6.4. Caso duas ou mais propostas iniciais apresentem preços iguais, será realizado sorteio para determinação da ordem de oferta dos lances.

6.5. A oferta dos lances deverá ser efetuada no momento em que for conferida a palavra à licitante, obedecida a ordem prevista nos itens 6.3 e 6.4.

6.5.1. Dada a palavra a licitante, esta disporá de 10 s (dez segundos) para apresentar nova proposta.

6.6. É vedada a oferta de lance com vista ao empate.

6.6.1. A diferença entre cada lance não poderá ser inferior a R$ 10,00 (dez reais).

6.7. Não poderá haver desistência dos lances já ofertados, sujeitando-se a proponente desistente às penalidades constantes no item 12 deste edital.

6.8. O desinteresse em apresentar lance verbal, quando convocada pelo pregoeiro, implicará na exclusão da licitante da etapa competitiva e, conseqüentemente, no impedimento de apresentar novos lances, sendo mantido o último preço apresentado pela mesma, que será considerado para efeito de ordenação das propostas.

6.9. Caso não seja ofertado nenhum lance verbal, será verificada a conformidade entre a proposta escrita de menor preço unitário e o valor estimado para a contratação, podendo o pregoeiro negociar diretamente com a proponente para que seja obtido preço melhor.

6.10. O encerramento da etapa competitiva dar-se-á quando, convocadas pelo pregoeiro, as licitantes manifestarem seu desinteresse em apresentar novos lances.

6.11. Encerrada a etapa competitiva e ordenadas as ofertas, de acordo com o menor preço apresentado, o pregoeiro verificará a aceitabilidade da proposta de valor mais baixo, comparando-a com os valores consignados em planilha de custos, decidindo motivadamente a respeito.

6.12. A classificação dar-se-á pela ordem crescente de preços propostos e aceitáveis. Será declarada vencedora a licitante que ofertar o menor preço unitário, desde que a proposta tenha sido apresentada de acordo com as especificações deste edital e seja compatível com o preço de mercado.

6.13. Serão desclassificadas as propostas que:

a) não atenderem às exigências contidas no objeto desta licitação;

b) contiverem opções de preços alternativos;

c) forem omissas em pontos essenciais, de modo a ensejar dúvidas;

d) se oponham a qualquer dispositivo legal vigente, bem como as que não atenderem aos requisitos do item 5;

e) apresentarem preços manifestamente inexeqüíveis.

Observação: Quaisquer inserções na proposta que visem modificar, extinguir ou criar direitos, sem previsão no edital, serão tidas como inexistentes, aproveitando-se a proposta no que não for conflitante com o instrumento convocatório.

6.14. Não serão consideradas, para julgamento das propostas, vantagens não previstas no edital.

6.15. Encerrada a sessão de lances, será verificada a ocorrência do empate ficto, previsto no art. 44, §2º, da Lei Complementar 123/06, sendo assegurada, como critério do desempate, preferência de contratação para as microempresas, as empresas de pequeno porte e as cooperativas que atenderem ao item 3.5.1, deste edital.

6.15.1. Entende-se como empate ficto aquelas situações em que as propostas apresentadas pela microempresa e pela empresa de pequeno porte, bem como pela cooperativa, sejam superiores em até 5% (cinco por cento) à proposta de menor valor.

6.16. Ocorrendo o empate, na forma do item anterior, proceder-se-á da seguinte forma:

a) A microempresa, a empresa de pequeno porte ou a cooperativa detentora da proposta de menor valor será convocada para apresentar, no prazo de 5 (cinco) minutos, nova proposta, inferior àquela considerada, até então, de menor preço, situação em que será declarada vencedora do certame.

b) Se a microempresa, a empresa de pequeno porte ou a cooperativa, convocada na forma da alínea anterior, não apresentar nova proposta, inferior à de menor preço, será facultada, pela ordem de classificação, às demais microempresas, empresas de pequeno porte ou cooperativas remanescentes, que se enquadrarem na hipótese do item 6.15.1 deste edital, a apresentação de nova proposta, no prazo previsto na alínea a deste item.

6.17. Se nenhuma microempresa, empresa de pequeno porte ou cooperativa, satisfizer as exigências do item 6.16 deste edital, será declarado vencedor do certame o licitante detentor da proposta originariamente de menor valor.

6.18. O disposto nos itens 6.15 a 6.17, deste edital, não se aplica às hipóteses em que a proposta de menor valor inicial tiver sido apresentada por microempresa, empresa de pequeno porte ou cooperativa.

6.19. Da sessão pública do pregão será lavrada ata circunstanciada, contendo, sem prejuízo de outros, o registro das licitantes credenciadas, as propostas escritas e verbais apresentadas, na ordem de classificação, a análise da documentação exigida para habilitação e os recursos interpostos.

6.20. A sessão pública não será suspensa, salvo motivo excepcional, devendo todas e quaisquer informações acerca do objeto serem esclarecidas previamente junto ao setor de Licitações deste Município.

6.21. Caso haja necessidade de adiamento da sessão pública, será marcada nova data para continuação dos trabalhos, devendo ficar intimadas, no mesmo ato, as licitantes presentes.

7 - DA HABILITAÇÃO:

7.1. Para fins de habilitação neste pregão, o licitante deverá apresentar, dentro do ENVELOPE Nº 02, os seguintes documentos:

7.1.1 declaração que atende ao disposto no artigo 7.°, inciso XXXIII, da Constituição Federal, conforme o modelo do Decreto Federal n.° 4.358-02;

7.1.2 - HABILITAÇÃO JURÍDICA:

a) registro comercial no caso de empresa individual;

b) prova de inscrição no Cadastro Nacional de Pessoa Jurídica (CNPJ/MF);

c) ato constitutivo, estatuto ou contrato social em vigor, devidamente registrado, em se tratando de sociedades comerciais, e, no caso de sociedade por ações, acompanhado de documentos de eleição de seus administradores;

d) decreto de autorização, em se tratando de empresa ou sociedade estrangeira em funcionamento no País, e ato de registro ou autorização para funcionamento expedido pelo órgão

competente, quando a atividade assim o exigir.

7.1.3 - REGULARIDADE FISCAL:

a) prova de inscrição no Cadastro de Contribuintes do Estado ou do Município, se houver, relativo ao domicílio ou sede do licitante, pertinente ao seu ramo de atividades;

b) prova de regularidade com a Fazenda Federal (Certidão Negativa de Débito de Tributos e Contribuições Federais expedida pela Secretaria da Receita Federal e Certidão Negativa de Débitos quanto à dívida ativa da União, expedida pela Procuradoria Geral da Fazenda Nacional), Estadual e Municipal, sendo a última do domicílio ou sede da licitante;

c) prova de regularidade relativa à Seguridade Social (CND/INSS), demonstrando situação regular no cumprimento dos encargos sociais instituídos em lei;

d) prova de regularidade (CRF) junto ao Fundo de Garantia por Tempo de Serviço (FGTS);

e) Certidão Negativa de Débitos Trabalhistas.

f) certidão negativa de falência ou concordata expedida pelo distribuidor da sede da pessoa jurídica, em prazo não superior a 30 (trinta) dias da data designada para a apresentação do documento;

g) Declaração de visita técnica comprovando que a LICITANTE, por intermédio de seu responsável técnico, visitou o local do respectivo serviço, reconheceu as características dos sistemas e da tecnologia existente, ambiente, instalações e tomou conhecimento de todas as informações e das condições locais para o cumprimento das obrigações do objeto da presente licitação, inclusive sobre as peculiaridades técnicas dos serviços a serem realizados, cientificando-se de todos os aspectos que possam influir direta ou indiretamente na execução do objeto licitado (art. 30, inciso III da Lei 8.666/93);

h) A visita técnica para as empresas participantes é obrigatória até 02 (dois) dias úteis a abertura do processo licitatório, onde as mesmas receberão um atestado para comprovação desta visita e de conhecimento de toda a infraestrutura e instalações onde deverão ser utilizados o sistema de gestão. Este documento deverá fazer parte do envelope de documentos para a respectiva comprovação. A visita deverá ser marcada com a servidora Xxxxxxxxxx Xxxxxxxxx, CPF: 000.000.000-00 pelo fone (00) 0000-0000, nos seguintes horários: 7:30 horas as 11:30hrs e das 13:00hrs as 17:00hrs;

i) As LICITANTES deverão comprovar aptidão para desempenho de atividade pertinente e compatível em características, quantidades e prazos com o objeto da licitação (art. 30, II, da Lei 8.666/93);

j) A apresentação de atestados de capacidade técnica ou qualquer outra documentação incompatível com o objeto do certame será interpretada como interferência negativa no normal andamento de qualquer ato da licitação e será´ passível de aplicação das sanções previstas no art. 81 da Lei n.o 8.666/1993. (item 9.4, TC-006.580/2009- 0, Acórdão TCU n° 1.724/2010 Plenário);

k) Para comprovação de que a empresa LICITANTE possui capacitação e experiência na execução de serviços correlatos aos do objeto deste Edital, a empresa deverá, nos termos do Art. 30, parágrafo 1°, da Lei no 8.666/93, juntamente com a documentação de habilitação necessária, apresentar atestado(s) de Capacidade Técnica expedido(s) por pessoa jurídica de direito público ou privado. No atestado deve constar os módulos contratados que devem ser igual ao do objeto, em características, quantidades e prazo.

l) Relação da equipe técnica responsável pelos serviços de instalação, conversão, implantação, treinamento e suporte técnico.

m) Declaração de que os aplicativos ofertados são plenamente compatíveis com o sistema operacional, ambiente de rede e estrutura de hardware atualmente existente no município.

7.2. Para as empresas cadastradas no Município, a documentação poderá ser substituída pelo seu Certificado de Registro de Fornecedor, desde que seu objetivo social comporte o objeto licitado e o registro cadastral esteja no prazo de validade.

Observação: Caso algum dos documentos fiscais obrigatórios, exigidos para cadastro esteja com o prazo de validade expirado, a licitante deverá regularizá-lo no órgão emitente do cadastro ou anexá-lo, como complemento ao certificado apresentado, sob pena de inabilitação.

7.3 A microempresa e a empresa de pequeno porte, bem como a cooperativa que atender ao item 3.5.1, que possuir restrição em qualquer dos documentos de regularidade fiscal, previstos no item 7.1.3, deste edital, terá sua habilitação condicionada à apresentação de nova documentação, que comprove a sua regularidade em dois dias úteis, a da sessão em que foi declarada como vencedora do certame.

7.3.1 O prazo de que trata o item anterior poderá ser prorrogado uma única vez, por igual período, a critério da Administração, desde que seja requerido pelo interessado, de forma motivada e durante o transcurso do respectivo prazo.

7.3.2 Ocorrendo a situação prevista no item 7.3, a sessão do pregão será suspensa, podendo o pregoeiro fixar, desde logo, a data em que se dará continuidade ao certame, ficando os licitantes já intimados a comparecer ao ato público, a fim de acompanhar o julgamento da habilitação.

7.3.3 O benefício de que trata o item 7.3 não eximirá a microempresa, a empresa de pequeno porte e a cooperativa, da apresentação de todos os documentos, ainda que apresentem alguma restrição.

7.3.4 A não regularização da documentação, no prazo fixado no item 7.3, implicará na inabilitação do licitante e a adoção do procedimento previsto no item 8.2, sem prejuízo das penalidades previstas no item 12.1, alíena a, deste edital.

7.4. O envelope de documentação que não for aberto ficará em poder do pregoeiro pelo prazo de 30 (trinta) dias, a contar da homologação da licitação, devendo a licitante retirá-lo, após aquele período, no prazo de 5 (cinco) dias, sob pena de inutilização do envelope.

8 - DA ADJUDICAÇÃO:

8.1. Constatado o atendimento das exigências fixadas no edital, a licitante que ofertar o menor preço será declarada vencedora, sendo-lhe adjudicado o objeto do certame.

8.2. Em caso de desatendimento às exigências habilitatórias, o pregoeiro inabilitará a licitante e examinará as ofertas subseqüentes e qualificação das licitantes, na ordem de classificação e, assim, sucessivamente, até a apuração de uma que atenda ao edital, sendo a respectiva licitante declarada vencedora, ocasião em que o pregoeiro poderá negociar diretamente com a proponente para que seja obtido preço melhor.

8.3. Encerrado o julgamento das propostas e da habilitação, o pregoeiro proclamará a vencedora e, a seguir, proporcionará às licitantes a oportunidade para manifestarem a intenção de interpor recurso, esclarecendo que a falta dessa manifestação expressa, imediata e motivada, importará na decadência do direito de recorrer por parte da licitante.

9 - DOS RECURSOS ADMINISTRATIVOS:

9.1. Tendo a licitante manifestado motivadamente, na sessão pública do pregão, a intenção de recorrer, esta terá o prazo de 03 (três) dias corridos para apresentação das razões de recurso.

9.2. Constará na ata da sessão a síntese das razões de recurso apresentadas, bem como o registro de que todas as demais licitantes ficaram intimadas para, querendo, manifestarem- se sobre as razões do recurso no prazo de 03 (três) dias corridos, após o término do prazo da recorrente, proporcionando-se, a todas, vista imediata do processo.

9.3. A manifestação expressa da intenção de interpor recurso e da motivação, na sessão pública do pregão, são pressupostos de admissibilidade dos recursos.

9.4. O recurso será dirigido à autoridade superior, por intermédio daquela que praticou o ato recorrido, a qual poderá, no prazo de 5 (cinco) dias úteis, reconsiderar sua decisão ou fazê- lo subir, acompanhado de suas razões, devendo, neste caso, a decisão ser proferida dentro do prazo de 5 (cinco) dias úteis, contado da subida do recurso, sob pena de responsabilidade daquele que houver dado causa à demora.

10 - DOS PRAZOS DA GARANTIA:

10.1 Esgotados todos os prazos recursais, a Administração, no prazo de 5 (cinco) dias, con- vocará a vencedora para assinar o contrato, sob pena de decair do direito à contratação, sem prejuízo das sanções previstas neste edital.

10.2 O prazo de que trata o item anterior poderá ser prorrogado, uma vez e pelo mesmo período, desde que seja requerido de forma motivada e durante o transcurso do respectivo prazo.

10.3 O prazo de vigência do contrato será de 12 meses, a contar de sua assinatura, podendo ser prorrogado, a critério da Administração e com a anuência da contratada, nos termos do art. 57, inciso II da Lei nº 8.666-93.

11. DO ATESTADO DE TESTE DE CONCEITO DE PRODUTO

11.1. A Administração Pública Municipal, através da Comissão Especial de Avaliação, realizará com a empresa licitante vencedora, antes da assinatura do contrato, um teste de conformidade do sistema, com o objetivo de comprovar se o sistema realmente dispõe dos requisitos mínimos obrigatórios, presentes no Termo de Referência.

11.2. A Comissão Especial de Avaliação, se reserva o direito de avaliar, todos os requisitos obrigatórios e aqueles que julgar necessário, dentre todos apresentados no Termo de Referência. Ressalta-se ainda que, aqueles requisitos obrigatórios que dependem da integração com sistemas em uso na Secretaria Municipal da Saúde de Tapejara, não serão avaliados pela Comissão, pois o funcionamento dos mesmos depende de algumas customizações das soluções por parte da licitante durante a fase de implantação. Estas customizações decorrentes da integração com sistemas já existentes, poderão ser computadas naquelas mencionadas no Anexo I.

11.3. A responsabilidade de providenciar todos os equipamentos necessários para a realização do teste de conformidade, inclusive conexão a internet (tecnologia 3G ou outros) é da empresa licitante, ficando a Prefeitura Municipal de Tapejara responsável somente pela disponibilização do espaço para realização do mesmo.

11.4. Caso a solução da licitante não seja aprovada no teste de conformidade, a mesma será desclassificada, sendo convocadas para a realização deste teste as demais licitantes, por ordem de classificação. A licitante cuja solução for reprovada no teste de conformidade, ou seja, não atender a qualquer dos requisitos mínimos obrigatórios, poderá ser julgada inidônea para contratar com a Administração Pública. Constatado o atendimento pleno às exigências fixadas neste edital e consequente aprovação no teste de conformidade, a licitante será declarada vencedora, sendo-lhe adjudicado o presente objeto, para o qual apresentou proposta.

12. OBRIGAÇÕES E RESPONSABILIDADES DA CONTRATADA

12.1. A licitante contratada ficará obrigada a fornecer o objeto nas condições, no preço e no prazo estipulados na proposta.

12.2 Se constatada, por ocasião do recebimento ou durante a utilização qualquer irregularidade do produto licitado, a licitante deverá substituir o objeto recusado dentro dos prazos estabelecidos no Edital.

12.3. A Contratada se compromete a executar os serviços, quando for o caso, em perfeito acordo com as especificações do Edital e seus anexos, assim como as da proposta, do Contrato e das normas técnicas durante todo o período de vigência do contrato.

12.4. A Contratada não poderá alegar incapacidade de execução de parte ou todo do objeto contratado, bem como impossibilidade de ajuste e/ou adequação de performance técnica, quaisquer que sejam os empecilhos, estando obrigada à execução dos ajustes e adequações necessárias para dirimi-los, sem ônus para a CONTRATANTE.

12.5. Cabe à licitante contratada, além das obrigações constantes neste Edital e nas Especificações Técnicas estabelecidas em cláusulas próprias deste instrumento, e ainda daquelas estabelecidas em lei, em especial as definidas nos diplomas federais e estaduais sobre licitações:

12.5.1 cumprir as posturas do Município e as disposições legais Estaduais e Federais que interfiram na execução dos serviços;

12.5.2 responsabilizar-se pelos danos causados diretamente à CONTRATANTE ou a terceiros decorrentes de sua culpa ou dolo na execução do Contrato, não excluindo ou reduzindo essa responsabilidade a fiscalização da PREFEITURA em seu acompanhamento;

12.5.3 manter, durante toda a execução do contrato, todas as condições de habilitação e a qualificação exigida na licitação indicada no preâmbulo deste termo, apresentando à PREFEITURA, inclusive, a licença de funcionamento da empresa correspondente a cada exercício;

12.5.4. responsabilizar-se por eventuais paralisações dos serviços por parte de seus empregados, substituindo-os sem repasse de qualquer ônus à PREFEITURA, para que não haja interrupção dos serviços prestados;

12.5.5 manter seu pessoal uniformizado, identificando-os por meio de crachás, fornecendo-lhes os Equipamentos de Proteção Individual (EPI), quando for o caso;

12.5.6 dar ciência imediata e por escrito à CONTRATANTE sobre qualquer anormalidade que verificar na execução dos serviços;

12.5.7 prestar esclarecimentos que lhe forem solicitados e atender prontamente às reclamações sobre seus serviços;

12.5.8 manter equipamentos e utensílios necessários à execução dos serviços em perfeitas condições de uso, em quantidade necessária à boa execução dos trabalhos.

12.5.9 responsabilizar-se, às suas expensas, pelos serviços de manutenção corretiva e preventiva dos serviços pertinentes, bem como pelos danos causados às instalações físicas da PREFEITURA, mesmo que efetuados por empresa terceirizada;

12.5.10 exercer controle sobre a qualidade e pontualidade dos serviços prestados;

12.5.11. re-executar serviços que justificadamente forem solicitados pela CONTRATANTE quando estiverem em desacordo com as técnicas e procedimentos aplicáveis aos mesmos;

12.5.12 assumir total responsabilidade pelos equipamentos, móveis e utensílios colocados à sua disposição para a execução do serviço, garantindo-lhes a integridade e ressarcindo a PREFEITURA das despesas com a manutenção corretiva decorrente de sua má utilização;

12.5.13. Executar o treinamento dos profissionais de informática em quantidade de horas e em números de servidores, segundo especificação contida no Anexo I neste Edital.

12.5.14. Antes de efetivar a instalação, o proponente deve entregar um cronograma contendo descrição da instalação e da configuração que deve ser submetido à aprovação da equipe técnica da PREFEITURA;

12.5.15. A contratada deverá disponibilizar equipe com experiência em serviços de migração de dados a fim de executar as rotinas de migração. A contratada também deverá disponibilizar ferramentas tecnológicas adequadas para a correta e eficiente migração dos dados e oferecer serviços de consultoria técnica para resolução de problemas e conflitos inerentes ao serviço de migração de dados, tais como: consolidações e inconsistências.

12.5.15.1. Disponibilização do Banco de Dados e auxilio na migração do banco de dados, caso ocorra recisão contratual futura.

13. OBRIGAÇÕES DA CONTRANTE

13.1. Para o fornecimento dos produtos e para a execução dos serviços objeto do presente contrato, a Prefeitura de Tapejara obriga-se a:

13.1.1. Exercer, através da Secretaria Municipal da Saúde, a fiscalização do contrato, dos produtos e serviços;

13.1.2. Facilitar, por todos os meios, o exercício das funções da PREFEITURA, dando-lhe acesso às suas instalações, promovendo o bom entendimento entre seus servidores e os empregados da Prefeitura e cumprindo suas obrigações estabelecidas neste Contrato;

13.1.3. Prestar aos empregados da contratada informações e esclarecimentos que eventualmente venham a ser solicitados e que digam respeito à natureza dos serviços contratados;

13.1.4. Destinar local adequado, dotado da infraestrutura necessária bem com a devida segurança que os serviços demandam.

13.1.5. A contratante deverá disponibilizar equipe técnica com conhecimento da base de dados legada a ser migrada para nova solução, bem como usuários dos sistemas legados para auxiliar em eventualidades, com o objetivo de determinar o que deve ser migrado.

14 - DO PAGAMENTO:

14.1.1. SOFTWARES: A entrega e Instalação das Licenças dos softwares deverão ser pagos em 15 dias, mediante emissão do termo de aceite correspondente.

14.1.2. SERVIÇOS MANUTENÇÃO: A prestação dos Serviços Especializados, Manutenção, Suporte e Treinamento deverão ser pagos em 12 parcelas mensais e iguais mediante aceite correspondente, cujo prazo começará a contar 30 dias após o início da prestação dos serviços.

14.2. A Prefeitura de Tapejara efetuará o pagamento até 5º (quinto) dia útil do mês subsequente após o recebimento e aceite dos produtos/serviços com a respectiva Nota Fiscal/Fatura ou documento legalmente equivalente, observado o cumprimento integral das disposições contidas neste edital.

14.3. A empresa deverá mencionar na respectiva Nota Fiscal/Fatura informações sobre os produtos e serviços prestados, tais como: atividade realizada, local, além de mencionar o número do Contrato, o número da Licitação e o nº do Processo, bem como o relatório dos serviços realizados no período a que o pagamento se referir.

14.4. Os preços são fixos e irreajustáveis, exceto por força de disposição legal, especialmente quando comprovadas as situações descritas no art. 65, I, “b”, II, “d”, da Lei n.º 8.666/93 e com base no limite do IPCA, desde que atendidas as condições preconizadas no Edital.

14.4.1 Em caso de renovação contratual, após 12 (doze) meses da vigência do contrato, os valores poderão reajustados com base na variação do IPCA ocorrida no período, tendo como base inicial o preço consignado na proposta apresentada pela licitante contratada.

14.5. Ocorrendo atraso no pagamento, os valores serão corrigidos monetariamente pelo IPCA do período, ou outro índice que vier a substituí-lo, e a Administração compensará a contratada com juros de 0,5% ao mês, pro rata.

15 - DAS PENALIDADES:

15.1 Pelo inadimplemento das obrigações, seja na condição de participante do pregão ou de

contratante, as licitantes, conforme a infração, estarão sujeitas às seguintes penalidades:

a) deixar de apresentar a documentação exigida no certame: suspensão do direito de licitar e contratar com a Administração pelo prazo de 2 anos e multa de 10% sobre o valor estimado da contratação;

b) manter comportamento inadequado durante o pregão: afastamento do certame e suspen-são do direito de licitar e contratar com a Administração pelo prazo de 2 anos;

c) deixar de manter a proposta (recusa injustificada para contratar): suspensão do direito de licitar e contratar com a Administração pelo prazo de 5 anos e multa de 10% sobre o valor estimado da contratação;

d) executar o contrato com irregularidades, passíveis de correção durante a execução e sem prejuízo ao resultado: advertência;

e) executar o contrato com atraso injustificado, até o limite de 3 (três)dias, após os quais será considerado como inexecução contratual: multa diária de 0,5% sobre o valor atualizado do contrato;

f) inexecução parcial do contrato: suspensão do direito de licitar e contratar com a Administração pelo prazo de 3 anos e multa de 8% sobre o valor correspondente ao montante não adimplido do contrato;

g) inexecução total do contrato: suspensão do direito de licitar e contratar com a Administração pelo prazo de 5 anos e multa de 10% sobre o valor atualizado do contrato;

h) causar prejuízo material resultante diretamente de execução contratual: declaração de inidoneidade cumulada com a suspensão do direito de licitar e contratar com a Administração Pública pelo prazo de 5 anos e multa de 10 % sobre o valor atualizado do contrato.

15.2 As penalidades serão registradas no cadastro da contratada, quando for o caso.

15.3 Nenhum pagamento será efetuado pela Administração enquanto pendente de liquidação qualquer obrigação financeira que for imposta ao fornecedor em virtude de penalidade ou inadimplência contratual.

16 - DAS DISPOSIÇÕES GERAIS:

16.1. Quaisquer informações ou dúvidas de ordem técnica, bem como aquelas decorrentes de interpretação do edital, deverão ser solicitadas por escrito, ao Município de Tapejara, setor de Licitações, sito na Rua do Comércio, nº 1468, ou pelo telefone 00-0000-0000, no horário compreendido entre as 8:00 e 17:00 horas, preferencialmente, com antecedência mínima de 03 (três) dias da data marcada para recebimento dos envelopes.

16.2. Os questionamentos recebidos e as respectivas respostas com relação ao presente Pregão encontrar-se-ão à disposição de todos os interessados no Município, setor de Licita- ções.

16.3 Ocorrendo decretação de feriado ou qualquer fato superveniente que impeça a realiza- ção de ato do certame na data marcada, a data constante deste edital será transferida, auto- maticamente, para o primeiro dia útil ou de expediente normal subseqüente ao ora fixado.

16.4. Para agilização dos trabalhos, solicita-se que as licitantes façam constar na documen- tação o seu endereço, e-mail e os números de fax e telefone.

16.5. Todos os documentos exigidos no presente instrumento convocatório poderão ser apresentados em original ou por qualquer processo de cópia autenticada por tabelião ou, ainda, publicação em órgão da imprensa oficial. Os documentos extraídos de sistemas informatizados (internet) ficarão sujeitos à verificação da autenticidade de seus dados pela Administração.

16.6. A proponente que vier a ser contratada ficará obrigada a aceitar, nas mesmas condições contratuais, os acréscimos ou supressões que se fizerem necessários, por conveniência da Administração, dentro do limite permitido pelo artigo 65, § 1º, da Lei nº 8.666-93, sobre o valor inicial contratado.

16.7. Após a apresentação da proposta, não caberá desistência, salvo por motivo justo decorrente de fato superveniente e aceito pelo pregoeiro.

16.8. A Administração poderá revogar a licitação por razões de interesse público, devendo anulá-la por ilegalidade, em despacho fundamentado, sem a obrigação de indenizar (art. 49 da Lei Federal nº 8.666-93).

16.9. Fica eleito o Foro da Comarca de Tapejara para dirimir quaisquer litígios oriundos da licitação e do contrato dela decorrente, com expressa renúncia a outro qualquer, por mais privilegiado que seja.

Tapejara, 15 de dezembro de 2021.

XXXXXX XXXXX

Prefeito Municipal de Tapejara – RS

Este edital se encontra examinado e aprovado por esta Assessoria Jurídica.

Em   - -    .

XXXXXXXX XXXXXXX

OAB/RS 111697 - Procurador Jurídico

ANEXO I - TERMO DE REFERÊNCIA

1. Objeto da Licitação:

Contratação de empresa especializada no fornecimento de Licenças de uso de software para a área de gestão da Saúde, com execução de serviços técnicos em manutenção, atualização, suporte e assessoria operacional, customização, implantação e migração de base de dados, incluindo a capacitação dos usuários em todos os módulos do sistema e com o acompanhamento presencial na fase inicial de utilização e acompanhamento presencial e/ou on-line pós implantação, descritos nos anexos “I” e “II deste edital, por um período de 12 meses, a contar do início da vigência do contrato, nos termos deste edital, de forma a atender completamente as funcionalidades descritas no mesmo, devendo estar incluída a LICENÇA DE BI (BUSINESS INTELLIGENCE), sistema para apuração de indicadores para metas do Ministério da Saúde e para geração de relatórios de gestão.

1.1. Benefícios esperados:

1.1.1. Aumento da eficácia administrativa e operacional

1.1.2. Redução de prazos e riscos operacionais;

1.1.3. Melhoria da qualidade da informação;

1.1.4. Criação de condições para a utilização de ferramentas de apoio a tomada de decisão;

1.1.5. Aprimoramento dos mecanismos de gestão e controle interno da saúde pública municipal;

1.1.6. Melhoria no atendimento aos indivíduos.

1.2. Áreas envolvidas:

1.2.1. Secretaria Municipal de Saúde;

1.2.2. Todas Unidades de Saúde do município;

1.3. Justificativa

A Secretaria Municipal da saúde de Tapejara atualmente tem em sua rede, 07 unida- des de atendimento. O Sistema de Gestão de Saúde visa:

1.3.1. Prover o Município de uma solução tecnologicamente atual e homogênea, integrando as informações de saúde;

1.3.2. Organizar o acervo disponível de informações existentes, numa base de dados integrada e estruturada;

1.3.3. Criar ponto de fusão digital baseado nas informações do Sistema para ampla socialização do conhecimento, como também realizar ações de monitoramento e avaliação da gestão;

1.3.4. Melhoria da execução de atividades e gerenciamento de informações da área da Saúde do Município de Tapejara;

1.3.5. Promover a economia de recursos públicos e a redução de retrabalho, contribuindo para o aumento da produtividade dos servidores envolvidos;

1.3.6. Consolidar relatórios de dados entre todas as Unidades de Saúde do Município possibilitando um melhor planejamento das ações;

1.3.7. Implantação de sala de situação gerencial para melhoria da agilidade decisória e tomada de decisão dos gestores da saúde, no elenco das suas prioridades;

1.3.8. Desenvolver a prática da análise, avaliando o custo-benefício dos investimentos da saúde;

1.3.9. Agilizar o acesso às informações pelos órgãos de controle e pela sociedade em geral;

1.3.10. Permitir a mobilidade e rastreabilidade dos dados coletados.

1.4. Visita Técnica

1.4.1. A implantação do Sistema de Informação para Gestão da Saúde, deve abranger todas as especificações técnicas/funcionais e itens obrigatórios, constantes no Anexo I deste edital.

1.4.2. A visita técnica para as empresas participantes é obrigatória e deve ser realizada em até 03 (três) dias uteis anteriores ao início do processo licitatório. Na ocasião da visita as proponentes receberão um atestado para comprovação desta, e declararão conhecimento de toda a infraestrutura e instalações onde deverá ser utilizado o sistema de gestão. A visita deverá ser marcada com a servidora Xxxxxxxxxx Xxxxxxxxx, CPF: 000.000.000-00 pelo fone

(00) 0000-0000, nos seguintes horários: 7:30 horas as 11:30hrs e das 13:00hrs as 17:00hrs.

2. Dos serviços de migração de dados e customização

2.1. O serviço de customização relacionado na definição do objeto refere-se aquelas cus- tomizações de requisitos que não se encontram descritas neste edital e que não se encontrarem implementadas na solução contratada, ressaltando-se que não sejam decorrentes de imposições legais ou atualizações. Para tanto, estima-se uma cota de horas para customização. Os serviços que corresponderem a este item do edital, somente

deverão ser executados mediante prévia autorização da equipe técnica da contratante, que será responsável pela gestão destas horas.

2.2. O serviço de migração de dados será executado de forma compartilhada entre as partes (contratada e contratante). A contratante deverá disponibilizar equipe técnica com conhecimento da base de dados legada a ser migrada para nova solução, bem como usuários dos sistemas legados para auxiliar em eventualidades, com o objetivo de determinar o que deve ser migrado. A contratada deverá disponibilizar equipe com experiência em serviços de migração de dados a fim de executar as rotinas de migração. A contratada também deverá disponibilizar ferramentas tecnológicas adequadas para a correta e eficiente migração dos dados e oferecer serviços de consultoria técnica para resolução de problemas e conflitos inerentes ao serviço de migração de dados, tais como: consolidações e inconsistências. As atividades de consultoria e execução para migração de dados por parte da contratada deverão ser executadas e computadas dentro das horas de cota estabelecida anteriormente.

2.3. Os serviços de customização, quando autorizados, deverão ser realizados pela contratada conforme calendário de entregas acordado entre as partes.

3. Da Licença de uso do Sistema de Informação para Gestão da Saúde:

3.1. A licença de uso da solução, concedida pelo tempo de validade do contrato, é a cessão do direito de uso não exclusivo do sistema de informação para gestão da saúde, para a secretaria da saúde do município.

3.2. Não haverá restrições quanto ao número de usuários e/ou estações de trabalho que utilizarão o sistema, não sendo permitido a cobrança de custo adicional de licenciamento, caso o número de usuários, acessos simultâneos e/ou estações de trabalho seja alterado para mais ou para menos, esta variação estará automaticamente licenciada e não irá gerar custo adicional.

4. Da garantia

4.1. Entende-se por garantia do sistema a manutenção do software, corrigindo eventuais falhas do sistema, originados por erro de codificação e/ou análise dos programas que fazem parte integrante do sistema de informação para gestão da saúde.

5. Dos Serviços de Manutenção e Suporte Técnico

5.1. O serviço de ‘manutenção corretiva', adaptativa e evolutiva relacionado na definição do objeto é obrigação da empresa fornecedora do software visando manter o sistema de informação para gestão da saúde em perfeito funcionamento.

5.2. Entende-se por ‘manutenção corretiva' aquela que for necessária para o reparo de imperfeições ou falhas no sistema aplicativo que o impeça de funcionar adequadamente.

5.3. Entende-se por ‘manutenção adaptativa', aquela que for necessária para adequar o sistema aplicativo a um novo quadro normativo originado por alteração na legislação municipal, estadual ou federal.

5.4. Entende-se por ‘manutenção evolutiva' aquelas manutenções que visarem a implementação de novas funcionalidades à solução, a fim atender necessidades novas percebidas, desde que não estejam compreendidas como manutenção adaptativa. As quais poderão ser orçadas de acordo com o item 2.1.

5.5. O serviço de suporte técnico e manutenção será prestado durante toda a fase de implantação da solução e/ou vigência do contrato.

5.6. A empresa deverá disponibilizar dois (02) técnicos residentes no Município por um período de 12 meses para auxiliar no processo de implantação e treinamento.

5.7. A manutenção e suporte técnico será pago mensalmente durante a vigência do con- trato. De acordo com o cronograma.

5.8. O atendimento de um chamado decorrente da manutenção e suporte técnico, deverá ser iniciado em um prazo máximo de 04 (quatro) horas a contar do chamado realizado. Entende-se por chamado realizado, a abertura do mesmo por qualquer meio de co- municação estabelecido entre as partes (telefonia, sistema eletrônico de help-desk, entre outros).

5.9. Deverá ser disponibilizado, pela empresa equipe para suporte, correção de erros e atendimento de dúvidas solicitadas tanto pelo usuário final quanto pela equipe técnica do município, seja à distância (atendimento remoto) ou presencial (atendimento in loco), de acordo com a necessidade da mesma, durante todo o período de contrato, 07 (sete) dias por semana (de Segunda-feira à Domingo) durante as 24 horas do dia.

6. Das horas/aula (Capacitação/Treinamento)

6.1.1. Durante a implantação deverão ser desenvolvidas as atividades de consulto- ria nas dependências da Secretaria Municipal de Saúde, tais como:

6.1.2. Avaliação do pessoal envolvido;

6.1.3. Definição dos objetivos a serem alcançados;

6.1.4. Sugestões para melhoria dos pontos críticos e adaptações necessárias para atender às necessidades do município.

6.2. O município irá disponibilizar uma sala (espaço físico) com infraestrutura necessária para que a empresa contratada possa realizar a capacitação dos usuários do sistema.

6.3. Neste local serão ministrados os treinamentos durante o período de implantação do sistema.

6.4. O licitante vencedor deverá disponibilizar equipe de treinamento, na secretaria da sa- úde parte de gestão e administração, em todas as unidades de saúde, agentes de saúde, enfim a todos os usuários envolvidos no processo de informatização da secre- taria da saúde.

6.5. A empresa deverá apresentar cronograma de treinamento para compor o plano de treinamento acima solicitado.

7. Da Comissão Especial De Avaliação:

7.1. A Diretoria de Informática juntamente com a Secretaria de Saúde, designarão em co- mum acordo, um grupo de servidores que acompanharão a execução dos serviços, prestando todas as informações necessárias e mediando os contatos com os usuá- rios, visando assim garantir as características técnicas exigidas para o perfeito funci- onamento do produto instalado.

7.2. A Comissão Especial de Avaliação se reunirá periodicamente com o responsável téc- nico da contratada para planejamento, elaboração de cronograma de ações, definição de prioridades e controle de mudanças.

8. Da Gestão do Projeto

8.1. A gestão do projeto deverá ser executada por profissionais da contratada, devida- mente capacitados, que exercerão a função de gerente de projeto, responsáveis por todo o acompanhamento da implantação bem como da execução dos serviços de acordo com as especificações do cronograma definido.

9. Dos Termos de Aceite Parciais e Finais

9.1. Caberá a comissão especial de avaliação a emissão dos termos de aceites parciais e termo de aceite final, de acordo com as determinações contidas neste edital.

9.2. Após a emissão do último termo de aceite parcial, referente a última fase da implan- tação, conforme cronograma de execução, mediante funcionamento da solução con- tratada e a devida fiscalização realizada pela comissão especial de avaliação, emitir- se-á o termo de aceite final, atestando a entrega completa de todos os serviços do presente objeto nos termos deste edital.

10. Do Teste de Conformidade

10.1. A administração pública municipal, através da comissão especial de avaliação, realizará com a empresa licitante vencedora, antes da assinatura do contrato, um teste de conformidade do sistema, com o objetivo de comprovar se o sistema real- mente dispõe dos requisitos mínimos obrigatórios, presentes no termo de referência.

10.2. A comissão especial de avaliação, se reserva o direito de avaliar, todos os re- quisitos obrigatórios ou somente aqueles que julgar necessário, dentre todos apre- sentados no termo de referência. Ressalta-se ainda que, aqueles requisitos obrigató- rios que dependem da integração com sistemas em uso na prefeitura não serão ava- liados pela comissão, pois o funcionamento dos mesmos depende de algumas cus- tomizações da solução por parte da licitante durante a fase de implantação.

10.3. A responsabilidade de providenciar todos os equipamentos necessários para a realização do teste de conformidade, inclusive conexão com a internet (tecnologia 3G ou outros) é da empresa licitante, ficando a contratante responsável somente pela disponibilização do espaço para realização do mesmo.

10.4. A licitante que apresentar a proposta comercial vencedora será convocada para o teste de conformidade da solução objeto deste edital, a fim de comprovar o atendi- mento dos requisitos mínimos obrigatórios. Caso a solução da licitante não seja apro- vada no teste de conformidade, a mesma será desclassificada, sendo convocadas para a realização deste teste as demais licitantes, por ordem de classificação. A lici- tante cuja solução for reprovada no teste de conformidade, ou seja, não atender a qualquer dos requisitos mínimos obrigatórios, poderá ser julgada inidônea para con- tratar com a administração pública. Constatado o atendimento pleno às exigências fixadas neste edital e consequente aprovação no teste de conformidade, a licitante será declarada vencedora, sendo-lhe adjudicado o presente objeto, para o qual apre- sentou proposta.

ANEXO II DESCRIÇÃO TÉCNICA

1. Ambiente Tecnológico

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 admi- tidas licenças parciais ou que apresentem qualquer tipo de restrição de funcionalidade em relação a versão mais completa do produto licenciado.

1.1. Ambiente tecnológico:

1.1.1. Os servidores a serem utilizados: A aplicação deverá rodar em MS Windows 2003 ou superior ou Linux, tanto para o servidor da aplicação como no servidor de banco de dados.

1.1.1.1. Nas estações, o sistema deverá funcionar através da utilização de navegadores de internet compatíveis com Mozilla Firefox 6.0 ou superior ou ainda Google Chrome versão 23 ou superior.

1.1.1.2 - A aplicação não deve possuir nenhum tipo de bloqueio quanto ao número de usuários que poderão acessá-la simultaneamente ou ainda unidades de saúde a serem gerenciadas.

1.1.1.3- O banco de dados a ser utilizado: Pela solução deve ser de código aberto sem custo adicional de licenças. Caso o banco de dados não seja de código aberto, o fornecedor da solução deverá arcar com os custos relativos a licenças para utilização durante a vigência do contrato. Não serão aceitas versões de bancos de dados que possuam qualquer tipo de limitação de uso em virtude da versão utilizada. Caso o banco de dados a ser utilizado seja proprietário, suas licenças de uso deverão ser adquiridas em nome da contratante e entregues junto com a aplicação para as pessoas responsáveis pelo seu ambiente tecnológico.

1.1.1.4 - O banco de dados a ser utilizado deverá obrigatoriamente possuir recursos de arquivamento de log, permitindo a recuperação automática após queda (crash) do sistema.

1.1.1.5 - Deve possuir mecanismo de controle de concorrência de multi-versão (MVCC) onde processos de leitura não bloqueiem processos de escrita e vice-versa reduzindo de forma drástica a contenção entre transações concorrentes e paralisação parcial ou completa (deadlock).

1.1.1.6 - O banco de dados adotado deve possui mecanismo para backup's online permitindo sua restauração point-in-time, que refletirá exatamente o mesmo ambiente do momento em que o mesmo foi realizado.

1.1.1.7. - O SGDBOR (Sistema de Gerenciamento de Banco de Dados e Objetos Relacionais) deve suportar índices B-Tree, rTree e hash permitindo a melhor escolha para cada situação.

1.1.1.8. - Deve ser baseado em arquitetura TOAST (The Oversized-Attribute Storage Technique) onde os limites para armazenamento de tipos de dados serão impostos pela configuração de hardware e não pelo SGDB (Sistema de Gerenciamento de Banco de Dados).

1.1.1.9 - O sistema gerenciador de banco de dados padrão SQL deve permitir a criação, pelo operador, de novos: Tipos de dados, Funções, Operadores, Funções de Agregação, métodos de índice. Além de permitir a utilização de mais de uma linguagem procedural.

1.2. Tecnologia Requisitada

1.2.1 O sistema deverá estar adequado para funcionar sobre a rede local da contratante, sua intranet ou ainda através da internet (web) utilizando servidores com sistemas operacionais Windows e Linux. As aplicações desktop, que não serão utilizadas através de browsers, deve permitir sua utilização através de servidores de terminais (Windows Terminal Services, NoMachine, Go Global ou outros). Todas as licenças necessárias para utilização das aplicações via servidores de terminal devem ter seu custo absorvido pelo fornecedor da solução, suas licenças deverão ser adquiridas em nome da contratante e entregues aos responsáveis pelo seu ambiente tecnológico.

1.2.1.1 - Os sistemas oferecidos deverão obrigatoriamente ser multiusuários e multitarefas, permitindo o controle de tarefas concorrentes com acesso simultâneo ao banco de dados sem perda da integridade referencial.

1.2.1.2 - O cadastro dos operadores dos sistemas deverá possuir mecanismo de controle de acessos e de nível de acesso (Inclusão, Exclusão, Consulta e alteração) através da utilização de senhas pessoais.

1.2.1.3 - A solução deverá possuir mecanismo de log de atividades (auditoria) que possibilitem rastrear todas as operações realizadas para cada operador do sistema através da utilização de filtros que facilitem sua utilização, mostrando obrigatoriamente quem fez, quando fez e o que fez. A solução deve possuir parametrização para o local de armazenamento dos logs de utilização do sistema (auditoria) permitindo que o mesmo seja armazenado em outro banco de dados se a contratante assim desejar, permitindo aumentar a eficiência do processo de leitura e escrita no banco de dados onde serão armazenados os dados a serem gerenciados pela aplicação ofertada.

1.2.1.4 - A aplicação ofertada deverá permitir que cada operador abra várias janelas do browser, possibilitando desta forma maior agilidade na sua operação, sem que haja nenhuma perda de integridade das informações a serem armazenadas.

2. Requisitos mínimos obrigatórios da solução ofertada

2.1. O sistema de gestão de saúde ofertado deve ser desenvolvido para rodar sobre ser- vidores 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.

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

2.3. O sistema deve possuir mecanismo para integrar os seguintes sistemas disponibiliza- dos pelo Ministério da Saúde: E-SUS, CNS, BPA Magnético, CNES, SIA, SISCTA, SIPNI, HÓRUS, RAAS, SIGTAP.

2.4. A empresa contratada, compromete-se, quando da atualização de versões, a dispo- nibilizar 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 atual- mente ainda não possuem layout aberto tais como: SISREG e outros que forem exi- gidos, considerando ainda sistemas posteriores a assinatura do contrato com layout aberto, sem qualquer ônus ao município.

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

2.6. 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.

2.7. Comunicação entre o servidor e servidor utilizando conexão criptografada (SSL/HTTPS).

2.8. Permitir configurar o acesso individual de usuários em uma ou várias unidades de saúde.

2.9. Deverá disponibilizar ajuda on-line em todos os módulos do sistema.

2.10. Sistema deve agrupar os usuários por função para controle das permissões.

2.11. 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.

2.12. 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 con- sulta, inclusão, alteração e exclusão de qualquer informação, inclusive aquelas rela- tivas a administração da solução, de qualquer usuário, indistintamente, inclusive ad- ministradores, com exceção das informações relativas ao prontuário conforme deter- minado pelas regras da SBIS e CFM para homologação de sistemas de prontuário eletrônico. O log registrado deve permitir a identificação completa do dado que foi acessado/atualizado.

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

2.14. 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 Lan- guage) e em formato PDF (Portable Document Format), permitindo a disponibiliza- ção para usuários finais, bem como impressão dos dados consultados.

2.15. 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/sis- temas.

2.16. 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.

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

2.18. 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 idi- oma português do Brasil.

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

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

2.21. 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;

2.22. 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 confi- guração;

2.23. 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 a certificação do software junto ao SBIS (Sociedade Brasileira de Informática na Saúde) e ao CFM (Conselho Federal de Medicina), NGS 2.

2.24. Cadastros e Funcionalidades Gerais

2.24.1. Garantir que todos os cadastros possam ser alterados e incluídos de acordo com o nível de permissão do usuário.

2.24.2. Possuir registro de Pacientes totalmente compatíveis com Cadastro Nacional de Saúde – Cartão SUS e os dados completos do Cadastro Brasileiro de Ocupa- ções.

2.24.3. Possuir dados completos de municípios com os respectivos códigos do IBGE.

2.24.4. Possuir cadastro de Bairros, Logradouros e Tipos de Logradouros.

2.24.5. Permitir cadastro e consulta de empresas mantenedoras.

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

2.24.7. Possuir cadastro de CEP, contendo dados do CEP Brasil para validação no cadastro e evitar inconsistências no BPA-I.

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

2.24.9. Possuir cadastro de UF, Municípios e Localidades.

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

2.24.11. Possuir cadastro de Segmento, Área e Micro área vinculado ao SIAB.

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

2.24.13. Possuir cadastro de Nacionalidades.

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

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

2.24.16. Cadastro de Pacientes com as características descritas abaixo:

2.24.16.1. Deve possuir cadastro de pacientes compatível com padrão SUS con- tendo 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, Comple- mento, Cep e Unidade de Saúde onde o mesmo foi cadastrado.

2.24.16.2. 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 certi- dão de nascimento, Nome do Cartório, Tipo da Certidão Livro, Folha, Termo, Data de Emissão, Naturalidade, Carteira Profissional série.

2.24.16.3. 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.

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

2.24.16.5. Possuir campos para informar os seguintes dados da empresa onde tra- balha: Nome da Empresa, Número de Registro Funcional, Ocupação e Ho- rário de Trabalho.

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

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

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

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

2.24.16.10. Xxxxxx para informar as pessoas com quem o mesmo divide a resi- dência.

2.24.16.11. Deve possuir locais para informação do seu e-mail, Altura e tipo Sanguíneo sendo que os dois últimos não podem ser exibidos no cadastro.

2.24.16.12. Campo para informar se toma insulina e se possui algum tipo de aler- gia.

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

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

2.24.16.15. Possuir funcionalidade para registro das deficiências do paciente. 2.24.16.16. Possuir dentro do cadastro funcionalidade para emissão da ficha ca- dastral do paciente.

2.24.16.17. Possuir funcionalidade para armazenamento da foto do paciente. 2.24.16.18. Possuir funcionalidade para armazenamento de dados sociodemográ- ficos do paciente conforme ficha de cadastro individual do e-SUS.

2.24.16.19. Possuir cadastro ou funcionalidade para armazenas as informações de saúde do paciente conforme ficha de cadastro individual do e-SUS com restrição de acesso através do papel do usuário.

2.24.16.20. Possuir funcionalidade para indicar informações sobre ‘Morador de Rua' quando aplicado, conforme ficha de cadastro individual do e-SUS. 2.24.16.21. Possuir mecanismo ou funcionalidade que permita listar todos os ho- mônimos já processados.

2.24.16.22. Possuir integração com webservice do CNS, permitindo aos operado- res pesquisar e importar os dados pessoas já cadastradas no Cartão Naci- onal de Saúde.

2.24.17. Possuir mecanismo para desativação de logradouros cadastrados incorreta- mente, migrando todos os pacientes do logradouro incorreto para o logradouro correto.

2.24.18. Possuir mecanismo para desativação de bairros cadastrados incorretamente migrando todos os pacientes cadastrados no bairro incorreto para o bairro cor- reto.

2.24.19. Deve possuir funcionalidade para gerenciamento de emissão de cartões mu- nicipais 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 cance- lamento da solicitação.

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

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

2.24.22. Possuir cadastro de tipos de deficiências.

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

2.24.24. 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 Estabeleci- mento 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, Escola- ridade (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, Xxxxx, Xxxxxx ou igno- rado), 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, Xxxxxxxx ou ignorado), quantas consultas foram na rede pública e quantas na rede privada.

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

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

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

2.24.28. A solução deve possuir mecanismo ou funcionalidade que permita a execução de um gerenciamento de homônimos para o cadastro de pacientes com possibi- lidade de unificação dos cadastros e de todas as operações realizadas para os homônimos, num único cadastro.

2.24.29. Deve possuir mecanismo de criação de regras para validação de cadastros, onde seja possível se configurar quais campos do cadastro de pacientes compõe a regra, permitindo a seleção de um ou mais campos, se a regra é de obrigatori- edade de preenchimento do campo, aviso ao operador sobre possibilidade de duplicidade, bloqueio, no caso de duplicidade e, ainda, as unidades de saúde onde a regra será aplicada.

2.25. Módulo de envio de sms/e-mail, com as funcionalidades:

2.25.1. 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.

2.25.2. 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, agenda- mento de transportes, e outros).

2.25.3. 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, sta- tus do agendamento, período da consulta e texto a ser enviado

2.26. Controle de estoques, com ao menos as seguintes funcionalidades:

2.26.1. Possuir 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.

2.26.2. Deve possuir cadastro de Motivos de Acertos de Estoque.

2.26.3. Possuir cadastro de fabricantes.

2.26.4. Possuir cadastro de centros de custo.

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

2.26.6. Possuir cadastro de grupos de materiais com seus respectivos subgrupos.

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

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

2.26.9. Deve permitir que sejam cadastradas as diversas formas nas quais o medica- mento pode estar disponível para consumo.

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

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

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

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

2.26.14. 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.

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

2.26.16. 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.

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

2.26.18. Deve possuir entrada de Materiais e Medicamentos com base na nota de compra, contendo as seguintes informações: Data da Entrada, Ponto de Distri- buiçã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.

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

2.26.20. 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.

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

2.26.22. 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.

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

2.26.24. 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.

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

2.26.26. O sistema deve possuir mecanismo de conferência das transferências reali- zadas, não permitindo que possam ser desviados materiais e medicamentos en- viados para os pontos de distribuição.

2.26.27. 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.

2.26.28. Deve possuir mecanismo para registro das dispensações de materiais e me- dicamentos para os pacientes onde possam ser registradas as seguintes infor- maçõ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.

2.26.29. Durante a saída o sistema deverá controlar e obrigar a alimentação dos cam- pos 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 entorpe- centes a qual o medicamento controlado pertence.

2.26.30. 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.

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

2.26.32. 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.

2.26.33. Deve possuir mecanismo para registro dos medicamentos e materiais procu- rados 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 Quanti- dade Reprimida.

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

2.26.35. 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.

2.26.36. 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.

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

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

2.26.39. 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.

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

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

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

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

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

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

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

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

2.26.48. Possuir mecanismo ou funcionalidade que permita importar o arquivo de pro- dutos do Hórus em formato CSV.

2.26.49. A aplicação deve possuir mecanismo ou funcionalidade para que novos me- dicamentos cadastrados possam ser relacionados a um determinado material do HORUS.

2.26.50. A aplicação deve possuir funcionalidade que permita parametrizar o sistema o sistema de modo a permitir que o operador informe a dosagem exata de insulina no momento da retirada do medicamento.

2.26.51. Deve possuir relatório específico de dispensação e doses globais de insulina.

2.26.52. Deve possuir registro de solicitação de compra.

2.26.53. Deve possuir na compra recurso para atender ao pedido de solicitação de compra.

2.27. Regulação/Agendamento de Consultas, cumprindo os seguintes requisitos mínimos:

2.27.1. Deverá possuir interface 100% WEB e a comunicação que se estabelece entre o navegador e o servidor de aplicação deve ser segura, utilizar HTTPS para cifrar

a comunicação e assinar as requisições de modo a evitar ataques a segurança do servidor de aplicações.

2.27.2. Permitir o cadastramento de feriados e dias facultativos, tendo como funciona- lidade garantir que não sejam feitos agendamentos e consultas neste dia.

2.27.3. Montagens das agendas obedecendo as regras do gestor

• Garantir controle de ocupação, controle de colisão de horários e locais, bem como o controle das cotas por unidade

• Controle por tipo de atendimento: Consultas, Retornos e fila de espera.

2.27.4. Processo de agendamento automatizado da fila de espera com base nas agen- das cadastradas, respeitando as regras de prioridade e a posição do paciente na fila.

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

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

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

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

2.27.9. 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.

2.27.10. 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.

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

2.27.12. 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.

2.27.13. Deve possuir cadastro de motivos de cancelamento de agendamentos.

2.27.14. 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 procedi- mento.

2.27.15. 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 antece- dência.

2.27.16. 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.

2.27.17. Nos cronogramas, deve possuir mecanismo para indicar se poderão ser mar- cados 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.

2.27.18. A aplicação deve possuir mecanismo para gerenciamento de exceções que permita suspender, aumentar ou diminuir, mudar as faixas de horário de atendi mento, 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.

2.27.19. Deve possuir cadastros de causas de atendimento.

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

2.27.21. Deve possuir mecanismo para criação de fichas de anamnese permitindo es pecificar 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 res postas poderão ser dos tipos alfanumérico, data, numérico ou de múltipla esco lha, 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 é obri gatória, a ordem da pergunta na anamnese e um campo para inserção de infor mações de ajuda, para o momento do preenchimento da mesma.

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

2.27.23. 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.

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

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

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

2.27.27. 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 dis poníveis na rede de saúde em percentual e quantidade, que poderão ser distri buídas para todos os locais onde as agendas estarão disponíveis para marcação.

2.27.28. 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 pro cesso da marcação de consulta.

2.27.29. 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.

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

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

2.27.32. 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.

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

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

2.27.35. Durante o processo de agendamento o sistema deve alertar ao operador so bre 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.

2.27.36. 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 pro cesso 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.

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

2.27.38. 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.

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

2.27.40. 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.

2.27.41. Registro de Agendamento manual das solicitações de serviços ofertados pelo município, respeitando as regras de cotas das unidades definidas para as agendas, com impressão de comprovante de agendamento.

2.27.42. Registro manual de agendamento das solicitações para serviços de terceiros com impressão do comprovante de agendamento.

2.27.43. Permitir acesso externo aos municípios que tenham PPI cadastradas. Através deste acesso deve ser possível cadastras pacientes, realizar agendamentos obedecendo as regras de cotas estabelecidas, bem como acompanhar consumo de sua cota.

2.27.44. Garantir cancelamento de agendamentos informando o motivo do cancelamento.

2.27.45. Permitir que no momento do agendamento o paciente possa selecionar a data do atendimento dentre as datas em que o serviço procurado esteja disponível.

2.28. Regulação/ Agendamento de Exames, com os seguintes recursos:

2.28.1. Permitir o cadastro de Preparo de Exames para que seja impresso junto com o comprovante de agendamento, com objetivo de informar ao paciente como se preparar para a realização do exame.

2.28.2. O sistema deve possuir cadastro de convênios.

2.28.3. O sistema deve possuir cadastro de grupos de exames.

2.28.4. 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.

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

2.28.6. 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.

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

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

2.28.9. 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.

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

2.28.11. 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.

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

2.28.13. 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.

2.28.14. 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.

2.28.15. 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.

2.29. Controle de transportes, com as seguintes possibilidades:

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

2.29.2. 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.

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

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

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

2.29.6. 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.

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

2.29.8. Deve possuir cadastro de eventos do veículo.

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

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

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

2.29.12. 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.

2.29.13. 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.

2.29.14. 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.

2.29.15. 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.

2.29.16. 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.

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

2.29.18. 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.

2.29.19. 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, quilome- tragem, 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.

2.29.20. 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.

2.29.21. 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.

2.29.22. 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.

2.29.23. 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.

2.29.24. 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.

2.29.25. 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.

2.29.26. 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.

2.29.27. 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.

2.30. TFD

2.30.1. Deverá possuir interface de operação 100% WEB e a comunicação entre o navegador e o servidor de aplicação deve ser segura, utilizando HTTPS para cifrar

a comunicação e assinar as requisições de modo a evitar ataques a segurança do servidor de aplicações.

2.30.2. 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.

2.30.3. 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.

2.30.4. 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.

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

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

2.30.7. Disponibilizar informações referentes ao andamento dos processos de TFD nas recepções das unidades de saúde.

2.31. Acolhimento

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

2.31.2. 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.

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

2.31.4. 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.

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

2.31.6. 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.

2.31.7. 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.

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

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

2.31.10. 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.

2.31.11. 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.

2.31.12. 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.

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

2.31.14. 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.

2.31.15. 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.

2.31.16. 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.

2.32. Prontuário Eletrônico Multiprofissional

2.32.1. 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 cha-mado na sala de espera e encaminhado para o consultório onde o profissional irá atendê-lo.

2.32.2. Deve permitir que o profissional possa alterar a data e hora do atendimento, mantendo a data e hora do registro das informações;

2.32.3. Deve possuir lista de problemas do paciente

2.32.4. Deve permitir que o problema possa evoluir ou ser mesclado em um novo ou então em outro já existente.

2.32.5. Deve permitir registrar:

• Descrição do problema;

• Codificação (CID-10 ou CIAP-2)

• Tipo (cadastrável com possibilidade de inativação)

• Estado do problema;

• Observações;

• Data de início podendo ser fracionada (Data, Data/Hora, Xxxx;

• Data Final do problema;

2.32.6. Deve possuir gráfico de evolução dos problemas de acordo com seu registro de evolução ou mesclagem.

2.32.7. Deve permitir que as informações coletadas durante o atendimento sejam armazenadas no formato SOAP (Subjetivo, Objetivo, Avaliação e Plano).

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

2.32.9. Deve possuir o registro de anamnese conforme segue:

• Anamnese definida conforme resolução 2056 de 2013 do Conselho Federal de Medicina (CFM).

• Anamnese personalizável que deverá ser exibida conforme o CBO do profissional que está atendendo.

2.32.10. 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 atendi- mentos dos pacientes.

2.32.11. Permitir o preenchimento da ficha de atendimento individual do e-SUS du-rante o atendimento sem precisar sair e entrar em outra tela.

2.32.12. Permitir o preenchimento da ficha de atendimento odontológico do e-SUS du- rante o atendimento sem precisar sair e entrar em outra tela.

2.32.13. Consultar e registrar as informações e ações do paciente quanto a Atenção Domiciliar referente ao Registro de Ações Ambulatoriais de Saúde (RAAS);

2.32.14. Consultar e registrar as informações e ações do paciente quanto a Atenção Psicossocial referente ao Registro de Ações Ambulatoriais de Saúde (RAAS);

2.32.15. Deve possuir campo específico para registro de informações que o profissio-nal julgar importantes, estas informações deverão ser mostradas em destaque durante os atendimentos.

2.32.16. Deverá possuir campo para informar as queixas do paciente.

2.32.17. Deve possuir local para registro das anotações de enfermagem;

2.32.18. Registrar informações referentes a Exames Físicos

2.32.19. Dados gerais do exame contendo:

• Campo texto para descrição do Aspecto;

• Campo texto para descrição da Postura corporal;

• Campo texto para descrição da Cor da pele;

• Todos os campos devem possuir a possibilidade de informar codificação CID-10 ou CIAP-2;

2.32.20. Deve possuir local para registro da Avaliação antropométrica com a possibili- dade de registro de data e hora fracionada (mantendo a data e hora do registro) com no mínimo as seguintes informações:

• Peso e unidade de medida;

• Estatura e unidade de medida;

• Deve calcular o IMC e a Área de Superfície Corporal;

• Quadril e unidade de medida;

• Cintura e unidade de medida;

• Circunferência Braquial e unidade de medida;

• Prega Cutânea e Unidade de Medida;

• Estado Nutricional.

2.32.21. Deve possuir recurso para registrar as Aferições Vitais com a possibilidade de registro de data e hora fracionada (mantendo a data e hora do registro), com no mínimo as seguintes informações:

• Temperatura e unidade de medida;

• Pressão arterial e unidade de medida;

• Frequência respiratória e unidade de medida;

• Frequência cardiaca e unidade de medida;

• Pulsação e unidade de medida;

• Glicemia e unidade de medida, bem como o tipo de coleta;

• Saturação O2 e unidade de medida;

• Saturação CO2 e unidade de medida;

2.32.22. Deve possuir funcionalidade para registro da propedêutica com a possibili- dade de registro de data e hora fracionada (mantendo a data e hora do registro), com campos de texto livre para informar no mínimo os seguintes dados:

• Cabeça e pescoço;

• Boca, nariz, faringe e laringe;

• Olhos;

• Sistema auditivo;

• Sistema nervoso;

• Sistema respiratório;

• Sistema circulatório/vascular;

• Sistema digestório;

• Sistema gênito-urinário;

• Pele, mucosas e anexos;

• Sistema músculo-esquelético;

• Sistema endócrino;

• Saúde mental.

2.32.23. Deve permitir funcionalidade para acompanhamento através de gráficos a evolução do perímetro cefálico e peso corporal de crianças.

2.32.24. A aplicação deve possuir funcionalidade para acompanhamento através de gráfico perímetro cefálico e peso corporal de crianças, para adultos gráfico de

acompanhamento de peso/altura, glicemia/p.a., evolução imc, evolução da fre- quência respiratória/pulsação e para evolução cintura/quadril.

2.32.25. Deve possuir campo para anotação médica específica do profissional, estas anotações não devem aparecer em impressões e são de utilização exclusiva do profissional sobre o paciente em atendimento.

2.32.26. Deve haver possibilidade de compartilhar a anotação registrada com outros profissionais cadastrados no sistema.

2.32.27. Deve haver possibilidade de compartilhar a anotação registrada com outros profissionais utilizando o Cadastro Brasileiro de Ocupações (CBO).

2.32.28. Deve possuir campo de texto livre para informar o plano terapêutico.

2.32.29. Deve possuir campo de texto livre para informar o plano preventivo.

2.32.30. Deve possuir campo de texto livre para informar a Hipótese Diagnóstica.

2.32.31. Deve possuir campo de texto livre para informar o prognóstico.

2.32.32. Deve possuir recurso para informar terminologias CID-10 e CIAP-2.

2.32.33. Quando XXX notificável a solução deve exibir alerta ao profissional e registrar dados para preenchimento da ficha de notificação com opção de escolha para preenchimento imediato ou posterior.

2.32.34. Quando do preenchimento de ficha de notificação, nesta já deve estar infor- mados os dados básicos do paciente e da notificação, cabendo ao profissional informar os dados necessários.

2.32.35. Deve possuir campo de texto livre para informar o serviço.

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

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

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

2.32.39. Deve permitir vincular o resultado digitado do exame com o exame solicitado.

2.32.40. Deve controlar o estado do exame (solicitado, realizado ou avaliado).

2.32.41. Deve possuir funcionalidade para envio de anexos referentes a imagens e laudos de resultados de exames, bem como a possibilidade de recuperação des- tes arquivos para avaliação.

2.32.42. Deve possuir funcionalidade para requisição de exames de mamografia, requisição de exame histopatológico de colo de útero e exame citopatológico de colo de útero com emissão dos formulários padrões da contratante.

2.32.43. Deve possuir recurso fora do prontuário para registro de resultados de exames, permitindo assim que profissionais técnicos não autorizados a visualizar o prontuário do paciente também possam registrar estas informações.

2.32.44. Deve possuir mecanismo para emissão de receitas de medicamentos com funcionalidade para pesquisa em receitas padrões pré-cadastradas, identificando o medicamento, quantidade, via e posologia.

2.32.45. Deve possuir funcionalidade para cadastramento de receitas padrões agilizando o processo de criação do receituário.

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

2.32.47. Deve emitir receita normal e controlada de acordo com os medicamentos inseridos pelo profissional;

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

2.32.49. Recurso para inserir o item selecionado na lista de medicamentos ativos.

2.32.50. Deve permitir assinar digitalmente as receitas geradas em meio eletrônico com a utilização de certificado eletrônico válido ICP-Brasil.

2.32.51. Deve exibir lista de medicamentos dispensados para o paciente nas unidades de saúde de toda a rede municipal integrada ao sistema.

2.32.52. Xxxx possuir recurso para exibir e adicionar medicamentos ativos que o paciente está utilizando.

2.32.53. Deve possui funcionalidade para emissão de atestado contendo número de dias, número de horas, data do atestado, acompanhante (caso atestado de acompanhante), observações e opção para indicação se o CID deverá ou não ser impresso.

2.32.54. Deve permitir assinar digitalmente os atestados gerados em meio eletrônico com a utilização de certificado eletrônico válido ICP-Brasil.

2.32.55. Deve possuir funcionalidade para emissão de atestado de comparecimento contendo número da carteira profissional, UF, série, data, horário inicial, horário final e campo para descrição da finalidade.

2.32.56. Deve permitir assinar digitalmente os atestados de comparecimento gerados em meio eletrônico com a utilização de certificado eletrônico válido ICP-Brasil.

2.32.57. 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.

2.32.58. Deverá permitir através de parametrização a possibilidade de encaminhamento para profissional registrado na rede municipal.

2.32.59. Deve permitir assinar digitalmente os encaminhamentos gerados em meio eletrônico com a utilização de certificado eletrônico válido ICP-Brasil.

2.32.60. No prontuário médico multiprofissional deve haver a possibilidade de criação de prescrição médica para paciente 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.

2.32.61. Deve possuir mecanismo de consulta as imunizações recebidas pelo paciente.

2.32.62. Deve possuir impressão de “Termo de Consentimento Informado” para assinatura do paciente com opção para indicar se paciente assinou durante o atendimento.

2.32.63. Deve possuir mecanismo para geração da produção ambulatorial com verificações para que não sejam gerados procedimentos não compatíveis com as regras do SIA e possibilidade de inclusão de procedimentos extras que venham a ser realizados, registrando o profissional, grupo, procedimento, quantidade, CBO e CID10 do atendimento realizado.

2.32.64. Deve possuir recurso de lista de procedimentos que serão exibidos de acordo com parametrização por CBO com opção de informar os realizados e ação para confirmação da produção destes procedimentos.

2.32.65. Deve permitir o acesso as informações registradas durante o processo de triagem dos pacientes.

2.32.66. Possuir funcionalidade para impressão da ficha clínica do paciente e de seu prontuário do atendimento atual ou completo.

2.32.67. Deve permitir assinar digitalmente a ficha clínica ou prontuário gerados em meio eletrônico com a utilização de certificado eletrônico válido ICP-Brasil.

2.32.68. Deve na impressão do prontuário registrar o objetivo, para quem foi entregue, qual foi o profissional que gerou, data e hora, número do documento da pessoa que retirou, campo para informar se o retirante apresentou documento e observações e emissão de recibo para assinatura.

2.32.69. Deve possuir mecanismo para informar o desfecho do atendimento e alteração da prioridade de atendimento do paciente.

2.32.70. Deve permitir informar data fracionada do desfecho.

2.32.71. Deve permitir escolher uma classificação de especialidade referente ao atendimento caso não tenha sido informado no início.

2.32.72. Deve permitir informar o tipo de desfecho cadastrável.

2.32.73. Xxxxx para informar se foi verificado por médico responsável.

2.32.74. Campo para registrar observações do desfecho do atendimento.

2.32.75. Deve permitir assinar digitalmente em meio eletrônico o atendimento com a utilização de certificado eletrônico válido ICP-Brasil.

2.32.76. Esta assinatura assinará os dados salvos no banco de dados impossibilitando sua alteração, garantindo desta forma a invalidação das informações caso estes dados sejam alterados indevidamente.

2.32.77. Deve possuir ação para validar se o atendimento assinado digitalmente é válido e não sofreu ou adulterações.

2.32.78. O documento somente poderá ser assinado por profissional detentor de certificado digital válido ICP-Brasil.

2.32.79. O certificado a ser utilizado deve estar vinculado em seu cadastro, que no momento do registro será validado através do seu CPF.

2.32.80. O certificado a ser utilizado não pode estar expirado.

2.32.81. O certificado a ser utilizado não pode estar com problemas de integridade.

2.32.82. O certificado a ser utilizado não pode estar revogado.

2.32.83. Deve no momento da assinatura exibir o documento que será assinado para conferência e validação do profissional assinador.

2.32.84. Deve possuir recurso para o profissional efetuar o gerenciamento de atendimentos não assinados e possa assiná-los caso não os tenha conseguido no momento do atendimento.

2.32.85. Deve possuir registro administrativo para gerenciamento de assinaturas não efetuadas.

2.32.86. Xxxx possuir delegação de poder para registro de dados no prontuário.

2.32.87. Quando atendimento assinado por usuário delegado, este deverá ser assinado posteriormente por usuário delegador.

2.33. Prontuário Odontológico

2.33.1. 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.

2.33.2. 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.

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

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

2.33.5. Deve disponibilizar ao odontólogo todas as funcionalidades do prontuário do paciente, conforme descrito no item 2.29.

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

2.33.7. 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.

2.33.8. 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.

2.33.9. 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.

2.33.10. A solução deve possuir mecanismo ou funcionalidade que permita a seleção dos dentes no odontograma pelo sextante, permitindo que sejam lançados um ou mais procedimentos para um ou mais sextantes.

2.33.11. A solução deve permitir a seleção de dentes no odontograma por arcada su- perior ou inferior, permitindo que sejam lançados um ou mais procedimentos para a arcada selecionada.

2.33.12. A solução deve permitir em casos de múltipla seleção no momento de lança- mento da condição inicial ou do procedimento escolher se quantidade será apli- cada para todos os dentes, para cada arcada, para cada sextante, para cada dente ou para cada face conforme o enquadramento da seleção.

2.34. Lista de Espera

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

2.34.2. Deve possuir cadastro de Tipos de Lista de Espera

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

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

2.34.5. 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.

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

2.34.7. 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.

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

2.34.9. 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.

2.34.10. 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.

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

2.34.12. 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.

2.35. Ações Programáticas em Saúde

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

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

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

2.35.4. 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.

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

2.35.6. 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.

2.35.7. 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.

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

2.35.9. 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.

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

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

2.35.12. 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.

2.35.13. 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.

2.35.14. 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.

2.35.15. A montagem do kit deve ser feita através de um processo de linha de monta- gem, visando otimizar o fluxo de trabalho, de forma a atender ao menos as se-guintes 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.

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

2.35.17. 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.

2.36. Medicamento Judicial

2.36.1. 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.

2.36.2. 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.

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

2.36.4. 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.

2.36.5. 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.

2.36.6. 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.

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

2.36.8. 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.

2.36.9. 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.

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

2.37. Benefícios

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

2.37.2. Deve possuir cadastro de locais para encaminhamentos.

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

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

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

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

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

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

2.37.9. 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.

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

2.37.11. 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.

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

2.38. Faturamento da Produção Ambulatorial

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

2.38.2. Importar e manter atualizada automaticamente, sem interação do usuário, a tabela unificada de procedimento SIGTAP, mantendo a série histórica das versões.

2.38.3. 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.

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

2.38.5. 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.

2.38.6. 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.

2.38.7. 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.

2.39. Imunizações/Vacinas

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

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

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

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

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

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

2.39.7. 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.

2.39.8. 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

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

2.39.10. 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

2.39.11. 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.

2.39.12. 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

2.39.13. 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

2.39.14. 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.

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

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

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

2.39.18. 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.

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

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

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

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

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

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

2.40. Saúde da Família

2.40.1. Deve possuir mecanismo para importação dos dados do SIAB do Ministério da Saúde.

2.40.2. Deve possuir mecanismo para exportação dos dados para o SIAB do Ministério da Saúde.

2.40.3. Deve permitir o cadastro das Áreas, Micro Áreas e equipes do PACS/PSF.

2.40.4. Deve possibilitar o cadastramento de Famílias e seus integrantes, obtendo as informações de situação de moradia e saneamento das famílias, condições referidas dos pacientes conforme o sistema SIAB do Ministério da Saúde.

2.40.5. Deve possuir funcionalidade para registro das informações coletadas através da ficha A.

2.40.6. Deve possuir funcionalidade para emissão dos relatórios SSA2 e PMA2 com base em informações coletadas.

2.40.7. Deve possuir mecanismo ou funcionalidade que impeça que mesmos pacientes sejam inseridos em mais de uma família.

2.40.8. Deve possuir indicadores gráficos para o acompanhamento do número de pacientes e número de famílias cadastradas por unidade de saúde, equipe, ano, mês e dia.

2.40.9. Deve permitir acompanhamento do histórico dos dados, permitindo a separação dos dados por segmento, área e equipe.

2.40.10. Deve possuir mecanismo de monitoramento, mostrando todos os indicadores de saúde separados em gestantes, infância e Idade Adulta/Velhice em formato gráfico. Cada indicador deve conter a Situação atual do município, sua média histórica e o parâmetro utilizado para o cálculo da situação atual.

2.40.11. Possuir indicador gráfico de Gestação em Menores de 20 anos de Idade,

contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.12. Indicador de Percentual de Ultrassonografia Obstétrica, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.13. Indicador de Percentual de Cobertura Pré-natal pelo PSF, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas.

2.40.14. Indicador Percentual de Gestantes Acompanhadas, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.15. Indicador Percentual de Gestantes com Pré-Natal no Mês, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.16. Indicador Percentual de Gestantes com Vacina em Dia, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.17. Indicador Percentual de Gestantes com Inicio do Pré-Natal no Primeiro Trimestre, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.18. Indicador da Taxa DHEG grave por 1000 Gestantes, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas.

2.40.19. Indicador da Taxa de Doença Hemolítica Perinatal por 1000, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas.

2.40.20. Indicador Percentual de Recém-Nascidos com Baixo Peso ao Nascer, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.21. Indicador Percentual de Aleitamento Exclusivo, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.22. Indicador da Taxa de Mortalidade Infantil Neonatal por 1000 Nascidos Vivos, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas.

2.40.23. Indicador da Taxa de Óbitos por Violência em População de 10 a 19 anos por 100000, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.24. Indicador da Taxa de Hospitalização por Abuso de Álcool em População com mais de 15 Anos por 100000, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.25. Indicador de Prevalência de Alcoolismo Referido em População com 15 Anos ou mais, contendo média histórica, valor por ano, para o município, seus segmentos, áreas e micro áreas.

2.40.26. Indicador da Taxa de Hospitalizações Psiquiátricas em Pessoas com Mais de

15 Anos por 1000, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.27. Indicador do Percentual de Diabéticos Cadastrados sobre Número de Diabéticos Esperados, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.28. Indicador do Percentual de Diabéticos Acompanhados, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.29. Indicador do Percentual de Hipertensos Cadastrados sobre Numero de Hipertensos Esperados, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.30. Indicador do Percentual de Hipertensos Acompanhados, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.31. Indicador do Percentual de Hospitalizações por Complicações do Diabetes em Cadastrados, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.32. Indicador do Percentual de Hospitalizações por Diabetes por 10000 Pessoas Acima de 40 Anos, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.33. Indicador da Taxa de Acidente Vascular Cardíaco por 1000 Hipertensos, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas.

2.40.34. Indicador da Taxa de Infarto por 1000 Hipertensos, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas.

2.40.35. Indicador da Taxa de Acidente Vascular Cardíaco em População com mais de 40 Anos por 10000, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas.

2.40.36. Indicador da Taxa de Infarto em População com mais de 40 Anos por 10000, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas.

2.40.37. Indicador do Percentual de Cobertura de Citologia Cérvico Vaginal, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas.

2.40.38. Possuir indicador do Percentual de Citologia Oncótica NIC III, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas.

2.40.39. Deve possuir indicador da Taxa de Fratura de Colo de Fêmur por 1000 Pessoas com mais de 50 Anos, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas.

2.40.40. Possuir indicador de Prevalência de Tuberculose, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.41. Possuir indicador de Prevalência de Hanseníase, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.42. Possuir indicador do Percentual de Hanseníase com Grau de Incapacidade II e III, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas.

2.40.43. Possuir indicador da Taxa de Hospitalização por Todas as Causas, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município,

2.40.44. Possuir indicador do Percentual de Crianças Até 1 Ano Desnutridas, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.45. Possuir indicador do Percentual de Crianças de 1 a 2 Anos Desnutridas, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.46. Possuir indicador do Percentual de Crianças Até 1 Ano com Vacina em Dia, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.47. Possuir indicador do Percentual de Crianças de 1 a 2 Anos com Vacina em Dia, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.48. Possuir indicador do Percentual de Crianças Até 1 Ano Pesadas, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o muni-cípio, seus segmentos, áreas e micro áreas.

2.40.49. Possuir indicador do Percentual de Crianças de 1 a 2 Anos Pesadas, con-tendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.50. Possuir indicador do Percentual de cobertura de Puericultura, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas.

2.40.51. Possuir indicador da Taxa de Hospitalização em Menores de 5 Anos por Pneumonia por 1000, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.52. Possuir indicador da Taxa de Hospitalização em Menores de 5 Anos por Desidratação, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.53. Possuir indicador do Percentual de Óbitos em Menores de 1 Ano Sobre o Total de Óbitos, contendo média histórica, valor por ano, e sua classificação se-gundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.54. Possuir indicador do Percentual da Taxa de Mortalidade Infantil Global por 1000 Nascidos Vivos, valor por ano, e sua classificação segundo a OMS, para o município,

2.40.55. Possuir indicador do Percentual da Taxa de Mortalidade Infantil por Diarréia por 1000 Nascidos Vivos, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.56. Possuir indicador da taxa de Mortalidade Infantil por IRA por 1000 Nascidos Vivos, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

2.40.57. Possuir indicador da Taxa de Valvulopatia Reumática por 100000 Pessoas de 5 a 14 Anos, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas.

2.41. Painel Multimídia

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

2.41.2. 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.

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

2.41.4. 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.

2.41.5. 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.

2.42. Business Intelligence

2.42.1. Deve ser baseado em conceito de datawarehouse (armazém de dados).

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

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

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

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

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

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

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

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

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

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

2.42.12. Deve permitir o acompanhamento da execução dos processos de ETL via e- mail.

2.42.13. Deve possuir mecanismo ou funcionalidade para agendamento de execução de relatórios e processos de ETL por mês, data, semana, dia da semana, dia do mês e horário.

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

2.42.15. Deve possuir mecanismo ou funcionalidade de área de trabalho, onde ficarão armazenados os resultados dos relatórios agendados e demais informações so-bre agendamentos dos usuários.

2.42.16. Deve possuir ferramenta específica para realização de análise de desempe-nho dos modelos de informação.

2.42.17. Deve possuir funções para cálculo de variações e tendências.

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

2.42.19. Deve permitir a criação de alertas e indicadores automáticos.

2.42.20. Deve permitir a impressão instantânea em vários formatos, no mínimo em pdf, planilhas Excel, texto, csv files.

2.42.21. Deve permitir a publicação da informação em intranet e internet.

2.42.22. Deve permitir de forma nativa acesso aos SGDB Oracle (a partir do 9i), SQL Server, Firebird (1.5 ou superior) e PostgreSql.

2.42.23. Deve permitir a criação de formulários estruturados para entrada de dados manuais para geração de informações cruzadas.

2.42.24. Possuir função ou mecanismo para geração de Curvas ABC instantâneas

2.42.25. Permitir a execução multiplataforma tanto para aplicação quanto para o banco de dados a ser utilizado como repositório das informações.

2.43. Consulta Geral

2.43.1. Deve permitir a consulta das atividades dos usuários do SUS.

2.43.2. Emitir de forma sintética ou detalhada o histórico dos usuários.

2.44. Portal com informações da Saúde

2.44.1. Deve apresentar informações gerenciais sobre os dados coletados pelo sis-tema, que serão disponibilizados para acesso através do browser.

2.44.2. Sistema deve possuir consultas apresentadas no formato de gráficos.

2.44.3. No sistema deve existir consulta gráfica de dispensação de medicamentos por faixa etária de pacientes

2.44.4. Deve possuir mecanismo de cadastramento de metas flexível, permitindo que a contratante possa criar as suas próprias metas para acompanhamento.

2.44.5. As consultas necessárias para o acompanhamento das metas devem ser apresentadas em gráficos.

2.44.6. Deve possuir consultas de dados estatísticos com os filtros de período, bairro, unidade, sexo, faixa etária e procedimento

2.44.7. Deve disponibilizar os locais de atendimento da SMS que prestam determinado tipo de atendimento e os dias em que estará disponível.

2.44.8. Deve apresentar os procedimentos realizados por faixa-etária e sexo.

2.44.9. Deve possuir gráficos contendo as movimentações de consumo dos materiais e medicamentos por bairro.

2.44.10. Deve possuir gráficos demonstrando o consumo de medicamentos por faixa etária, UPS, bairro.

2.44.11. Deve gerar gráficos de acompanhamento baseado na movimentação mensal extraídas dos atendimentos ambulatoriais de procedimentos registrados nas movimentações diárias realizadas nas unidades de saúde do Município, como con-sultas médicas, odontológicas, enfermagem e demais procedimentos e serviços realizados, específicos e ainda o número de casos por faixa-etária, sexo, por pro-fissional, por unidade de atendimento etc.

2.45. Captação de dados Móveis

2.45.1. Mobilidade – Ambiente de Desenvolvimento

2.45.1.1. Deve permitir o desenvolvimento e a customização de aplicativos mó-veis sem a necessidade de programação (codificação em alguma linguagem de programação específica) ou conhecimento tecnológico sobre sistemas operacio-nais e dispositivos móveis, utilizando, para isto, interface gráfica baseada em na-vegadores da Internet.

2.45.1.2. 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:

2.45.1.3. Um aplicativo móvel deve consistir de um conjunto de formulários de coleta ou consulta de dados, compondo atividades a serem executadas em campo por um usuário, eventualmente em um local pré-determinado ou seguindo uma rota de locais pré-determinados.

2.45.1.4. Os formulários devem ser estruturados em telas, a fim de garantir melhor experiência de uso em dispositivos de proporções menores.

2.45.1.5. Os formulários devem permitir a coleta de informações: a. Gerais: são coletadas informações gerais acerca da atividade de campo; ou b. Por itens: são coletadas informações relacionadas a itens de uma determinada lista, sendo que cada item pode representar um objeto, pessoa, local, evento ou documento.

2.45.1.6. As informações a serem coletadas devem poder ser definidas, no mí-nimo, como campos dos seguintes tipos básicos de dados: a. Alfanumérico (res-trição de tamanho); b. Numérico (restrição de número de dígitos inteiros e deci-mais); 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; e g. Hora.

2.45.1.7. 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; e c. Visível ou não visível.

2.45.1.8. Deve ser possível a criação de um número ilimitado de campos relacio- nados: 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.

2.45.1.9. Deve ser possível a definição de fórmulas de cálculo de valores deriva-dos, de forma que, a partir de um ou mais campos, pode ser calculado automati-camente o valor de outro campo.

2.45.1.10. Os operandos das fórmulas de cálculo devem incluir: a. Xxxxxx do for- mulá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.

2.45.1.11. Devem ser suportados, no mínimo, os seguintes operadores aritméti-cos: a. Adição, subtração, multiplicação e divisão; e b. Somatório;

2.45.1.12. 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 preen-chimento do formulário; ou b. Exibir uma mensagem, mas permitir o encerramento do preenchimento do formulário.

2.45.1.13. 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).

2.45.1.14. Deve permitir a captura de imagens (fotos) com a câmera do dispositivo móvel.

2.45.1.15. Deve permitir a captura de anotações livres (desenhos) em dispositivos com tela sensível ao toque.

2.45.1.16. Deve permitir a captura de coordenadas de GPS (Global Positioning System) do dispositivo móvel, se houver, para registro georeferenciado no mo-mento da execução da tarefa de campo.

2.45.1.17. Deve ser possível definir se os dados coletados em uma atividade de campo devem ser sincronizados com o repositório da solução imediatamente após seu término ou se os mesmos podem ser sincronizados posteriormente, em lote.

2.45.1.18. Deve ser possível a customização de todas as mensagens dos Ambi-entes de Execução de Aplicativos Móveis, de Desenvolvimento e de Operação e Gestão, adaptando-as ao jargão adequado ao contexto do aplicativo móvel con-forme padrão da PROPONENTE.

2.45.1.19. Deve ser possível a customização do visual dos Ambientes de Execu-ção de Aplicativos Móveis, de Desenvolvimento e de Operação e Gestão, inclu-indo a utilização da logomarca (brasão) e cores características da PROPONENTE.

2.45.1.20. O Ambiente de Desenvolvimento deve poder ser executado alternativa- mente nos seguintes navegadores da Internet: Apple Safari versão 5 ou superior, Google Chrome versão 8 ou superior, Microsoft Internet Explorer versão 8 ou su-perior e Mozilla Firefox versão 4 ou superior.

2.45.1.21. Deve possuir cadastro customizavel.

2.45.1.22. Deve possuir calculo automático com datas.

2.45.1.23. Campo de lista customizava.

2.45.2. Mobilidade – Ambiente de Execução de Aplicativos Móveis

2.45.2.1. Deve suportar a execução dos aplicativos criados no Ambiente de De- senvolvimento sem a necessidade de qualquer tipo de adaptação, sobre disposi-tivos móveis operando, no mínimo, as seguintes plataformas: a. Java Micro Edition (JME) com MIDP 2.x ou superior e CLDC 1.1 ou superior; b. Google Android ver-são 1.5 ou superior; e c. RIM Blackberry 4.6.1 ou superior.

2.45.2.2. 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.

2.45.2.3. A interface gráfica dos aplicativos móveis deverá respeitar o padrão de usabilidade de cada umas das plataformas suportadas.

2.45.2.4. 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 In-fraestrutura Operacional da Plataforma. b. Via remessa de mensagem de texto para o dispositivo móvel do usuário. c. Via transferência de arquivo por cabo USB. d. Via download das empresas

2.45.2.5. Os aplicativos móveis devem poder ser executados, adicionalmente, em notebooks e desktops conectados à Internet, utilizando um dos seguintes navega- dores da Internet: Apple Safari versão 5 ou superior, Google Chrome versão 8 ou superior, Microsoft Internet Explorer versão 8 ou superior e Mozilla Firefox versão 4 ou superior.

2.45.2.6. Deve apresentar para o usuário do aplicativo móvel as tarefas de campo que deve executar.

2.45.2.7. Deve permitir que o usuário do aplicativo móvel tenha acesso às rotas de execução de tarefas de campo definidas para ele.

2.45.2.8. Deve permitir que o usuário execute tarefas de campo não previamente programadas ou previstas em rotas.

2.45.2.9. 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 ma-nual, 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.

2.45.2.10. Deve possuir opção para realização de sincronização manual de dados com a Infraestrutura Central da Plataforma.

2.45.2.11. 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 reposi-tório do dispositivo móvel para sincronização posterior

2.45.2.12. 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 Infraestru-tura Central da Plataforma, e desta são recebidos os dados sobre novas ativida-des de campo a cargo do usuário, entre outras informações.

2.45.2.13. Novos aplicativos, bem como as customizações executadas em aplica-tivos já existentes, empregando o Ambiente de Desenvolvimento, devem ser dis- ponibilizadas para os usuários em campo, automaticamente através da sincroni-zação, sem a necessidade de intervenção dos mesmos

2.45.2.14. O aplicativo deve constar nas lojas AppStore, PlayStore, Google e per-mitir que o usuário possa efetuar download sem nenhum custo financeiro.

2.45.3. Mobilidade – Ambiente de Operação e Gestão

2.45.3.1. Deve permitir o cadastro dos seguintes elementos de informação:

• Usuários;

• Locais em que as atividades de campo são executadas;

• Itens utilizados em seções por itens

2.45.3.2. Deverão existir pelo menos três perfis distintos de usuários de acordo com a função de cada um:

• Usuário Administrador: execução de todas as funções da Plataforma, incluindo sua configuração, desenvolvimento e customização de aplicativos móveis e edição e consulta de todos os cadastros da solução.

• Usuário de Monitoria: execução da criação e cancelamento das tarefas de campo de usuários de aplicativos, monitoramento do estado destas tarefas e consulta às visualizações de modelos de análise.

• Usuário de Aplicativo: execução dos aplicativos móveis disponibilizados para ele, monitoramento do estado das tarefas e, opcionalmente, consulta às visualizações de modelos de análise. 2.45.3.3. Ao realizar o cadastro de locais, deve identificar e armazenar as coor-denadas geográficas aproximadas de sua localização, a partir da informação de seu endereço.

2.45.3.4. Ao realizar o cadastro de locais, deve identificar e armazenar as coor- denadas geográficas aproximadas de sua localização, a partir da informação de seu endereço.

2.45.3.5. Deve permitir a criação de tarefas de campo a serem executadas em um local pré-determinado, especificando qual ou quais formulários deverão ser preenchidos pelo usuário do aplicativo móvel.

2.45.3.6. Deve permitir a criação de rotas pré-definidas de execução de tarefas de campo, especificando a sequência de locais e os formulários que deverão ser preenchidos pelo usuário do aplicativo móvel.

2.45.3.7. As rotas devem poder ser visualizadas e editadas visualmente através de mapas que apresentem o trajeto.

2.45.3.8. Deve ser possível identificar os usuários de aplicativos móveis que po-derão executar cada rota.

2.45.3.9. Deve permitir a busca de tarefas de campo, no mínimo, pelos seguintes critérios e suas combinações:

• Usuário;

• Local de execução;

• Data de execução;

• Situação (executada ou pendente) 2.45.3.10. Deve permitir a análise do estado das tarefas de campo por meio de painel de controle que apresente, no mínimo, as tarefas pelo seu estado (pen-dentes ou executadas) e por usuário.

2.45.3.10. Deve permitir a análise do estado das tarefas de campo por meio de painel de controle que apresente, no mínimo, as tarefas pelo seu estado (pen-dentes ou executadas) e por usuário.

2.45.3.11. Deve permitir a análise do estado das tarefas de campo por meio de painel de controle que apresente, no mínimo, as tarefas pelo seu estado (pen-dentes ou executadas) e por usuário.

2.45.3.12. Deve permitir a análise das tarefas por meio de mapas (análise georreferenciada).

2.45.3.13. Deve ser possível a definição de estruturas de classificação para cada um dos seguintes elementos de informação:

• Atividades de campo: no mínimo uma estrutura de classificação;

• Usuários que executam atividades de campo: no mínimo duas estruturas de classificação;

• Locais em que as atividades de campo são executadas: no mínimo duas estruturas de classificação; e

• Itens utilizados em seções por itens: no mínimo duas estruturas de classificação.

2.45.3.14. Deve permitir a definição de modelos de análise de negócio em modelagem multidimensional (cubos), que devem ser gerados automaticamente a partir das estruturas de classificação dos elementos de informação e populados automaticamente a partir das informações coletadas nas atividades de campo;

2.45.3.15. Deve permitir a definição, pelo próprio usuário, de diferentes visualiza-ções dos modelos de análise, na forma de tabelas e gráficos visuais de barras, linhas e “pizza”, entre outros.

2.45.3.16. As visualizações devem poder ser exportadas para outros formatos, como Microsoft Excel (XLS) e Adobe Acrobat (PDF).

2.45.3.17. Deve ser possível integrar os aplicativos móveis com os sistemas de informação do PROPONENTE ou de terceiros.

2.45.3.18. A integração deve de dar, no mínimo, pelas seguintes formas:

• Troca de arquivos: permitir a troca de arquivos de importação e exportação por meio de protocolo de transferência de arquivos da internet; e

• Chamada de serviços da internet (webservices ou REST).

2.45.3.19. Deve ser possível definir chaves de identificação das informações, a fim estabelecer vinculação destas com os respectivos registros de dados mantidos nos sistemas de informação a serem integrados, para os seguintes elementos de informação:

• Atividades de campo;

• Usuários;

• Locais em que as atividades de campo são executadas; e

• Itens de uma lista.

2.45.3.20. O Ambiente de Gestão deve poder ser executado alternativamente nos seguintes navegadores da Internet: Apple Safari versão 5 ou superior, Google Chrome versão 8 ou superior, Microsoft Internet Explorer versão 8 ou superior e Mozilla Firefox versão 4 ou superior.

2.45.4. Mobilidade – Ambiente do ACS

2.45.4.1. Cadastro de famílias, contendo:

• Número da Família;

• Pessoa de Referencia;

• Número de moradores;

• Telefones para contato;

• Segmento;

• Área;

• Micro Área;

• Informações de todas as pessoas cadastradas.

• Cartão SUS.

2.45.4.2. A aplicação ofertada deve possuir cadastro de pessoas, contendo:

• Nome;

• Data de Nascimento;

• Idade;

• Sexo;

• Escolaridade OU Frequência Escolar (criança);

• Ocupação;

• Doenças.

2.45.4.3. Cadastro de hipertensos;

2.45.4.4. Cadastro de diabéticos;

2.45.4.5. Cadastro de hiperdia;

2.45.4.6. Cadastro de hanseníase;

2.45.4.7. Cadastro de gestantes;

2.45.4.8. Cadastro de bebês e crianças;

2.45.4.9. Cadastro de tuberculose;

2.45.4.10. Registro de reuniões de pesagem;

2.45.4.11. Registro de bancas de pressão;

2.45.4.12. Registro de focos de dengue;

• Comprovado por pelo menos uma foto;

• Georeferenciamento;

2.45.4.13. Cadastro de moradia, com funcionalidade para anexar imagens (foto- grafias tiradas diretamente do dispositivo móvel)

2.45.4.14. Cadastro de saneamento, com funcionalidade para anexar imagens (fo- tografias tiradas diretamente do dispositivo móvel)

2.45.4.15. Cadastro de informações sociais sobre a família;

2.45.4.16. Possibilidade de consulta e edição de qualquer informação a qualquer momento.

2.45.4.17. Permitir ao gestor adicionar campos de fotos e assinaturas digitais em formulários a qualquer momento.

2.46. Indicadores

2.46.1. Indicadores Saúde Sispacto

2.46.1.1. Cobertura populacional estimada pelas equipes de Atenção Básica.

2.46.1.2. Proporção de internações por condições sensíveis à Atenção Básica.

2.46.1.3. Cobertura de acompanhamento das condicionalidades de Saúde do Programa Bolsa Família.

2.46.1.4. Cobertura populacional estimada pelas equipes básicas de Saúde Bu- cal.

2.46.1.5. Média da ação coletiva de escovação dental supervisionada.

2.46.1.6. Proporção de exodontia em relação aos procedimentos.

2.46.1.7. Razão de procedimentos ambulatoriais de média complexidade e popu- lação residente.

2.46.1.8. Razão de internações clínico-cirúrgicas de média complexidade e po- pulação residente.

2.46.1.9. Razão de procedimentos ambulatoriais de alta complexidade e popula- ção residente.

2.46.1.10. Razão de internações clínico-cirúrgicas de alta complexidade na popu- lação residente.

2.46.1.11. Proporção de serviços hospitalares com contrato de metas firmado.

2.46.1.12. Número de unidades de Saúde com serviço de notificação de violência doméstica, sexual e outras violências implantado.

2.46.1.13. Proporção de acesso hospitalar dos óbitos por acidente.

2.46.1.14. Proporção de óbitos nas internações por infarto agudo do miocárdio (IAM).

2.46.1.15. Proporção de óbitos, em menores de 15 anos, nas Unidades de Terapia Intensiva (UTI).

2.46.1.16. Cobertura do Serviço de Atendimento Móvel de Urgência (Samu – 192).

2.46.1.17. Proporção das internações de urgência e emergência reguladas.

2.46.1.18. Razão de exames citopatológicos do colo do útero em mulheres de 25 a 64 anos e a população da mesma faixa etária.

2.46.1.19. Razão de exames de mamografia de rastreamento realizados em mu- lheres de 50 a 69 anos e população da mesma faixa etária.

2.46.1.20. Proporção de parto normal.

2.46.1.21. Proporção de nascidos vivos de mães com sete ou mais consultas de pré-natal.

2.46.1.22. Número de testes de sífilis por gestante.

2.46.1.23. Número de óbitos maternos em determinado período e local de residên- cia

2.46.1.24. Taxa de mortalidade infantil.

2.46.1.25. Proporção de óbitos infantis e fetais investigados.

2.46.1.26. Proporção de óbitos maternos investigados.

2.46.1.27. Proporção de óbitos de mulheres em idade fértil (MIF) investigados.

2.46.1.28. Número de casos novos de sífilis congênita em menores de 1 ano de idade.

2.46.1.29. Cobertura de Centros de Atenção Psicossocial – Caps.

2.46.1.30. Para município/região com menos de 100 mil habitantes: Número de óbitos prematuros (< 7 anos de idade com esquema vacinal completo.

2.46.1.31. Proporção de óbitos infantis e fetais indígenas investigados.

2.46.1.32. Proporção de óbitos maternos em mulheres indígenas investigados.

2.46.1.33. Proporção de óbitos de mulheres indígenas em idade fértil (MIF) investigados.

2.46.1.34. Proporção de vacinas do Calendário Básico de Vacinação da Criança com coberturas vacinais alcançadas.

2.46.1.35. Proporção de cura de casos novos de tuberculose pulmonar bacilífera.

2.46.1.36. Proporção de exame anti-HIV realizados entre os casos novos de tuberculose.

2.46.1.37. Proporção de registro de óbitos com causa básica definida.

2.46.1.38. Proporção de casos de doenças de notificação compulsória imediata (DNCI) encerradas em até 60 dias após notificação.

2.46.1.39. Proporção de municípios com casos de doenças ou agravos relacionados ao trabalho* notificados.

2.46.1.40. Percentual de municípios que executam as ações de Vigilância Sanitá- ria consideradas necessárias a todos os municípios.

2.46.1.41. Número de casos novos de aids em menores de 5 anos.

2.46.1.42. Proporção de pacientes HIV+ com 1º CD4 inferior a 200 cel/mm3.

2.46.1.43. Número de testes sorológicos anti-HCV realizados.

2.46.1.44. Proporção de cura dos casos novos de hanseníase diagnosticados nos anos das coortes.

2.46.1.45. Proporção de contatos intradomiciliares de casos novos de hanseníase examinados.

2.46.1.46. Número absoluto de óbitos por leishmaniose visceral.

2.46.1.47. Proporção de cães vacinados na campanha de vacinação antirrábica canina.

2.46.1.48. Proporção de escolares examinados para o tracoma nos municípios prioritários.

2.46.1.49. Incidência Parasitária Anual (IPA) de malária.

2.46.1.50. Número absoluto de óbitos por dengue.

2.46.1.51. Proporção de imóveis visitados em, pelo menos, quatro ciclos de visitas domiciliares para controle da dengue.

2.46.1.52. Proporção de análises realizadas em amostras de água para consumo humano quanto aos parâmetros coliformes totais, cloro residual livre e turbidez.

2.46.1.53. Percentual de municípios com o Sistema Hórus implantado ou enviando o conjunto de dados por meio do serviço WebService.

2.46.1.54. Proporção de municípios da extrema pobreza com farmácias da Aten- ção Básica e centrais de abastecimento farmacêutico estruturados.

2.46.1.55. Percentual de indústrias de medicamentos inspecionadas pela Vigilân- cia Sanitária, no ano.

2.46.1.56. Proporção de ações de educação permanente implementadas e/ou re- alizadas.

2.46.1.57. Proporção de novos e/ou ampliação de programas de Residência em Medicina de Família e Comunidade e da Residência Multiprofissional em Atenção Básica/Saúde da Família/Saúde Coletiva.

2.46.1.58. Proporção de novos e/ou ampliação de programas de Residência Médica em Psiquiatria e Multiprofissional em Saúde Mental.

2.46.1.59. Número de pontos do Teles saúde Brasil Redes implantados.

2.46.1.60. Proporção de trabalhadores que atendem ao SUS, na esfera pública, com vínculos protegidos.

2.46.1.61. Número de mesas ou espaços formais municipais e estaduais de negociação permanente do SUS, implantados e/ou mantidos em funcionamento.

2.46.1.62. Proporção de plano de saúde enviado ao conselho de Saúde.

2.46.1.63. Proporção conselhos de Saúde cadastrados no Sistema de Acompanhamento dos Conselhos de Saúde (Siacs).

2.46.1.64. Proporção de municípios com ouvidoria implantada.

2.46.1.65. Componente do SNA estruturado.

2.46.1.66. Proporção de entes com pelo menos uma alimentação por ano no Banco de Preço em Saúde.

2.46.2. Indicadores PMAQ

2.46.2.1. Área: Saúde da Mulher

2.46.2.1.1. Proporção de gestantes cadastradas pela equipe de Atenção Básica

2.46.2.1.2. Média de atendimentos de pré-natal por gestante cadastrada. 2.46.2.1.3. Proporção de gestantes que iniciaram o pré-natal no 1º trimestre. 2.46.2.1.4. Proporção de gestantes com pré-natal no mês.

2.46.2.1.5. Proporção de gestantes com vacina em dia. 2.46.2.1.6. Razão entre exames citopatológicos do colo do útero.

2.46.2.1.7. Proporção de gestantes acompanhadas por meio de visitas domiciliares.

2.46.2.2. Área: Saúde da Criança

2.46.2.2.1. Média de atendimentos de puericultura.

2.46.2.2.2. Proporção de crianças menores de 4 meses com aleitamento exclusivo.

2.46.2.2.3. Proporção de crianças menores de 1 ano com vacina em dia. 2.46.2.2.4. Proporção de crianças menores de 2 anos pesadas.

2.46.2.2.5. Média de consultas médicas para menores de 1 ano.

2.46.2.2.6. Média de consultas médicas para menores de 5 anos. 2.46.2.2.7. Proporção de crianças com baixo peso ao nascer.

2.46.2.2.8. Proporção de crianças menores de 1 ano acompanhadas no do- micílio.

2.46.2.2.9. Cobertura de crianças menores de 5 anos de idade no Sistema de Vigilância Alimentar e Nutricional (SISVAN).

2.46.2.3. Área: Controle de Diabetes Mellitus e Hipertensão Arterial Sistê- mica.

2.46.2.3.1. Proporção de diabéticos cadastrados. 2.46.2.3.2. Proporção de hipertensos cadastrados. 2.46.2.3.3. Média de atendimentos por diabético. 2.46.2.3.4. Média de atendimentos por hipertenso.

2.46.2.3.5. Proporção de diabéticos acompanhados no domicílio. 2.46.2.3.6. Proporção de hipertensos acompanhados no domicílio.

2.46.2.4. Área: Saúde Bucal

2.46.2.4.1. Média da ação coletiva de escovação dental supervisionada. 2.46.2.4.2. Cobertura de primeira consulta odontológica programática.

2.46.2.4.3. Cobertura de 1ª consulta de atendimento odontológico à ges- tante.

2.46.2.4.4. Razão entre tratamentos concluídos e primeiras consultas odon- tológicas programáticas.

2.46.2.4.5. Média de instalações de próteses dentárias.

2.46.2.4.6. Média de atendimentos de urgência odontológica por habitante. 2.46.2.4.7. Taxa de incidência de alterações da mucosa oral.

2.46.2.5. Área: Produção Geral

2.46.2.5.1. Média de consultas médicas por habitante.

2.46.2.5.2. Proporção de consultas médicas para cuidado continuado/programado. 2.46.2.5.3. Proporção de consultas médicas de demanda agendada.

2.46.2.5.4. Proporção de consulta médica de demanda imediata. 2.46.2.5.5. Proporção de consultas médicas de urgência com observação.

2.46.2.5.6. Proporção de encaminhamentos para atendimento de urgência e emergência.

2.46.2.5.7. Proporção de encaminhamentos para atendimento especializado. 2.46.2.5.8. Proporção de encaminhamentos para internação hospitalar.

2.46.2.5.9. Média de exames solicitados por consulta médica básica. 2.46.2.5.10. Média de atendimentos de enfermeiro.

2.46.2.5.11. Média de visitas domiciliares realizadas pelo Agente Comunitário de Saúde (ACS) por família cadastrada.

2.46.2.5.12. Proporção de acompanhamento das condicionalidades de saúde pelas famílias beneficiárias do Programa Bolsa Família.

2.46.2.6. Área: Vigilância - Tuberculose e Hanseníase 2.46.2.6.1. Média de atendimentos de tuberculose. 2.46.2.6.2. Média de atendimentos de hanseníase.

2.46.2.7. Área: Saúde Mental

2.46.2.7.1. Proporção de atendimentos em saúde mental, exceto de usuários de álcool e drogas.

2.46.2.7.2. Proporção de atendimentos de usuário de álcool. 2.46.2.7.3. Proporção de atendimentos de usuário de drogas. 2.46.2.7.4. Taxa de prevalência de alcoolismo.

ANEXO III MODELO DE PROPOSTA

Item	Descrição	Un	Qtd	Vlr Uni	Total
1	DESLOCAMENTO DIÁRIO PARA ATENDIMENTO E TREINAMENTO NA SEDE DO MUNICÍPIO	HRS	100	150,00	15.000,00
2	HORA DE TREINAMENTO	HRS	100	150,00	15.000,00
3	HORA PARA CUSTOMIZAÇÃO SISTEMA PARA ADEQUAR AS NECESSIDADES ESPECIFICAS DO MUNICÍPIO.	HRS	100	150,00	15.000,00
4	HOSPEDAGEM DO BANCO DE DADOS EM NUVE	MES	48	1.500,00	72.000,00
5	LICENÇA DE SOFTWARE LICENÇA DE USO, IMPLANTAÇÃO DO SISTEMA DE GESTÃO DA SAÚDE; CONVERSÃO DOS DADOS EXISTENTES; E CONFIGURAÇÃO, PARAMETRIZAÇÃO E CUSTOMIZAÇÃO PARA ADAPTAR O SISTEMA AS NECESSIDADES DA SECRETARIA.	UN	1	9.000,00	9.000,00
6	LOCAÇÃO MENSAL POR MOBILIDADE LOCAÇÃO MENSAL POR MOBILIDADE PARA AGENTES DE SAÚDE E ENDEMIAS.	MES	48	150,00	7.200,00
7	LOCAÇÃO/MANUNTENÇÃO MENSAL DO SOFTWARE DE GESTÃO	MES	48	600,00	28.800,00
8	VISITA TÉCNICA MENSAL	MES	48	400,00	19.200,00
	TOTAL DO LOTE	R$

Preço global R$         (                                 ) Validade da Proposta:              

DADOS DA LICITANTE Razão Social/Nome: CNPJ/CPF/MF

Endereço completo CNPJ/CPF/MF:

Fone/Fax: ( ) E-Mail:

DADOS BANCÁRIOS: Banco: Agência: Conta: DADOS DO REPRESENTANTE LEGAL

Nome:

Carteira de Identidade: CPF: Endereço completo:

Local e data:

Assinatura e Carimbo Representante da empresa

ANEXO IV

DECLARAÇÃO COMPROBATÓRIA DE ENQUADRAMENTO COMO MICROEMPRESA OU EMPRESA DE PEQUENO PORTE

Declaramos para os efeitos do disposto na Lei Complementar nº 123, de 14 de dezembro de 2006, que a Empresa................................................................, CNPJ .........................., está

enquadrada na categoria...............................................................(Pequeno Porte ou Microempresa), bem como não está incluída nas hipóteses do §4º do art. 3º da Lei Complementar nº 123, de 14 de dezembro de 2006.

Local e data,....................................

NOME E ASSINATURA DO REPRESENTANTE DA EMPRESA

ANEXO V DECLARAÇÃO

.

.........................................................................................................., inscrito no CNPJ

n°..................., por intermédio de seu representante legal o(a) Sr(a) ,

portador(a) da Carteira de Identidade no............................ e do CPF no ,

DECLARA, para fins do disposto no inciso V do art. 27 da Lei Federal nº 8.666, de 21 de junhode 1993, que não emprega menor de dezoito anos em trabalho noturno, perigoso ou insalubre e não emprega menor de dezesseis anos.

Ressalva: emprega menor, a partir de quatorze anos, na condição de aprendiz ( ) . (Observação: em caso afirmativo, assinalar a ressalva acima)

Local e Data:

Nome, cargo e assinatura Razão Social da empresa

ANEXO VI

MODELO DE CREDENCIAMENTO

Pelo presente a empresa ..................................................., situada na ......................, CNPJ

nº ......................................, através de seu ......................................, outorga ao

Sr. ..........................................., RG n.º .........................................., amplos poderes para re-

presentá-la junto ao Município de Tapejara, no Pregão nº 81/2021, inclusive para interpor ou desistir de recursos, receber citações, intimações, responder administrativa e judicialmente por seus atos, formular ofertas e lances de preços e, enfim, praticar todos os atos pertinentes ao certame, em nome da proponente. ---------------------

Local e Data

Assinatura do representante legal da licitante Carimbo do CNPJ da empresa

ANEXO VII

MODELO DE DECLARAÇÃO QUANTO AO FATO IMPEDITIVO DE HABILITAÇÃO

(Nome da empresa) , CNPJ

n.º                  , sediada           (endereço completo)      , declara, sob as penas da lei, conforme art. 4º, inciso VII, da Lei Federal nº 10.520, de 17 dejulho de 2002, que está ciente e cumpre plenamente os requisitos da habilitação e entrega os envelopes contendo a indicação do objeto e do preço oferecidos.

Local e Data

Assinatura do representante legal da licitante Carimbo do CNPJ da empresa

ANEXO VIII

MODELO DE DECLARAÇÃO DE REGULARIDADE FISCAL

DECLARAÇÃO DE REGULARIDADE FISCAL (   local, data      ) À PREFEITURA

Ref.: Declaração de Regularidade Fiscal Prezados Senhores,

A (       identificar e qualificar        ), por seu representante legal abaixo firmado, em atendimento ao disposto no Edital de Licitação Pregão Presencial 81/2021, DECLARA sob as penas da lei, que não se encontra cadastrada na Fazenda desse Município e que se encontra em SITUAÇÃO DE REGULARIDADE FISCAL perante o mesmo.

Atenciosamente,

Assinatura do representante legal da licitante Carimbo do CNPJ da empresa

ANEXO IV

MINUTA CONTRATO PRESTAÇÃO DE SERVIÇOS

Pelo presente termo de contrato, de um lado o Município de Tapejara, pessoa jurídica de direito público interno, inscrita no CNPJ sob n° 87.615.449/0001-42, com sede na Xxx xx Xxxxxxxx, xx 0000, neste ato representado por seu Prefeito Municipal, Sr. Xxxxxx Xxxxx, brasileiro, casado, portador da Carteira de Identidade n° 3017284674, CPF n° 453.376.75087, residente e domiciliado na Rua Xxxxxx Xxxxxxxx, nº 254, apto: 601, nesta cidade, doravante denominado CONTRATANTE e, de outro lado, a empresa ,

inscrita no CNPJ n°....................., com sede na........................, n°. ,

bairro..................., na cidade de................, neste ato representada pelo sr , bra-

xxxxxxx, xxxxxx, (profissão), portador da carteira de identidade n°...................., CPF n°............., residente e domiciliado na rua.............., n°............., bairro.............., na cidade de...................., doravante denominada CONTRATADA, com base na licitação modalidade Pregão Presencial n° 81/2021, na Lei n° 8.666/93, assim como em conformidade com as condições do edital referido, e termos da proposta, firmam o presente contrato, mediante as cláusulas e condições a seguir enunciadas:

CLÁUSULA PRIMEIRA:

Contratação de empresa especializada no fornecimento de Licenças de uso de software para a área de gestão da Saúde, com execução de serviços técnicos em manutenção, atualização, suporte e assessoria operacional, customização, implantação e migração de base de dados, incluindo a capacitação dos usuários em todos os módulos do sistema e com o acompanhamento presencial na fase inicial de utilização e acompanhamento presencial e/ou on-line pós implantação, descritos nos anexos “I” e “II deste edital, por um período de 12 meses, a contar do início da vigência do contrato conforme especificações e condições estabelecidas no edital, e na referida proposta da Contratada, que fica fazendo parte integrante deste Contrato.

CLÁUSULA SEGUNDA:

Os serviços objeto deste contrato deverão ser iniciados, pela CONTRATADA, no prazo máximo de 5 (cinco) dias contados do recebimento da Ordem de Execução dos Serviços, emitida pelo MUNICÍPIO.

Parágrafo único - A CONTRATADA não poderá transferir a outrem as obrigações assumidas neste contrato.

O prazo de vigência do contrato será de 12 meses, a contar de sua assinatura, podendo ser prorrogado, a critério da Administração e com a anuência da contratada, nos termos do art. 57, inciso II da Lei nº 8.666-93, tendo como reajuste o índice IPCA.

CLÁUSULA TERCEIRA:

SOFTWARES: A entrega e Instalação das Licenças dos softwares deverão ser pagos em 15 dias, mediante emissão do termo de aceite correspondente.

SERVIÇOS MANUTENÇÃO: A prestação dos Serviços Especializados, Manutenção, Suporte e Treinamento deverão ser pagos em 12 parcelas mensais e iguais mediante aceite correspondente, cujo prazo começará a contar 30 dias após o início da prestação dos serviços.

A Prefeitura de Tapejara efetuará o pagamento até 5º (quinto) dia útil do mês subsequente após o recebimento e aceite dos produtos/serviços com a respectiva Nota Fiscal/Fatura ou documento legalmente equivalente, observado o cumprimento integral das disposições contidas neste edital.

A empresa deverá mencionar na respectiva Nota Fiscal/Fatura informações sobre os produtos e serviços prestados, tais como: atividade realizada, local, além de mencionar o número do Contrato, o número da Licitação e o nº do Processo, bem como o relatório dos serviços realizados no período a que o pagamento se referir.

Os preços são fixos e irreajustáveis, exceto por força de disposição legal, especialmente quando comprovadas as situações descritas no art. 65, I, “b”, II, “d”, da Lei n.º 8.666/93 e com base no limite do IGPM/FGV, desde que atendidas as condições preconizadas FONE E E-MAIL no Edital.

Em caso de renovação contratual, após 12 (doze) meses da vigência do contrato, os valores poderão reajustados com base na variação do IGPM-FGV ocorrida no período, tendo como base inicial o preço consignado na proposta apresentada pela licitante contratada.

Ocorrendo atraso no pagamento, os valores serão corrigidos monetariamente pelo IGPM/FGV do período, ou outro índice que vier a substitui-lo, e a Administração compensará a contratada com juros de 0,5% ao mês, pro rata.

CLÁUSULA QUARTA:

Pela inexecução total ou parcial do contrato o MUNICÍPIO poderá, garantida prévia defesa, aplicar à CONTRATADA as seguintes penalidades:

I - multa de 0,5 % (meio por cento) por dia de atraso, limitado esta a 3 (três) dias, após o qual será considerado inexecução contratual;

II - multa de 8% (oito por cento) no caso de inexecução parcial do contrato, cumulada com a pena de suspensão do direito de licitar e o impedimento de contratar com a Administração pelo prazo de 01 (um ano);

III - multa de 10 % (dez por cento) no caso de inexecução total do contrato, cumulada com a pena de suspensão do direito de licitar e o impedimento de contratar com a Administração pelo prazo de 02 (dois anos).

Parágrafo único - As multas serão calculadas sobre o montante não adimplido do contrato.

CLÁUSULA QUINTA - ENCARGOS DA CONTRATADA

Cabe a CONTRATADA, além de manter atualizada a versão do Sistema, esclarecer as suas alterações, mantendo-o em pleno funcionamento, dentro das características da concessão.

Corrigir eventuais defeitos nos programas em uso.

Alterar os Sistemas, quando solicitado pelo usuário, para adaptação a normas legais.

Esclarecer se consultada por via telefônica, correspondência, email 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.

A responsabilidade da CONTRATADA estará limitada ao complemento das obrigações aqui assumidas com a Contratante não lhe cabendo qualquer outra, inclusive por perdas e danos ou lucros cessantes cujas causas possam ser atribuídas direta ou indiretamente à utilização do sistema.

CLÁUSULA SEXTA - ENCARGOS DA CONTRATANTE

Efetuar os pagamentos, conforme Cláusula Quinta.

Dar prioridade aos técnicos da CONTRATADA para utilização do equipamento da CONTRATANTE quando da visita técnica dos mesmos.

Notificar a CONTRATADA, por escrito, quaisquer irregularidades que venham a ocorrer, em função da prestação do serviço.

Acompanhar e fiscalizar a execução deste contrato e comunicar à CONTRATADA toda e qualquer ocorrência relacionada com a execução do contrato.

CLÁUSULA SÉTIMA:

As multas aplicadas na execução do contrato serão descontadas do pagamento, a critério exclusivo do MUNICÍPIO e, quando for o caso, cobradas judicialmente.

CLÁUSULA OITAVA:

Será rescindido o presente contrato, independente de notificação judicial ou extrajudicial, sem qualquer direito à indenização, por parte da CONTRATADA, se esta:

I - não cumprir regularmente quaisquer das obrigações assumidas neste contrato;

II - subcontratar, transferir ou ceder, total ou parcialmente, o objeto deste contrato a terceiros;

III - fusionar, cindir ou incorporar-se a outra empresa;

IV - falir, requerer concordata ou for instaurada insolvência civil;

V - paralisar ou cumprir lentamente os serviços, sem justa causa, por mais de 3 (três) dias consecutivos;

VI - demonstrar incapacidade, desaparelhamento, inidoneidade técnica ou má fé; VII - atrasar injustificadamente o início dos serviços.

Parágrafo único - Este contrato poderá ser rescindido por mútuo acordo, atendida a conveniência do MUNICÍPIO, mediante termo próprio, recebendo a CONTRATADA o valor dos serviços já executados.

CLÁUSULA NONA:

As despesas decorrentes desta contratação serão suportadas pelas seguintes dotações orçamentárias:

28875.09.01.10.301.0118.2231.3.3.3.90.39.00000000.0040 Secretaria Municipal de Saúde.

CLÁUSULA DÉCIMA:

Para questões de litígios decorrentes do presente contrato, fica eleito o Foro da Comarca de Tapejara-RS, com exclusão de qualquer outro, por mais especializada que seja.

E, por estarem assim justos e contratados, assinam o presente instrumento, em 3 (três) vias de igual teor e forma, juntamente com as testemunhas abaixo firmadas, a tudo presentes.

Tapejara,     /        /   

XXXXXX XXXXX Empresa:

Prefeito Municipal de Tapejara