SOA - IOP. Dos caras de la misma moneda.
76
UNIVERSIDAD DE ALCALÁ ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA Master universitario en informática pluridisciplinar – Especialización en Tecnologías de la Información para la Salud TRABAJO FINAL DE MASTER SOA – IOP: dos caras de la misma moneda José Román Fernández Engo 2.011
-
Upload
jose-roman-fernandez-engo -
Category
Technology
-
view
645 -
download
10
Transcript of SOA - IOP. Dos caras de la misma moneda.
UNIVERSIDAD DE ALCALÁ
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA
Master universitario en informática pluridisciplinar – Especialización en
Tecnologías de la Información para la Salud
TRABAJO FINAL DE MASTER
SOA – IOP: dos caras de la misma moneda
José Román Fernández Engo 2.011
TFM: SOA – IOP: dos caras de la misma moneda
TFM: SOA – IOP: dos caras de la misma moneda
UNIVERSIDAD DE ALCALÁ
Escuela Técnica Superior de Ingeniería Informática
Master universitario en informática pluridisciplinar
Trabajo Fin de Master SOA – IOP: dos caras de
la misma moneda
Autor: José Román Fernández Engo
Director/es: Dr. Miguel Ángel Sicilia Urban
TRIBUNAL:
Presidente:
Vocal 1º:
Vocal 2º:
CALIFICACIÓN.............................................. FECHA:
TFM: SOA – IOP: dos caras de la misma moneda
TFM: SOA – IOP: dos caras de la misma moneda
A mi mujer, Susana, y a mi hija, Clara,
sin cuyo apoyo y sacrificio jamás hubiese
podido concluir este trabajo.
TFM: SOA – IOP: dos caras de la misma moneda
TFM: SOA – IOP: dos caras de la misma moneda
AGRADECIMIENTOS
En primer lugar, agradecer tanto a mi Director de Proyecto, Miguel Ángel, como al coordinador de los
trabajos Fin de Master, Salvador, el apoyo y la paciencia que han mostrado con este alumno tan sui
generis. Este agradecimiento es extensivo a todos y cada uno de los profesores que he tenido la suerte de
conocer durante el transcurso de estos dos años y de los cuales me llevo un grato recuerdo y una
excelente formación.
Agradecer profundamente tanto a todos los compañeros de la Subdirección de Tecnologías de la
Información del Servicio Andaluz de Salud, especialmente a Ana Ceballos – Subdirectora ‐ y Adolfo García
–Jefe de Servicio ‐ , como al Secretario General, Jesús Huertas, la oportunidad que me dieron hace ya dos
años de participar con ellos en un proyecto tan apasionante como es la definición y puesta en marcha de
una estrategia de Interoperabilidad en un entorno tan complejo como el Servicio Sanitario Público de
Andalucía.
A la Fundación Iavante, por haberme introducido en el mundo de la Informática Sanitaria, un especial
compendio de innovación, obsolescencia, complejidad funcional, etc. que lo hacen a un tiempo complejo
e irresistible para una mente inquieta.
Por último, y no por ello menos importantes, a mis padres y familia sin cuyo apoyo y fomento de mis
inquietudes habría constreñido mi impaciencia por aprender en una simple carrera.
TFM: SOA – IOP: dos caras de la misma moneda
TFM: SOA – IOP: dos caras de la misma moneda Pág. 1
INDICE GENERAL
Pág.
DEDICATORIA ............................................................................................................................ ii
AGRADECIMIENTOS
INDICE DE TABLAS .................................................................................................................... 3
INDICE DE FIGURAS .................................................................................................................. 5
RESUMEN ................................................................................................................................. 7
ABSTRACT ................................................................................................................................. 8
1. Conceptos ...................................................................................................................... 9
SOA ........................................................................................................................... 9
La Gobernanza ............................................................................................................. 14
SOA en el ámbito de la salud ....................................................................................... 14
Interoperabilidad ......................................................................................................... 15
2. Sistemas de información en entorno sanitario: hoy día .............................................. 18
Problemas Organizacionales ........................................................................................ 19
Problemas en tratamiento de la información ............................................................. 24
Problemas en tecnología ............................................................................................. 26
Problemas en volumen ................................................................................................ 27
3. SOA ‐ interoperabilidad: binomio autodefinido ......................................................... 29
Cómo se relacionan ..................................................................................................... 29
Cómo SOA conduce a la Interoperabilidad ......................................................... 30
Cómo la Interoperabilidad define SOA ............................................................... 31
Hoja de Ruta para la implementación ......................................................................... 33
Impacto del modelo de implementación en el sistema .............................................. 36
4. caso práctico: el sistema andaluz de salud .................................................................. 38
El S.A.S.......................................................................................................................... 38
TFM: SOA – IOP: dos caras de la misma moneda Pág. 2
Datos de referencia ............................................................................................ 39
Datos de uso ....................................................................................................... 40
Historia ........................................................................................................ 42
Situación en Septiembre de 2.009 ..................................................................... 44
El proyecto ................................................................................................................... 45
Objetivos ........................................................................................................ 45
Modelo adoptado ............................................................................................... 46
Arquitectura adoptada ................................................................................................ 47
Metodología de trabajo ............................................................................................... 49
Documentación ............................................................................................................ 51
Proyectos embrión ....................................................................................................... 53
Diraya Atención Especializada (DAE) .................................................................. 54
Módulo de Pruebas Analíticas (MPA) ................................................................. 56
Hitos alcanzados .......................................................................................................... 56
APLICABILIDAD A OTROS ÁMBITOS DE NEGOCIO .................................................................. 59
BibliograFÍA ............................................................................................................................ 60
A N E X O S .............................................................................................................................. 63
Anexo A: GLOSARIO ............................................................................................................... 64
ANEXO B: ANTEPROYECTO ..................................................................................................... 68
TFM: SOA – IOP: dos caras de la misma moneda Pág. 3
INDICE DE TABLAS Tabla 1‐1: diferencias entre SOA y Web Services ......................................................................................... 14
Tabla 1‐2 Niveles de Interoperabilidad (Grupo de Interoperabilidad. Living Lab Salud Andalucía., 2.009) . 16
Tabla 3‐1 Relación entre los niveles de IOP y las tareas de implantación SOA ............................................ 30
TFM: SOA – IOP: dos caras de la misma moneda Pág. 4
TFM: SOA – IOP: dos caras de la misma moneda Pág. 5
INDICE DE FIGURAS
Ilustración 1‐1: Granulación en la derivación del proceso al servicio (STI, 2011) ......................................... 11
Ilustración 1‐2: ejemplo de definición de flujo en función de las etapas de la Ilustración anterior. (STI,
2011) ............................................................................................................................................................. 12
Ilustración 1‐3: apilamiento de casos de uso sobre la granulación de los procesos (STI, 2011) .................. 13
Ilustración 2‐1: Estructura de dirección de una empresa de éxito (Inditex). Como puede comprobarse, las
TI están presentes en la toma de decisiones estratégicas de la misma. ...................................................... 20
Ilustración 2‐2: Inversión media en IT en la Unión Europea por ámbito de negocio. .................................. 21
Ilustración 2‐3: Gasto medio por empleado IT en la UE por ámbito de negocio. ......................................... 22
Ilustración 2‐4: Interoperabilidad en el SNS (Ministerio de Sanidad, Política Social e Igualdad) ................. 23
Ilustración 2‐5 países pertenecientes al proyecto epSOS ............................................................................. 24
Ilustración 2‐6 Estado de las aplicaciones (STI, 2011)©STI‐SAS ................................................................... 25
Ilustración 2‐7 Diversas informaciones que reflejan los problemas de los sistemas actuales ..................... 26
Ilustración 3‐1: solapamiento SOA ‐ IOP ....................................................................................................... 32
Ilustración 3‐2: modelos de relación Servicios – Tecnología. Ciclo de vida y Gestión del Cambio. .............. 34
Ilustración 4‐1: Estructura organizacional del S.A.S. (SAS, Servicio Andaluz de Salud, 2011) ...................... 39
Ilustración 4‐2: presupuesto del S.A.S. para el año 2011 (SAS, Servicio Andaluz de Salud, 2011) ............... 40
Ilustración 4‐3: Evolución de Receta XXI – Prescripción electrónica en el S.A.S. (SAS, Servicio Andaluz de
Salud, 2011)................................................................................................................................................... 41
Ilustración 4‐4 Segmentación de la citación vía Web en el S.A.S. (SAS, Servicio Andaluz de Salud, 2011) .. 42
Ilustración 4‐5: esquema original del Proyecto Diraya (SAS) ........................................................................ 44
Ilustración 4‐6: modelo SOA adoptado (Fernández‐Engo, 2011)©STI‐SAS .................................................. 47
Ilustración 4‐7: arquitectura lógica adoptada (Fernández‐Engo, 2011)©STI‐SAS ........................................ 48
Ilustración 4‐8: arquitectura física adoptada (STI‐SAS, 2011) ....................................................................... 49
Ilustración 4‐9: metodología SOA adoptada (STI, 2011) ............................................................................... 50
Ilustración 4‐10: situación inicial (STI, 2011) ................................................................................................ 50
Ilustración 4‐11: desacoplamiento (STI, 2011) ............................................................................................. 51
Ilustración 4‐12: extracto de las normas de desarrollo (STI, 2011) .............................................................. 53
Ilustración 4‐13: modelo inicial de D.A.E. ..................................................................................................... 55
Ilustración 4‐14: Modelo actual de DAE basado en SOA .............................................................................. 55
Ilustración 4‐15: modelado de procesos global (STI, 2011) .......................................................................... 57
TFM: SOA – IOP: dos caras de la misma moneda Pág. 6
TFM: SOA – IOP: dos caras de la misma moneda Pág. 7
RESUMEN
Tanto el paradigma de negocio basado en la Orientación a Servicios (SOA) como la Interoperabilidad, en
todos sus niveles, son conceptos muy en boga hoy en día en el mundo de los sistemas de información en
Salud. Hay infinidad de literatura sobre ambos, herramientas, experiencias puntuales, etc. Sin embargo,
el nivel de desarrollo que presentan en este ámbito es muy escaso. No existen apenas proyectos en
producción orientados a servicio en entornos de sistemas públicos prestatarios de servicios de salud y la
interoperabilidad sigue siendo la asignatura pendiente en el mundo de la información sanitaria a pesar
del esfuerzo invertido en su consecución.
El presente trabajo, basado en la experiencia del autor en el Servicio Andaluz de Salud, intenta reflejar la
estrecha relación existente entre ambos paradigmas. Como, necesariamente, el desarrollo consecuente
de un entorno de información basado en servicios, incluyendo la necesaria gobernanza, conlleva la
consecución de la interoperabilidad en el sistema a todos sus niveles así como los procedimientos
generales que se llevan a cabo para lograr la interoperabilidad derivan necesariamente en la existencia de
servicios de negocio en el medio.
Como reflejo de esto se presenta el estudio, a alto nivel, tanto de la situación actual como de los procesos
puestos en marcha por la Subdirección de Tecnologías de la Información del SAS tomando como base el
paradigma SOA, procesos que han llevado a hitos de gestión de la información en este entorno
impensables hace unos años.
Lasabiduríasupremaestenersueñosbastantegrandesparanoperderlosdevista
mientrassepersiguen(WilliamFaulkner)
Palabras Clave: SOA, interoperabilidad, gobernanza, ESB, servicios, SAS
TFM: SOA – IOP: dos caras de la misma moneda Pág. 8
ABSTRACT
Service Oriented Architecture (SOA) as well Interoperability are concepts in vogue now a day in the world
of healthcare information management. There are a lot of studies, articles, tools and single experiences
about them but the level of deployment and consolidation is really poor. There are no complete SOA
projects in Public Healthcare and Interoperability is yet an unreachable topic even thought the great
efforts realized during the last five years.
This work, based on my own experience in the Andalusian Public Healthcare Ministry (APHM), tries to
show the relationships between both concepts. In one way, a solid deploy of an information
environment based on SOA, including the necessary Governance, achieving interoperability in all levels.
And in the other way, the tools usually used to achieve interoperability imply the existence of certain
specific services from the point of view of the business.
As an example, I present the study, at high level, of the actual situation of the Information Systems in the
APHM as well as the process running today based in SOA and the goals achieved in the management of its
information, unimaginable just two years ago.
Thehighest wisdomisto have dreamsbig enough tokeep track of themwhile
chasing(WilliamFaulkner)
Keywords: Interoperability, SOA, process, business, healthcare, legacy systems
TFM: SOA – IOP: dos caras de la misma moneda Pág. 9
1. CONCEPTOS
Aunque, en principio, no debería ser necesaria una introducción conceptual sobre las referencias básicas
de SOA e Interoperabilidad he considerado conveniente un breve repaso de ambos conceptos. El motivo
principal es que ambos están de moda y, como suele ocurrir generalmente en estos casos, podemos
encontrar todo tipo de interpretaciones desvirtuadas que van desde visiones circunscritas a la tecnología
que pueden confundir SOA con SOAP a visiones excesivamente teóricas y despegadas de la realidad que
dejan de tener en cuenta que la automatización a nivel tecnológico es un requisito “sine qua non” de la
interoperabilidad a cualquier nivel. .
SOA
Acrónimo de Service Oriented Arquitecture, SOA es un modelo de negocio, no tecnológico, basado en el
conocimiento profundo de los procesos y flujos de información de la organización, sea esta del tipo que
sea, el modelado de los mismos y la definición, implementación y gobernanza de los servicios que
gestionan estos procesos, alineando las necesidades estratégicas (objetivos) y funcionales de la
organización con los objetivos y requerimientos en la implementación y gestión de estos servicios y, en
última instancia, con las capacidades de las distintas áreas.
SOA es una estrategia, una forma de ver la organización que debe orientar la actividad de todos los
sectores y ámbitos, tanto verticales como horizontales, que soportan la actividad de la organización.
Como logros importantes de la aplicación de una estrategia SOA podemos resaltar:
• Desacoplamiento del negocio de la tecnología: una implementación exitosa de SOA debe
conllevar la independización de los procesos de negocio de la tecnología subyacente, evitando
que esta limite el crecimiento funcional u obstruya su evolución por condiciones de limitación de
capacidad u obsolescencia.
• Garantiza la permanencia del conocimiento de la organización en la organización: la organización
debe conocerse en profundidad y mantener este conocimiento de sus procesos, objetivos,
condiciones, evolución, recursos, etc. en la misma tanto a nivel estratégico, de toda la
organización, como táctico, área por área. Esto no significa que no se externalicen determinados
procesos o la implementación tecnológica de los mismos, o su estudio original, pero siempre
debe revertir este conocimiento en personal de la organización y, por supuesto, en sus
repositorios de información corporativa desde el nivel más alto al de más bajo detalle, es decir,
desde un modelado de primer nivel con actores de perfil humano‐directivo a nivel más bajo de
detalle con descripción completa de la tecnología a implementar, identificación de la información
necesaria en los datos de las aplicaciones, etc.
TFM: SOA – IOP: dos caras de la misma moneda Pág. 10
• Definir el gobierno tanto del negocio como de las implementaciones tecnológicas usadas, es
decir, cómo se llevan a cabo las acciones dentro de la organización, quién puede hacerlo, quién lo
autoriza, quién es el responsable, que tipo de tecnología se usa, qué información se intercambia
en qué ámbito, cuáles son los datos maestros de la organización, etc. estableciendo el uso de
estándares y normas, políticas y procedimientos, tanto a nivel tecnológico como de gestión de la
información de forma que se protocolice el modelado de los procesos, su concreción documental,
formas de intercambio de información tanto a nivel interno como externo, etc.
• Establecer un modelo subsecuente tecnológico basado en el uso del concepto Enterprise Service
Bus, entendiendo este no como una herramienta tecnológica meramente sino como la capa de
gestión de los servicios de negocio de la organización cuenten o no con una implementación
tecnológica, garantizando la integración de los sistemas tanto internos como externos en base al
uso de dicho servicios, la modelización estandarizada, completa y compartida de los flujos y
procesos de la organización orquestados en base a los servicios definidos y la gobernanza de
dichos modelos en todos sus niveles de actuación.
• Garantizar la escalabilidad y sostenibilidad del negocio habilitando los mecanismos que permitan
tanto el crecimiento horizontal (en volumen de actividad, usuarios, etc.) como vertical (aumento
de funcionalidades) de forma ordenada y previsible.
De todo lo expuesto anteriormente extraemos dos conceptos fundamentales para dejar claros
• Proceso: según el diccionario de la R.A.E. un proceso de negocio es un conjunto de tareas
relacionadas de forma lógica, llevadas a cabo para lograr un resultado de negocio definido. Cada
proceso de negocio tiene sus entradas, funciones y salidas. A esto, desde un prisma SOA,
podemos añadir ciertos condicionantes:
o Debe modelarse en base a un lenguaje estandarizado de fácil comprensión e
interpretación y, por supuesto, con fácil traslación tecnológica.
o Su análisis debe facilitar la identificación y/o definición de los servicios de negocio.
o Debe ser consecuencia inmediata del conocimiento de los funcionales expertos en el
negocio de la organización.
o Debe reflejar de forma completa actores, responsabilidades, unidades de información,
flujo de la información, casos de uso, etc.
o Debe presentar varios niveles de abstracción de forma que se refleje desde el proceso a
alto nivel hasta el nivel de tarea a identificar con servicios de negocio únicos.
TFMM: SOA – IO
Ilustr
OP: dos cara
ración 1‐1: G
as de la mism
Granulación
ma moneda
n en la deriv
a
vación del pproceso al se
ervicio (STI,
Pág.
2011)
11
TFM
•
M: SOA – IO
Ilustració
Servicio d
secuencia
o sin
o Pu
de
co
o Ca
la
o Se
or
Si
OP: dos cara
n 1‐2: ejem
de negocio:
de actividad
n estado, aut
uede actuar
evolviendo u
onsumidor lla
ada servicio
multiplicida
e orquestan
rquestación s
un proceso e
as de la mism
mplo de defin
es una fun
des que cump
tocontenida,
como prove
na respuest
amando a ot
refleja una s
d.
en función
secuencia lo
es una prote
ma moneda
nición de flu
anterior.
nción, enten
ple las siguie
, no depende
eedor permit
a con el res
tro servicio p
sola tarea y
n del mode
os servicios y
eína, un serv
a
ujo en funció
(STI, 2011)
ndida esta c
entes caracte
e de la condi
tiendo llama
ultado de la
para obtener
es reutilizad
elado de lo
y provee la ló
icio es un am
ón de las et
como un co
erísticas:
ición de otro
das para la r
s acciones (t
una respues
o las veces q
os procesos
ógica adicion
minoácido.
tapas de la
onjunto de
o servicio.
recepción de
tarea) ejecut
sta (consumi
que sea nec
s y flujos d
nal para pro
Pág.
Ilustración
operacione
e informació
tadas y/o co
idor).
esario evitan
de negocio.
cesar los dat
12
s o
ón y
omo
ndo
La
tos.
TFM
Ilus
Dada
tecnol
el aná
comun
de des
tecnol
servici
arquite
M: SOA – IO
stración 1‐3
la coinciden
ogía de Serv
álisis de un
nicación den
sarrollo cua
ogía. Por ta
ios web fa
ecturas de in
Plataform
Protocolo
Su desarro
Influencia
OP: dos cara
3: apilamien
ncia históric
vicios Web d
servicio de
tro de la ap
ndo quieren
nto no prop
cilita en d
nformación.
a tecnológic
de transpor
ollo se basa e
directa en lo
as de la mism
nto de casos
ca del inicio
demasiado a
negocio con
licación. Este
n abordar es
pugna el uso
eterminadas
a
rte
en el negocio
os flujos y m
ma moneda
s de uso sob
o de las im
menudo, ca
n el uso de
e es uno de
ste tipo de
o de ningun
s circunstan
o
modelos de ne
a
bre la granu
plementacio
asi diríamos
un servicio
los principa
proyecto. A
a en concre
ncias la im
egocio
ulación de lo
ones SOA co
que de form
web o de
les errores c
Axiomáticam
to aunque e
plementació
SO
N
N
Sí
Sí
os procesos
on la difusi
ma sistemátic
métodos de
cometidos po
mente SOA s
es cierto qu
ón tecnológ
OA Web S
No Sí
No Sí
í No
í No
Pág.
s (STI, 2011)
ón del uso
ca, se confun
efinidos para
or las empre
e desliga de
e el uso de
gica de cier
ervices
13
)
de
nde
a la
esas
e la
los
rtas
TFM: SOA – IOP: dos caras de la misma moneda Pág. 14
Es un facilitador del cambio en el negocio y su soporte tecnológico Sí Sí
Es un estándar de la industria No Sí
Tabla 1‐1: diferencias entre SOA y Web Services
La Gobernanza
Cabe mencionarla de forma independiente dada la importancia que tiene su correcta comprensión y
aplicación en el establecimiento de un proyecto SOA. Generalmente, se entiende la gobernanza SOA
como una parte integrante de la gobernanza tecnológica. Sin embargo, desde nuestro punto de vista la
Gobernanza SOA debe presentar una capa más de abstracción que permita la gobernanza de la
información gestionada en la organización. No sólo se trata de la optimización del uso de la tecnología, ni
siquiera de la optimización del uso de los servicios para garantizar la no presencia de multiplicidades sino
que debe incluirse la optimización de la gestión en la propia información. Esto hace necesarias tanto
actuaciones a nivel organizativo como a nivel tecnológico. Si estas acciones no se toman de forma eficaz y
se referencian en una sola entidad nos podemos encontrar que:
• Sin una acción a nivel organizativo, la implementación se convierte en ingobernable y desemboca
en una falta real de orientación a servicios, volviendo generalmente a la situación de partida tras
la realización de fuertes inversiones.
• Sin una acción a nivel de arquitectura tecnológica, la implementación se queda en el papel y los
servicios no se llegan a implementar o son altamente ineficaces con el consiguiente rechazo por
parte de los usuarios y la generación de un obstáculo de gran magnitud en la consecución de los
objetivos de la organización.
SOA en el ámbito de la salud
La aplicación del paradigma SOA en organizaciones dedicadas a los Servicios de Salud se distingue por una
serie de peculiaridades que la diferencian de otros terrenos con información menos dinámica,
semánticamente hablando, y que han retrasado y/o complicado su aplicación hasta hace muy poco
tiempo. Estas peculiaridades han sido reforzadas en este efecto retraso por determinados problemas
específicos del entendimiento de la gestión de la información en España que veremos en la sección
correspondiente. Dichas peculiaridades pueden resumirse en los siguientes puntos:
• Los sistemas heredados son el núcleo tecnológico del negocio en el momento de iniciar una
estrategia SOA. Nos encontraremos en situaciones en las que su evolución resultará inviable o
poco rentable y, sin embargo, no estemos en condiciones de sustituir funcionalmente dichos
TFM: SOA – IOP: dos caras de la misma moneda Pág. 15
sistemas. Esto quiere decir que debe plantearse la evolución de los mismos garantizando, por
supuesto, la continuidad funcional y desacoplando dichas aplicaciones del cuerpo general para
poder ir sustituyéndolas de forma adecuada.
• Ningún proveedor es el mejor en todos los campos. Aunque haya normas establecidas en los
distintos ámbitos siempre será necesaria la integración con sistemas o plataformas no previstas.
Por supuesto, los proveedores tenderán a la presentación de aplicaciones monolíticas con
tendencia a la apropiación de la información organizacional.
• El entorno del negocio de la salud tanto a nivel clínico como administrativo cambia
continuamente y se requiere un marco tanto de gestión de la información como tecnológico, que
permita reaccionar rápidamente manteniendo la calidad y consistencia de la información clínica.
• Falta de perfiles específicos que combinen el conocimiento de la información clínica con el de
gestión de la información y la tecnología. Por desgracia, la tendencia habitual en las distintas
organizaciones suele ser la formación “express” de profesionales médicos en determinados
campos de la informática a nivel tecnológico, la inmersión de profesionales informáticos en
entornos clínicos, etc. ligando puro negocio con pura tecnología. Esto, que evidentemente va en
contra del principio SOA de independencia del negocio respecto a la tecnología, dificulta además
la entrada en juego de perfiles expertos en procesos y arquitecturas tecnológicas, con formación
de alto nivel en análisis y abstracción, que cuentan con una capacidad real de implementar una
capa de independización intermedia. Esta necesidad es especialmente imperiosa en
organizaciones de gran volumen puesto que la mera gestión de las ingentes cantidades de
información manejadas suponen un grave problema ya para informáticos expertos, ni que decir
tiene para médicos con visión ingenieril limitada, y el gran número de enfoques funcionales
resulta igualmente un problema para los responsable funcionales de la organización, obviamente
mucho mayor para los informáticos de desarrollo.
Interoperabilidad
En el caso de la interoperabilidad nos encontramos con dos ámbitos de influencia especialmente
diferenciados y muy mal comunicados entre sí que enfocan, por regla general, el concepto de forma muy
distinta. Las empresas de desarrollo y el ámbito académico. Y, en medio y sin arrancar casi, las
organizaciones prestatarias.
Por regla general, las empresas tienen una especial tendencia a confundir interoperabilidad con
integración, en el sentido de la definición reflejada más abajo, y las universidades, que tienen un nivel
muy alto de entendimiento y desarrollo de herramientas de información, tienden a equiparar la
capacidad de una organización para alcanzar la interoperabilidad con su capacidad, la de la universidad,
de entenderla sin tener en cuenta generalmente la falta de formación del personal destinado en dichas
TFM: SOA – IOP: dos caras de la misma moneda Pág. 16
organizaciones, la dificultad de migrar los sistemas, el coste real de las intervenciones en estas
organizaciones, etc.
Para asentar los conceptos definimos:
Integración: solución técnica para el intercambio de datos entre dos aplicaciones. Por regla general para
cada integración se genera una solución distinta y su evolución está totalmente ligada a la tecnología.
Interoperabilidad: La interoperabilidad es la condición mediante la cual sistemas heterogéneos pueden
intercambiar procesos o datos, de forma automática y manteniendo el significado en ambos extremos.
Ejemplo: hablar 2 idiomas
Obviamente, el concepto que tenemos en consideración en este trabajo es el segundo. El primero
encarna uno de los grandes retos en la visión presentada: su eliminación.
Nivel de Interop. Temas a tratar Necesidades Horizontales
Políticas de Salud Visión y estrategiaEstructuras, procesos, incentivos Marco legal y socio‐económico sostenible Privacidad y confidencialidad Certificación de sistemas y equipos
Escalabilidad Sostenibilidad
Organizacional Proveedores de servicios
Organizaciones y CulturaProcesos de servicios internos y externos Gestión del cambio Reingeniería de procesos
Semántica Terminología, Clasificación y OntologíasTraducciones Implantación y desarrollo de infraestructuras sostenibles.
Sintáctica Mensajería
Técnica Estándares técnicosConectividad hardware y software Seguridad Interfaz de usuario
Tabla 1‐2 Niveles de Interoperabilidad (Grupo de Interoperabilidad. Living Lab Salud Andalucía.,
2.009)
La disposición en capas presentada en la Tabla 1‐2 evidencia la relación entre ellas a la hora de abordar la
consecución de una interoperabilidad completa. Estas relaciones y la misma definición de los niveles
TFM: SOA – IOP: dos caras de la misma moneda Pág. 17
considerados evidencian que alcanzar la interoperabilidad implica la consecución de la misma en todos
los niveles y estos son interdependientes entre sí.
Es decir, y desde arriba hacia abajo, no es posible establecer políticas interoperables entre organizaciones
si los procesos que definen estas políticas no lo son. Estos procesos no pueden ser interoperables si la
significación de la información que gestionan no lo es, no entenderse. No se puede lograr la
interoperabilidad semántica necesaria para compartir esa información si la forma de estructurarla y
transmitirla no es interoperable y de nada sirve lograr todo lo anterior si la capa de transmisión
tecnológica no logra comunicar ambas organizaciones.
De abajo hacia arriba la dependencia es, quizás, más evidente.
TFM: SOA – IOP: dos caras de la misma moneda Pág. 18
2. SISTEMAS DE INFORMACIÓN EN ENTORNO SANITARIO: HOY DÍA
Desde el punto de vista de las organizaciones prestatarias de servicios de salud públicos, es decir las
consejerías autonómicas y el ministerio de sanidad, los sistemas de información que actualmente dan
soporte a la actividad de las mismas, especialmente en el ámbito clínico, se encuentran en un punto
crítico de su evolución, especialmente, aunque resulte paradójico, en las organizaciones de mayor
tamaño y que comenzaron su aventura digital hace más tiempo.
Estas dificultades que encuentran los sistemas de información (dispongan o no de soporte
computacional) para dar soporte al negocio en el ámbito de la salud pueden enfocarse desde distintos
puntos de vista pero, en general, afectan a todos los niveles de la organización. Básicamente podemos
considerar los siguientes:
‐ Estratégico: son muy pocas las organizaciones que cuentan con un Plan Estratégico para sus
Sistemas de Información. Por consiguiente, se carece de una visión de la actividad de la
organización a nivel de Información, de objetivos definidos a medio y largo plazo, de medición
concreta de los recursos necesarios para alcanzarlos ya sean humanos o tecnológicos, de Planes
de Acción a nivel táctico que permitan cubrir las etapas hacia los objetivos finales, etc.
‐ Tecnológico: normalmente los sistemas adolecen de obsolescencia y falta de capacidad evolutiva,
con graves problemas para adaptarse de forma ágil a las necesidades planteadas por la sociedad
de hoy. Esto se debe en gran parte al crecimiento descoordinado que han tenido la mayoría de
ellos, la falta de planes tecnológicos o estrategias definidas, etc.
‐ De implantación: no existe generalmente un Plan de Implantación procedimentado y
estructurado que permita despliegues coordinados, graduales y bien dirigidos. Así mismo, es
patente la carencia de planes de evaluación del impacto de las implementaciones y la falta de
estrategias definidas a largo plazo para el avance en la cobertura funcional.
‐ Normalización e interoperabilidad: el estado de la normalización y la interoperabilidad es
usualmente pobre, principalmente a nivel organizacional. Habitualmente, las causas hay que
buscarlas en la falta de estrategia definida cuando empezaron a desarrollarse los primeros
sistemas electrónicos aplicados en el campo de la salud y en la falta de aplicación de normas y
estándares a los desarrollos que hoy en día funcionan en la mayoría de centros y organizaciones
prestatarias de servicios de salud. El desarrollo de muchos de los sistemas ha ido abarcando
consecutivamente distintos ámbitos de atención (generalmente primero la Atención Primaria
para ir creciendo a Urgencias, Movilidad, etc.) no siempre atendidos por la misma organización y
casi nunca contando con un modelo de información de base que permitiera un crecimiento de
funcionalidad y ámbito sin tener que definir nuevos modelos de datos.
TFM: SOA – IOP: dos caras de la misma moneda Pág. 19
‐ Modelos de provisión de cuidados: hoy día existen una gran diversidad de modelos de provisión
de cuidados médicos. Sin embargo, en su mayoría, se basan en el modelo tradicional de provisión
de cuidados basados en episodios agudos o de la prevención de estos pero no en el tratamiento
enfocado a problemas y/o episodios crónicos. Esto constituye un problema debido a la evolución
de nuestra sociedad a tener una población de edad avanzada, con pocos episodios agudos, con
un paciente cada vez más capacitado, etc. en el que los episodios crónicos cada vez tienen mayor
relevancia. Así mismo, los métodos de compensación económica existentes (por capitación o
número de pacientes atendidos, por prestación puntual del servicio o por sueldo) también toman
como base el modelo de atención tradicional constituyendo una barrera importante a la hora de
poner en marcha de forma extensiva soluciones de asisting‐living, telemedicina, telediagnóstico,
etc. o, simplemente, de modelar los sistemas de provisión y compensación en base a variables
definidas y coherentes.
‐ Evaluación de servicios y tratamiento de información: a día de hoy los sistemas de e‐health
adolecen de la falta de estudios que aporten información sólida el valor de su aplicación (medida
de eficacia, coste‐eficacia, eficiencia,…). Esto se debe principalmente a que los estudios y pilotos
llevados a cabo, a pesar de ser numerosos y avalados por la UE, no cuentan en su mayoría con un
análisis independiente. La mayoría se basan en la aportación de los propios responsables, tanto
técnicos como políticos, de la implantación y mantenimiento de esos sistemas por lo que
difícilmente los resultados llegan a ser fiables.
El análisis desde los anteriores enfoques revela la existencia de una serie de problemas semi‐endémicos
que han provocado o han sido provocados por esta evolución pero que, hoy día, condicionan el avance de
los sistemas y de las organizaciones de forma muy importante siendo su resolución una necesidad
prioritaria para continuar avanzando en condiciones de prestar un adecuado servicio. Estos problemas se
pueden dividir en cuatro bloques independientes:
Problemas Organizacionales
Son problemas propios de las organizaciones responsables de la prestación de los servicios y de su
capacidad de planificación y ejecución tanto táctica como estratégica. Podemos resumirlos en:
• Falta de visión TI, es decir, tecnología e INFORMACION: Sigue siendo un problema endémico
confundir la “informática” con el tratamiento de la información. Las divisiones encargadas de la TI
son tratadas como meras responsables de los sistemas informáticos, mantenimiento de CPDs,
abastecimiento de máquinas, comunicaciones, desarrollo de aplicaciones, etc. pero en muy pocos
casos cuentan ni con la consideración necesaria como gestores de información (modelado,
optimización, etc.) ni como parte estratégica en el desarrollo de la organización.
TFM
•
c
•
M: SOA – IO
Falta de c
cuentan co
conocimie
ejemplo) y
experienci
ser compl
costumbre
tendencia
Ilustración
comprobars
Generalme
influencia
dotación d
TI de las o
para contr
la informá
OP: dos cara
conocimiento
on escaso nú
nto con mu
y no con e
a es complic
eja cuando
e en el trato
a confundir
2‐1: Estruct
se, las TI est
ente los sist
derivada de
de profesiona
organizacione
ratar en núm
tica o el trat
as de la mism
o del negoc
úmero de ex
uchos años
l estudio sis
cada. Por ot
se trata de
con estos p
la funcionali
tura de dire
tán present
temas están
e lo expues
ales, tanto e
es que encue
mero suficien
tamiento de
ma moneda
cio: derivada
xpertos funci
de experie
stemático d
ro lado, la c
e modelar la
profesionales
idad con la a
ección de un
tes en la tom
mal dotado
sto en los d
en número co
entran grand
nte profesion
la informaci
a
a en gran m
ionales y, los
encia en en
el entorno
cooperación
a informació
s, la habitual
arquitectura
na empresa
ma de decis
os de profes
dos puntos
omo en form
des dificultad
nales de alto
ón como un
medida de la
s que lo son,
tornos dete
con lo que
con los grup
ón que man
endogamia
tecnológica,
de éxito (In
iones estrat
sionales de
anteriores s
mación y/o ex
des tanto ec
o nivel. De he
a parte del s
a anterior, la
, suelen hab
erminados (
la generali
pos funciona
nejan debido
en los ento
, etc.
nditex). Com
tégicas de l
la informaci
suele llevar
xperiencia, d
onómicas co
echo se sigu
soporte adm
Pág.
as divisiones
ber adquirido
hospitales,
zación de e
ales puros su
o a su falta
rnos clínicos
mo puede
a misma.
ión. La falta
a la deficie
de las divisio
omo jerárqui
e consideran
inistrativo d
20
s TI
o su
por
esta
uele
de
s, la
de
ente
nes
icas
ndo
e la
TFM
M: SOA – IO
organizaci
esto tiene
Ilustració
OP: dos cara
ón y no com
un reflejo di
ón 2‐2: Inve
as de la mism
mo una parte
irecto en sus
rsión media
ma moneda
e estratégica
s dotaciones
a en IT en la
a
en el funcio
.
a Unión Euro
onamiento y
opea por ám
y crecimiento
mbito de ne
Pág.
o de la mism
egocio.
21
ma y
TFM
•
•
•
M: SOA – IO
Ilustrac
Evolución
directivos
organigram
impidiendo
alcance co
y otro me
que puede
Falta de ca
capacidad
limitada y
Existen do
o El
o El
Esta dicot
estancami
ejemplo cl
y los datos
OP: dos cara
ción 2‐3: Ga
condicionad
desde el niv
mas operativ
o la consolid
on objetivos
dio de desp
en llegar a im
apacidad de
de decisión
está muy co
s clientes en
profesional:
ciudadano: s
tomía y lo
ento en el t
laro es la ine
s que en ella
as de la mism
asto medio p
da por la po
vel intermed
vos se ven
dación tanto
claros. El cic
edida, hacen
mpedir su des
decisión en
n en las orga
ndicionada p
n la cadena d
ven a las TI
se debe cum
reflejado e
ratamiento
ercia del cole
a residen, pa
ma moneda
por emplea
olítica: al se
io cargos de
gravemente
de equipos
clo de cuatro
n que los gr
spliegue.
n las organiz
anizaciones
por el temor
de valor:
como sus te
mplir como em
en el punto
de la inform
ectivo médic
ra usar en su
a
ado IT en la
r organizacio
e adjudicació
e influidos p
humanos co
o años máxim
randes proye
aciones: com
por parte de
r a la confron
ecnólogos.
mpleados pú
o anterior l
mación para e
co a consider
us investigac
UE por ámb
ones de ám
n tanto los o
por la direcc
ompetitivos c
mo, incluyend
ectos sufran
mo consecue
e los mando
ntación con l
úblicos.
leva a situ
evitar colisió
rar como pro
ciones, por e
bito de nego
mbito político
objetivos glo
ción política
como de pro
do medio d
vaivenes m
encia de tod
os tecnológic
os profesion
uaciones de
ón entre am
opia la histo
ejemplo, y la
Pág.
ocio.
o y los pues
obales como
a del mome
oyectos de la
e asentamie
uy importan
do lo anterio
cos es basta
nales.
indefinición
bas facetas.
ria del pacie
s leyes vigen
22
stos
los
nto
argo
nto
ntes
or la
ante
n y
Un
ente
ntes
TFM
•
Ilus
M: SOA – IO
que garan
acceso a lo
Estamos e
avanzando
superiores
o Lo
o Pr
stración 2‐4
OP: dos cara
ntizan al pac
os mismos a
en el mundo
o y las auto
s como, por e
os proyectos
royectos euro
: Interopera
as de la mism
ciente la tot
los clínicos q
y este se m
nomías deb
ejemplo:
del Minister
opeos de Int
abilidad en
ma moneda
tal confidenc
que decida.
mueve. Adem
ben respond
rio a nivel na
teroperabilid
el SNS (Min
a
cialidad de
más de lo ex
er a los req
cional: Histo
dad como el e
nisterio de S
sus datos y
puesto ante
querimientos
oria Única Dig
epSOS
Sanidad, Pol
la posibilid
eriormente, e
s planteados
gital o Recet
lítica Social
Pág.
ad de nega
el mundo sig
s desde nive
ta electrónica
e Igualdad)
23
r el
gue
eles
a
d)
TFM
Proble
Los pr
tecnol
común
organi
inform
•
•
M: SOA – IO
Ilustr
emas en trat
roblemas aq
ógica aunqu
n de casi tod
ización en la
mación gestio
Los sistem
document
suele ser,
referencia
como cons
Subsistem
los flujos d
negocio sin
agregación
que es des
inviable la
OP: dos cara
ración 2‐5 p
tamiento de
quí reflejado
ue, por regla
dos ellos es
que se care
onada en cad
mas no co
ación ni difu
especialmen
n estos dato
secuencia la
as fuerteme
de la organiz
no desde la c
n de funcion
spués sumam
continuidad
as de la mism
países perte
la informaci
os tienen u
general, la s
la falta de d
ece, habitual
da uno de los
omparten d
usión de los
nte en organ
os según el
incoherencia
nte acoplado
zación conlle
conveniencia
nalidades de
mente costos
d de esta agre
ma moneda
enecientes a
ión
una compon
segunda es c
efinición, es
mente, de v
s ámbitos y s
atos maest
s datos cons
izaciones gra
criterio del
a estructura
os (dependie
eva que los
a de la empr
distintos es
so de modu
egación.
a
al proyecto e
nente tanto
consecuencia
structuración
visión global
su impacto e
tros. No e
siderados ma
andes, que c
funcional al
l en la semán
entes). La fa
desarrollos
resa desarro
spacios del n
larizar cuand
epSOS (Euro
de gestión
a directa de
n, gestión y u
o conciencia
n el resto.
xiste en la
aestros por
cada vez que
cargo en es
ntica de la or
lta de mode
evolucionen
lladora. Gen
negocio en u
do la evoluci
opean Unio
n de la info
la primera d
uso de la inf
a de la trans
a organizac
la misma. L
e se empieza
se momento
rganización.
elización de l
n no desde la
eralmente e
una sólo unid
ión del prop
Pág.
on)
ormación co
dado que la
formación de
cendencia d
ión definici
a consecuen
un proyecto
o teniendo e
a informació
a necesidad
esto deriva e
dad tecnológ
io negocio h
24
omo
raíz
e la
e la
ión,
ncia
o se
esto
ón y
del
n la
gica
ace
TFM
•
•
•
M: SOA – IO
Escalabilid
en la gesti
en primera
a las unida
desarrollo
real de uso
usuarios) o
Muchos da
haber pro
principales
rápidas o i
parte de la
Necesidad
modelo de
sin un gra
ámbitos at
OP: dos cara
dad no previs
ión de la info
a instancia d
ades de gest
s sean inutil
o en la organ
o incapaces d
atos se com
ocedimientos
s lo que sue
imprevistas,
a organizació
de integra
e datos comú
n esfuerzo d
tendidos por
Ilustración
as de la mism
sta ni vertica
ormación y l
de impacto p
tión de la in
lizables una
nización (por
de hacer cre
parten medi
s de contro
ele conllevar
evoluciones
ón de sus dat
r historias d
ún y de dato
de transform
r aplicacione
n 2‐6 Estado
ma moneda
al ni horizon
la tendencia
pero que no
nformación a
vez termina
r ejemplo po
cer su funcio
iante réplica
l y actualiza
r errores de
s no deseada
tos estructur
de ámbitos
os maestros c
mación y evo
es distintas, o
o de las apli
a
ntalmente. L
política a co
se someten
antes de que
ados dada s
or su ineficien
onalidad con
s no control
ación de las
e coherencia
as de tablas
rales, etc.
contemplad
consolidados
olución de lo
o en ocasione
icaciones (S
a falta de vi
orporativizar
a un análisis
e estén term
u incapacida
ncia en la ge
forme lo dem
adas o, dich
s tablas com
en cuanto
de datos ma
dos de form
s conlleva la
os sistemas,
es con la mis
STI, 2011)©S
isión global y
r ideas que p
s riguroso ni
minadas hace
ad de afront
estión de un
manda el ne
o de otra m
mpartidas po
se realizan
aestros, falta
ma disjunta.
imposibilida
los registro
sma.
STI‐SAS
Pág.
y/o experien
pueden pare
se hacen lle
en que muc
tar el escena
número alto
gocio.
anera, no su
or los sistem
actualizacio
a de control
La carencia
ad de gestion
s generados
25
ncia
ecer
egar
hos
ario
o de
uele
mas
nes
por
de
nar,
s en
TFM
Proble
•
•
•
•
Ilu
M: SOA – IO
emas en tecn
Multitud
negocio ex
existe una
misma org
procedimi
desarrollad
Sistemas
compatibi
problemas
Dependen
Sistemas c
tecnología
falta de pla
soportada
ustración 2‐
OP: dos cara
nología
de entidade
xisten distint
a gobernanz
ganización de
entos distint
do o se está
que han c
lidad entre
s de tiempos
ncia de la pol
con mucha h
as de desarro
anificación e
s, son incom
‐7 Diversas
as de la mism
es desarrolla
tas entidade
a definida d
esarrollan di
tos, visiones
desarrolland
crecido sin
tecnologías
s de desarrol
ítica. Tal y có
historia en c
ollo que en s
en su momen
mpatibles con
informacion
ma moneda
adoras no c
es con capac
de las mism
stintas empr
y finalidade
do en otros á
definición
de desarro
lo e implant
ómo se come
comunidades
su momento
nto de la evo
n los sistema
nes que refl
a
coordinadas.
cidad de des
as ni una vi
resas o divisi
s distintas y
ámbitos den
del proyec
llo, SO, bas
ación, proble
entó en la in
s grandes lo
o fueron de
olución tecno
s actuales, e
lejan los pro
Especialme
arrollo y des
isión genera
iones interna
sin visión en
tro de la mis
cto. Lo que
es de datos
emas con los
troducción.
que provoca
primera líne
ológica del si
etc.
oblemas de
ente cuando
spliegue de
al de la orga
as con tecno
n absoluto de
sma organiza
e conlleva
s, tecnología
s métodos d
a la coexiste
ea pero hoy
istema, está
los sistema
Pág.
o en el mis
soluciones y
anización. En
ologías distin
e lo que ya e
ación.
problemas
a de hardwa
e soporte, et
ncia de muc
día, debido a
án obsoletas,
as actuales
26
smo
y no
n la
tas,
está
de
are,
tc.
chas
a la
, de
TFM: SOA – IOP: dos caras de la misma moneda Pág. 27
• Falta de procedimientos y metodologías. En general, tanto de desarrollo como de implantación,
gestión o control de la calidad. Esta falta de procedimiento provoca una enorme ineficiencia,
además, en los procesos de rotación del personal encargado de llevar a cabo las tareas dado que
el personal nuevo tarda muchísimo más en aprender lo que debe y cómo lo debe hacer, se pierde
conocimiento, etc.
• Organizaciones con sistemas no interoperables entre sí internamente. Aplicaciones que atienden
a ámbitos distintos pero que son incapaces de intercambiar información cuando estos ámbitos se
relacionan en la actividad del negocio.
A consecuencia de las pautas de evolución reflejadas anteriormente nos encontramos con la coexistencia
no prevista y forzada de multitud de tecnologías algunas obsoletas, otras sin soporte, otras
incompatibles,…
Problemas en volumen
En las organizaciones con gran cobertura funcional y poblacional nos encontramos, además, con
problemas específicos del volumen de datos manejado y la falta de previsión en la gestión de los mismos.
• Concurrencia de sistemas no prevista. Sistemas que requieren información de otros sistemas en
cantidades o con periodicidad no prevista lo que provoca caídas en el funcionamiento del sistema
que cede la información.
• Pasos a históricos no contemplados en las aplicaciones ni por los funcionales. La acumulación de
grandes volúmenes de datos no se ha contemplado ni desde el punto de vista tecnológico (paso a
histórico de determinados datos que quedan fuera de uso del operacional a partir de cierta
horquilla de tiempo) ni desde el punto de vista funcional (tiempo de vigencia del resultado de
una prueba de laboratorio, qué se hace con la historia de un deceso, etc.).
• Optimización de consultas por volumen no contempladas en las aplicaciones, consecuencia
evidente de la falta de pautas y buenas prácticas que ha sido la norma hasta hace muy poco
tiempo.
• Evolución de repositorios de datos no prevista. Repositorios que inician su existencia con una
finalidad concreta y, normalmente por conveniencia de desarrollo, terminan dando servicio de
forma muy distinta. Por ejemplo, los sistemas actuales de gestión de pacientes en varias
comunidades tienen su origen en los sistemas de capitación de Atención Primaria. Actualmente
esa forma de crecer los ha llevado a enquistar la evolución de los MPI en estas comunidades.
Todos estos problemas han llevado, en todas las comunidades con cierto recorrido, a caídas de sistemas
catastróficas, levantamiento de médicos, ataques de adversarios políticos de gran virulencia, etc. que
aunque no siempre se corresponden con la realidad si crean un ambiente contrario a la propia evolución
TFM: SOA – IOP: dos caras de la misma moneda Pág. 28
de esos sistemas aun cuando, aunque de forma atropellada, consigan hitos de funcionalidad y cobertura
impensables hace 10 años y que nadie hubiera apostado por ver implantados en la Sanidad Pública.
TFM: SOA – IOP: dos caras de la misma moneda Pág. 29
3. SOA ‐ INTEROPERABILIDAD: BINOMIO AUTODEFINIDO
En esta sección intentaremos establecer cómo la implementación de una estrategia SOA bien definida
deriva en la consecución de la Interoperabilidad, a todos los niveles, tanto a nivel intra‐organizacional
como estableciendo los criterios de interoperabilidad para su relación con entidades externas, así como,
en sentido opuesto, las tareas necesarias para alcanzar la interoperabilidad en sus distintos niveles
pueden identificarse, de forma directa, con una parte de las bases necesarias para el establecimiento de
la gestión SOA en la organización.
Una vez establecida la relación, proponemos una hoja de ruta para el despliegue de la estrategia SOA y,
por ende, la consecución de la interoperabilidad. Elegimos este enfoque, en lugar de usar la dirección
Interoperabilidad – SOA, por varios motivos:
‐ El modelo SOA es un modelo consolidado y que abarca todos los niveles de forma coherente
en tanto que la relación entre los distintos niveles de interoperabilidad está aún mal
estudiada.
‐ Existen casos de éxito en el despliegue de estrategias SOA en tanto que los intentos de
consecución de Interoperabilidad en organizaciones extensas, de momento, han dado malos
resultados.
‐ Las herramientas del modelo SOA y sus métodos de despliegue y uso están bien definidas en
tanto no existen protocolos definidos para la consecución de la interoperabilidad.
‐ La implicación de la dirección de la organización, factor fundamental en ambas empresas, es
bastante más fácil de conseguir explicando un modelo de gestión empresarial que las
virtudes de la consecución de la interoperabilidad.
Cómo se relacionan
En la siguiente tabla establecemos las principales relaciones entre los niveles de interoperabilidad y las
bases de la estrategia SOA cuya consecución conllevaría obtener dichos niveles de IOP.
Nivel IOP SOA
Políticas de salud Adopción de una estrategia de la
organización. Marcos normativos.
Organizacional Definición y modelado de los procesos de la
organización. Definición de los estándares de
modelado. Gobierno y gestión del cambio.
TFM: SOA – IOP: dos caras de la misma moneda Pág. 30
Semántica Definición de los datos maestros de la
organización. Terminologías y ontologías.
Gestión del ciclo de vida de los servicios
Sintáctica Aplicación de normas y estándares en el
desarrollo de mensajería
Técnica Aplicación de normas y estándares
tecnológicos en sistemas.
Tabla 3‐1 Relación entre los niveles de IOP y las tareas de implantación SOA
En definitiva, tanto un proyecto como el otro comparten la misma necesidad de una gobernanza clara,
metodológica y entendida por la organización para garantizar escalabilidad y sostenibilidad.
Cómo SOA conduce a la Interoperabilidad
El despliegue de una estrategia SOA habilita y consolida las condiciones necesarias para lograr la
interoperabilidad tanto interna como externa a todos sus niveles a través de:
• La adopción de una estrategia y una política de información definidas y estables en el tiempo, y el
establecimiento de un modelo de gobernanza que permite la consolidación y difusión tanto de
estas políticas como de las normas, datos maestros, etc. necesarios en los niveles inferiores (IOP
política).
• La definición, modelado y consolidación de los procesos de la organización y la definición y
aplicación de modelo de ciclo de vida sostenible a todos los servicios necesarios ya sean o no
tecnológicos. La aplicación generalizada de normas y estándares para el modelado de procesos y
establecimiento de responsabilidades sobre la información en la organización. El establecimiento
de una oficina de gobernanza (IOP organizacional).
• La puesta en marcha de los servicios que establecen y unifican la interpretación de la información
en la organización. Establecimiento de los patrones de interpretación de la información en la
organización y sus modelos de datos de referencia asociados. Un conocimiento profundo del
negocio, sus necesidades y su evolución derivado del modelado de los procesos (IOP semántica).
• La adopción de una sintaxis de comunicación basada en estándares y común a todos los
sistemas, de obligado cumplimiento y derivada del modelado del negocio (IOP sintáctica).
TFM: SOA – IOP: dos caras de la misma moneda Pág. 31
• El despliegue de una arquitectura física de gestión de la información y comunicaciones, basada en
estándares tecnológicos, que garantiza el intercambio de información a nivel físico (IOP
tecnológica).
Cómo la Interoperabilidad define SOA
Aunque, tal y como ya se ha referenciado, el camino práctico para la consecución de la interoperabilidad
(obviamente por caminos distintos al aquí expuesto) es a día de hoy mucho más nebuloso que el anterior
existen ciertas pautas y/o condicionantes necesarios comunes en esos caminos que derivan en la
facilitación de la estrategia SOA. Algunos de ellos son:
• La necesidad de un modelo de referencia para la gestión de datos que permita la abstracción de
la información de la capa de datos y la relación directa de esta información con recursos
sintácticos y semánticos estandarizados.
• Vocabularios comunes, terminologías y ontologías que reflejen adecuadamente los conceptos del
negocio y las relaciones entre estos.
• Artefactos que relacionan de forma automatizable la información con el modelo de referencia y
conforman una semántica correcta en virtud de los recursos del punto anterior.
• La necesidad de que todo esto sea implementable en un sistema IT capaz de automatizar el
proceso de intercambio de información.
• Fuerza un cambio de modelo de desarrollo que antepone el uso de la información al de los datos
y desliga al experto del negocio de la tecnología.
• Precisa de un conocimiento muy extenso y profundo del negocio.
• Se recurre de forma sistemática a la normalización, estándares, tablas maestras, etc.
TFM
Como
gran m
Facilita
conllev
organi
relacio
extien
Realm
decisió
M: SOA – IO
puede segu
medida, muc
a en conocim
va el uso si
ización, prec
onando dato
da el uso de
ente, el cum
ón de adopta
OP: dos cara
uirse sin dem
has de las n
miento profu
stemático y
cisa de una
os, informac
las termino
mplimiento d
arla.
as de la mism
Ilustración
masiado esfu
ecesidades c
undo de la o
extensivo d
infraestruct
ción y nego
logías, sistem
de estos crite
ma moneda
n 3‐1: solap
uerzo, el cum
concretas de
organización
de normas y
tura tecnoló
ocio, necesit
mas, etc.
erios deja la
a
amiento SO
mplimiento d
el despliegue
n, facilita la s
y estándares
ógica tanto
a de un m
estrategia S
OA ‐ IOP
de los objetiv
e de una estr
separación d
s que deben
a nivel físic
odelo de go
SOA a expen
vos anterior
rategia basa
del negocio
n ser conoci
co como lóg
obernanza q
nsas, casi ún
Pág.
res resuelve,
da en servic
y la tecnolo
idos en toda
gico que op
que gestion
icamente, de
32
, en
cios.
gía,
a la
pere
e y
e la
TFM: SOA – IOP: dos caras de la misma moneda Pág. 33
Hoja de Ruta para la implementación
"Governance is essential, you need a central entity that ensures tight coordination throughout the project and
disciplines the process of design of new services. Governance is needed for security, planned change and
configuration management, testing, monitoring, and setting of quality-of-service requirements." (Thompson,
Gartner Says SOA Is Evolving Beyond Its Traditional Roots, 2009)
Tal y como refleja la cita, la Gobernanza es el punto de apoyo esencial sobre el que pivota el despliegue
de una estrategia SOA. Según Gartner, en organizaciones con un número de servicios definidos por
encima del centenar, la inversión en Gobernanza debe ser de al menos el 50% de lo dispuesto para todo
el proceso. Efectivamente, un proyecto de este tipo es lo suficientemente complejo en su gestión como
para necesitar ese nivel de recursos. Pero, en mi opinión, no sólo es la necesidad de gestión la que
determina ese nivel de inversión. El nivel de análisis y abstracción necesarios para una correcta
implementación de una estrategia de este tipo hace necesario que el personal responsable de su
definición disponga de un alto nivel de formación y, por supuesto, capacidad de análisis y relación con los
funcionales, tiempo para pensar, etc. cosas que, hoy en día, son cualidades y condiciones difíciles de
encontrar y caras de adquirir y, sobre todo, de mantener.
Para poder llevar a cabo la adopción de la estrategia necesitamos establecer una serie de objetivos
estratégicos que deben establecerse como reglas de cabecera desde el momento en que se toma la
decisión de arrancar el proyecto:
• Adoptar un modelo escalable, sostenible y coherente. Y no podemos obviar ninguno de los tres
puntos en ninguno de los niveles en los que vamos a trabajar.
• Convertirnos en expertos en nuestra propia organización. No sólo en especialistas en nuestra
área sino que debemos tener, además de ese conocimiento especializado, otro extenso de qué
hace la organización en cada ámbito, la idiosincrasia de cada espacio de negocio, cómo podemos
establecer relaciones entre ellos, cuáles son necesidades y peculiaridades, etc.
• Establecer marco de normas y estándares, difundirlos y hacerlos cumplir.
• El modelo tecnológico debe permitir una gobernanza tecnológica eficaz, la integración de la
información de los distintos ámbitos, la modelización adecuada de los procesos para poder
automatizarlos en base a la tecnología y la reutilización de todo lo desarrollado de forma eficaz.
• Es primordial la convergencia de los sistemas y de la propia organización al nuevo modelo paso a
paso, proyecto a proyecto en el marco de un macro‐proyecto global que es la propia
organización. Uno de los principales errores cometidos es el establecer un alcance demasiado
ambicioso en el plan de arranque.
• Establecer las responsabilidades sobre la información en todos los ámbitos y sobre cualquier
dato. La organización no debería crecer sin tener el control efectivo de la información que genera
y gestiona.
TFM
Basánd
pasos
•
•
•
Ilust
•
•
•
M: SOA – IO
donos en la
principales a
Adopción
necesidade
decisiones
capacidade
alcance de
Definir mo
definir los
priorizació
Definir mo
tecnológic
aunque el
tración 3‐2:
Modelar e
de uso, ut
los experto
Establecer
Definir dat
OP: dos cara
necesidad fi
a dar para el
efectiva de
es, tiempos
s estratégica
es. Definició
el modelo.
odelo y gobie
grupos fun
ón se van a se
odelo y gobi
ca mantenga
modelo de t
modelos de
el negocio, to
tilización de
os en el nego
r marco de n
tos maestros
as de la mism
inal de cump
establecimie
e la estrate
y objetivos.
as de la or
n de los indi
erno de la re
cionales, có
eguir, etc.
ierno tecno
a su evoluci
traspaso no p
e relación S
odos sus fluj
datos maest
ocio y tiempo
ormas y está
s de la Organ
ma moneda
plir con esto
ento de la es
egia por la
Participació
rganización
icadores de e
elación del ne
mo se van a
ológico, de f
ón y capaci
progrese al m
Servicios – T
os, procesos
tros, etc. Re
o.
ándares, polí
nización y las
a
os objetivos,
strategia, a a
organizació
ón de tecnol
alineando
evaluación d
egocio con S
a adjudicar
forma indep
dad de ada
mismo tiemp
Tecnología.
s de intercam
equiere un g
íticas de uso
s responsabil
se define la
alto nivel.
ón. Asunció
ogías de la
las necesida
del éxito de la
Sistemas de I
las responsa
endiente, de
ptación a la
po.
Ciclo de vid
mbio de info
ran nivel de
y difusión y
lidades sobre
Hoja de rut
n de la di
información
ades del ne
a estrategia
Información.
abilidades, q
e manera qu
as necesidad
da y Gestión
ormación con
e participació
procedimie
e los mismos
Pág.
a. Estos son
rección de
n en la toma
egocio con
y definición
. Cómo se va
qué criterios
ue la respue
des funciona
n del Cambio
n actores, ca
ón por parte
ntos.
s.
34
los
las
de
las
del
an a
s de
esta
ales
o.
asos
e de
TFM: SOA – IOP: dos caras de la misma moneda Pág. 35
• Convergencia de los sistemas al nuevo modelo, proyecto a proyecto, en el marco de un macro‐
proyecto global, asegurando la coexistencia con lo existente.
Proponemos asimismo un Plan de puesta en marcha que quiere ser el reflejo de un plan ejecutivo de
arranque que facilite el enfoque y la definición concreta de tareas al iniciar un proyecto de este tipo.
• Selección de las personas que van a dirigir la implantación
• Inicio del proceso de modelado del negocio. Es necesario que el personal seleccionado adquiera
conocimiento práctico de las herramientas e inmersión rápida en el negocio.
• Implementación de los modelos lógicos y físicos. Adquisición de infraestructuras y aplicaciones,
despliegue, formación del personal, etc.
• Puesta en marcha “oficial” de la oficina SOA tanto a nivel técnico como estratégico. Difusión de
sus tareas en toda la organización y en sus proveedores, que deben también ser conscientes del
cambio. Entre sus tareas iniciales las principales deben ser, según (Malinverno, Sample
Governance Mechanisms for a Service‐Oriented Architecture, 2006):
o Servicios a desarrollar.
o Priorización del desarrollo.
o Reutilización.
o Quién desarrollo y mantiene el servicio.
o Definir las responsabilidades sobre el servicio.
• Difusión del gobierno del negocio y tecnológico.
o Uso de estándares y normas.
o Procedimientos de desarrollo.
o Procedimientos de relación con la Tecnologías e Información en sus distintos niveles.
• Difusión de los datos maestros de la organización y de sus formas de actualización, adecuándolas
al uso que se haga de los mismos.
• De qué dispone ya la organización y de qué no.
o Funcionalidades existentes no evolucionables y no utilizables por otros sistemas
o Funcionalidades existentes no evolucionables pero utilizables por otros sistemas
o Funcionalidades existentes evolucionables pero utilizables por otros sistemas
o Necesidad de nuevas funcionalidades
• Selección de los proyectos‐piloto tanto para los análisis que parten de cero como para
aplicaciones existentes que empiecen a evolucionar.
• Priorización de los desarrollos y adaptaciones derivados del punto anterior.
• Definición, desarrollo y adecuación de los servicios diseñados y/o existentes en base a los dos
puntos anteriores.
TFM: SOA – IOP: dos caras de la misma moneda Pág. 36
• Establecer un calendario para el desmembramiento de aplicaciones monolíticas. Y arrancarlo,
claro.
Impacto del modelo de implementación en el sistema
Obviamente, el impacto de la implantación de una estrategia de este tipo es muy alto. Tanto positiva
como negativamente en el caso en que no se lleve bien a cabo.
• Impacto en la contratación
o Uniformidad del soporte y de la tecnología y de las prestaciones necesarias de forma que
las contrataciones en la organización pueden asegurar la idoneidad de lo contratado al
tiempo que se facilita el uso del volumen de compra para la mejora de las condiciones.
o Facilidad en el desarrollo de pliegos al contar con referencias documentadas concretas
respecto a lo que debe cumplimentar el adjudicatario del pliego respecto a la gestión de
la información.
o Eleva la dificultad de encontrar personal cualificado al requerir no sólo expertos en el
negocio y expertos en tecnología sino también personal con una elevada capacidad de
análisis y abstracción, amén de formación en procesos.
• Impacto en el desarrollo
o Se cuenta con una sólida documentación de referencia con un gran control en su
evolución y que afecta a todos los proveedores y desarrolladores relacionados con la
organización.
o Soporte unificado, lo que simplifica la formación del personal tanto tecnológico como de
dirección de proyectos, las líneas de relación con las empresas desarrolladoras, etc.
o Simplificación y reutilización de los desarrollos al basarse estos en unidades “atómicas”
desde el punto de vista de la funcionalidad del negocio y no de su configuración
tecnológica.
o Aumento de la complejidad de abstracción de las aplicaciones al quedar fuera de las
formas de trabajo el típico desarrollo a medida y hacer recaer el mayor peso en la
definición y orquestación de los servicios.
o Desacoplamiento entre aplicaciones, permitiendo la evolución independiente de distintos
ámbitos de negocio en función de las necesidades funcionales.
o Garantiza la escalabilidad y la sostenibilidad.
• Impacto en la gestión del conocimiento
o Se interioriza el conocimiento del negocio mejorando el control interno de los proyectos
y revirtiendo el conocimiento en la organización, evitando así dependencia de agentes
externos.
TFM: SOA – IOP: dos caras de la misma moneda Pág. 37
o Se difunde dicho conocimiento.
o Se evitan las incoherencias de datos al contar con modelos de referencia de la
información que deben reflejar esos datos.
o Se complica el diseño básico de la primera capa de conocimiento aunque se agiliza en las
superiores. No siempre se entiende o resulta sencillo de modelar el salto de la capa de
datos a la capa de información usando únicamente esta como referencia.
o Garantiza la interoperabilidad de la organización tanto interna como externa.
En las organizaciones en marcha la hoja de ruta recomendada parte de un enfoque que combina la visión
top – down y la bottom – up tanto en el análisis como en la priorización de actividades puesto que es
inviable eliminar de forma inmediata los sistemas heredados no interoperables y, además, resulta muy
desaconsejable desperdiciar el conocimiento funcional que dio origen en su día a esas aplicaciones.
Aun así, estas aplicaciones deben aislarse cuanto antes mediante servicios – fachada para acometer su
evolución con garantías, sin condicionar el crecimiento del resto del sistema y habilitando, además, la
adhesión de aplicaciones nuevas al modelo de servicios de forma directa.
El impacto del modelo en la organización es extenso e innegable pero deben priorizarse las actuaciones
para consolidar la evolución del mismo, evitando que un crecimiento demasiado rápido haga “morir de
éxito” al proyecto.
TFM: SOA – IOP: dos caras de la misma moneda Pág. 38
4. CASO PRÁCTICO: EL SISTEMA ANDALUZ DE SALUD
El S.A.S.
Tal y como se referencia en el estudio general de los sistemas actuales, uno de los problemas hasta hace
muy poco tiempo ha sido la falta de fiabilidad de los datos reales, confundiéndose muchas veces el deseo
con la realidad.
“Actualmente la Receta Electrónica en Catalunya (Rec@t) está implantada en todo el territorio,
en el ámbito de la atención primaria.” (Generalitat de Catalunya)
“EXTREMADURA: La telemedicina está presente ya en todos los hospitales públicos y en 18
centros de salud de Extremadura.” (Comunidad de Extremadura, 2003)
“Así pues, el modelo de historia clínica permite la consulta y la anotación de datos en todos los
dispositivos y niveles asistenciales: atención primaria, atención especializada, urgencias y
hospitalización.” (Dossier Diraya , 2010)
Este tipo de presentaciones y referencias, muy habituales en los foros de Informática Médica y
medios generales de difusión, que provienen tanto de proveedores como de representantes de
comunidades autónomas, han creado una nube de información muy poco fidedigna en torno a
los sistemas de información en salud. Las diferentes interpretaciones de la realidad,
transformando el registro electrónico de una prescripción en un sistema completo de receta
electrónica, confundiendo la telemedicina con una cámara web o presentando un logro sectorial
por ámbito de negocio como un sistema conjunto, como esta forma de trabajar ha sido
impulsada especialmente desde los puestos políticos, la falta ya comentada de capacidad de
gestión independiente de los responsables de los sistemas de información y el hecho de que los
teóricos estudios independientes de la UE, como los informes ehr‐impact, recogen los datos
directamente de estas fuentes corporativas provocan una situación de desinformación poco
deseable que se caracteriza por:
‐ Ni el público en general, ni los profesionales clínicos ni los políticos conocen el
alcance funcional real de los sistemas e e‐salud en su comunidad. Generalmente, ni
siquiera los técnicos tienen una visión global de qué existe y qué es puro proyecto.
TFM
Por lo
respe
pasos
Inform
Datos
Poblac
Superf
Profes
Person
Ilu
M: SOA – IO
‐ Así m
diseño
frase
‐ Cualq
de la
recurs
o anteriorm
cto al alcan
dados po
mación del S
de referenc
ción: 8,3 M (
ficie: 87.579
sionales: 84.0
nal Subdirecc
ustración 4‐
OP: dos cara
mismo, no s
o, desarroll
de “pues es
uier iniciati
realidad ex
sos.
mente expu
nce necesar
or el proy
Servicio And
cia
17,8% de la
km2
000
ción de Siste
‐1: Estructu
as de la mism
son conscie
o, impleme
sto lo puedo
iva de camb
istente que
esto he cre
rio como a
ecto SOA
daluz de Sa
población Es
emas de la In
ra organiza
ma moneda
entes de la
entación, de
o hacer con
bio en los s
e, muchas v
eído neces
la situació
impulsado
lud.
spañola)
nformación: 7
acional del S
a
dificultad
espliegue y
n Google” es
sistemas pr
eces, consu
ario estable
n actual de
por la S
70 incluyend
S.A.S. (SAS,
tanto técni
soporte de
s un buen e
recisa de un
umirá una g
ecer un ma
e los sistem
ubdirección
do subcontra
Servicio And
ica como e
e estos siste
exponente.
n análisis e
gran cantida
arco de ref
mas antes d
n de Tecn
atados. (Ratio
daluz de Sa
Pág.
económica
emas. La típ
n profundid
ad de tiemp
ferencia ta
e describir
ologías de
o: 0.08%)
alud, 2011)
39
del
pica
dad
po y
nto
los
la
TFM
Nº de
Hospit
Presup
Los da
cuanto
las grá
EU est
están
ámbito
Ilust
Datos
Presen
año. C
andalu
mundo
Datos
Más d
Conec
farmac
M: SOA – IO
centros de s
tales: 29 + 16
puesto S.A.S.
atos anterior
o a la consid
áficas presen
tá en el 4.2%
en el 0.08%
o funcional.
tración 4‐2:
de uso
nto aquí de f
Como puede
uz uno de lo
o.
de Diraya:
e 7,9 millone
tados 1.145
cias.
OP: dos cara
salud: 1.500
6 CHARES
.: 8.600 millo
res confirma
eración de lo
ntadas en el
% y la inversió
y apenas el
: presupues
forma esque
e comproba
s sistemas d
es de historia
5 centros de
as de la mism
ones de Euro
n que el S.A
os servicios d
capítulo 2, e
ón en TIC en
1% respect
to del S.A.S
emática los d
rse, el volum
de informació
as con datos
e atención p
ma moneda
os Presup
A.S. no es un
de informac
en tanto el r
n el mismo e
ivamente. Y
S. para el añ
datos de uso
men y ámbi
ón de soport
s clínicos
primaria (10
a
puesto S.T.I.
a organizació
ión se refier
ratio de pers
en el 3.9% m
aún así des
ño 2011 (SAS
o del proyect
to abarcado
te a program
0% de pobl
: 80 millones
ón diferente
e. Como pue
sonal TIC en
ientras que
arrolla soluc
S, Servicio A
o Diraya a fe
os son muy c
mas de salud
ación), 28 á
s de Euros (r
e, en el ámb
ede comprob
el ámbito d
las cifras de
ciones de pri
Andaluz de S
echa de Ene
considerable
d públicos m
áreas hospit
Pág.
atio: 0.93%)
ito español,
barse revisan
e la salud en
la organizac
imer nivel en
Salud, 2011
ro del prese
es haciendo
ás extensos
talarias y 3.5
40
en
ndo
n la
ción
n el
1)
ente
del
del
500
TFM
Usuari
Usuari
Regist
Uso Re
de la d
Ilu
Dispen
95 mil
M: SOA – IO
ios: Más de 1
ios concurre
ros:
‐ 39,7 m
‐ 3,0 mi
‐ Nº de
‐ Nº His
eceta Electró
dispensación
ustración 4‐3
nsaciones Re
lones de con
OP: dos cara
17.000 profe
ntes en A.P.
millones hoja
llones episod
citas: 400 M
storias: 8,8 M
ónica: 58% (
de forma el
3: Evolución
eceta XXI 20
nsultas citada
as de la mism
esionales san
: >9000 en p
s de consult
dios de urge
Millones
Millones
(entendiendo
ectrónica, es
n de Receta
An
10: 105 millo
as con Diraya
ma moneda
nitarios y 3.5
picos de asist
a de atenció
encias hospit
o por receta
s decir, sin re
a XXI – Presc
ndaluz de Sa
ones
a en el año 2
a
00 farmacéu
tencia seman
ón primaria
alarias
a electrónica
eceta impres
cripción elec
alud, 2011)
2.010
uticos.
nal.
a tanto la pre
sa).
ctrónica en
escripción c
el S.A.S. (SA
Pág.
omo el regis
AS, Servicio
41
stro
TFM
Ilustr
Histor
Como
sistem
Sin con
Los pri
M: SOA – IO
ración 4‐4 S
ria
principal ca
mas han creci
‐ Polític
‐ econó
‐ funcio
ntar con un p
incipales hito
1995: Con
1997‐2003
1999‐2000
2001: La B
OP: dos cara
Segmentaci
aracterística
do a golpes
a: la aparició
mica: la disp
onal: un dete
proyecto de
os de la histo
venio TASS c
3: Despliegue
0: Se empiez
BDU. Sistema
as de la mism
ón de la cita
de todo lo
de oportunid
ón de un dec
ponibilidad d
rminado gru
desarrollo n
oria de los si
con la Seguri
e de TASS
a a pensar e
a de Usuarios
ma moneda
ación vía W
2011
o desarrollad
dad. Oportu
creto o la ide
e un program
upo de clínico
ni nada simila
stemas de in
idad Social.
n Diraya
s para la elec
a
Web en el S.A
1)
do en la or
nidad de tod
ea de un polít
ma de ayuda
os propicia d
ar por lo que
nformación c
cción de méd
A.S. (SAS, Se
ganización p
do tipo:
tico
as determina
desarrollos co
e
corporativos
dico, pago ca
ervicio Anda
podemos de
ado
oncretos, etc
en el SAS so
apitativo, etc
Pág.
aluz de Salu
estacar que
c.
on:
c.
42
ud,
los
TFM: SOA – IOP: dos caras de la misma moneda Pág. 43
2002: InterSas (web de acceso al ciudadano) y AGD (Sistema de gestión de la demanda para las
operaciones de decreto).
2003: Migración del Módulo de Atención Primaria a un modelo en local con centralización de
datos. Cita en Salud Responde. Receta XXI (prescripción electrónica). Registro del Plan de
Vacunas.
2004: Estructura y operadores. Regulación de la cartera de servicios de la organización,
corporativización de catálogos, poblaciones de referencia, centralización de los operadores y de
las auditorías.
2005: Centralización de primaria. Citación de consultas externas, las agendas salen de los centros
y pasan a estar a disposición de la organización. Corporativización del RIS. Explotación de datos:
Diábaco.
2006: Despliegue de Urgencias (integración funcional) y Consultas Externas. Cita en InterSas a
través de Internet. Explotación de datos en Urgencias y citas.
2007: MPA en despliegue. Módulo de Tarjetas con el Ministerio. Notificación de cita a través de
SMS
2008: Integración de la Base de Datos de Usuarios (BDU)‐ con el registro del SNS.
2009: DAH en producción. MPA en Urgencias.
2010: Replicación de todo el soporte asistencial de Primaria y bases de datos centralizadas a un
nuevo CPD en Málaga (Plan Málaga). Extensión de DAH y RIS. 100% en AP y urgencias
hospitalarias. MPA en el 25% de AP.
2011: consolidación de DAH en 7 hospitales. Entrada en 2 de los hospitales más grandes de
Andalucía (Hospital Universitario Virgen Macarena y Hospital Universitario Virgen del Rocío).
Extensión del RIS al 95% de Hospitales Públicos. Uso del Catálogo de Servicios por parte de
entidades externas (empresas públicas, sistemas concertados, etc.).
TFM
Como
supera
Como
centra
cubier
hace r
ejemp
disgreg
pacien
Situac
La situ
model
reseña
•
M: SOA – IO
referencia,
a los 60 millo
puede ver
alizados que
rta, obviando
relativament
plo, la obsole
gación e inco
nte (NUHSA)
ción en Septi
uación de los
lo SOA y la
ados en el ca
Los sistem
tener defi
OP: dos cara
Ilustració
diremos que
ones de euro
se, los desa
dan sopor
o su sosteni
te poco tiem
escencia tecn
onsistencia d
no conciliad
iembre de 2
s sistemas en
arquitectur
apítulo dos y
mas no comp
nidas respo
as de la mism
ón 4‐5: esqu
e el presupu
os.
arrollos des
te a la mis
bilidad tecno
mpo y ha tro
nológica de m
de la informa
dos, etc.
.009
n septiembre
ra derivada
que pueden
parten tabla
nsabilidades
ma moneda
uema origin
uesto destin
stinados tan
sma tienen
ológica. Sin
opezado con
muchos de lo
ación de refe
e de 2.009, m
del mismo,
n resumirse e
as maestras.
s concretas
a
nal del Proye
ado al proye
to a la Ate
una muy co
embargo, el
n grandes inc
os HIS presen
erencia, el gr
momento en
responde b
en:
Estas se re
sobre la inf
ecto Diraya
ecto Diraya
ención Prim
onsiderable
ámbito hos
conveniente
ntes (alguno
ran número
n que se tom
básicamente
plican en la
formación q
a (SAS)
durante los
maria como
extensión y
spitalario ha
es en el proc
s de la décad
de identifica
ma la decisió
e a los patr
as distintas a
que gestiona
Pág.
últimos 8 a
a los sistem
y funcionalid
sido aborda
ceso como,
da de los 90)
ativos únicos
n de adopta
ones genera
aplicaciones
an ni planes
44
ños
mas
dad
ado
por
), la
s de
ar el
ales
sin
de
TFM: SOA – IOP: dos caras de la misma moneda Pág. 45
actualización efectivos, provocando grandes problemas de comunicación por descargas masivas,
incoherencia de datos, etc.
• Subsistemas fuertemente acoplados (dependientes) que impiden desarrollos ágiles para
responder a la demanda funcional así como la evolución tecnológica de las aplicaciones
existentes. Este acoplamiento demoró la replicación del nodo principal en el nodo de Málaga
durante más de un año.
• Difícil escalabilidad de las aplicaciones obsoletas.
• Falta de conocimiento del negocio dentro de la propia organización. Ni los funcionales conocen
bien los flujos de información ni el poco personal de TI conoce los procesos de atención sanitaria.
• Falta de conocimiento de lo que está disponible. Se desconoce cómo están desarrollados y
desplegados los sistemas más antiguos, cuáles son sus dependencias, qué limitaciones tienen,
etc.
• Problemas de volumen e históricos. No se contempla funcionalmente cómo gestionar la historia
de las personas fallecidas ni cómo trabajar con los grandes volúmenes de datos acumulados en el
operacional en la atención a una población tan extensa. Igualmente el volumen de información
gestionado y la concurrencia de usuarios provoca errores en aplicaciones comerciales
teóricamente robustas y fiables pero que no han pasado por pruebas de carga tan exigentes. Un
ejemplo claro es el descubrimiento de bugs en las bases de datos de Oracle.
• Necesidad de incorporar la hospitalización y otros ámbitos ya corporativos: RIS, enfermería…
• Multitud de tecnologías y arquitecturas empleadas en los distintos proyectos existentes.
Tecnologías y arquitecturas que han ido definiéndose en virtud básicamente de la decisión de la
empresa responsable del desarrollo sin referencia por parte de la misma de arquitectura tipo,
posibilidades de evolución tecnológicas o de infraestructura, etc.
El proyecto
Objetivos
Los objetivos principales en la adopción del modelo SOA, además de los objetivos generales de cualquier
implementación de este tipo, fueron:
‐ Facilitar la entrada en los hospitales de los sistemas corporativos, flexibilizando las
implantaciones y evitando las dependencias rígidas entre aplicaciones desbloqueando,
específicamente, la implantación de DAH.
‐ Facilitar la evolución de los sistemas de gestión de pacientes y gestión de profesionales, BDU
y MACO respectivamente, hacia modelos federados que dinamicen la gestión de los mismos.
‐ Reducir los costes de mantenimiento N3 de las aplicaciones distribuidas en los centros
unificando modelos de datos, soportes tecnológicos, tecnologías de desarrollo, etc.
TFM: SOA – IOP: dos caras de la misma moneda Pág. 46
‐ Facilitar la evolución de los sistemas más obsoletos de la organización aislándolos de las
aplicaciones actuales.
‐ Estandarizar los procesos de intercambio de información en las aplicaciones de la
organización desde la propia organización, independizándose de las decisiones de empresas
externas.
‐ Facilitar la comunicación y participación en los proyectos de Historia de Salud Digital del
Ministerio y el proyecto de Interoperabilidad europeo epSOS en los que Andalucía
encontraba grandes dificultades debido a la falta de estandarización de sus sistemas.
Modelo adoptado
El modelo adoptado es un modelo básico de SOA diferenciando la capa de negocio de la responsabilidad
de gestión tecnológica. En el ámbito de esta quedan tres capas quedaría englobada:
Capa 1: capa de datos. Bases de datos de datos maestros, bases de datos de datos operacionales,
aplicaciones tanto propias como externas de gestión directa del negocio, modelo de datos,
servidores de terminología, etc. siendo los estándares de aplicación a la capa los referidos a
modelos de referencia (RIM HL7, OpenEHR, etc.), terminologías y ontologías (LOINC, SNOMED CT,
…), etc.
Capa 2: capa de servicios o ESB es la capa que controla la difusión de la información entre los
distintos niveles y actores. Refleja la publicación de servicios, mensajería, orquestaciones, registro
de actividad, enrutado, aplicaciones compuestas, etc. Los estándares aplicables aquí son los de
mensajería (HL7), tecnologías de servicios (SOAP), segurización de comunicaciones, etc.
Capa 3: capa de negocio tecnológico que refleja el modelado de procesos, estándares aplicados
(BPML) y consumo de servicios tanto por entidades internas como externas.
TFM
Arquit
A nive
gobern
de ato
M: SOA – IO
Ilust
tectura adop
el lógico la
nanza. Const
omización qu
‐ Capa
desple
pueda
centro
‐ ESB Ce
que ge
‐ Capa d
los fun
‐ Capa d
en la c
‐ Una c
compo
OP: dos cara
tración 4‐6:
ptada
arquitectura
ta de 4 capa
ue puede lleg
base: refleja
egados. Este
ser distinta
o a otro.
entralizado e
estiona y sirv
de modelado
ncionales orq
de monitoriz
capa de mod
capa vertica
onentes de la
as de la mism
modelo SO
a adoptada
as horizontal
gar a present
a las instanc
despliegue
a en cada ce
enlazado a ca
ve de órgano
o de proceso
questando d
zación de pro
elado de neg
l de Gobern
as 4 capas, s
ma moneda
OA adoptado
permite el
es y una ver
tar el marco
cias de ESB
es idéntico
entro y el de
ada instancia
o superior.
os de negocio
irectamente
ocesos de ne
gocio propor
nanza que
us ciclos de
a
o (Fernánde
crecimiento
rtical que re
final.
B distribuida
en todas las
espliegue o
a de la capa
o en la que s
los servicios
egocio que m
rcionando in
controla, te
vida, visibilid
ez‐Engo, 201
o federado
flejan el grad
s por los ho
s instancias
suscripción
1 y con sus p
se aplican lo
s publicados
monitoriza la
dicadores de
cnológicame
dad, docume
11)©STI‐SA
del sistema
do de abstra
ospitales co
aunque la p
a los servic
propios serv
os modelados
en las dos c
as orquestac
e uso de alto
ente, el des
entación, etc
Pág.
AS
a, así como
acción y/o n
on sus servic
parametrizac
ios varía de
icios publica
s realizados
apas inferior
ciones defini
o valor añadi
spliegue de
c.
47
su
ivel
cios
ción
un
dos
por
res
das
ido.
los
TFM
A nive
hospit
publica
mantie
maest
cada u
DAE, C
M: SOA – IO
Ilustrac
el físico la ar
talario más u
ación de ser
enen las ins
ros de la or
uno de los á
CEU,… en el c
OP: dos cara
ción 4‐7: arq
rquitectura s
una instancia
rvicios centra
tancias de b
ganización p
ámbitos de a
centralizado
as de la mism
quitectura ló
se compone
a centralizad
alizados, com
bases de dat
para cada ám
aplicaciones
MACO, BDU
ma moneda
ógica adopt
de un sistem
da que perm
municación c
tos que perm
mbito hospit
concretas t
U, etc.) .
a
tada (Ferná
ma federado
mite la comu
con el exterio
miten el ma
talario y el c
anto interna
ández‐Engo,
o de instanci
nicación ent
or de la orga
ntenimiento
centralizado
as como exte
, 2011)©ST
ias de ESB id
tre instancia
anización, et
o y la difusió
y la conexió
ernas (ej. En
Pág.
TI‐SAS
dénticas a n
as hospitalar
c. Así mismo
ón de los da
ón a los ESB
n los hospita
48
ivel
rias,
o se
atos
B en
ales
TFM
Metod
La me
directa
aplicac
del an
estand
coordi
existen
M: SOA – IO
dología de tr
etodología de
amente, mo
ciones que s
nálisis de lo
darizándolos
inación de a
nte en un ám
OP: dos cara
Ilustració
rabajo
e trabajo de
odelando sus
e desarrollan
s que está
y llegando
ambas meto
mbito concre
as de la mism
ón 4‐8: arqu
e análisis co
s procesos y
n desde cero
funcionando
así a la mis
dologías par
eto desembo
ma moneda
uitectura físi
mbina proce
y llegando
o o que van a
o a día de
sma capa qu
ra evitar qu
oque en servi
a
ica adoptad
edimientos t
a la capa d
a ser rescrita
hoy, identif
ue el proces
e el crecimi
icios distinto
da (STI‐SAS,
tanto partien
e servicios,
as en su tota
icando posi
so anterior.
ento en un
os para las m
2011)
ndo de la ca
usado gene
alidad, con o
bles servicio
Se cuida es
sentido y e
ismas neces
Pág.
apa de nego
eralmente p
tros que par
os reutilizab
specialmente
n el otro de
idades.
49
ocio
para
rten
bles,
e la
e lo
TFM
Como
indepe
anterio
con la
M: SOA – IO
parte de e
endización d
ores que da
estrategia a
OP: dos cara
Ilustra
esta metodo
de aplicacion
n soporte a
doptada.
Il
as de la mism
ción 4‐9: m
ología bidire
nes que per
los mismos
lustración 4
ma moneda
metodología
ccional, des
rmite estand
pero habilit
4‐10: situaci
a
SOA adopt
sde su foco
darizar los p
tando “facha
ión inicial (S
ada (STI, 20
bottom‐up,
procesos ma
adas” estand
STI, 2011)
011)
, se incluye
anteniendo l
darizadas y e
Pág.
el proceso
as aplicacio
en consonan
50
de
nes
ncia
TFM
Como
dos ve
empre
contra
la inclu
de la o
diseño
Docum
Uno d
actual
estruc
la STI s
son los
•
M: SOA – IO
un complem
ertientes. Po
esas externa
atos de uso d
usión de los
organización
o de nuevos s
mentación
de los pilare
izada, abarca
tura de la m
se han defin
s siguientes:
Perfil func
modelizac
en la orga
existentes
OP: dos cara
Ilu
mento muy
or un lado n
as a través d
de los servici
hospitales c
en su conju
servicios com
es de la est
ar todos los
mensajería pa
ido una serie
cional y aná
ión de proce
anización,
o no.
as de la mism
ustración 4‐
importante
normalizar y
de normas c
os, certificac
omo centros
nto amén de
mo en su des
rategia SOA
ámbitos con
asando por e
e de docume
lisis SOA: lo
esos e identif
los casos d
ma moneda
‐11: desaco
se contemp
y procedime
concretas d
ción de desa
s asociados l
e involucrar a
sarrollo.
A es la docu
ntemplados e
el catálogo d
entos que in
os perfiles fu
ficación de s
e uso de lo
a
plamiento (
pla una meto
entar los pro
e desarrollo
rrollos y emp
lo que perm
a los centros
umentación.
en la estrate
e servicios, d
tentan abarc
uncionales c
servicios, el
os mismos y
(STI, 2011)
odología de
ocesos de d
o, document
presas en est
ite optimizar
s en la estrat
Esta debe
gia, desde la
documentac
car todos los
cubren, med
modelado d
y su plasma
desarrollo c
desarrollo po
tos de diseñ
tas normas,
r la capacida
tegia tanto e
mantenerse
as normas de
ción de los p
s niveles de a
diante una m
de los proces
ación en se
Pág.
corporativo
or parte de
ño de servic
etc. y, por ot
ad de desarro
n la detecció
e estrictame
e desarrollo
rocesos, etc.
actuación y q
metodología
sos estableci
rvicios ya se
51
con
las
ios,
tro,
ollo
ón y
ente
a la
. En
que
de
dos
ean
TFM: SOA – IOP: dos caras de la misma moneda Pág. 52
• Perfil operativo: Este tipo de documento especifican la secuencia de servicios necesaria para
resolver un caso de uso específico contemplando los diferentes actores implicados en una
transacción, concretando el contenido de los mensajes HL7 a usar, especificando los eventos que
disparan la mensajería y estableciendo el vocabulario (tablas maestras) a usar.
• Servicios compuestos: Este documento tiene como objetivo describir el flujo de comunicación de
los servicios que componen el servicio compuesto. Además, describen las diferentes reglas de
negocio y propiedades configurables disponibles por el servicio compuesto, indicando para cada
hospital la configuración acordada.
• Servicios atómicos: Este documento tiene como objetivo describir la cobertura funcional del
servicio así como los requisitos técnicos necesarios para la correcta implementación del servicio
tecnológico.
• Tablas maestras: Conjunto de tablas corporativas que contienen y marcan la codificación y
semántica del negocio y/o apoyan al mismo. Incluye asimismo una serie de premisas para su
gestión que son:
o Mapa de réplicas de solo lectura
o Esquema único de tablas maestras
o Un procedimiento de validación de modelos de datos de proveedores y la vigilancia de
los modelos de datos propuestos para evitar la inclusión en los mismos de Tablas
Maestras.
o Actualización inteligente (no full) usando un procedimiento de actualización diferenciado
para cada tipo de tabla y cada tipo de ámbito usando la infraestructura federada de
buses de integración.
• Normas y estándares de integración
A estos documentos descriptivos hay que sumar:
• Catálogo de Servicios: catálogo que recopila y describe todos los servicios disponibles en la
organización ya residan o no en los ESB.
• Catálogo de aplicaciones que han validado sus desarrollos de servicios contra el Catálogo de
Servicios.
• Listado de Centros de desarrollo certificado. Centros hospitalarios y/u organizaciones externas
que han certificado su personal en las herramientas corporativas según el Plan de Formación de
la Oficina de Gobernanza.
TFM
•
•
•
Proyec
Según
basa u
•
•
•
•
M: SOA – IO
I
Mapa de s
identificac
global del
Contratos
servicios e
requisitos
integració
Procedimie
o El
o So
o De
o Au
ctos embrión
Gartner (M
una iteración
Identificar
Medir el im
Selecciona
Arrancar e
OP: dos cara
Ilustración 4
sistemas SOA
ción de servi
sistema.
de integrac
existentes en
que tendrá
n (ESB corpo
entos: meto
modelado d
olicitud de re
esarrollo de s
uditoría de có
n
Malinverno &
de aplicació
r el impacto e
mpacto en el
ar el proyecto
el proyecto p
as de la mism
4‐12: extrac
A, Mapa que
cios y las ap
ción: Este ti
ntre el siste
án que cum
orativo).
dologías con
e negocios y
eutilización d
soluciones e
ódigo de los
Barnes, SOA
ón SOA son:
en el negocio
l negocio
o piloto
piloto
ma moneda
cto de las n
e presenta lo
plicaciones fi
ipo de docu
ma a integr
mplirse entre
ncretas para:
y detección d
de servicios e
en los ESB
desarrollos
A: Where Do
o
a
ormas de d
os procesos d
inales que le
umento tien
ar con el ES
e el sistema
:
de servicios
existentes
en el ESB
I Start?, 200
esarrollo (S
de negocio, l
es dan sopor
ne como obj
SB corporativ
a a integrar
06), los cinco
STI, 2011)
los flujos de
rte para obt
bjetivo enum
vo y docum
con la infr
o hitos princi
Pág.
información
ener una vis
merar todos
entar todos
raestructura
pales en que
53
n, la
sión
los
los
de
e se
TFM: SOA – IOP: dos caras de la misma moneda Pág. 54
• Medir el impacto en el negocio y ganar credibilidad
En la STI se seleccionaron dos proyectos concretos para poner a prueba el enfoque SOA: DAE o Diraya
Atención Especializada (hoy día Diraya Atención Hospitalaria) y MPA o Módulo de Pruebas Analíticas.
Diraya Atención Especializada (DAE)
Como referencia de aplicación del modelo a un proyecto con la finalidad de hacerlo viable se seleccionó
en su día Diraya Atención Especializada. Este proyecto representa la corporativización de las aplicaciones
de soporte a la atención hospitalaria e incluye una estación de gestión administrativa, una estación clínica
médica, una estación de cuidados, la solución corporativa de asistencia en consultas externas y urgencias
y el aplicativo de gestión de informes de radiología.
El objetivo del proyecto era unificar de cara al facultativo y los administrativos la gestión de las distintas
aplicaciones compartiendo los datos entre estas. Las dificultades que solucionaba eran varias:
En primer lugar, en el contexto de la atención de un paciente, por ejemplo, para un facultativo que
realizaba la atención de un paciente ingresado el disponer de toda la información obligaba a una penosa
navegación entre los distintos módulos que almacenaban información relativa a la historia clínica, los
planes de cuidado de enfermería, la información generado en consultas externas o urgencias, los
resultados de las pruebas diagnósticas, etc. Además la carencia de un sistema único de identificación del
paciente dificultaba más aún la localización de la información. En segundo lugar, al no estar normalizados
los modelos de información ni los ficheros maestros de cada uno de estos módulos, la conciliación de la
información en términos de análisis y explotación de datos, hacían poco fiables y poco sostenibles, los
indicadores de gestión que se elaboraban para los mandos de gestión de la organización.
Abordar conceptos como, cuadernos de mando integrales, gestión de costes por proceso, evaluación de
los niveles de servicio, eficiencia de los recursos, medicina basada en la evidencia y otros mecanismos de
mejora de la calidad asistencial y de gestión se encontraban fuera o muy lejos de lo que podían aportar
estos sistemas de información.
El primer enfoque adoptado, tal y como puede verse en la ilustración, se basaba en el apilamiento de
funcionalidades más que en la integración de la información. Este modelo tuvo muchos problemas tanto
de coordinación como de desarrollo y terminó adoptando el enfoque SOA. Esto permitió desbloquear los
desarrollos al centrarlos en los servicios que debían disponerse en el ESB, facilitar los despliegues (ya hay
7 hospitales funcionando con el sistema) y reutilizar los servicios diseñados a través del uso de contratos
de integración.
TFMM: SOA – IOOP: dos cara
Ilustra
as de la mism
Ilustración
ción 4‐14: M
ma moneda
n 4‐13: mod
Modelo actu
a
elo inicial d
ual de DAE
de D.A.E.
basado en SSOA
Pág.
55
TFM: SOA – IOP: dos caras de la misma moneda Pág. 56
Módulo de Pruebas Analíticas (MPA)
El módulo de pruebas analíticas es un módulo que permite unificar la gestión de las peticiones a
laboratorio desde las estaciones clínicas de la organización habilitando el uso de un catálogo de pruebas
común, parámetros comunes de distribución y evaluación y la optimización de los recursos de los
laboratorios de las áreas que dan servicio a atención primaria.
Es el primer sistema centralizado que empezó a usar criterios de servicios en su desarrollo aunque no
llegó a abstraerse tanto como para considerarlo un diseño SOA. Como primer proyecto de esta índole
carece de la madurez suficiente como para definirlo como caso de éxito de la estrategia pero abrió el
camino para la utilización a nivel centralizado de contratos de servicio y mensajería estandarizada, que
era uno de los principales obstáculos en el arranque del proyecto SOA.
Sin embargo, adolece de excesiva interrelación entre los desarrollos tecnológicos y de mensajería y los
procesos de negocio propiamente dicho reflejando los primeros procesos separados que, realmente, son
variaciones del mismo y que de haberse modelado según un análisis estricto SOA hubiese ahorrado una
gran cantidad de esfuerzo y dinero.
A día de hoy este proyecto, extendido en más del 70% de áreas hospitalarias de la comunidad, está en
proceso de redefinición para su uso en los centros hospitalarios a nivel interno y la optimización de su
arquitectura.
Hitos alcanzados
• Adquisición y despliegue de la arquitectura diseñada. Mediante el lanzamiento de sendos pliegos
en Julio de 2010 y Julio de 2011 se ha llevada a cabo la adquisición de 29 licencias e
infraestructuras físicas para el ESB hospitalario a desplegar en cada uno de los centros del SAS. En
el pliego de 2011 se amplió el sistema con la adquisición de licencias para la implantación tanto
del ESB centralizado como de las capas de BPM, BAM y Gobernanza que permitirán el despliegue
completo del modelo antes de finales del presente año.
• Puesta en marcha:
o de la Oficina Técnica de Interoperabilidad: así mismo mediante concurso en Julio de 2010
se dota la OTI como brazo tecnológico de la Oficina de Gobernanza SOA. Esta Oficina es la
encargada del análisis de servicios, definición de mensajería, certificación de aplicaciones,
desarrollos iniciales, etc.
o de la Oficina de Gobernanza SOA: arrancada de forma paralela y contando únicamente
con personal de la organización, esta oficina es la encargada de establecer las políticas
generales, aprobar procedimientos, validar y publicar normas, etc.
TFM
•
•
•
M: SOA – IO
Despliegue
metodolog
negocio y
reutilizable
que facilit
momento.
proyectos
la OTI y po
Publicació
desarrollad
resultados
Subdirecci
Internet a
certificado
Inicio del a
los análisi
modelo ge
un mapa g
OP: dos cara
e de sistem
gía general
y presentaci
es, la econo
tará la ampl
. De esta ma
de consultas
or tanto en e
n de docum
da por la o
s de audito
ón de Tecn
aunque cue
os, etc. (http
análisis de p
s desarrolla
eneral de pro
global tanto a
Ilustraci
as de la mism
as bajo el p
de desarrol
ón del aná
mía en el us
iación de la
anera proyec
s de la Histo
l modelo.
mentación –
oficina de in
rías de los
ologías de l
nta con va
://ws001.jun
rocesos de l
dos para el
ocesos de la
a nivel asiste
ión 4‐15: m
ma moneda
paraguas de
lo y como
álisis SOA. E
so de recurs
a funcionalid
ctos como el
ria Única de
Catálogo de
ntegración a
servicios, e
la Informaci
arias seccion
ntadeandalu
la organizaci
arranque d
a organizació
encial como l
odelado de
a
e las Oficina
paso previo
Esto facilita
sos y el con
dad de la ap
l Sistema Int
l Ciudadano
e servicios y
sí como tod
etc. se enc
ón denomin
nes restring
cia.es/unific
ón. Tanto de
de proyectos
ón, aunando
logístico, adm
e procesos g
as: se ha co
al análisis
la detecció
ocimiento p
plicación des
tegral de Ges
se referenci
metodología
das las norm
uentra pub
nado Unifica
idas a pers
a)
e forma espe
s concretos
los resultad
ministrativo,
global (STI, 2
onseguido es
tecnológico
ón tempran
profundo del
sarrollada cu
stión Logísti
ian de forma
as. Toda la
mas y proce
licada en e
a y que está
sonal propio
ecífica como
se le está d
dos de cada
, etc.
2011)
Pág.
stablecer en
, el análisis
na de servic
flujo funcio
uando llegue
ca (SIGLO) y
a sistemática
documentac
edimientos,
el portal de
á accesible
o, proveedo
o aprovechan
dando forma
uno de ellos
57
n la
de
cios
onal
e el
los
a en
ción
los
e la
por
ores
ndo
a al
s en
TFM: SOA – IOP: dos caras de la misma moneda Pág. 58
• Puesta en marcha del modelo de gestión de datos maestros y terminología con el diseño, prueba
e implemetación de un proceso de Actualización de Tablas Maestras basado en la infraestructura
federada de ESB que permite la actualización de estas tablas de forma inmediata y su gestión
desde un solo punto de la organización evitando de esta manera incongruencias básicas en la
interpretación de los mismos.
TFM: SOA – IOP: dos caras de la misma moneda Pág. 59
5. APLICABILIDAD A OTROS ÁMBITOS DE NEGOCIO
Los problemas evolutivos analizados no afectan en exclusividad al ámbito de la salud. Muchos sectores se
ven afectados por problemas de igual índole (volúmenes acumulados, ámbitos de aplicación extensos,
necesidad de intercambio de información estructurada con soporte semántico adecuado, etc.) y con
riesgos similares como la Administración de Hacienda y Seguridad Social o los Cuerpos y Fuerzas de
Seguridad del Estado que, aunque sus modelos de información son más simples y bastante menos
dinámicos, no han conseguido ver resuelta de forma satisfactoria la interoperabilidad entre sus distintos
entornos (ya sean funcionales, organizacionales o geográficos), incluso dentro de las mismas
organizaciones. Es más, algunos sectores muy representativos de la sociedad, como la Justicia, aún no
han conseguido acometer un plan de gestión automatizada de la información manteniéndose a niveles
tecnológicos propios del siglo pasado.
Así mismo, la estrategia asumida es independiente del negocio dado que es una estrategia general de
adopción SOA y la concreción de la misma en una hoja de ruta adecuada a un ámbito concreto de negocio
no debería suponer más dificultad que la priorización de las tareas a desarrollar en función de la
disponibilidad de recursos de la organización afectada y el ámbito, ya sea de información, funcional o
tecnológico, que necesite con más imperiosidad la adopción del modelo.
Por tanto, el proceso establecido en la organización estudiada debería tener una fácil extensión en otros
ámbitos menos complejos informativamente hablando aún en el caso de los que carecen de un soporte
de clasificaciones tan sólido como el del ámbito sanitario. Esto no significa que dicha adopción sea
sencilla ya que los condicionantes de implicación de la organización, establecimiento de estrategias de
gobernanza, etc. no son fáciles de cumplir. Es más, prevemos que adoptar una estrategia de este tipo
resultaría mucho más viable y efectivo en organizaciones fuertemente jerarquizadas (cuerpos de
seguridad, ejército, etc.) que en otro tipo de organizaciones.
TFM: SOA – IOP: dos caras de la misma moneda Pág. 60
BIBLIOGRAFÍA
Comunidad de Extremadura. (03 de 06 de 2003). Telemedicina en España. Obtenido de
iTelemedicina.com: http://www.itelemedicina.com/index.asp?p=espania/4.asp
Fernández‐Engo, J. R. (20 de 05 de 2011). La estrategia de Interoperabilidad en la STI ‐ SAS. Seville, Seville,
Spain.
Gaur, H., & Zirn, M. (2006). BPEL Cookbook. PACKT Publishing.
Generalitat de Catalunya. (s.f.). Receta Electrónica. Obtenido de eSalut ‐ Generalitat de Catalunya:
http://www.gencat.cat/especial/esalut/cas/recepta.htm
Grupo de Interoperabilidad. Living Lab Salud Andalucía. (2.009). Interoperabilidad: qué es y por qué
debemos llegar a ella.
Jellema, L. (2011). Oracle SOA Suite 11g Handbook. Oracle Press ‐ McGraw Hill.
Junta de Andalucia. (2010). Presupuesto de la Comunidad Autónoma de Andalucía para el año 2010.
Seville: Junta de Andalucia.
Kenn, M., Allison, A., Dan, A., Falkl, J., Hately, A., Peng, D., y otros. (2008). Red Paper. Case Study: SOA
Governance Scenario. IBM.
Laine, S. (s.f.). SOA and Business Process Manegement: A Case Study of a Healthcare Organization.
Obtenido de Service Oriented Entreprise Architecture Modelling:
http://www.irwanashari.com/pdf/Service‐Oriented‐Enterprise‐Architecture‐Modelling.html
Malinverno, P. (2006). Sample Governance Mechanisms for a Service‐Oriented Architecture. Gartner
Research.
Malinverno, P., & Barnes, M. (2006). SOA: Where Do I Start? Gartner Research.
Malinverno, P., Natis, Y., Pezzini, M., & Weaver, T. (2009). Th 13 Most Common SOA Mistakes and How to
Avoid Them. Gartner Research.
Ministerio de Sanidad, Política Social e Igualdad. (s.f.). Esquema de Interoperabilidad. Obtenido de
Ministerio de Sanidad, Política Social e Igualdad:
http://www.msps.es/organizacion/sns/servWebSNS/EsqInterope/home.htm
S. Daskalakis; J. Mantas. (2009). The Impact of SOA for Achieving Healthcare Interoperability. An empirical
investigation based on a hypothetical adoption. Methods Inf Med, 190‐195.
TFM: SOA – IOP: dos caras de la misma moneda Pág. 61
SAS. (2010). Dossier Diraya . Seville: SAS.
SAS. (s.f.). SAS ‐ Diraya. Historia de Salud Única de Andalucía. Obtenido de Dossier Diraya:
http://www.juntadeandalucia.es/servicioandaluzdesalud/principal/documentosAcc.asp?pagina=
pr_diraya
SAS, C. d. (2011). Healthy Andalusia. Seville: Junta de Andalucía.
SAS, C. d. (2011). Servicio Andaluz de Salud. Obtenido de Junta de Andalucía:
http://www.juntadeandalucia.es/servicioandaluzdesalud/principal/default.asp
STI, S. A. (2011). Interoperabilidad. Obtenido de Unifica: https://ws001.juntadeandalucia.es/unifica
STI‐SAS. (20 de 06 de 2011). Pliego de condiciones técnicas . Convocatoria para la adquisición de una
plataforma corporativa de gestión de servicios SOA para el Servicio Andaluz de Salud. Exp 108/11‐
SP. Madrid, Spain: Red.es.
Thompson, J. (2 de April de 2009). Gartner Says SOA Is Evolving Beyond Its Traditional Roots. Stamford,
Connecticut, USA. Obtenido de Gartner Newsroom.
Thompson, J. (2009). SOA Infraestructure Selection Criteria. Gartner Research.
TFM: SOA – IOP: dos caras de la misma moneda Pág. 62
TFM: SOA – IOP: dos caras de la misma moneda Pág. 63
A N E X O S
TFM: SOA – IOP: dos caras de la misma moneda Pág. 64
ANEXO A: GLOSARIO
A
Arquitectura de referencia SOA – Una arquitectura de referencia SOA define los servicios tecnológicos
requeridos para sostener cada fase en el ciclo de vida de los servicios.
AP ‐ atención primaria.
B
BPM ‐ Business Process Management (BPM) es una disciplina que combina software y conocimiento del
negocio a través de personas, sistemas e información, mejorando el desarrollo y la mejora de los
procesos, facilitando la sostenibilidad, escalabilidad e innovación.
BPEL ‐ Business Process Execution Language. Lenguaje de desarrollo basado en XML usado para la
orquestación de servicios a través de servicios compuestos o de proceso. El resultado son servicios Web.
C
Ciclo de vida ‐ El ciclo de vida define una metodología para conseguir la consecución del modelo SOA a
través del modelado de los procesos de negocio y los servicios que los soportan, componiendo servicios
en aplicaciones compuestas, desarrollando servicios en entornos robustos y escalables, gestionando y
monitorizando los recursos tecnológicos clave y las métricas de negocio.
Conectividad – La conectividad SOA permite el intercambio de información entre todos los actives de la
organización, tanto de forma interna como externa, a través de un sistema horizontal de mensajería
seguro y escalable que consolida la comunicación entre aplicaciones, actores y fuentes de información.
Cuadro de mando – provee vistas simplificadas de determinados indicadores del negocio en caliente,
unificando fuentes fragmentadas de información para monitorizar, analizar, gestionar la toma de
decisiones, etc.
CAE – Consultas Externas
D
DAE – Diraya Atención Especializada
DAH – Diraya Atención Hospitalaria
TFM: SOA – IOP: dos caras de la misma moneda Pág. 65
E
Entry Points ‐ Entry Points en SOA son 5 puntos de vista distintos pero interrelacionados de entender los
proyectos SOA y que permiten acompasar negocio y componentes tecnológicos: actores, procesos,
información, conectividad y reutilización.
ESB – Un ESB (Enterprise Service Bus) es una infraestructura flexible basada en la conectividad diseñada
para integrar aplicaciones y servicios optimizando las siguientes actividades entre los servicios y los
consumidores:
• Enrutado de mensajes entre servicios
• Conversión entre los protocolos de transporte usados por servicio y consumidor
• Transformación entre los formatos de los mensajes usados por servicio y consumidor
• Gestión de los eventos de negocio que disparan los servicios
Evento – Un evento es una acción o instancia del mundo real que ocurre o no ocurre en un periodo
específico de tiempo. Los servicios responden a los eventos en función de las reglas de negocio.
G
Gestión SOA – La gestión SOA estructura el despliegue, monitorización, aseguramiento, control y
disponibilidad de los procesos de negocio SOA basados en servicios y aplicaciones compuestas así como
el soporte de los entornos tecnológicos en que se apoyan.
Gobierno – El gobierno SOA ayuda a las organizaciones a alcanzar las metas establecidas y el estado
deseado según la visión del negocio estableciendo reglas de decisión, indicadores, políticas y mecanismos
de control a lo largo del ciclo de vida de los servicios.
I
Información – La Información entendida como un servicio es un enfoque que desacopla la misma de su
repositorio, procesos o almacenamientos en aplicaciones proporcionando un servicio unificado y
verificado a las aplicaciones, procesos y actores decisores que la necesiten.
Interoperabilidad
La capacidad de distintos sistemas de intercambiar información unos con otros de forma desatendida, sin
la intervención humana, e interpretarla de la misma manera para su asimilación inmediata por actores
humanos. La interoperabilidad entre diferentes plataformas y lenguajes de programación es un
TFM: SOA – IOP: dos caras de la misma moneda Pág. 66
objetivo/logro fundamental de un despliegue SOA. Hay que indicar que la simple aplicación de estándares
no garantiza la interoperabilidad.
M
MPA – Módulo de Pruebas Analíticas
MPI – Master Patient Index
N
NUHSA – número único de identificación de paciente en Andalucía. Asignado por BDU.
O
OASIS ‐ Organization for the Advancement of Structured Information Standards. Consorcio Internacional
de la industria de la computación, sin ánimo de lucro, para el desarrollo, convergencia y adopción de
estándares de e‐bussines y Servicios Web http://www.oasis‐open.org.
OMG ‐ Object Management Group. Consorcio Internacional de la industria de la computación, sin ánimo
de lucro, para el desarrollo, de estándares de integración empresarial. Entre otros UML, MDA y BPMN.
http://www.omg.org.
Orientación a servicios – Una forma de pensar en el negocio como tareas relacionadas pero escasamente
acopladas y sostenidas por servicios.
P
Procesos – Un proceso es un conjunto de tareas de negocio relacionadas para generar un servicio o
producto específicos y que abarcan actores, sistema e información. Los procesos pueden ser tanto
manuales como automáticos
R
Repositorio ‐ El repositorio almacena y gestiona los servicios y sus componentes desde un punto de vista
de negocio. Esto es, gestiona interfaces, contratos, acuerdos de nivel de servicio, dependencias, etc. para
ayudar a identificar, diseñar y desarrollar servicios. La descripción de los servicios debe ser independiente
de los detalles técnicos y de la arquitectura. Esto garantiza que no es necesario el cambio del repositorio
si se cambia de infraestructura (ESB). La información debe usarse para fomentar la reutilización de los
servicios así como para gestionar estos a través de todo su ciclo de vida.
TFM: SOA – IOP: dos caras de la misma moneda Pág. 67
Reutilización – Esta orientación proporciona vías para crear nuevos servicios de negocio reutilizando los
servicios tecnológicos existentes y creando aplicaciones compuestas de los servicios de negocio
disponibles.
S
SIGLO – Sistema Integrado de Gestión Logística
Seguridad – La seguridad SOA se articula habilitando políticas de usuario centralizadas que gestionan la
autenticación, autorización y acceso a las aplicaciones, la información y los datos proporcionando un
direccionamiento consistente hacia el cumplimiento de las políticas de seguridad corporativa y su
auditoría.
Servicio ‐ Servicios son módulos reutilizables de software, autocontenidos, que son independientes de las
aplicaciones y de las plataformas en que corren. Tienen interfaces bien definidas y permiten mapear 1 a 1
las tareas de negocio y los componentes tecnológicos exactos necesarios para ejecutar la tarea.
Servicio de Negocio compuesto – Los servicios de negocio compuestos son colecciones de negocio/lógica
individuales y servicios tecnológicos que trabajan de forma orquestada, alineados con las aplicaciones
existentes, para proporcionar soluciones de negocio específicas acordes a los estándares definidos en el
ámbito dado.
SOA ‐ Service Oriented Architecture (SOA) es una aproximación a una arquitectura tecnológica basada en
el negocio que gestiona la integración del mismo como un conjunto de tareas relacionadas pero
escasamente acopladas, reutilizables y sostenidas por servicios. Asegura la rápida adaptación de los
sistemas tecnológicos a la evolución del negocio usando la estructura tecnológica subyacente en forma
de servicios para crear conexiones a través de aplicaciones y fuentes de información dispares.
TFM: SOA – IOP: dos caras de la misma moneda Pág. 68
ANEXO B: ANTEPROYECTO
DATOS DEL ALUMNO Nombre José Román Fernández Engo e-mail [email protected] DATOS DEL TUTOR (si no se propone ninguno, dejar en blanco) Nombre Miguel Ángel Sicilia Institución / departamento Ciencias de la computación e-mail [email protected] Datos generales del proyecto: Titulo Evolución a SOA basado en estándares de Sistemas de Información en
Salud existentes. Interoperabilidad semántica de forma no traumática. Objetivo principal
Conseguir una hoja de ruta viable para la evolución de sistemas existentes en entornos autonómicos de envergadura hacia sistemas interoperables semánticamente basándose en el paradigma SOA y la aplicación de estándares.
Objetivos detallados
Determinar el estado actual del entorno habitual en SI; casos Definir las metas necesarias para un enfoque SOA Definir, para cada una de estas metas, el Roadmap a seguir Definir la relación entre SOA e interoperabilidad Proponer un plan de acción
Breve descripción de actividades
Analizar el estado actual de los modelos de SI autonómicos en el entorno de la salud, especialmente en comunidades con largo recorrido en estos sistemas y con un ámbito de actuación amplio Definir la relación entre la consecución de una arquitectura SOA basada en estándares y la consecución de la IOP semántica en un entorno dado Profundizar en las hojas de ruta necesarias para lograr los desarrollos previstos Establecer este marco como base para un estudio más profundo y detallado (tesis)
Planificación (diagrama de Gantt)
Resultados esperados (incluir hitos)
- Diagnóstico de los SI actuales - Establecimiento de las relaciones causa-efecto SOA – IOP - Propuesta de la arquitectura SOA necesaria - Propuesta de hoja de ruta
Principales aportaciones del trabajo
Establecer la relación entre las arquitecturas basadas en el negocio y la IOP semántica Definir un camino conceptualmente sencillo para la consecución de la IOP semántica basado en SOA y el uso de estándares
Método de evaluación propuesto
Observaciones adicionales (opcional)
