*Grupo de Informática Médica. Facultad de Informática, Universidad Politécnica de Valencia.
^#Conselleria de Sanitat. Generalitat Valenciana
**Hospital Lluis Alcanyís de Xàtiva

Cada día más la atención sanitaria de un paciente es la responsabilidad compartida de un grupo de profesionales pertenecientes a diversas disciplinas o instituciones. Como consecuencia de ello, la capacidad de compartir información sanitaria sobre las pacientes, en particular el acceso compartido a la historia clínica, de una manera sencilla, segura y conservando el significado original de los datos es una de las principales cuestiones a ser resuelta por el sector sanitario. En la situación actual, el mayor impedimento son las historias clínicas tradicionales (basadas en papel) que restringen el acceso a los datos del paciente a un único usuario, en único lugar en un momento determinado.

El desarrollo de sistemas de historias clínicas electrónicas (HCE) se prevé a medio plazo por lo que cualquier proyecto de integración de sistemas de información sanitarios debe considerar las implicaciones de las HCE y por tanto la estrategia de integración elegida deberá ser compatible con ellas.

En este sentido se presenta una visión general de un prototipo de sistema informático, actualmente en desarrollo, que permite a los profesionales sanitarios acceder a la información de los pacientes almacenada en sistemas de información heterogéneos y autónomos, y que está basado en el estándar de arquitectura de historia clínica electrónica ENV13606 del CEN/TC251 el cual se utiliza como modelo canónico para la representación de la información clínica. La estandarización de la arquitectura es esencial si los registros médicos van a ser compartidos o transferidos más allá de la departamento/organización donde fueron creados, ya que éstos deben ser entendibles por todos los demás sistemas que la quieran manejar.

Como primer paso hacia la historia clínica electrónica se propone una solución escalable y compatible con futuros desarrollos de sistemas de historias clínicas electrónicas. Para ello se está desarrollando un servidor de historias médicas electrónicas que permite el acceso controlado a la información médica sobre los pacientes almacenada en diversos sistemas de información heterogéneos y autónomos entre sí y que presenta los datos a los usuarios de forma unificada e integrada (ENV 13606). El sistema permite manejar una historia medica "virtual" que se construye "al vuelo" a partir de múltiples sistemas dinámicamente.

El sector sanitario genera, almacena y utiliza una enorme cantidad de información. Pero a pesar de esto la promoción, aceptación y uso de las tecnologías de la información y comunicación va por detrás de otros sectores similares en cuanto al volumen de información que manejan, como el bancario y el de seguros. Esto es debido, más que a una falta de conciencia del potencial de las tecnologías de la información en el sector sanitario, a una serie de factores: la insuficiente inversión en informática médica, la necesidad de justificar la inversión en los equipos ya adquiridos, la existencia de un mercado muy fragmentado donde los proveedores desarrollan sistemas que no son interoperables entre sí, la falta de estándares definitivos o su lenta adopción cuando éstos existen y la imposibilidad de los organismos normalizadores de ofrecer una perspectiva global con una estrategia clara.

Se constata actualmente en el sector sanitario un crecimiento en la utilización de las tecnologías de la información, pero a pesar de esto mucha información se sigue gestionando manualmente en la forma de historias clínicas soportadas en papel. Esto es debido a que los sistemas informáticos se utilizan principalmente en tareas administrativas o en los servicios centrales tales como laboratorios, radiología o farmacia dejando de lado los procesos propiamente asistenciales.

Es extremadamente difícil desarrollar un único sistema informático que puede satisfacer todas las necesidades de información de una organización tan compleja, como por ejemplo, un hospital. Si a esto añadimos que dentro de las organizaciones no ha existido una política global en cuanto al uso e implantación de las tecnologías de la información el resultado ha sido la proliferación de múltiples sistemas de información departamentales autónomos y heterogéneos entre si que contienen información duplicada, en muchos casos inconsistente y que no son accesibles desde toda la organización. La mayoría de estos sistemas son adecuados para la realización de las tareas específicas del departamento o unidad donde fueron implantados pero son inadecuados cuando se adopta una visión global a nivel de organización.

La atención sanitaria a los pacientes, cada día más, requiere la compartición de responsabilidades entre distintos profesionales que trabajan en diversos departamentos e incluso en diversas organizaciones. Esto acarrea que los profesionales necesiten compartir la información clínica sobre los pacientes. Históricamente esta compartición de información se ha llevado a cabo por medio de cartas, informes de alta y hojas de resultados, todas ellas en papel. Se gasta mucho tiempo extrayendo información de los documentos asociados al paciente para preparar tales informes, e incluso estos datos se vuelven a introducir en el sistema informático del receptor de la información. Estas transacciones basadas en papel son a menudo demasiado lentas para proporcionar la información necesaria cuando se deben tomar decisiones críticas. Se puede afirmar que la imposibilidad actual de compartir información sanitaria sobre los paciente entre sistemas y organizaciones automáticamente es uno de las mayores trabas del sector sanitario en aras de proporcionar una atención eficiente tanto desde el punto de vista asistencial como económico.

