Relatório de Projecto Data Mining associado ao Diagnóstico Médico

Transcrição

1

2 ii

3 Relatório de Projecto Data Mining associado ao Diagnóstico Médico José Miguel Bernardo Cordeiro Instituto Politécnico de Bragança Escola Superior de Tecnologia e Gestão Bragança Engenharia Informática 3 o Ano a20186@alunos.ipb.pt Setembro 2011

4 A Escola Superior de Tecnologia e Gestão não se responsabiliza pelas opiniões expressas neste relatório. ii

5 Aprovações Certifico que li este relatório e que na minha opinião, é adequado no seu conteúdo e forma como demonstrador do trabalho desenvolvido no âmbito da disciplina de Projecto. Prof. Doutor Paulo Matos Orientador Certifico que li este relatório e que na minha opinião, é adequado no seu conteúdo e forma como demonstrador do trabalho desenvolvido no âmbito da disciplina de Projecto. Prof. Arguente Aceite para avaliação da unidade curricular de Projecto iii

6 iv

7 Abstract Having access to accurate and organized is an asset for any decision process. This project stems from a concern shown by the stakeholders of the problem domain, healthcare professionals, to achieve greater efficiency in the use of antibiotics. It is thought that the medic history of the patients can be used to help choose the more appropriate antibiotic to prescribe in each case. This project is therefore to explore the existing data, including using Data-Mining techniques to extract hidden or not easily identifiable information from the data, in order to ascertain the feasibility and usefulness of such data for the problem at hand.

8 vi

9 Resumo Ter a informação correcta e organizada é uma mais-valia para qualquer processo de decisão. Este projecto resulta de uma preocupação demonstrada por parte dos próprios intervenientes do domínio do problema, os profissionais de saúde, no sentido de obter uma maior eficácia na utilização de antibióticos. Pensa-se que a informação existente sobre o histórico dos vários utentes possa ser utilizada para identificar o antibiótico a receitar mais adequado a cada caso. Este projecto tem assim por objectivo explorar os dados existentes, nomeadamente com recurso a técnicas de Data-Mining no sentido de extrair informação que à partida não é facilmente identificável, no sentido de averiguar a viabilidade e utilidade desses dados para o problema em questão. Palavras-chave: Data-Mining, Extracção de conhecimento.

10 viii

11 Agradecimentos Durante o último ano em que estive envolvido neste projecto de investigação e análise desta tecnologia, tive a oportunidade de contar com o apoio de várias pessoas que contribuíram para a realização deste projecto. Em primeiro lugar, quero agradecer ao meu orientador, Professor Paulo Matos, pela ajuda e pela sua visão simples e crítica de ver os problemas para a realização deste projecto. Também quero agradecer à minha família e amigos que estiveram sempre perto de mim e que me apoiaram durante o difícil e duro percurso que é a licenciatura. Também quero agradecer à comunidade que contribuiu para a criação do LATEX que é uma ferramenta espantosa de criar texto saindo este relatório através dessa ferramenta. E por fim, quero agradecer ao Instituto Politécnico de Bragança por me ter acolhido e me ter proporcionado dos 3 melhores anos da minha vida. A todos, os meus maiores agradecimentos!

12 x

13 Lista de abreviaturas BD Base de Dados BIDS Business Intelligence Development Studio CSV Comma separated value DM Data-Mining GUI Graphical User Interface IDE Integrated Development Environment JDBC Java Database Connectivity MD Mineração de Dados SGBD Sistema de Gestão de Base de Dados SQL - Structured Query Language YACC Yet Another Compiler Compiler

14 xii

15 Índice 1 Introdução e Objectivos Introdução Objectivo do projecto Estrutura do documento Conceitos Data-Mining Tipos de abordagem Classificação Clustering (ou Segmentação) Associação Regressão Previsão Análise Sequencial Análise de desvio Ferramentas utilizadas Weka MySQL NetBeans Outras ferramentas Data Mining existentes BIDS (comercial) Tanagra (gratuíto e de código aberto) Implementação Descrição do Dataset Análise do problema Formulação do processo de mineração Problemas resultantes do modelo de mineração Decisões para a resolução dos problemas Aplicação do Algoritmo de Data Mining xiii

16 4.5 Como gerar resultados através do Weka Síntese dos resultados Análise crítica Conclusões Análise crítica Trabalho Futuro A Código 39 A.1 SQL A.2 Rotina para geração dos ficheiros CSV xiv

17 Lista de Figuras 2.1 Àrvore de decisão GUI do Weka Ave Weka inspirada no programa de MD Logo MySQL Logo do IDE NetBeans Logo do BIDS Logo Tanagra Imagem do dataset original montada numa BD Exemplo do dataset a criar para o modelo de mineração Ligações da tabela da BD Resultado da simplificação da tabela principal Resultados do valor da Sensibilidade Resultado da combinação antibiótico/microorganismo e vice-versa Resultado de combinações repetidas Representação do algoritmo k-means Escolha do método clustering e do algoritmo Escolha dos parâmetros do algoritmo k-means Começar a gerar resultados Resultados Exemplo Resultados Exemplo Resultados Exemplo Resultados Exemplo xv

18 xvi

