AUTOMATIZAÇÃO DO PROCESSO DE MAPEAMENTO DE...

UNIVERSIDADE ESTADUAL DO OESTE DO PARANÁ

CAMPUS DE FOZ DO IGUAÇU

PROGRAMA DE PÓS-GRADUAÇÃO EMENGENHARIA DE SISTEMAS DINÂMICOS E ENERGÉTICOS

DISSERTAÇÃO DE MESTRADO

AUTOMATIZAÇÃO DO PROCESSO DE MAPEAMENTODE LAUDOS MÉDICOS PARA UMA REPRESENTAÇÃO

ESTRUTURADA

JEFFERSON TALES OLIVA

FOZ DO IGUAÇU2014

Jefferson Tales Oliva

Automatização do Processo de Mapeamento de LaudosMédicos para uma Representação Estruturada

Dissertação de Mestrado apresentada ao Programa dePós-Graduação em Engenharia de Sistemas Dinâmi-cos e Energéticos como parte dos requisitos para ob-tenção do título de Mestre em Engenharia de Siste-mas Dinâmicos e Energéticos. Área de concentração:Sistemas Dinâmicos e Energéticos.

Orientador: Huei Diana LeeCo-orientador: Wu Feng ChungCo-orientador: Cláudio Saddy Rodrigues Coy

Foz do Iguaçu2014

FICHA CATALOGRÁFICA

O48 Oliva, Jefferson TalesAutomatização do processo de mapeamento de laudos médicos para uma

representação estruturada / Jefferson Tales Oliva. - Foz do Iguaçu, 2014.152 p.: tab.: graf.

Orientadora: Profa. Dra. Huei Diana Lee.Co-orientador: Prof. Dr. Wu Feng Chung.Co-orientador: Prof. Cláudio Saddy Rodrigues Coy.Dissertação (Mestrado) - Programa de Pós-Graduação em Engenharia de

Sistemas Dinâmicos e Energéticos - Universidade Estadual do Oeste do Paraná.

1. Engenharia de software. 2. Bioinformática. 3. Laudo médico. 4.Ontologia. 5. Endoscopia digestiva. 6. Sistema Computacional Colaborativo.I. Título.

CDU 004.41004.75:61

Miriam Fenner R. Lucas - CRB/9:268 - Unioeste - Campus de Foz do Iguaçu

ii

Resumo

Na área da saúde, grandes quantidades de dados provenientes de diversas fontes, como exames clínicos e de pro-cedimentos, são armazenadas em bases de dados de hospitais e clínicas médicas. As características observadasnesses exames são descritas em laudos médicos textuais. Esses laudos constituem ferramenta indispensável paraprofissionais de qualquer especialidade médica para a manutenção do histórico clínico de pacientes. Os dados con-tidos nesses laudos podem ser analisados, de modo mais completo, através de recursos computacionais, como oprocesso de Mineração de Dados apoiado por técnicas de Inteligência Computacional. No entanto, para a aplicaçãodesse processo, é imprescindível que os dados estejam representados em formato estruturado, como as Bases deDados Computacionais. Nesse sentido, no Laboratório de Bioinformática da Universidade Estadual do Paraná emparceria com o Serviço de Coloproctologia da Faculdade de Ciências Médicas da Universidade Estadual de Cam-pinas foi desenvolvido o Processo de Mapeamento de Laudos Médicos (PMLM) por ontologias com o propósito deprover apoio para a transformação de laudos médicos textuais não estruturados em uma representação estruturada.Entretanto, as técnicas empregadas no PMLM devem ser executadas separadamente e manualmente por meio deinstruções computacionais, dificultando o seu uso por profissionais que não sejam da área computacional. Assim,o objetivo deste trabalho consiste em automatizar e otimizar o PMLM por ontologias mediante a integração desuas técnicas de processamento de textos em uma ferramenta computacional. Para isso, foi construído um SistemaComputacional Colaborativo (SCC) utilizando o modelo de desenvolvimento por prototipagem, que é aplicadode cinco etapas: comunicação; plano rápido; modelagem; construção do protótipo; e avaliação e feedback. Essesistema computacional foi avaliado em conjunto com especialistas do domínio, os quais constataram que o SCCatende às especificações determinadas e apresenta-se de grande valia para a extração e o estudo de padrões quepodem ser encontrados em textos médicos. O SCC foi também submetido a uma avaliação experimental, por meioda aplicação do PMLM automatizado em um conjunto de 100 laudos médicos textuais artificiais que simulamdescrições de exames de Endoscopia Digestiva Alta (EDA), apresentando bons resultados. Desse modo, com oPMLM por ontologias automatizado, implementado no SCC, é possível a realização de estudos mais completos edetalhados, contribuindo com a geração de novos conhecimentos.

Palavras-chave: Laudo Médico, Ontologia, Engenharia de Software, Endoscopia Digestiva Alta, Sistema Com-putacional Colaborativo.

v

Abstract

In the health area, large amounts of data from different sources, such as clinical examinations and procedures, arestored in hospitals and medical clinics databases. Characteristics observed in these examinations and proceduresare described in textual medical reports. These findings are indispensable for professionals of any medical speci-alty, as they are used to maintain the clinical history of the patients. The data contained in these reports can beanalyzed, in a more complete manner, through the use of computational resources, such as the Data Mining processsupported by computational intelligence techniques. However, for the application of such process, it is essentialthat the data is represented in a structured format, as Computational Data Bases. In this sense, the Laboratory ofBioinformatics from the West Paraná State University in partnership with the Coloproctology Service of the Fa-culty of Medical Sciences from the State University of Campinas, developed the Mapping Medical Digital FindingsProcess (PMLM) using ontologies with the aim of providing support for the transformation of unstructured textualmedical reports into a structured representation. Nevertheless, the techniques employed in PMLM must be perfor-med manually and separately by means of computer instructions, hampering its use by professionals who are notfrom the computational area. The objective of this work is to automate and optimize PMLM using ontologies byintegrating its preprocessing methods in a computational tool. For this purpose, a Collaborative Computer System(SCC) was built using the prototyping development model, which is applied in five stages: communication, fastplan, modeling, prototype construction, and evaluation and feedback. The developed computational system wasevaluated in conjunction with domain experts, confirming that SCC meets the required specifications and presentsa great value for the extraction and the study of patterns that may be discovered in medical findings. SCC was alsoevaluated experimentally, using a set of 100 artificial medical reports that simulate the Upper Digestive Endoscopy(EDA), showing good results. Thus, the automated PMLM using ontologies, implemented in the SCC, enables theperformance of more complete and detailed studies, contributing to the generation of new knowledge.

Keywords: Medical Findings, Ontology, Software Engineering, Upper Digestive Endoscopy, Collaborative Com-putational System.

vi

vii

Aos meus pais,Carmem e Ilia.

Aos meus orientadores,Huei e Wu.

À minha noiva e futura esposa,Danieli.

Ao meu irmão (in memoriam),Ivo.

Agradecimentos

Ao longo dessa árdua caminhada, várias pessoas, de alguma forma, fizeram parte dessetrajeto e proporcionaram momentos de alegria, bem como ajudaram a superar os momentosdifíceis e contribuíam com a minha formação pessoal e profissional. Nesse sentido, é difícil euexpressar por meio de palavras a minha gratidão a essas pessoas que ajudaram diretamente eindiretamente. Desse modo, a seguir são descritos meus sinceros agradecimentos e reconheci-mento pelas contribuições recebidas nesta minha fase de vida e acadêmica.

À toda minha família, pelo incentivo na minha trajetória para a minha formação.

Aos meus amados pais, Carmem e Ilia, pelo amor, dedicação e educação incondicionais.Pelo apoio e incentivo para lutar pela realização de todos os meus sonhos pessoais e profissio-nais. Por sempre acreditarem na minha capacidade em superar todos os obstáculos na vida.

Ao meu irmão Ivo (in memoriam), pelo carinho, incentivo e sempre estar preocupado como meu bem estar. Também, por termos compartilhados vários bons momentos juntos. Apesarde não estar entre nós, sempre carregarei comigo as nossas boas lembranças como motivação eamenização da saudade e da dor de sua perda.

Às minhas avós, Benedita e Vitalina pelos "mimos", carinho e apoio para a realização dosmeus objetivos de vida.

À minha amada noiva e futura esposa, Danieli, pela compreensão dos vários momentosque não podemos passar juntos nessa trajetória acadêmica, bem como pelo apoio, incentivoe amor incondicional. Também gostaria de agradecê-la não apenas por compartilharmos osmomentos felizes, mas também por ter me apoiado nos momentos mais difíceis.

À minha futura nova família, Armelinda, Pedro e Tatiana pelo apoio e compreensão dosmomentos em que estive ausente.

Aos meus mestres e orientadores, os professores Huei e Wu, pelos valiosos ensinamentostanto na parte técnica quanto na parte pessoal, os quais levarei pelo resto da minha vida. Porincontáveis vezes em que assumiram o papel dos pais para nos educarem. Por abdicar de muitasnoites de descanso para trabalharem com a finalidade de criar oportunidades para os alunos doLABI. Pela nossa amizade e paciência em nos orientar em momentos de turbulência.

Aos professores e amigos, André, Andrés, Joylan, Renato e Richardson, pela amizade e

ix

x

ensinamentos compartilhados.

Aos meus amigos do LABI, Altamira, Antônio, Bianca, Caio, Chris, Dabna, Everton,Felipe, Fonteque, Jediel, Jorge, Leandro, Paulo, Maurício, Neimar, Newton, Rafaela, Ricardo,Vanize, Willian e Wilson, pela amizade, respeito, apoio e sugestões nas minhas decisões.

Ao meu amigo Narco, pela amizade e os bons momentos compartilhados nesses quasetrês anos vivenciados na mesma casa. Pela nossa invenção do prato Macalango ("Miojo" comfarinha e molho de pimenta habanero).

Aos meus amigos da Pós-graduação, Katiani, Marcos Ricardo, Mariana, Rodrigo, Wil-lian, Jhonny (Dionísio do Sertão), pela amizade e os momentos inesquecíveis que vivenciamosnessa trajetória.

Aos meus amigos de infância, Alex, André, Eduardo (Dudu), Guilherme (Totão), Gustavo(Legal), Helton Alegra (Heltroo), Helton (Tibira), Luiz Fernando (Nando), Renam, Tiago, VitorAngeli e Vitor Hugo, por essa amizade duradoura e compreensão dos momentos de minhaausência.

Aos demais amigos, pela amizade e contribuição de forma direta e indireta na minhaformação.

Aos profissionais da área médica do Serviço de Coloproctologia da Faculdade de CiênciasMédicas da UNICAMP que confeccionaram laudos textuais artificiais de exames de endoscopiadigestiva alta.

À Fabiana, secretária do PGESDE, que não mediu esforços para nos apoiar e ajudar emdiversas situações que envolvam a pós-graduação.

Aos professores do PGESDE e aos funcionários da UNIOESTE.

À UNIOESTE, pelo apoio financeiro em despesas com viagens para a apresentação detrabalhos científicos em congressos.

À CAPES (Coordenação de Aperfeiçoamento de Pessoal de Nível Superior), pelo apoiopor intermédio da concessão de bolsas de pós-graduação.

Todas as demais pessoas que, de alguma forma, contribuíram com desenvolvimento destetrabalho.

“O mundo é perigoso não por causa daqueles que fazem o mal,mas por causa daqueles que vêem e deixam o mal ser feito.”

Albert Einstein

xi

Sumário

Lista de Figuras xvi

Lista de Tabelas xix

Lista de Símbolos xxi

1 Introdução 1

1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Premissas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Hipótese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Organização do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Fundamentos de Ontologia 7

2.1 Considerações Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Definição de Ontologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Aplicações da Ontologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4 Tipos de Ontologias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5 Construção de Ontologias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.6 Linguagens de Representação de Ontologias . . . . . . . . . . . . . . . . . . . 12

2.6.1 Knowledge Interchange Format . . . . . . . . . . . . . . . . . . . . . 12

2.6.2 Ontolingua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.6.3 Resource Description Framework . . . . . . . . . . . . . . . . . . . . 14

2.6.4 Ontology Inference Layer . . . . . . . . . . . . . . . . . . . . . . . . 16

2.6.5 DAML + OIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

xiii

xiv

2.6.6 Ontology Web Language . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.7 Ferramentas para Representação de Ontologias . . . . . . . . . . . . . . . . . 22

2.7.1 Chimaera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.7.2 OilED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.7.3 Protégé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.7.4 Servidor Ontolingua . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.8 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 Processo de Mapeamento de Laudos Médicos utilizando Ontologias 25


3.2 Mapeamento de Laudos Médicos . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3 Primeira Fase do PMLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3.1 Construção do Conjunto de Frases Únicas . . . . . . . . . . . . . . . . 30

3.3.2 Normalização do Conjunto de Frases Únicas . . . . . . . . . . . . . . 30

3.3.3 Construção do Arquivo de Padronização . . . . . . . . . . . . . . . . . 31

3.3.4 Remoção de Stopwords . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.3.5 Aplicação de Stemming . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.3.6 Aplicação de Lematização . . . . . . . . . . . . . . . . . . . . . . . . 35

3.3.7 Definição dos Atributos da Tabela Atributo-Valor e da Ontologia . . . . 38

3.4 Segunda Fase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40


4 Desenvolvimento de Sistemas Computacionais 43


4.2 Processo de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.3 Levantamento de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.4 Projeto de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.5 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

xv

4.6 Testes de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50


5 Ferramentas e Tecnologias 55


5.2 Linguagem de Programação Java . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.3 Linguagem de Programação Ruby . . . . . . . . . . . . . . . . . . . . . . . . 57

5.4 Framework Ruby on Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.5 Ambiente de Desenvolvimento NetBeans . . . . . . . . . . . . . . . . . . . . 59

5.6 Linguagem de Programação Perl . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.7 Linguagem de Marcação HTML . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.8 Linguagem de Marcação XML . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.9 Linguagem CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.10 Linguagem de Programação Javascript . . . . . . . . . . . . . . . . . . . . . . 68


6 Processo de Desenvolvimento do Sistema Computacional Colaborativo 71


6.2 Etapa de Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6.3 Etapa de Plano Rápido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.4 Etapa de Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.5 Etapa de Construção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.6 Apresentação do Sistema Computacional Colaborativo Desenvolvido . . . . . . 81

6.7 Etapa de Avaliação e Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . 93


7 Estudo de Caso 95


7.2 Avaliação Experimental do SCC . . . . . . . . . . . . . . . . . . . . . . . . . 96

xvi

7.3 Construção do Arquivo de Padronização . . . . . . . . . . . . . . . . . . . . . 98

7.4 Elaboração da Stoplist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

7.5 Definição de Atributos da Base de Dados e de Regras de Mapeamento . . . . . 100

7.6 Ontologia Construída no Estudo de Caso . . . . . . . . . . . . . . . . . . . . . 102

7.7 Aplicação do Método Mapeamento por Ontologias em Laudos Médicos Artificiais108


8 Resultados e Discussão 111


8.2 Aplicação do PMLM em Trabalhos Anteriores . . . . . . . . . . . . . . . . . . 111

8.3 Construção do Sistema Computacional Colaborativo . . . . . . . . . . . . . . 112

8.4 Avaliação Experimental em Laudos Médicos Artificiais . . . . . . . . . . . . . 116


9 Conclusão 125

9.1 Principais Desfechos deste Trabalho . . . . . . . . . . . . . . . . . . . . . . . 126

9.2 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

9.3 Principais Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

9.4 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Referências Bibliográficas 132

A Arquivos Definidos para a Avaliação Experimental do Estudo de Caso 141

A.1 Stoplist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

A.2 Arquivo de Padronização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Lista de Figuras

2.1 Exemplo de definição de classes KIF. . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Exemplo de definição de classes Ontolingua. . . . . . . . . . . . . . . . . . . . 14

2.3 Exemplo de definição de classes RDFS. . . . . . . . . . . . . . . . . . . . . . 15

2.4 Exemplo de definição de classes OIL . . . . . . . . . . . . . . . . . . . . . . . 16

2.5 Exemplo de representação de um conjunto de dados DAML+OIL. . . . . . . . 17

2.6 Exemplo de representação de definição de classes OWL. . . . . . . . . . . . . 19

2.7 Exemplo de uso de propriedade da linguagem OWL. . . . . . . . . . . . . . . 21

3.1 Exemplo de transcrição manual de um laudo textual artificial . . . . . . . . . . 27

3.2 Estrutura do Dicionário de Conhecimento . . . . . . . . . . . . . . . . . . . . 28

3.3 Primeira fase do PMLM baseado em ontologia . . . . . . . . . . . . . . . . . 29

3.4 Processo de identificação de frases únicas . . . . . . . . . . . . . . . . . . . . 30

3.5 Normalização de um exemplo de CFU. . . . . . . . . . . . . . . . . . . . . . . 31

3.6 Exemplo de estrutura do Arquivo de Padronização. . . . . . . . . . . . . . . . 32

3.7 Exemplo de stoplist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.8 Exemplo de aplicação de stemming. . . . . . . . . . . . . . . . . . . . . . . . 35

3.9 Exemplo de conjunto de regras para lematização de verbos. . . . . . . . . . . . 36

3.10 Exemplo de esquema de ontologia para mapeamento de laudos médicos. . . . . 39

3.11 Segunda fase do PMLM baseado em ontologia . . . . . . . . . . . . . . . . . . 40

4.1 Modelo de desenvolvimento por prototipagem . . . . . . . . . . . . . . . . . . 46

4.2 Processo de gerenciamento de projetos . . . . . . . . . . . . . . . . . . . . . . 49

4.3 Etapas do teste de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

xvii

xviii

5.1 Padrão MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2 Exemplo de documento HTML e página web equivalente. . . . . . . . . . . . . 64

5.3 Exemplo de estrutura de documento XML . . . . . . . . . . . . . . . . . . . . 66

6.1 Diagrama de casos de uso do SCC. . . . . . . . . . . . . . . . . . . . . . . . . 75

6.2 Modelo de arquitetura do SCC. . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.3 Exemplos de AP antigos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.4 Exemplo de nova estrutura otimizada de AP. . . . . . . . . . . . . . . . . . . . 78

6.5 Tela de acesso ao sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.6 Exemplo de estrutura do arquivo de parâmetros do SCC. . . . . . . . . . . . . 83

6.7 Funcionalidade "Gerenciamento do Conjunto de Laudos Médicos" da primeirafase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

6.8 Telas de gerenciamento de carregamento de laudos textuais. . . . . . . . . . . . 84

6.9 Funcionalidade "Construção e Gerenciamento do Conjunto de Frases Únicas" daprimeira fase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6.10 Funcionalidade "Definição e Gerenciamento da Lista de Stopwords" da pri-meira fase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6.11 Funcionalidade "Construção e Gerenciamento do Arquivo de Padronização" daprimeira fase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.12 Tela para definição de uma nova RP. . . . . . . . . . . . . . . . . . . . . . . . 88

6.13 Funcionalidade "Definição e Gerenciamento do Conjunto de Atributos" da pri-meira fase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.14 Tela para definição de nova RM. . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.15 Funcionalidade "Aplicação de Pré-Processamento" da segunda fase. . . . . . . 91

6.16 Funcionalidade "Realização de Mapeamento" da segunda fase. . . . . . . . . . 92

7.1 Exemplo de laudo textual de exame EDA da região do esôfago. . . . . . . . . . 96

7.2 Fragmento do AP desenvolvido no Estudo de Caso. . . . . . . . . . . . . . . . 99

7.3 Exemplo de transcrição de stopwords. . . . . . . . . . . . . . . . . . . . . . . 100

7.4 Hierarquia de classes da ontologia do SCC . . . . . . . . . . . . . . . . . . . . 104

xix

7.5 Esquema detalhado de ontologia com um exemplo de instância para cada classe 105

7.6 Exemplo de atributo representado na linguagem OWL. . . . . . . . . . . . . . 106

7.7 Exemplo de esquema de ontologia criada automaticamente pelo SCC . . . . . . 108

8.1 Avaliação dos CFU gerados por quantidade de frases. . . . . . . . . . . . . . . 118

8.2 Avaliação dos CFU gerados por quantidade de palavras. . . . . . . . . . . . . . 118

8.3 Avaliação do desempenho em relação ao tempo para o mapeamento manual eautomático. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Lista de Tabelas

5.1 Tabela de exemplos de metacaracteres utilizados em ER . . . . . . . . . . . . . 62

8.1 Resultados da avaliação dos CFU gerados. . . . . . . . . . . . . . . . . . . . . 119

8.2 Quantidade de termos não-processados. . . . . . . . . . . . . . . . . . . . . . 120

8.3 Complexidade dos métodos empregados no PMLM . . . . . . . . . . . . . . . 121

xxi

Lista de Siglas

AP Arquivo de PadronizaçãoBD Base de DadosCFU Conjuntos de Frases ÚnicasCSS Cascading Style SheetsDAML DARPA Agent Markup LanguageDARPA US Defense Advanced Research Projects AgencyDC Dicionário do ConhecimentoDOM Document Object ModelDRY Don’t Repeat YourselfECMA European Computer Manufacturers AssociationEDA Endoscopia Digestiva AltaER Expressões RegularesFCM Faculdade de Ciências MédicasFO Frame OntologyHTML HyperText Markup LanguageIC Inteligência ComputacionalIDE Integrated Development EnvironmentINPI Instituto Nacional de Propriedade IndustrialJDK Java Development KitJRE Java Runtime EnvironmentJSON Javascript Object NotationKIF Knowledge Interchange FormaKISS Keep It Simple, StupidLABI Laboratório de BioinformáticaMD Mineração de DadosMeSH Medical Subject HeadingsMJV Máquina Virtual JavaMVC Model-View-ControllerNLM National Lybrary of MedicineOIL Ontology Inference LayerOWL Ontology Web LanguagePERL Practical Extraction and Report Language

xxiii

xxiv

PMLM Processo de Mapeamento de Laudos MédicosRDF Resource Description FrameworkRDFS Resource Description Framework SchemaRDR Ripple Down RuleRL Regras de LematizaçãoRM Regra de MapeamentoRP Regra de PadronizaçãoRoR Ruby on RailsSC Sistema ComputacionalSCAIMED-Mobile

Sistema Computacional para Análise de Imagens Médicas

SCC Sistema Computacional Colaborativo’sed’ Stream EDitorSGML Standard Generalized Markup LanguageSNOMED-CT

Systematized Nomenclature of Medicine – Clinical Terms

TMTOWTDI There’s More Than One Way To Do ItUML Unified Modeling LanguageUMLS Unified Medical Language SystemUNICAMP Universidade Estadual de CampinasUNIOESTE Universidade Estadual do Oeste do ParanáW3C Wide World Web ConsortiumXML eXtensible Markup Language

Capítulo 1

Introdução

Com os avanços tecnológicos da área computacional, são armazenadas crescentementegrandes quantidades de dados provenientes de diversas fontes. Na área da saúde, os examesmédicos podem ser representados em diversos formatos, como áudio, vídeo, imagens, formu-lários, entre outros (Wiederhold and Shortliffe, 2006). Uma parte importante das informaçõescontidas nesses exames é descrita por meio de linguagem natural em laudos textuais, com a fi-nalidade de registrar observações à respeito do estado clínico do paciente (Lee, Oliva, Maletzke,Machado, Voltolini, Coy, Fagundes and Wu, 2013).

Nesse contexto, os laudos e os exames médicos são armazenados com o objetivo de man-ter o histórico clínico do paciente e auxiliar nos diagnósticos de futuras enfermidades. Adi-cionalmente, esses laudos, quando registrados em bases de dados computacionais, podem serutilizados para a construção de modelos de predição para o auxílio no diagnóstico de enfer-midades em pacientes, por meio da descoberta de padrões nesses laudos (Cherman, Spolaôr,Lee, Costa, Fagundes, Coy and Wu, 2008; Lee, Monard, Honorato, Lorena, Ferrero, Maletzke,Zalewski, Coy, Fagundes and Chung, 2011).

No entanto, o crescente armazenamento de dados médicos, ao mesmo tempo em que seapresenta como um fato positivo, inviabiliza a análise manual dos mesmos, tornando necessárioo desenvolvimento de métodos e ferramentas computacionais que auxiliem na análise e nogerenciamento dessas informações (Han, 2005).

Para prover suporte a análise e ao gerenciamento de dados em distintas áreas do conheci-mento, diversos processos computacionais podem ser usados, dos quais se destaca o de Minera-ção de Dados (MD), que tem o intuito de explorar conjuntos de dados mediante a identificaçãode padrões, auxiliando na descoberta de conhecimento. Esses padrões podem ser identificadospor meio de métodos de Inteligência Computacional (IC) para a criação de modelos descritivose preditivos a partir do conhecimento presente nos dados analisados (Witten and Frank, 2005).Para a aplicação da MD, é necessário que os dados sejam representados em formato estruturado,

1

2

como a tabela atributo-valor 1, na qual cada linha dessa tabela é um elemento do conjunto dedados analisados e cada coluna é uma característica observada (atributo) (Rezende, 2003).

Na área médica, os dados registrados em base de dados não estão geralmente represen-tados em formato adequado para a aplicação do processo de MD. Para isso ser possível, énecessário o desenvolvimento de métodos e ferramentas para transformar esses dados para umformato estruturado, como as tabelas atributo-valor (Cherman, Spolaôr, Lee and Wu, 2008; Lee,Monard, Honorato, Lorena, Ferrero, Maletzke, Zalewski, Coy, Fagundes and Chung, 2011; Lee,Oliva, Maletzke, Machado, Voltolini, Coy, Fagundes and Wu, 2013).

Nesse sentido, no Laboratório de Bioinformática (LABI) da Universidade Estadual doOeste do Paraná (UNIOESTE / Foz do Iguaçu) em parceria com o Serviço de Coloproctologiada Faculdade de Ciências Médicas (FCM) da Universidade Estadual de Campinas (UNICAMP)e outros parceiros, está sendo desenvolvido o projeto interdisciplinar denominado Análise Inte-ligente de Dados, que tem como objetivo pesquisar e propor métodos e ferramentas para proversuporte à análise de dados médicos.

Esse projeto inclui o desenvolvimento do Processo de Mapeamento de Laudos Médicos(PMLM), que tem o propósito de transformar conjuntos de laudos médicos para uma represen-tação estruturada (Lee, Monard, Honorato, Lorena, Ferrero, Maletzke, Zalewski, Coy, Fagundesand Chung, 2011). Em Honorato, Cherman, Lee, Monard and Wu (2007) foi proposta a primeiraversão do PMLM, a qual utiliza uma estrutura de dados denominada Dicionário do Conheci-mento (DC) para representação de informações de laudos textuais médicos. Nessa abordagem,o DC é utilizado para a transcrição de laudos, por meio de casamento de padrões, para base dedados computacionais. No DC encontram-se Regras de Mapeamento (RM), as quais represen-tam possíveis combinações de termos para as frases de cada laudo e o modo como devem sermapeadas para a tabela atributo-valor (Cherman, Spolaôr, Lee and Wu, 2008).

Esse processo é aplicado em duas fases. Na primeira fase, o conjunto de laudos médicosé submetido à aplicação de técnicas de processamento de textos com o propósito de definir asseguintes estruturas com o auxílio de especialistas da área médica: Arquivo de Padronização(AP), que é aplicado para a uniformização de laudos, com a finalidade de reduzir a complexi-dade de cada frase presente nos laudos; características que irão compor a tabela atributo-valor,que é utilizada para a representação do conhecimento presente nos laudos; e DC, que é aplicadono mapeamento de laudos médicos para sua representação na tabela atributo-valor.

Na segunda fase, primeiramente os laudos selecionados são padronizados por meio doAP. Em seguida, os laudos uniformizados são processados e o conhecimento dos mesmos émapeado para a tabela atributo-valor por meio de um algoritmo especializado utilizando o DC.Nesse contexto, com a aplicação do PMLM baseado em DC a alguns domínios foi possível

1Neste trabalho os termos tabela atributo-valor e base de dados serão usadas indistintamente.

3

obter resultados considerados satisfatórios (Spolaôr, Lee, Cherman, Honorato, Fagundes, Góes,Coy and Chung, 2007; Cherman, Spolaôr, Lee, Honorato, Coy, Fagundes and Wu, 2008).

No entanto, o DC gerado por meio da aplicação desse método apresenta-se como umaestrutura de dados com pouca flexibilidade no contexto de representação de RM, dificultandoa tarefa de descrição de regras mais complexas. Assim, caso seja necessária a representaçãode regras mais complexas e completas, é imprescindível a definição de um novo esquema parao DC, bem como realizar as modificações no método, de modo a adaptar o algoritmo para oprocessamento desses laudos (Lee, Oliva, Maletzke, Machado, Voltolini, Coy, Fagundes andWu, 2013).

Sendo assim, com a finalidade de aumentar a flexibilidade e a capacidade de representa-ção desse método, foi proposta uma variação do PMLM com o intuito de substituir o DC poruma ontologia, que é uma estrutura que apresenta maior flexibilidade para a representação doconhecimento (Lee, Monard, Honorato, Lorena, Ferrero, Maletzke, Zalewski, Coy, Fagundesand Chung, 2011). Nessa abordagem é eliminada parte do problema de definição de novasregras para mapeamento de laudos.

Embora o método possa ser utilizado amplamente, inclusive por profissionais que nãosejam da área de computação, atualmente todas as técnicas utilizadas no PMLM devem serexecutadas separadamente por meio de instruções computacionais, dificultando o seu uso porprofissionais de áreas não relacionadas com a computação. Desse modo, para prover suporteao usuário e tornar o uso do método amigável e intuitivo, é necessário que todas as técnicasque compõem o PMLM estejam integradas em um sistema computacional. Adicionalmente,outras técnicas de processamento de textos podem ser aplicadas para auxiliar na transformaçãode laudos médicos, de modo que o alcance do método seja aumentado para a realização domapeamento nesses laudos.

1.1 Objetivos

Esse trabalho tem como objetivo geral automatizar e otimizar o PMLM por ontologiasmediante a integração de técnicas de processamento de laudos textuais em uma ferramentacomputacional.

Para alcançar o objetivo principal deste trabalho, os seguintes objetivos específicos foramdefinidos:

• Levantamento bibliográfico sobre conceitos relacionados com ontologias e PMLM;

• Desenvolvimento de um Sistema Computacional Colaborativo (SCC) para prover suporteà aplicação automatizada do método de mapeamento de laudos médicos;

4

• Auto-suficiência do SCC para a construção e a alteração da ontologia empregada em umdeterminado domínio;

• Pesquisa e desenvolvimento de outros métodos de processamento de textos para aprimo-rar a representação dos laudos;

• Realização de um estudo de caso para a aplicação do SCC no mapeamento de um deter-minado conjunto de laudos médicos;

• Avaliação e validação dos resultados do trabalho em conjunto com especialistas do domí-nio.

1.2 Premissas

As premissas deste trabalho são:

• Cada técnica de processamento de textos implementada no PMLM é executada manual-mente e separadamente por intermédio de instruções computacionais;

• As estruturas auxiliares utilizadas como apoio ao PMLM devem ser construídas manual-mente e separadamente utilizando a linguagem de marcação XML (eXtensible MarkupLanguage);

• A ontologia deve ser elaborada utilizando outras ferramentas computacionais, como oProtégé;

• Uma das técnicas de processamento de textos utilizada no PMLM pode acarretar na percade legibilidade e/ou na transformação errônea de alguns termos.

1.3 Hipótese

A hipótese deste trabalho é que a integração e a automatização de todas as técnicas eas etapas do PMLM por ontologias em um SCC pode tornar o processo de mapeamento maiseficiente, tanto em termos de custo de tempo quanto em termos de precisão, bem como torná-lomais amigável.

1.4 Organização do Trabalho

Este trabalho está organizado do seguinte modo:

5

• Capítulo 2 – Fundamentos de Ontologia: neste capítulo são abordados os principaisconceitos sobre ontologias, suas definições e utilidades. Também, são apresentados ostipos de ontologias, método de construção dessas estruturas, linguagens aplicadas pararepresentação de conhecimento e ferramentas comumente utilizadas para a construção deontologias;

• Capítulo 3 – Processo de Mapeamento de Laudos Médicos utilizando Ontologias:neste capítulo o processo como um todo é apresentado juntamente com as técnicas deprocessamento de textos utilizadas no PMLM bem como o método de lematização, abor-dagem proposta para a substituição do método de stemming neste trabalho;

• Capítulo 4 – Desenvolvimento de Sistemas Computacionais: neste capítulo são abor-dados conceitos de engenharia de software focados na construção de sistemas computa-cionais. Também são apresentados conceitos de processo de software utilizado para odesenvolvimento do SCC;

• Capítulo 5 – Ferramentas e Tecnologias: neste capítulo são apresentadas as ferramentasutilizadas para a construção da solução computacional deste trabalho, como as linguagensde programação Java, Javascript, Perl e Ruby, o ambiente de desenvolvimento NetBeans,as linguagens de marcação HTML e XML, a linguagem de estilo CSS e o framework paradesenvolvimento de sistemas web Ruby on Rails;

• Capítulo 6 – Processo de Desenvolvimento do Sistema Computacional Colaborativo:neste capítulo são descritas a aplicação de uma abordagem disciplinada de engenharia desoftware e ferramentas utilizadas para a construção do SCC;

• Capítulo 7 – Estudo de Caso: neste capítulo é apresentado o estudo de caso realizadoneste trabalho, utilizando o SCC desenvolvido para a aplicação do PMLM automatizadoem um conjunto de laudos médicos textuais artificiais que simulam exames de EndoscopiaDigestiva Alta (EDA);

• Capítulo 8 – Resultados e Discussão: neste capítulo são apresentados e discutidos osresultados da avaliação experimental do SCC desenvolvido. Essa avaliação foi realizadapor meio da aplicação do PMLM automatizado em um conjunto de laudos médicos tex-tuais artificiais de exames de EDA. Também foi comparado o desempenho da execuçãodo mapeamento manual e automático;

• Capítulo 9 – Conclusão: neste capítulo são apresentadas as conclusões deste trabalho,suas possíveis e principais contribuições, limitações identificadas durante o seu desenvol-vimento, e sugestões de trabalhos futuros.

Capítulo 2

Fundamentos de Ontologia

2.1 Considerações Iniciais

Com o crescente aumento no volume e no armazenamento de informações em base dedados, é imprescindível a construção de métodos e de ferramentas para a organização e o ge-renciamento dessas informações de modo que possam ser utilizadas futuramente em aplicaçõesde processos para a descoberta de conhecimento, como Mineração de Dados (MD). Para isso, énecessário que esses dados sejam representados de forma estruturada para que esses processosdesempenhem as suas tarefas de forma rápida e eficiente. Nesse sentido, o uso de ontologiaspode auxiliar na representação e na organização dessas informações.

Sendo assim, na Seção 2.2 são descritas as principais definições de ontologia. Na Se-ção 2.3 são discutidos alguns domínios em que as ontologias podem ser empregadas. Na Se-ção 2.4 são apresentados os tipos de ontologias. Na Seção 2.5 é descrito o método geral paraa construção de ontologias proposto por Uschold and Gruninger (1996). Na Seção 2.6 são de-monstradas algumas linguagens que podem ser utilizadas para representação do conhecimento.Na Seção 2.7 são apresentadas algumas ferramentas que provém suporte para a representação eo processamento de ontologias.

2.2 Definição de Ontologia

Ontologia, palavra oriunda dos termos gregos ontos (ser) e logia (conhecimento), consisteem um campo da filosofia que tem o propósito de estudar as características do ser, da existênciae das questões que envolvem a metafísica (Harper, 2010). A definição de ontologia teve origemna Grécia Antiga e ocupou a mente de filósofos como Platão, Aristóteles e Parmênides. Noséculo XVII, enquanto uns filósofos consideravam o termo ontologia equivalente à palavra me-tafísica, outros definiam esse termo como uma divisão da metafísica. Atualmente, a metafísicae a ontologia são consideradas sinônimos, filosoficamente (Guarino and Giaretta, 1995). Na

7

8

área computacional, ontologia é uma estrutura de dados que tem a finalidade de representar oconhecimento de um domínio específico.

Para Uschold and Gruninger (1996), ontologia é um termo utilizado como referência paradenominar o compartilhamento do conhecimento de alguma área de interesse, podendo seraplicada no desenvolvimento de ferramentas computacionais para processamento de informa-ções representadas estruturadamente. Em uma ontologia é incorporado algum tipo de visão demundo relacionado com um determinado campo de conhecimento. Essa visão é caracterizadacomo um conjunto de conceitos (entidades, atributos, processos, entre outros) e relacionamen-tos entre os mesmos.

Para Guarino (1997), ontologia é uma caracterização intuitiva de um vocabulário lógico,em que as sentenças expressam relacionamentos entre características específicas, sendo quemuitas vezes é necessária uma inferência mais detalhada do conhecimento para excluir ou re-duzir interpretações errôneas por Sistemas Computacionais (SC).

Na definição de Fox, Barbuceanu, Gruninger and Lin (1998) e de Garcia and Sichman(2003), ontologia é uma representação formal de uma entidade, ou seja, é constituída de propri-edades, de relações, de restrições e de comportamentos. Nesse sentido, uma entidade é definidacomo uma organização, que é composta por várias divisões e consiste em um grupo de agentesassociados a um conjunto de papéis, que são funções desempenhadas pelos agentes da organi-zação com a finalidade de cumprir metas estipuladas. Agente é um membro de uma divisão daorganização que assume pelo menos um papel a ser desempenhado.

Segundo Gruber (2009), uma ontologia tem o intuito de definir um conjunto de primi-tivas de representação, como classes, atributos e relacionamentos para modelar o domínio deconhecimento. Para a definição de primitivas, devem ser incluídas as informações sobre o seusignificado e as restrições lógicas para sua aplicação. Por exemplo, em sistemas de bancos dedados, o nível de abstração de modelos de dados pode ser considerado uma ontologia.

2.3 Aplicações da Ontologia

Na área computacional, o uso de ontologias é dividido em três categorias (Uschold andGruninger, 1996):

• Comunicação: permitem o compartilhamento de conhecimento e o contato entre indiví-duos com necessidades e ideias diferentes em distintos domínios específicos. Em SC,essas estruturas são utilizadas para padronizar modelos de dados, relacionamento de re-des, integração de diferentes sistemas, entre outros;

• Interoperabilidade: possibilitam a integração de diferentes softwares sem a necessidade

9

de tradução de métodos de modelagem, de linguagens de programação, de ferramentascomputacionais, e de arquiteturas;

• Engenharia de Sistemas: facilitam o processo de identificação de requisitos durante a mo-delagem e o desenvolvimento de projetos de SC, tal como possibilitam a automatizaçãoda verificação de consistência, aumentando a confiabilidade do sistema. Também, essasestruturas de dados podem ser reutilizadas para a construção de outros sistemas. Assim,ontologias podem ser utilizadas como apoio na especificação de requisitos, auxiliandona tarefa de identificação de necessidades que deverão ser atendidas por meio de umasolução computacional.

Nesse contexto, as ontologias geralmente são utilizadas com o propósito de facilitar arealização de tarefas, como: organização de conhecimento; compartilhamento de informaçõesentre as pessoas; processamento de dados; aplicação de processos de MD; e comunicação entreos componentes de software e/ou aplicações computacionais (Chute, 2005). Assim, ontologiaspodem ser aplicadas em projetos que envolvem multidisciplinaridade com o objetivo de facilitaro diálogo entre os especialistas de diferentes áreas, bem como apoio para reduzir a complexi-dade do desenvolvimento de sistemas.

Na área da saúde, por exemplo, várias ontologias foram desenvolvidas com o intuito derepresentar vocabulários médicos em estruturas de dados para que possam ser utilizadas por fer-ramentas computacionais (Campbell, 1998), dos quais se destaca a Unified Medical Language

System (UMLS) (Humpheys, Lindberg, Schoolman and Barnett, 1998).

A UMLS é um repositório mantido pela organização norte-americana National Lybrary

of Medicine (NLM) e é composto por vários vocabulários de termos utilizados nas ciênciasmédicas. Sendo assim, esse repositório possui três bases de conhecimento, tais como a Me-

tathesaurus, a Semantic Network e a Specialist Lexicon.

A Metathesaurus é uma ampla base de dados multilíngua de vocabulários utilizada parao mapeamento de termos médicos com a finalidade de definir ou de identificar distintos termosque estão associados a um simples conceito. Essa base possui mais de um milhão de conceitosmédicos e mais de cinco milhões de nomenclaturas de termos, compondo mais de 100 voca-bulários diferentes, incluindo os vocabulários controlados Medical Subject Headings (MeSH) eSystematized Nomenclature of Medicine – Clinical Terms (SNOMED-CT).

A Semantic Network é um catálogo de tipos de semânticas (categorias) e de relaciona-mentos que definem a classificação dos conceitos presentes na base Metathesaurus por meio daatribuição. Essa base contém 133 tipos semânticos e 54 relacionamentos diferentes.

A Specialist Lexicon é um dicionário em que são apresentadas as definições sintáticaspara termos médicos no idioma inglês. Cada termo de entrada processado (dados de entrada)contém informações ortográficas, morfológicas (forma e estrutura) e sintaxe (como as palavras

10

são organizadas para gerar um significado).

No Laboratório de Bioinformática (LABI) da Universidade Estadual do Oeste do Paraná(UNIOESTE) em parceria com o Serviço de Coloproctologia da Faculdade de Ciências Médi-cas (FCM) da Universidade Estadual de Campinas (UNICAMP) foi proposta uma versão doProcesso de Mapeamento de Laudos Médicos (PMLM) que utiliza ontologias para a represen-tação do conhecimento. Essa estrutura contém atributos e Regras de Mapeamento (RM), quesão utilizados para transformação de laudos médicos textuais não estruturados para o formatoestruturado, como a tabela atributo-valor (Lee, Monard, Honorato, Lorena, Ferrero, Maletzke,Zalewski, Coy, Fagundes and Chung, 2011).

2.4 Tipos de Ontologias

As ontologias podem ser categorizadas de acordo com o domínio do conhecimento envol-vido, que é representado em uma estrutura de dados segundo os níveis de detalhes determina-dos (Bodenreider and Burgun, 2005). Nesse sentido, essas ontologias podem ser classificadascomo:

• Ontologias de aplicação (application ontologies): representam os conceitos que sãodependentes de um domínio específico e de suas atividades que atendem as especificaçõesdo problema a ser resolvido (Guarino, 1997);

• Ontologias centrais (core ontologies): descrevem as divisões do estudo de uma deter-minada área e/ou conceitos genéricos e abstratos (Guarino and Giaretta, 1995). Essasontologias contém apenas definições necessárias para compreender outros conceitos;

• Ontologias de domínio (domain ontologies): especificam o conhecimento de um deter-minado domínio específico, ou seja, parte particular do mundo. Para a construção dessetipo de ontologia é necessário o uso de uma ontologia de nível mais genérico que descrevaos termos mais gerais e que sejam independentes de domínio. As ontologias de nível maisgenérico são denominadas de ontologias gerais (França, 2009);

• Ontologias gerais (foundation ontologies): representam o conhecimento em um nívelintermediário de detalhes independentemente do seu uso em representações específi-cas (Bodenreider and Burgun, 2005). Assim, as ontologias gerais consistem em mo-delos de dados comumente aplicáveis a uma grande variedade de ontologias de domínio.Por exemplo, os termos relacionados ao veículo podem ser aplicados na conceituação decarro, de trem, de avião ou de navio. Desse modo, o veículo pode ser representado poruma ontologia geral e os tipos derivados de veículo podem ser representados por umaontologia de domínio;

11

• Ontologias de representação (representation ontologies): esboçam a classificação dasprimitivas que são utilizadas por intermédio de uma linguagem de representação de co-nhecimento (Guarino, 1997);

• Ontologias de tarefas (task ontologies): descrevem o vocabulário relacionado com asatividades necessárias para a resolução de problemas independentemente do domínio emque ocorrem (Guarino and Giaretta, 1995).

2.5 Construção de Ontologias

Na literatura foram propostos vários métodos para o desenvolvimento de ontologias, dosquais se destaca o método geral de construção de ontologias (Uschold and Gruninger, 1996),que tem como objetivo generalizar o processo de construção dessas estruturas de dados.

O método proposto por Uschold and Gruninger (1996) é aplicado em cinco fases:

1. Identificação do escopo e do objetivo;

2. Construção da ontologia;

3. Avaliação;

4. Documentação;

5. Estabelecimento de diretrizes para cada fase.

Na Fase (1), são levantadas as especificações para o desenvolvimento de uma ou maisontologias, bem como são respondidas questões à respeito das mesmas, como a motivação eo modo de uso. O escopo é definido mediante um conjunto de questões de competência, osquais são problemas diferentes de raciocínio que devem ser atendidos pela ontologia proposta.Assim, as definições e as restrições de uma ontologia são avaliadas e validadas por meio dasquestões de competência.

Na Fase (2), após as definições da etapa anterior, é construída a ontologia considerandotrês aspectos:

• Captura: contempla atividades para a definição da ontologia, como a identificação dosconceitos principais e dos relacionamentos existentes no domínio de interesse, a produçãode definições exatas de texto não ambíguos para os conceitos identificados e a definiçãodos termos referentes aos conceitos e aos relacionamentos;

12

• Codificação: a partir dos conceitos identificados durante a captura da ontologia, a mesmaé construída por meio de uma linguagem de representação em um ambiente de desenvol-vimento;

• Integração com ontologias existentes: durante a codificação dessa estrutura, podem serreaproveitadas outras ontologias que foram desenvolvidas anteriormente.

Na Fase (3), verifica-se se foram atendidas todas as especificações levantadas para o de-senvolvimento de uma ou mais ontologias. Assim, são avaliadas as suas características, taiscomo a sua expressividade e a sua consistência. Essa avaliação deve determinar se é necessáriaa extensão da ontologia ou se as questões de competência podem ser respondidas por meio deontologias existentes.

Na Fase (4), o processo de desenvolvimento da ontologia é documentado. Nessa docu-mentação são incluídas as especificações levantadas durante as etapas anteriores e os conceitosutilizados para o desenvolvimento da estrutura.

Na Etapa (5), são definidos os conjuntos de técnicas, métodos e princípios para a aplicaçãode cada uma das fases anteriores, bem como são estipulados os relacionamentos entre essasfases, tais como a ordem de execução, a intercalação e a entrada/saída de informações. Éimportante ressaltar que as duas últimas fases são complementos que provém suporte para odesenvolvimento das outras fases.

2.6 Linguagens de Representação de Ontologias

Nessa seção são apresentadas as linguagens comumente utilizadas para a representaçãode esquemas de ontologias, das quais se destaca a linguagem Ontology Web Language (OWL)que foi utilizada para o processamento de laudos textuais médicos por meio do PMLM.

2.6.1 Knowledge Interchange Format

A linguagem Knowledge Interchange Format (KIF) (Genesereth, Fikes, Brachman, Gru-ber, Hayes, Letsinger, Lifschitz, Macgregor, Mccarthy, Norvig and Patil, 1992) foi desenvolvidacom o objetivo de facilitar a troca de informações entre softwares escritos em diferentes lingua-gens. A KIF, caracterizada por ser baseada no cálculo de predicados e por apresentar alto poderde expressividade, foi uma das primeiras linguagens elaboradas com o intuito de representar oconhecimento por meio de ontologias. O propósito dessa linguagem é similar ao da linguagemPostscript (Adobe Systems, 1990), que é comumente utilizada em programas de formatação detextos e de gráficos para a visibilização de informações.

13

Nesse sentido, essa linguagem possui algumas características que podem ser essenciaispara a representação do conhecimento, tais como:

• Semântica declarativa: possibilita a compreensão das principais expressões dessa lingua-gem sem a necessidade dos recursos de um interpretador para manipular essas expressões;

• Logicamente compreensível: fornece expressões de sentenças arbitrárias para o cálculode predicados;

• Representação de meta-conhecimento: provém suporte aos usuários em processo de to-madas de decisões no contexto de representação do conhecimento explícito.

Na Figura 2.1 é apresentado um exemplo de expressão para definição de uma classe, noqual subclass é uma operação para a definição de subclasses, => é um operador para declaraçãode regras, instancia é a operação para a definição de instância, ?PF é uma variável, attribute éuma característica de ?PF.

Figura 2.1: Exemplo de definição de classes KIF.

2.6.2 Ontolingua

Proposta por Gruber (1992), a linguagem Ontolingua tem como objetivo auxiliar na ma-nutenção de ontologias de maneira flexível e que seja compatível com várias linguagens derepresentação de conhecimento. Essa linguagem é implementada em um programa que utilizauma sintaxe simples para traduzir definições, que são os dados de entrada para vários sistemasde representação.

Nesse contexto, a sintaxe da Ontolingua é baseada nas notações padrões e cálculo depredicados presentes na linguagem KIF. Assim, a linguagem Ontolingua traduz ontologias de-senvolvidas na linguagem KIF em sistemas de representação, os quais são limitados pela lógicade primeira ordem para a implementação do raciocínio. Desse modo, essa linguagem é proje-tada para capturar representações comuns do conhecimento. Também, a Ontolingua é baseadano Frame Ontology (FO) (Farquhar, Fikes and Rice, 1997), o qual foi construído como umacamada sobre o KIF e consiste em uma ontologia de representação do conhecimento que tem

14

a finalidade de permitir a construção de ontologias seguindo o paradigma de quadros (frames),propiciando termos como classes, instâncias, herança, entre outros.

Comumente utilizado na área da Inteligência Artificial, frame é uma estrutura de dadosutilizada para representar conhecimento de um determinado domínio (Minsk, 1985).

Desse modo, de acordo com Corcho and Gómez-Pérez (2000), a linguagem Ontolinguapermite construir ontologias por qualquer uma das três maneiras: utilizando exclusivamente ovocabulário FO; usando expressões KIF; ou aplicando ambas as linguagens simultaneamente.

Na Figura 2.2 é apresentado um exemplo de definição de classes estruturadas na lingua-gem Ontolingua, no qual define-class é um construtor de classe, ?nome e ?cpf são variáveis,:def é um comando para a definição de atributos de classes, :axiom-def é um comando paraa especificação de propriedades de classes e subclass-of é uma operação para a definição desubclasses.

Figura 2.2: Exemplo de definição de classes Ontolingua.

2.6.3 Resource Description Framework

A linguagem Resource Description Framework (RDF) (Klyne, Carroll and McBride,2014) foi desenvolvida com o intuito de padronizar a comunicação de dados entre dispositi-vos por meio da Internet. Essa linguagem é focada na representação de dados de forma flexívele minimamente restritiva para facilitar a automatização do processamento de recursos da web.

A sintaxe do RDF utiliza a linguagem de marcação denominada eXtensible Markup Lan-

guage (XML) (Bray, Paoli, Sperberg-McQueen, Maler and Yergeau, 2006) para representar osdados e possibilitar a especificação da semântica para os dados baseados em XML de modopadronizado e interoperável.

XML é uma linguagem simples e flexível que foi desenvolvida para a criação e a formata-ção de documentos de maneira hierárquica. Essa linguagem foi desenvolvida com a finalidadede enfrentar o desafio de gerenciar grandes quantidades de documentos eletrônicos publicados

15

na web. Assim, o XML oferece uma definição de sintaxe padrão para o desenvolvimento dedocumentos estruturados. Essa linguagem é apresentada no Capítulo 5.

Nesse contexto, a linguagem RDF foi desenvolvida para atender a alguns requisitos derepresentação do conhecimento, tais como: prover suporte ao desenvolvimento de modelosde dados que sejam simples e fáceis de serem utilizados em aplicações de processamento ede manipulação de informações; possuir semântica formal e inferência de raciocínio provável;portar um vocabulário totalmente extensível e baseado em URI, que são referências utilizadaspara nomear todos os tipos de objetos em RDF; utilizar XML para codificar o modelo de dadospara a troca de informações entre aplicativos distribuídos; utilizar diferentes tipos de dados deesquema XML para representar valores com o objetivo de auxiliar no compartilhamento deinformações entre aplicativos que utilizam as linguagens XML e RDF; e facilitar o uso emescala de recursos da Internet.

No entanto, RDF não oferece mecanismos para descrição de propriedades, bem comonão provê recursos para a descrição de relações entre estas propriedades e outros recursos. Parareduzir esses problemas, foi desenvolvido o RDF Schema (RDFS) (Brickley and Guha, 2004),também conhecido como esquema RDF, o qual consiste em uma extensão de RDF que tem afinalidade de definir as classes e as propriedades para serem utilizadas na descrição de outraspropriedades.

Na Figura 2.3 é apresentado um exemplo de definição de classes estruturadas na lingua-gem RDFS, no qual rdfs:Class é um construtor que define classes, rdf:ID é o identificador de umelemento declarado em um construtor, rdfs:Property é o construtor de propriedades de classes,rdfs:subClassOf é a operação de herança de características de classes, rdf:domain estabelecequal a classe que um elemento pertence neste exemplo e rdf:resource representa o nome daclasse que um elemento está vinculado.

Figura 2.3: Exemplo de definição de classes RDFS.

16

2.6.4 Ontology Inference Layer

Ontology Inference Layer (OIL) (Horrocks, Fensel, Broekstra, Decker, Erdmann, Goble,van Harlemen, Klein, Staab, Studer, Motta and Horrocks, 2000) consiste em uma linguagemque tem o propósito de padronizar a tarefa de construção de ontologias por meio do uso depadrões web para a representação de dados, tais como as linguagens XML e RDFS. Para isso,essa linguagem possui uma camada de inferência para ontologias. A OIL combina o uso deprimitivas de modelagem, que são amplamente utilizadas em linguagens baseadas em frames,com a aplicação da semântica formal e da lógica descritiva para a inferência do raciocínio.

Para definição de ontologias em OIL é necessária a distinção de três camadas diferentesdessa linguagem, tais como: nível de objeto, na qual são descritas as instâncias concretas deuma ontologia; primeiro meta-nível, em que as definições ontológicas atuais são disponibiliza-das; e segundo meta-nível, também conhecido como meta-meta nível, na qual são definidas ascaracterísticas que descrevem a ontologia do nível de objeto.

Na Figura 2.4 é ilustrado um exemplo de definição de classes de uma ontologia OIL, noqual class-def define o nome de uma classe, slot-def determina um elemento de classe, domain

estabelece qual a classe que um elemento pertence e subclas-of é a operação de herança decaracterísticas de classes.

Figura 2.4: Exemplo de definição de classes OIL (Modificado de van Harmelen and Horrocks(2000)).

2.6.5 DAML + OIL

Inicialmente, por meio de um programa financiado pela agência norte-americana US De-

fense Advanced Research Projects Agency (DARPA), do Departamento de Defesa dos EstadosUnidos (United States Department of Defense), foi desenvolvida uma linguagem de marcaçãobaseada em RDF e XML denominada DARPA Agent Markup Language (DAML) (Hendler andD. L. McGuinness, 2000). Essa linguagem foi elaborada com o objetivo de facilitar o desenvol-vimento de estruturas de dados para a realização de buscas na web.

Após o desenvolvimento da DAML, a mesma sofreu algumas alterações e foi evoluídapara a DAML–ONT, que consiste em uma linguagem simplificada para a representação de con-

17

ceitos em classes RDF de forma mais sofisticada que a representação permitida pela linguagemRDFS.

Assim, com objetivo de aprimorar a representação do conhecimento, foram unidas aslinguagens DAML–ONT e OIL em uma nova linguagem chamada DAML+OIL (Horrocks,2002). Essa tecnologia adota o paradigma orientado a objetos na descrição de estruturas para arepresentação do conhecimento por meio do uso de classes e propriedades.

Essa linguagem também utiliza estruturas XML Schema para a representação de dados.Na Figura 2.5 é apresentado um exemplo de estrutura DAML+OIL para a representação de umconjunto de dados, no qual daml:oneOf define a enumeração de elementos, parseType repre-senta o tipo de dados, daml:collection determina que essa estrutura é uma coleção não ordenadade dados, daml:Thing é um elemento utilizado para a declaração de elementos de representaçãode dados e rdf:about é utilizado para nomear um elemento.

Figura 2.5: Exemplo de representação de um conjunto de dados DAML+OIL.

2.6.6 Ontology Web Language

Ontology Web Language (OWL) (Smith, Welty and McGuinness, 2004) é uma linguagembaseada nas linguagens OIL e DAM+OIL utilizada para a representação do conhecimento quetem o intuito de construir e de instanciar ontologias na web. Assim, a linguagem OWL foidesenvolvida para ser utilizada na web semântica (semantic web) (Berners-Lee, Hendler andLassila, 2006).

A web semântica consiste em uma visão do futuro da web, onde a informação terá umsignificado explícito, facilitando o processamento e a integração de informações disponíveisna web pelos computadores. Assim, o propósito é tornar os recursos da web mais acessíveisaos processos automatizados por meio da adição de informações sobre os recursos que descre-vem ou fornecem conteúdo na web, facilitando o trabalho de cooperação entre o humano e amáquina (McGuinness and van Harmelen, 2004).

18

Desse modo, a ontologia OWL é construída utilizando estruturas XML e RDF. As infor-mações desse tipo de ontologia são organizadas utilizando as tags RDF, RDFS e OWL, tambémconhecidos como construtores. Também, nessa linguagem as semânticas formais e específicasdeterminam como derivar consequências lógicas, tais como os fatos que não estejam presentesna ontologia, mas que foram vinculados com a semântica.

Classes

Uma classe consiste em um mecanismo de abstração para definir um grupo de indivíduos(também conhecidos como objetos na área computacional) pertencentes a um conjunto quecompartilham as mesmas propriedades. Por exemplo, carro e avião são indivíduos pertencentesà classe Veiculo. Nesse sentido, cada classe OWL está associada a um conjunto de indivíduos,sendo essa associação denominada extensão de classe. Cada indivíduo nessa extensão é deno-minado uma instância de classe.

As classes podem ser organizadas em uma hierarquia de especialização, também deno-minado herança, por exemplo, a classe PessoaJurídica pode ser uma especialização da classePessoa. Na linguagem OWL, o mecanismo de especialização pode ser aplicado utilizando oconstrutor rdfs:subClassOF. Nessa linguagem existe uma classe embutida mais geral deno-minada Thing, que é uma superclasse para todas as classes OWL (Bechhofer, van Harmelen,Hendler, Horrocks, McGuinnes, Patel-Schneider and Stein, 2004; McGuinness and van Harme-len, 2004).

Para definição de classes OWL, também podem ser utilizados os seguintes construtores:

• owl:complementOf : permite a combinação de classes por meio da operação lógica decomplemento. Por exemplo, a classe Cozinha é um complemento da classe Casa;

• owl:disjointWith: garante que um indivíduo de uma classe não pode ser associado simul-taneamente com uma outra classe especificada, ou seja, as classes não podem possuir osmesmos indivíduos. Por exemplo, os indivíduos da classe Fruta não podem ser instanci-ados pela classe Carne.

• owl:equivalentClass: indica que duas classes possuem a mesma extensão de uma mesmaclasse, ou seja, duas ou mais classes podem conter os mesmos indivíduos. Por exemplo,as classes PessoaFísica e PessoaJurídica podem obter os mesmos indivíduos relacionadosà classe Pessoa;

• owl:intersectionOf : permite a combinação de classes por meio da operação lógica deintersecção. Assim, a classe que utiliza esse construtor, além de suas características es-pecíficas, permite o uso apenas das características que são semelhantes entre as classes

19

utilizadas. Por exemplo, a intersecção das classes Brasileiro e Argentino ocasiona nascaracterísticas equivalentes aos da classe Pessoa;

• owl:oneOf : define a enumeração de classes, permitindo que as mesmas sejam descritaspela enumeração exaustiva de suas instâncias. Assim, a classe definida por esse construtorcontém apenas indivíduos enumerados. Por exemplo, a classe Fruta pode ser compostapelos indivíduos das classes Maçã, Banana, Pêssego, Abacate, entre outras;

• owl:unionOf : permite a combinação de classes por meio da operação lógica de união.Esse construtor viabiliza a junção de características de várias classes em uma única classe.Por exemplo, a classe América pode ser elaborada com a união das classes Argentina,Brasil, Colômbia, entre outras.

Na Figura 2.6 é apresentado um exemplo de definição de uma classe na linguagem OWL,no qual owl:Class representa uma classe OWL, rdf:ID é um atributo para nomeação de umcomponente OWL e owl:resource é utilizado para referenciar elementos nessa linguagem.

Figura 2.6: Exemplo de representação de definição de classes OWL.

Propriedades

Na linguagem OWL, as propriedades tem como finalidade representar as regras de re-lacionamento entre os indivíduos (Bechhofer, van Harmelen, Hendler, Horrocks, McGuinnes,Patel-Schneider and Stein, 2004; Smith, Welty and McGuinness, 2004). Essa linguagem possuidois tipos diferentes de propriedades:

• datatype properties: estabelece relações entre as instâncias de classes, literais da lingua-gem RDF e XML Schema datatypes;

• object properties: define relações entre as instâncias de duas ou mais classes.

Nesse sentido, podem ser utilizados os seguintes construtores para a definição de propri-edades, para os quais são apresentadas as suas funcionalidades:

• owl:equivalentProperty: determina que duas ou mais propriedades são equivalentes, ouseja, têm a mesma propriedade de extensão;

20

• owl:functionalProperty: especifica que uma propriedade P pode ter apenas um únicovalor para cada indivíduo;

• owl:inverseFunctionalProperty: indica que um valor pode ser somente atribuído à pro-priedade P de um único indivíduo;

• owl:inverseOf : define que uma propriedade é inversa em relação à outra propriedade. Porexemplo, se a propriedade Px é inversa da propriedade Py e se a classe X está relacionadacom a classe Y pela Py, então Y está associada com X pela Px;

• owl:symmetricProperty: utilizado para indicar que uma propriedade é simétrica, ou seja,se o conjunto de indivíduos (x, y) é uma instância de P, então o conjunto (y, x) é umainstância de P;

• owl:transitiveProperty: determina que uma propriedade é transitiva, isto é, se os conjun-tos (x, y) e (y, z) são instâncias de P, então o conjunto (x, z) é uma instância de P;

• rdfs:domain: caracterizado como domínio da propriedade, limita os indivíduos para pos-sibilitar a aplicação da propriedade. Assim, se a propriedade possui uma classe como umde seus domínios e um indivíduo é relacionado a um outro indivíduo por meio dessa pro-priedade, então esses indivíduos pertencem a mesma classe. Por exemplo, a propriedadedenominada temFilho pode ser indicada para ter o domínio de progenitores (mãe e/oupai);

• rdfs:range: limita a instanciação de indivíduos por meio da definição de valores que sãoválidos para uma determinada propriedade. Por exemplo, a propriedade diaSemana podeser indicada para possuir um dos valores presentes no conjunto (domingo, segunda-feira,..., sábado);

• rdfs:subPropertyOf : define que a propriedade é uma sub-propriedade de outra propri-edade. Por exemplo, as propriedades terCarro, terCamionete e terCaminhão são sub-propriedades de terVeiculoTerrestre.

Sendo assim, cada propriedade é representada pela estrutura XML <owl:ObjectProperty

rdf:about=”nomeAtributo”>, na qual rdf:about é um atributo de nomeação ou referência de umatributo.

Na Figura 2.7 é apresentado um exemplo de uso de propriedade na linguagem OWL, emque é definida a propriedade temCasa, que é sub-propriedade de temImovel e possui a propri-edade temDomicilio como equivalente e a classe Imovel como limitação do valor a ser aceitonessa definição.

21

Figura 2.7: Exemplo de uso de propriedade da linguagem OWL.

Restrições de Propriedades

A linguagem OWL permite o uso de restrições sobre o modo como as propriedades sãopermitidas para serem aplicadas em instâncias de uma classe. Essa linguagem fornece dois tiposde restrições que podem ser utilizados em propriedades: restrição de valor (value constraints)e restrição de cardinalidade (cardinality constraints). A restrição de valor aplica limitações noalcance da propriedade quando são utilizadas na descrição de classes, ou seja, define os valorespossíveis ou um intervalo de valores que uma propriedade é capaz de obter. A restrição decardinalidade limita a quantidade de valores que uma propriedade pode assumir na descrição declasses (Bechhofer, van Harmelen, Hendler, Horrocks, McGuinnes, Patel-Schneider and Stein,2004; McGuinness and van Harmelen, 2004).

Em ontologias desenvolvidas com a linguagem OWL, as restrições de propriedades po-dem ser aplicadas por meio do uso das tags <owl:Restriction> e<owl:onProperty rdfs:resource=”propriedade”>, das quais a tag <owl:onProperty> indica apropriedade restrita. A seguir são apresentados os construtores das restrições que limitam osvalores que são utilizados em uma propriedade:

• owl:allValuesFrom: descreve uma classe para todos os indivíduos de um determinadoconjunto em que todos os valores da propriedade em questão são membros quaisquer daextensão de classe de descrição ou são valores de dados em um determinado intervalo, istoé, são especificados todos os relacionamentos entre os indivíduos de uma classe. Assim,a propriedade presente nesta classe tem uma restrição local para valores associados àmesma. Por exemplo, a classe Escola possui a propriedade temProfessor restringindotodos os seus valores como instâncias da classe Pessoa;

• owl:someValuesFrom: determina uma classe para todos os indivíduos de um determinadoconjunto que possuem pelo menos um valor da propriedade em questão e o mesmo é umexemplo da classe de descrição ou de valor em um intervalo especificado. Ao contráriodo allValuesFrom, o construtor someValuesFrom não limita a propriedade para que todosos seus valores sejam instâncias da mesma classe.

Também, nessa linguagem são incluídas limitações de cardinalidade, que são definidas

22

como restrições locais, as quais são apresentados a seguir:

• owl:maxCardinality: determina o número máximo de instâncias que uma propriedadepossa possuir;

• owl:minCardinality: estabelece o número mínimo de instâncias que uma propriedadepossa obter;

• owl:cardinality: define que uma propriedade possui o valor de maxCardinality igual aovalor do minCardinality, ou seja, uma propriedade deve possuir exatamente um númerode instâncias. Por exemplo, a propriedade temCPF da classe PessoaJurídica deve ter ovalor de cardinality exatamente igual a um.

2.7 Ferramentas para Representação de Ontologias

Várias ferramentas foram desenvolvidas com o objetivo de facilitar o processo de cons-trução de ontologias. A seguir são apresentadas as principais ferramentas utilizadas para odesenvolvimento dessas estruturas.

2.7.1 Chimaera

Chimaera (McGuinness, Fikes, S. and Wilder, 2000) é uma ferramenta computacional quetem a finalidade de prover suporte aos usuários nas tarefas de criação e de manutenção de onto-logias na web. Essa ferramenta tem duas funções principais: mesclar ontologias múltiplas emuma só e evoluí-las. Também, Chimaera suporta ontologias oriundas de bases de conhecimentode formatos diferentes por meio da reorganização de taxonomias, da resolução de conflitos denome, da edição, entre outros.

Nesse sentido, Chimaera possui um ambiente simples para a construção e a edição deontologias, tal como possibilita que o usuário utilize o editor/navegador do ambiente Ontolinguapara a edição mais extensa e complexa dessas estruturas de dados. Também, é importantedestacar que essa ferramenta computacional pode utilizar ontologias representadas por meiodas linguagens OWL e DAML.

2.7.2 OilED

OilED (Horrocks, Goble and Stevens, 2001) é uma ferramenta para construção de onto-logias nas linguagens OIL e DAML+OIL com o intuito de proporcionar um estilo simples eintuitivo para indução de raciocínio por intermédio de uma interface amigável ao usuário. Essa

23

ferramenta utiliza frames para lidar com a expressividade da linguagem OIL. A ferramenta Oi-lED também usa mecanismos altamente sofisticados de indução de raciocínio por DL com opropósito de gerar conclusões para o raciocínio que está sendo processado, facilitando a elabo-ração de ontologias mais complexas e detalhadas.

Na versão atual dessa ferramenta é necessária a inclusão de vários recursos para a cons-trução de ontologias, pois o mesmo não suporta o desenvolvimento dessas estruturas em largaescala, bem como não provê suporte para versionamento.

2.7.3 Protégé

Protégé (Gennari, Musen, Fergerson, Grosso, Crubzy, Eriksson, Noy and Tu, 2003) con-siste em um ambiente de código aberto (open source) e de uso gratuito para construção desistemas baseados em conhecimento. Inicialmente desenvolvido com objetivo de atender a áreamédica, esse ambiente foi aprimorado para um conjunto de ferramentas de uso geral. O Protégéé composto por duas partes: o modelo (model), que é um mecanismo interno para representaçãode ontologias e bases de conhecimento; e a visão (view), que oferece uma interface ao usuáriopara exibir e editar ontologias.

Atualmente, Protégé pode construir e editar ontologias em várias linguagens, tais comoOWL, RDF, XML, Unified Modeling Language (UML) e banco de dados relacionais. Para aconstrução de ontologias na linguagem OWL foi desenvolvido um plugin 1 de extensão denomi-nado Protégé OWL Plugin (Knublauch, Fergerson, Noy and Musen, 2004). O uso desse plugin

oferece alguns benefícios, dos quais se destacam: uma grande comunidade de usuários e de-senvolvedores ativos que utilizam e desenvolvem esse plugin; uma biblioteca de componentesreutilizáveis; e uma arquitetura flexível.

2.7.4 Servidor Ontolingua

Servidor Ontolingua (Farquhar, Fikes and Rice, 1997) é um conjunto de ferramentas quetem o propósito de apoiar o processo de construção de ontologias na linguagem Ontolingua demodo individual, bem como de forma compartilhada entre grupos. Essas ferramentas fazemo uso da web para permitir o acesso e oferecer recursos aos usuários para manipulação deontologias, como publicação, navegação, criação, edição e compartilhamento em um servidorespecífico.

Sendo assim, o Servidor Ontolingua oferece muitas facilidades para o desenvolvimentode ontologias, tais como:

1Plugin é um componente de software que permite adicionar uma caraterística específica a uma aplicação desoftware já existente.

24

• Linguagem de representação semi-formal que oferece suporte para a descrição de ter-mos apresentados informalmente em linguagem natural e formalmente em linguagem derepresentação de conhecimento interpretável por computadores;

• Busca, reposição, construção, melhoria e extensão de ontologias em repositórios;

• Facilidade de interpretação de ontologias de repositórios em sistemas computacionais;

• Facilidade de acesso a ontologias por meio de aplicações remotas via web.

2.8 Considerações Finais

Ontologia consiste em uma estrutura de dados promissora para representação de dadosmédicos, pois com essa estrutura é possível organizar o conhecimento de modo flexível e estru-turado. Para representação de dados médicos, na literaturam foram desenvolvidas várias onto-logias, como a UMLS, que é o maior vocabulário de termos de ciências biomédicas disponívelpara auxiliar sistemas computacionais no processamento e no gerenciamento de dados.

No PMLM são utilizadas ontologias com o propósito de representar atributos e RM paramapear conjuntos de laudos médicos textuais para uma base de dados. As ontologias utilizadasnesse processo são representadas por intermédio da linguagem OWL devido a sua grande quan-tidade de recursos para flexibilizar o desenvolvimento de ontologias, permitindo a expansão dopotencial de representação dessas estruturas de acordo com o domínio de conhecimento. Para odesenvolvimento de ontologias nessa linguagem, geralmente é utilizada a ferramenta Protége,pois é facilitada a construção dessas estruturas por meio de uma interface gráfica amigável eintuitiva ao usuário, bem como não é necessário o conhecimento da linguagem OWL por partedo usuário para o uso dessa ferramenta. Também, essa ferramenta possui código-fonte aberto eo seu uso é gratuito, possibilitando que desenvolvedores de software aprimorem essa ferramentade acordo com as suas necessidades e/ou de outros usuários.

Capítulo 3

Processo de Mapeamento de LaudosMédicos utilizando Ontologias


Neste capítulo é apresentado o processamento de textos utilizados no Processo de Mape-amento de Laudos Médicos (PMLM), que tem o objetivo de transformar conjuntos de laudostextuais não estruturados para uma representação estruturada, como a tabela atributo-valor (Lee,Monard, Honorato, Lorena, Ferrero, Maletzke, Zalewski, Coy, Fagundes and Chung, 2011).

Inicialmente, em Cherman, Lee, Honorato, Fagundes, Góes, Coy and Wu (2007) foi pro-posta a primeira versão desse processo, a qual utiliza o Dicionário do Conhecimento (DC) paraa descrição de Regras de Mapeamento (RM). O DC consiste em uma estrutura de dados utili-zada para a transformação de laudos por intermédio de casamento de padrões. Essa estrutura érepresentada por um arquivo estruturado descrito na linguagem de marcação XML (eXtensible

Markup Language), que é amplamente aplicada para a construção de documentos com dadosorganizados hierarquicamente com o uso de marcadores (tags).

Porém, estudos realizados anteriormente apontam que o DC apresenta pouca flexibilidadepara a representação do conhecimento, dificultando a elaboração de RM mais complexas, sendonecessária a construção de novos esquemas de DC e a alteração do método de mapeamentopara adaptá-lo à nova estrutura de DC (Honorato, Cherman, Lee, Monard and Wu, 2007; Costa,Ferrero, Lee, Coy, Fagundes and Chung, 2009; Costa, Ferrero, Lee, Coy, Fagundes and Chung,2010; Lee, Monard, Honorato, Lorena, Ferrero, Maletzke, Zalewski, Coy, Fagundes and Chung,2011).

Com o propósito de reduzir as limitações dessa abordagem, em Lee, Monard, Honorato,Lorena, Ferrero, Maletzke, Zalewski, Coy, Fagundes and Chung (2011) foi proposta uma varia-ção do método original com o intuito de substituir o DC por uma ontologia, que é uma estruturade dados que apresenta maior flexibilidade para representação de dados.

25

26

Nesse contexto, na Seção 3.2 são apresentadas abordagens utilizadas para o mapeamentodesses laudos médicos e alguns trabalhos nos quais foram aplicadas essas abordagens. Emseguida, são apresentadas as duas etapas do PMLM, as quais são abordadas nas Seções 3.3 e3.4.

3.2 Mapeamento de Laudos Médicos

Os laudos textuais são imprescindíveis para qualquer especialidade médica, pois permi-tem descrever achados em exames realizados e manter o histórico do paciente quanto a proce-dimentos, sintomas, enfermidades, entre outros. No entanto, para que as informações contidasnesses laudos possam ser utilizadas, por exemplo, para estatísticas ou pesquisas médicas, parao estudo de enfermidades, a identificação de padrões, o desenvolvimento de procedimentos mé-dicos, entre outros, o mapeamento de laudos é geralmente realizado de forma manual para umabase dados, como planilhas eletrônicas, o que torna essa tarefa inviável para grandes quanti-dades de laudos textuais. Na Figura 3.1 é ilustrado um exemplo de transcrição manual de umfragmento de laudo artificial pré-processado da seção de esôfago para uma base de dados, ondeas linhas representam laudos mapeados e as colunas representam características (atributos) con-sideradas essenciais mapeadas nesses laudos.

Nesse sentido, no LABI da UNIOESTE/Foz do Iguaçu em parceria com o Serviço deColoproctologia da Faculdade de Ciências Médicas (FCM) da UNICAMP foi desenvolvido oPMLM com a finalidade de automatizar e padronizar a transcrição de informações presentesem laudos médicos para uma base de dados (Honorato, Cherman, Lee, Monard and Wu, 2007;Cherman, Lee, Honorato, Fagundes, Góes, Coy and Wu, 2007; Lee, Monard, Honorato, Lorena,Ferrero, Maletzke, Zalewski, Coy, Fagundes and Chung, 2011).

Inicialmente, em Cherman, Lee, Honorato, Fagundes, Góes, Coy and Wu (2007) foi pro-posta a versão do PMLM que utiliza uma estrutura de dados denominada Dicionário de Co-nhecimento (DC) para o mapeamento de laudos. Essa estrutura contém RM que representampossíveis combinações de termos em frases de cada laudo para o preenchimento da base dedados. Essas RM são geralmente apresentadas na forma local-característica-subcaracterística

e/ou local-característica, onde:

• Local: corresponde aos termos que descrevem uma porção anatômica do corpo humano;

• Característica: equivale às palavras que caracterizam possíveis anormalidades ou outrasinformações importantes à respeito de um determinado local;

• Subcaracterística: representa as informações complementares de uma determinada carac-

27

Figura 3.1: Exemplo de transcrição manual de um laudo textual artificial da seção de esôfagopara uma base de dados.

terística.

No caso do DC, essas regras são representadas de modo sequencial, em que cada localdescreve uma lista de característica e cada característica pode possuir uma lista de subcarac-terísticas, como ilustrado na Figura 3.2, em que Li é uma lista de locais, LiCj é a lista decaracterísticas de Li, Aj é o atributo que é preenchido caso seja encontrada a sequência LiCj

no laudo, Vj é o valor do atributo Aj , LiCjSk é subcaracterística de LiCj , Ask é o atributo queé preenchido caso seja encontrado no laudo a sequência LiCjSk no laudo e V sk é o valor doatributo Ask.

Entretanto, o DC apresenta pouca flexibilidade para a representação do conhecimento ea descrição de RM, dificultando a elaboração de regras que apresentam maior complexidadee completitude 1, tornando indispensável a construção de novas estruturas de DC e especial-mente, a realização de modificações no método para adaptá-lo ao novo esquema de DC para omapeamento de laudos que não tenham sidos mapeados anteriormente.

Com a finalidade de melhorar a representação do conhecimento presente em laudos tex-1Possibilidade de inclusão de maior quantidade de informações relevantes em uma única regra.

28

Figura 3.2: Estrutura do Dicionário de Conhecimento (Spolaôr, Lee, Cherman, Honorato, Fa-gundes, Góes, Coy and Chung, 2007).

tuais, em Costa, Ferrero, Lee, Coy, Fagundes and Chung (2009) foi apresentada uma propostainicial de uma variação do PMLM com o objetivo de substituir o DC por uma ontologia paraaumentar a flexibilidade na representação do conhecimento e facilitar o reuso dessa estruturapara a construção de outras ontologias sem a necessidade de reconstruí-la e sem a necessidadeda alteração do algoritmo de mapeamento para adaptá-lo a essas estruturas.

Em Wu, Coy, Lee, Fagundes, Ferrero, Machado, Maletzke, Zalewski, Leal, Ayrizono andCosta (2010) e Lee, Monard, Honorato, Lorena, Ferrero, Maletzke, Zalewski, Coy, Fagundesand Chung (2011), foi proposta a versão atual do PMLM. Entretanto, todas as técnicas aplicadasnesse processo devem ser executadas manualmente e separadamente por intermédio do uso decomandos computacionais, dificultando a aplicação do método por profissionais que não sejamda área computacional. Por exemplo, para a construção de Conjuntos de Frases Únicas (CFU)e o pré-processamento de laudos textuais, o usuário deve executar de forma manual os arquivosescritos na linguagem Perl utilizando instruções específicas por meio de interpretadores dessalinguagem. Outro exemplo é a realização do mapeamento desses laudos, para a qual é necessáriaa execução manual do método por meio de uma Máquina Virtual Java (MVJ), o qual é executadocom o uso de instruções computacionais.

Ainda, a construção das estruturas como a lista de stopwords (stoplist) e o Arquivo dePadronização (AP), que são apresentadas na Seção 3.3, é realizada manualmente com o uso deestruturas XML. A organização manual de stopwords e de Regras de Padronização (RP) emestruturas XML se apresenta como uma atividade altamente repetitiva e custosa, pois as suasinformações devem ser organizadas de forma padronizada e hierárquica por intermédio de mar-cadores, podendo acarretar na representação errônea das mesmas e influenciar no desempenhodo pré-processamento e do mapeamento de laudos médicos (Lee, Oliva, Maletzke, Machado,Voltolini, Coy, Fagundes and Wu, 2013).

29

Para a construção de ontologias, podem ser utilizadas ferramentas computacionais de usogratuito para a representação das RM, como o Protégé (Gennari, Musen, Fergerson, Grosso,Crubzy, Eriksson, Noy and Tu, 2003). No entanto, o uso dessa ferramenta requer treinamento eo conhecimento da linguagem de representação de ontologias denominada OWL (Smith, Weltyand McGuinness, 2004) por parte de seus usuários, tal como para a elaboração de RM e deatributos é exigido grande esforço.

3.3 Primeira Fase do PMLM

Nessa etapa são aplicadas técnicas de processamento de textos em um conjunto de laudostextuais digitais com a finalidade de identificar padrões relevantes que são representados pormeio de um Arquivo de Padronização (AP). Em seguida, os padrões identificados nos laudossão analisados em conjunto com profissionais da área médica e da área computacional paradefinir os atributos da tabela atributo-valor (base de dados estruturada) e as RM que irão com-por a ontologia para a representação do conhecimento presente em laudos médicos (Cherman,Spolaôr, Lee, Costa, Fagundes, Coy and Wu, 2008; Lee, Monard, Honorato, Lorena, Ferrero,Maletzke, Zalewski, Coy, Fagundes and Chung, 2011).

Na Figura 3.3 é apresentada a primeira fase do método de mapeamento de laudos.

Figura 3.3: Primeira fase do PMLM baseado em ontologia (Modificado de Lee, Oliva, Ma-letzke, Machado, Voltolini, Coy, Fagundes and Wu (2013)).

Com base na Figura 3.3, nas seções seguintes são apresentadas as técnicas de processa-mento de textos utilizadas no PMLM, bem como são abordadas a construção do AP, da tabela

30

atributo-valor e da ontologia.

3.3.1 Construção do Conjunto de Frases Únicas

A identificação de frases únicas consiste na extração de todas as sentenças distintas exis-tentes em um conjunto de laudos médicos. Essa técnica é aplicada de forma sequencial em trêspassos (Cherman, Lee, Honorato, Fagundes, Góes, Coy and Wu, 2007):

1. Concatenação de todas as frases presentes no conjunto de laudos em um único arquivo;

2. Ordenação alfabética das frases;

3. Eliminação de frases redundantes, restando apenas um exemplo para cada frase.

Após a aplicação dessa técnica, é gerado o Conjunto de Frases Únicas (CFU). Na Fi-gura 3.4 é ilustrado graficamente o processo de identificação de frases únicas.

Figura 3.4: Processo de identificação de frases únicas (Cherman, Lee, Honorato, Fagundes,Góes, Coy and Wu, 2007).

3.3.2 Normalização do Conjunto de Frases Únicas

O desempenho da aplicação de métodos de processamento de textos pode ser influenciadopela simples variação de um caracter em um determinado termo. Por exemplo, os termos Japão,japão, Japao e japao podem ser considerados distintos por métodos de processamento de textos

31

devido à variação de um ou mais caracteres, como a presença ou a ausência de acentuação e decaracteres maiúsculos ou minúsculos.

Nesse sentido, para evitar problemas de variações de um mesmo caractere, cada termopresente no CFU é normalizado com o objetivo de substituir caracteres maiúsculos por caracte-res minúsculos e caracteres com presença de acentuação por caracteres sem acentuação (Cherman,Lee, Honorato, Fagundes, Góes, Coy and Wu, 2007). Na Figura 3.5 é apresentado um exemplode aplicação da normalização em um fragmento de CFU.

Figura 3.5: Normalização de um exemplo de CFU.

3.3.3 Construção do Arquivo de Padronização

Após a construção e a normalização do CFU, é possível identificar algumas informaçõesque podem ser padronizadas, como termos semelhantes ou frases que apresentam as mesmasinformações de maneiras distintas. Assim, em conjunto com especialistas do domínio é iniciadaa construção do AP. Esse arquivo é uma estrutura de dados representada por meio da linguagemde marcação XML utilizada para uniformização de laudos textuais com o objetivo de reduzir acomplexidade de cada frase presente nesses laudos, de modo que seja compatível com as RMpresentes em uma ontologia. Essa uniformização é realizada por intermédio da substituição determos que apresentam o mesmo significado ou em formato inadequado por um sinônimo ou

32

um conjunto de sinônimos definidos como sendo mais adequados que estão descritos no AP.

Por exemplo, a frase "esôfago com presença erosões", que descreve uma possível anor-malidade presente em um tecido biológico, pode ser substituída pelo sinônimo definido como"esôfago anormal". Também, podem ocorrer frases que apresentam mais de uma característica,como "calibre distensibilidade normais", na qual são descritas duas características: calibre edistensibilidade, que são classificadas como normais. Por meio da aplicação de padroniza-ção nessa frase, a mesma pode ser substituída por duas outras frases, como "calibre normal" e"distensibilidade normal".

Na Figura 3.6 é apresentado um exemplo de estrutura do AP, onde <pattern> é o mar-cador que representa o cabeçalho do AP, number é o número de Regras de Padronização (RP)presentes no AP, <synonym> é o marcador que representa uma RP, n é o número de termosque irão substituir um determinado termo, <old> é o marcador que constitui um termo a serpadronizado e <new> é o marcador que representa um novo termo que substituirá o termo re-presentado no marcador <old>, caso seja encontrado em um laudo textual durante a aplicaçãodo AP.

Figura 3.6: Exemplo de estrutura do Arquivo de Padronização.

Para a construção de um AP, podem ser utilizadas Expressões Regulares (ER) 2 com afinalidade de identificar sequências de caracteres importantes para a padronização de termos,como espaços em branco excedentes entre palavras, sequência excedente de um determinadocaractere, ou termos que ocorrem raramente em frases (Honorato, Cherman, Lee, Wu and Mo-nard, 2007). Por exemplo, no padrão "ponto[s]*\s*esbranquicado[s]*" (Figura 3.6), a expres-são regular "[s]*" aponta a possibilidade de haver zero ou mais vezes a presença do caractere"s" em uma determinada parte de uma palavra e a expressão regular "\s*" aponta a possibilidade

2Expressão regular é uma sequência de caracteres que formam um padrão a ser identificado em uma frase ouuma palavra, por exemplo na forma de operações "busca e substituição".

33

de haver zero ou mais vezes a presença de espaços em branco.

Nesse contexto, a aplicação de outras técnicas de processamento de textos, como as apre-sentadas nas próximas seções, pode gerar termos ou frases diferentes, aumentando as possibili-dades para desenvolvimento de RP. Desse modo, a construção do AP é continuada no decorrerda aplicação da primeira fase do PMLM, à medida que são identificadas informações que podemser uniformizadas.

3.3.4 Remoção de Stopwords

Esse método tem a finalidade de reduzir o tamanho de frases por meio da eliminação destoptwords (Makrehchi and Kamel, 2008), que são termos considerados irrelevantes, ou seja,não são necessários para a compreensão de frases. É importante notar que as stopwords sãodependentes de contexto. Os exemplos mais comuns incluem tais como pronomes, preposições,artigos, entre outros. Nesse método, os stopwords compõem uma lista denominada stoplist, queé utilizada no processamento do CFU e de laudos durante a remoção desses termos. A stoplist

é construída em conjunto com especialistas do domínio e assim como AP, é representada porintermédio da linguagem de marcação XML.

Na Figura 3.7 é apresentado um exemplo de stoplist, onde <stopwords> é o marcadorque representa a lista de termos considerados irrelevantes, number é o número de stopwords

presentes na stoplist e <stopword> é o marcador que representa um stopword.

Figura 3.7: Exemplo de stoplist.

34

3.3.5 Aplicação de Stemming

O método de aplicação de stemming tem o objetivo de reduzir cada termo para o seuradical, eliminando diferentes inflexões da mesma palavra (Hull, 1996). Radical ou morfemaé a parte invariante de uma palavra que explicita o significado da mesma, isto é, o sentidode um termo é mantido mesmo sem prefixo e/ou sufixo (Michaelis, 2009). Assim, stemming

é aplicado com o intuito de identificar e eliminar frases redundantes, pois muitas sentençaspodem ser consideradas distintas por causa da variação de uma palavra, por exemplo, mucosa

terço distal erosão e mucosa terço distal erosões representam uma mesma observação, masestão escritas de formas diferentes. Ao aplicar stemming nessas frases, obtém-se muc terç dist

eros para ambos os casos.

Nesse sentido, na literatura foram propostos diversos métodos para a aplicação de stem-

ming, dos quais se destaca o Stemmer de Porter (Porter, 1997), que é um algoritmo de remoçãode sufixos de palavras em inglês. Nesse algoritmo, a remoção de sufixos é exclusivamente base-ada em regras, sem o uso de outras estruturas para realização de operações de busca, tais comolistas de exceções e/ou dicionários de dados. Essas regras são escritas na forma S1 → S2, emque o sufixo S1 é substituído por S2. Por exemplo, a regra ”ico” → ¨¨ elimina os sufixos depalavras terminadas com "ico", como a palavra médico, que é transformada em méd.

Com base no Stemmer de Porter, foram desenvolvidos métodos de aplicação de stemming

para a remoção de sufixos de palavras escritas em outros idiomas. Em (Orengo and Huyck,2001), foi proposto um método de aplicação de stemming em termos escritos em português,o qual foi implementado pelo grupo de pesquisa do LABI para ser utilizado no PMLM. Essemétodo é aplicado em oito passos, que são apresentados a seguir:

1. Transformação de termos plurais para singular;

2. Conversão de substantivo feminino para masculino;

3. Redução de advérbio para verbo infinitivo ou adjetivo masculino singular;

4. Transformação de substantivo diminutivo/aumentativo para singular;

5. Remoção de pronomes;

6. Eliminação de sufixos de verbos;

7. Exclusão da última vogal;

8. Remoção de acentuação.

35

No PMLM, os passos 3 e 8 não são necessários para o processamento de termos, poisjá são aplicados anteriormente nos métodos apresentados nas Seções 3.3.2 e 3.3.4, respectiva-mente. Na Figura 3.8 é ilustrado graficamente um exemplo de aplicação de stemming em umconjunto de frases normalizadas e sem a presença de stopwords.

Figura 3.8: Exemplo de aplicação de stemming.

No entanto, a aplicação de stemming pode acarretar, em alguns casos, na perda da legi-bilidade de termos, dificultando a compreensão de algumas palavras. Também, a redução dostermos para o seu radical pode conduzir eventualmente a uma interpretação semântica incorretadevido à existência de termos com significados diferentes, mas com radicais iguais (Fuller andZobel, 1998). Um exemplo disso são as palavras média e médico que tem o mesmo radical méd,mas os significados são distintos.

Desse modo, com a finalidade de amenizar esses problemas de representação do conheci-mento, neste trabalho também é proposta a substituição do método de stemming pela técnica deaplicação de lematização, que é apresentada na próxima seção.

3.3.6 Aplicação de Lematização

Laudos textuais médicos contém um vasto vocabulário de termos, apresentados na litera-tura médica, para descrição de procedimentos médicos, diagnóstico de enfermidades e outrasinformações. Entretanto, há termos que se diferenciam apenas morfologicamente, mas possuem

36

o mesmo significado (Ananiadou and Mcnaught, 2005). Essa variedade morfológica aumenta acomplexidade das informações presentes em laudos médicos, dificultando a aplicação de méto-dos e de ferramentas computacionais para a análise desses dados. Para amenizar a complexidadedessas informações, podem ser aplicadas técnicas de lematização (lemmatization) com a finali-dade de reduzir a variabilidade de termos (Abacha and Zweigenbaum, 2011; Liu, Christiansen,Jr. and Verspoor, 2012).

A lematização tem como objetivo transformar morfologicamente cada termo para a suaforma canônica, denominada lema, que é a forma simplificada de um termo, como o singularde um substantivo plural, a forma infinitiva de um verbo conjugado, o masculino do substantivofeminino, entre outros. Assim, a lematização consiste em um processo de redução de termosonde diferentes variações morfológicas de uma palavra são transformadas para um lema basecomum, reduzindo o número total de termos distintos (Chrupala, 2006; Jongejan and Dalia-nis, 2009). Esse processo pode ser realizado por meio da busca em um Dicionário de Lemas(DL) e/ou do uso de Regras de Lematização (RL). O DL consiste em uma estrutura de dados emque são registradas palavras não canônicas e os seus respectivos lemas (Branco and Silva, 2007).As RL tem como objetivo substituir afixos de termos não canônicos por afixos que os tornamcanônicos (Nunes, 2007). Os verbos na língua portuguesa em forma canônica, por exemplo,geralmente possuem sufixos "ar" (chamar, trabalhar, conversar), "er" (poder, torcer, crescer),"ir" (pedir, surgir, sorrir), "or" (repor, transpor) ou "ôr" (pôr). Neste caso, o método de lema-tização substitui os sufixos dos verbos conjugados, como os sufixos de verbos "ou" (agonizou),"rá" (terminará), "ei" (estudei) ou "ado" (recortado) são substituídos pelo su?xo "ar" (agonizar,terminar, estudar, recortar), por um dos cinco sufixos apresentados anteriormente usando RL.

Na Figura 3.9 é apresentado um modelo de conjunto de RL para processamento de verbose um exemplo de aplicação para cada RL exibida.

Figura 3.9: Exemplo de conjunto de regras para lematização de verbos.

A RL de número dois apresentada na Figura 3.9, por exemplo, tem como finalidade subs-tituir sufixos de verbos conjugados para o tempo passado que terminam com ado pelo sufixoar, transformando esse verbo para a sua forma infinitiva. Assim, uma regra pode englobarum grande número de lemas, não sendo necessário listá-los explicitamente em um lista, comoocorre em caso de lematizadores que utilizam DL (Branco and Silva, 2007). No entanto, paracada RL pode haver exceções que devem ser tratadas de modo que evite as transformaçõeserrôneas de termos, como na regra "ado"→ "ar", a qual é aplicada em verbos, pois, existem

37

palavras terminadas com o sufixo ado que não são verbos, tais como: reinado, gado, lado, entreoutros.

Para a transformação de termos na sua forma canônica em uma determinada linguagem,existem dois processos principais que podem ser utilizados para isso: o derivativo e o inflexi-onal (Kanis and Skorkovská, 2010). No processo derivativo, os termos são normalizados deacordo com a sua classe morfológica, por exemplo, as palavras diagnosticou e diagnosticará

são derivadas do verbo diagnosticar. No processo inflexional, os termos são normalizados con-forme outras classes morfológicas, como o termo diagnosticadamente.

Nesse contexto, sistemas computacionais avançados de processamento textos que aplicama técnica de lematização para transformação de dados utilizam RL construídas manualmente(lematizador manual) ou automaticamente (lematizador automático). O lematizador manualutiliza DL e/ou RL construídos manualmente para processamento de termos. O lematizadorautomático constrói RL e/ou DL automaticamente durante o treinamento do lematizador a partirde conjuntos de dados, que são representados em pares (palavra não simplificada – lema). Nessaabordagem, a construção de RL é baseada na busca de maiores sub-palavras comuns em termosnão canônicos e lemas (Jongejan and Dalianis, 2009).

Assim como stemming, na literatura também foram propostas várias abordagens para alematização de palavras escritas em diversos idiomas. Por exemplo, em Juršic, Mozetic and La-vrac (2007) é apresentado um sistema denominado LemmaGen para a construção automática delematizadores, que foi aplicado em conjuntos de termos escritos em idiomas como alemão, búl-garo, esloveno, estoniano, espanhol, francês, húngaro, inglês, italiano, romeno, sérvio e tcheco.Para a geração de lematizadores, esse sistema utiliza o algoritmo de aprendizado denominadoRipple Down Rule (RDR) (Plisson, Lavrac, Mladenic and Erjavec, 2008), que tem a finalidadede construir RL automaticamente a partir do processamento de textos. Após a elaboração doconjunto de RL, novas regras podem ser adicionados ao sistema na medida em que novos exem-plos de termos são avaliados.

Em outro trabalho, foi proposto um algoritmo de lematização baseado em regras para pro-cessamento de termos nominais escritos no idioma português utilizando listas com quantidademínima de palavras (Branco and Silva, 2007). Esse algoritmo é baseado no método propostopor Porter (1997), sendo que ao invés de remover os sufixos presentes nos termos, os mesmossão substituídos por outros sufixos definidos nas RL. Também, nesse algoritmo é utilizado umconjunto de regras para desfazer mudanças nas palavras em casos de exceções para a aplicaçãode determinadas regras.

Desse modo, a lematização proporciona os mesmos benefícios da aplicação de stemming,mas tem as vantagens de facilitar a compreensão dos resultados do processamento e de possi-bilitar a manutenção da semântica dos termos processados (Korenius, Laurikkala, Järvelin andJuhola, 2004).

38

3.3.7 Definição dos Atributos da Tabela Atributo-Valor e da Ontologia

Após a aplicação do pré-processamento, os CFU resultantes são analisados em conjuntocom especialistas do domínio e utilizados para especificar os atributos e seus possíveis valoresque irão compor a base de dados (tabela atributo-valor) e serão aplicados para a representaçãode padrões relevantes que se encontram em laudos textuais, bem como são elaboradas as RMque serão aplicadas com a finalidade de mapear esses padrões para uma base de dados. Osatributos e as RM são representados por intermédio de uma ontologia, que é uma estrutura dedados utilizada para representar o conhecimento de um determinado domínio (Gruber, 2009),conforme apresentado no Capítulo 3.

Nesse sentido, o uso de ontologias possibilita a definição de esquemas flexíveis para adescrição e a classificação de termos presentes em laudos textuais médicos, bem como a repre-sentação dos atributos da tabela atributo-valor e das RM. Essas regras definem as combinaçõesde termos para o preenchimento de cada atributo com valores definidos como possíveis para opreenchimento de cada atributo.

Conforme mencionado, as RM geralmente são estruturadas para interpretar sentenças comos termos apresentados sequencialmente na forma:

• Local: corresponde aos termos que descrevem uma porção anatômica do corpo humano;

• Característica: equivale às palavras que caracterizam possíveis anormalidades ou outrasinformações importantes à respeito de um determinado local;

• Subcaracterística: representa as informações complementares de uma determinada ca-racterística.

Em laudos médicos, cada frase pode ser organizada na sequência local-característica oulocal-característica-subcaracterística. Por exemplo, na frase esôfago com úlcera de 8 mm, oesôfago é uma porção anatômica (local), a úlcera é uma anormalidade observada no esôfago(característica) e o termo 8 mm é a extensão da úlcera (subcaracterística).

Na Figura 3.10 é ilustrado um exemplo de esquema de ontologia para a representação deatributos e de RM:

• Thing: é a classe principal da maioria das ontologias e corresponde a todos os indivíduosrepresentados por essas estruturas;

• Atributo: é a classe responsável por agrupar todos os atributos de uma tabela atributo-valor e é dividida em duas subclasses:

– Nome_atributo: é a classe que representa o nome do atributo;

39

– Tipo_atributo: indica os valores possíveis para o atributo.

• Termo: constitui os termos que podem ser encontrados em laudos textuais e é compostapor duas classes:

– Região: que descreve as porções anatômicas do corpo humano;

– Observações: determina as informações sobre uma região do corpo humano. Essaclasse é divida em duas classes:

∗ Característica: equivale às descrições sobre uma região;∗ Subcaracterística: representa as informações complementares sobre uma ca-

racterística.

Figura 3.10: Exemplo de esquema de ontologia para mapeamento de laudos médicos.

Geralmente, os atributos representados por uma ontologia são nomeados de modo que sejafacilitada a identificação dos mesmos, adotando padrões de nomenclatura local_característica,local_característica_subcaracterística ou outros formatos que sejam compatíveis com a RM.Nesse sentido, a relação local-característica pode gerar no máximo um atributo e a relação

40

local-característica-subcaracterística pode gerar no mínimo dois atributos. Por exemplo, nafrase esôfago com úlcera de 8 mm, podem ser definidos dois atributos para compor a tabelaatributo-valor: "esofago_ulcera", que consta presença ou ausência de úlcera no esôfago, ou seja,os valores desse atributos são booleanos (verdadeiro ou falso); e "esofago_ulcera_extensoa",que representa a extensão da úlcera no esôfago, isto é, os valores devem ser numéricos.

3.4 Segunda Fase

Na Figura 3.11 é ilustrada a segunda fase do processo de mapeamento, que é aplicadasequencialmente na seguinte forma: primeiramente é selecionado o conjunto de laudos a serprocessado, podendo opcionalmente ser escolhido o conjunto utilizado na primeira fase. Emseguida, as técnicas selecionadas para o processamento de textos como normalização, remoçãode stopwords, stemming e/ou padronização são aplicadas nesses laudos com a finalidade deuniformizá-los, reduzindo a complexidade de suas sentenças. Após, em cada laudo é aplicado oalgoritmo de mapeamento com o auxílio de uma ontologia, preenchendo a tabela atributo-valor.

Figura 3.11: Segunda fase do PMLM baseado em ontologia (Modificado de Lee, Oliva, Ma-letzke, Machado, Voltolini, Coy, Fagundes and Wu (2013)).

Essa etapa tem como propósito preencher a tabela atributo-valor, definida anteriormentecom os dados contidos no conjunto de laudos textuais digitais. Nessa etapa, o processamentoé realizado automaticamente, pois não há interação com o usuário, sendo necessária apenas aescolha do conjunto de laudos a serem processados e o uso das estruturas definidas na etapaanterior, como a stoplist e o AP para a uniformização dos laudos e a ontologia para a realização

41

do mapeamento com base nas RM definidas (Lee, Oliva, Maletzke, Machado, Voltolini, Coy,Fagundes and Wu, 2013). Essa transcrição é realizada por meio de um algoritmo especializado,que processa cada frase dos laudos mediante o casamento de padrões, utilizando RM represen-tadas em uma ontologia. Assim, para cada laudo é gerado um registro com valores de cadaatributo presente na ontologia. Esses registros compõem a tabela atributo-valor, representandoo conjunto de laudos estruturadamente (Costa, Ferrero, Lee, Coy, Fagundes and Chung, 2010).

O método de mapeamento de laudos por meio de ontologias é aplicado em três eta-pas (Costa, Ferrero, Lee, Coy, Fagundes and Chung, 2009), as quais são apresentadas a seguir:

1. Divisão de laudos em sentenças: cada laudo textual selecionado para a aplicação dométodo de mapeamento é dividido em um conjunto de sentenças;

2. Processamento das sentenças: cada termo presente nas sentenças é processado e vincu-lado a uma propriedade de acordo com a sua classificação na ontologia. Caso um termonão seja identificado na ontologia, o mesmo é incluído em uma lista de termos não pro-cessados. Após, as palavras identificadas são associadas com as RM, definindo quais sãoos atributos a serem preenchidos e os seus respectivos valores;

3. Preenchimento de atributos não-mapeados: após o processamento de cada sentença,os atributos que não foram mapeados são preenchidos com o caractere traço (”-").


O PMLM apresenta grande importância para a padronização e a representação de laudostextuais no contexto de aplicação da Mineração de Dados (MD) para a extração de padrõesrelevantes. Isso pode contribuir com a geração de novos conhecimentos, tais como a descobertade fatores que aumentam o risco de enfermidades, a criação de novas técnicas para o diagnósticode doenças, o desenvolvimento de novos medicamentos, a construção de modelos preditivospara auxiliar especialistas da área médica em tomadas de decisão, entre outros.

Esse processo foi avaliado em trabalhos anteriores e apresentaram resultados considera-dos satisfatórios, tanto para a abordagem baseada em DC (Cherman, Lee, Honorato, Fagundes,Góes, Coy and Wu, 2007; Honorato, Cherman, Lee, Monard and Wu, 2007; Cherman, Spolaôr,Lee, Costa, Fagundes, Coy and Wu, 2008; Honorato, Cherman, Lee, Monard and Chung, 2008),quanto a baseada em ontologia (Costa, Ferrero, Lee, Coy, Fagundes and Chung, 2009; Costa,Ferrero, Lee, Coy, Fagundes and Chung, 2010).

A ontologia se apresenta como uma estrutura de dados mais flexível e representativa paraa aplicação do método de mapeamento de laudos médicos em relação ao DC. É possível ob-servar essa característica na Figura 3.10, na qual no DC a relação local-característica e/ou

42

local-característica-subcaracterística, bem como os atributos e seus respectivos valores são re-presentados em uma única classe, o que se caracteriza como uma estrutura de dados com poucaflexibilidade para representação do conhecimento. Nesse sentido, caso seja necessária a descri-ção de RM mais complexa e/ou em outros formatos, pode ser necessária a alteração de toda aestrutura do DC ou a geração de um novo esquema.

Com a substituição do DC por uma ontologia, o problema de representação do conheci-mento é amenizado, pois cada tipo de termo é descrito por uma classe específica, facilitando oreaproveitamento dessa estrutura para a elaboração de RM em diversos formatos.

No entanto, como apresentado anteriormente, todas as técnicas utilizadas no PMLM de-vem ser executadas manualmente e separadamente em todas as suas etapas, dificultando, princi-palmente, o seu uso por profissionais que não são da área computacional ou que não conheçamdetalhadamente o processo. O desenvolvimento de um sistema computacional para automatizare facilitar o uso do processo é portanto de grande valia.

Para a construção de um sistema confiável e com qualidade, é necessária a aplicação deabordagens sistemáticas e disciplinadas de engenharia de software. Sendo assim, no Capítulo 4são apresentados métodos de engenharia de software que visam orientar na construção de siste-mas computacionais.

Capítulo 4

Desenvolvimento de SistemasComputacionais


Atualmente, os Sistemas Computacionais (SC) 1 apresentam grande importância no cená-rio mundial, sendo indispensável para os negócios, a ciência, a engenharia e a criação de novastecnologias. O SC está embutido em diferentes domínios, como médico, militar, transporte, co-municação, industrial, entretenimento, entre outros. Esses sistemas são produtos resultantes daaplicação de processos de engenharia de software para a execução de um conjunto de instruções,que são realizados sequencialmente para a manipulação de informações (Pressman, 2011).

A engenharia de software consiste em uma área da computação relacionada com a pro-dução de software, focada na sua especificação, desenvolvimento e manutenção, definição eaplicação de tecnologias e métodos adequados, gerenciamento de projetos e outras atividadescom a finalidade de garantir a organização, a produtividade e a qualidade na construção dosoftware (Sommerville, 2009).

O processo de desenvolvimento de software pode ser realizado por meio de vários mode-los de processos que são aplicados de acordo com o tamanho da equipe de desenvolvimento, acomplexidade dos requisitos, o nível de risco do projeto e o domínio do problema a ser resol-vido (Pfleeger, 2004).

Sendo assim, na Seção 4.2 são apresentados alguns conceitos e um exemplo de processode software. Após, são apresentadas as principais tarefas dos processos de software, como aatividade de levantamento de requisitos (Seção 4.3). Na Seção 4.4 é apresentada a atividade deprojeto de SC. Na Seção 4.5 é abordada a atividade de codificação dos requisitos de software ena Seção 4.6 são descritas algumas técnicas de testes de SC.

1Neste trabalho, sistema, software e programa são considerados sinônimos.

43

44

4.2 Processo de Software

O processo de software, também denominado ciclo de vida de software, consiste em umconjunto de atividades necessárias para a construção de um SC. Esse conjunto de atividades éexecutados de forma sequencial, gerando como produto final um SC. Atividade é uma fase doprocesso de software caracterizada como um grupo de tarefas imprescindíveis para atingir umobjetivo amplo, como o planejamento da construção do programa. A tarefa é concentrada emum objetivo pequeno e bem definido, por exemplo, a escolha de tecnologias para o desenvolvi-mento da solução computacional (Pfleeger, 2004; Sommerville, 2009).

Basicamente, um processo de software é constituído por cinco atividades (Pressman,2011):

• Comunicação: são realizadas reuniões em conjunto com os interessados no projeto paraidentificar e compreender as necessidades dos futuros usuários por meio do levantamentode requisitos para a definição das características que deverão ser atendidas pelo sistema;

• Planejamento: são descritas as tarefas técnicas a serem desempenhadas, os riscos possí-veis, os recursos necessários, o cronograma de trabalho e os resultados esperados;

• Modelagem: são criados os modelos computacionais e/ou gráficos para facilitar a com-preensão das necessidades do usuário e como as mesmas deverão ser atendidas;

• Construção: é gerado o código-fonte do SC com base nas especificações do planeja-mento e nos modelos construídos, bem como são elaborados testes com o objetivo deidentificar os erros na codificação;

• Emprego: o SC é entregue aos usuários finais, que o avaliam e fornecem um feedback.

Nesse sentido, o processo de software é aplicado de modo iterativo e interativo, no qualcada iteração do processo resulta em um incremento do SC. Sendo assim, é importante ressaltarque todos processos de software tem como entrada a definição das necessidades do usuário ecomo saída uma versão do programa. O ciclo de desenvolvimento de software é comumenterepetido várias vezes, na medida em que o requisitos são incrementados, atualizados ou remo-vidos (Pfleeger, 2004).

Para oferecer suporte às atividades do processo de software no decorrer da execução doprojeto, podem ser realizadas algumas atividades de apoio (Pressman, 2011), como:

• Controle e acompanhamento do projeto, no qual é avaliada a evolução do desenvolvi-mento do projeto, tomando medidas necessárias para o cumprimento do cronograma deexecução;

45

• Administração de riscos, em que são avaliados possíveis problemas que possam afetar noresultado e/ou na qualidade do sistema;

• Garantia de qualidade, que conduz tarefas para garantir o desenvolvimento de softwareque atenda satisfatoriamente as especificações levantadas;

• Revisões técnicas, na qual são avaliados todos os documentos da engenharia de software,também denominados artefatos, com o objetivo de identificar os possíveis erros para evi-tar problemas na aplicação das atividades seguintes;

• Medição, que determina critérios para medir a qualidade e o progresso do SC, podendoser utilizadas nas demais atividades do processo de software;

• Gerenciamento de configuração, que tem o propósito de controlar os efeitos das mudançasao longo da aplicação do processo;

• Gerenciamento da reusabilidade, em que são definidos os critérios para o reuso dos arte-fatos e estabelecidos mecanismos para o uso dos componentes reutilizáveis;

• Produção de artefatos, que define as tarefas necessárias para elaborar artefatos, comomodelos, documentos textuais, diagramas, formulários, código-fonte, entre outros.

No entanto, um único modelo de processo de software não é adequado para a aplicaçãoem todos projetos de sistemas. Nesse sentido, os processos de software podem ser aprimoradosmediante padronizações dos mesmos, que são denominados modelos de processo, os quaissão representações abstratas do processo de software, representando-o em uma determinadaperspectiva (Sommerville, 2009). O objetivo de um modelo processo de software é guiar, demodo sistemático, a aplicação das tarefas fundamentais para garantir a construção de um sistemaque atenda aos objetivos do projeto e as necessidades dos usuários por intermédio da definiçãode um conjunto de tarefas a serem executadas, a entrada, a saída, as condições, a sequência e ofluxo de cada tarefa (Tsui and Karam, 2013).

Assim, na literatura foram propostos vários modelos de processo de software, os quaissão utilizados de acordo com o tipo e a complexidade dos requisitos, como o modelo ágil dedesenvolvimento por prototipagem, que é apresentado seguir.

Modelo de Desenvolvimento de Sistemas por Prototipagem

Prototipagem é uma abordagem da engenharia de software para construção de soluçõescomputacionais de modo ágil. Esse modelo se apresenta adequado quando os requisitos sãoconsiderados complexos e há a necessidade de maior participação dos usuários no processo dedesenvolvimento do sistema (Pressman, 2011). Na Figura 4.1 é ilustrado o ciclo do modelo dedesenvolvimento por prototipagem, que é constituído de cinco etapas:

46

1. Comunicação: é realizado o levantamento de requisitos por meio de reuniões em con-junto com os interessados no projeto para definir as funcionalidades que deverão ser exer-cidas pelo novo SC;

2. Plano rápido: os requisitos levantados na etapa anterior são analisados e estudados coma finalidade de verificar a viabilidade do desenvolvimento de um software. Em seguida,é realizado um planejamento rápido para a construção de uma solução computacional.Assim, são estruturadas as necessidades dos usuários por intermédio da interpretação dosrequisitos e são estudados os métodos e tecnologias existentes que podem prover apoiono desenvolvimento do software;

3. Modelagem: a partir das especificações levantadas nas etapas anteriores, são criadosmodelos com a finalidade de facilitar a compreensão dos requisitos;

4. Construção do protótipo: o software é implementado por meio de uma linguagem deprogramação apoiado por um ambiente de desenvolvimento e de outras ferramentas com-putacionais. Durante e após a codificação, são realizados testes no sistema com a finali-dade de identificar e corrigir erros que podem afetar o desempenho do processamento, aintegridade e a segurança dos dados;

5. Avaliação e feedback: o SC é entregue aos usuários finais, os quais verificarão se foramatendidos satisfatoriamente os requisitos levantados. Após a avaliação, os usuários forne-cem feedback com sugestões definindo os requisitos que devem ser incluídos, removidose/ou alterados.

Figura 4.1: Modelo de desenvolvimento por prototipagem (Modificado de Pressman (2011)).

Na Figura 4.1, é possível observar que a construção do sistema é iniciada com um con-junto simples de requisitos. No decorrer da execução do ciclo de desenvolvimento, os requisitossão ajustados e detalhados. O planejamento para a construção da solução computacional é apri-morado por meio do desenvolvimento de modelos. Ao final, o SC é implementado utilizandouma linguagem de programação e após a realização de testes, o mesmo é entregue aos usuáriospara avaliação e validação. Assim, cada atividade do ciclo pode ser repetida inúmeras vezes namedida em que novos requisitos são levantados e erros são encontrados (Pfleeger, 2004).

47

4.3 Levantamento de Requisitos

O levantamento de requisitos é realizado por meio de reuniões em conjunto com usuáriose/ou outros interessados no projeto com o objetivo de estabelecer as necessidades que devem seratendidas em um SC (Pfleeger, 2004). Essa fase de construção de software ocorre no início dociclo de desenvolvimento, podendo ser repetidas mais de uma vez, até atender satisfatoriamenteas especificações levantadas, dependendo do modelo de construção de sistema abordado.

Na engenharia de software, requisitos são descrições das funcionalidades que o programadeve oferecer, as quais são documentadas e revisadas no decorrer do desenvolvimento do pro-jeto do SC (Sommerville, 2009). Essas descrições podem ser do tipo explícito, normativo ouimplícito (Filho, 2009). Os requisitos explícitos são descritos, em linguagem natural, em docu-mentos textuais.

Os requisitos normativos descrevem as aplicações que devem seguir normas impostas porleis, padrões, regras, entre outros. Os requisitos implícitos são as funções esperadas por clientesque não são documentadas, como tratamento de segurança de dados, desempenho, entre outros.

Dessa maneira, os requisitos são geralmente classificados em dois tipos: funcionais enão-funcionais (Pressman, 2011; Sommerville, 2009). Os requisitos funcionais são relacio-nados diretamente com as funcionalidades do sistema, isto é, definem a entrada de dados, ocomportamento do SC e a saída de dados. Esses requisitos incluem o processamento de da-dos, a realização de cálculos, entre outras aplicabilidades que o programa deverá atender. Osrequisitos não-funcionais descrevem as restrições de uso do software, tais como segurança, de-sempenho, tecnologias auxiliares, entre outros.

Nesse contexto, o final dessa fase resulta em um conjunto de requisitos. Entretanto, no de-correr da construção do software podem haver mudanças e alternativas na medida em que ocor-rem diálogos com os usuários durante todas as etapas de cada ciclo de desenvolvimento. Comisso, é importante ressaltar que, para a produção bem sucedida de uma solução computacional éimprescindível a compreensão detalhada dos requisitos, sendo que um levantamento deficientepode influenciar negativamente nas fases seguintes da elaboração do sistema (Pfleeger, 2004).

4.4 Projeto de Software

Antes da elaboração do projeto de software, os requisitos levantados inicialmente sãoanalisados e estudados detalhadamente com a finalidade de verificar a viabilidade tecnológica eeconômica para o desenvolvimento de uma solução computacional que atenda as especificaçõesdesses requisitos (Pressman, 2011). Caso seja viável a construção, é iniciada a elaboração doprojeto do SC, bem como são definidas as tecnologias necessárias para esse fim.

48

O projeto de software tem o objetivo de traduzir os requisitos para documentos em for-matos textuais e/ou gráficos, definindo como o sistema deve ser desenvolvido. Assim, sãodefinidas as tarefas que serão desempenhadas pelo programa, os riscos possíveis do desenvol-vimento do projeto, a arquitetura do SC, os elementos da interface, os recursos necessáriospara a implementação da solução computacional, o cronograma de execução do trabalho, entreoutras (Braude, 2005). Para melhor descrição dos requisitos do programa, cinco modelos deprojeto podem ser aplicados simultaneamente (Pressman, 2011):

• Projeto de dados/classes: definição de modelos de dados, também denominado estruturade dados, que serão manipulados pelo sistema;

• Projeto arquitetural: definição dos tipos de relacionamentos entre modelos de dados,a arquitetura do SC e os padrões de projeto que podem ser aplicados para atender asespecificações levantadas anteriormente;

• Projeto de interface: tem a finalidade de determinar o modo de interação da soluçãocomputacional com outros softwares e com os usuários que o utilizarão;

• Projeto em nível de componente: descreve o comportamento de cada elemento do SC,isto é, os algoritmos para o processamento de dados que ocorre em um elemento e/ou emuma interface que executa todas as operações desses componentes;

• Projeto em nível de implantação: determina os recursos tecnológicos necessários paraa implantação do sistema, como o ambiente computacional físico e os subsistemas queirão interagir com o novo software.

Nesse contexto, o gerenciamento de projetos consiste em uma tarefa essencial para aconstrução de software e tem o propósito de assegurar que essa tarefa seja realizada correta-mente. Para o gerenciamento de projetos de sistemas, são comumente executadas as seguintesatividades: preparação da proposta; planejamento do desenvolvimento; elaboração do crono-grama; estimativa de custos e de riscos; monitoração e revisões de projeto; seleção e avaliaçãode integrantes; preparação de relatórios; e apresentações dos resultados (Sommerville, 2009).

O gerenciamento de projetos pode ser aplicado em quatro fases (Tsui and Karam, 2013),que são apresentadas na Figura 4.2.

Na fase de planejamento, são determinados os resultados esperados do projeto, o cro-nograma de execução, os recursos necessários, as metas a serem alcançadas, as medidas dequalidade e os riscos do projeto. Na fase de organização, são definidos os mecanismos parao monitoramento das tarefas e do cronograma, os recursos imprescindíveis para o desenvolvi-mento do projeto, os meios para mensurar e monitorar os objetivos e as medidas para listar,acompanhar e minimizar os riscos. Na fase de monitoramento é acompanhada a execução doprojeto para verificar se a construção do mesmo está progredindo como planejado. Essa fase

49

Figura 4.2: Processo de gerenciamento de projetos (Modificado de Tsui and Karam (2013)).

é realizada por meio da coleta de informações do projeto, da análise dos dados coletados e daapresentação das informações por intermédio de reuniões com os envolvidos. Na fase de ajuste,são realizadas as alterações no projeto para adequá-lo com os novos requisitos, os problemasencontrados durante a elaboração do software, entre outros.

Também, outras técnicas e ferramentas podem ser utilizadas para o desenvolvimento deprojetos de software, como a Unified Modeling Language (UML) 2, que é uma linguagem pa-drão de modelagem, de especificação e de documentação de SC, comumente utilizada para essefim. Nessa linguagem, são desenvolvidos diversos diagramas, dos quais cada tipo de diagramaé utilizado para representar diferentes partes e detalhes do SC com a finalidade de eliminar ouminimizar possíveis erros de projeto (Miles and Hamilton, 2006).

4.5 Implementação

A maioria dos projetos de engenharia de software tem o intuito de construir um SC fun-cional (Tsui and Karam, 2013). Nesse sentido, na etapa de implementação, os requisitos e osmodelos computacionais são codificados por meio de uma linguagem de programação com su-porte de um ambiente de desenvolvimento (Pressman, 2011). Para essa tarefa, existem váriaslinguagens de programação que são utilizadas para construção de programas de acordo com asnecessidades dos usuários, como Java 3, Ruby 4, Python 5, entre outras. A implementação desistemas pode ser facilitada com o uso de ambientes de desenvolvimento e de outras ferramentascomputacionais, auxiliando e automatizando a tarefa de geração de código-fonte.

2http://www.uml.org/3http://www.java.net/4http://www.ruby-lang.org/pt/?5http://www.python.org/

50

Durante a etapa de construção do programa, os desenvolvedores devem escrever o código-fonte de forma simples e compreensível, adotando padrões de programação das linguagens uti-lizadas para reduzir custos e facilitar as atividades de manutenção, de revisão e de reuso. Assim,para a codificação de softwares, alguns aspectos gerais de programação devem ser considera-dos, tais como: conjuntos de algoritmos que devem ser utilizados para atender os requisitos dousuário; entrada e saída de dados para o uso dos algoritmos; estruturas de controle para coorde-nar o fluxo de dados do sistema; estrutura de dados para organizar os algoritmos e simplificar aconstrução do SC; revisões do código-fonte com a finalidade de aprimorá-lo; e reutilização decódigos-fonte desenvolvidos em outros projetos para facilitar a elaboração da solução computa-cional. Também, o código-fonte dever ser documentado para facilitar a compreensão da lógicainterna do software, auxiliando nas manutenções futuras do mesmo (Pfleeger, 2004).

De acordo com Tsui and Karam (2013), para uma boa codificação de sistemas, os desen-volvedores devem considerar as seguintes características:

• Legibilidade: o código-fonte deve ser escrito de forma que facilite a sua leitura e compre-ensão por outros desenvolvedores;

• Manutenibilidade: o código-fonte deve ser facilmente alterado e mantido;

• Desempenho: os algoritmos devem ser produzidos de modo que a sua execução sejarealizada o mais rápido possível;

• Rastreabilidade: o código do sistema deve corresponder a um elemento de design, ouseja, garantir que o software seja desenvolvido corretamente;

• Exatidão: o código-fonte deve ser escrito para fazer exatamente as tarefas para o qual foiconstruído;

• Integralidade: todos os requisitos devem ser atendidos satisfatoriamente.

Entretanto, uma codificação mal realizada e mal documentada pode implicar na geraçãode um software deficiente, mesmo funcionando corretamente, dificultando a realização de al-terações, o reuso dos componentes de software em outros projetos e a compreensão da lógicainterna por outros integrantes do projeto (Tsui and Karam, 2013).

4.6 Testes de Software

O teste de software é um conjunto de tarefas projetadas antecipadamente para desem-penhar as funcionalidades do sistema com o propósito de identificar erros que influenciam nofuncionamento correto dos algoritmos, tal como na integridade e na segurança dos dados pro-cessados pelo programa (Pressman, 2011).

51

A realização de testes em SC consiste em uma tarefa complexa e altamente custosa, re-presentando cerca de 50% a 80% do custo total do desenvolvimento do projeto. Os testes desoftware são utilizados de forma controlada para verificar a concordância de suas funcionalida-des em relação às especificações levantadas e expôr as suas falhas de forma antecipada à suaentrega ao usuário final (Sommerville, 2009).

Nesse contexto, foram propostas várias abordagens para a avaliação de sistemas, as quaissão divididas em testes dos tipos caixa-branca, caixa-preta e e caixa-cinza. O teste caixa-branca,também denominado teste estrutural ou orientado à lógica, tem o objetivo de avaliar a lógicainterna dos componentes de um determinado SC. O teste caixa-preta, igualmente denominadoteste funcional, orientado a dados ou a entrada/saída, tem a finalidade de avaliar o comporta-mento do programa em relação à entrada de dados e são conduzidas por meio de uma interfacegráfica. O teste caixa-cinza consiste na combinação das técnicas caixa-branca e caixa-preta paraa avaliação do SC (Myers, Badgett, Sandler and Thomas, 2004; Sommerville, 2009; Tsui andKaram, 2013; Lewis, 2008).

Geralmente, as avaliações de software são realizadas em várias etapas: teste de unidade,teste de integração, teste de sistema e teste de aceitação. Essas etapas são ilustradas na Fi-gura 4.3 e apresentadas em seguida.

Figura 4.3: Etapas do teste de software (Jung, 2012).

O teste de unidade tem o intuito de avaliar isoladamente cada membro do SC. Essa abor-

52

dagem é focada na lógica interna do processamento e nas estruturas de dados que envolvem umcomponente e pode ser aplicado em paralelo com outros testes de unidade (teste de integração).O planejamento do teste unitário pode ser realizado antes, durante e depois da codificação dosistema (Pressman, 2011).

O teste de integração é uma técnica utilizada para identificar falhas de agregação dosmembros de SC testados anteriormente, isto é, os componentes são combinados e avaliadosem grupo. Esse teste tem o propósito de avaliar os requisitos funcionais, o desempenho e amodelagem da solução computacional para descobrir erros relacionados com a interface. Paraisso, foram propostas várias abordagens, das quais se destacam as técnicas bottom-up e top-

down (Pfleeger, 2004). O teste bottom-up é uma abordagem incremental que avalia os elementosdo programa hierarquicamente, começando com pequenos grupos de componentes combinados,nos quais são incrementados alguns elementos (unidades de componentes e/ou outros grupos)no decorrer da evolução dos testes, até que todos os componentes estejam integrados a um únicogrupo. O teste top-down é o inverso de bottom-up, ou seja, a avaliação é iniciada com todos oscomponentes integrados em um único grupo, o qual é fragmentado em pequenos grupos até quetodas as falhas identificadas serem isoladas.

O teste de sistema é aplicado para avaliar o SC como um todo por meio da execução detodas as suas funcionalidades, sob o ponto de vista do usuário final. Esse tipo de teste englobadiversos tipos de avaliações que são vantajosas para a construção de SC (Pressman, 2011),tais como: teste de recuperação, que é executado para forçar o programa de várias maneiraspara falhar e verificar se a recuperação de falhas é realizada corretamente; teste de segurança,que é utilizado para examinar os métodos de proteção usados na solução computacional com opropósito de garantir que os dados dos usuários estejam protegidos de acessos indevidos; testepor estresse, que avalia o SC em situações anormais, como a demanda de recursos em termos dequantidade, frequência e/ou intensidades consideradas anormais; teste de desempenho, o qual éusado com o objetivo de assegurar que o sistema pode operar o volume necessário de dados, queé aumentado até o comportamento do SC ser considerado inaceitável e é realizado em todas asetapas de testes; e teste de disponibilização, que examina a operação do software em diferentestipos de plataformas.

O teste de aceitação é focado nas atividades que serão desempenhadas pelo usuário. Paraisso, são definidos os critérios a serem considerados na validação por intermédio de um planode avaliação que define os tipos de testes que serão conduzidos com o intuito de garantir quetodos os requisitos sejam atendidos satisfatoriamente, todas as características comportamentaisanormais sejam identificadas e que todos os dados originados pelo sistema sejam confiáveis eapresentados adequadamente. Nesse sentido, os testes de aceitação são realizados inicialmentepor desenvolvedores em ambiente controlado e são caracterizados como testes alpha. Após arealização dos testes e correção dos erros identificados pelos desenvolvedores, o SC é entregueaos usuários finais para avaliarem as suas funcionalidades com a finalidade de identificar erros

53

que não foram identificados pelos desenvolvedores. Essa avaliação é também conhecida comoteste beta (Sommerville, 2009).

Desse modo, os testes são realizados enquanto os erros forem encontrados e soluciona-dos. Assim, quando as avaliações forem bem-sucedidas, o sistema é entregue aos usuários.Entretanto, podem ser necessárias algumas adaptações para o melhor aproveitamento e funcio-namento da solução computacional, como o treinamento dos usuários e a aquisição de hardwaree software (Laudon and Laudon, 2007).


Para a construção de SC, o processo de software apresenta-se como uma abordagem degrande importância para o sucesso do projeto, o qual é uma ferramenta relevante para o de-senvolvimento de uma solução computacional de qualidade, pois possibilita a organização dasatividades a serem ministradas, o estudo e a análise dos riscos, o gerenciamento de equipes,a estipulação de custos, entre outros. Para o êxito e a entrega do sistema dentro do prazo es-tipulado, é necessário que cada atividade do processo seja realizada cuidadosamente, desde ainiciação até o final do projeto, de modo que garanta a entrega de um produto de qualidadesatisfatória e que facilite a realização de manutenções futuras. Outro recurso importante paraa construção de programas é o uso da UML, que facilita a compreensão e o registro exato dosrequisitos por meio da elaboração de modelos e de diagramas.

Neste trabalho foi utilizado o modelo ágil de desenvolvimento de sistemas por prototi-pagem devido à complexidade dos requisitos e a necessidade do envolvimento de especialistasdo domínio para acompanhar a construção de um Sistema Computacional Colaborativo (SCC)com a finalidade de automatizar o Processo de Mapeamento de Laudos Médicos (PMLM). NoCapítulo 5 são apresentadas as tecnologias que foram utilizadas para o desenvolvimento do SCCpara a automatização do PMLM apresentado neste trabalho.

Capítulo 5

Ferramentas e Tecnologias


Uma área tecnológica em crescente evolução é o de desenvolvimento de sistemas webdevido à facilidade e a agilidade no seu uso, pois não são necessários computadores sofisticados,bem como é dispensável a instalação de softwares específicos e a configuração da máquina parautilizar um sistema web. Outra vantagem é a não ocupação de espaço no disco ou em outrodispositivo de armazenamento do usuário. Com essas características, o usuário pode acessar osistema por meio de computadores, sendo necessário apenas que um navegador web como oMozila Firefox 1, o Opera 2, o Internet Explorer c©, ou o Google Chrome 3 esteja instalado namáquina do usuário e que haja acesso à Internet.

Para a construção de sistemas web é necessário o uso combinado de diversos tipos detecnologias, tais como: linguagens de programação, de marcação e de estilo; ambientes dedesenvolvimento; frameworks; e infraestrutura física, como servidores, redes de computadores,entre outros. Para o uso dessas tecnologias, é imprescindível o conhecimento técnico por partedos desenvolvedores para possibilitar a construção de sistemas web eficientes e que atendam àsespecificações de seus usuários, bem como deve ser considerado o uso de diferentes tipos denavegadores web, pois cada navegador possui características específicas que podem influenciarno funcionamento correto desses sistemas (Jung, 2012).

Desse modo, neste capítulo são apresentadas as principais ferramentas e as tecnologiasutilizadas pelo Processo de Mapeamento de Laudos Médicos (PMLM) e as que são necessá-rias para o desenvolvimento do Sistema Computacional Colaborativo (SCC) para automatizar autilização do método.

Nas Seções 5.2 e 5.3 são apresentadas algumas características das linguagens de progra-

1www.mozilla.org/pt-BR/2www.opera.com/pt-br3www.google.com/intl/pt-BR/chrome/browser/

55

56

mação Java e Ruby, respectivamente. Na Seção 5.4 é apresentado o principal framework dalinguagem Ruby que é aplicado na construção de sistemas web. Na Seção 5.5 é descrito um dosambientes de desenvolvimento de softwares mais utilizados na atualidade por desenvolvedoresde software. Na Seção 5.6 é apresentada a linguagem de programação comumente aplicada naelaboração de métodos de processamento de textos denominada Perl. Nas Seções 5.7 e 5.3 sãodescritas as linguagens de marcação HTML e XML. Na Seção 5.9 é apresentada a linguagemde estilo denominada CSS, que é comumente utilizada para a modelagem de layout de docu-mentos HTML e XML. Na Seção 5.10 é explanada a linguagem de programação Javascript, queé frequentemente usada no tratamento de eventos relacionados com a interação de páginas webcom usuários.

5.2 Linguagem de Programação Java

Java é uma das linguagens de programação mais utilizadas para o desenvolvimento deSistemas Computacionais (SC), devido à ampla variedade de recursos disponíveis (Deitel andDeitel, 2010). Essa linguagem, foi construída na década de 90 por desenvolvedores lideradospor James Gosling, na empresa Sun Microsystems 4.

Diferentemente de outras linguagens, o código-fonte escrito em Java é traduzido para umformato intermediário de código, denominado bytecode, que é interpretado por uma MáquinaVirtual Java (MVJ), a qual tem como finalidade converter os bytecodes para um código execu-tável por máquinas, bem como gerenciar aplicações desenvolvidas na linguagem Java. Com aMVJ, os softwares escritos em Java podem ser executados em qualquer sistema operacional quecontém uma MVJ instalada (Lindholm, Yellin, Bracha and Buckley, 2013).

Assim, nessa linguagem podem ser destacadas algumas características: paradigma deprogramação orientado a objetos; independência de plataforma, isto é, o software desenvol-vido nessa linguagem pode ser executado em qualquer sistema operacional; extensa bibliotecade ferramentas para auxiliar na construção de sistemas, recurso necessário para projetos queapresentam requisitos complexos para o seu desenvolvimento; simplicidade e eficiência para aconstrução de softwares, sem a necessidade do gerenciamento de memória por código, redu-zindo possibilidades de erros de programação; desalocação automática de memória por meiodo processo denominado coleta de lixo (garbage collector) (Deitel and Deitel, 2010).

Para facilitar a construção de SC por intermédio da linguagem Java, foram desenvolvidasvárias ferramentas e bibliotecas. Na Sun Microsytems, foi criado o pacote de ferramentas deno-minado Java Development Kit (JDK), que contém bibliotecas e outros recursos necessários paraa escrita de código-fonte de softwares. Também, foi desenvolvido o Java Runtime Environment

4http://www.oracle.com/us/sun/index.html

57

(JRE), o qual é uma biblioteca que inclui a MVJ e outros recursos para a execução de sistemasJava (Gosling, Joy, Steele and Bracha, 2005).

Foram construídos também diversos ambientes de desenvolvimento, denominados Inte-

grated Development Environment (IDE), que têm o propósito de reunir os principais recursospara a construção de softwares em Java, tais como JDK, JRE, entre outras ferramentas e bibliote-cas (Boudreau, Glick and Spurlin, 2002). Um dos IDE mais populares entre os desenvolvedorespara a implementação de SC em Java é o NetBeans 5, que é apresentado na Seção 5.5.

5.3 Linguagem de Programação Ruby

Ruby é uma linguagem dinâmica de código aberto focada na simplicidade e na produti-vidade para a elaboração de sistemas que foi criada em 1995 por Yukihiro "Matz" Matsumoto,o qual tinha como objetivo desenvolver uma linguagem de script mais poderosa do que Perl emais orientada a objetos do que a linguagem Python 6, combinando a programação funcionalcom a programação imperativa. Assim, a linguagem Ruby consiste na combinação das lingua-gens Perl, Smalltalk, Eiffel, Ada e Lisp. Atualmente, essa linguagem se encontra na versão2.0 e é disponível para diversas plataformas, como Windows c©, GNU/Linux, Mac OS, Solaris,entre outros (Metz, 2012).

A linguagem Ruby apresenta as seguintes características: todos os elementos utilizadossão considerados objetos, incluindo números e outros tipos de dados primitivos; o gerencia-mento de memória é realizado de modo automático; a linguagem é dinâmica e forte, permitindoo uso de variáveis sem a necessidade de declará-las ou pré-determiná-las; possui sintaxe intui-tiva, o que facilita a compreensão do código-fonte; utiliza caracteres especiais para determinara condição de uma determinada variável, como "$" e "@", os quais indicam que as variáveis sãoglobais e de instância, respectivamente; e a possibilidade de desenvolvimento de ferramentas ede disponibilizá-las em formato padrão de pacote de código, também denominado gem (Carlsonand Richardson, 2006).

Também, para a linguagem Ruby existem várias implementações alternativas, como oJRuby 7, que foi escrito na linguagem de programação Java para funcionar em MVJ e possibili-tar o uso dos recursos dessa linguagem sem a necessidade da instalação de gems e configuraçãodo computador para viabilizar o uso de ferramentas e/ou outros recursos desenvolvidos nessalinguagem por sistemas construídos em Ruby. JRuby foi desenvolvido em 2001 por Jan ArnePetersen e atualmente se encontra na versão 1.7.4, o qual oferece suporte para Ruby 2.0. OJRuby possibilita o reconhecimento de código escrito em Java e a utilização de classes da pla-

5https://netbeans.org/6http://www.python.org/7http://jruby.org/

58

taforma Java no interpretador Ruby (Nutter, Enebo, Sieger, Bini and Dees, 2011).

É importante ressaltar que a linguagem Ruby obteve maior aceitação no mercado devido,principalmente, ao desenvolvimento do framework denominado Ruby on Rails 8, o qual tambémé compatível com o JRuby. Esse framework é apresentado na próxima seção.

5.4 Framework Ruby on Rails

Ruby on Rails (RoR) consiste em um framework de código aberto e de uso gratuito quetem o intuito de agilizar a construção de sistemas web por meio de estruturas pré-definidas,baseada no modelo de desenvolvimento ágil de sistemas. Esse framework foi lançado no anode 2004 por David Heinemeier Hansson, mas os direitos para o compartilhamento do projetoforam disponibilizados apenas em 2005 (Ruby, Thomas, Hansson, Breedt, Clark, Davidson,Gehtland and Schwarz, 2011). Atualmente, o RoR se encontra na versão 4.0.1.

A arquitetura do RoR segue os preceitos do padrão Model-View-Controller (MVC), oqual tem o objetivo de organizar o código-fonte do sistema web em três camadas: model, quedetermina e gerencia as informações processadas pelo SC; view, que apresenta as informaçõesdo model de forma que seja útil ao usuário por intermédio de uma interface; e controller, quetem a finalidade de receber a entrada de dados, processá-la e apresentar os resultados ao usuá-rio (Saint-Laurent, Dumbill and Gruber, 2012). Na Figura 5.1 é ilustrado o padrão MVC, emque as setas contínuas representam o relacionamento direto entre os componentes MVC e a setatracejada representa o relacionamento indireto entre model e view.

Figura 5.1: Padrão MVC (Modificado de Ruby, Thomas, Hansson, Breedt, Clark, Davidson,Gehtland and Schwarz (2011)).

Assim, o framework RoR segue os seguintes princípios (Holzner, 2006; Húngaro, 2013):

8http://www.rubyonrails.com.br/

59

• Não se repita (Don’t Repeat Yourself - DRY): determina mecanismos para evitar anecessidade de repetição do código em diversas partes do sistema;

• Convenção sobre configuração (convention over configuration): define padrões paraa construção de sistemas com a finalidade de reduzir a necessidade de elaborar configu-rações para o funcionamento do mesmo, possibilitando que o desenvolvedor se preocupeapenas com a solução do problema;

• Controladores magros e modelos gordos (tiny controllers, fat models): estimula o há-bito de limitar as tarefas de um determinado domínio de um problema aos modelos e astarefas de controle do fluxo de dados aos controladores;

• Mantenha simples, estúpido! (Keep It Simple, Stupid - KISS): baseado em um princí-pio de origem militar, determina que a simplicidade deve ser o foco do projeto e toda acomplexidade deve ser desconsiderada ou reduzida;

• Você não vai precisar disso (you ain’t gonna need it): define que nenhuma funcionali-dade dispensável deve ser adicionada ao sistema;

• Desenvolvimento iterativo e incremental (iterative and incremental development): éa base dos métodos ágeis de construção de sistemas em que o ciclo de desenvolvimentopode ser repetido várias vezes e para cada repetição de ciclo é adicionado pelo menosuma funcionalidade;

• Desenvolva menos (build less): resultado de todos os princípios e práticas apresentadosanteriormente, possibilita a redução do processo de construção de sistemas.

Nesse sentido, RoR oferece diversos mecanismos para facilitar a construção de SC pormeio da automatização de várias tarefas, como o comando generate, que é aplicado para gerarcomponentes do sistema. Neste comando, podem ser incluídas outras instruções para a geraçãode componentes no Padrão MVC, como o scaffold, que tem o intuito de gerar uma parte dosistema no padrão MVC com toda a estrutura CRUD (Create, Read, Update, Delete), que sãoas operações básicas para manipulação de dados de um sistema, como criar, ler ou visibilizar,atualizar e excluir (Griffiths, 2009). Também,o RoR oferece suporte para o uso de diversosbancos de dados, como PostgreSQL, MySQL, Oracle, entre outros (Ruby, Thomas, Hansson,Breedt, Clark, Davidson, Gehtland and Schwarz, 2011).

5.5 Ambiente de Desenvolvimento NetBeans

Inicialmente sob o nome Xelfi 9, o projeto do NetBeans foi iniciado em 1996 e tinha afinalidade de agregar funcionalidades semelhantes aos disponíveis nos IDE populares da lingua-

9http://www.xelfi.cz/

60

gem Delphi 10, os quais eram atrativos por serem fáceis de utilizar e também por apresentaremrecursos gráficos para facilitar o desenvolvimento de softwares. Em 1997, foi desenvolvidaa primeira versão comercial do IDE NetBeans, que foi comprada pela Sun Microsystems em1999, tornando-o em um IDE gratuito e de código aberto (NetBeans, 2013).

Atualmente na versão 7.4, o NetBeans foi construído com o propósito de simplificar eaumentar a produtividade do processo de construção de sistemas. Essa IDE pode ser utili-zada em qualquer sistema operacional, pois foi desenvolvida em Java. Também, essa IDEsuporta qualquer linguagem de programação como o próprio Java, Python, Ruby, Perl, entreoutras (Boudreau, Glick and Spurlin, 2002; Kutler and Leonard, 2008). Assim, é possível aconstrução de sistemas utilizando várias linguagens simultaneamente, isto é, dependendo dacomplexidade dos requisitos, pode ser usada mais de uma linguagem em um único projeto desoftware.

Essa IDE possui vários recursos, das quais se destacam: editor de código-fonte com vastagama de mecanismos para a construção de sistemas web e aplicações visuais para a elaboraçãode interfaces gráficas; gerador automático de código; ferramentas para a criação de diagramasUML; controle de versão, o qual tem como finalidade manter antigas versões dos arquivos emuma base dados para facilitar a recuperação dos mesmos quando necessário; gerenciamento debases de dados; integração e/ou reuso de componentes; disponibilidade de servidores de siste-mas para web; ferramentas de modelagem de interfaces gráficas; e suporte para a construção deaplicações para dispositivos móveis (Silva, 2005).

5.6 Linguagem de Programação Perl

Perl (Practical Extraction and Report Language) 11 é uma linguagem de programaçãomultiplataforma que tem o intuito de facilitar o desenvolvimento de métodos e ferramentaspara o processamento de textos, de relatórios e de formulários textuais. Essa linguagem foidesenvolvida por Larry Wall em 1987 com o objetivo de reunir as principais vantagens detecnologias comumente utilizadas no sistema operacional Unix, como o editor Stream EDitor(’sed’) 12 e as linguagens AWK 13, C 14 e Shell Script 15. Em 1992, na sua quarta versão,Perl tornou-se uma linguagem padrão para o sistema operacional Unix (Schwartz, Phoenix andD’Foy, 20011). Recentemente, o Perl se encontra na versão 5.18.1.

A linguagem Perl segue o preceito "Existe mais de uma maneira para fazer isso" (There’s

10http://c2.com/cgi/wiki?BorlandDelphi11http://www.perl.org/12http://www.gnu.org/software/sed/manual/sed.html13http://awk.freeshell.org/14http://www.open-std.org/JTC1/SC22/WG14/www/standards15http://tldp.org/LDP/abs/html/why-shell.html

61

More Than One Way To Do It - TMTOWTDI), isto é, para cada tarefa ou problema existem vá-rias formas para solucioná-las, facilitando o desenvolvimento de soluções computacionais e oaprendizado do uso da linguagem por programadores (Wall, Christiansen and Schwartz, 2012).

A sintaxe do Perl é semelhante ao do C e possui uma ampla variedade de recursos pararealização de tarefas comuns, como a manipulação de arquivos. No código-fonte Perl, todasas variáveis escalares, ou seja, que assumem um valor individual, são precedidas pelo caractere"$". As variáveis vetoriais que representam os conjuntos de valores (arrays) são precedidas pelocaractere "@" e as variáveis associativas, as quais apresentam valores de arrays associativas(tabelas hash), são precedidas pelo caractere "%". Também, todas as versões dessa linguagemgerenciam a memória automaticamente e possuem tipagem dinâmica, uma característica quenão exige a declaração de variáveis devido à capacidade de definição do tipo de dado dinami-camente para cada variável (Wainwright, Cozens, Calpini, Corliss and Merelo-Guervos, 2001).

Outras vantagens da linguagem Perl são: possibilidade de elaboração de código-fonte ra-pidamente; disponibilidade de comandos poderosos para processamento de textos; suporte àprogramação estruturada e à orientada a objetos; disponibilidade para vários sistemas opera-cionais; facilidade de compreensão da documentação da linguagem; e viabilidade do uso deExpressões Regulares (ER) (Schwartz, Phoenix and D’Foy, 20011).

Uma das características responsáveis pela popularização da linguagem Perl é a possibili-dade do uso de ER, que tem a finalidade de identificar cadeias de caracteres com característicasde interesse, tais como letras particulares, palavras ou padrões de caracteres (Wall, Christiansenand Schwartz, 2012; Friedl, 2006). Essas expressões são escritas formalmente em uma lingua-gem que pode ser interpretada por determinados processadores de textos, os quais processamER por meio de casamento de padrões, que geralmente é realizado com suporte de caracteres es-peciais, denominados de metacaracteres (Friedl, 2006). Na Tabela 5.1, são apresentados algunsexemplos de metacaracteres e os seus significados.

Por exemplo, na ER "ˆ \s*", são identificados todos os espaços em branco no início deuma frase. Em Perl, uma ER é designada entre barras (/) e o casamento de padrões é realizadopor meio do operador lógico "=∼". Na expressão "$algo =∼ /ˆ \s+ /", por exemplo, o resul-tado será verdadeiro (true) se a sentença analisada contém no mínimo um espaço em branco noinício de uma frase e o resultado será falso (false), caso contrário. Também, podem ser apli-cadas operações em ER, como substituição, que é dada por "$algo =∼ s / ER / P /", na qual"s" (substitute) é o caractere que representa a operação de substituição e "P" é a sequência decaracteres que substituirá o padrão encontrado por "ER", como na expressão "$frase =∼ s /

ˆ \s* //", a qual elimina os espaços em branco no início de uma frase. No entanto, a expres-são "$algo =∼ s / ER / P" elimina apenas uma ocorrência de "ER", sendo que pode haver anecessidade de remover todas as ocorrências. Para isso, na expressão deve ser adicionada ao

62

Tabela 5.1: Tabela de exemplos de metacaracteres utilizados em ER (Adaptado de Schwartz,Phoenix and D’Foy (20011) e de Intentor (2010)).

Metacaractere Significado. Coincidir qualquer caractere* Presença de zero ou mais vezes de um determinado caractere ou conjunto+ Presença de um único caractere ou de conjunto no mínimo uma vez

{n} Presença de um determinado caractere ou de um conjunto exatamente n vezes{n,m} Presença de um determinado caractere ou um conjunto no mínimo n e máxima de m

vezes\ Quando um determinado caractere especial está presente em uma cadeia de caracteres,

é utilizado "\" precedido do mesmo[] Agrupamento de expressões() Agrupamento de caracteresˆ Início de uma linha de texto$ Fim de uma linha de texto\n Nova linha\t Caractere de tabulação

\d ou \D Reconhecem apenas dígitos\s ou \S Reconhecem apenas espaços em branco

\w ou \W Reconhecem qualquer caractere alfanumérico e o caractere underline ("_")

final mais uma barra e um caractere que represente a operação de remoção de todas as ocor-rências, acarretando na expressão "$algo =∼ s / ER / P / g", na qual "g" (global) é o caractereque representa todas as ocorrências de "ER", por exemplo, a expressão "$algo =∼ s / - / \s /

g" substitui cada caractere “-" por um espaço em branco. Neste caso, também pode ser utilizadono final da expressão o caractere "gi" (global ignore), que tem a mesma funcionalidade de "g",mas neste caso, os caracteres maiúsculos não são diferenciados dos minúsculos (Wainwright,Cozens, Calpini, Corliss and Merelo-Guervos, 2001; Schwartz, Phoenix and D’Foy, 20011).

5.7 Linguagem de Marcação HTML

HyperText Markup Language (HTML) 16 é uma linguagem de marcação utilizada paraconstrução de páginas web que foi criada pelo físico Britânico Tim Berners-Lee com a fina-lidade de resolver um problema de comunicação e de disseminação de pesquisas entre ele eseu grupo de pesquisadores. Nas primeiras versões dessa linguagem foram definidas regrassintáticas para auxiliar na publicação de documentos na Internet (Castro and Hyslop, 2013).

Essa linguagem foi especificada na década de 1990 baseada nas propostas de Tim Berners-Lee para a elaboração de uma linguagem inspirada em Standard Generalized Markup Language

(SGML) 17 para a web. A primeira versão do HTML foi publicada em 1993 como uma apli-cação do SGML. Após a publicação da versão 3.5 do HTML em 1997, foi iniciado pela Wide

16http://www.w3.org/html/17http://xml.coverpages.org/sgmlsyn/sgmlsyn.htmC6

63

World Web Consortium (W3C) 18 o desenvolvimento do XHTML 19, que combina as funcio-nalidades das linguagens HTML e XML (eXtensible Markup Language) 20 com o propósito deser o sucessor da linguagem HTML. Em 2008, foi lançado a quinta versão do HTML, tambémconhecido como HTML5, que é amplamente utilizado atualmente (Pilgrim, 2011; Lubbers, Al-bers and Dalim, 2013).

Para a elaboração de documentos utilizando qualquer versão da linguagem HTML, sãoutilizadas estruturas de marcação pré-definidas com instruções denominadas etiquetas, marca-dores ou tags, que são representadas na forma <nome_do_marcador>. Uma tag contém o seurespectivo nome e opcionalmente possui atributos, os quais são aplicados para alterar os resul-tados padrões de uma tag por intermédio de valores que definem essas mudanças. Um elementoHTML geralmente contém uma tag de abertura, uma tag de encerramento e conteúdo. Umatag e abertura é representada na forma <Nome_Tag atributo=valor> e na mesma pode conterinúmeros atributos. Uma tag de fechamento é representada na forma </Nome_Tag> e não com-porta atributos. O conteúdo é apresentado entre as duas tags e geralmente são textos, imagens,vídeos ou outros tipos elementos representados pela tag. Assim, um elemento HTML pode serrepresentado na forma <Nome_Tag att1=valor1 attN=valorN> Conteúdo </Nome_Tag> hou-ver a representação de alguma informação, ou na forma <Nome_Tag atr=valor> </Nome_Tag>

ou <Nome_Tag att1=valor1 attN=valorN />, caso contrário (Lawson and Sharp, 2011).

A estrutura básica de um documento HTML é definida pelas seguintes tags (Castro andHyslop, 2013):

• <html>: é a tag que define o início de um documento HTML;

• <head>: define o cabeçalho da página e as informações sobre o documento para o nave-gador web;

• <body>: determina o conteúdo principal da página web. Nessa tag, são comportadosoutros marcadores que contém textos, imagens, vídeos, ou outros tipos de dados;

• <title>: representa o título do documento.

Outro componente que faz parte da estrutura básica de um documento HTML é denomi-nado <!DOCTYPE html>, que é geralmente localizada na primeira linha de código do docu-mento, antes das tags básicas. O Doctype tem o intuito de informar ao navegador web ou outrossistemas e ferramentas qual especificação de código deve ser utilizada para a exibição do do-cumento. É importante ressaltar que o Doctype não é uma tag HTML, mas sim uma instrução

18http://www.w3.org/19http://www.w3.org/TR/xhtml1/20http://www.w3.org/XML/

64

interpretada pelo navegador web para informar sobre a versão do HTML em que o código foiescrito (Lubbers, Albers and Dalim, 2013).

Nesse contexto, existem várias tags para a representação e a formatação de dados em pá-ginas web (Pilgrim, 2011). Para formatação de textos, podem ser citados os seguintes exemplosde tag:

• <p>: determina um novo parágrafo;

• <b>: formata o texto para negrito;

• <i>: formata o texto para itálico;

• <u>: formata o texto para sublinhado;

• <sub>: formata o texto para subscrito;

• <sup>: formata o texto para sobrescrito;

• <h1>, <h2>, <h3>, <h4>, <h5> e <h6>: determina o tamanho dos caracteres, sendo<h1> o maior e <h6> o menor.

Na Figura 5.2, é apresentado um exemplo de documento HTML (à esquerda) e a páginaweb equivalente (à direita).

Figura 5.2: Exemplo de documento HTML e página web equivalente.

Outras tags comumente utilizadas para a representação de dados são: <img>, que tema finalidade de exibir uma imagem; <a>, que representa um link para uma outra página web;<ul>, <ol> e <dl> para a exibição de listas; <form> para a elaboração de formulários e écomposta pelos marcadores <input> (campo de texto para entrada de dados), <button> (botão),<select> (lista de opções para seleção), entre outros; <table> para a apresentação de tabelase os seus elementos são definidos pelas tags <tr> (coluna), <th> (célula destacada) e <td>

(célula comum); entre outras (Castro and Hyslop, 2013; Lawson and Sharp, 2011; Lubbers,Albers and Dalim, 2013).

65

No entanto, para a construção de um sistema web, a linguagem HTML é utilizada ape-nas para a exibição do conteúdo. Para melhorar a visibilização de dados e a organização doconteúdo, bem como tornar a página interativa com os usuários, é necessário o uso de outrastecnologias para aprimorar o documento HTML, como uma linguagem de estilo para definircomo as informações devem apresentadas e uma linguagem de programação para tornar a pá-gina interativa.

5.8 Linguagem de Marcação XML

eXtensible Markup Language (XML) é uma linguagem de marcação utilizada para repre-sentar tipos de dados e organizá-los hierarquicamente. O principal objetivo do XML é facilitar,simplificar e generalizar o compartilhamento de informações por meio da Internet. Essa lingua-gem é o resultado de um projeto da W3C desenvolvido na década de 1990 que tinha o propósitode desenvolver uma linguagem de marcação que combinasse a flexibilidade da SGML com asimplicidade da HTML e que pudesse facilitar a comunicação entre sistemas construídos emlinguagens de programação diferentes (Bray, Paoli, Sperberg-McQueen and Maler, 1996).

Assim como o HTML, a linguagem XML utiliza tags para representar dados, no entanto,o XML possibilita a criação de marcadores para a representação de informações, ao contráriode HTML, que tem um repertório limitado de tags. Também, essas linguagens foram desen-volvidas para atender as especificações de diferentes alvos, sendo que o XML é focado notransporte e no armazenamento de dados e o HTML na exibição de dados. Outra diferençaentre essas linguagens é que a declaração de um documento HTML é dada por <!DOCTYPE

html> e a de um documento XML é <?xml version="1.0" encoding="UTF-8"?>, no qual oatributo version define a versão da linguagem e o encoding determina o modo de codificação decaracteres (Harold, 1998; Deitel, 2012; Lubbers, Albers and Dalim, 2013).

Na Figura 5.3 é apresentado um exemplo de estrutura de documento XML para a repre-sentação de informações bibliográficas de trabalhos científicos.

Desse modo, o uso da linguagem XML apresenta os seguintes benefícios: operaçõesde buscas mais eficientes; construção de aplicações flexíveis para a web; integração de dadosem formatos diferentes; facilidade na manipulação de dados; várias maneiras de visibilizar osdados; fácil distribuição na Internet; facilidade na compreensão do conteúdo de documentosrepresentados nessa linguagem; baseado em textos simples; suporta o padrão representação decaracteres Unicode 21, possibilitando a elaboração de documentos com o conteúdo representadoem linguagens latinas; entre outros (Deitel, 2012).

21http://www.unicode.org/

66

Figura 5.3: Exemplo de estrutura de documento XML para a representação de documentoscientíficos.

5.9 Linguagem CSS

Cascading Style Sheets (CSS) 22 é uma linguagem de estilo utilizada para definir a for-matação (design) da apresentação de documentos escritos mediante ao uso de linguagens demarcação, como XML e HTML. O objetivo da linguagem CSS consiste em separar o layout doconteúdo de documentos web. Hoje em dia, grande parte desses documentos utilizam CSS paraorganizar, formatar e expor informações de modo personalizado (Sklar, 2001; Larsen, 2013).

A linguagem CSS foi criada em 1994 por Håkon Wium Lie e Bert Bos, os quais apre-sentaram o projeto dessa linguagem para a W3C, que lançaram a recomendação oficial do CSSLevel 1 (CSS1) em 1996 e CSS2 no ano de 1998. Atualmente, a linguagem CSS está em suaterceira versão (CSS3) e ainda se encontra em desenvolvimento (Meyer, 2009).

Essa linguagem possui uma sintaxe simples e utiliza palavras em inglês para especificaros nomes de regras e de suas propriedades. Uma regra CSS é dividida em três partes, como oidentificador da regra (seletor), a propriedade do seletor e o valor de cada propriedade. Assim,

22http://www.w3.org/Style/CSS/

67

uma regra é definida na forma nome_seletor{ propriedade1:valor1; propriedadeN:valorN; } eé classificada em três tipos distintos (Lie and Bos, 2005; Sklar, 2001; Meyer, 2009):

• Seletores XHTML: definem o modo de exibição de uma tag HTML. Esse tipo de se-letor não pode ser nomeado dinamicamente, isto é, podem apenas conter nomes de tags

HTML. Por exemplo, a regra p{color:red; background-color:green;} determina que asinformações representadas pela tag <p> terão todos os seus caracteres apresentados nacor vermelha e o parágrafo terá a cor de fundo verde;

• Classes: os seletores podem ser nomeados dinamicamente e aplicados em distintos ele-mentos. O nome do seletor para esse tipo de regra é precedido pelo caractere ponto (".").Ao contrário dos seletores XHTML, o seletor do tipo classe deve ser declarado na tag

que utilizará as suas propriedades por meio do atributo class e o seu valor com nome daclasse sem o caractere ponto. Assim, esse tipo de regra pode ser utilizada em qualquer tag

HTML. Por exemplo, a regra .minha_classe{ background-color:blue; } determina que acor de fundo de cada tag que a utiliza terá cor azul, como <p class="minha_classe”> ...

<p/> e <body class="minha_classe”> ... </body>;

• Identificadores (ID): também nomeável dinamicamente, porém, cada ID pode ser apli-cada apenas uma única vez em qualquer tag HTML. O nome do seletor para esse tipo deregra é precedido pelo caractere cerquilha ("#") e sua declaração em uma tag HTML édefinida pelo atributo id. Por exemplo, a regra #meu_id{color:white;} determina que acor dos caracteres será branco, como <b id="meu_id”> ... </b>.

Em um documento HTML, o CSS pode ser usado em três modos distintos: adição doatributo style diretamente na tag com a respectiva declaração de propriedades, por exemplo, <h2

style="color:black”> ... </h2>; inclusão da tag <style type="text/css”>, que permite a criaçãode regras CSS dentro do próprio documento HTML; ou inserção de arquivo CSS externo pormeio da tag <link>, utilizando o atributo rel para determinar o tipo de documento aplicado e oatributo href para definir o local e o nome do arquivo CSS (Lie and Bos, 2005).

Desse modo, com o uso do CSS é possível construir páginas web com design aprimoradosem a necessidade da formatação de informações em arquivos HTML, ou seja, o layout dapágina é separado da estrutura do arquivo HTML, tornando a página mais leve e viabilizandoo reuso do design em outras páginas web, ou seja, um arquivo CSS pode ser utilizado em todacoleção de páginas. Também, o CSS possibilita a redução de tempo para o carregamento depáginas web, pois com todas as regras de formatação em arquivos CSS, é reduzida a quantidadede código dessas páginas, diminuindo o fluxo de dados a serem transmitidos e analisados pelosnavegadores web (Meyer, 2009).

68

5.10 Linguagem de Programação Javascript

Javascript 23 é uma linguagem de programação interpretada de característica orientada aobjetos e inspirada nas linguagens C, C++ e Java. Originalmente desenvolvida por BrendanEich da Netscape 24, sob o nome de Mocha, foi mudado para LiveScript que foi lançado em suaprimeira versão em setembro de 1995. A mudança do nome LiveScript para Javascript ocorreuno mesmo período em que a Netscape iniciou a utilização da tecnologia Java em seu navegadorweb, em dezembro de 1995. Em 1996, Javascript foi submetida para o ECMA (European Com-

puter Manufacturers Association) Internacional com a finalidade de torná-lo uma linguagem pa-drão industrial, resultando na versão padronizada denominada ECMAScript (Crockford, 2008).

Atualmente, Javascript é a linguagem mais utilizada para construção de componentes deinterfaces de sistemas web, sites, portais, entres outras ferramentas web. Essa linguagem égeralmente aplicada no desenvolvimento de funcionalidades para a interação do sistema comos usuários, tais como tratamento de eventos (clique com botões do mouse, pressionamento deteclas, entre outras), validação de formulários, efeitos visuais, transferência de informações,entre outras (Goodman and Morrison, 2007).

Essa linguagem possui sintaxe de programação estruturada semelhante ao da linguagemC e tipagem dinâmica, ou seja, não é necessária a declaração do tipo de dados. Também, Ja-vascript é quase inteiramente baseada em objetos (orientação a objetos), possui programaçãodirigida por eventos e é independente de plataforma (Crockford, 2008). Os códigos escritosna linguagem Javascript são incluídos em arquivos HTML (páginas web), os quais são exi-bidos para os usuários por meio de um navegador web. Assim, é importante ressaltar quea variabilidade de tipos de navegadores para o acesso às páginas web pode influenciar nocomportamento de funcionalidades escritas em Javascript, isto é, uma funcionalidade podegerar resultados diferentes para cada tipo de navegador (Flanagan, 2006). Esse tipo de pro-blema pode ser solucionado ou amenizado com o uso simultâneo de métodos compatíveis comos principais navegadores para a realização de uma determinada tarefa. Por exemplo, o co-mando document.selection.createRange().text é utilizado para a captura do texto selecionadopelo usuário e funciona corretamente nos navegadores web Netscape e Internet Explorer, aocontrário dos navegadores Opera, Firefox e Chrome, na quais devem ser usado o comando win-

dow.getSelection().toString(). Nesse sentido, esses dois comandos podem ser utilizados em umúnico SC, sendo necessário apenas a realização de um tratamento para que cada comando sejaexecutado no navegador correto.

Para facilitar a construção de aplicações em Javascript, podem ser utilizadas outras tec-

23http://www.javascriptsource.com/24http://isp.netscape.com/

69

nologias, como Javascript Object Notation (JSON) 25 e Document Object Model (DOM) 26.O JSON é uma estrutura padrão de dados manipulável pela linguagem Javascript. Essa estru-tura, proposta por Douglas Crockford, é uma alternativa à linguagem XML para manipulaçãode informações de páginas web (Ferguson and Heilmann, 2013). O DOM é uma linguagemmultiplataforma independente para representar interação entre objetos em documentos HTML,XHTML e XML (van Kesteren, Gregor, Russel and Berjor, 2014).

Também, para construção de ferramentas utilizando Javascript, podem ser utilizados bibli-otecas de código-fonte, como o JQuery 27, que oferece várias funcionalidades para manipulaçãode informações (Crockford, 2008).


A escolha de ferramentas e tecnologias para auxiliar na construção de uma solução com-putacional se apresenta como uma abordagem essencial para o sucesso de um projeto de soft-ware. Essas escolhas são baseadas nas características e na complexidade dos requisitos estabe-lecidos. Assim, são definidas as linguagens de programação, os frameworks e outros recursosque deverão ser utilizados na elaboração do SC para atender às especificações de seus usuários.

Neste capítulo, foram apresentadas as tecnologias mais empregadas na construção de sis-temas computacionais, bem como no SC para a automatização do PMLM. Para o método demapeamento, foi utilizada a linguagem de programação Perl para a implementação das técnicasde processamento de texto devida a sua variabilidade de métodos que facilitam essa tarefa. Alinguagem de marcação XML é usada para representar a lista de stopwords e do Arquivo dePadronização (AP). A linguagem de programação Java foi aplicada sob apoio do ambiente dedesenvolvimento NetBeans e outras ferramentas para a implementação do algoritmo de mapea-mento de laudos médicos por ontologias.

Para automatizar e consolidar o PMLM e facilitar o seu uso por especialistas da área mé-dica, neste trabalho foi desenvolvido um sistema web de modo que seja acessível em qualquerlugar sem a necessidade de instalação de softwares e de configuração da máquina para o seu uso,sendo apenas indispensável um navegador web instalado no computador do usuário e acesso àInternet. Com esse sistema é eliminada a necessidade do conhecimento técnico de seus usuáriospara a aplicação de cada método de processamento de textos e a criação de estruturas como astoplist, o AP e a ontologia. Para a construção desse SC, foi utilizada a linguagem JRuby com osuporte do framework RoR e de métodos e ferramentas desenvolvidas em Java e em Perl. Paraa elaboração de uma interface amigável, intuitiva e interativa ao usuário, foram utilizadas as

25http://www.json.org/26http://www.w3.org/DOM/27http://jquery.com/

70

linguagens HTML, CSS e Javascript.

Desse modo, no Capítulo 6 é descrita detalhadamente a aplicação da abordagem de enge-nharia de software denominada método de desenvolvimento por prototipagem e o uso de ferra-mentas e tecnologias discutidas neste capítulo para a construção do SCC para a automatizaçãoe a consolidação do PMLM.

Capítulo 6

Processo de Desenvolvimento do SistemaComputacional Colaborativo


Neste trabalho, foi desenvolvido o Sistema Computacional Colaborativo (SCC) seguindoos preceitos de Engenharia de Software conhecido como método de desenvolvimento de siste-mas computacionais por prototipagem. Essa escolha foi realizada devido à complexidade dasespecificações, bem como pela importância e indispensabilidade da participação de especia-listas do domínio. Esse método é aplicado em cinco etapas (Lee, Oliva, Maletzke, Machado,Voltolini, Coy, Fagundes and Wu, 2013), as quais são apresentadas a seguir.

Sendo assim, na Seção 6.2 são apresentadas as atividades realizadas na etapa de Comu-nicação. Na Seção 6.3 são descritas as tarefas desempenhadas na etapa de Plano Rápido. NaSeção 6.4 é apresentada a modelagem do SCC. Na Seção 6.5 é descrita a construção do sis-tema. Na Seção 6.6 são ilustradas as telas do SCC e as suas funcionalidades. Na Seção 6.7 éapresentada a avaliação do sistema realizada por especialistas do domínio.

6.2 Etapa de Comunicação

Nessa etapa, primeiramente foram estudados conceitos relacionados ao PMLM e às téc-nicas de processamento de textos utilizadas nesse processo para a compreensão do funciona-mento do método de mapeamento. Nesse estudo, foi observado que todas as técnicas utilizadasno PMLM devem ser executadas separadamente por meio do uso de instruções computacionais,dificultando a sua aplicação por profissionais que não sejam da área computacional ou que nãoconheçam detalhadamente o processo. Também, foi constatado que uma das técnicas utilizadasno pré-processamento, denominada stemming, pode dificultar o entendimento de alguns ter-mos e os resultados de sua aplicação podem ser interpretados pelos especialistas erroneamente,

71

72

como discutido no Capítulo 3.

Após o estudo direcionado ao PMLM, foram realizadas reuniões com especialistas dodomínio para o levantamento de requisitos para a construção do SCC com o propósito de reduziros problemas apresentados anteriormente e maximizar a criação de um Sistema Computacional(SC) funcional, amigável e interativo. Assim, os principais requisitos definidos foram:

• Automatização do PMLM por ontologias mediante a integração de técnicas de processa-mento de laudos textuais;

• Substituição da técnica de pré-processamento stemming pelo método de lematização, noqual os resultados podem ser mais facilmente compreendidos pelos seus usuários;

• Desenvolvimento de uma interface web amigável e intuitiva ao usuário para facilitar ouso do sistema, de modo que não seja necessária a instalação de programas adicionais ea configuração específica do computador para a execução do SCC;

• Possibilidade do uso do sistema por qualquer computador com configuração mediana atu-almente (por exemplo, computadores com processador Intel c© Core i3) que tenha acessoà internet.

6.3 Etapa de Plano Rápido

Na etapa de Plano Rápido, os requisitos foram analisados com a finalidade de compreen-der o problema a ser resolvido para verificar se era viável o desenvolvimento de uma soluçãocomputacional. Neste projeto, inicialmente foram realizadas análises conceituais e práticas so-bre os métodos desenvolvidos na linguagem Perl com o intuito de esclarecer o funcionamentodo pré-processamento de laudos textuais. Assim, primeiramente foram estudados os aspectosteóricos que abrangem essas técnicas, caracterizado como estudo conceitual. O estudo práticofoi conduzido de dois modos: simulado, no qual não foram executados os códigos dos métodospor meio de um interpretador computacional, mas de forma manual para simular a execuçãodos mesmos; e real, em que os códigos dos métodos são executados em um interpretador decódigo Perl.

Também, foram estudados a técnica de pré-processamento aplicada na segunda fase doPMLM e o método de mapeamento de laudos por ontologias, os quais foram codificados naslinguagens Perl e Java, respectivamente. O pré-processamento consiste na seleção e na apli-cação das técnicas de transformação de textos utilizadas na construção de Conjuntos de FrasesÚnicas (CFU) para a uniformização dos laudos que serão mapeados para a tabela atributo-valorpor intermédio do método de mapeamento. Esses estudos foram conduzidos da mesma formaque foi aplicada nos métodos de pré-processamento. Sendo assim, com esses estudos foi possí-

73

vel compreender as dificuldades que abrangem o uso do PMLM por profissionais que não sejamda área de computacional ou que não conheçam detalhadamente o processo.

Após, foi iniciado o planejamento da solução computacional, bem como foram definidase analisadas as tecnologias que podem ser utilizadas para apoiar na construção de um SCC coma finalidade de facilitar o uso do método e atender aos requisitos levantados anteriormente.

6.4 Etapa de Modelagem

Na etapa de Modelagem do SCC, foram estruturados dois cenários, um para cada fasedo PMLM, com o intuito facilitar a compreensão das especificações para o seu desenvolvi-mento (Lee, Oliva, Maletzke, Machado, Voltolini, Coy, Fagundes and Wu, 2013).

No cenário da primeira fase do PMLM, foram definidas as seguintes funcionalidades:

• Gerenciamento do Conjunto de Laudos Médicos: tem a finalidade de gerenciar os con-juntos de laudos textuais que serão utilizados para a geração do CFU. Essa funcionalidadedeve possibilitar a seleção, a abertura e a exclusão de laudos em uma lista de arquivos,bem como a visibilização do conteúdo dos mesmos;

• Construção e Gerenciamento do Conjunto de Frases Únicas: tem o objetivo de aplicaras técnicas de processamento de textos do PMLM no conjunto de laudos médicos seleci-onados para a geração de CFU (Conjunto de Frases Únicas). Nessa funcionalidade deveser possível visibilizar, comparar e gravar os resultados do processamento;

• Definição e Gerenciamento da Lista de Stopwords: tem o intuito de auxiliar na defini-ção da stoplist. Nessa tarefa deve ser possível construir uma lista de stopwords, a qual éexibida em um painel de exibição de stoplist. Também, deve ser viável o carregamento eo download da stoplist e a aplicação do método de remoção de stopwords;

• Construção e Gerenciamento do Arquivo de Padronização: tem o propósito de au-xiliar na construção do AP (Arquivo de Padronização) para a uniformização de laudos.Assim, essa funcionalidade deve permitir a definição de uma lista de padrões, os quaissão representados por dois conjuntos, sendo um de termos a serem substituídos e outrode termos substitutos. Do mesmo modo, deve ser possível carregar e gravar AP, tal comoaplicá-lo para a uniformização do CFU por meio do método de padronização;

• Definição e Gerenciamento do Conjunto de Atributos: tem a finalidade de apoiar nadefinição de elementos que serão representados por uma ontologia, como os atributos eseus respectivos valores que constituirão a base de dados e as RM que serão utilizadaspara mapear o conhecimento presente em laudos textuais para essa base. Esses atributosdevem ser apresentados em uma lista e as suas respectivas RM devem ser exibidas no

74

caso de seleção de um elemento dessa lista. Do mesmo modo, nessa funcionalidade épossível carregar e gravar ontologias.

Para a segunda fase do PMLM, foram definidas as seguintes funcionalidades:

• Aplicação de Pré-Processamento: tem o objetivo de aplicar as técnicas de processa-mento de textos em um conjunto de laudos, que pode ser o que foi utilizado na primeirafase e/ou outro conjunto novo de laudos disponibilizados em uma única lista de arquivos.Essa funcionalidade deve permitir a seleção de técnicas de pré-processamento a seremaplicadas ao conjunto de laudos, a aplicação dessas técnicas a esses laudos e o downloaddo conjunto pré-processado;

• Realização de Mapeamento: tem o intuito de aplicar o método de mapeamento pormeio de uma ontologia para a transcrição do conjunto de laudos pré-processados e opreenchimento de uma base de dados. Nessa funcionalidade deve ser possível a visibi-lização dos resultados por meio de uma tabela atributo-valor e de uma lista de termosnão-processados, bem como deve ser permitido gravá-los no computador do usuário.

Na Figura 6.1 são apresentadas as funcionalidades de ambos cenários utilizando a lingua-gem UML (Unified Modeling Language) por meio de um diagrama de casos de uso, no qual éilustrado a interação entre o usuário e o SCC.

Também, a partir da análise dos requisitos e de sua respectiva modelagem, foi elabo-rado um modelo arquitetural com o intuito de ilustrar a integração das técnicas aplicadas noPMLM com o SCC e a sua respectiva interação com o usuários. Esse modelo é apresentado naFigura 6.2 e é constituído pelos seguintes elementos:

• Cliente: é o componente do SCC utilizado pelos usuários para a aplicação do PMLMautomatizado por intermédio da Internet;

• Internet: rede de comunicação de dados;

• Servidor de Aplicações (SA): é o componente do sistema que tem o propósito de ge-renciar os recursos computacionais disponíveis para a aplicação do PMLM automatizadopor meio da interação do Cliente com o sistema. Esse servidor é composto por:

– Interface Web (IW) para a disponibilização das funcionalidades do sistema por meiode telas intuitivas e amigáveis ao usuário;

– Controlador de Recursos do Sistema (CRS) para gerenciar o acesso às funcionali-dades do sistema, que são compostas por scripts Perl e métodos escritos em Java;

– Scripts Perl (SP) para a aplicação das técnicas de processamento de textos, escritasna linguagem Perl, em laudos textuais selecionados pelo usuário;

75

Figura 6.1: Diagrama de casos de uso do SCC.

– Métodos Java (MJ) para controlar a execução de SP no sistema e a aplicação dométodo de mapeamento. Também, esse componente é utilizado para gerenciar asestruturas utilizadas pelo PMLM, como a stoplist, o AP, a ontologia e a base dedados;

– Banco de Dados (BD) para armazenar dados de cadastro e de login de usuários;

– Base de Dados do Usuário (BDU) para armazenar os laudos e os outros arquivosnecessários para a aplicação do PMLM, tal como gravar os seus respectivos resulta-dos.

Sendo assim, é importante ressaltar que os dados produzidos pelo PMLM, como o CFU,o AP, a ontologia, os laudos transformados, os termos não processados e a tabela atributo-valorpodem ser armazenados no computador do usuário, caso assim seja definido. Desse modo,estruturas como AP e ontologias podem ser reaproveitadas para o mapeamento de outros con-juntos de laudos e a construção de novas bases de dados.

76

Figura 6.2: Modelo de arquitetura do SCC.

6.5 Etapa de Construção

Após o planejamento e a modelagem da solução computacional, nessa etapa foi cons-truído o SCC utilizando as ferramentas e as tecnologias apresentadas no Capítulo 5.

Nesse sentido, a principal linguagem de programação utilizada foi uma implementação

77

da linguagem Ruby denominada JRuby com o suporte do framework para o desenvolvimentode sistemas web Ruby on Rails (RoR) na versão 3.2.14.

Para o controle do acesso ao SCC, foi utilizada a gem Devise 1 na versão 3.0.2, que éaplicada ao controle do acesso ao sistema por intermédio de login e senha, assim como para ogerenciamento do cadastro de conta de usuários do sistema. Para prover suporte no armazena-mento de dados dos cadastros de usuário, foi utilizado o sistema de gerenciamento de base dedados RoR denominado SQLite 2 na versão 3.7.2.2.

Para facilitar a integração e a consolidação do PMLM com o SCC, foram desenvolvidosmétodos utilizando a linguagem de programação Java apoiada pelo ambiente de desenvolvi-mento NetBeans 7.3 para a construção e o carregamento de estruturas utilizadas pelo PMLM ea execução de técnicas de processamento de textos escritas na linguagem Perl por meio de uminterpretador JRuby. Esses métodos são apresentados a seguir:

• Gerenciador de CFU: controla a aplicação de técnicas de processamento de textos doPMLM escritos em Perl para a geração de CFU;

• Gerenciador de stopwords: é aplicado para a construção da stoplist por meio da lista determos considerados irrelevantes definida no SCC. Também é utilizado para a exibiçãodos stopwords no SCC;

• Gerenciador de Regras de Padronização (RP): constrói e carrega o AP por intermédiode RP definidas pelos usuários no SCC;

• Configurador de parâmetros: determina as técnicas que deverão ser aplicadas para opré-processamento de laudos, isto é, os métodos escolhidos pelo usuário;

• Pré-processador de laudos: utiliza as técnicas determinadas no configurador de parâ-metros para a execução do pré-processamento em laudos textuais.

Também, os métodos escritos em Perl sofreram alterações em nível de código-fonte coma finalidade aprimorá-las e reduzir a complexidade de sua execução por meio da linguagemJava. Assim, na técnica de normalização foi incluída a remoção dos caracteres iniciais ”-", queé utilizado na descrição de observações em laudos textuais por especialistas.

Na técnica de remoção de stopwords foi incluída a possibilidade de processamento decaracteres especiais caso sejam definidas como stopwords, tais como parênteses ("()"), ponto deinterrogação ("?") e ponto de exclamação ("!"), os quais são comumente encontrados em laudostextuais.

Na técnica de aplicação de padronização eram anteriormente utilizados dois AP, sendoum com o intuito de representar RP para a substituição de uma palavra ou parte de uma frase

1http://rubygems.org/gems/devise2http://www.sqlite.org/

78

antiga por apenas um novo termo ou uma nova frase (RP do tipo um para um) e outro AP com oobjetivo de desempenhar RP para a substituição de uma palavra ou de uma frase antiga por doisou mais novos termos e/ou frases (RP do tipo um para vários). Na Figura 6.3 são apresentadosdois exemplos de AP, em que (a) é a estrutura que representa as RP que contém apenas umasentença para substituir uma observação presente no laudo não-padronizado e (b) é o AP quecontém RP com duas sentenças novas para a substituição de uma única observação. Nessafigura, pattern é o marcador da estrutura do AP que contém apenas RP do tipo um para um,patterntwo é a tag da estrutura do AP que contém apenas RP do tipo um para vários, number éum atributo que descreve o número de RP contidas em uma AP, synonym é o marcador de umaRP de pattern, synonymtwo é a tag de uma RP de patterntwo, n é um atributo que determina onúmero de termos e/ou de sentenças substitutas contidas em synonymtwo, old é o marcador quedefine uma palavra ou uma frase a ser substituída e new é a tag que se refere a uma palavra ouuma frase substituta.

Figura 6.3: Exemplos de AP antigos.

Nesse sentido, o método de padronização foi reestruturado para utilizar apenas um APque represente todas RP, mantendo as técnicas originais para tratar diferentes tipos de RP. NaFigura 6.4 é a demonstrado um exemplo para a nova estrutura de AP utilizando os exemplosapresentados na Figura 6.3.

Figura 6.4: Exemplo de nova estrutura otimizada de AP.

Também, no SCC desenvolvido neste trabalho, a técnica de processamento de textos de-nominada stemming foi substituída pelo método de lematização com o objetivo de reduzir as

79

limitações relacionadas ao stemming, conforme apresentado no Capítulo 3. O método de lemati-zação foi implementado por intermédio da linguagem de programação Perl com base no métodoproposto por Branco and Silva (2007) e na técnica de stemming implementada por Honorato,Cherman, Lee, Wu and Monard (2007). O método de lematização foi adaptado ao PMLM paraprocessar apenas substantivos femininos e/ou plurais, os quais são mais comuns nos laudos tex-tuais. Como essa técnica de lematização é baseada no algoritmo de Porter (1997), foi possívelreutilizar o código-fonte do método de stemming do PMLM, realizando algumas adaptações,como a substituição das regras de remoção de sufixos por regras de lematização. Com a retiradado método de stemming e a inclusão da técnica de lematização no processo de mapeamento,foi necessária a realização de modificações adaptativas no código-fonte do método aplicado nasegunda fase do PMLM para o pré-processamento de laudos.

Também, por meio da linguagem Perl foi desenvolvido um método para facilitar e auto-matizar a geração de CFU a partir de um conjunto de laudos médicos selecionados por usuários.Esse método tem a finalidade de construir sequencialmente os seguintes tipos de CFU:

• Não-processado;

• Normalizado;

• Sem stopwords;

• Lematizado;

• Padronizado.

O CFU não-processado consiste em um conjunto de frases e/ou palavras distintas extraí-das de laudos médicos, no qual não foram aplicadas técnicas de processamento de textos doPMLM e os outros CFU são conjuntos de frases pré-processadas. Para a elaboração da téc-nica de geração de CFU, foram utilizados os métodos do PMLM escritos e aprimorados emPerl. Nesse contexto, é importante ressaltar que no método de criação dos CFU, cada tipo deconjunto de frases é gerado a partir do último CFU criado.

Além disso, o método de mapeamento de laudos médicos por ontologias, desenvolvidoem Java (Costa, Ferrero, Lee, Coy, Fagundes and Chung, 2009; Lee, Monard, Honorato, Lo-rena, Ferrero, Maletzke, Zalewski, Coy, Fagundes and Chung, 2011), foi integrado ao SCC.As ontologias utilizadas nesse método, eram construídas na linguagem OWL (Ontology Web

Language) utilizando a ferramenta Protégé, as quais foram apresentadas no Capítulo 2. Com ointuito de facilitar e de aprimorar a integração desse método com o SCC foram desenvolvidasas novas funcionalidades, como:

• Possibilidade de seleção de ontologias por usuários;

80

• Construção de um gerenciador de atributos para a geração de ontologias por intermédioda definição de RM e de características por usuários no SCC. Esse gerenciador é tambémutilizado para a exibição de atributos e suas RM no sistema. Para a construção de ontolo-gias, essa ferramenta gera os seguintes componentes, que são apresentado na Seção 7.6:

– Propriedades de dados: descrevem os elementos de ontologias;

– Propriedades de objeto: desempenham o relacionamento entre os elementos da on-tologia, formando as RM e os atributos;

– Classes: rotulam e organizam o conhecimento de forma hierárquica;

– Elementos: determinam os indivíduos que devem estar presentes em todas as onto-logias utilizadas pelo SCC, como regiões anatômicas, características, subcaracterís-ticas, tipo de dados, atributos e RM.

• Requisito de que todas as RM devem conter uma região anatômica e no mínimo umacaracterística para descrevê-la;

• Geração de resultados no formato de texto e organizados de forma que simplifiquem arepresentação de seus resultados na interface do SCC;

• Carregamento e gravação da tabela atributo-valor e da lista de termos não-processados nosistema.

Para a construção de uma interface web amigável e interativa com o usuário, foram utili-zadas as linguagens:

• HTML para a construção de páginas web;

• CSS para a modelagem visual dessas páginas;

• Javascript para a interatividade da página com o usuário.

Nesse sentido, foi desenvolvida uma página web para cada funcionalidade de ambos oscenários do sistema e adicionalmente, foram construídas outras páginas para auxiliarem nouso dessas funcionalidades, tais como para carregamento de laudos, de lista de stopwords, deAP e de ontologias, bem como para a criação e a edição de RP e de mapeamento. Para ogerenciamento do carregamento de arquivos, no SCC foi utilizada a gem Paperclip 2.3 3. Assim,para elaboração da interface do SCC foi utilizado o modelo de estruturas CSS desenvolvidas emJung (2012) com o propósito de padronizar o SCC de acordo com os projetos em andamento noLABI.

3http://rubygems.org/gems/paperclip

81

6.6 Apresentação do Sistema Computacional Colaborativo De-senvolvido

Como mencionado, o SCC foi estruturado em dois cenários, um para cada uma das fases1 e 2, e as tarefas foram organizadas em menus de seleção que proveem acesso direcionado àsfuncionalidades do PMLM.

Na Figura 6.5 é apresentada a primeira tela do SCC em que é solicitada a autenticaçãodo usuário para possibilitar o uso desse sistema. Somente após a autenticação do usuário, épossível que o mesmo tenha acesso a todas as funcionalidades do sistema relacionadas aoslaudos textuais. A partir dessa tela, também é viável a criação de novos cadastros de usuário pormeio do link "Criar uma conta" e redefinir senha do usuário por intermédio do link "Esqueceua sua senha?", a partir do qual é enviado para a conta do usuário a sua senha de acesso.

Figura 6.5: Tela de acesso ao sistema.

Após a autenticação do usuário, caso essa conexão seja a primeira ao SCC, no diretóriodo computador servidor onde esse sistema encontra-se hospedado é gerada uma pasta cujo onome é o número de identificação da conta do usuário e as seguintes subpastas são criadas:

• CFU: contendo todos os CFU construídos durante a aplicação da primeira fase do PMLM;

• laudos: contendo laudos textuais que foram selecionados para a criação de CFU;

• laudos_padronizados: contendo laudos utilizados para o mapeamento, os quais são pré-processados mediante técnicas de processamento de textos do PMLM;

• tabela_atributo_valor: contendo resultados do mapeamento dos laudos contidos na pastalaudos_padronizados. Os resultados armazenados são a tabela atributo-valor e a lista determos não processados.

82

Na pasta do usuário, também são criadas e armazenadas as estruturas que são utilizadaspelo PMLM, tais como o AP, a stoplist e a ontologia, as quais são geradas e/ou carregadaspelo usuário. Outro arquivo que se encontra nessa pasta, é o de configuração de parâmetrosdenominado parameters, que tem a finalidade de controlar a aplicação do pré-processamentona segunda fase do método no SCC. Esse arquivo é estruturado na linguagem de marcação XMLe é composto pelos seguintes marcadores:

• applyNormalize: determina se a técnica de normalização deve ser aplicada;

• applyStopwords: define se o método de remoção de stopwords deve ser usado;

• applyLemmatization: indica se o procedimento de aplicação de lematização deve serexecutado;

• applyPattern: determina se a técnica de padronização deve ser aplicada;

• dirStopWord: define a localização do diretório do usuário em que se encontra a stoplist;

• dirDocuments: indica onde está situada a pasta do usuário na qual estão os laudos uti-lizados para a construção de CFU. Esse marcador também é utilizado para o reuso doslaudos da pasta referenciada pela mesma para a aplicação do pré-processamento e/ou domapeamento;

• dirPatterns: determina o local do diretório do usuário onde está localizado o AP;

• dirOutput: indica a localização da pasta do usuário em que se encontram os laudos paraserem ou que foram padronizados;

Nesse arquivo, os marcadores que determinam a aplicação de técnicas de processamentode textos podem representar apenas os seguintes valores: "sim", o qual é atribuído a um marca-dor caso o usuário escolheu uma determinada técnica para a aplicação de pré-processamento delaudos; ou "não", que é atribuído aos marcadores das técnicas de processamento de textos quenão foram escolhidos pelo usuário. Os marcadores que representam a localização de arquivos ede diretórios do usuário apresentam valores na forma /localização do SCC/tmp/sessions/número

de identificação do usuário ou no formato /localização do SCC/tmp/sessions/número de identi-

ficação do usuário/subpasta. Na Figura 6.6 é apresentado um exemplo de estrutura de arquivode parâmetros, que é criado na pasta de um usuário.

O arquivo de parâmetros ilustrado na Figura 6.6 determina que as técnicas de proces-samento de textos como a de normalização, de remoção de stopwords, de lematização e depadronização foram selecionadas pelo usuário para serem aplicadas ao conjunto de laudos lo-calizado no diretório laudos_padronizados, para o qual a sua localização é representada pelomarcador dirOutput, em que "1" é o nome da pasta de um usuário.

83

Figura 6.6: Exemplo de estrutura do arquivo de parâmetros do SCC.

Sendo assim, a seguir são apresentadas as funcionalidades de cada cenário do SCC, nasquais os componentes são descritos na forma C.F.I, onde C é o número do cenário, F é o númeroda funcionalidade de C e I é o item destacado da funcionalidade F.

Na Figura 6.7 é apresentada a tela do SCC equivalente à funcionalidade denominada"Gerenciamento do Conjunto de Laudos Médicos", na qual foram destacados:

• Menu de seleção das funcionalidades (1.a);

• Link para a mudança de cenário (1.b);

• Painel da lista de laudos (1.1.1);

• Área de texto em que é exibido o conteúdo do laudo selecionado na lista (1.1.2);

• Botão "Excluir", que tem a finalidade de descartar os laudos selecionados como sendo denão interesse nesse momento. Essa operação pode ser aplicada pelo pressionamento datecla ”Delete” no computador do usuário, sendo necessária a seleção de no mínimo, umlaudo em (1.1.1);

• Botão "Carregar", é usado para carregar conjuntos de laudos. Esse botão ao ser clicado,é aberta uma janela popup com uma página web de gerenciamento do carregamento delaudos textuais.

Na Figura 6.8 são apresentadas as telas de gerenciamento de carregamento de laudostextuais. Nessa figura, (a) representa a tela abertura de arquivos e (b) é a tela para a qual se édirecionado após o usuário clicar no botão "Enviar" na tela (a). É importante destacar que nessatela é viável carregar vários laudos simultaneamente a partir do computador do usuário.

Na Figura 6.9 é exibida a tela da funcionalidade "Conjunto de Frases Únicas (CFU)", naqual têm-se:

• Campos do tipo texto para a exibição de um determinado CFU (1.2.1);

84

Figura 6.7: Funcionalidade "Gerenciamento do Conjunto de Laudos Médicos" da primeira fase.

Figura 6.8: Telas de gerenciamento de carregamento de laudos textuais.

• Campos de seleção do tipo de CFU a ser apresentado no campo de exibição (1.2.2);

• Botão "Reconstruir CFU", que tem o objetivo de gerar o conjunto de CFU a partir doslaudos carregados na tela da Figura 6.7 e o botão "Download CFU" que permite gravar osresultados no computador do usuário. O texto do botão "Reconstruir CFU" é exibido emduas maneiras, sendo que o texto "Reconstruir CFU" é apresentado neste botão caso pelomenos um CFU seja existente na base de dados ou "Construir CFU", caso contrário.

Nessa funcionalidade, também é possível a visibilização de dois CFU distintos simultane-amente. Nesse contexto, é importante ressaltar que os CFU são construídos por meio do métodode geração automática de CFU desenvolvido neste trabalho, sendo apresentadas na seguinte or-dem:

• Conjunto de Frases Únicas – CFU;

• CFU Normalizado;

• CFU Normalizado e sem Stopwords (caso exista stoplist na base de dados);

85

Figura 6.9: Funcionalidade "Construção e Gerenciamento do Conjunto de Frases Únicas" daprimeira fase.

• CFU Lematizado (caso não exista uma stoplist cadastrada no SCC) ou CFU Lematizadoe sem Stopwords (caso exista uma stoplist cadastrada);

• CFU Padronizado (caso exista uma AP na base de dados).

Essa funcionalidade apresenta as seguintes restrições: para a construção de CFU, é ne-cessária a existência de laudos textuais para esse fim na base de dados do SCC, os quais devemser carregados por meio da funcionalidade "Gerenciamento do Conjunto de Laudos Médicos",apresentado na Figura 6.7; e para a construção dos CFU sem stopwords e do CFU padronizadoé imprescindível a presença de uma stoplist e de um AP na base de dados local do usuário noSCC, respectivamente.

Na Figura 6.10 é ilustrada a tela da funcionalidade "Definição e Gerenciamento da Listade Stopwords", em que é possível a visibilização de todos CFU gerados até o momento, facili-tando a definição e a identificação de palavras consideradas irrelevantes para aquele contexto,também denominadas stopwords. A seguir são apresentados os principais componentes dessafuncionalidade:

• Campo de texto para a determinação de uma nova palavra irrelevante, a qual é incluídana stoplist (1.3.1);

• Stoplist (1.3.2);

• Botão "Incluir", que é utilizado para incluir a stopword de (1.3.1) na stoplist;

• Botão "Excluir", que tem o propósito de excluir a stopword selecionada em (1.3.2);

86

• Botão "Carregar Stoplist", que é usado para carregar uma stoplist por intermédio do com-putador do usuário;

• Botão "Download Stoplist", que tem o intuito de gravar a stoplist no computador dousuário;

• Botão "Aplicar Stoplist", que tem a finalidade de aplicar o método de remoção de stopwords

no último CFU construído.

Figura 6.10: Funcionalidade "Definição e Gerenciamento da Lista de Stopwords" da primeirafase.

As restrições da funcionalidade apresentada na Figura 6.10 são: a exigência do preenchi-mento do campo (1.3.1) para a inclusão de uma stopword; a necessidade da existência de umastoplist para a aplicação do método de remoção de stopwords; e a impossibilidade de cadas-trar termos irrelevantes repetidos. No sistema desenvolvido neste trabalho, a existência de umastoplist é dada pela presença de no mínimo uma stopword em (1.3.2) da Figura 6.10. Nessesentido, ao executar a técnica de remoção de palavras consideradas irrelevantes mediante o bo-tão "Aplicar Stoplist", os métodos de remoção de stopwords e de lematização são aplicados noúltimo CFU construído, gerando o CFU normalizado e sem stopwords e o CFU lematizado esem stopwords, respectivamente.

Na Figura 6.11 é mostrada a tela da funcionalidade "Construção e Gerenciamento doArquivo de Padronização", na qual destacam-se:

• Painel da lista de termos antigos a serem substituídos (1.4.1);

• Painel da lista de termos substitutos do termo antigo selecionado (1.4.2);

• Botão "Novo", que ao ser clicado, é aberta uma janela popup para definição de uma novaRP. Também é possível definir uma nova RP por meio da seleção de palavras na área de

87

texto de exibição de CFU, na qual, ao selecionar um termo ou sequência de termos, éaberta a tela de definição de novas regras;

• Botão "Editar", que ao ser clicado, é aberta uma janela popup, como na Figura 6.12, paraa edição da RP selecionada em (1.4.1). A edição de uma RP também pode ser realizadapor intermédio da tecla "Enter";

• Botão "Excluir", que ao ser clicado, é aplicado a remoção de uma RP selecionada em(1.4.1). A exclusão de uma RP também pode ser realizada por meio da tecla "Delete";

• Botão "Carregar Arquivo", que é aplicado para carregar AP do computador do usuário;

• Botão "Download Arquivo", que é usado para gravar o AP no computador do usuário;

• Botão "Padronizar CFU", que é utilizado para a aplicação da técnica de padronização noúltimo CFU construído.

Figura 6.11: Funcionalidade "Construção e Gerenciamento do Arquivo de Padronização" daprimeira fase.

Para a aplicação da técnica de padronização de CFU, é necessária a existência de um APna base de dados do SCC, isto é, a lista de termos a serem substituídos como apresentado naFigura 6.11 deve conter no mínimo um termo presente nessa lista.

A janela popup para definição de uma nova RP descrita anteriormente é apresentada naFigura 6.12, onde (a) é o campo de texto referente ao termo a ser substituído, (b) é o campo determo substituto a ser cadastrado e (c) é a lista de termos substitutos. Nessa tela, é possível adefinição, a edição e a exclusão de termos substitutos. Assim, o texto do botão de inclusão determos substitutos é "Incluir +", caso exista no mínimo um termo substituto cadastrado na listade termos novos ou "Incluir" caso contrário.

88

Figura 6.12: Tela para definição de uma nova RP.

Para a edição de RP, o SCC disponibiliza uma tela semelhante ao apresentado na Fi-gura 6.12, na qual a única diferença é o título de ambas, sendo "Editar Padrão" para a atualiza-ção de RP. Para definir ou editar uma RP, é necessário que (a) seja preenchido e (c) contenhapelo menos um elemento. Também, para cada RP em ambos os casos não pode haver repetiçãode termos novos, bem como não é permitido que duas ou mais RP possuam o mesmo termoantigo, o qual é substituído pela lista de termos substitutos. Neste caso, um termo pode serconsiderado uma palavra ou uma frase.

Na Figura 6.13 é exibida a tela da funcionalidade "Definição e Gerenciamento do Con-junto de Atributos", a qual apresenta:

• Lista de nome de atributos (1.5.1);

• Valor padrão do atributo selecionado (1.5.2);

• Valores possíveis do atributo selecionado (1.5.3);

• Região da RM (1.5.4);

• Característica da RM (1.5.5);

• Lista de observações do atributo selecionado (1.5.6);

• Valor da observação selecionada (1.5.7);

• Botão "Novo", que é usado para a definição de uma nova RM a partir de uma janelapopup, que é apresentada na Figura 6.14;

• Botão "Editar", é utilizado para a edição de uma RM selecionada em (1.5.1) por intermé-dio de uma tela popup similar à apresentada 6.14. A edição de uma RM também pode serrealizada por meio da tecla "Enter";

• Botão "Excluir", que é aplicado para a remoção de uma RM selecionada em (1.5.1). Essaoperação pode ser realizada por meio da tecla "Delete";

89

• Botão "Carregar Ontologia", que é utilizado para carregar ontologia do computador dousuário;

• Botão "Download Arquivo", que usado para armazenar localmente a ontologia no com-putador do usuário.

Figura 6.13: Funcionalidade "Definição e Gerenciamento do Conjunto de Atributos" da pri-meira fase.

Com essa funcionalidade, a necessidade do uso de ferramentas externas ao SCC paraa construção de ontologias na linguagem OWL, como o Protégé, se torna dispensável pararepresentação de atributos e de RM, facilitando e simplificando a elaboração de estruturas dedados para a representação do conhecimento presente em laudos textuais. Outra característicadessa funcionalidade é a impossibilidade de cadastrar atributos com nomes repetidos. Para adefinição de novos atributos e suas RM, é utilizada uma tela popup semelhante ao de elaboraçãode RP.

A tela para definição de atributos e de RM é apresentada na Figura 6.14, em que (a)é o campo para nomeação do atributo, (b) é o campo de seleção de valores possíveis para oatributo, (c) é o valor padrão do atributo, (d) é a região para ser identificada com a RM, (e) éa característica para ser identificada pela RM, (f) é o campo de cadastramento de observações(subcaracterísticas) que serão mapeadas na RM, (g) é valor da observação a ser cadastrada,(h) é a lista de observações cadastradas e (i) é o campo de texto com o valor da observaçãoselecionada em (h).

Na Figura 6.14 é ilustrada a definição do atributo "esofagite_edematosa_inferior" comRM no formato local-característica-subcaracterística, no qual "terço distal" é o local, "pre-

senca_edema" é a característica e "normal" e "anormal" são as subcaracterísticas, contabi-lizando duas RM. No SCC, uma observação é implicitamente considerada subcaracterística

90

Figura 6.14: Tela para definição de nova RM.

quando a RM representa sentenças no formato local-característica-subcaracterística ou é deter-minada como característica quando a RM representa sentenças no formato local-característica,que ocorre quando o campo "Característica" se encontra vazio no momento em que o atributo éregistrado por intermédio do botão "Salvar".

Para a definição de atributos e de suas respectivas RM, o sistema apresenta as seguintesrestrições: para cadastrar um novo atributo, no mínimo o usuário deve preencher o campo denomeação do atributo, selecionar uma região e cadastrar no mínimo uma observação; e não épermitido o registro de observações com nomes repetidos. Nesse sistema, cada observação écomposta por duas informações: o nome e o seu respectivo valor. O nome da observação éuma informação que deve ser mapeada por meio de uma RM e o valor da observação é umainformação utilizada para o preenchimento de um atributo na base de dados caso o nome de suarespectiva observação seja mapeada. Também, no SCC é permitida a criação de observaçõescom nomes iguais aos seus valores, por exemplo, se uma observação tem o nome "normal", omesmo pode conter o valor "normal".

Na Figura 6.15 é apresentada a tela da funcionalidade "Aplicação de Pré-Processamento",na qual são destacados:

• Menu de seleção das funcionalidades do segundo cenário (2.a);

• Link para mudança de cenário (2.b);

91

• Lista de laudos escolhidos para pré-processamento e mapeamento (2.1.1);

• Área de texto utilizada para exibição de laudos (2.1.2);

• Botão "Laudos Fase 1", que tem a finalidade de reutilizar os laudos do primeiro cenário;

• Botão "Outros Laudos", que é utilizado para carregar outros laudos no computador dousuário;

• Botão "Outra Stoplist", que é aplicado para o carregamento de uma stoplist;

• Botão "Outro Arquivo", que é usado para o carregamento de um AP;

• Botão "Pré-Processamento", tem o objetivo de pré-processar os laudos selecionados parao mapeamento;

• Botão "Download Laudos", tem o propósito de gravar os laudos pré-processados no com-putador do usuário.

Figura 6.15: Funcionalidade "Aplicação de Pré-Processamento" da segunda fase.

Para o pré-processamento, é permitida a seleção de técnicas como a de normalização,de remoção de stopwords, de lematização e/ou de padronização, de acordo com os critériosdo usuário. Sendo assim, nessa funcionalidade, os laudos selecionados podem ser visibiliza-dos apenas em seu estado atual em (2.1.2), ou seja, se não foi aplicada nenhuma técnica depré-processamento são exibidos os laudos em suas versões originais, caso contrário, são apre-sentados os laudos processados.

Também, o processamento de textos é realizado por meio do botão "Pré-Processamento",que ao ser clicado, o SCC primeiramente verifica as técnicas de processamento de textos seleci-onados pelo usuário para configurar o arquivo de parâmetros, como apresentado na Figura 6.6.Em seguida, esse arquivo é interpretado pelo sistema com a finalidade de indicar quais técni-cas devem ser aplicadas para a transformação dos laudos selecionados para o mapeamento, tal

92

como determinar a localização de alguns elementos importantes nessa tarefa, como a pasta quecontém os laudos para serem transformados e as estruturas indispensáveis para a aplicação dastécnicas de remoção de stopwords e de padronização.

Na Figura 6.16 é ilustrada a tela da funcionalidade "Realização de Mapeamento", na qualdestacam-se:

• Tabela em que são apresentados os resultados do mapeamento dos laudos pré-processados(2.2.1);

• Área de texto em que são apresentados os termos não processados de cada laudo, os quaissão utilizados para identificar falhas no mapeamento e definir novas RP e/ou RM (2.2.2);

• Botão "Mapear Laudos", que é usado para a realização do mapeamento de laudos textuais;

• Botão "Download Tabela", que é utilizado para gravar a tabela atributo-valor dos laudosmapeados;

• Botão "Download Termos", que é aplicado para armazenar localmente o arquivo de ter-mos não processados.

Figura 6.16: Funcionalidade "Realização de Mapeamento" da segunda fase.

Nessa funcionalidade, para o mapeamento dos laudos transformados na função "Aplica-ção de Pré-Processamento", apresentado na Figura 6.15, o método utiliza a ontologia desenvol-vida ou carregada na funcionalidade "Definição e Gerenciamento do Conjunto de Atributos" doprimeiro cenário do SCC, conforme apresentado na Figura 6.13.

93

6.7 Etapa de Avaliação e Feedback

Durante a construção do SCC, o mesmo foi constantemente avaliado em conjunto comos envolvidos na elaboração do projeto com o intuito de verificar o andamento do projeto e seas especificações levantadas foram atendidas satisfatoriamente. Assim, foram realizadas reu-niões quinzenais entre os envolvidos no desenvolvimento do sistema para discutir as atividadesque foram desempenhadas desde a última reunião, bem como apresentadas as dificuldades en-contradas e as possíveis soluções. Também, nessas reuniões foram definidos quais requisitosdeveriam ser acrescentados, alterados e/ou removidos.

Após a construção da versão final do SCC, o mesmo foi avaliado em conjunto com es-pecialistas do domínio, os quais constataram que esse sistema cumpre os requisitos definidos ese apresenta como promissor para a definição, a extração e o estudo de padrões que podem serencontrados em laudos textuais (Lee, Oliva, Maletzke, Machado, Voltolini, Coy, Fagundes andWu, 2013).

Ainda, o SCC foi avaliado quanto ao desempenho na aplicação do PMLM automatizadoa um conjunto de 100 laudos médicos textuais artificiais que simulam exames de EndoscopiaDigestiva Alta (EDA). Os critérios e os resultados dessas avaliações são apresentados no Capí-tulo 7.


Neste capítulo foi apresentada a aplicação do processo de desenvolvimento de sistemaspor prototipagem para a construção do SCC com o intuito de automatizar o PMLM por ontolo-gias.

Inicialmente, foram estudados os aspectos teóricos e práticos que abrangem a aplicaçãode todas as técnicas de processamento de textos utilizadas nas duas fases do PMLM. A análisedesse processo permitiu constatar que o uso de todas as técnicas é complexo para qualquer pes-soa que não conheça detalhadamente o método e principalmente por profissionais que não sejamda área computacional. Isso se deve ao fato de que essas técnicas são executadas separadamentemediante às instruções computacionais, bem como as estruturas utilizadas pelo PMLM devemser construídas manualmente por meio de uma linguagem de marcação.

Após o estudo do PMLM, foram realizadas reuniões com especialistas do domínio com ointuito de identificar os requisitos para desenvolver um SCC para automatizar e facilitar o uso dométodo. Em seguida, os requisitos foram estudados e analisados com a finalidade de verificar aviabilidade para o desenvolvimento de uma solução computacional e planejar a construção domesmo. Depois, o SCC foi modelado em dois cenários, sendo um para cada fase do PMLM.

94

Após, o sistema foi implementado utilizando a linguagem programação Ruby com o auxílioda ferramenta RoR. Para o uso das técnicas de construção de CFU, de pré-processamento e demapeamento de laudos médicos foi utilizada a linguagem de programação Java por intermédiodo ambiente de desenvolvimento NetBeans.

Para facilitar e agilizar o uso do SCC, foi construída uma interface gráfica web amigável,intuitiva e interativa ao usuário. Oferece suporte completo a todas a tarefas e fases do PMLMsem a necessidade do usuário conhecer detalhadamente as especificações técnicas, como lin-guagens de programação e de marcação, bem como comandos para a execução dos métodosdo PMLM, possibilitando a construção de bases de dados para a realização estudos futuros deforma ágil e eficiente. Também, para o uso do SCC não é necessária a sua instalação e a con-figuração do computador do usuário, bastando apenas um navegador web instalado na máquinae acesso à internet.

Depois da construção do sistema, o mesmo foi avaliado e validado em conjunto com espe-cialistas do domínio, os quais constataram que a solução computacional atendeu aos requisitosestabelecidos e se apresenta como promissora para a extração e o estudo de padrões em laudostextuais médicos.

Em seguida, o SCC foi aplicado a um conjunto de 100 laudos médicos textuais artificiaissimulando exames de EDA com a finalidade de avaliar o desempenho do PMLM automatizado.Essa avaliação é apresentada detalhadamente Capítulo 7.

Capítulo 7

Estudo de Caso


Como apresentado anteriormente, este trabalho tem o objetivo de automatizar e de con-solidar o Processo de Mapeamento de Laudos Médicos (PMLM) por ontologias por meio daintegração de todas as suas técnicas de processamento de textos, bem como a inclusão de outrosmétodos e funcionalidades em um sistema computacional. Para isso, foi realizado um estudode caso interdisciplinar envolvendo as áreas computacional e médica.

Para alcançar os objetivos deste trabalho, foi construído um Sistema Computacional Co-laborativo (SCC) no Laboratório de Bioinformática (LABI) da Universidade Estadual do Paraná(UNIOESTE/Foz do Iguaçu) em parceria com o Serviço de Coloproctologia da Faculdade deCiências Médicas da Universidade Estadual de Campinas (UNICAMP). Esse sistema foi de-senvolvido para automatizar e facilitar o uso do PMLM por profissionais que não sejam da áreacomputacional, por exemplo, da área de saúde e que não possuam conhecimento detalhado dométodo, possibilitando a construção de grandes bases dados, as quais poderão ser utilizadaspara a aplicação de processos como o de Mineração de Dados (MD).

Após a construção do SCC e a avaliação por especialistas do domínio, foi realizado umestudo de caso com a finalidade de avaliar o desempenho do sistema durante o processamentode um conjunto de laudos médicos textuais artificiais.

Na Seção 7.2 é descrita a avaliação experimental realizada neste estudo de caso. NasSeções 7.3 e 7.4 são apresentadas a definição do Arquivo de Padronização (AP) e da stoplist,respectivamente. Na Seção 7.5 são descritos os atributos da base de dados e a forma de estru-turação de Regras de Mapeamento (RM). Na Seção 7.7 é demonstrada a aplicação do métodode mapeamento por ontologias. Na Seção 7.6 são apresentadas as principais características daontologia utilizada pelo SCC para este estudo de caso, a qual foi proposta em (Lee, Monard,Honorato, Lorena, Ferrero, Maletzke, Zalewski, Coy, Fagundes and Chung, 2011).

95

96

7.2 Avaliação Experimental do SCC

Neste trabalho, a avaliação experimental do sistema computacional desenvolvido foi re-alizada em um conjunto de 100 laudos médicos artificiais que simulam relatórios de exa-mes de Endoscopia Digestiva Alta (EDA). Esses exames são usados por especialistas em pro-cessos de diagnóstico de enfermidades que acometem o esôfago, o estômago e/ou o duo-deno (Cordeiro, 1994; Cotran, Kumar and Collins, 1996). Os documentos utilizados nessaavaliação experimental contêm um total de 400 frases e 2.520 palavras. Os laudos artificiaisapresentam a seguinte estrutura:

• Cabeçalho: indica a porção anatômica analisada e geralmente está presente na primeiralinha do texto e escrito em caixa-alta;

• Observações: são sentenças que descrevem anormalidades e/ou outras característicasobservadas em uma determinada região e são precedidas pelo caractere traço (-).

Na Figura 7.1 é apresentado um exemplo de laudo textual artificial de exame de EDA daseção de esôfago, no qual a parte destacada na cor vermelha é o cabeçalho e na cor verde são asobservações.

Figura 7.1: Exemplo de laudo textual de exame EDA da região do esôfago.

De acordo com as informações apresentadas na Figura 7.1 é possível notar que não foramidentificadas anormalidades na região do esôfago por intermédio do exame de EDA. Nessasobservações, o calibre se refere ao diâmetro interno do esôfago, a distensibilidade é a capacidadede ampliação (elasticidade) de um tecido, a motilidade está relacionada à capacidade de umórgão de executar movimentos autônomos e a TEG é o limite entre o esôfago e o estômago.

Conforme mencionado, o PMLM é realizado em duas fases. É importante lembrar que aose realizar o processo pela primeira vez para um conjunto de laudos de um determinado domí-

97

nio, é necessária a realização de todas as tarefas associadas ao processo, incluindo a construçãodo Arquivo de Padronização (AP), da stoplist e da ontologia.

Na primeira fase, as frases de todos os documentos selecionados foram concatenados eordenados alfabeticamente em um único arquivo. Em seguida, todas as frases repetidas forameliminadas, originando o Conjunto de Frases Únicas (CFU), o qual contém uma entrada paracada frase distinta. Depois, foi executada a técnica de normalização para a redução da varia-ção de caracteres por meio da substituição de todas as letras maiúsculas e/ou acentuadas porcaracteres minúsculos e sem acentuação, resultando no CFU Normalizado.

Após, foi definida uma lista de termos considerados irrelevantes, conforme apresentada naSeção 7.4. Essa stoplist foi aplicada no CFU Normalizado por meio da técnica de remoção destopwords, gerando o CFU Normalizado e sem Stopwords. Em seguida, esse grupo de sentençasfoi submetido à transformação por intermédio do método de lematização, concebendo o CFULematizado e sem Stopwords.

Posteriormente, foram definidas Regras de Padronização (RP) a partir da análise dos CFUgerados anteriormente, construindo o AP, conforme apresentado na Seção 7.3. Essas regras fo-ram determinadas para transformar as sentenças de modo que sejam representadas no formatolocal-característica-subcaracteristica ou local-característica com o propósito de facilitar a de-finição de RM, como apresentada na Seção 7.5. A aplicação do AP no último conjunto de frasesgerados concebeu o CFU Padronizado.

Depois da construção de todos os CFU, as frases foram analisadas com o intuito de de-finir as variáveis e os valores da tabela atributo-valor (base de dados), bem como a estruturada ontologia, como apresentadas nas Seções 7.5 e 7.6, respectivamente, para a representaçãodo conhecimento presente nos laudos médicos utilizados neste trabalho por intermédio dessasestruturas.

Na segunda fase, o conjunto de laudos médicos utilizado na construção de CFU foi sub-metido à aplicação de técnicas de processamento de textos com o propósito de transformá-lospara uma representação adequada para a execução do método de mapeamento. Para isso, fo-ram usadas as estruturas como a stoplist e o AP definidas anteriormente. Sendo assim, nessesdocumentos foram efetuadas sequencialmente as seguintes técnicas: normalização, remoção destopwords, lematização e padronização.

Posteriormente, as informações presentes nos laudos padronizados foram mapeadas paraa base de dados. Esse mapeamento foi conduzido de duas formas: manual, que é realizadomanualmente para uma planilha do Microsoft Excel c©; e automático, o qual é aplicado porintermédio do SCC.

Após a realização do mapeamento, manual e automática, no conjunto de laudos médicos,para a avaliação dos resultados da aplicação do PMLM por ontologias foram calculados:

98

• Medidas estatísticas para os termos e as frases dos CFU gerados durante a aplicaçãode técnicas de processamento na primeira fase do PMLM, como média, desvio-padrão,mínimo e máximo;

• Custo computacional da aplicação de cada técnica utilizada para a construção de CFU;

• Custo computacional da aplicação da primeira fase do PMLM;

• Porcentagem de atributos mapeados para a base de dados;

• Porcentagem de laudos que apresentaram termos não-processados;

• Incidência de termos não-processados;

• Custo de tempo para o mapeamento manual;

• Custo computacional para o mapeamento automático;

• Custo computacional da aplicação do PMLM por meio do SCC.

7.3 Construção do Arquivo de Padronização

Para trabalhar com um vocabulário controlado e possibilitar que as informações estejamem formato adequado para a construção de Regras de Mapeamento (RM) que irão comporuma ontologia, como a apresentada na Seção 7.6, deve ser definido o AP por intermédio daelaboração de RP.

Nesse sentido, neste trabalho foram definidas, em conjunto com especialistas, 81 RP coma finalidade de uniformizar as frases para o formato local-característica-subcaracterística oulocal-característica. Dessas regras, 66 são do tipo um para um (um termo antigo é substituídopor um termo novo) e 15 são do tipo um para vários (um único termo antigo é substituído porvários termos novos simultaneamente). Para a elaboração de RP, também foram utilizadas Ex-pressões Regulares (ER) com o intuito de identificar características em palavras ou frases, comoespaço em branco excedentes, para padronizá-las adequadamente. Essas RP são apresentadasno Apêndice A.2. Na Figura 7.2 é ilustrado um fragmento do AP elaborado neste trabalho.

No fragmento de AP apresentado na Figura fig:apEC são apresentados três exemplos deRP para a aplicação da padronização de laudos textuais. A primeira RP é aplicada para a substi-tuição da palavra "enantemo" pela sequência "presenca_edema sim", transformando a frase parao formato local-característica-subcaracterística, sendo que esse termo antigo geralmente é pre-cedido por uma palavra que determina uma porção anatômica, por exemplo, "esofago inferior

enantemo".

A frase antiga da segunda RP determina que todas as porções do esôfago apresentampelo menos uma enfermidade, as quais não são descritas explicitamente. Nesse caso, a regra é

99

Figura 7.2: Fragmento do AP desenvolvido no Estudo de Caso.

aplicada para a substituição da sentença antiga por outras três no formato local-característica,determinando que existem anormalidades nas três porções do esôfago.

A terceira RP apresentada na Figura 7.2 é uma das regras que tem o propósito de transfor-mar a descrição da extensão da TEG (transição esôfago-gástrico) medida em centímetros paragrau de anormalidade. Assim, essa porção é considerada normal quando se encontra no mesmonível ou até 0,50 cm acima do pinçamento diafragmático do esôfago, grau 1 ("gi") quando élocalizada entre 1,00 cm e 2,99 cm acima, grau 2 ("gii") para valores de 3,00 cm até 4,49 cm,grau 3 ("giii") para valores de 4,50 cm até 6,00 cm e grau 4 ("giv") para valores a partir de 6,01cm. Essa RP contém ER para identificação de padrões em sentenças de laudos textuais, na qual".*" determina que pode existir nenhum, um ou mais caracteres de qualquer tipo ("."). Ainda, aexpressão "[,.]" determina que pode existir ou não os caracteres "," ou ".", "s*" estabelece quepode haver zero ou mais espaços em branco e "[acima]" descreve que pode existir ou não otermo "acima".

Nesse contexto, as RP foram desenvolvidas para serem aplicadas em laudos textuais le-matizados e sem stopwords devido a menor variabilidade de frases, facilitando a construçãodessas regras.

7.4 Elaboração da Stoplist

Neste estudo de caso foi definida, em conjunto com especialistas, uma stoplist contendo59 termos considerados irrelevantes nesse contexto, na qual são incluídas pronomes, preposi-ções, advérbios, entre outros. Essa transcrição foi realizada por meio da análise do CFU Nor-malizado. Na Figura 7.3 é ilustrada a definição da lista de stopwords a partir de um fragmento

100

de CFU Normalizado, na qual, o usuário identifica o termo considerado irrelevante e o sistemaarmazena-o na stoplist.

Figura 7.3: Exemplo de transcrição de stopwords.

Sendo assim, a stoplist definida neste trabalho é apresentada com as suas stopwords orga-nizadas em ordem alfabética crescente no Apêndice A.1, no qual essa lista é exibida utilizandoestruturas determinadas na linguagem de marcação XML.

7.5 Definição de Atributos da Base de Dados e de Regras deMapeamento

Após a construção dos CFU, as informações geradas são analisadas com o intuito de de-finir a estrutura da base de dados, ou seja, a tabela atributo-valor do SCC. Para isso, foramdefinidos, em conjunto com especialistas, dezesseis atributos representativos com a finalidadede descrever informações relevantes presentes em laudos textuais médicos de EDA. Essas pro-priedades foram divididas em três grupos de acordo com os seus respectivos tipo de valores, quesão apresentados na Seção 7.6. Desse modo, foram definidos nove atributos para a representa-ção dos valores "sim" e "nao" (Grupo 1). Essas características tem a finalidade de representar apresença ou a ausência de enfermidades inflamatórias nas porções de esôfago inferior, médio esuperior, as quais são apresentadas a seguir:

• esofagite_edematosa_inferior: edemas na região do esôfago inferior;

• esofagite_edematosa_medio: edemas no esôfago médio;

• esofagite_edematosa_superior: edemas no esôfago superior;

• esofagite_erosiva_inferior: erosões no esôfago inferior;

• esofagite_erosiva_medio: erosões no esôfago médio;

• esofagite_erosiva_superior: erosões no esôfago superior;

101

• esofagite_ulcerada_inferior: úlceras no esôfago inferior;

• esofagite_ulcerada_medio: úlceras no esôfago médio;

• esofagite_ulcerada_superior: úlceras no esôfago superior.

Os atributos que contém os valores "normal" ou "anormal" (Grupo 2) tem o propósitode determinar se as porções do esôfago (inferior, médio e superior) e as características comocalibre, distensibilidade e motilidade apresentam anormalidade, correspondendo no total de seisatributos, que são apresentados a seguir:

• calibre_esofago: diâmetro interno do esôfago;

• distensibilidade_esofago: elasticidade do tecido do esôfago;

• motilidade_esofago: capacidade do esôfago de realizar movimentos autônomos;

• mucosa_esofago_inferior: condição do esôfago inferior;

• mucosa_esofago_medio: situação do esôfago médio;

• mucosa_esofago_superior: estado do esôfago superior.

Para o grupo de valores "normal", "gi", "gii", "giii" e "giv" (Grupo 3) foi definido apenasum atributo, que é denominado teg_extensao e tem o propósito de determinar se a largura dateg é normal ou caso contrário, apresentar o grau da gravidade de enfermidade.

Paralelamente à atividade de definição de atributos, foram definidas as suas respectivasRM, que são foram elaboradas para mapear frases no formato local-característica e local-

característica-subcaracterística. Para os atributos do Grupo 1, as RM foram definidas paramapear frases que apresentam:

• Uma porção do esôfago (inferior, médio, superior), como região;

• Presença ou ausência de enfermidade do tipo edema, erosão ou úlcera, na forma "pre-senca_anormalidade", como característica;

• Subcaracterística: "sim" ou "não".

Para os atributos do Grupo 2, as RM foram apresentadas na forma local-característica-

subcaracterística para a descrição de características do esôfago inteiro, como o calibre, a dis-tensibilidade e motilidade e para a apresentação da situação de uma porção do esôfago e dapropriedade do Grupo 3, a RM apresenta o formato local-característica. A seguir são apresen-tados exemplos de RM para alguns atributos descritos anteriormente:

• esofagite_edematosa_inferior:

102

– "esofago_inferior presenca_edema nao";

– "esofago_inferior presenca_edema sim".

• calibre_esofago:

– "esofago calibre normal";

– "esofago calibre anormal".

• mucosa_esofago_medio:

– "esofago_medio normal";

– "esofago_medio anormal".

• teg_extensao:

– "teg normal";

– "teg gi";

– "teg gii";

– "teg giii";

– "teg giv".

É importante destacar que os atributos e as RM são representadas por meio de uma on-tologia, como a apresentada na Seção 7.6. Também, a base de dados é preenchida apenas apóso mapeamento dos laudos textuais, com base nas características determinadas para a tabelaatributo-valor.

7.6 Ontologia Construída no Estudo de Caso

Para a representação de atributos e de seus respectivos RM em uma ontologia, foi utilizadaa linguagem OWL devido ao grande poder de expressividade, à inclusão de todos os recursosda linguagem OWL e a garantia de completude computacional e de operação de expressões porcomputadores em tempo finito. Sendo assim, nesse sistema é utilizado o esquema de ontologiaproposto por Costa, Ferrero, Lee, Coy, Fagundes and Chung (2009), que é organizado pelasseguintes classes (Figura 7.4):

• Thing: é a principal classe de todas as ontologias estruturadas na linguagem OWL;

• Valor_de_Atributo: determina os valores dos atributos que deverão ser utilizados para opreenchimento da base de dados;

103

• Grupo_va_1: é uma subclasse de Valor_de_Atributo que apresenta os valores "nao" e"sim";

• Grupo_va_2: é uma subclasse de Valor_de_Atributo que descreve os valores "normal" e"anormal";

• Grupo_va_3: é uma subclasse de Valor_de_Atributo que determina os valores "normal","gi" (grau 1), "gii" (grau 2), "giii" (grau iii) e "giv" (grau 4);

• Atributo_Base_de_Dados: representa os atributos da base de dados;

• Atributo_Tipo_va_1: é uma subclasse de Atributo_Base_de_Dados que descreve os atri-butos que são preenchidos pelos valores de Grupo_va_1;

• Atributo_Tipo_va_2: é uma subclasse de Atributo_Base_de_Dados que determina osatributos que são preenchidos pelos valores de Grupo_va_2;

• Atributo_Tipo_va_3: é uma subclasse de Atributo_Base_de_Dados que estabelece osatributos que são preenchidos pelos valores de Grupo_va_3;

• Termo: é destinada para a representação de termos presentes nos laudos pré-processados;

• Regiao: é uma subclasse de Termo que descreve as regiões do corpo humano;

• Observacao: é uma subclasse de Termo que relata as características e as subcaracterísticasque foram observadas nas regiões representadas pela classe Regiao;

• Caracteristica: é uma subclasse de Observacao que representa as informações relevantesque podem ser mapeadas em laudos textuais;

• Situacao: é uma subclasse de Observacao que descreve as subcaracterísticas, tambémdenominadas informações complementares;

• Anormalidade: é uma subclasse de Situacao que determina as anormalidades descritasem laudos médicos;

• Outra_Situacao: é uma subclasse de Situacao que apresenta outras informações comple-mentares.

Na ontologia apresentada na Figurafig:ontologiaOWL, as classes são representadas deforma hierárquica e os indivíduos como atributos, possíveis valores, regiões anatômicas e ob-servações são instanciados nas subclasses de níveis mais baixos da hierarquia da estrutura,como Anormalidade, Outra_Situacao, Caracteristica, Regiao e as subclasses relacionadas aosatributos.

Para auxiliar na organização do conhecimento presente em laudos médicos por ontolo-gia foram definidas propriedades para desempenhar relacionamentos entre os indivíduos dessaestrutura (Figura 7.6). Assim, uma dessas propriedades de dados é a denominada nomeInstan-

cia, que tem o propósito de descrever um termo para cada elemento, como palavras de laudos

104

Figura 7.4: Hierarquia de classes da ontologia proposta por Costa, Ferrero, Lee, Coy, Fagundesand Chung (2009).

textuais pré-processados, atributos da base de dados e possíveis valores para cada tipo de atri-buto. Essa característica se encontra presente em todas as instâncias de classes. Também, foramdefinidas as seguintes propriedades de objeto:

• observacao: contém os indivíduos que descrevem características e subcaracterísticas emRM;

• regiao: representa as instâncias que determinam as porções anatômicas em RM;

• valor_da_observacao: apresenta o valor a ser preenchido na tabela atributo-valor casoseja mapeada uma determinada RM. Essa propriedade é associada aos elementos perten-centes às classes Anormalidade e Outra_Situacao;

• valor_padrao: determina um valor a ser preenchido em um atributo da tabela atributo-valor caso o mesmo não seja mapeado. Essa propriedade, assim como a observacao e aregiao são aplicadas nas instâncias pertencentes às classes Grupo_va_1, Grupo_va_2 eGrupo_va_3.

Também, cada instância é referenciada pela propriedade rdf:about, a qual é utilizada pormétodos e ferramentas que processam ontologias OWL para identificar cada componente dessa

105

estrutura, como indivíduos, classes e propriedades. Essas referências são atribuídas automatica-mente pelo SCC de forma que seja facilmente legível em nível de código por desenvolvedores deontologias que utilizam a linguagem OWL, permitindo desse modo a intercomunicação, quandonecessário, entre ontologias criadas em ferramentas como o Protege e o SCC desenvolvido nestetrabalho. Na Figura 7.5 é apresentado o exemplo de ontologia ilustrado na Figura 7.4 com umainstância para cada classe do nível mais baixo dessa hierarquia. Nessa Figura, os retânguloscom presença de um círculo de cor alaranjada são classes e os com presença de um prisma decor roxa são indivíduos instanciados em suas respectivas classes.

Figura 7.5: Esquema detalhado de ontologia proposta por Costa, Ferrero, Lee, Coy, Fagundesand Chung (2009) com um exemplo de instância para cada classe utilizada para representaçãode conhecimento.

Assim, as referências de elementos instanciados pelas classes Regiao, Caracteristica,Anormalidade e Outra_Situacao são traduzidas no formato classeIndividuo_numeroIndividuo,no qual classeIndividuo corresponde à classe em que o item se encontra instanciado e nume-

roIndividuo determina a i-ésima instância cadastrada em uma classe da ontologia. Por exemplo:regiao_01, caracteristica_01, anormalidade_01 e outra_situacao_01.

As instâncias das classes Grupo_va_1, Grupo_va_2 e Grupo_va_3 são atribuídas no for-mato valor_de_atributo_x_numeroIndividuo, em que x é uma referência ao grupo de valoresem que o atributo encontra-se instanciado e pode conter apenas os valores "1", "2" ou "3", porexemplo, valor_de_atributo_1_01, que representa o valor de atributo "nao".

106

Os indivíduos das classes Atributo_Tipo_va_1, Atributo_Tipo_va_2 e Atributo_Tipo_va_3

são iguais aos respectivos valores atribuídos pela propriedade nomeInstancia, pois representamos atributos da tabela atributo-valor e as suas respectivas RM. Essas instâncias são definidas deacordo com os grupo de valores que foram escolhidos para o preenchimento de seus atributosna base de dados, por exemplo, se um atributo for do tipo Grupo_va_1, o indivíduo que orepresenta será instanciado na classe Atributo_Tipo_va_1.

Desse modo, as propriedades de objetos são aplicadas nas instâncias que contêm os atri-butos com a finalidade de representar as RM. Abaixo é apresentado um exemplo de atributocom as suas propriedades:

• nomeInstancia: "calibre_esofago";

• regiao: "esofago" (regiao_01);

• valor_padrao: "normal" (valor_de_atributo_2_02);

• observacao: "calibre" (caracteristica_01);

• observacao: "anormal" (anormalidade_01);

• observacao: "normal" (outra_situacao_01);

Na Figura 7.6 é apresentado o atributo "calibre_esofago" representado na linguagemOWL, no qual owl:Thing é um construtor para a definição de indivíduos, rdf:type é uma pro-priedade aplicada para estabelecer as classes relacionadas com o indivíduo, NamedIndividual éa classe de todas as instâncias que são definidas pelo construtor owl:Thing, rdf:resource é umapropriedade semelhante à rdf:about que é utilizada para determinar o nome de uma classe oude uma outra instância.

Figura 7.6: Exemplo de atributo representado na linguagem OWL.

Nesse contexto, o SCC determina implicitamente os indivíduos para as classes Regiao,Grupo_va_1, Grupo_va_2 e Grupo_va_3, nas quais não é permitido que os usuários definamnovos elementos. Os nomes das instâncias de Regiao são:

107

• "esofago" (regiao_01);

• "esofago_inferior" (regiao_02);

• "esofago_medio" (regiao_03);

• "esofago_superior" (regiao_04);

• "teg" (regiao_05);

• "terco_distal" (regiao_06);

• "terco_medio" (regiao_07);

• "terco_proximal" (regiao_08).

Os itens de Grupo_va_1 são nomeados com valores como:

• "nao" (valor_de_atributo_1_01);

• "sim" (valor_de_atributo_1_02).

Os elementos de Grupo_va_2 são identificados como:

• "normal" (valor_de_atributo_2_01);

• "anormal" (valor_de_atributo_2_02).

As instâncias de Grupo_va_3 possuem nomes como:

• "normal" (valor_de_atributo_3_01);

• "gi" (valor_de_atributo_3_02);

• "gii" (valor_de_atributo_3_03);

• "giii" (valor_de_atributo_3_04);

• "giv" (valor_de_atributo_3_05).

Na Figura 7.7 é apresentado um exemplo de esquema de ontologia expandida na classeRegiao.

Para as classes Caracteristica, Anormalidade, Outra_Situacao e as subclasses de Atri-

buto_Base_de_Dados, os indivíduos são criados após a definição de um novo atributo por meiode uma tela acessível pela funcionalidade "Conjunto de Atributos" do SCC apresentada na Fi-gura 6.14. Antes da gravação de novos elementos, na ontologia é verificada a existência deum indivíduo nas subclasses de Atributo_Base_de_Dados com o nome igual ao do atributo em

108

Figura 7.7: Exemplo de esquema de ontologia criada automaticamente pelo SCC com a classeRegiao expandida.

definição. Caso seja inexistente, é criada uma nova instância para representar o novo atributo.Também, os termos que representam características e subcaracterísticas na RM são analisadoscom a finalidade de verificar se foram cadastrados na ontologia. Assim, são criadas instânciasda classe Caracteristica para os termos que descrevem características, da classe Anormalidade

para as observações que apresentam o valor "sim", "anormal", "gi", "gii", "giii" ou "giv" e daclasse Outra_Situacao para as observações que contém o valor "nao" ou "normal".

7.7 Aplicação do Método Mapeamento por Ontologias emLaudos Médicos Artificiais

Com base na estrutura apresentada na Figura 7.4, o PMLM é aplicado em cada cadeia decaracteres presente em um conjunto de laudos médicos. Nesse sentido, ao processar uma frase,o método primeiramente compara cada termo presente na sentença com a informação contidana propriedade nomeInstancia de cada indivíduo das subclasses de Termo com o propósito deverificar se a palavra analisada foi cadastrada na ontologia por meio de RM. Caso o vocábulonão seja encontrado na estrutura, o mesmo é adicionado à lista de termos não-processados, oqual pode ser utilizado posteriormente para a definição de novas RP e RM. Após, nas sub-classes de Atributo_Base_de_Dados são analisadas as respectivas instâncias para localizar osatributos que contém RM compatíveis com as palavras da frase que foram localizadas na onto-logia e preencher a tabela atributo-valor com o valor dos elementos presentes nas subclasses deValor_de_Atributo.

Por exemplo, na frase "esofago calibre normal", para cada termo, primeiramente o algo-

109

ritmo realiza uma busca nos indivíduos representados nas subclasses de Termo da ontologia,como a apresentada na Figura7.5, com a finalidade de identificar uma RM compatível coma sentença avaliada e mapear o seu respectivo atributo. Assim, para cada termo é procuradoum indivíduo compatível nas classes Região ("esofago"), Caracteristica ("calibre") e Situacao

("normal"), sequencialmente. Após, as RM cadastradas na ontologia são investigadas para iden-tificar o atributo, como o "esofago_calibre", que contenha uma RM compatível com essa frasee mapeá-la para uma base de dados.

Também, é importante ressaltar que o algoritmo de mapeamento foi alterado para evitarque os atributos não mapeados sejam preenchidos com seus respectivos valores padrões paraevitar representações errôneas semanticamente. Por exemplo, se em um registro (linha) da ta-bela atributo-valor o atributo "esofagite_erosiva_inferior" for preenchido com o valor "sim",o atributo "mucosa_esofago_inferior" do mesmo registro não pode ocupar o valor "normal",sendo que a outra característica indica presença de erosões no esôfago inferior. Assim, cadaatributo não mapeado em um registro é preenchido com o caractere ”-", indicando que um de-terminado campo está vazio.


Neste capítulo foram apresentadas distintas abordagens para o mapeamento de laudos mé-dicos, desde a abordagem manual até as duas versões do PMLM, que foram desenvolvidas noLABI da UNIOESTE/Foz do Iguaçu em parceria com o Serviço de Coloproctologia da UNI-CAMP. A análise do PMLM permitiu constatar que o uso de todas as técnicas é complexo paraqualquer pessoa que não conheça detalhadamente o método e principalmente por profissionaisque não sejam da área computacional. Isso se deve ao fato de que essas técnicas são executadasseparadamente mediante as instruções computacionais, bem como as estruturas utilizadas peloPMLM devem ser construídas manualmente por meio de uma linguagem de marcação, como oXML.

Com o desenvolvimento de uma solução computacional, o PMLM por ontologias foiautomatizado por intermédio da integração de todas as suas técnicas no SCC. Nesse sistemanão é necessário o conhecimento detalhado de métodos de processamento de textos aplicadospelo processo e de linguagens de marcação para a representação de stoplists, RP, base de dados,RM e atributos.

Nesse contexto, o SCC foi utilizado para a realização de uma avaliação experimental em

110

um conjunto de laudos médicos textuais artificiais de exames de EDA. Assim, foram definidasestruturas para a transformação de laudos e a representação do conhecimento, como a stoplist,o AP, a base de dados e a ontologia. Para isso, foram aplicados métodos de processamento detextos laudos para a construção de CFU, os quais eram utilizados como suporte para a definiçãodas estruturas aplicadas na segunda fase do PMLM.

Após, os laudos foram processados por intermédio dos métodos de normalização, de re-moção de stopwords, de lematização e de padronização. Em seguida, as informações dos laudosuniformizados foram mapeadas para a base de dados (tabela atributo-valor). Esse mapeamentofoi realizado de duas formas: manual, no qual o conhecimento presente nos documentos foitranscrito manualmente para uma planilha eletrônica; e automático, em que foi utilizado o SCCpara a realização do mapeamento.

Desse modo, os resultados da aplicação do PMLM foram avaliados utilizando medidascomo média, desvio-padrão, máximo, mínimo, precisão, custo de tempo (apenas para mapea-mento manual) e custo computacional. Os resultados obtidos nessas avaliações são apresenta-dos no Capítulo 8.

Capítulo 8

Resultados e Discussão


Após a construção do Sistema Computacional Colaborativo (SCC), o mesmo foi avaliadoem conjunto com especialistas do domínio e submetido à aplicação de uma avaliação expe-rimental em um conjunto de 100 laudos médicos textuais artificiais. Para a realização desseexperimento, foi realizado um estudo de caso com o propósito de avaliar o desempenho da apli-cação do Processo de Mapeamento de Laudos Médicos (PMLM) por ontologias automatizado.

Neste capítulo são apresentadas algumas considerações sobre o desenvolvimento do SCC,bem como são apresentados e discutidos os resultados da avaliação experimental da utilizaçãodo PMLM automatizado em um conjunto de laudos textuais. Essas avaliações foram realizadasna etapa de avaliação e feedback do processo de desenvolvimento de sistemas por prototipagem,abordagem utilizada para a construção da solução computacional. Nesse mapeamento, cadafuncionalidade do sistema foi executado e os resultados avaliados.

Sendo assim, a Seção 8.2 são descritas abordagens utilizadas para o mapeamento desseslaudos médicos e alguns trabalhos nos quais foram aplicadas essas abordagens. Na Seção 8.3são discutidos os resultados do desenvolvimento do SCC e na Seção 8.4 são apresentados osresultados e as discussões sobre a aplicação do PMLM automatizado em um conjunto de laudosmédicos, tal como são discutidos os resultados do mapeamento manual dos laudos.

8.2 Aplicação do PMLM em Trabalhos Anteriores

Conforme apresentado no Capítulo 3, o mapeamento de laudos textuais médicos é geral-mente realizado de forma manual para uma base de dados ou planilhas eletrônicas. O mape-amento manual apresenta-se como uma abordagem ineficiente e com elevado custo de tempo,tornando essa atividade inviável para grandes quantidades de documentos textuais.

111

112

Como mencionado, a primeira versão do PMLM era baseada em Dicionário de Dados.Essa proposta foi aplicada em conjuntos de laudos textuais de diversas regiões do sistema di-gestório, nos quais foram obtidos resultados satisfatórios. Em Cherman, Spolaôr, Lee, Hono-rato, Coy, Fagundes and Wu (2008), por exemplo, o método foi usado em um conjunto de 100laudos textuais provenientes de exames de colonoscopia e 609 de exames de Endoscopia Diges-tiva Alta (EDA), para os quais foram mapeados 82,00% e 100,00% das informações presentes,respectivamente.

Assim como o DC, a nova proposta inicial utilizando ontologias, no entanto não automa-tizada, também foi aplicada efetivamente para o mapeamento de conjuntos de laudos médicos,como em Costa, Ferrero, Lee, Coy, Fagundes and Chung (2010), no qual o PMLM foi aplicadoa um conjunto de 3647 laudos de exames de EDA, mapeando aproximadamente 85,82% de suasinformações.

8.3 Construção do Sistema Computacional Colaborativo

Como descrito no Capítulo 7, a utilização do PMLM por profissionais que não sejam daárea computacional ou que não conheçam detalhadamente o método pode não ser uma ativi-dade simples, pois as suas técnicas eram executadas por intermédio de comandos computacio-nais. Também, a construção de estruturas como o Arquivo de Padronização (AP) e a lista destopwords (stoplist) eram realizadas manualmente por meio da linguagem de marcação XML.Ainda, para a elaboração de Regras de Mapeamento (RM) e de atributos era necessário utilizaroutras ferramentas, como o Protégé, que é empregado para a construção de ontologias.

Com o objetivo de automatizar e facilitar o uso do PMLM, neste trabalho foi desenvol-vido um SCC. Para a construção do Sistema Computacional Colaborativo (SCC), foi usada aabordagem de engenharia de software denominada processo de desenvolvimento de sistemaspor prototipagem em virtude da complexidade dos requisitos e a necessidade do envolvimentode especialistas do domínio para o desenvolvimento de uma solução computacional. Essa abor-dagem é aplicada em cinco etapas, como apresentado no Capítulo 4.

Na Etapa 1 (Comunicação) foram estudados os conceitos sobre o PMLM com o propósitode compreender profundamente o funcionamento dos métodos empregados no processo para atransformação de textos. No Capítulo 6, foram apresentadas limitações do uso do processopor profissionais da área da saúde ou que não conhecem o funcionamento do PMLM, comoa execução de técnicas de processamento de textos, as quais eram realizadas manualmente eseparadamente com o uso de comandos computacionais executados por meio de interpretadoresde linha de comando, como o Prompt Command (CMD) do Microsoft c©Windows e o Terminaldo Linux. Para o funcionamento correto desses comandos, é necessária a instalação de um

113

interpretador das linguagens Perl e Java, bem como é imprescindível a instalação de outrasferramentas auxiliares e a configuração do computador do usuário.

Também, a aplicação do método de pré-processamento aplicado no PMLM denominadostemming pode, em alguns casos, gerar resultados de difícil compreensão por especialistas,acarretando na interpretação errônea de alguns termos, Como apresentado em Fuller and Zobel(1998), a redução de palavras para o seu radical pode acarretar casualmente a uma interpretaçãosemântica incorreta por causa da existência de termos com significados distintos, mas comradicais iguais, conforme apresentado no Capítulo 3.

Após a execução de estudos, foram realizadas reuniões em conjunto com especialistasdo domínio com a finalidade de definir os requisitos para a construção do SCC. Os principaisrequisitos foram: a automatização do PMLM; substituição do método de stemming pela técnicade lematização; construção de uma interface web amigável e intuitiva ao usuário; e possibilitaro uso do sistema em qualquer lugar por computadores e outros dispositivo.

Na Etapa 2 (Plano Rápido), os requisitos levantados anteriormente foram estudados eanalisados com o objetivo de compreendê-los e de determinar as atividades e as tecnologias ne-cessárias para o desenvolvimento de uma solução computacional. Paralelamente, foi verificadose era viável a produção de um sistema computacional para atender às especificações levantadasna Etapa 1. Após, foi iniciado o planejamento da construção do SCC e estudada as tecnologiasdescritas no Capítulo 5.

Na Etapa 3 (Modelagem), para facilitar a compreensão das especificações levantadas nasetapas anteriores, no sistema foi modelado um cenário para cada fase do PMLM. Para o primeirocenário foram definidas as seguintes funcionalidades: gerenciamento do conjunto de laudos mé-dicos; construção e gerenciamento do CFU; definição e gerenciamento da stoplist; construçãoe gerenciamento do AP; e definição e gerenciamento do conjunto de atributos. Para o segundocenário foram determinadas as subsequentes funcionalidades: aplicação de pré-processamento;e realização de mapeamento. Nesse sentido, essas funcionalidades disponibilizam recursos parafacilitar a execução de cada técnica de processamento de textos e a definição de estruturas au-xiliares como a stoplist, o AP e a ontologia, sem a necessidade do conhecimento detalhado daslinguagens e outras tecnologias para esse fim. Também, é possível reaproveitar essas estruturaspara realização de novos experimentos. Além disso, no SCC são gerados outros tipos de dadoscomo CFU, laudos padronizados, tabela atributo-valor e lista de termos não processados.

Na Etapa 4 (Construção), o SCC foi construído utilizando ferramentas de uso gratuito, dosquais se destaca o JRuby sob o apoio do framework de desenvolvimento web denominado Rubyon Rails (RoR), para a qual estão disponíveis diversas funcionalidades para prover suporte àconstrução de sistemas, as quais são mantidas e desenvolvidas crescentemente pela comunidade.

Para o gerenciamento do cadastro e o controle do acesso ao sistema por meio de login e

114

senha, foi utilizada a gem Devise, a qual constrói automaticamente as telas para a autenticação,o cadastro, a atualização e a remoção de conta de usuário, sendo apenas necessária a customiza-ção dessas telas por parte dos desenvolvedores. O controle do acesso ao SCC apresenta grandeimportância para a segurança de dados dos usuários, principalmente por se tratar de informa-ções médicas, pois é uma das formas mais eficazes para evitar o acesso indevido aos dados,proporcionando confidenciabilidade e integridade dos mesmo.

O armazenamento de dados de cadastro de usuários é realizado com o uso do sistemade gerenciamento de bases de dados RoR chamado SQLite devido a sua simplicidade para ogerenciamento, a implementação e a manutenção de base bases de dados.

A linguagem de programação Java apoiada pelo ambiente de desenvolvimento NetBeansfoi utilizada para a elaboração de métodos que ofereçam suporte para a execução das técnicasde processamento de textos do PMLM que foram escritas na linguagem Perl e a construção e ocarregamento de AP, stoplists e ontologias. Assim, foram desenvolvidos os seguintes métodos:gerenciador de CFU; gerenciador de stopwords; gerenciador de Regras de Padronização (RP);configurador de parâmetros; e pré-processador de laudos. Nesse contexto, as tecnologias em-pregadas para a construção desses métodos oferecem vários recursos, como extensa bibliotecade ferramentas auxiliares, para a produção de sistemas que apresentam requisitos consideradoscomplexos.

Para facilitar o uso das técnicas de processamento de textos do PMLM pelo SCC, ocódigo-fonte das mesmas foi alterado para reduzir a complexidade de sua execução em méto-dos escritos na linguagem Java. Das técnicas alteradas destaca-se a de padronização de laudos,a qual foi reformulada para utilizar apenas um AP que represente todas as RF definidas, masmantendo as técnicas originais de tratamento de RP de diferentes tipos, como um para um e umpara vários.

Para a redução da perda de legibilidade causada pela transformação de termos por seusrespectivos radicais, a técnica de stemming foi substituída pela de lematização, que tem a finali-dade de transformar as palavras para a sua forma simplificada, também denominadas de lemas,como o masculino do substantivo feminino, infinitivo do verbo conjugado, singular de um subs-tantivo plural, entre outros. O uso da lematização possibilita a redução da perda de legibilidadee da variabilidade de palavras, facilitando a descoberta de padrões que podem ser utilizados paraa elaboração do RP, RM e de atributos da base dados. Esse método foi implementado utilizandoa linguagem Perl para facilitar a sua integração com as técnicas de geração de CFU da primeirafase e de pré-processamento da segunda fase do PMLM.

Com a linguagem Perl, também foi desenvolvido um método para automatizar a constru-ção de CFU a partir dos laudos textuais selecionados por usuários na funcionalidade de geren-ciamento do conjunto de laudos médicos do primeiro cenário do SCC. Assim, nesse métodofoi possível integrar ao sistema as técnicas aplicadas no PMLM que foram desenvolvidas na

115

linguagem Perl em trabalhos anteriores realizados no Laboratório de Bioinformática (LABI) emodificados neste trabalho.

Também, o método de mapeamento de laudos médicos por ontologias, desenvolvido emJava, foi integrado ao SCC. Para isso, foram elaboradas novas funcionalidades para possibi-litar a realização das seguintes tarefas: seleção de ontologias por usuários; gerenciamento deatributos de bases de dados; imposição de que as RM devem-se encontrar nos padrões local-

característica-subcaracterística ou local-característica; geração de resultados no formato detexto de forma que simplifique a sua visibilização na interface do sistema; e carregamento egravação dos resultados do mapeamento como a tabela atributo-valor e a lista de termos nãoprocessados. Com o desenvolvimento dessas funcionalidades, o uso do método de mapea-mento foi facilitado e aprimorado, bem como não é mais necessário o uso de outras ferramentascomputacionais para a construção de ontologias, estando todas as técnicas necessárias para aaplicação do PMLM integradas no SCC.

Também, destaca-se que o SCC pode ser utilizado remotamente em qualquer computadorou outro dispositivo computacional e em qualquer lugar, sem a necessidade de instalação e deconfiguração de um ambiente computacional, sendo necessário apenas o acesso à internet. Ou-tra característica importante desse sistema é a utilização de apenas ferramentas de uso gratuitopara sua construção. Além disso, foi construída uma interface web amigável e interativa como usuário para facilitar o uso do SCC. Para isso, foram utilizadas as linguagens HTML, CSS eJavascript com a finalidade de desenvolver uma página web acessível para cada funcionalidadedos cenários do sistema. As linguagens utilizadas para a elaboração de telas são amplamenteaplicadas em sistemas web pela comunidade de desenvolvedores, pois possuem código legívele de fácil uso, bem como é possível desenvolver ferramentas interativas e intuitivas com osusuários.

Para a construção das telas do SCC, foi usado o modelo de estruturas propostas por Jung(2012) com a finalidade de padronizá-las de acordo com os projetos desenvolvidos e em desen-volvimento no LABI. Também, para auxiliar no carregamento de laudos, de stoplists, de AP ede ontologias, foi utilizada a gem Paperclip, que constrói automaticamente os gerenciadores decarregamento de laudos do computador do usuário.

Na Etapa 5 (Avaliação), o SCC foi avaliado em conjunto com especialistas do domínio,os quais constataram que o mesmo atende às especificações definidas e apresenta-se como degrande valia para a extração e o estudo de padrões que podem ser encontrados nos laudostextuais (Lee, Oliva, Maletzke, Machado, Voltolini, Coy, Fagundes and Wu, 2013). Assim, osistema pode contribuir com a geração de novos conhecimentos, tais como: desenvolvimentode novos procedimentos médicos; identificação de padrões que podem acarretar à determinadasenfermidades, entre outras.

A construção do SCC possibilitou automatizar e facilitar o uso do PMLM por usuários

116

sem a necessidade do conhecimento detalhado dos métodos empregados nesse processo, daslinguagens de marcação utilizadas para a representação do conhecimento e de outras ferramen-tas para a construção de ontologias. Para isso, como mencionado, no SCC são disponibilizadasfuncionalidades para o processamento de laudos textuais em dois cenários, sendo cada um cor-respondente a uma fase do PMLM.

No primeiro cenário, é possível carregar laudos textuais remotamente a partir do com-putador do usuário e visibilizar os seus respectivos conteúdos no sistema, tal como é viável aconstrução e a visibilização de CFU por intermédio da aplicação de métodos de processamentode textos nesses documentos. Também, é agilizada a definição de stopwords e, posteriormente,a exportação dos termos considerados irrelevantes para uma stoplist; a elaboração de RP, quecompõem o AP; e na definição de RM e de atributos da base de dados que irão constituir umaontologia.

O segundo cenário, possibilita o reuso dos laudos usados no primeiro cenário e/ou a aber-tura de novos conjuntos; a seleção e a aplicação de técnicas de processamento de textos, comonormalização, remoção de stopwords, lematização e padronização; e a realização do mapea-mento dos laudos uniformizados utilizando ontologias para o preenchimento da base de dados,bem como a visibilização dos resultados, como a tabela atributo-valor (base de dados) e a listade termos não processados.

É importante destacar que o usuário pode armazenar localmente em seu computador osresultados da aplicação do PMLM, como a lista de CFU, a stoplist, o AP, a ontologia, o conjuntode laudos pré-processados para a aplicação do método de mapeamento, a tabela atributo-valore a lista de termos não processados.

Desse modo, o desenvolvimento do SCC foi considerado desafiador, pois além da com-plexidade dos requisitos e da interdisciplinaridade do projeto, envolveu a interação entre dife-rentes métodos e ferramentas escritos em linguagens de programação distintas, o que ocasionouem maior tempo de estudos das especificações levantadas inicialmente e de tecnologias para aprodução do sistema.

8.4 Avaliação Experimental em Laudos Médicos Artificiais

Como apresentado no início deste capítulo, o PMLM automatizado foi aplicado a umconjunto de 100 laudos médicos textuais artificiais construídos por especialistas do Serviçode Coloproctologia da Universidade Estadual de Campinas (UNICAMP). Assim, esses docu-mentos foram submetidos à aplicação de técnicas de processamento de textos em cada fase doPMLM por meio do uso do SCC.

No primeiro cenário do sistema, os laudos foram submetidos à aplicação de técnicas de

117

processamento de textos para a construção de estruturas como a stoplist, o AP e a ontologia.Inicialmente, foi construído o primeiro CFU mediante concatenação dos documentos textuais eeliminação de frases repetidas. Em seguida, nesse conjunto de sentenças foi aplicada a técnicade normalização, gerando o CFU Normalizado.

Após, foi construída a stoplist apresentada no Apêndice A.1 e aplicado o método deremoção de stopwords no CFU Normalizado para a construção do CFU Normalizado e semStopwords. Depois, nesse conjunto foi aplicado o procedimento de lematização, concebendoo CFU Lematizado e sem Stopwords, o qual foi analisado com a finalidade de identificar pa-drões interessantes para a elaboração RP que irão compor o AP. Essas regras foram geradas noformato local-característica-subcaracterística e local-característica, as quais são apresentadasno Apêndice A.2. Em seguida, O AP foi aplicado por meio da técnica de padronização para aconstrução do CFU Padronizado.

Depois da geração do CFU Padronizado, o mesmo foi utilizado para a definição de atribu-tos que compõem a base de dados e as RM para mapear essas características em laudos textuaispara essa base. Esses atributos e RM constituem uma ontologia, que é utilizada para a transfor-mação de documentos textuais não estruturados para o formato estruturado.

No segundo cenário do SCC, os laudos utilizados na primeira fase do PMLM foram pré-processados utilizando sequencialmente as técnicas de normalização, de remoção de stopwords,de lematização e de padronização. Nesse pré-processamento foram utilizados a stoplist e o APdefinidos no primeiro cenário. Após, as informações presente nos laudos pré-processados forammapeadas para a base de dados utilizando a ontologia definida anteriormente. Esse mapeamentofoi realizada de duas formas: manual, em que essa tarefa é realizada manualmente para umaplanilha eletrônica; e automática, na qual o SCC realiza automaticamente essa tarefa. A seguir,são apresentados e discutidos os resultados da avaliação dos dados gerados com a execução doPMLM.

A avaliação dos CFU gerados em relação à quantidade de frases é apresentada na Fi-gura 8.1, em que é possível constatar que a quantidade de frases foi reduzida no decorrer daexecução das técnicas de processamento de textos do PMLM. Sendo assim, a geração do CFUproporcionou uma redução de 82,25% do número de frases em relação à quantidade total inicial(400 frases), facilitando a análise por parte dos especialistas do domínio. O CFU Normalizadocontém a mesma quantia de sentenças em relação ao primeiro conjunto, com o total de 71 obser-vações. A efetuação da técnica de remoção de stopwords acarretou na eliminação de 9,86% dasfrases do CFU. Com o emprego do método de lematização, o número de sentenças foi reduzidoem 4,69% e a padronização do CFU ocasionou na eliminação de 21,31% das observações emrelação ao total.

Na Figura 8.2 é ilustrada graficamente a quantidade de termos gerados para cada CFU.Nessa figura, o CFU construído inicialmente e o CFU normalizado contém 853 palavras cada,

118

Figura 8.1: Avaliação dos CFU gerados por quantidade de frases.

representando uma redução de 66,15% em relação ao total original de 2.520 palavras. Com ageração do CFU Normalizado e sem Stopwords, foi reduzido 50,29% do número total de vocá-bulos. A aplicação do método de lematização acarretou na eliminação de 2,59% das palavras doCFU e a padronização do CFU determinou na atenuação de 55,45% da quantidade de termos.

Figura 8.2: Avaliação dos CFU gerados por quantidade de palavras.

Nesse sentido, é importante destacar que cada frase não pré-processada do conjunto de

119

laudos contém em média 6,30 termos. No primeiro CFU construído foi constatada uma médiade 12,01 palavras por sentença, indicando que a maioria das observações repetidas comportama menor quantidade de vocábulos. As frases que apresentam maiores repetições são calibre e

distensibilidade normais e motilidade normal, os quais retêm 99 registros cada, correspondendoa 49,50% do número total. A remoção de termos considerados irrelevantes e a lematizaçãoresultou em 6,62 e 6,77 palavras por frase, respectivamente. A padronização do CFU acarretouem 3,83 vocábulos por observação, constatando que esse conjunto possui frases que não estãototalmente no formato local-característica ou local-característica-subcaracterística, as quaissão adicionadas a uma lista de termos não processados que poderá ser utilizada futuramentepara aumentar e atualizar a ontologia, a tabela atributo-valor e as RM.

Na Tabela 8.1 são apresentadas as médias, os desvios-padrão, os mínimos e os máximossobre os resultados da avaliação dos CFU gerados neste trabalho.

Tabela 8.1: Resultados da avaliação dos CFU gerados.Média Desvio-padrão Mínimo Máximo

Frases 63,00 9,46 48 71Termos 542,60 300,99 184 853

Com base nesta tabela, o menor CFU construído neste trabalho contém 48 frases ou 184termos e o maior conjunto de CFU contém 71 frases ou 853 termos. Assim, a partir da análisedas Figuras 8.1 e 8.2 é constatado que o CFU Padronizado apresenta a menor quantidade desentenças e de vocábulos e o CFU Normalizado contém o maior número de observações e depalavras.

A transcrição automática para a base de dados resultou no mapeamento de 100,00%das informações consideradas relevantes nesses documentos. Nesse contexto, é destacado que40,00% dos laudos apresentaram termos que não foram processados, pois não foram definidasRP e RM para processá-las. Esses vocábulos são incluídos na lista de termos não-processados,o qual contém 37 palavras diferentes, apresentados em ordem alfabética na Tabela 8.2.

Nessa tabela é possível constatar que os termos não-processados com maior incidêncianos laudos padronizados são nao_confluente, espessado e linear, os quais foram registradosdez, oito e seis vezes, respectivamente. Desse modo, é importante destacar que a lista de termosnão-processados pode ser empregada para a definição de novos atributos, RM e RP, aumentandoa variabilidade de opções para a representação do conhecimento.

Também, a aplicação do PMLM foi avaliado quanto custo computacional para a execuçãodas técnicas de processamento de textos e ao tempo estimado para a construção da stoplist, doAP e da ontologia.

O custo computacional de cada técnica de transformação de textos aplicada no PMLMpor meio do SCC é diretamente relacionado com a quantidade de laudos utilizados para o pré-

120

Tabela 8.2: Quantidade de termos não-processados.Termo Quantidade Termo Quantidade

12 1 extensao 215 1 gastrico 52,0 1 infiltrado 13,0 1 junto 45 1 linear 6

acima 2 liquido 1avaliacao 1 medio 1

barrett 5 miniliase 1biopsia 2 mm 2

circunferencia 3 moniliase 2cm 5 mucosa 5

confluente 1 nao_confluente 10diafragmatico 1 pincamento 1dificultando 1 piriforme 1

epiglote 1 presenca 1especifico 1 profunda 1espessado 8 quantidade 1

extendendo 2 seio 1extendento 1 – –

processamento e pode ser organizado de acordo com as duas fases do processo (cenários noSCC). Na Tabela 8.3 é apresentado o custo computacional, em termos de complexidade, para aexecução de cada método do PMLM, bem como o número de operações de comparação realiza-das. Como referência para o tempo de execução correspondente, considerou-se neste trabalhoum computador capaz de executar um milhão de instruções por segundo, ou seja, equivalente aum computador com processador Intel 4004 de 1.000 KHz (Ziviani, 2010). Nessa tabela têm-se:

• NL: quantidade de laudos;

• NMC : número médio de caracteres por frase;

• NMF : número médio de frases por laudo;

• NMT : número médio de termos por frase;

• NRL: número de regras de lematização;

• NS: quantidade de stopwords;

• NP : quantidade de RP;

• NRM : quantidade de RM.

O conjunto de 100 laudos (NL) utilizado neste estudo de caso contém no total 15.798caracteres, sendo contabilizados 39,50 por frase (NMC). Cada frase contém em média 6,30termos (NMT ) e cada laudo desse conjunto contém quatro frases em média (NMF ).

Como apresentado no Capítulo 7, para a aplicação das técnicas de remoção de stopwords

e de padronização foram definidas 59 palavras consideradas irrelevantes (NS) e 81 RP (NP ),

121

Tabela 8.3: Complexidade dos métodos empregados no PMLM e os respectivos valores emnúmero total de comparações para 100 laudos.

Método Complexidade No de ComparaçõesConstrução de CFU (E1) O(NMC × (NMF ×NL)

2 +NMF ×NMC ×NL) 6.407.980Normalização (E2) O(NMF ×NMC ×NL) 15.800

Remoção Stopwords (E3) O(NMF ×NS ×NL ×NMT ) 148.680Lematização (E4) O(NMF ×NRL ×NL ×NMT ) 65.520Padronização (E5) O(NMF ×NP ×NL ×NMT ) 204.120Mapeamento (E6) O(3×NMF ×NRM ×NL ×NMT ) 264.600

respectivamente. Com relação à aplicação da técnica de lematização, neste estudo de caso foramdefinidas um total 26 regras (NRL) para a substituição de sufixos de palavras.

Na ontologia utilizada no estudo de caso, os atributos apresentam uma RM para cadavalor possível relacionado ao tipo de dados que os mesmos representam. Nessa ontologia,quinze atributos são do tipo que apresentam dois valores possíveis, isto é, pertencentes ao Grupo1 ("sim" ou "nao") e ao Grupo 2 ("normal" ou "anormal"), determinado duas RM para cadaatributo, totalizando 30 regras. Para o Grupo 3 ("normal", "gi", "gii", "giii" ou "giv"), foidefinido um atributo com cinco RM. Essa ontologia contém portanto o total de 35 RM (NRM ).

Como mencionado, a análise do custo computacional para a execução do PMLM com-pleto, considerando que ainda não existem as estruturas AP, base de dados, ontologia e stoplist,que devem ser construídas apenas para o primeiro mapeamento e podem ser reutilizadas paramapeamentos posteriores do mesmo tipo de laudos, pode ser organizada em duas partes, deacordo com as duas fases do processo ou cenários do SCC.

Assim, na primeira fase (cenário 1 do SCC), o custo computacional total é de 24.621,84segundos (6 horas 50 minutos e 21,84 segundos), estimados do seguinte modo:

1. Construção de CFU normalizado, com remoção de stopwords, lematizado e padronizado:E1 + E2 + E3 + E4 + E5 baseado nas complexidades apresentadas na Tabela 8.3, ou seja,6.842.280 de comparações equivalentes a 6,84 segundos;

2. Análise dos CFU e construção da stoplist contendo 59 stopwords (Tarefa 1): 1.800 se-gundos (30 minutos);

3. Construção do AP (Tarefa 2): 13.365 segundos (3 horas 42 minutos e 45 segundos) para81 RP (165 segundos ou 2 horas e 45 segundos para a definição de cada RP);

4. Construção da ontologia (Tarefa 3): 9.450 segundos (2 horas 37 minutos e 30 segundos)para 35 RM (270 segundos ou 4 minutos e 30 segundos para a definição de cada RM).

Para a segunda fase (cenário 2 do SCC), o custo computacional é de E2 + E3 + E4 +

E5 + E6, totalizando 698.900 comparações (0,70 segundos). Assim, o custo total da aplicação

122

das técnicas de processamento de textos nas duas fases do PMLM é de (Tarefa 1 + Tarefa 2 +

Tarefa 3) + E1 + 2 × (E2 + E3 + E4 + E5) + E6, isto é, a 24.622,54 segundos (6 horas 50minutos e 22,54 segundos).

Para o mapeamento manual, as informações contidas nos laudos padronizados foramtranscritas para uma planilha eletrônica, neste caso específico o Excel. Nessa base de dados,foram definidas 17 colunas, na qual uma é utilizada para o preenchimento de células com onome dos laudos e 16 para a representação dos atributos. Em seguida, o conhecimento lido emcada um desses documentos foi transcrito manualmente para a planilha desenvolvida anterior-mente, preenchendo cada atributo identificado nos laudos. O tempo médio para o mapeamentofoi de 95 segundos por laudo, totalizando 9.500 segundos, ou seja, aproximadamente 2 horas e38 minutos. A este tempo estimado, é imprescindível acrescentar o custo de tempo necessáriopara a definição dos atributos que irão compor a base de dados. Esta tarefa também requer aconstrução e a análise de CFU, de modo que os padrões a serem mapeados possam ser identifi-cados. Neste trabalho foi estimado o tempo de 10.560 segundos (2 horas 56 minutos) para paraesta tarefa, divididos do seguinte modo:

• 5 segundos para copiar e colar as frases de cada laudo em um aplicativo que permitamanipular as frases dos laudos, como o Excel (subtotal de 500 segundos);

• 10 segundos para selecionar a opção no aplicativo que permite ordenar as frases;

• 600 segundos para identificar e excluir as frases repetidas;

• 9450 segundos, equivalente a Tarefa 3, para analisar o CFU e criar a base de dados.

Desse modo, o custo de tempo total estimado para a realização do mapeamento manualfoi de 5 horas e 34 minutos.

Para prover uma visão mais ampla sobre o desempenho comparativo entre as abordagensde mapeamento manual e automático, na Figura 8.3 é apresentado um gráfico da relação númerode laudos (em centenas) versus minutos.

É importante relembrar que, apesar do tempo elevado para a construção das estruturasAP, ontologia, base de dados e stoplist, essas estruturas necessitam ser definidas apenas naprimeira execução do PMLM automatizado e poderão ser reutilizadas nos mapeamentos poste-riores de outros laudos do mesmo domínio. Além disso, a segunda fase do PMLM apresentacusto extremamente baixo de execução. Em contrapartida, no mapeamento manual, o tempopara a transcrição das informações por documento é constante e portanto, cresce linearmentede acordo com o número de laudos a serem analisados, como pode ser observado na Figura 8.3.Outra vantagem do PMLM automatizado é a possibilidade de fácil identificação e inclusão denovos atributos, apoiado pela identificação automática dos termos não mapeados anteriormente.

123

Figura 8.3: Avaliação do desempenho em relação ao tempo para o mapeamento manual e auto-mático.

Nesse contexto, é possível observar que a partir de 260 laudos, considerando documentoscom características semelhantes aos empregados neste estudo de caso, o custo de tempo para aaplicação do PMLM automatizado será menor que o da transcrição manual (Figura 8.3).


Neste trabalho, foi construído o SCC com o intuito de automatizar o PMLM por ontolo-gias. Para isso, foram utilizadas as tecnologias apresentadas no Capítulo 5, das quais se destacaa linguagem JRuby, que possibilita o uso de métodos escritos nas linguagens Ruby e Java si-multaneamente. Para a construção de um sistema web de forma rápida e eficiente, o principalframework utilizado foi o Ruby on Rails (RoR).

Após a construção da solução computacional e a sua apreciação por especialistas do do-mínio, o sistema foi utilizado para a realização de uma avaliação experimental em um conjuntode 100 laudos médicos artificiais de exames de EDA, apresentando resultados consideradosmuito bons.

124

Na abordagem manual, foram mapeados todos os atributos presentes nos laudos para abase de dados com o tempo médio de 95 segundos por documento textual, totalizando aproxi-madamente 2 horas e 38 minutos. Nesse sentido, o mapeamento manual apresenta-se ineficientequando aplicado em grandes quantidades de dados, pois é necessária a efetuação de um imensoesforço repetitivo em um longo período, podendo acarretar em transcrições errôneas e desesti-mular a realização de estudos em grandes quantidades de laudos.

Com a transcrição automática por intermédio do SCC, foram mapeados 100% dos atribu-tos presentes nesses laudos. Apesar de que algumas palavras não foram processadas, devido àinexistência de RP para tratá-las ou de RM para mapeá-las, a execução do método apresentoubons resultados, ratificando com as avaliações realizadas em trabalhos anteriores. Nesse sen-tido, a lista de termos não processados pode ser empregada para a elaboração de novas regraspara a transformação e o mapeamento do conhecimento presente em textos médicos, tal comoos seus elementos podem ser incluídos na lista de vocábulos considerados irrelevantes (stoplist)de modo que seja possível a eliminação ou a redução de inconsistências de documentos textuaisprocessados pelo PMLM.

Sendo assim, a representação adequada de frases apresenta-se fundamental para que ométodo de mapeamento seja aplicado corretamente e obtenha resultados satisfatórios. Neste tra-balho, por exemplo, as RM da ontologia representam as frases no formato local-característica

ou local-característica-subcaracterística, ou seja, é recomendado que as sentenças de laudospré-processados estejam representados dessa maneira.

Nesse contexto, a aplicação do PMLM automatizado apresenta-se promissora para a ex-tração de padrões em laudos médicos e a representação do conhecimento em base de dadosestruturadas, como a tabela atributo-valor. Com o segundo cenário do SCC, a transformaçãode laudos e o mapeamento de suas informações são realizadas automaticamente, sendo apenasnecessária a seleção de técnicas de processamento de textos e a existência de estruturas como astoplist, o AP e a ontologia cadastradas remotamente na pasta do usuário no sistema.

No Capítulo 9, são apresentadas as conclusões adquiridas durante o desenvolvimentodeste trabalho, as principais contribuições e limitações do SCC e as sugestões para desenvolvi-mento de trabalhos futuros.

Capítulo 9

Conclusão

Atualmente, devido às grandes quantidades de informações médicas armazenadas em ba-ses de dados em hospitais e clínicas, é fundamental o desenvolvimento de métodos e de fer-ramentas computacionais para auxiliar na análise e no gerenciamento desses dados. Um dosprocessos que podem prover apoio nessa análise é o de Mineração de Dados (MD), que permitea identificação de padrões contidos nos dados, os quais podem contribuir para a aquisição deimportantes conhecimentos, como: elaboração de novos medicamentos; criação e aperfeiçoa-mento de procedimentos médicos; novas formas para o diagnóstico e o tratamento de enfermi-dades; fatores que aumentam os riscos para a progressão de certas doenças; entre outros. Outrapossibilidade de uso desses padrões é a construção de modelos preditivos por meio de técni-cas de Inteligência Computacional (IC) para prover suporte aos especialistas em diversas áreas,como na da saúde no diagnóstico de enfermidades e em processo de tomadas de decisão.

Imensa parte das informações registradas nas bases de dados médicos são provenientes deexames clínicos, laboratoriais e de imagens, os quais são descritos em laudos textuais com a fi-nalidade de representar observações a respeito do estado de saúde dos pacientes, procedimentosmédicos, medicamentos, entre outros. Esses laudos, além de serem comumente representa-dos de forma não-estruturada, ou seja, em língua natural, podem conter, por exemplo, errosde digitação e de ortografia, falta de preenchimento de informações importantes, entre outros,dificultando a aplicação direta de MD.

Nesse sentido, o Processo de Mapeamento de Laudos Médicos (PMLM) pode ser am-plamente utilizado para a transformação de laudos textuais a fim de representá-los em um for-mato adequado para a realização de MD, auxiliando na extração e na descoberta do conheci-mento. Para possibilitar o uso do método por profissionais que não conheçam detalhadamenteo processo ou que não sejam da área computacional, como os da área de saúde, neste trabalhofoi construído um Sistema Computacional Colaborativo (SCC) para automatizar e aprimorar oPMLM por meio da integração de todos os métodos propostos e inseridos neste processo.

Durante o desenvolvimento deste trabalho, foi realizada a revisão bibliográfica, na qualforam estudados conceitos relacionados ao PMLM por ontologias com a finalidade de com-

125

126

preender o funcionamento e as limitações do método. Para isso, foram estudadas as técnicase as estruturas utilizadas no PMLM, bem como foi realizado o mapeamento manual, seguindoos métodos do PMLM em um conjunto de laudos textuais artificiais que simulam exames deEndoscopia Digestiva Alta (EDA) para verificar detalhadamente o funcionamento do processoe do sistema em desenvolvimento.

Após, foi realizado um estudo de caso com a finalidade de propor e desenvolver umaferramenta para reduzir as limitações do uso do PMLM por usuários que não fossem da áreacomputacional. Assim, nesse estudo foi desenvolvido um SCC com o propósito de automatizare de consolidar o PMLM. Nesse sistema foram construídas funcionalidades para cada fase dométodo, tal como foi proposta a substituição da abordagem de transformação de textos deno-minada stemming pela lematização para aprimorar a representatividade dos termos presentesnos laudos, facilitando e melhorando a padronização. A técnica de lematização passou a serutilizada também na segunda fase, de modo que o próprio processo de busca na ontologia e omapeamento para a base de dados fosse otimizado.

No SCC, foi definida uma interface gráfica web com o intuito de possibilitar o seu usoem qualquer lugar que tenha acesso à Internet e sem a necessidade de instalação de softwares ede configuração da máquina do usuário. Esse sistema foi organizado em dois cenários baseadosnas duas fases do PMLM e cada uma das tarefas é disponibilizada ao usuário por meio de telasespecíficas de modo que cada técnica de processamento seja facilmente aplicada e os resultadossejam visibilizados de modo direto e simples.

O SCC foi avaliado em conjunto com especialistas do domínio, os quais o consideraramcomo promissor para a extração e o estudo de padrões que podem ser identificados em laudostextuais médicos. Também, o SCC foi utilizado para avaliar o desempenho de sua aplicação emum conjunto de laudos médicos textuais artificiais, no qual se obteve resultados consideradosmuito bons.

9.1 Principais Desfechos deste Trabalho

Com a concepção do SCC e o resultado de sua avaliação, é possível obter as seguintesconclusões:

• A automatização e a consolidação do PMLM por meio de um SCC possibilita o uso dométodo por especialistas de outras áreas, como da área médica, sem a necessidade daparticipação de profissionais da área computacional;

• O SCC proporciona a aplicação do método de mapeamento de forma mais objetiva, ágil,eficiente e com menor custo de tempo por meio de uma interface gráfica web amigável e

127

intuitiva ao usuário;

• O sistema oferece recursos que facilitam a elaboração de Regras de Padronização (RP) ede Regras de Mapeamento (RM) sem a necessidade do conhecimento técnico de lingua-gens de marcação para representá-las;

• Para a construção de ontologias não é necessária a utilização de outras ferramentas, comoo Protégé;

• É possível reutilizar as estruturas de representação do conhecimento para a realização deoutros experimentos;

• O desenvolvimento deste trabalho foi considerado desafiante, visto que além de envolverinterdisciplinaridade, necessitou o uso de tecnologias escritas em distintas linguagens deprogramação;

• A integração das técnicas de processamento de textos utilizadas no PMLM viabiliza arealização de estudos mais completos e detalhados em conjuntos de laudos médicos porprofissionais da área de saúde;

• O SCC pode contribuir em descobertas importantes por meio da identificação e do estudode padrões encontrados em laudos médicos.

9.2 Limitações

Durante e após o desenvolvimento deste trabalho foram identificadas limitações do SCC,as quais são descritas a seguir:

• No sistema não é possível determinar exceções para regras de lematização;

• Para a definição de algumas RP, é exigido o conhecimento do usuário sobre ExpressõesRegulares (ER);

• A construção de RM pode ser realizada apenas de uma única forma (local-característica-

subcaracterística). No entanto, esta forma se mostrou adequada, até o momento, do pontode vista dos especialistas do domínio;

• No SCC não é realizado tratamento semântico de RM para correção de erros relacionadosao preenchimento de informações por especialistas, podendo influenciar no desempenhoda aplicação do método de mapeamento;

• O estudo de caso foi restrito a um conjunto de laudos textuais artificiais de exames deEDA.

128

No SCC, foi proposta a substituição da técnica de stemming pela lematização com a fi-nalidade de aprimorar a transformação de laudos textuais por meio do uso de regras de le-matização em cada termo, modificando para sua forma canônica, mediante a substituição desufixos de substantivos femininos e/ou plurais por sufixos que convertem esses vocábulos parasubstantivos masculinos e infinitivos. No entanto, existem palavras na forma canônica queapresentam sufixos compatíveis com regras de lematização, podendo acarretar na modificaçãoerrônea desses termos. Por exemplo, na palavra "mucosa"pode ser aplicada a regra "osa"→"oso", transformando-o erroneamente em "mucoso". Assim, é necessário o desenvolvimento deuma funcionalidade no SCC que possibilite ao usuário a inclusão de exceções para as regras delematização, isto é, definição de uma lista de vocábulos que não devem ser processados pelométodo de lematização.

Nos laudos médicos, mesmo com a execução de técnicas como normalização, remoção destopwords e lematização, as frases podem apresentar algumas peculiaridades que dificultariama aplicação de RP durante a uniformização dos laudos, como o excesso de espaços em brancoentre termos, os erros de digitação, a presença de certos vocábulos entre sentenças, as medidas,entre outros. Para eliminar ou reduzir esses problemas, podem ser aplicadas ER para a identi-ficação de padrões nos termos presentes em documentos textuais. No entanto, para a inclusãodessas expressões em RP é necessário o conhecimento técnico para a sua elaboração, que é inco-mum em profissionais que não sejam da área computacional e que não possuam conhecimentodetalhado do método.

Apesar do sistema facilitar a definição de atributos e de RM, no mesmo só é possível adefinição de regras apenas no formato local-característica-subcaracterística. No entanto, estaforma se mostrou adequada, até o momento, do ponto de vista dos especialistas do domínio, poisem trabalhos anteriores, a sua aplicação para o desenvolvimento de regras tanto para ontologiasquanto para Dicionários do Conhecimento (DC) apresentaram resultados satisfatórios ao seremutilizados na execução do mapeamento de conhecimento em laudos textuais médicos.

O sistema não permite a realização de tratamento semântico de RM para evitar o pre-enchimento errôneo da tabela atributo-valor. Por exemplo, como apresentado no Capítulo 7,se em uma linha dessa tabela o atributo esofagite_erosiva_inferior for preenchido com o valorsim, no atributo mucosa_esofago_inferior deve ser atribuído o valor anormal. No entanto, oSCC não garante que essas atribuições sejam feitas semanticamente corretas, isto é, se esofa-

gite_erosiva_inferior contiver o valor "sim" é possível que mucosa_esofago_inferior seja ocu-pado com o valor "normal". Esse tipo de erro é causado em consequência do preenchimentoerrôneo de informações em laudos textuais por parte dos especialistas. Assim, é imprescindívela inclusão de procedimentos para a criação de regras semânticas com o propósito de aprimorara interpretação de RM pelo método e evitar esse tipo de erro.

129

Neste trabalho, a aplicação do PMLM automatizado foi limitado a um conjunto de laudosmédicos artificiais. A devida documentação para que se possa utilizar dados reais está sendoprovidenciada e outros estudos de caso serão realizados após.

9.3 Principais Contribuições

As principais contribuições deste trabalho incluem:

• Maior agilidade e facilidade para a aplicação do PMLM;

• Redução da dependência de especialistas da área computacional para o uso do método;

• Facilidade para a representação de RP e de RM;

• Possibilidade de fácil identificação de padrões não mapeados e atualização da ontologiapara abranger os mesmos;

• Viabilidade para a definição de vocabulário padrão para termos médicos;

• Construção padronizada e automatizada de grandes bases de dados para estudos futuros;

• Possibilidade de identificação de padrões relevantes em laudos médicos;

• Auxílio no gerenciamento e na análise dados médicos;

• Publicação de resultados em eventos científicos.

Devido às dificuldades para o uso do PMLM por profissionais da área médica, foi rea-lizado o planejamento para o desenvolvimento do SCC para automatizar e facilitar o uso doprocesso tanto por especialistas da área de saúde quanto por profissionais de outras áreas doconhecimento. Nesse sistema foi construída uma interface gráfica web visando facilitar o usodo mesmo e omitir a necessidade de instalação de softwares adicionais e de configuração damáquina por parte do usuário. Também, é destacada a facilidade do uso de cada técnica sema necessidade do usuário executar instruções computacionais e a disponibilidade de funciona-lidades para geração de stoplists, de Arquivos de Padronização (AP) e de ontologias sem anecessidade de conhecimento técnico sobre as linguagens utilizadas para a construção dessasestruturas. Nessas tarefas implementadas em funcionalidades específicas é possível visibili-zar os Conjuntos de Frases Únicas (CFU) gerados, facilitando a identificação de stopwords ea elaboração de RP e de RM. Outro recurso que facilita o uso do PMLM é a possibilidade daseleção, pelos usuários, de técnicas para a transformação dos laudos que serão processadas pelométodo de mapeamento para o preenchimento da tabela atributo-valor. Por fim, nesse sistema épermitida a visibilização e a gravação dos resultados gerados pelo PMLM.

Um termo médico pode apresentar vários sinônimos e as frases podem ser estruturadasde várias formas para descrever uma mesma característica observada em exames de pacientes,

130

dificultado a aplicação de MD em estudos futuros. Nesse sentido, é necessária a utilização demétodos para a redução da complexidade das sentenças desses laudos. No sistema desenvolvidoneste trabalho é disponibilizada uma funcionalidade para a construção de AP de modo ágil eintuitivo. Com a facilidade para a definição de RP, é possível propôr vocabulários padrões paraa estruturação de laudos textuais de modo que seja reduzido e padronizado o uso de sinônimospara descrições médicas, diminuindo a diversidade das frases.

A utilização do PMLM era uma atividade considerada complexa por especialistas da áreada saúde, pois exigia conhecimento técnico de vários conceitos relacionados com a área compu-tacional, como linguagens de marcação e de programação, tal como o uso instruções computa-cionais para a execução de cada técnica de processamento, dificultando a realização de estudosem conjuntos de laudos médicos. Com a automatização do processo e a disponibilidade de fun-cionalidades para a concepção de estruturas utilizadas no método mediante ao SCC é possívela efetuação de estudos mais complexos e detalhados em laudos médicos, bem como construirgrandes bases de dados para esse fim por meio das informações mapeadas. Da mesma forma,os dados mapeados podem ser empregados em aplicações de MD, auxiliando na descoberta depadrões relevantes nesses dados e na contemplação de novos conhecimentos.

Nesse contexto, durante o desenvolvimento deste trabalho foram publicados um resumoe um artigo completo no 62o Congresso Brasileiro de Coloproctologia sob o título de "Sis-tema Computacional para Automatização do Processo de Mapeamento de Laudos Médicos porOntologias", no ano de 2013. Esse trabalho foi escolhido entre os sete melhores deste impor-tante congresso, considerado um dos mais relevantes da área, bem como foi escolhido para serpublicado no Journal of Coloproctology em 2014.

Também, como atividade paralela a este trabalho, foi desenvolvido um aplicativo paradispositivos móveis denominado Sistema Computacional para Análise de Imagens Médicas(SCAIMED-Mobile) com a finalidade de auxiliar na extração de características em fragmen-tos de imagens de tecidos cólicos. Os resultados referentes à construção do SCAIMED-Mobileforam publicados no 62o Congresso Brasileiro de Coloproctologia sob o título de "Protótipode um Sistema Móvel para a Extração de Características em Fragmentos de Imagem de TecidoCólico".

É importante ressaltar também que está em fase de confecção do registro de softwaredo SCC para ser submetido ao Instituto Nacional de Propriedade Industrial (INPI), como umprojeto conjunto entre o Laboratório de Bioinformática (LABI), o Programa de Pós-graduaçãoem Sistemas Dinâmicos e Energéticos da UNIOESTE e o Serviço de Coloproctologia da Fa-culdade ele Ciências Médicas da UNICAMP. Posteriormente, serão também realizadas outraspublicações dos resultados finais deste trabalho

131

9.4 Trabalhos Futuros

Após a construção e a avaliação do sistema, foram constatados diversos trabalhos futurosque podem trazer melhorias e aumentar a aplicabilidade do SCC. Desse modo, trabalhos futurosincluem:

• Realizar testes em laudos médicos reais;

• Executar testes mais amplos e complexos no sistema;

• Disponibilizar no SCC uma funcionalidade que permita aos usuários definirem termosque não devam ser processados pelo método de lematização;

• Incluir outras abordagens de processamento de textos para aumentar a representatividadedos laudos médicos;

• Adicionar procedimentos de monitoramento de qualidade de dados para auxiliar na cons-trução de bases dados complexas e sem inconsistências;

• Viabilizar a criação automática de laudos textuais a partir do processamento de imagens,de vídeos, de áudios, entre outros;

• Oferecer suporte à criação de regras semânticas com o objetivo de propiciar a sincroni-zação de atributos para controlar o preenchimento da tabela atributo-valor por meio dotratamento de possíveis erros relacionados ao preenchimento de dados em laudos textuaispor especialistas;

• Integrar o sistema com outros projetos em desenvolvimento no Laboratório de Bioin-formática (LABI) da Universidade Estadual do Oeste do Paraná (UNIOESTE/Foz doIguaçu);

• Divulgação do trabalho por meio de publicações de trabalhos científicos, de relatóriostécnicos e de registro de software.

Referências Bibliográficas

Abacha, A. B. and Zweigenbaum, P. (2011). Medical entity recognition: a comparison ofsemantic and statistical methods, In Proceedings of BioNLP 2011 Workshop, Stroudsburg,pp. 56–64.

Adobe Systems (1990). Postscript Language Reference Manual, Addison-Wesley, Reading.

Ananiadou, S. and Mcnaught, J. (2005). Text Mining for Biology And Biomedicine, ArtechHouse, Norwood.

Bechhofer, S., van Harmelen, F., Hendler, J., Horrocks, I., McGuinnes, D. L., Patel-Schneider,P. and Stein, L. A. (2004). OWL Web Ontology Language Reference, Disponível em:http://www.w3.org/TR/2004/REC-owl-ref-20040210/. Acesso em: 27 de jan. 2014.

Berners-Lee, T., Hendler, J. and Lassila, O. (2006). The semantic web revisited, IEEE Intelli-gent Systems 21(3): 96–101.

Bodenreider, O. and Burgun, A. (2005). Biomedical ontologies, in H. Chen, S. S. Fuller, C. Fri-edman and W. Hersh (eds), Medical Informatics: knowledge management and Data Mi-ning in biomedicine, Springer, New York, pp. 211–236.

Boudreau, T., Glick, J. and Spurlin, V. (2002). NetBeans: the definitive guide, O’Reilly Media,Sebastopol.

Branco, A. and Silva, J. (2007). Very high accuracy rule-based nominal lemmatization with aminimal lexicon, Anais do XXI Encontro Anual da Associação Portuguesa de Linguística,Lisboa, pp. 169–181.

Braude, E. (2005). Projeto de Software: da programação à arquitetura: uma abordagem base-ada em Java, Bookman Companhia Editora LTDA, Porto Alegre.

Bray, T., Paoli, J., Sperberg-McQueen, C. M. and Maler, E. (1996). Extensible Markup Lan-guage (XML) 1.0, Disponível em: http://www.w3.org/TR/WD-xml-961114.html. Acessoem: 27 de jan. 2014.

Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E. and Yergeau, F. (2006). Extensible Mar-kup Language (XML) 1.0 (second edition), Disponível em: http://www.w3.org/TR/xml11/.Acesso em: 27 de jan. 2014.

Brickley, D. and Guha, R. V. (2004). RDF Vocabulary Description Language 1.0: RDF Schema,Disponível em: http://www.w3.org/TR/2004/REC-rdf-schema-20040210/. Acesso em: 27de jan. 2014.

Campbell, K. E. (1998). The unified medical language system: Toward a collaborative ap-proach for solving terminologic problems, Journal of the American Medical InformaticsAssociation 1(5): 12–16.

133

134

Carlson, L. and Richardson, L. (2006). Ruby Cookbook, O’Reilly Media, Sebastopol.

Castro, E. and Hyslop, B. (2013). HTML and CSS: Visual QuickStart Guide, Peachpit Press,San Francisco.

Cherman, E. A., Lee, H. D., Honorato, D. F., Fagundes, J. J., Góes, J. R. N., Coy, C. S. R. andWu, F. C. (2007). Metodologia de mapeamento de laudos médicos para bases de dados:aplicação em laudos colonoscópicos, Anais do II Congresso da Academia Trinacional deCiências, Foz do Iguaçu, pp. 1–9.

Cherman, E. A., Spolaôr, N., Lee, H. D., Costa, L. H. D., Fagundes, J. J., Coy, C. S. R. andWu, F. C. (2008). Metodologia de mapeamento computacional de informações médicas:aplicação em laudos de coloscopia e manometria anorretal, 57o Congresso Brasileiro deColoproctologia, Vol. 28, Revista Brasileira de Coloproctologia, pp. 42–42.

Cherman, E. A., Spolaôr, N., Lee, H. D., Honorato, D. F., Coy, C. S. R., Fagundes, J. J. and Wu,F. C. (2008). Um estudo do mapeamento de laudos médicos de endoscopia digestiva altae colonoscopia para aquisição de conhecimento, Anais do VII Workshop de InformáticaMédica, Belém, pp. 1–10.

Cherman, E. A., Spolaôr, N., Lee, H. D. and Wu, F. C. (2008). Mapeamento automático delaudos médicos para extração de conhecimento, Anais do VIII Safety, Health and Environ-mental World Congress, Rio de Janeiro, pp. 1–1.

Chrupala, G. (2006). Simple Data-Driven Context-Sensitive Lemmatization, Procesamiento delLenguaje Natural 37(0): 121–127.

Chute, C. B. (2005). Medical concept representation, in H. Chen, S. S. Fuller, C. Friedmanand W. Hersh (eds), Medical Informatics: knowledge management and Data Mining inbiomedicine, Springer, New York, pp. 165–182.

Corcho, O. and Gómez-Pérez, A. (2000). A roadmap to ontology specification languages, InProceedings of the 12th European Workshop on Knowledge Acquisition, Modeling andManagement, New York, pp. 80–96.

Cordeiro, F. (1994). Endoscopia Digestiva, Editora Média e Científica, Rio de Janeiro.

Costa, L. H. D., Ferrero, C. A., Lee, H. D., Coy, C. S. R., Fagundes, J. J. and Chung, W. F.(2009). Construção de uma ontologia para auxiliar no mapeamento de laudos médicosde endoscopia digestiva alta para bases de dados estruturadas, Anais do IV Congresso daAcademia Trinacional de Ciências, Foz do Iguaçu, pp. 1–9.

Costa, L. H. D., Ferrero, C. A., Lee, H. D., Coy, C. S. R., Fagundes, J. J. and Chung, W. F.(2010). Mapeamento de laudos médicos de endoscopia digestiva alta apoiados por onto-logias, Anais do X Workshop de Informática Médica, Belo Horizonte, pp. 1–10.

Cotran, R. S., Kumar, V. and Collins, T. (1996). Patologia Estrutural e Funcional, GuanabaraKoogan, Rio de Janeiro.

Crockford, D. (2008). JavaScript: The Good Parts, O’Reilly Media, Sebastopol.

Deitel, H. M. (2012). Xml: como programar, Bookman, Porto Alegre.

135

Deitel, H. M. and Deitel, P. D. (2010). Java: como programar, Pearson, São Paulo.

Farquhar, A., Fikes, R. and Rice, J. (1997). The ontolingua server: a tool for collaborative on-tology construction, International Journal of Human-Computer Studies 46(6): 707–727.

Ferguson, R. and Heilmann, C. (2013). Beginning JavaScript with DOM Scripting and Ajax,Apress, Berkely.

Filho, W. P. P. (2009). Engenharia de Software: fundamentos, métodos e padrões, LTC, Rio deJaneiro.

Flanagan, D. (2006). JavaScript: the definitive guide, O’Reilly Media, Sebastopol.

Fox, M., Barbuceanu, M., Gruninger, M. and Lin, J. (1998). An organizational ontology forenterprise modeling, in M. Prietula, K. Carley and L. Gasser (eds), Simulating Organiza-tions: computational models of institutions and groups, AAAI/MIT Press, Menlo Park,pp. 131–152.

França, P. C. (2009). Conceitos, classes e/ou universais: com o que é que se constrói umaontologia?, Linguamatica 1(1): 105–121.

Friedl, J. E. F. (2006). Mastering Regular Expressions, O’Reilly Media, Sebastopol.

Fuller, M. and Zobel, J. (1998). Conflation-based comparison of stemming algorithms, In Pro-ceedings of the Third Australian Document Computing Simposium, Sydney, pp. 8–13.

Garcia, A. C. B. and Sichman, J. S. (2003). Agentes e sistemas multiagentes, in S. Rezende(ed.), Sistemas Inteligentes: fundamentos e aplicações, Editora Manole, Barueri, pp. 269–306.

Genesereth, M., Fikes, R. E., Brachman, R., Gruber, T., Hayes, P., Letsinger, R., Lifschitz,V., Macgregor, R., Mccarthy, J., Norvig, P. and Patil, R. (1992). Knowledge interchangeformat version 3.0 reference manual, Technical report, Stanford University, Stanford.Disponível em: citeseer.ist.psu.edu/genesereth92knowledge.html

Gennari, J. H., Musen, M. A., Fergerson, R. W., Grosso, W. E., Crubzy, M., Eriksson, H., Noy,N. F. and Tu, S. W. (2003). The evolution of protégé: an environment for knowledge-basedsystems development, International Journal of Human-Computer Studies 58(1): 89–123.

Goodman, D. and Morrison, M. (2007). JavaScript Bible, Wiley, John & Sons, Incorporated.

Gosling, J., Joy, B., Steele, G. and Bracha, G. (2005). Java (TM) Language Specification,Addison-Wesley, Boston.

Griffiths, D. (2009). Head First Rails: a learner’s companion to Ruby on Rails, O’Reilly Media,Sebastopol.

Gruber, T. (2009). Ontology, in L. Liu and M. T. Özsu (eds), Encyclopedia of Database Systems,Springer, New York, pp. 1963–1965.

Gruber, T. R. (1992). Ontolingua: a mechanism to support portable ontologies, Technical report,Stanford University, Stanford.Disponível em: ftp://ksl.stanford.edu/pub/KSL_Reports/KSL-91-66.ps.gz

136

Guarino, N. (1997). Semantic matching: Formal ontological distinctions for information or-ganization, extraction, and integration, in M. T. Pazienza (ed.), Information Extraction: amultidisciplinary approach to an emerging information technology, international summerschool, SCIE-97, Springer, New York, pp. 139–170.

Guarino, N. and Giaretta, P. (1995). Ontologies and knowledge bases: towards a terminologicalclarification, in N. J. I. Mars (ed.), Towards Very Large Knowledge Bases: knowledgebuilding and knowledge sharing, IOS Press, Washington, pp. 25–32.

Han, J. (2005). Data Mining: concepts and techniques, Morgan Kaufmann Publishers, SanFrancisco.

Harold, E. R. (1998). XML: Extensible Markup Language, IDG Books Worldwide, Foster City.

Harper, D. (2010). Online Etymonology Dictionary, Disponível em:http://www.etymonline.com/index.php?allowed_in_frame0&searchontology. Acessoem: 21 de jan. 2014.

Hendler, J. and D. L. McGuinness, D. L. (2000). The DARPA Agent Markup Language, IEEEIntelligent Systems 15(6): 67–73.

Húngaro, L. (2013). Princípios do Rails, Disponível em:http://lucashungaro.wordpress.com/2007/11/03/principios-do-rails/. Acesso em: 27de jan. 2014.

Holzner, S. (2006). Beginning Ruby on Rails, Wiley, John & Sons, Incorporated, Chatham.

Honorato, D. F., Cherman, E. A., Lee, H. D., Monard, M. C. and Chung, W. F. (2008). Construc-tion of an attribute-value representation for semi-structured medical findings knowledgeextraction, CLEI Electronic Journal 11(2): 1–12.

Honorato, D. F., Cherman, E. A., Lee, H. D., Monard, M. C. and Wu, F. C. (2007). Cons-trução de uma representação atributo-valor para extração de conhecimento a partir deinformações semi-estruturadas de laudos médicos, Anais do XXXIII Conferência Latino-Americana de Informática, San José, pp. 1–12.

Honorato, D. F., Cherman, E. A., Lee, H. D., Wu, F. C. and Monard, M. C. (2007). Descriçãodo projeto da metodologia de mapeamento de informações semi-estruturadas em uma re-presentação atributo-valor, Technical report, Universidade de São Paulo, São Carlos.Disponível em: http://www.icmc.usp.br/ biblio/BIBLIOTECA/reltec/rt309.pdf

Horrocks, I. (2002). Daml+oil: a reason-able web ontology language, In Proceedings of the 8thInternational Conference on Extending Database Technology (EDBT), Praga, pp. 2–13.

Horrocks, I., Fensel, D., Broekstra, J., Decker, S., Erdmann, M., Goble, C., van Harlemen,F., Klein, M., Staab, S., Studer, R., Motta, E. and Horrocks, I. (2000). The ontologyinference layer oil, Technical report, Free University of Amsterdam, Amsterdam.Disponível em: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.22.2713&rep=rep1&type=pdf

Horrocks, I., Goble, C. and Stevens, R. (2001). Oiled: a reason-able ontology editor for thesemantic web, In Proceedings of the Joint German/Austrian Conference on Artificial In-telligence, Lecture Notes in Artificial Intelligence, New York, pp. 396–408.

137

Hull, D. A. (1996). Stemming algorithms – a case study for detailed evaluation, Journal of theAmerican Society for Information Science 47(1): 70–84.

Humpheys, B. L., Lindberg, D. A. B., Schoolman, H. M. and Barnett, G. O. (1998). The unifiedmedical language system: An informatics research collaboration, Journal of the AmericanMedical Informatics Association 1(5): 1–11.

Intentor (2010). Pequeno Guia de Expressões Regulares, Disponível em:http://intentor.com.br/pequeno-guia-regex/. Acesso em: 25 de nov. 2013.

Jongejan, B. and Dalianis, H. (2009). Automatic training of lemmatization rules that handlemorphological changes in pre-, in- and suffixes alike, In Proceedings of the Joint Confe-rence of the 47th Annual Meeting of the ACL and the 4th International Joint Conferenceon Natural Language Processing of the AFNLP, Suntec, pp. 145–153.

Jung, W. (2012). Aplicação de princípios de qualidade de dados durante o desenvolvimentode um sistema computacional médico para a cirurgia coloproctológica, Dissertação demestrado, Universidade Estadual do Oeste do Paraná, Foz do Iguaçu.

Juršic, M., Mozetic, I. and Lavrac, N. (2007). Learning Ripple Down Rules for Efficient Lem-matization, In Proceedings of the 10th International Multiconference Information Society,Ljubljana, pp. 206–209.

Kanis, J. and Skorkovská, L. (2010). Comparison of different lemmatization approaches th-rough the means of information retrieval performance, Lecture Notes in Artificial Intelli-gence 6231: 93–100.

Klyne, G., Carroll, J. J. and McBride, B. (2014). RDF 1.1: concepts and abstract syntax,Disponível em: http://www.w3.org/TR/rdf11-concepts/. Acesso em: 23 de mai. 2014.

Knublauch, H., Fergerson, R. W., Noy, N. F. and Musen, M. A. (2004). The protégé owl plugin:An open development environment for semantic web applications, in S. A. McIlraith,D. Plexousakis and F. van Harmelen (eds), The Semantic Web – ISWC 2004, SpringerBerlin, Berlin, pp. 229–243.

Korenius, T., Laurikkala, J., Järvelin, K. and Juhola, M. (2004). Stemming and lemmatizationin the clustering of finnish text documents, In Proceedings of the Thirteenth ACM Interna-tional Conference on Information and Knowledge Management, New York, pp. 625–633.

Kutler, C. and Leonard, B. (2008). NetBeans Ruby and Rails IDE with JRuby, Apress, Berkely.

Larsen, R. (2013). Beginning HTML and CSS, Wrox Press, Birmingham.

Laudon, K. C. and Laudon, J. P. (2007). Sistemas de Informação Gerenciais, Pearson, SãoPaulo.

Lawson, B. and Sharp, R. (2011). Introdução ao HTML5, Alta Books, Rio de Janeiro.

Lee, H. D., Monard, M. C., Honorato, D. F., Lorena, A. C., Ferrero, C. A., Maletzke, A. G.,Zalewski, W., Coy, C. S. R., Fagundes, J. J. and Chung, W. F. (2011). Mapping uns-tructured data in digital and printed documents into attribute-value tables, in R. A. E.Andrade, J. M. Gómez and A. R. Valdés (eds), Towards a Trans-disciplinary Technologyfor Business Intelligence, Gathering Knowledge Discovery, Knowledge Management andDecision Making, Shaker Verlag, Maastricht, pp. 198–209.

138

Lee, H. D., Oliva, J. T., Maletzke, A. G., Machado, R. B., Voltolini, R. F., Coy, C. S. R.,Fagundes, J. J. and Wu, F. C. (2013). Sistema computacional para automatização doprocesso de mapeamento de laudos médicos por ontologias, 62o Congresso Brasileiro deColoproctologia, São Paulo, pp. 1–24.

Lewis, W. E. (2008). Software Testing and Continuous Quality Improvement, Auerbach Publi-cations, Boston.

Lie, H. W. and Bos, B. (2005). Cascading Style Sheets: designing for the Web, Addison-Wesley,Boston.

Lindholm, T., Yellin, F., Bracha, G. and Buckley, A. (2013). Java Virtual Machine Specification,Addison-Wesley, Boston.

Liu, H., Christiansen, T., Jr., W. A. B. and Verspoor, K. (2012). Biolemmatizer: a lemmatizationtool for morphological processing of biomedical text, J. Biomedical Semantics 3(1): 3.

Lubbers, P., Albers, B. and Dalim, F. (2013). Programação Profissional em HTML5, AltaBooks, Rio de Janeiro.

Makrehchi, M. and Kamel, M. S. (2008). Automatic extraction of domain-specific stopwordsfrom labeled documents, In Proceedings of the IR Research, 30th European conference onAdvances in Information Retrieval, Berlim, pp. 222–233.

McGuinness, D., Fikes, R., S., J. R. and Wilder (2000). The chimaera ontology environment, InProceedings of the Seventeenth National Conference on Artificial Intelligence and TwelfthConference on Innovative Applications of Artificial Intelligence, Austin, pp. 1123–1124.

McGuinness, D. L. and van Harmelen, F. (2004). OWL Web Ontology Language Overview,Disponível em: http://www.w3.org/TR/owl-features/. Acesso em: 27 de jan. 2014.

Metz, S. (2012). Practical Object-Oriented Design in Ruby: an agile primer, Addison-Wesley,Boston.

Meyer, E. A. (2009). Cascading Style Sheets – the definitive guide: visual styles for HTML,O’Reilly Media, Sebastopol.

Michaelis (2009). Dicionário de Português Online, Disponível em:http://michaelis.uol.com.br/moderno/portugues/index.php?lingua=portugues-portuguespalavra=morfema. Acesso em: 24 de set. 2013.

Miles, R. and Hamilton, K. (2006). Learning UML 2.0, O’Reilly Media, Sebastopol.

Minsk, M. (1985). A framework for representing knowledge, in R. J. Brachman and H. J.Levesque (eds), Readings in Knowledge Representation, Kaufmann, Los Altos, pp. 245–262.

Myers, G. J., Badgett, T., Sandler, C. and Thomas, T. M. (2004). The Art of Software Testing,Wiley, New Jersey.

NetBeans (2013). A Brief History of NetBeans, Disponível em:http://netbeans.org/about/history.html. Acesso em: 20 de nov. 2013.

139

Nunes, F. V. (2007). Verbal lemmatization and featurization of portuguese with ambiguityresolution in context, Dissertação de mestrado, Universidade de Lisboa, Lisboa.

Nutter, C. O., Enebo, T., Sieger, N., Bini, O. and Dees, I. (2011). Using JRuby: bringing Rubyto Java, Pragmatic Bookshelf, Raleigh.

Orengo, V. M. and Huyck, C. (2001). A stemming algorithm for portuguese language, InProceedings of the Eighth Symposium on String Processing and Information Retrieval,Laguna de San Rafael, pp. 186–193.

Pfleeger, S. L. (2004). Engenharia de Software: teoria e prática, Prentice Hall, São Paulo.

Pilgrim, M. (2011). HTML 5 – entendendo e executando, Alta Books, Rio de Janeiro.

Plisson, J., Lavrac, N., Mladenic, D. and Erjavec, T. (2008). Ripple down rule learning forautomated word lemmatisation, AI Communications 21(1): 15–26.

Porter, M. F. (1997). Readings in information retrieval, Morgan Kaufmann Publishers, SanFrancisco, chapter An Algorithm for Suffix Stripping, pp. 313–316.

Pressman, R. (ed.) (2011). Engenharia de Software: uma abordagem profissional, MakronBooks, São Paulo.

Rezende, S. (ed.) (2003). Sistemas Inteligentes: fundamentos e aplicações, Editora ManoleMa-nole, Barueri.

Ruby, S., Thomas, D., Hansson, D. H., Breedt, L., Clark, M., Davidson, J. D., Gehtland, J. andSchwarz, A. (2011). Agile Web Development with Rails, Pragmatic Bookshelf, Raleigh.

Saint-Laurent, S., Dumbill, E. and Gruber, E. J. (2012). Learning Rails 3, O’Reilly Media,Sebastopol.

Schwartz, R. L., Phoenix, T. and D’Foy, B. (20011). Learning Perl, O’Reilly Media, Sebastopol.

Silva, W. (2005). Netbeans 4.1: primeiros passos, Disponível em:http://www.aprendajavafacil.com.br/portal/netbeans_guj.pdf. Acesso em: 21 denov. 2013.

Sklar, J. (2001). Designing Web Pages with Cascading Style Sheets, Course Technology Press,Boston.

Smith, M. K., Welty, C. and McGuinness, D. (2004). OWL Web Ontology Language Guide,Disponível em: http://www.w3.org/TR/owl-guide/. Acesso em: 27 de jan. 2014.

Sommerville, I. (2009). Engenharia de Software, Pearson Brasil, São Paulo.

Spolaôr, N., Lee, H. D., Cherman, E. A., Honorato, D. F., Fagundes, J. J., Góes, J. R. N., Coy, C.S. R. and Chung, W. F. (2007). Um estudo de caso do mapeamento de laudos endoscópicospara bases de dados, Anais do II Congresso da Academia Trinacional de Ciências, Foz doIguaçu, pp. 1–10.

Tsui, F. and Karam, O. (2013). Fundamentos de Engenharia de Software, LTC, Rio de Janeiro.

Uschold, M. and Gruninger, M. (1996). Ontologies: principles, methods and applications,Knowledge Engineering Review 11(2): 93–155.

140

van Harmelen, F. and Horrocks, I. (2000). Questions and answers on oil: the ontology inferencelayer for the semantic web, Disponível em: http://web.squ.edu.om/med-Lib/med/net/e-pathways-net/Docs/OIL%20FAQ.htm. Acesso em: 13 de mar. 2014.

van Kesteren, A., Gregor, A., Russel, A. and Berjor, R. (2014). W3c dom4, Disponível em:http://www.w3.org/TR/dom/. Acesso em: 23 de mai. 2014.

Wainwright, P. C., Cozens, S., Calpini, A., Corliss, A. and Merelo-Guervos, J. J. (2001). Pro-fessional Perl Programming, Wrox Press, Birmingham.

Wall, L., Christiansen, T. and Schwartz, R. L. (2012). Programming Perl, O’Reilly Media,Sebastopol.

Wiederhold, G. and Shortliffe, E. H. (2006). System design and engineering in health care,in E. H. Shortliffe and J. J. Cimino (eds), Biomedical Informatics, Springer, New York,pp. 233–264.

Witten, I. H. and Frank, E. (2005). Data Mining: practical machine learning tools and techni-ques, Morgan Kaufmann Publishers, San Francisco.

Wu, F. C., Coy, C. S. R., Lee, H. D., Fagundes, J. J., Ferrero, C. A., Machado, R. B., Maletzke,A. G., Zalewski, W., Leal, R. F., Ayrizono, M. L. S. and Costa, L. H. D. (2010). Mé-todo de mapeamento de documentos textuais para bases de dados estruturadas utilizandoontologias - protocol. 01810036941 inpi.

Ziviani, N. (2010). Projeto de Algoritmos: com implementações em Pascal e C, Thomson.

Apêndice A

Arquivos Definidos para a AvaliaçãoExperimental do Estudo de Caso

A.1 Stoplist

1 <?xml version="1.0" encoding="UTF−8" standalone="no"?>

2 <stopwords number="59">3 <stopword>$</stopword>4 <stopword>$</stopword>5 <stopword>,</stopword>6 <stopword>−</stopword>7 <stopword>\?</stopword>8 <stopword>a</stopword>9 <stopword>alimentares</stopword>

10 <stopword>ao</stopword>11 <stopword>aparelho</stopword>12 <stopword>aproximadamente</stopword>13 <stopword>area</stopword>14 <stopword>as</stopword>15 <stopword>aspecto</stopword>16 <stopword>ate</stopword>17 <stopword>com</stopword>18 <stopword>conseguida</stopword>19 <stopword>cor</stopword>20 <stopword>da</stopword>21 <stopword>de</stopword>22 <stopword>depois</stopword>23 <stopword>desde</stopword>24 <stopword>dificuldade</stopword>

141

142

25 <stopword>do</stopword>26 <stopword>dos</stopword>27 <stopword>e</stopword>28 <stopword>elevada</stopword>29 <stopword>elevado</stopword>30 <stopword>em</stopword>31 <stopword>esparsos</stopword>32 <stopword>especificas</stopword>33 <stopword>espessada</stopword>34 <stopword>fibrina</stopword>35 <stopword>friavel</stopword>36 <stopword>grande</stopword>37 <stopword>o</stopword>38 <stopword>observa−se</stopword>39 <stopword>observado</stopword>40 <stopword>ocupando</stopword>41 <stopword>partir</stopword>42 <stopword>passagem</stopword>43 <stopword>peptica</stopword>44 <stopword>pequena</stopword>45 <stopword>pequenas</stopword>46 <stopword>presente</stopword>47 <stopword>presneca</stopword>48 <stopword>progressao</stopword>49 <stopword>quantidade</stopword>50 <stopword>realizada</stopword>51 <stopword>regiao</stopword>52 <stopword>residuo</stopword>53 <stopword>residuos</stopword>54 <stopword>se</stopword>55 <stopword>situada</stopword>56 <stopword>situado</stopword>57 <stopword>sua</stopword>58 <stopword>suas</stopword>59 <stopword>tambem</stopword>60 <stopword>tipo</stopword>61 <stopword>uma</stopword>62 </stopwords>

143

A.2 Arquivo de Padronização

1 <?xml version="1.0" encoding="UTF−8" standalone="no"?>

2 <pattern number="81">3 <synonym n="12">4 <old>normal toda extensao</old>5 <new>esofago_superior normal</new>6 <new>terco_proximal presenca_edema nao</new>7 <new>terco_proximal presenca_erosao nao</new>8 <new>terco_proximal presenca_ulcera nao</new>9 <new>esofago_medio normal</new>

10 <new>terco_medio presenca_edema nao</new>11 <new>terco_medio presenca_erosao nao</new>12 <new>terco_medio presenca_ulcera nao</new>13 <new>esofago_inferior normal</new>14 <new>terco_distal presenca_edema nao</new>15 <new>terco_distal presenca_erosao nao</new>16 <new>terco_distal presenca_ulcera nao</new>17 </synonym>18 <synonym n="2">19 <old>calibre distensibilidade normal</old>20 <new>esofago calibre normal</new>21 <new>esofago distensibilidade normal</new>22 </synonym>23 <synonym n="1">24 <old>teg nivel pincamento diafragmatico</old>25 <new>teg normal</new>26 </synonym>27 <synonym n="1">28 <old>teg\s∗proximo\s∗pincamento\s∗diafragmatico</old>29 <new>teg normal</new>30 </synonym>31 <synonym n="1">32 <old>teg.∗0[,.]5\s∗cm\s∗[acima]∗\s∗pincamento\s∗diafragmatico</old>33 <new>teg normal</new>34 </synonym>35 <synonym n="1">36 <old>teg.∗1[,.]0\s∗cm\s∗[acima]∗\s∗pincamento\s∗diafragmatico</old>37 <new>teg gi</new>

144

38 </synonym>39 <synonym n="1">40 <old>teg.∗1[,.]5\s∗cm\s∗[acima]∗\s∗pincamento\s∗diafragmatico</old>41 <new>teg gi</new>42 </synonym>43 <synonym n="1">44 <old>teg.∗2[,.]0\s∗c(m)∗\s∗[acima]∗\s∗pi(n)∗camento\s∗diafragmatico</old

>45 <new>teg gi</new>46 </synonym>47 <synonym n="1">48 <old>teg.∗2[,.]5\s∗cm\s∗[acima]∗\s∗pincamento\s∗diafragmatico</old>49 <new>teg gi</new>50 </synonym>51 <synonym n="1">52 <old>teg.∗3[,.]0\s∗cm\s∗[acima]∗\s∗pincamento\s∗diafragmatico</old>53 <new>teg gii</new>54 </synonym>55 <synonym n="1">56 <old>teg.∗3[,.]5\s∗cm\s∗[acima]∗\s∗pincamento\s∗diafragmatico</old>57 <new>teg gii</new>58 </synonym>59 <synonym n="1">60 <old>teg.∗4[,.]0\s∗cm\s∗[acima]∗\s∗pincamento\s∗diafragmatico</old>61 <new>teg gii</new>62 </synonym>63 <synonym n="1">64 <old>teg.∗4[,.]5\s∗cm\s∗[acima]∗\s∗pincamento\s∗diafragmatico</old>65 <new>teg giii</new>66 </synonym>67 <synonym n="1">68 <old>teg.∗5[,.]0\s∗cm\s∗[acima]∗\s∗pincamento\s∗diafragmatico</old>69 <new>teg giii</new>70 </synonym>71 <synonym n="1">72 <old>teg.∗5[,.]5\s∗cm\s∗[acima]∗\s∗pincamento\s∗diafragmatico</old>73 <new>teg giii</new>74 </synonym>75 <synonym n="1">

145

76 <old>teg.∗6[,.]0\s∗cm\s∗[acima]∗\s∗pincamento\s∗diafragmatico</old>77 <new>teg giii</new>78 </synonym>79 <synonym n="1">80 <old>(presenca\s∗)∗ponto[s]∗\s∗(placa[s]∗\s∗)∗esbranquicado[s]∗</old>81 <new>anormal</new>82 </synonym>83 <synonym n="1">84 <old>(presenca\s∗)∗placa[s]∗\s∗(ponto[s]∗\s∗)∗esbranquicado[s]∗</old>85 <new>anormal</new>86 </synonym>87 <synonym n="1">88 <old>tipo\s∗gastrico</old>89 <new>anormal</new>90 </synonym>91 <synonym n="1">92 <old>enantema</old>93 <new>presenca_edema sim</new>94 </synonym>95 <synonym n="1">96 <old>proximo\s∗teg</old>97 <new>terco_distal</new>98 </synonym>99 <synonym n="1">

100 <old>(presenca\s∗)∗polipo(\s∗\d∗mm)</old>101 <new>anormal</new>102 </synonym>103 <synonym n="1">104 <old>(presenca\s∗)∗cord[o]∗ao\s∗va[r]∗icoso[s]∗</old>105 <new>anormal</new>106 </synonym>107 <synonym n="1">108 <old>fibrino</old>109 <new>anormal</new>110 </synonym>111 <synonym n="1">112 <old>(coloracao\s∗)∗esbranquicado</old>113 <new>anormal</new>114 </synonym>

146

115 <synonym n="1">116 <old>16\s∗cm\s∗[da]∗\s∗ad[s]∗</old>117 <new>terco_proximal</new>118 </synonym>119 <synonym n="1">120 <old>17\s∗cm\s∗[da]∗\s∗ad[s]∗</old>121 <new>terco_proximal</new>122 </synonym>123 <synonym n="1">124 <old>18\s∗cm\s∗[da]∗\s∗ad[s]∗</old>125 <new>terco_proximal</new>126 </synonym>127 <synonym n="1">128 <old>19\s∗cm\s∗[da]∗\s∗ad[s]∗</old>129 <new>terco_proximal</new>130 </synonym>131 <synonym n="1">132 <old>20\s∗cm\s∗[da]∗\s∗ad[s]∗</old>133 <new>terco_proximal</new>134 </synonym>135 <synonym n="1">136 <old>21\s∗cm\s∗[da]∗\s∗ad[s]∗</old>137 <new>terco_proximal</new>138 </synonym>139 <synonym n="1">140 <old>22\s∗cm\s∗[da]∗\s∗ad[s]∗</old>141 <new>terco_proximal</new>142 </synonym>143 <synonym n="1">144 <old>23\s∗cm\s∗[da]∗\s∗ad[s]∗</old>145 <new>terco_medio</new>146 </synonym>147 <synonym n="1">148 <old>24\s∗cm\s∗[da]∗\s∗ad[s]∗</old>149 <new>terco_medio</new>150 </synonym>151 <synonym n="1">152 <old>25\s∗cm\s∗[da]∗\s∗ad[s]∗</old>153 <new>terco_medio</new>

147

154 </synonym>155 <synonym n="1">156 <old>26\s∗cm\s∗[da]∗\s∗ad[s]∗</old>157 <new>terco_medio</new>158 </synonym>159 <synonym n="1">160 <old>27\s∗cm\s∗[da]∗\s∗ad[s]∗</old>161 <new>terco_medio</new>162 </synonym>163 <synonym n="1">164 <old>28\s∗cm\s∗[da]∗\s∗ad[s]∗</old>165 <new>terco_medio</new>166 </synonym>167 <synonym n="1">168 <old>29\s∗cm\s∗[da]∗\s∗ad[s]∗</old>169 <new>terco_medio</new>170 </synonym>171 <synonym n="1">172 <old>30\s∗cm\s∗[da]∗\s∗ad[s]∗</old>173 <new>terco_distal</new>174 </synonym>175 <synonym n="1">176 <old>31\s∗cm\s∗[da]∗\s∗ad[s]∗</old>177 <new>terco_distal</new>178 </synonym>179 <synonym n="1">180 <old>32\s∗cm\s∗[da]∗\s∗ad[s]∗</old>181 <new>terco_distal</new>182 </synonym>183 <synonym n="1">184 <old>33\s∗cm\s∗[da]∗\s∗ad[s]∗</old>185 <new>terco_distal</new>186 </synonym>187 <synonym n="1">188 <old>34\s∗cm\s∗[da]∗\s∗ad[s]∗</old>189 <new>terco_distal</new>190 </synonym>191 <synonym n="1">192 <old>35\s∗cm\s∗[da]∗\s∗ad[s]∗</old>

148

193 <new>terco_distal</new>194 </synonym>195 <synonym n="1">196 <old>36\s∗cm\s∗[da]∗\s∗ad[s]∗</old>197 <new>terco_distal</new>198 </synonym>199 <synonym n="1">200 <old>37\s∗cm\s∗[da]∗\s∗ad[s]∗</old>201 <new>terco_distal</new>202 </synonym>203 <synonym n="1">204 <old>38\s∗cm\s∗[da]∗\s∗ad[s]∗</old>205 <new>terco_distal</new>206 </synonym>207 <synonym n="1">208 <old>39\s∗cm\s∗[da]∗\s∗ad[s]∗</old>209 <new>terco_distal</new>210 </synonym>211 <synonym n="1">212 <old>40\s∗cm\s∗[da]∗\s∗ad[s]∗</old>213 <new>terco_distal</new>214 </synonym>215 <synonym n="1">216 <old>area\s∗esbranquicado</old>217 <new>anormal</new>218 </synonym>219 <synonym n="1">220 <old>calibre\s∗aumentado</old>221 <new>calibre anormal</new>222 </synonym>223 <synonym n="1">224 <old>fino\s∗calibre</old>225 <new>calibre anormal</new>226 </synonym>227 <synonym n="1">228 <old>1/3 superior</old>229 <new>terco_superior</new>230 </synonym>231 <synonym n="1">

149

232 <old>hiperemia</old>233 <new>anormal</new>234 </synonym>235 <synonym n="3">236 <old>toda extensao anormal</old>237 <new>esofago_superior anormal</new>238 <new>esofago_medio anormal</new>239 <new>esofago_inferior anormal</new>240 </synonym>241 <synonym n="1">242 <old>(mucoso\s∗)∗terco\s∗distal</old>243 <new>terco_distal</new>244 </synonym>245 <synonym n="1">246 <old>(presenca\s∗)∗erosao</old>247 <new>presenca_erosao sim</new>248 </synonym>249 <synonym n="1">250 <old>(lesao\s∗)∗ulcerado(\s∗lesao)∗</old>251 <new>presenca_ulcera sim</new>252 </synonym>253 <synonym n="1">254 <old>(mucoso\s∗)∗terco\s∗medio</old>255 <new>terco_medio</new>256 </synonym>257 <synonym n="1">258 <old>presenca\s∗ulcera</old>259 <new>presenca_ulcera sim</new>260 </synonym>261 <synonym n="1">262 <old>edematoso</old>263 <new>presenca_edema sim</new>264 </synonym>265 <synonym n="1">266 <old>estenose</old>267 <new>anormal</new>268 </synonym>269 <synonym n="1">270 <old>(mucoso∗\s∗)∗terco\s∗proximal</old>

150

271 <new>terco_proximal</new>272 </synonym>273 <synonym n="1">274 <old>terco(\s|_)∗superior</old>275 <new>esofago_superior</new>276 </synonym>277 <synonym n="3">278 <old>nao presenca lesao</old>279 <new>esofago_inferior normal</new>280 <new>esofago_medio normal</new>281 <new>esofago_superior normal</new>282 </synonym>283 <synonym n="1">284 <old>nao\s∗confluente</old>285 <new>nao_confluente</new>286 </synonym>287 <synonym n="2">288 <old>terco(\s|_)∗medio\s∗((presenca erosao)|(presenca_erosao sim))\s∗(

terco_distal|(32 cm ad))\s∗(anormal|estenose)</old>289 <new>terco_medio presenca_erosao sim</new>290 <new>esofago_inferior anormal</new>291 </synonym>292 <synonym n="2">293 <old>terco(\s|_)∗proximal\s∗(anormal|(presenca cordao varicoso))\s∗medio\

s∗grosso\s∗calibre</old>294 <new>esofago_superior anormal</new>295 <new>esofago calibre anormal</new>296 </synonym>297 <synonym n="2">298 <old>terco(\s|_)∗medio\s∗((presenca\s∗cordao\s∗varicoso)|anormal)\s∗

medio\s∗calibre</old>299 <new>esofago_medio anormal</new>300 <new>esofago calibre normal</new>301 </synonym>302 <synonym n="1">303 <old>terco(\s|_)∗distal\s∗(mucos(a|o)∗)∗\s∗(esbranquicado|anormal)</old>304 <new>esofago_inferior anormal</new>305 </synonym>306 <synonym n="1">

151

307 <old>((proximo\s∗teg\s∗)|terco_distal\s∗)pincamento\s∗diafragmatico\s∗ (((presenca\s∗)∗polipo(\s∗\d∗mm))|\s∗anormal)</old>

308 <new>esofago_inferior anormal</new>309 </synonym>310 <synonym n="2">311 <old>teg\s∗((40\s∗cm\s∗ad\s∗)|terco_distal\s∗) proximo\s∗pincamento\s∗

diafragmatico\s∗(presenca_erosao|erosao)</old>312 <new>teg normal</new>313 <new>terco_distal presenca_erosao sim</new>314 </synonym>315 <synonym n="2">316 <old>presenca(\s∗|_)ulcera\s∗(sim\s∗)∗ ((30\s∗cm\s∗ad\s∗)|terco_distal\s∗) (

presenca)∗(\s∗|_)erosao\s∗</old>317 <new>terco_distal presenca_ulcera sim</new>318 <new>terco_distal presenca_erosao sim</new>319 </synonym>320 <synonym n="2">321 <old>terco(\s|_)∗medio\s∗azul\s∗medio\s∗calibre</old>322 <new>esofago_medio anormal</new>323 <new>esofago calibre normal</new>324 </synonym>325 <synonym n="2">326 <old>medio\s∗calibre\s∗alzul\s∗sinal\s∗vermelho∗\s∗ausente\s∗terco(\s|_)∗

medio</old>327 <new>esofago calibre normal</new>328 <new>esofago_inferior anormal</new>329 </synonym>330 <synonym n="1">331 <old>^motilidade</old>332 <new>esofago motilidade</new>333 </synonym>334 <synonym n="2">335 <old>terco(\s|_)∗medio\s∗presenca(\s|_)∗erosao\s∗(sim\s∗)∗(32\s∗cm\s∗ad|

terco_distal|esofago_inferior)\s∗(estenose|anormal)</old>336 <new>terco_medio presenca_erosao sim</new>337 <new>esofago_inferior anormal</new>338 </synonym>339 <synonym n="2">

152

340 <old>((terco(\s|_)∗distal)|esofago_inferior)\s∗((coloracao\s∗esbranquicado\s∗)|anormal\s∗)presenca(\s|_)∗erosao</old>

341 <new>esofago_inferior anormal</new>342 <new>terco_distal presenca_erosao sim</new>343 </synonym>344 <synonym n="2">345 <old>((terco(\s|_)∗distal)|esofago_inferior)\s∗((coloracao\s∗esbranquicado\s

∗)|anormal\s∗)(presenca_edema|edematosa)</old>346 <new>esofago_inferior anormal</new>347 <new>terco_distal presenca_edema sim</new>348 </synonym>349 <synonym n="3">350 <old>terco(\s|_)∗distal\s∗presenca(\s|_)∗erosao\s∗(sim\s∗)∗ linear\s∗nao(\s∗|

_)confluente\s∗(esofago_inferior\s∗|terco(\s|_)∗distal\s∗) anormal\s∗calibre\s∗anormal</old>

351 <new>terco_distal presenca_erosao sim</new>352 <new>esofago_inferior anormal</new>353 <new>esofago calibre anormal</new>354 </synonym>355 </pattern>

AUTOMATIZAÇÃO DO PROCESSO DE MAPEAMENTO DE...

Documents

Transcript of AUTOMATIZAÇÃO DO PROCESSO DE MAPEAMENTO DE...