o processo clínico electrónico (pce) na instituição militar · a existência, a nível europeu,...

O Processo Clínico Electrónico (PCE) na Instituição Militar

Jaime Adolfo Cabral Ribeiro da Cunha

Dissertação para obtenção do Grau de Mestre em

Engenharia Informática e de Computadores

Júri

Presidente: Prof. Pedro Manuel Moreira Vaz Antunes de Sousa

Orientador: Prof. Gabriel César Ferreira Pestana

Vogal: Prof. Diogo Manuel Ribeiro Ferreira

Novembro 2012

O Processo Clínico Electrónico na Instituição Militar

i

Agradecimentos

Os primeiros agradecimentos vão para a família, para o meu filho e para a minha esposa que

sempre me apoiaram e que por vezes abdicaram do seu tempo para garantir que eu tivesse

todas as condições para levar a bom porto esta aventura, um muito obrigado. Sem querer

esquecer ninguém, agradeço a todos os que mais de perto seguiram esta empreitada e que

sempre tiveram uma palavra de apoio e incentivo.

Gostaria também de agradecer ao Major General Médico Joaquim Lopes Henriques e Major

General Médico Luís Almeida Duarte pelo incentivo e confiança que ao longo dos vários anos

da minha colaboração com o Hospital Militar Principal em foram dados. Em particular

agradeço ao MajGen Lopes Henriques pela sua amabilidade e interesse abrindo assim portas

que de outra forma seria impossível.

Em concreto para o trabalho efectuado agradeço, em primeiro lugar, ao Coronel Médico Luís

Gusmão pelo interesse demostrado e sugestões apresentadas que conduziram a que fosse

possível a sua realização. O seu incentivo e contactos por si efectuados permitiram a

interacção com diferentes especialidades e profissionais de saúde que em muito enriqueceram

o trabalho realizado. A todos os profissionais de saúde entrevistados agradeço a

disponibilidade, interesse e contribuições, sem as quais não seria possível apresentar uma

proposta concreta sobre o conjunto de informação clínica e parâmetros relevantes para a

síntese dos utentes e para os planos de monitorização.

Por fim um agradecimento em especial ao meu orientador, o Professor Gabriel Ferreira

Pestana que de mim esteve mais perto, contribuindo, com o seu apoio e orientação, para a

execução desta tese.


ii

Dedicatória

Ao meu Pai, que nos deixou prematuramente.


iii

Resumo

A existência, a nível europeu, de um contexto favorável à utilização de tecnologias de

informação e comunicação (TIC) na área da saúde levou, em Portugal, à realização de

esforços e iniciativas no âmbito do Serviço Nacional de Saúde (SNS), extensíveis a outros

subsistemas de saúde como o Serviço de Saúde Militar (SSM), de forma a cumprir com

iniciativas para a operacionalização do conceito de eHealth. Consequentemente na

especificação de serviços de saúde inovadores que promovam acções preventivas na

monitorização do estado de saúde de doentes crónicos, bem como na responsabilização do

utente pelo seu estado de saúde.

Apesar das alterações implementadas contribuírem para agilizar processos administrativos e

clínicos, a utilização das TIC como um agente de mudança e de alteração de hábitos pouco

saudáveis é muito limitado e pouco eficiente. Situação que se agudiza se considerarmos a

utilização das TIC em contextos colaborativos de partilha de informação e no apoio ao

processo de decisão.

O contributo proposto nesta dissertação procura responder a este desafio. Apresenta uma

metodologia para recolha de valores sobre parâmetros clínicos, diferenciando medições

efectuadas em ambientes formais e não-formais. Esta abordagem permite aos profissionais de

saúde disporem de uma base de conhecimento credível sobre a evolução do estado de saúde

dos utentes, incidindo a partilha de informação sobre dados de síntese do processo clinico do

utente. Em termos tecnológicos a solução proposta assenta na utilização de uma plataforma

web de gestão por processos, com um motor de regras e mecanismos de gestão de alertas.

Esta metodologia será testada na Unidade Hospital da Estrela pertencente ao Hospital das

Forças Armadas.

Keywords: Processo Clinico Electrónico, Partilha de informação, Síntese Clinica do Utente,

Plano de Monitorização.


iv

Abstract

The existence, on a European level, of a context that supports the use of information and

communication technologies (ICT) in the healthcare field led to the implementation in

Portugal of efforts and initiatives in the National Healthcare Service (Serviço Nacional de

Saúde – SNS), which were extended to other healthcare systems such as the Military

Healthcare Service (Serviço de Saúde Militar – SSM), in order to comply with initiatives to

make the eHealth concept operational. Consequently, the specification of innovative

healthcare services that promote preventive action in monitoring the status of chronic patients

and the patient’s accountability for his/her health condition.

While the implemented changes have contributed to expedite the administrative and clinical

processes, there are still some remaining constraints and inefficiencies to the use of ICT as an

agent for changing and modifying unhealthy habits. This situation is aggravated if we

consider the use of ICT in collaborative settings for the sharing of information and for

supporting the decision process.

The contribution offered in this thesis seeks to meet this challenge. It brings forth a

methodology for collecting clinical parameter values, differentiating between measurements

performed in formal and non-formal environments. This approach allows healthcare

professionals to have a reliable knowledge base on the evolution of the patient’s health

condition, focusing the sharing of information on synthesis data from the patient’s clinical

process. In technological terms, the offered solution is based upon the use of a process

management web platform, with rules and alert management mechanisms. This methodology

will be tested in the “Unidade Hospital da Estrela” which belongs to the “Hospital das Forças

Armadas” (Armed Forces Hospital).

Keywords: Electronic Health Record, Sharing of Information, Patient Clinical Synthesis,

Monitoring Plan.


v

Índice

Lista de Figuras ........................................................................................................................ vii

Lista de Tabelas ......................................................................................................................... ix

Acrónimos ................................................................................................................................. xi

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

1.1. Enquadramento / Contextualização ........................................................................... 13

1.2. Trabalho Relacionado ................................................................................................ 15

1.3. Aspectos Relevantes para o Problema ....................................................................... 16

1.3.1. Breve enquadramento da evolução histórica ......................................................... 16

1.3.2. Estrutura Organizacional ....................................................................................... 20

1.4. Definição do Problema .............................................................................................. 24

1.5. Principais Contribuições ............................................................................................ 25

1.6. Introdução ao Conteúdo dos Capítulos ...................................................................... 26

2. Estado da Arte ............................................................................................................... 27

2.1. eHealth ....................................................................................................................... 27

2.2. Desmaterialização de processos ................................................................................ 32

2.3. Normalização (Standards) ......................................................................................... 34

2.3.1. ISO/TR 20514:2005 Health informatics -- Electronic health record -- Definition, scope and context. ................................................................................................................ 34

2.3.2. HL7 (Health Level Seven) ..................................................................................... 35

2.4. Arquitecturas ............................................................................................................. 38

2.4.1. Service-Oriented Architecture ............................................................................... 38

2.4.2. Event Driven Architecture ..................................................................................... 41

2.4.3. Soluções Web Baseadas em Serviços .................................................................... 43

2.5. Workflow ................................................................................................................... 45

2.5.1. Modelo de Referência ............................................................................................ 46

2.5.2. Workflow Software ................................................................................................ 49

3. Metodologia Proposta ................................................................................................... 51

3.1. Abordagem metodológica .......................................................................................... 52

3.2. Modelo de colaboração .............................................................................................. 53

3.2.1. Componente orientada a serviços .......................................................................... 53

3.2.2. Componente orientada a eventos (EDA) ............................................................... 56

3.2.3. Metadados de suporte à metodologia proposta ...................................................... 57

4. Case Study ..................................................................................................................... 66


vi

4.1. Caracterização da Unidade Hospitalar da Estrela ...................................................... 66

4.2. Infra-estrutura Tecnológica ....................................................................................... 71

4.3. Sistemas Clínicos em Produção ................................................................................. 74

4.4. Cenário Clinico .......................................................................................................... 75

4.4.1. Serviços Clínicos Objecto do Estudo ..................................................................... 75

4.4.2. Caracterização do Universo Amostral dos Utentes ............................................... 76

4.4.3. Parâmetros Clínicos a Monitorizar ........................................................................ 78

4.4.4. Contribuição das fontes para a síntese do PCE do utente. ..................................... 81

5. Conclusões .................................................................................................................... 85

Referências ............................................................................................................................... 88

Anexo A – Situação Actual dos Estabelecimentos de Saúde do SSM. .................................... 91

Anexo B – Relação de Especialidades da UHE ....................................................................... 94

Anexo C – Aplicações / Módulos de Saúde em Produção na UHE ......................................... 95

Anexo D – Valores de Referência por Parâmetro .................................................................. 107

Anexo E – Modelo de Domínio – Classes, seus Atributos e Métodos ................................... 109

Anexo F – Sistemas Fonte - Ecrãs ......................................................................................... 118


vii

Lista de Figuras

Figura 1-1 - Alterações na Infra-estrutura Hospitalar decorrentes da reforma/reestruturação da

Saúde Militar .................................................................................................................... 20

Figura 1-2 - Alterações na Assistência à Doença aos militares decorrentes da unificação de

2005 .................................................................................................................................. 21

Figura 2-1 – Agentes envolvidos em decisão colaborativa. ..................................................... 33

Figura 2-2 - Modelo Open Systems Interconnection ............................................................... 36

Figura 2-3 - Clinical Document Architecture .......................................................................... 37

Figura 2-4 – Componentes SOA .............................................................................................. 39

Figura 2-5 – Funcionamento SOA ........................................................................................... 40

Figura 2-6 - Event-Driven Arquitecture ................................................................................... 42

Figura 2-7 - Definição de camadas de serviços disponibilizados via internet ......................... 43

Figura 2-8 - Gartner Hype Cycle Model. ................................................................................. 46

Figura 2-9 – Modelo de referência de Workflow ..................................................................... 47

Figura 3-1 - Modelo de Colaboração ....................................................................................... 52

Figura 3-2 - Modelo de Domínio ............................................................................................. 59

Figura 3-3 – Síntese / BI Clínico do Utente ............................................................................. 60

Figura 3-4 – Lista de intercorrências ........................................................................................ 62

Figura 3-5 – Planos de Monitorização ..................................................................................... 63

Figura 4-1 - Criação de Fichas de Utentes (Anos 2005 a 2011) .............................................. 67

Figura 4-2 – Interacção com Utentes (Anos 2005 a 2011) ...................................................... 68

Figura 4-3 – Rede de Bastidores UHE ..................................................................................... 72

Figura E-1 - Modelo de Domínio ........................................................................................... 109

Figura F-1 – GH-Gestão Doentes – Ficha do doente ............................................................. 118

Figura F-2 – EPR-Desktop Médico – História Clinica .......................................................... 118

Figura F-3 – EPR-Desktop Médico – História Clinica/Biometria ......................................... 119


viii

Figura F-4 – EPR-Desktop Médico – Terapêutica ................................................................. 119

Figura F-5 – EPR-Desktop Médico – Exames ....................................................................... 120

Figura F-6 – GH – Gestão Doentes – Registo de operações .................................................. 120

Figura F-7 – GH – Gestão Doentes – Actos Médicos (Consulta) .......................................... 121

Figura F-8 – GH – Gestão Doentes – Actos Médicos (Exame) ............................................. 122

Figura F-9 – GH – Gestão Doentes – Registo de internamento ............................................. 122


ix

Lista de Tabelas

Tabela 1-1 – Custos de encargos com a saúde e universo de beneficiários SNS vs SSM ....... 22

Tabela 1-2 - Utentes dos Estabelecimentos de Saúde Militar .................................................. 23

Tabela 2-1 – Indicadores de aplicação e uso de eHealth .......................................................... 29

Tabela 2-2 – Modelo de referência de Workflow - Interfaces ................................................. 47

Tabela 3-1 – Síntese / BI Clínico do Utente ............................................................................. 61

Tabela 3-2 – Lista de intercorrências ....................................................................................... 62

Tabela 3-3 – Planos de Monitorização ..................................................................................... 64

Tabela 4-1 – Actividade da UHE – Ano 2011 ......................................................................... 69

Tabela 4-2 – Infra-estruturas Hospitalares – Ano 2011 ........................................................... 69

Tabela 4-3 – Pessoal ao Serviço da UHE – Ano 2011 ............................................................. 70

Tabela 4-4 – Hardware (aplicações de saúde e de suporte) ..................................................... 73

Tabela 4-5 – Aplicações / Módulos de Saúde em Produção na UHE ...................................... 74

Tabela 4-6 – Recursos Humanos – Cardiologia / Endocrinologia e Nutrição ......................... 76

Tabela 4-7 – Produção e faixas etárias Ano 2011 – Cardiologia / Endocrinologia e Nutrição 77

Tabela 4-8 – Utentes Ano 2011 – Cardiologia / Endocrinologia e Nutrição ........................... 78

Tabela 4-9 – Matriz de parâmetros por especialidade/patologia .............................................. 80

Tabela 4-10 – Contributo para a síntese do PCE do utente dos sistemas verticais existentes . 81

Tabela A-1 – Situação dos SI dos hospitais ............................................................................. 91

Tabela A-2 – Situação dos SI dos Centros de Saúde e Postos de Socorros ............................. 93

Tabela B-1 – Especialidades Médicas e Cirúrgicas (UHE) ..................................................... 94

Tabela D-1 – Parâmetros e valores de referência ................................................................... 107

Tabela E-1 – Utente ................................................................................................................ 110

Tabela E-2 – Valida Utente .................................................................................................... 110

Tabela E-3 – Medicação Activa ............................................................................................. 111

Tabela E-4 – Antecedentes ..................................................................................................... 111


x

Tabela E-5 – Patologias .......................................................................................................... 111

Tabela E-6 – Episodio ............................................................................................................ 112

Tabela E-7 – Episodio Cirurgia .............................................................................................. 112

Tabela E-8 – Episodio Consulta ............................................................................................. 112

Tabela E-9 – Episodio Internamento ...................................................................................... 113

Tabela E-10 – Episodio Exame .............................................................................................. 113

Tabela E-11 – Contacto .......................................................................................................... 113

Tabela E-12 – Medico ............................................................................................................ 114

Tabela E-13 – Instituição de Saúde ........................................................................................ 114

Tabela E-14 – Plano Monitorização ....................................................................................... 114

Tabela E-15 – Parâmetro ........................................................................................................ 115

Tabela E-16 – Parâmetro Plano .............................................................................................. 115

Tabela E-17 – Sensor ............................................................................................................. 115

Tabela E-18 – Sensor Parametro ............................................................................................ 116

Tabela E-19 – Medição .......................................................................................................... 116

Tabela E-20 – Frequência de Recolha .................................................................................... 116

Tabela E-21 – Regra ............................................................................................................... 117

Tabela E-22 – Alerta .............................................................................................................. 117

Tabela E-23 – Contacto Regra ............................................................................................... 117


xi

Acrónimos

ACSS Administração Central do Sistema de Saúde

ADM Assistência na doença aos Militares das Forças Armadas

ADMA Assistência na doença aos Militares da Armada

ADME Assistência na doença aos Militares do Exército

ADMFA Assistência na doença aos Militares da Força Aérea

ADSE Direcção Geral de Protecção Social aos Funcionários e Agentes da Administração Pública

API Application Programming Interface

AVC Acidente Vascular Cerebral

BMT Blood Medical Test

BPM Business Process Management

BRE Business Rules Engine

CDM Collaborative Decision Making

CEMGFA Chefe do Estado-Maior-General das Forças Armadas

CEN European Committee for Standardization

CORBA Common Object Request Broker Architecture

CSR Case Study Research

DCOM Distributed Component Object Model

DICOM Digital Imaging and Communication in Medicine

EIS Europe Information Society

EPSOS Smart Open Services for European Patients

ERP Enterprise Resource Planning

FA Forças Armadas

FND Forças Nacionais Destacadas

GDH Grupo Diagnóstico Homogéneo

HFA Hospital da Força Aérea

HFAR Hospital das Forças Armadas

HIMSS Healthcare Information and Management Systems Society

HINARI Health Internetwork Access to Research Initiative

HIS Healthcare Information Systems

HL7 Health Level Seven

HM Hospital da Marinha


xii

HMB Hospital Militar de Belém

HMP Hospital Militar Principal

HMR1 Hospital Militar Regional n.º1

HMR2 Hospital Militar Regional n.º2

IASFA Instituto de Acção Social das Forças Armadas

ICD International Classification of Diseases

IEEE Institute for Electrical and Electronic Engineers

INR International Normalized Ratio

ISO International Organization for Standardization

MDN Ministério da Defesa Nacional

NIST National Institute of Standards and Technology

ORB Object Request Brokers

PaaS Platform as a Service

PACS Picture Archiving and Communication System

PDS Plataforma de Dados da Saúde

RNU Registo nacional de Utentes

RSE Registo de Saúde Electrónico

SAM Sistema de Apoio ao Médico

SGBD Sistema de Gestão de Base de Dados

SI Sistema de Informação

SNS Serviço Nacional de Saúde

SO Sistema Operativo

SOA Service Oriented Architecture

SOAP Subjective, Objective, Assessment, and Plan

SONHO Sistema de Informação para a gestão de Doentes

SSM Sistema de Saúde Militar

SUC Serviços de Utilização Comum

TI Tecnologia de Informação

TIC Tecnologias de Informação e Comunicação

UHE Unidade Hospitalar da Estrela

UHL Unidade Hospitalar do Lumiar

UHSC Unidade Hospitalar de Santa Clara

WFMC Workflow Management Coalition

WFMS Workflow Management Systems


13

1. Introdução

A saúde e as tecnologias de informação e comunicação (TIC) estão hoje, mais do que nunca,

presentes no quotidiano de todos nós, pois cada vez mais temos cidadãos informados e mais

exigentes. A procura de formas para estruturar a informação de saúde, disponibilizar e aceder

a essa mesma informação, tem sido objecto de trabalhos de investigação de organizações

internacionais, governos e universidades. Todavia, ainda subsistem ineficiências e

dificuldades na partilha de informação decorrentes quer de deficiências no planeamento, quer

devido a ineficiências na gestão dos recursos disponíveis ou decorrentes de problemas

relacionados com os actuais sistemas verticalizados que se constituem como ilhas de

informação.

1.1. Enquadramento / Contextualização

Existe ao nível europeu um contexto político favorável à utilização de tecnologias de

informação e comunicação (TIC) na área da saúde. Praticamente todos os países da União

Europeia (EU) iniciaram ou têm em produção sistemas de âmbito nacional de informação

para a saúde que disponibilizam informação sobre os utentes aos diversos profissionais de

saúde [1]. Em Portugal registam-se esforços no sentido de criar infra-estruturas para a

informatização da saúde. Este trabalho tem sido efectuado, quer ao nível do Serviço

Nacional de Saúde (SNS), quer ao nível de outros subsistemas nos quais se enquadra o

sistema de saúde militar (SSM), tendo porém em consideração as especificidades deste

último.

O SSM opera com profissionais de saúde militares e civis, apresentando um conjunto de

serviços de saúde específicos para os militar que o diferencia do SNS, designadamente:

• Tarefas de classificação e selecção de pessoal, nomeadamente no que diz respeito

à componente do estado de saúde dos candidatos;

• Aprontamento sanitário, i.e, observação médica, exames complementares e

vacinação prévia às missões das Forças Nacionais Destacadas (FND);

• A avaliação de doenças e/ou sequelas de lesões, relacionadas com o serviço

militar;

• A realização de Juntas Médicas para apreciação da aptidão/inaptidão e capacidade

/incapacidade para o serviço militar;


14

• Treino e enquadramento militar contínuos do pessoal militar de saúde, no âmbito

de cenários de conflito armado convencional, missões NATO e missões sob a

égide das Nações Unidas.

Para além destes serviços de saúde, o SSM também contempla o apoio hospitalar e

serviços de cuidados primários aos familiares e dependentes dos militares, genericamente

designado de “Família Militar”. São também beneficiários dos serviços de saúde

prestados pelo SSM as forças de segurança, como a Guarda Nacional Republicana,

Policia de Segurança Pública e Policia Municipal, bem como os respectivos familiares, e

em casos pontuais os beneficiários da Direcção Geral de Protecção Social aos

Funcionários e Agentes da Administração Pública (ADSE).

Alinhado com as orientações/directrizes legislativas de reforma do sistema de saúde

militar está a penetração cada vez maior dos Sistemas de Informação (SI) na área da

saúde. A disponibilidade de informação sobre o estado de saúde e perfil do utente no

momento e local onde esta é necessária é cada vez mais um requisito num contexto de

trabalho colaborativo como é o caso do ambiente hospitalar.

O processo de decisão do profissional de saúde assenta na evidência científica,

recorrendo com alguma frequência a especialistas ou à recolha de uma segunda opinião

junto dos seus pares. Este ambiente de partilha do conhecimento, que em termos

operacionais poderá ser tão simples como a necessidade de transferência de doentes nas

urgências hospitalares devido ao funcionamento por turnos, enquadra-se no conceito de

Collaborative Decision Making (CDM), que ocorre quando dois ou mais indivíduos

contribuem com o seu conhecimento e experiencia para o processo de tomada de decisão

[2].

Um processo clínico electrónico (PCE) em ambiente CDM resulta por norma da

integração de dados dispersos por fontes/sistemas heterogéneos havendo assim a

necessidade, numa fase inicial de desmaterialização de processos, de integração com os

sistemas verticais, administrativos como Sistema de Informação para a Gestão de

Doentes (SONHO) ou clínicos como o Sistema de Apoio ao Médico (SAM),

responsáveis pelo registo de dados sobre o estado de saúde do utente, para se conseguir

obter uma síntese sobre o estado de saúde do mesmo.

A dispersão e a heterogeneidade de SI presentes no SSM, decorrentes da sua estrutura

orgânica/funcional, dificultam a partilha de informação. O único benefício traduz-se na


15

existência de SI nas diferentes unidades hospitalares, sendo os constrangimentos

relacionados com a falta / dificuldade de interoperabilidade. Também em relação ao

