Integración de Guías Clínicas en Sistemas de Elearning

Integración de guías clínicas
en Sistemas de eLearning
JOSÉ LUIS SANTOS ODRIOZOLA
Projecte Fi de Carrera
Director/a: Josep Blat
Toni Navarrete
Francis Casado (Fundació Barcelona Media)
Ayman Moghnieh
13-08-2007
Enginyeria en Informàtica
Universitat Pompeu Fabra
AGRADECIMIENTOS
Le agradezco su ayuda a todas las personas que han podido influir de alguna u otra manera en
el desarrollo de este proyecto, pero especialmente, quiero agradecerle su ayuda a mis
directores de proyecto.
Aprovecho, por otra parte, a agradecer a los compañeros del proyecto TENCompetence y
Opendock que aunque no hayan influido directamente en el desarrollo de este proyecto, me han
ayudado a coger energías admirando su dedicación, especialmente, Daniel Burgos, Ruud
Lemmers y Edwin Veenendaal.
Una especial dedicatoria a Dai Griffiths: “Gràcies per haver confiat en mi i la teva comprensió
amb les meves carències amb l’anglès”.
Finalmente agradecer a mis compañeros en la universidad por hacerme la estancia en la
universidad una experiencia inolvidable.
Mi familia y mi novia, Norma, unos pilares en mi vida y que me han ofrecido su soporte
incondicional.
Y la verdad, es que me dejaba a una persona muy importante y representativa en mi estancia
laboral en la universidad, Ayman Moghnieh, ha sido un estupendo coordinador, una persona
que ha pensado en mi futuro cuando no era su obligación, que ha confiado en mí, y que ha
tenido gran parte de “culpa” en la elaboración de este proyecto, en el que me ayudado en lo
que ha podido y en lo que le he pedido.A todo esto sólo puedo decirte: “‫( ” ًا آًا‬Espero que
la traducción sea correcta)
Resumen
En este proyecto se muestra el desarrollo del proceso en el modelado de guías clínicas, la

implementación de librerías que hacen factible su procesamiento y su utilidad en un entorno de
aprendizaje.
La finalidad es proveer un sistema de personalización de guías clínicas que pueda ser ejecutado
en un entorno de prevención y de actuación de enfermedades, y a su vez, proveer un simulador
que pueda ser utilizado en entornos didácticos para mejorar la efectividad en el proceso de
aprendizaje, mostrando la importancia de este tipo de herramientas en los entornos educativos.
Concretamente, este proyecto se divide en diferentes fases. Basandonos en el modelo de GLIF3,
desarrollamos un esquema, el cuál, pueda representar guías de práctica clínica, dónde se
modelará la Guía de Práctica Clínica del Cáncer Colorrectal, posteriormente, se verá la
implementación de librerías que procesen el modelado de dicha guía, y finalmente se mostrará
la importancia de esta herramienta en un entorno de aprendizaje, mostrando diversos escenarios
donde podría ser utilizada.
Resum
En aquest projecte es mostra el desenvolupament del procès en el modelatge de guíes clíniques,
la implementació de llibreríes que fan posible el seu processament i la utilitat en un entorn
d’aprenentatge.
En aquest projecte es mostra el desenvolupament del procés en el modelatge de guies clíniques,
la implementació de llibreries que fan possible el seu processament i la utilitat en un entorn
d’aprenentatge.
La finalitat es proveir un sistema de personalització de guies clíniques que pot ser executat en
un entorn de prevenció i de actuació de malalties, y a la vegada, proveir un simulador que pot
ser utilitzar en entorns didàctics per millorar la efectivitat en el procés de aprenentatge, mostrant
la importància d’aquest tipus d’eines en entorns educatius.
Concretament, aquest projecte es divideix en diferents fases. Basant-nos en el model de GLIF3,
desenvolupem un esquema, el qual, pot representar guies de pràctica clínica, on es modelarà la
Guia de Pràctica Clínica del Càncer Colorrectal, posteriorment, es veurà la implementació de
llibreries que processin el modelatge de la guia citada, i finalment es mostrarà la importància
d’aquesta eina en un entorn d’aprenentatge, mostrant diversos escenaris on podria ser utilitzada.
Índice
1. Introducción ........................................................................................................................................... 9
2. ESTADO DEL ARTE.......................................................................................................................... 11
2.1 HGML. Hypertext Guideline Markup Language............................................................................. 11
2.2 GEM (Guideline Elements Model) .................................................................................................. 13
2.3 GLIF3 .............................................................................................................................................. 15
3. ANÁLISIS DE REQUERIMIENTOS................................................................................................ 19
3.1 CASOS DE USO ............................................................................................................................. 19
3.1.1 Caso de uso crear nueva guía .................................................................................................... 19
3.1.2 Caso de usi Cargar historia clínica............................................................................................ 19
3.2 REQUERIMIENTOS ...................................................................................................................... 20
4. Planificación del proyecto ................................................................................................................... 21
5. ESPECIFICACIÓN............................................................................................................................. 23
5.1 Primera versión de la especificación................................................................................................ 24
5.2 Segunda versión en la especificación............................................................................................... 33
5.2.1 Razones para la modificación. .................................................................................................. 34
5.2.2 Cambios en la segunda versión de la especificación................................................................. 34
5.2.2.1 Guideline y Algorithm ....................................................................................................... 34
6. DESARROLLO DE LA APLICACIÓN............................................................................................ 37
6.1 Modelo............................................................................................................................................. 37
6.1.1 Clase Guideline......................................................................................................................... 38
6.1.2 Clase Algorithm. ....................................................................................................................... 39
6.1.3 Clase GuideLineStepType ........................................................................................................ 39
6.1.4 Clase ActionStep....................................................................................................................... 39
6.1.5 Clase ActionSpecification......................................................................................................... 40
6.1.6 Clase DecissionStep.................................................................................................................. 40
6.1.7 Clase DecissionOption.............................................................................................................. 40
6.1.8 Clase Criterion .......................................................................................................................... 41
6.1.9 Clase GetDataItems .................................................................................................................. 41
6.1.10 Clase Condition....................................................................................................................... 41
6.1.11 Clase DataItem........................................................................................................................ 42
6.1.12 Clase Concept. ........................................................................................................................ 42
6.1.13 Clase BranchStep .................................................................................................................... 42
6.2 Controller ......................................................................................................................................... 43
6.2.1 Controller.java .......................................................................................................................... 43
6.2.2 Search.java................................................................................................................................ 43
6.2.3 Charge.java ............................................................................................................................... 44
6.2.4 Action.java................................................................................................................................ 45
6.2.5 Decission.java ........................................................................................................................... 45
6.3 Viewer.............................................................................................................................................. 46
6.3.1 Página index.jsp ........................................................................................................................ 46
6.3.2 Página Decission.jsp ................................................................................................................. 46
6.3.3 Página Action.jsp ...................................................................................................................... 47
6.4 Recursos auxiliares .......................................................................................................................... 47
6.4.1 Paquete DAO ............................................................................................................................ 47
6.4.2 Paquete parseador ..................................................................................................................... 49
6.4.3 Paquete AuxClasses .................................................................................................................. 49
6.4.4 Paquete Test.............................................................................................................................. 50
7. Integración del sistema en un contexto de e-Learning...................................................................... 51
7.1 E-learning ........................................................................................................................................ 51
7.2 Escenario 1....................................................................................................................................... 52
7.3 Escenario 2....................................................................................................................................... 52
7.4 Escenario 3....................................................................................................................................... 52
7.5 Escenario 4....................................................................................................................................... 52
7.6 TENCompetence y arquitectura propuesta ...................................................................................... 53
7.7 Viabilidad de los escenarios con la arquitectura propuesta.............................................................. 54
8. Conclusiones y trabajo futuro............................................................................................................. 55
1. Introducción
En la actualidad, la sociedad en la que vivimos es denominada con el sobrenombre de Sociedad
de la Información y esto es debido a la gran cantidad que recibimos de ésta. Gracias a Internet,
la información es gratuita y accesible fácilmente pero sin duda, ésta por sí sola, no tiene valor.
Para que tenga una relevante importancia ha de ir acompañada de conocimiento, cómo
interpretarla y de cómo aplicarla.
Nuestra sociedad y los individuos que la conforman requieren métodos pedagógicos más
flexibles para poder adquirir ese conocimiento de una manera práctica, eficaz y fácilmente
accesible. Por esta propia necesidad evoluciona el eLearning adquiriendo una importancia
relevante para el desarrollo personal y profesional del individuo.
La tecnología en nuestra sociedad se está convirtiendo en uno de sus pilares, donde se convierte
en casi indispensable para su propio desarrollo, por ejemplo, en la medicina, vemos como cada
vez más la tecnología se va adentrando en todos sus niveles, no únicamente en el diagnóstico,
sino, también, en la gestión. Algo que parece tan necesario y tan factible como la historia
clínica, hoy en día, no está por completo digitalizada y por lo tanto no es accesible desde
cualquier centro sanitario. Pero en cambio, es un sector donde la investigación de enfermedades,
genera actualmente mucha información y conocimiento, que se perpetra mediante protocolos de
actuación, guías clínicas, etc.
En el caso más concretos de las guías clínicas, sabemos que su uso en los centros sanitarios es
bajo, a pesar de que el personal sanitario, se muestra de acuerdo con la valoración y
funcionalidad de estas.
Principalmente, esto es debido a la incapacidad de los mecanismos tradicionales para
incrementar su uso, como son las publicaciones y sesiones didácticas con el personal sanitario.
Esto es debido principalmente a tres razones, el personal sanitario no recuerda como ha de
aplicar la guía clínica en todo momento, los detalles más concretos de la guía no son accesibles
en todo momento desde el centro sanitario, y los mecanismos tradicionales de publicación de las
guías no hacen inmediata su aplicación.
Las guías clínicas, tradicionalmente, han sido distribuidas de una forma impresa como revistas
de medicina, libros o monografías de investigación. Más recientemente, las guías se han ido
publicando electrónicamente, utilizando CD-ROM o repositorios en Internet. Pero a pesar de
este pequeño avance con la publicación electrónica que favorece la accesibilidad, nos
encontramos que la mayoría siguen siendo guías documentadas con un gran contenido en texto.
Como consecuencia, es necesario muchas veces tener una formación específica previa para
entenderla o la gran cantidad de material referenciado, la convierte en una guía densa e
inaccesible.
Debido a las razones comentadas anteriormente, y por otra parte, sin olvidar, que al ser
distribuidas las guías en un lenguaje natural, estas se pueden convertir en ambiguas por su
propia naturaleza, una ventaja y desventaja, puede controlar un alto espectro de posibilidades,
pero haciendo necesario tener un alto background en la materia para poderlo aplicar. La
tecnología ha de facilitar, flexibilizar y aumentar la eficacia de las guías clínicas, creando
sistemas que cumplan estos objetivos.
Viendo estas necesidades, este proyecto tratará los siguientes objetivos. La creación de una
especificación que especifique el flujo de trabajo de la guía clínica y permita la personalización
de ésta, un player que reproduzca dicha especificación y la concepción de todo lo nombrado en
un contexto de eLearning.
Además, las guías clínicas contienen una revisión sistemática de las pruebas médicas
focalizando en un problema específico. A parte, estas proveen una visión integrada en como
tratar el problema en términos prácticos, que decisión tomar en cada situación. Toda esta
información puede ser utilizada como una fuente valiosa en un proceso de aprendizaje de
estudiantes de medicina, como también en la formación continua de los profesionales de la
medicina. Los estudios muestan que la educación basada en la práctica a través de guías y
9
10
sistemas que den soporte en las decisiones mejoran la detección de enfermedades. El artículo
“Effectiveness of educational interventions in improving detection and management of
dementia in primary care: cluster randomised controlled” [3] muestra la mejora de resultados en
la detección de problemas diabéticos y asmáticos en la asistencia primaria, mientras “Do
clinical guidelines introduced with practice based education improve care of asthmatic and
diabetic patients? A randomised controlled trial in general practices in east London” [4] muestra
los resultados en la detección de demencia en pacientes en la asistencia primaria, comparado
con otras opciones educacionales.
Los estudiantes y profesionales pueden aprender de las ejecuciones de las guías con datos reales
de pacientes. Las herramientas de simulación donde estudiantes y profesionales pueden
determinar la correcta decisión en situaciones extraidas de casos reales pueden ser muy útiles
para el aprendizaje.
Resaltar la importancia que las guías pueden aportar información valiosa a los pacientes que
están siendo examinados, y que mientras los materiales de enseñanza pueden quedar obsoletos
rápidamente, el uso de las guías, al ser continuamente actualizadas, como centro del proceso de
aprendizaje provee una aproximación mucho más dinámica.
Este proyecto se desarrolla con la colaboración del Hospital Clínic de Barcelona y el proyecto
europeo TENCompetence (Building The European Network for Lifelong Competence
Development). Y basándose en los objetivos de este proyecto, se publicó un paper “Using
clinical guidelines in an eLearning context” en el workshop “TENCompetence Open workshop
on Service Oriented Approaches and Lifelong Competence Development Infrastructures” en
Manchester el 11 y 12 de Enero de 2007.
La función de estas dos entidades colaboradores será, por parte del Hospital Clínico, la
supervisión y la validación tanto en el desarrollo del player como de la especificación, y por
parte del proyecto europeo TENCompetence, la supervisión y validación de la aplicación dentro
de un contexto de e-Learning.
11
2. ESTADO DEL ARTE

Para afrontar los objetivos anteriores, se analizaron diferentes especificaciones y herramientas
que describen el esfuerzo realizado en el intento de modelar las guías clínicas ya que la
adopción de un estándar para la solución permitirá una resultado más interoperable con
diferentes sistemas.
Desgraciadamente, ninguna de las especificaciones estudiadas ha tenido una gran difusión y los
repositorios existentes de guías clínicas contienen documentos sin estructura (archivos PDF o
similares), como el americano [1].
A pesar de los datos obtenidos en el análisis de las especificaciones, y no tener librerías abiertas
para trabajar con ellas, hemos escogido, como referencia, la especificación GLIF3, por ser la
más completa. Por el contrario, hemos tenido que adaptar nuestra especificación para cubrir
únicamente la parte de administración del flujo de decisiones, ya que GLIF3, cubre diferentes
niveles de descripción en el modelado de una guía clínica, y cubrir toda la especificación sería
un trabajo más extenso.
2.1 HGML. Hypertext Guideline Markup Language

HGML es una especificación XML/XHTML pensada para la identificación de las condiciones y
recomendaciones en las guías clínicas en modo texto.
Se basa en definir etiquetas para elementos condicionales y elementos asociados a
recomendaciones que pueden ser identificados en una guía clínica en modo texto usando un
editor. La correlación de variables condicionales, sujetas a sus restricciones, con los datos
clínicos permiten que el sistema ofrezca unas restricciones a partir del contexto original.
Los objetivos que se marcan al diseñar esta especificación son:
• Capacidad de representar guías en varios formatos a diferente nivel de detalle
permitiendo la fácil navegabilidad entre ellos.
• Capacidad para producir rápidamente recomendaciones específicas al paciente.
• Fácil integración con sistemas clínicos de información.
La idea comenzó creando un modelo simple de los elementos estructurales que se podían
identificar en documentos existentes. La guía clínica se veía como un documento que contenía
varios segmentos de información que cada uno de ellos, servía para diferentes propósitos. El
principal objetivo de una guía clínica se basa en proporcionar consejos, pero lo que interesa
relacionado a esta especificación es identificar las recomendaciones y las condiciones bajos las
cuales son aplicadas.
Esta especificación consta de unas etiquetas básicas:
<recomendation>…</recomendation>: el texto englobado en estas etiquetas se podría
considerar una recomendación.
<condition [id] [operador]>…</condition>: identifica la parte del texto que pudiera ser
considerado una condición respecto a una particular recomendación.
<statement>…</statement>: podría indicar la parte relacionada con el texto que exprese un
propósito.
<keyword>…</keyword>: permite identificar una expresión que puede estar relacionada con
un propósito o una recomendación.
Luego encontramos dentro de la especificación una serie de etiquetas que describen la lógica de
la guía:
<variable>…</variable>: identifica una porción de texto que puede ser asociada a una
particular característica del paciente, variable o parámetro.
12
<relation operador=”equal-to” [value=”value”] [min=”value”]

[max=”value”]>…</value>: equivale a una representación procesable para el texto que sirve
como función lógica de un operador tal como el “igual a”.
<reference id/>: en el lenguaje natural, a veces encontramos propósitos que hacen referencia a
condiciones que no aparecen explícitamente en el texto y que requieren una codificación como
dato adicional. Por ejemplo, se puede utilizar para referenciar otras condiciones.
Para hacer esto, se dispone de unas herramientas, el editor de etiquetaje:
Fig. 1: Captura de pantalla del markup tool.

La captura de pantalla anterior muestra como el texto queda después de ser etiquetado. En este
caso, ya se han usado las etiquetas básicas y las de lógica.
La idea es que una vez etiquetado se puedan mostrar diferentes vistas de la guía:
Fig. 2: Spatial 2D representation

13
Fig. 3. Tree view
2.2 GEM (Guideline Elements Model)

