ministÉrio da saÚde secretaria executiva...

de 35

MINISTÉRIO DA SAÚDE

SECRETARIA EXECUTIVA DEPARTAMENTO DE INFORMÁTICA DO SUS - DATASUS

Esplanada dos Ministérios, Bloco G, Anexo A, sala 107 Brasília DF CEP 70058-900

Telefones (61) 3315-2796/2166 – Fax: 3315-2774 e-mail: [email protected]

RESPOSTA DO MINISTÉRIO DA SAÚDE AOS COMENTÁRIOS APRESENTADOS NA CONSULTA PÚBLICA

DO OBJETO (Item da Minuta do Termo de Referência)

Data: 24/07/2009 Comentário 1: Objeto inadequado as necessidades dos hospitais. Justificativa: Enquanto os hospitais objeto da contratação necessitam de um amplo projeto de gestão e ordenamento da assistência, com ferramentas gerenciais capazes de otimizar o uso dos recursos disponíveis e evitar os desperdícios, o Termo de Referência traz um compêndio de informações voltadas para o desenvolvimento e testes de sistemas a serem desenvolvidos, além de não incluir em seu escopo, módulos e funcionalidades fundamentais para a gestão. Contrário a isto, o próprio Governo Federal, atento a necessidade de modernização destes hospitais lançou o Decreto Presidencial que cria os hospitais estratégicos, garantindo a isenção de tributos para seis diferenciados hospitais brasileiros com o compromisso destes em apoiar a modernização gerencial dos seis hospitais pertencentes ao Ministério da Saúde, no Rio de Janeiro.

Resposta do MS ao comentário 1: O Ministério da Saúde entende que o objeto está adequado as necessidades dos Hospitais por: • Não se tratar de desenvolvimento de software e sim de aquisição de sistema pronto

conforme especificações contidas no Anexo A do Termo de Referência; • Nestas especificações estão contemplados alguns módulos que apóiam a gestão, e outros

serão acrescentados, acatando assim a sugestão de outros comentários descritos abaixo; • Os Hospitais Estratégicos/Excelência, instituídos por decreto presidencial, já se encontram

inseridos no Projeto de Reestruturação e Qualificação dos HFRJ realizando consultoria no diagnóstico dos principais processos para a sua otimização, que servirão de base para as adaptações necessárias;

• A utilização de ferramentas de TI, apesar da sua inquestionável importância, representa parte das ações do Ministério nos Hospitais Federais do Rio de Janeiro, e como tal está inserida num contexto mais amplo.

Não se trata de contratação de serviços para desenvolvimento de software, o objeto do presente termo de referência é “AQUISIÇÃO DE SOLUÇÃO DE INFORMAÇÃO HOSPITALAR INTEGRADA AO SISTEMA DE REGISTRO ELETRÔNICO DE SAÚDE PARA ATENÇÃO INTEGRAL (RES-AI) COM IMPLANTAÇÃO NOS SEIS (6) HOSPITAIS FEDERAIS DO RIO DE JANEIRO”, portanto trata-se de aquisição de sistema (software) pronto para o uso, com transferência de tecnologia e propriedade intelectual, cujas especificações estão detalhadas no Apêndice A.

de 35

A aquisição do sistema contempla a transferência de tecnologia para o Ministério da Saúde que será realizada através da capacitação, integração com sistemas legados e implantação nos 6 (seis) hospitais federais do Rio de Janeiro. Os serviços necessários estão descritos neste termo de referência e deverão ser realizados num prazo máximo de 12 meses.

A responsabilidade que o Ministério da Saúde detém como gestor das unidades hospitalares em questão e da constante necessidade de que elas atuem conforme as regras e organização do SUS, além de assumirem o papel estratégico de apoio ao sistema com o desenvolvimento de estratégias inovadoras do ponto de vista assistencial e gerencial, justificam a deliberação, incluída nas ações prioritárias do Mais Saúde (Planejamento Estratégico do MS para 2008-2011), pela reestruturação e qualificação da gestão dos hospitais federais do Rio de Janeiro, agregando diversas iniciativas no sentido de modernizar e fortalecer o conjunto de unidades assistenciais federais e inseri-las na rede de assistência em saúde do Rio de Janeiro. Assim, ações de reestruturação física e de processos gerenciais serão implementadas para preparar tais unidades para assumir o papel estratégico para o SUS. Através da parceria com alguns hospitais de excelência já deu início a incorporação na gestão de métodos mais eficientes e modernos, conforme os princípios que o SUS e a administração pública prevêem, ampliando assim a qualidade gerencial e assistencial dos hospitais.

Dentre as ações prioritárias previstas estão a implantação da rede lógica, elétrica e sem fio, a reestruturação com a ampliação de seus parques computacionais e a implantação de um Sistema de Informação Hospitalar baseado no Registro Eletrônico de Saúde. Um Sistema de Informação Hospitalar (SIH) deve, em princípio, otimizar a gestão da informação e, por conseqüência, a gestão organizacional dos processos de administração, atenção e assistência à saúde, além de possibilitar a integração com sistemas de informação externos ligados à rede assistencial de saúde onde estes hospitais estão inseridos. No entanto, os sistemas informatizados implantados nos hospitais brasileiros visaram, até o momento, atender essencialmente aspectos administrativos internos, com pouca ou nenhuma visão de rede assistencial. Relegaram ao segundo plano as informações clínicas dos indivíduos que compõem o Registro Eletrônico Individual de Saúde (RES), e na sua maioria, coletam informações clínicas visando essencialmente atender objetivos financeiros, gerando um registro clínico eletrônico fragmentado e desintegrado. O sistema pretendido deverá estar centrado no Registro Eletrônico de Saúde (RES) e não apenas em informações administrativas, uma vez que a ausência de informações individuais de saúde tem gerado grande desperdício de recursos financeiros e humanos, agravando a ineficiência dos sistemas de saúde. Atualmente a implantação de Registro Eletrônico de Saúde para a Atenção Integral (RES-AI) de forma ampla e interoperável é prioridade em todos os países desenvolvidos, uma vez que maioria das informações que geram os principais indicadores gerenciais é obtida no momento do atendimento dos indivíduos pelos diversos profissionais de saúde.

Neste sentido, o presente termo de referência visa estruturar um sistema de informação que garanta uma base de dados para informações gerenciais tanto clínicas, epidemiológicas, como administrativas. Não se desconsidera, nesta aquisição, a importância da gestão como objetivo primordial, apenas posiciona o Registro Eletrônico de Saúde (RES) como o principal módulo para a gestão e integração no SUS. Pelos motivos expostos o comentário é considerado improcedente.

de 35

Data: 24/07/2009

Comentário 2: Item 1.1.1. – Ao solicitar o desenvolvimento através de código-fonte aberto e transferência de propriedade intelectual o ministério da saúde limitará o desenvolvimento a empresas focadas exclusivamente em desenvolvimento de softwares excluindo todos os fornecedores de sistemas “prontos”, os pacotes, que possam atender aos requisitos sistêmicos. Justificativa: Justificativa para plataforma livre. Este é um tema altamente questionável, pois de um lado existe a transferência de conhecimento e a “liberdade” de desenvolvimento, porém a médio e longo prazo a equipe do ministério terá que investir em atualização tecnológica, treinamento e uma equipe exclusiva para a manutenção e evolução do produto. Entendemos que um sistema de classe mundial traz em seus conceitos a atualização constante das melhores práticas em atendimento na indústria de saúde ao redor do mundo, portanto ao restringir as desenvolvedoras dos chamados “pacotes” o ministério da saúde abrirá mão do avanço tecnológico e conceitual contido nestes sistemas.

Resposta do MS ao comentário 2: As justificativas para adoção de padrões abertos são as seguintes (em conformidade com a EGTI/SLTI/MPOG – 20/11/2008):

1. Reforço da autonomia da Administração Pública quanto aos sistemas informatizados; 2. Aderência ao projeto de migração para adoção de plataformas de código aberto nos

sistemas digitais, em todos os setores da Administração Federal, em consonância com as diretrizes do Ministério do Planejamento, Orçamento e Gestão;

3. Compartilhamento do sistema no Portal de Software Público e fomentar a criação de uma comunidade para aprimoramento contínuo do produto;

4. Aumento do ciclo de vida do software adquirido através da utilização do Código Aberto, trazendo maior eficiência na utilização dos recursos públicos.

5. Diminuir o custo para a administração pública nos processos de informatização de suas unidades de saúde.

As recomendações de uso de sessão de códigos fontes e transferência tecnológica são compatíveis com a visão e a proposta do Governo Federal de inclusão digital e distribuição de tecnologias para o SUS. É estratégico para o país avançar na absorção de novas tecnologias, e esta aquisição é uma oportunidade concreta para que o Ministério da Saúde contribua na solidificação desta estratégia. O país passa por processo de estímulo à difusão do conhecimento e ao desenvolvimento tecnológico, no qual o uso de código fonte aberto propicia a criação de ambientes de desenvolvimento integrados, distribuídos e de livre acesso à população das diversas áreas do país. Um sistema de informação de saúde pública, além de estar alinhado às melhores práticas, fomenta o desenvolvimento do país. Custos de Software Livre/Código Aberto estão associados aos serviços prestados e não ao uso de licenças. Uma dada solução em SL/CA parametrizada/customizada para uma Administração Pública pode ser livremente transferida para outras organizações públicas interessadas, resultando em economia de recursos e redução do uso de softwares ilegais (por exemplo: softwares cuja licença de uso não tenha sido adquirida). Como o código-fonte da solução em SL/CA é prontamente disponível, qualquer fornecedor de software pode suportá-lo. Vide item 2-Justificativa e item 3.1-Gerais do Termo de Referência. Pelos motivos expostos o comentário é considerado improcedente.

Data: 24/07/2009 Comentário 3: Integração com sistemas legados – Entendimento do Termo e Referência.

de 35

Justificativa: 1.1.2 E Serviços Técnicos Especializados não continuados de transferência de tecnologia (capacitação, Manuais e Mapeamentos dos Macro-Processos), de Implantação (Planejamento e Implantação, Parametrização, Customização, Migração e Integração de Sistemas Legados) e de Sustentação à operação ao Sistema de Registro Eletrônico de Saúde para atenção integral (RES-AI) nos 6 (seis) Hospitais Federais do Rio de Janeiro, cujas estruturas constam no Apendice B, parte integrante deste Termo de Referência. Conforme o texto acima, entendemos que a integração de sistemas legados envolve apenas o sistema que hora está sendo adquirido e o sistema existente. Qualquer integração que não envolva a integração entre o RES-AI e o (HOSPUB) está fora do escopo desse projeto. Está correto nosso entendimento?

Resposta do MS ao comentário 3: A integração será essencialmente com as funcionalidades do HOSPUB, mas não exclusivamente com este. O objeto prevê que o sistema adquirido poderá e deverá ser integrados com outros sistemas públicos e atualmente utilizados pelos hospitais federais. Integrados e não necessariamente “incorporados” ou “redesenvolvidos”. Como o sistema pretendido, necessariamente estará em plataforma web, serão disponibilizados serviços de troca dinâmica de dados e funções de interoperabilidade, para que seja possível um baixo acoplamento entre os sistemas, permitindo assim a reutilização de sistemas já implantados nos diversos ambientes. O Quadro 1 da minuta do termo de referência estabelece os limites a serem utilizadas no processo de integração de sistemas, e demais serviços. O Ministério da Saúde estabelecerá as prioridades para as integrações com sistemas legados, considerando aqueles que sejam fundamentais para o perfeito funcionamento da solução a ser implantada. O entendimento não é correto.

DA JUSTIFICATIVA (Item da Minuta do Termo de Referência)

Data: 14/07/2009 Comentário 4: No final da página 6 e início da página 7, é citado que "os hospitais não dispõem de uma infra-estrutura básica de equipamentos ligados em rede". Não sei se na época deste levantamento a situação era essa, mas hoje isso já está bem diferente.Justificativa: Com a entrada do DATASUS criando núcleos de TI nos hospitais, essa situação está diferente, já existem estruturas básicas de redes e até algum parque de máquinas, ainda existem deficiências, como a velocidade do link de INTERNET, mas já temos e-mail, o HOSPUB já está implantado e interligado em rede, etc.

Resposta do MS ao comentário 4: Esta afirmação foi realizada pelo DGH em 2006, conforme descrito na Justificativa do Termo de Referência, visando contextualizar a situação dos Hospitais Federais. Assim não poderá ser alterada. Porém cabe salientar que o cenário tecnológico de infra-estrutura dos hospitais federais vem obtendo melhorias com as ações realizadas pelo Ministério da Saúde. Outras ações estão em andamento a fim de preparar e suportar o avanço na utilização de sistemas de informação mais adequados. Vide Minuta do Termo de Referência - Item 2 - Justificativa página 7: Ações de infra-estrutura. Data: 24/07/2009

de 35

Comentário 5: Disponibilidade sem custos para o Ministério da Saúde de solução similar.Justificativa: Desconhecimento desse Departamento no que tange, à “Disponibilidade sem custos para o Ministério da Saúde de solução similar em outro órgão ou entidade da Administração Pública Federal”, conforme se encontra insculpido nas Alíneas “a”, “b” e “c” do Art. 10 da I.N. (MPOG) Nº 04/2008, vez que, observada, constatar-se-ia a existência de solução de TI em pleno atendimento a todas as necessidades de instituições de saúde do próprio Ministério da Saúde, dentre elas, o INC/MS/RJ e INTO/MS/RJ, este que é o Único Hospital Público do Brasil com Acreditação Internacional cujo certificado é fornecido pela Joint Commission International. Perguntamos então como é possível o Ministério pagar novamente por um produto que já está disponível, pago e em perfeito funcionamento em 2 Hospitais Federais aqui já nomeados (INC/MS/RJ e INTO/MS/RJ), ambos localizados no mesmo Estado para onde se almeja as novas implantações, bastando para isto apenas uma solicitação de cessão do direito de uso das licenças, gerando assim uma enorme economia financeira aos cofres públicos.

