Interoperabilidade Semântica na Troca de Informações de Segunda Opinião Diagnóstica

Transcrição

1 Interoperabilidade Semântica na Troca de Informações de Segunda Opinião Diagnóstica D. F. Pires 1, R. A. Halah 2, E. E. S. Ruiz 3 1 UniCOC Ribeirão Preto SP dfpires@gmail.com 2 SH Clínicas Ribeirão Preto - SP ricardo@shclinicas.com 3 DFM FFCLRP USP Ribeirão Preto evandro@usp.br Resumo - A troca e o compartilhamento de informações clínicas entre sistemas de informação em saúde é um importante aspecto visando o aprimoramento desses sistemas com novas atividades, tais como a obtenção de segunda opinião diagnóstica de diferentes médicos, mesmo quando estes não estão disponíveis no momento da requisição. Porém, problemas de interoperabilidade semântica causados por sistemas de terminologia heterogêneos e diferentes ontologias clínicas utilizados em aplicações médicas precisam ser explorados e solucionados de modo a permitir que a atividade citada torne-se possível. Este artigo tem como objetivo explorar esses problemas de interoperabilidade semântica, e assim propor soluções com a criação de uma ontologia denominada SODOnt. Esta ontologia original é proposta para definir um vocabulário comum para médicos, e um conjunto de dados e suas estruturas para outros softwares clínicos que precisam trocar informações de segunda opinião diagnóstica em um ambiente compartilhado, orientado a serviço, e computacionalmente distribuído. Para auxiliar o uso da SODOnt nas aplicações em saúde, um conjunto de softwares foram criados: uma API Java para facilitar a criação de documentos RDF da Web Semântica, e Serviços Web que viabilizam o ambiente colaborativo. Um estudo de caso foi criado para testar o uso da SODOnt. Palavras-chave: interoperabilidade, semântica, segunda opinião diagnóstica, conhecimento. Abstract - The exchange and share of clinical knowledge among medical information systems is an important feature to improve healthcare systems with novel clinical activities, such as to obtain a second opinion diagnosis from different physicians even in when their are not available at the requested time. Semantic interoperability problems can occur because heterogeneous terminology and ontology clinical systems are applied by medical application. Therefore, these semantic interoperability problems must be explored and solved to make these new activities possible. This works aims to discuss these interoperability problems and proposes solutions with SODOnt ontology, and a set of software to help developers to use them: a SODOnt Java API that create RDF and OWL Semantic Web documents, and a set of Web services. This novel ontology is proposed to define a common vocabulary for physicians, and also a medical dataset and their structure for other clinical software in need to exchange second opinion diagnosis information in a shared, service oriented, and distributed computer environment. An acute abdominal pain use case is also presented to demonstrate SODOnt usability. Key-words: interoperability, semantic, second opinion diagnosis, knowledge. 1. Introdução Atualmente, a troca de informações clínicas entre sistemas de informação em saúde tem se tornado um importante foco de pesquisa para a área de Informática em Saúde [1]. Aplicações desta área como Prontuário Eletrônico do Paciente (PEP), Telemedicina e Sistemas de Suporte a Decisão Diagnóstica (SDD) podem se aproveitar da possibilidade de compartilhar informações clínicas. Ainda, algumas situações relevantes podem aparecer aos usuários destas aplicações, como a obtenção de segunda opinião diagnóstica, ou a troca de registros clínicos entre Sistemas de Informação Hospitalares (HIS). Especificamente, em um cenário de consulta por uma segunda opinião diagnóstica, ferramentas de comunicação baseadas na Web como comunicadores instantâneos, vídeoconferência ou ainda salas de chat podem suportar atividades clínicas remotamente [2]. Desta maneira, médicos e estudantes podem discutir valores de sintomas e diagnósticos através de um sistema digital de troca de informação; em outras palavras, esses usuários podem expressar uma segunda opinião clínica, que apenas ocorre quando estes estão todos conectados ao mesmo tempo na Internet. Uma situação interessante é quando um médico pode obter uma segunda opinião diagnóstica de um especialista mesmo que este último não esteja conectado na Internet naquele momento. Este cenário pode se tornar possível se

