Capa final Jorge - Repositório Aberto › bitstream › 10216 › 55340 › 2... · 2011-08-11 ·...

i

Agradecimentos

Ao Centro Regional de Sangue do Porto do Instituto Português do Sangue, I.P., na pessoa

da Senhora Directora Dra. Marília Morais, pelo estímulo e disponibilização de todo o apoio

para a realização do presente trabalho.

A todos os meus colegas que no Centro Regional de Sangue do Porto apoiaram directa ou

indirectamente a realização deste trabalho.

A todos os responsáveis dos Serviços de Sangue e de Medicina Transfusional de Portugal, e

seus representantes, que amavelmente se dispuseram a despender algum do seu tempo,

na resposta ao inquérito realizado.

Ao Mestre Jorge Condeço, pelo seu contributo científico e pela sua orientação dinâmica,

motivadora, rigorosa, paciente, inspiradora e realista.

Ao Professor Doutor Alberto Freitas, pelo seu contributo científico e orientação rigorosos e

úteis.

Ao Dr. Charles Munk (Suíça), membro do ISBT Working Party on Information Technology,

pela disponibilidade demonstrada e pela aberta troca de opiniões sobre o tema aqui

abordado que foram sem dúvida fonte de motivação e inspiração.

Ao Dr. Jonathan Harber, CIO & Vice‐presidente para Tecnologia da Informação da Blood

Systems, Inc. em Scottsdale Arizona, por me ter dado a conhecer a abordagem da sua

instituição na definição dos requisitos do utilizador do sistema que utiliza e pela partilha da

sua perspectiva inovadora sobre como devem ser os sistemas informáticos utilizados na

área da transfusão sanguínea no futuro.

Ao Serviço de Bioestatística e Informática Médica da Faculdade de Medicina da

Universidade do Porto, na pessoa do Professor Doutor Altamiro da Costa Pereira.

A todos os Professores do Mestrado pela dinâmica e conhecimentos e transmitidos.

A todos os colegas do mestrado, por tudo o que realizei e aprendi com eles.

À Isabel, aquela cujo nome virá em último, mas para mim estará sempre em primeiro, pela

sinceridade e honestidade, capacidade de trabalho e competência, motivação e

dinamismo, generosidade e paciência, timidez, graciosidade e amor.

ii

Sumário

A rápida evolução das tecnologias da informação e a proliferação do uso de sistemas

informatizados, em contextos que envolvem risco elevado, tais como a prestação de

cuidados de saúde, levanta questões quanto à qualidade, fiabilidade, validade e segurança

destes sistemas. Esta preocupação originou a elaboração e publicação de regulamentação

por várias autoridades reguladoras.

Apesar de relativamente recentes, os sistemas informáticos a operar nos Serviços de

Sangue e Serviços de Medicina Transfusional Portugueses, foram desenvolvidos em

contextos muito diferentes do actual contexto organizacional e legal.

O Ministério da Saúde Português, publicou o Decreto‐Lei n.º 267/2007, que estabelece que

"(...) se utilizados, (...) os sistemas devem ser validados antes da utilização e deve ser

assegurado que continuam validados (...) ". No entanto, após a entrada em vigor da

presente lei, não são conhecidas iniciativas formais para a resolução desta solicitação legal.

Assim a realização desta dissertação apresentou‐se como uma oportunidade para

contribuir através da melhoria da utilização de Sistemas Informáticos, para uma prática

transfusional mais segura. Foi definido como objectivo, estruturar um modelo de validação

para sistemas informatizados utilizados em serviços de sangue. Para que este fosse

cumprido foi necessário examinar o pensamento actual no que diz respeito aos princípios e

metodologias para a definição de requisitos, explorar as várias abordagens e contextos

possíveis com base na revisão bibliográfica e propor um conjunto de requisitos elaborados

com base nas obrigações legais e nas boas práticas, estruturados num protocolo de

validação. Contemplou‐se também a caracterização da utilização, gestão e actividades de

validação dos Sistemas Informáticos dos Serviços de Sangue e Serviços de Medicina

Transfusional Portugueses de modo a justificar aplicabilidade do modelo, o que foi

realizado através de entrevistas semi‐estruturadas realizadas aos responsáveis dos serviços

de sangue e a outros profissionais por eles indicados.

Os resultados permitiram verificar que a cultura de validação de Sistemas Informáticos não

está ainda suficientemente enraizada existindo no entanto sinais de que a importância e

atenção dada pelos profissionais desta área a esta temática estão a aumentar, motivada

tanto por razões legais como pela evolução do estado da arte. A evolução natural a ocorrer

estará provavelmente no estabelecimento de um consenso em relação aos requisitos

mínimos a cumprir para a validação, a disponibilização de formação em Informática e em

iii

particular daquela que se relaciona mais directamente com a Medicina Transfusional,

conjugando conhecimentos das diferentes áreas e a criação de entidades externas de

regime público ou privado, que possam apoiar o processo de validação.

iv

Abstract

The rapid evolution of information technology and the proliferation of the use of

computerized systems in contexts that involve high risks, such as health care delivery, led

to concerns about its quality, reliability, validity and security, involving the preparation and

publication of regulation by various regulatory authorities.

Although relatively recent, the systems operating in Blood Banks and Blood Transfusion

Services in Portugal were developed in quite different contexts from the current

organizational and legal context.

The Portuguese Ministry of Health has published the Decree 267/2007 which states that

"(...) if used, informatics systems (...) should be validated before use and it must be ensured

that they continue validated(...)" However, after entry into force of this legislation, formal

legal initiatives by national regulators to promote standardized validation schemes are not

known.

Thus the realization of this work was presented as an opportunity to contribute through

better use of IT Systems for a safer transfusion practice. It was defined as objective, the

design of a validation model for computerized systems used in blood services. For this to

be accomplished was necessary to examine current thinking with regard to the principles

and methodologies for requirements definition, exploring the various approaches and

possible contexts based on literature review. A set of requirements based on legal

obligations and good practices is proposed as a structured validation protocol. It is also

contemplated the characterization of the use, management and validation activities of the

Informatics Systems in Portuguese Blood and Transfusion Medicine Services in order to

justify applicability of the model, which was conducted through semi‐structured interviews

with heads of the Blood and Transfusion Services or other professionals appointed by

them.

Results showed that the validation culture is not yet sufficiently rooted however there are

signs that the importance and attention given by professionals in this field to this subject

are increasing, driven by both legal reasons as the evolution of the state of the art. The

natural evolution most likely to occur, is establishing a consensus on the minimum

requirements to be met for the validation, the provision of training in IT and in particular

one that relates more directly to the transfusion medicine, combining knowledge from

v

different areas and the development of external entities of public or private regime, which

could support the validation process.

Keywords: Computer Systems, Computer Systems Evaluation, Software Validation,

Validation Studies, Blood Banks.

vi

Preâmbulo

No âmbito dos Serviços de Sangue e Serviços de Medicina Transfusional são constantes os

desafios relativos à segurança e à qualidade.

Pelas potencialidades facilitadoras identificadas de acesso, disponibilização e

rastreabilidade da informação, o recurso a meios automáticos para tratamento da mesma

revelou desde muito cedo contribuir significativamente para o aumento da segurança e da

qualidade da prática transfusional.

No entanto, nesta área médica com elevados riscos associados e regulada pela aplicação

de boas práticas, a criação e implementação dos primeiros sistemas informáticos (SI)

desencadeou a necessidade de controlo e garantia do desempenho dos mesmos.

Nos Serviços de Sangue e Serviços de Medicina Transfusional os desafios relativos à

segurança e à qualidade são constantes. Pelas potencialidades de acesso, disponibilização

e rastreabilidade da informação, o recurso a meios automáticos revelou desde muito cedo

contribuir significativamente para a resposta a estes desafios.

No entanto, nesta área médica com elevados riscos associados e regulada pela aplicação

de boas práticas, a criação e implementação dos primeiros sistemas informáticos (SI)

desencadeou a necessidade de controlo e garantia do desempenho dos mesmos.

Nos países pioneiros nesta área, paralelamente ao desenvolvimento de SI, surgiram

conceitos e processos para verificação e validação destes antes da sua implementação e

durante a sua utilização.

Sendo utilizados em Portugal Sistemas Informáticos na área da Medicina Transfusional há

várias décadas, desde 2007 que existe a obrigatoriedade legal da sua validação.

Desconhecem‐se no entanto iniciativas das entidades reguladoras que orientem os

Serviços de Sangue e Serviços de Medicina Transfusional e facilitem o cumprimento dos

normativos.

Apesar desta norma legal nacional ter surgido como transposição de normativos Europeus

é recente a preocupação a nível europeu na emissão de orientações que conduzam os

profissionais e responsáveis dos serviços neste processo.

Assim, a realização desta dissertação apresentou‐se como uma oportunidade para

contribuir através da melhoria da utilização de Sistemas Informáticos, para uma prática

transfusional mais segura.

vii

Pretende‐se dar este contributo realizando uma pesquisa bibliográfica sobre os

procedimentos para validação de sistemas informáticos específicos utilizados em Serviços

de Sangue e Serviços de Medicina Transfusional, caracterizando em Portugal esses Serviços

e a utilização, gestão e actividades de validação desenvolvidas.

Estas actividades levaram à elaboração de um conjunto de requisitos com base nas

obrigações legais e nas boas práticas e à proposta de um protocolo de validação

retrospectiva dos Sistemas Informáticos em utilização nos Serviços de Sangue.

viii

Acrónimos

AABB – American Association of Blood Banks

AMIA – American Medical Informatics Association

ANSI – American National Standards Institute

AS – Standards Association of Australia

CCBBA – Council for Commonality in Blood Bank Automation

EF – Especificação Funcional

ERU – Especificação do Requisitos do Utilizador

FDA – Food and Drug Administration

FDA – Food and Drug Administration

GMP – Boas práticas de fabrico (Good Manufacturing Practices)

GT – Grupo de Trabalho

GTI – Grupo de Trabalho Inicial

GxP – Boas Práticas

IEC – International Electrotechnical Commission

IEEE – Institute for Electrical and Electronics Engineers

ISBT – International Society of Blood Transfusion

ISBT 128 – Sistema global de codificação e rotulagem para a transferência de informação

associada com a transplantação de tecidos humanos, terapia celular e transfusão

sanguínea (Padrão Internacional)

ISO – International Organization for Standardization

ISPE – International Society for Pharmaceutical Engineering

NIST – National Institute of Standards and Technology

PIC – Pharmaceutical Inspection Convention

ix

POP – Procedimentos Operativos Padronizados

PT – Ponto transfusional

QD – Qualificação do Desempenho

QI – Qualificação das instalações

QO – Qualificação das Operações

SGQ – Sistema de Gestão da Qualidade

SI – Sistema informático

SISS – Sistemas Informáticos dos Serviços de Sangue

SMT – Serviço de medicina transfusional

SS – Serviço de sangue

SS (Proc. Ext.) – Serviço de sangue com processamento das unidades colhidas e das

análises no exterior

SSS – Software dos Serviços de Sangue

V&V – Verificação e Validação

x

Organização da tese

Esta dissertação organiza‐se em 7 capítulos: 1‐ Introdução, 2‐ Estado da arte, 3‐ Proposta

de especificação dos requisitos do utilizador, 4‐ Proposta de protocolo de validação

retrospectiva de SI utilizados em SS, 5‐ Caracterização dos Serviços de Sangue e Serviços de

Medicina Transfusional Portugueses, da utilização e gestão dos seus Sistemas Informáticos,

actividades e conhecimentos sobre validação, 6‐ Conclusões e recomendações, 7‐ Trabalho

futuro.

No primeiro capítulo faz‐se uma contextualização histórica e técnica da Medicina

Transfusional, da sua relação com as tecnologias da informação e definem‐se os objectivos

da dissertação.

No segundo capítulo, apresenta‐se o resultado da pesquisa bibliográfica efectuada sobre

validação de Sistemas Informáticos e orientada especificamente para os utilizados em

Serviços de Sangue e Serviços de Medicina Transfusional.

No terceiro capítulo, apresenta‐se uma proposta de requisitos do utilizador elaborada com

base em normativos legais e de boas práticas transfusionais.

No quarto capítulo, apresenta‐se uma proposta de protocolo de validação retrospectiva de

Sistemas Informáticos utilizados em Serviços de Sangue elaborado com base nos requisitos

obrigatórios propostos no capítulo anterior.

No quinto capítulo, apresentam‐se e discutem‐se os dados de um inquérito realizado aos

Serviços de Sangue e Serviços de Medicina Transfusional Portugueses com vista a

caracterizar os Sistemas Informáticos por eles utilizados na sua actividade, identificar e

caracterizar os vários softwares utilizados (na perspectiva dos utilizadores), a

responsabilidade de gestão dos sistemas informáticos, as políticas de segurança, registo e

controlo de propostas e alterações ao sistema, rastreabilidade dos processos, bem como o

estado, as actividades e as competências relacionadas com a validação destes sistemas.

No sexto capítulo, apresentam‐se as conclusões obtidas pela realização das várias

actividades implicadas nesta dissertação e apresentam‐se algumas recomendações.

No sétimo capítulo, apresentam‐se planos e recomendações de trabalho futuro a ser

posto em prática, com pretensão de aproveitamento e melhoria de tudo o que foi criado

com o desenvolver desta dissertação.

xi

Resultados científicos

Publicações e apresentações

Leal, J. (2009). Validation of Informatics Systems in Use in Blood Services. 2º Simpósio de Informática Médica. Faculdade de Ciências da Universidade do Porto.

Condeço, J., Leal, J. (2010). Requisitos dos Sistemas Informáticos nos Serviços de Sangue e

de Medicina Transfusional. 6º Simpósio de Imuno‐hemoterapia, Maio 2010, Guimarães, Portugal.

Submissões planeadas para publicação

“Validation status and characterization of informatics systems in use by the Portuguese

Blood Banks and Transfusion Medicine Services in 2010”. No 21st Regional Congress of the

ISBT, Junho 18 a 22 de 2011 Europa, Portugal, Lisboa.

“Caracterização dos sistemas informáticos em utilização pelos Serviços de Sangue e

Serviços de Medicina Transfusional Portugueses em 2010” a propor à revista ABO – Revista

de Medicina Transfusional.

xii

Índice Agradecimentos ...................................................................................................................... i

Sumário ....................................................................................................................................ii

Abstract .................................................................................................................................. iv

Preâmbulo .............................................................................................................................. vi

Acrónimos ............................................................................................................................. viii

Organização da tese ................................................................................................................ x

1. Introdução ...................................................................................................................... 1

1.1 Os sistemas informatizados e a medicina transfusional ........................................... 2

1.2 Os sistemas informatizados e a medicina transfusional em Portugal ...................... 3

1.3 Objectivos ................................................................................................................... 4

1.3.1 Objectivo Geral ............................................................................................... 4

1.3.2 Objectivos específicos ..................................................................................... 4

1.3.3 Métodos .......................................................................................................... 5

1.3.4 Resultados esperados ..................................................................................... 5

2. Estado da arte ................................................................................................................. 6

2.1 Validação de Sistemas Informatizados ...................................................................... 6

2.2 Quanta validação é necessária: a gestão do risco ................................................... 24

2.3 Modelos de Validação .............................................................................................. 28

2.4 Plano de validação ................................................................................................... 33

2.4.1 Âmbito de Validação ..................................................................................... 34

2.4.2 Constituição da equipa de validação ............................................................ 34

2.4.3 Gestão de riscos pela qualidade ................................................................... 34

2.4.4 Estratégia de validação ................................................................................. 34

2.4.5 Planeamento operacional da validação, incluindo prazos e recursos .......... 35

2.4.6 Documentação a produzir no processo de validação ................................... 35

2.4.7 Critérios de aceitação da validação; resultados de validação ...................... 36

2.5 Requisitos definidos pelo utilizador ........................................................................ 36

2.5.1 Requisitos de informação ............................................................................. 37

2.5.2 Requisitos de segurança ............................................................................... 38

2.5.3 Requisitos de infra‐estruturas (perspectiva tecnológica) ............................. 38

2.5.4 Classificação dos requisitos ........................................................................... 39

2.6 Protocolos de validação ........................................................................................... 42

2.6.1 Resolução de problemas ............................................................................... 42

xiii

2.6.2 Relatório de Validação e revisão final ........................................................... 43

2.7 Conclusão .................................................................................................................. 44

3. Proposta de Especificação dos Requisitos do Utilizador ............................................ 45

3.1 Objectivo e Âmbito .................................................................................................. 45

3.2 Descrição das organizações e suas actividades ....................................................... 46

3.2.1 Serviço de sangue ......................................................................................... 46

3.2.2 Serviço de Medicina Transfusional ............................................................... 48

3.3 Descrição dos Grupos de Utilizadores e Seus Papéis .............................................. 49

3.3.1 Órgãos de Gestão e Administração ............................................................... 49

3.3.2 Médicos ......................................................................................................... 49

3.3.3 Técnicos de Análises Clínicas e S. P. .............................................................. 50

3.3.4 Enfermeiros ................................................................................................... 50

3.3.5 Administrativos ............................................................................................. 50

3.4 Riscos ........................................................................................................................ 50

3.5 Especificação de Requisitos do Utilizador ............................................................... 50

4. Proposta de protocolo de validação ............................................................................ 63

4.1 Objectivo e Âmbito .................................................................................................. 63

4.2 Instruções e Metodologia de teste .......................................................................... 63

5. Caracterização dos sistemas informáticos dos SS e SMT Portugueses ...................... 82

5.1 Objectivo................................................................................................................... 82

5.2 Material e métodos .................................................................................................. 82

5.2.1 Tipo de Estudo .............................................................................................. 82

5.2.2 População e Amostra em Estudo .................................................................. 82

5.3 Metodologia ............................................................................................................. 82

5.3.1 Elaboração do Questionário ......................................................................... 82

5.3.2 Tratamento dos Dados .................................................................................. 83

5.4 Resultados ................................................................................................................ 84

5.4.1 Tipo de Instituição e Serviço ......................................................................... 85

5.4.2 Sistema informático utilizado ....................................................................... 89

5.4.3 Responsabilidades de gestão do sistema informático .................................. 95

5.4.4 Segurança dos dados e dos equipamentos ................................................... 97

5.4.5 Registo e controlo de propostas e alterações ao sistema ............................ 98

5.4.6 Rastreabilidade dos processos .................................................................... 101

xiv

5.4.7 Estado, actividades e competências relacionadas com a validação destes

sistemas 103

5.5 Discussão ................................................................................................................ 109

6. Conclusões e Recomendações ................................................................................... 113

7. Trabalho futuro .......................................................................................................... 115

8. Referências ................................................................................................................. 116

9. Anexos ........................................................................................................................ 118

xv

Índice de figuras

Figura 1 ‐ Modelo em V da GAMP‐1 ..................................................................................... 31

Figura 2 ‐ Modelo em V da GAMP‐2 ..................................................................................... 31

Figura 3 ‐ Modelo em V da Engenharia Informática ............................................................. 32

Figura 4 ‐ Modelo em V resultante da combinação dos modelos da GAMP com o da

Engenharia Informática......................................................................................................... 32

Figura 5 – Fluxograma da realização do inquérito ................................................................ 84

Figura 6 – Número de colheitas realizadas em 2009 ............................................................ 86

Figura 7 – Número de unidades transfundidas em 2009 ..................................................... 86

Figura 8 ‐ Número de Camas de 45 inquiridos com internamento ...................................... 87

Figura 9 – Número de profissionais por serviço ................................................................... 87

Figura 10 – Distribuição dos serviços inquiridos relativamente ao estado de certificação . 89

xvi

Índice de tabelas

Tabela 1 ‐ Categorias de risco de software clínico ............................................................... 26

Tabela 2 – Classificação de risco proposta nas directrizes da ISBT ...................................... 27

Tabela 3 ‐ Legenda de códigos utilizados ............................................................................. 53

Tabela 4 ‐ Especificação dos requisitos do utilizador ........................................................... 54

Tabela 5 ‐ Distribuição das respostas por tipos e agrupamentos de serviços ...................... 85

Tabela 6 ‐ Caracterização das instituições questionadas em 2009 ...................................... 86

Tabela 7 ‐ População da amostra versus, dados da ASST relativos a 2009 .......................... 88

Tabela 8 ‐ Software utilizado por tipo de serviço ................................................................. 89

Tabela 9 ‐ Software utilizado por tipo de serviço após integração em agrupamentos

hospitalares ........................................................................................................................... 90

Tabela 10 – Actividades não integradas no sistema informático ou deficitárias ................. 91

Tabela 11 – Classificação do servidor de cada sistema, por tipo de serviço ........................ 95

Tabela 12 ‐ Responsabilidade de gestão do hardware e do software .................................. 95

Tabela 13 ‐ Responsabilidade de gestão do hardware e do software versus, estado de

certificação dos serviços ....................................................................................................... 96

Tabela 14 ‐ Responsabilidade de gestão do hardware versus, tipo de servidor .................. 96

Tabela 15 ‐ Responsabilidade de gestão do software versus, responsabilidade de gestão

do hardware .......................................................................................................................... 97

Tabela 16 ‐ Registo das actividades relacionadas com as propostas de melhoria do SI e suas

interfaces .............................................................................................................................. 98

Tabela 17 ‐ Existência de procedimentos para registo e controlo das alterações ao

hardware e ao software ........................................................................................................ 98

Tabela 18 ‐ Responsabilidade de gestão do hardware versus, existência de procedimentos

para registo e controlo do hardware .................................................................................... 99

Tabela 19 ‐ Responsabilidade de gestão do hardware versus, existência de protecções

físicas dos equipamentos ...................................................................................................... 99

Tabela 20 – Existência de procedimentos para registo e controlo do hardware versus,

existência de procedimentos para registo e controlo do software ...................................... 99

Tabela 21 ‐ Existência de procedimentos para registo e controlo do hardware versus,

existência de protecções físicas dos equipamentos ........................................................... 100

Tabela 22 – Estado de certificação dos serviços versus, existência de protecções físicas dos

equipamentos ..................................................................................................................... 100

Tabela 23 ‐ Registo das actividades relacionadas com as propostas de melhoria do SI e suas

interfaces, Existência de procedimentos para registo e controlo do hardware e do software

versus, estado de certificação dos serviços ........................................................................ 101

xvii

Tabela 24 ‐ Capacidade dos sistemas para assegurar a rastreabilidade de todos os

processos relacionados com cada colheita e transfusão .................................................... 102

Tabela 25 – Desenvolvimento nos serviços de actividades para validação dos sistemas

informáticos ........................................................................................................................ 103

Tabela 26 ‐ Estado de validação dos sistemas automáticos ligados ao sistema informático

............................................................................................................................................ 103

Tabela 27 ‐ Estado de Validação dos Sistemas Informáticos .............................................. 104

Tabela 28 ‐ Previsão de Validação dos Sistemas não Validados ......................................... 104

Tabela 29 ‐ Premência atribuída à validação dos sistemas informáticos ........................... 104

Tabela 30 ‐ Existência nos serviços de recursos próprios que permitam fazer a validação do

SI .......................................................................................................................................... 105

Tabela 31 – Motivos da não existência nos serviços de recursos próprios que permitam

fazer a validação do sistema informático ........................................................................... 105

Tabela 32 – Soluções apresentadas para validação dos sistemas informáticos, pelos

serviços sem recursos próprios para a sua realização ........................................................ 105

Tabela 33 – Estado de validação dos SI, realização ou desenvolvimento de actividades para

validação do SI, estado de validação dos sistemas automáticos ligados ao SI e previsão de

validação dos SI versus, estado de certificação dos serviços ............................................. 106

Tabela 34 ‐ Estado de validação dos sistemas automáticos ligados ao SI versus, estado de

validação dos SI ................................................................................................................... 107

Tabela 35 – Estado de certificação dos serviços, estado de validação dos SI e previsão de

validação dos SI versus, premência atribuída à validação dos SI ....................................... 107

Tabela 36 ‐ Existência de recursos próprios para validar os SI versus, estado de validação

dos SI ................................................................................................................................... 107

Tabela 37 ‐ Existência de recursos próprios para validar os SI, motivos para a falta de

recursos próprios para validar os SI e soluções apresentadas para resolver a falta de

recursos versus, estado de certificação dos serviços ......................................................... 108

Validação de Sistemas Informáticos de Serviços de Sangue e de Medicina Transfusional

1

1. Introdução

Os progressos da medicina e das tecnologias associadas à prestação de cuidados de saúde

têm sido constantes e sucedem‐se a um ritmo cada vez mais rápido.

Neste contexto, a medicina transfusional não constitui uma excepção. Os constantes

desafios a que tem sido necessário dar resposta desde o início da sua prática, têm

constituído importantes factores de evolução.

A existência de sistemas de gestão da informação adequados ao tratamento de volumes de

dados cada vez maiores e ao processamento de informação cada vez mais complexa, o

aumento da disponibilidade de máquinas cada vez mais potentes e dos conhecimentos

relacionados com a utilização de computadores, são factores que têm permitido o

fornecimento de componentes sanguíneos cada vez mais seguros e a recolha e

armazenamento de informação crítica relacionada com a cadeia transfusional.

No entanto esta rápida evolução das tecnologias da informação e a proliferação da

utilização de sistemas informatizados em contextos que envolvem riscos elevados, como a

prestação de cuidados de saúde, em geral, e da Medicina Transfusional em particular, deu

origem desde muito cedo a preocupações relativas à sua qualidade, fiabilidade, validade e

segurança.

Ao mesmo tempo que se assistiu a esta rápida evolução tecnológica, e desde há pelo

menos duas décadas, que se tem investido nos serviços de sangue e de medicina

transfusional em Portugal na implementação de sistemas de gestão da qualidade, tendo

como principais objectivos a obtenção de níveis de segurança transfusional óptimos e a

minimização do risco. Pretende‐se desta forma garantir, entre outros, a realização dos

processos de acordo com as boas práticas estabelecidas a nível nacional e internacional e a

adopção de políticas de melhoria contínua da qualidade.

Todas estas preocupações levaram à elaboração de regulamentação por entidades

reguladoras, que por vezes e em muitas áreas antecipam a aplicação real destas medidas.

Assim, estes regulamentos deverão ser implementados pelo trabalho conjunto da

comunidade científica e dos profissionais da área, disponibilizando directrizes e

procedimentos que possibilitem o cumprimento do que é definido.


2

1.1 Os sistemas informatizados e a medicina transfusional

Na medicina transfusional, os avanços científicos e tecnológicos desenvolveram‐se

simultaneamente.

Considera‐se que a medicina transfusional moderna começou com a primeira descrição da

circulação sanguínea por William Harvey, em 1628. Foi necessário esperar até 1785 para

Philip Syng Physick realizar a primeira transfusão de sangue humano. O século XIX centrou‐

se em diferentes experiências para pesquisar casos em que a transfusão pode melhorar a

saúde do paciente, bem como no controlo da infecção durante a transfusão e na procura de

possíveis substitutos do sangue para transfusão. Mas foi a descoberta dos grupos

sanguíneos por Karl Landsteiner e seus colegas Alfred Decastello e Adriano Sturli em 1900,

o que realmente impulsionou a inovação tecnológica na medicina transfusional.

O século XX mostrou‐se prolífico para a medicina transfusional, especialmente a segunda

metade, onde todas as actividades tenderam a tornar‐se mais especializadas e, por

conseguinte, ganharam individualmente importância e especificidade. Foi feito um

progresso enorme para melhorar a qualidade do produto, a segurança do doente, bem

como a saúde do dador.

Nos últimos 30 anos, a tecnologia da informação tem contribuído consideravelmente para

melhorar a segurança da medicina transfusional, especialmente no equipamento de

laboratórios, com sistemas automatizados, complementando a colheita de sangue total,

com a colheita de componentes sanguíneos específicos com a utilização de máquinas de

aférese, automatizando o processamento de sangue bem como na implementação de