processo clínico do utente existem diferenças no que diz respeito ao seu grau de

informatização, havendo unidades em que o suporte em papel ainda tem grande peso e

unidades onde a situação é inversa1.

1.2. Trabalho Relacionado

Segundo a HIMSS - Healthcare Information and Management Systems Society2, eHealth

(ou e-health) é qualquer aplicação que faz uso da Internet, que é utilizada em conjunto

com outras tecnologias de informação, focada na melhoria do acesso, na eficiência e na

qualidade dos processos clínicos e assistenciais em uso nas instituições de saúde, com o

objectivo de conseguir as melhores condições de tratamento para o utente e as melhores

condições em termos de custo para o Sistema de Saúde. Este conceito relacionado com o

suporte da prática clinica através de processos electrónicos e comunicações é

relativamente recente havendo referencias ao mesmo desde 1999 [3].

O uso do termo tem sofrido alterações havendo quem defenda a sua utilização em

ambientes de troca de informação clinica por meios electrónicos [4] enquanto outros, de

uma forma mais restrita, referem e-health nos casos onde os cuidados de saúde são

prestados fazendo uso da internet.

A questão que se coloca é saber de que forma pode o e-health contribuir para reduzir o

“gap” entre aquilo que é o conhecimento e investigação da comunidade científica e aquilo

que é pratica dos profissionais de saúde. O volume e complexidade do conhecimento

gerado obrigam à utilização de sistemas de informação havendo uma necessidade de

ferramentas que consigam agregar conhecimento de diferentes fontes e que possibilitem o

seu uso quando e onde seja necessário [5]. Programas como o Health Internetwork

Access to Research Initiative (HINARI) da Organização Mundial de Saúde facultam, a

profissionais de saúde de países em desenvolvimento, acesso online a informação

cientifica de topo na área da saúde, possibilitando assim uma partilha de conhecimento

entre estes profissionais.

1 Anexo A – Situação Actual dos Estabelecimentos de Saúde do SSM. 2 HIMSS E-Health SIG White Paper - http://www.himss.org/content/files/ehealth_whitepaper.pdf.


16

Ao nível do trabalho nas instituições de saúde, e em concreto ao nível dos cuidados

prestados aos utentes, esta partilha de informação é essencial para que o profissional de

saúde aceda a informação de suporte ao diagnóstico. Esta informação, que por norma é

obtida através da integração de dados dispersos por fontes/sistemas heterogéneos, requer

uma desmaterialização do PCE. Desta forma temos, por um lado o e-health suportado em

sistemas de informação e em mecanismos de recolha de informação de diferentes fontes,

e por outro a aplicação do conceito de CDM pois a decisão médica é alicerçada em

contributos de vários profissionais de saúde.

A necessidade de acesso à informação por parte dos profissionais de saúde bem como por

parte dos utentes tem sido endereçada através do uso de PCE ou por Personal Health

Records, que não são mais do que uma vista da informação pertinente para o utente,

tipicamente para utentes com doenças crónicas que carecem de acompanhamento e

vigilância [6]. A hipótese colocada pelos autores refere o acesso do utente a um subset da

informação constante no PCE através de web, garantindo, aos profissionais de saúde, um

meio de acesso à informação clínica do utente, corroborando o conceito de CDM em

meio clinico, e ao utente, uma forma de visualização e contribuição de informação.

1.3. Aspectos Relevantes para o Problema

Presentemente o SSM agrega os serviços de saúde dos três ramos das forças armadas:

Exército, Marinha e Força Aérea, por conseguinte existe uma necessidade de agregação e

uniformização de informação bem como requisitos de interoperabilidade entre os SI que

dantes estavam em serviços de saúde de cada um destes ramos. Sucintamente a missão do

SSM consiste em garantir o apoio sanitário3 à componente operacional das Forças

Armadas e, simultaneamente, assegurar a assistência médica aos efectivos militares e às

suas famílias [7].

1.3.1. Breve enquadramento da evolução histórica

Até 2005 a assistência na doença aos militares estava segmentada em subsistemas de

saúde distintos:

• ADME – Assistência na doença aos Militares do Exército;

• ADMA - Assistência na doença aos Militares da Armada;

3 O apoio sanitário é um sistema integrado de tratamento, evacuação e logística sanitária.


17

• ADMFA - Assistência na doença aos Militares da Força Aérea.

Em setembro de 2005 foi unificada, através de diploma legal4 num único subsistema, a

Assistência na Doença aos Militares (ADM), sujeito a um regime paralelo ao da

Direcção Geral de Protecção Social aos Funcionários e Agentes da Administração

Pública (ADSE). A gestão da recém-criada ADM passa para o Instituto de Acção

Social das Forças Armadas (IASFA) que é um instituto público integrado na

administração indirecta do Estado, dotado de personalidade jurídica, com autonomia

administrativa, financeira e património próprio.

Esta reorganização no âmbito da saúde militar despoletada por iniciativa legislativa5

dos Ministros de Estado, das Finanças e da Defesa Nacional visa criar um novo

modelo de gestão hospitalar que abrange um conjunto de recursos, nomeadamente

humanos, materiais, financeiros e de infra-estruturas dos hospitais militares dos três

ramos.

Da resolução do conselho de ministros em Fevereiro de 20086, surgem directrizes que

regulam a gestão da mudança, destacando-se as seguintes orientações:

• Proceder à criação de um órgão, na dependência do Ministro da Defesa

Nacional, responsável pela concepção, coordenação e acompanhamento das

políticas de saúde a desenvolver no âmbito militar e que terá como

atribuição inicial o estudo da racionalização da rede hospitalar militar, bem

como a proposta do respectivo modelo de gestão;

• Criar um Hospital das Forças Armadas, na dependência do Chefe do

Estado-Maior-General das Forças Armadas (CEMGFA), organizado em

dois pólos hospitalares, um em Lisboa e outro no Porto;

• Iniciar a instalação do Pólo Hospitalar de Lisboa, mediante o

redimensionamento da estrutura hospitalar militar existente na área de

Lisboa, através da racionalização e concentração de valências e de recursos,

atendendo ao seguinte faseamento:

4 Decreto-Lei n.º 167/2005 de 23 de Setembro, Diário da República, 1.ª série A — N.º 184. 5 Despacho conjunto nº 393/2006 de 2 de Maio de 2006, Diário da República II Série, nº 93 de 15 de Maio de 2006 6 Resolução do Conselho de Ministros n.º 39/2008, Diário da República I Série, nº 42 de 28 de Fevereiro de 2008.


18

o No curto prazo, proceder à racionalização e concentração de

valências médicas e capacidades, constituindo serviços de utilização

comum, guarnecidos por pessoal militar e civil dos três ramos das

Forças Armadas;

o No médio prazo, redimensionar a estrutura hospitalar militar,

através da sua concentração.

A reforma em curso7 com vista à criação do Hospital das Forças Armadas (HFAR),

organizado num pólo em Lisboa e outro no Porto, e colocado sob dependência do

Chefe de Estado-Maior General das Forças Armadas (CEMGFA), procura racionalizar

os cuidados de saúde diferenciados, através da redução de custos, concentração dos

meios e recursos disponíveis e maior eficiência, incidindo sobre as unidades

hospitalares de maior dimensão, designadamente:

• Hospital da Marinha, em Lisboa;

• Hospital Militar Principal (Exército), em Lisboa;

• Hospital Militar de Belém (Exército), em Lisboa;

• Hospital da Força Aérea, em Lisboa;

• Hospital Militar Regional Nº 1 (Exército), no Porto;

• Hospital Militar Regional Nº 2 (Exército), em Leiria.

Através do despacho de 11 de Fevereiro de 2010, o Ministro da Defesa Nacional criou

um grupo de trabalho para proceder ao estudo da racionalização de valências

hospitalares e de recursos, assente na constituição de serviços de utilização comum

(SUC), guarnecidos por pessoal militar e civil dos três ramos das Forças Armadas,

incluindo um serviço de urgência único.

Para a concretização da reforma sai a 4 de Maio de 2010 directiva ministerial8. Este

documento refere ainda que, no desenvolvimento do HFAR, se deverá considerar a sua

articulação na utilização de serviços e instalações, com outras entidades,

designadamente o Serviço Nacional de Saúde (SNS). Ouvido o Conselho Superior

Militar, o Ministro da Defesa Nacional proferiu dois despachos9 que consubstanciam a

7 Lei Orgânica n.º 1-A/2009 de 7 de Julho, Diário da República, 1.ª série — N.º 129 de 7 de Julho de 2009 8 Despacho nº.7770/2010 de 16 de Abril de 2010, Diário da República, 2.ª série — N.º 86 — 4 de Maio de 2010. 9 Despacho n.º 10825-10826/2010 de 16 de Junho de 2010, Diário da República, 2.ª série — N.º 126 — 1 de Julho de 2010.


19

decisão sobre o processo de constituição do HFAR e de organização do seu pólo de

Lisboa.

O actual governo refere no seu programa, na área reservada à defesa nacional, o

seguinte:

“Tomando como referência o que está disposto a este respeito no Memorando de

Entendimento, concretizar a reforma do sistema de saúde militar, mas garantindo um

apoio de qualidade aos seus utentes e um aproveitamento completo da capacidade

instalada”10.

Com base neste desígnio foi criada a 24 de Agosto de 2011 uma equipa técnica com o

objectivo de elaboração do estudo que conduziu à apresentação de uma proposta sobre

a melhor localização para a instalação do pólo de Lisboa do HFAR tendo em

consideração critérios de eficiência e eficácia bem como o actual contexto financeiro e

orçamental do país, salvaguardando a qualidade dos cuidados de saúde a prestar e a

prontidão da resposta. Após a elaboração do estudo foi proposto à tutela que o pólo de

Lisboa do HFAR fosse instalado na Unidade Hospitalar do Lumiar (antigo HFA),

proposta esta aceite e reflectida em despacho ministerial publicado a 5 de Dezembro

de 201111.

A 16 de Agosto de 2012 arranca em definitivo o processo de fusão12 que deverá estar

concluído no prazo máximo de 24 meses. Com a entrada em vigor do referido diploma

são extintos o Hospital da Marinha, o Hospital Militar Principal, o Hospital Militar de

Belém e o Hospital da Força Aérea, sendo as respectivas atribuições e competências

transferidas para o pólo de Lisboa do HFAR, ficando para momento posterior a

criação e implementação do pólo do Porto do HFAR cujos estudos estão em curso.

Deste processo de fusão, para além dos desafios organizacionais, decorrem os

objectivos da criação de um utente único para as forças armadas, da partilha de

informação clínica entre as diferentes unidades de saúde e da fusão da informação

existente nos casos da extinção das organizações de origem.

10 Programa do XIX Governo Constitucional, Presidência do Conselho de Ministros. 11 Despacho nº.16437/2011 de 4 de Novembro de 2011, Diário da República, 2.ª série — N.º 232 — 5 de Dezembro de 2011. 12 Decreto-Lei nº 187/2012 de 16 de Agosto de 2012, Diário da Republica, 1ª série – Nº 158 – 16 de Agosto de 2012.


20

1.3.2. Estrutura Organizacional

A descrição da organização do SSM até ao modelo actual permite ter uma ideia clara

da sua complexidade e das entidades envolvidas. O SSM, onde se concentra o caso de

estudo, agrega os serviços de saúde dos três ramos das forças armadas: Exército,

Marinha e Força Aérea, estando estes serviços dependentes em termos funcionais,

administrativos e hierárquicos do ramo onde se inserem, contemplando a vertente dos

cuidados diferenciados ao nível hospitalar e possuindo unidades que prestam cuidados

primários, essencialmente executados pelos postos de socorros e centros de saúde de

menor dimensão e diferenciação.

A figura 1-1 mostra as alterações decorrentes da reforma em curso, quer por extinção,

quer por alteração da dependência hierárquica, administrativa e funcional dos vários

estabelecimentos de saúde militar de carácter hospitalar. Esta alteração estende-se

também aos recursos humanos (médicos, enfermeiros, técnicos, auxiliares de acção

médica, administrativos) do quadro e contratados, quer sejam eles militares ou civis,

resultando numa estrutura organizacional mais ágil e com maior centralização de

comando.

Organograma Hospitalar Militar antes da

Reestruturação na Saúde Militar

Organograma Hospitalar Militar após

Reestruturação na Saúde Militar

Figura 1-1 - Alterações na Infra-estrutura Hospitalar decorrentes da reforma/reestruturação da Saúde Militar


21

No que diz respeito aos subsistemas de saúde em 2005 registou-se a unificação dos

três subsistemas de saúde específicos de cada um dos ramos (ADME, ADMA e

ADMFA), num único subsistema a ADM.

Assistência à doença aos militares antes da

unificação de 2005

Assistência à doença aos militares após a unificação

de 2005.

Figura 1-2 - Alterações na Assistência à Doença aos militares decorrentes da unificação de 2005

As alterações reflectidas na figura 1-2 têm como objectivo a uniformização dos vários

sistemas de saúde públicos, ao mesmo tempo que permitem uma melhor

racionalização dos meios humanos e materiais disponíveis, criando um subsistema

sujeito a um regime paralelo ao da ADSE, salvaguardando as especificidades da

condição militar. Têm um impacto directo na gestão da assistência na saúde aos

militares, retirando esse ónus dos ramos das forças armadas, centralizando-a numa

única entidade que abarca essa responsabilidade para os três ramos.

Os indivíduos elegíveis como beneficiários deste novo subsistema, quer sejam

beneficiários titulares ou beneficiários familiares ou equiparados são os seguintes13:

• Beneficiários titulares da ADM

o Os militares dos quadros permanentes nas situações de activo, de

reserva e de reforma;

o Os militares em regime de contrato ou de voluntariado, nos termos

estabelecidos para os militares dos quadros permanentes; 13 Portaria N.º 284/2007, de 12 de Março de 2007, Diário da República, 2.ª série – N.º 50.


22

o Os alunos dos estabelecimentos de ensino militares que frequentem

cursos de formação para ingresso nos quadros permanentes;

o O pessoal militarizado da Marinha e do Exército, nos termos

estabelecidos para os militares dos quadros permanentes.

• Beneficiários familiares ou equiparados, i.e. a “família militar”:

o O cônjuge, os descendentes ou equiparados e os ascendentes ou

equiparados a cargo do beneficiário titular;

o Pessoa que vive com o beneficiário titular em união de facto.

A prestação dos cuidados de saúde aos beneficiários da ADM pode ser efectuada pelas

seguintes entidades:

• Estabelecimentos do Serviço de Saúde Militar. Estão aqui incluídos os centros

de saúde e hospitais militares já referidos.

• Estabelecimentos do Serviço Nacional de Saúde;

• Pessoas singulares ou colectivas com as quais tenham sido celebrados acordos;

• Pessoas singulares ou colectivas da livre escolha dos beneficiários.

Nos dois primeiros casos a prestação dos cuidados de saúde é gratuita para os

beneficiários, sem prejuízo do pagamento de taxa moderadora que no SSM é de valor

idêntico ao praticado no SNS, cabendo aos respectivos estabelecimentos facturar os

actos médicos praticados à ADM. A tabela 1-1 apresenta os custos e o número de

beneficiários do SNS e do SSM. A grande diferença de valores tem essencialmente a

ver com a diferença que existe em termos do número de beneficiários, bem como pelo

facto dos beneficiários do SSM serem também utentes do SNS.

Tabela 1-1 – Custos de encargos com a saúde e universo de beneficiários SNS vs SSM

Entidade Custo (Milhares de Euros) Universo de Beneficiários (estimativa)

SNS 9.399.10014 10.555.85315

SSM 19.04416 297.00817

14 Entidade Reguladora da Saúde, Relatório de Sustentabilidade do SNS, Setembro 2011 15 INE, censos 2011 16 ISAFA, I.P – Relatório de actividades de 2010 17 Sem considerar os beneficiários da ADSE.


23

Na tabela 1-2 temos, sem contabilizar os beneficiários da ADSE, cerca de 300.000

beneficiários que, apesar da reforma em curso, terão o seu respectivo PCE repartido

entre os vários locais de prestação de cuidados de saúde que possuem SI, e ainda

processos clínicos manuscritos nos locais que não possuem a tecnologia necessária.

Tabela 1-2 - Utentes dos Estabelecimentos de Saúde Militar

Subsistema Total de Beneficiários

ADM 18 Exercito – 67.058

131.731

Marinha – 40.834

Força Aérea – 23.839

SAD/PSP19 74.277

SAD/GNR20 90.000

ADSE21

Titulares/Activos – 577.482

1.362.896

Titulares/Aposentados – 324.654

Familiares – 460.760

Outros22 < 1.000 Totais (S/ ADSE) 297.008

Totais (C/ADSE) 1.659.904

Acresce a tudo isto o facto de não existir entre os vários locais uma uniformização na

identificação do utente. Esta falta de uniformização aliada à inexistência de

informação partilhada em formato digital, às dificuldades de integração dos sistemas

de saúde existentes no SSM para as diferentes áreas de actuação nas unidades de saúde

e sobretudo a fraca orientação dos sistemas de informação para o utente, agudizam os

problemas do funcionamento do SSM com implicações na saúde dos utentes.

18 IASFA, I.P - Divisão de Estudos e Estatística (07/10/2011) 19 Serviços de assistência na Doença da PSP (07/10/2011). Inclui os elementos da polícia municipal 20 Divisão da Assistência na Doença / Direcção de Saúde e Assistência na Doença (07/10/2011) 21 Sitio da ADSE – http://www.adse.pt – Dados referentes a Agosto de 2011. Inclui, deste Janeiro 2011, os serviços sociais do ministério da justiça. 22 Utentes inscritos no Hospital Militar Principal. Elementos das embaixadas, Palop´s, Autorizados, etc


24

1.4. Definição do Problema

No SSM, tal como na maioria dos hospitais e centros de saúde do SNS o nível de

informatização é por norma medido pelo número de computadores e aplicações existentes.

Contudo a proliferação de computadores por unidades de saúde não é, com toda a certeza,

sinónimo de serviço de maior qualidade. Em muitos casos a “informatização” dita mesmo

um significativo acréscimo na carga de trabalho [8]. Para este acréscimo de trabalho

contribui o facto de termos SI orientados aos serviços em vez de orientados aos processos,

bem como SI vistos exclusivamente com tecnologia e não como meios de optimização

organizacional [9].

Apesar das alterações decorrentes da reformulação do SSM contribuírem para agilização

de alguns processos administrativos e funcionais do sistema de saúde, ainda subsistem

constrangimentos e ineficiências que podem ser rectificadas com o intuito de tornar o

SSM mais eficiente, das quais podemos destacar:

• Inexistência de uma identificação única para os utentes do SSM;

• Existem diferentes SI nas instituições do SSM, bem como diferentes estádios de

maturidade;

• Os Hospitais não partilham, em formato electrónico, informação entre si, não

existindo um PCE com fluxos de partilha de informação;

• Dentro do mesmo hospital, existem dificuldades de interoperabilidade entre as

soluções informáticas existentes;

• Ineficiência no acesso aos dados do processo clínico do utente;

• Apesar dos SI agilizarem a implementação da desmaterialização de processos e de

haver alguns serviços de fluxo de informação, o estado de desmaterialização dos

processos é embrionário;

• Inexistência de informação de gestão consolidada;

• Uma fraca orientação dos SI para o utente, não havendo ou sendo residual a

presença dos hospitais na Web com possibilidade de interacção com o utilizador;

Acresce à questão tecnológica o facto de em medicina estarmos perante um ambiente de

tomada de decisão colaborativa e mesmo em locais onde a utilização de SI com a

respectiva desmaterialização do processo clínico é uma realidade, este continua a existir

de forma isolada impedindo ou dificultando a partilha de informação entre os


25

profissionais de saúde. Temos portanto um desalinhamento entre o negócio e os SI que

importa corrigir através de mecanismos que assegurem uma identificação única para os

utentes e a respectiva desmaterialização do seu processo clínico, garantindo que a

informação estará disponível sempre que necessária, de forma a assegurar um verdadeiro

ambiente de tomada de decisão colaborativo.

Dos problemas encontrados no SSM pretende-se com este trabalho endereçar duas

questões fundamentais:

• Identificar qual deverá ser a informação de síntese do estado de saúde do utente

acessível a todos os profissionais de saúde;

• Aumentar a interacção com o utente fazendo que este assuma uma maior

responsabilidade pelo seu estado e hábitos de saúde;

A resolução das questões passa pelo estabelecimento de uma arquitectura inovadora de

utilização dos SI que garanta a uniformização e acesso a dados de síntese do PCE do

utente, trazendo este para o centro do sistema de saúde, fomentando ao mesmo tempo a

partilha de informação (CDM) entre profissionais de saúde e fazendo o “empowerment”

do utente através do seu envolvimento e participação activa.

1.5. Principais Contribuições

A contribuição desta tese para a resolução do problema enunciado em 1.4 suporta-se num

modelo de colaboração que endereçará o problema da compartimentação dos SI e das

ilhas de informação existentes e que permitirá a definição de um catálogo de serviços

suportado numa plataforma de workflow, e na resolução das seguintes questões:

• Identificação unívoca dos utentes do SSM de forma a possibilitar a articulação de

informação dentro e para fora do SSM;

• Definição do conjunto de informação que se constituirá como síntese do estado de

saúde do utente acessível a todos os profissionais de saúde do SSM e de entidades

como as quais o SSM partilhe os utentes, através da formalização da estrutura de

dados que caracteriza o perfil clinico de um utente.

• Concepção de um novo serviço de saúde que fomente o aumento da interacção

com o utente fazendo que este assuma uma maior responsabilidade pelo seu

estado e hábitos de saúde, através da formalização da estrutura dados de suporte a

planos de monitorização e sua disponibilização.


26

• Apoio à análise do desempenho de um utente face a um universo amostral, através

da definição das variáveis que permitem identificar a amostra e dos parâmetros

que se constituem como indicadores.

O modelo de colaboração tem como objectivos principais a agilização do fluxo de

informação entre os profissionais saúde, o acesso a dados de síntese do PCE, quer por

