TFM analiza SOA e IOP en Sistema Sanitario Andaluz

NOMBRE FERNANDEZ Firmado digitalmente por NOMBRE FERNANDEZ ENGO JOSE - NIF
31254607E

ENGO JOSE - NIF Nombre de reconocimiento (DN): cn=NOMBRE FERNANDEZ ENGO
JOSE - NIF 31254607E, c=es, o=FNMT, ou=fnmt clase 2 ca
Motivo: Autor
31254607E Fecha: 2011.11.15 08:16:56 +01'00'

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

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:


A mi mujer, Susana, y a mi hija, Clara,
sin cuyo apoyo y sacrificio jamás hubiese
podido concluir este trabajo.


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.


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. 1

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


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


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


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.

La sabiduría suprema es tener sueños bastante grandes para no perderlos de vista
mientras se persiguen (William Faulkner)

Palabras Clave: SOA, interoperabilidad, gobernanza, ESB, servicios, SAS


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.

The highest wisdom is to have dreams big enough to keep track of them while
chasing (William Faulkner)

Keywords: Interoperability, SOA, process, business, healthcare, legacy systems


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.


• 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.


Ilustr
ración 1‐1: G
Granulación
n en la deriv
vación del proceso al se
p ervicio (STI, 2011)

TFM: SOA – IO dos cara de la mism moneda
M OP: as ma a Pág. 11

Ilustración 1‐2: ejem
mplo de defin
nición de flu
ujo en funció
ón de las et
tapas de la Ilustración
anterior. (STI, 2011)

• Servicio d negocio: es una fun
de nción, enten
ndida esta como un co
c onjunto de operaciones o
secuencia de actividad
des que cump
ple las siguie
entes caracte
erísticas:
o n estado, aut
sin tocontenida,
, no depende
e de la condi
ición de otro
o servicio.
o Pu
uede actuar como prove
eedor permit
tiendo llamadas para la r e informació
recepción de ón y
de
evolviendo una respuest a con el resultado de las acciones (t
tarea) ejecut
tadas y/o co
omo
co
onsumidor lla
amando a ot
tro servicio p
para obtener una respues
sta (consumi
idor).
o Ca
ada servicio refleja una s
sola tarea y es reutilizado las veces q
que sea necesario evitan
ndo
la multiplicidad.
o Se orquestan en función del mode
e n elado de lo procesos y flujos de negocio. La
os s d
or
rquestación s
secuencia lo
os servicios y
y provee la ló
ógica adicion
nal para procesar los dat
tos.
Si un proceso e
es una prote
eína, un servicio es un am
minoácido.

TFM SOA – IO dos cara de la mism moneda
M: OP: as ma a Pág. 12

Ilus
stración 1‐3
3: apilamien
nto de casos
s de uso sob
bre la granu
ulación de lo
os procesos
s (STI, 2011)
)

Dada la coinciden
ncia históric del inicio de las implementacio
ca o ones SOA co la difusión del uso de
on
tecnología de Serv
vicios Web d
demasiado a menudo, ca
asi diríamos que de form
ma sistemátic
ca, se confun
nde
álisis de un servicio de negocio con el uso de un servicio web o de métodos de
el aná n efinidos para la
a
nicación dentro de la aplicación. Este
comun e es uno de los principales errores c
cometidos po
or las empre
esas
de des
sarrollo cuando quieren abordar es tipo de proyecto. Axiomáticam
n ste A mente SOA se desliga de la
e
tecnología. Por tanto no prop
pugna el uso de ninguna en concreto aunque e cierto que el uso de los
o es
servici
ios web facilita en determinadas circunstan
s ncias la implementació tecnológ
ón gica de cier
rtas
ecturas de in
arquite nformación.

SO
OA Web Services

Plataforma tecnológica N
No Sí

Protocolo de transpor
rte N
No Sí

Su desarro
ollo se basa e
en el negocio
o Síí No