El propuesto Guideline Elements Model es un intento de proveer un modelo que oculte ciertos
detalles de una guía clínica, describiendo conceptos referentes a la representación, atributos de
conceptos y la relación entre dichos conceptos. GEM promueve la traducción de los lenguajes
naturales utilizados en las guías en lenguajes procesables por ordenadores. El framework intenta
ser útil a desarrolladores, disseminadores, implementadores de guías y usuarios finales de las
guías.
Se basa en tres principales fuentes:
• Los conceptos relacionados al desarrollo de la guía y su evaluación, el Institute of
Medicine’s Provisional Instrument for Assessing Clinical Guidelines provee una serie
de criterios para la evaluación de guías prácticas. El objetivo de este instrumento era
definir los atributos ideales para las guías, reforzando el desarrollo sistemático de las
guías, y proveer una aproximación estandarizada y una estructura para la evaluación de
los documentos que conforman la guía.
• Conceptos relacionados con la tarea de difundir de las guías, la NGC (National
Guideline Clearinghouse) provee un servicio online para guías clínicas basadas en
evidencias. Patrocinado por U.S. Agency for Healthcare Research and Quality, the
American Medical Association, and the American Association of Health Plans, provee
un esquema para la clasificación de componentes de guías clínicas. Este modelo incluye
una serie de atributos clave para poder resumir la guía para facilitar la búsqueda de
información en el NGC Web site y comparación entre guías.
• Los conceptos relacionados a la implementación de las recomendaciones de las guías,
se aplica una serie de construcciones derivadas originalmente. Esta aproximación es
usada para representar el conocimiento derivado de:
o Guías de diversas fuentes, incluyendo la American Academy Pediatrics, el
American Collage of Pgysicans, el Agency for Health Care Policy and
Research, el U.S. Preventive Services Task Force, y una administración de
organización del cuidado.
o Guías referentes a diferentes temas como la diagnosis de apendicitis, riesgos de
hipercolesterolemia, indicaciones para hacer bypass en arterias coronarias, y
control del asma.
o Guías que fueron creadas basándose en evidencias y usando concienzudas
metodologías.
14
El modelo original de GEM ha sido ampliado substancialmente y mejorado. GEM representa un

componente de la infraestructura clave para desarrollar el framework para el desarrollo de guías
reproducidas en ordenadores.
Los componentes de GEM son definidos como elementos de XML:
Fig. 4: Elementos del modelo en alto nivel

Identity: Información que identifica una particular guía y describe esta, en términos generales y
describe como ha sido desarrollada.
Developer: La organización responsable del desarrollo que la identidad describe.
Purpose: Describe principalmente los motivos esenciales para el desarrollo de la guía y las
principales prácticas que se usan.
Intended Audience: Este elemento hace referencia a que personas, trabajadores de centros
clínicos, va dirigida la guía.
Method of Development: Descripción de cómo se ha ido validando todo el proceso.
Target Population: Cubre el sector de la población que se le puede aplicar el documento.
Testing: Instituciones o grupos de personas externas a la organización desarrolladora de la guía
que han validado esta.
Revision Plan: Plazos, con fechas incluidas, de la revisión de la guía, por si se da el caso de que
existen nuevos descubrimientos que la hacen variar.
Knowledge Components: Son los elementos que se describen en la siguiente figura y su árbol
jerárquico. Son la parte que debe ser definido por los expertos en el cuidado de la salud, los tres
elementos principales, son las recomendaciones, las definiciones o glosario y el algoritmo. Es la
parte que guarda la lógica de la guía, y la que realmente guarda la funcionalidad.
Fig. 5: Elementos jerárquicos del elemento knowledge component.

15
2.3 GLIF3
GLIF3 es una metodología que permite modelar y representar guías clínicas de una forma
estructurada. El objetivo principal es que cada guía pueda ser utilizada en aplicaciones de
soporte.
Las guías modeladas en GLIF tienen tres niveles de abstracción: un organigrama que es fácil de
comprender, una especificación procesable de una manera lógica y una especificación que
puede ser incorporada a sistemas institucionales particulares de información.
GLIF3 es un modelo orientado a objetos. El modelo es descrito usando UML (Unified Modeling
Language). Ciertos datos adicionales, son representados mediante OCL (Object Constraint
Language).
El modelo a más alto nivel, lo podemos ver en la siguiente figura:
Fig. 6: Modelo GLIF. Principales clases de alto nivel.

GLIF puede ser usado en diversos tipos de guías. Las guías pueden ser clasificadas respecto al
dominio clínico que tratan, la fase del problema clínico y su gestión, tiempo (urgente o no),….
GLIF ha sido utilizado para codificar varios tipos de guía como la vacunación de la gripe,
gestión de la tos crónica, gestión de angina de pecho estable, control de tiroides, dolor de
espalda, enfermedades coronarias, depresión, neumonía comunitaria, hipertensión y migrañas.
Como expresa la siguiente figura.
16
Fig. 7. Clasificación de las guías clínicas codificadas en GLIF.

En GLIF, las guías son representadas mediante organigramas de nodos secuenciales llamados
guideline steps. Son usadas diferentes clases de guideline steps para modelar las diferentes
posibilidades que nos podríamos encontrar en un documento:
Decission_Step: Representa los puntos de decisión de la guía. Una jerarquía de clases de
decisión, proporciona la ventaja de representar diferentes modelos de decisión.
Action_Step: Se utiliza para modelar acciones que se pueden llevar a cabo. Los Action Step
contienen tareas y dos tipos de tareas pueden modelarse: acciones médicas tal como una
recomendación para un tipo de tratamiento y la recuperación de datos sobre un paciente.
Branch_Step y Synchronization_Step: Permite modelar caminos múltiples y simultáneos a
través de la guía.
Patient_State_Step: Se utilizan como puntos de entrada a la guía, por ejemplo etiquetando el
estado de un paciente (ej. Tomando un medicamento anti-hipertensivo).
La especificación GLIF incluye expresiones que son derivadas de la gramática lógica que
especifica la sintaxis de Arden. Estas expresiones se pueden utilizar para representar criterios de
decisión, eventos en forma de triggers, condiciones excepcionales, expresiones de duración, y
estados.
GLIF permite especificar ontologías médicas que a su vez permite, utilizar un vocabulario
estandarizado y referenciar a data individuales de pacientes, conocimiento médico, y acciones
clínicas. Lo cual permite el uso compartido de guías entre instituciones.
La especificación permite el uso de material adicional, asociando material didáctico en algunas
secciones. Este material adicional puede ser codificado en diferentes formatos (tal como texto
plano o HTML) y puede ser utilizado con diferentes propósitos (tal como más información para
el médico como para la educación del paciente).
Como hemos comentado antes, GLIF3 soporta tres niveles de abstracción en su representación.
Cuando una guía es creada, deriva en un primer nivel de representación (llamado nivel A). Este
nivel permite a los autores de la guía concentrarse en la conceptualización de la guía como un
17
organigrama. A este nivel de abstracción, al autor no le concierne el formalizar detalles

específicos, como los criterios de decisión, los datos relevantes del paciente y la información
iterativa que debe ser proporcionada para que la especificación sea procesada. Todos esos
detalles cogen importancia en el segundo nivel de la especificación (nivel B), donde los
conceptos médicos, la definición de los datos del paciente, los criterios lógicos y el control de
flujo son especificados formalmente. Uno de los objetivos del proyecto GLIF, es la creación de
herramientas que actúen en este nivel.
Antes de que las guías puedan ser incorporadas en un sistema propio de una institución,
acciones y datos de los pacientes tienen que ser mapeados a los procedimientos institucionales y
los formatos en que se graban los datos (EMRs). Este mapeo de información se reprenda en el
nivel de implementación (nivel C). El cuál en esta versión de la especificación no ha sido
completado.
Es decir, por ejemplo, el nombre de un atributo es especificado en el nivel A, mientras la
especificación del atributo es especificado en el nivel B. Cuando un experto en la materia
codifica una guía, el primero puede especificar los atributos en el nivel A. Después de esto, un
informático puede especificarlos en el nivel B, después de consultarlo con el experto. Todas las
clases de GLIF tienen al menos un atributo de nivel A que permite al autor describir la
construcción sin restricciones de forma narrativa.
Las expresiones lógicas (con las que se definen los criterios) y las acciones especificadas a los
datos clínicos de los pacientes y los conceptos médicos son formalmente definidos en la
ontología médica, mediante la referencia al vocabulario estandarizado (ej. UMLS - Unified
Medical Language System) y los modelos de datos médicos estandarizados (ej. HL7’s
Reference Information Model version 1.0). Definiendo conceptos médicos en relación a
vocabulario médico estandarizado permite que en la guía se codifique, en el nivel B, conceptos
que no son dependientes de la institución. De esta manera, los términos concretos de cada
institución se especifican únicamente en nivel C, que definirá el mapeo entre los términos
expresados en nivel B con los términos propios de cada institución. Definir la estructura de los
datos del paciente de acuerdo con estándares de modelos de datos médicos se hace con la idea
de facilitar el proceso de mapeo del nivel B a codificaciones EMR institucionales y de esta
manera facilitar el uso compartido de las guías. El soporte de las necesidades ontológicas para
modelar la guía se separa en tres capas, correlacionadas a los 3 niveles de abstracción. La
primera capa, Core GLIF, es parte de la especificación de GLIF y define una interfaz estándar a
los datos y conceptos médicos, y la relación entre ellos.
La segunda capa, Reference Information Model (RIM), es esencial para la ejecución de la guía y
comunicación de datos entre diferentes aplicaciones y diferentes instituciones. Esto define el
modelo básico de datos para representar información médica que es necesitada en protocolos
específicos y guías clínicas. Esto incluye un alto nivel de clasificación de conceptos, tal como
medicaciones y observaciones sobre pacientes, y atributos, como unidades de medida y dosis de
medicamentos, que son datos y conceptos médicos que podrían tener. El RIM por defecto que
acepta GLIF3 es HL-7’s Reference Information Model version 1, también conocido como el
Unified Service Action Model (USAM).
La tercera capa, es la capa del conocimiento médico, que en esta versión de GLIF está aún bajo
desarrollo. Esta especificará los métodos que ha de tener una interfaz para poder seguir los
recursos que contienen el conocimiento médico:
1. Vocabulario estándar y controlado tal como (UMLS).
2. Las bases del conocimiento médico, tal como la jerarquía de medicamentos, y los
rangos normales en pruebas médicas.
3. Repositorios clínicos (EMRs)
4. Otras aplicaciones clínicas, como entrar en ellas y alertas o recordatorios de dichos
sistemas.
18
19
3. ANÁLISIS DE REQUERIMIENTOS
En este capítulo se estudian las necesidades principales de la solución propuesta como resultado
de este proyecto. Plantemos los casos de uso necesarios para el desarrollo de la aplicación y los
requerimientos tanto en el modelado de la especificación como de la aplicación.
En este capítulo hemos aprovechado ciertos aspectos del proyecto final de carrera de Nídia
Berbegal [2], donde desarrolla una interfaz de usuario de un sistema de personalización de guías
clínicas de prevención. Los aspectos a destacar de este proyecto son la detección de
requerimientos funcionales y casos de uso. Los datos extraídos de este trabajo son de relevante
importancia ya que elaboró el proceso de detección de necesidades por parte de los usuarios
potenciales de estas aplicaciones.
3.1 CASOS DE USO
3.1.1 Caso de uso crear nueva guía

Una de las opciones que el sistema tiene que ofrecer es la posibilidad de personalizar desde cero
una guía clínica. Este es el caso de uso representado, para personalizarla desde cero,
necesitaremos que se introduzcan los datos específicos del paciente, y una vez introducidos, el
usuario podrá (según el flujo de decisión de la guía), responder a las preguntas, adjuntar pruebas
o ir al siguiente paso.
3.1.2 Caso de usi Cargar historia clínica
Una vez hemos personalizado la guía clínica y la hemos grabado en memoria, hemos de poderla
recuperar. Todo paciente, vendrá representado por un identificador y por el que se podrá buscar
20
su archivo de guía clínica personalizada. Una vez recuperado el archivo, el sistema lo cargará y
devolverá el estado de decisión en el que se encontraba la última sesión de personalización de la
guía.
3.2 REQUERIMIENTOS
Los requerimientos de la especificación son los siguientes:
• La especificación ha de ser en XML. Actualmente el XML es un sistema de etiquetaje
estandarizado y utilizado por la mayoría de especificaciones y protocolos de
comunicación.
• La especificación ha de soportar, como mínimo, el modelado de la Guía de Práctica
Clínica de Prevención del Cáncer Colorrectal.
• Ha de favorecer la reutilización, es decir, durante la ejecución de una guía clínica,
siguiendo diferentes caminos podemos llegar a la misma acción, será mejor definir una
acción que no dos, y la especificación ha de permitirlo.
• Ha de ser intuitiva, por lo que las etiquetas han de reflejar lo que han de contener.
Los requerimientos de las librerías son:
• Han de favorecer su reutilización, por lo que el código ha de ser lo más independiente
posible.
• Las librerías han de reflejar la estructura de la especificación, de esta manera, si se
comprende la especificación, se puede entender, la estructura de las librerías.
• El lenguaje escogido para la implementación de las librerías es Java, debido a su
portabilidad y la cantidad de frameworks creados en este lenguaje y que podrían ser
utilizados para mejorar su efectividad.
Los requerimientos de la aplicación en general son:
• La aplicación será una aplicación web, decisión tomada por la gran propagación de este
tipo de aplicaciones y como no, por poder ser ejecutadas en multitud de plataformas.
• La interfaz de la aplicación ha de ser intuitiva y fácil de utilizar.
21
4. Planificación del proyecto

22
El proyecto se ha dividido en 3 etapas:

1. Análisis y diseño de la guía clínica
En esta fase se hace un estudio de la situación actual de los estándares o
especificaciones actuales en el mercado. Donde hemos de analizar las posibilidades de
utilizarlas en este proyecto y reutilizar el máximo trabajo ya realizado.
Una vez realizado el estudio, se estudiarán dos posibilidades, utilizar una especificación
o estándar ya existente o la elaboración de una nueva especificación adaptando una ya
existente a nuestras necesidades pero manteniendo la compatibilidad, por ejemplo en el
caso de que la especificación encontrada sea demasiado extensa podremos simplificarla.
Para ello tendremos que modelar la guía de práctica clínica de prevención del cáncer
colorrectal en la especificación elegida.
Finalmente, estudiaremos la posibilidad de los posibles casos de uso en los que se
podría utilizar el player resultante de este proyecto dentro de un entorno de elearning
como el TENCompetence Client.
2. Implementación de librerías de soporte para guías en XML.
Desarrollo del esquema que defina la especificación escogida y las librerías que sirvan
como engine de la especificación.
3. Diseño e implementación de la User Interface del Player.
Desarrollo de la interfaz que utilizando las librerías, podamos ejecutar una guía de
práctica clínica.
23
5. ESPECIFICACIÓN
El modelado de una guía clínica es necesario para la obtención de datos resultantes de la
interacción del usuario con la guía. Una guía contiene recomendaciones, argumentaciones para
las tomas de decisiones, de una manera ordenada. La idea de modelar una guía es pasar la
estructura de una guía en lenguaje natural a una estructura más formal.
Para la elaboración del modelado nos hemos basado en el modelo de GLIF3, principalmente por
su gran potencial en el campo de las ontologías, que gracias a ellas, se podrían hacer guías
totalmente estandarizadas y en diferentes idiomas con capacidad a ser adaptadas a diferentes
sistemas de información propios de ciertas instituciones. Por lo que pensamos que de esta
manera favorecemos la reutilización de este proyecto.
Existen dos versiones de la especificación:
• La primera especificación es resultado del estudio de la guía de práctica clínica del
cáncer colorrectal, donde se extrae el algoritmo fundamental y se modela en
GLIF3, intentando extraer los elementos más importantes de GLIF3, los cuales
serán representados en la especificación. El resultado es explicado en el
siguiente apartado.
• En el siguiente apartado (5.2), se explican las razones y los cambios que sufre la
primera especificación respondiendo a las necesidades encontradas en la reunión
concertada con el Hospital Clínico, organismo que supervisó el desarrollo de la
especificación.
Principalmente, el mayor problema que nos podemos encontrar en el modelado de las guías
clínicas, es la dificultad de relacionar el lenguaje natural, con un lenguaje formal y estructurado.
La libre interpretación de las palabras, y la ausencia de información, nos lleva a errores en el
modelado, debido a esto, el modelado de una guía siempre debiera estar supervisado por
personal especialista en la materia.
24
5.1 Primera versión de la especificación
• element Guideline: Es nuestro elemento raíz, y consta de tres elementos hijos, el

Algorithm, MaintenanceInfo y DataItem. Podríamos decir que es el elemento que
engloba al resto de elementos que constituyen la Guía Clínica.
Diagram
children Algorithm MaintenanceInfo DataItem

25
source <xs:element name="Guideline">

<xs:annotation>
<xs:documentation>Comment describing your root element</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element ref="Algorithm"/>
<xs:element ref="MaintenanceInfo"/>
<xs:element ref="DataItem" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
Ejemplo del xml que representa la guía de práctica clínica en particular:
<Guideline xmlns:xdb="http://xmlns.oracle.com/xdb" xmlns:xsi="http://www.w3.org/2001/XMLEsquema-instance"

xsi:noNamespaceEsquemaLocation="C:\clinico\prueba esquema2.xsd">
Contenido de la guía
</Guideline>
xmlns:xdb="http://xmlns.oracle.com/xdb" ~ Es un dato que expresa que las extensiones del

esquema de Oracle están activadas
xmlns:xsi="http://www.w3.org/2001/XMLEsquema-instance" ~ Expresa contra qué lo
tendrá que validar, en este caso un esquema.
xsi:noNamespaceEsquemaLocation="C:\clinico\clinical_guides.xsd" ~ Identifica la
localización del esquema, normalmente, no está ubicado en local si no con un URL remota.
• element Algorithm: Con este elemento definiremos el flujo de la guía, con la ayuda de
sus elementos hijos. En este caso, la relación es de uno a uno, es decir por cada
Algoritmo, solo tenemos un Step, pero esto es debido a que luego los mismos Steps,
serán los que contengan más Steps, de est6a manera iremos definiendo el flujo.
diagram
children ActionStep DecissionStep BranchStep

