Dise

no e implementaci
on de un repositorio de arquetipos
openEHR-OWL

Trabajo realizado por Fernando Sanchez Duran

Dirigido por Dr. Jose Francisco Aldana Montes

Universidad de M alaga
M
aster en ingeniera del software e inteligencia artificial

Resumen Es interesante trasladar los arquetipos de openEHR a OWL para poder aplicar herramientas
de una tecnologa moderna y en constante evolucion a sistemas de informaci
on medicos que progresan
a un ritmo m as moderado debido a la complejidad de los mismos. En la actualidad existen ontologas
medicas expresadas en OWL que aline andolas con los arquetipos de openEHR pueden mediante razo-
nadores inferir conocimiento, en este trabajo se desarrolla un sistema que realiza una traduccion de
arquetipos openEHR a OWL y se proponen algunas aplicaciones de gran utilidad en el a mbito medico
y cientfico.

1. Introducci
on

Los profesionales de la salud necesitan acceder a toda la informaci

on clnica de sus pacientes para poder
desarrollar su labor, lo que se denomina historial, si dicha informaci on esta soportada en un sistema
informatico entonces podemos hablar de Historia Clnica Electr onica (HCE). Un sistema sanitario efi-
ciente y de calidad requiere de una HCE como elemento integrador de los datos clnicos y fuente de
informacion para los profesionales de la salud. Podemos decir hoy da que, es un elemento esencial
en un entorno sanitario. Acceder a todos los datos de un paciente de forma centralizada y actuali-
zados con la ultima informacion obtenida, es un objetivo estrategico en el ambito de la salud desde el
punto de vista: Asistencial, de la gesti
on y de la investigaci
on.

Hoy en da nadie en el mundo de la sanidad, duda ya de la prioridad de dirigirse hacia una HCE en
la que esten informatizados e integrados los documentos que contienen: Observaciones, evaluaciones e
informacion de cualquier tipo concerniente a la situaci
on y a la evoluci
on clnica de un paciente a lo
largo del proceso asistencial.

Los beneficios de usar una HCE son claros. Seg un un informe de la SEIS (Sociedad Espa nola de In-
formatica de la Salud), los historiales clnicos tradicionales presentan dificultades como son: El desorden
y la falta de uniformidad en los documentos, la inclusi on de informaci
on muchas veces ilegible, se pro-
ducen errores en su archivado, no se garantiza la confidencialidad, deterioro del soporte documental y
dificultad para separar los datos demogr aficos de los clnicos. [17]

Una HCE debe tener una estructura que pueda ser procesada por un sistema inform atico. La estructura
debe ser adecuada tanto para un ambiente de atenci on sanitaria como para otros usos como: Inves-
tigaci
on, formaci
on, estadsticas. Es por ello que el aspecto m as importante a la hora de desarrollar
sistemas de HCE, es la organizaci on de la informaci
on clnica.

Una arquitectura de historia clnica electr onica debe modelar las caractersticas genericas aplicables a
cualquier historial clnico posible (existente y futuro), en la actualidad se presentan algunos est andares
que pretenden cumplir este cometido. Los procesos de estandarizaci on han cobrado mayor importan-
cia y se est
an volviendo m as complejos con la globalizaci on de la economa y la liberalizaci
on de los
mercados. Los productos se tienen que dise nar para ser aceptados por usuarios de m ultiples pases, con
diferentes lenguas, distintos sistemas de valores y distintas condiciones de trabajo.
2. Interoperabilidad en los sistemas de salud
La interoperabilidad es la capacidad de los sistemas de informaci
on de compartir datos y posibilitar el
intercambio de informacion entre ellos.

Las instituciones sanitarias tienen el objetivo de adoptar sistemas de informaci on que permitan una
gesti
on eficiente y centrada en los ciudadanos, para lograr esta eficiencia uno de los objetivos es la
interoperabilidad. Una interoperabilidad que posibilite la comunicaci on transversal y longitudinal a lo
largo de todas las estructuras de los servicios de salud, garantizando la confidencialidad y la integridad
de la informacion compartida.

Para conseguir sistemas interoperables es necesario adoptar estandares. En las instituciones sanitarias
existen m
ultiples sistemas de informacion y la informaci
on residente en cada uno de ellos es de vital
importancia para una atenci on medica en todos los niveles de la organizaci
on. Por otra parte, es fre-
cuente que la informacion este fragmentada en diversos sistemas independientes, formando islas que
provocan un acceso parcial a los datos necesarios para tomar decisiones [14].

En la mayora de los pases conviven medicina p

ublica y privada con distintas modalidades de asistencia,
adem as tenemos en el caso de Espa na que la sanidad esta transferida a las comunidades aut onomas,
con lo cual nos encontramos con 17 instituciones sanitarias p ublicas cada una con su propio sistema
de informacion y todo eso unido a un gran n umero de centros concertados. Este escenario nos conduce
a una situacion en la que cada instituci on sanitaria, aseguradora, hospital concertado, universidad y
demas actores del sistema de salud, es una isla de informaci on en s misma, donde el intercambio de
datos con los dem as actores es la excepci
on. Con este panorama es difcil coordinar polticas y ejecutar
proyectos concretos en conjunto para buscar la mejora global en la calidad de la salud. Los gobiernos
tienen una visi
on parcial de lo que sucede en las instituciones, no pudiendo evaluar de forma o ptima la
ejecuci
on de proyectos ni el impacto de los mismos, dificultando el planeamiento de nuevas polticas en
salud y la toma de decisiones a nivel estatal.

La interoperabilidad no es solamente la habilidad de intercambiar informaci on sanitaria, tambien requie-

re la habilidad de entender lo que se ha intercambiado. Los est andares son la base de la interoperabilidad
y sin ellos no es posible construir sistemas interoperables. Los est andares centrados en la comunicaci on
proveen estructuras de datos que est an compuestos por tipos, formatos, codificaci on, campos y proveen
tambien alguna sintaxis para representar esas estructuras en un formato comunicable va inform atica,
este nivel mnimo es necesario para que la informaci on pueda ser enviada y recibida pero no garantiza
la interpretacion efectiva de la informaci on comunicada, a este tipo de interoperabilidad se la deno-
mina interoperabilidad sint actica, un concepto importante es que sin interoperabilidad sint actica no
es posible implementar ning un otro tipo de interoperabilidad. Una vez que se logra interoperabilidad
sint
actica entre dos o m as sistemas es posible avanzar un paso m as para lograr la correcta interpretacion
y el uso efectivo de la informaci on intercambiada, a esta caracterstica se la denomina interoperabilidad
sem antica y en un proceso de estandarizaci on es el objetivo final.

La interoperabilidad sem antica permite que los sistemas sean capaces de aplicar reglas l ogicas para
as realizar deducciones que permitan el intercambio de informaci on. La interoperabilidad entre sis-
temas de salud la podemos clasificar en dos niveles, donde el primero es el de la interoperabilidad
sem antica para la visualizacion de la informacion y el segundo es el de la interoperabilidad sem antica
para el procesamiento. La visualizaci on de informacion es una de las necesidades m as comunes en los
sistemas de informaci on en salud, es frecuente que la informaci on registrada en un sistema inform atico
deba ser visualizada en otro sistema distinto, por ejemplo: Un laboratorio genera el resultado de un
an alisis y este debe ser visualizado o enviado a otro sistema para su evaluaci on, si a un medico se le
presenta en pantalla el valor (13, 8) el dato es difcil de interpretar, en cambio si el sistema es capaz
de presentar los datos en un contextopresi on arterial, presi
on sist
olica, presi
on diastolica, unidad de
medida, precisi on, aparato de medida, posici on del paciente en el momento de la medida, etc.... Sin
duda la informaci on puede ser interpretada de manera m as precisa.

Por otro lado, tenemos la interoperabilidad sem antica para el procesamiento automatico de la infor-
maci
on, es uno de los principios b
asicos de la informatica y uno de los procesos que da mayor valor

2
a los sistemas de salud, algunos ejemplos son: Evaluaci on de la calidad, correcci
on y completitud de
la informacion, listas de espera, fuentes bibliogr
aficas relacionadas y evidencia, an
alisis para encontrar
nueva informaci on a partir de los datos disponibles, soporte a la toma de decisiones, alarmas, tenden-
cias, predicci
on probabilista, etc...

Al igual que en Internet, donde se almacenan muchos datos, se necesitan est andares como los que
propone la web sem antica, los sistemas de informaci on de salud necesitan est andares que le den a la
informaci
on un significado para que esta sea tratada de forma autom atica. En el caso planteado de la
comunicacion de la medida de la presion arterial, suponiendo que dos sistemas usan diferentes unidades
de medida, mediante la interoperabilidad sem antica se puede verificar que se empleen unidades que
miden la misma propiedad fsica (presion) y cuando las unidades cambien, tambien lo har an los valores
de la medida de forma autom atica. Si dos sistemas cumplen los mismos est andares que permiten la
interoperabilidad semantica, un sistema podra consultar al otro los datos de los pacientes, aunque estos
se hayan registrado de forma diferente.

La realidad impone que sea necesario compartir informacion a todo nivel con el objeto de garantizar la
calidad de la asistencia de los ciudadanos, es recomendable tener polticas nacionales e internacionales
que definan el marco de interoperabilidad en el que se debe trabajar. Pensar en interoperabilidad es
fundamental en la planificacion de un sistema de informaci
on sanitario.

3. Estado actual de la HCE

