ESTADO DE SANTA CATARINA MUNICIPIO DE RIO DAS ANTAS

Prefeitura Municipal

Secretaria Municipal de Administração e Finanças – SMAF

TERMO DE REFERÊNCIA

1. OBJETO DA CONTRATAÇÃO

1.1. Contratação de empresa especializada para fornecimento de licença de uso de software de registro eletrônico em saúde (SRES) com execução de serviços técnicos de manutenção (corretiva, adaptativa e evolutiva), atualização, suporte técnico, consultoria técnica, customização, implantação, migração de dados legados e treinamento, incluindo acompanhamento presencial e remoto, e suporte técnico, em atendimento a demanda do Fundo Municipal de Saúde conforme condições, quantidades e exigências estabelecidas neste instrumento.

1.2. Detalhamento do objeto:

SISTEMA DE SAÚDE PÚBLICA MUNICIPAL
Item	Descrição / Especificações mínimas	Qtd	Un.	Valor Unt	Subtotal
1	Serviço de Implantação e treinamento de usuários de gestão pública de saúde	01	UN.	R$16.666,66	R$16.666,66
2	Licença de uso de sistema WEB, manutenção, hospedagem em nuvem, atualização e suporte técnico remoto de gestão pública de saúde.	12	Mês	R$3.802,00	R$45.624,00
3	Hora de visita técnica pós sistema implantado sob demanda e não obrigatório de gestão pública de saúde.	100	Hora	R$155,00	R$15.500,00
4	Hora customização pós sistema implantado sob demanda e não obrigatório de gestão pública de saúde.	100	Hora	R$178,88	R$17.888,00
Total Global Estimado					R$95.678,66

1.3. Não é obrigatório que os programas ofertados sejam organizados na mesma ordem e conjunto, ou nome do módulo, porém, é obrigatório que atenda as especificações, tarefas e rotinas citadas na parte descritiva deste termo da referência.

1.4. A presente licitação adotará o tipo “menor preço global”, justificada a aglutinação dos itens diante da indivisibilidade do objeto, nos termos da Súmula 247 do TCU por se tratar de sistema integrado.

1.5. O número de usuários deverá ser ilimitado, sem a necessidade de o município adquirir licenças adicionais durante toda a vigência do contrato.

2. JUSTIFICATIVA DA NECESSIDADE DA CONTRATAÇÃO

2.1. A adoção de sistemas informatizados de gestão é uma necessidade da administração municipal na área de saúde, como forma de automação de processos, controle e registros, redução de tempo e otimização de recursos materiais e humanos. É uma ferramenta imprescindível para o alcance da efetividade social das ações e políticas públicas de saúde.

3. FUNDAMENTAÇÃO LEGAL

3.1. Para elaboração deste documento, foram observados às seguintes normas de regência:

3.1.1. Lei Federal nº 8.666/1993: Institui normas para licitações e contratos da Administração Pública e dá outras providências;

3.1.2. Lei Federal nº 10.520/2002: Institui no âmbito da União, Estados, Distrito Federal e Municípios, modalidade de licitação denominada pregão, para aquisição de bens e serviços comuns, e dá outras providências;

3.1.3. Demais legislações correlatas, aplicando-se subsidiariamente, no que couber.

4. CLASSIFICAÇÃO DOS SERVIÇOS

4.1. A aquisição do objeto deste Termo de Referência deverá ser realizada na modalidade de PREGÃO do tipo MENOR PREÇO GLOBAL em observância ao Art. 4º do Decreto nº 5.450/05, considerando que os serviços e bens são considerados comuns, conforme as características previstas no Art. 1º da Lei nº 10.520/02.

4.2. Trata-se de serviço comum, de caráter continuado, a ser contratado mediante licitação, na modalidade pregão, em sua forma eletrônica.

4.3. A prestação dos serviços não gera vínculo empregatício entre os empregados da Contratada e a Administração Contratante, vedando-se qualquer relação entre estes que caracterize pessoalidade e subordinação direta.

5. REQUISITOS DA CONTRATAÇÃO

5.1. São requisitos básicos para a contratação do serviço que a empresa:

5.1.1. Serviço continuado, com fornecimento de mão de obra em regime de dedicação exclusiva;

5.1.2. Domine o conhecimento das soluções tecnológicas adotadas e utilizadas pela CONTRATANTE;

5.1.3. Consiga entregar os produtos e serviços dentro dos prazos e em consonância ao acordo de nível de serviço estabelecido;

5.1.4. Mantenha as informações da CONTRATANTE, a que tem acesso, sob sigilo;

5.1.5. Planeje previamente suas atividades;

5.1.6. Proponha soluções baseadas nas necessidades da CONTRATANTE e nas melhores práticas de mercado e de acordo com as recomendações dos fabricantes das soluções;

5.1.7. Documente e mantenha atualizado o registro das atividades desempenhadas na CONTRATANTE;

5.1.8. Todos esses requisitos têm como objetivo a entrega de produtos e serviços com qualidade preestabelecida e dentro do prazo acordado entre a CONTRATANTE e a CONTRATADA;

6. DA PROVA DE CONCEITO

6.1. Definido um vencedor da disputa de lances e este sendo habilitado após análise de sua documentação, é facultado a Administração, caso seja de seu interesse, submeter a solução ofertada a uma avaliação de conformidade do objeto ofertado, através de uma prova de conceito, conforme Instrução Normativa n° 04/2014, da Secretaria de Logística e Tecnologia da Informação SLTI do Ministério do Planejamento, Orçamento e Gestão – MPOG e orientações da Nota Técnica nº 04/2008/TCU, visando dar segurança mínima a contratação, conforme preconizado na Lei de Licitações.

6.2. Caso seja de interesse da Administração a avaliação de amostra, a data, horário e local para realização da prova de conceito será divulgada pelo Pregoeiro. Por questões de ordem sanitária, a Prova de Conceito poderá ser feita de forma remota, por meio de videoconferência ou outro recurso tecnológico adequado, visando a segurança e saúde dos participantes e acompanhamento/validação em tempo real em equipamento da licitadora por parte da equipe de apoio e avaliação.

6.3. A prova de conceito deverá ser realizada por Comissão Especial a ser designada, formada por servidores com conhecimento pertinente.

6.4. Ao final da Prova de Conceito – POC, a Comissão Especial avaliadora, especialmente nomeada e designada, registrará em Ata o resultado e encaminhará ao Pregoeiro e à sua Equipe de Apoio. A critério da comissão, poderão ser emitidas atas diárias ao término dos trabalhos, com intuito de registro das atividades realizadas, porém sem julgamento de resultado.

6.5. A PROPONENTE que convocada para avaliação não comparecendo em dia e hora previamente agendados para a realização da Sessão Pública da Prova de Conceito – POC, será automaticamente reprovada pela Comissão avaliadora.

6.6. Caso a primeira colocada não atenda aos requisitos do Termo de Referência conforme regras aqui estabelecidas, será chamada a segunda colocada e assim sucessivamente, até a obtenção de uma proposta adequada ou ser considerada fracassada a licitação

6.7. Para a POC, a licitadora fornecerá local apropriado que contenha:

a) Mesa ou bancada e cadeiras para uso na apresentação;

b) Ponto de energia elétrica (220v ou 110v);

c) Um ponto de acesso à internet por rede cabeado, sem bloqueios ou restrições.

6.8. Para a POC, a licitante ficará responsável por providenciar:

a) Computador (Dekstop ou Laptop) com SO Linux Kernel 5.14 ou superior;

b) Computador (Dekstop ou Laptop) com SO Windows 10 ou superior;

c) Smartphone com Android;

d) Tablet com Android.

6.9. A proponente será responsável pelo banco de dados de teste para a demonstração efetiva de todas as funcionalidades exigidas neste termo e disponíveis no sistema, sendo que cada função requerida deverá ser executada e seus resultados demonstrados. Bem como deverá trazer os equipamentos previamente configurados para a realização dos testes, não sendo aceitas intervenções de pessoas externas a avaliação (não presentes na demonstração).

6.10. O objetivo da avaliação é atestar-se o seu funcionamento satisfatório em uma situação real, o sistema apresentado deverá estar previamente instalado em datacenter, com os recursos exigidos de segurança, desempenho e disponibilidade, como descrito neste termo de referência.

6.11. A licitadora poderá solicitar que algumas operações sejam demonstradas em equipamento de sua propriedade.

6.12. Para o bom andamento dos trabalhos de avaliação, bem como resguardo de direitos do particular quanto à propriedade intelectual protegidos por Xxx, só será permitida a participação de no máximo um representante das demais licitantes por sala de apresentação, sendo-lhe vedado a manifestação, resguardado o direito de tomar apontamentos por escrito.

6.13. Os apontamentos realizados por escrito poderão ser solicitados pela comissão de avaliação e também pela empresa que está sendo avaliada, ao término de cada apresentação.

6.14. Durante a apresentação é proibido o uso de telefone, smartphone, tablete, notebook, gravadores e outros equipamentos do gênero, para todos os presentes, ficando somente liberados os equipamentos necessários para a demonstração da empresa a ser avaliada;

6.15. O representante de licitante que estiver assistindo à apresentação e se comportar de maneira a prejudicar os trabalhos, poderá ser conduzida para fora do recinto, bem como incidir nas cominações civis e criminais aplicáveis.

6.16. Os equipamentos da licitante poderão ser auditados pela Equipe da Licitadora, bem como poderão ser recolhidos para eventuais diligências ou perícias.

6.17. É vedado as demais licitantes acesso aos equipamentos da empresa que estiver realizando a apresentação, antes, durante ou após esta, sob pena de desclassificação da infratora, sem prejuízo as cominações civis e criminais aplicáveis.

6.18. Será considerada aprovada a solução que atender a todas as exigências contidas neste instrumento e efetuar a demonstração técnica, apresentando as condições mínimas previstas neste Termo de Referência.

6.19. A Prova de Conceito – POC consiste na validação dos requisitos mínimos exigidos no Termo de Referência.

6.20. Caso a solução ofertada não atenda 90% dos requisitos relacionados a Performance, ou ao Padrão Tecnológico e de Segurança, não se passará a etapa de Avaliação dos Requisitos Específicos por módulos de Programas, sendo automaticamente reprovada, por princípio de economicidade, celeridade e utilidade do procedimento.

6.21. A apresentação dever se dar na ordem em que os itens estão relacionados, devendo a EMPRESA VENCEDORA apresentá-los de forma objetiva, sem ajustes e sem contato externo. Não será permitido desenvolver, editar, corrigir ou ajustar o sistema durante a apresentação;

6.22. A apresentação dos sistemas poderá ser realizada de forma simultânea ou não, conforme acordado entre as partes. As empresas que estão participando do certame serão comunicadas por e-mail, do(s) dia(s), horário(s) e locai(s) em que acontecerão.

6.23. Os itens devem ser apresentados de maneira sequencial, iniciando-se no primeiro e seguindo-se ordenadamente até o último, sem que seja permitido retroceder na apresentação.

6.24. Será permitido à vencedora provisória, após a avaliação de um item não aprovado, uma segunda tentativa, visando garantir que em caso de algum entendimento que a empresa tenha tido em divergência com a comissão especial de avaliação seja sanado de imediato.

6.25. Durante a prova de conceito, deverão ser avaliados todos os itens (sem exceção) assinalados como requeridos no descritivo técnico.

6.26. Informa-se que toda a estrutura (software e hardware) necessários para a apresentação do SOFTWARE e realização da POC são de responsabilidade da empresa concorrente.

6.27. Em casos de completa impossibilidade de realização da prova de conceito por motivos alheios aos citados (falta de energia, por exemplo), a prova será suspensa e transferida para o próximo dia útil caso a situação que a impeça dure um período maior que 30 minutos.

7. OBRIGAÇÕES DA CONTRATANTE

7.1. São obrigações da Contratante:

7.1.1. Nomear Fiscais do Contrato para acompanhar e fiscalizar sua execução;

7.1.2. Encaminhar formalmente as demandas de serviços, de acordo com os critérios estabelecidos neste Termo de Referência;

7.1.3. Receber o objeto prestado pela CONTRATADA que esteja em conformidade com a proposta aceita, conforme inspeções realizadas;

7.1.4. Supervisionar a execução do objeto do Contrato, exigindo presteza na execução e correção das falhas eventualmente detectadas;

7.1.5. Aplicar à CONTRATADA as sanções administrativas regulamentares e contratuais cabíveis;

7.1.6. Liquidar o empenho e efetuar o pagamento à CONTRATADA, dentro dos prazos preestabelecidos em Contrato;

7.1.7. Comunicar à CONTRATADA todas e quaisquer ocorrências relacionadas com a prestação dos serviços;

7.1.8. Prestar as informações e os esclarecimentos pertinentes que venham a ser solicitados pelo representante da CONTRATADA;

7.1.9. Registrar as ocorrências que estejam em desacordo com as condições estabelecidas neste Termo de Referência, solicitando a CONTRATADA a pronta regularização;

7.1.10. Proceder com a avaliação dos serviços e ateste das respectivas faturas decorrentes.

7.1.11. Receber o objeto no prazo e condições estabelecidas no Edital e seus anexos;

7.1.12. Verificar minuciosamente, no prazo fixado, a conformidade dos bens recebidos provisoriamente com as especificações constantes do Termo de Referência, Edital e da proposta, para fins de aceitação e recebimento definitivo;

7.1.13. Comunicar à Contratada, por escrito, sobre imperfeições, falhas ou irregularidades verificadas no objeto fornecido, para que seja substituído, reparado ou corrigido;

7.1.14. Acompanhar e fiscalizar o cumprimento das obrigações da Contratada, através de comissão/servidor especialmente designado;

7.1.15. Efetuar o pagamento à Contratada no valor correspondente ao fornecimento do objeto, no prazo e forma estabelecidos no Termo de Referência, Edital e seus anexos;

7.2. A Administração não responderá por quaisquer compromissos assumidos pela Contratada com terceiros, ainda que vinculados à execução do contrato, bem como por qualquer dano causado a terceiros em decorrência de ato da Contratada, de seus empregados, prepostos ou subordinados.

7.3. Dispor de equipamentos de informática adequados para uso do sistema e programas locados, bem como para treinamento via internet de usuários;

7.4. Proceder o download da cópia de segurança do banco de dados ou disponibilizar estrutura para redundância de informações, assumindo integral responsabilidade pela proteção, integridade e guarda arquivos de dados, todos de sua propriedade, visando satisfazer às necessidades de segurança, assim como “restart” e recuperação no caso de falha de máquina;

7.5. Cumprir as orientações e procedimentos técnicos especificados pela CONTRATADA para o bom funcionamento e operacionalidade do sistema;

7.6. Dar prioridade aos técnicos da CONTRATADA para utilização do equipamento da CONTRATANTE quando da visita técnica dos mesmos, bem como assegurar o acesso dos empregados da Contratada, quando devidamente identificados e uniformizados, aos locais em que devam executar os serviços;

8. OBRIGAÇÕES DA CONTRATADA

8.1. Indicar formalmente preposto apto a representá-la junto à CONTRATANTE, que deverá responder pela fiel execução do contrato;

8.2. Atender prontamente quaisquer orientações e exigências do fiscal do contrato, inerentes à execução do objeto contratual;

8.3. Sujeitar-se à mais ampla e irrestrita fiscalização por parte da CONTRATANTE, prestando todos os esclarecimentos solicitados e atendendo prontamente às reclamações formuladas;

8.4. Tomar todas as providências necessárias à fiel execução dos serviços objeto do Contrato;

8.5. Reparar quaisquer danos diretamente causados à CONTRATANTE ou a terceiros por culpa ou dolo de seus representantes legais, prepostos ou empregados, em decorrência da relação contratual, não excluindo ou reduzindo a responsabilidade da fiscalização ou o acompanhamento da execução dos serviços pela CONTRATANTE;

8.6. Propiciar todos os meios e facilidades necessárias à fiscalização dos serviços pela CONTRATANTE, cujo representante terá poderes para sustar o fornecimento, total ou parcialmente, em qualquer tempo, sempre que considerar a medida necessária;

8.7. Manter durante toda a vigência do contrato, em compatibilidade com as obrigações assumidas, todas as condições de habilitação e qualificação exigidas na licitação;

8.8. Providenciar que seus contratados portem documento de identificação quando da execução do objeto à CONTRATANTE;

8.9. Promover a execução dos serviços dentro dos parâmetros e rotinas estabelecidas, em observância às normas legais e regulamentares aplicáveis e às recomendações aceitas pela boa técnica;

8.10. Prestar todas as informações e esclarecimentos solicitados pela CONTRATANTE, julgados necessários à boa gestão do contrato;

8.11. Cumprir com os prazos, disposições e especificações estabelecidas neste Termo de Referência;

8.12. Repassar aos fiscais do Contrato, em tempo hábil, quaisquer justificativas de situações específicas que envolvam impedimento do cumprimento dos termos do Contrato, por razões alheias ao controle da CONTRATADA;

8.13. Comunicar a contratante quaisquer ocorrências que impeçam, mesmo que temporariamente, a execução dos serviços;

8.14. Apresentar a CONTRATANTE, sempre que exigido pela equipe de fiscalização do contrato, relatórios e outros documentos inerentes à execução dos serviços;

8.15. Manter sigilo de todos os dados ou informações da CONTRATANTE obtidas em função da execução dos serviços;

8.16. Submeter seus empregados, durante o tempo de permanência nas dependências da CONTRATANTE, aos regulamentos de segurança e disciplina por este instituído, mantendo-os devidamente identificados;

8.17. Orientar-se pelo sigilo do teor de todos os documentos produzidos e abster-se de transferir responsabilidade a outrem;

8.18. Assumir a responsabilidade por todos os encargos previdenciários e obrigações sociais previstos na legislação social e trabalhista em vigor, obrigando-se a saldá-los na época própria, uma vez que seus empregados não manterão nenhum vínculo empregatício com a CONTRATANTE;

8.19. Assumir a responsabilidade por todas as providências e obrigações estabelecidas na legislação específica de acidentes de trabalho, quando, em ocorrência da espécie, forem vítimas os seus empregados quando da execução do objeto ou em conexão com ele, ainda que acontecido nas dependências da CONTRATANTE, inclusive por danos causados a terceiros;

8.20. Fornecer à sua equipe técnica todos os materiais necessários para a prestação dos serviços;

8.21. Responder por quaisquer acidentes de que possam sofrer os seus empregados, quando em serviço nas dependências da CONTRATANTE;

8.22. Adotar práticas de sustentabilidade ambiental na execução dos serviços, quando couber, nos termos das legislações em vigor;

8.23. Abster-se de veicular publicidade acerca do contrato, salvo mediante prévia autorização da CONTRATANTE;

8.24. Abster-se de contratar servidor pertencente ao quadro de pessoal da CONTRATANTE durante a vigência do contrato;

8.25. A Contratada deve cumprir todas as obrigações constantes no Termo de Referência, Edital, seus anexos e sua proposta, assumindo como exclusivamente seus os riscos e as despesas decorrentes da boa e perfeita execução do objeto e, ainda:

8.25.1. Efetuar a entrega do objeto em perfeitas condições, conforme especificações, prazo e local constantes no Termo de Referência e seus anexos, acompanhado da respectiva nota fiscal, na qual constarão as indicações referentes a: marca, fabricante, modelo, procedência e prazo de garantia ou validade;

8.25.2. Responsabilizar-se pelos vícios e danos decorrentes do objeto, de acordo com os artigos 12, 13 e 17 a 27, do Código de Defesa do Consumidor (Lei nº 8.078, de 1990);

8.25.3. Substituir, reparar ou corrigir, às suas expensas, no prazo fixado neste Termo de Referência, o objeto com avarias ou defeitos;

8.25.4. Comunicar à Contratante, no prazo máximo de 24 (vinte e quatro) horas que antecede a data da entrega, os motivos que impossibilitem o cumprimento do prazo previsto, com a devida comprovação;

8.25.5. Manter, durante toda a execução do contrato, em compatibilidade com as obrigações assumidas, todas as condições de habilitação e qualificação exigidas na licitação;

8.25.6. Indicar preposto para representá-la durante a execução do contrato.

8.25.7. Executar os serviços conforme especificações deste Termo de Referência e de sua proposta, com a alocação dos empregados necessários ao perfeito cumprimento das cláusulas contratuais, além de fornecer e utilizar os materiais e equipamentos, ferramentas e utensílios necessários, na qualidade e quantidade mínimas especificadas neste Termo de Referência e em sua proposta;

8.25.8. Reparar, corrigir, remover ou substituir, às suas expensas, no total ou em parte, no prazo fixado pelo fiscal do contrato, os serviços efetuados em que se verificarem vícios, defeitos ou incorreções resultantes da execução ou dos materiais empregados;

8.25.9. Responsabilizar-se pelos vícios e danos decorrentes da execução do objeto, bem como por todo e qualquer dano causado à União ou à entidade federal, devendo ressarcir imediatamente a Administração em sua integralidade, ficando a Contratante autorizada a descontar da garantia, caso exigida no edital, ou dos pagamentos devidos à Contratada, o valor correspondente aos danos sofridos;

8.25.10. Utilizar empregados habilitados e com conhecimentos básicos dos serviços a serem executados, em conformidade com as normas e determinações em vigor;

8.25.11. Vedar a utilização, na execução dos serviços, de empregado que seja familiar de agente público ocupante de cargo em comissão ou função de confiança no órgão Contratante, nos termos do artigo 7° do Decreto n° 7.203, de 2010;