Influencia directa en lo
os flujos y m
modelos de ne
egocio Síí No


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


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


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.

Necesidades
Nivel de Interop. Temas a tratar
Horizontales
Políticas de Salud Visión y estrategia
Estructuras, procesos, incentivos
Marco legal y socio‐económico sostenible
Privacidad y confidencialidad
Certificación de sistemas y equipos

Organizacional Organizaciones y Cultura
Proveedores de servicios Procesos de servicios internos y externos
Gestión del cambio
Reingeniería de procesos

Semántica Terminología, Clasificación y Ontologías Escalabilidad
Traducciones Sostenibilidad
Implantación y desarrollo de infraestructuras sostenibles.

Sintáctica Mensajería

Técnica Estándares técnicos
Conectividad 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


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.


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.


‐ 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.


• Falta de c
conocimiento del negoc derivada en gran medida de la anterior, la divisiones TI
o cio: a m a as s
cuentan co
on escaso nú
úmero de ex
xpertos funci
ionales y, los
s que lo son,, suelen hab
ber adquirido
o su
conocimiento con mu
uchos años de experie
encia en entornos dete
erminados (hospitales, por
ejemplo) y no con el estudio sis
y stemático del entorno con lo que   la generalización de e
esta
experiencia es complic cooperación con los grup
cada. Por ot ro lado, la c pos funciona
ales puros su
uele
ser compleja cuando se trata de modelar la informació que man
e a ón nejan debido a su falta de
o
e en el trato con estos p
costumbre profesionales
s, la habitual endogamia  en los entornos clínicos
s, la
tendencia a confundir la funcionaliidad con la a
arquitectura tecnológica,, etc.

Ilustración 2‐1: Estruct
tura de dire
ección de un
na empresa de éxito (In
nditex). Com
mo puede
c
comprobars
se, las TI est
tán present
tes en la tom
ma de decisiones estrat
tégicas de la misma.

• Generalme
ente los sist
temas están   mal dotado de profes
os sionales de la informaci
ión. La falta de
influencia derivada de lo expues en los dos puntos anteriores s
e sto d suele llevar a la deficie
ente
de profesiona
dotación d ales, tanto e
en número co
omo en form
mación y/o ex
xperiencia, d
de las divisiones
TI de las o
organizacione
es que encue
entran grand
des dificultad
des tanto ec onómicas co
omo jerárqui
icas
para contr
ratar en núm
mero suficien
nte profesion
nales de alto
o nivel. De he
echo se sigue consideran
ndo
la informática o el trat
tamiento de la información como una parte del s
soporte administrativo de la


organización y no com
mo una parte
e estratégica en el funcio
onamiento y
y crecimiento
o de la mism
ma y
esto tiene un reflejo di
irecto en sus
s dotaciones.

Ilustració
ón 2‐2: Inversión media
a en IT en la
a Unión Euro
opea por ám
mbito de ne
egocio.


Ilustrac
ción 2‐3: Ga
asto medio p
por emplea
ado IT en la UE por ámb
bito de nego
ocio.

• Evolución condicionad por la po
da olítica: al ser organizacio
ones de ám
mbito político y los pues
o stos
directivos desde el niv
vel intermed io cargos de
e adjudicación tanto los o obales como los
objetivos glo
organigram operativ se ven gravemente influidos por la direcc
mas vos e p ción política del momento
a
impidiendo
o la consolid
dación tanto de equipos humanos co
ompetitivos c
como de pro
oyectos de la
argo
alcance co
on objetivos claros. El cic
clo de cuatro
o años máxim
mo, incluyend
do medio de asentamiento
y otro medio de despedida, hacen que los gr
n randes proye
ectos sufran vaivenes muy importan
ntes
en llegar a im
que puede mpedir su des
spliegue.
• Falta de ca
apacidad de decisión en
n las organizaciones: com
mo consecue
encia de tod
do lo anterio
or la
capacidad de decisión en las orga
n anizaciones por parte de los mando tecnológic es basta
e os cos ante
limitada y está muy condicionada p
por el temor
r a la confron
ntación con l os profesion
nales.
• Existen dos clientes en
n la cadena d
de valor:
o El profesional: ven a las TI como sus te
ecnólogos.
o El ciudadano: s
se debe cum
mplir como em
mpleados pú
úblicos.