sistemas de gestão de sangue com diferentes graus de complexidade (desde a gestão de

dadores à gestão de doentes até compatibilização (crossmatching electrónico), de forma a

garantir o fornecimento de sangue através do recrutamento de dadores, a qualidade do

sangue, a segurança do doente, rastreabilidade dador‐produto‐doente e manter o controlo

de toda a indústria.

Além disso, a utilização de padrões para a identificação do sangue e dos produtos

sanguíneos melhorou consideravelmente o controlo dos processos garantindo a qualidade

do sangue e dos componentes relacionados, bem como a segurança dos doentes. O padrão

internacional para identificação do sangue e dos componentes sanguíneos, o sistema ISBT

128, gerido pelo CCBBA é amplamente reconhecido em todo o mundo, fornece meios

adequados para garantir a qualidade do sangue, componentes sanguíneos, bem como de


3

todas as outras células humanas, tecidos, e produtos celulares e produtos à base de tecidos

que deverão ser desenvolvidos no futuro.

A tecnologia da informação hoje disponível é o resultado da interacção de mais de dois

séculos de inovações nesta área. As actuais inovações da tecnologia da informação podem

contribuir para melhorar a actividade da medicina transfusional. O desafio é usar a

tecnologia mais adequada, que vai de encontro às expectativas em termos de melhoria da

actividade e segurança do doente (Munk 2009a).

As mudanças nos sistemas de saúde na próxima década, vão fazer parecer os últimos 20

anos bons velhos tempos de relativa estabilidade. Vão continuar a surgir novas drogas,

novos dispositivos e novas técnicas, no entanto, a verdadeira mega mudança da próxima

década será a recolha, gestão e utilização da informação clínica. Esta previsão deve

revelar‐se verdadeira para todas as áreas da saúde incluindo a medicina transfusional e

englobará as vertentes administrativas, clínica, de ensino e de investigação.

1.2 Os sistemas informatizados e a medicina transfusional em

Portugal

Apesar de relativamente recentes, os sistemas informatizados que operam nos serviços de

sangue (SS) e de medicina transfusional (SMT) em Portugal foram desenvolvidos, e/ou

implementados, em contextos organizacionais e legais bastante diferentes do contexto

actual.

A preocupação contínua com a segurança transfusional, os investimentos realizados com a

adopção de políticas e de sistemas de garantia da qualidade e as alterações dos normativos

legais, produziram alterações rápidas e profundas do ambiente em que este tipo de

sistemas tem que garantir um desempenho optimizado.

O Ministério da Saúde Português, pelo Decreto‐Lei n.º 267/2007 de 24 de Julho, transpôs

para a ordem jurídica interna as Directivas números 2002/98/CE, do Parlamento Europeu e

do Conselho, de 27 de Janeiro de 2003, 2004/33/CE, da Comissão, de 22 de Março,

2005/61/CE, da Comissão, de 30 de Setembro, e 2005/62/CE, da Comissão, de 30 de

Setembro que estabelecem normas de qualidade e segurança em relação à colheita,

análise, processamento, armazenamento e distribuição de sangue humano e de

componentes sanguíneos.


4

Segundo este Decreto‐Lei, anexo III, § 4.5: “...Se forem utilizados sistemas informatizados,

os procedimentos relativos ao software, ao hardware e às cópias de segurança devem ser

periodicamente analisados para assegurar a sua fiabilidade. Devem igualmente ser

validados antes de serem utilizados e há que assegurar que se mantenham validados. O

hardware e o software devem estar protegidos em relação ao uso ou a alterações não

autorizados. O procedimento de cópia de segurança deve evitar a perda ou a deterioração

dos dados em situações de indisponibilidade ou de avaria previstas ou

imprevistas…”(Portugal. Ministério da Saúde 2007).

No entanto, após entrada em vigor desta legislação, não se conhecem outras iniciativas

legais ou formais por parte das entidades reguladoras nacionais. À semelhança do que se

tem verificado em outros países, é importante que se forneçam orientações produzidas de

forma consensual e que promovam uma abordagem padronizada do problema. É

necessário definir metodologias tecnicamente válidas e actuais que, quando

implementadas, permitam evidenciar objectivamente as capacidades de desempenho,

determinar a segurança e o estado de validação dos sistemas informatizados durante todo

o seu período de utilização, independentemente da complexidade.

1.3 Objectivos

1.3.1 Objectivo Geral

Estruturar e um modelo de validação para sistemas informatizados utilizados em serviços

de sangue.

1.3.2 Objectivos específicos

1. Analisar o pensamento actual relativamente aos princípios e metodologias de

validação de sistemas informatizados;

2. Explorar as várias abordagens possíveis deste problema, tendo em vista a sua

futura aplicação ao nível dos serviços de transfusão sanguínea;

3. Conceptualizar uma estrutura que possa dar origem a modelos de validação;

4. Definir um modelo de validação.

5. Elaborar e aplicar inquérito para a caracterização dos SS e SMT Portugueses e os

sistemas informáticos em utilização na sua actividade, identificar e caracterizar os


5

vários softwares utilizados (na perspectiva dos utilizadores), a responsabilidade de

gestão dos sistemas informáticos, as políticas de segurança, registo e controlo de

propostas e alterações ao sistema, rastreabilidade dos processos, bem como o

estado, as actividades e as competências relacionadas com a validação destes

sistemas.

1.3.3 Métodos

Para alcançar os objectivos propostos será realizada pesquisa bibliográfica e elaborado um

modelo de validação de sistemas informáticos utilizados em serviços de sangue. Os dados

de caracterização serão obtidos por entrevistas semi‐estruturadas a responsáveis dos

serviços de sangue e a outros profissionais por eles indicados.

1.3.4 Resultados esperados

Compreender o pensamento actual relativamente à validação de Sistemas Informáticos.

Obter um modelo de validação de sistemas informáticos, aplicável nos serviços de sangue

portugueses.

Caracterizar a situação em Portugal relativamente aos diferentes sistemas informáticos

utilizados nos SS e SMT, e ao seu estado de validação.


6

2. Estado da arte

2.1 Validação de Sistemas Informatizados

Um dos objectivos da validação é ser capaz de demonstrar rapidamente a alguém externo

à organização (gestão, auditores, entidades reguladoras, etc.) que um sistema está

completamente validado através de evidências (FDA/CBER (U.S.) 2002). É inútil validar

parte do sistema, ou o hardware e software separadamente e, em seguida, assumir que no

final eles irão trabalhar juntos da mesma forma. Deve ser possível demonstrar através de

evidências obtidas nas instalações do utilizador que, o software, é adequado para as

operações específicas e volume de trabalho, satisfazendo repetidamente e com rigor as

necessidades, e que existe um elevado nível de confiança na integridade dos processos

realizados e no controlo dos processos dentro do ambiente de operação definido no

documento dos requisitos (FDA/CBER (U.S.) 2007; PIC/S 2007).

A validação de SI e das suas interfaces, seja realizada pelo utilizador final ou por terceiros,

deve ser conduzida no ambiente onde serão utilizados. Os testes realizados pelo fabricante

ou fornecedor de software não são um substituto para a validação dos SI nas instalações

onde vai ocorrer o processo de produção. Também as instituições que desenvolvam os

seus próprios softwares devem ter como referência princípios de validação do software.

A gravidade das potenciais consequências resultantes da falta de controlo adequado dos

SI, e a seriedade com que as entidades reguladoras abordam estas questões originaram

uma série de avisos relacionados com deficiências de controlo de software, controlo

inadequado na qualificação e validação das instalações, não manutenção de

documentação adequada, ausência de procedimentos escritos, falha na manutenção de

registos relacionados com a realização de passos significativos na colheita, processamento,

armazenamento, e distribuição de cada unidade, não realização de estudos de validação

de software, documentação não concorrente e casos de falsificação de registos (Wingate

2004).

O processo de validação deve ser executado utilizando procedimentos que deverão

identificar as acções ou sequência de acções específicas a realizar para completar cada

actividade. Os serviços devem desenvolver um plano de validação onde se define e

controla como será realizada a validação e o que se deve obter, incorporando os princípios

reconhecidos de validação de software, de garantia da qualidade e as actuais boas práticas

de engenharia do software (FDA/CBER (U.S.) 2007). Os planos de validação devem


7

especificar o âmbito, abordagem, recursos, calendarização, tipos e extensão das

actividades, tarefas, itens de trabalho e processo de aprovação (FDA/CBER (U.S.) 2002;

FDA/CBER (U.S.) 2007), o que é discutido mais à frente.

Os ensaios do utilizador final podem repetir alguma da validação realizada durante o

desenvolvimento, tais como testes de carga ou stress e verificação de parâmetros de

segurança e controlo, a fim de avaliar o desempenho sob condições reais de

funcionamento. Além disso, o utilizador final deve avaliar a capacidade dos colaboradores

para utilizar o SI como se pretende que ele seja utilizado, no contexto dos processos de

trabalho reais. Os colaboradores devem ser capazes de compreender o hardware e suas

interfaces com o software e de responder adequadamente às mensagens, avisos, e outras

funções.

As actividades da validação têm que ficar documentadas. O relatório da validação deve

incluir um sumário dos resultados dos testes, incluindo variações nos resultados ou testes

falhados, alterações feitas aos testes ou ao plano de validação, uma avaliação do resultado

dos testes e aprovação e assinaturas da gestão.

Uma validação bem sucedida de um sistema informatizado é um desafio que pode ser

superado se for feita uma boa abordagem do problema.

As técnicas de validação dos processos tradicionais de fabrico não são suficientes, e as

técnicas de engenharia de software não abordam todos os aspectos necessários (Tracy and

Nash 2002). Contudo, é possível delinear estratégias bem sucedidas na difícil tarefa de

validação de sistemas complexos.

Dependendo da natureza da sua funcionalidade, as alterações ao SISS podem resultar em

alterações à forma como um processo é realizado. Se isso ocorrer, também deve ser

realizada a revalidação processo. No processo de validação, os responsáveis pela

supervisão da qualidade devem rever e aprovar os planos de validação, os resultados, e as

acções correctivas e devem determinar se a execução pode prosseguir com ou sem

limitações.

A abordagem da validação deve ser holística, certificando o sistema como um todo –

exactamente como ele se destina a ser utilizado operacionalmente (Evans 2004).

Sendo reconhecidas as complexidades inerentes aos projectos de validação de sistemas

automatizados temos neste momento a vantagem de podermos usufruir de orientações e


8

regulamentações – provenientes de instituições, sociedades, associações nacionais e

internacionais – reflexo de anos de experiência, aprofundados debates e de processos de

construção de consenso com a participação de peritos conceituados.

Por exemplo, o pensamento actual da Food and Drug Administration (FDA) estrutura‐se

com base em referências e padrões produzidos por diversas instituições como:

American National Standards Institute (ANSI);

Institute for Electrical and Electronics Engineers (IEEE);

National Institute of Standards and Technology (NIST);

Standards Association of Austrália (AS);

International Electrotechnical Commission (IEC);

International Organization for Standardization (ISO);

International Society for Pharmaceutical Engineering (ISPE), entre outras

(FDA/CBER (U.S.) 2002).

Os mesmos padrões e normas servem como referências principais a outras organizações

como, a International Society of Blood Transfusion (ISBT) (ISBT, Bocker et al. 2003; Munk

2009c), American Association of Blood Banks (AABB) (AABB 2008)e a Pharmaceutical

Inspection Convention (PIC) (PIC/S 2007).

De uma forma simplista, pode considerar‐se que os sistemas informatizados existem com

três tipos de aplicações principais podendo existir “interfaces” que fazem as ligações entre

eles (PIC/S 2007):

1. Sistemas de controlo de processos,

2. Sistemas de processamento de dados e

3. Sistemas de armazenamento de dados;

A FDA considera os Sistemas Informáticos dos Serviços de Sangue (SISS) como

equipamentos que incluem hardware, software, dispositivos periféricos, pessoas e

documentação (Manuais do Utilizador, Procedimentos Operativos Padronizados (POP)). O

Software dos Serviços de Sangue (SSS) é considerado um dispositivo médico que pode ser


9

fabricado internamente (in‐house) ou por uma entidade externa, fabricante de software

(FDA (U.S.) 1995; FDA/CBER (U.S.) 2002; FDA/CBER (U.S.) 2007).

Nos EUA, todos os serviços de sangue têm que submeter às entidades reguladoras

informação a descrever os seus SISS juntamente com o seu pedido de licenciamento do

estabelecimento. Qualquer alteração “importante” proposta ao sistema original tem que

ser comunicada como suplemento ao sistema principal (Wingate 2004).

Também a nível Europeu (EU) se tem desenvolvido trabalho besta área pela sua

importância para o mercado e consumidores. Foram aprovadas pela Comissão Europeia

duas directivas que estabelecem princípios e directrizes das boas práticas de fabrico (GMP)

para medicamentos. A Directiva 2003/94/CE aplica‐se a medicamentos para uso humano e

a Directiva 91/412/CEE para uso veterinário. Orientações pormenorizadas, em

conformidade com esses princípios são publicadas no Guia de Boas Práticas de Fabrico,

utilizado na avaliação dos pedidos de autorização de fabrico e como base para a inspecção.

Além das questões gerais de GMP descritos na Parte I e II, uma série de anexos,

fornecendo detalhes sobre áreas específicas da actividade estão incluídos. Entre eles o

anexo 11 sobre sistemas computorizados aplica‐se a todas as formas de informatização

utilizada no âmbito das actividades reguladas, incluindo controlo de processos,

documentação e sistemas de processamento de dados. Ele também abrange o

desenvolvimento, selecção, validação e utilização dos sistemas.

Todos os Estados‐Membros e a indústria concordam que as exigências de GMP aplicáveis

ao fabrico de medicamentos veterinários são os mesmos que os aplicáveis ao fabrico de

medicamentos para uso humano, existindo ainda uma aceitação implícita da extensão do

seu âmbito a outras áreas laboratoriais como é o caso dos Serviços de Sangue e de

Transfusão.

Sempre que um sistema informatizado substitui uma operação manual, não deverá haver

diminuição da qualidade de produto, controlo de processos ou controlo de qualidade, não

devendo ocorrer aumento no risco geral de falha do produto. A validação de sistemas

informatizados deve permitir tanto ao titular da autorização de fabrico, como à autoridade

competente, ter um alto nível de confiança na integridade tanto nos processos executados

sob o controlo do sistema informático como naqueles processos controlados e/ou ligados

a sistemas de computadorizados.


10

Para sistemas proprietários, quando o fornecedor tenha completado o ciclo de

desenvolvimento independentemente, então, dependendo da natureza da aplicação

pretendida, o titular da autorização de fabrico ou comprador, podem necessitar de avaliar

as evidências de desenvolvimento / validação do produto, junto do fornecedor,

nomeadamente nos seguintes pontos (European Commission 2008):

“…

1. Gestão de Risco

1.1. Decisões sobre a extensão de validação e controlo de integridade dos dados

devem ser baseadas e justificadas num documento de avaliação de risco do

sistema informatizado, no que diz respeito ao seu impacte na qualidade e

segurança do produto assim como na segurança e integridade dos dados.

2. Pessoal

2.1. É essencial que haja uma grande colaboração entre o pessoal chave, tais como

utilizadores, administradores de sistema, pessoal da garantia da qualidade e

pessoal técnico (tanto dos colaboradores internos como dos prestadores e

serviços) envolvidos no desenvolvimento, validação, gestão e utilização de

sistemas informatizados. Pessoas que exercem esses papéis devem ter

qualificações adequadas e documentadas, formação, conhecimentos técnicos,

responsabilidades e experiência para realizar as funções que lhes estão atribuídas.

3. Validação

3.1. O sistema de qualidade do titular da autorização de fabrico, necessitará de

incluir políticas e planos para a validação de sistemas informatizados, bem como

listagens actualizadas dos sistemas e das suas funcionalidades GxP. O estado de

validação de cada sistema deve estar claramente definido no programa de

validação. A extensão da validação necessária dependerá do tipo, complexidade e

risco dos sistemas informatizados e da avaliação de risco do titular da autorização

de fabrico.

3.2. Para a validação de sistemas informatizados significativamente personalizados,

deve haver um processo em que se assegure a avaliação formal e comunicação

dos padrões de qualidade e de desempenho para todas as fases do ciclo de vida do

software e de desenvolvimento do sistema, a sua implementação, qualificação e


11

aceitação, operação modificação, requalificação, manutenção, suporte contínuo e

abate, (em relação aos sistemas personalizados, os controlos acima descritos são

necessários para os aspectos de personalização e seus impactos no sistema como

um todo).

3.3. A documentação de validação deve abranger todas as etapas pertinentes do ciclo

de vida específico do projecto, requerendo métodos adequados de medição e

comunicação (por exemplo, relatórios de avaliação e os pormenores de qualidade

e medidas de teste). Os requisitos dos utilizadores devem ser rastreados durante o

processo de validação / ciclo de vida. Os titulares de autorização de fabrico devem

ser capazes de justificar e defender os seus padrões, protocolos, critérios de

aceitação, procedimentos e registos, à luz das avaliações complexidade e do risco

documentado, visando garantir a adequação para o propósito e a conformidade

regulamentar.

3.4. A documentação de validação deve incluir o controlo de alterações e os registos de

erro gerados durante o processo de validação.

3.5. Em relação à fase de testes do processo de validação:

Deve ser avaliada a adequação das ferramentas automatizadas de teste

utilizadas para fins de validação.

Devem ser incluídas evidências dos testes de provocação, em especial os das

definições dos parâmetros do sistema e dos dados e tratamento de erro.

3.6. Na adequação das melhores práticas para avaliação de riscos e gestão da

mudança, o titular da autorização de fabrico deve realizar revisões periódicas aos

sistemas informatizados para determinar se mudanças incrementais, problemas

de desempenho do sistema, ou a evolução da regulamentação implicam trabalha

adicional no sentido de reconfirmar a validação ou a integridade dos dados. Tais

revisões devem incluir a gama actual de funcionalidade, os registos de erro,

actualização da história, o desempenho, fiabilidade, segurança e relatórios do

estado de validação.


12

3.7. A validação de sistemas apoiados em base de dados deve incluir o seguinte:

Mecanismos para garantir a integridade dos dados em termos de precisão e

fiabilidade (por exemplo macros, para verificação da estrutura lógica de dados,

desenho de tabelas, etc.).

Meios para garantir a segurança dos dados (controlo de acessos, tipo de

visionamento, mecanismos internos de encriptação).

Controlo de transacções / protocolos (particularmente importante no que diz

respeito ao bases de dados distribuídas).

Articulação entre diferentes bases de dados (o software desenvolvido para

interligar diferentes bases de dados proprietárias).

Mecanismos de recuperação (recuperação de uma base de dados para o seu

estado consistente após um falha).

O teste de carga (incluindo as necessidades presentes e futuras de crescimento

da base de dados).

Meios para monitorização pós‐acompanhamento do desempenho do sistema e

o crescimento da base de dados.

Arquivo de dados em tempo real se aplicável.

3.8. As folhas de cálculo devem ser devidamente verificadas quanto à precisão e

fiabilidade e armazenadas de forma que se garanta o controlo apropriado da

versão. Deve ser garantida a segurança dos cálculos, bloqueando as fórmulas para

que estas não sejam intencionalmente ou acidentalmente substituídas. Os cálculos

devem ser executados com a precisão exibida (no monitor ou em relatórios). As

fórmulas devem ser protegidas da entrada acidental de um tipo de dados

inapropriado (por exemplo: texto, num campo numérico e / ou um formato

decimal no campo inteiro).

4. Sistema

4.1. Um inventário, ou lista de todos os sistemas informatizados é essencial. O

inventário deve mencionar o local e a finalidade do sistema informatizado. Esta

lista deverá indicar a categoria de risco avaliada de cada sistema. Sistemas que


13

têm uma influência em actividades reguladas precisam ser identificados. Os

titulares de autorização de fabrico deverão manter registos detalhados das

características físicas, das estruturas lógicas e das infra‐estruturas de controlo de

ambientes seguros, conjuntamente com descrições detalhadas actualizadas de

cada sistema, os fluxos de dados e interacções com outros sistemas ou processos.

Estes devem ser tratados como documentos controlados.

4.2. As especificações actuais devem estar disponíveis (incluindo diagramas, se

apropriado) devendo descrever as funções necessárias do sistema, qualquer

modularidade e suas relações, suas interfaces e ligações externas, os limites do

sistema, principais entradas e saídas, principais tipos de dados armazenados,

tratados ou transformados, quaisquer pré‐requisitos de hardware e software e

medidas de segurança. Deve ser prestada atenção à localização em condições

adequadas do hardware, onde factores estranhos não possam interferir com o

funcionamento do sistema.

5. Software

5.1. O software é um componente crítico de um sistema informatizado. O utilizador

deve tomar as medidas razoáveis para garantir que ele tenha sido produzido de

acordo com um sistema adequado de Garantia da Qualidade. O fornecedor de

software deve ser devidamente qualificado, o que pode incluir a sua avaliação e /

ou auditoria.

5.2. Os sistemas informatizados devem ser concebidos e desenvolvidos de acordo com

um sistema de gestão de qualidade adequado. A documentação fornecida com os

produtos comerciais deve ser revista pelos titulares de autorização de fabrico para

verificar que se os requisitos do utilizador estão satisfeitos.

5.3. Informações sobre o sistema de qualidade e de auditorias, relativos aos

fornecedores ou desenvolvedores de software e sistemas, implementados pelo

titular da autorização de fabrico, devem ser disponibilizados aos inspectores, a

pedido, como material de apoio destinado a demonstrar a qualidade dos

processos de desenvolvimento.


14

6. Dados

6.1. O sistema deve incluir, se for caso disso, verificações internas para verificar da

entrada e processamento correcto e seguro de dados, incluindo dados transcritos

manualmente de outros meios ou sistemas, como por exemplo, portáteis de

laboratório, ou relatórios de outros sistemas ou instrumentos, que não estão

directamente interligados com o sistema informatizado. Os sistemas de controlo e

gestão de dados e documentos devem ser concebidos para assegurar a

integridade dos dados e a gravação irrefutável da identidade dos operadores que

entram ou confirmam dados (ou seja a partilha de senhas de acesso não é

permitida), assim como da origem e fonte dos dados registados ou recebidos

automaticamente. Sistemas críticos devem ser projectados e protegidos para

assegurar que os dados e arquivos não podem ser alterados sem as autorizações

adequadas. Devem existir registos de actividade electrónicos imutáveis, para

alterações feitas para todos os níveis de acesso, incluindo os administradores do

sistema.

7. Teste de utilizador e adequação do sistema ao propósito

7.1. Antes que um sistema informático substituto, novo ou actualizado seja colocado

em uso, deverá ser completamente especificado, documentado, validado, testado

e aprovado conforme referido nas secções anteriores deste anexo. O pessoal

utilizador deve ter recebido treino eficaz documentado sobre a utilização de tais

sistemas (ver anexo 15 que também fornece alguns conselhos sobre o teste de

aceitação do utilizador). Quando estão a ser substituídos, sistemas manuais ou

sistemas informatizados pré‐existentes pode ser adequado realizar testes

comparativos “em paralelo", ou "em série".

8. Segurança

8.1. Devem ser criados controlos físicos e / ou lógicos para restringir o acesso dos

sistemas informatizados somente a pessoas autorizadas. Métodos eficazes de

prevenir a entrada a áreas de acesso restrito de equipamento informático e de

armazenamento de dados, incluem o uso de chaves, cartões magnéticos pessoais,

códigos com senhas e biometria entre outros.

8.2. O acesso a aplicações, pastas, arquivos e dados deve ser controlado através de

permissões de execução, definidas no sistema de gestão de segurança de


15

informação do titular da autorização de fabrico (Information Security

Management System ISMS)

8.3. Métodos adequados, proporcionais à criticidade dos dados, devem ser criados e

implementados para impedir e registar a entrada e/ou modificações não

autorizada de dados. Estes métodos podem incluir o limite do tempo de acesso,

encriptação ou reintrodução de identificador único para dados críticos.

8.4. No ISMS deve haver um procedimento definido, que permita o rastreamento da

atribuição, alteração e cancelamento de autorização, de acesso ao sistema à

aplicação ou ao acesso a dados.

8.5. Devem ser considerados, com base numa avaliação de risco, mecanismos para a

detecção de tentativas de acesso não autorizado ao sistema, a arquivos e dados,

de modo a definir acções adequadas.

9. Verificação de Precisão

9.1. Para a inserção manual ou por transferência de outro sistema, de dados críticos

(por exemplo: o peso e o número do lote durante a preparação, ou a introdução de

dados de laboratório), deve haver uma verificação adicional sobre a precisão do

registo que é feito, antes do processamento desses dados. Essa verificação pode

ser feita por um segundo operador, ou por meio electrónico validado. A criticidade

e as consequências potenciais de dados errados ou digitados incorrectamente num

sistema, devem ser avaliados numa avaliação de risco e como parte da validação.

9.2. Se um sistema informatizado controla um processo crítico (em que a criticidade é

baseada na avaliação de risco, como documentado por um processo do titular de

autorização), uma verificação independente secundária de parâmetros críticos

desse processo deve ser implementada.

10. Rastreabilidade para auditoria

10.1. O sistema deve permitir o registo da identidade única de operadores que inserem

ou confirmam dados críticos. Qualquer entrada ou alteração de dados críticos

deve ser autorizada e registada com a justificação para a mudança. Deverá ser

dada atenção à implementação no sistema, de um registo completo de todas as

entradas e alterações (um sistema gerando "rastreabilidade de auditoria"). A

rastreabilidade de auditoria necessita de reflectir com precisão as alterações (por


16

exemplo, se um registo electrónico relevante é criado usando um determinado

número de campos, todos estes devem ser ligados para a rastreabilidade de

auditoria. O objectivo é saber em qualquer ponto do tempo que informação foi

registada). Os rastreios de auditoria devem estar disponíveis e conversíveis em

forma legíveis.

11. Assinaturas

11.1. Os registos electrónicos podem ser assinados, ou electronicamente ou por uma

assinatura numa cópia impressa do registo. Isso só é aceitável se todas as

informações relevantes de meta‐dados estiverem incluídas na impressão. As

assinaturas electrónicas e identificação por meios biométricos são desejáveis se:

São legalmente equivalentes à assinatura manuscrita,

Estão ligados ao registo respectivo,

Incluem a data e a hora em que foram aplicados.

11.2. Podem ser aplicáveis requisitos legais nacionais para o controlo dos registos

electrónicos e das identidades ou assinaturas electrónicas a eles ligadas. As cópias

impressas dos documentos electronicamente compilados e assinados devem ser

rastreavam através da impressão de caminhos na transacção electrónica original.

12. Controlo de alterações e gestão de configuração

12.1. A alteração de qualquer componente de um sistema informatizado deve ser feita

apenas em conformidade com procedimentos e politicas de gestão de risco

definidos pelo titular de autorização de fabrico. Estes procedimentos devem incluir

disposições para a avaliação do impacte da mudança, na qualidade do produto,

na integridade do sistema de dados. Deve ainda ser referido o âmbito de qualquer

trabalho de validação necessário, com o seu relato e revisão, de modo a aprovar e

implementar a mudança.

13. Impressos

13.1. A Impressão de registos deve indicar se algum dos dados foi alterado desde a

entrada original. Para sistemas complexos, pode também ser necessário que os

inspectores sejam capazes de aceder e estudar os sistemas de registos electrónicos


17

em tempo real (por exemplo, bases de dados, cromatografias, controlo de

processos, etc.)

14. Armazenamento de Dados

14.1. A segurança dos dados deve ser garantida por meios físicos e electrónicos contra

danos dolosos ou acidentais. Os meios de armazenamento utilizados devem ser

submetidos a uma avaliação de qualidade, fiabilidade e durabilidade por ou em

nome do titular de autorização de fabrico. Os dados armazenados devem ser

verificados para a acessibilidade, durabilidade, legibilidade e precisão. Os

mecanismos de verificação não devem constituir um risco para os dados presentes

no sistema. Se são propostas mudanças para os equipamentos ou seus programas,

os controlos acima mencionados devem ser realizados com um frequência

adequada para o suporte de armazenamento a ser utilizado. O acesso aos dados

deve ser garantido durante todo o período de retenção.

15. Cópias de segurança; Migração, Recuperação; Arquivo

15.1. Devem ser feitas cópias de segurança regulares de todos os dados pertinentes. As

cópias de segurança dos dados devem ser armazenadas num local separado e

seguro. A integridade e precisão das cópias e segurança dos dados devem ser

verificados durante ou após a conclusão do processo

15.2. Caso o sistema não tenha capacidade de retenção de registos para o período de

tempo especificado os dados devem ser devidamente arquivados. A segurança dos

dados arquivado, deverá ser garantida por meios físicos e/ou por meios

electrónicos contra danos intencionais e/ou acidentais. Estes dados devem ser

verificados periodicamente sobre a sua acessibilidade, durabilidade, legibilidade e

integridade. Se forem feitas alterações no equipamento do computador ou nos

seus programas, deve ser em seguida verificada a capacidade de restaurar os

dados.

15.3. As práticas de cópias de segurança, arquivo, recuperação precisam ser definidas,

testadas e estabelecidas em conformidade com o sistema de gestão da qualidade

do titular da autorização de fabrico, o ISMS e requisitos de gestão de risco.


18

16. Continuidade de Operações

16.1. Para a implementação de sistemas informatizados apoiando processos

regulamentares críticos ou de risco de vida, devem ser tomadas medidas para

garantir a continuidade do apoio aqueles processos em caso de avaria do sistema

(por exemplo, um sistema alternativo manual). O tempo necessário para

implementar soluções alternativas deve ser mínimo e adequado para um

determinado sistema. Estas disposições deverão ser devidamente documentadas e

testadas.

17. Gestão de Incidentes

17.1. Falhas do sistema e erros de dados devem ser monitorizados, registados,

analisados e acções correctivas e preventivas devem ser executadas conforme o

caso. Devem ser definidos e verificados os procedimentos a seguir em caso de

falha ou rotura do sistema

18. Fornecedores

18.1. Quando agências externas, fornecedores ou outros, fornecem, instalam,

configuram, integram, validam, mantêm ou modificam um sistema informatizado,

processam dados ou prestam serviços relacionados, deve haver um acordo formal

explícito definindo claramente as responsabilidades desses agentes

18.2. Para que o titular da autorização de fabrico possa assegurar que os produtos

medicinais estão aptos para o uso pretendido, a competência e a fiabilidade dos

fornecedores são factor essencial na escolha de um produto ou prestador de

serviços para que tal objectivo possa ser assegurado. A necessidade de uma

auditoria de apoio para este fim (selecção de fornecedores) deve ser baseada

numa avaliação de risco (em relação ao impacto do sistema na qualidade e

segurança do produto, bem como na segurança e integridade de dados) para

determinar se o sistema informatizado foi projectado e desenvolvido, e é mantido,

em conformidade com um sistema adequado de gestão da qualidade. A

continuidade do suporte técnico dos fornecedores deve ser documentada num

contrato escrito.


19

19. Libertação de lotes

19.1. Quando a libertação de lotes para venda ou o fornecimento é efectuado através

de um sistema informático, o sistema deverá permitir que apenas uma pessoa

qualificada ateste a libertação dos lotes e deve claramente identificar e registar a

pessoa que libertou esses lotes. Qualquer certificação produzida por sistemas

informatizados deve estar claramente relacionada com a identidade da pessoa

que certificou. Os nomes devem ser claramente declarados e rastreáveis para as

operações de verificação ou auditoria, relacionadas com GMP, tanto para o caso

dos registos electrónicos como para os impressos, com a data, hora contexto e

identidades (fonte humana ou electrónica).

…”

Também o Guia do Conselho da Europa (Council of Europe. 2009) descreve nos seus

princípios e padrões a necessidade da realização por parte do utilizador final, de

procedimentos de validação com pontos semelhantes aos descritos anteriormente.

Os SSS são desenhados para impossibilitarem a distribuição de sangue ou produtos

sanguíneos inadequados pelo que devem ser considerados dispositivos críticos já que a sua

utilização está ligada directamente ao processo de produção, teste, rotulagem e libertação

para transfusão de sangue ou de componentes sanguíneos, e são utilizados para manipular

e armazenar a informação relacionada (ISBT, Bocker et al. 2003; ISBT, Sampson et al.

2010). A verificação, validação e certificação são actividades essenciais no ciclo de vida de

qualquer sistema integrado considerado crítico para a segurança.

O desenvolvimento de qualquer sistema não está completo sem a realização de um teste

rigoroso e verificação de que a aplicação é compatível com as especificações. Com o

aumento da complexidade do software nos sistemas, o processo de verificação e validação

(V&V) tem‐se tornado cada vez mais importante e o seu planeamento é necessário a partir

do início do ciclo de vida do desenvolvimento.

Durante os últimos 30 a 40 anos, o desenvolvimento de software tem evoluído de

pequenas tarefas, envolvendo um pequeno número de pessoas, para tarefas de grandes

dimensões envolvendo muitas mais. Anteriormente, verificação e validação consistiam

num processo informal realizado pelo próprio engenheiro de software. Com o aumento da

complexidade dos sistemas tornou‐se óbvio que continuar este tipo de teste resultaria em


20

produtos pouco fiáveis. Tornou‐se necessário olhar para V&V como uma actividade

independente integrada na perspectiva global do ciclo de vida do desenvolvimento de

software. A V&V actualmente é abordada de uma forma significativamente diferente do

passado, uma vez que é praticada ao longo de todo o ciclo de vida do software. É também

muito formalizada e, por vezes, as actividades são realizadas por organizações

independentes do fabricante do software (Andriole 1986). Além disso, como a V&V é um

componente importante de apoio à certificação está muito relacionada com a mesma.

A qualidade do Software deve focalizar‐se na prevenção da introdução de defeitos no

processo de desenvolvimento e não em tentar "testar e introduzir a qualidade" no código

fonte, depois de ele ter sido escrito na totalidade. Os testes de software são muito

limitados na sua capacidade de detectar todos os defeitos latentes no código já que a

complexidade da maioria dos softwares impede que sejam testados exaustivamente. São

no entanto uma actividade necessária, mas na maioria dos casos, não são suficientes para

estabelecer a confiança de que o software está apto para o uso pretendido. Para

estabelecer essa confiança, os programadores de software devem usar uma mistura de

métodos e técnicas para evitar erros. A melhor combinação de métodos depende de

muitos factores, incluindo o ambiente de desenvolvimento, aplicação, tamanho do

projecto, a linguagem, e o risco envolvido (FDA/CBER (U.S.) 2002).

O termo “validação” é interpretado de diferentes formas em campos diferentes. Alguns

autores utilizam os termos “verificação” e “validação” sem qualquer distinção e em alguns

casos é referido “verificação, validação e teste (VV&T)” como sendo um único conceito,

sem distinção entre os três termos (FDA/CBER (U.S.) 2007). No âmbito das normas ISO

“verificação” e “validação” são tratados como termos distintos e separadamente.

Verificação é definida como "o processo de avaliação de um sistema ou componente para

determinar se os produtos de uma determinada fase de desenvolvimento satisfazem as

condições impostas no início dessa fase." (IEEE. 1990; FDA/CBER (U.S.) 2002) A verificação

de software olha de um modo exaustivo para a consistência, integralidade e exactidão, do

software e da sua documentação, durante o seu desenvolvimento, e fornece as bases para

uma decisão posterior relativa à sua validação (FDA/CBER (U.S.) 2002). A verificação de

software significa a confirmação por exame e disponibilização de evidências objectivas que

os requisitos especificados foram cumpridos (FDA/CBER (U.S.) 2002; FDA/CBER (U.S.)

2007).


21

Validação, por outro lado, é definida como "o processo de avaliação de um sistema ou

componente durante ou no final do processo de desenvolvimento para determinar se

satisfaz os requisitos especificados" (IEEE. 1990) ou "confirmação por exame e

fornecimento de evidências objectivas de que as especificações particulares para as

utilizações pretendidas do software podem ser consistentemente satisfeitas" (FDA/CBER

(U.S.) 2007). Para a FDA, a conclusão de que um software está validado está dependente

de testes que abrangem a inspecção, análise, e outras tarefas de verificação a realizar em

cada fase do ciclo de vida do desenvolvimento do software.

Portanto, a verificação demonstra simplesmente a coerência entre a entrada e saída dos

resultados nas diferentes fases do processo. Não irá detectar erros resultantes da

especificação incorrecta de entradas, podendo esses erros propagar‐se sem serem

detectados através de fases posteriores do ciclo de desenvolvimento. Não é suficiente

depender apenas da verificação, pelo que a validação é necessária para comprovar se há

problemas com a especificação e para demonstrar que o sistema está operacional.

Dependendo da situação e da fase do ciclo de vida do software ou do sistema podemos

considerar 3 tipos de validação.

“Validação concorrente é a validação realizada quando não há possibilidade de

completar um programa de validação antes de libertar um produto ou parte dele.

Neste caso, todas as preocupações da validação devem ser documentadas antes

da libertação do produto.

Validação prospectiva é a validação realizada antes da distribuição de qualquer

novo produto, ou produto fabricado ao abrigo do processo de fabrico revisto, em

que as revisões podem afectar as características do produto” (ISBT, Bocker et al.

2003).

“Validação retrospectiva é a validação de qualquer SISS ou SSS que já esteja a ser

utilizado para gerir registos críticos. Deve fazer parte de um programa de

correcção que pode incluir a retirada ou substituição do actual sistema para

cumprir com as especificações reguladoras. No caso de sistemas de bases de

dados, a validação retrospectiva pode ser utilizada para confirmar a integridade

dos registos existentes” (Wingate 2004).


22

Tendo em conta que a validação se pode tornar uma tarefa bastante onerosa, tanto em

tempo como economicamente, deve ser colocado ênfase em conseguir obter resultados

reprodutíveis e de grande qualidade, e não em testes extensos desnecessários e em

documentação demasiadamente detalhada (Tracy and Nash 2002).

Quanto à certificação esta pode ser definida como a demonstração formal da realização de

um processo de confirmação, evidenciando que um sistema ou componente está em

conformidade com os requisitos especificados e é aceitável para uso operacional (IEEE.

1990).

Uma das características associadas ao software é a rapidez e facilidade com que este pode

ser alterado. No entanto, devido à sua complexidade, o processo de desenvolvimento de

software deverá ser alvo de um controlo ainda mais apertado do que o hardware, de

forma a prevenir problemas que podem não ser facilmente detectados mais tarde no

processo de desenvolvimento (FDA/CBER (U.S.) 2002).

Embora possa não fazer parte da validação do sistema, cada serviço de sangue deve basear

a sua escolha de um SSS numa avaliação e comparação dos softwares existentes em função

das suas necessidades, devendo posteriormente monitorizar a existência de relatos de

ocorrências relativas a esse sistema (FDA/CBER (U.S.) 2007).

A ISBT considera que a validação deve começar no momento em que se toma a decisão de

adquirir um SISS (cujo conceito engloba os sistemas de informação e equipamentos) ou

implementar um novo processo (ISBT, Bocker et al. 2003).

A validação de um SISS deve reflectir e antecipar a verdadeira utilização do sistema nesse

local específico.

