O texto da tese 2011-1010-vf-ad

427 views
362 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
427
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

O texto da tese 2011-1010-vf-ad

  1. 1. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática Médica Mestrado em Informática Médica Análise dos requisitos técnicos dos cadernos de encargos destinados a sistemas de informação hospitalares Domingos Manuel da Silva PereiraOrientação: Prof Dr Ricardo Correia Outubro de 2011 TeseDomingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 1 Outubro 2011 |
  2. 2. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática MédicaConteúdoRevisão Bibliográfica. .................................................................................................................... 3 O que é um sistema de informação hospitalar? Que componentes o constituem habitualmente? ......................................................................................................................... 3 O que são requisitos? ................................................................................................................ 7 O modelo Zachman e a especificação de requisitos ........................................................... 12 As entidades certificadoras. .................................................................................................... 14O caso de estudo como metodologia de investigação científica. ............................................... 16 Estratégia de investigação ou abordagem metodológica adoptada neste trabalho. ............. 19 Action research/Action Science. ........................................................................................ 20Objectivo do trabalho – as questões de investigação................................................................. 22Métodos para a Recolha de Dados ............................................................................................. 23Resultados ................................................................................................................................... 24 Entrevistas ............................................................................................................................... 24 Entrevista com IPO do Porto. .............................................................................................. 24 Entrevista com HP. .............................................................................................................. 26 Entrevista com Glintths. ...................................................................................................... 27 Entrevista com CHVNG. ....................................................................................................... 28 A experiência do investigador ................................................................................................. 30 Análise de documentos ........................................................................................................... 32Conclusões .................................................................................................................................. 34 As limitações inerentes às conclusões apresentadas ......................................................... 34 As conclusões associadas aos temas/questões em estudo ................................................ 34 Outras conclusões possíveis. ............................................................................................... 36Recomendações .......................................................................................................................... 38Lista de Figuras e Tabelas ............................................................................................................ 40Acrónimos ................................................................................................................................... 41Bibliografia .................................................................................................................................. 43 Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 2 Outubro 2011 |
  3. 3. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática MédicaRevisão Bibliográfica.O que é um sistema de informação hospitalar? Quecomponentes o constituem habitualmente?Quando se fala em sistema de informação relacionado com um qualquer sistema operativo,falamos habitualmente da componente de dados e informações que acompanha e cria umaabstracção das operações que ocorrem nesse sistema. Em alguns sistemas a matéria-prima emtransformação nas operações do negócio são só dados. As indústrias bancárias e seguradora sãobons exemplos disso.No passado estes sistemas de informação, já existiam e em alguns casos funcionavam muitobem, tendo presente as tecnologias disponíveis. Hoje quando falamos em sistemas deinformação, falamos sobretudo nos sistemas que utilizam as chamadas tecnologias deinformática e comunicações (TIC), as quais tendencialmente deverão eliminar progressivamenteo papel nas organizações e entre as organizações.Tendo no entanto em conta os esforços para a construção de soluções organizacionais nosnossos hospitais sem papel é claro que ainda existem muitos sistemas de informação, fora doâmbito das TIC, a funcionar.A figura seguinte ilustra os componentes aplicativos mais comuns, a menos da infra-estruturatecnológica, que constituem um sistema de informação hospital suportado nas TIC.Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 3 Outubro 2011 | Revisão Bibliográfica.
  4. 4. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática MédicaFigura 1 - Arquitectura Aplicativa de um Sistema de Informação Hospitalar, adaptadopelo autor a partir de documentos produzidos no CHVNG para apresentar o projecto SIH.CTH – Consulta Tempo e Horas; RNU – Registo Nacional de Utentes; RSE – RegistoSaúde Eletrónico; SIGIC - Sistema de Gestão dos Utentes Inscritos para CirurgiaOs acrónimos anglo-saxónicos CPR (Computer based Patient Record), EMR (ElectronicMedical Record), EPR (Electronic Patient Record), EHR (Electronic Health Record), e mesmoHIS (Hospital Information System), são habitualmente usados com o mesmo sentido, quando sereferem à arquitectura aplicativa dum hospital.Tendencialmente EHR tem vindo a ser usado quando nos referimos ao registo de saúdeelectrónico de um cidadão de um país, e no contributo longitudinal de todas as organizações queprestam cuidados e do próprio cidadão nesse registo. (Cunha, 2009)Neste trabalho entendemos CPR, EMR, EPR, como as componentes aplicativas centradas notratamento da informação clínica do utente no hospital, incluindo os fluxos padronizados doscuidados a prestar num dado contexto ao Utente, e como tal como um subconjunto de um HIS(ou SIH), o qual inclui também todas as áreas clinico-administrativas associadas às váriasDomingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 4 Outubro 2011 | Revisão Bibliográfica.
  5. 5. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática Médicamodalidades de tratamento que o Hospital oferece, e o tradicional back-office, da gestão daorganização, habitualmente incluído na designação ERP (Enterprise Resource Planning).Na figura, o CPR agrupa os componentes aplicativos dentro do tracejado.Qualquer arquitectura funcional de um sistema pode ser descrita através de quatro elementos: • As actividades principais de cada componente apresentado • Os fluxos que se operam entre os vários componentes • Os fluxos de entrada e saída do sistema com os sistemas ou agentes exteriores com que interage • As propriedades ou características particulares que aquela arquitectura demonstra ou potenciaA profundidade da descrição de cada elemento dependerá do objectivo do trabalho e doconhecimento do seu autor.Uma característica certamente comum, é o facto de existirem vários componentes, cada um comvarias soluções aplicativas, numa mesma arquitectura HIS, o que implica a necessidade deassegurar uma interoperabilidade adequada entre os vários componentes/aplicações por umlado, e por outro, um equilíbrio saudável entre os componentes/aplicações transversais a todosos agentes, valências e modalidades de modo a reduzir esse mesmo número de componentes eaplicações a um valor gerível do ponto de vista da administração dessas aplicações e da suainteracção com as outras.O conceito de interoperabilidade tem vindo a ser trabalhado seriamente pela HIMSS, (HIMSS,2011) que propõe para o mesmo a seguinte definição:Interoperabilidade é a capacidade dos sistemas de informação na Saúde trabalharem emconjunto, quer no interior das organizações quer cruzando fronteiras organizacionais, no apoioa uma eficaz prestação de cuidados de saúde a indivíduos e à comunidade (HIMSS, 2011)A esta definição a HIMSS adiciona um conjunto de dimensões que clarificam o conceito deinteroperabilidade:a) Uniformidade na movimentação dos dados de um sistema para outro, de tal forma que a finalidade e o significado clínico e operacional desses dados sejam preservados e não sofram alteração;b) Uniformidade na apresentação dos dados, permitindo aos diversos utilizadores dos diferentes sistemas obter uma apresentação consistente sempre que isso for clínica ou operacionalmente importante;c) Uniformidade nos controlos de utilização, permitindo a um utilizador, acedendo a diversos sistemas, obter informação contextual e controlos de navegação apresentados consistentemente, permitindo actuações consistentes em todos os sistemas relevantes;d) Uniformidade na preservação da segurança e integridade dos dados, na movimentação de dados entre sistemas, de tal modo que só pessoas e programas autorizados possam ver, manipular, criar ou alterar esses dados;Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 5 Outubro 2011 | Revisão Bibliográfica.
  6. 6. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática Médicae) Uniformidade na protecção da confidencialidade dos pacientes, mesmo quando diferentes utilizadores em diferentes organizações acedem a dados trocados entre sistemas, para prevenir acessos não autorizados a informação sensível;f) Uniformidade na garantia de um grau comum de qualidade de serviço (fiabilidade, desempenho, disponibilidade, etc.) para que os interessados, que dependem de um conjunto de sistemas interoperantes, possam contar com a disponibilidade e capacidade de resposta do sistema global na realização das suas actividades.Como se percebe não se trata apenas de movimentar os dados de modo contextualizado, mastambém fazê-lo com segurança, qualidade de serviço, e permitindo uma experiência deutilização na apresentação e actuação ou navegação sobre os dados apresentados, uniforme,evitando ao utilizador, confrontar-se no decurso da realização de uma operação clínica ouadministrativa com vários interfaces aplicativos distintos.A realidade dos nossos sistemas de saúde, não é, na sua grande maioria, esta. Não é raro oprofissional de saúde, ter de se movimentar por várias aplicações que transportam dados entresi, com interfaces distintos, e em alguns casos obrigando mesmo a apresentação repetida decredenciais aplicativas, ao longo do mesmo processo.Em termos tecnológicos as arquitecturas orientadas a serviços, SOA - Service OrientedArchitecture, apresentam-se como modelos e plataformas tecnológicas capazes para odesenvolvimento de soluções que respeitem estes vectores de interoperabilidade. Os Web-Services são um exemplo de uma SOA (Service Oriented Architecture) cujos serviçosdesenvolvidos assentam em tecnologia web.Os sistemas colaborativos e de identificação e autenticação, representam dois componentesdistintos que assumem cada vez mais importância e presença nos hospitais.O portal interno do hospital, o servidor de email, as plataformas mais elaboradas decomunicações unificadas, como o OCS da Microsoft, são aplicações que ajudam na informaçãoe comunicação formal e informal entre os colaboradores e chefias do Hospital.Hoje em dia se o portal interno ou o servidor email está ‘em baixo’ o help-desk da informática élogo confrontado com a sua indisponibilidade, o que torna evidente a sua forte utilização.As soluções de comunicação unificadas, começam a marcar presença nas instituições, com osseus serviços de presença, mensagens instantâneas, fax, áudio e vídeo conferência, voz sobre IP,correio de voz, disponíveis no computador onde o colaborador realiza o seu trabalho diário.Os sistemas de identificação e autenticação no acesso ao domínio do hospital e as suasaplicações têm cada vez mais requisitos de exigência, em termos de robustez e facilitação. Hojeem dia assiste-se a uma multiplicidade de sistemas distintos, com mecanismos de identificação eautenticação frágeis e fortes, com os perfis funcionais, repartidos e desconexos pelas váriasaplicações utilizadas.O cartão do cidadão e a exigência de autenticação biométrica para os colaboradores doshospitais torna viável e fácil a adopção destes mecanismos e tecnologias de identificação eautenticação forte nas redes e aplicações hospitalares existentes, permitindo ainda outrosDomingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 6 Outubro 2011 | Revisão Bibliográfica.
  7. 7. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática Médicaserviços de segurança electrónica como a assinatura digital de documentos ou a sua encriptação,no contexto das suas ferramentas habituais como o Microsoft Office, por exemplo.Para proporcionar ao utilizador uma experiência de navegação pelas várias aplicações, maisagradável e fácil, as soluções de single sign-on tornam-se necessárias quando o profissional temde aceder a vários aplicativos no decurso de um processo. De outra forma o profissionalnecessita apresentar credenciais em todas elas, e tendencialmente escolhe credenciais frágeissenão as mesmas em todas elas, o que naturalmente eleva o risco de roubo de identidade porterceiros.A infra-estrutura tecnológica é o componente que representa as redes de dados, voz e imagem,os servidores físicos, os sistemas operativos, de gestão de base de dados, de monitorização egestão das operações e as condições necessárias ao seu acondicionamento e protecção, salas deservidores, áreas técnicas para bastidores de rede, que hospedam estes sistemas de hardware esoftware, nos quais as aplicações correm e por onde circulam os seus dados.O que são requisitos?Explica (Wiegers, 1999) que um problema da indústria de software é a falta de definiçõescomuns para os termos que são usados para descrever aspectos do trabalho que aí se faz.Isto deve-se na opinião do autor, no que respeita ao termo ‘requisitos’, ao facto de existiremmúltiplos níveis nos requisitos de software, todos eles legítimos, e que representam cada umperspectivas diferentes e graus distintos de detalhe e precisão.Wiegers, cita exemplos de várias definições de requisitos, como a definição do IEEE (1997),que define requisito como; • Uma condição ou capacidade necessária pelo utilizador para resolver um problema ou atingir um objectivo • Uma condição ou capacidade que tem de ser satisfeita, ou possuída pelo sistema, ou componente, para satisfazer um contrato, uma norma, uma especificação ou outra qualquer formalidade imposta.A definição de Jones (1994); • A afirmação de necessidades dos utilizadores, que dispara o desenvolvimento de um sistemaA definição de Alan Davis (1993), que alarga a definição anterior para; • Uma necessidade de utilizador ou uma característica particular, uma função ou atributo do sistema que pode ser sentida a partir de uma posição externa a esse sistemaDomingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 7 Outubro 2011 | Revisão Bibliográfica.
  8. 8. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática MédicaDiz Wiegers, que as definições anteriores reforçam a componente ‘o que/what’ vai ser osistema, em vez do ‘como/how’ vai ser desenhado ou construído.Já (Mylopoulos, 2004) cita Ross para afirmar que definir os requisitos de um sistema é realizaruma avaliação cuidadosa das necessidades que o sistema tem de satisfazer, a qual deve dizer porque razão o sistema é necessário, tendo presente as condições actuais e previsíveis no futuro,que deve descrever que características (features) do sistema servirão e satisfarão o contexto aque se destina, e deve ainda dizer como é que o sistema deverá ser construído.Concluem (Dean Leffingwell, 2000) que se os requisitos definem capacidades/característicasque o sistema deve entregar, e a conformidade ou a falta dela ao conjunto de requisitos,frequentemente determina o sucesso ou o insucesso dos projectos, faz sentido descobrir quaissão os requisitos, escrevê-los (ou documentá-los) organizá-los e monitorizá-los para apossibilidade de se alterarem, isto é torna-se necessário gerir os requisitos.Gerir requisitos é assim a aproximação sistemática para a exploração/descoberta (elicitation),organização e documentação dos requisitos de um sistema, e um processo que estabelece emantêm o acordo/compromisso entre o cliente do sistema e a equipa de projecto relativamenteàs alterações do conjunto de requisitos do sistema.A sabedoria tradicional (Jawed Siddiqi, 1996) continua a insistir que os requisitos de umsistema se focam no ‘o que’ (what) o sistema deve fazer, sem referirem ‘como’ (how) vai fazerisso. A resistência desta visão é surpreendente dado que há bastante tempo que osinvestigadores a contestam. Os requisitos e o desenho da solução são interdependentes.Na prática a maioria do trabalho realizado na geração dos requisitos do sistema tem comoobjectivo principal estabelecer um contrato através do qual o cliente e o fornecedor do sistemachegam a um acordo preciso e sem ambiguidade sobre o trabalho a desenvolver.Continuando na visão mais prática da construção dos requisitos Scharer (Scharer, 1981) remeteas dificuldades da tarefa para as visões e interesses distintos que utilizadores e analistas têm doprocesso.Desde logo os analistas gostariam que os requisitos a ‘sacar’ aos utilizadores pudessemconverter-se directamente no desenho do sistema. Isto implica que a documentação dosrequisitos funcionais seja expressa em processos (actividades), ‘outputs’, ‘inputs’ e estruturas dedados. Além disso os analistas gostariam que esta especificação fosse completa e precisa,evitando as ambiguidades de interpretação.Os utilizadores parecem mais satisfeitos na especificação dos requisitos em termos qualitativos,em generalidades e nos benefícios que esperam obter com o novo sistema. Tem algumadificuldade em satisfazer a insistência dos analistas, na separação conceptual do ‘o que’ e do ‘ocomo’. Parece que os analistas estão habitualmente um passo à frente dos utilizadores.John (Mylopoulos, 2004) propõe que os requisitos descrevem o sistema relativamente ao seuambiente e não ao seu funcionamento interno. Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 8 Outubro 2011 | Revisão Bibliográfica.
  9. 9. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática MédicaExistem tipicamente dois tipos de requisitos, os funcionais e os não-funcionais.Os funcionais descrevem: • O processamento (i.e. as funções a serem suportadas) do novo sistema • As entradas (inputs) que irão chegar ao novo sistema • As saídas (outputs) que o novo sistema irá produzir • Os dados que o novo sistema terá de gerir.Os não-funcionais descrevem o modo (how well) como o sistema deverá suportar os requisitosfuncionais, e daí que sejam também designados de requisitos de qualidade. Esta descrição podeincluir: • Critérios de desempenho • Requisitos de fiabilidade (Reliability) • Considerações de segurança • Requisitos de usabilidade • E outros.Widrig (Dean Leffingwell, 2000) dão testemunho da sua longa experiência na disciplina deengenharia de requisitos para conciliar a visão dos utilizadores e a da equipa do projecto desoftware, ou como do ‘o que’ se chega ao ‘como’ na especificação de requisitos, e que estádiosde especificação (documentação) podem ser encontrados ao longo do processo.A imagem seguinte sintetiza a sua aproximação.Figura 2 - domínios do problema e da solução na engenharia de requisitos (DeanLeffingwell, 2000)Afirmam que as jornadas mais bem-sucedidas de análise dos requisitos começam no terreno doproblema (ou da oportunidade). O domínio do problema é o terreno dos utilizadores reais e dosoutros interessados. Pretende-se nesta etapa, compreender o problema a ser resolvido, ou aoportunidade a ser agarrada. Problemas e oportunidades são afinal caras da mesma moeda.Definem a etapa de análise do problema como o processo para compreender os problemas e asnecessidades dos utilizadores e propor caminhos possíveis de solução que possam satisfazerDomingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 9 Outubro 2011 | Revisão Bibliográfica.
  10. 10. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática Médicaessas necessidades. Muitas vezes a solução mais simples pode ser uma alteração ao processo denegócio, em vez de um novo sistema.Propõem um conjunto de técnicas/passos, as etapas de análise do problema e compreensão dasnecessidades • A análise do problema: passos propostos o Chegar a consenso na definição do problema o Chegar à raiz do problema – o problema que causa o problema o Identificar os interessados e os utilizadores o Definir as fronteiras que o sistema que possa resolver o problema deve respeitar o Identificar os constrangimentos que a solução deve respeitarOs autores propõem que a modelização do negócio seja um dos métodos utilizados na fase deanálise do problema, para que se possa compreender a estrutura e a dinâmica da empresa e aindaque os clientes, utilizadores e analistas possam dispor de uma compreensão comum daorganização. Como técnica para este método, sugerem a utilização do modelo ‘casos de uso donegócio’ e do modelo ‘objectos do negócio’, propostos pela metodologia UML.Não basta perguntar aos utilizadores quais são as suas necessidades, e preciso ‘arrancar-lhas’ epara tal os autores propõem um conjunto de técnicas que devem ser utilizadas de modoarticulado.Necessidade é definida como o reflexo de um problema operacional, pessoal ou de negócio, quedeve ser satisfeita, e deste modo justificar o investimento no novo sistema. • A compreensão das necessidades do utilizador: técnicas propostas o Entrevistas e questionários o ‘Workshops para recolha de requisitos’ o ‘Brainstormings’ o ‘Storyboards’ o Casos de Uso o ‘Role playing’ o PrototipagemIdentificadas as necessidades que o novo sistema deve satisfazer, para solucionar o problema ouagarrar a oportunidade, expressas muitas vezes de modo vago e ambíguo, o analista deverá sercapaz de descrever as características mais relevantes que o novo sistema deve respeitar. Estascaracterísticas expressas de modo afirmativo habitualmente com um alto nível de abstracção,designam-se de ‘features’ e marcam a mudança relevante do ‘o que’ para ‘o como’.‘Feature’ é definida como um serviço que o novo sistema oferece para satisfazer uma ou maisnecessidades do interessado (stakeholder).De facto o objectivo de compreender as necessidades dos utilizadores é ser capaz de extrair asnecessidades e as ‘features’ do sistema proposto como solução. Muitas vezes a diferença ésubtil, mas ter consciência da diferença é importante na clareza do ‘output’ a produzir.As ‘features’ são habitualmente expressas em linguagem natural, em frases curtas.Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 10 Outubro 2011 | Revisão Bibliográfica.
  11. 11. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática MédicaO número de ‘features’ expressas dá uma medida do nível de abstracção da definição propostapara o novo sistema. Os autores, Widrig & Leffingwell, sugerem entre 25 a 99 features,preferencialmente com menos de 50 para cada novo sistema.Os requisitos que vão sendo capturados, ao longo do processo, devem ser documentados, e oseu conjunto articulado (raramente constituem apenas um documento) é designado como‘documentos de especificação de requisitos’. Os autores propõem que os requisitos capturadosna fase de análise do problema e compreensão das necessidades, sejam reunidos no ‘documentode visão’, o qual a um nível elevado de abstracção descreve já uma solução para o problema.A próxima etapa na construção dos requisitos do sistema, destina-se a especificar os chamadosrequisitos de software e especifica o comportamento externo do novo sistema, acabando de vezcom o mito que a análise funcional, ou a especificação de requisitos, se limita à especificação do‘o que’.Davis (Davis, 1999) propõe que a especificação dos requisitos de software se faça via 5 classesdistintas de requisitos: • Entradas no sistema (inputs) – não apenas o conteúdo, mas também os detalhes dos dispositivos de entrada, a forma, o aspecto e o protocolo. • Saídas do sistema. – Descrição dos dispositivos de saída, bem como os protocolos e formatos dos mesmos. • Funções a realizar. Tradução das entradas nas saídas. • Atributos do sistema. Tipicamente requisitos não-funcionais, como fiabilidade, manutenção, disponibilidade, desempenho. • Atributos do ambiente no qual o sistema vai correr. De novo requisitos não funcionais associados aos constrangimentos nos quais o sistema terá de correr, como limitações operacionais, carga e compatibilidade de sistemas e subsistemas operativos. Muitos dos requisitos que impõem constrangimentos ao desenho da solução a criar, cabem aqui.Widrig & Leffingwell, esclarecem no início do capítulo 28, que assumem que a maioria dosrequisitos sejam escritos em linguagem natural, seja no texto tradicional, seja via a utilizaçãodos casos de uso.Alertam no entanto que se a descrição do requisito é muito complexa para ser expresso emlinguagem natural, e não pode haver lugar a ambiguidade, dado tratar-se de um sistema critico,será útil ponderar a utilização de métodos-técnicas para especificar tal requisito.Ao longo do capítulo, sintetiza algumas dessas técnicas: • Pseudo-código • Máquinas de estados finitos • Árvores de decisão • Diagramas de actividades ou ‘flowcharts’ • Modelos de Entidade-Relação • Análise orientada a objectos • Análise estruturada – DFDComo se percebe este tipo de especificação, vai já no sentido sugerido por Scharer (Scharer,1981), de produzir especificações que facilitem os trabalhos posteriores, de desenho,codificação e teste das soluções, embora não possam deixar de ter presente que têm de continuara assegurar a comunicação com os ‘key-users’ o que em alguns casos pode mesmo justificaralguma formação destes, nestas técnicas.Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 11 Outubro 2011 | Revisão Bibliográfica.
  12. 12. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática MédicaO modelo Zachman e a especificação de requisitosDada a abrangência de um SIH no suporte à actividade de um hospital, o ‘framework’ deZachman surge naturalmente como algo a contextualizar ainda que de modo breve nesta revisãobibliográfica.Zachman, (Zachman, 1987), afirma que com o crescimento dos SI, em tamanho ecomplexidade, é necessário usar uma arquitectura para: • Definir e controlar as interfaces • Integrar todas as componentes do sistema.A descentralização é boa, mas para não se transformar em caos, precisa duma arquitectura.E uma arquitectura é a representação dos elementos-chave de tecnologia de informação de umaorganização e do seu impacto no negócio.Componentes da arquitectura:Figura 3 – Componente da arquitectura dos sistemas de informação de uma organização(Velho, 2007)Contextualizando a arquitectura no domínio mais abrangente do IT Governance, poderemossumarizar os quatro pilares da função TIC na organização na seguinte figura:Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 12 Outubro 2011 | Revisão Bibliográfica.
  13. 13. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática MédicaFigura 4 – Os pilares da funçao tecnologias de informaçao e comunicaçoes numaorganização, (Velho, 2007)A tabela seguinte ilustra o framework de Zachman: Tabela 1 - Framework de Zachman, (Hay)David Hay, na comparação que efectuou da matriz de Zachman com o tradicional ciclo de vidado desenvolvimento dos sistemas de informação (SDLC), que compreende as seguintes etapas:Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 13 Outubro 2011 | Revisão Bibliográfica.
  14. 14. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática Médica • Estratégia – Planeamento global do desenvolvimento dos sistemas de informação de que a empresa necessita; • Análise – A documentação dos requisitos de uma determinada área de negócio • Desenho – A especificação do mapeamento dos requisitos da análise, nas tecnologias concretas a utilizar • Construção – a construção dos vários objectos que vão dar corpo à solução • Documentação – a preparação dos manuais de utilizador e de referência para descrever o sistema aos vários actores • Transição – a implementação do sistema, como mais um elemento articulado da estrutura tecnológica da empresa em termos das TIC. • Produção – O acompanhamento do sistema no dia a dia de modo a avaliar se continua a satisfazer as necessidades dos vários actores.Conclui que no que respeita à fase de análise a matriz de Zachman introduz duas perspectivasdistintas, uma que descreve a situação em termos da linguagem do negócio, enquanto a segundaembora não falando ainda de tecnologia, descreve a situação já na linguagem dos sistemas deinformação.No entanto a matriz de Zachman não se limita à especificação dos dados e funções na descriçãodo sistema a desenvolver. Incorpora também a necessidade de descrever os aspectosrelacionados com o local onde as operações acontecem, as pessoas que as executam, osmomentos em que devem acontecer e o que as justifica (motiva) na óptica da empresa.Do ponto de vista da abordagem de Widrig & Leffingwell, há uma analogia relevante entre a 1ªperspectiva, e o domínio do documento de visão que incorpora a necessidade e as característicasque a solução deve satisfazer e adoptar, e entre a 2ª perspectiva e o domínio dos requisitos desoftware que são já expressos em linguagem e modelos do domínio das tecnologias deinformação.As entidades certificadoras.A preocupação com a qualidade e abrangência das aplicações informáticas que suportam osregistos de saúde dos cidadãos, levaram à emergência de entidades certificadoras de aplicaçõesditas EHR. Pretendem estas entidades estabelecer um conjunto de requisitos mínimos quedevem ser observados pelos aplicativos em certificação no âmbito específico a que se destinam.Duas das entidades certificadoras mais conhecidas são a CCHIT (CCHIT, 2011) dos EUA, e aEuroRec (EuroRec, 2011) da EU.Do lado dos organismos de saúde compreende-se facilmente que gostariam que as suas escolhaspossuíssem o selo de entidades certificadoras internacionais para as áreas clínicas que nãonecessitem tanto de ‘localização’, o que a somar aos seus próprios requisitos os tranquilizariamais na sua escolha de modo a evitar falhas graves na solução escolhida e que só mais tarde noprocesso de implementação seriam detectadas.Qualquer uma das certificações do CCHIT contempla três subtipos de critérios de avaliação, • Funcionalidades • Segurança e PrivacidadeDomingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 14 Outubro 2011 | Revisão Bibliográfica.
  15. 15. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática Médica • Interoperabilidade no sentido da partilha de informação tendo em vista uma arquitectura NHIN ou HIE. Actualmente limita-se ao envio e recepção do sumário do paciente, tendo por referência o normativo HITSP C32 ou o HL7-CCD.Resumindo os métodos utilizados pela CCHIT para a avaliação da conformidade da aplicaçãoface aos critérios estabelecidos: Tabela 2 - métodos para avaliar conformidade CCHIT (CCHIT, 2011)A análise da documentação representa a auto-avaliação do fornecedor, face à lista de critériosestabelecidos pela CCHIT para a modalidade ou valência em certificação.A demonstração é realizada pelo fornecedor pela corrida dos scripts (guiões) estabelecidos, cujoresultado e acompanhado via ambiente Web pelos vários elementos do júri nomeado.No que respeita ao EuroRec (EuroRec, 2011) os requisitos são desenvolvidos, (na sua maioriarecolhidos de fontes já existentes, passam depois o crivo das respectivas equipas de avaliação), efinalmente arquivados no repositório central, são indexados via três categorias principais: • Funções de negócio o Total de 50 índices que incluem por exemplo autenticação, privacidade, planeamento de cuidados ou avaliação de necessidades de saúde. Estes índices estão agrupados em 8 subcategorias • Modalidades de prestação de cuidados o Total de 18 índices que incluem por exemplo cuidados hospitalares e cuidados primários. Estes índices estão agrupados em 3 subcategorias. • Tipo de componentes. o Total de 18 índices que incluem por exemplo componentes de interoperabilidade, ontologia ou terminologia. Estes índices estão agrupados em 4 subcategorias.O processo de certificação do EuroRec não parece estar ainda muito estruturado. É possívelacordar com a organização uma certificação centrada num determinado âmbito, seleccionado apartir dos índices disponíveis, o que permite recolher o repositório um conjunto de ‘good praticerequirements’ que serão testados a partir de guiões (scripts) e cenários de teste construídos parao efeito.Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 15 Outubro 2011 | Revisão Bibliográfica.
  16. 16. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática MédicaEstes requisitos de boas práticas, tem associados a si declarações mais detalhadas e focadas, asdesignadas ‘fine grained statements’ que deverão ser também testadas nas suas particularidadesnos respectivos guiões (scripts) e cenários de teste.Qualquer uma das entidades certificadoras, alarga o seu âmbito de certificação além do hospital,sendo que no caso da EuroRec este alargamento está claramente expresso no classificador demodalidades de prestação de cuidados.O caso de estudo como metodologia deinvestigação científica.Os sistemas de informação são uma ciência social (Caldeira, 2004) citando Rivas, (1989).Caldeira (Caldeira, 2004) citando Frankfort-Nachmias (1992) esclarece que o objetivo principaldas ciências sociais é produzir um corpo de conhecimento confiável, que nos permita explicar,prever e perceber o mundo social.Peter Drucker, conhecido filósofo da gestão, citado por (Gummesson, 2000), afirma que agestão não é, nem nunca será, uma ciência tal como a cultura ocidental entende ciência. Gestãoe Medicina são práticas, e como práticas alimentam-se de um corpo largo de ciências. A gestãoalimenta-se da economia, da psicologia, das matemáticas, da teoria politica, da história e dafilosofia. Mas tal como a Medicina, a Gestão é uma disciplina de direito próprio, com os seuspressupostos, os seus objetivos, os seus instrumentos, os seus objetivos de desempenho e osseus indicadores. Como disciplina autónoma de direito próprio, a gestão é o que os alemãesdesignam por ‘Geisteswissenschaft’, ou ciência social, ainda que na opinião de Peter Drucker‘ciência moral’ ou mesmo ‘arte liberal’ possam constituir melhores designações.A investigação centrada sobre os sistemas de informação e a gestão deve assim orientar-se pelasontologias, epistemologias e estratégias adequadas às ciências sociais.O pensamento neopositivista (Pereira, 2010) que teve como principais líderes o austríaco MoritzSchlick e o alemão Rudolf Carnap, separa o conhecimento à priori, que é lógico e matemático,do conhecimento científico que é empírico. O verificacionismo, base do pensamentoneopositivista, verifica-se de modo distinto em ambos os tipos de conhecimento. As verdadesmatemáticas e lógicas são estabelecidas por provas cujo método de verificação não precisarecorrer à experiencia, mas sim à dedução lógica. Na teoria científica, o conhecimento precisaser verificado empiricamente, na opinião dos neopositivistas.Assim qualquer investigação para gerar conhecimento científico, por pequena que seja a suacontribuição, necessita verificar no real esse mesmo conhecimento, e necessita fazê-lorespeitando um método que partindo de uma concepção filosófica do real, estabeleça umcaminho que proteja a investigação de enviesamentos e ajude o investigador a gerir o seupercurso.A estratégia de investigação adotada deve ter subjacente uma perspetiva filosófica que permitaperceber as crenças e assunções que o investigador tem sobre a natureza do fenómeno quepretende investigar (a sua ontologia) e o seu ponto de vista relativamente ao modo como podeadquirir conhecimento relativamente ao mesmo fenómeno (a sua epistemologia). Sustenta(Caldeira, 2004) que existe habitualmente uma relação forte entre a estratégia de investigaçãoadoptada e a perspectiva filosófica do investigador relativamente à ontologia da realidade ainvestigar e à epistemologia que acredita adequada para a conhecer. Os métodos de investigaçãoDomingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 16 Outubro 2011 | O caso de estudo como metodologia de investigação científica.
  17. 17. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática Médicanão são válidos por si mesmo. Necessitam de uma contextualização filosófica coerente com assuas práticas.Finalmente a estratégia de investigação deve instanciar-se num desenho concreto da aplicaçãoda estratégia genérica ao objecto de investigaçãoCaldeira apresenta a lógica inerente a esta sequência, neste slide:Figura 5 - Da realidade à estratégia de investigação, (Caldeira, 2004)(Caldeira, 2000) refere que o Realismo é uma perspectiva filosófica emergente, com a suaprópria ontologia e epistemologia. Citando Blaikie, “ Embora partilhe o desejo do positivismopara produzir explicações causais, e a perspectiva interpretativista na natureza da realidadesocial, o realismo argumenta uma visão da ciência distinta de ambas”.Clarifica a ontologia do realismo citando Bhaskar : “ as coisas existem e actuamindependentemente das nossas descrições, mas apenas as podemos conhecer em condiçõesparticulares”, ou seja a ciência é vista como uma tentativa sistemática de expressar empensamento, as estruturas e formas de actuar das coisas que existem independentemente dopensamento.Continuando a citar Bhaskar, Caldeira apresenta os três domínios da realidade, o empírico, oactual e o real, os quais servem para classificar experiências, eventos, mecanismos e estruturas.O empírico é feito das experiências, dos eventos que podem ser observados; O actual écomposto pelos eventos, quer possam ou não ser observados. O domínio do real consiste nasestruturas e mecanismos que produzem os eventos. O realismo é assim baseado na assunção queas abstracções que fazemos das estruturas e mecanismos (conceptualizações) e os eventos queobservamos (o domínio empírico) não representam completamente o real, seja as estruturas emecanismos, seja o actual. Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 17 Outubro 2011 | O caso de estudo como metodologia de investigação científica.
  18. 18. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática MédicaCaldeira (2004), apresenta esta ideia num slide alegre:Figura 6 - As ontologias do realismo crítico, do interpretativismo e do positivismo(Caldeira, 2004)Questiona (Mingers, 2004) o que são leis causais, ou antes o que é que causa ou gera oseventos, dadas as regularidades que podem ser estabelecidas nas experiências e a habitual faltade regularidade fora do âmbito fechado das experiências. De igual modo pergunta comopodemos assegurar-nos que as regularidades são baseadas em conexões reais em vez de simplescoincidências. A resposta que propõe é que deve existir entidades duradouras, físicas (p. ex.átomos ou organismos), sociais (p. ex. o mercado ou a família) ou conceptuais (p. ex. categoriasou ideias), observáveis ou não, que tem poder ou tendência para actuar de determinada maneira.A operação continua destas entidades e a sua interacção gera (i.e. causa) o fluxo dos eventos,mas é independente dele. As entidades podem ter esse poder, que no entanto não exercem numdado momento (pode ser necessário uma experiência para o desplotar), ou o poder pode serexercido mas não se manifestar em eventos, por causa de actuação contrária de quaisquer outrosmecanismos generativos.(Almeida, 2005) citando Bryman e Bell (2003) afirma que o Realismo Crítico implica que aocontrário do positivismo que pressupõe que a conceptualização do cientista sobre a realidadeDomingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 18 Outubro 2011 | O caso de estudo como metodologia de investigação científica.
  19. 19. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática Médicareflecte directamente a realidade, o realismo crítico afirma que a conceptualização do cientista ésimplesmente uma forma de conhecer essa realidade.Do ponto de vista epistemológico, Caldeira (2000), cita Blaikie, para justificar que o realismocrítico é metodologicamente aberto, ou seja não define uma metodologia específica. “ Orealismo está relacionado com métodos de desenvolvimento apropriados à situação particularque pretende investigar”. De novo o princípio, que embora aceite que o mundo social é real eexiste, aceita também a perspectiva interpretativista que a sociedade é produzida e reproduzidapelos seus membros, os quais podem ter percepções e interpretações diferentes da mesmarealidade.Estratégia de investigação ou abordagem metodológicaadoptada neste trabalho.Caldeira (2000) e Mingers (2004), citando Orlikowski & Baroudi (1991) e Farhoomand (1992)esclarecem que a investigação nos sistemas de informação tem vindo a ser dominada por trêsestratégias dominantes; a experimentação laboratorial, os inquéritos e os estudo de casos. Aevolução desta área relativamente recente do conhecimento (SI/TI), dum foco inicial natecnologia para uma cada vez maior ênfase nas questões sociais, levou a uma mudança numaperspectiva mais positivista inicial para uma perspectiva mais interpretativista. Citando Galliers(1992) “os investigadores dos sistemas de informação estão-se a dar conta das limitações dasaproximações científicas do seu trabalho, dada a natureza técnico-sociológica do seu campo deinvestigação”.Yin, citado por Gummesson (2000), distingue três tipos de estudo de casos em investigação:exploratório, descritivo e explicativo. Uma crítica frequente na investigação via estudo de casosé que esta abordagem é inferior relativamente aos métodos baseados em amostragem estatísticade um número elevado de observações. Em investigação médica são caracterizados como‘anedóticos’, ou seja de validade científica limitada, embora úteis para a formulação dehipóteses a testar. Esta atitude vigente leva habitualmente os investigadores que suportam o seutrabalho via estudo de casos, a apresentarem as suas conclusões, com algumas defesas do tipo‘naturalmente estas conclusões são insuficientes para generalizar; este estudo deve ser vistocomo exploratório na procura de hipóteses que devem ser posteriormente testadas.’Gummesson recorda no entanto que Hipocrates, conhecido como o pai da medicina, suportou oseu trabalho pioneiro em alguns casos apenas.Normann, citado por Gummesson (2000), afirma que se o investigador tem uma boa linguagemdescritiva e analítica, através da qual consegue perceber a interacção entre as várias partes dosistema e as características mais importantes do mesmo, a possibilidade para generalizar oconhecimento a partir de poucos casos de estudo, pode ser razoavelmente boa. As possibilidadespara generalizar a partir de um único caso terão de ser suportar na compreensão plena e nasmedidas que permitem atingir a compreensão fundamental da estrutura, dos processos, e dasforças impulsionadoras do sistema, o que é muito mais do que estabelecer uma correlação decausa e efeitos entre algumas variáveis.Escreve (Yin, 1994) que o estudo de caso é preferível na examinação de eventoscontemporâneos, quando os comportamentos relevantes não podem ser manipulados. O estudoDomingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 19 Outubro 2011 | O caso de estudo como metodologia de investigação científica.
  20. 20. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática Médicade caso sustenta-se em muitas das mesmas técnicas da Historia, mas adiciona duas fontes deevidência que a estratégia histórica habitualmente não contempla, a observação directa e aentrevista sistemática.Finalmente a estratégia de investigação deve instanciar-se num desenho concreto da aplicaçãoda estratégia genérica ao objecto de investigaçãoO desenho instanciado da investigação:Figura 7 – da estratégia de investigação ao desenho explicito da mesma(Caldeira, 2004)Action research/Action Science.Gummesson (2000), afirma que o método de ‘action research’ ou ‘action science’ é o maisexigente e com maior potencial de sucesso da investigação dos casos de estudo.‘Action Research’, (Baskerville, 2004) tem como finalidade resolver problemas concretosenquanto expande o conhecimento científico.‘Action research’ é uma forma de aprender acerca de um sistema social e simultaneamente otentar mudar.Gummerson estabelece 10 pontos para esclarecer o seu conceito de ‘management actionscience’ que foca o método no estudo das organizações:Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 20 Outubro 2011 | O caso de estudo como metodologia de investigação científica.
  21. 21. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática Médica 1. Os cientistas/investigadores agem sobre a organização. São agentes de mudança sobre os próprios processos e eventos que estudam. 2. A ‘Action science’ tem duas finalidades, contribuir para o cliente (a organização) e para a ciência. 3. A ‘action science’ é interactiva, requer cooperação entre os investigadores e os colaboradores da organização e ajuste continuo a novos dados e novos eventos que vão surgindo. 4. A compreensão desenvolvida durante um projecto de investigação debaixo do método de ‘ action science’ pretende ser holístico, reconhecendo as complexidades. A investigação por estudo de casos, onde se insere a ‘action science/action reseach’, é realizada para ter acesso às realidades complexas e à realidade que pertence à parte escondida debaixo do iceberg, que corresponde a 90% da sua massa/volume. 5. ‘Action science’ é aplicável à compreensão, planeamento e implementação da mudança nas organizações. 6. É essencial perceber a base ética, os valores e normas que devem guiar a investigação num projecto concreto. 7. ‘Action science’ pode incluir todos os tipos de métodos para geração de dados, mas necessita do total envolvimento do investigador. Acesso à realidade pode fazer-se via métodos qualitativos, informais, entrevistas detalhadas, métodos etnográficos de observação e participação e qualquer outros. 8. Aplicar construtivamente o conhecimento prévio (pre-understanding) do ambiente da organização e das condições onde o negócio decorre é essencial. 9. ‘Action science’ deve ser conduzida preferencialmente em tempo real, mas retrospectivamente é também uma opção. 10. O paradigma da ‘action science’ requer o seu próprio critério de qualidade. A ‘action science’ deve ser governada pelo paradigma ‘hermenêutico’ (interpretativismo) embora elementos do paradigma positivista possam ser incluídos.Fica assim justificada a relevância dos dados recolhidos pelo investigador enquanto participantedo projecto da construção do caderno de encargos do CHVNG para este trabalho.Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 21 Outubro 2011 |
  22. 22. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática MédicaObjectivo do trabalho – as questões deinvestigação.O domínio da investigação deste trabalho foca-se na forma e no conteúdo dos requisitos quecompõem os anexos técnicos dos cadernos de encargos associados a sistemas de informaçãohospitalares, e centra-se na análise das seguintes questões/temas particulares: • Tema1- Processo de desenvolvimento do anexo técnico do caderno de encargos: • Gestão do Projecto – Organização Interna • Período e duração • Em termos percentuais onde o situam? Do lado da visão (necessidades e features) versus requisitos de software ? • Tema 2 - Impacto: • Adequado para proteger o contrato estabelecido? • Assegura a cobertura do que a instituição pretende? • Em que medida o caderno de encargos está a impactar o que está a acontecer na prática da implementação da solução? • Tema 3 - De que modo é que os requisitos/critérios das entidades certificadoras contribuíram para a redacção do caderno? • Teria sido útil considerá-las como fonte para a redacção do mesmo? • Como classificam/situam estes critérios? Do lado da visão ou do lado da especificação de requisitos software?Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 22 Outubro 2011 | Objectivo do trabalho – as questões de investigação.
  23. 23. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática MédicaMétodos para a Recolha de DadosForam utilizados três métodos para recolha de dados que permitissem encontrar respostas àsquestões colocadas : • Entrevistas a dois hospitais que recentemente lançaram para o mercado cadernos de encargos para SIH, o IPO do Porto e o CHVNG e a dois fornecedores destas soluções, a HP e a Glintths; • A experiencia vivida pelo próprio autor no desenvolvimento do caderno de encargos do CHVNG; • O estudo dos dois cadernos de encargos produzidos por ambas as instituições, bem como os documentos disponíveis pelas entidades certificadoras, CCHIT e EuroRec, centrados na modalidade de internamento hospitalarA escolha dos hospitais resultou do critério conveniência, dado que o IPO do Porto estava aviver a implementação do projecto que resultou do concurso internacional subordinado a umcaderno de encargos para um SIH, e o CHVNG tinha lançado no mercado o seu concurso erespectivo caderno de encargos recentemente e o investigador deste trabalho participou na suacriação.A escolha dos fornecedores resultou do facto da Glintths ter ganho o concurso do IPO do Portoe da HP ter participado em vários concursos para a escolha de sistemas de informaçãohospitalares que nos últimos anos ocorreram no mercado português.E naturalmente do facto das várias instituições se mostrarem disponíveis para participarem nestetrabalho, solicitação que lhes foi formalmente enviada.Os documentos que materializam os cadernos de encargos de ambas as instituições são dodomínio público.Os documentos que materializam os requisitos-critérios das entidades certificadoras, no querespeita à CCHIT estão disponíveis no seu site oficial, e no caso da EuroRec, após contacto viaemail com o seu presidente, foi possível aceder ao site da entidade, navegar e exportar osrequisitos-critérios adequados.Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 23 Outubro 2011 | Métodos para a Recolha de Dados
  24. 24. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática MédicaResultadosEntrevistasPara suportar estas entrevistas semi-estruturadas foi desenvolvida uma pequena apresentação em‘power-point’ que sintetiza os objectivos do trabalho, a revisão bibliográfica na óptica do que seentende por requisitos de software e por requisitos-critérios de entidades certificadoras, e asquestões/temas para as quais se procuram respostas, recordando: • Tema1- Processo de desenvolvimento do Caderno de Encargos: • Gestão do Projecto – Organização Interna • Período e duração • Em termos percentuais onde o situam? Do lado da visão (necessidades e features) versus requisitos de software ? • Tema 2 - Impacto: • Adequado para proteger o contrato estabelecido? • Assegura a cobertura do que a instituição pretende? • Em que medida o caderno de encargos está a impactar o que está a acontecer na prática da implementação da solução? • Tema 3 - De que modo é que os requisitos/critérios das entidades certificadoras contribuíram para a redacção do caderno? • Teria sido útil considerá-las como fonte para a redacção do mesmo? • Como classificam/situam estes critérios? Do lado da visão ou do lado da especificação de requisitos software?Entrevista com IPO do Porto.Entrevista realizada no IPO do Porto dia 2011-08-02, com o Director de Informática, EngºRenato Magalhães.Tema 1 - Processo de desenvolvimento do Caderno de Encargos :A componente técnica do caderno de encargos para o SIH, foi atribuída à Direcção deInformática, no último semestre de 2006, que dada a natureza estruturante do projecto deveriaser realizado por uma organização com provas dadas neste domínio com a natural colaboraçãodo Serviço de Informática. Todo este processo foi realizado rapidamente dada a urgência doConselho de Administração do IPO do Porto em substituir a solução anterior. Foramconsultadas duas entidades, mas a escolha recaiu na Netvita pois apresentou o preço mais baixoe já tinha desenvolvido o caderno de encargos para os Açores, no âmbito do projecto AçoresSaúde.Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 24 Outubro 2011 | Resultados
  25. 25. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática MédicaForam enviados questionários aos vários serviços do IPO, centrados na identificação das suasnecessidades. Esta foi a fase do projecto que mais demorou. Na sequência das respostasrecebidas, foram efectuadas algumas entrevistas com alguns serviços. Houve também lugar aentrevistas com o Conselho de Administração. Em paralelo a Netvita fez uma análise ao sistemainstalado.No início de 2007 a componente técnica do caderno de encargos foi entregue ao IPO nocontexto de uma apresentação ao vogal do CA responsável pela informática. Foi aindaadicionado um conjunto de linhas orientadoras de natureza tecnológica (requisitos nãofuncionais) produzidos pela Direcção de Informática, e a componente jurídico-administrativapelo Serviço de Aprovisionamento, o que acresceu mais dois meses à conclusão do caderno deencargos para ficar em condições de ser colocado no mercado.A implementação de todos os módulos do projecto que inclui a substituição do SIH está emcurso.Do ponto de vista da organização do projecto, a Netvita articulou sempre com Director deInformática, e não foi estabelecida nenhuma equipa de projecto do lado do IPO paraacompanhar e contribuir para o desenvolvimento do mesmo.A componente técnica do caderno produzido, situa-se sobretudo no domínio da especificação denecessidades e características que a solução deve satisfazer/respeitar.Tema 2 - Impacto :Do ponto de vista do impacto que o caderno de encargos teve e está a ter na implementação dosvários sistemas que o mesmo contempla, incluído o SIH no IPO, uma preocupação foitransmitida: ‘vamos ter uma solução que responde às necessidades apresentadas, mas dado que éuma solução standard do fornecedor, em algumas opções vai obrigar-nos a adaptarmo-nos àsolução quando deveria ser a solução a ir de encontro com a nossa realidade.’Por exemplo quando o médico recebe um doente que necessita de medicação urgente e o actoadministrativo que suporta essa sessão/episódio ainda não está criado, o médico não podeprescrever. Ora o médico gostaria que o sistema prescritor, neste caso, comunicasse com acomponente gestor de actos e lhe permitisse efectuar a prescrição no momento, sem ter dedevolver o utente ao administrativo. Continua a ser capaz de prescrever, mas necessita que oregisto do utente nesta admissão directa, aconteça primeiro.Seria útil que o ‘workflow’ das operações tivesse sido suficientemente detalhado para que asnossas necessidades fossem satisfeitas do modo que pretendemos, e não de um modo que assatisfaçam mas que não é exactamente o modo que queremos no IPO, porque o sistema é asolução standard do fornecedor.Ou então seria útil que o próprio SIH fosse capaz de permitir configurar facilmente a sequênciadas operações.Com o nível de detalhe da especificação de requisitos, é a solução do fornecedor que se impõe ea organização tem de se adaptar, o que gera frustração: ’se a organização já fazia bem porquetem de mudar ?Esta preocupação levantou a questão de saber como seria possível na opinião do entrevistado,ao longo do processo de análise das propostas detectar e minimizar este risco.Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 25 Outubro 2011 | Resultados
  26. 26. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática MédicaUm dos factores pode estar no facto do IPO não ter escolhido a melhor solução técnica que lhefoi proposta pela equipa técnica responsável por esta avaliação. Provavelmente escolheu amelhor solução económica, mas não técnica.A Comissão técnica constituída pelo Engº Renato Magalhães, Drª Raquel Deveza da ACSS eEngº Carlos Ribeiro da ARSN, analisaram as propostas à luz de um conjunto de factores: • Modernidade; • Usabilidade; • Capacidade de Adaptação e evolução; • Interoperabilidade; • Arquitectura; • Ferramenta de BI; • Adequação aos requisitos; • Migração de dados; • Soluções idênticas já implementadas.E em função destes, hierarquizaram as várias propostas. A solução escolhida não fazia parte dastrês melhores em termos da avaliação técnica.Não houve também no processo de escolha visitas por parte do Júri a implementações dosvários fornecedores. Em alternativa foi disponibilizado a cada concorrente uma sala parainstalar as soluções para que o júri e potenciais utilizadores as pudessem avaliar.Tema 3 - De que modo é que os requisitos/critérios das entidades certificadoras contribuírampara a redacção do caderno ?No que respeita a requisitos-critérios das entidades certificadoras, não foram considerados nodesenvolvimento do caderno de encargos. Houve sim a preocupação que a solução finalintegrasse standards internacionais.Entrevista com HP.Entrevista realizada em V.N.Gaia dia 2011-07-27, com o Eng Carlos Barreira e a Drª AnaMorais.Tema 1 - Processo de desenvolvimento do Caderno de Encargos :Em termos gerais os cadernos de encargos focados em SIH centram-se mais na descrição dasnecessidades e ‘features’ e raramente nos requisitos de software propriamente dito.A maioria dos cadernos de encargos na sua componente técnica de caracterização dos SIHtraduzem sobretudo uma vontade do cliente de percorrer um caminho até chegar a uma soluçãopara seu problema e não propriamente a especificação dessa solução.Do lado da HP quanto mais detalhado o caderno de encargos melhor, porque permite à equipaauditora do projecto avaliar com mais rigor o risco associado à entrega da solução ao cliente edeste modo tornar mais fácil a aprovação da proposta a enviar ao cliente.Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 26 Outubro 2011 | Resultados
  27. 27. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática MédicaQuando o mercado não conhece a história associada ao caderno de encargos e o mesmo é muitodetalhado, fica o receio de que possa ter sido desenvolvido por um fornecedor especifico, o queadultera as condições de igualdade de concorrência.Muitas vezes os cadernos têm níveis de detalhe muito distintos ao longo das várias áreas. Porexemplo podem ser muito pormenorizados na descrição do internamento, mas quase não fazemreferência aos mecanismos de interoperabilidade que a solução deve prover.Outro aspecto que muitas vezes falta nos cadernos de encargos é a exigência aos fornecedoresacerca do estado actual da sua solução para responder a cada um dos requisitos estabelecidos. Sejá existe, se existe parcialmente, se terá de ser desenvolvido. Esta tabela/matriz ajudaria adistinguir o grau de maturidade das soluções propostas, face à necessidade apresentadaTema 2 - Impacto :O risco do cliente chegar a uma solução que responde aos requisitos mas que não respeita omodo como o hospital está habituado a trabalhar, é reconhecido pela HP. E este risco é muitoperigoso num hospital onde habitualmente os utilizadores médicos tem uma força muitoconsiderável, e podem bloquear todo um projecto de implementação.Na tentativa de gerir o mais rapidamente que é possível as expectativas dos utilizadores, após aadjudicação, a HP olha para o caderno de encargos e constrói um ‘statement of work’ ondepor via de texto, mas sobretudo de prototipagem sobre o seu produto, explica ao cliente comovai responder aos vários requisitos.Tema 3 - De que modo é que os requisitos/critérios das entidades certificadoras contribuírampara a redacção do caderno ?Os entrevistados não conheciam nem encontraram nos cadernos de encargos analisadosreferência aos requisitos-critérios da CCHIT ou da EuroRec.Entrevista com Glintths.Entrevista realizada nas instalações da Glintths no Porto, dia 2011-08-09, com os Engs RuiHenriques, Orlando Rodrigues e Nuno Ribeiro.Tema 1 - Processo de desenvolvimento do Caderno de Encargos :De acordo com a sua experiencia também situam os requisitos da componente técnica doscadernos de encargos dos SIH a que tiveram acesso, no domínio da visão da solução, isto é, nadefinição das necessidades e características que a solução deve ter.Na verdade raramente se confrontam com cadernos de especificação de requisitos que vão alemdisso, mesmo para âmbitos mais limitados do que um SIH. Um exemplo desta excepção foi arecente especificação da prescrição electrónica enviada aos fornecedores que pretendamcertificar a sua solução.Na óptica do fornecedor demasiado detalhe na especificação de requisitos pode não ser benéficopara quem já tem um produto maduro, porque pode ter mais dificuldade em adaptá-lo arequisitos particulares, do que outro fornecedor que ainda vá construir a solução.Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 27 Outubro 2011 | Resultados
  28. 28. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática MédicaÉ normal o caderno de encargos ser desequilibrado no detalhe dos seus componentes e isso poderesultar de várias causas: • Um grupo de pressão muito forte que imponha uma lista de requisitos longa e detalhada num dado domínio • Uma aplicação sectorial que já funcione bem e seja replicada em termos funcionais para o caderno de encargos • Do próprio desequilíbrio em termos de competência/experiencia dos vários key-users das várias áreas que contribuem para a especificação de requisitos. • Falta de contributo em algumas áreas, que aparecem no caderno de encargos com sínteses muito breves das suas necessidades.Tema 2 - Impacto :Reconhecem o risco do cliente obter uma solução que responda as necessidades espelhadas nocaderno de encargos, mas obrigue o mesmo a desenvolver o seu trabalho de modo muitodiferente do que pretendia.Este risco do ponto de vista da sequência das operações, não se resolve com a descrição dosmacro processos a serem suportados, dado que é no detalhe particular que estas dificuldadessurgem.Muitas delas resultam também de inferências indevidas que os utilizadores fazem, do género, sea aplicação faz isto, então não é lógico (expectável) que faça também aquilo?Admitindo que os cadernos de encargos de um SIH se focará sempre no domínio da visão, asaproximações seguintes podem ajudar a minimizar o risco identificado: • Bom senso entre as partes. Não fazer finca pé em todas as questões que possam surgir. • Ir ver soluções a funcionar e preparar a visita para fazer as perguntas certas. Habitualmente quem recebe, é lisonjeiro para a solução do fornecedor, mas responde honestamente às questões que são colocadas. • Pedir ao fornecedor demonstrações do produto. Este é habitualmente o espaço mais aberto e disponível para ficar a saber como a sequência das operações se faz no seu detalheA Glintths tem vindo também a adoptar a abordagem da prototipagem para, após a adjudicação,explicar aos utilizadores como a solução se implementa no seu produto, nivelando o mais cedopossível as expectativas dos utilizadores.Tema 3 - De que modo é que os requisitos/critérios das entidades certificadoras contribuírampara a redacção do caderno ?Os entrevistados não conheciam nem encontraram nos cadernos de encargos analisadosreferencias aos requisitos-critérios da CCHIT ou da EuroRec.Entrevista com CHVNG.Entrevista realizada nas instalações do CHVNG, em Vila Nova Gaia, dia 2011-08-05, com oEngº Manuel Sousa.Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 28 Outubro 2011 | Resultados
  29. 29. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática MédicaTema 1 - Processo de desenvolvimento do Caderno de Encargos :O projecto para o desenvolvimento da componente técnica do caderno de encargos para o SIHdo CHVNG, decorreu ao longo de 2009. Do lado dos consultores externos este trabalho foiadjudicado à MakeSense e contou com a participação do Engº Manuel Sousa e o Engº NunoFernandes.Do lado do CHVNG, a direcção do projecto foi atribuído ao director de informática doCHVNG, e contou com a participação de um conjunto de key-users que na sua maioria fazemparte da equipa nomeada pelo Conselho de Administração para participarem na reflexão para odesenvolvimento do sistema de informação do CHVNG.A equipa consultora já tinha participado no desenvolvimento do plano director para os sistemasde informação no CHVNG e como tal conhecia bem a instituição. O Engº Manuel Sousadesenvolveu trabalho semelhante para o Centro Hospitalar do Porto. Esta experiênciacumulativa permitiu obter rapidamente uma primeira versão do caderno técnico, que foienriquecida pelos key-users nos vários domínios, e após 3 iterações o caderno foi fechado emdezembro de 2009.Em alguns casos houve necessidade de fazer uma síntese de propostas muito detalhadas emtermos do modo de execução das tarefas que chegaram à equipa consultora. Por um lado porquese achou que haveria que equilibrar o nível de detalhe de cada componente do caderno deacordo com o seu grau de importância e por outro porque demasiado detalhe poderia limitar aspropostas do mercado.Do ponto de vista do entrevistado, os requisitos documentados, sobretudo os funcionais sãosobretudo a apresentação detalhada da necessidade do CHVNG em termos de funcionalidadesdo SIH. Em algumas situações há lugar a uma descrição da sequência pretendida das operações,mas num nível de abstração elevado.Tema 2 - Impacto :Não há, à data desta entrevista, experiência sobre o eventual impacto do caderno técnico naimplementação da solução. O concurso internacional já iniciado está suspenso, a aguardarratificação para poder prosseguir.No entanto o risco de o CHVNG poder optar por uma solução que, respondendo aos requisitosexpressos, possa no entanto obrigar os utilizadores a um modo de realizarem o seu trabalhodiferente do que pretendem, é reconhecido.Seria preciso um detalhe da sequência de passos necessários para concluir cada operação para osvários momentos/eventos que as despoletasse, incompatível com o âmbito temporal para odesenvolvimento do caderno.As respostas produzidas pelo CHVNG aos longos pedidos de esclarecimentos, bem como apossibilidade imposta no concurso de ir ver as soluções propostas a funcionar, podem ajudar aminimizar este risco.Tema 3 - De que modo é que os requisitos/critérios das entidades certificadoras contribuírampara a redacção do caderno ?O caderno de encargos não teve em linha de conta os requisitos-critérios da CCHIT e daEuroRec.Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 29 Outubro 2011 | Resultados
  30. 30. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática MédicaSeria útil ter olhado para eles durante o período de desenvolvimento do caderno de encargos.Mais útil seria ainda que a ACSS tivesse já evoluído suficientemente o trabalho com a EuroRecno sentido de criar e adoptar um conjunto de critérios e provas que permitissem aosfornecedores de soluções hospitalares, certificarem o seu software. Tal facto permitiria tambémàs entidades hospitalares uma maior confiança na selecção e adopção de soluções, simplificandoo processo ao nível da garantia de cumprimento de um conjunto de requisitos basilares.A experiência do investigadorEnquanto responsável pelo Serviço de Informática e Tecnologias de Informação do CHVNG,fui o chefe de projecto designado para gerir do lado do CHVNG o desenvolvimento do cadernode encargos para o SIH, coordenando e envolvendo a equipa de key-users designados para oefeito e a relação com os consultores contratados para este projecto, e chefiados pelo EngºManuel Sousa.O caderno de encargos foi construído ao longo de 2009, tendo por base trabalho já desenvolvidopelos consultores em trabalhos anteriores, e depois muito enriquecido pela experiencia econhecimento que os key-users do CHVNG transferiram para o documento, ao longo das váriasiterações e versões que o mesmo foi tendo.O CHVNG formalizou em 2008 uma equipa de key-users com a missão de acompanharem econtribuírem para o desenvolvimento da arquitectura do SI do CHVNG. Esta equipa surgiunaturalmente a partir dos utilizadores mais envolvidos em projectos TIC em 2007.Embora centrados sobre a componente de visão do caderno de encargos (especificação denecessidades e características a que o SIH deve dar resposta) acrescentaram muito valor aocaderno técnico acrescentando-lhe muitos detalhes neste domínio. Embora de acordo com arevisão bibliográfica as frases/declarações acrescentadas se situem no domínio da visão, o que éfacto e que podem a esse nível ser muito detalhadas, não se ficando, como os autoresconsultados sugerem, num máximo típico a rondar as 50 declarações.O facto do projecto se ter desenvolvido ao longo de um ano, permitiu também que a equipa setenha sentido confortável com o resultado final, em termos de sentir que o ganho marginal quepoderia resultar em aguardar mais tempo poderia não ser relevante.No que respeita aos requisitos ditos não funcionais, atributos do sistema como a segurança eatributos do contexto onde o sistema vai correr, como a interoperabilidade aplicativa com outrasaplicações que não fazem parte do SIH em concurso, essa reflexão ficou naturalmente do meulado e do lado dos consultores. Os key-users participaram pouco nela.Também aqui as especificações produzidas se situem mais no domínio das características arespeitar, do que a especificação mais técnica própria do domínio da especificação de software.Um bom exemplo disso mesmo, é a preocupação que tivemos em clarificar que o CHVNG podedecidir optar por manter as suas aplicações de prescrição medicamentosa e de MCDTs, dado ograu de integração que já possuem com a Logística e as aplicações que suportam a produção dosvários RIS (Radiology Information Systems) e LIS (Laboratory Information System), e queficou refletida no 2º paragrafo da capitulo 4.5 do caderno de encargos.Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 30 Outubro 2011 | Resultados
  31. 31. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática MédicaA reflexão que deu origem a este paragrafo preocupou-se também em assegurar que no caso doCHVNG decidir manter as aplicações, há que garantir ao utilizador uma experiencia decontinuidade na navegação entre aplicações, sem no entanto especificar tecnicamente de quemodo tal será possível de obter, embora o capitulo 3.8 estabeleça alguns constrangimentos paraa implementação da interoperabilidade aplicativa.Um outro requisito de contexto que entendemos documentar, é o desenho da ‘arquitectura’entendida como um conjunto de componentes maioritariamente de natureza funcional que ajudaa limitar as fronteiras, o domínio interno do caderno de encargos e das conexões mais relevantesdos vários componentes. Este ‘boneco’ que surge no capítulo 2.2 do caderno de encargosarticulado com a matriz de integração entre as aplicações ajuda a contextualizar o âmbito dotrabalho a desenvolver e a planear e coordenar o mesmo, quer da componente técnica docaderno de encargos, quer mais tarde da própria elaboração da proposta do lado do fornecedor.Foi esta visão sintética do âmbito do projecto que nos facilitou já em 2010 realizar a ultimaalteração ao caderno de encargos. Numa reunião com um representante da Oracle responsávelpela Europa do Sul, e depois de lhe explicarmos o que pretendíamos fazer com este caderno deencargos, o senhor falou-nos nas soluções que conhecia em termos europeus e dos estadosunidos, e reforçou o nosso sentimento que se pudéssemos fazer conviver a nova solução comuma solução oferecida pela Tutela para assegurar os requisitos de facturação do serviço nacionalda saúde, das estatísticas legais a que o hospital está obrigado, isso seria muito útil, dado quenem sempre é fácil aos fornecedores acompanharem com a velocidade necessária as alteraçõesimpostas pela Tutela neste domínio. A experiencia que conhecia em França, o senhor é francês,tinha sido esta.Esta conversa levou-nos a constituir um sub-lote a que chamamos ‘sonho reduzido’ quepreferencialmente seria satisfeito pela ACSS no quadro da sua actualização do Sonho actual ecom a qual a restante solução terá de interagir no quadro de referencia dos mecanismos deinteroperabilidade identificados. Se tal não acontecer ao fim do primeiro ano de projecto, oadjudicatário terá de o instalar no CHVNG também.Também este requisito se situa no domínio da necessidade a satisfazer e não no domínio daespecificação de software, ou seja na perspectiva do ‘owner’ e da sua capacidade de especificarutilizando linguagem do seu negócio e não os modelos e técnicas que o analista funcional,‘designer’ na perspectiva do ‘framework’ Zachman, conhece e tem à sua disposição.Após o desenvolvimento da componente técnica do caderno de encargos a enviar ao mercado,designado como ‘Cláusulas Técnicas Especiais do Caderno de Encargos’ houve duaspreocupações que nos ocuparam: • Como iriamos evitar que nos surgissem propostas de fornecedores sem experiencia e capacidade financeira para aguentar um projecto desta natureza? • Como iriamos conseguir tomar conhecimento, sentir as soluções propostas em cada caso, em matérias tão áridas em termos de discurso escrito, como usabilidade ou detalhes específicos do modo como o produto executa as operações.No primeiro caso decidimos adoptar a figura de concurso internacional com prévia qualificação.Dos cerca de seis fornecedores que conhecíamos com soluções SIH a operar no mercadonacional, 4 foram qualificados, e mais tarde o 5º que inicialmente foi excluído, ganhou a acçãoque interpôs em tribunal.O 6º foi excluído, por razões exclusivamente de forma.Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 31 Outubro 2011 | Resultados
  32. 32. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática MédicaRelativamente ao segundo risco, incluímos no artigo 17º – proposta, na alínea g), aobrigatoriedade do fornecedor nos facultar uma visita a um hospital que tenha a sua solução atrabalhar e na alínea h) a possibilidade de exigirmos outro tipo de documentação que o júrientenda necessária para a sua avaliação, o que pode incluir demonstrações dirigidas da solução.Um elemento que deverá contribuir para esclarecer os fornecedores do modo como pretendemosque a solução funcione no CHVNG, serão com certeza as respostas aos pedidos deesclarecimentos colocadosNeste momento o concurso está suspendo a aguardar a autorização da titula conjunta doministério da saúde e das finanças para o retomar, dado que o investimento previsto ultrapassaos 5% do capital social do CHVNG, e no actual contexto económico de Portugal, taisinvestimentos públicos necessitam ver a sua autorização ratificada de novo.Análise de documentosNo que respeita ao 3º tema, o contributo dos requisitos-critérios para o enriquecimento docaderno de encargos, na sua componente técnica, as entrevistas e a própria experiencia do aluno,não permitiram recolher dados que permitam alguma reflexão e conclusões.Analisando os documentos disponíveis, em particular os 300 requisitos-critérios da CCHIT2011 para o internamento hospitalar, é possível arrumá-los facilmente nos seguintesagregadores: • Informação administrativa e demográfica do paciente – 6 requisitos • Informação do prestador de cuidados – 6 requisitos • Lista de problemas – 11 requisitos • Informação sobre alergias – 20 requisitos • Lista de medicação – 18 requisitos • Requisitos genéricos sobre prescrição – 26 requisitos • Protocolos ou conjuntos de prescrições – 19 requisitos • Prescrição de Medicamentos – 22 requisitos • Apoio na decisão de prescrição de Medicamentos e vacinas – 41 requisitos • Reconciliação de Medicamentos – 10 requisitos • Suporte genérico para a decisão clinica – 5 requisitos • Administração de medicamentos – 31 requisitos • Administração de vacinas – 12 requisitos • Gestão da actividade de prestação de cuidados – 6 requisitos • Registo de instruções específicas do paciente – 2 requisitos • Gestão do registo de saúde do paciente – 3 requisitos • Geração de documentação clinica – 2 requisitos • Integração aplicativa/funcional – 8 requisitos • Perfil de acessos – 4 requisitos • Auditabilidade – 9 requisitos • Autenticação – 12 requisitos • Documentação sobre a administração da solução – 10 requisitos • Serviços técnicos a disponibilizar – 9 requisitos • Backup e recuperação – 3 requisitosDomingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 32 Outubro 2011 | Resultados
  33. 33. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática Médica • Outros – 5 requisitosO grau de detalhe destes requisitos-critérios é elevado. Por exemplo, os que respeitam aosubgrupo de geração de documentação clinica, estabelecem o seguinte:IO-OP.01.20 – O sistema deve fornecer a possibilidade/funcionalidade de visualizardocumentos que sigam a norma HITSP C32/CCD e guardá-los de modo intacto no processoclinico electrónico do paciente;IO-IP.01.22 – O sistema deve fornecer a possibilidade/funcionalidade de gerar e formatardocumentos com o sumário do paciente de acordo com a norma HITSP C32 (v2.3 ou v2.5).Oregisto do sumário do paciente deve incluir informação demográfica do paciente, os seusmedicamentos e as suas alergias clinicas. Os documentos XML gerados devem demonstrar ouso de vocabulários e terminologias standard na indústria. O objectivo é testar os camposobrigatórios incluindo o código de produto para a medicação e alergia.Embora ambos os cadernos estudados façam referência e estabeleçam como requisitos autilização das terminologias da indústria, apenas o caderno do CHVNG numa nota de rodapéfaz referência à possibilidade de gerar sumários clínicos a integrar no processo clinico dopaciente ao nível nacional. (pag 22, 2ª nota de rodapé).No que respeita ao subgrupo ‘Apoio na decisão de prescrição e administração de medicamentose vacinas’ estão expressos 41 requisitos com detalhe muito concreto enquanto em ambos oscadernos de encargos existem referências breves a esta matéria.Como exemplo do detalhe dos requisitos na lista do CCHIT:FN 12.05 – O sistema deve permitir ver o racional associado a um alerta sobre a interacçãomedicamentosaFN 12.06 – O sistema deve permitir capturar e manter pelo menos uma das razões quejustificaram que o alerta de interacção entre medicamentos ou entre medicamento e alergiasnão tenha sido tomado em atenção no momento da prescrição dos medicamentos.No caderno de encargos do CHVNG, na pag 25, no domínio do processo clinico, no ponto 11,pode ler-se um requisitos mais abstrato relacionado com apoio na decisão de prescrição:Associar fluxogramas de procedimentos com mecanismos automáticos de detecção, de forma apermitir a redução de erros médicos e a assistência à gestão do risco.E na pag 57, no domínio da prescrição medicamentosa, pode ler-se no ponto 10:Efectuar o registo de alergias e/ou reacções adversas com avisos de possível reacção commedicamentos prescritos com o principio activo que provoca o evento.Do mesmo modo no caderno de encargos do IPO do Porto na pag 45, no domínio dasprescrições, no ponto 4.a pode ler-se:Gerar alertas no acto da prescrição que informem o médico sobre a eventual existência desituações anómalas resultantes de interacções medicamentosas, fruto da validação daprescrição a efectuar em relação a eventuais problemas ou outra administração demedicamentos constante no processo clinico do utente.Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 33 Outubro 2011 | Resultados
  34. 34. FACULDADE DE MEDICINA DA UNIVERSIDADE DO PORTO FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO 2º Ciclo de Estudos em Informática MédicaOu seja, em ambos os casos, os requisitos que traduzem a preocupação com o apoio na decisãode prescrição e administração de medicamentos está muito mais sintetizada do que na lista dos41 requisitos critérios que o CCHIT estabelece para efeitos de certificação do software.É interessante reparar que o detalhe expresso nas declarações escritas em linguagem natural, ieno texto tradicional, sugere que os seus autores são agentes do ‘negócio’ ie, são profissionais desaúde que conhecem bem as suas necessidades e as detalham a um nível muito elevado,transformando-as nas funções/capacidades que o novo sistema terá de ter.Foi este mesmo fenómeno que aconteceu no CHVNG nas várias interacções da construção docaderno de encargos, quando os profissionais envolvidos fizerem verter sobre a base propostamuito do seu conhecimento e experiencia com os sistemas que já usavam e ainda com aslimitações que lhes detectavamConclusõesEste capítulo sintetiza as conclusões que o plano de investigação me permitiu obter, tendopresente as questões/temas iniciais da investigação, que foram sendo refinadas ao longo dotrabalho.As limitações inerentes às conclusões apresentadasA metodologia de investigação respeitada neste trabalho permite, em meu entender, produzirconclusões, que embora válidas tendo presente os contextos e experiências de onde sãoextraídas, não devem ser consideradas como verdades absolutas, tendo em conta a naturezacontingente do domínio da gestão dos sistemas de informação, onde este trabalho se insere e poroutro lado o âmbito limitado que abrangeu.Não sendo verdades absolutas, como a aproximação do realismo critico à gestão sugere(Mingers, 2004), (Caldeira, 2000), podem as conclusões a apresentar de seguida, gerar umconjunto de recomendações que devam estar presentes nos vários responsáveis que tenham aseu cargo a produção de um anexo técnico ao caderno de encargos para a escolha de um SIH.As conclusões associadas aos temas/questões em estudoTema1- Processo de desenvolvimento do anexo técnico do caderno de encargos • Questão - De que lado da barreira estão os requisitos expressos nos cadernos técnicos e mesmo nos critérios-requisitos ? Do lado da lista das necessidades-‘features’ ou do lado dos requisitos de software ?Os cadernos de encargos estudados (CHVNG, 2010) (Porto, 2007), bem como as entrevistasefectuadas, permitem concluir que os requisitos dos cadernos de encargos não documentamrequisitos de software, tal como são descritos na literatura (Davis, 1999) (Dean Leffingwell,2000). Não há de facto uma descrição do novo sistema utilizando modelização própria dalinguagem dos sistemas de informação.Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. 34 Outubro 2011 | Conclusões

×