El sistema sanitario, el cual constituye uno de los mayores usuarios potenciales de tecnología multimedia, toda- vía actualmente sigue en gran medida manejando la información clínico- diagnóstica (no así la de gestión) en sus soportes tradicionales: papel, film, cintas de audio y vídeo, etc.

Este retraso es debido a múltiples factores, que van desde aspectos tecnológicos, ya que para los volúmenes de información generados, serían necesarios avances en temas tales como: sistemas distribuidos, ancho de banda en las redes, estaciones de trabajo multimedia, reconocimiento de voz, ’pen computing’, ’work-flow’ automático y otros; pero también (y sobre todo) a aspectos de estandarización. Para poder llegar a una informatización global de la historia clínica, aspecto básico en todo el proceso, es necesario alcanzar un consenso en están- dares sobre: el modelo conceptual y arquitectura; contenido, representación y codificación de la información; comunicaciones y tecnologías involucradas; aspectos operacionales; y aspectos legales. Organizaciones como CEN/TC251/WGs 1-7, ANSI-HISPP que coordina las diferentes organizaciones de EEUU (ASTM, IEEE, HL7, DICOM, ASC, AIIM, NCDP), EWOS-EG/MED, y otras están involucradas en este arduo y complejo proceso.

No obstante, desde una perspectiva de grupo investigador, tampoco se debe dar la espalda a estudios, desarrollos e implementaciones, que permitan evaluar la viabilidad de usar en el campo médico, estándares estrictamente tecnológicos o procedentes de otros campos. En esta línea de trabajo, nuestro grupo ha estudiado la posibilidad de usar dos estándares que se complementan a la hora de soportar la información médica multimedia: SGML (Standard Generalized Markup Language, ISO 8879 [1]) y ODA (Open Document Architecture, ISO 8615, ITU-T Rec.410 [2] [3]). Cada uno enfoca el problema de procesado e intercambio de documentos multimedia de forma diferente. Ambos son mencionados como posibles formatos de intercambio por el CEN/TC251/PT004 [8] [9] y IEEE P1157 MEDIX [10] [11].

Después de un breve resumen de ambos estándares - haciendo especial mención de los inconvenientes que presentan y una comparación entre ellos, se presenta en este artículo un conversor bidireccional SGMLODA desarrollado en nuestro Laboratorio y las conclusiones obtenidas.

SGML es un estándar internacionalmente aceptado que soporta diferentes tipos de contenido, así como la estructuración lógica del documento. Como su propio nombre indica, constituye un lenguaje y una notación para la descripción de clases de documentos. Un documento codificado según este están- dar se estructura en una serie de elementos (párrafos, subsecciones, apéndices, figuras, etc.) delimitados con strings de caracteres común- mente llamados tags.

Un documento SGML tiene tres partes :

• Declaración SGML
• Declaración de tipo de documento (DTD)
• Instancia de Documento

La declaración SGML caracteriza la DTD y, por tanto, las instancias de documento (que incluyen el contenido propiamente dicho) que se generen a partir de ella, en términos de conjunto de caracteres usados y otros puntos opcionales de SGML.

Esta declaración puede ser omitida, en cuyo caso se asumen unos grupos de caracteres por defecto y ninguna característica opcional. Una clase de documentos tiene en común una gramática que define el marcado permitido en esa clase, el marcado requerido, y cómo debe ser utilizado dicho marcado en la instancia de documento. El estándar define esta gramática mediante la DTD. SGML no especifica ningún conjunto particular de elementos; el conjunto de elementos que pueden ser usados se define en la DTD. Existe la posibilidad de hacer referencia a una DTD pública, mezclar definiciones originales con la DTD pública o generar una DTD original. La DTD es necesaria.

De lo anterior se puede deducir que la instancia de documento lleva el contenido estructurado según el marco definido en la DTD, y con las características fijadas por la declaración SGML. Sin embargo, SGML presenta dos inconvenientes importantes:

SGML no permite incorporar información de apariencia o layout del documento. Para solventar esta carencia otro estándar está siendo desarrollado: Document Style and Semantics Specification Language (DSSSL). t41 no permite el intercambio abierto. Este estándar permite absoluta libertad en lo que a forma- tos de contenido se refiere. Aquí radica tanto su potencia como su gran inconveniente. Es esta libertad la que ha originado su enorme aceptación comercial, pero la que lo hace inútil para el intercambio entre sistemas heterogéneos sin previo acuerdo entre las partes y sin un tren de conversores que abarque todas las posibilidades.

