TERMO DE REFERÊNCIA

Prestação de Serviço de locação do Software Regulação

1. OBJETO

Contratação de serviço de locação de solução integrada para o Serviço de Atendimento Móvel de Urgência (SAMU) incluindo a locação de software para atender aos usuários simultâneos e unidades especificadas, serviços técnicos especializados (STE) de implantação, suporte técnico, manutenção das licenças, hospedagem da solução, integração com a solução de comunicação híbrida {satélite e celular/tablet (Multioperadora)}.

Por solução integrada entende-se aquela que possua módulos nativos e com interação de dados internamente (transparente ao usuário) de forma a atender aos processos do SAMU, mantendo uma camada única de persistência, a identificação unívoca do usuário do SUS, dos profissionais, dos estabelecimentos de saúde e a agregação de dados clínicos e administrativos.

O objeto contempla:

I.Serviço de locação de solução integrada de SAMU para atender aos usuários simultâneos e unidades especificadas no Quadro 3 - Projeto Básico: Volumetria do Projeto, incluindo:

a) Fornecimento de licenças de uso do software

b) Suporte técnico ao usuário

c) Hospedagem da solução

d) Integração com o serviço de comunicação híbrida {satélite e celular/tablet (Multi-operadora)}

II.Serviços Técnicos Especializados de implantação para cobrir o escopo descrito no Quadro 3 - Projeto Básico: Escopo e Volumetria do Projeto incluindo:

a) Mapeamento e desenho (as is) dos processos, subprocessos e atividades existentes, analisar e indicar melhorias. Elaborar Plano de Implantação dos Processos (to be) estabelecendo relação entre processos/subprocessos e atividades com módulos/componentes/funcionalidades, comandos e parâmetros (orientações para a implantação) da solução.

b) Parametrizações, customizações e integrações necessárias à efetiva entrada em produção de todos os requisitos funcionais e não funcionais.

c) Importação de Dados: serviço de carga de dados para as tabelas auxiliares e básicas necessárias ao funcionamento pleno da solução.

d) Disponibilização dos ambientes de homologação e de treinamento. Estes ambientes devem ser suficientes para aprovação das funcionalidades pelos usuários.

e) Implantação nas unidades de saúde especificadas no Quadro 3 - Projeto Básico: Volumetria do Projeto.

