PREGÃO (PRESENCIAL) n° 009/2022

PREGÃO (PRESENCIAL) n° 009/2022

Edital nº. 020/2022

Processo Administrativo Municipal n° 022/2022

OBJETO: CONTRATAÇÃO DE EMPRESA ESPECIALIZADA EM LICENCIAMENTO DE SISTEMA DE GESTÃO EM SAÚDE, EM PLATAFORMA WEB, PARA SER UTILIZADO PELA REDE MUNICIPAL DA SAÚDE, APLICANDO AS MELHORES PRÁTICAS EM GERENCIAMENTO DE PROJETOS, COMPREENDENDO: GESTÃO DE IMPLANTAÇÃO, GESTÃO DE PÓS-IMPLANTAÇÃO, TREINAMENTO, SUPORTE TÉCNICO E SERVIÇOS BÁSICOS.

CRITÉRIO DE JULGAMENTO: MENOR VALOR UNITÁRIO DO ITEM

DATA DA REALIZAÇÃO: Dia 13 DE ABRIL DE 2022.

HORÁRIO DE INÍCIO: 14h30min – horário de Brasília (início do credenciamento).

LOCAL DA REALIZAÇÃO DA SESSÃO: Sala de licitações da Prefeitura Municipal. A sessão será conduzida pelo(a) Pregoeiro(a), com o auxílio da Equipe de Apoio, designados pela Portaria nº. 004/2022. Os envelopes contendo a proposta e os documentos de habilitação serão recebidos na sessão de processamento logo após o credenciamento das empresas interessadas.

ESCLARECIMENTOS: Setor de Licitações e Compras da Prefeitura Municipal de Cachoeira Paulista, e-mail: xxxxxxxxxx@xxxxxxxxxxxxxxxxx.xx.xxx.xx, telefone: (00) 0000-0000 e 0000-0000.

A Prefeitura Municipal de Cachoeira Paulista torna público que se acha aberta a licitação na modalidade PREGÃO (presencial), conforme estabelecido neste instrumento convocatório. Este certame será regido pela Lei Federal nº 10.520, de 17 de julho de 2002, aplicando-se, subsidiariamente, no que couberem, as disposições da Lei Federal nº 8.666/93 e atualizações posteriores, da Lei Complementar nº 123, de 14 de dezembro de 2006.

As propostas deverão obedecer às especificações e exigências constantes deste instrumento convocatório.

Integram este Edital os anexos:

I – Termo de Referência; II - Minuta de Contrato;

III - Modelo de Declaração de Habilitação;

IV - Modelo de Declaração de Microempresa e Empresa de Pequeno Porte;

V - Modelo de Declaração de Situação Regular Perante o Ministério do Trabalho; VI – Modelo de Proposta Comercial;

1- CONSIDERAÇÃO INICIAL

1.1- O objeto contratado em decorrência da presente licitação poderá sofrer, nas mesmas condições, acréscimos ou supressões do valor inicial, nos termos do artigo 65, § 1º, da Lei

Federal nº 8.666/93 e atualizações posteriores.

2- PARTICIPAÇÃO

2.1- Poderão participar deste pregão empresas interessadas do ramo de atividade pertinente ao objeto desta licitação que atenderem às exigências de habilitação.

2.2- Não será permitida a participação de empresas:

2.2.1- Estrangeiras que não funcionem no País;

2.2.2- Reunidas em consórcio, qualquer que seja sua forma de constituição;

2.2.3- Que estejam cumprindo penalidade de suspensão temporária para licitar e impedimento de contratar com a Administração nos termos do inciso III do artigo 87 da lei 8.666/93 e suas alterações posteriores;

2.2.4- Impedidas de licitar e contratar nos termos do art. 7º da Lei 10.520/02;

2.2.5- Declaradas inidôneas pelo Poder Público e não reabilitadas.

3- CREDENCIAMENTO

3.1- Por ocasião da fase de credenciamento dos licitantes, deverá ser apresentado o que se segue:

3.1.1- Quanto aos representantes:

a) Tratando-se de Representante Legal (sócio, proprietário, dirigente ou assemelhado), instrumento constitutivo da empresa registrado na Junta Comercial, ou tratando-se de sociedade simples, o ato constitutivo registrado no Cartório de Registro Civil de Pessoas Jurídicas, no qual estejam expressos seus poderes para exercer direitos e assumir obrigações em decorrência de tal investidura;

b) Tratando-se de Procurador, instrumento público de procuração ou instrumento particular com firma reconhecida do representante legal que o assina, do qual constem poderes específicos para formular ofertas e lances, negociar preço, interpor recursos e desistir de sua interposição, bem como praticar todos os demais atos pertinentes ao certame. No caso de instrumento particular, o procurador deverá apresentar instrumento constitutivo da empresa na forma estipulada no subitem “a”;

c) O representante (legal ou procurador) da empresa interessada deverá identificar-se exibindo documento oficial que contenha foto;

d) O licitante que não contar com representante presente na sessão ou, ainda que presente, não puder praticar atos em seu nome por conta da apresentação de documentação defeituosa, ficará impedido de participar da fase de lances verbais, de negociar preços, de declarar a intenção de interpor ou de renunciar ao direito de interpor recurso, ficando mantido, portanto, o preço apresentado na proposta escrita,

que há de ser considerada para efeito de ordenação das propostas e apuração do menor preço.

e) Encerrada a fase de credenciamento pelo Pregoeiro, não serão admitidos credenciamentos de eventuais licitantes retardatários.

f) Será admitido apenas 1 (um) representante para cada licitante credenciado, sendo que cada um deles poderá representar apenas um licitante credenciado.

3.1.2- Quanto ao pleno atendimento aos requisitos de habilitação:

• Declaração de pleno atendimento aos requisitos de habilitação e inexistência de qualquer fato impeditivo à participação, que deverá ser feita de acordo com o modelo estabelecido no Anexo III deste Edital, e apresentada FORA dos Envelopes nº. 1 (Proposta) e nº. 2 (Habilitação);

3.1.3- Quanto às microempresas e empresas de pequeno porte:

• Declaração de microempresa ou empresa de pequeno porte visando ao exercício da preferência prevista na Lei Complementar nº. 123/06, que deverá ser feita de acordo com o modelo estabelecido no Anexo IV deste Edital, e apresentada FORA dos Envelopes nº. 1 (Proposta) e nº. 2 (Habilitação).

4- FORMA DE APRESENTAÇÃO DA PROPOSTA E DOS DOCUMENTOS DE HABILITAÇÃO

4.1 - A Proposta e os Documentos de Habilitação deverão ser apresentados separadamente, em envelopes fechados e indevassáveis, contendo em sua parte externa os seguintes dizeres:

Envelope nº 1 – Proposta Comercial Pregão Presencial nº /2022 Denominação da Empresa:

CNPJ:

Envelope nº 2 – Documentos de Habilitação

Pregão Presencial nº /2022 Denominação da empresa: CNPJ:

5- PROPOSTA

5.1 - A Proposta deverá ser apresentada datilografada ou impressa, em língua portuguesa, salvo quanto às expressões técnicas de uso corrente, sem rasuras, emendas, borrões ou entrelinhas, sem cotações alternativas, datada e assinada pelo representante legal do licitante ou pelo procurador.

5.2 - Não serão admitidas, posteriormente, alegações de enganos, erros ou distrações na apresentação das propostas comerciais, como justificativas de quaisquer acréscimos ou

solicitações de reembolsos e indenizações de qualquer natureza.

5.3 - Deverão estar consignados na proposta:

5.3.1 - A razão social da proponente, endereço completo/CEP, telefone/fax, e-mail (se houver) e CNPJ do licitante;

5.3.2- Preço unitário global, em algarismos, expressos em moeda corrente nacional, apurados à data de sua apresentação, sem inclusão de qualquer encargo financeiro ou previsão inflacionária, incluindo, além do lucro, todas as despesas resultantes de encargos, impostos, taxas, tributos, frete e demais despesas diretas ou indiretas relacionadas com o integral fornecimento do objeto da presente licitação;

a) O preço ofertado é fixo e irreajustável e deverá ser apresentado com precisão de duas casas decimais;

b) Para os licitantes que fizerem lances será considerado o último valor ofertado.

5.3.3- Prazo de validade da proposta de, no mínimo, 60 (sessenta) dias corridos, contados a partir da data de abertura dos envelopes, podendo ser prorrogado por acordo das partes;

5.4 – A proposta deverá estar datada e assinada.

5.5 – Marca do produto cotado (fabricante ou nome comercial).

5.6 – Será solicitado ao vencedor deste certame a apresentação de nova proposta, para fins de controle, com valores individualizados por sistema contratado.

6 – DOCUMENTAÇÃO COMPLETA

6.1- No que se refere à DOCUMENTAÇÃO COMPLETA, os licitantes deverão apresentar:

6.1.1- HABILITAÇÃO JURÍDICA, conforme o caso:

a) Em se tratando de sociedades empresárias ou simples, o ato constitutivo, estatuto ou Ata social em vigor, devidamente registrado na Junta Comercial ou no Cartório de Registro Civil de Pessoas Jurídicas, nos termos da lei e conforme o caso, e, ainda, no caso de sociedades por ações, acompanhado de documentos de eleição de seus administradores;

a1) Os documentos descritos no subitem “a” deverão estar acompanhados de todas as alterações ou da consolidação respectiva, conforme legislação em vigor.

a2) Será dispensada da apresentação, no envelope de habilitação, dos documentos referidos no item 6.1.1, a empresa que já os houver apresentado no momento do credenciamento, previsto no item 3 deste edital.

b) Decreto de autorização e ato de registro ou autorização para funcionamento expedido pelo órgão competente, tratando-se de empresa ou sociedade estrangeira em funcionamento no país, quando a atividade assim o exigir;

6.2.2- REGULARIDADE FISCAL E TRABALHISTA

a) Prova de inscrição no Cadastro Nacional de Pessoas Jurídicas do Ministério da Fazenda (CNPJ);

b) Prova de inscrição no Cadastro de Contribuintes Estadual e/ou Municipal, relativo à sede ou ao domicílio da licitante, pertinente ao seu ramo de atividade e compatível com o objeto do certame.

c) Prova de regularidade para com as Fazendas Federal, Estadual e Municipal, mediante a apresentação de:

c1) Certidão Conjunta Negativa de Débitos ou Certidão Conjunta Positiva com Efeitos de Negativa, relativos a Tributos Federais e à Dívida Ativa da União, expedida pela Secretaria da Receita Federal, válida para o estabelecimento matriz e suas filiais, referente à situação do sujeito passivo no âmbito da RFB e da PGFN e abrangendo inclusive as contribuições sociais previstas nas alíneas 'a' a 'd' do parágrafo único do art. 11 da Lei no 8.212, de 24 de julho de 1991.

c2) Certidão de Regularidade Estadual.

c3) Certidão de Regularidade Municipal Mobiliária.

d) Prova de regularidade perante o Sistema de Seguridade Social – INSS mediante a apresentação da CND - Certidão Negativa de Débito ou CPD-EN - Certidão Positiva de Débito com Efeitos de Negativa; (Substituída pela certidão referente ao item B1 – acima)

e) Prova de regularidade perante o Fundo de Garantia por Tempo de Serviço (FGTS), por meio da apresentação do CRF - Certificado de Regularidade do FGTS;

f) Prova de inexistência de débitos inadimplidos perante a Justiça do Trabalho, mediante a apresentação da Certidão Negativa de Débitos Trabalhistas (CNDT) ou Certidão Positiva de Débitos Trabalhistas com Efeito de Negativa, nos termos do Título VII-A da Consolidação das Leis do Trabalho, aprovada pelo Decreto-Lei no 5.452, de 1o de maio de 1943;

g) A comprovação de regularidade fiscal das microempresas e empresas de pequeno porte somente será exigida para efeito de assinatura do contrato/Ata de Registro de Preços;

g.1) As microempresas e empresas de pequeno porte, por ocasião da participação neste certame, xxxxxxx apresentar toda a documentação exigida para fins de comprovação de regularidade fiscal, mesmo que esta apresente alguma restrição;

g.2) Havendo alguma restrição na comprovação da regularidade fiscal, será assegurado o prazo de cinco dias úteis, a contar da data em que for declarado vencedor, nos termos do art. 43, § 1º da Lei Complementar Federal nº 123/06, prorrogáveis por igual período, a critério desta prefeitura, para a regularização da documentação, pagamento ou parcelamento do débito, e emissão de eventuais certidões negativas ou positivas com efeito de certidão negativa;

g.3) A não-regularização da documentação, no prazo previsto no subitem g.1, implicará na decadência do direito à contratação, sem prejuízo das sanções previstas neste edital, procedendo-se à convocação dos licitantes para, em sessão pública, retomar os atos referentes ao procedimento licitatório, nos termos do art. 4º, inciso XXIII, da Lei Federal nº 10.520/02.

6.2.3- QUALIFICAÇÃO ECONÔMICO-FINANCEIRA

a) Certidão negativa de falência, recuperação judicial e extrajudicial, expedida pelo distribuidor da sede da pessoa jurídica.

a1) Nas hipóteses em que a certidão encaminhada for positiva, deve o licitante apresentar comprovante da homologação/ deferimento pelo juízo competente do plano de recuperação judicial/extrajudicial em vigor.

*SUMULA N° 50 - Em procedimento licitatório, não pode a administração impedir a participação de empresas que estejam em recuperação judicial, das quais poderá ser exigida a apresentação, durante a fase de habilitação, Plano de Recuperação já homologado pelo juízo competente e em pleno vigor.

b) Poderão participar do certame os licitantes que apresentarem certidão positiva de recuperação judicial, desde que comprove, pelos documentos hábeis, que o plano de recuperação judicial foi deferido e homologado, por decisão transitada em julgado, do juízo da recuperação judicial. Elucide-se que se trata da decisão concessiva do benefício da recuperação judicial e não da decisão na qual o juízo manda processar a recuperação judicial. No caso da recuperação extrajudicial o licitante deverá comprovar que o plano de recuperação foi homologado judicialmente. A participação do licitante em recuperação judicial e extrajudicial só será permitida, nos termos do plano devidamente homologado.

6.2.4- DOCUMENTAÇÃO COMPLEMENTAR

a) Declaração do licitante, elaborada em papel timbrado e subscrita por seu representante legal, de que se encontra em situação regular perante o Ministério do Trabalho. (Anexo V).

6.2.5- QUALIFICAÇÃO OPERACIONAL

a) Prova de aptidão para o desempenho de atividade pertinente e compatível em características com o objeto desta licitação, por meio da apresentação de atestado(s) expedido(s), necessariamente em nome do licitante, por pessoa jurídica de direito público.

6.3- DISPOSIÇÕES GERAIS SOBRE A DOCUMENTAÇÃO DE HABILITAÇÃO

6.3.1- Os documentos poderão ser apresentados no original, por qualquer processo de cópia, autenticada por cartório competente, autenticada por servidor da administração, ou mesmo cópia simples, desde que acompanhada do original para que seja autenticada pelo Pregoeiro ou por um dos membros da Equipe de Apoio no ato de sua apresentação;

6.3.2- Não serão aceitos protocolos de entrega ou solicitação de documentos

em substituição aos documentos ora exigidos, inclusive no que se refere às certidões;

6.3.3- Na hipótese de não constar prazo de validade nas certidões apresentadas, esta Prefeitura aceitará como válidas as expedidas até 90 (noventa) dias imediatamente anteriores à data de apresentação das propostas;

6.3.4- Se o licitante for a matriz, todos os documentos deverão estar em nome da matriz, e se for a filial, todos os documentos deverão estar em nome da filial, exceto aqueles documentos que, pela própria natureza, comprovadamente, forem emitidos somente em nome da matriz;

6.3.5- Se algum documento apresentar falha não sanável na sessão acarretará a

inabilitação do licitante;

6.3.6- O Pregoeiro ou a Equipe de apoio diligenciará efetuando consulta direta nos sites dos órgãos expedidores na Internet para verificar a veracidade de documentos obtidos por este meio eletrônico.

7- PROCEDIMENTO E JULGAMENTO DAS PROPOSTAS

7.1- No horário e local indicados neste Edital será aberta a sessão pública, iniciando-se pela fase de credenciamento dos licitantes interessados em participar deste certame, ocasião em que serão apresentados os documentos indicados no item 3.1.

7.2- Encerrada a fase de credenciamento, os licitantes entregarão ao(a) Pregoeiro(a) os envelopes nº 1 e nº 2, contendo, cada qual, separadamente, a Proposta de Preços e a Documentação de Habilitação.

7.3- O julgamento será feito pelo critério de menor valor unitário do item, observadas as especificações técnicas e parâmetros mínimos de qualidade definidos neste Edital;

7.4- A análise das propostas pelo Pregoeiro visará ao atendimento das condições estabelecidas neste Edital e seus anexos, sendo desclassificadas as propostas:

7.4.1- Cujo objeto não atenda às especificações, prazos e condições fixados neste Edital;

7.4.2- Que apresentem preço ou vantagem baseados exclusivamente em proposta ofertadas pelos demais licitantes;

7.4.3- Que contiverem cotação de objeto diverso daquele constante neste Edital.

7.5- Na hipótese de desclassificação de todas as propostas, o Pregoeiro dará por encerrado o certame, lavrando-se ata a respeito.

7.6- As propostas classificadas serão selecionadas para a etapa de lances, com

observância dos seguintes critérios:

7.6.1- Seleção da proposta de menor preço e das demais com preços até 10%

(dez por cento) superior àquela;

7.6.2- Não havendo pelo menos três propostas nas condições definidas no item anterior, serão selecionadas as propostas que apresentarem os menores preços, até o máximo de três. No caso de empate das propostas, serão admitidas todas estas, independentemente do número de licitantes;

7.6.3- O Pregoeiro convidará individualmente os autores das propostas selecionadas a formular lances de forma verbal e sequencial, a partir do autor da proposta de maior preço e, os demais, em ordem decrescente de valor, decidindo-se por meio de sorteio no caso de empate de preços;

a) O licitante sorteado em primeiro lugar escolherá a posição na ordenação de lances em relação aos demais empatados, e assim sucessivamente até a definição completa da ordem de lances.

7.7- Os lances deverão ser formulados em valores distintos e decrescentes, inferiores à

proposta de menor valor unitário do item, observada a redução mínima de 1% (um).

7.8- A etapa de lances será considerada encerrada quando todos os participantes dessa etapa declinarem da formulação de lances.

7.9- Se houver empate, será assegurado o exercício do direito de preferência

às microempresas e empresas de pequeno porte, nos seguintes termos:

7.9.1 - Entende-se por empate aquelas situações em que as propostas apresentadas pelas microempresas e empresas de pequeno porte sejam iguais ou até 5% (cinco por cento) superiores à proposta mais bem classificada;

7.9.2 - A microempresa ou empresa de pequeno porte cuja proposta for mais bem classificada poderá apresentar proposta de preço inferior àquela considerada vencedora da fase de lances, situação em que sua proposta será declarada a melhor oferta;

a) Para tanto, será convocada para exercer seu direito de preferência nos termos da LC 123/2006 e apresentar nova proposta no prazo máximo de 5 (cinco) minutos após o encerramento dos lances, a contar da convocação do Pregoeiro, sob pena de preclusão;

b) Se houver equivalência dos valores das propostas apresentados pelas microempresas e empresas de pequeno porte que se encontrem no intervalo estabelecido no subitem 7.9.1, será realizado sorteio entre elas para que se identifique aquela que primeiro poderá exercer a preferência e apresentar nova proposta;

b.1) entende-se por equivalência dos valores das propostas as que apresentarem igual valor, respeitada a ordem de classificação.

7.9.3- O exercício do direito de preferência somente será aplicado quando a melhor oferta da fase de lances não tiver sido apresentada pela própria microempresa ou empresa de

pequeno porte;

7.9.4- Não ocorrendo a contratação da microempresa ou empresa de pequeno porte, retomar-se-ão, em sessão pública, os procedimentos relativos à licitação, nos termos do quanto disposto no art. 4º, inciso XXIII, da Lei 10.520/02, sendo assegurado o exercício do direito de preferência na hipótese de haver participação de demais microempresas e empresas de pequeno porte cujas propostas se encontrem no intervalo estabelecido no subitem 7.9.1;

a) Na hipótese da não-contratação da microempresa e empresa de pequeno porte, e não configurada a hipótese prevista no subitem 7.9.4, será declarada a melhor oferta àquela proposta originalmente vencedora da fase de lances.

7.10- Após a fase de lances, serão classificadas, na ordem crescente dos valores, as propostas não selecionadas por conta da regra disposta no item 7.6.1, e aquelas selecionadas para a etapa de lances, considerando-se para estas, o último preço ofertado.

7.11- Não poderá haver desistência dos lances ofertados, sujeitando-se o licitante desistente às penalidades constantes deste Edital.

7.12- O Pregoeiro poderá negociar com o autor da oferta de menor valor com vistas à redução do preço.

7.13- Após a negociação, se houver, o Pregoeiro examinará a aceitabilidade do menor preço, decidindo motivadamente a respeito.

7.14- Considerada aceitável a oferta de menor preço, no momento oportuno, a critério do Pregoeiro, será verificado o atendimento do licitante às condições habilitatórias estipuladas neste Edital.

7.15- Eventuais falhas, omissões ou outras irregularidades nos documentos efetivamente entregues de habilitação, poderão ser saneadas na sessão pública de processamento do Pregão, até a decisão sobre a habilitação, sendo vedada a apresentação de documentos novos.

7.16- A verificação será certificada pelo Pregoeiro, anexando aos autos documentos passíveis de obtenção por meio eletrônico, salvo impossibilidade devidamente justificada.

7.17- Esta Prefeitura Municipal não se responsabilizará pela eventual indisponibilidade dos meios eletrônicos de informações, no momento da verificação. Ocorrendo essa indisponibilidade e não sendo apresentados os documentos alcançados pela verificação, o licitante será inabilitado.

7.18- Constatado o atendimento pleno dos requisitos de habilitação previstos neste Edital, o licitante será habilitado e declarado vencedor.

7.19- Se a oferta de menor preço não for aceitável, ou se o licitante não atender às exigências de habilitação, o Pregoeiro examinará as ofertas subsequentes, na ordem de classificação, podendo negociar com os respectivos autores, até a apuração de uma

proposta que, verificada sua aceitabilidade e a habilitação do licitante, será declarada vencedora.

7.20- Da sessão será lavrada ata circunstanciada, na qual serão registradas as ocorrências relevantes e que, ao final, será assinada pelo Pregoeiro e Equipe de apoio.

7.21- O Pregoeiro, na fase de julgamento, poderá promover quaisquer diligências julgadas necessárias à análise das propostas, da documentação, e declarações apresentadas, devendo os licitantes atender às solicitações no prazo por ele estipulado, contado do recebimento da convocação.

7.22 – Concluídas as fases de lances e habilitação, a empresa detentora do menor preço será convocada a realizar a demonstração dos produtos ofertados para a certificação de atendimento às exigências do Anexo I – Termo de referência.

7.23 – Na eventualidade da empresa vencedora da fase de lances não comprovar o atendimento às exigências do Anexo I – Termo de referência durante o procedimento de demonstração, conforme descrito no item anterior, serão convocadas as próximas empresas pela ordem de classificação na fase de lances para que o façam, a fim de obter a melhor proposta que cumpra integralmente os requisitos deste certame.

8- DA IMPUGNAÇÃO AO EDITAL DA ADJUDICAÇÃO E DA HOMOLOGAÇÃO

8.1- Até dois dias úteis da data fixada para o recebimento das propostas, qualquer pessoa poderá solicitar esclarecimentos, providências ou impugnar o ato convocatório do Pregão. A petição será encaminhada ao(a) Pregoeiro(a) que decidirá no prazo de 01 (um) dia útil.

8.2- Eventual impugnação deverá ser dirigida ao(a) Pregoeiro e protocolada no setor de Protocolo localizado na Av. Coronel Xxxxxxxxx, nº 92 – Centro – Cachoeira Paulista/SP, XXX 00.000-000, e-mail: xxxxxxxxxx@xxxxxxxxxxxxxxxxx.xx.xxx.xx, telefone: 00 0000-0000 e 3186-

6010.

8.2.1- Admite-se impugnação por meio físico ou eletrônico (xxxxxxxxxx@xxxxxxxxxxxxxxxxx.xx.xxx.xx);

8.2.2- Acolhida a petição contra o ato convocatório, em despacho fundamentado, será designada nova data para a realização deste certame.

8.3- A entrega da proposta, sem que tenha sido tempestivamente impugnado este Edital, implicará na plena aceitação, por parte das interessadas, das condições nele estabelecidas.

8.4. As dúvidas a serem equacionadas por telefone serão somente aquelas de caráter estritamente informal.

8.4- Dos atos do Pregoeiro cabe recurso, devendo haver manifestação verbal imediata na própria sessão pública, com o devido registro em ata da síntese da motivação da sua intenção, abrindo-se então o prazo de três dias que começará a correr a partir do dia em que houver expediente nesta Prefeitura Municipal para a apresentação das razões, por meio de memoriais, ficando os demais licitantes, desde logo, intimados para apresentar contrarrazões, em igual número de dias, que começarão a correr no término do prazo

do recorrente, sendo-lhes assegurada vista imediata dos autos;

8.4.1- Na hipótese de interposição de recurso, o Pregoeiro poderá reconsiderar a sua decisão ou encaminhá-lo devidamente fundamentado à autoridade competente;

8.4.2- O recurso contra decisão do Pregoeiro terá efeito suspensivo e o seu acolhimento resultará na invalidação apenas dos atos insuscetíveis de aproveitamento;

8.4.3- As contrarrazões de recurso devem ser protocoladas no setor de Xxxxxxxxx xx Xxxxxxxxxx Xxxxxxxxx xx Xxxxxxxxx Xxxxxxxx - XX, localizada na Av. Coronel Xxxxxxxxx, nº 92 Centro – Cachoeira Paulista – SP – Xxx 00000-000.

8.5- A falta de manifestação imediata e motivada da intenção de interpor recurso, por parte da(s) proponente(s), importará na decadência do direito de recurso, competindo à autoridade competente homologar o certame e determinar a convocação dos beneficiários para a assinatura do contrato.

8.6- Existindo recurso(s) e constatada a regularidade dos atos praticados e após a decisão do(s) mesmo(s), a autoridade competente deve praticar o ato de homologação do certame e determinar a convocação dos beneficiários para a assinatura do contrato.

9 – DO CONTRATO

9.1. A contratação decorrente desta licitação será formalizada mediante celebração de

termo de contrato, cuja minuta integra este Edital.

9.1.1. Se, por ocasião da formalização do contrato, as certidões de regularidade de débito do adjudicatário perante o Sistema de Seguridade Social (INSS), o Fundo de Garantia por Tempo de Serviço (FGTS) e a Fazenda Nacional estiverem com os prazos de validade vencidos, esta Prefeitura Municipal verificará a situação por meio eletrônico hábil de informações, certificando nos autos do processo a regularidade e anexando os documentos passíveis de obtenção por tais meios, salvo impossibilidade devidamente justificada.

a) Se não for possível atualiza-las por meio eletrônico hábil de informações, o adjudicatário será notificado para, no prazo de cinco dias úteis, comprovar a situação de regularidade de que trata o subitem 9.1.1, mediante a apresentação das certidões respectivas com prazos de validade em vigência, sob pena de a contratação não se realizar.

9.1.2. O adjudicatário deverá assinar o instrumento de contrato, no prazo de cinco dias úteis contados da data da convocação, podendo ser prorrogado uma única vez por igual período a critério desta Prefeitura Municipal, sob pena de decair do direito à contratação se não o fizer, sem prejuízo das sanções previstas neste Edital.

9.1.3. Tratando-se de microempresa ou empresa de pequeno porte, cuja documentação de regularidade fiscal tenha indicado restrições à época da fase de habilitação, deverá comprovar, previamente à assinatura do contrato, a regularidade fiscal, no prazo de cinco dias úteis, a contar da publicação da homologação do certame, prorrogável por igual período, a critério desta Prefeitura Municipal, sob pena de a contratação não se

realizar, decaindo do direito à contratação, sem prejuízo das sanções previstas neste edital.

a) Não ocorrendo a regularização prevista no subitem anterior, retomar-se-ão, em sessão pública, os procedimentos relativos a esta licitação, sendo assegurado o exercício do direito de preferência na hipótese de haver participação de demais microempresas e empresas de pequeno porte, cujas propostas de preços se encontrem classificadas.

b) Na hipótese de nenhuma microempresa e empresa de pequeno porte atenderem aos requisitos deste Edital, será convocada outra empresa na ordem de classificação das ofertas, com vistas à contratação.

9.2. A empresa contratada se obriga a manter, durante toda a execução do contrato, compatibilidade com as obrigações assumidas, assim como todas as condições de habilitação e qualificação, exigidas na licitação, apresentando documentação revalidada se, no curso do contrato, algum documento perder a validade.

9.3. O contrato terá vigência de 12 meses a partir da data da assinatura.

10- DA EXECUÇÃO DOS SERVIÇOS

10.1. Os serviços deverão ser executados nos moldes inscritos no termo de referência, devendo a vencedora cumprir o cronograma aprovado pelo município.

10.2 – A ordem de serviço será expedida após a assinatura do Contrato e indicará: o nome da Empresa, o local da prestação do serviço, e a descrição do serviço a ser executado. A Contratada fica obrigada a prestar o serviço nos termos descritos no termo de referência, sob pena de serem aplicadas as sanções previstas no Contrato.

10.2.1- A Ordem de Serviço será enviada ao fornecedor por meio de fax e/ou e-mail informados na proposta comercial da Empresa; será ônus da empresa vencedora comunicar eventual alteração do fax e do e-mail informados em sua proposta comercial.

10.2.2- O prestador de serviço que, convocado, recusar-se injustificadamente em confirmar o recebimento da ordem de serviço no prazo de 01 (um) dia útil após o recebimento, poderá sofrer as sanções previstas pela inexecução do ajuste.

10.2.3 – A critério da administração, para atendimento das necessidades no ato do início dos serviços, poderá ser fracionada a Ordem de Serviço e não incluir todos os itens do objeto deste certame, ficando o fornecedor obrigado a cumprir em sua totalidade os compromissos e prazos assumidos, para eventual item em que seja emitida Ordem de Serviço posteriormente, contando os prazos a partir da data da emissão deste documento.

10.3 – A contratação do prestador de serviços será formalizada por intermédio de Contrato, com emissão de nota de empenho de despesa, ordem de serviço ou outro similar, conforme disposto no artigo 62, da Lei 8666/93.

10.4- Tendo em vista a atividade exercida em caráter ininterrupta pelo poder público, o prazo para conclusão dos serviços de implantação será de 30 (trinta) dias, contados da assinatura do contrato.

11- DA DOTAÇÃO ORÇAMENTÁRIA

As despesas decorrentes da contratação futura, previstas em R$ 224.120,04 (duzentos e vinte e quatro mil cento e vinte reais e quatro centavos), onerarão os seguintes recursos orçamentários e financeiros:

FUNCIONAL PROGRAMÁTICA	ORGÃO	FICHA	FONTE	ELEMENTO
00.000.0000.0000	08	67	00	0.0.00.00.00
00.000.0000.0000	08	80	00	0.0.00.00.00

12- FORMA DE PAGAMENTO

12.1 – O pagamento será efetuado em até 30 (TRINTA) dias a partir do recebimento do objeto/prestação dos serviços. Para entrega do objeto deverá ser emitida a Nota Fiscal Eletrônica (Portaria CAT nº 173/2009) devidamente atestada pelo setor de Compras de por meio de cheque nominal ou em conta corrente indicada pela empresa contratada.

12.2. - Quando for constatada qualquer irregularidade na Nota Fiscal/Fatura, será imediatamente solicitado ao contratado, carta de correção, quando couber, ou ainda pertinente regularização, que deverá ser encaminhada a esta Prefeitura Municipal no prazo de 24 (vinte e quatro) horas;

12.2.1- Caso a contratada não apresente carta de correção no prazo estipulado, o prazo para pagamento será recontado, a partir da data da sua apresentação.

13- SANÇÕES

13.1. Pela inexecução total ou parcial do objeto deste contrato serão aplicadas ao inadimplente, conforme o caso, as sanções previstas nos artigos nºs 86, 87 e 88 das Leis Federais nºs 8.666/93, 8.883/94 e 9.648/98, ou seja:

13.2. O não cumprimento das obrigações assumidas no presente Contrato ou a ocorrência da hipótese prevista no artigo 78, da Lei Federal n.º 8.666, de 21 de junho de 1993, e no artigo 7º da Lei Federal nº 10.520/02 autorizam, desde já, o CONTRATANTE a rescindir, unilateralmente, o Contrato, independentemente de interpelação judicial, sendo aplicável, ainda, o disposto nos artigos 79 e 80 do mesmo diploma legal, no caso de inadimplência, e ainda, será aplicada multa de 20% (vinte por cento) sobre o valor da contratação.

13.3. No caso da inexecução da prestação de serviços no dia e horários indicados na Ordem de Serviço, ou de sua execução de forma inadequada, caberá a rescisão unilateral do Contrato e aplicação das sanções previstas no artigo 7º da Lei Federal nº 10.520/02, sem o pagamento do valor devido, sem prejuízo de eventuais ações indenizatórias cabíveis contra a Contratada.

14- DISPOSIÇÕES FINAIS

14.1- As normas disciplinadoras desta licitação serão interpretadas em favor da

ampliação da disputa, respeitada a igualdade de oportunidade entre os licitantes, desde que não comprometam o interesse público, a finalidade e a segurança da contratação.

14.2- A homologação do presente certame será divulgada no DOE (Diário Oficial do Estado)

14.3- Os demais atos pertinentes a esta licitação, passíveis de divulgação, serão publicados conforme dispõe a Lei Orgânica Municipal.

14.3.1. O Contrato será publicado conforme dispõe a Lei Orgânica Municipal.

14.4- Após a publicação do Contrato, os envelopes contendo os documentos de habilitação das demais licitantes ficarão à disposição para retirada, pelo prazo de cinco dias, findo o qual serão inutilizados.

14.5- Para dirimir quaisquer questões decorrentes desta licitação, não resolvidas na esfera administrativa, será competente o foro da Comarca de Cachoeira Paulista - SP.

Cachoeira Paulista, 30 de março de 2022.

Xxxxxxx Xxxxxx Xxxxxxx Prefeito Municipal

ANEXO I – TERMO DE REFERÊNCIA

PREGÃO (PRESENCIAL) n° 009/2022

Edital nº. 020/2022

Processo Administrativo Municipal n° 022/2022

OBJETO: CONTRATAÇÃO DE EMPRESA ESPECIALIZADA EM LICENCIAMENTO DE SISTEMA DE GESTÃO EM SAÚDE, EM PLATAFORMA WEB, PARA SER UTILIZADO PELA REDE MUNICIPAL DA SAÚDE, APLICANDO AS MELHORES PRÁTICAS EM GERENCIAMENTO DE PROJETOS, COMPREENDENDO: GESTÃO DE IMPLANTAÇÃO, GESTÃO DE PÓS-IMPLANTAÇÃO, TREINAMENTO, SUPORTE TÉCNICO E SERVIÇOS BÁSICOS.

1. OBJETO

Contratação de empresa especializada em licenciamento de Sistema de Gestão em Saúde, em plataforma Web, para ser utilizado pela rede municipal da Saúde, aplicando as melhores práticas em gerenciamento de projetos, compreendendo: gestão de implantação, gestão de pós-implantação, treinamento, suporte técnico e serviços básicos.

1.1.DETALHAMENTO DO OBJETO

Este objeto tem por finalidade a Locação de Sistema de Gestão em Saúde em plataforma Web para ser utilizado na integração e gestão dos serviços prestados pela rede municipal da Saúde, deste município, dotando-a de recursos tecnológicos e servidores públicos capacitados dentro da unificação e otimização de trabalho, proporcionados pela ferramenta sistêmica pretendida.

Para o desenvolvimento integral deste objeto devem ser adotadas as melhores práticas em gerenciamento de projetos segundo dispõe o guia PMBOK® do Instituto de Gerenciamento de Projeto – PMI®, sendo aceita padronização de gerenciamento de projetos equivalente (similar).

