Controlo de Acesso à Informação de Saúde - Da legislação à prática: Um caso de estudo do Break-The-Glass

Resumo

As recomendações e os regulamentos que estão disponíveis nos cuidados de saúde para proteger a informação médica sensível, têm como intuito garantir que este tipo de informação só seja acedido e utilizado num contexto especíco, e de forma justicada e devidamente autorizada. Estas recomendações tendem no entanto, a ser bastante genéricas e, por isso, é bastante difícil traduzi-las para a prática clínica.

No inicio do ano de 2005, foi publicada em Portugal a Lei no _{12/2005, que vem}

regulamentar o acesso à Informação genética pessoal e informação de saúde. Tendo o sistema de informação ICU (Informação Clínica do Utente), em uso no Hospital de S. João (HSJ) desde 2004, relatórios do serviço de Imuno-Hemoterapia que contêm informação genética, foi necessário implementar políticas mais exíveis de controlo de acesso, para fazer cumprir a legislação em causa, neste mesmo sistema.

Um modelo de controlo de acesso, bastante utilizado na área médica, é o Role Based Access Control (RBAC), cujo princípio é associar os privilégios ou as permissões, juntamente com os recursos, aos papéis (por ex. categorias prossionais) que os prossionais ocupam na instituição onde trabalham. Este modelo permite uma maior facilidade de gestão e independência relativamente aos utilizadores do sistema. No entanto, o modelo RBAC não consegue expressar regras de controlo de acesso em situações de emergência, como as que contêm as operação Break-The-Glass (BTG). O conceito BTG consiste em deixar que um utilizador aceda a um recurso do sistema em caso de emergência, quando este utilizador não está autorizado para tal ou quando os serviços de autenticação não estão a funcionar correctamente, de forma controlada e responsável.

O processo de traduzir a legislação para a prática clínica, onde também se deni-ram os procedimentos técnicos necessários, passou por várias fases. Este processo envolveu um grupo de trabalho multidisciplinar, que durante todo o processo reali-zou várias reuniões e troca de emails, e de onde foi produzida uma proposta nal de implementação.

Para implementar o modelo de controlo de acesso BTG-RBAC, foi necessário efectuar um conjunto de alterações do lado da plataforma que gere o controlo de acessos, a plataforma Web.Care, e do próprio sistema ICU. Esta implementação está actual-mente a ser usada pelos prossionais de saúde com acesso ao ICU, desde Maio de 2009.

Os resultados mostram, que no primeiro ano de utilização, o modelo de controlo de acesso BTG-RBAC ltra acessos de utilizadores não autorizados que tentem aceder a relatórios com informação genética. Porém, em termos comparativos por grupos de utilizadores, o número médio de relatórios acedidos por utilizador pertencente ao grupo dos médicos diminuiu de 8,2 para 5,5 (relatórios por utilizador), enquanto que, no caso do grupo de utilizadores ao qual pertence o pessoal em formação pré carreira, aumentou de 3,9 para 4,5 (relatórios por utilizador).

No entanto, é necessário implementar uma plataforma de auditoria para melhor avaliar os motivos evocados pelos utilizadores no que diz respeito aos acessos efectuados por BTG. Mesmo que sejam implementados os procedimentos técnicos necessários para garantir o cumprimento da legislação em vigor, é necessária uma infra-estrutura hu-mana que verique os resultados desses procedimentos e faça as validações necessárias das justicações introduzidas pelos utilizadores do ICU, relativas aos acessos dos re-spectivos relatórios.

Abstract

The recommendations and regulations that are available in health care to protect sensitive medical information have as the main goal to ensure that this type of infor-mation is only accessed and used in a specic context and in a justied and properly authorized manner. These recommendations tend however, to be fairly generic, so it is quite dicult to translate them into clinical practice.

At the beginning of 2005, the Law No. 12/2005, which regulates the access to personal genetic information and health information, was published in Portugal. The ICU (Patient Clinical Information System) collects and stores patient reports that contain genetic information, from the Immuno-Hematology Service since 2004, at Hospital de São João (HSJ), in Portugal. In order to enforce the legislation mentioned previously, it was necessary to implement more exible access control policies that could express the ICU access control needs.

An access control model that is widely used in the medical eld is the Role Based Ac-cess Control (RBAC) model, whose principle is to associate privileges and permissions to the roles (for ex. professional categories) that healthcare professionals have within the institution where they work. This model allows easier administration and inde-pendence in relation to the users of the system. However, the RBAC model cannot express access control rules for emergency or unanticipated situations, such as those containing the Break-The-Glass (BTG) operation. The BTG concept allows a user to access a resource in emergency situations, in a controlled and responsible manner, when the user is not authorized to do so at that moment or when the authentication services are not functioning properly.

The process of translating law 12/2005 into the clinical practice went through sev-eral phases, in which the required technical procedures were dened,. This process included a multidisciplinary working group, that organized and attended several meet-ings and exchanged emails, until a nal proposal was produced.

To implement the BTG-RBAC model it was necessary to make some changes in the access control management platform, the Web.Care, as well as in the ICU system. The model is currently in use by health professionals with access to the ICU, since May 2009.

The results show that in the rst year of use, the BTG-RBAC model ltered accesses to unauthorized users that were trying to view reports containing genetic information. However, in comparative terms by groups of users, the average number of reports accessed by users belonging to the group of doctors decreased from 8.2 to 5.5 (reports per user) while the group of personnel in pre career training increased from 3.9 to 4.5 (reports per user).

It is necessary to implement an audit platform to help assess the reasons given by the users regarding the accesses they made using the BTG feature. Even if the necessary technical procedures are in place to ensure compliance with the legislation, a human infrastructure is also required in order to verify the results of these procedures and make the necessary validations of the justications given by the ICU users for accessing those reports.

Agradecimentos

Ao Professor Doutor Luís Filipe Antunes, orientador deste trabalho, por conar e acreditar, pela sua orientação durante o decorrer deste trabalho, pelas críticas e con-selhos.

À Mestre Ana Ferreira, co-orientadora deste trabalho, pelas críticas e conselhos mas, sobretudo, pelo estímulo e ajuda na concretização deste projecto.

Ao Professor Doutor Altamiro da Costa Pereira, director do Mestrado em Informática Médica e do Serviço de Bioestatística e Informática Médica da Faculdade de Medicina da Universidade do Porto, pela oportunidade de realização deste trabalho.

Ao Professor Doutor Ricardo Cruz Correia, pelo tema, motivação e perseverança para a realização deste trabalho.

Ao Mestre Jorge Jácome Gomes, pela motivação e ajuda prestada.

Aos meus colegas de trabalho Carla Amaral, Eliana Sousa, Luís Almeida, Pedro Sacadura e Tiago Costa.

À restante equipa do Serviço de Bioestatística e Informática Médica e do Centro Infor-mática da Faculdade de Medicina do Porto pelo apoio e disponibilidade demonstrada. À minha família, pelo apoio que me deu.

Acrónimos

ANSI American National Standards Institute AR Assembleia da República

BTG Break-The-Glass CE Comissão Europeia

CEN European Committee for Standardization CES Comissão de Ética para a Saúde

CCADIG Corpo Clínico de Acesso aos Dados de Informação Genética CNPD Comissão Nacional Protecção de Dados

CRep Central Repository

DAC Discretionary Access Control DIS Department Information Systems

FMUP Faculdade de Medicina da Universidade do Porto HSJ Hospital São João

ICU Informação Clínica do Utente

LDAP Lightweight Directory Access Protocol MAC Mandatory Access Control

MAID Multi-Agent System for Integration of Data NIST National Institute of Standards and Technology

PL/SQL Procedural Language/Structured Query Language RBAC Role Based Access Control

RCE Registo Clínico Electrónico SAM Sistema Apoio Médico

SBIM Serviço de Bioestatística e Informática Médica SI Sistemas Informação

SSI Serviço Sistemas Informação TBAC Task Based Access Control TMAC Team Based Access Control UAG Unidade Autónoma de Gestão VBAC View Based Access Control VIZ Visualization

Resultados Cientícos

• Farinha P, Cruz-Correia R, Antunes L, Filipe Almeida, Ferreira A. From legis-lation to practice: a case study of break the glass in healthcare. Proceedings of the International Conference on Health Informatics - Healthinf 2010.

• Ferreira A, Chadwick D, Zao G, Farinha P, Correia R, Chilro R, Antunes L.