profissionais de saúde quer pelos próprios utentes, que para além de acederem à

informação podem também constituir-se como fontes de informação.

1.6. Introdução ao Conteúdo dos Capítulos

A estrutura do relatório, para além da introdução no actual capítulo, apresenta no capítulo

2 o resultado da pesquisa efectuada na área de domínio deste trabalho, oferecendo desta

forma uma panorâmica sobre esta área do conhecimento, nomeadamente através de

análise de artigos, pesquisas por palavras-chave e recolha de informação sobre conceitos

e standards relacionados com a saúde, com a problemática da integração de sistemas de

informação hospitalar, arquitecturas orientadas a serviços, bem como soluções de

workflow, gestão documental e motores de regras. O capítulo 3 apresenta uma exposição

da metodologia proposta para a resolução do problema definido em 1.4 com especial

ênfase para o modelo de colaboração e respectiva plataforma de suporte. O Case Study é

apresentado no capítulo 4 onde se faz a introdução à instituição onde será aplicado o caso

de estudo, descrevendo como a metodologia foi aplicada e fazendo referência aos

resultados obtidos. Por fim, no capítulo 5, apresenta-se um resumo do âmbito e do

problema abordado bem como as principais conclusões. É também feita referência à

componente do caso de estudo e fornecidas indicações relacionadas com o trabalho futuro,

nomeadamente no que diz respeito a aspectos que não foram possíveis explorar no âmbito

desta dissertação.


27

2. Estado da Arte

Hoje em dia a mobilidade de meios e recursos é uma realidade incontornável. As tecnologias

de comunicação wireless garantem aos profissionais de saúde maior mobilidade, permitindo

que estejam contactáveis ou que possam aceder a informação relevante independentemente do

local onde estejam. Requisito essencial em ambientes colaborativos e de partilha de

informação como é o caso do sector da saúde.

Todavia, o acesso à informação clinica fora da área de influência da instituição de saúde é

ainda um problema. Apesar dos progressos, os Sistemas de Informação (SI) em saúde pouco

mais são do que um conjunto de ilhas de informação que dificultam a partilha de dados entre

instituições de saúde. O desafio actual consiste em disponibilizar níveis de serviço capazes de

disponibilizar informação de síntese sobre o processo clinico do utente independentemente

dos SI ou fontes de dados.

No levantamento efectuado foram considerados o eHealth, os registos de saúde electrónicos,

standards em uso na saúde, as arquitecturas orientadas a serviços e a eventos, as diferentes

soluções web baseadas em serviços e ainda aspectos relacionados com workflow.

2.1. eHealth

O conceito de ehealth é usado a nível académico, institucional e profissional apesar de

não haver consenso numa clara e precisa definição. Um estudo efectuado e publicado no

Jounal of Medical Internet Research [10], que teve por base uma análise exaustiva de

definições propostas para eHealth encontrou 51 diferentes versões. Nestas conseguiram

identificar duas palavras-chave: saúde e tecnologia.

Segundo a Healthcare Information and Management Systems Society (HIMSS)23, o

conceito de eHealth corresponde a utilizar a Internet para acesso a dados de saúde, em

especial a dados sobre o processo clinico dos utentes. Nesta abordagem os SI em saúde

partilham informação entre instituições. O objectivo é conseguir globalmente melhores

condições de tratamento para o utente e melhores condições em termos de custo para o

sistema de saúde.

23 HIMSS E-Health SIG White Paper - http://www.himss.org/content/files/ehealth_whitepaper.pdf.


28

A tipologia e quantidade de serviços de saúde abrangidos pelo eHealth são por si só

meritórios de um estudo profundo que excede o âmbito desta tese. Razão pela qual

enumeramos cinco serviços que se relacionam com o objecto de estudo desta tese:

• Registo de saúde electrónico (RSE), de forma a fomentar a comunicação de dados

do utente entre diferentes profissionais de saúde;

• Telemedicina, através da possibilidade de efectuar actos médicos à distância;

• Equipas médicas virtuais compostas por profissionais de saúde que partilham

informação sobre os seus doentes;

• mHealth, que inclui o uso de dispositivos móveis para a recolha de informação

médica e que se diferencia essencialmente no hardware usado para o acesso e

recolha de informação, garantindo requisitos de mobilidade aos profissionais de

saúde e utentes;

• Soluções de software, HIS - Healthcare Information Systems, onde é possível

recolher e gerir toda a parte administrativa ligada à saúde, e.g: gestão de agenda,

marcação de actos médicos, identificação dos utentes, entre outros.

Para a Europe´s Information Society24 (EIS), o conceito de eHealth consiste “na

utilização de ferramentas de TIC, bem como serviços para a saúde, independentemente

destas ferramentas serem usadas apenas por profissionais de saúde ou directamente pelos

utentes”, garantindo um papel fundamental no melhoramento da saúde dos cidadãos. A

EIS considera o eHealth transversal a todos os intervenientes (i.e., pacientes,

profissionais de saúde e instituições de saúde), disponibilizando serviços segundo os

interesses e perspectivas de análise de cada um deles. Requisito que obriga a uma

interoperabilidade forte entre os SI existentes em cada instituição de saúde a nível

nacional e entre estados membros da Comunidade Europeia (CE).

No seu relatório sobre indicadores de eHealth25, refere que na CE existe grandes

discrepâncias na utilização dos SI em saúde. Diferenças que decorrem de dois factores

principais: SI em saúde com níveis de maturidade diferentes e recursos com

competências díspares na utilização dos SI em saúde. A Tabela 2-1 apresenta dados sobre

utilização de SI por profissionais de saúde na sua prática diária.

24 http://ec.europa.eu/information_society/activities/health/index_en.htm. 25 Benchmarking ICT use among General Practitioners in Europe.


29

Tabela 2-1 – Indicadores de aplicação e uso de eHealth

Indicador Resultado

Uso de SI para

armazenamento de

dados do utente

O armazenamento de dados é feito por 80% dos médicos de clínica

geral dos países considerados no estudo (EU27). Porém a partilha de

informação encontra-se abaixo dos 50% em alguns países, descendo

mesmo para os 26 %, naqueles que menos partilham informação.

Uso de

computadores na

consulta.

O uso de computadores nas consultas ronda os 66% em termos de

sistemas clínicos e cerca de 62% no que diz respeito a sistemas de

suporte à decisão.

Uso da internet para

partilha de

informação entre

profissionais de

saúde e interacção

com utentes.

55% dos profissionais de saúde considerados utilizam a internet ou

outras redes dedicadas para partilha de informação em ambiente

colaborativo, nomeadamente laboratórios, outros médicos ou

autoridades de saúde.

As interacções com os utentes por este meio são virtualmente

inexistentes, com valores inferiores a 1%.

O primeiro aspecto a referir diz respeito ao desfasamento existente entre a

disponibilização de meios de TI aos profissionais de saúde e o seu uso efectivo que se

situa entre os 8% e os 29%. Para além deste ponto importa também referir as diferenças

encontradas tendo em consideração o tipo de informação a armazenar. Neste campo

temos por ordem decrescente o armazenamento de dados administrativos (92%),

informação clínica básica (ex: alergias – 85%), resultados de laboratório (81%), sintomas

e razão da visita (79%), estando o armazenamento de imagem no fundo da lista com

cerca de 35%. Outra conclusão a retirar destes indicadores diz respeito à forma de

armazenamento, onde cerca de 76% de informação é armazenada de forma estruturada

facilitando o processamento automático da mesma por outros sistemas.

A análise do uso de computadores na consulta revela que no campo de sistemas de apoio

à decisão os mais comuns são os de suporte ao diagnóstico em detrimento dos sistemas

de suporte à prescrição. Salientar também deste estudo que a tendência na utilização de

sistemas de apoio à decisão aponta para alertas e sugestões genéricas não especificas para

cada utente.


30

Detalhando um pouco mais o uso da internet para a ligação a outros actores verifica-se

que a maior fatia destas ligações têm a ver com ligações a laboratórios seguidas de

ligações entre profissionais de saúde. A utilização deste meio para a comunicação com

especialistas ou entidades de saúde é mais reduzida.

No plano eEurope 200526 da EIS procura-se, na área da saúde, estimular serviços,

aplicações e conteúdos que criem novos mercados, reduzam custos e incrementem a

produtividade. Para atingir este objectivo foram propostas três acções: utilização de

cartões de saúde electrónicos; expansão de redes de informação de saúde;

estabelecimento de serviços de saúde on-line [11].

O projecto EPSOS27 (Smart Open Services for European Patients) é a mais recente

iniciativa europeia ao nível de serviços de eHealth. Este projecto, cujo piloto entrou em

produção em Abril de 2012 e que terá a duração de um ano, é o culminar de três anos de

trabalho no sentido de dotar os países participantes de uma ferramenta de serviços de

eHealth transfronteiriça. O EPSOS constitui-se pois como o principal projecto de

interoperabilidade em termos de eHealth tendo como focus a melhoria do tratamento

/acompanhamento médico de cidadãos no estrangeiro através do fornecimento, aos

profissionais de saúde, de dados dos utentes. Os objectivos do projecto com relevância

para esta tese consistem na disponibilização de informação de síntese dos utentes (e.g.

alergias e cirurgias efectuadas) e informação sobre prescrição de medicamentos.

Posteriormente será ainda possível ao utente aceder à sua própria informação.

Portugal apresenta um nível de maturidade elevado na utilização da Internet para a

disponibilização de dados do utente. Desde 2011 que passou a ser possível às instituições

de saúde o acesso ao registo nacional de utentes (RNU) no âmbito da prescrição

electrónica28.

O plano nacional de saúde 2012-2016 [12] enumera uma carteira de projectos que vão de

encontro à criação de um conjunto de serviços ligados à área da saúde, tais como a

biblioteca virtual em saúde nacional, o Portal da Saúde, o RSE e ainda o acesso online a

26 eEurope 2005: Uma sociedade da informação para todos

http://ec.europa.eu/information_society/eeurope/2002/news_library/documents/eeurope2005/eeurope2005_pt.pdf 27 http://www.epsos.eu/home.html 28http://www.min-saude.pt/NR/rdonlyres/952C2EB7-0778-4C7C-AF0B-B102FB9FABB5/0/portaria_198_2011.pdf


31

serviços tais como: RNU, SIGIC, eAgenda. Incitativas que vão de encontro às directrizes

preconizadas pelo eHealth. No âmbito desta tese a convergência com esta iniciativa

incide sobre a necessidade urgente de um novo modelo que fomente o relacionamento

cidadão-profissionais de saúde, assente numa responsabilização partilhada e participação

activa do cidadão no processo de tratamento. A preocupação por uma política de saúde

preventiva é outra das considerações referidas em [12], das quais destacamos a

divulgação da produção de evidência científica, o estreitamento da relação entre os

profissionais de saúde e os cidadãos e a padronização da informação disponível.

O mais recente desenvolvimento de eHealth em Portugal, com o qual participa no

projecto EPSOS, é a Plataforma de Dados da Saúde (PDS)29. A PDS é um mecanismo de

acesso a informação dos utentes que permite mostrar os dados aos profissionais de saúde

em diversos pontos do SNS (hospitais, urgências, cuidados primários), permitindo a um

médico ou enfermeiro aceder a informação sem a poder modificar ou danificar. O seu

acesso é restrito e auditado, sendo que cada vez que um profissional acede a dados esse

facto fica registado num histórico de acessos.

A ACSS (Administração Central do Sistema de Saúde) e o ministério da saúde têm

desenvolvido esforços no sentido de estabelecer orientações para o RSE [13]. Este

agregará dados de saúde dos cidadãos, possibilitando o seu acesso, através de

mecanismos que incluem o controlo de acessos e de autorizações, privacidade e

confidencialidade da informação. O RSE, centrado no cidadão, apoia a missão dos

profissionais de saúde e garante o acompanhamento do cidadão, na sua mobilidade

espaço – temporal. São esperados benefícios ao nível da qualidade e celeridade dos

cuidados prestados, bem como em termos de redução do risco de erros resultantes da falta

da informação indispensável à decisão clínica.

Estudo sobre a usabilidade e o impacto do uso do RSE em unidades de cuidados

primários em Portugal [14], apesar dos benefícios descritos pela ACSS, aponta para uma

degradação da relação entre o médico e o utente que aliada a um deficiente suporte do

serviço, à “resistência à mudança” e à alteração do ritmo de trabalho, conduzem a uma

apreciação desfavorável dos SI em uso.

29 Direção-Geral de Saúde - http://www.dgs.pt/?cr=22490


32

2.2. Desmaterialização de processos

A desmaterialização de processos tem sido encarada, em várias áreas de negócio, como

uma vantagem competitiva com inegáveis benefícios em termos do aumento da eficiência

(e.g., acesso mais rápido à informação), maior controlo sobre a execução e estado dos

processos com custos mais baixos. A componente de segurança no acesso a informação

em ambientes de trabalho colaborativo é outro dos benefícios enumerados na literatura

[15].

Nos Estados Unidos, uma das economias onde os serviços de saúde são maioritariamente

prestados por entidades privadas, apesar do esforço na contenção de custos apenas 1,7%

dos 5.000 hospitais dispõem de sistemas que minimizam a necessidade de fluxos de

informação em papel30. A situação tornou-se de tal forma crítica que em 2009 a

administração norte americana definiu que até 2014 o RSE deveria estar disponível a

todos os cidadãos [16]. Nesta iniciativa, um dos vectores que mais contribuem para a

redução de custos e melhoria dos serviços tem a ver com a eliminação de duplicações nos

procedimentos e redução de erros, bem como facilitar a partilha de informação entre os

profissionais de saúde.

Artigo publicado no Health Affairs [17] refere que apesar dos adeptos do RSE

defenderem que este conduz a uma redução de custos e erros, existem relatórios que

sugerem o contrário, afirmando que a utilização do RSE provoca um aumento dos custos,

uma diminuição da produtividade sem qualquer benefício no que diz respeito à relação

entre prestador de serviço e o utente. O autor afirma que não se pode olhar para o RSE

como solução para problemas de custos, de produtividade e eficiência, mas sim como

veículo de suporte para projectos que conduzam à centralização dos cuidados de saúde no

utente, à criação de um ambiente CDM e à partilha de informação.

Corroborando a existência de ambiente de decisão colaborativo em saúde está, segundo

[18], a especialização nas diferentes áreas do conhecimento médico, que leva à

necessidade de troca de informação e conhecimento entre os vários agentes envolvidos na

decisão clínica, Figura 2-1.

30http://press.himss.org/press-release/himss-analytics-news/himss-analytics-recognizes-hennepin-county-medical-center-stage-7


33

Figura 2-1 – Agentes envolvidos em decisão colaborativa.

Os actos colaborativos, entre profissionais de saúde com menor e maior diferenciação,

permitem, de acordo com [18], o tratamento de um maior volume de informação com

influência directa na qualidade da decisão, nomeadamente no que diz respeito ao

diagnóstico e ao tratamento a seguir.

Estudos efectuados ao nível de união europeia [19] colocam os países nórdicos, como a

Dinamarca e a Suécia, com uma implementação quase total de RSE para os seus cidadãos,

cenário bastante diferente nos países do sul onde não existe uma utilização do RSE a

nível nacional. Em Portugal, no programa do XVIII Governo Constitucional, os SI de

saúde surgem alinhados com os objectivos globais e as prioridades da política de saúde

sendo o principal desafio, de acordo com o então Gabinete do Secretário de Estado

Adjunto e da Saúde, assegurar que até ao final de 2012, todos os portugueses possuam

um RSE.

Sobre o RSE o plano nacional de saúde 2012-2016 [12] refere que o suporte em papel e a

não integração da informação no ciclo de prestação dos serviços de saúde são obstáculos

significativos à melhoria no acesso, à qualificação dos serviços e à optimização dos

recursos. Refere também a necessidade de reengenharia e simplificação dos processos

administrativos porque automatizar os processos existentes, contribuiria apenas para

automatizar as ineficiências e modernizar a burocracia, indicando que os impactos da

desmaterialização de processos têm o potencial para melhorar muito o nível de eficiência

e eficácia dos serviços, se acompanhadas de esforços significativos de reorganização dos

processos.

Em Portugal a aplicação do RSE está a ser conduzida no sentido de ser um meio para a

reengenharia de processos que se constitui elemento fundamental para a melhoria dos

cuidados de saúde, maior produtividade e maior qualidade com menores custos. Os riscos

que podem comprometer os objectivos traçados dizem respeito à falta de envolvimento e


34

participação dos stakeholders, falta de empenho na disponibilização de novos serviços de

ehealth, bem como a não resolução de problemas associados aos níveis de acesso à

informação.

2.3. Normalização (Standards)

A saúde é um sector extremamente regulamentado e a normalização surge como forma de

assegurar a interoperabilidade dos SI. Esta interoperabilidade é vista pela HIMSS como a

“capacidade dos SI na saúde trabalharem em conjunto, quer no interior das organizações

quer atravessando fronteiras organizacionais, no suporte de uma eficaz prestação de

cuidados de saúde a indivíduos e à comunidade”.

Como é então possível um sector tão normalizado e uniformizado dispor de SI que

constituem ilhas de informação? O problema, para além da renitência na partilha devido a

questões de confidencialidade, está na informação colocada no processo clínico em

formato livre (e.g. notas clinicas) que são registadas de forma diferente pelos vários

profissionais de saúde.

Não sendo a interoperabilidade técnica, i.e, a capacidade de mover dados de um sistema

A para um sistema B sem que se tenha em consideração o significado da informação

trocada, o problema, temos na interoperabilidade semântica o verdadeiro desafio, i.e,

garantir que o sistema A e o sistema B interpretam a informação trocada da mesma forma

[20].

No âmbito da tese consideramos dois tipos de standards. O primeiro ligado à área clínica,

endereçando questões tais como a qualidade e melhores práticas, e o segundo ligado às TI

usadas na saúde, que tem o seu enfoque na garantia de comunicação entre SI, entre

equipamentos médicos e entre SI e equipamentos.

2.3.1. ISO/TR 20514:2005 Health informatics -- Elec tronic health

record -- Definition, scope and context.

O ISO/TC 215, comité técnico para a informática na saúde, visa a criação de normas

para TIC na área da saúde de forma a garantir compatibilidade e interoperabilidade

entre sistemas independentes. Uma das normas desenvolvidas é a ISO/TR 20514:2005

[21] que apresenta uma proposta para o RSE separando o conteúdo da estrutura de


35

dados, bem como definindo níveis de acesso ao mesmo distinguido zonas partilhadas e

não partilhadas.

Para além da questão do controlo no acesso a zonas partilhadas, este documento refere

a necessidade de interoperabilidade ao nível técnico/sintáctico, através da utilização de

normas concretas que permitam a troca de informação entre SI, bem como a

necessidade de interoperabilidade de nível semântico, também conseguida através do

uso de normas, garantindo que a informação trocada é entendível pelos utilizadores.

No primeiro caso estamos a falar de normas como HL7 (Health Level Seven) que

define as mensagens que são trocadas entre sistemas em formato XML (Extensible

Markup Language), e.g. a comunicação de dados, requisições e relatórios de e para

laboratórios de análises e de radiologia, receitas médicas, resumos de admissão e alta,

entre outros. No segundo caso estamos perante normas como o ICD 9 – CM; ICD 10 –

CM (International Classification of Diseases), cuja codificação permite reduzir a

ambiguidade de termos garantindo uma plataforma de entendimento comum.

2.3.2. HL7 (Health Level Seven)

Devido à sua importância ao nível da integração de SI na área da saúde, quer em

termos de interoperabilidade técnica/funcional quer em termos semânticos, será dado

aqui o destaque às normas que a Health Level Seven International, como autoridade

global para a interoperabilidade de TIC na saúde, representa. Esta organização com

membros em mais de cinquenta e cinco países, onde estão representados 90% dos

fornecedores de SI na área da saúde31, tem como missão o desenvolvimento de normas

de interoperabilidade que garantam um melhor serviço, optimizem os fluxos de

trabalho, reduzam a ambiguidade e permitam a transferência de informação entre os

vários actores desta área.

31 http://www.hl7.org/index.cfm?ref=nav


36

Figura 2-2 - Modelo Open Systems Interconnection32

Como se pode verificar na Figura 2-2, o desenvolvimento das normas HL7 são feitas

ao nível de topo, nível aplicacional, definindo a estrutura dos dados a enviar e receber,

o momento da transferência e a comunicação de potenciais erros às aplicações.

Mantendo o seu enfoque nos requisitos de interface, trata-se de um conjunto de normas

não invasivas, permitindo a manutenção de diferentes SI que através do seu uso

poderão interagir.

A HL7 International atingiu, para as suas normas, o estatuto de ISO mantendo também

relações a nível europeu com o CEN (European Committee for Standardization) bem

como com outras importantes organizações que desenvolvem normas tais como a

DICOM (Digital Imaging and Communication in Medicine) ou o IEEE (Institute for

Electrical and Electronic Engineers). A HL7 tem as suas normas organizadas em sete

categorias de acordo com o objectivo que endereçam [22], sendo três delas relevantes

para esta tese:

• Primary Standards – Usados para integração de sistemas e interoperabilidade

técnica.

• Clinical and Administrative Domains – Nesta categoria encontram-se as

mensagens e normas para as especialidades clínicas, sendo que são

normalmente implementadas após a implementação dos Primary Standards.

• EHR (electronic health record) Profiles – As normas nesta categoria fornecem

as ferramentas necessárias para a gestão dos RSE.

32 http://www.hl7.com.au/FAQ.htm


37

Com maior relevância para esta tese temos o HL7 CDA – Clinical Document

Architecture que disponibiliza uma norma para a organização de documentos

produzidos no decorrer da prestação de serviços de saúde, sendo estes codificados

através de XML e podendo incluir textos, imagens, sons ou outros formatos

multimédia que se venham a identificar como necessários. De acordo com a Figura 2-3

os documentos produzidos terão três áreas distintas: cabeçalho, corpo e entradas.

Figura 2-3 - Clinical Document Architecture33

Temos o cabeçalho com informação genérica sobre o documento que se pretende