Portanto, a CONTRATADA deverá fornecer seu serviço técnico aplicado através das melhores práticas em gerenciamento de projetos, observando as regras e atividades estruturantes de cada um dos elementos abaixo:

a) Serviço da Gestão de Implantação - Consiste na execução das regras e atividades descritas no Anexo I – A, para colocar o sistema em operação nas unidades e setores da saúde.

b) Serviço da Gestão de Pós-implantação- Consiste na execução das regras e atividades descritas no Anexo I – B, referentes à operação dos serviços continuados nas unidades e setores da saúde.

c) Serviços Básicos - Consiste na execução das regras e atividades descritas no Anexo I – C, referentes aos serviços estruturantes e contínuos para o funcionamento do sistema de gestão informatizado.

d) Detalhamento Tecnológico- consiste no pleno atendimento de todos os requisitos solicitados descritos no Anexo I – D, referentes à tecnologia e regra de negócio estruturante em que o sistema de gestão informatizado deverá apresentar-se.

e) Recursos Humanos do Projeto - consiste no pleno atendimento de todos os requisitos solicitados descritos no Anexo I – E, referentes às responsabilidades e coordenação do desdobramento prático de cada serviço previsto neste projeto.

f) Macrocronograma- consiste no pleno atendimento da solicitação descrita no Anexo I – F, referente às entregas dos trabalhos previstos neste projeto.

g) Prova de Conceito consiste no pleno atendimento da solicitação descrita no Anexo I – G, referente à verificação técnica criteriosa em que a CONTRATANTE irá aplicar à CONTRATADA durante a condução licitatória.

1.2.PMBOK® - PROJECT MANAGEMENT BODY OF KNOWLEDGE

PMBOK® é um conjunto de conhecimentos gerenciado pela organização PMI® - Project Management Institute e de maneira resumida é visto como a mais importante bibliografia de gestão de projetos da atualidade conhecido como “PMBOK®Guide” de autoria da própria organização PMI® pelo Comitê de Padronização - Standards Committee reconhecido em 1999 como um padrão de gerenciamento de projetos pelo ANSI – American National Standards Institute.

Este guia contempla os principais aspectos que podem ser abordados no gerenciamento de um projeto genérico, naturalmente, tornando-se um manual que descreve em detalhes este universo de conhecimentos para o gerenciamento de projetos. Todavia, por sua imensa importância mundial atualmente, tanto no setor privado quanto no público, transformou-se num padrão que é fonte de inspiração para quase todos os outros guias existentes.

Não se trata de uma metodologia de gerenciamento de projetos, e sim, de uma padronização que identifica e nomeia processos, técnicas, regras e métodos, com ciclo de vida estruturado em (1) Iniciação, (2) Planejamento, (3) Execução, (4) Monitoramento e

(5) Encerramento, interagindo com as seguintes Áreas de Conhecimento e Gestão:

a) Gerenciamento de Integração;

b) Gerenciamento do Escopo;

c) Gerenciamento do Tempo;

d) Gerenciamento de Custos;

e) Gerenciamento da Qualidade;

f) Gerenciamento de Recursos Humanos;

g) Gerenciamento de Comunicações;

h) Gerenciamento de Riscos;

i) Gerenciamento das Aquisições;

j) Gerenciamento de Partes Interessadas.

O objetivo da utilização da padronização em gerenciamento de projeto para este escopo de trabalho é garantir que todas as etapas sejam guiadas por normas, métodos, processos e práticas estabelecidas, entregues dentro dos prazos, com plena transparência.

A CONTRATADA poderá utilizar outro padrão de gerenciamento de projeto desde que seja reconhecido e aceitável pela similitude ao “PMBOK®Guide”, tal como são os padrões abaixo:

k) ISO/FDIS 21500:2002 – Orientações sobre Gerenciamento de Projetos (ABNT);

l) NBR – ISO 10006:2000 – Diretrizes para Qualidade no Gerenciamento de Projetos (ABNT);

m) Prince 2™ – Projects in a Controlled Environment;

n) ABNT - Associação Brasileira de Normas Técnicas;

o) ANSI – American National Standards Institute;

p) APMG - Accreditation Professional Managers Group;

q) IPMA - International Project Management Association. Informações adicionais poderão ser encontradas no endereço eletrônico: xxxx://xxxxxx.xxx.xxx.

2. JUSTIFICATIVA

A necessidade de se buscar continua melhoria na prestação de serviços públicos e modernização dos processos e procedimentos no atendimento, bem como a necessidade de se adequar às novas exigências legais e padronização dos serviços públicos, faz com que a Secretaria Municipal de Saúde de Cachoeira Paulista dê continuidade ao processo de informatização da gestão pública através de contratação de empresa especializada no licenciamento de uso de sistema de gestão em plataforma web para rede municipal de saúde. Tendo como prioridade a reestruturação da Rede de Saúde para atender aos usuários do Sistema Único de Saúde – SUS - com efetividade e resolutividade, com informações organizadas e qualificadas, que se dará mediante a adoção de novos e modernos Sistemas de Informação Integrado em Saúde, capaz de coletar e disponibilizar informações altamente precisas, tanto para suportar a continuidade do processo assistencial, como para subsidiar o processo de decisão dos gestores.

A presente contratação pretende, cada vez mais, profissionalizar a gestão pública através de módulos informatizados para áreas que necessitam de controle e transparência.

Assim serão locados sistemas modulares, que deverão ser integrados entre si, ressaltando que a integração trará sinergia possibilitando a ação conjunta setorial, visando obter melhor desempenho. E ainda serão locados sistemas que deverão atender legislações recentes como novo programa Previne Brasil e controle de atendimentos a setores específicos.

Essa ação permitirá reduzir significativamente os retrabalhos e resultará na melhoria do processo de assistência à saúde, por meio de informação fidedigna e atualizada, resultando em ações de saúde mais eficazes.

A importância estratégica desta iniciativa baseia-se por sua inclusão no Programa do Registro Eletrônico em Saúde, exigida pelo Ministério da Saúde aos municípios como plataforma de Informação, promovendo a transparência e subsidiando o processo de gestão do SUS. Sendo assim, o novo sistema, deverá atender totalmente as exigências implementadas pelo Ministério da Saúde.

Com essas medidas, busca a administração pública modernizar seus sistemas para proporcionar melhor atendimento aos cidadãos, mais agilidade e segurança nas informações e melhor controle do erário público, bem como atender totalmente os novos programas do Governo Federal.

3. INFORMAÇÕES DE APOIO

Para suprir a atual demanda dos serviços prestados, este município conta com as seguintes informações:

Censo Demográfico 2021: Sinopse	Cachoeira Paulista - SP	Código: 3508603
População estimada [2021]	33.827	Pessoas

Fonte: Fonte: IBGE, Censo Demográfico 2021.

Para suprir a atual demanda dos serviços prestados ao contingente populacional, o município conta com 200 profissionais, colaboradores diretos e indiretos na área da saúde que deverão ser geridos e aos quais deverá ser disponibilizado o acesso sistêmico.

Os serviços estão alocados nas seguintes unidades prestadoras de serviço:

Secretaria Municipal de Saúde:

PREFEITURA MUNICIPAL DE CACHOEIRA PAULISTA
CNES	Nome Fantasia
6970796	CEO CENTRO DE ESPECIALIDADES ODONTOLOGICAS DR XXXXX XXXXX
7907176	POLO ACADEMIA DA SAUDE XXXXX XXXX XXXXXXXX
5484448	ESF EMBAUZINHO TURMA26
2025175	ESF EMBAU QUILOMBO
3363554	ESF SAO JOAO
3363589	ESF CDHU
5381266	FARMACIA MUNICIPAL
3363562	ESF MARGEM ESQUERDA
6015573	PRAD PROGRAMA DE ALCOOLATRAS E DROGADICTOS
3462196	SERVICO DE ATENDIMENTO EM DST AIDS
6825893	SECRETARIA XXXXXXXXX XX XXXXX XX XXXXXXXXX XXXXXXXX
0000000	ESF VILA CACARRO
5671744	CAPS I XXXXXXXXX XXXXXXXX
0000000	ESF PITEU
5822998	ESF JARDIM EUROPA
2024780	AMBULATORIO MUNICIPAL DE ESPECIALIDADES CENTRO
0039241	ESF VILA CARMEM
0974137	SETOR IMUNIZAÇÃO CACHOEIRA PAULISTA
2024772	SANTA CASA DE MISERICORDIA SAO JOSE
TOTAL DE UNIDADES = 19

Como demonstrado, o município possui uma considerável rede prestadora de serviços, devendo a CONTRATADA utilizar-se da seguinte infraestrutura tecnológica disponível na Secretaria de Saúde.

ANEXO I-A- SERVIÇO DA GESTÃO DE IMPLANTAÇÃO

1. INSTALAÇÃO E IMPLANTAÇÃO DO SISTEMA DE GESTÃO INFORMATIZADO

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

A implantação do sistema consiste na instalação do sistema informatizado e do treinamento equipe de profissionais por parte da CONTRATANTE e da CONTRATADA, visando sua entrada em produção para uso nas unidades, estando suas fases contidas no Plano de Gestão do Projeto.

1.1.CARACTERÍSTICAS DA IMPLANTAÇÃO DO SISTEMA DE GESTÃO INFORMATIZADO

Para a execução da implantação do sistema de gestão informatizado, a CONTRATADA deverá apresentar Plano de Gestão do Projeto que estabeleça as regras e responsabilidades das partes (CONTRATADA e CONTRATANTE) para a efetiva entrega do projeto no cronograma estabelecido.

A CONTRATANTE avaliará ainda, a qualidade das entregas do projeto por meio do seu gerente de projetos, com a observância rigorosa dos critérios que serão adotados para cada pacote de trabalho.

O Plano de Gestão do Projeto voltado para a instalação e implantação do sistema de gestão informatizado deverá conter de forma detalhada:

a) As estratégias para a realização do Evento de Abertura do Projeto;

b) A EAP – Estrutura Analítica do Projeto, contendo as entregas de cada pacote de trabalho de forma detalhada;

c) A lista dos pacotes de trabalho (no mínimo os citados no item “d”, a seguir), caracterizando, detalhadamente, as suas entregas ou subprodutos do projeto, representando o dicionário da EAP;

d) Pacotes de Trabalho:

i) Planejamento: Contempla a realização e entrega de todo o planejamento do trabalho;

Critérios de Aceitação do Pacote de Trabalho:

1. Esboço preliminar do projeto para avaliação da CONTRATANTE entregue dentro do cronograma do projeto;

2. Listagem de atividades executadas pela CONTRATADA para comprovação e aprovação dos serviços executados nas áreas envolvidas pela CONTRATANTE.

ii) Infraestrutura de Apoio:

Contempla a identificação e acompanhamento da entrega da infraestrutura necessária para que os consultores da CONTRATADA possam executar as suas atividades na CONTRATANTE;

Critérios de Aceitação do Pacote de Trabalho:

1. Documentação formal entregue pela CONTRATANTE à CONTRATADA com a indicação da infraestrutura necessária para que os consultores da CONTRATADA possam executar os serviços de implantação e que, no entendimento, é de responsabilidade da CONTRATANTE;

2. E-mail do Gerente de Projetos da CONTRATANTE aprovando a infraestrutura solicitada pela CONTRATADA;

3. Listagem de atividades executadas pela CONTRATADA para comprovação e aprovação dos serviços executados nas áreas envolvidas pela CONTRATANTE.

iii) Infraestrutura de Capacitação: Contempla a identificação e acompanhamento da entrega da infraestrutura necessária para a realização das capacitações de cadastro de tabelas e execução de rotinas operacionais.

Critérios de Aceitação do Pacote de Trabalho:

1. Documentação formal entregue pela CONTRATADA à CONTRATANTE com a indicação da infraestrutura necessária para que os consultores possam executar os serviços de capacitação e que, no entendimento, é de responsabilidade da CONTRATANTE;

2. E-mail do Gerente de Projeto da CONTRATANTE, aprovando a infraestrutura solicitada pela CONTRATADA;

3. Listagem de atividades executadas pela CONTRATADA para comprovação e aprovação dos serviços executados nas áreas envolvidas pela CONTRATANTE.

iv) Lista de Cadastros Prioritários: Contempla a disponibilização, pela CONTRATADA, da lista de cadastros prioritários e seus campos correspondentes para o funcionamento adequado do sistema para posterior identificação dos responsáveis pelos cadastros junto à CONTRATANTE;

Critérios de Aceitação do Pacote de Trabalho:

1. Documentação formal entregue pela CONTRATANTE com a listagem dos cadastros (e seus campos correspondentes) considerados prioritários que deverão ser organizados e preparados previamente pela CONTRATADA, antes da data definida para a realização prática da capacitação em cadastramento de tabelas;

2. Listagem de atividades executadas pela CONTRATADA para comprovação e aprovação dos serviços executados nas áreas envolvidas pela CONTRATANTE.

v) Lista de Informações Preliminares: Contempla a lista de pré- requisitos e/ou ações que a CONTRATANTE deverá providenciar para posterior input no sistema.

Critérios de Aceitação do Pacote de Trabalho:

1. Documentação formal entregue pela CONTRATADA com a listagem de todas as definições e as regras que serão necessárias e que deverão ser organizadas e preparadas previamente, para o fiel cumprimento do cronograma;

2. Listagem de atividades executadas pela CONTRATADA para comprovação e aprovação dos serviços executados nas áreas envolvidas pela CONTRATANTE.

vi) Infraestrutura para a Realização do Evento de Abertura: Contempla a disponibilização da infraestrutura necessária para a realização da reunião de abertura do projeto.

Critérios de Aceitação do Pacote de Trabalho:

1. Documentação formal entregue pela CONTRATADA à CONTRATANTE com a indicação da infraestrutura necessária para a realização do evento de abertura;

2. E-mail do Gerente de Projeto da CONTRATANTE, aprovando a infraestrutura solicitada pela CONTRATADA;

3. Listagem de atividades executadas pela CONTRATADA para comprovação e aprovação dos serviços executados nas áreas envolvidas pela CONTRATANTE.

vii) Plano de Gestão do Projeto: Contempla o plano de gestão do projeto que será parte integrante do contrato firmado entre CONTRATANTE e CONTRATADA;

Critérios de Aceitação do Pacote de Trabalho:

1. Documento Plano de Gestão do Projeto e seus anexos assinados pela CONTRATADA e CONTRATANTE, constando todas as regras do projeto;

2. Listagem de atividades executadas pela CONTRATADA para comprovação e aprovação dos serviços executados nas áreas envolvidas pela CONTRATANTE.

viii) Instalação: Contempla as atividades que serão executadas para a disponibilização da tecnologia para a preparação, cadastramento, parametrização e capacitação dos usuários finais, visando posterior operacionalização do sistema;

Critérios de Aceitação do Pacote de Trabalho:

1. Sistema instalado no Data Center da CONTRATADA como ambiente de Produção, que deverá também, manter um ambiente de contingência, onde, em ambos os casos, serão administrados pela CONTRATADA e estarão disponíveis para acesso pelos usuários nas unidades e áreas envolvidas, entregues dentro do cronograma do projeto. A CONTRATADA poderá solicitar, a qualquer momento, a transferência do sistema para um Data Center próprio, caso haja necessidade.

2. Comprovação em documento formal de que a instalação do sistema foi concluída, com a assinatura do Gerente de Projetos da CONTRATANTE;

3. Listagem de atividades executadas pela CONTRATADA para comprovação e aprovação dos serviços executados nas áreas envolvidas pela CONTRATANTE.

ix) Entendimento dos Processos para a Implantação de Sistema: Contempla a realização de entrevistas com as áreas envolvidas para o conhecimento da sistemática de execução das atividades nas diversas unidades prestadoras de serviços, com a obrigatória documentação do modus operandi vigente que será submetida à aprovação dos responsáveis pelas referidas unidades e gestor do projeto por parte da CONTRATANTE;

Critérios de Aceitação do Pacote de Trabalho:

1. Levantamento da rotina atual detalhada e documentada, validada e assinada pelo responsável da área (por área participante do levantamento);

2. Especificação de Customização, Migração e/ou Integração, identificada e documentada;

3. Documentação formal com a indicação da infraestrutura física e lógica (hardwares e softwares) necessárias para o funcionamento do sistema em cada unidade mapeada para que a CONTRATANTE providencie a devida aquisição no prazo do cronograma formalizado;

4. Listagem das atividades executadas pela CONTRATADA para comprovação e aprovação pela CONTRATANTE, dos serviços executados nas áreas envolvidas.

x) Parametrização: Contempla a configuração e documentação desta etapa (prints de tela), demonstrando como o sistema será operacionalizado quando da entrada em produção;

Critérios de Aceitação do Pacote de Trabalho:

1. Documentação formal da parametrização efetuada, indicando, tela a tela do sistema, a forma de execução da rotina parametrizada para a unidade/área envolvida;

2. Listagem das atividades executadas pela CONTRATADA para comprovação e aprovação pela CONTRATANTE, dos serviços executados nas áreas envolvidas.

xi) Migração: Contempla a identificação, acompanhamento, validação e entrega de todas as migrações identificadas no projeto;

Critérios de Aceitação do Pacote de Trabalho:

1. Consiste na execução das atividades de transferência de dados de um sistema em operação para o sistema contratado que será posto em operação;

2. A migração contempla a identificação, acompanhamento, validação e entrega de todas as migrações identificadas no projeto; A contratada deverá migrar os cadastros existentes.

Será disponibilizado o banco de dados em formato DUMP.

3. Definição entre as partes para a confecção da documentação formal que indicará os critérios das atividades e responsabilidades das partes

- CONTRATANTE e CONTRATADA - para a realização do processo de migração;

4. Atividade analítica de viabilidade técnica com observância de laudo técnico de avaliação a ser elaborado pela CONTRATADA, com a indicação do nível de aceitação dos dados analisados referentes às consistências, inconsistências e irregularidades diagnosticadas, constando a aprovação do Gerente de Projetos da CONTRATANTE.

5. Listagem de atividades executadas pela CONTRATADA para comprovação e aprovação pela CONTRATANTE, dos serviços executados nas áreas envolvidas;

xii) Integração: Contempla a identificação, acompanhamento, entrega e validação de todas as integrações identificadas realizadas no projeto; Critérios de Aceitação do Pacote de Trabalho:

1. Consiste na execução das atividades de estabelecimento de comunicação entre sistemas diversos em operação na CONTRATANTE com o sistema contratado;

2. A CONTRATANTE, em conjunto com a CONTRATADA, planejará e identificará as necessidades de integração de sistemas considerando sempre as condições técnicas envolvidas. Em caso de necessidade de integração com sistemas de terceiros, caberá à CONTRATANTE o estabelecimento de comunicação com o terceiro para viabilizar a realização dos serviços;

3. Documentação formal indicando os critérios de realização da integração de sistemas e as responsabilidades das partes -

CONTRATANTE e CONTRATADA - para a realização da atividade de integração;

4. Listagem de atividades executadas pela CONTRATADA para comprovação e aprovação pela CONTRATANTE dos serviços executados.

xiii) Customização: Contempla a identificação, priorização, acompanhamento e entrega de todas as customizações identificadas no projeto;

Critérios de Aceitação do Pacote de Trabalho:

1. Documentação formal indicando os critérios de realização da customização e as responsabilidades das partes - CONTRATANTE e CONTRATADA - para a realização da atividade de customização;

2. Listagem das atividades executadas pela CONTRATADA para comprovação e aprovação dos serviços executados nas áreas envolvidas pela CONTRATANTE.

xiv) Cargas Externas: Contempla a apresentação de todas as cargas externas que a CONTRATADA e a CONTRATANTE deverão providenciar antecipadamente, dentro do cronograma, para inserção no sistema de gestão integrado;

Critérios de Aceitação do Pacote de Trabalho:

1. Documentação formal com a indicação de todas as cargas externas que o sistema necessita, inclusive com as responsabilidades das partes

- CONTRATANTE e CONTRATADA - para a realização da atividade;

2. Listagem de atividades executadas pela CONTRATADA para comprovação e aprovação pela CONTRATANTE dos serviços executados nas áreas envolvidas.

xv) Cadastros: Contempla o plano de organização e capacitação da realização prática dos cadastros de tabelas pelos usuários que ficarão responsáveis por essa atividade (cadastramento das tabelas no sistema informatizado), devendo conter o mecanismo de acompanhamento e controle da realização dessa atividade para evitar o atraso na entrega dos cadastros por parte da CONTRATANTE. A qualidade da capacitação deverá ser avaliada por cada participante em formulário padrão a ser disponibilizado pela CONTRATADA;

Critérios de Aceitação do Pacote de Trabalho:

1. Agenda da capacitação de cadastramento de tabelas assinado pelo Gerente de Projetos da CONTRATANTE;

2. Lista de presença da capacitação assinada pelos participantes, comprovando a realização do evento (capacitação de cadastramento de tabelas);

3. Avaliação da Capacitação assinada pelos profissionais e Gerente de Projetos da CONTRATANTE;

4. Listagem de atividades executadas pela CONTRATADA para comprovação e aprovação pela CONTRATANTE dos serviços executados nas áreas envolvidas.

xvi) Manuais: Contempla a confecção dos manuais de operação do sistema, segundo a parametrização definida para as áreas envolvidas nas unidades prestadoras de serviço, tendo em vista os seus processos de trabalho, para posterior aprovação da usabilidade de cada manual pelo gestor do projeto por parte da CONTRATANTE;

Critérios de Aceitação do Pacote de Trabalho:

1. Documento formal constando a estrutura do Manual Operacional a ser desenvolvido pela CONTRATADA com a aprovação dessa estrutura pelo Gerente de Projetos da CONTRATANTE;

2. Manual Operacional constando o passo a passo de todas as rotinas das unidades/áreas que utilizam o sistema;

3. Listagem de atividades executadas pela CONTRATADA para comprovação e aprovação pela CONTRATANTE dos serviços executados nas áreas envolvidas;

xvii) Capacitação ao Usuário Final: Contempla o plano de organização e realização da capacitação operacional prática dos usuários finais que executarão as atividades de rotina nas unidades prestadoras de serviços, devendo conter o mecanismo de acompanhamento e controle de realização dessa atividade.

A capacitação deverá ser realizada nas dependências da prefeitura. A capacitação deverá ser organizada a realizada por turma de acordo com o tema / módulo a ser ministrado.

Cada turma deverá ter no máximo 20 profissionais, respeitando o distanciamento social.

A capacitação deverá ser realizada de forma prática, onde o instrutor apresenta o conteúdo e os profissionais realizam simulações práticas no sistema.

A qualidade da capacitação deverá ser avaliada pelos participantes em formulário padrão a ser disponibilizado pela Contratada a fim de identificar a necessidade da realização de reforço de treinamento aos profissionais que tiveram dificuldades em assimilar o conteúdo ministrado.

A proponente deverá disponibilizar Manual Operacional com todo detalhamento das funcionalidades e regras dos sistemas, e de acordo com as parametrizações aplicadas.

O Cronograma detalhado das capacitações deve ser definida e validada entre as partes na fase de planejamento.

Deverão ser capacitados 200 profissionais. Critérios de Aceitação do Pacote de Trabalho:

1. Agenda da capacitação operacional assinada pelo Gerente de Projetos da CONTRATANTE;

2. Lista de presença da capacitação assinada pelos participantes, comprovando a realização do evento (capacitação) nos níveis: operacional, tático e estratégico de acordo com a característica de cada unidade/área envolvida;

3. Avaliação da Capacitação assinada pelos profissionais e Gerente de Projetos da CONTRATANTE;

4. Listagem de atividades executadas pela CONTRATADA para comprovação e aprovação pela CONTRATANTE dos serviços executados nas áreas envolvidas;

xviii) Simulação: Contempla o plano de simulação estruturado segundo a realidade de operação definida no sistema e configurado para as unidades prestadoras de serviços, visando posterior disponibilização do plano de simulação aos usuários finais para que possam simular e treinar a execução das operações que serão executadas no sistema, após a sua

entrada em produção, além dos mecanismos de acompanhamento e controle da efetiva realização da simulação pelos usuários finais; Critérios de Aceitação do Pacote de Trabalho:

1. Listagem constando o plano de simulação para cada unidade/área que utilizará o sistema;

2. Laudo técnico de avaliação a ser elaborado pela CONTRATADA, com a indicação no nível de aceitação da simulação do sistema utilizado pelos usuários, constando a aprovação do Gerente de Projetos da CONTRATANTE;

3. Listagem de atividades executadas pela CONTRATADA para comprovação e aprovação dos serviços executados nas áreas envolvidas pela CONTRATANTE.

xix) Plano de Entrada em Produção: Contempla a apresentação detalhada do planejamento para entrada em produção com as atividades obrigatórias, que são necessárias, antes, durante e imediatamente após a efetiva entrada do sistema em produção. O plano de entrada em produção deverá ser aprovado entre os gerentes de projeto das partes; Critérios de Aceitação do Pacote de Trabalho:

1. Documento formal com a indicação do plano para a entrada do sistema em produção nas unidades/área, segundo o cronograma de implantação, constando a aprovação do Gerente de Projetos da CONTRATANTE;

2. Listagem de atividades executadas pela CONTRATADA para comprovação e aprovação pela CONTRATANTE dos serviços executados nas áreas envolvidas.

xx) Acompanhamento da Entrada em Produção: Contempla as atividades que serão executadas nos primeiros cinco dias, contados a partir da entrada do sistema em produção nas unidades prestadoras de serviços;

Critérios de Aceitação do Pacote de Trabalho:

1. Laudo técnico de avaliação a ser elaborado pela CONTRATADA, com a indicação do nível de aceitação da entrada em produção do sistema utilizado pelos usuários, constando a aprovação do Gerente de Projetos da CONTRATANTE;

2. Listagem de atividades executadas pela CONTRATADA para comprovação e aprovação dos serviços executados nas áreas envolvidas pela CONTRATANTE.

xxi) Critérios de Encerramento do Projeto (Por Fases/Por Pacotes de Trabalho e Encerramento Global): Contempla o plano de encerramento do projeto por fases (pacotes de trabalho) e encerramento global, comprovando a efetiva entrega dos serviços contratados junto ao fornecedor pela CONTRATANTE. Os termos de encerramento somente serão aceitos com a devida aprovação do gerente de projeto da CONTRATADA (do Termo de Encerramento por Fase e do Termo de Encerramento Global) e pela equipe gestora da CONTRATANTE (somente do Termo de Encerramento Global);

Critérios de Aceitação do Pacote de Trabalho:

1. Termo de Encerramento de cada fase e Termo de Encerramento Global do projeto assinados pelo Gerente de Projetos da CONTRATANTE e da CONTRATADA;

2. Listagem de atividades executadas pela CONTRATADA para comprovação e aprovação, pela CONTRATANTE, dos serviços executados nas áreas envolvidas.

OBS.: A entrega de pacote de trabalho somente será considerada como concluída, após a devida aprovação em documento formal por parte dos gerentes de projeto da CONTRATANTE e da CONTRATADA.

e) As responsabilidades das partes em todas as fases do projeto ou em cada pacote de trabalho da EAP;

f) Os riscos preliminarmente identificados e os planos de respostas a esses riscos que garantam a entrega do projeto no prazo pactuado;

g) Os procedimentos para a realização de reuniões de acompanhamento do projeto nos níveis operacional, tático e estratégico, destacando a periodicidade necessária:

1) Reuniões entre os gerentes de projetos; 2) Reuniões para apresentação do Status Report do Projeto; 3) Reuniões para execução do Projeto;

h) O cronograma para execução do projeto;

i) As regras de solicitação de mudança no projeto;

j) Documentação das expectativas identificadas nas diversas áreas envolvidas (partes interessadas no projeto);

k) A sistemática de gerenciamento e comprovação de entrega das expectativas documentadas das diversas áreas envolvidas (partes interessadas no projeto).

1.2.CRONOGRAMA DE TRABALHO

Após a assinatura de contrato entre as partes, a CONTRATADA terá 15 dias corridos para a apresentação do Plano de Gestão do Projeto para avaliação e aprovação por parte da CONTRATANTE.

O prazo limite para a implantação e plena operação do sistema é de 120 dias corridos a contar da data de assinatura do Contrato, devendo todo o seu detalhamento estar contido no Plano de Gerenciamento de Tempo que fará parte do Plano de Gestão do Projeto.

O Plano de Gestão do Projeto deverá apresentar:

a) Consonância com os critérios e diretrizes estabelecidos no edital;

b) Atender ao prazo de implantação do sistema

c) Detalhamento das responsabilidades das partes

d) Detalhamento dos recursos materiais necessários à execução do projeto;

e) Planos de gestão de escopo, tempo, qualidade, risco, comunicação, partes interessadas, integração e recursos humanos, nos termos do organismo internacional que disciplina as melhores práticas em gerenciamento de projeto PMI®– Project Management Institute ou equivalente (similar) de gerenciamento de projetos.

ANEXO I-B - SERVIÇO DA GESTÃO DE PÓS-IMPLANTAÇÃO

1. GESTÃO PÓS-IMPLANTAÇÃO

A Gestão Pós-implantação caracteriza-se pela prestação de serviços continuados após o encerramento do projeto global de implantação de sistema.

Caracterização do serviço: Representa o procedimento de visita mensal às unidades prestadoras de serviços.

Para a execução da Gestão Pós-implantação, a CONTRATADA deverá seguir as atividades do roteiro de trabalho já estruturado pelo Plano de Gestão do Projeto que estabelece as regras e responsabilidades das partes - CONTRATADA e CONTRATANTE - para a efetiva entrega do projeto no cronograma estabelecido.

Neste sentido integram, obrigatoriamente, as seguintes etapas:

1.1. PLANO DE GESTÃO PÓS-IMPLANTAÇÃO:

Consiste no desenho e validação do planejamento do serviço de gestão pós-implantação em que sua estrutura documental deverá ser apresentada através do Plano de Gestão Pós-implantação.

O Plano de Gestão Pós-implantação deverá ser anexado e estar em consonância (conformidade) com o Plano de Gestão do Projeto caracterizado no item “1.1” do Anexo I – A.

Somente após a aprovação do Plano de Gestão Pós-implantação pelas partes envolvidas, será permitido o início efetivo deste serviço. Havendo atraso na aprovação, as responsabilidades deverão ser apuradas e documentadas.

Entrega(s):

a) Plano de Gestão Pós-implantação aprovado pelas partes envolvidas.

1.2. A GESTÃO PÓS-IMPLANTAÇÃO INTEGRA, OBRIGATORIAMENTE, AS SEGUINTES ATIVIDADES:

a) Realização da capacitação continuada para novos servidores das unidades: Caracterização da atividade: Representa a preparação dos novos servidores públicos que ingressaram em qualquer unidade prestadora de serviços na operacionalização das suas atividades que são suportadas pelo sistema;

Todo novo servidor público capacitado no sistema deverá realizar avaliação da eficácia da capacitação e receber o Manual de Operação de suas atividades que são suportadas pelo sistema em operação.

b) Eliminação de dúvidas operacionais na utilização do sistema: Caracterização da atividade: Representa a disponibilização de profissionais da CONTRATADA na sede da CONTRATANTE em caráter permanente para prestar o suporte local e à distância às diversas unidades prestadoras de serviços para a contínua reciclagem dos usuários finais na utilização operacional do sistema;

A cada ciclo trimestral, os serviços prestados pela CONTRATADA às unidades prestadoras de serviços serão avaliados.

c) Recapacitação na operação do sistema:

Caracterização da atividade: Representa a realização de novas capacitações (reciclagem) aos servidores públicos já capacitados anteriormente em qualquer unidade prestadora de serviços na operacionalização de suas atividades que são suportadas pelo sistema;

Todo servidor público recapacitado no sistema deverá realizar avaliação da eficácia da nova capacitação e receber o Manual de Operação de suas atividades que são suportadas pelo sistema em operação.

d) Acompanhamento do nível de utilização do sistema:

Caracterização da atividade: Representa a realização de auditoria periódica e com indicadores previamente definidos para verificar o nível de utilização do sistema nas unidades prestadoras de serviços que tiveram o sistema implantado e estão em plena produção;

O produto dessa atividade deverá servir como base do plano de ação para que a CONTRATADA potencialize o uso do sistema nas unidades prestadoras de serviços que, por qualquer motivo, estejam apresentando índices que comprovem a redução no uso do sistema para a execução de suas atividades.

e) Acolhimento de propostas de customização no sistema: Caracterização da atividade: Representa o recebimento da identificação detalhada das solicitações de customização no sistema efetuadas por qualquer unidade prestadora de serviços da CONTRATANTE;

As customizações solicitadas deverão sempre ser analisadas, detalhadas e deliberadas entre as áreas técnicas da CONTRATADA e da CONTRATANTE;

A CONTRATADA deverá manifestar-se sobre a viabilidade técnica de atendimento das solicitações de customização. As customizações não aprovadas pela CONTRATADA deverão ser acompanhadas de relatório técnico que comprovem a inviabilidade técnica da customização e da indicação de procedimento alternativo para atendimento da demanda apresentada pela CONTRATANTE ou por sua unidade prestadora de serviços.

f) Análise dos Indicadores das Unidades em conjunto com os responsáveis de área:

Caracterização da atividade: Representa o auxílio técnico às unidades prestadoras de serviços na interpretação de seus indicadores padrão que são disponibilizados pelo sistema. O resultado dessa reunião deverá periodicamente ser registrado em ata de reunião, tendo como foco o auxílio ao entendimento das informações já disponíveis no sistema e sem consumo por parte das unidades prestadoras de serviços.

g) Interação com o Setor de Suporte e/ou Setor de Desenvolvimento: Caracterização da atividade: Representa a comunicação da equipe da CONTRATADA internalizada na CONTRATANTE com a sua equipe externa (da Fábrica de Software) com o objetivo de promover a interação adequada para o atendimento tempestivo das demandas apresentadas pelas unidades prestadoras de serviços.

h) Retorno de Solicitações às Unidades:

Caracterização da atividade: Representa a comunicação da equipe da CONTRATADA internalizada com a CONTRATANTE para dar retorno às demandas apresentadas pelas unidades prestadoras de serviços.

i) Atualização do Manual de Operação do Sistema

Caracterização da atividade: Representa a manutenção dos manuais operacionais de uso do sistema, segundo a parametrização adotada em cada unidade prestadora de serviços da CONTRATANTE, mantendo-os

atualizados.

A CONTRATADA deverá consolidar e apresentar a documentação gerada durante a execução das atividades de pós-implantação, minimamente, dos seguintes indicadores:

ATIVIDADES	INDICADORES
Realização de capacitação para novos servidores das unidades	Quantidade de servidores capacitados no mês
Eliminação de dúvidas operacionais na utilização do sistema	Quantidade de servidores orientados no mês
Recapacitação na operação do sistema	Quantidade de servidores recapacitados no mês
Acompanhamento do nível de utilização do sistema	Relatório mensal do nível de utilização preenchido
Acolhimento de propostas de customização no sistema para avaliação	Quantidade de propostas acolhidas no mês
Orientação na utilização dos Indicadores nas Unidades em conjunto com os responsáveis de área	Quantidade de unidades visitadas e responsáveis acolhido no mês
Interação com o Setor de Suporte	Quantidade de contatos realizados com o setor de Suporte no mês
Interação com o Setor de Desenvolvimento	Quantidade de interações realizadas no mês
Retorno de Solicitações às Unidades	Quantidade de retornos efetuados no mês
Realização de Visita Mensal à Unidade	Quantidade de visitas realizadas no mês
Atualização do Manual de Operação do Sistema	Quantidade de manuais atualizados no mês

j) Atualizações das versões do Sistema:

A atualização do Sistema em suas respectivas versões não incidirá em custo adicional à CONTRATANTE.

1.3. CRONOGRAMA DE TRABALHO

Após a assinatura do contrato entre as partes, a CONTRATADA, em caráter obrigatório, terá 15 dias corridos para a apresentação do Plano de Gestão Pós-implantação, contendo, detalhadamente, a sistemática de operacionalização das atividades.

A CONTRATADA deverá considerar a operacionalização da gestão de pós-implantação a partir do 5º mês, perdurando sua execução até o 12º mês de contrato, podendo o serviço ser renovado conforme os termos da Lei, contados a partir da assinatura do Termo de Encerramento do Projeto Global de Implantação do Sistema, previsto para ocorrer em até 04 meses.

O não cumprimento da apresentação do Plano de Gestão Pós-Implantação acarretará penalidades.