Existen diferentes organizaciones reconocidas en el ambito internacional que dedican parte de su acti-
vidad a tareas de normalizacion en informatica medica y sistemas de HCE como son la ISO que es una
organizacion de a
mbito mundial en la que opera el comite tecnico ISO TC215. En Europa la autoridad
es CEN (Comite Europeo de Normalizaci on) en el que participan organismos nacionales como es el
caso de AENOR en Espa na. ANSI (American Nacional Standard Institute) es el organismo oficial de
EEUU que gestiona las actividades nacionales de normalizaci on en inform
atica para la salud mediante
el HISPP (Healthcare Informatics Standard Planning Panel), este comite canaliza la participaci on de
los grupos de normalizacion de varias organizaciones independientes como son HL7, DICOM [1], IEEE
y SNOMED . Tambien hay otros organismos internacionales como el comite IT 14 de Est andares Aus-
traliano, o el MEDIS-DC del MITI en Jap on. En el campo de la normalizaci on, no podemos pasar por
alto el trabajo de otras organizaciones que realizan un gran esfuerzo en el desarrollo de estandares de
HCE, entre ellas cabe destacar OpenEHR Foundation, Open Source Health Care Alliance, EUROREC-
European Health Records Institute y los Centros Nacionales PROREC en Europa.

Las actividades de estandarizaci on en inform atica de la salud en Europa se remonta a 1990 cuando
se establece el comite tecnico CEN TC251, el campo de competencias de comite es la Inform atica y
Telematica para la Salud, su a mbito de actuaci on incluye la organizaci
on, coordinaci
on y seguimiento
del desarrollo de los est
andares. Actualmente el CEN TC251 lo conforman cuatro grupos de trabajo y
cada uno de ellos desempe na las siguientes tareas:

Modelos de informaci on
Terminologa y bases de conocimiento
Protecci
on, seguridad y calidad
Tecnologa para la interoperabilidad

Las tareas de estandarizaci on de la historia clnica electr

onica, tanto la arquitectura como los modelos
de informaci on, se desarrollan dentro del grupo Modelos de informaci on. En 1995, CEN public o el
est
andar ENV 12265 Arquitectura de historia clnica electr onica, que fue un est andar de
referencia historica definiendo los principios b asicos en los que se deben basar las historias clnicas
electr
onicas.

3
3.1. CEN/ISO 13606
Actualmente el estandar mas importante en Europa en el ambito de la inform atica medica es el
CEN/ISO 13606, la primera versi on fue publicada en 1999 pero esta primera implementaci on fue
muy compleja y en 2002 la CEN revis o el proyecto y tomo la determinaci
on de actualizarlo completa-
mente, el aspecto mas importante de la revisi
on fue la decisi
on de adoptar el enfoque de modelado
dual de openEHR conocido como metodologa de arquetipos y tambien la de incorporar parte del
modelo de referencia de openEHR.

Es importante destacar que en principio la especificaci on de CEN/ISO 13606 esta destinada al inter-
cambio de registros medicos electr
onicos y no para especificar un sistema completo de EHR, para que
sea un sistema completo necesita tener m as caractersticas de las que especifica el est
andar como son:
Control de versiones, control de flujos e interfaces con otros sistemas.

En resumen CEN/ISO 13606 de momento para lo u nico que sirve es para mover piezas de EHR entre
distintos sistemas, estara al nivel de HL7 RIM que sera su hom
ologo americano para el intercambio
de datos clnicos.

Figura 1. Fragmento de un arquetipo

El CEN/ISO 13606 se compone de las siguientes partes [2]:

Parte 1: Modelo de Referencia: Un modelo de informaci

on generico para modelar la historia clnica
electr
onica de cualquier paciente.

Parte 2: Especificaci
on de intercambio de arquetipos: Un modelo de informaci on generico y un
lenguaje para representar y comunicar la definici
on de instancias individuales de arquetipos.

4
 Parte 3: Arquetipos de referencia y listas de terminos: Un rango de arquetipos reflejando una di-
versidad de requisitos clnicos y condiciones, como un conjunto de arranque para ilustrar c
omo
otros dominios clnicos podran representarse de forma similar.

Parte 4: Caractersticas de seguridad: Define los conceptos del modelo de informaci

on que se necesi-
tan reflejar dentro de instancias de HCE individuales para permitir una interacci on apropiada con
los componentes de seguridad que pudieran ser requeridos en cualquier implantaci on futura de HCE.

Parte 5: Modelos de Intercambio: contiene un conjunto de modelos que se construyen sobre las
partes anteriores de la norma y pueden formar el soporte de comunicaciones basadas en mensajes
o en servicios.

3.2. HL7 [5]

HL7 Health Level Seven es un conjunto de est andares destinado a facilitar el intercambio electr
onico
de informacion clnica. Tiene origen en 1987, este est
andar est
a destinado al intercambio de datos entre
aplicaciones, sin embargo, la creciente necesidad de generar sistemas de informaci on integrados regio-
nalmente hizo necesario el desarrollo de extensiones del est andar para facilitar la interoperabilidad,
por ese motivo desde el a no 2000 la organizacion HL7 cuenta con un proceso para definir una serie
de herramientas de interoperabilidad. HL7 se encuentra entre las organizaciones m as importantes de
informatica medica a nivel internacional, la especificaci
on mas utilizada es un estandar de mensajera
para el intercambio electr onico de datos en salud HL7 RIM.

HL7 es la sigla de Health Level Seven Inc la palabra Health hace referencia al a mbito de tra-
bajo de la organizaci on y las palabras Level Seven hacen referencia al u ltimo nivel del modelo de
comunicaciones para interconexi on de sistemas abiertos OSI. El Nivel Siete dentro del modelo es el ni-
vel de aplicaci
on, que se ocupa de la definici
on y la estructura de los datos que van a ser intercambiados.

Algunos est
andares desarrollados en HL7 son:

Mensajera HL7 Versi

on 2 (obsoleta): Est
andar de mensajera para el intercambio electr
onico de
datos de salud.

Mensajera HL7 Versi on 3: Est

andar de mensajera para el intercambio electr
onico de datos de
salud basada en el RIM Reference Information Model, destacar que se abandona el modelo de
la versi
on 2 y se adopta otro m
as en lnea con el de openEHR. En 1994 fue acreditada como SDO
(Standards Developing Organization) por la ANSI.

CDA HL7: (Clinical Document Architecture) Est

andar de arquitectura de documentos clnicos
electr
onicos.

SPL HL7: (Structured Product Labeling) Est

andar electr
onico de etiquetado de medicamentos.

HL7 Medical Records: Est

andar de administraci
on de Registros Medicos.

GELLO: Est
andar para la expresi
on de reglas de soporte de decisiones clnicas.

Arden Sintax: Es est

andar sint
actico (if then) para compartir reglas de conocimiento clnico.

3.3. OpenEHR [8]

OpenEHR es una especificacion abierta destinada a la gesti
on de registros de salud, describe la admi-
nistraci
on y almacenamiento de informaci
on sanitaria mediante informes de historia clnica electr
onica

5
HCE .

OpenEHR est a basado en m

as de 15 a
nos de investigaci
on bajo la experiencia de un entorno real. En
los u
ltimos a
nos openEHR ha tenido gran influencia en el desarrollo de est
andares EHR, el m
as notable
es el CEN/ISO EN13606 recoge un subconjunto importante de la especificaci on openEHR.

Las especificaciones de openEHR son mantenidas por una fundaci on sin a

nimo de lucro que se encarga
de su desarrollo, investigaci
on e implementaci
on de herramientas para las gesti
on de todos los elementos
relacionados con el especificacion de openEHR.

Figura 2. Analoga entre el modelo de openEHR y Lego [11]

Los orgenes de openEHR comienzan en enero del 1992 cuando arranca en Londres un proyecto llamado
GEHR (Good European Health Record) que diriga un grupo de trabajo compuesto por personas de la
universidad, la empresa y sanitarios con el objetivo de crear un est andar EHR, el proyecto esta finan-
ciado por la UE. Participan varios pases Inglaterra, Belgica, Portugal y Francia. En 1994 se acaba la
financiaci
on y todos los trabajos a
un incompletos no arrojan ning un resultado concluyente.

Cuando en 1994 se acaba el proyecto, Thomas Beale, uno de los participantes del proyecto GEHR, se
vuelve a Australia pero con una idea muy clara de cuales eran los principales problemas que enfrentaban
a tecnicos y profesionales de la salud y durante unos a
nos no para de darle vueltas a este tema, finalmente
en 1997 cre o junto a un colega un modelo de informaci on y un conjunto de restricciones que dio origen
a lo que conocemos como arquetipo de openEHR. En 1998 creo la fundaci on openEHR y una empresa
llamada Oceans Informatics y los siguientes a nos los dedic
o a definir junto con otros colaboradores
las especificaciones de openEHR.

4. Descripci
on de openEHR
OpenEHR define un modelo de referencia para la representaci on de la informaci
on clnica as como un
modelo de arquetipos encargado de representar conceptos clnicos de mayor nivel sem antico.

6
 Figura 3. Componentes de openEHR [8]

En el modelo de referencia se incluyen todas las clases necesarias para representar cualquier tipo de
informaci
on clnica incluyendo informacion de contexto relativa a esos datos, como puede ser el medico
responsable (participantes), las fechas de realizaci
on de las pruebas, protocolo o el lugar del acto clnico.
Es un modelo simple y flexible adaptable a cualquier estructura de informaci on sanitaria.

En cuanto al modelo de arquetipos, permite definir de manera formal conceptos clnicos de mayor
nivel sem
antico, como puede ser un informe de alta, una prueba de laboratorio o la administraci on de
sustancias y para ello se basa en las clases del modelo de referencia, restringiendolas a unos valores o
estructuras de datos precisas.

Todos los nodos representados en el arquetipo pueden enlazarse con terminologas clnicas que doten a
la definici
on del arquetipo de un significado preciso que asegure su interoperabilidad sem
antica.