Alterações efectuadas a um processo existente devem dar início a um processo de

validação como parte do procedimento de controlo de alterações (ISBT, Bocker et al.

2003). É necessário garantir a implementação de um processo eficaz de gestão das

alterações para determinar tanto os seus potenciais benefícios, custos e efeitos, como para

garantir que foram adequadamente testadas (Evans 2004).

Devido à complexidade dos SISS e dos SSS, mudanças pontuais aparentemente pequenas

podem ter um impacte significativo no sistema global. Quando qualquer alteração (mesmo

que pequena) é feita no SISS, é necessário que seja restabelecido o estado de validação do

software. Sempre que o software é alterado, deve ser realizada uma análise de validação


23

não só para validação de cada mudança, mas também para determinar a extensão e o

impacte dessa alteração sobre a totalidade do sistema. A realização de um nível adequado

de testes retrospectivos deve permitir determinar se porções inalteradas, mas vulneráveis,

do sistema não foram prejudicadas. A análise e testes retrospectivos adequados fornecem

a confiança de que o software está validado após uma alteração. É recomendável, quando

a análise for indicativa disso, que se faça a repetição de casos de teste em que o sistema

passou previamente, fazendo assim uma comparação actual–retrospectiva (FDA/CBER

(U.S.) 2002). Quando o fabricante realiza alterações ao software, este deve informar os

clientes de que outras funções podem ter sido afectadas. No entanto, a responsabilidade

por assegurar que o SISS foi validado para a utilização pretendida continua a ser do

utilizador do serviço de sangue ou de medicina transfusional (FDA/CBER (U.S.) 2007).

Na perspectiva da FDA, as actividades de validação devem ser conduzidas cumprindo com

o preceito básico da garantia da qualidade de “independência da revisão”. A auto‐

validação é difícil. Quando possível, uma avaliação independente é sempre melhor,

especialmente para aplicações de risco mais elevado. Em alguns casos são contratados

terceiros para uma verificação e validação independentes, mas esta solução pode nem

sempre ser viável. Outra abordagem pode ser a atribuição das actividades de verificação e

validação a funcionários internos com conhecimentos suficientes para avaliar o projecto e

que não estão envolvidos na sua concepção ou execução (FDA/CBER (U.S.) 2002).

O que parece ser óbvio, é que o processo de validação pelo utilizador deve ser realizado

por uma entidade que não tenha conflitos de interesse com o fornecedor, podendo ser

realizado pelo próprio utilizador ou por terceiros.

Os utilizadores finais devem desenvolver e executar o seu próprio plano de validação, mas

quando necessário e viável, podem contratar consultores independentes para aconselhar e

desenvolver os materiais necessários para a realização da validação ou mesmo para

realizar todo o processo. Os fornecedores devem fazer a verificação da instalação, mas não

a validação operacional e dos processos. Permitindo que os fornecedores do software

trabalhem juntos com os utilizadores e terceiros (consultores de software independentes)

talvez se obtenha um padrão mais elevado de funcionamento do software.


24

2.2 Quanta validação é necessária: a gestão do risco

A validação de software consiste, principalmente, em desenvolver um nível de confiança

de que o dispositivo cumpre todos os requisitos e expectativas do utilizador relativamente

às características e funções automatizadas que possui e pode constituir uma boa forma

dos utilizadores “aprenderem” o sistema.

O nível de confiança e o nível do esforço de validação necessários variam, dependendo dos

potenciais perigos que representam as funções automatizadas do sistema. A própria FDA

refere que se deve usar a abordagem menos pesada para cumprir com os requisitos

reguladores (FDA/CBER (U.S.) 2002). O plano de teste e casos de teste devem ser

desenvolvidos com base numa avaliação de risco numa fase precoce do processo de

validação. Com base nos riscos e pontos críticos identificados, deve ser determinado o grau

de validação necessária e desenvolvido o plano e casos de teste adequados. Por exemplo,

as possíveis consequências fatais da falha de uma função automatizada implicam um grau

de teste mais elevado (FDA/CBER (U.S.) 2007).

Deve optar‐se por uma abordagem baseada no risco para garantir que se vão focalizar os

esforços, nos pontos em que é mais provável ocorrerem problemas. Ter em conta o risco

inerente à falha de diferentes partes do sistema, permite‐nos testar até um nível razoável,

e evitar gastar muito tempo a testar detalhes (Evans 2004).

A avaliação de riscos é necessária quando um novo sistema automatizado está a ser

implementado, actualizado ou a sua retirada de funcionamento está a ser planeada. A

avaliação de riscos deve ser realizada para identificar pontos de controlo críticos, para

determinar os tipos de testes necessários e definir planos de mitigação de risco. Isso

requer considerações sobre o impacto, probabilidade e detectabilidade de um potencial

perigo ou de dano para um sistema informatizado.

A avaliação de riscos também analisa os pontos críticos de controlo no software e pode

identificar as áreas em que, se houver uma falha ou mau funcionamento, pode ocorrer

dano para o paciente, dador ou actividade/empresa.

A avaliação dos riscos tem um lugar importante no processo de validação, pois pode

maximizar recursos pela utilização de testes "melhores e mais inteligentes”. Uma vez que é

impossível testar tudo, é melhor identificar as funcionalidades que implicam maior risco e

gastar proporcionalmente mais tempo e esforço na validação destes processos. Fornece

um conjunto de directrizes para garantir que os módulos com o grau de risco mais alto são


25

abordados mais fortemente. Uma vez definida, uma avaliação de risco contribui para

explicar o impacte de uma falha do software, seja ele funcional ou financeiro (ISBT,

Sampson et al. 2010).

Muitos sistemas automatizados utilizados em bancos de sangue são considerados pacotes

de software configurável. Uma característica típica destes sistemas é que eles permitem

que cada utilizador final desenvolva as suas próprias parametrizações,

personalizando/configurando o sistema. Cada aplicação torna‐se específica para esse

utilizador e a manutenção do sistema torna‐se um processo importante, especialmente

quando são instaladas novas actualizações para o sistema. Muitas vezes, o sistema

configurável faz parte de uma rede muito maior, que por sua vez constitui todo o sistema.

Isto impossibilita ao vendedor a validação de cada tipo diferente de sistema final. A

quantidade de testes e quantas vezes o mesmo processo é testado, dependem da

quantidade de risco que a funcionalidade possa apresentar. Isso deve fornecer ao

utilizador um maior grau de certeza/garantia de que o sistema irá produzir

consistentemente um produto de qualidade.

É necessária uma abordagem sistemática para realizar uma avaliação exaustiva dos riscos.

Primeiro, deve ser identificado cada risco potencial de um sistema ou subsistema e deve

ser rastreado qual o factor, evento ou causa que o activa. As informações relativas a cada

risco potencial são colhidas, analisadas e classificadas

Em seguida, devem ser fornecidas opções para a redução do risco, seja para o mitigar e/ou

eliminar. Pode ser decidido que os riscos no sistema são tão elevados, que este não deve

ser implementado. Se for decidido avançar com a implementação, devem ser utilizados

controlos, do processo ou do produto, para reduzir/mitigar e/ou eliminar os riscos

potenciais identificados.

Devem ser dadas opções para reduzir, mitigar e/ou eliminar o risco. A mitigação envolve

geralmente a criação de soluções alternativas, quer com software independente ou com

procedimentos operatórios normalizados escritos que impeçam o utilizador final de

replicar o processo que cria risco no sistema (desvio em relação ao desejável). A

Documentação de todo o processo deve ser elaborada, aprovada e controlada (ISBT,

Bocker et al. 2003; ISBT, Sampson et al. 2010).


26

Várias abordagens de avaliação de risco são possíveis.

Um consórcio, no qual se inclui a American Medical Informatics Association (AMIA) definiu

um conjunto de recomendações à FDA (Miller and Gardner 1997), entre as quais se inclui

uma classificação para sistemas de software clínico em quatro categorias conforme o risco

(tabela 1).

Tabela 1 ‐ Categorias de risco de software clínico

Categoria 0 Sistemas genéricos ou informativos que fornecem conteúdo factual

Categoria 1 Sistemas de risco baixo específicos dos pacientes, que efectuam funções complexas relacionadas com a saúde com risco clínico relativamente baixo e possibilitam aos profissionais ignorar as suas acções ou indicações

Categoria 2 Sistemas de risco intermédio específicos dos pacientes, que efectuam funções complexas relacionadas com a saúde com risco clínico relativamente elevado, mas possibilitam aos profissionais ignorar as suas acções ou indicações

Categoria 3 Sistemas de risco elevado específicos dos pacientes, que efectuam funções complexas relacionadas com a saúde com impacte clínico elevado e dão aos profissionais pouca ou nenhuma oportunidade de intervir nas suas acções ou indicações. A cada uma destas categorias de risco deverá corresponder uma de quatro classes de acções reguladoras.

Uma outra abordagem (guia GAMP), classifica os tipos de software em cinco categorias:

Categoria 1 – Sistema Operativo;

Categoria 2 – Firmware;

Categoria 3 – Pacotes de Software Normalizados;

Categoria 4 – Pacotes de Software Configuráveis;

Categoria 5 – Software Personalizado.

A cada categoria deve corresponder uma abordagem de validação específica, sendo que a

categoria 5 requer realização de auditoria ao fornecedor e a validação de todo o sistema

(GAMP Forum. 2001).


27

Um outro modo de abordar o risco associado ao processo em análise para validação, é a

classificação proposta nas directrizes da ISBT, para a validação de sistemas automatizados

(ISBT, Sampson et al. 2010), que embora mais simples, pode ser facilitador em ambientes

regulados (Tabela 2).

Tabela 2 – Classificação de risco proposta nas directrizes da ISBT

Alto

Médio

Baixo

Os riscos são considerados intoleráveis

Os riscos são indesejáveis

Os riscos são tão baixos que podem ser negligenciados

Mesmo as análises de risco e avaliações de boas práticas mais superficiais podem

facilmente confirmar que os SISS devem ser classificados como sistemas que tratam dados

críticos e de risco elevado, tais como:

Registo de dadores;

Selecção de dadores (detalhes pessoais dos dadores);

Resultados de análises laboratoriais das unidades de sangue (ABO/Rh/doenças

infecciosas, etc);

Dados de testes de compatibilidade;

Prazo de validade de produtos sanguíneos, etc.

Estes sistemas devem ser validados prospectivamente porque só assim se pode ter a

garantia de que eles cumprem fiável e consistentemente com as funções pretendidas, com

os regulamentos relevantes, e acima de tudo, não põem em causa a segurança dos

receptores do sangue (Wingate 2004).


28

2.3 Modelos de Validação

Como já foi referido, a validação de um SISS deve ser abordada de um modo global. Assim,

a abordagem normalizada de Qualificação das instalações (QI), Qualificação das Operações

(QO), e Qualificação do Desempenho (QD) é fundamental e bem conhecida na indústria

farmacêutica. Segundo as especificações da FDA estes conceitos definem‐se da seguinte

forma.

“Qualificação das instalações – demonstra que o sistema foi instalado correctamente.

Depois de iniciada a qualificação de instalações as alterações ao sistema e infra‐

estrutura devem manter‐se sob controlo formal. O apoio do fornecedor é obrigatório

durante os testes de qualificação de instalação. A qualificação de instalação tem como

objectivo criar confiança de que os equipamentos e sistemas auxiliares são

compatíveis com os códigos adequados e intenções dos modelos aprovados, e que as

recomendações do fabricante foram devidamente consideradas. Pontos importantes

na qualificação de instalações são os seguintes:

Condições de instalação (hardware, software; cablagem, UPS, etc.);

Conexões de interface;

Documentação do fornecedor;

Documentação de Software e hardware;

Cópias de segurança do Software;

Aspectos de segurança;

Condições ambientais (tais como temperatura, humidade).


29

Qualificação das operações – Nesta fase, o sistema automatizado e os parâmetros de

funcionamento processo devem ser testados para garantir que o produto resultante

cumpre com todo os requisitos definidos pelo utilizador em todas condições de fabrico

previstas, incluindo testes de pior cenário. Tem como objectivo “estabelecer confiança

de que os equipamentos e sistemas auxiliares são capazes de operar consistentemente

com os limites e tolerâncias estabelecidos.” Pontos importantes na qualificação das

operações são os seguintes:

Configuração;

Funcionalidades do sistema, incluindo alarmes e limites;

Limites de controlo do processo monitorizados pelo sistema;

Especificações operacionais do sistema;

Procedimentos operacionais do processo;

Controlo de alterações ao processo;

Formação;

Dados para provar a estabilidade e a capacidade do processo onde o sistema é

utilizado;

Avaliações de modos de falha potencial e das condições de pior cenário

(análise de riscos e pontos de controlo críticos, modo de falha e análise de

efeito, análise da árvore de falhas);

Cópias de segurança e recuperação;

Acesso e segurança ao sistema.


30

Qualificação de desempenho. O objectivo é demonstrar que o processo informatizado

produz resultados aceitáveis de forma consistente e em condições normais de

funcionamento. Devido a razões de ordem prática parte dos testes das condições

limitantes e extremas muitas vezes realizado nesta fase.

Poder‐se‐á realizar a QD em duas vertentes:

Qualificação do desempenho do processo – Estabelecer confiança de que o

processo é eficaz e reprodutível.

Qualificação do desempenho do produto – Estabelecer confiança através de

ensaios adequados, que o produto final obtido por um determinado processo

cumpre todos os requisitos de libertação relativos à funcionalidade e

segurança.” (FDA (U.S.) 1995; ISBT, Bocker et al. 2003)

Pontos importantes na qualificação de desempenho incluem os mesmos pontos da QO

realizados em ambiente de produção:

Devem ser utilizados parâmetros informatizados reais e procedimentos

estabelecidos na QO e utilizados durante a operação;

Reconfirmar a aceitação dos processos informatizados como estabelecido na

QO;

Reconfirmar a reprodutibilidade do processo e garantir a sua estabilidade

quando utilizado em ambiente real com operadores treinados;

Migração de dados para a nova plataforma.

Apesar de toda a variabilidade que se pode verificar na diversidade dos SISS, existem vários

modelos de validação, sendo os mais “populares” o Modelo em V da GAMP e o Modelo em

V da Engenharia Informática.

O Modelo em V da GAMP (figura 1), apesar de incluir terminologia (IQ/OQ/PQ),

conceptualmente não se adequa com uma abordagem lógica para validação de sistemas de

software, faltando‐lhe algumas relações, pelo que pode ser considerado

fundamentalmente incompleto se considerarmos os conceitos de verificação e validação

como complementares.


31

Figura 1 ‐ Modelo em V da GAMP‐1

Figura 2 ‐ Modelo em V da GAMP‐2

O Modelo em V da Engenharia Informática (figura 3) pode ser considerado como uma

abordagem muito mais compreensiva da verificação como um pré‐requisito para a

validação. Relativamente ao primeiro modelo, é mais detalhado e apresenta

rastreabilidade entre os diferentes níveis. No entanto, ainda lhe falta a realização de testes

finais e validação.


32

Figura 3 ‐ Modelo em V da Engenharia Informática

Combinando estes dois modelos, é possível cobrir todos os requisitos de uma abordagem

compreensiva da validação. Consegue‐se testar e confirmar a validação detalhada das

actividades de desenvolvimento do software (configuração e/ou personalização) e os

aspectos do processo global (Tracy and Nash 2002).

Figura 4 ‐ Modelo em V resultante da combinação dos modelos da GAMP com o da Engenharia Informática


33

2.4 Plano de validação

Um plano de validação deve ser elaborado após ser tomada uma decisão para mudar ou

implementar de novo, um sistema existente. É um registo histórico que deve ser arquivado

após a conclusão do processo.

O plano de validação deve fornecer uma descrição do sistema automatizado, as actividades

de validação, as responsabilidades, os procedimentos, como a validação deve ser feita e

resultados esperado, conjuntamente com as exigências de aceitação. Devem ser definidos

os papéis e responsabilidades do utilizador e fornecedor nas actividades de validação. A

identidade dos autores, revisores e aprovadores dos resultados devem ser identificados no

plano. Devem ser incluídos procedimentos para documentar, relatar, avaliar e resolver

incidentes e desvios detectados durante o processo de validação, bem como mecanismos

para documentar e justificar excepções a estes procedimentos e ao plano de validação. O

plano completo de validação deve ser revisto e aprovado de acordo com as políticas da

instalação do sistema de qualidade. Os protocolos de validação serão usados para produzir

evidências documentais, de que o sistema desempenha conforme o esperado (ISBT,


A abordagem de validação deve abranger os seguintes tópicos, que devem estar incluídos

no plano de validação:

Âmbito de Validação;

Constituição da equipa de validação;

Gestão do risco pela Qualidade;

Estratégia de validação:

Qualificação de instalação;

Qualificação Operacional;

Qualificação de Desempenho;

Planeamento operacional da validação, incluindo prazos e recursos;

Documentação a produzir no processo de validação;

Critérios de aceitação da validação;

Resultados de validação.


34

2.4.1 Âmbito de Validação

O âmbito de validação deve especificar a identificação do sistema automatizado, o

contexto do seu uso, os seus limites (ou seja, o que está dentro e fora do âmbito do

projecto de validação), os processos a ser empregues, e o objectivo da validação.

2.4.2 Constituição da equipa de validação

A utilização de uma equipa de validação assegura que os processos de validação estão bem

analisados, que os protocolos são abrangentes e que a validação final está bem

documentada e é fácil de seguir. A equipa deve aconselhar sobre os "piores" cenários,

comunicar com as principais áreas funcionais sobre produtos novos e alterados e gerir a

cooperação inter‐funcional. Os elementos da equipa de validação devem incluir,

utilizadores finais, colaboradores da Garantia de Qualidade, das TI e de outros serviços ou

departamentos envolvidos ou interessados (serviços de engenharia, fabricação,

laboratório, serviços técnicos, pesquisa e desenvolvimento, assuntos regulatórios, compras

e gestão de topo) dependendo do assunto.

2.4.3 Gestão de riscos pela qualidade

Deve envolver uma avaliação inicial dos riscos, incluindo uma decisão se o sistema ou parte

dele (s) está GxP regulamentado ou não. O nível de risco é um factor importante na

determinação do nível de esforço de validação.

2.4.4 Estratégia de validação

A estratégia a seguir para a validação vai depender do tipo e complexidade do sistema

automatizado e o grau de risco da sua utilização. Ela deve basear‐se essencialmente nos

diferentes elementos identificados na avaliação de risco e nos documentos apresentados

pelo fornecedor, relativos aos testes realizados utilização e gestão do sistema

automatizado em causa. A descrição da quantidade, tipo e resultados dos testes realizados

pelo fornecedor, pode ser usada para se decidir e concentrar a quantidade de testes

necessários durante o esforço de validação. A estratégia de validação deve definir as

actividades que podem ser realizadas de forma prospectiva, retrospectiva ou


35

concomitantemente. A estratégia deve definir a plataforma do(s) sistema(s) e ambiente

controlado em que os processos de qualificação devem ser realizados.

A estratégia de validação implica também a classificação das diferentes tarefas de

validação e testes que devem ser realizados para garantir a qualidade do uso de um

sistema automatizado, englobando:

Qualificação de instalação – demonstrando que o sistema tem foi instalado

correctamente. Depois de se ter iniciado a qualificação de instalação deve ser

demonstrado de modo formal que o sistema e infra‐estrutura estão sob controlo

de mudança. O apoio do fornecedor é obrigatório nesta fase.

Qualificação Operacional – nesta fase devem ser simuladas as condições que serão

encontradas durante a operação, o que deve incluir a gama de condições cobertas

pelo POP. O processo deve ser repetido o número de vezes suficientes para

garantir que os resultados são significativos e consistentes. Terão de ser testados

os limites superiores e inferiores do processo.

2.4.5 Planeamento operacional da validação, incluindo prazos e recursos

Dependendo da complexidade da validação processo, um cronograma deve ser

estabelecido para:

Avaliar o tempo e os recursos gastos na validação;

Definir o cronograma em que a validação deve ser executados;

Definir o momento em que o sistema automatizado deverá estar em operação.

2.4.6 Documentação a produzir no processo de validação

Devem ser elaborados relatórios das actividades de qualificação e a aderência aos

requisitos documentados. A infra‐estrutura deve ser qualificada sob a mudança de

controlo.


36

2.4.7 Critérios de aceitação da validação; resultados de validação

Os critérios gerais de aceitação de testes de validação e os resultados globais de aceitação

devem ser definidos no plano de validação.

Devem ser obtidos documentos relevantes durante o processo de teste. Estes documentos

devem ser usados para avaliar se sistema automatizado pode ou não ser validado ou

certificado.

2.5 Requisitos definidos pelo utilizador

Um processo de validação não pode ser iniciado sem o estabelecimento de especificações

prévias dos requisitos. Assim, a sua preparação deve começar precocemente, ou seja,

durante o desenho e planeamento do desenvolvimento. É necessário o estabelecimento

das especificações dos requisitos do utilizador (ERU) para um novo sistema ou para realizar

alterações significativas num sistema existente. Estas especificações devem descrever o

que o utilizador quer ou espera do sistema, não descrevendo como, mas afirmando

claramente o que se pretende. Não sendo esta uma tarefa fácil, necessita do

conhecimento de peritos e de capacidades analíticas. Sendo da responsabilidade do

utilizador, frequentemente apenas pode ser completada após consulta com os possíveis

fornecedores ou peritos independentes. A aprovação das ERU deve ser documentada de

acordo com o sistema de gestão da qualidade (SGQ).

No caso de software desenvolvido de forma personalizada as ERU formarão a base para

uma especificação funcional (EF), que descreve cada uma das funções do sistema

necessárias para satisfazer os requisitos do utilizador.

Ao começar a especificar o que se quer ou deseja, é possível “colidir” com a linguagem

técnica dos requisitos. Assim há que definir claramente o que são.

As boas práticas de fabrico automatizado (GAMP) recomendam as seguintes directrizes

durante a elaboração do caderno de especificações:

Cada requisito deve ser referenciado apenas uma vez, não devem existir em

duplicado ou ser contraditórios;

Cada requisito não deve ter mais do que 250 palavras;

Devem ser expressas necessidades e não soluções de desenho;


37

Deve ser possível testar e rastrear cada requisito;

Tanto o utilizador como o fornecedor devem compreender o caderno de

especificações (evitar ambiguidade e jargão);

Sempre que possível, deve ser feita a distinção entre requisitos obrigatórios /

regulamentares e características desejáveis;

Devem ser incluídos requisitos de boas práticas de fabrico (GMP) relativos ao

sistema da qualidade do fornecedor;

Devem ser incluídos requisitos de segurança da informação (ISPE 2008; ISBT,


De modo a facilitar a elaboração destes requisitos pode‐se fazer a sua análise, classificação

e agrupamento nas categorias seguintes.

2.5.1 Requisitos de informação

A informação é essencial para estabelecer a estratégia e realizar os objectivos da

organização. No entanto, actualmente a quantidade de informação a ser gerida e a sua

complexidade, são grandes desafios para garantir a sua consistência e integridade.

A compreensão destas definições ajuda a focar na informação essencial necessária na

organização e a organizar a mesma adequadamente de forma a não a interpretar

erradamente passados muitos anos, já que embora os dados não mudem, o seu significado

pode mudar ao longo do tempo – INFORMAÇÃO, bem como o seu impacte no nosso

julgamento ou juízo – CONHECIMENTO.

Isto é essencial, especialmente para informação que precisa de ser rastreada por um longo

período tempo (por exemplo, na medicina transfusional, no que diz respeito às directivas

da UE, as informações relativas a dador‐produtos‐doente deve ser monitorizada/rastreada

por 30 anos). O significado da informação hoje, pode não ser necessariamente o mesmo

daqui a 30 anos. Há tantos factores que poderiam alterar o significado, tais como: evolução

do comportamento social, evolução da política e da regulamentação, evolução dos

processos do negócio, aquisição de conhecimento (Munk 2009b).


38

2.5.2 Requisitos de segurança

A complexidade e a quantidade crescentes da informação a ser gerida, bem como a

disponibilidade da informação a ser dada a organizações externas, exige que o proprietário

da informação tenha uma política de segurança da informação. A política deve ser

estabelecida tendo em consideração os regulamentos aplicáveis, bem como as

vulnerabilidades relacionadas com aspectos, tais como a configuração das redes, a

arquitectura das aplicações, as partes interessadas envolvidas e as infra‐estruturas. As

organizações de medicina transfusional devem assegurar quanto a sua informação o

seguinte:

Confidencialidade: entendida como "Garantir que a informação esteja acessível

apenas àqueles autorizados a ter acesso"

Integridade: entendida como "Salvaguardar a exactidão e a integridade das

informações e métodos de processamento"

Disponibilidade: entendida como "Garantir que os utilizadores autorizados tenham

acesso à informação e activos associados quando necessário" (ISO/IEC 2005; ISBT,

Bobos et al. 2006).

2.5.3 Requisitos de infra‐estruturas (perspectiva tecnológica)

A tecnologia adequada tem de estar disponível a curto, médio e longo prazo. A infra‐

estrutura é necessária para manter a informação sob controlo e para lhe dar acesso

adequado pelos interessados em momentos e locais adequados. É a principal salvaguarda

da informação além do factor humano.

O investimento numa infra‐estrutura depende de diferentes parâmetros relacionados com

o tamanho e a configuração da organização, a importância da informação ao longo dos

processos, e, sem dúvida, com a estratégia das operações.


39

Alguns exemplos de critérios a considerar no estabelecimento de requisitos de infra‐

estrutura são:

Requisitos de informação;

Quantidade de informação que deve ser gerida num período de tempo adequado;

Velocidade a que a informação deve estar disponível;

Política de continuidade do negócio;

As funções relacionadas com o processamento de informação, a fim de

seleccionar/desenvolver aplicações adequadas;

Interfaces simultâneas com outros sistemas, como sistemas automatizados,

sistemas de gestão empresarial (por exemplo, sistemas de contabilidade e de

facturação), armazéns de dados, sistemas ERP, Hospital de Base e outros sistemas

de TI organizacionais;

Configurações de rede;

Configurações do local de trabalho;

Sistemas de gestão dos dados (por exemplo, backup, arquivo) (Munk 2009b).

2.5.4 Classificação dos requisitos

Como referido acima cada requisito deve, sempre que possível, ser classificado em

requisito obrigatório/regulamentar ou característica desejável. Estas características tanto

podem ser definidas por documentos externos regulamentares, como baseada numa

análise de risco que define alguns deles como críticos para o funcionamento do sistema.

Na distinção de requisitos e estabelecimento de prioridades, pode ser utilizado o método

“MoSCoW” (Must, Should, Could, Won’t) (Clegg and Barker 1994) em que cada requisito

pode ser categorizado da seguinte forma:

TEM que ter “isto” (prioridade máxima).

DEVE ter “isto” se for mesmo possível.

PODERIA ter “isto” se não afectar mais nada.

NÃO terá “isto” agora, mas GOSTARIAMOS que tivesse no futuro. (prioridade

mínima)


40

Do exposto se retira da complexidade de que se pode revestir a tarefa de definição de

requisitos.

Sugere‐se, como orientadora a seguinte metodologia para elaboração da especificação dos

requisitos do utilizador (Sommerville 2007; ISPE 2008; Sage and Rouse 2009; ISBT,

Sampson et al. 2010):

1. Formar grupo de trabalho inicial (GTI) com 2‐3 elementos da instituição que

possuam:

Bom domínio de conhecimentos sobre a actividade e processos.

Competências informáticas.

Capacidades analíticas.

Nota: Se for necessário e economicamente viável, contratar peritos independentes.

2. O GTI pesquisa e selecciona os mais recentes normativos legais e orientações de

organizações e grupos de peritos, nacionais e internacionais, que vão servir de

referência para os requisitos.

3. O GTI escreve uma primeira lista de requisitos, com base nas referências

seleccionadas e nos conhecimentos que cada elemento tem dos processos.

4. Convidar outros elementos para integrar o grupo de trabalho (GT), máximo de 12

elementos:

A chefia de cada sector.

Outros profissionais com bom domínio de conhecimentos sobre a actividade e

processos e com capacidades analíticas.

5. Organizar 2 a 3 sessões de 1 dia (se possível, fora do local do trabalho para

minimizar interferências). A partir da primeira lista de requisitos vai‐se analisar,

discutir, elaborar requisitos consensuais e estabelecer prioridades para cada um de

acordo com critérios legais, de risco, funcionais, dos processos.


41

6. Coligir todos os requisitos obtidos e produzir um documento final que se pode

basear na seguinte estrutura:

a. Introdução

b. Objectivo e Âmbito

c. Descrição da Instituição e Suas Actividades

d. Descrição dos Grupos de Utilizadores e Seus Papéis

e. Riscos

f. Especificação de Requisitos do Utilizador

g. Referências

h. Glossário

i. Controlo da Versão/Revisão e Data

j. Assinaturas

7. Submeter o documento final à revisão de todos os utilizadores que integraram o

GT, da direcção e da gestão da qualidade. Nesta fase devem surgir as sugestões de

alteração/correcção que se considerem convenientes.

8. Reunir todos os utilizadores que integraram o GT, a direcção e a gestão da

qualidade para aprovação e assinatura do documento final revisto. O documento

passa a estar sujeito a controlo.


42

2.6 Protocolos de validação

Os testes de validação são frequentemente realizados por meio de protocolos de validação

detalhados que são desenvolvidos no contexto do plano de validação e de avaliação dos

riscos. Para a QI, QO e QD, os protocolos de validação devem conter (ISBT, Bocker et al.

2003; ISBT, Sampson et al. 2010):

Âmbito coberto;

As instruções de teste;

Os resultados esperados;

Os critérios de aceitação / rejeição;

Documentos para registo dos resultados dos testes, incluindo declaração de

aprovação ou rejeição e uma secção para o operador e o revisor assinar e datar.

Os protocolos de validação devem ser revistos de forma independente após a conclusão.

2.6.1 Resolução de problemas

Todos os problemas encontrados durante os testes devem ser documentados. Para a

análise dos problemas estes podem dividir‐se em duas categorias:

Falhas dos testes de validação

Devem ser realizadas as seguintes tarefas:

Documentar todos os casos de falha de teste;

Investigar todos os incidentes para determinar:

Se o teste foi descrito correctamente,

Se houve erro do utilizador na execução do teste,

Se houve um erro de especificação,

Se houve uma limitação do sistema;

Conclusões do documento e resolução;


43

Dependendo da alteração necessária para corrigir o problema, determinar se

apenas o caso de teste deve ser repetido, ou se são necessários testes de

regressão de diversas funções.

Questões não relacionadas com os ensaios/testes

Questões ou problemas que surgem devem ser documentados, investigados e resolvidos

antes de se considerar um sistema validado. Eles são encontrados quando existem

limitações do sistema por causa de factores como o ambiente e/ou limitações de recursos.

Documentar a solução irá fornecer informações históricas que serão úteis na tomada de

decisões futuras. Dependendo da criticidade da solução devem ser realizados testes

adequados, devendo por isso ser utilizada uma abordagem baseada em risco.

2.6.2 Relatório de Validação e revisão final

O relatório de validação apresenta os resultados das actividades de validação, incluindo a

migração de dados, interpretação dos resultados e conclusões. Se forem obtidos

resultados inesperados estes devem ser resumidos. O resumo deve definir quais as

mudanças e/ou "soluções" que serão necessárias para mitigar o risco.

A revisão final é feita por funcionários identificados no plano de validação, após a

conclusão do processo de validação e consiste em analisar todos os documentos gerados

durante o processo.

A revisão deve confirmar que:

A documentação está completa;

Os testes provam, com um elevado grau de fiabilidade, que o sistema irá

atender de forma consistente os seus critérios de aceitação;

A migração de dados está completa e exacta;

Qualquer não conformidade foi abordada através de resolução de problemas;

Os requisitos de formação foram cumpridos;

Que um plano de continuidade das operações negócios está implementado.


44

Os possíveis resultados desta revisão são os seguintes:

Libertação;

Libertação condicional;

Não libertar.

O sistema só pode ser libertado por pessoal qualificado. Se o sistema não pode ser

libertado ou só pode ser libertado condicionalmente, a razão para a decisão deve ser

documentada. Em todos os casos, as decisões devem focalizar a importância da segurança

do doente e do produto.

Após a libertação, a organização é responsável pela manutenção do estado de validação do

sistema automatizado de acordo com planos pré‐estabelecidos (ISBT, Sampson et al.

2010).

2.7 Conclusão

A verificação, validação e certificação são essenciais no ciclo de vida de qualquer sistema

integrado, considerado crítico para a segurança.

A validação de sistemas informáticos é crítica nos serviços de sangue e de medicina

transfusional pelas implicações que tem na segurança transfusional e pela necessidade de

serem cumpridos normativos legais.

A validação de sistemas informáticos deve ser conduzida no ambiente onde serão

utilizados.

A validação não deve ser feita ao hardware e software isoladamente, mas no seu conjunto

e interfaces.

É necessário no momento actual definir em Portugal o normativo da validação dos SISS.


45

3. Proposta de Especificação dos Requisitos do Utilizador

A actividade da medicina transfusional tem como objectivo fundamental, a obtenção,

disponibilização e acessibilidade de forma consistente e sustentada de sangue e

componentes sanguíneos de qualidade, seguros e eficazes.

Num ambiente regulado, como é o caso dos serviços de sangue e de medicina

transfusional, a definição de requisitos pelo utilizador deve ser obrigatoriamente

condicionada pelos mais recentes normativos legais e orientações, que reflectem as boas

práticas para a realização dessas actividades.

A Especificação de Requisitos do Utilizador (ERU) é um documento chave que descreve

exactamente o que o dono do processo quer ou espera do sistema, as necessidades do

utilizador final.

3.1 Objectivo e Âmbito

Pretende‐se com este documento especificar quais os requisitos para sistemas

informáticos de serviços de sangue e medicina transfusional, que os utilizadores dos

mesmos consideram necessários para poder realizar a sua actividade cumprindo com os

normativos legais aplicáveis e seguindo as directrizes internacionais de boas práticas

aplicáveis.

Esta ERU deve formar a base do contrato com o fornecedor, e no caso de sistemas

desenvolvidos de forma personalizada formará a base para uma especificação funcional

(EF), que descreve cada uma das funções necessárias para satisfazer os requisitos do

utilizador.

No caso de sistemas já implementados, esta ERU servirá de referência para a validação

retrospectiva dos mesmos, juntamente com o histórico do seu desempenho.


46

3.2 Descrição das organizações e suas actividades

A actividade dos Serviços de Sangue e Medicina Transfusional pode ser subdividida nas

seguintes áreas e actividades correspondentes:

3.2.1 Serviço de sangue

Promoção da dádiva/ Planeamento de colheitas

Os técnicos administrativos realizam o agendamento das sessões de colheita, o

envio de convites para a dádiva, agradecimentos ou material promocional da

dádiva (etiquetas, sms, mails, etc.).

Recepção / inscrição de dadores

O técnico administrativo:

Recebe o dador, presta‐lhe as informações necessárias e/ou solicitadas.

Faz a inscrição do dador com base nos dados identificativos fornecidos pelo

mesmo ou recuperando informação prévia.

Corrige dados se necessário.

O dador preenche o questionário, assina o consentimento informado e aguarda

chamada pelo médico para triagem.

Triagem Clínica / exame objectivo de dadores

Os médicos:

Chamam o dador para a triagem.

Analisam a história pregressa já registada (analítica e clínica), o questionário e o

consentimento informado.

Determinam e registam o valor da hemoglobina por um método rápido, a

pressão arterial e o peso.

Concluem da triagem clínica: aprova, suspende ou elimina o dador.

Podem fazer a atribuição do número de colheita.


47

Colheitas

Os enfermeiros:

Verificam a identificação dos dadores aprovados para a realização da dádiva.

Preparam e identificam os sistemas de colheita (sacos e tubos) adequados ao

tipo de colheita a realizar.

Rotulam os sacos e os tubos.

Realizam a colheita de sangue total ou selectiva de componentes sanguíneos.

Confirmam a identificação das colheitas relativamente aos dadores e registam

as colheitas ou causas de não validação das mesmas.

Podem fazer a atribuição do número de colheita.

Laboratórios (microbiologia, imuno‐hemoterapia e controlo da qualidade)

Os técnicos de análises clínicas:

Recebem, verificam e centrifugam as amostras relativas a cada colheita.

Realizam todas as análises obrigatórias e necessárias para a caracterização de

cada dador.

Procedem á transferência dos dados analíticos obtidos ou registam dados se

necessário.

Verificam e validam todos os resultados obtidos para cada dador.

Separação de componentes


Recebem, verificam e processam as colheitas preparando os componentes

sanguíneos.


48

Rotulagem/gestão de stocks/distribuição


Rotulam os componentes sanguíneos e procedem à verificação da congruência

da rotulagem.

Recebem pedidos de componentes sanguíneos para reposição dos stocks dos

serviços de medicina transfusional.

Enviam os componentes sanguíneos requisitados em função dos stocks

disponíveis em cada momento (gestão dos stocks).

3.2.2 Serviço de Medicina Transfusional

Gestão de stocks

Os responsáveis, sejam médicos ou técnicos fazem:

Registo inequívoco de cada unidade recebida e das suas características

relevantes (tipo de componente, grupo ABO e Rh(D), processamento, data de

validade…).

Monitorização do stock existente – utilização de componentes com

características semelhantes, com prioridade à data de validade.

Preparação de transfusões

Os técnicos de análises clínicas, os médicos ou os administrativos fazem:

Registo do pedido transfusional

Os técnicos de análises clínicas ou os médicos fazem:

Registo de testes de compatibilização (pré‐transfusionais, ou pós relacionados

com procedimentos de urgência – envio de unidades sem provas de

compatibilidade).


49

Disponibilização para transfusão

Os técnicos de análises clínicas ou os médicos fazem:

Rotulagem de disponibilização.

Libertação e envio para o local de transfusão.

Administração / Confirmação Positiva da Transfusão

Os enfermeiros:

Verificam da congruência da informação entre unidades disponibilizadas,

pedido transfusional e identidade do doente.

Administram a transfusão.

Monitorizam a transfusão.

Notificam o serviço de disponibilização de reacções adversas.

Enviam para o serviço de disponibilização o registo do fim último do

componente / produto (administração, inutilização, devolução).

3.3 Descrição dos Grupos de Utilizadores e Seus Papéis

3.3.1 Órgãos de Gestão e Administração

Acesso a informação sistematizada para avaliação dos níveis de actividade em

qualquer das áreas.

3.3.2 Médicos

Actividades relacionadas com Triagem Clínica e Exame Objectivo de Dadores.

Nos Laboratórios (microbiologia e imuno‐hemoterapia) no estudo analítico, quer

da rotina de dadores (incluindo a notificação de dadores) quer de processos de

estudo retrospectivo de reacções adversas em receptores.

Na preparação de transfusões, na prescrição de transfusões e na avaliação da

adequação.

Na Administração / Confirmação Positiva da Transfusão na intervenção e

investigação de reacções adversas.


50

3.3.3 Técnicos de Análises Clínicas e S. P.

Actividades relacionadas com Laboratórios (microbiologia, imuno‐hemoterapia,

controlo da qualidade), separação de componentes, rotulagem, gestão de stocks,

distribuição e preparação de transfusões.

3.3.4 Enfermeiros

Actividades relacionadas com colheitas, administração e confirmação positiva da

transfusão.

3.3.5 Administrativos

Actividades relacionadas com Promoção da dádiva/ Planeamento de colheitas e

Recepção / inscrição de dadores

3.4 Riscos

Ao analisar as actividades desenvolvidas pelos serviços de sangue que envolvem a

utilização do sistema informático, foi possível identificar os seguintes riscos transversais a

todos os processos, que se encontram muitos deles interligados e que se manifestam em

cada área com diferentes ponderações:

A. Acesso de pessoas não autorizadas

B. Comprometimento da integridade dos dados

C. Libertação de produtos ou componentes não conformes

D. Perda de rastreabilidade (produto / processo)

E. Perda de eficiência ou diminuição da capacidade de resposta

F. Administração de componentes não adequados

3.5 Especificação de Requisitos do Utilizador

Como ponto de partida para a especificação de requisitos foram considerados os seguintes

requisitos principais de informação, de segurança e de infra‐estruturas.


51

Requisitos de informação

O sistema tem que garantir a coerência (consistência) dos dados

É necessário que estejam definidos identificadores únicos que relacionados entre si,

permitam de um modo consistente caracterizar cada evento (e.g. número de dador;

número de colheita; identificação de utilizador, caracterização de instituição, identificação

de doente).

Têm de existir mecanismos que permitam a verificação do registo de dados (tanto a nível

da sua unicidade, como de estrutura, como de adequação).

O sistema tem que assegurar a rastreabilidade de todos os processos

Todas as operações/transacções críticas têm de ser registadas, e/ou criados registos de

actividades electrónicos imutáveis, que permitam rapidamente estabelecer e caracterizar o

percurso entre um dador e o destino de um componente / produto (receptor, investigação,

indústria, inutilização, etc.).

Requisitos de segurança

O sistema tem de garantir a segurança dos acessos

É necessário que estejam definidos níveis de acesso de acordo com as actividades a

desenvolver de modo a garantir a confidencialidade dos dados.

É necessário que as áreas relacionadas com equipamentos críticos (servidores, routers,

etc.) tenham acesso restrito, e tenham condições ambientais controladas.

O sistema tem de garantir a integridade dos dados

É necessário ter disponíveis meios que permitam que não haja modificação ou eliminação

acidental ou propositada de dados.

Devem ser definidas políticas para a realização de cópias de segurança, de um modo

adequado ao volume da informação processada pela organização.

Deve ser conseguida a deslocalização das cópias de segurança com uma periodicidade

adequada.


52

Devem ser feitas verificações periódicas à capacidade de recuperação de dados a partir das

cópias de segurança.

Devem existir meios de garantir a realização de cópias de segurança, de um modo

adequado ao volume da informação processada pela organização.

Requisitos de infra‐estruturas

O sistema tem de garantir os meios físicos adequados às operações a desenvolver

Têm que ser disponibilizados um conjunto de recursos que permitam a gestão e operação

do sistema para os fins a que se destina, considerando os diferentes requisitos normativos

e as diferentes configurações das organizações.

Estes requisitos têm de ser definidos pela tendência da evolução das operações da

organização a curto, médio e longo prazo.

Devem ser respondidos os requisitos de segurança e informação acima referidos.

Adicionando a estes requisitos as necessidades funcionais inerentes ao desempenho das

actividades dos SS e SMT de acordo com as boas práticas e as exigências normativas (BCSH

1999; BCSH, Ashford et al. 2000; IPS 2002; ISBT, Bocker et al. 2003; BCSH, Chapman et al.

2004; IPS 2004; ISO/IEC 2005; ISBT, Bobos et al. 2006; BCSH 2007; PIC/S 2007; Portugal.

Ministério da Saúde 2007; AABB 2008; ASST 2008; European Commission 2008; Grupo de

Trabalho de Imuno‐hematologia 2008; Council of Europe. 2009; ISBT, Sampson et al. 2010),

foram especificados no total de 161 requisitos.

Sendo 88 considerados de prioridade máxima (P1), 63 estão classificados no segundo nível

de prioridade (P2) e 10 requisitos no terceiro (P3). Não se identificaram requisitos de

menor prioridade por estes corresponderem a necessidades mais específicas de cada

utilizador ou serviço e não implicarem em primeira análise o incumprimento dos

normativos tidos como referência.

Tendo em conta as várias actividades dos SS e SMT foi assumida a distribuição dos

requisitos aqui propostos por 15 processos para facilitar a sua compreensão e verificação.


53

Para melhor compreensão da codificação utilizada na sistematização dos requisitos deve

ser utilizada a legenda da tabela 3.

Tabela 3 ‐ Legenda de códigos utilizados

Código Legenda

SS1 Geral

SS2 Promoção da Dádiva / Planeamento de Colheitas

SS3 Recepção / Inscrição de Dadores

SS4 Triagem Clínica / Exame Objectivo de Dadores

SS5 Colheitas

SS6 Laboratórios (Microbiologia, Imuno‐hemoterapia e Controlo da Qualidade)

SS7 Separação de Componentes

SS8 Rotulagem / Gestão de Stocks / Distribuição

SMT9 Gestão de Stocks e requisição de componentes aos SS

SMT10 Registo e Gestão de pedidos

SMT11 Preparação / Atribuição de Transfusões

SMT12 Disponibilização para Transfusão

SMT13 Administração / Confirmação Positiva da Transfusão

SS‐SMT14 Apoio à Gestão

Admin15 Administração do Sistema

P1 Tem que ter (prioridade máxima)

P2 Deve ter (2º em prioridade)

P3 Pode ter (3º em prioridade)

P4 Não terá agora (prioridade mínima)


54

Tabela 4 ‐ Especificação dos requisitos do utilizador

Número do Processo

Ordem no Processo Especificação do Requisito do Utilizador Prioridade

SS1 1.1 Tem de estar operacional 24h/365dias. P1

SS1 1.2 Tem de garantir o registo de todas as operações (e da identidade dos operadores por elas responsáveis) que possam ter influência na qualidade dos componentes sanguíneos.

P1

SS1 1.3 Tem de assegurar a rastreabilidade de todos os processos realizados pelos serviços de sangue com: 1) Identificação do serviço de sangue; 2) Identificação do dador de sangue; 3) Identificação da unidade de sangue; 4) Identificação do componente sanguíneo individual; 5) Data da colheita (ano/mês/dia); 6) Instalações às quais são distribuídas; 7) Unidades de sangue ou componentes sanguíneos ou destruição subsequente, e de todos os processos realizados pelos estabelecimentos com: 1) Identificação do fornecedor do componente sanguíneo; 2) Identificação do componente sanguíneo disponibilizado; 3) Identificação do receptor transfundido; 4) Para unidades de sangue não transfundidas, confirmação da destruição subsequente; 5) Data da transfusão ou da destruição (ano/mês/dia); 6) Número do lote do componente, se relevante.