used by element Guideline
source <xs:element name="Algorithm">

<xs:complexType>
<xs:choice>
<xs:element ref="ActionStep"/>
<xs:element ref="DecissionStep"/>
<xs:element ref="BranchStep"/>
</xs:choice>
</xs:complexType>
</xs:element>
<Algorithm>
26
Steps…
</Algorithm>
En este caso, podemos ver que son dos tags (uno de apertura y otro de cierre) que engloban el
flujo.
• element ActionStep: Los ActionStep, implican una acción, una medida o una
recomendación que nos indica la guía clínica. Por ejemplo:
Este elemento consta del InfoGuidelineStep, que explicaremos a continuación,

StrengthOfRecomendation, que implica, la importancia de la recomendación, la idea de
utilizar dicho elemento es que se llegaran a dos recomendaciones, no compatibles y que
una pudiera predominar sobre la otra, según una escala anteriormente definida, el
DurationConstraint, no está tan enfocado a guías de prevención, ya que implica, por
ejemplo, la duración de un tratamiento, y finalmente, tenemos un posible Step destino.
diagram
children InfoGuidelineStep StrengthOfRecomendation DurationConstraint ActionSpecification

DecissionStep ActionStep BranchStep
used by elements ActionStep Algorithm BranchStep DecissionOption
source <xs:element name="ActionStep">

<xs:complexType>
<xs:sequence>
<xs:element name="InfoGuidelineStep" type="GuidelineStepType"/>
<xs:element name="StrengthOfRecomendation" type="xs:string" minOccurs="0"/>
<xs:element name="DurationConstraint" type="xs:string" minOccurs="0"/>
<xs:element ref="ActionSpecification" maxOccurs="unbounded"/>
<xs:choice minOccurs="0">
</xs:choice>
</xs:sequence>
</xs:complexType>
</xs:element>
27
• element InfoGuidelineStep: Este elemento es común en todos los Steps, en el

ActionStep, el name implica el tipo de acción, en el DecissionStep, indica la pregunta, y
en el BranchStep da únicamente información adicional. El id debería de ser único, el
DidacticMaterial, contiene la ubicación de los diferentes materiales de soporte que
pueden ayudar al usuario a escoger correctamente las respuestas, y finalmente el
comment, para que el médico o usuario en general pueda dejar anotaciones.
diagram
type GuidelineStepType
children name id DidacticMaterial comment
source <xs:element name="InfoGuidelineStep" type="GuidelineStepType"/>
• element ActionSpecification: Un ActionStep, puede contener varios

ActionSpecification, esto es debido a que se puede dar el caso de que sean necesarias
indicar la posibilidad de que existen varias acciones.
diagram
children name description intention

used by element ActionStep
source <xs:element name="ActionSpecification">

<xs:complexType>
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="description" type="xs:string"/>
<xs:element name="intention" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<ActionStep>
<InfoGuidelineStep>
<name>Debe realizar la/s siguiente/s accion/es (a partir de cumplir los 50 años):</name>
<id>7_1</id>
</InfoGuidelineStep>
<ActionSpecification>
<name>SOH</name>
28
<description>SOH anual o biennal</description>

</ActionSpecification>
<name>Sigmoidoscopia</name>
<description>Sigmoidoscopia cada 5 años</description>
<name>Colonoscopia</name>
<description>Colonoscopia cada 10 años</description>
</ActionStep>
• element BranchStep: Se da en el caso de que varios caminos se han de seguir,

independientemente de la decisión tomada, si es el caso. Por ejemplo:
Consta, básicamente, del elemento InfoGuidelineStep, ya definido y explicado

anteriormente, y el Step destino.
diagram
children InfoGuidelineStep ActionStep BranchStep DecissionStep

source <xs:element name="BranchStep">

<xs:complexType>
<xs:sequence>
<xs:choice maxOccurs="unbounded">
</xs:choice>
</xs:sequence>
</xs:complexType>
</xs:element>
<BranchStep>
<InfoGuidelineStep>
<name>Riesgo familiar y/o personal</name>
<id>4</id>
29
<DecissionStep>
Se define el DecissionStep
</DecissionStep>
<DecissionStep>
</DecissionStep>
</BranchStep>
• element DecissionStep: El DecissionStep, lo utilizamos para el típico caso de decisión.

Por ejemplo:
Consta del ya explicado InfoGuidelineStep, del AutomaticDecission, que es un bolean

con dos posibles valores, true o false. La idea es que en principio, las guías están vacías,
pero cuando ya han sido ejecutadas alguna vez, y han sido rellenadas con los datos de
un paciente, si el AutomaticDecission, está a true, al cargar la guía “rellenada”, con los
datos concretos, volveremos al último punto donde nos encontrábamos donde lo
dejamos con el paciente en particular. El DessionOption lo comentaremos a
continuación.
diagram
children InfoGuidelineStep AutomaticDecission DecissionOption

source <xs:element name="DecissionStep">

<xs:complexType>
<xs:sequence>
<xs:element name="AutomaticDecission" type="xs:boolean" default="false"/>
<xs:element ref="DecissionOption" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
30
• element DecissionOption: Este elemento representa una de las decisiones posibles,

Name, es un nombre representativo, DisplayName es el que se mostrará por pantalla,
Criterion se explicará a continuación y, finalmente, el siguiente paso.
diagram
children Name DisplayName Criterion ActionStep DecissionStep BranchStep

used by element DecissionStep
source <xs:element name="DecissionOption">

<xs:complexType>
<xs:sequence>
<xs:element name="Name" type="xs:string"/>
<xs:element name="DisplayName" type="xs:string"/>
<xs:element ref="Criterion"/>
<xs:choice>
</xs:choice>
</xs:sequence>
</xs:complexType>
</xs:element>
• element Criterion: Como su nombre indica, establece el criterio de decisión, es decir,

establece la relación entre el paciente y la condición. Name es un nombre identificativo,
GetDataItems, establece a que variable corresponde en el historial clínico del paciente,
y finalmente la Condition, que explicaremos a continuación.
diagram
children Name GetDataItems Condition

used by element DecissionOption
source <xs:element name="Criterion">

<xs:complexType>
<xs:sequence>
<xs:element name="GetDataItems">
<xs:complexType>
<xs:sequence>
31
<xs:element name="Item" type="xs:string" maxOccurs="unbounded"/>

</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="Condition"/>
</xs:sequence>
</xs:complexType>
</xs:element>
• element Criterion/GetDataItems: Establece las variables que hemos de conseguir del

historial clínico del paciente.
diagram
children Item
source <xs:element name="GetDataItems">
<xs:complexType>
<xs:sequence>
<xs:element name="Item" type="xs:string" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
• element Condition: Este elemento establece la condición, habitualmente, Name1,

contendrá la variable que antes hemos nombrado en GetDataItems y Name2 contendrá
el valor con el que hemos de comparar.
diagram
children Name1 Operator Name2

used by element Criterion
source <xs:element name="Condition">

<xs:complexType>
<xs:sequence>
<xs:element name="Name1" type="xs:string"/>
<xs:element name="Operator" type="xs:string"/>
<xs:element name="Name2" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<DecissionStep>
<InfoGuidelineStep>
<name>¿Usted cree que el paciente es sospechoso de tener CCR?</name>
<id>1</id>
<DidacticMaterial>guia.pdf</DidacticMaterial>
<AutomaticDecission>true</AutomaticDecission>
<DecissionOption>
32
<Name>Sospecha CCR cierto </Name>

<DisplayName>Sí</DisplayName>
<Criterion>
<Name>Sospecha CCR cierto</Name>
<GetDataItems>
<Item>sosp_CCR</Item>
</GetDataItems>
<Condition>
<Name1>sosp_CCR</Name1>
<Operator>==</Operator>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
Se define el actionStep
</ActionStep>
</DecissionOption>
<DecissionOption>
<Name>Sospecha CCR falso</Name>
<DisplayName>No</DisplayName>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>false</Name2>
</Condition>
</Criterion>
<DecissionStep>
</DecissionStep>
</DecissionOption>
</DecissionStep>
• element DataItem: Los DataItems definirán la historia clínica del paciente, el Name,
corresponde al nombre de la variable donde se guardarán los datos, el Value,
corresponde a su valor, y el Concept, y el ConceptSource, solo se usarán en caso de
utilizar, por ejemplo, UMLS.
diagram
children Name Value Concept ConceptSource

source <xs:element name="DataItem">

<xs:complexType>
<xs:sequence>
<xs:element name="Value" type="xs:string"/>
<xs:element name="Concept">
<xs:complexType>
<xs:sequence>
<xs:element name="ConceptName" type="xs:string"/>
<xs:element name="ConceptId" type="xs:string"/>
<xs:element name="ConceptSource" type="xs:string"/>
33
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
• element DataItem/Concept: Solo se usará en caso de utilizar, por ejemplo, UMLS.
diagram
children ConceptName ConceptId ConceptSource

source <xs:element name="Concept">
<xs:complexType>
<xs:sequence>
<xs:element name="ConceptName" type="xs:string"/>
<xs:element name="ConceptId" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
• element MaintenanceInfo: Son datos particulares de la guía, título, autores y la fecha

de creación.
diagram
children Title Author AuthoringDate

source <xs:element name="MaintenanceInfo">

<xs:complexType>
<xs:sequence>
<xs:element name="Title" type="xs:string"/>
<xs:element name="Author" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="AuthoringDate" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
5.2 Segunda versión en la especificación.

Después de realizar una reunión con el Hospital Clínic de Barcelona, donde se les presenta un
xml de prueba que modela en xml la guía de práctica clínica de prevención del cáncer
34
colorrectal y una serie de prototipos que representarían la funcionalidad del player y la

representación del esquema (se puede consultar Anexo 1 y 2). Esos prototipos son una serie de
capturas de pantalla que representarían el flujo que seguiría en dos casos tipos que nos
proporcionaron antes de la reunión. Por otra parte también se les presentó los xml resultantes de
una teórica ejecución. (Anexo 3)
5.2.1 Razones para la modificación.
La primera especificación, se diseña con la idea de que la ejecución fuera única, por lo que no se
guardaría la historia clínica del paciente, o mejor dicho, sólo se guardaría la historia clínica de la
anterior visita. Nos comentan que la historia clínica es relevante y necesaria para la elaboración
de un buen diagnóstico.
Otro de los problemas que nos indicaron fue la interpretación de los Branch Step, ya que induce
a confusión, y por su parte se comprometen a darnos una guía totalmente secuencial, es decir,
que la interpretación de la funcionalidad o como hemos de procesar los Branch Step, la
ignoraremos, se dejará indicado en la especificación pero no trabajaremos con ello.
Una funcionalidad que añadieron fue adjuntar pruebas clínicas en los Decission Step. En este
punto se decidió hacer un cambio importante para seguir más fielmente la especificación de
GLIF, el algoritmo de la guía siempre sería el mismo, no tendría variación, lo que irían variando
únicamente son los Data Items.
Por lo que uniendo los conceptos comentados anteriormente, se decide, no hacer Steps
anidados, ya que únicamente conseguiríamos, desfavorecer la reutilización de los Steps, y en
vez de contenerse unos a otros, se utilizan identificadores. Esta decisión no sólo favorece la
reutilización de los Steps, como consecuencia menos uso de memoria, sino que hace más fácil la
comprensión del archivo xml.
Estos son los principales errores que nos encontramos en la primera versión de la
especificación. En la siguiente sección se explicarán de una manera más concreta los cambios
en la segunda versión de la especificación.
5.2.2 Cambios en la segunda versión de la especificación.

En esta sección explicaremos los principales cambios individualmente.
5.2.2.1 Guideline y Algorithm
• diagrama versión 1
Guideline Algorithm
Guideline Algorithm
35
Como hemos indicado en la anterior sección, la principal diferencia es que el elemento

Algorithm era el que contiene un Step y el a su vez contiene más Steps, pero en la segunda
versión el elemento Algorithm, únicamente contiene el identificador del primer Step y es el
elemento Guideline quien contiene los Steps
5.2.2.2 InfoGuidelineStep y DataItem

InfoGuidelineStep DataItem
InfoGuidelineStep DataItem
InfoGuideLineStep simplemente se le extrae la posibilidad de llevar un comentario, ya que se

decidió que los comentarios irían con los DataItem, ya que los Steps son parte estática que
simplemente define el flujo de la guía.
36
En cambio podemos ver que los DataItems, se les ha añadido la fecha, para poder realizar las
historias clínicas, el comentario que antes lo podíamos encontrar en InfoGuidelineStep y File,
un campo dedicado a guardar la ruta de los archivos adjuntados.
37
6. DESARROLLO DE LA APLICACIÓN
Para el desarrollo de la aplicación se ha escogido seguir el Model-View-Controller como patrón
de arquitectura.
Hay funcionalidades específicas que no están implementadas, como la conexión con sistemas
propios de instituciones, actualmente, tanto el esquema como la aplicación, funcionan con los
dataItems propios del sistema que hemos diseñado.
En este capítulo podemos encontrar las explicaciones sobre la implementación de la

arquitectura. Se explica por partes, relacionándolo con la figura anterior mostrada. En el último
apartado, podemos encontrar una serie de clases que se salen del patrón, pero que se ha visto
necesario utilizarlas para la correcta implementación de la aplicación.
6.1 Modelo
Como nombramos en los requerimientos, se ha intentado ser fiel en la implementación al
modelo de la especificación, de esta manera, la persona que entienda la especificación podrá
entender fácilmente la implementación de las librerías. Por lo que a continuación se define el
diagrama de clases del modelo:
38
6.1.1 Clase Guideline

A parte de los setters y getters habituales podemos encontrar las siguientes funciones y las
principales funciones para gestionar los vectores que contiene los datos, podemos encontrar la
siguiente función:
• getXMLGuideline: Esta función devuelve el xml generado por la interacción del
usuario con la guía. El modo de funcionamiento es el siguiente, la clase delega a todas
las clases que contiene la construcción del xml como elementos constituyentes del
esquema, es decir, cada clase construye una parte del xml, la del elemento que es dentro
del esquema.
De esta manera el elemento Guideline es el encargado, al ser el principal, de construir la

cabecera del archivo xml, y poner su propia etiqueta <Guideline>…</Guideline>, delegando a
las otras clases la construcción del resto del esquema.
39
Así conseguimos cierta independencia en el modelo, cada clase tiene la responsabilidad de

generar los datos correctamente.
6.1.2 Clase Algorithm.
Es la que define el primer identificador del Step con el que se empieza el algoritmo de la guía.
Es una clase muy simple, únicamente contiene, un String que define el identificador, pero
también tiene su función para generar el xml.
Como podemos ver, es una función mucho más simple que la anterior, pero en el caso de que
cualquier persona se viera con la necesidad de modificarla, tendría que modificar únicamente
esta clase. Con la ventaja de sólo tener que recompilar esta clase.
6.1.3 Clase GuideLineStepType
Esta clase la contienen todos los Steps, se podría utilizar la herencia, y que todos los Steps
heredaran de ella, declarándola como abstracta. La decisión de no aplicar herencia, es la mayor
similitud al modelo utilizado en el esquema.
Contiene principalmente tres atributos, el identificador del step, que debe ser único, el nombre
del step, que por ejemplo en las decissionStep puede ser utilizado para plantear la pregunta y un
Vector que contiene los paths a los materiales didácticos.
Su función para recuperar el xml es el siguiente:
6.1.4 Clase ActionStep.

Contiene los datos relacionados con las acciones clínicas que se han de aplicar. Tiene dos
atributos cuya funcionalidad no ha sido implementada, son _durationConstraint y
_strengthofRecommendation, cuyo significado es expresar la duración de un tratamiento y
priorizar las recomendaciones o establecer la urgencia de estas. La razón de que la
funcionalidad no fuera implementada se basa en que trabajábamos con una guía que no requiere
el uso de estos atributos, por lo que, sería mejor en un futuro decidir como trabajar con su
funcionalidad.
A pesar de lo comentado, en la función de recuperación del xml se han incluido estos atributos,
ya que en el esquema se han definido.
40
Otro de los detalles a resaltar en esta clase es el atributo Vector que contiene un conjunto de
ActionSpecification, clase que explicaremos en la siguiente sección. Y siguiendo la línea del
patrón aplicado, la obtención del XML correspondiente al elemento ActionSpecification se
delega a la subclase.
6.1.5 Clase ActionSpecification
Tres atributos principales encontramos en esta clase, el nombre, que puede servir para describir
el contenido de la acción, la descripción, que será la que se muestre por pantalla cuando se
ejecute el player, y la que exprese con todos los detalles como y que tipo de acción se ha de
aplicar. Y finalmente la intención, para explicar y dar detalles del porqué hay que realizar la
acción.
La función para recuperar XML es la siguiente:
6.1.6 Clase DecissionStep

Esta clase contiene la clase GuideLineStepType, y un vector con DecissionOptions, que son los
que contienen las respuestas y posibles destinos que hay en un Step. Podemos encontrar un
atributo que es automaticDecission, que es para que el sistema interprete si ha de buscar una
respuesta automáticamente, por ejemplo buscando una respuesta en una BD remota, o se ha de
introducir manualmente.
Esta clase como contiene otras clases, sigue el patrón de delegarle la tarea de generar el xml:
6.1.7 Clase DecissionOption

En esta clase encontramos los atributos de nombre, que debiera ser un nombre representativo de
la DecissionOption, el nombre que se muestra, es decir la opción a escoger y que se mostrará
por pantalla, el siguiente paso en caso de ser escogida la opción y el criterio, clase que se
explicará a continuación.
La forma de generar el XML, sigue el patrón utilizado hasta el momento, delegando a la clase
Criterion, la tarea de generar su xml:
41
6.1.8 Clase Criterion

