Nº 65 - Sociedad Española de Informática de la Salud

Nº 65 - Sociedad Española de Informática de la Salud

Foro de Normalización
Coordinador: Adolfo Muñoz
ADL - LENGUAJE DE DEFINICIÓN DE ARQUETIPOS
Para el desarrollo de la norma europea EN13606 para la transferencia de historias clínicas electrónicas se han
seguido, principalmente, los 3 paradigmas que actualmente gobiernan la definición de normas: separación
de responsabilidades, según el cual es necesario descomponer un sistema complejo, como es el caso de la
informática sanitaria, en otros más simples y manejables, separación de puntos de vista, que sigue el modelo
de referencia de ISO para el desarrollo de sistemas abiertos de procesamiento distribuido (RM/ODP) y
separación de información y conocimiento paradigma mediante el que se diferencian los datos conocidos de
una determinada entidad del dominio (la información:
Juan Español tiene una tensión arterial de 150 – 95 mmHg) de aquellos conceptos que son ciertos para
todas las entidades (el conocimiento: una medida de la presión arterial humana está compuesta por dos valores,
la presión sistólica y la diastólica). Este último paradigma es el que va a permitir que los sistemas de
información compatibles con la norma estén, por un lado protegidos frente a los cambios del conocimiento que,
como fruto de la investigación o de la práctica diaria, tan comunes son en el campo clínico y, por otro, sean
semánticamente interoperables entre sí.
En la norma EN13606 la separación de información y conocimiento se implementa mediante la especificación
de un doble modelo, de referencia y de arquetipos. El modelo de referencia representa las características
generales de los componentes del registro de salud, cómo se organizan y la información de contexto
necesaria para satisfacer los requerimientos tanto éticos como legales. Define el conjunto de clases para
representar los bloques constitutivos del registro, es decir, sus características estables. Sin embargo, para
alcanzar la interoperabilidad semántica deseada, este modelo debe ser complementado en el dominio del
conocimiento por un método formal para transmitir y compartir estructuras de clases predefinidas, acordadas
por una comunidad, que se correspondan con fragmentos del registro, creados en situaciones clínicas
específicas: los arquetipos. Un arquetipo es una combinación jerárquica de componentes del modelo de
referencia a los que restringe (fijando sus nombres, los tipos de datos posibles, valores por defecto,
cardinalidad, etc.) para modelar conceptos clínicos del dominio del conocimiento.
La norma EN13606 define en su primera parte el modelo de referencia, mientras que en la segunda
define el modelo de arquetipos, así como propone un lenguaje para la definición de los mismos, el ADL
(Archetype Definition Language).
El ADL es un lenguaje creado para la expresión de arquetipos que puede ser utilizado en cualquier dominio
en el que los conceptos se puedan describir como instancias de un modelo de referencia subyacente,
pues no está basado en ningún modelo de referencia concreto, ni comparte ninguna palabra clave con él.
ADL especifica restricciones sobre los tipos o las clases del modelo por medio de una sintaxis concreta, el
cADL (constraint ADL - ADL de restricciones) definiendo las características que deben cumplir las instancias
del modelo de referencia para ser conformes al arquetipo.
Además del cADL, ADL utiliza una segunda sintaxis, en este caso para definir instancias de los datos también
acordes a un modelo de referencia, el dADL (data ADL - ADL de datos). Es decir, mientras el cADL se usa
para determinar restricciones que deben cumplir las instancias e datos, dADL se emplea para expresar
instancias de los mismos.
1.1 dADL - ADL de datos
El dADL es una sintaxis que proporciona una manera de expresar instancias de datos, acordes a un modelo de
referencia, de tal manera que sean procesables por una máquina y legibles por un humano. El siguiente ejemplo
es una muestra de su aspecto:
PERSONA [01234] = <
nombre = NOMBRE_PERSONA <-- nombre de persona
nombre = <”Irene”>
apellido = <”Adler”>
>
direccion = DIRECCION <-- dirección de persona
nombre_calle = <”Baker”>
número_calle = <”223 b”>
ciudad = <”Londres”>
país = <”Inglaterra”>
>
El ejemplo es una instancia de datos acordes a un hipotético modelo de referencia en el que se definiese una
clase llamada “PERSONA” que contuviese, al menos, dos atributos: nombre, de tipo NOMBRE_PERSONA y
dirección, de tipo DIRECCION. A su vez la clase NOMBRE_PERSONA contendría como mínimo dos
atributos, ambos de tipo CADENA: nombre y apellido. Por su parte, la clase DIRECCIÓN contendría los
atributos, también de tipo CADENA: nombre_calle, número_calle, ciudad y país. Un documento dADL
siempre expresará una jerarquía de una o más instancias de objetos de un modelo de referencia. En su forma
más básica, la estructura es una repetición del siguiente esquema:
identificador_atributo = {TIPO_VALOR} <valor>
donde valor puede ser un valor literal de uno de los tipos primitivos definidos en el lenguaje (carácter, entero,
cadena, etc.) con lo que representaría una hoja de la jerarquía, o una anidación de atributos (es decir, uno de los
tipos de datos definidos en el modelo de referencia) y nuevos valores. El valor también puede ser una cadena
vacía, para indicar que en esa particular instancia de un objeto, no se da valor a un determinado atributo.
Ante el parecido de dADL parecido con XML puede surgir la duda de por qué no utilizar aquél en lugar de
proponer un lenguaje nuevo. La principal razón para la creación de dADL reside en que el objetivo principal
del lenguaje es que sea fácilmente leído por un humano y esa característica no está presente en XML (cualquier
ejemplo real de XML es difícilmente comprensible por un humano) porque XML es un lenguaje enfocado al
procesamiento automático y que se mantiene legible únicamente como una consecuencia de otra de sus
características, que es asegurar la interoperabilidad sintáctica. Otras razones para el uso de dADL son: un
conjunto de tipos primitivos más completo, incluyendo intervalos, listas y fechas, que XML no define,
dADL se adhiere a una semántica orientada a objetos, característica que XML generalmente no ofrece, y, por
último, evitar la confusa notación de XML que diferencia entre atributos y elementos para representar lo que en
el fondo son propiedades de objetos.
1.2 cADL - ADL de restricciones
cADL es un lenguaje para la definición de restricciones sobre datos definidos por un modelo de referencia.
Estas restricciones pueden ser incluidas en arquetipos o en otros formalismos de definición de conocimiento, de
tal manera que puedan emplearse tanto por los diseñadores, para modelar conceptos de un dominio, como en
tiempo de ejecución de manera que los sistemas de información puedan validar si unos datos determinados
son conformes o no a un modelo. El siguiente ejemplo muestra su aspecto general:
PERSONA [at0000] matches
{-- Restricciones para instancias de PERSONA
nombre matches {
TEXTO matches { /.+/} -- Cadena no vacía
}
dirección cardinality matches { 0..*} matches {
DIRECCIÓN_POSTAL matches {
--- etc ---
En el ejemplo se establecen restricciones sobre elmismo modelo de referencia utilizado anteriormente,
para definir cómo deben ser las instancias de datos del tipo PERSONA que nos interesan. En concreto se dice
que una instancia ha de tener un nombre, que éste es de tipo TEXTO y que debe ser una cadena no vacía y
también que puede tener de 0 a varias direcciones.
La estructura general de las restricciones escritas en cADL es anidada. Siempre se comienza expresando las
restricciones sobre un tipo. Estas restricciones se definen a su vez por medio de restricciones sobre las
propiedades (atributos) del tipo original. A su vez, las restricciones sobre las propiedades se definen
estableciendo restricciones sobre sus tipos de datos. El proceso continúa hasta que el tipo de la propiedad es
uno de los tipos de datos primitivos y se establece una restricción sobre los valores que puede tomar. En el
ejemplo de la sección anterior se establecen restricciones sobre el tipo PERSONA.
Para ello se definen restricciones sobre sus propiedades (atributos nombre y dirección) y para definir estas
restricciones se plantean restricciones sobre los tipos de los atributos (TEXTO y DIRECCIÓN_POSTAL).
Únicamente se establecen restricciones para aquellos nodos que sea necesario. Si alguno de los atributos
pertenecientes a una clase no aparece entre las restricciones establecidas para dicha clase, lo que se indica es
que no se establecen para ese atributo más restricciones que las establecidas por el modelo de referencia. Las
restricciones establecidas por medio de cADL no pueden ser más fuertes que las que establece el propio
modelo de referencia subyacente. Es decir, si, por ejemplo, el modelo de referencia establece que de los
atributos del tipo PERSONA, nombre es obligatorio, ninguna restricción cADL de un arquetipo puede
establecer que dicho atributo sea opcional.
1.3 Definición de un arquetipo
Utilizando estas dos sintaxis vistas, ADL permite definir arquetipos para modelar conceptos del conocimiento
del dominio tratado. En la figura pueden verse las distintas secciones que componen un arquetipo, junto con
la sintaxis utilizada en cada una de ellas.
Las primeras secciones se usan para dar un nombre al arquetipo (archetype), para indicar si se trata de una
especialización de otro (specialize) y para especificar el concepto del dominio que modela (concept). Este
concepto puede, como cualquier otro nodo incluido en la definición del arquetipo, codificarse utilizando un
sistema propio o cualquiera de las terminologías disponibles, como SNOMED. A continuación se indica el
idioma original del arquetipo así como las traducciones disponibles (language). La siguiente sección
(description) sirve para informar sobre el autor y la organización para la que trabaja, así como detalles de usos
recomendados y prohibidos del arquetipo. La sección de definición (definition) es la única escrita en cADL y
es la que expresa las restricciones sobre el modelo de referencia. En la sección de ontología se da valor a los
códigos definidos en los nodos del arquetipo y se enlazan éstos con las ontologías deseadas. También en esta
sección se incluyen las traducciones de cada elemento textual a los diferentes idiomas de los que dispone el
arquetipo. En la última sección (revision_history) se puede incluir la historia de la evolución del arquetipo.