2 uma base de conhecimento 1, criada a partir de um conjunto de casos clínicos e de técnicas de aprendizado de máquina, puder permanecer disponível e compartilhada em um computador remoto na Internet. Desta maneira, é possível acessar e compartilhar bases de conhecimento de diferentes especialistas e consultar várias segundas opiniões diagnósticas, mesmo que os responsáveis por estas não estejam presentes no ambiente computacional [3]. De modo a trocar conhecimento clínico entre a comunidade médica na Internet para suportar a segunda opinião diagnóstica, problemas de interoperabilidade semântica precisam ser explorados, especificamente, os de incompatibilidade terminológica e ontológica. Problemas terminológicos podem ocorrer quando aplicações médicas que precisam trocar dados clínicos utilizam-se de diferentes vocabulários médicos como COSTAR [4], MeSH [5], e SNOMED CT [6]. Problemas ontológicos podem acontecer quando sistemas em saúde precisam compartilhar informações médicas e fazem uso de ontologias clínicas incompatíveis, como UMLS Semantic Network [7], Galen Common Reference Model [8], e HL7 RIM [9]. A compatibilidade sintática é também tratada neste projeto, porém não será discutida porque se considera que todos os documentos clínicos trocados entre as aplicações são representados em XML. A compatibilidade terminológica em aplicações que precisam suportar a troca de segunda opinião diagnóstica pode ser conseguida com o uso de ferramentas como o UMLS Metathesaurus [10] ou a Open Galen [11], que relacionam os conceitos médicos entre átomos de diferentes vocabulários, preservando os seus significados. Por outro lado, a compatibilidade ontológica mostra-se ainda sem solução na literatura, uma vez que as ontologias clínicas, como as citadas anteriormente, são caracterizadas como muito complexas em razão da grande quantidade de classes, de propriedades de objetos e de tipos de dados, e também de restrições. Assim, tornam-se difíceis de serem entendidas por programadores e utilizadas por aplicações. Ainda, elas não foram projetadas para definir um vocabulário comum, nem um conjunto de dados com suas estruturas de modo que médicos e outros programas possam utilizá-la para compartilhar informações de segunda opinião diagnóstica. Sendo assim, esforços devem ser realizados pela comunidade de Informática em Saúde no sentido de se criar uma ontologia para este caso em específico. O uso de especificações da Web Semântica como RDF (Resource Description 1 Contém a descrição da experiência do médico necessária para a resolução do problema. O seu conteúdo pode ser manipulado por um motor de inferência. Framework) 2 e OWL (Ontology Web Language) 3 permitem que ontologias possam ser representadas na forma de documentos na Web. E que estes documentos possam ainda expressar significado sobre seu conteúdo, podendo criar assim um ambiente na Internet onde agentes de software possam obter informações que apenas o ser humano poderia concluir. Sendo assim, essas especificações podem ser utilizadas na implementação de uma ontologia para o ambiente da Web que possa suportar o compartilhamento de segunda opinião diagnóstica. Este artigo tem como objetivo explorar esses problemas de interoperabilidade semântica, e assim propor soluções com a criação de uma ontologia denominada SODOnt, promovendo assim a compatibilidade ontológica. Esta ontologia original é proposta para definir um vocabulário comum para médicos, e um conjunto de dados e suas estruturas para outros softwares clínicos que precisam trocar informações de segunda opinião diagnóstica em um ambiente compartilhado, orientado a serviço, e computacionalmente distribuído. Para auxiliar o uso da SODOnt nas aplicações em saúde, um conjunto de softwares foram criados: uma API Java para facilitar a criação de documentos RDF da Web Semântica, e Serviços Web que viabilizam o ambiente colaborativo. Um desses serviços faz uso da UMLS Metathesaurus, promovendo assim a compatibilidade terminológica. Um estudo de caso foi criado para testar o uso da SODOnt. 2. Interoperabilidade Semântica em Sistemas de Informação em Saúde São comuns aplicações clínicas fazerem uso de diferentes sistemas de terminologia médica em razão principalmente da não existência de um sistema que seja reconhecido, aceito e adotado mundialmente pela comunidade médica. Consequentemente é difícil descobrir que dois átomos médicos diferentes e de fontes terminologicamente heterogêneas estão relacionados a um mesmo conceito. A Figura 1 ilustra um exemplo de troca de dados clínicos entre médicos localizados remotamente. Na figura, os softwares dos médicos estão utilizando sistemas de terminologia diferentes: MeSH, RxNorm, COSTAR e SNOMED CT. Todos eles representam o conceito Cholecystitis da UMLS Metathesaurus com átomos diferentes: o software que utiliza o sistema MeSH utiliza o átomo Gallbladder Inflammation para representar a Cholecystitis; já o aplicativo que faz uso do sistema COSTAR utiliza o átomo INFLAMMATION GALL BLADDER para significar o mesmo conceito; enquanto que o programa que

