Salud 2.0 - Vicenç Robert

Trabajo Final – 30 de Septiembre de 2012
Vicenç Robert Butí
Página 1 de 67
SALUD 2.0
Y
EJEMPLO PRÁCTICO
Trabajo Final segundo curso de Master TIC Salud
(2011-2012)

Página 2 de 67
INDICE
1 INTRODUCCIÓN ................................................................................................3
2 BPM .....................................................................................................................6
2.1 BPMN (Business Process Modeling Notation)...............................................7
2.2 Orquestación y Coreografía de los Procesos de Negocio.............................. 16
2.3 De BPMN a BPEL (Business Process Execution Language) ........................ 18
3 Modelado de Procesos Sector Sanitario ............................................................... 22
3.1 Modelado EPC con MS Visio......................................................................22
3.2 Modelado EPC con ARIS Express............................................................... 27
3.3 Modelado BPMN con ARIS Express........................................................... 30
3.4 Modelado BPMN con BizAgi......................................................................31
4 SOA.................................................................................................................... 36
4.1 Modelo de Referencia, Arquitectura y Plataforma........................................37
4.2 CORBA.......................................................................................................39
4.3 ESB (Enterprise Service Bus) ......................................................................40
5 Estrategia BPM + SOA ....................................................................................... 43
5.1 EAI (Enterprise Application Integration) ..................................................... 44
5.2 Sistemas de Workflow.................................................................................44
5.3 Integración basada en SOA y BPM.............................................................. 46
6 Productos de Mercado......................................................................................... 51
6.1 Ensemble de Intersystems............................................................................52
6.2 Rhapsody de Orion Health...........................................................................56
6.3 Mirth ...........................................................................................................58
6.4 TIBCO ........................................................................................................59
6.5 WebMethods de SAG.................................................................................. 62
7 Conclusiones.......................................................................................................64
8 Bibliografía.........................................................................................................67

Página 3 de 67
1 INTRODUCCIÓN
El paradigma actual imperante en la empresa es la Orientación a Procesos. Las
organizaciones basadas en procesos pueden traducir las estrategias definidas por la
dirección en acciones reales sobre la organización, pueden definir indicadores clave de
rendimiento a todos los niveles y gestionar correctamente los procesos para mejorar los
resultados.
Podemos comprobar que las compañías de éxito son capaces de sincronizar y alinear sus
objetivos estratégicos con la ejecución táctica y diaria de sus procesos correspondientes.
Es por ello que debemos trasladar estas ventajas competitivas al Sector Sanitario para
obtener los mismos resultados.
El objetivo de ese trabajo es realizar un estudio sobre la situación y los componentes de
la Orientación a Procesos, mediante la Gestión de Procesos de Negocio (BPM: Business
Process Management) y complementarlo con su soporte TI necesario que tiene como
máxima expresión la Arquitectura Orientada a Servicios (SOA). El correcto desarrollo
de ambas aproximaciones permitirá el éxito de la solución a desplegar. Ambas
tecnologías se complementan y son los dos caras de la misma moneda, la empresa
orientada a la consecución de sus objetivos estratégicos, sus resultados y su capacidad
de supervivencia.
El Sector Sanitario sólo puede alcanzar sus objetivos de manera eficiente si sus
empleados/médicos/enfermeras/auxiliares/etc. y los sistemas de información se
polarizan en la misma dirección, siendo los procesos de negocio quienes facilitan esta
colaboración.
En las compañías en general suele haber una brecha entre los aspectos organizacionales
del negocio y la tecnología de información. Es importante hacer mínima esta brecha
porque el mercado suele forzar a dar más y mejores productos a los clientes. Los
productos que son exitosos hoy, pueden no serlo mañana. El mercado puede inclinarse
hacia quien ofrezca el mejor producto y que sea más barato, con más calidad y con más
eficiencia.
En un nivel organizacional, los procesos de negocio son esenciales para comprender
cómo funciona una organización. Aunque también son importantes para el diseño e
implementación de sistemas de información flexibles. Estos sistemas proveen la base
para la creación rápida de nueva funcionalidad que cree nuevos servicios, y también
para adaptar rápidamente funcionalidad existente a requerimientos del negocio.
BPM es por tanto una estrategia para gestionar y mejorar el rendimiento de una
organización optimizando sus procesos a través de la modelización, ejecución y medida
de rendimiento dentro de un ciclo de mejora continua.

Página 4 de 67
Por otro lado disponemos de SOA (Service Oriented Architecture o Arquitectura
Orientada a Servicios) que es otro paradigma que va mucho más allá de la arquitectura
de software que implementa.
La arquitectura SOA permite diseñar, construir, desplegar e integrar los servicios
independientes de los lenguajes en los que estén codificados y de las plataformas en las
que se ejecutan. Estos servicios están vinculados entre sí y se definen a través de
procesos de negocio formando servicios compuestos que llevan a cabo las funciones
empresariales. Algunos ejemplos de servicios que se pueden enumerar dentro del
mundo real son: la localización de la información de facturación para el paciente,
solicitud de transacciones recientes de cuenta financiera, identificación del propietario
de un vehículo registrado, control de inventario de almacén para un determinado
producto, o solicitud de una lista de vuelos disponibles para un determinado destino.
En este marco, los servicios pueden compartirse y reutilizarse en varios procesos de
negocio. El resultado es un entorno altamente adaptable, con menores costos para el
desarrollo de aplicaciones, mejoras en la integración y despliegue rápido.
Una simple SOA basada en servicios puede, de hecho, ser reutilizada ampliamente a lo
largo de una empresa por muchos procesos de negocio. Y estos procesos de negocio
pueden modificarse en cualquier momento a solicitud de otros nuevos y diferentes
servicios. Una vez que se despliega SOA para las funciones principales del negocio, la
capacidad de añadir dinámicamente nuevas capacidades a través de servicios pueden
ayudar a reducir los costos de desarrollo y casi eliminar el tradicional ciclo de desarrollo
más rápidamente, para ofrecer nuevos servicios al cliente y abrir nuevos canales de
mercado.
Un error común es creer que una SOA es una nueva versión de los Web Services. SOA
define un modelo para la ejecución de un determinado proceso. Los Web Services, por
otra parte, pueden facilitar la aplicación táctica del modelo SOA. De este modo, los
Web Services son esencialmente sólo una de las muchas maneras en que puede
construirse una SOA.
El desarrollo de SOA y BPM están vinculados con la utilización del workflow. El logro
principal que se busca alcanzar aquí es la representación explícita de las estructuras de
los procesos a través de modelos, y la representación controlada de los procesos
basándonos en los modelos creados con anterioridad.
El término workflow consiste en la automatización de un proceso de negocio, en su
totalidad o en parte, y en el cual se intercambian documentos, información o tareas de
un participante a otro, para provocar la acción de acuerdo a un conjunto de reglas
procedimentales.
Un sistema de gestión de workflow permite definir, crear y manejar la ejecución de
flujos de trabajo a través del uso de software, puede correr en uno o más motores, y es
capaz de interpretar la definición del proceso, interactuar con los participantes del
workflow y, donde sea requerido, invocar el uso de herramientas y aplicaciones de
tecnología de la información.

Página 5 de 67
La tecnología de workflow no sólo es capaz de soportar procesos de negocio dentro de
un sistema dado o dentro de un conjunto de aplicaciones, lo que permite efectivamente
integrar estos sistemas, sino que posibilita también representar procesos en los que hay
seres humanos activamente involucrados, y así mejorar la colaboración entre los
trabajadores con conocimiento.

Página 6 de 67
2 BPM
La Gestión de Procesos de Negocio engloba 2 visiones dentro de la empresa: el punto
de vista de los analistas de negocio y el punto de vista de las Tecnologías de la
Información TI. Los analistas de negocio desean modelizar, gestionar y optimizar los
distintos proceso de negocio de la empresa con la subordinación de las Tecnologías de
la Información. Por lo contrario los departamentos de TI consideran prioritario el uso
adecuado de los Sistemas de Información y menos relevantes los aspectos de negocio y
de modelizado de procesos.
El objetivo debe ser la conciliación de ambos puntos de vista, la alineación de
resultados comunes mediante el correcto uso de los paradigmas BPM y SOA.
Business Process Management (BPM) es un conjunto de métodos, herramientas y
tecnologías utilizados para diseñar, representar, analizar y controlar procesos de negocio
operacionales. BPM es un enfoque centrado en los procesos para mejorar el rendimiento
que combina las tecnologías de la información con metodologías de proceso y gobierno.
BPM es una colaboración entre personas de negocio y tecnólogos para fomentar
procesos de negocio efectivos, ágiles y transparentes. BPM abarca personas, sistemas,
funciones, negocios, clientes, proveedores y socios.
BPM combina métodos ya probados y establecidos de gestión de procesos con una
nueva clase de herramientas de software empresarial. Ha posibilitado adelantos muy
importantes en cuanto a la velocidad y agilidad con que las organizaciones mejoran el
rendimiento de negocio.
Con BPM se alcanzan diversos objetivos:
• Los directores de negocio pueden, de forma más directa, medir, controlar y
responder a todos los aspectos y elementos de sus procesos operacionales.
• Los directores de tecnologías de la información pueden aplicar sus habilidades y
recursos de forma más directa en las operaciones de negocio.
• La dirección y los empleados de la organización pueden alinear mejor sus
esfuerzos y mejorar la productividad y el rendimiento personal.
• La empresa, como un todo, puede responder de forma más rápida a cambios y
desafíos a la hora de cumplir sus fines y objetivos.
Para representar un proceso de negocio es preciso acordar una notación posible de modo
que cada símbolo tenga un significado unívoco. Esta posible e importante notación es la
que se conoce como BPMN.

Página 7 de 67
2.1 BPMN (Business Process Modeling Notation)
BPMN (Business Process Modeling Notation): El Business Process Management
Initiative (BPMI) ha desarrollado una notación estándar llamada Business Process
Modeling Notation (BPMN). El objetivo principal de BPMN es definir una notación
que sea rápidamente comprensible por todos los profesionales de los negocios, desde el
analista de negocio que hace el borrador inicial de los procesos, pasando por los
desarrolladores técnicos responsables de implementar la tecnología que llevarán a cabo
dichos procesos, llegando finalmente a la gente de negocio que gestionará y
monitorizará esos procesos.
Además, BPMN está apoyado en un modelo interno que genera el ejecutable
BPEL4WS. Así, BPMN crea un puente estandarizado para el gap entre el diseño de los
procesos de negocio y la implementación de procesos.
BPMN define un Business Process Diagram (BPD), que se basa en una técnica de
grafos de flujo para crear modelos gráficos de operaciones de procesos de negocio. Un
modelo de procesos de negocio, es una red de objetos gráficos, que son actividades
(trabajo) y controles de flujo que definen su orden de rendimiento.
Un BPD está formado por un conjunto de elementos gráficos. Estos elementos permiten
un fácil desarrollo de diagramas simples que serán familiares para la mayoría de
analistas de negocio (diagrama de flujo). Los elementos han sido elegidos para ser
distinguibles los unos de los otros y para usar formas familiares para la mayoría de
modeladores. Por ejemplo, las actividades son rectángulos y las decisiones son
diamantes.
Debe notarse que uno de los objetivos del desarrollo de BPMN es crear un mecanismo
simple para crear modelos de procesos de negocio, y al mismo tiempo que sea posible
gestionar la complejidad inherente en dichos procesos. El método elegido para gestionar
estos dos conflictivos requisitos fue organizar los aspectos gráficos de la notación en
categorías específicas. Esto ofrece un pequeño grupo categorías que alguien que lea un
BPD pueda reconocer fácilmente los tipos básicos de elementos y pueda entender el
diagrama. Dentro de las categorías básicas de elementos, se puede añadir información y
variaciones adicionales para dar soporte a los requerimientos complejos sin cambiar
dramáticamente el look-and-feel básico del diagrama. Las cuatro categorías básicas de
elementos son:
• Objetos de flujo
• Objetos conectores
• Artefactos
• Swimlanes
Objetos de flujo
Un BPD es un pequeño conjunto (tres) de elementos básicos, que son los Objetos de
Flujo, de modo que los modeladores no tienen que aprender y reconocer un gran
número de formas diferentes. Los tres objetos de flujo son:

