Anexo I - TERMO DE REFERÊNCIA

Anexo I - TERMO DE REFERÊNCIA

DO OBJETO

Contratação de empresa especializada para fornecimento de licença de uso de software de registro eletrônico em saúde (SRES) com execução de serviços técnicos de manutenção (corretiva, adaptativa e evolutiva), atualização, suporte técnico, consultoria técnica, customização, implantação, migração de dados legados e treinamento, incluindo acompanhamento presencial e remoto, e suporte técnico para a secretaria municipal da saúde, suas unidades de atendimento.

DA JUSTIFICATIVA

É necessário introduzir novos mecanismos de gerenciamento dos processos assistenciais, modernizando a regulação do acesso aos serviços de saúde. A implantação de um SRES nesta secretaria da Saúde, objetiva:

Operacionalizar e garantir aos cidadãos o acesso universal e igualitário aos serviços de saúde;

Prover o Município de uma solução tecnologicamente atual e homogênea, integrando as informações de saúde através do Cartão Nacional de Saúde (CNS), do CPF e da gestão de redes e de territórios assistenciais;

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

Criar ponto de fusão digital das informações dos munícipes, baseado nas informações do SRES para ampla socialização do conhecimento, como também realizar ações de monitoramento e avaliação da gestão;

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

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

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

Melhoria da agilidade decisória e tomada de decisão dos gestores da saúde, no elenco de suas prioridades;

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

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

Permitir a mobilidade e rastreabilidade dos dados coletados por todos os agentes envolvidos na operacionalização da secretaria de saúde;

Para que essas premissas possam atingir êxito na realização é necessária uma ampla organização e sistematização dos sistemas de informação, não só no nível local dos Estabelecimentos Assistenciais de Saúde (EAS), mas também em toda esfera municipal. Isto posto, justifica-se a necessidade de implantar, consolidar e fortalecer o uso de um robusto SRES pela municipalidade.

DAS ESPECIFICAÇÕES TÉCNICAS

MIGRAÇÃO DE DADOS

A migração de dados legados consiste na conversão e absorção de todas as bases de dados existentes e indicadas a converter pelo contratante antes da implantação do SRES. Este processo se dará em paralelo ao processo de implantação do sistema, conforme cronograma a ser elaborado em conjunto pelas partes, sempre de forma organizada e clara, seguindo os seguintes preceitos:

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

A empresa fornecedora do SRES deve importar os seguintes dados legados:

Cadastro de cidadãos;

Registros de prontuário;

Históricos de consumo de medicamentos;

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

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

A empresa fornecedora do SRES deve disponibilizar equipe com experiência em serviço de migração de dados para execução das rotinas de importação. Deve ainda, disponibilizar de ferramentas adequadas para a correta e eficiente migração dos dados e oferecer serviços de consultoria técnica para resolução de problemas e conflitos inerentes ao serviço de importação, tais como detecção de inconsistências e incoerências.

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

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

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

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

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

ADAPTAÇÕES LEGAIS

Serão sempre motivadas por alterações na legislação municipal, estadual ou federal.

O prazo para desenvolvimento sempre será o prazo de vigência da referida legislação.

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

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

DEMAIS ADAPTAÇÕES E EVOLUÇÕES

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

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

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

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

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

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

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

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

DO LICENCIAMENTO DO SRES

O SRES alvo deste processo aquisitivo consiste em fornecimento, pelo tempo que durar o contrato, na cessão do direito de uso do SRES pela secretaria de saúde, assim como todos seus entes, conveniados e contratados. Nesta licença não deverão haver restrições quanto ao número de usuários, estações de trabalho, ou unidades de atendimento que utilizarão o SOFTWARE, sendo também facultativo a municipalidade disponibilizar o mesmo a todos seus prestadores de serviço, de forma a gerir todos os serviços prestados, direta ou indiretamente, não sendo permitida a cobrança de custo adicional de licenciamento, caso o número de usuários, acessos simultâneos e/ou estações de trabalho seja alterado para mais ou para menos. Sempre haverá entendimento claro de que esta variação é automaticamente licenciada e, não implica em ônus a municipalidade.

DAS GARANTIAS

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

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

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

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

INCIDENTES 03: Caracterizarão incidentes deste tipo, casos em que o atendimento ao público é comprometido, mas, existe alguma forma de contorno paliativo. O registro deste tipo de incidente pode ser feito diretamente no sistema de chamados eletrônico da CONTRATADA e, o atendimento deve iniciar-se em até 1 dia útil.

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

DOS CANAIS DE COMUNICAÇÃO

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

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

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

DA MANUTENÇÃO E DO SUPORTE

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

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

Manutenções que envolvam customização, adaptação ou evolução, serão pagas sob demanda, de acordo com a autorização prévia da secretaria.

DAS MANUTENÇÕES

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

Entende-se por ‘manutenção legal’, aquela que for necessária para adequar o sistema aplicativo a um novo quadro normativo originado por alteração na legislação municipal, estadual ou federal. Este cenário não aceitará também consumo de horas previstas para customização, adaptação ou evolução. Os prazos referentes a estas demandas serão sempre os previstos na legislação, salvo os da legislação municipal, que serão acordados, caso a caso entre as partes.

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

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