How to securely break into RBAC: the BTG-RBAC model. Proceedings from 25th Annual Computer Security Applications Conference - ACSAC 2009; 23-31. • Ferreira A, Cruz-Correia R, Antunes L, Farinha P, Oliveira-Palhares E, Chad-wick DW, Costa-Pereira A. How to break access control in a controlled man-ner? Proceeding of the 19th IEEE International symposium on Computer-based Medical systems 2006; 847-851.

Índice

2.2 Modelos de controlo de acesso . . . 10

2.2.1 DAC - Discretionary Access Control . . . 10

2.2.3 RBAC- Role Based Access Control . . . 11

2.2.4 TBAC - Task Based Access Control . . . 11

2.2.5 TMAC - Team Based Access Control . . . 12

2.2.6 VBAC - View Based Access Control . . . 12

2.3 Controlo de acesso à informação de saúde . . . 13

2.4 BTG-RBAC . . . 14

2.5 Papéis e níveis de acesso dos SI de Saúde . . . 17

2.6 Características da autenticação nos SI na saúde . . . 19

2.7 Legislação . . . 20 3 Material e Métodos 25 3.1 Pesquisa bibliográca . . . 25 3.2 Da legislação à prática . . . 26 4 Implementação 35 4.1 Arquitectura do ICU . . . 36 4.2 Web.Care . . . 39 4.2.1 Modelação de dados . . . 40 4.2.2 Tecnologias . . . 41 4.2.3 Módulos . . . 41 4.2.4 Autenticação na plataforma . . . 44 4.3 Implementação . . . 46

Índice

4.3.1 Alterações no Web.Care . . . 48 4.3.2 Alterações no ICU . . . 48

5 Resultados 55

5.1 Resultados antes e depois da implementação do modelo BTG-RBAC . 55 5.2 Resultados por categorias prossionais . . . 57 5.3 Justicações para efectuar BTG . . . 60

6 Discussão 67

6.1 Implementação do modelo BTG-RBAC . . . 67 6.2 Impacto antes e depois da implementação do modelo BTG-RBAC . . 68 6.3 Análise por categorias prossionais . . . 69 6.4 Análise das justicações para efectuar BTG . . . 70

7 Conclusões e trabalho futuro 75

8 Anexos 89

8.1 Artigo publicado como primeiro autor . . . 89 8.2 Legislação . . . 97

Índice de Figuras

2.1 Diagrama de interacção do modelo BTG-RBAC. . . 17

3.1 Métodos da legislação à prática na implementação do modelo BTG-RBAC. . . 27

4.1 Arquitectura do ICU. . . 36

4.2 Modelo Entidade-Relacionamento da plataforma de controlo de acessos Web.Care. . . 40

4.3 Módulos de gestão recursos. . . 42

4.4 Interface para registar e denir o perl do utilizador. . . 43

4.5 Interface para congurar o RBAC. . . 44

4.6 Esquema para efectuar BTG. . . 47

4.7 Janela de aviso para o BTG. . . 50

5.1 Motivos inseridos pelos utilizadores para efectuar BTG, distribuídos mensalmente. . . 61

5.2 Percentagens acumuladas dos motivos inseridos pelos utilizadores que efectuaram BTG. . . 62

Índice de Tabelas

2.1 Tipo de papéis. . . 18 4.1 Relatórios recolhidos por departamento. . . 38 4.2 Dados estatísticos de utilização do ICU. . . 39 4.3 Tabela para armazenar as justicações sobre a auditoria ao BTG. . . . 49 5.1 Percentagem de acessos aos relatórios contendo informação genética de

acordo com o número total desses relatórios antes e depois da imple-mentação do modelo BTG-RBAC, bem como o número de utilizadores distintos que realizaram os acessos. . . 56 5.2 Número de acessos feitos por BTG aos relatórios contendo a informação

genética (de utilizadores que não pertencem ao grupo de autorização). 57 5.3 Os motivos mais comuns para os utilizadores efectuarem BTG,

apre-sentados pelos mesmos utilizadores. . . 57 5.4 Dados por grupos de utilizadores antes e depois da implementação do

BTG. . . 58 5.5 Ocorrência de BTG por grupos de utilizadores. . . 59 5.6 Motivos introduzidos na opção outro para efectuar BTG. . . 63

Capítulo 1

Introdução

1.1 Contextualização

Actualmente, para aumentar a eciência e a qualidade dos cuidados de saúde, todos os resultados dos procedimentos para obtenção de um diagnóstico, assim como os exames efectuados e as terapêuticas realizadas, devem ser documentados, comunica-dos e avaliacomunica-dos cuidacomunica-dosamente. Neste contexto, devem ser implementacomunica-dos sistemas de informação e de comunicação partilhados por vários estabelecimentos de saúde e acessíveis a diversos prossionais de saúde [Blobel, 2004]. Em particular, é essencial garantir a segurança da informação, isto é, a condencialidade, integridade e disponi-bilidade, num sistema com estas característica [Benferhat and Baida, 2004]. Neste âmbito, em particular no sector da saúde, um acesso ou uma alteração não autor-izada à informação existente no registo clínico pode conduzir a graves consequências sobre o diagnóstico do paciente. No entanto, proibir de forma absoluta que um médico aceda ao registo clínico pode originar efeitos desastrosos para o paciente, nomeada-mente em situações de emergência [Benferhat and Baida, 2004]. Contudo, este estudo mostra que falhas num sistema de informação (incluído as falhas de segurança), podem mesmo originar a morte dos pacientes [Gritzalis, 1997].

As recomendações e os regulamentos que estão disponíveis nos cuidados de saúde, para proteger a informação médica sensível, têm como intuito garantir que este tipo de in-formação só seja acedida e utilizada num contexto especíco, e de forma justicada [Membres-CdMaÉ, 1997][Ministers-CoE-Co, 2004]. Estas recomendações tendem a ser genéricas. No entanto, não é fácil traduzir essas orientações na prática, sendo mesmo muitas vezes impossível. Estudos efectuados mostram que uma regulamen-tação excessiva pode criar uma barreira que os médicos têm de superar quando estão a cuidar de um paciente. No entanto, deve-se desenvolver todos os esforços possíveis para tornar essa tradução efectiva de modo que a condencialidade da informação médica - prevenção do acesso não autorizado - seja garantida [Ross-Lee and Weiser, 1994] [Anderson, 2007].

Os Registos Clínicos Electrónicos (RCE) são uma importante ferramenta de apoio para consulta, diagnóstico e integração de informação heterogénea de diferentes lu-gares, [Cruz-Correia et al., 2005] salientando ainda mais a necessidade de conden-cialidade e controlo de acesso para denir quem tem acesso a um determinado recurso, e também qual o tipo de acesso a esse recurso. No entanto, a segurança não deve constituir um entrave para uma utilização ecaz e para a integração dos RCE na prática médica, mas sim permitir uma forma controlada e transparente de o fazer. Um RCE chamado ICU - Informação clínica do Utente, foi desenvolvido e está em uso desde 2004 no segundo maior hospital de Portugal - o Hospital S. João (HSJ) - [Cruz-Correia et al., 2005][Ferreira et al., 2004]. Associado ao ICU houve a neces-sidade de usar uma plataforma para efectuar a gestão dos acessos para o RCE, e a plataforma WebCare foi desenvolvida com essa nalidade [Farinha P, 2006]. Esta plataforma é baseada no modelo Role Based Access Control (RBAC) [Ferraiolo et al., 2001] e ajuda a realizar de uma forma fácil e exível, as acções administrativas de controlo de acesso.

1.2. Descrição do problema

1.2 Descrição do problema

Em Maio de 2005, a directora do serviço de Imuno-Hemoterapia comunicou ao HSJ a sua preocupação relativa à Lei no _{12/2005, que vem regulamentar o acesso à} In-formação genética pessoal e inIn-formação de saúde. Esta legislação, Portuguesa, de-ne como a informação de genética deve ser protegida e quais os prossionais de saúde que estão autorizados a acedê-la durante o seu trabalho [AR, 2005]. Tendo o ICU relatórios do serviço de Imuno-Hemoterapia que contêm informação genética, foi necessário implementar políticas mais exíveis de controlo de acesso, não só para melhorar a eciência do ICU, mas também para fazer cumprir a legislação relacionada com a informação de genética.