La comunicación de información clínica entre profesionales u organismos depende, de forma crucial, del uso de tecnologías de la información y comunicaciones. Aunque la necesidad de las historias clínicas informatizadas como herramienta para conseguir una atención sanitaria integrada es ampliamente reconocida, los progresos realizados han sido pocos. Se han expuesto muchas razones del porqué de esta situación: la complejidad y diversidad de la información médica, la necesidad de usar gran cantidad de términos descriptivos, la seguridad y confidencialidad, el tener que cubrir las necesidades de todos los implicados en el sector sanitario: profesionales, pacientes, investigadores, administradores, organismos públicos, etc., además de contemplar las peculiaridades funcionales, institucionales, departamentales, lingüísticas y personales.

El resto de la presente comunicación se organiza de la siguiente manera. En primer lugar se tratarán brevemente aspectos relacionados con las historias clínicas electrónicas, a continuación se describirá brevemente el pre-estándar de arquitectura de historia clínica electrónica ENV13606 del CEN/TC251 que es el utilizado en el proyecto que actualmente estamos desarrollado. En la siguiente sección se trata problema de la integración de sistemas de información en general y de los sistemas de información sanitarios en particular para acabar describiendo la solución utilizada en nuestro proyecto al problema de la integración de subsistemas de información hospitalarios.

Existe en la literatura una gran confusión de términos relacionados con los registros médicos almacenados en soporte electrónico. Cuatro de los más usuales son: las historias médicas automatizadas, historias médicas computarizadas, historias médicas electrónicas e historias clínicas electrónicas [1].

• Las historias médicas automatizadas son las que se encuentra actualmente en la mayoría de los hospitales. Utilizan el papel como soporte junto con un conjunto de sistemas informáticos departamentales aislados basados en arquitecturas tradicionales.
• Las historias médicas computarizadas se construyen escaneado los documentos basados en papel.
• Las historias médicas electrónicas comprenden un conjunto de sistemas de información departamentales pertenecientes a una única organización sanitaria que se encuentran integrados con un alto nivel de interoperabilidad.
• Las historias clínicas electrónicas incluyen a las historias médicas electrónicas junto con enlaces multi-organización (regional, nacional, internacional). Por tanto requiere un sistema universal de identificación de pacientes y una infraestructura y tecnología para el intercambio de información.

La figura 1 contiene un gráfico temporal donde se muestra la posible evolución de todos estos tipos de registros médicos en soporte informático [1].

Figura 1. Posible evolución temporal de los diversos tipos de registros clínicos en soporte informático. Fuente: Medical Record Institute,

 

La historia médica/clínica electrónica tiene diversas ventajas sobre las historias tradicionales basadas en papel, podemos enumerar las más importantes:

• Toda la información sobre un paciente esta disponibles en varios lugares al mismo tiempo.
• La información está disponible rápidamente lo cual es muy importante en urgencias.
• Permite presentar los datos de diversas formas: cronológicamente, por episodio, origen de datos, etc.
• Permite la reutilización de resultados de pruebas diagnósticas previas lo cual puede evitar su duplicación.
• Facilita la investigación médica

Por otro lado también tiene algunas desventajas:

• Existe riesgo de pérdida de integridad o disponibilidad debido a fallos técnicos.
• Requiere un mayor desembolso inicial en hardware, software y formación del personal.
• La seguridad y confidencialidad de los datos son aspectos críticos especialmente cuando el sistema no se administrada adecuadamente.
• El personal puede presentar resistencia a las nuevas formas de introducción de datos (barrera del teclado).

El desarrollo de sistemas de historias clínicas electrónicas ha sido bastante lento a pesar de los grandes avances tecnológicos en las tecnologías de la información que han surgido en los últimos años, como por ejemplo: Internet, CORBA (CORBAmed), Java o XML, los cuales son adecuados para el desarrollo de estos sistemas. En la introducción ya se citaron algunas razones para este subdesarrollo tales como: la falta de inversión en tecnologías de la información, la necesidad de proteger pasadas inversiones, la complejidad intrínseca de la información sanitaria en cuanto a variedad y estructura, la ausencia de una planificación global y la falta de estándares.

Las historias clínicas electrónicas contiene información clínica sobre los pacientes, esta información debe estar estructura de alguna manera, de forma que la información pueda ser manipulada o procesada por un sistema informático. Esta estructura debe ser adecuada para el proceso de atención sanitario así como para otros posibles usos de la información (investigación, formación, auditoría, aspectos legales, etc.). Es por esto que unos de los aspecto más importantes a la hora de desarrollar sistemas de historia clínicas (médicas) electrónicas es cómo organizar la información clínica.

