En artículos anteriores, hemos explorado las ventajas de integrar sistemas en sanidad y los principales estándares sanitarios. Ahora, vamos a describir el escenario ideal para integrar nuestra aplicación, lo que nos lleva a la Arquitectura Orientada a Servicios (SOA).

En este artículo hablaremos de SOA, su finalidad, su papel en las aplicaciones, su relación con los servicios web y mucho más. Explicaremos por dónde empezar la integración SOA y las ventajas de adoptar esta estrategia, basándonos en pruebas y en nuestra experiencia.

Antes de definir SOA, es importante comprender el problema que llevó a su creación. Esto nos lleva a la «arquitectura espagueti», o integración punto a punto, un auténtico antipatrón.

La integración Punto a Punto y sus problemas #

Desde hace muchos años, existe la necesidad de integrar aplicaciones en los sistemas sanitarios en medio de una rápida evolución tecnológica. Los que llevamos tiempo en este campo conocemos los retos de hacer las cosas precipitadamente.

El problema es que estas necesidades se han abordado esporádicamente, centrándose en el ahorro de costes a corto plazo y en objetivos inmediatos, sin una visión estratégica o de futuro.

Cada comunicación en la integración era punto a punto, implementada mediante aplicaciones integradas, conexiones a bases de datos, archivos FTP, etc., lo que daba lugar a sistemas estrechamente acoplados. Cada sistema utilizaba su semántica o abusaba de los estándares en las comunicaciones.

Al cabo de un tiempo de adoptar esta «estrategia», los sistemas quedan atrapados en una «arquitectura espagueti». Esto puede cuantificarse calculando el número total de conexiones punto a punto en función del número de sistemas integrados.

Por ejemplo:

• 2 sistemas: 1 conexión.
• 3 sistemas: 3 conexiones.
• 4 sistemas: 6 conexiones.
• 5 sistemas: 10 conexiones.
• …
• 50 sistemas: 1225 conexiones.
• 100 sistemas: 4950 conexiones.

C = (N * (N - 1)) / 2
Where:
- N: number of systems
- C: number of point-to-point connections.

Está claro que integrar incluso unos pocos sistemas hace casi imposible sustituir, añadir o actualizar sistemas.

SOA al rescate #

Ante este escenario indeseable, podríamos preguntarnos:

¿No sería ideal centralizar todo este flujo de información redundante de forma que permitiera desacoplar los sistemas entre sí?

¿No sería preferible tener procesos empresariales generalizados representados en un catálogo de servicios, en lugar de necesidades específicas y requisitos funcionales para cada aplicación?

¿No sería beneficioso que los sistemas integrados utilizaran correctamente los mismos estándares de mensajería y semántica?

¿No sería sensato adoptar una estrategia común que permita la evolución tecnológica natural de los sistemas de información, y la sustitución, adición y actualización de los sistemas integrados sin incurrir en costes desorbitados?

Puedes encontrar las respuestas a estas preguntas y a otras más en la siguiente sección sobre qué es SOA, sus ventajas y las funciones que puede desempeñar nuestra aplicación en esta arquitectura.

¿Qué es SOA? #

SOA significa Arquitectura Orientada a Servicios. Hay muchas definiciones de SOA en Internet, dependiendo de quién la adopte, cómo y dónde.

Algunos proveedores de tecnología ven SOA como una arquitectura tecnológica centrada en un Bus de Servicios Empresariales, otros lo relacionan con servicios web o un conjunto de aplicaciones para la integración de sistemas. A este término se le ha atribuido casi todo.

Sin embargo, SOA no es una tecnología o una arquitectura de software/hardware en sí misma, ni siquiera un concepto. Nos alineamos con quienes piensan que SOA es una estrategia centrada en los procesos empresariales que conducen a un catálogo de servicios. Los servicios web forman parte de la solución tecnológica recomendada para su implantación, aunque no son obligatorios.

Como proveedores de tecnología especializados en la integración de sistemas, hablamos de SOA desde la perspectiva de las aplicaciones integradas. Desde nuestro punto de vista, hay una gran diferencia entre integrar una aplicación dentro de SOA y sin ella. De ahí que siempre aconsejemos a las organizaciones que se comprometan con una estrategia SOA. Es una inversión a largo plazo que realmente merece la pena.