19 Capítulo 1 Introdução e Objectivos 1.1 Introdução O evoluir da informática e dos meios de comunicação potenciou o crescimento da sociedade da informação. O que era outrora desprezado pelo facto de ser inconsistente, redundante, disperso, de pouca utilidade, deu origem a informação estruturada, classificada e de uma enorme utilidade e influência para a sociedade em geral. Hoje em dia sabe-se o valor real dessa informação, que condiciona tudo e todos, desde a economia à política. Ter informação é um trunfo, uma mais valia, uma vantagem concorrencial. É assim natural o aparecimento exponencial de fontes de informação, cada vez com dados de maior qualidade e em maior quantidade. Percebeu-se inclusive que a prospecção dessas fontes de dados permitia obter informação, e até mesmo conhecimento, que à partida não seria previsível obter. É nesta realidade que surge este trabalho de projecto, que pretende tirar partido das tecnologias emergentes desta realidade, para aferir novas informações e mais conhecimento, neste caso, aplicado à área da saúde. Este projecto resulta de uma preocupação manifestada pelos próprios intervenientes do domínio do problema: os profissionais da saúde. Segundo estes, determinados microorganismos (vírus e bactérias) têm demonstrado uma enorme capacidade de adaptação que lhes permite ser imunes aos novos antibióticos, reduzindo o efeito destes ou chegando mesmo a torná-los obsoletos. O caso é de maior gravidade nos espaços de saúde pública, que são sistematicamente expostos a novas estirpes trazidas pelos utentes. Estes locais acabam por funcionar eles próprios como incubadoras e fontes indesejáveis de propagação desses mesmos vírus e bactérias. Ter informação actualizada sobre a manifestação destas estripes ou variantes, ou simplesmente identificar casos problemáticos de utentes que de alguma forma carregam consigo estes microorganismos, é fundamental para despoletar acções que permitam controlar a sua propagação. Trata-se de uma questão de saúde pública, merecedora da nossa maior atenção, pois como se diz na gíria "com a saúde não se brinca!". Um dos grandes desafios da medicina actual é garantir um controlo mais afinado da apli- 1

20 cação dos antibióticos. A sua utilização de forma desmedida como recurso para todos os males, que muitas vezes nem sequer tem em conta um diagnóstico preciso e o historial clínico do paciente, levou a que as bactérias e vírus se fossem adaptando, tornando-se mais resistentes ou mesmo imunes a esses antibióticos. Casos há, que já só com as soluções mais agressivas é que se consegue tratar os pacientes. Ter presente o historial clínico do paciente é muito importante para se receitar o antibiótico adequado, aquele que vai permitir curar o paciente sem no entanto recorrer a soluções mais agressivas, ou que devem ser salvaguardadas para casos mais graves, ou para outro tipo de diagnósticos. É também sabido que mesmo perante o mesmo diagnóstico, a reacção dos pacientes a um determinado antibiótico, nem sempre é igual. Novamente, o historial clínico tem um peso importante na compreensão deste fenómeno, mas também a própria fisionomia do paciente, entre outros elementos. 1.2 Objectivo do projecto O objectivo deste projecto é desenvolver um modelo de mineração de dados (MD) que permita caracterizar e agrupar os utentes segundo o seu historial de análises e a sua fisionomia. Esperase que este modelo possa posteriormente ser utilizado num sistema de apoio à decisão que permita identificar os antibióticos mais adequados a receitar para cada tipo de caso. 2

21 1.3 Estrutura do documento A estrutura deste relatório foi criada com o objectivo de que o leitor perceba o que se pretende, o que contém e o que se realizou ao longo projecto. O primeiro capítulo pretende enquadrar o leitor para o tema do projecto, mostrando a motivação deste, os objectivos e também a forma como o relatório de final de curso está estruturado. O segundo capítulo mostra os conceitos de MD e as abordagens genéricas deste tema. O terceiro capítulo fala das ferramentas utilizadas na elaboração deste projecto e de outras ferramentas que se poderiam utilizar. O quarto capítulo é sobre a implementação, onde está presente, a descrição do dataset; uma análise do problema; formulação do modelo de mineração; problemas resultantes do modelo de mineração; decisões para a resolução dos problemas, aplicação do algoritmo utilizado; síntese dos resultados e, por fim, uma análise crítica dos resultados obtidos. O quinto e último capítulo encontram-se as conclusões com uma análise crítica e possíveis trabalhos futuros. 3

22 4

23 Capítulo 2 Conceitos 2.1 Data-Mining Data-mining (DM) [11, 9, 23, 4, 13, 24], ou Mineração de Dados (MD), é o processo de explorar grandes quantidades de dados à procura de padrões e relações entre dados. Este processo permite encontrar informação valiosa só pelo facto de analisar dados. [1] O ser humano aprendeu com a observação de padrões, com a formulação de hipóteses e com a realização de testes para descobrir novas regras. Mas quando a quantidade de informação é de tal forma gigantesca um ser humano não consegue assimilar tantos conteúdos, pois a solução encontrada foi usar o computador para detectar relações novas e úteis. A ideia é contruir um programa que passe por bases de dados e procure padrões ou informação semelhante, para depois prever, classificar ou associar acertadamente dados que se poderão adicionar posteriormente. Poderá surgir dificuldades porque muitos padrões são banais, outros poderão ser coincidentes e os dados reais sejam imperfeitos, porque há sempre dados ilegíveis e falta dados, por isso, tudo que poderá ser descoberto, poderá não ser exacto. Os algoritmos precisam de ser capazes de lidar com os dados e extrair regularidades que não são exactas mas que poderão ser úteis mais tarde. Hoje em dia, a MD surge para ser aplicada para a pesquisa científica ou até para estimular os lucros de empresas. Um dos exemplos que se destaca, é o de uma empresa de seguros, que experimentou esta tecnologia e obteve resultados interessantes, em que os clientes que cancelavam os seus seguros de saúde eram aqueles que menos o usavam. Para não estarem a perder clientes iniciaram uma nova campanha, porque conquistar um novo cliente pode custar sete vezes mais do que manter um cliente antigo. Com outro cruzamento de dados, puderam verificar quais os clientes com maior hipótese de comprar um seguro para os carros, então fizeram novos contratos com clientes para ter ambos os seguros a um preço reduzido. Contudo, apesar da empresa ganhar menos com este novo método, o facto é que resultou, obtendo mais lucros graças a esta tecnologia. Outro exemplo a ter em conta e que ficou para a história, é o de uma empresa que pegou 5