3 utiliza SNOMED CT utiliza o átomo Cholecystitis NOS (disorder) para exibir a Cholecystitis; e finalmente o software que faz uso do CRISP Thesaurus utiliza o mesmo átomo Cholecystitis para representar o conceito em questão. Figura 1 Cenário 1 de incompatibilidade terminológica Outro cenário de incompatibilidade terminológica é quando um mesmo átomo de fontes terminologicamente heterogêneas está relacionado a diferentes conceitos. A Figura 2 ilustra um exemplo de troca de dados clínicos entre médicos localizados remotamente. Na figura, os softwares dos médicos estão utilizando sistemas de terminologia diferentes: MeSH, MTH, e COSTAR. No sistema MeSH, COLD pode significar temperatura fria, no sistema MTH, COLD pode significar resfriado, e ainda no sistema COSTAR, COLD pode representar o acrônimo da palavra Chronic Obstructive Lung Disease. Figura 2 Cenário 2 de incompatibilidade terminológica São habituais aplicações clínicas fazerem uso de diferentes sistemas de ontologia médica em razão principalmente dos distribuidores ainda não chegarem a um consenso sobre um padrão comum de ontologia clínica. Consequentemente, as diferentes formas de se relacionar e se representar a semântica, assim como os diferentes tipos semânticos existentes, tornam a interoperabilidade entre as aplicações médicas muito difícil. A Figura 1 ilustra um exemplo de softwares médicos utilizando sistemas ontológicos diferentes: HL7 RIM, Galen, UMLS Semantic Network e xdt. Essas ontologias são caracterizadas como muito complexas em razão da grande quantidade de classes, de propriedades de objetos e de tipos de dados, e também de restrições. Assim, tornam-se difíceis de serem entendidas por programadores e utilizadas por aplicações. Ainda, elas não foram projetadas para definir um vocabulário comum, nem um conjunto de dados com suas estruturas de modo que médicos e outros programas possam utilizá-la para compartilhar informações de segunda opinião diagnóstica. Neste contexto, os aplicativos médicos que trocam dados clínicos objetivando segunda opinião médica precisam fazê-lo transferindo não somente a informação do átomo. A fim de verificar quais as outras informações necessárias para serem transferidas, um estudo foi realizado na UMLS Metathesaurus. Assim, este trabalho verificou que existem outras informações essenciais que devem ser transferidas juntamente e são relacionadas ao átomo: o identificador do átomo, os identificadores da string, do termo léxico, e do conceito, as descrições do conceito, do tipo semântico, da definição, e ainda do nome do sistema terminológico de origem. Com esse conjunto de informações este projeto criou um tipo de dados chamado de SODOntADT, e está presente na ontologia SODOnt, apresentada na próxima seção. Todos as instâncias médicas de segunda opinião diagnóstica, como sintoma, diagnóstico ou patologia, devem ser do tipo SODOntADT. 3. A ontologia SODOnt A ontologia SODOnt define um vocabulário comum para médicos e um conjunto de dados com suas estruturas para programas que precisam compartilhar informações de segunda opinião diagnóstica. SODOnt ainda propõe o compartilhamento de uma estrutura comum de informações de segunda opinião diagnóstica entre médicos e agentes de software. Suponhase que diferentes médicos contêm um conjunto de sintomas e diagnósticos. Se esses médicos compartilham e publicam os dados seguindo uma mesma ontologia, os agentes de software podem agregar e extrair informações destas sendo trocadas. Os agentes podem utilizar desta informação para responder consultas de médicos. SODOnt permite o reuso de conhecimento clínico. Por exemplo, da mesma forma que SODOnt pode reusar ontologias médicas como a rede semântica da UMLS, HL7 RIM ou Galen, outras ontologias clínicas podem reutilizar a SODOnt. Ainda, esta ontologia torna a segunda opinião diagnóstica mais explícita e mais fácil de ser utilizada por novos usuários que precisam aprender o significado dos diferentes termos neste domínio específico de aplicação. A metodologia 101 [12] para desenvolvimento de ontologias foi utilizada para se definir a SODOnt. Os resultados da execução