P1

SS1 1.3.1 Tem de garantir o estabelecimento claro de uma relação entre o dador e o sangue, os componentes sanguíneos e as amostras de sangue para análise.

P1

SS1 1.3.2 Tem de garantir o estabelecimento claro de uma relação entre cada colheita e o sistema de colheita utilizado.

P1

SS1 1.3.3 Tem de utilizar identificadores previamente definidos que relacionados entre si, permitam de um modo consistente caracterizar cada evento. Estes identificadores englobam: número de dador; número de colheita; tipo de dádiva; tipo de colheita; locais de colheita; identificação de utilizador, caracterização de instituição, identificação de doente; equipamentos; tipo de componentes; métodos de colheita; métodos de processamento; métodos de análise; reacções adversas; critérios de exclusão; critérios de suspensão (definitiva/temporária); serviços; hospitais; destino final (inclui instituição, transfundido, devolvido ou destruído)

P1

SS1 1.3.4 Deve ser possível parametrizar o nº de lote, designação e código de produto, data de validade, componentes relacionados, tipo de dádiva (sangue ou componente), das soluções aditivas, da embalagem primária (sacos) e equipamentos utilizados.

P2

SS1 1.3.5 Tem de registar e armazenar detalhes dos movimentos das unidades, incluindo transferência entre stocks reservados e não reservados, transferência de e para frigoríficos satélite, envios a enfermarias e serviços, transferências para outros hospitais e causas de inutilização.

P1

SS1 1.3.6 Tem de possuir meios que permitam a conservação dos dados necessários para assegurar a rastreabilidade integral pelo prazo mínimo de 30 anos.

P1

SS1 1.4 Tem que fazer a gestão do acesso dos utilizadores com base em perfis pré‐estabelecidos definidos de acordo com as suas funções.

P1

SS1 1.4.1 Deve estabelecer procedimentos de renovação de palavras‐chave. P2

SS1 1.4.2 Tem de existir uma hierarquia de permissão de acesso para introduzir, corrigir, ler, ou imprimir dados.

P1


55

Número do Processo


SS1 1.5 Tem de registar as operações de introdução, modificação ou eliminação de dados e de validação, devendo incluir no mínimo: identidade do operador, data e hora da operação, alterações associadas a grupos de sangue, pesquisas de anticorpos e fenotipagem, fusão de registos, qualquer tomada de conhecimento de alertas do sistema.

P1

SS1 1.6 Tem de disponibilizar meios que permitam que não haja modificação ou eliminação acidental ou propositada de dados.

P1

SS1 1.7 Tem de garantir a interoperabilidade com os equipamentos existentes.

P1

SS1 1.7.1 Deve utilizar preferencialmente protocolos estabelecidos como padrão ou na sua falta os que obtenham maior consenso dentro da área transfusional.

P2

SS1 1.8 Tem de disponibilizar um sistema de rotulagem do sangue colhido, dos componentes sanguíneos intermediários e acabados e das amostras que identifique sem margem para erro o tipo de conteúdo e observe os requisitos de rotulagem e rastreabilidade obrigatórios por lei.

P1

SS1 1.9 Deve possuir mecanismos que permitam a verificação do registo de dados (tanto a nível da sua unicidade, como de estrutura, como de adequação).

P2

SS1 1.10 Deve utilizar, sempre que possível, meios de leitura automática das identificações de forma a minimizar qualquer risco de erro de identificação.

P2

SS1 1.11 Deve utilizar caracteres de verificação em todas as introduções manuais e onde estiverem disponíveis. A validade da introdução deve ser confirmada.

P2

SS1 1.12 Tem de existir um processo de verificação da introdução manual de dados críticos, tais como resultados de testes laboratoriais.

P1

SS1 1.13 Tem de impossibilitar que uma unidade de sangue ou de componentes sanguíneos seja aprovada até que tenham sido observados todos os requisitos obrigatórios estabelecidos.

P1

SS1 1.14 Tem de exercer um controlo sobre os procedimentos de libertação e disponibilização de componentes.

P1

SS1 1.14.1 Tem que permitir a parametrização das condições de validação e libertação de componentes sanguíneos.

P1

SS1 1.14.2 Deve permitir validação automática dos componentes (quando todos os requisitos obrigatórios estiverem satisfeitos).

P2

SS1 1.14.3 Deve permitir demonstrar que um sangue ou componente sanguíneo foi formalmente aprovado para libertação (manual ou automaticamente) por uma pessoa autorizada.

P2

SS1 1.14.4 Tem de possuir mecanismos que permitam assegurar que o sangue e os componentes sanguíneos com resultados repetidamente positivos nos testes serológicos de rastreio das infecções víricas, de acordo com o normativo existente, não possam ser utilizados para fins terapêuticos.

P1

SS1 1.14.5 Tem de possuir mecanismos que permitam assegurar que o sangue e os componentes sanguíneos sem os estudos imunhematológicos adequados não possam ser utilizados para fins terapêuticos.

P1

SS1 1.14.6 Tem de possuir mecanismos que permitam assegurar que o sangue os componentes sanguíneos e os lotes de onde eles provêm, não possam ser utilizados para fins terapêuticos, sem que haja validação dos resultados de Controlo da Qualidade.

P1

SS1 1.14.7 Deve permitir procedimentos de libertação e de distribuição de sangue e componentes sanguíneos não normalizados, claramente documentados e autorizados por uma pessoa designada.

P2


56

Número do Processo


SS1 1.15 Tem de possuir protecções físicas para proteger de perigos naturais e ambientais, bem como de intrusões não autorizadas a informação, os sistemas de tecnologia de informação, e os edifícios e equipamento relacionados.

P1

SS1 1.16 Tem de ter definidas politicas e procedimentos para a realização de cópias de segurança para prevenir perda de registos devido a falhas esperadas ou inesperadas.

P1

SS1 1.17 Deve permitir o registo e documentação de reclamações, eventos adversos ou reacções relacionados com os componentes, bem como dos factores causadores do defeito.

P2

SS1 1.18 Deve ter avisos de segurança para procedimentos normalizados com impacte na segurança ou na coerência dos registos.

P2

SS1 1.19 Tem que garantir que nas transferências com outras bases de dados os registos ou dados incoerentes não são actualizados automaticamente.

P1

SS1 1.20 Tem que permitir o acesso ao registo do histórico de cada dador em função da área de actividade que a solicita e o perfil do utilizador.

P1

SS1 1.21 Deve ter meios para bloquear quaisquer dádivas futuras de um dador que tenha sido previamente eliminado.

P2

SS1 1.22 Tem que disponibilizar local para atribuição do número de colheita a realizar, assegurando a unicidade da ligação Dador ‐ Nº de colheita.

P1

SS1 1.23 Tem de existir um mecanismo de verificação do número de colheita atribuído.

P1

SS2 2.1 Pode permitir fazer o planeamento e a gestão dos locais de colheita.

P3

SS2 2.2 Pode permitir fazer a gestão de dadores por locais de colheita recorrendo ao conjunto de dados administrativos que caracterizam o dador.

P3

SS2 2.3 Pode permitir a utilização de meios que facilitem a comunicação com o dador (cartas, e‐mails, SMS, etc.).

P3

SS2 2.4 Deve permitir o agendamento sessões de colheita. P2

SS3 3.1 Tem de permitir o registo de dados administrativos de cada dador ou candidato a dador de modo a obter uma identificação individual e inequívoca.

P1

SS3 3.2 Tem de verificar e alertar para a existência de dadores com dados administrativos idênticos.

P1

SS3 3.3 Tem de permitir a consulta dos registos de dadores com dados administrativos idênticos.

P1

SS3 3.4 Tem de permitir o registo de cada visita do dador ou candidato a dador.

P1

SS3 3.5 Tem de permitir a identificação do motivo de inscrição de dadores (tipo de dádiva, análises, etc.).

P1

SS4 4.1 Deve permitir a parametrização dos critérios de suspensão temporária ou definitiva de dadores de dádivas homólogas e autólogas.

P2

SS4 4.2 Deve disponibilizar a consulta dos dadores ainda sem observação clínica.

P2

SS4 4.3 Tem de ser possível registar os resultados dos procedimentos de avaliação clínica.

P1

SS4 4.4 Deve permitir visualizar o registo do valor de proteínas determinado pelo menos anualmente no sangue dos dadores de plasma por aférese.

P2

SS4 4.5 Deve permitir visualizar o registo do valor de plaquetas determinado no sangue dos dadores de plaquetas por aférese.

P2


57

Número do Processo


SS4 4.6 Tem de ser possível registar os resultados das análises efectuadas ao dador no contexto da triagem clínica.

P1

SS4 4.6.1 Deve permitir o registo do valor de hemoglobina determinado no sangue dos dadores de sangue total e de componentes celulares.

P2

SS4 4.7 Tem que alertar sobre a inscrição de um dador para colheita se, desde a última dádiva, ainda não tiver passado o intervalo de tempo determinado para cada tipo de dádiva.

P1

SS4 4.8 Tem de impedir a aprovação para colheita de um dador previamente eliminado.

P1

SS4 4.9 Tem de permitir o registo dos motivos de suspensão temporária ou definitiva de dadores homólogos ou autólogos.

P1

SS4 4.10 Tem de permitir o registo do prazo de suspensão temporária de dadores homólogos.

P1

SS5 5.1 Tem que permitir a parametrização das reacções adversas decorrentes da dádiva de sangue ou células.

P1

SS5 5.2 Tem de possuir meios que obriguem à confirmação da identificação do dador imediatamente antes da venopunção.

P1

SS5 5.3 Tem de possuir meios que obriguem à confirmação da identificação da dádiva e das amostras para análise após a venopunção.

P1

SS5 5.4 Deve permitir o registo e controlo do tempo de colheita das dádivas.

P2

SS5 5.5 Tem que permitir registar reacções adversas e/ou lesões decorrentes da dádiva de sangue ou componentes e observações.

P1

SS5 5.6 Tem que permitir registar as características dos dispositivos médicos utilizados na colheita.

P1

SS5 5.7 Deve permitir o registo do tipo de dádiva (sangue ou componente), das soluções aditivas, da embalagem primária (sacos) e equipamentos utilizados.

P2

SS6 6.1 Tem de permitir a parametrização das análises tendo em atenção factores como: área laboratorial; normativo (obrigatório ou opcional); história clínica; tipos de valores admissíveis; tipo de resultados (qualitativo, quantitativo); unidades de leitura; intervalos de referência.

P1

SS6 6.2 Tem permitir fazer a gestão dos pedidos de análises, diferenciando claramente entre análise realizadas e por realizar.

P1

SS6 6.3 Tem que permitir fazer o registo de todos os resultados analíticos obtidos no laboratório de imunohematologia para as análises obrigatórias.

P1

SS6 6.3.1 Tem de permitir o registo para todos os dadores dos grupos sanguíneos AB0 e RhD.

P1

SS6 6.3.2 Deve permitir o registo de resultados de dois testes independentes AB0 RhD, para dadores novos.

P2

SS6 6.3.3 Deve permitir o registo de resultados da pesquisa de anticorpos eritrocitários irregulares clinicamente significativos, para dadores com história de transfusões ou gravidez desde a última dádiva.

P2

SS6 6.3.4 Deve comparar o grupo AB0 e RhD da última dádiva com o registado no histórico do dador e se forem detectadas discrepâncias os componentes sanguíneos devem ficar bloqueados até a discrepância ter sido resolvida inequivocamente.

P2

SS6 6.4 Tem que permitir fazer o registo de todos os resultados analíticos obtidos no laboratório de microbiologia para as análises obrigatórias.

P1


58

Número do Processo


SS6 6.4.1 Tem de possuir mecanismos que permitam assegurar que os dadores com resultados repetidamente positivos nos testes de rastreio das infecções víricas tenham um tratamento diferenciado obrigando à intervenção directa de utilizador habilitado.

P1

SS6 6.5 Pode ter mecanismos para a apoiar no processo de notificação de dador com resultados anormais, nomeadamente pela emissão de relatórios ou cartas para comunicação ao dador de anomalias importantes dos resultados dos procedimentos de avaliação clínica ou das análises efectuadas.

P3

SS6 6.6 Deve permitir fazer o registo de todos os resultados analíticos obtidos no laboratório de CQ para as análises obrigatórias.

P2

SS6 6.7 Tem que permitir realizar a validação automática de resultados de acordo com critérios pré‐estabelecidos (negatividade do rastreio, comparação com histórico, etc.).

P1

SS6 6.8 Tem de permitir o registo do valor de proteínas determinado no sangue dos dadores de plasma por aférese, pelo menos anualmente.

P1

SS6 6.9 Tem de permitir o registo do valor de plaquetas determinado no sangue dos dadores de plaquetas por aférese.

P1

SS6 6.10 Deve ser possível evidenciar a resolução de resultados discrepantes.

P2

SS7 7.1 Tem permitir o registo do processamento a que cada colheita é submetida.

P1

SS7 7.2 Tem permitir fazer a gestão das unidades de sangue que aguardam processamento, diferenciando claramente entre processamentos realizados e por realizar.

P1

SS7 7.3 Pode permitir o registo das condições de transporte (temperatura).

P3

SS7 7.4 Deve impedir que as dádivas que excederam o tempo máximo de colheita sejam processadas, ou que dêem origem a determinados componentes.

P2

SS7 7.5 Deve prever o registo de operações adicionais sobre os componentes (irradiação ‐ dose de radiação, lavagem, criopreservação ‐ metodologias de conservação, etc).

P2

SS8 8.1 Tem que permitir a impressão de rótulos normalizados (ISBT128) para identificação de cada componente sanguíneo. "O rótulo de cada um dos componentes deve conter as seguintes informações: Designação oficial do componente; Volume, peso ou número de células do componente (consoante o caso); Identificação única, numérica ou alfanumérica, da dádiva; Nome do serviço de sangue de produção; Grupo ABO (não necessária para o plasma destinado exclusivamente a fraccionamento); Grupo Rh D, especificando «Rh D positivo» ou «Rh D negativo» (não necessária para o plasma destinado exclusivamente a fraccionamento); Data ou prazo de validade (consoante o caso); Temperatura de armazenamento; Nome, composição e volume do anticoagulante e ou solução aditiva (caso exista)."

P1

SS8 8.1.1 Deve ser incluída no rótulo informação sobre leucoredução dos Concentrados Eritrocitários.

P2

SS8 8.1.2 Deve ser incluída no rótulo a identificação do dador e a advertência "Só para transfusão autóloga", no caso de sangue e componentes autólogos.

P2

SS8 8.1.3 Deve ser incluída no rótulo informação sobre processamentos adicionais a que os componentes tenham sido sujeitos.

P2

SS8 8.2 Tem de permitir a rotulagem dos componentes de dádivas de dadores novos só após a realização de dois testes independentes AB0 RhD.

P1


59

Número do Processo


SS8 8.3 Tem de impedir a rotulagem dos componentes eritrocitários de dádivas de dadores sujeitas a pesquisa de anticorpos eritrocitários irregulares, cujo resultado seja positivo.

P1

SS8 8.4 Tem de permitir identificar todos os componentes sanguíneos resultantes de dádivas com resultados repetidamente positivos para testes de rastreio, características não conformes com os parâmetros de qualidade do produto ou dos processos, expiração da validade, estudos imunohematológicos inconclusivos de modo a que tenham um tratamento diferenciado, com vista à sua eliminação ou uso não terapêutico.

P1

SS8 8.5 Tem de permitir o registo do envio de componentes sanguíneos a outras instituições.

P1

SS8 8.6 Deve registar a identificação da pessoa que realizou a distribuição e do cliente que recebeu os componentes.

P2

SS8 8.7 Tem de gerar documentação comprovativa do envio de componentes sanguíneos a outras instituições.

P1

SS8 8.8 Tem que permitir a monitorização do inventário de componentes disponíveis e indisponíveis.

P1

SS8 8.9 Deve permitir a recepção de pedidos de componentes sanguíneos de outras instituições.

P2

SS8 8.10 Deve permitir a reintegração do sangue e dos componentes sanguíneos no inventário com vista à sua distribuição subsequente se estiverem preenchidos todos os requisitos e procedimentos de qualidade estabelecidos pelo serviço de sangue para assegurar a integridade dos componentes sanguíneos.

P2

SS8 8.10.1 Deve permitir registar as condições de armazenamento a que os componentes estiveram sujeitos e a inspecção realizada antes da redistribuição no caso da aceitação da devolução de componentes para subsequente distribuição.

P2

SMT9 9.1 Tem de permitir o registo adequado no inventário das unidades provenientes do exterior.

P1

SMT9 9.1.1 Deve permitir a introdução de stock no sistema para todos os componentes por meio de transferência electrónica ou leitura electrónica (leitor de código de barras, RFID, etc.). As seguintes informações devem ser capturadas, para cada unidade individual: ‐ identificador exclusivo de dádiva (não deve ocorrer nova rotulagem de unidades); ‐ grupo ABO e RhD ; ‐ código do componente; ‐ Prazo de validade.

P2

SMT9 9.2 Tem de permitir o registo de todas as manipulações de componentes após a recepção.

P1

SMT9 9.3 Deve permitir o registo de características adicionais dos componentes.

P2

SMT9 9.4 Deve permitir a visualização dos detalhes do inventário: stock reservado e não reservado apresentado por tipo de unidade, grupo e características específicas. ‐Incluir detalhes com o prazo de validade de todas as unidades e dar uma lista ordenada por número dias de validade restantes para qualquer tipo de unidade e grupo AB0 e RhD; ‐Dar detalhes do stock recebido, stock usado e stock eliminado com diferentes intervalos de tempo.

P2

SMT9 9.5 Tem de permitir a “reintegração do sangue e dos componentes sanguíneos no inventário com vista à sua disponibilização subsequente” (…) se estiverem preenchidos os requisitos e procedimentos de qualidade estabelecidos pelo serviço de sangue para assegurar a integridade dos componentes sanguíneos.”

P1

SMT9 9.6 Pode ser capaz de gerar um pedido de reposição de stock que possa ser transmitido ao SS por transferência electrónica de dados.

P3


60

Número do Processo


SMT10 10.1 Tem de gerar um código único para identificar cada pedido. P1

SMT10 10.2 Tem de permitir o registo dos seguintes dados do pedido: Nome; Apelido; Género; Data de nascimento; nº do hospital; data e hora do pedido; Serviço; tipo de pedido (grupo, reserva, compatibilidade); Tipo de amostra enviada; razão do pedido; ‐ ID médico; ‐ Se forem pedidos componentes sanguíneos: ‐ tipo de componente, incluindo requisitos especiais; ‐ nº de unidades necessárias; ‐ data e hora a que o componente será necessário. ‐ Informação adicional desejável: grupo sanguíneo; transfusões anteriores; história obstétrica. DHRN. Presença de anticorpos conhecidos.

P1

SMT10 10.3 Deve permitir a realização de pedidos de componentes sanguíneos directamente no sistema do SMT ou num formato electrónico compatível com o mesmo.

P2

SMT10 10.4 Tem de existir um interface electrónico para o registo de pedidos manuais de componentes sanguíneos num formato semelhante.

P1

SMT10 10.5 Tem de verificar e alertar para a existência de doentes com dados administrativos semelhantes.

P1

SMT11 11.1 Deve permitir a identificação das amostras no laboratório por um número de amostra único, associado ao registo de cada pedido para o paciente, de preferência com código de barras.

P2

SMT11 11.2 Pode permitir um registo de reagentes, contendo o número do lote, fornecedor e data de validade.

P3

SMT11 11.3 Devem ser guardadas as seguintes informações para cada amostra na grupagem ABO e Rh: ‐ Data e hora de realização do teste; ‐ resultados do teste; ‐ identidade da(s) pessoa(s) que introduz / valida os resultados; ‐ técnica utilizada para realização do teste.

P2

SMT11 11.3.1 Pode guardar a imagem quando são utilizados leitores automáticos para interpretar padrões de reacção.

P3

SMT11 11.4 Têm de estar definidos os critérios de compatibilidade por tipo de componentes e grupo.

P1

SMT11 11.4.1 Tem de impedir a utilização de componentes incompatíveis. P1

SMT11 11.4.2 Tem de permitir a atribuição de unidades ABO‐compatíveis, mas serologicamente incompatíveis desde que realizada por utilizador com nível adequado, em circunstâncias excepcionais previamente definidas.

P1

SMT11 11.4.3 Deve impedir, nos testes de compatibilidade, a selecção de unidades de eritrócitos ABO‐incompatíveis e deve exigir a autorização de incompatibilidade RhD.

P2

SMT11 11.4.4 Tem de permitir a emissão de unidades de «emergência», O RhD negativo ou O RhD positivo, sem um grupo sanguíneo conhecido do paciente.

P1

SMT11 11.4.5 Tem de permitir a emissão de unidades grupo compatíveis, com base num grupo sanguíneo de emergência apenas, antes da introdução da pesquisa de anticorpos ou dos resultados de compatibilidade.

P1

SMT11 11.4.6 Deve permitir a introdução retrospectiva de novos testes, por exemplo, resultados de compatibilidade, com registo da hora de tais entradas.