24 na sua Data-Warehouse 1 e descobriu que às sextas-feiras, homens entre os 20 e 35 anos que compravam fraldas descartáveis, também compravam cerveja. A partir desta constatação, e por experiência, puseram os produtos lado a lado, sendo o resultado o previsto, ou seja, a venda de cerveja e fraldas descartáveis disparou. 1 - Uma Data-Warehouse é uma base dados construída com o propósito de integrar grandes quantidades de dados e facultar um acesso mais rápido e eficiente para efeitos de análise. 6

25 2.2 Tipos de abordagem Classificação Uma das abordagens mais utilizadas na resolução de problemas de MD, é a classificação [12, 17, 3]. Como o próprio nome deixa antever, a ideia é classificar elementos segundo métricas discretas que são previamente definidas. É o tipo de solução cuja aprendizagem é normalmente supervisionada, o que significa que, com base em exemplos, tenta-se construir um modelo que permita posteriormente efectuar a classificação dos elementos de entrada. Os modelos criados são normalmente do tipo árvores (de decisão) ou conjunto de regras. O algoritmo J48 (ou C4.5) permite obter uma árvore de decisão com base em informação previamente obtida (dataset, ou dados de uma base de dados, etc.). Temos como exemplo, a decisão de uma criança ir para a rua brincar. Aplicando o algoritmo, obtém-se a árvore de decisão na figura 2.1. Figura 2.1: Àrvore de decisão. Então a figura 2.1 mostra que: quando está nublado vai brincar. quando está sol e a humidade estiver: alta, não vai brincar. normal, vai brincar. quando está a chover: se houver vento, não vai brincar. se não houver vento, vai brincar. 7

26 2.2.2 Clustering (ou Segmentação) O método de clustering [7], com base num conjunto de objectos de dados, tenta identificar grupos onde os elementos sejam similares entre si. Os não similares ficam fora do cluster ou dentro de outro(s) cluster(s), porque um elemento pode ter várias afinidades com outros elementos de outros grupos. É um tipo de classificação não supervisionada, ou seja, o algoritmo tenta segmentar os elementos agrupando-os com a afinidade que têm. Para esta abordagem existem algoritmos como EM, K-means, etc Associação A associação [12, 22, 8] identifica e caracteriza ligações naturais que podem existir entre classes, com o objectivo de identificar associações relevantes entre elementos e definir regras que caracterizam essas associações para obter melhor informação. Esta técnica é umas das melhores técnicas de MD para descobrir informação ignorada. A ideia é identificar itens consistentes e verificar a sua ocorrência relativamente a outros itens Regressão A regressão [12] é semelhante à classificação mas aplicada a um domínio continuo, ou seja, não se pretende classificar segundo uma escala discreta, mas sobre uma escala contínua. Então, para um conjunto de entradas, pretende-se saber qual o valor que deverá corresponder ao valor de saída segundo uma abordagem genérica onde é possível utilizar técnicas de regressão linear, árvores de regressão ou redes neuronais. 8

27 2.2.5 Previsão A previsão [17, 12] visa identificar efeitos sazonais e tendências em séries de dados temporais. O que permite prever a evolução futura dessas séries, com base nos valores passados. É útil para identificar fenómenos tendenciais como estimar a evolução dos mercados financeiros, ou mesmo prever a evolução do consumo de um determinado bem ou serviço Análise Sequencial A análise sequêncial [12] é uma técnica que pretende identificar padrões comportamentais em séries de eventos designados por sequências. Esta, consegue perceber o percurso de ligações, operações que executa, que páginas consulta, entre outros, dos utilizadores num determinado site. Com base nesses padrões consegue determinar os percursos mais utilizados. É semelhante à previsão em que aqui entram valores discretos ou estados Análise de desvio A análise de desvio [12] identifica padrões comportamentais que raramente surgem, como por exemplo, identificar acessos ilegais ou não desejados a sites ou também o uso de determinados serviços que alguém não subscreveu. Podem ser aplicadas às árvores de decisão, redes neuronais ou mesmo técnicas de clustering. 9

28 10

