PROCESSO DE LICITAÇÃO Nº 22/2022/FMS EDITAL PE Nº 04/2022/FMS CONTRATO Nº 08/2023/FMS

ESTADO DE SANTA CATARINA

MUNICÍPIO DE JOAÇABA

PROCESSO DE LICITAÇÃO Nº 22/2022/FMS EDITAL PE Nº 04/2022/FMS

CONTRATO Nº 08/2023/FMS

TERMO DE CONTRATO DE PRESTAÇÃO DE

SERVIÇOS, que entre si celebram o Município de Joaçaba (SC), por intermédio da SECRETARIA MUNICIPAL DE SAÚDE, e a empresa RANG TECNOLOGIA E DESENVOLVIMENTO DE

SISTEMAS LTDA de acordo com o Capítulo III da Lei 8.666/93 e alterações, e as cláusulas e condições seguintes.

O FUNDO MUNICIPAL DE SAÚDE, com sede na Xxxxxxx XX xx Xxxxxxxx, xx 000, inscrito no CNPJ/MF sob o nº 10.594.533/0001-00, por intermédio da SECRETARIA MUNICIPAL DE SAÚDE, doravante denominado CONTRATANTE, representado neste ato pelo Secretário, Sr. VALMOR JOÃO REISDORFER, e a empresa RANG TECNOLOGIA E DESENVOLVIMENTO DE SISTEMAS LTDA, CNPJ: 19.286.537/0001-98,

estabelecida na AV. Xxxxxxxx Xxxxxxx, Xx 000, 0x Xxxxx – Xxxx xx Xxxxx xx Xxx / XX | 85618-000, doravante denominada CONTRATADA, representada neste ato pelo Sr. XXXXXX XXXXXXXX, inscrito(a) no CPF/MF sob o nº 086.xxx.xxx-32, celebram entre si o presente TERMO DE CONTRATO, mediante cláusulas e condições que aceitam, ratificam e outorgam na forma abaixo estabelecida, tudo de acordo com o Processo de Licitação nº 22/2021/PMJ, instaurado através do Edital de Pregão Eletrônico nº 04/2021/PMJ, homologado em 15.06.2023, o qual é parte integrante do presente instrumento.

CLÁUSULA PRIMEIRA - DO OBJETO

O objeto do presente contrato é o fornecimento, pela CONTRATADA, de licenciamento de uso de software e/ou manutenção de software para a gestão do Sistema de Saúde Pública Municipal, incluindo os serviços de conversão de dados, implantação, treinamento, manutenção mensal corretiva, adaptativa e evolutiva, bem como suporte técnico e consultoria técnica para a utilização de serviços móveis, em atendimento às necessidades do Município de Joaçaba/SC, de acordo com as especificações no Termo de Referência (Anexo I) deste contrato.

Além da locação da solução, a empresa deverá efetuar os serviços de instalação, customização, treinamento, operação assistida, suporte operacional, atualizações tecnológicas, bem como, links de internet para transmissão de dados entre os dispositivos móveis e a central de operações.

CLÁUSULA SEGUNDA - DA FORMA DE EXECUÇÃO

2.1. O objeto deste contrato deverá ser executado em conformidade com as especificações e prazos constantes dos Anexos I – Termo de Referência.

2.2. O software deverá ser compatível com todos os equipamentos existentes na Secretaria Municipal de Saúde.

2.3. A contratada deverá apresentar cronograma detalhado das etapas do projeto, constando as atividades que serão realizadas, recursos de pessoal, prazos de desenvolvimento dos serviços de migração, implantação, treinamento e acompanhamento pós-implantação, contemplando todos os módulos e processos da solução em todas as áreas atendidas e envolvidas neste projeto.

2.4. Este cronograma deve ser apresentado preferencialmente em diagrama Gantt (gráfico para ilustrar as etapas de um projeto), gerado a partir de software de gerenciamento de projetos disponível no mercado ou outro mecanismo que ilustra claramente as atividades e prazos de cada etapa.

2.5. A contratada deverá responsabilizar-se integralmente por sua equipe técnica, primando pela qualidade, desempenho, eficiência e produtividade, visando a efetividade dos trabalhos durante toda a execução do contrato dentro dos prazos estipulados.

2.6. Todas as decisões e entendimentos havidos entre as partes durante o andamento dos trabalhos e que impliquem em modificações ou implementações nos planos, cronogramas ou atividades pactuadas, deverão ser feitas previamente, formalmente acordadas e documentadas entre as partes.

2.7. A contratada deverá fornecer garantia dos serviços contra defeitos de fabricação e apresentação de qualidade inadequada, cuja resolução do problema, pela licitante, deverá ser imediata.

2.8. A contratada responderá pelas perdas, reproduções indevidas e/ou adulterações que por xxxxxxx xxxxxx a ocorrer nas informações da Secretaria Municipal de Saúde, quando estas estiverem sobre sua responsabilidade.

2.9. Os dados são de propriedade da Secretaria Municipal de Saúde, não tendo direito a contratada, a reter os mesmos, ao fim do contrato, sob pena se sanções/penalidade tanto nas esferas administrativas, quanto nas cíveis/penais.

2.10. A detentora e os membros da equipe guardarão sigilo absoluto sobre os dados e informações do objeto das prestações de serviços ou quaisquer outras informações que venham ter conhecimento em decorrência da execução das atividades previstas no contrato, respondendo contratual e legalmente pela inobservância desta instrução, inclusive após o término do contrato.

2.11. A qualquer tempo, o Município poderá solicitar a cópia do Banco de Dados/Informações existentes no sistema, a qual a contratada deverá fornecer sem nenhum óbice/ônus a administração.

2.12. Não deve haver limitador de usuários, quantidade de acessos, requisições e tarefas simultâneo.

2.13. Por ocasião do recebimento dos serviços, a Secretaria Municipal de Saúde, por intermédio de servidor designado, reserva-se no direito de proceder às validações das funcionalidades requeridas e especificadas neste contrato, rejeitá-los, no todo ou em parte, se estiverem em desacordo com as especificações técnicas do objeto licitado, obrigando-se a contratada promover as devidas correções, observando-se os prazos estipulados.

2.13.1. O aceite dos serviços não exclui a responsabilidade civil da contratada por vícios de quantidade, de qualidade ou técnico, ou por desacordo com as especificações estabelecidas neste contrato, verificadas posteriormente.

2.13.2. Caso os serviços sejam recusados ou o documento fiscal apresente incorreção, o prazo de pagamento será contado a partir da data da regularização, a depender do evento.

2.14. A contratada deverá obedecer ao objeto do presente contrato, prestando-o dentro dos padrões de qualidade, continuidade e regularidade.

2.15. A prestação dos serviços somente poderá ser efetuada pela contratada, sendo vedada a sublocação

dos mesmos.

CLÁUSULA TERCEIRA – DA VIGÊNCIA E DO ACOMPANHAMENTO

3.1. O presente instrumento terá vigência de 12 (doze) meses, podendo ocorrer prorrogação, se de interesse das partes, por períodos iguais e sucessivos, até o limite de 48 (quarenta e oito) meses, observado o disposto no art. 57, II, da Lei 8.666/93.

3.2. A execução do presente contrato deverá ser acompanhada e fiscalizada pelos servidores LUANA TAIS PIOVESAN, XXX XXXXX XXXXXX, XXXXXX XXXXXXX XXXXXXXX e XXXXX XXXXXXXXXX XXXXXXXX XXXXXXXX, que anotará em registro próprio todas as ocorrências, determinando o que for necessário à regularização das falhas ou defeitos observados.

3.3. Não obstante o fato de a contratada ser a única e exclusiva responsável pela execução dos serviços, o Município, através de seus servidores ou de prepostos formalmente designados, sem restringir a plenitude daquela responsabilidade, exercerá a mais ampla e completa fiscalização dos serviços em execução.

3.4. A fiscalização exercerá controle em relação a quantidade e particularmente a qualidade dos serviços executados, a fim de possibilitar a aplicação das penalidades previstas, quando desatendidas as disposições a elas relativas.

3.5. A fiscalização poderá ordenar a qualquer momento, sem prejuízo de outras sanções cabíveis ao caso, a paralisação dos serviços sempre que a empresa deixar de cumprir o contido com as exigências.

CLÁUSULA QUARTA – DO PREÇO, DA FORMA DE PAGAMENTO, DO REAJUSTE E DA REVISÃO

4.1. O valor global ora contratado é de R$ 233.519,20 (duzentos e trinta e três mil, quinhentos e dezenove reais e vinte centavos), consignado na proposta apresentada e vencedora do Processo de Licitação, conforme segue:

LOTE 01
ITEM	QTDE	UN	ESPECIFICAÇÃO	VALOR UNITÁRIO (R$)	VALOR TOTAL (R$)
1	12	MES	Cadastros e funcionalidades gerais	542,26	6.507,12
2	12	MES	Sistema de Comunicação com Pacientes por SMS/WhatsApp	268,60	3.233,20
3	12	MES	Controle de estoques e farmácia	925,18	11.102,16
4	12	MES	Regulação e agendamento de consultas	204,14	2.449,68
5	12	MES	Regulação e Agendamento de exames	182,17	2.186,04
6	12	MES	Acolhimento/Atendimento	639,80	7.677,60
7	12	MES	Prontuário eletrônico Multiprofissional	1.613,00	19.356,00
8	12	MES	Prontuário Odontológico	377,27	4.527,24
9	12	MES	Listas de espera	255,34	3.064,08
10	12	MES	Ações programáticas em Saúde	156,17	1.874,04
11	12	MES	Medicamento Judicial	182,16	2.185,92
12	12	MES	Benefícios	148,04	1.776,48
13	12	MES	Faturamento da produção ambulatorial	615,42	7.385,04
14	12	MES	Imunizações/ Vacina	221,21	2.654,52
15	12	MES	Saúde da família	230,95	2.771,40
16	12	MES	Painel Multimídia	133,40	1.600,80
17	12	MES	Business Intelligence	401,57	4.818,84
18	12	MES	Vigilância Sanitária	801,73	9.620,76
19	12	MES	Vigilância Epidemiológica	301,69	3.620,28
20	12	MES	Laboratório	1.052,03	12.624,36
21	12	MES	Consulta Geral	133,40	1.600,80
22	12	MES	Zoonoses	204,14	2.449,68
23	12	MES	Assinatura Digital	167,55	2.010,60
24	12	MES	Mobilidade/Captação dados móveis	1.577,54	18.930,48
25	12	MES	Controle de Transportes	532,50	6.390,00
26	12	MES	TFD	304,43	3.653,16
27	12	MES	Portal com informações da Saúde	156,16	1.873,92
28	500	H	Hora técnica para customização de sistema para adequar as necessidades especificas do Município.	93,10	46.550,00
29	500	H	Hora técnica para treinamento complementar após implantação do sistema	78,07	39.035,00
VALOR TOTAL:					233.519,20

4.2. Os pagamentos serão realizados pelo Departamento de Contabilidade e Finanças da Prefeitura Municipal de Joaçaba da seguinte forma:

a. Os pagamentos serão feitos em moeda nacional, de acordo com os Módulos do Sistema liberados para implantação, e será efetuado até o 5º (quinto) dia útil contado da apresentação da nota/fatura devidamente atestada, com as cautelas e formalidades preconizadas pelos artigos 73 e 74 da Lei nº 8.666/93 e suas alterações. As notas fiscais a serem entregues, deverão informar o número de empenho, descrição conforme empenho, número do processo de licitação e dados bancários para realização do pagamento a contratada.

b. Será emitida a nota fiscal referente a implantação e cessão de direitos de uso em até 15 (quinze) dias após a implantação do sistema, desde que contenha Autorização de Fornecimento autorizando a implantação.

c. Serão emitidas notas fiscais referentes à manutenção/locação de cada Modulo, mensalmente, trinta dias a partir da implantação do modulo, desde que contenha Autorização de Fornecimento liberando o serviço de implantação do modulo.

d. Horas de treinamentos adicionais e de customização serão pagos no 5º (quinto) dia do mês subsequente a prestação de serviço e quanto solicitado por escrito pela Secretaria de Saúde e com a comprovação do serviço realizado, em nota fiscal emita de forma individual em relação aos outros serviços.

e. O pagamento será suspenso se observado algum descumprimento das obrigações assumidas pela contratada, no que se refere à habilitação, qualificação e demais exigências especificadas neste processo licitatório, em virtude de penalidade ou inadimplência, sem que isto gere direito ao pleito de reajustamento de preço ou correção monetária.

f. Nos pagamentos realizados após a data de vencimento, incidirá correção monetária pela variação mensal do INPC, “pro-rata-die”, nas condições e periodicidade estabelecida pela legislação aplicável.

g. A contratação dos módulos se dará gradativamente e somente após a emissão da Autorização de Fornecimento emitida pela Secretaria de Saúde.

