TERMO DE REFERÊNCIA

TERMO DE REFERÊNCIA

1. INFORMAÇÕES PRIMÁRIAS:

Órgão Requerente: Secretaria Municipal de Saúde e Saneamento.	Descrição de categoria de investimento:
	( ) Aquisição (x) Contratação de Serviços

2. MODALIDADE E O TIPO DE LICITAÇÃO:

Modalidade de Licitação:	Tipo de Licitação:
( ) Concorrência - Art. 22 § 1°, Art. 23 incisos I e II
alínea c da Lei n° 8.666/93.	Art. 45, incisos I ao IV, da Lei
( ) Tomada de Preço - Art.22 §2°, Art.23 incisos I e	n° 8.666/93:
II alínea b da Lei n° 8666/93.	( ) Menor Preço Global.
( ) Convite - Art. 22 §3, Art.23 incisos I e II alínea a	( ) Menor Preço por item.
da Lei n° 8.666/93.	( ) Menor Preço Lote.
( ) Concurso - Art. 22 § 4° da Lei n° 8.666/93.	( ) Melhor Técnica.
( ) Leilão - Art. 22 § 5° da Lei n° 8.666/93.	( ) Técnica e Preço.
( ) Dispensa de Licitação - Art. 24 da Lei n°	( ) Maior Lance ou Oferta.
8.666/93.	( ) Tabela de preço.
( ) Inexigibilidade de Licitação - Art. 25 da Lei n°	( ) Não se enquadra.
8.666/93.	( ) Credenciamento.
( ) Pregão Eletrônico – SRP - Lei Federal n°	(X) Adesão à Ata de Registro
10.520/02 e subsidiariamente, no que couber, as	de Preços
disposições da Lei no 8.666/93.
( ) Pregão Eletrônico – Tradicional - Lei Federal n°
10.520/02 e subsidiariamente, no que couber, as
disposições da Lei no 8.666/93.
( ) Pregão Presencial – SRP - Lei Federal n°
10.520/02 e subsidiariamente, no que couber, as
disposições da Lei no 8.666/93.
(x) Adesão à Ata de Registro de Preços nº
03/2020, Pregão Eletrônico 008/2020, realizado
pelo Consórcio Intermunicipal da Região Centro
Leste de Rondônia - CIMCERO
( ) Pregão Presencial – Tradicional - Lei n°
10.520/2002 e subsidiariamente, no que couber, as
disposições da Lei no 8.666/93.
( ) Lei Municipal 2738/2017

3. DA LEGISLAÇÃO APLICÁVEL:

(X) Lei n°8.666/93 e suas alterações (Institui normas para Licitações e Contratos da Administração).

( ) Lei Complementar n°123/2006 (Institui o Estatuto Nacional da Microempresa e Empresa de Pequeno Porte) e alterações posteriores.

(X) Lei n°10.520/2002 (Institui a modalidade de licitação denominada Pregão);


( ) Decreto Municipal n° 176/2006 e 044/2013 que regulamenta Sistema de Registro de Preços no Município.

( ) Lei Municipal n° 2738/2017 que dispõe sobre tratamento diferenciado as ME e EPP.

( ) E demais disposições a serem estabelecidas no Edital de Licitação e em seus Anexos.

4. DO OBJETO:

O presente Termo de Referência tem por finalidade definir XXXXXX X XXX 000/0000 XX XXXXXX ELETRÔNICO SRP 008/2020, REALIZADO PELO CONSÓRCIO INTERMUNICIPAL DA REGIÃO CENTRO LESTE DE RONDÔNIA – CIMCERO PARA CONTRATAÇÃO DE EMPRESA ESPECIALIZADA PARA O FORNECIMENTO DE SOFTWARE INTEGRADO PARA GESTÃO DE SAÚDE PÚBLICA MUNICIPAL NOS INSTRUMENTOS DE GESTÃO DE SAUDE PUBLICA, SENDO NA ATENÇÃO BÁSICA, MEDIA E ALTA COMPLEXIDADE, REGULAÇÃO, ASSISTENCIA FARMACÊUTICA, CONTROLE E AVALIAÇÃO E VIGILANCIA EM SAÚDE, DENTRE OUTRAS NECESSIDADES INERENTES AO SUPORTE DA GESTÃO DE SAUDE DO MUNICIPIO DE SORRISO/MT E DISTRITOS ADJACENTES (CARAVAGIO, BOA ESPERANÇA E PRIMAVERA DO NORTE) CONFORME ESPECIFICAÇÕES CONTIDAS NOS ANEXOS,

QUE SÃO PARTES INTEGRANTES DESTE ATO conforme condições necessárias.

5. DA JUSTIFICATIVA:

5.1. O planejamento administrativo surge da necessidade de se efetuar combinações técnicas, modernas e de conceito racional, através da implantação de um sistema informatizado capaz de satisfazer a todas as exigências legais em todos os âmbitos, possibilitando ainda maior agilidade e confiabilidade na obtenção de resultados, primando, acima de tudo, pelo zelo para com o bem público. Por isso, a utilização de softwares que serão interligados em rede local e remota, se necessário, permitindo assim que todas as unidades de saúde funcionem integradas no sistema ao mesmo tempo, dará ao município maior efetividade no processamento de informações e posterior decisão por parte da gestão da saúde.

5.2. É preciso destacar que a contratação de empresa especializada em serviço de software é voltada para facilitar e uniformizar o atendimento dos usuários do Sistema Único de Saúde

– SUS, tanto pelas Unidades Básicas de Saúde do Município (UBS), quanto unidades Especializadas e Vigilância em Saúde;

5.3. Registramos que é de fundamental importância para o município a manutenção no uso de um sistema adequado e compatível com as atividades da Secretaria de Saúde, a fim de, garantir a continuidade dos atendimentos de forma célere e informatizada, por isso, em levantamento realizado pela secretário para a formalização de um novo processo, já que o contrato atual encerra-se neste mês de fevereiro/2021, verificou-se viabilidade econômica na formalização de um processo de adesão, que além de garantir uma aquisição com valor dentro do preço de mercado, também viabiliza, de maneira mais célere, a contratação do serviço para um novo período de vigência.

5.4. Destaca-se para o fato de que o uso de um sistema adequado também traz maior segurança para que o município monitore os indicadores de atendimento na saúde estabelecidos por governo federal e estadual, para garantir repasses financeiros, dessa forma, é de fundamental importância que o município possua um software de gestão em pleno funcionamento.

6. DA ESPECIFICAÇÃO DOS PRODUTOS E/OU SERVIÇOS:

6.1. Os itens que a secretaria pretende adquirir são:
	Cód. Agili	Cód. TCE	UNID	QTD	DESCRIÇÃO	V. UNIT	V. TOTAL
	845972	00034324	MÊS	03	SAÚDE – LOCAÇÃO DE SOFTWARE MEDIANTE LICENÇA DE USO, SERVIÇOS DE SUPORTE TÉCNICO ESPECIALIZADO,	R$ 30.750,00	R$ 92.500,00

					MANUTENÇÃO E CONFIGURAÇÃO IMPLANTAÇÃO
	845975	00011993	MÊS	03	VIGILÂNCIA – LOCAÇÃO DO SOFTWARE MEDIANTE LICENÇA DE USO, SERVIÇOS DE SUPORTE TÉCNICO ESPECIALIZADO, MANUTENÇÃO E CONFIGURAÇÃO.	R$ 3.460,00	R$ 10.380,00
6.1.1. Os itens combatíveis com a necessidade da secretaria e que serão aderidos da Ata de Registro de Preços do CIMCERO são: item 6.1 e item 12.1; 6.2. Os serviços a serem realizados seguirão as descrições constantes no Anexo I, especialmente no que se refere a valores e quantitativo;

7. VALOR ESTIMADO DE CONTRATAÇÃO:

7.1. O valor total de referência R$ 102.630,00 (Cento e dois mil e seiscentos e trinta reais).

7.2. Cesta de preços obtida através de cotações de empresas e ATA DE REGISTRO DE PREÇO, sendo:

ATA DE REGISTRO DE PREÇO Nº 006/2020 – PREGÃO ELETRONICO Nº 008/2020 – CIMCERO;

PLURALD ASSESSORIA E CONSULTORIA EIRELI CNPJ: 08.197.371/0001-17;

TWI TECNOLOGIA E GESTÃO DE SISTEMAS LTDA – ME CNPJ: 11.601.924/0001-60; RLZ INFORMATICA LTDA CNPJ: 65.596.744/0001-66.

7.2.1. Os valores de referência para o processo de contratação de empresa especializada para o fornecimento de software integrado para gestão de saúde pública municipal de Sorriso-MT;

8. DOTAÇÃO ORÇAMENTÁRIA:

ORGÃO	DOTAÇÃO	PROJ./ATIVIDADE	ELEMENTO DESPESA	COD. RED	VALOR
SECRETARIA MUNICIPAL DE SAÚDE	15.001.10.302.0005.2115	MANUT. DAS AÇÕES DO AME	339040	647	11.830,00
SECRETARIA MUNICIPAL DE SAÚDE	15.001.10.301.0004.2110	MANUT. DAS AÇÕES DA ATENCAO BASICA	339040	602	44.000,00
SECRETARIA MUNICIPAL DE SAÚDE	15.001.10.302.0005.2114	MANUT. DAS AÇÕES DO UPA	339040	634	12.000,00
SECRETARIA MUNICIPAL DE SAÚDE	15.001.10.302.0005.2149	MANUT. DAS AÇÕES DO SAE	339040	678	8,700,00
SECRETARIA MUNICIPAL DE SAÚDE	15.001.10.302.0005.2117	MANUT. DAS AÇÕES DO CEO	339040	657	8.700,00
SECRETARIA MUNICIPAL DE SAÚDE	15.001.10.302.0005.2118	MANUT. DAS AÇÕES DO CAPS	339040	667	8.700,00
SECRETARIA MUNICIPAL DE SAÚDE	15.001.10.302.0005.2163	MANUT. DE MEDIA E ALTA COMPLEXIDADE – RENASCER	339040	687	8.700,00