La Arquitectura Abierta de Documento y su Formato de Intercambio (ODIF) fueron diseñados esencialmente para facilitar el intercambio de documentos en un entorno heterogéneo. La codificación en ODA de un documento separa la información referente a su estructura de la información de con- tenido.

ODA se basa en la siguiente distinción para definir su modelo estructural. Dentro de un documento se pueden definir dos partes: una que constituiría el aspecto físico o visión de disposición del documento. Abarcaría todos aquellos elementos que permiten a la aplicación encargada de su presentación decidir acerca de márgenes, tamaños, color, organización en bloques, páginas, etc. otro que constituiría la visión del documento como conjunto de componentes abstractos o lógicos, componentes resultantes de una división del mismo en función de su significado. Por ejemplo, un conjunto de capítulos de un texto.

El concepto de estructura e clave en esta arquitectura. Resulta por tanto, de la división y subdivisión repetida del contenido del documento en partes cada vez más pequeñas denominadas objeto Dependiendo de que estas divisiones se hagan con arreglo a la disposición o al significado, tendremos las estructuras de disposición o las lógicas, respectivamente. ODA define un documento como un árbol. estructura del documento es especificada por la forma del árbol, donde los nodos representan objetos compuestos y las hojas representan objetos básicos. El contenido del documento (porciones de contenido), sólo puede estar asociado con las hojas del árbol (i.e. objetos básicos). Los atributos proporcionan información sobre los objetos compuestos y básicos.

Un documento ODA se compone, además de las Estructuras Lógicas y/o Estructuras de Disposición, un Perfil de Documento y de Estilos de Presentación y/o Disposición. El estándar permite la representación e intercambio de documentos en tres formas, cada una de las cuales permite al originador declarar intenciones con respecto a la edición, formatación y presentación del documento intercambiado. Estas formas o arquitecturas de documento son las siguientes :

• Formateada (AF), que permite presentar los documentos en la forma prevista por el originador.
• Procesable (AP), que permite editar y formatear los documentos.
• Formateada procesable (AFP), que permite presentar y también editar y reformatear los documentos.

Según se envíe el documento en una forma u otra, habrá partes o constituyentes obligatorios y optativos, como se muestra la siguiente tabla:

El Perfil de Documento constituye un conjunto de atributos que aportan información de gestión - título, nombre del autor, etc. - y un sumario de las características del documento enviado, para que el destinatario pueda determinar fácilmente las capacidades necesarias para editar o presentar el documento.

Los Estilos de Presentación y Disposición añaden información para permitir la visualización del documento según las intenciones del originador.

ODA permite integrar en un mismo documento diferentes tipos de contenido, (texto, imágenes y gráficos geométricos y, reciente- mente, audio) definiendo un formato o arquitectura de contenido para cada uno de ellos:

- Arquitectura de contenido de caracteres : define la representación de porciones de contenido de texto, y permite la utilización de conjuntos estandarizados de caracteres como ISO 6937 y ISO 8895. También especifica una serie de caracteres de control. [5]

- Arquitectura de contenido de Gráficos Raster: define la representación de porciones de contenido, imágenes por puntos (bitmap). [6]

- Arquitectura de contenido de Gráficos Geométricos: utiliza el estándar ISO Computer Graphics Metafile (CGM). [7]

- Arquitectura de contenido de Audio: ha sido definida en noviembre de 1996.

ODA presenta graves inconvenientes:

- Todavía no soporta vídeo.

- Introduce un alto grado de redundancia a la hora de codificar un documento.

- Alto grado de complejidad que entorpece el desarrollo de sistemas basados en este estándar.

ODIF (Office Document Inter- change Format)

ODIF especifica procedimientos para codificar documentos estructurados según ODA, y permitir así su intercambio. ODIF ha sido estandarizado de forma que cumple los requerimientos de representación de documentos para diferentes entornos de aplicación. ODIF es una sintaxis de datos abstracta en la que los constituyentes del documento y sus atributos son representados por una estructura jerárquica, especificada mediante la notación de sintaxis abstracta ASN.1.