OpenEHR dispone de una herramienta para la gesti on del conocimiento clnico, con esta herramien-
ta se puede compartir conocimiento (arquetipos) y controlar su cliclo de vida, as como abrir nuevos
proyectos donde colaboren distintas personas en la creaci
on y gestion del conocimiento clnico, esta
herramienta es propiedad de Ocean informatics [7] y es de pago.

OpenEHR tiene como caracterstica que el conocimiento representado mediante los arquetipos puede
ser traducido a cualquier idioma, para ello dispone de una ontologa propia multilenguaje que a su vez
se puede alinear con cualquier otra ontologa medica externa.

4.1. Modelo dual

El concepto de separar la informacion del conocimiento es lo que en openEHR se llama modelo dual,
este enfoque viene a justificar en un entorno sanitario que un medico sabe organizar y gestionar la
informaci
on que maneja y un ingeniero en inform atica sabe como automatizar procesos, recoger la in-
formaci
on con una interfaz agradable y almacenar grandes vol umenes de datos.

Uno de los autores de openEHR Thomas Beale, durante su trabajo en el grupo GEHR observaba
reiteradamente que en los procesos de definici on e implementaci on de los sistemas informaticos para
la gestion de registros medicos, se producan discrepancias entre medicos e ingenieros y no haba una
lnea divisoria clara entre el trabajo de cada uno y por ese motivo, Thomas quiso buscar la forma de
independizar ambos procesos: Por un lado la definici on del conocimiento y por otro el procesado de

7
dicho conocimiento en un sistema inform
atico. A esta separaci
on la llam
o modelo dual.

Tenemos que considerar que la complejidad de la informaci on sanitaria, su heterogeneidad en cuanto

a los tipos de datos representados y la continua variabilidad del conocimiento medico, hace que los
sistemas de informaci
on se suelan quedar obsoletos y sean difciles de mantener.

El modelo dual tiene como base fundamental separar la informaci on del conocimiento teniendo en
cuenta que, la informaci on son aquellos datos que una vez almacenados en el sistema no varan con
el tiempo, en el contexto sanitario corresponde a los datos introducidos respecto a la salud de un
paciente, un ejemplo sera la medida de la presi on sangunea de un paciente 130/80 mm[Hg] en una
fecha concreta. En cuanto al conocimiento, se refiere al conjunto de conceptos de un determinado
dominio profesional, conceptos que pueden variar o modificarse con el paso del tiempo y cuyo significado
completo solo conocen los profesionales expertos en ese campo, en lnea con el ejemplo anterior, se puede
considerar como conocimiento el concepto presi on sangunea que est a compuesta de presion sistolica
(medida de presi on cuando el coraz on se encuentra contrado), presion diastolica (medida de presi on
cuando el corazon est
a relajado), unidad de medida mm[Hg]. Este conocimiento medico en un momento
dado, puede llegar a variar por razones estrictamente medicas, como por ejemplo: Recoger la media de
pulsaciones del corazon durante la medida, o medir la temperatura corporal, por que a posteriori se
determina que son importantes a la hora de medir la presi on arterial. Por este motivo podemos decir
que los datos no varan pero el conocimiento si.

Figura 4. Composici
on de arquetipos [11]

En la figura 4 podemos observar como el conocimiento medico de un examen ginecol

ogico est
a com-
puesto por varios arquetipos de openEHR, este conocimiento puede variar cambiando los arquetipos
que lo componen o versionando los ya existentes.

Con esta separaci

on entre informaci
on y conocimiento, un EHR basado en el modelo dual es capaz de
evolucionar y adaptarse a los cambios producidos en las definiciones de los conceptos clnicos.

8
 Figura 5. Partes de un arquetipo [8]

4.2. Arquetipos y lenguaje ADL

Archetype Definition Language (ADL) es un lenguaje formal destinado a expresar arquetipos, est a ba-
sado en un modelo de restricciones sobre entidades/elementos de un dominio. Archetype Object Model
es un modelo de objetos que define la sem antica de un arquetipo, la sintaxis ADL sera una posible
serializaci
on de un arquetipo.
ADL utiliza dos sintaxis bien definidas: El formato de definicion de restricciones (cADL) y el formato
de definicion de datos (dADL). La sintaxis cADL se utiliza para expresar el apartado de definiciones
del arquetipo y la sintaxis dADL para las secciones que necesitan asignar valores finales y tambien
para crear instancias de los arquetipos con datos concretos. Con cADL se expresa una estructura de
restricciones que define el formato de los datos que va a contener el arquetipo, es decir, define el registro
medico. Con dADL se informan los datos fijos del arquetipo, como son, el nombre, autor, significado
de los terminos en lenguaje natural, mapeo de ontologas, idiomas soportados, etc...

Para describir mediante ADL cualquier concepto clnico es necesario un modelo de informaci on muy
generico, por ejemplo: Los conceptos paciente, doctor, enfermero se definen mediante la clase PARTY
(individuo), para el concepto hospital y direccion del paciente, la clase ADDRESS y los arquetipos son
usados para restringir sobre las instancias de estas clases genericas las estructuras v
alidas que represen-
tan dicho concepto. De esta forma teniendo un conjunto de clases muy generico y usando el lenguaje
ADL se puede definir cualquier concepto clnico presente y futuro, mirar figura 2 y 6.

Los arquetipos usan un lenguaje neutral y disponen de estructuras para marcar mediante una termi-
nologa propia los elementos que lo componen, esta terminologa se expresa en lenguaje natural y se
traduce a cuantos idiomas sea necesario, adem as los arquetipos disponen de estructuras para conectar
la terminologas propias con otras externas como ICD-10, SNOMED-CT [6], etc...

9
Figura 6. Analoga entre el modelo de referencia y los arquetipos [10]

10
Un arquetipo tiene tres partes principales: Cabecera, definiciones y ontologa. mirar figura 5:

La cabecera est
a compuesta por varias secciones:

Secci
on arquetipo, donde se recoge la versi
on del lenguaje y un identificador u
nico dentro de su
CKM, mirar figura 1.

Seccion especializaci
on, indica el nombre del arquetipo que se va a especializar, cuando se es-
pecializa un arquetipo se crean nuevas restricciones teniendo como base el arquetipo padre. Por
ejemplo: openEHR-EHR-OBSERVATION.lab-test-blood-glucose.v1 especializa a openEHR-EHR-
OBSERVATION.lab-test.v1, mirar figura 7.

Seccion concepto, mediante un codigo describe que concepto clnico del mundo real representa.
Este c
odigo se describe mediante lenguaje natural en los distintos idiomas que recoge el arquetipo,
a su vez se puede alinear con una terminologa externa.

La parte de definici
on contiene la definici
on formal del arquetipo escrita en cADL. Est a compuesta
por una serie de restricciones en forma de a rbol, creadas a partir del modelo de referencia.

La secci
on ontologa se expresa en dADL y la podemos dividir a su vez en varias secciones:

Una cabecera donde se especifica el idioma principal del arquetipo y los idiomas a los que se ha
traducido, en esta parte tambien se especifica las terminologas que se van a usar.

Secci
on de definicion de terminos donde se escriben los terminos locales del arquetipo, en esta
secci
on los terminos tienen el formato [atNNNN].

Seccion de definicion de restricciones con el mismo formato que la anterior, proporciona las
definiciones, que son de la forma [acNNNN]. Las definiciones de restricci on no proporcionan las
restricciones propiamente dichas sino que definen el significado de tales restricciones de una mane-
ra comprensible para el humano, normalmente se codifican en los nodos finales cuando se quiere
describir el significado de un valor concreto.

Seccion de bindings en la que se describen las equivalencias entre terminos locales del arquetipo
y terminos de una ontologa externa.

ADL no es un lenguaje definido exclusivamente para el a mbito clnico, puede usarse para definir cual-
quier tipo de arquetipo, es muy flexible ya que la misma estructura puede utilizarse para especificar
arquetipos basados en distintos modelos de referencia, por tanto, ADL aporta una estructura sint actica
y el modelo de referencia aporta un estructura semantica.

Un arquetipo ADL es necesario que sea definido para un modelo de informaci on en particular, sien-
do posible definir arquetipos basados en diferentes modelos de referencia, ISO13606, OpenEHR, etc.
Por otro lado, un parser para ADL no sabe nada acerca del modelo de referencia en el que se basa,
cuando se parsea un fichero ADL el mismo devuelve una colecci on de objetos siguiendo un modelo
abstracto de objetos de arquetipos (AOM. Archetype Object Model). Es un lenguaje generico, por lo
que, no presenta ninguna garanta sobre la consistencia de la informaci on clnica que representa, tan
s
olo ofrece consistencia a nivel de arquetipos. Las herramientas de openEHR que se usan para crear
arquetipos, chequean la consistencia del arquetipo en base al modelo de referencia definido en openEHR.

Con el objetivo de realizar el procesamiento sem antico de un arquetipo descrito en ADL el documento
debe identificar el modelo de referencia en el que se basa dicho arquetipo, esto se realiza en la parte de
identificaci
on de la cabecera. El modelo de referencia especifica las clases, los conceptos y relaciones.
Para chequear todo esto, es necesario un programa especfico que entienda un modelo de referencia
concreto, que realice las validaciones para que el arquetipo sea correcto conforme a dicho modelo de
referencia, en el caso de openEHR las propias herramientas suministradas por la fundaci on realizan
estas validaciones.

11
 Figura 7. Especializaci
on de arquetipos [11]

4.3. Modelo de referencia de openEHR

El modelo de referencia define el conjunto de entidades que forman los bloques de construcci
on generi-
cos de la HCE.