● Treinamento dos usuários da central de regulação do SAMU, equipes móveis, administradores, parametrizadores, gestores do CIAS, das SMSA`s e coordenadores dos serviços de pronto atendimento dos hospitais de referência, conforme especificado no Quadro 3 - Projeto Básico: Escopo e Volumetria do Projeto, no item Nº de usuários para fins de treinamento.

● Operação assistida na central do SAMU e nos serviços de pronto atendimento dos hospitais de referência, conforme especificado no Quadro 3 - Projeto Básico: Escopo e Volumetria do Projeto.

III. Serviço de sustentação da solução em produção composto de:

a) Serviço de manutenção de software e suporte técnico ao usuário;

b) Serviço de Hospedagem

c) Serviço de manutenção da integração com a comunicação híbrida, Celular e Satélite.

IV. Pontos de Função: serviços para desenvolvimento e evolução da solução para atender a necessidades futuras, distintas daquelas previstas neste Edital, executados por meio de Pontos de Função a serem mensurados pela CONTRATADA e validados e autorizados pela CONTRATANTE mediante Ordem de Serviço, até o limite de 500 (quinhentos) Pontos de Função.

V.Incremento de veículos do SAMU do município de Belo Horizonte: serviços para garantir o uso da solução, caso haja aumento no nº de veículos do SAMU, incluindo licenças, treinamento, parametrizações, configurações, bem como a sustentação, suporte aos usuários, executados por meio da unidade de custos veículo mês (total de veículos incrementados multiplicado pelo total de meses de utilização), até o limite de 420 unidades de custo veículos mês, autorizados mediante Ordem de Serviço. Por exemplo, o incremento de 5 veículos em 10 meses equivaleria ao consumo de 50 unidades de custo veículo mês.

VI.Incremento de veículos dos municípios do interior regulados pela Central em Belo Horizonte: serviços para garantir o uso da solução, caso haja aumento do nº de veículos do interior, incluindo licenças, treinamento, parametrizações, configurações, bem como a sustentação, suporte aos usuários, executados por meio da unidade de custos veículo mês (total de veículos incrementados multiplicado pelo total de meses de utilização), até o limite de 966 unidades de custo veículos mês, autorizados mediante Ordem de Serviço. Por exemplo, o incremento de 5 veículos em 10 meses equivaleria ao consumo de 50 unidades de custo veículo mês). A solução deverá se dar no município de origem dos veículos. O quantitativo foi levantado pela Central de Regulação, com base no histórico dos registros da Secretaria Municipal de Saúde.

A Solução ofertada neste certame deverá atender na plenitude, em tempo de projeto, a todos os requisitos funcionais e não funcionais previstos neste Projeto Básico e seus Anexos, devendo atender de forma nativa ou parametrizável o percentual mínimo ( oitenta e cinco por cento) de requisitos estabelecido no Item Qualificação Técnica. A descrição detalhada dos requisitos, especificações técnicas e de arquitetura da solução objetivada neste Termo de Referência são descritas no Projeto Básico e seus anexos.

2. MODALIDADE:

Modalidade de licitação: pregão eletrônico.

3. TIPO:

3.1. Menor preço global ofertado

3.2. Regime de execução: empreitada por preço global

4. DOTAÇÃO (ÇÕES) ORÇAMENTÁRIA(S)

Os serviços contratados serão custeados por recursos orçamentários provenientes da dotação orçamentária aprovada, destinada para a Manutenção do SAMU Macro Centro, a qual será informada em documento posterior.

5. PARTICIPANTES

Poderão participar da Licitação os interessados pessoas jurídicas, que atenderem a todas às exigências deste Termo de Referência e seus Anexos.

As empresas estrangeiras com subsidiária, filial, agência, escritório, estabelecimento ou agente no Brasil deverão apresentar autorização, mediante decreto ou ato expedido pelo Ministro de Estado do Desenvolvimento, Indústria e Comércio Exterior para funcionar no Brasil, ato de registro ou autorização para funcionamento expedido pelo órgão competente, se a atividade assim o exigir,e os documentos exigidos neste Edital (Lei nº 10.406/2002 – Código Civil, arts. 1.134 a 1.141 e Decreto- Lei nº 2.627/1940, arts. 59 a 73).

5.1. Será admitida a participação de empresas em regime de consórcio, desde que atendidas as exigências contidas nos itens que se seguem:

a) O consórcio deverá ser formado, no máximo, por até três empresas.

b) O licitante vencedor fica obrigado a promover, antes da celebração do contrato, a constituição e o registro do consórcio, nos termos do compromisso referido na Declaração de Compromisso (ANEXO IX).

5.2. Estarão impedidos de participar de qualquer fase do procedimento os interessados que se enquadrem em quaisquer das situações a seguir:

c) estejam cumprindo a penalidade de suspensão temporária imposta pelo CIAS, ou pelo município de Belo Horizonte;

d) tenham sido declarados inidôneos ou suspensos de participarem de licitações realizadaspela Administração Pública, nos âmbitos Federal, Estadual e Municipal;

e) estejam sob falência, recuperação judicial ou extrajudicial, dissolução ou liquidação;

Admite-se a participação, em licitações, de empresas em recuperação judicial, desde que amparadas em certidão emitida pela instância judicial competente afirmando que a interessada está apta econômica e financeiramente a participar de procedimento licitatório

f) cujo(s) proprietário(s) ou sócio(s) seja(m) servidor(es) público(s) do CIAS, ou de qualquer um dos 23 municípios que compoem a macrorregião de saúde, conforme quadro 2 – Projeto Básico, , de acordo com a vedação no artigo 9º, inciso III, da Lei Federal nº 8.666/93 e artigo 39;

g) Micro empresas e Empresas de Pequeno Porte com fulcro no art. 3º da Lei Complementar Federal nº 123/2006, tendo em vista o valor estimado para a contratação do serviço.

h) Pessoa física, tendo em vista a qualificação técnica e econômica indispensáveis à garantia do cumprimento das obrigações.

i) Cooperativas, devido a natureza do serviço e pelo modo como é usualmente executado no mercado. Podendo haver existência de vínculos de emprego/subordinação dos profissionais com a pessoa jurídica contratada (cooperativa), bem como dispensam os elementos da habitualidade e pessoalidade.

j) Demais hipóteses proibidas pela legislação vigente.

6. CONDIÇÕES DE HABILITAÇÃO

6.1. Habilitação Jurídica conforme artigo 28 da lei 8.666/1993.

6.1.1. Cédula de Identidade, CNH ou outro documento equivalente do Sócio Administrador

6.1.2. Registro comercial, no caso de empresa individual;

6.1.3. Ato constitutivo, estatuto ou contrato social em vigor devidamente registrado, em se tratando de sociedades comerciais e, no caso de sociedades por ações, acompanhado de documentos de eleição de seus administradores;

6.1.3.1. O ato constitutivo, estatuto ou contrato social em vigor, deverá prever objeto social compatível ao(s) objeto(s) licitado(s).

6.1.3.2. Para todos os efeitos, considera-se como ato constitutivo, estatuto ou contrato social em vigor, o documento de constituição da empresa, acompanhado da(s) última(s) alteração(ões) referente(s) à natureza da atividade comercial e à administração da empresa, ou a última alteração consolidada.

6.1.4. Inscrição do ato constitutivo, no caso de sociedades civis, acompanhada de prova de diretoria em exercício;

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

6.1.6. Tratando-se de licitantes reunidos em consórcio, serão observadas as seguintes exigências:

6.1.6.1.Comprovar a existência de compromisso público ou particular de constituição de consórcio, subscrito pelas empresas que dele participarão, com indicação da empresa-líder, que deverá possuir amplos poderes para representar os consorciados no procedimento licitatório e no instrumento contratual, receber e dar quitação,

responder administrativa e judicialmente, inclusive receber notificação, intimação e citação.

6.1.6.1.1. Obrigatoriamente, a liderança deverá se dar por empresa brasileira no consórcio formado por empresas brasileiras e estrangeiras.

6.1.6.2.apresentar, antes da assinatura do contrato decorrente desta licitação, o Instrumento de Constituição e o registro do Consórcio, contemplando o seguinte conteúdo:

6.1.6.2.1. empresas participantes e a proporção de participação de cada consorciado;

6.1.6.2.2. compromisso de não alteração da constituição ou composição do consórcio, salvo aprovação da CONTRATANTE, visando manter válidas as premissas que asseguram a sua habilitação;

6.1.6.2.3. indicação da empresa responsável - líder - pelo consórcio que deverá atender às condições de liderança fixadas neste instrumento;

6.1.6.2.4. responsabilidade solidária dos integrantes pelos atos praticados em consórcio, tanto na fase de licitação quanto na de execução do Termo decorrente da licitação;

6.1.6.2.5. vigência do consórcio compatível com o prazo previsto para o contrato, inclusive com a possibilidade de prorrogação.

6.1.7. Empresas estrangeiras

6.1.7.1. Decreto de autorização, em se tratando de empresa ou sociedade estrangeira em funcionamentono País, e ato de registro ou autorização para funcionamento expedido pelo órgão competente, quando a atividade assim o exigir.

6.2. Regularidade Fiscal e Trabalhista conforme art. 29 da Lei 8.666/93

6.2.1.1.Prova de inscrição no Cadastro Nacional de Pessoa Jurídica (CNPJ);

6.2.1.2.Prova de inscrição no Cadastro de Contribuintes Estadual ou Municipal, se houver, relativo ao domicílio ou sede do licitante, pertinente ao seu ramo de atividade e compatível com o objeto contratual;

6.2.1.3.Prova de regularidade para com as Fazendas Federal, Estadual/Distrital e Municipal do domicílio ou sede do interessado, ou outra equivalente, na forma da lei;

0.0.0.0.Xx caso da comprovação de regularidade com a respectiva fazenda pública exigir a emissão de mais de uma certidão (ex. certidão mobiliário e imobiliária, etc.) o licitante deverá

apresentar quantas forem necessárias para a completa demonstração de regularidade.

6.2.1.5.Caso o licitante seja considerado isento dos tributos estaduais e/ou municipais relacionados ao objeto licitatório, deverá comprovar tal condição mediante declaração da Fazenda Pública Estadual e/ou Municipal do seu domicílio ou sede, ou outra equivalente, na forma da lei;

6.2.1.6.Prova de regularidade relativa à Seguridade Social e ao Fundo de Garantia por Tempo de Serviço (FGTS), demonstrando situação regular no cumprimento dos encargos sociais instituídos por lei.

6.2.1.7.Prova de inexistência de débitos inadimplidos perante a Justiça do Trabalho, mediante apresentação de certidão, nos termos do Título VII-A da Consolidação das Leis do Trabalho, aprovada pelo Decreto- Lei no 5.452, de 1o de maio de 1943.

6.3. Qualificação Técnica

6.3.1. Atestado(s) de Capacidade Técnica, emitido (s) por pessoa jurídica de direito público ou privado, comprovando a experiência da PROPONENTE com a prestação de serviços de locação de solução integrada de SAMU ou fornecimento de sistema (licença) em quantidades e características compatíveis com a realidade do SAMU da Macrorregião de Belo Horizonte (micro Belo Horizonte, micro Ouro Preto e micro Vespasiano), contemplando obrigatoriamente: gerenciamento das solicitações, regulação, atendimento móvel e transporte, e controle e monitoramento de veículos.

6.3.1.1.Para fins desta licitação, entende-se por experiência em prestação de serviço de locação de solução integrada ou fornecimento de sistema (licença) em situação semelhante a realidade da Xxxxxxxxxxxx em questão, aquela que contempla pelo menos duas das três características descritas a seguir, sendo obrigatória a comprovação da característica III:

1) Experiência de implantação em única rede assistencial organizada e gerida por um órgão, empresa ou consórcio intermunicipal, circunscrita em território federativo (município, conjunto d e municípios, estado ou país), com estabelecimentos de saúde, geograficamente distribuídos.

2) Experiência em serviços de atendimento móvel, cujo número de veículos esteja em quantidade que represente no mínimo 50% (27 veículos) do número de veículos previsto para o SAMU da Macrorregião de Belo Horizonte (micro Belo Horizonte, micro Ouro Preto e micro Vespasiano), (54 Veículos), conforme Quadro 3 - Escopo do Projeto, item Nº de veículos, esse quantitativo de veículos gerenciados por uma única Central ou Rede Assistencial.

3) Experiência em complexo regulador, com número de atendimentos anuais que represente no mínimo 50% (53.400 atendimentos) do SAMU do Macrorregional de Belo Horizonte, conforme Quadro 3- Escopo do Projeto, item Nº médio de solicitações atendidas por mês.

6.3.2. Será permitido o somatório para a comprovação da volumetria indicada nas características II, III do item anterior, tanto para as PROPONENTES isoladas ou consorciadas, sendo obrigatório pelo menos 1 (um) atestado com quantidade mínima de 33,33% do exigido (ou seja, mínimo de 18 veículos e 35.600 atendimentos/ano).

6.3.3. O atestado ou atestados deverão ser emitidos por pessoa jurídica de direito público ou privado em língua portuguesa. As empresas estrangeiras deverão traduzir para a língua portuguesa (por tradutor juramentado) os seus atestados internacionais.

Descrição sugerida para o atestado ou atestados:

a) O nome da entidade que está emitindo o atestado, na qualidade decliente/CONTRATANTE.

b) E-mail e telefone de contato para eventuais diligências.

c) O nome da solução tecnológica (software) implantada.

d) Descrição sumarizada do escopo da solução tecnológica integrada.

e) Avaliação da qualidade dos serviços prestados.

f) Prazo de execução dos serviços prestados.

g) Data de emissão do atestado.

h) Nome do responsável pela assinatura do atestado.

6.3.4. O atestado ou atestados deverão ser emitidos em papel timbrado do Órgão ou Empresa que o expediram ou deverão conter carimbo do CNPJ.

6.3.5. A CONTRATANTE poderá realizar diligências junto aos emissores dos atestados, por meio detelefone ou e-mail, para esclarecer eventuais dúvidas sobre a comprovação de experiência da LICITANTE na prestação de serviços. Serão considerados os esclarecimentos enviados em até10 dias corridos a contar a partir do envio do e-mail ou contato telefônico.

6.3.6. No caso de participação como PROPONENTES consorciadas, as empresas devem atestar a propriedade ou a permissão de comercialização da solução ofertada no certame por meio da Declaração de Propriedade e Permissão de Comercialização (ANEXO VIII).

6.4. Qualificação Econômico-financeira conforme art. 31 da Lei 8.666/93.

6.4.1. Balanço Patrimonial e Demonstração Contábil do Resultado do Último Exercício Social já exigíveis e apresentados na forma da lei, que demonstrem a situação financeira do licitante, vedada a sua substituição por balancetes ou balanços provisórios.

6.4.1.1. Serão considerados, “na forma da lei”, o Balanço Patrimonial e a Demonstração Contábil do Resultado do Último Exercício Social, assim apresentados:

a) publicados em Diário Oficial; ou

b) publicados em Jornal; ou

c) por fotocópia do livro Diário, devidamente registrado/autenticado na Junta Comercial da sede ou domicílio do licitante ou registrado no órgão de registro equivalente, inclusive com os Termos de Abertura e de Encerramento; ou

d) na forma de escrituração contábil digital (ECD) instituída pela Instrução Normativa daRFB nº 1.420 de 19/12/2013 e suas alterações.

6.4.1.2. As empresas com menos de um ano de existência, desde que não enquadradas no art. 1.065 do Código Civil, devem apresentar Balanço de Abertura devidamente registrado/autenticado na Junta Comercial da sede ou domicílio do licitante ou registrado no órgão de registro equivalente.

6.4.1.3. O Balanço Patrimonial (inclusive o Balanço de Abertura) e a Demonstração Contábil do Resultado do Último Exercício Social deverão estar assinadas por Xxxxxxxx ou por outro profissional equivalente, devidamente registrados no Conselho Regional de Contabilidade.

6.4.2. Cálculo dos índices de Liquidez Geral (LG) e Liquidez Corrente (LC), resultantes da aplicação das fórmulas abaixo, sendo considerado habilitado o licitante que apresentar resultado igual ou maior que 1 (um), em todos os índices aqui mencionados:

LG = Ativo Circulante + Realizável a Longo PrazoPassivo Circulante + Passivo não Circulante

LC = Ativo Circulante Passivo Circulante

6.4.2.1. O licitante que apresentar resultado menor que 1 (um) em qualquer dos índices referidos no subitem acima deverá comprovar patrimônio líquido ou capital social mínimo de 10% (dez porcento) do valor da proposta.

6.4.3. Certidão negativa de falência ou recuperação judicial, expedida pelo distribuidor da sede da pessoa jurídica, ou de execução patrimonial, expedida no domicílio da pessoa física, quando for o caso.

6.4.4. Não utilizar em seu quadro de funcionários menores de 18 (dezoito) anos em trabalho noturno, perigoso ou insalubre, nem menores de 16 (dezesseis) anos em qualquer trabalho, salvo na condição de aprendiz, a partir de 14 (quatorze) anos, nos termos do art. 7º, XXXIII, da Constituição Federal.

6.4.5. Apresentação dos documentos exigidos neste item do Termo de Referência, por parte de cada consorciado, admitindo-se, para efeito de qualificação econômico-financeira, o somatório dos valores de cada consorciado, na proporção de sua respectiva participação

7. CRITÉRIOS DE AVALIAÇÃO E ACEITABILIDADE DA PROPOSTA

7.1. Critério de julgamento: 1° menor preço, conforme valor do lance de arrematação; 2° Habilitação: verificação de documentação de Habilitação Jurídica, Qualificação e Proposta Técnica da Solução Tecnológica ofertada; 3° Testes de Conformidade: verificação da conformidade dos requisitos da Solução ofertada neste certame, conforme o item deste Termo de Referência.

7.2. A proposta de preços deverá conter:

7.2.1. Razão Social, n.º do CNPJ, endereço, telefone e endereço eletrônico do licitante.

7.2.2. Modalidade e número da licitação.

7.2.3. Descrição da solução tecnológica ofertada indicando nome comercial, relação de todos os módulos e versões.

7.2.4. Valor do lance vencedor do lote, discriminando os valores unitários conforme modelo do Anexo XI.

7.2.5. Declaração de validade da proposta de 90 (noventa) dias, contados da assinatura.

7.3. Juntamente com a proposta de preços a empresa arrematante deverá apresentar:

7.3.1. Formulário de Resumo Financeiro da Proposta Comercial, conforme ANEXO XI.

7.3.1.1. Considerar-se-ão incluídos nos preços propostos pelos licitantes todos os tributos, encargos sociais e trabalhistas, seguros, despesas com mão-de-obra, deslocamento, alimentação e hospedagem de pessoal, fornecimentos de materiais, softwares e licenças de uso, treinamentos,transferência de tecnologia, serviços de suporte técnico de manutenção necessária para consolidação da Solução SAMU, elaboração de projetos, lucro e quaisquer outros ônus que porventura possam recair sobre o fornecimento de bens e a prestação dos serviços objetos da presente licitação, os quais ficarão a cargo única e exclusivamente do PROPONENTE.

7.3.1.2. Quaisquer tributos e taxas, despesas e custos diretos ou indiretos incorretamente cotados ou, porventura, omitidos na proposta comercial serão considerados como inclusos nos preços propostos pelo licitante, não sendo considerados pleitos de acréscimos a qualquer título, devendo o fornecimento de produtos e os serviços objetos desta licitação ser prestados ao CONTRATANTE sem quaisquer outros ônus adicionais.

7.3.2. Declaração de Compromisso de que a tecnologia utilizada na solução proposta tem condição de atender todos osrequisitos funcionais e não funcionais em tempo de projeto (ANEXO IX).

7.3.3. Declaração de Propriedade Intelectual e Autoral e ou Permissão de Comercialização (Anexo VIII) Solução Tecnológica ofertada para atender ao objeto deste TR.

7.3.4. Formulários de requisitos funcionais preenchidos – ANEXOS I – do Projeto Básico.

7.3.4.1. Para Atendimento aos Requisitos - preenchimento dos Formulários de Requisitos Funcionais, com a coluna de “Forma de Atendimento” preenchida.

7.3.4.2. Para fins de avaliação da solução as planilhas devem ser preenchidas detalhando a forma de atendimento de cada requisito que deverá ser preenchido com um “X” nas seguintes opções:

a) Nativa

b) Parametrizável

c) Customizável

7.3.4.3. Cada requisito definido na Especificação de Requisitos – ANEXOS I – do Projeto Básico, deve ser necessariamente atendido em Tempo de Projeto.

7.3.4.4. Entende-se por:

d) Xxxxxx: a solução proposta pela PROPONENTE que já esteja contemplada no sistema de forma direta não necessitando de nenhum tipo de intervenção técnica para que o processamento seja executado e o resultado obtido.

e) Parametrizável: a solução proposta pela PROPONENTE na qual o resultado desejado pode ser obtido através de parâmetros contidos em tabelas específicas, em faixas de valores pré-cadastradas ou opções documentadas no dicionário de dados. Não serão aceitas propostas onde o resultado da parametrização for obtido através de codificação encadeada.

f) Customizável: é a solução proposta pela PROPONENTE para os itens que não fazem parte do kernel ou núcleo da aplicação e que dependa de estudo e caso de uso para desenvolvimento codificado, integrando a solução na mesma plataforma e linguagem.

7.3.5. Serão desclassificadas tecnicamente as propostas que não atenderem aos requisitos funcionais, de forma Nativa e/ou parametrizada, no mínimo de 85% (oitenta e cinco por cento) dos requisitos funcionais do módulo SAMU – ANEXO I do Projeto Básico. Excetuando-se os Requisitos classificados como: “Integração” e como “Interface da unidades hospitalares – Grade de Leitos”, que estão representados nos Requisitos de numeração 86 à 108.

7.3.5.1 Os Requisitos preenchidos pelo PROPONENTE, no Formulários de Requisitos Funcionais, como “Nativos e Parametrizáveis”, deverão ser demonstrados no Teste de Conformidade, sob pena de desclassificação.

7.3.6. Declaração (ANEXO IX) de que a solução atende 100% dos requisitos não funcionais em tempo de projeto, identificando os requisitos nativos, parametrizáveis e customizáveis.

8. VERIFICAÇÃO DE CONFORMIDADE DOS REQUISITOS DA SOLUÇÃO OFERTADA

8.1. A PROPONENTE, provisoriamente classificada em primeiro lugar, por ofertar o menor valor/preço e ser habilitada conforme exigências do Edital, será devidamente convocada pelo pregoeiro, para comprovar que atende os requisitos (Anexos I e II do Projeto Básico) por meio dos testes exigidos neste item.

8.1.1. A PROPONENTE nesta condição será identificada como PROPONENTE em Avaliação.

8.2. A data e horário dos testes serão previamente agendados pela PROPONENTE em Avaliação através de contato com a CONTRATANTE, divulgados na plataforma de realização do certame no site do Consórcio Aliança para a Saúde – CIAS, e deverão ser iniciados em até 8 (oito) dias úteis a partir da convocação do pregoeiro.

8.2.1. Esse prazo visa que a PROPONENTE em Avaliação prepare um piloto/amostra do produto, contendo todas as informações e condições necessárias, para demonstrar atividades dosmacroprocessos, os requisitos funcionais deixando-o em plena condição operacional de avaliação.

8.3. Se houver condição sanitária em razão da pandemia de Covid, os testes de conformidade serão realizados nas dependências físicas do CIAS, ou em Órgão/Entidade integrante da Administração Direta ou Indireta do Município de Belo Horizonte, com duração prevista, inicialmente, de 5 (cinco) dias úteis, podendo ser prorrogável a critério da CONTRATANTE.

8.3.1. Se não houver condição sanitária em razão da pandemia de Xxxxx, os testes de conformidade serão realizados por meio de videoconferência, podendo ser prorrogável a critério da CONTRATANTE.

8.4. Para a verificação da conformidade da Solução ofertada neste certame serão realizados dois Testes de Conformidade (TDC). O primeiro é a verificação de funcionalidades por meio de Execução de Macroprocessos (TDC - PROC) e, o segundo, o Teste de Conformidade de Requisitos Funcionais (TDC - RFU), ambos realizados sob a coordenação da CONTRATANTE e abertas à participação de interessados.

8.4.1. Em Relação ao Teste de Conformidade de Requisitos Funcionais (TDC - RFU), citado acima, não serão exigidos nesta etapa, os Requisitos classificados como: “Integração” e como “Interface da unidades hospitalares – Grade de Leitos”, que estão representados nos Requisitos de numeração 86 à 108.

8.4.2. Os testes mencionados visam averiguar de forma prática em ambiente simulado, que a solução ofertada neste certame atende às especificações dos requisitos funcionais estabelecidos neste Termo de Referência.

8.5. A avaliação será realizada por uma Equipe Técnica de Avaliação formalmente designada pelo titular da CONTRATANTE.

8.5.1. A Equipe Técnica de Avalização, será composta por 05 membros, sendo 03 indicados pelo CIAS e 02 menbros indicados pela Prefeitura de Belo Horizonte.

a) coordenar a execução de todas as atividades relativas aos Testes de Conformidade;

b) fazer questionamentos e ou realizar diligências a fim de esclarecer dúvidas quanto ao piloto/amostra apresentada;

c) declarar a conclusão das atividades de Avaliação Técnica;

d) emitir, ao pregoeiro e ao Diretor da Área Técnica, o Relatório de Julgamento dos dois Testes deConformidade, devidamente justificado, para apreciação e validação.

8.5.2. Cabe à Equipe Técnica de Avaliação:

a) coordenar a execução de todas as atividades relativas aos Testes de Conformidade;

b) fazer questionamentos e ou realizar diligências a fim de esclarecer dúvidas quanto ao piloto/amostra apresentada;

c) declarar a conclusão das atividades de Avaliação Técnica;

d) emitir, ao pregoeiro e ao Diretor da Área Técnica, , o Relatório de Julgamento dos dois Testes deConformidade, devidamente justificado, para apreciação e validação.

8.6. O Pregoeiro emitirá sua decisão em até 3 (três) dias após a conclusão do Teste de Conformidade, e, independente de impgunação, o mérito dessa decisão deverá ser reexaminado pelo Secretário Executivo, consubstanciado em Parecer da Área Técnica, para que se produza efeitos.

8.7. Qualquer interessado poderá acompanhar a realização dos testes, sendo que durante a sessão somente poderão se manifestar integrantes da Equipe Técnica de Avaliação e da PROPONENTE em Avaliação. Os demais interessados poderão se manifestar por escrito durante a fase de recursos.

8.7.1. O credenciamento dos integrantes da equipe da PROPONENTE em avaliação e demais interessados que acompanharão os testes, será realizado pela equipe da CONTRATANTE até 10 minutos antes dos inícios dos trabalhos, no local de avaliação ou por meio do e-mail: xxxxxxxxx@xxxx.xx.xxx.xx.

8.8. A PROPONENTE em Avaliação deverá apresentar profissionais especialistas no produto para executar a avaliação do piloto/amostra, bem como exaurir eventuais questionamentos da Equipe Técnica de Avaliação.

8.9. Todas as dúvidas e esclarecimentos demandados pela Equipe Técnica devem ser dirimidos durante a sessão de avaliação da conformidade da Solução. Não serão consideradas quaisquer informações fornecidas após a conclusão da sessão.

8.10. Toda a infraestrutura de hardware, software, rede e equipamentos para a realização dos testes de conformidade é de responsabilidade da PROPONENTE em Avaliação, assim como as massas de dados necessárias para a demonstração. A demonstração poderá ocorrer acessando o sistema em nuvem ou através de acesso a servidores locais trazidos pela PROPONENTE em Avaliação.

8.11. A PROPONENTE em Avaliação deverá garantir a captura em filmes de todas as demonstrações realizadas durante o TDC.

8.11.1. Os arquivos gerados da captura das telas serão entregues à Equipe Técnica de Avaliação ao finalde cada dia.

8.11.2. A mídia a ser utilizada na gravação dos arquivos supracitados deve ser fornecida pela Proponente em Avaliação e será devolvida posteriormente, pela CONTRATANTE, caso seja retornável.

8.12. Teste 1 – TDC-PROC - Verificação de Processos

8.12.1. O primeiro teste a ser realizado será a verificação de funcionalidades por meio da execução de macroprocessos (TDC-PROC).

8.12.2. No teste TDC-PROC - Verificação de Processos, os requisitos funcionais serão avaliados da seguinte forma:

8.12.2.1. Tendo como referência os Requisitos Funcionais contidos no ANEXO I – Projeto

Xxxxxx, a PROPONENTE em Avaliação deverá demonstrar, de ponta a ponta, macroprocessos conforme a seguir, por meio da execução de funcionalidades da Solução ofertada neste certame.

I. Demonstração do Macroprocesso de atendimento de uma solicitação do SAMU para usuário da Macro Centro pelo sistema da PROPONENTE:

1. Registrar o cadastro da ocorrência de uma ligação externa, simulando uma Central de Atendimento do SAMU.

2. Tramitar a ocorrência para o regulador via sistema.

3. Registrar, pelo regulador, os dados de atendimento relativo à:

a) tipo de demanda (trauma, clínica, etc.);

b) descrição da demanda com as informações clínicas do paciente e o contexto da cena;

c) classificação da prioridade;

d) necessidade de envio de uma ambulância;

e) definição do tipo de ambulância com envio de uma USB e depois a redefinição paraUSA;

f) orientação prestada ao solicitante.

4. Exibir o ordenamento dos atendimentos com base nos dados fornecidos pelo sistema e exibido sem painel que deve indicar minimamente: dados do status das ambulâncias e a classificação da prioridade dos atendimentos em curso, localização e tempo de deslocamentos das ambulâncias disponíveis mais próximas da ocorrência atual.

5. Empenhar a ambulância, pelo controlador de frota, com base no ordenamento e tipo de ambulância definidos pelo regulador.

6. Emitir alerta para a equipe de atendimento, com exibição dos dados da solicitação contendo: o local da ocorrência e dados clínicos do paciente e informações coletadas pelo regulador.

7. Permitir a confirmação do recebimento da ocorrência pela equipe de atendimento da ambulância e aviso do início do deslocamento.

8. Registrar o atendimento da ocorrência, por meio de registro em texto, gravação de vídeo, foto e áudio com a transmissão dos dados para a central.

9. Registrar a conduta do regulador para o atendimento, com a consulta às informações inseridas pela equipe de atendimento, inclusive fotos vinculadas à ocorrência e orientação da equipe da ambulância.

10.Permitir a comunicação via chat entre a equipe e o regulador sobre o atendimento.

11.Permitir ao regulador registrar a unidade de destino passando essa informação para a equipe de atendimento.

12.Permitir a geração de relatório do atendimento a ser entregue na recepção da unidade de destino.

13.Encerrar a solicitação pela central de regulação após a finalização do atendimento, com atualização automática do status da ocorrência e liberação da ambulância.

8.13. Teste 2 – TDC- RFU - Teste de Conformidade de Requisitos Funcionais

8.13.1. A avaliação dos requisitos funcionais se baseará em uma seleção de 25 (vinte e cinco) requisitos parao módulo SAMU, que foram preenchidos pela PROPONENTE em Avaliação como atendidos, pela solução ofertada neste certame, na condição de Nativo ou Parametrizável.

8.13.2. A seleção dos requisitos será por meio de sorteio realizado no início dos trabalhos. O sorteio será realizado por meio de macro em Planilha eletrônica - Excel. A PROPONENTE em avaliação poderá conferir este mecanismo.

8.13.3. A dinâmica do TDC-RFU será:

a) Declarada aberta a sessão, estando presente a PROPONENTE em Avaliação, com seus representantes credenciados e, portando/acessando o piloto/amostra, a Equipe Técnicade Avaliação dará início aos trabalhos.

b) Os requisitos a serem demonstrados serão sorteados. A PROPONENTE em avaliação deverá fazer a leitura do requisito e proceder com a sua demonstração, informando o término da demonstração daquele requisito.

c) Xxxx a PROPONENTE em Avaliação não consiga demonstrar um determinado requisito, ela poderá, exclusivamente durante a sessão, a partir de uma solicitação à Equipe Técnica de Avaliação, preparar a nova demonstração.

d) Concluída as demonstrações, a Equipe Técnica de Avaliação declarará encerrada a sessão de testes.

e) A Equipe Técnica de Avaliação se reunirá para elaborar o Relatório de Avaliação dos testes de conformidade, que será entregue ao ao Diretor da Área Técnica e ao pregoeiro, em até

3 (três) dias após a finalização das demonstrações, com a conclusão da Avaliação apresentada de forma clara e inequívoca: Aprovada ou Reprovada, o que representa respectivamente, Classificada ou Desclassificada.

● Serão anexados ao Relatório os registros individuais dos integrantes da equipe.

8.14. Condições de reprovação:

8.14.1. Não comparecimento para execução dos testes de conformidade na data e hora marcadas.

8.14.2. Não demonstrar em sua completude ou demonstrar com a presença de erros requisitos indicados para verificação de conformidade em número superior ao descrito a seguir:

a) Para a TDC-PROC

●Três itens do Macroprocesso do SAMU.

Entende-se por item o passo numerado na descrição do macroprocesso.

b) Para TDC-RFU

Requisitos Funcionais (RFU) - 20 % dos requisitos sorteados, sendo:

●5 requisitos do módulo SAMU do total de 25 requisitos sorteados.

8.14.3. Não atendimento a qualquer regra do edital relativa à verificação de conformidade.

8.14.4. Em caso de reprovação da PROPONENTE em Avaliação nos testes de conformidade, será convocada a PROPONENTE subsequente, conforme a ordem de classificação no certame.

8.15. Disposições gerais dos testes de conformidade:

8.15.1. Será concedida uma única oportunidade para a realização dos testes de conformidade (TDC- PROC, TDC-RFU) para a PROPONENTE em Avaliação.

8.15.2. Não será permitida a prorrogação dos prazos estabelecidos no procedimento dos testes, salvo por motivo devidamente justificado e aceito pela CONTRATANTE.

8.15.3. Caberá à CONTRATANTE apenas a disponibilização do local para a realização dos testes.

8.15.4. Ocorrendo alguma situação excepcional que demande o adiamento da data e/ou horário da realização dos testes, a PROPONENTE em Avaliação será devidamente comunicada e convocada para nova data.

8.15.5. Eventuais questionamentos prévios acerca da execução dos testes poderão ser feitos pelas PROPONENTES, oportunamente, nos prazos pertinentes ao pedido de esclarecimentos e impugnações, após publicado o edital de licitação.

8.15.6. Será oportunizado às PROPONENTES a possibilidade de recorrer da execução dos testes, por meio da via recursal licitatória, depois de comunicado o Relatório de Avaliação.

8.15.7. A aprovação nos testes de conformidade classifica a PROPONENTE como fornecedora aprovada para a contratação.

9. DA FORMALIZAÇÃO DO CONTRATO

9.1. Homologada a licitação será firmado contrato com o licitante vencedor do presente pregão nos termos da minuta constante do Anexo X, parte integrante deste edital, que conterá, dentre suas cláusulas, as de Obrigações da Contratada e Obrigações do Contratante.

9.2. O prazo de vigência do contrato é de 48 (quarenta e oito meses) sem prejuízo da garantia, contados

da data de assinatura do presente instrumento, podendo ser prorrogado, em conformidade com o Art. 57, inciso I e/ou § 1° da Lei nº 8.666/93.

9.2.1. Em observância ao investimento realizado pela adjucatária para atender 100% do escopo do objeto e a inevitável redução de valor para a administração pública, devido a segunça de um contrato de maior vigência, justifica-se o período inicia do contrato de 48 (quarenta e oito) meses

9.3. Ocorrendo prorrogação, serão mantidas as condições do contrato inicial e observada a legislação em vigor. Nos casos de majoração do valor contratual exigir-se-á reforço da garantia prevista.

9.4. A Adjudicatária deverá assinar o contrato dentro do prazo de 05 (cinco) dias contados da respectiva convocação.

9.4.1. O prazo para a assinatura do contrato poderá ser prorrogado uma vez, por igual período, quando solicitado pela adjudicatária durante o seu transcurso, desde que ocorra motivo justificado e aceito pela CONTRATANTE.

9.5. Quando da assinatura do contrato a adjudicatária deverá apresentar e/ou comprovar:

9.5.1. Comprovação da realização da garantia contratual.

9.5.2. Termo de Constituição do Consórcio, se for o caso.

9.6. A recusa em formalizar o contrato ou não apresentar a documentação indicada nos sub-itens anteriores, no prazo estabelecido, sem justificativa por escrito e aceita pela autoridade competente, bem como a não manutenção de todas as condições exigidas na habilitação, sujeitará a licitante vencedora às penalidades cabíveis, sendo facultado à CONTRATANTE convocar remanescentes, na ordem de classificação, nos termos da Lei nº 10.520/2002.

9.7. As despesas com a publicação do extrato do contrato no Diário Oficial correrão por conta da CONTRATANTE.

10. ÍNDICE DE REAJUSTE

10.1. Para todos os contratos, se necessário, serão reajustados mediante iniciativa da CONTRATADA, desde que observados o interregno mínimo de 01 (um) ano a contar da data limite para apresentação da proposta ou do último reajuste, tendo como base a variação do Índice Nacional de Preços ao Consumidor Amplo do Instituto Brasileiro de Geografia e Estatística (IPCA/IBGE).

10.2. Os efeitos financeiros do reajuste serão devidos a partir da solicitação da CONTRATADA.

11. GARANTIA CONTRATUAL:

11.1. Exigir-se-á da CONTRATADA, previamente à assinatura do contrato, a prestação de garantia no percentual de 5% (cinco por cento) do valor do contrato, conforme condições estabelecidas na minuta do contrato, anexo X do presente edital.

12. DAS SANÇÕES ADMINISTRATIVAS

12.1. Verificada a prática de ato ilícito (assim considerada a conduta que infringe dispositivos legais, atos convocatórios de licitação, no contrato ou instrumento que o substitui) e descumprimento dos parâmetros de Níveis de Serviços Acordados (SLAs – Anexo VI), ficará a CONTRATADO sujeito às seguintes penalidades:

12.1.1. Advertência.

12.1.2. Multas nos seguintes percentuais:

a) Multa moratória de 0,33% (trinta e três centésimos por cento) por dia de atraso na entrega de material ou execução de serviços, até o limite de 9,9%, correspondente a até30 (trinta) dias de atraso, calculado (Indicador de Cumprimento de Prazo dos Marcos –ICPM, descrito no Anexo VI) sobre o valor correspondente à parte inadimplente, excluída, quando for o caso, a parcela correspondente aos impostos destacados no documento fiscal, nos termos do Decreto nº 15.113/2013.

b) Multa indenizatória de 10% (dez por cento) sobre o valor total da nota de empenho ou outro instrumento hábil em caso de recusa do infrator em aceitá-la (o) ou retirá-la (o).

c) Multa de 3% (três por cento) sobre o valor total da adjudicação da licitação quando houver o descumprimento das normas jurídicas atinentes ou das obrigações assumidas,nos termos do art. 7º, IV, do Decreto Municipal nº 15.113/13.

d) Multa de 5% (cinco por cento) sobre o valor da parcela que eventualmente for descumprida na hipótese de o infrator entregar o objeto contratual em desacordo com as especificações, condições e qualidade contratadas e/ou com vício, irregularidade ou defeito oculto que o tornem impróprio para o fim a que se destina.

e) Multa indenizatória de 5% (cinco por cento) sobre o valor total do contrato por inexecução parcial dos serviços que acarretem a inviabilidade da entrada em produção da solução de forma global e integrada.

f) Multa aplicada pelo descumprimento dos Níveis de Serviços Acordados aferidos pelos indicadores: Indicador de Defeitos no Software (IDS), Indicador Satisfação do Treinamento (IST), Indicador de Suporte Técnico (ISUT) e Indicador de Disponibilidade da Hospedagem do Sistema (IDHS), descritos no Anexo VI.

g) Multa indenizatória de 10% (dez por cento) sobre o valor total do contrato ou instrumento equivalente quando o infrator der causa ao seu cancelamento.

h) Multa indenizatória, a título de perdas e danos, na hipótese de o infrator ensejar o

cancelamento do contrato ou instrumento equivalente e sua conduta implicar em gastos à Administração Pública superiores aos contratados ou registrados.

12.1.3. Na aplicação das penalidades supracitadas será facultada a defesa prévia no respectivo processo, no prazo de 5 (cinco) dias úteis.

12.1.4. É competente para aplicar as sanções de advertência e multa a Diretoria da Área Técnica.

12.1.5. Impedimento de licitar e contratar, com o Consórcio Intermunicipal Aliança para a Saúde, nos termos do art. 7º da Lei nº 10.520/02.

12.1.6. A penalidade de impedimento de licitar e contratar será aplicada pelo Secretário Executivo do CIAS.

12.1.7. No caso de aplicação da penalidade do item 12.1.6, será concedido prazo de 10 (dez) dias úteis para apresentaçãode recurso.

12.1.8. O atraso injustificado superior a 30 (trinta) dias corridos caracterizará inexecução total do contrato e ocasionará sua rescisão, salvo razões de interesse público devidamente explicitadas no ato da autoridade competente pela contratação.

12.1.9. Nos casos previstos pela legislação, as multas poderão ser descontadas do pagamento imediatamente subsequente à sua aplicação.

12.1.10. Na hipótese de o infrator deixar de pagar a multa aplicada, o valor correspondente será executado observando-se os seguintes critérios:

a) se a multa aplicada for superior ao valor das faturas subsequentes ao mês do inadimplemento, responderá o infrator pela sua diferença, devidamente atualizada monetariamente e acrescida de juros, fixados segundo os índices e taxas utilizados na cobrança dos créditos não tributários do Município de Belo Horizonte, ou cobrados judicialmente;

b) inexistindo faturas subsequentes ou sendo estas insuficientes, descontar-se-á do valor da garantia;

c) impossibilitado o desconto a que se refere o inciso b deste item, será o crédito correspondente inscrito em dívida ativa.

12.1.11. As penalidades são independentes entre si e não exime a Contratada da plena execução do objeto contratado.

12.1.12. Na hipótese de cumulação a que se refere o subitem acima serão concedidos os

prazos para defesa e recurso aplicáveis à pena mais gravosa.

13. CONSÓRCIO

13.1. É permitida a participação de empresas reunidas em consórcio.

14. SUBCONTRATAÇÃO

14.1. Será admitida a subcontratação de serviços acessórios, correlacionados a apoio à efetivação/consecução dos Serviços Técnicos que compõem os itens do Objeto.

14.2. A subcontratação não poderá exceder a 30% (trinta por cento) do valor global do CONTRATO e deverá, necessariamente, ser previamente autorizada pela CONTRATANTE.

14.3. Não será permitida a subcontratação de empresa que tenha participado como LICITANTE isolada ou em consórcio.

14.4. A subcontratação, mesmo autorizada pela CONTRATANTE, não exime a futura CONTRATADA das obrigações decorrentes do CONTRATO, permanecendo a mesma como única responsável perante a CONTRATANTE.

14.5. A futura CONTRATADA responderá por todos os atos da SUBCONTRATADA.

15. DISPOSIÇÕES GERAIS

15.1. As relações entre a CONTRATADA e o Consórcio Intermunicipal Aliança para a Saúde serão sempre por escrito, ressalvados os entendimentos verbais motivados pela urgência dos serviços que deverão ser, imediatamente, confirmados por escrito. Para tal, conforme disposição legal deverá a CONTRATADA, nomear, formalmente, preposto.

15.2. A CONTRATADA deverá submeter, previamente, para aprovação da CONTRATANTE, qualquer substituição por motivos de faltas injustificadas, afastamentos médicos, doenças, afastamentos legais, férias ou qualquer outro motivo, seja temporário ou definitivo, dos profissionais envolvidos na execução do objeto deste TR.

15.3. A CONTRATADA fica obrigada a aceitar nas mesmas condições contratuais, os acréscimos ou supressões que se fizerem até 25% (vinte e cinco por cento) do valor inicial atualizado do Contrato, conforme parágrafo 1º do art. 65 da Lei nº 8.666/93.

15.4. Fazem parte integrante deste Termo de Referência todos os itens do Abaixo:

Projeto Básico

ANEXO I

Formulário 1 de Apresentação da Situação dos Requisitos Funcionais

ANEXO II

Formulário 2 de Apresentação da Situação dos Requisitos Não Funcionais da Solução Tecnológica

ANEXO III

Especificação da Hospedagem da Solução

ANEXO IV

Regras de Validação de Pontos de Função

ANEXO V

Interface da Solução

ANEXO VI

Níveis de Serviços Acordados (SLA’S)

ANEXO VII

Treinamento

ANEXO VIII

Declaração de Propriedade e Permissão de Comercialização

ANEXO IX

Declaração de Compromisso

ANEXO X

Minuta do Contrato – Implementação do Projeto Básico

ANEXO XI

Formulário de Resumo Financeiro da Proposta Comercial

LISTA DE FIGURAS

Quadro 1 – Projeto Básico 23 Municípios da Macrorregião, com suas respectivas populações

Quadro 2 – Projeto Básico 23 Municípios da Macrorregião, com suas respectivas quantidades de ambulâncias Quadro 3 – Projeto Básico Escopo e Volumetria do Projeto

Quadro 4 – Projeto Básico Cronograma e Previsão de Desembolso dos Itens II Quadro 5 – Projeto Básico Cronograma físico dos itens que compõem o objeto Quadro 6 - Anexo III Requisitos de segurança

Quadro 7 – Anexo V Integrações

Quadro 8 – Anexo VI Indicadores que serão aferidos dos SLAs

Quadro 9 – Anexo VI Indicador de Cumprimento de Prazo dos Marcos (ICPM) Quadro 10 – Anexo VI Indicador de Defeitos no Software (IDS)

Quadro 11 – Anexo VI Indicador de Satisfação do Treinamento (IST) Quadro 12 – Anexo VI Indicador de Suporte Técnico (ISUT)

Quadro 13 – Anexo VI Suporte Técnico – Nível de Severidade Quadro 14 – Anexo VI Exemplo de aplicação do indicador ISUT

Quadro 15 – Anexo VI Definição de Tempo de Atendimento do Chamado

Quadro 16 – Anexo VI Indicador de Disponibilidade da Hospedagem do Sistema (IDHS) Quadro 17 – Anexo VI Prazos das Entregas dos itens I e II do objeto

Quadro 18- Anexo VII Resumo das modalidades de treinamento por segmento de público-alvo

Formulário 1 - Anexo I Formulário de Apresentação da Situação dos Requisitos Funcionais Formulário 2 - Anexo II Formulário de Apresentação da Situação dos Requisitos Não Funcionais da

Solução Tecnológica

Formulário 3– Anexo XI Proposta Global correspondente ao valor do Lance no Pregão Eletrônico

PROJETO BÁSICO

IMPLANTAÇÃO DA SOLUÇÃO TECNOLÓGICA INTEGRADA PARA O SAMU

1. OBJETO

O objeto contempla:

I. Serviço de locação de solução integrada de SAMU para atender aos usuários simultâneos e unidades especificadas no Quadro 3 - Projeto Básico: Volumetria do Projeto, incluindo:

a) Fornecimento de licenças de uso do software

b) Suporte técnico ao usuário

c) Hospedagem da solução

d) Integração com o serviço de comunicação híbrida {satélite e celular/tablet (Multioperadora)}

II. Serviços Técnicos Especializados de implantação para cobrir o escopo descrito no Quadro 3 - Projeto Básico: Escopo e Volumetria do Projeto incluindo:

b) Parametrizações, customizações e integrações necessárias à efetiva entrada em produção de todos os requisitos funcionais e não funcionais.

c) Importação de Dados: serviço de carga de dados para as tabelas auxiliares e básicas necessárias ao funcionamento pleno da solução.

d) Disponibilização dos ambientes de homologação e de treinamento. Estes ambientes devem ser suficientes para aprovação das funcionalidades pelos usuários.

e) Implantação nas unidades de saúde especificadas no Quadro 3 - Projeto Básico: Volumetria do Projeto.

● Operação assistida na central do SAMU e nos serviços de pronto atendimento dos hospitais de referência, conforme especificado no Quadro 3 - Projeto Básico: Escopo e Volumetria do Projeto.

III. Pontos de Função: serviços para desenvolvimento e evolução da solução para atender a necessidades futuras, distintas daquelas previstas neste Edital, executados por meio de Pontos de Função a serem mensurados pela CONTRATADA e validados e autorizados pela CONTRATANTE mediante Ordem de Serviço, até o limite de 500 (quinhentos) Pontos de Função.

IV. Incremento de veículos do SAMU do município de Belo Horizonte: serviços para garantir o uso da solução, caso haja aumento no nº de veículos do SAMU, incluindo licenças, treinamento, parametrizações, configurações, bem como a sustentação (suporte aos usuários), executados por meio da unidade de custos veículo mês (total de veículos incrementados multiplicado pelo total de meses de utilização), até o limite de 420 unidades de custo veículos mês, autorizados mediante Ordem de Serviço. Por exemplo, o incremento de 5 veículos em 10 meses equivaleria ao consumo de 50 unidades de custo veículo mês).

V. Incremento incremento de veículos dos municípios do interior regulados pela Central em Belo Horizonte: serviços para garantir o uso da solução, caso haja aumento do nº de veículos do interior, incluindo licenças, treinamento, parametrizações, configurações, bem como a sustentação (, suporte aos usuários), executados por meio da unidade de custos veículo mês (total de veículos incrementados multiplicado pelo total de meses de utilização), até o limite de 966 unidades de custo veículos mês, autorizados mediante Ordem de Serviço. Por exemplo, o incremento de 5 veículos em 10 meses equivaleria ao consumo de 50 unidades de custo veículo mês). A solução deverá se dar no município de origem dos veículos. O quantitativo foi levantado pela Central de Regulação, com base no histórico dos registros da Secretaria Municipal de Saúde.

A Solução ofertada neste certame deverá atender na plenitude, em tempo de projeto, a todos os requisitos funcionais e não funcionais previstos neste Projeto Básico e seus Anexos, devendo atender de forma nativa ou parametrizável o percentual mínimo de oitenta e cinco por centos dos requisitos estabelecido no Item Qualificação Técnica. A descrição detalhada dos requisitos, especificações técnicas e de arquitetura da solução objetivada neste Termo de Referência são descritas no Projeto Básico e seus anexos.

2. JUSTIFICATIVA

Atualmente, o SAMU e o Transporte em Saúde utilizam o sistema 192, desenvolvido há mais de 18 anos em tecnologia Delphi, para registro dos dados das solicitações, sua regulação e atendimento, sendo que a comunicação entre a equipe da central e as equipes móveis se dá por meio de rádio.

Em 2017, a Subcontroladoria de Auditoria da Prefeitura Municipal de Belo Horizonte conduziu uma avaliação dos controles e da efetividade dos processos do Serviço de Transporte em Saúde - processo de auditoria nº 00.000.000.00.00, que identificou vulnerabilidades operacionais e também algumas limitações do sistema 192, que é o sistema utilizado tanto para a regulação do Transporte em Saúde quanto para a regulação do SAMU.

Os principais problemas identificados sobre o sistema foram:

a) O banco de dados não tem a estruturação e organização necessárias para sustentar o sistema de forma satisfatória e confiável.

b) O sistema não contém todas as funcionalidades necessárias às rotinas operacionais.

c) As funcionalidades existentes não validam as informações fornecidas ou emitidas pelos usuários.

d) Não há controle de segurança eficiente.

e) Inexistência de funcionalidades de consulta, geração de relatórios, controle de segurança (perfil de acesso, histórico de eventos) e mecanismos para aprovação de transportes atípicos

f) Baixa aderência do sistema aos processos do transporte em Saúde.

Ainda de acordo com o relatório da auditoria, o volume de informações armazenadas é expressivo e demanda uma plataforma robusta para o processamento das informações com a segurança e rapidez necessárias. A referida auditoria recomendou a evolução do sistema, para apoiar e qualificar os processos de trabalho.

A obsolescência tecnológica do sistema 192 compromete sua performance e escalabilidade, representando um obstáculo à sua evolução conforme indicado pela auditoria supracitada. Por outro lado, a necessidade de incorporação de novas tecnologias, tais como a comunicação híbrida por satélite e celular/tablet, que ainda não são de domínio da PBH, dificultam a estratégia de desenvolvimento de uma nova solução própria. Diante destas dificuldades e da existência no mercado soluções projetadas para atender ao SAMU, entende-se que a melhor alternativa é a substituição do sistema 192 por uma solução de mercado, customizada de acordo com as necessidades da SMSA.

A não contratação dessa nova solução representa impedimento para atender às recomendações da auditoria.

3. ESCOPO E VOLUMETRIA DO PROJETO

A Macrorregião, escopo deste projeto, é composta por três micros, sendo elas: Micro Belo Horizonte, Micro Ouro Preto e Micro Vespasiano. A população a ser atendida será de 3.902.598 (três milhões, novecentos e dois mil, quinhentos e noventa e oito) habitantes, conforme quadro 1, abaixo:

Quadro 1 – 23 Municípios da Macrorregião, com suas respectivas populações:

<.. image(Tabela Descrição gerada automaticamente) removed ..>

Apesar de compreender 23 municípios, apenas 16 municípios serão sede de Base Descentralizada, representado, no quadro 2 abaixo, pelos municípios que possuem, no mínimo 01 ambulância:

Quadro 2 – 23 Municípios da Macrorregião, com suas respectivas quantidades de ambulâncias:

<.. image(Tabela Descrição gerada automaticamente com confiança média) removed ..>

Neste escopo, serão 54 ambulâncias reguladas pela Central de Regulação sediada em Belo Horizonte. Esse quantitativo pode sofrer acréscimos a depender de demandas extraordinárias, tais como situações de epidemia, eventos de grande porte, expansão do número de municípios regulados por BH, aumento da população, aumento de Bases Descentralizadas, etc.

Serão usuários da solução, além da central do SAMU e suas equipes móveis, as UPA e as unidades hospitalares de pronto atendimento de referência para os municípios. As UPAs farão solicitação de transferência de cidadãos para unidades hospitalares de referência para pronto atendimento. Estas unidades hospitalares de referência também serão usuárias do sistema para atualizar diariamente as condições operacionais de atendimento (leitos de urgência disponíveis, composição das equipes, situação de equipamentos e outros recursos que podem impactar na capacidade de atendimento).

As ambulâncias da região metropolitana que são reguladas pela Central de Regulação também terão acesso direto à solução. Ressalta-se que a composição desses municípios regulados pela Central em Belo Horizonte pode sofrer mudanças durante o período de contrato. Nesta situação, havendo incremento de ambulâncias, poderá haver o consumo do Item V do objeto.

O horário de funcionamento do SAMU é 24 horas por dia, 7 dias por semana. Em determinadas situações, algumas demandas de transferência de pacientes são atendidas pelo Serviço de Transporte em Saúde, bem como algumas demandas de transporte são atendidas pelo SAMU.

Quadro 3 - Escopo e volumetria do Projeto

Nº unidades usuárias da solução para fins de implantação	45*
Nº de usuários para fins de treinamento	890

Nº de usuários simultâneos - estimativa	225**
Nº de veículos em Belo Horizonte	28
Nº de veículos de outros municípios regulados em BH	26
Nº médio de solicitações atendidas por mês - Estimativa	8.900

* Central SAMU, UPA`s, Hospitais de referência e Pronto Atendimentos. Estes hospitais utilizarão o sistema para informar as condições de operação e atendimento (nº de leitos disponíveis, eventuais impedimentos por falta de profissional ou equipamentos, etc.).

** É estimado 225 acessos simultâneos, sendo 15 TARM´s / 05 Rádio Operador (Despachante) / 10 Médicos Reguladores / 12 Supervisão/Direção / 60 Mobile Embarcados / 69 Mobile para Gestores Municipais / 50 Mobile nas Bases Descentralizadas / 04 Mobile CIAS.