La diferencia más importante entre ambos estándares la constituyen las distintas posturas que éstos adoptan frente a la estructuración y procesado de documentos.

SGML es, básicamente, un lengua- je para describir la estructura de documentos. El procesado que se lleve a cabo una vez se ha creado el documento no se trata directamente en el estándar. Sólo se incluye una sintaxis de instrucciones de procesa- do que proporciona comandos para ser embebidos en el markup SGMI.

Adicionalmente, SGML no aporta información de apariencia del documento, es decir, no permite, por sí mismo, que el documento sea presentado en recepción como pretendía el originador. Es necesario el uso de un estándar complementario, DSSSL, como ya se ha mencionado.

La estructura genérica lógica de un documento ODA se corresponde con el concepto SGML de definición de tipo de documento (DTD) . ODA presenta un modelo más amplio de procesado de documento, incluyen- do, además de la creación, su edición y formateado. ODA incorpora información de formateado o de disposición directamente en el documento, a través de las estructuras de disposición y de los estilos de presentación y disposición.

Un fichero ODA contiene un documento completo, por tanto, la distribución de un documento en ODA requiere la transmisión de un único fichero. Sin embargo, un documento SGML consiste en una serie de ficheros independientes.

Es interesante mencionar que debido a su complejidad, ODA está siendo poco desarrollado actualmente; mientras en el entorno de SGML hay numerosas herramientas comerciales ampliamente extendidas.

Como conclusión se puede afirmar que SGML es más apropiado para la edición y almacenamiento, mientras que ODA es el que permite un intercambio abierto.

En el marco del proyecto HIPERMED del programa PASO, nuestro grupo ha desarrollado un conversor de un estándar a otro.

Un filtro que permita la conversión entre ambos estándares debe operar tanto a nivel estructural como de contenido, y contemplar las siguientes características: pérdidas mínimas automático, manejan- do una variedad amplia de documentos con intervención mínima del usuario pero nunca a expensas de la fiabilidad.

La DTD del documento contiene información estructural de la clase de documentos a la que éste pertenece. Esta información debe mantener- se en el documento ODA, bien como parte de la estructura específica lógica, bien como parte de la estructura genérica del documento (EGL).

La esencia del problema a nivel estructural es :

• en una conversión ODA - SGML, generar una DTD SGML compatible con la estructura genérica ODA de la que se parte.
• en una conversión SGML - ODA, generar una EGL ODA compatible con la DTD SGML de que se parte.

Una DTD SGML y una EGLODA son compatibles si y sólo si:

• Cada elemento de la DTD se corresponde exactamente con un objeto de la EGL y viceversa.
• El atributo generador de subordinados de cada objeto compuesto de la EGL es equivalente al modelo de contenido del elemento correspondiente SGML en la DTD.
• Existe un conjunto generador completo para la EGL.

Una excepción a tener en cuenta la constituyen los objetos lógicos básicos artificiales, cuyo único objetivo es conectar un objeto 1ógico compuesto a una porción de contenido.

Se puede definir la compatibilidad de un modo menos estricto, dependiendo del sentido de conversión. Así, un documento codificado en ODA es suficientemente compatible con una DTD si y sólo si:

• Cada clase de objeto referencia- do en el documento ODA (excluyen- do de nuevo los objetos artificiales) se corresponde exactamente con un elemento de la DTD.
• Cada objeto específico lógico del documento ODA tiene un atributo de subordinados que se corresponde con el modelo de contenido de un elemento de la DTD.

De modo similar un documento codificado en SGML es suficientemente compatible con una EGL si y sólo si:

• Cada elemento usado en el documento SGML se corresponde exactamente con una clase definida en la EGL.
• Los elementos del documento SGML siguen lo indicado en los atributos generadores de subordinados de los distintos objetos lógicos genéricos.

Surge aquí de nuevo el concepto de compatibilidad, en este caso a nivel de contenido: el texto ODA habrá de ser "escaneado" en busca de caracteres especiales que constituyan funciones de control. Muchas DTDs facilitan elementos con el mismo objetivo. En este caso la con- versión es directa. El contenido ODA no textual, como pueden ser las imágenes, gráficos vectoriales y audio, debe ser situada en ficheros separados e introducido en el documento SGML como referencias a entidades (entity references), mediante atributos de los elementos, o mediante la característica NDATA.

