Con este artículo completamos la serie sobre SOA. En los anteriores artículos hemos visto una introducción a la estrategia SOA, partiendo del problema de la “arquitectura espagueti”. Ahora ya sabemos que en SOA existe un catálogo de servicios que podemos consumir o producir (o proveer).

Vamos a ver qué relación existe entre estos servicios, los servicios web y los estándares de interoperabilidad en sanidad. Finalizaremos la serie de artículos resumiendo todas las ventajas vistas hasta el momento (¡y alguna más!) que obtendremos si adoptamos una estrategia SOA.

Serie de artículos sobre Arquitectura Orientada a servicios (SOA):

• I: El problema de la arquitectura espagueti.
• II: ¿Qué es SOA?
• III: Servicios web, estándares y ventajas de SOA.

SOA, los servicios web y los estándares sanitarios

Es conveniente no confundir los servicios del catálogo SOA con los servicios web, son cosas completamente diferentes. Esta creencia tan extendida hace que los servicios web se vinculen fuertemente (por error) al término SOA.

Los servicios web son una tecnología muy extendida en la actualidad. Surgieron de la necesidad de intercambiar datos entre aplicaciones desarrolladas en diferentes lenguajes de programación y ejecutadas además sobre plataformas diferentes. Utilizan un conjunto de protocolos que a todos nos sonarán, como HTTP, FTP, SMTP, SOAP (¡no confundir con  SOA!) o REST, y se pueden describir mediante una interfaz pública haciendo uso de un WSDL.

Los servicios web son interesantes para SOA porque se pueden describir mediante un  WSDL. Un WSDL es un contrato entre las partes para producir o consumir un servicio. Así, para recibir la mensajería del servicio que se pretenda producir (o proveer) el ESB tiene que publicar un WSDL , y los consumidores deben publicar un WSDL para consumirlos desde el ESB.

En resumen, los servicios web son una tecnología muy recomendable para implementar los servicios de SOA, pero no es la única.  SOA como estrategia debe quedar por encima de todas las tecnologías e implementaciones.

¿Y qué papel juegan los estándares sanitarios en SOA?

Independientemente de cómo se implementen los servicios en SOA, la información que se intercambia debe estar basada en estándares sanitarios.

Ejemplo con el censo de pacientes

Continuando el ejemplo del anterior artículo: el censo de pacientes. Para mantener este censo en un sistema sanitario que utilice una estrategia SOA, servicios web para la implementación y mensajería HL7, tendremos que:

1. Identificar los servicios del catálogo que queremos consumir.
2. Publicar un WSDL para consumir de cada uno de estos servicios del ESB.
3. Procesar la mensajería HL7 recibida.

Por otro lado, la organización debe decidir qué tipos de mensajes HL7 se han de utilizar para implementar sus servicios. Algunas implementaciones típicas son:

• ADT^A28 para la creación de un nuevo paciente.
• ADT^A08 para la modificación de un paciente.
• ADT^A40 para la fusión de pacientes.
• ADT^A23 para la eliminación de un paciente.
• ADT^A37 para la anulación de fusión de pacientes.
• ADT^A47 para cambiar la lista de identificadores de un paciente.

Dentro de estas implementaciones, la organización también tendrá que decidir qué vocabularios controlados se deben utilizar para la semántica (SNOMED-CT, ICD-10, LOINC, etc.).

En definitiva, si queremos integrar nuestra aplicación en SOA, debemos usar obligatoriamente implementaciones basadas en estándares de interoperabilidad sanitaria establecidas por la organización.

Ventajas de adoptar una estrategia SOA

Hasta ahora hemos destacado muchas de las ventajas que obtendremos si seguimos una estrategia SOA. Aquí vamos a resumirlas y a añadir alguna más:

Flexibilidad y escalabilidad

El acoplamiento débil entre sistemas integrados hace que sea fácil la sustitución, adición y actualización de los mismos. De esta forma nuestras integraciones no se verán afectadas por estos cambios.

No crear dependencias de las tecnologías

Usar de tecnologías como servicios web permite intercambiar información entre aplicaciones de forma independiente de las tecnologías y plataformas que usen.

Servicios concentrados

El uso de un catálogo de servicios impuesto por la organización hace que todos los procesos de negocio del sistema se encuentren centralizados. De esta forma evitamos el análisis redundante de los requisitos funcionales específicos de cada aplicación.

Enrutado centralizado y tratamiento homogéneo de la seguridad

Todas las comunicaciones entre los extremos están centralizadas por el ESB. Esto hace que sea posible intercambiar información entre aplicaciones sin realizar tareas de especificación y análisis directamente con ellas. Todas las gestiones necesarias para integrar nuestra aplicación las realizaremos a través de la organización. Esto también permite que se pueda dar un tratamiento homogéneo a la seguridad.

Composición de servicios en base a otros más simples

La organización debe definir un nivel de granularidad lo suficientemente grande como para cubrir un proceso de negocio completo, y, a la vez, lo suficientemente pequeño como para cubrir necesidades específicas que pueden existir en las aplicaciones. Así se pueden crear servicios más generales a partir de otros más simples en caso de que nuestra aplicación lo requiera.

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 proveer) o consumir los 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 involucradas. Y sin duda reducirá grandes costes a medio-largo plazo y permitirá que el sistema siga creciendo y evolucionando de forma natural.

Con esto ponemos el punto y final a la serie sobre SOA: partimos del problema de la arquitectura espagueti, explicamos qué es  SOA y para terminar hemos comentado su relación con los servicios web y las ventajas que aporta.

En la próxima serie de artículos hablaremos de las herramientas interesantes que todos debemos conocer a la hora de abordar integraciones sanitarias.