tomía y lo reflejado e el punto anterior lleva a situ
Esta dicot en o uaciones de indefinición y
n
estancamiento en el tratamiento de la inform
mación para e ón entre ambas facetas. Un
evitar colisió
laro es la ine
ejemplo cl ercia del cole
ectivo médic
co a consider
rar como pro
opia la historia del pacie
ente
y los datos
s que en ella
a residen, pa ra usar en su
us investigac
ciones, por e
ejemplo, y las leyes vigen
ntes


que garan
ntizan al pac
ciente la tot confidenc
tal cialidad de sus datos y la posibilidad de negar el
acceso a lo que decida.
os mismos a los clínicos q

• Estamos e el mundo y este se m
en mueve. Adem de lo expuesto ante
más eriormente, el mundo sig
e gue
avanzando y las autonomías deb responder a los req
o ben querimientos planteados desde nive
s s eles
superiores
s como, por e
ejemplo:
o Lo
os proyectos del Minister
rio a nivel nacional: Histo
oria Única Dig
gital o Recet
ta electrónica
a
o Pr
royectos euro
opeos de Int
teroperabilid
dad como el e
epSOS

Ilus
stración 2‐4: Interopera
abilidad en el SNS (Min
nisterio de S
Sanidad, Pollítica Social e Igualdad)
d)


Ilustr
ración 2‐5 p
países perte
enecientes a
al proyecto e
epSOS (Euro
opean Unio
on)

Proble
emas en trat
tamiento de la informaci
ión

Los pr
roblemas aq reflejado tienen u
quí os una compon
nente tanto de gestión de la info
n ormación co
omo
tecnológica aunqu
ue, por regla general, la s
segunda es c
consecuencia
a directa de la primera d
dado que la raíz
n de casi tod
común dos ellos es la falta de d efinición, es
structuración
n, gestión y u
uso de la inf
formación de
e la
ización en la que se care
organi ece, habitual mente, de v a de la transcendencia de la
visión global o conciencia
inform
mación gestio
onada en cad
da uno de los
s ámbitos y s
su impacto en el resto.

