Análise dos requisitos técnicos de sistemas de informação hospitalares

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 Pereira

Orientação: Prof Dr Ricardo Correia

Outubro de 2011

Tese

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


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 científica. ............................................... 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 experiência do investigador ................................................................................................. 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
Bibliografia .................................................................................................................................. 43

Outubro 2011 |


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 infra-estrutura
tecnológica, que constituem um sistema de informação hospital suportado nas TIC.

Outubro 2011 | Revisão Bibliográfica.


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 subconjunto de um HIS
(ou SIH), o qual inclui também todas as áreas clinico-administrativas associadas às várias


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;



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 fazê-lo com segurança, qualidade de serviço, e permitindo uma experiência 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 têm 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


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 experiência de navegação pelas várias 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 aí 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 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
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



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 por
que 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 determina o sucesso ou o insucesso dos projectos, faz sentido descobrir quais
são os requisitos, escrevê-los (ou documentá-los) organizá-los e monitorizá-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
mantê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 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 prática 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 têm 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.



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
• 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 experiência 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 análise dos requisitos começam no terreno do
problema (ou da oportunidade). O domínio do problema é o 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 análise 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



essas necessidades. Muitas vezes a solução mais simples pode ser uma alteração ao processo de
negó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 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 negócio seja um dos métodos utilizados na fase de
análise 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
negó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’ 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 negócio, 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 deverá 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.

As ‘features’ são habitualmente expressas em linguagem natural, em frases curtas.



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 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 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 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 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-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 – 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 têm 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.


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, (Zachman, 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 domínio mais abrangente do IT Governance, poderemos
sumarizar os quatro pilares da função TIC na organização na seguinte figura:



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:



• 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 perspectivas
distintas, uma que descreve a situação em termos da linguagem do negócio, 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 ó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ísticas
que a solução deve satisfazer e 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 específico 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 subtipos de critérios de avaliação,

• Funcionalidades
• Segurança e Privacidade


• 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 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í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.



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 está claramente expresso no classificador de
modalidades de prestação de cuidados.

O caso de estudo como metodologia de
investigaçã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 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 filósofo 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 deve assim orientar-se pelas
ontologias, epistemologias e estratégias adequadas às ciências sociais.

O pensamento neopositivista (Pereira, 2010) que teve como principais líderes o austríaco Moritz
Schlick 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 pensamento
neopositivista, verifica-se de modo distinto 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 científica, o conhecimento precisa
ser verificado empiricamente, na opinião dos neopositivistas.

Assim qualquer investigação para gerar conhecimento científico, por pequena que seja a sua
contribuição, necessita verificar no real esse mesmo conhecimento, e necessita fazê-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). Sustenta
(Caldeira, 2004) 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
Outubro 2011 | O caso de estudo como metodologia de investigação científica.


não são válidos 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 pelos 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 assunçã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.