9. VIGENCIA DE CONTRATO:

9.1. O presente processo de adesão terá validade e vigência de 03 (três) meses, contados a partir da data de assinatura do contrato.

10. HORÁRIO DE ATENDIMENTO:

10.1. O sistema deverá atender as necessidades das unidades de saúde de acordo com suas particularidades, bem como a Gestão.

11. FISCALIZAÇÃO DE SERVIÇOS/VISTORIA:

11.1. O licitante poderá fazer fiscalização/vistoria pelo Fiscal de Contrato a qualquer momento com o objetivo de inteirar-se das condições de atendimento e grau de dificuldades existentes;

11.2. A fiscalização/vistoria acontecerá em horário comercial e em dias uteis;

11.2.1. Este procedimento deverá ser acompanhado pelo responsável da empresa;

13.3. Após a fiscalização será realizado relatório elencando todas as ocorrências e deficiências constatadas, objetivando a imediata correção das irregularidades apontadas;

13.4. As exigências e atuação da fiscalização/vistoria, em nada restringem a responsabilidade, única, integral e exclusiva da credenciada, no que concede a execução do objeto contratado;

13.5. Durante a fiscalização de serviços/vistoria poderá ser realizado pesquisa de satisfação dos usuários.

13.6. A Fiscalização realizada pelo município não exclui a obrigatoriedade e o dever de fiscalização dos demais órgãos competentes pelo controle de funcionamento da atividade desenvolvida pelas empresas;

13.7. Atuarão como fiscais de contrato da presente contratação os servidores: XXXXX XXXXXXX XXX XXXXXX (fiscal) e XXXXXX XXXXXX (Substituto).

12. OBRIGAÇÃO DO CONTRATADO:

12.1. É proibido o CONTRATADO cobrar taxas ou quaisquer outros encargos do usuário, sob pena de rescisão contratual que poderá ocorrer de maneira unilateral, conforme regras dos arts. 77 e 78 da Lei 8.666/93 e aplicação de multa a ser apurado em processo administrativo instaurado imediatamente após a denuncia apresentada pelo usuário, assegurado o contratado o direito ao contraditório e à ampla defesa.

12.2. O acompanhamento do contrato de execução de serviço, bem como valor financeiro do contrato, é também responsabilidade do CONTRATADO. O fato de ter o fiscal do contrato não divide, nem tampouco retira as obrigações do CONTRATADO.

12.3. Executar os serviços dentro dos padrões estabelecidos pela CONTRATANTE e de acordo com o especificado no termo de referência, responsabilizando-se por eventuais prejuízos decorrentes do descumprimento de qualquer cláusula ou condição aqui estabelecida;

12.4. Assumir inteira responsabilidade técnica e administrativa pela qualidade dos serviços contratados, não podendo, sob qualquer hipótese, transferir à outra pessoa a prestação dos serviços.

12.5. Indenizar terceiros e/ou a CONTRATANTE, mesmo em caso de ausência ou omissão de sua parte, por quaisquer danos ou prejuízos causados, devendo a CONTRATADA adotar todas as medidas preventivas, com fiel observância às exigências das autoridades competentes e as disposições legais vigentes;

12.6. Responder, por quaisquer prejuízos que causar à CONTRATANTE ou à terceiros, decorrentes da incompatibilidade de ação ou omissão culposa, procedendo imediatamente os reparos ou indenizações cabíveis e assumindo inteiramente o ônus decorrente;

12.7. Responsabilizarem-se integralmente pelos serviços contratados, nos termos da legislação vigente, entre eles todas as despesas, impostos, encargos sociais;

12.8. Disponibilizar todo Hardware necessário para os sistemas implantados. O hardware deve ser disponibilizado no Datacenter do município.

12.9. Prover todos os meios necessários à garantia da plena operacionalidade dos serviços;

12.10. Indenizar terceiros e/ou a CONTRATANTE, mesmo em caso de ausência ou omissão de sua parte, por quaisquer danos ou prejuízos causados, devendo a CONTRATADA adotar todas as medidas preventivas, com fiel observância às exigências das autoridades competentes e as disposições legais vigentes;

12.11. Aceitar nas mesmas condições contratadas, os acréscimos ou supressões que se fizerem necessários, até o limite de 25% (vinte e cinco por cento) do valor atualizado do contrato.

12.12. O CONTRATADO não poderá terceirizar os serviços, objeto do presente contrato, sendo de sua responsabilidade a realização dos mesmos.

13. DAS OBRIGAÇÕES DA CONTRATANTE:

13.1. Efetuar o pagamento à empresa, de acordo com a forma e prazo estabelecidos no Decreto de programação financeira do Município de Sorriso-MT;

13.2. Prestar as informações e os esclarecimentos pertinentes ao objeto, quando solicitados pela empresa credenciada;

13.3. Rejeitar qualquer tipo de serviço prestado equivocadamente, ou, em desacordo com as especificações mínimas exigidas neste edital e seus anexos;

13.4. Levar ao conhecimento do gestor do contrato, qualquer fato extraordinário que ocorreu na execução do objeto contratado, para que o mesmo possa tomar as providências cabíveis.

14. QUALIFICAÇÃO DO PROPONENTE:

14.1. HABILITAÇÃO JURIDICA: Conforme disposto na Lei n° 8.666/93 e suas alterações (Institui normas para Licitações e Contratos da Administração) e Lei n° 10.520/2002 (Institui a modalidade de licitação denominada Pregão).

14.2. REGULARIDADE FISCAL: Conforme disposto na Lei n° 8.666/93 e suas alterações (Institui normas para Licitações e Contratos da Administração) e Lei n° 10.520/2002 (Institui a modalidade de licitação denominada Pregão).

14.3. QUALIFICAÇÃO ECONÔMICO-FINANCEIRA: Conforme disposto na Lei n° 8.666/93 e suas alterações (Institui normas para Licitações e Contratos da Administração) e Lei n° 10.520/2002 (Institui a modalidade de licitação denominada Pregão).

14.4. QUALIFICAÇÃO TÉCNICA PESSOA JURIDICA: Conforme disposto na Lei n° 8.666/93 e suas alterações (Institui normas para Licitações e Contratos da Administração) e Lei n° 10.520/2002 (Institui a modalidade de licitação denominada Pregão).

14.5. O município poderá solicitar a qualquer das empresas licitantes a apresentação de Licença Ambiental de Operação/Produção

Sorriso – MT, 12 de fevereiro de 2021.

SECRETARIA MUNICIPAL DE SAÚDE E SANEAMENTO

Secretário: XXXX XXXXX XXXXXXXXX

ANEXO I

ESPECIFICAÇÃO DOS PRODUTOS E/OU SERVIÇOS

1. DO AMBIENTE TECNOLOGICO:

⮚ O recurso ofertado deverá rodar sobre o ambiente tecnológico existente na contratante. 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.

⮚ O Backup do banco de dados é de propriedade exclusiva do município;

⮚ A empresa participante deve atender 100% dos módulos aplicados neste Termo de Referência.

2. DOS REQUISITOS MINIMOS OBRIGATÓRIOS:

⮚ O sistema de gestão de saúde deve ser desenvolvido para rodar sobre servidores de páginas de internet e ser acessado através de navegadores de internet e intranet do município, sem a utilização de qualquer tipo de emulador ou plug-in. Deverá ser compatível com os navegadores Internet Explorer, Mozilla Firefox, Edge e Ópera, em suas versões atuais.

⮚ O sistema deve possuir mecanismo para integrar os seguintes sistemas disponibilizados pelo Ministério da Saúde: E-SUS, DIGISUS, RAG, PAN, CNS (Cadweb), BPA Magnético, CNES, SIA, SISCTA, SISPNI, BNDASAF, SIGTAP, RPOM, RAAS devendo ser encaminhado mensalmente relatório para a secretaria municipal de saúde, dados dos envios de produção ao ministério da saúde e Sistemas de Gestão.

⮚ O banco de dados deverá ser em SQL server ou Oracle. Deverá ter a base de dados toda local no município, seja em servidor, centralizador ou em várias unidades do município, desde que atenda a necessidade do município;

⮚ O sistema dever ser em base única e todo interligado com todas as unidades de saúde do município, não sendo permitido a sua divisão parcial ou total em quaisquer dos módulos descritos neste Termo.

⮚ A empresa contratada, deve comprometer-se em realizar as atualizações necessárias para as versões dos sistemas do ministério da saúde e disponibilizar em tempo hábil as novas integrações que possam ocorrer de acordo com a disponibilização do Ministério da Saúde através do DATASUS e/ou outros órgãos, os quais atualmente ainda não possuem layout aberto tais como: SISREG e outros que forem exigidos, considerando ainda sistemas posteriores a assinatura do contrato com layout aberto, sem qualquer ônus ao município.

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

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

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

⮚ Permitir auditoria automática das operações efetuadas no sistema, através de logs de acesso, de modo que seja possível identificar claramente as atividades de consulta, inclusão, alteração e exclusão de qualquer informação, inclusive aquelas de qualquer usuário, indistintamente, inclusive administradores. O log

registrado deve permitir a identificação completa do dado que foi acessado/atualizado.

