Análise dos requisitos técnicos dos cadernos de encargos destinados a sistemas de informação hospitalares

(1)

Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. Outubro 2011 |

1

Mestrado em Informática Médica

Analise dos requisitos técnicos dos cadernos de encargos destinados a

sistemas de informação hospitalares

Domingos Manuel da Silva Pereira

Orientação: Prof Dr Ricardo Correia

Outubro de 2011

(2)

2

Conteúdo

Revisã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. ... 14

O caso de estudo como metodologia de investigação cientifica. ... 16

Estratégia de investigação ou abordagem metodológica adoptada neste trabalho. ... 19

Action research/Action Science. ... 20

Objectivo do trabalho – as questões de investigação. ... 22

Métodos para a Recolha de Dados ... 23

Resultados ... 24

Entrevistas ... 24

Entrevista com IPO do Porto. ... 24

Entrevista com HP. ... 26

Entrevista com Glintths. ... 27

Entrevista com CHVNG. ... 28

A experiencia do aluno ... 30

Análise de documentos ... 32

Conclusõ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. ... 36

Recomendações ... 38

Lista de Figuras e Tabelas ... 40

Acrónimos ... 41

(3)

Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. Outubro 2011 | Revisão Bibliográfica.

3

Revisão Bibliográfica.

O que é um sistema de informação hospitalar ? Que

componentes 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 uma abstracção das operações que ocorrem nesse sistema. Em alguns sistemas a matéria-prima em transformação nas operações do negócio são só dados. As indústrias bancárias e seguradora são bons exemplos disso.

No passado estes sistemas de informação, já existiam e em alguns casos funcionavam muito bem, tendo presente as tecnologias disponíveis. Hoje quando falamos em sistemas de informação, falamos sobretudo nos sistemas que utilizam as chamadas tecnologias de informática e comunicações (TIC), as quais tendencialmente deverão eliminar progressivamente o 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 nos nossos 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 infraestrutura tecnológica, que constituem um sistema de informação hospital suportado nas TIC.

(4)

4

Figura 1 - Arquitectura Aplicativa de um Sistema de Informação Hospitalar, adaptado pelo autor a partir de documentos produzidos no CHVNG para apresentar o projecto SIH. CTH – Consulta Tempo e Horas; RNU – Registo Nacional de Utentes; RSE – Registo Saúde Eletrónico; SIGIC - Sistema de Gestão dos Utentes Inscritos para Cirurgia

Os acrónimos anglo-saxónicos CPR (Computer based Patient Record), EMR (Electronic Medical Record), EPR (Electronic Patient Record), EHR (Electronic Health Record), e mesmo HIS (Hospital Information System), são habitualmente usados com o mesmo sentido, quando se referem à arquitectura aplicativa dum hospital.

Tendencialmente EHR tem vindo a ser usado quando nos referimos ao registo de saúde electrónico de um cidadão de um país, e no contributo longitudinal de todas as organizações que prestam cuidados e do próprio cidadão nesse registo. (Cunha, 2009)

Neste trabalho entendemos CPR, EMR, EPR, como as componentes aplicativas centradas no tratamento da informação clínica do utente no hospital, incluindo os fluxos padronizados dos cuidados a prestar num dado contexto ao Utente, e como tal como um sub-conjunto de um HIS (ou SIH), o qual inclui também todas as áreas clinico-administrativas associadas às varias

(5)

5 modalidades de tratamento que o Hospital oferece, e o tradicional back-office, da gestão da organizaçã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 potencia

A profundidade da descrição de cada elemento dependerá do objectivo do trabalho e do conhecimento do seu autor.

Uma característica certamente comum, é o facto de existirem vários componentes, cada um com varias soluções aplicativas, numa mesma arquitectura HIS, o que implica a necessidade de assegurar uma interoperabilidade adequada entre os vários componentes/aplicações por um lado e por outro um equilíbrio saudável entre os componentes/aplicações transversais a todos os agentes, valências e modalidades de modo a reduzir esse mesmo número de componentes e aplicações a um valor gerível do ponto de vista da administração dessas aplicações e da sua interacçã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 em conjunto, quer no interior das organizações quer cruzando fronteiras organizacionais, no apoio a 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 de interoperabilidade:

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;

(6)

6 e) 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, mas também faze-lo com segurança, qualidade de serviço, e permitindo uma experiencia de utilizaçã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 ou administrativa com vários interfaces aplicativos distintos.

A realidade dos nossos sistemas de saúde, não é, na sua grande maioria, esta. Não é raro o profissional de saúde, ter de se movimentar por várias aplicações que transportam dados entre si, com interfaces distintos, e em alguns casos obrigando mesmo a apresentação repetida de credenciais aplicativas, ao longo do mesmo processo.