29 Capítulo 3 Ferramentas utilizadas 3.1 Weka Weka [26, 15] é um software, feito em Java e livre, que agrega algoritmos que provém da área da inteligência artificial. Assim, faz com que o computador aprenda através do uso de um algoritmo dessa área. Este procede à análise dos dados fornecidos, recorrendo à técnica de MD tentanto encontrar padrões para gerar hipóteses e soluções. Figura 3.1: GUI do Weka. O Weka é uma boa ferramenta, mas tem um grande defeito, é que existe pouca documentação e o interface é bastante confuso e difícil de manusear. A título de curiosidade, o weka é uma ave neozelandesa que está em perigo de extinção (figura 3.2). É conhecida pela sua curiosidade e agressividade. Esta ave dá nome a uma vasta colecção de algoritmos de máquinas de conhecimento. O Weka contém as ferramentas necessárias para realizar transformações sobre os dados, tarefas de classificação, regressão, clustering, associação e visualização. Podendo também adicionar novas funcionalidades. Figura 3.2: Ave Weka inspirada no programa de MD. 11

30 3.2 MySQL MySQL [19, 21, 20] é um sistema de gestão de BD, que usa a linguagem SQL. Foi escrito em C e C++, para fazer o parser das queries usa o YACC. Este SGBD tem um grande sucesso pelo seu desempenho, estabilidade, por ser fácil de instalar e configurar, por não exigir grandes recursos, por existirem drivers para as principais plataformas de desenvolvimento (Java, PHP,.NET, etc), por haver versões para os principais sistemas operativos UNIX, Windows e Macintosh, mas principalmente porque é livre (baseado em GPL). É usado muitas vezes para suportar portais e aplicações web e, também, para aplicações locais. É neste momento proprietário da Oracle, mas antes passou pela Sun Microsystems. Figura 3.3: Logo MySQL. 12

31 3.3 NetBeans O NetBeans [25] é um IDE Integrated Development Environment - gratuito e de código aberto para programadores nas linguagens Java, C, C++, PHP, Groovy, Ruby, entre outras. Dado ser implementado em Java pode ser utilizado em qualquer sistema operativo para o qual já exista a Máquina Virtual do Java (JVM - Java Virtual Machine), o que actualmente abrange praticamente todas as plataformas computacionais. Pelo facto de ser uma aplicação de código aberto e por facultar soluções que permitem facilmente expandir as suas funcionalidades, o Netbeans disponibiliza um vasto conjunto de recursos para os programadores, capaz de suportar o desenvolvimento das mais diversas aplicações, como web sites, web services, aplicações para dispositivos móveis, aplicações stand-alone, aplicações distribuídas, etc. Como é comum nos IDE s mais evoluídos, o Netbeans faculta um editor com tecnologia intellisense e highlight, compiladores e interpretadores, depuradores de código para as linguagens já citadas, e muitos outros recursos que potenciam a produtividade de quem o utiliza. Figura 3.4: Logo do IDE NetBeans. 13

32 3.4 Outras ferramentas Data Mining existentes BIDS (comercial) Business Intelligence Development Studio (BIDS) [27, 5, 14] é um IDE da Microsoft que é parte integrante do SQL Server 2008 e que tem por base o Visual Studio 2008, parametrizado para facultar recursos especializados para o desenvolvimento de soluções de análise de dados e business intelligence 1. O SQL Server é um servidor de base de dados relacionais, mas não só, é também capaz de albergar Data-Warehouses, processos de integração de dados, processos de geração automática de relatórios, entre outros. Faculta directamente ou através do BIDS vários recursos para a análise de dados, designadamente por OLAP (On-line Analytical Processing) e por MD. Figura 3.5: Logo do BIDS. 1 - O business inteligence é o processo de organizar, analisar, partilhar e monitorizar as informações mais importantes para o trabalho final. 14

33 3.4.2 Tanagra (gratuíto e de código aberto) Tal como o Weka, o Tanagra [18, 28] é um software livre e de código aberto, para análise de dados, que inclui muitas soluções de MD, mas também de análise estatística. Este projecto vem suceder a outro (SIPINA) que implementa vários algoritmos de aprendizagem com interacção visual para construções de árvores de decisão. Este programa contém vários algoritmos de aprendizagem supervisionada, bem como algoritmos de aprendizagem não supervisionada para clustering, análise de desvio, etc. O principal objectivo do Tanagra é facultar aos investigadores e estudantes uma framework de suporte à investigação, que lhes permita testar os seus próprios algoritmos e compará-los com os já existentes. É também um software fácil de usar, dado que, permite descrever os modelos de mineração de forma gráfica e com recurso a uma interface desenvolvida propositadamente para este efeito. Figura 3.6: Logo Tanagra. 15

34 16

35 Capítulo 4 Implementação É importante compreender que este é um trabalho de investigação aplicada, que parte de uma hipótese e que essencialmente visa averiguar a viabilidade dessa hipótese, o que por si só se mostrou uma tarefa muito complexa. Mesmo a formulação dessa hipótese não foi um trabalho trivial. Pelas informações facultadas pelos profissionais da saúde era de acreditar haver um enorme potencial nos dados existentes nas unidades de saúde. Infelizmente, e apesar de haver muitos dados, a grande maioria são inacessíveis. Existe uma clara falta de abertura das entidades responsáveis pelos sistemas de informação instalados nas unidades de saúde. Acresce a isto, as normais preocupações sobre a privacidade dos dados. Mas talvez o pior seja mesmo o facto de não haver uma integração e total cobertura dos sistemas de informação. Do que resulta um conjunto de bases de dados independentes, redundantes, incoerentes e pouco úteis para efectivamente rastrear o percurso dos utentes em termos clínicos. Para complicar, uma parte significativa dos procedimentos clínicos não estão suportados pelos sistemas de informação (diagnóstico médico, confirmação dos efeitos dos tratamentos, etc). Pelo que foi muito moroso conseguir elementos concretos sobre os dados existentes. Quando se refere isto, não se está a falar de dados concretos e reais, mas apenas do tipo de dados existentes e do seu significado e utilidade. Só quando se teve acesso a esta informação, é que foi possível efectuar uma análise desses dados (entenda-se tipo de dados), para perceber o que se poderia fazer, nomeadamente no âmbito das preocupações manifestadas pelos profissionais de saúde. Contudo, a hipótese formulada foi aquela que se entendeu ser viável e de maior interesse para o domínio do problema. Mesmo sabendo de antemão que a obtenção de resultados concretos seria uma tarefa muito complexa. 17