⮚ O sistema deverá possibilitar a personalização dos relatórios existentes no sistema da contratante para atender as demandas do município cabendo a esta Secretaria a decisão de alterar em quaisquer módulo que se julgar necessário.

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

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

⮚ O sistema deverá possuir controle de medicamentos constantes das listas da Portaria SVS/MS/Nº344, de 12 de maio de 1998 /98 (ANVISA) e suas alterações, bem como a lista do REMUME – Relação Municipal de Medicamentos.

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

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

⮚ Deverá possuir padronização do uso de botões de forma a facilitar o seu aprendizado e operação, disponibilizando ao usuário recursos de informação sobre o que um botão, menu ou ícone faz ao posicionar o cursor sobre ele;

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

⮚ 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;

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

⮚ Deverá integrar com os sistemas sociais existentes para que os gestores possam efetuar em um único ambiente consultas online.

⮚ A empresa deverá realizar a prestação de serviços de sistema de informatização das unidades para a gestão da Secretaria Municipal de Saúde, visando oferecer ao município o suporte necessário ao eficiente desempenho das suas atividades, tanto no sistema quanto na compilação dos dados, confrontando o aperfeiçoamento da gestão e a organização do Fundo Municipal de Saúde.

⮚ Possuir software que possa permitir ao Gestor abrir chamado para empresa e acompanhar em tempo real os andamentos das solicitações realizadas pela equipe, visando o maior controle da oferta da prestação dos serviços.

3. DO   TESTE   DE   CONFORMIDADE:                

⮚ O teste de conformidade (prova de conceito) do software será apresentado mediante aplicação de amostragem da solução dos módulos de gestão solicitados. Havendo a necessidade, deverá ser nomeada uma Comissão de Avaliação Técnica, composta por no mínimo 03 (três) profissionais da área que de fato conhecem os processos e serviços a serem atendidos pelo sistema no contexto das atividades de Saúde e Tecnologia da Informação.

⮚ No caso de solicitação, à licitante melhor qualificada deverá apresentar um ambiente operacional com o(s) módulo/software (s) ofertados, no prazo máximo de até 07 (sete) dias úteis depois de notificada pelo condutor do certame. Ao final

desse prazo, o sistema apresentado (software) deverá estar em plenas condições operacionais, atendendo no mínimo 85% (oitenta e cinco por cento) dos requisitos constantes ao Módulo de Gestão ofertado, e de acordo com as exigências constantes deste Termo de Referência.

⮚ O prazo poderá ser prorrogado por igual período, desde que solicitado à Administração do Município de Sorriso/MT com antecedência de até 02 (dois) dias da apresentação, devidamente justificado e aprovado pela Administração do Município.

⮚ Os itens de serviços a serem submetidos e avaliados na prova de conceito pela Comissão designada, devem ser definidos, observados os requisitos mínimos constantes deste Termo de Referência.

⮚ As provas de conceito e amostragem será realizada em local a ser definido pelo condutor do certame licitatório, em ambiente devidamente adequado a realização de todos os testes e ensaios necessários, e na presença da Comissão de Avaliação Técnica designada.

⮚ A Comissão Técnica de Avaliação deverá no prazo de até 03 (três) dias úteis, emitir um Parecer Técnico da Avaliação de Aprovação e/ou Reprovação dos Softwares apresentados.

⮚ O licitante melhor classificado que não atender no mínimo 85 % (oitenta e cinco por cento) dos requisitos analisados na prova de conceito será inabilitado no certame licitatório, ficando desde já autorizado ao condutor do certame, convocar a empresa qual ficou em 2º (segundo) lugar, e assim, sucessivamente na ordem de classificação, e fará, mediante convocação pelo chat do sistema eletrônico específico.

⮚ Em caso que a solução atender o mínimo de 85%, a Comissão Técnica de Avaliação deverá estipulara o prazo para a licitante providenciar o(s) item(s) faltante(s), sendo o prazo conforme a complexidade da parametrização/customização e/ou criação.

4. DO      TREINAMENTO:                     

⮚ O contratado deverá disponibilizar capacitações para os operadores do programa de todas as funções do sistema pertencente a sua área de responsabilidade sem custos adicionais.

⮚ Todos os recursos e material necessário para o treinamento deverá ser por conta da empresa contratada.

⮚ As turmas devem ser dimensionadas por módulo, sendo que cada turma não poderá ter mais de 10 (dez) participantes para facilitar o entendimento e agilidade no aprendizado.

⮚ A empresa deverá fornecer Certificado de Participação aos funcionários que tiverem comparecido a mais de 85% (oitenta e cinco por cento) das atividades de cada curso.

⮚ As despesas relativas à participação dos instrutores e de pessoal próprio, tais como: hospedagem, transporte, diárias, etc. serão por conta da empresa contratada.

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

⮚ A Contratante deverá fornecer um passo a passo dos módulos para cada profissional.

⮚ Quando solicitado pela Contratante, a Contratada deverá providenciar alterações no programa de treinamento, incluindo recursos, instrutores, conteúdo, entre outros que se fizer necessário.

⮚ A contratada deverá disponibilizar um técnico capacitado para acompanhamento da implantação e acompanhamento aos usuários. Bem como, um profissional

técnico que ficará no Setor de Dados de Produção do município até a completa funcionalidade do sistema exigida pelo município (mínimo 6 meses ou).

⮚ A empresa deverá fornecer uma central 0800 para atendimento 24 horas para tirar dúvidas sobre treinamentos realizados e outros assuntos pertinentes.

5. DOS LOCAIS DE IMPLANTAÇÃO:

⮚ Deverá ser implantado no município de Sorriso e distritos Adjacentes (Boa Esperança, Primavera do Norte e Caravagio) nas seguintes locais: Unidades Básicas de Saúde, Unidades Especializadas, Assistência Farmacêutica, Vigilância em Saúde, Secretaria de Saúde e outras que venham atender a necessidade do município.

6. DA VISITA TÉCNICA:

⮚ As empresas interessadas em participar do processo licitatório deverão efetuar visita técnica para conhecer as instalações e estrutura onde será implantado o sistema, a visita deverá ser marcada e efetuada até 03 (três) dias antes da abertura dos envelopes.

⮚ A visita será marcada com o Sr. XXXXX XXXXXXX XXX XXXXXX no período das 8:00 hs as 17:00 hs. O mesmo receberá um comprovante (certificado) da visita realizada o qual fará parte da documentação exigida na habilitação do processo licitatório.

⮚ A licitante receberá um comprovante (certificado) da visita realizada o qual fará parte da documentação exigida na habilitação do processo licitatório.

⮚ Caso a Licitante não possua interesse em realizar a visita técnica deverá apresentar declaração de que possui conhecimento das condições e locais das instalações, não podendo a mesma alegar desconhecimento ou impossibilidade de prestação do serviço futuramente, sendo de sua inteira responsabilidade atender aos requisitos do Termo Referência

7. DO SUPORTE TÉCNICO:

⮚ Durante o período contratual, a partir da parametrização do sistema e início das atividades de suporte, a contratada deverá garantir profissionais no município. Devendo atender a Contratante em horário de expediente: das 07:00 às 11:00 horas e das 13:00 às 17:00 horas, de segundas às sextas feiras. Conforme necessidade de:

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

⮚ Auxílio na recuperação da base de dados por problemas originados em erros de operação, queda de energia ou falha de equipamentos, desde que não exista backup adequado para satisfazer as necessidades de segurança;

⮚ Treinamento de servidores na operação ou utilização do sistema em função de substituição de pessoal, tendo em vista demissões, licenças, mudanças de cargos, etc.,

⮚ Auxiliar o usuário, em caso de dúvidas, na elaboração de quaisquer atividades técnicas relacionadas à utilização dos sistemas, como: gerar/validar arquivos para Órgão Governamental, entre outros.

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

⮚ Auxílio na recuperação da base de dados por problemas originados em erros de operação, queda de energia ou falha de equipamentos.

⮚ Treinamento de servidores na operação ou utilização do sistema em função de substituição de pessoal, tendo em vista demissões, licenças, mudanças de cargos, etc.,

⮚ Auxiliar o usuário, em caso de dúvidas, na elaboração de quaisquer atividades técnicas relacionadas à utilização dos sistemas, como: gerar/validar arquivos para Órgão Governamental, entre outros.

⮚ No caso de parada do sistema, o atendimento de suporte deverá estar garantido durante o período necessário para reestabelecer suas funções normais, inclusive sábados, domingos e feriados.

⮚ A Contratada deverá estar apta a acessar remotamente o sistema contratado em produção no cliente, de forma a poder verificar condições de erros que não possam ser reproduzidas em ambientes internos da empresa fornecedora do sistema.

⮚ O prazo máximo para atender solicitações de suporte, deverá ser num prazo não superior a (uma) hora, viabilizando no caso da prioridade mais severa, em prazo não superior a (1) dia útil. Este prazo se inicia com a abertura do chamado técnico.

⮚ A empresa deve fornecer o número 0800 para atendimento.

8. DO ATESTADO DE CAPACIDADE TÉCNICA:

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

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

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

9. QUANTO AOS MÓDULOS E SERVIÇOS:

⮚ Devem estar integrados para atender todas as necessidades da rede municipal de saúde (atenção básica, especialidades, assistências farmacêuticas, controle e avaliação, urgência e emergência e vigilâncias), gestão e aplicativos móveis e BI (controle e avaliação).

9.1. DOS CADASTROS E FUNCIONALIDADES GERAIS