4.2.1. Os pagamentos somente poderão ser efetuados após comprovação do recolhimento das contribuições sociais (Fundo de Garantia do Tempo de Serviço e Previdência Social), correspondentes ao mês da última competência vencida, compatível com o efetivo declarado, na forma do § 4º, do art. 31, da Lei nº 9.032/1995 e apresentação de Nota Fiscal/Fatura atestada por servidor municipal competente, conforme disposto nos artigos 67 e 73 da Lei 8.666/93.

4.2.2. Os pagamentos serão efetuados por meio de transferência bancária Banco: Banco do Brasil – 001

| Agência: 1391-9 | Conta Corrente: 15900-0.

4.3. A Nota Fiscal ou outro documento fiscal correlato deverá, conforme o caso, ser emitido para:

✓ FUNDO MUNICIPAL DE SAÚDE, Xxx Xxxxxxx Xxxxxx, 000, 0x xxxxx, Xxxxxxxx Xxxxxxx Xxxxxxxx, Xxxxxx - Xxxxxxx - XX, CNPJ nº 10.594.533/0001-00.

4.3.1. A Nota Fiscal deverá ter a mesma Razão Social e CNPJ dos documentos apresentados por ocasião da habilitação, contendo ainda número do empenho e do processo licitatório.

4.3.2. A apresentação do documento fiscal que contrarie essas exigências inviabilizará o pagamento, isentando o órgão requisitante do ressarcimento de qualquer prejuízo para a proponente vencedora.

4.4. Os valores propostos somente serão reajustados depois de decorrido o primeiro ano contratual, com base no INPC (IBGE) apurado no período de referência, ou na falta desse, pelo índice legalmente permitido à época, mediante requerimento expresso da contratada neste sentido, com antecedência mínima de 30 (trinta) dias do reajuste.

4.5. Os preços somente serão revisados quando houver alteração de valor, devidamente comprovada, podendo ocorrer de acordo com o art. 65 da Lei 8.666/93 e alterações, mediante requerimento a ser formalizado pela contratada.

CLÁUSULA QUINTA - DA DOTAÇÃO ORÇAMENTÁRIA

5.1. As despesas provenientes da execução deste contrato correrão por conta das seguintes dotações orçamentárias:

Órgão: 18.001 - FUNDO DE SAÚDE

Despesa: 15

Projeto Atividade: 2.122 – BLATB: BLOCO DE ATENÇÃO BÁSICA

Dotação: 3.3.90.00.00.00.00.00.0.0.00.0122 – Aplicações Diretas

5.2. A Secretaria Municipal de Saúde consignará nos próximos exercícios em seu orçamento os recursos necessários ao atendimento dos pagamentos previstos.

CLÁUSULA SEXTA - DAS RESPONSABILIDADES

3.1. Responsabilidades do CONTRATANTE:

3.1.1. Tomar todas as providências necessárias à execução do contrato.

3.1.2. Prestar as informações e os esclarecimentos que venham a ser solicitados.

3.1.3. Emitir Autorização de Fornecimento para a efetiva execução do objeto.

3.1.4. Promover o acompanhamento e a fiscalização do da execução do objeto, sob os aspectos qualitativos e quantitativos, anotando em registro próprio as falhas e solicitando as medidas corretivas.

3.1.5. Observar para que durante a vigência do contrato sejam cumpridas as obrigações assumidas pela contratada, bem como sejam mantidas todas as condições de habilitação e qualificação exigidas na licitação.

3.1.6. Proporcionar todas as facilidades para que a contratada possa desempenhar seus serviços, facilitando o acesso dos técnicos da contratada às áreas de trabalho, registros, documentação e demais informações necessárias ao bom desempenho das funções.

3.1.7. Notificar por escrito à contratada a ocorrência de eventuais imperfeições no curso da execução dos serviços, fixando prazo para a sua correção.

3.1.8. Rejeitar, no todo ou em parte, os serviços executados em desacordo com as exigências do Termo de Referência.

3.1.9. Efetuar o pagamento à contratada, de acordo com o descrito neste contrato.

3.1.10. Notificar à contratada, por escrito, da aplicação de eventuais penalidades, garantido o contraditório e a ampla defesa, nos termos da Lei 8.666/93.

3.2. Responsabilidades da CONTRATADA:

3.2.1. Executar os serviços de acordo com o disposto na cláusula terceira – Forma de Execução.

3.2.2. Exigir do Município, a Autorização de Fornecimento para o efetivo fornecimento do objeto.

3.2.3. Manter, durante a execução do contrato todas as condições de habilitação previstas no Edital, e em compatibilidade com as obrigações assumidas.

3.2.4. Obedecer ao objeto e as disposições legais contratuais, prestando-os dentro dos padrões de qualidade, continuidade e regularidade.

3.2.5. Responsabilizar-se por eventuais danos causados à Administração ou a terceiros, decorrentes de sua culpa ou dolo na execução do contrato.

3.2.6. Responsabilizar-se pelos custos inerentes a encargos tributários, sociais, fiscais, trabalhistas, previdenciários, securitários e de gerenciamento, resultantes da execução do contrato.

3.2.7. Instalar o sistema, objeto deste contrato e treinar os usuários para a sua utilização.

3.2.8. Prestar suporte na operacionalização do sistema, objeto deste contrato, ao usuário que tenha recebido o devido treinamento.

3.2.9. Prestar, às suas expensas, as manutenções que se fizerem necessárias no sistema, causadas por problemas originados das fontes dos seus programas.

3.2.10. Tratar como confidenciais informações e dados contidos nos sistemas da Secretaria de Saúde, guardando total sigilo perante terceiros.

3.2.11. Disponibilizar, sempre que requisitado pela Secretaria de Saúde, os dados (banco de dados) constantes no sistema.

3.2.12. Facilitar todas as atividades de fiscalização do contrato.

CLÁUSULA OITAVA - DAS SANÇÕES

8.1. Nos termos do art. 7° da Lei 10.520/2002, se a CONTRATADA, convocada no prazo estipulado, não celebrar o contrato, deixar de entregar ou apresentar documentação falsa exigida para o certame, ensejar o retardamento da execução de seu objeto, não mantiver a proposta, falhar ou fraudar na

execução do Contrato, comportar-se de modo inidôneo ou cometer fraude fiscal, ficará impedida de licitar e contratar com a União, Estados, Distrito Federal ou Municípios, e será descredenciado nos sistemas de cadastramento de fornecedores, pelo prazo de até 05 (cinco) anos, sem prejuízo das multas previstas neste Edital e das demais cominações legais.

8.2. O atraso injustificado na entrega do objeto sujeitará a proponente vencedora à multa, no valor de R$ 100,00 (cem reais), por dia de atraso, até o limite de 20% (vinte por cento) do total do contrato.

8.3. No caso de inexecução total ou parcial do objeto contratado, multa de 10% sobre o valor global do contrato, a ser recolhida no prazo de 15 (quinze) dias corridos, contado da comunicação oficial da decisão definitiva.

8.4. As penalidades aludidas acima não impedem que a Administração aplique as outras sanções previstas em Lei.

8.5. Na aplicação das penalidades serão admitidos os recursos previstos em lei, garantido o contraditório e a ampla defesa.

CLÁUSULA NONA – DA INEXECUÇÃO E DA RESCISÃO CONTRATUAL

9.1. O contrato poderá ser rescindido nos seguintes casos:

9.1.1. Por ato unilateral escrito do CONTRATANTE, nos casos enumerados nos incisos I a XVII, do art. 78, da Lei 8.666/93.

9.1.2. Amigavelmente, por acordo das partes, mediante formalização de aviso prévio de, no mínimo, 30 (trinta) dias, não cabendo indenização a qualquer uma das partes, resguardando-se o interesse público.

9.1.3. Judicialmente, nos termos da legislação vigente.

9.2. O descumprimento, por parte da CONTRATADA, de suas obrigações legais e/ou contratuais, assegura ao CONTRATANTE o direito de rescindir o contrato a qualquer tempo, independente de aviso, interpelação judicial e/ou extrajudicial.

9.3. Fica reservado ao CONTRATANTE o direito de rescindir total ou parcialmente o presente contrato, desde que seja administrativamente conveniente ou que importe no interesse público, conforme preceituam os artigos 78, 79 e 80 da Lei 8.666/93 e alterações, sem que assista a CONTRATADA, direito algum de reclamações ou indenização, com exceção da rescisão com fulcro no art. 78, XII a XVII, em que será observado o disposto no art. 79, § 2º, da Lei 8.666/93.

CLÁUSULA DÉCIMA - DAS CONDIÇÕES GERAIS

10.1. Na execução deste contrato aplicar-se-á a Lei 8.666/93 e alterações, e ainda os preceitos gerais do direito público, os princípios da teoria geral dos contratos e as disposições de direito privado.

10.2. A declaração de nulidade deste contrato opera retroativamente impedindo os efeitos jurídicos que ele, ordinariamente, deveria produzir, além de desconstituir os já produzidos.

10.3. Os casos omissos serão resolvidos à luz da Lei 8.666/93 e suas alterações, recorrendo-se à analogia, aos costumes e aos princípios gerais do direito.

CLÁUSULA DÉCIMA PRIMEIRA - DO FORO

11.1. Fica eleito o foro da cidade de Joaçaba (SC) para dirimir questões oriundas deste contrato, renunciando as partes a qualquer outro que lhe possa ser mais favorável.

E, por estarem acordes, firmam o presente instrumento, juntamente com as testemunhas abaixo, em 04 (quatro) vias de igual teor, para todos os efeitos de direito.

Xxxxxxx (SC), 15 de junho de 2023.

FUNDO MUNICIPAL DE SAÚDE DE JOAÇABA SECRETARIA MUNICIPAL DE SAÚDE VALMOR XXXX XXXXXXXXXX – Secretário

XXXXXX XXXXXXXX

RANG TECNOLOGIA E DESENVOLVIMENTO DE SISTEMAS LTDA CNPJ: 19.286.537/0001-98

Testemunhas:

1ª

2ª

ANEXO I

TERMO DE REFERÊNCIA

1. OBJETIVOS GERAIS

O presente termo de referência tem por objetivo a contratação de empresa especializada na cessão de licenciamento de uso de software e/ou manutenção de software para a gestão do Sistema de Saúde Pública Municipal, incluindo os serviços de conversão de dados, implantação, treinamento, manutenção mensal corretiva, adaptativa e evolutiva, bem como suporte técnico e consultoria técnica para a utilização de serviços móveis, em atendimento às necessidades do município de Joaçaba/SC.

2. JUSTIFICATIVA

Levando em consideração o aumento de demandas burocráticas, a modernização e a evolução tecnologia em todos os setores públicos, e considerando-se que a saúde é um serviço que demanda grande quantidade de processos, muitas vezes envolvendo vários tipos de protocolos e metodologias, é necessário que tais processos sejam executados com eficiência e eficácia, sob pena de comprometer a qualidade de prestação do serviço à população.

Assim, de tempos em tempos é preciso avaliar os cenários e melhorar a disponibilização de recursos tecnológicos, realizando um processo de modernização da saúde para que não se perca a qualidade na prestação dos serviços.

Com isso, após todo processo concluído, espera-se obter uma base de dados completa e fidedigna sobre as informações da saúde do município e sua população, melhoria no processo de tomada de decisão com a utilização de ferramentas inteligentes, que em contrapartida deverão proporcionar a melhoria dos indicadores de saúde do município em todos os aspectos.

3. PRAZO DE VIGÊNCIA

A contratação dos serviços e licenciamento de solução objeto do presente projeto será por 12 (doze) meses, podendo ser prorrogado por até 48 (quarenta e oito meses).

4. SERVIÇOS A SEREM PRESTADOS

A Contratada deverá apresentar cronograma detalhado das etapas do projeto, constando as atividades que serão realizadas, recursos de pessoal, prazos de desenvolvimento dos serviços de migração, implantação, treinamento e acompanhamento pós-implantação, contemplando todos os módulos e processos da solução em todas as áreas atendidas e envolvidas neste projeto.

Este cronograma deve ser apresentado preferencialmente em diagrama Gantt (gráfico para ilustrar as etapas de um projeto), gerado a partir de software de gerenciamento de projetos disponível no mercado ou outro mecanismo que ilustra claramente as atividades e prazos de cada etapa.

4.1. IMPLANTAÇÃO

Entenda-se como implantação todos os serviços necessários ao normal funcionamento da solução em todas as áreas abrangidas, dentre os quais: implantação, configuração, treinamento, customização, migração e conversão de informações existentes e necessárias à operação dos sistemas:

4.1.1. A CONTRATADA deverá prestar serviço de implantação, ou seja, a adequação e customização do sistema para a realidade, fluxos e assuntos do município.

4.1.2. A implantação deverá cumprir as seguintes etapas:

a. Configuração do sistema licitado, com todos os fluxos e assuntos descritos no termo de referência, em um ambiente de testes;

b. Criação de contas para usuários internos;

c. Aplicação de regras de validações em formulários, juntamente com equipe do município. As regras de validações dizem respeito a como os formulários dos assuntos e fluxos podem ser validados pelo próprio sistema, sem interação humana;

d. Tramitação de processos testes (não reais) nos fluxos e assuntos cadastrados;

e. Adequação de fluxos e assuntos que o município entender não estarem ideais;

f. Lançamento e liberação do sistema para requerentes.

4.1.3. A licitante vencedora deverá realizar a migração das informações de atendimento contidas no software atual, disponibilizando meio de consulta, impressão e ainda disponibilizando os históricos de atendimento, cadastros, dispensação de medicamentos, transporte, laboratório e todos os registros efetuados para dentro do software a ser disponibilizado.

4.1.4. A empresa CONTRATADA deverá providenciar a conversão dos dados existentes para os formatos e padrões exigidos pelos novos sistemas licitados, mantendo a integridade e segurança dos dados.

4.1.5. A entidade não dispõe de diagrama e/ou dicionário de dados para fornecimento a empresa vencedora da licitação, devendo ela migrar / converter a partir de cópia de banco de dados a ser fornecida.

4.1.6. Na ausência da possibilidade de migração dos dados do banco atual, a CONTRATADA deverá providenciar, sem ônus para o município, a digitação de todos os itens corrigidos, sujeito a verificação posterior por parte do município.

4.1.7. Efetuada a migração e consistência dos dados importados, as informações deverão ser homologadas pelo município, através dos responsáveis pelos dados atuais dos sistemas em cada área.

4.1.8. Para cada um dos sistemas licitados, quando couber, deverão ser cumpridas as atividades de configuração / customização de programas, de forma que os mesmos estejam adequados à legislação da entidade.

4.1.9. Dúvidas sobre estrutura, tamanho e quantidade de bancos de dados podem ser esclarecidas em visita técnica.

4.1.10. Acompanhamento dos usuários, na sede da entidade, em tempo integral na fase de implantação do objeto.

4.1.11. Todas as decisões e entendimentos havidos entre as partes durante o andamento dos trabalhos e que impliquem em modificações ou implementações nos planos, cronogramas ou atividades pactuadas, deverão ser prévia e formalmente acordados e documentados entre as partes.

4.1.12. A CONTRATADA será responsabilizada pelas perdas, reproduções indevidas e/ou adulterações que porventura venham a ocorrer nas informações da CONTRATANTE, quando der causa e estas estiverem sob sua responsabilidade.

4.1.13. A CONTRATADA e os membros da equipe deverão manter absoluto sigilo acerca de todos os dados e informações relacionadas ao objeto da presente licitação, assim como, quaisquer outras informações a que venham a ter conhecimento em decorrência da prestação de serviços contratados, podendo responder contratualmente e legalmente pela inobservância desta alínea, inclusive após o término do contrato.

4.1.14. O cronograma de implantação deverá ser apresentado em até 05 (cinco) dias úteis a partir da emissão da ordem de serviço.

4.1.15. A implantação deverá ser concluída no prazo máximo de 90 (noventa) dias, contados a partir do envio do cronograma de implantação.

4.1.16. A emissão do termo de aceite dos serviços de implantação e treinamento, ocorrerá somente ao fim da data prevista para fim dos serviços, caso o serviço tenha sido executado de maneira satisfatória, mediante procedimentos de validação por parte do fiscal do contrato.

4.1.17. O sistema deverá integrar os módulos, proporcionando aos profissionais responsáveis administrar os serviços oferecidos pela Secretaria de Saúde de maneira centralizada, além de agilizar e melhorar todo o processo.

4.2. DA CAPACITAÇÃO / TREINAMENTO

4.2.1. A CONTRATADA deverá apresentar, Plano de Treinamento destinado à capacitação dos usuários e técnicos operacionais para a plena utilização das diversas funcionalidades de cada um dos sistemas, abrangendo os níveis funcional e gerencial, o qual deverá conter os seguintes requisitos mínimos:

a. Nome e objetivo de cada módulo de treinamento;

b. Público-alvo;

c. Conteúdo programático, devendo contemplar a execução de todas as funcionalidades e requisitos técnicos do edital, respeitadas as devidas permissões e casos de uso;

d. Registro de listas de presença com data, nome e assinatura dos participantes;

e. Carga horária de cada módulo do treinamento;

f. Processo de avaliação da aprendizagem e conhecimentos adquiridos;

g. Processo de avaliação qualitativa do conteúdo e dos instrutores do treinamento;

h. Recursos utilizados no processo de treinamento (equipamentos, softwares, filmes, slides, apostilas, livros, fotos etc.).

4.2.2. O treinamento para o nível técnico compreendendo: capacitação para suporte aos usuários, aspectos relacionados a configurações, monitoramento de uso e permissões de acesso, permitindo que a equipe técnica possa propiciar o primeiro atendimento aos usuários, ou providenciar a abertura de chamado para suporte pela CONTRATADA.

4.2.3. As turmas devem ser dimensionadas por área de aplicação, sendo que cada turma não possuirá mais de 20 (vinte) participantes.

4.2.4. Deverá ser fornecido Certificado de Participação aos funcionários que tiverem comparecido a mais de 85% (oitenta e cinco por cento) das atividades de cada curso.

4.2.5. Em relação a possíveis usuários externos (que por meio de algum convênio venham a interagir com algum dos módulos) dos sistemas, deverá a CONTRATADA realizar palestras orientadoras, cada uma com duração mínima de uma hora, nos limites territoriais do Município de Joaçaba, em local a ser designado pelo CONTRATANTE.

4.2.6. A CONTRATANTE resguardar-se-á o direito de acompanhar, adequar e avaliar o treinamento contratado com instrumentos próprios, sendo que se o treinamento for julgado insuficiente, caberá à CONTRATADA, sem ônus para a CONTRATANTE, ministrar o devido reforço.

4.2.7. Os treinamentos necessários após a conclusão da implantação da solução, para novos profissionais e reforços aos atuais, serão de responsabilidade da empresa CONTRATADA, sem ônus ao município até o término do contrato.

4.2.8. A CONTRATADA deverá oferecer treinamentos da solução para a formação de usuários / multiplicadores que possibilitem a instalação, configuração, gerência, manutenção e uso eficiente do sistema. Os treinamentos deverão ser ministrados pela CONTRATADA.

4.2.9. O treinamento para os usuários administradores deve contemplar uma visão geral sobre o ambiente técnico, ferramentas de consulta, como manter e operar o sistema, como efetuar manutenções futuras e como operar toda e qualquer rotina do sistema, metodologia utilizada, possíveis adequações de apoio (segurança, parametrização, etc.) e de suporte ao usuário (cadastrar usuário, cadastrar grupos, gravação, execução, etc.).

4.2.10. O treinamento para os gestores do sistema deve contemplar uma visão geral sobre suas funcionalidades, bem como efetuar todas as operações e fazer as configurações necessárias para permissões e restrições de uso.

4.2.11. A CONTRATANTE providenciará o local do treinamento, computadores para os participantes, equipamento audiovisual de suporte e material didático para o treinamento.

4.2.12. A CONTRATADA deverá realizar treinamentos diretamente nas unidades que a CONTRATANTE solicitar.

4.2.13. As despesas relativas à participação dos instrutores e de pessoal próprio, tais como: hora técnica, hospedagem, transporte, diárias etc. serão de responsabilidade exclusiva da CONTRATADA.

4.3. DA MANUTENÇÃO

4.3.1. Os sistemas de informações e programas serão mantidos em datacenter pertencente a empresa proponente ou de terceiros, devendo a empresa CONTRATADA fornecer/dispor de cópia semanal dos dados alocados no datacenter para o município.

4.3.2. A empresa CONTRATADA deverá disponibilizar a atualização de versão de todos os módulos, sempre que necessário, para atendimento da legislação municipal, estadual ou federal, sem quaisquer ônus adicionais para o município, durante a vigência contratual.

4.3.3. A CONTRATADA deverá executar a manutenção corretiva, adaptativa e evolutiva dos sistemas contratados, durante a execução do contrato, de acordo com as exigências a seguir:

a. Entende-se por ‘manutenção corretiva’ aquela decorrente de problemas de funcionalidade detectados pelo usuário, ou seja, funcionamento em desacordo com o que foi especificado relativo a telas, regras de negócio, relatórios e integração, com prazo máximo de até 10 (dez) dias úteis para conclusão;

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

c. Entende-se por ‘manutenção evolutiva’ aquelas manutenções que visarem a implementação de novas funcionalidades à solução, a fim atender necessidades novas percebidas, desde que não estejam compreendidas como manutenção adaptativa.

4.3.4. Todas as manutenções evolutivas e de solicitação exclusiva da CONTRATANTE, que impliquem em inclusões de novas funções, telas ou relatórios, poderão ser desenvolvidas e pagas por hora técnica, mediante valores indicados pela proponente na proposta de preço, desde que exigido e autorizado pelo responsável pela gestão do contrato no município.

4.3.5. O servidor na nuvem utilizado pela CONTRATADA (próprio ou subcontratado), deverá atender no mínimo aos seguintes requisitos:

a. Monitoramento técnico especializado no local, durante todos os dias do ano;

b. Restrição de acesso aos servidores para pessoas não autorizadas;

c. Capacidade elástica;

d. Proteção contra malwares e ataques de negação de serviço;

e. Tempo de atividade (uptime) mínimo de 98%.

4.3.6. A CONTRATADA deverá garantir alta disponibilidade dos sistemas que fazem parte da solução, 24/7 (vinte e quatro horas por dia, sete dias por semana), e, em caso de exceções, aplicar políticas de gerenciamento de riscos e continuidade dos serviços com redundância de servidores (espelhos), aumento de capacidade de processamento e outros procedimentos que reduzam o tempo de interrupção dos serviços.

4.3.7. A CONTRATADA deverá executar no mínimo as seguintes atividades:

a. Backups de rotina do banco de dados, de no mínimo 06 (seis) em 06 (seis) horas.

b. Testes de qualidade (QA) antes de implementar atualizações e correções no ambiente do sistema utilizado pelo município.

c. Garantir a atualização do sistema para versões mais seguras e otimizadas a que desenvolver no período de vigência contratual.

d. Mitigação de erros, bugs e outras anormalidades que possam prejudicam o funcionamento do sistema.

4.3.8. A plataforma deve possuir elasticidade virtualmente infinita de armazenamento de dados, que permita o dimensionado da estrutura de TI dedicada de acordo com a demanda de armazenamento.

4.3.9. Não serão admitidas soluções baseadas em máquinas virtuais estáticas, manualmente dinamizadas, e que não suportem picos de processamento bem como onerem a administração pública em médio e longo prazo com aumento de capacidade de processamento.

4.3.10. Os sistemas devem permanecer hospedados em ambiente em nuvem com comprovação de disponibilidade multizona com no mínimo três estruturas distintas e fisicamente separadas em locais com distância mínima de 50km entre si, assegurando-se plena acessibilidade e disponibilidade dos serviços e da plataforma.

4.3.11. O ambiente multizona deve funcionar com replicação de dados em tempo real, assegurando disponibilidade dos serviços em caso de queda de um ambiente em nuvem, sem prejuízo de disponibilidade e acessibilidade.

4.3.12. A CONTRATADA deverá comunicar o município, tão logo tomar conhecimento, sobre instabilidades, indisponibilidades e falhas no sistema.

4.3.13. Em regra, manutenções que tornem o sistema inacessível, devem ser realizadas fora do horário comercial.

4.3.14. As atualizações deverão ser disponibilizadas com sua instalação e configuração feitas pela CONTRATADA, garantindo a correto funcionamento do sistema.

4.4. DO SUPORTE TÉCNICO

4.4.1. O atendimento às solicitações de suporte deve ser providas presencialmente ou remotamente via telefone, e-mail, ferramenta de registro de chamados e chat, por técnico apto a prover o devido suporte ao sistema.

4.4.2. São objetivos do suporte técnico:

a. Esclarecer dúvidas que possam surgir durante a operação e utilização dos sistemas;

b. Sugerir e apoiar métodos e práticas visando a correta e adequada utilização dos módulos, possibilitando obter o máximo de aproveitamento de seus recursos;

c. Apoiar na análise e documentação de informações a respeito de mudanças na legislação municipal, estadual e federal, visando a adequada implementação destas nos sistemas;

d. Apoiar na análise e documentação de informações a respeito de mudanças ou melhorias nas metodologias de trabalho, visando a otimizada implementação destas nos sistemas.

4.4.3. O serviço de suporte técnico operacional deve ser provido no mínimo de segunda à sexta-feira, das 7:30h (sete e trinta) às 11:30h (onze e trinta) e das 13:00h (treze) às 17:00h (dezessete).