P2

SMT11 11.4.7 Deve exigir, no caso de discrepância entre as provas directa e reversa para determinação do grupo AB0, a confirmação da interpretação dos resultados após inspecção visual com registo manual dos resultados da repetição do teste da amostra.

P2

SMT11 11.5 Deve alertar o utilizador para requisitos especiais de transfusão.

P2


61

Número do Processo


SMT11 11.6 Pode ser feita a introdução manual por meio de padrões de reacção, ou grupo sanguíneo interpretado, usando o teclado ou menu de código de barras.

P3

SMT11 11.6.1 Deve solicitar que os resultados manuais sejam verificados por uma segunda entrada cega, que sempre que possível deve ser realizado por um segundo operador.

P2

SMT11 11.7 Deve, nos testes de compatibilidade, permitir definir um período de reserva para as unidades compatibilizadas e produzir um retorno à lista de stock. A data de reserva não deve exceder o prazo de validade do componente.

P2

SMT11 11.7.1 Tem, nos testes de compatibilidade, de permitir que os resultados sejam imputados a cada unidade compatibilizada (seja ela compatível ou não). Têm de ser registadas as seguintes informações: Data e hora da realização do teste; identidade da(s) pessoa(s) que introduziu e/ou validou os resultados.

P1

SMT11 11.8 Deve haver um mecanismo para edição e correcção dos resultados por pessoa autorizada com registo da identificação e operações realizadas.

P2

SMT11 11.9 Tem de permitir a substituição do grupo sanguíneo de um doente, diferente do registado no histórico, por pessoa autorizada com registo da identificação e operações realizadas. Isto deve ser acompanhado por mensagens de aviso adequadas.

P1

SMT11 11.10 Tem de ser guardado o resultado, a data de realização e a metodologia utilizada na pesquisa e identificação de anticorpos.

P1

SMT11 11.10.1 Tem de haver a possibilidade de inserir mais de um anticorpo na pesquisa e identificação de anticorpos.

P1

SMT11 11.10.2 Deve haver um mecanismo para permitir comentários relativos à pesquisa e identificação de anticorpos, por exemplo, ‐ sem significado clínico; ‐ com significado clínico; ‐ Fenótipo dos eritrócitos do paciente, etc.

P2

SMT11 11.10.3 Tem de permitir o registo dos resultados da titulação e / ou quantificação de anticorpos.

P1

SMT11 11.11 Tem de permitir o registo dos resultados do teste de antiglobulina directa (TAD).

P1

SMT11 11.11.1 Deve permitir adicionar comentários ao registo dos resultados do teste de antiglobulina directa (TAD).

P2

SMT11 11.11.2 Deve ser possível inserir os resultados obtidos com reagentes AHG monoespecíficos para o teste de antiglobulina directa (TAD).

P2

SMT11 11.12 Deve ser possível armazenar os resultados dos testes serológicos realizados em caso de suspeita de reacção transfusional.

P2

SMT11 11.13 Deve ser possível, no caso de testes relacionados com a Gravidez, associar o seguinte com o registo do paciente: ‐ Número de semanas de gestação no momento do teste; ‐ Detalhes da hemorragia fetomaterna em ml; ‐ Dose e número do lote de imunoglobulina anti‐D administrada (possibilidade para múltiplas entradas); ‐ Resultados do teste da criança.

P2

SMT11 11.13.1 Deve ser possível, no caso de testes relacionados com a Gravidez, solicitar e inserir os resultados do fenótipo do parceiro.

P2

SMT11 11.13.2 Deve ser possível, no caso de testes relacionados com a Gravidez, inserir comentários codificados e de texto livre contra os resultados dos pacientes.

P2

SMT11 11.14 Tem de ser possível a atribuição de unidades individuais ou múltiplas a doentes e os detalhes gravados e armazenados devem incluir: ‐ identificador do doente; ‐ Data de administração; ‐ Nº de lote; ‐ n º de unidades.

P1


62

Número do Processo


SMT11 11.14.1 Deve produzir um relatório de compatibilidade e os rótulos após a validação dos resultados dos testes de compatibilidade.

P2

SMT12 12.1 Tem de permitir o registo adequado da disponibilização de componentes: ‐identidade da pessoa que envia as unidades; ‐identidade da pessoa que recebe as unidades; ‐ destino da unidade; ‐ data e hora do envio.

P1

SMT12 12.2 Pode permitir que os utilizadores nas enfermarias tenham acesso remotamente à disponibilidade de stock reservado para doentes.

P3

SMT13 13.1 Deve permitir registar a administração de cada componente (data, hora e utilizador) e a monitorização pré e pós‐transfusional.

P2

SMT13 13.2 Deve possibilitar registar as reacções adversas observadas durante ou após a transfusão, incluindo caracterização, terapêutica e comentários.

P2

SMT13 13.3 Deve permitir verificar se cada unidade disponibilizada foi transfundida ao receptor previsto.

P2

SS‐SMT14 14.1 Tem de existir um mecanismo para identificar múltiplos registos de um mesmo dador ou doente baseados em critérios relacionados com os identificadores.

P1

SS‐SMT14 14.1.1 Deve existir um mecanismo para ligar ou “fundir” múltiplos registos de um mesmo dador ou doente suportado por critérios definidos localmente.

P2

SS‐SMT14 14.1.2 Deve ser assegurada a rastreabilidade conservando todos os detalhes dos dadores/doentes dos registos anteriores à fusão / ligação, a data/hora da fusão/ligação, e o nome da pessoa que autorizou a fusão/ligação, independentemente do mecanismo usado.

P2

SS‐SMT14 14.2 Tem de permitir obter os dados necessários à realização do relatório anual para o IPS.

P1

SS‐SMT14 14.3 Tem de permitir obter os dados necessários à realização do relatório anual para a ASST.

P1

SS‐SMT14 14.4 Deve ser capaz de realizar consultas quer estejam integradas no sistema ou tornando a base de dados disponível para acesso externo. É importante que tal consulta ad hoc tenha acesso a todos os itens de dados. A segurança de acessos deve continuar a ser aplicada. Se não for possível disponibilizar sistemas de consulta sofisticados, o sistema deve fornecer um conjunto mínimo de informação de gestão (estatísticas dos processos de colheita, processamento e de utilização) e médico‐legal.

P2

SS‐SMT14 14.5 Deve realizar o registo do inventário de componentes disponíveis e indisponíveis por período.

P2

SS‐SMT14 14.6 Tem de permitir o registo de comunicações do dador após a dádiva (reacções, complicações, infecções, etc.).

P1

Admin15 15.1 Deve exercer controlo estrito sobre as propostas e mudanças/alterações nas bases de dados.

P2

Admin15 15.2 Tem de ser realizado treino adequado do pessoal. Programa de treino documentado que cubra todos os POP’s, que cumpra os requisitos documentados da instituição e a um nível de exigência de competência proporcional à importância das tarefas de cada elemento.

P1

Admin15 15.3 Tem de prever e ter implementados meios que visem maximizar a segurança de todas as comunicações externas de dados.

P1

Admin15 15.4 Tem de respeitar estritamente as condições estabelecidas na Lei de Protecção de Dados Pessoais, aprovada pela Lei nº. 67/98, de 26 de Outubro ou por outra que a revogue.

P1


63

4. Proposta de protocolo de validação

4.1 Objectivo e Âmbito

Validar retrospectivamente o sistema informático de um serviço de sangue de acordo com

os requisitos do utilizador para o cumprimento dos requisitos legais do Decreto‐Lei n.º

267/2007 e das boas práticas desejáveis na actividade destes serviços.

4.2 Instruções e Metodologia de teste

Nome e código do processo: Administração do sistema informático (Admin15)

Requisitos a testar:

1.1 Tem de estar operacional em todos os períodos de funcionamento do serviço ou de funcionamento de sistemas em este esteja integrado.

Instruções de teste

Pesquisar no sistema se existem registos de diferentes actividades, realizados em diferentes períodos do dia e em dias diferentes e em qualquer período de funcionamento do serviço da instituição ou de sistemas em este esteja integrado. Imprimir ecrã com indicação de data e hora da realização de cada registo.

Resultados esperados

São encontrados registos realizados em diferentes períodos do dia e em dias diferentes e em qualquer período de funcionamento dos serviços da instituição ou de sistemas em este esteja integrado.

Critérios de aceitação

É possível evidenciar que o SI permite o registo das actividades da instituição em todos os períodos de funcionamento dos seus serviços.

Resultados obtidos

Conclusão

1.2 Tem de garantir o registo de todas as operações (e da identidade dos operadores por elas responsáveis) que possam ter influência na qualidade dos componentes sanguíneos.


Verificar nos registos de actividades se ficam registados a identidade dos operadores, a operação realizada e a data e hora tendo em particular atenção a inscrição de dadores, os dados da triagem clínica, os dados de colheita, a validação de componentes, o registo e validação dos dados laboratoriais, realização da rotulagem e as actividades de distribuição.


São registadas pelo SI todas as operações (e a identidade dos operadores por elas responsáveis) que possam ter influência na qualidade dos componentes sanguíneos.


Foi possível rastrear no SI quem realizou todas as operações com influência na qualidade dos componentes sanguíneos.

Resultados obtidos

Conclusão


64

1.3.6 Tem de possuir meios que permitam a conservação dos dados necessários para assegurar a rastreabilidade integral pelo prazo mínimo de 30 anos.


Verificar quais os meios e capacidade de armazenamento de informação existentes e se existirem meios de armazenamento amovíveis verificar da actualidade da visualização. Verificar se permite aceder aos dados desde 1985, ou desde 2007, ou desde o inicio de funcionamento do serviço (se posterior a 2007), ou desde o inicio de funcionamento do SI (se posterior a 2007).


Existem meios e capacidade de armazenamento de informação suficiente a médio prazo (2 anos) para o volume de dados produzido no ano actual. Existe possibilidade de incrementar continuamente a capacidade de armazenamento em função das necessidades, sem perda de operacionalidade. É possível aceder aos dados desde o início do funcionamento do SI.


Ter capacidade de armazenamento a médio prazo (2 anos) para o volume de dados produzido no ano actual. Permite aceder aos dados desde 1985, ou desde 2007, ou desde o inicio de funcionamento do serviço (se posterior a 2007), ou desde o inicio de funcionamento do SI (se posterior a 2007).

Resultados obtidos

Conclusão

1.4 Tem que fazer a gestão do acesso dos utilizadores com base em perfis pré‐estabelecidos definidos de acordo com as suas funções.

1.4.2 Tem de existir uma hierarquia de permissão de acesso para introduzir, corrigir, ler, ou imprimir dados.

1.6 Tem de disponibilizar meios que permitam que não haja modificação ou eliminação acidental ou propositada de dados.


1. Solicitar ao administrador do sistema 3 perfis de utilizadores com funções e níveis de permissão diferentes (descriminando as operações permitidas e em que áreas, e datas de atribuição das palavras‐chave). Imprimir ecrãs desta amostragem.

2. Solicitar a esses 3 utilizadores que acedam e tentem realizar operações para as quais estão habilitados e outras para que não estão habilitados. Imprimir ecrãs com caixas de diálogo e mensagens.

3. Solicitar a esses 3 utilizadores a realização de modificação e eliminação de dados. Imprimir ecrãs com caixas de diálogo e mensagens.


1. As configurações dos perfis devem ser distintas e deve existir evidência de renovação periódica das palavras‐chave.

2. Os utilizadores apenas devem conseguir aceder e realizar operações permitidas pelo seu perfil.

3. Deve solicitar confirmação das modificações e eliminações antes da sua gravação.


1. Existem configurações dos perfis distintas 2. Os utilizadores apenas devem conseguir aceder e realizar operações

permitidas pelo seu perfil. 3. É solicitada confirmação das modificações e eliminações antes da sua

gravação.

Resultados obtidos


65

Conclusão

1.15 Tem de possuir protecções físicas para proteger de perigos naturais e ambientais, bem como de intrusões não autorizadas, a informação, os sistemas de tecnologia de informação, e os edifícios e equipamento relacionados.


Verificar as condições das instalações e da rede eléctrica, a existência de controlo do acesso de pessoas ao edifício e dentro deste aos terminais do sistema. Se possível documentar com anexos.


As instalações e a rede eléctrica têm condições adequadas, existe controlo do acesso de pessoas ao edifício e dentro deste aos terminais do sistema.


É evidenciado que as condições das instalações e da rede eléctrica não são precárias e que existe controlo de acessos.

Resultados obtidos

Conclusão

1.16

Tem de ter definidas políticas e procedimentos para a realização de cópias de segurança para prevenir perda de registos devido a falhas esperadas ou inesperadas.


1. Verificar a existência de POP onde sejam descritas as condições de realização de cópias de segurança, sua periodicidade, responsabilidades e manutenção.

2. Verificar a existência física das cópias de segurança e dos registos da sua realização. Fazer cópia ou impressão de uma página dos registos.


1. Existem POP para realização de cópias de segurança. 2. Existem cópias de segurança realizadas com a periodicidade definida, mantidas em condições que não comprometam a sua integridade e deslocalizadas relativamente aos dados originais.


Existem cópias de segurança realizadas com a periodicidade definida, mantidas em condições que não comprometam a sua integridade e registo da realização das mesmas. Caso não existam POP para realização de cópias de segurança, recomendar a sua implementação.

Resultados obtidos

Conclusão

1.19

Tem que garantir que nas transferências com outras bases de dados os registos ou dados incoerentes não são actualizados automaticamente.


Transferir resultados/dados laboratoriais para dadores/doentes/amostras não registadas na base de dados. Imprimir ecrãs com caixas de diálogo e mensagens.


Permite visualizar os dados a transferir com sinalização, mensagem (ns) de erro, de alerta, ou de pedido de confirmação para as incoerências criadas.


É evidenciada a não actualização automática, obrigando à verificação e confirmação pelo utilizador.

Resultados obtidos

Conclusão


66

15.2 Tem de ser realizado treino adequado do pessoal. Programa de treino documentado que cubra todos os POP’s, que cumpra os requisitos documentados da instituição e a um nível de exigência de competência proporcional à importância das tarefas de cada elemento.


Verificar se: ‐Existe um plano de formação? ‐Existe calendarização de formações iniciais e de actualização? ‐Existem registos das formações (quem recebeu formação, quem foi o formador, actividades e materiais utilizados)? ‐É realizada a avaliação de competências com níveis de exigência proporcionais à importância das tarefas de cada elemento? Anexar cópia de uma página de cada registo.


Existe um plano de formação, calendarização de formações iniciais e de actualização, registos das formações e avaliação de competências.


Verificação integral dos resultados esperados.

Resultados obtidos

Conclusão

15.3 Tem de prever e ter implementados meios que visem maximizar a segurança de todas as comunicações externas de dados.


Verificar se: ‐Existe uma política para a comunicação de dados? ‐Existem procedimentos específicos para a transmissão dos diferentes tipos de dados (públicos, confidenciais, etc.) de acordo com o seu nível de confidencialidade (por ex., encriptação utilizando canais seguros de comunicação)? ‐Existem firewalls físicos de protecção da rede local?


Existe uma política para a comunicação de dados, procedimentos específicos para a transmissão dos diferentes tipos de dados de acordo com o seu nível de confidencialidade (por ex., encriptação utilizando canais seguros de comunicação) e firewalls físicos de protecção da rede local.



Resultados obtidos

Conclusão


67

15.4 Tem de respeitar estritamente as condições estabelecidas na Lei de Protecção de Dados Pessoais, aprovada pela Lei n.º 67/98, de 26 de Outubro ou por outra que a revogue.


Verificar se estão implementadas medidas para garantir a confidencialidade dos dados pessoais dos dadores e o acesso dos dadores aos seus dados pessoais com possibilidade de correcção. Verificar se está previsto o registo do acesso dos dadores aos seus dados pessoais e dos pedidos e realização de alterações.


Existem procedimentos que visam garantir a confidencialidade dos dados pessoais dos dadores e o acesso dos dadores aos seus dados pessoais com possibilidade de correcção. Está previsto o registo do acesso dos dadores aos seus dados pessoais e dos pedidos e realização de alterações.



Resultados obtidos

Conclusão

5.1 Tem que permitir a parametrização das reacções adversas decorrentes da dádiva de sangue ou células.

6.1 Tem de permitir a parametrização das análises tendo em atenção factores como: área laboratorial; normativo (obrigatório ou opcional); história clínica; tipos de valores admissíveis; tipo de resultados (qualitativo, quantitativo); unidades de leitura; intervalos de referência.


1. Solicitar a um utilizador de nível adequado de acesso, a parametrização: ‐ De uma nova reacção adversa decorrente da dádiva de sangue ou células. ‐De uma nova análise tendo em atenção factores como: área laboratorial;

normativo (obrigatório ou opcional); história clínica; tipos de valores admissíveis; tipo de resultados (qualitativo, quantitativo); unidades de leitura; intervalos de referência.

2. Verificar se as novas parametrizações criadas ficam disponíveis como opções para os utilizadores realizarem registos.

3. Solicitar ao administrador do sistema a eliminação da reacção adversa e análise criadas como teste do funcionamento da sua parametrização.


É possível fazer as novas parametrizações. As novas parametrizações criadas ficam disponíveis como opções para os utilizadores realizarem registos.


É evidenciada a possibilidade de fazer as parametrizações indicadas e a funcionalidade das mesmas para realização de registos.

Resultados obtidos

Conclusão


68

Nome e código do processo: Inscrição de dadores (SS3)


3.1 Tem de permitir o registo de dados administrativos de cada dador ou candidato a dador de modo a obter uma identificação individual e inequívoca.

3.2 Tem de verificar e alertar para a existência de dadores com dados administrativos idênticos.

3.3 Tem de permitir a consulta dos registos de dadores com dados administrativos idênticos.

3.4 Tem de permitir o registo de cada visita do dador ou candidato a dador.

3.5 Tem de permitir a identificação do motivo de inscrição de dadores (tipo de dádiva, análises, etc.).


Solicitar quais os dados de preenchimento obrigatório para identificação de dadores. Solicitar a um profissional com funções de registo de dadores que faça o login no SI. Imprimir os ecrãs de todas as operações seguintes. 1. Solicitar ao profissional com funções de registo de dadores que simule (sem

gravar o registo) a inscrição de um dador com dados administrativos idênticos a um existente.

2. Verificar se o SI informa sobre essa repetição. 3. Verificar como o SI discrimina os repetidos. 4. Verificar se existe registo da (s) última (s) inscrição (ões) do dador. 5. Verificar no histórico das inscrições em que tipo de dádivas o dador se

inscreveu.


1. Verificar se dados de identificação de preenchimento obrigatório são suficientes para distinguir entre dadores com identificações idênticas.

2. Durante a inscrição de um dador verificar se permite a sua inscrição por outros motivos além da dádiva.


É possível evidenciar que os dados de identificação de preenchimento obrigatório são suficientes para distinguir entre dadores com identificações idênticas e que é possível a sua inscrição por outros motivos além da dádiva.

Resultados obtidos

Conclusão


69

Nome e código do processo: Realização da triagem clínica (SS4)


4.3 Tem de ser possível registar os resultados dos procedimentos de avaliação clínica.

4.6 Tem de ser possível registar os resultados das análises efectuadas ao dador no contexto da triagem clínica.

4.7 Tem que alertar sobre a inscrição de um dador para colheita se, desde a última dádiva, ainda não tiver passado o intervalo de tempo determinado para cada tipo de dádiva.

4.8 Tem de impedir a aprovação para colheita de um dador previamente eliminado.

4.9 Tem de permitir o registo dos motivos de suspensão temporária ou definitiva de dadores homólogos ou autólogos.

4.10 Tem de permitir o registo do prazo de suspensão temporária de dadores homólogos.

1.22 Se aplicável

Tem que disponibilizar local para atribuição do número de colheita a realizar, assegurando a unicidade da ligação Dador ‐ Nº de colheita.

1.23 Se aplicável

Tem de existir um mecanismo de verificação do número de colheita atribuído.


Solicitar quais os dados de preenchimento obrigatório para a triagem clínica de dadores. Solicitar ao profissional médico da triagem que aceda à ficha de registo electrónico dos resultados dos procedimentos de avaliação clínica e que realize os procedimentos a seguir referidos. Imprimir os ecrãs de todas as operações. 1. Verificar se permite registar todos os dados de preenchimento obrigatório

para a triagem clínica de dadores e os resultados das análises efectuadas ao dador no contexto da triagem clínica.

2. Inscrever um dador para colheita dos vários tipos de dádivas, para os quais ainda não tenha passado o intervalo de tempo mínimo determinado para cada tipo de dádiva.

3. Aprovar e inscrever para colheita um dador previamente eliminado. 4. Registar os motivos de suspensão temporária e definitiva de dadores

homólogos ou autólogos e do prazo de suspensão temporária de dadores homólogos.

Se aplicável neste processo: 5. Atribuir a um dador um número de colheita. 6. Atribuir um número de colheita já utilizado ao mesmo e a outro dador, e um

número de colheita com estrutura errada. 7. Demonstrar ligação unívoca do dador ao número de colheita atribuído

(pesquisando por número de colheita e por número de dador)


70


Os dados de preenchimento obrigatório incluem forçosamente todos os dados obrigatórios por lei e necessários para assegurar a rastreabilidade.

1. A ficha de registo electrónico dos resultados dos procedimentos de avaliação clínica permite registar todos os dados de preenchimento obrigatório para a triagem clínica de dadores e os resultados das análises efectuadas ao dador no contexto da triagem clínica.

2. O SI NÃO permite inscrever dadores para colheita dos vários tipos de dádivas, para os quais ainda não tenha passado o intervalo de tempo determinado para cada tipo de dádiva e emite alertas e/ou mensagens de erro adequados a cada situação.

3. O SI NÃO permite aprovar e inscrever para colheita um dador previamente eliminado e emite alertas e/ou mensagens de erro adequados a cada situação.

4. O SI tem previsto o registo dos motivos de suspensão temporária e definitiva de dadores homólogos ou autólogos e do prazo de suspensão temporária de dadores homólogos.

Se aplicável neste processo: 5. O SI permite à atribuição a um dador de um número de colheita a realizar. 6. O SI não permite atribuir um número de colheita já utilizado nem ao mesmo

nem a outro dador, nem atribuir um número de colheita com estrutura errada.

7. O SI permite demonstrar a ligação unívoca do dador ao número de colheita atribuído (pesquisando por número de colheita e por número de dador).


Verificação de todos os resultados esperados para as situações aplicáveis.

Resultados obtidos

Conclusão


71

Nome e código do processo: Realização da colheita (SS5)


1.22 Se aplicável

Tem que disponibilizar local para atribuição do número de colheita a realizar, assegurando a unicidade da ligação Dador ‐ Nº de colheita.

1.23 Se aplicável

Tem de existir um mecanismo de verificação do número de colheita atribuído.

5.2 Tem de possuir meios que obriguem à confirmação da identificação do dador imediatamente antes da venopunção.

5.3 Tem de possuir meios que obriguem à confirmação da identificação da dádiva e das amostras para análise após a venopunção.

5.5 Tem que permitir registar reacções adversas e/ou lesões decorrentes da dádiva de sangue ou componentes e observações.

1.3.2 Tem de garantir o estabelecimento claro de uma relação entre cada colheita e o sistema de colheita utilizado.

5.6 Tem que permitir registar as características dos dispositivos médicos utilizados na colheita.


Solicitar quais os dados de preenchimento obrigatório para ao registo dos dados de colheita. Solicitar ao profissional que efectua a colheita que aceda ao registo electrónico dos procedimentos de colheita e que realize os procedimentos a seguir referidos. Imprimir os ecrãs de todas as operações. Se aplicável neste processo: 1. Atribuir a um dador um número de colheita. 2. Atribuir um número de colheita já utilizado ao mesmo e a outro dador, e um

número de colheita com estrutura errada. 3. Demonstrar ligação unívoca do dador ao número de colheita atribuído

(pesquisando por número de colheita e por número de dador) Aplicar sempre: 4. Assistir aos procedimentos de confirmação obrigatória da identificação do

dador imediatamente antes da venopunção. 5. Assistir aos procedimentos de confirmação obrigatória da identificação da

dádiva e das amostras para análise após a venopunção. 6. Simular (sem gravar), ou efectuar na ocorrência de uma situação real, o

registo de reacções adversas e/ou lesões decorrentes da dádiva de sangue ou componentes e observações.

7. Assistir ao registo do tipo e características do sistema de colheita utilizado relativo a cada colheita, para os tipos de colheita e de sistemas distintos.


Os dados de preenchimento obrigatório incluem forçosamente todos os dados obrigatórios por lei e necessários para assegurar a rastreabilidade. Se aplicável neste processo: 1. O SI permite à atribuição a um dador de um número de colheita a realizar. 2. O SI não permite atribuir um número de colheita já utilizado nem ao mesmo

nem a outro dador, nem atribuir um número de colheita com estrutura errada.

3. O SI permite demonstrar a ligação unívoca do dador ao número de colheita


72

atribuído (pesquisando por número de colheita e por número de dador). Verificar sempre 4. O SI permite e regista a realização de procedimentos de confirmação da

identificação do dador imediatamente antes da venopunção. 5. O SI permite e regista a realização de procedimentos de confirmação de

identificação da dádiva e das amostras para análise após a venopunção. 6. O SI permite o registo de reacções adversas e/ou lesões decorrentes da

dádiva de sangue ou componentes e observações. 7. O SI permite o registo do tipo e características do sistema de colheita utilizado

relativo a cada colheita, para os tipos de colheita e de sistemas distintos.



Resultados obtidos

Conclusão


73

Nome e código do processo: Laboratórios de Microbiologia, Imuno‐hemoterapia e

Controlo da Qualidade (SS6)


6.2 Tem permitir fazer a gestão dos pedidos de análises, diferenciando claramente entre análise realizadas e por realizar.

6.3 Tem que permitir fazer o registo de todos os resultados analíticos obtidos no laboratório de imunohematologia para as análises obrigatórias.

6.3.1 Tem de permitir o registo para todos os dadores dos grupos sanguíneos AB0 e RhD.

6.4 Tem que permitir fazer o registo de todos os resultados analíticos obtidos no laboratório de microbiologia para as análises obrigatórias.

6.4.1 Tem de possuir mecanismos que permitam assegurar que os dadores com resultados repetidamente positivos nos testes de rastreio das infecções víricas tenham um tratamento diferenciado obrigando à intervenção directa de utilizador habilitado.

6.7 Tem que permitir realizar a validação automática de resultados de acordo com critérios pré‐estabelecidos (negatividade do rastreio, comparação com histórico, etc.).

6.8 Tem de permitir o registo do valor de proteínas determinado no sangue dos dadores de plasma por aférese, pelo menos anualmente.

6.9 Tem de permitir o registo do valor de plaquetas determinado no sangue dos dadores de plaquetas por aférese.

1.12 Tem de existir um processo de verificação da introdução manual de dados críticos, tais como resultados de testes laboratoriais.


Solicitar quais os dados de preenchimento obrigatório para ao registo dos dados laboratoriais para cada área. Solicitar ao(s) profissional(is) que efectuam testes laboratoriais que realize os procedimentos a seguir referidos. Imprimir os ecrãs de todas as operações. 1. Demonstrar a gestão dos pedidos de análises e a distinção entre análises

realizadas e por realizar. 2. Demonstrar o registo dos resultados analíticos obtidos no laboratório de

imunohematologia para as análises obrigatórias. 3 Demonstrar o registo dos resultados analíticos obtidos no laboratório de

microbiologia para as análises obrigatórias. 4. Demonstrar que os dadores com resultados repetidamente positivos nos

testes de rastreio das infecções víricas têm um tratamento diferenciado obrigando à intervenção directa de utilizador habilitado.

5. Realizar a validação automática de resultados de acordo com critérios pré‐estabelecidos (negatividade do rastreio, comparação com histórico, etc.). e demonstrar que dadores com resultados anteriores não normais foram processados de modo diferenciado dos sem antecedentes.

6. Demonstrar o registo do valor de proteínas determinado no sangue dos dadores de plasma por aférese e do valor de plaquetas determinado no sangue dos dadores de plaquetas por aférese.

7. Realizar um processo de introdução manual de dados críticos, tais como resultados de testes laboratoriais.


74


Os dados de preenchimento obrigatório incluem forçosamente todos os dados obrigatórios por lei e necessários para assegurar a rastreabilidade. 1. O SI permite a gestão dos pedidos de análises e a distinção entre análises

realizadas e por realizar. 2. O SI permite o registo dos resultados analíticos obtidos no laboratório de

imunohematologia para as análises obrigatórias. 3. O SI permite o registo dos resultados analíticos obtidos no laboratório de

microbiologia para as análises obrigatórias. 4. O SI permite que os dadores com resultados repetidamente positivos nos

testes de rastreio das infecções víricas tenham um tratamento diferenciado obrigando à intervenção directa de utilizador habilitado.

5. O SI permite realizar a validação automática de resultados de acordo com critérios pré‐estabelecidos (negatividade do rastreio, comparação com histórico, etc.). e os dadores com resultados anteriores não normais são processados de modo diferenciado dos sem antecedentes.

6. O SI permite o registo do valor de proteínas determinado no sangue dos dadores de plasma por aférese, pelo menos anualmente e do valor de plaquetas determinado no sangue dos dadores de plaquetas por aférese para todas as dádivas.

7. O SI realiza um processo de verificação da introdução manual de dados críticos, tais como resultados de testes laboratoriais.



Resultados obtidos

Conclusão


75

Nome e código do processo: Separação de Componentes (SS7)


7.1 Tem permitir o registo do processamento a que cada colheita é submetida.

7.2 Tem permitir fazer a gestão das unidades de sangue que aguardam processamento, diferenciando claramente entre processamentos realizados e por realizar.


Solicitar quais os dados de preenchimento obrigatório para o registo da Separação de Componentes. Solicitar ao(s) profissional(is) que efectuam estas actividades que realize(m) os procedimentos a seguir referidos. Imprimir os ecrãs de todas as operações. 1. Demonstrar o registo do processamento de 3 unidades com diferentes

destinos finais. 2. Demonstrar a gestão da separação das colheitas de acordo com os seus

diferentes estados.


1. O SI permite o registo do processamento de unidades com diferentes destinos finais (preparação de diferentes produtos sanguíneos, inutilização por diferentes motivos, etc.).

2. O SI permite a gestão da separação das colheitas de acordo com os seus diferentes estados.



Resultados obtidos

Conclusão


76

Nome e código do processo: Rotulagem, Gestão de Stocks e Distribuição de componentes

(SS8)


8.1 Tem que permitir a impressão de rótulos normalizados (ISBT128) para identificação de cada componente sanguíneo. "O rótulo de cada um dos componentes deve conter as seguintes informações: Designação oficial do componente; Volume, peso ou número de células do componente (consoante o caso); Identificação única, numérica ou alfanumérica, da dádiva; Nome do serviço de sangue de produção; Grupo ABO (não necessária para o plasma destinado exclusivamente a fraccionamento); Grupo Rh D, especificando «Rh D positivo» ou «Rh D negativo» (não necessária para o plasma destinado exclusivamente a fraccionamento); Data ou prazo de validade (consoante o caso); Temperatura de armazenamento; Nome, composição e volume do anticoagulante e ou solução aditiva (caso exista)."

8.2 Tem de permitir a rotulagem dos componentes de dádivas de dadores novos só após a realização de dois testes independentes AB0 RhD.

8.3 Tem de impedir a rotulagem dos componentes eritrocitários de dádivas de dadores sujeitas a pesquisa de anticorpos eritrocitários irregulares, cujo resultado seja positivo.

8.4 Tem de permitir identificar todos os componentes sanguíneos resultantes de dádivas com resultados repetidamente positivos para testes de rastreio, características não conformes com os parâmetros de qualidade do produto ou dos processos, expiração da validade, estudos imunohematológicos inconclusivos de modo a que tenham um tratamento diferenciado, com vista à sua eliminação ou uso não terapêutico.

8.5 Tem de permitir o registo do envio de componentes sanguíneos a outras instituições.

8.7 Tem de gerar documentação comprovativa do envio de componentes sanguíneos a outras instituições.

8.8 Tem que permitir a monitorização do inventário de componentes disponíveis e indisponíveis.

1.3.5 Tem de registar e armazenar detalhes dos movimentos das unidades, incluindo transferência entre stocks reservados e não reservados, transferência de e para frigoríficos satélite, envios a enfermarias e serviços, transferências para outros hospitais e causas de inutilização.


Solicitar ao(s) profissional(is) que efectuam estas actividades que realize(m) os procedimentos a seguir referidos. Imprimir os ecrãs de todas as operações. 1. Verificar se os rótulos para identificação de cada componente sanguíneo são

normalizados segundo a norma ISBT128. 2. Verificar se os rótulos de 3 componentes têm as seguintes informações: ‐Designação oficial do componente; ‐Volume, peso ou número de células do componente (consoante o caso); ‐Identificação única, numérica ou alfanumérica, da dádiva; ‐Nome do serviço de sangue de produção; ‐Grupo ABO (não necessária para o plasma destinado exclusivamente a fraccionamento); ‐Grupo Rh D, especificando «Rh D positivo» ou «Rh D negativo» (não necessária para o plasma destinado exclusivamente a fraccionamento);


77

‐Data ou prazo de validade (consoante o caso); ‐Temperatura de armazenamento; ‐Nome, composição e volume do anticoagulante e ou solução aditiva (caso exista). 3. Demonstrar como decorre a rotulagem dos componentes de dádivas de