De forma a implementar uma solução legal e exível, a informação é restrita a um grupo de prossionais de saúde previamente denido. No entanto, este acesso não é totalmente negado a todos os outros prossionais de saúde, eles podem ter tam-bém acesso a essa informação, em situações de emergência, mas de forma contro-lada [Rissanen et al., 2004][Povey, 2000][Ferreira et al., 2006], como Break-The-Glass (BTG). A ideia é que os prossionais de saúde sejam avisados de que não estão au-torizados a aceder essa informação, mas se for uma emergência ou outra situação justicável, eles poderão aceder, sabendo que terão que justicar o acesso e esta jus-ticação será mais tarde validada por um seu superior.

1.3 Objectivos

O objectivo principal desta dissertação é implementar um modelo de controlo de acesso BTG-RBAC [Ferreira et al., 2009] num cenário real de saúde, (sistema de informação

ICU), assente na legislação no_{12/2005. Foi também efectuada uma avaliação, do}

processo de tradução da legislação para a prática de saúde, de forma a vericar se o conceito BTG-RBAC, consegue ltrar os acessos não autorizados que normalmente ocorreriam a relatórios com informação de genética no ICU, caso o BTG-RBAC não

Capítulo 2

Estado da arte

2.1 Controlo de acesso

Num sistema de informação, os utilizadores não devem ter os mesmos acessos e os mesmos direitos à informação que é gerada, processada e disponibilizada, visto não terem os mesmos objectivos ou executarem as mesmas tarefas com o sistema. O con-trolo de acesso, regula a forma como os privilégios (alteração, leitura, execução, etc.) a determinados recursos são ou não permitidos [Ferraiolo, 2001]. O controlo de acesso dene quem tem acesso a um determinado recurso, e também qual o tipo de acesso a esse recurso. O controlo pode estar embutido dentro do sistema de informação, incorporado nas aplicações ou pode ser implementado por meio de módulos de segu-rança. Pode, ainda, ser implementado no sistema de informação a ser protegido ou ser implementado em dispositivos externos ao sistema. Todo o processo de controlo de acesso terá de estar enquadrado na legislação em vigor.

Os mecanismos de controlo de acesso que são implementados nesses sistemas de in-formação, têm como principal objectivo assegurar a condencialidade, a integridade e a disponibilidade da informação existente:

• Condencialidade - prevenir o acesso não autorizado à informação; • Integridade - prevenir a modicação não autorizada à informação; • Disponibilidade - acesso autorizado à informação sempre que necessário.

2.2 Modelos de controlo de acesso

Existem vários tipos de modelos de controlo de acessos, nomeadamente: DAC - Dis-cretionary Access Control, MAC - Mandatory Access Control, RBAC - Role Based Access Control, TBAC - Task Based Access Control, TMAC - Team Based Access Control ou VBAC - View Based Access Control. Os modelos de base são o DAC e o MAC, todos os outros modelos herdaram conceitos destes modelos. Nesta secção fazemos uma breve descrição de cada um.

2.2.1 DAC - Discretionary Access Control

Trata-se de um modelo de controlo de acesso determinado pelo proprietário do recurso. O proprietário do recurso decide quais são os utilizadores que têm permissões de acesso ao seu recurso e quais são os privilégios que eles devem ter sobre o mesmo. Todos os re-cursos de um sistema têm um determinado proprietário [Kalam et al., 2003][Miège, 2006]. No entanto, esta forma de controlo de acessos não é aconselhada num ambiente hospi-talar porque não pode ser controlada nas prestações de cuidados de saúde em hospitais ou redes de cuidados com centenas ou mesmo milhares de utilizadores [Blobel, 2004].

2.2.2 MAC - Mandatory Access Control

As políticas de controlo de acesso a um determinado recurso são determinadas pelo sistema e não pelo proprietário do recurso, ao contrário do DAC [Miège, 2006]. Sempre que existe uma tentativa de acesso a um recurso, uma regra de autorização imposta

2.2. Modelos de controlo de acesso

pelo sistema examina os atributos de controlo de acesso e decide se o acesso pode ocorrer.

Este modelo é utilizado em sistemas de informação militares por causa do seu con-trolo centralizado. A principal limitação do MAC é a sua aplicabilidade em sistemas distribuídos, onde não é recomendado [Navarro, 2003].

2.2.3 RBAC- Role Based Access Control

O modelo RBAC propõe estruturar a política de controlo de acesso em torno do conceito de papel. Um papel é um conceito organizacional: os papéis são asso-ciados aos utilizadores normalmente conforme a categoria prossional desses uti-lizadores numa dada organização. O princípio de base do modelo RBAC é con-siderar que os privilégios, as permissões ou os recursos estão associados esses papéis. No RBAC, os papéis associados são às permissões para realizar acções sobre ob-jectos. Utilizadores com a mesma categoria prossional têm os mesmos privilégios [Ferraiolo et al., 2001][Kalam et al., 2003][Miège, 2006]. No RBAC, também é pos-sível organizar os recursos de forma hierárquica. Os recursos herdam os privilégios dos recursos que são hierarquicamente inferiores.

2.2.4 TBAC - Task Based Access Control

No modelo RBAC, as acções correspondem geralmente a comandos elementares, como o da leitura ou de escrita num objecto. Nas aplicações mais recentes, surge a neces-sidade de controlar a realização de acções compostas, chamadas de tarefas ou de actividades [Miège, 2006]. Por exemplo, dentro de uma agência de viagens, a tarefa da compra de um bilhete de avião decompõe-se em várias acções elementares, tal como a reserva do bilhete, o pagamento do bilhete e a emissão de uma factura. A necessidade de controlar as actividades compostas, está presente nas aplicações do tipo workow. O modelo TBAC foi o primeiro a introduzir o conceito de tarefa.

Out-ros modelos também foram desenvolvidos para controlar a execução de um workow [Bertino et al., 1999]. Assim, no exemplo da compra de um bilhete de avião, a per-missão de editar uma factura só pode ser realizada após as tarefas reserva e compra do bilhete estarem concluidas.

2.2.5 TMAC - Team Based Access Control

O modelo TMAC introduz a noção de equipa onde os privilégios estão associados aos papéis como as equipas. Os privilégios que um determinado utilizador tenha associados, são as combinações dos privilégios associados a ele próprio mais os priv-ilégios associadas à equipa, à qual ele pertence [Georgiadis et al., 2002][Miège, 2006]. Muitas combinações (por exemplo, a união dos privilégios) são encaradas. No en-tanto, o modelo TMAC está incorrecto porque ele introduz duas relações binárias : tarefa-privilégio e equipa-privilégio. Se introduz a noção de equipa, é necessário con-siderar uma relação ternária equipa-tarefa-autorização para especicar que os priv-ilégios dependem, não somente da tarefa, mas também da equipa na qual é exercida essa tarefa. Com a ajuda de uma relação ternária, pode-se facilmente especicar que os privilégios da tarefa de um médico mudam quando se trata de um médico dentro de uma equipa de internamento, ou de um médico numa equipa de urgência [Thomas, 1997][Miège, 2006].

2.2.6 VBAC - View Based Access Control

Os modelos RBAC e TBAC introduziram respectivamente os conceitos de papel e de tarefas para as estruturas, os sujeitos e as acções. Para facilitar a denição e a gestão de uma política de controlo de acesso, é necessário o conceito estruturado de objectos estruturados. Entre os modelos de controlo de acesso que oferecem uma tal estruturação de objectos, o exemplo mais comum é o modelo de controlo de acesso proposto pelo SQL para as bases de dados relacionais. A expressão de uma política de controlo de acesso no SQL baseia-se no conceito de vista, cujo o modelo é designado

2.3. Controlo de acesso à informação de saúde

de VBAC (View Based Access Control). Intuitivamente, dentro de uma base de dados relacional, uma vista corresponde aos resultados de uma consulta de SQL à qual nós demos o nome. Este conceito de vista é utilizado para estruturar a expressão de uma política de controlo de acesso com a ajuda das instruções GRANT (que permite atribuir uma nova permissão a um utilizador) e REVOKE (que permite remover uma permissão a um utilizador) [Miège, 2006].

No entanto, nenhum dos modelos de controlo de acesso que foram abordados acima é completo, visto que é difícil aplicar uma política de controlo de acesso genérica em certos cenários que incluam, por exemplo [Kalam et al., 2003]:

• Regras que indiquem as permissões ou proibições contextuais. Existem muitas regras que se aplicam somente em circunstâncias especícas. Por exemplo, os médicos podem ter permissões em contextos especícos, como o contexto do serviço de urgência;

• Regras que indiquem os compromissos ou as recomendações. Nos modelos clás-sicos de controlo de acesso as permissões são limitadas. Alguns modelos de controlo de acesso incluem as proibições;

• Regras que são especícas de organizações. Em particular, organizações que são estruturadas em várias sub - organizações, tendo elas próprias as suas políticas de controlo de acesso. Os modelos devem fornecer meios para denir as difer-entes políticas de controlo de acesso a adoptar em cenários especícos.

2.3 Controlo de acesso à informação de saúde

Um sistema de informação nos serviços de saúde é um conjunto de componentes que se integram para pôr em prática os serviços e-saúde, que consistem na utilização de tecnologias de informação e de comunicação através de um conjunto de funções, que se encontram associadas ao sector da saúde [Oh et al., 2005]. Enquanto os dados

são transformados em informação, pelos sistemas de informação, a autenticação e a autorização tornam-se num aspecto necessário aos sistemas e-saúde. Isto signica, que os sistemas devem proteger os dados e a informação que é produzida de forma a manter a condencialidade, a integridade e a disponibilidade a qualquer nível. As arquitecturas que vão sendo propostas são simultaneamente para a autorização e a autenticação dos sistemas de informação na saúde e, são uma prática corrente [Han et al., 2006].

2.4 BTG-RBAC

Os modelos de controlo de acesso que já foram referidos, partem do princípio que todas as necessidades de acesso são conhecidas previamente e que essas necessidades podem ser expressas e compreendidas por uma máquina. No entanto, a realidade é dinâmica e as situações imprevistas acontecem a qualquer momento. Por este motivo, e devido às características únicas que existem nos cuidados de saúde, a política de Break-The-Glass [Rissanen et al., 2004], (que consiste em aceder a um recurso do sistema em caso de emergência, quando a autenticação normal não pode ser efectuada ou não funcione normalmente) deve ser aplicada nestas situações de forma a que um dado utilizador aceda à informação de um doente. Quando existe uma tentativa de aceder à informação para a qual não tem autorização, o utilizador deve ser alertado e avisado que se continuar com o procedimento, alguém responsável será noticado pela sua acção e pedirá justicações mais tarde [Ferreira et al., 2006].

O modelo RBAC é um modelo rígido onde existem apenas 2 decisões de controlo de acesso: conceder ou negar. As políticas BTG, por outro lado, são exíveis e permitem aos utilizadores quebrar ou sobrepor os controlos de acesso de uma forma controlada e justicável. Em 2009, foi proposto o modelo BTG-RBAC [Ferreira et al., 2009], que é uma extensão do modelo Core RBAC com obrigações, de modo a incluir a operação BTG. Trata-se de uma integração do BTG dentro do standard NIST RBAC ANSI, de forma transparente e segura, para que este possa ser adoptado genericamente

2.4. BTG-RBAC

em qualquer domínio onde imprevistos ou situações de emergência podem ocorrer [Ferreira et al., 2009].

As obrigações são operações accionadas automaticamente e de forma obrigatória, quando determinada acção é realizada. São tarefas que estão associadas aos privilégios (ou permissões). Assim, quando uma operação é realizada num objecto, as obrigações que estão associadas com essa operação nesse objecto são activadas e realizadas ao longo dessa operação. OBTG(op) é denida como uma operação Break-The-Glass num objecto para uma determinada operação op.

Neste novo modelo BTG-RBAC existe uma função designada por CheckBTGAccess, que vai vericar se um determinado utilizador tem permissões para aceder ao recurso pedido, e retorna um destes 3 resultados:

1. Tem autorização para aceder ao recurso que pediu (GRANT); 2. Não tem autorização para aceder ao recurso que pediu (DENY);

3. Não tem autorização para aceder ao recurso, mas tem permissão para efectuar BTG nesse recurso.

As etapas necessárias para que um utilizador execute BTG a um recurso no modelo BTG-RBAC, supondo que o estado de BTG é inicialmente FALSO, são as seguintes:

1. O utilizador tenta aceder a um recurso para o qual não tem autorização 2. O serviço de autenticação valida as credenciais do utilizador

3. O serviço de autenticação retorna a identidade autenticada do utilizador (no caso onde a autenticação não é sastifeita, uma mensagem da rejeição é emitida pela aplicação para o utilizador e o pedido termina aqui)

4. Se o utilizador estiver autenticado, a aplicação chama o motor de gestão de políticas de BTG-RBAC passando-lhe os detalhes da sessão, a operação pedida e o objecto pedido (CheckBTGAccess)

• Ao existir uma regra da política que concede o acesso ao objecto, o CheckBT-GAccess retorna PERMISSÃO(GRANT), passando assim para a etapa 9; • Ao existir uma regra da política que concede o acesso ao objecto se o estado de BTG é VERDADEIRO, mas o valor é actualmente FALSO, o motor de BTG-RBAC retorna o valor da decisão

• Em todos os outros casos o CheckBTGAccess nega o pedido, terminando

aqui

5. A aplicação pode agora perguntar ao utilizador se quer executar o BTG naquele recurso. Se o utilizador executar o BTG (dando uma razão, se aplicável) passa para o passo seguinte. (No caso do utilizador escolher não fazer BTG, o pedido original termina aqui)

6. A aplicação chama o motor da política de BTG-RBAC passando-lhe os detalhes da sessão, a operação (OBTG (op)) pedida e o objecto pedido (CheckBTGAc-cess):

• O motor da política de BTG-RBAC verica a politica, vê que a operação é permitida e ajusta a variável de estado de BTG para VERDADEIRO e retorna todas as obrigações associadas com a operação (op) de OBTG (por exemplo noticar um gerente responsável, escrever para um(a) auditor(ia)) à aplicação, junto com a resposta de PERMISSÃO(GRANT)

7. A aplicação executa as obrigações retornadas e é mostrada novamente ao uti-lizador a opção para aceder ao recurso que pediu, seleccionando-a

8. A aplicação chama o motor da política de BTG-RBAC passando-lhe os detalhes da sessão, a operação e o objecto pedidos originalmente (CheckBTGAccess):

• CheckBTGAccess retorna permissão(GRANT) dado que a variável de

es-tado BTG já está a VERDADEIRO (TRUE) 9. Aplicação executa a operação pedida pelo utilizador

2.5. Papéis e níveis de acesso dos SI de Saúde

10. & 11 O recurso é acedido pelo utilizador

Figura 2.1: Diagrama de interacção do modelo BTG-RBAC.

2.5 Papéis e níveis de acesso dos SI de Saúde

Visto que os papéis (categorias prossionais) que são desempenhados nos cuidados de saúde são relevantes para certos modelos de controlo de acesso, é importante serem especicados. Existem dois tipos de papéis distintos: os papéis estruturais altamente estáticos e os papéis funcionais altamente dinâmicos. Vendo os papéis estruturais e os papéis funcionais no mesmo contexto, os papéis estruturais fornecem os pré requisitos e competências para que as entidades possam executar as suas interacções (actos) nos seus papéis especicamente funcionais. As qualicações, as aptidões, etc. inuenciam a atribuição dos papéis estruturais e a execução das suas tarefas conforme os seus papéis funcionais [Blobel et al., 2006]. Exemplos de possíveis papéis estruturais e funcionais dos prossionais de saúde, são apresentados na seguinte Tabela 2.1: O nível de acesso à informação na saúde deve ter em consideração a sensibilidade da

Tabela 2.1: Tipo de papéis.

Exemplos de papéis estruturais Exemplos de papéis funcionais Director médico Membro da equipa de diagnóstico Director de clínica Membro da equipa de terapêutica Chefe do departamento Médico de consulta

Médico sénior Médico de família

Médico residente Enfermeira de função especíca Médico Médico assistente Estagiário Enfermeira chefe Enfermeira Estudante de medicina

informação existente no registo clínico. A Comissão Europeia de Normalização (CEN) produziu normas que vieram especicar os níveis de sensibilidade, consoante o papel praticado do prossional de saúde, nos cuidados prestados ao paciente [CEN, 2007]. Sendo o nível 5 o mais sensível e o nível 1 o menos sensível, os níveis de sensibilidade são os seguintes:

Nível 5 - Cuidados pessoais: Apenas acessível ao individuo ou para ser partilhado pelo individuo com apenas uma ou duas pessoas da sua conança (e os outros apenas com autorização).

Nível 4 - Cuidados privilegiados: Acesso restrito a um pequeno grupo de pessoas que cuidam intimamente do paciente, talvez uma equipa de cuidados imediatos ou equipa de clínicos seniores.

Nível 3 - Cuidados clínicos: Padrão para o atendimento clínico normal (a maioria do pessoal clínico que cuida directamente do paciente deve ser capaz de aceder à quase totalidade do RCE).

Nível 2 - Gestão clínica: Informação de saúde menos sensível, que pode necessitar de ser acedidas por um maior número de pessoas, das quais nem todas estão activamente a cuidar do paciente.

2.6. Características da autenticação nos SI na saúde

Nível 1 - Gestão de cuidados: Informação de saúde que talvez precise de ser acedidas por uma ampla gama de administrativos, para gerirem o acesso aos cuidados de saúde.

2.6 Características da autenticação nos SI na saúde

• A integração de sistemas de informação: facilita a colaboração das instituições de saúde nas quais cada uma delas é independente no seu domínio e denem elas próprias as suas políticas de controlo de acesso. No entanto, os utilizadores num determinado domínio podem pedir e aceder a informação noutros domínios; • As redes existentes entre as várias instituições não são estáticas: podem existir

novas instituições de saúde a querer partilhar a rede a qualquer momento; • Não existe nenhuma autoridade central que administre ou imponha uma política

a todos os locais que se encontram interligados;

• O facto de a informação médica poder ser consultada em locais afastados e de-sconhecidos, pertencendo provavelmente a domínios diferentes e exibindo conse-quentemente uma política diferente de controlo de acesso, impõe a necessidade de tratar os dados de acordo com os atributos especícos de controlo de acesso (políticas);

• Nenhuma relação predenida de conança perante as diferentes unidades de

saúde ou grupos de unidades podem ser assumidas. A avaliação de conança deve ser dinâmica.

Devido à grande sensibilidade que os dados têm em sistemas de informação de saúde, é estritamente necessário manter os níveis de controlo de acesso adequados. As

condições necessárias para vericar esses níveis de controlo de acesso é a utilização de uma estrutura centralizada, a autenticação e a autorização devem ser efectuadas uma vez, com o suporte da gestão de uma base de dados e com a segurança de arquitec-turas distribuídas com funções de decisão de controlo de acessos. As infra-estruarquitec-turas distribuídas de autenticação e de autorização devem fornecer um apoio para políticas hierárquicas de controlo de acesso [Blobel et al., 2006].

Estas mesmas infra-estruturas devem-se encontrar em ambientes de desenvolvimento, onde a quantidade de código de segurança para a qual é necessário efectuar manutenção, deve ser mínimo e desenvolvido de forma a simplicar a iteração de segurança [Gritzalis, 2004].

2.7 Legislação

A 2 de Abril de 1976 a assembleia constituinte aprova a nova Constituição da República Portuguesa e decreta novos princípios fundamentais no qual surge, sob o capítulo dos direitos, liberdades e garantias pessoais, o artigo 35o_{sobre a utilização da informática.} Na alínea 1 desse mesmo artigo, foi denido que todos os cidadãos tem o direito de tomar conhecimento do que constar de registos mecanográcos a seu respeito e do m a que se destinam as informações, podendo exigir a recticação dos dados e a sua actualização. [AR, 1976].

A 24 de Outubro de 1995 o Parlamento e Conselho Europeu publicam por sua vez a directiva 95/46/CE relativa à protecção de pessoas singulares no que diz respeito ao tratamento dos dados pessoais e à livre circulação desses dados [PE, 1995].

A 26 de Outubro de 1998, foi publicada em Portugal a lei no_{67/98, que transpõe para} a ordem jurídica Portuguesa a directiva 95/46/CE, do parlamento e conselho Europeu, do artigo 7, alínea 4, onde se lê: o tratamento dos dados referentes à saúde e à vida sexual, incluindo os dados genéticos, é permitido quando for necessário para efeitos de medicina preventiva, de diagnóstico médico, de prestação de cuidados ou tratamentos médicos ou de gestão de serviços de saúde, desde que o tratamento desses dados seja

2.7. Legislação

efectuado por um prossional de saúde obrigado a sigilo, ou por outra pessoa sujeita igualmente a segredo prossional, seja noticado à CNPD, nos termos do artigo 27o_, e sejam garantidas medidas adequadas de segurança da informação [AR, 1998]. A 3 de Janeiro de 2001, uma resolução da Assembleia da República no _{1/01 publica} em Portugal, a convenção para a protecção dos direitos do homem e da dignidade do ser humano face às aplicações da biologia e da medicina: convenção sobre os direitos do homem e a biomedicina. No artigo 8 lê-se situações de urgência: Sempre que, em virtude de uma situação de urgência, o consentimento apropriado não puder ser obtido, poder-se-á proceder imediatamente à intervenção medicamente indispensável em benefício da saúde da pessoa em causa [AR, 2001].

A 15 de Dezembro de 2004, o Comité Europeu aprovou a Recomendação no_{R(2004) 17} que foca o Impacto das Tecnologias de informação nos Cuidados de Saúde, nomeada-mente a Internet e o modo como estas tecnologias inuenciam a recolha, tratamento e o acesso aos dados clínicos [Ministers-CoE-Co, 2004].

Por m a 26 de Janeiro de 2005, foi aprovada em Portugal a Lei 12/2005 designada Lei de Informação Genética Pessoal de Saúde, cujo Artigo 3 aborda a propriedade da informação de saúde. A alínea 1 indica que a informação de saúde, incluindo os dados clínicos registados, resultados de análises e outros exames subsidiários, intervenções e diagnósticos, é propriedade da pessoa, sendo as unidades do sistema de saúde os depositários da informação, a qual não pode ser utilizada para outros ns que não os da prestação de cuidados, a investigação em saúde e outros estabelecidos pela lei. Na alínea 3, está escrito que o acesso à informação de saúde por parte do seu titular, ou de terceiros com o seu consentimento, é feito através do médico, com habilitação própria, escolhido pelo titular da informação [AR, 2005].

Capítulo 3

Material e Métodos

Este capítulo está dividido em duas partes, na primeira parte são descritas as palavras-chave que foram utilizadas em diversos portais na internet, onde se pode pesquisar publicações cienticas na área da segurança informática na saúde, com o intuito de obter a literatura adequada para a elaboração do estado da arte. Na segunda parte deste capítulo, são relatados todos os passos que foram efectuados desde o dia em que foi publicada, em diário da república, a lei 12/2005 referente à Informação genética pessoal e informação de saúde. São enunciados os vários intervenientes neste processo, as várias reuniões que foram realizadas, os documentos que foram produzidos e os procedimentos elaborados para a implementação do BTG-RBAC no sistema ICU referido anteriormente.

3.1 Pesquisa bibliográca

Foram efectuadas pesquisas na Medline, Google Scholar, Google, ACM e IEEE Xplore, com várias combinações de termos: como access control, security, health, au-torization, privilege management. Os artigos encontrados foram seleccionados pelo título e resumo de acordo com o tema abordado, tendo sido valorizados os artigos mais

recentes, que foram descarregados na totalidade dos vários sítios. Após a selecção dos artigos, foi efectuada uma leitura na íntegra dos mesmos, sendo seleccionados os con-teúdos para este trabalho que abordavam temas sobre a segurança informática na saúde, o controlo de acesso à informação na saúde e modelos de controlo de acesso na saúde. A recolha dos artigos foi efectuada do dia 6 de Agosto até ao dia 25 de Agosto de 2007.

Quanto à pesquisa sobre a legislação, foram efectuadas pesquisas directas nos portais institucionais onde existe informação sobre legislação nacional e europeia. A nível nacional, as pesquisas foram realizadas no portal do diário da república, da assem-bleia nacional e da comissão nacional de protecção de dados. A nível europeu, as pesquisas foram realizadas nos portais do parlamento Europeu, do conselho Europeu e da comissão Europeia. Foram seleccionados os documentos que abordam legislação e directivas sobre informática na saúde. Nesses documentos foi efectuada uma leitura na íntegra dos artigos que abordavam o tema da informática na saúde e retirado a informação de interesse sobre a segurança, privacidade e controlo de acesso na saúde.