4.4.4. A CONTRATADA deverá disponibilizar portal de atendimento, suporte e sustentação ao usuário, permitindo à entidade uma visão gerencial completa dos serviços e do atendimento técnico prestado pela empresa CONTRATADA.

4.4.5. Para cada novo atendimento iniciado deverá ser vinculado um código ou número de chamado exclusivo, podendo ser listado e visualizado pelo usuário posteriormente.

4.4.6. O portal de atendimento deve permitir o cadastro dos usuários em diversas entidades a qual ele esteja vinculado, possibilitando abrir chamados, executar reclamações, enviar documentos, tramitar questões técnicas.

4.4.7. O portal de atendimento deve disponibilizar um recurso para o usuário pesquisar e visualizar todos os seus registros de chamados realizados.

4.4.8. O portal de atendimento deve permitir que o usuário altere a sua senha de acesso.

4.4.9. O portal de atendimento deve permitir o envio/recebimento de notificações aos usuários envolvidos no atendimento de uma solicitação ou tarefa.

4.4.10. O portal de atendimento deve possuir pesquisa de satisfação dos chamados atendidos, acessível pela entidade CONTRATANTE, inclusive.

4.4.11. Os prazos de atendimento serão determinados em função do nível de severidade da ocorrência. O tempo de atendimento começa a contar a partir da abertura do chamado e deverá ser atendido de acordo com a tabela abaixo:

a. Sistema inoperante: até 02 horas;

b. Problema ou dúvida, restringindo a operação do sistema: até 12 horas;

c. Problema ou dúvida, prejudicando a operação do sistema: até 24 horas;

d. Problema ou dúvida, que não afeta a operação do sistema: até 48 horas.

4.4.12. A contratada deverá disponibilizar, no mínimo um (01) profissional de referência, em tempo integral à disposição da Secretaria de Saúde, com visitas periódicas, para suporte, treinamento, atualizações, entre outras atividades, o qual deverá possuir meio de locomoção da empresa CONTRATADA, caso tenha que se deslocar dentro do município.

4.4.13. A empresa disponibilizará diariamente, das 7h30 às 17h, durante os 06 (seis) primeiros meses da vigência do contrato, um técnico contratado para auxiliar presencialmente, tanto no processo de implantação, quanto nas demandas diárias inerentes ao uso do sistema.

4.5. DOS SERVIÇOS DE CUSTOMIZAÇÃO

4.5.1. O serviço de customização e consultoria técnica relacionado na definição do objeto refere-se aquelas customizações de requisitos que não se encontram descritas neste edital e que não se encontrarem implementadas na solução contratada, ressaltando-se que não sejam decorrentes de imposições legais ou atualizações.

4.5.2. Os serviços de customização somente poderão ser executados mediante prévia autorização da equipe técnica da CONTRATANTE, que será responsável pela gestão das horas contratadas.

4.5.3. As customizações serão solicitadas via e-mail e a CONTRATADA apresentará plano contendo o prazo para execução, as etapas de trabalho e número de horas estimado, o qual será submetido à aprovação.

4.5.3.1. Após finalizado, a CONTRADA emitirá Nota Fiscal referente às horas executadas.

4.5.4. Os serviços de customização e consultoria técnica, quando autorizados, deverão ser realizados pela CONTRATADA conforme calendário de entregas acordado entre as partes.

4.5.5. Os serviços de customização e consultoria técnica, quando necessário e mediante autorização da equipe técnica da CONTRATANTE, deverão ser realizados pela CONTRATADA de forma paralela à fase de implantação, pela sua equipe de desenvolvimento, a fim de evitar atrasos no cronograma de cada fase

do projeto, a ser detalhado no momento da assinatura do contrato, respeitando os prazos do cronograma físico-financeiro.

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

4.6. DA LICENÇA DE USO DO SISTEMA DE INFORMAÇÃO PARA GESTÃO DA SAÚDE

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

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

4.6.3. Os sistemas serão instalados parceladamente conforme a necessidade da Secretaria. As implantações serão precedidas de autorização com emissão da ordem de serviço.

4.7. DA GARANTIA

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

4.8. DOS SERVIÇOS DE MANUTENÇÃO E SUPORTE TÉCNICO

4.8.1. O serviço de manutenção corretiva, adaptativa e evolutiva relacionado na definição do objeto é obrigação da empresa fornecedora do software visando manter o Sistema de Informação para Gestão da Saúde em perfeito funcionamento.

4.9. DA COMISSÃO ESPECIAL DE AVALIAÇÃO

4.9.1. A Secretaria Municipal de Saúde designará através de portaria, um grupo de servidores que acompanharão a execução dos serviços, prestando todas as informações necessárias e mediando os contatos com os usuários, visando assim garantir as características técnicas exigidas para o perfeito funcionamento do produto instalado.

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

4.9.3. A Comissão Especial de Avaliação se reunirá periodicamente para fiscalização e aprovação dos serviços prestados pela CONTRATADA, de acordo com as especificações contidas neste edital.

4.10. DA GESTÃO DO PROJETO

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

4.11. DO TERMO DE ACEITE FINAL

4.11.1. Caberá a Comissão Especial de Avaliação a emissão do termo de aceite final, atestando a entrega completa de todos os serviços do presente objeto nos termos deste edital.

4.12. DO TESTE DE CONFORMIDADE

4.12.1. A administração pública municipal, através da Comissão Especial de Avaliação, realizará com a empresa licitante vencedora, antes da assinatura do contrato, um teste de conformidade do sistema,

com o objetivo de comprovar se o sistema realmente dispõe dos requisitos mínimos obrigatórios, presentes no termo de referência.

4.12.2. O vencedor do certame deverá apresentar-se na Secretaria Municipal de Saúde, Xxx Xxxxxxx Xxxxxx, xx 000, Xxxxxx, na cidade de Joaçaba/SC, em até 5 (cinco) dias úteis após a divulgação do resultado em que for declarado proponente vencedor do certame para o teste de conformidade do objeto deste edital, devendo apresentar o sistema de forma online, em uma base de dados que simule as condições reais de uso, a fim de comprovar o atendimento dos requisitos mínimos obrigatórios requeridos neste Termo de Referência.

4.12.3. A Comissão Especial de Avaliação se reserva o direito de avaliar, todos os requisitos obrigatórios ou somente aqueles que julgarem necessários, dentre todos apresentados no termo de referência. Ressalta-se ainda que, aqueles requisitos obrigatórios que dependem da integração com sistemas em uso na prefeitura não serão avaliados pela comissão, pois o funcionamento dos mesmos depende de algumas customizações da solução por parte da licitante durante a fase de implantação.

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

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

4.13. DAS CONDIÇÕES DE PAGAMENTO

4.13.1. Os pagamentos serão feitos em moeda nacional, de acordo com os Módulos do Sistema liberados para implantação, e será efetuado até o 5º dia útil contado da apresentação da nota/fatura devidamente atestada, com as cautelas e formalidades preconizadas pelos artigos 73 e 74 da Lei nº 8.666/93 e suas alterações. As notas fiscais a serem entregues, deverão informar o número de empenho, descrição conforme empenho, número do processo de licitação, e, dados bancários para realização do pagamento ao fornecedor.

4.13.2. Será emitida a nota fiscal referente a implantação e cessão de direitos de uso em até 15 dias após a após a implantação do sistema, desde que Contenha Ordem de Serviço autorizando a implantação.

4.13.3. Serão emitidas notas fiscais referentes à manutenção/locação de cada Modulo, mensalmente, trinta dias a partir da implantação do modulo, desde que contenha Ordem de Serviço liberando o serviço de implantação do modulo.

4.13.4. Horas de treinamentos adicionais e de customização serão pagos no quinto dia do mês subsequente a prestação de serviço e quanto solicitado por escrito pela Secretaria de Saúde e com a comprovação do serviço realizado, em nota fiscal emita de forma individual em relação aos outros serviços.

4.13.5. O pagamento será suspenso se observado algum descumprimento das obrigações assumidas pelo licitante, no que se refere à habilitação, qualificação e demais exigências especificadas neste processo licitatório, em virtude de penalidade ou inadimplência, sem que isto gere direito ao pleito de reajustamento de preço ou correção monetária.

4.13.6. Nos pagamentos realizados após a data de vencimento, incidirá correção monetária pela variação mensal do INPC, “pro-rata-die”, nas condições e periodicidade estabelecida pela legislação aplicável.

4.13.7. A contratação dos módulos se dará gradativamente e somente após a emissão da ordem de serviço emitida pelo contratante.

4.14. FISCALIZAÇÃO DO CONTRATO

4.14.1. A responsabilidade de fiscalizar o contrato advindo do Processo Licitatório em questão ficará a cargo dos servidores Xxxxxxx Xxxxxxxxx, Xxxxx Xxxx Xxxxxxxx, Xxx Xxxxx Xxxxxx, Xxxxxx Xxxxxxx Xxxxxxxx e Xxxxx Xxxxxxxxxx Xxxxxxxx Xxxxxxxx.

4.15. DOTAÇÃO ORÇAMENTÁRIA

4.15.1. As despesas provenientes da execução do referido Processo correrão por conta da seguinte Dotação Orçamentária:

2.121 – BLGES – BLOCO DE GESTÃO DO SUS

9-3.3.90.00.00.00.00.00.00.0.02.0002 – Aplicações Diretas

2.122 – BLATB – BLOCO DE ATENÇÃO BÁSICA

12-3.3.90.00.00.00.00.00.00.01.02.0002 – Aplicações Diretas

2.123 – BLVGS – BLOCO DE VIGILÂNICA EM SAÚDE

17-3.3.90.00.00.00.00.00.00.01.02.0002 – Aplicações Diretas

2.123 – BLMAC – BLOCO DE ATENÇÃO DE MÉDIA COMPLEXIDADE 23-3.3.90.00.00.00.00.00.00.01.0002 – Aplicações Diretas

5. DESCRIÇÃO TÉCNICA

5.1. AMBIENTE TECNOLÓGICO

5.1.1. A solução ofertada deverá rodar sobre o ambiente tecnológico existente na CONTRATADA. Os sistemas gerenciadores de bancos de dados, servidores web, sistemas operacionais ou aplicações que se façam necessárias para o pleno funcionamento da ferramenta, devem ser devidamente licenciados em nome da CONTRATANTE, quando aplicável. Não serão admitidas licenças parciais ou que apresentem qualquer tipo de restrição de funcionalidade em relação a versão mais completa do produto licenciado.

5.1.2. O software aplicativo deverá obrigatoriamente apresentar todos os módulos desenvolvidos com tecnologia WEB, podendo rodar em ambiente operacional Windows ou Linux, tanto para o servidor da aplicação quanto para o servidor de banco de dados.

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

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

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

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

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

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

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

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

5.1.11. O sistema deve oferecer total segurança contra a violação dos dados ou acessos indevidos às informações:

a. Não permitir o acesso ao banco de dados com ferramentas de terceiros utilizando o usuário e senha do sistema;

b. Não permitir a alteração de dados por outro meio que não seja o sistema ou suas ferramentas.

5.1.12. As atualizações deverão ser aplicadas a todos os usuários de forma automática.

5.1.13. O sistema deve atender as legislações federais, estaduais, municipais, estatutos, bem como resoluções e normativas de órgãos da Prefeitura, permitindo a criação de novas funcionalidades conforme orientação e solicitações da CONTRATANTE.

5.1.14. O sistema deve realizar todas as integrações sistêmicas e ministeriais, conforme o Ministério da Saúde orienta.

5.1.15. O sistema deverá ter a possibilidade de integração com outras tecnologias, plataformas e suportes, que forem entendidas como necessárias durante a vigência do contrato, sempre levando em consideração as condições de plataforma, viabilidade e plausabilidade.

5.1.16. Integrações e sincronizações: O software deverá possibilitar integração/sincronização/importação de dados com os sistemas que o município achar necessário para eficiência e eficácia do uso do sistema, não se limitando apenas a sincronização com webservices integração com sistemas locais mais ainda importação de planilhas ou arquivos que o município achar necessário, não impondo custos adicionais ao município, o sistema deve realizar sincronização com o sistema e-SUS para importação de prontuários, receituários, encaminhamentos, integração com a plataforma CADWEB para importação de cadastros e atualização de informações de cadastros; deve realizar o envio por meio de webservice dos dados do sistema Hórus, BNAFAR, BNDASAF e suas evoluções quando necessário, deve permitir a importação, migração, com as tecnologias atualizadas disponibilizadas pelo departamento de informática do ministério da saúde.

