SISU - Sistema de Informação de Sarcomas Uterinos

FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO SISU - Sistema de Informação de Sarcomas Uterinos Nuno Manuel Santos Queirós Mestrado Integrado em Engenharia Informática e Computação Orientador: Daniel Castro Silva (Professor Doutor) Co-Orientador: Pedro Henriques Abreu (Professor Doutor) Fevereiro de 2015 © Nuno Manuel Santos Queirós, 2015 SISU - Sistema de Informação de Sarcomas Uterinos Nuno Manuel Santos Queirós Mestrado Integrado em Engenharia Informática e Computação Aprovado em provas públicas pelo Júri: Presidente: Rosaldo Rossetti (Professor Doutor) Vogal Externo: Luis Paulo Reis (Professor Doutor) Orientador: Daniel Castro Silva (Professor Doutor) ____________________________________________________ 20 de Fevereiro de 2015 Resumo Atualmente, um dos problemas existentes nas instituições nacionais de oncologia é o armazenamento dos dados dos pacientes em formato papel, nomeadamente de pacientes mais antigos. Por consequência, a informação encontra-se muito dispersa e torna-se difícil de aceder, o que dificulta a prática diária dos clínicos e os avanços na investigação. Assim, é necessária uma aplicação que permita não só uma centralização da informação como também permita ao clínico extrair informações valiosas que possam ajudar no tratamento dos pacientes ou na realização de estudos clínicos. Este documento descreve o conceito, arquitetura e funcionalidades de um sistema designado por SISU - Sistema de Informação de Sarcomas Uterinos. Com o SISU, pretende-se dar o primeiro passo para a criação de um sistema de informação oncológico nacional que auxilie o médico na sua prática clínica diária. O SISU é um projeto piloto, desenvolvido em parceria com clínicos do Instituto Português de Oncologia do Porto, que tem como caso de estudo os sarcomas uterinos e permite aos clínicos gerir a informação dos seus pacientes, efetuar consultas personalizadas de dados e partilhar informações com outros clínicos. O SISU foi desenvolvido de forma modular, baseado num modelo genérico que garante ao sistema elevados níveis de flexibilidade e configurabilidade, permitindo assim a expansão do sistema a outras patologias de uma forma rápida e fácil. Foram efetuados testes de usabilidade, com uma amostra de quinze participantes, onde se pode concluir que o sistema desenvolvido se apresenta dentro dos padrões comuns de usabilidade. Abstract Currently, one of the problems in national oncology institutions is the storage of patient data in paper format, especially earlier patients. Therefore, the information is too scattered and it becomes difficult to access it, which complicates the clinician's daily practice and advances in research. Thus, an application it is required that allows not only a centralization of the information but also the clinician to extract valuable information that may help in the treatment of patients or in clinical studies. This paper describes the concept, architecture and features of a system called USIS - Uterine Sarcoma Information System. With USIS, it is intended to take the first step to create a national oncology information system that assists clinicians in their daily clinical practice. USIS is a pilot project, developed in partnership with clinicians of the Portuguese Institute of Oncology of Porto, with uterine sarcomas as the case study and it allows the clinician to manage the information of his patients, to perform customized data queries and to share information with other clinicians. USIS was developed in modules, based on a generic model that provides the system with high levels of flexibility and configurability, thereby allowing to quick and easily expand the system to others pathologies. Usability tests were performed, with a sample of fifteen, in which it can be concluded that the developed system is within the common usability standards. Agradecimentos Em primeiro lugar, quero agradecer aos meus orientadores, Professor Daniel Castro Silva e Professor Pedro Abreu, por me terem selecionado para o projeto e por se mostrarem sempre disponíveis, ao longo de toda a dissertação, para esclarecer qualquer dúvida e ajudar a ultrapassar as dificuldades que surgiam. Em segundo, agradecer à minha família, em especial aos pais e irmão, por terem estado sempre ao meu lado, nomeadamente ao longo destes anos de curso, nos bons e nos maus momentos e por me encorajarem a enfrentar todos os obstáculos que foram surgindo. Por último, mas não menos importante, quero agradecer aos meus colegas de curso, em especial aos verdadeiros amigos, com os quais passei bons e inesquecíveis momentos ao longo destes últimos anos. A todas estas pessoas citadas o meu sincero Obrigado! Nuno Queirós xvi Figura 22. Modelo Conceptual de Dados para o Módulo de Pacientes. 40 Figura 23. Modelo Conceptual de Dados para o Módulo de Comunicação, secção do Fórum. 41 Figura 24. Modelo Conceptual de Dados para o Módulo de Comunicação, secção das Mensagens. 41 Figura 25. Modelo Conceptual de Dados para o Módulo de Pesquisas Personalizadas. 43 Figura 26. Escalamento vertical da camada de base de dados. 45 Figura 27. Escalamento horizontal na camada de base de dados. 45 Figura 28. Página inicial do SISU. 51 Figura 29. Página de Perfil de um Clínico. 52 Figura 30. Lista dos clínicos registados no sistema a que o administrador tem acesso. 52 Figura 31. Email recebido pelo clínico após registo no sistema por parte do administrador. 53 Figura 32. Página de Serviços Gerais. 54 Figura 33. Página de Unidades de Saúde. 54 Figura 34. Página de Especialidades. 55 Figura 35. Página de uma Unidade de Saúde. 55 Figura 36. Página de um Serviço dentro de uma Unidade de Saúde. 56 Figura 37. Lista de variáveis clínicas existente no sistema. 57 Figura 38. Criação de uma variável clínica. 57 Figura 39. Criação de um trigger. 59 Figura 40. Página de um Grupo de Variáveis do sistema. 60 Figura 41. Lista de grupos de variáveis existentes no sistema. 60 Figura 42. Página de uma Vista do sistema. 61 Figura 43. Áreas clínicas e respetivos Tipos de Dados Clínicos associados. 62 Figura 44. Associação de Vistas com Especialidades e Tipos de Dados Clínicos 62 Figura 45. Lista de pacientes do clínico. 63 Figura 46. Ficha clínica de um paciente, onde é possível visualizar os valores mais recentes de alguns dos dados mais importantes. 64 Figura 47. Relatórios clínicos do tipo Quimioterapia da área de Tratamentos. 65 Figura 48. Visualização de um relatório clínico (do tipo Quimioterapia da àrea de Tratamentos) dividido em várias Vistas. 66 Figura 49. Visualização de uma Vista do relatório onde o clínico tem permissão para editar os dados clínicos. 67 Figura 50. Página inicial do módulo de Mensagens. 68 Figura 51. Caixa de entrada do clínico, com uma mensagem aberta. 68 Figura 52. Grupos de Utilizadores que o clínico pode escolher como destinatários. 69 Figura 53. Página inicial do fórum do SISU. 71 Figura 54. Fórum de uma Unidade de Saúde. 72 xvii Figura 55. Tópico do Fórum do SISU. 72 Figura 56. Primeira fase da realização de uma pesquisa personalizada, onde o clínico seleciona as variáveis que pretende restringir. 73 Figura 57. Segunda fase da realização de uma pesquisa personalizada, onde o clínico indica as restrições que pretende aplicar. 74 Figura 58. Modelo conceptual relativo à parte das váriáveis clínicas (à esquerda) e interface respeitando esse mesmo modelo (à direita). 75 Figura 59. Template de um relatório clínico da norma OpenEHR. 76 Figura 60. Exemplo de relatório clínico do SISU. 77 Figura 61. Modelo Conceptual definido tendo já em conta o alargamento a outras patologias. 78 Figura 62. Modelo Conceptual demonstrando que a Patologia tem influência na estrutura dos relatórios clínicos. 78 xix Lista de Tabelas Tabela 1. Comparação dos vários sistemas existentes com o sistema pretendido. 21 Tabela 2. Comparação entre base de dados relacional e não relacional (noSQL). 46 Tabela 3. Distribuição dos resultados obtidos no questionário efetuado. 82 xxi Abreviaturas e Símbolos ACID ADL ANSI AQL BASE CBCR CDA CDSS CRUD CSS EHR EMR HL7 HTML HTTPS IDMR IPO MVC NPI PHP PLANN-ARD RIM SEER SISU SQL SUS TNM XML Atomicity, Consistency, Isolation and Durability Archetype Definition Language American National Standards Institute Archtype Query Language Basically Available, Soft State, Eventual Consistency Central Breast Cancer Registry Clinical Document Architecture Clinical Decision Support System Create, Read, Update and Delete Cascading Style Sheets Electronic Health Record Electronic Medical Record Health Level Seven Hypertext Markup Language Hypertext Transfer Protocol Secure Intelligent Digital Medical Record Instituto Português de Oncologia Model-View-Controller Nottingham Prognostic Index PHP: Hypertext Preprocessor Partial Logistic Artificial Neural Network with Automatic Relevance Determination Reference Information Model Surveillance, Epidemiology and End Results Sistema de Informação de Sarcomas Uterinos Structured Query Language System Usability Scale Tumor, Nodes and Metastasis Extensible Markup Language xxii 1 Capítulo 1 Introdução Neste capítulo será apresentado o contexto em que esta dissertação se realiza, sendo descrito o problema em questão e que se pretende resolver ou pelo menos minimizar. Serão também descritos a motivação e os objetivos da dissertação. O capítulo terminará com uma breve descrição da estrutura do documento. 1.1 Contexto O organismo humano é constituído por milhões de células, células estas que formam os tecidos e estes por sua vez formam os orgãos. Num processo normal, as células crescem e dividem-se, de forma periódica e regular, para dar origem a novas células e também envelhecem e acabam por morrer. Tudo num equilíbrio saudável para manter a integridade e o correto funcionamento de todo o organismo [POP13]. Por diversas razões, alterações ao nível dos genes podem ocorrer, transformando-se em oncogenes, originando comandos errados que fazem com que se formem novas células a um ritmo muito elevado, sem que as mais velhas morram, originando um excesso de células. Este excesso irá formar um tumor, como demonstrado na Figura 1 [POP13]. Introdução 2 A investigação constante, numa área de intervenção tão importante como o cancro é, inquestionavelmente, necessária. As tecnologias de informação, mais especificamente os sistemas de informação, poderão contribuir de forma positiva para o aumento da qualidade desta investigação, disponibilizando aos profissionais de saúde uma série de ferramentas que os auxiliem na sua prática diária, tendo sempre em vista a melhoria dos tratamentos dos pacientes. 1.2 Problema Foi possível perceber, junto de clínicos, que atualmente nos centros de tratamento oncológico em Portugal, principalmente nos Institutos Portugueses de Oncologia, grande parte dos registos e arquivos dos pacientes, nomeadamente de pacientes antigos, são guardados em formato papel. Este tipo de armazenamento faz com que a informação se encontre muito dispersa criando uma grande dificuldade no seu acesso por parte dos clínicos, envolvidos nos processos de tratamento e acompanhamento dos pacientes. Torna-se difícil e moroso, por exemplo, consultar todo historial clínico de um paciente, através das várias áreas de tratamento que atravessou. Torna-se também difícil para os clínicos, fazerem uma análise global dos vários pacientes acompanhados ao longo do tempo ou determinar, quais os pacientes que obedecem a determinados parâmetros e daí retirar ilações ou efetuar estudos clínicos. Outra dificuldade encontrada é a troca de informação entre os clínicos, problema agravado quando se tratam de clínicos de unidades de saúde diferentes. Com a dificuldade no acesso à informação e todos os problemas associados, os próprios tratamentos tornam-se mais morosos e surgem poucos avanços na investigação. Os poucos Figura 1. Divisão celular desregulada que origina cancro. Introdução 3 avanços surgem de forma isolada, sem grande continuidade, pelo que não se nota uma melhoria clara e objetiva. Muitos estudos clínicos são assentes em bases de dados construídas para o efeito pelo próprio clínico envolvido. No entanto, muitas vezes essa base de dados fica perdida e não é reaproveitada num possível futuro estudo, perdendo-se assim informação valiosa. 1.3 Motivação e Objectivos A motivação e o objetivo desta dissertação passam por tentar resolver, ou pelo menos minimizar, o problema descrito na secção anterior. Com esta dissertação, pretende-se dar o primeiro passo, através de um projeto piloto, cujo caso de estudo serão os sarcomas uterinos, para a criação de um sistema de informação oncológico nacional, para auxiliar o clínico na sua prática clínica diária. O objetivo principal é assim a especificação e implementação de um sistema que permita centralizar um conjunto alargado de casos de sarcomas uterinos com vista a extrair, de forma fácil e rápida, informações valiosas que possam ajudar o clínico no tratamento dos pacientes e/ou na realização de estudos clínicos. O sistema que se propõe a especificar e desenvolver nesta dissertação deverá permitir aos clínicos funcionalidades básicas, como a inserção de novos pacientes e a alteração e consulta dos seus dados de forma rápida e intuitiva. Deverá ser um sistema dinâmico e flexível, onde os clínicos possam definir as variáveis e a estrutura dos relatórios específicos de cada área clínica. O sistema deverá assim funcionar sobre um modelo genérico, altamente configurável e adaptável a diversas áreas. Deverá também ser um sistema que apresente um nível alto de escalabilidade e expansibilidade, de forma a permitir a introdução de novas unidades de saúde, novas especialidades, novos serviços e novas patologias. Esta flexibilidade deverá ser um dos principais aspetos inovadores do sistema. Espera-se também como elemento inovador, que o sistema permita ao clínico efetuar consultas personalizadas dos dados dos pacientes, no sentido de filtrar a informação e obter diversas informações. O clínico terá assim um elemento de auxílio na tomada de decisão, podendo tirar ilações com base em registos, para a construção dos quais contribuiu de forma ativa, potenciando assim a realização de estudos clínicos. Pretende-se também que o sistema funcione como uma plataforma de comunicação, permitindo aos clínicos partilharem informações e experiências, estimulando a discussão e potenciando o seu conhecimento. O sistema deverá permitir que os clínicos debatam temas e casos clínicos, funcionando também como ferramenta de troca, armazenamento e aprendizagem de conhecimentos clínicos. Fora do âmbito desta dissertação, mas fazendo parte do sistema que se está a iniciar, deverá existir um módulo de “investigação e descoberta”: com base nos dados clínicos contidos no sistema e através de técnicas de data mining o sistema deverá permitir ao clínico o acesso a diversas informações, como por exemplo, prognósticos através de curvas de sobrevivência ou estatísticas sobre os efeitos dos tratamentos. Revisão Bibliográfica 10 Modelação em dois níveis O objetivo da norma OpenEHR é alcançar a interoperabilidade semântica sobre toda a área de saúde. Para que isso seja possível, é necessário, um modelo genérico de informação de saúde, capaz de armazenar novos e diferentes tipos de dados sem necessitar de grandes mudanças no modelo de dados. A desvantagem de um modelo deste tipo é que não há controlo sobre a informação que é armazenada, levando à baixa qualidade dos dados. Este problema é resolvido através de uma abordagem de modelação em dois níveis, criando um segundo nível para retringir a informação. A estrutura da informação é restringida pelo modelo do archetype. Desta forma o domínio específico do conhecimento é independente da implementação, o que permite ter diferentes vistas para o mesmo conhecimento. Obtém-se assim um modelo genérico de registo de saúde capaz de guardar qualquer tipo de dados clínicos, o que significa grande melhoramento na interoperabilidade e ao mesmo tempo torna possível controlar a estrutura da informação usando archtypes [Vel11]. Archetypes Um archtype representa um conceito clínico. É usado para restringir instâncias do modelo de informação OpenEHR, definindo uma estrutura válida, tipos de dados e valores. Um registo de saúde que foi modelado sobre um archtetype vai ter o mesmo significado, independentemente de onde aparece, portanto pode ser partilhado por múltiplos sistemas de saúde. Tal como demonstrado na Figura 2, os archtetypes são definidos por especialistas do domínio (neste caso, médicos e outros profissionais de saúde). Desta forma, o utilizador que cria e insere a informação não necessita de saber como a informação deve ser estruturada, uma vez que vai ser validada pelas regras definidas pelos especialistas. Figura 2. Modelação em dois níveis da norma OpenEHR. Revisão Bibliográfica 11 Um archetype é constituído por três partes: dados descritivos, que consistem numa identificação, descrição do conceito clínico que é modelado e metadados (autor, versão, etc); regras de restrição que são a parte principal do archtype, pois especificam a estrutura, cardinalidade e conteúdo para uma instância válida; e definições de ontologia, que controlam o vocabulário que pode ser usado para especificar uma instância. Os archetypes são definidos usando a Archetype Definition Language (ADL), que é uma linguagem formal que permite definir os archtypes com restrições. Para pesquisar informação num sistema definido por archtypes foi definida a Archtype Query Language (AQL) que permite aceder a nós, sendo idêntica a uma pesquisa num documento XML usando XML Path Language (XPath) [Vel11]. 2.4 Sistemas Oncológicos Existentes Nos dias de hoje, existem vários sistemas na área da saúde que se focam em tarefas ou campos específicos. Alguns sistemas foram desenvolvidos para responder às necessidades de qualquer ramo da saúde sendo, portanto, sistemas genéricos que também podem ser adaptados á prática oncológica. No entanto, alguns sistemas foram desenvolvidos especificamente para o domínio da oncologia [WSM+08]. Foi efetuada uma pesquisa no sentido de averiguar algumas das soluções, de auxílio aos clínicos, já existentes no campo da oncologia. Esta pesquisa envolveu uma análise da informação disponível sobre os sistemas bem como, em alguns casos, uma experimentação das suas funcionalidades de forma a registar quais as características e limitações. Realizada a pesquisa, é de salientar a existência de distintos grupos de sistemas de auxílio aos clínicos de oncologia, na sua prática diária. Um dos grupos identificados debruça-se no auxílio à realizaçao de prognósticos. Funcionam como calculadoras, onde o clínico (ou, em alguns casos, até mesmo o paciente) insere as características do paciente, maioritariamente características específicas da patologia identificada, e onde o sistema devolve como resultado um prognóstico como, por exemplo, a probabilidade de sobrevivência nos anos seguintes com ou sem tratamentos aplicados. Da pesquisa efetuada, deste grupo de sistemas, destacam-se os seguintes: CancerMath.net O objetivo do CancerMath.net é fornecer calculadoras aos profissionais médicos, baseadas na web, para prever o resultado clínico (prognóstico), estimando a probabilidade de sobrevivência e o impacto das várias opções de tratamento. O CancerMath.net permite introduzir as características do paciente e da sua patologia (idade, sexo, tamanho tumor e outras variáveis mais específicas de cada tipo de cancro) e calcula a probabilidade de sobrevivência nos anos seguintes. O sistema calcula também a redução da esperança de vida (em anos ou Revisão Bibliográfica 12 percentagem) que a patologia provoca no paciente. O CancerMath.net suporta vários tipos de cancro: mama, pele, renal, cólon e cabeça e pescoço (otorrino). Além da probabilidade de sobrevivência e redução da esperança de vida, para os cancros da mama e pele, o sistema calcula também a probabilidade de existirem nódulos linfáticos positivos (com células cancerígenas) que são um indicador importante na probabilidade de aparecimento de um novo cancro. No caso do cancro da mama, o sistema permite também calcular a probabilidade de sobrevivência no caso de serem aplicadas diversas terapias, indicando também o benefício dessa mesma terapia (tempo de vida ganho). Tal como demonstrado na Figura 3, todas estas probabilidades de sobrevivência são retornadas ao utilizador sob a forma de gráficos (sendo possível visualizar vários tipos de gráficos) e são acompanhadas de uma pequena descrição, onde são indicados também os restantes resultados calculados. Não é necessário registo, pelo que o sistema está disponível tanto a clínicos como a pacientes. As previsões matemáticas disponibilizadas pelo CancerMath.net foram confirmadas com dados de pacientes diagnosticados com cancro, entre 1987 e 2007, provenientes do programa Surveillance, Epidemiology, and End Results (SEER), nos Estados Unidos. Foram também usados dados de pacientes de alguns hospitais [CM13]. Figura 3. Funcionamento do CancerMath.net no caso de uma paciente com cancro da mama. Revisão Bibliográfica 13 Adjuvant! Online O sistema Adjuvant! Online permite aos profissionais de saúde e pacientes com cancro, ainda em estado precoce, discutir os riscos e benefícios de obter terapia adicional (geralmente quimioterapia, terapia hormonal ou ambos) após ter sido efetuada cirurgia [AO13]. O conceito por detrás do Adjuvante! On-line é que a qualidade da tomada de decisão sobre a terapia adjuvante (após terapia primária ou inicial) é reforçada nas consultas onde os médicos podem comunicar aos pacientes o benefício dos vários tipos de terapia. O objetivo é ajudar os profissionais de saúde a fazer estimativas sobre o risco de resultado negativo (morte ou reincidência do cancro) sem terapia adjuvante, estimativas da redução possível destes resultados negativos através do uso de terapias e os riscos de efeitos secundários. As estimativas baseiamse nas informações inseridas sobre o paciente e a sua patologia (por exemplo, idade do paciente, tamanho do tumor e grau histológico). Como demonstrado na Figura 4, os resultados destas estimativas são retornados sob a forma de indicadores horizontais simples, acompanhados de uma legenda descritiva, sendo possível imprimir os resultados. O sistema está disponível para vários tipos de cancro. O Adjuvant! Online possui também uma componente de investigação, onde é possível ao profissional de saúde aceder a informações sobre a patologia em causa e evidências clínicas que auxiliam a decisão. O sistema destina-se apenas a ser usado por profissionais de saúde, pelo que é requerido registo. O Adjuvant! Online baseia-se em informações da base de dados SEER, dos Estados Unidos, em visões gerais e resultados de ensaios clínicos individuais e na literatura em geral [GD09]. Figura 4. Estimativas calculadas pelo Adjuvant! Online para um caso de cancro do pulmão. Revisão Bibliográfica 14 Outro grupo de sistemas identificados aquando a realização da pesquisa caracteriza-se por agregarem funcionalidades dos sistemas de apoio à decisão clínica e funcionalidades dos sistemas de registos médicos e de saúde eletrónicos. O resultado são sistemas bastante completos, com uma vasta gama de funcionalidades que auxiliam os clínicos no tratamento dos pacientes, desde o diagnóstico até ao acompanhamento pós-tratamento. Da pesquisa efetuada, deste grupo de sistemas, destacam-se os seguintes: e-Prolipsis e-Prolipsis é um projeto que estava, à data do artigo publicado, em desenvolvimento na Grécia, que consiste numa plataforma web de estimação de risco de cancro da mama e num registo central de cancro da mama (Central Breast Cancer Registry - CBCR), que juntos permitem aos clínicos e aos pacientes ter acesso a diagnósticos e estimação do risco, quer por processos computacionais quer por estatísticas que indicam a tendência. O sistema ajuda o clínico na avaliação final da existência ou não de um cancro da mama. Está disponível através de um portal web com diferentes níveis de acesso para clínicos e pacientes [DLA+12]. O clínico registado na plataforma tem acesso a uma aplicação, Intelligent Digital Medical Record (IDMR), que lhe permite armazenar e gerir todos os dados dos pacientes. Esta aplicação permite também inserir exames (mamografias) e disponibiliza ao clínico ferramentas para os analisar e identificar regiões de interesse onde existam suspeitas da existência de cancro. Após esta análise ser feita e as regiões serem assinaladas a aplicação permite ao clínico submeter a mamografia no Hippocrates-mst, um sistema de diagnóstico auxiliado por computador que, através do processamento da imagem e baseado em modelos de risco bem definidos, determina e retorna ao clínico o número e tipo de microcalcificações (um indicador da possível existência de cancro da mama) bem como o risco de cancro associado [DLA+12]. A Figura 5 demonstra a interação da aplicação do clínico com o sistema de diagnóstico num processo de diagnóstico da patologia. O clínico pode guardar os resultados obtidos na ficha do paciente. O registo central de cancro da mama tem como objetivo principal reunir todos os dados relevantes contidos nos registos feitos por cada clínico (com consentimento dos pacientes e remoção de qualquer informação confidencial como a identificação), dados estes que são utilizados para análise estatística para determinar os parâmetros de risco e registar e guardar eventos similares a eventuais futuros casos [DLA+12]. Revisão Bibliográfica 15 BCSurvival O sistema BCSurvival, foi um sistema desenvolvido no âmbito de uma dissertação de mestrado e é um sistema web de apoio à decisão para médicos oncologistas e pacientes de cancro da mama. Este sistema tem em consideração diversas características individuais de um paciente com cancro de mama permitindo aos clínicos identificar o nível de risco e as regras associadas a esse nível assim como o intervalo de confianca. O sistema disponibiliza curvas de sobrevivência (curvas Kaplan-Meier) dos vários níveis de risco, identificando a curva onde o paciente se enquadra. Permite também ao médico guardar a informação referente ao prognóstico dos seus pacientes. No sistema estão incorporados três diferentes modelos de prognóstico: o Nottingham Prognostic Index (NPI), a Regressão de Cox e o Partial Logistic Artificial Neural Network with Automatic Relevance Determination (PLANN-ARD). Como funcionalidades principais, como demonstrado na Figura 6, o sistema permite: gerir pacientes, através da inserção e remoção de pacientes, assim como a edição dos seus dados; permite efetuar prognósticos, com os diferentes modelos, através da inserção das características do paciente e da sua patologia (idade, tamanho do tumor, grau histológico, nódulos envolvidos, etc). Como resultado é identificado o grupo de risco em que o paciente se encontra e é devolvida a probabilidade de sobrevivência a 5 anos (bem como o grau de confiança dessa estimativa) e quais os tratamentos mais aconselhados, como a Figura 7 demonstra. Figura 5. Processo de diagnóstico comum em comparação com o processo de diagnóstico auxiliado no e-Prolipsis. Revisão Bibliográfica 16 Os modelos de prognóstico utilizados neste sistema têm em consideração um conjunto de dados composto por 931 pacientes do sexo feminino, obtidos pelo Christie Hospital em Wilmslow (Manchester) no Reino Unido, no período entre 1990 e 1994. Estes dados dizem respeito a pacientes com cancro da mama em situação pós-operatória, tendo sido utilizado o método de filtragem TNM (Tumor, Nodes and Metastasis), que considera o tamanho do tumor Figura 6. Gestão de Pacientes (à esquerda) e Identificação do grupo de risco de um paciente (à direita) no BCSurvival. Figura 7. Indicação dos melhores tratamentos a aplicar para o paciente com determinadas características. Revisão Bibliográfica 17 menor que 5cm, estado do nódulo menor que 2 e onde não podem existir registos com sintomas clínicos de metástases [Alv10]. Oncological Information System O Oncological Information System foi um sistema implementado no Medical Oncology Department no Hospital Universitario Virgen de la Victoria em Málaga em 2009. É um sistema web intuitivo e de fácil uso que sistematiza e unifica o trabalho diário da unidade oncológica do hospital, facilitando o trabalho dos clínicos. O sistema permite a gestão dos pacientes e dos seus dados e gestão das consultas, sendo possível gerir e coordenar todos os processos associados à assistência do paciente e reunir notas clínicas dos vários tipos de consulta. Este módulo reúne informações como data do diagnóstico, tipo de neoplasia, localização, estágio, tipo e intenção de tratamento e a condição no último follow-up. Permite também a gestão dos tratamentos ambulatórios, sendo possível gerir as actividades diárias que ocorrem na unidade ambulatorial de tratamentos. O sistema inclui também um módulo de pesquisa e investigação que permite acompanhar e gerir informações de pacientes incluídos em ensaios clínicos. Oferece fácil acesso a todas as informações sobre cada ensaio, tais como horários de avaliação, critérios de elegibilidade, tratamentos, critérios de modificação da dose ou listas de medicamentos concomitantes proibidos. Os dados guardados podem também identificar os pacientes para futuros ensaios clínicos. Possui também um módulo de aconselhamento genético que contém procedimentos adequados para a recolha de informação a respeito de árvores genealógicas e tipos específicos de consultas médicas de genética. O sistema disponibiliza também estatísticas, sendo permitido ao clínico realizar análises estatísticas em tempo real a partir das informações contidas na base de dados. Apresenta ainda um módulo de administração que permite gerir os utilizadores (operações CRUD), controlo de erros e a criação de backups [URS+13]. Oncology Lifeline O Oncology Lifeline é uma framework que sintetiza vários dados do paciente, dados de radiologia, cirurgia, patologia, oncologia médica e informação genética, num paradigma de linha de tempo e apresenta elementos de apoio à decisão clínica. O sistema recolhe dados dos vários sistemas das áreas da oncologia e disponibiliza aos clínicos de forma intuitiva as várias ocorrências (em cada área), associadas a um paciente, ao longo do tempo. Com este sistema é assim possível observar todo o percurso clínico do paciente. O sistema emite também alertas visuais sempre que deteta alguma anomalia nos dados recolhidos. Na Figura 8, um dos eventos na área da cirurgia encontra-se rodeado a vermelho uma vez que foi detetado nesse evento um cancro invasivo. O Oncology Lifeline permite também criar documentos com base nos dados recolhidos. Este sistema apresenta-se como uma ferramente de concatenação e visualização dos dados clínicos, das várias especialidades, dos pacientes [DGH10]. Revisão Bibliográfica 18 Caisis O Caisis é um sistema de gestão de dados de clínicos que integra funcionalidades de investigação e cuidados de saúde. Permite a gestão dos pacientes e de todos os seus dados clínicos tais como exames de diagnóstico, medicação pescrita e tratamentos efetuados, como mostra a Figura 9. O sistema apresenta uma série de templates de formulários personalizados, para vários tipos de tumor (próstata, bexiga, rim, mama, etc), tal como demonstrado na Figura 10, no sentido de facilitar a gestão dos dados. Desta forma o clínico só necessitará de gerir dados específicos do tumor em causa, diminuindo assim a quantidade de informação sem utilidade. O sistema possui também um módulo de investigação onde é possível criar e gerir ensaios clínicos. Disponibiliza ainda estatísticas sob a forma de gráficos intuitivos [Cai13]. Figura 8. Exemplo de vários eventos de um paciente no Oncology Lifeline, com um alerta num evento da área de Cirurgia. Revisão Bibliográfica 19 Figura 9. Dados clínicos de um paciente no sistema Caisis. Figura 10. Templates personalizados para diversas patologias. Especificação do Sistema 26 Clínico 1. Como clínico, eu quero terminar a minha sessão para finalizar com segurança as minhas funções. 2. Como clínico, eu quero gerir o meu perfil para manter os meus dados sempre atualizados. 3. Como clínico, eu quero gerir os meus pacientes, para manter a minha lista sempre atualizada. 4. Como clínico, eu quero efetuar pesquisas personalizadas (queries) aos dados clínicos dos pacientes contidos no sistema, para tirar ilações e realizar estudos clínicos. 5. Como clínico, eu quero gerir as minhas pesquisas personalizadas para poder guardar ou partilhar com outros clínicos. 6. Como clínico, eu quero trocar mensagens e informações e criar discussões com clínicos para partilhar ideias sobre os pacientes e patologias associadas. 7. Como clínico, eu quero investigar e explorar com maior detalhe os dados contidos no sistema para me ajudar na tomada das decisões clínicas. Clínico Especializado 1. Como clínico especializado, eu quero gerir os dados clínicos dos meus pacientes, que são do âmbito da(s) minha(s) especialidade(s), para manter a informação sempre atualizada. Gestor de Unidade 2. Como gestor de unidade, eu quero gerir os serviços da minha unidade, para mantêla sempre atualizada. 3. Como gestor de unidade, eu quero gerir os clínicos dos serviços da minha unidade, para mantê-la sempre atualizada. 4. Como gestor de unidade, eu quero nomear os diretores de serviços, para lhes atribuir responsabilidades e dar permissões. Diretor de Serviço 1. Como diretor de serviço, eu quero gerir os clínicos do meu serviço, para o manter sempre atualizado. Administrador 1. Como administrador, eu quero gerir as entidades que fazem parte do sistema, para manter o sistema sempre atualizado. 2. Como administrador, eu quero gerir os utilizadores contidos no sistema para manter a informação sempre atualizada. Especificação do Sistema 27 3. Como administrador, eu quero gerir os templates em uso no sistema, de forma a manter os dados clínicos sempre corretos e atualizados. 4. Como administrador, eu quero gerir o fórum, de forma a garantir o seu bom funcionamento. 3.2.3 Requisitos Funcionais No sentido de especificar com maior detalhe as funcionalidades que o SISU deverá incluir, recorrer-se-á agora a uma abordagem com casos de uso. Serão demonstrados os respetivos diagramas e será apresentada uma breve descrição das funcionalidades. Para melhor percepção será feita uma divisão em módulos de funcionalidades. Para identificação da importância e prioridade dos vários módulos de funcionalidades, será utilizada a escala de MoSCoW (MUST, SHOULD, COULD, WON’T), onde MUST indica o nível mais alto de prioridade e WON’T o nível mais baixo. Módulo de Gestão de Clínicos Figura 12. Diagrama de Casos de Uso para o Módulo de Gestão de Clínicos. Especificação do Sistema 28 O módulo de Gestão de Clínicos, demonstrado na Figura 12, inclui todos os requisitos que permitirão a gestão dos utilizadores do sistema (clínicos) e da sua informação, desde o seu registo, à autenticação e alocação em serviços de unidades de saúde. Deverá ser permitido a qualquer clínico gerir a informação do seu perfil pessoal. O diretor de serviço deverá ter permissões de alocar clínicos no serviço pelo qual é responsável, da mesma forma que o gestor da unidade de saúde deverá ter permissões para alocar clínicos nos vários serviços da sua unidade. O gestor da unidade deverá ainda poder nomear os diretores dos serviços da sua unidade. Ao administrador, como responsável máximo do sistema, deverá ser-lhe permitido, além de alocar clínicos em qualquer serviço de qualquer unidade, nomear diretores de serviço e gestores de unidade, registar novos clínicos no sistema bem como visualizar e gerir o perfil de qualquer clínico e modificar as suas permissões de administração (isto é, poderá nomear qualquer outro clínico como administrador). Este módulo de funcionalidades, sendo o módulo que permite a gestão dos clínicos de todo o sistema, apresenta nível de prioridade MUST. Módulo de Gestão de Entidades Figura 13. Diagrama de Casos de Uso para o Módulo de Gestão de Entidades. Especificação do Sistema 29 O módulo de Gestão de Entidades, demonstrado na Figura 13, inclui os requisitos que permitirão adicionar e gerir as várias entidades clínicas do sistema: Unidades de Saúde, Serviços Gerais e Especialidades. Deverá ser permitido ao gestor da unidade adicionar/remover serviços à sua unidade de saúde. Ao administrador, além de permitido adicionar serviços a qualquer unidade, deverá ainda ser permitido adicionar/remover Unidades de Saúde, Especialidades e Serviços Gerais ao sistema. Os Serviços Gerais, ao contrário dos serviços das unidades, são serviços transversais a todas as unidades que servem para identificar a equivalência entre serviços idênticos, com nomes distintos, de diferentes unidades de saúde. Este módulo de funcionalidades servirá como base de todo o sistema e será um módulo fundamental para garantir um bom nível de escalabilidade e expansibilidade, pelo que apresenta nível de prioridade MUST. Módulo de Gestão de Templates Figura 14. Diagrama de Casos de Uso para o Módulo de Gestão de Templates. Especificação do Sistema 30 O módulo de Gestão de Templates, demonstrado na Figura 14, inclui os requisitos que permitirão ao administrador definir e gerir os templates dos relatórios clínicos das várias áreas de tratamento. O administrador deverá conseguir criar vistas, grupos e variáveis e fazer associações entre si, isto é, colocar variáveis dentro de grupos, grupos dentro de grupos e grupos dentro de vistas. Um relatório clínico será um conjunto de vistas. Para definir que vistas é que um relatório de um determinado tipo (quimioterapia, radioterapia, etc) deverá conter, assim como quais as especialidades que possuem permissão para editar os dados clínicos duma determinada vista (isto é, definir as vistas que são do âmbito das especialidades), o administrador deverá ter a possibilidade de fazer associações entre as especialidades, vistas e tipo do relatório. Por último, o clínico deverá também ter a possibilidade de criar triggers, isto é, determinar o efeito que um valor (ou mudança do mesmo) de uma variável clínica terá numa outra variável do relatório clínico. Este é um dos principais módulos de funcionalidades e um dos mais inovadores. Deverá conferir ao sistema um alto nível de flexibilidade e configurabilidade, pelo que possui um nível de prioridade MUST. Módulo de Gestão de Pacientes Figura 15. Diagrama de Casos de Uso para o Módulo de Gestão de Pacientes. Especificação do Sistema 31 O módulo de Gestão de Pacientes, demonstrado na Figura 15, inclui todos os requisitos que permitirão a qualquer clínico gerir os seus pacientes, tais como adicionar novo paciente (ao sistema e à sua lista) ou associar à sua lista um paciente já existente no sistema, listar e visualizar os pacientes da sua lista, criar novos relatórios clínicos e visualizar os respetivos dados. O clínico especializado, deverá também ter permissão para editar os dados clínicos que são do âmbito da(s) sua(s) especialidade(s). Este é o módulo que permitirá aos clínicos efetivamente gerir os seus pacientes e a sua informação, que são as funcionalidades bases de um sistema de informação da área da saúde, pelo que possui prioridade MUST. Módulo de Comunicação Figura 16. Diagrama de Casos de Uso para o Módulo de Comunicação, secção das Mensagens. Especificação do Sistema 32 O módulo de Comunicação inclui os requisitos que permitirão aos clínicos usufruírem de um sistema de mensagens privadas, demonstrado na Figura 16, e também de um fórum, demonstrado na Figura 17. Tal como num sistema de mensagens típico, qualquer clínico poderá enviar mensagens a outros clínicos (ou grupos de clínicos) e terá acesso a uma caixa de entrada e caixa de saída (onde serão armazenadas as mensagens recebidas e enviadas, respetivamente) bem como uma reciclagem. Deverá também existir um fórum, com as funcionalidades típicas, onde os clínicos poderão criar novos tópicos para discussão e submeter posts. Para evitar eliminações indevidas e/ou excesso de níveis no fórum, apenas o administrador deverá ter permissões para eliminar tópicos ou criar novos sub-fóruns. Este módulo de funcionalidades apresenta nível de prioridade SHOULD. Figura 17. Diagrama de Casos de Uso para o Módulo de Comunicação, secção do Fórum. Especificação do Sistema 33 Módulo de Gestão de Pesquisas Personalizadas No módulo de Gestão de Pesquisas Personalizadas, demonstrado na Figura 18, encontramse todos os requisitos que permitirão ao clínico efetuar e gerir as pesquisas personalizadas aos dados clínicos dos pacientes contidos no sistema. Qualquer clínico deverá poder efetuar pesquisas e guardá-las nos favoritos e/ou torná-las públicas, para que outros clínicos possam aceder. Este módulo, não apresenta funcionalidades fulcrais ao nível do funcionamento básico do sistema, mas apresenta-se como um módulo com bastante importância uma vez que servirá de auxílio ao clínico na tomada de decisão. Assim, possui nível de prioridade SHOULD. Figura 18. Diagrama de Casos de Uso para o Módulo de Gestão de Pesquisas Personalizadas. Especificação do Sistema 34 Módulo de Investigação e Descoberta Deverá também existir o Módulo de Investigação e Descoberta. Este módulo encontra-se fora do âmbito desta dissertação e não se encontra totalmente definido e especificado, uma vez que requer que todo o restante sistema esteja completamente especificado e implementado para se poder especificar, implementar e testar convenientemente. No entanto, é um módulo que, no futuro, deverá fazer parte do sistema que está a ser agora iniciado e como funcionalidades principais deverá permitir ao clínico, investigar e explorar com maior detalhe os dados contidos no sistema, a partir de técnicas de data mining. As funcionalidades deste módulo centrar-se-ão na ajuda da tomada de decisão clínica, facilitando a realização de prognósticos (calculando, por exemplo, probabilidades de sobrevivência com recurso a curvas de Kaplan-Meier) e formulando hipóteses ou dando sugestões de tratamentos a aplicar. Deverá também permitir extrair estatísticas do conjunto de dados do sistema. Sendo um módulo fora do âmbito desta dissertação e que nesta fase ainda não se encontra totalmente definido, possui nível de prioridade WON’T. 3.2.4 Requisitos Não Funcionais Interoperabilidade Com a diversidade enorme de sistemas em funcionamento nas unidades de saúde atualmente, torna-se imprescindível que o SISU seja um sistema capaz de armazenar a informação num formato standard, de forma a poder efetuar-se facilmente, numa primeira fase, o import/export da informação para outros sistemas e mais tarde poder comunicar diretamente com outros sistemas. O SISU deverá assim seguir as normas de armazenamento e transmissão de dados, descritas no capítulo anterior. Escalabilidade e Expansibilidade O SISU deverá ter um alto nível de escalabilidade, podendo crescer facilmente ao nível do caso de estudo, com o aumento de unidades de saúde, serviços, especialidades, pacientes, clínicos, etc. O sistema deverá permitir este crescimento de uma forma fácil e simples, mantendo-se sempre operacional e atualizado. Deverá também ter um alto nível de expansibilidade para ser capaz de se alargar a outras patologias. Como referido anteriormente nesta dissertação, o SISU é um projeto piloto que tem como caso de estudo os sarcomas uterinos, mas um dos principais objetivos é que o sistema se expanda a outras patologias, tornando-se assim num sistema de informação oncológico nacional. Assim, o sistema deverá ser desenvolvido de forma a permitir facilmente este alargamento e expansão, principalmente a outras patologias. Especificação do Sistema 35 Segurança e Auditoria Tratando-se de um sistema da área da saúde, onde estão em causa dados pessoais e confidenciais, a segurança de todo o sistema é um aspeto fundamental. Assim o sistema deverá possuir acessos restritos e garantir que a informação só é acedida por clínicos competentes e com permissão para tal, negando qualquer acesso indevido. No sentido de reforçar a segurança de todo o sistema, ter controlo sobre as principais ações efetuadas e permitir recuperações em caso de falha, o SISU deverá ainda manter um registo atualizado de todas as atividades efetuadas e a respetiva informação associada, tal como autor da atividade, data, detalhes da atividade, etc. Usabilidade e Acessibilidade O auxílio da prática diária dos clínicos é um dos objetivos do SISU, pelo que o sistema deverá ser fácil de usar no dia-a-dia, tornando-se de facto uma ajuda e não um obstáculo. Assim, o sistema deverá possui um bom grau de usabilidade, apresentando uma interface simples e pemitindo o uso de todas as funcionalidades de forma rápida e com poucos cliques. Nos dias de hoje, assistimos a uma grande proliferação do uso de dispositivos com acesso à internet e a área da saúde não é excepção, onde cada vez é mais visível o uso de diversos instrumentos de auxílio, desde computadores a dispositivos móveis. Tendo em conta este crescimento, o SISU deverá também ser um sistema com boa acessibilidade, nomeadamente, deve ser acessível a partir de qualquer dispositivo (smartphone, tablet ou computador) com ligação à internet e a partir de qualquer um dos principais browsers que existem atualmente. 3.3 Arquitetura O sistema a ser desenvolvido deverá seguir o modelo cliente-servidor. Como demonstrado na Figura 19, o utilizador (clínico) poderá aceder ao sistema e às suas funcionalidades através da aplicação web disponibilizada, usando para isso o browser do seu dispositivo (computador ou dispositivo móvel) com acesso à internet. É através desta aplicação web (lado do cliente) que o clínico fará os pedidos ao servidor. O servidor por sua vez interage com a base de dados, onde estão armazenados todos os dados necessários ao funcionamento do sistema, no sentido de responder a estes pedidos do clínico. Especificação do Sistema 42 A Figura 23 demonstra os conceitos envolvidos no módulo de Comunicação, na secção das Mensagens e segue os conceitos comuns de um sistema de mensagens privadas. Uma mensagem possui um Clínico remetente e poderá ser enviada para vários Clínicos. A Figura 24 demonstra os conceitos envolvidos no módulo de Comunicação, na secção relativa ao Fórum. Este módulo apresenta também fatores inovadores, com o conceito de Fórum a poder estar associado a diversas entidades, o que lhe conferirá um bom nível de dinamismo. Um Fórum pode estar associado a diversos outros conceitos:  Somente a uma Unidade de Saúde, significando que é o fórum específico da Unidade, onde deverão participar todos os clínicos que estejam alocados em algum Serviço da Unidada;  Somente a um Serviço Geral (SuperServiço), significando que é o fórum específico daquele Serviço Geral, onde deverão participar todos os clínicos que estejam alocados num Serviço equivalente àquele Serviço Geral;  Somente a uma Especialidade, significando que é o fórum específico daquela Especialidade, onde deverão participar todos os clínicos que estejam a exercer a Especialidade em algum serviço;  A um Serviço e a uma Unidade de Saúde, significando que é o fórum daquele Serviço dentro daquela Unidade de Saúde, onde deverão participar apenas os clínicos que estejam alocados naquele Serviço específico da Unidade;  A uma Unidade de Saúde e a uma Especialidade, significando que é o fórum daquela especialidade dentro daquela Unidade de Saúde, onde deverão pariticipar apenas os clínicos que estejam a exercer a Especialidade dentro da Unidade. Dentro destes Fóruns poderão existir tópicos (que por sua vez deverão conter Posts), criados pelos Clínicos, bem como sub-fóruns. Especificação do Sistema 43 Módulo de Pesquisas Personalizadas A Figura 25 demonstra os conceitos envolvidos no módulo de Gestão de Pesquisas. Este é também um dos módulos mais inovadores e complexos do sistema. Um Clínico pode efetuar uma ou mais Pesquisas, sendo que estas Pesquisas poderão posteriormente ser partilhadas com outros clínicos. Para facilitar a compreensão dos conceitos, poderá fazer-se uma analogia entre as Pesquisas Personalizadas e as queries em SQL. Uma query em SQL possui as variáveis às quais se quer aplicar restrições no WHERE e as variáveis que se pretendem filtrar no SELECT. O WHERE possui também a restrição a aplicar à variável assim como o valor associado à restrição. Neste módulo, uma Pesquisa Personalizada inclui uma ou mais Variáveis, equivalentes às Variáveis que estão presentes no WHERE da query. Inclui também uma Restrição a ser aplicada, equivalente à restrição. As restrições estão relacionadas com o Tipo da Variável e a Estrutura da Variável, para definir quais as restrições válidas para uma variável de um determinado tipo e estrutura. À semelhança dos módulos anteriores, para identificação com precisão das Váriaveis em questão, uma Pesquisa está também associada à Patologia, ao Tipo de Dado Clínico (tipo de relatório) e a Vista onde a variável se encontra e contém um atributo "caminho". Figura 25. Modelo Conceptual de Dados para o Módulo de Pesquisas Personalizadas. Especificação do Sistema 44 Nesta fase está especificada somente parte do módulo de Gestão de Pesquisas, que permitirá a um Clínico efetuar uma Pesquisa Personalizada e obter como resultado a lista de pacientes que possuiu variáveis que obedecem às restrições introduzidas. Fazendo novamente analogia com uma query SQL, está apenas especificada a parte relativa ao WHERE. 3.4 Tecnologias Serão agora identificadas e justificadas as principais tecnologias que deverão ser utilizadas no desenvolvimento do protótipo do SISU. 3.4.1 Base de Dados e Sistema de Gestão Uma das principais e mais importantes escolhas para o desenvolvimento do SISU será o tipo de base de dados que suportará todo o sistema. Atualmente existem dois grandes tipos de base de dados: base de dados relacionais e base de dados não relacionais (também conhecidas como noSQL). Bases de dados relacionais assentam numa coleção de tabelas, de estrutura fixa, que contêm os dados e que são formadas e descritas segundo o modelo relacional. Seguindo o modelo relacional, as tabelas interrelacionam-se entre si e referenciam-se através do uso de chaves estrangeiras. Normalmente a informação que se deseja obter, neste tipo de base de dados, provém de várias tabelas, sendo combinada antes de ser fornecida pela aplicação (da mesma forma, a escrita também deverá ser coordenada e executada em várias tabelas). A linguagem padrão utilizada neste tipo de base de dados é o SQL (Structured Query Language) [Bri10]. Bases de dados noSQL não seguem o modelo relacional e os dados podem ser armazenados de diversas formas, tais como, documentos (documentos json por exemplo), grafos, pares chave-valor ou em colunas sem qualquer tipo de estrutura definida. Por exemplo, dados relacionados que se estendem por 20 tabelas num modelo relacional, podem ser agregados e armazenados num único documento json, o que pode levar à duplicação de informações, mas por outro lado aumentam a flexibilidade do modelo de dados e facilitam a distribuição de forma eficiente dos documentos resultantes [Bri10]. Para lidar com o aumento de utilizadores e da quantidade de dados as aplicações e as suas bases de dados subjacentes necessitam de escalar, existindo duas opções: scale up (escalamento vertical) e scale out (escalamento horizontal). Scale up, demonstrado na Figura 26, implica uma abordagem centralizada, que se baseia em servidores cada vez maiores e com mais recursos. Scale out, demonstrado na Figura 27, implica uma abordagem distribuída, aumentando o número de servidores [Gig11]. Ao nível da camada da base de dados a opção de escalamento varia consoante o tipo de base de dados. Especificação do Sistema 45 Bases de dados relacionais, devido à sua natureza baseada em tabelas, utilizam escalamento vertical: para suportar um maior número de utilizadores e uma maior quantidade de dados, é necessário um servidor maior e com mais recursos [Bri10]. Estes tipos de servidores são desproporcionalmente caros e provocam uma descida no desempenho do sistema. As bases de dados noSQL têm sido desenvolvidas para tentar resolver este problema de escalabilidade dos sistemas relacionais. Este tipo de base de dados utiliza um cluster de servidores para armazenar dados e suportar operações na base de dados. Para escalar, servidores extra são adicionados ao cluster e os dados e operações são espalhados por todo o cluster – escalamento horizontal. Não são necessárias modificações ao nível da aplicação uma vez que esta apenas “vê” uma única base de dados (que se encontra distribuída). Estes servidores extra Figura 26. Escalamento vertical da camada de base de dados. Figura 27. Escalamento horizontal na camada de base de dados. Especificação do Sistema 46 são bastante mais baratos que os grandes e complexos servidores que as base de dados relacionais necessitam e não implicam uma quebra no desempenho do sistema. Este tipo de escalamento horizontal traz também outras vantagens, como a inexistência de um ponto único de falha no sistema, uma vez que os dados se encontram distribuídos. Servidores ao nível da base de dados podem ser adicionados ou trocados, sem que isso implique que o sistema fique totalmente offline [Bri10]. Como visto anteriormente, as base de dados noSQL surgem como melhor opção para armazenar grandes quantidades de dados (big data) onde existe um crescimento de informação muito grande e por consequência um rápido e fácil escalamento é fulcral. No entanto, bases de dados relacionais também apresentam vantagens. Graças à sua estrutura em tabelas, este tipo de sistemas garante uma maior integridade lógica do modelo de domínio, garantindo não só a consistência de uma entidade como a consistência entre as várias entidades. Devido às propriedades ACID (Atomicity, Consistency, Isolation, Durability) as bases de dados relacionais garantem também uma maior consistência das transações e por consequência uma maior consistência dos dados. Bases de dados noSQL relacionais possuem características BASE (Basically Available, Soft State, Eventual Consistency), sacrificando assim um pouco a integridade e consistência dos dados, com o objetivo de obter resultados de forma mais rápida, tolerando assim algum tipo de inconsistência [Roe12]. Os sistemas de gestão de base de dados relacionais permitem também efetuar consultas de dados mais potentes, através da linguagem SQL, quando comparados com sistemas de base de dados noSQL. A capacidade de agrupar e reunir dados, de entidades não relacionadas, num novo ponto de vista sobre os dados é algo que faz deste tipo de sistemas de gestão de base dados uma ferramente poderosa. Este tipo de base de dados torna-se então mais indicado quando há necessidade de efetuar consultas complexas e frequentes [Bri10]. A Tabela 2 apresenta uma comparação sintetizada entre os dois tipos de base de dados. Tabela 2. Comparação entre base de dados relacional e não relacional (noSQL). Base de dados relacional Base de dados não relacional Tipos Único tipo: baseado em tabelas Vários tipos: baseado em documentos, pares chave-valor, grafos e colunas. Esquema de Dados Fixo, para se efetuar alterações no esquema a base de dados necessita de ficar offline. Tipicamente dinâmico, sem necessitar de ficar totalmente offline. Escalamento Vertical Horizontal Especificação do Sistema 47 Modelo de Desenvolvimento Open-source e Closed-source Open-source Manipulação de Dados Linguagem específica (SQL) que permite alta manipulação e consulta de dados Através de APIs orientadas a objetos Exemplos MySQL, PostgreSQL, Oracle e Microsoft SQL-Server MongoDB, Cassandra e HBase Um dos objetivos do SISU será alargar-se a nível nacional, cobrindo todas as patologias e todas as unidades oncológicas do país. A taxa de incidência do cancro (número de novos casos detetados) em Portugal encontra-se de momento em cerca de 40-50 mil por ano [DGS13]. Foi possível estimar, junto de clínicos do IPO Porto, que em média, as consultas dos pacientes distam entre si de 1 a 3 meses e os tratamentos, análises e exames distam 1 a 3 semanas. Estimou-se também, que um relatório clínico, que será originado por consultas, tratamentos, análises e exames dos pacientes, será constituído por 2 a 5 secções (correspondentes a vistas) onde cada secção poderá ter entre 10 a 30 variáveis clínicas. É assim possível efetuar uma estimativa, no pior caso, do número mensal de novos registos (dados clínicos) introduzidos na base de dados:  Total de variáveis de um relatório clínico de um paciente: 30*5 = 150  Total mensal de relatórios clínicos, excepto consultas, de um paciente: 4  Total mensal de relatórios clínicos de consultas de um paciente: 1  Total mensal de novos pacientes: 4000 Fazendo a estimativa do número médio mensal de inserções de novos dados clínicos: (150*4 + 150*1) *4000 = 3 000 000 novas inserções. Este número estimado corresponde ao número de novas inserções mensais de dados clínicos de pacientes, na base de dados do sistema nacional, sendo a operação que se espera ser a mais comum em todo o sistema. De salientar que este número diz respeito ao pior cenário, abrangendo todas as patologias e todas as Unidades e Serviços a nível nacional. Esta quantidade de informação encontra-se muito longe dos típicos problemas de big data, onde o uso de bases de dados não relacionais é mais adequado, como por exemplo, problemas que envolvem redes sociais como o twitter onde são enviados diariamente cerca de 500 milhões de tweets [AT14]. Espera-se que o SISU, ao contrário de aplicações como redes sociais, não tenha um escalamento tão drástico e repentino. Por outro lado, a consistência e integridade dos dados envolvidos no SISU são de grande importância, uma vez que estão em causa dados altamente sensíveis que devem ser corretamente armazenados e preservados. O SISU assentará também Especificação do Sistema 48 grande parte em consultas complexas de dados clínicos, pelo que estas deverão ser efetuadas com eficiência. Assim sendo, a escolha sobre o tipo de base de dados a ser implementado no SISU recaiu sobre uma base de dados relacional, uma vez que o volume de dados envolvidos não justifica um modelo noSQL e as suas desvantagens associados. Tendo a escolha do tipo de base de dados recaído sobre uma base de dados relacional, é necessário proceder à escolha do sistema de gestão. Atualmente, os 5 sistemas de gestão de base de dados relacionais mais populares são: Oracle1, MySQL2, Microsoft SQL Server3, PostgreSQL4 e DB25 [DB14]. Oracle e Microsoft SQL Server sendo softwares closed-source (ou a licença livre que possuem não permite que seja usado no desenvolvimento de software que possa ser comercializado, algo que o SISU poderá vir a ser) foram colocados de parte. PostgreSQL, MySQL e DB2 apresentam sensivelmente o mesmo leque de funcionalidades [SQL14]. A escolha recaiu sobre PostgreSQL por existir uma maior familiarização e nível de experiência com a ferramenta por parte do autor desta dissertação. 3.4.2 Outras tecnologias Para o desenvolvimento do SISU serão utilizadas ainda as seguintes tecnologias:  Servidor Apache6, versão 2.  PHP7, versão 5, como linguagem de servidor. A escolha da principal linguagem de desenvolvimento recaiu sobre PHP uma vez que é a linguagem com que o autor da dissertação possui mais experiência de desenvolvimento, o que permitirá encurtar o tempo de aprendizagem e minimizar assim os riscos envolvidos.  Framework de PHP Laravel8, versão 4, para auxiliar e agilizar o desenvolvimento modular do sistema.  HTML59, Javascript e CSS310, como é prática corrente no desenvolvimento de uma aplicação web, serão usados para o desenvolvimento do lado do cliente do sistema. 1 Oracle. Mais informação disponível em: http://www.oracle.com/index.html 2 MySQL. Mais informação disponível em: http://www.mysql.com/ 3 SQL Server. Mais informação disponível em: http://www.microsoft.com/en-us/server-cloud/products/sql-server/ 4 PostgreSQL. Mais informação disponível em: http://www.postgresql.org/ 5 DB2. Mais informação disponível em: http://www-01.ibm.com/software/data/db2/ 6 Apache. Mais informação disponível em: http://httpd.apache.org/ 7 PHP. Mais informação disponível em: http://php.net/ 8 Laravel. Mais informação disponível em: http://laravel.com/ Especificação do Sistema 49  Twitter Bootstrap11, versão 3, para auxiliar no desenvolvimento da interface e melhorar o nível de usabilidade e acessibilidade da aplicação. 9 HTML5. Mais informação disponível em: http://www.w3.org/html/ 10 CSS3. Mais informação disponível em: http://www.w3.org/Style/CSS/ 11 Boostrap. Mais informação disponível em: http://getbootstrap.com/ 50 Capítulo 4 Sistema Implementado Neste capítulo será feita uma descrição do sistema implementado. Serão descritas todas as funcionalidades implementadas e de que forma os requisitos, funcionais e não funcionais, foram abordados. 4.1 Visão Geral Foi desenvolvido um protótipo do SISU contemplando 4 dos 6 atores especificados no capítulo anterior, sendo eles: visitante, clínico, clínico especializado e administrador. Este protótipo inclui todos os módulos de funcionalidades descritos no capítulo anterior com o nível de prioridade mais elevado, MUST (com a excepção das funcionalidades atribuídas aos atores não contemplados no protótipo), bem como o módulo de Comunicação. Inclui também uma parte das funcionalidades do módulo de Pesquisas Personalizadas. De salientar que o sistema desenvolvido tem como caso de estudo uma só patologia, os sarcomas uterinos. 4.2 Funcionalidades Serão agora descritas as funcionalidades do sistema desenvolvido e os detalhes mais importantes da sua implementação. Uma vez mais será feita uma divisão em módulos de funcionalidades. Em cada módulo serão descritas as funcionalidades disponíveis a cada tipo de utilizador: visitante, clínico, clínico especializado e administrador. No protótipo desenvolvido, as funcionalidades que são unicamente do âmbito do administrador (gestão de clínicos, gestão de entidades e gestão de templates) encontram-se no menu superior. Este menu superior permite também a qualquer clínico aceder à sua página de Sistema Implementado 51 perfil e terminar sessão. As funcionalidades a que todos os clínicos terão acesso (gestão pacientes, gestão de pesquisas e módulo de comunicação) encontram-se no menu da esquerda. O sistema foi implementado seguindo o padrão MVC (Model-View-Controller). Os controladores contêm toda a parte desenvolvida em PHP e neles estão contidas todas as funções que acedem à base de dados. Existe um controlador para cada elemento integrante do sistema que possa ser gerido: Clínico, Unidade de Saúde, Serviço Geral, Especialidade, Serviço, Vista, Grupo de Variáveis, Variável, Trigger, Templates, Pesquisa, Mensagem, Fórum e Tópico. Existe ainda um controlador para gerir as sessões dos utilizadores e outro para gerir os grupos de permissões. Cada controlador possui um conjunto de views associadas, que são as páginas de funcionalidades com que os utilizadores vão interagir. Para a implementação das views foi utilizado o mecanismo de templates Blade12 fornecido pela framework utilizada, Laravel. Recorreu-se também à biblioteca JQuery13 assim como à coleção JQuery UI14 para simplificar e melhorar o desenvolvimento das views. Quando é necessário efetuar pedidos ao servidor é utilizado AJAX, obtendo-se como resposta a informação solicitada (ou um aviso informando que ocorreu um erro) em formato json, que por sua vez é tratada do lado do cliente, sendo posteriormente apresentada ao utilizador do sistema. 4.2.1 Módulo de Gestão de Clínicos Visitante Quando chega à aplicação, o visitante tem a possibilidade de efetuar login ou fazer pedido de recuperação de password, como mostra a Figura 28. Caso faça pedido de recuperação de password irá receber um email com instruções para adquirir uma nova password. Caso inicie sessão com sucesso, passará a ter acesso às funcionalidades do sistema. 12 Blade Templating. Mais informação disponível em: http://laravel.com/docs/5.0/templates 13 JQuery. Mais informação disponível em: http://jquery.com/ 14 JQuery UI. Mais informação disponível em: http://jqueryui.com/ Figura 28. Página inicial do SISU. Sistema Implementado 58 Os tipos e estruturas válidas para uma variável estão definidos na base de dados (tabelas de conteúdo fixo). Os tipos válidos disponíveis são: inteiro, decimal, texto, data, hora, sim/não e ficheiro. As estruturas válidas disponíveis são: lista simples, lista múltipla, intervalo, valor simples e standard (esta última estrutura é definida por omissão para tipos de variáveis que só possuam uma estrutura válida, como por exemplo sim/não ou ficheiro). A relação entre os tipos e estruturas de variáveis é também definida ao nível da base de dados (numa tabela de conteúdo fixo). Esta relação define quais as estruturas que vão aparecer como válidas após o administrador ter selecionado um determinado tipo de variável. Por exemplo, para uma variável do tipo inteiro, estão disponíveis as estruturas lista simples, lista múltipla, intervalo e valor simples, enquanto para uma variável do tipo texto só estão disponíveis as estruturas de lista simples, lista múltipla e valor simples. Os campos válidos para restringir uma variável são também definidos na base de dados (numa tabela de conteúdo fixo), estando disponíveis três campos: mínimo, máximo e valor. Da mesma forma, é também definida ao nível da base de dados a relação entre as estruturas e os campos. Esta relação define quais os campos que deverão aparecer e ser preenchidos após o administrador selecionar a estrutura da variável. Por exemplo, para uma variável do tipo inteiro com estrutura de intervalo, aparecerão para preencher os campos de mínimo e máximo. De referir que o tipo de input (ao nível do HTML) destes campos dependerá também do tipo da variável que o administrador selecionou anteriormente. De realçar que não será possível desativar variáveis que já tenham sido preenchias no relatório clínico de algum paciente. O administrador poderá também criar triggers para aplicar a variáveis, para que determinados valores ou mudança de valores numa variável faça despoletar uma ação ou restrição noutra variável. Por exemplo, o administrador pode aplicar um trigger a uma variável do tipo sim/não que indique se o paciente é maior de idade: caso a variável possua valor "sim", então a variável idade ficará limitada, só podendo agora tomar valores maiores ou iguais a 18, como mostra a Figura 39. Sistema Implementado 59 O administrador deverá introduzir um nome para o trigger e identificar as variáveis em causa (variável de origem e variável de destino), seguindo a estratégia referida no capítulo anterior, indicando o Tipo de Dados (tipo de relatório), a posição da variável na hierarquia de vistas e grupos (caminho) e a variável em si. Após identificar a variável, será solicitado ao administrador que indique a ação que irá despoletar o trigger (no caso da variável de origem) e a reação (no caso da variável de destino). As ações/reações disponíveis dependerão do tipo e estrutura da variável selecionada anteriormente. Após ser selecionada a ação/reação, será solicitado ao administrador que preencha os respetivos campos (se aplicável). As ações e reações válidas para uma variável estão definidas na base de dados (tabelas de conteúdo fixo). Estão disponíveis como ações: maior que, menor que, igual a, está entre, número de opções maior que, número de opções menor que, número de opções igual a e número de opções está entre. Como reações estão disponíveis todas as ações bem como a opção de colocar uma variável disabled ou torná-la de preenchimento obrigatório. Na base de dados, as ações/reações estão relacionadas com o tipo e a estrutura das variáveis (tabela de conteúdo fixo), de forma a definir-se quais as ações/reações válidas para uma variável de um determinado tipo e estrutura. Por exemplo, para uma variável do tipo inteiro e estrutura valor simples, estarão apenas disponíveis ações de quantificação (maior que, menor que, igual a e está entre). Tal Figura 39. Criação de um trigger. Sistema Implementado 60 como na criação de variáveis, descrita anteriormente, as ações/reações possem também campos associados (tabela de conteúdo fixo), definindo assim os campos que o administrador deverá preencher para a ação/reação selecionada. Há no entanto a realçar que esta funcionalidade de triggers, está apenas disponível em backoffice, isto é, o administrador pode criar os triggers e estes ficarão guardados na base de dados, mas não terão qualquer impacto real no sistema, faltando desenvolver a parte de frontoffice. O administrador poderá também visualizar e gerir os grupos, como demonstrado na Figura 40. Poderá visualizar a informação do grupo e a sua constituição e poderá adicionar variáveis (que já tenham sido criadas previamente) ao grupo e definir a ordem em que irão aparecer, arrastando para isso as variáveis dentro do grupo. De igual forma, poderá também adicionar outros grupos, como demonstra a Figura 41. De realçar que o administrador só terá disponíveis para adicionar, grupos que não criem problemas de recursividade infinita (por exemplo, se o Grupo 1 estiver contido dentro do Grupo 2, dentro do Grupo 1 não poderá adicionar-se nenhum outro grupo que já contenha o Grupo 2). Figura 41. Lista de grupos de variáveis existentes no sistema. Figura 40. Página de um Grupo de Variáveis do sistema. Sistema Implementado 61 De forma semelhante, o administrador poderá também visualizar e gerir as Vistas existentes no sistema. Poderá visualizar a sua informação e constituição e poderá também adicionar novos grupos e determinar a sua ordem, como mostra a Figura 42. Por fim, o administrador poderá visualizar e gerir os Tipos de Dados Clínicos (tipos de relatórios) que existem, distribuídos pelas várias Áreas clínicas. De salientar que estas Áreas Clínicas estão definidas na base de dados (tabela de conteúdo fixo), sendo elas: Ficha Clínica, Análises, Consultas, Exames, Tratamentos e Follow-up. A Ficha Clínica, sendo uma área com tratamento especial onde podem ser visualizados os valores mais recentes das variáveis mais importantes, como já referido anteriormente, não aparece nesta página. A área de Follow-up apresenta um único Tipo de Dado Clínico, standard por omissão, uma vez que possui uma estrutura fixa. A todas as outras Áreas o administrador poderá adicionar novos Tipos de Dados Clínicos, como mostra a Figura 43. Por exemplo, o administrador poderá adicionar um novo tipo, 'Hormonal', à área clínica de tratamentos. Figura 42. Página de uma Vista do sistema. Sistema Implementado 62 Por fim, o administrador poderá definir quais as Vistas que cada Especialidade terá permissão para editar, demonstrado na Figura 44. Há que salientar que esta associação funciona como dois em um: indica quais as Vistas que um relatório de um determinado Tipo deverá conter e simultaneamente indica quais as Especialidades que terão permissão para editar os dados clínicos dessas mesmas Vistas. Por exemplo, se o administrador definir que nos relatórios do tipo "Quimioterapia", a Especialidade de "Cirurgia Geral" terá permissão para editar os dados das Vistas "VistaAC" e "VistaAA", significa que todos os clínicos (independentemente das suas especialidades) vão visualizar estas duas Vistas num relatório daquele tipo. No entanto, apenas os clínicos que estejam a exercer a Especialidade de "Cirurgia Geral" poderão editar os dados clínicos presentes nessas Vistas. Esta parte de permissão de edição dos dados clínicos será melhor abordada no subcapítulo seguinte. Figura 43. Áreas clínicas e respetivos Tipos de Dados Clínicos associados. Figura 44. Associação de Vistas com Especialidades e Tipos de Dados Clínicos Sistema Implementado 63 4.2.4 Módulo de Gestão de Pacientes Clínico Clicando em „Pacientes‟ no menu da esquerda, o clínico pode aceder à lista de pacientes que acompanha de momento, como mostra a Figura 45. Nesta página, é-lhe permitido adicionar à sua lista um novo paciente (que ainda não exista no sistema) ou então associar à sua lista um paciente que já tenha sido introduzido no sistema e esteja numa das Unidades de Saúde onde o clínico exerce funções. Também lhe é permitido eliminar um paciente da sua lista (lembrando que o paciente se mantém no sistema, simplesmente deixa de ser acompanhado pelo clínico e como tal deixa de aparecer na sua lista de pacientes). O clínico poderá aceder à página do paciente, onde terá acesso a uma grande diversidade de informação clínica. Poderá aceder à ficha clínica do paciente, onde pode visualizar de forma sintetizada os dados clínicos mais importantes mais recentes do paciente, como demonstrado na Figura 46. Figura 45. Lista de pacientes do clínico. Sistema Implementado 64 As variáveis presentes na Ficha Clínica (dados clínicos mais importantes) deverão ser definidas na base de dados. Respeitando a especificação feita no capítulo anterior, estas variáveis da Ficha Clínica deverão estar associadas a variáveis de relatórios devidamente identificadas (respeitando a estratégia definida anteriormente de identificação de variáveis com a identificação do conjunto Tipo de Dado-Vista-Caminho-Variável). Com esta associação feita, é possível localizar todos os os relatórios do tipo pretendido, sendo possível obter-se (com o restante conjunto da identificação da variável) as variáveis em questão e os respetivos valores para o paciente. É depois feita uma filtragem, na procura do valor mais recente (que está contida no relatório mais recente encontrado), sendo este o valor que deve ser apresentado na Ficha Clínica do Paciente. No exemplo da Figura 46, a variável 'Massa do tumor' e o respetivo valor corresponde à variável 'Massa do tumor' mais recente, de todos os relatórios de tipo quimioterapia do paciente. O clínico poderá também aceder às outras áreas clínicas do paciente: análises, consultas, exames, tratamentos e follow-up. Clicando numa das áreas clínicas, será solicitado ao clínico que escolha o tipo de dado clínico que pretende consultar. Por exemplo, se o clínico clicou na área clínica de "Tratamentos", ser-lhe-á agora solicitado que escolha o tipo, que poderá ser Quimioterapia, Radioterapia, etc (excepto se tiver escolhido a área clínica de "Follow-up", nesse Figura 46. Ficha clínica de um paciente, onde é possível visualizar os valores mais recentes de alguns dos dados mais importantes. Sistema Implementado 65 caso o tipo é standard e único). Após escolher o tipo de dado, o clínico terá a hipótese de visualizar, numa timeline dinâmica e interagível, todos os relatórios clínicos que o paciente possui, correspondentes ao tipo e área clínica selecionados anteriormente, como demonstra a Figura 47. A timeline foi implementada com recurso à biblioteca Vis17 de javascript. Nesta fase, o clínico tem também a possibilidade de criar um novo relatório clínico para o paciente (correspondente ao tipo e área clínica selecionados previamente). A timeline permite adicionar novos elementos (neste caso, novos relatórios) dinamicamente pelo que não é necessário novo carregamento da página quando um novo relatório é adicionado. O clínico poderá clicar num relatório da timeline para visualizar os respetivos dados tal como demonstrado na Figura 48. O relatório, como explicado anteriormente neste documento, é composto por várias vistas, onde cada vista possuiu grupos de variáveis que por sua vez possuem variáveis clínicas ou até mesmo outros grupos. O clínico poderá navegar pelas várias vistas que compõem o relatório. 17 Biblioteca Vis. Mais informação disponível em: http://visjs.org/docs/ Figura 47. Relatórios clínicos do tipo Quimioterapia da área de Tratamentos. Sistema Implementado 66 Clínico Especializado O clínico especializado, poderá editar os dados clínicos das vistas que sejam do âmbito da(s) sua(s) especialidade(s), como demonstra a Figura 49. Como visto anteriormente, são as especialidades que o clínico possui ativas (isto é, o clínico encontra-se alocado com a(s) especialidade(s) em algum serviço de uma Unidade onde o paciente se encontra) que determinam quais as vistas (e por consequência, quais os dados clínicos) que poderá editar. De forma resumida, o clínico pode visualizar tudo, mas só pode editar o que lhe está diretamente ligado pelas especialidades. Esta restrição surge para evitar, ou minimizar, erros clínicos, como por exemplo o preenchimento errado de uma variável que apesar de possuir o mesmo nome, encontra-se num contexto completamente diferente fazendo parte do conjunto de dados de uma outra especialidade. Nos exemplos da Figura 48 e Figura 49, o clínico tem permissão para editar os dados das vistas "Vista AA" e "Vista AC" mas possui apenas permissão para visualizar os dados da vista "Vista AB". Figura 48. Visualização de um relatório clínico (do tipo Quimioterapia da àrea de Tratamentos) dividido em várias Vistas. Sistema Implementado 67 Respeitando o modelo especificado no capítulo anterior, existe na base de dados uma tabela que relaciona as Vistas, com as Especialidades e com os Tipos de Dados Clínicos (tipo de relatório). De realçar que estas relações são definidas pelo administrador, como referido no subcapítulo. A Patologia é ignorada, uma vez que o sistema desenvolvido tem como caso de estudo uma só patologia (sarcomas uterinos). Para se determinar quais as vistas que fazem parte de um relatório de um tipo, é feita uma seleção na tabela da base de dados de todas as vistas que estejam relacionadas com o tipo de dado clínico, sendo ignoradas as relações com as especialidades. Para se determinar quais as vistas que um clínico pode editar, é feita uma seleção, dentro do conjunto de vistas obtido anteriormente, das vistas que estão relacionadas com alguma das especialidades que o clínico se encontra a exercer no momento. Figura 49. Visualização de uma Vista do relatório onde o clínico tem permissão para editar os dados clínicos. Sistema Implementado 74 Avançando, o clínico passará para a fase onde terá que escolher que restrições pretende aplicar, às variáveis previamente selecionadas, para obter os seus resultados da pesquisa, como demonstrado na Figura 57. O clínico deverá assim selecionar a variável que pretende usar para restringir, seguida da escolha da restrição. De referir que as restrições que irão aparecer como opção de escolha, à imagem das ações/reações na criação de um trigger, dependem do tipo e estrutura da variável selecionada. Por exemplo, existirá a restrição "maior que" para uma variável do tipo inteiro, mas não para uma variável do tipo texto. Esta restrição às opções válidas é feita ao nível da base de dados (tabela de conteúdo fixo), à semelhança das ações/reações dos triggers. Após selecionar a restrição a aplicar à variável, o clínico deverá introduzir qual o valor associado à restrição (por exemplo, valor 5, numa restrição "maior que"). Completado este processo, o clínico poderá concluir a sua pesquisa sendo-lhe retornado os resultados. Como referido, o protótipo apresenta algumas limitações neste módulo de funcionalidades. É somente permitido ao clínico efetuar pesquisas com uma só restrição a uma só variável clínica. Os resultados obtidos são também limitados, obtendo-se apenas uma lista com o nome dos pacientes que respeitam a restrição. Fazendo uma analogia com uma query de SQL onde existem as variáveis respeitantes ao WHERE e ao SELECT, neste protótipo está apenas implementada a parte das variáveis do WHERE (sendo permitida apenas uma só variável), faltando a restante parte que compõe uma query. Figura 57. Segunda fase da realização de uma pesquisa personalizada, onde o clínico indica as restrições que pretende aplicar. Sistema Implementado 75 4.3 Abordagem aos Requisitos Não Funcionais 4.3.1 Interoperabilidade No sentido de garantir a interoperabilidade do SISU com os sistemas de informação já existentes e em funcionamento atualmente nas unidades de saúde nacionais, o sistema foi especificado e implementado de forma a seguir as normas de armazenamento de dados clínicos, mais especificamente a norma OpenEHR. Esta é uma norma open-source (ao contrário da HL7) da qual é mais fácil obter informação e especifica, entre outras coisas, o armazenamento de dados clínicos, enquanto a norma HL7 é mais focada nas mensagens em si e na sua troca, tal como descrito no capítulo 2. O SISU, como descrito no capítulo anterior, a nível de interoperabilidade, tem como primeiro objetivo permitir que se faça o import/export correto de dados, de forma a garantir que não ocorre perda de informação e só depois então permitir que comunique diretamente com os outros sistemas. Por estes motivos, optou-se por ter como modelo a norma OpenEHR. Como referido no capítulo 2, a norma OpenEHR baseia-se em archtypes para definir os conceitos clínicos. Estes archtypes têm como propósito definir as restrições do conceito, tais como estrutura, tipo de dados e valores possíveis de tomar. Esta forma de restringir os conceitos clínicos foi replicada no SISU através do conceito de “variável clínica”. É permitido ao administrador criar novas variáveis clínicas para serem utilizadas nos relatórios das várias áreas. À imagem dos archtypes, estas variáveis têm uma estrutura e um tipo associado, bem como campos com valores que restringem os valores que a variável poderá tomar, tal como demonstrado na Figura 58. Figura 58. Modelo conceptual relativo à parte das váriáveis clínicas (à esquerda) e interface respeitando esse mesmo modelo (à direita). Sistema Implementado 76 A norma openEHR também estipula o formato standard para relatórios clínicos. Os relatórios são compostos por secções, onde cada secção pode conter simplesmente conceitos clínicos ou grupos de conceitos, grupos estes que podem ser de vários tipos e conter outros grupos, tal como demonstrado na Figura 59. O SISU foi implementado de forma similar: os relatórios das várias áreas de tratamento, que são definidos e estruturados pelo administrador, são compostos por vistas que contêm grupos. Estes grupos podem conter variáveis bem como outros grupos, sendo assim um modelo “em cascata”, tal como demonstrado na Figura 60, à semelhança do formato dos relatórios definidos pela norma OpenEHR. Tentou-se assim aproximar o SISU aos padrões definidos pela norma OpenEHR. Figura 59. Template de um relatório clínico da norma OpenEHR. Sistema Implementado 77 4.3.2 Expansibilidade e Escalabilidade Apesar do SISU ser um sistema que tem como caso de estudo os sarcomas uterinos, um dos seus objetivos principais é alargar-se a nível nacional e abranger todas as patologias oncológicas. Tendo em vista este objetivo, o SISU foi especificado tendo já em conta este alargamento. Como a Figura 61 indica, o sistema inclui um conjunto de „Patologias‟ (que poderão ser adicionadas pelo administrador do sistema). Cada Patologia possuirá um responsável dentro da unidade e um responsável a nível nacional. As Patologias estão também diretamente ligadas com a estrutura dos relatórios: relatórios de diferentes patologias, possuem diferentes templates (diferentes vistas), como indica a Figura 62. Figura 60. Exemplo de relatório clínico do SISU. Sistema Implementado 78 Figura 62. Modelo Conceptual demonstrando que a Patologia tem influência na estrutura dos relatórios clínicos. Figura 61. Modelo Conceptual definido tendo já em conta o alargamento a outras patologias. Sistema Implementado 79 O SISU foi assim especificado e implementado de forma a poder alargar-se facilmente a outras patologias oncológicas e até, por ventura, a outras áreas da saúde, uma vez que se trata de um sistema altamente genérico capaz de se adaptar de forma rápida e simples a muitas áreas. 4.3.3 Segurança Tratando-se de um sistema de informação da área da saúde, a segurança e confidencialidade dos dados torna-se um aspeto essencial. O SISU foi implementado de forma a ter acessos limitados e apenas clínicos registados (registo que apenas pode ser feito pelo administrador) podem aceder às funcionalidades do sistema. Antes de cada adição/eliminação/edição ser feita no sistema é verificado qual o tipo de utilizador que se encontra conectado e que tenciona efetuar a ação. A ação só será permitida, caso o clínico possua permissões para tal, sendo negada qualquer tipo de ação que ultrapasse o seu nível de permissões. Como já referido anteriormente, existem dois grupos principais de permissões que distinguem os utilizadores: utilizadores comuns e administradores. Apenas os administradores têm permissões para efetuar alterações na parte de administração (gestão de clínicos, gestão de entidades e gestão de templates), evitando assim eventuais complicações por mau uso das funcionalidades. Um outro nível de segurança é introduzido no sistema com a encriptação, através do algoritmo bcrypt, das passwords dos utilizadores antes de serem guardadas na base de dados. Este algoritmo de encriptação é baseado no Blowfish [PM99]. A segurança do algoritmo bcrypt está relacionada com a sua velocidade, sendo um algoritmo muito lento, podendo demorar até 1s a gerar uma encriptação. Esta lentidão significa que um ataque de força bruta é praticamente impossível de executar, devido à quantidade de tempo que necessitaria. O algoritmo utiliza um parâmetro de custo que especifica o número de ciclos que deverão ocorrer. O aumento desse número fará, naturalmente, aumentar o tempo de execução do algoritmo, mas aumentará também a segurança do resultado. As comunicações no sistema são também feitas através do protocolo HTTPS, garantindo assim um nível extra de segurança ao sistema. 4.3.4 Usabilidade e Acessibilidade O sistema foi desenvolvido de forma a possuir uma interface simples e intuitiva. Como referido anteriormente, recorreu-se ao uso da framework Bootstrap para se obter uma interface mais limpa e homogénea assim como para garantir um bom nível de responsividade, para que o sistema possa ser utilizado em qualquer dispositivo com acesso à internet. No sentido de se testar o real nível de usabilidade do sistema, foram conduzidos testes com utilizadores reais que serão descritos no capítulo seguinte. 80 Capítulo 5 Testes e Resultados A Usabilidade não existe num sentido absoluto, uma vez que apenas pode ser definida em relação a contextos particulares. Uma vez que a usabilidade de um produto ou serviço é definida pelo contexto em que o produto ou serviço é utilizado, então as medidas de usabilidade devem também ser definidas tendo em conta esse contexto. Apesar disso, existe uma necessidade de medidas gerais que possam ser utilizadas para comparar a usabilidade em contextos variados [Bro96]. Para avaliar a usabilidade do protótipo SISU desenvolvido, foi conduzida uma sessão de teste com vários participantes que será agora descrita. 5.1 Participantes Na impossibilidade de se obter uma amostra de participantes significativa, composta unicamente por profissionais da área da saúde, recorreu-se a uma amostra heterógenea, onde estiveram envolvidos participantes de diferentes áreas profissionais. Nesta sessão de teste participaram 15 pessoas, a maior parte do sexo masculino (N=14) e com idades compreendidas entre os 22 e os 51 anos (M=28.33, DP=9.88). Já todos os participantes envolvidos tinham tido contacto, pelo menos uma vez, com um sistema de informação, mas apenas uma pequena parte (N=3) com sistemas de informação da área da saúde. 81 5.2 Procedimento A realização de cada teste seguiu um planeamento previamente estruturado, garantindo que todos os sujeitos do teste seriam submetidos às mesmas condições, com o objetivo de se obter um conjunto de respostas consistente. O plano de testes foi composto por diversas fases, sendo iniciado com um pequeno briefing, onde era dado a conhecer aos participantes todo o desenrolar da sessão. Neste pequeno briefing, eram também explicados alguns dos conceitos mais importantes envolvidos no sistema, nomedamente quais as entidades envolvidas e como se relacionam, sendo também explicada a estrutura adotada para os relatórios clínicos. Após o briefing, era solicitado aos participantes que cumprissem um conjunto de 8 tarefas no sistema, seguindo um enunciado. Estas tarefas incluíam o uso e interação com as funcionalidades mais importantes de todo o sistema, desde as funcionalidades de administração até às funcionalidades básicas de um clínico. Para finalizar a sessão, após a realização das tarefas, era solicitado a cada participante que respondesse a um questionário, de forma a avaliar o grau de usabilidade do sistema. 5.3 Questionário - System Usability Scale Para avaliar o grau de usabilidade do sistema, com base nos participantes dos testes, foi utilizado o questionário System Usability Scale. Este questionário foi originalmente criado por John Brooke em 1986 e permite avaliar uma grande variedade de produtos e serviços, incluindo websites e aplicações. Este questionário consiste em 10 afirmações, sendo solicitado ao inquirido o seu grau de concordância com cada afirmação. O inquirido tem 5 opções de resposta, seguindo a escala de Likert, desde “Discordar Fortemente” até “Concordar Fortemente”. O questionário possui afirmações de carácter positivo alternadas com afirmações de carácter negativo, para evitar respostas inconscientemente adulteradas por parte dos participantes e assim os obrigar a refletir e a pensar quando realmente concordam ou discordam com as afirmações [Bro13]. 5.4 Análise dos Resultados Os resultados apresentados na Tabela 3 demonstram a distribuição dos resultados do questionário colocado aos 15 participantes. 82 Segundo Jeff Sauro [Sau11], o SUS score para cada participante deve ser calculado da seguinte forma:  Para as afirmações ímpares (de carácter positivo): subtrair 1 à resposta do participante.  Para as afirmações pares (de carácter negativo): subtrair a resposta do participante a 5.  Isto coloca todas as respostas numa escala de 0 a 4 (sendo 4 a resposta mais positiva).  Somar todos os valores obtidos e multiplicar por 2.5. Assim, é possível calcular o SUS score para o protótipo do SISU desenvolvido, utilizando os valores médios de concordância obtidos para cada afirmação e efetuando os cálculos sugeridos por Jeff Sauro: SUS score para o protótipo desenvolvido = 67.5 Segundo os estudos de Jeff Sauro, o SUS score de um sistema com um nível médio de usabilidade situa-se nos 68 [Sau11]. Assim, pode-se concluir que o protótipo do SISU desenvolvido se encontra dentro dos padrões comuns de usabilidade. Este valor de usabilidade, dentro da média, pode ser explicado por comentários partilhados por alguns dos participantes, de forma espontânea, no decorrer da sessão de teste. Tabela 3. Distribuição dos resultados obtidos no questionário efetuado. 83 “Se não fosse o briefing, penso que me ia perder em algumas destas tarefas” (P4) “Depois de se perceber a estrutura base do sistema, até se torna fácil de utilizar” (P9) Estes comentários realçam a importância de existir algum tipo de suporte antes ou durante a utilização do sistema. Os comentários vão também ao encontro de alguns dos resultados obtidos. As afirmações Q4 e Q10 avaliam o nível de aprendizagem que o sistema requer [LS09] e são as duas afirmações de carácter negativo que possuem valor médio mais elevado. Fica assim revelada a existência de alguma inércia na fase inicial de interação com o sistema bem como a importância de algum suporte técnico, nomeadamente antes da primeira utilização. De realçar também a pontuação obtida mais elevada, numa afirmação de carácter positivo, Q1. Este valor bastante positivo indica que a maioria dos participantes gostou de utilizar o sistema e gostaria, eventualmente, de o utilizar de forma mais frequente, como por exemplo, na sua atividade profissional. 5.5 Considerações Finais Todas as sessões de testes foram realizadas conforme o procedimento descrito na secção 5.1.2. Os participantes mostraram-se todos particularmente interessados e atentos no pequeno briefing inicial, fator que se relevou importante para o bom desempenho na realização das tarefas pedidas na fase seguinte. Na última fase das sessões de teste, o questionário foi bem interpretado por todos os participantes pelo que foi possível reunir um conjunto de respostas consistentes e passar então à análises dos resultados obtidos. O questionário SUS revelou que o protótipo do SISU desenvolvido se encontra dentro dos padrões comuns de usabilidade. 90 Para realizar as 5 tarefas que se seguem, termine a sessão da conta com permissões de administrador e inice nova sessão com as seguintes credenciais duma conta de um clínico especializado:  Nome de utilizador: [email protected]  Password: sentryuser Tarefa 4 Envie uma Mensagem para um grupo de clínicos. Tarefa 5 Submeta um Post num dos fóruns a que tem acesso. Tarefa 6 Efetue uma Pesquisa Personalizada, restringindo uma variável à sua escolha. Nota extra: o resultado obtido estará em formato json, não se assuste caso obtenha como resultado da pesquisa uma estranha linha com parêntesis e chavetas. Tarefa 7 Visualize a Ficha Clínica de um Paciente. Tarefa 8 Edite os Dados Clínicos de um relatório clínico de um paciente. Nota extra: lembre-se que poderá não ter permissão para editar todos os dados de um relatório clínico. ==================== FIM DE ENUNCIADO ==================== 91 Anexo B Questionário do Teste de Usabilidade 92