Resposta do MS ao comentário 5: O Ministério da Saúde não desconhece o que determinada a IN-04 SLTI/MPOG, equivocadamente transcrita na Justificativa acima. O presente termo de referência não tem por objeto à aquisição de licenças de uso, e sim, a aquisição da propriedade intelectual, com a conseqüente independência na utilização do sistema adquirido (em conformidade com o art.111 da Lei 8.666/93 e com a Estratégia Geral de TI – EGTI, publicado em 20/11/2008). Esta aquisição permitirá a possibilidade de distribuição gratuita para outras unidades de saúde do SUS. O projeto de informatização dos hospitais do Rio de Janeiro está dentro de um contexto maior proposto pelo Ministério da Saúde quanto à estruturação da atenção à saúde em redes e territórios assistenciais. Neste sentido, para que seja possível a replicação deste projeto no âmbito do SUS, é necessária a utilização de tecnologias em plataformas abertas, desenvolvimento nativo para a Internet, alta escalabilidade, facilidade de manutenção e menor custo de implantação em escala. Para a elaboração deste termo de referência foi consultado o Portal Público Brasileiro de Software, como determina a IN 04/2008 da SLTI/MPOG, onde não há solução pública que atenda os requisitos deste termo de referência. Este referido portal é uma oportunidade para que detentores de softwares possam nele depositar os seus produtos e assim disponibilizá-los para a comunidade brasileira sem custos de propriedade. Vale ressaltar que este é um dos alicerces que norteiam esta aquisição. Importa ressaltar que o objetivo desta aquisição é mais amplo que informatizar os processos internos dos Hospitais Federais, mas o de sim disponibilizar um sistema em plataforma livre que permita a integração das informações clínicas individuais com os diversos estabelecimentos de saúde a eles relacionados, desta forma contribuindo concretamente na sua integração em redes/territórios de saúde, os quais estão inseridos. Ao ensejo cabe fazer uma relevante distinção: um software doado mesmo sem qualquer custo, não traz consigo o direito de alterar e customizá-lo segundo as conveniências da Administração Pública. Se fosse assim, não haveria diferença entre a doação livre, com entrega de códigos fontes e direitos autorais. São questões juridicamente diferentes. O fato de estar em uso e até admitirmos que o fornecedor doe o software não significa que atenda os interesses mais amplos ora propostos. O texto da IN 04/MPOG, citado neste comentário, é corretamente transcrito abaixo.

de 35