DO SUPORTE

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

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

Deverá ser disponibilizado, pela empresa fornecedora do SRES equipe para suporte, correção de erros e atendimento de dúvidas, sempre restrito à equipe técnica do município, seja à distância (atendimento remoto) ou presencial (atendimento in loco), de acordo com a necessidade da mesma, durante todo o período de contrato, respeitando os horários descritos.

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

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

DO REGISTRO DE SOLICITAÇÕES

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

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

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

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

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

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

Número do chamado – objetivando a identificação única do mesmo;

Data e hora de abertura;

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

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

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

COMUNICAÇÕES ALTERNATIVAS

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

DAS PROPOSTAS COMERCIAIS

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

Solicitação recebida (de forma integral);

História de usuário (resumo que será usado para contextualizar a alteração);

Principais alterações a serem feitas no SRES para atendimento da demanda;

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

Valor do orçamento (conforme valor da hora, constante em contrato);

Prazo para aprovação do orçamento;

Prazo para entrega da solicitação;

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

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

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

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

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

DO AMBIENTE DE TREINAMENTO

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

DAS ATUALIZAÇÕES

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

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

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

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

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

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

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

DAS CAPACITAÇÕES E TREINAMENTOS

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

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

POR PARTE DA SECRETARIA DE SAÚDE:

Avaliação dos técnicos da CONTRATADA envolvidos nos treinamentos e capacitações;

Definição dos objetivos a serem alcançados a cada treinamento ou capacitação;

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

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

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

POR PARTE DA CONTRATADA

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

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

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

Finda a parte processual do processo licitatório, a empresa vencedora será submetida a avaliação de atendimento às exigências editalícias.

A apresentação do sistema se realizará in loco, respeitando todos os protocolos exigidos em virtude da pandemia de Covid-19.

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

Na ocasião da realização da apresentação do sistema, em data, horário e local a serem estipulados pela Secretaria de Saúde.

A apresentação formal do sistema será analisada por uma comissão especial de avaliação, nomeada e designada através de portaria.

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

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

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

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

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

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

DO PROJETO DE IMPLANTAÇÃO

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

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

Desenvolver, com auxílio da gestão da Secretaria de Saúde, o projeto de implantação. A gestão do projeto deverá ser executada por profissionais da empresa fornecedora do SRES, devidamente capacitados, que exercerão a função de gerente de projeto, responsáveis por todo o acompanhamento da implantação bem como da execução dos serviços de acordo com as especificações do cronograma definido. O projeto não poderá ter prazo de execução superior a 6 meses após a assinatura do contrato.

DESCRITIVO TÉCNICO DO SRES

CARACTERÍSTICAS TÉCNICAS OBRIGATÓRIAS

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

Requisitos não funcionais

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

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

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

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

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

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

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

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

Deve utilizar de banco de dados de código aberto, com minimamente as seguintes características: possuir todas as características de um sistema gerenciador de bancos de dados relacional; possuir controle de concorrência multi-versão; permitir indexação; não possuir limitação em relação ao tamanho do banco de dados; não possuir limitação em relação ao número de acessos ou transações (limitado a capacidade dos servidores); permitir minimamente 30 TB por tabela em sua estrutura; permitir número ilimitado de linhas em uma tabela; não limitar o número de índices; permitir rotina de backup íntegro e/ou incremental, sem impactos em performance e, com garantia de integridade de dados em um momento específico; permitir o uso de replicação para garantir alta disponibilidade; permitir o uso de pool para gerenciamento de conexões, de modo a garantir melhor uso do hardware, aumentando a performance; permitir o uso de cache para acesso rápido a dados com alto consumo; permitir uso de objetos espaciais, como pontos, linhas, segmentos, polígonos, sem uso de artifícios não nativos ao banco de dados; exigir o tráfego com uso de criptografia entre os servidores de aplicação e as estações (https) e entre os servidores de aplicação e o banco de dados, visando evitar o sequestro de informações que trafegam em rede (para criptografia, deve ser possível usar certificados emitidos pelo letsencrypt ou outra fonte gratuita e confiável); garantia de atomicidade das transações; garantia de consistência dos dados, através da execução de transações isoladas; garantia de isolamento das transações, de modo que cada transação ocorra sem necessidade de conhecimento de outras; permitir o uso de particionamento dos bancos de dados, permitindo armazenamento em diversos discos rígidos ligados ao servidor, visando melhorar a performance e segurança; todos os recursos administrativos (usuários, grupos de acesso, partições de dados, e outros) relativos ao banco de dados não devem possuir limitações; o banco de dados a ser utilizado deverá obrigatoriamente possuir recursos de arquivamento de log, permitindo a recuperação automática após queda (crash) do sistema; deve possuir mecanismo de controle de concorrência de multi-versão (MVCC) onde processos de leitura não bloqueiem processos de escrita e vice-versa reduzindo de forma drástica a contenção entre transações concorrentes e paralisação parcial ou completa (deadlock); o banco de dados adotado deve possuir mecanismo para cópias de segurança online permitindo sua restauração point-in-time, que refletirá exatamente o mesmo ambiente do momento em que o mesmo foi realizado; deve suportar minimamente índices b-tree, hash, gist, spgist, gin, e brin, permitindo a melhor escolha para cada situação; deve ser baseado em arquitetura TOAST (The Oversized-Attribute Storage Technique); deve permitir a criação, pelo operador, de novos: Tipos de dados, Funções, Operadores, Funções de Agregação, métodos de índice. Além de permitir a utilização de mais de uma linguagem procedural;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Requisitos funcionais e regras de negócio

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