4 dos passos da metodologia 101 são mostrados a seguir: Qual é o domínio da ontologia? Aplicações em saúde, especificamente sistemas eletrônicos em saúde em ambientes distribuído e baseado em serviços e componentes. Qual o propósito da utilização da ontologia? Trocar informações de segunda opinião diagnóstica compostas de sinais, sintomas, e diagnósticos, e seus respectivos valores. mais sintomas do tipo SODOntADT, conforme a associação hassymptoms, e ainda informação de uma opinião diagnóstica, também do tipo SODOntADT, formalizada pela restrição hasdiagnosisopinion. A última propriedade da classe ClinicalEvaluation é opcional porque o software do médico pode não estar trocando informação da opinião diagnóstica já que a mesma está sendo requisitada. Quais os tipos de respostas a ontologia deve responder? A ontologia SODOnt está habilitada Figura 3 Ontologia SODOnt Quais as classes da ontologia? A ontologia SODOnt é composta basicamente de 3 classes ilustradas na Figura 3 e descritas como: 1) SODOntADT: Essa classe representa um tipo abstrato de dados da ontologia SODOnt e é composta de 8 propriedades: UMLS atom unique identifier, UMLS string unique identifier, UMLS lexical unique identifier, UMLS concept, UMLS concept unique identifier, UMLS semantic type, UMLS definition, e source system name. Essas propriedades são consideradas como obrigatórias para elementos que possuem como tipo a classe SODOntADT, como um Symptom Description, um Symptom Value, uma Pathology Description, ou ainda um Diagnosis Opinion; 2) Symptom: Precisa ser construído e trocado com uma descrição SODOntADT, como indicado pela restrição hassymptomdescription, e também com um conteúdo SODOntADT, como representa a restrição hassymptomcontent; e 3) ClinicalEvaluation: A classe representa todas as informações clínicas sendo transferidas para uma segunda opinião diagnóstica: uma descrição patológica do tipo SODOntADT, representada pela restrição haspathologydescription, um ou a responder os seguintes tipos de perguntas: 1) Se um elemento do tipo SODOntADT tem exatamente as 8 propriedades; 2) Se um sintoma Symptom possui um valor Symptom Value; 3) Se um valor de sintoma Symptom Value é do tipo SODOntADT; 4) Se um sintoma Symptom possui uma descrição Symptom Description; 5) Se uma descrição de sintoma Symptom Description é do tipo SODOntADT; 6) Se uma avaliação clínica Clinical Evaluation possui uma descrição patológica Pathology Description; 7) Se uma descrição patológica Pathology Description é do tipo SODOntADT; 8) Se uma avaliação clínica Clinical Evaluation possui uma ou nenhuma opinião diagnóstica DiagnosisOpinion; 9) Se uma opinião diagnóstica DiagnosisOpinion é do tipo SODOntADT; e 10) Se uma avaliação clínica Clinical Evaluation possui um ou mais sintomas Symptoms. Quem irá utilizar e manter a ontologia? Médicos, juntas médicas especializadas, e sistemas eletrônicos em saúde podem utilizar a ontologia SODOnt. O laboratório IMAGCOM, do DFM - USP - FFCLRP mantém a SODOnt. Como reutilizar ontologias existentes? Como não foi encontrada na literatura uma ontologia