⮚ Possuir: cadastro de Bairros e Tipos de Logradouros com CEP. Permitindo vincular Bairros e Logradouros, delimitando os cadastros dos usuários de acordo com área de abrangência de cada unidade de saúde (Segmento, Área e Micro área). Identificar o usuário que não possui endereço fixo. Ofertar UFs, Municípios e Localidades. Possuir cadastro de Motivos de desativação dos Pacientes. Possuir cadastro de CBO (Código Brasileiro de Ocupações). Possuir cadastro de Nacionalidades. Possuir cadastro de Situações do Usuário. Possuir cadastro de Órgão Emissor dos Documentos de Identidade. Possuir integração e funcionalidades para importar os dados do CARTAO SUS nacional. Possuir cadastro de Programas de Saúde.

9.2. DO CADASTRO DE USUÁRIOS:

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

⮚ Possuir mecanismos para desativar usuários, informando a data de sua desativação bem como o motivo pelo qual o mesmo foi desativado.

⮚ Possuir mecanismo para desativação de logradouros e bairros cadastrados incorretamente, migrando todos os usuários para o local correto;

⮚ Deve possuir campos para informar dados pessoais: CPF, Número de Identidade com Órgão Emissor e UF, Nº.registro de nascimento (nome do Cartório, Tipo da Certidão Livro, Folha, Termo, Data de Emissão), Naturalidade, Religião, Carteira Profissional, carteira de trabalho com número, Série, UF, Data de Emissão, Número PIS/PASEP, Título de Eleitor (Zona e Seção), Escolaridade.

⮚ Campo para armazenamento da Latitude e Longitude da residência do usuário a ser utilizado em georreferenciamento;

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

⮚ Deve possuir locais para informação de sua Peso, Altura, tipo Sanguíneo, reações alérgicas, limitações físicas, psíquicas, mentais ou outras;

⮚ 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;

⮚ Campo para informar medicações em uso contínuo.

⮚ Disponibilizar emissão da ficha cadastral do usuário, obedecendo o seguinte fluxo: solicitação, impressão de cartão provisório, envio para gráfica, retorno da gráfica e entrega ao usuário ou cancelamento da solicitação; Possuir a funcionalidade para exportação dos dados necessários para emissão de cartões permanentes em formato csv com os campos do cadastro de usuários a serem definidos pela contratante.

⮚ Possuir funcionalidade para gerenciamento de emissão de cartões municipais de saúde.

⮚ Permitir a identificação dos grupos de risco (idosos, gestantes, deficientes, e outros que a Secretaria de Saúde requerer).

⮚ Ofertar funcionalidade para gerenciamento e emissão de DNV (Declaração de Nascidos Vivos) contendo todas as informações que o documento exige.

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

⮚ Permitir a inserção de registro das impressões digitais do paciente, através de leitura biométrica, identificando o dedo que está sendo registrado.

⮚ Integrar com a finalidade de importar os dados do CARTAO SUS nacional.

⮚ Ofertar integração e funcionalidades para registrar foto do paciente.

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

⮚ Utilizar parametrização no envio de mensagens por sms/e-mail

identificando o remetente, usuário e senha utilizados e DDD padrão para o envio das mensagens e ainda possibilidade de configuração por unidade de saúde para envio automático de sms/e-mail.

⮚ Garantir cadastro de eventos permitindo que o sistema possa identificar o momento e o evento para qual deseja realizar o envio de sms (dispensação de medicamentos, agendamento de consultas, agendamento de transportes, e outros).

⮚ Possuir mecanismo de envio de sms/e-mail em lotes através da utilização de filtros como tipo usuário, bairro, logradouro, unidade de origem, unidade de destino, tipo de serviço (consulta, exames e outros), profissional que atenderá, status do agendamento, e texto a ser enviado.

⮚ O sistema de SMS deve apresentar em seu relatório e auditoria o status dos envios da seguinte forma: sms enviado e sms entregue pela operadora.

9.4. DO CONTROLE DE ESTOQUES MEDICAMENTOS E INSUMOS:

⮚ A empresa deve possibilitar o cadastro de fornecedores contendo dados do CNPJ, data do cadastro, telefone, fax, e-mail e responsável. 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.

⮚ Possuir: cadastro dos fabricantes identificando se o produto é medicamento ou insumos/materiais com campo de identificação, cadastro de centros de custos, cadastro de entorpecentes e suas versões, cadastro de materiais e medicamentos por grupo e subgrupo.

⮚ Ofertar motivos de acertos de estoque em cada ponto de distribuição com os campos de: data do acerto, motivo, material, forma de apresentação, unidade, data de validade e quantidade real.

⮚ Proporcionar o gerenciamento de estoque por competência, campo de pesquisa da posição do estoque (competência inicial e final, material, forma de apresentação e ponto de distribuição), informar estoques mínimos, apresentação em cada ponto de distribuição de materiais/medicamentos em funcionamento na contratante.

⮚ Relatório de estoque atual e estimativa do número de dias que o saldo atual conseguira suprir com base no consumo diário. Indicar os itens que estão com quantidade mínima.

⮚ Motivos de Acertos de Estoque, e se o sistema devera aceitar ou não os acertos com datas retroativas;

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

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

⮚ Ofertar as opções de formas nas quais o medicamento pode estar disponível para consumo.

⮚ Possuir cadastro de DCB’s (Denominação Comum Brasileira).

⮚ Apresentar a opção de entrada de Materiais e Medicamentos com base na nota de compra com as seguintes informações: Data e local da Entrada, Ponto de Distribuição, Fornecedor, Licitação, Data da Compra, Número da Nota Fiscal, Série, Frete, Acréscimo, Desconto, Forma de Apresentação, Centro de Custo, Fabricante; e indicar quais pontos de distribuição podem realizar a entrada de material/medicamento através das notas de compra.

⮚ Deve possuir mecanismo para gerenciamento de 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;

⮚ Fornecer um mecanismo para fechamento da compra e cálculo do custo médio por item da nota emitida.

⮚ Permitir a funcionalidade para gerenciamento de fornecimento de medicamentos de rotina, contendo o paciente, o medicamento, observação, forma de apresentação e quantidade a ser dispensada;

⮚ Xxxxxxxx mecanismo para aceitar entrada de materiais e medicamentos recebidos através de doações;

⮚ Fornecer a funcionalidade do extrato de compra.

⮚ Disponibilizar requisição de materiais para que as unidades de distribuição possam solicitar os materiais e medicamentos necessários;

⮚ Possuir a funcionalidade para: geração da transferência dos materiais e medicamentos solicitado com base na requisição de abastecimento com o mínimo de trabalho possível;

⮚ Fornecer relatórios para abastecimento das unidades de distribuição permitindo acompanhar o consumo diário e mental, conferencia das transferências realizadas evitando desvios de materiais e medicamentos;

⮚ Dispor de registro das dispensações de materiais e medicamentos para os usuários onde possam ser registradas as seguintes informações: ponto de distribuição onde foi realizada a saída, data, competência, número da receita, identificação do usuário, profissional e programa de saúde. Nos itens de cada saída de ser possível que sejam registradas as seguintes informações: material, forma de apresentação, lote, validade, quantidade liberada, quantidade prescrita e duração. Durante a dispensação 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 de acordo com a lista de entorpecentes a qual o medicamento pertence.

⮚ Na tela de saída o sistema deve permitir que sejam consultadas as últimas dispensações de medicamentos realizadas para o usuário que está sendo atendido; Permitir que o usuário seja pesquisado através de parte do nome, nome da mãe, data de nascimento ou cartão SUS;

⮚ Dispor de mecanismos para registro dos medicamentos e materiais procurados pelos usuários e não disponíveis nos pontos de distribuição contendo os campos de: ponto de distribuição, data da demanda, data do lançamento, nome do usuário, centro de custo, material, forma de apresentação, quantidade a ser dispensada e quantidade reprimida.

⮚ Fornecer parametrização do número máximo de dias em atraso que se pode realizar uma transferência e número máximo de dias em atraso que se pode realizar uma saída.

⮚ Indicar se é possível que o ponto de distribuição possa inserir uma saída sem informar o usuário que retirou o produto; Se é possível realizar saídas informando apenas o centro de custo; Se é ou não obrigatória a informação do profissional que receitou o medicamento durante a dispensação do mesmo; Se o tempo de utilização do material deve ser informado no momento da saída; Se o operador poderá ou não lançar a demanda reprimida no momento da dispensação; Se permitirá ou não a transferência de medicamentos vencidos; Se o ponto de distribuição trabalha com utilização de etiqueta de códigos de barra bem como o modelo de etiqueta a ser utilizado;

⮚ Indicar se um aviso será dado ao operados assim que o material/medicamento atingir sua quantidade mínima;

⮚ O sistema deverá possuir rotina para acompanhamento de medicamentos vencidos;

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

⮚ Permitir devolução para fornecedor, obtendo os dados da compra, tipo de movimentação do (BNDASAF – Base Nacional de Dados de Ações e Serviços da Assistência Farmacêutica) e itens para devolução; Mecanismo para devolução de saídas.

⮚ Funcionalidade para que novos medicamentos cadastrados possam ser relacionados a um determinado material.

⮚ Dispor obrigatoriamente da funcionalidade de integração com o BNDASAF.

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

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

⮚ Disponibilizar cadastro dos tipos de atendimento disponíveis na rede

de saúde.

⮚ Possuir parâmetros para indicar para cada forma de atendimento se serão impressas fichas de atendimento ambulatorial no momento do atendimento, informando se a ficha de atendimento será impressa em tela ou enviada diretamente para a impressora para cada forma de atendimento.

⮚ Indicar se serão impressas múltiplas fichas de atendimento ambulatorial para cada forma de atendimento.

⮚ Ofertar a geração de 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, data da atualização e ainda data de faturamento do respectivo protocolo para cada forma de atendimento.

