archforms: generación automática de aplicaciones …...en el centro de está revolución se...

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.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.


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.


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


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 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 = <"*">

>

>

>

>


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].


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-


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


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.


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:


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.


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


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.


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


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.


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-


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.


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


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.


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.


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


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:


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


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


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 );




at0000.getContent (). add(at0001 );

























at0033 = factoria.createCLUSTER ();








}

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 ")



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 );



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 );}



return "/ at0007.seam";

}

}


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 ")


public class Beanat0020{




}



}

}

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 (){


ITEM indice = null;



Beanat0020 beanAuxat0020 = new Beanat0020 ();

SIMPLETEXT at0020at0022simple_text = factoria.createSIMPLETEXT ();


at0020at0022simple_text.setOriginalText(at0020_at0022_originalText );

at0020.setValue(at0020at0022simple_text );

beanAuxat0020.setat0020_at0022_originalText(at0020_at0022_originalText );


at0020_list.add(beanAuxat0020 );


}

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 ")


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_displayName = "";

public void setat0034_at0035_displayName(String param){

this.at0034_at0035_displayName = param;

}

public String getat0034_at0035_displayName (){


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 ");




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 );



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 );

}


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.


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


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

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 {/.∗/}}

}

}


value matches {

DATE[ at0011 ] occur r ence s matches { 1 . . 1 } matches {

date matches {yyyy−mm−dd}}

}

}

}

}


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 {



}

}


value 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 {


value matches {



}

}


value 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 {


value ex i s t en c e matches { 0 . . 1 } matches {




}

}

}

}

}

}




items c a r d i n a l i t y matches { 1 . . 1 ; unordered ; unique } matches {


value 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 {


value 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 {


value matches {



}

}

}

}


items c a r d i n a l i t y matches { 2 . . 3 ; ordered ; unique } 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 {


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 {


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 {/.∗/}}

}

}

}

}

}

}


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">


>

[" at0003 " ] = <

text = <"Datos c l í n i c o s ">


>

[" at0004 " ] = <

text = <"Motivo de ing r e s o">


>

[" at0005 " ] = <

text = <"Antecedentes">


>

[" at0006 " ] = <


t ext = <"Curso c l í n i c o ">


>

[" 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">


>

[" at0012 " ] = <

text = <"Fechas de l proceso a s i s t e n c i a l ">


>

[" at0013 " ] = <

text = <"Fecha de i ng r e s o">


>

[" at0014 " ] = <

text = <"Fecha de a l t a">


>

[" at0015 " ] = <

text = <"Otros">


>

[" at0016 " ] = <

text = <"Procedencia">


>

[" at0017 " ] = <

text = <"Tratamiento">


>

[" at0018 " ] = <

text = <"Datos de contacto">


>

[" at0019 " ] = <

text = <"Domic i l i o">


>

[" at0020 " ] = <

text = <"Telé fono">


>

[" 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 " ] = <




>

[" at0022 " ] = <



>

[" at0023 " ] = <

text = <"DATE">


>

[" at0024 " ] = <

text = <"DATE">


>

[" at0025 " ] = <



>

[" at0026 " ] = <

text = <"Desc r ipc ión de l motivo de i ng r e s o">


>

[" at0027 " ] = <



>

[" at0028 " ] = <

text = <"Desc r ipc ión de antecedentes">


>

[" at0029 " ] = <



>

[" at0030 " ] = <

text = <"Diagnóst i co p r i n c i p a l ">


>

[" 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">


>

[" 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 " ] = <


t ext = <"Diagnóst i co">


>

[" at0038 " ] = <

text = <"Desc r ipc ión de tratamiento">


>

[" at0039 " ] = <



>

[" at0040 " ] = <

text = <"Exitus">


>

[" 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:


-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:


-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:


-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:


-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.


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.



En la Figura D.5 se muestra la vista para la ENTRY at0015.


En la Figura D.6 se muestra la vista de la ENTRY at0004.



En la Figura D.7 se muestra la vista generada para la ENTRY at0005


En la Figura D.8 se encuentra la vista de la ENTRY at0017.

Anexos, Bibliografía 81


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.


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.

archforms: generación automática de aplicaciones …...en el centro de está revolución se...

Documents