3.2 Da legislação à prática

A Figura 3.1 apresenta todas as fases que ocorreram desde a publicação da lei 12/2005, até ao dia em que o modelo BTG-RBAC entrou em produção no HSJ. Durante todo este processo houve várias reuniões, troca de emails e uma proposta nal para im-plementar o modelo BTG-RBAC, para que esta lei pudesse ser cumprida. Tudo isto envolveu um grupo de trabalho multidisciplinar, desde o director clínico do HSJ, à directora do serviço de Imuno-Hemoterapia , à Comissão de Ética (CES) do HSJ, o representante do Serviço de Sistemas de Informação(SSI) do HSJ e por m elementos do SBIM, responsáveis pelo ICU. A parte da implementação do BTG-RBAC e a sua colocação em produção, refere-se às fases Implementação e testes ao processo de con-trolo de acessos e O sistema de concon-trolo de acesso é usado pelos utilizadores reais do HSJ apresentadas na Figura 3.1.

3.2. Da legislação à prática

No dia 11 de Maio de 2005, a então directora do serviço de Imuno-Hemoterapia, deu conhecimento à CES do HSJ de uma comunicação que oportunamente havia feito ao Sr. Director Clínico, referindo-lhe as preocupações que a Lei no _{12/2005 tinha que} ser devidamente aplicada no HSJ. Ela elaborou um documento onde transcreveu oito excertos da lei que lhe suscitava dúvidas, quatro delas dizem respeito ao sistema ICU. A 28 de Novembro de 2005, a CES esclareceu as dúvidas levantadas a partir de um parecer.

Para agilizar o tratamento institucional desta matéria no respeito pelas novas exigên-cias legais, a CES reuniu várias vezes com os representantes da Direcção Clínica, do Serviço de Imuno-Hemoterapia, Serviço de Genética Médica, Serviço de Sistemas de Informação e Serviço de Bioestatística (SBIM) e Informática Médica da Faculdade de Medicina da Universidade do Porto (FMUP), e interrogou os Srs. Directores das UAG's do HSJ no sentido de indicarem quem, nos respectivos Serviços e, por razões clínicas devidamente fundamentadas (i.e. pela natureza das funções clínicas desem-penhadas, possam produzir e aceder a informação genética deste âmbito), pudesse ter acesso a áreas restritas de informação genética no processo clínico informatizado. No termo deste percurso, a 20 de Agosto de 2008, foi elaborada uma proposta -nal que foi submetida para aprovação do conselho de administração do HSJ, com a denição metodológica do que devia ser implementado. Foi proposto ao conselho de administração do HSJ que:

1. Fossem listados os médicos do Hospital de S. João que reunissem os requisi-tos clínicos e legais, de acordo com o imposto pela CES, e constituissem um Corpo Clínico de Acesso aos Dados de Informação Genética (CCADIG), para poder solicitar a detecção do estado de heterozigotia para doenças recessivas, o diagnóstico pré-sintomático de doenças monogénicas e os testes de susceptibil-idades genéticas em pessoas saudáveis e, bem assim, poder aceder à respectiva informação;

3.2. Da legislação à prática

sendo do foro da responsabilidade individual, o cumprimento desta determi-nação legal;

3. Os resultados dos estudos relativos à informação genética em apreço serão dev-idamente codicados pelo laboratório que os efectua;

4. A lista de relatórios disponíveis no ICU manter-se-á idêntica à actual, ou seja, os relatórios de genética serão listados a todos os utilizadores e não serão marcados com nenhuma etiqueta que permita a sua distinção dos restantes;

5. A gestão dos utilizadores que pertencem ao CCADIG é efectuada por pessoal indicado pelo SSI do HSJ (será efectuada uma pequena acção de formação, para o efeito);

6. Aos utilizadores registados no CCADIG é facultado o acesso livre ao conteúdo dos relatórios com informação genética;

7. Aos utilizadores que não pertençam ao CCADIG, e que solicitem a visualização de um relatório com a informação genética no âmbito denido (Lei n.o_12/2005 - DR no_{18 de 26 Jan 2005), será mostrado um alerta avisando que o relatório} contém informação genética de acesso restrito. Este alerta terá a seguinte men-sagem: O relatório que tentou aceder contém informação genética. Segunda a legislação em vigor apenas pessoas que pertençam ao CCADIG - Corpo Clínico de Acesso aos Dados de Informação Genética têm acesso a essa informação. Actualmente você não pertence a esse grupo. Se pretende aceder a este relatório deverá descrever o motivo do acesso e seleccionar a opção Sim, pretendo ver o relatório. Este acesso não previsto será noticado à Direcção Clínica. Solicitar-se-á a introdução de uma mensagem que descreva o motivo para este acesso não previsto (um pequeno formulário incluirá uma lista de frases feitas com os mo-tivos mais comuns, simplicando e normalizando assim o processo de escrita). Descrito o motivo, será activado um botão que permitirá a visualização do re-latório. Se o relatório for visualizado, será registada na base de dados do ICU

a informação relativa a este acesso (data e hora, identicação do médico, iden-ticação do doente e ideniden-ticação do computador);

8. Será enviado um e-mail periódico, semanal, com aviso de recepção, para a Di-recção Clínica, com a lista dos acessos não previstos, sendo registada a noti-cação da recepção na Base de Dados do ICU;

9. Se aprovado pelo Conselho de Administração, este documento será divulgado a todos os prossionais de saúde do Hospital São João (HSJ), bem como o teor da Lei 12/2005.

No dia 20 Março de 2009, o CES reuniu com a directora do SSI do HSJ e com três elementos do SBIM da FMUP para denirem aspectos técnicos da implementação do modelo BTG-RBAC. Nessa reunião cou aprovado o desenho da janela de aviso, com o respectivo formulário que foi apresentado pelo SBIM. Ainda foi proposto pelo SBIM, e aceite nessa reunião, que existissem motivos predenidos de forma a que o utilizador do Informação Clínica do Utente (ICU) pudesse optar por um deles para fazer Break-The-Glass (BTG). Os motivos predenidos são:

• Eu deveria pertencer ao grupo CCADIG;

• Tenho urgência em aceder a esta informação mesmo não tendo autorização neste momento para tal;

• Outro (descrever o motivo na caixa de texto abaixo).

Decidiu-se ainda que os dados referentes ao BTG fossem guardados na base de dados do ICU e que, ao m da semana, o sistema enviasse automaticamente o resumo semanal para o director clínico do HSJ, sobre as ocorrências de BTG durante essa semana. Para implementar este procedimento, deniu-se a criação de um programa automático que corresse todas as semanas de sábado para domingo, onde iria executar um cheiro que consultasse a base de dados do ICU, e que devolvesse uma listagem dos relatórios com informação de genética, que foram acedidos no sistema de informação

3.2. Da legislação à prática

do ICU, por utilizadores que não pertencessem ao grupo CCADIG. Essa listagem deveria conter dados sobre a data de acesso ao relatório, número mecanográco e nome do prossional de saúde, data e tipo de relatório, serviço que produziu o relatório, nome e número sequencial do utente e por m o motivo invocado para fazer BTG. A partir desta reunião foi implementado o modelo BTG-RBAC e efectuados alguns testes no ICU com as características que foram denidas. No dia 13 de Maio de 2009, foi colocado em produção o controlo de acesso com BTG e os utilizadores do ICU começaram a usufruir dele.

Capítulo 4

Implementação

Neste capítulo é descrita a implementação do modelo BTG-RBAC no ICU. É impor-tante referir que o modelo BTG-RBAC é implementado num SI que já se encontra em produção desde 2004 no HSJ, e cujo arquitectura é apresentada nesta secção. Numa primeira fase, é efectuada uma breve descrição do ICU, como é feita a recolha dos relatórios dos doentes e como um utilizador pode aceder aos mesmo. Numa segunda fase, é apresentada a plataforma Web.Care. É nesta plataforma que são conguradas as políticas de controlo de acesso dos vários SI que o SBIM mantém, e onde se gere as contas de utilizadores, monitoriza os diversos recursos existentes em vários projectos distintos, controla os acessos que são efectuados na plataforma e administra as permissões de acessos. Por m, são descritos todos os passos que foram necessários para implementar o modelo BTG-RBAC, desde as alterações necessárias que foram efectuadas na base de dados às alterações na conguração da plataforma Web.Care, para denir um novo perl de utilizador no código.