Em termos tecnológicos as arquitecturas orientadas a serviços, SOA - Service Oriented Architecture, apresentam-se como modelos e plataformas tecnológicas capazes para o desenvolvimento de soluções que respeitem estes vectores de interoperabilidade. Os Web-Services são um exemplo de uma SOA (Service Oriented Architecture) cujos serviços desenvolvidos assentam em tecnologia web.

Os sistemas colaborativos e de identificação e autenticação, representam dois componentes distintos 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 de comunicações unificadas, como o OCS da Microsoft, são aplicações que ajudam na informação e 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 os seus 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 suas aplicações tem cada vez mais requisitos de exigência, em termos de robustez e facilitação. Hoje em dia assiste-se a uma multiplicidade de sistemas distintos, com mecanismos de identificação e autenticação frágeis e fortes, com os perfis funcionais, repartidos e desconexos pelas várias aplicações utilizadas.

O cartão do cidadão e a exigência de autenticação biométrica para os colaboradores dos hospitais torna viável e fácil a adopção destes mecanismos e tecnologias de identificação e autenticação forte nas redes e aplicações hospitalares existentes, permitindo ainda outros

(7)

7 serviç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 experiencia de navegação pelas varias aplicações, mais agradável e fácil, as soluções de single sign-on tornam-se necessárias quando o profissional tem de aceder a vários aplicativos no decurso de um processo. De outra forma o profissional necessita apresentar credenciais em todas elas, e tendencialmente escolhe credenciais frágeis senão as mesmas em todas elas, o que naturalmente eleva o risco de roubo de identidade por terceiros.

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 e gestão das operações e as condições necessárias ao seu acondicionamento e protecção, salas de servidores, áreas técnicas para bastidores de rede, que hospedam estes sistemas de hardware e software, 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ções comuns para os termos que são usados para descrever aspectos do trabalho que ai se faz.

Isto deve-se na opinião do autor, no que respeita ao termo ‘requisitos’, ao facto de existirem múltiplos níveis nos requisitos de software, todos eles legítimos, e que representam cada um perspectivas diferentes e graus distintos de detalhe e precisão.

Wiegers, cita exemplos de varias 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 contracto, 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 sistema

a 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 sistema

(8)

8 diz Wiegers, que as definições anteriores reforçam a componente ‘o que/what’ vai ser o sistema, 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 é realizar uma 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 a que 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ísticas que o sistema deve entregar, e a conformidade ou a falta dela ao conjunto de requisitos frequentemente determinam o sucesso ou o insucesso dos projectos, faz sentido, descobrir quais são os requisitos, escreve-los (ou documenta-los) organiza-los e monitoriza-los para a possibilidade 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 e mantem 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 um sistema se focam no ‘o que ‘ (what) o sistema deve fazer sem referirem ‘como’ (how) vai fazer isso. A resistência desta visão é surpreendente dado que há bastante tempo que os investigadores a contestam. Os requisitos e o desenho da solução são interdependentes.

Na pratica a maioria do trabalho realizado na geração dos requisitos do sistema tem como objectivo principal estabelecer um contrato através do qual o cliente e o fornecedor do sistema chegam 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) remete as dificuldades da tarefa para as visões e interesses distintos que utilizadores e analistas tem do processo.

Desde logo os analistas gostariam que os requisitos a ‘sacar’ aos utilizadores pudessem converter-se directamente no desenho do sistema. Isto implica que a documentação dos requisitos funcionais seja expressa em processos (actividades), ‘outputs’, ‘inputs’ e estruturas de dados. 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 alguma dificuldade em satisfazer a insistência dos analistas, na separação conceptual do ‘o que’ e do ‘o como’. 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 seu ambiente e não ao seu funcionamento interno.

(9)

9 Existem 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

• e os dados que o novo sistema terá de gerir.

Os não-funcionais descrevem o modo (how well) como o sistema deverá suportar os requisitos funcionais, e daí que sejam também designados de requisitos de qualidade. Esta descrição pode incluir:

• 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 experiencia na disciplina de engenharia de requisitos para conciliar a visão dos utilizadores e a da equipa do projecto de software, ou como do ‘o que’ se chega ao ‘como’ na especificação de requisitos, e que estádios de 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 (Dean Leffingwell, 2000)

Afirmam que as jornadas mais bem sucedidas de analise dos requisitos começa no terreno do problema (ou da oportunidade). O domínio do problema e a terreno dos utilizadores reais e dos outros interessados. Pretende-se nesta etapa, compreender o problema a ser resolvido, ou a oportunidade a ser agarrada. Problemas e oportunidades são afinal caras da mesma moeda. Definem a etapa de analise do problema como o processo para compreender os problemas e as necessidades dos utilizadores e propor caminhos possíveis de solução que possam satisfazer