Os requisitos funcionais, foram divididos em eixos organizacionais, para facilitar à gestão municipal a agregação dos recursos que espera-se obter com esta contratação. Importante ressaltar neste ponto que, a organização segue o modelo organizacional deste município e, não obrigatoriamente deve ser seguido em sua organização no software apresentado. Caberá, contudo a empresa vencedora garantir que as funcionalidades e recursos sejam apresentados nesta ordem, visando organizar a avaliação de conformidade.

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

Tipo: Requerido para a prova de conceito, apresentação.

Eixo técnico

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

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

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

O SRES deve possuir parametrização para o local de armazenamento dos logs de utilização do sistema, permitindo que o mesmo seja armazenado em outro banco de dados, se a Secretaria de Saúde assim desejar, permitindo aumentar a eficiência do processo de leitura e escrita no banco de dados onde serão armazenados os dados a serem gerenciados pela aplicação ofertada;

Deve possuir mecanismo para uso do barramento SOA - SUS Cartão Nacional de Saúde, com as interfaces PIX/PDQ;

Deve possuir mecanismo para uso do barramento de envio de vacinas ao SIPNI, para realizar envios de vacinas contra COVID-19. (Este ponto será considerado apresentado, evidenciando declaração de outro município de que usa esta solução para envio normalmente, com data não inferior a 30 dias anteriores a realização da prova de apresentação. Este item será aceito neste formato devido a necessidade de autorização federal para uso do ambiente);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AGENDAMENTO DE CONSULTAS

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

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

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

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

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

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

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

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

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

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

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

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

A tela de agenda deve disponibilizar minimamente os seguintes filtros:

Unidade destino do paciente;

Especialidade;

Profissional;

Cidadão;

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

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

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

Pacientes em processo de acolhimento;

Pacientes acolhidos;

Pacientes em atendimento;

Pacientes atendidos;

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

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

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

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

Nome e/ou nome social;

Foto;

Endereço;

Sexo;

Data de nascimento;

Idade;

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

CPF;

Identidade;

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

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

Idoso (a);

Pessoa com deficiência;

Gestante;

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

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

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

Atendimento de acolhimento;

Atendimento em prontuário;

Cancelamento do agendamento;

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

Transferência;

Cancelamento;

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

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

Motivo do cancelamento;

Observações sobre o cancelamento;

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

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

Agendamentos em um determinado período;

Cotas;

Cronogramas;

Detalhado de atendimentos;

Estatísticas por período;

PRODUÇÃO AMBULATORIAL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Atendimentos por profissional;

Atendimentos RAAS;

Atendimentos por CBO e unidade;

Atendimentos por CBO e idade;

Atendimento por CBO e procedimento;

Atendimento por XXX e procedimento;

Consolidado de produção mensal;

Produção analítica por profissional;

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

Atendimentos por idade e sexo;

Faturamento dos profissionais;

Faturamento mensal;

Procedimentos mais realizados;

Procedimentos não faturados;

Produção por unidade de saúde;

Produção por especialidade.

ATENÇÃO PRIMÁRIA

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

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

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

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

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

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

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

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

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

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

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

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

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

Forma de selecionar os tipos de fichas a exportar;

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

Relatório simplificado de fichas exportadas no processo;

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

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

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

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

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

Ficha;

CBO;

Unidade de Saúde;

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

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

Atendimentos dos cidadãos (fichas);

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

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

Condutas registradas nas fichas;

Conferência de produção;

Consolidado de cadastros;

Consolidado por Profissional;

Domicílios registrados no sistema;

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

Marcadores de consumo alimentar;

Procedimentos faturados e-SUS/BPA;

Produtividade Odontológica Mensal;

Totais de famílias e integrantes;

Visitas domiciliares;

Visitas domiciliares por ACS;

Visitas domiciliares não realizadas;

CONTROLE DE AUTORIZAÇÕES À TERCEIROS

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

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

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

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

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

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

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

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

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

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

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

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

Deve possuir mecanismo para criação de cronogramas de atendimento para cada exame, determinando os dias e horários em que o mesmo poderá ser marcado para atendimento pelo prestador;

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

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

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;

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

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

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

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

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

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

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

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

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

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

Deverá possibilitar a configuração da aplicação de modo que a mesma realize automaticamente o cancelamento das autorizações que não tenham sido confirmadas pelo prestador até o prazo limite para a confirmação, bem como permitir que seja configurado que ao realizar os cancelamentos a aplicação retorne o saldo das mesmas aos seus respectivos orçamentos e fiquem disponíveis para serem utilizados por novas autorizações;

Deve possuir minimamente os seguintes relatórios:

Procedimentos autorizados por cidadão;

Procedimentos autorizados por município;

Procedimentos autorizados por prestador;