“IV - identificação por parte da Área de Tecnologia da Informação, com participação do Requisitante do Serviço, das diferentes soluções que atendam às necessidades, considerando: a) disponibilidade de solução similar em outro órgão ou entidade da Administração Pública Federal; b) soluções existentes no Portal do Software Público Brasileiro (http://www.softwarepublico.gov.br); c) capacidade e alternativas do mercado, inclusive a existência de software livre ou software público; d) observância às políticas, premissas e especificações técnicas definidas pelos Padrões de Interoperabilidade de Governo Eletrônico - e-PING e Modelo de Acessibilidade em Governo Eletrônico - e-MAG, conforme as Portarias Normativas SLTI nº 5, de 14 de julho de 2005, e nº 3, de 07 de maio de 2007; e) aderência às regulamentações da Infra-estrutura de Chaves Públicas Brasileira - ICP-Brasil, conforme a Medida Provisória nº 2.200-2, de 24 de agosto de 2001, quando houver necessidade de utilização de certificação digital; e f) custo financeiro estimado;”

DOS RESULTADOS ESPERADOS (Item da Minuta do Termo de Referência)

Data: 24/07/2009 Comentário 6: Um dos itens especificados no texto é: Oferecer ao gestor dos hospitais um sistema de informações integrado de apoio à gestão. Entretanto não está na lista de requisitos um módulo que forneça indicadores específicos e de verificação. Justificativa: Considerando-se o processo de acreditação é essencial que esteja previsto no sistema o acompanhamento através de indicadores, tais como os indicadores do Sistema Integrado de Indicadores Hospitalares ANAHP.

Resposta do MS ao comentário 6: O SUS tem como premissa a implementação de indicadores amplos e relacionados com a Atenção Integral à Saúde. A aquisição pretendida prevê a formação de uma base de dados estruturada que dará suporte à criação de indicadores gerenciais estáticos e dinâmicos, sejam clínicos, administrativos, sociais e financeiros. Como o sistema pretendido, necessariamente estará em plataforma web, serão disponibilizados serviços de troca dinâmica de dados e funções de interoperabilidade, para que seja possível um baixo acoplamento entre os sistemas, permitido assim a reutilização de sistemas maduros e diferentes nos diversos ambientes, e integração com sistemas e funcionalidades específicas. Comentário pertinente e já previsto nos requisitos do Termo de Referência.

DO MODELO DE LICITAÇÃO ADOTADO (Item da Minuta do Termo de Referência)

Data: 24/07/2009 Comentário 7: Escolha inadequada da modalidade licitação (Pregão Eletrônico). Justificativa: A escolha da modalidade Pregão Eletrônico para, sic, “Aquisição de SOLUÇÃO DE INFORMAÇÃO HOSPITALAR INTEGRADA AO SISTEMA DE REGISTRO ELETRÔNICO

de 35

DE SAÚDE PARA ATENÇÃO INTEGRAL (RES-AI) compreende: FORNECIMENTO, com Transferência de Tecnologia e de Propriedade Intelectual, de SISTEMA DE REGISTRO ELETRÔNICO DE SAÚDE (RES) INTEGRADO AO SISTEMA DE GESTÃO HOSPITALAR, exclusivamente em ambiente WEB, utilizando servidor de aplicação e servidor de banco de dados em CÓDIGO- FONTE ABERTO, visando a integração com o HOSPUB e seu aprimoramento,... e SERVIÇOS TÉCNICOS ESPECIALIZADOS NÃO CONTINUADOS de TRANSFERÊNCIA DE TECNOLOGIA (Capacitação, Manuais e Mapeamentos dos Macro-Processos), de IMPLANTAÇÃO (Planejamento e Implantação, Parametrização, Customização, Migração e Integração de Sistemas Legados) e de SUSTENTAÇÃO A OPERAÇÃO AO SISTEMA DE REGISTRO ELETRÔNICO DE SAÚDE PARA ATENÇÃO INTEGRAL (RES-AI) nos 6 (seis) Hospitais Federais do Rio de Janeiro...” afronta, sob o ponto de vista legal, o Parágrafo Único do Art. 1º da Lei Nº 10.520/2002 c/c o ANEXO II (CLASSIFICAÇÃO DE BENS E SERVIÇOS COMUNS) do Decreto Nº 3.555. Robustecendo estes mesmos argumentos, resta salientar, que o objeto licitado, software de grande complexidade, a exigir 410.000 (quatrocentos e dez mil horas) de trabalho a serem distribuídas apenas em customizações, implantação e operação assistida, >> não é objeto comum conforme definido na lei. É objeto complexo, que não admite licitação via Pregão Eletrônico. << Não é de nosso desconhecer, que existem softwares, os famosos softwares de prateleira, que por sua própria natureza, admitem o pretendido neste processo, o que não é o caso do objeto licitado. Não é por demais frisar, que este, é igualmente o entendimento de nossos tribunais, dentre eles, o próprio Tribunal de Contas da União.

Resposta do MS ao comentário 7: O primeiro ponto diz respeito ao uso do pregão. O ponto cerne para elidir a questão não está na identificação de software ser de “prateleira” ou não como se pretende colocar. A possibilidade de licitação por pregão – e a diretriz sempre reforçada pelo TCU para o uso dessa modalidade – consiste em decidir se o objeto pretendido pode ou não ser objetivamente definido pelo edital, com base em especificações usuais no mercado. “Especificações usuais do mercado” é precisamente possibilitar ao mercado reconhecer o objeto, definir a possibilidade de realizá-lo ou não e apresentar uma estrutura de custos adequados, para apresentar a proposta. Quando se determina “especificações usuais no mercado” não significa que está completamente afastada a complexidade, mas que o “mercado” fornecedor está apto a reconhecer o produto, identificar a característica e oferecer a proposta. Na doutrina, diversos autores esclarecem que a norma definiu o que deve ser entendido por comum, acrescentado o entendimento do TCU em dois acórdãos: 817/2005 – Plenário, da lavra do Ministro Valmir Campelo, e 165/2003, também do Plenário, da lavra do Ministro Benjamim Zymler. Nesse último, a lição que fica é que o conceito é genérico, dinâmico e relativo. Esclareceu o Ministro que se entende por dinâmico o fato de depender de o mercado ser capaz de identificar especificações usuais. Neste Termo de Referência, a solução pretendida, embora eventualmente necessite de adaptações pontuais e específicas, é passível de ser desenvolvida por qualquer empresa especializada na área de desenvolvimento de softwares, mercado amplamente competitivo. Nesse caso, não é permitido à Administração optar por outra modalidade de licitação que não a do pregão, sob a forma eletrônica. A respeito, o Tribunal de Contas da União já assentou entendimento em célebre Acórdão nº 2471/2008-Plenário:

de 35

“9.2.1. A licitação de bens e serviços de tecnologia da informação considerados comuns, ou seja, aqueles que possuam padrões de desempenho e de qualidade objetivamente definidos pelo edital, com base em especificações usuais no mercado, deve ser obrigatoriamente realizada pela modalidade Pregão, preferencialmente na forma eletrônica. Quando, eventualmente, não for viável utilizar essa forma, deverá ser anexada a justificativa correspondente (Lei nº 10.520/2002, art. 1º; Lei nº 8.248/1991, art. 3º, § 3º; Decreto nº 3.555/2000, anexo II; Decreto nº 5.450/2005, art. 4º, e Acórdão nº 1.547/2004 - Primeira Câmara); 9.2.2. Devido à padronização existente no mercado, os bens e serviços de tecnologia da informação geralmente atendem a protocolos, métodos e técnicas pré-estabelecidos e conhecidos e a padrões de desempenho e qualidade que podem ser objetivamente definidos por meio de especificações usuais no mercado. Logo, via de regra, esses bens e serviços devem ser considerados comuns para fins de utilização da modalidade Pregão (Lei nº 10.520/2002, art. 1º); 9.2.3. Bens e serviços de TI cuja natureza seja predominantemente intelectual não podem ser licitados por meio de pregão. Tal natureza é típica daqueles serviços em que a arte e a racionalidade humanas são essenciais para sua execução satisfatória. Não se trata, pois, de tarefas que possam ser executadas mecanicamente ou segundo protocolos, métodos e técnicas pré-estabelecidos e conhecidos; 9.2.4. Em geral, nem a complexidade dos bens ou serviços de tecnologia da informação nem o fato de eles serem críticos para a consecução das atividades dos entes da Administração descaracterizam a padronização com que tais objetos são usualmente comercializados no mercado. Logo, nem essa complexidade nem a relevância desses bens justificam o afastamento da obrigatoriedade de se licitar pela modalidade Pregão (Lei nº 10.520/2002, art. 1º, e Acórdão nº 1.114/2006 - Plenário);”

Como se verifica, três importantes conclusões sobressaem desse recentíssimo acórdão que revela a dinamicidade do conceito:

• A tendência da padronização (protocolos, métodos e técnicas pré-estabelecidos e conhecidos e a padrões de desempenho e qualidade);

• A obrigatoriedade do uso do pregão e da forma eletrônica; • A inexistência de relação entre a complexidade e a essencialidade do serviço como

condição para afastar o uso do pregão. Mas o atual entendimento do TCU vai além e foi reafirmado no Acórdão nº 819/2009, do qual se extrai o seguinte extrato que consolida a jurisprudência sobre o uso do pregão nas aquisições de TI pela Administração:

“1.6.2. As contratações para aquisição de bens e serviços de informática não precisam ser realizadas, necessariamente, sob a forma de licitação do tipo "técnica e preço", podendo também ocorrer sob a forma de pregão, conforme já tratado pelo TCU em diversos precedentes (Acórdãos nº 237/2009, 144/2008, 2.658/2007, 1.782/2007, 1.114/2006, 2.138/2005, 2.094/2004, 1.182/2004, 740/2004 (com redação alterada pelo 1.299/2006) e 313/2004, todos do Plenário);”

No presente caso, a Administração entende que o objeto da licitação contém especificações usuais do mercado, e requer a utilização de técnicas amplamente disseminadas, o que a leva a decidir pela utilização do pregão eletrônico, prestigiando a maior competitividade e isonomia, em busca da proposta mais vantajosa. Tal medida, aliada à boa especificação do objeto da licitação, não trará qualquer risco para o sucesso do empreendimento, e mais do que isso: poderá representar o afastamento de cartéis de empresas; dar maior transparência a competição efetiva e oferecer, de fato a proposta mais vantajosa, com redução de custos. Não é de hoje, que este Ministério vem se empenhando pelo aprimoramento dos serviços e

de 35

enfrentando com firmeza setores que buscam o retrocesso e a estagnação. A transparência que o pregão oferece, com a ampliação da competição, com licitantes sem relação entre si, na forma eletrônica, tem sido objeto de aplausos da sociedade civil. As licitações de hemoderivados lançaram a Administração Pública num cenário de maior eficiência e extraordinária redução de custos. Agora é o momento de usar essa “expertise” e essa transparência no delineamento de um novo modelo que terá por finalidade o ser humano, na dimensão da saúde; construindo a sua história de intercorrências médicas dentro do Sistema Único de Saúde, num primeiro momento, a partir dos Hospitais Federais no Rio de Janeiro. Um salto qualitativo, sem precedentes. O fato de exigir aparentemente muitas horas, não descaracteriza o uso do pregão. Primeiro “aparentemente” porque essa quantidade se refere ao total, considerando toda complexidade física e funcional dos seis (6) hospitais, durante todo o contrato. Segundo, porque essas horas não revelam tarefas de elevada complexidade, a ponto de tornar singular o objeto. Terceiro, porque não há outro meio de se licitar. Explicando melhor: Se o Ministério fosse primeiramente licitar o software, e depois exigir horas de trabalho a serem distribuídas apenas em customizações, implantação e operação assistida – retardaria em muito em alcançar o real objetivo, que é o de obter uma solução funcional e implantada. Note-se, que o objeto está relacionado com seu pregresso histórico em que os hospitais envolvidos viram-se obrigados a se submeter a ordens judiciais para o cumprimento do dever de licitar com prazo definido. Se fosse licitado o software e depois essas horas haveria sim o risco, já antevisto pelo TCU de ser contratado objeto com propostas inexeqüíveis, não em relação ao preço quanto a efetivo conhecimento do software. Como é possível, no âmbito da lei 8.666, fazer uma licitação com itens separados exigindo-se que quem cotar um item ofereça seu serviço para customizar um software que ainda não se conhece. Por esse motivo, a licitação não pode ser tecnicamente dividida, preservando-se a unicidade técnica, no prazo de uma só licitação. Segue, de forma complementar, a argumentação obtida a partir do Dr. Jair Eduardo Santana, a respeito da modalidade de licitação para as aquisições de produtos e serviços para TI, in verbis:

“Diante de tudo o que já dissemos e acompanhando diuturnamente o comportamento dos pregões realizados no Brasil, consolidamos o que já pensávamos e escrevemos anteriormente. Assim, hoje mais do que nunca entendemos que não mais se licita por técnica e preço bem ou serviços afeto a tecnologia de informática (TI), a menos que a racionalidade humana seja imprescindível e essencial para a execução dos respectivos trabalhos. Ou seja, a natureza intelectual de que nos fala a lei(art. 46 da Lei nº 8.666/93) deve se de tamanha monta que sem ela os serviços não seriam realizados. É como se houvesse a necessidade de algo que extrema com algum tipo de “ arte”, onde a “pedra de toque”do objeto, a justificar o “tipo” respectivo, fosse não apenas preponderante, mas conditio sine qua non da execução dos serviços( ou do objeto). De modo inverso, aqueles serviços que se realizam segundo protocolos, métodos, técnicas conhecidas, pré- estabelecidas, visíveis, facilmente mensuráveis e identificáveis, são hoje considerados serviços comuns independentemente da complexidade que apresentem. Temos sustentado em público (essa é outra dimensão que a incorreta indicação da modalidade licitatória apresenta) que configura ato de gestão antieconômica, possível de responsabilizar o gestor, a adoção de modalidade licitatória diversa de pregão que, sabidamente, permite uma maior disputa entre concorrentes e – sem discussão – traz vantagens outras além de economia aos cofres públicos. É dizer por outras palavras: se o objeto é comum – embora pertencente ao setor de TI – ele pertence ao domínio do pregão. Caso se eleja outra modalidade, sem justificativa plausível, certamente estará havendo ônus aos cofres públicos e, sem prejuízo disso, não se estará densificando o princípio da competição entre concorrentes.

de 35

Conhecemos casos emblemáticos de grade êxito, cujos certames lograram permitir disputa saudável e valiosa economia aos cofres da Administração Pública. Tudo devido a correta configuração da modalidade eleita. O tema em comento se interliga àquelas questões relativas ao planejamento das licitações, especialmente no que diga respeito a elaboração do Termo de Referência e/ou Projeto Básico. Se a Administração possui dificuldade para delimitar o objeto de TI não será a adoção do tipo técnica e preço que solucionará aquelas que denominamos de incorreções congênitas. Enfim, a técnica e o preço como tipo de licitação não trazem, por si só, qualquer garantia de eficiência e satisfação ao interesse público. Esse argumento, alias , é de todo impróprio para que a Administração Pública relegue o pregão a modalidade secundária em se tratando de objeto relativo a TI. Nossa conclusão, a propósito do tema, é que o pregão é a via obrigatória para a contratação de objeto pertencente ao domínio da tecnologia da informação, exceto se a racionalidade humana se mostrar imprescindível e essencial para a execução do ajuste. Sentimo-nos confortados pela evolução da jurisprudência do TCU, cujos excertos merecem transcrição: (...) RELATÓRIO 19. Relativamente à modalidade licitatória adotada, o TCU já se pronuncia pela legalidade da aquisição de bens e serviços comuns de informática por intermédio de pregão (Acórdão nº 313/2004- Plenário; Acórdão nº 2.138/2005- Plenário; Acórdão nº58/2007- Plenário), sob o entendimento de que a Lei nº 10.520/2002 revogou os dispositivos que determinavam a obrigatoriedade de licitação do tipo “técnica e preço” para todos os bens e serviços de informática (art. 45, §4º, da Lei nº 8.666/93 e art. 1º do Decreto nº 1.070/1994). 19.1. Todavia, conforme mencionado no voto condutor do Acórdão nº 313/2004- Plenário, “o agente público deve avaliar se os padrões de desempenho e de qualidade podem ser objetivamente definidos no edital e se as especificações estabelecidas são usuais no mercado. Aduzo que o objeto da licitação deve se prestar a uma competição unicamente baseada nos preços propostos pelos concorrentes, pois não haverá apreciação de propostas técnicas. Caso essas condições sejam atendidas, o pregão poderá ser utilizado”. VOTO Quanto à natureza de bens e serviços comuns, o Sr. Analista- Instrutor, em privilégio ao principio da verdade material que norteia os processos neste Tribunal, diligenciou à Secretaria de Tecnologia da Informação do TCU (SETEC), a fim de obter informações sobre a natureza de bem comum do software a ser adquirido. Sobre o assunto, assim se manifestou a SETEC, nas palavras do Sr. Analista- Instrutor: a descrição do objeto do pregão em análise atende a especificações usuais no mercado, podendo ser enquadrado no conceito de bens e serviços comuns. Nesse sentido, acolho a manifestação da Unidade Técnica no sentido de considerar o objeto do certame em análise como bem comum, motivo por que não subsiste o questionamento acerca do emprego de pregão pela Câmara dos Deputados para aquisição desse software. (AC- 0144-03/08-P, Sessão: 13/02/08 Grupo: I Classe: VII Relator: Ministro Benjamim Zymler. Os destaques não constam do original). VOTO - A utilização do pregão com vistas à contratação de serviços de TI 14. Uma das questões levantadas pela unidade técnica demanda uma análise mais detida. Refiro-me à possibilidade e aos limites da utilização do pregão para contratar

de 35

serviços de Tecnologia da Informação. Essa questão tem despertado debates tanto na jurisprudência quanto na doutrina. De forma sintética, pode-se dizer em conformidade com o disposto no art. 1º da Lei nº 10.520/2002, que a utilização do pregão será cabível quando o objeto licitado for um serviço comum. Assim sendo, o fulcro da questão ora posta reside na possibilidade de se caracterizar um serviço de TI como comum. 15. No âmbito desta Corte de Contas, cabe destacar o entendimento exarado no Acórdão nº 2.658/2007 – Plenário, segundo o qual, um objeto complexo pode, em determinadas circunstâncias, ser considerado um serviço comum. Por via de conseqüência, a caracterização de um serviço complexo de TI como comum não estaria, em princípio, vedada (AC-2471-46/08-P, Sessão: 05/77/08 Grupo: I Classe: V Relator: Ministro Benjamim Zymler. Os destaques não constam do original). Uma terceira lição cabe ser transcrita: 11.(...) a lista constante do anexo II do Decreto nº 3.555/2000 não é mesmo exaustiva, mas sim exemplificativa, podendo ser contratados, por meio de pregão, outros bens e serviços, inclusive de informática, bastando que estes se enquadrem na definição de bens comuns constante do art. 1º, parágrafo único, da Lei nº 10.520/2002, ou seja, aqueles cujos padrões de desempenho e qualidade possam ser objetivamente definidos pelo edital, por meio de especificações usuais no mercado. 12. A revisão que ora se propõe é tanto mais oportuna na medida em que o TCU, em decisões mais recentes, vem-se manifestando no sentido de que a Administração deve dar preferência a essa modalidade (pregão), não obstante o caráter facultativo que lhe confere a referida Lei nº 10.520/2002, e que a adoção de outra opção deve ser devidamente justificada. Isso, em função das vantagens que esse sistema vem trazendo para o Setor Público, com a redução dos preços praticados, a simplificação dos procedimentos e a maior celeridade dos certames. 13. Nessa linha, transcrevo trechos do voto do Ministro- Substituto Marcos Bemquerer Costa, condutor do Acórdão nº 2.094/2004 – Plenário: forçoso concluir, portanto, que, apesar do uso do pregão ser uma faculdade da Administração, se no caso concreto os bens e serviços de informática forem considerados “comuns”, a nosso sentir, tudo indica que a licitação na modalidade pregão afigurar-se-à como a solução mais econômica, além de mais célere e ágil, possibilitando a obtenção de preços, mais baixos. (AC- 1299-31/06-P, Sessão: 02/08/06, Classe: I Relator: Ministro – TOMADA E PRESTAÇÃO DE CONTAS. Os destaques não constam do original) Para que não caminhemos para local muito distante, fiquemos com o debate que segue travado também no âmbito do TCU. O caso bem mostra o quanto atualmente são comuns determinados objetos relativos à tecnologia da informação: Representação. Dataprev. Classificação do objeto como de natureza comum. Realização de pregão eletrônico para contratação de empresa de serviços especializados em migração de sistemas, funcionalidades do sistema operacional e base de dados, mantidos em plataforma Unisys de grande porte. SUMÁRIO 1. A utilização da modalidade pregão é possível, nos termos da Lei nº 10.520/2002, sempre que o objeto da contratação for padronizável e disponível no mercado, independentemente de sua complexidade. VOTO MINISTRO AUGUSTO NARDES 9. No que tange à utilização da modalidade pregão para a contratação, destaco que não há irregularidade na escolha efetuada pela entidade. A dificuldade em estabelecer se é cabível, ou não, a realização de pregão, questão que vem sendo diurturnamente enfrentada por este Tribunal, reside no fato de definir se o objeto licitado trata-se de serviço comum (Lei nº 10.520/2002, art. 1º).

de 35

10. Como afirmei, a Corte vem enfrentando a questão, cabendo destacar o precedente citado pela unidade técnica (Acórdão nº 2.658/2007 – Plenário) quando ficou estabelecido que, nada obstante a complexidade do objeto, ele pode ser considerado como serviço comum. 11. No caso em foco, consoante a análise da Secex/RJ, os serviços de migração de sistemas, embora complexos, podem ser considerados comuns, porquanto podem ser padronizáveis e estão disponíveis no mercado, não havendo, dessa maneira, vedação à utilização do pregão. DECLARAÇÃO DE VOTO MINISTRO BENJAMIM ZYMLER Ressalto, a propósito, que os serviços de caráter predominantemente intelectual devem ser licitados com a adoção dos tipos de licitação melhor técnica ou técnica e preço. E quando se tratar de serviços de informática com essa característica, com a utilização do tipo técnica e preço. Tal conclusão decorre dos preceitos contidos nos arts. 45, §4º, e 46 da Lei nº 8.666/1993. Entretanto como serviços de natureza intelectual aqueles em que a arte e a racionalidade humana sejam essenciais para a sua satisfatória execução. Não se trata, pois, de tarefas que possam ser executadas mecanicamente ou segundo protocolos, métodos e técnicas pré- estabelecidos e conhecidos. No caso em tela, verifico que o objeto a ser contratado não merece ser enquadrado como serviço de natureza predominantemente intelectual. Exatamente porque consiste em serviços de migração COBOL Unisys para JEE e DMSII para Oracle, que são padronizados e possuem contornos precisamente definidos. Relembro, inclusive, que há referenciais de mercado para o preço de cada linha de códigos de programa a ser traduzida (item 14 do Voto do Relator) Assim sendo, por considerar que o objeto sob exame pode ser classificado como de natureza comum, entendo ser possível a adoção da modalidade de licitação pregão, na forma eletrônica. ACÓRDÃO 9.1 conhecer da presente Representação, uma vez que atende aos requisitos de admissibilidade estabelecidos no art. 113, §1º, da Lei nº 8.666/1993 c/c o art. 237, inciso VII, do Regimento Interno/TCU, para no mérito, considerá-la improcedente (AC- 2172-40/08- P, Sessão: 01/10/08, Grupo: I Classe: VII Relator: Ministro Augusto Nardes – FISCALIZAÇÃO – REPRESENTAÇÃO). Também o TRF da 1ª Região é claro em seu entendimento quanto à possibilidade de se adquirir ou contratar bem ou serviço comum de informática através de pregão. Reforça esta afirmativa a emenda que transcrevemos: Processual civil e administrativo. Agravo regimental/interno. Agravo de instrumento. Negativa de seguimento. Licitação. Serviços comuns de informática. Pregão eletrônico. Legitimidade. 1. Pode-se negar seguimento a recurso por manifesta improcedência (art. 557, CPC), situação que prescinde da existência de jurisprudência dominante ou uníssona. 2. A aquisição de bens e serviços de informática e automação, considerados como bens e serviços comuns nos termos do parágrafo único do art. 1º da Lei nº 10.520, de 17 de julho de 2002, pode ser realizada na modalidade pregão (art. 3º, §3º da Lei 8.248/91). 3. São bens e serviços comuns aqueles cujos padrões de desempenho e qualidade possam ser objetivamente definidos pelo edital, por meio de especificações usuais no mercado (art. 1º parágrafo único, da Lei 10.520/2002). 4. Consideram-se serviços comuns na área de informática a digitação e a manutenção (Anexo II do Decreto 3.555/2000, com a redação dada pelo Decreto 3.784/2001).

de 35

5. Sendo o objeto do certame a manutenção dos equipamentos e da rede de informática, mostra-se cabível a licitação na modalidade pregão. 6. Agravo regimental/interno não provido. (AGA 2008.01.00.028352-9/DF, Rel. Juiz Federal Marcelo Albernaz (conv), Quinta Turma- DJF1 p. 210 de 07/11/2008 No mesmo sentido: Administrativo. Mandado de segurança. Licitação. Prestação de serviços de informática. Pregão eletrônico n. 06/2008 da Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES). Inadequação dessa modalidade para a contratação de serviços não enquadrados na categoria de “comuns”. Violação à legislação. Anulação do certame. 1. A contratação de serviços técnicos de informática, mais aprofundados que o comum ou ordinário, como no caso, conforme se depreende do item 1.1 do Edital, não pode ser objeto de licitação do tipo “pregão eletrônico”, mas do tipo “técnica e preço” (Lei nº 8.666/1993, art. 45, §4º). 2. Agravo provido. (AG 2008.01.00.005946-0/DF, Rel. Desembargador Federal Daniel Paes Ribeiro, Sexta Turma, e-DJF1, p. 708, 28 out. 2008)”

SANTANA, Jair Eduardo; Pregão presencial e eletrônico: sistema de registro de preços: manual de operacionalização e controle. 3. ed., rev. e atual., nos termos do Estatuto das Microempresas (Lei Contemplar n° 123/06). Belo Horizonte: Fórum, 2009. pag. 102-112.

Pelos motivos expostos o comentário é considerado improcedente. Data: 24/07/2009 Comentário 8: Sugestão de Alteração da Modalidade de Licitação Justificativa: Entendemos que este projeto implicará em mudanças profundas no modelo de gestão e operação atualmente adotados pelos hospitais. Novos conceitos e metodologia de trabalho deverão ser inseridos na rotina atual visando racionalizar os recursos e garantir maior eficiência e qualidade na assistência à saúde da população por parte destas unidades, assim como sua gestão. É recomendável, portanto, a inclusão de serviços técnicos especializados de Consultoria, complementares aos serviços já previstos no material fornecido, de forma a mitigar os riscos inerentes a projetos de grande porte e complexidade. Nessa linha, a adoção da modalidade Pregão não se coaduna com a contratação de serviços de consultoria, haja vista sua natureza eminentemente intelectual. Para tal, recomenda-se a adoção da modalidade Concorrência, do tipo “Técnica e Preço”. Em projetos desta magnitude, entendemos ser essencial a verificação da capacitação técnica operacional e profissional das empresas Licitantes, a fim de preservar o investimento público, garantindo a eficiência e o sucesso da implantação. Existem diferentes níveis de prontidão para as soluções de mercado, o quê significa que cada solução atende de forma distinta os requerimentos do Ministério, sendo necessária uma diferenciação em termos de solução. O elemento mais importante de sucesso de um projeto desta envergadura é a experiência, capacidade, metodologia e corpo técnico do integrador da solução, e não a ferramenta em si. O termo de referência busca menor preço, e para permitir que haja uma segregação mínima entre as empresas participantes pelos pontos citados acima, sugerimos que seja alterado para avaliação técnica e preço, com 70% da avaliação em competências e características técnicas, e 30% no preço final total A adoção do fator de ponderação 7 (sete) para a proposta técnica se justifica pela natureza, importância e complexidade dos serviços a serem contratados e pela qualificação e especialização da empresa que o índice técnico pode revelar Entendemos que a melhor prática para o presente Termo de referência consiste em adotar um critério que considere, além de separação entre capacidade técnica e preço total, um peso maior para pontuação técnica e um peso menor para a pontuação

de 35

de preço. Tal prática justifica-se pelos seguintes motivos: 1) Não se trata de contratação de uma “commodity” 2) Existe muita diferença de qualidade entre os participantes, haja vista a possibilidade de licitantes (Fundações, Consultorias, Empresas pequenas, etc) 3) A responsabilidade técnica do Projeto é enorme, pois a empresa Contratada será responsável pela transferência de tecnologia e implantação. 4) A parte técnica da empresa Contratada deveria ter um diferencial maior em relação aos preços, uma vez que este é um projeto em que não se admite erros de prazo e escopo, devido ao prazo previsto para a implantação da solução como um todo, assim, o Ministério deveria certificar-se da “expertise” da empresa Contratada e atribuir maior pontuação efetivamente para as experiências da empresa e dos profissionais 5) Acreditamos que o Ministério irá estipular um valor médio advindo dos preços de referencia, assim, não haverá discrepância entre os participantes, além de ter agregado inúmeras atividades adicionais.