8.25.12. A empresa contratada deverá encaminhar ao Departamento de Contratos no endereço eletrônico xxxxxxxxx@xxxxxxxxxxx.xx.xxx.xx , até o dia trinta do mês seguinte ao da prestação dos serviços, os seguintes documentos: a) prova de regularidade com a Fazenda Federal (Certidão Negativa de Débitos quanto à dívida ativa da União, expedida pela Procuradoria Geral da Fazenda Nacional); b) prova de regularidade para com a Fazenda Estadual; c) prova de regularidade para com a Fazenda Municipal, sendo da sede da proponente; d)Fundo de Garantia por Tempo de Serviço (FGTS); e) prova de inexistência de débitos inadimplidos perante a Justiça do Trabalho, mediante a apresentação de Certidão, nos termos da Lei federal nº. 12.440/2011; f)Certidão (ões) de Falência ou Concordata expedida pelo distribuidor da sede da pessoa jurídica, em plena validade, devendo ser apresentada tanto no Sistema E-SAJ quanto no Sistema E-Proc, considerando a implantação do Sistema no Poder Judiciário no Estado de Santa Catarina; Quando for o caso.

8.25.13. Responsabilizar-se pelo cumprimento das obrigações previstas em Acordo, Convenção, Dissídio Coletivo de Trabalho ou equivalentes das categorias abrangidas pelo contrato, por todas as obrigações trabalhistas, sociais, previdenciárias, tributárias e as demais previstas em legislação específica, cuja inadimplência não transfere a responsabilidade à Contratante;

8.25.14. Comunicar ao Fiscal do contrato, no prazo de 24 (vinte e quatro) horas, qualquer ocorrência anormal ou acidente que se verifique no local dos serviços.

8.25.15. Prestar todo esclarecimento ou informação solicitada pela Contratante ou por seus prepostos, garantindo-lhes o acesso, a qualquer tempo, ao local dos trabalhos, bem como aos documentos relativos à execução do empreendimento.

8.25.16. Paralisar, por determinação da Contratante, qualquer atividade que não esteja sendo executada de acordo com a boa técnica ou que ponha em risco a segurança de pessoas ou bens de terceiros.

8.25.17. Promover a guarda, manutenção e vigilância de materiais, ferramentas, e tudo o que for necessário à execução dos serviços, durante a vigência do contrato.

8.25.18. Promover a organização técnica e administrativa dos serviços, de modo a conduzi-los eficaz e eficientemente, de acordo com os documentos e especificações que integram este Termo de Referência, no prazo determinado.

8.25.19. Conduzir os trabalhos com estrita observância às normas da legislação pertinente, cumprindo as determinações dos Poderes Públicos, mantendo sempre limpo o local dos serviços e nas melhores condições de segurança, higiene e disciplina.

8.25.20. Submeter previamente, por escrito, à Contratante, para análise e aprovação, quaisquer mudanças nos métodos executivos que fujam às especificações do memorial descritivo.

8.25.21. Manter durante toda a vigência do contrato, em compatibilidade com as obrigações assumidas, todas as condições de habilitação e qualificação exigidas na licitação;

8.25.22. Guardar sigilo sobre todas as informações obtidas em decorrência do cumprimento do contrato;

8.25.23. Arcar com o ônus decorrente de eventual equívoco no dimensionamento dos quantitativos de sua proposta, inclusive quanto aos custos variáveis decorrentes de fatores futuros e incertos, tais como os valores providos com o quantitativo de vale transporte, devendo complementá-los, caso o previsto inicialmente em sua proposta não seja satisfatório para o atendimento do objeto da licitação, exceto quando ocorrer algum dos eventos arrolados nos incisos do § 1º do art. 57 da Lei nº 8.666, de 1993.

8.25.24. Cumprir, além dos postulados legais vigentes de âmbito federal, estadual ou municipal, as normas de segurança da Contratante;

8.25.25. Prestar os serviços dentro dos parâmetros e rotinas estabelecidos, fornecendo todos os materiais, equipamentos e utensílios em quantidade, qualidade e tecnologia adequadas, com a observância às recomendações aceitas pela boa técnica, normas e legislação;

8.25.26. Assegurar à CONTRATANTE, em conformidade com o previsto no subitem 6.1, “a” e “b”, do Anexo VII – F da Instrução Normativa SEGES/MP nº 5, de 25/05/2017:

8.25.26.1. O direito de propriedade intelectual dos produtos desenvolvidos, inclusive sobre as eventuais adequações e atualizações que vierem a ser realizadas, logo após o recebimento de cada parcela, de forma permanente, permitindo à Contratante distribuir, alterar e utilizar os mesmos sem limitações;

8.25.26.2. Os direitos autorais da solução, do projeto, de suas especificações técnicas, da documentação produzida e congêneres, e de todos os demais produtos gerados na execução do contrato, inclusive aqueles produzidos por terceiros subcontratados, ficando proibida a sua utilização sem que exista autorização expressa da Contratante, sob pena de multa, sem prejuízo das sanções civis e penais cabíveis.

8.25.26.3. Realizar a transição contratual com transferência de conhecimento, tecnologia e técnicas empregadas, sem perda de informações, podendo exigir, inclusive, a capacitação dos técnicos da contratante ou da nova empresa que continuará a execução dos serviços.

8.25.27. Tratar como confidenciais informações e dados contidos nos sistemas da Contratante, guardando total sigilo perante terceiros, nos termos da Lei 13.709/2018 (Lei Geral da Proteção de Dados Pessoais – LGPD);

8.25.28. Comunicar imediatamente, por escrito, a impossibilidade de execução de qualquer obrigação contratual, para adoção das providências cabíveis;

8.25.29. Responsabilizar-se por quaisquer danos ou prejuízos causados a contratante ou terceiros em função do desempenho de suas atividades, se apurada culpa ou responsabilidade civil, nos termos da legislação, observado o direito à ampla defesa e ao contraditório.

8.25.30. Executar a configuração, migração de informações e demais atividades necessárias à implantação dos módulos do sistema contratado, autorizados formalmente pela CONTRATANTE, através de ordem de início de serviço, no prazo máximo declarado no contrato;

8.25.31. Efetuar a manutenção legal do sistema para adaptação às alterações legais (legislação federal e estadual) inerentes às suas funcionalidades, durante toda a vigência do contrato, devendo executar as atualizações que se fizerem necessárias para o seu perfeito funcionamento e enquadramento as mudanças nas legislações;

8.25.32. Efetuar a manutenção corretiva do sistema, corrigindo eventuais falhas, independentemente de serem observadas ou não pelos usuários;

8.25.33. Prestar o serviço de suporte técnico conforme disposições do termo de referência e contrato;

8.25.34. Avaliar, em prazo razoável, a viabilidade técnica e jurídica das solicitações de alteração específicas encaminhadas eletronicamente pelo CONTRATANTE, e repassar orçamento acompanhado de cronograma para execução dos serviços;

8.25.35. Executar as customizações do sistema, conforme viabilidade técnica e solicitações da CONTRATANTE, mediante orçamento prévio aprovado e acordo de nível de serviços;

8.25.36. Fornecer o Banco de Dados utilizado, bem como as licenças para esta CONTRATANTE, caso seja necessário;

9. DA SUBCONTRATAÇÃO

9.1. Não será admitida a subcontratação do objeto licitatório.

10. DA ALTERAÇÃO SUBJETIVA

10.1. É admissível a fusão, cisão ou incorporação da contratada com/em outra pessoa jurídica, desde que sejam observados pela nova pessoa jurídica todos os requisitos de habilitação exigidos na licitação original; sejam mantidas as demais cláusulas e condições do contrato; não haja prejuízo à execução do objeto pactuado e haja a anuência expressa da Administração à continuidade do contrato.

11. DO CONTROLE E FISCALIZAÇÃO DA EXECUÇÃO

11.1. Nos termos do art. 67 Lei nº 8.666, de 1993, será designado representante para acompanhar e fiscalizar a entrega dos bens, anotando em registro próprio todas as ocorrências relacionadas com a execução e determinando o que for necessário à regularização de falhas ou defeitos observados.

11.1.1. O recebimento de material de valor superior a R$ 176.000,00 (cento e setenta e seis mil reais) será confiado a uma comissão de, no mínimo, 3 (três) membros, designados pela autoridade competente.

11.2. A fiscalização de que trata este item não exclui nem reduz a responsabilidade da Contratada, inclusive perante terceiros, por qualquer irregularidade, ainda que resultante de imperfeições técnicas ou vícios redibitórios, e, na ocorrência desta, não implica em corresponsabilidade da Administração ou de seus agentes e prepostos, de conformidade com o art. 70 da Lei nº 8.666, de 1993.

11.3. O representante da Administração anotará em registro próprio todas as ocorrências relacionadas com a execução do contrato, indicando dia, mês e ano, bem como o nome dos funcionários eventualmente envolvidos, determinando o que for necessário à regularização das falhas ou defeitos observados e encaminhando os apontamentos à autoridade competente para as providências cabíveis.

11.4. Caberá aos fiscais do contrato, dentre outras atribuições, determinar providências necessárias ao regular e efetivo cumprimento contratual, bem como anotar e enquadrar as infrações contratuais constatadas, comunicando as mesmas ao seu superior hierárquico.

11.5. As decisões e providências que ultrapassarem as competências dos Fiscais deverão ser solicitadas ao seu gestor, em tempo hábil, para a adoção das medidas que se fizerem necessária.

11.6. A Administração, devidamente representada na forma legal, poderá rejeitar no todo ou em parte os serviços contratados, sem ônus para a contratante, se executado em desacordo com as especificações estabelecidas em Termo de Referência e seus anexos, bem como em contrato e na proposta comercial.

11.7. O fiscal técnico apresentará ao preposto da CONTRATADA a avaliação da execução do objeto ou, se for o caso, a avaliação de desempenho e qualidade da prestação dos serviços realizada.

11.8. Em hipótese alguma, será admitido que a própria CONTRATADA materialize a avaliação de desempenho e qualidade da prestação dos serviços realizada.

11.9. A empresa CONTRATADA será a única e exclusiva responsável pela execução dos serviços, sendo a contratante reservada o direito de exercer a mais ampla e completa fiscalização contratual, mediante servidores designados para este fim.

11.10. O descumprimento total ou parcial das obrigações e responsabilidades assumidas pela CONTRATADA ensejará a aplicação de sanções administrativas, previstas neste Termo de Referência e na legislação vigente, podendo culminar em rescisão contratual, conforme disposto nos artigos 77 e. 87 da Lei nº 8.666/93.

11.11. A fiscalização do contrato, ao verificar que houve subdimensionamento da produtividade pactuada, sem perda da qualidade na execução do serviço, deverá comunicar à autoridade responsável para que esta promova a adequação contratual à produtividade efetivamente realizada, respeitando-se os limites de alteração dos valores contratuais previstos no § 1º do artigo 65 da Lei nº 8.666, de 1993.

11.12. O representante do CONTRATANTE deverá promover o registro das ocorrências verificadas, adotando as providências necessárias ao fiel cumprimento das cláusulas contratuais, conforme o disposto nos §§ 1º e 2º do art. 67 da Lei nº 8.666, de 1993.

11.13. As atividades de gestão e fiscalização da execução contratual devem ser realizadas de forma preventiva, rotineira e sistemática, podendo ser exercidas por servidores, equipe de fiscalização ou único servidor, desde que, no exercício dessas atribuições, fique assegurada a distinção dessas atividades e, em razão do volume de trabalho, não comprometa o desempenho de todas as ações relacionadas à Gestão do Contrato.

12. DO FATURAMENTO

12.1. Os serviços objeto desta contratação serão solicitados por Autorizações de Fornecimento (AF), emitidas e autorizadas conforme necessidade da CONTRATANTE.

12.2. Somente serão faturadas as Ordens efetivamente executadas, após avaliação de conformidade das condições de entrega dos serviços e validação pela CONTRATANTE.

13. DO PAGAMENTO

13.1. O pagamento será realizado no prazo máximo de até 15 (quinze) dias, contados a partir do recebimento da Nota Fiscal ou Fatura, através de ordem bancária, para crédito em banco, agência e conta correntes indicados pelo contratado.

13.2. Considera-se ocorrido o recebimento da nota fiscal ou fatura quando o órgão contratante atestar a execução do objeto do contrato.

13.3. Havendo erro na apresentação da Nota Fiscal ou dos documentos pertinentes à contratação, ou, ainda, circunstância que impeça a liquidação da despesa, como, por exemplo, obrigação financeira pendente, decorrente de penalidade imposta ou inadimplência, o pagamento ficará sobrestado até que a

Contratada providencie as medidas saneadoras. Nesta hipótese, o prazo para pagamento iniciar-se-á após a comprovação da regularização da situação, não acarretando qualquer ônus para a Contratante.

13.4. Será considerada data do pagamento o dia em que constar como emitida a ordem bancária para pagamento.

PARÁGRAFO ÚNICO: Será exigida, no ato do pagamento, a apresentação das Certidões de Regularidade FGTS, e de Regularidade Fiscal dos encargos tributários das Fazendas Federal, Estadual e Municipal da sede da CONTRATADA. Juntamente com:

• Atestado de recebimento emitido pela Secretaria Competente;

13.5. Fica expressamente estabelecido que os preços constantes na proposta da CONTRATADA incluam todos os custos diretos e indiretos para a execução do Objeto contratado, constituindo-se na única remuneração devida.

13.6. A Nota Fiscal/Fatura deverá ser emitida de acordo com os valores unitários e totais discriminados na Autorização de Fornecimento.

13.7. A Nota Fiscal deverá ser emitida em nome do Município de Rio das Antas com indicação do CNPJ específico, nº 83.074.294/0001-23.

13.8. De acordo com o §6º, I, do Art. 23, Anexo XI, do Regulamento do ICMS Catarinense, ficam os licitantes vencedores obrigados a emitir nota fiscal eletrônica – NF-e, modelo 55, em substituição às notas fiscais impressas modelos 1 e 1-A, quando for o caso.

13.9. As notas fiscais deverão ser enviadas para os e-mails:

Secretaria de Saúde: xxxxxxx@xxxxxxxxxxx.xx.xxx.xx

13.10. Os arquivos XML deverão ser enviados no e-mail: xxx@xxxxxxxxxxx.xx.xxx.xx

13.11. Após a apresentação da proposta, não haverá reajuste de preço.

13.12. Quando houver glosa parcial dos serviços, a contratante deverá comunicar a empresa para que emita a nota fiscal ou fatura com o valor exato dimensionado.

13.13. O pagamento será efetuado pela Contratante no prazo de 15 (quinze) dias, contados do recebimento da Nota Fiscal/Fatura.

13.14. O setor competente para proceder ao pagamento deve verificar se a Nota Fiscal ou Fatura apresentada expressa os elementos necessários e essenciais do documento, tais como:

I - O prazo de validade;

II - A data da emissão;

III - Os dados do contrato e do órgão contratante; IV - O período de prestação dos serviços;

V - O valor a pagar; e

VI - Eventual destaque do valor de retenções tributárias cabíveis.

13.10. Havendo erro na apresentação da Nota Fiscal/Fatura, ou circunstância que impeça a liquidação da despesa, o pagamento ficará sobrestado até que a Contratada providencie as medidas saneadoras. Nesta hipótese, o prazo para pagamento iniciar-se-á após a comprovação da regularização da situação, não acarretando qualquer ônus para a Contratante;

13.11. A emissão da Nota Fiscal/Fatura será precedida do recebimento provisório e definitivo.

13.4.1. O pagamento somente será autorizado depois de efetuado o “atesto” pelo servidor competente, condicionado este ato à verificação da conformidade da Nota Fiscal/Fatura apresentada em relação aos serviços efetivamente prestados, devidamente acompanhada das comprovações mencionadas no item 2 do Anexo XI da IN SEGES/MPDG n. 5/2017.

I - A Nota Fiscal ou Xxxxxx deverá ser obrigatoriamente acompanhada da comprovação da regularidade fiscal conforme documentação mencionada no art. 29 da Lei nº 8.666, de 1993.

13.5. Considera-se ocorrido o recebimento da nota fiscal ou fatura quando o órgão contratante atestar a execução do objeto do contrato.

13.6. Havendo erro na apresentação da Nota Fiscal ou dos documentos pertinentes à contratação, ou, ainda, circunstância que impeça a liquidação da despesa, como, por exemplo, obrigação financeira pendente, decorrente de penalidade imposta ou inadimplência, o pagamento ficará sobrestado até que a Contratada providencie as medidas saneadoras. Nesta hipótese, o prazo para pagamento iniciar-se-á após a comprovação da regularização da situação, não acarretando qualquer ônus para a Contratante.

13.7. Será considerada data do pagamento o dia em que constar como emitida a ordem bancária para pagamento.

13.8. Não havendo regularização ou sendo a defesa considerada improcedente, a contratante deverá comunicar aos órgãos responsáveis pela fiscalização da regularidade fiscal quanto à inadimplência da contratada, bem como quanto à existência de pagamento a ser efetuado, para que sejam acionados os meios pertinentes e necessários para garantir o recebimento de seus créditos.

13.9. Persistindo a irregularidade, a contratante deverá adotar as medidas necessárias à rescisão contratual nos autos do processo administrativo correspondente, assegurada à contratada a ampla defesa.

13.10. Havendo a efetiva execução do objeto, os pagamentos serão realizados normalmente, até que se decida pela rescisão do contrato, caso a contratada não regularize sua situação.

13.11. Será rescindido o contrato em execução com a contratada inadimplente, salvo por motivo de economicidade, segurança nacional ou outro de interesse público de alta relevância, devidamente justificado, em qualquer caso, pela máxima autoridade da contratante.

13.12. Quando do pagamento, será efetuada a retenção tributária prevista na legislação aplicável.

13.12.1. A Contratada regularmente optante pelo Simples Nacional, nos termos da Lei Complementar nº 123, de 2006, não sofrerá a retenção tributária quanto aos impostos e contribuições abrangidos por aquele regime. No entanto, o pagamento ficará condicionado à apresentação de comprovação, por meio de documento oficial, de que faz jus ao tratamento tributário favorecido previsto na referida Lei Complementar.

14. DO REAJUSTE

14.1. Os preços inicialmente contratados são fixos e irreajustáveis no prazo de um ano contado da data limite para a apresentação das propostas.

14.2. Na hipótese de alteração de preços de mercado, para mais ou para menos devidamente comprovadas, estes poderão ser revistos, visando ao restabelecimento da relação inicialmente pactuada, em decorrência de situações previstas na aliena 'd' do inciso II do caput e do §5º do art. 64 da Lei nº8.666, de 1993.

14.3. Dentro do prazo de vigência do contrato e mediante solicitação da contratada, os preços contratados poderão sofrer reajuste após o interregno de um ano, aplicando-se o índice INPC exclusivamente para as obrigações iniciadas e concluídas após a ocorrência da anualidade.

14.4. Nos reajustes subsequentes ao primeiro, o interregno mínimo de um ano será contado a partir dos efeitos financeiros do último reajuste.

14.5. No caso de atraso ou não divulgação do índice de reajustamento, o CONTRATANTE pagará à CONTRATADA a importância calculada pela última variação conhecida, liquidando a diferença correspondente tão logo seja divulgada o índice definitivo. Fica a CONTRATADA obrigada a apresentar memória de cálculo referente ao reajustamento de preços do valor remanescente, sempre que este ocorrer.

14.6. Nas aferições finais, o índice utilizado para reajuste será, obrigatoriamente, o definitivo.

14.7. Caso o índice estabelecido para reajuste venha a ser extinto ou de qualquer forma não possa mais ser utilizado, será adotado, em substituição, o que vier a ser determinado pela legislação então em vigor.

14.8. Na ausência de previsão legal quanto ao índice substituto, as partes elegerão novo índice oficial, para reajustamento do preço do valor remanescente, por meio de termo aditivo.

14.9. O reajuste será realizado por apostilamento.

15. PROPRIEDADE, SIGILO E SEGURANÇA DAS INFORMAÇÕES

15.1. A CONTRATADA deverá manter sigilo em relação aos dados, informações ou documentos que tomar conhecimento em decorrência da prestação dos serviços objeto desta contratação, bem como se submeter às orientações e normas internas de segurança da informação vigentes, devendo orientar seus empregados e/ou prepostos nesse sentido, sob pena de responsabilidade civil, penal e administrativa.

16. DAS SANÇÕES ADMINISTRATIVAS

16.1. Com fundamento no DECRETO Nº 044/2021 DE 1º DE ABRIL DE 2021, normas regulamentares sobre o procedimento administrativo, no âmbito da Administração Pública Municipal, voltado à aplicação de sanções administrativas aos licitantes e contratados, fundamentadas na Lei Federal nº 8.666, de 1993 e no artigo 7º, da Lei Federal nº 10.520, de 2002, e descredenciamento no cadastro de fornecedores da CONTRATANTE, pelo prazo de até 05 (cinco) anos, garantida a ampla defesa, sem prejuízo das multas previstas neste Termo de Referência/Contrato e demais cominações legais a(s) contratada(s) que:

16.1.1. Apresentar documentação falsa;

16.1.2. Ensejar o retardamento da execução do objeto;

16.1.3. Xxxxxx ou fraudar na execução do contrato;