Procedimentos autorizados por unidade solicitante;

Procedimentos autorizados por unidade autorizadora;

Saldo dos orçamentos por município;

Saldo dos orçamentos por unidade;

Saldo dos orçamentos por prestador;

Totais de autorizações e procedimentos autorizados;

Procedimentos faturados por prestador;

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

CONCESSÃO DE BENEFÍCIOS

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

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

Possuir cadastro de locais para encaminhamento do benefício;

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

Deve possuir 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, a fim de identificar de forma simples se o mesmo se encontra autorizado, negado ou se está em análise;

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

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

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

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

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

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

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

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

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

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

CONTROLE DE ESTOQUES E C.A.F.

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

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

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

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

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

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

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

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

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

Permitir cadastrar grupos e subgrupos para os materiais;

Deve permitir identificar quando o material é do tipo medicamento;

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

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

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

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

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

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

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

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

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

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

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

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

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

Deve possuir rotina para pesquisa da posição de estoque utilizando filtros como competência inicial e final, material/forma de apresentação e ponto de distribuição;

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

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

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

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

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

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

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

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

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

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

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

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

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

Deve possuir funcionalidade para geração da transferência dos materiais e medicamentos solicitados pelos pontos de distribuição, com base na requisição de abastecimento;

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

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

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

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

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

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

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

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

Deve permitir o operador cadastrar e gerenciar as receitas do cidadão, contendo minimamente as informações de: cidadão, profissional da receita, data da receita, data de validade da receita, e lista de materiais/medicamentos prescritos, contendo o nome/apresentação do material/medicamento, quantidade prescrita, a quantidade máxima que o cidadão pode retirar por vez, a posologia, a quantidade já entregue do medicamento e disponibilizar o salto por item;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

GESTÃO DE PROCESSOS JUDICIAIS DE MEDICAMENTOS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CONTROLE DE DENGUE

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

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

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

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

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

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

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

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

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

PAINEL DE CHAMADAS

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

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

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

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

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

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

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

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

PRONTUÁRIO ELETRÔNICO DO CIDADÃO

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

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

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

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

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

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

Caso o paciente em atendimento seja mulher em idade fértil, a aplicação deve registrar se a mulher está gestando, caso sim, registrar a data da última menstruação, peso pré-gestacional, altura uterina, toque vaginal, batimentos cardíacos do feto, posição do colo, data provável do parto, se a gestação é planejada, se é gestação de risco bem como criar acompanhamento através de controle gestacional alertando outros profissionais de que esta paciente está em acompanhamento gestacional;

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

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

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

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

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

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

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

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

Deve permitir a emissão de declaração de comparecimento, contendo, no mínimo, informações de data, horário inicial, horário final e observações, além de registrar se o paciente estava acompanhado;

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

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

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

Na lista de problemas deve ser possível registrar: descrição do problema, codificação (CID-10 ou CIAP-2), tipo (cadastrável com possibilidade de inativação), estado do problema, observações, data de início do problema, data final do problema;

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

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

Dele permitir mesclar problemas existentes;

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

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

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

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

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

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

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

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

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

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

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

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

Deverá possuir campo para informar as queixas do paciente;

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

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

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

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

Deve possuir funcionalidade para registro da propedêutica com a possibilidade de registro de data e hora fracionada (mantendo a data e hora do registro), com campos de texto livre para informar no mínimo os seguintes dados e suas respectivas avaliações: ‘cabeça e pescoço’; ‘boca, nariz, faringe e laringe’, ‘olhos’, ‘sistema auditivo’, ‘sistema nervoso’, ‘sistema respiratório’, ‘sistema circulatório/vascular’, ‘sistema digestório’, ‘sistema gênito-urinário’, ‘pele, mucosas e anexos’, ‘sistema músculo-esquelético’, ‘sistema endócrino’, ‘saúde mental’;

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

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

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

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

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

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

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

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

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

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

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

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;

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

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

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

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

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

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

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

Deve possuir funcionalidade para cadastramento de receitas padrões 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;

Deve emitir receita normal, controlada e de controle especial de acordo com os medicamentos inseridos pelo profissional;

Deve conter mecanismo a fim de possibilitar profissional solicite informações a outro profissional de maneira que o profissional solicitado seja informado sobre o questionamento e possa responder ao profissional solicitante, que receberá aviso de recebimento do retorno do seu questionamento, podendo este questionamento ser finalizado;

Deverá prover alerta de itens do componente especializado, LME, para emissão de laudo padronizado para a solicitação e autorização dos mesmos, bem mecanismo para preenchimento dos mesmos;

No receituário o profissional deve poder verificar quais medicamentos possui na rede de saúde, bem como se o mesmo pertence a lista de medicamentos básicos, porém deve haver a possibilidade do lançamento de medicamentos que não sejam encontrados na rede municipal de saúde;

Deve ser possível identificar o medicamento como sendo de uso contínuo na receita a ser emitida ao paciente, bem como demais informações como, via de administração, quantidade e posologia;

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

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

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

Possibilitar a criação de layout personalizado para a emissão do atestado;

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

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

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