5.1.17. O sistema locado deverá realizar pareamento/sincronização com o sistema e-SUS AB, possibilitando a emissão relatórios complementares, extração de informações para composição do B.I. (Business Intelligence) que deverá ser fornecido pela empresa VENCEDORA, além de permitir a sincronização de cadastros e compartilhamento de informações de atendimentos em tempo real possibilitando a homogeneidade da base de cadastros, reunindo informações em um só sistema para fins de gestão e atendimento, permitindo que o município solicite informações que achar necessárias dentro da plausabilidade para realização da gestão da saúde; Esta funcionalidade se da para realização da comparação de produção executada e enviada, ou seja, para que se possa ter o acompanhamento, homogeneidade de base, comparação entre os dados produzidos no sistema locado e os de fato enviado para o sistema e-SUS (ferramenta qual realiza a transmissão da produção para o ministério da saúde).

5.1.18. A empresa deverá dispor de Data Center com Alta Performance e Balanceamento de Carga - 7/24 -, que detenha certificação reconhecida pelos órgãos competentes para todos os critérios de Segurança Física (fogo, falta de energia, antifurto) e Segurança Tecnológica.

5.1.19. O acesso ao sistema deverá ser realizado mediante conexões SSL, com Certificação Segura e Criptografada do Transporte das Informações – HTTPS.

5.1.20. A empresa deverá manter sistemas para gerenciamento de cópias de segurança (backups), sendo backup minimamente diários.

5.2. TECNOLOGIA REQUISITADA

5.2.1. O sistema deverá estar adequado para funcionar sobre a rede local da CONTRATANTE, sua intranet ou ainda através da internet (web) utilizando servidores com sistemas operacionais Windows e Linux.

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

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

5.2.4. A solução deverá possuir mecanismo de log de atividades (auditoria) que possibilitem rastrear todas as operações realizadas para cada operador do sistema através da utilização de filtros que facilitem sua utilização, mostrando obrigatoriamente quem fez, quando fez e o que fez.

5.2.5. A solução deve possuir parametrização para o local de armazenamento dos logs de utilização do sistema (auditoria), permitindo que o mesmo seja armazenado em outro banco de dados, se a CONTRATANTE assim desejar, permitindo aumentar a eficiência do processo de leitura e escrita no banco de dados onde serão armazenados os dados a serem gerenciados pela aplicação ofertada.

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

5.3. REQUISITOS MINIMOS OBRIGATÓRIOS DO SOFTWARE

5.3.1. O Sistema de Informação para Gestão de Saúde ofertada deve ser desenvolvido para rodar sobre servidores de páginas de internet e ser acessado através de navegadores de internet, sem a utilização

de qualquer tipo de emulador ou plug-in.

5.3.2. A solução ofertada deve ser compatível com os navegadores Mozilla Firefox, Microsoft Edge, Google Chrome, Ópera, entre outros, em suas versões atuais em toda vigência do contrato.

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

5.3.4. A empresa CONTRATADA compromete-se, quando da atualização de versões, a disponibilizar novas integrações que possam ocorrer com os Sistemas disponibilizados pelo Ministério da Saúde através do DATASUS e/ou outros órgãos, os quais atualmente ainda não possuem layout aberto e outros que forem exigidos, considerando ainda sistemas posteriores a assinatura do contrato com layout aberto, sem qualquer ônus ao município.

5.3.5. A solução ofertada deverá estar em conformidade no mínimo com a versão 4.0 do E-SUS ou a atual do momento da implantação.

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

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

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

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

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

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

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

5.3.13. Permitir auditoria automática das operações efetuadas no sistema, através de logs de acesso, de modo que seja possível identificar claramente as atividades de consulta, inclusão, alteração e exclusão de qualquer informação, inclusive aquelas relativas a administração da solução, de qualquer usuário, indistintamente, inclusive administradores, com exceção das informações relativas ao prontuário conforme determinado pelas regras da SBIS e CFM para homologação de sistemas de prontuário eletrônico. O log registrado deve permitir a identificação completa do dado que foi acessado/atualizado.

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

5.3.15. A solução deve possuir mecanismo ou funcionalidade que permita a gravação dos relatórios gerados em arquivos compatíveis com os formatos texto (TXT), RichTextFormat (RTF), OpenDocumentFormat (ODT/ODS), XML (ExtensibleMarkupLanguage) e em formato PDF (PortableDocumentFormat), permitindo a disponibilização para usuários finais, bem como impressão dos dados consultados.

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

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

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

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

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

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

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

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

5.3.24. A solução ofertada deve possuir mecanismo de assinatura digital de registro eletrônico em saúde em conformidade com os padrões de assinatura digital determinados pela Legislação pertinente.

5.3.25. O conjunto de softwares que compõem a solução (sistema operacional, banco de dados, servidor de aplicação, etc.) deve estar todos em suas versões mais atuais ou, no mínimo, em uma versão ainda suportada pelo fabricante/desenvolvedor.

5.3.26. O sistema deverá permitir a total integração com o sistema E-SUS PEC, possibilitando o envio diário das informações registradas em prontuário eletrônico pelas unidades de saúde.

5.4. CADASTROS E FUNCIONALIDADES GERAIS MÍNIMAS

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

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

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

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

5.4.5. Permitir cadastro e consulta de empresas mantenedoras.

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

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

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

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

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

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

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

5.4.13. Possuir cadastro de Nacionalidades.

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

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

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

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

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

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

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

5.4.16.5. Possuir campos para informar os seguintes dados da empresa onde trabalha: Nome da Empresa, Número de Registro Funcional, Ocupação e Horário de Trabalho.

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

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

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

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

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

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

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

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

5.4.16.14. Possuir funcionalidade para registro das deficiências do paciente.

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

5.4.16.16. Possuir funcionalidade para armazenamento da foto do paciente.

5.4.16.17. Possuir funcionalidade para armazenamento de dados sociodemográficos do paciente conforme ficha de cadastro individual do e-SUS.

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

5.4.18. Possuir funcionalidade para indicar informações sobre ‘Morador de Rua’ quando aplicado, conforme ficha de cadastro individual do e-SUS.

5.4.19. Possuir mecanismo ou funcionalidade que permita listar todos os homônimos já processados.

5.4.20. Possuir integração com webservice do CNS, permitindo aos operadores pesquisar e importar os dados pessoas já cadastradas no Cartão Nacional de Saúde.

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

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

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

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

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

5.4.26. Possuir cadastro de tipos de deficiências.

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

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

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

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

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

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

5.5. MÓDULO DE ENVIO DE SMS / E-MAIL (funcionalidades mínimas exigidas)

5.5.1. O sistema deverá possibilitar o envio individualizado de SMS - Short Message Service, compondo mensagem e informando os destinatários.

5.5.2. O sistema deverá possibilitar o envio individualizado de comunicações pelo aplicativo Whatsapp, compondo mensagem e informando os destinatários.

5.5.3. Permitir a integração com pelo menos dois diferentes servidores de SMS – Short Message Service, além do Whatsapp, para envio de mensagens automáticas, possibilitando a composição da mensagem, programação do horário de envio para as seguintes funcionalidades:

a. Notificação de agendamentos (consultas/exames), transporte e autorizações (consultas/exames);

b. Notificação para retirada de resultado de exames;

c. Notificação de vencimento de produtos do estoque para destinatários especificados;

d. Notificação de notificações de ocorrência de CID - Classificação Internacional de Doenças - para destinatários especificados;

e. Notificação para retirada de resultado de exames;

f. Notificação de vencimento de receitas de medicamentos com necessidade de renovação.

5.6. CONTROLE DE ESTOQUES/FARMÁCIA (Funcionalidades mínimas exigidas)

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

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

5.6.3. Possuir cadastro de fabricantes.

5.6.4. Possuir cadastro de centros de custo.

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

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

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

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

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

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

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

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

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

5.6.14. Deve possuir mecanismo para controle patrimonial contendo os seguintes campos:

⮚ Número do patrimônio;

⮚ Data da garantia;

⮚ Número da nota fiscal;

⮚ Material;

⮚ Fornecedores;

⮚ Unidade de Saúde;

⮚ Centro de Custo;

⮚ Localização;

⮚ Indicação se o mesmo foi baixado;

⮚ Data da baixa e observações.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.6.48. Possuir mecanismo ou funcionalidade que permita importar o arquivo de produtos do Hórus em formato CSV.

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

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

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

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

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

5.7. REGULAÇÃO / AGENDAMENTO DE CONSULTAS (funcionalidades mínimas exigidas)

5.7.1. Deverá possuir interface 100% web e a comunicação que se estabelece entre o navegador e o servidor de aplicação deve ser segura, utilizar HTTPS para cifrar a comunicação e assinar as requisições de modo a evitar ataques a segurança do servidor de aplicações.

5.7.2. Permitir o cadastramento de feriados e dias facultativos, tendo como funcionalidade garantir que não sejam feitos agendamentos e consultas neste dia.

5.7.3. Montagens das agendas obedecendo as regras do gestor:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.7.19. Deve possuir cadastros de causas de atendimento.

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

5.7.21. Deve possuir mecanismo para criação de fichas de anamnese permitindo especificar em quais CBO’s a mesma será utilizada. O mecanismo de criação de fichas deve permitir que sejam criados subtítulos dentro de cada anamnese aos quais ficaram atreladas todas as perguntas constantes na anamnese cujas respostas poderão ser dos tipos alfanumérico, data, numérico ou de múltipla escolha, neste caso

determinando quais são as opções disponíveis para seleção. Deve ainda possuir campo que permita sua desativação, se sua resposta é obrigatória, a ordem da pergunta na anamnese e um campo para inserção de informações de ajuda, para o momento do preenchimento da mesma.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.8. REGULAÇÃO / AGENDAMENTO DE EXAMES (funcionalidades mínimas exigidas):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.9. CONTROLE DE TRANSPORTES (funcionalidades mínimas exigidas):

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

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

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

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

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

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

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

5.9.8. Ainda no lançamento da viagem, deve permitir que sejam atrelados a cada viagem os pacientes e acompanhantes com seus devidos locais de saída, locais de destino, telefones, documentos, tipo da

viagem (ida, ida e volta), vagas consumidas na ida, vagas consumidas na volta, acompanhantes, horário da saída, horário da chegada, data do aviso ao paciente, horário do aviso e observação.

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

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

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

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

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

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

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

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

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

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

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

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

5.10. TFD (funcionalidades mínimas exigidas):

5.10.1. Deverá possuir interface de operação 100% WEB e a comunicação entre o navegador e o servidor de aplicação deve ser segura, utilizando HTTPS para cifrar a comunicação e assinar as requisições de modo a evitar ataques a segurança do servidor de aplicações.

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

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

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

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

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

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

5.11. ACOLHIMENTO / ATENDIMENTO (funcionalidades mínimas exigidas):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.12. PRONTUÁRIO ELETRÔNICO MULTIPROFISSIONAL (funcionalidades mínimas exigidas):

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

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

5.12.3. Deve possuir lista de problemas do paciente.

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

5.12.5. Deve permitir registrar:

a. Descrição do problema;

b. Codificação (CID-10 ou CIAP-2);

c. Tipo (cadastrável com possibilidade de inativação);

d. Estado do problema;

e. Observações;

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

g. Data Final do problema.

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

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

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

5.12.9. Deve possuir o registro de anamnese conforme segue:

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

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

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

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

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

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

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

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

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

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

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

5.12.19. Dados gerais do exame contendo:

a. Campo texto para descrição do Aspecto;

b. Campo texto para descrição da Postura corporal;

c. Campo texto para descrição da Cor da pele;

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

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

a. Peso e unidade de medida;

b. Estatura e unidade de medida;

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

d. Quadril e unidade de medida;

e. Cintura e unidade de medida;

f. Circunferência Braquial e unidade de medida;

g. Prega Cutânea e Unidade de Medida;

h. Estado Nutricional.

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

a. Temperatura e unidade de medida;

b. Pressão arterial e unidade de medida;

c. Frequência respiratória e unidade de medida;

d. Frequência cardíaca e unidade de medida;

e. Pulsação e unidade de medida;

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

g. Saturação O2 e unidade de medida;

h. Saturação CO2 e unidade de medida.

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

a. Cabeça e pescoço;

b. Boca, nariz, faringe e laringe;

c. Olhos;

d. Sistema auditivo;

e. Sistema nervoso;

f. Sistema respiratório;

g. Sistema circulatório/vascular;

h. Sistema digestório;

i. Sistema gênito-urinário;

j. Pele, mucosas e anexos;

k. Sistema músculo-esquelético;

l. Sistema endócrino;

m. Saúde mental.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.12.70. Deve permitir informar data fracionada do desfecho.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.12.88. O sistema deve ter vinculação e integração com o sistema E-SUS AB, realizando o envio das informações diariamente.

5.13. PRONTUÁRIO ODONTOLÓGICO (funcionalidades mínimas exigidas):

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

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

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

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

5.13.5. Deve disponibilizar ao odontólogo todas as funcionalidades do prontuário do paciente.

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

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

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

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

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

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

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

5.13.13. O sistema deve ter vinculação e integração com o sistema E-SUS AB, realizando o envio das informações diariamente.