El modelo de referencia de openEHR esta representado por un diagrama UML con una gran cantidad
de clases y relaciones, en este trabajo voy a simplificar para que sea facil comprender el modelo sin
entrar a analizar todas las clases que lo componen, observar figuras 8 , 9 y 10.

Clases m
as importantes dentro del modelo de referencia:

EHR .- La Historia Clnica Electr

onica, define el conjunto de documentos relacionados con la historia
clnica de una persona.

FOLDER .- Clasifica los historiales por e specialidades, episodios, servicios, etc.. es una forma de agru-
par la informaci
on.

COMPOSITION .- Es el documento clnico mnimo que se produce en un sistema y que debe firmar el
medico, es el equivalente a un informe, receta, diagn
ostico, tratamiento, que se produce en un sistema
de HCE.

SECTION.- Dentro de un COMPOSITION se establecen secciones, que son encabezados que dividen
el documento en distintas partes, evaluaci
on, diagn
ostico, tratamiento.

ENTRY .- La clase entry es el primer nivel que se usa para definir un concepto clnico. Las entradas
pueden ser de tipo administrativa o clnica. Cuando se define un arquetipo nunca se usa directamente,
lo que se usan son las clases que heredan de esta y que son: observaciones, evaluaciones, acciones e
instrucciones. M
as adelante se describen con m as detalle pues son las clases m
as importantes a la hora
definir un concepto clnico.

12
 Figura 8. Resumen modelo de referencia [8]

CLUSTER .- Se usa para agrupan elementos, por ejemplo la presi

on sangunea se agrupo en un cluster
donde est
an la sist
olica y diast
olica.

ELEMENT .- Representan los nodos finales y son los que contienen los datos concretos de una medida,
resultado, estado, conclusi
on, etc...

Entre todas las clases del modelo de referencia se pueden destacar las que se van a describir a conti-
nuaci
on, todas pertenecen la clase ENTRY y en s mismas definen conceptos clnicos de alto nivel:

OBSERVATION.- Es una clase que representa la observaci on de un hecho concreto, como puede ser la
talla, el peso, presi
on sangunea, indice de masa corporal, color de la piel, etc... Un observaci
on siempre
tiene como hijas una clase de tipo HISTORY de la cuelgan elementos de tipo EVENT.

EVALUATION.- Se usa para registrar el estado de salud del paciente, en base a las observaciones. Es
cuando el medico describe en que estado se encuentra el paciente.

ACTION.- Se usa para realizar acciones concretas sobre un paciente, por ejemplo: ordenar una trans-
fusi
on sangunea, la administraci
on de un medicamento, ordenar una ciruga, etc... de esta clase cuelga
obligatoriamente un elemento de tipo ISM-TRANSITION donde se registra la secuencia de acciones
realizadas para llevar a cabo la acci
on en openEHR se llama Careflow.

INSTRUCTION.- Conjunto de instrucciones que se deben llevar a cabo sobre un paciente, una ins-
trucci
on est
a compuesta de una o m as actividades (ACTIVITIES). Un ejemplo sera si un paciente
est
a ingresado y el medico quiere realizar unas pruebas la instrucci
on sera:

Actividad 1 - Solicitar an
alisis de sangre.

actividad 2 - Solicitar un esc

aner de una parte del cuerpo.

13
 Figura 9. Resumen jerarqua de clases del RM [8]

actividad 3 - medir presi

on sangunea y la temperatura.

Un enfermero con estas instrucciones procedera a realizar las acciones necesarias para llevar a cabo la
petici
on.

Figura 10. Clases que intervienen en la definici

on de un concepto clnico [8]

4.4. Herramientas
Una vez que se han repasado los conceptos b
asicos de openEHR lo mejor es inspeccionar las herramien-
tas disponibles en www.openehr.org para afianzar estos conceptos. En primer lugar se puede acceder a
la CKM http://www.openehr.org/ckm/ para revisar algunos de los arquetipos que la fundaci on ha
confeccionado. Podemos observar las partes que tiene y la forma en que se estructura, de este modo
nos familiarizamos con el lenguaje ADL, una vez hecho esto, podemos descargar una par de herramien-
tas que est
an colgadas en la propia web de la fundacion: ADL WorkBench, Archetype editor y crear

14
arquetipos para hacer pruebas.

ADL WorkBench es una herramienta para crear, modificar y validar arquetipos de forma gr afica, esta
herramienta es muy u til en la fase de aprendizaje del lenguaje ADL. Como comentamos anteriormen-
te el parser ADL no valida que un arquetipo sea sem anticamente correcto ya que se trata de parser
generico y solo valida la sintaxis del lenguaje, para validar la semantica usamos las herramientas de
edici
on de arquetipos.

Archetype editor es una herramienta de m as alto nivel que se puede conectar con una CKM para ex-
traer arquetipos y modificarlos. Tiene iconos que representan las distintas estructuras del arquetipo y
de manera visual se puede crear y modificar arquetipos. Estos editores te van guiando a la hora de
construir un nuevo arquetipo y va mostrando cuales son las estructuras v alidas para cada nivel.

Template editor; es una herramienta muy parecida al editor de arquetipos pero destinada a crear y
modificar plantillas. Las plantillas de openEHR no las hemos tratado en este trabajo, b asicamente
son estructuras que agrupan arquetipos con el fin de crear interfaces gr
aficas para la adquisici
on y
visualizaci
on de informaci
on.

4.5. CKM (Clinical Knowledge Manager)

Un aspecto importante en openEHR es gestionar el conocimiento clnico mediante arquetipos y es por
eso que la fundacion ha colgado en la web una herramienta para gestionarlo, se llama CKM. Esta
herramienta online tiene varias funciones: La m
as importante de todas, en mi opinion, es la de tener
un repositorio centralizado de arquetipos donde un pas o una comunidad de pases tengan una gua
est
andar y normalizada de como debe ser registrada la informaci
on en cada una de las a
reas que con-
forman un sistema sanitario.

La CKM es una herramienta propietaria que comercializa y mantiene la empresa Ocean Informatics,
esta herramienta es clave en un sistema basado en openEHR, aunque tambien es posible montar un
repositorio propio fuera de esta herramienta es muy recomendable hacer uso de ella, adem
as tambien
se cuenta con el soporte de la empresa la cual tiene experiencia con openEHR.

Algunas CKM que podemos consultar son:

http://www.openehr.org/ckm/

http://dcm.nehta.org.au/ckm/

http://www.clinicalmodels.org.uk/ckm/

Otra de las funciones que tiene la CKM, es la de gestionar el ciclo de vida de un arquetipo, donde
un comite de expertos en salud elabora, debate y aprueba las versiones de cada arquetipo y todo este
trabajo lo hacen los expertos en el campo de la salud.

El exito de openEHR es precisamente la autonoma que da a los profesionales de la salud, al final ellos
son los que tienen las competencias y la responsabilidad sobre el paciente y en cierto modo les molesta
tener que discutir con un ingeniero si un campo se introduce o no en una tabla de una base de datos,
por otro lado, los tiempos de dise
no, desarrollo y puesta en produccion se acortan considerablemente,
desde que el comite acepta la versi
on del arquetipo como valido, este se puede cargar en el sistema y
ya esta operativo.

El sistema inform atico que explota los arquetipos debe como mnimo ser capaz de: Dado un conjunto
de arquetipos presentar en pantalla los formularios necesarios para registrar la informaci on requerida
en ellos. Este trabajo se centra en el estudio de los arquetipos pero en la especificaci
on se tratan otros
elementos para realizar una gestion completa de un sistema hospitalario, donde se combinan arquetipos,
templates, folders y una serie de elementos que unidos, orquestan la atenci on sanitaria de un paciente

15
durante toda su vida.

Hay que resaltar que con openEHR y con los est andares basados en el, la oferta de software crecer
a de
manera importante, ahora mismo un centro de salud est a atado literalmente al sistema de informacion
y al proveedor del mismo ya que migrar a otro sistema supone un esfuerzo muy grande, con openEHR
migrar de un sistema a otro en teora es inmediato, esto supondra una mayor oferta de software clnico
en el mercado y una mayor competencia mejorando as la calidad y el precio de los productos.

4.6. Introducci
on a la web sem
antica [9]
La Web Sem antica es una extensi
on de la web que tiene como objetivo automatizar el tratamiento de los
documentos y la recuperaci on de la informaci
on, proporcionando a los datos un significado bien definido
que permite a los ordenadores y a las personas trabajar en cooperaci on. El significado de los recursos
web es establecido mediante metadatos formales, definidos gracias a nuevos est andares y tecnologas,
que seran gestionados por agentes software para descubrir e integrar la informaci
on. La iniciativa de la
Web Sem antica est
a coordinada por el consorcio W3C, que es una organizaci on internacional dedicada
a la creaci
on y difusi
on de est
andares y guas para la web.

La propuesta de la Web Sem antica est

a ganando aceptaci on conforme se est an publicando las especifi-
caciones y se dispone de aplicaciones que demuestran sus beneficios. En la actualidad el mayor interes
en las tecnologas de la Web Semantica est
a en el a
rea de la integraci
on de la informaci
on, y en especial,
en el dominio de la salud y la biologa.

4.7. XML, RDF, RDF schema [9]

La arquitectura de la Web Sem antica se organiza como una pila de lenguajes y tecnologas, donde
cada capa aprovecha las capacidades de las capas inferiores. El nivel inferior de la arquitectura est
a re-
presentado por la capa URI/IRI que tiene como prop osito la identificaci
on de los recursos en la Web
Semantica, mientras que la capa XML proporciona un metalenguaje para definir la sintaxis de los len-
guajes de la Web Sem antica.

