Standardization of Clinical Health Records through CEN/ISO 13606

Estandarización de la Historia Clínica Electrónica a través de la
norma CEN/ISO 13606. Estudios, desarrollos y aplicaciones
R. Somolinos Cristóbal 1 , A. Muñoz Carrero 2
1 Laboratorio de Bioingeniería y Telemedicina, Hospital Universitario Puerta de Hierro Majadahonda, Madrid, España,
rsomolinos@bioing.cph.es
2 Área de Investigación en Telemedicina y Sociedad de la Información, Instituto de Salud Carlos III, Madrid, España,
adolfo.munoz@isciii.es
Resumen
La Historia Clínica Electrónica (HCE) es uno de los temas de
investigación de mayor relevancia dentro del campo de la
Telemedicina. En este artículo se describe la gran apuesta
europea para la normalización e interoperabilidad de las HCE:
la norma CEN/ISO 13606. Nuestro grupo de investigación tiene
una línea de trabajo abierta en este campo, en la que se
encuadran diversos trabajos como el diseño y desarrollo de un
módulo ‘middleware’ servidor de HCE conforme a la norma
ISO 13606, estudios de compatibilidad entre diferentes normas
(modelado del CCR, diseño de mecanismos de armonización
basados en arquetipos) y el desarrollo de un servidor
demográfico conforme a dicha norma e integrado en distintos
ensayos clínicos.
1. Introducción
El seguimiento continuado de los pacientes, su alta
movilidad y los niveles de exigencia hacen que en los
sistemas sanitarios actuales sea necesario el uso de
Historias Clínicas Electrónicas (HCE). Los sistemas de
información tienen que ser capaces de transferir la
información de forma que conserve todo su significado,
independientemente del lugar en que se encuentren. Por
ello un requisito imprescindible que deben cumplir las
HCE es la interoperabilidad. Para cumplir este requisito
se deben normalizar las HCE o, como mínimo, los
mensajes de intercambio de HCE entre sistemas.
La norma europea EN13606 tiene como propósito
normalizar la transferencia entre sistemas de información
de HCE (o de parte de las mismas) de forma que sean
interoperables, pero sin especificar cómo implementar
dichos sistemas. De su elaboración se ha encargado la
Task Force EHRCom, dentro del Working Group 1 del
Comité Técnico 251 -Health Informatics- del Comité
Europeo de Normalización (CEN) [1], siguiendo los
paradigmas actuales en la creación de normas: separación
de puntos de vista, separación de responsabilidades y
separación de información y conocimiento. Esta norma,
que al ser europea es automáticamente adoptada como
norma española UNE, está en proceso de ser también
norma ISO: las primeras partes ya han sido aprobadas
como tal y la parte 5 está siguiendo un proceso común en
ambas organizaciones de normalización bajo el paraguas
de los acuerdos de Viena (Vienna Agreement)
La norma está orientada a la comunicación y define cómo
realizar el intercambio de HCE entre sistemas de
información, dejando libertad a cada sistema local para
guardar los datos clínicos en el formato que elija. La
norma está formada por cinco partes: 1.- Modelo de
referencia, 2.-Especificación para el intercambio de
arquetipos, 3.- Referencia de arquetipos y lista de
términos, 4.- Características de seguridad, y 5.- Modelos
de intercambio.
La norma ISO 13606 se basa en el doble modelo
información/conocimiento y cambia radicalmente su
diseño respecto a las anteriores normas. El modelo dual se
basa en dos modelos: de referencia y de arquetipos. El
modelo de referencia representa las estructuras que se
utilizan para albergar la información, mientras que el
modelo de arquetipos se utiliza para generar las
estructuras que guardan el conocimiento del dominio, que
son los arquetipos.
El modelo de referencia (MR) define las estructuras para
organizar la información. La estructura más general es el
extracto, que contiene la parte seleccionada de la HCE de
un paciente para ser transferida a otro sistema. Los
extractos forman parte de los mensajes, que son
estructuras de nivel superior definidas en la parte 5 del
estándar. Los extractos incluyen información demográfica
para reconocer al paciente y a todos los agentes
involucrados, información sobre las políticas de acceso,
información clínica y otros tipos de información auxiliar
como auditorías o firmas.
2. Servidor de HCE conforme a ISO 13606
Nuestro grupo de investigación ha diseñado y
desarrollado, de forma paralela a la elaboración de la
norma 13606, un servidor „middleware‟ de HCE
conforme a dicha norma [2-5]. Dicho servidor utiliza
tecnologías pertenecientes a muy diferentes ámbitos: Java