Página 8 de 67
Evento: un evento se representa con un círculo. Es algo que “pasa” durante el curso del
proceso de negocio. Estos eventos afectan al flujo del proceso y suelen tener una causa
(trigger) o un impacto (resultado). Los eventos representados con un círculo con centro
abierto permiten a los marcadores internos diferenciar diferentes triggers y resultados.
Hay tres tipos de eventos, basados en cuando afectan al flujo: Inicio , Intermedio, y
Final.
Un evento se representa con un círculo. Es algo que “pasa” durante el curso del proceso
de negocio. Estos eventos afectan al flujo del proceso y suelen tener una causa (trigger)
o un impacto (resultado). Los eventos representados con un círculo con centro abierto
permiten a los marcadores internos diferenciar diferentes triggers y resultados.
Evento Inicio Evento Intermedio Evento final
Actividad: una actividad se representa con un rectángulo redondeado y es un término
genérico para el trabajo que hace una compañía. Una actividad puede ser atómica o
compuesta. Los tipos que hay son: Tarea y Sub-Proceso. El Sub-Proceso se distingue
por una pequeña marca de suma en la parte central inferior de la figura.
Gateway (compuerta): una gateway se representa por la típica figura de diamante y se
usa para controlar la divergencia o convergencia de la secuencia de flujo. El gateway
determina las tradicionales decisiones, así como la creación de nuevos caminos, la
fusión de estos o la unión. Los marcadores internos indicarán el tipo de control de
comportamiento.

Página 9 de 67
Objetos conectores
Los objetos de flujo se conectan entre ellos en un diagrama para crear el esqueleto
básico de la estructura de un proceso de negocio. Hay tres objetos conectores que hacen
esta función. Estos conectores son:
Sequence Flow: el flujo de secuencia se representa por una linea sólida con una cabeza
de flecha sólida y se usa para mostrar el orden (la secuencia) en el que las diferentes
actividades se ejecutarán en el Proceso. El término “control flow” normalmente no se
usa en BPMN.
Message Flow: el flujo de mensaje se representa por un linea discontinua con una punta
de flecha hueca y se usa para mostrar el flujo de mensajes entre dos participantes del
proceso separados (entidades de negocio o roles de negocio). En BPMN, dos pools
separadas en el diagrama representan los dos participantes.
Association: una asociación se representa por una linea de puntos con una punta de
flecha de lineas y se usa para asociar datos, texto, y otros artefactos con los objetos de
flujo. Las asociaciones se usan para mostrar entradas y salidas de las actividades.
Para los modeladores que requieren o desean más precisión para crear modelos de
proceso por motivos de documentación y comunicación, los elementos básicos más los
conectores dan la posibilidad de crear fácilmente diagramas comprensible.

Página 10 de 67
Para los diseñadores que necesiten un nivel más alto de precisión, para análisis detallado
o que sean gestionados por un Business Process Management System (BPMS), existen
detalles adicionales que se pueden añadir a los elementos básicos.
Swimlanes (canales)
Muchas metodologías de modelado de procesos usan el concepto de swimlanes como un
mecanismo para organizar actividades en categorías separadas visualmente para ilustrar
diferentes capacidades funcionales o responsabilidades. BPMN soporta los swimlanes
con dos constructores principales.
Los dos tipos de objetos swimlanes o canales son:
• Pool: una pool representa un Participante de un Proceso. Además actúa
como un contenedor gráfico para particionar un conjunto de actividades
desde otros pools, normalmente en el contexto de B2B
• Lane: una lane es una sub-partición dentro de un pool y extiende la
longitud del pool, verticalmente u horizontalmente. Las lanes se usan
para organizar y categorizar actividades.

Página 11 de 67
Las pools se usan cuando un diagrama implica dos entidades de negocio o participantes
separados y están físicamente separados en el diagrama. Las actividades dentro de pools
separadas se consideran procesos autocontenidos. Así, el flujo de secuencia no debe
cruzar el límite de un pool. El flujo de mensajes se define como el mecanismo para
mostrar las comunicaciones entre dos participantes, y, de este modo debe conectar dos
pools (o los objetos dentro de las pools).
Las pistas (lanes) están más estrechamente relacionadas con las metodologías
tradicionales de las swimlanes. Las pistas se suelen usar para separar las actividades
asociadas con la función o rol de una compañía específica. El flujo de secuencia puede
cruzar los límites de las pistas dentro de un pool, pero el flujo de mensajes no puede ser
usado entre objetos de flujo en pistas de mismo pool.

Página 12 de 67
Artefactos
BPMN fue diseñado para permitir a los modeladores y las herramientas de modelado un
poco de flexibilidad a la hora de extender la notación básica y a la hora de habilitar un
contexto apropiado adicional según una situación específica, como para un mercado
vertical (por ejemplo, seguros o banca). Se puede añadir cualquier número de artefactos
a un diagrama como sea apropiado para un contexto de proceso de negocio específico.
La versión actual de la especificación de BPMN sólo tiene tres tipos de artefactos BPD
predefinidos, los cuales son:
• Data Object: los objetos de datos son un mecanismo para mostrar como
los datos son requeridos o producidos por las actividades. Están
conectados a las actividades a través de asociaciones.
• Group: un grupo es representado por un rectángulo redondeado con
linea discontinua. El agrupamiento se puede usar documentación o
análisis, pero no afecta al flujo de secuencia.
• Annotation: las anotaciones son mecanismos para que un modelador
pueda dar información textual adicional.

Página 13 de 67
Los modeladores pueden crear sus propios tipos de artefactos, que añaden más detalle
sobre como se ejecuta el proceso. Sin embargo, la estructura básica del proceso,
determinada por las actividades, gateways, y flujos de secuencia, no se cambia por
añadir artefactos al diagrama.
El modelado de procesos de negocio se usa para comunicar una amplia variedad de
información a diferentes audiencias. BPMN está diseñado para cubrir muchos tipos de
modelados y para permitir la creación de segmentos de proceso así como procesos de
negocio end-to-end, con diferentes niveles de fidelidad. Dentro de la variedad de
objetivos de modelado de procesos, hay dos tipos de modelos básicos que se pueden
crear con un BPD:
- Procesos B2B colaborativos (públicos)
- Procesos de negocio internos (privados)

Página 14 de 67
Procesos B2B colaborativos
Un proceso B2B colaborativo ilustra las interacciones entre dos o más entidades de
negocio. Los diagramas para estos tipos de procesos están generalmente desde un punto
de vista global. Esto es, no toman la visión de un participante en particular, pero
muestra las interacciones entre los participantes. Las interacciones están ilustradas como
una secuencia de actividades y los patrones de intercambio de mensajes entre
participantes. Las actividades para los participantes son los “touch-points” entre
participantes; el proceso define las interacciones que son visibles al público para cada
participante. Cuando miramos un proceso en un solo Pool (por ejemplo, para un
participante), un proceso público también se llama proceso abstracto. Los procesos
reales (internos) son como tener más actividades y detalle que lo que se enseña en los
procesos B2B colaborativos.
Procesos de negocio internos
Un proceso de negocio interno se enfocará generalmente en el punto de vista de una
única organización de negocio. Aunque los procesos internos suelen mostrar
interacciones con participantes externos, definen las actividades que generalmente no
están visibles para el público, esto es, privadas.
Si se usan swimlanes entonces un proceso interno estará contenido dentro de un solo
Pool. El flujo de secuencia del proceso está por lo tanto contenido dentro de un Pool y
no puede cruzar los límites del Pool. El fujo de mensajes puede cruzar los límites del
Pool para mostrar las interacciones que existen entre procesos de negocios internos
separados. Así, un solo diagrama de procesos de negocio puede mostrar múltiples
procesos de negocio privados.
Propósitos diferentes – diferentes niveles de precisión
El modelado de procesos de negocio suele empezar capturando actividades de alto nivel
para luego ir bajando de nivel de detalle dentro de diferentes diagramas. Pueden haber
múltiples niveles de diagramas, dependiendo de la metodología usada para desarrollar
los modelos. De todas formas, BPMN es independiente de cualquier metodología.

Página 15 de 67
A continuación tenemos un ejemplo de procesos de alto nivel, capturados para un caso
de estudio de BPMN. Se trata de una serie de sub procesos con tres puntos de decisión
A continuación se baja de nivel para mostrar en detalle el primer sub proceso: dos
pools, una para los clientes y otra para la compañía suministradora Este diagrama
muestra un proceso de negocio interno para la compañía y un proceso abstracto para el
cliente.

Página 16 de 67
¿Cual es el valor de modelar en BPMN?
Los miembros de BPMI Notation Working Group representan un gran segmento de la
comunidad de modelado de procesos de negocio y han llegado a un consenso y
presentan BPMN como la notación de modelado de procesos de negocio estándar. El
desarrollo de BPMN es un paso importante para reducir la fragmentación que existe con
la gran cantidad de herramientas de modelado de procesos y notaciones. El BPMI
Notation Working Group aportan una gran experiencia con muchas de las notaciones
existentes y trabajan para consolidar las mejores ideas de todas estas notaciones para
crear una sola notación estándar.
Como ejemplos de otras notaciones o metodologías que existen y fueron revisadas por
el BPMI tenemos:
• Diagramas de actividades de UML
• UML EDOC Business Processes,
• IDEF
• ebXML BPSS
• Diagrama de flujo de actividades-decisiones (ADF)
• RosettaNet
• LOVeM,
• Cadenas de Eventos-Procesos (EPCs: Event-driven Process Chain).
2.2 Orquestación y Coreografía de los Procesos de Negocio
Los procesos de negocio atraviesan la estructura organizativa y definen sus reglas
independientemente del proceso.
Los servicios resuelven funcionalidades concretas requeridas dentro de cada unidad
organizativa y se componen para realizar los procesos de negocio a través de su
orquestación y coreografía.
En la tabla siguiente se presenta una comparación entre ambos conceptos fijando como
patrones a contrastar, el objetivo de cada uno, el modelo o metáfora que siguen, el
enfoque que se le da y el fundamento para su uso.
ORQUESTACIÓN COREOGRAFÍA
Objetivo Componer servicios para
cumplir con un proceso de
negocio dentro de una
organización
Componer servicios para
colaboración entre
organizaciones
Modelo Jerárquico.
Pregunta-Respuesta
Peer – to –Peer
Enfoque Componer servicios y el orden
en que son
Definir la manera en que
múltiples partes colaboran para