Los atributos con los que contamos en esta clase son el nombre, que es un texto representativo
del criterio escogido, GetDataItems, los DataItems que entran para que se cumpla o no la
condición y la condición, que es donde se configura las condiciones para que se cumpla el
criterio. Estas dos últimas clases se explicarán a continuación.
La función para generar el XML es la siguiente:
6.1.9 Clase GetDataItems

Esta clase es muy simple, se podía haber omitido, en el caso de que hubiéramos creado un
Vector en la clase Criterion que contuviera únicamente un Vector con los tipos de DataItems
que se requerían en la condición. Debido a ello sólo contiene un atributo item que es un vector
que contiene los ítems que se necesitan para evaluar la condición.
Esta se decisión, se tomó, para parecerse lo máximo posible a la especificación, y en la
especificación se tomó la decisión por similitud a GLIF.
La función de generar XML es la siguiente:
6.1.10 Clase Condition

La utilidad de esta función es la de definir condiciones, GLIF contempla el uso de diversas
operaciones, en nuestro caso contemplamos, únicamente, el igual como operación para definir
condiciones. Este criterio se tomó para poder simplificar las cosas, aunque conociendo
diferentes formatos de especificación de datos de paciente, y contemplando ontologías que
regulen el uso de UMLS, podría ser muy interesante la definición de más operaciones.
A pesar de lo comentado anteriormente, el modelo contempla el uso de cualquier operación, es
el controlador quien únicamente contempla el igual. Por esta razón los atributos que forman
parte de esta clase, son la primera parte de la condición (name1), la segunda (name2) y el
operador.
La función que genera el XML es:
42
6.1.11 Clase DataItem

La clase DataItem si nos remontamos a GLIF, sirve para definir, que tipo de DataItem es
requerido y de done, debido a esto hemos incluido, los atributos conceptSource, que sería donde
se ubica la fuente, y la clase Concept que se explicará en la siguiente sección. De todas formas
esta estructura está pensada en el uso de estándares de modelado de datos de paciente, y al no
utilizarlo en este proyecto, se pensó el poder incluir los datos relacionados con el paciente.
Como el valor del dataItem, la fecha de cuando se ha generado, el comentario relacionado, y los
documentos adjuntos a esos datos. El nombre es común en las dos especificaciones, tanto en
GLIF como en la actual.
La función de XML utilizada en esta clase es:
6.1.12 Clase Concept.

Es una clase muy simple y especifica en sus atributos el identificador del concepto, es decir, el
identificador del dato requerido, por otra parte el nombre, y finalmente el tipo de especificación
o estándar que sigue (conceptSource).
Al no ser usada, no hemos desarrollado la función de generar XML.
6.1.13 Clase BranchStep
Al final, esta clase no es utilizada en la funcionalidad de la aplicación, ya que en la reunión que
se mantuvo con el Hospital Clínic, no se llego a un punto real de encuentro de como interpretar
este tipo de clase. Las soluciones proporcionadas, según su punto de vista, llevaban a la
confusión, por lo que decidimos su interpretación, ya que era posible modelar la guía sin esta
clase.
En esta clase, al igual que en ActionStep y DecissionStep, podemos encontrar el tipo
GuidelineStepType ya explicado anteriormente, y el otro atributo que también podemos
encontrar es un vector que contiene los identificadores de todo los siguientes Steps a los que se
puede ir siguiendo la guía.
La generación del XML se hace de la siguiente manera:
43
6.2 Controller
El controller es el encargado de gestionar las peticiones que recibe a través del viewer y
gestionarlas con el modelo, en cierta manera, es el motor de la aplicación y el que hace que el
modelo no se cargue con ciertas tareas de lógica que son necesarias para comunicarse con el
viewer.
6.2.1 Controller.java
Es un servlet que se utiliza cuando queremos crear una nueva historia clínica de un paciente. El
parámetro más importante que utiliza se llama myfile que está codificado dentro del request, y
contiene la ruta de la plantilla de la guía clínica, es decir una guía modelada en xml pero vacía,
sin contenido específicos de pacientes. Entonces es el encargado de llamar a los métodos de las
clases pertinentes para que el xml sea leído y se cree una clase Guideline.
Es el primero que empieza a personalizar la guía, ya que recibe otros cuatro parámetros:
1. name: El nombre del paciente.
2. surname1: El primer apellido del paciente.
3. surname2: El segundo apellido del paciente.
4. id: Identificador del paciente, por ejemplo, en la estructura de la sanidad pública
española, sería el número de la seguridad social, que ha de ser único. En caso de
instituciones privadas, podría ser el DNI.
También es el encargado de cargar una relación de nombres de DataItems a un lenguaje más
inteligible para cualquier persona. La intención con esto es poder leer la historia clínica de un
paciente de una manera más fácil. Por ejemplo, el nombre de una dataItem es
polipos_personales_familiares y una “traducción” más inteligible para la historia clínica podría
ser “La persona tiene antecedentes personales de pólipos >15”. Este proceso podría ser
elaborado mediante ontologías, aunque es una de las mejores que se dejarán para el futuro.
Esta relación de DataItems con frases, se hace a través de una BD en mysql, y una vez cargados
los datos, se introducen como atributos de sesión de la siguiente manera:
La siguiente tarea que hace es encontrar del primer Step de la guía:
Y luego hace una búsqueda entre todos los AccionStep y DecissionStep que tiene definidos en
la guía, una vez encontrado cuál es el primero, se envían los datos al viewer para poder ser
visualizado correctamente, introduciendo como atributos de sesión el flujo que se está
siguiendo, un vector llamado workflow, la guía, y como parámetros de petición el step
encontrado.
6.2.2 Search.java
Cuando una guía es personalizada, puede ser buscada por su identificador, función que recae en
este servlet. Recibe en la petición el parámetro id, que contiene el identificador de la guía clínica
personalizada y que se desea encontrar.
Una vez encontrada, le pasa mediante atributos de petición los datos que se han de mostrar por
pantalla.
44
6.2.3 Charge.java
Su funcionalidad puede ser utilizada, una vez se ha utilizado el servlet Search.java, una vez que
hemos encontrado el usuario deseado.
Este servlet tiene la función de procesar una guía clínica, y encontrar el Step donde se encuentra
el paciente teniendo en cuenta su historia clínica.
Uno de los problemas que nos encontramos es que los datos clínicos de un paciente, es decir, los
DataItems, no tienen un orden cronológico y, por otra parte, la especificación no estaba pensada
para ello. Por lo tanto, es muy importante que cuando se evalúen los DataItems, siempre se
evalúen en un tiempo posterior a los anteriores que podríamos encontrar en la historia clínica.
Para ello hemos creado dos funciones auxiliares para ayudarnos en el proceso.
Esta función tiene como input el nombre del DataItem buscado (variable) y el vector que
contiene los DataItem (dataItem), lo busca y si lo encuentra, compara que la fecha sea posterior
al anterior DataItem evaluado. Para poder trabajo con la clase Date de java y hacer las
conversiones desde Strings, hemos desarrollado la segunda función.
Recibe una fecha como String y el formato "yyyy-MM-dd HH:mm:ss" donde yyyy indica el año
con 4 dígitos, MM representa el mes con 2 dígitos, dd expresa el día con los mismos dígitos que
el mes, HH, mm, ss, representan horas, minutos y segundos respectivamente y todos con 2
dígitos. Parsea la fecha en el String y lo transforma a la clase Date.
A parte de estas dos funciones comentadas anteriormente, lo que nos encontramos en la función
principal donde se procesa la petición es lo siguiente:
Primero inicializamos el atributo de clase _date a una fecha que sepamos que sea anterior a
todas las anteriores.
Recogemos el atributo que está codificado en la petición con nombre myfile y que identifica el
archivo donde encontramos modelada la guía clínica personalizada en xml y a partir de aquí
funciona de una manera similar al Controller. La principal diferencia es que en lugar de buscar
únicamente el primer Step del algoritmo de la guía, va evaluando todos lo Steps siguiendo el
algoritmo, si encuentra DataItems, con los cual puede evaluar los DecissionSteps, prosigue
buscando nuevos Steps, hasta que ya no quedan más DataItems para evaluar.
45
6.2.4 Action.java
Esta clase tiene la función de procesar los datos de los ActionStep que le envía el viewer. El
viewer le manda un parámetro en el request llamado nextStep, que es el indicador del siguiente
paso del algoritmo de la guía al que tiene que ir el usuario de la guía.
El servlet obtiene el parámetro y busca el Step destino entre su colección de ActionStep y
DecissionStep, y se lo envía al viewer, siguiendo la metodología que se ha utilizado en el
Controller.java o en Charge.java al encontrar el Step indicado.
Pero en este caso también se contempla otra posibilidad de interacción, que es ir un Step atrás,
por ejemplo, si el usuario se encuentra con la necesidad de modificar algún dato introducido
anteriormente.
Para realizar la acción de Atrás, se ha de trabajar con el vector workflow que contienen todas las
clases del controller y es donde se guarda el flujo que ha seguido el usuario interactuando con la
guía.
La clase AuxStep, que ya explicaremos más adelante, nos permite recuperar el anterior Step,
discerniendo entre si, si éste es ActionStep y DecissionStep. Después de obtener el Step
correcto, se lo enviamos al viewer.
La última interacción que contempla este servlet es la funcionalidad de grabar la guía clínica
con los nuevos DataItems generados.
6.2.5 Decission.java
Este servlet procesa los DecissionStep, pero con la peculiaridad del codificado del Request, que
recibe una codificación multipart/form-data, por lo que la manera de procesar el request es
diferente. Esto es debido a que una de las funcionalidades es adjuntar pruebas médicas.
A parte, al procesar DecissionStep, recibe un parámetro que es la respuesta obtenida por el

viewer, es el parámetro radiobutton. Una vez obtenida la respuesta proporcionada por el
usuario, el Controller, busca en el DecissionStep, la decissionOption que cumpla la opción
escogida por el usuario y una vez que la encuentra, le pide el siguiente Step. Una vez obtenido
el Step destino se busca en la colección de ActionStep y DecissionStep.
Este servlet, también tiene implementado la opción de Atrás y Guardar, de similar manera que
la clase Action.java.
46
6.3 Viewer
El viewer es el encargado de mostrar la interfaz html para que el usuario pueda interactuar con
el sistema. Para ello se trabaja con 3 jsps que se explicarán a continuación.
Para hacer el diseño de la interfaz, no se ha hecho un estudio a considerar, se ha intentado que
sea simple e intuitivo. En la reunión con el clínico se mostraron de acuerdo con el prototipo, por
lo que se ha intentado seguir ese camino.
6.3.1 Página index.jsp
Se basa en un simple formulario, para crear la nueva historia clínica de un paciente, donde hay
que introducir, el nombre, apellidos e identificador. Luego se puede hacer búsqueda de historial
a partir del identificador y cargar la historia clínica.
6.3.2 Página Decission.jsp

La página para tratar las Decisiones es la siguiente:
47
Es un formulario con el tipo de codificación multipart/form-data, ya que se incluye la

posibilidad de subir archivos. También se incluye la opción de insertar comentarios, ya que una
de las opciones que valoran mucho los médicos es poder seguir otro camino en la guía, pero hay
que dejar constancia de ello, ese campo de texto se puede utilizar con este fin, incluir la
justificación de la decisión tomada. Por otra parte, incluye las opciones de ir al siguiente Step, o
ir atrás, y grabar en el caso de que hayamos de parar la ejecución de la guía con un paciente
determinado.
La historia Clínica se muestra en todas las páginas en orden cronológico inverso, de esta
manera, el usuario puede consultar todas las decisiones que se han ido tomando.
6.3.3 Página Action.jsp
La página Action.jsp la podemos ver a continuación.
Simplemente nos muestra las recomendaciones que nos ofrece la guía, tiene la funcionalidad de
grabar, poder ir al anterior Step e ir al siguiente Step. En este caso no vemos el botón siguiente
porque simboliza que hemos llegado al final de un camino de la guía.
6.4 Recursos auxiliares

Es un conjunto de paquetes para acceder a la BD en mysql, para leer el XML y una serie de
clases que se usan para facilitar las operaciones pero que no forman parte, estrictamente, de
ninguna de las partes comentadas anteriormente.
6.4.1 Paquete DAO
El sistema utiliza una BD muy simple con dos tablas. La primera se llama patient y guarda los
datos del paciente nombre, primer apellido, segundo apellido, identificador y el path completo
del archivo donde se guarda la historia clínica del paciente. Es la BD que da soporte a la función
buscar que podemos encontrar en el index.jsp. La segunda BD tiene el nombre de
relation_dataitem y contiene la relación del nombre de las variables de los DataItems (columna
nameDataItem) con un posible significado (columna mean), esta relación y su uso está
explicada en la sección 6.2.1.
Para utilizar esta BD, tenemos 4 clases cuyo diagrama de clases es el siguiente.
48
6.4.1.1 Clase DAO

DAO es la superclase de la cual heredan las demás. La clase DAO contiene dos atributos de
clase, uno de tipo Connection y otro de tipo Statement.
Los métodos que están implementados en esta clase son el openConnection, que su función es
abrir una conexión con la BD guideline y el closeConnection, para cerrar la conexión.
6.4.1.2 Clase DAOInsertUser
Se utiliza cuando se personaliza una guía y se decide grabarlo en la BD. Contiene un método
que se llama insertUser, y el proceso que sigue es el siguiente
• openConnection (método de la superclase)
• Inserta usuario en la tabla patient
• closeConnection (método de la superclase)
6.4.1.3 Clase DAOSearchUser
Esta clase contiene la funcionalidad de hacer búsquedas de pacientes a través del identificador,
gracias al método llamado searchPatient, que funciona como a continuación se explica:
• A partir del identificador busca el paciente en la tabla patient
• Una vez cerrada la conexión devuelve el paciente a través de la clase Person que
explicaremos más adelante.
6.4.1.4 Clase DAOgetRelationDataItems
La funcionalidad de este clase, es la de recoger las traducciones entre nombre de DataItems y un
significado que se pueda traducir para que sea inteligible la historia clínica. Su forma de
funcionar es la siguiente:
• recoge todos los datos de la tabla relation_dataitem
• Una vez cerrada la conexión devuelve un vector que contiene todas las relaciones de la
tabla.
49
6.4.2 Paquete parseador

Este paquete contiene únicamente una clase, funciona como el patrón DAO, la idea es abstraer
como almacenamos los datos.
6.4.2.1 Clase GuidelineParser
En este caso guardamos los datos de las guías clínicas personalizadas en ficheros xml, pero
también se podría guardar los datos en una BD.
Esta clase funciona con la librería de SAXParser, es un parseador que únicamente controla las
etiquetas del fichero xml que se va encontrando, activa una serie de boléanos, que a posteriori
según los que están activados y los que no, sabe donde ha de insertar el contenido de las
etiquetas en nuestro atributo de clase Guideline. Si todo evoluciona de manera correcta, la
función parser, que es la que se llama desde el exterior, nos debería devolver un tipo Guideline.
6.4.3 Paquete AuxClasses
Este paquete contiene clases auxiliares que son utilizadas para ayudarnos a trabajar dentro del
sistema, pero que no forman parte del modelo, porque la intención es que el modelo formara un
conjunto de librerías que se adaptaran al esquema.
6.4.3.1. Clase AuxStep
Es una clase auxiliar que contiene 4 atributos, un string llamado step, la intención es que guarde
el tipo de Step al que nos estamos refiriendo, es decir ActionStep o DecissionStep, y luego
guarda 3 enteros llamados actionIdStep, decissionIdStep y dataItemId, que contiene
identificadores al ActionStep, DecissionStep y DataItem a los cuales nos referimos. La
particularidad de esta clase es que nunca sus atributos tienen todo un valor.
Esta clase se utiliza para la funcionalidad de ir a un Step inmediatamente anterior, por lo que en
función de si el Step inmediatamente anterior es un ActionStep o DecissionStep se le da valor a
unos atributos o a otros. Es decir, podemos encontrarnos en el caso de que sea un ActionStep,
en ese caso tenemos para ponerle valores a esta clase utilizaríamos la función:
Donde coge valor el atributo step y el actionIdStep, en cambio, si fuera un DecissionStep, se

utilizaría la siguiente función:
Pero como a parte el DecissionStep, estaría relacionado con un DataITem, también tenemos que
utilizar la siguiente función, que en el caso del ActionStep no se utiliza:
6.4.3.2. Clase Person

La clase Person se utiliza en la función de búsqueda de historial de un paciente, por lo que nos
encontramos que es una representación de la tabla patient, explicada en el 6.4.1. Por lo que
podemos encontrarnos la siguiente serie de atributos, nombre, primer apellido, segundo
apellido, identificador y el path completo del archivo XML, donde se guarda la guía clínica
personalizada.
50
6.4.3.3. Clase RelationDataItem

En esta clase nos encontramos un caso similar anterior, se utiliza para extraer los datos de la
tabla relation_dataitem, explicada en el 6.4.1. Y guarda la relación entre nombre de un
DataItem con un significado inteligible para el usuario, por lo que hay dos atributos de clase, el
nombre del dataItem y el significado.
6.4.4 Paquete Test
En este paquete, encontramos una serie de clases que se han ido generando para ir comprobando
las funcionalidades más críticas como el parseo de los archivos xml y la conexión con la BD.
51
7. Integración del sistema en un contexto de e-Learning.