5 que suporte a troca de informações de segunda opinião diagnóstica, não houve reutilização. Definição de algumas instâncias da ontologia Para exemplificar as instâncias das classes da ontologia SODOnt, foram criados exemplos clínicos da patologia de dor abdominal aguda: AcuteAbdominalPain, Vomitus, Vomit: Bilious Finding, Severities, Moderate (severity modifier), e Cholecystitis, todas instâncias da classe SODOntADT. VomitusSymptom e SeveritySymptom são instâncias da classe Symptom, e AcuteAbdominalPainEvaluation é uma instância de ClinicalEvaluation. A Figura 3 ilustra a ontologia SODOnt em sua totalidade. 4. Softwares Relacionados a SODOnt Procurando permitir e facilitar o uso da ontologia SODOnt por parte de aplicações em saúde que desejam trocar informações de segunda opinião diagnóstica, este trabalho projetou a criação de uma API em Java e de um conjunto de Serviços Web. A API em Java auxilia os programas a gerarem documentos semânticos de acordo com a ontologia SODOnt, enquanto que os Serviços Web permitem que aplicações possam criar, publicar e procurar por uma base de conhecimento, ou ainda solicitar por uma segunda opinião diagnóstica. E principalmente, permitem a compatibilidade terminológica com o uso da UMLS Metathesaurus. Esses softwares são apresentados a seguir. 4.1 Introdução aos Documentos Semânticos Para formalizar e representar a ontologia SODOnt em termos de documentos semânticos, permitindo assim que se possa trocá-los entre aplicações pela Internet, documentos OWL foram criados e estão disponíveis no endereço virtual do laboratório ImagCom em 4, respectivamente. A especificação OWL permite a criação de linhas de instrução que definem cardinalidade mínimas e máximas. Assim, pode-se definir que uma Clinical Evaluation precisa ter pelo menos 1 Symptoms e no máximo 40 Symptoms, e ainda pelo menos 0 ou 1 DiagnosisOpinion. Suponha-se que uma aplicação médica está trocando informação clínica para obtenção de uma segunda opinião diagnóstica. A Clinical evaluation é relacionada a patologia de dor abdominal aguda. Os sintomas Vomitus e Severities são um dos importantes sintomas a serem considerados e trocados neste caso, e Bilious Finding e Moderate são os seus valores, respectivamente. Ainda neste exemplo, Cholecystitis é o valor de segunda opinião diagnóstica. De modo a trocar essas informações utilizando documentos estruturados e a Web, uma instância de documento RDF é adequada neste 4 caso. A instância RDF bem-formada e válida em relação ao documento OWL da ontologia SODOnt está disponível no endereço do laboratório ImagCom em 5. Analisando o documento, é importante notar que os conceitos Acute Abdominal Pain, Vomitus, Bilious Finding, Severities, Moderate, e Cholecystitis possuem domínio SODOntADT, significando que a aplicação que receber esses dados podem entendê-los independentemente de sistema terminológico e ontológico. Para que as aplicações possam ter suporte na geração e manipulação de documentos XML como o mostrado anteriormente, um conjunto de classes em Java foi criado na forma de uma API. A essa API deu-se o nome de SODOnt Java API. Ela é apresentada a seguir. 4.2 SODOnt Java API As classes da SODOnt Java API foram construídas utilizando-se da API JAXB (Java Architecture for XML Bindind). Essa API permite que a criação e manipulação de documentos XML possam acontecer a partir de classes e métodos em Java, não tendo assim a necessidade de conhecer sobre XML. A SODOnt Java API é composta pelos seguintes componentes de software: 1) um documento XML Schema, que define as regras de construção dos documentos XML da SODOnt; 2) as classes ClinicalEvaluationType, SODOntADTType, SymptomsType e SymptomType são responsáveis pela criação dos elementos de marcação no documento XML relacionado a um instância de, respectivamente, ClinicalEvaluation, SODOntADT, Symptom, e Symptom; 3) a classe ObjectFactory permite a construção das representações Java em conteúdo XML; 4) a classe SODOntMarshal é um programa exemplo mostrando como se cria um programa em Java que gera um documento XML de acordo com a ontologia SODOnt; e 5) a classe SODOntUnMarshal é um programa exemplo ilustrando como se manipula em Java um documento XML no formato da ontologia Particularmente em relação às classes exemplo, elas podem ser muito úteis aos programadores que irão construir pela primeira vez um programa que manipula documentos XML. Todos esses componentes estão compactados no arquivo SODOntJavaAPI.jar e disponíveis em 6. Ainda, foi gerada uma documentação Java (javadoc) da API para auxiliar os programadores no uso das classes e métodos da mesma. Essa documentação está disponível em