36 4.1 Descrição do Dataset Na impossibilidade de se fazer uso de dados reais, criou-se um dataset que tem por base os campos existentes no laboratório de análises clínicas, mas com dados que apesar de representativos dessa realidade são fictícios. O dataset utilizado representa assim uma hipotética realidade dos registos existentes sobre as análises clínicas realizadas numa unidade hospitalar. Tentou-se dentro dos possíveis utilizar a mesma terminologia e os mesmos conceitos que são utilizados no mundo real. Cada registo do dataset representa a realização de uma análise de imunidade de um microorganismo a um antibiótico. Análise essa, que corresponde a uma de muitas que normalmente são solicitadas para um utente num dado momento da sua vida. Cada lote de análises requisitadas está associado a uma requisição. O microorganismo advém de uma amostra (sangue, urina, fezes, expectoração, etc.) recolhida do utente. Segunda a informação prestada, os dados existentes possuem os seguintes campos: NSF é o código de identificação do utente, neste caso é um código fictício; Data_Nasc representa a data de nascimento do utente; Data_Req representa a data solicitada da análise; Proveniencia identifica o local de onde foi efectuado o pedido da análise; Tipo_Exame identifica o tipo de exame solicitado; Microorganismos identifica o microorganismo para qual se vai verificar a imunidade; Antibiotico identifica o antibiótico utilizado na análise; Sensibilidade é o resultado da análise de imunidade do microorganismo ao antibiótico. O resultado poderá ser sensível, significa que o microorganismo é afectado pelo antibiótico, isto é, este faz efeito. Pode ser resistente, significa que para o utente e microorganismo em questão, o antibiótico já não faz efeito, isto é, na amostra em causa o microorganismo é imune ao antibiótico. E pode ser é indeterminado, o que significa que funcionou parcialmente, isto é, afectou parte da amostra mas não toda a amostra (sinal de que já há alguma imunidade por parte do microorganismo). Como era possível, o conceito de Data_Req foi substituído por um outro, o de Episodio, também utilizado neste contexto, mas mais útil para os objectivos deste projecto. Enquanto a data de requisição é uma representação de uma data, o conceito de episódio aqui utilizado funciona como um identificador relativo ao utente que faculta uma sequência temporal dos vários episódios de um utente. Normalmente, são solicitadas várias análises de cada vez, isto é, se o utente for hospitalizado o médico pode solicitar a realização de um conjunto de análises. 18

37 Cada conjunto de análises tem um número de episódio, que é sequencial para cada utente. A primeira vez que são solicitadas análises para um utente corresponde ao episódio um. Há ainda um segundo campo introduzido que é o ID e que serve para atribuir uma chave única a cada registo, mas que não tem qualquer significado especial para lá disto. Isto porque, com os campos base não é possível formar uma chave, mesmo que composta, que garanta a unicidade dos registos. Figura 4.1: Imagem do dataset original montada numa BD. 19

38 4.2 Análise do problema Com o modelo de dados disponibilizado, o passo seguinte foi perceber o que é que se poderia fazer com ele. Segundo este modelo, há um registo do histórico de análises efectuadas por cada paciente. Análises essas, que de alguma forma descrevem a sensibilidade do utente (mais concretamente dos microorganismos do utente) aos antibióticos. Sabe-se também que os resultados das análises são utilizados pelos médicos para decidirem que antibiótico receitar ao utente. Não foi possível obter dados que permitissem confirmar concretamente qual o antibiótico efectivamente receitado. Informação que teria certamente sido uma enorme mais-valia para os objectivos deste projecto. Também não há qualquer controlo directo sobre a eficácia da medicação receitada e muito menos registos informáticos. Os dados das análises clínicas, podem dar alguma informação sobre a eficácia dos antibióticos, isto porque, se resultar, o utente não volta tão cedo à unidade de saúde. Mas se a medicação falhar, o utente regressa e, o normal é, que sejam solicitadas novas análises. Assim, o facto de essas análises existirem, pode ser significativo da ineficácia da medicação. Partindo deste pressuposto e sabendo de antemão das potencialidades das tecnologias de mineração de dados, tentou-se dar alguma utilidade prática a estes dados. A hipótese formulada foi de que o registo das análises dos utentes poderia ser útil para averiguar a eficácia dos antibióticos. Se tal hipótese fosse verdade, a informação daí resultante seria certamente muito valiosa na escolha dos antibióticos a receitar. A prova desta hipótese passou por tentar obter grupos de utentes com um histórico semelhante. Cada grupo seria representativo de uma parte da realidade no que diz respeito à evolução de determinados microorganismos e da sua imunidade aos antibióticos, considerando nesta equação elementos característicos dos próprios utentes (por exemplo: idade e sexo). Rapidamente se percebeu que a solução a utilizar para fazer prova da hipótese formulada, passava por utilizar soluções de clustering/segmentação, o que permitiria criar os tais grupos de utentes. 20