descrever, permitindo identificar qual o tipo de documento, para além da informação

referente à própria constituição da estrutura do CDA, incluindo a semântica, as

secções do documento e a estrutura de entradas. No corpo temos a secção de texto

livre que poderá ser subdividida em secções mais restritas em termos de conteúdos e

por último temos as entradas com lista opcional de códigos que caracterizam os itens

principais referidos na secção de texto livre.

33 ACSS - Registo de Saúde Electrónico - R1: Documento de Estado da Arte - 30 de Setembro de 2009

Header • Document Type • Sender • Receiver • Patient

Body

Section(s) • Admission Details • Primary/Secondary Diagnostic • Observations • Medications • Follow-up

T E X T

Entries • Admission Details • Primary/Secondary Diagnostic • Observations • Medications

C O D E D


38

A relevância para a tese das normas referidas enquadra-se nos requisitos para a

interoperabilidade semântica dos RSE [23], i.e, serviços que garantam a

interoperabilidade técnica, existência e acordo sobre modelo para partilha de

informação, e acordo sobre conceitos e terminologia.

2.4. Arquitecturas

Podemos enquadrar a disponibilização de serviços através da internet em duas vertentes:

a vertente do modelo e a vertente arquitectural. Em termos de modelo estamos a falar do

conjunto de componentes necessários para disponibilizar o serviço. A vertente de

arquitectura conduz-nos à forma de funcionamento do serviço. Independentemente do

modelo e arquitectura a usar pretende-se elencar as alternativas de serviço que nos

permitam o acesso aos dados residentes nos sistemas verticais e a respectiva partilha de

informação de forma a fomentar o trabalho colaborativo.

2.4.1. Service-Oriented Architecture

A arquitectura baseada em serviços (SOA) é na sua essência um conjunto de serviços

que comunicam uns com os outros para a simples troca de informação ou para a

coordenação de actividades. Apesar de se poder pensar tratar-se de algo novo este tipo

funcionamento já era utilizado no passado através de DCOM (Distributed Component

Object Model) ou ORBs (Object Request Brokers) baseados na especificação CORBA

(Common Object Request Broker Architecture).

A definição de SOA, representada na Figura 2-4, baseia-se em quatro conceitos chave:

Frontend Aplicaccional, Serviço, Repositório de Serviços e Conector (Bus), sendo que

o serviço consiste numa implementação, numa interface e num contrato, garantindo

independência tecnologia bem como independência das infra-estruturas do negócio

[24].


39

Figura 2-4 – Componentes SOA

O frontend aplicaccional é o componente activo da arquitectura, sendo este que dá

inicio à actividade e que recebe os resultados. Estes frontends podem ser interfaces

Web que interagem com os utilizadores ou aplicações automáticas que são invocadas

periodicamente ou através de algum evento. O serviço é um componente de software

que encapsula lógica de negócio. Como podemos ver na Figura 2-4 este é composto

pela interface onde estão presentes as operações que este serviço realiza. A

especificação destas operações pode ser vista no contrato, nomeadamente no que diz

respeito ao objectivo, funcionalidade e restrições de uso do serviço. A implementação

mapeia a lógica de negócio que se pretende para o serviço, acedendo e

disponibilizando dados. Todos estes componentes, frontend, serviço e repositório de

serviços, estão ligados por um conector que permite a comunicação entre todos eles.

Na prática, na Figura 2-5, temos o fornecedor de serviços que implementa o serviço, a

sua lógica e os respectivos dados, define a interface e publica o mesmo num directório

ou repositório. O consumidor ao necessitar de determinado serviço procede à pesquisa

no directório. Caso encontre o serviço desejado, o directório fornece ao cliente o

endereço do serviço pretendido restando a este fazer a ligação e invocação no

respectivo fornecedor.


40

Figura 2-5 – Funcionamento SOA

De acordo com a Gartner [25] esta arquitectura é dominante nos casos em que se

antevê partilha de informação e alterações frequentes nos sistemas. Refere também que

a mais-valia na utilização de SOA deriva da rapidez/agilidade que esta permite no

desenvolvimento de sistemas, bem como na independência na sua evolução. Deriva

também da capacidade de reutilização de funcionalidades reduzindo a necessidade de

desenvolvimento e evitando duplicações, e ainda do uso de standard´s que permitem

que as boas práticas possam ser replicadas.

Em Portugal a ACSS [26] refere que as arquitecturas baseadas em serviços são o actual

estado da arte da integração de aplicações, tratando-se de um modelo de software

distribuído que tem como principais características as noções de Serviços, usados para

dividir aplicações de grande dimensão em módulos menores, Fornecedores (de

serviços), Clientes (de serviços) e Directórios (de serviços). Refere também que este

modelo possibilita a definição e criação de processos transversais suportados por

diferentes aplicações, facilitando as integrações sendo apenas necessário o

conhecimento das normas de comunicação e de uma linguagem standard entre as

componentes aplicacionais, visíveis como Serviços. A tecnologia e o conhecimento da

estrutura das aplicações a integrar passa a ser transparente.


41

2.4.2. Event Driven Architecture

Uma arquitectura baseada em eventos (EDA) consiste numa framework que faz a

gestão de eventos (produção, detecção e consumo), bem como das respostas aos

mesmos, sendo que um evento pode ser definido como qualquer alteração significativa

de estado ou qualquer acção que aconteça dentro ou fora do nosso sistema e que nele

tenha impacto34. De uma forma geral a EDA tem como componentes os produtores de

eventos, que são a fonte dos eventos, os consumidores de eventos, que correspondem

às entidades que podem estar envolvidas no processamento do evento ou que são

afectadas pelo mesmo, os detectores de eventos que fazem a detecção e o

encaminhamento dos eventos de acordo com regras estabelecidas e os processadores

de eventos que executam um conjunto de acções estabelecidas para o evento em causa.

Tipicamente existe uma subscrição por parte dos consumidores do(s) tipo(s) de

evento(s) com interesse e uma infra-estrutura para troca de mensagens entre os vários

componentes, muito à semelhança do que acontece com os message broker´s.

Os produtores de eventos e os consumidores podem estar ligados directamente (ponto-

a-ponto) ou via middleware ou broker (bus), sendo que os produtores de eventos

podem ser aplicações, processos de negócio, ou utilizadores. Após a geração dos

eventos, Figura 2-6, estes são capturados pelos detectores de eventos (agentes), e

processados e encaminhados para os consumidores através dos processadores de

eventos que detém a lógica para a recolha e encaminhamento dos eventos. O

consumidor reage aos eventos recebidos executando acções ou tomando decisões.[27].

Tipicamente, e ao contrário de SOA, os componentes da EDA interagem de forma

assíncrona sendo o processador de eventos uma das peças fundamentais e mais

complexas da arquitectura. Na EDA os produtores de eventos e os consumidores de

eventos não têm necessariamente conhecimento uns dos outros, nem os produtores de

eventos sabem qual a reacção que um determinado evento irá provocar.

34 Event-Driven Architecture Overview - http://www.omg.org/soa/Uploaded%20Docs/EDA/bda2-2-06cc.pdf


42

Figura 2-6 - Event-Driven Arquitecture

Apesar das diferenças, SOA e EDA têm características que podem servir de

complemento entre elas. Ambas usam serviços porém diferem na forma como estes

são invocados. Enquanto a SOA utiliza na maior parte dos casos web services que têm

uma dinâmica de pedido/resposta, a EDA, tal como já foi referido, fornece

mecanismos de comunicação assíncrona.


43

2.4.3. Soluções Web Baseadas em Serviços

O National Institute of Standards and Technology (NIST) identifica três formas de

disponibilizar capacidades de computação através da internet: Software as a Service

(SaaS), Platform as a Service (PaaS) e Infrastructure as a Service (IaaS) [28]. O

funcionamento por camadas na disponibilização destes serviços, espelhado na Figura

2-7, garante flexibilidade na sua escolha e utilização.

Figura 2-7 - Definição de camadas de serviços disponibilizados via internet


44

De acordo com as necessidades e com o grau de flexibilidade desejado será subscrito o

serviço mais adequado. Os conceitos subjacentes a estes serviços disponibilizados

através da internet levam-nos a definir o IaaS como um serviço de disponibilização

essencialmente de hardware (servidores, armazenamento, rede, etc) no qual os clientes

instalam o seu próprio software, tipicamente através de máquinas virtuais. Na camada

seguinte temos o PaaS que consiste na disponibilização de uma plataforma e ambiente

de desenvolvimento assente numa IaaS. Por fim o SaaS disponibiliza uma ou mais

aplicações predefinidas através da internet, aplicações essas desenvolvidas e colocadas

em produção por uma terceira parte que não o cliente final [29]. As aplicações são

normalmente acedidas por clientes web ou através de interfaces programáticas. O

cliente não tem qualquer controlo sobre a plataforma subjacente e tem capacidade

limitada de customização.

A solução proposta, que necessita de recolher e partilhar informação online, enquadra-

se numa tipologia SaaS que possua um catálogo de serviços que podem ser subscritos

pelos sistemas dos clientes finais. Esta tipologia garante ainda o acesso dos

utilizadores ao sistema independentemente da sua localização, é uma solução

transversal aos sistemas existentes na instituição e transversal às próprias instituições,

sendo o serviço prestado disponibilizado ao utilizador final via web browser.

A solução que terá uma tipologia SaaS apresenta, de acordo com os objectivos

pretendidos, a possibilidade de utilização de SOA e EDA. A componente de obtenção

de dados de síntese sobre o processo clínico dos utentes que residem nos sistemas

verticais das instituições terá uma abordagem baseada em SOA com utilização de web

services, portanto uma abordagem síncrona, que permitirá a recolha de informação

referente a dados pessoais de utentes, incluindo grupo sanguíneo, alergias, patologias,

medicação activa, exames realizados, bem como o resumo dos diferentes episódios/

intercorrências com o sistema de saúde, com impacto nulo em termos de alterações aos

sistemas verticais existentes.

A componente de monitorização e de alertas existente no serviço a disponibilizar terá

uma abordagem baseada em eventos. Esta abordagem ajusta-se às funcionalidades

pretendidas em termos de monitorização e alertas pois temos por um lado os

produtores de eventos, essencialmente os utentes através da sua colaboração na

produção de informação, e por outro, os consumidores de eventos que se


45

consubstanciam nos profissionais de saúde que subscrevem os eventos para os quais

pretendem estar ligados.

2.5. Workflow

Ao longo do tempo os SI sofreram evoluções no sentido de criar camadas de abstracção

que facilitassem a interacção com as aplicações e a gestão dos dados. Os sistemas de

gestão de base de dados (SGBD) tiveram o seu papel no que diz respeito à gestão da

camada persistente, da mesma forma que se separa e desenvolve a camada de

apresentação e interacção com o utilizador de forma autónoma. A camada que contém a

lógica do negócio, que segundo os autores [30] consiste num conjunto de procedimentos

que podem ser isolados, permite que o seu acesso e manipulação possa ser efectuado por

WFMS - Workflow Management Systems. Ainda sobre estes sistemas os autores

comparam-nos a sistemas operativos, isto é, sistemas que controlam o workflow entre os

vários recursos: pessoas e aplicações.

O workflow ou fluxo de trabalho corresponde à operacionalização de um determinado

processo de negócio onde se definem as tarefas a serem executadas, a sua ordem, o

responsável pela sua execução, bem como a respectiva sincronização entre essas mesmas

tarefas, muitas vezes com o objectivo de automatização das mesmas. Em termos formais

[31] Workflow é a automatização total ou parcial de um processo de negócio, durante a

qual informação e/ou tarefas são passadas entre os participantes: pessoas e aplicações, de

acordo com um conjunto de regras estabelecidas.

A Gartner em 200835 , afirma que a utilização de workflow irá assumir um papel

preponderante na saúde. Recomenda que as instituições de saúde adquiram competências

em ferramentas e metodologias relacionadas com workflow e que promovam projectos-

piloto de forma a adquirir experiência nesta tecnologia. Esta previsão assenta no Gartner’s

Hype Cycle, Figura. 2-8 36, que é uma metodologia que tem como objectivo caracterizar a

progressão típica de uma tecnologia emergente desde a fase mais entusiástica, passando

por um período de desilusão, e por fim, para um estado de entendimento sobre a sua

relevância e papel no mercado.

35 Gartner IR: Hype Cycle for Healthcare Provider Technologies and Standards, 2008. In.; 2008. 36 Hype Cycle Special Report for 2011.


46

Figura 2-8 - Gartner Hype Cycle Model.

Os analistas da Gartner posicionam as diferentes tecnologias com base no entusiamo que

suscitam, bem como na sua maturidade. Para representar as diferentes velocidades para

atingir o chamado “Plateau de Productivity”, a cada tecnologia é associada uma categoria

que representa o número de anos que a mesma demorará, desde a posição actual, para

atingir a maturidade que permita a sua adopção pelo mercado.

2.5.1. Modelo de Referência

Com o investimento a ser feito em soluções de workflow surgiu a necessidade de

garantir que o desenvolvimento deste tipo de soluções estivesse de acordo com

critérios previamente estabelecidos, reduzindo o risco para as organizações e

aumentando a confiança. Indo ao encontro desta necessidade a Workflow

Management Coalition (WFMC) desenvolve uma Framework para a criação de

standards de workflow, cujo modelo de referência podemos ver na Figura. 2-9.


47

Figura 2-9 – Modelo de referência de Workflow37

Este modelo foi desenvolvido a partir de aplicações genéricas de workflow

identificando as interfaces necessárias para garantir a interoperabilidade a vários níveis.

É efectivamente através da definição de interfaces e do formato dos dados a serem

trocados que se estabelece a interoperabilidade entre os vários componentes. Na

Figura 2-9 estão presentes cinco interfaces cujo objectivo é explicado na Tabela 2-2.

Tabela 2-2 – Modelo de referência de Workflow - Interfaces

Process Definition Tools

Interface (1)

Contém a especificação da interface entre as ferramentas de

definição do processo e o motor de workflow38.

Workflow Client Application

Interface (2)

Contém a definição da API (Application Programming

Interface) que pode ser usada pelas aplicações clientes para

solicitar serviços ao motor de workflow.

Invoked Application

Interface (3)

Definição da API que permite ao motor de workflow invocar

aplicações através do uso de agentes.

Workflow Interoperability

Interface (4)

Definição de normas que permitem a interoperabilidade entre

diferentes motores de workflow.

Administration & Monitoring

Tools Interface (5)

Definição das funções de monitorização e controlo

37 Fonte: http://www.e-workflow.org/standards/index.htm 38 Motor de Workflow: Software que garante o ambiente de execução para uma instância de workflow.


48

Para além das interfaces já referidas existe a necessidade, que decorre do próprio

conceito de workflow, de gerir a forma como a informação e/ou tarefas são passadas

entre os participantes: pessoas e aplicações. Tipicamente é estabelecido um conjunto

de regras que são implementadas através dos chamados motores de regras. Os

Business Rules Engine (BRE) [32] são aplicações que têm como objectivo gerir e

fazer aplicar regras de negócio e que se distinguem umas das outras pela forma como

aplicam as regras de negócio e pelo tipo de regras de negócio que suportam.

No caso da saúde, e em particular no caso do presente trabalho, o conceito de

workflow enquanto forma de operacionalização de um determinado processo de

negócio onde estão definidas as várias tarefas e os respectivos intervenientes, está

muito presente. Temos, na solução proposta, intervenientes com diferentes papeis

(roles) como é o caso dos utentes e dos profissionais de saúde e dentro destes últimos

podemos ainda ter papéis de médico, enfermeiro ou técnico. Em conjunto com os

diferentes papeis, que por si só podem desde logo garantir diferentes níveis de acesso à

informação e a funcionalidades, temos o estabelecimento de regras e fluxos de

trabalho que garantem o correcto desenrolar dos processos de negócio levantados.

Duas das principais contribuições deste trabalho dizem respeito à necessidade da

definição de um conjunto de informação que se constituirá como síntese do estado de


como as quais o SSM partilhe os utentes, e à disponibilização de planos de

monitorização que garantem o aumento da interacção do utente bem como uma maior

responsabilização do mesmo pelo seu estado de saúde. Tendo em mente estas

contribuições e o que se referiu em termos de workflow, podemos mapear as

actividades, bem como os respectivos intervenientes, que farão parte do fluxo de

trabalho para atingir os objectivos das duas contribuições referidas.

No caso concreto da síntese do processo clinico do utente surge a necessidade do

estabelecimento de um conjunto de tarefas que permitam a recolha dessa informação a

partir dos sistemas verticais existentes nas diferentes instituições, bem como a

necessidade de atribuição de permissões de acesso de acordo com o tipo de

interveniente e com o seu papel. Um utente apenas terá acesso à sua própria

informação enquanto que um profissional de saúde, no seu papel de médico, terá


49

acesso a informação de saúde de diferentes utentes, seus pacientes ou pacientes de

outros médicos.

A questão dos planos de monitorização, bem como a análise deles decorrente, conduz

à definição de um número de actividades onde profissionais de saúde e utentes

desempenham diferentes papéis com diferentes responsabilidades. Por um lado

teremos que permitir, ao profissional de saúde no seu papel de médico, a criação de

planos de monitorização com diferentes parâmetros a serem monitorizados, e por outro

permitir que um determinado individuo, no seu papel de utente, possa fazer o registo

das medições efectuadas tendo em consideração alguns aspectos tais como o ambiente

onde a medição é executada (formal ou não formal), a data em que a mesma foi

efectuada, entre outros.

Importa pois realçar que para se aplicar o conceito de worflow terão que se definir os

processos de negócio que se pretendem implementar, descrevendo em pormenor as

diferentes actividades que os constituem, a ordem pela qual essas actividades são

executadas, e ainda quais são os diferentes intervenientes e qual ou quais os papeis

associados a esses intervenientes.

2.5.2. Workflow Software

Actualmente existe uma grande variedade de oferta de software que incorpora em todo

ou em parte o modelo de referência proposto pela WFMC. Na área da saúde Vojtech

Huser em [33], conjuntamente com outros autores, implementa com base num motor

de workflow um sistema com capacidade de apoiar a decisão médica. O objectivo dos

autores deste trabalho foi a utilização das potencialidades da ferramenta de workflow

para desenhar os processos de negócio /decisão e definir as regras de negócio através

do uso do motor de regras de forma a colmatar a inexistência, no software de RSE, de

ferramentas de apoio à decisão médica, tendo como desafios a disponibilização de

interface amigável ao utilizador e a criação de workflows que mapeiem os processos

de decisão. A suite de workflow de open source utilizada é composta por um editor de

workflow (JaWE - Java Workflow Editor) e por um motor de workflow (Shark - Java

Open Source XPDL Workflow), tendo sido estendida, para os casos em que a mesma

não possui capacidade de integração, nomeadamente com sistemas de RSE, através de

pequenas aplicações ou adaptadores que possibilitam essa integração, respondendo a

eventos clínicos em tempo real.


50

Outras iniciativas também na área da saúde, mas com a utilização de software

proprietário, como é o caso da implementação de linhas mestra para a gestão de casos

de acidente vascular cerebral (AVC), foram desenvolvidas com suites de workflow

[34]. Os autores fizeram uso de Oracle workflow software suite para a gestão dos

AVC, em que o motor de workflow, para além de gerir as tarefas, enviava alertas por

email para os médicos. Mor Peleg em [35] refere que a tecnologia de workflow, com

as adaptações necessárias em termos de expansão das suas funcionalidades base, pode

constituir-se como alternativa a sistemas clínicos de apoio à decisão.

Pelos exemplos já referidos apercebemo-nos da grande variedade de software de

workflow, quer seja proprietário como é o caso da solução Oracle39 ou da ainda não

referida Microsoft através do Windows Workflow Foundation40 ou não proprietários

como é o caso das soluções Enhydra Shark41 ou o YAWL42.

Apesar da maior parte das soluções apresentarem independência tecnológica em

relação aos sistemas operativos e SGBD, trabalharem numa plataforma Web,

disponibilizarem adaptadores e conectores diversos, bem com uma arquitectura

orientada a serviços, nem todas possuem simultaneamente um editor gráfico de

workflow, um motor de workflow, um motor de regras com capacidade de mapear

regras de negócio e gestão documental. A solução IPDMS (Integrated Process Design

and Management System)43 da SINFIC (Sistemas de Informação Industriais e

Consultoria), junta num mesmo produto todas as características atrás mencionadas.

39 http://www.oracle.com/technetwork/middleware/bpel/overview/index.html 40 http://msdn.microsoft.com/en-us/netframework/aa663328 41 http://www.together.at/prod/workflow/twe 42 http://www.yawlfoundation.org 43 http://www.sinfic.pt/SinficWeb/displayconteudo.do2?numero=23859


51

3. Metodologia Proposta

O trabalho de investigação desenvolvido caracteriza-se por um trabalho sistemático baseado

no estudo de um caso específico aplicado ao SSM. O objectivo foi o de conceptualizar um

novo serviço capaz de fomentar a interacção entre o paciente e os profissionais de saúde,

permitindo simultaneamente uma participação activa do utente no seu tratamento. Seguindo a

metodologia do Design Science Research para sistemas de informação, as hipóteses

formuladas tiveram como principal desafio encontrar formas para a implementação desse

serviço.

Do levantamento efectuado no estado-da-arte pouco mais pode ser dito sobre a relevância e

utilidade de um serviço que endereça uma tipologia de problemas amplamente discutido no

sector da saúde, validado aliás pelos stakeholders com os quais foi possível interagir no

âmbito do desenho da solução proposta. Os artefactos produzidos endereçam assim tipologias

de problemas específicos de ambientes críticos (e.g., Unidade Hospitalar da Estrela do

HFAR), com requisitos de partilha de informação e trabalho colaborativo.

A pesquisa através de caso de estudo (Case Study Research – CSR) permitiu definir um plano

de trabalho com uma abordagem aos stakeholders assente em entrevistas direccionadas para

um fim específico. Procedimento alinhado com as recomendações do CSR. Este método é

normalmente usado quando se pretende fazer o estudo de um fenómeno no seu ambiente