dadores novos com e ainda sem a realização de dois testes independentes AB0 RhD.

4. Demonstrar como decorre a rotulagem dos componentes de dádivas de dadores sujeitos a pesquisa de anticorpos eritrocitários irregulares, cujo resultado seja positivo.

5. Demonstrar como é feita a identificação de todos os componentes sanguíneos resultantes de dádivas com resultados repetidamente positivos para testes de rastreio, características não conformes com os parâmetros de qualidade do produto ou dos processos, expiração da validade, estudos imunohematológicos inconclusivos e do tratamento diferenciado de que são alvo, com vista à sua eliminação ou uso não terapêutico.

6. Realizar o registo do envio de componentes sanguíneos a outras instituições e emitir a documentação comprovativa do mesmo.

7. Realizar a consulta do inventário de componentes disponíveis e indisponíveis. 8. Demonstrar o registo e os detalhes armazenados dos movimentos das

unidades, incluindo transferência entre stocks reservados e não reservados, transferência de e para frigoríficos satélite, envios a enfermarias e serviços, transferências para outros hospitais e causas de inutilização.


1. Os rótulos para identificação de cada componente sanguíneo são normalizados segundo a norma ISBT128.

2. Os rótulos dos vários componentes têm as seguintes informações: ‐Designação oficial do componente; ‐Volume, peso ou número de células do componente (consoante o caso); ‐Identificação única, numérica ou alfanumérica, da dádiva; ‐Nome do serviço de sangue de produção; ‐Grupo ABO (não necessária para o plasma destinado exclusivamente a fraccionamento); ‐Grupo Rh D, especificando «Rh D positivo» ou «Rh D negativo» (não necessária para o plasma destinado exclusivamente a fraccionamento); ‐Data ou prazo de validade (consoante o caso); ‐Temperatura de armazenamento; ‐Nome, composição e volume do anticoagulante e ou solução aditiva (caso exista). 3. O SI permite a rotulagem dos componentes de dádivas de dadores novos

apenas quando foram realizados dois testes independentes AB0 RhD e na situação oposta gera uma mensagem de alerta.

4. O SI não permite a rotulagem dos componentes de dádivas de dadores sujeitos a pesquisa de anticorpos eritrocitários irregulares, cujo resultado seja positivo e gera uma mensagem de alerta.

5. É possível, por meio de listagem, pesquisa ou de outra forma identificar todos os componentes sanguíneos resultantes de dádivas com resultados repetidamente positivos para testes de rastreio, características não conformes com os parâmetros de qualidade do produto ou dos processos, expiração da validade, estudos imunohematológicos inconclusivos e do tratamento diferenciado de que são alvo, com vista a facilitar e garantir à sua eliminação ou uso não terapêutico.


78

6. É possível realizar o registo do envio de componentes sanguíneos a outras instituições e emitir a documentação comprovativa do mesmo.

7. É possível realizar a consulta do inventário de componentes disponíveis e indisponíveis.

8. É possível realizar o registo dos movimentos das unidades e armazenar detalhes dos mesmos, incluindo transferência entre stocks reservados e não reservados, transferência de e para frigoríficos satélite, envios a enfermarias e serviços, transferências para outros hospitais e causas de inutilização.


Verificação de todos os resultados esperados.

Resultados obtidos

Conclusão


79

Nome e código do processo: Apoio à Gestão (SS‐SMT14)


14.1 Tem de existir um mecanismo para identificar múltiplos registos de um mesmo dador ou doente baseados em critérios relacionados com os identificadores.

14.2 Tem de permitir obter os dados necessários à realização do relatório anual para o IPS.

14.3 Tem de permitir obter os dados necessários à realização do relatório anual para a ASST.

14.6 Tem de permitir o registo de comunicações do dador após a dádiva (reacções, complicações, infecções, etc.).


Solicitar ao(s) profissional(is) com nível de permissão adequado os procedimentos a seguir referidos. Imprimir os ecrãs de todas as operações. 1. Realizar a pesquisa de dadores com dados demográficos idênticos e realizar a

comparação dos registos com base nos identificadores que permitem a sua distinção inequívoca.

2. Fazer a consulta dos dados estatísticos e verificar se são produzidos todos os indicadores necessários para a realização dos relatórios para o IPS e para a ASST.

3. Demonstrar a existência de registos no SI de comunicações do dador após a dádiva (reacções, complicações, infecções, etc.), ou se não existirem demonstrar a possibilidade da sua realização.


1. O SI permite realizar a pesquisa de dadores com dados demográficos idênticos e realizar a comparação dos registos com base nos identificadores que permitem a sua distinção inequívoca, de forma a facilitar a detecção de múltiplos registos do mesmo indivíduo.

2. O SI permite realizar a consulta dos dados estatísticos entre datas e produz todos os indicadores necessários para a realização dos relatórios para o IPS e para a ASST.

3. O SI permite realizar registos de comunicações do dador após a dádiva (reacções, complicações, infecções, etc.), ficando estas comunicações relacionadas com a dádiva e dador em causa.


Verificação de todos os resultados esperados.

Resultados obtidos

Conclusão


80

Nome e código do processo: SS1 Geral

1.3 Tem de assegurar a rastreabilidade de todos os processos realizados pelos serviços de sangue com: 1) Identificação do serviço de sangue; 2) Identificação do dador de sangue; 3) Identificação da unidade de sangue; 4) Identificação do componente sanguíneo individual; 5) Data da colheita (ano/mês/dia); 6) Instalações às quais são distribuídas; 7) Unidades de sangue ou componentes sanguíneos ou destruição subsequente, e de todos os processos realizados pelos estabelecimentos com: 1) Identificação do fornecedor do componente sanguíneo; 2) Identificação do componente sanguíneo disponibilizado; 3) Identificação do receptor transfundido; 4) Para unidades de sangue não transfundidas, confirmação da destruição subsequente; 5) Data da transfusão ou da destruição (ano/mês/dia); 6) Número do lote do componente, se relevante.

1.3.1 Tem de garantir o estabelecimento claro de uma relação entre o dador e o sangue, os componentes sanguíneos e as amostras de sangue para análise.

1.3.3 Tem de utilizar identificadores previamente definidos que relacionados entre si, permitam de um modo consistente caracterizar cada evento. Estes identificadores englobam: número de dador; número de colheita; tipo de dádiva; tipo de colheita; locais de colheita; identificação de utilizador, caracterização de instituição, identificação de doente; equipamentos; tipo de componentes; métodos de colheita; métodos de processamento; métodos de análise; reacções adversas; critérios de exclusão; critérios de suspensão (definitiva/temporária); serviços; hospitais; destino final (inclui instituição, transfundido, devolvido ou destruído)

1.5 Tem de registar as operações de introdução, modificação ou eliminação de dados e de validação, devendo incluir no mínimo: identidade do operador, data e hora da operação, alterações associadas a grupos de sangue, pesquisas de anticorpos e fenotipagem, fusão de registos, qualquer tomada de conhecimento de alertas do sistema.

1.6 Tem de disponibilizar meios que permitam que não haja modificação ou eliminação acidental ou propositada de dados.

1.7 Tem de garantir a interoperabilidade com os equipamentos existentes.

1.8 Tem de disponibilizar um sistema de rotulagem do sangue colhido, dos componentes sanguíneos intermediários e acabados e das amostras que identifique sem margem para erro o tipo de conteúdo e observe os requisitos de rotulagem e rastreabilidade obrigatórios por lei.

1.13 Tem de impossibilitar que uma unidade de sangue ou de componentes sanguíneos seja aprovada até que tenham sido observados todos os requisitos obrigatórios estabelecidos.

1.14 Tem de exercer um controlo sobre os procedimentos de libertação e disponibilização de componentes.

1.14.1 Tem que permitir a parametrização das condições de validação e libertação de componentes sanguíneos.

1.14.4 Tem de possuir mecanismos que permitam assegurar que o sangue e os componentes sanguíneos com resultados repetidamente positivos nos testes serológicos de rastreio das infecções víricas, de acordo com o normativo existente, não possam ser utilizados para fins terapêuticos.


81

1.14.5 Tem de possuir mecanismos que permitam assegurar que o sangue e os componentes sanguíneos sem os estudos imunohematológicos adequados não possam ser utilizados para fins terapêuticos.

1.14.6 Tem de possuir mecanismos que permitam assegurar que o sangue os componentes sanguíneos e os lotes de onde eles provêm, não possam ser utilizados para fins terapêuticos, sem que haja validação dos resultados de Controlo da Qualidade.

1.20 Tem que permitir o acesso ao registo do histórico de cada dador em função da área de actividade que a solicita e o perfil do utilizador.


Em função dos incumprimentos detectados nos testes realizados nos processos anteriores será possível identificar quais destes requisitos não são satisfeitos.


Todos os testes anteriores verificam o cumprimento destes requisitos.


Não se tendo verificado situações de incumprimento nos testes realizados nos processos anteriores pode‐se considerar o cumprimento de todos estes requisitos.

Resultados obtidos

Conclusão

Resumo global

Não cumpre com os seguintes requisitos:

Recomendações:


82

5. Caracterização dos sistemas informáticos dos SS e SMT

Portugueses

5.1 Objectivo

O objectivo deste inquérito é recolher informação que permita caracterizar os sistemas

informáticos em utilização pelos SS e SMT Portugueses na sua actividade, identificando e

caracterizando segundo a perspectiva dos utilizadores os vários softwares utilizados, a

responsabilidade de gestão dos sistemas informáticos, as políticas de segurança, registo e

controlo de propostas e alterações ao sistema, rastreabilidade dos processos, bem como o

estado, as actividades e as competências relacionadas com a validação destes sistemas.

5.2 Material e métodos

5.2.1 Tipo de Estudo

Estudo transversal, descritivo, observacional realizado por inquérito, aplicado por

entrevistador único.

5.2.2 População e Amostra em Estudo

Todos os SS e SMT Portugueses. A população coincide com a amostra.

5.3 Metodologia

5.3.1 Elaboração do Questionário

O questionário (Anexo 1) foi elaborado a partir da listagem de requisitos previamente

preparada (incluída no capítulo 3, “Proposta de Especificação dos Requisitos do

Utilizador”) e tendo como referências principais o Decreto‐Lei nº 267/2007 de 24 de Julho,

as Guidelines e as boas práticas já referenciadas.

A estrutura do questionário foi preparada para caracterizar as seguintes dimensões:

Tipo de instituição e serviço

Sistema informático utilizado

Responsabilidade de gestão do sistema informático

Segurança dos dados e dos equipamentos

Registo e controlo de propostas e alterações ao sistema


83

Rastreabilidade dos processos

Estado, actividades e competências relacionadas com a validação destes sistemas.

As questões elaboradas para caracterizar cada uma das dimensões deram origem a um

Inquérito semi‐estruturado, com perguntas maioritariamente fechadas e algumas abertas

para permitir uma melhor caracterização das actividades não cobertas pelo SI e de

comentários importantes a algumas das questões fechadas.

Testou‐se o inquérito com 4 elementos de um Serviço de Sangue e com actividade em

Medicina Transfusional, sendo 3 especialistas em Imuno‐hemoterapia e 1 Licenciado em

Informática de Gestão. Em função destes testes foi decidido acrescentar, alterar e/ou

adaptar algumas opções de resposta para várias questões.

O questionário foi aplicado por um único entrevistador através de contacto telefónico

personalizado, com garantia explícita de confidencialidade, aos responsáveis dos serviços

ou aos elementos dos serviços por si delegados por terem a seu cargo os assuntos

relacionados com a informática.

Os contactos foram efectuados entre 22‐09‐2010 e 02‐11‐2010.

5.3.2 Tratamento dos Dados

Os dados recolhidos foram registados numa base de dados criada expressamente para o

efeito, utilizando a aplicação SPSS® tendo‐se posteriormente realizado o seu tratamento

estatístico uni e bivariado.

Durante este processo de tratamento foram assumidos os seguintes artifícios:

Em alguns casos trataram‐se os “NS ‐ Não sabe” e “NA ‐ Não aplicável” como respostas

neutras, sendo obtidas as frequências absolutas e relativas sem considerar estas respostas.


84

5.4 Resultados

Utilizou‐se uma listagem inicial de 143 entidades prestadoras de cuidados de saúde.

Não foi possível estabelecer contacto telefónico com 16 serviços.

Dos 127 serviços contactados não se aplicou o questionário a 35, por não possuírem

sistema informático, restando assim 92.

Destes 92 serviços, verificaram‐se 7 recusas de prosseguir a resposta durante realização

do questionário. As razões apontadas para tal foram: estar impedidos de prestar

declarações ao exterior pela administração da instituição (3 directores), apenas poder

responder presencialmente (2 directores), 1 director achou as questões iniciais demasiado

intrusivas e 1 inicialmente demonstrou desconfiança e apesar de várias tentativas não foi

possível contactar novamente.

Figura 5 – Fluxograma da realização do inquérito

143 Prestadores de cuidados de saúde com potencial prática

transfusional

Foi possível contactar 127 serviços:

‐ 24 PT

‐ 69 SMT

‐ 34 SS+SMT

92 Serviços com sistema informático:

‐ 59 SMT

‐ 33 SS+SMT

85 Serviços com sistema informático

(Muitos serviços integrados em agrupamentos hospitalares )

48 Respostas de responsáveis dos agrupamentos :

‐25 SS+SMT

‐23 SMT

7 Recusas de resposta após início do inquérito

‐ 2 SS+SMT

‐ 1 SS Proc. Ext.+SMT

‐ 4 SMT

35 Serviços sem sistema informático:

‐ 24 PT

‐ 10 SMT

‐ 1 SS+SMT

Não foi possível contactar por telefone 16


85

5.4.1 Tipo de Instituição e Serviço

Pelo facto de muitas Instituições terem sido integradas em agrupamentos hospitalares de

diferente tipo administrativo a situação organizacional revelou‐se complexa, em alguns

casos confusa e ainda mal definida. Por vezes não havia uma clara definição e assumir das

funções de direcção dos serviços, o que se pode atribuir a processos de reorganização

ainda em curso.

Assim, a partir da classificação inicial de cada serviço ou instituição como Ponto

Transfusional (PT), Serviço de Sangue, Serviço de Medicina Transfusional, Serviço de

Sangue e de Medicina Transfusional (SS + SMT) e Serviço de Sangue com Processamento

de Análises e Separação de Componentes no Exterior e Serviço de Medicina Transfusional

(SS (Proc. Ext.) + SMT), procedeu‐se à reclassificação dos 48 serviços com resposta válida

ao inquérito de forma a explicitar a organização actual da instituição ou agrupamento

hospitalar em que se inserem (Erro! A origem da referência não foi encontrada.):

Tabela 5 ‐ Distribuição das respostas por tipos e agrupamentos de serviços

Tipos e Agrupamentos de Serviços N

SMT 12

SS (Proc. Ext.) + SMT 3

SS + SMT 11

Agrupamento Hospitalar com 1 SS + SMT e 2 PT 1

Agrupamento Hospitalar com 1 SMT e 1 PT 2


Agrupamento Hospitalar com 1 SS + SMT e 1 SMT 2

Agrupamento Hospitalar com 1 SS+SMT e 1 PT 1

Agrupamento Hospitalar com 1 SS+SMT e 1 SMT 1

Agrupamento Hospitalar com 2 SMT 2



Agrupamento Hospitalar com 3 SS + SMT 1




Prestador de Serviços em 15 SMT 1

Total 48

Não contabilizando as 7 recusas de resposta nem os pontos transfusionais, pode‐se

considerar que as 48 respostas válidas obtidas caracterizam a realidade de 85 Instituições.


86

Na tabela 6 e nas figuras 6 a 9, faz‐se a sua caracterização relativamente ao volume de

actividade e dimensão das estruturas.

Tabela 6 ‐ Caracterização das instituições questionadas em 2009

Nº de colheitas

Nº de Unidades Transfundidas

Nº de Camas Nº de

Profissionais

Contagem N válidos 25 47 45 47

Mediana 6000 5367 450 14

Mínimo 208 200 54 3

Máximo 88441 50000 1300 154

Soma 319971 399977 21180 1056

Percentis 25 2883 1971 217 8

50 6000 5367 450 14

75 9000 10000 613 23

Figura 6 ‐ Número de colheitas realizadas em 2009

Figura 7 ‐ Número de unidades transfundidas em 2009


87

Dois serviços de sangue não dispõem de internamento e não foi possível obter resposta

relativamente a alguns serviços englobados num mesmo inquérito.

Figura 8 ‐ Número de Camas de 45 inquiridos com internamento

Quanto ao número de profissionais (figura 5), os resultados obtidos são muito discrepantes

apontando para diferentes critérios de contabilização de profissionais sem alocação às

diferentes actividades (SS, SMT ou ambos). Em alguns casos são contabilizados os

profissionais dos laboratórios de patologia por todos eles prestarem serviço no SS,

escalados regular ou pontualmente.

Figura 9 – Número de profissionais por serviço


88

Comparando o número de SS (28) e de SMT (85), o número total de colheitas (319 971) e

de unidades transfundidas (399 977) por nós obtido, com o número de SS (29) e de SMT

(59), o número total de unidades de eritrócitos produzidas (398 429) e o número de

unidades de todos os componentes transfundidos (462 366) apresentados pela Autoridade

para os Serviços de Sangue e da Transplantação (ASST) relativos ao ano de 2009, podemos

considerar que os dados obtidos são representativos da actividade transfusional

Portuguesa como se encontra resumido na tabela 7.

Tabela 7 ‐ População da amostra versus, dados da ASST relativos a 2009

Inquérito ASST

SS 28 29

SMT 85 59

Nº total de colheitas 319 971

Nº total de unidades de eritrócitos produzidas 398 429

Nº de unidades de todos os componentes transfundidos 399 977 462 366

Fonte: Autoridade para os Serviços de Sangue e de Transplantação

As causas da diferença relativamente ao número de SMT contabilizados pela ASST e por

nós, são difíceis de apurar, pois a metodologia de recolha e tratamento de dados por parte

daquela Autoridade não está descrita. Poder‐se‐á dever entre outras ao facto desta

Autoridade questionar os responsáveis dos SMT sem ter em conta a realidade que são os

agrupamentos hospitalares, (como já descrito anteriormente sobre a constituição dos

agrupamentos hospitalares – tabela 5), ou à falta de registo ou resposta de alguns.

Dos 48 serviços e agrupamentos hospitalares inquiridos:

30 (62,50%) estão certificados;

8 (16,67%) têm o processo de certificação em curso;

10 (20,83%) não estão certificados (1 destes últimos já esteve mas perdeu a

certificação), (figura 10).


89

Figura 10 – Distribuição dos serviços inquiridos relativamente ao estado de certificação

5.4.2 Sistema informático utilizado

Na tabela 8 são apresentadas as frequências por tipo de instituição e software utilizado

para as 85 instituições abrangidas pelos 48 inquéritos realizados.

Tabela 8 ‐ Software utilizado por tipo de serviço

Software SMT SS + SMT SS (Proc. Ext.) + SMT Total (%)

ASIS 19 13 32 (37,65%)

SIBAS 14 10 4 28 (32,94%)

DELPHYN 13 13 (15,29%)

e‐DELPHYN 3 3 (3,53%)

ClinidataBST 3 3 (3,53%)

IMAGINASOFT 1 2 3 (3,53%)

NOVA HIS 1 1 (1,18%)

PELICANO 1 1 (1,18%)

ROCAIL 1 1 (1,18%)

Total 55 26 4 85 (100,00%)

Contabilizando as instituições que recusaram a resposta depois do inicio do inquérito, foi

possível saber qual o software utilizado em 92 serviços. Das 7 recusas, 5 utilizam o ASIS e 2

o SIBAS.

A análise dos softwares utilizados por agrupamento hospitalar, permite verificar que os

softwares ASIS e SIBAS são os mais utilizados pela generalidade dos serviços (tabela 9)

Já esteve1,83%

Não19,00%

Processo em Curso16,67%

Sim62,50%


90

Tabela 9 ‐ Software utilizado por tipo de serviço após integração em agrupamentos hospitalares

SMT SS + SMT SS (Proc. Ext.) + SMT Total (%)

ASIS 11 9 20 (41,67%)

SIBAS 6 10 3 19 (39,58%)

IMAGINASOFT 1 2 3 (6,25%)

ClinidataBST 1 1 (2,08%)

DELPHYN 1 1 (2,08%)

e‐DELPHYN 1 1 (2,08%)

NOVA HIS 1 1 (2,08%)

PELICANO 1 1 (2,08%)

ROCAIL 1 1 (2,08%)

Total 23 22 3 48 (100,00%)

É de salientar que o DELPHIN, apesar de contabilizado apenas uma vez (correspondente a

um inquérito) está instalado em 13 locais.

O SIBAS é utilizado em 13 SS + SMT que realizam 92 566 colheitas, o ASIS é utilizado em 9

SS + SMT que realizam 204 178 colheitas.

Relativamente ao número de unidades transfundidas, o SIBAS documentou em 2009,

221 279 em 28 serviços e o ASIS documentou 132 302 em 32 locais.

Com outros 2 softwares (IMAGINASOFT e PELICANO) foram registadas as restantes 23 227

colheitas.

Os softwares IMAGINASOFT, ClinidataBST, DELPHIN, e‐DELPHIN, NOVA HIS, PELICANO e

ROCAIL documentaram 46 396 transfusões, no entanto não se obtiveram dados para 15

SMT que têm o seu funcionamento assegurado por um prestador de serviços comum.


91

Quanto à análise das actividades do serviço que os inquiridos consideram não estar

integradas no sistema informático, esta está sistematizada na tabela seguinte.

Tabela 10 – Actividades não integradas no sistema informático ou deficitárias

Actividade Software Comentários Serviços *

Promoção da Dádiva / Planeamento de Colheitas IMAGINASOFT Não integrada 1 SS + SMT

Laboratório de Imuno‐hemoterapia SIBAS Apresenta dificuldades quando se trata de doentes com pedido de estudo e sem pedido de transfusão

1 SS (Proc. Ext.) + SMT

Laboratório de Controlo da Qualidade SIBAS Não integrada 6 SS + SMT e 2 SS

SIBAS Rudimentar 1 SS + SMT

ASIS Não integrada 6 SS + SMT

PELICANO Não integrada 1 SS + SMT

Preparação / Atribuição de Transfusões ASIS Não contempla as transfusões emergentes, não permitindo o envio de unidades sem provas nem o registo de alguns grupos e pesquisas de anticorpos

1 SS + SMT

Administração / Confirmação Positiva da Transfusão ASIS

Não integrada 6 SMT e 3 SS + SMT

IMAGINASOFT Não integrada 1 SS + SMT

NOVAHIS Não integrada 1 SMT

PELICANO Não integrada 1 SS + SMT

SIBAS Não integrada 1 SMT

Apoio à Gestão ASIS Integrada mas, má ou fraca

2 SMT e 2 SS + SMT

SIBAS Pouco amigável ou pouco fiável ou confuso ou rudimentar. Referido por 1 serviço que melhorou na última versão.

6 SS + SMT

ClinidataBST Não integrada 1 SMT

*Nº e tipo de serviços que fizeram comentários

Alguns comentários em relação à mesma aplicação foram contraditórios, talvez devido à

utilização de versões diferentes do mesmo software. Muitos dos serviços não sabiam

informar qual seria essa versão, pelo que não foi aqui apresentada qualquer discriminação.

Apresenta‐se seguidamente a sistematização da informação obtida, de acordo com os

diferentes softwares utilizados.


92

ASIS

Segundo vários inquiridos o ASIS não integra o registo e gestão dos resultados do

“Laboratório de Controlo da Qualidade” e não permite a “Administração / Confirmação

Positiva da Transfusão”.

Relativamente à “Preparação / Atribuição de Transfusões”, foi referido que não

contempla as transfusões emergentes, não permitindo o envio de unidades sem provas.

Não contempla a possibilidade de realização de transfusões maciças. Também não

permite o registo de alguns grupos e pesquisas de anticorpos.

Segundo outros utilizadores o “Apoio à Gestão” é mau, fraco ou insuficiente, sendo

mesmo considerado a “parte mais fraca”.

A realização de consultas e estatísticas são lentas e segundo 1 inquirido péssimas, a

usabilidade é má, gera consumo excessivo de papel, e a aplicação está ultrapassada.

Necessita de melhorias ao nível da exploração da base de dados e das listagens

disponíveis.

Ao imprimir cartas para os dadores por vezes imprime várias para o mesmo dador ou

saem apenas as cartas para os que fizeram uma dádiva dos últimos 12 meses ignorando

assim os dadores menos frequentes.

A assistência técnica prestada pelo IPS dá pouca resposta as solicitações.

Um inquirido referiu ter havido falha na formação durante a instalação do novo ASIS

hospitalar, e que complicaram demais o sistema.

Vários serviços ultrapassam a não integração de algumas actividades do serviço

recorrendo a registos manuais em papel, a folhas de cálculo Excel e a outras aplicações.

Apresenta limitações ao nível das interfaces com outros sistemas ou aplicações. A

transmissão de dados online é incompleta e requer optimização dos pedidos online.

Tem algumas funcionalidades que não se utilizam.

De salientar que existem dois softwares ASIS. Um dedicado à actividade dos SS e outro

à actividade dos SMT.


93

e‐DELPHYN

Não permite entrada de hemoderivados comerciais.

Não permite corrigir erros de introdução do fenótipo.

A resposta da empresa que comercializa e presta assistência decepciona.

IMAGINASOFT

1 SS + SMT não está totalmente satisfeito com a rastreabilidade das colheitas e das

transfusões

NOVA HIS

A “Administração / Confirmação Positiva da Transfusão” é realizada por registo manual.

No registo das unidades provenientes de outras instituições o sistema não permite a

leitura directa das unidades, sendo necessário atribuir um nº interno manual.

Obriga a excesso de intervenção humana.

PELICANO

Aplicação que aguarda substituição, foi descontinuada pelo fornecedor.

Não permite aceder à história clínica do dador.

Erros complicados e impossíveis de desfazer.

Sem transferência de resultados (obriga à introdução manual).

Não integra o registo e gestão dos resultados do “Laboratório de Controlo da

Qualidade”.

Não permite a “Administração / Confirmação Positiva da Transfusão”.


94

ROCAIL

Aplicação que aguarda substituição, foi descontinuada pelo fornecedor.


SIBAS

Promoção da Dádiva / Planeamento de Colheitas deve ser melhorada.

“Laboratório de Imuno‐hemoterapia” apresenta algumas dificuldades no registo de

estudos de doentes sem pedido de transfusão.

Oito SS referiram que não integra o “Laboratório de Controlo da Qualidade”, enquanto

outros SS informaram que não integra totalmente, que é muito incompleto, rudimentar

e outro que tem mas não usa. Informações contraditórias talvez devido à utilização de

diferentes versões do software, situação difícil de esclarecer por não ser feito adequado

controlo de versões pelos serviços.


No “Apoio à Gestão” faz tratamento estatístico com apresentação dos resultados pouco

amigável, confuso, rudimentar, pouco fiável, tendo sido referido por vários que é

necessário pedir a intervenção do fornecedor do software ou do serviço de informática

da instituição, é dificultado pelo conjunto de dados solicitados pelas entidades

reguladoras (mas com tendência a estabilizar). Um referiu que melhorou com a última

versão.

Vários serviços ultrapassam a não integração de algumas actividades do serviço

recorrendo a registos manuais em papel, a folhas de cálculo Excel e a outras aplicações.

Não permite o registo de colheitas de plaquetas por aférese, stem cells e outros.

Não permite criar pools de plaquetas, nem fazer pedidos electrónicos.


95

5.4.3 Responsabilidades de gestão do sistema informático

Quando inquiridos se o servidor do sistema informático é próprio ou partilhado, 17

(35,42%) responderam próprio e 31 (64,58%) partilhado.

Tabela 11 – Classificação do servidor de cada sistema, por tipo de serviço

Tipo de Serviço

Servidor

Partilhado Próprio Total

SMT 16 (33,33%) 7 (14,58%) 23 (47,92%)

SS + SMT 15 (31,25%) 7 (14,58%) 22 (45,83%)

SS (Proc. Ext.) + SMT 3 (6,25%) 3 (6,25%)

Total 31 (64,58%) 17 (35,42%) 48 (100,00%)

No que diz respeito à responsabilidade de gestão do hardware e do software dos sistemas

(Tabela 12), constatou‐se que na maior parte dos locais ocorre partilha de

responsabilidades ou delegação das mesmas nos serviços de informática da instituição ou

a empresas externas.

Tabela 12 ‐ Responsabilidade de gestão do hardware e do software

Responsabilidade de gestão

Fora do serviço Partilhada Do Serviço

Tipo de Serviço Hardware Software Hardware Software Hardware Software

SMT 11 (22,92%) 11 (22,92%) 10 (20,83%) 11 (22,92%) 2 (4,17%) 1 (2,08%)

SS + SMT 9 (18,75%) 7 (14,58%) 12 (25,00%) 14 (29,17%) 1 (2,08%) 1 (2,08%)

SS (Proc. Ext.) + SMT 3 (6,25%) 3 (6,25%)

Total 20 (41,67%) 18 (37,50%) 25 (52,08%) 28 (58,33%) 3 (6,25%) 2 (4,17%)

A quase totalidade dos serviços certificados ou com o processo em curso atribui as

responsabilidades de gestão do software e do hardware a elementos ou entidades

externas, total ou parcialmente (tabela 13).


96

Tabela 13 ‐ Responsabilidade de gestão do hardware e do software versus, estado de certificação dos serviços

Estado de certificação

Sim Processo em

Curso Não Já esteve Total

Responsabilidad

e de

gestão

do hardware Fora do serviço 15 (31,25%) 2 (4,17%) 2 (4,17%) 1 (2,08%) 20 (42,67%)

Partilhada 14 (29,17%) 6 (12,50%) 5 (10,42%)

25 (52,08%)

Serviço 1 (2,08%)

2 (4,17%)

3 (6,25%)

Total 30 (62,50%) 8 (16,67%) 9 (18,75%) 1 (2,08%) 48 (100,00%)

Responsabilidad

e de

gestão

do software Fora do serviço 14 (29,17%) 1 (2,08%) 2 (4,17%) 1 (2,08%) 18 (37,50%)

Partilhada 15 (31,25%) 7 (14,58%) 6 (12,50%)

28 (58,33%)

Serviço 1 (2,08%)

1 (2,08%)

2 (4,17%)

Total 30 (62,50%) 8 (16,67%) 9 (18,75%) 1 (2,08%) 48 (100,00%)

Dos 17 (35,42%) com servidor próprio, 15 (88,24%) têm a gestão do mesmo, partilhada ou

fora do serviço.

Tabela 14 ‐ Responsabilidade de gestão do hardware versus, tipo de servidor

Responsabilidade de gestão do hardware

Servidor

Partilhado Próprio Total

Fora do serviço 16 (33,33%) 4 (8,33%) 20 (41,67%)

Partilhada 14 (29,17%) 11 (22,92%) 25 (52,08%)

Serviço 1 (2,08%) 2 (4,17%) 3 (6,25%)

Total Geral 31 (64,58%) 17 (35,42%) 48 (100,00%)

É de referir que apenas 1 serviço assume a responsabilidade de gestão integral do

hardware e do software conjuntamente. (Tabela 15)

Vinte e dois assumem a partilha destas responsabilidades e 16 delegam completamente as

responsabilidades em entidades externas aos serviços.

Para os restantes 9 não se verifica a coincidência da atribuição de responsabilidades

relativamente ao hardware e software


97

Tabela 15 ‐ Responsabilidade de gestão do software versus, responsabilidade de gestão do hardware

Responsabilidade de gestão do software


Fora do serviço Partilhada Serviço Total

Fora do serviço 16 (33,33%) 2 (4,17%) 18 (37,50%)

Partilhada 4 (8,33%) 22 (45,83%) 2 (4,17%) 28 (58,33%)

Serviço 1 (2,08%) 1 (2,08%) 2 (4,17%)

Total 20 (41,67%) 25 (52,08%) 3 (6,25%) 48 (100,00%)

5.4.4 Segurança dos dados e dos equipamentos

Quando questionado sobre a capacidade de recuperação de informação e integridade dos

dados expressa com a questão ‐ “Estão definidas políticas para a realização de cópias de

segurança?”, apenas um SS + SMT respondeu não ter definido políticas para a realização

das mesmas. Este encontra‐se com processo de certificação em curso, partilha as

responsabilidades de gestão do hardware e do software e realizou cerca de 1 000 colheitas

e 1 000 transfusões em 2009.

Todos responderam afirmativamente à questão sobre a existência de definição de níveis

de acesso adequados ao tipo de operações.

À questão, “Existem protecções físicas dos equipamentos?”, 40 (93,02%) responderam

“SIM”, 3 SS (Proc. Ext.) + SMT (6,98%) responderam “NÃO” e 5 não sabem.


98

5.4.5 Registo e controlo de propostas e alterações ao sistema

Na tabela 16 verifica‐se que 43,75% dos inquiridos afirma que não realiza registos das

actividades relacionadas com propostas de melhoria do SI e suas interfaces. No entanto, na

tabela 17 constata‐se que 60,42% e 64,58% afirmaram não ter definidos procedimentos

para registo e controlo das alterações do hardware e software o que pode estar

provavelmente relacionado com a definição do que é um procedimento e registo

relacionado. Considerar por exemplo que as mensagens de correio electrónico que enviam

a comunicar problemas, ou a solicitar alterações, funcionam como registo. Estas

percentagens distribuem‐se uniformemente entre aqueles com responsabilidades de