Página 17 de 67
ejecutados para alcanzar el
objetivo de un proceso de
negocio
conformar una transacción de
negocio
Fundamento Constituye un servicio en sí
mismo
Define la interacción del negocio
La orientación a procesos implica independizarse de la estructura organizativa, pensar
las actividades según la manera en que se ejecutan en lugar de dónde se realizan.
Los servicios resuelven aspectos funcionales directamente vinculados a la ubicación de
la unidad funcional dentro de la estructura.
Una buena resolución de procesos garantiza una buena solución orientada a servicios y
no viceversa.
La noción de una aplicación o servicio compuesto se basa en la idea de la construcción
de nuevas aplicaciones o servicios, interconectando las partes existentes. La
orquestación juega un papel importante en esto, ya que es quien aglutina estas partes al
coordinar la ejecución de cada servicio discreto.
La orquestación resuelve el problema de la ejecución de la aplicación de forma
centralizada. En ella debe existir un mecanismo que dirige las actividades. Estas
actividades son en realidad interacciones entre servicios, es decir, servicios que se
invocan unos a otros, pero no de forma desordenada, sino de manera controlada por el
orquestador que es quien conoce el detalle de todas las tareas que se deben llevar a cabo
para completar el proceso.
La construcción del proceso de negocio se realiza en dos pasos: primero se publican los
servicios y luego se orquestan, es decir, se integra cada servicio al proceso en su lugar y
momento adecuado.
En la orquestación de servicios hay varios actores involucrados. Entre ellos
encontramos la especificación del proceso de negocio, un motor de ejecución de
procesos que contiene los procesos de negocios y sus reglas, y los consumidores de los
servicios que se exponen.
A diferencia de la orquestación, la coreografía plantea un esquema en donde no hay un
control centralizado del proceso, sino un control “declarativo” que sólo especifica
cuáles son las interacciones permitidas entre dos pares. De esta forma, dadas las reglas
correctas, las partes interactuarán unas con otras en un estilo “peer-to-peer” y el proceso
de negocio estará definido de forma implícita. De ahí su nombre (coreografía), ya que se
asemeja a un estilo en donde cada parte hace su trabajo bajo ciertas reglas y se obtiene
un resultado final conjunto.
Para implementar coreografía se puede usar BPEL aún cuando éste está pensado para
orquestación. La diferencia reside en que se especifica una serie de procesos entre cada
par que interactuará y cada uno de estos procesos especificados representa la interacción
válida entre dichos pares.

Página 18 de 67
Los estándares para orquestación de procesos incluyen:
• WSBPEL: cada proceso WSBPEL se expone como un Web Service usando
WSDL que describe la entrada de datos y los puntos de salida del proceso.
• BPEL4People: es una extensión del estándar WSBPEL que inserta tareas
humanas en la orquestación.
• BPMN: una notación visual para modelar procesos. diseñado para ilustrar los
procesos y mapearlos a los lenguajes de ejecución como BPEL
El estándar número uno para ejecutar procesos de negocios y controlar en forma
centralizada (orquestar) servicios, es BPEL (Business Process Execution Language).
BPEL es un lenguaje ejecutable que especifica la interacción entre Web Service. El
estándar fue construido por un comité y hoy es mantenido por OASIS. Dicho comité se
planteó ciertos objetivos, tales como usar Web Service, usar XML, poder administrar el
ciclo de vida del proceso y poder gestionar transacciones a largo plazo.
2.3 De BPMN a BPEL (Business Process Execution Language)
Para ayudar a aliviar el vacío técnico de modelado, un objetivo clave para el desarrollo
de BPMN era crear un puente entre la notación de modelado de procesos de negocios y
los lenguajes de ejecución respecto a las Tecnologías de la Información que
implementan los procesos que hay dentro de un sistema.
A partir de un diagrama BPMN, más un buen número de atributos de sus objetos, se
puede hacer un mapeado al denominado Business Process Execution Language para
Web Services (BPEL4WS). A continuación tenemos un segmento de un proceso de
negocio que marca el mapeo con BPEL4WS.

Página 19 de 67
BPEL
(Web Services) Business Process Execution Language, WS-BPEL (en castellano,
Lenguaje de Ejecución de Procesos de Negocio con Servicios Web), es un lenguaje
estandarizado por OASIS para la composición de servicios web. Está desarrollado a
partir de WSFL y XLANG, ambos lenguajes orientados a la descripción de servicios
Web. Básicamente, consiste en un lenguaje basado en XML diseñado para el control
centralizado de la invocación de diferentes servicios Web, con cierta lógica de negocio
añadida que ayuda a la programación en gran escala (programming in the large). Antes
de su estandarización se denominaba BPEL4WS.
BPEL es un lenguaje de orquestación, no un lenguaje coreográfico. La diferencia mayor
entre ambos es el ámbito. Un modelo de orquestación provee un ámbito específicamente
enfocado en la vista de un participante en particular (ej: un modelo par-a-par). En
cambio, un modelo coreográfico abarca todos los participantes y sus interacciones
asociadas, dando una vista global del sistema. Las diferencias entre orquestación y
coreografía están basadas en analogías: la orquestación describe un control central del
comportamiento como un director de orquesta, mientras que la coreografía trata sobre el
control distribuido del comportamiento donde participantes individuales realizan
procesos basados en eventos externos, como en una danza coreográfica donde los
bailarines reaccionan a los comportamientos de sus pares.
A través de un documento XML BPEL, un analista de negocio es capaz de representar
la lógica asociada y los elementos con los que se verá relacionado. Estos elementos
serán servicios Web y la lógica el proceso BPEL.
Si imaginamos un flujo de negocio determinado, con una entrada A y una salida Z, este
se podría componer de muchos procesos internos que se lanzarían dependiendo de
valores y respuestas anteriores. BPEL sería el encargado de orquestar todo el proceso
ordenando qué proceso ejecutar (servicio Web) y en qué momento.
Este lenguaje fue concebido por grandes de la informática como Oracle, BEA Systems,
IBM, SAP y Microsoft entre otros.
Es un lenguaje de alto nivel que lleva el concepto de servicio un paso adelante al
proporcionar métodos de definición y soporte para flujos de trabajo y procesos de
negocio
El enfoque sobre procesos de negocios modernos más el bagaje de los lenguajes WSDL
y XLANG, guiaron a BPEL a adoptar los servicios Web como su mecanismo de
comunicación externa. Así las facilidades de mensajería BPEL dependen del uso del
WSDL para describir los mensajes entrantes y salientes.
Adicionalmente a proveer facilidades para habilitar el envío y recepción de mensajes, el
lenguaje de programación BPEL también posibilita:
• Un mecanismo de correlación de mensajes basado en propiedades.
• Variables del tipo XML y WSDL.

Página 20 de 67
• Un modelo de lenguaje extensible de componentes para permitir escribir
expresiones y consultas (queries) en múltiples lenguajes: BPEL soporta
Xpath 1.0 predeterminadamente.
• Construcciones de programación estructurada incluyendo "if-then-elseif-
else", "while", "sequence" (posibilita la ejecución de comandos en orden) y
"flow" (posibilita la ejecución de comandos en paralelo).
• Un sistema de ámbito (scoping) que permite el encapsulamiento de lógica
con variables locales, manejadores de fallo, manejadores de compensación y
manejadores de eventos.
• Ámbitos serializados para controlar los accesos a las variables.
Objetivos del diseño de BPEL
• Definir procesos de negocio que interactúan con entidades externas mediante
operaciones de un servicio Web definidas usando WSDL 1.1 y que se
manifiestan a sí mismas como servicios Web.
• Definir procesos de negocio utilizando un lenguaje basado en XML. No
definir una interpretación gráfica de procesos o proveer de una metodología
de diseño en particular.
• Definir una serie de conceptos de orquestación de servicios Web que
pretenden ser usados por vistas internas o externas de un proceso de negocio.
• Proveer sistemas de control jerárquicos y de estilo gráfico, que permitan que
su uso sea lo más fusionado e inconsútil posible. Esto reduciría la
fragmentación del espacio del modelado de procesos.
• Proveer funciones de manipulación simple de datos, requeridas para definir
datos de procesos y flujos de control.
• Soportar un método de identificación de instancias de procesos que permita
la definición de identificadores de instancias a nivel de mensajes de
aplicaciones. Los identificadores de instancias deben ser definidos por socios
y pueden cambiar.
• Brindar la posibilidad de la creación y terminación implícitas de instancias
de procesos, como un mecanismo básico de ciclo de vida. Operaciones
avanzadas de ciclo de vida como por ejemplo "suspender" y "continuar"
pueden agregarse en futuras versiones para mejorar el manejo del ciclo de
vida.
• Definir un modelo de transacción de largo plazo que se base en técnicas
probadas tales como acciones de compensación y ámbito, de tal manera a
brindar recuperación a fallos para partes de procesos de negocios de largo
plazo.
• Usar servicios Web como modelo para la descomposición y ensamblaje de
procesos.
• Construir sobre estándares de servicios Web (aprobados y propuestos) tanto
como sea posible, de manera modular y extensible.
La siguiente figura muestra una visión global de la Arquitectura SOA y todos sus
componentes principales.

Página 21 de 67
Si ubicamos en cada componente las tecnologías que nos parecen más apropiadas para
el despliegue tenemos la siguiente figura
En ella vemos el papel relevante de BPEL como tecnología para la composición de
servicios ya existentes para conseguir construir los procesos de negocio que permitirán
conseguir los objetivos empresariales deseados.

Página 22 de 67
3 Modelado de Procesos Sector Sanitario
Como aplicación práctica se presenta a continuación el modelado de un proceso
sanitario: el Proceso de Ingreso en Cirugía:
Mediante el modelado de este proceso se intenta mostrar y validar distintos tipos de
diagramas y herramientas para poder comparar la efectividad y las facilidades de uso.
Los posibilidades y alternativa presentadas en este trabajo son las siguiente:
• Primeramente se realizará una descripción del proceso de Ingreso en Cirugía
y su correspondiente modelado BPM mediante diagramas EPC (Event-
driven Process Chain) o Evento-Función. Para este primer paso de utiliza la
herramienta VISIO de Microsoft, herramienta que se utiliza sólo como
herramienta gráfica, sin ningún tipo de validación del proceso diagramado.
• A continuación se presenta una parte del proceso de Ingreso en Cirugía con
el mismo tipo de diagrama EPC pero mediante la herramienta ARIS Express
de Software AG. Dicha herramienta permite realizar distintas
comprobaciones en relación a la corrección del diagrama presentado. No se
hace en su totalidad porque se comprueba que a este nivel no aporta
funcionalidad adicional y los esquemas resultan más pesados y difíciles de
manipular en un portátil.
• Después se realiza el modelado del Proceso de Ingreso en Cirugía con la
herramienta ARIS Express pero utilizando la notación BPMN que es la que
se considera más idónea en la actualidad y es la que se ha descrito con cierto
detalle en este documento.
• Finalmente se utiliza la herramienta BizAgi para realizar los mismos
diagramas que se han desarrollado con ARIS Express para poder comparar
ambas herramientas.
3.1 Modelado EPC con MS Visio
Se describe a continuación lsa etapas mostradas del Proceso de Ingreso en Cirugía y los
elementos del esquema EPC (Event-driven Process Chain):
• Evento Realizar Ingreso Cirugía: Es el inicio del proceso de ingreso.
• Función Búsqueda Paciente: El auxiliar administrativo accede al menú de
pacientes del Sistema de Información Hospitalario (SIH) y busca mediante la
identificación del paciente si el paciente ya está dado de alta en el Sistema.
Puede que el paciente esté dado de alta o por lo contrario no esté dado de
alta.