natural, através do emprego de múltiplos métodos de recolha de informação de uma ou mais

entidades, sejam estas pessoas ou organizações [36], havendo a necessidade do

estabelecimento claro das fronteiras e âmbito do mesmo.

A abordagem ao problema levou à definição de uma metodologia que permitisse

operacionalizar a desmaterialização de processos relacionados com o acesso a dados de

síntese sobre o PCE. Para tal será necessário dispor de uma plataforma tecnológica que

garanta de forma ágil a implementação de mecanismos para a identificação unívoca dos

utentes do SSM, para a recolha de dados de síntese do estado de saúde do utente, para dar

apoio à análise de desempenho de um utente face a um universo amostral e ainda para

aumentar a interacção com o utente, nomeadamente através de planos de monitorização, que

consistem num conjunto de parâmetros clínicos e/ou antropométricos que merecem atenção

por parte do médico e cujas leituras e registos, em ambiente formal ou não formal, serão

efectuadas pelos utentes que poderão receber alertas (e.g. via SMS) no caso de os valores

registados estarem fora dos intervalos estabelecidos pelo médico.


52

3.1. Abordagem metodológica

A abordagem metodológica esquematizada na Figura 3-1 conceptualiza a necessidade de

implementação de um modelo de colaboração, que tem como objectivos principais a

agilização do fluxo de informação entre os profissionais saúde, o acesso a dados de

síntese do PCE, quer por profissionais de saúde quer pelos próprios utentes, que para

além de acederem à informação podem também contribuir com informação, de acordo

com regras estabelecidas e respectivas permissões de acesso.

Figura 3-1 - Modelo de Colaboração

Este modelo consiste numa plataforma web com interfaces de acesso (e.g. browser) aos

dados de síntese do PCE para profissionais de saúde e para os utentes, i.e., o acesso à

plataforma é efectuado de forma idêntica por todos os utilizadores porém, de acordo com

o perfil de utilizador (e.g. médico, utente), existirá mais ou menos informação disponível

e existirão mais ou menos funcionalidades.

A plataforma suporta ainda processos de negócio geridos de acordo com um conjunto de

regras procedimentais e onde a informação é definida em termos de metadados, i.e.,


53

através de um conjunto de entidades relacionadas entre si, caracterizadas pelos seus

atributos. A informação de síntese é disponibilizada para a plataforma web através de

conectores que servem de interface entre esta plataforma, os sistemas de informação

hospitalar e os diversos sistemas de informação departamentais como é o caso da área da

imagiologia e da patologia clinica entre outros. Estes conectores, seguindo uma lógica

orientada aos serviços, baseiam-se em webservices que ao serem invocados fornecem

informação sobre os utentes, informação essa residente nos sistemas verticais existentes.

A informação extraída dos sistemas verticais e a nova informação produzida pelos

profissionais de saúde e pelos utentes, nomeadamente no caso dos planos de

monitorização, é armazenada em repositório central para acesso posterior, de acordo com

a lógica das entidades levantadas e respectivos atributos (metadados).

3.2. Modelo de colaboração

Em termos tecnológicos o modelo assenta na utilização de uma plataforma de gestão por

processos com mecanismos de workflow, gestão de regras, bem como de uma

componente de gestão de indicadores associados a mecanismos de alerta para um apoio

efectivo ao trabalho do profissional de saúde. Em termos concretos importa separar as

várias componentes deste modelo por forma a ser possível fazer o detalhe das mesmas.

Assim teremos uma componente SaaS que consiste na plataforma web a ser

disponibilizada e que funcionará, de acordo com os diferentes processos, de forma

síncrona ou assíncrona, isto é, fazendo uso de uma arquitectura orientada a serviços bem

como de uma arquitectura orientada a eventos. Teremos toda a parte de conectores aos

sistemas verticais existentes e de autenticação dos utilizadores desenvolvida em ambiente

SOA fazendo uso de web services e toda a parte planos de

monitorização/acompanhamento e alertas desenvolvida numa lógica EDA.

3.2.1. Componente orientada a serviços

As principais componentes orientadas a serviços dizem respeito à necessidade de

recolha de dados por forma a criar a respectiva síntese ou BI clínico do utente e ainda

para gerar a lista de intercorrências do utente com as diferentes instituições de saúde,

para além das funcionalidades de suporte tais como a autenticação dos utilizadores e

atribuição dos respectivos papéis.


54

Esta recolha será efectuada através do estabelecimento de conectores entre a

plataforma web proposta e os sistemas de informação existentes nas instituições de

saúde, conectores estes baseados em web services. Neste ponto foram equacionados

vários modelos de implementação tendo em consideração, tal como efectuado em

estudo da ACSS [26], o local de armazenamento dos dados de síntese do utente e das

credenciais dos utilizadores e ainda a forma de transacção dos dados. No que ao

armazenamento diz respeito temos:

• Em repositórios locais às entidades onde são produzidos, nos diversos

encontros e episódios de prestação de cuidados;

• Em repositório centralizado

• De uma forma distribuída, em repositórios dispersos local e centralmente

Em termos de transacção dos dados as opções são:

• Push: os sistemas das diferentes entidades “empurram” os dados para o

repositório central;

• Pull: o repositório central “puxa” os dados dos sistemas das diferentes

entidades;

• Push/pull: permite a entrega de dados por parte dos sistemas das diferentes

entidades, bem como a recolha de dados por parte do repositório central.

No nosso modelo a opção passa, em termos de armazenamento, por uma solução de

repositório central que, em termos de informação, apenas terá a necessária para definir

os utilizadores e suas credenciais bem como os dados de síntese ou BI clínico do

utente e ainda a lista de intercorrências ou episódios nas diferentes instituições de

saúde. No que à forma de transacção diz respeito, isto é, forma de ligação aos sistemas

de informação existentes nas diferentes instituições de saúde, a opção recai sobre a

opção mista “Push/Pull” garantindo desta forma maior flexibilidade na obtenção de

informação.

De acordo com a Figura. 3-1 teremos na plataforma a necessidade de conter

informação para acesso à mesma sendo por isso obrigatório o registo dos utilizadores

nos seus diferentes papeis. Este componente terá associado um web service que fará a

recolha de informação para a criação dos utilizadores, nomeadamente no que diz

respeito ao seu ID, papel associado e respectiva password. Para todos os utentes será


55

utilizado para identificação perante o sistema o par (nº de contribuinte, nº SNS) e no

caso dos profissionais de saúde será utilizado o par (nº da ordem, nº de contribuinte).

Haverão posteriormente métodos que garantam a possibilidade do utilizador fazer a

alteração da respectiva password e a recuperação da mesma no caso de esquecimento.

Em termos da informação relativa ao do utente esta está organizada em três secções,

sendo as duas primeiras aquelas em que se irá seguir uma lógica orientada a serviços.

Temos pois a secção de síntese ou BI clinico do utente que será subdividida em duas

sub-secções: A sub-secção de identificação do utente, onde consta uma identificação

unívoca do utente (Número do SNS, Número de contribuinte) e os chamados dados

demográficos: nome, data de nascimento, idade, foto, género, etnia, morada, contactos,

subsistema de saúde, e nº de beneficiário, e a subsecção de perfil clinico do utente com

informação referente a peso, altura, IMC, grupo sanguíneo, antecedentes pessoais e

familiares, medicação activa, patologias ou doenças activas, exames complementares

de diagnóstico referentes aos últimos 3 meses e cirurgias.

Temos ainda a secção referente à lista de intercorrências / episódios onde se colocará

um registo cronológico de todos os episódios do utente com o sistema de saúde. Estas

intercorrências/episódios contêm informação sobre os quatro tipos de episódios mais

comuns: episódios de consulta (especialidade e urgência), episódios de internamento,

cirúrgicos e relativos a execução de exames complementares de diagnóstico e

terapêutica. A recolha de informação comum a todos os episódios baseia-se na data de

realização do episódio, no tipo de episódio, no médico e na instituição de origem. Para

cada um dos tipos de episódio será recolhida a seguinte informação:

• Episódio Consulta

Especialidade, Resumo.

• Episódio Internamento

Data da Baixa, Data da Alta, Motivo da Alta, GDH.

• Episódio Cirurgia

Especialidade, Diagnóstico, Procedimento

• Episódio Exame

Especialidade, Descrição, Resultado.

A componente orientada a serviços é pois uma componente em que teremos um nível

mais baixo de interactividade com o profissional de saúde visto se consubstanciar num


56

resumo de informação que permite dar a conhecer o perfil clinico do utente, isto

apesar de ser possível a esse profissional de saúde inserir informação que ache

pertinente neste capítulo (e.g. medicação activa do utente).

3.2.2. Componente orientada a eventos (EDA)

Duas das principais contribuições desta tese dizem respeito ao aumento da interacção

com o utente fazendo que este assuma uma maior responsabilidade pelo seu estado e

hábitos de saúde, essencialmente garantida pela criação e disponibilização de planos

de monitorização e ainda pelo apoio à análise do desempenho de um utente face a um

universo amostral, através da definição das variáveis que permitem identificar a

amostra e dos parâmetros que se constituem como indicadores. É para a

implementação destas contribuições que será utilizada uma filosofia baseada em

eventos.

A componente de planos de monitorização (indicadores) é na sua essência uma

componente orientada a eventos, permitindo ao médico a criação dos planos de

monitorização, recolhendo a informação dos sensores e gerando os alertas de acordo

com as regras estabelecidas. Para os planos de monitorização foi, no decurso de

reuniões com pessoal clínico, levantado um conjunto de parâmetros antropométricos e

clínicos relevantes que permitem aos médicos traçar os planos de monitorização aos

seus doentes.

Esta última secção terá, numa lógica orientada a eventos, a capacidade de

estabelecimento de indicadores clínicos de acompanhamento do utente que forneçam

alertas com base em evidência científica e garantam um apoio efectivo ao trabalho do

médico. Neste nível o utente terá capacidade de interacção com o sistema, não apenas

para consulta de informação mas, e mais importante, como veiculo de produção de

informação. Como exemplo poderemos ter o seguimento de doentes diabéticos ao

nível da medição da tensão arterial e do BMT (Blood Medical Test – Glicémia Capilar)

para controlo do açúcar no sangue. Podemos ter ao nível da cardiologia os valores do

INR (International Normalized Ratio) para o controlo do tempo de coagulação do

sangue ou ainda a evolução da função renal através de parâmetros de análise tais como

a ureia, hemoglobina, creatinina, bem como o registo da tensão arterial e peso antes e

depois dos tratamentos.


57

3.2.3. Metadados de suporte à metodologia proposta

No modelo de colaboração apresentado temos como objectivos a agilização do fluxo

de informação entre os profissionais saúde, o acesso a dados de síntese do PCE, quer

por profissionais de saúde quer pelos próprios utentes, de acordo com regras

estabelecidas e respectivas permissões de acesso, sendo o focus do nosso trabalho os

processos de negócio onde a informação é definida em termos de metadados, o

conjunto de regras procedimentais que possibilitam ou não a sua disponibilização e o

funcionamento dos conectores entre os SI existentes e a plataforma Web que suportará

o fluxo de informação.

Procura-se com este trabalho promover a harmonização da informação que é

disponibilizada potenciando a sua fluidez através de um modelo como o da Figura 3-1

em que se apresentam três secções ou conjuntos de informação. A primeira secção

consiste na síntese ou BI clinico do utente que será subdividida em duas sub-secções: a

sub-secção de identificação do utente e a subsecção de perfil clinico do utente. A

segunda secção contém informação referente à lista de intercorrências / episódios do

utente com o sistema de saúde, e por último temos a secção de indicadores com os

respectivos planos de monitorização e acompanhamento que permite o

estabelecimento de indicadores clínicos de acompanhamento do utente e a definição

dos alertas associados aos parâmetros e medições efectuadas.

Para a determinação da informação relevante a constar nas diferentes secções e para a

determinação da sua organização foram realizadas diversas entrevistas a profissionais

de saúde, designadamente:

• Dr.º Luís Gusmão – Nefrologia;

• Dr.º Paulo Lúcio – Hemato-oncologia;

• Dr.º Eduardo Fazenda – Gastroenterologia ;

• Dr.º Ricardo Ferreira– Cardiologia;

• Dr.º Evangelista Rocha – Cardiologia;

• Dr.º Jácome de Castro – Endocrinologia;

• Dr.º Nunes Correia – Endocrinologia;

• Dr.º Luís Gardet – Endocrinologia;

• Dr.ª Filomena Almeida – Anatomia Patológica / Codificadora.


58

Destas entrevistas resulta o modelo de domínio da Figura 3-2 onde estão representadas

as classes/entidades e as respectivas relações entre elas. Este modelo de domínio

garante não só a possibilidade de armazenamento da informação em si, mas também

garante a organização da informação tendo em vista a sua posterior utilização nas

diferentes secções, que no seu todo constituem a visão que pretendemos para o PCE

do utente.


59

Figura 3-2 - Modelo de Domínio


60

A componente de síntese ou BI clinico do utente é uma componente orientada a

serviços que, apesar de permitir a introdução de dados directamente pelo utilizador,

vai recolher a informação relativa ao utente aos sistemas clínicos existentes via web

services. A informação, de acordo com a Figura 3-3, está agrupada em quatro grandes

grupos. No utente teremos a informação demográfica e alguns parâmetros

antropométricos que podemos analisar em maior detalhe na Tabela 3-1, temos depois

uma composição de antecedentes que se subdividem em pessoais e familiares, a

medicação activa, isto é, medicação prescrita nos últimos seis meses, a medicação

crónica, e as patologias ou doenças activas tais como a diabetes ou a hipertensão

arterial.

Figura 3-3 – Síntese / BI Clínico do Utente

Ainda na Figura 3-3 é possível verificar a existência de episódios do âmbito cirúrgico

e da área de exames complementares de diagnóstico. No primeiro caso teremos em

atenção o critério tempo, isto é, procedimentos cirúrgicos com menos de 6 meses, bem

como o procedimento em si, dando ênfase a procedimentos relacionados com

extracção de órgãos. No segundo caso, o dos exames complementares de diagnóstico,

teremos em consideração o critério tempo, seleccionado aqueles efectuados há menos

de 3 meses.


61

Na Tabela 3-1 podemos em maior detalhe analisar o tipo de informação que as

entidades representadas na Figura 3-3 poderão conter. Esta tabela reflecte pois a

informação que estará disponível para o profissional de saúde, independentemente do

sistema vertical que o mesmo poderá estar a utilizar.

Tabela 3-1 – Síntese / BI Clínico do Utente

Entidade Informação

Utente Nº utente; Nome, Foto, Data de Nascimento e Idade, Género, Etnia, Peso, Altura, IMC, Grupo Sanguíneo.

Na agregação com os episódios de exames complementares recolhe:

Data Exame, Descrição, Especialidade, Resultado, Local da Realização

Antecedentes Na componente de antecedentes pessoais teremos patologias passadas tais como AVC´s ou doenças infecciosas como por exemplo a tuberculose, complementados com episódios cirúrgicos relevantes (critério tempo e procedimento), indicando:

Data da Cirurgia, Cirurgião, Diagnóstico, Procedimento, Especialidade e Local de Realização da Cirurgia.

Na componente de antecedentes familiares teremos indicação da história familiar ou genética com indicação das patologias (Ex: diabetes, neoplasias malignas, doenças cardíacas, alergias)

Medicação Activa

Indicação da medicação prescrita à menos de 6 meses e medicação crónica.

Código Medicamento, Nome medicamento, Substância activa, Data da Prescrição, Data início da toma, indicação de medicação crónica.

Patologias Serão colocadas as doenças activas do utente.

Código, Descrição, Data de Atribuição, Médico, Local de origem

A componente da lista de intercorrências do utente com as instituições de saúde, à

semelhança da componente de BI clínico, é uma componente orientada a serviços

tendo como fonte quase exclusiva de informação os diferentes sistemas verticais que

possuem informação do utente. Como é mostrado na Figura 3-4 a lista de

intercorrências consiste num conjunto de episódios que podem ser de quatro tipos:

Episódios cirúrgicos, de consulta, de internamento e de meio complementar de

diagnóstico e terapêutica.


62

Figura 3-4 – Lista de intercorrências

Na Tabela 3-2 apresenta-se a informação a constar na lista de intercorrências que

consiste no conjunto histórico de episódios que o utente vai possuindo fruto da sua

interacção com as diferentes instituições de saúde. De referir que, para além de

informação específica de cada um dos episódios, teremos comum a todos a data de

realização do episódio, o médico e a instituição de origem.

Tabela 3-2 – Lista de intercorrências


Episódio Data Realização, Instituição de Origem, Médico

Episódio Consulta

Especialidade, Resumo.

Episódio Internamento

Data da Baixa, Data da Alta, Motivo da Alta, GDH, Diagnóstico

Episódio Cirurgia

Especialidade, Diagnóstico, Procedimento

Episódio Exame Especialidade, Descrição, Resultado.


63

Por último, a Figura 3-5 tem a representação da componente de planos de

monitorização. Trata-se de uma componente orientada essencialmente a eventos,

permitindo ao médico a criação dos planos de monitorização, recolhendo a informação

dos sensores e gerando os alertas de acordo com as regras estabelecidas.

Figura 3-5 – Planos de Monitorização

A informação constante nas entidades chave desta componente pode ser analisada na

Tabela 3-3. De salientar a existência de classes associação que servem, de um modo

geral, como desmultiplicador de relações muitos-para-muitos ou para adicionar

informação a uma relação entre outras duas classes. A Tabela 3-3 apresenta a

informação a constar nas entidades com maior relevância para os planos de

monitorização.


64

Tabela 3-3 – Planos de Monitorização


Plano Monitorização

Os planos de monitorização terão: data de criação, data de início e data fim do plano, médico responsável, o contexto de criação (e.g. em consulta de especialidade), duração e estado (e.g. activo ou inactivo)

Parâmetro A entidade parâmetro irá conter uma listagem de parâmetros que o médico pode utilizar. Cada parâmetro tem associado os seguintes atributos: tipo, sigla, descrição, valores máximos e mínimos recomendados, fórmula de cálculo e unidade de medida.

Parâmetro_Plano Esta entidade corresponde aos parâmetros que efectivamente foram adicionados a um determinado plano de monitorização. Para se fazer a ligação entre os planos e o parâmetro, esta entidade terá de ter o ID do plano e o ID do parâmetro.

Sensor A entidade sensor irá conter uma listagem de sensores que o médico pode utilizar para um determinado parâmetro. São atributos do sensor: marca, modelo, fabricante, estado (e.g. operacional, inop).

Sensor_Parâmetro Esta entidade corresponde ao sensor que efectivamente foi associado a um parâmetro do plano. Para além do ID do sensor e do ID do parâmetro do plano esta entidade tem ainda os seguintes atributos: tipo de fornecimento (e.g. empréstimo, adquirido) e origem (e.g. Instituição de saúde, farmácia).

Medição Os parâmetros do plano podem ter várias medições efectuadas ou não por sensores. Para a medição os atributos são: ID do parâmetro do plano, valor, tipo de ambiente (e.g. formal ou não formal) e timestamp.

Frequência de recolha

Esta entidade possui os atributos necessários para poder uniformizar as escolhas das frequências de recolha. Os atributos são: Periodicidade, hora, dias semana e dias mês.

Regra As regras são construídas e aplicadas a um determinado parâmetro do plano. Para o fazer têm como atributos: ID do parâmetro do plano, descrição e condição aplicada.

Alerta Esta entidade faz a sua ligação com a regra através do ID da regra e possui ainda como atributos os seguintes: remetente, contacto do remetente, parâmetro, valor, severidade (e.g. baixa, média ou alta) e timestamp.

Contacto_Regra A entidade contacto_regra é uma entidade que faz a ligação entre a regra e a entidade contacto, possuindo como atributos o ID da regra e o ID ou id´s do contacto, que não é mais do a lista de destinatários dos alertas gerados por uma determinada regra.


65

O detalhe do modelo de domínio, nomeadamente a descrição mais exaustiva das

classes, seus atributos e métodos podem ser analisados no Anexo E – Modelo de

Domínio – Classes, seus Atributos e Métodos.

Já foram referidas as três secções que constituem a síntese do PCE do utente no

âmbito do trabalho que está a ser desenvolvido: Síntese ou BI clinico do utente,

Sumário Clínico ou lista de intercorrências/episódios e Indicadores com os planos de

monitorização e acompanhamento.


66

4. Case Study

O SSM, guarnecido por profissionais de saúde militares e civis, para além de um conjunto de

serviços específicos de saúde militar que o diferencia do SNS, contempla o apoio hospitalar e

serviços de cuidados primários, à “Família Militar”, i.e, familiares e dependentes dos militares,

bem como às forças de segurança, como é o caso da Guarda Nacional Republicana, Policia de

Segurança Pública e Policia Municipal, e seus respectivos familiares, e nalguns casos, aos

próprios beneficiários da ADSE, num total de aproximadamente 1.659.90 (Um milhão

seiscentos e cinquenta e nove mil e noventa) potenciais utentes, caso consideremos os

beneficiários da ADSE e cerca de 297.008 (Duzentos e noventa e sete mil e oito) não

considerando os beneficiários da ADSE.

O SSM contempla a vertente dos cuidados diferenciados ao nível hospitalar e possui unidades

que prestam cuidados primários, essencialmente executados pelos postos de socorros e

centros de saúde de menor dimensão e diferenciação, sendo o foco da reestruturação em curso

sobretudo a componente hospitalar. A Unidade Hospitalar da Estrela (UHE) pertencente ao

HFAR, instituição que servirá de suporte ao caso de estudo, é parte integrante do SSM,

encontrando-se em fase de transformação e reorganização com vista a criar um novo modelo

de gestão hospitalar que abrange um conjunto de recursos, nomeadamente humanos, materiais,

financeiros e de infra-estruturas dos hospitais militares dos três ramos.

4.1. Caracterização da Unidade Hospitalar da Estrel a

A UHE iniciou durante o ano de 2005 a substituição do Sistema de Informação de Gestão

Hospitalar existente por uma solução modular alinhada com o roadmap traçado pela

