Adquisición de conocimiento médico para aplicaciones en telemedicina

M. Taboada1, J.L. González1, M. Argüello1, J. Des2, J. Mira3 and D. Martínez4

1
Dpto. de Electrónica e Computación. Edificio Monte da Condesa, Campus Sur. Universidade de Santiago de
Compostela. 15782 Santiago de Compostela. Spain. E-mail: chus@dec.usc.es,
http://aiff.usc.es/~elchus/chus.html
2
Servicio de Oftalmología. Hospital Comarcal de Monforte. Monforte. Spain
3
Dpto. de Inteligencia Artificial. UNED. Madrid. Spain
4 Dpto. de Física Aplicada. Universidade de Santiago de Compostela. Spain

Resumen

La calidad del diagnóstico en telemedicina puede mejorarse si existe un modelo de

conocimiento subyacente. El desarrollo de dichos modelos puede hacerse de manera
estructurada y coherente si usamos alguna metodología de la Ingeniería de
Conocimiento. Si además, la metodología elegida se aplica orientada a la reutilización
de componentes y modelos de conocimiento, los beneficios aportados pueden ser
varios: 1) disminución del tiempo de desarrollo y de los costes implicados en la
construcción de la aplicación, 2) ayuda en la etapa de adquisición de conocimiento y 3)
obtención de un sistema con terminología estándar y común, lo cual facilitará compartir
y reutilizar su conocimiento con otros sistemas.

1 Introducción

Un posible enfoque en cuanto a los sistemas de telemedicina, que puede ayudar en gran
medida a mejorar la calidad y rapidez del diagnóstico y tratamiento de pacientes, es el
uso de aplicaciones inteligentes basadas en conocimiento, conocidas como Sistemas
Basados en Conocimiento (SBC). Dichas aplicaciones disponen de un modelo de
conocimiento conocido como base de conocimiento donde se recoge información sobre
objetos, propiedades y relaciones del dominio de interés, esto es, en nuestro caso,
información sobre síntomas, signos, patologías, etc., y las propiedades y relaciones
entre los mismos. Además, los SBC cuentan con información relevante sobre cómo
resolver la tarea para la que son construidos, a partir de la información contenida en la
base de conocimiento y los datos aportados por el usuario. En la aplicación que
presentamos en este trabajo, la tarea a resolver por el sistema de conocimiento es el
diagnóstico a partir de los síntomas relatados por el paciente y los resultados de las
observaciones que se le practiquen al mismo. Este proceso de diagnóstico debe ser
cooperativo en tanto que el usuario de la aplicación debe, en todo momento, poder
disponer del control sobre los datos introducidos y del proceso de razonamiento
seguido. En el entorno médico, los SBCs permiten, pues, no sólo ayudar a un clínico en
las tareas de diagnóstico o tratamiento de pacientes, sino que además pueden ser útiles
como herramienta de aprendizaje para nuevos especialistas.

En 1991, Neches y col. [12] propusieron que la construcción de SBCs podría orientarse
a combinar y ensamblar componentes de conocimiento. Esto permitiría reutilizar y
compartir conocimiento entre diferentes sistemas, de forma que el desarrollo de nuevos
sistemas se centraría en especializar conocimiento y razonadores preexistentes para la
aplicación dada. Desde entonces, se han desarrollado muchos tipos de fuentes de
conocimiento, que podemos encontrar disponibles ‘on-line’ en el WWW. Por ello, hoy
en día, el diseño de sistemas inteligentes basado en componentes es la alternativa más
recomendada en el campo de la Inteligencia Artificial aplicada.

En este trabajo presentamos una aplicación basada en conocimiento de telemedicina

