Download Consultar

Interoperabilidad entre aplicaciones sanitarias
P. Ferriol Monserrat1, F. Tous Llull1, J. Oliver Mesquida1, S. Ramis Oliver1
1
Fundació IBIT, Palma de Mallorca, España, {pedro, xisco, joliver, sramis}@ibit.org
Resumen
2.
Interoperabilidad
En el entorno sanitario los Sistemas de Información (SI) clínica
tienen cada vez un uso más generalizado, dadas las potenciales
ventajas que ofrecen a la hora de mejorar la gestión y uso de los
recursos sanitarios. Debido al carácter heterogéneo de estos SI
su interconexión resulta en la mayoría de los casos complicada,
tanto en el ámbito de una misma organización como entre
organizaciones diferentes. Mediante la interconexión de
diferentes SI se pueden establecer eficaces canales para el
intercambio de información y conocimientos que permitan
mejorar la gestión de los recursos sanitarios, tanto desde un
punto de vista clínico como administrativo. En la presente
publicación se describen los aspectos fundamentales a tener en
cuenta a la hora de lograr interoperar SI, las tecnologías que
pueden contribuir a este fin y las acciones realizadas en este
sentido en la Comunitat de les Illes Balears.
Podemos definir el concepto de interoperabilidad como la
habilidad de dos o más sistemas o componentes para
intercambiar información y de usar la información que se
han intercambiado [1].
1.
3.
Introducción
En las Illes Balears, igual que en el resto de Comunidades
Autónomas, estamos asistiendo a un periodo de transición
respecto al uso de las Nuevas Tecnologías de la
Información y las Comunicaciones (NTIC) en el entorno
sanitario. Si inicialmente el interés se centraba en el
diseño e implementación de aplicaciones puramente
telemédicas, como la provisión de servicios médicos a
distancia o la consulta remota de información
digitalizada, ahora la atención está recayendo en los
Sistemas de Información (SI) y su interoperabilidad.
En el entorno sanitario los SI tienen cada vez un uso más
generalizado, tanto en las áreas de gestión administrativa
como en la práctica médica, dadas las potenciales ventajas
que ofrecen a la hora de mejorar la gestión y uso de los
recursos sanitarios. Desafortunadamente, estos SI son
muy heterogéneos, por lo que su interconexión resulta
bastante complicada, sino imposible en algunos casos.
Nos encontramos, además, en un escenario donde esta
falta de interoperabilidad entre los SI se produce no sólo a
nivel de centros o entidades diferentes, sino también
dentro de un mismo centro o incluso servicio.
En el presente documento veremos cuales son los
beneficios que puede proporcionar la interoperabilidad
entre SI clínicos, qué tecnologías se encuentran
disponibles en este sentido y las tareas llevadas a cabo en
la Comunidad de las Illes Balears, encaminadas a alcanzar
este objetivo.
Basándonos en esta definición podemos identificar dos
niveles de interoperabilidad: la intercomunicación y la
integración de los datos. Mediante la intercomunicación
de SI se hace posible el intercambio de información entre
ellos, una vez lograda esta comunicación, los datos
intercambiados deben poder ser usados, por lo que se
hace necesaria su integración semántica en las bases de
datos y procesos de los sistemas involucrados en la
comunicación.
Necesidad de interoperabilidad
Hoy en día, la falta de interoperabilidad entre SI supone,
en la mayoría de casos, un desaprovechamiento de los
recursos y una gestión poco eficaz de la información
sanitaria manejada.
En este sentido, actualmente se dan situaciones en las que,
por ejemplo, un mismo paciente está dado de alta en
diferentes sistemas clínicos, de diferentes centros
sanitarios, con diferentes historiales y sin ningún
elemento que los relacione. Incluso puede darse la
situación en la que un mismo paciente tenga diferentes
historias clínicas abiertas en un mismo sistema.
Esta falta de interoperabilidad entre SI provoca varios
problemas, entre ellos:
• Falta de disponibilidad de información previa
referente a un paciente.
• Duplicidad de registros y repetición innecesaria de
pruebas o exploraciones.
• Falta de continuidad en el seguimiento de los
pacientes debido a la imposibilidad de crear una
historia clínica electrónica unificada.
La solución a estos problemas pasa por la provisión de
interoperabilidad entre los diferentes SI clínicos, de
manera que se establecen unos eficaces canales para el
intercambio de información y conocimiento, lo que
permite una mejor gestión de los recursos sanitarios, tanto
desde un punto de vista clínico como administrativo. De
esta forma se evitan duplicidades en los SI y se unifican
los historiales clínicos de los pacientes, se ofrece un trato
más eficiente y se incrementa el nivel de calidad
asistencial percibido por el paciente.
Por otro lado, disponer de un modelo de interoperabilidad
mediante el que puedan interconectarse los diferentes
sistemas y aplicaciones que componen el entorno
sanitario, supondrá a largo plazo una sólida plataforma a
partir de la que diseñar e implementar nuevos proyectos.
Algunos de estos desarrollos pueden ser: sistemas de
petición remota de cita previa, sistemas de petición de
interconsultas, sistemas de diagnóstico remoto o segundas
opiniones, consulta remota de historiales clínicos, receta
electrónica o aplicaciones de telemedicina, entre otros.
4.
Intercomunicación de SI
Conseguir intercomunicar SI puede considerarse como un
primer paso hacia la interoperabilidad total entre sistemas.
En el entorno sanitario coexisten multitud de proveedores
de SI, lo que supone multitud de aplicaciones y
plataformas diferentes, cada una con sus propias
particularidades a la hora de funcionar y comunicarse. En
este escenario, a priori, puede resultar bastante
complicado poder intercomunicar dos SI cualesquiera.
Afortunadamente, hoy en día existen diferentes sistemas
o iniciativas que contribuyen a la intercomunicación de
SI, entre ellos destacan los estándares de comunicaciones,
el middleware de integración o las soluciones de gestión
integral.
En el ámbito de los estándares de comunicaciones entre
SI, básicamente, existen dos grandes iniciativas: HL7
(Health Level Seven) [2] y CEN/TC 251 [3]. HL7 es un
estándar gestionado por voluntarios y de consenso,
acreditado por el ANSI (American National Standards
Institute), para el formato de datos e intercambio de
información entre diferentes SI de salud. En la actualidad,
HL7 cuenta con una gran difusión y uso en el entorno
sanitario, habiéndose convertido en un estándar “de facto”
para la comunicación entre aplicaciones sanitarias a todos
los niveles, al ser implementado en los productos de la
mayoría de fabricantes del sector, entre ellos General
Electric, Siemens o Hewlett-Packard. A nivel nacional
existe la organización HL7-Spain [4] para promocionar y
fomentar el uso del estándar en España, así como
recomendar formas de actuación, metodologías y guías
adaptadas a las particularidades del entorno sanitario
nacional, dentro de las posibilidades que ofrece el
estándar internacional.
Como alternativa a la versión 3 de HL7, la última versión
del estándar y aún en proceso de borrador, el CEN
(Comité Europeo de Normalización), a través de su
Comité Técnico 251, está trabajando en la norma
CEN/TC 251 para las comunicaciones e intercambio de
información entre los sistemas sanitarios. Actualmente
esta norma se encuentra en fase de desarrollo y sólo se
han publicado borradores de las diferentes partes que la
componen.
El término middleware es relativamente nuevo en la
definición de arquitecturas de SI y surge como el
resultado de la proliferación de aplicaciones multicapa,
entornos distribuidos y el desarrollo del comercio
electrónico. Las tecnologías middleware se pueden definir
como las funciones que permiten la comunicación en un
sistema distribuido y las herramientas que ayudan a la
usabilidad general de una arquitectura basada en
productos de muchos vendedores distintos y en múltiples
plataformas [5].
Existen diversos tipos de servicios middleware, que
pueden clasificarse en los siguientes grupos [6, 7]:
•
Bases de datos: permite a las aplicaciones
comunicarse con bases de datos locales o remotas.
Ejemplos de este middleware son ODBC (Open
DataBase Connectivity) o JDBC (Java Data Base
Connection) que permiten la comunicación entre las
aplicaciones, en forma de llamadas desde el lenguaje
de programación en el cual están escritas y los
motores de bases de datos.
•
Mensajería: permite el envío de mensajes entre
aplicaciones, independientemente de la capa de
transporte de datos, un ejemplo de esta tecnología es
la API de JMS (Java Message Service) [8]. JMS es
una interfaz estándar desarrollada para permitir el
acceso a servicios de mensajería de forma sencilla,
delegando la responsabilidad de la comunicación al
propio servicio.
•
Monitores de proceso transaccional: asegura la
integridad de las transacciones entre aplicaciones y
bases de datos y, en caso de error, permiten regresar
al estado inmediatamente anterior al inicio de la
transacción.
•
Integración de aplicaciones: este tipo de middleware
proporciona interfaces a una gran variedad de
aplicaciones, permitiendo la comunicación entre ellas
sin demasiado esfuerzo de programación, dentro de
este grupo se encuentran los servicios web. Un
servicio web es una colección de protocolos y
estándares que sirve para intercambiar datos entre
aplicaciones. Un ejemplo de esta tecnología es el uso
del protocolo SOAP (Simple Object Access Protocol)
para implementar llamadas a procedimientos
remotos, RPC (Remote Procedure Call), sobre HTTP
[9]. Mediante RPC, SOAP permite a las aplicaciones
ejecutar funcionalidades de otras aplicaciones
remotas y recibir los resultados de dicha ejecución.
•
Superservicios middleware: esta tecnología consiste
en la integración de varios tipos de middleware y en
ella podemos englobar a los llamados motores de
integración entre aplicaciones, también conocidos
como EAI (Enterprise Application Integration), cuyo
uso está cada vez más extendido en el ámbito
sanitario. A pesar de la gran ayuda que supone el
disponer de un estándar de comunicaciones entre
aplicaciones como es HL7, por debajo de este nivel,
en muchos casos se hace necesario disponer de una
herramienta para simplificar la creación y gestión de
interfaces entre aplicaciones y sistemas, tanto dentro
de una misma organización como entre
organizaciones diferentes. En este sentido, los
motores de integración intercambian mensajes, por
ejemplo en formato HL7, permitiendo además la
gestión, mapeo, traducción y modificación de los
datos entre SI. En el mercado existen diversos
motores de integración diferentes con soporte para
HL7, algunos más específicos del entorno sanitario
como es Rhapsody Integration Engine de Orion
Systems International [10] y otros más generales
como es BizTalk Server de Microsoft [11].
Finalmente, las soluciones de gestión integral consisten
en productos empresariales que abarcan los distintos
ámbitos de la gestión administrativa y la práctica clínica
de un centro sanitario. Estos productos suelen consistir en
una plataforma que incluye aplicaciones que van desde la
gestión de pacientes y personal, el historial clínico
electrónico o farmacia, hasta la asignación de citas o
peticiones de pruebas, a la vez que ofrecen diferentes
soluciones tecnológicas para la interconexión con el
equipamiento médico existente en un centro sanitario. Un
ejemplo de este tipo de solución es la ofrecida por SAP
[12] en el sector de la Salud.
5.
Integración de datos entre SI
Aparte de las dificultades de intercomunicación entre SI
diferentes, que pueden solucionarse mediante el uso de
algunas de las herramientas comentadas anteriormente,
existe otra dificultad importante que se manifiesta a la
hora de integrar la información correspondiente a estos
sistemas: la existencia de múltiples tipos de
identificadores únicos para pacientes diferentes e
incompatibles, uno para cada SI.
Al intercomunicar SI heterogéneos, cada uno con su
propio dominio de identificación de pacientes, aparecen
las dificultades relativas a la identificación única de los
pacientes. Así, un mismo paciente que esté dado de alta
en centros sanitarios distintos, dispondrá de
identificadores diferentes, no sólo en contenido sino
también en formato. En este sentido, una vez lograda la
intercomunicación entre SI, se hace necesario el
desarrollo de un sistema que permita la identificación
unívoca de los pacientes a nivel autonómico y el enlace de
los diferentes registros de información sanitaria, tanto en
un mismo sistema como en sistemas distintos,
correspondientes a un mismo paciente.
Para lograr este objetivo y mejorar la integración entre los
SI, existen diferentes iniciativas, entre ellas: PIDS
(Patient/Person Identification Service) [13] de
CORBAMed o PDQ (Patient Demographics Query) [14]
y PIX (Patient Identifier Cross-referencing) [15], ambas
de IHE (Integrating the HealthCare Enterprise) [16].
CORBAMed es la división de salud del OMG (Object
Management Group) [17]. OMG es un consorcio formado
por empresas con el fin de promocionar las aplicaciones
de las Tecnologías Orientadas a Objetos. CORBAMed
nació con el objetivo de convertirse en el estándar de
interoperabilidad en el sector sanitario, aportando, como
tal, una solución para el problema de la identificación
única de pacientes.
La solución propuesta por CORBAMed no se fundamenta
en la existencia de un identificador único de paciente, sino
que facilita los mecanismos de comunicación necesarios
para que las aplicaciones puedan buscar y emparejar
diferentes perfiles de pacientes, mediante correlaciones
entre identificadores de diferentes dominios [13].
IHE es una iniciativa internacional promovida por
profesionales del sector y la industria sanitaria que
pretende mejorar, mediante el uso coordinado de
estándares ya establecidos, como HL7, la forma en que
los SI comparten información. En este sentido, la
organización desarrolla y publica Technical Frameworks
para las distintas áreas que comprenden el entorno
sanitario, en los que se describe cómo integrar los
diferentes SI que habitualmente están presentes en estas
áreas. Dentro de los Technical Frameworks, las tareas a
realizar se concretan en Integration Profiles, los cuales
describen la información, los flujos de trabajo, los actores
y transacciones involucradas para llevar a cabo una
correcta integración. Algunos de estos perfiles, como
PDQ [14] y PIX [15], están específicamente destinados a
la identificación única de pacientes en un entorno con
varios dominios de identificación.
En concreto, el perfil PDQ permite a aplicaciones
distribuidas obtener datos demográficos de los pacientes a
partir de peticiones a un servidor central. Por su parte,
PIX permite a una entidad mantener en una sola ubicación
todos los identificadores de pacientes utilizados por varios
SI.
Al igual que en el caso de HL7, también existe una
organización a nivel nacional IHE-España [18] para
promover las directrices marcadas y el trabajo realizado a
nivel internacional y adaptarlo a nuestro entorno.
6.
Modelo de interoperabilidad en las Illes
Balears
Hoy en día, en las Illes Balears se está trabajando en la
definición e implementación de un modelo de
interoperabilidad a nivel autonómico que permita a los
diferentes SI clínicos de la Comunidad interoperar.
Debido a la gran cantidad de SI involucrados y las
distintas áreas de información a tratar, para poner en
práctica la definición del modelo, así como para conocer
su comportamiento en un entorno real, se está
implementando una plataforma de interoperabilidad
centrada en el ámbito de los datos demográficos y
administrativos de los pacientes.
En concreto, se está desarrollando una plataforma piloto
que intercomunica los HIS (Hospital Information System)
de los hospitales de Son Llàtzer y Can Misses, el RIS
(Radiology Information System) de Son Llàtzer y el
sistema e-SIAP para la gestión de Atención Primaria.
Dada la heterogeneidad de los SI involucrados y la
necesidad de desarrollar una plataforma abierta y
escalable, ha sido necesario combinar el uso de diversas
de las tecnologías para la intercomunicación de SI
comentadas anteriormente. La implantación de una
solución de gestión integral fue descartada dada la
elevada cantidad de recursos que supondría a nivel
autonómico y los cambios que conllevaría en las
infraestructuras tecnológicas de las organizaciones
involucradas.
En primer lugar, se definió un formato para la
información a intercambiar entre los sistemas. Dado su
extendido uso en el entorno sanitario, se optó por utilizar
el estándar de comunicación HL7, en concreto la versión
2.3.1. Actualmente, se dispone de un documento de
especificación del formato, centrado en mensajes de tipo
ADT para la administración de pacientes, que deben tener
los mensajes HL7 que se intercambien los SI conectados a
la plataforma.
Como núcleo de la plataforma para la intercomunicación
de los SI se utiliza el motor de integración Rhapsody de
Orion Systems International, dadas sus características de
facilidad de manejo, robustez, fiabilidad y escalabilidad,
ajustadas plenamente a los requisitos de la plataforma a
implementar [19]. Rhapsody permite intercomunicar de
forma transparente los diferentes SI conectados a la
plataforma, encargándose de la gestión de las
comunicaciones, comprobando el formato de los mensajes
HL7 o haciendo peticiones al sistema de identificación
única de pacientes a través de un servicio web.
Como ya se ha comentado, otro aspecto fundamental para
la interoperabilidad entre SI, además de su
intercomunicación, es la integración de sus datos. En este
sentido, se ha desarrollado un sistema de identificación de
pacientes que asigna un identificador único a nivel
autonómico a todos los usuarios del sistema balear de
salud. Este sistema sigue las recomendaciones del perfil
de integración PIX (Patient Identifier Cross-referencing)
[15] de IHE, está basado en tecnología PL/SQL sobre
Oracle y consiste en un repositorio donde se almacena el
identificador único del paciente y su correspondiente
identificador local en cada uno de los SI conectados a la
plataforma.
Referencias
[1] Institute of Electrical and Electronics Engineers. IEEE
Standard Computer Dictionary: A Compilation of IEEE
Standard Computer Glossaries. New York. 1990.
[2] Health Level Seven. [on-Line]
(Consultado Agosto 2005).
http://www.hl7.org
http://www.centc251.org
[3] CEN/TC 251. [on-Line]
(Consultado Agosto 2005).
[4] Health
Level
Seven
Spain.
[on-Line]
http://www.hl7spain.org (Consultado Agosto 2005).
[5] Thompson, J. Avoiding a middleware muddle. IEEE
Software, vol. 14, Issue: 6, Nov.-Dec. 1997. Page(s): 92 –
95
[6] Department of Technology Planning, Commonwealth of
Virginia. Middleware standard. Diciembre 2001.
[7] The COTS Enterprise Architecture Workgroup,
Middleware Domain Team. Middleware Architecture
Report. Preparado para The Council on Technology
Services Commonwealth of Virginia. Mayo 2001.
[8] Java
Message
Service
[on-Line]
http://java.sun.com/products/jms (Consultado Agosto
2005).
[9] Chester, T. M. Cross-platform integration with XML and
SOAP. IT Professional, vol. 3, Issue: 5, Sept-Oct. 2001.
Page(s): 26-34.
[10] Orion
Systems
International
[on-Line]
http://www.orionhealth.com (Consultado Agosto 2005).
[11] Microsoft
BizTalk
Server
[on-Line]
http://www.microsoft.com/biztalk (Consultado Agosto
2005).
[12] SAP
España,
Sanidad
[on-Line]
http://www.sap.com/spain/industries/healthcare/index
.epx (Consultado Agosto 2005).
[13] OMG. Patient Identification Service Specification, version
1.0. Junio 2000.
[14] IHE IT Infrastructure Technical Committee. Patient
Demographics Query. Trial Implementation Version. IHE
IT Infrastructure Technical Framework Supplement 20042005
[15] IHE IT Infrastructure Technical Committee. Volume 1 (ITI
TF-1) Integration Profiles. IHE IT Infrastructure Technical
Framework, July 2004
[16] Integrating
the
Healthcare
Enterprise
[on-Line]
http://www.ihe-europe.org (Consultado Agosto 2005).
[17] Object
Management
Group
[on-Line]
http://www.omg.org (Consultado Agosto 2005).
[18] Integrating the Healthcare Enterprise. Grupo España [onLine] http://www.seram.es/IHE (Consultado Agosto
2005).
[19] Ponseti M, Gargoulas F, Contesti T, Cabrer M, Vaquer D.
Implementación de un motor de integración en un centro
hospitalario. Casos reales de aplicación. Informed 2004, X
Congreso Nacional de Informática Médica, Libro de
ponencias, Comunicaciones y Pósters. Pag(s) 137-142.