16.1.4. Comportar-se de modo inidôneo;

16.1.5. Fizer declaração falsa;

16.1.6. Cometer fraude fiscal;

16.1.7. Não assinar o contrato;

16.1.8. Deixar de entregar documentação exigida no edital, anexos e termo de contrato.

16.1.9. Não mantiver a proposta e demais casos omissos.

16.2. Considera-se comportamento inidôneo, entre outros, a declaração falsa quanto às condições de participação, quanto ao enquadramento como ME/EPP ou o conluio entre os licitantes, em qualquer momento da licitação, mesmo após o encerramento da fase de lances.

16.3. As sanções previstas nos incisos I, III e IV do art. 87 da Lei nº 8.666/93 poderão ser aplicadas juntamente com a do inciso II do mesmo artigo, facultada a defesa prévia do interessado, no respectivo processo, no prazo de 5 (cinco) dias úteis, a contar a partir da notificação da empresa.

16.4. Em qualquer hipótese de aplicação de sanções será assegurado à licitante vencedora o contraditório e a ampla defesa.

16.5. Sem prejuízo das sanções previstas no item anterior, com fundamento nos artigos 86 e 87 da Lei nº 8.666/93, a licitante vencedora ficará sujeita, no caso de atraso injustificado, assim considerado pela Administração, inexecução parcial ou inexecução total da obrigação, sem prejuízo das responsabilidades civil e criminal, assegurada a prévia e ampla defesa, às seguintes penalidades:

16.5.1. Advertência;

16.5.2. Multa de:

I - 0,33% (trinta e três centésimos por cento) por dia de atraso, na execução dos serviços, calculado sobre o valor correspondente à parte inadimplente, até o limite de 9,9% (nove vírgula nove por cento), que corresponde até 30 (trinta) dias de atraso;

II - 0,66% (sessenta e seis centésimos por cento) por dia de atraso, na execução dos serviços, calculado, desde o primeiro dia de atraso, sobre o valor correspondente à parte inadimplente, em caráter excepcional, e a critério do órgão contratante, quando o atraso ultrapassar 30 (trinta) dias;

III - 5% (cinco por cento) sobre o valor total do contrato/nota de empenho, por descumprimento do prazo de entrega, sem prejuízo de demais sanções;

IV - 15% (quinze por cento) em caso de recusa injustificada do adjudicatário em assinar o contrato ou retirar o instrumento equivalente e/ou entrega da garantia contratual, dentro do prazo estabelecido pela administração, recusa parcial ou total na entrega do material, recusa na conclusão do serviço, ou rescisão do contrato/nota de empenho, calculado sobre a parte inadimplente; e

V - 20% (vinte por cento) sobre o valor do contrato/nota de xxxxxxx, pela inexecução total do contrato.

16.6. Declaração de inidoneidade para licitar ou contratar com a Administração Pública enquanto perdurarem os motivos determinantes da punição ou até que seja promovida a reabilitação, que será concedida sempre que o contratado ressarcir a Administração pelos prejuízos resultantes e após decorrido o prazo da sanção aplicada com base no item anterior.

16.7. No caso de multa, cuja apuração ainda esteja em processamento, ou seja, na fase da defesa prévia e/ou prazo recursal, a CONTRATANTE poderá fazer a retenção do valor correspondente à multa, até a decisão final. Caso a defesa prévia e/ou recurso seja aceito, ou aceito parcialmente, pela CONTRATANTE, o valor retido correspondente será depositado em favor da CONTRATADA, em até 5 (cinco) dias úteis a contar da data da decisão final.

16.8. As sanções serão aplicadas pela autoridade administrativa, assegurada a ampla defesa e podendo dar-se cumulativamente, inclusive por medida cautelar, antecedente ou incidente de procedimento administrativo.

16.9. As advertências serão aplicadas sempre que necessário ao fiel cumprimento contratual, desde que os fatos apresentados não tenham gerado prejuízo à Administração.

16.10. Se, durante o processo de aplicação de penalidade, se houver indícios de prática de infração administrativa tipificada pela Lei nº 12.846, de 1º de agosto de 2013 e demais normas vigentes, como ato lesivo à administração pública nacional ou estrangeira, cópias do processo administrativo necessárias à apuração da responsabilidade da empresa deverão ser remetidas à autoridade competente, com despacho fundamentado, para ciência e decisão sobre a eventual instauração de investigação preliminar ou Processo Administrativo.

16.11. A apuração e o julgamento das demais infrações administrativas não consideradas como ato lesivo à Administração Pública nacional ou estrangeira nos termos da Lei nº 12.846, de 1º de agosto de 2013, seguirão seu rito normal na unidade administrativa.

16.12. Caso o valor da multa não seja suficiente para cobrir os prejuízos causados pela conduta do licitante, a União ou Entidade poderá cobrar o valor remanescente judicialmente, conforme artigo 419 do Código Civil.

17. DAS HIPÓTESES DE RESCISÃO

17.1. A inexecução total ou parcial do contrato enseja a sua rescisão, com as consequências contratuais e as previstas em lei ou regulamento.

17.2. A rescisão do contrato poderá ser determinada por ato unilateral e escrita da Administração, pelos seguintes motivos:

17.2.1. O não cumprimento de cláusulas contratuais, especificações, projetos ou prazos;

17.2.2. O cumprimento irregular de cláusulas contratuais, especificações, projetos e prazos;

17.2.3. A lentidão do seu cumprimento, levando a Administração a comprovar a impossibilidade da conclusão da obra, do serviço ou do fornecimento, nos prazos estipulados;

17.2.4. O atraso injustificado no início da obra, serviço ou fornecimento;

17.2.5. A paralisação da obra, do serviço ou do fornecimento, sem justa causa e prévia comunicação à Administração;

17.2.6. A subcontratação total ou parcial do seu objeto, a associação do contratado com outrem, a cessão ou transferência, total ou parcial, bem como a fusão, cisão ou incorporação, não admitidas no edital e no contrato;

17.2.7. O desatendimento das determinações regulares da autoridade designada para acompanhar e fiscalizar a sua execução, assim como as de seus superiores;

17.2.8. O cometimento reiterado de faltas na sua execução, anotadas em registro próprio;

17.2.9. A decretação de falência ou a instauração de insolvência civil;

17.2.10. A dissolução da sociedade ou o falecimento do contratado;

17.2.11. A alteração social ou a modificação da finalidade ou da estrutura da empresa, que prejudique a execução do contrato;

17.2.12. Razões de interesse público, de alta relevância e amplo conhecimento, justificados e determinados pela máxima autoridade da esfera administrativa a que está subordinado o contratante e exaradas no processo administrativo a que se refere o contrato;

17.2.13. A ocorrência de caso fortuito ou de força maior, regularmente comprovada, impeditiva da execução do contrato.

17.3. Comete infração administrativa nos termos da Lei nº 10.520, de 2002, a Contratada que:

a) Falhar na execução do contrato, pela inexecução, total ou parcial, de quaisquer das obrigações assumidas na contratação;

b) Ensejar o retardamento da execução do objeto;

c) Fraudar na execução do contrato;

d) Comportar-se de modo inidôneo; ou

e) Cometer fraude fiscal.

17.4. Também ficam sujeitas às penalidades do art. 87, III e IV da Lei nº 8.666, de 1993, as empresas ou profissionais que:

17.4.26. Tenham sofrido condenação definitiva por praticar, por meio dolosos, fraude fiscal no recolhimento de quaisquer tributos;

17.4.27. Xxxxxx praticado atos ilícitos visando a frustrar os objetivos da licitação;

17.4.28. Demonstrem não possuir idoneidade para contratar com a Administração em virtude de atos ilícitos praticados.

17.5. A aplicação de qualquer das penalidades previstas realizar-se-á em processo administrativo que assegurará o contraditório e a ampla defesa à Contratada, observando-se o procedimento previsto na Lei nº 8.666, de 1993, e subsidiariamente a Lei nº 9.784, de 1999.

17.6. As multas devidas e/ou prejuízos causados à Contratante serão deduzidos dos valores a serem pagos, ou recolhidos em favor da União, ou deduzidos da garantia, ou ainda, quando for o caso, serão inscritos na Dívida Ativa da União e cobrados judicialmente.

17.4.26. Caso a Contratante determine, a multa deverá ser recolhida no prazo máximo de 15 (quinze) dias, a contar da data do recebimento da comunicação enviada pela autoridade competente.

17.7. Caso o valor da multa não seja suficiente para cobrir os prejuízos causados pela conduta do licitante, a União ou Entidade poderá cobrar o valor remanescente judicialmente, conforme artigo 419 do Código Civil.

17.8. A autoridade competente, na aplicação das sanções, levará em consideração a gravidade da conduta do infrator, o caráter educativo da pena, bem como o dano causado à Administração, observado o princípio da proporcionalidade.

18. CRITÉRIOS DE SELEÇÃO DO FORNECEDOR.

18.1. As exigências de habilitação jurídica e de regularidade fiscal e trabalhista são as usuais para a generalidade dos objetos, conforme disciplinado no edital.

18.2. Os critérios de qualificação econômico-financeira a serem atendidos pelo fornecedor estão previstos no edital.

18.3. Os critérios de qualificação técnica a serem atendidos pelo fornecedor serão:

18.4. Comprovação de aptidão para desempenho de atividade pertinente e compatível em características, quantidades e prazos com o objeto da licitação, mediante a apresentação de no mínimo 1 (um) atestado ou declaração de capacidade técnica, expedido por entidade pública ou privada, comprovando que a proponente implantou e/ou que mantém em funcionamento sistema, similar e compatível com o objeto desta licitação, mediante a apresentação de atestado(s) fornecido(s) por pessoas jurídicas de direito público ou privado.

• Declaração de que a proponente é fabricante do sistema, ou autorização expressa deste, comprovando que tem acesso e total conhecimento sobre os programas fontes, estando apta a realizar os serviços de implantação, configuração, suporte, customização e manutenção dos programas ofertados;

• Declaração de Atendimento dos Requisitos Técnicos e de Capacidade Operativa (art. 30, caput, inciso II e § 6º todos da Lei 8.666/93) - Declaração de que a licitante disporá, por ocasião da futura contratação, de todos os equipamentos, pessoal técnico e operacional necessários à execução dos serviços, conforme orientações do termo de referência, garantindo ainda que não haverá qualquer tipo de paralisação dos serviços por falta dos equipamentos ou de pessoal;

18.5. O critério de julgamento da proposta é MENOR PREÇO GLOBAL

18.6. As regras de desempate entre propostas são as discriminadas no edital.

19. ESTIMATIVA DE PREÇOS E PREÇOS REFERENCIAIS.

19.1. Conforme critérios definidos na PORTARIA Nº 804, DE 13 DE NOVEMBRO DE 2018 expedida pelo Ministério da Justiça, de modo especial no inciso II do artigo 2º, e a recente INSTRUÇÃO NORMATIVA Nº 73, DE 5 DE AGOSTO DE 2020, cujos dispositivos indicam como parâmetro de pesquisa, a busca de contratações similares de outros entes públicos.

I - Painel de Preços, disponível no endereço eletrônico xxx.xx/xxxxxxxxxxxxxx, desde que as cotações refiram-se a aquisições ou contratações firmadas no período de até 1 (um) ano anterior à data de divulgação do instrumento convocatório; II - aquisições e contratações similares de outros entes públicos, firmadas no período de até 1 (um) ano anterior à data de divulgação do instrumento convocatório; III - dados de pesquisa publicada em mídia especializada, de sítios eletrônicos especializados ou de domínio amplo, desde que atualizados no momento da pesquisa e compreendidos no intervalo de até 6 (seis) meses de antecedência da data de divulgação do instrumento convocatório, contendo a data e hora de acesso; ou IV - pesquisa direta com fornecedores, mediante solicitação formal de cotação, desde que os orçamentos considerados estejam compreendidos no intervalo de até 6 (seis) meses de antecedência da data de divulgação do instrumento convocatório.

§1º Deverão ser priorizados os parâmetros estabelecidos nos incisos I e II.

I – Os comprovantes das pesquisas de preços coletadas integram este processo, tais como: Pesquisas que tratam os incisos II, III e IV do Art. 5º da IN 73/2020, como documento anexo. Estas informações subsidiaram a elaboração do Mapa de Preços no qual constam as médias das cotações de preços para o estabelecimento dos valores unitários máximos dos itens a serem licitados.

II – A metodologia utilizada para obtenção do preço estimado está de acordo com conforme trata o Art.6º da IN 73/2020:

Art. 6º Serão utilizados, como métodos para obtenção do preço estimado, a média, a mediana ou o menor dos valores obtidos na pesquisa de preços, desde que o cálculo incida sobre um conjunto de três ou mais preços, oriundos de um ou mais dos parâmetros de que trata o art. 5º, desconsiderados os valores inexequíveis, inconsistentes e os excessivamente elevados.

§ 1º Poderão ser utilizados outros critérios ou métodos, desde que devidamente justificados nos autos pelo gestor responsável e aprovados pela autoridade competente.

§ 2º Para desconsideração dos valores inexequíveis, inconsistentes e os excessivamente elevados, deverão ser adotados critérios fundamentados e descritos no processo administrativo.

§ 3º Os preços coletados devem ser analisados de forma crítica, em especial, quando houver grande variação entre os valores apresentados.

§ 4º Excepcionalmente, será admitida a determinação de preço estimado com base em menos de três preços, desde que devidamente justificada nos autos pelo gestor responsável e aprovado pela autoridade competente.

Foram consultados os preços através do sítio “banco de preços”, uma ferramenta informatizada, cuja pesquisa baseia-se em resultados de licitações adjudicadas e/ou homologadas realizadas pela Administração

Pública o que contempla os parâmetros dos Incisos I e II. Na ausência de informação neste meio foram utilizados preços de sítios eletrônicos especializados de amplo domínio, que trata o Inciso III do Art. 5º da IN 73/2020.

A pesquisa direta com fornecedores que trata o Inciso IV da IN 73/2020 só foi utilizada quando não foi possível a obtenção de preços nos parâmetros citados anteriormente ou quando os valores apresentados não foram excessivamente elevados.

A administração adotou o critério de consultar fornecedores do ramo de atuação compatível com o objeto pesquisado, além de fornecedores participantes de outras licitações do Órgão. Desta forma, foram consultados formalmente fornecedores, através de correios eletrônicos.

A busca e, por conseguinte, embasamento de preços em contratações similares, traz sem dúvida alguma maior agilidade ao lançamento do certame. A administração não fica adstrita apenas a intenção de participação e, por conseguinte boa vontade de fornecedores em retornarem as solicitações de orçamentos. Tais solicitações além de sequer serem em sua maioria respondidas, quando ocorrem, são cumpridas apenas no momento que os fornecedores entenderem como viáveis.

Além disso, a administração apresenta como base preços constantes de contratos públicos integrantes de certames já homologados por outras administrações. Contratos já referendados pelo E. Tribunal de Contas do estado, posto que, extraídos do site do próprio órgão da Administração Pública Municipal ou mesmo do respectivo Tribunal.

Acerca da matéria, o Tribunal de Contas da União manifestou posicionamento destacando o dever quanto a busca diversificada de fontes de preços, com prioridade para o Painel de Preços e as contratações similares de outros Órgãos. Vejamos:

TCU – Acórdão nº 1445/2015 – Plenário

Na elaboração do orçamento estimativo da licitação, bem como na demonstração da vantajosidade de eventual prorrogação de contrato, devem ser utilizadas fontes diversificadas de pesquisa de preços. Devem ser priorizadas consultas ao Portal de Compras Governamentais e a contratações similares de outros entes públicos, em detrimento de pesquisas com fornecedores, publicadas em mídias especializadas ou em sítios eletrônicos especializados ou de domínio amplo, cuja adoção deve ser tida como prática subsidiária.

Relator: UBIRATAN AGUIAR

Sumário: REPRESENTAÇÃO. PEDIDO DE REEXAME. PREGÃO ELETRÔNICO. SERVIÇOS DE INFORMÁTICA. REVOGAÇÃO DE MEDIDA CAUTELAR.

PROVIMENTO PARCIAL. 1. A aferição de preços nas aquisições e contratações de produtos e serviços de tecnologia da informação, no âmbito da Administração Pública federal, na fase de estimativa de preços, no momento de adjudicação do objeto do certame licitatório, na contratação e alterações posteriores, deve se basear em valores aceitáveis, que se encontrem dentro da faixa usualmente praticada pelo mercado em determinada época, obtida por meio de pesquisa a partir de fontes diversas, como orçamentos de fornecedores, valores adjudicados em licitações de órgãos públicos - inclusos aqueles constantes no Comprasnet -, valores registrados em atas de Sistema de Registro de Preços, entre outras, a exemplo de compras/contratações realizadas por corporações privadas em condições idênticas ou semelhantes àquelas da Administração Pública.

2. Preço aceitável, a ser considerado na faixa de preços referida no item precedente, é aquele que não representa claro viés em relação ao contexto do mercado, ou seja, abaixo do limite inferior ou acima do maior valor constante da faixa identificada para o produto ou serviço. 3. A utilização de fontes que não sejam capazes de representar o mercado de tecnologia da informação para produtos com certa complexidade ou serviços fornecidos para o setor público - como sites na Internet, inclusive internacionais - pode servir apenas como mero indicativo de preço, sem que sirvam os valores encontrados, por si sós, para caracterização de sobrepreço ou superfaturamento. 4. Os critérios apontados nos itens precedentes devem balizar, também, a atuação dos órgãos de controle, ao ser imputado sobrepreço ou superfaturamento nas aquisições e contratações relacionadas à área de tecnologia da informação.

Ainda com base nas decisões destacadas, salientamos do respectivo posicionamento que além da definição quanto aos requisitos a serem priorizados, resulta clara a condição de utilização de orçamentos de fornecedores e consulta em sites especializados apenas de forma subsidiária na consulta de preços.

Assim, diante da realidade aqui apresentada, essa administração tomou como base contratações por outras administrações, todos com similaridades na prestação dos serviços buscados por essa administração.

Esta metodologia de estimativa de preço foi adotada devido à singularidade da solução que se pretende contratar, havendo dificuldades em encontrar outras contratações semelhantes no painel de preços, banco de preços e diretamente nos demais órgãos e entidades.

Portando, posso assegurar que os preços obtidos através da Média das cotações refletem fielmente a realidade dos preços de mercado.

O anexo I da portaria 804, reforça a orientação do Tribunal de Contas da União inclusive quanto a utilização como parâmetro os contratos anteriores firmados com o próprio órgão. In Verbis:

A unidade requisitante, conforme orientação do Tribunal de Contas da União, deverá consultar o maior número de fontes possíveis, de modo a possibilitar que a pesquisa de preços reflita o real comportamento do mercado, levando em conta diversas origens, como, por exemplo, contratos anteriores do próprio órgão e os firmados por outros órgãos públicos, valores registrados no Sistema Integrado de Administração de Serviços Gerais - SIASG, nas atas de registro de preços da Administração Pública Federal e cotações com fornecedores (Acórdãos n° 2.318/2014 - Plenário e Acórdão 2.816/2014 - Plenário).

Desse modo concluímos que, os valores praticados pelas contratações baseadas nas similaridades destacadas, indicam que o valor definido por essa administração para a presente contratação, não se caracteriza como excessivo nem como inexequível.

Cumpre ainda salientar de que o valor definido para a contratação com base na similaridade de contratos formalizados por outras administrações/órgãos, demonstra ainda que, não somente pelos parâmetros apurados, mas pela necessidade atual e futura da administração, principalmente em se assegurar de que estará contratando um fornecedor que possa suprir integralmente suas necessidades tecnológica, o valor definido se encontra dentro da realidade do mercado.

20. DOS RECURSOS ORÇAMENTÁRIOS

20.1. A indicação da dotação orçamentária fica postergada para o momento da assinatura do contrato ou instrumento equivalente.

21. DAS DISPOSIÇÕES GERAIS

21.1. Dúvidas acerca das disposições contidas neste Termo de Referência poderão ser esclarecidas por intermédio do correio eletrônico xxxxxxxxx@xxxxxxxxxxx.xx.xxx.xx.

21.2. O presente documento segue assinado pelos responsáveis:

Rio das Antas/SC 2022.

Ordenador da Despesa

Visto Assessoria Jurídica:

ANEXO I – DAS ESPECIFICAÇÕES TÉCNICAS MIGRAÇÃO DE DADOS

A migração de dados legados consiste na conversão e absorção de todas as bases de dados existentes e

indicadas a converter pelo contratante antes da implantação do SRES. Este processo se dará em paralelo ao processo de implantação do sistema, conforme cronograma a ser elaborado em conjunto pelas partes, sempre de forma organizada e clara, seguindo os seguintes preceitos:

A secretaria de saúde disponibilizará os dados legados em arquivos de texto, com dicionário de dados, assim como, equipe técnica com conhecimento dos dados preexistentes a serem importados, visando auxiliar a equipe técnica da empresa fornecedora do SRES no que se refere a estrutura dos dados legados.

A empresa fornecedora do SRES deve importar os seguintes dados legados: Cadastro de cidadãos;

Registros de prontuário;

Históricos de consumo de medicamentos; Históricos de aplicação de imunobiológicos;

Laudos laboratoriais pré-emitidos (emitidos em PDF no sistema anterior, para trazer junto as assinaturas digitalizadas dos profissionais que liberaram os resultados).