39 4.3 Formulação do processo de mineração Para representar o historial de análises clínicas de cada utente, havia que sintetizar toda a informação do utente num único registo. Esse registo deveria conter informação da fisionomia do utente e do dito histórico de análises, reflectindo o número, sequência e tipo das análises realizadas, bem como os respectivos resultados. Ou seja, cada registo para além da dita informação fisionómica do utente deve conter a descrição dos vários episódios, em que para cada episódio se identificam as várias triplas formadas por microorganismo versus antibiótico versus resultado (sensibilidade). A ideia de vectorizar vem na utilização da abordagem clustering em que se pretende criar grupos. Para criar esses grupos é preciso ter o historial completo do utente num único registo. Assim o algoritmo (de clustering) vai comparar os campos das combinações possíveis e comparar resultados. Aqueles que tenham resultados semelhantes da combinação episódio, microorganismo e antibiótico, irão para o mesmo cluster. A figura 4.2 mostra um exemplo do dataset construído para o modelo de mineração. Para além do número de identificação do utente (NSF), se existisse no dataset original 2 episódios, 2 microorganismos e 3 antibióicos, neste novo dataset haveria 12 combinações possíveis entre episódio, microorganismo e antibiótico. Figura 4.2: Exemplo do dataset a criar para o modelo de mineração. 21