orientada a ayudar al profesional médico en las tareas de diagnóstico y tratamiento de
pacientes. La aplicación está diseñada siguiendo la metodología de ensamblado de
componentes de conocimiento, con el objetivo de facilitar compartir conocimiento con
otros sistemas Web. El ámbito clínico de aplicación seleccionado ha sido el diagnóstico
en urgencias oftalmológicas e, inicialmente, el dominio del conocido Ojo Rojo. El
diagnóstico del Ojo Rojo es una actividad muy común llevada a cabo en unidades de
cuidados primarios. Sin embargo, muchos médicos de cabecera tienen dificultades para
hacer un diagnóstico preciso. La aplicación que presentamos aquí está enfocada a
facilitar este tipo de diagnóstico en una unidad de urgencias o en una consulta
ambulatoria. Su objetivo es proporcionar algunas recomendaciones a los profesionales
que no son expertos en oftalmología, tales como [1,3]:

1. Ayudar a distinguir adecuadamente entre causas banales y serias.

2. Orientar en el tratamiento de problemas banales, ya que la mayor parte de los
casos que se presentan en este tipo de unidades son benignos (como, por
ejemplo, Conjuntivitis, Blefaritis, Hemorragia Subconjuntival o Episcleritis) y
se pueden tratar en ellas de forma eficiente.
3. Destacar aquellos casos que requieren consulta oftalmológica, tales como
Glaucoma Agudo de Ángulo Cerrado, Queratopatías, Uveítis o Escleritis}, en
cuyo caso los pacientes deben ser enviados al especialista inmediatamente.

Esta aplicación se está desarrollando con la colaboración de expertos en dominio y será

accesible vía web, por lo cual puede ser usada desde cualquier lugar. Comenzaremos
por una breve explicación de los métodos usados en el diseño de la aplicación, para
luego comentar los resultados alcanzados y exponer las conclusiones.

2 Métodos

En las últimas décadas se han construido múltiples sistemas inteligentes basados en

conocimiento en varios campos. En la mayoría de los casos, fueron diseñados sin
reutilizar el conocimiento contenido en servidores de terminología unificada, bibliotecas
de conocimiento o bases de conocimiento ya existentes. Esta forma de desarrollar
sistemas inteligentes impide compartir conocimiento, ya que los diferentes sistemas
usan conceptos diferentes para describir los mismos dominios. Además, es improbable
que estos sistemas interactúen entre sí. Sin embargo, un proceso de diseño basado en la
reutilización de componentes de conocimiento [4,7] puede proporcionar varias ventajas,
tales como guiar el proceso de adquisición de conocimiento, disminuir el tiempo de
desarrollo y los costes, y, como resultado, producir un sistema con una terminología
estándar. Esto último será beneficioso cuando se comparta y reutilice el conocimiento
de otros sistemas. Esta ventaja es de la mayor relevancia hoy en día debido a la
aparición de lenguajes orientados a la provisión de interoperabilidad en la Web, tales
como DAML+OIL [15].
La construcción de sistemas inteligentes basados en conocimiento por compartición y
reutilización de conocimiento pre-existente puede llevarse a cabo:
1. Reutilizando el conocimiento de hechos del dominio. Esto es, reutilizando
conocimiento sobre objetos, propiedades, relaciones y axiomas del dominio de
interés. El conocimiento de los hechos del dominio es específico al dominio de
que se trate, por lo que su diseño puede realizarse sin recurrir al uso de trabajos
previos. Sin embargo, su construcción mediante la reutilización de ontologías es
altamente recomendada [2]. En el campo de la Inteligencia Artificial, una
ontología es una representación formal y explícita de los conceptos, propiedades
y relaciones de un dominio. En el contexto de los SBC, una ontología
proporciona la estructura básica para el diseño de una base de conocimiento.
Algunas ventajas en la reutilización de ontologías preexistentes son [2]:
a. El proceso de desarrollo se simplifica si usamos la estructura de
conceptos proporcionada por una ontología para codificar porciones de
conocimiento.
b. La ontología formal subyacente a una base de conocimiento clarifica las
representaciones semánticas.
c. La base de conocimiento puede ser compartida con mayor fiabilidad.

2. Reutilizando conocimiento sobre los aspectos operacionales de SBC construidos

previamente. Esto incluye identificar la tarea que el sistema debe acometer y,
como resultado, la selección de patrones preexistentes de conocimiento
adecuados para la resolución de los objetivos de la tarea. Se han propuesto
algunas metodologías orientadas a la reutilización de conocimiento operacional,
tal como CommonKADS [13] o UPML [6]. Sin embargo, el desarrollo de
sistemas reutilizando y aplicando estas metodologías no es sencillo.