Resposta do MS ao comentário 8: Não está previsto no escopo da presente licitação a contratação de serviços de consultoria. Os Hospitais Estratégicos/Excelência, instituídos por decreto presidencial, já se encontram inseridos no Projeto de Reestruturação e Qualificação dos HFRJ realizando consultoria no diagnóstico dos principais processos para a sua otimização. Conforme Resposta do MS ao comentário número 7, o objeto contém especificações de serviços e produtos do mercado, com a utilização de técnicas de tecnologia da informação amplamente disseminadas. Na linguagem do TCU: protocolos, métodos e técnicas pré-estabelecidos e conhecidos e a padrões de desempenho e qualidade. Desta feita, a licitação pode e deve ser feita pela modalidade pregão. A contratação de consultoria, caso se vislumbre a necessidade, deverá ser realizada em outra licitação, até mesmo porque não se justifica licitar o conjunto dessas atividades. O Ministério já vem desenvolvendo outros segmentos com uso de consultoria externa, o que revela não ser desconhecido deste órgão, quando a mesma se faz necessária ou não, incluindo a recente iniciativa de participação de 6 (seis) Hospitais brasileiros de excelência na modernização dos Hospitais do Rio de Janeiro. Se a sugestão fosse válida, licitar o conjunto restringiria muito a competição, de forma desnecessária e até mesmo contrária à Lei nº 8.666/1993, que em seu art. 23, § 2º, determina o uso da modalidade pertinente a totalidade do objeto. Nesse caso, prevaleceria, a forma presencial e a modalidade concorrência, com o tipo técnica e preço, muito ao gosto dos que buscam restringir a competição. Pelos motivos expostos o comentário é considerado improcedente. Data: 24/07/2009 Comentário 9: Alteração da modalidade de licitação para Concorrência do tipo Técnica-Preço, contendo critérios claros de pontuação técnica para diferenciação de qualidade entre as diversas Licitantes Justificativa: Entendemos que atividades de consultorias especializadas sejam essenciais para o sucesso e qualidade da implantação. Nessa linha, a adoção da modalidade Pregão não se coaduna com a contratação de serviços de consultoria, haja vista sua natureza eminentemente intelectual. Para tal, recomenda-se a adoção da modalidade Concorrência, do tipo “Técnica e Preço”. Dentro desta sugestão, recomendamos a definição de um critério de pontuação para avaliação da empresa proponente, equipe técnica e solução em quatro dimensões de análise: 1 - DESEMPENHO: Experiência das proponentes no fornecimento e implantação do Sistema. 2 - QUALIDADE: Experiência técnica da equipe das proponentes na implantação do Sistema. 3 - COMPATIBILIDADE: Atendimento aos Requisitos Técnicos do Sistema. 4 - SUPORTE DE

de 35

SERVIÇOS: Capacidade das proponentes na prestação de serviços de treinamento, suporte e manutenção de sistemas. Sugerimos que o Termo de referência solicite atestados de competência técnica sobre domínios específicos relacionados ao sucesso da implantação da solução, visando assegurar que apenas empresas com reconhecida capacidade e competência técnica para entregar os benefícios e objetivos previstos para o Ministério possam ser alvo da licitação. Domínios que sugerimos serem alvos de uma avaliação técnica são: Gestão de Escritório de Projetos (EGP); Gestão de Mudanças; Arquitetura de Sistemas de Informação; Desenho de Processos de Gestão e Operação Hospitalar; Implantação, Desenvolvimento de sistemas em ambiente internet (browser); Implantação de Sistemas de Gestão Hospitalar Políticas de Segurança de Informação; Infra-Estrutura de TIC (Tecnologia da Informação e Comunicação); Service Desk. A experiência deveria ser comprovada através da apresentação de atestado(s) de capacidade técnica, fornecido(s) por cliente(s) das empresas integradoras, com complexidade e envergadura similares às do Ministério da Saúde. Sugerimos serem aceitos apenas os atestados de capacidade técnica emitidos pelos clientes receptores direto dos serviços prestados e que estejam de acordo com os itens abaixo:1 - Projetos relacionados aos domínios de conhecimento deste objeto finalizados ou em andamento, com qualidade, com duração mínima de 6 (seis) meses completos. 2 - Projetos realizados no período de 1999 em diante. 3 -Projetos de Gestão de Mudança envolvendo, por exemplo, acima de 3.000 usuários finais capacitados. 4 - Projetos de implantação de Sistemas de Gestão Hospitalar com relação mínima dos serviços implantados (exemplo: Medicina Diagnóstica, Pronto Socorro, etc). 5 - Projetos de implantação de Sistemas de Gestão Hospitalar que possuam no mínimo a quantidade de leitos especificadas na Minuta. 6 - Projetos de implantação de sistema central que suporte mais de 6 unidades de negócio. 7 - Projetos de Operação Assistida que possuam no mínimo a quantidade de usuários impactados pelo escopo deste projeto

Resposta do MS ao comentário 9: Respondido nos comentários 7 e 8 Data: 24/07/2009 Comentário 10: Alteração da modalidade de licitação para Concorrência do tipo Técnica-Preço, contendo critérios claros de pontuação técnica para diferenciação de qualidade da equipe técnica das Licitantes Justificativa: Conforme já mencionado em outra contribuição, entendemos que atividades de consultorias especializadas sejam essenciais para o sucesso e qualidade da implantação. Nessa linha, a adoção da modalidade Pregão não se coaduna com a contratação de serviços de consultoria, haja vista sua natureza eminentemente intelectual. Para tal, recomenda-se a adoção da modalidade Concorrência, do tipo “Técnica e Preço”. Nessa linha se faz necessário uma avaliação detalhada da capacidade técnica dos empregados das Licitantes que participarão do projeto. Para comprovar a qualidade dos métodos, técnicas e procedimentos que serão adotados pelos funcionários da Licitante na execução dos serviços, sugerimos solicitar a apresentação de certificado ISO 9001:2000. Para comprovar a experiência da Equipe Técnica responsável pelo projeto – dividida em Equipe de Gestão e Equipe de Projeto – sugerimos solicitar a apresentação de atestados de capacidade técnica, fornecidos por clientes nos domínios técnicos: Gestão de Escritório de Projetos (EGP); Gestão de Mudanças; Arquitetura de Sistemas de Informação; Desenho de Processos de Gestão e Operação Hospitalar; Implantação, Desenvolvimento de sistemas em ambiente internet (browser); Implantação de Sistemas de

de 35

Gestão Hospitalar Políticas de Segurança de Informação; Infra-Estrutura de TIC (Tecnologia da Informação e Comunicação); Service Desk. A adoção deste conjunto de critérios visa avaliar a qualidade do serviço prestado pela equipe e a experiência dos profissionais a serem alocados como Equipe Técnica responsável pelo projeto a ser executado nos Hospitais Federais localizados na cidade do Rio de Janeiro. Sugerimos avaliar também o CV de todas as pessoas da equipe de projeto, onde deveriam ser comprovados vínculos empregatícios permanentes através de CLT, para garantia de identidade funcional, metodológica e alinhamento aos fatores de qualidade das empresas. Recomendamos que seja feita uma diferenciação técnica através de pontuações nos domínios acima mencionados, e que sejam pontuados um mínimo de 2.000 horas trabalhadas por profissional. Para os líderes do projeto pelas empresas proponentes (estimamos cerca de três líderes: coordenador do contrato, líder adjunto e líder do projeto), sugerimos exigir comprovação de certificação em gestão de projetos por entidades como PMI.

Resposta do MS ao comentário 10: Quanto à modalidade a ser utilizada já foi extensamente tratado nas respostas 7 e 8. Quanto à qualificação da equipe a ser contratada está prevista a qualificação para a contratação baseada em perfis profissionais, com exigências de qualificação mediante comprovação, conforme detalha o termo de referencia. (Vide item 12.6.4-Das Atividades e da Qualificação Profissional para Execução dos Serviços)

DA PARTICIPAÇÃO DE CONSÓRCIOS (Item da Minuta do Termo de Referência)

Data: 24/07/2009 Comentário 11: É necessário esclarecer as regras para participação de empresas em consórcio. Justificativa: Todas as empresas do consórcio devem atender aos requisitos técnicos estabelecidos no termo de referência.