direcção do hospital. Esta visão estratégica contemplava um conjunto de projectos a três

anos e cujo objectivo consistia num sistema integrado, no qual estivessem presentes as

diferentes áreas de trabalho. Desta forma deu-se início em Dezembro de 2005 à

exploração do sistema através da sua componente mais administrativa e que contemplava

a gestão de doentes, consulta externa e internamento. Durante o ano de 2006 avançou-se

para a área de facturação, laboratório de análises clínicas, serviço de imunohemoterapia,

integração com agrupador de Grupo Diagnóstico Homogéneo (GDH), no caso do

internamento, e disponibilização de ferramenta de cariz mais clínico para apoio do

trabalho médico.


67

Em 2007 implementou-se a área de bloco operatório e chegou-se a um estado de

estabilidade e maturidade que permitiu o desencadear do processo de estudo de uma

solução de Business Intelligence que permitisse à organização tirar melhor partido da

informação existente, procurando utilizá-la como contributo para o apoio à decisão e

ainda para resolver alguns problemas em termos de custos e de performance do sistema.

Para além de pequenos projectos, como o aviso aos utentes por SMS (Short Message

Service) dos actos médicos de ambulatório (marcação e remarcações de consultas),

iniciou-se em 2010, antevendo a sua obrigatoriedade, a prescrição electrónica de

medicamentos para a farmácia de oficina. Para além desta funcionalidade, dotou-se o

sistema de ferramenta que permite aos médicos registar informação clínica, de forma

estruturada, sobre os utentes, prescrever mcdt´s e visualizar resultados de análises

realizadas no hospital.

O universo potencial de utentes da UHE, na ordem dos 300.000 beneficiários, provém

essencialmente, como se pode consultar na Tabela 1-2, do somatório dos beneficiários

dos subsistemas de saúde dos militares das forças armadas e forças de segurança. Como

mostra a Figura 4-1 a UHE tem vindo a registar os utentes no sistema de informação

clínica desde 2005 tendo neste momento cerca de 88% do total de beneficiários inseridos

em sistema. O valor de 2005, na ordem dos duzentos e vinte mil utentes inscritos

justifica-se pela migração dos dados da anterior aplicação para o novo sistema em vigor

desde Dezembro de 2005.

Figura 4-1 - Criação de Fichas de Utentes (Anos 2005 a 2011)

Como será lógico grande parte destes potenciais utentes não se consubstanciam como

utentes da UHE. O que se procura mostrar com a Figura 4-2 é o número de interacções


68

distintas, por ano, que este universo de utentes realizou com o hospital permitindo ter

assim a noção do número de diferentes beneficiários que recorreram aos serviços da UHE.

O valor de 2005, alto para apenas um mês de actividade em comparação com os restantes

anos, mais uma vez reflecte a situação de migração de dados entre sistemas. Levando em

linha de conta o total de interacções distintas entre 2005 e 2011 podemos verificar que

cerca de 27.6% dos 300.000 potenciais utentes recorreram aos serviços de saúde do

hospital.

Figura 4-2 – Interacção com Utentes (Anos 2005 a 2011)

Como se pode ver na tabela 4-1, o hospital presta serviços nas diversas áreas de cuidados

de saúde quer seja Consulta Externa, Urgência, Internamento, Cirurgia e Meios

Complementares de Diagnóstico e Terapêutica. Tem uma capacidade instalada de 177

camas, oferecendo serviço ambulatório em 29 especialidades44. Em termos de consultas,

ambulatório e urgência temos um total de 73.370 e mais de meio milhão de mcdt

realizados, com maior expressão na área da imagiologia, patologia clínica e medicina

física e de reabilitação, salientando que a urgência se trata de um serviço comum aos três

ramos das forças armadas. No que diz respeito ao internamento, contabilizando para as

entradas e número de dias de internamento o serviço de observações, temos

respectivamente 2.761 doentes entrados e 29.235 dias de internamento. No âmbito da

cirurgia os valores apontam para as 2.002 intervenções, contabilizando 1.590 utentes

operados.

44 Anexo B – Relação de especialidades da UHE.


69

Tabela 4-1 – Actividade da UHE – Ano 201145

Tipo Valor

Consulta Externa (realizadas) 57.986 Urgência 15.384 MCDT´s 502.883 Internamento Entradas – 2.761

Dias de internamento – 29.235 Demora média – 7 dias

Cirurgia 2.002 Intervenções

No que a infra-estruturas hospitalares diz respeito a Tabela 4-2 permite ter uma noção da

dimensão deste hospital que se encontra, em termos de classificação, equiparado a

hospital regional. Podemos ver, para além do que já foi referido no âmbito da capacidade

de internamento, a existência de 77 gabinetes para consultas externas, seis salas

operatórias que se encontram agrupadas em dois blocos, o bloco central com quatro salas

e o bloco de ortopedia com as restantes duas salas. Saliento também nesta tabela a

capacidade em termos de hemodiálise e de imuno-hemoterapia, sendo este realce

efectuado pois são serviços comuns aos três ramos das forças armadas.

Tabela 4-2 – Infra-estruturas Hospitalares – Ano 201146

Infra-estruturas Hospitalares UHE

Salas operatórias (incluídas ou não em bloco operatório) 6

Gabinetes de consulta externa 77

Eq

uip

amen

tos

de

dia

gnó

stic

o e

de

tera

pêu

tica

Endoscopia 9

Hemodiálise (indicar o nº de dialisadores) 12

Imag

iolo

gia

Ecografia 14

Imagiologia convencional (Raios X)

17

Mamografia 1

Osteodensiometria 1

Tomografia computorizada (TC)

1

Outros (discriminar) 1

Laboratórios de anatomia patológica e tanatologia Sim

45 Fonte: UHE- Gabinete estudos técnicos – Anuário 2011 46 Idem


70

Infra-estruturas Hospitalares UHE

Laboratórios de patologia clínica Sim

Medicina nuclear Não

Raios Laser Não

Serviços de imuno-hemoterapia Sim

Serviços farmacêuticos Sim

A UHE opera com um conjunto de profissionais de saúde, militares e civis, quer sejam

médicos, enfermeiros e técnicos ou pessoal administrativo. Estes recursos humanos, que

se encontram em diferentes situações em termos de vínculo à instituição tais como:

quadro permanente (QP - militares), quadro permanente de civis do exército (QPCE),

regime de contrato de trabalho em funções públicas (RCTFP) e regime de contrato de

prestação de serviços (RCPS), garantem o funcionamento das diferentes especialidades,

serviços de meios complementares de diagnóstico e terapêutica, serviços de internamento,

blocos operatórios e serviços administrativos de suporte. A Tabela 4-3 resume, por

classes, o pessoal ao serviço na UHE.

Tabela 4-3 – Pessoal ao Serviço da UHE – Ano 201147

Pessoal ao serviço UHE

Pessoal dirigente 3

Pes

soal

méd

ico

Médicos especialistas e Chefes de Clínica 131

Médicos internos 29

Outro pessoal médico 31

Sub-Total 191

Outro pessoal técnico superior 14

Pes

soal

de

enfe

rmag

em

Enfermeiros especialistas 6

Enfermeiros não especialistas 187

Outro pessoal de enfermagem

Sub-Total 207

Pessoal técnico de diagnóstico e terapêutica 72

Pessoal técnico-profissional e administrativo 88

Pessoal auxiliar de acção médicas 64

47 Fonte: UHE- Gabinete estudos técnicos – Anuário 2011


71

Pessoal ao serviço UHE

Pessoal dos serviços gerais 126

Socorristas 46

Outro pessoal 0

TOTAL 797

Para a caracterização do hospital em termos de pessoal não se achou necessário mostrar a

distribuição do pessoal por serviços ou especialidades, no entanto é de referir que no

pessoal médico estão incluídos os médicos dentistas e que no item “Outro pessoal técnico

superior” estão incluídos os técnicos superiores de saúde do ramo farmácia e do ramo

psicologia clínica.

Para a realização do caso de estudo e implementação do projecto-piloto de monitorização

de doentes crónicos, foram seleccionados, de entre os diversos serviços contactados

durante a fase de entrevistas, os serviços de Endocrinologia e Cardiologia tendo em

consideração o acompanhamento que nestes serviços é efectuado a doentes crónicos,

nomeadamente doentes diabéticos e hipertensos.

4.2. Infra-estrutura Tecnológica

A dispersão das infra-estruturas físicas da UHE, que possui três edifícios fisicamente

separados, deu origem à necessidade do estabelecimento de uma rede de bastidores,

interligados por fibra óptica, que garantisse a comunicação entre os diferentes edifícios e,

no seu interior, a ligação entre os diversos serviços bem como aos utilizadores. A Figura

4-3 é representativa da rede instalada no hospital, correspondendo cada nó a um bastidor.

Os nós assinalados correspondem aos bastidores que fazem a interligação entre os três

edifícios.


72

Figura 4-3 – Rede de Bastidores UHE

Sendo a componente de rede uma das sustentações da alta disponibilidade das aplicações

de saúde foi efectuada a sua restruturação estando actualmente disponível ligação de fibra

óptica entre todos os nós da rede, conseguindo-se ter uma velocidade de ligação ao

equipamento terminal de 1 Gigabit.

O hardware de suporte às aplicações de saúde, também ele componente essencial para a

alta disponibilidade, sofreu em 2007 remodelação por forma a garantir, não só uma

melhor performance dos sistemas em produção, mas também para garantir a existência de

um ambiente de desenvolvimento e de testes. Na Tabela 4-4 estão enumeradas as

características e quantidades dos equipamentos que sustentam as aplicações de saúde bem

como as aplicações de suporte tais como o serviço de directório (Active Directory), DNS

(Domain Name Service) e DHCP – (Dynamic Host Configuration Protocol).


73

Tabela 4-4 – Hardware (aplicações de saúde e de suporte)

Servidores Aplicacionais Servidores de Base de dados

Hardware Software Hardware Software

Ambiente de Produção

(1 servidor aplicacional e 2 servidores de base de dados em cluster)

• Memoria: 8GB

• Processador: 1 x QUAD-CORE

• Discos para instalação do software: 2 x 146GB

• Sistema de Discos partilhado (SAN) com 1TB

• OS: Windows 2003 R2 x64 enterprise edition

• Outros: IIS

• Memoria: 8GB

• Processador: 1 x QUAD-CORE


• Sistema de Discos partilhado (SAN) com 1TB48


• RDBMS: Oracle 10GR2 x64 standard edition49

• SGBD: SQLServer 2005 standard edition

Ambiente de Desenvolvimento / Testes

(1 servidor que é simultaneamente aplicacional e de base de dados)

• Memoria: 8GB

• Processador: 1 X QUAD-CORE


• Sistema de Discos partilhado (SAN) com 1TB50


• RDBMS: Oracle 10GR2 x64 standard edition

• SGBD: SQLServer 2005 standard edition

• Outros: IIS

Aplicações de Suporte

(2 servidores com a mesma configuração)

• Memoria: 4GB • Processador: 2 x

XEON DUAL-CORE


• OS: Windows 2003 R2 x32 enterprise edition Outros: AD, DNS, DHCP

Para além do hardware a Tabela 4-4 dá a indicação do software em uso nomeadamente no

que diz respeito a sistemas operativos (SO) e sistemas de gestão de base de dados (SGBD)

em ambiente de produção e em ambiente de desenvolvimento e testes. Refere ainda a

configuração dos dois equipamentos que têm instaladas as aplicações de suporte.

O motor de base de dados que suporta as aplicações de saúde consiste num cluster oracle

por forma a garantir uma redundância no que diz respeitos às instâncias que estão

disponíveis para as aplicações. O armazenamento dos dados é efectuado numa storage

MSA1500 com capacidade actual de 1 TB. Esta capacidade, tendo em consideração a não

48 O mesmo do servidor aplicacional 49 Esta versão de licenciamento inclui clustering para dois nós. 50 O mesmo do servidor aplicacional (de produção)


74

existência de sistema PACS (Picture Archiving and Communication System), serve as

necessidades do hospital, permitindo a sua partilha com o servidor aplicacional bem

como com o servidor de desenvolvimento e testes. Apenas para referência, o espaço

ocupado pela base de dados de produção é de 25 GB 51. Será esta a infra-estrutura

disponível para suportar o protótipo/piloto da solução proposta.

4.3. Sistemas Clínicos em Produção

A UHE possui, desde Dezembro de 2005, um conjunto de aplicações clinicas e

administrativas fornecidas pela empresa CPCHS, agora GLINTTHS. A Tabela 4-5

mostra-nos um resumo dessas aplicações bem como a sua área de utilização e

destinatários, remetendo para o Anexo C – Aplicações / Módulos de Saúde em Produção

na UHE um maior detalhe sobre cada um dos módulos aplicacionais.

Tabela 4-5 – Aplicações / Módulos de Saúde em Produção na UHE

Aplicação / Módulo

Área de Utilização Destinatários

GH – Gestão de doentes

Secretariado Administrativos em apoio ao internamento e ambulatório

GH – Consulta externa e ambulatório

Secretariado Administrativos em apoio ao internamento e ambulatório

GH – Gestão do Internamento

Secretariado e internamento

Administrativos e enfermeiros em apoio ao internamento.

Factus Financeira Administrativos em apoio à logística e financeira.

EPR – Desktop Médico

Clínica Médicos (internamento, ambulatório e bloco)

EResults Clinica Médicos, enfermeiros e técnicos (internamento, ambulatório e bloco)

Bloco Operatório Clinica (Salas Bloco) Médicos e enfermeiros do bloco operatório

Sibas e Sislab Laboratórios Médicos, enfermeiros e técnicos dos serviços de Imunohematologia e Patologia Clínica

SIG (Indicadores) Gestão / Informática Administradores Hospitalares e Gabinete de estudos técnicos

51 Valor em 10 de Setembro de 2012.


75

Para além das aplicações/ módulos da Tabela 4-5 foram sendo desenvolvidas ao longo do

tempo algumas funcionalidades com objectivos muito específicos como é o caso do aviso

de marcação /remarcação de consultas e exames por SMS, bem como o envio dos

resultados das análises clínicas por correio electrónico. No que a integrações diz respeito

apenas gostaria de salientar a integração que é efectuada com o agrupador fornecido pela

empresa 3M e que permite, através do módulo de gestão do internamento, fazer a

codificação dos episódios e a consequente geração do código de GDH (Grupo

Diagnóstico Homogéneo) com o qual será possível efectuar a facturação desses episódios.

4.4. Cenário Clinico

Durante a recolha de informação através de entrevistas e reuniões com pessoal clínico da

UHE, nomeadamente médicos dos serviços de nefrologia, cardiologia, hematologia,

imagiologia, endocrinologia e nutrição e ainda médicos com trabalho específico na área

da codificação e produção de GDH, seleccionaram-se os serviços de cardiologia e

endocrinologia e nutrição como os serviços que irão participar na realização do caso de

estudo no que à monitorização de doentes diz respeito. Esta escolha deriva do facto dos

doentes acompanhados nestes serviços terem um perfil clinico adequado às necessidades

da componente de monitorização e alertas. São na sua maioria doentes que padecem de

patologias crónicas, com necessidade de controlo dessas mesmas patologias através da

medição dos parâmetros e visitas regulares ao hospital.

4.4.1. Serviços Clínicos Objecto do Estudo

Com a Tabela 4-6 pretende-se fazer a caracterização dos serviços de cardiologia e

endocrinologia e nutrição em termos de recursos humanos nomeadamente no que diz

respeito a médicos, enfermeiros, técnicos e pessoal administrativo e auxiliar,

permitindo depois associar estes recursos à produção, em concreto no que a consultas

e exames realizados diz respeito.


76

Tabela 4-6 – Recursos Humanos – Cardiologia / Endocrinologia e Nutrição52

Serviço Tipo de Recursos Quantidade

Cardiologia Médico 7

Enfermeiro 1

Técnico 5

Administrativo /Auxiliar 3

Endocrinologia e Nutrição Médico 5

Enfermeiro 2

Técnico 3

Administrativo /Auxiliar 2

4.4.2. Caracterização do Universo Amostral dos Uten tes

A produção destes dois serviços, bem como a caracterização em termos de faixas

etárias dos utentes que a eles recorrem, pode ser analisada através da consulta à Tabela

4-7. Será de realçar, no serviço de cardiologia, que cerca de 69 % da produção incide

sobre utentes com idades compreendidas entre os 65 e 84 anos. Os meios

complementares de diagnóstico executados pela cardiologia, com especial ênfase nos

electrocardiogramas e ecocardiograma com estudo doppler, repartem-se de forma mais

ou menos homogénea pelas diferentes faixas etárias. Os valores de exames realizados

a utentes com idades superiores a 64 anos têm uma correspondência com os doentes

seguidos em consulta de ambulatório, enquanto para idades inferiores a esta temos

uma grande parte dos exames decorrentes de eventos militares tais como candidatos ao

exército em provas de selecção e classificação, candidatos às forças especiais, exames

médicos obrigatórios para pessoal dos quadros permanentes decorrentes de processos

de promoção ou ainda para a realização das provas físicas de aptidão.

No que a consultas de endocrinologia diz respeito verificamos mais uma vez a

tendência para que o maior número de consulta esteja nas faixas mais idosas,

permanecendo cerca de 53% da produção em utentes com idades entre os 65 e 84 anos,

passando para os 87% se considerarmos a faixa entre os 45 e 64.

52 Fonte: Gabinete de Estudos Técnicos – UHE (referente a 01/01/2012)


77

Tabela 4-7 – Produção e faixas etárias Ano 2011 – Cardiologia / Endocrinologia e Nutrição

Serviço Acto Médico Faixa Etária

Nº de actos

%

Cardiologia Consulta de Cardiologia 15-24 220 3,20

25-44 208 3,03

45-64 1.163 16,92

65-74 2.287 33,27

75-84 2.459 35,77

>=85 538 7,83

Total 6.875 ---

Cardiologia Meios Complementares de Diagnóstico

15-24 2.005 13,63

25-44 1.867 12,69

45-64 3.049 20,73

65-74 3.518 23,91

75-84 3.455 23,49

>=85 817 5,55

Total 14.711 ---

Endocrinologia E Nutrição

Consulta de Endocrinologia

5-9 2 0,06

10-14 3 0,10

15-24 65 2,09

25-44 253 8,12

45-64 1.049 33,69

65-74 1.025 32,92

75-84 636 20,42

>=85 81 2,60

Total 3.114 ---


Consulta de Enfermagem 15-24 6 0,82

25-44 21 2,85

45-64 228 30,98

65-74 268 36,41

75-84 185 25,14

>=85 28 3,80

Total 736 ---


Consulta da Nutrição 10-14 4 0,20

15-24 121 6,19

25-44 230 11,77

45-64 807 41,30

65-74 560 28,66

75-84 216 11,05

>=85 16 0,82

Total 1.954 ---


78

As consultas de enfermagem, com grande incidência na problemática do pé diabético e

no aconselhamento do utente, seguem de perto a tendência das consultas registando

valores de 67 % nas faixas dos 45 aos 74 e de 92,5% se considerarmos também a faixa

dos 75 aos 84 anos. As consultas de nutrição efectuadas muitas vezes como

complemento ao tratamento da diabetes seguem, como seria de esperar, a tendência

das consultas de endocrinologia concentrando 70% da produção na faixa dos 45 aos 64

anos.

Para além destes dados é importante referir o número de utentes que estão a ser

seguidos nestes dois serviços por forma a termos a noção da dimensão do universo,

sendo esta informação vertida na Tabela 4-8. Os valores constantes na tabela referem-

se ao total de utentes distintos, isto é, apenas contando uma interacção,

independentemente do nº de vezes que os utentes acederam aos serviços no ano de

2011.

Tabela 4-8 – Utentes Ano 2011 – Cardiologia / Endocrinologia e Nutrição

Serviço Tipo Acto Nº Utentes

Cardiologia Consulta 3.046

Mcdt´s 7.441

Endocrinologia e Nutrição Consulta endocrinologia e de Enfermagem

1.789

Consulta de Nutrição 875

Tendo em consideração o que nos foi referido durante as entrevistas efectuadas aos

clínicos das especialidades constantes na Tabela 4-8, e que se consubstancia no facto

de haver uma partilha de utentes entre estes serviços com base na comorbilidade

associada aos doentes diabéticos ou com patologias do foro cardíaco, realizou-se

cruzamento de informação no qual se verificou que estes serviços partilham 545

utentes.

4.4.3. Parâmetros Clínicos a Monitorizar

Para o caso de estudo, e de acordo com o modelo proposto, temos como objectivo a

disponibilização e partilha de informação do utente organizada em três secções:

síntese ou BI clínico do utente, lista de intercorrências do utente com as instituições de


79

saúde e planos de monitorização e alertas adequados à patologia do utente. Para esta

última secção foi elaborada, com o apoio dos profissionais de saúde, uma matriz de

parâmetros com interesse por especialidade e patologia que podemos ver na Tabela 4-

9.

A matriz apresentada, que abrange outras especialidades para além da cardiologia e

endocrinologia que são o foco do caso de estudo, servirá de base à criação dos planos

de monitorização podendo os médicos adicionar, caso a caso, os parâmetros com

interesse para o caso clinico em particular, definindo também as regras associadas à

alarmística. No Anexo D – Valores de Referência por Parâmetro, temos os valores que

por defeito serão colocados aquando da associação dos parâmetros aos planos de

monitorização, sendo estes a base de alarmística, que no entanto pode ser alterada,

também caso a caso, consoante a avaliação médica.


80

Tabela 4-9 – Matriz de parâmetros por especialidade/patologia

Especialidade/Patologia

Cardiologia Endocrinologia Nutrição Nefrologia Urologia

Hemato-

Oncologia Gastroenterologia

Parâmetros

Doença

cardiovascular

Doença das

artérias coronárias

Reabilitação

Cardíaca

Diabetes

/Obesidade

Diabetes

/Obesidade

Doença renal

crónica

Peso x x x x x x x x x

Altura x x x x x x x x x

IMC x x x x x x x x x

SC x