Página 23 de 67
• El siguiente paso, por tanto, es un o-exlusivo, es decir hay 2 alternativas y
sólo se pueden realizar una u otra. Las alternativas son operador o-
exclusivo:
o Existe paciente en el SIH
o No existe paciente en el SIH
• Evento Si Existe Paciente: El auxiliar administrativo sólo tiene que validar
los datos administrativos del paciente: nombre, apellidos, DNI, domicilio,
teléfono, correo electrónica, etc.
• Evento Si NO Existe Paciente: El auxiliar administrativo tiene que registrar
los datos administrativos del paciente: nombre, apellidos, DNI, domicilio,
teléfono, correo electrónica, etc.
En el siguiente paso se juntan los 2 caminos del o-exclusivo y se pasa a la siguiente
función:
• Función Confirmación Origen: El auxiliar administrativo confirma o
introduce el origen del paciente: programado desde consultas externas,
derivado de otros centros, gestionado por lista de espera, etc.
• A continuación volvemos a tener 2 alternativas y sólo se pueden realizar una
u otra. Las alternativas son operador o-exclusivo:
o Existe paciente en el SIH
o No existe paciente en el SIH
• Evento Si Existe Paciente: El auxiliar administrativo sólo tiene que validar
los datos de cobertura económica y filiación del paciente: paciente privado,
mutua, seguridad social, etc.
• Evento Si NO Existe Paciente: El auxiliar administrativo tiene que registrar
los datos cobertura económica y filiación del paciente: paciente privado,
mutua, seguridad social, etc.
En el siguiente paso se juntan los 2 caminos del o-exclusivo y se pasa a la siguiente
función.
• Función Comprobación Historia y Episodio: El auxiliar administrativo
comprueba la historia clínica y el episodio. El paciente y el episodio quedan
asignados al servicio clínico correspondiente al ingreso.

Página 24 de 67
Realizar
Ingreso Cirugía
Búsqueda
Paciente
SIH
Auxiliar
Administrativo
Existe
Paciente
Revisión
Datos
Admin
1
SIH
XOR
NO Existe
Paciente
Registro
Datos
Admin
Auxiliar
Administrativo
SIH
Confirmación
Origen
XOR
SIH
Auxiliar
Administrativo
XOR
Existen
Datos
Cobertura
NO Existen
Datos
Cobertura
Revisión
Datos
Cobertura
Registro
Datos
Cobertura
SIH SIH
Auxiliar
Administrativo
XOR
Comprobación
Historia y
Episodio
SIH
Auxiliar
Administrativo

Página 25 de 67
La etapas mostradas en el dibujo número de 2 (ver más abajo), continuación del número
1 tenemos:
• Evento Paciente y Episodio Asignados: a continuación sigue.
• Función Preasignación de Cama: El auxiliar administrativo accede al
Mapa de Camas del Sistema de Información Hospitalario (SIH) y realiza
una preasignación de cama o unidad de enfermería.
• Función Confirmación de Reserva de Quirófano: El auxiliar
administrativo consulta la Planificación Quirúrgica del HIS y comprueba la
reserva de quirófano.
• La siguiente es la Función es la Validación de Otros Datos: El auxiliar
administrativo validad los otros datos clínicos: médico, diagnóstico al
ingreso, medicación preoperatoria, solicitudes de pruebas, informe de
ingreso, etc.
• Ahora se pasa a la Función de Aceptación Firmada: El auxiliar
administrativo imprime la Hoja de Consentimiento y otros documentos de
aceptación legal que debe firmar el paciente.
• Finalmente se realiza la Función de Confirmación Ingreso: El auxiliar
administrativo confirma en el SIH el ingreso del paciente a cirugía.
• Se alcanza el Evento de Ingreso Realizado y finaliza el proceso de Ingreso
en Cirugía
Comentarios:
- Para la claridad del esquema del Ingreso de Cirugía se ha omitido algunos elementos
que eran evidentes, como por ejemplo en alguna función no se ha indicado que la realiza
el auxiliar administrativo, o tampoco se ha indicado en alguna otra función que se
accede al SIH (Sistema de Información Hospitalaria), todo ello para simplificar el
esquema.

Página 26 de 67
Paciente y
Episodio
Asignados
1
Preasignación
Cama
Comprobación
Reserva
Quirófano
SIH
Aceptación
Firmada
Consentimiento
Auxiliar
Administrativo
Confirmación
IIngreso
SIH
Ingreso
Realizado
Auxiliar
Administrativo
Otros
Documentos
Auxiliar
Administrativo
Mapa Camas
SIH
Planificación
quirúrgica
Auxiliar
Administrativo
Validación
Otros
Datos
SIH
Auxiliar
Administrativo

Página 27 de 67
3.2 Modelado EPC con ARIS Express
Pasamos a continuación a mostrar el mismo esquema (o parte de él) utilizando la
herramienta ARIS Express.
ARIS Express, que es una herramienta integral que permite diagramar de forma
integrada varios tipos de esquemas,:
• Diagrama de Organización
• Proceso de Negocio a alto nivel
• Proceso de Negocio
• Modelo de Datos
• Infraestructura TI
• Sistemas TI
• Diagrama según modelo BMPN
• Diagrama tipo general
A continuación se muestra la pantalla de inicio de modelado de ARIS Express

Página 28 de 67
Utilizando ARIS Express primeramente se muestra el Esquema del Proceso de Ingreso
de Cirugía a alto nivel (Nivel 0) y podemos afirmar que hay cuatro funciones
importantes:
• Validar / Registrar Datos Pacientes
• Comprobar Historia Clínica y Episodio
• Preasignación de Cama y Quirófano
• Firma de Consentimiento.
Model graphic:
A continuación se desarrolla el esquema de parte del Proceso de Ingreso de Cirugía
utilizando ARIS Express.
Como se puede ver no aporta, a nivel de esquema, ninguna novedad en relación a los
esquemas realizados con VISIO, pero en cambio hay que resaltar que todos los
esquemas están integrados. Además ARIS sólo permite realizar determinadas acciones y
comprueba en todo momento la integridad y coherencia de la información introducida.
En contraposición con VISIO sólo se ha realizado un dibujo o esquema, de forma libre,
y sin ninguna restricción.
Otra característica importante de ARIS Express es que genera los capítulos y apartados
de la documentación de forma automática. En el diagrama se han introducido
comentarios adicionales, utilizando las cuadros de comentario de ARIS Express para
complementar el esquema.

Página 29 de 67
Model graphic:

Página 30 de 67
3.3 Modelado BPMN con ARIS Express
Se utiliza en este apartado la misma herramienta ARIS Express pero basándonos en los
diagramas BPMN que son los más adecuados para un modelado profesional y
correctamente validado, y que permite posteriormente generar instrucciones BPEL de
forma inmediata para la construcción del proceso de negocio.
Los diagramas BPMN permite definir los Diagramas de Proceso de Negocio (BPD)
mediante Tareas y SubTareas / Subprocesos lo que facilita una visión de distintos
niveles del proceso de negocio a diagramar.
Primeramente se presenta el BPD de nivel 0, en que sólo hay los Tareas Principales que
serán descompuestas en los siguientes diagramas de nivel 1.
Como hemos indicado anteriormente el Proceso de Ingreso de Cirugía a alto nivel y
podemos decir que hay cuatro subprocesos importantes:
El proceso se inicia con el correspondiente Evento de Inicio (círculo verde) y finaliza
con el Evento de Finalización (círculo rojo)
Cada uno de las tareas anteriores debe descomponerse en sus correspondientes procesos.
A continuación se modela el Subproceso de Validar / Registrar los Datos de Paciente y
para ello se utiliza la compuerta exclusiva XOR , que implica que de varias alternativas
presentadas sólo puede utilizarse una.

Página 31 de 67
El siguiente subproceso que se ha modelado es el Preasignación de Cama y Quirófano
como se muestra a continuación.
3.4 Modelado BPMN con BizAgi
Pasamos a desarrollar los diagramas del Proceso de Ingreso en Cirugía utilizando
BizAgi.
BizAgi es una suite ofimática con dos productos complementarios, un Modelador de
Procesos (bizagi Process Modeler) y una Suite de BPM (bizagi BPM Suite):

Página 32 de 67
• Bizagi Process Modeler es un Freeware que cuenta con miles de usuarios a
nivel mundial y es utilizado para diagramar y documentar procesos usando la
notación estándar BPMN (Business Process Modeling Notation)
• Bizagi BPM Suite es una solución de Gestión de procesos de negocio (BPM)
que le permite a las organizaciones ejecutar/automatizar procesos o flujos de
trabajo (workflows). Bizagi BPM Suite se integra con aplicaciones como
SAP, Documentum, Sharepoint y correo electrónico. Existe una edición de
nivel de entrada (Edición Xpress) y dos ediciones corporativas (Enterprise
.NET y Enterprise JEE).
Bizagi Limited es una compañía privada establecida en 1989, y su nombre significa
agilidad de negocio (Business Agility).
Volvemos a diagramar el BPD de novel 0 con los correspondientes subprocesos:

Página 33 de 67
Vemos que en este Diagrama de Nivel 0 ya nos aparece el concepto de Canal o Lanes
para indicar la propiedad o pertenencia del Proceso.
Pasamos ahora a analizar los distintos subprocesos. Primeramente desarrollamos el
diagrama del Subproceso de Validar / Registrar Datos de Pacientes
Una vez realizado el diagrama podemos comprobar el subproceso de Validar / Registrar
Datos de Pacientes puede visualizarse dentro del proceso principal si se considera
necesario. La herramienta BizAgi permite este tipo de representaciones que facilita la
comprensión de los diagramas:
A continuación desarrollamos el Subproceso de Preasignación de Cama y Quirófano
con sus 3 tareas correspondientes:

Página 34 de 67
Podemos visualizar una vez mas el proceso a nivel 0 (BPD0) y su descomposición, en el
mismo diagrama, con los subprocesos correspondientes.
Pasamos ahora a mostrar distintos formas de enriquecer los diagramas y mejoras la
comprensión de ellos mediante comentarios explicativos.

Página 35 de 67
También podemos añadir texto formateado para disponer de información adicional para
la comprensión del proceso diagramado.
Finalmente en la definición del subproceso de Consentimiento se han utilizado los
denominados Artefactos para mostrar que el Sistema genera un documento que el
Paciente debe aceptar y firmar. En este caso se generan 2 documentos: la Hoja de
Consentimiento y Otros Documentos Legales.