Un arquitectura de historia clínica electrónica modela las características genéricas aplicables a cualquier anotación en una historia clínica independientemente de la organización (primaria, especializada, etc). La arquitectura debe proporcionar principalmente constructores o mecanismos para capturar fielmente el significado original de la información y asegurar que la historia clínica sea comunicable. Por comunicable entendemos la comunicación de partes de la historia clínica entre diversos profesionales que trabajan en distintos lugares sea segura y relevante, y que por tanto se salvaguarde el significado original de los datos. Por último, cabe destacar que una arquitectura no dicta que información clínica debe registrarse ni como debe implementarse el sistema información que gestione las historias clínicas.

Un aspecto clave que cualquier arquitectura de historia clínica debe definir es el contexto que debe acompañar a cualquier anotación en la historia clínica. Básicamente una anotación consiste de tres tipos de constructores [2]:

• Contenedores: encabezamientos, etiquetas, etc.
• Contenido: texto libre, medidas, sistemas de codificación, imágenes, listas de opciones, etc.
• Contexto: cualquier tipo de información que influencia la interpretación de una anotación. El contexto es básico para capturar fielmente el significado original de la información y preservar la integridad médico-legal. Ejemplos de información de contexto son: sujeto de atención (paciente, feto, familiar, etc.), fecha y hora de las acciones sanitarias y su registro, control de versión, énfasis y presentación, agente sanitario responsable, enlaces con otras anotaciones, certeza, estado, unidades de medida, precisión, etc. Uno de los mayores problemas es determinar que información de contexto debe ser almacenada y transmitida con la información de forma que se salvaguarde su significado original.

Hasta la fecha en Europa se han llevado a cabo diversos estudios sobre la estandarización de la arquitectura de historia clínica electrónica. Algunos ejemplos son el proyecto GEHR (Good European Healthcare Record) [3], Synapses [4], CEN/TC251 ENV12265 [5] y ENV13606 [8][9][10][11]. Estos estudios han identificado la información básica que debe acomodar cualquier arquitectura de historia clínica para que cumpla sus propósitos básicos.

El trabajo del comité técnico 251 del CEN dio lugar en 1999 al pre-estándar de arquitectura de historia clínica electrónica prENV 13606[3], el cual puede verse como una continuación de un proyecto previo (PT1-011) que produjo un primer pre-estándar (prENV 12265) a mediados de 1995. Este primer pre-estándar fue sobre todo un punto de partida que estimuló el debate sobre cuál es el ámbito de las historias clínicas informatizadas y sobre cuales son las características genéricas que se deben consensuar entre dos sistemas de HCI para que puedan compartir de forma segura información. El prENV 12265 ha sido reemplazado por prENV 13606.

La duración estimada del prENV 13606 es de tres años. Durante este periodo se espera que la experiencia obtenida a partir de las diferentes implementaciones del pre-estándar produzca nuevos requerimientos y posibles mejoras. El objetivo del CEN es producir una nueva versión, con la categoría de estándar europeo (EN) hacia el 2003 que contenga cualquier mejora que se considere necesaria como resultado de las experiencias de implementación.

El pre-estándar de arquitectura de historia clínica electrónica prENV13606 tiene como propósito general la definición de un conjunto de principios para el control de la estructura lógica y el comportamiento de las historias clínicas electrónicas y que permitan la comunicación de toda o una parte de la historia clínica.

El pre-estándar consta de cuatro partes:

Parte 1, prENV 13606-1. Arquitectura extendida y modelo de dominio (Extended Architecture and Domain Model [8]. El resultado de esta parte será la definición de las componentes de la arquitectura (arquitectura extendida) que son necesarias para permitir que el contenido de una historia clínica pueda ser construido, usado, compartido y mantenido. En el siguiente apartado se describirá con mayor detalle esta arquitectura. Por lo que respecta al modelo de dominio, el resultado será una descripción formal del contexto que envuelve a la historia clínica. Para ello, se documentarán requerimientos de tipo profesional, ético, legal y de seguridad que la arquitectura extendida, el dominio de lista de términos y las reglas de distribución deban satisfacer.

Parte 2, prENV 13606-2. Dominio de lista de términos (Domain Termlist) [9]. El resultado de esta parte es la definición un conjunto de términos que son usados tradicionalmente por los profesionales sanitarios, y en particular por médicos y enfermeras. El objetivo es permitir que todos los profesionales sanitarios puedan transmitir y reconocer el significado de la información clínica en función de la posición de estos términos dentro de la historia clínica. Cada entrada en esta lista de términos debe incluir el término, la definición del concepto a que se refiere, su uso en la atención sanitaria y su lugar en los registros médicos de acuerdo con la arquitectura.

Parte 3, prENV 13606-3. Reglas de distribución (Distribution Rules) [10]. El resultado de esta parte del pre-estándar será un conjunto de reglas para el intercambio de registros médicos. Por intercambio se entiende cualquier método por el cual los registros médicos se ponen a disposición de los profesionales sanitarios. Incluye el acceso a un archivo físico de historias clínicas, la creación de una historia clínica virtual que se construye a partir de la información almacenada en diversas fuentes y la comunicación de historias clínicas, o partes de estas, entre sistemas. Estas reglas representan requerimientos profesionales, éticos y legales de la práctica clínica y restricciones de seguridad (disponibilidad, confidencialidad, privacidad, integridad y seguridad física).

Parte 4, prENV 13606-4. Mensajes para el intercambio de registros de información (Messages for the Exchange of Record Information) [11]. Esta parte del pre-estándar especifica los mensajes que permiten el intercambio de HCI entre centros o personal sanitario responsables de la atención sanitaria de un paciente. Estos mensajes permiten que la información contenida en una HCI pueda ser enviada de un profesional a otro. Se permite definir mensajes con diferentes niveles de estructura. Desde los menos estructurados que únicamente permiten a cualquier sistema receptor presentar los datos de forma legible hasta los más estructurados que permiten que la información transferida pueda ser procesada por el sistema receptor.

Los componentes arquitecturales se clasifican en dos grupos:

• EHCR Root Architectural Component (Componente raíz de la historia clínica informatizada). Representa el contenedor o carpeta maestra dentro de la cual se encuentra la información referente a un paciente.
• Record Component (Componente de registro). Es una clase abstracta que tiene subtipos que representan componentes estructurales o de datos que contienen, a su vez, información clínica.

La clase Record Component tiene cuatro subclases:

• Original component complex (Componente complejo original). El prestándar usa la noción de contexto original de información, es decir, la componente arquitectural de nivel superior que contenía a la entrada en la historia clínica cuando ésta última fue creada. Los OCC sirven, por tanto, para agrupar otras componentes que comparten algunas características. El prestándar proporciona un amplio rango de posibles agrupaciones, desde OCC que representan secciones completas de las historia clínica de un paciente (una estancia en un hospital, atención primaria, etc), hasta OCC que agrupan un conjunto de anotaciones atómicas íntimamente relacionadas: presión sanguínea (sístole, diástole) o calendario de administración de insulina.
• Data item (Item de información). Unidad de información que dentro de un determinado contexto es indivisible, es decir, representa la unidad estructural más pequeña con significado en la cual se puede descomponer una historia clínica. Es una clase abstracta que se especializa en diversos tipos que están diseñados para representar los diversos tipos de datos que pueden existir dentro de una HCI.
• Link item (Enlace). Componente estructural que proporciona un mecanismo para relacionar dos instancias de otras componentes y especificar el tipo de relación entre ellas. Por ejemplo, permite relacionar una componente que describe una diabetes con otra que contiene una catarata por medio de una relación "causada por".
• Selected component complex (Componente complejo seleccionado). Componente estructural útil para reutilizar la información original ya que permite cambiar el contexto original de los datos. Dicho con otras palabras, nos permite definir reagrupar un conjunto de componentes independientemente de su contexto original. Las componentes se seleccionan al ejecutar un procedimiento de búsqueda o una consulta. Por ejemplo, se puede definir un SCC "medicación actual" que a partir de las componentes que contienen diversas prescripciones obtiene una lista de toda la medicación seguida por el paciente.

La clase abstracta Original Component Complex se especializa en:

• Folder OCC (Componente original complejo carpeta). Se usa como subdivisión de alto nivel de la historia clínica de un paciente. Usualmente agrupa entradas referidas a un largo periodo de tiempo o para un determinado departamento u organización o para un problema de salud en particular. Esta componente puede contener información recogida y registrada en distintas fechas y por distintas personas. Proporciona el contexto de información original para todos sus miembros.
• Composition OCC (Componente original complejo composición). Se usa como una especialización de OCC que contiene un conjunto de componentes que tienen en común una fecha y lugar de atención sanitaria, una única sesión de registro o un único documento incluido en la historia clínica. Un Composition OCC se distingue de un Folder OCC en su mayor nivel de homogeneidad.
• Headed Section OCC (Componente original complejo sección con encabezamiento). Se usa para representar una subdivisión dentro un composition OCC, cuyo contenido tiene un tema común o se deriva del mismo proceso sanitario.
• Cluster OCC (Componente original complejo grupo). Se usa para agregar ítems de información u otros cluster OCC con el fin de poder representar conceptos compuesto.

Las dos aproximaciones principales para permitir a las organizaciones la compartición de su información sanitaria entre los diversos sistemas de información existentes son:

• La aproximación revolucionaria que consiste en comenzar de nuevo, por tanto descartando los sistemas existentes y adquiriendo unos nuevos. Consideramos que está aproximación esta condenada al fracaso debido a diversas razones. Es realmente muy difícil que un único sistema pueda cumplir eficientemente los requerimientos de información de todos los usuarios y gestionar y almacenar toda la información requerida en el proceso de atención sanitaria [6]. La mayoría de los sistemas específicos o especializados en una tarea o dominio determinado cumplen adecuadamente los requerimientos de los departamento donde están implantados: admisión, laboratorios, urgencias, etc. Por otro lado, existen también razones puramente económicas: la necesidad de los gestores de los centros sanitarios de proteger las inversiones pasadas en sistemas de información y la gran inversión inicial que esta aproximación requiere no sólo en la adquisición de equipos y software sino en la formación del personal.
• La aproximación evolutiva que mantienen y utiliza las aplicaciones informáticas actualmente existentes. En vez de implantar un sistema de información monolítico, cada departamento puede instalar el mejor sistema existente para su área. Esta aproximación requiere el desarrollo de algún tipo de software que se sitúe entre los sistemas existentes y los usuarios finales, es decir, algún tipo de middleware. Este software debe integrar de alguna forma la información que se encuentra dispersan en los diversos sistemas de información existentes y presentar a los usuarios finales la información en un formato unificado y ocultando los detalles sobre la localización y formato de los datos.

La integración de sistemas de información tiene tres dimensiones principales: autonomía, heterogeneidad y distribución que hay que conocer y tener en cuenta en cualquier proyecto de integración de sistemas de información, a continuación se describen brevemente.

Por autonomía se entiende distribución de control, en contraposición a la distribución de la información. Por tanto, indica hasta que punto los sistemas de información pueden operar independientemente. Dicho con otras palabras, las bases de datos generalmente están bajo control separado e independiente. Así por ejemplo, aquellos que controlan el acceso a las bases de datos únicamente permitirán el acceso a otros usuarios sólo si siguen manteniendo el control total sobre los datos. Existen distintos tipos de autonomía, todos ellos importantes, y que es necesario entender y saber como hacerles frente cuando un sistema de base de datos participa en una red o bien cuando comparte su información. Los distintos tipos de autonomía son:

• Autonomía de diseño: las bases de datos locales pueden elegir su propio modelo de datos (cómo se estructura la información), lenguaje de interrogación, restricciones, interpretación semántica de los datos, qué operaciones o funciones soporta, etc. Esta es la principal causa de la heterogeneidad entre los distintos sistemas.
• Autonomía de comunicación: las bases de datos locales tienen el poder de decidir cuando y cómo responder a las peticiones de información procedentes de otras bases de datos.
• Autonomía de ejecución: las bases de datos locales controlan el orden de ejecución de las transacciones u operaciones independientemente del tipo de éstas: locales o externas.
• Autonomía de asociación: las bases de datos locales pueden decidir qué datos comparten con determinados usuarios.

La heterogeneidad entre los diversos sistemas que conviven dentro de una organización se debe principalmente al desarrollo e implantación de manera independiente y aislada de tales sistemas. La heterogeneidad puede ocurrir a cualquier nivel del sistema de base de datos. A un nivel técnico la heterogeneidad es debida a la utilización de diversos tipos de hardware, sistemas de información, lenguajes de programación o sistemas gestores de bases de datos. Por otro lado, en el nivel conceptual la heterogeneidad aparece cuando se utilizan diversos modelos datos para representar la información o cuando existen discrepancias con respecto al significado de los datos (heterogeneidad semántica), por ejemplo, cuando se utiliza el mismo nombre para representar diversos conceptos o el uso de nombres diferentes para detonar el mismo concepto. Posiblemente en cualquier proyecto de integración de sistemas de información la superación de la heterogeneidad entre los diversos sistemas es la tarea más difícil. Obviamente, cuanto más diferentes sean los sistemas a integrar mayor es la dificultad. Las técnicas empleadas con mayor frecuencia para superar este problema son la utilización de modelos de datos comunes y estándares específicos, que pueden ser útiles para definir el significado de la información cuando ésta debe ser compartida entre diversos sistemas.

En mucho entornos y aplicaciones los datos están distribuidos en múltiples bases de datos. Las bases de datos pueden estar en un único o en múltiples sistemas informáticos, que a su vez pueden estar en un único o en múltiples lugares (departamentos, organizaciones o incluso países) pero están interconectados por un sistema de comunicación. Los datos pueden estar distribuidos en diversas bases de datos de varias formas. Estas incluyen, desde un punto de vista relacional, particiones verticales y horizontales. Además pueden existir varias copias de la misma información (replicación) [6].

Actualmente la tecnología ofrece diversas herramientas para la integración de sistemas de información sanitarios pero al echar un vistazo al mercado nos encontramos que todos los productos utilizan soluciones "ad-hoc" y no tienen en cuenta los estándares, por tanto, deben considerarse como soluciones "interinas". Por ejemplo, en el mercado existen algunos productos del tipo data warehouse, estos productos proporcionan una forma de integrar y homogeneizar la información dispersa por múltiples sistemas, e incluso la información contenida por el propio data warehouse, con ciertas restricciones, puede ser la base de una historia clínica electrónica informatizada. El principal problema que esta solución presenta es la replicación de información, es decir, los datos se encuentra tanto en el sistema original como en el data warehouse, con los consiguientes problemas de sincronización de los datos. Otro tipo de productos son los conocidos como herramientas de integración (integration engines o inteface engines) que permite el intercambio de información entre diversos sistemas a través de un conjunto estandarizado de mensajes (por ejemplo, HL7). Esta aproximación soluciona el problema básico de la comunicación entre sistemas pero se queda a medio camino en cuanto a alcanzar un mínimo nivel de interoperabilidad e integración de información. Pero esta solución da lugar a sistemas poco escalables, es decir, es cada vez más difícil añadir nuevos sistemas ya que el número de interacciones entre los sistemas también aumenta.

Por otro lado, las historias clínicas electrónicas (HCE) están en camino y cualquier organización que se plantee actualmente un proyecto de integración de sistemas de información sanitarios debe tener en cuenta las implicaciones de las HCE y si la estrategia de integración elegida es compatible y facilita la implantación de futuros sistemas de historias clínicas. Una de las implicaciones de esto último es que la solución tecnológica utilizada dentro de la organización para la integración de sus sistemas de información (por ejemplo en el desarrollo de algún sistema de historia médica electrónica) deberá ser compatible, idealmente la misma, con la utilizada para la comunicación de datos entre organizaciones.

El objetivo de proyecto actualmente en curso es el desarrollo de un sistema informático que permita a los profesionales sanitarios acceder de manera controlada a la información sanitaria sobre los pacientes que se encuentra repartida por múltiples sistemas de información heterogéneos y autónomos en el hospital. Asimismo, la información se debe presentar de una manera unificada ocultando los detalles propios de los sistemas a integrar, tanto de localización como de formato de datos.

Consideramos importante establecer un conjunto de condiciones al comienzo del proyecto con respecto a la metodología a emplear. Así por ejemplo, consideramos importante mantener la autonomía de los sistemas ya existentes en el hospital, es decir, cuantos menos cambios mejor. De esta manera los usuarios de estos sistemas no se verán afectados y podrán continuar trabajando con ellos de la manera acostumbrada. La solución debe ser fácilmente escalable, es decir, el añadir nuevas fuentes de información debe realizarse de forma sencilla y sin afectar a los sistemas ya integrados. Por último consideramos como muy importante la utilización de los estándares disponibles.

Como se ha perfilado anteriormente nuestra solución se basa en el desarrollo de un servidor que se sitúa entre los usuarios y las bases de datos ya existentes y que por tanto se puede considerar como una forma de middleware. A través de este servidor los profesionales sanitarios pueden obtener toda o parte de la información sanitaria sobre un paciente integrada en un formato unificado. Por tanto, en esta solución hacemos más hincapié en la compartición de datos entre los sistemas más que en la integración de los sistemas que contienen los datos. De esta forma, el servidor permite la gestión de un historia médica electrónica "virtual". Decimos virtual porque los usuarios finales pueden disponer de una historia médica electrónica de los paciente, pero realmente ésta no existe como entidad propia en ningún sistema informático sino que se encuentra repartida por múltiples bases de datos. La historia clínica, o parte de ésta, se construye "al vuelo" y siempre bajo demanda de los usuarios finales. Obviamente esta solución implica la utilización de una estructura común para representar la información sanitaria: arquitectura de historia clínica electrónica. Así, en nuestro proyecto utilizamos prENV13606 como arquitectura de historia clínica electrónica. La razón de esta elección es simple, este pre-estándar va en camino de convertirse en el estándar definitivo en cuanto a arquitectura de historia clínica en Europa lo cual supone una base firme, y aunque el proyecto no tiene como objetivo el desarrollo de una historia clínica electrónica, sino que se queda un paso atrás (integración a nivel de una organización), consideramos que la estrategia elegida es compatible y facilitará futuros desarrollos o implementaciones de sistemas de historia clínica electrónica.

Como ya se ha comentado ENV13606 es la vista unificada en la cual se presenta a los usuarios finales las historias médicas de los pacientes y por tanto proporciona un mecanismo para construir historias médicas, por tanto el intercambio de datos debe realizarse utilizado uno o varias de las estructuras definidas en el pre-estándar. La primera dificultad que apareció a la hora de utilizar ENV13606 en nuestro proyecto fue el alto grado de abstracción de sus componentes. ENV13606 tiene como propósito el poder representar cualquier entrada en una historia clínica producida en cualquier institución sanitaria (hospital, atención primaria, centro de especialidades, atención a domicilio, etc.), para cualquier especialidad o por cualquier profesional sanitario, por tanto, sus constructores básicos fueron definidos con un alto grado de abstracción. Por otro lado, los sistemas de información a integrar, como ya hemos visto, contienen información específica sobre un aspecto concreto de la atención sanitaria de los pacientes (laboratorio, urgencias, admisión, anatomía patológica, etc.). Además, los profesionales sanitarios suelen manejar un conjunto más o menos fijo de documentos o agregados de información para la realización de sus actividades (por ejemplo, informe de alta, hoja de solicitud de ingreso, hoja de urgencias, hoja de evolución, etc.). Por tanto, es conveniente que los usuarios finales puedan realizar peticiones de información sobre los pacientes por medio de estos documentos o agregados o cualquier otro definido a posteriori.

Estos documentos o agregados pueden ser representados fácilmente utilizando las estructuras definidas por el pre-estándar. Esto nos lleva a un conjunto de lo que nosotros denominamos "clases clínicas" (ya que representan conceptos médicos) y que extienden las clases definidas en prENV13606. Estas clases clínicas pueden "enlazarse" fácilmente a los esquemas de las bases de datos a integrar y los usuarios finales realizan peticiones de información por medio de una o varias instancias de estas clases. Por enlazar entendemos definir qué estructuras de la bases de datos conectadas al servidor contienen la información sobre los pacientes necesaria para poder instanciar las clases médicas. No solamente es necesario definir la localización de la información puramente clínica sino que es necesario definir dónde se encuentra almacenada la información de contexto (si existe) requerida a instancias del pre-estándar.

Una característica interesante de la solución adoptada es el alto grado de reutilización que se permite con las clases clínicas, en efecto, las clases ya definidas puede ser utilizadas para definir otras clases siguiendo las reglas de agregación definidas en el pre-estándar.

La figura 2 presenta un esquema de la arquitectura de nuestro sistema. El servidor se sitúa entre los usuarios y las bases de datos a integrar. El servidor, recupera, bajo demanda de los usuarios, la información relevante sobre el paciente y la devuelve a los usuarios. La componente principal es el servicio de historia médica electrónica el cual recibe y sirve las peticiones de información. Como ya se ha comentado, los usuarios para obtener información sobre un paciente piden una o varias instancias de cualquier clase médica almacenada en el diccionario de clases médicas que está gestionado por el servidor de metainformación.

El servidor de metainformación gestiona el diccionario de datos del sistema el cual almacena toda la información necesaria para el funcionamiento del sistema. El diccionario de datos contiene información sobre las bases de datos conectadas al sistema, los esquemas de las bases de datos en un formato común, qué objetos de las bases de datos conectadas pueden ser accedidos por las aplicaciones clientes (los administradores de las bases de datos pueden decidir qué información comparten con el resto de usuarios), la definición y versiones anteriores de las clases clínicas, sinónimos, los enlaces de éstas con los esquemas de bases de datos, las relaciones semánticas entre clases clínicas, heurísticos para la optimización de las consultas y direcciones de red.

El servidor de historias médica obtiene del servidor de metainformación la definición de la clase y sus enlaces con las bases de datos y construye y realiza las consultas oportunas a las bases de datos (a través de JDBC) para crear en tiempo de ejecución una instancia (objeto) de la clase clínica demandada, la cual contendrá la información clínica sobre el paciente. El servidor de historias médicas puede utilizar otros dos servidores para realizar su tarea, el servidor de control de acceso que previene que usuarios no autorizados puedan acceder a los datos y el servidor de identificadores de pacientes que permite identificar pacientes idénticos entre diferentes sistemas cuando no existe un identificador de paciente común para todas las bases de datos conectadas el servidor.

Junto con el servidor se han diseñado e implementado dos aplicaciones visuales para la gestión de la metainformación de sistema: el editor de clases clínicas y el gestor de esquemas de bases de datos. El primero tiene como propósito el ayudar en el proceso de definición de clases clínicas, permite a los diseñadores crear nuevas clases de cero o a partir de las ya existentes, comprueba su validez y gestiona el versionado. El segundo es una herramienta para gestionar los esquemas de las bases de datos conectadas al servidor, permite definir que información puede ser accesible, detecta las entidades que contienen información referente al paciente y permite completar el esquema (si es necesario) al permitir la adición de nuevas dependencias de equivalencia entre conjunto de atributos (claves ajenas).

Con el fin de conseguir la mayor independencia de implementación se esta utilizando Java para el desarrollo de los servidores los cuales se comunican entre si por medio de CORBA. Los clientes pueden conectarse directamente al servidor de historias médicas electrónicas (a través de CORBA) o pueden conectarse a través de una interface de forma que se les aísla del uso de CORBA. El uso de CORBA permite que los clientes puedan desarrollar sus propias aplicaciones en el entorno y lenguaje de programación que deseen.

Figura 2. Esquema general de la arquitectura propuesta para el sistema de integración de datos clínicos

La responsabilidad de la atención sanitaria de los pacientes cada vez tiene más una naturaleza distribuida, de forma que la responsabilidad recae sobre un grupo de profesionales pertenecientes a diversas disciplinas e instituciones. Por tanto, la posibilidad de compartir de forma eficiente, segura y válida la información sanitaria sobre los pacientes es vital para proporcionar una atención sanitaria de calidad. Por otra lado la estandarización de la arquitectura de historia clínica es vital cuando la información clínica tiene que transferida o usado fuera del departamento u organización donde fue creada. Este artículo describe de manera muy somera la arquitectura y estructuras de información utilizadas en el desarrollo de un servidor capaz de integrar y presentar a los usuarios finales de forma unificada la información sanitaria distribuida en múltiples sistemas de información en una institución. La arquitectura de historia clínica utiliza es prENV13606 del CEN/TC251, sin embargo, ha sido necesario desarrollar algunas extensiones (clases médicas) para poder aplicar esta arquitectura en nuestro proyecto. El sistema informático en desarrollo está compuesto de varios servidores (o servicios) interconectados por medio de CORBA. Este proyecto pretende ser el primer paso hacia la consecución de la historia clínica electrónica para los hospitales de la Comunidad Valenciana.

Este proyecto está financiado por Comisión Interministerial de Ciencia y Tecnología (CICYT) y la comisión Europea , proyecto FEDER-CICYT 1FD97-0910 y por Novasoft S.A.

1. Medical records institute: http://www.medrecinst.com
2. Rossi Mori, A.; Consorti, F. Integration of clinical information across patient records: a comparison of mechnisms used to enforce semantic coherence. IEEE transaction on information technology in biomedicine, 2-4 (1998) 243-253.
3. Ingram, D., Lloyd, D., Kalra, D., Beale, T., Heard, S., Grubb, P., Dixon, R., Camplin, D., Ellis, J., Maskens, A.: GEHR Architecture, Version 1.0. The Good European Health Record Project, Deliverables 19, 20, 24. AIM Office (1995)
4. Grimson, J., Grimson, W., Berry, D., Stephens, E.F., Kalra, D., Toussaint, P., Weier O.W.: A CORBA-Based integration of distributed electronic healthcare records using the Synapses approach. IEEE Transactions on information technology in biomedicine 2-3 (1998) 124-138
5. Hurlen, P. (ed.).: ENV 12265 Electronic Healthcare Record Architecture. CEN/TC251 PT 1-011. Brussels (1995)
6. Sheth, A.P., Larson, J.A.(1990). Federated database systems for managing distributed, heterogeneous, and autonomous databases. ACM Computing Surveys, 22 (3), 183-235.
7. Stead W.W. et al. (2000). Integration and beyond: liking information from disparate sources and into workflow. Journal of the American Medical Informatics Association, 7-2, 135-145.
8. CEN/TC251 WG I, (1999). Health Informatics-Electronic Healthcare Record Communication- Part 1: Extended architecture and domain model, Final Draft prENV13606-1, http://www.centc251.org/Witems/PT/26/PT26.htm.
9. CEN/TC251 WG I, (1999). Health Informatics-Electronic Healthcare Record Communication- Part 2: Domain term list, Final Draft prENV13606-2, http://www.centc251.org/Witems/PT/27/PT27.htm.
10. CEN/TC251 WG I, (1999). Health Informatics-Electronic Healthcare Record Communication- Part 3: Distribution rules, Final Draft prENV13606-3, http://www.centc251.org/Witems/PT/28/PT28.htm
11. CEN/TC251 WG I, (1999). Health Informatics-Electronic Healthcare Record Communication- Part 4: Messages for the exchange of record information, Final Draft prENV13606-4, http://www.centc251.org/Witems/PT/29/PT29.htm

[OBJETIVO] [COMITÉS] [PARTICIPANTES] [ÁREAS] [ACTIV.INTERNACIONALES] [PROGRAMA] [MESAS REDONDAS] [S. CIENTÍFICAS] [S. TECNOLÓGICAS] [PÓSTERS] [INSCRIPCIÓN]

Última actualización: miércoles, 04 de abril de 2001