ANEXO I-C - SERVIÇOS BÁSICOS

1. SERVIÇOS BÁSICOS

Consiste, durante a vigência do contrato, na execução das regras e atividades descritas em cada elemento abaixo, sendo os serviços estruturantes e contínuos para o funcionamento do sistema de gestão informatizado.

Aos Serviços Básicos integra, obrigatoriamente:

1.1. LICENÇA DE USO

Consiste durante a vigência do contrato a cessão de direito de uso do sistema de propriedade da CONTRATADA para utilização nas unidades, setores e áreas administrativas prestadoras de serviços sociais, sem limitação de usuários.

1.2. SUPORTE TÉCNICO

Consiste em trabalho prático orientado por norma técnica ITIL em que a CONTRATADA deverá gerir a fim de solucionar dúvidas, problemas, ajustes e desenvolvimento técnico relacionado ao sistema de gestão informatizado.

1.2.1. Central de Serviço Técnico

Conforme recomendação ITIL, a CONTRATADA deverá estabelecer sua Central de Serviço Técnico para gerir minimamente as seguintes atividades:

a) Este serviço deverá centralizar toda a comunicação entre a CONTRATANTE e a CONTRATADA referente às solicitações de chamado técnico;

b) Realizar a primeira linha de investigação e diagnóstico do chamado – suporte de 1º nível – a fim de categorizar e atribuir a justa prioridade de nível de serviço, sendo encaminhado aos níveis seguintes e/ou complexos;

c) Monitorar e auditar o andamento resolutivo dos chamados encaminhados;

d) Estabelecer comunicação ativa mantendo o usuário solicitante informado sobre o status da resolução de cada chamado;

e) Realizar entrega dos chamados resolvidos;

f) Encerrar entregas aprovadas;

g) Avaliar cada entrega através de feedback eletrônico e/ou presencial referente à satisfação operacional;

h) Manter um banco de dados dos problemas superados, em que seja possível visualizar detalhadamente todo o histórico percorrido de cada ocorrência;

1.2.2. Ferramenta administrativa de suporte técnico

O sistema de gestão informatizado deverá possuir ferramenta administrativa de suporte técnico a fim de registrar monitorar as solicitações e intercorrências relativas ao sistema classificadas através de método de análise em Nível de Serviço, onde os usuários possam abrir os “Chamados”, para:

a) Reportar dúvidas.

b) Reportar problemas – bugs – identificados.

c) Solicitar ajustes legais.

d) Solicitar melhorias e customizações específicas.

1.2.3. Tipos de Chamado

Deverá conter minimamente os seguintes Tipos de Chamado:

a) Dúvidas – solicitação de atendimento para dúvidas na operação, funcionalidade e/ou modulo de trabalho.

b) Manutenção – manutenção corretiva de bugs recorrente de problemas identificados.

c) Ajuste – desenvolvimento de software para adequação legal.

d) Customização – serviço de desenvolvimento de software para adaptações, melhorias e/ou criações de novas funcionalidades e regras de negócio.

1.2.3.1. Dúvidas:

Caracteriza-se na detecção de dúvidas dos usuários para realização da operação sistêmica:

a) Este serviço está condicionado a identificar qualquer dúvida relatada pelos usuários, unicamente relacionada ao sistema, devendo sua resolução ser programada conforme enquadramento da prioridade;

b) No controle do suporte técnico essa classe de serviço deverá enquadrar- se em quaisquer das prioridades: NÍVEL 1, NÍVEL 2, NÍVEL 3.

1.2.3.2. Manutenção:

Caracteriza-se no aperfeiçoamento sistêmico através do procedimento de manutenção corretiva direcionada a resolver defeitos e falhas de funcionamento do sistema em operação:

a) Este serviço está condicionado a resolver, unicamente, bugs identificados, tais como: erros no próprio código-fonte, telas, relatórios, interfaces com sistema de terceiros, bancos de dados, falhas de segurança, dentre outros. Não faz parte deste serviço de manutenção: melhorias, adaptações e desenvolvimento de novas funções de relatórios, telas de manutenção de dados, funções de negócios e rotinas de controle específicas, ou ainda, alterações na estrutura tecnológica do software;

b) No controle do suporte técnico essa classe de serviço deverá enquadrar- se em quaisquer das prioridades: NÍVEL 1, NÍVEL 2, NÍVEL 3 ou NÍVEL 4.

1.2.3.3. Ajuste:

Caracteriza-se pela modificação do sistema em que seja necessária uma programação adaptativa ou específica para pleno atendimento de mudanças na legislação, advindas das esferas Federal, Estadual e/ou Municipal:

a) Este serviço é direcionado a enquadrar o sistema às regras legais e prazos estabelecidos pelo dispositivo da lei;

b) Por tratar-se de serviço complexo deverá obedecer aos critérios da metodologia de desenvolvimento de software prevista neste projeto;

c) No controle do suporte técnico essa classe de serviço deverá enquadrar- se, ordinariamente, na prioridade de NÍVEL 4.

1.2.3.4. Customização:

Caracteriza-se pelo aperfeiçoamento continuado através do procedimento de desenvolvimento de software das atuais funcionalidades de negócios, bem como desenvolvimento de novas regras de negócio:

a) Este serviço de customização é direcionado, unicamente, a realizar: melhoria de funcionalidades existentes, adição de novas

funcionalidades e criação de novas rotinas e processos de negócio inexistentes no pretendido projeto, devendo obedecer aos critérios da metodologia de desenvolvimento de software prevista no projeto;

b) No controle do suporte técnico essa classe de serviço deverá enquadrar- se, ordinariamente, na prioridade de NÍVEL 4.

1.2.4. Tempo para resolução de cada prioridade:

O tempo máximo para a resolução de cada prioridade deverá ser:

a) NÍVEL 1 – atendimento em até 24 horas para a solução;

b) NÍVEL 2 – atendimento em até 72 horas para a solução;

c) NÍVEL 3 – atendimento em até 96 horas para a solução;

d) NÍVEL 4 – definido sob demanda - o tempo deverá ser acordado entre as partes.

1.2.4.1. Contagem de tempo do chamado técnico:

A contagem de tempo do chamado técnico se dará a partir do momento em que ocorrer o registro de sua abertura.

a) Prioridade NIVEL 1: são situações – problemas – de alto impacto na operação do sistema, cujo não atendimento em curto espaço de tempo causará graves prejuízos de ordem financeira, operacional ou legal, tais como situações de auditoria para a CONTRATANTE ou ainda a terceiros – contribuintes, fornecedores etc.;

b) Prioridade NIVEL 2: são situações – problemas – de médio impacto na operação do sistema cujo não atendimento em médio espaço de tempo causará prejuízos de ordem financeira, operacional ou legal – tais como situações de auditoria para a CONTRATANTE ou ainda a terceiros – contribuintes, fornecedores etc.;

c) Prioridade NIVEL 3: são situações – problemas – que não causarão impactos na operação do sistema, sem prejuízo no fluxo de trabalho e dúvidas sobre a operação das funcionalidades;

d) Prioridade NIVEL 4: são situações de intervenções no código fonte e banco de dados do sistema cujo prazo de entrega deverá ser mensurado e acordado entre as partes.

1.2.5. Norteadores dos Níveis de Serviço:

a) Indicador TAC (Tempo de Atendimento dos Chamados);

b) Definição: Monitoramento do tempo decorrido entre a qualificação do chamado e o envio da resolução;

c) Cumprimento: Mínimo de 80% dos chamados atendidos nos prazos previstos;

d) Período: Apuração mensal;

e) Relatório: Apresentação mensal. Exemplo:

PERÍODO APURADO: JANEIRO
Prioridade	Chamados Abertos	Atendidos	TAC	Cumprimento
Nível 1	10	10	100,00%	Sim
Nível 2	20	18	90,00%	Sim
Nível 3	15	10	66,66%	Não
Nível 4	3	1	33,33%	Não

1.2.6. Limite de tempo para qualificar a prioridade:

A CONTRATADA terá limite de 30 minutos para qualificar a prioridade de cada registro técnico. Qualificado, dar-se-á início ao procedimento de resolução. Todo andamento do chamado técnico será acompanhado pelo solicitante.

1.2.7. Chamados complexos:

Havendo chamado sem clareza ou tecnicamente complexo, caberá à CONTRATADA organizar os esforços necessários juntamente com a CONTRATANTE na obtenção de pleno entendimento e detalhamento da solicitação.

1.2.8. Pacote de atualização:

Ao término resolutivo de cada chamado técnico que resulte em correções, ajustes, adequações, melhorias e/ou adições sistêmicas, deverá ser gerado e aplicado o pacote de atualização ao sistema.

1.3. DESENVOLVIMENTO DE SOFTWARE:

Consiste no procedimento de levantamento, detalhamento, validação, construção e entrega das solicitações qualificadas como ajustes e customizações, visando: adequação legal, melhoria de funcionalidades existentes, adição de novas funcionalidades e criação de novas rotinas e processos de negócio inexistentes no pretendido projeto.

Para cada hora trabalhada deve ser entendido que haja esforço da equipe técnica na realização das seguintes atividades:

a) Abertura da solicitação qualificada;

b) Levantamento e análise preliminar dos processos operacionais, estruturais e funções de negócios dos serviços, unidades e setores envolvidos;

c) Estruturação detalhada da análise preliminar aprovada;

d) Construção da documentação técnica com os devidos fluxos aprovados;

e) Modelagem do banco de dados;

f) Programação;

g) Testes;

h) Entrega aprovada.

A contabilização das horas trabalhadas neste serviço aplica-se exclusivamente aos chamados técnicos qualificados como ajustes e customização, devendo estar contemplado no valor da proposta, sem custos adicionais.

1.4. HOSPEDAGEM DO SISTEMA: APLICAÇÃO E BANCO DE DADOS

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

1.4.1. Administração e alocação de Data Center

Essa necessidade se faz fundamental devendo a CONTRATADA administrar o(s) servidor(es) em que será(ão) instalado(s) o sistema, podendo estar alocada fisicamente em infraestrutura própria ou estar alocada fisicamente em infraestrutura subcontratada (sem prejuízo das responsabilidades contratuais e legais nos termos do artigo 72 da Lei nº 8.666/93).

1.4.2. Características técnicas do Data Center:

Para total garantia deste serviço o Data Center profissional proposto deverá possuir minimamente as seguintes características técnicas:

a) Visão geral:

i) Possuidora de instalações Auditadas SAS70 Tipo-II;

ii) Possuidora de instalações Certificadas ISO 27.001;

iii) Possuidora de instalações TIER-III.

b) Conectividade:

i) Possuidora de infraestrutura nos moldes de acesso “zeromile” para conectividade com as principais e mais importantes operadoras nacionais e internacionais;

ii) Possuidora de vínculo a um segundo Centro de Hospedagem de Dados

– Data Center – para prover total redundância em caso de qualquer tipo de parada ou desastres do principal Centro de Hospedagem de Dados, podendo este estar em território nacional e/ou internacional.

c) Infraestrutura de energia:

i) Desenhado para exceder as especificações Tier-III do UptimeInstitute;

ii) Estruturado para atender 99.992% de garantia de disponibilidade de energia elétrica.

1.5. ADMINISTRAÇÃO DE BANCO DE DADOS

Consiste na disponibilidade de profissional especialista e responsável por gerenciar, instalar, configurar, atualizar e monitorar o SGDB - Sistema Gerenciador De Bancos De Dados - sob a responsabilidade da CONTRATADA, durante a vigência de contrato.

Nesta função, consistem nas seguintes atividades:

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

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

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

iii) O backup deverá ocorrer em local da rede determinado pelo

responsável da CONTRATANTE, que se encarregará de armazenar os dados em mídias, mantendo assim, condições para atender a uma situação de desastre.

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

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

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

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

f) Realizar auxílio à equipe de desenvolvimento e à equipe de testes para maximizar o uso e desempenho do banco de dados;

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

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

Fica a CONTRATADA obrigada a fornecer, mediante solicitação da CONTRATANTE ou obrigatoriamente ao término do contrato, o banco de dados em sua integra. Este processo será validado mediante ao carregamento e abertura completa do banco em um sistema de gerenciamento de banco de dados compatível (como mySQL, SQL Server, PostgreSQL ou Oracle).

ANEXO I-D- DETALHAMENTO TECNOLÓGICO

Consiste no detalhamento tecnológico em que o sistema de gestão informatizado deverá se apresentar para pleno atendimento da rotina de trabalho operante nas unidades prestadoras de serviço.

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

1. ASPECTOS TECNOLÓGICOS DO SISTEMA DE GESTÃO INFORMATIZADO:

1.1. O sistema deverá estar concebido integralmente em plataforma de tecnologia WEB, tendo sua linguagem de programação Interpretada e/ou orientada a objetos devendo todas as suas funcionalidades ser operacionalizadas unicamente através do navegador browser de internet, não sendo aceito o acesso ao sistema através de executáveis, serviços de terminal – Terminal Services – e/ou através de emuladores de terminal – Virtual Machine;

1.2. O SGBD – Sistema Gerenciador de Banco de Dados - deverá ser do tipo relacional com suporte à linguagem estruturada de consulta SQL, multiplataforma, preferencialmente livre de licenças. No caso de licenças pagas deverá a CONTRATADA prever em seu fornecimento quantidade necessária em número suficiente para atender ao projeto, sem ônus para CONTRATANTE;

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

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

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

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

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

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

1.9. O sistema deverá conter segurança nas conexões estabelecidas com seus usuários, assim, deve ser utilizado o Certificado Digital para Servidor Web que garanta a identificação, autenticação, verificação, privacidade e a integridade dos dados trafegados entre o navegador de internet do usuário e o sistema aplicativo hospedado no Centro de Hospedagem de Dados. Garantia mínima:

1.9.1. Canal criptográfico seguro com os usuários – clientes – do sistema utilizando os protocolos seguros SSL/TLS 1.2;

1.9.2. Criptografia de 128 bits;

1.9.3. Compatibilidade com os principais navegadores de internet, acompanhando as atualizações futuras.

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

2. REQUISITOS FUNCIONAIS DO SISTEMA DA REDE MUNICIPAL

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

Salientamos que a nomenclatura utilizada nas “macro” funcionalidades e suas respectivas subfuncionalidades solicitadas constituem-se num mero processo de classificação e organização da informação pretendida e necessária por este projeto, não representando qualquer restrição sistêmica quanto ao sistema que será ofertado.

As “macro” funcionalidades e suas respectivas subfuncionalidades solicitadas deverão estar contidas em um único banco de dados, não sendo aceito uma ou várias macro funcionalidades e/ou subfuncionalidades de trabalho e/ou parte do sistema tenha seu funcionamento em banco de dados desagregados.

2.1. Modulo Ajuda Online

2.1.1. Deve permitir cadastrar os chamados de suporte técnico, contendo no mínimo: data e horário do chamado, unidade, usuário que originou o chamado, nome da funcionalidade, título do chamado, descrição do chamado;

2.1.2. Deve permitir abrir chamados somente das “macro” funcionalidades e

subfuncionalidades que o usuário possui permissão;

2.1.3. Deve permitir anexar arquivos nos chamados;

2.1.4. Deve permitir editar o texto do chamado contendo no mínimo as opções: negrito, sublinhado, itálico, marcadores, alinhar a esquerda, centralizar, alinhar a direita, justificar;

2.1.5. Deve permitir cancelar o envio do chamado registrando o motivo do cancelamento;

2.1.6. Deve gerar automaticamente o número de protocolo do chamado;

2.1.7. Deve permitir controlar chamados lidos e não lidos;

2.1.8. Deve permitir controlar chamados por status contendo no mínimo: solicitação enviada, em atendimento, informações pendentes, solicitação concluída, solicitação finalizada;

2.1.9. Deve permitir registrar as interações com o suporte com no mínimo: nome do atendente, nome do usuário que originou o chamado, data e horário da interação, e descrição da interação.

2.1.10. Deve permitir visualizar e buscar os chamados em atendimento possibilitando visualizar todo o histórico do chamado;

2.1.11. Deve permitir finalizar os chamados resolvidos;

2.1.12. Deve permitir visualizar os chamados finalizados possibilitando visualizar todo o histórico deste chamado.

2.2. Módulo Intranet

2.2.1. Deve permitir enviar mensagens entre os funcionários que utilizarão o sistema, contendo no mínimo: destinatário, unidade do destinatário, título da mensagem, descrição da mensagem, data de envio da mensagem e remetente;

2.2.2. Deve permitir anexar arquivos nas mensagens;

2.2.3. Deve permitir enviar uma mensagem a vários destinatários;

2.2.4. Deve permitir editar o texto da mensagem contendo no mínimo as opções: negrito, sublinhado, itálico, marcadores, alinhar a esquerda, centralizar, alinhar a direita e justificar;

2.2.5. Deve permitir cancelar o envio da mensagem registrando o motivo do cancelamento;

2.2.6. Deve permitir controlar as mensagens lidas e não lidas;

2.2.7. Deve permitir registrar as interações, com no mínimo: mensagem original, nome do usuário que originou o chamado, nome do usuário que interagiu, data e horário da interação e descrição da interação;

2.2.8. Deve permitir escolher se quer visualizar todas as interações ou se quer ocultar as interações;

2.2.9. Deve permitir responder, excluir e arquivar mensagens;

2.2.10. Deve permitir visualizar e buscar as mensagens possibilitando visualizar todo o histórico da mensagem;

2.2.11. Deve permitir organizar as mensagens por pasta contendo no mínimo: caixa de entrada, mensagens enviadas, mensagens arquivadas;

2.2.12. Deve permitir visualizar os chamados finalizados possibilitando visualizar todo histórico do chamado finalizado.

2.3. Módulo Cadastro

2.3.1. O sistema deve permitir bloquear e/ou desbloquear os pacientes do SUS.

2.3.2. O sistema deve diferenciar os pacientes bloqueados dos pacientes desbloqueados.

2.3.3. O sistema deve permitir registrar um motivo ao realizar o bloqueio dos pacientes do SUS.

2.3.4. O sistema deve permitir o desbloqueio de pacientes somente se o usuário do sistema tiver permissão de desbloqueio cadastrada.

2.3.5. O sistema deve apresentar os pacientes do SUS cadastrados, diferenciando-os por status.

2.3.6. O sistema deve permitir cadastrar pacientes do SUS.

2.3.7. O sistema deve permitir registrar óbito para os pacientes.

2.3.8. O sistema deve permitir cancelar o óbito registrado equivocadamente para o paciente.

2.3.9. Ao registrar óbito para um paciente que é responsável familiar e que possui outros residentes no mesmo endereço (domicílio) com cadastro individual na atenção básica diferente do status óbito, o sistema deve permitir atribuir a responsabilidade para outro membro da família.

2.3.10. Ao cancelar o óbito registrado para um paciente que era responsável familiar, o sistema não deve atribuir a responsabilidade (responsável familiar) novamente.

2.3.11. O sistema deve apresentar os pacientes do SUS cadastrados, diferenciando-os por status.

2.3.12. Ao registrar óbito para um paciente, o sistema deve permitir identificar que o paciente faleceu.

2.3.13. O sistema deve permitir alteração dos dados do óbito.

2.3.14. Tanto no cadastro quanto na alteração dos dados de óbito, o sistema deve permitir registrar somente data de óbito menor ou igual à data atual.

2.3.15. O sistema deve permitir registrar somente data da certidão de óbito igual ou maior que a data de óbito.

2.3.16. O sistema deve permitir consultar, cadastrar e alterar os dados cadastrais dos fornecedores.

2.3.17. O sistema deve verificar se o cadastro do fornecedor já existe e deve informar a duplicidade caso o usuário do sistema tente cadastrá-lo novamente.

2.3.18. O sistema deve permitir consultar, cadastrar e alterar os dados das unidades de saúde.

2.3.19. O sistema deve permitir cadastrar setores para as unidades de saúde.

2.3.20. O sistema deve permitir cadastrar o responsável pela unidade de saúde.

2.3.21. O sistema deve permitir cadastrar o responsável pelo setor da unidade de saúde.

2.3.22. O sistema deve permitir exclusão dos responsáveis cadastrados.

2.3.23. O sistema deve verificar se o cadastro da unidade de saúde já existe e deve informar a duplicidade caso o usuário do sistema tente cadastrá-la novamente.

2.3.24. O sistema deve permitir cadastrar, alterar, consultar e excluir cargos.

2.3.25. O sistema deve permitir consultar os dados do paciente cadastrado por nome, data de nascimento, número do prontuário, número do prontuário antigo, número do cartão nacional de saúde (CNS) e nome da mãe.

2.3.26. O sistema deve apresentar os pacientes do SUS cadastrados, diferenciando-os por status (ativo, bloqueado, óbito).

2.3.27. O sistema deve permitir cadastrar os pacientes do SUS.

2.3.28. Se a raça/cor informada for indígena, o sistema deve obrigar a escolha de uma etnia indígena para o paciente.

2.3.29. O sistema deve permitir vincular à unidade de saúde que o paciente do SUS pertence.

2.3.30. O sistema deve permitir informar se o paciente é munícipe, provisório ou de outro município.

2.3.31. O sistema deve permitir vincular o endereço de residência completo do paciente.

2.3.32. O sistema deve permitir cadastrar telefones para contato do paciente e deve obrigar o preenchimento de pelo menos um número de telefone.

2.3.33. O sistema deve permitir registrar a validade do cadastro do paciente.

2.3.34. Se a validade do cadastro expirar, o sistema deve bloquear o cadastro do paciente.

2.3.35. O sistema deve permitir informar se o paciente é safrista, turista ou estudante.

2.3.36. O sistema deve permitir registrar o número da família.

2.3.37. O sistema deve permitir bloquear o cadastro do paciente SUS.

2.3.38. O sistema deve permitir registrar um motivo ao realizar o bloqueio do cadastro do paciente.

2.3.39. O sistema deve permitir desbloquear o cadastro do paciente SUS.

2.3.40. O sistema deve permitir cadastrar um novo logradouro.

2.3.41. O sistema deve permitir registrar o prontuário antigo (físico) do paciente por unidade.

2.3.42. O sistema deve gerar um número novo de prontuário (único) para o paciente SUS, que será utilizado em todas as unidades de saúde.

2.3.43. O sistema deve permitir alterar os dados do cadastro do paciente SUS e deve registrar a data da última alteração e o nome do usuário do sistema que realizou a última alteração.

2.3.44. O sistema deve permitir cadastrar os documentos do paciente SUS: CPF, número do cartão nacional de saúde (CNS), número do título de eleitor, RG, certidão (nascimento, casamento, divórcio) e carteira de trabalho.

2.3.45. O sistema deve permitir indicar se os documentos RG, CPF e CNS são obrigatórios.

2.3.46. O sistema deve verificar se o número do CPF e CNS são válidos.

2.3.47. O sistema não deve permitir duplicidade de cadastro de paciente. Deve verificar por: nome do paciente e data de nascimento, interligando ou com o nome da mãe, ou o nome do pai, ou o município de nascimento.

2.3.48. O sistema deve gerar etiqueta com código de barras contendo no mínimo: nome do paciente, data de nascimento, sexo, número do prontuário, número do cartão nacional de saúde (CNS), unidade de saúde que o paciente SUS pertence, data de emissão, município de residência e número de identificação social (NIS).

2.3.49. O sistema deve gerar o cartão SUS para o paciente contendo no mínimo: número do cartão nacional de saúde (CNS), nome do paciente, data de nascimento, sexo, data de emissão e município de residência.

2.3.50. O sistema deve permitir imprimir etiqueta com código de barras do paciente SUS.

2.3.51. O sistema deve permitir imprimir o cartão SUS do paciente.

2.3.52. O sistema deve permitir consultar os prontuários antigos do paciente por unidade.

2.3.53. O sistema deve permitir gerar e imprimir etiqueta cartão SUS com código de barras contendo no mínimo: nome do paciente, data de nascimento, sexo e número do cartão nacional de saúde (CNS).

2.3.54. O sistema deve permitir gerar e imprimir etiqueta com códigos de barras contendo no mínimo: nome do paciente, data de nascimento, sexo, número do cartão nacional de saúde (CNS) e número do prontuário.

2.3.55. O sistema deve permitir imprimir listagem com os dados cadastrais do paciente SUS.

2.3.56. O sistema deve permitir cadastrar as condições de moradia do paciente SUS que serão utilizadas no atendimento domiciliar na atenção básica: área e microárea do domicílio, tipo do imóvel, localização (urbano ou rural), tipo de domicílio, quantidade de moradores, quantidade de cômodos, energia elétrica, abastecimento de água, tratamento de água, destino do lixo, animais, higiene residencial, benefícios (bolsa família, vale gás, bolsa escola), renda mensal e profissão.

2.3.57. O sistema deve permitir vincular os residentes atuais do domicílio.

2.3.58. O sistema deve permitir excluir os residentes atuais do domicílio.

2.3.59. O sistema deve permitir vincular os dados do profissional responsável pelo cadastro domiciliar: nome do responsável pelo cadastro, unidade, CBO do responsável pelo cadastro, código da equipe e data do cadastro.

2.3.60. O sistema deve permitir consultar o prontuário, nome, data de nascimento e parentesco dos moradores atuais do domicílio.

2.3.61. O sistema deve permitir cadastrar os usuários do sistema, incluindo os profissionais que irão realizar algum tipo de atendimento (pronto atendimento, atendimento odontológico, farmácia, laboratório).

2.3.62. O sistema deve verificar se o e-mail informado é valido.

2.3.63. O sistema deve permitir consultar os dados dos usuários do sistema.

2.3.64. O sistema deve permitir alterar os dados dos usuários do sistema.

2.3.65. Ao realizar uma consulta, o sistema deve permitir diferenciar os usuários do sistema que realizam atendimento dos demais usuários.

2.3.66. Ao realizar o cadastro de profissionais que realizam atendimentos, o sistema deve permitir cadastrar a categoria do registro profissional e o número do registro.

2.3.67. O sistema deve permitir relacionar o usuário do sistema com a unidade de saúde a que ele pertence.

2.3.68. O sistema deve permitir vincular as especialidades médicas somente para os profissionais que realizam atendimentos.

2.3.69. O sistema deve permitir indicar se o usuário do sistema cadastrado poderá ser controlado pelo RH.

2.3.70. O sistema deve permitir registrar os dados de acesso do usuário do sistema: username, expediente de trabalho (horário de trabalho e dias da semana trabalhados), expediente extra de trabalho e obrigatoriedade de troca de senha no próximo acesso.

2.3.71. Quando o usuário do sistema realizar seu primeiro login, o sistema deve obrigar a troca da senha de acesso.

2.3.72. O sistema deve restringir o cadastro de senha de acesso, aplicando critérios de segurança.

2.3.73. Ao cadastrar uma senha, o sistema deve apresentar quais são os critérios de segurança para a criação da senha.

2.3.74. O sistema deve permitir vincular o cargo do usuário do sistema.

2.3.75. O sistema deve permitir imprimir listagem com os dados de acesso (login) do usuário do sistema.

2.3.76. O sistema deve registrar a quantidade de login que o usuário do sistema realizou até a data atual.

2.3.77. O sistema deve permitir registrar o tempo máximo de permanência no sistema.

2.3.78. O sistema deve permitir que o administrador do sistema resete a senha do usuário que não consiga acessar o sistema por motivo de esquecimento da senha cadastrada.

2.3.79. O sistema não deve permitir exclusão de especialidade médica, caso o profissional possua histórico de atendimento.

2.3.80. O sistema deve permitir imprimir listagem dos usuários do sistema cadastrados.

2.3.81. O sistema deve permitir cadastrar os dados que serão gerenciados pelo RH: data de admissão, data de demissão, salário fixo, salário variável, plantão (horas), data de início na saúde, função, insalubridade, periculosidade, programa de incentivos, adicional noturno, carga horária de trabalho e readaptação.

2.3.82. O sistema deve permitir imprimir listagem com os dados cadastrais detalhados do usuário do sistema.

2.3.83. O sistema deve permitir imprimir listagem com os dados cadastrais do usuário do sistema pertinentes ao RH.

2.3.84. O sistema deve permitir imprimir listagem com as especialidades médicas cadastradas para o profissional que realiza atendimentos.

2.3.85. O sistema deve permitir bloquear e/ou desbloquear o acesso (login) do usuário do sistema.

2.3.86. Ao realizar login, o sistema deve informar que o acesso do usuário do sistema está bloqueado.

2.3.87. O sistema deve permitir cadastrar, alterar e consultar os logradouros que serão utilizados no cadastro de pacientes do SUS.

2.3.88. O sistema deve permitir exclusão de logradouro somente se o logradouro não tiver cadastrado para nenhum paciente.

2.3.89. O sistema deve permitir cadastrar permissões de classificação (paciente é munícipe, provisório ou de outro município) que cada usuário do sistema poderá informar ao realizar o cadastro de pacientes do SUS.

2.3.90. O sistema deve permitir alterar as permissões de classificação registradas para os usuários do sistema.

2.3.91. O sistema deve permitir consultar as permissões cadastradas para os usuários do sistema.

2.3.92. O sistema deve permitir excluir as permissões cadastradas.

2.3.93. O sistema deve permitir cadastrar e alterar permissão que indique quais usuários do sistema poderão desbloquear os pacientes do SUS que estão bloqueados.

2.3.94. O sistema deve permitir transferir as movimentações (histórico) de um usuário do sistema para outro usuário do sistema.

2.3.95. O sistema deve permitir excluir o usuário do sistema que teve seu histórico transferido.

2.3.96. O sistema deve permitir consultar o paciente por nome, data de nascimento e número do prontuário para registro da recusa de atendimento.

2.3.97. O sistema deve permitir registrar o motivo da recusa do atendimento do paciente SUS.

2.3.98. O sistema deve permitir alterar o motivo da recusa do atendimento do paciente SUS.

2.3.99. O sistema deve permitir consultar as recusas de atendimento do paciente SUS.

2.3.100. O sistema deve permitir gerar e imprimir a certidão de recusa de atendimento do paciente SUS.

2.3.101. O sistema deve apresentar na certidão de recusa de atendimento o nome do paciente, nome da unidade de saúde, data (data e horário), nome do responsável (usuário do sistema) e o motivo pelo qual não foi realizado o atendimento do paciente SUS.

2.4. Módulo Painel de Controle

2.4.1. Deve possuir sistema de permissão possibilitando definir o que cada usuário e/ou grupo de usuários poderão ter acesso;

2.4.2. O Sistema de permissão deve possibilitar definir vários níveis de acesso: consulta simples, consulta completa, alteração, exclusão e impressão;

2.4.3. Deve possuir opção para excluir todas as permissões do usuário sem a necessidade de entrar em cada funcionalidade;

2.4.4. Deve possuir opção para atribuir todas as permissões de um usuário ou de um grupo;

2.4.5. Deve possuir tela de monitoramento on-line, onde seja possível visualizar em uma única tela todos os usuários conectados simultaneamente no sistema, as últimas falhas de acesso, o último acesso válido, o último desbloqueio e o usuário com maior número de acessos;

2.4.6. Deve possuir ferramenta para bloquear e desbloquear usuários;

2.4.7. Deve possuir ferramenta para criar senha aos usuários;

2.4.8. Deve permitir cadastrar os dias da semana e horários que cada usuário pode acessar o sistema;

2.4.9. Deve permitir cadastrar o tempo de acesso de cada usuário;

2.4.10. Ao expirar o tempo de acesso permitido o sistema deve alertar se o usuário quer manter conectado ou não, se não houver confirmação, o sistema deve fechar automaticamente;

2.4.11. Deve solicitar a troca de senha periodicamente;

2.4.12. Deve bloquear o usuário que ficar sem acessar por um de tempo pré-definido;

2.4.13. Deve possuir relatórios de acesso com no mínimo: nome do usuário, data e horário de entrada, data e horário de saída, IP, status do acesso (sucesso ou falha);

2.4.14. Deve prever relatório de acesso a funcionalidades com no mínimo: data e horário do acesso, módulo, funcionalidade, usuário, total de acessos;

2.4.15. Deve prever relatório de permissão com no mínimo: usuário do sistema com permissão, módulo, funcionalidade, unidades, e níveis de permissão (consulta simples, consulta completa, imprimir, cadastrar, alterar, excluir);

2.4.16. Deve permitir o cadastro de feriados e pontos facultativos contendo no mínimo: descrição do feriado, tipo do feriado (municipal, estadual, federal, facultativo), dia do feriado, mês do feriado, ano do feriado;

2.4.17. Deve possuir tabela SIGTAP integrada no sistema;

2.4.18. Deve prever atualizações automáticas das tabelas e layouts de arquivos dos programas do Ministério da Saúde, Secretaria de Estado da Saúde e legislação municipal, de acordo com os programas utilizados por esta municipalidade;

2.4.19. Deve possuir tabela CID 10 integrada ao sistema;

2.4.20. Deve possuir tabela de especialidades integrada com a tabela de CBO (Código Brasileiro de Ocupação);

2.4.21. Deve possuir ferramenta para consultar no período e em uma única tela, todo o histórico do paciente na rede municipal de saúde, contendo no mínimo: atendimentos realizados nas unidades básicas, atendimentos realizados nas

unidades especializadas, atendimentos realizados nas unidades de Urgência e emergência, medicamentos

2.4.22. Retirados em todas as unidades dispensadoras, exames laboratoriais realizados no município e/ou nos prestadores, exames de imagem realizados no município, vacinas aplicadas;

2.4.23. Deve possuir ferramenta para consultar no período e em uma única tela todas as ocorrências do paciente na rede municipal de saúde, contendo no mínimo: faltas nos atendimentos agendados, cancelamentos nos atendimentos agendados, reagendamentos de atendimentos agendados, cancelamento e/ou desistência de atendimento de urgência/emergência, falta na coleta de exames, falta na execução do exame de imagem, vacinas atrasadas;

2.4.24. Deve possuir tela que mostre a quantidade e porcentagem de todos os pacientes cadastrados no sistema, por sexo masculino e feminino, e por faixa etária;

2.4.25. Deve gerar relatório de pacientes cadastrados por bairro contendo no mínimo: unidade, bairro, nome do paciente, número de prontuário, número do CNS, data de nascimento, endereço (logradouro, número, bairro), telefone;

2.4.26. Deve gerar relatório de pacientes por classificação: munícipe, temporário, outro município, safrista, turista;

2.4.27. Deve gerar relatório de pacientes atualizados por unidade contendo no mínimo: período, unidade, faixa etária, quantidade de pacientes atualizados;

2.4.28. Deve gerar relatório de pacientes cadastrados contendo no mínimo: nome do paciente, data de nascimento, número de prontuário, nome da mãe, nome do cadastrador, unidade, data do cadastro;

2.4.29. Deve gerar relatório de pacientes com óbito contendo no mínimo: período, nome do paciente, data de nascimento, número do prontuário, data do óbito.

2.5. Módulo Controle do Agendamento e Tratamento das Consultas de Especialidades

2.5.1. O sistema deve permitir consultar o paciente por nome, número do prontuário e data de nascimento para realizar o agendamento retroativo.

2.5.2. O sistema deve permitir registrar agendamentos em datas retroativas.

2.5.3. O sistema deve permitir consultar o paciente SUS por nome, número do prontuário e data de nascimento para realizar o agendamento de consulta ou retorno.

2.5.4. O sistema deve apresentar histórico de consultas agendadas do paciente selecionado, contendo no mínimo: data, horário, especialidade médica, unidade de saúde, profissional e tipo de consulta (consulta ou retorno).

2.5.5. O sistema deve apresentar histórico das consultas que foram realizadas para o paciente, contendo no mínimo: data, horário, especialidade médica, unidade de saúde, profissional, tipo de consulta (consulta ou retorno) e status.

2.5.6. O sistema deve permitir atualizar os números de telefone de contato do paciente.

2.5.7. O sistema deve permitir escolher a unidade de saúde que o paciente será atendido, a especialidade médica e o profissional que possua agenda criada para realizar o agendamento de consulta ou retorno para o paciente.

2.5.8. Ao agendar uma consulta ou retorno para o paciente SUS, o sistema deve sugerir o primeiro horário livre (data, horário e dia da semana) da agenda do profissional.

2.5.9. O sistema deve permitir imprimir comprovante de agendamento para o paciente SUS, contendo no mínimo: informações da unidade de saúde que o paciente será atendido, nome do paciente, nome social, número do prontuário, tipo de atendimento (consulta ou retorno), data e horário do agendamento, especialidade médica, profissional que realizará o atendimento e mensagem de orientação.