4.1 Arquitectura do ICU

Com a disseminação das Tecnologias de Informação e Comunicação (TIC), muitos departamentos hospitalares, ou prossionais de saúde, adquiriram software médico ou criaram as suas próprias bases de dados informáticas, de forma a armazenar e gerir registos contendo dados relevantes para o tratamento dos seus paciente. A natureza destas aplicações não promove a partilha e utilização generalizada da infor-mação clínica, originando inúmeras vezes inconsistências e/ou redundância nos dados armazenados. [Cruz-Correia, 2005].

O ICU é um sistema de informação centrado no paciente que permite, de forma automatizada, a integração de informação clínica relevante proveniente de diversos sistemas de informação já existentes. O ICU disponibiliza a todos os prossionais de saúde, através da intranet hospitalar, um acesso centralizado ao historial clínico dos pacientes, bem como aos seus relatórios mais recentes, à medida que são produzidos.

Figura 4.1: Arquitectura do ICU.

Este sistema de informação é composto por três módulos (VIZ, MAID e CRep) que são apresentados na Figura 4.1. Os relatórios clínicos são recolhidos a partir de um

4.1. Arquitectura do ICU

sistema Multi-Agente que assegura a integração de dados de sistemas de informação heterogéneos (Multi-Agent System for Integration of Data - MAID) dos vários Sis-temas de Informação Departamentais do hospital (por exemplo, DIS A DIS e B), e os armazena num repositório central (CRep), constituído de uma base de dados com referências para esses relatórios. Sempre que é recolhido um relatório é vericada, no CRep, a existência de uma versão anterior do mesmo. No caso de já existir, o relatório é desactualizado e substituído pelo novo, no caso de não existir, o relatório é armazenado no CRep como sendo o relatório actualizado. Um relatório desactu-alizado nunca é removido, porque um prossional de saúde pode ter tomado uma decisão clínica baseado nele, quando este ainda não estava desactualizado.

A integração da informação clínica no ICU é disponibilizada aos utilizadores por meio de um modelo VIZ: um website disponível na Intranet do Hospital. Após a autenti-cação, os prossionais de saúde podem ter acesso aos relatórios dos pacientes através de vários métodos de pesquisa. A pesquisa pode ser realizada pelo nome do paciente, número do processo clínico ou número de urgência. Os pacientes podem ser identi-cados em cada DIS por um ou mais números de identicação. Este tipo de pesquisa é capaz de encontrar todos os dados, independentemente do local onde sejam produzi-dos. Ao seleccionar um relatório especíco, o seu conteúdo é descarregado a partir do sistema central de arquivos do repositório para o browser [Cruz-Correia et al., 2005]. Como já foi referido, o ICU é um sistema de informação que está em produção no HSJ, o segundo maior hospital de Portugal. Actualmente, recolhe mais de 8000 relatórios por dia, distribuídos por 14 serviços distintos, tendo neste momento mais de 7 400 000 relatórios depositados no repositório central (Tabela 4.1). Os dados estatísticos referem-se ao período de 01 de Janeiro de 2004 a 30 de Junho de 2010. É importante salientar que a 1 de Janeiro de 2004 nem todos os serviços tinham os seus SI (Sistemas de Informação) integrados com o ICU, por isso, nesses serviços, a recolha dos relatórios só começou a ser realizada mais tarde.

Tabela 4.1: Relatórios recolhidos por departamento.

Departamentos Relatórios actualizados Relatórios desactualizados Total

Obstetrícia 36813 13157 49340 Pneumologia 9675 12058 21733 Centro de Mama 5116 8031 13147 Gastroenterologia 36942 3522 40464 Imuno-Alergologia 764 0 764 Imuno-Hemoterapia 534697 376662 911359 Patologia Clínica 1474819 4582813 6057632 Anatomia Patológica 191753 13037 204790 Cuidados Intensivos 13471 3356 16827 Nefrologia Pediátrica 1 1 2

Lab. Hematologia Clínica 2293 2289 4582 U. Endoscopia Ginecológica 3952 1513 5465 Cardiologia - Cir. Torácica 51054 20618 71672 Gastroenterologia Pediátrica 2391 789 3180

Total 263111 5037846 7400957

Como se pode vericar na Tabela 4.2, a utilização do ICU pelos utilizadores do HSJ teve uma forte subida nos primeiros anos de utilização (do ano de 2004 até ao ano de 2008). A partir desse ano, o crescimento é menor, mas mesmo assim, continua a vericar-se um aumento de utilização (exceptuando o numero de sessões, que diminuiram no ano de 2009 em relação a 2008). Se a tendência se mantiver, tudo aponta para que o ano de 2010 seja o ano com maior utilização. Actualmente, em média, são registadas mais de 1680 sessões por dia e visualizados mais de 1420 relatórios.

4.2. Web.Care

Tabela 4.2: Dados estatísticos de utilização do ICU.

Ano No _{utilizadores distintos N}o _{total de sessões N}o _{de relatórios visualizados}

2004 40 860 631 2005 748 71018 103942 2006 906 168530 221046 2007 1329 308198 350500 2008 1867 581957 439973 2009 1950 581821 460224 20101 _{1899 305766 258112}

4.2 Web.Care

O Web.Care é um SI que centraliza a gestão de utilizadores de vários SI. Não é prático para os utilizadores de vários SI a existência de mecanismos de autenticação isolados que leva a que a mesma pessoa tenha vários logins e passwords. Outro aspecto a ter em consideração, é a gestão dos pers dos utilizadores, que caria dispersa e que levaria os responsáveis pela manutenção dos SI a dispensar mais tempo, e a aumentar os seus custos para a sua gestão. Para ultrapassar este problemas, o SBIM desenvolveu uma plataforma designada Web.Care. Esta plataforma é um sistema informático que tem como principais objectivos implementar as políticas denidas para o controlo de acesso aos vários SI, gerir as contas de utilizadores, monitorizar os diversos recursos existentes em projectos distintos, controlar os acessos que são efectuados na plataforma e administrar as permissões de acessos.

4.2.1 Modelação de dados

O modelo de controlo de acesso implementado [Ferreira et al., 2005] é baseado no standard Role-Based Access Control (RBAC) [Ferraiolo et al., 2001] e divide-se em seis conceitos básicos: projectos, recursos, acções, níveis de acesso, utilizadores e grupo de utilizadores, e as várias relações entre eles, como pode ser visto na Figura 4.2. Cada projecto é composto por um conjunto de recursos. Cada recurso tem um conjunto de acções associadas para as quais existem vários níveis de acesso. Os utilizadores podem pertencer a um ou vários grupos. Estes grupos, por sua vez, estão associados a um dado projecto. Finalmente, cada grupo de utilizadores pode aceder aos vários recursos de um dado projecto.

Figura 4.2: Modelo Entidade-Relacionamento da plataforma de controlo de acessos Web.Care.

Cada projecto em produção encontra-se desenhado numa base de dados própria. Nessa base de dados, são denidos privilégios de leitura e de escrita para a plataforma de controlo de acesso. Desta forma, quando é efectuada a autenticação para um determinado projecto, as bases de dados comunicam entre si, e é obtido o perl do utilizador que se está a autenticar na plataforma Web.Care.

4.2. Web.Care

4.2.2 Tecnologias

Para as interfaces web, assim como os formulários que permitem aos administradores dos projectos congurar as várias componentes, foram produzidas páginas em HTML. Essa informação é processada, tratada e validada por scripts em PHP [Achour et al., 2010]. Toda a informação relativa ao modelo de controlo de acesso e da implementação dos vários projectos, é armazenada numa base de dados relacional, em Oracle. A informação relativa à identidade e autenticação dos utilizadores é armazenada no OID -Oracle Internet Directory [-Oracle, 2000], e a execução da identicação, autenticação e autorização (carregamento do perl do utilizador), assim como outras acções de lig-ação à base de dados, são efectuadas com um procedimento PL/SQL [Oracle, 2002].

4.2.3 Módulos

A implementação do Web.Care foi desenvolvida em três módulos: gestão dos recursos, gestão dos utilizadores e edição do modelo de controlo de acesso. Cada projecto tem várias páginas web que são denidas como um recurso do projecto em causa. Cada página tem associadas as seguintes funcionalidades: execução, listagem, escrita (formulários) e pesquisa. Estas funcionalidades designam-se por acções, são modulares e podem ser alteradas e adicionadas conforme as características de cada projecto. O módulo para a gestão dos recursos permite a visualização e a criação de projectos na plataforma Web.Care. Dentro de cada projecto podem ser criados os recursos e, dentro dos mesmos, podem existir novos recursos, não existindo limite para esta hierarquia(ver Figura 4.3).