• Los sistem
mas no co
omparten d atos maest
tros. No existe en la organización definici
a ión,
documentación ni difu
usión de los datos cons
s siderados ma
aestros por la misma. La consecuen
ncia
suele ser, especialmen
nte en organ izaciones gra
andes, que c
cada vez que
e se empieza un proyecto
o se
referencian estos dato según el criterio del funcional al cargo en es momento teniendo e
os se o esto
secuencia la incoherencia
como cons ntica de la or
a estructural en la semán rganización.
• Subsistemas fuertemente acoplado entes). La falta de mode
os (dependie elización de la informació
ón y
de la organiz
los flujos d zación conlle
eva que los desarrollos evolucionen
n no desde la
a necesidad del
negocio sin
no desde la c
conveniencia
a de la empr
resa desarrolladora. Gen eralmente e
esto deriva en la
agregación
n de funcion
nalidades de distintos es
spacios del n
negocio en u
una sólo unid
dad tecnológ
gica
que es des
spués sumam
mente costos
so de modularizar cuand
do la evoluciión del propio negocio hace
inviable la continuidad
d de esta agre
egación.


• Escalabilid
dad no previs
sta ni vertica
al ni horizon
ntalmente. La falta de viisión global y
y/o experien
ncia
en la gesti
ión de la info
ormación y lla tendencia política a co
orporativizar
r ideas que p
pueden pare
ecer
en primera
a instancia d
de impacto p
pero que no se someten a un análisis
s riguroso ni se hacen lle
egar
a las unida
ades de gest
tión de la in
nformación antes de que estén term
a e minadas hace que muchos
en
desarrollos sean inutil
lizables una vez termina
ados dada su incapacida de afront el escena
ad tar ario
o en la organ
real de uso nización (por
r ejemplo po
or su ineficien
ncia en la ge
estión de un número alto
o de
usuarios) o
o incapaces d
de hacer cre cer su funcio
onalidad conforme lo dem
manda el negocio.
• atos se comparten mediiante réplicas no controladas o, dich o de otra manera, no su
Muchos da uele
haber pro
ocedimientos de contro l y actualiza
s ación de las tablas com
s mpartidas po los sistem
or mas
principales lo que sue conllevar errores de coherencia en cuanto se realizan actualizaciones
s ele r e
rápidas o i
imprevistas, evoluciones
s no deseada
as de tablas de datos ma
aestros, falta
a de control por
parte de la
a organizació
ón de sus dat
tos estructur
rales, etc.
• Necesidad de integrar historias d ámbitos contemplad de form disjunta. La carencia de
de dos ma
modelo de
e datos comú
ún y de dato
os maestros c s conlleva la imposibilida
consolidados ad de gestion
nar,
sin un gran esfuerzo de transform
d mación y evo
olución de lo sistemas, los registros generados en
os s
ámbitos at
tendidos por
r aplicacione
es distintas, o
o en ocasione
es con la mis
sma.

Ilustración
n 2‐6 Estado
o de las apli
icaciones (S
STI, 2011)©S
STI‐SAS


Proble
emas en tecn
nología

• Multitud de entidade desarrolla
es adoras no coordinadas. Especialme
c ente cuando en el mis
o smo
negocio ex
xisten distint
tas entidade
es con capac
cidad de desarrollo y des
spliegue de soluciones y
y no
existe una gobernanza definida d las mismas ni una vi
a de isión genera de la orga
al anización. En la
n
misma org
ganización de
esarrollan di stintas empr
resas o divisi
iones interna
as con tecno
ologías distintas,
procedimientos distint
tos, visiones y finalidades distintas y sin visión en
n absoluto de
e lo que ya e
está
do o se está desarrolland
desarrollad do en otros á
ámbitos dentro de la mis
sma organiza
ación.
• Sistemas que han crecido sin definición del proyec
c cto. Lo que conlleva problemas de
e
compatibilidad entre tecnologías de desarrollo, SO, bases de datos tecnología de hardwa
s, a are,
s de tiempos
problemas s de desarrol lo e implantación, proble
emas con los
s métodos de soporte, et
tc.
• ncia de la política. Tal y có
Dependen entó en la introducción.
ómo se come
• Sistemas c
con  mucha h
historia en c s grandes lo que provoca
comunidades a la coexistencia de muc
chas
tecnología
as de desarro
ollo que en s
su momento
o fueron de primera líne
ea pero hoy día, debido a
a la
falta de pla
anificación e
en su momen
nto de la evo
olución tecno
ológica del siistema,  está
án obsoletas,
, de
soportadas, son incom
mpatibles con
n los sistemas actuales, e
etc.

Ilu
ustración 2‐
‐7 Diversas informacion
nes que refl
lejan los pro
oblemas de los sistema
as actuales


• 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


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.


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 analiza SOA e IOP en Sistema Sanitario Andaluz

TFM analiza SOA e IOP en Sistema Sanitario Andaluz

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (8)

Similaire à TFM analiza SOA e IOP en Sistema Sanitario Andaluz

Similaire à TFM analiza SOA e IOP en Sistema Sanitario Andaluz (20)

Plus de José Román Fernández Engo

Plus de José Román Fernández Engo (9)

Dernier

Dernier (20)

TFM analiza SOA e IOP en Sistema Sanitario Andaluz