5.14. LISTA DE ESPERA (funcionalidades mínimas exigidas):

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

5.14.2. Deve possuir cadastro de Tipos de Lista de Espera.

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

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

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

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

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

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

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

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

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

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

5.15. AÇÕES PROGRAMÁTICAS EM SAÚDE (funcionalidades mínimas exigidas):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.16. MEDICAMENTO JUDICIAL (funcionalidades mínimas exigidas):

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

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

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

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

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

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

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

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

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

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

5.17. BENEFÍCIOS (funcionalidades mínimas exigidas):

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

5.17.2. Deve possuir cadastro de locais para encaminhamentos.

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

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

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

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

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

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

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

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

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

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

5.18. FATURAMENTO DA PRODUÇÃO AMBULATORIAL (funcionalidades mínimas exigidas):

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

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

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

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

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

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

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

5.19. IMUNIZAÇÕES / VACINAS (funcionalidades mínimas exigidas):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.19.25. Deve possuir mecanismo de agendamento para aplicação de imunizantes em pacientes atendidos.

5.20. SAÚDE DA FAMÍLIA (funcionalidades mínimas exigidas):

5.20.1. O software deve realizar a emissão de relatórios para monitoramento dos indicadores do Programa Previne Brasil.

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

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

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

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

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

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

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

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

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

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

5.20.12. Possuir indicador gráfico de Gestação em Menores de 20 anos de Idade, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.20.27. Indicador da Taxa de Hospitalizações Psiquiátricas em Pessoas com Mais de 15 Anos por 1000, contendo média histórica, valor por ano, e sua classificação segundo a OMS, para o município, seus segmentos, áreas e micro áreas.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.21. PAINEL MULTIMÍDIA (funcionalidades mínimas exigidas):

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

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

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

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

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

5.22. BUSINESS INTELLIGENCE (funcionalidades mínimas exigidas):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.22.16. Deve possuir ferramenta específica para realização de análise de desempenho dos modelos de informação.

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

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

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

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

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

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

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

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

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

5.23. VIGILÂNCIA SANITÁRIA (funcionalidades mínimas exigidas):

5.23.1. O Sistema deverá permitir o cadastro, edição, consulta e exclusão de um questionário. O formulário para cadastro do questionário deverá conter no mínimo os seguintes campos:

a. Nome do Questionário;

b. Tipo de Estabelecimento;

c. Subtipo de estabelecimento (Atividade exercida);

d. Ativo/Inativo;

e. Tipo de Prestador;

f. Nível de Atenção;

g. Grau Complexidade.

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

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

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

a. Descrição;

b. Tipo de Comprovação;

c. Nível;

d. Peso;

e. Pontos;

f. Referência;

g. Ativa/Inativa;

h. Tipo de Pergunta (Sim, Não, NA/ Múltipla Escolha / Única Escolha);

i. Comentário.

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

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

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

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

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

5.23.6. Os comunicados devem possuir no mínimo três níveis:

a. Em aberto – Recebidos, mas ainda sem tramitação;

b. Em Tramitação - Estão tramitando entre as pessoas envolvidas;

c. Arquivados - Finalizados e que não podem mais ser alterados ou tramitados.

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

a. Titulo;

b. Texto (com possibilidade de formatação HTML);

c. Criticidade (Baixo/verde, Médio/amarelo, Alto/vermelho);

d. Data da tramitação (automática);

e. Usuários remetente (automático);

f. Visualizado por;

g. Data de expiração;

h. Opção de Notificação ao expirar (Não Notificar, Notificar o Remetente, Notificar o Destinatário, Notificar o Superior do Destinatário, Notificar Remetente Destinatário, Notificar a Todos);

i. Anexos.

5.23.8. O Sistema deverá apresentar um formulário para a inclusão de reclamações. O formulário deverá possuir no mínimo os seguintes campos:

a. Título;

b. Data da Reclamação;

c. Descrição;

d. Tipo da reclamação;

e. Estabelecimento;

f. Anexos.

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

a. Título;

b. Data da reclamação;

c. Descrição;

d. Tipo da reclamação;

e. Estabelecimento;

f. Usuário;

g. Anexos.

5.23.10. O Sistema deverá permitir a pesquisa de reclamações com a utilização de no mínimo os seguintes filtros:

a. Título;

b. Faixa para data da reclamação;

c. Tipo da reclamação;

d. Estabelecimento;

e. Usuário.

5.23.11. O sistema deverá permitir a elaboração de documento de ATAS de reuniões contendo, no mínimo, os seguintes campos:

a. Descrição da Reunião;

b. Data da Reunião;

c. Local da reunião;

d. Usuário responsável;

e. Participantes;

f. Anexos;

g. Tópicos;

h. Responsável pelo Tópico;

i. Situação do tópico;

j. Data de conclusão.

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

a. Cidade do Estabelecimento (conforme área de abrangência da fiscalização);

b. Tipo de Estabelecimento;

c. Atividade Exercida;

d. Tipo de endereço;

e. Equipamentos que possui;

f. Documentos com vigência a vencer;

g. Criados pelo Auto cadastro;

h. Tipo de Estabelecimento;

i. Tipo de Pessoa;

j. CNPJ;

k. Tipo de CNPJ;

l. Razão Social;

m. Nome Fantasia;

n. Região;

o. Status do cadastro;

p. Data Inicial do Cadastro;

q. Data Final do Cadastro;

r. Tipo de Pendência.

5.23.13. O Sistema deverá apresentar o resultado da consulta em um mapa georreferenciado, com todos os endereços dos estabelecimentos resultantes da pesquisa.

5.23.14. O Sistema deverá mostrar um indicador para cada endereço de Estabelecimento, o qual, quando clicado deverá exibir no mínimo as seguintes informações:

a. Nome do Estabelecimento;

b. Endereço Eletrônico;

c. CNAE do Estabelecimento;

d. Tipo de Estabelecimento;

e. Subtipo de Estabelecimento;

f. Endereço completo;

g. Telefone e Fax;

h. Nome e E-mail da pessoa de contato.

5.23.15. O Sistema deverá também apresentar o resultado da consulta em uma tabela, com todos os estabelecimentos resultantes da pesquisa. A tabela deverá conter no mínimo os seguintes campos:

a. Alvará Razão Social;

b. Nome Fantasia;

c. CPF/CNPJ;

d. CNAE;

e. Solicitação Estabelecimento;

f. Cidade;

g. UF;

h. CNPJ Criado em;

i. Anexos;

j. Documentos.

5.23.16. O Sistema deverá possibilitar o registro e visualização de todas as operações de criação, edição e exclusão realizadas pelos usuários. As pesquisas poderão utilizar no mínimo filtros por usuário ou por tipo de ação.

5.23.17. Cadastro da estrutura de pastas: O Sistema deverá permitir o cadastro, edição e exclusão da estrutura de pastas, com a definição de no mínimo os seguintes campos:

a. Nome;

b. Pasta pai;

c. Nível mínimo de quem visualiza a pasta.

5.23.18. O Sistema deverá permitir que um usuário com perfil de administrador defina os valores dos parâmetros que serão utilizados para o agendamento automático, com no mínimo as seguintes informações:

a. Tempo de fiscalização por metragem;

b. Tempos de deslocamento entre as praças;

c. Quantidade de fiscais.

5.23.19. O Sistema deverá permitir que um usuário com perfil de administrador possa cadastrar a relação de documentos necessárias baseada no tipo de estabelecimento. Deverá definir se o documento é obrigatório ou não.

5.23.20. O Sistema deverá permitir que o administrador faça a manutenção das tabelas de dados do Sistema.

5.23.21. O Sistema deverá permitir que o administrador faça a criação das contas de usuários para os membros da vigilância sanitária e estabelecimentos.

5.23.22. O sistema deverá possibilitar que qualquer usuário seja capaz de acessá-lo através da inserção do tipo, identificação e senha do usuário através de uma página de entrada.

5.23.23. O sistema deverá possuir procedimento para recuperação automática da senha caso um usuário a tenha esquecido.

5.23.24. O sistema deverá restringir o acesso do usuário às suas funcionalidades de acordo com seus papéis.

5.23.25. O sistema deverá permitir que o administrador atribua os papéis dos usuários.

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

a. Solicitação de Alvará Sanitário;

b. Solicitação de Baixa de Alvará Sanitário;

c. Solicitação de Revalidação de Alvará Sanitário;

d. Solicitação de Baixa de Responsável Técnico;

e. Solicitação de Inclusão de Responsável Técnico;

f. Solicitação de Licença de Transporte;

g. Solicitação de Abertura e fechamento de livros Psicotrópicos;

h. Solicitação de 2ª Via de Documentos e Certidões.

5.23.27. O sistema deverá disponibilizar uma forma de acompanhamento e liberação de solicitações por parte da vigilância bem como o acompanhamento das solicitações por parte do estabelecimento.

5.23.28. O sistema deverá disponibilizar uma forma de emissão de documentos (Alvará Sanitário, auto de infração, auto de intimação, parecer pós inspeção e gerar DAM/DARE).

5.23.29. O sistema deverá disponibilizar um método o qual cruzamento de informações de acordo com a necessidade da vigilância deverá gerar indicadores ou relatórios os quais poderão contribuir para a otimização da produtividade da Vigilância.

5.23.30. O sistema deverá possuir um local o qual os seguintes dados da própria vigilância podem ser exibidos e editados:

a. Informações Cadastrais;

b. Razão Social;

c. Instituição / Órgão Superior;

d. Secretário Municipal de Saúde;

e. Responsável de Vigilância Sanitária;

f. Telefone;

g. Celular;

h. E-mail;

i. Dados Bancários;

j. Denominação;

k. Tipo da Conta Bancária;

l. CPF/CNPJ;

m. Banco;

n. Agência;

o. Digito da Agência;

p. Conta Corrente;

q. Digito da Conta Corrente;

r. Carteira;

s. Tipo Modalidade Carteira;

t. Modalidade Carteira;

u. Dados de Endereçamento;

v. CEP;

w. Logradouro;

x. Complemento;

y. Bairro;

z. Estado; aa.Cidade; bb.Dados de Fiscais; cc. Nome;

dd.E-mail; ee.Login; ff. CPF;

gg.Número Portaria; hh.Nascimento;

ii. Telefone;

jj. Horário de Trabalho;

kk. Especialidades: Opção para selecionar e direcionar as inspeções do fiscal somente para os estabelecimentos que possuem as atividades que atende.

5.23.31. Funcionalidade que permite a vigilância sanitária informar quais as atividades são de sua responsabilidade fiscalizar e quais são do Estado, permitindo que o sistema automaticamente filtre as solicitações dos estabelecimentos. O cadastro e pesquisa devem conter:

a. Código da Atividade CNAE;

b. Classe da Atividade;

c. Subclasse da atividade;

d. Pactuação: Município ou Estado.

5.23.32. Configuração da Unidade Financeira Municipal: Cadastro do valor da UFM para a geração do boleto de acordo com a quantidade de UFM das Atividades do Estabelecimento, contendo:

a. Valor UFM;

b. Taxa por Solicitação;

c. UFM x Atividade;

d. Valor Total R$.

5.23.33. Configuração das informações das guias de pagamento contendo:

a. Instruções da Guia de pagamento;

b. Local de Pagamento;

c. Tipo de Documento.

5.23.34. Opções de cadastro de usuário contador que deseja gerenciar um ou mais de seus estabelecimentos, contendo:

a. Tipo de Pessoa: Física ou Jurídica:

i. CPF/CNPJ;

ii. Inscrição Estadual;

iii. Inscrição Municipal;

iv. Razão Social;

v. Nome Fantasia;

vi. E-mail;

vii. Telefone;

viii. Celular;

ix. Site;

x. Conselho Regional de Contabilidade;

xi. Nº CRC.

b. Dados dos Profissionais:

i. Cargo;

ii. Nome Completo;

iii. CPF;

iv. Conselho Regional de Contabilidade;

v. Nº CRC;

vi. Telefone;

vii. Endereço do Estabelecimento;

viii. CEP;

ix. Logradouro;

x. Número;

xi. Complemento;

xii. Bairro;

xiii. Estado;

xiv. Cidade;

xv. Localização.

c. Localização em Mapa:

i. Latitude;

ii. Longitude.

d. Cadastro de Estabelecimentos;

e. Vinculação de Estabelecimento.

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

a. Gerar Solicitações;

b. Acompanhar andamento das solicitações.

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

a. CNPJ;

b. Inscrição Estadual;

c. Inscrição municipal;

d. CPF;

e. RG;

f. Data Nascimento;

g. CNAE;

h. Razão Social;

i. Nome Fantasia;

j. Telefone;

k. Endereço eletrônico;

l. E-mail Principal;

m. Nome da Pessoa de Contato;

n. Função da Pessoa de Contato;

o. E-mail da Pessoa do Contato;