En nuestro caso previamente a I; realización del filtro, se realizaron dos conversores: un codificador di formato TIFF a ODA, y otro de formato CGM a ODA, así como los inversos. Se eligieron estos formatos par las imágenes ráster y los gráficos geométricos ya que son los que emplea la aplicación HIPERMED por su sencillez y por constituir estándares "de facto" en sus respectivos campos. No se implementó sin embargo ningún conversor de audio a ODA, ya que en el momento de la especificación y comienzo del proyecto, aún no había sido definida la Arquitectura de contenido de Audio en ODA. A continuación se presenta el diagrama de bloques del filtro para ambas conversiones :

Conversión SGML/ODA

Conversión ODA/SGML

Un filtro SGMLODA no puede hacerse tan genérico como se desee, es necesario conocer previa- mente la DTD (o DTDs) con las que van a trabajar los sistemas, y el filtro estará adaptado específicamente a ese tipo de documentos.

En nuestro caso hemos desarrollado el filtro sobre las DTDs que emplea la aplicación HIPERMED, diseñadas de acuerdo con las especificaciones del Departamento de Neurología de la Clínica Puerta de Hierro de Madrid, y del Departamento de Salud Pública e Historia de la Facultad de Medicina de la Universidad Complutense de Madrid.

A nivel estructural, simplemente citar que la EGL de los documentos ODA generados es totalmente compatible con la DTD de los documentos con los que trabaja la aplicación.

Como ya se ha comentado, el filtro realizado no permite la conversión de ficheros de audio a ODA. Esto es así ya que la Arquitectura de Contenido de Audio en ODA no ha sido definida hasta noviembre de 1996, cuando el proyecto estaba prácticamente finalizado; de modo que en el caso de que la carpeta de paciente en SGML contenga algún fichero de este tipo, la información

se perderá al realizar la conversión a ODA .

En el apartado de pérdidas, aparte de las ya mencionadas referentes a los ficheros de audio, sólo se producen unas mínimas en las imágenes ráster, debido a que el formato TIFF y la Arquitectura de contenido de imágenes por puntos definida por ODA no son totalmente compatibles. Con los gráficos geométricos no ocurre esto, ya que la Arquitectura de contenido de gráficos geométricos definida por ODA está basada en el formato CGM.

[1] ISO 8879. "Structured Generalized Markup Language and Interchange Format". International Organization for Standardization, 1986.

[2] ISO 8613. "Information Technology - Open Document Architecture (ODA) and Interchange Format". International Organization for Standardization, 1993.

[3] Recommendations in the T.410- T.418 series. "Information Technology - Open Document Architecture (ODA) and Interchange Format". International Telecommunication Union (Telecommunication Standardization Sector), 1992. [4] ISO/IEC CD 10179. "Information Technology- Text and Office Systems - Document Style and Semantics Specification Language (DSSSL)", 1991.

[5] ISO/IEC 8613-6. "Information Technology - Open Document Architecture (ODA) and Interchange For- mat - Character Content Architecture", International Organization for Standardization, 1993.

[6] ISO/IEC 8613-7. "Information Technology - Open Document Architecture (ODA) and Interchange Format - Part 7: Raster Graphics Content Architecture", International Organization for Standardization, 1993.

[7] ISO/IEC 8613-7. "Information Technology - Open Document Architecture (ODA) and Interchange For- mat - Part 8: Geometric Graphics Content Architecture", International Organization for Standardization, 1993.

[8] CEN TC-251. "Medical Informatics. Setting the Standards for Health Care Informatics and Telematics. Directory of the European Standardization requirements for Health- care Informatics and Telematics. Draft European Prestandards. Stan- ding documents. Publications. Data bases". CD-ROM Produced by D. Soft, 1994.

[9] CEN TC 251 PT 004. "Investigation of sintaxes for Existing Interchange Formats to be used in Healthcare (MEDIF) ", European" Standardization Committee (CEN), 1993.

[10] IEEE P1157 Medical Data Interchange (Medix) Committee. "Overview and Status Report", 1990. f111 IEEE Standards Project 1157. "Medical Data Interchange (MEDIX) standard Version 2.00", IEEE Engineering in Medicine and Biology Society, 1990.

© El Copyright del presente artículo es propiedad de los autores, los cuales han transferido el mismo a la Sociedad Española de Informática de la Salud (SEIS) para su publicación.