(10)

10 essas necessidades. Muitas vezes a solução mais simples pode ser uma alteração ao processo de negocio, em vez de um novo sistema.

Propõem um conjunto de técnicas/passos, as etapas de analise do problema e compreensão das necessidades

• 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 respeitar

Os autores propõem que a modelização do negocio seja um dos métodos utilizados na fase analise do problema, para que se possa compreender a estrutura e a dinâmica da empresa e ainda que os clientes, utilizadores e analistas possam dispor de uma compreensão comum da organização. Como técnica para este método, sugerem a utilização do modelo ‘casos de uso do negocio’ e do modelo ‘objectos do negocio’, propostos pela metodologia UML.

Não basta perguntar aos utilizadores quais são as suas necessidades, e preciso ‘arrancar-lhas’ e para tal os autores propõem um conjunto de técnicas que devem ser utilizadas de modo articulado.

Necessidade é definida como o reflexo de um problema operacional, pessoal ou de negocio, que deve 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 Prototipagem

Identificadas as necessidades que o novo sistema deve satisfazer, para solucionar o problema ou agarrar a oportunidade, expressas muitas vezes de modo vago e ambíguo, o analista devera ser capaz de descrever as características mais relevantes que o novo sistema deve respeitar. Estas caracterí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 mais necessidades do interessado (stakeholder).

De facto o objectivo de compreender as necessidades dos utilizadores é ser capaz de extrair as necessidades 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.

(11)

11 O número de ‘features’ expressas dá uma medida do nível de abstracção da definição proposta para 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 o seu conjunto articulado (raramente constituem apenas um documento) é designado como ‘documentos de especificação de requisitos’. Os autores propõem que os requisitos capturados na fase de análise do problema e compreensão das necessidades, sejam reunidos no ‘documento de 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 chamados requisitos de software e especifica o comportamento externo do novo sistema, acabando de vez com o mito que a analise funcional, ou a especificação de requisitos, se limita à especificação do ‘o quê’.

Davis (Davis, 1999) propõe que a especificação dos requisitos de software se faça via 5 classes distintas 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 mesmo.

• 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 sub-sistemas operativos. Muitos dos requisitos que impõem constrangimentos ao desenho da solução a criar, cabem aqui. Widrig & Leffingwell, esclarecem no inicio do capitulo 28, que assumem que a maioria dos requisitos sejam escritos em linguagem natural, seja no texto tradicional, seja via a utilização dos casos de uso.

Alertam no entanto que se a descrição do requisito é muito complexa para ser expresso em linguagem 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-tecnicas para especificar tal requisito.

Ao longo do capitulo, sintetiza algumas dessa técnicas:

• Pseudo código

• Maquinas de estados finitos

• Arvores de decisão

• Diagramas de actividades ou ‘flowcharts’

• Modelos de entidade-Relaçao

• Analise orientada a objectos

• Analise estruturada – DFD

Como 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 tem de continuar a assegurar a comunicação com os ‘key-users’ o que em alguns casos pode mesmo justificar alguma formação destes, nestas técnicas.

(12)

12 O modelo Zachman e a especificação de requisitos

Dada a abrangência de um SIH no suporte à actividade de um hospital, o ‘framework’ de Zachman surge naturalmente como algo a contextualizar ainda que de modo breve nesta revisão bibliográfica.

Zachman, (Zackman, 1987), afirma que com o crescimento dos SI, em tamanho e complexidade, é 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 uma organizaçã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 dominio mais abrangente do IT Governance, poderemos sumarizar os quatro pilares da função TIC na organização na seguinte figura:

(13)

13

Figura 4 – Os pilares da funçao tecnologias de informaçao e comunicaçoes numa organizaçã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 vida do desenvolvimento dos sistemas de informação (SDLC), que compreende as seguintes etapas:

(14)

14

• Estratégia – Planeamento global do desenvolvimento dos sistemas de informação de que a empresa necessita;

• Analise – A documentação dos requisitos de uma determinada área de negócio

• Desenho – A especificação do mapeamento dos requisitos da analise, 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 analise a matriz de Zachman introduz duas perspectivas distintas, uma que descreve a situação em termos da linguagem do negocio, enquanto a segunda embora não falando ainda de tecnologia, descreve a situação já na linguagem dos sistemas de informação.

No entanto a matriz de Zachman, não se limita à especificação dos dados e funções na descrição do sistema a desenvolver. Incorpora também a necessidade de descrever os aspectos relacionados com o local onde as operações acontecem, as pessoas que as executam, os momentos em que devem acontecer e o que as justifica(motiva) na optica 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ísticas que a solução deve adoptar, e entre a 2ª perspectiva e o domínio dos requisitos de software que são já expressos em linguagem e modelos do domínio das tecnologias de informação.