Figura 4.3: Módulos de gestão recursos.

O módulo referente à gestão de utilizadores encontra-se dividido em 2 blocos: um para efectuar a gestão dos grupos de utilizadores e outro para gerir as contas de utilizadores. O bloco de gestão dos utilizadores também se encontra dividido em duas partes: uma parte permite registar os dados relacionados com a conta, tal como o login, nome e password; a outra permite assinalar os grupos a que eles pertencem (ver Figura 4.4).

4.2. Web.Care

Figura 4.4: Interface para registar e denir o perl do utilizador.

Por último, o módulo para administrar o controlo de acesso, foi desenvolvido a par-tir do modelo RBAC [Ferraiolo et al., 2001]. Esta ferramenta permite aos admin-istradores dos projectos associar os recursos e as permissões de acesso para cada grupo de utilizadores. Esta ferramenta é muito modular visto poder ser usada para todos os projectos que necessitem denir uma política de controlo de acesso (ver Figura 4.5). Inicialmente existem 5 acções (operações): execução, escrita, pesquisa, listagem e pesquisa avançada. Para cada acção existem 4 níveis de acesso: nada (sem permissões), sd (tem acesso apenas aos dados do seu departamento), sd+ (tem acesso apenas aos dados do seu departamento e mais alguma informação necessária) e tudo.

Figura 4.5: Interface para congurar o RBAC.

Existe também a possibilidade de inserir excepções para os acessos associados a deter-minados utilizadores. Isto signica que determinado utilizador herda as permissões do grupo ao qual pertence, mas podem existir outras regras a ele atribuídas que podem complementar ou mesmo substituir aquelas que ele entretanto herdou. Esta plataforma de controlo de acesso comtempla esta questão e permite gerir permissões especicas por utilizador, a determinados recursos.

4.2.4 Autenticação na plataforma

Para além do modelo já descrito anteriormente, e todas as ferramentas de gestão e desenvolvimento, a parte central desta plataforma de controlo de acesso é aquela onde o utilizador é autenticado e autorizado a aceder ao SI que necessita. Aquando da autenticação, o perl de cada utilizador, composto pelas permissões que ele herda dos grupos aos quais pertence, é carregado através de um procedimento PL/SQL, em Oracle. A identicação e validação das credenciais do utilizador é feita inicial-mente, com o mesmo procedimento, utilizando o protocolo LDAP [Wahl, 1997]. Mais especicamente, um utilizador que tenta entrar num determinado SI, disponibliza o seu login e a sua password. Um procedimento PL/SQL recebe como argumentos estas credenciais e efectua todos os passos necessários desde a identicação,

auten-4.2. Web.Care

ticação e autorização, do utilizador ao SI correspondente. As duas primeiras, como já descrito, são efectuadas usando o OID. O procedimento utiliza o protocolo LDAP para comunicar com a estrutura de directórios e verica se o utilizador inseriu ou não as credenciais correctas. Após conrmação de que as credenciais estão correctas, o procedimento prossegue em recolher o perl do utilizador, retornando informação relativa:

• aos projectos a que o utilizador pertence;

• aos recursos associados a cada projecto, com o nível de acesso de cada um; • o nome do utilizador autenticado;

• um valor de referência retornado pelo procedimento a indicar se a autenticação e autorização foram bem sucedidas.

Para aceder ao perl de um utilizador só é necessário chamar um procedimento em PL/SQL com 2 argumentos: o login e a password respectivamente. Este procedimento retorna 4 cursores com a seguinte informação:

• cursor1 - Retorna todos os identicadores dos projectos a que o utilizador per-tence

• cursor2 - Retorna todos os recursos por cada projecto e por nível de acesso cursor2[0] - id_recurso

cursor2[1] - id_projecto cursor2[2] - id_acesso

cursor2[3] - valor_do_acesso nada, sd, sd+,tudo) • cursor3 - Nome do utilizador

• cursor4 - Retorna -1 ou -2 caso a autenticação seja inválida ou o utilizador esteja desactivado.

No entanto, quando chegou o momento de colocar o Web.Care em produção no HSJ, constatamos que não seria possível da forma como foi desenhado porque a infra-estrutura usando o LDAP ainda não estava disponível. Para ultrapassar esse prob-lema, num primeiro passo tivemos de criar uma tabela na base de dados onde é guardado o login e a password encriptada pelo algoritmo de hash MD5. Num se-gundo passo, tivemos de criar um novo procedimento em PL/SQL, para substituir aquele que efectuava a autenticação a partir do LDAP para passar a autenticar numa tabela de utilizadores. Todavia, estas alterações não impedem a utilização do LDAP assim que o HSJ disponibilizar as infra-estruturas necessárias, bastando para isso desactivar este último procedimento que foi criado e colocar o primeiro em produção.

4.3 Implementação

Vários passos são necessários para que um utilizador possa fazer BTG. Após o acesso ao site do ICU na Intranet do HSJ, o prossional de saúde tem de introduzir um login e uma password para ter acesso aos relatórios de um utente. A plataforma Web.Care verica na base de dados se o par login / password está correcto. No caso da autenticação falhar, uma mensagem de rejeição é enviada a partir do Web.Care para o utilizador e o pedido termina aqui. No caso da autenticação ser válida, a plataforma Web.Care envia de volta o perl do utilizador com informação se o utilizador pode ou não efectuar BTG (pertence ou não ao grupo CCADIG) para aceder ao relatório. Depois da autenticação ser validada, o prossional de saúde pesquisa um utente no ICU, devolvendo o sistema uma lista de relatórios pertencente ao utente pesquisado. Nesta fase, o prossional de saúde selecciona o relatório que pretende visualizar. Após a selecção do relatório pretendido é vericado se este contém informação genética, se este for caso e se o utilizador pertence ao grupo CCADIG, é-lhe disponibilizado o relatório, senão é mostrada uma janela de aviso a informar que o relatório contém informação genética e que o prossional de saúde não pertence ao grupo CCADIG (nesta fase é guardada em base de dados a ocorrência de uma tentativa de acesso

4.3. Implementação

não autorizado ao relatório). Se o prossional de saúde não pretende ver o re-latório, é mostrada novamente a lista de relatórios anterioramente disponibilizados pela pesquisa de utente, senão deverá introduzir o motivo pelo qual pretende efec-tuar BTG e accionar a visualização do relatório. O processo é então despoletado e são guardados, em base de dados, dados sobre a visualização do relatório com o respectivo motivo introduzido. Por m, é disponabilizado o relatório ao prossional de saúde (ver Figura 4.6).

4.3.1 Alterações no Web.Care

No Web.Care foi preciso fazer duas alterações para poder implementar o BTG. Num primeiro passo, foi criado um novo grupo de utilizadores (11 médicos), que corre-spondem aos prossionais da saúde que estão autorizados a aceder aos relatórios dos pacientes que contêm informações genéticas, de acordo com o documento ocial da Comissão de Ética do HSJ. Num segundo passo, foi necessário associar esses uti-lizadores a esse grupo.

4.3.2 Alterações no ICU

A primeira alteração que foi efectuada no ICU foi a criação de um novo campo na tabela que armazena todos os dados referentes aos relatórios. Esse novo campo é do tipo booleano, tem o nome de genética, e indica se o relatório do paciente contém informação genética ou não. Esta informação é registada automaticamente a partir do momento em que o relatório do paciente é recolhido e armazenado na base de dados.

Quando um utilizador do ICU está a aceder a um relatório que contém informação genética, é necessário registar várias acções na base de dados para que mais tarde ele possa ser responsabilizado pelas mesmas. Existem três cenários possíveis:

1. O utilizador pretende aceder a um relatório com informação genética e após a janela de aviso ele fecha a janela ou clica no botão retroceder do browser. Neste caso são guardados na base de dados a data e a hora em que a janela de aviso apareceu, o identicador do relatório e o identicador da sessão (não houve BTG);

2. O utilizador pretende aceder a um relatório com informação genética e após a janela de aviso ele clica no botão que contém a seguinte mensagem não pretendo ver o relatório. Neste caso é guardada a mesma informação que é guardada no