SOA - IOP. Dos caras de la misma moneda.

967 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
967
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
20
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

SOA - IOP. Dos caras de la misma moneda.

  1. 1. NOMBRE FERNANDEZ Firmado digitalmente por NOMBRE FERNANDEZ ENGO JOSE - NIF 31254607EENGO JOSE - NIF Nombre de reconocimiento (DN): cn=NOMBRE FERNANDEZ ENGO JOSE - NIF 31254607E, c=es, o=FNMT, ou=fnmt clase 2 ca Motivo: Autor31254607E Fecha: 2011.11.15 08:16:56 +0100 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
  2. 2. TFM: SOA – IOP: dos caras de la misma moneda  
  3. 3. 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  
  4. 4. TFM: SOA – IOP: dos caras de la misma moneda  
  5. 5. 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  
  6. 6.      TFM: SOA – IOP: dos caras de la misma moneda  
  7. 7. 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  
  8. 8.      TFM: SOA – IOP: dos caras de la misma moneda  
  9. 9. INDICE GENERAL  Pág. DEDICATORIA ............................................................................................................................ iiAGRADECIMIENTOS 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 
  10. 10. 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. 2 
  11. 11.  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. 3 
  12. 12.      TFM: SOA – IOP: dos caras de la misma moneda Pág. 4 
  13. 13. 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. 5 
  14. 14.      TFM: SOA – IOP: dos caras de la misma moneda Pág. 6 
  15. 15. 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  TFM: SOA – IOP: dos caras de la misma moneda Pág. 7 
  16. 16. 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  TFM: SOA – IOP: dos caras de la misma moneda Pág. 8 
  17. 17. 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. 9 
  18. 18. • 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.  TFM: SOA – IOP: dos caras de la misma moneda Pág. 10 
  19. 19.   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 
  20. 20.   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 
  21. 21.   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  deel  aná n  efinidos  para la  a  nicación dentro de la aplicación. Estecomun 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 inarquite 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  TFM SOA – IO dos cara de la mism moneda M: OP: as ma a Pág. 13 
  22. 22. 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. 14 
  23. 23. 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. 15 
  24. 24. 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 HorizontalesPolí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 equiposOrganizacional Organizaciones y CulturaProveedores de servicios Procesos de servicios internos y externos Gestión del cambio Reingeniería de procesosSemántica Terminología, Clasificación y Ontologías Escalabilidad Traducciones Sostenibilidad Implantación y desarrollo de infraestructuras sostenibles.Sintáctica MensajeríaTé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  TFM: SOA – IOP: dos caras de la misma moneda Pág. 16 
  25. 25. 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. 17 
  26. 26. 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. 18 
  27. 27. ‐ 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: SOA – IOP: dos caras de la misma moneda Pág. 19 
  28. 28. • 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  TFM SOA – IO dos cara de la mism moneda M: OP: as ma a Pág. 20 
  29. 29. 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. TFM SOA – IO dos cara de la mism moneda M: OP: as ma a Pág. 21 
  30. 30.   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 TFM SOA – IO dos cara de la mism moneda M: OP: as ma a Pág. 22 
  31. 31. 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)  TFM SOA – IO dos cara de la mism moneda M: OP: as ma a Pág. 23 
  32. 32.   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 todcomú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 careorgani ece, habitual mente, de v a de la transcendencia de la  visión global o concienciainform 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.  TFM SOA – IO dos cara de la mism moneda M: OP: as ma a Pág. 24 
  33. 33. • 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 TFM SOA – IO dos cara de la mism moneda M: OP: as ma a Pág. 25 
  34. 34. 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   TFM SOA – IO dos cara de la mism moneda M: OP: as ma a Pág. 26 
  35. 35. • 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. 27 
  36. 36. 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. 28 
  37. 37. 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. 29 

×