As entidades certificadoras.

A preocupação com a qualidade e abrangência das aplicações informáticas que suportam os registos de saúde dos cidadãos, levaram à emergência de entidades certificadoras de aplicações ditas EHR. Pretendem estas entidades estabelecer um conjunto de requisitos mínimos que devem ser observados pelos aplicativos em certificação no âmbito especifico a que se destinam. Duas das entidades certificadoras mais conhecidas são a CCHIT (CCHIT, 2011) dos EUA, e a EuroRec (EuroRec, 2011) da EU.

Do lado dos organismos de saúde compreende-se facilmente que gostariam que as suas escolhas possuíssem o selo de entidades certificadoras internacionais para as áreas clínicas que não necessitem tanto de ‘localização’, o que a somar aos seus próprios requisitos os tranquilizaria mais na sua escolha de modo a evitar falhas graves na solução escolhida e que só mais tarde no processo de implementação seriam detectadas.

Qualquer uma das certificações do CCHIT contempla três sub-tipos de critérios de avaliação,

• Funcionalidades

(15)

15

• 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ção face 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érios estabelecidos pela CCHIT para a modalidade ou valência em certificação.

A demonstração é realizada pelo fornecedor pela corrida dos scripts (guiões) estabelecidos, cujo resultado 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 maioria recolhidos de fontes já existentes, passam depois o crivo das respectivas equipas de avaliação), e finalmente 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 sub-categorias

• 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 sub-categorias.

• 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 sub-categorias.

O processo de certificação do EuroRec não parece estar ainda muito estruturado. E possível acordar com a organização uma certificação centrada num determinado âmbito, seleccionado a partir dos índices disponíveis, o que permite recolher o repositório um conjunto de ‘good pratice requirements’ que serão testados a partir de guiões (scripts) e cenários de teste construídos para o efeito.

(16)

Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. Outubro 2011 | O caso de estudo como metodologia de investigação cientifica.

16 Estes requisitos de boas práticas, tem associados a si declarações mais detalhadas e focadas, as designadas ‘fine grained statements’ que deverão ser também testadas nas suas particularidades nos 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 esta claramente expresso no classificador de modalidades de prestação de cuidados.

O caso de estudo como metodologia de

investigação cientifica.

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 principal das ciências sociais é produzir um corpo de conhecimento confiável, que nos permita explicar, prever e perceber o mundo social.

Peter Drucker, conhecido filosofo da gestão citado por (Gummesson, 2000), afirma que a gestão não é nem nunca será uma ciência, tal como a cultura ocidental entende ciência. Gestão e Medicina são práticas, e como práticas alimentam-se de um corpo largo de ciências. A gestão alimenta-se da economia, da psicologia, das matemáticas, da teoria politica, da história e da filosofia. Mas tal como a Medicina, a Gestão é uma disciplina de direito próprio, com os seus pressupostos, os seus objetivos, os seus instrumentos, os seus objetivos de desempenho e os seus indicadores. Como disciplina autónoma de direito próprio a gestão, é o que os alemães, designam 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 devem assim orientar-se pelas ontologias, epistemologias e estratégias adequadas as ciências sociais.

O pensamento neopositivista (Pereira, 2010) que teve como principais lideres o austríaco Moritz Schlick e o alemão Rudolf Carnap, separa o conhecimento à priori, que é lógico e matemático, do conhecimento cientifico que é empírico. O verificacionismo, base do pensamento neopositivista, verifica-se de modo distintos em ambos os tipos de conhecimento. As verdades matemáticas e lógicas são estabelecidas por provas cujo método de verificação não precisa recorrer à experiencia, mas sim à dedução lógica. Na teoria cientifica, o conhecimento precisa ser verificado empiricamente, na opinião dos neopositivistas.

Assim qualquer investigação para gerar conhecimento cientifico, por pequena que seja a sua contribuição, necessita verificar no real esse mesmo conhecimento, e necessita faze-lo respeitando um método que partindo de uma concepção filosófica do real, estabeleça um caminho que proteja a investigação de enviesamentos e ajude o investigador a gerir o seu percurso.

A estratégia de investigação adotada deve ter subjacente uma perspetiva filosófica que permita perceber as crenças e assunções que o investigador tem sobre a natureza do fenómeno que pretende investigar (a sua ontologia) e o seu ponto de vista relativamente ao modo como pode adquirir conhecimento relativamente ao mesmo fenómeno (a sua epistemologia). (Caldeira, 2004) sustenta que existe habitualmente uma relação forte entre a estratégia de investigação adoptada e a perspectiva filosófica do investigador relativamente à ontologia da realidade a investigar e à epistemologia que acredita adequada para a conhecer. Os métodos de investigação