4. VISÃO GERAL DOS MACROPROCESSO NA NOVA SOLUÇÃO

Solução de gestão integrada para informatizar o Serviço de Atendimento Móvel de Urgência (SAMU) contemplando o gerenciamento das solicitações, regulação, atendimento móvel, controle e monitoramento de veículos, serviços de implantação, suporte, manutenção, hospedagem da solução, integração com a solução de comunicação híbrida {satélite e celular (multioperadora)}.

O componente de software da Solução Integrada deve contemplar o gerenciamento das solicitações, regulação, atendimento móvel, controle e monitoramento de veículos, integração com a solução de comunicação híbrida {satélite e celular/tablet (Multioperadora)}.

O componente de software da Solução Integrada deve estar apto a integrar-se aos dispositivos móveis (Tablet e Celular), bem como Impressora Térmica, Transceptores Satelitais todos esses embarcados em cada ambulância.

O componente de serviços técnicos especializados de implantação inclui o mapeamento, customizações, integrações, parametrizações, importação de dados, treinamento, operação assistida, suporte aos usuários e manutenção das licenças.

4.1. Conceitos e categorias de atendimento do SAMU

A solicitação de atendimento do SAMU é definida pelos seguintes conceitos e categorias:

● Ocorrência: é toda ligação recebida na Central, via 192, e deverá ser representada no sistema por uma série numérica (código da ocorrência) e tipificada conforme descrição a seguir.

● Tipo de ligação: Engano, trote, ligação interrompida, solicitação de informações em saúde ou solicitação de atendimento.

● Classificação quanto ao tipo de recurso (ambulância) demandado:

⮚ Unidade de Suporte Básico - USB: enviada nas ocorrências em que, pelo menos inicialmente, não há indícios da necessidade de medidas de suporte avançado

⮚ Unidade de Suporte Avançado - USA: enviada nas situações em que há risco imediato à vida, com necessidade de medidas de suporte avançado, como o estabelecimento de via aérea definitiva, por exemplo.

● Tipo de solicitação:

⮚ Pré-hospitalar ou atendimento móvel pré-hospitalar primário: quando a solicitação de atendimento é acionada por um cidadão comum

⮚ Inter hospitalar ou atendimento móvel pré-hospitalar secundário: transferência dos pacientes já atendidos em algum serviço médico (UPA e hospitais) quando há indicação de encaminhamento da vítima para o CTI ou necessidade de avaliação/propedêutica/terapêutica especializada, não disponível na unidade em que se encontra o paciente, ou seja, situação na qual o paciente já tenha recebido o primeiro atendimento necessário para a estabilização do quadro de urgência apresentado, mas necessite ser conduzido a outro serviço de maior complexidade para continuidade do tratamento.

● Tipos de demanda: Os atendimentos realizados pelo SAMU são classificados em grupos de atendimentos (clínico, trauma, psiquiátrico, gineco-obstétrico, inter-hospitalares, entre outros) conforme os protocolos da instituição que trazem informações detalhadas sobre como se proceder quanto ao provável diagnóstico, tratamento imediato e encaminhamento dos pacientes para as unidades assistenciais de acordo com a grade de referência/encaminhamento.

● Classificação de prioridade baseada em protocolo interno.

5.1. Fluxo da solicitação do SAMU no novo sistema

1. Atendimento pelo teledigifonista de uma ligação para o 192 (Serviço de Atendimento Móvel de Urgência) com a gravação do áudio e dos registros do cadastro da ocorrência na Central de Atendimento, inclusive do tipo de ligação e com início da contagem do tempo de atendimento em tela.

2. Integração do sistema do SAMU com o sistema SIGBASES, permitindo a busca opcional de dados do paciente, tais como: nome completo, idade, endereço e demais dados que estiverem disponíveis no cadastro do SIGBASES permitindo manter os dados recuperados. Este campo deve permitir inclusão na solução SAMU caso o usuário não seja localizado na base do SIGBASES.

3. Caso o paciente não seja localizado no SIGBASES, o sistema deve imediatamente integrar ao cadastro universal do Sistema Único de Saúde, o qual está diretamente vinculada ao Cartão SUS.

4. Tramitação da ocorrência para o regulador primário via sistema.

5. Registro pelo regulador primário: descrição da demanda com as informações clínicas do paciente e o contexto da cena, tipo de demanda (trauma, clínica, etc.), tipo de solicitação, classificação da prioridade; necessidade de envio de uma ambulância; tipo de recurso e da orientação prestada ao solicitante; utilização de scores padronizados de prioridade com campos específicos para o registro das informações.

6. Tramitação da solicitação para o regulador secundário via sistema.

7. Registro pelo regulador secundário: redefinição das categorias registrada pelo primeiro nível de regulação, se necessário, e ordenamento dos atendimentos com base nos dados fornecidos pelo sistema e exibidos em painel, tais como: status das ambulâncias, classificação da prioridade dos atendimentos em curso, localização e tempo de deslocamentos das ambulâncias disponíveis mais próximas da ocorrência atual.

8. Empenho da ambulância, pelo controlador de frota, ou por auto empenho, com base no ordenamento e tipo de ambulância definidos pelo regulador secundário.

9. Alerta para a equipe de atendimento, via sistema, com exibição dos dados da solicitação contendo: o local da ocorrência e dados clínicos do paciente e informações coletadas pelo regulador primário e secundário.

10. Confirmação do recebimento da ocorrência pela equipe de atendimento da ambulância e aviso do início do deslocamento, via sistema.

11. Localização automática georreferenciada e em tempo real do deslocamento da ambulância até o local de ocorrência com a exibição gráfica em mapa do, informando as características da ambulância, sendo elas: velocidade, status da sirene e giroflex, status da ambulância se ligada ou desligada, status da conexão com dados ou satélite.

12. Registro do atendimento da ocorrência, por meio de registro em texto, digitação por voz, gravação de vídeo, foto e áudio com a transmissão dos dados para a central via sistema.

13. Definição e registro da conduta para o atendimento pelo regulador secundário, com a consulta às informações inseridas pela equipe de atendimento, inclusive fotos vinculadas à ocorrência e orientação da equipe da ambulância via sistema.

14. Envio, pela equipe, via sistema, de dúvida sobre a conduta médica definida pelo regulador secundário.

15. Retorno do regulador secundário, via chat no sistema, com as orientações solicitadas pela equipe de atendimento.

16. Definição da unidade de atendimento pelo regulador secundário, com consulta às informações da grade de leitos das unidades com acesso a interface do sistema, e envio via sistema definindo qual unidade de atendimento o paciente deve ser encaminhado.

17. Geração de relatório do atendimento a ser impresso na ambulância e entregue na recepção na unidade de atendimento.

18. Registro da finalização do atendimento pela equipe de atendimento via sistema, após a recepção do paciente na unidade de atendimento.

19. Registro de checklist de materiais e medicamentos utilizados no atendimento vinculadas a ocorrência para fins de controle.

20. Encerramento da solicitação pela central de regulação, no sistema, após a finalização do atendimento, com atualização automática do status da ocorrência e liberação da ambulância.

5. REQUISITOS FUNCIONAIS DA SOLUÇÃO

Os Requisitos funcionais, descritos no ANEXO I, pretendem definir as funções do software, que podem ser agrupadas e identificadas por módulo ou componente do sistema que são necessárias para apoiar os processos de SAMU na rede própria SUS da Macrorregião.

6. REQUISITOS NÃO FUNCIONAIS DA SOLUÇÃO

Requisitos não funcionais, ao contrário dos funcionais, não expressam nenhuma função (transformação) a ser implementada em um sistema de informações; eles expressam condições de comportamento e restrições e devem prevalecer. Portanto, não será aceito o produto que não atender a todos os requisitos não funcionais classificados como essenciais/obrigatórios.

Em suma, trata-se de um conjunto de requisitos que devem ser atendidos para garantir o pleno funcionamento do software na infraestrutura padronizada e com padrão de qualidade indicado pela CONTRATANTE. Ver ANEXO II deste Projeto.

Os requisitos não funcionais poderão ser aferidos no início da utilização da solução e/ou no decorrer da sua utilização, podendo ser cobrados durante toda a execução contratual, sendo o seu não atendimento passível de sanções cabíveis.

7. INTERFACES/INTEROPERABILIDADE COM OUTROS PRODUTOS

No ANEXO V, consta a relação dos principais sistemas da CONTRATANTE e/ou sistemas de terceiros que deverão ter interoperabilidade/integração com os módulos do escopo deste Projeto Básico, entretanto, novos poderão surgir em tempo de projeto e serão desenvolvidos com consumo pontos de função.

A CONTRATADA será responsável pelo interfaceamento da solução com os sistemas da CONTRATANTE e/ou sistemas de terceiros, que forem definidos pela CONTRATANTE.

As interfaces não previstas serão implementadas utilizando os Pontos de Função previstos no Item III do Objeto (Serviços Adicionais).

8. RESTRIÇÕES IMPOSTAS À SOLUÇÃO - SERVIÇOS E PRODUTOS

A atuação da CONTRATADA será preferencialmente na sede da CONTRATANTE.

A solução não deverá usar o Data Center da Prodabel, e nenhum outro da CONTRATANTE, para hospedagem de toda a infraestrutura necessária para uso do sistema.

9. ESPECIFICAÇÃO DOS SERVIÇOS

Descrição dos Serviços por itens do objeto:

9.1 Para dimensionar os serviços deste projeto deve-se considerar os dados contidos no Edital, no Termo de Referência e no Projeto Básico e todos os seus anexos, especialmente os ANEXO I, II, III, IV, V, VI, VII, X e o prazo de execução de 48 meses.

9.2 Nestes documentos estão contemplados dados dos serviços que serão informatizados com a solução tecnológica ofertada neste certame, incluindo a volumetria detalhada no Quadro 3 -Projeto Básico: Escopo e Volumetria do Projeto, funcionalidades, integrações, infraestrutura, uso do sistema e prazo da implantação. Cabe à CONTRATADA considerar todos os dados na elaboração da proposta técnica e comercial a fim de cumprir o pretendido no objeto desta contratação.

9.3 Os dados permitem dimensionar o volume de transações que serão executadas no sistema e as integrações necessárias (interoperabilidades necessárias) para o uso da solução adquirida no contexto das SMSA´s, bem como da Central de Regulação sediada em BH).

9.4 Item I do Objeto - Serviço de fornecimento de licenças de uso do software, suporte técnico ao usuário, manutenção das licenças, hospedagem da solução.

9.4.1 Serviço de fornecimento de licenças de uso da solução, bem como o ambiente de produção, para atender aos usuários simultâneos e unidades especificadas No Quadro 3 - Volumetria do Projeto, operando com desempenho satisfatório conforme descrito nos indicadores e níveis de serviços descritos no Anexo VI do projeto Básico. A solução deve ser responsiva de forma que permita seu uso por meio de dispositivos móveis e/ou disponibilizar aplicativos.

Produto entregue mensalmente:

● Ambiente de produção em funcionamento com as licenças de uso instaladas e disponíveis conforme descrito no Anexo III - Hospedagem da solução

9.4.2 Serviço de manutenção e atualização das licenças da solução e suporte técnico ao usuário contemplando:

● Manutenção adaptativa relativa à atualização e manutenção do sistema de forma a mantê-lo em conformidade às exigências legais, para a política pública de saúde, dos municípios abrangidos na nessa Macrorregião, principalmente as específicas de Belo Horizonte. Deverá ser implantada e testada em até 30 dias antes do prazo legal para início da nova obrigação conforme a legislação.

● Manutenção corretiva relativa às correções identificadas pela CONTRATANTE, podendo estar relacionadas às customizações e integrações realizadas para o sistema, ou não.

● Suporte remoto e síncrono ao usuário do sistema voltado para os administradores, parametrizadores e usuários finais 24 x 7.

Produto entregue mensalmente:

● Solução atualizada, mantida aderente ao processo de trabalho e em pleno funcionamento por 42 meses.

● Usuários da solução e técnicos da CONTRATANTE assistidos conforme SLA por 42 meses.

9.4.3 Serviço de hospedagem – As exigências e padrões da hospedagem estão descritas no ANEXO III – Especificação de Hospedagem da Solução.

Produto entregue mensalmente:

● Solução de hospedagem atualizada, mantida aderente aos padrões exigidos pela Contratada e em pleno funcionamento, durante a vigência do contrato, conforme detalhado no ANEXO III - Hospedagem da Solução.

9.4.4 Serviço de Integração com a comunicação híbrida {satélite e celular (multioperadora)}

Serviço de integração com a comunicação híbrida incluindo canais de comunicação combinando as tecnologias de comunicação móvel e de satélites. O canal de dados deve ser a forma principal de comunicação, sendo a comunicação por satélite utilizada na situação de contingência, de maneira automática e transparente para o usuário. A CONTRATADA deverá apresentar relatórios comprovando o uso de ambas as tecnologias, com datas e horários do uso de cada uma delas, bem como a localização das ambulâncias sempre que o satélite for acionado, em periodicidade a ser definida pela CONTRATANTE que poderá realizar auditorias a qualquer momento.

Produto entregue mensalmente:

● Solução de Integração com a comunicação disponível operando conforme SLA com todos seus componentes para o escopo e a volumetria descrita no Quadro 3 - Projeto Básico: Escopo e Volumetria do Projeto durante 42 meses.

9.4.5 O Item I do Objeto iniciará após a instalação de equipamentos embarcados nas ambulâncias, incluindo a solução de integração com a comunicação híbrida, e o Termo de Aceite Definitivo do Item II do Objeto. Nas condições a seguir, o Item I prescinde do Termo de Aceite Definitivo do Item II do objeto:

● Desenvolvimento das funcionalidades mínimas para a implantação em produção e substituição do sistema legado.

● Plano de conclusão das pendências do item II do objeto, com detalhamento de prazos, treinamento, integrações, operação assistida, bem como os respectivos desembolsos, dentre outros.

9.5 Item II do Objeto - Contratação de Serviços Técnicos Especializados de implantação

9.5.1 Mapeamento e desenho dos processos de SAMU

Para as atividades relacionadas à modelagem de negócio, deverá ser utilizado Business Process Modeling – BPM, com o padrão de representação Business Process Modeling Notation – BPMN. E para tal, utilizar ferramenta livre, como por exemplo Bizagi Process Modeler, e sem custo adicional a CONTRATANTE:

● Realizar o mapeamento (as is) dos processos, subprocessos e atividades existentes, identificando as parametrizações necessárias bem como eventuais customizações.

● Desenhar os processos, subprocessos e atividades com as melhorias e padronizações. Apresentar e validar com a CONTRATANTE as proposições dos processos.

● Documentar o processo desenhado (to be) com descrição de todos os níveis (processos, subprocessos e atividades) e entrega da documentação impressa e em meio digital.

● Elaborar Plano de Implantação dos Processos (to be) estabelecendo relação entre processos/subprocessos e atividades com módulos/componentes/funcionalidades, comandos e parâmetros (orientações para a implantação) da solução.

Produto entregue:

● Documento com o registro do Processo (to be) incluindo oportunidades de melhorias nos processos e parâmetros do SAMU e Plano de Implantação.

9.5.2 Disponibilização dos ambientes de homologação e de treinamento

Estes ambientes deverão ser disponibilizados para a CONTRATANTE via acesso WEB, durante a vigência do contrato.

O ambiente de homologação deve ser suficiente para aprovação das funcionalidades pelos usuários.

Produto entregue:

● Ambientes de homologação e de treinamento em funcionamento em ambiente da CONTRATADA com capacidade para suportar 100 (cem) usuários simultâneos (em treinamento).

9.5.3 Customizações necessárias à efetiva entrada em produção de todos os requisitos funcionais e não funcionais.

Entende-se por customizações todas as melhorias identificadas como necessárias no sistema para garantir maior e melhor adesão aos processos de trabalho. Uma customização poderá ser classificada como:

● Customização SEM consumo de Pontos de Função - melhoria identificada, previamente pela contratada no preenchimento do formulário I do Anexo I (Formulários de Apresentação da Situação dos Requisitos Funcionais) como customizável ou requisito classificado como Nativo ou Parametrizável não demonstrado nos Testes de Conformidade (TDC-RFU).

● Customização COM consumo de Pontos de Função: melhoria identificada como necessária, mas sem cobertura por requisito funcional - novo escopo. Necessita de autorização para o consumo de Pontos de Função.

● Refinamento - uma melhoria identificada como necessária e coberta por requisito funcional (Anexo I) que foi classificado pela contratada como Nativo ou Parametrizável, mas avaliado como não aderente ao processo de trabalho após o mapeamento e desenho de processos e apresentação do sistema. Uma customização nessa situação representará uma implementação de melhoria no sistema SEM consumo de Ponto de Função.

9.5.3.1 A produção das CUSTOMIZAÇÕES, que compõem este entregável se baseará na seguinte metodologia:

1) A CONTRATADA deverá apresentar todas as funcionalidades Nativas e Parametrizáveis do sistema para cada etapa do processo de trabalho articulando-as com as propostas de melhorias, parametrizações e customizações da etapa de mapeamento.

2) A equipe do negócio da CONTRATANTE deverá verificar se as funcionalidades apresentadas têm requisito funcional previsto no Anexo I e se o preenchimento realizado pela CONTRATADA, para efeito da Habilitação Técnica, corresponde ao produto apresentado. Para cada requisito, a equipe deverá registrar:

● VALIDADO - requisito demonstrado e aderente ao processo de trabalho, sem necessidade de adequação ou melhoria.

● PARCIAL - requisito demonstrado parcialmente, necessitando de customização para torná-lo aderente ao processo de trabalho e para validá-lo, mesmo que tenha sido declarado como nativo e parametrizável pela CONTRATADA.

● CUSTOMIZADO - requisito não demonstrado, necessitando de customização para considerá-lo validado.

3) As equipes da CONTRATADA e CONTRATANTE deverão alinhar a compreensão da reclassificação

dos requisitos funcionais e caso ocorra discordância, essa deve ser tratada entre preposto da CONTRATADA, Gestor e Fiscal de contrato da CONTRATANTE.

4) Para as necessidades de funcionalidades não cobertas por requisitos, a customização será realizada por meio do consumo do Pontos de Função e emissão de Ordem de Serviço.

9.5.3.2 O escopo para a customização será composto de:

1) Requisitos reclassificados como PARCIAL ou CUSTOMIZADO, cobertos por requisitos funcionais do Anexo I, desenvolvidos sem consumo de Pontos de Função

2) Necessidades não cobertas pelos requisitos funcionais do Anexo I, desenvolvidos com consumo de Pontos de Função.

9.5.3.3 As equipes da CONTRATADA e CONTRATANTE deverão classificar os requisitos/necessidades conforme a prioridade, sendo:

● Prioridade 0 - como imprescindíveis para entrada em produção (substituição do sistema legado);

● Prioridade 1 - que pode ser implantado de forma incremental após a entrada em produção; e

● Prioridade 2 - menor prioridade.

9.5.3.4 Com o escopo definido de forma macro e priorizado pela equipe da CONTRATANTE, a equipe da CONTRATADA deverá atuar baseando-se em Metodologia Ágil de desenvolvimento de software, distribuindo o escopo em releases/sprints como capacidade de produção compatível com o cronograma apresentado neste Projeto Básico.

9.5.3.5 As customizações implementadas deverão ser homologadas pela equipe da CONTRATANTE, que atualizará a classificação dos requisitos funcionais.

9.5.3.6 A CONTRATADA deverá incorporar as melhorias nos materiais de treinamento.

9.5.4 Parametrizações necessárias à efetiva entrada em produção de todos os requisitos funcionais e não funcionais.

Caberá a CONTRATADA realizar a inserção dos parâmetros e configurações conforme necessidade do negócio da CONTRATANTE sem custos para a CONTRATANTE.

9.5.5 Integrações necessárias à efetiva entrada em produção de todos os requisitos funcionais e não funcionais.

As integrações devem ser desenvolvidas conforme indicado no Anexo V e detalhamento a serem definido em tempo de projeto.

9.5.6 Importação e exportação de dados não constituem integrações.

Importação de dados necessários à efetiva entrada em produção de todos os requisitos funcionais e não funcionais. Importação de Dados: serviço de carga de dados para as tabelas auxiliares e básicas e dados dos sistemas legados necessários ao funcionamento pleno do sistema. Caberá à CONTRATANTE o fornecimento de dados, em condição adequada para a carga, oriundos dos sistemas legados.

Produto entregue:

● Solução customizada e parametrizada, adaptada às necessidades de processos, definidas nos ANEXOS I e II e com as integrações descritas no ANEXO V, em tempo de projeto.

● Importação de Dados: serviço de carga de dados para as tabelas auxiliares e básicas e dados dos sistemas legados necessários ao funcionamento pleno do sistema.

9.5.7 Treinamento dos usuários na solução

A CONTRATADA deverá apresentar uma proposta específica de treinamento, conforme detalhado no Anexo VII, para cada segmento de público-alvo a saber:

1) usuários administradores/parametrizadores/auditores;

2) usuário final da solução nas unidades assistenciais e de gestão

Produto entregue:

● Usuários (administradores, parametrizadores auditores e usuários finais) plenamente capacitados no uso do sistema.

9.5.8 Operação assistida junto aos usuários do sistema para apoiá-los no uso, conforme a necessidade, dos módulos contemplados nos requisitos descritos nos ANEXOS I e II do Projeto Básico. Na entrada em produção a CONTRATADA deverá manter uma equipe de suporte técnico, com capacidade técnica

comprovada para resolução dos problemas, esclarecimento de dúvidas, apoio aos usuários pós- treinamento, atendendo aos usuários finais, administradores, parametrizadores e auditores.

Produto entregue:

● Suporte presencial junto aos usuários do SAMU (Central e equipes móveis) e unidades de pronto atendimento de referência, em escala 24x7, durante a entrada em produção por período igual a 15 dias.

Os entregáveis do Item II do objeto serão remunerados conforme cronograma de desembolso (Quadro 4 - Cronograma e Previsão de Desembolso Item II) e mediante a emissão de Termo de Aceite de cada produto e, após a conclusão e aprovação completa de todo o Item II, a emissão de Termo de Aceite Definitivo.

Item III - Serviços adicionais - Pontos de Função

a) Serviços adicionais para desenvolvimento e evolução da solução referente para atender a novas necessidades e executados por meio de Pontos de Função a serem mensurados pela CONTRATADA e validados e autorizados pela CONTRATANTE mediante Ordem de Serviço, até o limite de 500 (quinhentos) Pontos de Função.

1) O quantitativo de Pontos de Função mensurados pela CONTRATADA será validado pela CONTRATANTE conforme regras do Anexo IV.

2) A previsão total de Pontos de Função para este serviço é estimada em 500 (quinhentos) e não estabelece nenhuma obrigação de utilização para a CONTRATANTE.

3) O uso dos Pontos de Função será efetivado mediante ordem de serviço quando do surgimento das demandas.

4) Os níveis de serviço pertinente, acordados no ANEXO VI, incidirão sobre esse item do Objeto.

Produto entregue:

● Sistema de SAMU customizado de acordo com as demandas identificadas distintas do Projeto Básico e seus ANEXOS, durante o período de implantação da Solução tecnológica ofertada neste certame e durante o período de manutenção.

VI. Serviços adicionais por incremento de veículos do SAMU do município de Belo Horizonte: serviços adicionais para garantir o uso da solução, caso haja aumento no nº de veículos do SAMU, incluindo licenças, treinamento, parametrizações, configurações, bem como a sustentação (suporte aos usuários), executados por meio da unidade de custos veículo mês (total de veículos incrementados multiplicado pelo total de meses de utilização), até o limite de 500 unidades de custo veículos mês, autorizados mediante Ordem de Serviço. Por exemplo, o incremento de 5 veículos em 10 meses equivaleria ao consumo de 50 unidades de custo veículo mês).

a) Está previsto um limite de 500 unidades de custo veículos mês do SAMU-BH para atender demandas de incremento de veículos ao longo do contrato. A previsão estimada de unidades de custo veículos mês para este serviço, estabelece apenas aquela obrigação de utilização para a CONTRATANTE estabelecida em lei de 75% (setenta e cinco por cento).

b) Esse incremento será efetivado mediante ordem de serviço quando do surgimento das demandas.

Produto entregue:

● Veículos equipados, usuários treinados e em pleno uso do sistema pelo período demandado pela CONTRATANTE.

VII. Serviços adicionais por incremento de veículos dos municípios do interior: serviços adicionais garantir o uso da solução, caso haja aumento do nº de veículos do interior, incluindo licenças, treinamento, parametrizações, configurações, bem como a sustentação (suporte aos usuários), executados por meio da unidade de custos veículo mês (total de veículos incrementados multiplicado pelo total de meses de utilização), até o limite de 1160 unidades de custo veículos mês, autorizados mediante Ordem de Serviço. Por exemplo, o incremento de 5 veículos em 10 meses equivaleria ao consumo de 50 unidades de custo veículo mês). A solução deverá se dar no município de origem dos veículos.

a) Está previsto um limite de 1160 unidades de custo veículo mês do SAMU - Região Metropolitana de BH para atender demandas de incremento de veículos ao longo do contrato.

b) A previsão estimada de unidades de custo veículos mês para este serviço não estabelece nenhuma obrigação de utilização para a CONTRATANTE.

c) Esse incremento será efetivado mediante ordem de serviço quando do surgimento das demandas.

d) A CONTRATADA terá o prazo máximo de 3 dias úteis, a partir do recebimento da ordem de serviço, para estar em condição de instalar os equipamentos/software e 3 horas, após a liberação do veículo pela CONTRATANTE, para fazer a instalação e ajustes no sistema deixando-os em pleno funcionamento. A CONTRATANTE poderá demandar até 5 unidades de veículo mês para serem atendidas simultaneamente.

e) O uso da solução pelas equipes dos municípios do interior, caso ocorra, se dará dentro do limite de licenças adquiridas pela CONTRATANTE.

f) O consumo desse item de incremento inclui os serviços de treinamento dos usuários (equipes móveis e serviços de referência para o pronto atendimento nos municípios), parametrizações e configurações necessárias ao pleno funcionamento, operação assistida (nos serviços de pronto atendimento de referência para os municípios), bem como a sustentação da solução (suporte técnico ao usuário,).

Produto entregue:

● Veículos equipados, usuários treinados e em pleno uso do sistema pelo período demandado pela CONTRATANTE.

10. PLANEJAMENTO DA IMPLANTAÇÃO - ITEM II DO OBJETO

Planejamento

O Planejamento do projeto deverá considerar as seguintes fases, independente da metodologia a ser utilizada: planejamento, execução, monitoramento e encerramento.

O projeto deve seguir as melhores práticas preconizadas pelo Project Management Body of Knowledge

– PMBOK, ou outra guia equivalente, em um nível de detalhamento que permita acompanhar, no mínimo, as atividades em cada fase, etapa e os recursos envolvidos, com as respectivas responsabilidades.

A CONTRATADA deverá apresentar o Plano do Projeto de Implantação (item II do objeto) que será considerado na pactuação dos prazos e no alinhamento das expectativas dos entregáveis, gerando uma linha de base.

O Plano do Projeto de Implantação deverá ser apresentado até 10 dias após a assinatura do contrato, contendo no mínimo: mapeamento do processo, disponibilização do ambiente de homologação e treinamento, customizações, integrações, povoamento de tabelas e importação de dados, parametrizações, homologação, testes, treinamento, entrada em produção, operação assistida, suporte remoto.

11. Previsão de Desembolso Financeiro

O pagamento será realizado em até 30 (trinta) dias corridos contados do adimplemento da obrigação.

Os desembolsos vão seguir as porcentagens descritas no Quadro 4 do Projeto Básico. Para efeito de desembolso uma entrega/produto pode ser particionada em componentes e os pagamentos serão efetivados após a aprovação da conclusão de cada componente. O particionamento deve ser pactuado com o Gestor e o Fiscal do Contrato e identificado na Linha de Base aprovada.

Quadro 4 - Projeto Básico: Cronograma e Previsão de Desembolso do Item II

Item	Atividade	Dias/me ses	% Desembol so	Ano I
Item	Atividade	Dias/me ses	Item II	Mê s 1	Mê s 2	Mê s 3	Mê s 4	Mê s 5	Mê s 6
	Planejament
	o	15 d	5%
	Mapeament
	o	1 m	10%
	Disponibiliza
	ção
	ambiente
	treinamento	3 m	15%
	Validação
	dos RF e
	identificação
	das
	customizaçõ
	es	2 m	0%
II	Customizaçõ
	es e
	parametrizaç
	ões	3 m	20%
	Integrações	3 m	20%
	Importações	1 m	5%
	Homologaçã
	o	2 m	0%
	Testes em
	produção	7 d	0%
	Treinamento	1 m	20%
	Solução
	plenamente
	implantada	1 d	5%
	Total	6 meses	100%