La idea principal de este capítulo es presentar el posible uso de ejecuciones de guías clínicas
para el aprendizaje en estudiantes y profesionales en el ámbito de la medicina.
Por otra parte, las guías de prevención de práctica clínica pueden proveer información
interesante para los pacientes, ya que tienen que jugar un rol activo para que el resultado de
estas tenga éxito.
Contextualizando la situación, podemos ver que el e-Learning es el camino más idóneo para
poder desarrollar ciertas aptitudes de la manera más eficiente posible.
Para ello primero haremos un pequeño resumen de lo que es el e-Learning y alguna de las
opciones de aprendizaje que nos ofrece y luego presentaremos 4 escenarios, donde adquiere
significado esta propuesta, extraídos de la publicación presentada en el workshop
"TENCompetence Open workshop on Service Oriented Approaches and Lifelong Competence
Development Infrastructures" en Manchester el 11 y 12 de enero de 2007.
7.1 E-learning
La definición que da Wikipedia es la siguiente:
“Aprendizaje asistido por tecnologías de la información. El e-Learning fomenta el uso intensivo
de las TIC facilitando la creación, adopción y distribución de contenidos, así como la
adaptación del ritmo de aprendizaje y la disponibilidad de las herramientas de aprendizaje
independientemente de límites horarios o geográficos. Permitiendo al alumno intercambiar
opiniones y aportes a través de las TIC.”
Es una definición que se ajusta bastante a su significado, ya que en sí, es una definición bastante
abierta para poder abarcar el amplio espectro que ocupa el e-Learning en el mundo de
aprendizaje. La elección de esta definición es debido al uso de la palabra fomenta, porque el e-
Learning no establece sino fomenta nuevas formas de aprendizaje, flexibiliza los modelos
pedagógicos tradicionales y proporciona nuevas herramientas que generan nuevas formas de
adquirir conocimiento.
El e-Learning nos proporciona la personalización del aprendizaje, y nos hace soñar en un
aprendizaje a medida para cada persona.
La incorporación a Internet de la WEB 2.0 ha abierto nuevas perspectivas en el e-Learning, y ha
favorecido la creación de las comunidades de aprendizaje, comunidades donde los usuarios
pueden intercambiar recursos y solicitar soporte de diversas cuestiones. Una de las tecnologías
que su uso se está extendiendo exponencialmente es el blog, el sustituto de las páginas
personales, que es una manera de compartir intereses en común, y como consecuencia
conocimiento.
De todas formas no hemos de pensar que el e-Learning es un sustituto de los métodos de
aprendizaje tradicionales. El uso de la tecnología ha estado acompañando a la enseñanza
tradicional desde siempre, por lo que no deja de ser un avance más para flexibilizar los métodos
tradicionales. De hecho en el e-learning, se siguen aplicando conceptos como formal learning,
que no deja de ser un concepto que siempre ha asistido ya que su definición se basa en un
aprendizaje planeado y estructurado con actividades. Lo que sería un curso normal y, que
actuales universidades y academias imparten, por ejemplo la Universitat Oberta de Catalunya.
Pero a pesar de ser una estructura determinada y tener fechas en las entregas, se puede
evolucionar, ayudado con el material didáctico y soporte de los profesores o de otros
compañeros a través de foros, a un ritmo independiente del resto de compañeros.
En cierta manera el gran objetivo es aumentar la eficacia del informal learning, método que se
basa en ser autodidacta, una aprendizaje falto de estructura y no formal.
52
7.2 Escenario 1
Un estudiante de la carrera de medicina se ha matriculado en la asignatura llamada
Gastroenterologia. En un módulo de esta asignatura la docencia se imparte mediante e-Learning
y se basa en la comprensión de las guías clínicas. El estudiante procede a estudiar cada guía
clínica en su contexto científico, y tiene que aprender el flujo de cada guía, de tal manera, que
pondrá los conceptos aprendidos a través de resolver casos específicos. Por otra parte el
estudiante tiene que comunicarse con otros estudiantes para compartir consejos y solicitar ayuda
basándose en los cambios generados por la ejecución de la guía.
Este escenario provee un ejemplo de uso de guías clínicas en un contexto de formal learning,
donde la comunicación entre el alumnado para completar los objetivos del curso, adquiere un
valor de importancia considerable.
7.3 Escenario 2
Una persona está sufriendo síntomas que pueden significar que se le está desarrollando un
cáncer colorrectal. Al no tener una formación médica, la comprensión del procedimiento de
diagnosis resulta compleja de comprender. Sin embargo, la comprensión del procedimiento
puede tranquilizarle. El paciente se lo comenta al médico y le recomienda el uso de una guía
clínica interactiva como parte del programa de aprendizaje dedicado a los pacientes que están
inmersos en la diagnosis del cáncer colorrectal. El sistema sincroniza la copia digital del
paciente que esta guardada y simplifica las cuestiones médicas con la intención de hacer el
proceso comprensible para personas sin formación en medicina.
Este escenario nos proporciona un ejemplo de personalización y visualización de la
información. Este es el elemento clave para permitir a los pacientes entender las guías clínicas.
7.4 Escenario 3
Un medico de cabecera está intentando diagnosticar a un paciente con una serie de síntomas
desconocidos si se tiene que prevenir o no el desarrollo del cáncer colorrectal. Él trabaja en una
ciudad aislada de un área remota, y tiene problemas en mantener contacto con expertos en
gastroenterología con el objetivo de compartir conocimientos y experiencias. Él decide utilizar
un sistema online de eLearning y donde se puede compartir conocimientos y pueda mantener
relaciones con otros médicos y pueda pedir ayuda cuando él la necesite. Este sistema utiliza
guías clínicas y se puede conectar a un repositorio donde se guarden ejecuciones reales de
pacientes (pero donde la identidad del paciente no sea revelada). Compañeros de profesión
pueden responder preguntas planteadas por otros de una manera eficiente y rápida sin tener que
gasta mucho tiempo en estudiar el caso.
Este escenario provee un ejemplo del uso de guías como base de una comunidad de aprendizaje.
7.5 Escenario 4
Un doctor es especialista en cardiología y gastroenterología, pero durante muchos años de su
vida, se ha concentrado en la especialidad de cardiología. Pero recientemente, un puesto de
especialidad en gastroenterología ha sido abierto a concurso público, y él decide optar al puesto.
Por otra parte, él es consciente que se encuentra con la necesidad de refrescar sus conocimientos
en el área de gastroenterología. Opta por la opción de usar un sistema de guías clínicas para
simular la diagnosis y medidas de prevención asociadas con casos reales para mejorar sus
aptitudes en esta área. A través de esta práctica, él consigue recuperar y actualizar sus
conocimientos en el área de gastroenterología en cuestión de unas semanas sin la necesidad de
recibir clases o cursos.
Este escenario provee un ejemplo de un proceso de refrescar conocimientos en un contexto de
informal learning.
53
7.6 TENCompetence y arquitectura propuesta

TENCompetence (The European Network for Lifelong Competence Development) es un
proyecto subencionado por la Comisión Europea a través del IST Programme.
Uno de sus objetivos es desarrollar una infraestructura que soporte la creación y administración
de redes individuales, grupos y organizaciones que estén activamente inmiscuidos en temas de
ocupación la boral o en el dominio de los conocimientos. Estas redes de aprendizaje soportarán
el desarrollo de competencias a lo largo de la carrera educativa y profesional desde los básicos
niveles de habilidad hasta lo más altos niveles de calidad. La red estará formada por alumnos,
instituciones educativas, librerías, investigadores, comerciales, empleados, asociaciones y
demás personas que darán servicio o producto en algún determinado campo.
Las redes de aprendizaje incluyen:
• Frameworks para los diferentes campos de conocimiento
• Formales e informales facilidades de aprendizaje, incluyendo la posibilidad de
compartir conocimiento, actividades de aprendizaje, unidades didácticas y programas
didácticos.
• Todos los niveles de aprendizaje: primario, secundario y terciario, adultos y programas
de aprendizaje corporativos y otras formas de aprendizaje informal
• Mecanismos de intercambio social simulando el intercambio, el compartir y el soporte
entre personas, grupos y organizaciones en la red.
El proyecto:
• Desarrollará nuevas e innovadoras aproximaciones pedagógicas, modelos de evaluación
y modelos organizativos para el desarrollo de competencias a largo término.
• Desarrollará software para el efectivo soporte a los usuarios que creen, actualicen, usen
e intercambien recursos de conocimiento, actividades y unidades didácticas, y
programas de desarrollo de competencias en la red de aprendizaje.
• El proyecto integrará modelos aislados y herramientas para el desarrollo de
competencias.
• Pondrá en marcha pilotos, como mínimo, en el campo del Cine Digital, en el cuidado de
la salud, en la administración del agua y en el aprendizaje del recorrido histórico de las
ciudades, para validar la viabilidad de la aproximación.
• Desarrollará programas de aprendizaje para entender el funcionamiento de la
infraestructura, y enseñar a profesores y empresas a proveer servicios usando la
infraestructura.
• Construirá una creciente red de asociaciones para asegurar el uso en Europa de lo
desarrollado.
Y dentro de TENCompetence hemos desarrollado este proyecto, y hemos hecho una propuesta
para la integración dentro del software desarrollado en TENCompetence.
54
Fig. 8: Arquitectura propuesta para la integración

con el TENCompetence client
7.7 Viabilidad de los escenarios con la arquitectura propuesta.

La principal necesidad para hacer viables todos los escenarios es la elaboración del middelware.
El middelware dentro de la arquitectura tendrá la función de conectar las dos aplicaciones que
actualmente por sí solas, tienen un buen funcionamiento.
Los escenarios propuestos, son de una gran ambición, por lo que si no se pudieran llevar a cabo,
es por la dificultad de conseguir que todo funcione correctamente. Es decir, toda la arquitectura
funciona bajo un concepto, Learning Networks, las redes en Internet se expanden a una
velocidad vertiginosa bajo el concepto de Web 2.0 o Web Social, lo que hay que comprovar
realmente es si haber apostado por una aplicación Java, en lugar de una aplicación web como
entorno de aprendizaje, permite el desarrollo de redes de aprendizaje y permite una motivante
arquitectura de participación. Actualmente, las carencias de usabilidad de la aplicación
TENCompetence Client, a más, el servidor siendo una aplicación centralizada en lugar de
distribuida que causará un menor soporte de usuarios, hace apuntar que los escenarios, a pesar
de que la arquitectura los soporta (a falta del middelware), falta el entorno motivante para
llevarlos a cabo.
Realmente, merece la pena el éxito de esta aplicación, los objetivos son ambiciosos y
extensibles a múltiples áreas, pero no hay que olvidar que el éxito de las redes sociales en
Internet son los usuarios y se ha de responder a sus necesidades.
55
8. Conclusiones y trabajo futuro

Hasta el momento, podríamos decir que la investigación en el campo de trasladar las guías
clínicas al campo de las nuevas tecnologías de la información y la información ha sido
considerable. El mayor problema que se presenta es la ausencia de herramientas intuitivas que
faciliten la implantación de todos los avances. Este problema se traduce en un obstáculo en la
diseminación de estas tecnologías.
Por lo que podemos considerar que el proyecto en sí, a pesar de sus carencias, es un avance en
este campo, ya que favorece la estandarización y la interoperabilidad con otros sistemas, al
trabajar con especificaciones genéricas y no propias de cada algoritmo de guía clínica.
A parte, la contextualización de las guías clínicas en un contexto de e-learning es un objetivo
ambicioso pero necesario en un campo como el de la medicina que avanza rápidamente y hay
que estar al orden del día de los avances médicos. La parte positiva es que tenemos las
herramientas necesarias para cumplir con este objetivo, la colaboración y el conocimiento
común debe ser uno de los pilares de la Sociedad de la Información.
El uso de todo el potencial de las Nuevas Tecnologías de la Información y la Comunicación es
una necesidad social, y la estandarización en la representación de los protocolos en el campo de
la medicina, nos conduce a una forma de actuar común. El campo de la medicina no es un área
que se deba escapar de la globalización que nos proporciona Internet y, la facilidad de compartir
y propagar el conocimiento ha de ser utilizada para aumentar la eficiencia en la aplicación de los
avances que se puedan producir.
Para todo ello, se ha de fomentar la participación como base para conseguir los objetivos
fijados, pero para lograrlo hay que construir la infraestructura social que soporte la interacción
de todo y cada uno de los miembros de la sociedad que puedan colaborar en la creación de
redes, donde el conocimiento sea un recurso común. Conocimiento en forma de recursos
educativos, publicaciones, hasta la posibilidad de compartir experiencias profesionales de todo
tipo, en sí, crear una infraestructura de aprendizaje que funcione por sí misma, es decir, que la
infraestructura soporte lo que el alumno necesite, y como consecuencia la infraestructura no
será lo que se defina sino lo que el usuario quiera que sea.
Otro de los datos relevantes que hay que destacar de este proyecto es la posibilidad de generar
una base de datos de conocimiento. La posibilidad de estudio utilizando casos reales es una
necesidad en el campo de la medicina, y actualmente aunque se puede hacer, no se hace de una
manera tan estructurada.
El potencial de una herramienta de este tipo, es inmensurable, el estudio de casos reales mejora
la eficacia del aprendizaje [3][4], pero también, tiene un gran potencial en otros ámbitos, como
puede ser la detección de epidemias o la detección de casos particulares de enfermedades
extrañas en localidades geográficamente remotas entre ellas, y las Tecnologías de la
Información nos han de facilitar estas tareas.
Por todas estas razones, los próximos pasos en este campo debieran ser:
• El uso de ontologías para facilitar los objetivos de estandarización, tanto a nivel de
contenidos médicos como especificaciones, que nos hemos planteado, como ya describe
la especificación GLIF3.
• La integración real en el contexto del e-Learning de la herramienta resultante de este
proyecto, para poder resolver los escenarios planteados en el capítulo 7, una necesidad
para darle una elevada utilidad al trabajo realizado.
• La elaboración de un editor que no haga tan indispensable la participación de una
persona con elevados conocimientos técnicos en el modelado en XML de la guía.
56
57
REFERENCIAS
[1] http://www.guideline.gov
[2] Berbegal, Nídia. Desenvolupament de la interfície d'usuari d'un sistema de personalització
de guies clíniques de prevenció. Barcelona: Edicions UPF, 2004
[3] Downs, Murna; Turner, Stephen; Bryans, Michelle; Wilcock, Jane; Keady, John; Levin,
Enid; O'Carroll, Ronan; Howie, Kate; Iliffe, Steve: Effectiveness of educational interventions in
improving detection and management of dementia in primary care: cluster randomised
controlled study. BMJ 2006 332: 692-696.
[4] Feder, Gene; Griffiths, Chris; Highton, Clare; Eldridge, Sandra; Spence, Matthew;
Southgate Lesley: Do clinical guidelines introduced with practice based education improve care
of asthmatic and diabetic patients? A randomised controlled trial in general practices in east
London. BMJ 1995 311: 1473-1478.
BIBLIOGRAFÍA
http://www.qualityresearchinternational.com/glossary/formallearning.htm
http://en.wikipedia.org/wiki/Informal_learning
http://es.wikipedia.org/wiki/E-learning
http://www.qualityresearchinternational.com/glossary/formallearning.htm
http://www.infed.org/features/informal_learning.htm
http://www.openclinical.org/gmm_hgml.html
InterMed Collaboratory: Guideline Interchange Format 3.5 Technical Specification. May 4th,
2004 http://www.glif.org/glif_main.html
E2210-02 Standard Specification for Guideline Elements Model (GEM)-Document Model for
Clinical Practice Guidelines Developed by Subcommittee: E31.28 Book of Standards Volume:
14.01. ASTM International, 2003.
Boxwala AA, Peleg M, Tu S et al. GLIF3: a representation format for sharable computer-
interpretable clinical practice guidelines. J Biomed Inform. 2004 Jun;37(3):147-61.
Hagerty CG, Pickens D, Kulikowski C, Sonnenberg F. HGML: a hypertext guideline markup
language. Proc AMIA Symp. 2000;:325-9.
58
59
ANEXO 1.
XML que codifica la guía de práctica clínica de prevención del Cancer Colorrectal.
<?xml version="1.0" encoding="UTF-8"?>