RDF (Resource Description Framework) es el lenguaje para la descripci on de los recursos en la Web
Semantica. RDF permite establecer metadatos en forma de tripletas, es decir, sentencias que relacionan
un sujeto, un predicado y un objeto. Un conjunto de tripletas forman un grafo RDF. Las tres partes
de una tripleta pueden ser identificadas con una URI, aunque el sujeto y el objeto pueden ser nodos en
blanco, es decir, nodos con identificadores locales dentro del grafo. En RDF se puede asignar una URI
a una tripleta y que esta participe como sujeto u objeto en otra tripleta. Finalmente, los datos RDF se
almacenan en repositorios y se utiliza el lenguaje SPARQL para realizar consultas.

4.8. Presentaci
on de OWL y OWL 2 [9]
La sencillez de las primitivas de representaci on RDF hace que sean insuficientes para determinados
escenarios. RDF Schema (RDFS) es una extensi on de RDF para representar ontologas b
asicas median-
te constructores adicionales como la definici on de dominios y rangos de propiedades o subclases. Sin
embargo, la expresividad de RDFS es a un limitada, ya que por ejemplo, no es posible expresar que dos
conceptos son disjuntos o definir restricciones de la cardinalidad sobre propiedades. Por este motivo el
lenguaje recomendado para representar conocimiento ontol ogico en la Web Semantica es OWL (Web
Ontology Language) y OWL 2.

OWL est a pensado para ser usado cuando la informaci on contenida en los documentos necesita ser
procesada por las aplicaciones, al contrario que en las situaciones donde el contenido s olo necesita
ser presentado a los humanos. OWL puede ser usado para representar explcitamente el significado de
terminos en vocabularios y las relaciones entre esos terminos. Esta representaci
on de terminos y sus
interrelaciones se denomina ontologa.

16
OWL tiene mayor capacidad para expresar significado y sem antica que XML, RDF y RDF-S, de este
modo, OWL va m as all
a de estos lenguajes en su capacidad para representar contenido interpretable
por un ordenador en la Web. OWL es una revisi on del Lenguaje de Ontologas Web DAML+OIL in-
corporando lecciones aprendidas a partir del dise
no y aplicaci
on de DAML+OIL.

Figura 11. Construcciones de OWL [9]

La Web sem antica es una visi

on del futuro de la Web donde la informaci on esta dando un significado
explcito, permitiendo que las m aquinas puedan procesar autom aticamente e integrar la informaci
on
disponible en la Web. El primer nivel requerido por encima de RDF para la Web sem antica es un
lenguaje de ontologas que pueda describir formalmente el significado de la terminologa usada en los
documentos Web. Si se espera que las m aquinas hagan tareas u
tiles de razonamiento sobre estos docu-
mentos, el lenguaje debe ir mas all a de las sem
anticas b
asicas del RDF Schema.

OWL ha sido dise nado para cubrir la necesidad de un lenguaje de ontologas Web. OWL forma parte de
un conjunto creciente de recomendaciones del W3C relacionadas con la Web sem antica. XML propor-
ciona una sintaxis superficial para documentos estructurados, pero no impone restricciones sem anticas
en el significado de estos documentos. La evolucion ha sido la siguiente:

XML Schema es un lenguaje que se utiliza para restringir la estructura de los documentos XML, adem
as
de para ampliar XML con tipos de datos.

RDF es un modelo de datos para objetos y relaciones entre ellos, proporcionando una semantica simple
para este. Este tipo de modelo de datos puede ser representado en una sintaxis XML. RDF Schema es
un vocabulario utilizado para describir propiedades y clases de recursos RDF, con una semantica para
la generalizaci
on y jerarquizaci
on tanto de propiedades como de clases.

OWL anade m as vocabulario para describir propiedades y clases: entre otros, relaciones entre clases
como uni
on de conjuntos, cardinalidad, igualdad, caractersticas de propiedades como la simetra, clases
enumeradas, etc...

17
OWL 2 es un lenguaje de representaci on del conocimiento que permite desarrollar ontologas: clases,
propiedades, tipos y valores de datos que son automatizados como documentos de Web Sem antica.
Las ontologas de OWL 2 tiene como objetivo facilitar un modelo de marcado construido sobre RDF
(Resource Description Framework) y codificado en XML. OWL 2 es una extensi on de OWL.

Figura 12. Construcciones de OWL [9]

La figura 12 ofrece una vision general del lenguaje OWL 2, mostrando sus principales componentes
y como se relacionan entre s. La elipse en el centro representa la idea abstracta de una ontologa, se
puede ver como una estructura abstracta o como un grafo RDF. En la parte superior se representan
las sintaxis que se pueden utilizar para serializar las ontologas. En la parte inferior est
an las dos espe-
cificaciones semanticas que definen el significado de OWL 2.

La estructura general de OWL2 es muy similar a la de OWL, cualquier ontologa expresada en OWL es
v
alida en OWL2. OWL 2 a nade nuevas funcionalidades con respecto a OWL, estas nuevas funcionalida-
des ofrecen m as expresividad a OWL2. Algunas de estas nuevas funcionalidades son: claves, cadenas de
propiedades, tipos de datos complejos, definici on de rangos, restricciones de cardinalidad, propiedades
asimetrica, reflexiva, disjunto y ofrece capacidades de anotaci
on mejoradas.

4.9. Prot
eg
e y razonadores [3]
Protege es un editor de ontologas gratuito, de software abierto y un framework para la construcci
on
de sistemas inteligentes. Protege est
a mantenido por una amplia comunidad academica, el gobierno y
la empresa los cuales usan Protege para construir bases de conocimiento que a su vez se utilizan para
solucionar problemas muy diversos en a reas como la biomedicina, comercio electronico y modelado
organizativo.

Los desarrolladores pueden integrar en su software todas las posibilidades de Protege a traves de su
librera y cuentan con el soporte de la comunidad y el equipo de trabajo de Protege en la Universidad
de Stanford.

18
Protege soporta al completo la u
ltima versi
on de OWL 2 Web Ontology Language y las especificaciones
RDF del World Wide Web Consortium.

Protege dispone de un sistema de plugin que le da mayor potencia como por ejemplo:

RACER Razonador basado en l

ogicas descriptivas.

OWLViz Plugin para visualizar grafos.

Existen cientos de plugin. En http://protegewiki.stanford.edu, p agina oficial de protege, se muestra

una relaci
on con mas de 500, lo cual no da una idea de la cantidad de gente que hay trabajando en
mejorar la herramienta y la gran utilidad que tiene en diferentes a
reas.

La interfaz de Protege se centra fundamentalmente en los siguientes elementos:

Classes: Es el componente principal, las clases representan los conceptos. En esta pesta
na tambien se
definen las relaciones entre clases y las propiedades de las clases.

Object properties: Son elementos donde se definen unas propiedades y estas propiedades sirven para
crear relaciones entre individuos de una clase. Por ejemplo la propiedad hermano sirve para relacionar
individuos de la clase persona, entonces podramos decir que Pepe es hermano de Juan, si adem as
decimos que hermano cumple la propiedad transitiva, se podra deducir que si Pedro es hermano de
Juan, Pedro tambien es hermano de Pepe.

Data properties: Son elementos que relacionan individuos que pertenecen a una clase y los datos. Un
ejemplo sera la Object Porpertie edad, entonces se podra expresar que Pepe tiene la edad de 32 a
nos.

Individual: representan los objetos del dominio, son las instancias de las clases. Los properties pueden
tener un dominio y un rango, donde, un dominio de propiedad reduce los individuos a los que puede
aplicarse la propiedad y el rango de una propiedad reduce los individuos que una propiedad puede tener
como su valor.

A partir de la informacion provista por las ontologas y conjuntos de reglas, los razonadores pueden
llevar a cabo procedimientos autom aticos para inferir y generar nuevas relaciones. Existe un amplio
rango de razonadores automatizados disponibles y en general la inferencia utilizada en este contexto
corresponde al de la l
ogica de primer orden.

5. Descripcion del problema. Objetivos y Motivaci

on para convertir
arquetipos a OWL
OpenEHR teniendo ya algunos a nos de investigaci
on a sus espaldas todava lo podemos considerar una
tecnologa joven, existen pocas herramientas que traten la informaci on producida por el est andar. La
mayora del software que hay se centra en gestionar repositorios de arquetipos, creacion y validaci
on de
arquetipos, software que interpreta arquetipos para la gesti on de servicios en hospitales y programas
generadores de interfaces de usuario a partir de arquetipos. En cambio OWL tiene a su disposici on gran
cantidad de herramientas, adem as hay especialistas en tratar dicha informaci on y en la produccion de
nuevo conocimiento a traves de herramientas de minera de datos y razonadores OWL, por lo tanto, la
conversi
on de los arquetipos a OWL producir a nuevo conocimiento a partir de la informaci on registrada
por los est
andares basados en openEHR.

A continuaci
on voy a detallar una lista de motivos por los cuales, en mi opini
on, es u
til transformar
arquetipos expresados en ADL a OWL.

5.1. Informaci
on distribuida
Un punto fuerte de RDF es la gestion que hace de la informaci
on distribuida. RDF de forma natural
tiene elementos que permiten tratar los datos que se encuentran dispersos a lo largo del vasto mundo