Otros enlaces interesantes:

• SOA en Wikipedia.
• SOA en arcitura.com.
• Un caso de éxito de SOA en España: Servicio Andaluz de Salud (SAS).

¿Qué roles puede desempeñar nuestra aplicación en SOA? #

En SOA, hay un catálogo de servicios. Ejemplos de estos servicios son:

• ingresar un paciente,
• dar un alta,
• fusionar historias clínicas,
• informar de resultados de laboratorio, estudios radiológicos, recetas médicas,
• etc.

Aunque cada sistema sanitario tiene su catálogo, hay un conjunto básico de servicios comunes que suelen implementarse.

Para integrar nuestra aplicación con SOA, tenemos que determinar qué servicios queremos consumir y cuáles podemos producir (o proporcionar). Nuestra aplicación debe declararse consumidora de algunos servicios y productora (o proveedora) de otros.

Nuestra aplicación como consumidora de servicios #

Para integrar nuestra aplicación, necesitamos información sobre los pacientes e historiales médicos. Los servicios básicos, generalmente producidos por los Sistemas de Información Hospitalaria (HIS), nos permiten mantener un censo actualizado de pacientes para nuestra aplicación.

Los servicios más comunes son:

• crear un nuevo paciente,
• modificar los datos demográficos del paciente,
• y fusionar pacientes.

Menos comunes pero a veces implementadas son eliminar un paciente y anular una fusión de pacientes.

Si necesitamos información de otros sistemas, como LIS o RIS, simplemente nos declaramos consumidores de sus servicios. Debe justificarse ante la organización la necesidad de esta información adicional.

Una de las grandes ventajas de SOA es el débil acoplamiento de los sistemas. Si uno de estos sistemas cambia en el futuro, el nuevo sólo tiene que implantar los mismos servicios, y nosotros, como consumidores, no nos veríamos afectados. También debemos ser conscientes de que nuestro sistema puede ser sustituido por otro. Esto es impensable con la estrategia de integración punto a punto.

Nuestra aplicación como productora de servicios #

Si la información que proporciona nuestra aplicación encaja en un servicio del catálogo, podemos declararnos productores (o proveedores) de ese servicio.

Si nuestra aplicación produce información útil que no encaja en ningún servicio del catálogo, tenemos que negociar con la organización su inclusión.

En cualquier caso, la clave es que todas las tareas de especificación y análisis se realicen directamente con la organización, independientemente de las aplicaciones con las que compartamos información.

Hasta ahora, hemos hablado del problema de la integración punto a punto o «arquitectura espagueti», hemos introducido el término SOA y hemos examinado algunas ideas a tener en cuenta si queremos integrar dentro de SOA. Para concluir este artículo, veremos la relación entre SOA, servicios web y estándares sanitarios, y por último, resumiremos las ventajas de adoptar una estrategia SOA.

SOA, estándares de interoperabilidad sanitaria y servicios web #

Esta sección completa nuestro artículo sobre SOA. Anteriormente, hemos introducido la SOA, partiendo del problema de la «arquitectura espagueti» o integración punto a punto. Ahora sabemos que en SOA hay un catálogo de servicios que podemos consumir o producir (o proporcionar).

Veamos la relación entre estos servicios, los servicios web y los estándares de interoperabilidad sanitaria. Concluiremos resumiendo todas las ventajas (¡y más!) de adoptar una estrategia SOA.

Es importante no confundir los servicios SOA con los servicios web; son totalmente distintos. Esta creencia generalizada vincula erróneamente los servicios web estrechamente a la SOA.

Los servicios web, una tecnología muy extendida hoy en día, surgieron de la necesidad de intercambiar datos entre aplicaciones desarrolladas en distintos lenguajes de programación y ejecutadas en distintas plataformas. Utilizan un conjunto de protocolos que nos son familiares, como HTTP, FTP, SMTP, SOAP (¡no confundir con SOA!) o REST, y pueden describirse mediante una API o WSDL.