La reutilización de conocimiento no es un proceso directo. Aunque se han construido

muchas ontologías en varios dominios desde el inicio de los años 90, es improbable
encontrar una ontología que incluya todo el conocimiento requerido por un sistema
particular de nueva creación. En la mayor parte de los dominios existen ontologías muy
abstractas; es decir, ontologías que contienen construcciones muy generales. Sin
embargo, las aplicaciones de estos dominios requieren construcciones muy detalladas y
específicas. Así que el proceso de reutilización debe proporcionar un nexo de unión
entre cada aplicación del dominio y las ontologías generales [8]. Una opción puede ser
extraer conceptos específicos de algún servidor de terminología unificada e integrar este
conocimiento con alguna ontología genérica. Esta aproximación no es directa, ya que
generalmente el conocimiento incluido en estos servidores no está representado
formalmente; por lo cual será necesario un paso adicional consistente en la
formalización del conocimiento extraído.

En este trabajo, resumimos nuestras experiencias en cuanto a la construcción de una

base de conocimiento, mediante reutilización de conocimiento de los hechos del
dominio, aplicada a un sistema en el dominio clínico del diagnóstico en urgencias
oftalmológicas. En cuanto a la reutilización del conocimiento operacional no se aborda
en este trabajo, pero pueden consultarse otros trabajos de este grupo de investigación
como [14]. A continuación detallamos la metodología seguida en las diferentes fases de
desarrollo de la aplicación, y en la sección siguiente los resultados obtenidos siguiendo
los métodos descritos.
2.1 Adquisición de la base de conocimiento médico

En esta fase nos hemos ocupamos de la construcción de la estructura básica de la base

de conocimiento. Una base de conocimiento es una estructura jerarquizada compuesta
por los objetos del dominio, propiedades y relaciones entre los mismos. Aquí nos
ocupamos de diseñar las partes más genéricas de la estructura, necesarias para una
correcta construcción del modelo. Con el objetivo de obtener una notación lo más
estándar y consensuada posible, hemos revisado diversas fuentes de conocimiento
médico, destacando entre ellas:

1. La librería de Falasconi [5] contiene un conjunto de conceptos médicos

extraídos tanto de bibliografía como de sistemas implementados. Incluye
categorías generales de conocimiento médico, que nos permitieron dividir la
base de conocimiento en partes más manejables.
2. El servidor de conocimiento médico Unified Medical Language System (UMLS)
[9] es un conjunto de herramientas orientadas a facilitar el desarrollo de sistemas
biomédicos y a la integración de la información de distintas fuentes. Entre ellas,
hemos utilizado el Methasaurus, que contiene información sobre un gran número
de conceptos médicos, la Semantic Network, donde se clasifican todos los
objetos definidos en el anterior, y el Semantic Navigator, donde para cada
concepto se grafica todo el espacio semántico relacionado con el mismo.
3. La documentación de la Loyola University Medical Network [10] que
proporciona información sobre los componentes que se deben integrar en la
historia médica de un paciente.
4. La Clasificación Internacional de Enfermedades CIE-9-MC del Ministerio de
Sanidad y Consumo.
5. La ontología temporal y de conceptos propuesta en el proyecto EON [11].
Actualmente estamos revisando dicha ontología para su reutilización, lo que
actualizará nuestra base de conocimiento. Dicha ontología incluye un modelo
temporal, necesario para representar conocimiento dinámico de diagnóstico.
Además, la representación del modelo del paciente mejora el modelo
proporcionado por Loyola University Medical Network [10].

2.2 Proceso de desarrollo de la base de conocimiento médico

El proceso de desarrollo de una base de conocimiento puede acometerse mediante tres

alternativas distintas:

1. Un proceso de arriba a abajo (‘top-down’) comienza con la definición de los