19
de la web, es capaz de acceder a los datos distribuidos en multitud de servidores y reunirlos en una sola
consulta. Las bases de datos hospitalarias por regla general gestionan grandes vol umenes de informacion
y adem as est
a distribuida a lo largo y ancho de un pas, algunas centralizadas a nivel de comunidad
autonoma, otras a nivel provincial y en muchos casos a nivel de instituci on. Debemos tener tambien
en cuenta los hospitales privados que son islas de informaci on y que ganan cada vez m as cuota de
mercado en regiones que tienden a un modelo mixto entre lo p ublico y lo privado. Es por ese motivo,
que toda esta informaci on clnica que se encuentra distribuida, aun contando con un estandar que haga
interoperables las instituciones y suponiendo que ese est andar fuese openEHR, iso 13606 o HL7, no
tienen la capacidad de lanzar consultas que recojan la informaci on distribuida y la trate de manera
unificada, por ese motivo es importante trabajar en compatibilizar y alinear el mundo de los arquetipos
con el mundo de OWL.

5.2. Extracci
on de datos aislados de la informaci
on personal
Una de las caracterstica que tiene openEHR es la separaci on de los datos demogr aficos de los datos
clnicos, es una premisa de la especificaci on que los datos personales deben permanecer protegidos y
aislados de los datos clnicos, es por esta caracterstica, que hace que sea factible, abrir un canal publico
destinado a la investigaci on tanto de la universidad como de la empresa, por el cual se pueda extraer
informaci on para la realizaci
on de estudios de enfermedades, evoluci on de las mismas, efectividad de
los tratamientos, etc... se hara m as facil la colaboraci on entre el sistema sanitario y los potenciales
consumidores de la informaci on, tambien se ganara en transparencia, se podra realizar an alisis com-
parativo en cuanto a eficiencia y calidad entre los distintos centros. Todo esto no sera posible si en
algun momento se compromete la privacidad de los pacientes de un hospital. Por tanto OWL y sus
mecanismos de b usqueda son de gran utilidad a la hora extraer informaci on de las bases de datos de
openEHR, RDF y por ende OWL dispone de un lenguaje de consulta llamada SPARQL que es capaz
de extraer informaci on de las BBDD medicas si se crean los end-point correspondientes en cada una de
ellas.

5.3. Esquema de los datos conocido y p

ublico
OpenEHR tiene la particularidad de que el esquema de los datos es p ublico (al menos para los miembros
de una comunidad) y est a expresado en el lenguaje ADL, un lenguaje que seg un su autor es compren-
sible por un humano y que tiene una sem antica que da un significado a los datos y que esta en en lado
opuesto a las tablas dentro de una base de datos relacional con campos nombrados al antojo de un
informatico. Los arquetipos son en s mismos significativos para quien los lee.

Por ese motivo cualquier persona es capaz de extraer la informaci

on que m as le interese por si mismo,
sin tener que prepararla ning
un inform
atico conocedor de los datos internos de la instituci
on, para ello
openEHR proporciona un lenguaje de consulta llamado AQL (Archetype Query Languaje)

Los arquetipos manejados en una instituci on deben ser los aprobados y publicados en la CKM de la
regi
on/pas en el que opere. Esta caracterstica de esquema publico hace factible que por un lado se
puedan acceder a los repositorios de arquetipos para extraerlos y convertirlos a OWL y una vez hecho
esto, aplicar las herramientas de b
usqueda, consulta y extraccion de informaci
on que est
an disponibles
en OWL y poder hacer con los datos openEHR lo que se conoce como Liked Open Data, mirar figura. 13.

Todo este sistema hace factible la conversi

on de los datos a instancias de OWL y aprovechar las ventajas
que ofrecen las herramientas basadas en la web sem antica para la busqueda de informaci
on.

5.4. Minera de datos

Ya hemos comentado en los puntos anteriores que disponemos de un sistema capaz extraer un volumen
de datos considerable de forma distribuida y sin comprometer los datos personales de ning un paciente
y que toda esa informacion es posible reunirla en un u
nico sitio, es por ese motivo que se puede hacer
minera de datos y extraer informaci
on oculta dentro de los mismos mediante herramientas como por

20
 Figura 13. Liked Open Data

ejemplo: WEKA de la universidad de Waikato http://www.cs.waikato.ac.nz/ml/weka/.

De la misma forma que WEKA es capaz de ayudarnos a describir que productos est an relacionados
en un supermercado, por ejemplo la cerveza y las patatas fritas, con los datos adecuados tambien nos
podra ayudar a descubrir que sustancias se asocian a ciertas enfermedades o que efectos secundarios
producen ciertos medicamentos en la poblaci on. Estos son algunos ejemplos que se me ocurren sin
tener ning
un tipo de conocimiento medico, estoy convencido que este tipo de herramientas a un medico
investigador le puede servir de gran ayuda en su trabajo y puede ayudar a producir datos de mayor
calidad.

5.5. Razonamiento sobre los datos

Ya hemos repasado algunas de las ventajas de aplicar un est
andar en un sistema clnico, si ese est
andar
es openEHR contamos con ventajas adicionales y si adem as lo alineamos con OWL el resultado es que
podemos entre otras cosas, usar las herramientas que son compatibles con esta tecnologa. Una de estas
herramientas son los razonadores y en cierto modo las razon de ser de OWL y OWL 2.

Sobre OWL se pueden definir ontologas que modelen un arquetipo, sobre esta ontologa creamos
relaciones entre clases, a estas relaciones le a
nadimos propiedades y por u
ltimo sobre esa ontologa, que
puede ser cambiante y adaptada a las necesidades del un estudio en cuesti on, creamos instancias de
los datos. Llegados a este punto ya tenemos todos los ingredientes necesarios para poner a trabajar un
razonador OWL con datos de openEHR e inferir conocimiento.

6. Trabajo realizado
Los objetivos de este trabajo son los siguientes:

21
 Desarrollar un modelo para la conversi
on de openEHR a OWL

Implementar un algoritmo en Java que convierta arquetipos de openEHR a OWL

Probar que el algoritmo funciona mediante test

Ofrecer un servicio en la web para convertir arquetipos a OWL

Crear un repositorio donde convivan arquetipos y sus ontologas equivalente en OWL

Poblar el repositorio con los arquetipos existentes en todas las CKMs conocidas.

Crear un procedimiento autom atico de actualizaci

on del repositorio para incorporar los nuevos
arquetipos que se a
nadan en la CKM.

Crear instancias de las ontologas producidas.

Todos estos objetivos se han cumplido en este trabajo, aunque tambien hay que resaltar que todos son
mejorables, se podra decir que son la base de un trabajo mucho m
as extenso y que se podra abordar
en un futuro.

6.1. Antecedentes
Antes de empezar a crear una ontologa propia que sirva de base para convertir arquetipos de openEHR
a OWL he investigado en internet la existencia de algun proyecto relacionado con el objetivo de aprove-
char el trabajo realizado por otra persona. Afortunadamente he encontrado un trabajo interesante para
este proyecto. Se trata de una ontologa desarrollada en la Universidad de Sevilla [15] la cual a partir
de ahora llamaremos ontologa base, en ella se describe un modelo de openEHR bastante completo,
mirar figura 14.

La ontologa completa esta divida en siete ontologas que se organizan de forma jer
arquica, en el nivel
superior est
a la ontologa que representa el modelo de referencia de openEHR y se va apoyando como
si de una torre se tratara, en las que se encuentran por debajo hasta llegar a la m as b
asica, donde se
representan los tipos de los datos, cada una de estas ontologas tiene su equivalente en el modelo de
referencia de openEHR, todos estos ficheros se pueden encontrar en el cd que acompa na este docu-
mento. Tambien se puede descargar de http://www.openehr.es. A continuaci on describo brevemente
en que consisten cada una de ellas:

EHR EXTRACT Reference Model.owl .- Trata las clases que se usan para extraer informaci on de
openEHR, en nuestro caso si necesitamos extraer informaci
on lo haramos usando las herramientas
disponibles para OWL.

EHR Reference Model.owl .- Contiene las estructuras de m as alto nivel para la definicion de un
EHR. Abarca el estado de un EHR, control de accesos, versiones, carpetas de clasificaci
on. Tambien
incluye las clases SECTION, ENTRY, etc...

Common Reference Model.owl .- Recoge conceptos comunes, elementos para poder auditar un re-
gistro medico, el concepto de PATH que se usa para referenciar elementos dentro de un EHR,
conceptos como el identificador de un arquetipo, etc...

Demographic Reference Model.owl .- Clases para tratar los datos demogr aficos como son el nombre,
direcci
on, rol, relaciones entre personas, relaciones entre organizaciones, etc...

Data Structures Reference Model.owl .- Estructuras de datos manejadas en un EHR, incluye las
clases HISTORY, EVENT, etc...

22
 Figura 14. Clases de la ontologa base

Data Types Reference Model.owl .- Tipos propios del modelo de referencia, como son cantidad, fe-
chas, textos, etc... Estos tipos de datos se apoyan en los tipos primitivos, por ejemplo en openEHR
el tipo cantidad esta compuesto de un tipo primitivo real para el valor de la medida + una unidad
de medida (tipo enumerado) + un tipo real que indica la precisi on de la medida.

Support Reference Model.owl .- Esta ontologa recoge los tipos primitivos. Entero, real, caracter,
etc...

Para realizar la conversi

on de los arquetipos de openEHR a OWL es necesario en primer lugar parsear
el arquetipo y cargarlo en una estructura en memoria que nos permita manejar todos sus elementos
mediante un programa, para ello la especificacion de openEHR nos proporciona un conjunto de clases
que el est
andar denomina Archetype Object Model (AOM) y un parser java que es el encargado de leer
el arquetipo y montar una estructura de objetos java que representa el arquetipo.

Ya tenemos en memoria una estructura de objetos java que representa el arquetipo y que nos permite
acceder a cada una de sus elementos, necesitamos crear una ontologa que tenga como base la ontologa
descrita en el punto anterior y que represente al arquetipo en cuesti
on, para realizar este trabajo nos
apoyamos en un framework llamado Apache Jena que sirve para construir estructuras de web sem anti-
ca y aplicaciones Liked data.