⮚ Possuir parâmetro para indicar se existe integração com a autorização de exames;

⮚ A aplicação deve possuir parâmetros para indicar se a presença do usuário será realizada automaticamente após o agendamento, se será lançada a evolução da enfermagem, prescrição médica a tela de anamnese, 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 e CID-10;

⮚ Deve possuir cadastro obrigatório de motivos de cancelamento de agendamentos.

⮚ Disponibilizar procedimentos de acordo com o CBO de cada profissional e as exigências mínimas contidas na tabela SUS para aprovação da produção junto ao DATASUS (idade mínima do usuário, sexo, caráter do atendimento, e outros);

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

⮚ Deve permitir que sejam informados os dias da semana em que cada cronograma poderá ser utilizado, turno, número de consultas, caracterização da consulta (1ª consulta, retorno ou urgência/emergência) indicando o quantitativo, tempo de consulta e intervalos de horários em que o mesmo estará disponível.

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

⮚ Deve possuir mecanismo para gerenciar a suspensão, aumentar ou diminuir o número de consultas, mudar as datas e os horários de atendimento de uma determinada unidade de saúde, do profissional, da forma de atendimento, horários ou unidade de origem do agendamento em um determinado turno, dia da semana ou período.

⮚ Disponibilizar cadastros de causas de atendimento e a classificação os motivos de atendimento por gravidade.

⮚ Ofertar mecanismo de fichas de anamnese permitindo especificar em quais CBO’s a mesma será utilizada. O mecanismo de fichas deve permitir que sejam criados subtítulos dentro de cada anamnese de acordo com os questionamentos enumerados. As 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 a 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.

⮚ Consentir que sejam inseridas diversidades de procedimentos para cada agenda de atendimento em funcionamento nas Unidades de Saúde,

⮚ Admitir criação de turmas para atendimento em grupo onde possam ser identificados o nome do grupo, Unidade de Saúde, quantidade mínima e máxima de participantes, programa de saúde, data, horário, nome dos participantes e informações gerais necessárias.

⮚ Aceitar que sejam lançados procedimentos para todos os participantes de um grupo informando o profissional que atenderá, tipo de procedimento, CBO, características do atendimento, idade, CID e quantidade. Bem como permita que procedimentos extras possam ser lançados para cada participante do grupo.

⮚ Permitir que distribua e controle as quotas sobre a quantidade e percentual de vagas disponíveis em todas as formas de atendimento disponíveis na rede de saúde, que poderão ser distribuídas para todos os locais onde as agendas estarão disponíveis para marcação.

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

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

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

⮚ Disponibilizar 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.

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

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

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

⮚ Permitir que sejam marcadas consultas por tipo de classificação, obedecendo parametrização prévia e ainda, permitir que seja informado se a usuária está processo de gestação, quando for o caso, e se o usuário não apresentou documentos no momento da marcação da consulta.

⮚ O sistema deve disponibilizar a pesquisa nas agendas através do nome do usuário.

⮚ A tela de agendamento deve atualizar-se automaticamente, sem a intervenção do operador e permitir que o operador possa interrompa os processos de atualização automática se assim desejar.

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

⮚ O sistema ofertado deve possuir mecanismo para criação de centrais de agendamento, que poderão realizar marcações em outros locais onde os serviços são disponibilizados (clinicas, serviços de imagem, laboratórios e outros).

⮚ O sistema deve possuir mecanismo a opção de cancelamento de paciente na espera.

⮚ Parametrizar o número máximo de dias que pode realizar agendamento futuros.

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

⮚ O sistema deve possuir aviso de prioridade de espera.

⮚ O sistema deve possuir mecanismo integrado para efetuar o preenchimento de APAC e anexar os documentos sem a necessidade de impressão em papel.

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

⮚ O sistema deve possuir cadastro de convênios e prestadores de

serviços.

⮚ O sistema deve possuir cadastro de grupos e subgrupos de exames.

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

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

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

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

⮚ Durante o agendamento dos exames, 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 por CID (obrigatório somente nos exames de imagem), se gestante, idoso ou grupo de risco (tuberculoso, COVID, Hanseníase e outros que julgarem necessários), tipo do agendamento (urgência ou eletivo), número da requisição, exame, data da realização, prestador, turno, horário, quantidade e observação.

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

⮚ Possuir mecanismos 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.

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

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

⮚ A aplicação deve permitir que sejam autorizados exames indicando o prestador.

⮚ O sistema deverá emitir relatórios gerenciais na qual especifica o quantitativo de exames inseridos por prestador, valor de cada item e valor global contratado. Demonstrar o consumo dos exames por item, quantidade ofertada, quantidade realizada, valor consumido e valor disponível por prestador, por dia, mês e ano.

⮚ Disponibilize a opção de bloqueio de agendamento dos mesmos exames para um mesmo usuário em curto prazo de tempo, sendo o intervalo informado pelo contratante.

9.7. DO CONTROLE DE TRANSPORTES:

⮚ A aplicação deve possuir cadastro de tipos de veículos, setores ou

unidades responsáveis.

⮚ O cadastro de veículos deverá informar descrição, tipo, placa, marca, número do chassi, ano do veículo, capacidade/lotação, tipo do combustível e outras informações necessárias.

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

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

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

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

⮚ Disponibilizar cadastro de itens de consumo com sua descrição, unidade de apresentação e fornecedor padrão.

⮚ Elencar os tipos de viagens especificando se deve ser utilizado nos processos de TFD.

⮚ Incluir tipos de despesa e adiantamentos contendo sua descrição e seu valor unitário.

⮚ Possuir cadastro de destinos contendo seu nome, município onde se localiza e telefone.

⮚ Admitir lançamento de eventos para cada veículo contento: data de criação/atualização, tipo de evento, data do vencimento, número de dias que a programação pode ser postergada, indicação se foi realizado, data da realização, e observações gerais do evento.

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

⮚ 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. Relacionar 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 e número do cartão do SUS.

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

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

⮚ Na manutenção do veículo, o sistema deve permitir o lançamento dos itens da manutenção: nome do item, indicação se o era problema em peça original, data da próxima troca, km da próxima troca, número do documento, quantidade, valor unitário, valor total e campo para observações.

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

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

⮚ Deve possuir mecanismo para lançamento de gastos gerais com veículo contento a data da autorização, fornecedor, veículo, motorista, documento de referência, km, item, quantidade, valor e indicação se o mesmo foi autorizado ou cancelado. E oportunizar o acompanhamento dos saldos com cada fornecedor, (em quantidade e valores).

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

⮚ Gerar relatórios automáticos dos procedimentos de transporte do usuário e seu acompanhante, com base na quilometragem percorrida.

⮚ Permitir a importação dos km rodados em transporte de usuários e acompanhantes de acordo com a tabela SUS.

⮚ Gerar relatórios gerenciais conforme necessidade da contratante.

9.8. DO TFD - TRATAMENTO FORA DO DOMICILIO

⮚ O sistema deve permitir que sejam criados os processos de TFD

contendo número, data da abertura, paciente, profissional responsável, cid10, tratamento solicitado, tipo do atendimento e justificativa.

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

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

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

⮚ Apresente relatório/gráficos em tempo real do total de viagens e suas localidades.

9.9. DO ACOLHIMENTO

⮚ A tela de acolhimento deve permitir que sejam registrados

atendimentos sob demanda.

⮚ Deve permitir que os usuários acolhidos possam ser pesquisados através de: nome, data de nascimento, sexo, nome da mãe, CPF, CNS e nome social. (Mínimo 3 informações simultâneas).

⮚ Permitir a inserção do peso, estatura, quadril, cintura, temperatura, pressão arterial, frequência respiratória, pulso, saturação de O2, circunferência

braquial e percentual de gordura cutânea, além de registrar o valor de glicemia, (em jejum e/ou é pós-prandial).

⮚ Deve gerar o IMC por: sexo e faixa etária de acordo com manual do SISVAN.

⮚ Quando usuário for criança a solução deve permitir que sejam registrados perímetro cefálico, torácico, situação vacinal e tipo de alimentação. (Aleitamento exclusivo, misto ou outros).

⮚ O usuário sendo mulher em idade fértil, a aplicação deve registrar se é gestante e informar, data da última menstruação, peso pré-gestacional, altura uterina, toque vaginal, batimentos cardíacos do feto, posição do colo e data provável do parto.

⮚ Possuir funcionalidade para registro das anotações de enfermagem e queixas dos usuários.

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

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

⮚ A solução ofertada deve possuir mecanismo para que sejam listados ao profissional, durante o atendimento, procedimentos previamente relacionados aos seu CBO, permitindo a seleção, clicando sobre o procedimento realizado.

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

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

⮚ A solução deve possuir mecanismo ou funcionalidade para coletar todos os dados necessários para alimentação do e-sus no momento do atendimento do usuário.

⮚ O atendimento do acolhimento deve ser registrado em destaque no prontuário os dados relevantes a todos os atendimentos subsequentes.

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

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

10. DO PRONTUÁRIO ELETRÔNICO MULTIPROFISSIONAL

⮚ Deve haver interoperabilidade com o painel de avisos e quando o

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

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

⮚ A solução deve fornecer os CID’s para o atendimento com base na avaliação realizada pelo profissional, sendo obrigatório quando for emitir solicitação de exames.

exame

⮚ Possuir funcionalidade para registro de resultados de qualquer realizado pelo usuário.

⮚ Permitir funcionalidade para acompanhamento de todos os gráficos constantes no acolhimento.

⮚ Todos os procedimentos realizados durante o acolhimento deverão automaticamente gerar produção ambulatorial (BPA).

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