Deve possuir mecanismo de consulta as imunizações recebidas pelo paciente bem como mecanismo que possibilite o lançamento de imunização ao paciente a partir do atendimento do mesmo;

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

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

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

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

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

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

Xxxx possuir mecanismo para informar o desfecho onde a data deve permitir informar fracionada, poder escolher uma classificação de especialidade referente ao atendimento caso não tenha sido informado no início, deve permitir informar o tipo de desfecho cadastrável, campo para informar se foi verificado por médico responsável e campo para registrar observações do desfecho do atendimento;

Deve permitir assinar digitalmente em meio eletrônico os documentos do atendimento com a utilização de certificado eletrônico válido ICP-Brasil. Esta assinatura assinará os dados salvos no banco de dados impossibilitando sua alteração, garantindo desta forma a invalidação das informações caso estes dados sejam alterados indevidamente;

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

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

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

O certificado a ser utilizado não pode estar expirado;

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

O certificado a ser utilizado não pode estar revogado;

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

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

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

Xxxx possuir delegação de poder para registro de dados no prontuário de modo que o atendimento seja assinado posteriormente pelo responsável que delegou poderes ao usuário;

Permitir planejamento do atendimento odontológico realizado através da apresentação da arcada dentária em modo gráfico com distinção entre dentes permanentes, dentes decíduos, faces entre outros;

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

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

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

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

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 oferecido deve possuir campo para indicar para cada atendimento se o mesmo foi para: 1ª Consulta Odontológica Programática; Escovação Dental Supervisionada; Tratamento Concluído; Urgência; Atendimento a Gestantes;

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

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

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

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

A solução deverá dispor de relatórios com base no prontuário contendo minimamente: atendimentos por programa de saúde e atendimentos por CID10/CIAP2.

GESTÃO DE FILAS DE ESPERA

Compreende a gestão de listas de espera dos munícipes, dado que a oferta de serviços que tem maior demanda que oferta.

A plataforma deve possuir cadastro para os níveis de urgência a serem utilizados nas filas de espera contendo minimamente a descrição e a ordem.

Deve possuir cadastro de tipos de filas de espera (exames, consultas, transporte);

Deve possuir mecanismo ou funcionalidade que permitam que as filas sejam alimentadas nos locais de atendimento à população;

O sistema deve permitir que sejam criadas e gerenciadas filas de espera para cada tipo de especialidade disponível na rede de saúde;

A plataforma deve possuir mecanismo ou funcionalidade que permita a marcação das consultas da fila de espera em lote, permitindo que o operador selecione um ou mais cidadãos da fila e determine em que agenda de atendimento os mesmos devem ser inseridos;

O sistema deve permitir avisar/alertar o operador de possíveis problema na marcação de consultas em lote como em casos de falta de horários disponíveis;

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

Deve possuir mecanismo que permita ao gestor identificar quais filas estarão abertas/disponíveis para consultas públicas;

Deve possuir mecanismo que permita ao gestor configurar quais informações da fila devem estar visíveis nas consultas públicas contendo minimamente as informações: número do protocolo de atendimento; código do paciente; nome do paciente; nome social do paciente; nome da mãe; iniciais do nome do paciente; iniciais do nome social do paciente; iniciais do nome da mãe; data de nascimento; número do cartão nacional de saúde; número do CPF;

Deve possuir mecanismo que permita ao gestor configurar algumas filas de espera para passar por processo de regulação/autorização, enquanto outros tipos permitam apenas o fluxo simples;

Deve possuir mecanismo que permita ao gestor configurar para a fila de espera que possui processo de regulação, a obrigatoriedade da análise de um regulador, fazendo com que esse registro na fila fique em aguarde até finalização do processo do regulador para a mesma;

Nesta mesma funcionalidade supracitada, o sistema deve permitir ao regulador reclassificar a prioridade do atendimento na fila de espera, além de autorizar ou negar o atendimento, mediante justificativa;

O sistema deverá permitir anexar e visualizar os documentos/arquivos do cidadão ao inserir o mesmo em uma fila de espera ou pelo regulador durante a regulação, permanecendo possível a visualização destes documentos durante todo o fluxo do registro, até a consulta;

Deverá permitir o gestor verificar em forma de relatório o tempo médio de espera nas filas, com base em um período estipulado;

Deverá permitir o gestor verificar a ordem dos cidadãos em uma fila;

A plataforma deverá conter uma forma de agendamento automático pelo sistema, dos cidadãos que estão na fila de espera, conforme disponibilidade de vagas e ordem de posição do paciente na fila;

O sistema deve permitir o operador visualizar todas as filas que um cidadão se encontra, disponibilizando minimamente as informações do tipo da fila, especialidade, ordem, data de entrada na fila.

GESTÃO DE FROTAS E TFD

Deve conter ferramentas para controle de frotas e TFD (tratamento fora do domicílio).

O sistema deve possuir o cadastro de tipos de veículos;

O sistema deverá possuir campos para cadastro básico de veículo, contendo, minimamente descrição, tipo, placa, marca, número do chassi, renavam, ano do veículo sua capacidade/lotação, tipo do combustível e data da validade do extintor de incêndio;

Deve permitir a criação de rotas contendo minimamente sua descrição, município de saída e município de destino;