Buscando en la red informaci on acerca de c

omo convertir arquetipos a OWL encontre la tesis doctoral
de Leonardo Lezcano de la Universidad de Alcal a de Henares [16] que entre otras cuestiones referencia
una librera escrita en java y desarrollada en un proyecto llamado CISEP [12], esta librera toma
como referencia la ontologa base descrita anteriormente.

Ya tenemos la ontologa base y una librera que convierte arquetipos a OWL. La ontologa base no
la vamos a analizar en detalle ya que supondra varias p aginas de escritura y no es el objetivo de
este trabajo, por tanto en lo sucesivo se ir
an describiendo algunas partes de la misma, lo que si se

23
 Figura 15. Arquetipo Blood Pressure

Figura 16. Conversi

on a OWL del arquetipo Blood Pressure

24
puede adelantar es que la ontologa es un reflejo bastante fiel del modelo de referencia de openEHR
lo cual, hace pensar que esta ontologa puede haber sido disenada inicialmente para validar de forma
autom atica la correcci
on de un arquetipo e incluso para hacer interoperables arquetipos desde OWL,
en la bibliografa hay varios trabajos en este sentido.

6.2. Desarrollar un modelo de conversi

on de openEHR a OWL
Como era de suponer, la ontologa base se va a usar para realizar la conversi
on de los arquetipos de
openEHR a OWL, para poder usarla en este trabajo, ha sido necesario realizar unos peque nos ajustes
para que la misma se adapte a los objetivos pretendidos en este trabajo. No debemos olvidar que esta
ontologa no ha sido dise
nada para extraer informaci
on de los arquetipos.

Tras un primer an alisis se ve como esta ontologa modela el RM de openEHR de manera muy sint acti-
ca, es decir, si en el modelo de referencia de openEHR hay una clase HISTORY que es subclase de
LOCATABLE entonces la ontologa lo recrea de la misma forma y si adem as el modelo define que de un
elemento de tipo OBSERVATION debe colgar un solo elemento de tipo HISTORY entonces la ontologa
define propiedades para crear esta restricci on. Al arrancar el razonador se presentan inconsistencias en
la ontologa, por tanto, todas las restricciones innecesarias para nuestro trabajo y que presentan algun
tipo de inconsistencia en el razonador se han eliminado.

En segundo lugar uno de los objetivos pretendidos en este trabajo es: Poder trasladar la ontologa pro-
pia de openEHR y sus bindings (ICD, SNOMED, LOINC) a OWL y precisamente la ontologa base no
tiene clases para traducir los elementos del arquetipo que corresponden con el apartado ontology, por
tanto en la ontologa contenida en EHR Reference Model.owl se ha a nadido una nueva clase llamada
ONTOLOGY. Esta nueva clase ser a la encargada de contener la terminologa propia de los arquetipos
y los bindings con otras ontologas externas.

Una vez realizado estos peque nos ajustes ya tenemos la ontologa preparada para servir de contenedora
de los arquetipos que se van a convertir. Este trabajo se va a centrar en la parte del arquetipo que
nos conduce a los datos clnicos de los pacientes, por tanto, todas las clases que representan otras
partes del arquetipo que no son datos clnicos las vamos a ignorar. Es por ese motivo que nos vamos
a centrar en los arquetipos de tipo ENTRY y concretamente en los ENTRY que recopilan informaci on
del paciente como son los OBSERVATION y los EVALUATION. El resto no se tratan en este traba-
jo, en la figura 17 se pueden ver algunos arquetipos de tipo observacion dentro de la CKM de openEHR.

Figura 17. Muestra de arquetipos de tipo OBSERVATION

25
Para ilustrar como queda un arquetipo convertido a OWL podemos ver las im agenes 15 y 16 en la
primera observamos un fragmento del arquetipo en lenguaje ADL y en la siguiente vemos su conversi
on
a OWL.

En el ejemplo anterior solo se muestra un fragmento de la parte de definition, para visualizarlo completo
se puede hacer en la CKM de openEHR en la siguiente direcci on http://www.openEHR.org/CKM/ ,
haciendo una breve descripci on se ve como el arquetipo es de tipo OBSERVATION y contiene un nodo
de tipo HISTORY del que cuelgan eventos de tipo EVENT, dentro de un evento en particular hay una
estructura de tipo ITEM-TREE del que cuelgan ELEMENT, cada uno contiene un elemento de tipo
C-DV-QUANTITY el cual representa unidad, magnitud y precisi on, en el nodo de tipo ELEMENT es
donde se van a introducir los valores de las medidas dentro del arquetipo.

En la figura 16 se observa como para cada uno de los nodos del arquetipo se ha creado una clase, que
es subclase de la correspondiente dentro de la ontologa base, con las clases del modelo de referencia
de openEHR, la clase principal que representa al arquetipo es Blood-Pressure, corresponde al nombre
del arquetipo y se ha anadido como subclase de OBSERVATION que es la clase principal de la que
cuelgan los datos del arquetipo y as sucesivamente con todas las nodos, al final podemos ver como la
ontologa matriz act
ua como un engranaje donde se encajan las piezas correspondientes al arquetipo.

Figura 18. Termino at0000 del arquetipo Blood Pressure

Figura 19. Anotaciones comment y NodeId del termino at0000

En la parte de abajo de la figura 16 se ve como en la clase ONTOLOGY est an contenidos los elementos
de la ontologa del arquetipo, los elementos que se a naden son los correspondientes al term-binding
del arquetipo y se anaden tanto los terminos propios como los externos, adem as se crea una relaci
on
de equivalencia entre ambos. Los terminos de la ontologa del arquetipo que no tienen un equivalente
externo se introduce en el nodo correspondiente como una anotaci on: NodeId=[id del termino], com-
ment=valor del termino. En las figuras 18 y 19 se observa la conversion de los terminos.

6.3. Implementaci
on de un algoritmo java que convierte arquetipos a OWL
En el disco adjunto a este trabajo se incluye la librera CISEP, una vez estudiada la misma se observa
que el metodo de conversi
on que emplea es simple e intuitivo. Contiene un conjunto de clases java que
se corresponden con las clases contenidas en el arquetipo y que interesa trasladar a OWL, cada una de

26
ellas sabe como convertir el nodo correspondiente del arquetipo a OWL y se van llamando de forma
recursiva, en la figura 20 se muestran algunas de las clases java del convertidor.

Figura 20. Librera para convertir ADL a OWL

Una vez parseado el arquetipo y obtenida la estructura de clases que representa el misma mediante el
AOM, el metodo de conversion que emplea la librera es el siguiente: Si encuentra un elemento en el
arquetipo de tipo OBSERVATION entra en juego la clase ObservationTranslator.java, la clase java sabe
que dentro de un OBSERVATION hay un elemento data de tipo HISTORY por tanto convierte
el nodo en curso a OWL y delega en la clase HistoryTranslator.java la conversi on del nodo de tipo
HISTORY y as de forma recursiva hasta llegar a los nodos finales, en la figura 21 se puede observar
una muestra del codigo.

Modificar o extender la librera es simple, una vez modificada la ontologa base como se ha descrito
anteriormente para tratar las nuevas clases del arquetipo simplemente tenemos que a nadir el translator
correspondiente. En nuestro caso, una de las modificaciones sobre la ontologa base a sido anadir una
clase nueva en OWL llamada ONTOLOGY, las modificaciones al c odigo se pueden ver en la figura 22

En el c
odigo se observa como lo primero que se hace es localizar la clase ONTOLOGY dentro del
modelo creado por Jena desde la ontologa base, a partir de ah, navegando por la estructura de objetos
generados por el parser ADL se posiciona en el nodo term-bindings dentro del apartado ontology del
arquetipo, una vez ah, recorre todos los elementos y por cada uno crea dos clases OWL uno para el
termino at**** y otro para la ontologa externa, una vez creada las clases, se establece una relacion
de equivalencia entre ambas con el metodo addEquivalentClass de la clase OWLNamedClass.

Otra modificacion realizada a la librera es: Por cada nodo que se traslada desde el arquetipo a OWL
se a
nade una anotacion de tipo comment, esta anotaci on contiene una definici
on del nodo en el idioma
principal del arquetipo, esta definici
on se extrae de la secci
on de ontologa del arquetipo.

6.4. Servicio en la web para convertir ADL a OWL online

Una vez que tenemos la librera preparada para convertir arquetipos a OWL nos disponemos a crear un
servicio que a traves de la web, realice la conversi
on, dicho servicio est
a colgado en: http://www.openehr.es
la idea de la web no es solo subir esta aplicaci on de conversi on de arquetipos a OWL sino que pretende
ser un sitio donde se cuelguen futuras aplicaciones y trabajos relacionados con openEHR suponiendo
que haya m as gente interesada en este tema, por tanto, el grupo de investigaci on Khaos a puesto a dis-
posici
on de este trabajo, un servidor dentro del campus con Apache Tomcat. En la imagen 23 podemos

27
 Figura 21. Muestra del c
odigo del convertidor

Figura 22. C
odigo que convierte la parte de la ontologa

28
ver una imagen del portal.

El programa de conversi on est

a realizado en Java y lo que hace es subir el arquetipo al servidor, lo
procesa el convertidor y posteriormente devuelve al usuario el fichero convertido en formato OWL.
Todo este trabajo lo realiza un servlet llamado Convert.java que est a disponible junto con todas las
clases del proyecto en la web, tambien se ha puesto un enlace a la librera adl2ont al igual que a la
ontologa base, ver figura 24.