O cronograma do item II do objeto poderá ser revisto, a critério da CONTRATANTE, na etapa de Planejamento do Projeto, desde que não ultrapassem o prazo final estabelecido de 6 meses. O Item I terá início após o item II (verificar exceções descritas na Especificação dos Serviços do Item I do Objeto) e seu pagamento será mensal, por 42 meses.

Os itens III, IV e V serão executados se demandados.

12. Demais ações de Monitoramento e Controle – Projetos e Contratos

O Monitoramento e controle se baseará na produção da equipe de gerenciamento do projeto a ser constituída por representantes da CONTRATADA e da CONTRATANTE. Um importante dispositivo de comunicação é o Relatório de Acompanhamento e deverá ser adotado pelo gerenciamento do projeto.

Nos relatórios de acompanhamento dos itens I e II do Objeto devem constar, no mínimo, as seguintes informações:

a) Acompanhamento do cronograma, com um comparativo entre as atividades planejadas para o período e as atividades executadas no período. Atividades que não tenham sido executadas conforme o planejamento, devem ser acompanhadas de justificativa. Caso a justificativa seja acatada pela CONTRATANTE, um novo prazo deve ser acordado em conjunto.

b) Plano de trabalho atualizado contendo, quando necessário, os ajustes relativos ao cronograma, à alocação de recursos, à prioridade de execução de tarefas e à mudança de requisitos. Estes ajustes devem ser justificados pela CONTRATADA e devem ser aprovados pelos responsáveis pelo projeto por parte da CONTRATANTE, antes de serem executados.

c) Análise de impacto e riscos referente às possíveis mudanças no projeto que vierem a ser solicitadas pela CONTRATANTE.

d) Análise de quaisquer outros riscos inerentes ao projeto, apresentando um plano de ação para a mitigação

/ eliminação dos mesmos.

e) A referida análise de impacto e riscos deverá ser realizada sempre que a CONTRATANTE assim solicitar. As solicitações de mudanças serão encaminhadas à CONTRATADA. Esta deve providenciar uma análise de impacto e riscos que deve conter, no mínimo, as seguintes informações:

● Descrição do impacto da mudança sobre os produtos do projeto.

● Impacto no cronograma do projeto, incluindo o impacto em outras atividades.

● Análise de riscos oriundos da mudança.

A CONTRATANTE executará serviços de auditoria, verificação e monitoramento da prestação dos serviços. Nesse caso, a CONTRATADA deverá disponibilizar acesso às suas dependências, equipamentos e a toda documentação e base de dados vinculados ao serviço objeto deste certame e Anexos necessários à realização dos trabalhos de fiscalização.

13. CRONOGRAMA FÍSICO

O objeto a ser contratado será executado conforme cronograma físico descrito a seguir.

Quadro 5 – Projeto Básico: Cronograma físico dos itens que compõem o objeto

Itens do objeto	1º	2º	3º	4º	5º	Qte meses
I. Serviço de locação de solução integrada de SAMU para atender aos usuários simultâneos e unidades especificadas no Quadro 3 - Projeto Básico: Volumetria do Projeto		x	x	x	x	42
II. Contratação de Serviços Técnicos Especializados de implantação	x					6
III. Serviços Adicionais – Pontos de Função	x	x	x	x	x	48

IV. Serviços Adicionais veículo mês - BH		x	x	x	x	42
V. Serviços Adicionais veículo mês - interior		x	x	x	x	42

A execução de todo o objeto deste Projeto Básico está estimada em 48 meses, sendo 6 destinados à implantação da solução tecnológica ofertada neste certame e 42 meses destinados à contratação do serviço de disponibilização das licenças, manutenção, hospedagem e suporte técnico ao usuário. A conclusão da implantação é condição para iniciar a contratação do serviço de disponibilização das licenças, manutenção, suporte e hospedagem. Ou seja, a emissão do Termo de Aceite/Recebimento Definitivo da Implantação da solução do SAMU representa a conclusão dos itens II e autoriza automaticamente o início da execução do item I do Objeto, salvo exceções descritas na Especificação dos Serviços do Item I.

A execução do Item III do Objeto ocorrerá sob demanda e corresponderá a todo o período do projeto.

A execução dos itens V e VI – Serviços Adicionais veículos/mês – corresponderá ao período de execução do item II.

14. LOCAL DE EXECUÇÃO DOS SERVIÇOS

Os serviços serão executados em todo o território que abrange os 23 municípios, da macrorregião, conforme quadro 2, deste Projeto, com ênfase, na única, Central de Regulação localizada no município de Belo Horizonte.

15. PROPRIEDADE E CONFIDENCIALIDADE – SIGILO DA INFORMAÇÃO

A CONTRATADA fica responsável pela manutenção, sigilo e segurança dos dados a que tiver acesso. A CONTRATADA e seus prepostos respondem civil e criminalmente pela adulteração, divulgação ou má utilização de dados e informações da CONTRATANTE.

A CONTRATADA e seus empregados deverão manter sigilo quanto às informações contidas em documentos, papéis e arquivos gravados mediante meio magnético, e em qualquer material manipulado para realização dos serviços, dedicando especial atenção à sua guarda, assumindo total responsabilidade sobre o sigilo.

A CONTRATADA deverá zelar pela guarda e conservação dos documentos que forem colocados à sua disposição pela CONTRATANTE, devolvendo-os nas mesmas condições em que lhe foram entregues para a prestação de seus serviços.

A CONTRATADA obriga-se a tratar como "segredos comerciais e confidenciais", todo o Processo de Software da CONTRATANTE e quaisquer informações, dados, processos, fórmula, códigos, fluxogramas, diagramas lógicos, dispositivos e modelos relativos aos serviços ora contratados, utilizando-os apenas para as finalidades previstas neste ajuste, não podendo revelá-los ou facilitar a sua revelação a terceiros.

16. GARANTIA DOS SERVIÇOS E PRODUTOS

A garantia dos serviços e produtos se baseia na obrigação da CONTRATADA de entregar os produtos

livres de defeitos e adequados de acordo com as legislações vigentes, obrigando-se a substituir/corrigir/reparar, de imediato, se algum defeito for constatado, em tempo de contrato.

A garantia para os serviços prestados e produtos entregues será obrigatória durante toda a vigência do contrato/em tempo do projeto e após seu término por mais 90 dias.

A garantia cobre todos os eventuais erros ou falhas e, ainda, porventura adequações legais, identificados e migração do sistema (atualização) para a versão/release mais atualizada do (s) software (s) utilizado

(s) tanto no ambiente de homologação, treinamento e produção, sem ônus para a CONTRATANTE.

Os vícios identificados após a entrega de determinado serviço/produto ou após o Aceite, deverão ser sanados pela CONTRATADA, sem ônus para a CONTRATANTE.

Durante o período da garantia, o serviço de suporte e manutenção se manterá nas condições realizadas durante a vigência do contrato, mas voltados para captar solicitação de reparo.

A demanda para o reparo, também compreendida como manutenção corretiva, será realizada de acordo com a definição de prioridade, ajustada previamente entre a CONTRATANTE e CONTRATADA e em conformidade com o nível de serviço acordado (SLA) conforme ANEXO VI.

Métrica e Critério de Medição:

a) Para o item I – manutenção da solução em produção (suporte técnico ao usuário, manutenção das licenças, serviço de hospedagem), os serviços se basearão em mensalidade pré-fixada, na qual incidirá a cobrança de multa resultante da aplicação de penalidade do SLA, se for o caso.

b) Para o item II do objeto, os serviços realizados e os produtos entregues serão avaliados pelas equipes técnicas da CONTRATANTE, valorados conforme desembolso pré-estabelecido e aplicados os níveis de serviços acordados (SLA) descritos no ANEXO VI, se for o caso.

c) O item III, serviços adicionais ofertados por meio de pontos de função, serão remunerados conforme valores estipulados na Ordem de Serviço e aplicação do SLA, se for o caso.

17. CONDIÇÕES DE RECEBIMENTO/ACEITE

Critérios de Aceitação do Produto / Serviço Entregue

Os produtos e serviços objetos desta licitação serão recebidos e aceitos:

Item I – Contratação de serviço de fornecimento e manutenção de licenças de uso de software, serviço de suporte técnico ao usuário e serviço de hospedagem

Para cobrir o escopo descrito no Quadro 3 - Projeto Básico: Escopo e Volumetria do Projeto, contemplando: serviço de suporte técnico ao usuário e manutenção das licenças, serviço de hospedagem.

A prestação dos serviços compreendidos no item I é de natureza contínua e ininterrupta, iniciados automaticamente a partir da data de emissão do Aceite Definitivo do item II do objeto contratado, salvo exceções descritas na Especificação dos Serviços do Item I.

O faturamento será mensal e a CONTRATADA deverá apresentar à CONTRATANTE a Nota Fiscal/Fatura, até o 5.º (quinto) dia útil do mês subsequente à prestação de serviço, em conformidade com a aferição do Indicador de Suporte Técnico (ISUT) sobre os chamados registrados, Indicador de Disponibilidade da Hospedagem da Solução (IDHS) e do Indicador de Cumprimento de Prazo dos Marcos (ICPM) para os casos de manutenção adaptativa e para a atualização.

O chamado de atendimento para suporte e manutenção será aberto em ferramenta de gestão de

demandas, conforme especificado no Anexo VI (Níveis de Serviços Acordados - SLA) e sua tramitação será monitorada pela CONTRATADA e pela CONTRATANTE.

A referida ferramenta será utilizada para a medição da produção e aplicação da métrica indicada nos SLAs, obtendo assim o valor do faturamento mensal.

Para aceitação do atendimento serão feitos testes de aceitação a serem executados por equipe definida pela CONTRATANTE e acompanhados pelos profissionais da CONTRATADA. Os testes de aceitação são aqueles em que o usuário final experimenta, pela última vez, a solução antes da mesma entrar em produção.

As definições complementares sobre o do ciclo de vida do chamado de atendimento, situações, regras de atualização da situação, gerenciamento e suas implicações na aferição ISTU, assim como fluxos e responsáveis nos processos de medição e faturamento, devem ser detalhadas posteriormente e acordadas no âmbito da área técnica e o Secretário Executivo .

Item II – Implantação

Para aceitação dos produtos entregáveis serão feitos testes de aceitação a serem executados por equipe definida pela CONTRATANTE e acompanhamento de profissionais da CONTRATADA. Para cada produto entregue será emitido Termo de Aceite e ao final da conclusão do Item II será emitido o Termo de Aceite Definitivo.

A CONTRATANTE emitirá o termo de aceite, no prazo de até 10 (dez) dias úteis após a entrega de cada produto do Item II com desembolso previsto no Quadro 4 – Projeto Básico: Cronograma e Previsão de Desembolso do Item II.

Cabe ressaltar que o aceite não atribui condição de encerramento/conclusão ao item entregue. Observa- se que são esperadas alterações evolutivas em itens entregues e aceitos parcialmente, decorrentes da implementação/implantação incremental de requisitos do sistema e da solução com muitas funcionalidades inter-relacionadas, com alta complexidade e sem condição de antecipar, de forma absoluta, todas as repercussões possíveis do processo incremental de implantação. Sendo assim, ao se identificar a necessidade de realizar adequação, ajuste ou evolução em um item entregue e aceito na condição de parcial, ela deverá ser tratada pela contratada e não poderá ser pleiteada como retrabalho ou novo escopo. Tratam-se de adequações necessárias decorrentes e esperadas do processo incremental de implementação e implantação e devem ser absorvidas pela contratada sem gerar adimplemento extra para a contratante.

A CONTRATANTE poderá rejeitar, no todo ou em parte, o serviço prestado em desacordo com este Projeto Básico e seus Anexos. Em caso de rejeição parcial, será emitido o Termo de Aceite Parcial mediante entrega de plano e cronograma de conclusão do produto a ser elaborado pela CONTRATADA.

Na conclusão do Item II do objeto, com todos os produtos entregues, será emitido o Termo de Aceite Definitivo da Implantação (produto Solução Plenamente Implantada), com desembolso previsto no Quadro 4 – Projeto Básico: Cronograma e Previsão de Desembolso do Item II, nas seguintes condições:

● Solução Plenamente Implantada é a colocação em operação da solução com todos os seus componentes, compreendendo as atividades de treinamento dos usuários na operação e utilização do sistema, ambientes de homologação, treinamento e produção, configurações, integrações, mapeamento, customizações, parametrizações, importações de dados, testes de funcionamento, acompanhamento e avaliação do desempenho do sistema até sua total consolidação.

Para a conclusão do Item II, ou seja, para o produto Solução Plenamente Implantada, não será emitido Termo de Aceite Definitivo parcial ou com registro de ressalva.

A CONTRATADA para prestar os serviços e fornecer o objeto desta licitação deverá substituir ou refazer, às suas expensas e sem ônus para a CONTRATANTE, no prazo estabelecido pelos Níveis de Serviços Acordados (SLAs) – Anexo VI, contadas da comunicação escrita do CONTRATANTE, os produtos que porventura apresentarem defeito ou incorreção em sua forma de apresentação ou os serviços prestados em desacordo com este Termo de Referência e seus Anexos.

Ainda que recebidos em caráter definitivo, subsistirá, na forma da lei, a responsabilidade da CONTRATADA pela solidez, qualidade e segurança dos produtos fornecidos e serviços por ela prestados à CONTRATANTE, conforme item da Garantia dos Produtos e dos Serviços.

Documentação Exigida:

A CONTRATADA deverá produzir e entregar, nos prazos estipulados, os documentos e manuais definidos, em meio eletrônico, em português, respeitando as seguintes orientações:

● Documentação do mapeamento dos processos – conforme detalhamento do item II deste Projeto Básico.

● Documentação das customizações e integrações realizadas, em português.

● Documentação de Suporte Técnico: orientações para gestão dos chamados.

● Ajuda on-line em português.

● Demais documentos necessários para o gerenciamento do projeto e para apoiar os usuários técnicos, parametrizadores/administradores multiplicadores e usuário final.

● Disponibilizar toda a documentação do Projeto em mídia digital e em conformidade com os Requisitos Não Funcionais, Anexo II do Projeto Básico.

Item III - Serviços Adicionais – Pontos de Função

Os serviços adicionais serão executados mediante emissão de Ordem de Serviço autorizada pela Autoridade Competente, gestor e fiscal de contrato pela CONTRATANTE e pelo preposto da CONTRATADA.

A OS deve descrever o escopo do serviço a ser prestado, produto a ser entregue, a quantidade de horas e o prazo destinados à sua consecução, bem como a nomeação dos responsáveis pela emissão do Aceite/Recebimento provisório, quando seu escopo não estiver contido nos subprojetos/módulos.

Para a emissão da Ordem de Serviço é obrigatória a aprovação pela área técnica e o Secretário Executivo, elaborada pela CONTRATADA, descrevendo o planejamento para atender a demanda e contendo, obrigatoriamente, as seguintes informações:

● Xxxxxx detalhado

● Cronograma

● Produtos e artefatos que serão entregues

● Equipe técnica responsável

É permitido o particionamento das entregas, com prazos e valores correspondentes.

Incidirá sobre a OS, os SLAs aferidos por meio do Indicador de Cumprimento de Prazo dos Marcos (ICPM) e do Indicador de Defeitos no Software (IDS) descritos no Anexo VI.

Itens IV e V - Serviços adicionais por incremento de veículos do SAMU

Os serviços adicionais serão executados mediante emissão de Ordem de Serviço autorizada pelo gestor e fiscal de contrato pela CONTRATANTE e pelo preposto da CONTRATADA.

A OS deve descrever o escopo do serviço a ser prestado, produto a ser entregue, a quantidade de unidades veículos mês, prazo máximo a ser executado, endereço de localização do veículo, pessoa de referência para contato, bem como a nomeação dos responsáveis pela emissão do Aceite/Recebimento provisório, quando seu escopo não estiver contido neste Edital.

Para veículos de BH, a CONTRATADA terá o prazo máximo de 1 dia útil, a partir do recebimento da ordem de serviço, para estar em condição de instalar os equipamentos/software e 3 horas, após a liberação do veículo pela CONTRATANTE, para fazer a instalação e ajustes no sistema deixando-os em pleno funcionamento.

Para veículos dos municípios do interior regulados pela Central de Regulação em Belo Horizonte, a CONTRATADA terá o prazo máximo de 3 dias úteis, a partir do recebimento da ordem de serviço, para estar em condição de instalar os equipamentos/software e 3 horas, após a liberação do veículo pela CONTRATANTE, para fazer a instalação e ajustes no sistema deixando-os em pleno funcionamento.

A CONTRATANTE poderá demandar até 10 unidades de veículo mês para serem atendidos simultaneamente.

Incidirá sobre a OS os SLAs descritos no Anexo VI.

O faturamento será mensal e a CONTRATADA deverá apresentar ao CONTRATANTE a nota fiscal/ fatura até o 5º dia útil do mês subsequente à prestação de serviço, em conformidade com a aferição do indicador de cumprimento de prazo dos marcos sobre a OS emitida.

ANEXO I

Formulário 1 - Apresentação da Situação dos

Requisitos Funcionais

O escopo da solução é composto pela Descrição Geral da Solução Tecnológica (item 3.1 do Projeto Básico), dos requisitos funcionais constantes neste Anexo e dos requisitos não funcionais - Anexo II.

Legenda: (N) Nativo - (P) Parametrizável - (C) Customizável

ID	Grupo Funcional	Requisito	N	P	C
RFS001	Alertas	O sistema deve permitir que a equipe de atendimento acione alerta sonoro e/ou visual a serem disparados na central, quando houver necessidade de apoio.
RFS002	Alertas	O sistema deve permitir a equipe de atendimento disparar alerta sonoro ou visual quando a ocorrência envolver múltiplas vítimas (>=5 vítimas).
RFS003	Alertas	O sistema deve emitir alerta visual para o teledigifonista quando uma ligação for originária de um DDD não cadastrado ou fora da área de cobertura.
RFS004	Alertas	O sistema deve permitir gerar alerta visual, a ser disparado no módulo do controlador de frota e no painel de monitoramento da frota, quando situações de atenção específicas forem cadastradas pela equipe de atendimento no módulo de atendimento móvel.
RFS005	Alertas	O sistema deve permitir que a central dispare alertas ou envie mensagens simultaneamente para algumas ou todas as equipes de atendimento. Por exemplo: envio de mensagem comunicando aos usuários quando um novo documento de treinamento ou protocolo for cadastrado para consulta, entre outros.
RFS006	Alertas	O sistema deve permitir a visualização de alertas disparados pela equipe de atendimento.
RFS007	Alertas	O sistema deve emitir um alerta visual para o teledigifonista se o endereço informado estiver na área do SAMU-Regional (municípios do interior regulados pela Central de Regulação em Belo Horizonte).
RFS008	Alertas	Integrar com o dispositivo móvel, de forma a permitir a emissão de um som intermitente, em volume alto, indicando que uma ocorrência foi recebida, até que a equipe de atendimento confirme a visualização e ciência da ocorrência.
RFS009	Alertas	O sistema deve gerar alerta visual para o controlador de frota quando for detectado que após um veículo ser empenhado encontra-se parado na base ou no trajeto de deslocamento para o atendimento por determinado tempo (parametrizável).
RFS010	Alertas	O sistema deve gerar alerta visual para o controlador de frota quando for detectado que um veículo está em movimento sem que tenha sido atribuído registro de saída para ocorrência.
RFS011	Alertas	O sistema deve permitir que o regulador primário envie alerta visual de classificação de risco para o regulador secundário.

RFS012	Alertas	O sistema deve permitir que o teledigifonista dispare alerta visual para o regulador primário quando houver necessidade de priorização de atendimento.
RFS013	Alertas	O sistema deve permitir a integração com os dados de estoque, com a finalidade de gerar alerta visual quando atingir o estoque mínimo previamente cadastrado.
RFS014	Atendimento Móvel	O sistema deve permitir inserir os campos do cadastro da ocorrência (solicitação de atendimento), campos da regulação e atendimento móvel de acordo com as regras de preenchimento e consistência das fichas padronizadas de atendimento, podendo indicar campos que são obrigatórios, o preenchimento, para prosseguimento.
RFS015	Atendimento móvel	O sistema deve permitir que a equipe de atendimento confirme o recebimento da ocorrência e registrar de forma automática os tempos (fases) de atendimento tais como: deslocamento para o local da ocorrência (saída inicial), chegada no local (com a confirmação que o atendimento está andamento) e deslocamento para unidade destino (saída do local da ocorrência) com o respectivo horário de cada fase.
RFS016	Atendimento móvel	O sistema deve gerar a classificação de risco, de forma automática, a partir das informações inseridas pela equipe de atendimento, conforme regras e protocolos, a serem estabelecidos pela CONTRATANTE.
RFS017	Atendimento Móvel	O sistema deve enviar para o dispositivo móvel, embarcado nas ambulâncias, as ocorrências que cada equipe deverá atender, assim que a central associar um veículo a uma ocorrência.
RFS018	Atendimento Móvel	O sistema deve enviar para o dispositivo móvel, embarcado na ambulância, as ocorrências que a equipe de atendimento deverá atender, assim que a central associar um veículo a uma ocorrência. O sistema deve exibir os dados da ocorrência no dispositivo móvel para a equipe de atendimento móvel, contendo minimamente: • Número da ocorrência • Endereço da ocorrência • Data e hora da ocorrência • Número de vítimas envolvidas • Nome, sexo e idade do paciente/solicitante • Tipo de solicitação • Tipo de demanda
RFS019	Atendimento Móvel	O sistema deve permitir à equipe de atendimento registrar no sistema as informações do atendimento por meio do dispositivo móvel.
RFS020	Atendimento Móvel	O sistema deve permitir o cadastro de protocolos de orientação relacionados ao tipo de ocorrência tais como: trauma clínico, produtos tóxicos e permitir que a equipe de atendimento consulte esses materiais, inclusive, durante um atendimento.

RFS021	Atendimento Móvel	O sistema deve permitir a equipe de atendimento reportar, por meio de campos estruturados, as situações de atenção, tais como: ambulância com defeito, maca retida, área de risco, local de difícil acesso, paciente não está no local, paciente está internado, paciente nega o atendimento, ausência de acompanhantes, ausência de membros da equipe, acidente com veículo, agressão/violência, desastre ambiental, presença de polícia no local, número do boletim de ocorrência, troca de Equipe, almoço, abastecimento, viatura quebrada (permitir informar motivo de indisponibilidade e observação). O sistema deve registrar, de forma automática, quando aplicável, a data e hora do início e término da situação de atenção selecionada.
RFS022	Atendimento Móvel	O sistema deve permitir que a equipe de atendimento responda aos checklist cadastrados. As respostas devem permitir gerar relatórios parametrizáveis.
RFS023	Atendimento Móvel	O sistema deve permitir à equipe de atendimento registrar o consentimento ou a recusa de atendimento pelo paciente. O sistema deve permitir anexar (por foto) o registro do termo de consentimento ou de recusa de atendimento pelo paciente ou responsável com a assinatura do mesmo.
RFS024	Atendimento Móvel	O sistema deve permitir enviar e manter, em campos estruturados, os registros relativos ao atendimento realizado pela equipe de atendimento, contendo no mínimo: • Dados de identificação do paciente (nome, idade, sexo) • Dados vitais, frequência respiratória, frequência cardíaca, pressão arterial, temperatura (o sistema deve calcular e exibir automaticamente o Trauma Score aplicada a adultos ou crianças). • Abertura ocular, resposta verbal e resposta motora (o sistema deve calcular e exibir automaticamente o valor da escala de coma Glasgow aplicada a adultos ou crianças). • Oximetria de pulso. • Glicemia. • Registro completo das informações acerca da: conduta adotada, procedimentos e medicamentos administrados (incluindo todos os dados inerentes ao medicamento, tais como: lote, aplicação, validade etc.), bem como insumos consumidos no atendimento. • Registro de óbito durante o atendimento no local, durante o transporte pré-hospitalar ou durante o transporte inter- hospitalar. • Xxxxxx para informar o diagnóstico com opções pré- cadastradas. • Dados da cena • Campo de observações • Finalização com ou sem atendimento; caso a finalização seja sem atendimento, informar o motivo através de um campo com opções pré-cadastradas.

RFS025	Atendimento Móvel	O sistema deve permitir a transmissão multimídia (foto, áudio e vídeo) para a central, obtidas com o dispositivo móvel, embarcado na ambulância, durante o atendimento da equipe móvel, e associada à ocorrência em atendimento. O sistema deve manter os arquivos de multimídia, mesmo na ausência de comunicação via dados.
RFS026	Atendimento Móvel	O sistema deve permitir gerar um relatório contendo os dados do atendimento tais como: dados de identificação do usuário, da equipe, da unidade de atendimento, a ser impresso na impressora embarcada na ambulância e entregue à unidade de destino. Os campos e layout do relatório serão definidos pela CONTRATANTE.
RFS027	Atendimento Móvel	O sistema deve permitir à central registrar e manter os status de atendimento das equipes móveis dos municípios conveniados que forem comunicados por rádio.
RFS028	Atendimento Móvel	O sistema deve permitir que a central registre no sistema todas as informações e observações referentes ao atendimento (incluindo todos os campos acessíveis no dispositivo móvel) relatadas por rádio pelas equipes de atendimento dos municípios conveniados da região metropolitana que são regulados pela Central de Regulação em Belo Horizonte.
RFS029	Atendimento Móvel	O sistema deve permitir registrar que a ocorrência envolve mais de uma vítima e permitir registrar o atendimento de cada uma delas individualmente de forma que seja possível recuperar os dados tanto por ocorrência, quanto por vítimas.
RFS030	Atendimento Móvel	O sistema deve permitir autocompletar as informações em campos referentes a endereço.
RFS031	Atendimento Móvel	O sistema deve gerar a classificação de risco, a partir do atendimento do teledigifonista e/ou regulador primário, conforme regras e protocolos, a serem estabelecidas pela CONTRATANTE.
RFS032	Atendimento Móvel	O sistema deve contabilizar e exibir o tempo da ligação de cada teledigifonista (desde o início ao final do atendimento desse perfil).
RFS033	Atendimento Móvel	O sistema deve emitir alerta visual na tela do teledigifonista e em tela disponível para perfil de supervisão, quando o atendimento superar um tempo de ligação parametrizável.
RFS034	Atendimento móvel	O sistema deve inserir cores (de acordo com as padronizadas pela CONTRATANTE) diferenciando as classificações de risco selecionadas para cada vítima de forma automática.
RFS035	Atendimento Móvel	Quando o usuário do sistema fizer a baixa de uma medicação, o sistema deve exibir mensagem (pop-up) com o nome da medicação e seu respectivo lote solicitando a confirmação da baixa, integrado com o sistema de gestão de estoque
RFS036	Cadastro	O sistema deve permitir cadastrar os campos a serem exibidos no campo de desfecho da ocorrência, tais como: trote, solicitação de informação, entre outros definidos pela CONTRATANTE.

RFS037	Cadastro	O sistema deve permitir criar formulários (fichas com perguntas distribuídas ou não em sessões, cujas respostas podem apresentar diversos formatos tais como: múltipla escolha, caixa de seleção, data, resposta em texto). O sistema deve permitir disponibilizar os formulários para serem preenchidos pela equipe de atendimento no dispositivo móvel, embarcado, e para outros perfis com preenchimento no computador.
RFS038	Cadastro	O sistema deve permitir criar checklist (lista de itens previamente cadastrado com checkbox para cada item). O sistema deve permitir cadastrar e disponibilizar os checklist para a equipe de atendimento preencher no dispositivo móvel, embarcado, e para outros perfis com preenchimento no computador.
RFS039	Cadastro	O sistema deve permitir configurar (incluir opções de respostas) nos campos estruturados presentes na ficha de atendimento, por exemplo: um campo da ficha, cuja resposta deve ser selecionada em uma lista suspensa, nesse caso, o sistema deverá permitir acrescentar novas opções de resposta na lista.
RFS040	Cadastro	O sistema deve permitir que os checklist sejam exibidos de acordo com critérios determinados pelo administrador do sistema.
RFS041	Cadastro	O sistema deve permitir cadastrar fórmulas de cálculo de dosagem de medicamentos (posologia), escalas e scores.
RFS042	Cadastro	O sistema deve permitir cadastrar planos de manutenção preventiva para as ambulâncias, indicando o tempo ou quilometragem rodada em que um serviço deve ser executado ou uma peça pode ser substituída.
RFS043	Cadastro	O sistema deve permitir cadastrar todos equipamentos embarcados (como macas, respiradores) relacionados a cada ambulância.
RFS044	Comunicação	O sistema deve permitir criar campos estruturados parametrizáveis com listas de perguntas e respostas padrões disponíveis para agilizar a troca de mensagens entre as equipes e o regulador. Por exemplo: uma pergunta frequente poderá ser cadastrada nessa opção de perguntas e respostas frequentes; quando o profissional optar por usar esse recurso, selecionará uma pergunta pré- formatada; o sistema deve solicitar confirmação da opção selecionada, se confirmado, o sistema deve enviar a pergunta selecionada.
RFS045	Comunicação	O sistema deve permitir que a equipe de atendimento solicite orientação do regulador para conduta, por meio de campos estruturados, ou por mensagens de áudio transcrito para texto. O sistema deve exibir confirmação de entrega das mensagens.
RFS046	Comunicação	O sistema deve permitir à equipe de atendimento solicitar à central autorização de uso da sirene.