2.5.10. O sistema deve permitir consultar a agenda do profissional por mês e ano.

2.5.11. O sistema deve apresentar na agenda do profissional as datas disponíveis para agendamento de consultas conforme jornada de trabalho definida.

2.5.12. O sistema deve apresentar na agenda do profissional as datas disponíveis para agendamento de retorno conforme jornada de trabalho definida.

2.5.13. O sistema deve apresentar na agenda do profissional os feriados cadastrados.

2.5.14. O sistema deve permitir gerar e imprimir etiqueta de identificação do paciente, contendo no mínimo: nome do paciente, número do cartão nacional de saúde (CNS), data de nascimento, data de emissão, sexo, município de residência, unidade de saúde que o paciente SUS pertence e número do prontuário.

2.5.15. O sistema deve permitir visualizar durante o agendamento os dados do paciente: nome do paciente, data de nascimento, idade, sexo, número do prontuário, unidade de saúde que o paciente SUS pertence, município de residência e os números de telefone para contato.

2.5.16. O sistema deve permitir alertar que o paciente está com os dados cadastrais desatualizados.

2.5.17. O sistema deve bloquear a agenda do profissional nos feriados ou pontos facultativos cadastrados no sistema, nas férias do profissional ou nos dias em que o profissional se ausentar por alguma ocorrência (licença, falta, congresso, entre outras).

2.5.18. Ao atingir o limite de vagas definido para o dia, o sistema deve bloquear a data na agenda do profissional e deve permitir agendamentos somente com a senha de supervisor.

2.5.19. O sistema deve apresentar na agenda do profissional a quantidade de vagas disponíveis para agendamento e a quantidade de vagas agendadas (ocupadas) conforme a jornada de trabalho definida para o dia.

2.5.20. O sistema deve bloquear o agendamento quando solicitado para o mesmo paciente uma especialidade médica que já está agendada.

2.5.21. O sistema deve permitir realizar o agendamento descentralizado, possibilitando agendar consultas e retornos em todas as unidades de saúde do município.

2.5.22. Ao realizar o agendamento, o sistema deve permitir visualizar todas as unidades de saúde que poderão receber agendamentos ou somente a unidade do usuário do sistema que está realizando agendamentos.

2.5.23. O sistema deve apresentar histórico por paciente com os atendimentos realizados, agendados e faltas, contendo no mínimo: data da consulta, nome do paciente, número do prontuário, unidade de saúde, especialidade médica, nome do profissional, status, total de faltas, total de atendimentos realizados e total de agendamentos.

2.5.24. O sistema deve permitir agendar consultas, retornos e consultas de urgência (demanda espontânea e encaixes).

2.5.25. Ao realizar o agendamento, o sistema deve permitir incluir observação (orientação) para o paciente que deverá ser impressa no comprovante de agendamento.

2.5.26. O sistema deve permitir informar que existe a especialidade médica solicitada na unidade de saúde que o paciente pertence.

2.5.27. O sistema deve permitir verificar se o paciente possui faltas registradas dentro do período definido e deve apresentar a quantidade total de faltas especificando data, horário, especialidade médica e o profissional agendado.

2.5.28. Quando o paciente não for munícipe (de outro município), o sistema deve informar quais especialidades médicas poderão ser agendadas.

2.5.29. Se o paciente estiver realizando algum tratamento, o sistema deve permitir agendar várias datas para a mesma especialidade médica.

2.5.30. Ao realizar o agendamento, o sistema deve verificar se a especialidade médica (procedimento vinculado) está em conformidade com a tabela unificada de procedimentos (SIGTAP) de acordo com o paciente escolhido.

2.5.31. O sistema deve permitir realizar o envio de mensagem SMS ao paciente com informações do agendamento, contendo no mínimo: nome do paciente, especialidade médica, data e horário da consulta, unidade de saúde e mensagem de orientação com o telefone da unidade.

2.5.32. Se o paciente participar do Programa Bolsa Família, o sistema deve permitir informar que o paciente possui esse benefício.

2.5.33. O sistema deve permitir agendar vários pacientes no mesmo horário.

2.5.34. O sistema deve permitir agendar pacientes com horário marcado conforme sugestão do sistema.

2.5.35. O sistema deve permitir que o paciente escolha o horário de sua consulta de acordo com a jornada de trabalho do profissional.

2.5.36. O sistema deve permitir que os pacientes sejam agendados em bloco (fisioterapia).

2.5.37. Ao confirmar a consulta, se o paciente tiver outros agendamentos (exame laboratorial, exame de imagem, transporte, regulação, consultas especializadas) no mesmo dia/turno da consulta que está sendo agendada, o sistema deve apresentar os agendamentos especificando: data, turno, horário, local de exame/coleta, prestador, destino da viagem, unidade de saúde e/ou especialidade médica.

2.5.38. O sistema deve permitir que a mesma especialidade médica seja agendada mais de uma vez no dia para o mesmo paciente.

2.5.39. O sistema deve permitir cadastrar supervisores que possam autorizar agendamentos acima da capacidade da jornada dos profissionais assim como outras operações no controle de agendamento que necessitem de autorização.

2.5.40. O sistema deve apresentar os supervisores cadastrados.

2.5.41. O sistema deve verificar se o cadastro do supervisor já existe e deve informar a duplicidade caso o usuário do sistema tente cadastrá-lo novamente.

2.5.42. O sistema deve permitir excluir o supervisor cadastrado.

2.5.43. O sistema deve permitir consultar o paciente por nome, número do prontuário e data de nascimento para visualizar as consultas agendadas e as consultas que já foram realizadas (finalizadas).

2.5.44. Ao consultar o histórico de consultas agendadas e realizadas do paciente, o sistema deve permitir visualizar: nome do paciente, número do prontuário, número do cartão nacional de saúde (CNS), data de nascimento, sexo, estado civil, RG, CPF, unidade de saúde que o paciente SUS pertence, número da família, logradouro e números de telefone para contato.

2.5.45. O sistema deve apresentar as consultas agendadas para o paciente, contendo no mínimo: data, horário, especialidade médica, unidade de saúde, profissional e tipo de agendamento.

2.5.46. O sistema deve apresentar as consultas realizadas para o paciente, contendo no mínimo: data, horário, especialidade médica, unidade de saúde, profissional, tipo de atendimento e status.

2.5.47. O sistema deve permitir reimprimir o comprovante de agendamento do paciente SUS, contendo no mínimo: informações da unidade de saúde que o paciente será atendido, nome do paciente, número do prontuário, tipo de atendimento (consulta

ou retorno), data e horário do agendamento, especialidade médica, profissional que realizará o atendimento e mensagem de orientação.

2.5.48. O sistema deve permitir imprimir o histórico de consultas agendadas e realizadas do paciente, contendo no mínimo: data, horário, especialidade médica, unidade de saúde, profissional, tipo de agendamento e status (consulta finalizada).

2.5.49. O sistema deve permitir consultar e imprimir os dados da consulta realizada para o paciente, contendo no mínimo: dados da triagem (peso, altura, pressão arterial, temperatura, pulso, respiração, HGT - hemoglicoteste ou teste de dosagem do nível de glicemia, cintura, quadril, IMC - índice de massa corporal), prescrição médica e procedimentos executados durante o atendimento (procedimento, CBO, CID).

2.5.50. O sistema deve permitir consultar os atendimentos agendados por data, unidade de saúde, especialidade e profissional.

2.5.51. O sistema deve apresentar os atendimentos agendados, contendo no mínimo: nome do paciente, idade e número do prontuário.

2.5.52. O sistema deve permitir registrar o fechamento dos atendimentos agendados.

2.5.53. Ao finalizar cada agendamento, o sistema deve permitir registrar se o atendimento foi realizado ou se o paciente faltou.

2.5.54. O sistema deve permitir registrar os procedimentos executados durante o atendimento.

2.5.55. O sistema deve permitir registrar os CID’s (Classificação Internacional de Doenças

e Problemas Relacionados com a Saúde) identificados durante o atendimento.

2.5.56. O sistema somente deve permitir registrar procedimentos que estejam em conformidade com a tabela unificada de procedimentos SUS (SIGTAP).

2.5.57. O sistema somente deve permitir registrar procedimentos compatíveis com o CBO (Classificação Brasileira de Ocupações) do profissional.

2.5.58. O sistema somente deve permitir registrar XXX’x compatíveis com o procedimento de acordo com a tabela unificada de procedimentos SUS (SIGTAP).

2.5.59. O sistema deve permitir registrar automaticamente para todos os atendimentos agendados o comparecimento ou falta dos pacientes.

2.5.60. O sistema deve permitir lançar o mesmo procedimento para todos os pacientes da agenda.

2.5.61. O sistema deve permitir lançar vários procedimentos em um único atendimento.

2.5.62. O sistema deve permitir lançar o programa de saúde vinculado ao atendimento.

2.5.63. O sistema deve permitir consultar o procedimento por código e nome.

2.5.64. O sistema deve permitir cadastrar os dados da pré-consulta (triagem) realizada para o paciente, contendo no mínimo: peso, altura, pressão arterial, temperatura, pulso, respiração, HGT - hemoglicoteste ou teste de dosagem do nível de glicemia, cintura, quadril, IMC - índice de massa corporal e observação da enfermagem.

2.5.65. O sistema deve permitir visualizar e imprimir os dados da pré-consulta (triagem) realizada para o paciente.

2.5.66. O sistema deve permitir visualizar o histórico completo de consultas realizadas e agendadas.

2.5.67. No fechamento da consulta, o sistema deve permitir a emissão da prescrição médica.

2.5.68. O sistema deve permitir consultar o profissional da saúde por nome e cargo para criar sua agenda de atendimento.

2.5.69. O sistema deve permitir cadastrar, alterar ou excluir jornadas de trabalho do profissional por dia ou por período.

2.5.70. Ao criar a agenda de atendimentos para o profissional por dia, o sistema deve permitir escolher o município, a unidade de saúde e a especialidade que o profissional realizará o atendimento.

2.5.71. Ao criar a agenda de atendimentos para o profissional por período, o sistema deve permitir escolher o município, a unidade de saúde, os dias da semana, a operação desejada (inclusão, alteração ou exclusão) e a especialidade que o profissional realizará o atendimento.

2.5.72. O sistema deve permitir cadastrar jornadas de trabalho para o profissional em diferentes unidades de saúde do município.

2.5.73. O sistema deve permitir cadastrar jornadas de trabalho para o mesmo profissional em especialidades diferentes.

2.5.74. O sistema deve permitir configurar a agenda do profissional para agendar vários pacientes no mesmo horário.

2.5.75. O sistema deve permitir configurar a agenda do profissional para agendar pacientes com horário marcado conforme sugestão do sistema.

2.5.76. O sistema deve permitir configurar a agenda do profissional para que o paciente possa escolher o horário de sua consulta de acordo com a jornada de trabalho do profissional.

2.5.77. O sistema deve permitir configurar a agenda do profissional para que os pacientes sejam agendados em bloco (fisioterapia).

2.5.78. Ao criar a agenda de atendimentos, por dia ou por período, para o profissional, o sistema deve permitir cadastrar o horário inicial da jornada de trabalho, a quantidade de consultas e/ou retornos que o profissional atenderá e o tempo médio de cada atendimento.

2.5.79. O sistema deve permitir alterar a jornada de trabalho do profissional quando surgir alguma ocorrência que o impeça de realizar atendimentos (licença, falta, congresso, plantão, emergência, férias, atestado, entre outras).

2.5.80. De acordo com a data escolhida na agenda, o sistema deve apresentar as jornadas de trabalho cadastradas para o profissional incluindo o município, a unidade de saúde e a especialidade que o profissional realizará o atendimento.

2.5.81. Ao criar a agenda de atendimentos, por dia ou por período, para o profissional, o sistema deve permitir cadastrar jornadas de trabalho para municípios pactuados.

2.5.82. O sistema deve permitir consultar a agenda do profissional por mês e ano.

2.5.83. O sistema deve apresentar na agenda do profissional os feriados cadastrados.

2.5.84. Ao criar a agenda de atendimentos para o profissional, o sistema deve apresentar conforme a jornada de trabalho definida para o dia, a quantidade de vagas disponíveis para agendamento e a quantidade de vagas agendadas (ocupadas).

2.5.85. O sistema deve permitir excluir a agenda de atendimentos do profissional (jornadas de trabalho) somente se não existir pacientes vinculados.

2.5.86. Ao criar a agenda de atendimentos para o profissional, por dia ou por período, o sistema deve permitir visualizar, no mínimo, os seguintes dados: nome, data de nascimento, sexo, número do registro profissional, RG, CPF e estado civil.

2.5.87. O sistema não deve permitir cadastrar jornadas para o mesmo profissional em dias e horários coincidentes.

2.5.88. O sistema deve permitir consultar o paciente por nome, número do prontuário e data de nascimento para gerenciar as consultas agendadas.

2.5.89. O sistema deve apresentar as consultas agendadas do paciente selecionado, contendo no mínimo: data, horário, especialidade médica, unidade de saúde, profissional e tipo de agendamento.

2.5.90. O sistema deve permitir reimprimir o comprovante de agendamento do paciente SUS, contendo no mínimo: informações da unidade de saúde que o paciente será atendido, nome do paciente, número do prontuário, tipo de atendimento (consulta ou retorno), data e horário do agendamento, especialidade médica, profissional que realizará o atendimento e mensagem de orientação.

2.5.91. O sistema deve permitir cancelar ou reagendar as consultas do paciente selecionado.

2.5.92. O sistema deve solicitar confirmação do usuário do sistema antes de realizar o cancelamento da consulta agendada.

2.5.93. Ao realizar o reagendamento da consulta, o sistema deve apresentar para seleção a unidade de saúde que realizará o atendimento e o profissional com disponibilidade de horários na especialidade médica desejada.

2.5.94. Ao realizar o reagendamento da consulta, o sistema deve apresentar histórico de consultas agendadas do paciente selecionado, contendo no mínimo: data, horário, especialidade médica, unidade de saúde, profissional e tipo de consulta (consulta ou retorno).

2.5.95. Ao realizar o reagendamento da consulta, o sistema deve apresentar histórico das consultas que foram realizadas para o paciente, contendo no mínimo: data, horário, especialidade médica, unidade de saúde, profissional, tipo de consulta (consulta ou retorno) e status.

2.5.96. Ao realizar o reagendamento da consulta, o sistema deve permitir atualizar os números de telefone de contato do paciente.

2.5.97. Ao realizar o reagendamento da consulta, o sistema deve permitir consultar a agenda do profissional por mês e ano.

2.5.98. Ao realizar o reagendamento da consulta, o sistema deve permitir imprimir comprovante de agendamento para o paciente SUS, contendo no mínimo: informações da unidade de saúde que o paciente será atendido, nome do paciente, número do prontuário, tipo de atendimento (consulta ou retorno), data e horário do agendamento, especialidade médica, profissional que realizará o atendimento e mensagem de orientação.

2.5.99. Ao realizar o reagendamento da consulta, o sistema deve apresentar as datas disponíveis do profissional.

2.5.100. Ao realizar o reagendamento da consulta, o sistema deve apresentar na agenda do profissional os feriados cadastrados.

2.5.101. Ao realizar o reagendamento da consulta, o sistema deve permitir gerar e imprimir etiqueta de identificação do paciente, contendo no mínimo: nome do paciente, número do cartão nacional de saúde (CNS), data de nascimento, data de emissão, sexo, município de residência, unidade de saúde que o paciente SUS pertence e número do prontuário.

2.5.102. Ao realizar o reagendamento da consulta, o sistema deve bloquear a agenda do profissional nos feriados ou pontos facultativos cadastrados no sistema, nas férias do profissional ou nos dias em que o profissional se ausentar por alguma ocorrência (licença, falta, congresso, entre outras).

2.5.103. Ao realizar o reagendamento da consulta, o sistema deve permitir visualizar os dados do paciente: nome do paciente, data de nascimento, idade, sexo, número do prontuário, unidade de saúde que o paciente SUS pertence, município de residência e os números de telefone para contato.

2.5.104. Ao realizar o reagendamento da consulta, o sistema deve permitir alertar que o paciente está com os dados cadastrais desatualizados.

2.5.105. Ao realizar o reagendamento da consulta, o sistema deve sugerir o primeiro horário livre (data, horário e dia da semana) da agenda do profissional.

2.5.106. Ao realizar o reagendamento da consulta, o sistema deve apresentar na agenda do profissional a quantidade de vagas disponíveis para agendamento e a quantidade de vagas agendadas (ocupadas) conforme a jornada de trabalho definida para o dia.

2.5.107. Ao realizar o reagendamento da consulta, atingindo o limite de vagas definido para o dia, o sistema deve bloquear a data na agenda do profissional, permitindo agendamentos somente mediante senha de supervisor.

2.5.108. Ao realizar o reagendamento da consulta, o sistema deve permitir incluir observação (orientação) para o paciente que deverá ser impressa no comprovante de agendamento.

2.5.109. Ao realizar o reagendamento da consulta, o sistema deve permitir remarcar em qualquer unidade de saúde do município (agendamento descentralizado).

2.5.110. O sistema deve permitir consultar o paciente por nome, número do prontuário e data de nascimento para gerenciar as consultas agendadas por solicitação do profissional.

2.5.111. O sistema deve apresentar as consultas agendadas do paciente selecionado, contendo no mínimo: data, horário, especialidade, unidade de saúde, profissional e tipo de agendamento.

2.5.112. O sistema deve permitir reimprimir o comprovante de agendamento do paciente SUS, contendo no mínimo: informações da unidade de saúde que o paciente será atendido, nome do paciente, número do prontuário, tipo de atendimento (consulta ou retorno), data e horário do agendamento, especialidade, profissional que realizará o atendimento e mensagem de orientação.

2.5.113. O sistema deve permitir reagendar ou cancelar o agendamento do paciente por solicitação do profissional.

2.5.114. O sistema deve solicitar confirmação antes de realizar o cancelamento da consulta agendada.

2.5.115. O sistema deve permitir reagendar a consulta do paciente por solicitação do profissional.

2.5.116. O sistema deve gerar relatório para confirmação de consultas, contendo no mínimo: nome do paciente, nome social, número do prontuário, idade, horário do agendamento, tipo do atendimento (consulta ou retorno), data da solicitação e números de telefone para contato.

2.5.117. O sistema deve permitir consultar o profissional da saúde por nome e cargo para transferir a sua agenda de atendimentos para outra agenda.

2.5.118. O sistema deve permitir visualizar os dados de identificação do profissional para transferir a sua agenda de atendimentos.

2.5.119. O sistema deve permitir escolher o município, a unidade de saúde e a especialidade para transferir a agenda de atendimentos do profissional.

2.5.120. O sistema deve permitir escolher na agenda do profissional a data que deseja transferir os agendamentos.

2.5.121. O sistema deve permitir escolher o profissional para receber a agenda de atendimentos.

2.5.122. O sistema deve permitir transferir os agendamentos para outra agenda.

2.5.123. O sistema deve permitir consultar o profissional da saúde por nome e cargo para transferir a sua agenda de atendimentos de uma data para outra ou cancelar os agendamentos.

2.5.124. O sistema deve permitir visualizar os dados de identificação do profissional para transferir a sua agenda de atendimentos de uma data para outra ou cancelar os agendamentos.

2.5.125. O sistema deve permitir escolher o município, a unidade de saúde e a especialidade para transferir a agenda de atendimentos do profissional de uma data para outra ou cancelar os agendamentos.

2.5.126. O sistema deve permitir escolher na agenda do profissional a data que deseja transferir ou cancelar os agendamentos.

2.5.127. O sistema deve permitir cancelar os agendamentos.

2.5.128. O sistema deve permitir transferir os agendamentos para outra agenda do profissional.

2.5.129. Ao cancelar os agendamentos ou transferir a agenda de atendimentos do profissional de uma data para outra, o sistema deve permitir visualizar os números de telefone de contato do paciente.

2.5.130. O sistema deve gerar relatório quantitativo de produção, contendo no mínimo: procedimento, CBO, quantidade de execução do procedimento e total geral de procedimentos realizados.

2.5.131. O sistema deve gerar relatório de alteração das jornadas de trabalho do profissional, contendo no mínimo: profissional, especialidade, data da alteração, usuário que realizou a alteração, data do atendimento, dados da jornada anterior e dados da jornada atual.

2.5.132. O sistema deve gerar relatório que apresente as jornadas canceladas por profissional, contendo no mínimo: nome do profissional, motivo, especialidade e total de ausências.

2.5.133. O sistema deve gerar relatório de consultas agendadas, contendo no mínimo: data da solicitação, unidade de saúde, especialidade médica, nome do profissional e total de consultas agendadas na data.

2.5.134. O sistema deve gerar relatório que apresente as jornadas de trabalho do profissional, contendo no mínimo: data do atendimento, nome do profissional, especialidade médica, dia da semana, horário inicial da jornada, município, total de consultas e retornos definidos, total de agendamentos realizados, total geral (consultas e retornos definidos e agendamentos realizados) e status da jornada.

2.5.135. O sistema deve gerar relatório que apresente o histórico de atendimentos por paciente, contendo no mínimo: nome do paciente, prontuário, data de nascimento, consultas agendadas e atendimentos realizados (sinais vitais, prescrição médica e procedimentos executados).

2.5.136. O sistema deve gerar relatório que apresente as cotas definidas e utilizadas por especialidade em cada município, contendo no mínimo: especialidade, total de cotas definidas e total de cotas utilizadas.

2.5.137. O sistema deve gerar relatório de morbidade (pacientes considerados doentes ou vítimas de uma doença), contendo no mínimo: nome do programa de saúde, tipo de atendimento, tipo de consulta e total de procedimentos realizados.

2.5.138. O sistema deve gerar relatório quantitativo por CID, contendo no mínimo: CID

(código e nome), unidade de saúde e quantidade de CID’s lançados.

2.5.139. O sistema deve gerar relatório dos atendimentos que não foram lançados procedimentos e CID’s, contendo no mínimo: data do atendimento, paciente, prontuário, especialidade médica, profissional e total de atendimentos (sem procedimentos/CID’s).

2.5.140. O sistema deve gerar relatório que apresente os agendamentos que foram reagendados, contendo no mínimo: data e horário do agendamento, especialidade médica, unidade de saúde, profissional e tipo de agendamento.

2.5.141. O sistema deve gerar relatório que apresente os agendamentos por endereço, contendo no mínimo: nome do paciente, data de nascimento, número do prontuário, horário de atendimento e endereço.

2.5.142. O sistema deve gerar relatório quantitativo de produção por nome do procedimento, contendo no mínimo: procedimento (código e nome), CBO (código e nome) e quantidade de execução do procedimento.

2.5.143. O sistema deve permitir consultar os atendimentos finalizados por data, unidade de saúde, especialidade e profissional.

2.5.144. O sistema deve apresentar os atendimentos finalizados.

2.5.145. O sistema deve permitir alterar o status dos atendimentos finalizados, possibilitando realizar novo fechamento.

2.5.146. O sistema deve permitir consultar o paciente por nome, número do prontuário e data de nascimento para realizar a exclusão de consultas agendadas.

2.5.147. O sistema deve apresentar as consultas agendadas para o paciente, contendo no mínimo: data, horário, especialidade médica, unidade de saúde, profissional e tipo de agendamento.

2.5.148. O sistema deve permitir excluir a consulta agendada apenas mediante autorização de supervisor previamente cadastrado.

2.5.149. O sistema deve solicitar confirmação do usuário do sistema antes de realizar a exclusão da consulta agendada.

2.5.150. O sistema deve permitir reimprimir o comprovante de agendamento do paciente SUS, contendo no mínimo: informações da unidade de saúde que o paciente será atendido, nome do paciente, número do prontuário, tipo de atendimento (consulta ou retorno), data e horário do agendamento, especialidade médica, profissional que realizará o atendimento e mensagem de orientação.

2.5.151. O sistema deve gerar relatório de procedimentos lançados, contendo no mínimo: data do atendimento, município, unidade de saúde, especialidade médica, profissional, procedimento e quantidade de execução do procedimento.

2.5.152. O sistema deve permitir visualizar e imprimir o histórico de consultas fechadas por paciente.

2.5.153. O sistema deve permitir consultar as consultas agendadas de acordo com o período escolhido.

2.5.154. O sistema deve apresentar listagem de consultas agendadas conforme período selecionado, contendo no mínimo: nome do paciente, data de nascimento, número do prontuário, horário, tipo de agendamento, município, data da solicitação, usuário do sistema que realizou o agendamento e total de agendamentos no período.

2.5.155. O sistema deve permitir impressão da listagem de consultas agendadas em formato de formulário.

2.5.156. O sistema deve gerar relatório que apresente as consultas excluídas, contendo no mínimo: data do agendamento, data da exclusão, unidade de saúde, especialidade, profissional, paciente e usuário do sistema que realizou a exclusão.

2.5.157. O sistema deve permitir consultar os pacientes agendados para atendimento.

2.5.158. O sistema deve apresentar os pacientes agendados para atendimento, contendo no mínimo: nome do paciente, número do prontuário, especialidade, horário do agendamento, classificação de risco e status do atendimento.

2.5.159. Durante o atendimento do paciente, o sistema deve permitir visualizar o nome do paciente, número do cartão nacional de saúde (CNS), data de nascimento, idade, sexo, unidade de saúde que o paciente pertence e município de residência.

2.5.160. O sistema deve permitir visualizar os dados socioeconômicos do paciente durante o atendimento, contendo no mínimo: número de pessoas residentes, tipo de moradia, escoamento sanitário, energia elétrica, água encanada, portadores de deficiência, renda familiar e higiene residencial.

2.5.161. Durante o atendimento do paciente, o sistema deve permitir visualizar os dados da pré-consulta: peso, altura, pressão arterial, temperatura, pulso, respiração, HGT - hemoglicoteste ou teste de dosagem do nível de glicemia, cintura, quadril, IMC - índice de massa corporal e observação da enfermagem.

2.5.162. O sistema deve permitir registrar os dados da pré-consulta (triagem) durante o atendimento do paciente.

2.5.163. O sistema deve permitir registrar no atendimento do paciente os dados da anamnese, contendo no mínimo: antecedentes (pessoais, familiares e alérgicos), interrogatório de diferentes aparelhos e antecedentes obstétricos.

2.5.164. O sistema deve permitir registrar no atendimento do paciente dados do primeiro atendimento, história da moléstia, exames (físicos, oftalmológicos, laboratoriais e de imagem) hipótese diagnosticada, procedimentos, CID, conduta, prescrição médica, evolução, nova consulta, resultado de exames e encaminhamento.

2.5.165. O sistema deve permitir registrar no atendimento do paciente os dados verificados pela enfermagem, contendo no mínimo: queixa principal, história da doença atual, exames (físicos e oftalmológicos), procedimentos, CID’s, pré-atendimento, conduta, acompanhamento de gestantes e pré-natais.

2.5.166. O sistema deve permitir registrar no atendimento do paciente os dados da avaliação odontológica, contendo no mínimo: queixa principal, história da doença atual, Odontograma, procedimento/CID/CIAP, exames (laboratoriais e de imagem), prescrição médica e tratamento.

2.5.167. Durante o atendimento do paciente, o sistema deve permitir visualizar o histórico detalhado de todos os atendimentos realizados para o paciente.

2.5.168. O sistema deve permitir gerar atestado médico.

2.5.169. O sistema deve permitir gerar impressão do atendimento completo.

2.5.170. O sistema deve permitir gerar declaração de comparecimento.

2.5.171. O sistema deve permitir visualizar o tempo total do atendimento e o tempo despendido em cada etapa (triagem, atendimento de enfermagem e atendimento médico).

2.5.172. O sistema deve permitir que os profissionais prescrevam medicamentos padronizados da rede municipal de saúde.

2.5.173. O sistema deve permitir que os profissionais prescrevam medicamentos que não fazem parte da lista padronizada da rede municipal de saúde.

2.5.174. O sistema deve permitir que os profissionais solicitem exames (laboratoriais e de imagem) padronizados da rede municipal de saúde.

2.5.175. O sistema deve permitir que os profissionais solicitem exames (laboratoriais e de imagem) que não fazem parte da lista padronizada da rede municipal de saúde.

2.5.176. O sistema deve permitir gerar impressão da prescrição médica, contendo no mínimo: data da prescrição, nome do paciente, data de nascimento, documento de identificação do paciente, nome do medicamento, orientação de uso do medicamento, campo para carimbo e assinatura do profissional solicitante.

2.5.177. O sistema deve permitir gerar impressão de solicitação de exames laboratoriais, contendo no mínimo: unidade solicitante, nome do paciente, documento de

identificação do paciente, data de nascimento, idade, sexo, nome da mãe, endereço residencial, número de telefone para contato, nome e especialidade do profissional solicitante, data e horário da solicitação, nome do exame, suspeita clínica e campo para assinatura do profissional solicitante.

2.5.178. O sistema deve permitir gerar impressão de solicitação de exames de imagem, contendo no mínimo: unidade solicitante, nome do paciente, documento de identificação do paciente, data de nascimento, idade, sexo, nome da mãe, endereço residencial, número de telefone para contato, nome e especialidade do profissional solicitante, data e horário da solicitação, nome do exame, suspeita clínica e campo para assinatura do profissional solicitante.

2.5.179. O sistema deve permitir encaminhar o paciente para outros atendimentos especializados.

2.5.180. O sistema deve gerar relatório da produção ambulatorial por profissional, contendo no mínimo: nome do profissional, procedimento realizado, CBO, especialidade médica, idade do paciente, quantidade de execução do procedimento e total de procedimentos realizados.

2.5.181. O sistema deve gerar relatório de atendimento por paciente, contendo no mínimo: data do atendimento, nome do paciente, prontuário, unidade de saúde, especialidade médica, profissional, status e total de consultas (agendadas, realizadas e faltas).

2.5.182. O sistema deve gerar relatório dos atendimentos realizados por especialidade médica, contendo no mínimo: unidade de saúde, especialidade médica, profissional, tipo de atendimento, turno, data do atendimento, nome do paciente, prontuário, data de nascimento, idade, unidade de saúde que o paciente SUS pertence, bairro, total de atendimentos realizados e total geral de atendimentos realizados.

2.5.183. O sistema deve permitir consultar os atendimentos agendados por data, unidade de saúde, especialidade, profissional e turno.

2.5.184. O sistema deve apresentar os atendimentos agendados, contendo no mínimo: nome do paciente, número do prontuário, especialidade, horário do agendamento, profissional e status do atendimento.

2.5.185. O sistema deve permitir cadastrar os dados da pré-consulta (triagem) realizada para o paciente, contendo no mínimo: peso, altura, pressão arterial, temperatura, pulso, respiração, HGT - hemoglicoteste ou teste de dosagem do nível de glicemia, cintura, quadril, IMC - índice de massa corporal, classificação de risco e observação da enfermagem.

2.5.186. O sistema deve permitir registrar o atendimento completo de enfermagem realizado para o paciente.

2.5.187. O sistema deve permitir registrar se o paciente faltou ao atendimento.

2.5.188. O sistema deve gerar relatório de pacientes para atendimento, contendo no mínimo: data do atendimento, nome do paciente, prontuário, unidade de saúde, especialidade médica e profissional.

2.5.189. O sistema deve gerar relatório dos atendimentos realizados, contendo no mínimo: nome do profissional, total de atendimentos realizados por dia e total de atendimentos realizados no mês.

2.5.190. O sistema deve gerar relatório dos atendimentos realizados por unidade, contendo no mínimo: unidade de saúde, nome do profissional, total de atendimentos realizados no período e total geral de atendimentos realizados no período.

2.5.191. O sistema deve gerar relatório quantitativo de procedimentos por unidade, contendo no mínimo: nome do procedimento, CBO, unidade de saúde e quantidade de execução do procedimento.

2.5.192. O sistema deve gerar relatório de procedimentos realizados, contendo no mínimo: unidade de saúde, nome do profissional, especialidade médica, procedimento (código e nome), quantidade de execução do procedimento, total de atendimentos do profissional, total de procedimentos realizados pelo profissional, total de atendimentos prestados pela unidade e total de procedimentos executados na unidade de saúde.

2.5.193. O sistema deve gerar relatório que apresente as jornadas de trabalho do profissional, contendo no mínimo: mês, ano, unidade de saúde, dias do mês, dias da semana, nome do profissional e total de consultas definidas e agendadas por especialidade médica.

2.5.194. O sistema deve permitir bloquear a agenda do profissional conforme a unidade de saúde, especialidade médica e período selecionado.

2.5.195. O sistema deve apresentar a unidade de saúde, a especialidade médica e o período que está bloqueado na agenda do profissional.

2.5.196. O sistema deve permitir excluir o período de bloqueio cadastrado para a agenda do profissional.

2.5.197. O sistema deve permitir excluir o bloqueio realizado na agenda do profissional.

2.5.198. O sistema deve gerar relatório financeiro da produção ambulatorial, contendo no mínimo: procedimento (código e nome), quantidade de execução do procedimento, valor unitário e valor total.

2.5.199. O sistema deve gerar relatório de consultas solicitadas, contendo no mínimo: unidade solicitante, especialidade médica, quantidade de agendamentos e total de consultas solicitadas.

2.5.200. O sistema deve gerar relatório de produção médica, contendo no mínimo: unidade de saúde, mês e ano, nome do profissional, especialidade médica, tipo de contratação, PGI (Programa de Incentivos), G.A (Gratificação Ambulatorial) e total de atendimentos finalizados por dia e por mês.

2.5.201. O sistema deve gerar relatório que apresente os pacientes que passaram por consultas mais de uma vez no período, na mesma unidade de saúde, com o mesmo profissional e mesma especialidade médica, contendo no mínimo: data do atendimento, unidade de saúde, especialidade médica, profissional e nome do paciente.

2.5.202. O sistema deve permitir definir os diagnósticos dentais que serão utilizados no atendimento do paciente (Odontograma).

2.5.203. O sistema deve permitir definir, de acordo com a especialidade, os status que serão apresentados no fechamento de consultas.

2.5.204. O sistema deve gerar relatório dos tratamentos concluídos por especialidade médica, contendo no mínimo: paciente, data de nascimento, idade, prontuário, cartão SUS e data de conclusão do tratamento.

2.5.205. O sistema deve permitir definir, para cada CBO, quais etapas do prontuário médico serão preenchidas durante o atendimento do paciente.

2.5.206. O sistema deve gerar relatório de procedimentos realizados, contendo no mínimo: data do atendimento, paciente, data de nascimento, idade, prontuário, especialidade médica, CBO, nome do profissional e código do procedimento.

2.5.207. O sistema deve permitir definir as configurações utilizadas para o envio de mensagens SMS aos pacientes.

2.5.208. O sistema deve gerar relatório que permita consultar o status dos SMSs que foram enviados para os pacientes, contendo no mínimo: paciente, celular, unidade de saúde, especialidade médica, data do envio, status e total de SMSs enviados.

2.5.209. O sistema deve gerar relatório quantitativo de atendimento médico que considere os status das consultas agendadas e realizadas, contendo no mínimo: unidade de saúde, nome do profissional, total de atendimentos no período (do profissional e da unidade de saúde) e total geral de atendimentos no período.

2.5.210. O sistema deve permitir visualizar o histórico detalhado do atendimento realizado para o paciente.

2.5.211. O sistema deve permitir agendar atendimentos de demanda espontânea.

2.5.212. O sistema deve apresentar os acolhimentos agendados (não programados) para atendimento.

2.5.213. O sistema deve permitir registrar procedimentos para pacientes em atendimento pós-consulta.

2.5.214. O sistema deve permitir realizar baixa de materiais/medicamentos do estoque da unidade quando estes forem utilizados para atender o paciente.

2.5.215. O sistema deve permitir consultar pacientes para fins de registro de procedimentos de pós-consulta e/ou para dar baixa em produtos/medicamentos utilizados no atendimento, por: data, unidade, especialidade, especialista.

2.5.216. O sistema deve permitir registrar uso de materiais/medicamentos para pacientes em atendimento Pós-Consulta.

2.5.217. O sistema deve permitir excluir procedimentos lançados para pacientes em atendimento Pós-Consulta.