Deve possuir cadastro para lançamento de dotações orçamentárias contendo minimamente a descrição e o número;

Deve possuir cadastro de recursos contente minimamente a descrição e número;

O sistema deve permitir o cadastro de motoristas contendo minimamente o nome, CPF, telefone, endereço, município, complemento, CEP, tipo de veículo de condução, número da sua carteira de habilitação, categoria da carteira, data do vencimento da carteira;

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

Deve possuir cadastro de eventos do veículo;

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

O sistema deve gerar aviso/alerta para o operador quando o veículo for relacionado para algum tipo de viagem durante o período de vigência de um determinado evento a ele atrelado;

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

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

Deve possuir cadastro de destinos contendo minimamente nome, município onde se localiza e telefone;

Deve possuir registro de viagem, informando minimamente data e hora da saída, data e hora prevista para retorno, tipo da viagem, auxiliar, motorista, veículo, local de destino, cidade de destino, rota, dotação orçamentária e recurso;

Nesta mesma ferramenta supracitada, deve permitir que sejam atrelados a cada viagem os cidadãos e acompanhantes com seus devidos locais de saída hora da saída, locais de destino, telefone, documentos, tipo da viagem (ida, ida e volta), acompanhantes, data do aviso ao cidadão, horário do aviso e observação;

Deve permitir o gerenciamento das viagens permitindo o gestor visualizar a quantidade de vagas disponíveis por ida e quantidade de vagas disponíveis por volta;

Deve permitir no cadastro da viagem que sejam relacionados Km inicial, km final, nome da empresa (no caso de terceira) valores adiantados e km rodados;

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

A plataforma deve possuir funcionalidade ou mecanismo para lançamentos das despesas da viagem contendo minimamente a informações como data e hora de saída, data e hora da chegada, km inicial, km final, km rodado, número do documento da despesa, data da despesa, tipo da despesa, valor unitário, quantidade, total, local/fornecedor, um campo texto livre e campo indicativo permitindo informar se a viagem já foi finalizada;

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

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

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

Deve possuir mecanismo para lançamento de gastos gerais com veículo por tipo de gasto, incluindo a data da autorização, fornecedor, veículo, quilometragem, motorista, documento de referência, item, quantidade, valor e indicação se o mesmo foi autorizado ou cancelado;

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

O sistema deve permitir adicionar créditos ao fornecedor contendo minimamente a data, o fornecedor, qual o item ao qual o crédito é realizado, valor e quantidade;

O sistema deve possuir mecanismo para gerenciamento de solicitações de ambulância contendo minimamente a data da solicitação, data e hora da saída, cidade de destino, local de destino, veículo, motorista, pacientes na ida e pacientes no retorno e campo livre para anotações;

A solução deve possuir mecanismo que permita um controle em filas de espera para processos de TFD;

A solução deve possuir mecanismo que permita a publicação das filas de espera para transporte na internet para consultas públicas (sem necessidade de login) ao sistema;

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

O sistema deve permitir que sejam criados os processos de TFD contendo minimamente número do processamento, data da abertura, cidadão, profissional responsável, CID, tratamento solicitado, tipo do atendimento e um campo texto livre para justificativa;

Deve permitir para cada processo de TFD haver a indicação da situação do processo, se o mesmo foi autorizado, cancelado enviado para o estado, negado ou se está inconcluso e um campo livre texto para justificativa da situação e um campo livre texto observações gerais;

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

A solução deve permitir realizar o lançamento de todas as viagens necessárias para o processo TFD, contendo minimamente a data da solicitação, cidade e local de destino, transporte recomendado, veículo, motorista, data e hora da viagem, campo para observação da viagem, previsão de retorno e campo de observação para a previsão de retorno;

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

Deve disponibilizar informações referentes ao andamento dos processos de TFD nas recepções das unidades de saúde, contendo minimamente o cidadão, a situação e o número do processo;

Deve possuir mecanismo para geração automática dos procedimentos de transporte do cidadão e seu acompanhante, com base na quilometragem percorrida;

Deve possuir controle de manutenção e do abastecimento dos veículos.

GESTÃO DA REDE DE FRIO

Parte do SRES responsável por fazer a gerência dos imunobiológicos disponíveis na Secretaria de Saúde.

Deverá permitir o cadastramento das doses de vacinas a serem fornecidas;

Deverá possuir o cadastro de vacinas contendo minimamente a descrição e a ordem na carteira de vacinação do paciente;

Deverá permitir o cadastramento de grupos para imunização;

O sistema deverá permitir o cadastramento das faixas etárias utilizadas na imunização, de forma personalizável, contendo minimamente a descrição, idade inicial e idade final e sexo;

Deverá possuir funcionalidade para cadastramento de imunizações, contendo minimamente a vacina, a dose, as faixas etárias e o sexo;

Deverá permitir o cadastramento dos calendários de vacinação;

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

Deverá ser capaz de registrar todas as imunizações administradas ao cidadão, contendo minimamente as informações de data da aplicação, lote, validade, dose, tipo de imunobiológico e todas as demais requeridas pelo SI-PNI e e-SUS, ficando estas informações registradas no prontuário do cidadão;