⮚ A solução ofertada deve possuir mecanismo para que sejam listados ao profissional, durante o atendimento, procedimentos previamente relacionados aos seu CBO, permitindo que selecione procedimentos realizados clicando sobre ele.

⮚ O atendimento do prontuário deve ser registrado em destaque no prontuário os dados relevantes a todos os atendimentos subsequentes.

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

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

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

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

⮚ Conter com funcionalidade que permita ao profissional criar uma nova receita, com base em receitas anteriores já emitidas para o mesmo paciente.

⮚ Durante a elaboração do receituário o sistema deverá permitir a consulta ao REMUME, bem como, lançar medicamentos que não estejam disponíveis na rede municipal.

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

⮚ Deve possuir funcionalidade que permita ao profissional indicar o usuário em observação e a criação de prescrição médica, permitindo que sejam listados os medicamentos, via de administração, posologia e horário da administração com campo para checagem de realização do mesmo.

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

⮚ Também no atestado, o sistema deve permitir que seja registrado acompanhante.

⮚ Permitir emissão de declaração de comparecimento contendo data, horário inicial, horário final e campo para descrição da finalidade.

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

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

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

⮚ A aplicação deve conter funcionalidade que permita ao profissional a criação de novas solicitações de exames com obrigatoriedade de justificação médica com CID.

⮚ Deve possuir mecanismo para registro do final do atendimento, quando serão feitas as cobranças de produção ambulatorial.

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

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

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

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

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

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

⮚ O sistema de prontuário deverá informar quando o usuário de acompanhamento obrigatório não comparecer a unidade de saúde conforme consta em protocolo municipal (Gestante, famílias cadastradas no Bolsa Família, Hipertensos, Diabéticos e outros);

⮚ O Prontuário deverá estar disponível em intranet quando houver a falta de acesso à internet.

11. DO PRONTUÁRIO ODONTOLÓGICO

⮚ Permitir que o planejamento do atendimento seja realizado através da

apresentação da arcada dentária em modo gráfico com clara distinção entre dentes permanentes e dentes decíduos.

⮚ Na arcada dentária deve permitir usar para identificar os procedimentos, realizados e procedimentos a serem realizados em todas as faces dos dentes.

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

⮚ Possuir mecanismo para lançamento de procedimentos para todos os dentes.

⮚ Disponibilizar ao odontólogo todas as funcionalidades do prontuário e relatórios de atendimento integrado.

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

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

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

⮚ A solução deve possuir funcionalidade para consulta do histórico de todos os atendimentos em um único odontograma.

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

⮚ Deve ofertar relatório de produção individual por USF e CBO.

12. DA LISTA DE ESPERA

⮚ Deverá ofertar níveis de urgência a serem utilizados nas filas de espera.

⮚ Deve possuir cadastro para Lista de Espera de diversos serviços.

⮚ Permitir que as listas sejam alimentadas nos locais de atendimento à população.

⮚ Devem permitir que sejam elaboradas listas de espera para cada tipo de serviço disponível na rede de saúde. (Odontologia, médico, fisioterapeuta, nutricionista e outros)

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

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

⮚ A solução deve possuir mecanismo que permita a publicação das listas de espera para consultas públicas (sem necessidade de login) ao sistema bem como parametrizar quais listas deverão estar abertas para consultas públicas e quais informações: (número do protocolo de atendimento; nome do usuário ou iniciais do nome; nome social; nome da mãe; data de nascimento; número do cartão nacional de saúde; número do cpf.)

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

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

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

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

⮚ Permitir cadastramento de ações para cada programa existente na

rede municipal de saúde.

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

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

⮚ Disponibilizar mecanismo para geração de roteiros de entrega de medicamentos para os usuários inseridos em ações programáticas incluindo, bairro, rua, paciente e período de validade.

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

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

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

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

⮚ Possuir mecanismo para acompanhamento visual em formato de gráfico da evolução das dispensações por ano e mês.

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

⮚ Permitir acompanhar através de mapas os locais onde são entregues os medicamentos.

⮚ Disponibilizar que os usuários em cada programa possam ser desativados e, desta forma, suas receitas desconsideradas de novas elaborações de roteiro e montagem de kits.

⮚ Identificar a data de cadastro dos pacientes em cada programa, a data de atualização dos seus dados bem como a data da baixa dos usuários em cada programa.

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

⮚ A montagem do kit deve ser feita através de um processo de linha de montagem, com utilização de login e senha visando otimizar o fluxo de trabalho, atendendo no mínimo as seguintes etapas: geração e 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.

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

14. DO MODULO MEDICAMENTO VIA JUDICIAL

⮚ Ofertar mecanismo para controle de processos judiciais contendo

número do processo, data de abertura, parque requerente, unidade de saúde prazo para cumprimento e observações.

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

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

⮚ Identificar quais os processos que possa gerar algum tipo de bloqueio, multa, o valor da multa e a data do pedido, informar data de recebimento, advogado responsável, número na OAB e telefone do mesmo, 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.

⮚ Permitir que sejam ajustados a cada processo todos os materiais e medicamentos contidos no mesmo (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).

⮚ Gerar das entregas de medicamentos judiciais contendo: 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.

⮚ Disponibilizar impressão de comprovantes de entrega dos itens contendo os materiais e medicamentos dispensados.

15. DOS BENEFÍCIOS

⮚ Ofertar Cadastro de benefícios contendo sua descrição, valor e

procedimento e configuração para controle de saldos

⮚ Possuir cadastro de locais para encaminhamentos.

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

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

⮚ Emitir Laudo Social contendo o gestor, número do laudo social, número da lei, identidade e CPF.

⮚ Possuir campo para informações do histórico da solicitação do benefício e emissão de observações no recibo de entrega de cada benefício

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

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

⮚ Ofertar gerenciamento e emissão de encaminhamentos para cada usuário, o profissional, descrição do encaminhamento, trabalho, vínculo de usuário, renda, data, hora, dia da semana e valor do encaminhamento e campo para observações.

⮚ Possuir mecanismo para emissão de recibos de entrega de benefícios

16. DAS APACS

⮚ Dispõe de mecanismos para gerenciamento de autorizações para procedimento de alta complexidade (APAC).

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

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

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

⮚ Deve possuir campo para identificação da APAC através do seu tipo: Inicial, Continuidade e Sem Continuidade; campos para número da APAC; Para cada APAC através

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

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

⮚ Deve ter o mecanismo de ser inserido no prontuário o ato da consulta com todos os dados já preenchidos automaticamente.

17. DO FATURAMENTO DA PRODUÇÃO AMBULATORIAL

⮚ Deve possuir mecanismo para importação das tabelas de

procedimentos do CMD através do BPAMAG ou SIGTAP.

⮚ Possuir funcionalidade para definição de competências para Produção Ambulatorial com data de início e data final da mesma.

⮚ Ter bloqueio das competências impedindo que qualquer tipo de movimentação seja realizado na mesma, após a finalização das informações/dados inseridos.

⮚ A aplicação ofertada deve possuir mecanismo de configuração que impeça a geração do BPA com informações incorretas, demonstrando as críticas para a devida correção.

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

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

⮚ A contratada deve OBRIGATORIAMENTE: implantar em sua solução mecanismos automáticos integrados ao sistema para demonstrar para onde foi

sua produção (E-SUS/SISAB/FEDERAL/ESTADUAL); oferecer um setor de faturamento exclusivo para que os usuários deste setor possam ser atendidos.

⮚ Gerar gráficos de produção, anual, quadrimestral e mensal por unidade CBO.

⮚ Emitir relatórios gerenciais de produção por: unidade, competência, CBO, procedimentos, custos e outros que a contratante solicitar.

18. DAS IMUNIZAÇÕES/VACINAS

⮚ Possuir funcionalidade para cadastro das doses de vacinas a serem

fornecidas.

⮚ Deve ofertar mecanismo ou funcionalidade para cadastramento dos calendários a serem utilizados no sistema de imunizações indicando a vacina, a dose, descrição, faixas etárias e sexo para cada imunização.

⮚ Possuir funcionalidade para cadastro das faixas etárias a serem utilizadas na criação das imunizações; Mecanismo para cadastro dos tipos de baixa a serem utilizados pela imunização e cadastro de grupos para imunização.

⮚ Funcionalidade para gerenciamento das salas de vacinação disponíveis da rede municipal de saúde contendo a unidade de saúde onde está localizada.

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

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

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

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

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

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

⮚ 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;

⮚ Permitir registro de entradas de imunizações, alimentando automaticamente o estoque; Processo de acertos de estoque; imunizações;

⮚ Ofertar rotina ou funcionalidade para registro de transferências de imunizações entre as salas de vacinação;

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

⮚ Gerar relatório de balanço físico de imunizações por sala de imunização; Emissão do Boletim de Imunizações; relatório de imunizações por bairro

⮚ Deve possuir relatórios que permitam a visualização do estoque de imunizações em outras competências; Acompanhamentos das imunizações por lote e validade.

⮚ Permitir o acompanhamento da movimentação do estoque de imunizações por sala de imunização, imunização e motivo de baixa

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

19. DO PAINEL MULTIMÍDIA

⮚ Possuir mecanismo de Painel para utilização nas salas de espera dos

pontos de atendimento da contratante.

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

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

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

⮚ Deve possuir no momento da implantação informações visuais relacionados com o formato de atendimento e triagem (baseado no protocolo de Manchester) ou outro instituído pelo município com objetivo de orientar aos usuários na maneira como as filas de atendimento serão estabelecidas.

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

20.

BUSINESS INTELIGENTE – CONTROLE E AVALIAÇÃO EM TEMPO

REAL