A empresa fornecedora do SRES deve disponibilizar equipe com experiência em serviço de migração de dados para execução das rotinas de importação. Deve ainda, disponibilizar de ferramentas 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 importação, tais como detecção de inconsistências e incoerências.

As atividades de migração de dados constante neste edital serão pagas mediante uso das horas previstas para evolução e adaptação do sistema, conforme constante na tabela descritiva do objeto.

Todo trabalho de conversão de dados deve ser feito antes do início da implantação. O cronograma de implantação proposto no ato da assinatura do contrato deve considerar que as capacitações iniciam-se com os usuários apenas após a homologação da migração.

No caso de atrasos no cronograma proposto, por problemas na etapa de migração dos dados e o não comprometimento da CONTRATADA na busca de soluções, a Comissão Especial de Avaliação resguarda- se no direito de não emitir o Termo de Liberação para Pagamento até a respectiva normalização dos serviços, sem prejuízos legais ao município.

DAS ADAPTAÇÕES E EVOLUÇÕES DO SRES

A empresa fornecedora do SRES deve durante toda vigência do contrato ofertar serviço de adaptação e evolução do software, a ser usado sob demanda da Secretaria de Saúde, considerando as seguintes rotinas:

ADAPTAÇÕES LEGAIS

Serão sempre motivadas por alterações na legislação municipal, estadual ou federal. O prazo para desenvolvimento sempre será o prazo de vigência da referida legislação.

Sempre que for inviável o desenvolvimento em período hábil, a empresa fornecedora do SRES deverá oficializar este posicionamento de forma fundamentada junto a administração municipal e, negociar prazo para adequação.

Legislações não contempladas pelo preâmbulo deste termo de referência, não serão consideradas adaptações legais.

DEMAIS ADAPTAÇÕES E EVOLUÇÕES

Entende-se por adaptação qualquer ajuste desejado em uma rotina existente do sistema para promover melhor aderência aos processos de negócio da Secretaria de Saúde.

Entende-se por evolução, a criação de nova funcionalidade no SRES, não prevista no edital. Considera-se que após criada, a evolução passa a ser tratada como qualquer item do edital, no tocante a disponibilidade.

Nenhuma adaptação ou evolução serão consideradas como exigência para a implantação.

Uma vez iniciado o processo de implantação, a qualquer momento poderão ser levantadas necessidades de adaptação e evolução do sistema. Todas as ocorrências em que se identifique tal necessidade, serão formalmente registradas junto a empresa fornecedora do SRES, que deverá fornecer orçamento para consumo das horas de adaptação / evolução, conforme descrito no item ‘DAS PROPOSTAS COMERCIAIS’.

Neste item enquadram-se somente alterações que não esteja inclusas no item ‘ADAPTAÇÕES LEGAIS’.

Todas as customizações, adaptações e evoluções deverão utilizar as horas previstas para esta finalidade, neste edital, mediante autorização escrita da gestão.

Os serviços de adaptação e evolução, quando autorizados, deverão ser realizados pela CONTRATADA conforme calendário de constante em orçamento.

Os serviços de adaptação e evolução não devem, sob nenhum pretexto impactar no cronograma de cada fase do projeto, a ser detalhado no momento da assinatura do contrato, respeitando os prazos do cronograma físico-financeiro.

DO LICENCIAMENTO DO SRES

O SRES alvo deste processo aquisitivo consiste em fornecimento, pelo tempo que durar o contrato, na cessão do direito de uso do SRES pela secretaria de saúde, assim como todos seus entes, conveniados e contratados. Nesta licença não deverão haver restrições quanto ao número de usuários, estações de trabalho, ou unidades de atendimento que utilizarão o SOFTWARE, sendo também facultativo a municipalidade disponibilizar o mesmo a todos seus prestadores de serviço e municípios contratualizados, de forma a gerir todos os serviços prestados, direta ou indiretamente, não sendo permitida 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. Sempre haverá entendimento claro de que esta variação é automaticamente licenciada e, não implica em ônus a municipalidade.

DAS GARANTIAS

Caberá a empresa fornecedora do SRES manter durante toda vigência contratual, a aplicação em perfeitas condições de uso, identificando e corrigindo eventuais falhas que se apresentem neste período.

Para falhas, bugs e incidentes descobertos por esta secretaria de saúde, deve-se aplicar o seguinte acordo de nível de serviço:

INCIDENTES 01: Caracterizam-se por defeitos que impedem o uso do sistema e requerem início imediato no atendimento após o registro da ocorrência. Estes eventos devem ser atendidos com prontidão pela empresa fornecedora do SRES. O prazo para início do atendimento será de 30 minutos a contar da abertura do chamado pela empresa contratada. Devido à urgência deste tipo de chamado, a comunicação deverá ser feita sempre por telefone, de modo a garantir a imediata ciência da empresa fornecedora do SRES.

INCIDENTES 02: Esta tipificação será usada em situações em que o atendimento ao público é comprometido sem que haja maneira de contornar o problema. Neste cenário a Secretaria de Saúde fará notificação a empresa fornecedora do SRES por telefone e o início do atendimento não deverá ser posterior a 3 horas da abertura do chamado.

INCIDENTES 03: Caracterizarão incidentes deste tipo, casos em que o atendimento ao público é comprometido mas, existe alguma forma de contorno paliativo. O registro deste tipo de incidente pode ser

feito diretamente no sistema de chamados eletrônico da CONTRATADA e, o atendimento deve iniciar-se em até 1 dia útil.

INCIDENTES 04: Trata de problemas ou vícios em telas que não envolvem atendimento ao público mas, que geram impacto em produtividade dos colaboradores. Problemas relacionados a erros em recursos não funcionais, problemas de performance e outros em que não haja prejuízo iminente para a CONTRATANTE. O atendimento deve ser iniciado em até 5 dias úteis.

DOS CANAIS DE COMUNICAÇÃO

O registro de chamados de prioridade vermelho e alaranjado deve ser feito pela Secretaria de Saúde, através do acionamento dos canais de suporte interativos da empresa fornecedora do SRES. É fundamental que haja garantia da imediata ciência da empresa para que se inicie a contagem do prazo.

O prazo para atendimento passa a conta a partir do horário do registro da ocorrência.

Este acordo de prazos é válido unicamente para incidentes, não se aplicando a adaptações e evoluções.

DA MANUTENÇÃO E DO SUPORTE

O serviço de manutenção corretiva, adaptativa e evolutiva relacionado na definição do objeto é obrigação da empresa fornecedora do SRES visando manter o sistema em perfeito funcionamento durante toda vigência contratual.

Será pago à CONTRATADA mensalmente, o valor referente ao fornecimento de manutenção legal, corretiva e suporte técnico.

Manutenções que envolvam customização, adaptação ou evolução, serão pagas sob demanda.

DAS MANUTENÇÕES

Entende-se por ‘manutenção corretiva’ todas aquelas adequações que forem necessárias para o reparo de imperfeições ou falhas no sistema aplicativo que o impeça de funcionar adequadamente. Este tipo de manutenção engloba os incidentes e, não deve sob nenhuma hipótese consumir horas relativas a customização, adaptação ou evolução.

Entende-se por ‘manutenção legal’, 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. Este cenário não aceitará também consumo de horas previstas para customização, adaptação ou evolução. Os prazos referentes a estas demandas serão sempre os previstos na legislação, salvo os da legislação municipal, que serão acordados, caso a caso entre as partes.

Entende-se por ‘manutenção evolutiva’ aquelas manutenções que visem a implementação de novas funcionalidades à solução, ou ainda a evolução das funcionalidades existentes, a fim atender novas demandas percebidas ao longo do processo de uso do sistema, desde que não estejam compreendidas como manutenção legal. Estas demandas deverão consumir as horas previstas para adaptação e evolução, conforme termos editalícios.

Os serviços de manutenção corretiva, manutenção legal e manutenção evolutiva serão prestados durante toda a vigência contratual, sem exceções.

DO SUPORTE

Entende-se por suporte técnico, o atendimento em segundo nível pela empresa fornecedora do sres aos técnicos da Secretaria de Saúde. Este atendimento deve ser garantido durante toda vigência contratual.

O suporte técnico deverá ser disponibilizado de segunda a sexta-feira, das 8 às 18 horas, excetuando-se feriados municipais, estaduais ou federais, nas localidades das partes.

Deverá ser disponibilizado, pela empresa fornecedora do SRES equipe para suporte, correção de erros e atendimento de dúvidas, sempre restrito à 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, respeitando os horários descritos.

Haverá suporte ininterrupto, 24 horas por dia, 7 dias por semana, exclusivamente para atendimento a incidentes, durante toda vigência contratual.

Haverá ainda a necessidade de que a CONTRATADA disponibilize um gerente de projetos para acompanhar o projeto de implantação, conforme cronograma definido.

DO REGISTRO DE SOLICITAÇÕES

A empresa fornecedora do SRES deverá ofertar sistema de atendimento tipo helpdesk, para registro dos chamados técnicos. Todos os técnicos da Secretaria de Saúde devem possuir acesso através de login pessoal. Todas as solicitações feitas pela Secretaria de Saúde devem ser registradas no sistema de helpdesk para que inicie-se a contagem do prazo de atendimento.

O atendimento de chamados cujo prazo não seja descrito em casos anteriores deve iniciar-se em até 4 dias úteis a contar da abertura dos mesmos.

A comunicação entre a empresa fornecedora do SRES e a Secretaria de Saúde deverá ser documentada via software disponibilizado pela empresa fornecedora do SRES. Esta regra serve para todos os chamados, devendo utilizar os tempos estipulados neste documento.

Em chamados de prioridade vermelho ou alaranjado (apenas para incidentes) dentro ou fora do horário de expediente, ou ainda em caso de indisponibilidade do software disponibilizado pela empresa, a contratante deverá ser atendida via telefone, skype, comunicador ou outro meio síncrono de comunicação.

Todos os atendimentos prestados pela empresa fornecedora do SRES devem estar registrados em chamados, contendo minimamente a solicitação inicial, data de abertura, solicitante, técnico responsável da empresa fornecedora do SRES, status, desfecho e data de encerramento.

Os chamados serão abertos no software de chamados fornecido pela empresa fornecedora do SRES e o seu recebimento pela empresa deverá ser confirmado com a alteração da situação da solicitação no próprio software, a qual poderá ser consultada pelo histórico da mesma. Os itens abaixo deverão ser inseridos no histórico pela contratada:

número do chamado – objetivando a identificação única do mesmo; data e hora de abertura;

tipo de solicitação (se é o registro de um incidente, manutenção legal, adaptativa, evolutiva, ou outro);

status do chamado (indica se o mesmo foi registrado pela CONTRATADA, acatado pela contratante, encontra-se em produção, em fila, aguardando aprovação de proposta comercial, aguardando liberação de versão, aguardando validação pela CONTRATANTE ou concluído);

técnico da CONTRATADA responsável pelo acompanhamento do chamado.

COMUNICAÇÕES ALTERNATIVAS

Todas as comunicações que não caracterizarem chamados, devem ser feitas preferencialmente via e-mail, através dos endereços que devem ser fornecidos pela empresa fornecedora do SRES na elaboração do plano de implantação. As comunicações feitas por e-mail não estão sujeitas aos prazos estabelecidos para os chamados.

DAS PROPOSTAS COMERCIAIS

Para os chamados que consumirão as horas previstas para customização, adaptação ou evolução, a proposta comercial apresentada pela contratada deve apresentar, de forma organizada, em língua portuguesa, minimamente as seguintes informações:

Solicitação recebida (de forma integral);

História de usuário (resumo que será usado para contextualizar a alteração); Principais alterações a serem feitas no SRES para atendimento da demanda;

Estimativa de horas que serão usadas para atender a solicitação (neste item devem ser computadas as horas necessárias para treinamento e entrega da alteração);

Valor do orçamento (conforme valor da hora, constante em contrato); Prazo para aprovação do orçamento;

Prazo para entrega da solicitação;

Fica ciente a empresa fornecedora do SRES que não devem ser cobradas horas técnicas adicionais para sanar falhas ou vícios em relação as propostas comerciais previamente aprovadas.

Da mesma forma, fica a empresa ciente que, em caso de solicitações que gerem soluções não aderentes a real necessidade e que, posteriormente a entrega precisem ainda de novos ajustes, deverão ser tratadas como novas evoluções/ adaptações.

Caso a proposta comercial não seja aprovada, o chamado vinculado deve ser encerrado sem que seja executada a alteração.

Caso a proposta comercial não seja respondida em 30 dias, deve ser considerada não aprovada.

Se não houver acordo entre a contratada e a contratante sobre a especificação do orçamento enviado, a contratante poderá solicitar uma reunião online para esclarecimentos e ajustes no orçamento. A reunião será realizada em horário designado pelas partes, sem ônus a nenhum dos envolvidos.

DO AMBIENTE DE TREINAMENTO

Dada a criticidade dos dados contidos no SRES, deverá ser mantido em funcionamento, durante toda vigência contratual, ambiente para treinamento de usuários, assim como homologação de versões e testes, a ser instalado na infraestrutura disponível, visando garantir que em produção apenas sejam feitos registros de fato reais.

DAS ATUALIZAÇÕES

Visando manter as regras de negócio sempre atualizadas e aderentes a legislação, caberá a empresa fornecedora do SRES disponibilizar de forma organizada um calendário de atualizações, junto ao cronograma de implantação.

As atualizações devem ser feitas sempre em horário agendado, com autorização prévia do gestor e, em janela de manutenção programada.

Em caso de resolução de incidentes vermelhos, é necessário obter autorização do gestor para realizar atualização do SRES, caso não seja possível apenas corrigir o problema sem trocar a versão.

A empresa fornecedora do SRES pode solicitar a imediata reversão da atualização do sistema, caso sejam constatadas falhas de alta criticidade que já tenham sido resolvidas pela mesma.

A empresa fornecedora do SRES deve informar à Secretaria de Saúde todas as solicitações atendidas com a atualização bem como as configurações necessárias para o funcionamento do sistema após a atualização, através de ferramenta administrativa, dentro da própria solução.

A empresa fornecedora do SRES deverá estar ciente em que se tratando de serviços de saúde, toda e qualquer atualização, será ordinariamente realizada fora dos horários comerciais e em finais de semana, conforme previamente determinado pela Secretaria de Saúde, e sem qualquer tipo de ônus para o município. No entanto, todas as configurações necessárias para o funcionamento do sistema devem ser informadas dentro do horário de funcionamento da CONTRATANTE, seguindo o prazo mínimo estipulado nas cláusulas anteriores.

A CONTRATANTE deverá aprovar as solicitações atendidas em ambiente de homologação para liberar o envio à produção. Caso as solicitações atendidas aprovadas pela contratante apresentarem problemas em homologação, os mesmos devem ser resolvidos antes da implantação em produção da referida versão.

DAS CAPACITAÇÕES E TREINAMENTOS

A empresa deverá disponibiliz um técnico ou analista para auxiliar no processo de implantação, conforme calendário definido entre as partes, cobrando para tal o valor diário previsto para atendimento in loco, conforme cronograma.

Durante a implantação deverão ser desenvolvidas as atividades de consultoria técnica nas dependências da Secretaria Municipal de Saúde, minimamente contemplando:

POR PARTE DA SECRETARIA DE SAÚDE:

Avaliação dos técnicos da CONTRATADA envolvidos nos treinamentos e capacitações; Definição dos objetivos a serem alcançados a cada treinamento ou capacitação;

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

Disponibilização de equipe técnica para acompanhar e avaliar todos os treinamentos fornecidos;

Disponibilizar salas de treinamento, com computadores e infraestrutura adequada para realização dos treinamentos e capacitações.

POR PARTE DA CONTRATADA

Apresentar cronograma de treinamento para compor o plano de implantação;

Executar os treinamentos e capacitações de maneira adequada, segundo o plano de implantação e, garantir que haja de fato transmissão do conhecimento.

DA AVALIAÇÃO DE ATENDIMENTO AS EXIGÊNCIAS EDITALÍCIAS

Finda a parte processual do processo licitatório, a empresa vencedora será submetida a avaliação de atendimento às exigências editalícias. Esta avaliação considerará todos os requisitos funcionais e não funcionais descritos como requeridos no item ‘CARACTERÍSTICAS TÉCNICAS OBRIGATÓRIAS’ do Anexo II.

Caberá a Secretaria Municipal da Saúde publicar em diário oficial, data, local e horário para início da prova de conceito.

A prova de conceito deve iniciar-se em até 10 dias úteis após a sagração da empresa provisoriamente declarada vencedora.

Na ocasião da realização da prova de conceito, em data, horário e local a serem estipulados pela Secretaria de Saúde, deve-se realizar a leitura da ata que sagra vencedora provisória a proponente, justificando assim sua participação nesta avaliação.

Após a leitura, deve haver a apresentação formal da comissão especial de avaliação, apresentando cada membro e sua respectiva função e, por fim, iniciar-se a prova de conceito, conforme o seguinte rito:

Leitura do item em voz alta, por um membro da comissão; Apresentação do item pela empresa vencedora provisória;

A comissão deve proceder votação individual sobre a aderência ou não do item apresentado e, em caso de não aprovação, explanação da justificativa.

O item será considerado aprovado caso obtenha maioria simples dos votos da comissão (50% + 1)

O presidente somente manifestará seu voto em caso de empate, quando seu voto resolverá o impasse.

Os itens devem ser apresentados de maneira sequencial, iniciando-se no primeiro e seguindo-se ordenadamente até o último, sem que seja permitido retroceder na apresentação.

Será permitido à vencedora provisória, após a avaliação de um item não aprovado, uma segunda tentativa, visando garantir que em caso de algum entendimento que a empresa tenha tido em divergência com a comissão especial de avaliação seja sanado de imediato.

Durante a prova de conceito, deverão ser avaliados todos os itens (sem exceção) assinalados como requeridos no descritivo técnico.

Informa-se que toda a estrutura (software e hardware) necessários para a apresentação do SOFTWARE e realização da avaliação são de responsabilidade da empresa concorrente.

O município disponibilizará para a apresentação os seguintes itens:

Ponto de energia elétrica (110V ou 220V);

Um ponto de acesso a rede cabeado, sem bloqueios ou restrições; Mesa e cadeiras para uso na apresentação.

Demais itens que se façam necessários, devem ser providenciados pela proponente.

Em casos de completa impossibilidade de realização da prova de conceito por motivos alheios aos citados (falta de energia, por exemplo), a prova será suspensa e transferida para o próximo dia útil caso a situação que a impeça dure um período maior que 30 minutos.

Finda a apresentação de todos os itens, fica facultado a empresa reapresentar imediatamente itens que foram reprovados, visando garantir a empresa a oportunidade de corrigir eventuais falhas ou ainda, prover pequenas adaptações na solução ofertada, diante da explicitação do motivo do não atendimento. A apresentação dos itens reprovados deve ser feita somente mediante solicitação da empresa, que a fará diretamente a comissão especial. A reapresentação dos itens será iniciada imediatamente após a apresentação do último item e, seguirá as mesmas regras da apresentação.

A vencedora provisória será confirmada mediante a aceitação pela comissão de 85% (oitenta e cinco por cento) dos itens apresentados (desconsideradas as casas decimais sem arredondamento).

Caso a empresa tenha aprovação de mais de 75% (setenta e cinco por cento) dos itens, a mesma terá direito a uma segunda avaliação, que deve se realizar em 20 dias úteis após a publicação do resultado da primeira avaliação. Caso este evento ocorra, no mesmo deverão ser apresentados apenas os itens reprovados no primeiro evento, segundo rito da avaliação. Na segunda avaliação, a empresa deverá atingir o atendimento de minimamente 85% (oitenta e cinco por cento) dos itens previstos para a prova de conceito.

Na ocorrência de, após a segunda avaliação a empresa não atingir o índice de aprovação a mesma será declinada da condição de vencedora provisória e deverá ser convocada a segunda colocada, conforme termos editalícios.

Caso a vencedora provisória apresente índice final de aprovação inferior a 50%, a mesma deverá ser inscrita no cadastro de empresas inidôneas para contratar com a administração pública.

DO PROJETO DE IMPLANTAÇÃO

Após a assinatura do contrato, em até 20 dias úteis, a vencedora do certame deverá:

Disponibilizar instalados e prontos para uso todos os softwares necessários para o completo uso da ferramenta, fornecendo endereços de acesso, login e senha com permissões administrativas.

Desenvolver, com auxílio da gestão da Secretaria de Saúde, o projeto de implantação. A gestão do projeto deverá ser executada por profissionais da empresa fornecedora do SRES, devidamente 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. O projeto não poderá ter prazo de execução superior a 6 meses após a assinatura do contrato.

Caberá ao presidente da comissão especial de avaliação o ateste do aceite da execução do projeto, assim como o acompanhamento e fiscalização de sua execução, sempre apoiado pela comissão especial.

DO TERMO DE ACEITE FINAL

No ato da entrega do projeto de implantação, a comissão especial de avaliação emitirá termo de aceite final, considerando finda a implantação do sistema, iniciando-se a fase de execução do mesmo.

ANEXO II – CARACTERÍSTICAS TÉCNICAS OBRIGATÓRIAS

Consideram-se obrigatórias todas as características aqui apresentadas e, ressalta-se que qualquer uma destas características pode, a critério da comissão de avaliação, ser demonstrada no teste de conformidade sem prévio aviso.