p. Telefone da Pessoa de Contato;

q. Tipo de Endereço;

r. Logradouro;

s. Número;

t. Complemento;

u. Bairro;

v. CEP;

w. UF (Lista de Estados);

x. Localização;

y. Cidade (Lista baseada na UF selecionada).

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

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

b. Descrição do Documento;

c. Número;

d. Data de Expedição;

e. Data Início da Vigência;

f. Data Fim da Vigência;

g. Arquivo anexado;

h. Órgão emissor do documento.

5.23.38. Associado à lista de documentos necessários, a aplicação deverá permitir o cadastro, edição e exclusão das informações para cada documento, inclusive com o carregamento de arquivos em formato PDF DOC, ou de imagem (JPEG, TIFF, PNG, BMP), com aviso de limite máximo de 5 MB.

5.23.39. A solução ofertada deve permitir que sejam pesquisados os documentos com utilização de filtros com, no mínimo, os seguintes campos:

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

b. Faixa da Data de Início da Vigência;

c. Faixa da Data de Final da Vigência.

5.23.40. A aplicação deve possuir mecanismo para os administradores do sistema possam cadastrar a lista de documentos necessários para cada tipo de estabelecimento, identificando quando determinado documento é ou não obrigatório.

5.23.41. A cada estabelecimento, a aplicação deve permitir que sejam cadastrados, editados e excluídos equipamentos, com, no mínimo, as seguintes informações para cada equipamento:

a. Tipo de Equipamento;

b. Nome do Equipamento;

c. Modelo;

d. Descrição;

e. Ano de Aquisição;

f. Capacidade Total Efetiva;

g. Empresa Manutenção;

h. Última Manutenção;

i. Próxima Vistoria Prevista;

j. Ano de Fabricação.

5.23.42. A solução deverá enviar um e-mail ao estabelecimento quando algum dado ou documento tenha sido rejeitado.

5.23.43. A aplicação deve permitir que os estabelecimentos preencham formulários de solicitação de alvará com, no mínimo, as seguintes informações:

a. Número do protocolo;

b. Identificação do estabelecimento.

5.23.44. O sistema deve permitir que os próprios estabelecimentos emitam suas guias de pagamento de alvarás.

5.23.45. A solução deve possuir mecanismo ou funcionalidade que permita a integração das guias pagas através da importação do arquivo padrão de retorno bancário.

5.23.46. O aplicativo deve possuir funcionalidade para agendar automaticamente as fiscalizações baseado em regras que considerem:

a. Tempo de deslocamento entre as fiscalizações;

b. Histórico do fiscal.

5.23.47. A aplicação deve possuir mecanismo para o agendamento manual de eventos com, no mínimo, as seguintes informações:

a. Título;

b. Descrição;

c. Data e hora de início;

d. Data e hora de término;

e. Endereço;

f. Tipo de compromisso;

g. Arquivos anexados (opcional);

h. Fiscais;

i. Veículo;

j. Motorista;

k. Estabelecimento.

5.23.48. O Sistema deverá possibilitar a visualização dos compromissos agendados, em formato de calendário, com visualizações em formato diário, semanal e mensal.

5.23.49. A solução deve possuir mecanismo que permita a consulta de todas as inspeções criadas pelos usuários do sistema para estabelecimentos vinculados a uma determinada área de fiscalização.

5.23.50. A aplicação deve permitir que os estabelecimentos possam acessar o sistema e consultar todas as inspeções atreladas ao estabelecimento.

5.23.51. A solução deverá apresentar listagens das avaliações cadastradas com, no mínimo, as seguintes informações:

a. Número;

b. Data de início;

c. Data de finalização;

d. Avaliador;

e. Estabelecimento;

f. Questionário.

5.23.52. A aplicação deve possuir funcionalidade para finalização de avaliações, obrigando o operador a alimentar, pelo menos, as seguintes informações:

a. Data de Finalização;

b. Observações;

c. Opção se a avaliação será usada como Avaliação final.

5.23.53. A solução deve possuir aplicativo para mobilidade para auxiliar nas inspeções com, no mínimo, as seguintes funcionalidades:

a. Consulta de inspeções disponíveis no sistema online;

b. Importar as inspeções para dispositivo móvel, permitindo seu acesso offline;

c. Preenchimento dos questionários da inspeção;

d. Geração de Autos de intimação automático in loco;

e. Atualização da base de dados online, atualizando o sistema com as informações das inspeções realizadas a partir do dispositivo móvel.

5.24. VIGILÂNCIA EPIDEMIOLÓGICA (funcionalidades mínimas exigidas):

5.24.1. Possuir funcionalidade ou mecanismo para criação das fichas de investigação da vigilância epidemiológica contendo descrição, CID’s 10 compatíveis.

5.24.2. Deve possuir mecanismo para cadastramento das perguntas que irão compor as fichas de investigação de cada notificação.

5.24.3. Deve possuir mecanismo ou funcionalidade que permita a criação das perguntas que que compões cada ficha de investigação contendo:

a. campo para o questionamento a ser realizado;

b. tipo da resposta a ser aceito para cada pergunta podendo variar entre campos descritivos, numéricos, campos para datas e múltipla escolha, neste caso permitindo que sejam informadas as opções para

cada pergunta, assim como a seleção de um ou mais itens de acordo com a necessidade no momento da identificação das respostas;

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

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

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

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

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

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

5.24.5. Deve possuir funcionalidade ou mecanismo que permita que sejam listados na vigilância epidemiológica todos os CID’s relacionados nos atendimentos médicos em locais informatizados, que forem notificáveis.

5.24.6. Deve possuir mecanismo ou funcionalidade que permita o envio de emails para os responsáveis pelo setor de epidemiologia em intervalos pré-definidos, listando todos os CID’s notificáveis relacionados em atendimentos médicos nos locais informatizados.

5.25. CONSULTA GERAL (funcionalidades mínimas exigidas):

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

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

5.26. PORTAL COM INFORMAÇÕES DA SAÚDE (funcionalidades mínimas exigidas):

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

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

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

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

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

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

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

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

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

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

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

5.27. CAPTAÇÃO DE DADOS MÓVEIS (funcionalidades mínimas exigidas)

5.27.1. O aplicativo deve funcionar nos dispositivos móveis sob as plataformas ANDROID e iOS, de acordo com equipamento utilizado pela Secretaria de Saúde de Joaçaba.

5.27.2. O aplicativo deve funcionar off-line, não necessitando de internet ou outro tipo de rede para funcionamento, exceto para enviar e receber com o servidor.

5.27.3. O aplicativo deve solicitar usuário e senha para conectar-se ao servidor e para acesso ao aplicativo.

5.27.4. O aplicativo deve gerenciar a micro área de cada agente de saúde.

5.27.5. O aplicativo deve receber do servidor todos os dados cadastrais dos domicílios, famílias e seus componentes, do servidor referentes a micro área do agente de saúde que opera o dispositivo móvel.

5.27.6. O aplicativo deve alertar quando existem dados para serem sincronizados.

5.27.7. O aplicativo deve possibilitar o envio dos registros novos ou atualizados para o servidor e receber e fazer atualizações de dados mais atuais daqueles que os que o aplicativo está gerenciando.

5.27.8. O aplicativo dever ser totalmente compatível ao E-SUS.

5.27.9. O aplicativo deve estar disponível na loja virtual Google Play/App Store com download gratuito para instalação e atualização.

5.27.10. O aplicativo deve relacionar todos os domicílios que a micro área possui cadastrados.

5.27.11. O aplicativo deve possuir diversas formas de pesquisa de domicílios, tais como logradouro, bairro ou mesmo pelo nome do chefe de cada família.

5.27.12. O aplicativo deve possibilitar inclusão de novos ou atualização de dados cadastrais de cada Domicilio, no formato exigido pelo E-SUS.

5.27.13. O aplicativo deve possibilitar inclusão de novos ou atualização de dados cadastrais das famílias que o domicílio possui, tantas quantas forem em cada domicílio.

5.27.14. O aplicativo deve possibilitar inclusão de novos ou atualização de dados cadastrais de cada componente do domicílio e informar a qual família ele pertence.

5.27.15. O aplicativo deve possibilitar informar qual usuário é o chefe da família.

5.27.16. O aplicativo deve possibilitar o agente de saúde gerenciar suas visitas domiciliares, no formato E- SUS.

5.27.17. O aplicativo deve possibilitar ao agente de saúde saber quais domicílios já foram visitados por ele e qual foi a última dada da visita efetuada em cada um.

5.27.18. O aplicativo deve solicitar os dados da visita domiciliar seguindo o modelo especificado pelo E-SUS.

5.27.19. O aplicativo deve realizar as validações necessárias para manter o preenchimento dos dados com a mínima possibilidade de erros.

5.27.20. O aplicativo deve possuir tabela cadastral de todos os estados e municípios do Brasil e para essas duas tabelas, uma forma de pesquisa que faça o trabalho de auto completar, facilitando a seleção do registro desejado.

5.27.21. O aplicativo deve capturar o posicionamento das coordenadas GPS sempre que a agente de saúde iniciar uma Visita Domiciliar.

5.28. ASSINATURA DIGITAL (funcionalidades mínimas exigidas):

5.28.1. MÓDULO DE CERTIFICAÇÃO DIGITAL

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

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

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

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

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

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

5.28.1.7. Suportar os navegadores atuais do mercado.

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

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

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

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

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

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

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

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

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

5.28.1.17. A Solução deverá ser composta por um conjunto de web-services organizados da seguinte forma: 5.28.1.17.1. Componente Assinador para geração de assinatura digital em documento eletrônico; 5.28.1.17.2. Componente Verificador para verificar validade de assinatura digital em documento eletrônico; 5.28.1.17.3. Componente Carimbador para requisitar carimbo de tempo;

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

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

5.28.1.18. Componente para Assinatura Digital

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

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

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

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

5.28.1.18.4.1. Assinatura Digital com Referência Básica (AD-RB); 5.28.1.18.4.2. Assinatura Digital com Referência do Tempo (AD-RT); 5.28.1.18.4.3. Assinatura Digital com Referências para Validação (AD-RV); 5.28.1.18.4.4. Assinatura Digital com Referências Completas (AD-RC); 5.28.1.18.4.5. Assinatura Digital com Referências para Arquivamento (AD-RA).

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

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

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

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

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

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

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

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

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

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

5.28.1.18.11.1. Cifragem do resumo criptográfico (Assinatura Digital);

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

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

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

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

5.28.1.19. Componente para Carimbo do Tempo

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

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

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

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

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

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

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

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

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

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

5.28.1.20. Componente para Verificação de Assinatura Digital

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

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

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

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

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

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

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

5.28.1.20.5.3. Tipo de Política de Assinatura Utilizada; 5.28.1.20.5.4. Hash do Documento Assinado;

5.28.1.20.5.5. Dados dos Assinantes (no mínimo: nome, RG, CPF, data de nascimento, email, título de eleitor); 5.28.1.20.5.6. Dados dos Carimbos do Tempo (para as políticas que exijam carimbo: AD-RT, AD-RV, AD-RC,

AD-RA, no mínimo: data do carimbo, número serial, emissor);

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

5.28.1.20.5.8. Dados das LCRs e Cadeia de Certificados (para as políticas que exijam estas informações). 5.28.1.20.6. Deve validar o certificado digital do signatário (válido, inválido revogado, expirado) no ato da

conferência da assinatura e permitir que, para cada assinatura digital, seja visualizada a situação da verificação ou a descrição do erro caso a assinatura digital seja inválida.

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

5.28.1.21. Componente para Validação de Certificado Digital

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.28.1.21.18. Essa base de dados deve estar disponível para uso pelos demais componentes do módulo. 5.28.1.21.19. Deve permitir a consulta de LCR através do certificado que será validado, através da chave de

autoridade do certificado que emitiu a LCR e através do ponto de distribuição onde a LCR é publicada pela Autoridade Certificadora.

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

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

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

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

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

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

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

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

5.28.1.22. Componente para o Gerenciamento de Políticas de Assinatura

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

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

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

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

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

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

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

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

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

5.29. ZOONOSE com, no mínimo, as seguintes funcionalidades:

5.29.1. Dados da unidade de zoonose deve possuir mecanismos para inserir sua razão social, dados bancários e endereço.

5.29.2. Raça dos animais deve possuir mecanismos para inserir o nome da raça, anexos e fotos.

5.29.3. Espécie dos animais deve possuir mecanismos parainserir sua descrição.

5.29.4. Empresa prestadora de serviços deve possuir mecanismos para :

5.29.4.1. Inserir sua descrição;

5.29.4.2. Inserir a quantidade disponível de animais para comercialização;

5.29.4.3. Inserir o tempo de permanência;

5.29.4.4. Selecionar o grau de bem-estar dos animais;

5.29.4.5. Selecionar a classificação de risco do estabelecimento;