Los servicios web son interesantes para la SOA porque pueden describirse (mediante un WSDL o la documentación de la API), lo que establece un contrato entre las partes para producir o consumir un servicio. En resumen, es muy recomendable utilizar servicios web para implantar servicios SOA, pero no son la única opción. La SOA como estrategia debe estar por encima de todas las tecnologías e implementaciones.

¿Qué papel desempeñan los estándares sanitarios en SOA? #

Independientemente de cómo se implementen los servicios en SOA, la información clínica intercambiada debe basarse en estándares sanitarios.

Ejemplo con el Censo de Pacientes

Siguiendo con el ejemplo de la sección anterior, para mantener el censo de pacientes en un sistema sanitario utilizando una estrategia SOA, servicios web para la implementación y mensajería HL7, necesitaríamos

1. Identificar los servicios del catálogo que queremos consumir.
2. Publica un servicio web para cada uno de estos servicios.
3. Procesa la mensajería HL7 recibida.

La organización debe decidir qué tipos de mensajes HL7 va a utilizar para implementar sus servicios. Las implementaciones típicas incluyen:

• ADT^A28 para crear un nuevo paciente,
• ADT^A08 para modificar a un paciente,
• ADT^A40 para fusionar pacientes,
• ADT^A23 para borrar un paciente,
• ADT^A37 para deshacer una fusión paciente,
• y ADT^A47 para cambiar la lista de identificadores de un paciente.

Dentro de estas implementaciones, la organización también debe decidir qué vocabularios controlados utilizar para la semántica(SNOMED-CT, CIE-11, LOINC, etc.).

En resumen, si queremos integrar nuestra aplicación en SOA, debemos utilizar implementaciones basadas en estándares de interoperabilidad sanitaria establecidos por la organización.

Ventajas de adoptar una estrategia SOA #

Ya hemos destacado muchas ventajas de seguir una estrategia de Arquitectura Orientada a Servicios (SOA). Vamos a resumirlas y a añadir algunas más:

Flexibilidad y escalabilidad #

El débil acoplamiento entre los sistemas integrados facilita su sustitución, adición y actualización. Esto significa que estos cambios no afectarán a nuestras integraciones.

Independencia de la tecnología #

El uso de tecnologías como los servicios web permite el intercambio de información entre aplicaciones, independientemente de las tecnologías y plataformas que utilicen.

Servicios concentrados #

El uso de un catálogo de servicios impuesto por la organización centraliza todos los procesos empresariales del sistema. Esto evita el análisis redundante de los requisitos funcionales específicos de cada aplicación.

Enrutamiento centralizado y tratamiento uniforme de la seguridad #

Todas las comunicaciones entre puntos finales están centralizadas. Esto permite intercambiar información entre aplicaciones sin tener que realizar tareas de especificación y análisis directamente con ellas. Toda la gestión necesaria para integrar nuestra aplicación se realiza a través de la organización, lo que también permite un enfoque uniforme de la seguridad.

Composición de servicios basados en otros más simples #

La organización debe definir un nivel de granularidad lo suficientemente grande como para abarcar un proceso empresarial completo, pero lo suficientemente pequeño como para satisfacer las necesidades específicas que puedan existir en las aplicaciones. Esto permite crear servicios más generales a partir de otros más sencillos, si así lo requiere nuestra aplicación.

Uso de estándares sanitarios #

Todos los sistemas integrados deben utilizar los estándares de interoperabilidad sanitaria impuestos por la organización para producir (o proporcionar) o consumir servicios del catálogo.

Y, por supuesto, reducción de costes #

Todas estas ventajas hacen que adoptar esta estrategia sea una muy buena inversión para todas las partes implicadas. Sin duda, reducirá costes significativos a medio y largo plazo y permitirá que el sistema siga creciendo y evolucionando de forma natural.

Con esto, concluimos nuestro artículo sobre SOA: empezamos con el problema de la «arquitectura espagueti» o integración punto a punto, explicamos qué es SOA y, por último, discutimos su relación con los servicios web y las ventajas que ofrece.