gestão partilhadas ou fora do serviço.

Poder‐se‐á concluir que em 20 % dos casos em que são feitos registos estes terão uma

utilidade reduzida já que não estando sistematizados a sua análise será difícil.

Tabela 16 ‐ Registo das actividades relacionadas com as propostas de melhoria do SI e suas interfaces

Registo das actividades relacionadas com as propostas de melhoria

do SI e interfaces

Não Sim Total

SMT 13 (27,66%) 10 (21,28%) 23 (48,94%)

SS + SMT 7 (14,89%) 14 (29,79%) 21 (44,68%)

SS (Proc. Ext.) + SMT 1 (2,13%) 2 (4,26%) 3 (6,38%)

Total 21 (44,68%) 26 (55,32%) 47 (100,00%) * Um dos 48 inquiridos (2,08%) não soube responder, pelo que não foi contabilizado como resposta válida.

Tabela 17 ‐ Existência de procedimentos para registo e controlo das alterações ao hardware e ao software

Existência de procedimentos para registo e controlo das alterações

Hardware Software

Não Sim Total Não Sim Total

SMT 16 (34,04%) 7 (14,89%) 23 (48,94%) 17 (35,42%) 6 (12,50%) 23 (47,92%)

SS + SMT 10 (21,28%) 11 (23,40%) 21 (44,68%) 11 (22,92%) 11 (22,92%) 22 (45,83%)

SS (Proc. Ext.) + SMT 3 (6,38%) 3 (6,38%) 3 (6,25%) 3 (6,25%)

Total 29 (61,70%) 18 (38,30%) 47 (100,00%) 31 (64,58%) 17 (35,42%) 48 (100,00%)* Um dos 48 inquiridos (2,08%) não soube responder relativamente ao hardware, pelo que não foi

contabilizado como resposta válida.


99

Mesmo quando a responsabilidade de gestão do hardware é pelo menos partilhada pelos

serviços, isso não parece influenciar positivamente a existência de procedimentos para

registo e controlo do mesmo. (tabela 18)

Tabela 18 ‐ Responsabilidade de gestão do hardware versus, existência de procedimentos para registo e controlo do hardware


Procedimentos para registo e controlo do hardware

Não Sim Total

Fora do serviço 10 (21,28%) 10 (21,28%) 20 (42,55%)

Partilhada 18 (38,30%) 6 (12,77%) 24 (51,06%)

Serviço 1 (2,13%) 2 (4,26%) 3 (6,38%)

Total 29 (61,70%) 18 (38,30%) 47 (100,00%)

* Um dos 48 inquiridos (2,08%) não soube responder, pelo que não foi contabilizado como resposta válida.

O desconhecimento da existência de protecções físicas dos equipamentos distribui‐se por

todas as classes de responsabilidade de gestão do hardware, sendo superior quando esta

responsabilidade é exclusivamente externa ao serviço.

Tabela 19 ‐ Responsabilidade de gestão do hardware versus, existência de protecções físicas dos equipamentos

Existência de protecções físicas dos equipamentos

Responsabilidade de gestão do hardware Não Sim Total

Fora do serviço 17 (39,53%) 17 (39,53%)

Partilhada 3 (6,98%) 21 (48,84%) 24 (55,81%)

Serviço 2 (4,65%) 2 (4,65%)

Total 3 (6,98%) 40 (93,02%) 43 (100,00%)

* Cinco (10,42%) dos inquiridos não souberam responder relativamente à existência de protecções físicas dos

equipamentos, pelo que não foram contabilizados como respostas válidas.

A existência de procedimentos para registo e controlo do hardware e do software, além de

ser pouco frequente, não é coincidente em todos os serviços.

Tabela 20 – Existência de procedimentos para registo e controlo do hardware versus, existência de procedimentos para registo e controlo do software

Procedimentos para registo e controlo do hardware

Procedimentos para registo e controlo do software

Não Sim Total

Não 27 (57,45%) 2 (4,26%) 29 (61,70%)

Sim 3 (6,38%) 15 (31,91%) 18 (38,30%)

Total 30 (63,83%) 17 (36,17%) 47 (100,00%) * Um dos 48 inquiridos (2,08%) não sabe se tem procedimentos para registo e controlo do hardware e não tem

para o software, pelo que não foi contabilizado como resposta válida.


100

Tabela 21 ‐ Existência de procedimentos para registo e controlo do hardware versus, existência de protecções físicas dos equipamentos

Procedimentos registo e controlo do hardware


Não Sim Total

Não 3 (7,14%) 22 (52,38%) 25 (59,52%)

Sim 17 (40,48%) 17 (40,48%)

Total Geral 3 (7,14%) 39 (92,86%) 42 (100,00%) * Cinco (10,42%) dos inquiridos não sabem se existem protecções físicas dos equipamentos e um não sabe se

existem procedimentos de registo e controlo do hardware, pelo que não foram contabilizados como respostas

válidas.

As frequências verificadas na tabela 22 revelam que, os serviços envolvidos em actividades

de certificação parecem estar mais informados relativamente à necessidade de existência

de protecções físicas dos equipamentos.

Tabela 22 – Estado de certificação dos serviços versus, existência de protecções físicas dos equipamentos


Estado de certificação Não Sabe Não Sim Total

Sim 2 (4,17%) 2 (4,17%) 26 (54,17%) 30 (62,50%)

Processo em Curso 2 (4,17%) 1 (2,08%) 5 (10,42%) 8 (16,67%)

Não 1 (2,08%) 8 (16,67%) 9 (18,75%)

Já esteve 1 (2,08%) 1 (2,08%)

Total 5 (10,42%) 3 (6,25%) 40 (83,33%) 48 (100,00%)

Dos serviços certificados 36,67% não fazem registo das actividades relacionadas com as

propostas de melhoria do sistema informático e suas interfaces, enquanto esta frequência

é de 77,78% nas instituições não certificadas.

O estado de certificação dos serviços não parece influenciar a existência de procedimentos

para registo e controlo do hardware e do software.


101

Tabela 23 ‐ Registo das actividades relacionadas com as propostas de melhoria do SI e suas interfaces, Existência de procedimentos para registo e controlo do hardware e do software versus, estado de certificação dos serviços


Sim Processo em


Registo das actividades relacionadas

com as propostas de

melhoria do SI e suas interfaces

Sim 19 (39,58%) 5 (10,42%) 2 (4,17%)

26 (54,17%)

Não 11 (22,92%) 2 (4,17%) 7 (14,58%) 1 (2,08%) 21 (43,75%)

Não Sabe

1 (2,08%)

1 (2,08%)

Total 30 (62,50%) 8 (16,67%) 9 (18,75%) 1 (2,08%) 48 (100,00%)

Existência de procedimentos para registo e controlo do hardware

Não 18 (37,50%) 4 (8,33%) 6 (12,50%) 1 (2,08%) 29 (60,42%)

Sim 12 (25,00%) 3 (6,25%) 3 (6,25%)

18 (37,50%)

Não Sabe

1 (2,08%)

1 (2,08%)

Total 30 (62,50%) 8 (16,67%) 9 (18,75%) 1 (2,08%) 48 (100,00%)

Existência de procedimentos para registo e controlo do software

Não 18 (37,50%) 5 (10,42%) 7 (14,58%) 1 (2,08%) 31 (64,58%)

Sim 12 (25,00%) 3 (6,25%) 2 (4,17%)

17 (35,42%)

Total 30 (62,50%) 8 (16,67%) 9 (18,75%) 1 (2,08%) 48 (100,00%)

5.4.6 Rastreabilidade dos processos

Dos 25 serviços que realizam colheitas, apenas 2 consideram que o seu sistema não

assegura a rastreabilidade de todos os processos relacionados com cada colheita. No

entanto, quando questionados relativamente às actividades do serviço que não estão

integradas no sistema informático 20 destes inquiridos mencionaram pelo menos 1

actividade.


102

Tabela 24 ‐ Capacidade dos sistemas para assegurar a rastreabilidade de todos os processos relacionados com cada colheita e transfusão

Rastreabilidade de todos os processos

Colheita Transfusão

Tipo de serviço e software

Não Sim Total Não Sim Total

SMT 2 (8,33%) 21 (43,75%) 23 (47,92%)

ASIS 1 (2,08%) 10 (20,83%) 11 (22,92%)

SIBAS 6 (12,50%) 6 (12,50%)

IMAGINASOFT 1 (2,08%) 1 (2,08%)

ClinidataBST 1 (2,08%) 1 (2,08%)

DELPHYN 1 (2,08%) 1 (2,08%)

e‐DELPHYN 1 (2,08%) 1 (2,08%)

NOVA HIS 1 (2,08%) 1 (2,08%)

ROCAIL 1 (2,08%) 1 (2,08%)

SS (Proc. Ext.) + SMT 3 (12,00%) 3 (12,00%) 3 (6,25%) 3 (6,25%)

SIBAS 3 (12,00%) 3 (12,00%) 3 (6,25%) 3 (6,25%)

SS + SMT 2 (8,00%) 20 (80,00%) 22 (88,00%) 3 (6,25%) 19 (39%) 22 (45,83%)

SIBAS 10 (40,00%) 10 (40,00%) 10 (20,83%) 10 (20,83%)

ASIS 1 (4,00%) 8 (32,00%) 9 (36,00%) 2 (4,17%) 7 (14,58%) 9 (18,75%)

IMAGINASOFT 1 (4,00%) 1 (4,00%) 2 (8,00%) 1 (2,08%) 1 (2,08%) 2 (4,17%)

PELICANO 1 (4,00%) 1 (4,00%) 1 (2,08%) 1 (2,08%)

Total 2 (8,00%) 23 (92,00%) 25 (100,00%) 5 (10,42%) 43 (89,58%) 48 (100,00%)

Dos 25 serviços que realizam colheitas, 16 (64,00%) estão certificados. Dos serviços

certificados que realizam colheitas, 2 (12,50%) consideram que o SI não lhes assegura

rastreabilidade de todos os processos relacionados com a colheita e 1 destes afirmou ter o

sistema validado.

Dos 30 serviços certificados, 5 (16,67%) consideram que o SI não lhes assegura

rastreabilidade de todos os processos relacionados com a transfusão e 1 deles considera

ter o sistema validado.

Estes serviços referiram ser necessário recorrer a alternativas complementares, como

registos manuais, para cumprirem com os normativos legais.


103

5.4.7 Estado, actividades e competências relacionadas com a validação destes

sistemas

Relativamente às questões sobre validação, foi possível detectar dúvidas e mesmo

desconhecimento dos conceitos de sistema informático e de validação, tendo nestes casos

sido explicados os conceitos associados.

Tabela 25 – Desenvolvimento nos serviços de actividades para validação dos sistemas informáticos

Tipo de serviço

Desenvolvimento de actividades para validação dos SI

Não Sabe Não Sim Total

SMT 1 (2,08%) 18 (37,50%) 4 (8,33%) 23 (47,92%)

SS + SMT 15 (31,25%) 7 (14,58%) 22 (45,83%)

SS (Proc. Ext.) + SMT 3 (6,25%) 3 (6,25%)

Total 1 (2,08%) 36 (75,00%) 11 (22,92%) 48 (100,00%)

Dos 47 inquiridos que souberam responder, 76,60 % não esteve nem está envolvido em

actividades de validação não sendo esta situação conforme com o expectável para

aplicação do normativo legal em vigor.

Tabela 26 ‐ Estado de validação dos sistemas automáticos ligados ao sistema informático

Estado de validação dos sistemas automáticos

Tipo de serviço Não Sim Total

SMT 5 (11,91%) 13 (30,95%) 18 (42,86%)

SS + SMT 3 (7,14%) 18 (42,86%) 21 (50,00%)

SS (Proc. Ext.) + SMT 2 (4,76%) 1 (2,38%) 3 (7,14%)

Total 10 (23,81%) 32 (76,19%) 42 (100,00%)

A diferença no total da tabela 26 em relação ao número total de inquéritos deve‐se a que

seis inquiridos não utilizam equipamentos automáticos para realização dos testes

laboratoriais, pelo que não consideraram que esta questão lhes era aplicável, e assim não

foram contabilizados.


104

Tabela 27 ‐ Estado de Validação dos Sistemas Informáticos

Estado de validação dos SI

Tipo de serviço e software Não Sabe Não Sim Total

SMT 18 (37,50%) 5 (10,42%) 23 (47,92%)

ASIS 9 (18,75%) 2 (4,17%) 11 (22,92%)

SIBAS 5 (10,42%) 1 (2,08%) 6 (12,50%)

IMAGINASOFT 1 (2,08%) 1 (2,08%)

e‐DELPHYN 1 (2,08%) 1 (2,08%)

NOVA HIS 1(2,08%) 1 (2,08%)

ROCAIL 1 (2,08%) 1 (2,08%)

ClinidataBST 1 (2,08%) 1 (2,08%)

DELPHYN 1 (2,08%) 1 (2,08%)

SS (Proc. Ext.) + SMT 3 (6,25%) 3 (6,25%)

SIBAS 3 (6,25%) 3 (6,25%)

SS + SMT 1 (2,08%) 15 (31,25%) 6 (12,50%) 22 (45,83%)

ASIS 8 (16,67%) 1 (2,08%) 9 (18,75%)

SIBAS 1 (2,08%) 5 (10,42%) 4 (8,33%) 10 (20,83%)

IMAGINASOFT 1 (2,08%) 1 (2,08%) 2 (4,17%)

PELICANO 1 (2,08%) 1 (2,08%)

Total 36 (75,00%) 11 (22,92%) 48 (100,00%)

Tabela 28 ‐ Previsão de Validação dos Sistemas não Validados

Se está previsto validar os SI não validados

Tipo de serviço Não Sabe Não Sim Total

SMT 2 (5,41%) 8 (21,62%) 8 (21,62%) 18 (48,65%)

SS + SMT 10 (27,03%) 6 (16,22%) 16 (43,24%)

SS (Proc. Ext.) + SMT 2 (5,41%) 1 (2,70%) 3 (8,11%)

Total 2 (5,41%) 20 (54,05%) 15 (40,54%) 37 (100,00%)

Tabela 29 ‐ Premência atribuída à validação dos sistemas informáticos

Tipo de serviço

Premência (de 0 ‐ nenhuma a 5 ‐ máxima) Não sabe Total 0 1 2 3 4 5

SMT 1 (2,08%) 6 (12,50%) 9 (18,75%) 7 (14,58%) 23 (47,92%)

SS + SMT 1 (2,08%) 13 (27,08%) 7 (14,58%) 1 (2,08%) 22 (45,83%)

SS (Proc. Ext.) + SMT 2 (4,17%) 1 (2,08%) 3 (6,25%)

Total 2 (4,17%) 1 (2,08%) 8 (16,67%) 22 (45,83%) 14 (29,17%) 1 (2,08%) 48 (100,00%)


105

Tabela 30 ‐ Existência nos serviços de recursos próprios que permitam fazer a validação do SI

Existência de recursos para validação do SI

Tipo de serviço Não Sabe Não Sim Total

SMT 1 (2,08%) 11 (22,92%) 11 (22,92%) 23 (47,92%)

SS + SMT 1 (2,08%) 14 (29,17%) 7 (14,58%) 22 (45,83%)

SS (Proc. Ext.) + SMT 3 (6,25%) 3 (6,25%)

Total 2 (4,17%) 28 (58,33%) 18 (37,50%) 48 (100,00%)

Tabela 31 – Motivos da não existência nos serviços de recursos próprios que permitam fazer a validação do sistema informático

Motivos da não existência de recursos próprios para validar os SI

Tipo de serviço

Falta de formação na

área

Falta de recursos humanos

Falta de formação na área e de recursos humanos

Não Responde Não Sabe Total

SMT 1 (3,57%) 2 (7,14%) 7 (25,00%) 1 (3,57%) 11 (39,29%)

SS + SMT 1 (3,57%) 1 (3,57%) 12 (42,86%) 14 (50,00%)

SS (Proc. Ext.) + SMT 1 (3,57%) 2 (7,14%) 3 (10,71%)

Total 2 (7,14%) 3 (10,71%) 20 (71,43%) 2 (7,14%) 1 (3,57%) 28 (100,00%)

Em relação à tabela 32 é de realçar 1 SMT que utiliza o ASIS, que sugeriu a realização de

acções de formação pelo IPS dirigidas aos profissionais de Imuno‐hemoterapia.

Tabela 32 – Soluções apresentadas para validação dos sistemas informáticos, pelos serviços sem recursos próprios para a sua realização

Soluções apresentadas pelos serviços sem recursos

para validação dos SI

Tipo de serviçoNão

Responde

Formação dos RH na

área

IPS e Serviço Informática da Instituição

Outros Serviços da Instituição

Recursos Externos Total

SMT 2 (7,14%) 1 (3,57%) 4 (14,29%) 3 (10,71%) 10 (35,71%)

SS + SMT 1 (3,57%) 5 (17,86%) 9 (32,14%) 15 (53,57%)

SS (Proc. Ext.) + SMT 2 (7,14%) 1 (3,57%) 3 (10,71%)

Total 2 (7,14%) 3 (10,71%) 1 (3,57%) 10 (35,71%) 12 (42,86%) 28 (100,00%)

Na tabela 33 em que se analisa o estado de validação realçam‐se os seguintes aspectos:

Dois SS (Proc. Ext.) + SMT não vêem necessidade de validar o sistema.

Dos 30 serviços certificados 20 (68,97%) não têm o sistema informático validado e 1

não sabe. Dos 18 serviços não certificados 2 (11,11%) afirmaram ter o sistema

informático validado.


106

Relativamente ao desenvolvimento de actividades para validação do sistema, as

respostas obtidas foram idênticas às do estado de validação.

De 28 serviços certificados com sistema automáticos ligados ao sistema informático, 6

(21,43%) consideram não ter os sistemas automáticos validados, enquanto dos 14

serviços não certificados que utilizam sistemas automáticos, 10 (71,43%) têm esses

sistemas validados e 4 (28,57%) não.

Dos 37 serviços que não têm os SI validados, 15 (40,54%) têm previsto validar (8 dos

quais estão certificados). Nos 20 que não têm previsto fazer a validação do SI incluem‐

se 12 certificados e 5 não certificados e 3 com o processo em curso.

Um serviço certificado não sabe se tem o SI validado.

Tabela 33 – Estado de validação dos SI, realização ou desenvolvimento de actividades para validação do SI, estado de validação dos sistemas automáticos ligados ao SI e previsão de validação dos SI versus, estado de certificação dos serviços


Sim Processo em


Estado de validação dos SI

Não 20 (41,67%) 7 (14,58%) 8 (16,67%) 1 (2,08%) 36 (75,00%)

Sim 9 (18,75%) 1 (2,08%) 1 (2,08%) 11 (22,92%)

Não Sabe 1 (2,08%) 1 (2,08%)

Total 30 (62,50%) 8 (16,67%) 9 (18,75%) 1 (2,08%) 48 (100,00%)

Realização ou desenvolvimento de actividades para validação do SI

Não 20 (41,67%) 7 (14,58%) 8 (16,67%) 1 (2,08%) 36 (75,00%)

Sim 9 (18,75%) 1 (2,08%) 1 (2,08%) 11 (22,92%)

Não Sabe 1 (2,08%) 1 (2,08%)

Total 30 (62,50%) 8 (16,67%) 9 (18,75%) 1 (2,08%) 48 (100,00%)

Estado de validação dos sistemas automáticos ligados ao SI

Não 6 (14,29%) 1 (2,38%) 3 (7,14%) 10 (23,81%)

Sim 22 (52,38%) 6 (14,29%) 3 (7,14%) 1 (2,38%) 32 (76,19%)

Total 28 (66,67%) 7 (16,67%) 6 (14,29%) 1 (2,38%) 42 (100,00%)

Previsão de validação dos SI

Não 12 (32,43%) 3 (8,11%) 5 (13,51%) 20 (54,05%)

Sim 8 (21,62%) 4 (10,81%) 2 (5,41%) 1 (2,70%) 15 (40,54%)

Não Sabe 1 (2,70%) 1 (2,70%) 2 (5,41%)

Total 21 (56,76%) 7 (18,92%) 8 (21,62%) 1 (2,70%) 37 (100,00%)

De 32 serviços que afirmam ter os sistemas automáticos ligados ao SI, apenas 9 (28,13%)

dizem ter o SI validado e 1 não sabe.

Dos 6 serviços que não têm sistemas automáticos ligados ao SI (serviços de menor

dimensão), apenas 1 tem o SI validado.


107

Tabela 34 ‐ Estado de validação dos sistemas automáticos ligados ao SI versus, estado de validação dos SI

Estado de validação dos sistemas automáticos ligados ao SI

Estado de validação do SI

Não Sim Não Sabe Total

Não 9 (18,75%) 1 (2,08%) 10 (20,83%)

Sim 22 (45,83%) 9 (18,75%) 1 (2,08%) 32 (66,67%)

Não aplicável 5 (10,42%) 1 (2,08%) 6 (12,50%)

Total 36 (75,00%) 11 (22,92%) 1 (2,08%) 48 (100,00%)

Os serviços certificados e os serviços que afirmaram ter os SI validados têm tendência a

atribuir níveis de premência mais elevados à validação. Apesar disso, salienta‐se o facto de

2 serviços certificados que não têm o SI validado atribuírem o nível zero (tabela 35).

Tabela 35 – Estado de certificação dos serviços, estado de validação dos SI e previsão de validação dos SI versus, premência atribuída à validação dos SI

Premência que atribuída à validação dos SI

0 2 3 4 5 Não sabe Total

Estado de

certificação

Sim 2 (4,17%) 4 (8,33%) 15 (31,25%) 8 (16,67%) 1 (2,08%) 30 (62,50%)

Processo em Curso

1 (2,08%) 2 (4,17%) 5 (10,42%)

8 (16,67%)

Não 1 (2,08%) 3 (6,25%) 4 (8,33%) 1 (2,08%) 9 (18,75%)

Já esteve 1 (2,08%) 1 (2,08%)

Total 2 (4,17%) 1 (2,08%) 8 (16,67%) 22 (45,83%) 14 (29,17%) 1 (2,08%) 48 (100,00%)

Estado de

valid

ação

dos SI

Não 2 (4,17%) 1 (2,08%) 7 (14,58%) 17 (35,42%) 9 (18,75%) 36 (75,00%)

Sim 1 (2,08%) 5 (10,42%) 5 (10,42%) 11 (22,92%)

Não sabe 1 (2,08%) 1 (2,08%)

Total 2 (4,17%) 1 (2,08%) 8 (16,67%) 2 (4,17%) 14 (29,17%) 1 (2,08%) 48 (100,00%)

Previsão da

valid

ação

Não 2 (5,41%) 1 (2,70%) 4 (10,81%) 9 (24,32%) 3 (8,11%) 1 (2,70%) 20 (54,05%)

Sim 3 (8,11%) 6 (16,22%) 6 (16,22%) 15 (40,54%)

Não sabe 2 (5,41%) 2 (5,41%)

Total 2 (5,41%) 1 (2,70%) 7 (18,92%) 17 (45,95%) 9 (24,32%) 1 (2,70%) 37 (100,00%)

Dos 11 serviços com SI validado, 7 consideram ter recursos próprios para fazer a validação,

3 consideram não ter e 1 não sabe.

Dos 36 que não têm o SI validado, 25 (69,44%) consideram não ter recursos próprios para

realizar essa actividade.

Tabela 36 ‐ Existência de recursos próprios para validar os SI versus, estado de validação dos SI

Existência no serviço de recursos próprios que permitam fazer a validação dos SI

SI validado?

Não Sim Não sabe Total

Não 25 (52,08%) 3 (6,25%) 28 (58,33%)

Sim 11 (22,92%) 7 (14,58%) 18 (37,50%)

Não sabe 1 (2,08%) 1 (2,08%) 2 (4,17%)

Total 36 (75,00%) 11 (22,92%) 1 (2,08%) 48 (100,00%)


108

Comparando a existência de recursos próprios para validar com estar ou não certificado

verifica‐se que, dos 18 (37,50%) que responderam afirmativamente à existência de

recursos, 12 (66,67%) estão certificados. Dos 28 (58,33%) que responderam

negativamente, 16 (57,14%) estão certificados.

A associação dos factores “falta de formação na área e de recursos humanos” salienta‐se

como a causa principal para os serviços considerarem que não possuem recursos próprios

para realizar a validação, independentemente de estarem certificados.

Tabela 37 ‐ Existência de recursos próprios para validar os SI, motivos para a falta de recursos próprios para validar os SI e soluções apresentadas para resolver a falta de recursos versus, estado de certificação dos serviços


Sim Processo em


Existência no serviço

de recursos próprios

que perm

itam

fazer a

valid

ação

dos SI

Não 16 (33,33%) 7 (14,58%) 4 (8,33%) 1 (2,08%) 28 (58,33%)

Sim 12 (25,00%) 1

(2,08%) 5

(10,42%) 18 (37,50%)

Não sabe 2 (4,17%)

2 (4,17%)

Total 30 (62,50%) 8 (16,67%) 9 (18,75%) 1 (2,08%) 48 (100,00%)

Motivos para a falta de recursos para

valid

ar os SI

Falta de formação na área

2 (7,14%)

2 (7,14%)


10 (35,71%) 7 (25,00%) 2 (7,14%) 1 (3,57%) 20 (71,43%)


1 (3,57%)

2 (7,14%)

3 (10,71%)

Não responde 2 (7,14%)

2 (7,14%)

Não sabe 1 (3,57%)

1 (3,57%)

Total 17 (60,71%) 7 (25,00%) 4 (14,29%) 1 (3,57%) 28 (100,00%)

Soluções ap

resentadas para resolver a

falta de recursos

Recursos Externos 6 (21,43%) 2 (7,14%) 3 (10,71%) 1 (3,57%) 12 (42,86%)


5 (17,86%) 4 (14,29%) 1 (3,57%)

10 (35,71%)

Formação dos RH na área

2 (7,14%) 1 (3,57%)

3 (10,71%)

IPS e Serviço de Informática da Instituição

1 (3,57%)

1 (3,57%)

Não responde 2 (7,14%)

2 (7,14%)

Total 16 (57,14%) 7 (25,00%) 4 (14,29%) 1 (3,57%) 28 (100,00%)


109

As principais soluções propostas para resolver a necessidade de validar os sistemas

informáticos são recorrer a recursos externos 12 (42,86%) ou a outros serviços da

instituição 10 (35,71%). Apenas 3 serviços apontaram como solução formar os recursos

humanos que dispõem para esse fim.

5.5 Discussão

O presente trabalho de diagnóstico da situação não tem antecedentes identificados em

termos de referências, pelo que a sua estruturação levantou algumas dificuldades.

Pensando ter obviado à variabilidade entre observadores implementando um questionário

que foi aplicado por um único entrevistador, houve algumas questões que tiverem que ser

sucessivamente melhoradas de modo a obter a compreensão da maior parte dos

participantes. Este aspecto também se relacionou com a procura de interlocutores válidos

para responder de um modo completo a perguntas que por um lado se situam na área dos

Sistema de informação mas se relacionam estreitamente com normativos legais de

Medicina Transfusional. Muitos dos dados obtidos sobre as responsabilidades e actividades

realizadas revelam provavelmente a necessidade de melhorar a interacção entre Serviços

de Sangue / Medicina Transfusional e Serviços de Informática.

A sistematização das organizações também se manifestou complexa e para lá de dificultar

a gestão adequada dos sistemas informáticos, condicionou provavelmente algumas das

respostas. Este factor, quando associado a um ambiente de “secretismo”, de desconfiança

e falta de transparência dificultou também a realização do diagnóstico da situação.

Quanto à caracterização das instituições e dos serviços, constatou‐se existir

heterogeneidade tanto pela dimensão, como pela organização institucional e ainda quanto

ao nível dos utilizadores e das suas expectativas. Da caracterização dos serviços, é possível

verificar que os sistemas informáticos utilizados têm que suportar números de registos

anuais que podem variar entre as poucas centenas e as centenas de milhar, e gerir um

número de utilizadores que pode alcançar as centenas.

A frequência de serviços certificados e com o processo de certificação em curso parecem

ser indicativas da repercussão do quadro legislativo e da importância que a qualidade e a

segurança têm nesta área de actividade. As expectativas e exigências no que respeita à

qualidade e segurança dos sistemas informáticos são por consequência também elevadas,


110

o que é evidenciado pelos comentários feitos pelos utilizadores ao sistema que utilizam e

melhor conhecem.

Foram identificados nove softwares diferentes em utilização nos serviços abrangidos pelo

inquérito, havendo no entanto um predomínio da utilização de três deles.

Apesar de existir na prática liberdade de escolha e de configuração dos sistemas, o

acentuar da convergência para os três softwares predominantes tem sem dúvida origem

em factores que vão desde exigências de qualidade e segurança já referidas, mas também

factores de ordem económica, não desprezíveis pelas organizações, e outros de ordem

técnica e prática como é o caso da interoperabilidade entre sistemas.

Os servidores utilizados pelos sistemas são na sua maioria partilhados, o que se

compreende pelo volume de transacções realizadas por muitos, que não justificam o custo

de aquisição e manutenção de um servidor próprio e dos meios para assegurar a sua

segurança.

Os serviços parecem reconhecer as suas limitações para efectuar a análise e controlo do

seu software e hardware o que é manifesto pela uma percentagem elevada de delegação

de responsabilidades de gestão dos SI, ou então, as políticas de gestão definidas a um nível

organizacional superior a isso obrigam. Falta no entanto esclarecer se tal delegação se faz

de um modo informado tanto para quem delega como para quem assume.

O estado de certificação não parece influenciar a necessidade dos serviços assumirem a

responsabilidade de gestão do hardware e software utilizados. Mesmo a existência de

servidor próprio não parece afectar a responsabilidade de gestão do mesmo.

Em 18,75% dos serviços as responsabilidades de gestão do hardware e do software não

são coincidentes, o que parece demonstrar a falta de sensibilidade para reconhecer a

importância da interacção entre hardware e software.

Quanto à segurança dos dados e equipamentos as 4 questões colocadas permitiram saber

que apenas 1 serviço, com processo de certificação em curso, não tem políticas definidas

para realização de cópias de segurança. Esta situação expressa o incumprimento com a

obrigação legal de manutenção dos registos que permitam a rastreabilidade total durante

30 anos, já que o que é estabelecido não é a minimização do risco de perda de informação,

mas sim a realização dos procedimentos de cópia.


111

Todos têm definidas políticas para a segurança de acessos aos dados. No entanto, a

frequência de serviços que não têm protecções físicas dos equipamentos, ou desconhecem

se têm, é de 16,67%.

O delegar da gestão dos sistemas informáticos não é acompanhado da evidência de um

maior controlo dos processos e do sistema, através de procedimentos para registo e

controlo das alterações, mesmo quando se trata de instituições certificadas em que o

conceito de SI como equipamento não á aplicado.

Mesmo nas instituições certificadas parece haver desconhecimento sobre os requisitos e

práticas base para a validação e manutenção do estado de validação dos sistemas

informáticos.

Relativamente ao assegurar da rastreabilidade de todos os processos as opiniões divergem

mesmo quando os serviços utilizam o mesmo software.

Dois dos serviços consideram que o SI não lhes assegura rastreabilidade de todos os

processos relacionados com a colheita e 5 com a transfusão, sendo necessário

complementar os registos com procedimentos manuais, o que sem dúvida implica menor

eficiência e provavelmente menores garantias de segurança nos processos. No entanto ao

analisar os serviços que não têm todas as áreas de actividade cobertas, estes são em

número de 20. Esta incongruência aponta para que a rastreabilidade não seja atingida em

muitos mais sistemas do que os dois que o referiram.

Relativamente às questões sobre validação, foi possível detectar dúvidas e mesmo

desconhecimento dos conceitos de sistema informático e de validação.

Dos 48 serviços questionados, 11 (24,4%) referiram ter o SI validado e 76,60% não

estiveram nem estão envolvidos em actividades de validação não sendo esta situação

conforme com o expectável para aplicação do normativo legal em vigor. Curiosamente um

serviço certificado não sabe se tem o SI validado e outro serviço tendo o SI validado

afirmou não ter os sistemas automáticos validados.

Afirmaram não ter o sistema informático validado 20 (68,97%) dos 30 serviços certificados

e 16 (88,88%) dos 18 serviços não certificados. Em relação a este tema foi possível

identificar várias situações discrepantes com o desejável:

Serviços que não desenvolvem actividades para validação do SI utilizado,


112

Serviços cujos sistemas automáticos ligados ao SI não estão validados,

Sistemas informáticos não validados, situação agravada pelo facto de se verificar em

serviços certificados e em que não está prevista a validação.

Reconhecimento da importância da validação mas sem previsão de validar o SI,

A premência atribuída à validação variou essencialmente entre média (nível 3) a muito alta

(nível 5), tendo o nível 4 registado cerca de 45% das respostas.

O principal motivo para o estado de não validação dos sistemas parece ser a não existência

de recursos próprios suficientes para validar os SI (58%). As principais causas identificadas

para a falta de recursos serão a falta de formação na área e de recursos humanos,

associadas. As principais soluções apontadas para resolver a necessidade de validação dos

sistemas informáticos serão a contratação de recursos externos ou recorrer aos serviços de

informática da instituição.

O estado de certificação dos serviços não parece influenciar positivamente a realização de

actividades relacionadas com a validação, nem o estado de validação dos SI. Estas parecem

estar mais condicionadas pela insuficiência de recursos para a sua realização.

Salienta‐se a tendência de os serviços certificados e os serviços que afirmaram ter os SI

