Por Mario Chao, Director Global de la práctica de salud de everis
“Desarrollar o Comprar – esa es la cuestión”… Por décadas este planteamiento al más puro estilo shakesperiano parece ser una y otra vez el dilema de los CIOs cuando se decide abordar un nuevo proyecto informático. Tan viejo como la propia profesión informática, el debate se repite tanto para aplicaciones multisectoriales (ERPs, CRMs, etc.), como para aplicaciones especificas de un negocio o sector. Así pues, no es de extrañar que cuando el director informático de un hospital recibe el encargo de la dirección general y/o de la dirección médica de valorar la incorporación de un sistema de Historia Clínica Electrónica (HCE) se encuentre en esta disyuntiva.
Para ir al grano, no creo que exista una solución perfecta. Cada hospital o institución de salud tiene sus características y singularidades, y cada una debe valorar lo que es mejor en cada caso. Múltiples variables condicionan la decisión, entre ellas, las características propias de la institución (cuán especializadas y particulares son sus necesidades y qué oferta de mercado hay para satisfacerlas); la existencia o no de talento interno para construir y mantener por años su propio sistema clínico de acuerdo a las siempre cambiantes circunstancias del mercado de la salud; o la necesidad de contar con el sistema en tiempo y forma (restricciones temporales y presupuestarias), por mencionar tres grandes temas.
A pesar de que cada caso es único, existe un creciente consenso en el sector de que casi siempre la mejor opción es ir a un producto de mercado. ¿Por qué? Existe un par de argumentos fundamentales. Primero, desarrollar un sistema de HCE desde cero requiere gran cantidad de tiempo, esfuerzo e inversiones, especialmente si se pretende llegar a cubrir las capacidades funcionales de los líderes del mercado, y lo que es peor, no hay ninguna garantía de éxito a priori. Es importante destacar que existe un gran déficit global en especialistas en eHealth y en HCE, con lo cual la tarea de construir algo nuevo se torna aún mas complicada. Por otro lado, mientras que las empresas que se dedican a construir soluciones comerciales invierten importantes cantidades de dinero en I+D para mantener actualizadas y evolucionar sus soluciones para incorporar las mejores practicas del mercado, los hospitales usualmente no cuentan con partidas presupuestarias para estos fines. El segundo gran argumento es el foco en el negocio: un hospital o institución de salud tiene como objetivo cuidar y atender a sus pacientes, no ser una fábrica de soluciones informáticas, no es su “core-business” y por tanto mantener esta apuesta a largo plazo resulta poco justificable.
Sin embargo, ir a una solución de mercado no es la “panacea” tecnológica que nos libra de todos los riesgos. Para empezar, muchos productos comerciales requieren un esfuerzo importante de personalización, adaptación y ajustes para que cumpla los requerimientos y las expectativas de un cliente. Esto es normal, puesto que un producto de mercado se basa en incorporar las mejores prácticas, generalizándolas en una solución informática concreta. El quid de la cuestión está entonces en la capacidad del producto en ser tan flexible como un desarrollo a medida y poder así adaptarse a las necesidades especificas de un mercado y de un cliente concreto, sea vía parametrización, configuración o APIs de desarrollo.
La pregunta es entonces ¿hay espacio para una “tercera vía” en la implementación de la HCE? ¿Alguna solución comercial que ofrezca un producto base con las mejores prácticas internacionales, pero que a la vez nos permita adaptarlo a las necesidades de la organización sin morir en el intento?
Conceptualmente hablando, este tipo de soluciones flexibles, con módulos funcionales construidos como “building blocks” que se pueden ir ensamblando y adaptando para construir una solución final se le conoce como “EHR Modular” y en cierta medida, constituye el sueño de muchos clientes que desean dar un salto de calidad en sus soluciones de HCE pero sin renunciar ni descontinuar ciertos componentes o módulos desarrollados internamente con mucho esfuerzo y que están diseñados para responder a ciertas necesidades particulares de su organización.
Por otro lado, estos sistemas modulares y flexibles deben contener una biblioteca de funciones o APIs, orientadas al sector salud, que les permita no solo adaptar su HCE sino también abordar otros desarrollos específicos internamente sin depender de un proveedor externo. Así pues, se llega al concepto de framework de eHealth, o lo que es lo mismo, una arquitectura de desarrollo de software, que permita adaptar la HCE o generar nuevas aplicaciones de negocio disminuyendo sensiblemente el riesgo de un desarrollo a medida, y aprovechando las mejores practicas del mercado ya incorporadas en el framework y en el producto base.
En un mercado inmaduro como el sector de tecnologías de la información aplicada a la salud, y en concreto el sub-segmento de HCE, la llegada de esta “tercera vía” es una alternativa bastante viable y especialmente atractiva para clientes que han invertido mucho dinero en construir soluciones ad-hoc pero que necesitan actualizarse o mejorarlas, o incluso para clientes que quieren comprar una solución de mercado contrastada pero basada en frameworks o arquitecturas especialmente pensadas para la personalización y/o adaptación de la solución, que los haga flexibles, agiles y abordables, económica y técnicamente. Este enfoque esta ganado cada vez mas adeptos, incluso en mercados muy competitivos como el de Estados Unidos, donde iniciativas gubernamentales han estado incluyendo los sistemas modulares dentro del programa de estimulo a la adquisición de sistemas de HCE.
En everis seguimos este enfoque a través de nuestra plataforma ehCOS; creemos y apostamos a que es especialmente atractivo en mercados como el latinoamericano donde no abundan las soluciones flexibles que combinen fortalezas funcionales, tecnológicas y precios competitivos, adaptadas a las realidades de nuestros países. Nuestra arquitectura de desarrollo de software orientada a eHealth (llamada ehCOS framework), nos permite ofrecer un producto comercial de historia clínica electrónica, ehCOS CLINIC, pero con la posibilidad de adaptarlo y complementarlo utilizando los más de 70 componentes de negocio que conforman nuestro “Healthcare Development Toolkit” para responder a las necesidades especificas de un cliente. De esta forma logramos el equilibrio entre el time-to-market y el conocimiento empaquetado en una tecnología world-class con la flexibilidad de un “homegrown”. Todo esto, por supuesto, con un enfoque metodológico propio que guía adecuadamente el proceso de transformación y de gestión del cambio para minimizar la posibilidad de errores o desviaciones en los proyectos.
Futuro Salud Latam agradece a Mario Chao su valioso aporte.
Móvil México: (+52) 1 55 1877 2000
Móvil España: (+34) 619 705 043
Futuro Salud Latam 
Interesante vision para enfrentar el problema
Me gustaMe gusta
El desafío, de los directores, de los establecimientos de salud es formar un equipo de TI maduro que utilice herramientas de desarrollo orientadas a la productividad (no software libre), que aplique normas y estándares, que tenga una mirada amplia del negocio y con un ojo puesto en las nuevas tecnologías.
Se recomienda no inventar la rueda, los sistemas financieros, logística y recursos humanos cómprelos. Hay muchos, bastante buenos y a precios acordes a su tamaño.
La columna vertebral de su HIS, es mejor que la construya usted. Esto es lo que le entregará flexibilidad para manejar el negocio y competir adecuadamente. Me refiero a los sistemas que definen su negocio: Comercial (Convenios y precios), Admisión Hospitalizados, urgencia, Agenda Ambulatoria, el control de las cuentas de sus pacientes, el valorizador, la cobranza, las cajas y el sistema que vincula/retribuye a su equipo de profesionales.
Los sistemas departamentales cómprelos si son complejos para usted, como por ejemplo: RIS/PACS completo. El RIS es un sistema sencillo, pero normalmente viene junto con el PACS (ojo solo si no le encarece la solución).
Los sistemas departamentales, de apoyo al diagnóstico o al tratamiento, como Farmacia/Insumos Clínicos, Laboratorio Clínico, Pabellones Quirúrgicos, Banco de Sangre, Estaciones de enfermería, Respiratorio, Anatomía Patológica, etc.. dependiendo de la complejidad y expectativas de su organización es posible abordarlos con desarrollos locales, o en su defecto comprarlos. Siempre existe la posibilidad de construir un sistema único que le permita apoyar el proceso y capturar los cargos, mientras agrega paulatinamente los sistemas anteriores siempre que los necesite dependiendo de la complejidad /tamaño de su organización.
Los sistemas para el mundo de los profesionales de la salud, como un simple escritorio médico resulta un buen ejercicio para el equipo de desarrollo local. Pero un sistema de registro clínico o algo más avanzado como un Sistema Clínico con algún nivel de inteligencia es mejor comprarlo por ahora. Al igual que los servicios de conexión de analizadores con el RIS, equipos de imágenes (scaner,RX,etc) con el RIS/PACS o equipos médicos con la FCE.
Por último, el servicio técnico,, data center y otros como correo electrónico, etc.. también depende.
Me gustaMe gusta
Mi fe de erratas : dice «…. conexión de analizadores con el RIS,..»
debe decir «…. conexión de analizadores con el LIS,..»
y debo agregar , siempre utilice HL7 para integrar sus aplicativos.
Me gustaMe gusta
Clarísima exposición. Las tecnologías de la información y comunicación son elementos de competitividad entre hospitales. Por ello cada hospital debe tener la capacidad de innovar y mejorar sus herramientas para asir ser mas eficientes y aportar mayor calidad a sus clientes/pacientes.
Y esto lo permiten soluciones de mercado como la vuestra que ya han demostrado éxito de muchas partes del mundo.
Enhorabuena.
Me gustaMe gusta
Mas que una propuesta es una forma muy pragmática para enfrentar un gran reto a los que comienzan o van integrándose al área de TIC’s en salud, que esta todavía en pañales en Latinoamerica! y que en esta década apenas comienza a crecer en forma sustentable, todavía hay mucho camino por recorrer…
Me gustaMe gusta
Excelente artículo y planteamiento el de Mario y everis. Un Framework debe permitir huir de los sistemas monolíticos, cada vez más difíciles de mantener tanto en el caso de las empresas o de los centros. La tecnología actual permite la integración de aplicaciones actuales, y para los centros utilizar un framework puede ser una vía de disponer de lo mejor sin tener que renunciar a desarrollos propios.
La gran asignatura pendiente, para mi, en la adopción de la EHC y otras aplicaciones es la enorme resistencia al cambio, y en el sector público en ocasiones la baja cualificación de los potenciales usuarios de los sistemas.
Me gustaMe gusta
La idea de Everis es interesante desde varios puntos de vista, en particular me gusta el enfoque dual. Por un lado tenemos una herramienta para hacer software de salud y a la vez tenemos un software listo para ser usado. A diferencia de otras herramientas basadas en SOA o SaaS, el usuario final puede tener control total de sus datos y su herramienta de trabajo. Si a esto le sumamos la experiencia y el know-how de Everis en el tema podemos garantizar de antemano la satisfacción del cliente.
Me gustaMe gusta
Estoy de acuerdo con todos los comentarios anteriores y me gustaría agregar un enfoque adicional.
Hasta ahora hemos analizado los desafíos para implementar los HCE a nivel hospitalario ósea a nivel individual del prestador pero no a nivel de red.
A futuro la integración pública/privada será cada vez mayor y el paciente crónico necesitara atenderse en diferentes niveles asistenciales para mitigar su enfermedad.
El Desafío es crear una HCE (para empezar con los crónicos) que sea compatible y tenga interoperabilidad con el hospital, la atención primaria y otros prestadores en la red asistencial, con el fin que el medico pueda acceder a los datos del paciente que se registraron en otros establecimientos.
En Chile tenemos en algunos hospitales excelentes HCE funcionando pero creo que ninguno puede operar en red. Las preguntas que tengo son:
1. El contenido del HCE es del hospital o del paciente?
2. Puede una HCE Cloud integrar la información del paciente y facilitar el trabajo en red?
3. Quien debería liderar esta discusión el Minsal, Fonasa otra institución?
Hemos avanzado con el AUGE en línea porque resuelve la integración de los prestadores pero está lejos de ser una HCE intersectorial porque ese software fue concebido para cumplir otros objetivos importantes.
Me gustaMe gusta
No puedo estar más de acuerdo. Es absurdo que un hospital se centre en desarrollar algo que no va a saber diseñar, desarrollar, ni tampoco actualizar. De la misma forma, es absurdo que una empresa especializada pretenda que «todo» el mundo de ajuste a una sola solución, por buena que esta sea. Por ello, parece claro la aportación que supone para este campo la existencia de soluciones flexibles que sean cada vez más y más capaces de resolver los problemas y satisfacer las distintas soluciones que necesitan los usuarios.
Me gustaMe gusta
La pregunta es casi como ¿ir al médico o automedicarse?. Desde ya se debe contar con un servicio de consultoría de profesionales en informática. Comprar dicho servicio a mi entender sería la solución correcta. Existen empresas dedicadas casi exclusivamente al desarrollo de soluciones para el sector salud, en un producto único y en crecimiento, con los aportes de numerosas instituciones en salud. En lo personal tengo la suerte de poder ofrecer ese camino.
Me gustaMe gusta
Bastante buen artículo Mario, siempre he pensado que la mejor solución de Expediente Electrónico o Sistema de Gestión Clínica como llamamos en Centro Médico ABC es la que cumple con los criterios de «Usabilidad», «Flexibilidad» (para adaptarse tanto a las condiciones y necesidades de las Instituciones, como con el resto de sistemas para que se puedan integrar) y «Escalable» y aqui es donde ehCos tiene una buena respuesta a esta problemática de adaptación e integración de los procesos clinico – hospitalarios de la Instituciones de salud
Me gustaMe gusta
Sinceramente no me parece muy claro el concepto que en este artículo se trata de presentar como una «tercera» vía ya que con esta argumentación estamos confundiendo dimensiones conceptualmente diferentes.
La alternativa a lo que es «modular» viene siendo lo «monolítico». Esta es la «dimensión» que tiene que ver con el diseño y arquitectura de la solución. Cada una con sus pro y contras (en esta dimensión también puede caber hablar de frameworks etc.)
Pero en cambio el dilema «make it» (desarrollarlo) or «buy it» (comprarlo) es *otra* dimensión distinta que *nada* tiene necesariamente que ver con ser o no modular o al revés monolítico etc. Y por cierto que en esta dimensión la tercera vía ya existe (!) : «to rent» (arrendarlo).
Yo puedo optar por una solución modular o no, basada en un framework o no…. etc. independientemente de quién la desarrolle (yo o terceros), o si la compro, o si la arriendo.
El marketing de nuestras soluciones debiera ser un poco más consistente y alineado con la disciplina del rubro, sino vamos a salir pensando que la alternativa a «blanco» o «negro» (dos colores para pintar una pared) vendría siendo.. que se yo… digamos: «camioneta de 4 puertas» (un medio de transporte).
Me gustaMe gusta
Gracias Mauricio. Todas las opiniones son validas. La tercera vía, en el contexto del articulo, tiene que ver con «obtener» un software y se refiere a la posibilidad de «ensamblar» soluciones en una «economía de APIs», que es cualitativamente diferente a desarrollar o comprar. Bajo esa filosofía (totalmente posible y viable), el hecho de «modular» vs «monolítico» es crucial.en el debate aunque entiendo tu punto de vista y lo respeto mucho. Gracias por tus observaciones. Saludos, Mario Chao
Me gustaMe gusta
Reblogueó esto en HCE y sus aledañosy comentado:
Interesante reflexión sobre posibles soluciones a la HCE
Me gustaMe gusta
Te das de bruces con la egolatría y divinidad de aquellos en los que confías tu vida y para los que, como seres de otro universo, su forma de gestionar está más allá de la perfección y de esas herramientas diseñadas por políticos y gente «sin talento». Esas singularidades de las que habla usted, y esa divinidad de la que hablo yo, van en contra de un sistema homogéneo (que no idéntico) y estándar en el que unos pocos, o unos muchos a nivel mundial con estándares, tratan de conseguir con un esfuerzo titánico luchando contra esa mal llamada «fricción», que dicen existe cuando un profesional trata de usar una nueva herramienta. Te encuentras con el absurdo, ya no de que dos instituciones funcionen de forma homogénea e interoperable (que no idéntica), sino de que dos individuos de la misma organización (que deberían colaborar con un único objetivo: el paciente) quieran que las herramientas funcionen «como a ellos les gusta y vienen haciendo toda la vida». Y no hay más. Supongo que lo adecuado es llegar a un compromiso para que todos los profesionales de cualquier ámbito, colaborando, puedan llegar a un objetivo común y beneficioso, en lugar de estar quejándose por que nadie es capaz de aceptar y consensuar un cambio por ese bien común.
Por no hablar de la heterogeneidad del descomunal ecosistema de herramientas y proveedores que pueden existir en una institución (a pesar de los estándares de integración), y que solo conoce, decide y gestiona una pequeña parte de la institución.
Me gustaMe gusta