Resposta do MS ao comentário 11: Procedente. As regras de participação de consórcios serão melhores detalhadas no Edital, por serem pertinentes a competição e não ao objeto. Data: 24/07/2009 Comentário 12: Restrições à Subcontratação Justificativa: Apesar de não estar descrito na Minuta, entendemos que é necessário o posicionamento do Ministério da Saúde em relação a sub-contratação. Em nosso ponto de vista deveria ser vetado, total ou parcialmente, a sub-contratação neste Projeto. As empresas que não possuírem capacidade de atender à totalidade dos serviços objeto do Projeto poderão formar consórcio com outras; portanto e diante da inerente responsabilidade solidária gerada pela situação e da importância e complexidade do projeto, é a forma que melhor atenderá aos interesses deste Termo de referência. Ademais, a instituição do consórcio já existe e está prevista no Termo de referência justamente para prevenir a necessidade de subcontratação e dar ao Ministério a segurança de que um serviço dessa monta seja desempenhado pelos profissionais das pessoas jurídicas de fato Contratadas para tanto, que tiveram sua documentação e capacidade técnica devidamente averiguadas.

Resposta do MS ao comentário 12:

de 35

O Ministério da Saúde compartilha do mesmo entendimento, por isso não há previsão de subcontratação na minuta do edital. Caso fosse permitida a subcontratação, aí sim estaria previsto na minuta do edital a regulação da participação dessas empresas. A possibilidade de vedação à subcontratação é ato discricionário da Administração, admitido em lei – art. 72 e 78, inc. VI, da Lei nº 8.666, de 21 de junho de 1993. Neste caso o Ministério entende que é mais favorável ao Poder Público não permitir serviços por subcontratadas, notadamente, considerando que está prevista a participação de consórcios. Nesse caso, a responsabilidade jurídica ficará mais bem definida do que na subcontratação. Data: 24/07/2009 Comentário 13: Critérios de habilitação Justificativa: Sugerimos que seja incluída uma exigência de qualificação eliminatória para todos os consorciados, ou seja, cada consorciado deverá possuir, pelo menos, um atestado de capacidade técnica, compatível com alguma parte do escopo. Na parte de Habilitação econômico-financeira sugerimos estar previsto que, em caso de consórcios, o patrimônio líquido mínimo exigido seja de 13% do valor estimado da contratação, podendo ser resultado da soma dos patrimônios líquidos das empresas consorciadas, conforme prevê a legislação pertinente. Outro item importante é que todas as empresas consorciadas sejam obrigadas a apresentar seus respectivos documentos de habilitação, ou seja, todas deverão comprovar sua regularidade legal, fiscal, econômico-financeira e ainda, no que couber, entretanto, se entende cada consórcio individualmente como um proponente, na medida em que cada proponente poderá apresentar somente uma proposta de acordo com as exigências do Termo de referência. Não menos importante é a exigência de apresentação de Termo de Compromisso de Constituição de Consórcio firmado entre as partes que assim desejarem concorrer, como requisito adicional à habilitação, visando dar garantia à Administração Pública.

Resposta do MS ao comentário 13: O art. 33, inciso III, da Lei nº 8.666, de 21 de junho de 1993 permite que a Administração eleve o nível de qualificação técnica e econômica para o consórcio. A norma é clara ao estabelecer “podendo”. Embora lícita essa faculdade restringe a competição. Para ampliar a competição e a probabilidade de propostas mais favorável, não haverá acréscimos neste requisito. A comprovação individual de atendimento da habilitação fiscal e jurídica é de lei e deverá ser comprovada por todos os integrantes do consórcio.

DA PARTICIPAÇÃO DE COOPERATIVAS (Item da Minuta do Termo de Referência)

Não houve comentários

DA PROPRIEDADE INTELECTUAL (Item da Minuta do Termo de Referência)

Data: 24/07/2009 Comentário 14: Item 7 – Nós entendemos que ao transferir propriedade intelectual para a contratante, a empresa contratada perde o direito de vender seu software a outros, conforme descrito no certame e portanto não faz sentido desenvolver um software desta magnitude para vender apenas uma vez, exceto se for empresa especializada em serviços de desenvolvimento, os bureaus de informática, o que poderá onerar o ministério em termos de custos, pois certamente ao longo do tempo o Custo Total de Aquisição será maior, portanto sugerimos que este item seja retirado da licitação para permitir que um maior número de empresas qualificadas e que

de 35

atendam aos requisitos do ministério possam participar do certame. A justificativa da proibição de comercialização para coibir versões paralelas contradiz o conceito básico de software livre que é o de permitir o crescimento, ajustes, melhorias e alterações a partir da colaboração de diversos profissionais. Um sistema Informatizado baseado em RES já existe. Justificativa: Não faz sentido desenvolver um software desta magnitude para vender apenas uma vez e o Custo Total de Aquisição será maior. Resposta do MS ao comentário 14: A aquisição do direito de propriedade fundamenta-se nos seguintes aspectos:

1. Cabe ao Ministério da Saúde optar por estratégias que visem diminuir a dependência de tecnologias proprietárias para o SUS, atendendo assim as orientações gerais na adoção de TI no Governo Federal.

2. O objetivo é de disponibilizar solução em Portal de Software Público para que uma comunidade de desenvolvimento possa apoiar a sua melhoria contínua, o que reduzirá o Custo Total de Aquisição, no curto, médio e longo prazo.

3. O Ministério da Saúde visa concentrar seus esforços em TI na aquisição de serviços de TI e não na aquisição de produtos, no que se refere ao Registro Eletrônico de Saúde (RES). Associado a isto utilizará padrões abertos de troca de informações em saúde, para que todo o investimento já realizado, ou que vier a ser realizado por outros estabelecimentos de saúde, possam ser preservados.

4. O objetivo desta aquisição não é a adoção de uma solução única de Registro Eletrônico de Saúde (RES) no Brasil, mas sim o de apresentar uma solução robusta, em Software Livre/Código Aberto, para ser ofertada sem ônus de propriedade ou licenciamento para aqueles entes e instituições que fazem parte do SUS.

5. Como o sistema pretendido, necessariamente estará em plataforma web, serão desenvolvidos serviços de troca dinâmica de dados e funções de interoperabilidade, para que seja possível um baixo acoplamento entre os sistemas, permitido assim a integração com outros sistemas de RES. Data: 24/07/2009 Comentário 15: Venda da solução para o mercado privado – Entendimento do Termo e Referência Justificativa: Assim a CONTRATADA ficará proibida de veicular e comercializar os produtos gerados relativos ao objeto dos serviços contratados, salvo se houver a prévia autorização por ato do Ministério da Saúde. 13.1.1. O valor máximo para aquisição do Sistema com propriedade intelectual para o Ministério da Saúde, visando a implantação nos 6 (seis) Hospitais Federais da cidade do Rio de Janeiro, foi de R$ 20.564.000,00 (vinte milhões e quinhentos e sessenta e quatro mil reais); Segundo o texto acima e considerando o valor estimado do produto é nosso entendimento que a contratada ficará impedida de vender a solução apenas para área pública, podendo continuar a fazer a venda para iniciativa privada. Está correto nosso entendimento?

Resposta do MS ao comentário 15: A transferência de propriedade intelectual inclui a proibição de venda dos softwares tanto para o mercado público como privado em território nacional. Não está correto o entendimento. Data: 24/07/2009 Comentário 16: Impedir a comercialização do software irá restringir a participação de licitantes qualificadas, uma vez que a maioria das empresas do país, fornecedoras de soluções de gestão hospitalar com qualidade assegurada e atestada através de implantações já

de 35

realizadas, possui a comercialização com principal fonte de negócio. Justificativa: Entendemos que a restrição de comercialização do produto, conforme descritivo: “A necessidade de aquisição da propriedade intelectual associada a cessão dos códigos-fontes visa garantir que o sistema não seja mais comercializado em território nacional, evitando assim o surgimento de versões paralelas que continuem sendo comercializadas, frustrando assim um dos principais objetivos desta contratação que é a disponibilização de um Sistema Informatizado baseado no Registro Eletrônico de Saúde totalmente público.” irá restringir a participação de licitantes qualificadas, uma vez que a maioria das empresas do país, fornecedoras de soluções de gestão hospitalar com qualidade assegurada e atestada através de implantações já realizadas, possui a comercialização com principal fonte de negócio. Lembramos que o sistema em licitação impactará diretamente a qualidade do serviço prestado aos pacientes e a implantação de uma solução que não seja robusta o suficiente pode trazer sérios impactos à qualidade de vida dos pacientes atendidos. Um questionamento importante que devemos fazer seria sobre a continuidade do processo de inovação, de garantia da continuidade do software com as futuras manutenções necessárias inclusive por novas legislações, de garantia da compatibilidade, de garantia das futuras integrações entre outros. É necessário que se tenha claramente em mente o custo que será gerado para o Governo para garantir o controle e usabilidade do sistema a partir do momento que este passar a ser de sua responsabilidade, uma vez que por se tratar de um software para um escopo específico, é necessário profissionais com conhecimentos técnicos específicos. Sem investimento não há inovação. Vale ressaltar ainda que um estudo do Gartner mostrou que em sistemas de governo 3% apenas dos gastos são devidos ao sistema operacional utilizado. Já 75% dos gastos são destinados a treinamento, portanto, a médio e longo prazo, uma solução de Plataforma Livre pode não ser a solução mais econômica em termos de TCO (Custo Total de Propriedade). Entendemos portanto, que visando garantir a participação de empresas de qualidade assegurada e principalmente garantir que o software esteja sempre atualizado com o que existe de melhores práticas no mercado e novas legislações, o Governo não deveria exigir o software em Plataforma Livre bem como impedir a comercialização posterior do mesmo pela detentora de seus direitos.

Resposta do MS ao comentário 16: A aquisição do direito de propriedade fundamenta-se nos seguintes aspectos: 1. Cabe ao Ministério da Saúde optar por estratégias que visem diminuir a dependência de

tecnologias proprietárias para o SUS, atendendo assim as orientações gerais na adoção de TI no Governo Federal.

2. O objetivo é disponibilizar solução no Portal de Software Público para que uma comunidade de desenvolvimento possa apoiar a sua melhoria contínua, o que reduzirá o Custo Total de Aquisição, no curto, médio e longo prazo.

3. Após esta aquisição o Ministério da Saúde concentrará seus esforços em TI na aquisição de serviços e não na aquisição novos produtos semelhantes, no que se refere ao Registro Eletrônico de Saúde (RES). Associado a isto utilizará padrões abertos de troca de informações em saúde, para que todo o investimento já realizado, ou que vier a ser realizado por outros estabelecimentos de saúde, possam ser preservados.

4. O objetivo desta aquisição não é a adoção de uma solução única de Registro Eletrônico de Saúde (RES) no Brasil, mas sim o de apresentar uma solução robusta, em Software Livre/Código Aberto, sem ônus de propriedade ou licenciamento, para aqueles entes e instituições que fazem parte do SUS.

5. Como o sistema pretendido, necessariamente estará em plataforma web, serão desenvolvidos

de 35

serviços de troca dinâmica de dados e funções de interoperabilidade, para que seja possível um baixo acoplamento entre os sistemas, permitido assim a integração com outros sistemas de RES.

DA HABILITAÇÃO TÉCNICA (Item da Minuta do Termo de Referência)

Data: 24/07/2009 Comentário 17: Se o sistema não poderá ser vendido, como podemos apresentar um atestado que o sistema já esteja em funcionamento em um hospital público? Ou seja, para entrar no certame a empresa, que já investiu anos de desenvolvimento ficará proibida de vendê-lo, isso contraria o princípio do investimento empresarial que é de gerar lucro a partir de produtos e/ou serviços desenvolvidos. Se o sistema já está desenvolvido e implantado é um contra senso ser proibido vendê-lo a outros hospitais que poderão se beneficiar do sucesso alcançado pelos hospitais do Rio de Janeiro que são alvo do objeto deste certame. Justificativa: Limita a extensão dos benefícios de longo prazo.

Resposta do MS ao comentário 17: O sistema a ser adquirido não poderá mais ser vendido pela contratada após a sua aquisição pelo Ministério da Saúde. Como este termo de referência prevê a aquisição de sistema acabado e pronto para uso, será exigido atestado de capacidade técnica que demonstre a sua implantação em outros hospitais, visando qualificar as soluções pretendidas. A exigência de atestado de capacidade técnica visa qualificar as soluções pretendidas A transferência de propriedade intelectual se dará apenas na ocasião da assinatura do contrato com o Ministério da Saúde, referindo-se apenas às futuras aquisições Portanto serão preservadas todas as implantações já realizadas pela CONTRATADA, bem como os contratos anteriores à aquisição por parte do Ministério da Saúde A aquisição do direito de propriedade fundamenta-se nos seguintes aspectos:

1. Cabe ao Ministério da Saúde optar por estratégias que visem diminuir a dependência de tecnologias proprietárias para o SUS, atendendo assim as orientações gerais na adoção de TI no Governo Federal.

2. O objetivo de disponibilizar solução em Portal de Software Público para que uma comunidade de desenvolvimento possa apoiar a sua melhoria contínua, o que reduzirá o Custo Total de Aquisição, no curto, médio e longo prazo.

3. O Ministério da Saúde visa concentrar seus esforços em TI na aquisição de serviços de TI e não na aquisição de produtos, no que se refere ao Registro Eletrônico de Saúde (RES). Associado a isto utilizará padrões abertos de troca de informações em saúde, para que todo o investimento já realizado, ou que vier a ser realizado por outros estabelecimentos de saúde, possam ser preservados.

4. O objetivo desta aquisição não é a adoção de uma solução única de Registro Eletrônico de Saúde (RES) no Brasil, mas sim o de apresentar uma solução robusta, em Software Livre/Código Aberto, para ser ofertada sem ônus de propriedade ou licenciamento para aqueles entes e instituições que fazem parte do SUS.