Em consideração aos itens que são considerados obrigatórios, mas não compõem a prova de conceito, informa-se que a proponente que não cumprir integralmente os itens aqui expostos, será considerada inapta e consequentemente, deve ser desclassificada do ato licitatório.

Requisitos não funcionais

Neste ponto, descreve-se todas as características relativas a desempenho, arquitetura, usabilidade, disponibilidade e tecnologias envolvidas que o SOFTWARE deve apresentar.

Pode ser dividido em módulos, desde que haja total e irrestrita integração entre os mesmos, em tempo real, sem necessidade de ações por parte dos usuários, excetuando-se as aplicações complementares (devidamente qualificadas nos requisitos funcionais).

Deve possuir arquitetura voltada para web, sendo inadmissível o uso de qualquer forma de emulação, por mais tecnicamente vantajosa, excetuando-se os recursos ‘Interfaceamento laboratorial’, ‘PACs’ e ‘BIOMETRIA para os quais a solução WEB não tem recursos que não dependam de alguma instalação local, dada a necessidade de manipulação dos equipamentos laboratoriais, de imagem e de biometria.

Deve ser executado em servidores centralizados, permitindo o uso de balanceadores de carga (proxy reverso), com distribuição de carga inteligente, sem que seja necessária a fixação do acesso em um único servidor, de modo a garantir alta disponibilidade.

Deve ser executado em servidor web (Apache, Nginx, Xampp, THTTPD, IIS ou outro) sem emulação de nenhum tipo.

Não será permitida a instalação de nenhum plugin, extensão, ou qualquer outra aplicação, além do navegador (Google Chrome ou Firefox) para que o SOFTWARE seja utilizável (excetuando-se aplicações de interfaceamento, PACs e biometria, conforme descrito anteriormente.

A solução ofertada deve ser compatível com os navegadores Mozilla Firefox e Google Chrome, minimamente em suas versões atuais em toda vigência do contrato.

Deve trabalhar utilizando minimamente 3 camadas (apresentação, negócio e dados) minimamente com as seguintes características: a camada de apresentação deve possuir todas as principais regras de negócio, evitando que o operador cometa erros em tela e os perceba somente ao salvar o registro; a camada de negócios deve conter todas as regras de negócio, garantindo que os dados sejam persistidos apenas quando estiverem de acordo com as regras definidas na aplicação; a camada de dados pode ou não conter validação adicional de regras de negócio, mas precisa garantir através de características próprias a manutenção da integridade referencial.

Deve utilizar de banco de dados de código aberto, com minimamente as seguintes características: possuir todas as características de um sistema gerenciador de bancos de dados relacional; possuir controle de concorrência multi-versão; permitir indexação; não possuir limitação em relação ao tamanho do banco de dados; não possuir limitação em relação ao número de acessos ou transações (limitado a capacidade dos servidores); permitir minimamente 30 TB por tabela em sua estrutura; permitir número ilimitado de linhas em uma tabela; não limitar o número de índices; permitir rotina de backup íntegro e/ou incremental, sem impactos em performance e, com garantia de integridade de dados em um momento específico; permitir o uso de replicação para garantir alta disponibilidade; permitir o uso de pool para gerenciamento de conexões, de modo a garantir melhor uso do hardware, aumentando a performance; permitir o uso de cache para acesso rápido a dados com alto consumo; permitir uso de objetos espaciais, como pontos, linhas, segmentos, polígonos, sem uso de artifícios não nativos ao banco de dados; exigir o tráfego com uso de criptografia entre os servidores de aplicação e as estações (https) e entre os servidores de aplicação e o banco de dados, visando evitar o sequestro de informações que trafegam em rede (para criptografia, deve ser possível usar certificados emitidos pelo letsencrypt ou outra fonte gratuita e confiável); garantia de atomicidade das transações; garantia de consistência dos dados, através da execução de transações isoladas; garantia de isolamento das transações, de modo que cada transação ocorra sem necessidade de conhecimento de outras;

permitir o uso de particionamento dos bancos de dados, permitindo armazenamento em diversos discos rígidos ligados ao servidor, visando melhorar a performance e segurança; todos os recursos administrativos (usuários, grupos de acesso, partições de dados, e outros) relativos ao banco de dados não devem possuir limitações; 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; 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); o banco de dados adotado deve possuir mecanismo para cópias de segurança online permitindo sua restauração point-in-time, que refletirá exatamente o mesmo ambiente do momento em que o mesmo foi realizado; deve suportar minimamente índices b-tree, hash, gist, spgist, gin, e brin, permitindo a melhor escolha para cada situação; deve ser baseado em arquitetura TOAST (The Oversized-Attribute Storage Technique); 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;

Não é vetado neste pleito, o uso de banco de dados que não seja de código livre, devendo-se neste caso, obedecer as seguintes imposições: 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 de modo permanente (inclusive após a rescisão contratual); 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, sejam estas limitações referentes ao número de usuários, acessos, volume de dados, ou quaisquer outras; caso o banco de dados a ser utilizado seja proprietário, suas licenças deverão ser adquiridas em nome da contratante e obrigatoriamente ser protocoladas no setor de protocolos do município e endereçadas ao presidente da comissão especial de avaliação, em via original; caso os documentos possuam assinatura eletrônica, deve-se obter cópia autenticada em cartório para realização do protocolo, garantindo assim o valor legal da mesma.

A solução ofertada deverá ser instalada e executada no ambiente tecnológico fornecido pela contratante, o qual deverá ter toda infra-estrutura necessária para o bom funcionamento es os backups de segurança. .

Não serão admitidas licenças parciais ou que apresentem qualquer tipo de restrição de funcionalidade em relação a versão mais completa do produto licenciado.

O SOFTWARE deverá ser desenvolvido integralmente para uso em navegadores, através do protocolo HTTP ou similar, sem emulação ou adaptação de nenhum tipo, sendo executado em servidor WEB nativo.

A instalação do software deve ser feita em sistema operacional LINUX ou WINDOWS, ficando o mesmo a escolha da empresa fornecedora do SRES.

Caso o sistema operacional ou qualquer outra aplicação necessária para o pleno e correto funcionamento da ferramenta possua licença comercial, a mesma deverá ser adquirida em nome desta municipalidade, sempre em sua versão mais abrangente, de modo a garantir que o município não tenha limitações de acesso, tamanho, recurso, ou qualquer outra que seja imputável pela aquisição parcial da instalação.

Todas as licenças deverão obrigatoriamente ser adquiridas em nome do município e protocoladas no setor de protocolos do município e endereçadas ao presidente da comissão especial de avaliação, em via original. Caso os documentos possuam assinatura eletrônica, deve-se obter cópia autenticada em cartório para realização do protocolo, garantindo assim o valor legal da mesma.

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.

É responsabilidade única e exclusiva da CONTRATADA fornecer a licença de uso do software, e também qualquer programa, plataforma, sistema operacional e outros necessários ao funcionamento de qualquer módulo da solução ofertada, em caso de necessidade de licença proprietária, em nome do município, sem custos adicionais;

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.

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.

Em relação a certificação digital, deve-se observar:

A solução ofertada deve possuir mecanismo de assinatura digital de registro eletrônico em saúde certificado de acordo com o Manual de Certificação para S-RES v4.2 (Edição 2016) SBIS/CFM (Sociedade Brasileira de Informática em Saúde / Conselho Federal de Medicina) certificado nos Requisitos do Nível de Garantia de Segurança 2 (NGS2).

Os componentes do módulo devem estar aderentes ao DOC-ICP-155, da ICP-Brasil, que trata sobre a normalização de assinatura digital, para o padrão de “assinatura digital com referências básicas (AD-RB)”, sendo recomendado a utilização do padrão de “assinatura digital com referências para validação (AD-RV), com os objetos referenciados estando no domínio da instituição, ou padrão de “assinatura digital com referências completas (AD-RC)”.

Todas as funcionalidades do módulo devem ser disponibilizadas em componentes modulares distintos, que permitam assinar, validar as assinaturas digitais, verificar e validar certificados no momento da assinatura.

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

Deve dispor de assinador para geração de assinatura digital em documentos eletrônicos;

Deve dispor de verificador para averiguar a validade de assinatura digital em documentos eletrônicos;

Deve dispor de validador para verificar validade de certificado digital e sua correspondente cadeia de certificação;

Deve gerar assinaturas simples, coassinaturas e contra-assinaturas no padrão CMS Advanced Eletronic Signature - CAdES de acordo com o DOC-ICP 15.03.

Deve gerar assinatura digital seguindo todas as políticas de assinatura definidas pela ICP-Brasil no DOC- ICP 15.03.

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

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

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

Deve armazenar e alertar ao usuário sobre pendências, possibilitando a este assinar em momento futuro os documentos não assinados no momento do atendimento.

Deve possuir tela de gerenciamento para gestores, para verificação de documentos pendentes de assinaturas e seus respectivos responsáveis.

Deve permitir ao profissional a possibilidade de visualizar o documento antes de sua assinatura.

Deve permitir ao profissional selecionar em sua lista de pendências e assinar vários documentos de uma mesma vez.

Requisitos funcionais e regras de negócio

Neste ponto, descrevem-se todas as características relativas a recursos e características operacionais que o SOFTWARE deve apresentar.

Os requisitos funcionais, foram divididos em eixos organizacionais, para facilitar à gestão municipal a agregação dos recursos que esperasse obter com esta contratação. Importante ressaltar neste ponto que, a organização segue o modelo organizacional deste município e, não obrigatoriamente deve ser seguido em

sua organização no software apresentado. Caberá, contudo a empresa vencedora garantir que as funcionalidades e recursos sejam apresentados nesta ordem, visando organizar a avaliação de conformidade.

Todos os itens apresentados na tabela de requisitos funcionais, serão classificados com tipos e prazos relatados em cada seção:

Tipo: Requerido para a prova de conceito Eixo técnico

Engloba itens de segurança, de interoperabilidade e, trata de integrações com sistemas federais e demais pontos que trabalham a interoperabilidade.

1) a partir do FTP, sem que seja necessário baixar os arquivos de dados, importando todos os dados deste sistema, garantindo ainda que haja histórico e versionamento de todas as importações realizadas. Esta integração deve ser disponível durante toda a duração do contrato;

2) Deve ser possível cadastrar perfis de acesso para uso coletivo e, garantir que estes perfis possam ser configuráveis em relação às suas permissões de acesso a cada recurso do sistema, permitindo minimamente garantir que um perfil possa ou não acessar um determinado recurso, com privilégios para inclusão, edição e exclusão;

3) Deve ser possível cadastrar intervalos de acesso para vinculação a usuários de sistema em cada equipamento de saúde que o mesmo tenha acesso, restringindo assim o acesso ao sistema ao seu horário de trabalho. Caso não seja vinculado nenhum intervalo para a equipamento de saúde e usuário não haverá restrição de horários para o acesso ao sistema;

4) O SRES deve obedecer a norma do SBIS que determina que os operadores não podem se auto conceder permissões (NGS1.04.06);

5) O SRES deve permitir que operadores recebam acesso às unidades de saúde que sejam necessárias para o desempenho de suas atividades, vetando ou não o acesso às demais unidades;

6) As senhas devem ter sua complexidade em conformidade mínima com as normas do SBIS, definindo o nível de complexidade das senhas, os tipos de caracteres (letras maiúsculas, minúsculas números e caracteres especiais) são exigidos e o comprimento mínimo e máximo da senha;

7) Todas as alterações realizadas no sistema devem ser auditáveis;

8) Todos os acessos à tela no sistema devem ser auditáveis. O simples fato de entrar em uma tela, mesmo que não seja feita alteração deve ser registrado em log;

9) O log deve permitir que todas as informações alteradas, inseridas ou excluídas sejam rastreadas;

10) A personalização de relatórios deve ser possível a técnicos da Secretaria de Saúde;

11) Todos os relatórios da solução devem ser gerados minimamente nos formatos texto, p.f., c.v. (excetuam-se a esta regra todos os documentos que devem ser gerados com garantia de integridade do conteúdo ou que devam ser assinados eletronicamente (cópias de prontuário, laudos de exames, fichas clínicas, e outros desta mesma natureza), que devem ser gerados unicamente em PDF ou outro formato que aceite a assinatura eletrônica, garantindo a validade da informação);

12) O SRES deve disponibilizar ao usuário recursos de informação sobre o que um botão, menu ou ícone faz ao posicionar o cursor sobre ele;

13) Xxxx exibir mensagens de advertência ou erro informando ao usuário um determinado risco ao executar funções solicitando sua confirmação;

14) Deve possuir cadastro de cidadãos totalmente compatível com o Cartão Nacional de Saúde;

15) Deve possuir em sua estrutura o CBO (Classificação Brasileira de Ocupações), com todos os níveis hierárquicos, conforme padrão federal;

16) Possuir cadastro de municípios compatível com os dados do IBGE;

17) Possuir cadastro de estabelecimentos de saúde e suas mantenedoras, em formato compatível com o SCNES;

18) Possuir cadastro de bairros, logradouros, tipo de logradouro (compatível com cartão nacional de saúde) e vinculação de bairros e logradouros;

19) Deve permitir o cadastro de cidadãos sem endereço fixo, registrando o motivo da ausência do endereço (o motivo deve ser cadastrável);

20) Deve permitir a inativação de cadastros de cidadãos, identificando o motivo da inativação (o motivo deve ser cadastrável);

21) Deve permitir registro biométrico para identificação inequívoca dos cidadãos, evitando registro em homônimos.

22) O SRES deve permitir, no cadastro do cidadão, que haja controle histórico de todos os telefones fornecidos pelo mesmo para que se possa manter o histórico de contatos possíveis, não sendo necessário excluir um telefone do histórico do cidadão para inserir um novo;

23) Deve ser possível, no cadastro dos cidadãos, registrar documentos das unidades, informando a unidade que possui o documento e o número do mesmo, minimamente;

24) Deve ser possível cadastrar deficiências para o cidadão (as deficiências devem ser cadastráveis);

25) Deve ser possível armazenar imagem (fotografia) do cidadão em seu cadastro;

26) Deve ser possível unificar cadastros duplos encontrados no sistema, através de ferramenta administrativa. Este recurso deve unificar além do cadastro, todo o histórico de atendimentos dos mesmos;

27) Deve haver no sistema ferramenta para identificação em lote de possíveis cadastros duplos, para que seja feito processamento da unificação em lote ou análise de cada registro localizado;

28) Deve possuir mecanismo para desativação de logradouros cadastrados incorretamente, migrando todos os pacientes do logradouro incorreto para o logradouro correto;

29) Deve possuir mecanismo para desativação de bairros cadastrados incorretamente migrando todos os pacientes cadastrados no bairro incorreto para o bairro correto;

30) Deve ser possível emitir via impressa do cartão do munícipe conforme layout definido pela Secretaria de Saúde, utilizando-se de impressora térmica, através de linguagem EPL / PPLB;

31) Deve ser possível cadastrar Declarações de Nascido Vivo no sistema, com todos os dados existentes na ficha de Declaração de Nascidos Vivos fornecida pelo Ministério da Saúde;

32) Deve possuir funcionalidade de registro das impressões digitais do paciente, através de leitura biométrica, permitindo ao operador identificar o dedo que está sendo registrado;

33) Deve ser possível ao gestor, através de ferramenta administrativa, definir quais campos do cadastro do cidadão deverão ser requeridos para que um cidadão seja cadastrado;

34) Deve ser possível, no tocante ao item R.F.37, definir a quais unidades de saúde serão aplicadas cada regra criada. (Ex.: tornar obrigatório o registro do cartão nacional de saúde em todas as unidades de atendimento;

35) Deve ser possível ao gestor, através de ferramenta administrativa, definir quais campos do cadastro do cidadão gerarão alerta sobre possível duplicidade cadastral, a fim de auxiliar na redução do número de cadastros duplos;

36) Deve ser possível ao gestor, através de ferramenta administrativa, impedir que sejam cadastrados vários cidadãos com informações iguais, minimamente para os campos de documentos (CPF, CNS, Identidade e outros);

37) Deve conter cadastro de termos inválidos para cadastro de cidadãos, contendo minimamente os termos inválidos constantes no manual de integração do Barramento SOA CADSUS PIX/PDQ;

38) Deve haver no sistema mecanismo para georreferenciamento dos cidadãos, usando para tal, o endereço dos mesmos;

39) AGENDAMENTO DE CONSULTAS

40) Contempla recursos administrativos envolvidos no processo de gestão das agendas profissionais, a serem usadas tanto nas unidades básicas de saúde, quanto nos serviços especializados próprios e terceirizados.

41) Deve ser possível realizar o cadastro das especialidades e o vínculo das mesmas com as ocupações do CBO diretamente ou então por família de CBO (esta exigência ocorre, devido ao uso comum de subespecialidades no tratamento rotineiro das especialidades médicas, tais como ortopedistas especialistas em joelho, ou oftalmologistas especializados em glaucoma, endocrinologistas especializados em diabetes mellitus). Deve ainda possuir forma de organizar as especialidades em categorias, de forma a auxiliar o agrupamento de informações em relatórios;

42) Deve ser possível realizar o cadastro de protocolos de agendamento configuráveis pela Secretaria de Saúde, através de ferramenta administrativa;

43) Deve ser possível realizar a emissão de fichas de atendimento, em layout definido pela Secretaria de Saúde. Esta ficha será usada como alternativa ao prontuário eletrônico quando for inviável seu uso, por qualquer motivo.

44) O SRE deve possuir configuração de cronogramas altamente flexível, permitindo que as agendas sejam montadas, minimamente para os seguintes cenários:

45) Agendamentos por horário (cada atendimento tem uma duração pré-determinada, e as consultas são agendadas a cada N minutos). Nesta modalidade, existe um número de vagas delimitado para atendimento;

46) Agendamentos por ordem (de agendamento ou de chegada para atendimento);

47) Deve-se permitir o cadastro de cotas por unidade de destino, período de vigência e especialidade, sendo possível vincular as unidades de origem com suas quantidades ou percentuais;

48) Deve possibilitar configurar para cada cronograma a quantidade de vagas para agendas normais, encaixes e retornos;

49) Deve possibilitar configurar para cada cronograma os dias para visualização retroativas e/ou a frente para as vagas disponíveis;

50) Deve ser possível selecionar no equipamento se o profissional registrado para a ocupação poderá utilizar a agenda;

51) Deve haver no sistema, rotina para exibir todos os profissionais que possuem agenda em todas as especialidades disponíveis, conforme o controle de cotas;

52) A tela de agenda deve disponibilizar minimamente os seguintes filtros:

53) Unidade destino do paciente;

54) Especialidade;

55) Profissional;

56) Cidadão;

57) Deve haver, na agenda, minimamente separação dos pacientes nas seguintes listas (ou formas equivalentes que explicitem as informações em questão):

58) Pacientes que já foram agendados, mas ainda não estão no local de atendimento;

59) Pacientes que estavam agendados e já se apresentaram no local de atendimento e, aguardam pela chamada do profissional;

60) Pacientes em processo de acolhimento;

61) Pacientes acolhidos;

62) Pacientes em atendimento;

63) Pacientes atendidos;

64) Classificação de risco do paciente (feita através do prontuário eletrônico do SRES);

65) Pacientes cancelados (por qualquer motivo, sendo o motivo cadastrável);

66) Para cada agenda, o SRES deve exibir os totais de vagas ocupadas e disponíveis para cada tipo de consulta;

67) Deve possibilitar no momento de o agendamento visualizar os dados básicos do cidadão, contendo minimamente:

68) Nome e/ou nome social;

69) Foto;

70) C, endereço;

71) Sexo;

72) Data de nascimento;

73) Idade;

74) Cartão Nacional de Saúde (CNS);

75) CPF;

76) Identidade;

77) Deve dispor de ação para edição de cadastro do cidadão caso o usuário tenha acesso para alterações, ou se necessária criação de novo cadastro;

78) Deve possibilitar no momento de o agendamento identificar condições especiais de acordo com as prioridades legais, sendo elas minimamente:

79) Idoso (a);

80) Pessoa com deficiência;

81) Gestante;

82) Deve haver impressão automática do protocolo configurado;

83) Deve haver opção para imprimir ficha de atendimento;

84) Deve haver na listagem diária para cada agendamento minimamente as seguintes ações:

85) Atendimento de acolhimento;

86) Atendimento em prontuário;

87) Cancelamento do agendamento;

88) Deve haver forma de realizar processamento em lote, minimamente das seguintes operações:

89) Transferência;

90) Cancelamento;

91) A ação de cancelar deve minimamente solicitar as seguintes informações:

92) Opção para que o operador indique se a vaga será liberada para novo agendamento;

93) Motivo do cancelamento;

94) Observações sobre o cancelamento;

95) A rotina de transferência de agendamentos deve possibilitar selecionar os mesmos dados de cancelamento e possibilitar selecionar os dados do agendamento de destino, listando os cidadãos selecionados com opção de seleção de horário quando este definido em cronograma. (esta rotina deve cancelar os agendamentos e fazer os novos de acordo com os dados selecionados);

96) Deve possuir relatórios que possibilitem minimamente a extração das seguintes informações:

97) Agendamentos em um determinado período;

98) Cotas;

99) Cronogramas;

100) Detalhado de atendimentos;

101) Estatísticas por período;

102) PRODUÇÃO AMBULATORIAL