(17)

17 não são validos por si mesmo. Necessitam de uma contextualização filosófica coerente com as suas práticas.

Finalmente a estratégia de investigação deve instanciar-se num desenho concreto da aplicação da estratégia genérica ao objecto de investigação

Caldeira 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 sua própria ontologia e epistemologia. Citando Blaikie, “ Embora partilhe o desejo do positivismo para produzir explicações causais, e a perspectiva interpretativista na natureza da realidade social, o realismo argumenta uma visão da ciência distinta de ambas”.

Clarifica a ontologia do realismo citando Bhaskar : “ as coisas existem e actuam independentemente das nossas descrições, mas apenas as podemos conhecer em condições particulares”, ou seja a ciência é vista como uma tentativa sistemática de expressar em pensamento as estruturas e formas de actuar das coisas que existem independentemente do pensamento.

Continuando a citar Bhaskar, Caldeira apresenta os três domínios da realidade, o empírico, o actual 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 dos eventos, quer possam ou não ser observados. O domínio do real consiste nas estruturas e mecanismos que produzem os eventos. O realismo é assim baseado na assumpção que as abstracções que fazemos das estruturas e mecanismos (conceptualizações) e os eventos que observamos (o domínio empírico) não representam completamente o real, seja as estruturas e mecanismos seja o actual.

(18)

18 Caldeira (2004), apresenta esta ideia num slide alegre:

Figura 6 - As ontologias do realismo critico, do interpretivismo e do positivismo (Caldeira, 2004)

(Mingers, 2004) questiona o que são leis causais, ou antes o que é que causa ou gera os eventos, dadas as regularidades que podem ser estabelecidas nos experiências e a habitual falta de regularidade fora do âmbito fechado das experiências. De igual modo pergunta como podemos assegurar-nos que as regularidades são baseadas em conexões reais em vez de simples coincidências. A resposta que propõe é que devem existir entidades duradouras, físicas (p. ex. átomos ou organismos), sociais (p. ex. o mercado ou a família) ou conceptuais (p. ex. categorias ou 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 poder que no entanto não exercem num dado momento (pode ser necessário uma experiência para o desplotar), ou o poder pode ser exercido mas não se manifestar em eventos por causa de actuação contrária de quaisquer outros mecanismos generativos.

(Almeida, 2005) citando Bryman e Bell (2003) afirma que o Realismo Crítico implica que ao contrário do positivismo que pressupõe que a conceptualização do cientista sobre a realidade,

(19)

19 reflecte 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 realismo crítico é metodologicamente aberto, ou seja não define uma metodologia específica. “ O realismo está relacionado com métodos de desenvolvimento apropriados à situação particular que pretende investigar”. De novo o princípio, que embora aceite que o mundo social é real e existe, aceita também a perspectiva interpretativista que a sociedade é produzida e reproduzida pelos seus membros, os quais podem ter percepções e interpretações diferentes da mesma realidade.

Estratégia de investigação ou abordagem metodológica

adoptada 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 dominadas por três estratégias dominantes; a experimentação laboratorial, os inquéritos e os estudo de casos. A evolução desta área relativamente recente do conhecimento (SI/TI), dum foco inicial na tecnologia para uma cada vez maior ênfase nas questões sociais, levou a uma mudança numa perspectiva 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 das aproximações cientificas do seu trabalho, dada a natureza técnico-sociológica do seu campo de investigaçã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ística de um numero elevado de observações. Em investigação médica são caracterizados como ‘anedóticos’, ou seja de validade cientifica limitada, embora úteis para a formulação de hipóteses a testar. Esta atitude vigente leva habitualmente os investigadores que suportam o seu trabalho 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 visto como 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 o seu trabalho pioneiro em alguns casos apenas.

Normann, citado por Gummesson (2000), afirma que se o investigador tem uma boa linguagem descritiva e analítica, através da qual consegue perceber a interacção entre as várias partes do sistema e as características mais importantes do mesmo, a possibilidade para generalizar o conhecimento a partir de poucos casos de estudo, pode ser razoavelmente boa. As possibilidades para generalizar a partir de um único caso terão de ser suportar na compreensão plena e nas medidas que permitem atingir a compreensão fundamental da estrutura, dos processos, e das forças impulsionadoras do sistema, o que é muito mais do que estabelecer uma correlação de causa e efeitos entre algumas variáveis.

(20)

20 Escreve (Yin, 1994) que o estudo de caso é preferível na examinação de eventos contemporâneos, quando os comportamentos relevantes não podem ser manipulados. O estudo de caso sustenta-se em muitas das mesmas técnicas da Historia, mas adiciona duas fontes de evidência que a estratégia histórica habitualmente não contempla, a observação directa e a entrevista sistemática.

Finalmente a estratégia de investigação deve instanciar-se num desenho concreto da aplicação da estratégia genérica ao objecto de investigação

O 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 mais exigente e com maior potencial de sucesso da investigação dos casos de estudo.

‘Action Research’, (Baskerville, 2004) tem como finalidade resolver problemas concretos enquanto expande o conhecimento científico.

‘Action research’ é uma forma de aprender acerca de um sistema social e simultaneamente o tentar mudar.

(21)

21 Gummerson estabelece 10 pontos para esclarecer o seu conceito de ‘management action science’ que foca o método no estudo das organizações:

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 vao 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’, e realizada para ter acesso às realidades complexas e à realidade que pertende à parte escondida debaixo do iceberg, que corresponde a 90% da sua massa/volume.

5. ‘Action science’ e aplicável à compreensão, planeamento e implementação da mudança nas organizações.

6. E 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 negocio decorre e 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’ (interpretivismo) embora elementos do paradigma positivista possam ser incluídos.

Fica assim justificada os dados recolhidos pelo estudante enquanto participante do projecto da construção do caderno de encargos do CHVNG e da sua subjectividade

(22)

Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. Outubro 2011 | Objectivo do trabalho – as questões de investigação.

22

Objectivo do trabalho – as questões de

investigação.

O domínio da investigação deste trabalho foca-se na forma e no conteúdo dos requisitos que compõem os anexos técnicos dos cadernos de encargos associados a sistemas de informação hospitalares, 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 feactures) vs 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 pratica 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 considera-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 ?