5. Como o sistema pretendido, necessariamente estará em plataforma web, serão desenvolvidos serviços de troca dinâmica de dados e funções de interoperabilidade, para que seja possível um baixo acoplamento entre os sistemas, permitido assim a integração com outros sistemas de RES.

de 35

DA PROPOSTA (Item da Minuta do Termo de Referência)


DO SIGILO (Item da Minuta do Termo de Referência)


DO SISTEMA (Item da Minuta do Termo de Referência)

Data: 24/07/2009 Comentário 18: É necessário exigir boa prática de documentação do código aberto.Justificativa: A documentação interna de uma aplicação é essencial para sua evolução.

Resposta do MS ao comentário 18: O termo de referência solicita a documentação em conformidade com as boas práticas de documentação de software, e faz parte da especificação, sendo um importante critério de avaliação. Comentário procedente e já previsto no termo de referência. Data: 24/07/2009 Comentário 19: Funcionalidades adicionais a serem incluídas visando um suporte completo às atividades executadas nos Hospitais Justificativa: Funcionalidades que possam apoiar as funções administrativas, tais como: Faturamento; Gestão de Estoques (central, farmácia central, farmácias satélites e posto de enfermagem); Controle de saídas (óbitos, alta, evasão, etc.). Requisitos relacionados com as funcionalidades clínicas: 1 - Visualização de resultados de exames e dados específicos, como: pressão arterial, destro, peso; em formato gráfico, possibilitando assim análise histórica. 2 - Visualização no Prontuário Eletrônico de imagens de exames radiológicos. 3 - Tipo de saída

Resposta do MS ao comentário 19: Procedentes e novas funcionalidades serão acrescidas no Apêndice A. Data: 24/07/2009 Comentário 20: Necessário maior detalhamento da performance esperada e das integrações a serem implantadas visando com isso uma comparação justa entre as soluções apresentadas ao Governo. Justificativa: Requisitos sobre a performance da aplicação e do processo de integração com Legados, como por exemplo: tempo de resposta em mili-segundos para navegação das telas do sistema, critério de disponibilidade da solução, entre outros. Todas as interfaces previstas bem como os requerimentos técnicos das interfaces, para que a Licitante saiba exatamente o que deverá suprir, bem como todas as tabelas necessárias, como por exemplo, CID 10 e o descritivo da carga inicial de dados, como por exemplo, o histórico dos pacientes (prontuários) que deverão ser carregados no novo sistema.

Resposta do MS ao comentário 20: O Quadro 1 do termo de referência estabelece os limites para o número de horas a serem gastas

de 35

no processo de integração de sistemas. O Ministério da Saúde estabelecerá as prioridades de desenvolvimento das integrações, considerando aquelas que sejam fundamentais para o perfeito funcionamento da solução a ser implantada. A avaliação de performance de sistemas depende de diversos fatores, dentre eles a integração da tecnologia utilizada, a infra-estrutura instalada e a utilização do sistema. Desta forma, uma avaliação precisa de performance do “sistema” necessita de informações que ainda não estão disponíveis, uma vez que realidade e dimensionamento de cada hospital é diferente. Devido a este aspecto, comum aos demais serviços solicitados, se estabeleceu a execução por Ordem de Serviço, que deverão conter a definição clara dos “entregáveis”. Nas O.S. serão claramente definidos os requisitos a serem obtidos, por exemplo, performance de integração. E o atesto e liquidação dos mesmos somente após comprovada conformidade com o requisitado. Assim este termo de referência especifica uma plataforma tecnológica escalável que atenda as demandas esperadas. Nos anexos e apêndices deste termo de referência estão caracterizados dos requisitos não funcionais e funcionais da solução a ser adquirida. O comentário é considerado improcedente.

1. DOS SERVIÇOS TÉCNICOS ESPECIALIZADOS (Item da Minuta do Termo de Referência)

Data: 24/07/2009 Comentário 21: É necessário especificar o aprimoramento do HOSPUB Justificativa: O termo de referência não especifica quais serão os aprimoramentos do HOSPUB e quem será responsável por aprimorar os módulos contemplados pelo HOSPUB

Resposta do MS ao comentário 21: A especificação das possíveis melhorias ao HOSPUB ocorrerá ao longo do projeto por meio da incorporação de componentes e/ou integração entre os mesmos, de acordo com a maturidade, adequação e usabilidade dos módulos do HOSPUB. O comentário é considerado improcedente. Data: 24/07/2009 Comentário 22: O serviço de sustentação também pode ser prestado por canais online (chat ou comunicação instantânea). Justificativa: Canais online como chat ou comunicação instantânea podem ser mais eficientes para alguns casos de suporte

Resposta do MS ao comentário 22: Procede e será incluída nas especificações do termo de referencia. Diversos meios de comunicação eletrônicos podem ser utilizados para prover serviços de sustentação. Estes serviços devem ser providos por ferramentas de código aberto e que possam ser distribuídos sem custo. Data: 24/07/2009 Comentário 23: A CONTRATANTE poderá ter acesso aos chamados de suporte em tempo real, inclusive acompanhando as iterações do chamado Justificativa: Possibilitar uma melhor gestão dos serviços de sustentação à solução

Resposta do MS ao comentário 23: Procede e será incluída nas especificações do termo de referencia.

de 35

Data: 24/07/2009 Comentário 24: A qualificação dos profissionais não contempla conhecimentos em segurança da informação Justificativa: É importante que os profissionais envolvidos na implantação tenham conhecimentos em segurança da informação

Resposta do MS ao comentário 24: O profissional Analista de Sistemas contempla diversas especialidades técnicas, incluindo o levantamento de requisitos, modelagem de sistemas, programação, análise de testes, documentação, segurança da informação, dentre outras áreas de conhecimento. O comentário é considerado improcedente. Data: 24/07/2009 Comentário 25: Incluir o perfil de Analista de Testes Justificativa: É importante que a equipe técnica tenha analistas de testes com formação de nível superior e experiência compatíveis para planejar e elaborar testes do sistema

Resposta do MS ao comentário 25: Procedente De acordo com a solicitação será exigido o nível superior para o Analista de testes. Data: 24/07/2009 Comentário 26: 12.3.2.10. CUSTOMIZAÇÃO – Da forma que está descrito neste item não há limites do escopo de customização o que poderá extrapolar o tempo definido pelo certame, sugerimos definir um tempo em horas para customização dentro do projeto. Justificativa: Impossibilita o calculo correto de custos para a oferta.

Resposta do MS ao comentário 26: O Quadro 1 do termo de referência estabelece os limites para o número de horas a serem gastas no processo de customização. Os gestores do ministério responsáveis pelo projeto estabelecerão as prioridades de desenvolvimento das customizações. O cálculo das horas disponíveis no quadro 1 estabelece um referencial de aplicação de horas para que os objetivos do presente termo de referência sejam atingidos. O comentário é considerado improcedente. Data: 24/07/2009 Comentário 27: Os serviços especializados serão executados nas dependências das unidades hospitalares e nas dependências do DATASUS durante o período de 12 meses. É importante que se especifique cronograma inicial com as expectativas de prazos para as melhorias do HOSPUP e sua integração ao novo sistema; para integração do novo sistema aos demais sistemas em uso nas unidades; e para a implantação da nova solução nas unidades. Justificativa: As unidades hospitalares passaram por experiências anteriores de mudanças abruptas em sua rotina de trabalho. É interessante não repetir o mesmo erro e planejar melhor o início do uso do novo sistema, o que facilitaria a aceitação e adoção da nova solução.

Resposta ao comentário27: O termo de referência já exige a entrega de cronograma (item 12.1.7 página 16/170 do Termo de Referência). O processo de implantação da solução pretendida faz parte do conjunto de medidas contempladas no Projeto de Reestruturação e Qualificação da Gestão dos Hospitais Federais do

de 35

Rio de Janeiro. Também, no processo de implantação dos softwares nos hospitais do Rio de Janeiro deverá levar em consideração a Gestão de Mudanças. Este fato visa mitigar o risco de problemas não considerados nos processos de implantação de sistemas de informação. O painel global de monitoramento deste Projeto prevê, com o mapeamento prévios dos processos de cada unidade hospitalar, a estratégia e o momento correta para implantação das diversas ações, incluindo aquelas relativas a Tecnologia de Informação. O comentário é considerado improcedente. Data: 24/07/2009 Comentário 28: É necessário listar os sistemas que serão integrados a solução RES-AI. Justificativa: Para que se ofereça um sistema integrado de apoio à gestão é necessária a importação de diversas informações registradas em outros sistemas em uso nas unidades hospitalares, como por exemplo SIAFI, SIA, SISAIH. etc.

Resposta do MS ao comentário 28: Como o sistema pretendido necessariamente estará em plataforma web, serão desenvolvidos serviços de troca dinâmica de dados e funções de interoperabilidade, para que seja possível um baixo acoplamento entre os sistemas, permitido assim a integração com outros sistemas de RES. O Quadro 1 do termo de referência estabelece os limites para o número de horas a serem gastas, nas Ordens de Serviços, durante o processo de integração de sistemas. O Ministério da Saúde estabelecerá as prioridades das integrações, considerando aquelas que sejam fundamentais para o perfeito funcionamento da solução a ser implantada. O comentário é considerado improcedente. Data: 24/07/2009 Comentário 29: Inclusão de Serviços Técnicos de Consultoria Justificativa: Entendemos que este projeto implicará em mudanças profundas no modelo de gestão e operação atualmente adotados pelos hospitais. Novos conceitos e metodologia de trabalho deverão ser inseridos na rotina atual visando racionalizar os recursos e garantir maior eficiência e qualidade na assistência à saúde da população por parte destas unidades, assim como sua gestão. É recomendável, portanto, a inclusão de serviços técnicos especializados de Consultoria, complementares aos serviços já previstos no material fornecido, de forma a mitigar os riscos inerentes a projetos de porte e complexidade similar. Em nossa percepção, os seguintes serviços deveriam ser incluídos no escopo desta contratação: A revisão completa de todos os processos e sub-processos, para permitir a adequação da solução às necessidades dos hospitais e do atendimento à população, tendo em vista o perfil (terciário) dos mesmos, de forma otimizada e aderente às necessidades legais vigentes, à própria ferramenta, às melhores práticas de mercado e às aspirações do Ministério. Neste sentido, acreditamos que a padronização dos processos nos hospitais visando a otimização da gestão, auditoria e controle dos serviços efetuados é fundamental e pode facilitar a unificação da gestão dos hospitais, principalmente nas áreas de estoque, faturamento, compras, recursos humanos, hotelaria, lavanderia, gestão de leitos e algumas áreas de suporte como serviço de nutrição e dietética, trazendo dessa forma um grande salto de qualidade e de economicidade aos serviços prestados. A realização de um trabalho de gestão de mudança organizacional que prepare e sensibilize de forma adequada todos os profissionais envolvidos para a adoção e real utilização da nova tecnologia e que seja elaborada uma metodologia de acompanhamento e monitoramento dos

de 35

resultados obtidos visando o aprimoramento costante do uso e dos respectivos resultados. A estruturação, organização e implantação dos processos e atividades de um Escritório de Gestão de Projetos (EGP) para realizar a gestão e controle deste projeto alinhado com a Metodologia de Gerenciamento de Projetos do PMI (Project Management Institute) dada a complexidade e abrangência do projeto. Desta forma, o escopo deste projeto não pode ser encarado como apenas o fornecimento e implantação de um novo sistema. Trata-se, na verdade, de um projeto com um grau de amplitude muito maior, sendo necessário, portanto, atividades de consultoria, as quais consideramos essenciais para a adequada implantação da Solução, acompanhamento de sua operação e alinhamento das diretrizes federal e estadual.

Resposta do MS ao comentário 29: Vide Resposta do MS ao comentário 33 Data: 24/07/2009 Comentário 30: Dimensionamento inadequado da gerência e gestão do projeto. Parte 1 Justificativa: A necessidade de se adicionar valor aos produtos e serviços, visando o atendimento de um cliente que se encontra em constante mutação, apresentando um nível de exigência cada vez maior, tem provocado uma crescente necessidade de superação no atendimento a critérios como: eficiência, eficácia, redução de custos, agilidade, flexibilidade, qualidade, dentre outros. Gerenciar empreendimentos sob a ótica de projetos tornou-se uma solução cada vez mais praticada para atender esses critérios onde a complexidade e a mutabilidade dos fatores que compõem um empreendimento não permitem falhas na condução e na busca dos resultados planejados. Nesse contexto o gerente de projetos assume uma relevância fundamental, uma vez que o sucesso desejado no projeto está relacionado diretamente ao seu desempenho. Em função das características específicas dos projetos, existe a necessidade de uma gerência também específica para os mesmos. O gerenciamento de projetos está envolvido com métodos de coordenar e controlar alguns tipos de atividades complexas e dinâmicas, diferenciando-se muito da administração tradicional de atividades de rotina. O gerente de projetos é reconhecido como um administrador de um grande número de diferentes interfaces, com um relacionamento bastante dinâmico entre si. Para lidar com estas interfaces e com a elevada responsabilidade inerentes ao cargo, espera-se que este profissional possua um alto grau de flexibilidade face à limitada autoridade formal de que pode fazer uso (SBRAGIA, MAXIMIANO & KRUGLIANSKAS, 1986). CONTINUA...

Resposta do MS ao comentário 30: Vide Resposta do MS ao comentário 33

de 35