103) Contempla recursos pertinentes ao processo de faturamento ambulatorial, visa principalmente agregar informações assistenciais para gerar informações de faturamento que impactam financeiramente na rotina da Secretaria de Saúde.

104) Deve realizar a geração de arquivos de produção BPA (possibilitando conter procedimentos de competências passadas que ainda não foram enviados) no formato exigido pela versão atual do BPAMAG durante toda vigência contratual;

105) Deve dispor de recurso para seleção de unidade de saúde a ser gerado o arquivo de BPA, bem como poder escolher se os procedimentos do arquivo serão consolidados ou individualizados (para aqueles que se enquadram nas duas modalidades);

106) Dever utilizar vocabulários de procedimentos SIGTAP e vocabulário de diagnóstico CID-10;

107) Deve possuir mecanismo para importação das tabelas de procedimentos do SIA através do BPAMAG ou preferencialmente SIGTAP, devendo haver uma forma automática sem intervenção do usuário através de programação no sistema ou em agendador de tarefas do servidor de aplicação (crontab, agendador de tarefas, etc);

108) Importar e manter atualizada automaticamente, com ou sem interação do usuário, a tabela unificada de procedimentos SIGTAP, mantendo a série histórica das versões;

109) Possuir funcionalidade para definição de competências para Produção Ambulatorial contendo a competência, data de início, data final e situação para fins de bloqueio impedindo movimentações;

110) Possuir mecanismo de validação dos procedimentos SUS importados da tabela SIGTAP para que estes sejam informados respeitando os critérios de glosa do BPAMAG;

111) Permitir gerar o arquivo de cobrança do BPA nos padrões determinados para importação pelos sistemas do Ministério da Saúde estipulados em documento de integração fornecido pelo Datasus;

112) Dispor de recurso para importação da tabela de CEP Brasil disponibilizada pelo Datasus;

113) Dispor de cadastros de Origem e Destino do paciente para utilização nas fichas de Registro das Ações Ambulatoriais de Saúde (RAAS) domiciliar (RAS-AD) e psicossocial (RAS-PSI);

114) Possuir recurso para digitação das informações nos moldes do RAS-AD e RAS-PSI, passíveis de validação e exportação para o sistema RAAS;

115) Possuir recurso para validação das informações RAS-AD e RAS-PSI, exibindo ao usuário informações de validação, sendo que quando inválido informar qual o motivo para que este possa ser corrigido ou complementado de acordo com as regras de validação do sistema RAAS;

116) Permitir a geração de faturas por equipamento de saúde e exportação de arquivos para o sistema RAAS de acordo com manual de integração fornecido pelo Datasus;

117) Possuir minimamente relatórios estatísticos de produção que apresentem informações referentes a:

118) Atendimentos por profissional;

119) Atendimentos RAAS;

120) Atendimentos por CBO e unidade;

121) Atendimentos por CBO e idade;

122) Atendimento por CBO e procedimento;

123) Atendimento por XXX e procedimento;

124) Consolidado de produção mensal;

125) Produção analítica por profissional;

126) Possuir minimamente relatórios gerenciais que apresentem as seguintes informações:

127) Atendimentos por idade e sexo;

128) Faturamento dos profissionais;

129) Faturamento mensal;

130) Procedimentos mais realizados;

131) Procedimentos não faturados;

132) Produção por unidade de saúde;

133) Produção por especialidade.

134) ATENÇÃO PRIMÁRIA

135) Contém todos os recursos relevantes para coleta de dados e cumprimento de metas relacionadas a atenção primária, evidenciando de forma prioritária a integração com E-SUS no padrão Thrift, respeitando as peculiaridades deste município.

136) Deve permitir o cadastro das áreas, micro áreas e equipes da Estratégia Saúde da Família (ESF);

137) Possuir funcionalidade para importação do XML (disponibilizado pelo Datasus) contendo os dados dos equipamentos, profissionais e equipes da Secretaria de Saúde;

138) Possibilitar a inclusão, edição ou consulta de todas as fichas CDS disponíveis para integração na versão atual do layout de integração do E-SUS, respeitando layouts e campos para completo preenchimento das fichas;

139) Possuir cadastro ou funcionalidade para armazenar as informações de saúde do paciente conforme Ficha de Xxxxxxxx Individual do e-SUS com restrição de acesso através do perfil, evitando acesso indevido a informações clínicas do cidadão;

140) Possuir funcionalidade para indicar informações sobre ‘Morador de Rua’ quando aplicado, conforme Ficha de Xxxxxxxx Individual do e-SUS;

141) Possibilitar o cadastramento de domicílios conforme Ficha de Cadastro Domiciliar e Territorial;

142) Possibilitar cadastramento de famílias e seus integrantes, conforme Ficha de Cadastro Domiciliar e Territorial e Ficha de Cadastro Individual. Havendo a possibilidade de vincular a um registro existente no cadastro de cidadão, ou através da própria tela de domicílio/família inserir novos cidadãos, sendo que estes passaram a compor o cadastro unificado de cidadãos;

143) Deve possuir mecanismo ou funcionalidade que impeça que mesmos cidadãos sejam inseridos com situação ativo em mais de uma família, bem como ação para inativar o cidadão na família, mantendo- se o histórico do mesmo;

144) Possuir ferramenta ou funcionalidade para migrar domicílios entre micro áreas, no intuito de agilizar remanejamento de domicílios e famílias entre agentes comunitários de saúde sempre que necessário;

145) Possibilitar visualizar a situação das fichas em relação a exportação e envio ao e-SUS;

146) Deverá possuir recurso para exibir ao usuário em qual versão do e-SUS a ficha foi validada;

147) Deve possuir integração com sistema E-SUS na versão atual, disponibilizada pelo MS/DAB, transmitindo todas as informações conforme layout constante no LEDI e-SUS AB referente às fichas CDS, possuindo minimamente no processo de exportação:

148) Forma de selecionar os tipos de fichas a exportar;

149) Escolha de uma ou mais competências a serem exportadas;

150) Relatório simplificado de fichas exportadas no processo;

151) Visualização de log de exportação com informações básicas das fichas pertencentes ao processo;

152) Ação para baixar arquivo thrift conforme layout de integração e-SUS CDS;

153) Validar no momento da exportação eventuais problemas nas fichas evitando a glosa no centralizador e-SUS;

154) Informar para qual versão do e-SUS CDS está sendo feita a geração do arquivo e suas validações;

155) Possuir recurso para configuração de obrigatoriedade de fichas a serem preenchidas no prontuário, sendo possível indicar minimamente:

156) Ficha;

157) CBO;

158) Unidade de Saúde;

159) Possuir minimamente relatórios capazes de extrair as seguintes informações:

160) Acompanhamento de visitas dos Agentes Comunitários de Saúde;

161) Atendimentos dos cidadãos (fichas);

162) Cadastros de domicílios por Agente Comunitário de Saúde;

163) Cadastros individuais por Agente Comunitário de Saúde;

164) Condutas registradas nas fichas;

165) Conferência de produção;

166) Consolidado de cadastros;

167) Consolidado por Profissional;

168) Domicílios registrados no sistema;

169) Informações para preenchimento do programa “Mais médicos”;

170) Marcadores de consumo alimentar;

171) Procedimentos faturados e-SUS/BPA;

172) Produtividade Odontológica Mensal;

173) Totais de famílias e integrantes;

174) Visitas domiciliares;

175) Visitas domiciliares por ACS;

176) Visitas domiciliares não realizadas;

177) CONTROLE DE AUTORIZAÇÕES À TERCEIROS

178) Deve fornecer recursos para controlar saldos orçamentários, gerir contratos com prestadores de serviços e diagnosticar em tempo real o volume de dinheiro investido nestes processos.

179) Possibilitar o cadastro de preparos para os procedimentos que serão autorizados, de modo que este preparo seja impresso junto com o comprovante da autorização, objetivando comunicar ao paciente todos os preparativos necessários para realização do procedimento;

180) Deve possuir cadastro de convênios com objetivo de possibilitar a diferenciação de valores de exames por convênio, e assim controlar e diferenciar valores para um mesmo exame em diferentes convênios;

181) O sistema deve possuir cadastro de grupos de procedimentos, usados para agrupamento de informações em relatórios;

182) O SRES deve possuir cadastro de exames possibilitando informar código, descrição, apelido, tempo médio de atendimento, quantidade de agendamentos por hora, indicação de status (ativo/inativo), bem como possibilitar a sua ligação com o cadastro de grupo e a vinculação do mesmo com a tabela de procedimentos oficial SIGTAP;

183) Deverá possibilitar a vinculação de cada exame a grupos orçamentários, utilizados para elaboração dos orçamentos de tetos físicos e ou orçamentário para controle das autorizações;

184) A aplicação deverá possibilitar que sejam criados exames compostos por mais de um procedimento SUS através do vínculo do procedimento SIGTAP e quantidade do mesmo para formar a composição de valor do exame criado;

185) Deve possibilitar a definição de tetos orçamentários anuais por município de modo que o valor mensal possa ser acumulado para o próximo mês se houver saldo não utilizado, a definição deste orçamento deve ser possível de ser lançada por grupo e ou procedimento bem como a possibilidade que o teto seja definido por quantidade e ou valor;

186) Deve possuir mecanismo para definição de tetos orçamentários por município, prestador, unidade de saúde e profissional, atribuindo-se a eles quantidade e ou valor orçado;

187) Durante a autorização dos procedimentos, a aplicação deve permitir que sejam informados o nome do cidadão, a data da autorização, unidade de saúde que solicitou, unidade que autorizou, profissional solicitante, indicação de gravidez a cidadã do sexo feminino, número da requisição, procedimento (s), data da realização, prestador, turno, horário, quantidade e observação;

188) Durante a autorização sistema deverá exibir as últimas autorizações disponibilizadas ao cidadão;

189) Deverá possuir mecanismo para consultar o saldo disponível a ser utilizado pelo prestador selecionado a atender a autorização;

190) 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 atendimento pelo prestador;

191) Deve ser possível a criação de exceções, que deverão bloquear autorizações com base em suas informações;

192) Durante o processo de autorização a aplicação deverá obedecer rigorosamente aos tetos orçamentários definidos, não permitindo os mesmos sejam ultrapassados;

193) 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;

194) Deve permitir, de modo a ser configurado se desejável, que sejam autorizados exames sem que seja indicado o prestador que irá realizá-los, de modo a garantir a livre escolha do cidadão em relação ao prestador;

195) Deverá possibilitar a busca de solicitações realizadas pelo profissional em seu atendimento no prontuário eletrônico, restando ao operador a tarefa de confirmar os procedimentos a serem autorizados, a escolha do prestador em que será realizado data e hora;

196) Deverá possibilitar por meio de configuração prévia do sistema que a autorização possa ser atendida apenas por completo e sempre utilizando o mesmo prestador para atendimento total da requisição;

197) Deverá ser possível o cancelamento por completo de uma requisição que ainda não tenha sido atendida pelo prestador, bem como a sua replicação por completo para outra data;

198) Deve possibilitar a configuração de bloqueios de procedimentos e ou grupos de procedimentos por quantidade máxima a ser autorizada, número de dias de intervalo de realização entre autorizações e ou bloqueio por não retirada do resultado por determinado tempo;

199) Possuir tela para gerenciar os cidadãos que estejam com procedimentos bloqueados de maneira que operador autorizado possa realizar a liberação;

200) Deverá possibilitar a Secretaria de Saúde personalize o layout do impresso de autorização;

201) Deve disponibilizar mecanismo para confirmação de realização dos procedimentos autorizados e executados pelo prestador, bem como a possibilidade de o mesmo anexar resultados, mediante chave de confirmação impressa na autorização entregue ao cidadão;

202) Em sua funcionalidade de confirmação de realização pelo prestador, deverá listar as autorizações que contenham o prestador previamente definido na autorização ao seu executante, bem como possibilitar a busca de autorizações utilizando filtros como número de autorização ou cidadão, tanto para as autorizações com prestador pré-definido ou não;

203) Deve possibilitar a configuração de um intervalo de dias para que o prestador possa confirmar a realização dos procedimentos. Este tempo pode ser contado tanto pela data da autorização quanto pela data do lançamento da mesma (para quando forem digitadas autorizações de datas passadas, por exemplo);

204) Deverá possibilitar a configuração da aplicação de modo que a mesma realize automaticamente o cancelamento das autorizações que não tenham sido confirmadas pelo prestador até o prazo limite para a

confirmação, bem como permitir que seja configurado que ao realizar os cancelamentos a aplicação retorne o saldo das mesmas aos seus respectivos orçamentos e fiquem disponíveis para serem utilizados por novas autorizações;

205) Deve possuir minimamente os seguintes relatórios:

206) Procedimentos autorizados por cidadão;

207) Procedimentos autorizados por município;

208) Procedimentos autorizados por prestador;

209) Procedimentos autorizados por unidade solicitante;

210) Procedimentos autorizados por unidade autorizadora;

211) Saldo dos orçamentos por município;

212) Saldo dos orçamentos por unidade;

213) Saldo dos orçamentos por prestador;

214) Totais de autorizações e procedimentos autorizados;

215) Procedimentos faturados por prestador;

216) Totais de procedimentos autorizados, confirmados pelo prestador e ou canelados;

217) CONCESSÃO DE BENEFÍCIOS

218) Deve gerir as autorizações de procedimentos e outros benefícios disponibilizados ao paciente, que não se enquadrem no módulo de autorização de procedimento, tratando de situações eventuais, tanto para o paciente quanto para a Secretaria de Saúde.

219) Deve possuir cadastro de benefícios contendo minimamente a descrição, o valor e procedimento;

220) Possuir cadastro de locais para encaminhamento do benefício;

221) Deve possibilitar a configuração de obrigatoriedade de controle de saldo para cada benefício;

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

223) Deve possuir funcionalidade para identificação dos processos de concessão de benefícios segundo seu estado, a fim de identificar de forma simples se o mesmo se encontra autorizado, negado ou se está em análise;

224) Deve possuir funcionalidade ou mecanismo para emissão do Laudo Social contendo minimamente as informações de: gestor, número do laudo social, número da lei, identidade e CPF;

225) Deve possuir um campo de texto livre para informações do histórico da solicitação do benefício;

226) Deve possuir um campo de texto livre para observações no recibo de entrega de cada benefício;

227) Deve permitir que vários benefícios sejam atrelados a um mesmo processo de concessão de benefícios contendo minimamente as informações de benefício, a quantidade, o valor, o profissional, o local de retirada e observações;

228) Deve possuir mecanismo para gerenciamento e emissão de encaminhamentos para cada cidadão, contendo minimamente as informações de: cidadão, profissional, descrição do encaminhamento, trabalho do cidadão, renda do cidadão, data, hora, dia da semana, valor do encaminhamento e campo de texto livre para observações;

229) Deve permitir a emissão de recibo de entrega dos benefícios;

230) Deve permitir ao gestor verificar em forma de relatório quais os cidadãos que receberam um determinado benefício, a data e o valor recebido;

231) Deve possuir relatório de extrato dos benefícios, permitindo selecionar um período e o benefício desejado;

232) Deve possuir relatório de gerenciamento dos saldos mensais dos benefícios, permitindo selecionar o mês desejado;

233) Deve possuir impressão para requerimento de auxílio financeiro, para envio ao fundo municipal de saúde.

234) CONTROLE DE ESTOQUES E C.A.F.

235) Deve possuir recursos suficientes para realizar a gestão de estoques em geral da Secretaria de Saúde, assim como realizar a gestão dos C.A.F.s (Centros de Armazenamento Farmacêutico).

236) Deve possuir controle de medicamentos em conformidade com a Portaria SVS/MS/Nº344, de 12 de maio de 1998 /98 (ANVISA) e suas alterações (item declaratório);

237) Possuir cadastro de fornecedores contendo minimamente o CNPJ, data do cadastro, razão social, dados de endereço (logradouro, bairro, complemento, cidade, Cep, uf), telefone, e-mail, nome do responsável;

238) Deve permitir indicar se o fornecedor distribui medicamentos controlados, exigindo neste caso, seu número de alvará, número da licença, número da licença especial e o tipo do fornecedor (Distribuidora, indústria, farmácia);

239) Deve possuir cadastro de motivos para uso em acertos de estoque;

240) Deve possibilitar o cadastro de fabricantes, contendo minimamente os campos de descrição, CNPJ, razão social, dados para endereço (logradouro, bairro, complemento, cidade, Cep, uf), telefone, e-mail, nome do responsável;

241) Possuir cadastro de centro de custo, contendo minimamente a descrição, CNPJ e o CNES;

242) Possuir cadastro de listas de entorpecentes, assim como de suas versões;

243) Possuir cadastro de DCB’s (Denominação Comum Brasileira), contendo minimamente, a descrição, o código, a versão e a lista de entorpecentes;

244) Permitir cadastrar grupos e subgrupos para os materiais;

245) Deve permitir identificar quando o material é do tipo medicamento;

246) Deve permitir definir os materiais e medicamentos que necessitam de controle por lote e validade

247) Deve permitir gestão de estoque dos materiais/medicamentos com controle por lote e validade, permitindo identificar o fabricante, o lote a data de validade e a quantidade em estoque para cada unidade;

248) Deve possibilitar que seja definido quais medicamentos que necessitam de preenchimento do laudo LME, e caso seja dado baixa nesses medicamentos, permitir o operador a imprimir o laudo LME (imprimir recibo de dispensação do medicamento);

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

250) Deve permitir identificar um material/apresentação do sistema, com um material da catalogação dos materiais (CATMAT);

251) Deve permitir identificar um material/apresentação, com um procedimento da tabela SIGTAP;

252) Deve possuir mecanismo para informar os estoques mínimos para material, apresentação em cada ponto de distribuição de materiais/medicamentos em funcionamento na contratante, e permitir alertar o operador que realiza as baixas dos materiais, quando o mesmo atingiu o limite de estoque;

253) Deve possuir cadastro de competências específicas para o gerenciamento de estoque;

254) Deve permitir definição da administração, para quantidade máxima de dias de atraso que pode registrar uma compra (com base na data da compra);

255) Deve permitir definição da administração, para quantidade máxima de dias de atraso que pode registrar uma saída (com base na data da saída);

256) Permitir definição da administração, para quantidade máxima de dias de atraso que pode registrar uma transferência (com base na data da transferência);

257) Deve possuir mecanismo para controle de patrimônio, contendo os minimamente as seguintes informações: número do patrimônio, data da garantia, número da nota fiscal, material, fornecedor, unidade de saúde, centro de custo, localização, indicação se o mesmo foi baixado, data da baixa e campo para observações;

258) Deve permitir o gerenciamento e controle de medicamentos de rotina, contendo minimamente a data e hora, cidadão, o medicamento, observação e quantidade a ser dispensada;

259) Deve 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;

260) Deve possuir mecanismo para gerenciamento entrega parcial de medicamentos por licitação contendo minimamente as informações de Data da Licitação, número, item da licitação (Material/Medicamento), quantidade, valor unitário, fornecedor e campo para observações;

261) Deve permitir o ponto de distribuição de trabalhar com utilização de etiquetas de códigos de barra, e permitir o desenvolvimento padronizados desses modelos de etiqueta a ser utilizado;

262) Deve dispor de mecanismo de impressão de etiquetas informando minimamente o material/apresentação, fabricante, lote/validade e quantidade;

263) Deve possuir controle de entrada e compras de Materiais e Medicamentos com base na nota de compra, contendo minimamente as seguintes informações: data da entrada, ponto de distribuição a onde está sendo realizada a entrada, fornecedor, licitação, data da compra, número da nota fiscal, série, valor de frete, valor de acréscimo, descontos, lista como os materiais/medicamentos, centro de custo, fabricante, a quantidade e o valor total do material/medicamento;

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

265) Deve possuir mecanismo que não permita o lançamento de valores e quantidades incorretas com base nas informações da nota fiscal de entrada;

266) Para toda compra de materiais/medicamentos, o sistema deve dispor da emissão do extrato da compra;

267) Deve possuir mecanismo para fechamento/encerramento de lançamento dos itens da compra, e cálculo do custo médio de cada um dos itens que fazem parte da nota de compra;

268) Deve possuir na compra recurso para atender a uma requisição de compra de materiais/medicamentos;

269) Deve possuir mecanismo de requisição de materiais para que os pontos de distribuição possam solicitar os materiais e medicamentos que julgarem necessários, contendo minimamente as informações de data da requisição, qual unidade de saúde que está solicitando a compra, e a quantidade e itens de materiais/medicamentos;

270) Deve possibilitar o cadastro das licitações realizadas, permitindo cadastrar o número da licitação, data, observações, e os materiais/medicamentos pertencentes a essa licitação, contendo minimamente as informações de nome do material/medicamento, quantidade, valor unitário, valor total, número de parcelas e o fornecedor;

271) Deve permitir a entrada no estoque a partir de uma licitação, contendo um mecanismo ou funcionalidade que neste tipo de entrada de itens no estoque, não permita o operador lançar quantidade do material/medicamento ou valor diferente do registrado na licitação;

272) Deve possuir mecanismo para gerenciamento de entrega parcial de medicamentos por licitação contendo minimamente as informações de Data da Licitação, número, fornecedor, item da licitação (Material/Medicamento), quantidade total, valor unitário, quantidade entregue, quantidade restante e número de parcelas totais e número de parcelas entregues;

273) 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;