40 4.3.1 Problemas resultantes do modelo de mineração Para ter a tabela 4.2 como na figura é preciso reduzir bastante os dados de maneira a que no fim a BD tenha a combinação episódio, microorganismo e antibiótico que resulte em poucas colunas. Segundo apurado, haveria utentes com 33 episódios (número que poderia naturalmente aumentar, o número de microorganismos era de 116 e o número de antibióticos de 87, logo, o resultado das combinações possíveis destes números é (este seria o número de colunas de um novo dataset). Como se pode verificar o número é demasiado elevado, o que levaria muito tempo de processamento e memória para gerar uma tabela deste tipo, para mais tarde aplicar o algoritmo de MD, para posteriormente verificar os resultados obtidos. Convém acrescentar que a grande maioria das BD existentes no mercado dificilmente comporta mais do que alguns poucos milhares de campo (<4000). Foi assim imprescindível tentar reduzir o numero de combinações, tarefa que se mostrou muito complexa e que requereu uma análise bem mais detalhada dos dados e muito bom senso. Foi também logisticamente complexo, pois requereu solicitar a execução de muitas queries sobre a BD original (uma vez que não se tinha acesso directo aos dados) Decisões para a resolução dos problemas Antes de começar a redução de antibióticos, episódios ou microorganismos deve-se simplificar o mais possível a BD. O campo NSF e data de nascimento pertencem sempre a um mesmo utente, como tal, esses dois campos passaram para uma outra tabela e na tabela original retirou-se a Data de Nascimento mantendo o campo NSF como chave estrangeira ligada à nova tabela onde NSF é a chave primária. O mesmo, também deve ser aplicado para os campos Microorganismo e Antibiotico, para facilitar a criação de resultados e obter uma melhor eficiência. Criou-se um ID (identificador) para cada microorganismo e para cada antibiótico, e na tabela principal em vez do nome passou a ter o número do seu ID (de Microorganismo e Antibiótico) como chave estrangeira das tabelas antibiotico e microorganismo onde contêm o ID e o respectivo Nome. Ao ter feito esta uniformização permitiu que, mais tarde, a aplicação dos algoritmos de MD seja mais rápida e eficiente, porque um computador consegue processar mais facilmente números do que strings (identificadores iniciais dos microorganismos e antibióticos). Caso seja necessário verificar o nome do antibiótico ou microorganismo que o número representa, basta fazer um inner join entre a tabela principal e a tabela microorganismo ou antibiotico. Assim sendo, obtém-se a tabela final com o aspecto da figura 4.4, ficando assim, concluído o processo que contém apenas os dados necessários. A partir deste momento, começa a redução de dados desnecessários ou menos relevantes para a construção de um novo dataset para aplicar um dos algoritmos de segmentação. Com a seguinte query: select t0.cnt, COUNT(*) from 22

41 Figura 4.3: Ligações da tabela da BD. Figura 4.4: Resultado da simplificação da tabela principal. (select NSF, MAX(EPISODIO) as cnt from dbo.analiseskf2 group by nsf) as t0 group by t0.cnt order by t0.cnt como se pode verificar a partir do episódio 9 existem poucos resultados, isto porque, existe na BD poucos utentes com os números de episódios superior a esse número. Tendo em conta esta informação, analisou-se o que aconteceria caso se desprezassem os utentes com mais do que 9 episódios. Ao passar de um máximo de 33 episódios para 9, permitiu reduzir significativamente o número de combinações entre episódios, microorganismos e antibióticos. Uma vez que interessavam apenas as situações em que efectivamente havia um historial, entendeu-se também desprezar todos os utentes com 2 ou menos episódios. Isto não permite reduzir directamente o número de combinações, dado que quem tem mais do que 2 episódios também tem que ter no seu registo, informação respeitante aos dois primeiros episódios. Mas permitiu reduzir efectivamente, eliminando microorganismos e antibióticos que apenas ocorriam em utentes com um ou dois episódios. 23

42 Com estas simplificações, conseguiu-se reduzir o número de episódios para 9, o número de microorganismos para 85 e o número de antibiótico para 75. Do que resultam combinações, em oposição às mais de 300 mil iniciais. Após algum tempo a verificar a BD, foi possível perceber que havia registos com outros valores possíveis para a sensibilidade para lá dos inicialmente previstos. Ao fazer select distinct(sensibilidade) from analises apresenta os resultados, como está presente na figura 4.5, S, R, I, N, P, e segundo informações obtidas por parte de entidades ligadas a este ramo os resultados que interessam são os S, R e I. Pelo que se descartam os outros resultados de modo a que a BD fique mais leve. Figura 4.5: Resultados do valor da Sensibilidade. Ao apagar os resultados da Sensibilidade verificou-se que diminuiu o número de microorganismos e o número de antibióticos descendo estes para 57 e 68 unidades, respectivamente. Assim sendo neste momento o número de campos possíveis é de O próximo passo foi apagar combinações de microorganismos/antibióticos e vice-versa, que sejam muito pouco representativos com objectivo de reduzir ainda mais o número de microorganismos e antibióticos, de modo a que, também se possa reduzir o número de campos do novo dataset. Para tal usou-se as queries que estão abaixo da figura 4.6, e verificou-se possíveis combinações a apagar a fim de reduzir o número de antibióticos e de microorganismos. SELECT COD_ANTIBIO, t1.cod_micro, count( * ), t1.tm FROM dbo.analiseskf3 AS t2 INNER JOIN ( SELECT COD_MICRO, count( COD_MICRO ) AS tm FROM dbo.analiseskf3 GROUP BY COD_MICRO ) AS t1 ON t1.cod_micro = t2.cod_micro GROUP BY COD_ANTIBIO, t1.cod_micro, t1.tm order by t1.tm,t1.cod_micro 24

43 Figura 4.6: Resultado da combinação antibiótico/microorganismo e vice-versa. SELECT COD_MICRO, t1.cod_antibio, count( * ), t1.ta FROM dbo.analiseskf3 AS t2 INNER JOIN ( SELECT COD_ANTIBIO, count( COD_ANTIBIO) AS ta FROM dbo.analiseskf3 GROUP BY COD_ANTIBIO ) AS t1 ON t1.cod_antibio = t2.cod_antibio GROUP BY COD_MICRO, t1.cod_antibio, t1.ta order by t1.ta, t1.cod_antibio Então relativamente à figura 4.6 está ordenada pelo tm, que significa total de microorganismos e pelo COD_MICRO que é o código do microorganismo. Então o resultado desta query significa que a combinação de um antibiótico para um dado microorganismo aparece o número de vezes que está representado na terceira coluna. A última coluna representa o total de microorganismos. Como a tarefa é eliminar o número máximo de microorganismos e antibióticos possível, o ideal é pegar nestas duas colunas e verificar se realmente se pode eliminar. Por exemplo, relativamente à primeira linha podemos verificar que o resultado da query obteve-se o antibiótico 139 combinado com o microorganismo 203, a combinação de ambos aparece na BD apenas uma vez e o total de registos em que o microorganismo aparece é de 5, por isso, aqui está um dos potenciais microorganismos que pode desaparecer. Na mesma figura está presente o oposto, ou seja, em vez de ser a combinação antibiótico /microorganismo é a combinação microorganismo/antibiótico, em que na primeira e segunda colunas está representado o código do microorganismo e o código do antibiótico, respectiva- 25

44 mente. A 3 a coluna é o número de vezes que a combinação aparece na BD e a última coluna representa o número de vezes que o antibiótico aparece. Na primeira linha aparece um potencial antibiótico a eliminar, visto que na BD inteira apenas é utilizado uma única vez. Depois de definir um número mínimo de antibióticos e microorganismos (pelos menos 10) optou-se por apagar todos aqueles inferiores a esse número. Com esta simplificação ficou-se reduzido a 55 microorganismos, 60 Antibióticos e 9 episódios o que dá um total de campos. Numa fase avançada deste processo de redução, e como mostra a figura 4.7 constatou-se que para uma combinação utente, episódio, microorganismo e antibiótico poderia haver mais do que um resultado. Isto significaria voltar a duplicar o número de combinações (considerando que no máximo poderia haver dois resultados), pelo que se entendeu considerar o primeiro registo e desprezar os restante. Opção esta também sustentada pelo facto de que quando havia mais do que um resultado, o valor era na maioria das situações igual (segundo os entendidos, servia de confirmação de resultados). Figura 4.7: Resultado de combinações repetidas. Detectou-se também combinações que não continham resultados. Pelo que ao subtrair estes registos foi possível reduzir o número de combinações para um pouco mais de Como mesmo assim, não era possível tratar estes resultados a partir de uma BD (limite do MySQL é de pouco mais de 1000 colunas), optou-se por utilizar um formato textual para representar os dados. Optou-se por gerar um ficheiro csv com os resultados da sensibilidade vectorizados, no anexo A.2 está o código que gerou o ficheiro. Foi escolhido este formato por ser o mais simples de construir, pois o Weka é capaz de converter um ficheiro csv para um ficheiro com a extensão que o programa normalmente usa (arff ). Finalmente o último passo é correr no Weka e verificar os resultados. 26

45 4.4 Aplicação do Algoritmo de Data Mining O algoritmo k-means [6, 2, 16] usa um método de agrupamento não-supervisionado, consiste num procedimento em que um dado número de clusters, previamente determinado, calcula os pontos que representam os centros destes clusters sendo espalhados no conjunto de respostas e movidos até alcançar um equilíbrio estático. Em seguida, procede a uma divisão de todos os casos obtidos pelos k grupos estabelecidos previamente e a melhor partição de n casos será aquela que optimize o critério escolhido. Este procedimento inicia-se ao usar os valores dos primeiros k casos como estimativas. Os casos iniciais são formados através da designação de cada caso ao cluster mais próximo. Sempre que se incluir um ou mais casos é preciso recalcular as médias e alterar as posições do cluster até que não haja mais alterações nos cálculos das médias. Figura 4.8: Representação do algoritmo k-means. Este é um dos algoritmos mais simples para o método de clustering, um dos mais avançados foi feito com base no k-means que é o EM (Expected Maximization). Pontos fracos deste algoritmo: Quando o número de dados é pequeno, o grupo inicial determina o cluster; O número de clusters tem que ser previamente definido; Sensível aos dados iniciais, mesmo se trocar a ordem dos atributos poderá definir um cluster diferente. [10] 27

46 4.5 Como gerar resultados através do Weka Ao ter o dataset carregado no Weka pode-se escolher tratar os dados ou usar uma das abordagens. Como os dados já estão tratados, escolhe-se o separador cluster e de imediato escolhe-se o algoritmo que se pretende usar (através do botão choose, como mostra a figura 4.9). Figura 4.9: Escolha do método clustering e do algoritmo. O algoritmo escolhido foi o k-means, como tal é preciso clicar nesse algoritmo para ficar seleccionado. Para aceder às opções deste algoritmo, é necessário clicar na caixa de texto onde tem o seu nome, aparecendo assim, um menu com opções, nas quais é possível escolher quantos clusters se pretendem criar, o número de seeds, entre outros (tal como mostra a figura 4.10). Figura 4.10: Escolha dos parâmetros do algoritmo k-means. Escolhido o número de clusters é necessário escolher o tipo de acção: treino; usar um ficheiro de treino sendo que os dados do dataset ficam a ser avaliados; 28

47 divisão de uma percentagem do dataset para treino e para avaliação. Para começar clica-se em Start (como é visível na figura 4.11) e na caixa de texto ao lado aparecerão os resultados momentos depois. Figura 4.11: Começar a gerar resultados 29

48 4.6 Síntese dos resultados Exemplo 1 Na figura 4.12 estão representados 10 clusters (definido nos parâmetros) e a quantidade de utentes que foi atribuída a cada grupo, num universo de 269 utentes. No primeiro cluster (cluster 0) apenas foi atribuído um utente o que corresponde a aproximadamente 0%, o mesmo acontece com os clusters 4 e 6; quanto ao cluster 1 foram-lhe atribuídos 22 utentes que em termos percentuais corresponde a 8%; em relação ao cluster 2 foram-lhe atribuídos 34 utentes o que corresponde a 13%; o cluster 3 apenas foi-lhe atribuído 4 utentes, o que equivale a 1% ; o cluster 5 obteve 10 utentes que corresponde a 4%; já o cluster 7 obteve 183 utentes que corresponde a 68%; por fim, os clusters 8 e 9 obtiveram 2 e 11 utentes o que corresponde a 1% e 4%, respectivamente. Figura 4.12: Resultados Exemplo 1. Exemplo 2 Este exemplo foi elaborado de uma maneira diferente do exemplo anterior, desta vez em vez de apenas treinar, também se atribuíu uma percentagem a casos reais, como apresenta a figura Portanto, 66% do dataset foi usado para treino e os restantes 34% (91 utentes) foram usados para serem atribuídos a clusters. Em termos de resultados podemos verificar quantos utentes foram atribuídas a cada um dos grupos (clusters). Aos clusters 0, 1, 3, 6 e 8 não foram atribuídos utentes. Para o cluster 2 foram atribuídos 14 utentes o que corresponde a 15%; para o cluster 4 foram atribuídos 6 utentes que equivale a 7%; nos clusters 5 e 7 foram atribuídos 3 e 1 utentes o que corresponde a 3 e 1%, respectivamente; por fim, no cluster 9 foram atribuídos 60 utentes, ou seja, 74%. 30

49 Figura 4.13: Resultados Exemplo 2. Exemplo 3 Na figura 4.14 estão representados 20 clusters. Nos clusters 0, 4, 15 e 19 contém apenas 1 utente o que corresponde a aproximadamente a 0%; no cluster 1 existem 16 utentes que em termos percentuais corresponde a 6%; no cluster 2, 31 utentes equivale a 12%; os clusters 3 e 9 contêm 9 utentes e que corresponde a 3%; o cluster 5 possui 25 utentes que equivale a 9%; os clusters 6 e 17 contêm apenas 2 utentes que corresponde a 1%; ao cluster 7 foi atribuído 20 utentes que equivale a 7%; no cluster 8 existem 6 utentes que corresponde a 2%; os clusters 10 e 11 possuem 3 utentes que equivale a 3%; o cluster 12 é o que possui maior número de utentes com 102 que corresponde a 38%; nos clusters 14 e 16 contêm 7 utentes que equivale a 3%; finalmente, o cluster 18 com 4 utentes que corresponde a 1%. 31