as a PDF

Interoperabilidade Semântica na Troca de
Informações de Segunda Opinião Diagnóstica
D. F. Pires1, R. A. Halah2, E. E. S. Ruiz3
1
UniCOC – Ribeirão Preto – SP – [email protected]
SH Clínicas – Ribeirão Preto - SP – [email protected]
3
DFM – FFCLRP – USP – Ribeirão Preto – [email protected]
2
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
1
uma base de conhecimento , 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
2
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
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.
3
Framework) e OWL (Ontology Web Language)
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
3
http://www.w3.org/RDF
http://www.w3.org/2004/OWL/
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
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
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
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
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
4
laboratório ImagCom em , 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
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
5
ImagCom em . 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
6
disponíveis em . 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á
7
disponível em .
5
http://143.107.220.180/SODOnt/api/RDF
http://143.107.220.180/SODOnt/api/classes
7
http://143.107.220.180/SODOnt/api/javadoc
6
4
http://143.107.220.180/SODOnt/api/OWL
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/08274-0), 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. 264—271. 1. 2004.
[2] Ho, K. and et al. Videoconferencing for telehealth:
Unexpected challenges and unprecedented opportunities. In
British Columbia Medical Journal. pp. 133-140. 46. 6. 2004.
[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. 1. 2005.
[4] Barnett, G.O. and et al. COSTAR: A computer-based
medical information system for ambulatory care. Proceedings
of the IEEE. Pp. 1226-1237. 67. 1979.
[5] Lipscomb, C. E. Medical Subject Headings (MeSH). Journal
of the Medical Library Association. Pp. 265-266. 88. 3. 2000.
[6] Cote, R.A. and et al. The Systematized Nomenclature of
Human and Veterinary Medicine: SNOMED International.
Northfield, IL: College of American Pathologists, 1993.
[7] McCray, A. T. An Upper-Level Ontology for the Biomedical
Domain. Comparative and Functional Genomics. Pp. 80-84. 4.
1. 2003.
[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. 1-6. 1. 1996.
[9] HL7 Reference Information Model, http://www.hl7.org/.
2006.
[10] Schuyler, P. L. and et al. The UMLS Metathesaurus:
representing different views of biomedical concepts. Journal of
the Medical Library Association. Pp. 217-222. 2. 81. 1993.
[11] Rector, A.L. and et al. OpenGALEN: open source medical
terminology and tools. Proceedings of the American Medical
Informatics Association Annual Symposium. Pp. 982. 1. 2003.
[12] Noy, N.F. and McGuinness, D. L. Ontology Development
101 - A guide to creating your first ontology. KSL Technical
Report. Stanford University. 2001.
[13] Jena – A Semantic Web Framework for Java. Disponível
na Internet em http://jena.sourceforge.net/