conceptos más generales del dominio para luego especializarlos y obtener
subclases.
2. Un proceso de desarrollo de abajo a arriba (‘bottom-up’) comienza con la
definición de las clases (conceptos) más específicos, las hojas de la jerarquía,
para luego agruparlas obteniendo superclases.
3. Un proceso de desarrollo híbrido es una combinación de las dos aproximaciones
anteriores: definimos los conceptos más importantes, tanto generales como
específicos, que después generalizamos y especializamos obteniendo los
elementos intermedios de la jerarquía.
Nosotros hemos adoptado un proceso de desarrollo híbrido, que ha incluido tanto
reutilización de conocimiento como desarrollo de ciertas partes de la base de
conocimiento desde el inicio. Así, partimos de conceptos generales que hemos extraído
de la librería médica de Falasconi, de la red semántica de UMLS y de la Loyola
University Medical Network, y de conceptos específicos que hemos extraído del
Methasaurus de UMLS.

El entorno de desarrollo que hemos usado para modelar la base de conocimiento es

Protègè-2000 (http://protege.stanford.edu/). Se trata de una herramienta software de
desarrollo de sistemas basados en conocimiento, dirigida tanto a desarrolladores como a
expertos del dominio, y creada por el grupo de trabajo de Informática Médica de
Stanford.

2.3 Adquisición del modelo del dominio

En esta fase abordamos adquisición del conocimiento específico al dominio concreto de

la aplicación. A partir de las entrevistas iniciales con los expertos clínicos, se llegó a la
conclusión de que la manera más eficiente de adquirir el conocimiento era centrar
dichas entrevistas en torno a las plantillas (formularios), usadas por el médico para
recoger la información del paciente, la llamada historia clínica.

3 Resultados

La aplicación de los métodos descritos en la sección anterior han posibilitado que

nuestra base de conocimiento contenga gran cantidad de información relevante al
dominio de las urgencias oftalmológicas y permita la realización de varias tareas. Las
detallamos a continuación.

3.1 Alcance de la base de conocimiento

En la actualidad, nuestra base de conocimiento recoge información sobre más de 600

patologías oftalmológicas, más de 30 síntomas y alrededor de 200 signos exploratorios,
así como abstracciones de estados clínicos, pruebas exploratorias, etc.

3.2 Desarrollo de la base de conocimiento

De acuerdo a las categorías genéricas propuestas por Falasconi [5], la base de

conocimiento se ha descompuesto en varias partes: "Paciente genérico", "Test",
"Hallazgos y Abstracciones del Estado Clínico" y "Patologías y Fármacos". En lo que
sigue, mostramos cada una de estas partes, indicando como hemos reutilizado el
conocimiento en las mismas.

Paciente Genérico Esta parte modela las actividades que el médico realiza con cada
paciente, incluyendo los datos que identifican al paciente y su historia médica. La
mayor parte del conocimiento de esta parte ha sido modelado y formalizado a partir de
[10]. En cada visita, el médico deberá interrogar al paciente, realizando lo que se conoce
como ‘Anamnesis’, y preguntará al menos por la historia de la enfermedad actual,
incluyendo el motivo principal y un conjunto de síntomas adicionales. Si además, se
trata de la primera visita, el médico registrará la mayor información posible sobre su
historia médica pasada, y sus historias familiar y psicosocial. En la figura 1 puede verse
algunas de las jerarquías de conocimiento modeladas, junto con los atributos diseñados
para ‘anamnesis’ usando la herramienta PROTEGE-2000.

Fig. 1. Modelado de la base de conocimiento mediante el uso de la

herramienta PROTEGE-2000

Test Esta parte ontológica modela las actividades que los diferentes agentes médicos
llevan a cabo en relación con el cuidado de sus pacientes. En UMLS se distinguen tres
tipos de actividades relativas al cuidado de la salud: ‘Diagnostic Procedures’,
‘Laboratory tests’ y ‘Therapeutics’ (o ‘Preventatives’). En nuestra ontología hemos
usado conocimiento de ‘Diagnostic Procedures’, pues en éstos se engloban las tareas
centrales en el diagnóstico de urgencias oftalmológicas.

Hallazgos y abstracciones del estado clínico En esta parte modelamos todo lo que, en
relación con el ojo, puede ser directamente observado o medido (‘Finding’, tal y como
se define en UMLS); además de todo lo que, en un nivel de abstracción más alto, se
obtiene a través de algún tipo de razonamiento a partir de los anteriores (‘Clinical State
Abstraction’). UMLS no realiza claramente esta diferenciación que, sin embargo, la
recoge la librería de Falasconi.

Patologías y fármacos Esta parte se ocupa del modelado de conocimiento sobre

patologías y drogas. Las patologías describen las enfermedades como un proceso
clínico, que, en nuestro caso, es descrito basándose en los valores que pueden ser
tomados por el conjunto de’Findings’ y de ‘Clinical State Abstractions’, a través de sus
valores de sensibilidad y especificidad. En este caso, hemos extraído el conocimiento de
la CIE-9-MC. Además, hemos reutilizado el concepto ‘Pharmacological Substances’ de
UMLS, que contiene las substancias utilizadas en la exploración oftalmológica, para
modelar el conocimiento sobre drogas, ya que incluye todos los tipos requeridos.

3.3 El entorno KEAM (Knowledge Engineering Applied to Medicine)

KEAM es un prototipo de SBC accesible vía web que está siendo desarrollado en la
actualidad, y que pretende llegar a ser un sistema de telediagnóstico. Técnicamente,
puede considerarse que se trata de una aplicación cliente servidor construida para web y
basada en una base de datos. El prototipo cuenta con varios niveles de acceso (figura 2):
ingeniero de conocimiento, experto del dominio y usuario (profesional médico no
experto). Actualmente se están implementando, habilitando y evaluando en KEAM
opciones que permiten tanto la adquisición de la estructura del modelo (base de
conocimiento) como la adquisición del modelo del dominio.

Fig. 2. Niveles de acceso al entorno KEAM

El servidor web de la aplicación KEAM reside físicamente en la Universidad de

Santiago de Compostela y, puesto que todavía se encuentra en fase de desarrollo, se
encuentra generalmente fuera de la Red. En ocasiones puntuales, es accesible desde
Internet con motivo de:
• Realizar conexiones de prueba para evaluar los tiempos de acceso y tiempos de
respuesta de la aplicación.
• Valorar la interfaz visual en desarrollo. El diseño de ésta se realiza atendiendo a
criterios de sencillez y facilidad de uso y permite interaccionar con el contenido
de la aplicación, de forma análoga a como lo hace el entorno de ventanas de
Microsoft Windows.
3.4 Obtención del Modelo del Dominio

El prototipo en uso de KEAM permite (figura 3):

• Desarrollar más de una única plantilla de historia clínica electrónica, que

posibilite recoger la información de una Anamnesis General, una Anamnesis
Diabetes, etc.
• Exportar componentes entre las distintas plantillas de historia clínica electrónica.
Por ejemplo, que una ‘Anamnesis’ de Diabetes pueda tomar elementos de una
‘Anamnesis’ General.
• Usar de forma inmediata una plantilla de historia clínica electrónica una vez
configurada o re-configurada, dado que siempre es posible efectuar
modificaciones.
• Decidir en tiempo real el siguiente paso a realizar. Así, moverse por el entorno
visual de las plantillas de historia clínica electrónica es como navegar a través de
rutas preestablecidas pero no fijas.
• Conectar los componentes de las plantillas de historia clínica electrónica con el
conocimiento médico estructurado subyacente. Por ejemplo, enlazar el
elemento Patologías Previas de Antecedentes Personales con la clasificación de
patologías (CIE 9 MC).

Fig. 3. Pantalla de Keam mostrando algunas jerarquías del nivel

del dominio clínico
4 Conclusiones

Dada la analogía entre la interfaz visual de KEAM y los entornos de ventanas clásicos
del tipo Microsoft Windows (entornos de amplia difusión), la utilización de dicha
interfaz apenas necesita un proceso de aprendizaje. En este sentido, hemos recibido
valoraciones muy positivas de la interfaz visual, sobre todo teniendo en cuenta que uno
de los inconvenientes de cualquier aplicación software es el aprendizaje de uso de la
interfaz.

Con el objetivo de obtener una evaluación inicial de la implementación del prototipo

KEAM, se han probado varias conexiones desde diferentes ordenadores, obteniendo
como resultado:

• Los tiempos de acceso, esto es, el tiempo que toma el equipo cliente en cargar
totalmente la página que contiene a la aplicación oscila entre 3 y 5 segundos.
• Una vez cargadas, las páginas web permiten una alta interacción con el usuario.
Por ejemplo, podemos navegar a través de las 738 patologías introducidas en la
aplicación KEAM, sin necesidad de conectar constantemente con el servidor
para solicitar más información. El refresco de la información de un nodo, lo cual
entendemos por expandir o contraer una categoría, es casi inmediato. Debido a
esto, los tiempos de respuesta de la aplicación a la interacción con el usuario son
muy buenos.

Por todas sus funcionalidades, estimamos que KEAM es una aplicación que puede ser
usada en remoto como ayuda al diagnóstico y como aprendizaje a distancia, de manera
sencilla y con tiempos de respuesta excelentes que la convierten en una muy viable
herramienta en telemedicina.

Agradecimientos

Este trabajo ha sido financiado por la Secretaría Xeral de Investigación e

Desenvolvemento da Xunta de Galicia, mediante el proyecto de investigación
PGIDT01-PXI20608PR.

Referencias

1. Bertolini, J. and Pelucio, M. The red eye. Emerg Med Clin North Am, 13(3):561-
579, 1995.
2. Chandrasekaran, B. and Josephson, J.R. and Benjamins, R. What are ontologies,
and why do we need them? IEEE Intelligent Systems and their applications,
14(1):20-26, 1999.
3. Davey, C.C. The red eye. Br J Hosp Med, 55(3):89-94, 1996.
4. Eriksson, H. and Shahar, Y. and Tu, S.W. and Puerta, A.R. and Musen, M.A.
Task modeling with reusable problem-solving methods. Artificial Intelligence,
79(2):293-326, 1996.
5. Falasconi, S. and Stefanelli, M. A library of implemented ontologies. In Proc. of
the ECAI Workshop on comparison of implemented ontologies, Amsterdam,
1994.
6. Fensel, D. and Benjamins, R. and Motta, E. and Wielinga, B. UPML: A
Framework for knowledge system reuse. In Proceedings of the International
Joint Conference on AI (IJCAI-99), Stockholm, 1999.
7. Fensel, D. and Groenboom, R. Specifying Knowledge-based Systems with
reusable components. In Proceedings of the 9th International Conference on
Software Engineering and Knowledge Engineering (SEKE-97), Madrid, 1997.
8. Kayed, R.M. and Colomb, R.M. Extracting ontological concepts for tendering
conceptual structures. Data and Knowledge Engineering, 40:71-89, 2002.
9. National Library of Medicine. Unified Medical Language System. Bethesda,
MD, 2001
10. Lloyd, J.S. Components of the medical history. Introduction to the practice of
Medicine I. In http://www.meddean.luc.edu/lumen/MedEd/ipm/comphx1/,
August, 2001.
11. Musen, M. and Tu, S. and Das, A. and Shahar, Y. A component-based approach
to automation of protocol-directly therapy. JAMIA, 3:267-388, 1996.
12. Neches, R. and Fikes, R.E. and Finin, T. and Gruber, T.R. and Senator, T. and
Stwartout, W.R. Enabling technology for knowledge sharing. AI magazine,
12(3):36-56, 1991.
13. Schreiber, A. and Akkermans, H. and Anjewierden, A.A. and Hoog, R. and
Shadbolt, N.R. and Val de Velde, W. and Wielinga, B. Engineering and
managing knowledge. The CommonKADS methodology. The MIT Press, 1999.
14. Taboada, M. and Des, J. and Mira, J. and Marín, R. Development of diagnosis
systems in medicine with reusable knowledge components. IEEE Intelligent
Systems, 16(6):68-73, 2001.
15. van Harmelen, F. and Horrocks, I. Reference description of the {DAML+OIL}
ontology markup language. In http://www.daml.org/2001/03/reference.html,
DARPA Agent Markup Language Program, 2001