Data: 24/07/2009 Comentário 31: Dimensionamento inadequado da gerência e gestão do projeto. Parte 2Justificativa: Continuação... A principal precaução que o gerente de projetos deve tomar é providenciar para que a adequada atenção seja dada a todos os elementos constituintes do sistema do projeto. Muitos elementos do projeto podem ter pouco relacionamento direto com o sistema que está sendo trabalhado, porém podem ser críticos para o seu sucesso. A maioria dos projetos envolve um número diferente de unidades organizacionais, sendo elas vinculadas a serviços ou suporte de capacitação, e um grande número de pessoas podem estar interessadas em vários aspectos do projeto (STUCKENBRUCK, 1978). A importância do gerente como fator de sucesso do projeto foi enfatizada em pesquisas desenvolvidas pela Standish Group nos anos de 1994, 1996 e 1998 envolvendo 23.000 projetos em mercados de tecnologia da informação. Buscando informações contidas dentro do texto do termo de referência hora em consulta pública, descritas a seguir: Cenário Atual dos Hospitais federais Os seis (6) hospitais federais localizados no Rio de Janeiro apresentam características diferenciadas de alta complexidade, não apenas pelas suas dimensões físicas, mas também pelo volume e tipo da população atendida e pelas diversas especialidades ofertadas. Detalhamento das suas estruturas e áreas de atuação encontra-se no Apêndice B, parte integrante deste Termo de Referencia. 6.Da Participação de Cooperativas Será vedada a participação de cooperativas, pois o serviço a ser executado apresenta características incomparáveis com a organização do trabalho nesta modalidade, tais como: Mecanismos de comando e controle visando assegurar a adoção de métodos e padrões que serão rotineiramente cobrados; Relação de hierarquia técnica e funcional entre os profissionais; Níveis diferenciados de responsabilização técnica. A aquisição da propriedade intelectual também visa garantir que os esforços de implantação e adaptação da Solução estejam plenamente voltados para atender as necessidades do Ministério da Saúde durante o período de transferência de tecnologia. Trata-se de um projeto que envolve 6 (seis) Hospitais Federais de alta complexidade e o seu resultado terá alcance nacional. Os serviços especializados serão executados nas dependencias das unidades hospitalares e nas dependencias do DATASUS no Rio de Janeiro e em Brasília, durante o período de vigência do contrato que será de 12(doze) meses, podendo ser prorrogado conforme a Lei 8.666/93.

Resposta do MS ao comentário 31: Vide Resposta do MS ao comentário 33 Data: 24/07/2009 Comentário32: Dimensionamento inadequado da gerência e gestão do projeto. Parte 3 Justificativa: Continuação Conclui-se: 1)Que os seis (6) hospitais federais localizados no Rio de Janeiro apresentam características diferenciadas de alta complexidade, não apenas pelas suas dimensões físicas, mas também pelo volume e tipo da população atendida e pelas diversas especialidades ofertadas; 2)Que somando à complexidade e a diversidade de assuntos e áreas organizacionais envolvidas com o prazo de 12 meses para conclusão dos trabalhos, a implantação da solução deverá ocorrer de forma simultânea e paralela nos seis (6) hospitais; 3)Que a estrutura de gestão mais adequada para conduzir esse empreendimento está representada a seguir: Equipe gerencia proposta: Gerente Geral do Projeto, Assessoria, Gerente Hospital 1, Gerente Hospital 2, Gerente Hospital 3, Gerente Hospital 4, Gerente Hospital 5, Gerente Hospital 6 Além dos 3 pontos acima deve ser considerado também para

de 35

justificar e reforçar a implementação da estrutura de gestão sugerida, que a implantação da solução passa por um processo muito forte de gestão de mudança, onde novos procedimentos e controles serão exigidos nas atividades do dia a dia dos hospitais, o que faz com que a implantação da solução em cada hospital, com suas características especificas, seja um projeto claramente definido dentro dos preceitos do PMI (Project Management Institute). Segundo Kaplan e Norton (2008) no alinhamento das unidades organizacionais com estratégia o sistema também deve alinhar os empregados com a estratégia. Se todos os empregado não entenderem a estratégia e não estiverem motivados para realizá-las o sucesso na execução da estratégia será altamente improvável. Segundo Luftman Papp e Brier (2002), o alinhamento enfoca as atividades que a gerência executa para alcançar metas coerentes para toda organização sendo seu alcance dinâmico e evolucionário. O Alinhamento precisa de forte apoio da gerência dos seus bons relacionamentos no trabalho, liderança forte, participação, priorização, comunicação efetiva, o entendimento do ambiente e foco.

Resposta do MS ao comentário 32: Vide Resposta do MS ao comentário 33 Data: 24/07/2009 Comentário 33: Dimensionamento inadequado da gerência e gestão do projeto. Parte 4 Justificativa: Continuação... Um gerente de projetos terá que estar presente e dedicado a cada hospital dando atenção a todos os envolvidos diretamente ou não com a implantação da solução, prestigiando e atendendo prontamente os médicos, direção do hospital e equipe técnica com o seu tempo para resolução de problemas, busca de entendimento, motivação, controle e definido/planejando/ gerenciando o plano trabalho; conflitos; escopo; riscos; comunicação, documentação, qualidade e métricas, garantindo o alinhamento aos objetivos estabelecidos. Dado ao exposto acima entendemos que o número de horas de Gerência de projetos deve passar de 9280 horas para 15.360 horas, conforme memória de cálculo a seguir: 8 ( sete Gerentes e um Assessor) X 12 (meses) X160 (Horas)= 15.360 horas. Resposta do MS ao comentário 33: Referente aos itens 29, 30, 31, 32 e 33 (comentário único – dividido por limitação do campo de texto). A implantação desta solução se realiza dentro de um contexto maior, o Projeto de Reestruturação e Qualificação da Gestão dos Hospitais Federais no Rio de Janeiro. Neste projeto, já iniciado, se encontra o mapeamento de processos, o dimensionamento da força de trabalho e a análise de clima e cultura organizacionais dentre outras. Quanto à solicitação de acréscimo nas horas previstas para a Gestão do Projeto de informatização dos Hospitais Federais poderá ser considerada e incluída na versão final do Edital. Data: 24/07/2009 Comentário 34: Correção de erros – Entendimento do Termo e Referência Justificativa: 12.1.12 O aceite dos serviços e/ou artefatos (produtos) executados e entregues pela CONTRATADA não a exime das responsabilidades quanto às garantias específicas associadas a cada produto versionado, desenvolvido testado e homologado, estabelecido na OS, ficando a CONTRATADA responsável pela correção de todos os erros, defeitos, bugs e falhas

de 35

pelo período mínimo de 120 (cento e vinte) dias; No texto acima entendemos que a contratada fica responsável pela correção de todos os erro, defeitos, bugs e falhas pelo período de até 120 dias. Dessa forma a palavra “mínimo” deve ser retirada do texto. Está correto nosso entendimento?

Resposta do MS ao comentário 34: Procede e será alterado no termo de referência. Data: 24/07/2009 Comentário 35: Suporte Técnico – Entendimento do Termo e Referência. Justificativa: 12.3.3.3.5.1 Os Chamados de prioridade 1 serão atendidos no maximo em 1(uma) hora após a sua abertura e contarão com um esforço concentrado da CONTRATADA com vistas a aplicar as soluções necessárias em até quatro horas contadas a partir do inicio do atendimento; No texto acima entendemos que aplicar as soluções necessárias em 4 horas não significa que teremos o problema resolvido, pois muitas das soluções aplicadas não surtem efeitos imediatamente, como por exemplo, a recuperação de um banco de dados. Além do disso podem existir soluções que exijam mais que 4 horas para serem construídas e que possam ser aplicadas em produção. Está correto nosso entendimento?

Resposta do MS ao comentário 35: O tempo definido de resposta e de correção das chamadas de prioridade serve como referencial, que por acordo entre as partes, pode ser ajustado às características dos problemas. O comentário é considerado improcedente. Data: 24/07/2009 Comentário 36: Sugerimos substituir Ordens de Serviço por um detalhamento prévio da metodologia e etapas esperadas durante a implantação da solução bem como seus respectivos prazos e produtos finais para garantir um dimensionamento mais adequado do projeto bem como deixar claro que o foco da contratação é um produto (software) instalado e em uso adequado pelos hospitais e não apenas um quantitativo de horas que será consumido conforme necessidade. Justificativa: A Minuta aponta que devido aos diferentes níveis de maturidade dos serviços dos hospitais, todos os serviços serão prestados por Ordem de Serviço que serão geradas e validadas pela Contratante após a assinatura do contrato e que as mesmas possuem uma quantidade de horas pré-estabelecida para garantir a implantação completa da solução bem como do serviço de suporte pós-implantação durante os 12 meses de contrato. Entendemos que poderia ser pré-estabelecida uma metodologia esperada de implantação com prazos pré-estabelecidos, cobrando a CONTRATADA pela entrega do produto final, ou seja, um software implantado com todos os usuários treinados e capacitados para seu uso. Isso traria uma garantia maior da entrega de uma solução integrada associada a uma facilidade maior de controle de escopo e orçamentário por parte do Governo. Garantindo dessa forma uma integração total da solução a ser implantada. Acreditamos que a estimativa de horas por tipo de profissional incluída na Minuta possa não necessariamente atender a todas as necessidades do Governo ou em alguns casos estar em excesso. Por outro lado, como não existe um detalhamento claro de todas as interfaces da solução com os sistemas legados, bem como um direcionamento claro sobre customizações para atender a um processo específico que possa existir nos Hospitais em questão (o sistema se adequa aos processos ou os processos se

de 35

adéquam ao sistema?), seria interessante pré-estabelecer um banco de horas específico para esses casos, que, neste caso podem e devem ser gerenciados a partir de Ordens de Serviço.

Resposta do MS ao comentário 36: O Termo de Referência já estabelece que o primeiro produto a ser entregue pela CONTRATADA é o Cronograma de Implantação detalhado para cada Unidade Hospitalar. Este cronograma norteará a execução dos serviços conforme a necessidade específica de cada hospital, incluindo o plano de utilização das horas. Cabe destacar que as horas do Quadro 1 são limites máximos, e não serão necessariamente utilizadas na realização dos serviços previstos. Vide item 12.1.1 e 12.1.7 página 16. Responder sobre ordens de serviço. O comentário é considerado improcedente.

DA PRECIFICAÇÃO (Item da Minuta do Termo de Referência)


DAS OBRIGAÇÕES DO CONTRATANTE (Item da Minuta do Termo de Referência)


DAS OBRIGAÇÕES DA CONTRATADA (Item da Minuta do Termo de Referência)