Página 36 de 67
4 SOA
La arquitectura orientada a servicios de cliente (en inglés Service Oriented
Architecture), es un concepto de arquitectura de software que define la utilización de
servicios para dar soporte a los requisitos del negocio.
Permite la creación de sistemas de información altamente escalables que reflejan el
negocio de la organización, a su vez brinda una forma bien definida de exposición e
invocación de servicios (comúnmente pero no exclusivamente servicios web), lo cual
facilita la interacción entre diferentes sistemas propios o de terceros.
SOA define las siguientes capas de software:
• Aplicaciones básicas - Sistemas desarrollados bajo cualquier arquitectura o
tecnología, geográficamente dispersos y bajo cualquier figura de propiedad;
• De exposición de funcionalidades - Donde las funcionalidades de la capa
aplicativa son expuestas en forma de servicios (generalmente como servicios
web);
• De integración de servicios - Facilitan el intercambio de datos entre elementos
de la capa aplicativa orientada a procesos empresariales internos o en
colaboración;
• De composición de procesos - Que define el proceso en términos del negocio y
sus necesidades, y que varía en función del negocio;
• De entrega - donde los servicios son desplegados a los usuarios finales.
SOA proporciona una metodología y un marco de trabajo para documentar las
capacidades de negocio y puede dar soporte a las actividades de integración y
consolidación.
Conceptos y definiciones
Comenzaremos definiendo el concepto de una arquitectura de software para poder
comprender mejor la idea de una Arquitectura Orientada a Servicios.
Según IEEE una arquitectura de software es la organización fundamental de un sistema,
reflejado por sus componentes, relaciones entre ellos y entorno, así como los principios
que regirán su diseño y evolución.
Según OASIS, se define como la estructura o estructuras de un sistema de información
formado por entidades y sus propiedades externamente visibles, así como las relaciones
entre ellas (Modelo de Referencia para SOA 1.0 – Agosto de 2006).
Adaptándose a la definición de OASIS, se define SOA como un paradigma capaz de
organizar y utilizar las capacidades distribuidas, que pueden estar bajo el control de
distintas organizaciones, y de proveer un medio uniforme para publicar, descubrir,
interactuar y usar los mecanismos oportunos para lograr los efectos deseados.

Página 37 de 67
Podemos resumir los conceptos subyacentes fundamentales en este paradigma en los
siguientes:
Proveedor: entidad (organización o persona) que ofrece el uso de capacidades mediante
servicios.
• Necesidad: carencia de una empresa para resolver la actividad de su negocio.
• Consumidor: entidad (organización o persona) que busca satisfacer una
necesidad particular a través de las capacidades ofrecidas por servicios.
• Capacidad: tarea que el proveedor de un servicio puede proporcionar al
Consumidor
• Servicio: mecanismo que permite el acceso a una o más capacidades alcanzables
por medio de una interfaz preestablecida, y que se llevará a cabo de forma
consistente con las normas establecidas para él.
• Descripción del servicio: información necesaria para hacer uso del servicio.
• Interacción: actividad necesaria para hacer uso de una capacidad con el objeto de
obtener efectos deseados
4.1 Modelo de Referencia, Arquitectura y Plataforma
SOA es un modelo de referencia para entender las relaciones más significativas dentro
del dominio de un problema concreto y facilitar el desarrollo de estándares o
especificaciones. Se fundamenta en un pequeño número de conceptos para explicar el
modelo a profanos y busca producir una semántica sin ambigüedades.
SOA es un modelo de referencia para:
• La creación y utilización de servicios a lo largo de su vida útil
• La definición de la infraestructura que permita intercambiar datos entre
diferentes aplicaciones
• La participación de los servicios en los procesos de negocios
independientemente del sistema operativo, los lenguajes de
programación y si los procesos son internos o externos a la organización
Los conceptos y sus relaciones, definidas en el modelo de referencia SOA, deben ser la
base para describir la arquitectura.
Una arquitectura SOA concreta será el producto de aplicar la arquitectura de referencia
desarrollada según el modelo de referencia y los patrones de esa arquitectura, así como
los requerimientos necesarios, incluyendo los impuestos por los entornos tecnológicos.
La aplicación de un modelo de referencia para lograr una arquitectura completa,
equivale a pasar de una etapa de análisis a una de diseño en analogía con las etapas del
ciclo de vida del software. Implica dar un paso más en el nivel de detalle y comenzar a
buscar metodologías para aplicar sobre los conceptos analizados.

Página 38 de 67
Una arquitectura concreta se desarrolla en un contexto predefinido donde se fijan
protocolos, perfiles, especificaciones y estándares. La plataforma SOA combina estos
elementos a los efectos de generar un producto operativo.
La Figura siguiente presenta un marco general entre la noción de marco de referencia,
arquitectura de referencia y arquitectura específica, que muestra qué aporta y en qué
consiste cada una de ellas, así como el paso de lo más abstracto hacia lo más concreto.
Según los conceptos subyacentes a SOA descriptos con anterioridad, el modelo de
interacción es uno de los más relevantes dado que aporta la manera en que los servicios
se comunican entre sí.
Este modelo de interacción sigue el paradigma triangular de Publicar - Buscar –
Ejecutar.
En este paradigma, los proveedores registran sus servicios en un registro público. Los
consumidores utilizan este registro para buscar servicios que cumplan con cierto
criterio. Si el registro posee tal servicio, el mismo provee al consumidor con un contrato
y un punto de acceso para el servicio.
• Publicar: para que un servicio sea usado, su descripción de servicio debe
ser publicada
• Descubrir / Encontrar: el consumidor busca una descripción de servicio
directamente, o hace una búsqueda de servicios. La operación se puede
hacer en dos puntos del ciclo de vida del cliente: durante el diseño o
durante la ejecución