<Guideline xmlns:xdb="http://xmlns.oracle.com/xdb" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="C:\clinico\prueba schema2.xsd">
<Algorithm>
<DecissionStep>
<InfoGuidelineStep>
<id>1</id>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<name>Debe realizar la/s siguiente/s accion/es:</name>
<id>2</id>
<name>diagnóstico</name>
<description>Realizar diagnóstico preciso</description>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<name>¿El paciente tienen factores de riesgo familiar y/o personal?</name>
<id>3</id>
<DecissionOption>
<Name>Cierto</Name>
<DisplayName>Si</DisplayName>
<Criterion>
<Name>Cierto</Name>
<GetDataItems>
<Item>fact_riesg_pers_fam</Item>
</GetDataItems>
<Condition>
<Name1>fact_riesg_pers_fam</Name1>
<Name2>true</Name2>
</Condition>
</Criterion>
60
<BranchStep>
<InfoGuidelineStep>
<id>4</id>
<DecissionStep>
<InfoGuidelineStep>
<name>¿El paciente tiene factores de riesgo familiar?</name>
<id>6_1</id>
<DecissionOption>
<Name>CCR_familiar</Name>
<DisplayName>CCR</DisplayName>
<Criterion>
<Name>CCR familiar</Name>
<GetDataItems>
<Item>ccr_familiar</Item>
</GetDataItems>
<Condition>
<Name1>ccr_familiar</Name1>
<Name2>true</Name2>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<name>¿Parentesco familiar afecto más próximo?</name>
<id>10</id>
<DecissionOption>
<Name>Primer Grado</Name>
<DisplayName>Primer Grado</DisplayName>
<Criterion>
<Name>CCR familiar afectado más próximo caso de primer
grado</Name>
<GetDataItems>
<Item>ccr_grado_familiar_afectado_mas_proximo</Item>
</GetDataItems>
<Condition>
<Name1>ccr_grado_familiar_afectado_mas_proximo</Name1>
<Name2>1</Name2>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<name>Número de familiares afectos:</name>
<id>11</id>
<DecissionOption>
<Name>Uno</Name>
<DisplayName>1</DisplayName>
<Criterion>
<Name>Uno</Name>
<GetDataItems>
<Item>mas_de_un_familiar_afectado_ccr_primer_grado</Item>
</GetDataItems>
<Condition>
<Name1>mas_de_un_familiar_afectado_ccr_primer_grado</Name1>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<name>Edad diagnosticada</name>
<id>13</id>
<DecissionOption>
<Name>Menos de 60</Name>
<DisplayName> menos de 60 años</DisplayName>
61
<Criterion>
<GetDataItems>
<Item>menos_de_60_diagnosticado_ccr_unico_familiar_primer_grado_afectado</Item>
</GetDataItems>
<Condition>
<Name1>menos_de_60_diagnosticado_ccr_unico_familiar_primer_grado_afectado</Name1>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<name>Debe realizarse las siguientes
pruebas:</name>
<id>14_1</id>
<description>Colonoscopia cada 5 años a partir
de cumplir los 40 años</description>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Name>Mas de 60</Name>
<DisplayName>>=60 años</DisplayName>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
pruebas:</name>
<id>14_2</id>
<name>SOH</name>
<description>SOH anual o bienal</description>
<description>Sigmoidoscopia cada 5
años</description>
<description>Colonoscopia cada 10
años</description>
</ActionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
<DecissionOption>
<DisplayName>>=2</DisplayName>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
62
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
pruebas:</name>
<id>14_2</id>
<description>Colonoscopia cada 5 años a partir de
cumplir los 40 años</description>
</ActionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
<DecissionOption>
<Name>Segundo Grado</Name>
<DisplayName>Segundo Grado</DisplayName>
<Criterion>
<Name>CCR familiar afectado más próximo caso de segundo
grado</Name>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>2</Name2>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<id>12</id>
<DecissionOption>
<Name>Uno</Name>
<Criterion>
<Name>Uno</Name>
<GetDataItems>
<Item>mas_de_un_familiar_afectado_ccr_segundo_grado</Item>
</GetDataItems>
<Condition>
<Name1>mas_de_un_familiar_afectado_ccr_segundo_grado</Name1>
<Name2>false </Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<name>Debe realizar las siguientes pruebas (a partir de
cumplir los 40 años)</name>
<id>15_3</id>
<name>SOH</name>
años</description>
63
</ActionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<name>Debe realizarse las siguientes pruebas (a partir
de cumplir los 50 años):</name>
<id>15_2</id>
<name>SOH</name>
años</description>
</ActionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
<DecissionOption>
<Name>Tercer Grado</Name>
<DisplayName>Tercer Grado</DisplayName>
<Criterion>
<Name>CCR familiar afectado más próximo caso de tercer
grado</Name>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>3</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<name>Debe realizar la/s siguiente/s accion/es (a partir de
cumplir los 50 años):</name>
<id>7_1</id>
<name>SOH</name>
</ActionStep>
</DecissionOption>
</DecissionStep>
64
</DecissionOption>
<DecissionOption>
<Name>CCHNP_familiar</Name>
<DisplayName>CCHNP</DisplayName>
<Criterion>
<Name>CCHNP_Familiar</Name>
<GetDataItems>
<Item>cchnp_familiar</Item>
</GetDataItems>
<Condition>
<Name1>cchnp_familiar</Name1>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<name>Estudio específico</name>
<id>9_1</id>
<description>Aplicar los métodos necesarios para realizar el
cribado</description>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Name>PAF_familiar</Name>
<DisplayName>PAF</DisplayName>
<Criterion>
<GetDataItems>
<Item>paf_familiar</Item>
</GetDataItems>
<Condition>
<Name1>paf_familiar</Name1>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<id>9_2</id>
</ActionStep>
</DecissionOption>
</DecissionStep>
<DecissionStep>
<InfoGuidelineStep>
<name>¿El paciente tiene factores de riesgo personal?</name>
<id>6_2</id>
<DecissionOption>
<Name>Adenoma</Name>
<DisplayName>Adenoma</DisplayName>
<Criterion>
<Name>adenoma</Name>
<GetDataItems>
<Item>adenoma_personal</Item>
</GetDataItems>
<Condition>
<Name1>adenoma_personal</Name1>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<name>Algoritmo 3\n</name>
65
<id>17</id>
<name>polipectomía endoscópica</name>
<description>Realizar la prueba de polipectomía
endoscópica</description>
<name>[FILE]</name>
<description/>
<DecissionStep>
<InfoGuidelineStep>
<name>¿Carcinoma invasivo?</name>
<id>17</id>
<DecissionOption>
<Name>Cierto carcinoma invasivo</Name>
<Criterion>
<Name>carcinoma invasivo personal cierto</Name>
<GetDataItems>
<Item>carcinoma_invasivo_personal</Item>
</GetDataItems>
<Condition>
<Name1>carcinoma_invasivo_personal</Name1>
<Name2>true</Name2>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<name>¿Criterio de buen pronóstico?</name>
<id>19</id>
<DecissionOption>
<Name>Existe criterio de buen pronóstico</Name>
<Criterion>
<Name>Existe criterio de buen diagnóstico</Name>
<GetDataItems>
<Item>criterio_buen_diagnóstico_adenoma_colorrectal</Item>
</GetDataItems>
<Condition>
<Name1>criterio_buen_diagnóstico_adenoma_colorrectal</Name1>
<Operator>= =</Operator>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
pruebas:</name>
<id>22</id>
<description>Colonoscopia a los 3
meses</description>
<name>Biopsias </name>
<description>Biopsias a los 3 meses</description>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Name>Dudas sobre el criterio del buen
pronóstico</Name>
<Criterion>
<Name>No existe criterio de buen diagnostico</Name>
<GetDataItems>
66
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
pruebas:</name>
<id>21</id>
<name>Cirugía</name>
<description>Realizar cirugía</description>
</ActionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
<DecissionOption>
<Name>Falso Carcinoma invasivo</Name>
<Criterion>
<Name>carcinoma invasivo personal falso</Name>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<name>¿Pólipo sésil o de gran tamaño ?</name>
<id>20</id>
<DecissionOption>
<Name>Existe pólipo sésil o de gran tamaño</Name>
<Criterion>
<Name>Existencia de pólipo sésil o de gran
tamaño</Name>
<GetDataItems>
<Item>polipo_sesil_o_gran_tamano_personal</Item>
</GetDataItems>
<Condition>
<Name1>polipo_sesil_o_gran_tamano_personal</Name1>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
pruebas:</name>
<id>23</id>
<description>Colonoscopia a los 3-6
meses</description>
<name>Biopsias</name>
<description>Biopsias a los 3-6
meses</description>
67
</ActionStep>
</DecissionOption>
<DecissionOption>
<Name>No existe pólipo sésil o de gran tamaño</Name>
<Criterion>
<Name>No existencia de pólipo sésil o de gran
tamaño</Name>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<name>¿Exploración completa y bien preparada
?</name>
<id>24</id>
<DecissionOption>
<Name>Cumple las condiciones de la
exploración</Name>
<Criterion>
<Name>Cumple</Name>
<GetDataItems>
<Item>exploracion_completa_adenoma_personal</Item>
</GetDataItems>
<Condition>
<Name1>exploracion_completa_adenoma_personal</Name1>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<name>Debe realizar las siguientes
acciones:</name>
<id>26</id>
<description>Repetir
colonoscopia</description>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Name>No las cumple</Name>
<Criterion>
<Name>No cumple</Name>
<GetDataItems>
</GetDataItems>
<Condition>
<Operator>==false</Operator>
<Name2/>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<name>¿3 o más adenomas, o adenoma
avanzado o familiar primer grado con CCR ?</name>
<id>25</id>
68
<DecissionOption>
<Name>Cierto</Name>
<Criterion>
<Name>3 o mas adenomas</Name>
<GetDataItems>
<Item>3_o_mas_adenomas_o_avanzado_o_familiar_primer_grado_con_CCR</Item>
</GetDataItems>
<Condition>
<Name1>3_o_mas_adenomas_o_avanzado_o_familiar_primer_grado_con_CCR</Name1>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<name>Debe realizar la siguiente
prueba:</name>
<id>27</id>
años</description>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Name>Falso</Name>
<Criterion>
<Name>menos de 3
adenomas</Name>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
prueba:</name>
<id>28</id>
años</description>
</ActionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
</DecissionStep>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Name>Enfermedad inflamatoria intestinal</Name>
<DisplayName>Enfermedad inflamatoria intestinal</DisplayName>
<Criterion>
<Name>eii</Name>
<GetDataItems>
69
<Item>eii_personal</Item>
</GetDataItems>
<Condition>
<Name1>eii_personal</Name1>
<Name2>true</Name2>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<name>Algoritmo 4\n ¿Colangitis esclerosante?</name>
<id>16</id>
<DecissionOption>
<Name>Cierto colangitis esclerosante</Name>
<Criterion>
<Name>Colangitis esclerosante</Name>
<GetDataItems>
<Item>colangitis_esclerosante_personal</Item>
</GetDataItems>
<Condition>
<Name1>colangitis_esclerosante_personal</Name1>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<name>Debe hacerse las siguientes pruebas:</name>
<id>29</id>
<description>Colonoscopia anual</description>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Name>Falso colangitis esclerosante</Name>
<Criterion>
<Name>No colangitis esclerosante</Name>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<name>¿Extensión de la enfermedad ?</name>
<id>30</id>
<DecissionOption>
<Name>Proctitis</Name>
<DisplayName>Proctitis</DisplayName>
<Criterion>
<Name/>
<GetDataItems>
<Item/>
</GetDataItems>
<Condition>
<Name1/>
<Operator/>
<Name2/>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<name>Debe realizar:</name>
<id>33</id>
70
<name>Sin vigilancia</name>
<description>No es necesaria Vigilancia</description>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Name>Pancolitis</Name>
<DisplayName>Pancolitis</DisplayName>
<Criterion>
<Name/>
<GetDataItems>
<Item/>
</GetDataItems>
<Condition>
<Name1/>
<Operator/>
<Name2/>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<name>¿Tiempo de evolución ?</name>
<id>31</id>
<DecissionOption>
<Name>mas de 8 - 10 años</Name>
<DisplayName>mas de 8 -10 años</DisplayName>
<Criterion>
<Name>mas de 8 -10 años</Name>
<GetDataItems>
<Item>tiempo_evolucion_pancolitis_mas_8_10</Item>
</GetDataItems>
<Condition>
<Name1>tiempo_evolucion_pancolitis_mas_8_10</Name1>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<name>Debe realizarse la/s siguiente/s
prueba/s:</name>
<id>34</id>
<description>Colonoscopia, se recomienda
efectual una colonoscopia cada 3 años durante la segunda década de evolución, cada dos años durante la tercera
década y anual durante la cuarta década.</description>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Name>menos de 8 - 10 años</Name>
<DisplayName>menos de 8 - 10 años</DisplayName>
<Criterion>
<Name>menos de 8-10 años</Name>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<id>33_1</id>
71
<description>No es necesaria
Vigilancia</description>
</ActionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
<DecissionOption>
<Name>Colitis izquierda</Name>
<DisplayName>Colitis izquierda</DisplayName>
<Criterion>
<Name/>
<GetDataItems>
<Item/>
</GetDataItems>
<Condition>
<Name1/>
<Operator/>
<Name2/>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<id>32</id>
<DecissionOption>
<Name>mas de 15 años</Name>
<DisplayName>mas de 15 años</DisplayName>
<Criterion>
<GetDataItems>
<Item>tiempo_evolucion_colitis_izquierda_mas_de_15</Item>
</GetDataItems>
<Condition>
<Name1>tiempo_evolucion_colitis_izquierda_mas_de_15</Name1>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
prueba/s:</name>
<id>34_1</id>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Name>menos de 15 años</Name>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<ActionStep>
72
<InfoGuidelineStep>
<id>33_2</id>
</ActionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
</DecissionStep>
</BranchStep>
</DecissionOption>
<DecissionOption>
<Name>Falso</Name>
<Criterion>
<Name>Falso</Name>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<name>¿Tiene más de 50 años?</name>
<id>5</id>
<DecissionOption>
<Name>Tiene mas de 50 años</Name>
<Criterion>
<Name>Cierto</Name>
<GetDataItems>
<Item>mas_de_50</Item>
</GetDataItems>
<Condition>
<Name1>mas_de_50</Name1>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<name>Debe realizar las siguientes pruebas</name>
<id>7</id>
<name>SOH</name>
<description>SOH anual ó biennal</description>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Name>Tiene menos de 50 años</Name>
<Criterion>
73
<Name>Falso</Name>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<name>No debe realizar ninguna acción</name>
<id>8</id>
<name>Libre</name>
<description>No pertenece a ningún grupo de riesgo</description>
</ActionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
</DecissionStep>
</Algorithm>
<MaintenanceInfo>
<Title>Guia de práctica clínica de la prevención del cáncer colorrectal</Title>
<AuthoringDate>Marzo de 2004</AuthoringDate>
</MaintenanceInfo>
</Guideline>
74
75
ANEXO 2.
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
ANEXO 3.
XML resultante del primer caso de uso.
Baró de 39 anys, sense antecedents personals d’interès, que sol·licita consell en relació a la prevenció del
càncer colorrectal. Refereix que el seu pare va ser diagnosticat d’aquesta malaltia als 47 anys d’edat, tractat
amb cirurgia i quimioteràpia, i morint als 50 anys. És tributari d’alguna mesura preventiva? Quina és la tècnica
més adient? Si no s’observen alteracions, quan cal tornar-la a fer?

<Algorithm>
<DecissionStep>
<InfoGuidelineStep>
<id>1</id>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<id>2</id>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<id>3</id>
<DecissionOption>
<Name>Cierto</Name>
<Criterion>
<Name>Cierto</Name>
<GetDataItems>
</GetDataItems>
<Condition>
91
<Name2>true</Name2>
</Condition>
</Criterion>
<BranchStep>
<InfoGuidelineStep>
<id>4</id>
<DecissionStep>
<InfoGuidelineStep>
<id>6_1</id>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<id>10</id>
<DecissionOption>
<Criterion>
grado</Name>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>1</Name2>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<id>11</id>
<DecissionOption>
<Name>Uno</Name>
<Criterion>
<Name>Uno</Name>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<id>13</id>
92
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
pruebas:</name>
<id>14_1</id>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
pruebas:</name>
<id>14_2</id>
<name>SOH</name>
años</description>
años</description>
</ActionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<GetDataItems>
93
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
pruebas:</name>
<id>14_2</id>
</ActionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
grado</Name>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>2</Name2>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<id>12</id>
<DecissionOption>
<Name>Uno</Name>
<Criterion>
<Name>Uno</Name>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<id>15_3</id>
<name>SOH</name>
años</description>
94
</ActionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<id>15_2</id>
<name>SOH</name>
años</description>
</ActionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
grado</Name>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>3</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<id>7_1</id>
<name>SOH</name>
95
</ActionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<id>9_1</id>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<id>9_2</id>
</ActionStep>
</DecissionOption>
</DecissionStep>
<DecissionStep>
<InfoGuidelineStep>
<id>6_2</id>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
96
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<id>17</id>
<name>[FILE]</name>
<description/>
<DecissionStep>
<InfoGuidelineStep>
<id>17</id>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<id>19</id>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
pruebas:</name>
<id>22</id>
meses</description>
</ActionStep>
</DecissionOption>
<DecissionOption>
pronóstico</Name>
97
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
pruebas:</name>
<id>21</id>
</ActionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<id>20</id>
<DecissionOption>
<Criterion>
tamaño</Name>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
pruebas:</name>
<id>23</id>
meses</description>
98
meses</description>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
tamaño</Name>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
?</name>
<id>24</id>
<DecissionOption>
exploración</Name>
<Criterion>
<Name>Cumple</Name>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
acciones:</name>
<id>26</id>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2/>
</Condition>
</Criterion>
<DecissionStep>
99
<InfoGuidelineStep>
<id>25</id>
<DecissionOption>
<Name>Cierto</Name>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
prueba:</name>
<id>27</id>
años</description>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Name>Falso</Name>
<Criterion>
<Name>menos de 3
adenomas</Name>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
prueba:</name>
<id>28</id>
años</description>
</ActionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
</DecissionStep>
</ActionStep>
</DecissionOption>
<DecissionOption>
100