2.5.218. O sistema deve permitir verificar todas as consultas agendadas dentro de um período determinado, discriminado por unidade, especialidade e especialista, contendo no mínimo: nome do paciente, data de nascimento, número do prontuário, prontuário antigo, horas, tipo de consulta, município, data da solicitação, agendador / unidade.

2.5.219. O sistema deve gerar relatório estatístico de consulta, contendo no mínimo: data, município, unidade, especialidade, médico, tipo, status, quantidade e total.

2.5.220. O sistema deve permitir pesquisar o relatório estatístico de consulta por unidade, especialidade e médico conforme a data selecionada.

2.5.221. O sistema deve permitir pesquisar o relatório quantitativo de procedimentos por unidade, procedimentos, profissional e CBO conforme a data selecionada.

2.5.222. O sistema deve gerar relatório quantitativo de procedimentos, contendo no mínimo: código, procedimento, nome do profissional e quantidade.

2.5.223. O sistema deve gerar relatório de acompanhamento das consultas realizadas, contendo no mínimo: nome do paciente, número do prontuário, data de nascimento, idade, data da consulta, unidade, especialidade e especialista.

2.5.224. O sistema deve gerar relatório que apresente as consultas finalizadas, contendo no mínimo: profissional, especialidade, data da consulta, nome do paciente, número do prontuário, horário agendado, procedimentos lançados, CID lançado e programa de saúde vinculado.

2.5.225. O sistema deve gerar relatório que apresente as consultas realizadas, contendo no mínimo: unidade, CBO, médico e quantidade.

2.5.226. O sistema deve gerar relatório que apresente as jornadas canceladas, contendo no mínimo: data, profissional, especialidade, unidade de saúde, jornada de trabalho definida e motivo.

2.5.227. O sistema deve permitir consultar os atendimentos agendados por data, unidade de saúde, especialidade e profissional.

2.5.228. O sistema deve apresentar os atendimentos agendados, contendo no mínimo: nome do paciente, data de nascimento, idade, número do prontuário, número da família, número do cartão nacional de saúde (CNS), horário do agendamento e procedimentos lançados no fechamento da consulta.

2.5.229. O sistema deve permitir imprimir os atendimentos agendados, contendo no mínimo: nome do paciente, data de nascimento, idade, número do prontuário, número da família, número do cartão nacional de saúde (CNS), horário do agendamento e procedimentos lançados no fechamento da consulta.

2.5.230. O sistema deve permitir que imprima de uma só vez todas as fichas de atendimento ambulatorial dos pacientes que foram agendados, conforme critérios escolhidos na busca.

2.5.231. O sistema deve permitir imprimir a ficha de atendimento Ambulatorial do paciente agendado, contendo no mínimo: nome do paciente, idade, CPF, RG, prontuário, data de nascimento, sexo e número do CNS.

2.5.232. O sistema deve permitir gerar PDF dos atendimentos agendados, contendo no mínimo: nome do paciente, data de nascimento, idade, número do prontuário, prontuário antigo e número família, cartão SUS, tipo consulta e hora, procedimento e CID, CIAP e assinatura.

2.5.233. O sistema deve permitir imprimir os atendimentos agendados, contendo no mínimo: cabeçalho com a data, unidade, profissional, CBO e consultas agendadas com nome paciente, data de nascimento, idade, número prontuário, número família, prontuário antigo, cartão SUS, hora, tipo de consulta, procedimento/CID, CIAP e assinatura.

2.5.234. O sistema deve gerar relatório que apresente a quantidade de consultas realizadas, por CBO contendo no mínimo: CBO e quantidade.

2.5.235. O sistema deve gerar relatório que apresente os atendimentos realizados, contendo no mínimo: data, município, médico, especialidade, paciente, CNS, status e idade.

2.5.236. O sistema deve gerar relatório que apresente relação entre procedimentos e CID's, contendo no mínimo: CID, descrição do CID, procedimento e descrição do procedimento.

2.5.237. O sistema deve gerar relatório que apresente a estatística de atendimentos, contendo no mínimo: médico, especialidade, unidade, quantidade de atendimentos realizados, porcentagem de atendimentos realizados, quantidade de atendimentos que o paciente faltou, porcentagem de atendimentos que o paciente faltou e total de atendimentos.

2.5.238. O sistema deve gerar relatório da produção ambulatorial, contendo no mínimo: procedimento realizado, CBO, idade do paciente e quantidade de execução do procedimento.

2.5.239. O sistema deve permitir marcar falta para um paciente que não compareceu à unidade.

2.5.240. O sistema deve exibir os dados dos pacientes para registro de chegada ou falta, no mínimo por: nome do paciente, número do prontuário e data de nascimento.

2.6. Módulo Pronto Atendimento / Pronto Socorro Municipal

2.6.1. O Sistema deve prever módulo para atender a demanda de Pronto Atendimento e Pronto Socorro;

2.6.2. O sistema deve permitir consultar os atendimentos realizados na UPA/PS por período, nome do médico plantonista e nome do paciente para registrar o fechamento automático de várias FAA’s.

2.6.3. Ao realizar o fechamento automático de FAA’s, o sistema deve permitir visualizar cada atendimento realizado na UPA/PS, contendo no mínimo: nome do paciente, número da FAA, data do atendimento, unidade, médico e status do atendimento.

2.6.4. O sistema deve gerar relatório quantitativo de pacientes, contendo no mínimo: nome do paciente, número do prontuário, data de nascimento, total de atendimentos realizados e total de atendimentos geral.

2.6.5. O sistema deve permitir transferir FAA’s de um médico para outro.

2.6.6. O sistema deve permitir visualizar os médicos que poderão ter seus atendimentos transferidos.

2.6.7. O sistema deve permitir visualizar os atendimentos que poderão ser transferidos para outro profissional.

2.6.8. O sistema deve permitir escolher a faixa de atendimentos que poderá ser transferida para outro profissional.

2.6.9. O sistema deve permitir escolher o médico plantonista que receberá os

atendimentos (FAA’s).

2.6.10. Ao alterar os dados da FAA, o sistema deve permitir consultar os atendimentos realizados na UPA/PS por número do prontuário, nome do paciente, data do atendimento e número da FAA.

2.6.11. O sistema deve permitir visualizar os atendimentos realizados na UPA/PS para alterar os dados da FAA, contendo no mínimo: nome do paciente, número do prontuário, número da FAA, data do atendimento, unidade e nome do médico plantonista.

2.6.12. O sistema deve permitir visualizar as FAA’s do paciente para realizar a alteração.

2.6.13. O sistema deve permitir alterar o status do atendimento, data do atendimento, médico, bem como incluir/excluir procedimentos, CID’s e CBO’s que tenham sido lançados na FAA.

2.6.14. O sistema deve permitir cadastrar supervisores que terão permissão para registrar plantões em datas retroativas e autorizar outras operações realizadas nas unidades de saúde (UPA, PS) que exigem autorização.

2.6.15. O sistema deve permitir visualizar os supervisores cadastrados.

2.6.16. O sistema deve permitir excluir o supervisor cadastrado.

2.6.17. O sistema deve permitir consultar o paciente por nome, número do prontuário e número da FAA para consultar e/ou reimprimir a FAA.

2.6.18. O sistema deve permitir consultar e/ou reimprimir a FAA (Ficha de Atendimento Ambulatorial) do paciente.

2.6.19. O sistema deve permitir consultar e/ou reimprimir a FAA do paciente com classificação de risco vermelho.

2.6.20. O sistema deve permitir visualizar e/ou imprimir os atendimentos realizados na unidade de urgência/emergência, contendo no mínimo: nome do paciente, número do prontuário, número da FAA, data do atendimento, unidade, nome do médico plantonista e status do atendimento.

2.6.21. O sistema deve permitir consultar as FAA’s realizadas por número do prontuário,

nome do paciente e número da FAA para finalizar o atendimento do paciente.

2.6.22. O sistema deve permitir visualizar os atendimentos realizados na UPA/PS, contendo no mínimo: nome do paciente, número do prontuário, número da FAA, data do atendimento, unidade, nome do médico e status do atendimento.

2.6.23. O sistema deve permitir finalizar os atendimentos que foram realizados para os pacientes na UPA/PS, contendo no mínimo: sinais vitais (temperatura, pulso, respiração, pressão arterial), classificação de risco, hora de entrada, hora de saída,

tempo de permanência, exame clínico, medicamentos, anotações de enfermagem, procedimentos realizados, quantidade, CBO e CID.

2.6.24. O sistema deve permitir transferir FAA’s de um médico para outro.

2.6.25. O sistema deve permitir impressão da ficha de Atendimento Ambulatorial.

2.6.26. O sistema deve permitir impressão da FAA do paciente com classificação de risco vermelho.

2.6.27. Ao finalizar FAA’s na UPA/PS, o sistema deve permitir registrar desistência no

atendimento.

2.6.28. O sistema deve gerar relatório financeiro da produção da UPA/PS, contendo no mínimo: código do procedimento, nome do procedimento, quantidade, valor unitário, valor total e total geral.

2.6.29. O sistema deve gerar relatório quantitativo da produção da UPA/PS, contendo no mínimo: código do procedimento, CBO, quantidade e total geral de procedimentos realizados.

2.6.30. O sistema deve gerar relatório dos atendimentos realizados na UPA/PS, contendo no mínimo: data do atendimento, nome do paciente, número da FAA, unidade, especialidade médica, classificação, status do atendimento e total de atendimentos no período.

2.6.31. O sistema deve gerar relatório de produção do médico, contendo no mínimo: data, horário de início do plantão, horário final do plantão, nome do médico plantonista, unidade, total de atendimentos realizados por médico e total de atendimentos geral.

2.6.32. O sistema deve gerar relatório de FAA’s que não foram finalizadas, contendo no mínimo: nome do paciente, número do prontuário, número da FAA, data do atendimento, unidade, especialidade médica, nome do médico plantonista e total de FAA’s.

2.6.33. O sistema deve gerar relatório de morbidade (pacientes considerados doentes ou vítimas de uma doença), contendo no mínimo: código do CID, nome do CID, quantidade do CID no mês e total geral do CID.

2.6.34. O sistema deve gerar relatório dos atendimentos que não foram lançados procedimentos e CID’s na UPA/PS, contendo no mínimo: data, nome do paciente, número do prontuário, número da FAA, especialidade médica e médico plantonista.

2.6.35. O sistema deve permitir consultar o paciente por nome, número do prontuário e data de nascimento para registrar a FAA em data retroativa.

2.6.36. O sistema deve permitir o registro de FAA em datas retroativas, contendo no mínimo: nome do paciente, data de nascimento, sexo, número do prontuário, nome da mãe, data do atendimento, nome do médico plantonista, especialidade médica, horário do atendimento, origem de entrada do paciente na unidade de urgência/emergência e motivo do atendimento.

2.6.37. O sistema deve permitir imprimir a FAA nos atendimentos retroativos.

2.6.38. Ao registrar a FAA em data retroativa, o sistema deve permitir cadastrar o médico plantonista da UPA/PS.

2.6.39. O sistema deve gerar relatório que apresente os CID’s que foram registrados nos atendimentos realizados na UPA/PS, contendo no mínimo: data, nome do paciente, unidade de atendimento, unidade de origem, especialidade médica, código do CID e quantidade.

2.6.40. O sistema deve gerar relatório de atendimento por bairro, contendo no mínimo: data do atendimento, nome do paciente, data de nascimento, unidade, bairro e total de atendimentos realizados.

2.6.41. O sistema deve gerar relatório que apresente os plantões do profissional, contendo no mínimo: data, horário de início do plantão, horário final do plantão, nome do médico plantonista, especialidade médica, unidade, total de atendimentos por médico e total de atendimentos geral.

2.6.42. O sistema deve apresentar uma lista de pacientes para atendimento (fila de espera), contendo no mínimo: data e horário de entrada na unidade, nome do paciente, idade, unidade de atendimento, senha do paciente e informar se a senha é preferencial.

2.6.43. O sistema deve atualizar automaticamente a lista de pacientes que aguardam atendimento.

2.6.44. O sistema deve permitir atualizar manualmente a lista de pacientes que aguardam atendimento.

2.6.45. O sistema deve permitir realizar o controle de classificação de risco, garantindo o atendimento imediato do paciente com grau de risco elevado.

2.6.46. O sistema deve permitir chamar senhas de atendimento por meio do painel de senhas (painel eletrônico) nas unidades que atendem urgências e emergências.

2.6.47. O sistema deve permitir registrar o atendimento realizado para o paciente na unidade de urgência/emergência.

2.6.48. O sistema deve gerar relatório que apresente os pacientes que deram entrada na UPA/PS pelo SAMU, contendo no mínimo: data do atendimento, número da FAA, nome do paciente, número do prontuário, especialidade médica, nome do médico do SAMU, status do atendimento e total de entradas pelo SAMU.

2.6.49. O sistema deve permitir consultar os atendimentos realizados na unidade de urgência/emergência por data do atendimento, unidade, especialidade médica, nome do médico plantonista e número da FAA.

2.6.50. O sistema deve permitir visualizar os atendimentos realizados na UPA/PS, contendo no mínimo: nome do paciente, número do prontuário, número da FAA, nome do médico plantonista e plantão registrado para o profissional.

2.6.51. O sistema deve permitir finalizar os atendimentos que foram realizados para os pacientes na UPA/PS, contendo no mínimo: status do atendimento (realizado, desistência), procedimentos realizados, CID, classificação de risco e internação.

2.6.52. O sistema deve permitir registrar somente procedimentos que estejam em conformidade com a tabela unificada de procedimentos SUS (SIGTAP).

2.6.53. O sistema deve permitir finalizar várias FAA’s simultaneamente.

2.6.54. O sistema deve permitir registrar o mesmo procedimento em várias FAA’s

simultaneamente.

2.6.55. O sistema deve permitir registrar o mesmo status do atendimento (realizado,

desistência) em várias FAA’s simultaneamente.

2.6.56. O sistema deve permitir registrar vários procedimentos em um único atendimento (FAA).

2.6.57. O sistema deve permitir consultar procedimentos por código e nome.

2.6.58. Ao finalizar os atendimentos realizados na UPA/PS, o sistema deve permitir

visualizar o total de FAA’s que foram atendidas.

2.6.59. Ao registrar o atendimento prestado na unidade de saúde (UPA, PS), o sistema deve permitir consultar o paciente por nome, número do prontuário e número da FAA.

2.6.60. O sistema deve permitir registrar os atendimentos realizados nas unidades de saúde (UPA, PS), contendo no mínimo: nome do paciente, número do CNS, data de nascimento, idade, sexo, unidade que o paciente pertence, unidade de atendimento, nome do médico plantonista, data e horário do atendimento, sinais

vitais (temperatura, pulso, respiração, pressão arterial), classificação de risco, hora de entrada, hora de saída, tempo de permanência, anamnese, exame clínico, prescrição médica, exames SADT (Serviço de Apoio Diagnóstico Terapêutico), anotações de enfermagem, procedimentos realizados, CID e CBO.

2.6.61. O sistema deve permitir visualizar a data da última consulta realizada para o paciente na unidade de urgência/emergência.

2.6.62. O sistema deve permitir visualizar o motivo do atendimento e a origem de entrada do paciente na unidade de saúde (espontânea, SAMU, intervias, renovias, ambulância).

2.6.63. O sistema deve gerar impressão da ficha de Atendimento Ambulatorial, contendo no mínimo: número da FAA, data e horário de emissão da FAA, unidade, especialidade médica, nome do médico plantonista, número do registro profissional, nome da atendente da recepção, hora de entrada, hora de saída, tempo de permanência, origem de entrada, nome do paciente, data de nascimento, idade, sexo, número do CNS, número do prontuário, nome da mãe, endereço, telefone residencial, telefone celular, telefone de recado, motivo do atendimento, sinais vitais, classificação de risco, data da última consulta realizada para o paciente, anamnese, exame clínico, diagnóstico/CID, exames SADT, prescrição médica, procedimentos realizados, local para o paciente ou responsável assinar e local para o médico assinar.

2.6.64. O sistema deve permitir transferir FAA de um médico para outro.

2.6.65. O sistema deve permitir finalizar o atendimento registrado para o paciente na unidade de saúde (UPA, PS), contendo no mínimo: nome do médico, status do atendimento (realizado, desistência) e os procedimentos realizados.

2.6.66. O sistema deve permitir cadastrar, alterar e excluir doenças de notificação compulsória.

2.6.67. O sistema deve permitir consultar o CID por código e nome para realizar o cadastro de doenças de notificação compulsória.

2.6.68. O sistema deve permitir visualizar as doenças de notificação compulsória cadastradas.

2.6.69. O sistema deve gerar relatório de doenças de notificação compulsória, contendo no mínimo: nome do paciente, nome da mãe, endereço, data de nascimento, telefone, número da FAA, data da FAA, nome do médico, CID, doença, total de doenças por paciente, total de pacientes e total de doenças.

2.6.70. O sistema deve gerar relatório que apresente as FAA’s finalizadas na UPA/PS, contendo no mínimo: número da FAA, nome do paciente, número do prontuário, procedimentos e CID's realizados.

2.6.71. O sistema deve gerar relatório de acompanhantes, contendo no mínimo: nome do paciente, número do prontuário, data de nascimento, nome do médico plantonista, nome do acompanhante, total de pacientes no período e total de acompanhantes no período.

2.6.72. O sistema deve gerar relatório quantitativo de procedimentos realizados por período e por dia, contendo no mínimo: código do procedimento, nome do procedimento, quantidade e total geral de procedimentos realizados.

2.6.73. O sistema deve gerar relatório de classificação de risco dos atendimentos realizados na UPA/PS, contendo no mínimo: unidade, classificação de risco (vermelho, laranja, amarelo, verde e azul), total de classificação de risco por unidade e total de classificação de risco geral.

2.6.74. O sistema deve gerar relatório de procedimentos por FAA, contendo no mínimo: unidade, nome do médico, especialidade médica, data do atendimento, número

da FAA, CBO, procedimento, quantidade, total de atendimentos, total de procedimentos, total geral de atendimentos e total geral de procedimentos.

2.6.75. O sistema deve apresentar uma lista de pacientes para atendimento na ordem que foi definida a classificação de risco, contendo no mínimo: data e horário de entrada na unidade, nome do paciente, idade, classificação de risco (vermelho, laranja, amarelo, verde e azul) e nome do médico plantonista.

2.6.76. O sistema deve atualizar automaticamente a lista de pacientes que aguardam atendimento de acordo com a classificação de risco definida.

2.6.77. O sistema deve permitir atualizar manualmente a lista de pacientes que aguardam atendimento de acordo com a classificação de risco definida.

2.6.78. O sistema deve permitir chamar senhas de atendimento por meio do painel de senhas (painel eletrônico) nas unidades que atendem urgências e emergências.

2.6.79. O sistema deve permitir registrar o atendimento realizado para o paciente na unidade de urgência/emergência.

2.6.80. O sistema deve gerar relatório que apresente os motivos dos atendimentos na UPA/PS, contendo no mínimo: data do atendimento, unidade, motivo do atendimento, quantidade e total de motivos.

2.6.81. O sistema deve gerar relatório de procedimentos lançados na UPA/PS, contendo no mínimo: data e horário do atendimento, número da FAA, nome do paciente, número do prontuário, status do atendimento, código do procedimento, CBO, quantidade, total de atendimentos realizados e total de procedimentos realizados.

2.6.82. O sistema deve gerar relatório de produção da UPA/PS, contendo no mínimo: código do procedimento, CBO, idade do paciente, quantidade e status do atendimento.

2.6.83. O sistema deve gerar relatório de plantão, contendo no mínimo: data e horário de início do plantão, data e horário final do plantão, unidade, especialidade médica, nome do médico, horas trabalhadas, total de horas referente ao período do plantão e total de horas trabalhadas no período.

2.6.84. O sistema deve permitir gerar relatório de atendimentos realizados por dia no pronto atendimento, de acordo com o município e bairro de moradia dos pacientes, contendo no mínimo: bairro, todos os dias do mês selecionado, total por dia, total geral.

2.6.85. O sistema deve permitir impressão do relatório de atendimentos realizados por dia no pronto atendimento, de acordo com o município e bairro de moradia dos pacientes, contendo no mínimo: bairro, todos os dias do mês selecionado, total por dia, total geral.

2.6.86. O sistema deve permitir gerar relatório de atendimentos realizados por dia no pronto atendimento de acordo com o município de moradia dos pacientes, contendo no mínimo: município, todos os dias do mês selecionado, total por dia, total geral.

2.6.87. O sistema deve permitir impressão do relatório de atendimentos realizados por dia no pronto atendimento, de acordo com o município de moradia dos pacientes, contendo no mínimo: município, todos os dias do mês selecionado, total por dia, total geral.

2.6.88. O sistema deve permitir o agendamento da consulta para o paciente selecionando o especialista ou não e gerar automaticamente a senha de atendimento.

2.6.89. Quando o atendimento for proveniente de acidente de trabalho, o sistema deve permitir informar os dados do empregador, contendo no mínimo: ocupação, nome do empregador, endereço, bairro, telefone, município, UF e CEP.

2.6.90. Quando o atendimento for proveniente de acidente de trabalho, o sistema deve permitir imprimir a ficha RAAT.

2.6.91. Para agendamento da consulta no pronto atendimento, o sistema deve permitir buscar o paciente no mínimo pelo nome e data de nascimento.

2.6.92. O sistema deve permitir inserir o nome do médico do SAMU, caso o paciente tenha dado entrada no pronto atendimento pelo SAMU.

2.6.93. O sistema deve permitir imprimir a FAA do paciente.

2.6.94. O sistema deve permitir imprimir de uma só vez, as FAA's, de todos os pacientes agendados.

2.6.95. Quando o paciente possui acompanhante, o sistema deve permitir imprimir o comprovante de acompanhante, contendo no mínimo: nome do acompanhante, nome do paciente, nome social, data e número da FAA.

2.6.96. O sistema deve gerar relatório de RAAT emitida, contendo no mínimo: data do atendimento, paciente, data de nascimento e número do prontuário.

2.6.97. O sistema deve permitir que seja reimpressa a RAAT de um paciente listado no relatório de RAAT emitida.

2.6.98. O sistema deve permitir que seja gerada e impressa uma nova RAAT com os dados do paciente e do empregador.

2.6.99. O sistema deve permitir gerar relatório por pacientes atendidos, contendo no mínimo: data, paciente, unidade de origem, classificação de risco, internação e status.

2.6.100. O sistema deve permitir dispensar produtos do estoque da unidade para um paciente que possui um atendimento.

2.6.101. Ao dispensar produto do estoque para o paciente em atendimento, o sistema deve permitir buscar o paciente pelo número do prontuário, nome e data de nascimento.

2.6.102. Ao buscar pacientes para dispensar produto do estoque, o sistema deve exibir apenas pacientes que possuem alguma FAA em aberto na unidade que está realizando a dispensação e deve conter no mínimo os seguintes dados do paciente: número do prontuário, nome, data de nascimento e nome da mãe.

2.6.103. Ao dispensar produto para o paciente em atendimento, o sistema deve permitir dispensar apenas produto que possua saldo positivo no almoxarifado da unidade que está realizando a dispensação e quantidade não superior ao saldo existente.

2.6.104. O sistema deve permitir definir procedimentos padrões por especialidade, desde que estes sejam compatíveis com o CBO vinculado à especialidade em questão.

2.6.105. O sistema deve permitir definir se o usuário irá visualizar e imprimir o Termo de Ciência.

2.6.106. O sistema deve permitir definir se será necessário a Senha do Supervisor para Alteração dos dados da FAA.

2.6.107. O Sistema deve permitir definir se os campos Hora de Entrada e Hora de Saída serão preenchidos automaticamente ao realizar a triagem do paciente.

2.6.108. O sistema deve permitir definir procedimentos padrões a serem faturados por unidade e CBO.

2.6.109. O sistema deve gerar relatório de FAA's que foram alteradas, contendo no mínimo: data e hora da alteração, número da FAA, nome do paciente, supervisor, o usuário que realizou a alteração e o procedimento que foi incluído/excluído (caso tenha sido essa a alteração).

2.6.110. O sistema deve permitir gerar relatório de pacientes encaminhados, contendo no mínimo: data do atendimento, hora de emissão da FAA, paciente, prontuário, unidade que realizou o encaminhamento, unidade de cadastro do paciente.

2.6.111. O sistema deve permitir alterar os dados do plantão registrado para o profissional somente se o usuário logado for supervisor ou se o supervisor liberar a alteração com seu usuário e senha.

2.6.112. O sistema deve permitir cadastrar plantões somente se o médico possuir uma especialidade vincula a seu cadastro e que possuam duração máxima de 36 horas.

2.6.113. O sistema não deve permitir cadastrar plantão para profissional com uma data inicial maior do que um ano em relação a data atual.

2.6.114. O sistema deve permitir cadastrar os plantonistas para atender a demanda da Unidade de Pronto Atendimento (UPA) e do Pronto Socorro (PS), contendo no mínimo: nome do profissional, especialidade médica, data e horário de início do plantão, data e horário final do plantão.

2.6.115. O sistema deve permitir limitar a quantidade de atendimentos por plantão.

2.6.116. O sistema deve permitir visualizar os plantões cadastrados, contendo no mínimo: nome do profissional, especialidade médica, data e horário de início do plantão, data e horário final do plantão.

2.6.117. O sistema deve permitir excluir o plantão registrado para o profissional somente se não existir atendimento vinculado.

2.6.118. O sistema deve permitir consultar por período o histórico de plantões do profissional.

2.6.119. O sistema deve permitir impressão do histórico de plantões do profissional, contendo no mínimo: nome do médico plantonista, especialidade médica, nome da unidade e os plantões cadastrados no período.

2.6.120. O sistema deve permitir cadastrar plantões em datas retroativas somente com permissão de supervisor.

2.6.121. O sistema deve permitir gerar um Relatório de Tempo de Atendimento informando o mínimo Data Inicial, Data Final, Plantonista ou Paciente.

2.6.122. O sistema deverá exibir o resultado do Relatório de Tempo de Atendimento contendo Plantonista, Paciente, Chegada Paciente, Início Triagem, Fim Triagem, Início Atendimento Médico, Fim Atendimento Médico, Início Plantão, Fim Plantão e Status.

2.6.123. O sistema deve permitir imprimir o resultado Relatório de Tempo de Atendimento.

2.7. Módulo Controle dos Exames Laboratoriais

2.7.1. Deve permitir cadastrar grupos de exames;

2.7.2. Deve permitir cadastrar supervisores que terão privilégio de liberar exames bloqueados e exames sigilosos;

2.7.3. Deve permitir cadastrar exames contendo no mínimo: código do exame, descrição do exame, sexo de abrangência, grupo de exame, prazo de entrega, prazo de validade, ativo (sim ou não), número de reagente, código do procedimento, valor;

2.7.4. Deve permitir utilizar valor dos exames da tabela SIGTAP automaticamente;

2.7.5. Deve permitir cadastrar valor de exames conforme tabela dos prestadores;

2.7.6. Deve permitir configurar se o exame é sigiloso;

2.7.7. Deve permitir cadastrar a posição do exame no mapa de produção;

2.7.8. Deve permitir configurar quais exames poderão ser realizados por pacientes provisórios e de outros municípios;

2.7.9. Deve permitir configurar laudo por exame;

2.7.10. Deve permitir cadastrar o tipo de resultado por exame contendo no mínimo as opções: numérico, texto, alfanumérico, opções, fórmula;

2.7.11. Deve permitir cadastrar quantidade de casas decimais por linha de resultado;

2.7.12. Deve permitir cadastrar unidades de medidas;

2.7.13. Deve permitir cadastrar por exame o limite inferior mínimo e o limite superior máximo;

2.7.14. Deve permitir cadastrar os valores de referência por exame, por idade, por sexo;

2.7.15. Deve permitir cadastrar os exames que terão laudo exclusivo;

2.7.16. Deve permitir cadastrar os exames que terão laudo agrupado por grupo de exames;

2.7.17. Deve permitir cadastrar fórmulas de resultados;

2.7.18. Deve permitir cadastrar os locais de coletas contendo no mínimo: nome da unidade, dias da semana, horário inicial de coleta por dia da semana, horário final de coleta por dia da semana, quantidade máxima de coleta por dia da semana;

2.7.19. Deve permitir cadastrar várias unidades de coleta e unidades de coleta terceirizadas;

2.7.20. Deve permitir cadastrar os laboratórios executores contendo no mínimo: nome da unidade, dias da semana, horário inicial de coleta por dia da semana, horário final de coleta por dia da semana, quantidade máxima de coleta por dia da semana;

2.7.21. Deve permitir cadastrar vários laboratórios executores e terceirizados;

2.7.22. Deve permitir cadastrar cota e horário de coleta por unidade de coleta e por dia;

2.7.23. Deve permitir cadastrar cota física ou financeira por unidade solicitante contendo no mínimo: unidade solicitante, tipo da cota (física ou financeira), valor da cota, cota utilizada, mês, ano;

2.7.24. Deve permitir alterar/excluir cota física ou financeira por unidade solicitante;

2.7.25. Deve permitir cadastrar cota física ou financeira por laboratório executante contendo no mínimo: laboratório executante, tipo da cota (física ou financeira), valor da cota, cota utilizada, mês, ano, descrição da cota;

2.7.26. Deve permitir alterar/excluir cota física ou financeira por laboratório executante;

2.7.27. Deve permitir agendar a coleta de exame contendo no mínimo: nome do paciente, número do prontuário, data de nascimento, idade, sexo, estado civil, RG, CPF, médico solicitante, uso de medicamento, suspeita clínica urgente (sim ou não), local da coleta, laboratório executor, exames, data da coleta;

2.7.28. Deve permitir no agendamento da coleta, registrar a data da última menstruação, gestante (sim ou não), urgente (sim ou não);

2.7.29. Deve permitir no mesmo pedido agendar vários exames;

2.7.30. Deve mostrar a quantidade de coleta disponível por dia e por local de coleta;

2.7.31. Deve permitir que o agendamento de coleta seja feito de forma descentralizada online;

2.7.32. Não deve permitir agendar coletas em datas com feriados ou pontos facultativos cadastrados;

2.7.33. Não deve permitir agendar a coleta sem selecionar o local da coleta;

2.7.34. Não deve permitir agendar coleta de exames incompatíveis com o sexo do paciente;

2.7.35. Não deve permitir agendar coleta de exames sigilosos para operadores não autorizados;

2.7.36. Deve bloquear solicitação de agendamento de exames de pacientes que realizaram o mesmo exame e que está dentro do prazo de validade;

2.7.37. Deve bloquear o agendamento de exames a pacientes temporários e de outros municípios;

2.7.38. Deve permitir liberar o exame bloqueado através de senha de supervisor;

2.7.39. Deve bloquear o agendamento de exames ao atingir a capacidade máxima de coleta por unidade de coleta;

2.7.40. Deve bloquear o agendamento de exames ao atingir a cota de solicitação por unidade ou a cota do laboratório executor;

2.7.41. Deve permitir visualizar no calendário de agendamento a cota disponível por unidade solicitante;

2.7.42. Deve gerar comprovante de agendamento de exame contendo no mínimo: nome da unidade solicitante, endereço da unidade solicitante, telefone da unidade solicitante, nome do paciente, data de nascimento, número do prontuário, médico solicitante, código do pedido, data da coleta, horário da coleta, data prevista de entrega do laudo, local da coleta, exames solicitados, mensagem de observação;

2.7.43. Deve gerar etiqueta de agendamento de exame contendo no mínimo: nome do paciente, idade, prontuário, unidade, número do pedido;

2.7.44. Deve gerar o número do pedido automaticamente considerando todas as unidades solicitantes;

2.7.45. Deve permitir agendar pedidos de exames em datas retroativas;

2.7.46. Deve permitir reimprimir comprovante de agendamento de exames;

2.7.47. Deve permitir personalizar a mensagem de orientação do comprovante de agendamento de exames;

2.7.48. Deve permitir alterar agendamentos de coleta contendo no mínimo: nome do paciente, número do prontuário, número do pedido, data da solicitação, médico solicitante, operador que realizou o agendamento, exame, unidade de coleta, laboratório executor, calendário de coleta;

2.7.49. Deve permitir excluir agendamentos de coleta registrados erroneamente;

2.7.50. Deve gerar listagem de coletas agendadas contendo no mínimo: data, unidade de coleta, exame, nome do paciente, idade, número do prontuário, número do pedido, exame;

2.7.51. Deve gerar etiquetas com código de barras a serem coladas nos tubos contendo no mínimo: nome do paciente, idade, exame, código do pedido, unidade solicitante;

2.7.52. Deve permitir imprimir todas as etiquetas dos pacientes agendados no dia;

2.7.53. Deve permitir o lançamento de coleta contendo no mínimo: data, grupo de exames, exame, unidade solicitante, unidade de coleta, nome do paciente, número do prontuário, número do pedido, médico solicitante, status (faltou ou realizado);

2.7.54. Deve permitir a geração de mapa de produção contendo no mínimo: data, grupo de exames, exame, unidade, nome do paciente, idade, código do pedido, código do exame, campos de resultados;

2.7.55. Deve gerar o mapa de produção de acordo com as configurações do cadastro de exames, considerando exames do mesmo grupo, exames agrupados, exames exclusivos, posição no mapa;

2.7.56. Deve permitir o lançamento de resultado contendo no mínimo: código do pedido, nome do paciente, data de nascimento, data da coleta, exame, resultado, observação;

2.7.57. Deve permitir o lançamento de diferentes tipos de resultado com no mínimo: numérico, texto, alfanumérico, opção, fórmula;

2.7.58. Deve informar automaticamente se o resultado está alterado;

2.7.59. Deve permitir registrar o resultado de vários exames do mesmo paciente em uma única tela;

2.7.60. Deve permitir alterar/excluir resultados de exames registrados erroneamente;

2.7.61. Deve permitir rotina para autorizar laudos contendo no mínimo: data do pedido, nome do paciente, data de nascimento, código do pedido, nome do responsável, exame, resultados do exame, opção para autorizar;

2.7.62. Deve permitir gerar autorização do laudo através de senha digitalizada;

2.7.63. Deve gerar impressão dos laudos no laboratório ou descentralizada, possibilitando que todas as unidades de rede municipal de Saúde possam imprimir o laudo “on- line” com assinatura digitalizada dos profissionais executores;

2.7.64. Deve gerar impressão do Laudo contendo no mínimo: nome do paciente, número do prontuário, data de nascimento, idade, sexo, telefone, unidade solicitante, médico solicitante, número do pedido, data da solicitação, data da coleta, data do laudo, resultados do exame, nome e assinatura do profissional executor, número do registro profissional do profissional executor;

2.7.65. Deve permitir acesso on-line dos laboratórios terceirizados, para que estes retirem a listagem das pessoas que irão realizar a coleta;

2.7.66. Deve permitir que o laboratório terceirizado possa lançar e auditar o resultado do exame do munícipe diretamente no Sistema de Gestão via internet (on-line) e desta maneira possibilitar a entrega do exame em qualquer Unidade de Saúde;

2.7.67. Deve permitir controle de exames por status contendo no mínimo: agendado, não coletado, pendente de lançamento de resultados, pendente de conferência, pendente de impressão de laudo, pendente de entrada, entregue;

2.7.68. Deve permitir registrar a entrega dos exames contendo no mínimo: nome do paciente, número do prontuário, data de nascimento, código do pedido, data do pedido, data da coleta, exame, entregue (sim ou não), impressão do laudo, campo para o paciente assinar que retirou o exame;

2.7.69. Deve permitir consulta por paciente ao histórico de exames laboratoriais contendo no mínimo: nome do paciente, data de nascimento, número do prontuário, endereço, telefone, número do pedido, data da solicitação, data da coleta, previsão de entrega, unidade solicitante, médico solicitante, exame, status;

2.7.70. Deve gerar relatório de exames bloqueados contendo no mínimo: período, unidade, exame, data do pedido, hora do pedido, nome do paciente, unidade solicitante, exame bloqueado, valor economizado por exame, quantidade total de exames economizados no período, valor total economizado no período;

2.7.71. Deve gerar relatório de exames repetidos contendo no mínimo: período, unidade, nome do paciente, número do prontuário, data de nascimento, médico solicitante, data da coleta, exame, código e descrição do procedimento, valor unitário por exame, quantidade de exames por paciente, valor total por paciente;