como lenguaje de programación, XML Schemas para
validar los extractos XML, SAX para el análisis de los
extractos y Web Services como tecnologías de
comunicaciones.
El servicio posee una arquitectura cliente-servidor y está
preparado para trabajar con múltiples clientes
simultáneamente. Los clientes pueden acceder a las
funciones a través de Web Services. Las funciones que
ofrece el servidor son storeExtract y retrieveExtract. La
función storeExtract envía un extracto en fichero XML al
servidor, extrae su información y la guarda en la base de
datos. Mientras que retrieveExtract recupera un extracto
previamente almacenado en la base de datos en forma de
fichero XML. Estas funciones se basan en identificadores
únicos para guardar y recuperar los extractos.
El servidor se ha estructurado en varios módulos que dan
soluciones a los diferentes requisitos funcionales. Los
módulos son independientes entre sí, así se facilita la
integración y la reutilización de las distintas partes. En la
figura 1 se muestra un esquema de los módulos del
servidor que a continuación se pasan a describir y la
forma en que está la información durante los diferentes
procesos.
Figura 1. Esquema del servidor HCE EN 13606
El módulo principal del servidor es la representación de la
HCE siguiendo el modelo de referencia de la norma ISO
13606. Para ello se han desarrollado cuatro paquetes de
clases Java: una para representar el modelo de referencia,
otra para el paquete demográfico, otra para los tipos de
datos de soporte y una cuarta para representar otros tipos
de datos. Se genera una clase Java por cada entidad UML
de los diferentes modelos de referencia. Cada una de estas
clases incluye variables representando a los distintos
campos, funciones para acceder y actualizar dichas
variables, funciones para poder pasar la información a
extractos XML y para poder extraer los datos a partir de
dichos extractos y funciones para interactuar con la base
de datos.
El módulo de almacenamiento permanente utiliza un
interfaz ODBC, de forma que se pueda cambiar
fácilmente la base de datos utilizada sin tener que cambiar
el código. Actualmente el almacenamiento se realiza en
una base de datos MySQL, aunque anteriormente se
utilizaron otras bases de datos como Access. Cada clase
Java se representa por una tabla en la base de datos. Las
relaciones entre las distintas clases se implementan
basadas en la clave única que posee cada una de las
clases.
El módulo de validación se encarga de verificar los
ficheros XML que llegan al servidor antes de su
procesamiento y los que se van a transmitir a los clientes
antes de su envío evitando así posteriores errores. Para
ello se han implementado una serie de XML Schemas con
la misma estructura que las librerías de la norma.
El procesamiento de los datos XML se hace a través del
módulo parseador que se encarga del paso de la
información de los extractos XML validados previamente
a objetos Java acordes con el modelo de referencia. El
procesado de la información debe ser posible en ambas
direcciones: de ficheros XML a objetos Java y viceversa.
El primer caso es el más problemático y requiere del uso
de una tecnología de análisis de XML específica. La
tecnología escogida para esta labor ha sido SAX y con la
librería SAX de Java se ha desarrollado un parseador que
realiza esta función. El segundo caso es más sencillo y la
transformación se realiza a través de una serie de
llamadas a la función recursiva convertToXml.
El módulo de comunicaciones está basado en Web
Services. Para ello se ha utilizado la herramienta Axis de
Apache como librería Java para el desarrollo de las
funciones del servicio web. El despliegue del servicio
web se ha realizado sobre un servidor de aplicaciones
Tomcat en el puerto 8080.
3. Estudios de compatibilidad con otras
normas
Además de la norma ISO 13606, existen otras alternativas
en la estandarización de HCE como son HL7v3 y la
iniciativa openEHR. Por lo que la compatibilidad entre las
distintas normas de HCE se convierte en un aspecto
fundamental para la interoperabilidad de sistemas.
Nuestro grupo de investigación ha realizado varios
estudios para potenciar la compatibilidad entre las
diversas normas. A continuación se describen dos de los
estudios más importantes.
3.1. Modelado del CCR según ISO 13606
El registro para atención continuada [6] (Continuity of
Care Record - CCR) es la especificación de una norma
desarrollada conjuntamente por ASTM International
(American Society for Testing and Materials - Sociedad
Americana para Pruebas y Materiales), MMS
(Massachussets Medical Society - Sociedad Médica de
Massachussets), HIMMS (Health Information
Management and Systems Society - Sociedad para la
Gestion de la Información de la Salud y los Sistemas),
AAFP (American Academy of Family Physicians -

Sociedad Americana de Médicos de Familia) y AAP
(American Academy of Pediatrics - Academia Americana
de Pediatría) con el objetivo de organizar y transferir un
conjunto de datos de paciente suficiente como para dar
soporte a la continuidad asistencial. Sus objetivos son el
incrementar la seguridad del paciente, reducir el riesgo de
errores médicos, reducir costes, hacer más eficiente el
intercambio de información de salud y asegurar un
mínimo estándar en el intercambio de información cuando
un paciente es derivado o transferido a otro profesional
sanitario.
El CCR se utiliza para derivar un paciente de una sección
a otra, para que el paciente pueda guardar su registro de
atención y presentarlo en futuras visitas médicas y para
tener un registro personal de la salud del paciente. El
CCR contiene tres componentes principales: la cabecera,
el cuerpo y el pie. La cabecera incluye campos como el
identificador, el lenguaje, la versión, fecha y hora de
creación y el identificador del paciente entre otros. El
cuerpo incluye secciones relativas al estado clínico y a
temas administrativos. Y el pie incluye otros campos
adicionales como los actores, las referencias, los
comentarios y las firmas.
Nuestro grupo realizó un estudio exhaustivo sobre cómo
representar el CCR y sus diversos campos sobre un
extracto 13606 para su posible transmisión entre
diferentes sistemas [7]. El resultado fue que el CCR se
puede representar como una única composición dentro de
un extracto, ya que es un documento creado en una única
interacción con el sistema de información. Esta
composición está formada por tres secciones principales
que se corresponden con las tres partes principales del
CCR: cabecera, cuerpo y pie, como se puede observar en
la figura 2. Cada sección se modela a partir de un
arquetipo organizativo distinto.
Figura 2. Representación del CCR dentro de un extracto 13606
En la Cabecera cada uno de los campos se traduce como
una entrada de la sección correspondiente. Hay que
indicar que las entidades demográficas se corresponden
con las clases respectivas del paquete demográfico y que
se apunta a ellas desde los campos Desde y A. El campo
Identificador de Paciente se traduce en la sección de la
Cabecera por el campo Subject_of_care definido
específicamente en la norma.
El Cuerpo tiene diversos campos que podemos diferenciar
en dos grupos. Por un lado están los no clínicos
(pagadores, proveedores, testamento vital y asistencia)
que se traducen al extracto con una sección para cada uno
de ellos dentro de la sección del Cuerpo y que apuntan a
entidades demográficas. Por otro lado tenemos los
campos que incluyen la información clínica de paciente
que se traducen mediante las secciones clínicas necesarias
y que pueden apuntar a composiciones (otros encuentros
sanitarios) del paciente que pueden adjuntarse en el
extracto o sólo referenciar su identificador.
Los campos Referencias y Comentarios del Pie del CCR
se traducen como dos secciones dentro de la sección del
Pie. Mientras que el campo Firmas se traduce utilizando
las clases Attestation_info del modelo de referencia de la
norma y el campo Actores utilizando las entidades
demográficas necesarias de la norma.
3.2. Mecanismo de armonización HL7v3/ISO13606
basado en arquetipos
Siguiendo las líneas marcadas para armonizar las distintas
normas de HCE, nuestro grupo propuso un modelo para la
traducción automática de un mensaje HL7v3 a un extracto
conforme a ISO13606 [8, 9]. El diseño del mecanismo
sigue dos reglas: que sea aplicable para modelar la
información contenida en cualquier mensaje HL7v3, y
que se puedan utilizar en lo posible los mecanismos ya
desarrollados en la norma ISO13606, de manera que la
solución propuesta aproveche los esfuerzos realizados en
la concepción de la norma.
Por lo tanto, se propone como método para el modelado
de la información la restricción del modelo de referencia
utilizando el modelo de arquetipos de la norma,
complementándose con un mecanismo de “caminos”
(paths), similar al propuesto en el lenguaje ADL para
poder enlazar los contenidos del mensaje HL7 con las
clases del modelo de referencia de EN13606.
El mecanismo de armonización propuesto se fundamenta
en los siguientes puntos:
Creación de un arquetipo conforme al modelo de
arquetipos de EN13606 (con las modificaciones
necesarias) para cada mensaje definido por medio de
una HMD
Las restricciones para los valores que toman los
atributos de dichos arquetipos podrán contener
“caminos” que apunten directamente a los valores de
atributos dentro de la HMD
Los “caminos” se obtienen de forma automática y
recurrente a partir del HMD, comenzando con los
nombres de los atributos finales de la jerarquía