⮚ Todos os itens deste módulo CONTROLE E AVALIAÇÃO deve ser em tempo

real para que a gestão possa acompanhar todas as informações diárias.

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

⮚ Os indicadores da portaria 2.979 de 12 de novembro de 2019; e outras de acordo com protocolo municipal.

⮚ GEO PROCESSAMENTO online integração com a mobilidade para aplicativo moveis dos agentes de saúde e permitir a localização; controle da ATENÇÂO FARMACEUTICA apresentando em tempo real a relação de usuário que retiraram medicamento; Da ATENÇÂO FARMACEUTICA apresentando em tempo real a relação de medicamento retirados; Da ATENÇÂO FARMACEUTICA apresentando em tempo real os usuários cadastrados nos programas; Da ATENÇÂO BASICA apresentando em tempo real os usuários agendados para o atendimento diário e qual unidade pertence

⮚ Da ATENÇÂO BASICA apresentando em tempo real os pacientes atendidos e qual unidade pertence.

⮚ Da ATENÇÂO BASICA apresentando em tempo real os usuários em aguardando atendimento e qual unidade pertence.

⮚ Da MEDIA/ALTA COMPLEXIDADE apresentando em tempo real os usuários agendados, atendidos, em espera e qual unidade pertence.

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

⮚ Do LABORATORIO em tempo real dos usuários atendidos, aguardando atendimento e total de requisições realizadas no dia, na semana, no mês e no ano.

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

⮚ De Tempo de Atendimento por Turno médico descrevendo cada profissional.

⮚ Tempo de Espera por paciente nas unidades de Saúde.

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

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

⮚ Possuir mecanismo para controle de conteúdo e de acesso.

⮚ Permitir o gerenciamento das fontes de dados, dos módulos analíticos, dos metadados e das estruturas informacionais (Cubos).

⮚ Ofertar repositório de metadados centralizado e único.

⮚ Possuir mecanismo ou funcionalidade para a geração de scripts de extração para múltiplos sistemas gerenciados de bancos de dados; dispor de mecanismo ou funcionalidade para criação dos processos de ETL (extração, transformação e carga); possuir funcionalidade ou ferramenta para gerenciamentos dos modelos de informação; Permitir a integração de bases de dados heterogêneas;

⮚ Possuir funcionalidade ou mecanismo para construção e gerenciamento dos metadados; permitir a execução de mais de um processo simultâneo; criar de gráficos em formatos variados;

⮚ Apresentar em tempo real todos os indicadores da saúde da família descrito neste termo e outros que a gestão municipal requerer.

⮚ Dispor de relatórios integrados demonstrando o atendimento de cada profissional, incluindo tempo de atendimento médico para cada paciente; possuir relatório integrado demonstrando o atendimento e aplicação de cada vacina aplicada; apresentar o controle de transporte para pacientes TFD demonstrando a localidade e o número de pacientes em viagem em tempo real.

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

⮚ Possuir tópicos com a quantidade de pessoas cadastradas, famílias cadastradas, Domicilio Ativos, profissionais ativos.

21. DA PLATAFORMA DE APLICATIVOS MÓVEIS AMBIENTE DE DESENVOLVIMENTO

⮚ Os aplicativos móveis criados no Ambiente de Desenvolvimento devem permitir

sua execução sem a necessidade de qualquer tipo de adaptação, no mínimo sobre as seguintes plataformas:

a) Google Android versão 2.1 ou superior;

b) Apple iOS versão 4 ou superior;

c) RIM Blackberry 4.6.1 ou superior; e

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

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

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

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

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

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

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

f) Data;

g) Hora;

h) Fotos capturadas;

I) Desenhos manuscritos; e

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

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

a) Preenchimento obrigatório ou opcional;

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

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

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

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

a) ao formulário;

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

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

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

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

⮚ Os operandos das fórmulas de cálculo devem incluir:

a) Xxxxxx do formulário;

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

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

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

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

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

b) Somatório; e

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

d) Permitir a inclusão de fórmulas para cálculos de atendimento por especialidade, oferta de exames e outros atendendo as portarias ministeriais vigentes e outras legislações atuais.

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

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

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

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

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

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

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

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

⮚ Deve permitir a captura de coordenadas de GPS (Global Positioning System) do dispositivo móvel, se houver, para registro georreferenciado no momento da execução da tarefa de campo.

22. DO AMBIENTE DE EXECUÇÃO DE APLICATIVOS MÓVEIS

⮚ Deve suportar a execução dos aplicativos criados no Ambiente de Desenvolvimento sem a necessidade de qualquer tipo de adaptação, sobre dispositivos móveis operando, no mínimo, as seguintes plataformas:

a) Google Android versão 4.2 ou superior;

b) Apple iOS versão 4 ou superior;

c) RIM Blackberry 8.1 ou superior; e

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

⮚ A execução dos aplicativos deverá ocorrer através de código nativo de cada uma das plataformas, não sendo permitida a execução através de navegador internet do dispositivo móvel.

⮚ Deve ser um aplicativo instalado no dispositivo móvel e não acessar através de navegadores de internet.

⮚ Não deve permitir simulação de aplicativo através de páginas de internet ou do navegador do dispositivo móvel.

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

⮚ A instalação do Ambiente de Execução nos dispositivos móveis deve poder ser realizada das seguintes formas:

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

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

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

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

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

⮚ A sincronização de dados entre os aplicativos móveis e a Infraestrutura Central da Plataforma deve se dar alternativamente de forma automática ou manual, permitindo sua operação on-line ou off-line, quando, por exemplo, o usuário estiver fora de áreas de cobertura das operadoras de telefonia móvel ou rede wi-fi.

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

⮚ Caso a sincronização não seja possível em determinado momento, por falta de cobertura de telecomunicação, os dados devem ser mantidos no repositório do dispositivo móvel para sincronização posterior.

⮚ A sincronização deve ser bidirecional, ou seja, durante sua realização todos os dados coletados no dispositivo móvel são transmitidos para a Infraestrutura Central da Plataforma, e desta são recebidos os dados sobre novas atividades de campo a cargo do usuário, entre outras informações.

⮚ Novos aplicativos, bem como as customizações executadas em aplicativos já existentes, empregando o Ambiente de Desenvolvimento, devem ser disponibilizadas para os usuários em campo, automaticamente através da sincronização, sem a necessidade de intervenção dos mesmos.

23. DO AMBIENTE DO ACS – MOBILIDADE

⮚ Deve possuir os formulários do E-SUS integrados com o sistema de gestão.

⮚ Formulário de Cadastro Individual – E-SUS.

⮚ Formulário de Visita Domiciliar– E-SUS.

⮚ Formulário de Cadastro Domiciliar– E-SUS.

24. DA VIGILÂNCIA SANITÁRIA

⮚ 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:

⮚ Nome do Questionário

⮚ Tipo de Estabelecimento

⮚ Subtipo de estabelecimento (Atividade exercida)

⮚ Ativo/Inativo.

⮚ Tipo de Prestador

⮚ Nível de Atenção

⮚ Grau Complexidade

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

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

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

⮚ Descrição

⮚ Tipo de Comprovação

⮚ Nível

⮚ Peso

⮚ Pontos

⮚ Referência

⮚ Ativa/Inativa.

⮚ Tipo de Pergunta (Sim, Não, NA/ Múltipla Escolha / Única Escolha)

⮚ Comentário

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

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

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

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

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

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

⮚ Titulo

⮚ Texto (com possibilidade de formatação HTML)

⮚ Data da tramitação (automática)

⮚ Usuários remetente (automático)

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

⮚ Anexos

⮚ O Sistema deverá apresentar um formulário para a inclusão de denúncias. O formulário deverá possuir no mínimo os seguintes campos:

⮚ Título

⮚ Data da Denúncia

⮚ Descrição

⮚ Tipo da denúncia

⮚ Estabelecimento

⮚ Anexos

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

⮚ Título

⮚ Data da denúncias

⮚ Descrição

⮚ Situação

⮚ Meio de entrada da denúncia

⮚ Denunciado

⮚ Usuário

⮚ Anexos

⮚ O Sistema deverá permitir a pesquisa de denúncias com a utilização de no mínimo os seguintes filtros:

⮚ Faixa para data da reclamação

⮚ Estabelecimento

⮚ O sistema deverá permitir a elaboração de documento de ATAS de reuniões contendo, no mínimo, os seguintes campos:

⮚ Descrição da Reunião

⮚ Data da Reunião

⮚ Local da reunião

⮚ Usuário responsável

⮚ Participantes

⮚ Anexos

⮚ Data de conclusão

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

⮚ Tipo de Estabelecimento

⮚ Atividade Exercida

⮚ Tipo de endereço

⮚ Equipamentos que possui

⮚ Tipo de Estabelecimento

⮚ Tipo de Pessoa

⮚ CNPJ

⮚ Tipo de CNPJ

⮚ Razão Social

⮚ Nome Fantasia

⮚ O Sistema deverá apresentar o resultado da consulta em um mapa georreferenciado, com todos os endereços dos estabelecimentos resultantes da pesquisa.

⮚ 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:

⮚ Nome do Estabelecimento

⮚ Endereço Eletrônico

⮚ CNAE do Estabelecimento

⮚ Tipo de Estabelecimento

⮚ Subtipo de Estabelecimento

⮚ Endereço completo

⮚ Telefone e Fax

⮚ Nome e E-mail da pessoa de contato.

⮚ 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:

⮚ Alvará Razão Social

⮚ Nome Fantasia

⮚ CPF/CNPJ

⮚ CNAE

⮚ Solicitação Estabelecimento

⮚ Cidade

⮚ UF

⮚ CNPJ Criado em

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

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