Deverá permitir o cadastramento e gerenciamento das salas/módulos de vacinação disponíveis da rede municipal de saúde contendo minimamente descrição e a unidade de saúde onde está localizada;

Deverá possuir controle de estoque de imunizações minimamente por lote e validade, deverá possibilitar o gerenciamento e controle de estoque por cada sala/módulo;

Deverá possuir funcionalidade para cadastramento dos tipos de baixa a serem utilizados pela imunização;

Deverá ser capaz de gerar alerta internamente no sistema, todo cidadão que possui carteira de vacinação e o mesmo estiver com qualquer vacina em atraso deve gerar um aviso/alerta para o operador, em qualquer operação e módulo do sistema;

Deverá ser capaz de cadastrar as alergias do cidadão no cadastro da aplicação da vacina;

Deverá gerar aviso/alerta de todas as alergias cadastradas para o cidadão, para fins de visualização do operador, minimamente na carteira do cidadão e na aplicação de uma vacina;

Deverá controlar o calendário de vacinação incluindo intervalo mínimo e recomendado entre as doses do mesmo imunobiológico, bem como idade mínima e máxima do cidadão que pode receber a dose, sendo que a plataforma utilizará estes valores para realizar o aprazamento automaticamente das próximas doses no prontuário do cidadão;

Deverá permitir a atualização do registro de vacinação do cidadão por meio de inserção manual de registros realizados fora da rede municipal, com destaque de que se trata de atualização manual e não aplicação de imunobiológico;

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;

Deve permitir o lançamento de vacinas que não fazem parte do calendário de vacinação normal do cidadão;

Deve possuir mecanismo que permita o lançamento de imunizações através de planilhas de digitação contendo minimamente o nome do cidadão, a carteira de vacinação o profissional que realizou a imunização, a vacina, dose, lote/validade e quantidade, e deve permitir firmar a situação de gestante para cidadã;

Deve possuir mecanismo para registrar as entradas de imunizações, alimentando automaticamente o controle de estoque;

Deve permitir o gerenciamento de estoque pelo gestor, permitindo realizar acerto dos valores do estoque da imunização para o lote/validade já existentes, podendo diminuir a quantidade em estoque ou aumentar a quantidade em estoque;

Deve possuir mecanismo ou funcionalidade para controle de transferências de imunizações entre as salas/módulos de vacinação;

Deverá possuir mecanismo para gerenciamento das saídas de imunizações contendo minimamente as salas/módulos de vacinação, a data da saída, o motivo/tipo da baixa, as vacinas, lote/validade e quantidade;

Deve possuir mecanismo ou funcionalidade que permita o acompanhamento da movimentação do estoque de imunizações por salas/módulos de imunização, permitindo o gestor verificar a disponibilidade dos produtos por tipo de imunobiológico, permitindo monitorar o total de imunizações utilizadas e aplicadas, as perdas físicas e perdas técnicas;

Deve ter a possibilidade de fazer o envio das aplicações ao sistema oficial do governo SI-PNI e e-SUS, conforme o tipo de estabelecimento;

Deve permitir a impressão da caderneta de vacinação;

Deve possuir relatório de balanço físico de imunizações por sala/módulo de imunização;

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

Deve possuir relatório de acompanhamento de imunizações por bairro;

Deve possuir relatórios de gerenciamento com a visualização dos movimentos de estoque de mensal das imunizações;

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

Deve permitir o gestor verificar em forma de relatório a existência de imunizações atrasadas;

Deve permitir o gestor verificar as vacinações realizadas, e lista de vacinados por tipo de vacina;

Deve disponibilizar de mecanismo para importação de dados legados do sistema SIPNI, possibilitando a importação dos cidadãos e das vacinas aplicadas por cidadão;

Deve possuir integração com o RNDS para envio de vacinas do COVID, conforme layout e especificações técnicas do e-SUS.

GESTÃO DA VIGILÂNCIA EPIDEMIOLÓGICA

Deve dispor de mecanismos para identificação e gerenciamento das ocorrências relacionadas a vigilância epidemiológica.

A plataforma deverá possibilitar a customização de fichas de investigação da vigilância epidemiológica, contendo minimamente, descrição, CID’s 10 compatíveis;

Deve possuir mecanismo ou funcionalidade que permita a criação das perguntas que compõe cada ficha de investigação contendo minimamente: ordem de visualização das perguntas, campo para observação da resposta firmada e campo para inserção de ajuda para cada pergunta. O tipo da resposta a ser aceito para cada pergunta deve poder 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, sendo possível definir na pergunta se permite a seleção de um ou mais itens de resposta

Deve possuir ferramenta para gerenciamento e monitoramento dos agravos de notificação, contendo minimamente o agravo, tipo da notificação (negativa, individual, surto ou Inquérito Tracoma) a data dos primeiros sintomas, a data da notificação, situação da notificação (registrado, avaliando, investigando, providenciado, cancelado e rejeitado), município, unidade de saúde notificadora, responsável pela notificação, e os dados do cidadão;

Nesta mesma ferramenta supracitada deverá haver minimamente os dados do cidadão: Nome, data de nascimento, número do cartão SUS, idade (em Anos, Meses, Xxxx e Horas), sexo, raça/cor, nome da mãe e escolaridade e deverá permitir o detalhamento da residência do notificado contendo minimamente: bairro, CEP, latitude, longitude, logradouro, número, complemento, pontos de referência, DDD, telefone e zona (rural ou urbana);