validados atribuir níveis de premência mais elevados à validação. No entanto, 2 serviços

certificados que não têm o SI validado atribuíram o nível de premência zero.

Os dados obtidos sobre as actividades não cobertas e os respectivos comentários,

induzem‐nos a pensar que dentro de uma organização a comparação negativa com outras

aplicações não é justificável, devendo sim ser implementadas medidas de correcção e

melhoria se possível obedecendo a requisitos de autoridades reguladoras.

Sendo o controlo do Software e do Hardware condição básica para as actividades dos

serviços, sendo inclusive considerados dispositivos médicos quando aplicados à prática

transfusional, duvida‐se que a maior parte deles consiga fazer este controlo, pela ausência

verificada numa frequência importante de serviços sem controlo e registo das alterações

ao software e ao hardware.


113

6. Conclusões e Recomendações

As actividades de validação têm evoluído paralelamente com a complexidade dos sistemas,

com o risco associado e ainda com a generalização dos princípios básicos da Qualidade. Na

área da Medicina Transfusional a cultura de validação de Sistemas Informáticos não está

ainda suficientemente enraizada. No entanto existem sinais de que a importância e

atenção dadas pelos profissionais desta área a esta temática estão a aumentar, motivado

tanto por razões legais como pela evolução do estado da arte. Obviamente que as razões

da não validação sistemática destes sistemas tem causas multi‐factoriais:

As entidades reguladoras não estabeleceram ainda um quadro claro de validação.

Muitos dos Serviços de Sangue e de Medicina Transfusional não possuem recursos para

realizar estas actividades

Os profissionais da Medicina envolvidos nesta área não dominam completamente os

conhecimentos da informática, nem os profissionais de informática dominam

completamente todas as dimensões deste tema.

Assim e neste contexto, parece‐nos que o estabelecimento de um consenso em relação

aos requisitos mínimos a cumprir para a validação, seria o primeiro passo a atingir,

podendo o presente trabalho ser um ponto de partida para este fim. A formação de

equipas multidisciplinares, de âmbito geográfico e institucional a definir, integrando

Profissionais das áreas médica, informática e outras, será também um contributo para que

tal processo possa ser implementado.

Também a formação em Informática e em particular daquela que se relaciona mais

directamente com a Medicina Transfusional, conjugando conhecimentos das diferentes

áreas, pode e deve ajudar a resolver as necessidades existentes, contribuindo para a

melhoria da qualidade e aumento da segurança transfusional.

A criação de entidades externas de regime público ou privado, que possam apoiar o

processo de validação nas instituições, estando condicionado pelos pressupostos

anteriores, poderá ser uma resposta para a falta de recursos e formação. Para lá da

divulgação de conceitos e da prática da validação, a especialização destas entidades

permitirá obter benefícios em termos de eficiência e sinergia: menor tempo para atingir a

validação, menor dispêndio de recursos em actividades relacionadas e formação. Poderão


114

ainda os serviços utilizadores, ter definido para lá dos requisitos mínimos os seus próprios,

acrescentando valor ao processo de validação.


115

7. Trabalho futuro

Propomo‐nos a divulgar os resultados do inquérito e o trabalho realizado, tanto a nível dos

Serviços de Sangue como de Medicina Transfusional que foram contactados para a

realização do inquérito. Propomo‐nos ainda a fazer esta divulgação às entidades

reguladoras.

Serão promovidas acções de formação, no âmbito das actividades desenvolvidas pela

formação do Instituto Português do Sangue, I.P. a profissionais da área que terão como

objectivo a divulgação de conceitos em informática e validação de Sistemas aplicáveis à

Medicina Transfusional.

A breve prazo será feita a aplicação do modelo proposto, a uma instituição com o objectivo

do seu teste. Com base nos resultados obtidos, serão provavelmente introduzidas

alterações para a sua melhoria e proposta formação nas necessidades formativas que

forem identificadas.

Posteriormente tentar‐se‐á compatibilizar o presente modelo, com alguns padrões

referências de qualidade já existentes (ultrapassando assim o estabelecimento de um

modelo mínimo).


116

8. Referências

AABB (2008). Technical Manual. Bethesda, Md., American Association of Blood Banks. Andriole, S. J. (1986). Software Validation, Verification, Testing and Documentation: A

Source Book. Princeton, NJ, USA, Petrocelli Books, Inc. ASST (2008). Circular Normativa n.º 6/GDG de 23 de Junho de 2008. Requisitos em Matéria

de Análise das Dádivas de Sangue Colhidas. Autoridade para os Serviços de Sangue e da Transplantação. 6/GDG.

BCSH (1999). "The administration of blood and blood components and the management of transfused patients. British Committee for Standards in Haematology, Blood Transfusion Task Force. Royal College of Nursing and the Royal College of Surgeons of England." Transfus Med 9(3): 227‐238.

BCSH (2007). "The specification and use of information technology systems in blood transfusion practice. Working Party of the British Committee for Standards in Haematology Blood Transfusion Task Force." Transfusion Medicine.

BCSH, P. Ashford, et al. (2000). "Guidelines for blood bank computing. Working Party of the British Committee for Standards in Haematology, Blood Transfusion Task Force." Transfus Med 10(4): 307‐314.

BCSH, J. F. Chapman, et al. (2004). "Guidelines for compatibility procedures in blood transfusion laboratories. Working Party of the British Commitee for Standards in Haematology Blood Transfusion Task Force." Transfus Med 14(1): 59‐73.

Clegg, D. and R. Barker (1994). Case Method Fast‐Track: A RAD Approach, Addison‐Wesley Pub. Co.

Council of Europe. (2009). Guide to the preparation, use and quality assurance of blood components, 15th edition. Strasbourg.

European Commission (2008). EudraLex. The Rules Governing Medical Products in the European Union. EU Guidelines to Good Manufacturing Practice, Medical Products for Human and Veterinary Use. Draft Annex 11. E. I. D.‐G. European Commission, Consumer Goods, Pharmaceuticals., European Commission.

Evans, J. (2004). Case study 23: Blood establishment computer systems. Computer Systems Validation. G. Wingate, Interpharm/CRC: 923‐934.

FDA (U.S.) (1995). Glossary of Computer Systems Software Development Terminology. Division of field investigations. Office of regional operations. office of regulatory affairs. Rockville, MD, U.S. Dept. of Health and Human Services, Food and Drug Administration.

FDA/CBER (U.S.) (2002). Guidance for industry. General principles of software validation: Final guidance for industry and FDA staff. Rockville, MD, U.S. Dept. of Health and Human Services, Food and Drug Administration, Center for Biologics Evaluation and Research.

FDA/CBER (U.S.) (2007). Guidance for industry blood establishment computer system validation in the user's facility. Rockville, MD, U.S. Dept. of Health and Human Services, Food and Drug Administration, Center for Biologics Evaluation and Research: i, 9 p.

GAMP Forum. (2001). GAMP guide for validation of automated systems. Good automated manufacturing practice : GAMP 4. Tampa, FL, Society for Pharmaceutical and Medical Device Professionals : GAMP Forum.

Grupo de Trabalho de Imuno‐hematologia (2008). Imuno‐hematologia ‐ Recomendações, Instituto Português do Sangue, IP.

IEEE. (1990). IEEE standard glossary of software engineering terminology. New York, N.Y., Institute of Electrical and Electronics Engineers. Computer Society. Software Engineering Technical Committee.


117

IPS (2002). Circular Normativa n.º 003/CN‐IPS/02 de 04 de Dezembro de 2002. Requisitos em Matéria de Rotulagem das Unidades de Sangue: Identificação Única Nacional da Dádiva de Sangue. Instituto Português do Sangue. 003/CN‐IPS/02.

IPS (2004). Circular Normativa n.º 001/CN‐IPS/04 Padrão Internacional ISBT 128 para Rotulagem de Componentes Sanguíneos. Nota Técnica sobre a Etiqueta ISBT 128. Instituto Português do Sangue. 001/CN‐IPS/04.

ISBT, A. Bobos, et al. (2006). "ISBT guidelines for information security in transfusion medicine. International Society of Blood Transfusion Information Security Task Force." Vox Sang 91 Suppl 1: S1‐23.

ISBT, W. Bocker, et al. (2003). "ISBT ‐ Guidelines for validation and maintaining the validation state of automated systems in blood banking. International Society of Blood Transfusion Validation Task Force." Vox Sang 85 Suppl 1: S1‐14.

ISBT, J. Sampson, et al. (2010). "ISBT Guidelines for validation of automated systems in blood establishments. Working Party on Information Technology Validation Task Force." Vox Sang 98 Suppl 1: 1‐19.

ISO/IEC (2005). ISO/IEC 17799:2005: Information Technology ‐ Code of Practice for Information Security Management. Geneva, Switzerland, International Organization for Standardization/International Electrotechnical Commission.

ISPE (2008). GAMP® 5 A Risk‐based Approach to Compliant GxP Computerized Systems, International Society for Pharmaceutical Engineering.

Miller, R. A. and R. M. Gardner (1997). "Recommendations for responsible monitoring and regulation of clinical software systems. American Medical Informatics Association, Computer‐based Patient Record Institute, Medical Library Association, Association of Academic Health Science Libraries, American Health Information Management Association, American Nurses Association." J Am Med Inform Assoc 4(6): 442‐457.

Munk, C. (2009a). What about information technology in transfusion technology. Transfusion Today, International Society of Blood Transfusion: 9‐10.

Munk, C. (2009b). What about information technology in transfusion medicine (II). Transfusion Today, International Society of Blood Transfusion: 14‐17.

Munk, C. (2009c). Why standards are important in using infomation technologies (III). Transfusion Today, International Society of Blood Transfusion: 11‐12.

PIC/S (2007). Good Practices for computerised systems in regulated ‘GxP’ environments, Pharmaceutical Inspection Convention & Pharmaceutical Inspection Co‐Operation Scheme: 50 p.

Portugal. Ministério da Saúde (2007). Decreto‐Lei n.º 267/2007. 1.ª série‐N.º 141. Diário da República, Imprensa Nacional‐Casa da Moeda, S. A.: 22.

Sage, A. P. and W. B. Rouse (2009). Handbook of systems engineering and management. Hoboken, N.J., John Wiley & Sons.

Sommerville, I. (2007). Software engineering. Harlow, England, Addison‐Wesley. Tracy, D. S. and R. A. Nash (2002). "A Validation Approach for Laboratory Information

Management Systems." Journal of Validation Technology 9(1): 6‐14. Wingate, G. (2004). Computer systems validation : quality assurance, risk management,

and regulatory compliance for pharmaceutical and healthcare companies. Boca Raton, Fla., Interpharm/CRC.


118

9. Anexos

Anexo 1

1

Inquérito aos Serviços de Sangue e Serviços de Medicina

Transfusional sobre o Sistema Informático Utilizado

Tipo de Instituição e Serviço

1. Nome da Instituição______________________________________________________

2. Tipo de Serviço

□ SS □ SMT □ SS + SMT

□ SS (Processamento das análises e das separações no Exterior) + SMT

3. Está Certificado?

□ SIM □ NÃO □ Processo de certificação em curso

□ Já esteve mas perdeu a certificação

4. Nº de Colheitas (2009)____________________________________________________

5. Nº de Unidades Transfundidas (2009)________________________________________

6. Nº de Camas____________________________________________________________

7. Nº de Profissionais

7.1 Médicos_______________________________

7.2 Especialistas IHT_________________________

7.3 Outros especialistas______________________

7.4 Técnicos_______________________________

7.5 Enfermeiros____________________________

7.5 Administrativos_________________________

Sistema Informático Utilizado

8. Tem SI?

□ Sim □ Não □ Não sabe □ Não responde

8.1 Se SIM, qual?_________________________________________________________

9. Tem Servidor Próprio ou Partilhado?

□ Próprio □ Partilhado □ Não sabe □ Não responde

Anexo 1

2

10. Quais das seguintes actividades do serviço não estão integradas no SI?

□ Promoção da Dádiva / Planeamento de Colheitas

□ Recepção / Inscrição de Dadores □ Triagem Clínica / Exame Objectivo de Dadores

□ Colheitas □ Laboratório de Microbiologia

□ Laboratório de Imuno‐hemoterapia

□ Laboratório de Controlo da Qualidade □ Separação de Componentes

□ Rotulagem / Gestão de Stocks / Distribuição

□ Gestão de Stocks e requisição de componentes aos SS

□ Registo e Gestão de pedidos □ Preparação / Atribuição de Transfusões □ Disponibilização para Transfusão □ Administração / Confirmação Positiva da Transfusão

□ Apoio à Gestão □ Administração do Sistema

Comentários ao Sistema ou Software

Responsabilidade de Gestão do Sistema Informático

11. De quem é a responsabilidade de gestão do SI:

11.1 Relativamente ao Hardware

□ Serviço □ Fora do serviço □ Partilhada □ Não sabe □ Não responde

11.2 Relativamente ao Software

□ Serviço □ Fora do serviço □ Partilhada □ Não sabe □ Não responde

Segurança dos Dados e dos Equipamentos

12. Estão definidas políticas para a realização de Cópias de Segurança?


13. Estão definidas políticas para a Segurança dos Acessos ao Software?


14. Existem protecções físicas dos equipamentos? (Utilização de UPS, sala do servidor

ambientalmente controlada, restrição dos acessos, etc.)


Registo e Controlo de Propostas e Alterações ao Sistema

15. As actividades relacionadas com as propostas de melhoria do SI e suas interfaces estão

registadas?


Anexo 1

3

16. Estão definidos procedimentos para registo e controlo das alterações:

17.1 Do hardware?


17.1 Do software?


Rastreabilidade dos Processos

17. Considera que o seu sistema lhe assegura a rastreabilidade de todos os processos

relacionados com cada colheita?

□ Sim □ Não □ Não sabe □ Não responde □ Não aplicável

18. Considera que o seu sistema lhe assegura a rastreabilidade de todos os processos

relacionados com cada transfusão?

□ Sim □ Não □ Não sabe □ Não responde □ Não aplicável

Estado, Actividades e Competências Relacionadas com a Validação destes

Sistemas

19. O seu serviço esteve/está envolvido em actividades ou desenvolve actividades para

validação do SI?


20. Os sistemas automáticos ligados ao SI estão validados?

□ Sim □ Não □ Alguns □ Não sabe □ Não responde □ Não aplicável

21. O SI está validado?


21.1 Se NÃO, está prevista a validação?


22. Qual o nível de premência que atribui à validação do SI, numa escala de 0 a 5?

□ 0 □ 1 □ 2 □ 3 □ 4 □ 5 □ Não sabe

23. Considera ter no serviço recursos próprios que lhe permitam fazer a validação do SI?


24.1 Se NÃO, qual o motivo?

□ Falta de formação na área □ Falta de recursos humanos

□ Falta de formação na área e falta de recursos humanos □ Não sabe □ Não responde

24.2 Se NÃO, qual a solução para esta necessidade?

□ Outros serviços da instituição □ Recursos externos □ Formação dos recursos humanos na área

□ IPS e serviço de informática da instituição □ Não responde Outras soluções ou comentários:

Anexo 2

1

Tabelas de Resultados do Inquérito

1 ‐ Software utilizado por tipo de serviço ou agrupamento de serviços

N

SMT 12

ASIS 6

SIBAS 3

IMAGINASOFT 1

NOVA HIS 1

ROCAIL 1

SS Processamento no exterior + SMT 3

SIBAS 3

SS + SMT 11

SIBAS 6

ASIS 4

PELICANO 1


IMAGINASOFT 1


ASIS 1

SIBAS 1


ASIS 2

SIBAS 1

Agrupamento Hospitalar com 1 SS + SMT e 1 SMT 2

SIBAS 2

Agrupamento Hospitalar com 1 SS+SMT e 1 PT 1

ASIS 1


SIBAS 1


ASIS 1

SIBAS 1


IMAGINASOFT 1


ASIS 2

ClinidataBST 1

SIBAS 1

Agrupamento Hospitalar com 3 SS + SMT 1

ASIS 1


ASIS 1


ASIS 1


e‐DELPHYN 1

Prestador de Serviços em 15 SMT 1

13 DELPHYN, 1 e‐DELPHYN, 1 SIBAS 1

Total 48

Anexo 2

2

2 ‐ Classificação do servidor de cada sistema, por tipo de serviço e software utilizado

Tipo de Serviço e Software utilizado Tipo de servidor

Total Partilhado Próprio

SMT 16 (33,3%) 7 (14,6%) 23 (47,9%)

IMAGINASOFT 1 (2,08%) 1 (2,08%)

ASIS 9 (18,8%) 2 (4,2%) 11 (22,9%)

ClinidataBST 1 (2,1%) 1 (2,1%)

DELPHYN 1 (2,1%) 1 (2,1%)

e‐DELPHYN 1 (2,1%) 1 (2,1%)

NOVA HIS 1 (2,1%) 1 (2,1%)

ROCAIL 1 (2,1%) 1 (2,1%)

SIBAS 4 (8,3%) 2 (4,2%) 6 (12,5%)

SS (Proc. Ext.) + SMT 3 (6,3%) 3 (6,3%)

SIBAS 3 (6,3%) 3 (6,3%)

SS + SMT 15 (31,3%) 7 (14,6%) 22 (45,8%)

ASIS 6 (12,5%) 3 (6,3%) 9 (18,8%)

IMAGINASOFT 1 (2,1%) 1 (2,1%) 2 (4,2%)

PELICANO 1 (2,1%) 1 (2,1%)

SIBAS 8 (16,7%) 2 (4,2%) 10 (20,8%)

Total 31 (64,6%) 17 (35,4%) 48 (100,0%)

3 ‐ Responsabilidade de Gestão do Hardware e do Software, por tipo de serviço e software utilizado

Fora do serviço Partilhada Do Serviço

Hardware Software Hardware Software Hardware Software

SMT 11 (22,9%) 11 (22,9%) 10 (20,8%) 11 (22,9%) 2 (4,2%) 1 (2,1%)

IMAGINASOFT 1 (2,1%) 1 (2,1%)

ASIS 4 (8,3%) 4 (8,3%) 6 (12,5%) 7 (14,6%) 1 (2,1%)


DELPHYN 1 (2,1%) 1 (2,1%)

e‐DELPHYN 1 (2,1%) 1 (2,1%)

NOVA HIS 1 (2,1%) 1 (2,1%)

ROCAIL 1 (2,1%) 1 (2,1%)

SIBAS 3 (6,3%) 3 (6,3%) 2 (4,2%) 3 (6,3%) 1 (2,1%)

SS (Proc. Ext.) + SMT 3 (6,3%) 3 (6,3%)

SIBAS 3 (6,3%) 3 (6,3%)

SS + SMT 9 (18,8%) 7 (14,6%) 12 (25,0%) 14 (29,2%) 1 (2,1%) 1 (2,1%)

ASIS 2 (4,2%) 2 (4,2%) 7 (14,6%) 7 (14,6%)

IMAGINASOFT 1 (2,1%) 1 (2,1%) 1 (2,1%) 1 (2,1%)

PELICANO 1 (2,1%) 1 (2,1%)

SIBAS 6 (12,5%) 4 (8,3%) 4 (8,3%) 6 (12,5%)

Total 20 (41,7%) 18 (37,5%) 25 (52,1%) 28 (58,3%) 3 (6,3%) 2 (4,2%)

Anexo 2

3

4 ‐ Registo das actividades relacionadas com as propostas de melhoria do SI e suas interfaces, por tipo de serviço e software utilizado

Registo das actividades relacionadas com as propostas de

melhoria do SI e suas interfaces

Total Não Sim Não Sabe

SMT 13 (27,1%) 10 (20,8%) 23 (47,9%)

IMAGINASOFT 1 (2,1%) 1 (2,1%)

ASIS 8 (16,7%) 3 (6,3%) 11 (22,9%)


DELPHYN 1 (2,1%) 1 (2,1%)

e‐DELPHYN 1 (2,1%) 1 (2,1%)

NOVA HIS 1 (2,1%) 1 (2,1%)

ROCAIL 1 (2,1%) 1 (2,1%)

SIBAS 4 (8,3%) 2 (4,2%) 6 (12,5%)

SS (Proc. Ext.) + SMT 1 (2,1%) 2 (4,2%) 3 (6,3%)

SIBAS 1 (2,1%) 2 (4,2%) 3 (6,3%)

SS + SMT 7 (14,6%) 14 (29,2%) 1 (2,1%) 22 (45,8%)

ASIS 3 (6,3%) 6 (12,5%) 9 (18,8%)

IMAGINASOFT 1 (2,1%) 1 (2,1%) 2 (4,2%)

PELICANO 1 (2,1%) 1 (2,1%)

SIBAS 3 (6,3%) 7 (14,6%) 10 (20,8%)

Total 21 (43,8%) 26 (54,2%) 1 (2,1%) 48 (100,0%)

5 ‐ Existência de procedimentos para registo e controlo das alterações ao hardware e ao software, por tipo de serviço e software utilizado

Hardware Software

Não Sabe Não Sim Não Sim

SMT 16 (33,3%) 7 (14,6%) 17 (35,4%) 6 (12,5%)

IMAGINASOFT 1 (2,1%) 1 (2,1%)

ASIS 7 (14,6%) 4 (8,3%) 9 (18,8%) 2 (4,2%)


DELPHYN 1 (2,1%) 1 (2,1%)

e‐DELPHYN 1 (2,1%) 1 (2,1%)

NOVA HIS 1 (2,1%) 1 (2,1%)

ROCAIL 1 (2,1%) 1 (2,1%)

SIBAS 5 (10,4%) 1 (2,1%) 5 (10,4%) 1 (2,1%)

SS (Proc. Ext.) + SMT 3 (6,3%) 3 (6,3%)

SIBAS 3 (6,3%) 3 (6,3%)

SS + SMT 1 (2,1%) 10 (20,8%) 11 (22,9%) 11 (22,9%) 11 (22,9%)

ASIS 1 (2,1%) 5 (10,4%) 3 (6,3%) 6 (12,5%) 3 (6,3%)

IMAGINASOFT 2 (4,2%) 2 (4,2%)

PELICANO 1 (2,1%) 1 (2,1%)

SIBAS 4 (8,3%) 6 (12,5%) 4 (8,3%) 6 (12,5%)

Total 1 (2,1%) 29 (60,4%) 18 (37,5%) 31 (64,6%) 17 (35,4%)

Anexo 2

4

6 ‐ Desenvolvimento nos serviços de actividades para validação dos sistemas informáticos, por tipo de serviço e software utilizado

Desenvolvimento nos serviços de actividades para validação dos sistemas informáticos

Total Não Sabe Não Sim

SMT 1 (2,1%) 18 (37,5%) 4 (8,3%) 23 (47,9%)

IMAGINASOFT 1 (2,1%) 1 (2,1%)

ASIS 10 (20,8%) 1 (2,1%) 11 (22,9%)


DELPHYN 1 (2,1%) 1 (2,1%)

e‐DELPHYN 1 (2,1%) 1 (2,1%)

NOVA HIS 1 (2,1%) 1 (2,1%)

ROCAIL 1 (2,1%) 1 (2,1%)

SIBAS 5 (10,4%) 1 (2,1%) 6 (12,5%)

SS (Proc. Ext.) + SMT 3 (6,3%) 3 (6,3%)

SIBAS 3 (6,3%) 3 (6,3%)

SS + SMT 15 (31,3%) 7 (14,6%) 22(45,8%)

ASIS 7 (14,6%) 2 (4,2%) 9 (18,8%)

IMAGINASOFT 1 (2,1%) 1 (2,1%) 2 (4,2%)

PELICANO 1 (2,1%) 1

(2,1%)

SIBAS 6 (12,5%) 4 (8,3%) 10 (20,8%)

Total 1 (2,1%) 36 (75,0%) 11 (22,9%) 48 (100,0%)

7 ‐ Estado de validação dos sistemas automáticos ligados ao sistema informático, por tipo de serviço e software utilizado

Estado de validação dos sistemas automáticos ligados ao

sistema informático

Total Não Aplicável Não Sim

SMT 5 (10,4%) 5 (10,4%) 13 (27,1%) 23 (47,9%)

IMAGINASOFT 1 (2,1%) 1 (2,1%)

ASIS 2 (4,2%) 2 (4,2%) 7 (14,6%) 11 (22,9%)


DELPHYN 1 (2,1%) 1 (2,1%)

e‐DELPHYN 1 (2,1%) 1 (2,1%)

NOVA HIS 1 (2,1%) 1 (2,1%)

ROCAIL 1 (2,1%) 1 (2,1%)

SIBAS 2 (4,2%) 1 (2,1%) 3 (6,3%) 6 (12,5%)

SS (Proc. Ext.) + SMT 2 (4,2%) 1 (2,1%) 3 (6,3%)

SIBAS 2 (4,2%) 1 (2,1%) 3 (6,3%)

SS + SMT 1 (2,1%) 3 (6,3%) 18 (37,5%) 22 (45,8%)

ASIS 1 (2,1%) 2 (4,2%) 6 (12,5%) 9 (18,8%)

IMAGINASOFT 1 (2,1%) 1 (2,1%) 2 (4,2%)

PELICANO 1 (2,1%) 1 (2,1%)

SIBAS 10 (20,8%) 10 (20,8%)

Total 6 (12,5%) 10 (20,8%) 32 (66,7%) 48 (100,0%)

Anexo 2

5

8 ‐ Previsão de Validação dos Sistemas não Validados, por tipo de serviço e software utilizado

Previsão de Validação dos Sistemas não Validados


SMT 2 (5,5%) 8 (21,6%) 8 (21,6%) 18 (48,7%)

IMAGINASOFT 1 (2,7%) 1 (2,7%)

ASIS 1 (2,7%) 5 (13,5%) 3 (8,1%) 9 (24,3%)

ClinidataBST

DELPHYN

e‐DELPHYN 1 (2,7%) 1 (2,7%)

NOVA HIS 1 (2,7%) 1 (2,7%)

ROCAIL 1 (2,7%) 1 (2,7%)

SIBAS 1 (2,7%) 3 (8,1%) 1 (2,7%) 5 (13,5%)

SS (Proc. Ext.) + SMT 2 (5,4%) 1 (2,7%) 3 (8,1%)

SIBAS 2 (5,4%) 1 (2,7%) 3 (8,1%)

SS + SMT 10 (27,0%) 6 (16,2%) 16 (43,2%)

ASIS 6 (16,2%) 2 (5,4%) 8 (21,6%)

IMAGINASOFT 1 (2,7%) 1 (2,7%)

PELICANO 1 (2,7%) 1 (2,7%)

SIBAS 4 (10,8%) 2 (5,4%) 6 (16,2%)

Total 2 (5,5%) 20 (54,0%) 15 (40,5%) 37 (100,0%)

9 ‐ Nível de premência atribuída à validação dos sistemas informáticos, por tipo de serviço e software utilizado

Premência ( de 0 nenhuma a 5 máxima) Não sabe 0 1 2 3 4 5 Total

SMT 1 (2,1 %) 6 (12,5 %) 9 (18,8 %) 7 (14,6 %) 23 (47,9 %)

IMAGINASOFT 1 (2,1 %) 1 (2,1 %)

ASIS 1 (2,1 %) 4 (8,3 %) 4 (8,3 % 2 (4,2 %) 11 (22,9 %)

ClinidataBST 1 (2,1 %) 1 (2,1 %)

DELPHYN 1 (2,1 %) 1 (2,1 %)

e‐DELPHYN 1 (2,1 %) 1 (2,1 %)

NOVA HIS 1 (2,1 %) 1 (2,1 %)

ROCAIL 1 (2,1 %) 1 (2,1 %)

SIBAS 2 (4,2 %) 4 (8,3 %) 6 (12,5 %)

SS (Proc. Ext.) + SMT 2 (4,2 %) 1 (2,1 %) 3 (6,3 %)

SIBAS 2 (4,2 %) 1 (2,1 %) 3 (6,3 %)

SS + SMT 1 (2,1 %) 13 (27,1 %) 7 (14,6 %) 1 (2,1 %) 22 (45,8 %)

ASIS 1 (2,1 %) 4 (8,3 %) 4 (8,3 %) 9 (18,8 %)

IMAGINASOFT 2 (4,2 %) 2 (4,2 %)

PELICANO 1 (2,1 %) 1 (2,1 %)

SIBAS 7 (14,6 %) 2 (4,2 %) 1 (2,1 %) 10 (20,8 %)

Total 2 (4,2 %) 1 (2,1 %) 8 (16,7 %) 22 (45,8 %) 14 (29,2 %) 1 (2,1 %) 48 (100,0 %)

Anexo 2

6

10 ‐ Existência nos Serviços de Recursos Próprios que permitam fazer a validação do SI, por tipo de serviço e software utilizado

Existência nos Serviços de Recursos Próprios que permitam fazer a validação do SI


SMT 1 (2,1%) 11 (22,9%) 11 (22,9%) 23 (47,9%)

IMAGINASOFT 1 (2,1%) 1 (2,1%)

ASIS 1 (2,1%) 5 (10,4%) 5 (10,4%) 11 (22,9%)


DELPHYN 1 (2,1%) 1 (2,1%)

e‐DELPHYN 1 (2,1%) 1 (2,1%)

NOVA HIS 1 (2,1%) 1 (2,1%)

ROCAIL 1 (2,1%) 1 (2,1%)

SIBAS 3 (6,3%) 3 (6,3%) 6 (12,5%)

SS (Proc. Ext.) + SMT 3 (6,3%) 3 (6,3%)

SIBAS 3 (6,3%) 3 (6,3%)

SS + SMT 1 (2,1%) 14 (29,2%) 7 (14,6%) 22 (45,8%)

ASIS 7 (14,6%) 2 (4,2%) 9 (18,8%)

IMAGINASOFT 1 (2,1%) 1 (2,1%) 2 (4,2%)

PELICANO 1 (2,1%) 1 (2,1%)

SIBAS 1 (2,1%) 5 (10,4%) 4 (8,3%) 10 (20,8%)

Total 2 (4,2%) 28 (58,3%) 18 (37,5%) 48 (100,0%)

Anexo 2

7

11 ‐ Motivos da não existência nos serviços de recursos próprios que permitam fazer a validação do sistema informático, por tipo de serviço e software utilizado

Motivos da não existência nos serviços de recursos próprios que permitam fazer a validação do sistema informático

Falta de formação na

área



Não Responde Não Sabe Total

SMT 1 (3,6%) 2 (7,1%) 7 (25,0%) 1 (3,6%) 11 (39,3%)

ASIS 2 (7,1%) 3 (10,7%) 1 (3,6%) 6 (21,4%)

SIBAS 2 (7,1%) 2 (7,1%)

DELPHYN 1 (3,6%) 1 (3,6%)

NOVA HIS 1 (3,6%) 1 (3,6%)

IMAGINASOFT

ClinidataBST

e‐DELPHYN

ROCAIL 1 (3,6%) 1 (3,6%)

SS (Proc. Ext.) + SMT 1 (3,6%) 2 (7,1%) 3 (10,7%)

SIBAS 1 (3,6%) 2 (7,1%) 3 (10,7%)

SS + SMT 1 (3,6%) 1 (3,6%) 12 (42,9%) 14 (50,0%)

ASIS 1 (3,6%) 6 (21,4%) 7 (25,0%)

SIBAS 1 (3,6%) 4 (14,3%) 6 (21,4%)

IMAGINASOFT 1 (3,6%) 1 (3,6%)

PELICANO 1 (3,6%) 1 (3,6%)

Total Geral 2 (7,1%) 3 (10,7%) 20 (71,4%) 2 (7,1%) 1 (3,6%) 28 (100,0%)

Anexo 2

8

12 ‐ Soluções apresentadas pelos serviços sem recursos próprios que permitam fazer a validação do SI para a sua realização, por tipo de serviço e software utilizado

Soluções apresentadas pelos serviços sem recursos próprios que

permitam fazer a validação do SI para a sua realização

Total

Formação dos RH na

área

IPS e Serviço Informática da Instituição


Recursos Externos

Não Responde

SMT 2 (7,1%) 1 (3,6%) 4 (14,3%) 3 (10,7%) 10 (35,7%)

IMAGINASOFT

ASIS 1 (3,6%) 2 (7,1%) 2 (7,1%) 5 (17,9%)

ClinidataBST

DELPHYN 1 (3,6%) 1 (3,6%)

e‐DELPHYN

NOVA HIS 1 (3,6%) 1 (3,6%)

ROCAIL 1 (3,6%) 1 (3,6%)

SIBAS 1 (3,6%) 1 (3,6%) 2 (7,1%)

SS (Proc. Ext.) + SMT 1 (3,6%) 2 (7,1%) 3 (10,7%)

SIBAS 1 (3,6%) 2 (7,1%) 3 (10,7%)

SS + SMT 1 (3,6%) 5 (17,9%) 9 (32,1%) 15 (53,6%)

ASIS 1 (3,6%) 3 (10,7%) 3 (10,7%) 7 (25,0%)

IMAGINASOFT 1 (3,6%) 1 (3,6%)

PELICANO 1 (3,6%) 1 (3,6%)

SIBAS 1 (3,6%) 5 (17,9%) 6 (21,4%)

Total Geral 3 (10,7%) 1 (3,6%) 10 (35,7%) 12 (42,9%) 2 (7,1%) 28 (100,0%)

Capa final Jorge - Repositório Aberto › bitstream › 10216 › 55340 › 2... · 2011-08-11 ·...

Documents

Transcript of Capa final Jorge - Repositório Aberto › bitstream › 10216 › 55340 › 2... · 2011-08-11 ·...