RFS047	Comunicação	O sistema deve ser capaz de comutar automaticamente e instantaneamente o canal de rede por dados (rede sem fio dos dispositivos móveis embarcados) para o sistema de comunicação via satélite, caso o canal de dados falhar, mantendo todas as funcionalidades do sistema de comunicação e localização em pleno funcionamento.
RFS048	Comunicação	O sistema deve permitir o envio de mensagens pela equipe de atendimento para a central com a confirmação de entrega das mensagens.
RFS049	Comunicação	O sistema deve permitir que a central habilite a comunicação entre as equipes de atendimento.
RFS050	Controle de Frota	O sistema deve permitir que o controlador de frota visualize os dados da ocorrência, o tipo de ambulância indicado pelo regulador/Sistema, e as ambulâncias mais próximas disponíveis para empenho.
RFS051	Controle de Frota	O sistema deve permitir a visualização, em tempo real, da situação dos veículos da frota com a localização, o status (disponível, em atendimento, em manutenção etc.), o status da ignição (ligada ou desligada), o status da conexão do dispositivo móvel, a velocidade do veículo e o status da sirene e do giroflex (ligado ou desligado).
RFS052	Controle de Frota	O sistema deve indicar o veículo a ser enviado baseado nos dados da ocorrência, tipo de ambulância e localização das ambulâncias.
RFS053	Controle de Frota	O sistema deve permitir que uma vítima em atendimento seja transferida de um veículo para outro, a partir de um comando da central, que pode ser: de um veículo do SAMU para outro veículo do SAMU ou; do SAMU para o TS e vice-versa (nesse caso, o sistema deve permitir registrar a solicitação de apoio do TS). O sistema deve permitir indicar que a vítima foi transferida, alterando a equipe de atendimento que dará continuidade ao transporte.
RFS054	Controle de Frota	O sistema deve permitir enviar mais de um veículo para a mesma ocorrência ou substituir o veículo enviado para uma determinada ocorrência, por exemplo: substituir uma USB pela USA.
RFS055	Controle de Frota	O sistema deve exibir para o controlador de frota as seguintes informações a respeito do atendimento de cada ocorrência: • Saída para atendimento; • Chegada ao Local do Atendimento; • Saída para Hospital; • Chegada ao Hospital; • Redirecionamento para outra unidade de destino; • Unidade Liberada; maca retida • Chegada à Base.
RFS056	Controle de Frota	O sistema deve permitir à central registrar e manter o despacho das ambulâncias dos municípios conveniados.
RFS057	Controle de Frota	O sistema deve permitir à central registrar e manter a situação, o status, a localização e as etapas do atendimento das ambulâncias conveniadas.

RFS058	Controle de Frota	O sistema deve permitir o gerenciamento dos veículos da frota, com o registro de informações acerca dos veículos, tais como: lotação, características especiais.
RFS059	Controle de Frota	O sistema deve permitir indicar quais veículos estão com o plano de manutenção preventiva vencido ou próximo ao vencimento.
RFS060	Controle de Frota	O sistema deve permitir registrar os serviços e peças utilizadas na manutenção dos veículos, com os respectivos custos.
RFS061	Controle de Frota	O sistema deve permitir registrar quando uma marca ficar retida em uma unidade de atendimento, contendo os campos: unidade de atendimento, profissional que realizou o registro e o motivo para a retenção e salvando automaticamente a data e horário deste registro.
RFS062	Controle de Frota	O sistema deve permitir que seja atribuída mais de uma ocorrência para a mesma ambulância, mesmo que essa esteja com outro atendimento em curso.
RFS063	Controle de Frota	O sistema deve permitir visualizar em tela e em relatórios o tempo total de empenho por ambulância, com opções de filtrar por período (horas/dias), por equipe, por tempos de atendimento (saída, chegada etc.).
RFS064	Controle de Pessoal	O sistema deve permitir aos profissionais das equipes de atendimento e da central (por exemplo: condutores, técnicos, enfermeiros e médicos, etc.) registrarem o início e o fim dos turnos de trabalho, bem como a composição da equipe por ambulância/setor.
RFS065	Controle de Pessoal	O sistema deve permitir exibir, em tela, a lista de teledigifonistas, com os tempos de atendimento da chamada atual (total de minutos/horas em uma mesma ligação) e a média de tempo gasto, por teledigifonista.
RFS066	Gabinete de Crise	O sistema deve permitir enviar mensagens para todas as pessoas e organizações cadastradas. Essa funcionalidade deve ser habilitada a um perfil específico.
RFS067	Gabinete de crise	O sistema deve permitir cadastrar o "gabinete de crise", com a inclusão dos contatos (telefone e e-mail) de pessoas e organizações.
RFS068	Gestão de equipamentos e frota	O sistema deve permitir o gerenciamento da localização de equipamentos (por exemplo: macas e respiradores) embarcados nas ambulâncias ou não, que foram retidos em uma unidade de atendimento.
RFS069	Gestão de equipamentos e frota	O sistema deve permitir cadastrar informações adicionais para identificação das ambulâncias (USA e USB), por exemplo: USB Eventos, USA 01.
RFS070	Gestão de estoque	O sistema deve permitir que o usuário do sistema registre e transmita em tempo real para a central de regulação as informações referentes aos medicamentos e materiais utilizados no atendimento da ocorrência, integrado com o sistema de gestão de estoque.
RFS071	Gestão de estoque	O sistema deve atualizar os relatórios e telas do sistema referentes aos estoques com informações dos atendimentos em tempo real, através de Integração com Sistema de Estoque.

RFS072	Gestão de estoque	O sistema deve permitir que o usuário preencha e envie para o módulo de gestão, requisições de reposição de materiais e medicamentos.
RFS073	Gestão de estoque	O sistema deve permitir a inserção, visualização e impressão da prescrição dos medicamentos utilizados em cada atendimento, com campos parametrizáveis para inserção de informação tais como: via de administração, unidade de medida, dose entre outros.
RFS074	Gestão de estoque	O sistema deve permitir inserir prescrições para os atendimentos por ocorrência tanto pelo médico da equipe de atendimento quanto pelo médico regulador da central de regulação.
RFS075	Gestão de estoque	O sistema deve permitir que os profissionais da central e da equipe de atendimento visualizem as prescrições feitas pelo médico regulador por atendimento, por ocorrência por usuário atendido.
RFS076	Gestão de estoque	O sistema deve permitir visualizar a lista de medicamentos utilizados na ocorrência que forem informados pela equipe através do módulo de atendimento móvel.
RFS077	Gestão de estoque	O sistema deve gerar relatório indicando os medicamentos e materiais, suas quantidades utilizadas em cada ocorrência, os materiais e medicamentos que ficarem retidos nos estabelecimentos de saúde entre outras informações de atendimento.
RFS078	Gestão de estoque	O sistema deve permitir registrar e exibir em tela os materiais utilizados, com as suas respectivas quantidades, que ficarem retidos nos estabelecimentos de saúde.
RFS079	Gestão de estoque	O sistema deve permitir inserir informações dos materiais utilizados pela equipe de atendimento através do módulo de atendimento móvel.
RFS080	Gestão de estoque	O sistema deve permitir gerar relatórios utilizando filtros diversos a partir de dados estruturados existentes no sistema.
RFS081	Gestão de estoque	O sistema deve permitir que o usuário do serviço faça solicitação de documentações que são fornecidas pelo SAMU
RFS082	Gestão de estoque	O sistema deve permitir gerar relatórios, com opções de gráficos, das medicações e materiais utilizados por ambulância, por tipo de medicamento (por exemplo: controlados), por ocorrência, por usuário, por data de vencimento, entre outros.
RFS083	Gestão de estoque	O sistema deve permitir parametrizar prescrições de medicamentos, exigindo o preenchimento de itens como: via de administração, unidade de medida, dose, por especialidades médicas (CBO) solicitantes.
RFS084	Gestão de estoque	O sistema deve permitir manter dados da movimentação de materiais e medicamentos, e os dados pertinentes a cada item relacionado à ocorrência e ao usuário atendido.
RFS085	Gestão de estoque	O sistema, integrado com sistema de gestão de estoque, deve permitir consultar o estoque de medicamentos e insumos por ambulância.