<Criterion>
<Name>eii</Name>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<id>16</id>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<id>29</id>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<id>30</id>
<DecissionOption>
<Criterion>
<Name/>
<GetDataItems>
<Item/>
</GetDataItems>
<Condition>
<Name1/>
<Operator/>
<Name2/>
</Condition>
</Criterion>
101
<ActionStep>
<InfoGuidelineStep>
<id>33</id>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<Name/>
<GetDataItems>
<Item/>
</GetDataItems>
<Condition>
<Name1/>
<Operator/>
<Name2/>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<id>31</id>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
prueba/s:</name>
<id>34</id>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
102
<ActionStep>
<InfoGuidelineStep>
<id>33_1</id>
</ActionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<Name/>
<GetDataItems>
<Item/>
</GetDataItems>
<Condition>
<Name1/>
<Operator/>
<Name2/>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<id>32</id>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
prueba/s:</name>
<id>34_1</id>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
103
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<id>33_2</id>
</ActionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
</DecissionStep>
</BranchStep>
</DecissionOption>
<DecissionOption>
<Name>Falso</Name>
<Criterion>
<Name>Falso</Name>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<id>5</id>
<DecissionOption>
<Criterion>
<Name>Cierto</Name>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<id>7</id>
<name>SOH</name>
</ActionStep>
</DecissionOption>
104
<DecissionOption>
<Criterion>
<Name>Falso</Name>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<id>8</id>
<name>Libre</name>
</ActionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
</DecissionStep>
</Algorithm>
<MaintenanceInfo>
</MaintenanceInfo>
<DataItem>
<Name>Name</Name>
<Value>Andrés</Value>
</DataItem>
<DataItem>
<Name>Surname1</Name>
<Value>García</Value>
</DataItem>
<DataItem>
<Value>González</Value>
</DataItem>
<DataItem>
<Name>ID</Name>
<Value>46754321J</Value>
</DataItem>
<DataItem>
<Name>sosp_CCR</Name>
<Value>false</Value>
</DataItem>
<DataItem>
<Name>fact_riesg_pers_fam</Name>
<Value>true</Value>
</DataItem>
<DataItem>
<Name>ccr_familiar</Name>
<Value>true</Value>
</DataItem>
<DataItem>
<Name>ccr_grado_familiar_afectado_mas_proximo</Name>
<Value>1</Value>
</DataItem>
<DataItem>
<Name>mas_de_un_familiar_afectado_ccr_primer_grado</Name>
</DataItem>
<DataItem>
<Name>menos_de_60_diagnosticado_ccr_unico_familiar_primer_grado_afectado</Name>
<Value>true</Value>
</DataItem>
</Guideline>
105
XML resultante del segundo caso de uso.
A aquest mateix individu se li detecta la presència d’un pòlip pediculat en el còlon ascendent de 15 mm. La
preparació del còlon era correcta i l’exploració va ser completa. Es procedeix a la seva resecció endoscòpica i
posterior estudi anatomopatològic. Aquest posa en evidència que es tracta d’un adenoma tubulovellòs, amb
displàsia d’alt grau. Quina estratègia de vigilància cal recomanar-li?

<Algorithm>
<DecissionStep>
<InfoGuidelineStep>
<id>1</id>
<comment>A aquest mateix individu se li detecta la presència d’un pòlip pediculat en el còlon
ascendent de 15 mm. La preparació del còlon era correcta i l’exploració va ser completa. Es procedeix a la seva
resecció endoscòpica i posterior estudi anatomopatològic. Aquest posa en evidència que es tracta d’un adenoma
tubulovellòs, amb displàsia d’alt grau. </comment>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<id>2</id>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<id>3</id>
<DecissionOption>
<Name>Cierto</Name>
<Criterion>
<Name>Cierto</Name>
<GetDataItems>
106
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<BranchStep>
<InfoGuidelineStep>
<id>4</id>
<DecissionStep>
<InfoGuidelineStep>
<id>6_1</id>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<id>10</id>
<DecissionOption>
<Criterion>
grado</Name>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>1</Name2>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<id>11</id>
<DecissionOption>
<Name>Uno</Name>
<Criterion>
<Name>Uno</Name>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<DecissionStep>
107
<InfoGuidelineStep>
<id>13</id>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
pruebas:</name>
<id>14_1</id>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
pruebas:</name>
<id>14_2</id>
<name>SOH</name>
años</description>
años</description>
</ActionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
<DecissionOption>
108
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
pruebas:</name>
<id>14_2</id>
</ActionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
grado</Name>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>2</Name2>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<id>12</id>
<DecissionOption>
<Name>Uno</Name>
<Criterion>
<Name>Uno</Name>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<id>15_3</id>
<name>SOH</name>
109
años</description>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<id>15_2</id>
<name>SOH</name>
años</description>
</ActionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
grado</Name>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>3</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<id>7_1</id>
<name>SOH</name>
110
</ActionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<id>9_1</id>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<id>9_2</id>
</ActionStep>
</DecissionOption>
</DecissionStep>
<DecissionStep>
<InfoGuidelineStep>
<id>6_2</id>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
111
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<id>17</id>
<name>[FILE]</name>
<description>./polipectomia_endoscopica.pdf</description>
<DecissionStep>
<InfoGuidelineStep>
<id>17</id>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<id>19</id>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
pruebas:</name>
<id>22</id>
meses</description>
</ActionStep>
</DecissionOption>
112
<DecissionOption>
pronóstico</Name>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
pruebas:</name>
<id>21</id>
</ActionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<id>20</id>
<DecissionOption>
<Criterion>
tamaño</Name>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
pruebas:</name>
<id>23</id>
113

meses</description>
meses</description>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
tamaño</Name>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
?</name>
<id>24</id>
<DecissionOption>
exploración</Name>
<Criterion>
<Name>Cumple</Name>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
acciones:</name>
<id>26</id>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
114
<Name2/>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<id>25</id>
<DecissionOption>
<Name>Cierto</Name>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
prueba:</name>
<id>27</id>
años</description>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Name>Falso</Name>
<Criterion>
<Name>menos de 3
adenomas</Name>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
prueba:</name>
<id>28</id>
años</description>
</ActionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
</DecissionStep>
115
</ActionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<Name>eii</Name>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<id>16</id>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<id>29</id>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<id>30</id>
<DecissionOption>
<Criterion>
<Name/>
<GetDataItems>
<Item/>
</GetDataItems>
<Condition>
<Name1/>
116
<Operator/>
<Name2/>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<id>33</id>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<Name/>
<GetDataItems>
<Item/>
</GetDataItems>
<Condition>
<Name1/>
<Operator/>
<Name2/>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<id>31</id>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
prueba/s:</name>
<id>34</id>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
117
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<id>33_1</id>
</ActionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<Name/>
<GetDataItems>
<Item/>
</GetDataItems>
<Condition>
<Name1/>
<Operator/>
<Name2/>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<id>32</id>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
prueba/s:</name>
<id>34_1</id>
</ActionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<GetDataItems>
</GetDataItems>
118
<Condition>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<id>33_2</id>
</ActionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
</DecissionStep>
</BranchStep>
</DecissionOption>
<DecissionOption>
<Name>Falso</Name>
<Criterion>
<Name>Falso</Name>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<DecissionStep>
<InfoGuidelineStep>
<id>5</id>
<DecissionOption>
<Criterion>
<Name>Cierto</Name>
<GetDataItems>
</GetDataItems>
<Condition>
<Name2>true</Name2>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<id>7</id>
<name>SOH</name>
119

</ActionStep>
</DecissionOption>
<DecissionOption>
<Criterion>
<Name>Falso</Name>
<GetDataItems>
</GetDataItems>
<Condition>
</Condition>
</Criterion>
<ActionStep>
<InfoGuidelineStep>
<id>8</id>
<name>Libre</name>
</ActionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
</DecissionStep>
</DecissionOption>
</DecissionStep>
</Algorithm>
<MaintenanceInfo>
</MaintenanceInfo>
<DataItem>
<Name>Name</Name>
<Value>Andrés</Value>
</DataItem>
<DataItem>
<Value>García</Value>
</DataItem>
<DataItem>
<Value>González</Value>
</DataItem>
<DataItem>
<Name>ID</Name>
<Value>46754321J</Value>
</DataItem>
<DataItem>
<Name>sosp_CCR</Name>
</DataItem>
<DataItem>
<Name>fact_riesg_pers_fam</Name>
<Value>true</Value>
</DataItem>
<DataItem>
<Name>eii_personal</Name>
<Value>true</Value>
</DataItem>
<DataItem>
<Name>carcinoma_invasivo_personal</Name>
<Value>true</Value>
</DataItem>
<DataItem>
<Name>criterio_buen_diagnóstico_adenoma_colorrectal</Name>
</DataItem>
</Guideline>
120
121
ANEXO 4
Using clinical guidelines in an eLearning context
Josep Blat, Ayman Moghnieh, Toni Navarrete, José Luis

Santos
Departament de Tecnologia. Universitat Pompeu Fabra
Passeig de Circumval·lació, 8. 08003 Barcelona, Spain
E-mail: {josep.blat, ayman.moghnieh, toni.navarrete, joseluis.santos} @upf.edu
Francis Casado
Fundació Barcelona Media
Carrer Ocata, 2. 08003 Barcelona, Spain
E-mail: francisco.casado@upf.edu
Abstract: Clinical guidelines have been widely used to standardise medical practices according
to scientific evidence, aiming at improving quality and reducing risks. In this paper we discuss
how clinical guidelines are also extremely useful in an eLearning context. The information
contained in the guideline, its decision workflow and its execution with real patients can be the
basis for both formal and informal learning processes involving medical students, medical
professionals or patients. We present different learning scenarios based on the use of clinical
guidelines. We also describe the main elements of our guideline execution engine which is
currently under development.
Keywords: clinical guidelines, eLearning, formal learning, informal learning, lifelong learning
1 Introduction
Clinical guidelines are defined as “systematically developed statements to assist practitioner and
patient decisions about appropriate health care for specific clinical circumstances” (Institute of Medicine,
1990). A clinical guideline is a document describing a set of explicit recommendations, based on
scientific evidence, with the aim of guiding medical professionals and patients. Other commonly used
names for “clinical guidelines” are “medical guidelines”, “clinical practice guidelines” and “clinical
protocols”.
A clinical guideline addresses a specific medical problem and may be related to one or more stages of
the problem, as for instance prevention, diagnosis or therapy. A clinical guideline summarises consensus
information related to the medical problem, and then it addresses practical issues. It defines the main
questions related to clinical practice and identifies a workflow of all possible decision options and their
outcomes. This way, the clinical guideline provides a protocol of decisions and actions to be taken.
Depending on the focus of the guideline, these actions may consist of, for instance, specific clinical tests
to be carried out (in diagnosis guidelines) or specific medications (in therapy guidelines).
As we can observe, the main objective of clinical guidelines is to standardize medical care, improving
quality and reducing risks, based on scientific evidence. Some guidelines may also focus on other aspects
as the improvement of the efficiency and the reduction of costs. We will see in Section 3 that guidelines
also offer a valuable tool in the education of medical professionals and patients.
Clinical guidelines are usually developed at national and international levels by medical associations
and governmental institutions. These top-level guidelines are usually adapted by local organizations, such
as hospitals, to produce their own guidelines.
Although the use of clinical guidelines presents clear advantages, the development of a big number of
guidelines in the last years has originated situations where different guidelines contain conflicting
recommendations. Quality in the process of development of guidelines has become an increasing concern
122
(Grilli et al. 2000 and Shaneyfelt et al. 1999). There is a clear need for a common, valid and transparent
approach to develop good clinical practice guidelines. In Europe, the AGREE (Appraisal of Guidelines,
Research and Evaluation for Europe) instrument (AGREE Collaboration 2001) has been developed to
provide a tool for the assessment of the quality of guidelines. This tool can also support guideline
developers to follow a rigorous development methodology.
Clinical guidelines are often published in on-line catalogues, which are mainly built at national level
usually maintained by Health ministries. The biggest one is the National Guideline Clearinghouse1 (NGC)
from the USA, that comprises more than 2,000 guidelines, that have to be published under the auspices of
a medical association or a government agency and developed or revised within the last 5 years. Other on-
line databases are of significant importance in the development of clinical guidelines. The most salient are
the Cochrane2 evidence-base medicine database, as well as other medical literature databases, as the
PubMed3.
A guidelines execution engine is a software component that runs a clinical guideline for every
different patient. The patient’s data is structured to match the structure of the guideline. The guideline
execution engine enables the medical professional to follow the workflow for each patient, as well as to
receive the recommendations from the guideline at each step. Guideline execution engines are also
usually referred as medical decision support system or as interactive clinical guideline.
It has to be noted that, although a big number of guidelines are published in catalogues like NGC,
they are represented in an unstructured way, usually through PDF files. Guidelines have to be modelled in
order to be run in an execution engine. However, different engines use different models, making
interoperability impossible. To solve this problem, some specifications have been developed to model
clinical guidelines in a shareable way. Unfortunately, none of them has become a standard. GLIF
(Guideline Interchange Format) (InterMed Collaboratory 2004) is probably both the most complete and
the most widespread among them.
The rest of the paper is structures as follows. Section 2 describes the structure of an application for
running clinical guidelines, in particular the Guideline for the prevention of colorectal cancer (Asociación
Española de Gastroenterología et al. 2004). Section 3 discusses different scenarios where clinical
guidelines can be used in an educational framework. Finally, Section 4 states the main conclusions as
well as the following steps in our work.
2 An application to run clinical practice guidelines

We describe in this section the main elements of our guideline execution engine. This engine is being
developed with the main objective of running the Guideline for the prevention of colorectal cancer
(Asociación Española de Gastroenterología et al. 2004). It has to deal with patients data and control the
decision workflow specified in the guideline, providing the corresponding recommendations to the
doctor.
Nevertheless, the final objective is to build a more general engine, capable of running other
guidelines. We have chosen a subset of GLIF to model guidelines in a shareable way. Note that GLIF is a
quite complex specification and contains many classes apart from those specifying the decision workflow.
Our subset contains all the entities that are defined in GLIF to model the different types of steps in the
workflow (Decision_Step, Action_Step, Branch_Step, Synchronization_Step and Patient_State_Step).
GLIF contains references to didactic materials that can be related to the overall guideline or to specific
sections. Our subset also implements these elements for didactic materials.
Unfortunately there are no open source libraries for managing GLIF models, so we are currently
developing a Java library to manage them, which will be the core of the engine. Figure 1 shows a general
architecture for the engine.
The engine has also to keep track of the decisions for specific patients. Note that while guidelines are
modelled in GLIF, this specification does not cover patients executions, and consequently a schema to
represent them has also been defined.
1
http://www.guideline.gov
2
http://www.cochrane.org
3
http://www.pubmed.gov
123
Java
Library for
GLIF
Guideline
Execution
Engine
Clinical
Guideline
(PDF) Guideline data model
(GLIF)
Figure 1. General architecture for a guideline execution engine using GLIF

It has to be stressed that guidelines are usually built in a dynamic way. This means that guidelines are
usually modified based on experience and new research results. The guideline execution engine can be
used to this purpose, as a way to monitor and evaluate the evolution of patients according to the
recommendations provided by the guideline. This information is valuable to update the guideline itself
based on experience. Although not explicitly represented in the previous figure, we can observe that the
output of the guideline execution engine can be used as an input to the definition of the clinical guideline,
determining an iterative guideline definition process.
3 Clinical guidelines in an eLearning context

Clinical guidelines contain a systematic review of the scientific evidence focusing on a specific
medical problem. Furthermore, they provide an integrated view on how to address the problem in
practical terms: which decisions should be taken in each situation. All this information can be used as a
valuable source in the learning process of Medicine students, as well as in the continuing education of
medical professionals. Studies show that practice-based education through guidelines and decision
support systems improve the detection of diseases. (Feder 1995) shows the improvement of the results of
detection of asthmatic and diabetic problems in primary care, while (Downs 2006) shows the results of
detection of dementia in primary care, compared to other educational options.
Medical students and professionals can also learn from executions of guidelines with data of real
patients. Simulation tools where students or professionals have to determine the right decision in
situations taken from real cases can also be useful for learning.
Clinical guidelines can also provide helpful information for patients that want to be informed on their
situation. Especially relevant for patients are prevention guidelines, since patients are usually required to
play an active role in this case.
As we have noted in the previous section, guidelines are usually modified based on new evidence.
While training materials become quickly obsolete when traditional learning approaches are used, the use
of guidelines as the centre of the learning process provides a more dynamic approach, making the
adaptation to changes easier.
We will now present four different learning scenarios where the clinical guideline for the prevention
of colorectal cancer can be used.
Scenario 1
A Medicine degree student has registered for the subject called “Gastroenterology”. A module of this
subject is given by means of eLearning and is based on clinical guidelines. The student analyses the
scientific evidence related to each guideline. Then he has to study the corresponding decision workflows.
He will put these concepts into practice through solving specific cases as required by the course’s
proceedings. The student also communicates with other peers in order to share advice and solicit support
in addressing the challenges generated by the clinical guideline.
This scenario provides an example of using guidelines and their executions in the context of formal
learning. Communication is an important issue here too.
124
Scenario 2
A person is suffering from syndromes that might be related to colorectal cancer. The diagnosis
procedures and their course are difficult for him to follow and understand. However, the patient will be
much more comfortable through the diagnosis period if he understood the procedures exactly. The patient
raises the issue with his doctor who recommends him the use of an interactive clinical guideline as part of
a learning program dedicated to the patients under colorectal cancer diagnosis. The system synchronizes
the patient’s digital copy of the clinical guideline with the information recorded on his doctor’s computer,
and simplifies medical matters in order to make the process understandable by non-medical persons.
This scenario provides an example of customization of the information and its visualisation. This is a
key element in order to enable patients to understand guidelines.
Scenario 3
A family doctor is trying to diagnose a patient with unfamiliar set of symptoms in order to prevent the
development of colorectal cancer. In his work in an isolated city of a remote area, he has difficulties
maintaining contact with experts in gastroenterology in order to share knowledge and experience. He
decides to use an online eLearning and knowledge sharing system through which he can maintain
relationships with other doctors and solicit support whenever needed. The system uses clinical guidelines,
as well as a repository of real patient’s executions (of course, keeping anonymity). Colleagues can
respond to questions from peers quickly and efficiently without having to spend a lot of time of studying
the relevant case.
This scenario provides an example of using guidelines as the base of a learning community.
Scenario 4
A doctor is specialist in cardiology and gastroenterology, but during most of years in his practice, he
has only concentrated on cardiology specialities as part of his work in the local hospital. Recently, a post
in the hospital has opened for a gastroenterology specialist, so he decided to give it a try. On the other
hand, he knows that he needs to refresh his knowledge about gastroenterology area. He then uses an
interactive clinical guideline designed to simulate the diagnosis and prevention measures associated with
real cases in order to sharpen his skills in this area. By trial and error, he is able to recuperate and update
his skills in the area of gastroenterology in a matter of weeks without taking classes or training courses.
This scenario provides an example of a process of refreshing memory in a context of informal
learning.
4 Conclusions and further work

