UNIVERSIDADE ESTADUAL DO OESTE DO PARANÁ
CAMPUS DE FOZ DO IGUAÇU
PROGRAMA DE PÓS-GRADUAÇÃO EM
ENGENHARIA DE SISTEMAS DINÂMICOS E ENERGÉTICOS
DISSERTAÇÃO DE MESTRADO
AUTOMATIZAÇÃO DO PROCESSO DE MAPEAMENTO
DE LAUDOS MÉDICOS PARA UMA REPRESENTAÇÃO
ESTRUTURADA
JEFFERSON TALES OLIVA
FOZ DO IGUAÇU
2014
Jefferson Tales Oliva
Automatização do Processo de Mapeamento de Laudos
Médicos para uma Representação Estruturada
Dissertação de Mestrado apresentada ao Programa de
Pós-Graduação em Engenharia de Sistemas Dinâmicos e Energéticos como parte dos requisitos para obtenção do título de Mestre em Engenharia de Sistemas Dinâmicos e Energéticos. Área de concentração:
Sistemas Dinâmicos e Energéticos.
Orientador: Huei Diana Lee
Co-orientador: Wu Feng Chung
Co-orientador: Cláudio Saddy Rodrigues Coy
Foz do Iguaçu
2014
ii
Automatização do Processo de Mapeamento de Laudos
Médicos para uma Representação Estruturada
Jefferson Tales Oliva
Esta Dissertação de Mestrado foi apresentada ao Programa de Pós-Graduação em
Engenharia de Sistemas Dinâmicos e Energéticos e aprovada pela Banca Examinadora:
Data da defesa pública: 28/04/2014.
Profa . Dra . Huei Diana Lee - (Orientador)
Universidade Estadual do Oeste do Paraná - UNIOESTE
Prof. Dr. Wu Feng Chung - (Co-orientador)
Universidade Estadual do Oeste do Paraná - UNIOESTE
Prof. Dr. João Bosco Mangueira Sobral
Universidade Federal de Santa Catarina - UFSC
Prof. Dr. Renato Bobsin Machado
Universidade Estadual do Oeste do Paraná - UNIOESTE
iv
Resumo
Na área da saúde, grandes quantidades de dados provenientes de diversas fontes, como exames
clínicos e de procedimentos, são armazenadas em bases de dados de hospitais e clínicas médicas. As características observadas nesses exames são descritas em laudos médicos textuais.
Esses laudos constituem ferramenta indispensável para profissionais de qualquer especialidade
médica para a manutenção do histórico clínico de pacientes. Os dados contidos nesses laudos
podem ser analisados, de modo mais completo, através de recursos computacionais, como o
processo de Mineração de Dados apoiado por técnicas de Inteligência Computacional. No entanto, para a aplicação desse processo, é imprescindível que os dados estejam representados
em formato estruturado, como as Bases de Dados Computacionais. Nesse sentido, no Laboratório de Bioinformática da Universidade Estadual do Paraná em parceria com o Serviço de
Coloproctologia da Faculdade de Ciências Médicas da Universidade Estadual de Campinas foi
desenvolvido o Processo de Mapeamento de Laudos Médicos (PMLM) por ontologias com o
propósito de prover 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 de instruçõ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 de suas técnicas de processamento de textos em uma ferramenta computacional. Para isso, foi construído
um Sistema Computacional Colaborativo (SCC) utilizando o modelo de desenvolvimento por
prototipagem, que é aplicado de cinco etapas: comunicação; plano rápido; modelagem; construção do protótipo; e avaliação e feedback. Esse sistema computacional foi avaliado em conjunto
com especialistas do domínio, os quais constataram que o SCC atende às especificações determinadas e apresenta-se de grande valia para a extração e o estudo de padrões que podem ser
encontrados em textos médicos. O SCC foi também submetido a uma avaliação experimental, por meio da aplicação do PMLM automatizado em um conjunto de 100 laudos médicos
textuais artificiais que simulam descrições de exames de Endoscopia Digestiva Alta (EDA),
apresentando bons resultados. Desse modo, com o PMLM por ontologias automatizado, implementado no SCC, é possível a realização de estudos mais completos e detalhados, contribuindo
com a geração de novos conhecimentos.
Palavras-chave: Laudo Médico, Ontologia, Engenharia de Software, Endoscopia Digestiva
Alta, Sistema Computacional Colaborativo.
v
Abstract
In the health area, large amounts of data from different sources, such as clinical examinations
and procedures, are stored in hospitals and medical clinics databases. Characteristics observed
in these examinations and procedures are described in textual medical reports. These findings
are indispensable for professionals of any medical specialty, as they are used to maintain the
clinical history of the patients. The data contained in these reports can be analyzed, in a more
complete manner, through the use of computational resources, such as the Data Mining process
supported by computational intelligence techniques. However, for the application of such process, it is essential that the data is represented in a structured format, as Computational Data
Bases. In this sense, the Laboratory of Bioinformatics from the West Paraná State University in
partnership with the Coloproctology Service of the Faculty of Medical Sciences from the State
University of Campinas, developed the Mapping Medical Digital Findings Process (PMLM)
using ontologies with the aim of providing support for the transformation of unstructured textual medical reports into a structured representation. Nevertheless, the techniques employed in
PMLM must be performed manually and separately by means of computer instructions, hampering its use by professionals who are not from the computational area. The objective of this work
is to automate and optimize PMLM using ontologies by integrating 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, fast
plan, modeling, prototype construction, and evaluation and feedback. The developed computational system was evaluated in conjunction with domain experts, confirming that SCC meets
the required specifications and presents a great value for the extraction and the study of patterns
that may be discovered in medical findings. SCC was also evaluated 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
the performance of more complete and detailed studies, contributing to the generation of new
knowledge.
Keywords: Medical Findings, Ontology, Software Engineering, Upper Digestive Endoscopy,
Collaborative Computational 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.
viii
Agradecimentos
Ao longo dessa árdua caminhada, várias pessoas, de alguma forma, fizeram parte desse
trajeto e proporcionaram momentos de alegria, bem como ajudaram a superar os momentos
difíceis e contribuíam com a minha formação pessoal e profissional. Nesse sentido, é difícil eu
expressar por meio de palavras a minha gratidão a essas pessoas que ajudaram diretamente e
indiretamente. Desse modo, a seguir são descritos meus sinceros agradecimentos e reconhecimento 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 profissionais. 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 com
o meu bem estar. Também, por termos compartilhados vários bons momentos juntos. Apesar
de não estar entre nós, sempre carregarei comigo as nossas boas lembranças como motivação e
amenizaçã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 dos
meus objetivos de vida.
À minha amada noiva e futura esposa, Danieli, pela compreensão dos vários momentos
que não podemos passar juntos nessa trajetória acadêmica, bem como pelo apoio, incentivo
e amor incondicional. Também gostaria de agradecê-la não apenas por compartilharmos os
momentos 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 dos
momentos em que estive ausente.
Aos meus mestres e orientadores, os professores Huei e Wu, pelos valiosos ensinamentos
tanto na parte técnica quanto na parte pessoal, os quais levarei pelo resto da minha vida. Por
incontáveis vezes em que assumiram o papel dos pais para nos educarem. Por abdicar de muitas
noites de descanso para trabalharem com a finalidade de criar oportunidades para os alunos do
LABI. 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
ensinamentos compartilhados.
ix
x
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 quase
três anos vivenciados na mesma casa. Pela nossa invenção do prato Macalango ("Miojo" com
farinha e molho de pimenta habanero).
Aos meus amigos da Pós-graduação, Katiani, Marcos Ricardo, Mariana, Rodrigo, Willian, Jhonny (Dionísio do Sertão), pela amizade e os momentos inesquecíveis que vivenciamos
nessa 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, Vitor
Angeli e Vitor Hugo, por essa amizade duradoura e compreensão dos momentos de minha
ausência.
Aos demais amigos, pela amizade e contribuição de forma direta e indireta na minha
formação.
Aos profissionais da área médica do Serviço de Coloproctologia da Faculdade de Ciências
Médicas da UNICAMP que confeccionaram laudos textuais artificiais de exames de endoscopia
digestiva alta.
À Fabiana, secretária do PGESDE, que não mediu esforços para nos apoiar e ajudar em
diversas 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 de
trabalhos científicos em congressos.
À CAPES (Coordenação de Aperfeiçoamento de Pessoal de Nível Superior), pelo apoio
por intermédio da concessão de bolsas de pós-graduação.
Todas as demais pessoas que, de alguma forma, contribuíram com desenvolvimento deste
trabalho.
“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
xii
Sumário
Lista de Figuras
xvi
Lista de Tabelas
xix
Lista de Símbolos
xxi
1
2
Introdução
1
1.1
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.2
Premissas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.3
Hipótese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.4
Organização do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
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 . . . . . . . . . . . . . . . . . . . . . . . .
15
2.6.5
DAML + OIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
xiii
xiv
2.6.6
2.7
2.8
3
4
Ontology Web Language . . . . . . . . . . . . . . . . . . . . . . . . .
17
Ferramentas para Representação de Ontologias . . . . . . . . . . . . . . . . .
21
2.7.1
Chimaera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.7.2
OilED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.7.3
Protégé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.7.4
Servidor Ontolingua . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
Processo de Mapeamento de Laudos Médicos utilizando Ontologias
25
3.1
Considerações Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.3.6
Aplicação de Lematização . . . . . . . . . . . . . . . . . . . . . . . .
35
3.3.7
Definição dos Atributos da Tabela Atributo-Valor e da Ontologia . . . .
37
3.4
Segunda Fase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.5
Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
Desenvolvimento de Sistemas Computacionais
43
4.1
Considerações Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.2
Processo de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
4.3
Levantamento de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.4
Projeto de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.5
Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.6
Testes de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
xv
4.7
5
6
7
Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
Ferramentas e Tecnologias
55
5.1
Considerações Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 . . . . . . . . . . . . . . . . . . . . . . . . . .
64
5.9
Linguagem CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
5.10 Linguagem de Programação Javascript . . . . . . . . . . . . . . . . . . . . . .
67
5.11 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
Processo de Desenvolvimento do Sistema Computacional Colaborativo
71
6.1
Considerações Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
6.6
Apresentação do Sistema Computacional Colaborativo Desenvolvido . . . . . .
80
6.7
Etapa de Avaliação e Feedback . . . . . . . . . . . . . . . . . . . . . . . . . .
92
6.8
Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
Estudo de Caso
95
7.1
Considerações Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
7.2
Avaliação Experimental do SCC . . . . . . . . . . . . . . . . . . . . . . . . .
96
7.3
Construção do Arquivo de Padronização . . . . . . . . . . . . . . . . . . . . .
98
xvi
8
9
7.4
Elaboração da Stoplist
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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
7.8
Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Resultados e Discussão
99
111
8.1
Considerações Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
8.5
Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
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. . . . . . . . . . . . . . .
20
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 . . . . . . . . . . . . . . . . . . . . . .
48
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 . . . . . . . . . . . . . . . . . . . .
65
6.1
Diagrama de casos de uso do SCC. . . . . . . . . . . . . . . . . . . . . . . . .
74
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. . . . . . . . . . . . .
82
6.7
Funcionalidade "Gerenciamento do Conjunto de Laudos Médicos" da primeira
fase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
6.8
Telas de gerenciamento de carregamento de laudos textuais. . . . . . . . . . . .
84
6.9
Funcionalidade "Construção e Gerenciamento do Conjunto de Frases Únicas" da
primeira fase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
6.10 Funcionalidade "Definição e Gerenciamento da Lista de Stopwords" da primeira fase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
6.11 Funcionalidade "Construção e Gerenciamento do Arquivo de Padronização" da
primeira 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 primeira 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. . . . . . . . . . . . . . . .
98
7.3
Exemplo de transcrição de stopwords. . . . . . . . . . . . . . . . . . . . . . . 100
7.4
Hierarquia de classes da ontologia do SCC . . . . . . . . . . . . . . . . . . . . 103
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 . . . . . . 107
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 e
automático. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
xx
Lista de Tabelas
5.1
Tabela de exemplos de metacaracteres utilizados em ER . . . . . . . . . . . . .
8.1
Resultados da avaliação dos CFU gerados. . . . . . . . . . . . . . . . . . . . . 119
8.2
Quantidade de termos não-processados. . . . . . . . . . . . . . . . . . . . . . 119
8.3
Complexidade dos métodos empregados no PMLM . . . . . . . . . . . . . . . 120
xxi
61
xxii
Lista de Siglas
AP
BD
CFU
CSS
DAML
DARPA
DC
DOM
DRY
ECMA
EDA
ER
FCM
FO
HTML
IC
IDE
INPI
JDK
JRE
JSON
KIF
KISS
LABI
MD
MeSH
MJV
MVC
NLM
OIL
OWL
PERL
Arquivo de Padronização
Base de Dados
Conjuntos de Frases Únicas
Cascading Style Sheets
DARPA Agent Markup Language
US Defense Advanced Research Projects Agency
Dicionário do Conhecimento
Document Object Model
Don’t Repeat Yourself
European Computer Manufacturers Association
Endoscopia Digestiva Alta
Expressões Regulares
Faculdade de Ciências Médicas
Frame Ontology
HyperText Markup Language
Inteligência Computacional
Integrated Development Environment
Instituto Nacional de Propriedade Industrial
Java Development Kit
Java Runtime Environment
Javascript Object Notation
Knowledge Interchange Forma
Keep It Simple, Stupid
Laboratório de Bioinformática
Mineração de Dados
Medical Subject Headings
Máquina Virtual Java
Model-View-Controller
National Lybrary of Medicine
Ontology Inference Layer
Ontology Web Language
Practical Extraction and Report Language
xxiii
xxiv
PMLM
RDF
RDFS
RDR
RL
RM
RP
RoR
SC
SCAIMEDMobile
SCC
’sed’
SGML
SNOMEDCT
TMTOWTDI
UML
UMLS
UNICAMP
UNIOESTE
W3C
XML
Processo de Mapeamento de Laudos Médicos
Resource Description Framework
Resource Description Framework Schema
Ripple Down Rule
Regras de Lematização
Regra de Mapeamento
Regra de Padronização
Ruby on Rails
Sistema Computacional
Sistema Computacional para Análise de Imagens Médicas
Sistema Computacional Colaborativo
Stream EDitor
Standard Generalized Markup Language
Systematized Nomenclature of Medicine – Clinical Terms
There’s More Than One Way To Do It
Unified Modeling Language
Unified Medical Language System
Universidade Estadual de Campinas
Universidade Estadual do Oeste do Paraná
Wide World Web Consortium
eXtensible Markup Language
Capítulo 1
Introdução
Com os avanços tecnológicos da área computacional, são armazenadas crescentemente
grandes quantidades de dados provenientes de diversas fontes. Na área da saúde, os exames
médicos podem ser representados em diversos formatos, como áudio, vídeo, imagens, formulários, entre outros (Wiederhold and Shortliffe, 2006). Uma parte importante das informações
contidas nesses exames é descrita por meio de linguagem natural em laudos textuais, com a finalidade 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 manter o histórico clínico do paciente e auxiliar nos diagnósticos de futuras enfermidades. Adicionalmente, esses laudos, quando registrados em bases de dados computacionais, podem ser
utilizados para a construção de modelos de predição para o auxílio no diagnóstico de enfermidades 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 se
apresenta como um fato positivo, inviabiliza a análise manual dos mesmos, tornando necessário
o desenvolvimento de métodos e ferramentas computacionais que auxiliem na análise e no
gerenciamento dessas informações (Han, 2005).
Para prover suporte a análise e ao gerenciamento de dados em distintas áreas do conhecimento, 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ção
de padrões, auxiliando na descoberta de conhecimento. Esses padrões podem ser identificados
por meio de métodos de Inteligência Computacional (IC) para a criação de modelos descritivos
e 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,
como a tabela atributo-valor 1 , na qual cada linha dessa tabela é um elemento do conjunto de
1
Neste trabalho os termos tabela atributo-valor e base de dados serão usadas indistintamente.
1
2
dados 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 representados 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 um
formato 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 do
Oeste do Paraná (UNIOESTE / Foz do Iguaçu) em parceria com o Serviço de Coloproctologia
da 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 Inteligente de Dados, que tem como objetivo pesquisar e propor métodos e ferramentas para prover
suporte à 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 representação estruturada (Lee, Monard, Honorato, Lorena, Ferrero, Maletzke, Zalewski, Coy, Fagundes
and Chung, 2011). Em Honorato, Cherman, Lee, Monard and Wu (2007) foi proposta a primeira
versão do PMLM, a qual utiliza uma estrutura de dados denominada Dicionário do Conhecimento (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 de
dados computacionais. No DC encontram-se Regras de Mapeamento (RM), as quais representam possíveis combinações de termos para as frases de cada laudo e o modo como devem ser
mapeadas 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 as
seguintes 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 complexidade 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 é aplicado
no 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 do
AP. 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
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 uma
3
estrutura de dados com pouca flexibilidade no contexto de representação de RM, dificultando
a tarefa de descrição de regras mais complexas. Assim, caso seja necessária a representação
de regras mais complexas e completas, é imprescindível a definição de um novo esquema para
o DC, bem como realizar as modificações no método, de modo a adaptar o algoritmo para o
processamento desses laudos (Lee, Oliva, Maletzke, Machado, Voltolini, Coy, Fagundes and
Wu, 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 por
uma ontologia, que é uma estrutura que apresenta maior flexibilidade para a representação do
conhecimento (Lee, Monard, Honorato, Lorena, Ferrero, Maletzke, Zalewski, Coy, Fagundes
and Chung, 2011). Nessa abordagem é eliminada parte do problema de definição de novas
regras para mapeamento de laudos.
Embora o método possa ser utilizado amplamente, inclusive por profissionais que não
sejam da área de computação, atualmente todas as técnicas utilizadas no PMLM devem ser
executadas separadamente por meio de instruções computacionais, dificultando o seu uso por
profissionais de áreas não relacionadas com a computação. Desse modo, para prover suporte
ao usuário e tornar o uso do método amigável e intuitivo, é necessário que todas as técnicas
que 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ção
de laudos médicos, de modo que o alcance do método seja aumentado para a realização do
mapeamento nesses laudos.
1.1
Objetivos
Esse trabalho tem como objetivo geral automatizar e otimizar o PMLM por ontologias
mediante a integração de técnicas de processamento de laudos textuais em uma ferramenta
computacional.
Para alcançar o objetivo principal deste trabalho, os seguintes objetivos específicos foram
definidos:
• 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;
• Auto-suficiência do SCC para a construção e a alteração da ontologia empregada em um
determinado domínio;
• Pesquisa e desenvolvimento de outros métodos de processamento de textos para aprimorar a representação dos laudos;
4
• Realização de um estudo de caso para a aplicação do SCC no mapeamento de um determinado 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 manualmente e separadamente por intermédio de instruções computacionais;
• As estruturas auxiliares utilizadas como apoio ao PMLM devem ser construídas manualmente e separadamente utilizando a linguagem de marcação XML (eXtensible Markup
Language);
• A ontologia deve ser elaborada utilizando outras ferramentas computacionais, como o
Protégé;
• Uma das técnicas de processamento de textos utilizada no PMLM pode acarretar na perca
de 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 e
as etapas do PMLM por ontologias em um SCC pode tornar o processo de mapeamento mais
eficiente, tanto em termos de custo de tempo quanto em termos de precisão, bem como torná-lo
mais amigável.
1.4
Organização do Trabalho
Este trabalho está organizado do seguinte modo:
• Capítulo 2 – Fundamentos de Ontologia: neste capítulo são abordados os principais
conceitos sobre ontologias, suas definições e utilidades. Também, são apresentados os
tipos de ontologias, método de construção dessas estruturas, linguagens aplicadas para
representação de conhecimento e ferramentas comumente utilizadas para a construção de
ontologias;
5
• 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 de
processamento de textos utilizadas no PMLM bem como o método de lematização, abordagem proposta para a substituição do método de stemming neste trabalho;
• Capítulo 4 – Desenvolvimento de Sistemas Computacionais: neste capítulo são abordados conceitos de engenharia de software focados na construção de sistemas computacionais. Também são apresentados conceitos de processo de software utilizado para o
desenvolvimento do SCC;
• Capítulo 5 – Ferramentas e Tecnologias: neste capítulo são apresentadas as ferramentas
utilizadas para a construção da solução computacional deste trabalho, como as linguagens
de 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 para
desenvolvimento 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 de
software e ferramentas utilizadas para a construção do SCC;
• Capítulo 7 – Estudo de Caso: neste capítulo é apresentado o estudo de caso realizado
neste trabalho, utilizando o SCC desenvolvido para a aplicação do PMLM automatizado
em um conjunto de laudos médicos textuais artificiais que simulam exames de Endoscopia
Digestiva Alta (EDA);
• Capítulo 8 – Resultados e Discussão: neste capítulo são apresentados e discutidos os
resultados da avaliação experimental do SCC desenvolvido. Essa avaliação foi realizada
por meio da aplicação do PMLM automatizado em um conjunto de laudos médicos textuais artificiais de exames de EDA. Também foi comparado o desempenho da execução
do 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 desenvolvimento, e sugestões de trabalhos futuros.
6
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 de
dados, é imprescindível a construção de métodos e de ferramentas para a organização e o gerenciamento dessas informações de modo que possam ser utilizadas futuramente em aplicações
de 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 processos
desempenhem as suas tarefas de forma rápida e eficiente. Nesse sentido, o uso de ontologias
pode 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 para
a construção de ontologias proposto por Uschold and Gruninger (1996). Na Seção 2.6 são demonstradas 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 e
o processamento de ontologias.
2.2
Definição de Ontologia
Ontologia, palavra oriunda dos termos gregos ontos (ser) e logia (conhecimento), consiste
em um campo da filosofia que tem o propósito de estudar as características do ser, da existência
e das questões que envolvem a metafísica (Harper, 2010). A definição de ontologia teve origem
na Grécia Antiga e ocupou a mente de filósofos como Platão, Aristóteles e Parmênides. No
século XVII, enquanto uns filósofos consideravam o termo ontologia equivalente à palavra metafísica, outros definiam esse termo como uma divisão da metafísica. Atualmente, a metafísica
e a ontologia são consideradas sinônimos, filosoficamente (Guarino and Giaretta, 1995). Na
área computacional, ontologia é uma estrutura de dados que tem a finalidade de representar o
7
8
conhecimento de um domínio específico.
Para Uschold and Gruninger (1996), ontologia é um termo utilizado como referência para
denominar o compartilhamento do conhecimento de alguma área de interesse, podendo ser
aplicada no desenvolvimento de ferramentas computacionais para processamento de informações representadas estruturadamente. Em uma ontologia é incorporado algum tipo de visão de
mundo relacionado com um determinado campo de conhecimento. Essa visão é caracterizada
como um conjunto de conceitos (entidades, atributos, processos, entre outros) e relacionamentos 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 que
muitas vezes é necessária uma inferência mais detalhada do conhecimento para excluir ou reduzir 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 propriedades, de relações, de restrições e de comportamentos. Nesse sentido, uma entidade é definida
como uma organização, que é composta por várias divisões e consiste em um grupo de agentes
associados a um conjunto de papéis, que são funções desempenhadas pelos agentes da organização com a finalidade de cumprir metas estipuladas. Agente é um membro de uma divisão da
organização que assume pelo menos um papel a ser desempenhado.
Segundo Gruber (2009), uma ontologia tem o intuito de definir um conjunto de primitivas de representação, como classes, atributos e relacionamentos para modelar o domínio de
conhecimento. Para a definição de primitivas, devem ser incluídas as informações sobre o seu
significado e as restrições lógicas para sua aplicação. Por exemplo, em sistemas de bancos de
dados, 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 and
Gruninger, 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 redes, integração de diferentes sistemas, entre outros;
• Interoperabilidade: possibilitam a integração de diferentes softwares sem a necessidade
de tradução de métodos de modelagem, de linguagens de programação, de ferramentas
computacionais, e de arquiteturas;
9
• Engenharia de Sistemas: facilitam o processo de identificação de requisitos durante a modelagem e o desenvolvimento de projetos de SC, tal como possibilitam a automatização
da verificação de consistência, aumentando a confiabilidade do sistema. Também, essas
estruturas de dados podem ser reutilizadas para a construção de outros sistemas. Assim,
ontologias podem ser utilizadas como apoio na especificação de requisitos, auxiliando
na tarefa de identificação de necessidades que deverão ser atendidas por meio de uma
solução computacional.
Nesse contexto, as ontologias geralmente são utilizadas com o propósito de facilitar a
realização de tarefas, como: organização de conhecimento; compartilhamento de informações
entre as pessoas; processamento de dados; aplicação de processos de MD; e comunicação entre
os componentes de software e/ou aplicações computacionais (Chute, 2005). Assim, ontologias
podem ser aplicadas em projetos que envolvem multidisciplinaridade com o objetivo de facilitar
o diálogo entre os especialistas de diferentes áreas, bem como apoio para reduzir a complexidade do desenvolvimento de sistemas.
Na área da saúde, por exemplo, várias ontologias foram desenvolvidas com o intuito de
representar vocabulários médicos em estruturas de dados para que possam ser utilizadas por ferramentas 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ências
médicas. Sendo assim, esse repositório possui três bases de conhecimento, tais como a Metathesaurus, a Semantic Network e a Specialist Lexicon.
A Metathesaurus é uma ampla base de dados multilíngua de vocabulários utilizada para
o mapeamento de termos médicos com a finalidade de definir ou de identificar distintos termos
que estão associados a um simples conceito. Essa base possui mais de um milhão de conceitos
médicos e mais de cinco milhões de nomenclaturas de termos, compondo mais de 100 vocabulários diferentes, incluindo os vocabulários controlados Medical Subject Headings (MeSH) e
Systematized Nomenclature of Medicine – Clinical Terms (SNOMED-CT).
A Semantic Network é um catálogo de tipos de semânticas (categorias) e de relacionamentos que definem a classificação dos conceitos presentes na base Metathesaurus por meio da
atribuiçã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áticas
para 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
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-
10
cas (FCM) da Universidade Estadual de Campinas (UNICAMP) foi proposta uma versão do
Processo de Mapeamento de Laudos Médicos (PMLM) que utiliza ontologias para a representação do conhecimento. Essa estrutura contém atributos e Regras de Mapeamento (RM), que
são utilizados para transformação de laudos médicos textuais não estruturados para o formato
estruturado, 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 envolvido, que é representado em uma estrutura de dados segundo os níveis de detalhes determinados (Bodenreider and Burgun, 2005). Nesse sentido, essas ontologias podem ser classificadas
como:
• Ontologias de aplicação (application ontologies): representam os conceitos que são
dependentes de um domínio específico e de suas atividades que atendem as especificações
do problema a ser resolvido (Guarino, 1997);
• Ontologias centrais (core ontologies): descrevem as divisões do estudo de uma determinada área e/ou conceitos genéricos e abstratos (Guarino and Giaretta, 1995). Essas
ontologias contém apenas definições necessárias para compreender outros conceitos;
• Ontologias de domínio (domain ontologies): especificam o conhecimento de um determinado domínio específico, ou seja, parte particular do mundo. Para a construção desse
tipo de ontologia é necessário o uso de uma ontologia de nível mais genérico que descreva
os termos mais gerais e que sejam independentes de domínio. As ontologias de nível mais
genérico são denominadas de ontologias gerais (França, 2009);
• Ontologias gerais (foundation ontologies): representam o conhecimento em um nível
intermediário de detalhes independentemente do seu uso em representações específicas (Bodenreider and Burgun, 2005). Assim, as ontologias gerais consistem em modelos 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 de
carro, de trem, de avião ou de navio. Desse modo, o veículo pode ser representado por
uma ontologia geral e os tipos derivados de veículo podem ser representados por uma
ontologia de domínio;
• Ontologias de representação (representation ontologies): esboçam a classificação das
primitivas que são utilizadas por intermédio de uma linguagem de representação de conhecimento (Guarino, 1997);
• Ontologias de tarefas (task ontologies): descrevem o vocabulário relacionado com as
atividades necessárias para a resolução de problemas independentemente do domínio em
11
que ocorrem (Guarino and Giaretta, 1995).
2.5
Construção de Ontologias
Na literatura foram propostos vários métodos para o desenvolvimento de ontologias, dos
quais 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 mais
ontologias, bem como são respondidas questões à respeito das mesmas, como a motivação e
o modo de uso. O escopo é definido mediante um conjunto de questões de competência, os
quais 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 das
questões de competência.
Na Fase (2), após as definições da etapa anterior, é construída a ontologia considerando
três aspectos:
• Captura: contempla atividades para a definição da ontologia, como a identificação dos
conceitos principais e dos relacionamentos existentes no domínio de interesse, a produção
de definições exatas de texto não ambíguos para os conceitos identificados e a definição
dos termos referentes aos conceitos e aos relacionamentos;
• 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 desenvolvimento;
• Integração com ontologias existentes: durante a codificação dessa estrutura, podem ser
reaproveitadas outras ontologias que foram desenvolvidas anteriormente.
12
Na Fase (3), verifica-se se foram atendidas todas as especificações levantadas para o desenvolvimento de uma ou mais ontologias. Assim, são avaliadas as suas características, tais
como a sua expressividade e a sua consistência. Essa avaliação deve determinar se é necessária
a extensão da ontologia ou se as questões de competência podem ser respondidas por meio de
ontologias existentes.
Na Fase (4), o processo de desenvolvimento da ontologia é documentado. Nessa documentação são incluídas as especificações levantadas durante as etapas anteriores e os conceitos
utilizados para o desenvolvimento da estrutura.
Na Etapa (5), são definidos os conjuntos de técnicas, métodos e princípios para a aplicação
de cada uma das fases anteriores, bem como são estipulados os relacionamentos entre essas
fases, 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 o
desenvolvimento das outras fases.
2.6
Linguagens de Representação de Ontologias
Nessa seção são apresentadas as linguagens comumente utilizadas para a representação
de 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, Gruber, Hayes, Letsinger, Lifschitz, Macgregor, Mccarthy, Norvig and Patil, 1992) foi desenvolvida
com o objetivo de facilitar a troca de informações entre softwares escritos em diferentes linguagens. A KIF, caracterizada por ser baseada no cálculo de predicados e por apresentar alto poder
de expressividade, foi uma das primeiras linguagens elaboradas com o intuito de representar o
conhecimento por meio de ontologias. O propósito dessa linguagem é similar ao da linguagem
Postscript (Adobe Systems, 1990), que é comumente utilizada em programas de formatação de
textos e de gráficos para a visibilização de informações.
Nesse sentido, essa linguagem possui algumas características que podem ser essenciais
para a representação do conhecimento, tais como:
• Semântica declarativa: possibilita a compreensão das principais expressões dessa linguagem 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álculo
de predicados;
13
• Representação de meta-conhecimento: provém suporte aos usuários em processo de tomadas 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, no
qual subclass é uma operação para a definição de subclasses, => é um operador para declaração
de 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 manutenção de ontologias de maneira flexível e que seja compatível com várias linguagens de
representação de conhecimento. Essa linguagem é implementada em um programa que utiliza
uma sintaxe simples para traduzir definições, que são os dados de entrada para vários sistemas
de representação.
Nesse contexto, a sintaxe da Ontolingua é baseada nas notações padrões e cálculo de
predicados presentes na linguagem KIF. Assim, a linguagem Ontolingua traduz ontologias desenvolvidas na linguagem KIF em sistemas de representação, os quais são limitados pela lógica
de primeira ordem para a implementação do raciocínio. Desse modo, essa linguagem é projetada para capturar representações comuns do conhecimento. Também, a Ontolingua é baseada
no Frame Ontology (FO) (Farquhar, Fikes and Rice, 1997), o qual foi construído como uma
camada sobre o KIF e consiste em uma ontologia de representação do conhecimento que tem
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 dados
utilizada para representar conhecimento de um determinado domínio (Minsk, 1985).
Desse modo, de acordo com Corcho and Gómez-Pérez (2000), a linguagem Ontolingua
permite construir ontologias por qualquer uma das três maneiras: utilizando exclusivamente o
vocabulário FO; usando expressões KIF; ou aplicando ambas as linguagens simultaneamente.
14
Na Figura 2.2 é apresentado um exemplo de definição de classes estruturadas na linguagem 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 para
a especificação de propriedades de classes e subclass-of é uma operação para a definição de
subclasses.
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 dispositivos por meio da Internet. Essa linguagem é focada na representação de dados de forma flexível
e 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 Language (XML) (Bray, Paoli, Sperberg-McQueen, Maler and Yergeau, 2006) para representar os
dados e possibilitar a especificação da semântica para os dados baseados em XML de modo
padronizado 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 finalidade
de enfrentar o desafio de gerenciar grandes quantidades de documentos eletrônicos publicados
na web. Assim, o XML oferece uma definição de sintaxe padrão para o desenvolvimento de
documentos estruturados. Essa linguagem é apresentada no Capítulo 5.
Nesse contexto, a linguagem RDF foi desenvolvida para atender a alguns requisitos de
representação do conhecimento, tais como: prover suporte ao desenvolvimento de modelos
de dados que sejam simples e fáceis de serem utilizados em aplicações de processamento e
de 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 utilizadas
para nomear todos os tipos de objetos em RDF; utilizar XML para codificar o modelo de dados
para a troca de informações entre aplicativos distribuídos; utilizar diferentes tipos de dados de
esquema XML para representar valores com o objetivo de auxiliar no compartilhamento de
15
informações entre aplicativos que utilizam as linguagens XML e RDF; e facilitar o uso em
escala de recursos da Internet.
No entanto, RDF não oferece mecanismos para descrição de propriedades, bem como
não provê recursos para a descrição de relações entre estas propriedades e outros recursos. Para
reduzir 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 a
finalidade de definir as classes e as propriedades para serem utilizadas na descrição de outras
propriedades.
Na Figura 2.3 é apresentado um exemplo de definição de classes estruturadas na linguagem RDFS, no qual rdfs:Class é um construtor que define classes, rdf:ID é o identificador de um
elemento 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 estabelece
qual a classe que um elemento pertence neste exemplo e rdf:resource representa o nome da
classe que um elemento está vinculado.
Figura 2.3: Exemplo de definição de classes RDFS.
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 linguagem
que tem o propósito de padronizar a tarefa de construção de ontologias por meio do uso de
padrõ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 de
primitivas 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 diferentes
dessa linguagem, tais como: nível de objeto, na qual são descritas as instâncias concretas de
16
uma ontologia; primeiro meta-nível, em que as definições ontológicas atuais são disponibilizadas; e segundo meta-nível, também conhecido como meta-meta nível, na qual são definidas as
caracterí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, no
qual 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 de
caracterí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 Defense Advanced Research Projects Agency (DARPA), do Departamento de Defesa dos Estados
Unidos (United States Department of Defense), foi desenvolvida uma linguagem de marcação
baseada em RDF e XML denominada DARPA Agent Markup Language (DAML) (Hendler and
D. L. McGuinness, 2000). Essa linguagem foi elaborada com o objetivo de facilitar o desenvolvimento 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ída
para a DAML–ONT, que consiste em uma linguagem simplificada para a representação de conceitos em classes RDF de forma mais sofisticada que a representação permitida pela linguagem
RDFS.
Assim, com objetivo de aprimorar a representação do conhecimento, foram unidas as
linguagens 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 a
representaçã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 um
conjunto de dados, no qual daml:oneOf define a enumeração de elementos, parseType representa o tipo de dados, daml:collection determina que essa estrutura é uma coleção não ordenada
de dados, daml:Thing é um elemento utilizado para a declaração de elementos de representação
17
de 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 linguagem
baseada nas linguagens OIL e DAM+OIL utilizada para a representação do conhecimento que
tem o intuito de construir e de instanciar ontologias na web. Assim, a linguagem OWL foi
desenvolvida para ser utilizada na web semântica (semantic web) (Berners-Lee, Hendler and
Lassila, 2006).
A web semântica consiste em uma visão do futuro da web, onde a informação terá um
significado explícito, facilitando o processamento e a integração de informações disponíveis
na web pelos computadores. Assim, o propósito é tornar os recursos da web mais acessíveis
aos processos automatizados por meio da adição de informações sobre os recursos que descrevem ou fornecem conteúdo na web, facilitando o trabalho de cooperação entre o humano e a
máquina (McGuinness and van Harmelen, 2004).
Desse modo, a ontologia OWL é construída utilizando estruturas XML e RDF. As informações desse tipo de ontologia são organizadas utilizando as tags RDF, RDFS e OWL, também
conhecidos como construtores. Também, nessa linguagem as semânticas formais e específicas
determinam como derivar consequências lógicas, tais como os fatos que não estejam presentes
na 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 que
compartilham 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,
18
sendo essa associação denominada extensão de classe. Cada indivíduo nessa extensão é denominado uma instância de classe.
As classes podem ser organizadas em uma hierarquia de especialização, também denominado herança, por exemplo, a classe PessoaJurídica pode ser uma especialização da classe
Pessoa. Na linguagem OWL, o mecanismo de especialização pode ser aplicado utilizando o
construtor rdfs:subClassOF. Nessa linguagem existe uma classe embutida mais geral denominada Thing, que é uma superclasse para todas as classes OWL (Bechhofer, van Harmelen,
Hendler, Horrocks, McGuinnes, Patel-Schneider and Stein, 2004; McGuinness and van Harmelen, 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 de
complemento. 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 simultaneamente com uma outra classe especificada, ou seja, as classes não podem possuir os
mesmos indivíduos. Por exemplo, os indivíduos da classe Fruta não podem ser instanciados pela classe Carne.
• owl:equivalentClass: indica que duas classes possuem a mesma extensão de uma mesma
classe, 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 de
intersecção. Assim, a classe que utiliza esse construtor, além de suas características específicas, permite o uso apenas das características que são semelhantes entre as classes
utilizadas. Por exemplo, a intersecção das classes Brasileiro e Argentino ocasiona nas
características equivalentes aos da classe Pessoa;
• owl:oneOf : define a enumeração de classes, permitindo que as mesmas sejam descritas
pela enumeração exaustiva de suas instâncias. Assim, a classe definida por esse construtor
contém apenas indivíduos enumerados. Por exemplo, a classe Fruta pode ser composta
pelos 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 um
componente OWL e owl:resource é utilizado para referenciar elementos nessa linguagem.
19
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 relacionamento entre os indivíduos (Bechhofer, van Harmelen, Hendler, Horrocks, McGuinnes,
Patel-Schneider and Stein, 2004; Smith, Welty and McGuinness, 2004). Essa linguagem possui
dois tipos diferentes de propriedades:
• datatype properties: estabelece relações entre as instâncias de classes, literais da linguagem 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 propriedades, para os quais são apresentadas as suas funcionalidades:
• owl:equivalentProperty: determina que duas ou mais propriedades são equivalentes, ou
seja, têm a mesma propriedade de extensão;
• owl:functionalProperty: especifica que uma propriedade P pode ter apenas um único
valor para cada indivíduo;
• owl:inverseFunctionalProperty: indica que um valor pode ser somente atribuído à propriedade P de um único indivíduo;
• owl:inverseOf : define que uma propriedade é inversa em relação à outra propriedade. Por
exemplo, se a propriedade Px é inversa da propriedade Py e se a classe X está relacionada
com 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) é uma
instância de P;
• owl:transitiveProperty: determina que uma propriedade é transitiva, isto é, se os conjuntos (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 possibilitar a aplicação da propriedade. Assim, se a propriedade possui uma classe como um
20
de seus domínios e um indivíduo é relacionado a um outro indivíduo por meio dessa propriedade, então esses indivíduos pertencem a mesma classe. Por exemplo, a propriedade
denominada temFilho pode ser indicada para ter o domínio de progenitores (mãe e/ou
pai);
• rdfs:range: limita a instanciação de indivíduos por meio da definição de valores que são
válidos para uma determinada propriedade. Por exemplo, a propriedade diaSemana pode
ser 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 propriedade. Por exemplo, as propriedades terCarro, terCamionete e terCaminhão são subpropriedades 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 um
atributo.
Na Figura 2.7 é apresentado um exemplo de uso de propriedade na linguagem OWL, em
que é definida a propriedade temCasa, que é sub-propriedade de temImovel e possui a propriedade temDomicilio como equivalente e a classe Imovel como limitação do valor a ser aceito
nessa definição.
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ão
permitidas para serem aplicadas em instâncias de uma classe. Essa linguagem fornece dois tipos
de 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 no
alcance da propriedade quando são utilizadas na descrição de classes, ou seja, define os valores
possíveis ou um intervalo de valores que uma propriedade é capaz de obter. A restrição de
cardinalidade limita a quantidade de valores que uma propriedade pode assumir na descrição de
classes (Bechhofer, van Harmelen, Hendler, Horrocks, McGuinnes, Patel-Schneider and Stein,
2004; McGuinness and van Harmelen, 2004).
21
Em ontologias desenvolvidas com a linguagem OWL, as restrições de propriedades podem ser aplicadas por meio do uso das tags <owl:Restriction> e
<owl:onProperty rdfs:resource=”propriedade”>, das quais a tag <owl:onProperty> indica a
propriedade restrita. A seguir são apresentados os construtores das restrições que limitam os
valores que são utilizados em uma propriedade:
• owl:allValuesFrom: descreve uma classe para todos os indivíduos de um determinado
conjunto em que todos os valores da propriedade em questão são membros quaisquer da
extensã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 restringindo
todos os seus valores como instâncias da classe Pessoa;
• owl:someValuesFrom: determina uma classe para todos os indivíduos de um determinado
conjunto que possuem pelo menos um valor da propriedade em questão e o mesmo é um
exemplo da classe de descrição ou de valor em um intervalo especificado. Ao contrário
do allValuesFrom, o construtor someValuesFrom não limita a propriedade para que todos
os seus valores sejam instâncias da mesma classe.
Também, nessa linguagem são incluídas limitações de cardinalidade, que são definidas
como restrições locais, as quais são apresentados a seguir:
• owl:maxCardinality: determina o número máximo de instâncias que uma propriedade
possa possuir;
• owl:minCardinality: estabelece o número mínimo de instâncias que uma propriedade
possa obter;
• owl:cardinality: define que uma propriedade possui o valor de maxCardinality igual ao
valor do minCardinality, ou seja, uma propriedade deve possuir exatamente um número
de instâncias. Por exemplo, a propriedade temCPF da classe PessoaJurídica deve ter o
valor 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 construção de ontologias. A seguir são apresentadas as principais ferramentas utilizadas para o
desenvolvimento dessas estruturas.
22
2.7.1 Chimaera
Chimaera (McGuinness, Fikes, S. and Wilder, 2000) é uma ferramenta computacional que
tem a finalidade de prover suporte aos usuários nas tarefas de criação e de manutenção de ontologias na web. Essa ferramenta tem duas funções principais: mesclar ontologias múltiplas em
uma só e evoluí-las. Também, Chimaera suporta ontologias oriundas de bases de conhecimento
de formatos diferentes por meio da reorganização de taxonomias, da resolução de conflitos de
nome, da edição, entre outros.
Nesse sentido, Chimaera possui um ambiente simples para a construção e a edição de
ontologias, tal como possibilita que o usuário utilize o editor/navegador do ambiente Ontolingua
para a edição mais extensa e complexa dessas estruturas de dados. Também, é importante
destacar que essa ferramenta computacional pode utilizar ontologias representadas por meio
das linguagens OWL e DAML.
2.7.2
OilED
OilED (Horrocks, Goble and Stevens, 2001) é uma ferramenta para construção de ontologias nas linguagens OIL e DAML+OIL com o intuito de proporcionar um estilo simples e
intuitivo para indução de raciocínio por intermédio de uma interface amigável ao usuário. Essa
ferramenta utiliza frames para lidar com a expressividade da linguagem OIL. A ferramenta OilED também usa mecanismos altamente sofisticados de indução de raciocínio por DL com o
propósito de gerar conclusões para o raciocínio que está sendo processado, facilitando a elaboração de ontologias mais complexas e detalhadas.
Na versão atual dessa ferramenta é necessária a inclusão de vários recursos para a construção de ontologias, pois o mesmo não suporta o desenvolvimento dessas estruturas em larga
escala, 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) consiste em um ambiente de código aberto (open source) e de uso gratuito para construção de
sistemas baseados em conhecimento. Inicialmente desenvolvido com objetivo de atender a área
mé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ção
de ontologias e bases de conhecimento; e a visão (view), que oferece uma interface ao usuário
para exibir e editar ontologias.
Atualmente, Protégé pode construir e editar ontologias em várias linguagens, tais como
OWL, RDF, XML, Unified Modeling Language (UML) e banco de dados relacionais. Para a
23
construção de ontologias na linguagem OWL foi desenvolvido um plugin 1 de extensão denominado 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 desenvolvedores ativos que utilizam e desenvolvem esse plugin; uma biblioteca de componentes
reutilizáveis; e uma arquitetura flexível.
2.7.4
Servidor Ontolingua
Servidor Ontolingua (Farquhar, Fikes and Rice, 1997) é um conjunto de ferramentas que
tem o propósito de apoiar o processo de construção de ontologias na linguagem Ontolingua de
modo individual, bem como de forma compartilhada entre grupos. Essas ferramentas fazem
o uso da web para permitir o acesso e oferecer recursos aos usuários para manipulação de
ontologias, como publicação, navegação, criação, edição e compartilhamento em um servidor
específico.
Sendo assim, o Servidor Ontolingua oferece muitas facilidades para o desenvolvimento
de ontologias, tais como:
• Linguagem de representação semi-formal que oferece suporte para a descrição de termos apresentados informalmente em linguagem natural e formalmente em linguagem de
representaçã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 dados
médicos, pois com essa estrutura é possível organizar o conhecimento de modo flexível e estruturado. Para representação de dados médicos, na literaturam foram desenvolvidas várias ontologias, como a UMLS, que é o maior vocabulário de termos de ciências biomédicas disponível
para 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 para
mapear conjuntos de laudos médicos textuais para uma base de dados. As ontologias utilizadas
nesse processo são representadas por intermédio da linguagem OWL devido a sua grande quantidade de recursos para flexibilizar o desenvolvimento de ontologias, permitindo a expansão do
1
Plugin é um componente de software que permite adicionar uma caraterística específica a uma aplicação de
software já existente.
24
potencial de representação dessas estruturas de acordo com o domínio de conhecimento. Para o
desenvolvimento 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 e
intuitiva ao usuário, bem como não é necessário o conhecimento da linguagem OWL por parte
do usuário para o uso dessa ferramenta. Também, essa ferramenta possui código-fonte aberto e
o seu uso é gratuito, possibilitando que desenvolvedores de software aprimorem essa ferramenta
de acordo com as suas necessidades e/ou de outros usuários.
Capítulo 3
Processo de Mapeamento de Laudos
Médicos utilizando Ontologias
3.1
Considerações Iniciais
Neste capítulo é apresentado o processamento de textos utilizados no Processo de Mapeamento de Laudos Médicos (PMLM), que tem o objetivo de transformar conjuntos de laudos
textuais 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 proposta a primeira versão desse processo, a qual utiliza o Dicionário do Conhecimento (DC) para
a descrição de Regras de Mapeamento (RM). O DC consiste em uma estrutura de dados utilizada 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 dados
organizados hierarquicamente com o uso de marcadores (tags).
Porém, estudos realizados anteriormente apontam que o DC apresenta pouca flexibilidade
para a representação do conhecimento, dificultando a elaboração de RM mais complexas, sendo
necessária a construção de novos esquemas de DC e a alteração do método de mapeamento
para 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 estrutura
de 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 mapeamento
desses laudos médicos e alguns trabalhos nos quais foram aplicadas essas abordagens. Em
seguida, são apresentadas as duas etapas do PMLM, as quais são abordadas nas Seções 3.3 e
3.4.
3.2
Mapeamento de Laudos Médicos
Os laudos textuais são imprescindíveis para qualquer especialidade médica, pois permitem descrever achados em exames realizados e manter o histórico do paciente quanto a procedimentos, sintomas, enfermidades, entre outros. No entanto, para que as informações contidas
nesses laudos possam ser utilizadas, por exemplo, para estatísticas ou pesquisas médicas, para
o 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 uma
base dados, como planilhas eletrônicas, o que torna essa tarefa inviável para grandes quantidades de laudos textuais. Na Figura 3.1 é ilustrado um exemplo de transcrição manual de um
fragmento de laudo artificial pré-processado da seção de esôfago para uma base de dados, onde
as linhas representam laudos mapeados e as colunas representam características (atributos) consideradas essenciais mapeadas nesses laudos.
Nesse sentido, no LABI da UNIOESTE/Foz do Iguaçu em parceria com o Serviço de
Coloproctologia da Faculdade de Ciências Médicas (FCM) da UNICAMP foi desenvolvido o
PMLM com a finalidade de automatizar e padronizar a transcrição de informações presentes
em 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 proposta a versão do PMLM que utiliza uma estrutura de dados denominada Dicionário de Conhecimento (DC) para o mapeamento de laudos. Essa estrutura contém RM que representam
possíveis combinações de termos em frases de cada laudo para o preenchimento da base de
dados. 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 outras
informações importantes à respeito de um determinado local;
• Subcaracterística: representa as informações complementares de uma determinada característica.
No caso do DC, essas regras são representadas de modo sequencial, em que cada local
27
Figura 3.1: Exemplo de transcrição manual de um laudo textual artificial da seção de esôfago
para uma base de dados.
descreve uma lista de característica e cada característica pode possuir uma lista de subcaracterísticas, como ilustrado na Figura 3.2, em que Li é uma lista de locais, Li Cj é a lista de
características de Li , Aj é o atributo que é preenchido caso seja encontrada a sequência Li Cj
no laudo, Vj é o valor do atributo Aj , Li Cj Sk é subcaracterística de Li Cj , Ask é o atributo que
é preenchido caso seja encontrado no laudo a sequência Li Cj Sk no laudo e V sk é o valor do
atributo Ask .
Entretanto, o DC apresenta pouca flexibilidade para a representação do conhecimento e
a descrição de RM, dificultando a elaboração de regras que apresentam maior complexidade
e completitude 1 , tornando indispensável a construção de novas estruturas de DC e especialmente, a realização de modificações no método para adaptá-lo ao novo esquema de DC para o
mapeamento de laudos que não tenham sidos mapeados anteriormente.
Com a finalidade de melhorar a representação do conhecimento presente em laudos textuais, em Costa, Ferrero, Lee, Coy, Fagundes and Chung (2009) foi apresentada uma proposta
inicial de uma variação do PMLM com o objetivo de substituir o DC por uma ontologia para
aumentar a flexibilidade na representação do conhecimento e facilitar o reuso dessa estrutura
1
Possibilidade 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, Fagundes, Góes, Coy and Chung, 2007).
para a construção de outras ontologias sem a necessidade de reconstruí-la e sem a necessidade
da alteração do algoritmo de mapeamento para adaptá-lo a essas estruturas.
Em Wu, Coy, Lee, Fagundes, Ferrero, Machado, Maletzke, Zalewski, Leal, Ayrizono and
Costa (2010) e Lee, Monard, Honorato, Lorena, Ferrero, Maletzke, Zalewski, Coy, Fagundes
and Chung (2011), foi proposta a versão atual do PMLM. Entretanto, todas as técnicas aplicadas
nesse processo devem ser executadas manualmente e separadamente por intermédio do uso de
comandos computacionais, dificultando a aplicação do método por profissionais que não sejam
da á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 arquivos
escritos na linguagem Perl utilizando instruções específicas por meio de interpretadores dessa
linguagem. Outro exemplo é a realização do mapeamento desses laudos, para a qual é necessária
a execução manual do método por meio de uma Máquina Virtual Java (MVJ), o qual é executado
com o uso de instruções computacionais.
Ainda, a construção das estruturas como a lista de stopwords (stoplist) e o Arquivo de
Padronização (AP), que são apresentadas na Seção 3.3, é realizada manualmente com o uso de
estruturas XML. A organização manual de stopwords e de Regras de Padronização (RP) em
estruturas XML se apresenta como uma atividade altamente repetitiva e custosa, pois as suas
informações devem ser organizadas de forma padronizada e hierárquica por intermédio de marcadores, podendo acarretar na representação errônea das mesmas e influenciar no desempenho
do pré-processamento e do mapeamento de laudos médicos (Lee, Oliva, Maletzke, Machado,
Voltolini, Coy, Fagundes and Wu, 2013).
Para a construção de ontologias, podem ser utilizadas ferramentas computacionais de uso
gratuito 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 e
o conhecimento da linguagem de representação de ontologias denominada OWL (Smith, Welty
29
and McGuinness, 2004) por parte de seus usuários, tal como para a elaboração de RM e de
atributos é 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 laudos
textuais digitais com a finalidade de identificar padrões relevantes que são representados por
meio de um Arquivo de Padronização (AP). Em seguida, os padrões identificados nos laudos
são analisados em conjunto com profissionais da área médica e da área computacional para
definir os atributos da tabela atributo-valor (base de dados estruturada) e as RM que irão compor 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, Maletzke, Machado, Voltolini, Coy, Fagundes and Wu (2013)).
Com base na Figura 3.3, nas seções seguintes são apresentadas as técnicas de processamento de textos utilizadas no PMLM, bem como são abordadas a construção do AP, da tabela
atributo-valor e da ontologia.
30
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 existentes em um conjunto de laudos médicos. Essa técnica é aplicada de forma sequencial em três
passos (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 Figura 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 influenciado
pela 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
devido à variação de um ou mais caracteres, como a presença ou a ausência de acentuação e de
caracteres maiúsculos ou minúsculos.
Nesse sentido, para evitar problemas de variações de um mesmo caractere, cada termo
presente no CFU é normalizado com o objetivo de substituir caracteres maiúsculos por caracteres minúsculos e caracteres com presença de acentuação por caracteres sem acentuação (Cherman,
31
Lee, Honorato, Fagundes, Góes, Coy and Wu, 2007). Na Figura 3.5 é apresentado um exemplo
de 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ções
que podem ser padronizadas, como termos semelhantes ou frases que apresentam as mesmas
informações de maneiras distintas. Assim, em conjunto com especialistas do domínio é iniciada
a construção do AP. Esse arquivo é uma estrutura de dados representada por meio da linguagem
de marcação XML utilizada para uniformização de laudos textuais com o objetivo de reduzir a
complexidade de cada frase presente nesses laudos, de modo que seja compatível com as RM
presentes em uma ontologia. Essa uniformização é realizada por intermédio da substituição de
termos que apresentam o mesmo significado ou em formato inadequado por um sinônimo ou
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 anormalidade 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 e
32
distensibilidade, 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 marcador 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 termos
que irão substituir um determinado termo, <old> é o marcador que constitui um termo a ser
padronizado e <new> é o marcador que representa um novo termo que substituirá o termo representado no marcador <old>, caso seja encontrado em um laudo textual durante a aplicação
do 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 a
finalidade 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 determinado
caractere, ou termos que ocorrem raramente em frases (Honorato, Cherman, Lee, Wu and Monard, 2007). Por exemplo, no padrão "ponto[s]*\s*esbranquicado[s]*" (Figura 3.6), a expressã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
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 apresentadas nas próximas seções, pode gerar termos ou frases diferentes, aumentando as possibilidades para desenvolvimento de RP. Desse modo, a construção do AP é continuada no decorrer
da aplicação da primeira fase do PMLM, à medida que são identificadas informações que podem
ser uniformizadas.
2
Expressão regular é uma sequência de caracteres que formam um padrão a ser identificado em uma frase ou
uma palavra, por exemplo na forma de operações "busca e substituição".
33
3.3.4
Remoção de Stopwords
Esse método tem a finalidade de reduzir o tamanho de frases por meio da eliminação de
stoptwords (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ão
dependentes 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 por
intermédio da linguagem de marcação XML.
Na Figura 3.7 é apresentado um exemplo de stoplist, onde <stopwords> é o marcador
que 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.
3.3.5
Aplicação de Stemming
O método de aplicação de stemming tem o objetivo de reduzir cada termo para o seu
radical, 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 sentido
de 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ças
podem 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, mas
34
estã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 stemming, dos quais se destaca o Stemmer de Porter (Porter, 1997), que é um algoritmo de remoção
de sufixos de palavras em inglês. Nesse algoritmo, a remoção de sufixos é exclusivamente baseada em regras, sem o uso de outras estruturas para realização de operações de busca, tais como
listas de exceções e/ou dicionários de dados. Essas regras são escritas na forma S1 → S2 , em
que o sufixo S1 é substituído por S2 . Por exemplo, a regra ”ico” → ¨¨ elimina os sufixos de
palavras 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. Esse
mé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.
No PMLM, os passos 3 e 8 não são necessários para o processamento de termos, pois
já são aplicados anteriormente nos métodos apresentados nas Seções 3.3.2 e 3.3.4, respectivamente. Na Figura 3.8 é ilustrado graficamente um exemplo de aplicação de stemming em um
conjunto de frases normalizadas e sem a presença de stopwords.
No entanto, a aplicação de stemming pode acarretar, em alguns casos, na perda da legibilidade de termos, dificultando a compreensão de algumas palavras. Também, a redução dos
termos para o seu radical pode conduzir eventualmente a uma interpretação semântica incorreta
devido à existência de termos com significados diferentes, mas com radicais iguais (Fuller and
Zobel, 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.
35
Figura 3.8: Exemplo de aplicação de stemming.
Desse modo, com a finalidade de amenizar esses problemas de representação do conhecimento, neste trabalho também é proposta a substituição do método de stemming pela técnica de
aplicaçã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 literatura médica, para descrição de procedimentos médicos, diagnóstico de enfermidades e outras
informações. Entretanto, há termos que se diferenciam apenas morfologicamente, mas possuem
o mesmo significado (Ananiadou and Mcnaught, 2005). Essa variedade morfológica aumenta a
complexidade das informações presentes em laudos médicos, dificultando a aplicação de métodos e de ferramentas computacionais para a análise desses dados. Para amenizar a complexidade
dessas informações, podem ser aplicadas técnicas de lematização (lemmatization) com a finalidade 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 sua
forma canônica, denominada lema, que é a forma simplificada de um termo, como o singular
de um substantivo plural, a forma infinitiva de um verbo conjugado, o masculino do substantivo
feminino, entre outros. Assim, a lematização consiste em um processo de redução de termos
onde diferentes variações morfológicas de uma palavra são transformadas para um lema base
36
comum, reduzindo o número total de termos distintos (Chrupala, 2006; Jongejan and Dalianis, 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 em
que 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 tornam
canô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 lematizaçã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 verbos
e 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 substituir sufixos de verbos conjugados para o tempo passado que terminam com ado pelo sufixo
ar, transformando esse verbo para a sua forma infinitiva. Assim, uma regra pode englobar
um grande número de lemas, não sendo necessário listá-los explicitamente em um lista, como
ocorre em caso de lematizadores que utilizam DL (Branco and Silva, 2007). No entanto, para
cada RL pode haver exceções que devem ser tratadas de modo que evite as transformações
errôneas de termos, como na regra "ado"→ "ar", a qual é aplicada em verbos, pois, existem
palavras terminadas com o sufixo ado que não são verbos, tais como: reinado, gado, lado, entre
outros.
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 inflexional (Kanis and Skorkovská, 2010). No processo derivativo, os termos são normalizados de
acordo 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 conforme outras classes morfológicas, como o termo diagnosticadamente.
Nesse contexto, sistemas computacionais avançados de processamento textos que aplicam
a técnica de lematização para transformação de dados utilizam RL construídas manualmente
(lematizador manual) ou automaticamente (lematizador automático). O lematizador manual
utiliza DL e/ou RL construídos manualmente para processamento de termos. O lematizador
37
automático constrói RL e/ou DL automaticamente durante o treinamento do lematizador a partir
de conjuntos de dados, que são representados em pares (palavra não simplificada – lema). Nessa
abordagem, a construção de RL é baseada na busca de maiores sub-palavras comuns em termos
não canônicos e lemas (Jongejan and Dalianis, 2009).
Assim como stemming, na literatura também foram propostas várias abordagens para a
lematização de palavras escritas em diversos idiomas. Por exemplo, em Juršič, Mozetič and Lavrač (2007) é apresentado um sistema denominado LemmaGen para a construção automática de
lematizadores, que foi aplicado em conjuntos de termos escritos em idiomas como alemão, búlgaro, 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 denominado
Ripple Down Rule (RDR) (Plisson, Lavrac, Mladenic and Erjavec, 2008), que tem a finalidade
de construir RL automaticamente a partir do processamento de textos. Após a elaboração do
conjunto de RL, novas regras podem ser adicionados ao sistema na medida em que novos exemplos de termos são avaliados.
Em outro trabalho, foi proposto um algoritmo de lematização baseado em regras para processamento de termos nominais escritos no idioma português utilizando listas com quantidade
mínima de palavras (Branco and Silva, 2007). Esse algoritmo é baseado no método proposto
por Porter (1997), sendo que ao invés de remover os sufixos presentes nos termos, os mesmos
são substituídos por outros sufixos definidos nas RL. Também, nesse algoritmo é utilizado um
conjunto de regras para desfazer mudanças nas palavras em casos de exceções para a aplicação
de 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 possibilitar a manutenção da semântica dos termos processados (Korenius, Laurikkala, Järvelin and
Juhola, 2004).
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 conjunto
com especialistas do domínio e utilizados para especificar os atributos e seus possíveis valores
que irão compor a base de dados (tabela atributo-valor) e serão aplicados para a representação
de padrões relevantes que se encontram em laudos textuais, bem como são elaboradas as RM
que serão aplicadas com a finalidade de mapear esses padrões para uma base de dados. Os
atributos e as RM são representados por intermédio de uma ontologia, que é uma estrutura de
dados 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 a
descrição e a classificação de termos presentes em laudos textuais médicos, bem como a repre-
38
sentação dos atributos da tabela atributo-valor e das RM. Essas regras definem as combinações
de termos para o preenchimento de cada atributo com valores definidos como possíveis para o
preenchimento de cada atributo.
Conforme mencionado, as RM geralmente são estruturadas para interpretar sentenças com
os 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 outras
informações importantes à respeito de um determinado local;
• Subcaracterística: representa as informações complementares de uma determinada característica.
Em laudos médicos, cada frase pode ser organizada na sequência local-característica ou
local-característica-subcaracterística. Por exemplo, na frase esôfago com úlcera de 8 mm, o
esô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 de
atributos e de RM:
• Thing: é a classe principal da maioria das ontologias e corresponde a todos os indivíduos
representados por essas estruturas;
• Atributo: é a classe responsável por agrupar todos os atributos de uma tabela atributovalor e é dividida em duas subclasses:
– Nome_atributo: é a classe que representa o nome do atributo;
– Tipo_atributo: indica os valores possíveis para o atributo.
• Termo: constitui os termos que podem ser encontrados em laudos textuais e é composta
por 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. Essa
classe é divida em duas classes:
∗ Característica: equivale às descrições sobre uma região;
∗ Subcaracterística: representa as informações complementares sobre uma característica.
Geralmente, os atributos representados por uma ontologia são nomeados de modo que seja
facilitada a identificação dos mesmos, adotando padrões de nomenclatura local_característica,
39
Figura 3.10: Exemplo de esquema de ontologia para mapeamento de laudos médicos.
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
local-característica-subcaracterística pode gerar no mínimo dois atributos. Por exemplo, na
frase esôfago com úlcera de 8 mm, podem ser definidos dois atributos para compor a tabela
atributo-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 é aplicada
sequencialmente na seguinte forma: primeiramente é selecionado o conjunto de laudos a ser
processado, podendo opcionalmente ser escolhido o conjunto utilizado na primeira fase. Em
seguida, as técnicas selecionadas para o processamento de textos como normalização, remoção
de stopwords, stemming e/ou padronização são aplicadas nesses laudos com a finalidade de
40
uniformizá-los, reduzindo a complexidade de suas sentenças. Após, em cada laudo é aplicado o
algoritmo 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, Maletzke, Machado, Voltolini, Coy, Fagundes and Wu (2013)).
Essa etapa tem como propósito preencher a tabela atributo-valor, definida anteriormente
com 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 a
escolha do conjunto de laudos a serem processados e o uso das estruturas definidas na etapa
anterior, como a stoplist e o AP para a uniformização dos laudos e a ontologia para a realização
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 representadas em uma ontologia. Assim, para cada laudo é gerado um registro com valores de cada
atributo presente na ontologia. Esses registros compõem a tabela atributo-valor, representando
o 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 etapas (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 do
método de mapeamento é dividido em um conjunto de sentenças;
2. Processamento das sentenças: cada termo presente nas sentenças é processado e vinculado a uma propriedade de acordo com a sua classificação na ontologia. Caso um termo
41
não seja identificado na ontologia, o mesmo é incluído em uma lista de termos não processados. Após, as palavras identificadas são associadas com as RM, definindo quais são
os 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 (”-").
3.5
Considerações Finais
O PMLM apresenta grande importância para a padronização e a representação de laudos
textuais no contexto de aplicação da Mineração de Dados (MD) para a extração de padrões
relevantes. Isso pode contribuir com a geração de novos conhecimentos, tais como a descoberta
de fatores que aumentam o risco de enfermidades, a criação de novas técnicas para o diagnóstico
de doenças, o desenvolvimento de novos medicamentos, a construção de modelos preditivos
para auxiliar especialistas da área médica em tomadas de decisão, entre outros.
Esse processo foi avaliado em trabalhos anteriores e apresentaram resultados considerados 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 para
a aplicação do método de mapeamento de laudos médicos em relação ao DC. É possível observar essa característica na Figura 3.10, na qual no DC a relação local-característica e/ou
local-característica-subcaracterística, bem como os atributos e seus respectivos valores são representados em uma única classe, o que se caracteriza como uma estrutura de dados com pouca
flexibilidade 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 a
estrutura 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 conhecimento é amenizado, pois cada tipo de termo é descrito por uma classe específica, facilitando o
reaproveitamento dessa estrutura para a elaboração de RM em diversos formatos.
No entanto, como apresentado anteriormente, todas as técnicas utilizadas no PMLM devem ser executadas manualmente e separadamente em todas as suas etapas, dificultando, principalmente, o seu uso por profissionais que não são da área computacional ou que não conheçam
detalhadamente o processo. O desenvolvimento de um sistema computacional para automatizar
e facilitar o uso do processo é portanto de grande valia.
42
Para a construção de um sistema confiável e com qualidade, é necessária a aplicação de
abordagens sistemáticas e disciplinadas de engenharia de software. Sendo assim, no Capítulo 4
são apresentados métodos de engenharia de software que visam orientar na construção de sistemas computacionais.
Capítulo 4
Desenvolvimento de Sistemas
Computacionais
4.1
Considerações Iniciais
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 novas
tecnologias. O SC está embutido em diferentes domínios, como médico, militar, transporte, comunicação, industrial, entretenimento, entre outros. Esses sistemas são produtos resultantes da
aplicaçã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 produção de software, focada na sua especificação, desenvolvimento e manutenção, definição e
aplicação de tecnologias e métodos adequados, gerenciamento de projetos e outras atividades
com a finalidade de garantir a organização, a produtividade e a qualidade na construção do
software (Sommerville, 2009).
O processo de desenvolvimento de software pode ser realizado por meio de vários modelos de processos que são aplicados de acordo com o tamanho da equipe de desenvolvimento, a
complexidade dos requisitos, o nível de risco do projeto e o domínio do problema a ser resolvido (Pfleeger, 2004).
Sendo assim, na Seção 4.2 são apresentados alguns conceitos e um exemplo de processo
de software. Após, são apresentadas as principais tarefas dos processos de software, como a
atividade de levantamento de requisitos (Seção 4.3). Na Seção 4.4 é apresentada a atividade de
projeto de SC. Na Seção 4.5 é abordada a atividade de codificação dos requisitos de software e
na Seção 4.6 são descritas algumas técnicas de testes de SC.
1
Neste 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 um
conjunto 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 do
processo de software caracterizada como um grupo de tarefas imprescindíveis para atingir um
objetivo amplo, como o planejamento da construção do programa. A tarefa é concentrada em
um objetivo pequeno e bem definido, por exemplo, a escolha de tecnologias para o desenvolvimento 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 para
identificar e compreender as necessidades dos futuros usuários por meio do levantamento
de 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 compreensã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 planejamento e nos modelos construídos, bem como são elaborados testes com o objetivo de
identificar 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 qual
cada iteração do processo resulta em um incremento do SC. Sendo assim, é importante ressaltar
que todos processos de software tem como entrada a definição das necessidades do usuário e
como saída uma versão do programa. O ciclo de desenvolvimento de software é comumente
repetido várias vezes, na medida em que o requisitos são incrementados, atualizados ou removidos (Pfleeger, 2004).
Para oferecer suporte às atividades do processo de software no decorrer da execução do
projeto, podem ser realizadas algumas atividades de apoio (Pressman, 2011), como:
• Controle e acompanhamento do projeto, no qual é avaliada a evolução do desenvolvimento do projeto, tomando medidas necessárias para o cumprimento do cronograma de
execução;
• Administração de riscos, em que são avaliados possíveis problemas que possam afetar no
resultado e/ou na qualidade do sistema;
45
• Garantia de qualidade, que conduz tarefas para garantir o desenvolvimento de software
que 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 evitar problemas na aplicação das atividades seguintes;
• Medição, que determina critérios para medir a qualidade e o progresso do SC, podendo
ser utilizadas nas demais atividades do processo de software;
• Gerenciamento de configuração, que tem o propósito de controlar os efeitos das mudanças
ao longo da aplicação do processo;
• Gerenciamento da reusabilidade, em que são definidos os critérios para o reuso dos artefatos e estabelecidos mecanismos para o uso dos componentes reutilizáveis;
• Produção de artefatos, que define as tarefas necessárias para elaborar artefatos, como
modelos, 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ção
em todos projetos de sistemas. Nesse sentido, os processos de software podem ser aprimorados
mediante padronizações dos mesmos, que são denominados modelos de processo, os quais
são representações abstratas do processo de software, representando-o em uma determinada
perspectiva (Sommerville, 2009). O objetivo de um modelo processo de software é guiar, de
modo sistemático, a aplicação das tarefas fundamentais para garantir a construção de um sistema
que atenda aos objetivos do projeto e as necessidades dos usuários por intermédio da definição
de um conjunto de tarefas a serem executadas, a entrada, a saída, as condições, a sequência e o
fluxo de cada tarefa (Tsui and Karam, 2013).
Assim, na literatura foram propostos vários modelos de processo de software, os quais
são utilizados de acordo com o tipo e a complexidade dos requisitos, como o modelo ágil de
desenvolvimento por prototipagem, que é apresentado seguir.
Modelo de Desenvolvimento de Sistemas por Prototipagem
Prototipagem é uma abordagem da engenharia de software para construção de soluções
computacionais de modo ágil. Esse modelo se apresenta adequado quando os requisitos são
considerados complexos e há a necessidade de maior participação dos usuários no processo de
desenvolvimento do sistema (Pressman, 2011). Na Figura 4.1 é ilustrado o ciclo do modelo de
desenvolvimento por prototipagem, que é constituído de cinco etapas:
1. Comunicação: é realizado o levantamento de requisitos por meio de reuniões em conjunto com os interessados no projeto para definir as funcionalidades que deverão ser exercidas pelo novo SC;
46
2. Plano rápido: os requisitos levantados na etapa anterior são analisados e estudados com
a 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 dos
requisitos e são estudados os métodos e tecnologias existentes que podem prover apoio
no desenvolvimento do software;
3. Modelagem: a partir das especificações levantadas nas etapas anteriores, são criados
modelos com a finalidade de facilitar a compreensão dos requisitos;
4. Construção do protótipo: o software é implementado por meio de uma linguagem de
programação apoiado por um ambiente de desenvolvimento e de outras ferramentas computacionais. Durante e após a codificação, são realizados testes no sistema com a finalidade de identificar e corrigir erros que podem afetar o desempenho do processamento, a
integridade e a segurança dos dados;
5. Avaliação e feedback: o SC é entregue aos usuários finais, os quais verificarão se foram
atendidos satisfatoriamente os requisitos levantados. Após a avaliação, os usuários fornecem feedback com sugestões definindo os requisitos que devem ser incluídos, removidos
e/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 conjunto simples de requisitos. No decorrer da execução do ciclo de desenvolvimento, os requisitos
são ajustados e detalhados. O planejamento para a construção da solução computacional é aprimorado por meio do desenvolvimento de modelos. Ao final, o SC é implementado utilizando
uma linguagem de programação e após a realização de testes, o mesmo é entregue aos usuários
para avaliação e validação. Assim, cada atividade do ciclo pode ser repetida inúmeras vezes na
medida em que novos requisitos são levantados e erros são encontrados (Pfleeger, 2004).
4.3
Levantamento de Requisitos
O levantamento de requisitos é realizado por meio de reuniões em conjunto com usuários
e/ou outros interessados no projeto com o objetivo de estabelecer as necessidades que devem ser
47
atendidas em um SC (Pfleeger, 2004). Essa fase de construção de software ocorre no início do
ciclo de desenvolvimento, podendo ser repetidas mais de uma vez, até atender satisfatoriamente
as 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 programa
deve oferecer, as quais são documentadas e revisadas no decorrer do desenvolvimento do projeto do SC (Sommerville, 2009). Essas descrições podem ser do tipo explícito, normativo ou
implícito (Filho, 2009). Os requisitos explícitos são descritos, em linguagem natural, em documentos textuais.
Os requisitos normativos descrevem as aplicações que devem seguir normas impostas por
leis, padrões, regras, entre outros. Os requisitos implícitos são as funções esperadas por clientes
que 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 e
não-funcionais (Pressman, 2011; Sommerville, 2009). Os requisitos funcionais são relacionados diretamente com as funcionalidades do sistema, isto é, definem a entrada de dados, o
comportamento do SC e a saída de dados. Esses requisitos incluem o processamento de dados, a realização de cálculos, entre outras aplicabilidades que o programa deverá atender. Os
requisitos não-funcionais descrevem as restrições de uso do software, tais como segurança, desempenho, tecnologias auxiliares, entre outros.
Nesse contexto, o final dessa fase resulta em um conjunto de requisitos. Entretanto, no decorrer da construção do software podem haver mudanças e alternativas na medida em que ocorrem diálogos com os usuários durante todas as etapas de cada ciclo de desenvolvimento. Com
isso, é 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 deficiente
pode 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ão
analisados e estudados detalhadamente com a finalidade de verificar a viabilidade tecnológica e
econômica para o desenvolvimento de uma solução computacional que atenda as especificações
desses requisitos (Pressman, 2011). Caso seja viável a construção, é iniciada a elaboração do
projeto do SC, bem como são definidas as tecnologias necessárias para esse fim.
O projeto de software tem o objetivo de traduzir os requisitos para documentos em formatos textuais e/ou gráficos, definindo como o sistema deve ser desenvolvido. Assim, são
definidas as tarefas que serão desempenhadas pelo programa, os riscos possíveis do desenvolvimento do projeto, a arquitetura do SC, os elementos da interface, os recursos necessários
para a implementação da solução computacional, o cronograma de execução do trabalho, entre
48
outras (Braude, 2005). Para melhor descrição dos requisitos do programa, cinco modelos de
projeto podem ser aplicados simultaneamente (Pressman, 2011):
• Projeto de dados/classes: definição de modelos de dados, também denominado estrutura
de 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 as
especificações levantadas anteriormente;
• Projeto de interface: tem a finalidade de determinar o modo de interação da solução
computacional 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 em
uma interface que executa todas as operações desses componentes;
• Projeto em nível de implantação: determina os recursos tecnológicos necessários para
a implantação do sistema, como o ambiente computacional físico e os subsistemas que
irão interagir com o novo software.
Nesse contexto, o gerenciamento de projetos consiste em uma tarefa essencial para a
construção de software e tem o propósito de assegurar que essa tarefa seja realizada corretamente. Para o gerenciamento de projetos de sistemas, são comumente executadas as seguintes
atividades: preparação da proposta; planejamento do desenvolvimento; elaboração do cronograma; estimativa de custos e de riscos; monitoração e revisões de projeto; seleção e avaliação
de 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.
Figura 4.2: Processo de gerenciamento de projetos (Modificado de Tsui and Karam (2013)).
49
Na fase de planejamento, são determinados os resultados esperados do projeto, o cronograma de execução, os recursos necessários, as metas a serem alcançadas, as medidas de
qualidade e os riscos do projeto. Na fase de organização, são definidos os mecanismos para
o monitoramento das tarefas e do cronograma, os recursos imprescindíveis para o desenvolvimento 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 do
projeto para verificar se a construção do mesmo está progredindo como planejado. Essa fase
é realizada por meio da coleta de informações do projeto, da análise dos dados coletados e da
apresentaçã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 problemas
encontrados durante a elaboração do software, entre outros.
Também, outras técnicas e ferramentas podem ser utilizadas para o desenvolvimento de
projetos de software, como a Unified Modeling Language (UML) 2 , que é uma linguagem padrão de modelagem, de especificação e de documentação de SC, comumente utilizada para esse
fim. 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 ou
minimizar 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 funcional (Tsui and Karam, 2013). Nesse sentido, na etapa de implementação, os requisitos e os
modelos computacionais são codificados por meio de uma linguagem de programação com suporte de um ambiente de desenvolvimento (Pressman, 2011). Para essa tarefa, existem várias
linguagens de programação que são utilizadas para construção de programas de acordo com as
necessidades dos usuários, como Java 3 , Ruby 4 , Python 5 , entre outras. A implementação de
sistemas pode ser facilitada com o uso de ambientes de desenvolvimento e de outras ferramentas
computacionais, auxiliando e automatizando a tarefa de geração de código-fonte.
Durante a etapa de construção do programa, os desenvolvedores devem escrever o códigofonte de forma simples e compreensível, adotando padrões de programação das linguagens utilizadas 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 considerados, tais como: conjuntos de algoritmos que devem ser utilizados para atender os requisitos do
usuário; entrada e saída de dados para o uso dos algoritmos; estruturas de controle para coordenar o fluxo de dados do sistema; estrutura de dados para organizar os algoritmos e simplificar a
2
http://www.uml.org/
http://www.java.net/
4
http://www.ruby-lang.org/pt/?
5
http://www.python.org/
3
50
construção do SC; revisões do código-fonte com a finalidade de aprimorá-lo; e reutilização de
códigos-fonte desenvolvidos em outros projetos para facilitar a elaboração da solução computacional. Também, o código-fonte dever ser documentado para facilitar a compreensão da lógica
interna 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 desenvolvedores devem considerar as seguintes características:
• Legibilidade: o código-fonte deve ser escrito de forma que facilite a sua leitura e compreensã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 seja
realizada o mais rápido possível;
• Rastreabilidade: o código do sistema deve corresponder a um elemento de design, ou
seja, garantir que o software seja desenvolvido corretamente;
• Exatidão: o código-fonte deve ser escrito para fazer exatamente as tarefas para o qual foi
construído;
• Integralidade: todos os requisitos devem ser atendidos satisfatoriamente.
Entretanto, uma codificação mal realizada e mal documentada pode implicar na geração
de um software deficiente, mesmo funcionando corretamente, dificultando a realização de alterações, o reuso dos componentes de software em outros projetos e a compreensão da lógica
interna 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 desempenhar as funcionalidades do sistema com o propósito de identificar erros que influenciam no
funcionamento correto dos algoritmos, tal como na integridade e na segurança dos dados processados pelo programa (Pressman, 2011).
A realização de testes em SC consiste em uma tarefa complexa e altamente custosa, representando cerca de 50% a 80% do custo total do desenvolvimento do projeto. Os testes de
software são utilizados de forma controlada para verificar a concordância de suas funcionalidades em relação às especificações levantadas e expôr as suas falhas de forma antecipada à sua
entrega ao usuário final (Sommerville, 2009).
Nesse contexto, foram propostas várias abordagens para a avaliação de sistemas, as quais
são divididas em testes dos tipos caixa-branca, caixa-preta e e caixa-cinza. O teste caixa-branca,
51
também denominado teste estrutural ou orientado à lógica, tem o objetivo de avaliar a lógica
interna dos componentes de um determinado SC. O teste caixa-preta, igualmente denominado
teste funcional, orientado a dados ou a entrada/saída, tem a finalidade de avaliar o comportamento do programa em relação à entrada de dados e são conduzidas por meio de uma interface
gráfica. O teste caixa-cinza consiste na combinação das técnicas caixa-branca e caixa-preta para
a avaliação do SC (Myers, Badgett, Sandler and Thomas, 2004; Sommerville, 2009; Tsui and
Karam, 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 Figura 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 abordagem é focada na lógica interna do processamento e nas estruturas de dados que envolvem um
componente 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 do
sistema (Pressman, 2011).
O teste de integração é uma técnica utilizada para identificar falhas de agregação dos
membros de SC testados anteriormente, isto é, os componentes são combinados e avaliados
em grupo. Esse teste tem o propósito de avaliar os requisitos funcionais, o desempenho e a
modelagem da solução computacional para descobrir erros relacionados com a interface. Para
52
isso, foram propostas várias abordagens, das quais se destacam as técnicas bottom-up e topdown (Pfleeger, 2004). O teste bottom-up é uma abordagem incremental que avalia os elementos
do 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 único
grupo. O teste top-down é o inverso de bottom-up, ou seja, a avaliação é iniciada com todos os
componentes integrados em um único grupo, o qual é fragmentado em pequenos grupos até que
todas as falhas identificadas serem isoladas.
O teste de sistema é aplicado para avaliar o SC como um todo por meio da execução de
todas as suas funcionalidades, sob o ponto de vista do usuário final. Esse tipo de teste engloba
diversos 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 maneiras
para 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 o
propósito de garantir que os dados dos usuários estejam protegidos de acessos indevidos; teste
por estresse, que avalia o SC em situações anormais, como a demanda de recursos em termos de
quantidade, 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 as
etapas de testes; e teste de disponibilização, que examina a operação do software em diferentes
tipos de plataformas.
O teste de aceitação é focado nas atividades que serão desempenhadas pelo usuário. Para
isso, são definidos os critérios a serem considerados na validação por intermédio de um plano
de avaliação que define os tipos de testes que serão conduzidos com o intuito de garantir que
todos os requisitos sejam atendidos satisfatoriamente, todas as características comportamentais
anormais sejam identificadas e que todos os dados originados pelo sistema sejam confiáveis e
apresentados adequadamente. Nesse sentido, os testes de aceitação são realizados inicialmente
por desenvolvedores em ambiente controlado e são caracterizados como testes alpha. Após a
realização dos testes e correção dos erros identificados pelos desenvolvedores, o SC é entregue
aos usuários finais para avaliarem as suas funcionalidades com a finalidade de identificar erros
que não foram identificados pelos desenvolvedores. Essa avaliação é também conhecida como
teste beta (Sommerville, 2009).
Desse modo, os testes são realizados enquanto os erros forem encontrados e solucionados. 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 funcionamento da solução computacional, como o treinamento dos usuários e a aquisição de hardware
e software (Laudon and Laudon, 2007).
53
4.7
Considerações Finais
Para a construção de SC, o processo de software apresenta-se como uma abordagem de
grande importância para o sucesso do projeto, o qual é uma ferramenta relevante para o desenvolvimento de uma solução computacional de qualidade, pois possibilita a organização das
atividades 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 estipulado, é necessário que cada atividade do processo seja realizada cuidadosamente, desde a
iniciação até o final do projeto, de modo que garanta a entrega de um produto de qualidade
satisfatória e que facilite a realização de manutenções futuras. Outro recurso importante para
a construção de programas é o uso da UML, que facilita a compreensão e o registro exato dos
requisitos por meio da elaboração de modelos e de diagramas.
Neste trabalho foi utilizado o modelo ágil de desenvolvimento de sistemas por prototipagem devido à complexidade dos requisitos e a necessidade do envolvimento de especialistas
do 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). No
Capítulo 5 são apresentadas as tecnologias que foram utilizadas para o desenvolvimento do SCC
para a automatização do PMLM apresentado neste trabalho.
54
Capítulo 5
Ferramentas e Tecnologias
5.1
Considerações Iniciais
Uma área tecnológica em crescente evolução é o de desenvolvimento de sistemas web
devido à 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 para
utilizar um sistema web. Outra vantagem é a não ocupação de espaço no disco ou em outro
dispositivo de armazenamento do usuário. Com essas características, o usuário pode acessar o
sistema por meio de computadores, sendo necessário apenas que um navegador web como o
c , ou o Google Chrome 3 esteja instalado na
Mozila Firefox 1 , o Opera 2 , o Internet Explorer
máquina do usuário e que haja acesso à Internet.
Para a construção de sistemas web é necessário o uso combinado de diversos tipos de
tecnologias, tais como: linguagens de programação, de marcação e de estilo; ambientes de
desenvolvimento; frameworks; e infraestrutura física, como servidores, redes de computadores,
entre outros. Para o uso dessas tecnologias, é imprescindível o conhecimento técnico por parte
dos desenvolvedores para possibilitar a construção de sistemas web eficientes e que atendam às
especificações de seus usuários, bem como deve ser considerado o uso de diferentes tipos de
navegadores web, pois cada navegador possui características específicas que podem influenciar
no funcionamento correto desses sistemas (Jung, 2012).
Desse modo, neste capítulo são apresentadas as principais ferramentas e as tecnologias
utilizadas 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 a
utilização do método.
Nas Seções 5.2 e 5.3 são apresentadas algumas características das linguagens de programação Java e Ruby, respectivamente. Na Seção 5.4 é apresentado o principal framework da
1
www.mozilla.org/pt-BR/
www.opera.com/pt-br
3
www.google.com/intl/pt-BR/chrome/browser/
2
55
56
linguagem Ruby que é aplicado na construção de sistemas web. Na Seção 5.5 é descrito um dos
ambientes de desenvolvimento de softwares mais utilizados na atualidade por desenvolvedores
de software. Na Seção 5.6 é apresentada a linguagem de programação comumente aplicada na
elaboração de métodos de processamento de textos denominada Perl. Nas Seções 5.7 e 5.3 são
descritas as linguagens de marcação HTML e XML. Na Seção 5.9 é apresentada a linguagem
de estilo denominada CSS, que é comumente utilizada para a modelagem de layout de documentos 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 web
com usuários.
5.2
Linguagem de Programação Java
Java é uma das linguagens de programação mais utilizadas para o desenvolvimento de
Sistemas Computacionais (SC), devido à ampla variedade de recursos disponíveis (Deitel and
Deitel, 2010). Essa linguagem, foi construída na década de 90 por desenvolvedores liderados
por James Gosling, na empresa Sun Microsystems 4 .
Diferentemente de outras linguagens, o código-fonte escrito em Java é traduzido para um
formato intermediário de código, denominado bytecode, que é interpretado por uma Máquina
Virtual Java (MVJ), a qual tem como finalidade converter os bytecodes para um código executável por máquinas, bem como gerenciar aplicações desenvolvidas na linguagem Java. Com a
MVJ, os softwares escritos em Java podem ser executados em qualquer sistema operacional que
contém uma MVJ instalada (Lindholm, Yellin, Bracha and Buckley, 2013).
Assim, nessa linguagem podem ser destacadas algumas características: paradigma de
programação orientado a objetos; independência de plataforma, isto é, o software desenvolvido nessa linguagem pode ser executado em qualquer sistema operacional; extensa biblioteca
de ferramentas para auxiliar na construção de sistemas, recurso necessário para projetos que
apresentam requisitos complexos para o seu desenvolvimento; simplicidade e eficiência para a
construção de softwares, sem a necessidade do gerenciamento de memória por código, reduzindo possibilidades de erros de programação; desalocação automática de memória por meio
do 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 desenvolvidas
várias ferramentas e bibliotecas. Na Sun Microsytems, foi criado o pacote de ferramentas denominado Java Development Kit (JDK), que contém bibliotecas e outros recursos necessários para
a escrita de código-fonte de softwares. Também, foi desenvolvido o Java Runtime Environment
(JRE), o qual é uma biblioteca que inclui a MVJ e outros recursos para a execução de sistemas
Java (Gosling, Joy, Steele and Bracha, 2005).
4
http://www.oracle.com/us/sun/index.html
57
Foram construídos também diversos ambientes de desenvolvimento, denominados Integrated Development Environment (IDE), que têm o propósito de reunir os principais recursos
para a construção de softwares em Java, tais como JDK, JRE, entre outras ferramentas e bibliotecas (Boudreau, Glick and Spurlin, 2002). Um dos IDE mais populares entre os desenvolvedores
para 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 produtividade 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 e
mais orientada a objetos do que a linguagem Python 6 , combinando a programação funcional
com a programação imperativa. Assim, a linguagem Ruby consiste na combinação das linguagens Perl, Smalltalk, Eiffel, Ada e Lisp. Atualmente, essa linguagem se encontra na versão
c , GNU/Linux, Mac OS, Solaris,
2.0 e é disponível para diversas plataformas, como Windows
entre outros (Metz, 2012).
A linguagem Ruby apresenta as seguintes características: todos os elementos utilizados
são considerados objetos, incluindo números e outros tipos de dados primitivos; o gerenciamento de memória é realizado de modo automático; a linguagem é dinâmica e forte, permitindo
o uso de variáveis sem a necessidade de declará-las ou pré-determiná-las; possui sintaxe intuitiva, o que facilita a compreensão do código-fonte; utiliza caracteres especiais para determinar
a condição de uma determinada variável, como "$" e "@", os quais indicam que as variáveis são
globais e de instância, respectivamente; e a possibilidade de desenvolvimento de ferramentas e
de disponibilizá-las em formato padrão de pacote de código, também denominado gem (Carlson
and Richardson, 2006).
Também, para a linguagem Ruby existem várias implementações alternativas, como o
JRuby 7 , que foi escrito na linguagem de programação Java para funcionar em MVJ e possibilitar o uso dos recursos dessa linguagem sem a necessidade da instalação de gems e configuração
do computador para viabilizar o uso de ferramentas e/ou outros recursos desenvolvidos nessa
linguagem por sistemas construídos em Ruby. JRuby foi desenvolvido em 2001 por Jan Arne
Petersen e atualmente se encontra na versão 1.7.4, o qual oferece suporte para Ruby 2.0. O
JRuby possibilita o reconhecimento de código escrito em Java e a utilização de classes da plataforma Java no interpretador Ruby (Nutter, Enebo, Sieger, Bini and Dees, 2011).
É importante ressaltar que a linguagem Ruby obteve maior aceitação no mercado devido,
5
https://netbeans.org/
http://www.python.org/
7
http://jruby.org/
6
58
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 que
tem 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 ano
de 2004 por David Heinemeier Hansson, mas os direitos para o compartilhamento do projeto
foram 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), o
qual tem o objetivo de organizar o código-fonte do sistema web em três camadas: model, que
determina e gerencia as informações processadas pelo SC; view, que apresenta as informações
do model de forma que seja útil ao usuário por intermédio de uma interface; e controller, que
tem 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, em
que as setas contínuas representam o relacionamento direto entre os componentes MVC e a seta
tracejada 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):
• Não se repita (Don’t Repeat Yourself - DRY): determina mecanismos para evitar a
necessidade de repetição do código em diversas partes do sistema;
8
http://www.rubyonrails.com.br/
59
• Convenção sobre configuração (convention over configuration): define padrões para
a construção de sistemas com a finalidade de reduzir a necessidade de elaborar configurações para o funcionamento do mesmo, possibilitando que o desenvolvedor se preocupe
apenas 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 as
tarefas 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 a
complexidade deve ser desconsiderada ou reduzida;
• Você não vai precisar disso (you ain’t gonna need it): define que nenhuma funcionalidade 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 desenvolvimento
pode ser repetido várias vezes e para cada repetição de ciclo é adicionado pelo menos
uma funcionalidade;
• Desenvolva menos (build less): resultado de todos os princípios e práticas apresentados
anteriormente, possibilita a redução do processo de construção de sistemas.
Nesse sentido, RoR oferece diversos mecanismos para facilitar a construção de SC por
meio da automatização de várias tarefas, como o comando generate, que é aplicado para gerar
componentes do sistema. Neste comando, podem ser incluídas outras instruções para a geração
de componentes no Padrão MVC, como o scaffold, que tem o intuito de gerar uma parte do
sistema no padrão MVC com toda a estrutura CRUD (Create, Read, Update, Delete), que são
as 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 diversos
bancos 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 a
finalidade de agregar funcionalidades semelhantes aos disponíveis nos IDE populares da linguagem Delphi 10 , os quais eram atrativos por serem fáceis de utilizar e também por apresentarem
recursos gráficos para facilitar o desenvolvimento de softwares. Em 1997, foi desenvolvida
9
10
http://www.xelfi.cz/
http://c2.com/cgi/wiki?BorlandDelphi
60
a primeira versão comercial do IDE NetBeans, que foi comprada pela Sun Microsystems em
1999, 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 e
aumentar a produtividade do processo de construção de sistemas. Essa IDE pode ser utilizada em qualquer sistema operacional, pois foi desenvolvida em Java. Também, essa IDE
suporta qualquer linguagem de programação como o próprio Java, Python, Ruby, Perl, entre
outras (Boudreau, Glick and Spurlin, 2002; Kutler and Leonard, 2008). Assim, é possível a
construção de sistemas utilizando várias linguagens simultaneamente, isto é, dependendo da
complexidade dos requisitos, pode ser usada mais de uma linguagem em um único projeto de
software.
Essa IDE possui vários recursos, das quais se destacam: editor de código-fonte com vasta
gama de mecanismos para a construção de sistemas web e aplicações visuais para a elaboração
de interfaces gráficas; gerador automático de código; ferramentas para a criação de diagramas
UML; controle de versão, o qual tem como finalidade manter antigas versões dos arquivos em
uma base dados para facilitar a recuperação dos mesmos quando necessário; gerenciamento de
bases de dados; integração e/ou reuso de componentes; disponibilidade de servidores de sistemas para web; ferramentas de modelagem de interfaces gráficas; e suporte para a construção de
aplicaçõ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ção
multiplataforma que tem o intuito de facilitar o desenvolvimento de métodos e ferramentas
para o processamento de textos, de relatórios e de formulários textuais. Essa linguagem foi
desenvolvida por Larry Wall em 1987 com o objetivo de reunir as principais vantagens de
tecnologias 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 and
D’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
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 o
aprendizado do uso da linguagem por programadores (Wall, Christiansen and Schwartz, 2012).
11
http://www.perl.org/
http://www.gnu.org/software/sed/manual/sed.html
13
http://awk.freeshell.org/
14
http://www.open-std.org/JTC1/SC22/WG14/www/standards
15
http://tldp.org/LDP/abs/html/why-shell.html
12
61
A sintaxe do Perl é semelhante ao do C e possui uma ampla variedade de recursos para
realização de tarefas comuns, como a manipulação de arquivos. No código-fonte Perl, todas
as 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 pelo
caractere "@" 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 linguagem
gerenciam a memória automaticamente e possuem tipagem dinâmica, uma característica que
não exige a declaração de variáveis devido à capacidade de definição do tipo de dado dinamicamente 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 rapidamente; disponibilidade de comandos poderosos para processamento de textos; suporte à
programação estruturada e à orientada a objetos; disponibilidade para vários sistemas operacionais; facilidade de compreensão da documentação da linguagem; e viabilidade do uso de
Expressões Regulares (ER) (Schwartz, Phoenix and D’Foy, 20011).
Uma das características responsáveis pela popularização da linguagem Perl é a possibilidade do uso de ER, que tem a finalidade de identificar cadeias de caracteres com características
de interesse, tais como letras particulares, palavras ou padrões de caracteres (Wall, Christiansen
and Schwartz, 2012; Friedl, 2006). Essas expressões são escritas formalmente em uma linguagem que pode ser interpretada por determinados processadores de textos, os quais processam
ER por meio de casamento de padrões, que geralmente é realizado com suporte de caracteres especiais, denominados de metacaracteres (Friedl, 2006). Na Tabela 5.1, são apresentados alguns
exemplos de metacaracteres e os seus significados.
Tabela 5.1: Tabela de exemplos de metacaracteres utilizados em ER (Adaptado de Schwartz,
Phoenix and D’Foy (20011) e de Intentor (2010)).
Metacaractere
.
*
+
{n}
{n,m}
\
[]
()
ˆ
$
\n
\t
\d ou \D
\s ou \S
\w ou \W
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
Presença de um determinado caractere ou de um conjunto exatamente n vezes
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
Nova linha
Caractere de tabulação
Reconhecem apenas dígitos
Reconhecem apenas espaços em branco
Reconhecem qualquer caractere alfanumérico e o caractere underline ("_")
Por exemplo, na ER "ˆ \s*", são identificados todos os espaços em branco no início de
62
uma frase. Em Perl, uma ER é designada entre barras (/) e o casamento de padrões é realizado
por meio do operador lógico "=∼". Na expressão "$algo =∼ /ˆ \s+ / ", por exemplo, o resultado será verdadeiro (true) se a sentença analisada contém no mínimo um espaço em branco no
início de uma frase e o resultado será falso (false), caso contrário. Também, podem ser aplicadas 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 de
caracteres 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 expressão "$algo =∼ s / ER / P" elimina apenas uma ocorrência de "ER", sendo que pode haver a
necessidade de remover todas as ocorrências. Para isso, na expressão deve ser adicionada ao
final mais uma barra e um caractere que represente a operação de remoção de todas as ocorrências, acarretando na expressão "$algo =∼ s / ER / P / g", na qual "g" (global) é o caractere
que 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 utilizado
no 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 para
construção de páginas web que foi criada pelo físico Britânico Tim Berners-Lee com a finalidade de resolver um problema de comunicação e de disseminação de pesquisas entre ele e
seu grupo de pesquisadores. Nas primeiras versões dessa linguagem foram definidas regras
sintá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 BernersLee 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 aplicação do SGML. Após a publicação da versão 3.5 do HTML em 1997, foi iniciado pela Wide
World Web Consortium (W3C) 18 o desenvolvimento do XHTML 19 , que combina as funcionalidades das linguagens HTML e XML (eXtensible Markup Language) 20 com o propósito de
ser o sucessor da linguagem HTML. Em 2008, foi lançado a quinta versão do HTML, também
conhecido como HTML5, que é amplamente utilizado atualmente (Pilgrim, 2011; Lubbers, Albers and Dalim, 2013).
16
http://www.w3.org/html/
http://xml.coverpages.org/sgmlsyn/sgmlsyn.htmC6
18
http://www.w3.org/
19
http://www.w3.org/TR/xhtml1/
20
http://www.w3.org/XML/
17
63
Para a elaboração de documentos utilizando qualquer versão da linguagem HTML, são
utilizadas estruturas de marcação pré-definidas com instruções denominadas etiquetas, marcadores ou tags, que são representadas na forma <nome_do_marcador>. Uma tag contém o seu
respectivo nome e opcionalmente possui atributos, os quais são aplicados para alterar os resultados padrões de uma tag por intermédio de valores que definem essas mudanças. Um elemento
HTML geralmente contém uma tag de abertura, uma tag de encerramento e conteúdo. Uma
tag e abertura é representada na forma <Nome_Tag atributo=valor> e na mesma pode conter
inúmeros atributos. Uma tag de fechamento é representada na forma </Nome_Tag> e não comporta 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 ser
representado na forma <Nome_Tag att1=valor1 attN=valorN> Conteúdo </Nome_Tag> houver 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 and
Hyslop, 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 navegador web;
• <body>: determina o conteúdo principal da página web. Nessa tag, são comportados
outros 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 é denominado <!DOCTYPE html>, que é geralmente localizada na primeira linha de código do documento, antes das tags básicas. O Doctype tem o intuito de informar ao navegador web ou outros
sistemas e ferramentas qual especificação de código deve ser utilizada para a exibição do documento. É importante ressaltar que o Doctype não é uma tag HTML, mas sim uma instrução
interpretada pelo navegador web para informar sobre a versão do HTML em que o código foi
escrito (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 exemplos
de 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;
64
• <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ágina
web 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 tem
a 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 tabelas
e 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).
No entanto, para a construção de um sistema web, a linguagem HTML é utilizada apenas para a exibição do conteúdo. Para melhorar a visibilização de dados e a organização do
conteúdo, bem como tornar a página interativa com os usuários, é necessário o uso de outras
tecnologias para aprimorar o documento HTML, como uma linguagem de estilo para definir
como 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 representar tipos de dados e organizá-los hierarquicamente. O principal objetivo do XML é facilitar,
65
simplificar e generalizar o compartilhamento de informações por meio da Internet. Essa linguagem é o resultado de um projeto da W3C desenvolvido na década de 1990 que tinha o propósito
de desenvolver uma linguagem de marcação que combinasse a flexibilidade da SGML com a
simplicidade da HTML e que pudesse facilitar a comunicação entre sistemas construídos em
linguagens 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ário
de HTML, que tem um repertório limitado de tags. Também, essas linguagens foram desenvolvidas para atender as especificações de diferentes alvos, sendo que o XML é focado no
transporte e no armazenamento de dados e o HTML na exibição de dados. Outra diferença
entre 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 o
atributo version define a versão da linguagem e o encoding determina o modo de codificação de
caracteres (Harold, 1998; Deitel, 2012; Lubbers, Albers and Dalim, 2013).
Na Figura 5.3 é apresentado um exemplo de estrutura de documento XML para a representação de informações bibliográficas de trabalhos científicos.
Figura 5.3: Exemplo de estrutura de documento XML para a representação de documentos
científicos.
66
Desse modo, o uso da linguagem XML apresenta os seguintes benefícios: operações
de buscas mais eficientes; construção de aplicações flexíveis para a web; integração de dados
em formatos diferentes; facilidade na manipulação de dados; várias maneiras de visibilizar os
dados; fácil distribuição na Internet; facilidade na compreensão do conteúdo de documentos
representados nessa linguagem; baseado em textos simples; suporta o padrão representação de
caracteres Unicode 21 , possibilitando a elaboração de documentos com o conteúdo representado
em linguagens latinas; entre outros (Deitel, 2012).
5.9
Linguagem CSS
Cascading Style Sheets (CSS) 22 é uma linguagem de estilo utilizada para definir a formatação (design) da apresentação de documentos escritos mediante ao uso de linguagens de
marcação, como XML e HTML. O objetivo da linguagem CSS consiste em separar o layout do
conteúdo de documentos web. Hoje em dia, grande parte desses documentos utilizam CSS para
organizar, 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 apresentaram o projeto dessa linguagem para a W3C, que lançaram a recomendação oficial do CSS
Level 1 (CSS1) em 1996 e CSS2 no ano de 1998. Atualmente, a linguagem CSS está em sua
terceira versão (CSS3) e ainda se encontra em desenvolvimento (Meyer, 2009).
Essa linguagem possui uma sintaxe simples e utiliza palavras em inglês para especificar
os nomes de regras e de suas propriedades. Uma regra CSS é dividida em três partes, como o
identificador da regra (seletor), a propriedade do seletor e o valor de cada propriedade. Assim,
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 seletor 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 as
informações representadas pela tag <p> terão todos os seus caracteres apresentados na
cor vermelha e o parágrafo terá a cor de fundo verde;
• Classes: os seletores podem ser nomeados dinamicamente e aplicados em distintos elementos. 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 da
classe 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 a
21
22
http://www.unicode.org/
http://www.w3.org/Style/CSS/
67
cor 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 aplicada apenas uma única vez em qualquer tag HTML. O nome do seletor para esse tipo de
regra é 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 a
cor 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 do
atributo 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ção
de regras CSS dentro do próprio documento HTML; ou inserção de arquivo CSS externo por
meio da tag <link>, utilizando o atributo rel para determinar o tipo de documento aplicado e o
atributo 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 aprimorado
sem a necessidade da formatação de informações em arquivos HTML, ou seja, o layout da
página é separado da estrutura do arquivo HTML, tornando a página mais leve e viabilizando
o reuso do design em outras páginas web, ou seja, um arquivo CSS pode ser utilizado em toda
coleção de páginas. Também, o CSS possibilita a redução de tempo para o carregamento de
páginas web, pois com todas as regras de formatação em arquivos CSS, é reduzida a quantidade
de código dessas páginas, diminuindo o fluxo de dados a serem transmitidos e analisados pelos
navegadores web (Meyer, 2009).
5.10
Linguagem de Programação Javascript
Javascript 23 é uma linguagem de programação interpretada de característica orientada a
objetos e inspirada nas linguagens C, C++ e Java. Originalmente desenvolvida por Brendan
Eich da Netscape 24 , sob o nome de Mocha, foi mudado para LiveScript que foi lançado em sua
primeira versão em setembro de 1995. A mudança do nome LiveScript para Javascript ocorreu
no mesmo período em que a Netscape iniciou a utilização da tecnologia Java em seu navegador
web, em dezembro de 1995. Em 1996, Javascript foi submetida para o ECMA (European Computer Manufacturers Association) Internacional com a finalidade de torná-lo uma linguagem padrão industrial, resultando na versão padronizada denominada ECMAScript (Crockford, 2008).
Atualmente, Javascript é a linguagem mais utilizada para construção de componentes de
interfaces de sistemas web, sites, portais, entres outras ferramentas web. Essa linguagem é
geralmente aplicada no desenvolvimento de funcionalidades para a interação do sistema com
23
24
http://www.javascriptsource.com/
http://isp.netscape.com/
68
os usuários, tais como tratamento de eventos (clique com botões do mouse, pressionamento de
teclas, 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 linguagem
C e tipagem dinâmica, ou seja, não é necessária a declaração do tipo de dados. Também, Javascript é quase inteiramente baseada em objetos (orientação a objetos), possui programação
dirigida por eventos e é independente de plataforma (Crockford, 2008). Os códigos escritos
na linguagem Javascript são incluídos em arquivos HTML (páginas web), os quais são exibidos para os usuários por meio de um navegador web. Assim, é importante ressaltar que
a variabilidade de tipos de navegadores para o acesso às páginas web pode influenciar no
comportamento de funcionalidades escritas em Javascript, isto é, uma funcionalidade pode
gerar resultados diferentes para cada tipo de navegador (Flanagan, 2006). Esse tipo de problema pode ser solucionado ou amenizado com o uso simultâneo de métodos compatíveis com
os principais navegadores para a realização de uma determinada tarefa. Por exemplo, o comando document.selection.createRange().text é utilizado para a captura do texto selecionado
pelo usuário e funciona corretamente nos navegadores web Netscape e Internet Explorer, ao
contrário dos navegadores Opera, Firefox e Chrome, na quais devem ser usado o comando window.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 seja
executado no navegador correto.
Para facilitar a construção de aplicações em Javascript, podem ser utilizadas outras tecnologias, 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 estrutura, proposta por Douglas Crockford, é uma alternativa à linguagem XML para manipulação
de informações de páginas web (Ferguson and Heilmann, 2013). O DOM é uma linguagem
multiplataforma 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 bibliotecas de código-fonte, como o JQuery 27 , que oferece várias funcionalidades para manipulação
de informações (Crockford, 2008).
5.11
Considerações Finais
A escolha de ferramentas e tecnologias para auxiliar na construção de uma solução computacional se apresenta como uma abordagem essencial para o sucesso de um projeto de soft25
http://www.json.org/
http://www.w3.org/DOM/
27
http://jquery.com/
26
69
ware. Essas escolhas são baseadas nas características e na complexidade dos requisitos estabelecidos. Assim, são definidas as linguagens de programação, os frameworks e outros recursos
que 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 sistemas computacionais, bem como no SC para a automatização do PMLM. Para o método de
mapeamento, foi utilizada a linguagem de programação Perl para a implementação das técnicas
de processamento de texto devida a sua variabilidade de métodos que facilitam essa tarefa. A
linguagem de marcação XML é usada para representar a lista de stopwords e do Arquivo de
Padronização (AP). A linguagem de programação Java foi aplicada sob apoio do ambiente de
desenvolvimento NetBeans e outras ferramentas para a implementação do algoritmo de mapeamento 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 qualquer
lugar 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ários
para a aplicação de cada método de processamento de textos e a criação de estruturas como a
stoplist, o AP e a ontologia. Para a construção desse SC, foi utilizada a linguagem JRuby com o
suporte do framework RoR e de métodos e ferramentas desenvolvidas em Java e em Perl. Para
a elaboração de uma interface amigável, intuitiva e interativa ao usuário, foram utilizadas as
linguagens HTML, CSS e Javascript.
Desse modo, no Capítulo 6 é descrita detalhadamente a aplicação da abordagem de engenharia de software denominada método de desenvolvimento por prototipagem e o uso de ferramentas e tecnologias discutidas neste capítulo para a construção do SCC para a automatização
e a consolidação do PMLM.
70
Capítulo 6
Processo de Desenvolvimento do Sistema
Computacional Colaborativo
6.1
Considerações Iniciais
Neste trabalho, foi desenvolvido o Sistema Computacional Colaborativo (SCC) seguindo
os preceitos de Engenharia de Software conhecido como método de desenvolvimento de sistemas computacionais por prototipagem. Essa escolha foi realizada devido à complexidade das
especificações, bem como pela importância e indispensabilidade da participação de especialistas 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 Comunicação. Na Seção 6.3 são descritas as tarefas desempenhadas na etapa de Plano Rápido. Na
Seção 6.4 é apresentada a modelagem do SCC. Na Seção 6.5 é descrita a construção do sistema. 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écnicas de processamento de textos utilizadas nesse processo para a compreensão do funcionamento do método de mapeamento. Nesse estudo, foi observado que todas as técnicas utilizadas
no 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ão
conheçam detalhadamente o processo. Também, foi constatado que uma das técnicas utilizadas
no pré-processamento, denominada stemming, pode dificultar o entendimento de alguns termos e os resultados de sua aplicação podem ser interpretados pelos especialistas erroneamente,
como discutido no Capítulo 3.
71
72
Após o estudo direcionado ao PMLM, foram realizadas reuniões com especialistas do
domínio para o levantamento de requisitos para a construção do SCC com o propósito de reduzir
os 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 processamento de laudos textuais;
• Substituição da técnica de pré-processamento stemming pelo método de lematização, no
qual 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 o
uso do sistema, de modo que não seja necessária a instalação de programas adicionais e
a configuração específica do computador para a execução do SCC;
• Possibilidade do uso do sistema por qualquer computador com configuração mediana atuc Core i3) que tenha acesso
almente (por exemplo, computadores com processador Intel
à internet.
6.3
Etapa de Plano Rápido
Na etapa de Plano Rápido, os requisitos foram analisados com a finalidade de compreender o problema a ser resolvido para verificar se era viável o desenvolvimento de uma solução
computacional. Neste projeto, inicialmente foram realizadas análises conceituais e práticas sobre os métodos desenvolvidos na linguagem Perl com o intuito de esclarecer o funcionamento
do pré-processamento de laudos textuais. Assim, primeiramente foram estudados os aspectos
teóricos que abrangem essas técnicas, caracterizado como estudo conceitual. O estudo prático
foi conduzido de dois modos: simulado, no qual não foram executados os códigos dos métodos
por meio de um interpretador computacional, mas de forma manual para simular a execução
dos mesmos; e real, em que os códigos dos métodos são executados em um interpretador de
código Perl.
Também, foram estudados a técnica de pré-processamento aplicada na segunda fase do
PMLM e o método de mapeamento de laudos por ontologias, os quais foram codificados nas
linguagens Perl e Java, respectivamente. O pré-processamento consiste na seleção e na aplicaçã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-valor
por intermédio do método de mapeamento. Esses estudos foram conduzidos da mesma forma
que foi aplicada nos métodos de pré-processamento. Sendo assim, com esses estudos foi possível compreender as dificuldades que abrangem o uso do PMLM por profissionais que não sejam
da área de computacional ou que não conheçam detalhadamente o processo.
73
Após, foi iniciado o planejamento da solução computacional, bem como foram definidas
e analisadas as tecnologias que podem ser utilizadas para apoiar na construção de um SCC com
a 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 fase
do PMLM, com o intuito facilitar a compreensão das especificações para o seu desenvolvimento (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 conjuntos de laudos textuais que serão utilizados para a geração do CFU. Essa funcionalidade
deve 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 aplicar
as técnicas de processamento de textos do PMLM no conjunto de laudos médicos selecionados para a geração de CFU (Conjunto de Frases Únicas). Nessa funcionalidade deve
ser 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 e
o 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 auxiliar 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 quais
são representados por dois conjuntos, sendo um de termos a serem substituídos e outro
de termos substitutos. Do mesmo modo, deve ser possível carregar e gravar AP, tal como
aplicá-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 na
definição de elementos que serão representados por uma ontologia, como os atributos e
seus respectivos valores que constituirão a base de dados e as RM que serão utilizadas
para mapear o conhecimento presente em laudos textuais para essa base. Esses atributos
devem ser apresentados em uma lista e as suas respectivas RM devem ser exibidas no
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:
74
• Aplicação de Pré-Processamento: tem o objetivo de aplicar as técnicas de processamento de textos em um conjunto de laudos, que pode ser o que foi utilizado na primeira
fase 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 serem
aplicadas ao conjunto de laudos, a aplicação dessas técnicas a esses laudos e o download
do conjunto pré-processado;
• Realização de Mapeamento: tem o intuito de aplicar o método de mapeamento por
meio de uma ontologia para a transcrição do conjunto de laudos pré-processados e o
preenchimento de uma base de dados. Nessa funcionalidade deve ser possível a visibilização dos resultados por meio de uma tabela atributo-valor e de uma lista de termos
nã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 linguagem 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.
Figura 6.1: Diagrama de casos de uso do SCC.
75
Também, a partir da análise dos requisitos e de sua respectiva modelagem, foi elaborado um modelo arquitetural com o intuito de ilustrar a integração das técnicas aplicadas no
PMLM com o SCC e a sua respectiva interação com o usuários. Esse modelo é apresentado na
Figura 6.2 e é constituído pelos seguintes elementos:
• Cliente: é o componente do SCC utilizado pelos usuários para a aplicação do PMLM
automatizado 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 gerenciar os recursos computacionais disponíveis para a aplicação do PMLM automatizado
por 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 meio
de telas intuitivas e amigáveis ao usuário;
– Controlador de Recursos do Sistema (CRS) para gerenciar o acesso às funcionalidades 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, escritas
na linguagem Perl, em laudos textuais selecionados pelo usuário;
– Métodos Java (MJ) para controlar a execução de SP no sistema e a aplicação do
método de mapeamento. Também, esse componente é utilizado para gerenciar as
estruturas utilizadas pelo PMLM, como a stoplist, o AP, a ontologia e a base de
dados;
– 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 arquivos
necessários para a aplicação do PMLM, tal como gravar os seus respectivos resultados.
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-valor
podem 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 conjuntos de laudos e a construção de novas bases de dados.
6.5
Etapa de Construção
Após o planejamento e a modelagem da solução computacional, nessa etapa foi construído o SCC utilizando as ferramentas e as tecnologias apresentadas no Capítulo 5.
76
Figura 6.2: Modelo de arquitetura do SCC.
Nesse sentido, a principal linguagem de programação utilizada foi uma implementação
da linguagem Ruby denominada JRuby com o suporte do framework para o desenvolvimento
de 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
http://rubygems.org/gems/devise
1
na versão 3.0.2, que é
77
aplicada ao controle do acesso ao sistema por intermédio de login e senha, assim como para o
gerenciamento do cadastro de conta de usuários do sistema. Para prover suporte no armazenamento de dados dos cadastros de usuário, foi utilizado o sistema de gerenciamento de base de
dados 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 desenvolvidos
métodos utilizando a linguagem de programação Java apoiada pelo ambiente de desenvolvimento NetBeans 7.3 para a construção e o carregamento de estruturas utilizadas pelo PMLM e
a execução de técnicas de processamento de textos escritas na linguagem Perl por meio de um
interpretador JRuby. Esses métodos são apresentados a seguir:
• Gerenciador de CFU: controla a aplicação de técnicas de processamento de textos do
PMLM escritos em Perl para a geração de CFU;
• Gerenciador de stopwords: é aplicado para a construção da stoplist por meio da lista de
termos considerados irrelevantes definida no SCC. Também é utilizado para a exibição
dos stopwords no SCC;
• Gerenciador de Regras de Padronização (RP): constrói e carrega o AP por intermédio
de RP definidas pelos usuários no SCC;
• Configurador de parâmetros: determina as técnicas que deverão ser aplicadas para o
pré-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 com
a finalidade aprimorá-las e reduzir a complexidade de sua execução por meio da linguagem
Java. 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 de
caracteres especiais caso sejam definidas como stopwords, tais como parênteses ("()"), ponto de
interrogação ("?") e ponto de exclamação ("!"), os quais são comumente encontrados em laudos
textuais.
Na técnica de aplicação de padronização eram anteriormente utilizados dois AP, sendo
um com o intuito de representar RP para a substituição de uma palavra ou parte de uma frase
antiga por apenas um novo termo ou uma nova frase (RP do tipo um para um) e outro AP com o
objetivo de desempenhar RP para a substituição de uma palavra ou de uma frase antiga por dois
ou mais novos termos e/ou frases (RP do tipo um para vários). Na Figura 6.3 são apresentados
dois exemplos de AP, em que (a) é a estrutura que representa as RP que contém apenas uma
2
http://www.sqlite.org/
78
sentença para substituir uma observação presente no laudo não-padronizado e (b) é o AP que
contém RP com duas sentenças novas para a substituição de uma única observação. Nessa
figura, 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 uma
RP de pattern, synonymtwo é a tag de uma RP de patterntwo, n é um atributo que determina o
número de termos e/ou de sentenças substitutas contidas em synonymtwo, old é o marcador que
define uma palavra ou uma frase a ser substituída e new é a tag que se refere a uma palavra ou
uma frase substituta.
Figura 6.3: Exemplos de AP antigos.
Nesse sentido, o método de padronização foi reestruturado para utilizar apenas um AP
que represente todas RP, mantendo as técnicas originais para tratar diferentes tipos de RP. Na
Figura 6.4 é a demonstrado um exemplo para a nova estrutura de AP utilizando os exemplos
apresentados 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 denominada stemming foi substituída pelo método de lematização com o objetivo de reduzir as
limitações relacionadas ao stemming, conforme apresentado no Capítulo 3. O método de lematização foi implementado por intermédio da linguagem de programação Perl com base no método
proposto 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 para
79
processar apenas substantivos femininos e/ou plurais, os quais são mais comuns nos laudos textuais. Como essa técnica de lematização é baseada no algoritmo de Porter (1997), foi possível
reutilizar 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 retirada
do 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 na
segunda fase do PMLM para o pré-processamento de laudos.
Também, por meio da linguagem Perl foi desenvolvido um método para facilitar e automatizar 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 do
PMLM e os outros CFU são conjuntos de frases pré-processadas. Para a elaboração da técnica de geração de CFU, foram utilizados os métodos do PMLM escritos e aprimorados em
Perl. Nesse contexto, é importante ressaltar que no método de criação dos CFU, cada tipo de
conjunto de frases é gerado a partir do último CFU criado.
Além disso, o método de mapeamento de laudos médicos por ontologias, desenvolvido
em Java (Costa, Ferrero, Lee, Coy, Fagundes and Chung, 2009; Lee, Monard, Honorato, Lorena, 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 o
intuito de facilitar e de aprimorar a integração desse método com o SCC foram desenvolvidas
as novas funcionalidades, como:
• Possibilidade de seleção de ontologias por usuários;
• Construção de um gerenciador de atributos para a geração de ontologias por intermédio
da definição de RM e de características por usuários no SCC. Esse gerenciador é também
utilizado para a exibição de atributos e suas RM no sistema. Para a construção de ontologias, essa ferramenta gera os seguintes componentes, que são apresentado na Seção 7.6:
– Propriedades de dados: descrevem os elementos de ontologias;
80
– Propriedades de objeto: desempenham o relacionamento entre os elementos da ontologia, 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 ontologias utilizadas pelo SCC, como regiões anatômicas, características, subcaracterísticas, tipo de dados, atributos e RM.
• Requisito de que todas as RM devem conter uma região anatômica e no mínimo uma
característica para descrevê-la;
• Geração de resultados no formato de texto e organizados de forma que simplifiquem a
representação de seus resultados na interface do SCC;
• Carregamento e gravação da tabela atributo-valor e da lista de termos não-processados no
sistema.
Para a construção de uma interface web amigável e interativa com o usuário, foram utilizadas 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 os
cenários do sistema e adicionalmente, foram construídas outras páginas para auxiliarem no
uso dessas funcionalidades, tais como para carregamento de laudos, de lista de stopwords, de
AP e de ontologias, bem como para a criação e a edição de RP e de mapeamento. Para o
gerenciamento 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 em
Jung (2012) com o propósito de padronizar o SCC de acordo com os projetos em andamento no
LABI.
6.6
Apresentação do Sistema Computacional Colaborativo Desenvolvido
Como mencionado, o SCC foi estruturado em dois cenários, um para cada uma das fases
1 e 2, e as tarefas foram organizadas em menus de seleção que proveem acesso direcionado às
funcionalidades do PMLM.
3
http://rubygems.org/gems/paperclip
81
Na Figura 6.5 é apresentada a primeira tela do SCC em que é solicitada a autenticação
do 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 aos
laudos textuais. A partir dessa tela, também é viável a criação de novos cadastros de usuário por
meio do link "Criar uma conta" e redefinir senha do usuário por intermédio do link "Esqueceu
a 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ório
do computador servidor onde esse sistema encontra-se hospedado é gerada uma pasta cujo o
nome é 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 pasta
laudos_padronizados. Os resultados armazenados são a tabela atributo-valor e a lista de
termos não processados.
Na pasta do usuário, também são criadas e armazenadas as estruturas que são utilizadas
pelo PMLM, tais como o AP, a stoplist e a ontologia, as quais são geradas e/ou carregadas
pelo usuário. Outro arquivo que se encontra nessa pasta, é o de configuração de parâmetros
denominado parameters, que tem a finalidade de controlar a aplicação do pré-processamento
na segunda fase do método no SCC. Esse arquivo é estruturado na linguagem de marcação XML
e é composto pelos seguintes marcadores:
82
• 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 ser
executado;
• 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 utilizados para a construção de CFU. Esse marcador também é utilizado para o reuso dos
laudos da pasta referenciada pela mesma para a aplicação do pré-processamento e/ou do
mapeamento;
• 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 para
serem ou que foram padronizados;
Nesse arquivo, os marcadores que determinam a aplicação de técnicas de processamento
de textos podem representar apenas os seguintes valores: "sim", o qual é atribuído a um marcador caso o usuário escolheu uma determinada técnica para a aplicação de pré-processamento de
laudos; ou "não", que é atribuído aos marcadores das técnicas de processamento de textos que
não foram escolhidos pelo usuário. Os marcadores que representam a localização de arquivos e
de 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 identificação do usuário/subpasta. Na Figura 6.6 é apresentado um exemplo de estrutura de arquivo
de parâmetros, que é criado na pasta de um usuário.
Figura 6.6: Exemplo de estrutura do arquivo de parâmetros do SCC.
O arquivo de parâmetros ilustrado na Figura 6.6 determina que as técnicas de processamento de textos como a de normalização, de remoção de stopwords, de lematização e de
83
padronização foram selecionadas pelo usuário para serem aplicadas ao conjunto de laudos localizado no diretório laudos_padronizados, para o qual a sua localização é representada pelo
marcador dirOutput, em que "1" é o nome da pasta de um usuário.
Sendo assim, a seguir são apresentadas as funcionalidades de cada cenário do SCC, nas
quais os componentes são descritos na forma C.F.I, onde C é o número do cenário, F é o número
da 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 de
não interesse nesse momento. Essa operação pode ser aplicada pelo pressionamento da
tecla ”Delete” no computador do usuário, sendo necessária a seleção de no mínimo, um
laudo 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 de
laudos textuais.
Figura 6.7: Funcionalidade "Gerenciamento do Conjunto de Laudos Médicos" da primeira fase.
Na Figura 6.8 são apresentadas as telas de gerenciamento de carregamento de laudos
textuais. Nessa figura, (a) representa a tela abertura de arquivos e (b) é a tela para a qual se é
84
direcionado após o usuário clicar no botão "Enviar" na tela (a). É importante destacar que nessa
tela é viável carregar vários laudos simultaneamente a partir do computador do usuário.
Figura 6.8: Telas de gerenciamento de carregamento de laudos textuais.
Na Figura 6.9 é exibida a tela da funcionalidade "Conjunto de Frases Únicas (CFU)", na
qual têm-se:
• Campos do tipo texto para a exibição de um determinado CFU (1.2.1);
• 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 dos
laudos carregados na tela da Figura 6.7 e o botão "Download CFU" que permite gravar os
resultados no computador do usuário. O texto do botão "Reconstruir CFU" é exibido em
duas maneiras, sendo que o texto "Reconstruir CFU" é apresentado neste botão caso pelo
menos um CFU seja existente na base de dados ou "Construir CFU", caso contrário.
Figura 6.9: Funcionalidade "Construção e Gerenciamento do Conjunto de Frases Únicas" da
primeira fase.
Nessa funcionalidade, também é possível a visibilização de dois CFU distintos simultaneamente. Nesse contexto, é importante ressaltar que os CFU são construídos por meio do método
85
de geração automática de CFU desenvolvido neste trabalho, sendo apresentadas na seguinte ordem:
• Conjunto de Frases Únicas – CFU;
• CFU Normalizado;
• CFU Normalizado e sem Stopwords (caso exista stoplist na base de dados);
• CFU Lematizado (caso não exista uma stoplist cadastrada no SCC) ou CFU Lematizado
e 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, é necessária a existência de laudos textuais para esse fim na base de dados do SCC, os quais devem
ser 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 no
SCC, respectivamente.
Na Figura 6.10 é ilustrada a tela da funcionalidade "Definição e Gerenciamento da Lista
de Stopwords", em que é possível a visibilização de todos CFU gerados até o momento, facilitando 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 dessa
funcionalidade:
• Campo de texto para a determinação de uma nova palavra irrelevante, a qual é incluída
na 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);
• Botão "Carregar Stoplist", que é usado para carregar uma stoplist por intermédio do computador do usuário;
• Botão "Download Stoplist", que tem o intuito de gravar a stoplist no computador do
usuário;
• Botão "Aplicar Stoplist", que tem a finalidade de aplicar o método de remoção de stopwords
no último CFU construído.
As restrições da funcionalidade apresentada na Figura 6.10 são: a exigência do preenchimento do campo (1.3.1) para a inclusão de uma stopword; a necessidade da existência de uma
86
Figura 6.10: Funcionalidade "Definição e Gerenciamento da Lista de Stopwords" da primeira
fase.
stoplist para a aplicação do método de remoção de stopwords; e a impossibilidade de cadastrar termos irrelevantes repetidos. No sistema desenvolvido neste trabalho, a existência de uma
stoplist é dada pela presença de no mínimo uma stopword em (1.3.2) da Figura 6.10. Nesse
sentido, ao executar a técnica de remoção de palavras consideradas irrelevantes mediante o botã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 e
sem stopwords, respectivamente.
Na Figura 6.11 é mostrada a tela da funcionalidade "Construção e Gerenciamento do
Arquivo 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 nova
RP. Também é possível definir uma nova RP por meio da seleção de palavras na área de
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, para
a edição da RP selecionada em (1.4.1). A edição de uma RP também pode ser realizada
por 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;
87
• 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" da
primeira fase.
Para a aplicação da técnica de padronização de CFU, é necessária a existência de um AP
na base de dados do SCC, isto é, a lista de termos a serem substituídos como apresentado na
Figura 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 na
Figura 6.12, onde (a) é o campo de texto referente ao termo a ser substituído, (b) é o campo de
termo substituto a ser cadastrado e (c) é a lista de termos substitutos. Nessa tela, é possível a
definição, a edição e a exclusão de termos substitutos. Assim, o texto do botão de inclusão de
termos substitutos é "Incluir +", caso exista no mínimo um termo substituto cadastrado na lista
de termos novos ou "Incluir" caso contrário.
Para a edição de RP, o SCC disponibiliza uma tela semelhante ao apresentado na Figura 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) contenha
pelo menos um elemento. Também, para cada RP em ambos os casos não pode haver repetição
de termos novos, bem como não é permitido que duas ou mais RP possuam o mesmo termo
antigo, o qual é substituído pela lista de termos substitutos. Neste caso, um termo pode ser
considerado uma palavra ou uma frase.
Na Figura 6.13 é exibida a tela da funcionalidade "Definição e Gerenciamento do Conjunto de Atributos", a qual apresenta:
• Lista de nome de atributos (1.5.1);
88
Figura 6.12: Tela para definição de uma nova RP.
• 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 janela
popup, 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 ser
realizada por meio da tecla "Enter";
• Botão "Excluir", que é aplicado para a remoção de uma RM selecionada em (1.5.1). Essa
operação pode ser realizada por meio da tecla "Delete";
• Botão "Carregar Ontologia", que é utilizado para carregar ontologia do computador do
usuário;
• Botão "Download Arquivo", que usado para armazenar localmente a ontologia no computador do usuário.
Com essa funcionalidade, a necessidade do uso de ferramentas externas ao SCC para
a construção de ontologias na linguagem OWL, como o Protégé, se torna dispensável para
representação de atributos e de RM, facilitando e simplificando a elaboração de estruturas de
dados para a representação do conhecimento presente em laudos textuais. Outra característica
dessa funcionalidade é a impossibilidade de cadastrar atributos com nomes repetidos. Para a
89
Figura 6.13: Funcionalidade "Definição e Gerenciamento do Conjunto de Atributos" da primeira fase.
definição de novos atributos e suas RM, é utilizada uma tela popup semelhante ao de elaboração
de 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 o
atributo, (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ção
selecionada em (h).
Na Figura 6.14 é ilustrada a definição do atributo "esofagite_edematosa_inferior" com
RM no formato local-característica-subcaracterística, no qual "terço distal" é o local, "presenca_edema" é a característica e "normal" e "anormal" são as subcaracterísticas, contabilizando duas RM. No SCC, uma observação é implicitamente considerada subcaracterística
quando a RM representa sentenças no formato local-característica-subcaracterística ou é determinada 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 seguintes
restrições: para cadastrar um novo atributo, no mínimo o usuário deve preencher o campo de
nomeaçã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 é uma
90
Figura 6.14: Tela para definição de nova RM.
informação utilizada para o preenchimento de um atributo na base de dados caso o nome de sua
respectiva observação seja mapeada. Também, no SCC é permitida a criação de observações
com nomes iguais aos seus valores, por exemplo, se uma observação tem o nome "normal", o
mesmo 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);
• 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 do
usuá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 para
o mapeamento;
91
• Botão "Download Laudos", tem o propósito de gravar os laudos pré-processados no computador 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érios
do usuário. Sendo assim, nessa funcionalidade, os laudos selecionados podem ser visibilizados apenas em seu estado atual em (2.1.2), ou seja, se não foi aplicada nenhuma técnica de
pré-processamento são exibidos os laudos em suas versões originais, caso contrário, são apresentados 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 selecionados 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écnicas devem ser aplicadas para a transformação dos laudos selecionados para o mapeamento, tal
como determinar a localização de alguns elementos importantes nessa tarefa, como a pasta que
contém os laudos para serem transformados e as estruturas indispensáveis para a aplicação das
técnicas de remoção de stopwords e de padronização.
Na Figura 6.16 é ilustrada a tela da funcionalidade "Realização de Mapeamento", na qual
destacam-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 quais
são utilizados para identificar falhas no mapeamento e definir novas RP e/ou RM (2.2.2);
92
• 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 laudos
mapeados;
• Botão "Download Termos", que é aplicado para armazenar localmente o arquivo de termos 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 desenvolvida ou carregada na funcionalidade "Definição e Gerenciamento do Conjunto de Atributos" do
primeiro cenário do SCC, conforme apresentado na Figura 6.13.
6.7
Etapa de Avaliação e Feedback
Durante a construção do SCC, o mesmo foi constantemente avaliado em conjunto com
os envolvidos na elaboração do projeto com o intuito de verificar o andamento do projeto e se
as especificações levantadas foram atendidas satisfatoriamente. Assim, foram realizadas reuniões quinzenais entre os envolvidos no desenvolvimento do sistema para discutir as atividades
que foram desempenhadas desde a última reunião, bem como apresentadas as dificuldades encontradas e as possíveis soluções. Também, nessas reuniões foram definidos quais requisitos
deveriam ser acrescentados, alterados e/ou removidos.
93
Após a construção da versão final do SCC, o mesmo foi avaliado em conjunto com especialistas do domínio, os quais constataram que esse sistema cumpre os requisitos definidos e
se apresenta como promissor para a definição, a extração e o estudo de padrões que podem ser
encontrados em laudos textuais (Lee, Oliva, Maletzke, Machado, Voltolini, Coy, Fagundes and
Wu, 2013).
Ainda, o SCC foi avaliado quanto ao desempenho na aplicação do PMLM automatizado
a um conjunto de 100 laudos médicos textuais artificiais que simulam exames de Endoscopia
Digestiva Alta (EDA). Os critérios e os resultados dessas avaliações são apresentados no Capítulo 7.
6.8
Considerações Finais
Neste capítulo foi apresentada a aplicação do processo de desenvolvimento de sistemas
por prototipagem para a construção do SCC com o intuito de automatizar o PMLM por ontologias.
Inicialmente, foram estudados os aspectos teóricos e práticos que abrangem a aplicação
de todas as técnicas de processamento de textos utilizadas nas duas fases do PMLM. A análise
desse processo permitiu constatar que o uso de todas as técnicas é complexo para qualquer pessoa que não conheça detalhadamente o método e principalmente por profissionais que não sejam
da área computacional. Isso se deve ao fato de que essas técnicas são executadas separadamente
mediante às instruções computacionais, bem como as estruturas utilizadas pelo PMLM devem
ser 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 o
intuito de identificar os requisitos para desenvolver um SCC para automatizar e facilitar o uso do
método. Em seguida, os requisitos foram estudados e analisados com a finalidade de verificar a
viabilidade para o desenvolvimento de uma solução computacional e planejar a construção do
mesmo. Depois, o SCC foi modelado em dois cenários, sendo um para cada fase do PMLM.
Após, o sistema foi implementado utilizando a linguagem programação Ruby com o auxílio
da ferramenta RoR. Para o uso das técnicas de construção de CFU, de pré-processamento e de
mapeamento de laudos médicos foi utilizada a linguagem de programação Java por intermédio
do 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 PMLM
sem a necessidade do usuário conhecer detalhadamente as especificações técnicas, como linguagens de programação e de marcação, bem como comandos para a execução dos métodos
do PMLM, possibilitando a construção de bases de dados para a realização estudos futuros de
forma ágil e eficiente. Também, para o uso do SCC não é necessária a sua instalação e a con-
94
figuração do computador do usuário, bastando apenas um navegador web instalado na máquina
e acesso à internet.
Depois da construção do sistema, o mesmo foi avaliado e validado em conjunto com especialistas do domínio, os quais constataram que a solução computacional atendeu aos requisitos
estabelecidos e se apresenta como promissora para a extração e o estudo de padrões em laudos
textuais médicos.
Em seguida, o SCC foi aplicado a um conjunto de 100 laudos médicos textuais artificiais
simulando 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
7.1
Considerações Iniciais
Como apresentado anteriormente, este trabalho tem o objetivo de automatizar e de consolidar o Processo de Mapeamento de Laudos Médicos (PMLM) por ontologias por meio da
integração de todas as suas técnicas de processamento de textos, bem como a inclusão de outros
métodos e funcionalidades em um sistema computacional. Para isso, foi realizado um estudo
de caso interdisciplinar envolvendo as áreas computacional e médica.
Para alcançar os objetivos deste trabalho, foi construído um Sistema Computacional Colaborativo (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 de
Ciências Médicas da Universidade Estadual de Campinas (UNICAMP). Esse sistema foi desenvolvido para automatizar e facilitar o uso do PMLM por profissionais que não sejam da área
computacional, por exemplo, da área de saúde e que não possuam conhecimento detalhado do
método, possibilitando a construção de grandes bases dados, as quais poderão ser utilizadas
para 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 um
estudo de caso com a finalidade de avaliar o desempenho do sistema durante o processamento
de um conjunto de laudos médicos textuais artificiais.
Na Seção 7.2 é descrita a avaliação experimental realizada neste estudo de caso. Nas
Seçõ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 estruturação de Regras de Mapeamento (RM). Na Seção 7.7 é demonstrada a aplicação do método
de mapeamento por ontologias. Na Seção 7.6 são apresentadas as principais características da
ontologia 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 realizada em um conjunto de 100 laudos médicos artificiais que simulam relatórios de exames de Endoscopia Digestiva Alta (EDA). Esses exames são usados por especialistas em processos de diagnóstico de enfermidades que acometem o esôfago, o estômago e/ou o duodeno (Cordeiro, 1994; Cotran, Kumar and Collins, 1996). Os documentos utilizados nessa
avaliação experimental contêm um total de 400 frases e 2.520 palavras. Os laudos artificiais
apresentam a seguinte estrutura:
• Cabeçalho: indica a porção anatômica analisada e geralmente está presente na primeira
linha do texto e escrito em caixa-alta;
• Observações: são sentenças que descrevem anormalidades e/ou outras características
observadas 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 da
seção de esôfago, no qual a parte destacada na cor vermelha é o cabeçalho e na cor verde são as
observaçõ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 foram
identificadas anormalidades na região do esôfago por intermédio do exame de EDA. Nessas
observações, o calibre se refere ao diâmetro interno do esôfago, a distensibilidade é a capacidade
de 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 ao
se realizar o processo pela primeira vez para um conjunto de laudos de um determinado domínio, é necessária a realização de todas as tarefas associadas ao processo, incluindo a construção
do Arquivo de Padronização (AP), da stoplist e da ontologia.
Na primeira fase, as frases de todos os documentos selecionados foram concatenados e
ordenados alfabeticamente em um único arquivo. Em seguida, todas as frases repetidas foram
97
eliminadas, originando o Conjunto de Frases Únicas (CFU), o qual contém uma entrada para
cada 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 por
caracteres minúsculos e sem acentuação, resultando no CFU Normalizado.
Após, foi definida uma lista de termos considerados irrelevantes, conforme apresentada na
Seção 7.4. Essa stoplist foi aplicada no CFU Normalizado por meio da técnica de remoção de
stopwords, gerando o CFU Normalizado e sem Stopwords. Em seguida, esse grupo de sentenças
foi submetido à transformação por intermédio do método de lematização, concebendo o CFU
Lematizado e sem Stopwords.
Posteriormente, foram definidas Regras de Padronização (RP) a partir da análise dos CFU
gerados anteriormente, construindo o AP, conforme apresentado na Seção 7.3. Essas regras foram determinadas para transformar as sentenças de modo que sejam representadas no formato
local-característica-subcaracteristica ou local-característica com o propósito de facilitar a definição de RM, como apresentada na Seção 7.5. A aplicação do AP no último conjunto de frases
gerados concebeu o CFU Padronizado.
Depois da construção de todos os CFU, as frases foram analisadas com o intuito de definir as variáveis e os valores da tabela atributo-valor (base de dados), bem como a estrutura
da ontologia, como apresentadas nas Seções 7.5 e 7.6, respectivamente, para a representação
do conhecimento presente nos laudos médicos utilizados neste trabalho por intermédio dessas
estruturas.
Na segunda fase, o conjunto de laudos médicos utilizado na construção de CFU foi submetido à aplicação de técnicas de processamento de textos com o propósito de transformá-los
para uma representação adequada para a execução do método de mapeamento. Para isso, foram usadas as estruturas como a stoplist e o AP definidas anteriormente. Sendo assim, nesses
documentos foram efetuadas sequencialmente as seguintes técnicas: normalização, remoção de
stopwords, lematização e padronização.
Posteriormente, as informações presentes nos laudos padronizados foram mapeadas para
a base de dados. Esse mapeamento foi conduzido de duas formas: manual, que é realizado
c ; e automático, o qual é aplicado por
manualmente para uma planilha do Microsoft Excel
intermé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:
• Medidas estatísticas para os termos e as frases dos CFU gerados durante a aplicação
de 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;
98
• 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 estejam
em formato adequado para a construção de Regras de Mapeamento (RM) que irão compor
uma ontologia, como a apresentada na Seção 7.6, deve ser definido o AP por intermédio da
elaboração de RP.
Nesse sentido, neste trabalho foram definidas, em conjunto com especialistas, 81 RP com
a finalidade de uniformizar as frases para o formato local-característica-subcaracterística ou
local-característica. Dessas regras, 66 são do tipo um para um (um termo antigo é substituído
por um termo novo) e 15 são do tipo um para vários (um único termo antigo é substituído por
vários termos novos simultaneamente). Para a elaboração de RP, também foram utilizadas Expressões Regulares (ER) com o intuito de identificar características em palavras ou frases, como
espaço em branco excedentes, para padronizá-las adequadamente. Essas RP são apresentadas
no Apêndice A.2. Na Figura 7.2 é ilustrado um fragmento do AP elaborado neste trabalho.
Figura 7.2: Fragmento do AP desenvolvido no Estudo de Caso.
99
No fragmento de AP apresentado na Figura fig:apEC são apresentados três exemplos de
RP para a aplicação da padronização de laudos textuais. A primeira RP é aplicada para a substituição da palavra "enantemo" pela sequência "presenca_edema sim", transformando a frase para
o formato local-característica-subcaracterística, sendo que esse termo antigo geralmente é precedido 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 apresentam
pelo menos uma enfermidade, as quais não são descritas explicitamente. Nesse caso, a regra é
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 transformar a descrição da extensão da TEG (transição esôfago-gástrico) medida em centímetros para
grau de anormalidade. Assim, essa porção é considerada normal quando se encontra no mesmo
ní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,01
cm. 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, a
expressão "[,.]" determina que pode existir ou não os caracteres "," ou ".", "s*" estabelece que
pode haver zero ou mais espaços em branco e "[acima]" descreve que pode existir ou não o
termo "acima".
Nesse contexto, as RP foram desenvolvidas para serem aplicadas em laudos textuais lematizados e sem stopwords devido a menor variabilidade de frases, facilitando a construção
dessas regras.
7.4
Elaboração da Stoplist
Neste estudo de caso foi definida, em conjunto com especialistas, uma stoplist contendo
59 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 Normalizado. Na Figura 7.3 é ilustrada a definição da lista de stopwords a partir de um fragmento
de CFU Normalizado, na qual, o usuário identifica o termo considerado irrelevante e o sistema
armazena-o na stoplist.
Sendo assim, a stoplist definida neste trabalho é apresentada com as suas stopwords organizadas em ordem alfabética crescente no Apêndice A.1, no qual essa lista é exibida utilizando
estruturas determinadas na linguagem de marcação XML.
100
Figura 7.3: Exemplo de transcrição de stopwords.
7.5
Definição de Atributos da Base de Dados e de Regras de
Mapeamento
Após a construção dos CFU, as informações geradas são analisadas com o intuito de definir a estrutura da base de dados, ou seja, a tabela atributo-valor do SCC. Para isso, foram
definidos, em conjunto com especialistas, dezesseis atributos representativos com a finalidade
de descrever informações relevantes presentes em laudos textuais médicos de EDA. Essas propriedades foram divididas em três grupos de acordo com os seus respectivos tipo de valores, que
sã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 a
presença ou a ausência de enfermidades inflamatórias nas porções de esôfago inferior, médio e
superior, 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;
• 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ósito
de determinar se as porções do esôfago (inferior, médio e superior) e as características como
calibre, distensibilidade e motilidade apresentam anormalidade, correspondendo no total de seis
atributos, que são apresentados a seguir:
101
• 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 apenas
um atributo, que é denominado teg_extensao e tem o propósito de determinar se a largura da
teg é normal ou caso contrário, apresentar o grau da gravidade de enfermidade.
Paralelamente à atividade de definição de atributos, foram definidas as suas respectivas
RM, que são foram elaboradas para mapear frases no formato local-característica e localcaracterística-subcaracterística. Para os atributos do Grupo 1, as RM foram definidas para
mapear 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 "presenca_anormalidade", como característica;
• Subcaracterística: "sim" ou "não".
Para os atributos do Grupo 2, as RM foram apresentadas na forma local-característicasubcaracterística para a descrição de características do esôfago inteiro, como o calibre, a distensibilidade e motilidade e para a apresentação da situação de uma porção do esôfago e da
propriedade do Grupo 3, a RM apresenta o formato local-característica. A seguir são apresentados exemplos de RM para alguns atributos descritos anteriormente:
• esofagite_edematosa_inferior:
– "esofago_inferior presenca_edema nao";
– "esofago_inferior presenca_edema sim".
• calibre_esofago:
– "esofago calibre normal";
– "esofago calibre anormal".
• mucosa_esofago_medio:
– "esofago_medio normal";
102
– "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 ontologia, como a apresentada na Seção 7.6. Também, a base de dados é preenchida apenas após
o mapeamento dos laudos textuais, com base nas características determinadas para a tabela
atributo-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 utilizada
a linguagem OWL devido ao grande poder de expressividade, à inclusão de todos os recursos
da linguagem OWL e a garantia de completude computacional e de operação de expressões por
computadores em tempo finito. Sendo assim, nesse sistema é utilizado o esquema de ontologia
proposto por Costa, Ferrero, Lee, Coy, Fagundes and Chung (2009), que é organizado pelas
seguintes 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 o
preenchimento da base de dados;
• 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 atributos que são preenchidos pelos valores de Grupo_va_1;
• Atributo_Tipo_va_2: é uma subclasse de Atributo_Base_de_Dados que determina os
atributos que são preenchidos pelos valores de Grupo_va_2;
103
• Atributo_Tipo_va_3: é uma subclasse de Atributo_Base_de_Dados que estabelece os
atributos 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ísticas
que foram observadas nas regiões representadas pela classe Regiao;
• Caracteristica: é uma subclasse de Observacao que representa as informações relevantes
que podem ser mapeadas em laudos textuais;
• Situacao: é uma subclasse de Observacao que descreve as subcaracterísticas, também
denominadas informações complementares;
• Anormalidade: é uma subclasse de Situacao que determina as anormalidades descritas
em laudos médicos;
• Outra_Situacao: é uma subclasse de Situacao que apresenta outras informações complementares.
Figura 7.4: Hierarquia de classes da ontologia proposta por Costa, Ferrero, Lee, Coy, Fagundes
and Chung (2009).
Na ontologia apresentada na Figurafig:ontologiaOWL, as classes são representadas de
forma hierárquica e os indivíduos como atributos, possíveis valores, regiões anatômicas e ob-
104
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 aos
atributos.
Para auxiliar na organização do conhecimento presente em laudos médicos por ontologia foram definidas propriedades para desempenhar relacionamentos entre os indivíduos dessa
estrutura (Figura 7.6). Assim, uma dessas propriedades de dados é a denominada nomeInstancia, que tem o propósito de descrever um termo para cada elemento, como palavras de laudos
textuais pré-processados, atributos da base de dados e possíveis valores para cada tipo de atributo. Essa característica se encontra presente em todas as instâncias de classes. Também, foram
definidas as seguintes propriedades de objeto:
• observacao: contém os indivíduos que descrevem características e subcaracterísticas em
RM;
• 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 caso
seja mapeada uma determinada RM. Essa propriedade é associada aos elementos pertencentes às classes Anormalidade e Outra_Situacao;
• valor_padrao: determina um valor a ser preenchido em um atributo da tabela atributovalor caso o mesmo não seja mapeado. Essa propriedade, assim como a observacao e a
regiao são aplicadas nas instâncias pertencentes às classes Grupo_va_1, Grupo_va_2 e
Grupo_va_3.
Também, cada instância é referenciada pela propriedade rdf:about, a qual é utilizada por
métodos e ferramentas que processam ontologias OWL para identificar cada componente dessa
estrutura, como indivíduos, classes e propriedades. Essas referências são atribuídas automaticamente pelo SCC de forma que seja facilmente legível em nível de código por desenvolvedores de
ontologias que utilizam a linguagem OWL, permitindo desse modo a intercomunicação, quando
necessário, entre ontologias criadas em ferramentas como o Protege e o SCC desenvolvido neste
trabalho. Na Figura 7.5 é apresentado o exemplo de ontologia ilustrado na Figura 7.4 com uma
instância para cada classe do nível mais baixo dessa hierarquia. Nessa Figura, os retângulos
com presença de um círculo de cor alaranjada são classes e os com presença de um prisma de
cor roxa são indivíduos instanciados em suas respectivas classes.
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 numeroIndividuo 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 formato valor_de_atributo_x_numeroIndividuo, em que x é uma referência ao grupo de valores
105
Figura 7.5: Esquema detalhado de ontologia proposta por Costa, Ferrero, Lee, Coy, Fagundes
and Chung (2009) com um exemplo de instância para cada classe utilizada para representação
de conhecimento.
em que o atributo encontra-se instanciado e pode conter apenas os valores "1", "2" ou "3", por
exemplo, valor_de_atributo_1_01, que representa o valor de atributo "nao".
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 representam
os atributos da tabela atributo-valor e as suas respectivas RM. Essas instâncias são definidas de
acordo com os grupo de valores que foram escolhidos para o preenchimento de seus atributos
na base de dados, por exemplo, se um atributo for do tipo Grupo_va_1, o indivíduo que o
representa será instanciado na classe Atributo_Tipo_va_1.
Desse modo, as propriedades de objetos são aplicadas nas instâncias que contêm os atributos com a finalidade de representar as RM. Abaixo é apresentado um exemplo de atributo
com 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);
106
• observacao: "normal" (outra_situacao_01);
Na Figura 7.6 é apresentado o atributo "calibre_esofago" representado na linguagem
OWL, no qual owl:Thing é um construtor para a definição de indivíduos, rdf:type é uma propriedade 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 é uma
propriedade semelhante à rdf:about que é utilizada para determinar o nome de uma classe ou
de 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 definam
novos elementos. Os nomes das instâncias de Regiao são:
• "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).
107
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 classe
Regiao.
Figura 7.7: Exemplo de esquema de ontologia criada automaticamente pelo SCC com a classe
Regiao expandida.
Para as classes Caracteristica, Anormalidade, Outra_Situacao e as subclasses de Atributo_Base_de_Dados, os indivíduos são criados após a definição de um novo atributo por meio
de uma tela acessível pela funcionalidade "Conjunto de Atributos" do SCC apresentada na Figura 6.14. Antes da gravação de novos elementos, na ontologia é verificada a existência de
um indivíduo nas subclasses de Atributo_Base_de_Dados com o nome igual ao do atributo em
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 analisados
108
com a finalidade de verificar se foram cadastrados na ontologia. Assim, são criadas instâncias
da 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 da
classe Outra_Situacao para as observações que contém o valor "nao" ou "normal".
7.7
Aplicação do Método Mapeamento por Ontologias em
Laudos Médicos Artificiais
Com base na estrutura apresentada na Figura 7.4, o PMLM é aplicado em cada cadeia de
caracteres 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 contida
na propriedade nomeInstancia de cada indivíduo das subclasses de Termo com o propósito de
verificar se a palavra analisada foi cadastrada na ontologia por meio de RM. Caso o vocábulo
não seja encontrado na estrutura, o mesmo é adicionado à lista de termos não-processados, o
qual pode ser utilizado posteriormente para a definição de novas RP e RM. Após, nas subclasses de Atributo_Base_de_Dados são analisadas as respectivas instâncias para localizar os
atributos que contém RM compatíveis com as palavras da frase que foram localizadas na ontologia e preencher a tabela atributo-valor com o valor dos elementos presentes nas subclasses de
Valor_de_Atributo.
Por exemplo, na frase "esofago calibre normal", para cada termo, primeiramente o algoritmo 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 com
a sentença avaliada e mapear o seu respectivo atributo. Assim, para cada termo é procurado
um 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 identificar o atributo, como o "esofago_calibre", que contenha uma RM compatível com essa frase
e mapeá-la para uma base de dados.
Também, é importante ressaltar que o algoritmo de mapeamento foi alterado para evitar
que os atributos não mapeados sejam preenchidos com seus respectivos valores padrões para
evitar representações errôneas semanticamente. Por exemplo, se em um registro (linha) da tabela 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, cada
atributo não mapeado em um registro é preenchido com o caractere ”-", indicando que um determinado campo está vazio.
109
7.8
Considerações Finais
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 no
LABI da UNIOESTE/Foz do Iguaçu em parceria com o Serviço de Coloproctologia da UNICAMP. A análise do PMLM permitiu constatar que o uso de todas as técnicas é complexo para
qualquer pessoa que não conheça detalhadamente o método e principalmente por profissionais
que não sejam da área computacional. Isso se deve ao fato de que essas técnicas são executadas
separadamente mediante as instruções computacionais, bem como as estruturas utilizadas pelo
PMLM devem ser construídas manualmente por meio de uma linguagem de marcação, como o
XML.
Com o desenvolvimento de uma solução computacional, o PMLM por ontologias foi
automatizado por intermédio da integração de todas as suas técnicas no SCC. Nesse sistema
não é necessário o conhecimento detalhado de métodos de processamento de textos aplicados
pelo 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
um conjunto de laudos médicos textuais artificiais de exames de EDA. Assim, foram definidas
estruturas 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 de
textos laudos para a construção de CFU, os quais eram utilizados como suporte para a definição
das estruturas aplicadas na segunda fase do PMLM.
Após, os laudos foram processados por intermédio dos métodos de normalização, de remoção de stopwords, de lematização e de padronização. Em seguida, as informações dos laudos
uniformizados foram mapeadas para a base de dados (tabela atributo-valor). Esse mapeamento
foi realizado de duas formas: manual, no qual o conhecimento presente nos documentos foi
transcrito manualmente para uma planilha eletrônica; e automático, em que foi utilizado o SCC
para a realização do mapeamento.
Desse modo, os resultados da aplicação do PMLM foram avaliados utilizando medidas
como média, desvio-padrão, máximo, mínimo, precisão, custo de tempo (apenas para mapeamento manual) e custo computacional. Os resultados obtidos nessas avaliações são apresentados no Capítulo 8.
110
Capítulo 8
Resultados e Discussão
8.1
Considerações Iniciais
Após a construção do Sistema Computacional Colaborativo (SCC), o mesmo foi avaliado
em conjunto com especialistas do domínio e submetido à aplicação de uma avaliação experimental em um conjunto de 100 laudos médicos textuais artificiais. Para a realização desse
experimento, foi realizado um estudo de caso com o propósito de avaliar o desempenho da aplicaçã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ção
do PMLM automatizado em um conjunto de laudos textuais. Essas avaliações foram realizadas
na 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, cada
funcionalidade do sistema foi executado e os resultados avaliados.
Sendo assim, a Seção 8.2 são descritas abordagens utilizadas para o mapeamento desses
laudos médicos e alguns trabalhos nos quais foram aplicadas essas abordagens. Na Seção 8.3
são discutidos os resultados do desenvolvimento do SCC e na Seção 8.4 são apresentados os
resultados e as discussões sobre a aplicação do PMLM automatizado em um conjunto de laudos
mé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 é geralmente realizado de forma manual para uma base de dados ou planilhas eletrônicas. O mapeamento manual apresenta-se como uma abordagem ineficiente e com elevado custo de tempo,
tornando essa atividade inviável para grandes quantidades de documentos textuais.
Como mencionado, a primeira versão do PMLM era baseada em Dicionário de Dados.
111
112
Essa proposta foi aplicada em conjuntos de laudos textuais de diversas regiões do sistema digestório, nos quais foram obtidos resultados satisfatórios. Em Cherman, Spolaôr, Lee, Honorato, Coy, Fagundes and Wu (2008), por exemplo, o método foi usado em um conjunto de 100
laudos textuais provenientes de exames de colonoscopia e 609 de exames de Endoscopia Digestiva 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 automatizada, 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 aplicado
a um conjunto de 3647 laudos de exames de EDA, mapeando aproximadamente 85,82% de suas
informaçõ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 atividade simples, pois as suas técnicas eram executadas por intermédio de comandos computacionais. Também, a construção de estruturas como o Arquivo de Padronização (AP) e a lista de
stopwords (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 utilizar
outras 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 desenvolvido um SCC. Para a construção do Sistema Computacional Colaborativo (SCC), foi usada a
abordagem de engenharia de software denominada processo de desenvolvimento de sistemas
por prototipagem em virtude da complexidade dos requisitos e a necessidade do envolvimento
de especialistas do domínio para o desenvolvimento de uma solução computacional. Essa abordagem é 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ósito
de compreender profundamente o funcionamento dos métodos empregados no processo para a
transformação de textos. No Capítulo 6, foram apresentadas limitações do uso do processo
por profissionais da área da saúde ou que não conhecem o funcionamento do PMLM, como
a execução de técnicas de processamento de textos, as quais eram realizadas manualmente e
separadamente com o uso de comandos computacionais executados por meio de interpretadores
c Windows e o Terminal
de linha de comando, como o Prompt Command (CMD) do Microsoft
do Linux. Para o funcionamento correto desses comandos, é necessária a instalação de um
interpretador das linguagens Perl e Java, bem como é imprescindível a instalação de outras
ferramentas auxiliares e a configuração do computador do usuário.
113
Também, a aplicação do método de pré-processamento aplicado no PMLM denominado
stemming 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ção
semântica incorreta por causa da existência de termos com significados distintos, mas com
radicais iguais, conforme apresentado no Capítulo 3.
Após a execução de estudos, foram realizadas reuniões em conjunto com especialistas
do domínio com a finalidade de definir os requisitos para a construção do SCC. Os principais
requisitos foram: a automatização do PMLM; substituição do método de stemming pela técnica
de lematização; construção de uma interface web amigável e intuitiva ao usuário; e possibilitar
o uso do sistema em qualquer lugar por computadores e outros dispositivo.
Na Etapa 2 (Plano Rápido), os requisitos levantados anteriormente foram estudados e
analisados com o objetivo de compreendê-los e de determinar as atividades e as tecnologias necessárias para o desenvolvimento de uma solução computacional. Paralelamente, foi verificado
se era viável a produção de um sistema computacional para atender às especificações levantadas
na Etapa 1. Após, foi iniciado o planejamento da construção do SCC e estudada as tecnologias
descritas no Capítulo 5.
Na Etapa 3 (Modelagem), para facilitar a compreensão das especificações levantadas nas
etapas anteriores, no sistema foi modelado um cenário para cada fase do PMLM. Para o primeiro
cená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ção
e gerenciamento do AP; e definição e gerenciamento do conjunto de atributos. Para o segundo
cenário foram determinadas as subsequentes funcionalidades: aplicação de pré-processamento;
e realização de mapeamento. Nesse sentido, essas funcionalidades disponibilizam recursos para
facilitar a execução de cada técnica de processamento de textos e a definição de estruturas auxiliares como a stoplist, o AP e a ontologia, sem a necessidade do conhecimento detalhado das
linguagens e outras tecnologias para esse fim. Também, é possível reaproveitar essas estruturas
para realização de novos experimentos. Além disso, no SCC são gerados outros tipos de dados
como 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, dos
quais se destaca o JRuby sob o apoio do framework de desenvolvimento web denominado Ruby
on 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
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 grande
importância para a segurança de dados dos usuários, principalmente por se tratar de informa-
114
çõ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 sistema
de gerenciamento de bases de dados RoR chamado SQLite devido a sua simplicidade para o
gerenciamento, a implementação e a manutenção de base bases de dados.
A linguagem de programação Java apoiada pelo ambiente de desenvolvimento NetBeans
foi utilizada para a elaboração de métodos que ofereçam suporte para a execução das técnicas
de processamento de textos do PMLM que foram escritas na linguagem Perl e a construção e o
carregamento 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 empregadas para a construção desses métodos oferecem vários recursos, como extensa biblioteca
de ferramentas auxiliares, para a produção de sistemas que apresentam requisitos considerados
complexos.
Para facilitar o uso das técnicas de processamento de textos do PMLM pelo SCC, o
código-fonte das mesmas foi alterado para reduzir a complexidade de sua execução em métodos 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, mas
mantendo as técnicas originais de tratamento de RP de diferentes tipos, como um para um e um
para vários.
Para a redução da perda de legibilidade causada pela transformação de termos por seus
respectivos radicais, a técnica de stemming foi substituída pela de lematização, que tem a finalidade 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 substantivo plural, entre outros. O uso da lematização possibilita a redução da perda de legibilidade
e da variabilidade de palavras, facilitando a descoberta de padrões que podem ser utilizados para
a elaboração do RP, RM e de atributos da base dados. Esse método foi implementado utilizando
a linguagem Perl para facilitar a sua integração com as técnicas de geração de CFU da primeira
fase 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 gerenciamento do conjunto de laudos médicos do primeiro cenário do SCC. Assim, nesse método
foi possível integrar ao sistema as técnicas aplicadas no PMLM que foram desenvolvidas na
linguagem Perl em trabalhos anteriores realizados no Laboratório de Bioinformática (LABI) e
modificados neste trabalho.
Também, o método de mapeamento de laudos médicos por ontologias, desenvolvido em
Java, foi integrado ao SCC. Para isso, foram elaboradas novas funcionalidades para possibi-
115
litar a realização das seguintes tarefas: seleção de ontologias por usuários; gerenciamento de
atributos de bases de dados; imposição de que as RM devem-se encontrar nos padrões localcaracterística-subcaracterística ou local-característica; geração de resultados no formato de
texto de forma que simplifique a sua visibilização na interface do sistema; e carregamento e
gravação dos resultados do mapeamento como a tabela atributo-valor e a lista de termos não
processados. Com o desenvolvimento dessas funcionalidades, o uso do método de mapeamento foi facilitado e aprimorado, bem como não é mais necessário o uso de outras ferramentas
computacionais para a construção de ontologias, estando todas as técnicas necessárias para a
aplicação do PMLM integradas no SCC.
Também, destaca-se que o SCC pode ser utilizado remotamente em qualquer computador
ou outro dispositivo computacional e em qualquer lugar, sem a necessidade de instalação e de
configuração de um ambiente computacional, sendo necessário apenas o acesso à internet. Outra característica importante desse sistema é a utilização de apenas ferramentas de uso gratuito
para sua construção. Além disso, foi construída uma interface web amigável e interativa com
o usuário para facilitar o uso do SCC. Para isso, foram utilizadas as linguagens HTML, CSS e
Javascript com a finalidade de desenvolver uma página web acessível para cada funcionalidade
dos cenários do sistema. As linguagens utilizadas para a elaboração de telas são amplamente
aplicadas em sistemas web pela comunidade de desenvolvedores, pois possuem código legível
e de fácil uso, bem como é possível desenvolver ferramentas interativas e intuitivas com os
usuá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 desenvolvimento no LABI. Também, para auxiliar no carregamento de laudos, de stoplists, de AP e
de ontologias, foi utilizada a gem Paperclip, que constrói automaticamente os gerenciadores de
carregamento 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 de
grande valia para a extração e o estudo de padrões que podem ser encontrados nos laudos
textuais (Lee, Oliva, Maletzke, Machado, Voltolini, Coy, Fagundes and Wu, 2013). Assim, o
sistema pode contribuir com a geração de novos conhecimentos, tais como: desenvolvimento
de novos procedimentos médicos; identificação de padrões que podem acarretar à determinadas
enfermidades, entre outras.
A construção do SCC possibilitou automatizar e facilitar o uso do PMLM por usuários
sem a necessidade do conhecimento detalhado dos métodos empregados nesse processo, das
linguagens de marcação utilizadas para a representação do conhecimento e de outras ferramentas para a construção de ontologias. Para isso, como mencionado, no SCC são disponibilizadas
funcionalidades para o processamento de laudos textuais em dois cenários, sendo cada um correspondente a uma fase do PMLM.
116
No primeiro cenário, é possível carregar laudos textuais remotamente a partir do computador do usuário e visibilizar os seus respectivos conteúdos no sistema, tal como é viável a
construção e a visibilização de CFU por intermédio da aplicação de métodos de processamento
de 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, que
compõem o AP; e na definição de RM e de atributos da base de dados que irão constituir uma
ontologia.
O segundo cenário, possibilita o reuso dos laudos usados no primeiro cenário e/ou a abertura de novos conjuntos; a seleção e a aplicação de técnicas de processamento de textos, como
normalização, remoção de stopwords, lematização e padronização; e a realização do mapeamento 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 lista
de termos não processados.
É importante destacar que o usuário pode armazenar localmente em seu computador os
resultados da aplicação do PMLM, como a lista de CFU, a stoplist, o AP, a ontologia, o conjunto
de laudos pré-processados para a aplicação do método de mapeamento, a tabela atributo-valor
e a lista de termos não processados.
Desse modo, o desenvolvimento do SCC foi considerado desafiador, pois além da complexidade dos requisitos e da interdisciplinaridade do projeto, envolveu a interação entre diferentes métodos e ferramentas escritos em linguagens de programação distintas, o que ocasionou
em maior tempo de estudos das especificações levantadas inicialmente e de tecnologias para a
produçã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 um
conjunto de 100 laudos médicos textuais artificiais construídos por especialistas do Serviço
de Coloproctologia da Universidade Estadual de Campinas (UNICAMP). Assim, esses documentos foram submetidos à aplicação de técnicas de processamento de textos em cada fase do
PMLM por meio do uso do SCC.
No primeiro cenário do sistema, os laudos foram submetidos à aplicação de técnicas de
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 e
eliminação de frases repetidas. Em seguida, nesse conjunto de sentenças foi aplicada a técnica
de normalização, gerando o CFU Normalizado.
Após, foi construída a stoplist apresentada no Apêndice A.1 e aplicado o método de
remoção de stopwords no CFU Normalizado para a construção do CFU Normalizado e sem
117
Stopwords. Depois, nesse conjunto foi aplicado o procedimento de lematização, concebendo
o CFU Lematizado e sem Stopwords, o qual foi analisado com a finalidade de identificar padrões interessantes para a elaboração RP que irão compor o AP. Essas regras foram geradas no
formato local-característica-subcaracterística e local-característica, as quais são apresentadas
no Apêndice A.2. Em seguida, O AP foi aplicado por meio da técnica de padronização para a
construção do CFU Padronizado.
Depois da geração do CFU Padronizado, o mesmo foi utilizado para a definição de atributos que compõem a base de dados e as RM para mapear essas características em laudos textuais
para essa base. Esses atributos e RM constituem uma ontologia, que é utilizada para a transformaçã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 AP
definidos no primeiro cenário. Após, as informações presente nos laudos pré-processados foram
mapeadas para a base de dados utilizando a ontologia definida anteriormente. Esse mapeamento
foi realizada de duas formas: manual, em que essa tarefa é realizada manualmente para uma
planilha 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 do
PMLM.
A avaliação dos CFU gerados em relação à quantidade de frases é apresentada na Figura 8.1, em que é possível constatar que a quantidade de frases foi reduzida no decorrer da
execução das técnicas de processamento de textos do PMLM. Sendo assim, a geração do CFU
proporcionou 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 Normalizado
contém a mesma quantia de sentenças em relação ao primeiro conjunto, com o total de 71 observações. A efetuação da técnica de remoção de stopwords acarretou na eliminação de 9,86% das
frases do CFU. Com o emprego do método de lematização, o número de sentenças foi reduzido
em 4,69% e a padronização do CFU ocasionou na eliminação de 21,31% das observações em
relaçã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,
representando uma redução de 66,15% em relação ao total original de 2.520 palavras. Com a
geraçã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 do
CFU e a padronização do CFU determinou na atenuação de 55,45% da quantidade de termos.
Nesse sentido, é importante destacar que cada frase não pré-processada do conjunto de
laudos contém em média 6,30 termos. No primeiro CFU construído foi constatada uma média
de 12,01 palavras por sentença, indicando que a maioria das observações repetidas comportam
118
Figura 8.1: Avaliação dos CFU gerados por quantidade de frases.
Figura 8.2: Avaliação dos CFU gerados por quantidade de palavras.
a 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, correspondendo
a 49,50% do número total. A remoção de termos considerados irrelevantes e a lematização
resultou em 6,62 e 6,77 palavras por frase, respectivamente. A padronização do CFU acarretou
em 3,83 vocábulos por observação, constatando que esse conjunto possui frases que não estão
totalmente no formato local-característica ou local-característica-subcaracterística, as quais
119
são adicionadas a uma lista de termos não processados que poderá ser utilizada futuramente
para 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áximos
sobre os resultados da avaliação dos CFU gerados neste trabalho.
Tabela 8.1: Resultados da avaliação dos CFU gerados.
Frases
Termos
Média
63,00
542,60
Desvio-padrão
9,46
300,99
Mínimo
48
184
Máximo
71
853
Com base nesta tabela, o menor CFU construído neste trabalho contém 48 frases ou 184
termos e o maior conjunto de CFU contém 71 frases ou 853 termos. Assim, a partir da análise
das Figuras 8.1 e 8.2 é constatado que o CFU Padronizado apresenta a menor quantidade de
sentenças e de vocábulos e o CFU Normalizado contém o maior número de observações e de
palavras.
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 que
40,00% dos laudos apresentaram termos que não foram processados, pois não foram definidas
RP 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.
Tabela 8.2: Quantidade de termos não-processados.
Termo
12
15
2,0
3,0
5
acima
avaliacao
barrett
biopsia
circunferencia
cm
confluente
diafragmatico
dificultando
epiglote
especifico
espessado
extendendo
extendento
Quantidade
1
1
1
1
1
2
1
5
2
3
5
1
1
1
1
1
8
2
1
Termo
extensao
gastrico
infiltrado
junto
linear
liquido
medio
miniliase
mm
moniliase
mucosa
nao_confluente
pincamento
piriforme
presenca
profunda
quantidade
seio
–
Quantidade
2
5
1
4
6
1
1
1
2
2
5
10
1
1
1
1
1
1
–
Nessa tabela é possível constatar que os termos não-processados com maior incidência
nos laudos padronizados são nao_confluente, espessado e linear, os quais foram registrados
dez, oito e seis vezes, respectivamente. Desse modo, é importante destacar que a lista de termos
120
não-processados pode ser empregada para a definição de novos atributos, RM e RP, aumentando
a 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ção
das técnicas de processamento de textos e ao tempo estimado para a construção da stoplist, do
AP e da ontologia.
O custo computacional de cada técnica de transformação de textos aplicada no PMLM
por meio do SCC é diretamente relacionado com a quantidade de laudos utilizados para o préprocessamento e pode ser organizado de acordo com as duas fases do processo (cenários no
SCC). Na Tabela 8.3 é apresentado o custo computacional, em termos de complexidade, para a
execução de cada método do PMLM, bem como o número de operações de comparação realizadas. Como referência para o tempo de execução correspondente, considerou-se neste trabalho
um computador capaz de executar um milhão de instruções por segundo, ou seja, equivalente a
um computador com processador Intel 4004 de 1.000 KHz (Ziviani, 2010). Nessa tabela têm-se:
• NL : quantidade de laudos;
• NM C : número médio de caracteres por frase;
• NM F : número médio de frases por laudo;
• NM T : 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.798
caracteres, sendo contabilizados 39,50 por frase (NM C ). Cada frase contém em média 6,30
termos (NM T ) e cada laudo desse conjunto contém quatro frases em média (NM F ).
Tabela 8.3: Complexidade dos métodos empregados no PMLM e os respectivos valores em
número total de comparações para 100 laudos.
Método
Construção de CFU (E1)
Normalização (E2)
Remoção Stopwords (E3)
Lematização (E4)
Padronização (E5)
Mapeamento (E6)
Complexidade
O(NM C × (NM F × NL )2 + NM F × NM C × NL )
O(NM F × NM C × NL )
O(NM F × NS × NL × NM T )
O(NM F × NRL × NL × NM T )
O(NM F × NP × NL × NM T )
O(3 × NM F × NRM × NL × NM T )
No de Comparações
6.407.980
15.800
148.680
65.520
204.120
264.600
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
respectivamente. Com relação à aplicação da técnica de lematização, neste estudo de caso foram
definidas 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 cada
valor 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 Grupo
1 ("sim" ou "nao") e ao Grupo 2 ("normal" ou "anormal"), determinado duas RM para cada
atributo, totalizando 30 regras. Para o Grupo 3 ("normal", "gi", "gii", "giii" ou "giv"), foi
definido 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 completo, 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 para
mapeamentos posteriores do mesmo tipo de laudos, pode ser organizada em duas partes, de
acordo 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,84
segundos (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 segundos (30 minutos);
3. Construção do AP (Tarefa 2): 13.365 segundos (3 horas 42 minutos e 45 segundos) para
81 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
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 50
minutos e 22,54 segundos).
Para o mapeamento manual, as informações contidas nos laudos padronizados foram
transcritas 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 o
nome dos laudos e 16 para a representação dos atributos. Em seguida, o conhecimento lido em
cada um desses documentos foi transcrito manualmente para a planilha desenvolvida anteriormente, preenchendo cada atributo identificado nos laudos. O tempo médio para o mapeamento
122
foi de 95 segundos por laudo, totalizando 9.500 segundos, ou seja, aproximadamente 2 horas e
38 minutos. A este tempo estimado, é imprescindível acrescentar o custo de tempo necessário
para a definição dos atributos que irão compor a base de dados. Esta tarefa também requer a
construção e a análise de CFU, de modo que os padrões a serem mapeados possam ser identificados. Neste trabalho foi estimado o tempo de 10.560 segundos (2 horas 56 minutos) para para
esta tarefa, divididos do seguinte modo:
• 5 segundos para copiar e colar as frases de cada laudo em um aplicativo que permita
manipular 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 manual
foi de 5 horas e 34 minutos.
Para prover uma visão mais ampla sobre o desempenho comparativo entre as abordagens
de mapeamento manual e automático, na Figura 8.3 é apresentado um gráfico da relação número
de laudos (em centenas) versus minutos.
É importante relembrar que, apesar do tempo elevado para a construção das estruturas
AP, ontologia, base de dados e stoplist, essas estruturas necessitam ser definidas apenas na
primeira execução do PMLM automatizado e poderão ser reutilizadas nos mapeamentos posteriores de outros laudos do mesmo domínio. Além disso, a segunda fase do PMLM apresenta
custo extremamente baixo de execução. Em contrapartida, no mapeamento manual, o tempo
para a transcrição das informações por documento é constante e portanto, cresce linearmente
de 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 de
novos atributos, apoiado pela identificação automática dos termos não mapeados anteriormente.
Nesse contexto, é possível observar que a partir de 260 laudos, considerando documentos
com características semelhantes aos empregados neste estudo de caso, o custo de tempo para a
aplicação do PMLM automatizado será menor que o da transcrição manual (Figura 8.3).
8.5
Considerações Finais
Neste trabalho, foi construído o SCC com o intuito de automatizar o PMLM por ontologias. Para isso, foram utilizadas as tecnologias apresentadas no Capítulo 5, das quais se destaca
a linguagem JRuby, que possibilita o uso de métodos escritos nas linguagens Ruby e Java si-
123
Figura 8.3: Avaliação do desempenho em relação ao tempo para o mapeamento manual e automático.
multaneamente. Para a construção de um sistema web de forma rápida e eficiente, o principal
framework utilizado foi o Ruby on Rails (RoR).
Após a construção da solução computacional e a sua apreciação por especialistas do domínio, o sistema foi utilizado para a realização de uma avaliação experimental em um conjunto
de 100 laudos médicos artificiais de exames de EDA, apresentando resultados considerados
muito bons.
Na abordagem manual, foram mapeados todos os atributos presentes nos laudos para a
base de dados com o tempo médio de 95 segundos por documento textual, totalizando aproximadamente 2 horas e 38 minutos. Nesse sentido, o mapeamento manual apresenta-se ineficiente
quando aplicado em grandes quantidades de dados, pois é necessária a efetuação de um imenso
esforço repetitivo em um longo período, podendo acarretar em transcrições errôneas e desestimular 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 atributos 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 apresentou
124
bons resultados, ratificando com as avaliações realizadas em trabalhos anteriores. Nesse sentido, a lista de termos não processados pode ser empregada para a elaboração de novas regras
para a transformação e o mapeamento do conhecimento presente em textos médicos, tal como
os 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 textuais
processados pelo PMLM.
Sendo assim, a representação adequada de frases apresenta-se fundamental para que o
método de mapeamento seja aplicado corretamente e obtenha resultados satisfatórios. Neste trabalho, 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 laudos
pré-processados estejam representados dessa maneira.
Nesse contexto, a aplicação do PMLM automatizado apresenta-se promissora para a extração de padrões em laudos médicos e a representação do conhecimento em base de dados
estruturadas, como a tabela atributo-valor. Com o segundo cenário do SCC, a transformação
de laudos e o mapeamento de suas informações são realizadas automaticamente, sendo apenas
necessária a seleção de técnicas de processamento de textos e a existência de estruturas como a
stoplist, 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 desenvolvimento
deste trabalho, as principais contribuições e limitações do SCC e as sugestões para desenvolvimento de trabalhos futuros.
Capítulo 9
Conclusão
Atualmente, devido às grandes quantidades de informações médicas armazenadas em bases de dados em hospitais e clínicas, é fundamental o desenvolvimento de métodos e de ferramentas computacionais para auxiliar na análise e no gerenciamento desses dados. Um dos
processos que podem prover apoio nessa análise é o de Mineração de Dados (MD), que permite
a identificação de padrões contidos nos dados, os quais podem contribuir para a aquisição de
importantes conhecimentos, como: elaboração de novos medicamentos; criação e aperfeiçoamento de procedimentos médicos; novas formas para o diagnóstico e o tratamento de enfermidades; fatores que aumentam os riscos para a progressão de certas doenças; entre outros. Outra
possibilidade de uso desses padrões é a construção de modelos preditivos por meio de técnicas 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 de
exames clínicos, laboratoriais e de imagens, os quais são descritos em laudos textuais com a finalidade de representar observações a respeito do estado de saúde dos pacientes, procedimentos
médicos, medicamentos, entre outros. Esses laudos, além de serem comumente representados de forma não-estruturada, ou seja, em língua natural, podem conter, por exemplo, erros
de 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 amplamente utilizado para a transformação de laudos textuais a fim de representá-los em um formato adequado para a realização de MD, auxiliando na extração e na descoberta do conhecimento. Para possibilitar o uso do método por profissionais que não conheçam detalhadamente
o processo ou que não sejam da área computacional, como os da área de saúde, neste trabalho
foi construído um Sistema Computacional Colaborativo (SCC) para automatizar e aprimorar o
PMLM 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 qual
foram estudados conceitos relacionados ao PMLM por ontologias com a finalidade de compreender o funcionamento e as limitações do método. Para isso, foram estudadas as técnicas
125
126
e as estruturas utilizadas no PMLM, bem como foi realizado o mapeamento manual, seguindo
os métodos do PMLM em um conjunto de laudos textuais artificiais que simulam exames de
Endoscopia Digestiva Alta (EDA) para verificar detalhadamente o funcionamento do processo
e do sistema em desenvolvimento.
Após, foi realizado um estudo de caso com a finalidade de propor e desenvolver uma
ferramenta para reduzir as limitações do uso do PMLM por usuários que não fossem da área
computacional. Assim, nesse estudo foi desenvolvido um SCC com o propósito de automatizar
e de consolidar o PMLM. Nesse sistema foram construídas funcionalidades para cada fase do
método, tal como foi proposta a substituição da abordagem de transformação de textos denominada stemming pela lematização para aprimorar a representatividade dos termos presentes
nos laudos, facilitando e melhorando a padronização. A técnica de lematização passou a ser
utilizada também na segunda fase, de modo que o próprio processo de busca na ontologia e o
mapeamento para a base de dados fosse otimizado.
No SCC, foi definida uma interface gráfica web com o intuito de possibilitar o seu uso
em qualquer lugar que tenha acesso à Internet e sem a necessidade de instalação de softwares e
de configuração da máquina do usuário. Esse sistema foi organizado em dois cenários baseados
nas duas fases do PMLM e cada uma das tarefas é disponibilizada ao usuário por meio de telas
específicas de modo que cada técnica de processamento seja facilmente aplicada e os resultados
sejam visibilizados de modo direto e simples.
O SCC foi avaliado em conjunto com especialistas do domínio, os quais o consideraram
como promissor para a extração e o estudo de padrões que podem ser identificados em laudos
textuais médicos. Também, o SCC foi utilizado para avaliar o desempenho de sua aplicação em
um conjunto de laudos médicos textuais artificiais, no qual se obteve resultados considerados
muito bons.
9.1
Principais Desfechos deste Trabalho
Com a concepção do SCC e o resultado de sua avaliação, é possível obter as seguintes
conclusões:
• A automatização e a consolidação do PMLM por meio de um SCC possibilita o uso do
método por especialistas de outras áreas, como da área médica, sem a necessidade da
participaçã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
intuitiva ao usuário;
• O sistema oferece recursos que facilitam a elaboração de Regras de Padronização (RP) e
127
de Regras de Mapeamento (RM) sem a necessidade do conhecimento técnico de linguagens de marcação para representá-las;
• Para a construção de ontologias não é necessária a utilização de outras ferramentas, como
o Protégé;
• É possível reutilizar as estruturas de representação do conhecimento para a realização de
outros experimentos;
• O desenvolvimento deste trabalho foi considerado desafiante, visto que além de envolver
interdisciplinaridade, necessitou o uso de tecnologias escritas em distintas linguagens de
programação;
• A integração das técnicas de processamento de textos utilizadas no PMLM viabiliza a
realização de estudos mais completos e detalhados em conjuntos de laudos médicos por
profissionais da área de saúde;
• O SCC pode contribuir em descobertas importantes por meio da identificação e do estudo
de 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ões
Regulares (ER);
• A construção de RM pode ser realizada apenas de uma única forma (local-característicasubcaracterística). No entanto, esta forma se mostrou adequada, até o momento, do ponto
de vista dos especialistas do domínio;
• No SCC não é realizado tratamento semântico de RM para correção de erros relacionados
ao preenchimento de informações por especialistas, podendo influenciar no desempenho
da aplicação do método de mapeamento;
• O estudo de caso foi restrito a um conjunto de laudos textuais artificiais de exames de
EDA.
No SCC, foi proposta a substituição da técnica de stemming pela lematização com a finalidade de aprimorar a transformação de laudos textuais por meio do uso de regras de lematização em cada termo, modificando para sua forma canônica, mediante a substituição de
sufixos de substantivos femininos e/ou plurais por sufixos que convertem esses vocábulos para
128
substantivos masculinos e infinitivos. No entanto, existem palavras na forma canônica que
apresentam sufixos compatíveis com regras de lematização, podendo acarretar na modificação
errô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 de
uma funcionalidade no SCC que possibilite ao usuário a inclusão de exceções para as regras de
lematização, isto é, definição de uma lista de vocábulos que não devem ser processados pelo
método de lematização.
Nos laudos médicos, mesmo com a execução de técnicas como normalização, remoção de
stopwords e lematização, as frases podem apresentar algumas peculiaridades que dificultariam
a aplicação de RP durante a uniformização dos laudos, como o excesso de espaços em branco
entre 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 identificação de padrões nos termos presentes em documentos textuais. No entanto, para a inclusão
dessas expressões em RP é necessário o conhecimento técnico para a sua elaboração, que é incomum em profissionais que não sejam da área computacional e que não possuam conhecimento
detalhado do método.
Apesar do sistema facilitar a definição de atributos e de RM, no mesmo só é possível a
definição de regras apenas no formato local-característica-subcaracterística. No entanto, esta
forma se mostrou adequada, até o momento, do ponto de vista dos especialistas do domínio, pois
em trabalhos anteriores, a sua aplicação para o desenvolvimento de regras tanto para ontologias
quanto para Dicionários do Conhecimento (DC) apresentaram resultados satisfatórios ao serem
utilizados 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 preenchimento 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 valor
sim, no atributo mucosa_esofago_inferior deve ser atribuído o valor anormal. No entanto, o
SCC não garante que essas atribuições sejam feitas semanticamente corretas, isto é, se esofagite_erosiva_inferior contiver o valor "sim" é possível que mucosa_esofago_inferior seja ocupado com o valor "normal". Esse tipo de erro é causado em consequência do preenchimento
errôneo de informações em laudos textuais por parte dos especialistas. Assim, é imprescindível
a inclusão de procedimentos para a criação de regras semânticas com o propósito de aprimorar
a interpretação de RM pelo método e evitar esse tipo de erro.
Neste trabalho, a aplicação do PMLM automatizado foi limitado a um conjunto de laudos
médicos artificiais. A devida documentação para que se possa utilizar dados reais está sendo
providenciada e outros estudos de caso serão realizados após.
129
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 ontologia
para 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 realizado o planejamento para o desenvolvimento do SCC para automatizar e facilitar o uso do
processo tanto por especialistas da área de saúde quanto por profissionais de outras áreas do
conhecimento. Nesse sistema foi construída uma interface gráfica web visando facilitar o uso
do mesmo e omitir a necessidade de instalação de softwares adicionais e de configuração da
máquina por parte do usuário. Também, é destacada a facilidade do uso de cada técnica sem
a necessidade do usuário executar instruções computacionais e a disponibilidade de funcionalidades para geração de stoplists, de Arquivos de Padronização (AP) e de ontologias sem a
necessidade de conhecimento técnico sobre as linguagens utilizadas para a construção dessas
estruturas. Nessas tarefas implementadas em funcionalidades específicas é possível visibilizar os Conjuntos de Frases Únicas (CFU) gerados, facilitando a identificação de stopwords e
a elaboração de RP e de RM. Outro recurso que facilita o uso do PMLM é a possibilidade da
seleção, pelos usuários, de técnicas para a transformação dos laudos que serão processadas pelo
mé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 estruturadas
de várias formas para descrever uma mesma característica observada em exames de pacientes,
dificultado a aplicação de MD em estudos futuros. Nesse sentido, é necessária a utilização de
métodos para a redução da complexidade das sentenças desses laudos. No sistema desenvolvido
neste trabalho é disponibilizada uma funcionalidade para a construção de AP de modo ágil e
intuitivo. Com a facilidade para a definição de RP, é possível propôr vocabulários padrões para
a estruturação de laudos textuais de modo que seja reduzido e padronizado o uso de sinônimos
para descrições médicas, diminuindo a diversidade das frases.
130
A utilização do PMLM era uma atividade considerada complexa por especialistas da área
da saúde, pois exigia conhecimento técnico de vários conceitos relacionados com a área computacional, como linguagens de marcação e de programação, tal como o uso instruções computacionais para a execução de cada técnica de processamento, dificultando a realização de estudos
em conjuntos de laudos médicos. Com a automatização do processo e a disponibilidade de funcionalidades para a concepção de estruturas utilizadas no método mediante ao SCC é possível
a efetuação de estudos mais complexos e detalhados em laudos médicos, bem como construir
grandes 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 de
padrões relevantes nesses dados e na contemplação de novos conhecimentos.
Nesse contexto, durante o desenvolvimento deste trabalho foram publicados um resumo
e um artigo completo no 62o Congresso Brasileiro de Coloproctologia sob o título de "Sistema Computacional para Automatização do Processo de Mapeamento de Laudos Médicos por
Ontologias", no ano de 2013. Esse trabalho foi escolhido entre os sete melhores deste importante congresso, considerado um dos mais relevantes da área, bem como foi escolhido para ser
publicado no Journal of Coloproctology em 2014.
Também, como atividade paralela a este trabalho, foi desenvolvido um aplicativo para
dispositivos 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 fragmentos de imagens de tecidos cólicos. Os resultados referentes à construção do SCAIMED-Mobile
foram publicados no 62o Congresso Brasileiro de Coloproctologia sob o título de "Protótipo
de um Sistema Móvel para a Extração de Características em Fragmentos de Imagem de Tecido
Cólico".
É importante ressaltar também que está em fase de confecção do registro de software
do SCC para ser submetido ao Instituto Nacional de Propriedade Industrial (INPI), como um
projeto conjunto entre o Laboratório de Bioinformática (LABI), o Programa de Pós-graduação
em Sistemas Dinâmicos e Energéticos da UNIOESTE e o Serviço de Coloproctologia da Faculdade ele Ciências Médicas da UNICAMP. Posteriormente, serão também realizadas outras
publicações dos resultados finais deste trabalho
9.4
Trabalhos Futuros
Após a construção e a avaliação do sistema, foram constatados diversos trabalhos futuros
que podem trazer melhorias e aumentar a aplicabilidade do SCC. Desse modo, trabalhos futuros
incluem:
• Realizar testes em laudos médicos reais;
• Executar testes mais amplos e complexos no sistema;
131
• Disponibilizar no SCC uma funcionalidade que permita aos usuários definirem termos
que não devam ser processados pelo método de lematização;
• Incluir outras abordagens de processamento de textos para aumentar a representatividade
dos laudos médicos;
• Adicionar procedimentos de monitoramento de qualidade de dados para auxiliar na construçã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 sincronização de atributos para controlar o preenchimento da tabela atributo-valor por meio do
tratamento de possíveis erros relacionados ao preenchimento de dados em laudos textuais
por especialistas;
• Integrar o sistema com outros projetos em desenvolvimento no Laboratório de Bioinformática (LABI) da Universidade Estadual do Oeste do Paraná (UNIOESTE/Foz do
Iguaçu);
• Divulgação do trabalho por meio de publicações de trabalhos científicos, de relatórios
técnicos e de registro de software.
132
Referências Bibliográficas
Abacha, A. B. and Zweigenbaum, P. (2011). Medical entity recognition: a comparison of
semantic 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, Artech
House, 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 Intelligent Systems 21(3): 96–101.
Bodenreider, O. and Burgun, A. (2005). Biomedical ontologies, in H. Chen, S. S. Fuller, C. Friedman and W. Hersh (eds), Medical Informatics: knowledge management and Data Mining 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 a
minimal 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 baseada em Java, Bookman Companhia Editora LTDA, Porto Alegre.
Bray, T., Paoli, J., Sperberg-McQueen, C. M. and Maler, E. (1996). Extensible Markup Language (XML) 1.0, Disponível em: http://www.w3.org/TR/WD-xml-961114.html. Acesso
em: 27 de jan. 2014.
Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E. and Yergeau, F. (2006). Extensible Markup 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: 27
de jan. 2014.
Campbell, K. E. (1998). The unified medical language system: Toward a collaborative approach for solving terminologic problems, Journal of the American Medical Informatics
Association 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. and
Wu, 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 de
Ciê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. and
Wu, F. C. (2008). Metodologia de mapeamento computacional de informações médicas:
aplicação em laudos de coloscopia e manometria anorretal, 57o Congresso Brasileiro de
Coloproctologia, 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 alta
e colonoscopia para aquisição de conhecimento, Anais do VII Workshop de Informática
Médica, Belém, pp. 1–10.
Cherman, E. A., Spolaôr, N., Lee, H. D. and Wu, F. C. (2008). Mapeamento automático de
laudos médicos para extração de conhecimento, Anais do VIII Safety, Health and Environmental World Congress, Rio de Janeiro, pp. 1–1.
Chrupala, G. (2006). Simple Data-Driven Context-Sensitive Lemmatization, Procesamiento del
Lenguaje Natural 37(0): 121–127.
Chute, C. B. (2005). Medical concept representation, in H. Chen, S. S. Fuller, C. Friedman
and W. Hersh (eds), Medical Informatics: knowledge management and Data Mining in
biomedicine, Springer, New York, pp. 165–182.
Corcho, O. and Gómez-Pérez, A. (2000). A roadmap to ontology specification languages, In
Proceedings of the 12th European Workshop on Knowledge Acquisition, Modeling and
Management, 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édicos
de endoscopia digestiva alta para bases de dados estruturadas, Anais do IV Congresso da
Academia 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 ontologias, 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, Guanabara
Koogan, 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 ontology 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 de
Janeiro.
Flanagan, D. (2006). JavaScript: the definitive guide, O’Reilly Media, Sebastopol.
Fox, M., Barbuceanu, M., Gruninger, M. and Lin, J. (1998). An organizational ontology for
enterprise modeling, in M. Prietula, K. Carley and L. Gasser (eds), Simulating Organizations: 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 uma
ontologia?, 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 Proceedings 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 interchange
format 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-based
systems 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 organization, extraction, and integration, in M. T. Pazienza (ed.), Information Extraction: a
multidisciplinary approach to an emerging information technology, international summer
school, SCIE-97, Springer, New York, pp. 139–170.
Guarino, N. and Giaretta, P. (1995). Ontologies and knowledge bases: towards a terminological
clarification, in N. J. I. Mars (ed.), Towards Very Large Knowledge Bases: knowledge
building and knowledge sharing, IOS Press, Washington, pp. 25–32.
Han, J. (2005). Data Mining: concepts and techniques, Morgan Kaufmann Publishers, San
Francisco.
Harold, E. R. (1998). XML: Extensible Markup Language, IDG Books Worldwide, Foster City.
Harper,
D. (2010).
Online Etymonology Dictionary,
http://www.etymonline.com/index.php?allowedi nf rame
=
ontology. Acessoem : 21dejan.2014.
Disponível
0search
em:
=
Hendler, J. and D. L. McGuinness, D. L. (2000). The DARPA Agent Markup Language, IEEE
Intelligent Systems 15(6): 67–73.
Húngaro,
L.
(2013).
Princípios
do
Rails,
http://lucashungaro.wordpress.com/2007/11/03/principios-do-rails/.
jan. 2014.
Disponível
em:
Acesso em: 27 de
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). Construction
of an attribute-value representation for semi-structured medical findings knowledge extraction,
CLEI Electronic Journal 11(2): 1–12.
Honorato, D. F., Cherman, E. A., Lee, H. D., Monard, M. C. and Wu, F. C. (2007). Construção
de uma representação atributo-valor para extração de conhecimento a partir de informaçõ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ção do
projeto da metodologia de mapeamento de informações semi-estruturadas em uma representação atributo-valor, Technical report, Universidade de São Paulo, São Carlos.
Disponível em: http://www.icmc.usp.br/ biblio/BIBLIOTECA/relt ec/rt309.pdf
Horrocks, I. (2002). Daml+oil: a reason-able web ontology language, In Proceedings of the 8th
International 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 ontology inference 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 the semantic
web, In Proceedings of the Joint German/Austrian Conference on Artificial Intelligence, 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 the
American Society for Information Science 47(1): 70–84.
Humpheys, B. L., Lindberg, D. A. B., Schoolman, H. M. and Barnett, G. O. (1998). The unified medical language system: An informatics research collaboration, Journal of the American Medical
Informatics Association 1(5): 1–11.
Intentor (2010).
Pequeno Guia de Expressões Regulares,
http://intentor.com.br/pequeno-guia-regex/. Acesso em: 25 de nov. 2013.
Disponível
em:
Jongejan, B. and Dalianis, H. (2009). Automatic training of lemmatization rules that handle morphological changes in pre-, in- and suffixes alike, In Proceedings of the Joint Conference of the 47th
Annual Meeting of the ACL and the 4th International Joint Conference on Natural Language
Processing of the AFNLP, Suntec, pp. 145–153.
Jung, W. (2012). Aplicação de princípios de qualidade de dados durante o desenvolvimento de
um sistema computacional médico para a cirurgia coloproctológica, Dissertação de mestrado,
Universidade Estadual do Oeste do Paraná, Foz do Iguaçu.
Juršič, M., Mozetič, I. and Lavrač, N. (2007). Learning Ripple Down Rules for Efficient Lemmatization, In Proceedings of the 10th International Multiconference Information Society, Ljubljana,
pp. 206–209.
Kanis, J. and Skorkovská, L. (2010). Comparison of different lemmatization approaches through the
means of information retrieval performance, Lecture Notes in Artificial Intelligence 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, Springer Berlin, Berlin,
pp. 229–243.
Korenius, T., Laurikkala, J., Järvelin, K. and Juhola, M. (2004). Stemming and lemmatization in
the clustering of finnish text documents, In Proceedings of the Thirteenth ACM International
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ão Paulo.
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 unstructured 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 Technology for Business Intelligence, Gathering
Knowledge Discovery, Knowledge Management and Decision 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 do processo de mapeamento de laudos médicos por ontologias, 62o Congresso Brasileiro de Coloproctologia, São
Paulo, pp. 1–24.
Lewis, W. E. (2008). Software Testing and Continuous Quality Improvement, Auerbach Publications,
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 lemmatization tool
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, Alta Books,
Rio de Janeiro.
Makrehchi, M. and Kamel, M. S. (2008). Automatic extraction of domain-specific stopwords from
labeled documents, In Proceedings of the IR Research, 30th European conference on Advances
in Information Retrieval, Berlim, pp. 222–233.
McGuinness, D., Fikes, R., S., J. R. and Wilder (2000). The chimaera ontology environment, In
Proceedings of the Seventeenth National Conference on Artificial Intelligence and Twelfth Conference 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
http://michaelis.uol.com.br/moderno/portugues/index.php?lingua=portuguesportuguespalavra=morfema. Acesso em: 24 de set. 2013.
em:
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,
http://netbeans.org/about/history.html. Acesso em: 20 de nov. 2013.
Disponível
em:
Nunes, F. V. (2007). Verbal lemmatization and featurization of portuguese with ambiguity resolution
in context, Dissertação de mestrado, Universidade de Lisboa, Lisboa.
139
Nutter, C. O., Enebo, T., Sieger, N., Bini, O. and Dees, I. (2011). Using JRuby: bringing Ruby to
Java, Pragmatic Bookshelf, Raleigh.
Orengo, V. M. and Huyck, C. (2001). A stemming algorithm for portuguese language, In Proceedings 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 for automated
word lemmatisation, AI Communications 21(1): 15–26.
Porter, M. F. (1997). Readings in information retrieval, Morgan Kaufmann Publishers, San Francisco,
chapter An Algorithm for Suffix Stripping, pp. 313–316.
Pressman, R. (ed.) (2011). Engenharia de Software: uma abordagem profissional, Makron Books,
São Paulo.
Rezende, S. (ed.) (2003). Sistemas Inteligentes: fundamentos e aplicações, Editora ManoleManole,
Barueri.
Ruby, S., Thomas, D., Hansson, D. H., Breedt, L., Clark, M., Davidson, J. D., Gehtland, J. and
Schwarz, 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 de nov. 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ópicos para
bases de dados, Anais do II Congresso da Academia Trinacional de Ciências, Foz do Iguaç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.
van Harmelen, F. and Horrocks, I. (2000). Questions and answers on oil: the ontology inference layer
for the semantic web, Disponível em: http://web.squ.edu.om/med-Lib/med/net/e-pathwaysnet/Docs/OIL%20FAQ.htm. Acesso em: 13 de mar. 2014.
140
van Kesteren, A., Gregor, A., Russel, A. and Berjor, R. (2014).
http://www.w3.org/TR/dom/. Acesso em: 23 de mai. 2014.
W3c dom4, Disponível em:
Wainwright, P. C., Cozens, S., Calpini, A., Corliss, A. and Merelo-Guervos, J. J. (2001). Professional
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 techniques,
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 utilizando ontologias 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ção
Experimental do Estudo de Caso
A.1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Stoplist
<?xml version="1.0" encoding="UTF−8" standalone="no"?>
<stopwords number="59">
<stopword>\(</stopword>
<stopword>\)</stopword>
<stopword>,</stopword>
<stopword>−</stopword>
<stopword>\?</stopword>
<stopword>a</stopword>
<stopword>alimentares</stopword>
<stopword>ao</stopword>
<stopword>aparelho</stopword>
<stopword>aproximadamente</stopword>
<stopword>area</stopword>
<stopword>as</stopword>
<stopword>aspecto</stopword>
<stopword>ate</stopword>
<stopword>com</stopword>
<stopword>conseguida</stopword>
<stopword>cor</stopword>
<stopword>da</stopword>
<stopword>de</stopword>
<stopword>depois</stopword>
<stopword>desde</stopword>
<stopword>dificuldade</stopword>
<stopword>do</stopword>
141
142
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
<stopword>dos</stopword>
<stopword>e</stopword>
<stopword>elevada</stopword>
<stopword>elevado</stopword>
<stopword>em</stopword>
<stopword>esparsos</stopword>
<stopword>especificas</stopword>
<stopword>espessada</stopword>
<stopword>fibrina</stopword>
<stopword>friavel</stopword>
<stopword>grande</stopword>
<stopword>o</stopword>
<stopword>observa−se</stopword>
<stopword>observado</stopword>
<stopword>ocupando</stopword>
<stopword>partir</stopword>
<stopword>passagem</stopword>
<stopword>peptica</stopword>
<stopword>pequena</stopword>
<stopword>pequenas</stopword>
<stopword>presente</stopword>
<stopword>presneca</stopword>
<stopword>progressao</stopword>
<stopword>quantidade</stopword>
<stopword>realizada</stopword>
<stopword>regiao</stopword>
<stopword>residuo</stopword>
<stopword>residuos</stopword>
<stopword>se</stopword>
<stopword>situada</stopword>
<stopword>situado</stopword>
<stopword>sua</stopword>
<stopword>suas</stopword>
<stopword>tambem</stopword>
<stopword>tipo</stopword>
<stopword>uma</stopword>
</stopwords>
143
A.2
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
Arquivo de Padronização
<?xml version="1.0" encoding="UTF−8" standalone="no"?>
<pattern number="81">
<synonym n="12">
<old>normal toda extensao</old>
<new>esofago_superior normal</new>
<new>terco_proximal presenca_edema nao</new>
<new>terco_proximal presenca_erosao nao</new>
<new>terco_proximal presenca_ulcera nao</new>
<new>esofago_medio normal</new>
<new>terco_medio presenca_edema nao</new>
<new>terco_medio presenca_erosao nao</new>
<new>terco_medio presenca_ulcera nao</new>
<new>esofago_inferior normal</new>
<new>terco_distal presenca_edema nao</new>
<new>terco_distal presenca_erosao nao</new>
<new>terco_distal presenca_ulcera nao</new>
</synonym>
<synonym n="2">
<old>calibre distensibilidade normal</old>
<new>esofago calibre normal</new>
<new>esofago distensibilidade normal</new>
</synonym>
<synonym n="1">
<old>teg nivel pincamento diafragmatico</old>
<new>teg normal</new>
</synonym>
<synonym n="1">
<old>teg\s∗proximo\s∗pincamento\s∗diafragmatico</old>
<new>teg normal</new>
</synonym>
<synonym n="1">
<old>teg.∗0[,.]5\s∗cm\s∗[acima]∗\s∗pincamento\s∗diafragmatico</old>
<new>teg normal</new>
</synonym>
<synonym n="1">
<old>teg.∗1[,.]0\s∗cm\s∗[acima]∗\s∗pincamento\s∗diafragmatico</old>
<new>teg gi</new>
</synonym>
144
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
<synonym n="1">
<old>teg.∗1[,.]5\s∗cm\s∗[acima]∗\s∗pincamento\s∗diafragmatico</old>
<new>teg gi</new>
</synonym>
<synonym n="1">
<old>teg.∗2[,.]0\s∗c(m)∗\s∗[acima]∗\s∗pi(n)∗camento\s∗diafragmatico</old
>
<new>teg gi</new>
</synonym>
<synonym n="1">
<old>teg.∗2[,.]5\s∗cm\s∗[acima]∗\s∗pincamento\s∗diafragmatico</old>
<new>teg gi</new>
</synonym>
<synonym n="1">
<old>teg.∗3[,.]0\s∗cm\s∗[acima]∗\s∗pincamento\s∗diafragmatico</old>
<new>teg gii</new>
</synonym>
<synonym n="1">
<old>teg.∗3[,.]5\s∗cm\s∗[acima]∗\s∗pincamento\s∗diafragmatico</old>
<new>teg gii</new>
</synonym>
<synonym n="1">
<old>teg.∗4[,.]0\s∗cm\s∗[acima]∗\s∗pincamento\s∗diafragmatico</old>
<new>teg gii</new>
</synonym>
<synonym n="1">
<old>teg.∗4[,.]5\s∗cm\s∗[acima]∗\s∗pincamento\s∗diafragmatico</old>
<new>teg giii</new>
</synonym>
<synonym n="1">
<old>teg.∗5[,.]0\s∗cm\s∗[acima]∗\s∗pincamento\s∗diafragmatico</old>
<new>teg giii</new>
</synonym>
<synonym n="1">
<old>teg.∗5[,.]5\s∗cm\s∗[acima]∗\s∗pincamento\s∗diafragmatico</old>
<new>teg giii</new>
</synonym>
<synonym n="1">
<old>teg.∗6[,.]0\s∗cm\s∗[acima]∗\s∗pincamento\s∗diafragmatico</old>
<new>teg giii</new>
145
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
</synonym>
<synonym n="1">
<old>(presenca\s∗)∗ponto[s]∗\s∗(placa[s]∗\s∗)∗esbranquicado[s]∗</old>
<new>anormal</new>
</synonym>
<synonym n="1">
<old>(presenca\s∗)∗placa[s]∗\s∗(ponto[s]∗\s∗)∗esbranquicado[s]∗</old>
<new>anormal</new>
</synonym>
<synonym n="1">
<old>tipo\s∗gastrico</old>
<new>anormal</new>
</synonym>
<synonym n="1">
<old>enantema</old>
<new>presenca_edema sim</new>
</synonym>
<synonym n="1">
<old>proximo\s∗teg</old>
<new>terco_distal</new>
</synonym>
<synonym n="1">
<old>(presenca\s∗)∗polipo(\s∗\d∗mm)</old>
<new>anormal</new>
</synonym>
<synonym n="1">
<old>(presenca\s∗)∗cord[o]∗ao\s∗va[r]∗icoso[s]∗</old>
<new>anormal</new>
</synonym>
<synonym n="1">
<old>fibrino</old>
<new>anormal</new>
</synonym>
<synonym n="1">
<old>(coloracao\s∗)∗esbranquicado</old>
<new>anormal</new>
</synonym>
<synonym n="1">
<old>16\s∗cm\s∗[da]∗\s∗ad[s]∗</old>
<new>terco_proximal</new>
146
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
</synonym>
<synonym n="1">
<old>17\s∗cm\s∗[da]∗\s∗ad[s]∗</old>
<new>terco_proximal</new>
</synonym>
<synonym n="1">
<old>18\s∗cm\s∗[da]∗\s∗ad[s]∗</old>
<new>terco_proximal</new>
</synonym>
<synonym n="1">
<old>19\s∗cm\s∗[da]∗\s∗ad[s]∗</old>
<new>terco_proximal</new>
</synonym>
<synonym n="1">
<old>20\s∗cm\s∗[da]∗\s∗ad[s]∗</old>
<new>terco_proximal</new>
</synonym>
<synonym n="1">
<old>21\s∗cm\s∗[da]∗\s∗ad[s]∗</old>
<new>terco_proximal</new>
</synonym>
<synonym n="1">
<old>22\s∗cm\s∗[da]∗\s∗ad[s]∗</old>
<new>terco_proximal</new>
</synonym>
<synonym n="1">
<old>23\s∗cm\s∗[da]∗\s∗ad[s]∗</old>
<new>terco_medio</new>
</synonym>
<synonym n="1">
<old>24\s∗cm\s∗[da]∗\s∗ad[s]∗</old>
<new>terco_medio</new>
</synonym>
<synonym n="1">
<old>25\s∗cm\s∗[da]∗\s∗ad[s]∗</old>
<new>terco_medio</new>
</synonym>
<synonym n="1">
<old>26\s∗cm\s∗[da]∗\s∗ad[s]∗</old>
<new>terco_medio</new>
147
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
</synonym>
<synonym n="1">
<old>27\s∗cm\s∗[da]∗\s∗ad[s]∗</old>
<new>terco_medio</new>
</synonym>
<synonym n="1">
<old>28\s∗cm\s∗[da]∗\s∗ad[s]∗</old>
<new>terco_medio</new>
</synonym>
<synonym n="1">
<old>29\s∗cm\s∗[da]∗\s∗ad[s]∗</old>
<new>terco_medio</new>
</synonym>
<synonym n="1">
<old>30\s∗cm\s∗[da]∗\s∗ad[s]∗</old>
<new>terco_distal</new>
</synonym>
<synonym n="1">
<old>31\s∗cm\s∗[da]∗\s∗ad[s]∗</old>
<new>terco_distal</new>
</synonym>
<synonym n="1">
<old>32\s∗cm\s∗[da]∗\s∗ad[s]∗</old>
<new>terco_distal</new>
</synonym>
<synonym n="1">
<old>33\s∗cm\s∗[da]∗\s∗ad[s]∗</old>
<new>terco_distal</new>
</synonym>
<synonym n="1">
<old>34\s∗cm\s∗[da]∗\s∗ad[s]∗</old>
<new>terco_distal</new>
</synonym>
<synonym n="1">
<old>35\s∗cm\s∗[da]∗\s∗ad[s]∗</old>
<new>terco_distal</new>
</synonym>
<synonym n="1">
<old>36\s∗cm\s∗[da]∗\s∗ad[s]∗</old>
<new>terco_distal</new>
148
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
</synonym>
<synonym n="1">
<old>37\s∗cm\s∗[da]∗\s∗ad[s]∗</old>
<new>terco_distal</new>
</synonym>
<synonym n="1">
<old>38\s∗cm\s∗[da]∗\s∗ad[s]∗</old>
<new>terco_distal</new>
</synonym>
<synonym n="1">
<old>39\s∗cm\s∗[da]∗\s∗ad[s]∗</old>
<new>terco_distal</new>
</synonym>
<synonym n="1">
<old>40\s∗cm\s∗[da]∗\s∗ad[s]∗</old>
<new>terco_distal</new>
</synonym>
<synonym n="1">
<old>area\s∗esbranquicado</old>
<new>anormal</new>
</synonym>
<synonym n="1">
<old>calibre\s∗aumentado</old>
<new>calibre anormal</new>
</synonym>
<synonym n="1">
<old>fino\s∗calibre</old>
<new>calibre anormal</new>
</synonym>
<synonym n="1">
<old>1/3 superior</old>
<new>terco_superior</new>
</synonym>
<synonym n="1">
<old>hiperemia</old>
<new>anormal</new>
</synonym>
<synonym n="3">
<old>toda extensao anormal</old>
<new>esofago_superior anormal</new>
149
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
<new>esofago_medio anormal</new>
<new>esofago_inferior anormal</new>
</synonym>
<synonym n="1">
<old>(mucoso\s∗)∗terco\s∗distal</old>
<new>terco_distal</new>
</synonym>
<synonym n="1">
<old>(presenca\s∗)∗erosao</old>
<new>presenca_erosao sim</new>
</synonym>
<synonym n="1">
<old>(lesao\s∗)∗ulcerado(\s∗lesao)∗</old>
<new>presenca_ulcera sim</new>
</synonym>
<synonym n="1">
<old>(mucoso\s∗)∗terco\s∗medio</old>
<new>terco_medio</new>
</synonym>
<synonym n="1">
<old>presenca\s∗ulcera</old>
<new>presenca_ulcera sim</new>
</synonym>
<synonym n="1">
<old>edematoso</old>
<new>presenca_edema sim</new>
</synonym>
<synonym n="1">
<old>estenose</old>
<new>anormal</new>
</synonym>
<synonym n="1">
<old>(mucoso∗\s∗)∗terco\s∗proximal</old>
<new>terco_proximal</new>
</synonym>
<synonym n="1">
<old>terco(\s|_)∗superior</old>
<new>esofago_superior</new>
</synonym>
<synonym n="3">
150
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
<old>nao presenca lesao</old>
<new>esofago_inferior normal</new>
<new>esofago_medio normal</new>
<new>esofago_superior normal</new>
</synonym>
<synonym n="1">
<old>nao\s∗confluente</old>
<new>nao_confluente</new>
</synonym>
<synonym n="2">
<old>terco(\s|_)∗medio\s∗((presenca erosao)|(presenca_erosao sim))\s∗(
terco_distal|(32 cm ad))\s∗(anormal|estenose)</old>
<new>terco_medio presenca_erosao sim</new>
<new>esofago_inferior anormal</new>
</synonym>
<synonym n="2">
<old>terco(\s|_)∗proximal\s∗(anormal|(presenca cordao varicoso))\s∗medio\
s∗grosso\s∗calibre</old>
<new>esofago_superior anormal</new>
<new>esofago calibre anormal</new>
</synonym>
<synonym n="2">
<old>terco(\s|_)∗medio\s∗((presenca\s∗cordao\s∗varicoso)|anormal)\s∗
medio\s∗calibre</old>
<new>esofago_medio anormal</new>
<new>esofago calibre normal</new>
</synonym>
<synonym n="1">
<old>terco(\s|_)∗distal\s∗(mucos(a|o)∗)∗\s∗(esbranquicado|anormal)</old>
<new>esofago_inferior anormal</new>
</synonym>
<synonym n="1">
<old>((proximo\s∗teg\s∗)|terco_distal\s∗)pincamento\s∗diafragmatico\s∗ (((
presenca\s∗)∗polipo(\s∗\d∗mm))|\s∗anormal)</old>
<new>esofago_inferior anormal</new>
</synonym>
<synonym n="2">
<old>teg\s∗((40\s∗cm\s∗ad\s∗)|terco_distal\s∗) proximo\s∗pincamento\s∗
diafragmatico\s∗(presenca_erosao|erosao)</old>
<new>teg normal</new>
151
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
<new>terco_distal presenca_erosao sim</new>
</synonym>
<synonym n="2">
<old>presenca(\s∗|_)ulcera\s∗(sim\s∗)∗ ((30\s∗cm\s∗ad\s∗)|terco_distal\s∗) (
presenca)∗(\s∗|_)erosao\s∗</old>
<new>terco_distal presenca_ulcera sim</new>
<new>terco_distal presenca_erosao sim</new>
</synonym>
<synonym n="2">
<old>terco(\s|_)∗medio\s∗azul\s∗medio\s∗calibre</old>
<new>esofago_medio anormal</new>
<new>esofago calibre normal</new>
</synonym>
<synonym n="2">
<old>medio\s∗calibre\s∗alzul\s∗sinal\s∗vermelho∗\s∗ausente\s∗terco(\s|_)∗
medio</old>
<new>esofago calibre normal</new>
<new>esofago_inferior anormal</new>
</synonym>
<synonym n="1">
<old>^motilidade</old>
<new>esofago motilidade</new>
</synonym>
<synonym n="2">
<old>terco(\s|_)∗medio\s∗presenca(\s|_)∗erosao\s∗(sim\s∗)∗(32\s∗cm\s∗ad|
terco_distal|esofago_inferior)\s∗(estenose|anormal)</old>
<new>terco_medio presenca_erosao sim</new>
<new>esofago_inferior anormal</new>
</synonym>
<synonym n="2">
<old>((terco(\s|_)∗distal)|esofago_inferior)\s∗((coloracao\s∗esbranquicado\s
∗)|anormal\s∗)presenca(\s|_)∗erosao</old>
<new>esofago_inferior anormal</new>
<new>terco_distal presenca_erosao sim</new>
</synonym>
<synonym n="2">
<old>((terco(\s|_)∗distal)|esofago_inferior)\s∗((coloracao\s∗esbranquicado\s
∗)|anormal\s∗)(presenca_edema|edematosa)</old>
<new>esofago_inferior anormal</new>
<new>terco_distal presenca_edema sim</new>
152
348
349
350
351
352
353
354
355
</synonym>
<synonym n="3">
<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>
<new>terco_distal presenca_erosao sim</new>
<new>esofago_inferior anormal</new>
<new>esofago calibre anormal</new>
</synonym>
</pattern>