2.7.72. Deve gerar relatório de exames por status contendo no mínimo: período, exame, status, unidade solicitante, unidade de coleta, laboratório executor, data do pedido, data da coleta, nome do paciente;

2.7.73. Deve gerar relatório de pacientes atendidos contendo no mínimo: período, unidade solicitante, médico solicitante, data do pedido, data da coleta, código do pedido, nome do paciente, total de pacientes atendidos;

2.7.74. Deve gerar relatório de produção contendo no mínimo: período, unidade de coleta, laboratório executor, exame, quantidade de exames realizados por procedimento, quantidade por reagentes, quantidade total de exames, quantidade total de reagentes;

2.7.75. Deve gerar relatório financeiro de exames contendo no mínimo: exame, quantidade por exame, valor unitário por exame, valor total por exame, valor total geral;

2.7.76. Deve gerar relatório histórico do paciente contendo no mínimo: período, unidade, exame, nome do paciente, data de nascimento, exame, status, quantidade de exames;

2.7.77. Deve gerar relatório quantitativo de exames solicitados contendo no mínimo: período, unidade, exame, quantidade por exame, quantidade total geral;

2.7.78. O módulo de exames laboratoriais deverá trabalhar integrado com o módulo faturamento.

2.8. Módulo Controle dos Exames de Imagem

2.8.1. O sistema deve permitir alterar um pedido de exames agendado.

2.8.2. O sistema deve permitir consultar o paciente por nome, número do prontuário e data de nascimento para alterar o pedido de exames agendado.

2.8.3. O sistema deve permitir visualizar todos os pedidos de exames agendados para o paciente, contendo no mínimo: nome do paciente, número do pedido, data solicitada, data agendada, nome do médico solicitante e nome do operador que realizou o agendamento.

2.8.4. O sistema deve permitir cancelar o pedido de exames agendado.

2.8.5. Ao cancelar o pedido de exames agendado, o sistema deve liberar na agenda a vaga da jornada cancelada.

2.8.6. O sistema deve permitir visualizar no pedido todos os exames já agendados para o paciente.

2.8.7. O sistema deve permitir incluir novos exames no pedido agendado.

2.8.8. O sistema deve permitir excluir os exames agendados erroneamente.

2.8.9. O sistema deve permitir reimprimir o comprovante de agendamento de exames para o paciente.

2.8.10. Ao alterar um pedido de exames agendado, o sistema deve permitir reimprimir a etiqueta do paciente, contendo no mínimo: nome do paciente, data de nascimento, número do prontuário, médico solicitante, número do pedido, data do agendamento e exame.

2.8.11. O sistema deve permitir alterar a data de agendamento do pedido de exames.

2.8.12. Ao alterar um pedido de exames agendado, o sistema deve apresentar na agenda, de forma destacada, a data que o pedido está agendado.

2.8.13. O sistema deve permitir consultar os exames de imagem agendados por data do agendamento, unidade executante, grupo de exames, profissional e nome do exame.

2.8.14. O sistema deve permitir visualizar os exames agendados, contendo no mínimo: data do agendamento, nome do paciente, idade, número do prontuário, nome do médico solicitante e nome do exame solicitado.

2.8.15. O sistema deve permitir registrar se o exame de imagem agendado para o paciente foi realizado ou não.

2.8.16. O sistema deve permitir registrar automaticamente para todos os exames de imagem agendados se eles foram realizados ou não.

2.8.17. Ao fechar o exame de imagem agendado, o sistema deve permitir registrar o laudo médico (resultado do exame).

2.8.18. O sistema deve permitir parametrizar se os exames de imagem serão faturados para a unidade executante ou para a unidade prestadora.

2.8.19. O sistema deve permitir realizar um exame de imagem somente se ele estiver em conformidade com a tabela unificada de procedimentos SUS (SIGTAP): idade do paciente, sexo do paciente, instrumento de registro, CBO.

2.8.20. O sistema deve permitir consultar os exames de imagem realizados para o paciente por data do agendamento, nome do paciente, número do prontuário, data de nascimento e nome do exame para lançar o laudo médico.

2.8.21. O sistema deve permitir lançar o resultado do exame, contendo no mínimo: nome do paciente, número do prontuário, data de nascimento, idade completa, nome

do exame, médico solicitante, unidade solicitante, unidade executante, data do pedido e data de realização do exame.

2.8.22. O sistema deve permitir impressão do laudo médico, contendo no mínimo: nome do paciente, número do prontuário, data de nascimento, idade completa, nome do exame, unidade solicitante, médico solicitante, unidade executante, nome do profissional executante, data do pedido, data de realização do exame, resultado do exame, assinatura do profissional executor e número do registro profissional.

2.8.23. O sistema deve gerar relatório dos exames de imagem agendados, contendo no mínimo: nome do paciente, nome social, idade, número do prontuário, telefone para contato, horário do agendamento, profissional executante, grupo de exames, nome do exame, unidade solicitante, nome do operador que realizou o agendamento e total de exames agendados.

2.8.24. O sistema deve permitir impressão da etiqueta do paciente com a identificação do exame agendado.

2.8.25. O sistema deve permitir consultar o paciente por nome, número do prontuário e data de nascimento para agendar exames de imagem.

2.8.26. O sistema deve permitir visualizar os dados do paciente durante o agendamento de exames, contendo no mínimo: nome do paciente, nome social, sexo, data de nascimento, idade, número do prontuário, CNS, estado civil, RG e CPF.

2.8.27. Ao agendar exames de imagem, o sistema deve permitir gerenciar os agendamentos por exames ou atendimentos.

2.8.28. Ao agendar exames de imagem, o sistema deve permitir consultar a agenda do profissional por mês e ano.

2.8.29. O sistema deve permitir agendar exames de imagem, contendo no mínimo: nome do médico solicitante, local de realização do exame, grupo de exames, nome do profissional certificado para realizar exames, data e horário do agendamento, exames solicitados e se o pedido é urgente.

2.8.30. O sistema deve permitir solicitar vários exames de imagem no mesmo pedido.

2.8.31. Ao agendar exames de imagem, o sistema deve permitir cadastrar observação que deverá ser impressa no comprovante de agendamento.

2.8.32. Ao realizar o agendamento de exames de imagem, o sistema deve permitir informar o responsável pelo paciente.

2.8.33. Ao agendar exames de imagem, o sistema deve permitir cadastrar novos médicos (médico solicitante).

2.8.34. O sistema deve permitir visualizar na agenda do profissional as datas disponíveis para agendamento de exames conforme jornada de trabalho definida.

2.8.35. O sistema deve permitir visualizar na agenda do profissional a quantidade de vagas definidas para agendamento de exames e a quantidade de vagas agendadas (ocupadas) por dia.

2.8.36. Ao agendar exames de imagem, o sistema deve sugerir o primeiro horário livre (data, horário e dia da semana) da agenda do profissional.

2.8.37. O sistema deve bloquear na agenda do profissional os dias com feriados ou pontos facultativos cadastrados.

2.8.38. O sistema deve bloquear a agenda do profissional nos dias em que o profissional se ausentar por alguma ocorrência (licença, falta, congresso, entre outras) e nas férias do profissional.

2.8.39. O sistema deve permitir agendar exames de imagem em todas as unidades executantes do município.

2.8.40. O sistema deve permitir impressão do comprovante de agendamento de exames para o paciente, contendo no mínimo: dados da unidade solicitante, dados da

unidade executante (nome, endereço e telefone), nome do paciente, nome social, número do prontuário, data de nascimento, nome do médico solicitante, data e horário do agendamento, nome do profissional que realizará os exames de imagem, grupo de exames, número do pedido e os nomes dos exames agendados.

2.8.41. Ao atingir o limite de vagas para agendamentos de exames (exames ou atendimentos) definidos para o dia, o sistema deve bloquear a data na agenda do profissional e permitir agendamentos somente com a senha de supervisor.

2.8.42. Ao atingir o limite da cota mensal para agendamentos de exames, o sistema deve informar que a cota do prestador foi atingida e deve permitir agendamentos somente com a senha de supervisor.

2.8.43. Ao agendar exames de imagem, o sistema deve apresentar quais exames poderão ser agendados por pacientes provisórios e de outros municípios.

2.8.44. Ao realizar o agendamento de exames de imagem, o sistema deve permitir agendar somente os exames que estejam em conformidade (idade do paciente, sexo do paciente) com a tabela unificada de procedimentos SUS (SIGTAP).

2.8.45. O sistema deve permitir alertar que o paciente está com os dados cadastrais desatualizados.

2.8.46. O sistema deve permitir consultar o paciente por nome, número do prontuário e data de nascimento para reimprimir os resultados dos exames realizados.

2.8.47. O sistema deve permitir reimpressão do laudo médico, contendo no mínimo: nome do paciente, número do prontuário, data de nascimento, idade completa, nome do exame, unidade solicitante, médico solicitante, unidade executante, nome do profissional executante, data do pedido, data de realização do exame, resultado do exame, assinatura do profissional executor e número do registro profissional.

2.8.48. O sistema deve gerar relatório quantitativo de exames de imagem solicitados, contendo no mínimo: nome do exame, código do procedimento, quantidade e total.

2.8.49. O sistema deve permitir cadastrar exames de imagem contendo no mínimo: nome do exame, sexo de abrangência, prazo de entrega, validade do exame, preparo, número de incidências e se o exame exige procedimento.

2.8.50. O sistema deve permitir vincular um procedimento ao exame de imagem.

2.8.51. O sistema deve permitir cadastrar o preparo do exame para orientar o paciente.

2.8.52. O sistema deve permitir inativar ou ativar o exame de imagem cadastrado.

2.8.53. O sistema deve permitir utilizar automaticamente o valor dos exames de imagem da tabela SIGTAP.

2.8.54. O sistema deve permitir cadastrar o valor dos exames de imagem conforme tabela dos prestadores.

2.8.55. O sistema deve permitir parametrizar quais exames de imagem poderão ser realizados por pacientes provisórios e de outros municípios.

2.8.56. O sistema deve permitir indicar a qual grupo de exames pertence o exame cadastrado.

2.8.57. O sistema deve permitir visualizar os exames de imagem cadastrados.

2.8.58. O sistema deve permitir alterar os exames de imagem cadastrados.

2.8.59. O sistema deve permitir registrar se o exame de imagem é regulado ou não.

2.8.60. O sistema deve permitir formatar o laudo médico por exame, contendo no mínimo: tamanho da fonte, cor da fonte, negrito, itálico, sublinhado, alinhamento do texto, recortar, copiar, colar, marcadores, numeração, diminuir recuo e aumentar recuo.

2.8.61. O sistema deve permitir personalizar a mensagem de orientação do comprovante de agendamento de exames.

2.8.62. O sistema deve permitir cadastrar, consultar e excluir locais de realização de exames de imagem.

2.8.63. O sistema deve permitir visualizar os locais de realização de exames cadastrados.

2.8.64. O sistema deve permitir parametrizar os grupos de exames de imagem.

2.8.65. O sistema deve permitir visualizar os grupos de exames cadastrados.

2.8.66. O sistema deve permitir excluir o grupo de exames parametrizado somente se não existir exames vinculados.

2.8.67. O sistema deve permitir parametrizar se os agendamentos de exames serão controlados por exames ou por atendimentos nas unidades executantes.

2.8.68. O sistema deve permitir cadastrar unidades executantes e prestadores de serviços de exames de imagem.

2.8.69. O sistema deve permitir definir um prestador padrão (público ou privado) para a unidade executante.

2.8.70. O sistema deve permitir alterar o prestador padrão definido para a unidade executante.

2.8.71. O sistema deve permitir visualizar as unidades executantes e os prestadores de exames cadastrados.

2.8.72. O sistema deve permitir consultar as unidades executantes e os prestadores cadastrados.

2.8.73. O sistema deve permitir excluir, desabilitar ou habilitar a unidade executante e o prestador cadastrados.

2.8.74. O sistema deve permitir cadastrar supervisores que terão permissão para autorizar agendamentos de exames quando o limite da jornada definida para a unidade executante exceder e quando o limite da cota de exames definida para o prestador exceder.

2.8.75. O sistema deve permitir visualizar os supervisores cadastrados.

2.8.76. O sistema deve permitir excluir o supervisor cadastrado.

2.8.77. O sistema deve permitir cadastrar cotas mensais para as unidades prestadoras de exames, contendo no mínimo: nome da unidade, tipo de cota (física ou financeira), quantidade/valor da cota, mês e ano.

2.8.78. O sistema deve permitir consultar as cotas cadastradas por nome do prestador, ano e mês.

2.8.79. O sistema deve permitir visualizar as cotas cadastradas por prestador, contendo no mínimo: nome da unidade, cota definida, cota utilizada, tipo de cota, mês e ano.

2.8.80. O sistema deve permitir alterar a cota de exames cadastrada para o prestador.

2.8.81. O sistema deve permitir excluir a cota cadastrada para o prestador.

2.8.82. O sistema deve permitir consultar o profissional por nome e cargo para criar sua agenda de atendimentos de exames de imagem.

2.8.83. Ao criar a agenda de atendimentos de exames de imagem, o sistema deve permitir visualizar o nome completo do profissional, data de nascimento, sexo, estado civil, número do registro profissional, RG, CPF e tipo de contratação.

2.8.84. O sistema deve permitir cadastrar jornadas de trabalho para o profissional (médico, técnico ou outro profissional certificado para realizar exames de imagem) em diferentes unidades executantes do município.

2.8.85. O sistema deve permitir criar a agenda de exames por dia e por período.

2.8.86. Ao criar a agenda por dia, o sistema deve permitir escolher a unidade executante e o grupo de exames.

2.8.87. Ao criar a agenda por período, o sistema deve permitir escolher a unidade executante, os dias da semana, a operação desejada na agenda (inclusão, alteração ou exclusão) e o grupo de exames.

2.8.88. Ao criar a agenda do profissional, o sistema deve permitir controlar as jornadas por exames ou atendimentos.

2.8.89. Ao criar a agenda de exames, o sistema deve permitir cadastrar o horário inicial da jornada de trabalho, a quantidade de atendimentos ou exames que poderão ser agendados, tempo médio de cada atendimento, status da jornada e o prestador.

2.8.90. O sistema deve permitir visualizar as jornadas de trabalho cadastradas na agenda do profissional.

2.8.91. O sistema deve permitir consultar a agenda do profissional por mês e ano.

2.8.92. O sistema deve permitir alterar a agenda do profissional quando surgir alguma ocorrência que o impeça de realizar atendimentos de exames (licença, falta, congresso, plantão, emergência, férias, atestado, entre outras).

2.8.93. O sistema deve permitir cadastrar, alterar ou excluir jornadas de trabalho do profissional.

2.8.94. O sistema deve permitir visualizar na agenda de atendimentos do profissional a quantidade de vagas definidas para agendamento de exames e a quantidade de vagas agendadas (ocupadas) de acordo com as jornadas cadastradas.

2.8.95. Ao criar a agenda de atendimentos de exames, o sistema deve permitir visualizar os feriados ou pontos facultativos cadastrados.

2.8.96. O sistema deve permitir excluir a agenda de atendimentos de exames do profissional (jornadas de trabalho) somente se não existir agendamentos vinculados.

2.8.97. O sistema não deve permitir cadastrar jornadas para o mesmo profissional em dias e horários coincidentes.

2.8.98. O sistema deve permitir consultar o paciente por nome, número do prontuário e data de nascimento para realizar o agendamento de exames retroativo.

2.8.99. O sistema deve permitir registrar agendamentos de exames de imagem em datas retroativas.

2.8.100. O sistema deve gerar relatório de jornadas de trabalho cadastradas para o profissional (médico, técnico ou outro profissional certificado para realizar exames de imagem), contendo no mínimo: data do atendimento, nome do profissional, grupo de exames, dia da semana, horário inicial e final da jornada de trabalho, quantidade de atendimentos ou exames que poderão ser agendados, quantidade de agendamentos, status da jornada, total geral de atendimentos ou exames que poderão ser agendados e total geral de agendamentos.

2.8.101. O sistema deve gerar relatório financeiro de exames de imagem, contendo no mínimo: código do procedimento, nome do exame, quantidade, valor unitário, valor total e total geral.

2.8.102. O sistema deve gerar relatório financeiro de exames de imagem por paciente, contendo no mínimo: nome do paciente, número do prontuário, data de nascimento, data, nome do exame, código e nome do procedimento, valor unitário, valor total, total de exames por paciente, valor total por paciente, valor médio por paciente, total geral de exames, valor total geral e valor médio geral.

2.8.103. O sistema deve permitir consultar o paciente por nome, número do prontuário e data de nascimento para visualizar os exames de imagem agendados e os já realizados para o paciente.

2.8.104. Ao visualizar os exames de imagem agendados e os já realizados, o sistema deve exibir os dados do paciente, contendo no mínimo: nome do paciente, número do

prontuário, número do cartão nacional de saúde (CNS), data de nascimento, sexo, estado civil, RG, CPF, unidade de saúde que o paciente pertence, número da família, logradouro e telefones para contato.

2.8.105. O sistema deve permitir visualizar os exames de imagem agendados e os realizados para o paciente, contendo no mínimo: data, horário, nome do exame, unidade executante, profissional e número do pedido.

2.8.106. O sistema deve permitir visualizar os exames de imagem agendados e não realizados (paciente faltou).

2.8.107. O sistema deve permitir reimprimir o comprovante de agendamento de exames para o paciente.

2.8.108. O sistema deve permitir reimprimir o resultado do exame.

2.8.109. O sistema deve permitir impressão dos exames de imagem agendados e realizados para o paciente.

2.8.110. O sistema deve gerar relatório de exames de imagem por status, contendo no mínimo: data, nome do paciente, número do prontuário, nome do exame, código do procedimento, unidade solicitante, unidade executante, prestador, status, total de pacientes e total de exames.

2.8.111. O sistema deve gerar relatório de produção, contendo no mínimo: código e nome do procedimento, nome do exame, quantidade, unidade solicitante, unidade executante, nome do prestador, total de exames por unidade (solicitante, executante e prestadora) e total geral de exames.

2.8.112. O sistema deve permitir consultar os exames finalizados por data do atendimento, status do atendimento, unidade executante, grupo de exames, nome do profissional e nome do exame para alterar o status do exame registrado erroneamente.

2.8.113. O sistema deve permitir visualizar os exames finalizados, contendo no mínimo: nome do paciente, número do prontuário, nome do exame, código do procedimento e status registrados.

2.8.114. O sistema deve permitir alterar o status dos exames finalizados erroneamente para o status agendado.

2.8.115. O sistema deve permitir visualizar o total de exames realizados e não realizados de acordo com a data do atendimento.

2.8.116. O sistema deve gerar relatório de exames agendados e posteriormente cancelados, contendo no mínimo: data agendada, data em que o pedido foi cancelado, unidade executante, grupo de exames, profissional solicitante, nome do paciente, nome do exame, nome do operador que cancelou o pedido e total de exames cancelados.

2.8.117. O sistema deve permitir consultar o profissional por nome e cargo para transferir sua agenda de atendimentos de exames de imagem para outro profissional.

2.8.118. Ao transferir a agenda de atendimentos de exames de imagem, o sistema deve permitir visualizar o nome completo do profissional, data de nascimento, sexo, estado civil, número do registro profissional, RG, CPF e tipo de contratação.

2.8.119. O sistema deve permitir escolher o município, a unidade executante e o grupo de exames para visualizar os agendamentos de exames que poderão ser transferidos para outro profissional.

2.8.120. O sistema deve permitir escolher o profissional que receberá os agendamentos de exames (agenda) de outro profissional.

2.8.121. O sistema deve permitir escolher os pacientes que serão transferidos para outro profissional.

2.8.122. O sistema deve permitir escolher a jornada de trabalho que deseja transferir os pacientes.

2.9. Módulo Faturamento

2.9.1. O sistema deve permitir gerar o arquivo de exportação do faturamento, no padrão de layout disponibilizado pelo DATASUS, com todos os procedimentos (BPA/I e BPA/C) executados pelas unidades de saúde.

2.9.2. O sistema deve permitir gerar o arquivo de exportação do faturamento (BPA/I e BPA/C) por competência, unidade de saúde e financiamento.

2.9.3. Ao gerar o arquivo de exportação do faturamento (BPA/I e BPA/C), o sistema deve permitir informar o nome do arquivo a ser gravado.

2.9.4. O sistema deve permitir consultar, por período e unidade de saúde, os arquivos de exportação gerados (BPA/I e BPA/C).

2.9.5. Ao consultar os arquivos de exportação gerados (BPA/I e BPA/C), o sistema deve exibir a competência, nome da unidade de saúde, financiamento, data e hora de geração do arquivo e arquivo encaminhado (arquivo entregue ou não ao SIA).

2.9.6. O sistema deve permitir download do arquivo de exportação do faturamento (BPA/I e BPA/C), para ser encaminhado ao SIA.

2.9.7. O sistema deve gerar relatório de controle de remessa dos arquivos de exportação gerados (BPA/I e BPA/C), contendo no mínimo: competência, nome da unidade de saúde, nome do arquivo gerado e quantidade de registros gravados.

2.9.8. O sistema deve permitir o faturamento retroativo, de três meses, dos atendimentos prestados (procedimentos executados BPA/I e BPA/C), conforme regras do Sistema de Informação Ambulatorial (SIA/SUS).

2.9.9. O sistema deve permitir gerar o BPA consolidado por competência, aproveitando a produção já lançada pela unidade de saúde.

2.9.10. Ao gerar a produção dos procedimentos consolidados, por competência, o sistema deve considerar todos os atendimentos realizados na unidade de saúde, da competência atual e mais três anteriores, que não entraram nos arquivos de exportação do faturamento ao SIA.

2.9.11. Ao gerar a produção dos procedimentos consolidados, o sistema deve apresentar a quantidade de procedimentos gerados, a quantidade de folhas e de erros.

2.9.12. Ao gerar o BPA consolidado, o sistema deve informar se existem procedimentos executados, ainda não faturados, na unidade de saúde.

2.9.13. Ao gerar a produção, o sistema deve apresentar a folha e a quantidade de linhas dos procedimentos consolidados.

2.9.14. Ao gerar a produção dos procedimentos consolidados, o sistema deve agrupar, por competência, a quantidade de procedimentos realizados por CBO e idade.

2.9.15. O sistema deve permitir consultar a produção, por competência, unidade de saúde e CNES, dos procedimentos consolidados executados nos atendimentos prestados pela unidade de saúde.

2.9.16. Ao consultar a produção dos atendimentos realizados (procedimentos consolidados) pela unidade de saúde, o sistema deve exibir o CNES, nome da unidade, competência e folha.

2.9.17. O sistema deve apresentar, por competência, todos os procedimentos consolidados executados nos atendimentos prestados pela unidade de saúde, contendo no mínimo: procedimento, CBO, idade do paciente e quantidade de execução do procedimento.

2.9.18. O sistema deve permitir lançar manualmente, por competência, o boletim de produção ambulatorial (BPA) consolidado dos atendimentos prestados pelas unidades de saúde.

2.9.19. Ao lançar manualmente o BPA consolidado, o sistema deve permitir cadastrar no mínimo: CNES, competência, folha, procedimento, CBO, idade do paciente, quantidade de execução do procedimento e competência do atendimento.

2.9.20. Ao lançar manualmente o BPA consolidado, o sistema deve permitir cadastrar somente CBO válido.

2.9.21. Ao lançar manualmente o BPA consolidado, o sistema não deve exigir idade do

paciente, se o procedimento inserido é realizado “em grupo”.

2.9.22. Ao lançar manualmente o BPA consolidado, o sistema deve permitir informar somente procedimentos compatíveis com o CBO do profissional, conforme regras do SIGTAP.

2.9.23. Ao lançar manualmente o BPA consolidado, o sistema deve permitir cadastrar somente procedimentos com instrumento de registro consolidado.

2.9.24. Ao lançar manualmente o BPA consolidado, o sistema deve verificar, de acordo com a competência, se o procedimento inserido é um procedimento válido na tabela SIGTAP.

2.9.25. Ao lançar manualmente o BPA consolidado, o sistema deve obrigar o preenchimento da idade, somente para os procedimentos que exigem idade, conforme regras do SIGTAP.

2.9.26. Ao lançar manualmente o BPA consolidado, o sistema deve permitir cadastrar somente procedimentos compatíveis com a idade do paciente.

2.9.27. No BPA consolidado, o sistema deve permitir alterar a produção (lançamento manual e geração automática) dos atendimentos prestados pela unidade de saúde.

2.9.28. O sistema deve permitir excluir os procedimentos consolidados das competências não finalizadas.

2.9.29. No BPA consolidado, o sistema não deve permitir gerar o faturamento, para a unidade e competência, se o arquivo de exportação já foi encaminhado ao SIA.

2.9.30. O sistema deve permitir gerar o BPA individualizado por competência, aproveitando a produção já lançada pela unidade de saúde.

2.9.31. Ao gerar a produção dos procedimentos individualizados, por competência, o sistema deve considerar todos os atendimentos realizados na unidade de saúde, da competência atual e mais três anteriores, que não entraram nos arquivos de exportação do faturamento ao SIA.

2.9.32. Ao gerar a produção dos procedimentos individualizados, o sistema deve apresentar a quantidade de procedimentos gerados, a quantidade de folhas e de erros.

2.9.33. Ao gerar o BPA individualizado, o sistema deve informar se existem procedimentos executados, ainda não faturados, na unidade de saúde.

2.9.34. Ao gerar a produção, o sistema deve apresentar a folha e a quantidade de linhas dos procedimentos individualizados.

2.9.35. O sistema deve permitir consultar a produção, por competência, unidade de saúde e CBO, dos procedimentos individualizados executados nos atendimentos prestados pela unidade de saúde.

2.9.36. Ao consultar a produção dos atendimentos realizados (procedimentos individualizados) pela unidade de saúde, o sistema deve exibir a competência, CNES, nome da unidade, CNS do profissional, CBO e folha.

2.9.37. O sistema deve apresentar, por competência, todos os procedimentos individualizados executados nos atendimentos prestados pela unidade de saúde,

contendo no mínimo: nome do paciente, data do atendimento, procedimento, quantidade de execução do procedimento, CID e caráter de atendimento.

2.9.38. O sistema deve permitir lançar manualmente, por competência, o boletim de produção ambulatorial (BPA) individualizado dos atendimentos prestados pelas unidades de saúde.

2.9.39. Ao lançar manualmente o BPA individualizado, o sistema deve permitir cadastrar no mínimo: CNES, competência, folha, CBO, CNS do profissional, nome do paciente, data de nascimento, CNS, sexo, município, raça/cor, etnia indígena, nacionalidade, data do atendimento, procedimento, quantidade de execução do procedimento, CID e caráter de atendimento.

2.9.40. Ao lançar manualmente o BPA individualizado, o sistema deve permitir cadastrar somente CBO válido.

2.9.41. Ao lançar manualmente o BPA individualizado, o sistema deve permitir informar somente procedimentos compatíveis com o CBO e/ou CID.

2.9.42. Ao lançar manualmente o BPA individualizado, o sistema deve permitir cadastrar somente procedimentos compatíveis com a idade do paciente.

2.9.43. Ao lançar manualmente o BPA individualizado, o sistema deve permitir cadastrar somente procedimentos compatíveis com o sexo do paciente.

2.9.44. Ao lançar manualmente o BPA individualizado, o sistema deve permitir cadastrar somente procedimentos com instrumento de registro individualizado.

2.9.45. Ao lançar manualmente o BPA individualizado, o sistema deve obrigar o preenchimento do CID, somente para os procedimentos que exigem CID, conforme regras do SIGTAP.

2.9.46. Ao lançar manualmente o BPA individualizado, o sistema deve permitir cadastrar, no mesmo atendimento, somente a quantidade de execução do procedimento permitida pelo SIGTAP (quantidade máxima).

2.9.47. Ao lançar manualmente o BPA individualizado, o sistema deve verificar, de acordo com a competência, se o procedimento inserido exige que o CNS do profissional e do paciente estejam preenchidos, conforme regras do SIGTAP (atributo complementar).

2.9.48. Ao lançar manualmente o BPA individualizado, o sistema deve verificar, de acordo com a competência, se o procedimento inserido é um procedimento válido na tabela SIGTAP.

2.9.49. No BPA individualizado, o sistema deve permitir alterar a produção (lançamento manual e geração automática) dos atendimentos prestados pela unidade de saúde.

2.9.50. O sistema deve permitir excluir os procedimentos individualizados das competências não finalizadas.

2.9.51. No BPA individualizado, o sistema não deve permitir gerar o faturamento, para a unidade e competência, se o arquivo de exportação já foi encaminhado ao SIA.

2.9.52. O sistema deve permitir gerar o RAAS, RAS-PSI, por CNES e competência, aproveitando a produção já lançada pela unidade de saúde.

2.9.53. Ao gerar a produção dos procedimentos RAAS (Atenção Psicossocial), por competência, o sistema deve considerar todos os atendimentos realizados na unidade de saúde, da competência atual e mais três anteriores, que não entraram nos arquivos de exportação do faturamento ao SIA.

2.9.54. Ao gerar a produção dos procedimentos RAAS (Atenção Psicossocial), o sistema deve apresentar a quantidade de procedimentos gerados, a quantidade de folhas e de erros.

2.9.55. Ao gerar o RAAS (Atenção Psicossocial), o sistema deve informar se existem procedimentos executados, ainda não faturados, na unidade de saúde.

2.9.56. Ao gerar a produção, o sistema deve apresentar a folha e a quantidade de linhas dos procedimentos RAAS (Atenção Psicossocial).

2.9.57. O sistema deve permitir consultar a produção, por competência, unidade de saúde e CBO, dos procedimentos RAAS (Atenção Psicossocial) executados nos atendimentos prestados pela unidade de saúde.

2.9.58. Ao consultar a produção dos atendimentos realizados (procedimentos RAAS - Atenção Psicossocial) pela unidade de saúde, o sistema deve exibir a competência, CNES, nome da unidade, CNS do profissional, CBO e folha.

2.9.59. O sistema deve apresentar, por competência, todos os procedimentos RAAS (Atenção Psicossocial) executados nos atendimentos prestados pela unidade de saúde, contendo no mínimo: nome do paciente, data do atendimento, procedimento, quantidade de execução do procedimento, CID e caráter de atendimento.

2.9.60. O sistema deve permitir lançar manualmente, por competência, os procedimentos RAAS, RAS-PSI, dos atendimentos prestados pelas unidades de saúde.

2.9.61. Ao lançar manualmente o RAAS (Atenção Psicossocial), o sistema deve permitir cadastrar no mínimo: CNES, competência, folha, CBO, CNS do profissional, nome do paciente, data de nascimento, CNS, sexo, município, raça/cor, etnia indígena, nacionalidade, data do atendimento, procedimento, quantidade de execução do procedimento, CID, caráter de atendimento, autorização, destino do paciente e classificação do serviço.

2.9.62. Ao lançar manualmente o RAAS (Atenção Psicossocial), o sistema deve permitir cadastrar somente CBO válido.

2.9.63. Ao lançar manualmente o RAAS (Atenção Psicossocial), o sistema deve permitir informar somente procedimentos compatíveis com o CBO e/ou CID.

2.9.64. Ao lançar manualmente o RAAS (Atenção Psicossocial), o sistema deve permitir cadastrar somente procedimentos compatíveis com a idade do paciente.

2.9.65. Ao lançar manualmente o RAAS (Atenção Psicossocial), o sistema deve permitir cadastrar somente procedimentos compatíveis com o sexo do paciente.

2.9.66. Ao lançar manualmente o RAAS (RAS-PSI), o sistema deve permitir cadastrar somente procedimentos com instrumento de registro RAAS (Atenção Psicossocial).

2.9.67. Ao lançar manualmente o RAAS (Atenção Psicossocial), o sistema deve obrigar o preenchimento do CID, somente para os procedimentos que exigem CID, conforme regras do SIGTAP.

2.9.68. Ao lançar manualmente o RAAS (Atenção Psicossocial), o sistema deve permitir cadastrar, no mesmo atendimento, somente a quantidade de execução do procedimento permitida pelo SIGTAP (quantidade máxima).

2.9.69. Ao lançar manualmente o RAAS (Atenção Psicossocial), o sistema deve verificar, de acordo com a competência, se o procedimento inserido exige que o CNS do profissional e do paciente estejam preenchidos conforme as regras do SIGTAP (atributo complementar).

2.9.70. Ao lançar manualmente o RAAS (Atenção Psicossocial), o sistema deve verificar, de acordo com a competência, se o procedimento inserido é um procedimento válido na tabela SIGTAP.

2.9.71. O sistema deve permitir excluir os procedimentos RAAS (Atenção Psicossocial) das competências não finalizadas.

2.9.72. No RAAS (Atenção Psicossocial), o sistema não deve permitir gerar o faturamento, para a unidade e competência, se o arquivo de exportação já foi encaminhado ao SIA.

2.9.73. O sistema deve permitir gerar o arquivo de exportação do faturamento, no padrão de layout disponibilizado pelo DATASUS, com todos os procedimentos (RAAS (Atenção Psicossocial)) executados pelas unidades de saúde.

2.9.74. O sistema deve permitir gerar o arquivo de exportação do faturamento (RAAS (Atenção Psicossocial)) por competência, unidade de saúde e financiamento.

2.9.75. Ao gerar o arquivo de exportação do faturamento (RAAS (Atenção Psicossocial)), o sistema deve permitir informar o nome do arquivo a ser gravado.

2.9.76. O sistema deve permitir consultar, por período e unidade de saúde, os arquivos de exportação gerados (RAAS (Atenção Psicossocial)).

2.9.77. Ao consultar os arquivos de exportação gerados (RAAS (Atenção Psicossocial)), o sistema deve exibir a competência, nome da unidade de saúde, financiamento, data e hora de geração do arquivo e arquivo encaminhado (arquivo entregue ou não ao SIA).

2.9.78. O sistema deve permitir download do arquivo de exportação do faturamento (RAAS (Atenção Psicossocial)), para ser encaminhado ao SIA.

2.9.79. O sistema deve gerar relatório de controle de remessa dos arquivos de exportação gerados (RAAS (Atenção Psicossocial)), contendo no mínimo: competência, nome da unidade de saúde, nome do arquivo gerado e quantidade de registros gravados.

2.9.80. O sistema deve permitir o faturamento retroativo, de três meses, dos atendimentos prestados (procedimentos executados RAAS (Atenção Psicossocial)), conforme regras do Sistema de Informação Ambulatorial (SIA/SUS).

2.9.81. O sistema deve permitir cadastrar unidades do tipo "primária" ou "secundária".

2.9.82. O sistema deve permitir vincular unidades do tipo "secundárias" às unidades do tipo "primárias".

2.9.83. O sistema deve permitir excluir as unidades do tipo "primárias".

2.9.84. O sistema deve permitir desvincular as unidades do tipo "secundárias" das unidades do tipo "primárias".

2.9.85. O sistema deve gerar relatório de BPA Consolidado, contendo no mínimo: número, procedimento, CBO, idade, quantidade, folha e consistência.

2.9.86. O sistema deve gerar relatório de BPA Individualizado, contendo no mínimo: folha, número sequencial, nome do usuário, data, código procedimento, quantidade, CID, CBO e consistência.

2.9.87. O sistema deve gerar relatório financeiro BPA, contendo no mínimo: procedimento, descrição, quantidade, valor unitário e valor total.

2.9.88. O sistema deve gerar relatório de BPA por CBO, contendo no mínimo: número, CBO, procedimento e quantidade.

2.9.89. O sistema deve gerar relatório de RASS PSI, contendo no mínimo: nome do usuário, data, número de autorização, procedimento, quantidade, CID, CBO e consistência.

2.10. Módulo Atenção Básica

2.10.1. O sistema deve permitir realizar o cadastro individual do cidadão (e-SUS AB), contendo no mínimo: responsável pelo cadastro, unidade do profissional, código da equipe (INE), área, microárea, CBO, data do cadastro, nome completo do cidadão, nome social, data de nascimento, sexo, raça/cor, etnia, nome completo da mãe, nome completo do pai, nacionalidade, país de nascimento, município e UF de nascimento, número do cadastro nacional de saúde (cartão SUS), unidade/área/micro área do cidadão e permitir informar se o cidadão é o responsável familiar.