6 4.3 Serviços Web da SODOnt Para permitir a troca de informações de segunda opinião diagnóstica entre os médicos na Web, um conjunto de 5 Serviços Web foi definido, e são apresentados a seguir: UMLS Web Service: Este serviço é utilizado para se recuperar informações da UMLS Metathesaurus. Assim, a solução proposta consegue a compatibilidade terminológica; Clinical Knowledge Creator Web Service: Este serviço é útil para se criar uma base de conhecimento clínico a partir de casos clínicos; Second Opinion Diagnosis Web Service: Este serviço é empregado na obtenção de uma segunda opinião diagnóstica; Clinical Knowledge Publish Web Service: Este serviço é utilizado para publicar e compartilhar uma base de conhecimento com a comunidade; Clinical Knowledge Discover Web Service: Este último serviço Web é útil para se descobrir uma base de conhecimento de interesse; Para se respeitar os princípios de colaboração e compartilhamento, os Serviços Web apresentados anteriormente foram publicados e podem ser descobertos de maneira universal e padronizados. Para isso, foi utilizada a especificação UDDI, e o servidor escolhido foi o IBM UDDI Registry. 5. Implementação do Estudo de Caso O estudo de caso implementado pode criar, compartilhar e consultar segunda opinião diagnóstica da patologia de dor abdominal aguda. Dois módulos de software foram criados: um módulo para uma junta médica especializada, e um outro módulo para um médico. O software da junta médica foi utilizado para se definir 40 sintomas e 14 possíveis diagnósticos. Na sequência, foram criados 211 casos clínicos de treinamento para se gerar uma base de conhecimento, que posteriormente foi compartilhada. O módulo do médico foi criado para se criar 26 casos reais de treinamento para se gerar outra base de conhecimento. Assim, pôde-se fazer um teste do médico encontrar a base de conhecimento da junta médica, e antes de se decidir por um diagnóstico, consultar uma segunda opinião a partir da base da junta médica e da sua própria base. 6. Conclusões Esse artigo objetivou discutir e propor soluções para os problemas relacionados a interoperabilidade semântica em aplicações médicas compartilhadas, distribuídas e orientadas a serviço, e que suportam atividades de dor abdominal aguda. De modo a resolver esses problemas, uma ontologia intitulada SODOnt foi definida para solucionar a compatibilidade ontológica, e um conjunto de softwares foram desenvolvidos para dar suporte ao uso da SODOnt, e também para atingir a compatibilidade terminológica com o uso da UMLS Metathesaurus. Outras ontologias médicas foram estudadas, mas não foi encontrada uma que suportasse a troca de informações relacionada a segunda opinião diagnóstica. A Jena API [13] tem sido estudada e utilizada para realização de inferências no conjunto de dados criados a partir da SODOnt. Resultados estão sendo avaliados. O uso dos Serviços Web Semânticos estão sendo implementados e testados de modo que os serviços médicos possam ser melhor compartilhados, tanto na publicação como na recuperação. Finalmente, um estudo de caso está sendo desenvolvido no contexto do projeto TIDIA-Ae, FAPESP (03/ ), com o objetivo de mostrar como a SODOnt e a comunicação multimídia podem contribuir com o ensino médico e com a melhora na qualidade das bases de conhecimento compartilhadas. Referências [1] Beyer, M. and et al. Towards a flexible, process-oriented IT architecture for an integrated healthcare network. Proceedings of the 2005 ACM symposium on Applied computing. Computer applications in health care (CAHC). Pp [2] Ho, K. and et al. Videoconferencing for telehealth: Unexpected challenges and unprecedented opportunities. In British Columbia Medical Journal. pp [3] Pires, D. F. and Halah, R. A. and Tinos, R. and Ruiz, E. E. S. An Architecture to Support Clinical Knowledge Sharing Among Medical Community via Internet. Proceedings of the V Workshop de Informática Médica. Congresso Brasileiro de Qualidade de Software [4] Barnett, G.O. and et al. COSTAR: A computer-based medical information system for ambulatory care. Proceedings of the IEEE. Pp [5] Lipscomb, C. E. Medical Subject Headings (MeSH). Journal of the Medical Library Association. Pp [6] Cote, R.A. and et al. The Systematized Nomenclature of Human and Veterinary Medicine: SNOMED International. Northfield, IL: College of American Pathologists, [7] McCray, A. T. An Upper-Level Ontology for the Biomedical Domain. Comparative and Functional Genomics. Pp [8] Rector, A.L. and et al. The Galen High Level Ontology. Proceedings of the Fourteenth International Congress of the European Federation for Medical Informatics. Pp [9] HL7 Reference Information Model, [10] Schuyler, P. L. and et al. The UMLS Metathesaurus: representing different views of biomedical concepts. Journal of the Medical Library Association. Pp [11] Rector, A.L. and et al. OpenGALEN: open source medical terminology and tools. Proceedings of the American Medical Informatics Association Annual Symposium. Pp [12] Noy, N.F. and McGuinness, D. L. Ontology Development A guide to creating your first ontology. KSL Technical Report. Stanford University [13] Jena A Semantic Web Framework for Java. Disponível na Internet em