274) Deve possuir relatório de abastecimento dos pontos de distribuição, mostrando minimamente as informações de consumo, quantidade em estoque e estimativa do número de dias que o estoque atual conseguirá suprir com base no consumo;

275) Deve possuir mecanismo de conferência das transferências realizadas entre pontos de distribuição de materiais/medicamentos do município;

276) Deve dispor de impressão dos itens de uma nota de transferência, contendo minimamente as informações de: material/medicamento, unidade, quantidade;

277) Deve permitir registrar a devolução de materiais/medicamentos para o fornecedor, identificando qual o fornecedor, a data da devolução, os materiais/medicamentos, quantidade, validade (caso houver) e o motivo da devolução.

278) Deve possuir mecanismo que só permita devolver itens de compras/entradas realizadas pelo fornecedor informado;

279) Deve permitir fazer a devolução de uma saída de materiais/medicamentos, contemplando minimamente as informações de Data, cidadão ou centro de custo, e os materiais/medicamentos quantidade e validade (caso houver);

280) Deve possuir mecanismo que só permita devolver itens de saídas/dispensação realizadas para o cidadão ou centro de custo informado;

281) Deve conter mecanismo para que possam ser realizados acertos de estoque em cada ponto de distribuição contendo minimamente as informações de data do acerto, motivo, material/medicamento, unidade, data da validade, quando necessário, a quantidade real em estoque e um campo de texto livre para observações;

282) Deve permitir o operador cadastrar e gerenciar as receitas do cidadão, contendo minimamente as informações de: cidadão, profissional da receita, data da receita, data de validade da receita, e lista de

materiais/medicamentos prescritos, contendo o nome/apresentação do material/medicamento, quantidade

prescrita, a quantidade máxima que o cidadão pode retirar por vez, a posologia, a quantidade já entregue do medicamento e disponibilizar o salto por item;

283) Deve possuir mecanismo para registro das dispensações de materiais e medicamentos para os cidadãos deve possuir minimamente as informações de ponto de distribuição onde a baixa foi realizada, data, número da receita, cidadão, profissional e programa. Nos itens de dispensação deve ser possível registrar as seguintes informações: material e sua forma de Apresentação, lote de validade, quantidade, quantidade prescrita, duração;

284) Na tela de dispensação de materiais/medicamentos, a aplicação deve permitir encontrar o cidadão (cadastrado no sistema) com base em qualquer uma das informações: nome, sobrenome, cartão sus, nome da mãe e data de nascimento;

285) Permitir realizar baixas de materiais e medicamentos para centro de custo;

286) Permitir realizar baixas de materiais pelo código de barras (deve permitir definir o código de barras na apresentação do material/medicamento);

287) Deve possuir identificador de medicamentos controlados de acordo com a lista de entorpecentes a qual o medicamento controlado pertence, obrigando em uma dispensação deste tipo de medicamento que o operador indique a data e número da receita e o número da notificação;

288) Na dispensação de medicamentos para o cidadão, o sistema deve avisar/alertar o operador de quando o cidadão estiver retirando um medicamento antes da data prevista para sua retirada;

289) Deve disponibilizar um comprovante de baixa/saída dos materiais/medicamentos;

290) Na tela de dispensação de medicamentos para o cidadão, o sistema deve possuir mecanismo para que sejam consultadas as últimas dispensações de medicamentos realizadas para o cidadão que está sendo atendido;

291) Deve permitir o operador que realizará a dispensação/baixa de medicamento para o cidadão, visualizar os últimos medicamentos entregues ao cidadão;

292) Deve possuir mecanismo para registro dos materiais/medicamentos solicitados e não disponíveis nos pontos de distribuição, contendo minimamente as informações de: qual o ponto de distribuição, data da demanda, cidadão, centro de custo, material/medicamento, quantidade em estoque, quantidade a ser dispensada e quantidade reprimida;

293) Deve permitir identificar quais os pontos de estoque que podem realizar entradas, limitando a funcionalidade para apenas esses pontos de estoque;

294) Deve possuir parâmetro para indicar se é possível que o ponto de distribuição possa inserir uma saída de material/medicamento, sem informar o cidadão, apenas informando o centro de custo;

295) Deve possuir parâmetro para indicar se é possível que o ponto de distribuição possa inserir uma saída de material/medicamento, sem informar o cidadão nem ou centro de custo;

296) Permitir o gestor do sistema obrigar a informação do profissional que receitou o medicamento, durante a dispensação do mesmo;

297) Deverá possuir rotina para acompanhamento de medicamentos vencidos, contendo minimamente as informações de unidade de saúde, material/medicamento, fabricante, validade e quantidade;

298) Possuir parâmetro para indicar se o tempo de utilização do material/medicamento vai ser obrigatório informar no cadastro de uma saída ou dispensação;

299) Deve disponibilizar um mecanismo que identifique no momento do lançamento de uma dispensação, que o material/medicamento, não está disponível em estoque, podendo o operador, lançar a demanda reprimida sem ter que trocar de tela;

300) Permitir o administrador de estoque configurar se o sistema permitirá ou não aceitar acertos de estoque com datas retroativas;

301) Permitir o administrador de estoque configurar se o sistema permitirá ou não a transferência de medicamentos vencidos;

302) Permitir o administrador de estoque configurar se o sistema deve emitir um aviso ao operador, assim que o material/medicamento atingir sua quantidade mínima em estoque;

303) Deve possuir rotina para acompanhamento dos medicamentos com estoque abaixo da quantidade mínima;

304) Possibilitar o controle dos antimicrobianos em conformidade com os padrões da ANVISA;

305) Possuir mecanismo ou funcionalidade que permita importar o arquivo de produtos disponibilizados pelo Web Service Base Nacional da Assistência Farmacêutica;

306) Deve disponibilizar a funcionalidade de integração com o sistema da Base Nacional da Assistência Farmacêutica;

307) Deve possuir relatório de balancete demonstrativo físico dos materiais/medicamentos;

308) Deve possuir relatório de balancete demonstrativo financeiro dos materiais/medicamentos;

309) Deve dispor de relatório de análise de consumo de materiais/medicamentos dos cidadãos em um determinado período;

310) Deve dispor de relatório de análise estatístico curva ABC;

311) Deve permitir o gestor verificar em forma de relatório a movimentação de estoque de uma unidade de saúde em um determinado período;

312) Deverá permitir o gestor verificar em forma de relatório o total de materiais/medicamentos em estoque para cada unidade de saúde;

313) Deve dispor de relatórios gerenciais básicos de compras, saídas, transferências, acertos do estoque, e validade dos materiais em estoque.

314) PROGRAMA DE ENTREGA DE MEDICAMENTOS

315) Consiste na gestão logística do processo, integrado ao controle de estoque, para organização e distribuição de medicação em domicílio para pacientes de grupos específicos.

316) Deve possuir mecanismo para cadastramento dos cidadãos em programas de saúde;

317) Deve possuir funcionalidade para cadastramento das receitas do cidadão, permitindo incluir materiais e medicamentos com suas respectivas datas de validade;

318) 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;

319) 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;

320) Deve permitir o gerenciamento de receitas do cidadão, permitindo sua renovação por um período determinado;

321) 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;

322) Deve possuir funcionalidade para geração dos pacotes a serem entregues para cada paciente contendo seus materiais e medicamentos;

323) A montagem dos pacotes deve ser feita através de um processo de linha de montagem, visando otimizar o fluxo de trabalho, de forma a atender ao menos as seguintes etapas:

324) Listagem e organização dos pacotes;

325) Separação dos pacotes;

326) Conferência dos materiais;

327) Registro da entrega à equipe de transporte;

328) Registro de entrega ao destinatário;

329) Deve, no processo, permitir que seja registrada cada etapa com validação ao menos de um dos itens:

330) Login e senha;

331) Biometria;

332) 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;

333) Possuir funcionalidade para emissão dos recibos de entrega para cada paciente contendo no mesmo informações sobre os medicamentos e materiais contidos no pacote;

334) Deve possuir funcionalidade para baixa automática do estoque dos materiais e medicamentos contidos nos pacotes entregues;

335) Possuir recurso para baixas em lotes sem a geração de pacotes para itens que não se enquadram neste processo, efetuando a geração automática das baixas necessárias no módulo estoque, contendo as seguintes funcionalidades:

336) Listagem de cidadãos do processamento;

337) Rotina de processamento (baixa) dos itens do estoque;

338) Relatório de itens dispensados por cidadão;

339) Relatório de itens que não puderam ser integrados com a baixa do estoque;

340) Permitir a inativação dos cadastros de cidadãos nos programas, evitando a geração de pacotes a cidadãos que não atendem mais os critérios definidos;

341) Deve prover relatórios para extração minimamente das seguintes informações:

342) Previsão de consumo de itens para montagem de pacotes;

343) Pacotes não entregues por falta de estoque;

344) Previsão de entrega de itens para cidadãos;

345) Xxxxxxx e entrega;

346) Saldo de estoque de itens para montagem;

347) Validades das receitas.

348) GESTÃO DE PROCESSOS JUDICIAIS DE MEDICAMENTOS

349) Visa controlar os processos judiciais que são impetrados contra o município, de forma a garantir transparência em seus cumprimentos.

350) Deve possuir funcionalidade ou mecanismo para controle de processos judiciais, contendo minimamente as informações de número do processo, data de abertura, cidadão, equipamento de saúde de cobertura e campo para observações;

351) Deve permitir que os processos sejam classificados segundo sua situação, disponibilizando as opções: aberto, único, fora de linha, cumprido, devolvido, suspenso, em andamento;

352) No cadastro do processo judicial, deve-se dispor de campo para definição da patologia, data do pedido, data de recebimento, número da regional e indicativo do despacho (União, Estado ou Município);

353) Deve permitir que seja informado para cada processo se o mesmo gera algum tipo de bloqueio, se gera algum tipo de multa, sendo neste caso possível informar também o valor da multa;

354) Para o controle dos processos judiciais, o sistema deve possuir campos para informação dos dados do advogado, sendo possível informar nome do advogado responsável, número na OAB e telefone;

355) Deve possuir campo para indicar se o processo se encontra ativo ou inativo, e caso o processo esteja inativo, o operador deverá informar o motivo de inativação do processo e a data de fechamento;

356) Deve dispor de cadastramento dos materiais/medicamentos que serão identificados nos processos judiciais;

357) Para um processo judicial, deve permitir cadastrar todos os materiais/medicamentos referentes ao processo;

358) Deve possibilitar o operador a cadastrar para cada material/medicamento definido no processo, as informações de quantidade, valor unitário, desconto, identificar se é de uso contínuo, identificar se é genérico, por quem será fornecido e um campo para observações;

359) Deve permitir definir a situação do material no processo judicial, contendo minimamente as opções: aberto, único, fora de linha, cumprido, devolvido, suspenso, em andamento;

360) Deve possuir mecanismo para gerenciamento das entregas de medicamentos judiciais contendo minimamente as informações de material/medicamento, data da última entrega, data da próxima entrega, quantidade do processo, saldo e quantidade atual em estoque, para cada item de material/medicamento contido no processo;

361) Deve permitir que os operadores de dispensação de medicamentos, ao identificar um cidadão para dispensação que possui processo judicial, consigam visualizar os materiais/medicamentos do cidadão em processos judiciais, dispondo minimamente as informações de: material (ou medicamento) e a quantidade;

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

363) Deve possibilitar em forma de relatório gerencial, a verificação das informações dos processos judiciais, disponibilizando a informação do cidadão, o número do processo, a data de abertura, os materiais/medicamentos e sua quantidade.

364) CONTROLE DE DENGUE

365) Deve gerir a instalação e controle das armadilhas para controle de vetores de dengue.

366) Deve permitir o cadastramento dos tipos de recipientes, contendo minimamente, a descrição, indicativo de dificuldade de acesso, e indicador que define quais os tipos de recipientes que precisam de tratamento;

367) Xxxx possuir cadastros de recipientes, contemplando os tipos de recipientes, e sua descrição;

368) Deve permitir cadastrar fichas de Dengue, contendo minimamente as informações de endereço (bairro, logradouro, número, complemento), tipo de imóvel (residencial, comercial, terreno baldio, etc), dados de colocação das armadilhas e os recipientes encontrados no local, com possibilidade de foco da dengue;

369) No registro da ficha de dengue, deve ser permitido informar e identificar as armadilhas colocadas, permitindo informar minimamente, o profissional, o número da armadilha, a localização (referencial) e a data de instalação;

370) No registro da ficha de dengue, deve ser permitido informar os recipientes de possibilidade do foco da dengue, permitindo informar minimamente, o profissional, a data da visita, e quantidade e os recipientes encontrados no local;

371) Deve possibilitar as informações de investigação de dengue em forma de relatório, possibilitando minimamente a informação de quantitativos recipientes de investigação para cada tipo de imóvel, e quantitativo de locais que precisam de tratamento;

372) Deve disponibilizar a impressão do registro das atividades de prevenção e recolhimento de pequenos recipientes inservíveis;

373) Deve disponibilizar a impressão de consolidação das atividades de prevenção e recolhimento de pequenos recipientes inservíveis;

374) PAINEL DE CHAMADAS

375) Ferramenta para uso em televisores de 32” ou mais, visando chamar os pacientes para atendimento em detrimento a ida do profissional até a recepção para que faça verbalmente a chamada do mesmo.

376) Deve possuir mecanismo de painel para utilização nas salas de espera dos pontos de atendimento da Secretaria de Saúde;

377) O mecanismo do painel eletrônico deve possibilitar o chamamento do cidadão através do seu nome indicando para qual consultório ou sala que o mesmo deverá se deslocar para ser atendido;

378) Deve possibilitar que sejam inseridas informações a serem exibidas nas salas de espera entre um atendimento e outro, de modo a permitir a divulgação de informações relevantes para os pacientes em espera;

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

380) Deve possuir no momento da implantação informações visuais relacionados com o formato de atendimento e triagem (baseado no protocolo do Ministério da Saúde) com objetivo de orientar aos cidadãos na maneira como as filas de atendimento serão estabelecidas, para serem exibidos nas salas de espera onde o painel será utilizado;

381) Deve permitir envio de mensagens ou avisos ao painel, com opção de aviso sonoro;

382) Permitir parada das chamadas no painel, devido a situações adversas.

383) PRONTUÁRIO ELETRÔNICO DO CIDADÃO

384) Centraliza o registro clínico do atendimento, para todos os profissionais das unidades próprias e terceirizadas.

385) Deverá permitir a realização de acolhimento sob demanda, sem a necessidade de haver uma consulta ou agendamento prévio sendo necessário apenas identificar o cidadão através do seu cadastro na aplicação;

386) Deve permitir que os pacientes a sem acolhidos sejam pesquisados ao menos por: nome, sexo, data de nascimento, nome da mãe, CPF, CNS com ao menos três destas informações simultaneamente;

387) Deve possuir registro do peso, estatura, quadril, cintura, temperatura, pressão arterial, frequência respiratória, frequência cardíaca, pulsação, saturação de O2, saturação CO2, 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, data e hora das coletas;

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

389) Quando paciente em questão for uma criança a solução deve permitir o registro de perímetro cefálico e torácico, situação vacinal e tipo de aleitamento;

390) 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, data provável do parto, se a gestação é planejada, se é gestação de risco bem como criar acompanhamento através de controle gestacional alertando outros profissionais de que esta paciente está em acompanhamento gestacional;

391) Possuir funcionalidade para registro das anotações de enfermagem e das queixas do paciente;

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

393) Deve possuir mecanismo para digitação de produção, de maneira que o profissional possa pesquisar todos os procedimentos compatíveis segundo regras do SIGTAP, podendo registrar a execução de quaisquer procedimentos permitidos;

394) Deve possuir mecanismo para que sejam listados ao profissional, durante o atendimento, procedimentos previamente relacionados aos seu CBO, agilizando assim a indicação dos procedimentos realizados pelo profissional no atendimento;

395) 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 e pressão arterial, evolução do IMC, evolução da frequência respiratória/pulsação e para evolução cintura/quadril;

396) Deve permitir que o profissional realize a classificação de risco do paciente utilizando as definições do as cores Vermelho para Emergência, Laranja Muito Urgente, Amarelo Urgente, Verde Pouco Urgente e Azul Não Urgente;

397) 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;

398) 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;

399) Deve permitir a 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;

400) Deve haver interoperabilidade com o painel de avisos e quando o profissional acessar o prontuário através da fila de atendimento o paciente deverá ser chamado pelo painel indicando o consultório onde o profissional se encontra;

401) Deverá possibilitar a parametrização de funcionalidade que permita que o profissional possa alterar a data e hora do atendimento, de forma a ser mantida a data e hora de registro dos mesmos;

402) Deverá possibilitar lançamento em forma de lista de problema no prontuário eletrônico de maneira que um problema possa evoluir ou ser mesclado em um novo ou então em outro já existente;

403) Na lista de problemas deve ser possível 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 do problema, data final do problema;

404) Deve ser possível informar se um problema está sendo tratado no atendimento atual;

405) Deve existir rotina para gerar um novo problema com base no problema selecionado;

406) Dele permitir mesclar problemas existentes;

407) Deve possuir gráfico de evolução dos problemas de acordo com seu registro de evolução ou mesclarem;

408) Deve possibilitar a informação de alergias do paciente através de cadastro de alergias, bem como apresentar a informação referente a alergia em todos os atendimentos realizados ao paciente bem como indicação de alergia em caso de medicamentos indicados e que possam reagir a alergia e que estejam previamente cadastrados e vinculados a alergia em questão;

409) Deve permitir que as informações coletadas durante o atendimento sejam armazenadas no formato SOAP (Subjetivo, Objetivo, Avaliação e Plano), deve ainda sugerir KIDS na seção Avaliação, bem como sugerir CIAP2 em todas as seções do SOAP;

410) Deve possuir o registro de anamnese conforme resolução 2056 de 2013 do Conselho Federal de Medicina (CFM);

411) Permitir a elaboração de questionários personalizáveis para serem sugeridos aos profissionais conforme seu CBO no atendimento;

412) Na ferramenta de questionários personalizados, deve ser possível criar vários tipos de questões, entre elas, questões de resposta em texto livre, questões de múltipla escolha, questões de única escolha;

413) Deve ser possível pontuar as respostas das questões, para geração de escalas (criadas em ferramenta de BI);

414) Deve estar adequada às regras do e-SUS, coletando todas as informações necessárias para alimentação do mesmo durante os atendimentos dos pacientes, bem como possibilitar a obrigatoriedade de preenchimento das mesmas conforme configurações prévias;

415) Permitir o preenchimento das fichas de atendimento do e-SUS conforme layout oficial, para todas as fichas que estão envolvidas no atendimento individual e, conforme tipificação do atendimento, sem a necessidade de sair do atendimento atual pelo prontuário eletrônico e atendendo às regras estabelecidas pelo e-SUS para a compatibilização;

416) 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);

417) 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)

418) Deve possuir campo específico para registro de informações que o profissional julgar importantes, estas informações deverão ser mostradas em destaque durante os atendimentos;

419) Deverá possuir campo para informar as queixas do paciente;

420) Deve possuir local para registro das anotações de enfermagem;

421) Possibilitar o registro de informações referentes a Exames Físicos de modo que possa ser informado dados gerais do exame contendo campos para registro de: aspecto, postura corporal, cor da pele

422) Todos os campos do SOAP devem permitir uso direto da codificação CID-10 ou CIAP-2;

423) Deve possuir local para registro da avaliação antropométrica e aferições vitais contendo a mesma estrutura utilizada para o preenchimento do acolhimento descrito anteriormente;

424) deve possuir funcionalidade para registro da propedêutica com a possibilidade 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 e suas respectivas avaliações: ‘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 musculoesquelético’, ‘sistema endócrino’, ‘saúde mental’;

425) Deve apresentar lista dos acolhimentos previamente lançados ao paciente;

426) 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;

427) Deve haver possibilidade de compartilhar a anotação registrada com outros profissionais, Cabos e ou formas de atendimento;

428) Deve possuir campo de texto livre para informar planos terapêutico, preventivo, Hipótese Diagnóstica e prognóstico;

429) Deve possuir recurso para informar terminologias CID-10 e CIAP-2;

430) Quando informado 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;

431) A terminologia deve ser copulada automaticamente com dados coletados anteriormente como por exemplo a informação de XXX e ou CIAP nas seções anteriores;

432) Quando do preenchimento de ficha de notificação, nesta já deve estar informado os dados básicos do paciente e da notificação, cabendo ao profissional informar os dados necessários;

433) Deve possuir campo de texto livre para informar o serviço;

434) Deve possuir a funcionalidade de escolher e solicitar Testes Rápidos previamente definidos, emitindo a solicitação dos mesmos, bem como possibilitar o lançamento de resultado dos exames que tenham sido realizados;

435) Deve possuir funcionalidade para emissão de solicitações de exames com registro do profissional solicitante, data, observações, dados clínicos, materiais a examinar e exames a serem realizados e resultados;

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

437) Deve possuir funcionalidade para registro de resultados de qualquer exame realizado pelo paciente;

438) Deve permitir vincular o resultado digitado do exame com o exame solicitado, permitir lançamento de resultados de exames realizados com ou sem solicitações existentes, controle do estado da solicitação de exame (solicitado, realizado ou avaliado), bem como possibilitar o envio de anexos referentes a imagens e laudos de resultados de exames, bem como a possibilidade de recuperação dos mesmos para avaliação;