5.29.4.6. Escolher as espécies disponíveis para comercialização, integrando com a tela de cadastro de espécie dos animais;

5.29.4.7. Escolher as raças disponíveis para comercialização;

5.29.4.8. Habilitar ou não a liberdade nutricional (não sentir fome e sede), liberdade ambiental (ambiente com conforto), liberdade sanitária (não estar exposto à dor, ferimentos e doenças), Liberdade comportamental (expressar comportamento normal), Liberdade psicológica (não estar exposto ao medo, angústia, ansiedade, stress);

5.29.4.9. Inserir observações adicionais em todas as liberdades citadas no item acima;

5.29.4.10. Controle de microchips deve possuir mecanismos parainserir sua descrição e seu número identificador;

5.29.4.11. Procedência animal deve possuir mecanismos para inserir sua descrição;

5.29.4.12. Produto/Vacina deve possuir mecanismos para inserir sua descrição. Por exemplo: Vacina da Raiva.

5.29.4.13. Procedimento deve possuir mecanismos para inserir sua descrição, escolher o sexo do animal ao qual tal procedimento pode ser realizado e indicar a faixa etária.

5.29.5. Animal deve possuir mecanismos para:

5.29.5.1. Verificar, em uma única tela de cadastro, todas as informações do animal;

5.29.5.2. Visualizar e clicar em todos os itens do cadastro por meio de uma área acessível,

5.29.5.3. Identificar cada tipo de cadastro separadamente por cores,

5.29.5.4. Inserir o nome do animal e seu sexo;

5.29.5.5. Indicar se é castrado ou não;

5.29.5.6. Registrar o endereço de onde o animal vive;

5.29.5.7. Inserir observações diversas, como peso, pelagem, porte;

5.29.5.8. Inserir data de nascimento, número de registro.

5.29.6. Escolher sua espécie, integrando com o cadastro de espécies.

5.29.7. Escolher sua raça, integrando com o cadastro de raças.

5.29.8. Escolher o chip identificador de acordo com os chips disponíveis cadastrados no sistema.

5.29.9. Selecionar sua procedência, integrando com o cadastro de procedências.

5.29.10. Escolher sua empresa prestadora de serviço, de acordo com as empresas previamente cadastradas no sistema.

5.29.11. Inserir imagens e fotos do animal.

5.29.12. Visualizar, em forma de galeria, as imagens e fotos.

5.29.13. Inserir observações diversas acerca dos dados dos registros de exames físicos, como suas condições físicas, doenças e agravantes, nome da pessoa que realizou o exame e data de realização do exame.

5.29.14. Inserir dados diversos sobre o encaminhamento e destinação em caso de resgate.

5.29.15. Registrar os responsáveis pelo animal, inserindo seus nomes, CPFs, e-mails, telefones, indicar o representante principal, data de início do cuidado pelo animal, selecionar sua forma de aquisição e, em caso de cancelamento, inserir o seu motivo e a data de cancelamento da responsabilidade.

5.29.16. Inserir os dados das aplicações das vacinas e produtos, escolhendo a vacina/produto previamente cadastrado no sistema.

5.29.17. Inserir o responsável pelo animal, o nome da pessoa que aplicará a vacina/produto, observações adicionais e a data da aplicação.

5.29.18. Registrar os procedimentos junto do responsável, nome da pessoa que realizou o procedimento, observações adicionais e data da realização do procedimento.

5.29.19. Registrar agressões do animal em algum ser humano contendo o local da ocorrência, o nome da vítima, CPF, telefone, tratamento da vítima, data da ocorrência e as observações adicionais.

5.29.20. Registrar agressões do animal indicando o local correto no corpo humano, clicando sobre a parte do corpo e identificando por cores as lesões, o nome da vítima, data da lesão e suas observações adicionais, conforme imagem abaixo.

5.29.21. Registrar investigação de agressões determinado a data de agressão, o número SINAN, o nome do investigador, a destinação dada ao animal, o comportamento do animal, as condições do animal, os procedimentos instituídos, a evolução do agravo e suas observações adicionais.

5.29.22. Registrar vistorias zoosanitárias inserindo a data da vistoria, o nome do reclamante, o CPF, o e-mail, o telefone, o nome do reclamado junto de seu CPF, e-mail e telefone, o motivo da vistoria as recomendações e suas observações adicionais.

5.29.23. Registrar as avaliações da guarda dos responsáveis indicando o responsável pelo animal, previamente cadastrado no sistema, a data de avaliação, o grau de bem estar do animal, o diagnóstico geral da avaliação, suas observações, habilitar ou não a liberdade nutricional (não sentir fome e sede), liberdade ambiental (ambiente com conforto), liberdade sanitária (não estar exposto à dor, ferimentos e doenças), Liberdade comportamental (expressar comportamento normal), Liberdade psicológica (não estar exposto ao medo, angústia, ansiedade, stress).

5.29.24. Inserir observações adicionais em todas as liberdades citadas no item acima.

5.30. LABORATÓRIO

5.30.1. Deve ter a possibilidade de cadastro individual de cada usuário do laboratório, os bioquímicos devem ter uma assinatura digital para liberação dos resultados de exames.

5.30.2. Deve ter permissões especificas para cada usuário a ser definidas pelo responsável do técnico do laboratório.

5.30.3. Deve possuir para a cadastro do paciente alguns campos obrigatórios de preenchimento (Nome completo, data de nascimento, sexo, nome da mãe, cartão nacional do SUS, se é gestante ou não). E outros campos não obrigatórios como: CPF, nome do pai, endereço, telefone residencial, celular, trimestre de gestação).

5.30.4. Deve possuir cadastro de Procedimentos, profissionais, Setores de atendimento e UPS.

5.30.5. Deve possuir cadastro para estoque, com possibilidade inserir fornecedores e materiais.

5.30.6. Dentro do cadastro de laboratório deve ter opções de criar históricos padrões para a serem utilizados no lançamento dos resultados dos exames. E vínculo com o exame especifico que utiliza o mesmo.

5.30.7. Deve possuir cadastro de convênios.

5.30.8. Deve possuir cadastro de comarcas contendo o nome da comarca e campo para indicar se a comarca está ativa ou não.

5.30.9. Deve possuir no sistema uma aba especifica para gerenciamento de cadastros duplicados.

5.30.10. Deve possuir no comprovante de coleta, um layout totalmente editável pelo laboratório.

5.30.11. A solução oferecida deve possuir mecanismo ou funcionalidade que permita definir através da faixa etária dos pacientes, expressa em ano, dia ou meses, e do seu sexo, masculino, feminino, não informado, o grupo de layout a ser utilizado.

5.30.12. Xxxx possuir cadastro de recipiente para coleta contendo sua descrição e campo para indicar se o mesmo está ativo ou não.

5.30.13. Xxxx possuir cadastro de materiais para coleta contendo sua descrição e campo para indicar se o mesmo está ativo ou não.

5.30.14. Deve possuir cadastro de prazos de entrega onde possam ser definidos, para cada prazo, sua descrição, o número de dias de entrega e, para cada dia da semana, incluindo sábados e domingos, se: Realiza e Entrega, Apenas Entrega ou ainda Se não Realiza e Não Entrega, cada um com seu respectivo horário limite para coleta.

5.30.15. Deve possuir cadastro de grupos de layouts, onde pode ser realizada a configuração de cabeçalho de laudo, comprovante de coleta, etiqueta, exame, mapa, protocolo de agendamento.

5.30.16. A aplicação ofertada deve possuir funcionalidade para cadastro de tipos de requisição.

5.30.17. Deve possuir mecanismo ou funcionalidade que permita criação de variáveis para utilização na construção do layout do laudo de cada exame.

5.30.18. A aplicação deve possuir mecanismo ou funcionalidade para criação de mapas grade, bancada ou por paciente, completos e resumidos, contendo sua descrição e setor de uso, permitindo a seleção exame a exame, a seleção de todos os exames de um setor.

5.30.19. Deve possuir cadastro de setores de atendimento do laboratório contendo campos para identificar o responsável pelo setor, se o setor é de apoio, se está ativo e um campo texto para observações.

5.30.20. A solução deve oferecer cadastro de tipos de requisição contendo sua descrição, possuindo ainda mecanismo que possa determinar qual dos tipos deve ser utilizado como padrão no momento da requisição do exame.

5.30.21. A aplicação deve possuir funcionalidade para criação de layout dinâmicos para cada exame e grupo de layout. No layout devem ser criados os campos para a entrada dos resultados, layout a ser utilizado para impressão do laudo e layout a ser utilizado na impressão do mapa.

5.30.22. A aplicação deve possuir funcionalidade que permita edição dos layouts a serem utilizados integrado a aplicação, sua interface deve ser amigável a deve possuir as seguintes funcionalidades:

a. Deve permitir que sejam inseridos campos texto, campos numéricos e fórmulas para campos calculados

b. Deve permitir que seja anexada régua gráfica para apresentação dos valores de referência para cada leitura presente no laudo

c. Deve possuir mecanismo para limites de valores fora das referências para os resultados lançados nos laudos

d. Deve possuir mecanismo ou funcionalidade para seleção de campos de histórico para respostas padrões para cada resultado a ser lançado no laudo

e. Deve possuir lista padrão dos campos para inserção de valores nos laudos como nome do paciente, documentos do paciente, nº do CNS, nome do exame, material examinado e outros.

5.30.23. A aplicação deve possuir mecanismo para configuração dos mapas de trabalho com funcionalidades semelhantes ao de configuração dos laudos de exames.

5.30.24. Deve permitir que sejam informados para cada exame o setor em que o mesmo é realizado, o material de coleta, o recipiente, dias para entrega, sexo, campo para indicar quando o exame é sigiloso e campo para indicar quando o exame utilizará triagem.

5.30.25. Deve possuir mecanismo ou funcionalidade que permita limitar os históricos padrões a serem utilizados por cada exame relacionado para uso no laboratório.

5.30.26. Deve possuir funcionalidade que permita que sejam limitados os convênios aos quais cada exame pode ser relacionado.

5.30.27. Deve permitir que seja informado para cada exame, sua ordem de impressão e número da amostra nos Mapas de Trabalho e se serão impressos resultados anteriores durante a emissão dos laudos

5.30.28. Deve possuir funcionalidade para que possam ser determinadas as informações de coleta de material para cada exame e que essas informações sejam visíveis no comprovante de agendamento.

5.30.29. Deve possuir ajuste de configuração para as impressões de etiquetas dos tubos de coleta (impressora térmica), cada exame deve possuir uma etiqueta com o código de barras e agrupá-la conforme a necessidade do laboratório.

5.30.30. Deve possuir funcionalidade para interfaceamento aberto dos equipamentos existentes no laboratório. Também deve ser responsável pelos custos de instalação e manutenção do mesmo. É necessário o envio para o Laboratório de um computador para a utilização exclusiva do interfaceamento. (Computador, CPU, mouse, teclado, cabos necessários para instalação).

5.30.31. A empresa deve entrar em contato com a empresa vencedora dos equipamentos de hematologia e bioquímica para ajustar o que for necessário para instalação. A interface deve permitir a visualização de resultados anteriores, bem como ajustes de configuração para cada exame.

5.30.32. Deve possuir no cadastro de exames campo para indicação se o exame é interfaceado, se as etiquetas serão agrupadas para este exame, se o exame é liberado automaticamente quando vem do interfaceamento e a quantidade de etiquetas que serão impressas.

5.30.33. Deve possuir mecanismo ou funcionalidade que permita relacionar todos os reagentes a serem utilizados por cada exame a ser executado pelo laboratório.

5.30.34. Deve possuir um sistema de marcação dos pacientes por dia através da Agenda, possibilidade de criar mais vagas para um mesmo dia que já tenha agenda vigente, também deve possuir uma agenda para marcação de pacientes urgentes e que o laboratório possa configurar ela de acordo com a necessidade.

5.30.35. Na aba agenda deve ter ícones para agendar e visualizar a agenda dos pacientes já inseridos. Também deve possuir um campo para pesquisa pelo nome ou data de nascimento do paciente.

5.30.36. Deve possuir diversos relatórios de total de exames, por paciente, número de pacientes atendidos por dia, gestantes dentre outros. E de acordo com a necessidade o laboratório irá solicitar relatórios diferenciados.

5.30.37. O sistema deve estar disponível para todas as unidades de saúde, criando usuários para cada profissional que utilizar, o sistema deve disponibilizar para elas o agendamento de exames e a impressão de resultados.

5.30.38. Liberação de consulta do banco de dados para no caso de troca do sistema.

5.30.39. Deve possuir no sistema uma aba especifica para gerenciamento de cadastros duplicados.

Document Metadata

Table of Contents

PROCESSO DE LICITAÇÃO Nº 22/2022/FMS EDITAL PE Nº 04/2022/FMS CONTRATO Nº 08/2023/FMS

Document Metadata