2.10.2. O sistema deve permitir cadastrar informações sociodemográficas no cadastro individual do cidadão, contendo no mínimo: relação de parentesco com o

responsável familiar, ocupação, frequenta escola, curso mais elevado que frequenta ou frequentou, situação no mercado de trabalho, se possui crianças de 0 a 9 anos e com quem ficam, se frequenta cuidador tradicional, se participa de algum grupo comunitário, se possui plano de saúde privado, se é membro de comunidade tradicional, se deseja informar a orientação sexual, se deseja informar identidade de gênero, se tem alguma deficiência (auditiva, intelectual/cognitiva, visual, física, outra), saída do cidadão do cadastro (mudança de território ou óbito e a data) e permitir informar se o usuário recusou o cadastro por meio do termo de recusa do cadastro individual.

2.10.3. Ao realizar o cadastro individual do cidadão (e-SUS AB), o sistema deve permitir informar os problemas e condições de saúde dos usuários no território das equipes de AB, contendo no mínimo: se é gestante, DUM, nome da maternidade de referência, situação do peso, se é fumante, se faz uso de álcool, se usa drogas, se tem hipertensão arterial, se tem diabetes, se teve AVC/derrame, se teve infarto, se tem doença cardíaca e quais, se tem doenças respiratórias e quais, se está com hanseníase, se está com tuberculose, se tem ou teve câncer, se tem ou teve problemas nos rins e quais, se teve alguma internação nos últimos 12 meses e motivo, se fez ou faz tratamento com psiquiatra ou teve internação por problema de saúde mental, se está acamado, se está domiciliado, se usa plantas medicinais e quais, se usa práticas integrativas e complementares.

2.10.4. Ao realizar o cadastro individual do cidadão (e-SUS AB), o sistema deve permitir informar se o cidadão está em situação de rua, contendo no mínimo: tempo em situação de rua, se é acompanhado por outras instituições e quais, se recebe algum benefício, se possui referência familiar, se visita algum familiar com frequência e qual o grau de parentesco, quantas vezes se alimenta ao dia, qual a origem da alimentação e se tem acesso à higiene pessoal e quais.

2.10.5. O sistema deve gerar o termo de recusa da atenção básica quando o cidadão se recusar a fornecer os dados para preenchimento do cadastro individual.

2.10.6. O sistema deve permitir impressão do termo de recusa da atenção básica quando o cidadão se recusar a fornecer os dados para preenchimento do cadastro individual.

2.10.7. O sistema deve gerar a ficha de cadastro individual da atenção básica (e-SUS AB).

2.10.8. O sistema deve permitir impressão da ficha de cadastro individual da atenção básica (e-SUS AB).

2.10.9. O sistema deve permitir cadastrar o atendimento individual (e-SUS AB), contendo no mínimo: nome do paciente, cartão SUS, data de nascimento, nome e CBO do profissional que realizou o atendimento, unidade de saúde, área, microárea, código da equipe (INE), data do atendimento, turno, local de atendimento, tipo de atendimento, peso do paciente, altura, perímetro cefálico, se está com a vacinação em dia e aleitamento materno.

2.10.10. Ao realizar o atendimento individual, o sistema deve permitir cadastrar as informações da gestante (DUM, gravidez planejada, idade gestacional, gestações prévias, partos), risco da família (escala de coelho), modalidade do atendimento domiciliar, condição avaliada, doenças transmissíveis, rastreamento, CIAP2 (Classificação Internacional da Atenção Primária 2ª ed.), CID10, exames avaliados, exames solicitados, PIC, se ficou em observação, triagem neonatal, NASF/Polo, conduta, encaminhamento e procedimentos realizados.

2.10.11. Ao realizar o atendimento individual (e-SUS AB), o sistema deve permitir consultar o paciente por nome, prontuário, CNS e data de nascimento.

2.10.12. No atendimento individual da atenção básica, o sistema deve permitir visualizar o histórico dos atendimentos realizados para o paciente.

2.10.13. O sistema deve permitir excluir o atendimento individual somente se a ficha não tiver sido exportada para o e-SUS AB.

2.10.14. O sistema deve permitir cadastrar a ficha de Procedimentos e-SUS AB, contendo no mínimo: nome e CBO do profissional que realizou o atendimento, unidade de saúde, data do atendimento, nome do paciente, prontuário, cartão SUS, data de nascimento, área e microárea do paciente, local de atendimento, turno, código da equipe (INE), área e microárea do profissional, se teve escuta inicial/orientação e os procedimentos realizados (procedimentos/pequenas cirurgias, testes rápidos, administração de medicamentos, medição de peso, medição de altura, aferição de PA, glicemia, aferição de temperatura, coleta de material para exame laboratorial e outros procedimentos SIGTAP).

2.10.15. Ao cadastrar a ficha de Procedimentos e-SUS AB, o sistema deve permitir informar o código da equipe (INE), área e microárea do profissional e os procedimentos consolidados realizados (aferição de PA, aferição de temperatura, curativo simples, coleta de material para exame laboratorial, glicemia capilar, medição de altura e medição de peso) de acordo com a ficha do profissional.

2.10.16. O sistema deve permitir consultar as fichas de procedimentos do profissional (e- SUS AB) por data do atendimento, unidade de saúde e nome do profissional.

2.10.17. O sistema deve permitir excluir as fichas de procedimentos do profissional somente se a ficha (arquivo) não tiver sido exportada para o e-SUS AB.

2.10.18. O sistema deve exibir os atendimentos registrados para os pacientes (procedimentos realizados), contendo no mínimo: nome do paciente, cartão SUS e data de nascimento.

2.10.19. Ao realizar a visita domiciliar (e-SUS AB), o sistema deve permitir consultar o paciente por nome, prontuário, CNS e data de nascimento.

2.10.20. O sistema deve permitir cadastrar as visitas domiciliares (e-SUS AB), contendo no mínimo: nome do paciente, cartão SUS, data de nascimento, área e microárea do paciente, nome e CBO do profissional que realizou o atendimento, unidade de saúde, código da equipe, área, microárea, data do atendimento, turno, tipo do imóvel, se a visita foi acompanhada por outro profissional, motivos da visita (tipo de visita (cadastro/atualização, visita periódica) busca ativa, controle ambiental, acompanhamento), antropometria (peso, altura) e desfecho da visita.

2.10.21. O sistema deve permitir visualizar o histórico das visitas domiciliares realizadas para o paciente.

2.10.22. O sistema deve permitir excluir a visita domiciliar somente se a ficha não tiver sido exportada para o e-SUS AB.

2.10.23. Ao realizar a visita domiciliar, o sistema deve permitir visualizar a família (residentes), contendo no mínimo: logradouro (tipo de logradouro, logradouro, número, complemento, bairro e cidade) e os residentes (nome do cidadão, CNS, prontuário, data de nascimento e nome da mãe).

2.10.24. O sistema deve permitir cadastrar visita territorial (locais sem residentes).

2.10.25. Ao realizar o atendimento odontológico (e-SUS AB), o sistema deve permitir consultar o paciente por nome, prontuário, CNS e data de nascimento.

2.10.26. O sistema deve permitir cadastrar o atendimento odontológico (e-SUS AB), contendo no mínimo: nome do paciente, nome social, cartão SUS, data de nascimento, nome e CBO do profissional que realizou o atendimento, unidade de saúde, área, microárea, código da equipe, data do atendimento, turno, local de atendimento, tipo de atendimento, tipo de consulta, se o paciente possui

necessidades especiais, se é gestante, vigilância em saúde bucal, procedimentos realizados, fornecimento de produtos de higiene bucal (escova dental, creme dental, fio dental), conduta e encaminhamento.

2.10.27. No atendimento odontológico da atenção básica, o sistema deve permitir visualizar o histórico dos atendimentos realizados para o paciente.

2.10.28. O sistema deve permitir alterar os dados do atendimento odontológico somente se a ficha não tiver sido exportada para o e-SUS AB.

2.10.29. O sistema deve permitir registrar a atividade coletiva (e-SUS AB), contendo no mínimo: data da atividade, PSE (Programa Saúde na Escola), código INEP da escola/creche, local de atividade, CNES, turno, nome e CBO do profissional responsável pela atividade coletiva, unidade do profissional, código da equipe (INE), área, microárea, atividade (reunião de equipe, reunião com outras equipes de saúde, reunião intersetorial/conselho local de saúde/controle social, educação em saúde, atendimento em grupo, avaliação/procedimento coletivo e mobilização social), número de participantes e número de avaliações alteradas.

2.10.30. O sistema deve permitir cadastrar as atividades reunião de equipe, reunião com outras equipes de saúde e reunião intersetorial/conselho local de saúde/controle social, informando os temas para reunião (questões administrativas/funcionamento, processos de trabalho, diagnóstico do território/monitoramento do território, planejamento/monitoramento das ações da equipe, discussão de caso/projeto terapêutico singular e/ou educação permanente).

2.10.31. Ao registrar a atividade coletiva (e-SUS AB), o sistema deve permitir informar o público-alvo, os temas para saúde e as práticas em saúde de acordo com a atividade (ação) realizada.

2.10.32. Ao registrar a atividade coletiva (e-SUS AB), o sistema deve permitir cadastrar as pessoas avaliadas, contendo no mínimo: nome do cidadão, avaliação alterada, peso, altura, Programa Nacional de Controle do Tabagismo informando se o cidadão cessou o hábito de fumar e/ou abandonou o grupo.

2.10.33. O sistema deve permitir visualizar as pessoas avaliadas (atividade coletiva e-SUS AB), contendo no mínimo: nome do cidadão, nome social, cartão SUS, avaliação alterada (sim ou não), peso, altura, Programa Nacional de Controle do Tabagismo informando se o cidadão cessou o hábito de fumar e/ou abandonou o grupo e os procedimentos realizados.

2.10.34. O sistema deve gerar a ficha de atividade coletiva da atenção básica (e-SUS AB).

2.10.35. O sistema deve permitir impressão da ficha de atividade coletiva da atenção básica (e-SUS AB).

2.10.36. O sistema deve permitir consultar as atividades realizadas (atividade coletiva e- SUS AB) por data da atividade e nome do profissional responsável.

2.10.37. O sistema deve permitir parametrizar, por município, as áreas de abrangência das unidades básicas de saúde (UBSs), as microáreas (subdivisão da área), os códigos das equipes (INE) de atenção básica responsáveis pelo território (território-área e território-microárea) e os tipos de equipe (ESF, NASF e AD).

2.10.38. O sistema deve permitir parametrizar a área de abrangência de uma unidade básica de saúde, contendo no mínimo: nome da unidade, código da equipe (INE - código Identificador Nacional de Equipes), área e microárea.

2.10.39. O sistema deve permitir vincular os profissionais às equipes de atenção básica (INE) que atuarão em território definido e prestarão um conjunto de ações de saúde, em âmbito individual e coletivo, relacionadas com a promoção, prevenção, diagnóstico e tratamento, provendo atenção integral.

2.10.40. O sistema deve permitir excluir o profissional da equipe de atenção básica somente se ele não tiver atendimentos registrados.

2.10.41. Se existir atendimento realizado pelo profissional na equipe de atenção básica (INE), o sistema deve permitir somente inativar ou ativar o profissional na equipe.

2.10.42. O sistema deve permitir parametrizar se os procedimentos (alguns pré-definidos) realizados na atenção básica (e-SUS AB) deverão ser faturados e exportados para o sistema do governo SIASUS.

2.10.43. O sistema deve permitir parametrizar os CBOs que poderão realizar atendimentos na atenção básica (e-SUS AB).

2.10.44. O sistema deve permitir cadastrar supervisores para gerenciar e autorizar determinadas operações realizadas na atenção básica (e-SUS AB).

2.10.45. O sistema deve permitir gerar o arquivo de exportação do faturamento da atenção básica, no padrão de layout disponibilizado pelo e-SUS AB, com todas as informações das fichas de CDS (Coleta de Dados Simplificada).

2.10.46. O sistema deve permitir exportação dos dados das fichas de CDS (atenção básica) para os sistemas do governo: e-SUS AB, BPA Magnético, SIASUS e SISAB.

2.10.47. O sistema deve permitir consultar as fichas de atendimento domiciliar do profissional por data do atendimento, nome do profissional e unidade de saúde.

2.10.48. O sistema deve permitir cadastrar o atendimento domiciliar (serviços de atenção domiciliar - SAD), contendo no mínimo: nome e CBO do profissional que realizou o atendimento, unidade de saúde, código da equipe, área, microárea, data do atendimento, nome do profissional auxiliar no atendimento, nome do paciente, nome social, CNS, data de nascimento, área e microárea do paciente, local de atendimento, tipo de atendimento, modalidade, turno que foi realizado o atendimento, condições avaliadas, procedimentos realizados, conduta/motivo de saída do SAD e início de acompanhamento pós-óbito.

2.10.49. O sistema deve permitir visualizar os atendimentos realizados pelo profissional (atendimento domiciliar) por nome do paciente, CNS e data de nascimento.

2.10.50. O sistema deve permitir visualizar o histórico de atendimento domiciliar dos pacientes.

2.10.51. O sistema deve permitir excluir o atendimento domiciliar do paciente somente se a ficha não tiver sido exportada para o e-SUS AB.

2.10.52. O sistema deve permitir cadastrar os marcadores de consumo alimentar (e-SUS AB), contendo no mínimo: nome do paciente, cartão SUS, data de nascimento, área e microárea do paciente, nome e CBO do profissional, unidade de saúde, código da equipe, área, microárea, data do atendimento e local de atendimento.

2.10.53. O sistema deve permitir registrar os marcadores de consumo alimentar de acordo com a idade do paciente: menor de 6 meses (se a criança tomou leite materno no dia anterior, se a criança consumiu (mingau, água/chá, leite de vaca, fórmula infantil, suco de fruta, fruta, comida com sal e/ou outros alimentos/bebidas) no dia anterior).

2.10.54. O sistema deve permitir registrar os marcadores de consumo alimentar de acordo com a idade do paciente: de 6 a 23 meses (se a criança tomou leite materno, se a criança comeu fruta inteira, em pedaços ou amassada no dia anterior, se a criança comeu comida com sal no dia anterior e como essa comida foi oferecida (em pedaços, amassada, passada na peneira, liquidificada ou só o caldo), se a criança consumiu no dia anterior (outro leite sem ser o materno, mingau com leite, iogurte, legumes, vegetal ou fruta de cor alaranjada ou folhas verdes escuras, verdura de folha, carne, fígado, feijão, arroz, batata, inhame, aipim/macaxeira/mandioca, farinha ou macarrão, hambúrguer e/ou embutidos,

bebidas adoçadas, macarrão instantâneo, salgadinhos de pacote ou biscoitos salgados, biscoito recheado, doces ou guloseimas)).

2.10.55. O sistema deve permitir registrar os marcadores de consumo alimentar de acordo com a idade do paciente: acima de 2 anos (se o paciente tem o costume de comer assistindo TV, mexendo no computador/celular, quais refeições faz durante o dia (café da manhã, lanche da manhã, almoço, lanche da tarde, jantar, ceia), alimentos consumidos no dia anterior (feijão, frutas frescas, verduras e/ou legumes, hambúrguer e/ou embutidos, bebidas adoçadas, macarrão instantâneo, salgadinhos de pacote ou biscoitos salgados, biscoito recheado, doces ou guloseimas)).

2.10.56. O sistema deve permitir visualizar o histórico dos marcadores de consumo alimentar registrados para o paciente.

2.10.57. Ao registrar os marcadores de consumo alimentar (e-SUS AB), o sistema deve permitir consultar o paciente por nome, prontuário, CNS e data de nascimento.

2.10.58. O sistema deve permitir alterar os marcadores de consumo alimentar registrados somente se a ficha não tiver sido exportada para o e-SUS AB.

2.10.59. O sistema deve permitir cadastrar a Avaliação de Elegibilidade e Admissão (e-SUS AB) para o SAD (Serviços de Atenção Domiciliar), contendo no mínimo: nome do paciente, nome social, cartão SUS, data de nascimento, área e microárea do paciente, nome e CBO do profissional que realizou a avaliação (atendimento), unidade do profissional, código da equipe (INE), área, microárea, turno, data da avaliação, procedência, condições avaliadas, CID, conclusão e cuidador.

2.10.60. O sistema deve permitir visualizar o histórico das avaliações de elegibilidade e admissão (e-SUS AB) realizadas para o paciente, contendo no mínimo: data da avaliação e profissional que realizou o atendimento (nome, CNS e unidade).

2.10.61. Ao realizar a Avaliação de Elegibilidade e Admissão (e-SUS AB), o sistema deve permitir consultar o paciente por nome, prontuário, CNS e data de nascimento.

2.10.62. O sistema deve gerar a ficha de Avaliação de Elegibilidade e Admissão da atenção básica (e-SUS AB).

2.10.63. O sistema deve permitir impressão da ficha de Avaliação de Elegibilidade e Admissão da atenção básica (e-SUS AB).

2.10.64. O sistema deve permitir alterar os dados da Avaliação de Elegibilidade e Admissão registrada para o paciente somente se a ficha (arquivo) não tiver sido exportada para o e-SUS AB.

2.10.65. O sistema deve gerar relatório dos atendimentos realizados (Atendimento Individual e/ou Odontológico e-SUS AB) por unidade, contendo no mínimo: nome da unidade, data do atendimento, tipo de atendimento, nome do paciente, prontuário, nome do profissional que realizou o atendimento, área e microárea do paciente, local de atendimento, tipo de atendimento, conduta, encaminhamento, exames solicitados, total de atendimentos por unidade e total geral de atendimentos de todas as unidades.

2.10.66. O sistema deve gerar relatório que apresente as visitas domiciliares por unidade, contendo no mínimo: data da visita, nome do paciente, número do prontuário, nome do profissional que realizou a visita, desfecho, área e microárea do paciente e total de visitas realizadas no período.

2.10.67. O sistema deve gerar relatório dos atendimentos realizados (e-SUS AB) por unidade, contendo no mínimo: data do atendimento, nome do paciente, prontuário, data de nascimento, idade completa, sexo, nome do profissional, hipertenso, diabético, gestante, aleitamento materno, local do atendimento, condição avaliada, vacina em dia, total de pacientes e total de atendimentos.

2.10.68. O sistema deve gerar relatório que apresente os pacientes cadastrados na atenção básica por unidade, contendo no mínimo: nome do paciente, prontuário, data de nascimento, idade completa, sexo, área e microárea do paciente, nome do usuário responsável pelo cadastro e condicionalidades (hipertenso, diabético, gestante, hanseníase, tuberculose, peso, fumante, álcool, drogas, AVC/derrame, infarto, câncer, internação, doença cardíaca, doença renal, doença respiratória, tratamento psiquiátrico, acamado, domiciliado, plantas medicinais e práticas integrativas e complementares).

2.10.69. O sistema deve gerar relatório que apresente as visitas por domicílio de acordo com a unidade, contendo no mínimo: data da visita, nome do responsável familiar, número do prontuário, área e microárea do domicílio, nome do profissional que realizou a visita, logradouro (tipo, descrição do logradouro, número e complemento), quantidade de residentes, total de domicílios visitados, total de visitas e total de usuários atendidos.

2.10.70. O sistema deve gerar relatório consolidado dos atendimentos realizados (e-SUS AB) por unidade, contendo no mínimo: número de pessoas no território da equipe, número de pessoas de 15 ou mais anos, número de mulheres de 10 a 59 anos, número de gestantes, número de crianças menores de 02 anos acompanhadas, número de crianças menores de 01 ano acompanhadas, número de crianças menores de 06 meses acompanhadas, número de crianças menores de 04 meses acompanhadas, número de hipertensos, número de diabéticos, número de gestantes como pré-natal no mês, número de gestantes acompanhadas por meio de visitas domiciliares, número de crianças menores de 06 meses com aleitamento materno exclusivo, número de crianças menores de 04 meses com aleitamento materno exclusivo, número de crianças menores de 01 ano com vacina em dia e número de crianças menores de 02 anos pesadas.

2.10.71. O sistema deve gerar relatório que apresente as famílias cadastradas (e-SUS AB), contendo no mínimo: endereço, área e microárea, nome dos residentes, prontuário, data de nascimento, idade completa, sexo, renda, relação de parentesco com o responsável familiar, responsável pelo cadastro, condições/situações de saúde (fumante, hipertensão arterial, diabetes, gestante, hanseníase e/ou tuberculose), total de pessoas na família, total por condicionalidades na família (fumante, hipertensão arterial, diabetes, gestante, hanseníase e tuberculose), renda familiar e renda média familiar.

2.10.72. O sistema deve gerar relatório que apresente os dados que não foram exportados para o e-SUS AB e os motivos (inconsistências), contendo no mínimo: data do atendimento, tipo de ficha, identificação do paciente (nome e prontuário), nome do profissional e descrição dos erros.

2.10.73. O sistema deve gerar relatório que apresente as atividades coletivas realizadas (e-SUS AB), contendo no mínimo: data da atividade, atividade, tema, nome do profissional responsável pela atividade coletiva, local de atividade, nomes dos outros profissionais, total de participantes, pessoas avaliadas e total de atividades.

2.10.74. O sistema deve permitir cadastrar a ficha complementar (e-SUS AB - Registro de Emergência em Saúde Pública Síndrome Neurológica por Zika/Microcefalia), contendo no mínimo: nome e CBO do profissional que realizou o atendimento, unidade de saúde, código da equipe, área, microárea, data do atendimento, turno, nome do paciente, cartão SUS e data de nascimento.

2.10.75. O sistema deve permitir registrar os resultados de exames (ficha complementar e-SUS AB), contendo no mínimo: Teste do olhinho (Reflexo vermelho: data de realização e resultado (presente bilateral, duvidoso ou ausente)), Exame de fundo

de olho (data de realização e resultado (normal, alterado)), Teste da orelhinha – PEATE (data de realização e resultado (passou, falhou)), US Transfontanela (data de realização e resultado (normal, sugestivo de infecção congênita, outras alterações, indeterminado)), Tomografia computadorizada (data de realização e resultado (normal, sugestivo de infecção congênita, outras alterações, indeterminado)) e Ressonância magnética (data de realização e resultado (normal, sugestivo de infecção congênita, outras alterações, indeterminado)).

2.10.76. Ao registrar a ficha complementar (e-SUS AB), o sistema deve permitir consultar o paciente por nome, CNS, prontuário e data de nascimento.

2.10.77. O sistema deve permitir visualizar o histórico dos atendimentos realizados para o paciente (ficha complementar e-SUS AB).

2.10.78. O sistema deve permitir alterar os dados da Ficha Complementar registrada para o paciente somente se a ficha (arquivo) não tiver sido exportada para o e-SUS AB.

2.10.79. O sistema deve gerar relatório quantitativo de produção dos atendimentos realizados na atenção básica, contendo no mínimo: código do procedimento, CBO e quantidade.

2.10.80. Ao realizar o cadastro domiciliar e territorial (e-SUS AB), o sistema deve permitir registrar o endereço, contendo no mínimo: tipo de logradouro, logradouro, bairro, CEP, número, loteamento, complemento, município e UF.

2.10.81. Ao realizar o cadastro domiciliar e territorial, o sistema deve permitir registrar as condições de moradia, contendo no mínimo: área/microárea do domicílio, FA (fora de área), tipo do imóvel, situação, localização, tipo de domicílio, quantidade de moradores, quantidade de cômodos, situação rural, tipo de acesso ao domicílio, material predominante (paredes externas), disponibilidade de energia elétrica, tipo de abastecimento de água, tipo de tratamento de água, destino do lixo, forma de escoamento sanitário, se tem animais no domicílio (quantidade e tipo de animais), higiene residencial e permitir informar se o usuário recusou o cadastro por meio do termo de recusa do cadastro domiciliar e territorial.

2.10.82. Ao realizar o cadastro domiciliar e territorial, o sistema deve permitir informar o responsável pelo cadastro, unidade do profissional, CBO, código da equipe (INE), área, microárea e data do cadastro.

2.10.83. Ao realizar o cadastro domiciliar e territorial, o sistema deve permitir visualizar a família (residentes), contendo no mínimo: nome do cidadão, nome social, prontuário, data de nascimento, relação de parentesco com o responsável familiar e renda familiar.

2.10.84. O sistema deve gerar a ficha de cadastro domiciliar e territorial da atenção básica (e-SUS AB).

2.10.85. O sistema deve permitir impressão da ficha de cadastro domiciliar e territorial da atenção básica (e-SUS AB).

2.10.86. O sistema deve permitir consultar o endereço (logradouro estruturado) para realizar o cadastro domiciliar e territorial da atenção básica.

2.10.87. O sistema deve gerar relatório quantitativo que apresente os tipos de atendimento realizados (Atendimento Individual, Atendimento Domiciliar e Atendimento Odontológico e-SUS AB), contendo no mínimo: tipos de atendimento, outros tipos de atendimento e locais de atendimento.

2.10.88. O sistema deve gerar relatório que apresente o total de procedimentos realizados (e-SUS AB) no período, contendo no mínimo: procedimentos consolidados, administração de medicamentos, procedimentos/pequenas cirurgias, fornecimento e saúde bucal.

2.10.89. O sistema deve gerar relatório quantitativo dos atendimentos realizados (Atendimento Individual e-SUS AB), contendo no mínimo: descrição do exame, quantidade solicitada e quantidade avaliada.

2.10.90. O sistema deve gerar relatório quantitativo dos atendimentos realizados (e-SUS AB), contendo no mínimo: conduta/desfecho, desfecho da visita domiciliar, encaminhamentos e encaminhamentos especializados.

2.10.91. O sistema deve gerar relatório quantitativo dos atendimentos realizados na atenção básica (Atendimento Odontológico, Atendimento Domiciliar, Visita Domiciliar e Atividade Coletiva), contendo no mínimo: vigilância em saúde bucal, atenção domiciliar, busca ativa, atividades, outras atividades, temas nas ações de reuniões, temas para saúde e práticas em saúde.

2.10.92. O sistema deve gerar relatório consolidado que apresente os cadastros realizados na atenção básica (e-SUS AB), contendo no mínimo: resumo do cadastro (cadastrados e recusados: número de usuários, número de domicílios e número de famílias), situação de rua, pessoas com deficiência, situação sociodemográfica, localização do domicílio, tipo de tratamento de água, disponibilidade de energia elétrica e destino do lixo.

2.10.93. O sistema deve gerar relatório de gestantes e puérperas, contendo no mínimo: nome, DUM, idade gestacional, data do último atendimento, vacina em dia, sorologia de sífilis (VDRL) solicitada e avaliada, data da última consulta odontológica e data da última visita ACS.

2.10.94. O sistema deve gerar relatório dos atendimentos realizados (e-SUS AB) a crianças com idade igual ou menor de 5 anos, contendo no mínimo: nome da criança, teste pezinho, teste orelhinha, teste olhinho, última consulta odontológica, última visita domiciliar ACS, último atendimento individual, aleitamento materno, vacina em dia, perímetro cefálico, peso e altura.

2.10.95. O sistema deve gerar relatório que apresente os pacientes com risco cardiovascular, contendo no mínimo: nome do paciente, hipertensão, diabetes, fumante, data da última consulta odontológica e data da última visita ACS.

2.10.96. O sistema deve gerar relatório mensal que apresente as visitas realizadas por domicílio, contendo no mínimo: área e microárea do domicílio, nome do profissional que realizou a visita, nome do logradouro, número, complemento, bairro, nome do responsável familiar, total de residentes, total de atendimentos e total de visitas realizadas.

2.10.97. O sistema deve permitir consultar a quantidade de procedimentos realizados dentro de um período determinado, discriminado por unidade, atendimento, CBO, profissional e procedimento, contendo no mínimo: unidade, código do procedimento, descrição do procedimento e quantidade.

2.10.98. O sistema deve gerar relatório de atendimentos odontológicos, contendo no mínimo: 1ª consulta odontológica programática, escovação dental supervisionada, tratamento concluído, urgência, atendimento a gestante e instalações de próteses dentárias.

2.10.99. O sistema deve gerar relatório de acompanhamento contendo no mínimo: motivo da visita, tipos de acompanhamento, doenças transmissíveis, rastreamento, condições avaliadas e problemas mais frequentes.

2.10.100. O sistema deve gerar relatório de serviços ofertados pela equipe de atenção básica referente a indicador de monitoramento definido pelo PMAQ, que exiba o quantitativo de ações e serviços realizados pelas unidades e condizentes às fichas de atendimento individual, atividade coletiva e de procedimentos, contendo no mínimo (por unidade e somatório de todas as unidades selecionadas): total

quantitativo mensal, somatório quantitativo dos meses selecionados, média mensal, somatório das médias dos meses selecionados, percentual mensal e somatório percentual dos meses do período selecionado. As ações e serviços a serem contabilizados são: administração de medicamentos endovenoso, administração de medicamentos via intramuscular, administração de medicamentos via oral, administração de penicilina para tratamento de sífilis, aferição de pressão arterial, atendimento de urgência em atenção básica, atendimento individual em domicílio, atividade coletiva - educação em saúde, atividade coletiva - avaliação/ procedimento coletivo, avaliação antropométrica, coleta de material p/ exame citopatológico de colo uterino, coleta de material p/ exame laboratorial, consulta médica em atenção básica, curativo especial, curativo simples, drenagem de abscesso, exame do pé diabético, glicemia capilar, nebulização/inalação, retirada de cerume, retirada de corpo estranho da cavidade auditiva e nasal, retirada de corpo estranho subcutâneo, retirada de pontos de cirurgias básicas (por paciente), sutura simples, tamponamento nasal anterior e/ou posterior, terapia de reidratação oral, teste do pezinho, triagem oftalmológica.

2.10.101. O sistema deve gerar relatório com o percentual, média e quantidade mensal de encaminhamentos à especialistas pertencentes às equipes de Estratégia Saúde da Família – ESF, contendo no mínimo: unidade, equipe/área/microárea, especialista, sexo, serviço, meses e total do período

2.10.102. O sistema deve gerar relatório de serviços ofertados pela equipe de saúde bucal referente a indicador de monitoramento definido pelo PMAQ, que exiba o quantitativo de ações e serviços realizados pelas unidades e condizentes às fichas de atividade coletiva e de atendimento odontológico, contendo no mínimo (por unidade e somatório de todas as unidades selecionadas): total quantitativo mensal, somatório quantitativo dos meses selecionados, média mensal, somatório das médias dos meses selecionados, percentual mensal e somatório percentual dos meses do período selecionado. As ações e serviços a serem contabilizados são: ação coletiva de aplicação tópica de flúor gel, ação coletiva de escovação dental supervisionada, ação coletiva de exame bucal com finalidade epidemiológica, acesso à polpa dentaria e medicação (por dente), assistência domiciliar por equipe multiprofissional, atendimento a gestante, atendimento de urgência, avaliação dos itens de vigilância em saúde bucal, consulta agendada, consulta de conclusão do tratamento em odontologia, curativo de demora c/ ou s/ preparo biomecânico, exodontia de dente decíduo, exodontia de dente permanente, orientação de higiene bucal, primeira consulta odontológica programática, profilaxia/ remoção de placa bacteriana, pulpotomia dentária, raspagem alisamento e polimento supragengivais (por sextante), raspagem alisamento subgengivais (por sextante), restauração de dente decíduo, restauração de dente permanente anterior, restauração de dente permanente posterior, selamento provisório de cavidade dentária, tratamento de alveolite, ulotomia/ulectomia.

2.10.103. O sistema deve gerar relatório de tratamentos odontológicos que exiba os tratamentos concluídos e as primeiras consultas realizadas nas unidades, contendo no mínimo (por unidade e somatório de todas as unidades selecionadas): quantitativo mensal de primeiras consultas, somatório quantitativo de primeiras consultas dos meses selecionados, quantitativo mensal de tratamentos concluídos, somatório quantitativo de tratamentos concluídos dos meses selecionados, média

mensal, somatório das médias dos meses selecionados, percentual mensal e somatório percentual dos meses do período selecionado.

2.10.104. O sistema deve gerar relatório de cobertura de primeira consulta odontológica dos atendimentos condizentes como primeira consulta odontológica programática, contendo no mínimo (por unidade e somatório de todas as unidades selecionadas): total quantitativo mensal, somatório quantitativo dos meses selecionados, média mensal, somatório das médias dos meses selecionados, percentual mensal, somatório percentual dos meses selecionados, quantidade mensal de cadastros e somatório dos cadastros dos meses selecionados.

2.10.105. O sistema deve gerar relatório com o percentual, média e quantidade mensal dos índices de atendimentos por condição avaliada, discriminado por diabetes, hipertensão arterial e obesidade, contendo no mínimo: unidade, equipe/área/microárea, CBO, especialista, serviço, meses e total do período.

2.10.106. O sistema deve gerar relatório de exames citopatológico, contendo no mínimo (por unidade e somatório de todas as unidades selecionadas): total quantitativo mensal, somatório quantitativo dos meses selecionados, média mensal, somatório das médias dos meses selecionados, percentual mensal, somatório percentual dos meses selecionados, quantidade mensal de cadastros e somatório dos cadastros dos meses selecionados.

2.10.107. O sistema deve gerar relatório de produtividade por tipo de atendimento, separado por unidade, contendo no mínimo: número do registro, nome do profissional, total de atendimentos, percentual de atendimentos.

2.10.108. O sistema deve gerar relatório de atendimento por consulta, condizentes aos atendimentos realizados (por unidade, profissional e somatório de todas as unidades selecionadas), contendo no mínimo: total quantitativo mensal, somatório quantitativo dos meses selecionados, média mensal, somatório das médias dos meses selecionados, percentual mensal, somatório percentual dos meses selecionados.

2.10.109. O sistema deve gerar relatório médio de atendimento de especialistas separados por unidade, equipe/área/microárea e especialista, contendo no mínimo (por unidade e somatório de todas as unidades selecionadas): total quantitativo mensal, somatório quantitativo dos meses selecionados, média mensal, somatório das médias dos meses selecionados, percentual mensal e somatório percentual dos meses do período selecionado.

2.10.110. O sistema deve gerar relatório com o percentual, a média e o total mensal de atendimentos do núcleo de apoio à saúde da família – NASF, de acordo com o período escolhido, contendo no mínimo: unidade, equipe/área/microárea, especialista, tipo de atendimento, serviço, meses e total do período.

2.10.111. O sistema deve gerar relatório de atendimentos a recém-nascidos, contendo no mínimo: total do período, total mensal, média e percentual de atendimentos em relação a quantidade de recém-nascidos cadastrados.

2.11. Módulo Controle Logístico dos Medicamentos, Materiais de Enfermagem e Odontológicos

2.11.1. Deve permitir o controle logístico dos medicamentos, materiais de enfermagem, materiais odontológicos, materiais de consumo, materiais de limpeza, bem como o gerenciamento on-line do estoque e de requisições;

2.11.2. Deve permitir cadastrar os grupos a serem gerenciados contendo no mínimo: código do grupo, descrição do grupo, tipo do grupo, unidade responsável por grupo;

2.11.3. Deve permitir alterar os grupos cadastrados;

2.11.4. Deve permitir cadastrar os produtos contendo no mínimo: descrição do produto, código do produto, unidade de medida, grupo, controle de lote, estoque mínimo e máximo, tipo de estoque, ativo ou inativo;

2.11.5. Deve permitir cadastrar fornecedores contendo no mínimo: nome fantasia, razão social, CNPJ, Inscrição Estadual, site, endereço, telefones, tipo de fornecedor;

2.11.6. Deve permitir cadastrar os contatos em cada fornecedor contendo no mínimo: nome do contato, departamento, cargo, telefone, celular, e-mail;

2.11.7. Deve permitir consultar a relação de fornecedores por tipo de fornecedor;

2.11.8. Deve permitir visualizar histórico de cada produto contendo todo histórico de compras e de saídas, contendo no mínimo: data de entrada, fornecedor, lote, validade, quantidade de entrada, quantidade disponível por lote, valor unitário, valor total por lote, data de saída, unidade requisitante, usuário requisitante, setor requisitante, quantidade de saída;

2.11.9. Deve permitir visualizar o estoque total por produto e por lote,

2.11.10. Deve permitir o controle de estoque descentralizado, possibilitando criar vários almoxarifados na rede municipal de saúde;

2.11.11. Deve permitir o controle de estoque por centro de custo;