DO PRAZO DE EXECUÇÃO DOS SERVIÇOS TÉCNICOS ESPECIALIZADOS (Item da Minuta do Termo de Referência


DAS CONDIÇÕES DE PAGAMENTO DOS SERVIÇOS (Item da Minuta do Termo de Referência)


DOS PROCEDIMENTOS BÁSICOS DE SEGURANÇA (Item da Minuta do Termo de Referência)

Data: 24/07/2009 Comentário 37: O Item d deve contemplar a elaboração do um acordo de confidencialidade a ser anexado ao contrato. Justificativa: É importante existir um documento que garanta confidencialidade de acordo com as normas ISO 17999 e ISO 27002

Resposta do MS ao comentário 37: Procede e será detalhado no Edital.

de 35

DAS SANÇÕES (Item da Minuta do Termo de Referência)


APÊNDICE A - DESCRIÇÃO DOS REQUISITOS OBRIGATÓRIOS DO SISTEMA (Item da Minuta do Termo de Referência)

Data: 24/07/2009 Comentário 38: O sistema deve contemplar módulos de: Planejamento, Serviço Social, Gestão Financeira e Custos, Gestão de Recursos Humanos, Gestão de Materiais Permanentes, Hotelaria, Relatórios Gerenciais, Biblioteca, Gestão de Suprimentos. Justificativa: Esses módulos são necessários para gestão da unidade hospitalar.

Resposta do MS ao comentário 38: Como o sistema pretendido necessariamente estará em plataforma web, serão desenvolvidos serviços de troca dinâmica de dados e funções de interoperabilidade, para que seja possível um baixo acoplamento, permitido assim a integração com outros sistemas ou outros módulos. O Quadro 1 do termo de referência estabelece os limites para o número de horas a serem gastas, nas Ordens de Serviços, durante o processo de integração de sistemas. O Ministério da Saúde estabelecerá as prioridades das integrações, considerando aquelas que sejam fundamentais para o perfeito funcionamento da solução a ser implantada. Data: 24/07/2009 Comentário 39: É necessária a inclusão de previsão de assinatura de uma declaração para manutenção da confidencialidade da senha do sistema, ou incluir termo de sigilo que possua clausula pertinente a questão. Justificativa: Os usuários dos sistemas costumam fornecer suas senhas a outros em sua ausência. A senha de acesso ao sistema é pessoal e intransferível, não devendo ser fornecida a outros usuários.

Resposta do MS ao comentário 39: Já existem leis, normas e instruções que se aplicam aos servidores públicos federais. Nelas se estabelece os deveres e penalidades em relação à guarda e confidencialidade das senhas utilizadas nos sistemas de informação da administração pública. (Código Penal Brasileiro Art.325 - acrescentado pela Lei nº 9.983, de 14/07/00, DOU de 17/07/00, pg. 4) O comentário é considerado improcedente. Data: 24/07/2009 Comentário 40: É necessário, alem do bloqueio de acesso após numero definido de tentativas, especificar que: a senha deve ser alterada periodicamente (sugestão:120 dias); seja armazenado o histórico das ultimas 3 senhas utilizadas para a não repetição das mesmas; e se possível, implementar expiração de sessão para o sistema após determinado tempo de inatividade. Justificativa: Aumento da segurança no controle de acesso ao sistema. Criação de uma cultura de segurança na instituição Resposta do MS ao comentário 40: Aceitando a sugestão, a funcionalidade de “time-out “(expiração de sessão web) por inatividade de utilização do mesmo é uma características de qualidade do desenvolvimento de aplicações e

de 35

será exigido. A exigência de troca periódica automática de senhas é um mecanismo de segurança que também será exigido. Entretanto, o tempo de troca deverá ser estabelecido por parametrização. Data: 24/07/2009 Comentário 41: Garantir que os campos considerados para gravação em logs e trilhas de auditoria sejam aqueles que contenham informações “sensiveis” ao negocio Justificativa: Evitar a sobrecarga no armazenamento de informações nos servidores Resposta do MS ao comentário 41: A sugestão procede e este requisito poderá ser implementado ao longo da implantação da solução nos 6 (seis) hospitais federais. Data: 24/07/2009 Comentário 42: O sistema deve possuir previsão que garanta a criação de perfis de acesso com níveis de privilegio diferenciados de acordo com a segregação de funções da instituição Justificativa: Garantia de acesso as funcionalidades adequadas aos usuários certos. Resposta do MS ao comentário 42: Já descrito no termo de referência (Item 5.6 das características gerais do apêndice A). O comentário é considerado improcedente. Data: 24/07/2009 Comentário 43: O sistema deve possuir previsão de criptografia para informações trafegadas por linhas de comunicação, dispositivos ou armazenadas em bases de dados. Justificativa: Garantia de proteção de informações “sensíveis” para o negocio da instituição Resposta do MS ao comentário 43: A criptografia para as informações trafegadas será detalhada na especificação dos protocolos de comunicações dos servidores. O comentário é considerado improcedente. Data: 24/07/2009 Comentário 44: Segundo o PDS-Datasus, os sistemas Medico/ambulatoriais devem possuir, entre outros requisitos, disponibilidade alta. Porem, não foram especificados requisitos e controles básicos de garantia da continuidade das operações do sistema em caso de falhas ou interrupções. Justificativa: A paralisação de um sistema das proporções do que esta sendo adquirido pode comprometer o funcionamento dos equipamentos e processos internos, acarretando prejuízos não só aos ativos, mas colocando em risco as vidas dos pacientes Resposta do MS ao comentário 44: A plataforma solicitada deverá ter escalabilidade compatível com diversas demandas que possam aparecer. A especificação da infra-estrutura redundante e tolerante a falhas não faz parte do escopo deste termo de referência (página 7 item ações de infra-estrutura). O comentário é considerado improcedente. Data: 24/07/2009 Comentário 45: Gostaria de contribuir com a DESCRIÇÃO DOS REQUISITOS OBRIGATÓRIOS DO SISTEMA, com as seguintes observações: 1. NÃO ENCONTREI NO

de 35

APÊNDICE INFORMAÇÕES SOBRE CUSTOS GERAIS E POR PACIENTE, CONTROLE DE ESTOQUE, MÓDULO FARMÁCIA COM CUSTO GERAL E POR PACIENTE. 2. NOS REQUISITOS FUNCIONAIS OBRIGRATÓRIOS ITEM 8. GERAIS, NÃO VI A POSSIBILIDADE DE SE TRABALHAR COM PREÇO DIFERENCIADO DA TABELA DO SUS. 3. NOS ITENS 10.e 11. CADASTRAMENTO E PARAMETRIZAÇÃO DOS CIDADÃOS-USUÁRIOS DO SUS E PROFISSIONAIS. NÃO VI A OPÇÃO DE USO DA BIOMETRIA. PÁG. 40. 4. NO ITEM 12.8 RETIRAR A PALAVRA "REALIZAR" QUE ESTÁ EM DUPLICIDADE. PÁG. 41. 5. NO ITEM 16.3 E NOS QUE SE REFEREM AO LABORATÓRIO. NÃO VI A POSSIBILIDADE DA ASSINATURA ELETRÔNICA DO PROFISSIONAL RESPONSÁVEL PELO RESULTADO DO EXAME. PÁG. 42. 6. NO ITEM 18. REGISTRO ELETRÔNICO DE SAÚDE PARA ATENÇÃO INTEGRAL. VI QUE ATENDE AOS REQUISITOS MÉDICOS E DE ENFERMAGEM, PORÉM NÃO VI FALAR SOBRE OS OUTROS PROFISSIONAIS QUE ATENDEM NO LEITO COMO: FISIOTERAPEUTA, PSICOPEDAGOGO E OUTROS. PÁG. 43. 7. NO ITEM 19. SOLICITAÇÃO DE EXAMES. NÃO VI A OBRIGAÇÃO DE NOTIFICAÇÃO AUTOMÁTICA DOS RESULTADOS DE DOENÇAS DE NOTIFICAÇÃO COMPUSÓRIA. PÁG. 46. Justificativa: SOU ADMINISTRADOR DE CLÍNICAS E HOSPITAIS E JÁ FIZ SISTEMA DE GESTÃO HOSPITALAR COMO PROGAMADOR DE COMPUTADOR. TENHO 22 ANOS DE EXPERIÊNCIA NA ÁREA, EMBORA ACHE QUE ESTAS OBSERVAÇÕES FAÇAM PARTE INTEGRANTE DE QUALQUER SISTEMA DE GESTÃO HOSPITALAR, GOSTARIA DE DAR ESTA CONTRIBUIÇÃO JÁ QUE SE TRATA DE UM TERMO DE REFERÊNCIA. Resposta do MS ao comentário 45: Quanto ao item 1 - os requisitos para a aquisição do sistema prevêem uma plataforma web com baixa necessidade acoplamento, isso permitirá que diversas informações, provenientes de outros sistemas, possam ser integradas ao RES-AI, incluindo informações para elaboração de relatórios de custos, sejam eles por absorção, baseado em atividade, por centros de custos, ou outra metodologia. Quanto aos módulos de farmácia e estoque serão acrescentados nos requisitos do Apêndice A. Quanto ao item 2 do comentário – o objetivo desta aquisição e orientado para os estabelecimentos do SUS, que utilizam exclusivamente a Tabela SUS. Quanto ao item 3 - procedente e será incluída a exigência de que o sistema tenha autenticação de usuário por meio de Teste Biométrico, login e senha. Quanto ao item 4 – procedente e será corrigida. Quanto ao item 5 – procedente e será incluída a exigência de que o sistema tenha autenticação de usuário por meio de Teste Biométrico, login e senha. Quanto ao item 6 – o conceito já é de um sistema multiprofissional. Já previsto no Termo de Referência. Quanto ao item 7 – procedente e está previsto no Termo de Referência (Item 34.1). Data: 24/07/2009 Comentário 46: Apêndice A Item1 – Quais as características do padrão Java é desejável? Entendemos que esta é uma restrição que retira do certame muitas software houses que utilizam padrões diferentes, mas que dão a mesma performance, segurança e look and feel das ferramentas Java. Item 2- Mesma consideração feita anteriormente sobre software livre. Item 4- Existem plataformas que oferecem as mesmas características, mas que não são as nomeadas neste item. Ao nomear ferramentas de desenvolvimento o ministério favorece “marcas” e entendemos que deve ser exigido parâmetros de segurança e qualidade e não determinar fabricantes. Item 7 – Sugerimos inserir possibilidade de uso de biometria e Certificação Digital de acordo com a SBIS – Sociedade Brasileira Informática em Saúde e garantir as práticas solicitadas para o ICP-Brasil. 18.8.2 – Sugerimos que o padrão NANDA seja exigido, assim como é sugerido o uso de CID para diagnóstico.

de 35

Justificativa: A licitação torna limitante o trabalho de outras plataformas mais modernas e falta definição de alguns padrões internacionais, como o NANDA. Resposta do MS ao comentário 46: As questões relacionadas aos itens 1, 2 e 4 foram devidamente consideradas e respondidas no comentário 2. Quanto ao item 7 - procedente e será incluída a exigência de que o sistema tenha autenticação de usuário por meio de Teste Biométrico, login e senha. Quanto aos padrões estão sendo considerados aqueles já utilizados no SUS, o que não impede o uso de novos padrões que venham a ser adotados, uma vez que o Ministério da Saúde adquirirá o direito de propriedade intelectual com absorção da tecnologia. Data: 24/07/2009 Comentário 47: Item 19 – Sugerimos solicitar funcionalidade de configuração, prescrição e controle por protocolos. Assim como gestão por workflow, telas configuráveis de acordo com o contexto e módulos de suporte a decisão. Justificativa: Estas funcionalidades trazem segurança para os processos desenvolvidos através das diversas funções dos profissionais de saúde. Resposta do MS ao comentário 47: O presente termo de referência inclui a exigência de que o sistema permita criar protocolos nos quais prescrições de medicamentos, dietas e cuidados sejam associados a doenças por meios de seus códigos CID10 (Item 8.4 do apêndice A). O comentário é considerado improcedente. Data: 24/07/2009 Comentário 48: Requisitos de usabilidade como facilidade de aprendizagem e de memorização são essenciais na concepção de qualquer sistema de informação. É necessário definir quais heurísticas serão utilizadas na avaliação da usabilidade. Por exemplo: reconhecimento, flexibilidade e prioridade à informação importante. Justificativa: Para este sistema os usuários tem os perfis mais diversos, por exemplo: profissionais de saúde e administrativos, pacientes, pessoas com alta e baixa escolaridade, analfabetos funcionais, usuários acostumados ou não com o uso de computadores etc. Resposta do MS ao comentário 48: Os critérios de usabilidade serão considerados na execução do serviço e implantação do sistema. Dentre os perfis profissionais especificados na minuta do termo de referência, estão profissionais de saúde com especialização em sistemas de informação, que terão por função primordial avaliar os requisitos de usabilidade e preparação para a implantação. O comentário é considerado improcedente. Data: 24/07/2009 Comentário 49: É necessário levantar quais requisitos funcionais do HOSPUB estão realmente consolidados e aprovados por seus diversos usuários. Justificativa: O uso de um sistema não significa necessariamente que este tenha seus requisitos funcionais aprovados por seus usuários. Diversos módulos do HOSPUB possuem características que não se adequam a realidade dos serviços hospitalares, mas continuam em uso devido a ser o único sistema disponível nas unidades. Resposta do MS ao comentário 49: Os requisitos funcionais do HOSPUB e grau de maturidade foram avaliados em consultoria realizada pela OPAS em 2008. Esta avaliação subsidiou a elaboração deste termo de referência.

de 35

O comentário é considerado improcedente. Data: 24/07/2009 Comentário 50: Realizar a avaliação da Escala de Glasgow e outras. Justificativa: Existem outras escalas de avaliação neurológica e outros sistemas orgânicos que são utilizados com freqüência na avaliação clínica. Resposta do MS ao comentário 50: Requisito já contemplado (Item 18.8.5 de entrada de dados apêndice A). O comentário é considerado improcedente.

APÊNDICE B - CADASTRO DOS 06 HOSPITAIS FEDERAIS DO RIO DE JANEIRO (CNES)

Não houve comentários.

APÊNDICE C - PDS - PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

Data: 24/07/2009 Comentário 51: Apêndice C – Se estamos considerando que o sistema já tenha que estar em funcionamento em um hospital, imagina-se que o sistema já foi desenvolvido e desta forma já foram utilizadas técnicas e metodologias de gestão de fábrica que não necessariamente seguem os padrões estabelecidos neste apêndice, portanto podemos entender que este apêndice aplica-se apenas à parte de customizações que vierem a ser solicitadas durante o projeto, correto? Pois do contrário entendemos que a quantidade de empresas que utilizam exatamente os processos e técnicas descritos no documento serão reduzidas, impedindo que outras empresas com igual qualidade e completude possam participar do certame. Justificativa: Este apêndice leva em consideração que o sistema será desenvolvido o que não é desejado e contradiz o solicitado no item 8.1.1 onde solicita que o sistema já esteja em funcionamento em algum hospital. Ora, se o sistema já foi criado, eventualmente não foi utilizado exatamente este processo de desenvolvimento descrito no certame.

Resposta do MS ao comentário 51: O entendimento está correto. O Apêndice C se aplica somente nas customizações e integrações realizadas a partir do inicio do projeto disposto neste termo de referência. Data: 24/07/2009 Comentário: Deve-se considerar não só a participação do usuário no processo de desenvolvimento, mas também elaborar plano de análise de usabilidade que deve ser executado antes da implantação do sistema nas unidades. Plano que inclua também um estudo piloto.Justificativa: O usuário padrão não é receptivo a mudanças de sistemas de informação em sua rotina de trabalho. Para garantir a adoção do sistema em todos os setores é necessário que o sistema tenha sido previamente validado por usuários.

Resposta do MS ao comentário 52: Dentre os perfis profissionais especificados na minuta do termo de referência, estão profissionais

de 35

de saúde com especialização em sistemas de informação, que terão por função primordial avaliar os requisitos de usabilidade e preparação para a implantação. O comentário é considerado improcedente.

ANEXO I - MODELO DE PROPOSTA DE PREÇO (Item da Minuta do Termo de Referência)


ANEXO II - MODELO DE VISTORIA (Item da Minuta do Termo de Referência)


ANEXO III - MODELO DE CARTA DE CESSÃO DE DIREITO DE USO IRRESTRITO E PROPRIEDADE INTELECTUAL DO SISTEMA (Item da Minuta do Termo de Referência)


Brasília 04 de agosto de 2009

Francisco José Marques Coordenador Geral de Análise e Manutenção

DATASUS

ministÉrio da saÚde secretaria executiva...

Documents