En el portal tambien se puede consultar un repositorio de arquetipos convertidos a OWL mediante el

programa de conversion que se ha desarrollado para este trabajo. Diariamente, por la noche, se ejecuta
un proceso de conversion y se actualiza el repositorio con los u
ltimos cambios. En el siguiente punto se
explica como funciona este proceso de sincronizaci on y de conversion.

6.5. Programa que sincroniza repositorios p

ublicos
El grupo de investigacion Khaos de la Universidad de M alaga, ha organizado entre los meses de Abril,
Mayo y Junio un seminario de openEHR donde algunos alumnos de inform atica de la salud han tenido
la oportunidad de aprender OWL, ontologas medicas y tambien como no openEHR, los integrantes
del seminario entre los que me incluyo hemos realizado algunas pr acticas para afianzar los conoci-
mientos adquiridos en el seminario, entre las pr
acticas realizadas se inclua, un programa en Java que
sincronizase los datos de una CKM con un repositorio local. El proceso de sincronizaci on consiste en
comparar todos los elementos del repositorio local con los de la CKM y todos los elementos nuevos o
modificados en la CKM se actualizan en local. Los alumnos todos de segundo curso, con las pr acticas
que han realizado, han adquirido destreza en programaci on Java, han aprendido a manejar las libreras
de openEHR, han aprendido a manejar las libreras de Apache Jena y con su trabajo han contribuido
al desarrollo de este proyecto.

Por tanto, fruto del trabajo colectivo se ha desarrollado un sistema que conecta con una lista de CKM
y de forma autom atica, descarga del servidor donde se encuentre, un zip con todos los arquetipos,
inmediatamente despues, si no existe, crea un directorio en la maquina local con el nombre de la CKM
y compara los elementos locales con los del zip, por un lado, compara los elementos de los directorios y
a
nade los nuevos, tambien compara el contenido de los arquetipos y si hay alguna modificaci on borra
el local y copia el de la CKM, de esta forma tenemos en un servidor local una imagen de todos los
arquetipos de un repositorio.

En el seminario, como trabajo de pr acticas se ha desarrollado un programa generador de instancias

que, a partir de un fichero con datos tabulados se producen instancias (individuals) de las ontologas
generadas por el conversor, actualmente no tiene utilidad, en un futuro se pueden usar estas instancias
para generar datos ficticios y realizar pruebas.

Actualmente hay localizados los siguientes repositorios:

australia=http://dcm.nehta.org.au/ckm/

openehr=http://www.openehr.org/ckm/

uk=http://clinicalmodels.org.uk/ckm/

elovenia=http://ukz.ezdrav.si/ckm/

russia=http://simickm.ru/ckm/ (actualmente est

a vaco)

Por tanto, en el servidor donde est

a instalado el programa de sincronizaci
on se encuentran estos cinco
repositorios locales. La utilidad de tener estos repositorios en local en primer lugar es la de poder
trabajar con ellos oine y en segundo lugar es la de poder convertir los arquetipos contenidos en el
mismo a OWL. El programa en cuesti on se encuentra accesible en el servidor antes mencionado y se
llama sincronizaCKM.java en un propertie llamado ckms.propertie se a naden las nuevas CKM que va-
yan apareciendo.

29
30
 Figura 24. Aplicaci
on convertidor

6.6. Programa que convierte el repositorio ADL a OWL

Por ultimo y para concluir el trabajo, se ha realizado un programa que convierte todos los arquetipos de
los repositorios locales a OWL usando las ontologas y los programas descritos en los puntos anteriores.

El programa en cuesti on est

a integrado dentro del programa de sincronizaci
on con el fin de reutilizar
parte del c
odigo anterior, con lo cual cuando un arquetipo se a
nade al repositorio se convierte y si un
arquetipo se ha modificado entonces se borra el OWL generado de la versi on anterior y se vuelve a
convertir, con este sistema tenemos un repositorio de arquetipos y sus equivalentes OWL conviviendo
y ademas nos aseguramos que est an actualizados.

La utilidad de tener un repositorio de ontologas que representan los arquetipos son las que se han
descrito anteriormente, aunque en este trabajo no se va a aplicar ninguna, si abrimos la puerta a que
otras personas interesadas en esta tecnologa puedan hacer uso de ellas.

7. Conclusiones y Trabajo futuro

La curva de aprendizaje de openEHR al principio es muy costosa, al menos a mi me lo ha parecido, de-
bemos tener en cuenta que es una tecnologa muy nueva y con una filosofa revolucionaria en el a mbito
de la salud, adem as tenemos que pensar que la audiencia de este tipo de tecnologas se limita al campo
de la informatica medica y por tanto no es algo que este de moda, con esto quiero decir que ahora
mismo y salvo trabajos puntuales, toda la informaci on para hacerse con openEHR es la propia especifi-
cacion que existe en la web de la fundaci
on www.openEHR.com. Otra de las dificultades que plantea
openEHR es que hay muy poco software que ponga en pr actica esta tecnologa y por tanto cualquier
experimento supone trabajar muchas horas en montar tu propio software. Por otro lado tenemos OWL
y la web sem antica que est
a en el polo opuesto, aunque no est
a dise
nado para trabajar exclusivamente
con openEHR por las caractersticas que presenta encaja bastante bien, es por ese motivo por el que
al final de este trabajo podemos concluir que es muy interesante usar OWL y openEHR de manera
combinada.

En los puntos anteriores ya hemos visto algunas de las utilidades de tener los arquetipos en formato
OWL, pero quiz as la que a corto plazo, creo que puede ser m as factible para empezar a trabajar es la
de razonar a partir de las instancias de los arquetipos, yo creo que en este campo se pueden empezar
a realizar ya trabajos interesantes, para que a partir de la informacion contenida de las bases de datos

31
medicas, se puedan identificar patrones por los cuales algunas personas contraen ciertas enfermedades,
tambien se puede analizar la efectividad de algunos tratamientos en base a la evoluci
on de los pacientes.

Como trabajo futuro queda mucho por hacer, por ejemplo algo que me inquieta es la forma de alma-
cenar los datos contenidos en los arquetipos, la especificaci
on no dice nada y la gente que trabaja con
esta tecnologa se lo monta como puede, algunos directamente en ficheros, otros convierten a xml los
arquetipos y los almacenan en bases de datos xml y los m as atrevidos montan complejas estructuras
en bases de datos relacionales para almacenar las instancias de los arquetipos. Un trabajo futuro sera
crear un especificacion acompa
nada de su correspondiente librera en java para crear una base de datos
ADL que de soporte a las aplicaciones de openEHR.

Otro trabajo interesante es el de crear un software libre que sea capaz de montar un servicio medi-
co a partir de los arquetipos openEHR, como se ha descrito en puntos anteriores la especificaci on de
openEHR tiene todos los ingredientes para montar un servicio medico completo: Urgencias, traumato-
loga, obstetricia, etc... Los arquetipos contienen informaci on suficiente para que las interfaces gr
aficas
se generen de forma autom atica, por tanto, sera muy interesante montar un software donde especi-
ficando: Servicios, flujos de trabajo y arquetipos este sea capaz de dar soporte a un servicio medico.
Este trabajo sera muy bueno desde el punto de vista del aprendizaje de personas que tomen contacto
con la tecnologa y para demostrar la potencia de la especificaci on. Actualmente y que yo conozca
existen dos programas que van en esa lnea, el primero de ellos es EHRGen de Pablo Pazos investiga-
dor que trabaja en el campo de EHR [4] y LinkEHR del grupo Ibime de la Universidad de Valencia [13].

Otro trabajo interesante es el de crear una metodologa para mapear las actuales bases de datos
medicas con los arquetipos, los sistemas medicos son muy grandes y evolucionan muy lentamente y
sera muy difcil migrar un sistema de un hospital a otro basado en openEHR, por tanto, un trabajo
interesante sera especificar de que forma, se puede mapear un sistema de informaci on hospitalaria
cl
asico a los arquetipos de openEHR y para realizar dicho trabajo pueden ser gran ayuda las ontologas
y la tecnologas de la web semantica para marcar semanticamente las bases de datos medicas y realizar
el proceso contrario al que hemos realizado en este trabajo.

Referencias
1. Digital imaging and communications in medicine, dicom.nema.org, October 2014.
2. En 13606 association site, www.en13606.org, October 2014.
3. A free, open-source ontology editor and framework for building intelligent systems, prote-
ge.stanford.edu, October 2014.
4. Generador de sistemas de historia clnica electr
onica basado en el estandar openehr, October 2014.
5. Health level seven international, www.hl7.org, October 2014.
6. International health terminology standards development organisation, October 2014.
7. Ocean informatics, October 2014.
8. Openehr site, www.openehr.org, October 2014.
9. World wide web consortium, October 2014.
10. Koray Atalag. Innovation and openness is there room for both, 2010.
11. David Moner Cano. Modelo de arquetipos UNE-EN 13606. IBIME, VERATECH.
12. CISEP. Intelligent clinical records for patient safety., 2008.
13. Grupo de trabajo IBIME. Software platform for the normalization and semantic representation of
clinical datas, October 2014.
14. Selene Indarte. Interoperabilidad. Technical report, SEIS, 2010.
15. Isabel Rom an Martnez. Aportaciones Metodol ogicas a la Integraci
on de Sistemas de Informaci
on
Sanitarios basada en Gesti on Semantica. PhD thesis, Unversidad de Sevilla, 2006.
16. Leonardo Lezcano Mata. Combining ontologies and rules with clinical archetype. PhD thesis,
Unversidad de Alcal a de Henares, 2013.
17. Jose Luis Monteagudo. Est andares para la historia clnica electr
onica. Technical report, SEIS,
2003.

32