439) Deve disponibilizar automaticamente no prontuário os resultados de exames que tenham sidos realizados pela própria aplicação;

440) As solicitações, ao serem impressas devem respeitar os vínculos de grupos de exames para que as mesmas saem separadas de forma que cada solicitação impressa possua apenas exames do mesmo grupo;

441) 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;

442) 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;

443) 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;

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

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

446) Deve emitir receita normal, controlada e de controle especial de acordo com os medicamentos inseridos pelo profissional;

447) Deve conter mecanismo a fim de possibilitar profissional solicite informações a outro profissional de maneira que o profissional solicitado seja informado sobre o questionamento e possa responder ao profissional solicitante, que receberá aviso de recebimento do retorno do seu questionamento, podendo este questionamento ser finalizado;

448) Deverá prover alerta de itens do componente especializado, LME, para emissão de laudo padronizado para a solicitação e autorização dos mesmos, bem mecanismo para preenchimento dos mesmos;

449) No receituário o profissional deve poder verificar quais medicamentos possui na rede de saúde, bem como se o mesmo pertence a lista de medicamentos básicos, porém deve haver a possibilidade do lançamento de medicamentos que não sejam encontrados na rede municipal de saúde;

450) Deve ser possível identificar o medicamento como sendo de uso contínuo na receita a ser emitida ao paciente, bem como demais informações como, via de administração, quantidade e posologia;

451) Xxxx possuir recurso para exibir e adicionar medicamentos ativos que o paciente está utilizando;

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

453) 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;

454) Possibilitar a criação de layout personalizado para a emissão do atestado;

455) 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;

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

457) 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;

458) Deve possuir mecanismo de consulta as imunizações recebidas pelo paciente bem como mecanismo que possibilite o lançamento de imunização ao paciente a partir do atendimento do mesmo;

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

460) 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;

461) 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;

462) Deve permitir o acesso as informações registradas durante o processo de triagem dos pacientes;

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

464) Na impressão do prontuário deve ser 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;

465) Xxxx possuir mecanismo para informar o desfecho onde a data deve permitir informar fracionada, poder escolher uma classificação de especialidade referente ao atendimento caso não tenha sido informado no início, deve permitir informar o tipo de desfecho cadastrável, campo para informar se foi verificado por médico responsável e campo para registrar observações do desfecho do atendimento;

466) Deve permitir assinar digitalmente em meio eletrônico os documentos do atendimento com a utilização de certificado eletrônico válido ICP-Brasil. 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;

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

468) O documento somente poderá ser assinado por profissional detentor de certificado digital válido ICP-Brasil;

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

470) O certificado a ser utilizado não pode estar expirado;

471) O certificado a ser utilizado não pode estar com problemas de integridade

472) O certificado a ser utilizado não pode estar revogado;

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

474) 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;

475) Deve possuir registro administrativo para gerenciamento de assinaturas não efetuadas;

476) Xxxx possuir delegação de poder para registro de dados no prontuário de modo que o atendimento seja assinado posteriormente pelo responsável que delegou poderes ao usuário;

477) Permitir planejamento do atendimento odontológico realizado através da apresentação da arcada dentária em modo gráfico com distinção entre dentes permanentes, dentes decíduos, faces entre outros;

478) 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;

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

480) Deve possuir mecanismo para lançamento de procedimentos para todos os dentes;

481) Deve disponibilizar ao odontólogo todas as funcionalidades do prontuário do paciente;

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

483) 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;

484) 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;

485) 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;

486) 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;

487) A solução deve permitir a seleção de dentes no odontograma por arcada superior ou inferior, permitindo que sejam lançados um ou mais procedimentos para a arcada selecionada;

488) A solução deve permitir em casos de múltipla seleção no momento de lançamento da condição inicial ou do procedimento escolher se quantidade será aplicada para todos os dentes, para cada arcada, para cada sextante, para cada dente ou para cada face conforme o enquadramento da seleção;

489) A solução deverá dispor de relatórios com base no prontuário contendo minimamente: atendimentos por programa de saúde e atendimentos por CID10/CIAP2.

490) GESTÃO DE FILAS DE ESPERA

491) Compreende a gestão de listas de espera dos munícipes, dado que a oferta de serviços que tem maior demanda que oferta.

492) A plataforma deve possuir cadastro para os níveis de urgência a serem utilizados nas filas de espera contendo minimamente a descrição e a ordem.

493) Deve possuir cadastro de tipos de filas de espera (exames, consultas, transporte);

494) Deve possuir mecanismo ou funcionalidade que permitam que as filas sejam alimentadas nos locais de atendimento à população;

495) O sistema deve permitir que sejam criadas e gerenciadas filas de espera para cada tipo de especialidade disponível na rede de saúde;

496) A plataforma deve possuir mecanismo ou funcionalidade que permita a marcação das consultas da fila de espera em lote, permitindo que o operador selecione um ou mais cidadãos da fila e determine em que agenda de atendimento os mesmos devem ser inseridos;

497) O sistema deve permitir avisar/alertar o operador de possíveis problema na marcação de consultas em lote como em casos de falta de horários disponíveis;

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

499) Deve possuir mecanismo que permita ao gestor identificar quais filas estarão abertas/disponíveis para consultas públicas;

500) Deve possuir mecanismo que permita ao gestor configurar quais informações da fila devem estar visíveis nas consultas públicas contendo minimamente as informações: 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;

501) Deve possuir mecanismo que permita ao gestor configurar algumas filas de espera para passar por processo de regulação/autorização, enquanto outros tipos permitam apenas o fluxo simples;

502) Deve possuir mecanismo que permita ao gestor configurar para a fila de espera que possui processo de regulação, a obrigatoriedade da análise de um regulador, fazendo com que esse registro na fila fique em aguarde até finalização do processo do regulador para a mesma;

503) Nesta mesma funcionalidade supracitada, o sistema deve permitir ao regulador reclassificar a prioridade do atendimento na fila de espera, além de autorizar ou negar o atendimento, mediante

justificativa;

504) O sistema deverá permitir anexar e visualizar os documentos/arquivos do cidadão ao inserir o mesmo em uma fila de espera ou pelo regulador durante a regulação, permanecendo possível a visualização

destes documentos durante todo o fluxo do registro, até a consulta;

505) Deverá permitir o gestor verificar em forma de relatório o tempo médio de espera nas filas, com base em um período estipulado;

506) Deverá permitir o gestor verificar a ordem dos cidadãos em uma fila;

507) A plataforma deverá conter uma forma de agendamento automático pelo sistema, dos cidadãos que estão na fila de espera, conforme disponibilidade de vagas e ordem de posição do paciente na fila;

508) O sistema deve permitir o operador visualizar todas as filas que um cidadão se encontra, disponibilizando minimamente as informações do tipo da fila, especialidade, ordem, data de entrada na fila.

509) GESTÃO DE FROTAS E TFD

510) Deve conter ferramentas para controle de frotas e TFD (tratamento fora do domicílio).

511) O sistema deve possuir o cadastro de tipos de veículos;

512) O sistema deverá possuir campos para cadastro básico de veículo, contendo, minimamente descrição, tipo, placa, marca, número do chassi, RENAVAM, ano do veículo sua capacidade/lotação, tipo

do combustível e data da validade do extintor de incêndio;

513) Deve permitir a criação de rotas contendo minimamente sua descrição, município de saída e município de destino;

514) Deve possuir cadastro para lançamento de dotações orçamentárias contendo minimamente a descrição e o número;

515) Deve possuir cadastro de recursos contente minimamente a descrição e número;

516) O sistema deve permitir o cadastro de motoristas contendo minimamente o nome, CPF, telefone, endereço, município, complemento, CEP, tipo de veículo de condução, número da sua carteira de

habilitação, categoria da carteira, data do vencimento da carteira;

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

518) Deve possuir cadastro de eventos do veículo;

519) Deve possuir funcionalidade ou mecanismo para lançamento de eventos para cada veículo contendo minimamente 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;

520) O sistema deve gerar aviso/alerta para o operador 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;

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

522) Deve possuir cadastro de tipos de despesa e adiantamentos contendo minimamente sua descrição e seu valor unitário;

523) Deve possuir cadastro de destinos contendo minimamente nome, município onde se localiza e telefone;

524) Deve possuir registro de viagem, informando minimamente data e hora da saída, data e hora prevista para retorno, tipo da viagem, auxiliar, motorista, veículo, local de destino, cidade de destino, rota,

dotação orçamentária e recurso;

525) Nesta mesma ferramenta supracitada, deve permitir que sejam atrelados a cada viagem os cidadãos e acompanhantes com seus devidos locais de saída hora da saída, locais de destino, telefone, documentos, tipo da viagem (ida, ida e volta), acompanhantes, data do aviso ao cidadão, horário do aviso e observação;

526) Deve permitir o gerenciamento das viagens permitindo o gestor visualizar a quantidade de vagas disponíveis por ida e quantidade de vagas disponíveis por volta;

527) Deve permitir no cadastro da viagem que sejam relacionados Km inicial, km final, nome da empresa (no caso de terceira) valores adiantados e km rodados;

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

529) A plataforma deve possuir funcionalidade ou mecanismo para lançamentos das despesas da viagem contendo minimamente a informações como data e hora de saída, data e hora da 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 campo texto livre e campo indicativo permitindo informar se a viagem já foi finalizada;

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

531) Nesta mesma ferramenta supracitada, o sistema deve permitir que sejam lançados todos os itens da manutenção contendo minimamente 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 livre para observações;

532) A aplicação deve possuir mecanismo para lançamento de acertos de manutenção com o fornecedor contendo minimamente 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;

533) Deve possuir mecanismo para lançamento de gastos gerais com veículo por tipo de gasto, incluindo a data da autorização, fornecedor, veículo, quilometragem, motorista, documento de referência, item, quantidade, valor e indicação se o mesmo foi autorizado ou cancelado;

534) A aplicação deve possuir mecanismo para gerenciamento 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;

535) O sistema deve permitir adicionar créditos ao fornecedor contendo minimamente a data, o fornecedor, qual o item ao qual o crédito é realizado, valor e quantidade;

536) O sistema deve possuir mecanismo para gerenciamento de solicitações de ambulância contendo minimamente a data da solicitação, data e hora da saída, cidade de destino, local de destino, veículo, motorista, pacientes na ida e pacientes no retorno e campo livre para anotações;

537) A solução deve possuir mecanismo que permita um controle em filas de espera para processos de TFD;

538) A solução deve possuir mecanismo que permita a publicação das filas de espera para transporte na internet para consultas públicas (sem necessidade de login) ao sistema;

539) A plataforma deve 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;

540) O sistema deve permitir que sejam criados os processos de TFD contendo minimamente número do processamento, data da abertura, cidadão, profissional responsável, CID, tratamento solicitado, tipo do atendimento e um campo texto livre para justificativa;

541) Deve permitir para cada processo de TFD haver a indicação da situação do processo, se o mesmo foi autorizado, cancelado enviado para o estado, negado ou se está inconcluso e um campo livre texto para justificativa da situação e um campo livre texto observações gerais;

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

543) A solução deve permitir realizar o lançamento de todas as viagens necessárias para o processo TFD, contendo minimamente a data da solicitação, cidade e local de destino, transporte recomendado, veículo, motorista, data e hora da viagem, campo para observação da viagem, previsão de retorno e campo de observação para a previsão de retorno;

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

545) Deve disponibilizar informações referentes ao andamento dos processos de TFD nas recepções das unidades de saúde, contendo minimamente o cidadão, a situação e o número do processo;

546) Deve possuir mecanismo para geração automática dos procedimentos de transporte do cidadão e seu acompanhante, com base na quilometragem percorrida;

547) Deve possuir controle de manutenção e do abastecimento dos veículos.

548) GESTÃO DA REDE DE FRIO

549) Parte do SRES responsável por fazer a gerência dos imunobiológicos disponíveis na Secretaria de Saúde.

550) Deverá permitir o cadastramento das doses de vacinas a serem fornecidas;

551) Deverá possuir o cadastro de vacinas contendo minimamente a descrição e a ordem na carteira de vacinação do paciente;

552) Deverá permitir o cadastramento de grupos para imunização;

553) O sistema deverá permitir o cadastramento das faixas etárias utilizadas na imunização, de forma personalizável, contendo minimamente a descrição, idade inicial e idade final e sexo;

554) Deverá possuir funcionalidade para cadastramento de imunizações, contendo minimamente a vacina, a dose, as faixas etárias e o sexo;

555) Deverá permitir o cadastramento dos calendários de vacinação;

556) Deverá possuir o cadastro detalhado de tempos para utilização nos calendários de vacinação contendo minimamente a descrição, o calendário de vacinação onde será utilizado, idade inicial em anos, mês e dia e a idade final em anos, mês e dia;

557) Deverá ser capaz de registrar todas as imunizações administradas ao cidadão, contendo minimamente as informações de data da aplicação, lote, validade, dose, tipo de imunobiológico e todas as demais requeridas pelo SI-PNI e e-SUS, ficando estas informações registradas no prontuário do cidadão;

558) Deverá permitir o cadastramento e gerenciamento das salas/módulos de vacinação disponíveis da rede municipal de saúde contendo minimamente descrição e a unidade de saúde onde está localizada;

559) Deverá possuir controle de estoque de imunizações minimamente por lote e validade, deverá possibilitar o gerenciamento e controle de estoque por cada sala/módulo;

560) Deverá possuir funcionalidade para cadastramento dos tipos de baixa a serem utilizados pela imunização;

561) Deverá ser capaz de gerar alerta internamente no sistema, todo cidadão que possui carteira de vacinação e o mesmo estiver com qualquer vacina em atraso deve gerar um aviso/alerta para o operador, em qualquer operação e módulo do sistema;

562) Deverá ser capaz de cadastrar as alergias do cidadão no cadastro da aplicação da vacina;

563) Deverá gerar aviso/alerta de todas as alergias cadastradas para o cidadão, para fins de visualização do operador, minimamente na carteira do cidadão e na aplicação de uma vacina;

564) Deverá controlar o calendário de vacinação incluindo intervalo mínimo e recomendado entre as doses do mesmo imunobiológico, bem como idade mínima e máxima do cidadão que pode receber a dose, sendo que a plataforma utilizará estes valores para realizar o aprazamento automaticamente das próximas doses no prontuário do cidadão;

565) Deverá permitir a atualização do registro de vacinação do cidadão por meio de inserção manual de registros realizados fora da rede municipal, com destaque de que se trata de atualização manual e não aplicação de imunobiológico;

566) 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;

567) Deve permitir o lançamento de vacinas que não fazem parte do calendário de vacinação normal do cidadão;

568) Deve possuir mecanismo que permita o lançamento de imunizações através de planilhas de digitação contendo minimamente o nome do cidadão, a carteira de vacinação o profissional que realizou a imunização, a vacina, dose, lote/validade e quantidade, e deve permitir firmar a situação de gestante para cidadã;

569) Deve possuir mecanismo para registrar as entradas de imunizações, alimentando automaticamente o controle de estoque;

570) Deve permitir o gerenciamento de estoque pelo gestor, permitindo realizar acerto dos valores do estoque da imunização para o lote/validade já existentes, podendo diminuir a quantidade em estoque ou aumentar a quantidade em estoque;

571) Deve possuir mecanismo ou funcionalidade para controle de transferências de imunizações entre as salas/módulos de vacinação;

572) Deverá possuir mecanismo para gerenciamento das saídas de imunizações contendo minimamente as salas/módulos de vacinação, a data da saída, o motivo/tipo da baixa, as vacinas, lote/validade e quantidade;

573) Deve possuir mecanismo ou funcionalidade que permita o acompanhamento da movimentação do estoque de imunizações por salas/módulos de imunização, permitindo o gestor verificar a disponibilidade dos produtos por tipo de imunobiológico, permitindo monitorar o total de imunizações utilizadas e aplicadas, as perdas físicas e perdas técnicas;

574) Deve ter a possibilidade de fazer o envio das aplicações ao sistema oficial do governo SI-PNI e e- SUS, conforme o tipo de estabelecimento;

575) Deve permitir a impressão da caderneta de vacinação;

576) Deve possuir relatório de balanço físico de imunizações por sala/módulo de imunização;

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

578) Deve possuir relatório de acompanhamento de imunizações por bairro;

579) Deve possuir relatórios de gerenciamento com a visualização dos movimentos de estoque de mensal das imunizações;

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

581) Deve permitir o gestor verificar em forma de relatório a existência de imunizações atrasadas;

582) Deve permitir o gestor verificar as vacinações realizadas, e lista de vacinados por tipo de vacina;

583) Deve disponibilizar de mecanismo para importação de dados legados do sistema SIPNI, possibilitando a importação dos cidadãos e das vacinas aplicadas por cidadão;

584) Deve possuir integração com o RNDS para envio de vacinas do COVID, conforme layout e especificações técnicas do e-SUS.

585) DISPOSITIVOS MÓVEIS

586) Prevê o uso de dispositivos móveis, do tipo tablet, para coleta de dados de agentes comunitário de saúde, no exercício diário de suas atividades.

587) O aplicativo deve funcionar nos dispositivos móveis minimamente sob a plataforma ANDROID;

588) Deve trabalhar off-line, não necessitando de internet ou outro tipo de rede para funcionamento, exceto para enviar e receber informações com o servidor;

589) Deve solicitar usuário e senha para conectar-se ao servidor e para o acesso ao aplicativo;

590) Deve gerenciar a micro área de cada agente de saúde;

591) Deve receber do servidor todas os dados cadastrais dos domicílios, famílias e seus integrantes, do servidor referentes à micro área do agente de saúde que opera o dispositivo móvel;

592) Deve alertar quando existem dados para serem sincronizados;

593) Deve possibilitar o envio dos registros novos ou atualizados para o servidor, receber e fazer atualização de dados mais atuais daqueles que o aplicativo está gerenciando;

594) Deve ser compatível com as fichas e regras cds do e-sus, contendo minimamente as fichas de cadastro individual, ficha de cadastro individual, ficha de cadastro domiciliar, ficha de marcadores de consumo alimentar;

595) Deve estar disponível na loja virtual Google Play com download gratuito para instalação e atualização;

596) Deve relacionar todas os domicílios que a micro área possui cadastrados;

597) Deve possuir diversas formas de pesquisa de domicílios, tais como por logradouro, bairro ou mesmo pelo nome de qualquer dos integrantes, bem como CNS-Cartão SUS, entre outros;

598) Deve possibilitar inclusão ou atualização de dados cadastrais de cada domicílio no formato exigido pelo e-SUS;

599) Deve possibilitar inclusão ou atualização de dados cadastrais das famílias para cada domicílio;

600) Deve possibilitar inclusão ou atualização de dados cadastrais de cada integrante do domicílio e informar a qual família ele pertence;

601) Deve possibilitar identificar o chefe da família;

602) Deve possibilitar ao agente de saúde, gerenciar suas visitas domiciliares, no formato e-SUS;

603) Deve solicitar os dados da visita domiciliar seguindo o modelo especificado pelo e-SUS;

604) Deve possibilitar ao agente de saúde, identificar os domicílios que ainda não foram visitados nos últimos 7, 15, 30, 60 e mais dias e também exibir a data da última visita efetuada em cada um;

605) Deve realizar as validações necessárias com base nas regras de validação por ficha do e-SUS;

606) Deve possuir tabela cadastral de todos os países e municípios do Brasil, e para essas tabelas uma forma de pesquisa que faça o trabalho de auto completar, facilitando a seleção do registro desejado;

607) Deve capturar o posicionamento das coordenadas GPS durante todo o trabalho da ACS bem como em qualquer ação que venha a realizar utilizando o sistema;

608) Deve gerar LOG em todas as atividades que a ACS venha a realizar utilizando o aplicativo;

609) Deve fornecer um cadastro e gerenciamento de ocorrências adversas enfrentadas pela ACS, tanto na Visita Domiciliar como em qualquer momento que isso venha a ocorrer, acrescentando ainda a inclusão de imagens (fotos) acompanhadas de um descritivo informando o que é observado na imagem coletada;

610) Deve permitir a transferência cadastral de Integrantes entre micro áreas, através de solicitação no próprio aplicativo, evitando recadastro de integrantes;

611) Deve permitir a ação de coleta de imagem (foto) do Integrante no momento da realização da Visita Domiciliar, bem como coletar sua assinatura e possibilitar também à ACS registrar sua assinatura. Nas assinaturas, o sistema deve gravar o posicionamento GPS visível na imagem;

612) Deve possibilitar a coleta de imagem (foto) de cada integrante no cadastro individual;

613) Xxxx permitir que a ACS capture sua própria imagem através de foto capturada pelo próprio dispositivo, armazenando essa imagem no servidor;

614) Deve permitir o preenchimento de formulário para marcadores de consumo alimentar, realizando as validações do e-SUS, impedindo erros de digitação;

615) Deve permitir a realização de visitas domiciliares e coleta de marcadores de consumo alimentar, também em integrantes que não estejam cadastrados no micro área da ACS;

616) Deve possibilitar a edição de um local para informações extras nos domicílios no caso de visitas domiciliares, essas anotações são de caráter individual de cada ACS;

617) Deve disponibilizar no próprio aplicativo, acesso a vídeo aulas online sobre a operacionalização do aplicativo.

Document Metadata

Table of Contents

ESTADO DE SANTA CATARINA MUNICIPIO DE RIO DAS ANTAS

Document Metadata