(23)

Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. Outubro 2011 | Métodos para a Recolha de Dados

23

Métodos para a Recolha de Dados

Foram utilizados três métodos para recolha de dados que permitam encontrar respostas às questõ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 hospitalar

A escolha dos hospitais resultou do critério conveniência, dado que o IPO do Porto estava a viver a implementação do projecto que resultou do concurso internacional subordinado a um caderno de encargos para um SIH e o CHVNG tinha lançado no mercado o seu concurso e respectivo caderno de encargos recentemente e o autor deste trabalho participou na sua criação. A escolha dos fornecedores resultou do facto da Glintths ter ganho o concurso do IPO do Porto e da HP ter participado em vários concursos para a escolha de sistemas de informação hospitalares que nos últimos anos ocorreram no mercado português.

E naturalmente do facto das várias instituições se mostrarem disponíveis para participarem neste trabalho, solicitação que lhes foi formalmente enviada.

Os documentos que materializam os cadernos de encargos de ambas as instituições são do domínio público.

Os documentos que materializam os requisitos-critérios das entidades certificadoras, no que respeita à CCHIT estão disponíveis no seu site oficial, e no caso da EuroRec, após contacto via email com o seu presidente, foi possível aceder ao site da entidade, navegar e exportar os requisitos-critérios adequados.

(24)

Domingos Pereira – Requisitos técnicos de cadernos de encargos destinados a sistemas de informação hospitalares. Outubro 2011 | Resultados

24

Resultados

Entrevistas

Para 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 se entende por requisitos de software e por requisitos-critérios de entidades certificadoras, e as questõ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 feactures) vs 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 esta a impactar o que esta a acontecer na pratica 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 considera-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 de Informática, no último semestre de 2006, que entendeu não ter conhecimento funcional suficiente para o desenvolver autonomamente, pelo que procurou no mercado uma organização com provas dadas neste domínio. Todo este processo foi realizado rapidamente dada a urgência do Conselho de Administração do IPO do Porto em substituir a solução anterior. A escolha recaiu na Netvita que já tinha desenvolvido o caderno de encargos para os Açores, no âmbito do projecto Açores Saúde.

(25)

25 Foram enviados questionários aos vários serviços do IPO, centrados na identificação das suas necessidades. Esta foi a fase do projecto que mais demorou. Na sequencia das respostas recebidas, foram efectuadas algumas entrevistas com alguns serviços. Houve também lugar a entrevistas com o Conselho de Administração. Em paralelo a Netvita fez uma análise ao sistema instalado.

No início de 2007 a componente técnica do caderno de encargos foi entregue ao IPO no contexto de uma apresentação ao vogal do CA responsável pela informática. Foi ainda adicionado um conjunto de linhas orientadoras de natureza tecnológica (requisitos não funcionais) produzidos pela Direcção de Informática, e a componente jurídico-administrativa pelo Serviço de Aprovisionamento, o que acresceu mais 2 meses à conclusão do caderno de encargos para ficar em condições de ser colocado no mercado.

A implementação do SIH está em curso.

Do ponto de vista da organização do projecto, a Netvita articulou sempre com Director de Informática, e não foi estabelecida nenhuma equipa de projecto do lado do IPO para acompanhar e contribuir para o desenvolvimento do mesmo.