Caldeira (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 os
eventos, dadas as regularidades que podem ser estabelecidas nas 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 deve 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 esse 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



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 dominada 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 científicas 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 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 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.

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.

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 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 participante
do projecto da construção do caderno de encargos do CHVNG para este trabalho.

Outubro 2011 |


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
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?

Outubro 2011 | Objectivo do trabalho – as questões de investigação.


Métodos para a Recolha de Dados
Foram utilizados três métodos para recolha de dados que permitissem 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 investigador 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.

Outubro 2011 | Métodos para a Recolha de Dados


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
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 de
Informática, no último semestre de 2006, que dada a natureza estruturante do projecto deveria
ser realizado por uma organização com provas dadas neste domínio com a natural colaboração
do Serviço de Informática. 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. Foram
consultadas duas entidades, mas a escolha recaiu na Netvita pois apresentou o preço mais baixo
e já tinha desenvolvido o caderno de encargos para os Açores, no âmbito do projecto Açores
Saúde.

Outubro 2011 | Resultados


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 sequência 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 dois meses à conclusão do caderno de
encargos 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á 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 dos
vários sistemas que o mesmo contempla, incluído o SIH no IPO, uma preocupação foi
transmitida: ‘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 acto
administrativo que suporta essa sessão/episódio ainda não está criado, o médico não pode
prescrever. Ora o médico 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 as
satisfaçam mas que não é exactamente o modo que queremos no IPO, porque o sistema é a
solução standard do fornecedor.

Ou então seria útil que o próprio SIH fosse capaz de permitir configurar facilmente a sequência
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.

A Comissão 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çã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 das
trê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 dos
vários fornecedores. Em alternativa foi disponibilizado a cada concorrente uma sala para
instalar 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í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. Houve sim a preocupação que a solução final
integrasse standards internacionais.

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 ‘features’ 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 história 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 têm níveis de detalhe muito distintos ao longo das várias áreas. Por
exemplo podem ser muito pormenorizados na descrição do internamento, mas quase não fazem
referê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 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

Tema 2 - Impacto :

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, explica ao cliente como
vai responder aos vários requisitos.


Os entrevistados não conheciam nem encontraram nos cadernos de encargos analisados
referê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 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
• 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 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 sequência 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ça 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 sequência 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-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 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.

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 experiência
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 de funcionalidades
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.

Tema 2 - Impacto :

Não há, à data desta entrevista, experiência 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 já evoluído suficientemente o trabalho com a EuroRec
no sentido de criar e adoptar um conjunto de critérios e provas que permitissem aos
fornecedores 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, simplificando
o processo ao nível da garantia de cumprimento de um conjunto de requisitos basilares.

A experiência do investigador

Enquanto 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 caderno
de encargos para o SIH, coordenando e envolvendo a equipa de key-users designados para o
efeito 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á desenvolvido
pelos consultores em trabalhos anteriores, e depois muito enriquecido pela experiencia e
conhecimento que os key-users do CHVNG transferiram para o documento, ao longo das várias
iteraçõ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 e
contribuírem para o desenvolvimento da arquitectura do SI do CHVNG. Esta equipa surgiu
naturalmente 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 de
necessidades e características a que o SIH deve dar resposta) acrescentaram muito valor ao
caderno técnico acrescentando-lhe muitos detalhes neste domínio. Embora de acordo com a
revisã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 autores
consultados 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 se
tenha sentido confortável com o resultado final, em termos de sentir que o ganho marginal que
poderia 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 e
atributos do contexto onde o sistema vai correr, como a interoperabilidade aplicativa com outras
aplicações que não fazem parte do SIH em concurso, essa reflexão ficou naturalmente do meu
lado 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 a
respeitar, 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 pode
decidir optar por manter as suas aplicações de prescrição medicamentosa e de MCDTs, dado o
grau de integração que já possuem com a Logística e as aplicações que suportam a produção dos
vários RIS (Radiology Information Systems) e LIS (Laboratory Information System), e que
ficou refletida no 2º paragrafo da capitulo 4.5 do caderno de encargos.



A reflexão que deu origem a este paragrafo preocupou-se também em assegurar que no caso do
CHVNG decidir manter as aplicações, há que garantir ao utilizador uma experiencia de
continuidade na navegação entre aplicações, sem no entanto especificar tecnicamente de que
modo tal será possível de obter, embora o capitulo 3.8 estabeleça alguns constrangimentos para
a 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 ajuda
a limitar as fronteiras, o domínio interno do caderno de encargos e das conexões mais relevantes
dos vários componentes. Este ‘boneco’ que surge no capítulo 2.2 do caderno de encargos
articulado com a matriz de integração entre as aplicações ajuda a contextualizar o âmbito do
trabalho a desenvolver e a planear e coordenar o mesmo, quer da componente técnica do
caderno 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 ultima
alteração ao caderno de encargos. Numa reunião com um representante da Oracle responsável
pela Europa do Sul, e depois de lhe explicarmos o que pretendíamos fazer com este caderno de
encargos, o senhor falou-nos nas soluções que conhecia em termos europeus e dos estados
unidos, e reforçou o nosso sentimento que se pudéssemos fazer conviver a nova solução com
uma solução oferecida pela Tutela para assegurar os requisitos de facturação do serviço nacional
da saúde, das estatísticas legais a que o hospital está obrigado, isso seria muito útil, dado que
nem sempre é fácil aos fornecedores acompanharem com a velocidade necessária as alterações
impostas 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’ que
preferencialmente seria satisfeito pela ACSS no quadro da sua actualização do Sonho actual e
com a qual a restante solução terá de interagir no quadro de referencia dos mecanismos de
interoperabilidade identificados. Se tal não acontecer ao fim do primeiro ano de projecto, o
adjudicatá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 da
especificação de software, ou seja na perspectiva do ‘owner’ e da sua capacidade de especificar
utilizando 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 duas
preocupaçõ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 mercado
nacional, 4 foram qualificados, e mais tarde o 5º que inicialmente foi excluído, ganhou a acção
que interpôs em tribunal.