Página 39 de 67
• Enlazar: el cliente del servicio invoca o inicia la interacción con el
mismo durante la ejecución, contando con los detalles en la descripción
del servicio para localizarlo, contactarlo e invocarlo
4.2 CORBA
El mecanismo de integración vía un broker o agente de mensajes es el marco conceptual
sobre el que se sustenta CORBA. CORBA (Common Object Request Broker
Architecture) fue el proyecto de middleware más importante y ambicioso de la industria
de la informática de fines de la década del ‘90. Es producto de un consorcio que
aglutinó a 650 compañías (entre las que NO se encuentra Microsoft que compitió con
DCOM (Distributed Componente Object Model).
El bus de objetos de CORBA define la forma de los componentes que viven dentro de él
y cómo interoperan. CORBA constituye un estándar de la OMG4 que establece una
plataforma de desarrollo de sistemas distribuidos facilitando la invocación de métodos
remotos bajo un paradigma orientado a objetos.
CORBA fue diseñado para permitir que componentes inteligentes (pensadas en
términos de objetos) se descubran unas a otras e interoperen. Pero trasladar el
paradigma de la orientación a objetos a un entorno distribuido implica sin duda agregar
conceptos que están ausentes en un entorno único o local como lo son:
• Transaccionalidad
• Seguridad
• Cerramiento y/o Aislamiento
• Persistencia

Página 40 de 67
Para alcanzar los objetivos de interoperabilidad se definió el IDL (Interface Definition
Language). Es un lenguaje puramente declarativo, no provee detalles de
implementación y provee independencia del lenguaje de programación y del sistema
operativo. Un IDL se usa para:
• Especificar atributos de los componentes
• Heredar clases de un padre
• Levantar excepciones
• Emitir eventos tipificados
• Declarar los métodos que soporta el componente
La gramática IDL es un subconjunto de C++ con palabras claves adicionales para
soportar conceptos distribuidos. El ORB (Object Request Broker) es el middleware que
establece la relación solicitud/proveedor entre objetos distribuidos.
Las interfaces mediante las cuales especificar los servicios que se proveen, están
definidas en el lenguaje IDL de OMG y los objetos distribuidos son identificados por
medio de referencias que implementan la interfaz remota.
Por último, CORBA define un conjunto de servicios distribuidos, definidos en el nivel
superior del ORB, para soportar la integración e interoperabilidad de objetos
distribuidos. Estos servicios resuelven los aspectos mencionados anteriormente acerca
de los objetos distribuidos como lo son la transaccionalidad, seguridad, cerramiento y/o
aislamiento y persistencia
4.3 ESB (Enterprise Service Bus)
En función de las motivaciones presentadas en el paradigma SOA, resulta evidente la
necesidad de contar con una infraestructura de IT que apoye la gestión de los servicios.
Sobre una arquitectura SOA se puede definir un bus de servicios empresariales
(Enterprise Service Bus o ESB) como una plataforma de software que da soporte a
muchas funcionalidades resueltas a nivel de la capa de aplicación en los enfoques
tradicionales de construcción de aplicaciones.
Tales funcionalidades son:
• La comunicación: el ESB se ocupa del enrutamiento de los mensajes
entre los servicios.
• La conectividad: el ESB resuelve la conectividad entre extremos
mediante la conversión de protocolos entre solicitante y servicio.
• La transformación: es responsabilidad del ESB resolver la
transformación de formatos de mensajes entre solicitante y servicio.
• La portabilidad: los servicios serán distribuidos independientemente del
lenguaje de programación en el que estén escritos y del sistema operativo
subyacente.

Página 41 de 67
• La seguridad: el ESB posee la capacidad de incorporar los niveles de
seguridad necesarios para garantizar servicios que puedan autenticarse,
autorizarse y auditarse.
Actualmente existen dos tendencias mayoritarias para la implementación de un ESB: los
que requieren un servidor de aplicaciones y los que son totalmente distribuidos y, por lo
tanto, no lo requieren.
Funcionalmente, cualquiera de las dos tendencias conserva sus propias características
pero se puede afirmar que un ESB totalmente distribuido que no requiere de un servidor
de aplicaciones tendrá mayor independencia de la plataforma y será capaz de ofrecer
una mayor ubicabilidad de los servicios que gestiona.
Más allá de la estructura interna, el concepto de bus, lo componen los mecanismos de
comunicación que hacen que todos los elementos conectados al ESB puedan conectarse
entre sí, sin necesidad de conocerse unos a otros.
Un ESB centraliza el control y distribuye el procesamiento. Para lograr este objetivo los
ESB evolucionaron desde la integración por adaptadores, donde se centralizaba tanto el
control como el procesamiento. Los ESB representan una suerte de federación de
adaptadores a gran escala donde la configuración centralizada es un concepto que se
implementa de manera distribuida
En la siguiente Figurase muestra el resultado de la implementación de un ESB. El nodo
de Configuración y Control de Servicios tiene línea punteada para ilustrar su
construcción lógica.
Cuando las soluciones tecnológicas brindan herramientas completas para gestionar los
servicios desde los procesos de negocios, los ESB están dirigidos por los servidores de

Página 42 de 67
procesos donde se definieron los procesos de negocios y es dicho servidor quien
gestiona y orquesta las solicitudes a través del ESB. Tal es el caso de la solución de
IBM mediante su línea de WebSphere BPM.
En este marco, podemos afirmar que, hoy por hoy, los Web Services no constituyen un
ESB por sí mismos, pero sí pueden ser parte de él.

Página 43 de 67
5 Estrategia BPM + SOA
En este capítulo se realiza un análisis evolutivo del estado del arte respecto a la
integración de aplicaciones y se estudian las características principales de esta evolución
para poder plantear un nuevo modelo de integrabilidad entre SOA y BPM.
Este modelo se basa en la premisa de obtener soluciones a los problemas de las
organizaciones, que cuenten con una integración completa y esté guiada por una
metodología.
Como vimos en el capítulo 4, SOA es una metodología de desarrollo de software que se
enfoca en crear una arquitectura más flexible que pueda atravesar múltiples dimensiones
mientras que BPM, por su parte, se enfoca puramente en optimizar la manera de trabajo
real.
En el capítulo 2, al describir BPM, vimos que representa una manera de analizar y
medir el negocio o la realidad, en términos de procesos de negocios que atraviesan la
organización y los límites de los sistemas.
Si bien los primeros esbozos de realizar reingeniería de procesos fueron un aporte
importante en el sentido de que se basaban en la idea de la mejora de los mismos, no
dejaban de enfocarse en la automatización de la tarea y no en la optimización de la
misma. Además tenían la particularidad de que los procesos se gestionaban por
herramientas construidas ad-hoc.
La evolución natural fue entonces hacia la definición de una estrategia para gestionar y
mejorar el rendimiento de un negocio a través de la optimización continua de sus
procesos dentro de un ciclo de modelado, ejecución y medida. BPM es tal estrategia o
disciplina. BPMS (Sistemas o Suite para BPM) proveen un conjunto de herramientas
integradas que soportan el diseño, media, monitorización, análisis y mejoras continuas
al proceso de negocio.
BPM es el complemento natural de SOA, y un mecanismo a través del cual una
organización puede aplicar SOA a sus procesos de negocio.
BPM aporta valor en el mundo real mientras que SOA facilita la integración de
soluciones y provee tecnologías para gestionar los componentes técnicos de un proceso
de negocio.
Los analistas de procesos de negocio usan BPM para crear y optimizar modelos de
procesos de negocio, encontrar servicios de negocio que implementen las actividades
modeladas, volcándolos en un BPMS.
Lo deseable es que el resultado de esta producción culmine en procesos desplegados
como servicios, registrados en un repositorio y expuestos a los consumidores.

Página 44 de 67
El modelo de integración que se presenta y que surge de un análisis del estado del arte
en términos de integración de aplicaciones, define un conjunto de componentes tanto
tecnológicos como de negocios, que dan una visión unificada e integradora de la
solución alcanzada.
5.1 EAI (Enterprise Application Integration)
Este modelo se basa en la construcción de un nodo central y un conjunto de repetidores
directamente asociados a éste, aunque los repetidores no se encuentran conectados entre
sí. De esta manera, el middleware está representado por la integración centralizada de
aplicaciones, y las aplicaciones que deben ser integradas son reflejadas por los
repetidores. Las mismas interactúan entre ellas por medio de la integración centralizada
de aplicaciones.
Las aplicaciones pueden interactuar de formas muy diversas, desde invocaciones
simples hasta interacciones complejas entre múltiples aplicaciones. Estas últimas
consisten en una serie de actividades representadas por una invocación a una aplicación,
además de existir restricciones de ejecución entre las mismas.
Este esquema de agentes y mensajes tiene ciertos inconvenientes. El primero de ellos es
que el agente contiene cierta lógica, oculta en las reglas. La programación de éstas
puede volverse una labor compleja debido a las dependencias que pueden darse entre las
mismas, y el hecho de cambiar una regla puede tener implicancias en el comportamiento
global del sistema.
La razón principal de estos problemas es la “pérdida” conceptual que se da en la
integración de aplicaciones, ya que la integración de datos y de procesos requiere gran
actividad de programación y configuración de bajo nivel, tanto de adaptadores como de
los agentes de mensajes.
La integración de datos suele darse mediante actividades de mapping, lo cual requiere
un modelo de datos acordado entre todas las aplicaciones y que reside en los agentes.
Este modelo global suele no ser explícitamente desarrollado, pero es común encontrarlo
oculto en las reglas de mapeo de datos efectuadas por los adaptadores.
5.2 Sistemas de Workflow
El término workflow consiste en la automatización de un proceso de negocio, en su
totalidad o en parte, en el cual se intercambian documentos, información o áreas de un
participante a otro, para provocar la acción de acuerdo a un conjunto de reglas
procedimentales.
Un sistema de gestión de workflow es un sistema que permite definir, crear y manejar la
ejecución de flujos de trabajo a través del uso de software, que corre en uno o más
motores, y que es capaz de de interpretar la definición del proceso, interactuar con los

Página 45 de 67
participantes del workflow y, donde sea requerido, invocar el uso de herramientas y
aplicaciones IT.
La integración de aplicaciones es efectuada por el sistema de gestión de workflow,
usando adaptadores similares a los que se usan en un ambiente tradicional de
aplicaciones empresariales.
La tecnología de workflow es capaz de soportar procesos de negocio dentro de un
sistema dado o dentro de un conjunto de aplicaciones, lo que permite efectivamente
integrar estos sistemas. Sin embargo esta tecnología posibilita también representar
procesos en los que hay seres humanos activamente involucrados, y así mejorar la
colaboración entre los trabajadores con conocimiento.
El sistema de workflow cubre todos los aspectos del proceso de negocio
correspondiente: el Flujo, la Gente y los Efectos
La tecnología de gestión de workflow puede ser utilizada para facilitar la modificación
de la lógica del proceso realizado por aplicaciones. Las funciones de una aplicación son
pasos en el workflow, y cada componente usa un modelo de workflow para representar
las funciones. Por la modificación de la lógica del proceso especificada en los modelos
de workflow, se puede modificar el comportamiento de las aplicaciones sin codificar.
Workflow no es:
– Un sistema de gestión de documentos (trabaja con ellos)
– Un sistema de e-mail o groupware (trabaja con ellos)
– Un sistema de distribución de datos entre sistemas (para ello workflow utiliza
EDI, WebForms, XML, SOAP, http, etc.)
– Una transacción para secuenciar pantallas
– Administración de datos temporales
– Una herramienta que se utilice para realizar funciones no existentes en el
sistema (si no se puede ejecutar la función manualmente en el sistema,

Página 46 de 67
entonces el sistema de workflow tampoco lo hará)
Se presenta a continuación algunos esquemas de workflow.
Hoy en día, la mayor cantidad de aplicaciones empresariales, como las aplicaciones de
planificación, poseen un componente workflow que facilita la adaptación flexible de los
procesos de negocio dentro de estos sistemas.
Podemos concluir que una aplicación de workflow única consiste de actividades y su
correspondiente ordenamiento causal y temporal, donde las mismas son realizadas por
un sistema común. Los workflow de aplicación múltiple contienen actividades que son
realizadas por sistemas de múltiples aplicaciones, proveyendo así una integración de las
mismas.
5.3 Integración basada en SOA y BPM
El software de workflow utilizado para integrar aplicaciones siguiendo el paradigma de
SOA y BPM y puede cubrir cuatro aspectos:
• Ser un componente de aplicaciones verticales. Un software de workflow
es ágil a la hora de adaptarse a los cambios de procesos y cambios
organizacionales. Esta es una realidad en muchas aplicaciones verticales.

Página 47 de 67
• Es adecuado para utilizarlo como APIs. Esto es así si cuenta con soporte
para Java que permite integrarse tanto para aplicaciones Web como para
otras aplicaciones de IT.
• Constituye el elemento unificador para aplicaciones colaborativas, tanto
desde el punto de vista de aplicaciones que se construyen como
composición de otras bajo la filosofía de Web Services, como del de la
automatización de procesos basados en reglas.
• Se ajusta a la implementación de Web Services.
Pero en una aplicación donde el proceso de negocio sea realmente un conjunto de tareas
cuyos participantes son Servicios Web, provoca inevitablemente un desorden dentro del
workflow y surge la necesidad de interoperar y describir procesos ejecutables.
La interoperabilidad se logra a través de la adopción de estándares como XML y
WSDL, mientras que la descripción de procesos ejecutables se puede llevar a
cabo a través de BPEL
Los desarrollos en arquitectura de software empresarial y en BPM están relacionados
con la gestión de workflow. El logro principal que se busca alcanzar aquí es la
representación explícita de las estructuras de los procesos a través de modelos, y la
representación controlada de los procesos basada en los modelos creados con
anterioridad.
Para la realización de aplicaciones de composición en un ambiente de orientación a
servicios, se utilizan técnicas de composición de servicios.
El middleware de integración de aplicaciones en general, y el middleware de bus de
servicios empresariales en particular, proveen una base técnica aceptable para realizar
composición de servicios, debido a que proveen interfaces estándar que pueden ser
utilizadas en desarrollos de composición. El middleware típico para la integración de
aplicaciones empresariales presenta un componente de workflow de sistema, que puede
o bien usar un código propietario o bien usar código BPEL (Lenguaje de ejecución de
procesos de negocio para Web Services).
La composición de servicios es una idea de especial interés para el desarrollo de nuevas
aplicaciones, basándose en funcionalidad ya existente. Así, la composición describe la
forma en que se relacionan los distintos servicios, es decir que se están describiendo
estructuras de proceso. Como resultado, una composición BPM como la nueva
metodología para satisfacer los objetivos de una organización a través de la gestión de
procesos de negocio, no plantea una visión completamente renovadora y de empezar de
cero, sino que es necesario contemplar todo el trabajo realizado con anterioridad dentro
de la empresa, de manera de apuntar a la integración. Aquí es donde se insertan los
conceptos de SOA, Web Services y BPEL, de manera tal de lograr construir una
aplicación real, integrada e insertada en un entorno B2B, y por sobre todo, orientada a
procesos.

Página 48 de 67
El modelo de integración tiene por objetivo lograr una integración completa, segura y
confiable de un conjunto de sistemas de software existentes, maximizando la
reutilización de código, manteniendo un bajo acoplamiento y favoreciendo el
mantenimiento ágil y a bajo costo.
Los elementos de este modelo de integración llevan a analizar los tipos de integración
posible, los métodos aplicados para llevar a cabo la integración, los componentes de
infraestructura requerida y los actores que participan. Este análisis realizado tiene por
finalidad aportar criterios a la hora de decidir cuáles de todos los elementos se elegirán
para componer un modelo de integración.
Tipos de integración
Si bien existen diversas taxonomías acerca de los posibles tipos de integración
existentes, los más frecuentes, teniendo en cuenta el enfoque que se abordará, se
refieren a la integración desde dos aspectos posibles:
• Integración a nivel de datos: se enfoca en el movimiento de datos entre
aplicaciones con el objetivo de compartirlos. Es una integración
relativamente simple si se comparten formatos y estructuras, de lo
contrario se establecen protocolos o acuerdos entre las partes para poder
realizar la integración. (Ejemplo: integración por XML)
• Integración a nivel de aplicaciones: se basa fundamentalmente
encompartir funcionalidad. Es una integración basada en APIs que
exponen su funcionalidad a través del uso de interfaces que serán tanto
más portables dependiendo del lenguaje utilizado para definirse. (Ej: IDL
de CORBA o WSDL de los Web Services)
Tanto desde el punto de vista de los datos como de las aplicaciones, el modelo de
integrabilidad aborda cualquiera de estos tipos de integración con la visión de los
mismos como servicios coordinados por procesos.
La integración de datos dirigida por procesos ayuda a enriquecer los servicios de
negocios SOA y los procesos BPM a través de una secuencia de servicios de datos
combinados de manera reusable que incorpora la intervención de tareas humanas
transformando la información en exacta, consistente y oportuna.
La integración de aplicaciones tiene por objetivo entender y usar las interfaces para
acceder a la funcionalidad requerida y enmascarar u ocultar las diferencias tecnológicas
usadas por cada interfaz en su acceso. Esto último se lleva a cabo con servicios que
exponen sus interfaces.
La idea subyacente es que los procesos de integración se encuentren separados de los
procesos de negocio en sí mismos. Esto requiere examinar los sistemas existentes,
extraer datos y procesos y obtener una manera de meta-anotación
Componentes de infraestructura para la integración

Página 49 de 67
Los componentes de la infraestructura son un conjunto de servicios agrupados según la
funcionalidad que resuelven y que conforman la base sobre la que se construirá el
modelo de integrabilidad.
Analizamos cada uno en detalle dando una idea de su implementación posible.
Comunicación
La comunicación asegura a los desarrolladores un nivel de abstracción tal, que pueden
independizarse de los detalles de bajo nivel asegurando que proveedor y consumidor de
servicio puedan encontrarse. Pueden utilizarse sistemas de comunicación asincrónicos
basados en mensajería o bien sincrónicos vía un broker de objetos o bien un ESB.
Estos middleware usan protocolos estándar como SOAP (Simple Object Access
Protocol), HTTP, TCP/IP, IIOP (Internet Inter-ORB Protocol)
• Enrutamiento y mediación: el enrutamiento y mediación es un nivel
que adapta el nivel de comunicación entre aplicaciones de tal modo que
las mismas puedan interoperar. Entre las responsabilidades que tiene este
nivel está la de lograr que datos provenientes de distintas fuentes
representen un concepto de negocio. Este nivel utiliza metadatos para
definir las aplicaciones participantes, los métodos, los mensajes, las
interfaces y las secuencias de operación invocados.
• Transformación: La transformación de las estructuras de datos ha sido
siempre un problema resuelto de manera puntual, escribiendo código ad-
hoc que leía y transformaba al formato destino de manera puntual. La
aparición de los lenguajes de marcado y en particular el XML como
estándar de facto para el intercambio de datos, otorgaron un mayor nivel
de madurez a la transformación de los datos. La transformación hoy
puede considerarse como un servicio provisto por las máquinas de
transformación basadas en XSLT (EXtensible Stylesheet Language for
Transformations) que producen transformaciones independientes del
lenguaje y la plataforma.
• Coordinación/Orquestación: En un enfoque dirigido por procesos es
preciso sincronizar las actividades de integración definiendo
formalmente los servicios que requieren los procesos y las aplicaciones,
secuenciándolos en una orquestación. En este sentido, una infraestructura
de integración debe contar con algún mecanismo de coordinación inter-
procesos o intra-procesos que ordene los pasos a seguir para conducir los
servicios.
La orquestación ha evolucionado desde el enfoque manual al
automatizado. En el primer caso, se reducía a código inyectado en las
plicaciones que resolvía integración punto a punto y que tenía embebida
la lógica del workflow. Esto resultaba difícil de mantener y de modificar.

Página 50 de 67
El enfoque automático provee una mayor flexibilidad, desacoplando
procesos de datos y produciendo un servicio de datos independiente que
inicia una tarea de integración de datos de bajo nivel como parte del
proceso de workflow.
Este último enfoque, el automático, es solamente posible si los servicios
están construidos de modo adecuado como módulos autocontenidos sin
las dependencias típicas de la programación procedural.
• Transacción: Uno de los principales aportes al definir una
infraestructura de integración es la de proveer un mecanismo para llevar
a cabo las operaciones de modo transaccional, esto es, la capacidad de
invocar operaciones sobre diferentes sistemas soportando la semántica
del modelo transaccional bajo las propiedades ACID (Atomicity,
Consistency, Isolation, Durability). Estas propiedades garantizan la
preservación de la consistencia del sistema, aíslan las operaciones entre
sí, otorgan persistencia a los cambios y además son atómicas.
• Seguridad: Desde el punto de vista de la integración, la seguridad
conlleva los mismos conceptos tradicionales: autorización, autenticación
y auditoría. En este sentido, la infraestructura de la integración debe
proporcionar los medios para limitar el acceso al sistema, hacerlo de una
manera unificada y dejar rastros de dichos accesos

Página 51 de 67
6 Productos de Mercado
En este capítulo vamos a valorar y comparar distintos productos de mercado que aplican
los paradigmas de SOA y BPM. Estos productos presentan distintos grados de madurez
respecto a la evolución de SOA y además algunos de ellos son de aplicación genérica
para todo tipo de empresas o negocio y otros específicos para el Sector Sanitario.
Los productos que vamos a supervisar son los siguientes:
• Específicos para el Sector Sanitario
o Ensemble de Intersystems
o Rhapsody de Orion Health
o Mirth (Open Source)
• Generalistas
o TIBCO
o WebMethods de Software AG
En la siguiente figura del Informe Forrester de ESB para el inicio del año 2011 podemos
ver que los dos productos generalistas TIBCO y WebMethods (Software AG) están
posicionados en primera posición como líderes, seguidos por las soluciones de Oracle,
IBM, etc. También aparece MuleSoft que es el ESB que utiliza Mirth

Página 52 de 67
Pasamos a describir cada uno de los productos:
6.1 Ensemble de Intersystems
Ensemble es una plataforma de integración que implementa la última generación de
ESB y las últimas especificaciones de SOA. Utilizar Ensemble® implica trabajar con un
software líder en sistemas interconectados para el Sector Salud.
Ensemble permite que las aplicaciones podrán conectarse fácilmente a diversos
sistemas, servicios y procesos de negocio. Y también consigue mejorar rápidamente las
aplicaciones existentes (sin reescribirlas) con sólo añadir:
• Interfaces Web potentes
• “Workflow”adaptable
• Procesos de reglas de negocio
• Monitorización de la actividad de Negocio
• Otras funciones nuevas
Las características principales de Ensemble son las siguientes:
• Motor de Mensajería:
o Soluciones con direccionamiento basado en publicación /
suscripción, orientado a eventos y basada en contenidos
o Direccionamiento de mensajería inteligente con un motor de
normas ampliable

Página 53 de 67
o Modificación y gestión sencilla de la normas de direccionamiento
mediante un editor de normas gráfico para programadores y
analistas de negocio
o Acceso en tiempo real a mensajes en directo y procesados
previamente para la monitorización de la actividad de negocio,
alta fiabilidad y capacidad de recuperación para procesos de
negocio de larga duración
o Soporte bidireccional para XML, SOAP, servicios Web y otros
formatos de mensajería estándar, incluidos HL7 y X12 en
asistencia sanitaria.
o Creación rápida de transformaciones de datos personalizadas con
un editor de transformación de datos gráfico y basado en XML
• Base de datos de objetos incorporada y compatible con SQL
o Indexación de mapa de bits transaccional para acceso en tiempo
real tanto a mensajes en directo como procesados previamente
para monitorización de la actividad de negocio (BAM), auditoría,
informes basados en SQL y gestión
o Alta fiabilidad, capacidad de recuperación y rendimiento para
procesos de negocio de larga duración
o Un repositorio compartido de mensajes y metadatos posibilita una
integración más rápida, un desarrollo rápido, una gestión más
sencilla y mayores posibilidades de ampliación
o La base de datos ya probada soporta miles de usuarios
concurrentes y terabytes de datos
o Evita la sobrecarga de rendimiento y los costes superiores de una
base de datos relacional de terceros
• Tecnología de abstracción avanzada
o Proporciona una representación de objetos coherente y eficiente
de diversos modelos de programación y formatos de datos
o Desarrollo rápido de aplicaciones compuestas a través de la
potente abstracción de reglas y datos
o Puede hacer que los recursos abstractos estén disponibles para el
proyecto en diversos formatos que incluyen COM, .NET, ODBC,
Java, JDBC, EJB, XML y servicios Web
o Permite el uso de las últimas herramientas y tecnologías de
desarrollo para acceder a datos y funciones existentes como
componentes .NET o J2EE reutilizables, servicios Web o XML
o Proporciona tanto soporte para J2EE como para .NET y puede
ampliarse fácilmente para los futuros modelos de objetos y
infraestructuras tecnológicas
o Permite acceder a diversos sistemas de gestión de bases de datos
como una sola base de datos "federada
• Entorno rápido de integración y desarrollo
o Desarrollo rápido, orientado a servicios, de aplicaciones
compuestas que aprovechan los datos y las funciones existentes

Página 54 de 67
o Trabaja con lenguajes y herramientas que ya son familiares para
los desarrolladores
o Simplifica y acelera el modelado y la automatización de los
procesos de negocio para los analistas de negocio y los
desarrolladores
o Combina y compatibiliza el desarrollo gráfico, con XML y con
código para cubrir el rango más amplio de escenarios de
integración
o Desarrollo automático de adaptadores aprovechando los servicios
SOAP
o Integración inmediata con herramientas de gestión de procesos de
negocio de terceros a través del soporte del estándar BPEL
• Transformaciones de datos
o Acelera la terminación de los proyectos al eliminar las barreras
que surgen por las diferencias en la semántica y los esquemas de
datos entre las aplicaciones o los servicios
o Los asistentes de transformación y un editor de transformación
gráfico reducen la curva de aprendizaje y agilizan el desarrollo de
transformaciones
o Las transformaciones pueden utilizar fórmulas o búsquedas
sencillas en tablas de datos internas o externas
o Ampliable hasta cualquier grado de complejidad añadiendo
funciones personalizadas
• Orquestación de los procesos de negocio
o El modelado gráfico permite a los desarrolladores y a los
analistas de negocio centrarse en los procesos de negocio en lugar
de en la tecnología
o Combinar y compatibilizar los enfoques de integración
sincronizados (gráfico, documentos XML o código) para resolver
eficientemente el mayor rango de proyectos de integración
o Orquestar y mantener el estado de los procesos de negocio de
cualquier duración
o Cambiar el comportamiento de los procesos de negocio en
funcionamiento mediante normas fácilmente editables, en lugar
de mediante código
o Incorporar el flujo de trabajo del personal a procesos
automatizados
o Monitorizar la actividad y el estado de todo el sistema y de los
indicadores de rendimiento clave
• Motor de normas de negocio
o Los analistas de negocio y el personal de soporte pueden
configurar y cambiar rápidamente los puntos de decisión en un
proceso de negocio en marcha
o Reduce los costes ocasionados por los cambios

Página 55 de 67
o Libera desarrolladores para que trabajen en proyectos nuevos, en
lugar de en modificaciones de proyectos antiguos
o Las normas están separadas de las reglas de negocio y pueden
reutilizarse y modificarse tan fácilmente como otros objetos de
Ensemble
• Monitorización de la actividad empresarial
o Aprovecha el almacenamiento de mensajes y metadatos de la
base de datos incorporada para obtener más conocimientos
operativos sobre los procesos de negocio y el rendimiento del
sistema
o Conocimiento inmediato de los eventos de negocio y los cambios
en los indicadores de rendimiento claves
o Las pantallas de los paneles de mandos gráficos ayudan en la
toma de decisiones de gestión adecuadas y a tiempo
o Reduce los costes y acelera la ejecución de las estrategias de
negocio
o Las medidas empresariales definidas por Ensemble pueden iniciar
procesos de negocio automáticos para tomar acciones correctivas
y proporcionar notificaciones
• Motor de flujo de trabajo adaptable
o Totalmente integrado con el entorno de desarrollo
o Asignación eficiente de las tareas
o Mejor control sobre la ejecución de las tareas
o Las tareas pueden reutilizarse fácilmente en cualquier proceso de
negocio
o Incorporación sencilla de las interacciones manuales complejas,
que abarquen divisiones geográficas, tecnológicas y
departamentales, en aplicaciones compuestas.
o Separación de las definiciones de procesos de usuario a partir de
las reglas de negocio para obtener un desarrollo más sencillo y
más fiable
• Infraestructura y biblioteca de adaptadores
o Conectividad y transformaciones de datos predefinidas para un
amplio rango de aplicaciones, servicios, orígenes de datos y
tecnologías
o Ampliación rápida de los adaptadores existentes y creación de
adaptadores nuevos mediante el entorno de desarrollo de
Ensemble, la herencia de objetos y los servicios SOAP para
minimizar el esfuerzo de desarrollo necesario
o Todos los adaptadores comparten capacidades comunes para
conseguir una integración sencilla y coherente, así como
operaciones y gestión fiables
• Soporte de estándares
o Amplio soporte de los estándares de muchos sectores

Página 56 de 67
o Permite interoperar con otros sistemas que soportan los mismos
estándares
o Aprovecha los conocimientos que han obtenido los
desarrolladores utilizando los mismos estándares en otros
proyectos
o Protección de la inversión
• Gestión en todos los niveles
o La interfaz basada en la Web permite la gestión local o remota
desde cualquier dispositivo
o Optimización de los niveles de servicio y reducción de la carga de
trabajo del personal mediante la definición de consolas de gestión
personalizadas y alertas para monitorizar los recursos críticos
o Diagnóstico rápido y depuración de problemas durante el
desarrollo y las operaciones reales utilizando Visual Trace
o Utilización de cualquier herramienta SQL para consultar y
generar informes personalizados a partir del almacén de mensajes
para auditorías y otras necesidades de gestión
o Visión en tiempo real de los procesos de negocio así como del
rendimiento del sistema
6.2 Rhapsody de Orion Health
Las principales ventajas del Motor de Integración de Rhapsody son las siguientes:
• Rendimiento y Robustez: Diseñado teniendo en cuenta un alto
rendimiento y de disponibilidad, incluso durante la administración y
mantenimiento del sistema
• Fácil de Usar: El motor de Rhapsody es fácil de configurar a través de
un intuitivo de arrastrar y soltar, mientras que la supervisión del sistema
utiliza una familiar interfaz basada en Web que es fácil de usar y tiene
una potente capacidad de búsqueda
• Experiencia en Sector Salud: Diseñado para organizaciones de salud, por
lo que ofrece la experiencia única y la funcionalidad que necesita y que
otros productos no pueden ofrecer.
• Flexibilidad y Funcionalidad: El uso de la tecnología Java estándar y API
específicos para desarrolladores puede ofrecer un alto grado de
personalización y programación, así como la compatibilidad
multiplataforma
• Sin costes escondidos: Rhapsody ofrece un bajo coste de propiedad
(TCO) debido a los costes bajos de licencia y a la facilidad de su
implementación.

Página 57 de 67
Rhapsody ofrece una completa, potente integración back-end para las empresas del
Sector Salud El motor de integración Rhapsody asegura una integración sin esfuerzo
entre los sistemas sanitarios. Rhapsody dispone de apoyo para los distintos protocolos
de comunicación. en distintos formatos de mensaje. Esto permite Rhapsody actuar como
un mediador de mapeo y traducción entre sistemas incompatibles. Los mensajes se
entregan de forma fiable y precisa, independientemente del tipo de formato o el
transporte requerido
Las facilidades de Rhapsody para arrastrar y soltar permiten la configuración compleja
de enrutamiento y procesamiento de forma fácil y sus potentes herramientas basadas en
la Web de monitorización permiten una resolución rápida y eficaz de los problemas o el
reprocesamiento de los mensajes.
Rhapsody ofrece un alto rendimiento de almacenamiento de mensajes para asegurar la
trazabilidad completa y un rendimiento óptimo. Los mensajes se archivan en el almacén
de mensajes.

Página 58 de 67
6.3 Mirth
Mith es un motor con interfaz HL7 de plataformas cruzadas de código abierto que
permite el envío birideccional de mensajes HL7 entre sistemas y aplicaciones sobre
múltiples capas de transporte. Utilizando un bus framework de servicio empresarial y
una arquitectura orientada a canales, Mirth permite el filtrado de mensajes, el
transformado, y el enrutamiento de los mismos en base a una reglas definidas por el
usuario. Permite crear interfaces HL7 para los sistemas de forma fácil utilizando la
interfaz web y el asistente para crear canales que asocian las aplicaciones con los
componentes del motor Mirth.
Para integrar los servicios con los sistemas HL7 se debe implementar una capa de
adaptación para transformar los mensajes entre el dominio de la aplicación y el del
dominio de HL7. Mirth hace que este paso sea fácil proporcionando el framework para
la conexión de sistemas dispares con los protocolos establecidos en los adaptadores y
las herramientas de transformación de mensajes.
Mirth utiliza una arquitectura basada en canales para conectar los sistemas con otros
sistemas HL7. Los canales consisten en terminales (de entrada y de salida), filtros, y
transformadores. Múltiples filtros y una cadena de transformadores se pueden asociar
con un canal. La interfaz web de Mirth permite la reutilización de filtros y
transformadores en múltiples canales.
Los terminales se utilizan para configurar las conexiones y los detalles de los
protocolos. Los terminales de entrada se utilizan para designar el tipo de “listerner” para
los mensajes de entrada, como por ejemplo TCP/IP o un servicio web. Los terminales
de salida se utilizan para designar el destino de los mensajes de salida, como por
ejemplo a una aplicación servidora, una cola JMS, o una base de datos.

Página 59 de 67
Las características de Mirth son las siguientes:
• Amplia variedad de conectores. Mirth puede configurarse para escuchar
y enviar mensajes HL7 y conectar una variedad de protocolos:
o TCP/MLLP
o Bases de datos (MYSQL, Postgres, Oracle, MS SQL, ODBC)
o Archivos (sistema de archivos locales y compartición de redes)
o JMS
o FTP/SFTP
o SOAP (sobre HTTP)
• Plataforma cruzada. Mirth soporta la mayoría de sistemas operativos
(aquellos que soporten la máquina virtual de Java en su versión 1.5.
• Creación o utlización de filtros y perfiles de valildación. El sistema de
filtrado de Mirth permite elegir el tipo de mensajes que se acptan y se
encaminan. Multiples destinatarios se pueden seleccionar
automáticamente especificando los filtros HL7.
• Creación o utilización de transformadores. Una interfaz de Mirth permite
la creación de transformadores y mapeos de datos HL7. Simplementente
seleccionando y arrastrando con el puntero del ratón fragmentos de
mensajes HL7 creamos mapeos, o utilizar una variedad de funciones para
hacer consultas en la bases de datos, enviar correos electrónicos. Las
transformaciones disponibles son las siguientes:
• Transformador de mapeo: Mapea los datos desde los mensajes entrada
hasta las variables.
• Transformador de script: Ejecuta scripts definidos en los mensajes (por
ejemplo, JavaScript, Python, Tcl).
• Generador de mensajes HL7: construye mensajes HL7 a partir de una
fuente de datos.
• Transformador XSLT: Ejecuta transformacioens XLS sobre mensajes de
entrada HL7 v3 o XML. Todos los mensajes y transacciones se registran
en una base de datos interna. Se puede configurar para que se genere de
forma automática respuestas de reconcocimiento HL7 (ACK).
• Motor ESB robusto: Mirth está basado en el motor Mule ESB para
proporcionar velocidad, estabilidad y seguridad en un entorno flexible.
6.4 TIBCO
Los productos de TIBCO se centran en hacer realidad la visión de la compañía para su
estrategia de "Enterprise 3.0" y SOA. TIBCO ofrece la tecnología de la información
correcta en el lugar correcto en el momento adecuado con el contexto correcto, dando a
las empresas y organizaciones una ventaja significativa en el servicio a sus clientes y la
gestión de sus operaciones.
TIBCO ha identificado los siguientes requisitos fundamentales para Entreprise 3.0:
• Gestionar eventos a gran escala

Página 60 de 67
• Desarrollar y gestionar aplicaciones de forma universal
• Conectar a los profesionales con a la tecnología de forma natural
TIBCO es una plataforma tecnológica neutral diseñado para simplificar el desarrollo de
aplicaciones, implementación y administración de la gestión de compuestos de procesos
empresariales (BPM) y arquitecturas orientadas a servicios (SOA). La familia
ActiveMatrix incluye productos para la creación de servicios e integración, redes de
servicios y distribución de datos, aplicaciones empaquetadas, BPM y el gobierno.
Las principales características de TIBCO son:
• Integración, Orquestación y entorno la creación personalizado:
o ActiveMatrix BusinessWorks ofrece una rica gama de facilidades
para conectar, integrar, enrutar, transformar y distribuir datos
XML o no XML, tales como cuadernos COBOL a través de
diferentes protocolos como HTTP, JMS, FTP y correo
electrónico.
o Dispone de un potente conjunto de servicios, orquestación,
integración, manejo de excepciones, y las capacidades de
transacciones distribuidas, incluyendo BPEL 2.0.
o La creación de servicios gráficos con la importación / exportación
mediante un solo clic de definiciones de servicios de / a los
registros.
• Alto rendimiento, escalabilidad y confiabilidad a través de un sistema
distribuido, basado en Arquitectura Gris
o Las capacidades avanzadas de fiabilidad y capacidad de
recuperación como el soporte para control de flujo, o el
seguimiento de la dependencia, y la capacidad de automatizar la
auto-corrección que ha ayudado a las empresas a alcanzar el
99,99% o mayor tiempo de actividad.
• Entorno integrado de servicios

Salud 2.0 - Vicenç Robert

Recommandé

Recommandé

Contenu connexe

Similaire à Salud 2.0 - Vicenç Robert

Similaire à Salud 2.0 - Vicenç Robert (20)

Plus de Regulación Emocional TIPI

Plus de Regulación Emocional TIPI (12)

Dernier

Dernier (16)

Salud 2.0 - Vicenç Robert