⮚ Permitir que o administrador faça a manutenção das tabelas de dados do Sistema.

⮚ Que o administrador faça a criação das contas de usuários para os membros da vigilância sanitária e estabelecimentos.

⮚ O sistema deverá possibilitar que qualquer usuário seja capaz de acessá-lo através da inserção do tipo, identificação e senha do usuário através de uma página de entrada.

⮚ O sistema deverá possuir procedimento para recuperação automática da senha caso um usuário a tenha esquecido

⮚ Deverá restringir o acesso do usuário às suas funcionalidades de acordo com seus papéis

⮚ Permitir que o administrador atribua os papéis dos usuários.

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

⮚ Solicitação de Alvará Sanitário,

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

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

⮚ Solicitação de Baixa de Responsável Técnico,

⮚ Solicitação de Inclusão de Responsável Técnico,

⮚ Solicitação de Licença de Transporte,

⮚ Ofertar alerta da data de vencimento do alvará sanitário de no mínimo 30 dias antes.

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

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

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

⮚ O sistema deverá possuir um local o qual os seguintes dados da própria vigilância podem ser exibidos e editados:

⮚ Informações Cadastrais,

⮚ Razão Social,

⮚ Instituição / Órgão Superior,

⮚ Secretário Municipal de Saúde,

⮚ Responsável de Vigilância Sanitária,

⮚ Telefone,

⮚ Celular,

⮚ E-mail,

⮚ Dados Bancários,

⮚ Denominação,

⮚ Tipo da Conta Bancária,

⮚ CPF/CNPJ,

⮚ Banco,

⮚ Agência,

⮚ Digito da Agência,

⮚ Conta Corrente,

⮚ Digito da Conta Corrente,

⮚ Carteira,

⮚ Tipo Modalidade Carteira,

⮚ Modalidade Carteira,

⮚ Dados de Endereçamento,

⮚ CEP,

⮚ Logradouro,

⮚ Complemento,

⮚ Bairro,

⮚ Estado,

⮚ Cidade,

⮚ Nome,

⮚ E-mail,

⮚ Login,

⮚ CPF,

⮚ Número Portaria,

⮚ Xxxxxxxxxx,

⮚ Telefone.

⮚ Funcionalidade que permite a vigilância sanitária informar quais as atividades são de responsabilidades municipais e quais são do Estado, permitindo que o sistema automaticamente filtre as solicitações dos estabelecimentos.

⮚ Opções de cadastro de usuário contador que deseja gerenciar um ou mais de seus estabelecimentos, contendo:

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

⮚ CPF/CNPJ

⮚ Inscrição Estadual

⮚ Inscrição Municipal

⮚ Razão Social

⮚ Nome Fantasia

⮚ E-mail

⮚ Telefone

⮚ Celular

⮚ Site

⮚ Conselho Regional de Contabilidade

⮚ Nº CRC

⮚ Dados dos Profissionais

⮚ Cargo

⮚ Nome Completo

⮚ CPF

⮚ Conselho Regional de Contabilidade

⮚ Nº CRC

⮚ Telefone

⮚ Endereço do Estabelecimento

⮚ CEP

⮚ Logradouro

⮚ Número

⮚ Complemento

⮚ Bairro

⮚ Estado

⮚ Cidade

⮚ Localização

⮚ Localização em Mapa

⮚ Latitude

⮚ Longitude

⮚ Cadastro de Estabelecimentos

⮚ Vinculação de Estabelecimento

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

⮚ Gerar Solicitações

⮚ Acompanhar andamento das solicitações

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

⮚ CNPJ

⮚ Inscrição Estadual

⮚ Inscrição municipal

⮚ CPF

⮚ RG

⮚ Data Nascimento

⮚ CNAE

⮚ Razão Social

⮚ Nome Fantasia

⮚ Telefone

⮚ Endereço eletrônico

⮚ E-mail Principal

⮚ Nome da Pessoa de Contato

⮚ Função da Pessoa de Contato

⮚ E-mail da Pessoa do Contato

⮚ Telefone da Pessoa de Contato

⮚ Tipo de Endereço

⮚ Logradouro

⮚ Número

⮚ Complemento

⮚ Bairro

⮚ CEP

⮚ UF (Lista de Estados)

⮚ Localização

⮚ Cidade (Lista baseada na UF selecionada)

⮚ O 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:

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

⮚ Descrição do Documento.

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

⮚ A aplicação deve possuir mecanismo para os administradores do sistema possam cadastrar a lista de documentos necessários para cada tipo de

estabelecimento, identificando quando determinado documento é ou não obrigatório.

⮚ A cada estabelecimento, a aplicação deve permitir que sejam cadastrados, editados e excluídos equipamentos, com, no mínimo, as seguintes informações para cada equipamento:

⮚ Tipo de Equipamento.

⮚ Nome do Equipamento.

⮚ Modelo.

⮚ Descrição.

⮚ Empresa Manutenção

⮚ Última Manutenção

⮚ Ano de Fabricação

⮚ A solução deverá enviar um e-mail ao estabelecimento quando algum dado ou documento tenha sido rejeitado.

⮚ A aplicação deve permitir que os estabelecimentos preencham formulários de solicitação de alvará com, no mínimo, as seguintes informações:

⮚ Número do protocolo

⮚ Identificação do estabelecimento

⮚ O sistema deve permitir que os próprios estabelecimentos emitam suas guias de pagamento de alvarás.

⮚ A aplicação deve possuir mecanismo para o agendamento manual de eventos com, no mínimo, as seguintes informações:

⮚ Título.

⮚ Descrição.

⮚ Data de início.

⮚ Data de término

⮚ Endereço.

⮚ Tipo de evento

⮚ Arquivos anexados (opcional)

⮚ participantes

⮚ O Sistema deverá possibilitar a visualização dos compromissos agendados, em formato de calendário, com visualizações em formato diário, semanal e mensal.

⮚ A aplicação deve permitir que os estabelecimentos possam acessar o sistema e consultar todas as inspeções atreladas ao estabelecimento.

25. DA VIGILÂNCIA EPIDEMIOLÓGICA

⮚ Possuir funcionalidade ou mecanismo para criação das fichas de

investigação da vigilância epidemiológica contendo descrição, XXX’x 10 compatíveis

⮚ Deve possuir mecanismo para cadastramento das perguntas que irão compor as fichas de investigação de cada notificação; Dispor de mecanismo ou funcionalidade que permita a criação das perguntas que que compões cada ficha de investigação contendo:

⮚ campo para o questionamento a ser realizado

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

⮚ campo para inserção de ajuda para cada pergunta e campo de observação a ser utilizado nos questionamentos pertinentes; Mecanismo para gerenciamento de notificações contendo os campos:

⮚ número da notificação, tipo da notificação (negativa, individual, surto ou Inquérito Tracoma), agravo ou doença, data da notificação, uf,

município, unidade de saúde notificadora, data dos primeiros sintomas, paciente, data de nascimento, idade (em Anos, Meses, Xxxx e Horas), sexo, gestante, raça/cor, escolaridade, número do cartão SUS e nome da mãe;

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

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

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

⮚ Quando médico inserir a ID de alguma doença notificável , ficha de notificação é obrigatória.

⮚ Deve possuir funcionalidade ou mecanismo que permita que sejam listados na vigilância epidemiológica todos os CID’s relacionados nos atendimentos médicos em locais informatizados, que forem notificáveis.

⮚ Deve possuir mecanismo ou funcionalidade que permita o envio de e- mails para os responsáveis pelo setor de epidemiologia em intervalos pré- definidos, listando todos os CID’s notificáveis relacionados em atendimentos médicos nos locais informatizados.

26. DO MÓDULO DE CERTIFICAÇÃO DIGITAL

⮚ Os componentes do módulo devem estar aderentes ao DOC-ICP-15 e

demais documentos relacionados (DOC-ICP-15.01, DOC-ICP-15.02 e DOC- ICP-15.03), que trata dos requisitos técnicos para solução de assinatura digital no âmbito da ICP-Brasil.

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

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

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

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

⮚ Suportar os Sistemas Operacionais Linux SuSe, RedHat, Debian e Ubuntu e Windows XP, 2000, 2003, Vista e Windows7, 8.1 e 10.

⮚ Suportar os navegadores Internet Explorer 8 e superiores, Firefox 52 e superiores e Edge;

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

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

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

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

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

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

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

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

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

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

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

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

⮚ Componente Carimbador para requisitar carimbo de tempo;

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

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

27. DO COMPONENTE PARA ASSINATURA DIGITAL

⮚ Deve gerar assinaturas simples, coassinaturas e contra-assinaturas no

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

⮚ Cifragem do resumo criptográfico (Assinatura Digital);

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

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

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

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

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

28. DO COMPONENTE PARA CARIMBO DO TEMPO

⮚ Deve estar preparado para o uso de Carimbo de Tempo por meio de

integração com Solução externa, via TimeStamp Protocol – TSP, de acordo com as definições da Resolução nº. 78 de 06 de Abril de 2010 do ITI.

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

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

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

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

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

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

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

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

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

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

⮚ Deve seguir as definições do documento DOC-ICP-15.01 da ICP-

Brasil para validação de assinaturas digitais nos padrões CAdES e XAdES.

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

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

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

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

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

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

⮚ Tipo de Política de Assinatura Utilizada;

⮚ Hash do Documento Assinado;

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

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

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

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

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

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

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

⮚ Deve ser capaz de validar qualquer tipo de certificado digital e sua

correspondente cadeia de certificação, padrão ICP-Brasil.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

⮚ A empresa deve seguir o padrão brasileiro de assinatura digital utiliza

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

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

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

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

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

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

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

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

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