The scenarios described in the previous section show how clinical guidelines can be used in the
context of formal and informal learning. In the case of medical professionals, it is a good example of
lifelong learning based on competences acquisition.
Our plans for future work include the use of guidelines and their executions in the TENCompetence
client, as the basis for a business pilot. A repository containing clinical guidelines, as well as executions
of real patients, will be defined. Finally, a middleware will be built to enable the communication between
the TENCompetence client on the one hand and the repository and engine on the other, as Figure 2
shows. This middleware will consist of a layer providing a set of public web services, following the
Service Oriented Architecture approach used in the TENCompetence project.
125
Java
Library for
GLIF
Guideline
Execution
Engine
Clinical
Guideline
(PDF) Guideline data model Patient’s
executions
(GLIF) data
Guideline and
Executions
Repository
MIDDLEWARE
TENCompetence
CLIENT
Figure 2. Proposed architecture for using clinical guidelines with the TENCompetence Client
Acknowledgment
This work has been partially sponsored by the TENCompetence Integrated Project that is funded by
the European Commission's 6th Framework Programme, priority IST/Technology Enhanced Learning.
Contract 027087 (http://www.tencompetence.org)
References
AGREE Collaboration: Appraisal of Guidelines for Research & Evaluation (AGREE) Instrument.
www.agreecollaboration.org. 2001.
Asociación Española de Gastroenterología; Sociedad Española de Medicina de Familia y Comunitaria; Centro
Cochrane Iberoamericano: Guía de práctica clínica: prevención del cáncer colorrectal. Barcelona. 2004.
Downs, Murna; Turner, Stephen; Bryans, Michelle; Wilcock, Jane; Keady, John; Levin, Enid; O'Carroll, Ronan;
Howie, Kate; Iliffe, Steve: Effectiveness of educational interventions in improving detection and management
of dementia in primary care: cluster randomised controlled study. BMJ 2006 332: 692-696.
Feder, Gene; Griffiths, Chris; Highton, Clare; Eldridge, Sandra; Spence, Matthew; Southgate Lesley: Do clinical
guidelines introduced with practice based education improve care of asthmatic and diabetic patients? A
randomised controlled trial in general practices in east London. BMJ 1995 311: 1473-1478.
Grilli, R.; Magrini, N.; Penna, A.; Mura G.; Liberati: Practice guidelines developed by specialty societies: the need
for a critical appraisal. Lancet 2000; 355: 103-5.
Institute of Medicine. Clinical Practice Guidelines: Directions for a New Program, M.J. Field and K.N. Lohr (eds.)
Washington, DC: National Academy Press. page 38. 1990.
InterMed Collaboratory: Guideline Interchange Format 3.5 Technical Specification. May 4th, 2004
Shaneyfelt, T.M.; Mayo-Smith, M.F.; Rothwangl: Are guidelines following guidelines? The methodological quality
of clinical practice guidelines in the peer-reviewed medical literature. JAMA 1999; 281: 1900-5.
126
127
ANEXO 5
MODELAJE DE PARTE DEL ALGORITMO DE LA GUÍA DE PRÁCTICA CLÍNICA DE PREVENCIÓN DEL

CÁNCER COLORRECTAL.
128
MODELAJE EN XML Y EJECUCIÓN DE LA GUÍA

• Página principal, independiente del xml
• Código xml incial de una guía sin personalizar

<Algorithm>
<FirstStep>s1</FirstStep> <!- -Indica el primer step a procesar -- >
</Algorithm>
• Step s1
<DecissionStep>
<InfoGuidelineStep>
<name>Posibilidad de polipectomía endoscópica</name>
<id>s1</id>
<DecissionOption>
<Name>polipectomia_endoscopica_posible</Name>
<Criterion>
<Name>polipectomia_endoscopica_posible</Name>
<GetDataItems>
<Item>polipectomia_endoscopica</Item>
</GetDataItems>
<Condition>
<Name1>polipectomia_endoscopica</Name1>
129
<Name2>true</Name2>
</Condition>
</Criterion>
<NextStep>s2</NextStep>
</DecissionOption>
<DecissionOption>
<Name>polipectomia_endoscopica_no_posible</Name>
<Criterion>
<Name>polipectomia_endoscopica_no_posible</Name>
<GetDataItems>
<Item>polipectomia_endoscopica</Item>
</GetDataItems>
<Condition>
<Name1>polipectomia_endoscopica</Name1>
</Condition>
</Criterion>
</DecissionOption>
</DecissionStep>
• S2
<ActionStep>
<InfoGuidelineStep>
<id>s2</id>
<name>resección quirúrgica</name>
<description>Resección quirúrgica</description>
130
</ActionStep>
• S3
<DecissionStep>
<InfoGuidelineStep>
<id>s3</id>
<DecissionOption>
<Name>carcinoma_invasivo_presente</Name>
<Criterion>
<Name>carcinoma_invasivo_presente</Name>
<GetDataItems>
<Item>carcinoma_invasivo</Item>
</GetDataItems>
<Condition>
<Name1>carcinoma_invasivo</Name1>
<Name2>true</Name2>
</Condition>
</Criterion>
</DecissionOption>
<DecissionOption>
<Name>carcinoma_invasivo_no_presente</Name>
<Criterion>
<Name>carcinoma_invasivo_no_presente</Name>
131
<GetDataItems>
<Item>carcinoma_invasivo</Item>
</GetDataItems>
<Condition>
<Name1>carcinoma_invasivo</Name1>
</Condition>
</Criterion>
</DecissionOption>
</DecissionStep>
• S4
<DecissionStep>
<InfoGuidelineStep>
<name>¿Criterios de buen pronóstico?</name>
<id>s4</id>
<DecissionOption>
<Name>criterios_buen_pronostico_carcinoma_invasivo_cierto</Name>
<Criterion>
<Name>criterios_buen_pronostico_carcinoma_invasivo_cierto</Name>
<GetDataItems>
<Item>criterios_buen_pronostico_carcinoma_invasivo</Item>
</GetDataItems>
<Condition>
<Name1>criterios_buen_pronostico_carcinoma_invasivo</Name1>
<Name2>true</Name2>
</Condition>
132
</Criterion>
</DecissionOption>
<DecissionOption>
<Name>criterios_buen_pronostico_carcinoma_invasivo_falso</Name>
<Criterion>
<Name>criterios_buen_pronostico_carcinoma_invasivo_falso</Name>
<GetDataItems>
<Item>criterios_buen_pronostico_carcinoma_invasivo</Item>
</GetDataItems>
<Condition>
<Name1>criterios_buen_pronostico_carcinoma_invasivo</Name1>
</Condition>
</Criterion>
</DecissionOption>
</DecissionStep>
• S5
<DecissionStep>
<InfoGuidelineStep>
<name>¿Sésil resecado?</name>
<id>s5</id>
<DecissionOption>
<Name>sesil_resecado_cierto</Name>
<Criterion>
<Name>sesil_resecado_cierto</Name>
133
<GetDataItems>
<Item>sesil_resecado</Item>
</GetDataItems>
<Condition>
<Name1>sesil_resecado</Name1>
<Name2>true</Name2>
</Condition>
</Criterion>
</DecissionOption>
<DecissionOption>
<Name>sesil_resecado_falso</Name>
<Criterion>
<Name>sesil_resecado_falso</Name>
<GetDataItems>
<Item>sesil_resecado</Item>
</GetDataItems>
<Condition>
<Name1>sesil_resecado</Name1>
</Condition>
</Criterion>
</DecissionOption>
</DecissionStep>
• S6
<ActionStep>
<InfoGuidelineStep>
<id>s6</id>
134
<name>FCS</name>
<description>FCS 3 meses con biopsia base</description>
</ActionStep>
• S6
• S7
<ActionStep>
<InfoGuidelineStep>
<id>s7</id>
<name>resección quirúrgica</name>
<description>Resección quirúrgica</description>
</ActionStep>
135
• S8
<DecissionStep>
<InfoGuidelineStep>
<name>¿Calidad de FCS adecuada?</name>
<id>s8</id>
<DecissionOption>
<Name>calidad_FCS_adecuada</Name>
<Criterion>
<Name>calidad_FCS_aecuada</Name>
<GetDataItems>
<Item>calidad_FCS</Item>
</GetDataItems>
<Condition>
<Name1>calidad_FCS</Name1>
<Name2>true</Name2>
</Condition>
</Criterion>
</DecissionOption>
<DecissionOption>
<Name>calidad_FCS_no_adecuada</Name>
<Criterion>
<Name>calidad_FCS_no_adecuada</Name>
<GetDataItems>
<Item>calidad_FCS</Item>
</GetDataItems>
136
<Condition>
<Name1>calidad_FCS</Name1>
</Condition>
</Criterion>
</DecissionOption>
</DecissionStep>
• S9
<ActionStep>
<InfoGuidelineStep>
<id>s9</id>
<name>FCS</name>
<description>FCS 2-6 meses con biopsia base</description>
</ActionStep>
137
• S10
<ActionStep>
<InfoGuidelineStep>
<id>s10</id>
<name>FCS</name>
<description>Repetir FCS</description>
</ActionStep>
138
• S11
<DecissionStep>
<InfoGuidelineStep>
<name>¿>=3 adenomas, o tamaño >= 1 cm, o DAG, o velloso?</name>
<id>s11</id>
<DecissionOption>
<Name>mas_3_adenomas_cierto</Name>
<Criterion>
<Name>mas_3_adenomas_cierto</Name>
<GetDataItems>
<Item>mas_3_adenomas</Item>
</GetDataItems>
<Condition>
<Name1>mas_3_adenomas</Name1>
<Name2>true</Name2>
</Condition>
</Criterion>
</DecissionOption>
<DecissionOption>
<Name>mas_3_adenomas_falso</Name>
<Criterion>
<Name>mas_3_adenomas_falso</Name>
<GetDataItems>
<Item>mas_3_adenomas</Item>
</GetDataItems>
139
<Condition>
<Name1>mas_3_adenomas</Name1>
</Condition>
</Criterion>
</DecissionOption>
</DecissionStep>
• S12
<DecissionStep>
<InfoGuidelineStep>
<name>¿Persistencia adenoma?</name>
<id>s12</id>
<DecissionOption>
<Name>persitencia_adenoma_cierto</Name>
<Criterion>
<Name>persitencia_adenoma_cierto</Name>
<GetDataItems>
<Item>persitencia_adenoma</Item>
</GetDataItems>
<Condition>
<Name1>persitencia_adenoma</Name1>
<Name2>true</Name2>
</Condition>
</Criterion>
140
</DecissionOption>
<DecissionOption>
<Name>persitencia_adenoma_falso</Name>
<Criterion>
<Name>persitencia_adenoma_falso</Name>
<GetDataItems>
<Item>persitencia_adenoma</Item>
</GetDataItems>
<Condition>
<Name1>persitencia_adenoma</Name1>
</Condition>
</Criterion>
</DecissionOption>
</DecissionStep>
• S13
<DecissionStep>
<InfoGuidelineStep>
<name>¿carcinoma?</name>
<id>s13</id>
<DecissionOption>
<Name>carcinoma_presente</Name>
<Criterion>
<Name>carcinoma_presente</Name>
<GetDataItems>
141
<Item>carcinoma</Item>
</GetDataItems>
<Condition>
<Name1>carcinoma</Name1>
<Name2>true</Name2>
</Condition>
</Criterion>
</DecissionOption>
<DecissionOption>
<Name>carcinoma_no_presente</Name>
<Criterion>
<Name>calidcarcinoma_no_presente</Name>
<GetDataItems>
<Item>carcinoma</Item>
</GetDataItems>
<Condition>
<Name1>carcinoma</Name1>
</Condition>
</Criterion>
</DecissionOption>
</DecissionStep>
• S14
<ActionStep>
<InfoGuidelineStep>
<id>s14</id>
142
<name>FCS</name>
<description>FCS 3 años</description>
</ActionStep>
• S15
<DecissionStep>
<InfoGuidelineStep>
<name>¿2 FPG con CCR, o 1 FPG CCR mas 60 años?</name>
<id>s15</id>
<DecissionOption>
<Name>2_FPG_cierto</Name>
<Criterion>
<Name>2_FPG_cierto</Name>
<GetDataItems>
<Item>2_FPG</Item>
</GetDataItems>
<Condition>
<Name1>2_FPG</Name1>
<Name2>true</Name2>
</Condition>
</Criterion>
</DecissionOption>
143
<DecissionOption>
<Name>2_FPG_falso</Name>
<Criterion>
<Name>2_FPG_falso</Name>
<GetDataItems>
<Item>2_FPG</Item>
</GetDataItems>
<Condition>
<Name1>2_FPG</Name1>
</Condition>
</Criterion>
</DecissionOption>
</DecissionStep>
• S16
<ActionStep>
<InfoGuidelineStep>
<id>s16</id>
<name>FCS</name>
<description>FCS 1 año</description>
</ActionStep>
144
• S17
<ActionStep>
<InfoGuidelineStep>
<id>s17</id>
<name>FCS</name>
<description>FCS 5 años</description>
</ActionStep>
145
• S18
<ActionStep>
<InfoGuidelineStep>
<id>s18</id>
<name>FCS</name>
<description>FCS 5-10 años</description>
</ActionStep>
• Parte del XML de la guía sin personalizar que describe el título y la fecha de elaboración.
<MaintenanceInfo>
<Title>Algoritmo del Adenoma</Title>
<AuthoringDate>13-08-07</AuthoringDate>
</MaintenanceInfo>
</Guideline>

Integración de Guías Clínicas en Sistemas de Elearning

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Integración de Guías Clínicas en Sistemas de Elearning

Încărcat de

Drepturi de autor:

Formate disponibile

Integración de guías clínicas

JOSÉ LUIS SANTOS ODRIOZOLA

En este proyecto se muestra el desarrollo del proceso en el modelado de guías clínicas, la

2. ESTADO DEL ARTE

2.1 HGML. Hypertext Guideline Markup Language

<relation operador=”equal-to” [value=”value”] [min=”value”]

Fig. 1: Captura de pantalla del markup tool.

Fig. 2: Spatial 2D representation

Fig. 3. Tree view

2.2 GEM (Guideline Elements Model)

El modelo original de GEM ha sido ampliado substancialmente y mejorado. GEM representa un

Fig. 4: Elementos del modelo en alto nivel

Fig. 5: Elementos jerárquicos del elemento knowledge component.

Fig. 6: Modelo GLIF. Principales clases de alto nivel.

Fig. 7. Clasificación de las guías clínicas codificadas en GLIF.

organigrama. A este nivel de abstracción, al autor no le concierne el formalizar detalles

3.1 CASOS DE USO

3.1.1 Caso de uso crear nueva guía

4. Planificación del proyecto

El proyecto se ha dividido en 3 etapas:

5.1 Primera versión de la especificación

• element Guideline: Es nuestro elemento raíz, y consta de tres elementos hijos, el

children Algorithm MaintenanceInfo DataItem

source <xs:element name="Guideline">

Ejemplo del xml que representa la guía de práctica clínica en particular:

<Guideline xmlns:xdb="http://xmlns.oracle.com/xdb" xmlns:xsi="http://www.w3.org/2001/XMLEsquema-instance"

xmlns:xdb="http://xmlns.oracle.com/xdb" ~ Es un dato que expresa que las extensiones del

children ActionStep DecissionStep BranchStep

source <xs:element name="Algorithm">

Ejemplo del xml que representa la guía de práctica clínica en particular:

Este elemento consta del InfoGuidelineStep, que explicaremos a continuación,

children InfoGuidelineStep StrengthOfRecomendation DurationConstraint ActionSpecification

source <xs:element name="ActionStep">

• element InfoGuidelineStep: Este elemento es común en todos los Steps, en el

• element ActionSpecification: Un ActionStep, puede contener varios

children name description intention

source <xs:element name="ActionSpecification">

Ejemplo del xml que representa la guía de práctica clínica en particular:

<description>SOH anual o biennal</description>

• element BranchStep: Se da en el caso de que varios caminos se han de seguir,

Consta, básicamente, del elemento InfoGuidelineStep, ya definido y explicado

children InfoGuidelineStep ActionStep BranchStep DecissionStep

source <xs:element name="BranchStep">

Ejemplo del xml que representa la guía de práctica clínica en particular:

• element DecissionStep: El DecissionStep, lo utilizamos para el típico caso de decisión.

Consta del ya explicado InfoGuidelineStep, del AutomaticDecission, que es un bolean

children InfoGuidelineStep AutomaticDecission DecissionOption

source <xs:element name="DecissionStep">

• element DecissionOption: Este elemento representa una de las decisiones posibles,

children Name DisplayName Criterion ActionStep DecissionStep BranchStep

source <xs:element name="DecissionOption">

• element Criterion: Como su nombre indica, establece el criterio de decisión, es decir,

children Name GetDataItems Condition

source <xs:element name="Criterion">

<xs:element name="Item" type="xs:string" maxOccurs="unbounded"/>

• element Criterion/GetDataItems: Establece las variables que hemos de conseguir del

• element Condition: Este elemento establece la condición, habitualmente, Name1,

children Name1 Operator Name2

source <xs:element name="Condition">

<Name>Sospecha CCR cierto </Name>

children Name Value Concept ConceptSource

source <xs:element name="DataItem">

• element DataItem/Concept: Solo se usará en caso de utilizar, por ejemplo, UMLS.