Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
UNIVERSIDAD DE MURCIA
FACULTAD DE INFORMÁTICA
ArchForms: Generación automática de aplicaciones para la gestión de la Historia
Clínica Electrónica
María del Mar Rubio González
Dirigido por:
D. Jesualdo Tomás Fernández Breis D. Marcos Menárguez Tortosa
Septiembre 2009
Índice general
Abstract 1
1. Introducción y Contexto del Proyecto 2
1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Contexto del Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Objetivos y Metodología 5
2.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Cronograma del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Historia Clínica Electrónica 9
3.1. Arquitectura del Modelo Dual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Estándares de Historia Clínica Electrónica . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1. Estándares HL7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2. Estándar openEHR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.3. Estándar ISO/EN 13606 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3. El Modelo de Referencia de la Norma ISO/EN 13606 . . . . . . . . . . . . . . . . . . 15
3.4. El Modelo de Arquetipos de la Norma ISO/EN 13606 . . . . . . . . . . . . . . . . . 16
3.4.1. Arquetipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4.2. Lenguaje de de�nición de arquetipos (ADL) . . . . . . . . . . . . . . . . . . . 17
3.4.3. Lenguaje de Restricciones de ADL (cADL) . . . . . . . . . . . . . . . . . . . 19
4. Tecnologías utilizadas 20
4.1. JavaServer Faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.1. Estructura de una aplicación web con JSF . . . . . . . . . . . . . . . . . . . . 22
4.1.2. Modelo-Vista-Controlador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.3. RichFaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
ÍNDICE GENERAL ii
4.2. Framework de desarrollo para JSF: Seam Framework . . . . . . . . . . . . . . . . . . 24
4.3. Desarrollo de Software Dirigido por Modelos . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.1. Metamodelado y lenguajes de metamodelado . . . . . . . . . . . . . . . . . . 25
4.3.2. Eclipse Modelling Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.3. Transformación modelo-texto . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.4. MOFScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5. Diseño de la solución 30
5.1. Implementación de las restricciones del modelo de referencia de ISO/EN 13606. . . . 30
5.1.1. Tipos de datos de ISO/EN 13606. . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1.1.1. Paquete de restricciones para los tipos primitivos. . . . . . . . . . . 31
5.1.1.2. Tipos de datos no primitivos. Representación y consideraciones. . . 34
5.1.1.3. Tipos de datos estructurados . . . . . . . . . . . . . . . . . . . . . . 35
5.1.1.4. Tipos de datos de texto y codi�cados . . . . . . . . . . . . . . . . . 36
5.1.1.5. Tipos de magnitud . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.1.1.6. Tipos relacionados con el tiempo . . . . . . . . . . . . . . . . . . . . 40
5.1.2. Componentes de la jerarquía del modelo de referencia de ISO/EN 13606. . . 42
5.1.2.1. Restricciones aplicadas a los componentes de la jerarquía del modelo
de referencia de ISO/EN 13606 . . . . . . . . . . . . . . . . . . . . . 42
5.1.2.2. Representación grá�ca de los componentes de la jerarquía del modelo
de referencia de ISO/EN 13606. . . . . . . . . . . . . . . . . . . . . 43
5.2. Diseño de la estructura de las aplicaciones web. . . . . . . . . . . . . . . . . . . . . . 44
5.2.1. Estructura básica de las aplicaciones web generadas . . . . . . . . . . . . . . 44
5.2.2. Los controladores de la aplicación web. . . . . . . . . . . . . . . . . . . . . . . 46
5.2.3. Clases del paquete beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2.4. Clases del paquete clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2.5. Fichero de propiedades para el árbol de navegación de la aplicación . . . . . . 53
5.2.6. Vistas de la aplicación web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2.6.1. Vistas �jas en las aplicaciones web generadas. . . . . . . . . . . . . 54
5.2.6.2. Vistas creadas por el generador. . . . . . . . . . . . . . . . . . . . . 55
5.3. Implementación de los generadores de las aplicaciones web. . . . . . . . . . . . . . . 56
5.4. Generación del extracto del arquetipo. . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.5. Tarea Ant para la ejecución de los generadores y el despliegue de la aplicación . . . . 57
6. Conclusiones y vías futuras. 59
ÍNDICE GENERAL iii
Anexos 62
A. Datos detallados de representación de los Tipos de Datos de ISO/EN 13606 62
B. Arquetipo Informe de Alta en ADL 67
C. La tarea Ant. Detalles y consideraciones para ejecutar el generador 74
D. Vistas de la aplicación web generada para el arquetipo Informe de Alta 77
Índice de �guras
2.1. Cronograma del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Arquitectura del modelo de un solo nivel. . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Arquitectura del modelo dual. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Especi�caciones de openEHR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4. Diagrama de la jerarquía del Extracto de la HCE . . . . . . . . . . . . . . . . . . . . 15
4.1. Petición/respuesta de una página JSP que incluye etiquetas JSF . . . . . . . . . . . 21
4.2. Modelo-Vista-Controlador de JSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3. Ejemplo de la arquitectura de 4 capas OMG. . . . . . . . . . . . . . . . . . . . . . . 26
4.4. EMF uni�ca Java, XML y UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.5. Tres etapas fundamentales de DSDM. . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.6. Ejemplo de transformación con MOFScript . . . . . . . . . . . . . . . . . . . . . . . 29
5.1. Paquete de restricciones para los tipos primitivos de la Norma ISO/EN 13606. . . . 31
5.2. Paquete de los Tipos Estructurados de ISO/EN 13606 . . . . . . . . . . . . . . . . . 35
5.3. Representación grá�ca del tipo de dato Instance Identifier (II) . . . . . . . . . 36
5.4. Paquete de los Tipos de Texto y Codi�cados de ISO/EN 13606 . . . . . . . . . . . . 37
5.5. Representación grá�ca del tipo de dato Coded Text . . . . . . . . . . . . . . . . . . . 37
5.6. Representación grá�ca del tipo de dato Concept Role (CR) . . . . . . . . . . . . . . 38
5.7. Paquete de los Tipos de Magnitud de ISO/EN 13606 . . . . . . . . . . . . . . . . . . 39
5.8. Representación grá�ca del tipo de dato Physical Quantity (PQ) . . . . . . . . . . . 39
5.9. Representación grá�ca del tipo de dato Duration . . . . . . . . . . . . . . . . . . . . 40
5.10. Representación grá�ca del tipo de dato Quantity Ratio (RTO) . . . . . . . . . . . . 40
5.11. Representación grá�ca del tipo de dato Quantity Range (IVL<PQ>) . . . . . . . . . 40
5.12. Paquete de los Tipos de Tiempo de ISO/EN 13606 . . . . . . . . . . . . . . . . . . . 41
5.13. Representación grá�ca del tipo de dato Interval of Time (IVL<TS>) . . . . . . . . 41
ÍNDICE DE FIGURAS v
5.14. Representación grá�ca del tipo de dato Periodic Interval of Time (PIVL) . . . . 42
5.15. Representación grá�ca del tipo de dato Event Related Periodic Interval of Time
(EIVL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.16. Estructura de la aplicación web generada . . . . . . . . . . . . . . . . . . . . . . . . 44
5.17. Flujo de las aplicaciones web generadas . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.18. Tareas realizadas por Ant para generar, ejecutar y desplegar la aplicación web. . . . 58
D.1. Vista generada para la COMPOSITION at0000 . . . . . . . . . . . . . . . . . . . . . . 77
D.2. Vista generada para la ENTRY at0007 . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
D.3. Vista generada para la ENTRY at0018 . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
D.4. Vista generada para la ENTRY at0012 . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
D.5. Vista generada para la ENTRY at0015 . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
D.6. Vista generada para la ENTRY at0004 . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
D.7. Vista generada para la ENTRY at0005 . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
D.8. Vista generada para la ENTRY at0017 . . . . . . . . . . . . . . . . . . . . . . . . . . 81
D.9. Vista generada para la ENTRY at0037 . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Abstract
Hoy día, el acceso a la información clínica de un paciente es una de las necesidades básicas de
cualquier profesional sanitario. Que esta información sea accesible desde distintos centros ubicados
en sitios geográ�camente dispersos facilitaría enormemente las labores sanitarias, ya sea para �nes
médicos o de investigación. La compartición de la información es, por tanto, un aspecto clave en el
ámbito de la medicina.
Cuando la información clínica de un paciente se encuentra almacenada en un medio electrónico,
constituye lo que se denomina Historia Clínica Electrónica (HCE). Los sistemas de HCE deben
garantizar la perduración de la HCE y ser tecnológicamente independientes. Estas propiedades
facilitan la compartición de la información, permitiendo la interoperabilidad a nivel de los datos y
de conocimiento y el soporte de diferentes estructuras de datos clínicos.
El ámbito de la medicina comprende una gran cantidad de conceptos clínicos, y se encuentra
en continua evolución por lo que un modelo de información tradicional no permitiría cumplir los
requisitos clínicos ya que no es capaz de adaptarse a su continua evolución. Como respuesta a esta
necesidad surgen diferentes arquitecturas y estándares clínicos de donde destaca una arquitectura
denominada de modelo dual. Esta arquitectura distingue dos niveles conceptuales: (1) modelo de
referencia; y (2) modelo de los arquetipos. Un arquetipo se de�ne como un conjunto de restricciones
sobre un dominio de información, que de�nen un concepto clínico. Los arquetipos permiten expresar
la información clínica de manera compartible y reutilizable. De los estándares que siguen dicha
arquitectura (HL7, openEHR, ...), en este proyecto se utilizará el estándar ISO/EN 13606 ya que es
una Norma Europea muy extendida a lo largo de este territorio.
Para los profesionales sanitarios sería deseable que a partir de los arquetipos semánticos de
conceptos clínicos se dispusiera de una aplicación que procesara dichos arquetipos para generar una
aplicación web que les permitiera introducir la información en los mismos y almacenarla en un
extracto compatible con el estándar ISO/EN 13606. Por lo tanto, este proyecto trata de ofrecer un
generador de aplicaciones web que realice esta tarea. Para cumplir este objetivo, se tendrán que
cumplir los siguientes subobjetivos: (1) análisis e implementación de las restricciones de los tipos de
datos y de los componentes de la jerarquía del modelo de referencia ISO/EN 13606, (2) diseño de la
estructura de las aplicaciones web para obtener extractos de HCE conforme a arquetipos ADL e (3)
implementación de los generadores de las aplicaciones web. Cuando se cumplan estos tres objetivos,
el objetivo de este proyecto quedará satisfecho y se dispondrá de un generador de aplicaciones web
para los arquetipos de�nidos en el estándar ISO/EN 13606.
Capítulo 1
Introducción y Contexto del Proyecto
1.1. Introducción
El sector sanitario está en las puertas de un nuevo escenario inducido principalmente por las
nuevas tecnologías de la información y su potencial para transformar el proceso de atención sanitaria.
En el centro de está revolución se encuentran las Historias Clínicas Electrónicas (HCE) de los
pacientes, como así lo demuestran las recomendaciones efectuadas por muchas de las organizaciones
sanitarias, ya sean nacionales o internacionales, para la promoción y desarrollo de tales sistemas.
Las ventajas de las HCE sobre las tradicionales en papel son ampliamente reconocidas en el sector
como medio para mejorar la e�ciencia, seguridad y calidad de la atención sanitaria. Tres aspectos
de la sociedad actual inciden de forma directa en cómo han de ser las futuras HCEs:
La cada vez mayor movilidad de los ciudadanos hace que la necesidad de recibir atención
sanitaria en un lugar diferente al habitual sea cada vez más frecuente.
El cada vez más rápido camino hacia la sociedad de la información está con�gurando un ciu-
dadano que cada vez distingue menos entre capacidad de acceder a la información y ubicación
geográ�ca.
En los países occidentales, con el aumento de la esperanza de vida y el incremento de pacien-
tes crónicos y ancianos se ha hecho necesaria la aparición de nuevos modelos de prestación
de cuidados compartidos entre los diferentes niveles asistenciales basados en la atención por
distintos profesionales, en distintos momentos y distintos lugares de un mismo paciente.
Estos nuevos modelos de atención centrado en el paciente y basado en una política de compartición
de la responsabilidad de la asistencia sanitaria dependen crucialmente del uso e�ciente de las tec-
nologías de la información y las comunicaciones para desarrollar redes telemáticas y servicios que
comuniquen los centros de atención involucrados. Estos modelos están impulsados por los nuevos
métodos de gestión para el cuidado y control de la calidad asistencial, y apoyados por la posibilidad
real de acceder remotamente a la HCE del paciente y a las herramientas de análisis, investigación
y visualización de datos clínicos. Pero, actualmente existen extractos de la historia clínica de un
Introducción 3
paciente allí donde ha recibido alguna vez atención sanitaria (atención primaria, hospitalaria, tele-
medicina, etc.). Todos estos extractos se encuentran repartidos por múltiples sistemas de información
heterogéneos y autónomos y que no son directamente accesibles desde fuera de la organización o
departamento. Esto sigue siendo cierto, incluso en el caso que la institución disponga de sistemas de
historias clínicas electrónicas y la comunicación entre ellos sea de forma electrónica. Los principales
retos de los futuros sistemas de información sanitarios son:
Dar cabida a historias clínicas que engloben toda la vida del paciente (Historia Clínica Elec-
trónica federada)
Interoperabilidad entre todos los agentes (personas y organizaciones) que intervienen en la
atención sanitaria.
Dar soporte a la investigación clínica y sistemas de ayuda a la toma de decisiones.
Permitir que los expertos en el dominio clínico (más que los expertos en tecnologías de la
información) tengan control independiente y directo sobre el diseño de las estructuras de
información.
En los últimos años existe en la comunidad cientí�ca un aumento signi�cativo en el interés por las
HCE como se constata en la presencia creciente de artículos sobre HCE en revistas cientí�cas de
alto impacto no sólo en el ámbito de la informática médica sino en revistas médicas como British
Medical Journal o The Lancet. Por otro lado, existe una gran labor de estandarización en el campo
de las HCE, principalmente los realizados con HL7, CEN, ISO y OMG, así como diversos trabajos
de implementación de sistemas de información sanitarios, algunos con �nanciación pública y otros
restringidos al ámbito universitario. En el ámbito de la investigación existen buenas expectativas
en cuanto al uso extensivo de una HCE, sobre todo basándose en el concepto de HCE distribuida
o federada. Existen problemas, como la captura, integración y presentación de información descrip-
tiva, incompatibilidad de formatos, descripción automática del signi�cado cientí�co y clínico de la
información y la falta de aplicación de estándares para facilitar la cooperación.
Para la representación y el intercambio de la HCE se han propuesto diferentes arquitecturas,
pero la más prometedora es la arquitectura basada en el modelo dual. La principal característica
que ofrece esta arquitectura de modelado es la separación entre la información y el conocimiento.
Por un lado, la información se modela a través de un modelo de referencia (MR) y por otro lado, el
conocimiento se modela usando un modelo de arquetipos (MA). El primer modelo de�ne el conjunto
de clases que representan los bloques de construcción genéricos para una HCE, como por ejemplo,
los conceptos Persona o Sesión Clínica. El segundo permite modelar los conceptos especí�cos del
dominio clínico, como pueden ser la medida del colesterol y de la presión sanguínea [13].
Hoy día hay estándares y especi�caciones basadas en el modelo dual para representar y comunicar
las HCE, como son HL7 [3], openEHR [10] e ISO/EN 13606 [12]. El estándar ISO/EN 13606 es una
norma internacional que se encuentra bastante extendida y aceptada a lo largo de este territorio
y por tanto es el objetivo de este proyecto. Sin embargo, esta norma se caracteriza por la falta
y la necesidad de herramientas que trabajen con este estándar para facilitar su incorporación en
Contexto del Proyecto 4
la práctica clínica. Una herramienta de uso básico sería aquella que proporcionara soporte para
la recogida de datos. Por eso, en este proyecto se pretende ofrecer mecanismos automáticos para
la generación de aplicaciones web que faciliten la recogida de datos y la generación de extractos
compatibles con el estándar ISO/EN 13606 a partir de arquetipos, y las ventajas y posibilidades
posteriores que eso ofrece.
Para �nalizar con esta introducción, se presenta la estructura de la documentación. En el Capí-
tulo 2 se enumeran y describen los objetivos perseguidos, así como la metodología seguida para el
desarrollo del proyecto y el cronograma del mismo. En el Capítulo 3 se describen en profundidad
los conceptos relevantes que se han tenido en cuenta para el desarrollo del proyecto. En el Capítulo
4 se presentan las herramientas y tecnologías utilizadas en el mismo. En el Capítulo 6 se aborda el
diseño de la solución para realizar el generador de aplicaciones web y �nalmente, en el Capítulo 7
se hace un resumen del trabajo realizado y se indican las vías futuras que seguirá.
1.2. Contexto del Proyecto
El presente proyecto �n de carrera ha sido realizado en el marco del proyecto de investigación
ResearchEHR desarrollado por el grupo de investigación TECNOMOD (Tecnologías de modelado,
procesamiento y gestión del conocimiento) de la Universidad de Murcia. El objetivo del proyecto
ResearchEHR es desarrollar una plataforma genérica que permita la compartición de información y
conocimiento dentro del ámbito de un proyecto de investigación clínica. Para ello, se emplean tecno-
logías de la web semántica (ontologías), estándares de comunicación e interoperabilidad semántica
de la historia clínica electrónica (estándar ISO/EN 13606, especi�cación openEHR), terminologías
médicas, técnicas de procesado de lenguaje natural e inteligencia arti�cial. Todo ello permitirá crear
de manera sencilla y automática repositorios de datos clínicos orientados a la investigación enri-
quecidos con información semántica de su contenido. Hasta la fecha, este grupo de investigación ha
producido un conjunto de ontologías en OWL [17], relacionadas con la historia clínica electrónica,
un sistema para transformar arquetipos expresados en ADL a arquetipos en OWL y un sistema para
transformar arquetipos ISO/EN 13606 en arquetipos OpenEHR y viceversa.
Con el desarrollo del presente trabajo se pretende realizar un sistema que genere automáticamente
formularios basados en los arquetipos, de�nidos en el estándar ISO/EN 13606, con el �n de que un
profesional clínico pueda usarlos a la hora de editar la información de la historia clínica del paciente
para conseguir la tan ansiada compartición de la misma usando esta norma europea.
Para realizar el procesamiento de los arquetipos, se ha partido de un trabajo previo [13] realizado
dentro del grupo de investigación que permite procesar un arquetipo ADL y obtener este mismo
arquetipo con signi�cado semántico. A continuación se incluye un breve resumen de cómo se obtienen
los modelos con signi�cado semántico a partir de los arquetipos expresados en ADL, con signi�cado
sintáctico, con el �n de que proporcione una visión global del punto de partida del proyecto.
El proceso para obtener los modelos semánticos de los arquetipos expresados en ADL utiliza
técnicas y herramientas de Ingeniería de Modelos. En un primer paso se representan los arquetipos
como modelos y en un segundo son transformados en modelos semánticos conformes a una ontología.
Capítulo 2
Objetivos y Metodología
2.1. Objetivos
El objetivo principal de este proyecto consiste en desarrollar una herramienta que procese ar-
quetipos ISO/EN 13606, representados en un modelo semántico, para crear automáticamente una
aplicación web que sea usada por personal clínico para generar parte de la historia clínica electró-
nica de un paciente y generar un extracto compatible con el estándar ISO/EN 13606 que facilite la
compartición de la información de la HCE entre distintas organizaciones. Es importante destacar
que esta herramienta es la primera que ofrece esta funcionalidad para el estándar ISO/EN 13606.
El objetivo principal del proyecto abarca los siguientes objetivos secundarios:
1. Análisis e implementación de las restricciones de los tipos de datos y de los componentes de
la jerarquía del modelo de referencia ISO/EN 13606. Al cumplirse este objetivo se obtiene un
estudio de las restricciones de los tipos de datos y la implementación de los artefactos software
necesarios para su validación en un entorno web. Para conseguir este objetivo, se han utilizado
la biblioteca de componentes de RichFaces y las anotaciones que ofrece Hibernate Validator.
2. Diseño de la estructura de las aplicaciones web para obtener extractos de HCE conforme
a arquetipos ADL. Para realizar el diseño de la estructura de las aplicaciones web se han
realizado una serie de prototipos basados en arquetipos concretos de ISO/EN 13606. Estos
prototipos han permitido iterar en el diseño de la arquitectura software de la aplicación web.
3. Implementación de los generadores de las aplicaciones web. El contenido dinámico de las
aplicaciones web ha sido generado utilizando herramientas de transformación modelo a texto
de Ingeniería de Modelos.
2.2. Metodología
El presente proyecto ha seguido una metodología guiada por los subobjetivos que se acaban de
enumerar en la sección anterior (Sección 2.1). De esta forma, estos subobjetivos se han descompuesto
Metodología 6
en tareas.
1. Análisis e implementación de las restricciones de los tipos de datos y de los componentes de
la jerarquía del modelo de referencia ISO/EN 13606.
Tarea 1.1. Recopilación de información. La primera tarea consiste en recopilar, estudiar
y analizar información para tener los conocimientos requeridos para el desarrollo del
presente proyecto y que están relacionados con la historia clínica electrónica, el modelo
dual y los estándares que de�nen la estructura de la HCE. Para ello, se ha reunido
información de diferentes fuentes: desde publicaciones en revistas y congresos relacionados
con informática médica hasta los estándares de�nidos por organizaciones de prestigio,
como son openEHR, HL7 y el Comité Técnico CEN/TC 251.
Tarea 1.2. Estudio e implementación de los tipos de datos y de los componentes de la
jerarquía del modelo de referencia del estándar ISO/EN 13606. Esta tarea es una de
las más importantes del proyecto. En ella se han tenido que tomar decisiones de diseño
para representar los componentes de la jerarquía del MR del estándar ISO/EN 13606
y los tipos de datos del mismo. Estas decisiones han tenido que ver sobre todo con la
representación en las vistas de la aplicación web que tiene que ser generada, de forma que
sean intuitivos y fáciles de usar por los usuarios �nales de la aplicación.
Tarea 1.3. Estudio e implementación de las restricciones de los tipos de datos del estándar
ISO/EN 13606. En esta tarea se ha realizado un análisis riguroso de las restricciones que
se pueden establecer sobre los tipos de datos y de cómo tratarlas en las aplicaciones
web. Estas restricciones han hecho que algunos tipos de datos tengan representanciones
distintas dependiendo de sus restricciones.
2. Diseño de la estructura de las aplicaciones web para obtener extractos de HCE conforme a
arquetipos ADL.
Tarea 2.1. Estudio de los frameworks y herramientas necesarias para el desarrollo de
las aplicaciones web. Se ha realizado un estudio de las herramientas necesarias para el
funcionamiento de la aplicación web. De esta forma, se ha decidido usar una aplicación
cuyas vistas sean desarrolladas con JSF y usando bibliotecas de componentes (RichFaces).
Así mismo, se han utilizado las características del framework Seam para facilitar el uso
de JSF.
Tarea 2.2. Realización de prototipos. Esta etapa ha sido fundamental para el desarrollo
del proyecto. En ella se han realizado varios prototipos completamente funcionales de
ejemplos de arquetipos de�nidos para ISO/EN 13606 con el �n de conseguir determinar
la estructura de la aplicación web que se debía generar. Esta fase ha servido para detectar
la parte estática de la aplicación web, las clases Java que necesitaban ser generadas y el
diseño de las vistas. Tras la validación del diseño de varios prototipos, se ha comenzado
la fase de los generadores.
3. Implementación de los generadores de las aplicaciones web.
Metodología 7
Tarea 3.1. Generación de la estructura del árbol de la aplicación web. En esta etapa
ya comienza la generación automática y tiene como objetivo la de generar un �chero
de propiedades con la estructura del arquetipo que se está procesando para generar su
aplicación web.
Tarea 3.2. Generación de las clases Java de la aplicación web. Esta etapa ha sido una de
las más costosas y largas del proyecto, porque ha sido necesario generar todas las clases
Java de la aplicación web. Para ello, se ha utilizado la herramienta MOFScript y se han
de�nido reglas para ir mapeando los distintos componentes jerárquicos y tipos de datos
del modelo semántico del arquetipo a clases Java. En esta tarea se ha ido generando la
creación del extracto compatible con el estándar ISO/EN 13606.
Tarea 3.3. Generación de las vistas de la aplicación. En esta fase se han generado todas
las vistas de la aplicación, también con MOFScript, mapeando la estructura de�nida
por los componentes jerárquicos del MR del estándar y los formularios de�nidos por la
representación de los tipos de datos del mismo estándar en las vistas de la aplicación.
Tarea 3.4. Creación de un script en Ant que permita generar las aplicaciones de forma
automática.
Tarea 3.5. Validación y veri�cación de las aplicaciones web generadas. Esta fase ha consis-
tido en comprobar la corrección y validez de las aplicaciones web generadas. Es importante
indicar que tras esta fase, ha sido necesario volver a las etapas de generación de la apli-
cación web e incluso ir modi�cando el diseño de la aplicación para ir resolviendo errores
y problemas que iban sucediendo hasta que hemos obtenido un resultado satisfactorio.
Hay otra tarea que no forma parte de los subobjetivos y que tiene que ver con la documentación.
A esta tarea se le ha dado el identi�cador 4.1 y está dedicada a realizar la memoria del proyecto.
Cronograma del proyecto 8
2.3. Cronograma del proyecto
En la Figura 2.1 se muestra el cronograma del proyecto. En este cronograma, se han representado
las tareas que se han descrito en la Sección2.2, con la fecha de inicio y la fecha de �n de las mismas,
las semanas que han ocupado y el tiempo en horas dentro de cada semana. También contiene un
total de horas por tareas, por semanas y un total acumulado.
Figura 2.1: Cronograma del proyecto
Capítulo 3
Historia Clínica Electrónica
Para que un profesional sanitario pueda desarrollar su labor debe disponer de toda la información
clínica de sus pacientes. Cuando dicha información se encuentra en soporte informático hablamos
de Historia Clínica Electrónica (HCE).
La HCE, como elemento integrador de los datos sanitarios y fuente de información para los
profesionales, es un elemento esencial de un sistema sanitario e�ciente y de calidad. Tener reunidos
todos los datos del paciente y actualizados con toda la información que se obtiene es un objetivo
estratégico desde el punto de vista asistencial, de gestión y de investigación.
Ningún profesional del mundo de la sanidad duda ya de la prioridad de dirigirse hacia una HCE
en la que estén informatizados e integrados los documentos que contienen datos, valoraciones e
informaciones de cualquier índole sobre la situación y la evolución clínica de un paciente a lo largo
del proceso asistencial.
Las ventajas de utilizar una HCE son claras, debido a que las historias clínicas tradicionales
plantean di�cultades como el desorden y la falta de uniformidad en los documentos, así como la
inclusión de información muchas veces ilegible e inalterable y con una disponibilidad cuestionable.
Por otro lado, es bastante frecuente que se produzcan errores de archivado en estas historias clínicas
tradicionales, poniendo en duda su garantía de con�dencialidad. Además, hay que sumar el deterioro
del soporte documental que experimentan, así como la di�cultad para separar los datos de �liación
de los clínicos.
3.1. Arquitectura del Modelo Dual
En general, un sistema de HCE es una estructura compleja. Desde principios de los años 90, se
detectó la necesidad de una representación genérica para la comunicación de registros clínicos de
historias clínicas entre sistemas. En Europa dio lugar a una sucesión de proyectos de I+D �nanciados
por la Comisión Europea y a varias generaciones de normas del Comité Europeo de Normalización
(CEN) producidas por el Comité Técnico 251 (TC251) antes de que la propuesta CEN ENV13606
se conviertiera en estándar ISO.
Arquitectura del Modelo Dual 10
Estos proyectos y estándares se han dirigido a de�nir las características genéricas de información
de HCE e incorporarlas a modelos de información y modelos de mensajes que pudieran proveer una
interfaz estándar entre sistemas clínicos. De esta manera, se ha pretendido facilitar que diversos
sistemas clínicos pudieran intercambiar la totalidad o parte de la HCE de un paciente de forma
estandarizada.
La mayoría de los sistemas de información sigue una metodología basada en un modelo de un
solo nivel (Figura 3.1). En este modelo, los conceptos de dominio (o también llamados entidades de
negocio) se modelan directamente en software a través del modelado de casos de uso u otras técnicas
de desarrollo de software.
Figura 3.1: Arquitectura del modelo de un solo nivel.
El sistema de la izquierda de la �gura crea la información como instancias de las entidades
de negocio, la almacena, la transmite y la transforma para que sea entendible por las personas o
por otros sistemas de información. La base de datos, el software y la interfaz de usuario (que se
encuentran en el centro de la �gura) se desarrollan siguiendo un enfoque orientado a objetos o un
enfoque relacional que describe de manera formal la semántica del sistema de información. Con
este enfoque, la mayoría de los sistemas relacionales u orientados a objetos traducen directamente
los conceptos del dominio a código. Por ejemplo, el concepto Persona se modela con una serie de
atributos explícitos, como nombre, dirección, etc. Cuando la complejidad del dominio es baja y
exige pocos cambios esta aproximación es buena. Sin embargo, en dominios más complejos, como el
de la medicina, los cambios son frecuentes por lo que sería más apropiado usar lo que denominamos
un modelo dual.
El enfoque dual (Figura 3.2) [1] de�ne una aproximación alternativa para separar la información
y el conocimiento en dos niveles de modelado. El primer nivel es el de los modelos de los objetos y
los esquemas de las bases de datos y se conoce como modelo de referencia (MR). El MR debe tener
un tamaño pequeño para que sea comprensible y contener sólo conceptos no volátiles para que sea
Arquitectura del Modelo Dual 11
mantenible. El segundo nivel es el nivel de conocimiento, que necesita sus propios formalismos y
estructura, donde se expresan los conceptos más volátiles del dominio. Este nivel es el del modelo de
arquetipos (AM), donde un arquetipo se de�ne como un modelo formal de un concepto clínico en uso
y es de�nido usando un lenguaje de de�nición de arquetipos (ADL). Este lenguaje proporciona una
sintaxis concreta para expresar los arquetipos con un lenguaje textual. Para ver la diferencia entre
la información y el conocimiento, se presenta el siguiente ejemplo. La información sería: �Pedro
Martínez tiene una presión sanguínea de 110/80� y el conocimiento: �La presión sanguínea consta
de dos medidas: sistólica (la alta) y diastólica (la baja), cada una se mide en mmHg y tiene un
protocolo asociado para medirla�.
Siguiendo este enfoque, la información se estructura a través de un Modelo de Referencia (MR)
y el conocimiento se representa utilizando un Modelo de Arquetipos (MA).
Figura 3.2: Arquitectura del modelo dual.
El Modelo de Referencia es un modelo orientado a objetos que se utiliza para representar las
propiedades genéricas y estables de la información contenida en cualquier HCE. Es el encargado de
codi�car la información pero no determina cómo debe presentarse o almacenarse. Pueden existir
diferentes MR adaptados a diferentes objetivos o diseñados bajo distintas perspectivas. En este
trabajo se ha utilizado una adaptación del modelo de referencia del estándar ISO/EN 13606, que
está orientado a la representación de documentos clínicos.
El Modelo de Arquetipos representa el nivel de conocimiento y está formado por un conjunto de
de�niciones de arquetipos que representan formalmente diversos conceptos clínicos construidos en
base a entidades de un MR concreto. Un arquetipo de�ne formalmente un concepto clínico, como
por ejemplo un informe de alta, un análisis de glucosa o la historia clínica. Se utiliza el lenguaje
ADL como lenguaje de representación de dichos arquetipos.
En el centro de la �gura se encuentra el sistema encargado de almacenar y comunicar la infor-
mación. Los modelos de software y de bases de datos que implementan el modelo de referencia, no
Estándares de Historia Clínica Electrónica 12
ocupan mucho espacio y no son volátiles. Los conceptos que representan la semántica del sistema se
encuentran a la izquierda de la �gura en lo que denominamos biblioteca de conceptos. Los modelos
formales o lenguajes (ADL) en los que se expresan dichos conceptos se encuentran incluidos en la
parte derecha de la �gura en lo que se denomina entorno de desarrollo técnico.
Las arquitecturas de HCE basadas en un modelo dual fueron pensadas en un principio para
la implantación de nuevos sistemas de información sanitarios pero como se puede deducir también
pueden utilizarse como base de un sistema para la integración y estandarización de la información.
3.2. Estándares de Historia Clínica Electrónica
Actualmente existen diversos estándares sobre HCE como HL7, openEHR o ISO/EN 13606.
Cada uno de ellos de�ne sus propios modelos de información y los gestiona de forma distinta. Estos
tres estándares tienen una caracteristica en común: siguen la arquitectura del modelo dual. En
este apartado, se hará un breve repaso a estos tres estándares, para centrarnos posteriormente en el
estándar ISO/EN 13606 que es con el que se trabaja en el desarrollo del presente proyecto.
3.2.1. Estándares HL7
El estándar HL7 ha sido desarrollado por la organización HL7. Dicha organización fue fundada
en 1987 en los Estados Unidos y se caracteriza por ser una organización sin ánimo de lucro, de-
sarrolladora de estándares acreditados por ANSI para proporcionar un framework que permita el
intercambio, la integración, la compartición y la recuperación de la información clínica electrónica
con el �n de apoyar a la práctica y a la gestión clínica, al desarrollo y a la evaluación de los servicios
de salud [3].
Este estándar está enfocado al intercambio de datos entre aplicaciones (facilitando el desarrollo
de interfaces). Sin embargo, la creciente necesidad de generar sistemas de información integrados
regionalmente hizo necesario el desarrollo de una gama más amplia de estándares que faciliten la
interoperabilidad.
Por esta razón, en la actualidad la organización HL7 cuenta con un proceso para de�nir una
serie de herramientas de interoperabilidad (mensajes, documentos electrónicos, reglas, modelos de
referencia) que ha dado origen a varios estándares que facilitan los procesos de intercambio de
información de salud. Por este motivo, hoy día se habla de estándares HL7. Algunos de estos
estándares son:
Mensajería HL7 v2: estándar de mensajería para el intercambio electrónico de datos de salud.
Mensajería HL7 v3: estándar de mensajería para el intercambio electrónico de datos de salud
basada en el modelo de referencia de HL7 (RIM)
CDA HL7 (Clinical Document Architecture): estándar de arquitectura de documentos clínicos
electrónicos.
Estándares de Historia Clínica Electrónica 13
SPL HL7 (Structured Product Labeling): estándar electrónico para el etiquetado de medica-
mentos.
HL7 Medical Records: estándar de administración de registros médicos.
GELLO: estándar para la expresión de reglas de soporte de decisiones clínicas.
Arden Sintax: estándar sintáctico para compartir reglas de conocimiento clínico.
CCOW: estándar framework para compartir contexto entre aplicaciones.
El estándar relacionado con la arquitectura de las HCE es el CDA HL7. Este estándar fue publicado
en 2005 y como otros estándares, está basado en un modelo de referencia (RIM) y está diseñado para
capturar información en un documento y ser almacenada en sistemas de HCE. Esta información
estructurada también puede ser guardada y usada en diferentes sistemas, usando terminologías
médicas como SNOMED y LOINC [5].
3.2.2. Estándar openEHR
Este segundo estándar ha sido desarrollado por la fundación openEHR, que es una fundación
sin ánimo de lucro, creada para permitir el desarrollo de especi�caciones, software y recursos de
conocimiento para los sistemas de información de la salud [10]. La fundación openEHR está dedicada
al desarrollo de una plataforma abierta e interoperable para la informática en la salud, de la cual
su componente más importante es la HCE. Logra esto investigando requisitos clínicos y creando
especi�caciones e implementaciones. Las especi�caciones son modelos modulares que toman la
forma de modelos de información, modelos de servicios y modelos clínicos de información.
La fundación openEHR trabaja en dos amplias áreas de actividad: la técnica y la clínica. En el
área técnica es donde se hace el trabajo de ingeniería, incluyendo especi�caciones, implementaciones,
pruebas y conformidad. En el área clínica es donde los profesionales y las organizaciones del dominio
de la salud participan con openEHR, incluyendo el desarrollo y despliegue de ontologías, arquetipos,
templates, además de educación clínica y entrenamiento.
En la práctica, los proyectos de openEHR se agrupan en cuatro grandes ramas referentes a:
Especi�caciones conceptuales y de tecnologías de la implementación.
Implementaciones de código abierto, con la garantía que conforman alguna versión de las
especi�caciones.
Conocimiento clínico en los que se desarrollan arquetipos para todos los aspectos de la atención
de la salud, basados principalmente en el modelo de referencia.
Herramientas para crear y manipular artefactos clínicos del conocimiento tales como arquetipos
y terminologías.
Estándares de Historia Clínica Electrónica 14
Todos estos proyectos son sumamente importantes, pero cabe resaltar que el más importante es el
proyecto de especi�caciones ya que produce las especi�caciones formales en las que se basa la inicia-
tiva openEHR. La Figura 3.3 muestra los principales artefactos del proyecto de especi�caciones. Este
proyecto consta de requerimientos, especi�caciones arquitectónicas, tecnologías de implementación
(ITSs) y especi�caciones de conformidad.
Figura 3.3: Especi�caciones de openEHR.
Las especi�caciones de la arquitectura están constituidas por el Modelo de Referencia (RM),
el Modelo de Arquetipos (AM) y el Modelo de Servicios (SM). Dentro del Modelo de Arquetipos
destacan el Lenguaje de De�nición de Arquetipos (ADL), el Modelo de Objetos de Arquetipos
(AOM) y los Per�les de Arquetipos de openEHR (oAP) [8].
El Modelo de Referencia en openEHR es uno de los modelos más importantes de la especi�cación,
pues se encarga de describir la HCE en sí misma, no los datos clínicos que contiene. Es el primer
nivel de la arquitectura dual del estándar y proporciona soporte a los requisitos médico-legales y a
las funciones de gestión de almacenamiento de la HCE [11].
El otro modelo fundamental de openEHR es el Modelo de Arquetipos, de donde hay que destacar
la importancia de los templates, ya que permiten usar los arquetipos en tiempo de ejecución. Un
template es un árbol de arquetipos, cada uno de ellos restringiendo instancias de distintas partes
del modelo de referencia.
3.2.3. Estándar ISO/EN 13606
El estándar ISO/EN 13606 es una Norma Europea que ha sido elaborada por el Comité Técnico
CEN/TC 51 de Informática Sanitaria y surgió para sustituir la Norma Europea Experimental ENV
13606-1.
La meta global de esta norma europea es de�nir una arquitectura de información rigurosa y
estable para comunicar parte o toda la HCE de un único sujeto de la asistencia (paciente). Esto es
para dar soporte a la interoperabilidad de sistemas y componentes de los datos de la HCE que es
necesario comunicar.
Este estándar se compone de cinco partes bien diferenciadas [15]:
Parte 1: Modelo de referencia. Este modelo describe las características estables de una HCE.
El Modelo de Referencia de la Norma ISO/EN 13606 15
Las instancias de este modelo contienen los contenidos de una HCE que son intercambiados.
Parte 2: Especi�cación del intercambio de arquetipos. Esta parte especi�ca el Modelo de
Arquetipos (MA) y el Lenguaje de De�nición de Arquetipos (ADL) para especi�car instancias
de los arquetipos.
Parte 3: Arquetipos de referencia y listas de términos. Algunos atributos de�nidos en el
Modelo de Referencia usan valores que tienen que ser seleccionados de listas de términos que
están descritas en esta parte.
Parte 4: Seguridad. Esta parte describe la metodología para especi�car los privilegios nece-
sarios para acceder a los datos de una HCE.
Parte 5: Mensajes para el intercambio. Especi�ca los mensajes para intercambiar información
de una HCE entre grupos de salud responsables de proporcionar un cuidado clínico para un
paciente individual.
3.3. El Modelo de Referencia de la Norma ISO/EN 13606
El Modelo de Referencia (MR) representa las características globales de los componentes de la
historia clínica, cómo se agregan, y la información de contexto requerida para cumplir los requisitos
éticos, legales y de procedencia. Este modelo de�ne el conjunto de clases que forman los componentes
básicos genéricos de la HCE, es decir, re�eja las características estables de una HCE.
El MR de�ne los componentes jerárquicos principales del extracto de HCE. Estos componentes y
la relación establecida entre ellos se pueden observar en la Figura 3.4 y se realizará una descripción
de los mismos a continuación.
Figura 3.4: Diagrama de la jerarquía del Extracto de la HCE
El Modelo de Arquetipos de la Norma ISO/EN 13606 16
EHR_EXTRACT (Extracto de HCE): es el contenedor de más alto nivel de parte o toda la
HCE de un único sujeto de la asistencia, para la comunicación entre un sistema proveedor de
la HCE y un receptor de la HCE.
FOLDER (Carpeta): la organización de alto nivel dentro de una HCE, que la divide en com-
partimentos relativos a la asistencia prestada para una única condición, por un equipo o
institución clínica, o durante un tiempo �jado tal como un episodio de asistencia. Ejemplos
de carpeta podrían ser: atención a diabetes, esquizofrenia, pediatría, Hospital Reina Sofía,
Episodios 2000-01, etc.
COMPOSITION (Composición): el conjunto de información grabada en una HCE por un
agente, como resultado de un único encuentro clínico o una sesión de documentación de la
historia. Ejemplos de composición podrían ser: nota de evolución, formulario de resultado de
pruebas de laboratorio, informe radiológico, impreso de derivación, visita clínica, informe de
alta, etc.
SECTION (Sección): datos de la HCE dentro de una composición perteneciente a una cabecera
clínica, que usualmente re�eja el �ujo de información reunido durante un encuentro clínico, o
estructurado para una más bene�ciosa lectura futura. Ejemplos de sección serían: antecedentes,
información de alergias, hallazgos objetivos, dieta, análisis, examen de la retina, etc.
ENTRY (Entrada): la información registrada en una HCE como resultado de una acción clínica,
una observación, una interpretación clínica o un propósito clínico. Esto se conoce también como
declaración clínica. Ejemplos de entrada serían: síntoma, observación, medicamento prescrito,
recuento de leucocitos, etc.
CLUSTER (Grupo): estructura de datos para organizar otros elementos tales como las series
temporales, y para representar las columnas de una tabla. Ejemplos de clusters son: resultados
de un audiograma, interpretación de un encefalograma, diagnósticos diferenciales ponderados,
etcétera.
ELEMENT (Elemento): representa el valor de un dato en la HCE. Ejemplos de elemento son:
presión sanguínea sistólica, ritmo cardíaco, nombre de medicamento, síntoma, peso del cuerpo,
etc.
3.4. El Modelo de Arquetipos de la Norma ISO/EN 13606
3.4.1. Arquetipos
Formalmente, un arquetipo es una de�nición de una estructura de información utilizada en un
dominio particular y que está basada en un Modelo de Referencia.
En el ámbito clínico, un arquetipo se de�ne como un modelo formal de un concepto clínico en
uso. Un ejemplo de arquetipo clínico podría ser una condición genética de�nida por un profesional
sanitario. La de�nición de dicho arquetipo contendría la siguiente información: el nombre de la
El Modelo de Arquetipos de la Norma ISO/EN 13606 17
condición genética, la fecha de manifestación, la edad a la que se manifestó, la gravedad, la descrip-
ción clínica, la fecha en la que se reconoció, la localización, las complicaciones, la fecha y la edad
a la que se resolvió y los posibles enlaces a sitios web que describan aspectos relevantes sobre esta
condición genética.
Toda esta información debería estar presente cuando un médico evalúe en un paciente una condi-
ción de este tipo. Cada elemento de los anteriormente enumerados puede ser simple, como la
descripción clínica, o complejo, como las complicaciones que pueden ser descritas mediante el nom-
bre del problema concreto y una descripción del mismo. A su vez, estos elementos pueden tener
una serie de restricciones asociadas. Por ejemplo, la severidad de una condición genética puede
tomar un valor dentro de un rango {leve, moderada, severa} o las fechas incluidas en el arquetipo
se representarán con un formato que incluya el año y el mes.
Los arquetipos clínicos se construyen normalmente por expertos del dominio, por lo que se basan
en conocimiento clínico y de�nen con�guraciones válidas de los datos. Los profesionales sanitarios
hacen uso de ellos para controlar y validar los datos obtenidos de los pacientes y para guiar el proceso
de examen. Constituyen un intento de estandarización de la práctica clínica.
La construcción de arquetipos en el ámbito clínico plantea la necesidad de dar soporte a ciertos
aspectos de mantenimiento de diferentes versiones o a contemplar la especialización y la composición
de éstos. El ámbito clínico es un ámbito cambiante que recibe constantemente resultados de nuevas
investigaciones clínicas. Es por ello que la construcción de arquetipos tiene que tener en cuenta este
aspecto y permitir manejar y de�nir diferentes versiones. Permitir su reutilización es también algo
obviamente positivo para preservar el esfuerzo y el tiempo empleados e incrementar la productividad.
De esta manera algunos arquetipos pueden ser de�nidos como extensiones o especializaciones de
otros existentes. Por ejemplo, la de�nición de cierta condición genética puede ser vista como la
especialización de un arquetipo que representa problemas genéricos. Éste es otro aspecto que debe
considerarse en el manejo de arquetipos. Finalmente, algunos de ellos pueden ser partes estructurales
de otros. En este caso, los mecanismos para manejar esta estructura deben proporcionarse también.
3.4.2. Lenguaje de de�nición de arquetipos (ADL)
El lenguaje de de�nición de arquetipos ADL es un lenguaje creado para representar formalmente
los arquetipos. Un documento ADL se de�ne como un �chero estructurado de texto cuya estructura
es independiente de un dominio o estándar particular.
ADL no es un lenguaje de�nido exclusivamente para el ámbito clínico, pues puede usarse para
de�nir cualquier tipo de arquetipo. Sin embargo, a nosotros nos interesa como lenguaje de descrip-
ción de arquetipos clínicos.
Un arquetipo ADL está compuesto principalmente de tres partes: cabecera o descripción, de�ni-
ción y ontología. La sección de descripción incluye información de auditoría: autor/es, estado y
propósito. La parte de de�nición contiene la de�nición formal principal del arquetipo. Está com-
puesta por una serie de restricciones en forma de árbol creadas a partir del modelo de referencia
que de�nen y restringen la estructura del concepto clínico. En el siguiente código se puede observar
la parte de de�nición del arquetipo que representa el concepto clínico del colesterol descrito según
El Modelo de Arquetipos de la Norma ISO/EN 13606 18
el modelo de referencia del estándar ISO/EN 13606. Vemos que está formado por una ENTRY que
posee una lista de items. En este caso, sólo se ha de�nido un item, el elemento ELEMENT, cuyo
valor se encuentra en el rango [0, 1000] y se mide en mg/dl.
definition
ENTRY[at0000] occurrences matches {1..1} matches {
items cardinality matches {0..1} matches{
ELEMENT[at0001] ocurrences matches {0..1} matches {
value matches {
PQ occurrences matches {1..1} matches {
units matches {
CS matches {
codeValue matches {"mg/dl"}
}
}
value matches {|0.0..1000.0|}
}
}
}
}
}
ADL es un lenguaje bastante �exible ya que la misma estructura puede utilizarse para especi�car
arquetipos basados en distintos modelos de referencia, sin embargo, estamos hablando de la misma
estructura sintáctica pero no semántica. Por lo tanto, este mismo arquetipo puede representarse
para el estándar openEHR y sólo la parte de de�nición sufrirá unos pocos cambios ya que los tipos
de datos y los elementos que de�nen la estructura son distintos.
La parte de la ontología incluye la de�nición terminológica y los posibles enlaces de los términos
que aparecen en el arquetipo en diferentes terminologías. Como vemos en el siguiente código, para el
caso del colesterol en ISO/EN 13606 se proporciona la descripción de los términos at0000 y at0001.
ontology
primary_language = <"es">
languages_availabe = <"es", ...>
term_definitions = <
["es"] = <
items = <
[" at0000 "] = <
text = <"Colesterol">
description = <"*">
>
>
>
>
El Modelo de Arquetipos de la Norma ISO/EN 13606 19
3.4.3. Lenguaje de Restricciones de ADL (cADL)
cADL es un lenguaje para la de�nición de restricciones sobre datos de�nidos por un modelo de
referencia. Estas restricciones pueden ser incluidas en arquetipos o en otros formalismos de de�nición
de conocimiento, de tal manera que puedan emplearse tanto por los diseñadores, para modelar los
conceptos de un dominio, como por los sistemas de información en tiempo de ejecución con el �n
de que se puedan validar unos datos determinados contra un modelo concreto. El siguiente ejemplo
muestra el aspecto general de cADL.
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 para de�nir 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. También se indica que puede tener 0 o
muchas direcciones.
La estructura general de las restricciones escritas en cADL es anidada. Siempre se comienza
expresando las restricciones sobre un tipo. Estas restricciones se de�nen a su vez por medio de res-
tricciones sobre las propiedades (atributos) del tipo original. Las restricciones sobre las propiedades
se de�nen 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.
Ú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 predominar
sobre 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.
Capítulo 4
Tecnologías utilizadas
4.1. JavaServer Faces
La tecnología JavaServer Faces (JSF) es un marco de trabajo de interfaces de usuario del lado
de servidor para aplicaciones web basadas en tecnología Java.
Los principales componentes de la tecnología JavaServer Faces son:
Un API y una implementación de referencia para:
• Representar componentes de interfaz de usuario (UI) y manejar su estado.
• Manejar eventos, realizar validaciones en el lado del servidor y convertir datos.
• De�nir la navegación entre páginas.
• Soportar internacionalización y accesibilidad y proporcionar extensibilidad para todas
estas características.
Una biblioteca de etiquetas JavaServer Pages (JSP) personalizadas para dibujar componentes
UI dentro de una página JSP.
Este modelo de programación bien de�nido junto con la biblioteca de etiquetas para componentes
UI facilitan de forma signi�cativa la tarea de la construcción y mantenimiento de aplicaciones web
con UIs del lado del servidor. Con un mínimo esfuerzo, podemos:
Conectar eventos generados en el cliente a código de la aplicación en el lado del servidor.
Mapear componentes UI a una página de datos del lado del servidor.
Construir un UI con componentes reutilizables y extensibles.
Grabar y restaurar el estado del UI más allá de la vida de las peticiones de servidor.
JavaServer Faces 21
Como se puede apreciar en la Figura 4.1, el interfaz de usuario que creamos con la tecnología
JavaServer Faces (representado por myUI en el grá�co) se ejecuta en el servidor y se renderiza en
el cliente.
Figura 4.1: Petición/respuesta de una página JSP que incluye etiquetas JSF
La página JSP, Myform.jsp, dibuja los componentes del interfaz de usuario con etiquetas per-
sonalizadas de�nidas por la tecnología JavaServer Faces. El UI de la aplicación Web (representado
por myUI en la imagen) maneja los objetos referenciados por la página JSP:
Los objetos componentes que mapean las etiquetas sobre la página JSP.
Los listeners de eventos, validadores, y los conversores que está registrados en los componentes.
Los objetos del modelo que encapsulan los datos y las funcionalidades de los componentes
especí�cos de la aplicación.
Una de las grandes ventajas de la tecnología JavaServer Faces es que ofrece una clara separación
entre el comportamiento y la presentación. Las aplicaciones web construidas con tecnología JSP con-
seguían parcialmente esta separación. Sin embargo, una aplicación JSP no puede mapear peticiones
HTTP al manejo de eventos especí�cos de componentes o manejar elementos UI como objetos con
estado en el servidor. La tecnología JavaServer Faces nos permite construir aplicaciones web que
implementen una separación entre el comportamiento y la presentación tradicionalmente ofrecidas
por la arquitectura UI del lado del cliente.
La separación de la lógica de la presentación también permite a cada miembro del equipo de
desarrollo de una aplicación web centrarse en su parte del proceso de desarrollo, y proporciona un
modelo sencillo de programación para enlazar todas las piezas. Por ejemplo, los autores de páginas
web sin experiencia en programación pueden usar las etiquetas de componentes UI de la tecnología
JavaServer Faces para enlazar código de la aplicación desde dentro de la página web sin escribir
ningún script.
JavaServer Faces 22
Otro objetivo importante de la tecnología JavaServer Faces es mejorar los conceptos familiares
de componente UI y capa web sin limitarnos a una tecnología de script particular o a un lenguaje de
marcas. Aunque la tecnología JavaServer Faces incluye una biblioteca de etiquetas JSP personaliza-
das para representrar componentes en una página JSP, las APIs de la tecnología JavaServer Faces
se han creado directamente sobre el API JavaServlet. Esto nos permite hacer algunas cosas, como
por ejemplo, usar otra tecnología de presentación junto a JSP, crear nuestros propios componen-
tes personalizados directamente desde las clases de componentes o generar salidas para diferentes
dispositivos cliente.
En resumen, el aspecto más destacado de JSF es que proporciona una arquitectura rica para
manejar el estado de los componentes, procesar los datos, validar la entrada del usuario, y manejar
los eventos.
4.1.1. Estructura de una aplicación web con JSF
En su mayoría, las aplicaciones JavaServer Faces son como cualquier otra aplicación web Java.
Se ejecutan en un contenedor Servlet Java, y típicamente contienen:
Componentes JavaBeans (llamados objetos del modelo en tecnología JavaServer Faces) conte-
niendo datos y funcionalidades especí�cas de la aplicación.
Listeners de eventos.
Páginas web, como páginas JSP.
Clases de utilidades del lado del servidor, como beans para acceder a las bases de datos.
Además de estos items, una aplicación JavaServer Faces también tiene:
Una biblioteca de etiquetas personalizadas para dibujar componentes UI en una página.
Una biblioteca de etiquetas personalizadas para representar manejadores de eventos, valida-
dores, y otras acciones.
Componentes UI representados como objetos con estado en el servidor.
Validadores, manejadores de eventos y manejadores de navegación.
4.1.2. Modelo-Vista-Controlador
Modelo-Vista-Controlador (MVC) es un patrón arquitectónico muy usado en ingeniería del soft-
ware y cuya función es separar la lógica de negocio de la capa de presentación, permitiendo que
el desarrollo, las pruebas y el mantenimiento se realicen de forma independiente. Este patrón es
típico de las aplicaciones web, donde las vistas son páginas HTML o XHTML y el controlador es el
código que reúne los datos dinámicos y que genera el contenido de las páginas HTML o XHTML.
Finalmente, el modelo está representado por los objetos de negocio, que son almacenados en una
JavaServer Faces 23
base de datos o en nodos XML, y son las reglas de negocio las encargadas de transformar estos
objetos, basadas en las acciones del usuario.
Una de las ventajas clave de JSF es que sigue este patrón arquitectónico (Figura 4.2). Esto
hace que las aplicaciones JSF sean mucho más mantenibles porque el código de interfaz de usuario
(vista) está claramente separado de la lógica y de los datos de la aplicación (modelo). Para preparar
el contexto JSF que proporciona el acceso de las páginas a los datos de la aplicación y que evita
los accesos a las páginas no autorizadas, todas las interacciones del usuario con la aplicación son
manejadas por el servlet �Faces� (controlador) [16].
Figura 4.2: Modelo-Vista-Controlador de JSF
4.1.3. RichFaces
RichFaces es un framework y una biblioteca de componentes JSF de código abierto que añade
capacidades AJAX a aplicaciones JSF existentes sin recurrir a JavaScript. RichFaces permite:
Mejorar los bene�cios de JSF. RichFaces está completamente integrado en el ciclo de vida JSF.
Mientras otros marcos de trabajo sólo dan acceso a facilidades de gestión de beans, RichFaces
permite acceder a la acción y al listener, así como invocar validadores y conversores en la parte
del servidor durante el ciclo de petición-respuesta de AJAX.
Incorporar capacidades AJAX a las aplicaciones JSF existentes. El marco de trabajo propor-
ciona dos bibliotecas de componentes (Core AJAX y UI). La biblioteca Core permite añadir
funcionalidad AJAX en las páginas existentes, de modo que no hay necesidad de escribir
ningún código JavaScript o de reemplazar componentes existentes con nuevos componentes
AJAX. RichFaces permite de�nir un evento en la página.
Facilita la implementación de componentes propios. RichFaces incluye un entorno de desarrollo
con facilidades para la generación de código y el uso de plantillas usando una sintaxis tipo
JSP. Estas capacidades ayudan a prevenir un proceso rutinario de creación de componentes.
Generar recursos binarios con facilidad, como imágenes, sonidos, hojas de cálculos Excel, etc.
Framework de desarrollo para JSF: Seam Framework 24
Crear una interfaz de usuario con tecnología basada en skins. Se permite de�nir y manejar
diferentes esquemas de color y otros parámetros de la UI. Existen inicialmente un conjunto de
skins prede�nidas para empezar pero se pueden crear fácilmente skins personalizadas.
Crear y probar componentes, acciones, listeners y páginas al mismo tiempo. En el futuro se
podrán generar casos de prueba para los componentes que desarrolla el usuario. Esto no sólo
testeará los componentes, sino también otras funcionalidades del lado del servidor o del cliente
incluyendo código JavaScript.
4.2. Framework de desarrollo para JSF: Seam Framework
Seam es una plataforma de desarrollo de código abierto que sirve para construir aplicaciones web
en Java. Seam integra tecnologías como AJAX, JavaServer Faces (JSF), Persistencia Java (JPA),
Enterprise Java Beans (EJB 3.0) y Gestión del Procesos de Negocio (BPM) dentro de una solución
uni�cada.
A continuación vamos a citar las características del framework que han sido utilizadas en este
proyecto.
Conversaciones. Seam introduce el contexto de conversación web. Una conversación web pro-
porciona un control más re�nado sobre el ámbito tradicional de una sesión web, permitiendo
que conversaciones concurrentes puedan ocurrir en una misma sesión HTTP, que usualmente
ocurre cuando los usuarios abren otra ventana del navegador u otra pestaña. Esta caracterís-
tica ha sido fundamental en el desarrollo del proyecto, pues la herramienta de generación de
formularios evolucionará a una aplicación que recoja todos los formularios de los arquetipos
que se generen. De esta forma, se podría gestionar que un médico estuviera editando distin-
tos formularios a la vez porque cada uno de ellos se almacenaría en el contexto de su propia
conversación web dentro de la misma sesión y no habría interferencias entre ellos.
Anotaciones. Cuando se está desarrollando una aplicación en Seam, es posible usar una gran
variedad de anotaciones en el código fuente. En el presente proyecto, se han usado dos tipos
de anotaciones: las proporcionadas por Hibernate Validator y las proporcionadas por Seam.
• Las anotaciones para la validación de los datos se de�nen con Hibernate Validator. Hi-
bernate Validator es una implementación del JSR 303 (Bean Validation). Esta implemen-
tación permite expresar restricciones del dominio y asegurar su cumplimiento en varios
niveles de nuestro sistema de forma automática. Las anotaciones son una forma muy
conveniente y elegante para especi�car las restricciones invariantes de la implementación
del modelo del dominio. En este proyecto, estas anotaciones han permitido comprobar
de forma sencilla y cómoda las restricciones sobre los campos de los formularios, como
por ejemplo, la restricción de si un campo concreto cumple un patrón, si su longitud es
la adecuada, si es un campo obligatorio, ...
• Por otro lado, las anotaciones proporcionadas por Seam permiten realizar una gran va-
riedad de acciones sobre una aplicación web. Hay distintos tipos de anotaciones, pero las
Desarrollo de Software Dirigido por Modelos 25
que se han usado en el desarrollo de este proyecto son las relacionadas con la de�nicion
de componentes. Estas anotaciones se encargan, entre otras muchas funciones, de de�nir
un nombre para cada clase que es requerido por Seam y que servirá para instanciar esta
clase desde la vista de la aplicación y de de�nir el contexto por defecto del componente.
Es con una anotación de Seam cuando se le indica a la clase que su ámbito se encuentra
dentro de una conversación web.
4.3. Desarrollo de Software Dirigido por Modelos
El Desarrollo de Software Dirigido por Modelos (DSDM) o Ingeniería de Modelos es una prop-
uesta para el desarrollo de software en la que los modelos juegan el papel principal de todo el proceso,
frente a las propuestas tradicionales basadas en lenguajes de programación y plataformas de objetos
y componentes software.
En la Ingeniería de Modelos, cualquier artefacto software puede ser tratado o representado como
un modelo: ontologías, esquemas relacionales, esquemas XML, etc. Un modelo describe una realidad
física, abstracta o hipotética, recogiendo únicamente la información necesaria que permite conseguir
unos objetivos especí�cos como pueden ser la generación de código, integración de aplicaciones,
interoperabilidad entre aplicaciones, etc. Trabajar directamente sobre modelos aumenta el nivel de
abstracción de estas tareas y permite automatizarlas.
4.3.1. Metamodelado y lenguajes de metamodelado
El metamodelado nace debido a la necesidad de de�nir la sintaxis abstracta de un lenguaje de
modelado de manera �formal�. Esta tendencia genera importantes ahorros en tiempo y recursos
destinados al mantenimiento de software, desarrollo de nuevas aplicaciones y al desarrollo de nuevas
características sobre el software existente [?].
En sentido amplio, de�nimos un metamodelo como un modelo de un lenguaje de modelado. La
palabra �meta� signi�ca por encima de, haciendo referencia al hecho de que un metamodelo describe
un lenguaje de modelado con un nivel de abstracción mayor que el que posee el lenguaje en sí mismo.
Para entender qué es un metamodelo, es útil entender la diferencia con un modelo. Mientras que un
metamodelo es también un modelo, tiene dos características principales que lo diferencian de éste.
La primera es que captura las propiedades y las características esenciales del lenguaje que modela.
La segunda es que forma parte de una arquitectura de modelado.
Una arquitectura de metamodelado posibilita que un metamodelo sea visto como un modelo,
el cual es descrito a su vez por otro, permitiendo que todos los modelos sean descritos por uno
único. Este último es a veces conocido como un lenguaje de metamodelado o meta-metamodelo y
es la clave del metamodelado ya que permite que todos los lenguajes de modelado sean descritos de
forma uni�cada, es decir, que seamos capaces de describir cualquier lenguaje utilizando el mismo
lenguaje de metamodelado. Entre los lenguajes de metamodelado más extendidos se encuentran
MOF de OMG [14] y Ecore para Eclipse [6].
Desarrollo de Software Dirigido por Modelos 26
Como hemos mencionado un metamodelo forma parte de una arquitectura de metamodelado.
OMG de�ne una arquitectura basada en cuatro niveles de abstracción que permite distinguir entre
los distintos niveles concepturales que intervienen en el modelado de un sistema. Los niveles vienen
de�nidos en la Figura 4.3:
Figura 4.3: Ejemplo de la arquitectura de 4 capas OMG.
M0: Las instancias. Modela el sistema real y sus elementos son las instancias que componen
dicho sistema.
M1: El modelo del sistema. En este nivel, se realiza el modelado de la aplicación. Sus
elementos son modelos de datos de los sistemas concretos, por ejemplo en el que se de�nen
entidades como Persona o Coche, atributos como nombre o relaciones entre esas entidades.
Existe una relación muy estrecha entre los niveles M0 y M1: los conceptos del nivel M1 de�nen
las clasi�caciones de los elementos del nivel M0, mientras que los elementos del nivel M0 son
las instancias de los elementos del nivel M1.
M2: El modelo del modelo, el metamodelo. Sus elementos son los lenguajes de modelado, por
ejemplo UML. Los conceptos a este nivel podrían ser Clase, Atributo, Asociación. A este nivel
trabajan las herramientas. Al igual que pasaba entre los niveles M0 y M1, aquí también existe
una gran relación entre los conceptos de los niveles M1 y M2: los elementos del nivel superior
de�nen las clases de elementos válidos den un determinado modelo de nivel M1, mientras que
los elementos del nivel M1 pueden ser considerados como instancias de los elementos del nivel
M2.
M3: El meta-metamodelo, el modelo de M2. Finalmente, el nivel M3 de�ne los elementos que
constituyen los distintos lenguajes de modelado. Es el nivel más abstracto donde se encuen-
Desarrollo de Software Dirigido por Modelos 27
tran los lenguajes como MOF o ECORE que proporcionan los constructores y mecanismos
necesarios para desc
4.3.2. Eclipse Modelling Framework
El Eclipse Modelling Framework (EMF) [6] es un framework desarrollado como un plugin para
Eclipse y cuyo objetivo es construir de forma rápida aplicaciones basadas en modelos. Este frame-
work uni�ca tres tecnologías: Java, XML y UML, siendo capaz de generar un modelo EMF usando
cualquiera de estas tecnologías y de transformarlo a su vez al formato de cualquiera de ellas, como
se muestra en la Figura 4.4.
Figura 4.4: EMF uni�ca Java, XML y UML
EMF está compuesto fundamentalmente por dos frameworks, el framework Core y el EMF.Edit.
El primero proporciona soporte en tiempo de ejecución y generación básica de código para crear la
implementación de clases Java de un modelo. El segundo está construido sobre el primer framework
como una extensión añadiéndole la posibilidad de crear clases adaptadoras que permitan la visión
y edición de comandos de un modelo e incluso la generación de un editor básico para éste.
Uno de los bene�cios más importantes de EMF es la generación automática de código. A partir de
un modelo EMF, se permite generar automáticamente las clases del mismo. Una de las características
más importantes de esta generación, es que las clases del modelo se corresponden con dos clases en
Java: una interfaz con su clase implementación. Estas clases se crearán a través de una clase factoría
(también generada automáticamente) que incluye un método create para cada clase del modelo.
Gracias a esta característica de EMF, ha sido posible crear la estructura de los datos que se van
introduciendo en la aplicación web, pues se han usado las clases generadas automáticamente del
modelo de referencia de ISO/EN 13606.
4.3.3. Transformación modelo-texto
Las transformaciones modelo-texto son el último paso en DSDM. En el mundo del desarrollo
de software dirigido por modelos podemos distinguir tres etapas fundamentalmente: i) el diseño de
un modelo independiente del dominio (PIM-Platform Indepent Model), ii) el diseño de un modelo
Desarrollo de Software Dirigido por Modelos 28
especí�co de un dominio (PSM-Platform Speci�c Model) y por último iii) la generación de código
a partir del PSM como se muestra en la Figura 4.5. Podemos pasar de una etapa a otra de la
arquitectura a través de tranformaciones.
Figura 4.5: Tres etapas fundamentales de DSDM.
La transformación modelo-texto es un tipo de transformación vertical que consiste en pasar
los modelos de más bajo nivel a un lenguaje de propósito general ejecutable. Existen diferentes
alternativas a la hora de pasar de un modelo a código:
Usar lenguajes de propósito general como Java o C#.
Usar lenguajes de tipo script como XSLT [2], JET (Eclipse Java Emitter Templates) [9] o
Velocity Template Language [4] que no fueron creados para trabajar con metamodelos.
Usar herramientas tipo CASE que poseen lenguajes de scripts, por ejemplo, basados en UML
con el inconveniente de que están ligados a una herramienta determinada y de que no están
basados en estándares.
Usar herramientas que implementan el estándar MOF Model-to-Text del OMG, que aún no
son maduras.
Otras herramientas basadas en Ecore como MOFScript, que es ampliamente utilizada por la
comunidad DSDM.
4.3.4. MOFScript
MOFScript 4.6 es una herramienta para transformar modelos a texto. Por ejemplo, se puede
utilizar para apoyar el proceso de generación de código o documentación a partir de modelos.
Esto proporciona un lenguaje independiente del metamodelo que permite usar cualquier tipo de
metamodelo y sus instancias para la generación de texto. La herramienta MOFScript está basada
en EMF y Ecore como marco de trabajo para metamodelos.
Desarrollo de Software Dirigido por Modelos 29
Los aspectos relacionados con la generación de texto que cubre MOFScript son los siguientes:
Generación de texto a partir de modelos basados en Ecore: genera texto a partir de cualquier
modelo basado en Ecore, por ejemplo a partir de modelos UML.
Incluye sentencias de control imperativas: bucles, condicionales, etc.
Facilidad para la manipulación de cadenas.
Evaluar el resultado de expresiones que referencian elementos del modelo.
Permite trazabilidad entre los modelos iniciales y el texto generado. Por ejemplo, para pro-
porcionar re-generación.
A continuación se presenta un sencillo ejemplo con el �n de que se observe de forma super�cial la
sintaxis y la estructura del lenguaje MOFScript. En el ejemplo de la Figura 4.6 se observa que el
�chero comienza con la palabra textransformation. Con esta palabra se permite indicar cuál/cuáles
son los metamodelos que se usan para realizar la transformación. En este ejemplo, se han usado
dos metamodelos que han sido llamados uml y ec. La función main() de�ne el punto de entrada
de la transformación. Se puede observar como el ejemplo imprime el nombre de las clases de los
dos metamodelos que recibe como entrada realizando sencillas iteraciones sobre los elementos de los
mismos.
Figura 4.6: Ejemplo de transformación con MOFScript
Capítulo 5
Diseño de la solución
En este capítulo se describe cómo se ha llevado a cabo la generación de aplicaciones web basadas
en los modelos semánticos de los arquetipos del estándar ISO/EN 13606 para que un profesional
clínico pueda usarlas a la hora de editar la información de la historia clínica de un paciente con
el �n de almacenarla en un extracto compatible con el estándar ISO/EN 13606 que permita su
compartición. La estructura que se ha adoptado para explicar el diseño de la solución está basada
en los subobjetivos de�nidos en el Capítulo 2. Además de las secciones de los subojetivos, se ha
incorporado una sección extra al �nal del capítulo (Sección 5.4) para explicar la generación del
extracto, el uso de EMF para construir los modelos y la serialización a XML y otra para explicar la
tarea Ant implementada para que genere y despliegue la aplicación (Sección 5.5).
5.1. Implementación de las restricciones del modelo de refe-
rencia de ISO/EN 13606.
Los tipos de datos y los componentes de la jerarquía del modelo de referencia ISO/EN 13606
tienen unas restricciones asociadas. Sin embargo, las restricciones asociadas a cada uno de ellos son
diferentes. En primer lugar, los tipos de datos tienen restricciones que limitan su valor. Por otro
lado, los componentes de la jerarquía del MR tienen las llamadas restricciones de ocurrencia. Debido
a esto, hay que separar el estudio de los tipos de datos y de los componentes de la jerarquía del
MR. Las siguientes subsecciones (5.1.1) y (5.1.2) muestran el tratamiento de las restricciones y la
representación de los tipos de datos y de los componentes de la jerarquía del MR de ISO/EN13606
respectivamente.
5.1.1. Tipos de datos de ISO/EN 13606.
En ISO/EN 13606 se de�nen una serie de tipos primitivos: BOOLEAN, STRING, REAL e INTEGER.
Estos tipos de datos se caracterizan por poseer un atributo value, que contendrá el valor de estos
tipos primitivos. El Modelo de Restricciones de ISO/EN 13606 se encarga de de�nir las restriccio-
Implementación de las restricciones del modelo de referencia de ISO/EN 13606. 31
nes para estos tipos de datos primitivos. También de�ne restricciones para otros tipos que no son
primitivos, como son DATE, TIME y DURATION. En la Figura 5.1 se muestra el diagrama UML de
este modelo. Los tipos de datos de ISO/EN 13606 se dividen en varias categorías: tipos de datos
primitivos, tipos de datos estructurados, tipos de datos de texto y codi�cados, tipos de magnitud y
tipos relacionados con el tiempo. Dado que los tipos de datos que no son primitivos están compuestos
por otros tipos compuestos y tipos primitivos, las restricciones se de�nen sobre los tipos de datos
primitivos (a excepción de las restricciones de los tipos DATE, TIME y DURATION).
Figura 5.1: Paquete de restricciones para los tipos primitivos de la Norma ISO/EN 13606.
5.1.1.1. Paquete de restricciones para los tipos primitivos.
En el metamodelo semántico sobre el que se han realizado las transformaciones de modelo-texto
para crear las aplicaciones web, se encuentran los siguientes tipos de datos primitivos: BL, DV_STRING,
DV_INTEGER y DV_REAL. Estos tipos de datos se caracterizan por tener un valor asociado (value en el
metamodelo) y una restricción asociada a cada uno de ellos. Dependiendo del tipo primitivo, cada
uno tendrá su propia restricción. Por ejemplo, el tipo BL tendrá la restricción C_BOOLEAN, el tipo
DV_STRING la restricción C_STRING y así sucesivamente. Que cada tipo de dato primitivo tenga su
propia restricción hace que tengan que ser procesadas de forma distinta.
El tipo BL y su restricción C_BOOLEAN. La restricción C_BOOLEAN controla tres tipos de
restricciones:
Implementación de las restricciones del modelo de referencia de ISO/EN 13606. 32
Restricción �assumedValue�: esta restricción indicará el valor por defecto del booleano. En
caso de que se especi�que este tipo de restricción, habrá que establecer este valor por defecto
en el código Java que se generará para un tipo boolean. La forma de controlar esta restricción
será estableciendo este valor cuando se declare la variable booleana.
Restricción �trueValid�: indicará si es válido el valor true para un booleano. En caso de que
esta restricción no permita que se establezca el valor true para un booleano, lo que se hará
será establecer en el valor por defecto del booleano en el código Java el valor false y no se
mostrará el botón con valor true.
Restricción �falseValid�: indicará si es válido el valor false para un booleano. Es lo contrario
a la restricción anterior.
Nótese con respecto a las restricciones �trueValid� y �falseValid� que los dos atributos no pueden
ser establecidos a false. Una vez estudiada la restricción de este tipo de datos primitivo, hay que
establecer su representación. La representación escogida para el tipo BL en la vista es un componente
selectOneRadio que pertenece a la biblioteca de componentes de JSF.
El tipo DV_STRING y su restricción C_STRING. La restricción C_STRING controla las
siguientes restricciones:
Restricción �assumedValue�. Esta restricción es similar a la de C_BOOLEAN.
Restricción �lista�. Esta restricción hará que se especi�que una lista con los valores que
puede tomar un tipo DV_STRING. La forma de controlar este tipo de restricción se realizará en
la vista de las aplicaciones web generadas, pues en caso de que se establezca esta lista, habrá
que representar un DV_STRING con una lista desplegable.
Restricción �listOpen�. Si esta restricción toma el valor true, indicará que la lista anterior no
es exhaustiva, es decir, que además de los valores especi�cados en la lista, se podrán introducir
valores a mano. Para conseguir el procesamiento de esta restricción, habrá que permitir que
la lista desplegable sea editable.
Restricción �pattern�. Esta restricción contendrá una expresión regular con la que el String
que introduzca el usuario tendrá que corresponderse. Esta restricción se comprobará haciendo
uso de una etiqueta de Hibernate Validator (@Pattern). Un aspecto importante a tener en
cuenta es que es necesario realizar la conversión entre las expresiones regulares de�nidas en
ISO/EN 13606 y las expresiones regulares Java que usará Hibernate Validator.
La representación escogida para el tipo DV_STRING dependerá de si se ha de�nido una lista o no. En
caso de que no se haya de�nido una lista, la representación de este tipo será un simple componente de
texto inputText de la biblioteca de componentes de JSF y en caso contrario, una lista desplegable
comboBox de la biblioteca de componentes de RichFaces.
Implementación de las restricciones del modelo de referencia de ISO/EN 13606. 33
El tipo DV_INTEGER y su restricción C_INTEGER y el tipo DV_REAL y su res-
tricción C_REAL. Las restricciones C_INTEGER y C_REAL poseen las mismas restricciones, con
la salvedad de que una trata con valores enteros y la otra con valores reales. Estas restricciones son:
Restricción �assumedValue�. Esta restricción establecerá el valor por defecto para un DV_INTEGER
o DV_REAL , según corresponda, y será tratada de igual forma que las restricciones con el mismo
nombre en los tipos primitivos anteriores.
Restricción �lista�. Esta restriccion hará que se especi�que una lista con los valores que
puede tomar un tipo DV_INTEGER o DV_REAL. Se procesa de igual forma que la lista de valores
anterior.
Restricción �range�. Esta restricción es un intervalo de enteros o de reales, según corresponda.
Lo que hará este intervalo será establecer un valor mínimo y máximo para un entero. En caso
de que un entero o un real tenga esta restricción, se controlará a través del componente de la
vista. En caso de que no se de�na un rango, o uno de los límites superiores o inferiores del
mismo, se establecerán el límite superior o inferior con los valores que establece el estándar
ISO/EN 13606 para los tipos de datos enteros o reales según corresponda.
La representación escogida para el tipo DV_INTEGER o para el tipo DV_REAL dependerá de si se ha
de�nido una lista o no. En caso de que no se haya de�nido una lista, la representación de este tipo
será un componente comboBox, y en caso contrario, un componente inputNumberSpinner. Ambos
componentes pertenecen a la biblioteca de componentes de RichFaces.
El tipo DATE y su restricción C_DATE y el tipo TS y su restricción C_TIME. La
restricción C_DATE restringirá un tipo DATE usando las siguientes restricciones:
Restricción �assumedValue�. Esta restricción determinará el valor por defecto de una fecha.
Si un tipo DATE tiene esta restricción, habrá que establecer como valor por defecto en la
declaración Java del atributo en el que se mapee el tipo DATE el que aparece en assumedValue.
Restricción �pattern�. Esta restricción indicará el patrón que se usará para la fecha. Por
ejemplo, se puede establecer que el patrón de una fecha sea del tipo YYYY-MM-DD, por lo
que habrá que controlar que se cumpla. Para ello, hay que utilizar una función que ha sido
implementada para obtener una expresión regular que concuerde con este patrón y que se
pueda indicar la estructura de la fecha usando la anotación @Pattern de Hibernate Validator.
Restricción �range�. Esta restricción determinará un rango de valores de fechas que puede
tomar el tipo DATE. Para determinarlo, habrá que usar la restricción anterior (pattern) para
que una función cree la expresión regular correspondiente basándose en el formato. Si no se
ha de�nido ningún patrón, se tomará por defecto el YYYYMMDD que es el que aparece en
el estándar como predeterminado.
El tipo TS tendrá una restricción de tipo C_TIME que posee las mismas restricciones que C_DATE,
con la diferencia de que variará el patrón por defecto que ahora será hhhhmmss y las funciones para
Implementación de las restricciones del modelo de referencia de ISO/EN 13606. 34
procesar el tiempo. Por lo demás, el tratamiento de las restricciones es el mismo. Para representar
estos dos tipos de datos, se usará un inputText de la biblioteca de componentes de JSF.
El tipo DURATION y su restricción C_DURATION. El tipo DURATION no es un tipo
primitivo, sino que es un tipo perteneciente al paquete de tipos de magnitud. Sin embargo, este
tipo de dato tiene una restricción asociada que forma parte del paquete de restricciones primitivas.
Por este motivo, el estudio de las restricciones de este tipo se ha presentado aquí, aunque el tipo se
explicará de forma breve en su apartado correspondiente dentro del paquete de tipos de datos de
magnitud.
El procesamiento de las restricciones del tipo DURATION se ha realizado utilizando las vistas de las
aplicaciones web generadas. En ellas, los distintos componentes que representan a un tipo DURATION
han sido restringidos dependiendo de su restricción C_DURATION y de las restricciones que establece
el Sistema Internacional de unidades de medida para las unidades de tiempo. Las restricciones que
realizará el tipo C_DURATION son las siguientes:
Restricciones �years_allowed�, �month_allowed�, �days_allowed�, �minutes_allowed�, �
second_allowed � y �fractional_seconds_allowed�. Estas restricciones indicarán si se per-
mite que el usuario introduzca valores de años, meses, días, minutos, segundos y fracciones de
segundo respectivamente. En caso de que no se permita alguna de ellas, no se representará en
la vista.
Restricción �assumedValue�. Si existe un assumedValue, se establecerá cada uno de los atribu-
tos Java a los que se mapea con el valor por defecto que contenga este assumedValue cuando
se declaran.
Aparte, hay restricciones del tipo DURATION que hay que controlar. Estas restricciones son aquellas
que restringen el valor de las horas, días, minutos, segundos y fracción de segundo. Por ejemplo,
las horas tienen un valor entre 0 y 23, los minutos un valor entre 0 y 59 y así sucesivamente.
Para controlar este tipo de restricciones, en los componentes de las vistas (que serán por lo general
inputNumberSpinner ) se indicarán los valores máximo y mínimo para cada uno.
5.1.1.2. Tipos de datos no primitivos. Representación y consideraciones.
Como ya se ha comentado anteriormente, los tipos de datos compuestos están formados por
los tipos de datos estructurados, los tipos de datos de texto y codi�cados, los tipos de magnitud
y los tipos relacionados con el tiempo. Cada una de estas categorías contiene unos tipos de datos
concretos, compuestos por tipos de datos compuestos y tipos de datos primitivos (donde se controlan
las restricciones).
A continuación, se presenta cada categoría con sus tipos de datos concretos. Para cada tipo de
datos, se encontrará la descripción de cada uno de ellos, las decisiones de diseño que se han tomado
para su representación y mapeo en Java y un esquema que los represente. En el Apéndice A se
encuentran estos tipos de datos con sus características más detalladas.
Implementación de las restricciones del modelo de referencia de ISO/EN 13606. 35
5.1.1.3. Tipos de datos estructurados
Los tipos de datos estructurados son ED (Encapsulated Data), II (Instance Identifier),
OID (ISO Object Identifier), URI (Universal Resource Identifier) e IVL<T> (Interval). Sin
embargo, de estos tipos de datos sólo se presenta el estudio y la representación para los tipos
II, OID, BL y URI. El estudio de ED no se ha realizado porque la representación de contenidos
multimedia queda fuera del alcance de este proyecto. Por otro lado, el tipo IVL<T> no se expone
aquí directamente, porque es una clase que de�ne un intervalo de un tipo de datos Time Point (TS)
o Physical Quantity (PQ). Por tanto, en las secciones correspondientes se ha realizado el estudio
para los tipos de datos IVL<TS> e IVL<PQ>.
La Figura 5.2 muestra el diagrama UML de los tipos de datos estructurados de ISO/EN 13606.
Figura 5.2: Paquete de los Tipos Estructurados de ISO/EN 13606
Instance Identifier (II) Este tipo de dato es utilizado para identi�car únicamente una ocurren-
cia, recurso u objeto. Se caracteriza por poseer cuatro atributos, de los cuales sólo se representarán
tres, pues el atributo �extension� tiene un manejo poco intuitivo y por eso se ha dedicido prescindir
de él en las vistas. El aspecto que presenta este tipo de atributo en un formulario se encuentra en
la Figura 5.3. De este tipo de dato conviene remarcar que su atributo Identi�cador es obligatorio,
por lo que habrá que indicar en ese componente inputText que es requerido (siempre y cuando el
Implementación de las restricciones del modelo de referencia de ISO/EN 13606. 36
ELEMENT del que forme parte tenga una ocurrencia de 1...1)
Figura 5.3: Representación grá�ca del tipo de dato Instance Identifier (II)
ISO Object Identifier (OID) Un OID es una cadena globalmente única que consiste en números
y puntos. Esta cadena expresa una estructura de datos en árbol, representando el número más a
la izquierda la raíz y el número más a la derecha la hoja. Este tipo de objeto se representará con
un único componente inputText de la biblioteca de componentes JSF. Para restringir que sea una
cadena que esté compuesta por números y puntos, cada vez que se procesa un OID se inserta una
anotación @Pattern de Hibernate Validator con la expresión regular correspondiente.
Universal Resource Identifier (URI) Una URI es un tipo de dirección de telecomunicaciones
especi�cado en la norma de Internet RFC 1738. Para la representación de este tipo de datos, sólo se
ha mapeado a Java y se ha representado en la vista el atributo value, porque se ha considerado que
el personal clínico no se va a encontrar en disposición de introducir en un formulario el esquema,
el path y los demás elementos que componen una URI. Sin embargo, para que el usuario de la
aplicación web generada introduzca una URI correcta y no cualquier valor, se ha implementado una
restricción personalizada para Hibernate Validator.
5.1.1.4. Tipos de datos de texto y codi�cados
Esta categoría de tipos de datos está compuesta por: TEXT, ST (Simple Text), CODED_TEXT, CV
(Coded Value), CE (Coded with Equivalences), CD (Concept Descriptor), CR (Concept Role) y
CS. Nótese que la clase TEXT es una clase abstracta que no tiene representación y de la que heredan
todos los demás tipos. Esta clase hará que los demás tipos tengan el atributo originalText. Por
otro lado, está el tipo CS que es un valor simple codi�cado, como pueden ser las unidades del Sistema
Internacional, los idiomas, etc. Esta clase siempre se encontrará contenida por otra, por lo que su
representación dependerá de la clase en la que se encuentre. Dicho esto, se van a comentar los tipos
CODED_TEXT, CV, CE, CD, CR y CS. El paquete de los tipos de datos de texto y codi�cados se encuentra
en la Figura 5.4.
Implementación de las restricciones del modelo de referencia de ISO/EN 13606. 37
Figura 5.4: Paquete de los Tipos de Texto y Codi�cados de ISO/EN 13606
CODED_TEXT Este tipo de datos es una cadena de texto libre con un valor del código anexado. Para
su representación, se ha optado por mostrar los atributos displayName y codeValue del tipo de
datos CD. Hay que tener en cuenta en este tipo de datos (y en todos los que contengan un valor
codi�cado) que el valor codi�cado pertenecerá a una codi�cación que puede venir restringida en
el arquetipo del que se parte para generar la aplicación web. Si esto sucede, habrá que crear una
expresión regular que en el campo del atributo codeValue sólo acepte valores con el formato de la
codi�cación. En la Figura 5.5 se encuentra la representación de un CODED_TEXT.
Figura 5.5: Representación grá�ca del tipo de dato Coded Text
CODED VALUE (CV) Un CV contiene datos codi�cados, que especi�can sólo un código, sin ningún
otro cali�cador o correspondencia a otros conjuntos de códigos. Para su representación, se ha opta-
Implementación de las restricciones del modelo de referencia de ISO/EN 13606. 38
do por mostrar sus atributos displayName y codeValue, que dependiendo de las restricciones, se
representarán usando un componente inputText de JSF o un componente comboBox de RichFaces.
Los atributos codingScheme, codingSchemeName y codingSchemeVersion de este tipo de dato no
se representan, para evitar que el personal clínico esté tratando con esquemas de códigos y con sus
versiones. Sin embargo, sí que se procesan para que se cumplan las restricciones. Es decir, si un CV
tiene uno o varios codingSchemeName de�nidos, se creará una expresión regular para que el usuario
siga el formato del código. Por ejemplo, si el usuario quiere introducir un concepto de la terminología
CIE9, el formato de estos códigos es [CIE9::[0-9]+(.[0-9]+)*]. La representación es la misma que se
realiza para el tipo CODED_TEXT (ver Figura 5.5).
CODED WITH EQUIVALENCES (CE) Un CE contiene datos codi�cados que consisten en un valor del
código y, opcionalmente, uno o varios valores del código de otros sistemas de codi�cación que iden-
ti�can el mismo concepto. Se utiliza cuando puedan existir códigos alternativos. Este tipo de datos
ha sido representado y procesado de igual forma que el tipo CODED_TEXT (ver Figura 5.5), con la
salvedad de que aquí se permiten insertar códigos de distintas codi�caciones. Por ello, la expresión
regular estará compuesta por los formatos de las codi�caciones que contenga.
CONCEPT DESCRIPTOR (CD) Un CD está compuesto por un conjunto de atributos que representan
un concepto en un sistema de conceptos de�nido. Un CD posee la misma representación que un
CODED_TEXT. Esta representación se puede consultar en la Figura 5.5.
CONCEPT ROLE (CR) Un CR es un código cali�cador del concepto con un rol �jado opcionalmente.
Tanto los códigos del papel del cali�cador como los valores deben estar de�nidos en un sistema de
codi�cación. La representación grá�ca de este tipo de dato se muestra en la Figura 5.6.
Figura 5.6: Representación grá�ca del tipo de dato Concept Role (CR)
5.1.1.5. Tipos de magnitud
Esta categoría de tipos de datos está compuesta por: QUANTITY_RANGE, QUANTITY, RTO, ORD, PQ y
DURATION. Hay que destacar que la clase QUANTITY es una clase abstracta que no tiene representación
y de la que heredan todos los demás tipos, excepto QUANTITY_RANGE. Dicho esto, se van a comentar
los tipos QUANTITY_RANGE, QUANTITY, RTO, ORD, PQ y DURATION. El diagrama UML del paquete de
los tipos de datos de magnitud se encuentra en la Figura 5.7.
Implementación de las restricciones del modelo de referencia de ISO/EN 13606. 39
Figura 5.7: Paquete de los Tipos de Magnitud de ISO/EN 13606
ORDINAL (ORD) Un tipo ordinal es un número u otro símbolo que de�ne la posición en series
ordenadas. Para representar un ORD, se representará únicamente el valor del displayName o del
codeValue dependiendo de lo que se de�na en el arquetipo. El valor numérico será tratado cuando
se seleccione un displayName o un codeValue, ya que cada uno de ellos tendrá asociado el valor
numérico de forma oculta en el componente comboBox de RichFaces con el �n de que al seleccionarlo,
se establezca el atributo correspondiente en el bean donde se mapea este tipo de dato.
PHYSICAL QUANTITY (PQ) Este tipo de dato representa a una magnitud dimensionada que expresa
el resultado de una medición. Su representación en la vista se puede observar en la Figura 5.8. El
valor se representa mediante un componente de la biblioteca de RichFaces, el inputNumberSpinner,
de forma que es posible restringirlo atendiendo a las restricciones que se establecen sobre el tipo
primitivo DV_REAL del valor. Por otra parte, aparecen las unidades que son de tipo CS. Estas unidades
se representarán de la siguiente forma: en caso de que vengan restringidas en una lista, se mostrará
un componente comboBox con los valores de la lista y en caso contrario, se mostrarán las abreviaturas
de todas las medidas descritas en la codi�cación estándar UCUM. Por otro lado, la propiedad medida
será el campo displayName del tipo CD.
Figura 5.8: Representación grá�ca del tipo de dato Physical Quantity (PQ)
DURATION Representa un periodo de tiempo con respecto a un hipotético punto en el tiempo, que
no se especi�ca. Se puede utilizar el signo para indicar que la duración es hacia atrás en el tiempo en
Implementación de las restricciones del modelo de referencia de ISO/EN 13606. 40
lugar de hacia delante. Las restricciones aplicadas sobre este tipo de dato ya han sido comentadas en
el apartado que se encargaba de explicar las restricciones de los tipos de datos primitivos. Únicamente
resta presentar su representación grá�ca en la vista. Ésta se encuentra en la Figura 5.9 y todos los
componentes utilizados son inputNumberSpinner a excepción de un componente comboBox que se
usa para el signo.
Figura 5.9: Representación grá�ca del tipo de dato Duration
QUANTITY RATIO (RTO) Este tipo de dato representa una razón construida como el cociente de una
magnitud en el numerador y de una magnitud en el denominador. La representación de un RTO serán
dos PQ, uno en el numerador y otro en el numerador. El tratamiento de las restricciones se realiza
de igual forma que para el tipo de datos PQ. La Figura 5.10 muestra la representación en las vistas
de este tipo de datos.
Figura 5.10: Representación grá�ca del tipo de dato Quantity Ratio (RTO)
QUANTITY RANGE (IVL<PQ>) Este tipo de dato representa a un intervalo de magnitudes físicas,
representado por un IVL<PQ>. Este intervalo tendrá dos booleanos que indicarán si el intervalo está
cerrado o abierto tanto en el límite superior como en el límite superior. Por supuesto, también se
representarán los límites superiores e inferiores, que son de tipo PQ. Como las restricciones de este
tipo de dato son las mismas que las de un tipo PQ, sólo se mostrará su representación grá�ca, que
se puede observar en la Figura 5.11.
Figura 5.11: Representación grá�ca del tipo de dato Quantity Range (IVL<PQ>)
5.1.1.6. Tipos relacionados con el tiempo
Esta categoría de tipos de datos está compuesta por: EIVL, PIVL, TS y DATE. A continuación se
comentarán los estos tipos, que se pueden encontrar en el diagrama UML del paquete de los tipos
de datos de tiempo se encuentra en la Figura 5.12.
Implementación de las restricciones del modelo de referencia de ISO/EN 13606. 41
Figura 5.12: Paquete de los Tipos de Tiempo de ISO/EN 13606
DATE Identi�cación de un día en concreto del calendario, expresado mediante alguna combinación
de los elementos de datos año del calendario, mes del calendario, semana del calendario, día del
calendario o día del año. Este tipo de datos se representará con un simple inputText de JSF, y en
la subsección 5.1.1.2 ya se ha explicado la forma de manejarlas.
TIME POINT (TS) Un instante en el intervalo de tiempo considerado como adimensional. Al igual
que sucedía con el tipo DATE, este tipo de dato se representará con un inputText de JSF y ya se
han explicado sus restricciones en el apartado 5.1.1.2 de la presente memoria.
INTERVAL OF TIME (IVL<TS>) Un intervalo de tiempo se de�ne como la representación del tiempo
que hay entre una fecha/hora de comienzo y de �nalización. Un intervalo de tiempo tendrá las
mismas restricciones que TS asociadas a sus límites inferior y superior. La representación de este
tipo de datos se muestra en la Figura 5.13.
Figura 5.13: Representación grá�ca del tipo de dato Interval of Time (IVL<TS>)
PERIODIC INTERVAL OF TIME (PIVL) Un intervalo periódico de tiempo especi�ca un intervalo de
tiempo que sucede periódicamente. Los intervalos periódicos tienen dos propiedades, fase y periodo.
La fase se encuentra representada por un IVL<TS> y el periodo por un atributo de tipo DURATION.
Como la representación de estos dos tipos de atributos que componen el PIVL ya se ha realizado,
sólo se mostrará la representación de este tipo en la Figura 5.14.
Implementación de las restricciones del modelo de referencia de ISO/EN 13606. 42
Figura 5.14: Representación grá�ca del tipo de dato Periodic Interval of Time (PIVL)
EVENT RELATED PERIODIC INTERVAL OF TIME (EIVL) Especi�ca un intervalo periódico de tiempo
en el que la repetición se basa en actividades de la vida diaria. Para realizar la representación de
este tipo de dato, se ha incluido en la lista del comboBox un listado de actividades de la vida diaria,
com son desayuno, almuerzo, comida, merienda y cena. La representación de este tipo de dato se
encuentra en la Figura 5.15.
Figura 5.15: Representación grá�ca del tipo de dato Event Related Periodic Interval of Time
(EIVL)
5.1.2. Componentes de la jerarquía del modelo de referencia de ISO/EN
13606.
5.1.2.1. Restricciones aplicadas a los componentes de la jerarquía del modelo de re-
ferencia de ISO/EN 13606
Para los componentes de la jerarquía del MR de ISO/EN 13606 se ha manejado una restricción:
la restricción de ocurrencias. Esta restricción está relacionada con el número de ocurrencias de
estos componentes que pueden ser instanciadas. Cada componente de la jerarquía del MR tiene una
restricción de ocurrencia asociada, donde se indica un número máximo y mínimo de ocurrencias. El
tratamiento de las restricciones de ocurrencia se muestra a continuación:
En caso de que se establezca una ocurrencia de 1...1 (obligatorio), se crea inicialmente el
componente y se guarda en el ámbito de la conversación web de la aplicación web para que
se pueda recuperar posteriormente. Esto implica que este componente sea estático. También
se coloca un asterisco (*) en el árbol de navegación de la aplicación web con el �n de que el
usuario sepa que este componente es obligatorio. Por ejemplo, si a una entrada se le coloca un
Implementación de las restricciones del modelo de referencia de ISO/EN 13606. 43
asterisco al lado de su nombre, el usuario de la aplicación debe rellenar obligatoriamente esta
entrada.
En caso de que se establezca una ocurrencia de 0...1 (opcional), se creará el componente y se
colgará de la estructura XML cuando se utilice. Tanto en el caso anterior como en éste, habrá
que comprobar que no se almacene más de una ocurrencia de un componente concreto. Para
conseguir esto, se almacena un atributo como identi�cador para un componente y durante la
inserción se comprueba si hay algún componente con el valor del identi�cador. En caso de que
exista, se eliminará de la estructura y se almacenará el nuevo.
En caso de que se establezca una ocurrencia con un límite superior de�nido y que sea mayor que
uno, se irán creando los componentes y su estructura conforme se vayan utilizando. Además,
habrá que comprobar que no se supere el límite superior, por lo que estos componentes se irán
almacenando en listas para ir comprobando su tamaño y evitar que se supere dicho límite.
En caso de que se establezca una ocurrencia con un límite superior ilimitado, se irán creando
los componentes, su estructura y se irán almacenando en la lista. Sin embargo, en esta ocasión
no será necesario comprobar que se cumple un límite.
5.1.2.2. Representación grá�ca de los componentes de la jerarquía del modelo de
referencia de ISO/EN 13606.
La representación de estos componentes se realizará en dos lugares: el árbol de navegación de la
aplicación web y en las páginas web.
En el árbol de navegación, cada tipo de componente tendrá un símbolo que los identi�que. Por
ejemplo, las FOLDERs se representan con una carpeta pequeña, las ENTRYs con un símbolo de un
documento... En la parte de las páginas web, las FOLDER, COMPOSITION y SECTION se representarán
como un enlace, haciendo que los componentes que cuelguen de ellas (FOLDERs y COMPOSITIONs si
el padre es una FOLDER, SECTIONs si el padre es una COMPOSITION, y ENTRYs si el padre es una
SECTION) se representen con un enlace también. De esta forma, se conseguirá ir navegando tanto
por el árbol de navegación como por el contenido de la aplicación web. Se ha tomado la decisión de
que cuando se llegue al nivel de una ENTRY se representará un formulario para la introducción de los
datos. Es decir, hasta que no se llegue a este nivel, no se verán los formularios propiamente dichos.
Por otro lado, habrá que representar también los ELEMENTs y los CLUSTERs cuando se llegue a
una ENTRY. La representación de ambos se indica a continuación:
CLUSTER: un componente de este tipo se representará usando una tabla para visualizar los
datos que ya han sido insertados en el CLUSTER y un formulario para permitir la inserción de
los datos y que dependerá de los CLUSTERs y los ELEMENTs que anide el CLUSTER principal. Por
ejemplo, si un CLUSTER x contiene a un CLUSTER y, habrá que crear una tabla anidada para
almacenar este segundo CLUSTER y dentro del CLUSTER x.
ELEMENT: un componente de este tipo se representará dependiendo de dos posibles casos. El
primero consiste en que el elemento no tenga ocurrencia múltiple, por lo que su representación
Diseño de la estructura de las aplicaciones web. 44
dependerá del tipo de dato que contenga el elemento. En caso de que el elemento tenga ocu-
rrencia múltiple, habrá que realizar una representación similar a la realizada con los CLUSTERs:
mantener una tabla con los elementos ya insertados y un formulario para insertar este elemento.
5.2. Diseño de la estructura de las aplicaciones web.
Con el �n de diseñar la estructura de las aplicaciones web generadas, se ha realizado una primera
tarea que consiste en el estudio de las herramientas que se iban a usar para la aplicación web y
una segunda tarea que tiene que ver con el desarrollo de prototipos para determinar la estructura
más adecuada para dicha aplicación web. En el Capítulo 4 se detallan los frameworks que se han
usado �nalmente en las aplicaciones web generadas. Destacan JSF, con la biblioteca de componentes
RichFaces y Seam Framework. Tampoco hay que olvidar a EMF, gracias a la cual se crean las clases
del modelo semántico para crear la estructura de los datos que el usuario introducirá en el formulario
y que luego se pueda serializar en un �chero XML. Conviene reseñar de la segunda tarea que se
fueron realizando los prototipos por orden de di�cultad. Es decir, primero se hizo un prototipo de
un arquetipo muy sencillo para acabar realizando otros dos de arquetipos más complejos. Una vez
que se �nalizaron estas dos tareas, fue posible de�nir la estructura de las aplicaciones web.
5.2.1. Estructura básica de las aplicaciones web generadas
En la Figura 5.16 se muestra la estructura de las aplicaciones web generadas. Dentro de esta
aplicación web, hay que destacar dos directorios: src y archforms. La organización de la aplicación
sigue el patrón MVC. Por un lado, se encuentra el modelo que será una biblioteca que contiene todas
las clases del modelo de referencia para crear el extracto con la información del arquetipo, por otro
lado se encuentran los controladores situados dentro del paquete controlador y �nalmente las vistas
de la aplicación.
Figura 5.16: Estructura de la aplicación web generada
El directorio src contendrá el código Java de la aplicación web. Como se puede observar en la
Figura 5.16, la aplicación tiene tres paquetes:
Diseño de la estructura de las aplicaciones web. 45
Paquete �clusters�. Este paquete contendrá los beans para los CLUSTERs que se encuentren
en el modelo del arquetipo. Por ejemplo, si un arquetipo tiene un CLUSTER con identi�cador
at0001, dicho paquete tendrá una clase Java llamada Clusterat0001 con todos los atributos
resultantes de realizar los mapeos de los ELEMENTs y CLUSTERs que contiene. Esta clase será
usada a la hora de acceder posteriormente a los CLUSTERs para mostrar su contenido en una
tabla en las vistas de la aplicación web, ya que cada vez que se inserta un CLUSTER y un
ELEMENT dentro de un CLUSTER se almacena tanto en este tipo de bean como en la estructura
que luego se usará para generar el extracto compatible con el estándar ISO/EN 13606.
Paquete �beans�. Este paquete contendrá los beans generados para los ELEMENTs con ocurrencia
múltiple. Por ejemplo, si un arquetipo tiene un ELEMENT con identi�car at0001 y con ocurrencia
múltiple, que contiene un PQ, se creará un bean llamado Beanat0001 que contendrá el mapeo
de los atributos del tipo de dato a Java con los correspondientes métodos get y set.
Paquete �controlador�. Este paquete es el más importante de los tres que contiene el di-
rectorio src. Será el que contenga los controladores de la aplicación web, donde se controlen
las restricciones con Hibernate Validator y donde se irá generando la estructura del extracto.
Uno de los aspectos más importantes de las clases que se generan en este paquete es que
hay dos tipos de controladores: el controlador primario y los controladores secundarios. Estos
controladores se explicarán de forma más detallada en 5.2.2.
Paquete �tree�. Contendrá dos clases que se encargarán de leer el �chero de propiedades del
árbol de navegación y crearlo. La creación la realizarán los componentes tree y treeNode de
la librería RichFaces a través de los métodos que hay disponibles en la clase TreeBean.java
que está contenida en este paquete.
El directorio archforms se caracteriza por contener los siguientes contenidos:
Vistas de la aplicación web. Las vistas son �cheros JSP que se encargarán de visualizar el
contenido de las aplicaciones web y se encuentran debajo de archforms.
Hoja de estilo CSS. Esta hoja de estilo será la que dará la apariencia a la aplicación web. Se
encuentra en el directorio css.
Imágenes usadas por el árbol de contenidos. Estarán en el directorio img y servirán para
distinguir entre un tipo de componente y otro dentro del árbol de navegación de la aplicación.
Ficheros de con�guración:
• Fichero seam.properties. Se encuentra en el directorio src y en él se indicarán las
propiedades de Seam. En nuestra aplicación está vacío porque las propiedades que requiere
Seam se proporcionan a través de los �cheros XML de con�guración. A pesar de que esté
vacío, la aplicación web tiene que contenerlo obligatoriamente.
• Fichero components.xml. Este �chero se encuentra dentro del directorio WEB-INF y es el
descriptor de despliegue de componentes. En él se permiten con�gurar los componentes
Diseño de la estructura de las aplicaciones web. 46
que han sido instalados automáticamente, las clases instaladas que no poseen la anotación
@Name y los componentes que tienen una anotación @Name pero que no son instalados por
defecto.
• Fichero web.xml. Es el �chero de con�guración de la aplicación web. Hay que de�nir en
él el SeamListener y con�gurar el Faces Servlet para que redirija las peticiones de
páginas JSF a este Servlet.
• Fichero faces-config.xml. Este �chero se encuentra dentro del directorio WEB-INF y es
el archivo de con�guración central de JSF. Habrá que de�nir el FaceletViewHandler para
indicarle a JSF cómo tiene que manejar las vistas de la aplicación.
El directorio WEB-INF/lib contiene las bibliotecas de la aplicación.
En el directorio WEB-INF/pages se almacena un �chero de tipo PROPERTIES para la creación
del árbol de navegación de la aplicación web.
5.2.2. Los controladores de la aplicación web.
Los controladores de la aplicación web serán los encargados de manejar las peticiones lanzadas
por las vistas con el �n de implementar la lógica de negocio. Para conseguir este �n, lo que se hará
será que todos los controladores implementen una interfaz. Esta interfaz es la interfaz Register, que
tiene un método register() y que se encuentra empaquetada dentro del �chero utilidades.jar.
Por otro lado, en el diseño de los controladores de la aplicación web hay que destacar que hay
dos tipos de controladores: el controlador principal y los controladores sencundarios.
El controlador principal es el controlador generado cuando se procesa el componente raíz de
la parte de de�nición de un arquetipo. En el código que aparece a continuación se muestra
un ejemplo de controlador principal generado por la aplicación, que pertenece al arquetipo
Informe de Alta que se encuentra en el Apéndice B. Como se puede observar, tiene una parte
de declaraciones de variables, donde se declaran todos los componentes de la jerarquía que
cuelgan de él a excepción de los ELEMENTs. Después de la declaración de estos atributos, aparece
el método init(). Este método será al que se llame cuando comience una conversación web.
Lo que hará será crear la estructura estática de la aplicación y almacenarla en la conversación
web para que se acceda desde los controladores secundarios que irán creando progresivamente
la estructura de lo que se convertirá en un extracto compatible con el estándar ISO/EN 13606.
Al �nal de la clase se encuentra el método que implementa la interfaz register(). Por lo
general, este método contendrá una funcionalidad relevante en las ENTRYs, donde se rellenarán
los ELEMENTs y CLUSTERs que éstas contengan. Conviene reseñar también que esta clase hereda
de la clase ControladorAbstracto. Esta clase abstracta contendrá un método para generar
el �chero XML y que es común a todos los controladores principales. Por este motivo, se ha
decidido incluir esta clase para que los controladores primarios hereden de ella y dispongan de
este método. El método para generar el XML indicará el �n de una conversación web. Nótese
que cualquier componente de la jerarquía del modelo de referencia puede ser controlador
Diseño de la estructura de las aplicaciones web. 47
principal, pues depende del componente raíz que se encuentre en la parte de de�nición de un
arquetipo.
package controlador;
@Name (" controladorat0000 ")
@Scope(value = ScopeType.CONVERSATION)
public class at0000 extends ControladorAbstracto implements Register{
RmFactory factoria = RmFactory.eINSTANCE;
COMPOSITIONT at0000;
SECTION at0001;
ENTRY at0007;
ENTRY at0018;
SECTION at0002;
ENTRY at0012;
ENTRY at0015;
SECTION at0003;
ENTRY at0004;
ENTRY at0005;
ENTRY at0006;
ENTRY at0017;
ENTRY at0037;
CLUSTER at0033;
public void init (){
at0000 = factoria.createCOMPOSITIONT ();
at0001 = factoria.createSECTION ();
at0007 = factoria.createENTRY ();
at0001.getMembers (). add(at0007 );
Contexts.getConversationContext ().set(" at0007",at0007 );
at0018 = factoria.createENTRY ();
at0001.getMembers (). add(at0018 );
Contexts.getConversationContext ().set(" at0018",at0018 );
at0000.getContent (). add(at0001 );
Contexts.getConversationContext ().set(" at0001",at0001 );
at0002 = factoria.createSECTION ();
at0012 = factoria.createENTRY ();
at0002.getMembers (). add(at0012 );
Contexts.getConversationContext ().set(" at0012",at0012 );
at0015 = factoria.createENTRY ();
at0002.getMembers (). add(at0015 );
Contexts.getConversationContext ().set(" at0015",at0015 );
at0000.getContent (). add(at0002 );
Contexts.getConversationContext ().set(" at0002",at0002 );
at0003 = factoria.createSECTION ();
at0004 = factoria.createENTRY ();
at0003.getMembers (). add(at0004 );
Contexts.getConversationContext ().set(" at0004",at0004 );
at0005 = factoria.createENTRY ();
at0003.getMembers (). add(at0005 );
Contexts.getConversationContext ().set(" at0005",at0005 );
at0006 = factoria.createENTRY ();
at0003.getMembers (). add(at0006 );
Contexts.getConversationContext ().set(" at0006",at0006 );
at0017 = factoria.createENTRY ();
at0003.getMembers (). add(at0017 );
Contexts.getConversationContext ().set(" at0017",at0017 );
at0037 = factoria.createENTRY ();
at0033 = factoria.createCLUSTER ();
Diseño de la estructura de las aplicaciones web. 48
Contexts.getConversationContext ().set(" at0033",at0033 );
at0003.getMembers (). add(at0037 );
Contexts.getConversationContext ().set(" at0037",at0037 );
at0000.getContent (). add(at0003 );
Contexts.getConversationContext ().set(" at0003",at0003 );
Contexts.getConversationContext ().set(" at0000",at0000 );
}
public String register () {
return "/ at0000.seam";
}
}
Los controladores secundarios son aquellos componentes de la jerarquía del MR que no for-
man parte de la raíz de un arquetipo. Estos controladores secundarios se generan hasta el
nivel de las ENTRYs. También implementarán la interfaz Register, al igual que sucedía con
el controlador principal. Los controladores secundarios más importantes son los generados
para los componentes ENTRY. Estos controladores contendrán los mapeos de los atributos de
los tipos de datos que contienen los ELEMENTs y CLUSTERs. En el código que aparece a con-
tinuación se muestra el controlador generado para la ENTRY at0007 del arquetipo Informe
de Alta que se encuentra en el Apéndice B. La ENTRY a partir de la cual se está generando
este controlador tiene dos ELEMENTs (at0008 y at0009). El ELEMENT at0008 tiene en su inte-
rior un SIMPLE_TEXT at0010 y el ELEMENT at0009 tiene el DATE at0011. El primer ELEMENT
(at0008) es obligatorio y el segundo (at0009) opcional y ambos tienen una ocurrencia má-
xima de 1. Si se observa el código, se comprobará que los mapeos de�nidos en el Apéndice
A para los tipos de datos SIMPLE_TEXT y DATE se cumplen, ya que el ELEMENT at0008 se
mapea al atributo at0008_at0010_originalText y el ELEMENT at0009 se mapea al atributo
at0009_at0011_date. Además, se puede observar que para este último atributo se procesa
una restricción, ya que la fecha introducida tiene que cumplir el patrón YYYY-MM-DD. Tam-
bién es relevante que cada atributo tenga sus métodos get y set con el �n de que las vistas
puedan acceder a ellos para recuperarlos y/o establecerlos. Tras comentar los atributos, el
método register() es lo más importante que hay que comentar de esta clase. Este método
será llamado cuando en la vista se seleccione un botón para guardar los datos que se han
introducido en un formulario. En el �chero aparece como se recupera la ENTRY at0007 que
se encuentra almacenada en la conversación web para añadirle los ELEMENTs que el usuario
habrá rellenado y que este método se encarga de crear y rellenar. Con este método también se
puede observar la implementación de las restricciones de ocurrencia de los componentes de la
jerarquía del MR. Así, como las ocurrencias de ambos elementos tienen como límite superior
el valor 1, antes de insertar alguna buscará si se ha insertado ya un ELEMENT de este tipo que
cuelgue de la ENTRY que había en la sesión, y en caso a�rmativo, lo borra y lo actualiza con
los nuevos datos en la ENTRY.
package controlador;
@Name (" controladorat0007 ")
@Scope(value = ScopeType.CONVERSATION)
Diseño de la estructura de las aplicaciones web. 49
public class at0007 implements Register{
RmFactory factoria = RmFactory.eINSTANCE;
private String at0008_at0010_originalText = "";
public void setat0008_at0010_originalText(String param ){
this.at0008_at0010_originalText = param;
}
public String getat0008_at0010_originalText (){
return at0008_at0010_originalText;
}
private String at0009_at0011_date = "";
public void setat0009_at0011_date(String param ){
this.at0009_at0011_date = param;
}
@Pattern(regex=
"[0 -9][0 -9][0 -9][0 -9]\\ -((0[1 -9])|(1[0 -2]))\\ -((0[1 -9])|([1 -2][0 -9])|(3[0 -1]))")
public String getat0009_at0011_date (){
return at0009_at0011_date;
}
public String register () {
ENTRY at0007 = (ENTRY)Contexts.getConversationContext (). get(" at0007 ");
ITEM indice;
ELEMENT at0008 = factoria.createELEMENT ();
at0008.setArchetypeId (" at0008 ");
SIMPLETEXT at0008at0010simple_text = factoria.createSIMPLETEXT ();
at0008at0010simple_text.setOriginalText(at0008_at0010_originalText );
at0008.setValue(at0008at0010simple_text );
indice = null;
for (ITEM x:at0007.getItems ()){
String archetypeId = x.getArchetypeId ();
if (archetypeId != null && archetypeId.equals (" at0008 ")){
indice = x;
}
}
if (indice != null){ at0007.getItems (). remove(indice );}
at0007.getItems ().add(at0008 );
ELEMENT at0009 = factoria.createELEMENT ();
at0009.setArchetypeId (" at0009 ");
DATE at0009at0011date = factoria.createDATE ();
if (! at0009_at0011_date.equals ("")){
at0009at0011date.setDate(Utilidades.String2XMLGregorianCalendar(
at0009_at0011_date , "yyyy -mm -dd"));
}
at0009.setValue(at0009at0011date );
indice = null;
for (ITEM x:at0007.getItems ()){
String archetypeId = x.getArchetypeId ();
if (archetypeId != null && archetypeId.equals (" at0009 ")){
indice = x;
}
}
if (indice != null){ at0007.getItems (). remove(indice );}
at0007.getItems ().add(at0009 );
Contexts.getConversationContext ().set(" at0007",at0007 );
return "/ at0007.seam";
}
}
Diseño de la estructura de las aplicaciones web. 50
5.2.3. Clases del paquete beans
En el paquete beans se almacenan los beans generados para los componentes del la jerarquía del
MR que tienen ocurrencia múltiple. Estos beans contienen los atributos mapeados a partir de los
tipos de datos que se encuentran dentro de los componentes, con sus métodos get y set. Lo que se
hará cuando se inserte un componente con ocurrencia múltiple será almacenar en una lista que esté
compuesta por objetos beans del componente los valores, para luego accederlos con la tabla en la
vista.
Veamos un ejemplo para que se entienda mejor el uso de los beans. A continuación se encuentra
el código de la clase bean generada para el ELEMENT at0020 que tiene un atributo SIMPLE_TEXT.
Este atributo tiene ocurrencia múltiple, por lo que es necesario crear una clase bean. Esta clase
contiene los atributos en los que se mapea el tipo SIMPLE_TEXT, con sus métodos get y set.
package beans;
@Name (" elementat0020 ")
@Scope(value = ScopeType.CONVERSATION)
public class Beanat0020{
private String at0020_at0022_originalText = "";
public void setat0020_at0022_originalText(String param ){
this.at0020_at0022_originalText = param;
}
public String getat0020_at0022_originalText (){
return at0020_at0022_originalText;
}
}
Cuando el usuario de la aplicación generada introduzca una nueva ocurrencia para este ELEMENT,
se ejecutará un método llamado insertarElementat0020(). Este método creará un nuevo ELEMENT,
y lo almacenará en la ENTRY correspondiente que habrá recuperado de la sesión. Una vez realizado
esto, lo que hará será crear un objeto de tipo Beanat0020, al que establecerá el valor del campo que
ha introducido el usuario de la aplicación en él. Para �nalizar, almacenará este bean recién creado
en una lista que contiene objetos Beanat0020. Esta lista toma el nombre at0020_list. Este método
se puede consultar en el código que aparece a continuación, el cual pertenece a la ENTRY at0018.
Por último, la tabla que hay en la vista podrá acceder a los beans almacenados en la lista
at0020_list para mostrar al usuario los datos que ya ha insertado. Esta lista también se usará
para restringir las inserciones que realizará el usuario cuando el límite superior del número de
ocurrencias esté acotado.
public void insertarElementat0020 (){
ENTRY at0018 = (ENTRY)Contexts.getConversationContext (). get(" at0018 ");
ITEM indice = null;
ELEMENT at0020 = factoria.createELEMENT ();
at0020.setArchetypeId (" at0020 ");
Beanat0020 beanAuxat0020 = new Beanat0020 ();
SIMPLETEXT at0020at0022simple_text = factoria.createSIMPLETEXT ();
Diseño de la estructura de las aplicaciones web. 51
at0020at0022simple_text.setOriginalText(at0020_at0022_originalText );
at0020.setValue(at0020at0022simple_text );
beanAuxat0020.setat0020_at0022_originalText(at0020_at0022_originalText );
at0018.getItems ().add(at0020 );
at0020_list.add(beanAuxat0020 );
Contexts.getConversationContext ().set(" at0018",at0018 );
}
5.2.4. Clases del paquete clusters
En el paquete clusters se almacenan los beans generados para los CLUSTERs. Estos beans contienen
los atributos mapeados a partir de los tipos de datos que se encuentran dentro de los ELEMENTs que
hay dentro del CLUSTER y las listas con los beans de otros CLUSTERs que estén contenidos dentro
del CLUSTER raíz. Lo que se hará cuando se inserte una ��la� del CLUSTER será almacenarla en una
lista que esté compuesta por objetos del bean generado para el CLUSTER. Esta lista será accedida
posteriormente por la vista para mostrar la estructura de las ��las� del CLUSTER que ya se han
introducido en la aplicación.
Veamos un ejemplo para que se entienda mejor el uso de los beans de los CLUSTERs. En el siguiente
código se encuentra la clase bean generada para el CLUSTER at0033 del arquetipo Informe de Alta
(disponible en el Apéndice B). Este CLUSTER contendrá un ELEMENT cuyo identi�cador es at0034,
que a su vez estará formado por un CODED_TEXT con identi�cador es el at0035. Como se aprecia en
el código, se ha realizado el mapeo del ELEMENT y del tipo de dato que contiene dentro del bean.
package clusters;
@Name (" clusterat0033 ")
@Scope(value = ScopeType.CONVERSATION)
public class Clusterat0033{
private List <Beanat0034 > at0034_list = new ArrayList <Beanat0034 >();
public void setat0034_list(List <Beanat0034 > param){
this.at0034_list = param;
}
public List <Beanat0034 > getat0034_list (){
return at0034_list;
}
private String at0034_at0035_originalText = "";
public void setat0034_at0035_originalText(String param ){
this.at0034_at0035_originalText = param;
}
public String getat0034_at0035_originalText (){
return at0034_at0035_originalText;
}
private String at0034_at0035_displayName = "";
public void setat0034_at0035_displayName(String param){
this.at0034_at0035_displayName = param;
}
public String getat0034_at0035_displayName (){
Diseño de la estructura de las aplicaciones web. 52
return at0034_at0035_displayName;
}
private String at0034_at0035_codeValue = "";
public void setat0034_at0035_codeValue(String param){
this.at0034_at0035_codeValue = param;
}
@Pattern(regex = "\\[( CIE9 )::([0 -9])+(.[0 -9]+)*\\]")
public String getat0034_at0035_codeValue (){
return at0034_at0035_codeValue;
}
}
Cuando se almacena una ��la� en el CLUSTER, se llama a la función registerClusterat0033()
que se encontrará en la ENTRY at0037. El método registerClusterat0033() se encuentra a conti-
nuación. La funcionalidad que realiza es la siguiente: obtiene el CLUSTER at0033 y la ENTRY at0037
(componente padre de la jerarquía del arquetipo) de la conversación web. Tras realizar estas accio-
nes, crea un nuevo ELEMENT. Para este nuevo objeto, establece su identi�cador y genera la estructura
del mismo rellenando el tipo de dato que contiene (CODEDTEXT) con los atributos que almacenan el
valor que ha introducido el usuario en la vista. Una vez creado y rellenado el ELEMENT at0034, lo
añade al CLUSTER at0033 y a su vez, añade el CLUSTER at0033 a la ENTRY at0037. Tras crear la
estructura, almacenará el objeto padre (ENTRY at0037) de nuevo en la conversación web. Otra ac-
ción que tiene que realizar dicho método es la de la creación de una instancia del bean del CLUSTER
(Clusterat0003) para almacenarlo en la lista del CLUSTER con el �n de que la tabla de la vista
acceda a dicha lista para mostrar los datos que el usuario de la aplicación ha insertado.
public void registerClusterat0033 (){
CLUSTER at0033 = (CLUSTER)Contexts.getConversationContext ().get(" at0033 ");
ENTRY at0037 = (ENTRY)Contexts.getConversationContext (). get(" at0037 ");
ELEMENT at0034 = factoria.createELEMENT ();
at0034.setArchetypeId (" at0034 ");
CODEDTEXT at0034at0035coded_text = factoria.createCODEDTEXT ();
CD at0034at0035cd = factoria.createCD ();
at0034at0035cd.setDisplayName(at0034_at0035_displayName );
at0034at0035cd.setCodeValue(at0034_at0035_codeValue );
at0034at0035coded_text.setCodedValue(at0034at0035cd );
at0034at0035coded_text.setOriginalText(at0034_at0035_originalText );
at0034.setValue(at0034at0035coded_text );
at0033.getParts ().add(at0034 );
at0037.getItems ().add(at0033 );
Contexts.getConversationContext ().set(" at0037",at0037 );
Clusterat0033 beanClusterat0033 = new Clusterat0033 ();
beanClusterat0033.setat0034_at0035_originalText(at0034_at0035_originalText );
beanClusterat0033.setat0034_at0035_displayName(at0034_at0035_displayName );
beanClusterat0033.setat0034_at0035_codeValue(at0034_at0035_codeValue );
at0033cluster.add(beanClusterat0033 );
}
Diseño de la estructura de las aplicaciones web. 53
5.2.5. Fichero de propiedades para el árbol de navegación de la aplicación
Para crear el árbol de navegación de la aplicación, es necesario que una clase TreeBean que se
encuentra en el paquete tree, lea un �chero de propiedades y vaya creando el árbol. Este �chero
se creará automáticamente cuando se lea la estructura del arquetipo y contendrá tres tipos de
propiedades para cada componente de la jerarquía del MR de ISO/EN 13606 (excluyendo a los
ELEMENTs y a los CLUSTERs que no se representan en el árbol de navegación). Estos tres tipos de
propiedades son:
Propiedad name. Contendrá el nombre del componente que se está representando.
Propiedad action. Contendrá la vista a la que se redirige el �ujo de la aplicación si se selecciona
ese componente del árbol de navegación.
Propiedad icon. Contendrá el icono que se colocará al lado del nombre del componente en
el árbol de navegación. Este icono dependerá del tipo de componente que se represente en la
jerarquía.
En el siguiente código se encuentra una parte del �chero de propiedades para crear el árbol de
navegación del arquetipo Informe de Alta. Como se puede observar, en este árbol los nodos van
numerados en profundidad. Por ejemplo, la COMPOSITION Informe de alta que se encuentra en la
raíz de la jerarquía recibirá el identi�cador 1, la SECTION Datos demográficos que cuelga de la
COMPOSITION que se acaba de comentar recibirá el identi�cador 1.1 y asi sucesivamente. De esta
forma, se consigue que la clase TreeBean vaya creando el árbol con la jerarquía correspondiente.
1name Informe de alta (*)
1action /at0000.seam
1icon img/composition.png
1.1 name Datos demográficos (*)
1.1 action /at0001.seam
1.1 icon img/section.png
1.1.1 name Datos personales (*)
1.1.1 action /at0007.seam
1.1.1 icon img/entry.png
1.1.2 name Datos de contacto
1.1.2 action /at0018.seam
1.1.2 icon img/entry.png
(...)
5.2.6. Vistas de la aplicación web
Las vistas de las aplicaciones web generadas son los elementos con los que van a interactuar
los usuarios de la misma. Por este motivo, es importante que la interfaz de las aplicaciones web
sean diseñadas de forma sencilla, elegante y cómoda para el usuario �nal. Las vistas generadas en
las aplicaciones web contienen componentes de las librerías de RichFaces y de JSF. Además, se ha
incorporado una hoja de estilo CSS proporcionada por RichFaces con el �n de que la aplicación
tenga una apariencia profesional.
Diseño de la estructura de las aplicaciones web. 54
Para cada uno de los componentes de la jerarquía del RM de ISO/EN 13606, exceptuando a
CLUSTER y a ELEMENT, se crea una vista. Estas vistas contendrán enlaces a los componentes hijos
y cuando la vista a la que se esté accediendo sea la de una ENTRY, se mostrará el formulario para
introducir los valores de los CLUSTERs y los ELEMENTs que contiene. Antes de explicar la estructura
de estas vistas, hay que introducir unas vistas estáticas (no las crea el generador de las aplicaciones
web) y que son utilizadas por las demás vistas.
En la Figura 5.17 se presenta un esquema que muestra la navegación que se puede realizar entre
las vistas de la aplicacion web y las relaciones que tienen estas vistas con los �cheros que de�nen los
'layouts' o los diseños de las vistas. Como viene sucediendo con los ejemplos, las vistas representadas
en dicho esquema estarán basadas en el arquetipo Informe de Alta.
Figura 5.17: Flujo de las aplicaciones web generadas
5.2.6.1. Vistas �jas en las aplicaciones web generadas.
Vista index.html Esta vista será la página de inicio de inicio de las aplicaciones web generadas
y lo único que hará será redirigir el �ujo de la aplicación a la vista home.xhtml.
Vista home.xhtml Esta vista es una de la más importantes de las aplicaciones web generadas.
Será generada automáticamente, pero siempre se usará como punto de entrada de la aplicación. En
esta vista, se mostrará un enlace para acceder a la aplicación. La decisión de colocar el enlace en
esta vista se ha tomado por dos motivos:
Para preparar la herramienta para versiones futuras, con el �n de que se muestre un listado
de enlaces con los formularios de los arquetipos que se pueden editar.
Para iniciar la conversación web. Como ya se comentó en el apartado referente a Seam Frame-
work, las conversaciones servirán para mantener varios hilos dentro de una misma sesión web.
De esta forma, se permitirá la edición de varios formularios a la vez sin que los datos de uno
inter�eran con los demás. Por tanto, al seleccionar el enlace se comenzará una conversación
Diseño de la estructura de las aplicaciones web. 55
web. La forma de iniciar la conversación web se corresponderá con realizar una llamada al
método init() del controlador principal de la aplicación web.
Esta vista se generará automáticamente, pues la expresión de acceso al método init() variará en
función del nombre del controlador principal que sólo se conocerá mientras se esté realizando la
transformación modelo-texto.
Vista template.xhtml Esta plantilla de�nirá el layout de las aplicaciones web, será común a
todas las aplicaciones generadas y contendrá el esqueleto de las vistas. En ella se incluirá una página
como la cabecera de todas las vistas de la aplicación web que contenga el nombre del arquetipo (vista
menu.xhtml) y se dividirá en dos secciones: una sección que contendrá el árbol de navegación de la
aplicación web y otra que albergará al contenido. Esta vista también proporciona un pie de página
común a todas las demás.
Es aquí donde se crea el árbol de navegación haciendo uso del �chero de propiedades y de la
clase TreeBean, que lo irá construyendo usando los componentes tree y treeNode de la librería de
componentes RichFaces.
Vista templatePrincipal.xhtml Esta vista será igual que la anterior, pero con la excepción de
que no se incorporará el árbol de navegación de la apliación web. De�nirá la plantilla de la vista
home.xhtml.
5.2.6.2. Vistas creadas por el generador.
Como ya se ha comentado, se creará una vista por cada componente de la jerarquía del MR
que se encuentre en el modelo semántico del arquetipo que se esté procesando. Sin embargo, no
se crearán vistas para los componentes ELEMENT y CLUSTER porque su representación se encuentra
de�nida en la vista de la ENTRY que lo/s contenga.
Las vistas de la aplicación web utilizan la vista template.xhtml para su formato. Esto permite
que tengan una estructura bien de�nida. Todas las vistas contendrán una cabecera con la codi�cación
de caracteres y el título de la página y un cuerpo con el contenido de la misma. Dentro del contenido
de las vistas es necesario destacar que se encontrarán los tipos de datos contenidos en los ELEMENTs
y los CLUSTERs representados grá�camente, para que el usuario pueda insertar valores.
En las vistas, también se proporciona un botón para guardar los datos introducidos en el formu-
lario, que llamará al método register() de la clase correspondiente para que se cree la estructura
de la aplicación web que luego se almacenará en un extracto compatible con el estándar ISO/EN
13606.
Implementación de los generadores de las aplicaciones web. 56
5.3. Implementación de los generadores de las aplicaciones
web.
En la generación de las aplicaciones web, se han usado tres generadores implementados con
MOFScript:
Model2Java. Este generador leerá el modelo y lo procesará con el �n de crear todas las clases
Java necesarias para el funcionamiento de la aplicación. Para realizar la generación, es nece-
sario que se de�nan una serie de reglas. Estas reglas serán las encargadas de crear la clase
del controlador principal, la clase del ControladorAbstracto, las clases para los controladores
secundarios y las clases beans para los CLUSTERs y ELEMENTs.
Model2Xhtml. Este generador leerá el modelo y lo procesará con el �n de crear todas las vistas
de la aplicación web. Generará una página JSP para cada componente de la jerarquía del
modelo de referencia de ISO/EN 13606, llegando hasta el nivel de ENTRYs. Es decir, no se
generarán estas páginas para los ELEMENTs y CLUSTERs. Además de las vistas para los compo-
nentes de la jerarquía del MR, este generador creará dos vistas de la aplicación: home.xhtml
en el cual se incorporará un enlace al método init() del controlador principal con la �nali-
dad de que se inicie la conversación web y menu.html que se importará en la cabecera de las
vistas generadas y que incorporará tanto el título del arquetipo como un botón para generar
el extracto compatible con el estándar ISO/EN 13606.
Model2Tree. Este generador leerá el modelo y lo procesará con el �n de crear un �chero de
propiedades que sirva para generar el árbol de navegación de la aplicación web. Este �chero
de propiedades se caracterizará por tener para cada componente que se inserte en él una
numeración, que indicará el lugar que ocupa en la jerarquía y tres propiedades: el nombre del
componente, la página a la que se debe redirigir el �ujo de la aplicación en caso de que se
seleccione este componente en el árbol de navegación y el icono que se usará para identi�car
al componente en el árbol de navegación.
Estos son los tres �cheros principales implementados con MOFScript, aunque se han implementado
otros con la �nalidad de modularizar las transformaciones y el desarrollo de la aplicación. Los �cheros
auxiliares que se han generado son:
AccederListas. Este �chero creará el código de acceso desde las vistas a los atributos de los
beans sobre los que se construyan las tablas, con el �n de mostrar las �las de las tablas. Será
utilizado por las reglas del �chero de transformación Model2Xhtml.
CreacionTipoDatos. Este �chero se encargará de de�nir las instrucciones de creación de la
estructura que se serializará a XML para cada tipo de datos. Se utilizará desde las reglas del
�chero de transformación Model2Java.
MapeoTipoDatos. Este �chero realizará la declaración de los atributos en las clases Java para
los mapeos de cada tipo de dato. Lo utilizará el �chero de transformación Model2Java.
Generación del extracto del arquetipo. 57
MapeoTipoDatosVista. Este �chero se encargará de mapear los tipos de datos a componentes
en las vistas. Será utlizado por las reglas del �chero de transformación Model2Xhtml.
RellenarBeanAuxiliar. En este �chero de transformación se de�nirán las reglas sobre cómo
rellenar los beans auxiliares de los ELEMENTs con ocurrencia múltiple y de los CLUSTERs. Lo
utlizará la tranformación de�nida en Model2Java.
Util. Este �chero contendrá utilidades que necesitarán los otros �cheros de transformación
para realizar tareas comunes. En él se incluyen funciones para pasar de una expresión regular
en ISO/EN 13606 a una expresión regular en Java, funciones para obtener los intervalos de
tiempo para las restricciones de�nidas sobre los tipos de datos de tiempo, etc. Será utilizado
por el �chero de transformación Model2Java.
5.4. Generación del extracto del arquetipo.
El �n de las aplicaciones web generadas es que sea posible generar un extracto compatible con
el estándar ISO/EN 13606 donde se almacene toda la información introducida por los usuarios en
la aplicación web.
Como ya se ha comentado en los apartados anteriores de este capítulo, la estructura del extracto
se va creando incrementalmente conforme se van insertando y guardando los datos que el usuario
introduce en la aplicación web. Para crear esta estructura, se han utilizado las clases del modelo de
referencia semántico del estándar ISO/EN 13606. Estas clases son clases generadas automáticamente
a partir de un modelo EMF utilizando la utilidad de generación automática de código de este
framework. Esta utilidad genera a partir de una clase del modelo EMF dos clases en Java: una
interfaz con su clase implementación. Estas clases se instanciarán a través de una clase factoría
(también generada automáticamente) que incluye un método create para cada clase del modelo.
Una vez que el usuario de la aplicación ha introducido toda la información que desea en la
aplicación web, necesitará serializar esta información a XML. Para realizar esta serialización se
utiliza otra característica de EMF. Esta característica permite que a partir de un metamodelo
generado con un XMLSchema, todas las instancias de los modelos construidos a partir de este
metamodelo se puedan serializar conforme al XML Schema original.
5.5. Tarea Ant para la ejecución de los generadores y el des-
pliegue de la aplicación
Para automatizar el proceso de despliegue y ejecución del generador de aplicaciones web se ha
creado una tarea en Ant. Mediante la ejecución de esta tarea se permiten realizar diversas acciones
que el usuario puede indicar, desde generar los �cheros para desplegar la aplicación web, hasta lanzar
la aplicación web sobre un servidor web.
Para hacer esto, en primer lugar se ejecuta la aplicación para generar todas las clases, vistas y
Tarea Ant para la ejecución de los generadores y el despliegue de la aplicación 58
�cheros de con�guración necesarios que formarán la aplicación web. Se reciben como parámetros
de entrada el modelo semántico del arquetipo sobre el que se va a generar la aplicación web y
un �chero PROPERTIES donde se indican los parámetros de con�guración que usará la tarea
Ant, como son la ruta absoluta del metamodelo, los �cheros de las transformaciones, etc. Con este
modelo semántico y el �chero de propiedades se invoca a una aplicación Java que se encargará de
registrar el metamodelo y llamar a los �cheros de transformación para que generen los �cheros de la
aplicación web. A continuación se copian los �cheros generados dentro de la estructura estática de la
aplicación web. Tras esto se compilan las clases generadas, obteniendo como resultado una aplicación
web. A continuación se puede copiar la aplicación generada a un servidor web, por ejemplo a un
Apache Tomcat, y con�gurarlo de manera que se pueda ejecutar sobre el mismo. Al �nal de todo el
proceso realizado mediante la tarea Ant se obtiene una aplicación web sobre el arquetipo de entrada
completamente funcional ejecutándose en la dirección http://localhost:8080/archforms.
En la Figura 5.18 se muestra un esquema resumen de las tareas que realiza Ant para generar,
ejecutar y desplegar la aplicación. Si se desea más información sobre éstas, se puede consultar el
Apéndice C.
Figura 5.18: Tareas realizadas por Ant para generar, ejecutar y desplegar la aplicación web.
Capítulo 6
Conclusiones y vías futuras.
La Historia Clínica Electrónica (HCE) cubre una de las necesidades básicas de cualquier profesio-
nal sanitario: la de acceder a la información clínica de un paciente independientemente de que ésta
se encuentre en sitios geográ�camente dispersos. Esto hace que la compartición de la información
sea un aspecto clave hoy día en el ámbito de la medicina. Actualmente en Europa existe el estándar
ISO/EN 13606 que de�ne la estructura de la HCE y cómo debe llevarse a cabo la compartición de la
misma. Este estándar está basado en el modelo dual, que se caracteriza por separar el conocimiento
y la información en dos niveles de modelado. A la primera capa de modelado se le llama modelo
de referencia (MR) y a la segunda modelo de arquetipos (MA). Es en el MA donde se de�nen los
conceptos clínicos representados mediante arquetipos. El modelo dual permite suplir las carencias
de un enfoque de modelado tradicional cuando la complejidad del dominio es alta y hay una gran
cantidad de cambios.
En el presente trabajo se ha desarrollado un generador automático de aplicaciones web para
la gestión de la Historia Clínica Electrónica que toma como entrada el modelo semántico de un
arquetipo ISO/EN 13606. Con este generador automático se persigue que el personal clínico pueda
generar parte de la HCE de un paciente de forma que se facilite la compartición de la información de
la HCE entre distintas organizaciones. La herramienta desarrollada cubre una carencia dentro del
entorno europeo donde es necesaria la implementación de herramientas que den soporte al reciente
estándar ISO/EN 13606.
El estándar ISO/EN 13606 implementa el modelo dual, de forma que proporciona un MR en el
cual se de�nen los componentes de la HCE. También proporciona los tipos de datos que se usarán
dentro de la HCE y las restricciones que permitirán construir los arquetipos de conceptos clínicos.
El MA de�ne el concepto de arquetipo usando el lenguaje ADL. Sin embargo, este lenguaje sólo
proporciona signi�cado sintáctico a este arquetipo. Por este motivo, como entrada del generador de
aplicaciones se han usado modelos semánticos obtenidos a partir de un �chero ADL de un arquetipo.
Por otro lado, conviene destacar el papel del Desarrollo Software Dirigido por Modelos (DSDM)
en este proyecto. Este enfoque ha permitido procesar los arquetipos como modelos y aprovechar así
las herramientas que ofrece la comunidad DSDM como EMF y MOFScript. Gracias a EMF ha sido
posible la manipulación de los modelos como objetos Java y la generación de los extractos de la HCE
Conclusiones y vías futuras. 60
en XML. El lenguaje MOFScript nos ha facilitado notablemente la generación automática de las
aplicaciones web a partir de los modelos semánticos de los arquetipos. Este lenguaje se caracteriza
por su facilidad de uso ya que permite generar reglas para las metaclases de un metamodelo.
Por su parte, EMF permite la generación de código Java a partir de un metamodelo con el �n de
trabajar con los modelos a través de objetos Java. Se han obtenido las clases Java necesarias para
construir extractos de las HCEs conforme a los arquetipos. Asimismo, las clases generadas permiten
serializar los modelos en formato XML, permitiendo de este modo obtener extractos conformes al
estándar ISO/EN 13606 de la HCE.
Las aplicaciones web han sido generadas para la tecnología JSF de la plataforma Java. JSF ofrece
un modelo de programación web basado en componentes que organiza el código de la aplicación
segun el patrón arquitectónico Modelo-Vista-Controlador. Se ha utilizado el framework RichFaces
para JSF. RichFaces nos ha ofrecido una extensa biblioteca de componentes grá�cos que nos ha
facilitado sensiblemente la visualización de los componentes del modelo de referencia del estándar
ISO/EN 13606.
A pesar de la potencia de JSF y de RichFaces, se ha utilizado el framework Seam para facilitar el
desarrollo de las aplicaciones web. Por un lado, ha simpli�cado la con�guración de las aplicaciones.
Por otro lado, ofrece el concepto de conversación web que permite que un mismo usuario pueda
editar simultáneamente distintos extractos de un mismo arquetipo.
Finalmente, Seam integra Hibernate Validator para la programación de restricciones sobre los
tipos de datos. Esta herramienta ha sido de gran utilidad para la implementación de las restricciones
del modelo de referencia.
Las aplicaciones web generadas proporcionan una serie de bene�cios. En primer lugar, imple-
mentan el modelo arquitectónico Modelo-Vista-Controlador de JSF el cual permite separar la lógica
de negocio de la capa de presentación. Por otro lado, se han utilizado las conversaciones para alma-
cenar los datos dentro de una sesión web, lo que permitirá que se puedan editar varios formularios
de arquetipos a la vez sin que los datos almacenados en la conversación web de la información de un
arquetipo que se está editando inter�eran con los de otro. Otro de los bene�cios destacados de las
aplicaciones web generadas es que se han generado las estructuras para almacenar la información
de los arquetipos usando unas clases generadas por la herramienta EMF que permiten la gestión de
los modelos semánticos de los arquetipos como objetos y la obtención de extractos de HCE a partir
de estos modelos.
Quizás, el inconveniente más destacable de las aplicaciones web generadas es que hay que crear
demasiados controladores (uno por cada componente de la jerarquía del MR llegando hasta el nivel
de ENTRY). Sin embargo, no resulta ningun obstáculo al generar automáticamente las aplicaciones.
Otro de los inconvenientes que se puede presentar es la di�cultad para entender el código MOFScript.
Sin embargo, se ha intentado generar este código de la forma más modular posible y documentando
las reglas de�nidas en él.
Se ha obtenido un generador ejecutado desde Ant que genera una aplicación web y la despliega en
un servidor web. Al generador habrá que indicarle el modelo semántico del arquetipo que el usuario
desea que procese para generar la aplicación web.
Conclusiones y vías futuras. 61
Para concluir, hay que enumerar las vías futuras de este proyecto. Si por algo se caracteriza este
trabajo es por el amplio abanico de desarrollo que se presenta a partir de este punto. En él se pueden
identi�car las siguientes vías futuras:
Metamodelo de interfaz. En el proyecto se han generado directamente las aplicaciones web
a partir de los modelos de arquetipos. La generación modelo a texto ha sido implementada
para la plataforma tecnológica seleccionada (aplicación web JSF para Java). Sería deseable
de�nir un metamodelo de interfaz de usuario independiente de la plataforma (Java, .NET,
Android) y del dispositivo (PDA, móvil, web). A partir de este metamodelo se implementarían
transformaciones modelo-código para distintas plataformas y dispositivos.
Las aplicaciones web podrían ofrecer la edición de extractos de HCE. Actualmente, la aplicación
únicamente genera un extracto compatible con el estándar ISO/EN 13606.
Generación de una sola aplicación web que permita la gestión de varios arquetipos.
Gestión de usuarios. Se hará con la integración de la herramienta en el entorno ArchMS [7].
Acceso a los servidores de terminologías para evitar tener que introducir los códigos en los
formularios.
Apéndice A
Datos detallados de representación de
los Tipos de Datos de ISO/EN 13606
En este apéndice se presentan unas tablas para cada tipo de dato con el �n de que se detallen
sus atributos, los tipos de estos atributos, el mapeo de los atributos que se realiza a Java cuando
se generan automáticamente las aplicaciones web y los componentes que usarán las vistas para
representarlos. De las tablas, nótese que todos los atributos mapeados empiezan por un identi�cador
(id). Este identi�cador estará compuesto por el identi�cador del elemento y el del tipo de datos que
se de�na en el arquetipo. Por ejemplo, si en un arquetipo hay un elemento con identi�cador at0001
y contiene un tipo DATE con identi�cador at0002, el mapeo a una variable Java de este elemento
será at0001_at0002_date.
Anexos, Datos detallados de representación de los Tipos de Datos de ISO/EN 13606 63
Anexos, Datos detallados de representación de los Tipos de Datos de ISO/EN 13606 64
Anexos, Datos detallados de representación de los Tipos de Datos de ISO/EN 13606 65
Anexos, Datos detallados de representación de los Tipos de Datos de ISO/EN 13606 66
Apéndice B
Arquetipo Informe de Alta en ADL
En este Apéndice se muestra el código ADL del arquetipo Informe de Alta con el �n de que el
lector del proyecto pueda recurrir a él cuando se están explicando los aspectos de implementación
del mismo poniendo como ejemplo a este arquetipo.
archetype
CEN−EN13606−COMPOSITION. informe_de_alta . v1
concept
[ at0000 ]
language
or ig ina l_language = <[ISO_639−1: : e s ]>
d e s c r i p t i o n
or ig ina l_author = <
[" date " ] = <"20080201">
[" emai l " ] = <"damoca@upv . es">
["name" ] = <"David Moner Cano">
[" o r gan i s a t i on " ] = <"IBIME−ITACA−UPV">>
l i f e c y c l e_ s t a t e = <"Draft">
d e t a i l s = <
[" es " ] = <
language = <[ISO_639−1: : e s ]>
purpose = <"Informe de a l t a gené r i c o para e l CHGUV, base para e l
d e s a r r o l l o de l r e s t o de in formes .">
copyr ight = <"(c )2008 − IBIME , CHGUV">
use = <"Como base para e l d e s a r r o l l o de a rque t ipo s más e s p e c i a l i z a d o s .">
misuse = <"No usar como p l a n t i l l a para generar un informe .">
>
>
d e f i n i t i o n
COMPOSITION[ at0000 ] occur r ence s matches { 1 . . 1 } matches {
content c a r d i n a l i t y matches { 3 . . 3 ; ordered ; unique } matches {
SECTION[ at0001 ] occur r ence s matches { 1 . . 1 } matches {
members c a r d i n a l i t y matches { 1 . . 2 ; ordered ; unique } matches {
ENTRY[ at0007 ] occur r ence s matches { 1 . . 1 } matches {
items ex i s t en c e matches { 0 . . 1 } c a r d i n a l i t y matches { 1 . . 2 ; ordered ;
unique } matches {
ELEMENT[ at0008 ] occur r ence s matches { 1 . . 1 } matches {
value matches {
Anexos, Arquetipo Informe de Alta en ADL 68
SIMPLE_TEXT[ at0010 ] occur r ence s matches { 1 . . 1 } matches {
o r i g i na lTex t matches {/.∗/}}
}
}
ELEMENT[ at0009 ] occur r ence s matches { 0 . . 1 } matches {
value matches {
DATE[ at0011 ] occur r ence s matches { 1 . . 1 } matches {
date matches {yyyy−mm−dd}}
}
}
}
}
ENTRY[ at0018 ] occur r ence s matches { 0 . . 1 } matches {
items ex i s t en c e matches { 0 . . 1 } c a r d i n a l i t y matches { 0 . . ∗ ; ordered ;
unique } matches {
ELEMENT[ at0019 ] occur r ence s matches { 0 . .∗} matches {
value matches {
SIMPLE_TEXT[ at0021 ] occur r ence s matches { 1 . . 1 } matches {
o r i g i na lTex t matches {/.∗/}}
}
}
ELEMENT[ at0020 ] occur r ence s matches { 0 . .∗} matches {
value matches {
SIMPLE_TEXT[ at0022 ] occur r ence s matches { 1 . . 1 } matches {
o r i g i na lTex t matches {/.∗/}}
}
}
}
}
}
}
SECTION[ at0002 ] occur r ence s matches { 1 . . 1 } matches {
members c a r d i n a l i t y matches { 1 . . 2 ; ordered ; unique } matches {
ENTRY[ at0012 ] occur r ence s matches { 1 . . 1 } matches {
items ex i s t en c e matches { 0 . . 1 } c a r d i n a l i t y matches { 2 . . 2 ; ordered ;
unique } matches {
ELEMENT[ at0013 ] occur r ence s matches { 1 . . 1 } matches {
value matches {
DATE[ at0023 ] occur r ence s matches { 1 . . 1 } matches {
date matches {yyyy−mm−dd}}
}
}
ELEMENT[ at0014 ] occur r ence s matches { 1 . . 1 } matches {
value matches {
DATE[ at0024 ] occur r ence s matches { 1 . . 1 } matches {
date matches {yyyy−mm−dd}}
}
}
}
}
ENTRY[ at0015 ] occur r ence s matches { 0 . . 1 } matches {
items ex i s t en c e matches { 0 . . 1 } c a r d i n a l i t y matches { 0 . . ∗ ; unordered ;
unique } matches {
ELEMENT[ at0016 ] occur r ence s matches { 0 . .∗} matches {
value ex i s t en c e matches { 0 . . 1 } matches {
SIMPLE_TEXT[ at0025 ] occur r ence s matches { 0 . . 1 } matches {
Anexos, Arquetipo Informe de Alta en ADL 69
o r i g i na lTex t matches {/.∗/}}
}
}
}
}
}
}
SECTION[ at0003 ] occur r ence s matches { 1 . . 1 } matches {
members c a r d i n a l i t y matches { 1 . . 5 ; ordered ; unique } matches {
ENTRY[ at0004 ] occur r ence s matches { 0 . . 1 } matches {
items c a r d i n a l i t y matches { 1 . . 1 ; unordered ; unique } matches {
ELEMENT[ at0026 ] occur r ence s matches { 1 . . 1 } matches {
value matches {
SIMPLE_TEXT[ at0027 ] occur r ence s matches { 1 . . 1 } matches {
o r i g i na lTex t matches {/.∗/}}
}
}
}
}
ENTRY[ at0005 ] occur r ence s matches { 0 . . 1 } matches {
items ex i s t en c e matches { 0 . . 1 } c a r d i n a l i t y matches { 1 . . 1 ; unordered ;
unique } matches {
ELEMENT[ at0028 ] occur r ence s matches { 1 . . 1 } matches {
value matches {
SIMPLE_TEXT[ at0029 ] occur r ence s matches { 1 . . 1 } matches {
o r i g i na lTex t matches {/.∗/}}
}
}
}
}
ENTRY[ at0006 ] occur r ence s matches { 0 . . 1 } matches {∗}ENTRY[ at0017 ] occur r ence s matches { 0 . . 1 } matches {
items c a r d i n a l i t y matches { 1 . . 1 ; unordered ; unique } matches {
ELEMENT[ at0038 ] occur r ence s matches { 1 . . 1 } matches {
value matches {
SIMPLE_TEXT[ at0039 ] occur r ence s matches { 1 . . 1 } matches {
o r i g i na lTex t matches {/.∗/}}
}
}
}
}
ENTRY[ at0037 ] occur r ence s matches { 1 . . 1 } matches {
items c a r d i n a l i t y matches { 2 . . 3 ; ordered ; unique } matches {
ELEMENT[ at0030 ] occur r ence s matches { 1 . . 1 } matches {
value ex i s t e n c e matches { 0 . . 1 } matches {
CODED_TEXT[ at0031 ] occur r ence s matches { 0 . . 1 } matches {
codedValue matches {
CD[ at0032 ] occur r ence s matches { 0 . . 1 } matches {
codeValue matches {/.∗/}displayName matches {/.∗/}codingSchemeName matches {"CIE9"}
}
}
o r i g i na lTex t matches {∗}}
}
}
CLUSTER[ at0033 ] occur r ence s matches { 0 . . 1 } matches {
Anexos, Arquetipo Informe de Alta en ADL 70
part s e x i s t e n c e matches { 0 . . 1 } c a r d i n a l i t y matches { 0 . . ∗ ; unordered ;
unique } matches {
ELEMENT[ at0034 ] occur r ence s matches { 0 . .∗} matches {
value ex i s t e n c e matches { 0 . . 1 } matches {
CODED_TEXT[ at0035 ] occur r ence s matches { 0 . . 1 } matches {
o r i g i na lTex t matches {∗}codedValue matches {
CD[ at0036 ] occur r ence s matches { 0 . . 1 } matches {
codeValue matches {/.∗/}codingSchemeName matches {"CIE9"}
displayName matches {/.∗/}}
}
}
}
}
}
}
ELEMENT[ at0040 ] occur r ence s matches { 1 . . 1 } matches {
value matches {
BL[ at0041 ] occur r ence s matches { 1 . . 1 } matches {
value matches { true , f a l s e }
}
}
}
}
}
}
}
}
}
onto logy
t e rm ino l og i e s_ava i l ab l e = <...>
te rm_de f in i t i ons = <
[" es " ] = <
items = <
[" at0000 " ] = <
text = <"Informe de a l t a">
de s c r i p t i o n = <"informe_de_alta">
>
[" at0001 " ] = <
text = <"Datos demográ f i cos">
de s c r i p t i o n = <"This i s a SECTION ob j e c t">
>
[" at0002 " ] = <
text = <"Datos admin i s t r a t i vo s">
de s c r i p t i o n = <"This i s a SECTION ob j e c t">
>
[" at0003 " ] = <
text = <"Datos c l í n i c o s ">
de s c r i p t i o n = <"This i s a SECTION ob j e c t">
>
[" at0004 " ] = <
text = <"Motivo de ing r e s o">
de s c r i p t i o n = <"This i s a SECTION ob j e c t">
>
[" at0005 " ] = <
text = <"Antecedentes">
de s c r i p t i o n = <"This i s a SECTION ob j e c t">
>
[" at0006 " ] = <
Anexos, Arquetipo Informe de Alta en ADL 71
t ext = <"Curso c l í n i c o ">
de s c r i p t i o n = <"This i s a SECTION ob j e c t">
>
[" at0007 " ] = <
text = <"Datos pe r s ona l e s">
de s c r i p t i o n = <"This i s a ENTRY ob j e c t">
>
[" at0008 " ] = <
text = <"Nombre">
de s c r i p t i o n = <"This i s a ELEMENT ob j e c t">
>
[" at0009 " ] = <
text = <"Fecha de nacimiento">
de s c r i p t i o n = <"This i s a ELEMENT ob j e c t">
>
[" at0012 " ] = <
text = <"Fechas de l proceso a s i s t e n c i a l ">
de s c r i p t i o n = <"This i s a ENTRY ob j e c t">
>
[" at0013 " ] = <
text = <"Fecha de i ng r e s o">
de s c r i p t i o n = <"This i s a ELEMENT ob j e c t">
>
[" at0014 " ] = <
text = <"Fecha de a l t a">
de s c r i p t i o n = <"This i s a ELEMENT ob j e c t">
>
[" at0015 " ] = <
text = <"Otros">
de s c r i p t i o n = <"This i s a ENTRY ob j e c t">
>
[" at0016 " ] = <
text = <"Procedencia">
de s c r i p t i o n = <"This i s a ELEMENT ob j e c t">
>
[" at0017 " ] = <
text = <"Tratamiento">
de s c r i p t i o n = <"This i s a ENTRY ob j e c t">
>
[" at0018 " ] = <
text = <"Datos de contacto">
de s c r i p t i o n = <"This i s a ENTRY ob j e c t">
>
[" at0019 " ] = <
text = <"Domic i l i o">
de s c r i p t i o n = <"This i s a ELEMENT ob j e c t">
>
[" at0020 " ] = <
text = <"Telé fono">
de s c r i p t i o n = <"This i s a ELEMENT ob j e c t">
>
[" at0010 " ] = <
text = <"SIMPLE_TEXT">
de s c r i p t i o n = <"This i s a SIMPLE_TEXT ob j e c t">
>
[" at0011 " ] = <
text = <"DATE">
de s c r i p t i o n = <"This i s a DATE ob j e c t">
>
[" at0021 " ] = <
text = <"SIMPLE_TEXT">
de s c r i p t i o n = <"This i s a SIMPLE_TEXT ob j e c t">
Anexos, Arquetipo Informe de Alta en ADL 72
>
[" at0022 " ] = <
text = <"SIMPLE_TEXT">
de s c r i p t i o n = <"This i s a SIMPLE_TEXT ob j e c t">
>
[" at0023 " ] = <
text = <"DATE">
de s c r i p t i o n = <"This i s a DATE ob j e c t">
>
[" at0024 " ] = <
text = <"DATE">
de s c r i p t i o n = <"This i s a DATE ob j e c t">
>
[" at0025 " ] = <
text = <"SIMPLE_TEXT">
de s c r i p t i o n = <"This i s a SIMPLE_TEXT ob j e c t">
>
[" at0026 " ] = <
text = <"Desc r ipc ión de l motivo de i ng r e s o">
de s c r i p t i o n = <"This i s a ELEMENT ob j e c t">
>
[" at0027 " ] = <
text = <"SIMPLE_TEXT">
de s c r i p t i o n = <"This i s a SIMPLE_TEXT ob j e c t">
>
[" at0028 " ] = <
text = <"Desc r ipc ión de antecedentes">
de s c r i p t i o n = <"This i s a ELEMENT ob j e c t">
>
[" at0029 " ] = <
text = <"SIMPLE_TEXT">
de s c r i p t i o n = <"This i s a SIMPLE_TEXT ob j e c t">
>
[" at0030 " ] = <
text = <"Diagnóst i co p r i n c i p a l ">
de s c r i p t i o n = <"This i s a ELEMENT ob j e c t">
>
[" at0031 " ] = <
text = <"CODED_TEXT">
de s c r i p t i o n = <"This i s a CODED_TEXT ob j e c t">
>
[" at0032 " ] = <
text = <"CD">
de s c r i p t i o n = <"This i s a CD ob j e c t">
>
[" at0033 " ] = <
text = <"Diagnós t i co s s e cundar i o s">
de s c r i p t i o n = <"This i s a CLUSTER ob j e c t">
>
[" at0034 " ] = <
text = <"Diagnóst i co secundar io">
de s c r i p t i o n = <"This i s a ELEMENT ob j e c t">
>
[" at0035 " ] = <
text = <"CODED_TEXT">
de s c r i p t i o n = <"This i s a CODED_TEXT ob j e c t">
>
[" at0036 " ] = <
text = <"CD">
de s c r i p t i o n = <"This i s a CD ob j e c t">
>
[" at0037 " ] = <
Anexos, Arquetipo Informe de Alta en ADL 73
t ext = <"Diagnóst i co">
de s c r i p t i o n = <"This i s a ENTRY ob j e c t">
>
[" at0038 " ] = <
text = <"Desc r ipc ión de tratamiento">
de s c r i p t i o n = <"This i s a ELEMENT ob j e c t">
>
[" at0039 " ] = <
text = <"SIMPLE_TEXT">
de s c r i p t i o n = <"This i s a SIMPLE_TEXT ob j e c t">
>
[" at0040 " ] = <
text = <"Exitus">
de s c r i p t i o n = <"This i s a ELEMENT ob j e c t">
>
[" at0041 " ] = <
text = <"BL">
de s c r i p t i o n = <"This i s a BL ob j e c t">
>
>
>
>
con s t r a i n t_de f i n i t i o n s = <
>
term_binding = <
>
constra int_bind ing = <
>
Apéndice C
La tarea Ant. Detalles y
consideraciones para ejecutar el
generador
Para realizar la generación del proyecto y el despliegue de la aplicación web resultante en un
servidor web, se ha utilizado Ant. Según el guión realizado, Ant tiene que recibir dos argumentos y
la acción a ejecutar. Los argumentos son:
Dmodel: para especi�car la ruta del modelo que se va a utilizar. Los modelos que hay disponibles
para ejecutar el generador archforms se encuentran en el directorio modelos, que cuelga del
directorio raíz del software entregado con el proyecto.
Dprop: para especi�car la ruta del �chero de propiedades. En este �chero se sitúan todos los
parámetros necesarios para la creación y ejecución de la aplicación web, los cuáles pueden ser
modi�cados por el usuario en función de la con�guración de su sistema y sus preferencias. Las
propiedades que hay que con�gurar son los siguientes:
• pathTransformation. Ruta absoluta que indica donde se encuentran los �cheros de trans-
formación modelo-texto desarrollados en MOFScript.
• pathTargetMetamodel. Ruta absoluta donde se encuentra situado el metamodelo. Éste se
encuentra en el directorio metamodelo dentro del directorio raíz del software del proyecto.
• uriTargetMetamodel. URI del metamodelo. Esta URI es http:///org/eclipse/CenOWL.ecore
y no cambiará.
• pathModel2JavaTransformation. Ruta absoluta del lugar donde se encuentra el �chero
Model2Java.m2t, que será el encargado de generar las clases Java.
• pathModel2XhtmlTransformation. Ruta absoluta del lugar donde se encuentra el �chero
Model2Xhtml.m2t, que será el encargado de generar las vistas de las aplicaciones web.
Anexos, La tarea Ant. Detalles y consideraciones para ejecutar el generador 75
• pathModel2TreeTransformation. Ruta absoluta del lugar donde se encuentra el �chero
Model2Tree.m2t, que será el encargado de generar el �chero de propiedades del árbol de
navegación de la aplicación web.
• rootDirectory. Directorio donde se generan los �cheros de la aplicación web.
• base. Ruta absoluta del directorio donde está situada la aplicación web generada.
• javahome. Ruta absoluta del directorio donde está instalado el JDK de Java que va a ser
usado para compilar y ejecutar las clases de la aplicación web generada.
• tomcathome. Ruta absoluta del directorio donde está instalado el servidor web sobre el
que se desplegará la aplicación.
La acciones que se pueden indicar a Ant para ejecutar el generador son las siguientes:
Acción runjar. Ejecución del proyecto para obtener los �cheros de la aplicación web. Por
ejemplo:
ant -Dprop=propertiesFile.properties
-Dmodel=modelos\OwlCEN-EN13606-ENTRY.Colesterol.v1.xmi runjar
Acción transferir. Transferir los �cheros generados al directorio (y correspondientes subdi-
rectorios) de la aplicación web. Por ejemplo:
ant -Dprop=propertiesFile.properties
-Dmodel=modelos\OwlCEN-EN13606-ENTRY.Colesterol.v1.xmi transferir
Acción compilar. Compilar las clases recién generadas para crear la aplicación web. Por ejem-
plo:
ant -Dprop=propertiesFile.properties
-Dmodel=modelos\OwlCEN-EN13606-ENTRY.Colesterol.v1.xmi compilar
Acción copiar. Copia el directorio de la aplicación web dentro del directorio webapps del
servidor web. Por ejemplo:
ant -Dprop=propertiesFile.properties
-Dmodel=modelos\OwlCEN-EN13606-ENTRY.Colesterol.v1.xmi copiar
Acción startup. Arrancar el servidor web con la aplicación recién generada funcionando. Por
ejemplo:
ant -Dprop=propertiesFile.properties
-Dmodel=modelos\OwlCEN-EN13606-ENTRY.Colesterol.v1.xmi startup
Cuando se ejecuta esta acción, la aplicación web se estará ejecutando sobre el servidor. Se podrá
acceder a ella introduciendo la siguiente dirección en un navegador: http://localhost:8080/archforms.
Dado que se ha utilizado Ant, se ha establecido claramente un orden de dependencias para la
ejecución de cada una de las tareas o acciones. De este modo, en la línea de comandos sólo es
Anexos, La tarea Ant. Detalles y consideraciones para ejecutar el generador 76
necesario especi�car la acción que se quiere realizar (por ejemplo startup), ya que se realizarán
automáticamente todas las acciones anteriores que sean necesarias para la correcta ejecución de esta
última.
Cuando se va a generar una nueva aplicación empleando un nuevo modelo, resulta una buena
práctica eliminar todos los �cheros de la aplicación generada con el modelo anterior. Para hacer esto
se emplea:
ant clean
Apéndice D
Vistas de la aplicación web generada
para el arquetipo Informe de Alta
En este apéndice se muestran las vistas generadas por el generador ArchForms con el �n de que
el lector obtenga una visión global de la aplicación.
La Figura D.1 muestra la vista generada para la COMPOSITION at0000. En ella se puede observar
en la parte izquierda el árbol de navegación de la aplicación y en la parte de contenido una serie de
enlaces que llevan a las vistas de las SECTIONs que cuelgan de at0000.
Figura D.1: Vista generada para la COMPOSITION at0000
En la Figura D.2 se muestra la vista para la ENTRY at0007, llamada datos personales. Como se
puede apreciar en la �gura, se presenta un formulario para insertar los dos ELEMENTs que se declaran
dentro de la ENTRY en el arquetipo.
Anexos, Vistas de la aplicación web generada para el arquetipo Informe de Alta 78
Figura D.2: Vista generada para la ENTRY at0007
En la Figura D.3 se encuentra la vista para la ENTRY at0018. En esta ENTRY se de�nen dos
ELEMENTs con ocurrencia múltiple. Como se puede observar en la siguiente �gura, se permite insertar
más de un ELEMENT en la aplicación.
Figura D.3: Vista generada para la ENTRY at0018
En la Figura D.4 se muestra la vista para la ENTRY at0012. En ella se de�nen dos ELEMENTs que
contienen un tipo de dato DATE.
Anexos, Vistas de la aplicación web generada para el arquetipo Informe de Alta 79
Figura D.4: Vista generada para la ENTRY at0012
En la Figura D.5 se muestra la vista para la ENTRY at0015.
Figura D.5: Vista generada para la ENTRY at0015
En la Figura D.6 se muestra la vista de la ENTRY at0004.
Anexos, Vistas de la aplicación web generada para el arquetipo Informe de Alta 80
Figura D.6: Vista generada para la ENTRY at0004
En la Figura D.7 se muestra la vista generada para la ENTRY at0005
Figura D.7: Vista generada para la ENTRY at0005
En la Figura D.8 se encuentra la vista de la ENTRY at0017.
Anexos, Bibliografía 81
Figura D.8: Vista generada para la ENTRY at0017
En la Figura D.9 se encuentra la vista de la ENTRY at0037. Esta ENTRY aporta algo nuevo con
respecto a las demás, pues permite insertar ��las� en el CLUSTER at0037.
Figura D.9: Vista generada para la ENTRY at0037
Bibliografía
[1] T. Beale. Archetypes: Constraint-based Domain Models for Future-proof Information Sistems.
OOPSA. Año 2002.
[2] J. Clark. XSL Transformation (XSLT) Version 1.0. W3C Recommendation 16 November 1999.
Disponible en http://www.w3.org/TR/xslt.
[3] T. Clark, A. Evans, P. Sammut, J. Williams. Applied Metamodelling, A Foundation for Lan-
guage Driven Development. Año 2004.Health Level Seven. Disponible en http://www.hl7.org
[4] J. Cole, J. D. Gradecki. Mastering Apache Velocity. Wiley Computer Publishing. ISBN:
9780471457947
[5] R.H. Dolin, L. Alschuler. S. Boyer, C. Beebe, F.M. Bethlen, P.V. Biron, A. Shabo. HL7 Clinical
Document Architecture, Release 2. Journal of the American Medical Informatics Association.
13:30-39, año 2006.
[6] Eclipse Modelling Framework Project (EMF). Disponible en
http://www.eclipse.org/modeling/emf/?project=emf
[7] J.T. Fernández-Breis, M. Menárguez-Tortosa, C. Martínez-Costa, E. Fernández-Breis, J. He-
rrero, J. Sánchez Cuadrado, D. Moner, R. Valencia-García, M. Robles. A Semantic Web-based
System for Managing Clinical Archetypes. 30th Annual International Conference of the IEEE
Engineering in Medicine and Biology Society.
[8] R. Filgueira, A. Odriozola, F. Simini. Aplicación de OpenEHR en el desarrollo de SICTI un
sistema de historia clínica para medicina crítica. Congreso Argentino de Bioingeniería, 16. año
2007.
[9] F. Fondement, R. Schnekenburger, S. Gérard, P.A. Muller. Metamodel-Aware Textual Concrete
Syntax Speci�cation. LGL-REPORT-2006-005.
[10] Foundation openEHR. Disponible en http://www.openeht.org/home.html
[11] S. Garde, P. Knaup, E. Hovenga. openEHR Archetypes in Electronic Health Records: the Path
to Semantic Interoperability? Año 2005.
[12] ISO/EN 13606. http://www.iso.org/iso/catalogue_detail.htm?csnumber=40784.
Anexos, Bibliografía 83
[13] C. Martínez-Costa, M. Menárguez-Tortosa, J.A. Maldonado, J.T. Fernández-Breis. Semantic
Web technologies for managing EHR-related clinical knowledge.
[14] OMG's MetaObject Facility. Disponible en http://www.omg.org/mof/
[15] C. Rinner. Electronic health records (EHRs): Data export of health information systems based
on the Entity-Attribute-Value model as CEN prEN 13606 EHR extracts by means of Archetypes.
Tesis doctoral de la Universidad de Tecnología de Viena. Año 2007.
[16] C. Schalk. Introduction to Javaserver Faces - What is JSF?. año 2005.
[17] K. Smith; C. Welty, D. L. McGuinness (2004-02-10). OWL Web Ontology Language Guide.
W3C. Retrieved 2008-07-15.