TA(sist) x x x x x x x x x

TA(diast) x x x x x x x x x

FreqCard x x x

Colestrol Total x x x x x x x x x

Colestrol LDL x x x x x x x x x

Colestrol HDL x x x x x x x x x

Triglicéridos x x x x x x x x x

HbA1C x x

BMT - Glicemia Capilar x x

Glicemia pós-prandial

(às 2 horas) x x

Glicemia pré-prandial

(em jejum) x x

Microalbuminúria x x x x x

INR x x

PSA x

Actividade Física x x x

Suspensão tabágica x x x x x


81

4.4.4. Contribuição das fontes para a síntese do PC E do utente.

Sendo o caso de estudo focado na UHE pretende-se na Tabela 4-10 fazer uma

explicação dos ecrãs das aplicações/sistemas verticais utilizados no hospital e perceber

qual o contributo, em termos de partilha/disponibilização de dados, interoperabilidade

que os sistemas existentes terão com o piloto, para acesso aos dados do perfil clinico

do utente.

Tabela 4-10 – Contributo para a síntese do PCE do utente dos sistemas verticais existentes

Aplicação / Módulo / Ecrã Descrição dos Dados

GH – Gestão de doentes – Ecrã Ficha do Doente (Glintths)

• Anexo F - Figura F-1

Este módulo permite aos utilizadores fazer toda a gestão das fichas de utente, nomeadamente criação de novas fichas e edição de fichas já existentes. Não é possível, via ecrã utilizado pelos administrativos, apagar fichas de utentes ou fazer a fusão de fichas no caso de detecção de duplicação. Este módulo contém a base de utentes que é utilizada pelos diferentes módulos do sistema em uso na UHE.

O principal contributo para deste ecrã é para a secção de síntese ou BI clínico do utente, nomeadamente no que diz respeito à subsecção de identificação do utente com os seguintes dados:

Nome, género, data de nascimento, idade, nº de contribuinte, morada, contactos, nº de SNS, nº de beneficiário.


82


EPR – Desktop Médico - Ecrã de Consulta

(Glintths)






Este módulo está direccionado para a actividade diária do médico e possui um conjunto de ecrãs que permitem ao profissional de saúde fazer o registo de informação do foro clínico com especial pertinência para a construção do perfil clinico do utente.

GH – Gestão de doentes – Ecrã Registo de Operações

(Glintths)


O registo dos actos cirúrgicos efectuados, nomeadamente no que ao procedimento, recursos humanos, data da cirurgia diz respeito, pode ser consultado neste ecrã. Deste que foram instalados os ecrãs tácteis, a maior parte da informação é inserida directamente nesses ecrãs dentro do bloco operatório.

Para a subsecção de perfil clinico do utente, temos na aplicação utilizada pelo médicos, em diferentes ecrãs a informação sobre:

• Diagnósticos, Antecedentes pessoais e familiares, diagnósticos ou doenças activas.

• Biometrias (peso, altura, IMC); • Medicação Activa; • Exames (< 3 meses); • Cirurgias.

A informação que estará nesta subsecção poderá também ser adicionada directamente pelo médico na plataforma, nomeadamente no que a diagnósticos e medicação activa diz respeito.


83


GH – Gestão de doentes – Ecrã de Actos Médicos

(Glintths)



O ecrã de actos médicos permite aceder às consultas e exames efectuados pelo utente havendo todo um registo administrativo que contém informação suficiente para popular a lista de intercorrências/episódios no que a consultas e exames diz respeito

GH – Gestão de doentes – Ecrã Registo de Operações

(Glintths)


Temos neste ecrã toda a informação referente ao acto cirúrgico e que é suficiente para colocar na parte de intercorrências/episódios.

GH – Gestão de doentes – Ecrã Registo de Internamento

(Glintths)

• Anexo F - Figura F-9 – Ecrã de

registo de internamento

O ecrã de registo de internamento sumariza o episódio de internamento do utente sendo por isso a fonte para popular os episódios de internamento que serão colocados na lista de intercorrências.

A informação para a secção correspondente à lista de intercorrências /episódios, quer sejam episódios de consulta, mcdt, internamento ou cirúrgicos, é recolhida do sistema vertical existente.

Em termos de consulta teremos: Data da consulta, identificação do médico, especialidade/serviço.

No caso dos Exames: Data do exame, serviço executante, médico /técnico, Id do exame, descrição do exame.

Nas cirurgias: Data da cirurgia, médico /cirurgião, procedimento

No internamento: Data do internamento, data de alta, médico responsável, GDH correspondente, motivo de alta.

A terceira secção da síntese do PCE do utente, que corresponde aos indicadores e

planos de monitorização, não está contemplada na Tabela 4-10 por se tratar de uma

secção cuja informação é carregada directamente na plataforma seguindo uma lógica


84

ou orientação a eventos e não uma orientação a serviços como é o caso das duas

primeiras que são, na sua maioria, populadas por informação proveniente dos sistemas

verticais existentes.


85

5. Conclusões

Apesar de alterações decorrentes da reformulação do SSM contribuírem para agilização de

alguns processos administrativos e funcionais do sistema de saúde, ainda subsistem

constrangimentos e ineficiências, nomeadamente ao nível da partilha de informação, que

podem ser rectificadas. Dos problemas encontrados no SSM procurou-se com este trabalho

endereçar duas questões fundamentais:

• Identificar qual deverá ser a informação de síntese do estado de saúde do utente

acessível a todos os profissionais de saúde;

• Aumentar a interacção com o utente fazendo que este assuma uma maior

responsabilidade pelo seu estado e hábitos de saúde.

A contribuição desta tese para a resolução dos problemas identificados suporta-se num

modelo de colaboração, assente em plataforma web, que endereçará o problema da

compartimentação dos SI e das ilhas de informação existentes e que permitirá ter uma

componente de gestão de indicadores associados a mecanismos de alerta para um apoio

efectivo ao trabalho do profissional de saúde, e na resolução das seguintes questões:

• Identificação unívoca dos utentes do SSM de forma a possibilitar a articulação de

informação dentro e para fora do SSM;

• Definição do conjunto de informação que se constituirá como síntese do estado de


como as quais o SSM partilhe os utentes, através da formalização da estrutura de

dados que caracteriza o perfil clinico de um utente;

• Concepção de um novo serviço de saúde que fomente o aumento da interacção com o

utente fazendo que este assuma uma maior responsabilidade pelo seu estado e hábitos

de saúde, através da formalização da estrutura dados de suporte a planos de

monitorização e sua disponibilização;

• Apoio à análise do desempenho de um utente face a um universo amostral, através da

definição das variáveis que permitem identificar a amostra e dos parâmetros que se

constituem como indicadores.

O modelo de colaboração proposto, em particular a partilha de informação que garante,

enquadra-se no processo de decisão do médico que decorre da agregação / conjugação de

informação proveniente de diferentes fontes, corroborando o conceito de Collaborative


86

Decision Making em meio clínico, ao mesmo tempo que assegura ao utente uma forma de

visualização e contribuição de informação.

Para a determinação da informação relevante a constar em cada utente e para a determinação

da sua organização foram realizadas diversas entrevistas a profissionais de saúde, chegando-

se a um modelo composto por três secções. A primeira secção consiste na síntese ou BI

clinico do utente que será subdividida em duas sub-secções: a sub-secção de identificação do

utente e a subsecção de perfil clinico do utente. A segunda secção contém informação

referente à lista de intercorrências / episódios do utente com o sistema de saúde, e por último

temos a secção de indicadores com os respectivos planos de monitorização que permite o

estabelecimento de indicadores clínicos de acompanhamento do utente e a definição dos

alertas associados aos parâmetros e às respectivas medições efectuadas.

Também das entrevistas realizadas surge a matriz de parâmetros a monitorizar com indicação

dos valores de referência por parâmetro levantado e com a relação entre

especialidades/patologias e parâmetros, verificando-se a existência de conjuntos de

parâmetros com interesse para diferentes especialidades e patologias. Apesar das entrevistas e

reuniões terem sido realizadas com médicos de diferentes especialidades tais como: nefrologia,

cardiologia, hematologia, imagiologia, endocrinologia e nutrição, escolheram-se, para a

componente de monitorização, as especialidades de cardiologia e endocrinologia e nutrição.

Esta escolha teve como racional o facto dos doentes acompanhados nestes serviços terem um

perfil clinico adequado às necessidades da componente de monitorização e alertas, pois são na

sua maioria doentes que padecem de patologias crónicas, com necessidade de controlo dessas

mesmas patologias através da medição dos parâmetros e visitas regulares ao hospital, mas

também o facto da existência de comorbilidade associada aos doentes diabéticos ou com

patologias do foro cardíaco, havendo na unidade hospitalar da estrela um conjunto de 545

utentes comuns às duas especialidades.

Os resultados deste trabalho, que serão validados com projecto-piloto a seis meses, assentam:

• Na definição e estruturação da informação que se constitui com síntese ou BI clínico

do utente, resultante das entrevistas aos profissionais de saúde;

• No estabelecimento de uma matriz de parâmetros, com os respectivos valores de

referência, por especialidade/patologia. Com a criação da matriz foi ainda possível

detectar a existência de grupos de parâmetros com interesse para diferentes

especialidades/patologias;


87

• Na disponibilização de dashbord clínico que é constituído pela informação de síntese

do utente e respectivos planos de monitorização, permitindo assim a partilha de

informação entre os profissionais de saúde;

• No maior controlo existente sobre as medições efectuadas pelos utentes, medições

essas associadas a alertas para o profissional de saúde e para o utente, com indicação

das medidas a tomar;

• Na capacidade de análise do histórico das medições efectuadas, podendo ainda separar

as medições efectuadas em ambiente formal e não formal;

• Na co-responsabilização do utente no seu estado de saúde.

Constitui-se como trabalho futuro a expansão dos planos de monitorização a outras

especialidades /patologias, a inclusão dos centros de saúde e a resolução de outros problemas

levantados ao nível do SSM que não foram objecto de estudo nesta tese, tais como:

• A existência de diferentes SI nas instituições do SSM, bem como diferentes estádios

de maturidade;

• Dificuldades de interoperabilidade entre as soluções informáticas existentes;

• O estado de desmaterialização dos processos é embrionário;

• Inexistência de informação de gestão consolidada.

Ainda como trabalho futuro surge a possibilidade de implementação de um projecto-piloto em

ambiente real, assente em projecto QREN, na unidade hospitalar da estrela, que tem como

objectivo a implementação da metodologia proposta. Este projecto, que não foi possível

implementar durante a realização desta tese, apresenta um planeamento próprio e terá que

ficar em produtivo para testes durante um período mínimo de seis meses, findo o qual será

possível fazer a análise de resultados, nomeadamente no que diz respeito à validação do

impacto e utilidade no processo de monitorização clínica do utente.


88

Referências

[1] European Commission, DG Information Society and Media, ICT for Health Unit.

eHealth Strategies - Final European progress report. 2011.

[2] Christensen, Caryn and JR, James R. Larson. Collaborative Medical Decision Making.

Dezembro 1993. pp. 339-346.

[3] What is e-Health (2): The death of telemedicine? Mea, Vicenzo Della. s.l. : Journal Of

Medical Internet Research, 2001, Vol. 10.2196/jmir.3.2.e22. 11720964.

[4] Healy, Jean-Claude. Implementing e-Health in Developing Countries: Guidance and

Principles. Genebra : International Telecommunication Union, 2008.

[5] Kwankam, S. Yunkap. What e-Health can offer. Genebra : Bulletin of the World

Health Organization, 2004.

[6] Burke, Redmond P. et al. Transforming patient and family access to medical

information: utilisation patterns of a patient-accessible electronic health record.

Cambridge University Press. 2010, Vol. doi:10.1017/S1047951110000363.

[7] Direcção Geral de Pessoal e Recrutamento Militar. Reforma do Sistema de Saúde

Militar. [Online] 2011. [Cited: Outubro 10, 2011.]

http://www.mdn.gov.pt/mdn/pt/mdn/Servi%C3%A7os+Centrais+de+Suporte/dgprm/s

aude/DGPRM_Reforma_SistSaudeMilitar.htm.

[8] Cunha, Jaime. Modelação Organizacional Do Hospital Militar Principal. Lisboa : IST-

UTL, 2003.

[9] Rocha, Álvaro. Informática de Saúde - Reflexão sobre a informática de Saúde em

Portugal. Porto : Universidade Fernando Pessoa, 2007.

[10] Oh H, Rizo C, Enkin M, Jadad A. What Is eHealth (3): A Systematic Review of

Published Definitions. Jornal of Medical Internet Research. 2005, Vol. 7.

[11] Araújo, Sara Campos. Tese de Mestrado - Segurança na Circulação de Informação

Clínica. s.l. : Faculdade de Engenharia da Universidade do Porto, Março 2007.

[12] Ferrinho, Paulo et al. Plano Nacional de Saúde 2012 - 2016. Direcção-Geral de Saúde.

[Online] 26 de Junho de 2012. http://pns.dgs.pt/pns-2012-2016/

[13] ACSS. Registo de Saúde Electrónico - R1: Documento de Estado da Arte . 30 de

Setembro de 2009.

[14] Santos, Estevão Soares e Martins, Henrique Gil. Usability and Impact of Electronic

Health Records for Primary Care Units in Portugal. s.l. : Information Systems and

Technologies (CISTI), 2011 6th Iberian Conference, Junho 2011.


89

[15] Dannenfeldt, Diane. "How Paperless Offices Work". [Online] Dezembro 01, 2007.

[Cited: Dezembro 03, 2011.]

http://communication.howstuffworks.com/convergence/how-paperless-offices-

work.htm.

[16] King, Rachael. Paperless Health-Care Facilities. Bloomberg Businessweek. Abril 7,

2009.

http://images.businessweek.com/ss/09/04/0407_ceo_guide_emedical_records/1.htm -

Consultado em Dezembro 2011.

[17] Sidorov, Jaan. It Ain’t Necessarily So: The Electronic Health Record And The

Unlikely Prospect Of Reducing Health Care Costs. 2006, Vols. 25, n. 4, pp. 1079-

1085. http://content.healthaffairs.org/content/25/4/1079.full - Consultado em

Dezembro 2011.

[18] Quintero, J.M et al. Medical decision-making and collaborative reasoning.

Bioinformatics and Bioengineering Conference. 2001, pp. pp.161-165.

[19] European Commision, DG Information Society and Media. Benchmarking ICT use

among General Practitioners in Europe. Abril 2008.

[20] Benson, Tim. Principles of Health Interoperability HL7 and SNOMED - Health

Informatics. s.l. : Springer, 2009. 9781848828025.

[21] Health Informatics. Electronic Health Record - Definition, scope and context” ISO/TR

20514 – Final Report.

[22] Introduction to HL7 Standards. Health Level Seven International. [Online] [Cited:

Dezembro 14, 2011.] http://www.hl7.org/implement/standards/index.cfm?ref=nav.

[23] Lopez, Diego M., Blobel, Bernd G.M.E.. A development framework for semantically

interoperable health information systems. International Journal of Medical Informatics.

Fevereiro 2009, Vol. 78.

[24] Erl, Thomas. Service-Oriented Architecture: Concepts, Technology, and Design. s.l. :

Prentice Hall, 2005. ISBN:0131858580.

[25] SOA (Service-Oriented Architecture) | Gartner IT Glossary. Gartner. [Online] [Cited:

Dezembro 07, 2011.] http://www.gartner.com/technology/it-glossary/soa-service-

oriented-architecture.jsp.

[26] ACSS. Registo de Saúde Electrónico - R1: Documento de Estado da Arte . 30 de

Setembro de 2009.


90

[27] Levina, O.; Stantchev, V.; "Realizing Event-Driven SOA," ICIW '09. Fourth

International Conference on Internet and Web Applications and Services, 2009., vol.,

no., pp.37-42, 24-28 May 2009, doi: 10.1109/ICIW.2009.14.

[28] Mell, Peter e Grance, Timothy. The NIST Definition of Cloud Computing. Special

Publication 800-145, 2011, Recommendations of the National Institute of Standards

and Technology.

[29] Boniface, M.; et al, "Platform-as-a-Service Architecture for Real-Time Quality of

Service Management in Clouds,", 2010 Fifth International Conference on Internet and

Web Applications and Services (ICIW), vol., no., pp.155-160, 9-15 May 2010, doi:

10.1109/ICIW.2010.91.

[30] Aalst, Wil van der and Hee, Kees van. Workflow Management - Models, Methods,

and Systems. s.l. : MIT Press, 2002. ISBN: 0262011891.

[31] Hollingsworth, David. The Workflow Reference Model. s.l. : The Workflow

Management Coalition, 1995. TC00-1003.

[32] Berson, Alex and Dubov, Larry. Master Data Management and Customer Data

Integration for a Global Enterprise - Overview of Business Rules Engines. s.l. :

McGraw-Hill, 2007. ISBN-10: 0072263490.

[33] Huser et al. Implementation of workflow engine technology to deliver basic clinical

decision support functionality. BMC - Medical Research Methodology. 2011.

[34] Quaglini et al. Guideline-based patient careflow systems. Artificial Intelligence in

Medicine. NCBI - National Center for Biotechnology Information. Abril 2001.

[35] Peleg, Mor. Chapter 13: Guidelines and Workflow Models," in Clinical Decision

Support: The Road Ahead. s.l. : Greenes RA, 2007. ISBN: 9780123693778.

[36] Yin, Robert K. Case study research: design and methods. 3. s.l. : Sage Publications,

2003. ISBN: 076192552X.


91

Anexos

Anexo A – Situação Actual dos Estabelecimentos de S aúde

do SSM.

Ao nível de Sistemas de Informação, existem várias realidades nos hospitais, centros de saúde

e postos de socorros. Temos hospitais e centros de saúde com diferentes SI, bem como,

centros de saúde e postos de socorros onde não existe qualquer suporte informático à

actividade clínica. Neste ponto é feita a distinção entre hospitais, centros de saúde e postos de

socorros. Ao nível dos hospital é feita uma comparação mais detalhada em termos de módulos

aplicacionais/funcionalidades existentes, enquanto que ao nível dos centros de saúde e postos

de socorros é dada a indicação da existência ou não de SI de suporte à actividade

administrativa/Clínica.

Tabela A-1 – Situação dos SI dos hospitais

Instituição de Saúde Sistema de Informação

UHL e UHE Estes dois hospitais têm o mesmo fornecedor aplicacional, a GLINTTHS. As duas instituições encontram-se porém em diferentes estados relativamente aos módulos que possuem e às versões dos módulos que são comuns. A UHL possui uma maior abrangência, nomeadamente no que diz respeito ao processo clínico electrónico e à parte de farmácia-logística (Circuito do medicamento).

Os dois hospitais encontram-se em fase de actualização dos seus SI, nomeadamente na componente da prescrição electrónica e respectivo PCE.

A UHE descontinuou a componente MEDICINEONE, substituindo as suas funcionalidades por componentes GLINTTHS.

HMR1 Este hospital tem como fornecedor aplicacional a SHI (SIGEHP), encontrando, ao nível dos módulos disponibilizados, num estado muito semelhante à UHE.

A aplicação da SHI encontra-se em fase de actualização na área do PCE, tendo como parceiro a empresa - Manuel da Conceição Gonçalves Mesquita – para a área da prescrição electrónica.

UHSC Este hospital possui um SI desenvolvido internamente, faltando competências ao nível de desenvolvimento de interfaces para ligação às áreas de imagiologia, laboratório de análises e prescrição electrónica. Possui a componente de prescrição electrónica pela ALERT.


92

Em detalhe nas áreas de actuação dos SI temos:

Módulo / Aplicação UHE HMR1 UHL UHSC Observações

Gestão de Doentes e

Ambulatório

No HMR1 apenas alguns serviços utilizam agendamento electrónico

Hospital de Dia

Internamento A UHE e o HMR1 não possuem capacidade de prescrição em regime de unidose para a farmácia hospitalar.

O HMR1 tem em fase de implementação o PCE que possibilitará esta prescrição.

Urgência O serviço de urgência comum na estrela bem como o serviço de urgência do HMR1 não possuem uma aplicação dedicada urgência com a capacidade de implementação de protocolos de triagem e encaminhamento de doentes.

Patologia Clínica O HMR1 e a UHSC, apesar de possuírem soluções de laboratório, estas não integram com o HIS. O HMR1 tem em fase de implementação o PCE que possibilitará esta integração.

Imunohematologia O HMR1, a UHL e a UHSC não possuem valências ao nível do sangue.

Anatomia

Patológica

O HMR1 e a UHSC não possuem o serviço de Anatomia Patológica

Imagiologia A UHE, o HMR1 e a UHSC possuem digitalização da imagem, mas não integram com o HIS.

O HMR1 tem em fase de implementação o PCE que possibilitará esta integração.

Bloco Operatório

Enfermagem

Processo Clínico

Electrónico


93

Módulo / Aplicação UHE HMR1 UHL UHSC Observações

Gestão do

Medicamento

No HMR1, apesar de haver aplicação que gere a farmácia hospitalar, ainda não está definido todo o circuito do medicamento, nomeadamente no que diz respeito à prescrição em regime de unidose.

Nenhum dos hospitais tem a logística do medicamento integrada com o Sistema Integrado de Gestão (SIG) – ERP da defesa.

Facturação Nenhum dos hospitais tem a facturação integrada com o Sistema Integrado de Gestão (SIG) - ERP da defesa.

Portal Corporativo A UHSC tem já algum trabalho nesta área. Portal Sharepoint

Indicadores de

Gestão O HMR1 apesar d produzir

informação estatística não possui um Data Warehouse separado do ambiente operacional/produção.

Nota: só se assinala nos módulos que têm 100% das funcionalidades activas.

Tabela A-2 – Situação dos SI dos Centros de Saúde e Postos de Socorros

Local SI Fornecedor /Solução Observações

HMR2 MedicineOne Infra-estrutura própria.

Tem capacidade para ter a prescrição electrónica através do respectivo fornecedor.

Centro Saúde Santa Margarida

MedicineOne Máquina virtual em datacenter do exército.