A componente técnica do caderno produzido, situa-se sobretudo no domínio da especificação de necessidades 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 do SIH no IPO, uma preocupação foi transmitida: ‘vamos ter uma solução que responde às necessidades apresentadas, mas que nos vai obrigar a realizar o nosso trabalho de modo (numa sequencia …) diferente do que gostaríamos.’

Por exemplo quando o médico recebe um doente que necessita de medicação urgente e o acto administrativo que suporte essa sessão/episodio ainda não esta criado, o médico não pode prescrever. Ora o medico gostaria que o sistema prescritor, neste caso, comunicasse com a componente gestor de actos e lhe permitisse efectuar a prescrição no momento sem ter de devolver o utente ao administrativo. Continua a ser capaz de prescrever, mas necessita que o registo do utente nesta admissão directa, aconteça primeiro.

Seria útil que o ‘workflow’ das operações tivesse sido suficientemente detalhado para que as nossas necessidades fossem satisfeitas do modo que pretendemos, e não de um modo que a satisfaça mas que não é exatamente o que queremos no IPO.

Ou então seria útil que o próprio SIH fosse capaz de permitir configurar facilmente a sequencia das operações.

Com o nível de detalhe da especificação de requisitos, é a solução do fornecedor que se impõe e a organização tem de se adaptar, o que gera frustração: ’se a organização já fazia bem porque tem 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.

Um dos factores pode estar no facto do IPO não ter escolhido a melhor solução técnica que lhe foi proposta pela equipa técnica responsável por esta avaliação. Provavelmente escolheu a melhor solução económica, mas não técnica.

(26)

26 A Comissao técnica constituída pelo Eng Renato Magalhães, Drª Raquel Deveza da ACSS e Eng 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çao 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 das três melhores em termos da avaliação técnica.

Não houve também no processo de escolha visitas a implementações dos vários fornecedores. Tema 3 - De que modo é que os requisitos/critérios das entidades certificadoras contribuíram para a redacção do caderno ?

No que respeita a requisitos-critérios das entidades certificadoras, não foram considerados no desenvolvimento do caderno de encargos nem o entrevistado tinha conhecimento dos mesmos.

Entrevista com HP.

Entrevista realizada em V.N.Gaia dia 2011-07-27, com o Eng Carlos Barreira e a Drª Ana Morais.

Em termos gerais os cadernos de encargos focados em SIH centram-se mais na descrição das necessidades e ‘feactures’ e raramente nos requisitos de software propriamente dito.

A maioria dos cadernos de encargos na sua componente técnica de caracterização dos SIH traduzem sobretudo uma vontade do cliente de percorrer um caminho até chegar a uma solução para 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 à equipa auditora do projecto avaliar com mais rigor o risco associado à entrega da solução ao cliente e deste modo tornar mais fácil a aprovação da proposta a enviar ao cliente.

Quando o mercado não conhece a historia associada ao caderno de encargos e o mesmo é muito detalhado, fica o receio de que possa ter sido desenvolvido por um fornecedor especifico, o que adultera as condições de igualdade de concorrência.

Muitas vezes os cadernos tem níveis de detalhe muito distintos ao longo das varias áreas. Por exemplo podem ser muito pormenorizados na descrição do internamento, mas quase não fazem referencia aos mecanismos de interoperabilidade que a solução deve prover.

(27)

27 Outro aspecto que muitas vezes falta nos cadernos de encargos é a exigência aos fornecedores acerca do estado actual da sua solução para responder a cada um dos requisitos estabelecidos. Se já existe, se existe parcialmente, se terá de ser desenvolvido. Esta tabela/matriz ajudaria a distinguir o grau de maturidade das soluções propostas, face à necessidade apresentada

O risco do cliente chegar a uma solução que responde aos requisitos mas que não respeita o modo como o hospital está habituado a trabalhar, é reconhecido pela HP. E este risco é muito perigoso num hospital onde habitualmente os utilizadores médicos tem uma força muito considerá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 a adjudicação, a HP olha para o caderno de encargos e constrói um ‘statement of work’ onde por via de texto, mas sobretudo de prototipagem sobre o seu produto, explicam ao cliente como vão responder aos vários requisitos.

Tema 3 - De que modo é que os requisitos/critérios das entidades certificadoras contribuíram para a redacção do caderno ?

Os entrevistados não conheciam nem encontraram nos cadernos de encargos analisados referencias 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 Rui Henriques, Orlando Rodrigues e Nuno Ribeiro.