Deve permitir o cadastro inicial do surto, com data do primeiro caso suspeito, número de casos suspeitos, local inicial da ocorrência (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;

Deve possuir funcionalidade ou mecanismo para gerenciamento 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 e SMS 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;

Deve apresentar um sistema de alerta ao usuário para a notificação compulsória sempre que houver a digitação do CID ou CIAP, nos campos específicos, correspondente a agravos de notificação.

DISPOSITIVOS MÓVEIS

Prevê o uso de dispositivos móveis, do tipo tablet, para coleta de dados de agentes comunitário de saúde, no exercício diário de suas atividades.

O aplicativo deve funcionar nos dispositivos móveis minimamente sob a plataforma ANDROID;

Deve trabalhar off-line, não necessitando de internet ou outro tipo de rede para funcionamento, exceto para enviar e receber informações com o servidor;

Deve solicitar usuário e senha para conectar-se ao servidor e para o acesso ao aplicativo;

Deve gerenciar a micro área de cada agente de saúde;

Deve receber do servidor todas os dados cadastrais dos domicílios, famílias e seus integrantes, do servidor referentes à micro área do agente de saúde que opera o dispositivo móvel;

Deve alertar quando existem dados para serem sincronizados;

Deve possibilitar o envio dos registros novos ou atualizados para o servidor, receber e fazer atualização de dados mais atuais daqueles que o aplicativo está gerenciando;

Deve ser compatível com as fichas e regras cds do e-sus, contendo minimamente as fichas de cadastro individual, ficha de cadastro individual, ficha de cadastro domiciliar, ficha de marcadores de consumo alimentar;

Deve estar disponível na loja virtual Google Play com download gratuito para instalação e atualização;

Deve relacionar todas os domicílios que a micro área possui cadastrados;

Deve possuir diversas formas de pesquisa de domicílios, tais como por logradouro, bairro ou mesmo pelo nome de qualquer dos integrantes, bem como CNS-Cartão SUS, entre outros;

Deve possibilitar inclusão ou atualização de dados cadastrais de cada domicílio no formato exigido pelo e-SUS;

Deve possibilitar inclusão ou atualização de dados cadastrais das famílias para cada domicílio;

Deve possibilitar inclusão ou atualização de dados cadastrais de cada integrante do domicílio e informar a qual família ele pertence;

Deve possibilitar identificar o chefe da família;

Deve possibilitar ao agente de saúde, gerenciar suas visitas domiciliares, no formato e-SUS;

Deve solicitar os dados da visita domiciliar seguindo o modelo especificado pelo e-SUS;

Deve possibilitar ao agente de saúde, identificar os domicílios que ainda não foram visitados nos últimos 7, 15, 30, 60 e mais dias e também exibir a data da última visita efetuada em cada um;

Deve realizar as validações necessárias com base nas regras de validação por ficha do e-SUS;

Deve possuir tabela cadastral de todos os países e municípios do Brasil, e para essas tabelas uma forma de pesquisa que faça o trabalho de auto completar, facilitando a seleção do registro desejado;

Deve capturar o posicionamento das coordenadas GPS durante todo o trabalho da ACS bem como em qualquer ação que venha a realizar utilizando o sistema;

Deve gerar LOG em todas as atividades que a ACS venha a realizar utilizando o aplicativo;

Deve fornecer um cadastro e gerenciamento de ocorrências adversas enfrentadas pela ACS, tanto na Visita Xxxxxxxxxx como em qualquer momento que isso venha a ocorrer, acrescentando ainda a inclusão de imagens (fotos) acompanhadas de um descritivo informando o que é observado na imagem coletada;

Deve permitir a transferência cadastral de Integrantes entre micro áreas, através de solicitação no próprio aplicativo, evitando re-cadastro de integrantes;

Deve permitir a ação de coleta de imagem (foto) do Integrante no momento da realização da Visita Domiciliar, bem como coletar sua assinatura e possibilitar também à ACS registrar sua assinatura. Nas assinaturas, o sistema deve gravar o posicionamento GPS visível na imagem;

Deve possibilitar a coleta de imagem (foto) de cada integrante no cadastro individual;

Deve permitir que a ACS capture sua própria imagem através de foto capturada pelo próprio dispositivo, armazenando essa imagem no servidor;

Deve permitir o preenchimento de formulário para marcadores de consumo alimentar, realizando as validações do e-SUS, impedindo erros de digitação;

Deve permitir a realização de visitas domiciliares e coleta de marcadores de consumo alimentar, também em integrantes que não estejam cadastrados no micro área da ACS;

Deve possibilitar a edição de um local para informações extras nos domicílios no caso de visitas domiciliares, essas anotações são de caráter individual de cada ACS;

Deve disponibilizar no próprio aplicativo, acesso a vídeo aulas online sobre a operacionalização do aplicativo.

Ibiam, 03 setembro de 2.021.

Xxxxx Xxxxx Xxxxx xx Xxxxxxxx

Gestora Municipal de Saúde