2.11.12. Deve permitir cadastrar entrada de materiais contendo no mínimo: unidade, fornecedor, data da entrada, nome do operador, código do pedido de compras, número da nota fiscal, data da nota fiscal, produto, quantidade, lote, valor unitário, valor total por lote, valor total da nota;

2.11.13. Deve permitir registrar vários produtos em uma mesma entrada;

2.11.14. Deve permitir registrar entrada de materiais por doação;

2.11.15. Deve permitir estornar entradas registradas erroneamente;

2.11.16. Deve permitir alterar entradas realizadas;

2.11.17. Deve gerar listagem de produtos para inventário contendo no mínimo: grupo de produtos, unidade, código de produto, descrição do produto, unidade de medida, código do grupo, descrição do grupo, quantidade;

2.11.18. Deve permitir registrar a quantidade do inventário e automaticamente o sistema deve realizar as correções de estoque;

2.11.19. Deve permitir registrar o estoque inicial;

2.11.20. Deve permitir cadastrar as saídas de materiais contendo no mínimo: nome do almoxarifado, nome do operador, unidade requisitante, usuário requisitante, setor requisitante, código da requisição, data da requisição, produto, quantidade;

2.11.21. Deve permitir realizar a saída de vários materiais em uma única requisição;

2.11.22. Deve permitir realizar saída somente dos materiais sob a responsabilidade da unidade que está realizando a operação;

2.11.23. Não deve permitir realizar a saída de materiais que não possuem estoque disponível;

2.11.24. Deve permitir visualizar por material todos os lotes com estoque disponível;

2.11.25. Deve permitir visualizar por produto quais lotes estão saindo;

2.11.26. Deve automaticamente sair com os lotes que vencem primeiro;

2.11.27. Deve registrar o valor da saída considerando o valor real do material;

2.11.28. Deve imprimir comprovante de saída, contendo no mínimo: código da requisição, unidade solicitante, endereço da unidade solicitante, grupo do material, descrição do material, lote, quantidade, campo para o usuário assinar o recebimento dos materiais, campo para preencher a data do recebimento dos materiais;

2.11.29. Deve permitir o controle de estoque físico e financeiro;

2.11.30. Deve permitir estornar saídas registradas erroneamente;

2.11.31. Deve permitir cadastrar baixas de materiais vencidos, quebrados e interditados;

2.11.32. Deve permitir cadastrar transferências de materiais entre almoxarifados e municípios;

2.11.33. Deve permitir cadastrar fechamentos de balancetes;

2.11.34. Não deve permitir movimentação de estoque nos meses fechados (já contabilizados);

2.11.35. Deve permitir o cadastro de requisição online contendo no mínimo: unidade requisitante, nome do operador, nome do almoxarifado, grupo de material, descrição do material, quantidade por material;

2.11.36. Deve permitir cadastrar quais materiais cada unidade pode solicitar;

2.11.37. Deve disponibilizar para cada unidade somente a relação dos materiais liberadas para unidade solicitante;

2.11.38. Deve permitir que as unidades acompanhem o status da requisição contendo no mínimo: data da solicitação, data de envio dos materiais requisitados, almoxarifado requisitado, usuário solicitante, código da requisição, material, quantidade solicitada, quantidade enviada, quantidade recebida, lote, validade do lote;

2.11.39. Deve permitir que a unidade requisitante confirme o recebimento e registre a quantidade recebida por material;

2.11.40. Deve permitir que o Almoxarifado visualize e gerencie em uma única tela todas as requisições online contendo no mínimo: data do pedido, unidade requisitante, usuário requisitante, código de da requisição, material solicitado, quantidade requisitada, quantidade disponível no almoxarifado, quantidade enviada;

2.11.41. Deve permitir visualizar a quantidade em estoque do material solicitado na unidade requisitante, e as últimas remessas do material à unidade solicitante;

2.11.42. Deve permitir cadastrar justificativa do não envio da quantidade ou do material solicitado;

2.11.43. Deve permitir o controle de requisição por status com no mínimo: pendente, em andamento, retornado, finalizado;

2.11.44. Deve permitir o cadastro de contratos contendo no mínimo: período do contrato, número do contrato, fornecedor, modalidade de contratação, valor total do contrato, número de parcelas;

2.11.45. Deve permitir o gerenciamento das entregas dos contratos, possibilitando cadastrar informações de cada produto entregue, número da nota fiscal, quantidade entregue, saldo e quantidade pendente;

2.11.46. Deve gerar relatório de Balancete contendo no mínimo: período, grupo de material, código do grupo, material, unidade de medida, saldo anterior físico e financeiro por material, entradas no período físico e financeiro por material, saídas no período físico e financeiro por material, saldo atual físico e financeiro por material, saldo anterior financeiro total, entrada financeira total, saída financeira total, saldo atual financeiro total;

2.11.47. Deve gerar relatório resumo de balancete contendo no mínimo: período, grupos, saldo financeiro anterior por grupo de material, entradas financeiras por grupo de material, saídas financeiras por grupo de material, saldo atual financeiro por grupo de material, saldo financeiro anterior total, entrada financeira total, saída financeira total, saldo financeiro atual;

2.11.48. Deve gerar relatório de Baixa de Estoque contendo no mínimo: período, unidade, grupo de material, motivo da baixa, data da baixa, operador que realizou a baixa, quantidade de materiais baixados;

2.11.49. Deve gerar relatório de consumo médio diário contendo no mínimo: período, unidade, setor, grupo de material, material, unidade de medida, total consumido por dia, média do consumido por dia, saldo atual;

2.11.50. Deve gerar relatório de consumo médio mensal contendo no mínimo: período, unidade, setor, grupo de material, material, unidade de medida, total consumido por mês, média do consumido por mês, saldo atual;

2.11.51. Deve gerar relatório de entrada de materiais contendo no mínimo: período, grupo de material, material, fornecedor, data do documento, data do lançamento, número do pedido, unidade de medida, quantidade, valor unitário, valor total por material, valor total geral;

2.11.52. Deve gerar relatório de estorno de entrada de material contendo no mínimo: período, fornecedor, material, data do estorno, data do documento, número do documento, operador que realizou o estorno, quantidade estornada;

2.11.53. Deve gerar relatório de estorno de saída de material contendo no mínimo: período, requisitante, material, data do estorno, data da saída, número da requisição, operador que realizou a saída, operador que realizou o estorno, quantidade estornada;

2.11.54. Deve gerar relatório de posição de estoque por material contendo no mínimo: unidade, grupo de material, material, unidade de medida, estoque mínimo, estoque máximo, estoque disponível, status (abaixo do mínimo, acima do máximo, normal, zerado);

2.11.55. Deve gerar relatório de produtos a vencer contendo no mínimo: período, unidade, grupo de material, material, lote, validade do lote, tempo restante, quantidade em estoque por material;

2.11.56. Deve gerar relatório de saída por unidade contendo no mínimo: período, almoxarifado, tipo da saída (requisição ou baixa), motivo da baixa, unidade requisitante, grupo de material, material, data da saída, usuário requisitante, quantidade por material, número da requisição, quantidade total de baixas, quantidade total de consumo;

2.11.57. Deve gerar relatório de entrada por fornecedor contendo no mínimo: período, fornecedor, material, unidade de medida, data do documento, número do lote, validade do lote, quantidade, valor por produto, valor total de entradas;

2.11.58. Deve gerar relatório de saída de material contendo no mínimo: período, unidade requisitante, setor requisitante, usuário requisitante, grupo de materiais, material, unidade de medida, data da saída, data da requisição, quantidade de saída por material, quantidade de saída total.

2.12. Módulo Controle da Farmácia

2.12.1. O sistema deve cadastrar processos envolvendo medicamentos de alto custo.

2.12.2. O sistema deve permitir gerenciar os processos de medicamentos de alto custo cadastrados.

2.12.3. O sistema deve permitir consultar informações pertinentes ao processo (identificar quais medicamentos de alto custo serão retirados para o paciente, bem como a data de envio e entrega do medicamento).

2.12.4. O sistema deve permitir que os processos sejam visualizados por todas as unidades.

2.12.5. O sistema deve permitir alteração/exclusão do processo somente pela unidade que cadastrou o processo.

2.12.6. Ao acessar a funcionalidade, o sistema deve verificar a permissão do usuário logado.

2.12.7. O sistema deve buscar o médico solicitante pelo nome ou pelo CRM.

2.12.8. O sistema deve apresentar listagem e impressão de processos cadastrados para o paciente, contendo no mínimo: nome do paciente, CPF, CNS, tipo de processo, medicamento, quantidade e observação.

2.12.9. O sistema deve permitir consulta e impressão de processos cadastrados para o paciente, contendo no mínimo: nome do paciente, prontuário, prontuário alto custo, data de início (primeira retirada do medicamento, independente do processo), medicamento, retiradas (todas as retiradas do medicamento, independente do processo).

2.12.10. O sistema deve gerar relatório de dispensação dos medicamentos de alto custo retirados no gerenciamento de processos, contendo no mínimo: data, unidade, paciente, médico, medicamento, quantidade, total de pacientes e total de medicamentos dispensados.

2.12.11. O sistema deve registrar as saídas de medicamentos no estoque da farmácia.

2.12.12. Ao realizar a baixa do medicamento, o sistema deve permitir informar o motivo da baixa.

2.12.13. O sistema deve registrar log de todas as baixas realizadas.

2.12.14. O sistema deve registrar o supervisor no banco de dados somente se o motivo da baixa exigir senha do supervisor.

2.12.15. O sistema deve permitir consultar o estoque atual do medicamento.

2.12.16. O sistema deve apresentar todos os motivos de baixa cadastrados que estiverem ativos.

2.12.17. Após realizar a baixa, o sistema deve atualizar o saldo do medicamento no banco de dados.

2.12.18. Ao solicitar autorização de supervisor, o sistema deve realizar autenticação do usuário supervisor.

2.12.19. Ao registrar a baixa, o sistema deve gravar as informações da baixa na tabela referente ao sistema Hórus somente se o motivo da baixa foi indicado como validade vencida ou perda no cadastro de motivos de baixa.

2.12.20. O sistema deve permitir cadastrar/alterar os motivos de baixa, indicar se o motivo deverá ser enviado ao sistema Hórus e determinar se o motivo exigirá senha de supervisor.

2.12.21. O sistema deve permitir inativar ou ativar o motivo da baixa.

2.12.22. O sistema deve permitir excluir o motivo da baixa somente se o motivo não possuir nenhum registro de baixa.

2.12.23. O sistema não deve permitir duplicidade de motivo de baixa.

2.12.24. O sistema deve permitir cadastrar pacientes que tenham processos relacionados à dispensação de medicamentos.

2.12.25. O sistema deve permitir consultar pacientes que tenham processos cadastrados relacionados à dispensação de medicamentos.

2.12.26. O sistema deve permitir alterar processos cadastrados para os pacientes relacionados à dispensação de medicamentos.

2.12.27. O sistema deve permitir inativar ou ativar processos cadastrados relacionados à dispensação de medicamentos.

2.12.28. O sistema deve realizar cadastro de supervisores para autorizar determinadas operações na Farmácia.

2.12.29. O sistema deve permitir excluir o supervisor cadastrado.

2.12.30. O sistema deve permitir consultar o estoque atual do medicamento de todas as unidades que tiverem o medicamento cadastrado.

2.12.31. O sistema deve permitir consultar medicamentos para realizar o estorno de baixa.

2.12.32. O sistema deve permitir realizar o estorno de baixa dos medicamentos.

2.12.33. O sistema deve permitir consultar pacientes para realizar o estorno de dispensação dos medicamentos.

2.12.34. O sistema deve permitir realizar o estorno de dispensação dos medicamentos.

2.12.35. O sistema deve permitir consultar medicamentos para realizar o estorno de entrada.

2.12.36. O sistema deve realizar estorno de entrada dos medicamentos.

2.12.37. O sistema deve gravar log de estorno de entrada no banco de dados.

2.12.38. O sistema deve controlar os medicamentos que entram na farmácia.

2.12.39. O sistema deve permitir consultar os medicamentos cadastrados na farmácia.

2.12.40. O sistema deve apresentar produtos/medicamentos cadastrados no almoxarifado.

2.12.41. O sistema deve permitir cadastrar nomenclatura (nome referência) para os medicamentos na farmácia.

2.12.42. O sistema deve permitir relacionar os produtos/medicamentos cadastrados no almoxarifado com os medicamentos cadastrados na farmácia.

2.12.43. O sistema deve permitir desfazer o vínculo dos produtos/medicamentos do almoxarifado relacionados com os medicamentos da farmácia.

2.12.44. O sistema deve permitir exclusão dos medicamentos cadastrados na farmácia (nome referência).

2.12.45. O sistema deve permitir bloquear ou desbloquear os medicamentos cadastrados na farmácia.

2.12.46. O sistema deve permitir alterar a nomenclatura (nome referência) dos medicamentos cadastrados na farmácia.

2.12.47. O sistema deve permitir realizar entradas de estoque na farmácia somente se os produtos da farmácia tiverem como referência os produtos do almoxarifado.

2.12.48. O sistema deve permitir consultar as entradas realizadas no estoque da farmácia.

2.12.49. O sistema deve registrar log do usuário que realizar a alteração da nomenclatura (nome referência) dos medicamentos cadastrados na farmácia.

2.12.50. O sistema deve permitir consultar e imprimir a posição de estoque dos medicamentos cadastrados na farmácia.

2.12.51. O sistema deve apresentar somente os medicamentos cadastrados na unidade do usuário que estiver logado.

2.12.52. O sistema deve permitir consultar e imprimir a posição de estoque dos medicamentos cadastrados na farmácia.

2.12.53. O sistema deve apresentar somente os medicamentos cadastrados de acordo com a unidade escolhida pelo usuário.

2.12.54. O sistema deve gerar relatório dos medicamentos que foram dispensados para os pacientes do SUS, bem como o endereço da residência de cada paciente, contendo no mínimo: data, nome, prontuário, RG, endereço, medicamento e quantidade.

2.12.55. O sistema deve gerar relatório dos medicamentos que foram dados baixa por algum motivo na farmácia, contendo no mínimo: unidade, usuário, medicamento, quantidade e motivo.

2.12.56. O sistema deve gerar relatório das dispensações realizadas diariamente e/ou em um determinado período, contendo no mínimo: data, paciente, prontuário, unidade e tipo.

2.12.57. O sistema deve gerar relatório que apresente o valor financeiro das dispensações de medicamentos realizadas para os pacientes, contendo no mínimo: nome paciente, prontuário, data, medicamento, quantidade, valor unitário, valor total, subtotal e total.

2.12.58. O sistema deve gerar relatório que apresente o consumo médio mensal das dispensações de medicamentos realizadas, contendo no mínimo: grupo, medicamento, meses de consumo (apenas se escolher cálculo = específico), média, total, saldo atual e total (geral).

2.12.59. O sistema deve gerar relatório das dispensações realizadas e permitir consultar um medicamento específico de acordo com a unidade escolhida pelo usuário, contendo no mínimo: unidade, médico, medicamento, quantidade, paciente e total (total de medicamentos dispensados).

2.12.60. O sistema deve gerar relatório das dispensações que foram realizadas somente para os medicamentos cadastrados no grupo de produtos “antibióticos” e deve permitir também consultar um medicamento específico de acordo com a unidade escolhida pelo usuário, contendo no mínimo: data, tipo, histórico, quantidade, estoque e saldo anterior.

2.12.61. O sistema deve gerar relatório que apresente os medicamentos que foram dispensados para os pacientes do SUS, contendo no mínimo: paciente, prontuário, data (data - horário da dispensação), operador, unidade, médico, medicamento, quantidade, validade, origem da receita, total atendimentos (por paciente e geral), total de medicamentos (por paciente e geral) e total de pacientes.

2.12.62. O sistema deve gerar relatório que apresente as entradas de estoque realizadas na farmácia de acordo com a unidade escolhida pelo usuário, contendo no mínimo: data, operador, medicamento, lote, validade e quantidade.

2.12.63. O sistema deve gerar relatório que apresente os envios realizados ao sistema Hórus com retorno igual a “Sucesso” (registros consistentes recebidos pelo Hórus), contendo no mínimo: entrada, saídas por perda, saídas por vencimento, dispensações e quantidade dispensada.

2.12.64. O sistema deve gerar relatório que apresente os estornos de dispensação de medicamentos realizados para os pacientes, contendo no mínimo: data saída, data estorno, medicamento, paciente, usuário que dispensou, usuário que estornou e quantidade.

2.12.65. O sistema deve gerar relatório que apresente os pacientes do SUS que fazem uso de medicação contínua para tratamento de hipertensão e/ou diabetes, indicando quanto da medicação é consumida por dia, auxiliando a farmácia a planejar a compra desses medicamentos (qual medicamento e quantidade). O relatório deve conter no mínimo: medicamento, paciente, prontuário, comprimidos/unidades por dia, total pacientes, total/dia, total pacientes (geral) e total/dia (geral).

2.12.66. O sistema deve gerar relatório que apresente os medicamentos que estão por vencer de acordo com o período definido pelo usuário, contendo no mínimo: grupo, produto, lote, validade, quantidade a vencer, quantidade em estoque e tempo restante.

2.12.67. O sistema deve gerar relatório que apresente a quantidade de pacientes que solicitaram medicamentos (dispensação) em um determinado período, contendo no mínimo: nome paciente, prontuário, data, unidade, medicamento, grupo, quantidade, total de dispensações e total de pacientes atendidos.

2.12.68. O sistema deve gerar relatório de processos com as dispensações realizadas para os pacientes que possuem processos de medicamentos cadastrados, contendo no mínimo: nome paciente, prontuário, processo, tipo de processo, data e medicamento.

2.12.69. O sistema deve gerar relatório que mostre, em um determinado período, os medicamentos que têm data prevista para os pacientes do SUS retirarem,

contendo no mínimo: data de próxima retirada, nome do paciente, medicamento, quantidade de medicamento e total (total de medicamentos).

2.12.70. O sistema deve gerar relatório que apresente todos os tipos de saídas de medicamentos realizadas na farmácia (dispensação, baixa e/ou transferência), contendo no mínimo: data, unidade, médico, usuário/baixa, medicamento, quantidade e total (total de medicamentos que foram dispensados/dados baixa/transferidos).

2.12.71. O sistema deve gerar relatório que apresente a quantidade de medicamentos dispensados na farmácia, contendo no mínimo: medicamento, quantidade dispensada e total.

2.12.72. O sistema deve permitir realizar a transferência de medicamentos entre unidades.

2.12.73. O sistema deve permitir transferência de medicamentos somente com estoque maior que 0 (zero).

2.12.74. O sistema deve permitir incluir e excluir medicamentos antes de realizar a transferência.

2.12.75. O sistema deve apresentar lista com todos os medicamentos que serão transferidos.

2.12.76. O sistema deve apresentar tela de impressão com as saídas de material/medicamento.

2.12.77. O sistema deve gerar relatório que apresente as transferências de medicamentos entre unidades, contendo no mínimo: data, medicamento, unidade de destino e quantidade transferida.

2.12.78. O sistema deve permitir consultar os medicamentos que irão vencer.

2.12.79. O sistema deve permitir imprimir os medicamentos que irão vencer.

2.12.80. O sistema deve permitir consultar pacientes para realizar a dispensação de medicamentos.

2.12.81. O sistema deve verificar se existem pacientes com cadastro bloqueado e informar o usuário do sistema. Os pacientes bloqueados devem ser diferenciados dos demais pacientes.

2.12.82. O sistema não deve permitir dispensação de medicamentos para pacientes bloqueados.

2.12.83. O sistema deve permitir consultar as receitas pendentes de dispensação.

2.12.84. O sistema deve permitir excluir as receitas pendentes de dispensação.

2.12.85. O sistema deve permitir incluir e excluir medicamentos antes de realizar a dispensação.

2.12.86. O sistema deve registrar as saídas de medicamentos para os pacientes.

2.12.87. O sistema deve permitir dispensar medicamentos a partir das receitas pendentes.

2.12.88. O sistema deve permitir consultar os medicamentos dispensados anteriormente para o paciente.

2.12.89. O sistema deve verificar se o medicamento pode ser dispensado com estoque igual a 0 (zero) ou não.

2.12.90. Quando o usuário do sistema for excluir uma receita pendente de dispensação, o sistema deve permitir cadastrar o motivo da exclusão.

2.12.91. O sistema deve indicar os medicamentos que foram estornados após a dispensação.

2.12.92. O sistema deve permitir imprimir recibo de medicamentos para o paciente.

2.12.93. O sistema deve permitir reimprimir recibo de medicamentos para o paciente.

2.12.94. O sistema deve permitir alterar dados dos medicamentos incluídos na dispensação.

2.12.95. O sistema deve permitir consultar o paciente por nome, número do prontuário e data de nascimento para registrar a dispensação do aparelho de insulina.

2.12.96. O sistema deve permitir cadastrar a marca do aparelho de insulina.

2.12.97. O sistema deve permitir registrar as dispensações de aparelhos de insulina para os pacientes do SUS.

2.12.98. O sistema deve permitir indicar na dispensação se o aparelho de insulina é novo ou usado.

2.12.99. O sistema deve permitir excluir a dispensação do aparelho de insulina realizada.

2.12.100. O sistema deve permitir consultar as dispensações de aparelhos de insulina que foram realizadas para o paciente.

2.12.101. O sistema deve permitir consultar o paciente SUS para realizar o cadastro de hipertensão e/ou diabetes.

2.12.102. O sistema deve permitir cadastrar se o paciente SUS é hipertenso e/ou diabético.

2.12.103. O sistema deve permitir alterar as doenças concomitantes cadastradas para o paciente SUS.

2.12.104. O sistema deve permitir cadastrar os medicamentos contínuos que o paciente faz uso para tratamento da hipertensão e/ou diabetes.

2.12.105. O sistema deve permitir excluir o medicamento contínuo cadastrado para o paciente.

2.12.106. O sistema deve permitir consultar os pacientes cadastrados com hipertensão e/ou diabetes.

2.12.107. O sistema deve permitir excluir o cadastro do paciente hipertenso e/ou diabético.

2.12.108. O sistema deve permitir cadastrar e alterar as credenciais de acesso ao sistema Hórus para envio das informações de movimentação de entrada e saída de medicamentos da farmácia.

2.12.109. O sistema deve gerar relatório das baixas realizadas na farmácia, contendo no mínimo: nome do medicamento e quantidade da baixa.

2.12.110. O sistema deve gerar relatório das movimentações realizadas na farmácia e deve indicar se a movimentação foi enviada ou não ao sistema Hórus, contendo no mínimo: data, medicamento, quantidade, tipo de movimentação e status.

2.12.111. O sistema deve apresentar somente as movimentações da farmácia referentes à unidade do usuário autenticado.

2.12.112. O sistema deve permitir consultar o medicamento para realizar a baixa no estoque da farmácia.

2.12.113. O sistema deve apresentar somente os medicamentos que possuem lote.

2.12.114. Ao realizar a baixa do medicamento, o sistema deve permitir informar o motivo da baixa.

2.12.115. O sistema deve permitir consultar o saldo atual do medicamento.

2.12.116. O sistema deve registrar a saída do medicamento no estoque da farmácia.

2.12.117. Após realizar a baixa, o sistema deve atualizar o saldo do medicamento no estoque da farmácia.

2.12.118. O sistema deve permitir consultar os lotes do medicamento antes de realizar a baixa e deve apresentar o fornecedor, lote, validade, quantidade e quantidade da baixa informada.

2.12.119. O sistema deve gerar relatório que apresente os pacientes que retiraram medicamentos na farmácia, contendo no mínimo: data, nome do paciente, número do prontuário, data de nascimento, número do cartão nacional de saúde (CNS), observação e total de pacientes.

2.12.120. O sistema deve permitir cadastrar livro para gerenciar a saída dos medicamentos controlados (psicotrópicos) da farmácia, contendo no mínimo: número do livro,

data de abertura, nome do livro, tipo de livro, quantidade de páginas, nome do farmacêutico e autoridade sanitária.

2.12.121. O sistema deve permitir consultar os livros cadastrados por nome, tipo de livro e status (aberto ou fechado).

2.12.122. O sistema deve permitir atualizar o livro de medicamentos controlados com as movimentações realizadas na farmácia.

2.12.123. O sistema deve informar se houve alguma movimentação ou não no livro cadastrado de medicamentos controlados.

2.12.124. O sistema deve permitir consultar o histórico de movimentação (entrada, saída e/ou baixa) do medicamento controlado por nome do medicamento e tipo de movimentação.

2.12.125. O sistema deve apresentar o histórico de movimentação do medicamento controlado, contendo no mínimo: data de movimentação, quantidade (entrada, saída e/ou baixa) e saldo atual do medicamento na farmácia.

2.12.126. O sistema deve permitir fechar o livro de medicamentos controlados cadastrado.

2.12.127. O sistema deve permitir imprimir parcialmente o histórico de movimentação dos medicamentos controlados.

2.12.128. O sistema deve permitir cadastrar livro para gerenciar a saída do medicamento talidomida da farmácia, contendo no mínimo: número do livro, data de abertura, nome do livro, tipo de livro, quantidade de páginas, nome do farmacêutico e autoridade sanitária.

2.12.129. O sistema deve permitir consultar os livros cadastrados do medicamento talidomida por nome, tipo de livro e status (aberto ou fechado).

2.12.130. O sistema deve permitir atualizar o livro do medicamento talidomida com as movimentações realizadas na farmácia.

2.12.131. O sistema deve informar se houve alguma movimentação ou não no livro cadastrado do medicamento talidomida.

2.12.132. O sistema deve permitir consultar o histórico do medicamento talidomida por tipo de movimentação (entrada, saída e/ou baixa).

2.12.133. O sistema deve apresentar o histórico de movimentação do medicamento talidomida na farmácia.

2.12.134. O sistema deve permitir fechar o livro do medicamento talidomida cadastrado.

2.12.135. O sistema deve permitir imprimir o histórico de movimentação do medicamento talidomida.

2.12.136. O sistema deve gerar relatório que apresente a movimentação (entrada, saída e/ou transferência) dos medicamentos cadastrados na farmácia, contendo no mínimo: nome do medicamento, saldo anterior, entrada, saída, transferido e saldo atual.

2.12.137. Caso haja dispensação pendente para o paciente, dentro da validade da receita e o usuário queira dispensar os mesmos medicamentos, o sistema deve exigir senha de supervisor para salvar a dispensação no sistema.

2.12.138. O sistema deve permitir buscar medicamentos cadastrados na farmácia

2.12.139. O sistema deve permitir cadastrar número do documento, fabricante e fornecedor para entradas antigas realizadas diretamente no módulo farmácia.

2.12.140. O sistema deve gerar relatório de movimentação geral de medicamentos, contendo no mínimo: nome do medicamento, grupo, saldo inicial, entradas, dispensado, baixa, outras saídas e saldo final.

2.12.141. O sistema deve gerar relatório detalhado de movimentação contendo no mínimo: data, tipo, origem/destino, medicamento, quantidade movimentada e saldo.

2.12.142. O sistema deve gerar relatório de dispensação de psicotrópicos, contendo no mínimo: saldo anterior, data, tipo, histórico, quantidade e estoque.

2.12.143. O sistema deve gerar relatório de dispensação de psicotrópicos que apresente um determinado medicamento, contendo no mínimo: saldo anterior, data, tipo, histórico, quantidade e estoque.

2.12.144. O sistema deve permitir gerar relatório de estoque unificado de medicamentos, contendo no mínimo: Medicamento e Quantidade.

2.12.145. O sistema deve permitir vincular uma unidade a um usuário do sistema.

2.12.146. O sistema deve permitir alterar vínculo entre unidade e usuário do sistema.

2.12.147. O sistema deve permitir excluir vínculo entre unidade e usuário do sistema.

2.12.148. O sistema deve permitir consultar o histórico de dispensações migrado de sistema utilizado anteriormente, contendo no mínimo: nome do paciente, data de nascimento, prontuário.

2.12.149. O sistema deve permitir imprimir o histórico de dispensações de um determinado paciente, contendo no mínimo: nome do paciente, data de nascimento, prontuário, unidade, usuário do sistema, medicamento, data de saída, número do lote, data de validade e quantidade.

2.12.150. O sistema deve permitir consultar os erros geradas no envio do Web Service BNDASAF.

2.12.151. O sistema deve permitir reenviar ao Web Service BNDASAF os registros inconsistentes após a correção. O envio poderá ser realizado individualmente ou de acordo com a seleção do usuário.

2.13. Módulo Controle das Viagens dos Pacientes SUS

2.13.1. Deve permitir cadastrar os grupos de viagem;

2.13.2. Deve permitir cadastrar motivos de viagem contendo no mínimo: nome do grupo de viagem, nome do motivo da viagem, código do procedimento vinculado à tabela SIGTAP;

2.13.3. Deve permitir alterar e excluir os motivos de viagem cadastrados erroneamente;

2.13.4. Deve permitir cadastrar os destinos de viagem contendo no mínimo: nome do destino / prestador, CNPJ do prestador, endereço do prestador, telefone do prestador;

2.13.5. Deve permitir cadastrar os pontos de partida contendo no mínimo: descrição do ponto e bairro;

2.13.6. Deve permitir cadastrar os veículos contendo no mínimo: número da placa, marca, modelo, capacidade, ano de fabricação, tipo do veículo (passeio, passageiro, carga), cor, tipo de combustível, RENAVAM, número de eixos, número do chassi, nome do proprietário do veículo, CNPJ do proprietário do veículo;

2.13.7. Deve permitir cadastrar as jornadas dos veículos possibilitando definir a quantidade de viagem que cada veículo poderá executar no dia contendo no mínimo: dias da semana, período da jornada, horário de saída da jornada e horário de retorno da jornada, status da jornada;

2.13.8. Deve permitir cadastrar motoristas contendo no mínimo: nome do motorista vinculado ao módulo de recursos humanos, data da inclusão, número da CNH, data da primeira habilitação, data do vencimento da CNH, categoria da CNH;

2.13.9. Deve permitir cadastrar supervisores que terão privilégios para agendar pacientes acima da capacidade do veículo;

2.13.10. Deve permitir agendar o transporte com no mínimo: nome do paciente, data de nascimento, idade, número do prontuário, endereço, motivo de viagem, data agendada no prestador/destino, horário agendado no prestador/destino, município

de destino, nome do prestador previamente cadastrado e vinculado ao município, número de acompanhantes, ponto de partida, data da saída da viagem, horário de saída da viagem, veículo, jornada vinculada ao veículo;

2.13.11. Deve permitir o registro de pacientes com atenção especial, como cadeirantes, macas e acamados, possibilitando a identificação e destinação ao veículo adequado;

2.13.12. Deve gerar comprovante de agendamento do transporte contendo no mínimo: nome e endereço da unidade que registrou o agendamento, nome do paciente agendado, nome do destino, data da viagem, motivo da viagem, ponto de partida, quantidade de acompanhantes, data e horário da saída do veículo, e mensagem de observação/orientação;

2.13.13. Deve permitir reimprimir o comprovante de agendamento;

2.13.14. Deve permitir que os agendamentos sejam realizados de forma descentralizada evitando que o paciente se desloque ao departamento de transporte;

2.13.15. Deve possuir funcionalidades para gerenciar os veículos de acordo com a quantidade de pacientes a serem transportados contendo no mínimo: identificação da data da viagem, identificação dos municípios com viagens agendadas, identificação dos destinos por município, relação dos pacientes (nome do paciente, idade, prestador destino, município destino, descrição do ponto de partida, horário da partida e observações especiais), seleção dos veículos disponíveis e com a capacidade disponível;

2.13.16. Xxxx bloquear ao tentar agendar pacientes acima da capacidade do veículo;

2.13.17. Deve permitir agendar pacientes acima da capacidade com a liberação de senha de supervisor;

2.13.18. Deve gerar listagem dos transportes agendados contendo no mínimo: data da viagem, veículo, jornada, motorista, relação dos pacientes, nome do paciente, endereço do paciente, telefone do paciente, motivo da viagem, horário da saída, hora do atendimento no destino/prestador, número de acompanhantes, informações de atendimentos especiais (cadeirantes, maca, acamado), ponto de partida;

2.13.19. Deve permitir a impressão das listagens dos transportes agendados contendo as informações necessárias para o motorista, em relação aos dados dos pacientes e do destino;

2.13.20. Deve permitir o registro da distância percorrida registrando o KM inicial e o KM Final, por veículo e por viagem;

2.13.21. Deve permitir o registro de horários da viagem registrando o horário de partida, o horário de chegada ao destino, o horário de saída do destino, e horário de chegada da viagem;

2.13.22. Deve permitir o registro de despesas de viagem contendo no mínimo: despesa com refeição, despesa hospedagem, despesa com combustível, despesa com pedágios, outras despesas;

2.13.23. Deve permitir registrar o fechamento da viagem informando se os pacientes foram transportados ou não, além de registrar todas as despesas da viagem e os horários percorridos;

2.13.24. O sistema deverá permitir o reagendamento de datas de viagem;

2.13.25. Deve permitir alterar o agendamento da viagem contendo no mínimo: nome do paciente, data de nascimento, data da viagem agendada, horário da viagem agendada, município de destino, local de destino, motivo da viagem, status da viagem, ponto de partida, número de acompanhantes,

2.13.26. Deve permitir o cancelamento de agendamento de viagens, data da viagem, horário da viagem, veículo, jornada;

2.13.27. Deve permitir transferir todos os pacientes a serem transportados de um veículo para outro;

2.13.28. Deve permitir o pré-cadastramento de pacientes que possuam viagens / tratamentos contínuos facilitando o agendamento do transporte para esses pacientes;

2.13.29. Deve gerar relatório de atendimento contendo no mínimo: veículo, cidade de destino, local de destino, motivo da viagem, nome do paciente, número do prontuário, data da viagem, hora da viagem, motivo da viagem;

2.13.30. Deve gerar relatório de viagens por motorista contendo no mínimo: motorista, quantidade de viagens por destino e por mês, quantidade total por mês;

2.13.31. Deve gerar relatório quantitativo de viagem contendo no mínimo: período, veículo, cidade destino, local de destino, motivo de viagem, data da viagem, quantidade de pacientes transportados, quantidade de pacientes transportados por data e por destino, quantidade de acompanhantes transportados por data e por destino, quantidade total de pacientes transportados no período, quantidade total de acompanhantes transportados no período;

2.13.32. O módulo transporte deverá trabalhar integrado com o módulo de regulação.

2.14. Módulo Business Intelligence

2.14.1. Ferramenta para auxílio na Tomada de decisões, utilizando BI (Bussiness Intelligence) para acesso e cruzamento de informações do Banco de Dados de forma amigável.

2.14.2. Deve ter apresentação do software integral em português;

2.14.3. Deve possuir interface de operação 100% WEB

2.14.4. Acessibilidade (Permitir ser acessado via Web podendo o usuário acessar os principais navegadores gratuitos (Firefox e Google Chrome);

2.14.5. Deve exportar os dados em xls, cvs e PDF, com ou sem filtros aplicados;

2.14.6. Análise dinâmica das informações com cliques do mouse;

2.14.7. DrillDrown, DrillUp para navegação em em profundidade nas informações;

2.14.8. Possibilidade de combinação de vários filtros em uma consulta;

2.14.9. Ordenação automática e filtro dos dados das colunas da tabela pelo usuário;

2.14.10. Funcionamento em tablet e smartphones;

2.14.11. Controle de segurança para atribuição de privilégios de usuários por item de menu;

2.14.12. Capacidade de impressão dos gráficos visíveis pelo usuário;

2.14.13. Capacidade de impressão de relatório com ou sem a utilização de filtros;

2.14.14. Permitir que seja gerado arquivo PDF total ou parcial;

2.14.15. Permitir que seja gerado arquivo PPTX total ou parcial;

2.14.16. Permitir acesso aos diversos dashboards da solução, através de estrutura de Menus;

2.14.17. Perfil de acesso de usuários por item de menu da aplicação;

2.14.18. Todos os visuais devem suportar serem exibidos como tabelas;

2.14.19. Todos os visuais devem permitir a ordenação em ordem crescente e decrescente;

2.14.20. Deve ser possível gerenciar permissões;

2.14.21. Deve ser possível imprimir páginas;

2.14.22. Deve ser possível alterar configurações de exibição;

2.14.23. Permitir que os usuários tenham acesso aos dados da saúde de forma gerencial;