expresada en la HMD concatenando delante de ellos
el nombre de su contenedor.
Los arquetipos así construidos pueden almacenarse
en repositorios para ser utilizados en el momento en
que se desee traducir un mensaje
Para traducir un mensaje se acudirá al repositorio
para obtener el arquetipo adecuado según el tipo del
mismo, se instanciarán las clases expresadas en el
arquetipo rellenándose sus valores con los contenidos
del mensaje original apuntados por los “caminos”
presentes en el arquetipo
Dada la posibilidad de utilizar arquetipos dentro de
otros arquetipos, se ha de proporcionar un
mecanismo para poder crear caminos relativos, de tal
manera que los caminos definidos en el arquetipo
incrustado se puedan concatenar a un camino fuente
Como se ha indicado anteriormente, este mecanismo
aprovecha el modelo de arquetipos de la norma
ISO13606, pero para poder utilizarlo ha sido necesario
realizar unas pequeñas modificaciones sobre él. Con estos
cambios se permite “apuntar” desde el valor de un
atributo del extracto a su equivalente en el mensaje de
HL7. Estas modificaciones son dos:
Restricción del valor de un atributo: se debe poder
crear una restricción que haga que el valor tomado
por un atributo dentro del extracto conforme a la
norma ISO13606 sea igual al contenido de un
atributo del mensaje HL7v3. Se haría incluyendo en
la restricción el camino correspondiente extraído de
la HMD. En ADL se propone utilizar una nueva
palabra reservada: use_value_path.
Caminos relativos en el uso de arquetipos externos:
para poder utilizar un arquetipo externo, debe ser
posible utilizar un mecanismo de caminos relativos
de tal manera que, a los caminos usados dentro del
arquetipo externo, se les añadiera un origen en el
momento de la llamada. En ADL se haría añadiendo
una nueva restricción a las estructuras
allow_archetype, por medio de la nueva palabra
reservada paths.
4. Servidor demográfico conforme a ISO
13606
Una gran necesidad de los sistemas de información
sanitarios es la gestión de los datos demográficos de los
pacientes, personal sanitario y otras entidades
participantes en la atención médica, de forma separada a
la información clínica. Esta necesidad ha aumentado con
la puesta en marcha de la ley de protección de datos.
Además, los sistemas de información no están preparados
actualmente para gestionar información demográfica de
una forma compartida.
Nuestro grupo de investigación tiene una extensa línea de
trabajo abierta en el tratamiento y seguimiento de
enfermos crónicos utilizando la Telemedicina, en la que
se ha desarrollado una plataforma para dar soporte a los
numerosos proyectos de investigación y ensayos clínicos
de diferentes patologías (como hipertensión arterial [10],
tratamiento anticoagulante oral [11] y asma [12]). En
ellos la información personal de los pacientes se
almacenaba en bases de datos locales. Además, la
información demográfica utilizada podía variar
dependiendo de cada proyecto.
Por estos motivos, nuestro grupo de investigación se
decidió a diseñar y desarrollar un servidor demográfico
externo e independiente siguiendo la norma ISO13606, al
que pudieran acceder los distintos sistemas de
información sanitarios para gestionar los datos
demográficos. De esta manera se consigue también una
separación en el almacenamiento de los datos clínicos y
los datos personales del paciente como establece la ley de
protección de datos.
A partir de ahora se pretende que los nuevos proyectos de
investigación de esta línea se integren con el servidor
demográfico, separando tanto conceptualmente como
físicamente el almacenamiento y gestión de la
información clínica y demográfica. Este es un primer paso
para demostrar a las autoridades sanitarias la necesidad y
viabilidad de utilizar servidores demográficos externos e
independientes.
Para el diseño y desarrollo del servidor demográfico se ha
aprovechado la experiencia obtenida y el trabajo realizado
en el servidor de HCE. Muchas de las tecnologías
utilizadas son las mismas: Java como lenguaje de
programación, interfaz de base de datos ODBC (MySQL),
parseado mediante tecnología SAX y tecnología de
comunicaciones basada en Web Services gracias a la
herramienta Axis.
El servidor demográfico se centra en las clases del
paquete demográfico del servidor de HCE y en las clases
del paquete de soporte. De cara a los clientes, se ofrecen
una serie de funciones accesibles a través de un servicio
web. Estas funciones son las ya conocidas storeExtract y
retrieveExtract, provenientes del servidor de HCE, y unas
nuevas funciones útiles para la gestión de datos
demográficos desde los proyectos de Telemedicina:
retrieveIdentifiedEntity: devuelve un extracto con
toda la información demográfica de un paciente a
partir de uno de los identificadores del paciente
almacenados en el sistema
getPatientName, getPatientFullName y
getPatientAllData: son diferentes funciones que a
partir de un identificador del paciente y el proyecto al
que pertenece, devuelve diferentes datos
demográficos según las necesidades del cliente que
las invoca
En el desarrollo del servidor demográfico ha surgido la
necesidad del arquetipo demográfico. Se entiende por
arquetipo demográfico una forma de representar el
conocimiento en la que se restringe mediante lenguaje
ADL las múltiples posibilidades que tienen las clases del
paquete demográfico. De esta forma se podría enviar