O 6º foi excluído, por razões exclusivamente de forma.



Relativamente ao segundo risco, incluímos no artigo 17º – proposta, na alínea g), a
obrigatoriedade do fornecedor nos facultar uma visita a um hospital que tenha a sua solução a
trabalhar e na alínea h) a possibilidade de exigirmos outro tipo de documentação que o júri
entenda 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 pretendemos
que a solução funcione no CHVNG, serão com certeza as respostas aos pedidos de
esclarecimentos colocados

Neste momento o concurso está suspendo a aguardar a autorização da titula conjunta do
ministério da saúde e das finanças para o retomar, dado que o investimento previsto ultrapassa
os 5% do capital social do CHVNG, e no actual contexto económico de Portugal, tais
investimentos públicos necessitam ver a sua autorização ratificada de novo.

Análise de documentos

No que respeita ao 3º tema, o contributo dos requisitos-critérios para o enriquecimento do
caderno 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 CCHIT
2011 para o internamento hospitalar, é possível arrumá-los facilmente nos seguintes
agregadores:

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


• Outros – 5 requisitos

O grau de detalhe destes requisitos-critérios é elevado. Por exemplo, os que respeitam ao
subgrupo de geração de documentação clinica, estabelecem o seguinte:

IO-OP.01.20 – O sistema deve fornecer a possibilidade/funcionalidade de visualizar
documentos que sigam a norma HITSP C32/CCD e guardá-los de modo intacto no processo
clinico electrónico do paciente;

IO-IP.01.22 – O sistema deve fornecer a possibilidade/funcionalidade de gerar e formatar
documentos com o sumário do paciente de acordo com a norma HITSP C32 (v2.3 ou v2.5).O
registo do sumário do paciente deve incluir informação demográfica do paciente, os seus
medicamentos e as suas alergias clinicas. Os documentos XML gerados devem demonstrar o
uso de vocabulários e terminologias standard na indústria. O objectivo é testar os campos
obrigató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 a
utilizaçã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 do
paciente 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 medicamentos
e vacinas’ estão expressos 41 requisitos com detalhe muito concreto enquanto em ambos os
cadernos 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ção
medicamentosa

FN 12.06 – O sistema deve permitir capturar e manter pelo menos uma das razões que
justificaram que o alerta de interacção entre medicamentos ou entre medicamento e alergias
nã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 a
permitir 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 com
medicamentos 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 das
prescriçõ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 de
situações anómalas resultantes de interacções medicamentosas, fruto da validação da
prescrição a efectuar em relação a eventuais problemas ou outra administração de
medicamentos constante no processo clinico do utente.



Ou seja, em ambos os casos, os requisitos que traduzem a preocupação com o apoio na decisão
de prescrição e administração de medicamentos está muito mais sintetizada do que na lista dos
41 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, ie
no texto tradicional, sugere que os seus autores são agentes do ‘negócio’ ie, são profissionais de
saú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 do
caderno de encargos, quando os profissionais envolvidos fizerem verter sobre a base proposta
muito do seu conhecimento e experiencia com os sistemas que já usavam e ainda com as
limitações que lhes detectavam

Conclusões
Este capítulo sintetiza as conclusões que o plano de investigação me permitiu obter, tendo
presente as questões/temas iniciais da investigação, que foram sendo refinadas ao longo do
trabalho.

As limitações inerentes às conclusões apresentadas

A metodologia de investigação respeitada neste trabalho permite, em meu entender, produzir
conclusões, que embora válidas tendo presente os contextos e experiências de onde são
extraídas, não devem ser consideradas como verdades absolutas, tendo em conta a natureza
contingente do domínio da gestão dos sistemas de informação, onde este trabalho se insere e por
outro 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 um
conjunto de recomendações que devam estar presentes nos vários responsáveis que tenham a
seu 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 estudo

Tema1- 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 entrevistas
efectuadas, permitem concluir que os requisitos dos cadernos de encargos não documentam
requisitos 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 da
linguagem dos sistemas de informação.

Outubro 2011 | Conclusões

Análise dos requisitos técnicos de sistemas de informação hospitalares

Análise dos requisitos técnicos de sistemas de informação hospitalares

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Análise dos requisitos técnicos de sistemas de informação hospitalares

Ähnlich wie Análise dos requisitos técnicos de sistemas de informação hospitalares (20)

Análise dos requisitos técnicos de sistemas de informação hospitalares