Tem capacidade para ter a prescrição electrónica através do respectivo fornecedor.

Centro Saúde de Évora

Posto Socorros / Exercito

Posto Socorros / Força Aérea

Glintths Ligação à UHL através de aplicação web

Posto Socorros / Marinha


94

Anexo B – Relação de Especialidades da UHE

Tabela B-1 – Especialidades Médicas e Cirúrgicas (UHE)

Especialidades Médicas e Cirúrgicas Anatomia Patológica Anestesiologia Cardiologia Cirurgia Geral Cirurgia Pediátrica Cirurgia Plástica Cirurgia Torácica Cirurgia Vascular Clínica Geral Endocrinologia e Nutrição Estomatologia Fisiatria Hematologia Imuno-Hemoterapia Infecciologia Medicina Dentária Medicina Interna Medicina Trabalho Nefrologia Neurocirurgia Neurologia Oncologia Ortopedia Pediatria Psicologia Psiquiatria Reumatologia Senologia Urologia


95

Anexo C – Aplicações / Módulos de Saúde em Produção na

UHE

1. Identificação da designação comercial das aplicações em exploração;

Gestão Hospitalar 2. Identificação do fabricante e entidade a quem foi adquirida a aplicação, caso esta seja

diferente da entidade fabricante;

CPCHS, agora GLINTTHS

3. Identificação dos módulos em exploração por aplicação;

Gestão de Doentes

Consulta externa e ambulatório

Gestão do internamento

4. Capacidade de expansão a outros HM/CS, das aplicações em exploração;

Sim

5. Possibilidade de integração com outras aplicações (através de interfaces ou outro processo de interligação);

Sim, HL7

6. Custos de aquisição da aplicação (software);

Dado omitido

7. Custos de eventual customização da aplicação;

A customização da aplicação enquadra-se dentro do projecto inicial. Necessidades futuras são

cobertas por bolsa de horas contratada ou contrato de manutenção.

8. Custos do Hardware associados à aplicação (servidores): a. Referir se o servidor é de utilização exclusiva da aplicação ou partilhado;

Partilhado

b. Identificação das aplicações alojadas no servidor.

Restantes aplicações no âmbito de saúde: Sibas, Sislab, Factus, EResults, EPR,

Bloco Operatório, SIG (Sistema de indicadores de Gestão)

9. Custos de desenvolvimentos;


96

Os desenvolvimentos necessários são cobertos por bolsa de horas contratada ou com

orçamento, visto caso a caso.

10. Custos de manutenção externa;

Dado omitido

11. Custos de manutenção interna (custos dos RH* afectos, referindo a % de tempo gasto com a aplicação);

Dado Omitido

12. Custos das licenças caso existam;

O custo anual é reflectido no contrato de manutenção (ponto 10).

13. Custos de formação para a gestão, manutenção e desenvolvimentos;

Coberto pela bolsa de horas, ou caso a caso de acordo com as necessidades.

14. Outros custos não incluídos nos anteriores (discriminados).

Bolsa de horas transversal a todas as aplicações GLINTTHS que corresponde a 32

dias/homem


97


Factus 2. Identificação do fabricante e entidade a quem foi adquirida a aplicação, caso esta seja




Facturação - Factus


Sim


Sim, HL7 / Ficheiros


Dado omitido





Partilhado


Restantes aplicações no âmbito de saúde: Sibas, Sislab, Gestão Hospitalar,

EResults, EPR, Bloco Operatório, SIG (Sistema de indicadores de Gestão)





98


Dado omitido


Dado omitido


O custo anual é reflectido no contracto de manutenção (ponto 10).




Bolsa de horas transversal a todas as aplicações GLINTTHS, que corresponde a 32

dias/homem


99


EPR e EResults 2. Identificação do fabricante e entidade a quem foi adquirida a aplicação, caso esta seja




Processo Clínico Electrónico, EResults (Resultados exames on-line)


Sim


Sim, HL7


Dado omitido.





Partilhado


Restantes aplicações no âmbito de saúde: Sibas, Sislab, Gestão Hospitalar, Factus,

Bloco Operatório, SIG (Sistema de indicadores de Gestão)





100


Dado omitido


Dado omitido


O custo anual é reflectido no contrato de manutenção (ponto 10).





dias/homem


101


Bloco Operatório 2. Identificação do fabricante e entidade a quem foi adquirida a aplicação, caso esta seja




Bloco Operatório


Sim


Sim, HL7


Dado omitido





Partilhado


Restantes aplicações no âmbito de saúde: Sibas, Sislab, Gestão Hospitalar, Factus,

EPR, Eresults, SIG (Sistema de indicadores de Gestão)





102


Dado omitido


Dado omitido







dias/homem


103


Sislab e Sibas 2. Identificação do fabricante e entidade a quem foi adquirida a aplicação, caso esta seja




Sislab, Anasibas


Sim


Sim, HL7


Dado omitido





Partilhado


Restantes aplicações no âmbito de saúde: Bloco Operatório, Gestão Hospitalar,

Factus, EPR, Eresults, SIG (Sistema de indicadores de Gestão)





104


Dado omitido


Dado omitido







dias/homem


105


SIG (Sistema Indicadores de Gestão) 2. Identificação do fabricante e entidade a quem foi adquirida a aplicação, caso esta seja




Indicadores para: Consultas, Internamentos, Urgências, Bloco Operatório, Meios

Complementares de Diagnóstico, Facturação.


Sim


Sim, Base de dados


Dado omitido





Partilhado


Restantes aplicações no âmbito de saúde: Bloco Operatório, Gestão Hospitalar,

Factus, EPR, Eresults, Sislab, Sibas.





106


Dado omitido


Dado omitido







dias/homem


107

Anexo D – Valores de Referência por Parâmetro

Tabela D-1 – Parâmetros e valores de referência

Parâmetros Valor Máximo Valor mínimo Unidade Fonte

Peso S/R S/R Kg S/R - Sem referência

Altura S/R S/R cm S/R - Sem referência

IMC 24.99 Kg/m2 18,50 Kg/m2 Kg/m2

Organização Mundial de Saúde -

http://apps.who.int/bmi/index.jsp?introPage=intro_3.html

SC 1.73 m2 1.73 m2 m2

Valor médio. Este valor varia com idade e género (Adultos H -+ 1.9, M - 1.6) - Human

body surface area database and estimation formula

TA(sist) 129 mmHg 120 mmHg

mmHg (Milimetro de

mercurio)

Sociedade portuguesa de cardiologia / European Society of Cardiology. Nota: Os valores

"normais" variam de acordo com a idade

TA(diast) 84 mmHg 80 mmHg

mmHg (Milimetro de

mercurio) Sociedade portuguesa de cardiologia / European Society of Cardiology.

FreqCard 100 bpm 60 bpm

bpm (Batimentos por

minuto)

Sociedade portuguesa de cardiologia / American Heart Association (AHA): Pode ser

influenciado por: exercício, febre-calor; dor aguda,ansiedade, etc . Nota: Os valores

"normais" variam de acordo com a idade

Colestrol Total < 200 mg/dL S/R

mg/dL (Miligramas por

decilitro)

Sociedade portuguesa de cardiologia / American Heart Association (AHA):

http://www.heart.org/HEARTORG/Conditions/Cholesterol/AboutCholesterol/What-

Your-Cholesterol-Levels-Mean_UCM_305562_Article.jsp

Colestrol LDL < 129 mg/dL S/R


decilitro)




Colestrol HDL S/R

> 40 mg/dl (H), >

50 mg/dL (M)


decilitro)




Triglicéridos < 150 mg/dL S/R


decilitro)




HbA1C < 6,5 S/R %

International Diabetes Federation, OMS, direcção geral de saúde. Nota: Os valores de

referência Laboratoriais estão tipicamente entre 4% e 6 %

BMT - Glicemia Capilar

Idem Prós e pré

prandial S/R

minimoles por litro ou

miligramas por decilitro Glicemia capilar, coleta de sangue de capilares sanguíneo geralmente do dedo

Glicemia pós-prandial (às

2 horas)

< 7.8 mmol/l (<140

mg/dl) S/R


miligramas por decilitro

A IDF e outras organizações definem Tolerância normal à glicose como uma glicemia <

7.8 mmol/l (<140 mg/dl) duas horas após a ingestão de uma sobrecarga de 75 g de

glucose


108

Parâmetros Valor Máximo Valor mínimo Unidade Fonte Glicemia pré-prandial

(em jejum)

< 5.5 mmol/l (<100

mg/dl) S/R


miligramas por decilitro IDF

Microalbuminúria

< 30mg / g

(30mg/24h) S/R

Rácio de mg de albumina/g

de creatinina ou mg de

albumina/urina 24h American Diabetes Asociation (ADA)

INR 1.26 1.0 Adimensional

Associação Portuguesa de doentes anticoagulados -

http://www.apda.com.pt/anticoagulacao.php. Nota: Um INR = 1 indica um sangue com

coagulação normal. Quando maior for o valor, mais rápida é a coagulação do sangue.

Os valores a monitorizar depedem da patologia associada.

PSA

Entre 2,5 ng/ml (40 a

50 anos) a 6,5 ng/ml

(> 70 anos) S/R

ng/mL (nanogramas por

mililitro)

Associação portuguesa de Urologia ( http://www.apurologia.pt) e NIH - Nacional

Institute of Health e http://www.nlm.nih.gov/medlineplus/ency/article/003346.htm e

ainda http://emedicine.medscape.com/article/457394-overview#aw2aab6c11 - Os

valores variam de acordo com a idade o utente

Actividade Fisica S/R S/R S/R - Sem referência

Suspensão tabágica S/R S/R S/R - Sem referência


109

Anexo E – Modelo de Domínio – Classes, seus Atribut os e Métodos

Figura E-1 - Modelo de Domínio


110

Tabela E-1 – Utente

Utente - N_SNS: string (PK) - Nome: string - Genero: enum G {Masculino, Feminino} - Data_Nascimento: Date - Idade: int - N_Beneficiario: string - N_Contribuinte: string - Peso: decimal - Altura: decimal - IMC: decimal - Foto: Objecto - Password: string - Etnia: string - Grupo_Sanguineo: enum GS {AB+, AB-, A+, A-,B+,B-,O+,O-} + string []: RecolheUtente () - void: Processa DadosUtente (Utente utente) + Utente: CriaUtente (string n_sns, string nome, G genero, date data_nascimento) + Utente: EditaUtente (Utente utente) + string []: ToDoListUtente (string n_sns, date inicio, date fim) + Contacto []: ListaContactosUtente (string n_sns) + EpExame []: ListaEpExame (string n_sns, date data) - int: CalculaIdade (date data_nascimento) - decimal: CalculaIMC (decimal peso, decimal altura)

Tabela E-2 – Valida Utente

Valida Utente - Valida_UtenteID: int (PK) - UtenteID: string (FK) - Atributo: string - Valor: string - Origem: int - Utilizador_Valida: string - Data_Valida: date - Estado: bool (true-> validado, false-> por validar) - Atribuido: bool (true->atribuído, false->não atribuído) - Data_Atribuicao: date + void: ValidaAtributos (string [] atributos) - string []: ListaInconformidades (string utenteID)


111

Tabela E-3 – Medicação Activa

Medicação Activa - Medicacao_ActivaID: int (PK) - UtenteID: string (FK) - Designacao: string - Substancia_Activa: string - Generico: bool (true-> genérico, false-> não genérico) - Origem: int - Tipo_Medicacao: enum TM {activa, cronica} - Data_Prescricao: date + string []: RecolheMedicacaoActiva (string utenteID) - void: ProcessaMedicacao (Medicacao_Activa medicacao) + void: AlteraTipoMedicacao (Medicacao_Activa medicacao) + void: AdicionaMedicacao (string utenteID, string designacao, string substancia_activa, bool generico, TM tipo_medicacao, date data_prescricao) + Medicacao_Activa []: ListaMedicacaoPorUtente (string n_sns, date data)

Tabela E-4 – Antecedentes

Antecedentes - AntecedentesID: int (PK) - UtenteID: string (FK) - Tipo_Antecedente: enum TA {Familiar, Pessoal} - Patologia: string + string []: RecolheAntecedentes (string utenteID) - void : ProcessaAntecedentes (Antecedentes antecedente) + void: AdicionaAntecedentes (string utenteID, TA t_antecedente, string patologia) + Antecedentes []: ListaAntecedentesPorUtente (string utenteID) + EpCirurgia []: ListaEpCirurgiaRelevantes ( string utenteID, date data, string [] procedimentos)

Tabela E-5 – Patologias

Patologias - PatologiaID: string (PK) - UtenteID : string (FK) - Descricao: string - Data_Atribuicao: date - Medico: string - Origem: int + string []: RecolhePatologias (string utenteID) - void : ProcessaPatologias (Patologias patologia) + void: AdicionaPatologias (string utenteID, string patologiaID, string descricao, date data, string medico, int origem) + Patologias []: ListaPatologiasPorUtente (string utenteID)


112

Tabela E-6 – Episodio

Episodio - EpisodioID: int (PK) - UtenteID: string (FK) - Origem: int - Data_realizacao: date - Medico: string + string []: RecolheEpisodio (string utenteID) - void : ProcessaEpisodio (Episodio episodio)

Tabela E-7 – Episodio Cirurgia

EpCirurgia - EpCirurgiaID: int (PK) - EpisodioID: int (FK) - Especialidade: string - Cod_Diagnostico: int - Descricao_Diagnostico: string - Cod_Procedimento: int - Descricao_Procedimento: string + void : ProcessaEpCirurgia (EpCirurgia episodio) + EpCirugia []: ListaEpCirurgiaPorUtente (string utenteID)

Tabela E-8 – Episodio Consulta

EpConsulta - EpConsultaID: int (PK) - EpisodioID: int (FK) - Especialidade: string - Resumo_Clinico: string + void : ProcessaEpConsulta (EpConsulta episodio) + EpConsulta []: ListaEpConsultaPorUtente (string utenteID)


113

Tabela E-9 – Episodio Internamento

EpInternamento - EpInternamentoID: int (PK) - EpisodioID: int (FK) - Data_Baixa: date - Data_Alta: date - Motivo_Alta: string - GDH: int - Cod_Diagnostico: int - Descricao_Diagnostico: string + void : ProcessaEpInternamento (EpInternamento episodio) + EpInternamento []: ListaEpInternamentoPorUtente (string utenteID)

Tabela E-10 – Episodio Exame

EpExame - EpExameID: int (PK) - EpisodioID: int (FK) - Especialidade: string - Cod_Exame: int - Descricao_Exame: string - Resultado: string + void : ProcessaEpExame (EpExame episodio) + EpExame []: ListaEpExamePorUtente (string utenteID)

Tabela E-11 – Contacto

Contacto - ContactoID: string (PK) - Tipo_Contacto: enum TC {Tm, email} (PK) - Valor: string + string: ConsultaContacto (string contactoID, TC tipo_contacto) + string []: ConsultaContactosUtilizador ( string contactoID) - void: InsereContacto (string contactoID, TC tipo_contacto, string valor) - void: EditaContacto (string contactoID, TC tipo_contacto) - void: ApagaContacto (string contactoID, TC tipo_contacto)


114

Tabela E-12 – Medico

Medico - N_Ordem: string (PK) - Nome: string - Especialidade: string - Password: string + string []: RecolheMedico () - void: ProcessaMedico (Medico medico) - void: EditaMedico (Medico medico)

Tabela E-13 – Instituição de Saúde

Instituicao - InstituicaoID: int (PK) - Designacao: string - Tipo: string ( e.g. Hosp Central, Hosp Distrital, Centro Saúde .. ) - Distrito: string - Concelho: string - Localidade: string - void: CriaInstituicao ( string desigancao, string tipo, string distrito, string concelho, string localidade) - void: EditaInstituicao (Instituicao instituicao) + Instituicao []: ListaInstituicoes ()

Tabela E-14 – Plano Monitorização

Plano Monitorização - PlanoID: int (PK) - UtenteID: string (FK) - MedicoID: string (FK) - Data_Criacao: date - Data Inicio: date - Data Fim: date - Duracao: int - Contexto_Criacao: string ( e.g. consulta especialidade, clinica geral, etc) - Estado: bool (true-> activo, false-> inactivo) + void: CriaPlano (string utente, string medico, date data_criacao, date data_inicio, date data_fim, string contexto_criacao, bool estado) + void: EditaPlano (PlanoMonitorizacao plano) + PlanoMonitorizacao []: ListaPlanosPorUtente (string utenteID) + PlanoMonitorizacao []: ListaPlanosPorMedico (string medicoID) + Parametro []: ListaParametrosPorPlano (int planoID) + Sensor []: ListaSensoresPorPlano (int planoID) + Sensor []: ListaSensoresPorUtente (string utenteID) + FrequenciaRecolha []: ListaFreqRecolhaPorPlano (int planoID) + Alerta []: ListaAlertasPorUtente (int planoID, string utenteID)


115

Tabela E-15 – Parâmetro

Parâmetro - ParametroID: int (PK) - Tipo: enum T {Clinico, Antropométrico) - Sigla: string - Descricao: string - Valor_Max: string - Valor_Min: string - Formula_Calculo: string - Unidade_Medida: string - void: CriaParametro (T tipo, string sigla, string descricao, string max, string min, string formula, string unidade_medida) - void: EditaParametro (Parametro parametro) - void: apagaParametro (int parametroID) + Parametro: ConsultaParametro (int parametroID) + Parametro []: ListaParametros ()

Tabela E-16 – Parâmetro Plano

Parâmetro Plano - Parametro_PlanoID: int (PK) - ParametroID: int (FK) - PlanoMonitorizacaoID: int (FK) + void: InsereParametroPlano (int parametroID, int plano_monitorizacaoID) + int []: ListaParametrosPorPlano ( int plano_monitorizacaoID) + FrequenciaRecolha: ConsultaFrequnciaRecolhaPorParametro ( int parametro_planoID) + Alerta []: ListaAlertaPorParametroPlano (int parametro_planoID, int plano_monitorizacaoID)

Tabela E-17 – Sensor

Sensor - SensorID: int (PK) - Marca: string - Modelo: string - Fabricante: string - Estado: bool (true->op, false->inop) - instituicao: int - void: CriaSensor ( string marca, string modelo, string fabricante, bool estado, int instituicao) - void: EditaSensor (Sensor sensor) - void: ApagaSensor (int sensorID) + Sensor: ConsultaSensor (int sensorID) + Sensor []: ListaSensorPorInstituicao (int instituicao) + Sensor []: ListaSensorPorEstado (int instituicao, bool estado)


116

Tabela E-18 – Sensor Parametro

Sensor Parametro - SensorID: int (PK) - Parametro_PlanoID: int (PK) - Tipo_Fornecimento: string (e.g. Empréstimo, aquisição, etc) - Origem: string (e.g. Instituição de Saúde, farmácia, etc) + void: InsereSensorParametro (int sensorID, int parametro_planoID, string tipo_fornecimento, string origem) + int: SensorPorParametro (int parâmetro_planoID) + SensorParametro []: ListaSensorPorTipoFornecimento ( string t_fornecimento) + SensorParametro []: ListaSensorPorOrigem ( string origem)

Tabela E-19 – Medição

Medição - MedicaoID: int (PK) - Parametro_PlanoID: int (FK) - Tipo_Ambiente: enum TA {Formal, Não Formal} - Valor: decimal - timestamp: datetime + void: RegistaMedicao ( int parametro_planoID, TA t_ambiente, decimal valor, datetime timestamp) + decimal []: ListaMedicaoPorParametro (int parametro_plano)

Tabela E-20 – Frequência de Recolha

Frequência de Recolha - FrequenciaID: int (PK) - Parametro_PlanoID: int (FK) - Periodicidade: enum P {diário, semanal, quinzenal, mensal} - Dias_Semana: enum DS { Segunda,…., Domingo} - Dias_Mes: enum DM {1, 2, …..31} - Hora: enum H {1,2,….24, PAL, ALM, LANCH, JANT} + void: CriaFrequencia ( int parametro_planoID, P periodicidade, DS d_semana, DM d_mes, H hora) - void: EditaFrequencia ( FrequenciaRecolha frequencia) + void: ApagaFrequencia ( int frequenciaID) + FrequenciaRecolha: ConsultaFrequencia (int frequenciaID)


117

Tabela E-21 – Regra

Regra - RegraID: int (PK) - Parametro_PlanoID: int (FK) - Descricao: string - Condicao: string + void: CriaRegra (int parametro_planoID, string descricao, string condicao) - void: EditaRegra (Regra regra) + void ApagaRegra (int regraID) + Regra: ConsultaRegra ( int regraID) + void: ExecutaRegra (int regraID)

Tabela E-22 – Alerta

Alerta - AlertaID: int (PK) - RegraID: int (FK) - Remetente: string - Contacto_Remetente: string - Parametro: string - Valor: string - Severidade: enum S (Baixa, Média, Alta) - timestamp: datetime + void: CriaAlerta ( int regraID, string remetente, string contacto_remetente, string parametro, string valor, S severidade, datetime timestamp) + void: EnviaAlerta ( int alertaID)

Tabela E-23 – Contacto Regra

Contacto Regra - RegraID: int (FK) - ContactoID: string (FK) + void: InsereContactoRegra ( int regraID, string contactoID)


118

Anexo F – Sistemas Fonte - Ecrãs

Figura F-1 – GH-Gestão Doentes – Ficha do doente

Figura F-2 – EPR-Desktop Médico – História Clinica


119

Figura F-3 – EPR-Desktop Médico – História Clinica/Biometria

Figura F-4 – EPR-Desktop Médico – Terapêutica


120

Figura F-5 – EPR-Desktop Médico – Exames

Figura F-6 – GH – Gestão Doentes – Registo de operações


121

Figura F-7 – GH – Gestão Doentes – Actos Médicos (Consulta)


122

Figura F-8 – GH – Gestão Doentes – Actos Médicos (Exame)

Figura F-9 – GH – Gestão Doentes – Registo de internamento

o processo clínico electrónico (pce) na instituição militar · a existência, a nível europeu,...

Documents