RFS086	Integração	O sistema deve permitir integração com o sistema Sol- Maker MANAGER da empresa Método, ou seu substituto para vincular o registro das chamadas telefônicas às ocorrências correspondentes, permitindo o acesso das gravações via sistema.
RFS087	Integração	O sistema deve permitir integração com o sistema Sol- Maker MANAGER da empresa Método, ou seu substituto para vincular as gravações de todas as comunicações feitas por rádio, associando cada comunicação gravada à ocorrência correspondente, permitindo o acesso das gravações via sistema.
RFS088	Integração	O sistema deve permitir exportar informações das ocorrências atendidas pela central do SAMU para o Sistema de Gestão de Ocorrências do COP-BH.
RFS089	Integração	O sistema deve permitir importar informações do Sistema de Gestão de Ocorrências do COP-BH para o sistema do SAMU.
RFS090	Integração	O sistema deve permitir importar informações do cadastro dos profissionais da SMSA a partir do SIGBASES, permitindo a complementação de outros dados referentes à função do profissional no SAMU. Bem como dos sistemas gerais de Cadastro do SUS.
RFS091	Integração	O sistema deve permitir realizar o cadastro de profissional com integração assíncrona com o SIGBASES inoperante.
RFS092	Integração	O sistema deve permitir importar dados cadastrais das ambulâncias a partir do SIGBASES, permitindo a complementação de outros dados referentes à gestão de frota do SAMU. Bem como dos sistemas gerais de Cadastro do SUS.
RFS093	Integração	O sistema deve permitir importar dados de procedimentos a partir do SIGBASES, permitindo a complementação de outros dos referentes aos procedimentos utilizados no SAMU. Bem como dos sistemas gerais de Cadastro do SUS.
RFS094	Integração	O sistema deve permitir integração com o SIGBASES, permitindo trazer dados do cadastro de usuários e sua edição no sistema local. Bem como dos sistemas gerais de Cadastro do SUS.
RFS095	Integração	O sistema deve gerar alerta visual diante de falhas nas integrações e deve permitir parametrizar o envio de relatórios para perfis específicos.
RFS86	Integração	O sistema deve permitir visualizar e manter perfil de acesso de profissional usuário do Sistema que esteja ativo no cadastro de profissionais das SMSA´s.
RFS97	Integração	O sistema deve permitir excluir automaticamente todas as permissões de acesso de usuário do Sistema que esteja inativo ou em exclusão lógica do cadastro de profissionais das SMSA`s.
RFS98	Integração	O Sistema deve integrar com os dispositivos móveis embarcados nas ambulâncias.

RFS99	Integração	O Sistema deve integrar com os Transceptores Satelitais embarcados na ambulância.
RFS100	Interface das unidades hospitalares - grade de leitos	O sistema deve permitir aos serviços de pronto- atendimento (UPA e Hospitais) manter (incluir, alterar, excluir) a composição da equipe de urgência/emergência (nº de profissionais por especialidade e seu status - disponível ou ausente) por meio de digitação ou integração (WebService). A situação das equipes atualizada ao longo do dia deve ser exibida para a central de regulação e a CINT (Central de regulação de leitos).
RFS101	Interface das unidades hospitalares - grade de leitos	O sistema deve permitir aos serviços de pronto- atendimento (UPA e Hospitais) manter (incluir, alterar, excluir) o quadro de leitos de urgência/emergência e o seu status (ocupado ou vago) por meio de digitação ou integração (WebService). A situação dos leitos deve ser atualizada ao longo do dia e devem ser exibidas para a central de regulação e a CINT (Central de regulação de leitos).
RFS102	Interface das unidades hospitalares - grade de leitos	O sistema deve permitir aos serviços de pronto- atendimento (UPA e Hospitais) manter informação sobre situações adversas que possam impactar na capacidade de atendimento (RX inoperante, sem vaga de CTI, sem vaga em sala de observação, etc.). O sistema deve exibir as informações para a central de regulação e a CINT (Central de regulação de leitos).
RFS103	Interface das unidades hospitalares - grade de leitos	O sistema deve permitir à central gerenciar os dados de vagas nas unidades de UPA e Hospitais, a partir do registro na Interface das unidades hospitalares feito pelas unidades com informações das vagas de leitos, exibindo novo status de vagas sempre que uma vaga for ocupada e/ou sempre que o leito estiver disponível e pronto para receber o usuário do serviço.
RFS104	Interface das unidades hospitalares - grade de leitos	O sistema deve permitir a exibição da situação atual das vagas de pronto-atendimento e as especialidades dos médicos plantonistas no pronto-atendimento registradas pelas unidades hospitalares na Interface das unidades hospitalares.
RFS105	Interface das unidades hospitalares - grade de leitos	O sistema deve permitir o registro na Interface das unidades hospitalares das adversidades hospitalares, tais como: registro de impedimentos ou dificuldades para o atendimento ao paciente a ser encaminhado para o hospital.
RFS106	Interface das unidades hospitalares - grade de leitos	O sistema deve permitir a Central registrar as informações referentes às equipes e leitos dos serviços de urgência/emergência (UPA e hospitais) por meio de digitação ou integração (webservice), em caso de contingência, quando as unidades apresentarem impossibilidade de atualização dos dados.
RFS107	Interface das unidades hospitalares - grade de leitos	O sistema deve permitir que a Central de regulação envie o relatório de atendimento móvel para a unidade de atendimento, por meio eletrônico.

RFS108	Interface das unidades hospitalares - grade de leitos	O sistema deve permitir a exibição de todas as informações registradas na Interface das unidades hospitalares para a central e para perfis definidos pela CONTRATANTE.
RFS109	Interface usuário SUS	O sistema deve conter interface de interação do usuário de serviço, que permita o cadastro de informações pessoais, inclusive relacionadas à saúde, bem como salvar arquivos de multimídia relacionados a uma ocorrência direcionada ao SAMU (o sistema deve permitir configurar o tamanho dos arquivos a serem enviados pelo usuário) e realizar uma ligação para o número 192 para acionamento do serviço.
RFS110	Interface usuário SUS	O sistema deve permitir exibir as informações de localização e dados do solicitante que realizar ligação para o SAMU a partir da interface de interação do usuário do serviço. Essas informações devem ser exibidas em tela na central com opção de manter dados para cadastro da ocorrência.
RFS111	Interface usuário SUS	O sistema deve permitir exibir para o usuário de serviço informações (predefinidas pela CONTRATANTE) referentes a ocorrências geradas a partir de ligações realizadas por meio da interface de interação.
RFS112	Interface usuário SUS	O sistema deve permitir ao usuário de serviço realizar solicitação de documentos e/ou informações a partir da interface de interação, com opção para a central cadastrar e enviar o retorno da solicitação (podendo salvar e enviar documentos).
RFS113	Interface usuário SUS	O sistema deve permitir que o usuário informe a satisfação sobre o atendimento prestado através da interface de interação. O sistema deve permitir cadastrar os itens e parâmetros de avaliação da pesquisa de satisfação.
RFS114	Localização	O sistema deve manter o histórico de localização das ambulâncias e dos dispositivos móveis embarcados.
RFS115	Localização	O sistema deve identificar as coordenadas geográficas e exibir o local de atendimento em mapa acessível ao controlador de frota.
RFS116	Localização	O sistema deve indicar e exibir para a equipe de atendimento, o melhor trajeto, em um mapa de forma automática, o local de partida até o local da ocorrência e depois o local da ocorrência até a unidade de atendimento, com função de navegação, devendo calcular e informar o tempo previsto de chegada.
RFS117	Localização	O sistema deve gravar, automaticamente em sua base de dados, as coordenadas geográficas da ocorrência após a chegada no local, para georreferenciamento de local de atendimento e geração de relatórios.
RFS118	Localização	O sistema deve permitir georreferenciar e exibir em mapa os pontos de interesse tais como hospitais, bombeiros, bases do SAMU.
RFS119	Localização	O sistema deve permitir verificar a ambulância mais próxima do local da ocorrência, levando em consideração o status da ambulância (em atendimento, maca retida, etc.) e sinalizar para o controlador de frota.

RFS120	Localização	O sistema deve apresentar a localização das equipes/ambulâncias em um mapa, com atualizações em tempo real.
RFS121	Localização	O sistema deve exibir em um mapa a localização de cada ambulância, indicando se o veículo está disponível ou em atendimento. Se a ambulância estiver em atendimento, o sistema também deve exibir o trajeto previsto, o tempo previsto de chegada ao destino, e dados da ocorrência, tais como: número da ocorrência, número de vítimas, prioridade do atendimento.
RFS122	Localização	O sistema deve permitir a consulta ao histórico de deslocamento das ambulâncias com os seguintes filtros de pesquisa: por período, por localização/endereço, por veículo e ocorrência associada.
RFS123	Regulação	O sistema deve permitir à central registrar, na ocorrência, a necessidade e o contato de determinado apoio externo, tais como: bombeiros, defesa civil, outras ambulâncias.
RFS124	Regulação	O sistema deve permitir que o médico regulador primário continue o atendimento iniciado pelo teledigifonista, com possibilidade de visualizar e alterar os dados já preenchidos e ainda, registrar a descrição da demanda com as informações clínicas do paciente e o contexto da ocorrência, as orientações médicas entre outras informações do atendimento médico e a necessidade de envio de uma ambulância.
RFS125	Regulação	O sistema deve permitir que o regulador secundário registre os dados clínicos informados pela equipe móvel em caso de contingências. O sistema deve permitir incluir todas as informações referentes ao atendimento, tais como: Escala de Coma de Glasgow, histórico de saúde; pressão arterial; oximetria; frequência cardíaca; frequência respiratória; dentre outros.
RFS126	Regulação	O sistema deve permitir ao médico regulador secundário atribuir e alterar a gravidade de uma ocorrência a qualquer momento até o momento de final ização do atendimento. Os registros anteriores para esse campo devem ser mantidos no histórico.
RFS127	Regulação	O sistema deve permitir ao médico regulador definir o tipo de ambulância para o atendimento (USA ou USB do SAMU-BH ou USA ou USB do SAMU-Municípios conveniados).
RFS128	Regulação	O sistema deve permitir ao regulador primário indicar que uma ocorrência deva ser encaminhada para o TS informando o motivo em campo estruturado, o sistema deve permitir tramitar essa ocorrência para o regulador secundário concluir o atendimento com a transferência da demanda para o setor de Transporte em Saúde ou fazer a tramitação da ocorrência para o controlador de frota.
RFS129	Regulação	O sistema deve manter o histórico de preenchimento do campo de prioridade do chamado quando alterado por outro regulador.

RFS130	Regulação	O sistema deve permitir a configuração de um painel de gestão a vista para acompanhamento dos atendimentos em curso, bem como a situação atual com acesso para a Central de Regulação.
RFS131	Regulação	O sistema deve permitir que as ocorrências sejam visualizadas por todos os profissionais habilitados, e permitir que uma ocorrência seja triada por mais de um regulador (com a persistência de todos os registros de atendimentos) quando envolver múltiplas vítimas.
RFS132	Regulação	O sistema deve permitir classificar as solicitações em pré- hospitalar ou inter-hospitalar.
RFS133	Regulação	O sistema deve permitir agregar novas informações ao histórico de uma ocorrência, mesmo que essa já esteja finalizada, de maneira complementar e sem alterar dados registrados anteriormente, salvando a identificação do usuário do sistema, data e hora do registro.
RFS134	Regulação	O sistema deve permitir registrar e manter a regulação das ocorrências dos municípios conveniados do interior, regulados pela Central em Belo Horizonte.
RFS135	Regulação	O sistema deve permitir à central registrar e manter as informações de comandos e orientações transmitidos por rádio às equipes de atendimento dos municípios conveniados, tais como: definição do tipo de ambulância, orientações sobre conduta, definição de unidade de destino, entre outros.
RFS136	Regulação	O sistema deve permitir registrar a conduta médica definida pelo regulador para atendimento do paciente e a definição da unidade de atendimento que o paciente deverá ser transportado pela equipe de atendimento móvel. O registro da conduta e a unidade de atendimento definida devem ser exibidos no dispositivo móvel da equipe de atendimento móvel.
RFS137	Relatórios e indicadores	O sistema deve compor um registro histórico único de todas as informações e arquivos gerados para uma mesma ocorrência.
RFS138	Relatórios e indicadores	O sistema deve permitir parametrizar os campos do relatório de atendimento do usuário de serviço a ser entregue à unidade de destino.
RFS139	Relatórios e indicadores	O sistema deve permitir gerar relatórios gerenciais acerca dos atendimentos das equipes, com informações tais como: atendimento por motivo da ocorrência, por idade, sexo, tempo de atendimento (considerando cada status do atendimento desde a ligação para a central até o desembarque do paciente na unidade de atendimento), chamadas por município, por equipe, por unidade de destino e regional e bairro de origem.
RFS140	Relatórios e indicadores	O sistema deve permitir gerar relatórios com relação dos equipamentos embarcados.
RFS141	Relatórios e indicadores	O sistema deve permitir indicar a quantidade de vezes em que um número de telefone realizou chamada com desfecho de trote em ligação para o SAMU.

RFS142	Relatórios e indicadores	O sistema deve gerar relatórios detalhando os tempos de atendimento: Saída para Atendimento, Chegada ao Local, Saída para a Porta de Entrada, Chegada à Porta de Entrada, Chegada à Base.
RFS143	Relatórios e indicadores	O sistema deve permitir gerar relatórios com relação dos equipamentos retidos com minimamente os seguintes campos: data e horário, unidade de atendimento, profissional que realizou o registro, patrimônio, número de série e o motivo para a retenção.
RFS144	Relatórios e indicadores	O sistema deve permitir gerar relatórios gerenciais acerca dos atendimentos das equipes, com informações tais como: atendimento por motivo da ocorrência, por idade, sexo, tempo de atendimento, chamadas por município, por equipe.
RFS145	Relatórios e indicadores	O sistema deve permitir a extração de relatórios gerenciais em arquivos nos formatos para leitura pelo Excel e PDF.
RFS146	Relatórios e indicadores	O sistema deve permitir a configuração de um dashboard com informações dos atendimentos realizados pelo SAMU que seja acessível em painel de operações e outro formato definido pela gestão da CONTRATANTE.
RFS147	Relatórios e indicadores	O sistema deve permitir gerar relatório sobre as equipes de plantão, com informações sobre início/fim de turno e composição das equipes.
RFS148	Relatórios e indicadores	O sistema deve permitir gerar relatório sobre a situação/status dos veículos da frota, tais como: em atendimento, em manutenção, em refeição, maca retida.
RFS149	Relatórios e indicadores	O sistema deve gerar relatórios parametrizáveis por profissional, equipe e ambulância para atender as regras de envio da produção do SAMU para o níveis gerenciais dos municípios da macrocentro, e para a Secretaria Estadual de Saúde. Os relatórios deverão apresentar os campos necessários para atendimento a definições da CONTRATANTE e do Ministério da Saúde.
RFS150	Relatórios e indicadores	O sistema deve gerar relatórios com os registros de recusas de atendimento pelo paciente.
RFS151	Relatórios e indicadores	O sistema deve gerar relatórios de tempo médio de atendimento a partir do horário de cada status do atendimento registrado no sistema.
RFS152	Relatórios e indicadores	O sistema deve gerar relatório indicando o tempo de indisponibilidade de cada unidade/veículo, incluindo o motivo da indisponibilidade, data e hora de início e data e hora de fim.
RFS153	Relatórios e indicadores	O sistema deve permitir exibir mapas de calor (mapa de kernel), com indicação visual através de cores, dos motivos de atendimento e gravidade. Esses mapas devem possuir os seguintes filtros: data inicial e data final, prioridade dos atendimentos, veículo, motivo de atendimento, hora inicial e hora final e regional.
RFS154	Relatórios e indicadores	O sistema deve permitir gerar e exportar dados da base em um formato definido pela CONTRATANTE, sob demanda.

RFS155	Relatórios e indicadores	O sistema deve permitir gerar relatórios com o total e percentual de chamadas atendidas possibilitando filtrar por: número da ocorrência, data e hora da chamada e desfecho da ocorrência (se finalizada, transferida para o Transporte em Saúde etc.).
RFS156	Relatórios e indicadores	O sistema deve permitir gerar relatórios com o total e percentual de chamadas atendidas por número da solicitação/ocorrência, por data e hora da chamada, por diagnóstico, por município de origem da chamada, e por sexo e idade do paciente.
RFS157	Relatórios e indicadores	O sistema deve permitir gerar relatórios com o total e percentual de chamadas atendidas por número da ocorrência, por data e hora da chamada e nome do teledigifonista que realizou o atendimento.
RFS158	Relatórios e indicadores	O sistema deve permitir gerar relatórios com o total e percentual de chamadas atendidas por número da ocorrência, por data e hora da chamada e por sexo e idade do paciente.
RFS159	Relatórios e indicadores	O sistema deve permitir gerar relatórios com o total e percentual de chamadas atendidas por regulador (primário ou secundário), número da ocorrência, por data e hora da chamada, por diagnóstico, por classificação do regulador primário e classificação do regulador secundário, por tipo de veículo enviado e conduta adotada pelo regulador.
RFS160	Relatórios e indicadores	O sistema deve permitir gerar relatórios com o total e percentual de ambulâncias enviadas, por número da ocorrência, por data e hora, código e tipo da ambulância
RFS161	Relatórios e indicadores	O sistema deve permitir gerar relatórios com o status da ambulância, por exemplo: disponível, em atendimento, indicando a hora de início e final, bem como o tempo de permanência no status informado por código da ambulância e tipo.
RFS162	Relatórios e indicadores	O sistema deve permitir gerar relatórios com o total e percentual de ambulâncias enviadas, por número da ocorrência, por data e hora, por solicitante, por diagnóstico atribuído ao solicitante e a unidade de atendimento.
RFS163	Relatórios e indicadores	O sistema deve permitir gerar relatórios com a estatística de atendimentos indicando os horários de picos de atendimentos por hora; data e dia semana; dias e horários em que foi acionado a comunicação via satélite com o tempo de utilização e a localização do ponto de acionamento e o bairro.
RFS164	Relatórios e indicadores	O sistema deve permitir a extração de dados para tratamento em sistema de BI, entre outros.
RFS165	Relatórios e indicadores	O sistema deve permitir gerar relatórios dos processos de integrações, tais como: percentual de falhas, quantidades de integrações por processo, entre outros.
RFS166	Relatórios e indicadores	O sistema deve permitir buscar atendimentos de um mesmo usuário de serviço, podendo visualizar ou imprimir o histórico de atendimentos.

RFS167	Relatórios e indicadores	O sistema deve permitir gerar relatório da produção dos teledigifonista, por teledigifonista, data, número da ocorrência, tempo de atendimento, hora inicial e final, desfecho, com opções de filtros: por teledigifonista, por período (data e hora).
RFS168	Segurança	O sistema deve permitir cadastrar os dispositivos móveis, embarcados, com opção de atrelar o dispositivo móvel a uma determinada ambulância. O sistema deve permitir bloquear funções não relacionadas ao atendimento, de forma que os usuários não consigam alterar as configurações do equipamento.
RFS169	Segurança	O sistema deve possuir controle de acesso que permita configurar acesso às funcionalidades por perfis e usuários, possibilitando configurar diversos níveis de acesso e funções, incluindo a possibilidade de configurar acesso restrito para usuários externos às SMSA´s (p.ex., unidades de pronto atendimento, bombeiros, defesa civil, etc.).
RFS170	Segurança	O sistema deve permitir criar perfis e associá-lo a funcionalidades específicas.
RFS171	Segurança	O sistema deve permitir gerar relatórios das permissões liberadas para os usuários do sistema por perfil e/ou por nome do profissional.
RFS172	Segurança	O sistema deve permitir a alteração de senha pelo próprio usuário para acesso ao sistema.
RFS173	Segurança	O sistema deve permitir a auditoria de ações realizadas pelos usuários no sistema, registrando dados tais como o Tipo da Ação (Acesso, Cadastro, Atualização, Exclusão), Nome do Usuário, Endereço IP, Data e Hora, bem como a URL da funcionalidade acessada.
RFS174	Segurança	O sistema deve conter perfil para auditoria de ações realizadas pelos usuários no sistema, permitindo pesquisar as ações realizadas por Central, Grupo de Usuário, Nome, Tipo de Ação, Descrição, Endereço IP e Período.
RFS175	Segurança	O sistema deve permitir visualizar e manter o perfil de acesso e o cadastro de profissional de segurança do Sistema.
RFS176	Segurança	O sistema deve permitir visualizar e manter automaticamente logs do Sistema para fins de auditoria.
RFS177	Segurança	O sistema deve permitir visualizar e manter vinculação de perfil de acesso (segurança horizontal) à unidade organizativa de atuação do profissional de saúde (segurança vertical).
RFS178	Segurança	O sistema deve permitir visualizar e manter automaticamente identificação de responsável por alterações, inclusões ou exclusões de dados de campos do Sistema para fins de auditoria.
RFS179	Segurança	O sistema deve permitir manter automaticamente a identificação de responsável por consulta ou edição a dado sensível do Sistema.

RFS180	Segurança	O sistema deve permitir visualizar e manter perfis de acesso por meio da liberação de uso de recursos de segurança que podem ser: tela, aba, comando, link ou campo, conforme especificado pela CONTRATANTE.
RFS181	Segurança	Permitir utilizar assinatura digital certificada pelo ICP- Brasil, para os profissionais de saúde em vários pontos do contato assistencial tais como: solicitação de procedimentos, prescrição e registro do atendimento.
RFS182	Teledigifonista	O sistema deve ser capaz de recuperar as informações registradas em atendimentos anteriores para o mesmo número de telefone, permitindo, em casos de reincidência, que o profissional confirme os dados e modifique apenas o que for necessário.
RFS183	Teledigifonista	O sistema deve permitir diferenciar as ocorrências atendidas originadas em outros municípios conveniados nas telas do teledigifonista, do regulador primário e secundário, do controlador de frota e nos relatórios gerenciais.
RFS184	Teledigifonista	O sistema deve permitir cadastrar solicitações de atendimento móvel de urgência informando no mínimo: dados de localização, dados do solicitante, número de vítimas, dados de paciente(s), observações diversas e tipo da chamada (trote, ligação interna, ligação interrompida, engano, informações em saúde, entre outros).
RFS185	Teledigifonista	O sistema deve permitir a tramitação da ocorrência após o atendimento do teledigifonista para o médico regulador primário ou sua finalização indicando o motivo tais como: ligação interrompida, trote ou outro.
RFS186	Teledigifonista	O sistema deve permitir a recuperação automática do número de telefone do solicitante, possibilitando inserir outros números de contato.
RFS187	Avaliação	O sistema deve permitir a avaliação de métodos de revisão de casos, e de conformidade dos atendimentos com protocolo médico, para monitores de qualidade
RFS188	Avaliação	Gerar relatórios que reflitam qualquer período de tempo, com estatísticas semanais, mensais, e anuais que acusem tendências de erro de conformidade, e análises apropriadas para processos de melhoria de qualidade.
RFS189	Administração	O Sistema deverá permitir aos administradores da solução personalizar e modificar interfaces de usuários, e regras de negócio, para se adequar aos procedimentos operacionais do SAMU.
RFS190	Administração	O Sistema deverá permitir ao administrador atualizar parâmetros de segurança, mesmo com os operadores estando online.
RFS191	Administração	O sistema deverá permitir que todas as senhas da solução operacional sejam guardadas de forma encriptada.

RFS192

Administração

O Sistema deverá permitir ao administrador controlar a frequência mínima, que os usuários devem alterar suas senhas.

Quantitativo / Percentual da Situação dos requisitos Funcionais

Forma de Atendimento	N° Requisitos	Percentual
Nativo
Parametrizável
Subtotal
Customizável
Total
Não contabilizados para o cálculo do percentual
TOTAL GERAL

Belo Horizonte, de de 2023

Assinatura

Nome da Proponente

Nome do Representante

CNPJ

Favor carimbar e rubricar todas as páginas deste formulário

ANEXO II

Formulário 2 - Apresentação da Situação dos Requisitos Não Funcionais da Solução Tecnológica

ITEM

REQUISITO

RNF01

RNF01: Pelo menos 90% das funcionalidades do sistema devem ter um tempo de resposta não superior a seis (6) segundos sob condições normais de carga. Qualquer funcionalidade que exceda este tempo de resposta deve ser explicitamente aprovada pela CONTRATANTE.

RNF02

O sistema deve garantir uma integração completa e coesa entre todos os seus módulos, promovendo a reutilização eficiente das regras de negócio e das funções já implementadas. Essa integração deve ser orientada pelas seguintes diretrizes:

1. Conformidade com padrões de integração: A solução deve aderir a padrões de integração de sistemas amplamente aceitos, como REST, SOAP ou gRPC para as interfaces de programação de aplicativos (APIs). Isso permitirá uma integração mais suave e a interoperabilidade com outros sistemas.

2. Gestão de dados consistente: A integração deve garantir a consistência dos dados entre os módulos, de maneira que as alterações de dados em um módulo se reflitam corretamente em todos os outros módulos relevantes. Isso envolve a implementação de práticas sólidas de gestão de dados, como a transação ACID (Atomicidade, Consistência, Isolamento, Durabilidade) e a sincronização de dados em tempo real ou próximo do real.

3. Design de serviços reutilizáveis: As regras de negócio e funções devem ser projetadas como serviços reutilizáveis, sempre que possível, para promover a eficiência e a manutenção mais fácil. Isso deve ser feito seguindo práticas de design orientado a serviços ou de microsserviços.

4. Monitoramento e diagnóstico: Deve haver ferramentas e recursos de monitoramento e diagnóstico integrados para identificar e resolver problemas de integração, desempenho ou funcionalidade que possam surgir.

5. Segurança: A integração entre módulos deve ser projetada e implementada com considerações de segurança em primeiro plano, incluindo a autenticação e autorização adequadas, e o uso de canais de comunicação seguros, como HTTPS.

6. Não devem existir processos de importação e exportação de dados entre os módulos da aplicação que requeiram intervenções manuais.

RNF03

O sistema deve fornecer mensagens de erro padronizadas e coerentes para cada tipo de falha operacional. Essas mensagens devem ser claras, sucintas e proporcionar ao usuário uma compreensão adequada do problema ocorrido.

Além disso, as mensagens de erro devem seguir as diretrizes de acessibilidade do WCAG (Web Content Accessibility Guidelines) e do e-MAG (Modelo de Acessibilidade em Governo Eletrônico). Especificamente:

1. De acordo com a diretriz 3.3.1 do WCAG, se ocorrer um erro de entrada identificável automaticamente, o item que apresenta o erro deve ser identificado e o erro descrito aos usuários em texto (Nível A).

2. Seguindo a diretriz 3.3.3 do WCAG, se um erro de entrada for identificado automaticamente e sugestões de correção forem conhecidas, essas sugestões devem ser fornecidas ao usuário, a menos que seja prejudicial à finalidade da interface (Nível AA).

3. As mensagens de erro devem ser apresentadas de maneira a serem percebidas por todos os usuários, independentemente de suas habilidades sensoriais e cognitivas, de acordo com a diretriz 1.3.1 do WCAG, que trata de informações e relacionamentos (Nível A).

4. Finalmente, de acordo com a diretriz 4.1.3 do WCAG, as mensagens de erro devem ser apresentadas de forma que possam ser interpretadas por tecnologias assistivas (Nível AA).

RNF04

Todos os campos de preenchimento obrigatório em todas as interfaces do usuário devem ser claramente marcados e facilmente identificáveis, seguindo as diretrizes de acessibilidade do WCAG e do e-MAG. Especificamente:

1. Conforme a diretriz 3.3.2 do WCAG (Labels or Instructions - Rótulos ou Instruções), os rótulos ou instruções devem ser fornecidos quando o conteúdo requer entrada do usuário (Nível A). Assim, todos os campos obrigatórios devem ter rótulos claros indicando sua necessidade.

2. Seguindo a diretriz 2.4.6 do WCAG (Headings and Labels - Cabeçalhos e Rótulos), os rótulos ou instruções devem ser descritivos para ajudar o usuário a entender o que é necessário para o preenchimento correto (Nível AA).

3. De acordo com a diretriz 1.3.1 do WCAG (Info and Relationships - Informação e Relacionamentos), a informação, a estrutura e as relações apresentadas visualmente devem estar disponíveis para o usuário em formas que ele possa perceber. Isso implica que o design visual dos campos obrigatórios deve ser distinto para indicar sua importância (Nível A).

4. Finalmente, de acordo com a diretriz 4.1.2 do WCAG (Name, Role, Value - Nome, Função, Valor), o nome e o papel de todos os campos de interface, bem como o estado, as propriedades e os valores, devem ser acessíveis a tecnologias assistivas, incluindo os estados de preenchimento obrigatório (Nível A).

RNF05

O sistema deve notificar o usuário por meio de uma mensagem informativa ou indicação gráfica visível sempre que uma transação estiver demorando mais do que o tempo esperado, seguindo as diretrizes de acessibilidade do WCAG e do e-MAG. Especificamente:

1. Conforme a diretriz 2.2.1 do WCAG (Timing Adjustable - Ajuste de Tempo), o usuário deve ser informado sobre o tempo de espera ou qualquer atraso que possa ocorrer durante as transações (Nível A).

2. De acordo com a diretriz 4.1.2 do WCAG (Name, Role, Value - Nome, Função, Valor), o estado e as propriedades das transações devem ser acessíveis a tecnologias assistivas, incluindo o estado de espera (Nível A).

3. Seguindo a diretriz 1.4.1 do WCAG (Use of Color - Uso de Cor), a cor não deve ser usada como o único meio visual de transmissão de informações, indicando uma ação, pedindo uma resposta ou distinguindo um elemento visual. Se as cores forem usadas para indicar atrasos nas transações, elas devem ser complementadas com outros indicadores visuais ou mensagens de texto (Nível A).

RNF06

O sistema deve ser compatível e funcionar corretamente com as versões mais recentes dos navegadores web Firefox, Chrome e Edge, garantindo a acessibilidade do conteúdo em todos eles de acordo com as diretrizes do WCAG e do e-MAG. Especificamente:

1. Segundo a diretriz 4.1.1 do WCAG (Parsing - Análise), o código que está sendo usado deve ser válido e sem erros que possam ser interpretados incorretamente pelos navegadores e tecnologias assistivas (Nível A).

2. De acordo com a diretriz 2.4.5 do WCAG (Multiple Ways - Várias Maneiras), há várias maneiras de localizar uma página da web dentro de um conjunto de páginas da web, exceto onde a página seja o resultado ou um passo de um processo. Portanto, os usuários devem poder navegar facilmente pelo sistema, independentemente do navegador que estão usando (Nível AA).

3. Segundo a diretriz 1.4.4 do WCAG (Resize text - Redimensionar texto), o texto deve ser redimensionável até 200% sem a necessidade de um assistente tecnológico, garantindo que os usuários possam ajustar o texto de acordo com suas necessidades em todos os navegadores (Nível AA).

4. Conforme a diretriz 2.1.1 do WCAG (Keyboard - Teclado), todas as funcionalidades devem estar disponíveis via teclado, o que inclui a compatibilidade com atalhos de teclado padrão do navegador (Nível A).

RNF07

A solução contratada deverá cumprir integralmente com os requisitos estabelecidos para o Nível de Garantia de Segurança 2 (NGS2) especificamente para a categoria Assistencial, conforme delineado no Manual de Certificação para Sistemas de Registro Eletrônico em Saúde V. 4.2. Além disso, a solução deve implementar as seguintes considerações de segurança:

1. O cumprimento do NGS2 deve ser verificável por meio de auditorias de segurança independentes, conforme indicado no Manual de Certificação para Sistemas de Registro Eletrônico em Saúde.

2. Onde os requisitos do NGS2 não forem aplicáveis, a solução deve, no mínimo, aderir aos padrões de segurança geralmente aceitos para sistemas de registro eletrônico em saúde. As decisões sobre quais requisitos do NGS2 são aplicáveis devem ser documentadas e aprovadas por uma autoridade competente.

3. A solução deve ser projetada de maneira a permitir atualizações futuras de segurança conforme necessário para manter a conformidade com o NGS2 ou versões subsequentes do Manual de Certificação para Sistemas de Registro Eletrônico em Saúde.

4. A solução deve fornecer uma documentação detalhada de como ela atende aos requisitos do NGS2, para facilitar a auditoria de segurança e fornecer transparência para os stakeholders.

RNF08

Possuir um mecanismo de autenticação de acesso ao sistema integrado ao serviço diretório Active Directory e Acesso PBH (AD e Xxx.xx);

RNF09

O sistema deverá permitir o uso de Certificados Digitais ICP- Brasil, gerados por qualquer Autoridade Certificadora – AC homologadas pela ICP- Brasil.

RNF10

O sistema deve atender a LEI Nº 14.063, DE 23 DE SETEMBRO DE 2020 que dispõe sobre o uso de assinaturas eletrônicas.

RNF11

A aplicação deve suportar autenticação unificada (Single Sign-On - SSO), garantindo a segurança e a integridade dos dados do usuário, de acordo com as melhores práticas de segurança. Especificamente:

1. O SSO deve ser implementado em conformidade com os padrões de segurança de identidade, como SAML (Security Assertion Markup Language), OpenID Connect ou OAuth 2.0, para garantir a interoperabilidade e a segurança.

2. O SSO deve ser configurado para fornecer um mínimo de privilégios de acesso. Ou seja, os usuários devem receber apenas os privilégios necessários para realizar suas tarefas.

3. Deve haver uma política de expiração de sessão implementada para minimizar a possibilidade de ataques se uma sessão de usuário for deixada aberta. Quando a sessão de um usuário expirar ou se tornar inativa, ele deve ser solicitado a se autenticar novamente.

4. O processo de autenticação unificada deve ser auditável, com a possibilidade de rastrear tentativas de autenticação bem-sucedidas e mal-sucedidas, e registrar eventos de segurança relevantes.

5. O SSO deve suportar e implementar mecanismos adicionais de segurança, como autenticação multifatorial (MFA), quando apropriado ou exigido, para fornecer camadas adicionais de segurança.

RNF12

Todos os dados numéricos, alfanuméricos, texto, monetários e datas devem ser formatados segundo o padrão brasileiro, seguindo as diretrizes de acessibilidade do WCAG e do e- MAG. Especificamente:

1. Conforme a diretriz 3.1.1 do WCAG (Language of Page - Idioma da Página), o idioma principal de cada página da web deve ser determinável programaticamente (Nível A).

2. Seguindo a diretriz 3.1.2 do WCAG (Language of Parts - Idioma das Partes), o idioma de cada frase ou palavra em uma passagem ou frase no conteúdo pode ser determinado programaticamente, exceto para nomes próprios, termos técnicos, palavras de origem indeterminada e palavras ou frases que se tornaram parte do vernáculo do idioma imediatamente envolvente (Nível AA).

RNF13

O sistema deve fornecer uma funcionalidade de "Ajuda" acessível e compreensível para todas as funções, seguindo as diretrizes de acessibilidade do WCAG e do e-MAG. Especificamente:

1. De acordo com a diretriz 3.3.5 do WCAG (Help - Ajuda), deve ser fornecida ajuda contextual ou informações sobre o formato de entrada esperado para os dados de entrada (Nível AAA).

2. Seguindo a diretriz 3.2.3 do WCAG (Consistent Navigation - Navegação Consistente), as funções de navegação que são repetidas em várias páginas da web em um conjunto de páginas da web ocorrem na mesma ordem relativa cada vez que são repetidas, a menos que uma alteração seja iniciada pelo usuário (Nível AA). Isso implica que a opção "Ajuda" deve ser facilmente localizável e consistentemente colocada em todas as páginas.

3. De acordo com a diretriz 2.4.6 do WCAG (Headings and Labels - Cabeçalhos e Rótulos), os cabeçalhos e rótulos devem ser claros e descritivos para ajudar o usuário a entender o conteúdo e navegar eficientemente (Nível AA). Isso é particularmente importante para a funcionalidade de "Ajuda", onde o objetivo é auxiliar o usuário a entender e usar as funções do sistema corretamente.

ANEXO III

ESPECIFICAÇÃO DE HOSPEDAGEM DA SOLUÇÃO

SERVIÇOS DE HOSPEDAGEM

A CONTRATADA deverá fornecer também a hospedagem do Sistema relacionado nesta especificação. Nenhum equipamento ou Software necessário para a CONTRATADA prestar os serviços contratados será objeto de repasse para o CONTRATANTE. Os microcomputadores e o acesso à Internet, a partir dos quais os usuários farão acesso ao Sistema, serão fornecidos pela CONTRATANTE.

A CONTRATADA deverá realizar a disponibilização do acesso ao Sistema, com performance e disponibilidade satisfatórias para desempenho das funções da CONTRATANTE, sem a necessidade de que o CONTRATANTE tenha que providenciar a aquisição/implantação de quaisquer Softwares complementares e/ou suas licenças, além dos próprios navegadores especificados.

Os usuários poderão acessar o Sistema a partir de qualquer ambiente que disponibilize acesso de Internet, e deverão contar com CRIPTOGRAFIA E SEGURANÇA na sessão web com https, utilizando protocolo de criptografia TLS no mínimo na versão 1.2, garantindo a segurança do usuário em qualquer ambiente web.

A CONTRATADA deverá disponibilizar a capacidade que for adequada e necessária para armazenamento exclusivo dos dados gerados pela CONTRATANTE. Os documentos, informações e dados armazenados no Sistema serão de propriedade da CONTRATANTE, porém sob a responsabilidade da CONTRATADA.

Além da hospedagem, a CONTRATADA deverá realizar o monitoramento remoto do ambiente, envolvendo banco de dados, servidores de aplicação e de balanceamento de carga de aplicação envolvidos diretamente na disponibilização do acesso ao Sistema, de modo a prevenir e evitar instabilidades do ambiente de produção do Sistema.

O gerenciamento do desempenho e a detecção de falhas poderão ser feitas de maneira passiva, ou seja, com o uso de Softwares e ferramentas específicas para isso.

Para a contratação de serviços, é requerida uma disponibilidade mínima anual de 99,982% para a solução oferecida. Isso significa que a solução não pode ter mais do que aproximadamente 1 hora, 45 minutos e 7 segundos de tempo de inatividade não planejado ao longo de um ano.

Além disso, qualquer ocorrência de indisponibilidade contínua do serviço de hospedagem não deve exceder 30 minutos contínuos. Se este limite for ultrapassado, será considerado uma violação do Acordo de Nível de Serviço (SLA).

Esses requisitos devem ser monitorados e auditados regularmente, e relatórios de disponibilidade devem ser fornecidos anualmente, ou conforme acordado no SLA. Este relatório deve incluir, no mínimo, o tempo total de indisponibilidade no ano, a descrição dos incidentes de indisponibilidade, a duração de cada incidente e as ações corretivas implementadas para resolver cada incidente e prevenir futuras ocorrências.

A disponibilidade dos serviços definidos no objeto desta contratação deverá estar de acordo com os níveis de serviços definidos neste documento, relativo ao indicador de disponibilidade;

A Contratada deverá hospedar a solução em Data Center localizado no território nacional, informando a região geográfica deste ambiente de prestação dos serviços. Caso tenha que alterar a região geográfica estabelecida, a Contratada deverá informar nova a região geográfica do ambiente de prestação dos serviços à Contratante, com antecedência mínima de 30 (trinta) dias.;

A Contratada deverá garantir escalabilidade do ambiente, de forma que o serviço seja prestado conforme os níveis de serviço e indicadores estabelecidos para esta contratação.

A Contratada deverá garantir que haja balanceamento de carga em seu ambiente, de forma que a solução seja acessada sem perda de desempenho.

A Contratada informará previamente sobre a interrupção dos serviços contratados, juntamente com a justificativa e o cronograma de restabelecimento dos serviços à CONTRATANTE. Nos casos de manutenção, atualização ou evolução, a antecedência mínima exigida será de 5 (cinco) dias;

Os dados e informações do contratante devem residir exclusivamente em território nacional, incluindo replicação e cópias de segurança (backups), de modo que o contratante disponha de todas as garantias da legislação brasileira enquanto tomador do serviço e responsável pela guarda das informações armazenadas em nuvem.

O ambiente do serviço contratado esteja em conformidade com a norma ABNT NBR IEC 27001:2013, sem prejuízo de outras exigências, objetivando mitigar riscos relativos à segurança da informação.

O serviço a ser contratado deve permitir a portabilidade de dados para outra estrutura física, diferente daquela que foi contratada, em prazo adequado e sem custo adicional, de modo a garantir a continuidade do negócio e possibilitar a transição contratual.

A CONTRATADA deverá especificar todo o conjunto de hardware e software de hospedagem para que a CONTRATANTE possa adquirir ou contratar hospedagem em outra empresa. A especificação deve ser detalhada conforme solicitação da CONTRATANTE, sem ônus para a CONTRATANTE.

A CONTRATADA deverá desenvolver o plano de migração de dados conforme solicitação da CONTRATANTE, em tempo de contrato, sem ônus para a CONTRATANTE, caso esta necessite transferir os dados do ambiente desta CONTRATADA para outro ambiente.

A CONTRATADA deverá realizar a execução da migração de dados, conforme solicitação da CONTRATANTE, sem ônus para a CONTRATANTE.

Após o encerramento do contrato, a CONTRATADA deverá manter, sem ônus para a CONTRATANTE, todos os recursos provisionados operacionais por um prazo de 90 (noventa) dias, de acordo com o item “GARANTIA DOS SERVIÇOS E PRODUTOS” definida no item 16, para que seja realizada a migração sob responsabilidade da CONTRATADA.

INFRAESTRUTURA DE DATA CENTER

A Contratada deverá prover infraestrutura dedicada ao serviço de hospedagem (nuvem privada), armazenamento e processamento, garantindo um ambiente seguro, controlado e com infraestrutura local redundante e tolerante a falhas, segundo padrões internacionais.

Esta infraestrutura deverá ser composta de, no mínimo, 2 (dois) Data Centers (produção e contingência) interligados e em locais distintos, sendo todos em território nacional.

A Contratante se reserva o direito de visitar o ambiente físico da Contratada para certificar o cumprimento das obrigações estabelecidas neste Termo de Referência.

BACKUP DE DADOS

A Contratada deverá possibilitar, a qualquer momento, o acesso ao conteúdo, através do portal de autosserviço, da área de armazenamento de dados e das imagens dos servidores virtuais provisionados para a CONTRATANTE.

A Contratante poderá ter acesso, conforme sua necessidade, aos backups dos dados e das imagens dos servidores virtuais para gestão dos dados.

Enquanto estiver vigente o contrato a CONTRATADA deverá também realizar o backup diário, semanal e mensal da estrutura e dados armazenados em banco, exclusivamente do ambiente de produção.

Entende-se por backup diário aquele contendo as movimentações do dia cujo armazenamento deverá ser de 1(uma) semana - realizado de segunda à quinta-feira; o backup semanal aquele completo realizado na sexta-feira e armazenado por 1(um) mês; e o backup mensal aquele realizado no último dia do mês e armazenado até a realização do backup mensal subsequente, deverá ser mantido backup de 2 (dois) meses consecutivos.

ARMAZENAMENTO DE DADOS

Todos os dados armazenados devem ser mantidos íntegros e acessíveis durante a vigência do contrato. ANEXO III – REQUISITOS DE SEGURANÇA

RS1: A Contratada deverá implementar medidas robustas de segurança para garantir a proteção dos dados contra ameaças externas e internas, antecipando possíveis riscos à privacidade, segurança e integridade dos dados, e prevenindo o acesso não autorizado às informações.

RS2: A infraestrutura da Contratada deve ser submetida a testes de segurança interna e/ou auditorias em intervalos regulares, no mínimo mensalmente. Estes testes devem incluir verificação de vulnerabilidades, avaliação de segurança dos serviços e testes de penetração. Os relatórios resultantes destes testes devem ser disponibilizados à Contratante.

RS3: Se um relatório de teste de segurança identificar uma vulnerabilidade, a Contratada deve elaborar e apresentar um plano de correção detalhado, indicando ações específicas a serem tomadas e prazos para a resolução da vulnerabilidade.

RS4: A Contratada deve fornecer um mecanismo de acesso seguro aos bancos de dados, utilizando chaves de criptografia. Este mecanismo deve garantir que apenas aplicações e usuários autorizados possam acessar os bancos de dados.

RS5: Todo o tráfego de dados da solução deve ser criptografado utilizando técnicas e algoritmos de criptografia reconhecidos pelo mercado, sempre em suas versões mais recentes e seguras.

RS6: Quando possível, a solução deve utilizar criptografia de disco em todos os equipamentos físicos ou virtuais utilizados (ex.: servidores em nuvem, computadores, tablets, etc.). Quando a criptografia de disco não for possível, a Contratada deve fornecer um relatório técnico detalhado justificando a impossibilidade.

RS7: O ambiente onde os dados serão armazenados deve ser regularmente auditado e/ou certificado por uma empresa de auditoria/certificação independente. A Contratante pode solicitar, a qualquer momento, relatórios que atestem a adoção das melhores práticas de segurança da informação, conforme as normas NBR 27000 (27001, 27002, etc.) e ISO/IEC 27000.

RS8: A Contratada deverá fornecer soluções para Proteção e Mitigação de Ataque IP – DoS/DDoS, Sistema de Prevenção a Intrusos – IPS e Enterprise Firewall/Next Generation Firewall (NGFW).

RS9: A solução, quando implementada em nuvem, deve utilizar recursos de CSPM - Cloud Security Posture Management, permitindo a identificação proativa e remediação dos riscos de segurança na nuvem.

RS10: A solução deverá ser protegida por um Web Application Firewall (WAF) fornecido pela Contratada.

RS11: A solução deverá utilizar um Content Delivery Network (CDN) fornecido pela Contratada.

RS12: Sempre que possível, os sistemas e portais devem implementar autenticação multifatorial (MFA). Quando a implementação do MFA não for possível, a Contratada deve fornecer um relatório técnico detalhado justificando a impossibilidade.

RS13: Acesso Seguro - Deve haver pontos de acesso seguros permitindo conexões via HTTPS para comunicação, usando TLS. A versão de TLS utilizada deve ser, no mínimo, a 1.3, que é a mais recente e segura disponível.

RS14: Firewall - É essencial que haja um firewall integrado de alto desempenho e configurável para controle de nível de acessibilidade às instâncias, com capacidade para bloquear acessos indesejados e permitir fluxos de tráfego de confiança.

RS15: Armazenamento Criptografado - A solução deve suportar criptografia automática de todos os dados e objetos armazenados, utilizando algoritmos de criptografia robustos e reconhecidos pelo mercado, sempre na sua versão mais recente e segura.

RS16: Logs de Segurança - A solução deve fornecer logs detalhados de segurança que registrem todas as atividades de todos os usuários, incluindo as chamadas de API, facilitando a análise de segurança e auditorias. Estes logs devem ser facilmente acessíveis e interpretáveis.

RS17: Hierarquia de Usuários - É necessário permitir um controle rigoroso do nível de acesso dos usuários à conta, possibilitando a definição de hierarquias e restrições de acesso, a fim de garantir que cada usuário tenha somente as permissões necessárias para o seu papel.

RS18: Armazenamento de Logs - Os logs de acesso ao ambiente de hospedagem devem ser armazenados de forma segura e criptografada por um prazo de, no mínimo, 12 meses para permitir auditorias de longo prazo e análises de tendências de segurança.

CONFIDENCIALIDADE

A Contratada obriga-se a resguardar os dados e informações de propriedade da Contratante, tanto tecnológicos como administrativos, tais como: dados de usuários, bases de dados, produtos, sistemas,

técnicas, estratégias, métodos de operação e todos e quaisquer outros, repassados por força do objeto desta licitação e do contrato. Estes dados constituem informação privilegiada e possuem caráter de confidencialidade.

As informações só poderão ser utilizadas no cumprimento e execução das cláusulas e condições estabelecidas no Contrato, sendo expressamente vedada a sua utilização ou divulgação por parte da Contratada, estando sujeita às penalidades cabíveis.

Ao término da vigência do contrato, a CONTRATADA disponibilizará mídia digital contendo:

● Prover cópia da base de dados, em formato definido pela CONTRATANTE com fornecimento da documentação, de forma a permitir a recuperação, identificação, relacionamentos garantindo a possibilidade de utilização dos dados contidos nas tabelas do Banco de Dados.

● Validar a cópia descrita acima comparando com os dados em produção.

● Disponibilizar documentos digitais inseridos pelos usuários no sistema durante a vigência do contrato em formato conforme salvo na base de dados.

● executar a destruição/exclusão/“deleção” de todos os dados do seu ambiente e comprovar tal deleção de todas as informações em seu ambiente

ANEXO IV

REGRAS DE VALIDAÇÃO DE PONTOS DE FUNÇÃO

Este ANEXO tem como objetivo detalhar as regras para validação de Pontos de Função na contratação de desenvolvimentos e evoluções de soluções nas quais esta métrica é apontada.

Abreviaturas e Definições

Abreviaturas e Definições
APF	Análise de Pontos de Função é o método para a medição de tamanho funcional de um software. A técnica mede as funcionalidades de um software sob o ponto de vista do usuário.
CPM	Counting Practices Manual (CPM) é o Manual de Práticas de Contagem de pontos de função, mantido pelo IFPUG. Documento que estabelece o método para a realização da contagem de pontos de função, específica o conjunto de definições, regras e passos para a aplicação do método de medição funcional do IFPUG.
IFPUG	O “International Function Point Users Group” é uma organização governada por membros, sem fins lucrativos, com o compromisso de promover e fornece suporte a análise de pontos de função e outras técnicas de medição de software.
NESMA	Netherlands Software Metrics Association (xxx.xxxxx.xxx) é uma organização governada por membros, sem fins lucrativos na Holanda, comprometida para promover e suportar a análise de pontos de função e outros métodos de medição de software.
PBH	Prefeitura de Belo Horizonte
Ponto de Função	Unidade de medida de tamanho funcional de soluções de software tal como definido no método de Medição de Tamanho Funcional (FSM) do IFPUG.
PSP	Processo de Software da PBH, que tem como guia o Manifesto Ágil e o framework de desenvolvimento SCRUM e é constituído por atividades, métodos, práticas e transformações. É organizado em ciclos de desenvolvimento de software, onde cada ciclo contempla e implementa um subconjunto de requisitos.
SISP	O Roteiro de Métricas de Software do SISP (Roteiro SISP) tem o objetivo de apresentar métricas, com base nas regras de contagens de pontos de função do CPM, para vários tipos de projetos de desenvolvimento e manutenção de software, promovendo o uso de métricas objetivas em contratos de prestação de serviços de desenvolvimento e manutenção de sistemas.

Aplicação da Análise de Pontos de Função (APF)

A CONTRATADA deverá utilizar a análise de pontos de função (APF) como método para apurar o tamanho das demandas recebidas e produzidas. A APF foi a técnica escolhida devido aos seguintes fatores: é o método mais utilizado no mercado brasileiro; é o método melhor documentado; é suportado por uma instituição (IFPUG) com credibilidade reconhecida mundialmente.

A CONTRATADA deverá indicar profissional do seu quadro com experiência comprovada em medição de projetos utilizando APF e desejável com certificação em APF, para realizar todas as contagens de ponto de função necessárias ao projeto, sejam para fins de planejamento ou para fins de pagamento.

O CPM (Manual de Práticas de Contagem, na sigla em Inglês) em sua versão 4.3.1, ou mais recente conforme indicação da CONTRATANTE, mantido pelo IFPUG (International Function Point Users Group), será o documento de referência das regras de APF para a medição do tamanho funcional das demandas.

O Roteiro de métricas do SISP em sua versão 2.3, ou mais recente conforme indicação da CONTRATANTE, será adotado como referência para medir os projetos de desenvolvimento, melhoria, além de alguns cenários que não são cobertos pelo CPM.

Caso seja necessário a realização de contagem estimativa de pontos de função, quando necessário, será adotado o método desenvolvido pela NESMA.

Para os cenários onde não for possível determinar um tamanho funcional será utilizada como referência a “Tabela de Itens não Mensuráveis por Ponto de Função”, definida abaixo neste documento.

A critério da CONTRATANTE, para a medição das atividades onde as métricas de pontos de função não se aplicar e não tiverem sido previstas na Tabela - Itens Não Mensuráveis ou não constarem no manual do SISP indicado neste documento, deverá ser utilizado o Fator de Conversão FC=0,15 multiplicado pelo quantitativo em horas do serviço realizado pela CONTRATADA, para fins de faturamento.

O esforço em ponto de função, seja pela contagem do CPM, SISP ou Itens Não Mensuráveis, compreende não só o esforço de implementação da demanda, como também a produção de todos os artefatos necessários, de acordo com a metodologia em uso, acordado entre as partes.

A validação da contagem detalhada de pontos de função somente será feita para funcionalidades entregues e aceitas. Não serão remunerados ajustes feitos em uma solicitação antes do aceite formal da CONTRATANTE para a solicitação.

No caso de existir divergência por parte da CONTRATADA ou da CONTRATANTE quanto às contagens, as partes deverão encaminhar pedido de revisão. Persistindo as divergências, prevalecerá o entendimento da CONTRATANTE.

A existência de divergências quanto às contagens não autoriza a CONTRATADA a onerar os prazos ou o nível de atendimento previsto para o desenvolvimento dos sistemas contratados.

Itens não mensuráveis por ponto de função

A tabela abaixo de itens não mensuráveis será utilizada quando forem solicitados exclusivamente itens nela descritos, e, não houver outras solicitações que impactam processos elementares. Considera-se que os ajustes em processos elementares englobam quaisquer itens contidos nesta tabela.

Identificador	Tipo de Demanda	Unidade de Medida	Valor
01	Alterações de Elementos Visuais - contemplam alterações de cor, estilo e fonte de telas e relatórios sem que tenha havido mudança da funcionalidade.	Tela ou Relatório	0,1 PF
02	Alterações de Layout - contemplam alterações na apresentação sem que tenha havido mudança da funcionalidade - layouts de telas, mudanças de posição de campos em telas; - layouts de relatórios ou layout de arquivos sem que haja alteração em elementos de dados, arquivos referenciados ou informações de controle; - inclusão, alteração ou exclusão de logotipo, cabeçalhos ou títulos.	Quantidade de itens de layout impactados	0,2 PF
03	Mudanças na Navegação - contemplam alterações no fluxo de navegação entre interfaces.	Quantidade de telas impactadas	0,2 PF
04	Preenchimento de tabelas - Contempla o preenchimento de tabelas com dados fornecidos pelo cliente, SEM a necessidade de utilizar funcionalidade específica para isto.	Quantidade de tabelas preenchidas	0,2 PF
05	Divisão de uma tela ou relatório em vários e vice-versa, SEM mudança em funcionalidade.	Tela ou Relatório	2 PF
06	Alteração do texto de mensagens. Contempla a necessidade de alterações de mensagens de retorno ao usuário.	Quantidade de Mensagens alteradas, independente de quantas vezes essa mensagem for referenciada	0,1 PF
07	Adição ou reestruturação de menus de navegação estáticos, ajuda (help estático). Alteração ou exclusão de páginas estáticas.	Quantidade de telas incluídas, alteradas ou excluídas.	0,1 PF
08	DADOS HARD CODED - Criação de listas suspensas (ComboBox ou ListBox). Inclusão, alteração ou exclusão de dados nessas listas, desde que esses dados sejam fixos no código (hard coded) ou tabelas físicas.	Quantidade de dados manipulados	0,1 PF
09	PARÂMETROS DE PROCESSAMENTO. Contempla a	Quantidade de parâmetros	0,1 PF

necessidade de alteração dos valores dos parâmetros, sem que a lógica de processamento tenha sido alterada.

alterados

Tabela - Itens não mensuráveis

● Em relação à tabela acima, fica estabelecido que a unidade de referência “tela” corresponde a uma janela ou página do aplicativo para a realização de um cadastro, exibição de uma consulta, etc. No caso de aplicativos que utilizem recurso de abas para cada aba será contabilizada uma tela.

● A “Tabela - Itens não Mensuráveis” sobrepõe a seção 4.7 “Manutenção em Interface” do roteiro de métricas do SISP.

● Para os casos de desenvolvimento de scripts de banco de dados, será aplicado o fator de impacto de 50% em relação à seção 4.9 “Apuração Especial” do roteiro de métrica do SISP.

Cálculo do tamanho de uma demanda

● O cálculo do tamanho funcional de uma demanda obedece às seguintes regras: Para desenvolvimento de novos módulos ou sistemas:

● É realizado o cálculo do tamanho funcional da demanda conforme as regras estabelecidas no manual CPM.

● É realizada a aplicação dos fatores de impacto do roteiro de métricas do SISP, quando indicado.

● É realizada a inclusão dos itens listados na “Tabela de Itens não Mensuráveis por Ponto de Função” deste documento, quando aplicável, para as funções transacionais que não foram contadas nos itens acima.

Para cálculos de demandas evolutivas e serviços eventuais durante a sustentação de

sistemas:

● É realizado o cálculo do tamanho funcional da demanda conforme as regras estabelecidas no manual CPM.

● É realizada a aplicação dos fatores de impacto do roteiro de métricas do SISP, quando indicado.

Linha de base de ponto de função

● A linha de base de ponto de função é de responsabilidade da CONTRATADA e deverá ser atualizada e entregue junto com as contagem de tamanho funcional de cada solicitação. A linha de base, além de contemplar o tamanho funcional da aplicação, deverá conter o histórico das solicitações formalizadas pela CONTRATANTE entregues pela CONTRATADA.

Orientações gerais sobre o detalhamento da aquisição

● Caso o IFPUG divulgue novas versões do CPM, a CONTRATANTE se reserva o direito de adotar as novas versões do CPM ou manter a versão 4.3.1 vigente.

● Caso o SISP divulgue novas versões do roteiro, a CONTRATANTE se reserva o direito de adotar as novas versões deste roteiro ou manter a versão 2.3 vigente.

● Conforme descrito, utilizamos o CPM e o roteiro do SISP como referência de regras para medição do tamanho funcional do projeto.

● No entanto, para os cenários onde ainda são percebidos debates e impasses em relação às contagens, foi elaborado o documento de “Roteiro de Análise de Ponto de Função Prodabel”, no qual é especificado a forma de contagem destes cenários. Este documento pode ser acessado através do link xxxxx://xxx.xxx.xxx.xx/xxxx na seção Métrica de Software.

Pagamento por fases contratadas

● A critério da CONTRATANTE e também conforme indicado em algumas situações do roteiro do SISP, poderá ser solicitada a prestação de serviços para fases específicas do ciclo de desenvolvimento de software, considerando a distribuição percentual para cada fase, conforme tabela abaixo. O pagamento desses percentuais abrange a confecção de todos os artefatos previstos para a disciplina constantes no Processo de Software da Prefeitura de Belo Horizonte (PSP).

Fases	Percentual de esforço
Engenharia de Requisitos	25%
Análise e Desenho	10%
Implementação	40%
Teste	15%
Homologação	5%
Implantação	5%
Total	100%

ANEXO V INTERFACES DA SOLUÇÃO

1. CONSIDERAÇÕES

1.1. As integrações sinalizadas neste anexo, devem compor o valor apresentado pela PROPONENTE para execução do serviço em atendimento ao Edital. Logo, a empresa deve estimar o seu esforço para que possa precificar adequadamente.

1.2. Entende-se Fluxo de “Busca”, a customização na solução que permita que este sistema consuma os serviços dos sistemas de origem, buscando os dados e os apresentando adequadamente na interface da solução.

1.3. Entende-se Fluxo de “Envio” a customização na solução que permita que este sistema oferte serviços que serão consumidos pelos sistemas de destino, os quais devem registrar estes dados.

1.4. Quando um sistema integrado à solução SAMU for substituído em tempo de projeto, caberá à CONTRATADA apontar a integração para o novo sistema e fazer os devidos ajustes sem ônus para a CONTRATANTE.

Quadro 7 do Anexo V: Integrações

SISTEMA DA SMSA/PBH

Item

Sistema

Fornece dor

Mecanismo Interoperabili dade

Áreas Atendidas pelo Sistema

Dados Integrados

Complexi dade/Flux o

Necessário persistir dados na base de dados da solução

Sistema de Gestão de Ocorrências do COP-BH

(BHDigital) ou substituto

PBH

WebService; Síncrono.

Atendiment o SAMU e acionament o COP-BH.

Abertura de chamado no sistema BHdigital-COP-BH via acionamento direto do sistema SAMU e abertura de chamado no sistema do SAMU via acionamento direto do sistema BHdigital-COP-BH

Média; Busca e envio.

Sim.

Sistema de Gestão de Ocorrências do COP-BH

(BHDigital) ou substituto

PBH

WebService; Síncrono.

Atendiment o SAMU e acionament o COP-BH.

Envio de dados das ocorrências do SAMU para o sistema BHdigital-COP-BH e busca de dados das ocorrências do BHdigital-COP-BH para o sistema SAMU.

Média; Xxxxx e envio.

Sim

SIGBASES ou

substituto

PBH

WebService; Síncrono.

Cadastros básicos do sistema SAMU

Obter os dados cadastrais do usuário-SUS, incluindo endereço, do sistema SIGBASES, caso existam.

Média; Busca

Sim.

SIGBASES ou

substituto

PBH

WebService; assíncrono.

Cadastros básicos do SAMU

Obter os dados cadastrais do Profissional, das Unidades, dos Procedimentos e Código Local (SUS).

Média; Busca

Sim.

SIGRAH INTEGRA SUS BH ou

substituto

PBH/M V

WebService; Síncrono.

Dados Clínicos do Usuário- SUS (SAMU)

Histórico de atendimento do usuário-SUS.

Média: Busca e envio.

Sim.

SIGRAH -

Regulação do Acesso ou substituto

PBH/M V

WebService; Síncrono.

Dados de disponibilid ade de Leitos (SAMU).

Solicitação de transporte Liberação do leito.

Média: Busca e envio

Sim.

SIGRAH ou

substituto

PBH/M V

web service assíncrono

Dados de gestão de estoque de Materiais (SAMU)

Obter dados do estoque do sistema SIGRAH e informar dados de consumo para baixa de materiais no sistema SIGRAH.

Média: Busca e envio

Sim

Sistema de Gestão de Escala ou substituto

PBH

Web service síncrono

Dados de escala dos profissionai s de Saúde (SAMU)

Obter Dados de Escala do sistema de Gestão de Escala

Média: Busca

Sim

1.5. O mecanismo de interoperabilidade e os dados trafegados para todos os sistemas listados será o apresentado no documento, porém, o sistema responsável por disponibilizar a informação poderá variar conforme necessidade da CONTRATANTE, sendo o mesmo citado apenas como referência.

1.6. As interfaces - interoperabilidades - que serão realizadas, em tempo de Projeto, poderão ser exploradas tecnicamente pela PROPONENTE, por meio de visita técnica, agendada com o CIAS, à CONTRATANTE, à Prodabel, e sabatina à equipe técnica responsável pela sustentação dos sistemas indicados.

2. DADOS TÉCNICOS

2.1. Sistema de Gestão de Ocorrências do COP-BH (BH Digital) (item 1 e item 2):

a) Base de dados: base de dados do SICOP/BH Digital; Implementada em banco de dados orientado a documentos, utilizando o SGBD MongoDB.

b) Linguagem: JavaScript.

c) Hospedagem: Hospedado em nuvem

d) Serviços Web: API (tecnologia RESTFul)

2.2. SIGBASES - Sistema de Gestão de Bases Corporativas (item 3 e item 4)

a) Base de dados: PostgresSQL 12

b) Ambiente: Debian 9 (stretch)

c) Desenvolvimento: Eclipse, DBEaver 21.0.3

d) Ambiente de Qa: Esteira Integração Contínua - Jenkins, Logs dos Servidores de Aplicação (Graylog), Análise de Qualidade de Código (SonarQube)

e) Frameworks: Angular CLI versão 7.3.9., Bootstrap 4.x, Hibernate-Envers 4.x. Quartz Scheduler 2.3.0,

NPM 6.x

f) Servidor de aplicação: Wildfly 14.x, Tomcat 6.x, Apache 2.4

g) Linguagem: JDK 8u181 x64, Java EE 8

2.3. INTEGRA SUS (item 5)

	a)	Base de dados: PostgresSQL 11
	b)	Ambiente: Debian 9 (stretch)
	c)	Desenvolvimento: Eclipse, DBEaver 21.0.3
	d)	Ambiente de Qa: Esteira Integração Contínua - Jenkins, Logs dos Servidores de Aplicação (Graylog), Análise de Qualidade de Código (SonarQube)
	e)	Frameworks: Angular CLI versão 7.3.9., Bootstrap 4.x, Hibernate-Envers 4.x. Quartz Scheduler 2.3.0, NPM 6.x
	f)	Linguagem: JDK 8u181 x64, Java EE 8
	g)	Servidor de aplicação: Wildfly 14.x, Tomcat 6.x, Apache 2.4
2.4.		SIGRAH - Sistema de Gestão em Saúde (item 6 e item 7)
	a)	Base de dados: Oracle Database 12C Enterprise Edition 2 64bits em RAC
	b)	Ambiente SO: Sistema operacional Oracle Enterprise Linux 7 64 bits
	c)	Linguagem: JAVA
	d)	Serviços Web (WS): Usando barramento de serviços com REST
2.5.		Sistema de Gestão de Escala

ANEXO VI

NÍVEIS DE SERVIÇOS ACORDADOS - SLA’S

INTRODUÇÃO

Os níveis de serviço acordados são critérios objetivos e mensuráveis com a finalidade de aferir e avaliar fatores relacionados aos serviços contratados, principalmente qualidade, desempenho e disponibilidade. Eles incidirão sobre os três itens que compõem o objeto do contrato.

As penalidades previstas no descumprimento dos SLA's podem ser vinculadas às multas descritas no item SANÇÕES ADMINISTRATIVAS. Tais sanções poderão não ser aplicadas, a critério da CONTRATANTE, para casos excepcionais, devidamente justificados.

INDICADORES DE EXECUÇÃO DOS SERVIÇOS CONTRATADOS

Quadro 8 - Anexo VI: Indicadores de aferição dos SLAs

Indicadores dos SLAs
Indicador	Descrição
(2.1)ICPM - Indicador de Cumprimento de Prazo dos Xxxxxx	Xxxx indicador tem como objetivo definir critérios mínimos a serem atendidos pela CONTRATADA no que se refere ao cumprimento do prazo dos marcos acordados durante a execução de projeto de implantação e projetos de melhorias.
(2.2)IST - Indicador Satisfação do Treinamento	Mede o nível de satisfação dos treinados. Caso o nível de satisfação dos treinados, por meio de questionários de avaliação, não atinja 60% (sessenta por cento) por treinamento, este deverá ser refeito integralmente.
(2.3)IDS - Indicador de Defeitos no Software	Este indicador tem como objetivo definir critérios mínimos a serem atendidos pela CONTRATADA no que se refere à qualidade dos softwares entregues durante a execução de customizações e integrações do sistema.
(2.4)ISUT - Indicador de Suporte Técnico	Mede os chamados fechados que não cumpriram os prazos determinados no Quadro 13 – Anexo VI: Suporte Técnico – Nível de Severidade no período aferido.
(2.5)IDHS - Indicador de Disponibilidade da Hospedagem do Sistema	Este indicador tem como objetivo definir critérios mínimos a serem atendidos pela CONTRATADA no que se refere ao cumprimento do percentual de disponibilidade do ambiente de Data Center no qual está hospedado o sistema, incluindo o acesso aos dados.

Indicador de Cumprimento de Prazo dos Marcos (ICPM)

Quadro 9 - Anexo VI: Indicador de Cumprimento de Prazo dos Marcos (ICPM)

Indicador de Cumprimento de Prazo dos Marcos (ICPM)
Indicador	Descrição
Descrição do Indicador	Este indicador tem como objetivo definir critérios mínimos a serem atendidos pela CONTRATADA no que se refere ao cumprimento do prazo dos marcos acordados durante a execução de projeto de implantação e projetos de melhorias e customizações.
Aferição	Na entrega dos marcos do cronograma do projeto, o indicador será aferido pela CONTRATANTE, sendo que a CONTRATADA será considerada inadimplente caso ocorra atraso.
Fórmula de Xxxxxxx	Xxxx de Atraso do Marco = (Data Real da Entrega do Marco – Data Prevista da Entrega do Marco). Onde: Dias de Atraso do Xxxxx: dias de atraso na entrega do marco definido no cronograma e linha de base aprovadas pela CONTRATANTE. Data Real da Entrega do Marco: data na qual a CONTRATADA formaliza à CONTRATANTE a entrega do Xxxxx. Data Prevista da Entrega do Marco: data na qual estava prevista a entrega do Marco conforme respectiva Linha de Base (LB) aprovada, acordado entre as partes.
Incidência	O atraso ocorre quando os dias de atraso do Marco na linha de base forem superiores a zero.
Sanções	No caso de inadimplência, a CONTRATADA será advertida e/ou multada pela CONTRATANTE, conforme previsto neste documento. Caso ocorra atraso, será aplicada uma multa moratória de 0,33% por dia de atraso até o limite de 9,99%, sobre o valor correspondente à parte inadimplente, isto é, o valor correspondente ao marco em questão no cronograma físico financeiro ou Ordem de Serviço, sem prejuízo das demais sanções legais cabíveis à espécie.
Forma de Auditoria	Documentação: por meio das datas de entrega constantes nos termos de aceite do item aferido, conforme linha de base – LB respectiva.
Observação	Os marcos definidos no cronograma do plano de projeto com suas respectivas linhas de base poderão ser ajustados de acordo com a oportunidade e a conveniência da CONTRATANTE, respeitando todos os aspectos legais e os direitos da CONTRATADA.

Os prazos acordados/estabelecidos serão referenciados nos quadros Prazos das Entregas que se encontram neste documento.

Os prazos acordados pela CONTRATANTE e registrados como Linha de Base - LB – devem ser formalizados em ata, devidamente assinadas, e disseminada para as partes interessadas da CONTRATADA e da CONTRATANTE.

Atrasos que comprometam a execução do planejamento de implantação que sejam de responsabilidade do CONTRATANTE, devidamente comprovados pela CONTRATADA, não serão considerados na aferição dos níveis de serviço.

Indicador de Defeitos de Software (IDS)

Será aplicado em alguns entregáveis previstos no projeto de implantação e nos projetos de melhorias executados por meio de OS.

Quadro 10 - Anexo VI: Indicador de Defeitos no Software (IDS)

Indicador de Defeitos no Software (IDS)
Indicador	Descrição
Descrição do Indicador	Este indicador tem como objetivo definir critérios mínimos a serem atendidos pela CONTRATADA no que se refere à qualidade dos softwares entregues durante a execução dos pontos de função contratados pelo item III.
Aferição	O indicador é aferido ao fim do cumprimento da ordem de serviço correspondente, durante o processo de homologação da entrega.
Fórmula de Cálculo	IDS = (TDRC/TPEI) Onde: IDS = Indicador de Defeitos no Software TDRC= Total de Defeitos Registrados pela CONTRATANTE; somatório de todos os defeitos encontrados pela CONTRATANTE nos softwares entregues no respectivo versionamento, relativo aos processos elementares impactados. TPEI = Total de Processos Elementares Impactados; somatório de todos os processos elementares atendidos pelo software entregue pela CONTRATADA à CONTRATANTE no respectivo versionamento, relativo ao total de processos elementares impactados.
Nível mínimo de serviço exigido	O limite tolerável para o IDS é de 0,40 para não penalidade.
Sanções	> 0,40 até 0,60 penalidade de 3% sobre o valor da entrega > 0,60 até 0,80 penalidade de 5% sobre o valor da entrega > 0,80 penalidade de 10% sobre o valor da entrega
Forma de Auditoria	Documentação: a) Planilha de apresentação dos processos elementares (template Prodabel) b) Abertura de chamados para correção de defeitos.

Indicador de Satisfação do Treinamento - IST

Quadro 11 - Anexo VI: Indicador Satisfação do Treinamento – IST

Indicador Satisfação do Treinamento - IST
Indicador	Descrição
Descrição do Indicador	Mede o nível de satisfação dos treinandos. Caso o nível de satisfação dos treinandos, por meio de questionários de avaliação, não atinja 60% (sessenta por cento) por treinamento, este deverá ser refeito integralmente.
Aferição	Pela CONTRATANTE em pesquisa de satisfação pós-treinamento.
Fórmula de Cálculo	IST = (QtNC / TPF) Onde: IST = Índice de não conformidades com o nível de satisfação; QtNC = Quantidade de avaliações não conformes aferidas; TPF = Total de avaliações aferidas.
Nível mínimo de serviço exigido	IST Desejável = 0, nenhuma não conformidade. IST Aceitável = 0,4, não conforme até 40% (quarenta por cento) IST Inaceitável > 0,4, não conformidade acima de 40% (quarenta por cento)
Sanções	IST Desejável: nenhuma IST Aceitável: advertência IST Inaceitável: A CONTRATADA deverá refazer o treinamento sem custos adicionais.
Forma de Auditoria	Documentação: lista de presença e questionários de avaliação.

Indicador de Suporte Técnico - ISUT

O serviço de manutenção e suporte técnico relativo à prestação de serviços deste objeto será relatado pela CONTRATANTE e atendido pela CONTRATADA, mediante sistema web de registro de chamados disponibilizado pela CONTRATADA, em que conste, entre outros:

● descrição do problema evidenciado;

● data e hora de abertura do chamado;

Classificação de severidade do chamado (baixa, média, alta e crítico). Os chamados de suporte técnico compreendem as seguintes atividades:

. Incidente e/ou Problemas técnicos: incidentes e/ou problemas decorrentes de inadequação legal, erro de processamento, erros de programação e lógica, falhas na integração.

● “Incidente: É uma interrupção não planejada de um serviço de TI ou uma redução da qualidade de um serviço de TI”.

● “Problema: é a existência de um erro cuja causa é desconhecida. É a causa desconhecida de um ou mais incidentes”.

b. Dúvidas de uso: dúvidas decorrentes da utilização da solução, da atualização de versão ou da inclusão de novas funcionalidades.

c. Um chamado de solução técnica poderá ter seu nível de severidade alterado pela CONTRATANTE, para uma maior ou menor severidade, sendo todos os prazos referentes ao novo nível reiniciados.

d. A severidade de atendimento aos chamados será definida pela CONTRATANTE. Caso a equipe de suporte da CONTRATADA não concorde com a classificação de severidade de uma solicitação deverá contactar a CONTRATANTE para que sejam discutidas suas razões e uma nova classificação seja acordada. Caso essa solicitação não ocorra dentro do prazo de atendimento, será considerada a classificação de prioridade registrada no sistema pelo solicitante (CONTRATANTE).

e. Caberá à CONTRATADA prover os relatórios digitais dos tempos de atendimento nos quais permitam fazer a verificação da acuidade de cumprimento aos prazos definidos no Quadro 6 – Anexo VI: Suporte Técnico – Nível de Severidade

Quadro 12 - Anexo VI: Indicador de Suporte Técnico – ISUT

Indicador de Suporte Técnico – ISUT
Indicador	Descrição
Descrição do Indicador	Mede o atendimento de chamados para manutenção e suporte em conformidade com os prazos estabelecidos para solucionar incidente, causa de problema, dúvidas de usuários.
Aferição	Número de chamados atendidos dentre dos parâmetros de severidade para solução no período de medição.
Fórmula de Cálculo da Sanção	Incidirá sobre 33% do valor da mensalidade referente ao item I do objeto do contrato: Vm = 0,3 + 0,7 * (Ca ÷ Ct) * VInd.parcela Vm é o valor, em Reais (R$), a ser pago pela prestação dos serviços em cada período de medição; Ca é o número de chamados atendidos em conformidade com os níveis de severidade indicados no Quadro 13 Anexo VI - Suporte Técnico - Nível de Severidade no período apurado; Ct é o número total de chamados abertos no período de medição mais os chamados não atendidos do período anterior aferido; VInd.parcela é 33% do valor da parcela da mensalidade referente ao item I do objeto do contrato sobre a qual incidirá as penalidades
Nível mínimo de serviço exigido	Conforme Quadro 13 Anexo VI - Suporte Técnico - Nível de Severidade
Sanções	Multa aplicada como desconto sobre a medição dos chamados registrados.
Forma de Auditoria	Ferramenta de gestão de chamados.

Observações

Chamados não atendidos do período anterior serão somados no Ct (chamados abertos no período) do período em análise.

Ct sempre deve ser diferente de Zero para o cálculo. Se não teve chamados no período (Ct=0) e não tiver chamados não atendidos do período anterior aferido, o fornecedor recebe o valor integral da parcela VInd.Parcela;

Período de medição será mensal, com a apuração no quinto dia útil do mês subsequente.

Considera-se atendimentos pendentes como os casos abertos nos períodos de apuração anteriores e que não estão em conformidade com os níveis de severidade indicados no Quadro 13 - Anexo VI - Suporte Técnico - Nível de Severidade, seja um incidente e/ou o problema;

Esses atendimentos pendentes serão somados aos números totais de chamados abertos no período de medição, somando-se ao valor de Ct;

Como exemplo podemos simular uma situação de seis meses, e um valor de mensalidade do Item III do objeto do contrato de R$ 30.304,00 (trinta mil e trezentos e quatro reais), exposto no Quadro 14 - Anexo VI: Exemplo de aplicação do indicador ISUT

Quadro 13 - Anexo VI: Suporte Técnico – Nível de Severidade

SUPORTE TÉCNICO
NÍVEL DE SEVERIDADE	PRAZO PARA SOLUÇÃO DO INCIDENTE	PRAZO PARA SOLUÇÃO DA CAUSA DO PROBLEMA
CRÍTICO	01 hora corrida	12 horas úteis
ALTO	04 horas corridas	36 horas úteis
MÉDIO	12 horas úteis	60 horas úteis
BAIXO	24 horas úteis	90 horas úteis
DESCRIÇÃO DOS NÍVEIS DE SEVERIDADE
CRÍTICO	Incidente com paralisação da solução, parte importante dele, ou comprometimento gravíssimo de dados, processos, equipamentos ou ambiente.
ALTO	Incidente com paralisação de parte da solução, parte importante dele, ou comprometimento grave de dados, processos e equipamentos ou ambiente.

MÉDIO	Incidente sem paralisação da solução, parte importante dele, porém com comprometimento de dados, processos e equipamentos ou ambiente.
BAIXO	Incidente sem paralisação da solução, parte importante dele é pequeno ou nenhum comprometimento de dados, processos e equipamentos ou ambiente.

Cabe à CONTRATADA enviar à CONTRATANTE relatório contendo a identificação da solicitação, data de abertura, data de fechamento, status da solicitação: se a solicitação foi atendida em conformidade, atendida fora do prazo de conformidade ou se ainda está em atendimento.

A CONTRATANTE terá o direito de auditar os relatórios enviados, quando julgar necessário.

Quadro 14 – Anexo VI: Exemplo de aplicação do indicador ISUT

Meses

Atividades

Valor mensalidade Manutenção Item I do Objeto

R$ 30.304,00

Vmax (33% mensalidade) é o valor máximo da parcela

R$10.000,00

VM= valor, em Reais (R$), a ser pago pela prestação dos serviços em cada período de medição;

R$6.500,00

R$5.058,82

R$4.909,09

R$5.701,75

R$5.935,48

R$10.000,00

Glosa

R$3.500,00

R$4.941,18

R$5.090,91

R$4.298,25

R$4.064,52

R$0,00

Chamados abertos no mês

145

Ca-número de chamados atendidos em conformidade com os níveis de severidade indicados (incidente e causa do problema)

Chamados atendidos fora da Conformidade no mês

Chamados

não atendidos no mês

Chamados pendentes de meses

Ct=Chamados Abertos

155

dos 5

anteriores, 2 foram resolvidos

Foram resolvidos os 7 casos pendentes do mês 3 mas permaneceram 3 casos pendentes do mês 2.

dos 14 anteriores, 10 ficaram pendentes e os 3 pendentes do mês anterior foram resolvidos

Todas pendências resolvidas e tudo atendido em conformidade

● Considerando o valor mensalidade Manutenção (Item I do Objeto) igual a R$ 30.304.00 (trinta mil trezentos e quatro reais), o Vmax (valor máximo da parcela), será de R$ 10.000,00 (dez mil reais) correspondendo a (33% mensalidade);

● No mês 1 foram abertos quatro (4) casos, sendo que dois (2) foram resolvidos dentro do tempo estipulado, gerando um (1) caso atendido fora do prazo e um (1) caso não foram atendidos de forma alguma.

● O Vm foi calculado tendo o Ca de valor dois (2) e Ct de valor (4), garantindo um Vm de R$ 6.500,00 (seis mil e quinhentos reais) pelo serviço prestado

● No mês 2 foram abertos dezesseis (16) novos casos, sendo que apenas cinco (5) foram resolvidos em conformidade com o prazo estipulado, seis (6) chamados atendidos fora da conformidade no mês, cinco

(5) casos não foram atendidos. Considerando que o caso pendente do mês anterior ainda não foi resolvido, este será contabilizado no CT (chamados abertos), sendo igual a dezessete (17) casos. O Vm será calculado tendo Ca de valor cinco (5) e Ct de valor dezessete (17), resultando num valor de mensalidade de R$5.058,82 (cinco mil cinquenta e oito reais e oitenta e dois centavos);

● No mês 3 foram abertos dezenove (19) novos casos, sendo que seis (6) casos foram resolvidos dentro do tempo estipulado, seis (6) chamados atendidos fora da conformidade no mês, sete (7) casos não foram atendidos. Considerando que três (3) casos ficaram pendentes dos meses anteriores, este será contabilizado no CT (chamados abertos), sendo igual a vinte e dois (22) casos. O Vm será calculado tendo Ca de valor seis (6) e Ct de valor vinte e dois (22), resultando num valor de mensalidade de R$4.909,09 (quatro mil novecentos e nove reais e nove centavos);

● No mês 4 foram abertos cinquenta e quatro (54) novos casos, sendo que vinte e dois (22) caso foram resolvidos dentro do tempo estipulado, dezoito (18) chamados atendidos fora da conformidade no mês, quatorze (14) casos não foram atendidos. Considerando que três (3) casos ficaram pendentes dos meses anteriores, este será contabilizado no CT (chamados abertos), sendo igual a cinquenta e sete (57) casos. O Vm será calculado tendo Ca de valor seis (6) e Ct de valor vinte e dois (22), resultando num valor de mensalidade de R$5.701,75 (cinco mil setecentos e um reais e setenta e cinco centavos);

● No mês 5 foram abertos cento e quarenta e cinco (145) novos casos, sendo que sessenta e cinco (65) casos foram resolvidos dentro do tempo estipulado, quarenta e sete (47) chamados atendidos fora da conformidade no mês, trinta e três (33) casos não foram atendidos. Considerando que dez (10) casos ficaram pendentes dos meses anteriores, este será contabilizado no CT (chamados abertos), sendo igual a cento e cinquenta e cinco (155) casos. O Vm será calculado tendo Ca de valor sessenta e cinco (65) e Ct de valor cento e cinquenta e cinco (155), resultando num valor de mensalidade de R$5.935,48 (cinco mil novecentos e trinta e cinco reais e quarenta e oito centavos);

● No mês 6 foram abertos sessenta (60) novos casos, sendo que todos os casos foram resolvidos dentro do tempo estipulado. Considerando que não ficou nenhum caso pendente dos meses anteriores, o Vm será calculado tendo Ca de valor sessenta (60) e Ct de valor sessenta (60), resultando num valor de mensalidade integral de R$ 10.000,00 (dez mil reais);

Gerenciamento do Suporte Técnico:

O chamado será aberto pela CONTRATANTE, que definirá o nível de severidade e informará a identificação e descrição do incidente.

Os prazos acima descritos começarão a contar a partir do registro do chamado. Será considerado hora corrida de domingo a domingo das 00:00h às 24:00h.

Será considerado hora útil o período das 7h às 19h, horário de Brasília, de segunda-feira a sexta-feira, exceto feriados.

Os chamados deverão ser obrigatoriamente registrados no sistema de atendimento via web ou por telefone em qualquer horário, mas se registrado fora do horário indicado para os chamados de severidade média e baixa os prazos iniciar-se-ão às 7h do próximo dia útil.

Excepcionalmente para resolutividade de questões emergenciais de alto impacto, reserva-se ao CONTRATANTE o direito de abrir chamado e ter a questão solucionada dentro dos prazos acima previstos para alta criticidade em horários e dias diferentes dos descritos acima.

Para os níveis de severidade CRÍTICO e ALTO, a CONTRATADA deverá informar a previsão para a solução do problema ao CONTRATANTE em, no máximo, 01 (uma) hora corrida e 01 (uma) hora útil, respectivamente, a partir da abertura do chamado.

As ações realizadas pela CONTRATADA não podem comprometer outras funcionalidades da solução, de qualquer outro software ou ambiente do CONTRATANTE.

Considera-se como solução provisória do problema a correção, mesmo que paliativa, do mau funcionamento registrado.

Considera-se como solução da causa do problema a correção definitiva da situação que provocou o mau funcionamento registrado.

O atendimento a um chamado registrado para CONTRATADA, somente será considerado como concluído (fechado) depois do aceite registrado pela CONTRATANTE. Se a CONTRATANTE não der o aceite em até 5 dias úteis, o atendimento será registrado como aceito e concluído automaticamente.

Um chamado de solução técnica poderá ter seu nível de severidade alterado pela CONTRATANTE, para uma maior ou menor severidade, sendo todos os prazos referentes ao novo nível reiniciados.

A severidade de atendimento aos chamados será definida pela CONTRATANTE. Caso a equipe de suporte da CONTRATADA não concorde com a classificação de severidade de uma solicitação deverá contactar a CONTRATANTE para que sejam discutidas suas razões e uma nova classificação seja acordada. O grau de severidade só poderá ser alterado se aprovado pela CONTRATANTE. Caso essa solicitação não ocorra dentro do prazo de atendimento, será considerada a classificação de prioridade registrada no sistema pelo solicitante (CONTRATANTE).

A CONTRATANTE poderá prorrogar os prazos definidos no Quadro 13 - Anexo VI: Suporte Técnico Nível de Severidade, em relação a determinado chamado, desde que a prorrogação seja justificada pela CONTRATADA em razão da complexidade das atividades que deverão ser realizadas.

A CONTRATADA deverá registrar as justificativas do possível atraso no sistema de acompanhamento de chamados e comunicar previamente ao CONTRATANTE para que a prorrogação seja avaliada, antes do término do prazo original.

A justificativa de prorrogação deverá ser aprovada pela CONTRATANTE, caso contrário não será considerada para fins de apuração dos níveis de serviço.

A prorrogação de prazo é totalmente discricionária por parte do CONTRATANTE em relação a um específico chamado e não constituirá novação para chamados de natureza semelhante.

Até o fechamento do chamado, a CONTRATADA deverá completar o sistema de Registro de Chamados Técnicos com todas as informações envolvidas no chamado, ao menos a evolução da resolução do problema, as medidas paliativas definitivas e executadas e os documentos de referência utilizados, de modo a constituir base de conhecimento a outros profissionais da CONTRATADA e do CONTRATANTE e aferição dos indicadores de níveis de serviço.

Caberá à CONTRATADA garantir que os demandantes efetivem a confirmação do fechamento dos chamados.

O fechamento do chamado deverá ser registrado formalmente pelo usuário demandante no sistema de acompanhamento de chamadas. Caso este fechamento não se dê num prazo de 5 (cinco) dias corridos, esse atendimento será fechado automaticamente.

A resolução do chamado será registrada pela CONTRATADA, contendo todas as ações realizadas e devidamente documentadas e acompanhadas pelo responsável do CONTRATANTE.

As mudanças de evolução de cada atendimento (status) devem ser comunicadas via e-mail ao solicitante para ciência ou devidas providências.

O horário de fechamento do atendimento será considerado aquele em que o incidente ou o problema se apresentou como resolvido na ótica dos usuários do sistema.

Caso o usuário considere que o incidente ou solução do problema não satisfatório, este terá a opção de reabrir ou retornar o caso para a CONTRATADA dar tratamento.

No momento do fechamento o demandante deverá indicar se está “satisfeito” ou “insatisfeito” com o atendimento em geral.

Para efeito de mensuração dos níveis de serviço serão considerados as seguintes variáveis:

Quadro 15 – Anexo VI: Definição de tempo de atendimento do chamado

Níveis De Serviço
VARIÁVEIS	Descrição
TEMPO DE SOLUÇÃO DO INCIDENTE	Tempo de solução do incidente dos atendimentos de chamados de suporte técnico, por nível de severidade.
TEMPO DE SOLUÇÃO DA CAUSA	Tempo médio de solução da causa do problema de chamados de suporte técnico, por nível de severidade.

Cumprimento de SLA referente ao “tempo de solução do incidente” e “tempo de solução da causa”

O cálculo dos tempos médios será feito pela diferença entre data-hora-minuto de abertura do chamado e data-hora-minuto dos momentos previstos no Quadro 13 – Anexo VI: Suporte Técnico – Nível de Severidade.

O valor final será expresso em horas, considerando-se as duas primeiras casas decimais, desprezando- se as demais.

Serão considerados no cálculo dos tempos médios apenas os chamados fechados no mês do faturamento. Para o incidente que tiver prazo prorrogado, autorizado pela CONTRATANTE, será considerado para o cálculo dos tempos médios os prazos limites definidos no Quadro 13 – Anexo VI: Suporte Técnico – Nível de Severidade.

● Caso a empresa não cumpra o novo prazo concedido, o tempo excedente ao novo prazo será acrescido aos prazos limites definidos no Quadro 13 – Anexo VI: Suporte Técnico – Nível de Severidade no cálculo dos tempos médios.

Será considerado que os níveis de serviços foram atingidos se:

● Os indicadores de tempo forem iguais ou inferiores aos valores constantes no

● Quadro 13-Anexo VI: Suporte Técnico – Nível de Severidade.

Indicador de Disponibilidade da Hospedagem do Sistema - IDHS

Quadro 16 – Anexo VI: Indicador de Disponibilidade da Hospedagem do Sistema (IDHS)

Indicador de Disponibilidade da Hospedagem do Sistema (IDHS)

Indicador

Descrição

Descrição do Indicador

Este indicador tem como objetivo definir critérios mínimos a serem atendidos pela CONTRATADA no que se refere ao cumprimento do percentual de disponibilidade do ambiente de Data Center no qual está hospedado o sistema, incluindo o acesso aos dados.

Aferição

Relatório mensal provido pela CONTRATADA em meio digital de todas as paralisações ocorridas no período.

Este relatório poderá confrontado com o relatório de atendimento provido pela CONTRATADA da indisponibilidade da solução no ambiente de hospedagem.

Fórmula de Cálculo da Sanção

O sistema deverá atender ao SLA de disponibilidade de no mínimo 99,982% (noventa e nove, novecentos e oitenta e dois por cento), devendo ser calculado conforme a fórmula abaixo relacionada:

Sendo que:

Qtde. minutos no mês = (30 x 24 x 60) = 43200 minutos

Entende-se por disponibilidade do sistema, a possibilidade em executar qualquer funcionalidade referente ao processamento da solução.

Caso IDHS seja inferior ao valor de 99,982% temos que:

VS_IDHS = 0,3 * Vind.Parcela, onde

VS_IDHS é o valor da sansão aplicada sobre a VindParcela;

VInd.parcela é 33% do valor da parcela da mensalidade referente ao item III do objeto do contrato sobre a qual incidirá as penalidades

Incidência

A execução do sistema no ambiente do Data center deve ter a taxa de disponibilidade mensal igual ou superior a 99,982%. Qualquer taxa mensal inferior a essa incidirá sanções.

Sanções

A penalidade será de 30% sobre 33% (trinta e três por cento) do valor da parcela da mensalidade referente ao item III do objeto do contrato sobre a qual incidirá as penalidades, caso o IDHS seja inferior ao valor de 99,982%, contabilizados a cada mês.

Forma de Auditoria

Documentação: relatórios mensais enviados pela CONTRATADA contendo a taxa de disponibilidade do sistema-ambiente e auditoria, caso necessário.

Observação

Durante todo o período de vigência contratual, a CONTRATADA deverá prestar os serviços sob sua responsabilidade de forma contínua e ininterrupta, com elevado índice de qualidade, devendo tomar todas as providências cabíveis para a reversão dos problemas eventualmente identificados.

O sistema deve ser hospedado de acordo com os itens definidos no Anexo III - "Hospedagem da solução". Sobre essa hospedagem incide o indicador de disponibilidade do sistema.

A Contratada deverá prover, para a CONTRATANTE, mecanismos de monitoração das métricas dos serviços disponibilizados, tais como:

a) Tempo de indisponibilidade do sistema;

b) Percentagem de disponibilidade do serviço.

As paradas programadas para as manutenções do sistema deverão ser previamente acordadas com a CONTRATANTE, sendo desconsideradas do cálculo do SLA no que tange à disponibilidade do sistema.

Observação: Cálculo do valor a ser pago pela mensalidade referente ao item III do objeto do contrato será aferido considerando o valor da mensalidade subtraindo-se o somatório das sanções apuradas pelo ISUT e pelo IDHS.

IDENTIFICAÇÃO DOS ENTREGÁVEIS E A INCIDÊNCIA DOS NÍVEIS DE SERVIÇOS ACORDADOS CORRESPONDENTES

Itens I e II do objeto:

Quadro 17 – Anexo VI: Indicadores das Entregas dos itens I e II do objeto

Atividades

Produto

Indicadores Aplicados

Planejamento

Plano de Projeto Aprovado

ICPM

Aprovação, pelo CONTRATANTE, do Plano de Projeto - Deliberação da Linha de Base – LB 1

Mapeamento

Documento com o registro do Processo (to be) e parâmetros validados; Documento com oportunidade de melhorias.

ICPM

Disponibilização da solução em ambiente de treinamento e homologação

ICPM

Customizações e parametrizações

Solução customizada e parametrizada

ICPM

Integrações

Solução integrada

ICPM

Importação de Dados - povoamento das tabelas genéricas

Tabelas genéricas povoadas

ICPM

Treinamento

Treinamento realizado

ICPM IST

Disponibilização das licenças em produção

A solução em produção disponibilizada

ICPM IDHS

Operação assistida

A solução em produção disponibilizada e operação assistida concluída

ICPM ISUT

Solução plenamente implantada

Unidades em pleno funcionamento da solução

ICPM

Total

Item I do objeto:

Sobre as mensalidades do Item I do objeto aplicam-se os indicadores ICPM, IDS, IDHS e ISUT conforme definido neste anexo.

Item III do objeto:

Sobre o valor das ordens de Serviço do Item III do objeto aplicam-se os indicadores ICPM e IDS conforme definido neste anexo.

Itens IV e V do objeto:

Sobre o valor das ordens de Serviço do Item IV aplicam-se os indicadores ICPM, IDHS e ISUT conforme definido neste anexo.

ANEXO VII TREINAMENTO

A CONTRATADA deverá apresentar à CONTRATANTE, na oportunidade acordada (linha de base), uma proposta de treinamento PRESENCIAL e opcionalmente REMOTO, a critério da CONTRATANTE, na hipótese de qualquer impedimento para o treinamento presencial.

Adicionalmente a CONTRATADA deverá elaborar treinamento para auto estudo e sem tutoria – EaD, em plataforma web, para o usuário final, em português, considerando todas as funcionalidades e módulos contratados e implantados.

Treinamento presencial

O treinamento presencial será realizado nos prazos acordados, fornecendo antecipadamente, em meio digital e em formato editável, o material didático, respeitando as seguintes orientações:

a) material didático para treinamento, em português e garantindo o direito autoral de terceiros;

b) apresentação do sistema e tutoriais em vídeos e outros recursos áudio visuais, em português, disponíveis em plataforma EAD;

c) o material didático deverá conter todas as informações, os testes, os exemplos, a documentação técnica e os exercícios necessários ao bom acompanhamento das aulas, dispensando a utilização de qualquer outra bibliografia de apoio;

d) material didático deve ser validado pela CONTRATANTE;

e) entrega do material em meio digital e sem limitação de uso pela CONTRATANTE, durante a vigência do contrato.

A proposta de Treinamento Presencial será aceita após atender aos seguintes requisitos:

a) abranger os três segmentos de público-alvo:

●Administradores, parametrizadores e auditores do sistema: usuários donos do negócio e responsáveis pelas padronizações que serão aplicadas no sistema.

●Usuário final que utilizará o sistema na Central do SAMU, inclusive equipes móveis e gestores.

● Usuário final das unidades hospitalares de referência para pronto atendimento nas funcionalidades relacionadas à atualização das condições operacionais de atendimento (leitos de urgência disponíveis, composição das equipes, situação de equipamentos e outros recursos que podem impactar na capacidade de atendimento).

b) Conter os seguintes tópicos:

●conteúdo do curso/treinamento que deverá ser apresentado de forma detalhada, especificando os assuntos que serão estudados e a carga horária, adequados para cada segmento de público-alvo.

●A cada assunto especificado no conteúdo programático, será atribuída uma carga horária específica, pré-requisito e perfil recomendado para os alunos.

c) Apresentar cronograma e proposta de organização de treinamentos presenciais considerando os seguintes horários:

●O treinamento presencial dos usuários finais do SAMU deverá ocorrer no horário de 07:00 às 23:00 de forma a atender os profissionais dos turnos noturno e diurno, o qual justifica o horário amplo para o treinamento, em turmas com no máximo 10 pessoas, em local disponibilizado pelas SMSA´s.

A proposta de treinamento presencial deverá ser aplicada em situação de simulação da situação real de trabalho nos respectivos módulos.

Administradores/parametrizadores/auditores

●A Proposta de Treinamento Presencial destinada aos administradores/ parametrizadores/ auditores indicados pela CONTRATANTE, tem como objetivo prepará-los para parametrização, configuração e monitoração da Solução. Esse treinamento deverá ser ministrado a até 30 (trinta) profissionais da CONTRATANTE.

Usuário final

●A Proposta de Treinamento Presencial destinado ao usuário final tem como objetivo prepará-los para operar de forma plena a Solução, de modo a utilizar todos os recursos existentes em cada módulo, de acordo com sua área de atuação, e deve capacitar o número estimado de usuários, conforme descrito no Quadro 3 - Projeto Básico: Escopo e Volumetria do Projeto do item Nº de usuários para fins de treinamento.

A CONTRATADA deverá disponibilizar o ambiente de treinamento da solução, considerando sua instalação e configuração.

O CRONOGRAMA e a formação das turmas dos treinamentos presenciais serão acordados com a CONTRATANTE.

Será de responsabilidade da CONTRATANTE a montagem das salas de treinamento, contendo estações locais, mobiliário e estrutura lógica e elétrica necessárias ao treinamento.

Para cada treinamento presencial realizado, a CONTRATADA deverá emitir lista de presença contendo no mínimo, título do treinamento, público-alvo, carga horária, período da realização e identificação do treinando, unidade e setor, com sua assinatura confirmando a presença.

A CONTRATANTE fará a avaliação do grau de satisfação dos treinamentos, num processo a ser definido em tempo de projeto.

Na conclusão satisfatória do Treinamento Presencial, a CONTRATANTE emitirá um Termo de Aceite/Recebimento de Treinamento Presencial.

Modalidade treinamento remoto

A CONTRATADA deverá oferecer treinamento remoto a ser utilizado em substituição ao presencial, a critério da CONTRATANTE. Esse treinamento será realizado contemplando:

a) Disponibilização de vídeos da solução por processos, grupos funcionais ou perfis de usuário (por exemplo, teledigifonistas, reguladores, administradores, equipe móvel, etc.).

b) Apresentação virtual do sistema de forma síncrona para turmas de até 20 pessoas com possibilidade de esclarecimento de dúvidas, no horário de 07:00 às 21:00 horas.

c) Disponibilização de acesso ao ambiente de treinamento para simulação orientada por roteiro.

d) Disponibilização de suporte ao treinando por meio de sala de treinamento virtual com compartilhamento de tela e também por e-mail e por telefone, no horário de 07:00 às 21:00 para usuários finais do SAMU e em horário comercial para os demais públicos alvo.

e) Todos os softwares necessários devem ser disponibilizados pela CONTRATADA sem custos adicionais.

f) A chamada telefônica deve ser sem custos para a CONTRATANTE.

Ensino a Distância - EAD

Adicionalmente ao treinamento presencial e/ou remoto para fins de implantação, a CONTRATADA deverá elaborar treinamento para autoestudo e sem tutoria – EaD, para o usuário final, em português, considerando todas as funcionalidades e módulos contratados e implantados. Este tipo de treinamento será fornecido em plataforma web a ser mantido pela CONTRATADA durante a vigência do contrato.

O acesso ao conteúdo na condição EaD deverá ficar disponível durante a vigência do contrato, abrangendo os quatro seguintes segmentos de público-alvo:

a) Administradores, parametrizadores e auditores.

b) Usuário final que utilizará o sistema no SAMU, inclusive equipes móveis e gestores.

c) Usuário final das unidades hospitalares de referência em pronto atendimento nas funcionalidades relacionadas à atualização das condições operacionais de atendimento (leitos de urgência disponíveis, composição das equipes, situação de equipamentos e outros recursos que podem impactar na capacidade de atendimento).

Durante a vigência do contrato o conteúdo da modalidade EaD deve ser mantido atualizado, repercutindo a atualização de versão da solução tecnológica adquirida.

Quadro 18 - Anexo VII: Resumo das modalidades de treinamento por segmento de público-alvo

Público alvo

Presencial (até 10 pessoas/ turma) OU Remoto (até 20 pessoas/ turma)

EAD

Nº estimado de usuários para fins de treinamento

Administradores, parametrizadores e auditores

Sim

Usuário final SAMU e gestores

Sim

800

Usuário final unidades hospitalares de referência nas funcionalidades relacionadas à atualização de leitos, equipes, etc.

Sim

Total

890

DECLARAÇÃO DE PROPRIEDADE E PERMISSÃO DE COMERCIALIZAÇÃO

[MODELO]

Ao Consórcio Intermunicipal Aliança para a Saúde - CIAS Diretoria de Compras

Pregão /2023

Objeto: Contratação de serviço de locação de solução integrada para o Serviço de Atendimento Móvel de Urgência (SAMU) incluindo a locação de software para atender aos usuários simultâneos e unidades especificadas, serviços técnicos especializados (STE) de implantação, suporte técnico, manutenção das licenças, hospedagem da solução, solução de integração com a comunicação híbrida {satélite e celular (Multi-operadora)}.

Prezados Senhores,

O (LICITANTE), (qualificação), por meio de seu representante legal, declara que:

● É a fabricante ou detentora dos direitos autorais e de propriedade intelectual da solução ofertada neste certame; ou,

● É autorizada ou sub-licenciada pelo fabricante a comercializar serviço de locação da solução ofertada neste certame; ou,

● E credenciada pelo Fabricante como agente integrador ou implementador capacitado a prover os serviços objeto desta licitação.

Local:

Data:

Representante Legal: RG:

CPF:

DECLARAÇÃO DE COMPROMISSO

Ao Consórcio Intermunicipal Aliança para a Saúde - CIAS Diretoria de Compras

Pregão /2023

Prezados Senhores,

O (PROPONENTE), (qualificação), por meio de seu representante legal, declara que a tecnologia ofertada para atender ao objeto supracitado tem plena condição para atender a todos os requisitos funcionais e não funcionais, considerando o escopo da implantação descritos no Termo de Referência – TR/Projeto Básico e seus Anexos, em tempo de projeto.

Assume, também, que ofertará sempre a última versão homologada da Solução, inclusive para os seus agrupamentos internos (módulos ou similar), no decorrer do projeto e nos momentos de decisão sobre a solução a ser adotada.

Local:

Data:

Representante Legal: RG:

CPF:

ANEXO X

MINUTA DE CONTRATO – IMPLANTAÇÃO DO PROJETO BÁSICO

Contrato de prestação de serviços que entre si celebram o Consórcio Intermunicipal Aliança para a Saúde – CIAS e a empresa

...............................................................

O CIAS,, CNPJ 97.550.393/0001-49, neste ato representado pelo(a) Secretário

(a)Executivo , doravante denominado Contratante e a empresa

....................................................................................................................................................................

estabelecida ........................................, CNPJ ,

representada por , neste ato denominada Contratada, celebram o presente contrato,

decorrente do pregão eletrônico nº 00/2023, processo administrativo 00.000000.00.00, e em conformidade com os Decretos Municipais nº 12.436/2006, nº 12.437/2006, nº 15.113/2013, nº 15.185/2013, 16.603/2017, 16.736/2017 e nº 16.871/2018 que alteram o Decreto 10.710/2001 e com as Leis Federais n° 8.666/93 enº 10.520/2002, mediante as seguintes cláusulas e condições:

CLÁUSULA PRIMEIRA: DO OBJETO

O objeto contempla:

VII.Serviço de locação de solução integrada de SAMU para atender aos usuários simultâneos e unidades especificadas no Quadro 3 - Projeto Básico: Volumetria do Projeto, incluindo:

e) Fornecimento de licenças de uso do software

f) Suporte técnico ao usuário

g) Hospedagem da solução

h) Integração com o serviço de comunicação híbrida {satélite e celular/tablet (Multi-operadora)}

VIII.Serviços Técnicos Especializados de implantação para cobrir o escopo descrito no Quadro 3 - Projeto Básico: Escopo e Volumetria do Projeto incluindo:

f) Mapeamento e desenho (as is) dos processos, subprocessos e atividades existentes, analisar e indicar melhorias. Elaborar Plano de Implantação dos Processos (to be) estabelecendo relação entre processos/subprocessos e atividades com módulos/componentes/funcionalidades, comandos e parâmetros (orientações para a implantação) da solução.

g) Parametrizações, customizações e integrações necessárias à efetiva entrada em produção de todos os requisitos funcionais e não funcionais.

h) Importação de Dados: serviço de carga de dados para as tabelas auxiliares e básicas necessárias ao funcionamento pleno da solução.

i) Disponibilização dos ambientes de homologação e de treinamento. Estes ambientes devem ser suficientes para aprovação das funcionalidades pelos usuários.

j) Implantação nas unidades de saúde especificadas no Quadro 3 - Projeto Básico: Volumetria do Projeto.

● Operação assistida na central do SAMU e nos serviços de pronto atendimento dos hospitais de referência, conforme especificado no Quadro 3 - Projeto Básico: Escopo e Volumetria do Projeto.

IX.Serviços adicionais - Pontos de Função: serviços adicionais para desenvolvimento e evolução da solução para atender a necessidades futuras, distintas daquelas previstas neste Edital, executados por meio de Pontos de Função a serem mensurados pela CONTRATADA e validados e autorizados pela CONTRATANTE mediante Ordem de Serviço, até o limite de 500 (quinhentos) Pontos de Função.

X.Serviços adicionais por incremento de veículos do SAMU do município de Belo Horizonte: serviços adicionais para garantir o uso da solução, caso haja aumento no nº de veículos do SAMU, incluindo licenças, treinamento, parametrizações, configurações, bem como a sustentação, suporte aos usuários, executados por meio da unidade de custos veículo mês (total de veículos incrementados multiplicado pelo total de meses de utilização), até o limite de 420 unidades de custo veículos mês, autorizados mediante Ordem de Serviço. Por exemplo, o incremento de 5 veículos em 10 meses equivaleria ao consumo de 50 unidades de custo veículo mês.

Document Metadata

Table of Contents

TERMO DE REFERÊNCIA

Document Metadata