información al servidor siguiendo determinados
arquetipos y se podría pedir información al servidor a
partir de un identificador y un arquetipo concreto, y así el
servidor devolvería sólo los datos solicitados y en el
formato pedido. Cada proyecto, o cada aplicación que
utilice el servidor, definiría sus propios arquetipos que
modelen la información demográfica que manejan, y el
servidor podría utilizarse con cualquiera de ellos sin
ninguna modificación.
with oral anticoagulant therapy. IEEE Trans Inf Technol
Biomed. 2008, 12(6):696-706.
[12] L. Otero, M. Pascual, J. A. Fragua, P. García-Sagredo, M.
Carmona, I. Urgoiti, M. A. González, A. Muñoz, A. López-
Viña, L. Sánchez-Agudo, J. L. Monteagudo, C. H.
Salvador. Seguimiento de planes de autocuidado en asma
mediante un sistema de telemedicina. VIII Congreso
Nacional de Informática de la Salud – INFORSALUD
2005, Madrid, 5-7 abril 2005, pp 77-81
Referencias
[1] CEN (comité técnico 251). http://www.centc251.org
(consultado Abr-2009).
[2] A. Muñoz, R. Somolinos, J. A. Fragua, C. H. Salvador.
Servidor de historias clínicas electrónicas conforme a la
norma EN 13606. Informática y Salud, no. 51, marzo 2005,
pp 47-52
[3] R. Somolinos, A. Muñoz, J. A. Fragua, C. H. Salvador.
Servidor de historias clínicas electrónicas conforme a la
norma europea EN 13606. VIII Congreso Nacional de
Informática de la Salud – INFORSALUD 2005, Madrid, 5-
7 abril 2005, pp 143-147
[4] Somolinos R, Muñoz A, Fragua JA, Pascual M, González
MA, Salvador CH. Servidor de extractos de historias
clínicas conformes a la norma EN 13606. Actas del XXIII
Congreso Anual de la Sociedad Española de Ingeniería
Biomédica (CASEIB'05), Madrid, 10-12 noviembre 2005,
pp 39-42.
[5] Muñoz A, Somolinos R, Pascual M, Fragua JA, González
MA, Monteagudo JL, Salvador CH. Proof-of-concept
Design and Development of an EN13606-based Electronic
Health Care Record Service. Journal of the American
Medical Informatics Association (J Am Med Inform Assoc),
vol 14, 2007, pp 118-129 (DOI 10.1197/jamia.M2058).
[6] Continuity of Care Record (CCR). Disponible en:
http://www.astm.org/COMMIT/E31_ConceptPaper.d
oc (consultado Abr-2009).
[7] A. Muñoz, R.Somolinos, C. H. Salvador. Descripción del
ASTM E2369 Continuity of Care Record (CCR) según la
Norma Europea EN13606. Informática y Salud, no. 59,
noviembre 2006, pp 79-86
[8] Muñoz A. Interoperabilidad semántica entre los modelos de
historia clínica electrónica de CEN y HL7. Propuesta de un
modelo de armonización. Tesis doctoral. 2007.
[9] R. Somolinos, J. A. Fragua, M. A. González, M. Pascual,
E. Pregigueiro, P. García, M. Carmona, A. Muñoz.
Mecanismo de armonización HL7v3 / CEN/ISO 13606
basado en arquetipos. Actas del XXVI Congreso Anual de
la Sociedad Española de Ingeniería Biomédica
(CASEIB'08), Valladolid, 15-17 octubre 2008, pp 533-536.
[10] M. Pascual, CH. Salvador, PG. Sagredo, J. Marquez-
Montes, MA. Gonzalez, JA. Fragua, M. Carmona, LM.
Garcia-Olmos, F. Garcia-Lopez, A. Muñoz, JL.
Monteagudo. Impact of patient-general practitioner
interaction on the control of hypertension in a follow-up
service for low-to-medium risk hypertensive patients. IEEE
T Inf Technol B, 2008, 12(6):780-91.
[11] CH. Salvador, A. Ruiz-Sanchez, MA. Gonzalez, M.
Carmona, M. Pascual, PG. Sagredo, JA. Fragua, F.
Caballero-Martinez, F. García-López, J. Márquez-Montes,
JL. Monteagudo. Evaluation of a telemedicine-based
service for the follow-up and monitoring of patients treated