De acordo com a sua experiencia também situam os requisitos da componente técnica dos cadernos de encargos dos SIH a que tiveram acesso, no domínio da visão da solução, isto é, na definiçã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 alem disso, mesmo para âmbitos mais limitados do que um SIH. Um exemplo desta excepção foi a recente especificação da prescrição electrónica enviada aos fornecedores que pretendam certificar a sua solução.

Na óptica do fornecedor demasiado detalhe na especificação de requisitos pode não ser benéfico para quem já tem um produto maduro, porque pode ter mais dificuldade em adaptá-lo a requisitos particulares, do que outro fornecedor que ainda vá construir a solução.

É normal o caderno de encargos ser desequilibrado no detalhe dos seus componentes e isso pode resultar 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

(28)

28

• Do próprio desequilíbrio em termos de competência/experiencia dos vários key-users das varias áreas que contribuem para a especificação de requisitos.

• Falta de contributo em algumas áreas, que aparecem no caderno de encargos como sínteses muito breves das suas necessidades.

Reconhecem o risco do cliente obter uma solução que responda as necessidades espelhadas no caderno de encargos, mas obrigue o mesmo a desenvolver o seu trabalho de modo muito diferente do que pretendia.

Este risco do ponto de vista da sequencia das operações, não se resolve com a descrição dos macro processos a serem suportados, dado que é no detalhe particular que estas dificuldades surgem.

Muitas delas resultam também de inferências indevidas que os utilizadores fazem, do género, se a aplicação faz isto, então não é lógico (expectável) que façam também aquilo ?

Admitindo que os cadernos de encargos de um SIH se focará sempre no domínio da visão, as aproximaçõ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 sequencia das operações se faz no seu detalhe

A 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 cedo possível as expectativas dos utilizadores.

Os entrevistados não conheciam nem encontraram nos cadernos de encargos analisados referencias aos requisitos-criterios da CCHIT ou da EuroRec.

Entrevista com CHVNG.

Entrevista realizada nas instalações do CHVNG, em Vila Nova Gaia, dia 2011-08-05, com o Engº Manuel Sousa.

O projecto para o desenvolvimento da componente técnica do caderno de encargos para o SIH do CHVNG, decorreu ao longo de 2009. Do lado dos consultores externos este trabalho foi adjudicado à MakeSense e contou com a participação do Eng Manuel Sousa e o Eng Nuno Fernandes.

(29)

29 Do lado do CHVNG, a direcção do projecto foi atribuído ao director de informática do CHVNG, e contou com a participação de um conjunto de key-users que na sua maioria fazem parte da equipa nomeada pelo Conselho de Administração para participarem na reflexão para o desenvolvimento do sistema de informação do CHVNG.

A equipa consultora já tinha participado no desenvolvimento do plano director para os sistemas de informação no CHVNG e como tal conhecia bem a instituição. O Engº Manuel Sousa desenvolveu trabalho semelhante para o Centro Hospitalar do Porto. Esta experiencia cumulativa permitiu obter rapidamente uma primeira versão do caderno técnico, que foi enriquecida pelos key-users nos vários domínios, e após 3 iterações o caderno foi fechado em dezembro de 2009.

Em alguns casos houve necessidade de fazer uma síntese de propostas muito detalhadas em termos do modo de execução das tarefas que chegaram à equipa consultora. Por um lado porque se achou que haveria que equilibrar o nível de detalhe de cada componente do caderno de acordo com o seu grau de importância e por outro porque demasiado detalhe poderia limitar as propostas do mercado.

Do ponto de vista do entrevistado, os requisitos documentados, sobretudo os funcionais são sobretudo a apresentação detalhada da necessidade do CHVNG em termos do 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.

Não há, à data desta entrevista, experiencia sobre o eventual impacto do caderno técnico na implementação da solução. O concurso internacional já iniciado está suspenso, a aguardar ratificação para poder prosseguir.

No entanto o risco de o CHVNG poder optar por uma solução que respondendo aos requisitos expressos possa no entanto obrigar os utilizadores a um modo de realizarem o seu trabalho diferente do que pretendem, é reconhecido.

Seria preciso um detalhe da sequência de passos necessários para concluir cada operação para os vários momentos/eventos que as despoletasse, incompatível com o âmbito temporal para o desenvolvimento do caderno.

As respostas produzidas pelo CHVNG aos longos pedidos de esclarecimentos, bem como a possibilidade imposta no concurso de ir ver as soluções propostas a funcionar, podem ajudar a minimizar este risco.

O caderno de encargos não teve em linha de conta os requisitos-critérios da CCHIT e da EuroRec.

Seria útil ter olhado para eles durante o período de desenvolvimento do caderno de encargos. Mais útil seria ainda que a ACSS tivesse trabalhado com a EuroRec no sentido de criar um conjunto de critérios e provas que permitissem aos fornecedores de soluções hospitalares, certificarem o seu software.