Desarrollando software para el sector salud

Developing software for health

Francisco Javier Ramírez Ante

[email protected]

Soluciones Informáticas Integrales En Salud SAS

Resumen– ¿Por qué desarrollar software para el sector Salud?, pareciera una pregunta fácil de formular y con una respuesta aún más fácil de proyectar, pero la realidad del sector y muchos años inmerso en él me han enseñado que son más las preguntas que deberemos resolver, quizá no será este el espacio que ayude a despejar la mayoría de ellas pero si permitirá al lector tener un “Big Picture” del sector donde estamos queriendo incursionar y conocer algunas de las necesidades de las instituciones que prestan servicios de salud, de los retos que se le plantea a la industria del desarrollo de software especializado en Salud, de las expectativas que la normatividad Nacional e Internacional exigen a los desarrolladores de este tipo de aplicaciones, de los requerimientos de los profesionales de la salud y en últimas de los beneficios esperados por los actores más importantes de este ecosistema, los pacientes.

Palabras claves– Desarrollo de Software, Historias Clínicas electrónicas, Normas Internacionales, Sector Salud.

Abstract– Why develop software for Health ?, it seems an easy question to formulate and with an even easier answer to project, but the reality of the sector and many years immersed in it have taught me that are more questions to solve, maybe not Will be the space that helps us to clear most of them but will allow the reader to have a Big Picture of the sector where we are wanting to enter and learn some of the needs of the institutions that provide health services, the challenges that are It poses to the industry of the development of software specialized in Health, of the expectations that National and International normativity demand to the developers of this type of applications, of the requirements of the professionals of the health and in the last the benefits expected by the actors Most important of this ecosystem, patients.

Keywords– Electronic Health Records, Health, International Standards, Software development

1. Introducción

Desde el ya lejano 1993, el aspecto tecnológico de nuestro sistema de salud, ha evolución y se ha transformado, podríamos decir que inicio con la Ley 100 [6], por la cual se crea el Sistema de Seguridad Social Integral, promulgada el 23 de diciembre de aquel año, pues la entrada en vigencia de esta ley marcó un hito importante en el desarrollo de los sistemas de salud en el país, esta ley supuso un cambio en la cultura organizacional de las Instituciones Prestadoras de Salud (IPS), unos años más tarde, ya con nuevos actores en el sistema, se hizo necesario un estándar que reglamentara el intercambio de información, de manera que todos logren hablar un mismo idioma independiente de las aplicaciones que empleasen las IPS, es así como en el año 2000 una nueva resolución, la 3374 del 27 de diciembre [1], por la cual se reglamentaban los datos básicos que deben reportar los prestadores de servicios de salud y las entidades administradoras sobre los servicios de salud prestados, estructuro los Registros

Individuales de Prestación de Servicios (RIPS), que bien podríamos considerar el primer estándar de interoperabilidad en el sector, desde entonces y hasta la fecha este evolución ha sido constante y ha incorporado paulatinamente estándares y requerimientos de carácter internacional.

Después de 20 años en la industria del Software, en especial del desarrollo de sistemas de información para el sector salud, sé que no hay una fórmula mágica que permita amalgamar de manera perfecta todos los elementos que una casa de software debe considerar al momento de desarrollar un sistema de tal envergadura, por esa razón no encontrara dicha fórmula durante la lectura de este artículo, si a pesar de esta advertencia decide continuar con la lectura mencionare que encontrara algunos elementos que deberá considerar para la construcción de este tipo de sistemas, pues la industria del software, en especial la que ofrece servicios o productos para el sector salud presenta grandes retos a las casas de software que incursionan en el sector. Una industria como la nuestra deberá cumplir con requerimientos Normativos, generalmente promulgados por el Ministerio de Salud de cada País, relacionados con la prestación de los servicios de atención en salud siempre orientados a la calidad y eficiencia de las instituciones de salud, u otras leyes que norman aspectos como el manejo de los Datos Personales en posesión de terceros, el conjunto de datos mínimos y sensibles que deberán ser tratados en los sistemas de información, así mismo la implementación de estándares internacionales para la integración e interoperabilidad de los actores del sector, otros estándares como los de calidad que debemos respetar y cumplir como desarrolladores de software, además de las necesidades propias del personal asistencia y de los pacientes que estos atienden, e implementar metodologías de desarrollo y de gestión de proyectos que permitan la madurez progresiva de la empresa y que fortalezcan tu sistema interno de calidad, por consiguiente conseguir una fórmula que permita la integración perfecta de todos estos elementos y consideraciones es el mayor reto que enfrentamos como industria cada día.

Se recomienda un estudio constante de estos aspectos, monitorear con frecuencia la evolución los estándares, de las necesidades de la industria, de las tendencias tecnológicas, y de la aplicación de metodologías que permitan, apoyado en estos elementos, dirigir de la mejor manera la casa de software y la mesa de ayuda de tu empresa; durante el desarrollo de este articulo encontrara información respecto a los riesgos de la implementación de un sistema de información en general, de las oportunidades para la industria, en especial que encontramos en nuestro país, de las necesidades y requerimientos del sector salud. Este artículo describe estos temas a treinta dos mil pies de altura esperando motivar al lector a profundizar en muchos de estos elementos.

2. Visión global sobre la implementación de sistema de información

Desde 1994 Standish Group ha publicado periódicamente el Chaos Report o Reporte del Caos, este Reporte permite conocer los resultados que se obtienen en miles de proyectos de la industria del desarrollo de software e identificar los Riesgos que se presentan hoy día en la implementación de Sistemas de Información.

El último informe, publicado a finales de 2015, analizo 50.000 Proyectos de desarrollo alrededor del mundo, desde mantenimientos pequeños hasta gigantescos proyectos de reingeniería, concluyendo que el sólo el 29% fueron exitosos, es decir que éstos fueron desarrollados e implementados tal cual fueron previstos, cumpliendo los plazos, el presupuesto y además obteniendo resultados satisfactorios (no necesariamente cumpliendo el alcance), el 19% de los proyectos definitivamente fueron fracasos (se cancelaron o se finalizaron pero el producto nunca se usó) y el 52% presentaron varios problemas para poder ser completados (con retraso, por encima del presupuesto y/o con menos de los requisitos esperados) lo que implicó más inversión de tiempo y recursos [7]. La definición de proyecto exitoso empleada en el Chaos Report incorpora el resultado satisfactorio del proyecto y elimina el cumplimiento del alcance, esta dista de la definición del Project Management Institute (PMI) que determina el éxito de un proyecto por el cumplimiento de las 3 constantes clásicas el Plazo (onTime), el Presupuesto (onBudget) y el Alcance (onTarget).

Del análisis de los proyectos fracasados, según las estadísticas del Standish Group, un 56% de los errores se encuentra en la fase de estudio y análisis, principalmente en la definición de los requerimientos, un 10 % obedece a errores en la fase de Diseño, un 7% a errores de codificación y un 27% a otros factores como cambio o falta de identificación del personal clave con dominio del negocio y de procesos, como consecuencia, ante esta alta tasa de siniestralidad, las compañías de seguros difícilmente amparan proyectos de desarrollo de software. Un Reporte anterior del Standish Group permite identificar los factores de riesgo que conllevaron al Fracaso o cancelación del proyecto [26] (Ver Tabla 1.) donde prima antes que los factores técnicos la mala definición de los requerimientos y de la definición del alcance o expectativas que se desean obtener de la implementación del Sistema.

Tabla 1.Factores de fracaso o cancelación.

Una parte clave del análisis de Standish Group de los últimos 23 años ha sido la identificación y clasificación de los factores que confluyen para hacer que los proyectos sean más exitosos, los resultados muestran la siguiente lista y clasificación de factores (Ver Tabla 2.) resultando llamativo ver cómo los 3 factores que más influyen para hacer los proyectos más exitosos no son en absoluto técnicos [7].

Tabla 2.Factores de éxito.

El Chaos Report de este año deja dos importantes reflexiones a considerar como industria: los proyectos más pequeños tienen una probabilidad mucho más alta de éxito que los más grandes y en todos los tamaños de proyectos, la aplicación de enfoques ágiles dio como resultado proyectos más exitosos y menos fallas directas, aumentando el porcentaje de éxito del 11% al 39% y bajando el porcentaje de fracaso del 29% al 9% [7].

Por su parte, En Mayo de 2014, el PMI realizo una serie de estudios denominada Pulse of the Profession The High Cost of Low Performance [5] esta consulta, en la que participaron más de 2.000 profesionales en la gestión de proyectos, determinó que entre las principales causas del fracaso de un proyecto siempre se encontraban las siguientes: Corrupción del alcance, una Comunicación pobre, la Falta de implicación de los interesados y el Apoyo inadecuado del patrocinador del proyecto; La conclusión de este estudio por parte del PMI es que la clave para que las organizaciones puedan entregar proyectos con éxito radica en un buen análisis de negocio (business analysis) y para ser bueno en análisis de negocio tienes que ser bueno gestionando los requisitos, sólo el 20% de las organizaciones encuestadas se considera madura en cuanto a la gestión de requisitos Y sólo el 46% de las organizaciones reconoce utilizar un proceso formal para asegurar la validación de los requerimientos.

3. Oportunidades para la industria colombiana y las necesidades del sector salud

Con Asombro, y porque no un poco de incredulidad, escuchaba los datos que presentaba el Ministro David Luna, Titular del Ministerio de Tecnologías de la Información y las Comunicaciones (MinTIC), sobre las necesidades y oportunidades del sector durante su presentación de apertura de la Asamblea Anual de la Federación Colombiana de la Industria de Software y TI (FEDESOFT), El Ministro indicaba que para el 2018, el país tendrá una brecha de 53.000 profesionales del sector [16], de acuerdo con datos del Observatorio TI, que es una iniciativa del MinTIC y FEDESOFT. En su columna del diario el Tiempo Miguel Ángel Hernández, publicada en febrero de 2014 [8], citando fuentes del MinTIC, describía la necesidad del País de graduar 12.000 ingenieros por año, Sin embargo, solo 5.000 nuevos profesionales salían a suplir las necesidades de la industria.

Miguel Hernández comentaba también que En Colombia, al 80% los profesionales recién egresados les toma menos de un año encontrar trabajo, con remuneraciones salariales que ubican a la industria TIC en el tercer lugar del escalafón de las actividades económicas con mayor remuneración, siendo superado solo por las actividades científicas y la educación superior privada, pero esa inserción laboral no es tan inocua como debería ser pues el 85% de los egresados no cuentan con los conocimientos precisos que requieren las empresas que les contratan.

Otro dato importante que revelaba el Ministro Luna durante su intervención hacía referencia que las Empresas en el sector TI ofrecen sus productos a dos sectores en especial, Gobierno y Comercio, y solo entre el 6% y el 8% de las empresas concentran sus esfuerzos en tres sectores de la economía: Salud, logística y transporte, según el Informe de caracterización de la industria de Software y Tecnologías de la Información [17], elaborado por el Observatorio de TI a Finales del 2015; teniendo en cuenta lo anterior el Ministro mencionaba que habían grandes oportunidades para las empresas que hoy día ofrecen tanto desarrollo como servicios al sector salud, pues a pesar que la salud es un sector en estado crítico, donde la prioridad es la atención médica y el pago de nómina, la inversión en tecnología queda relegada a un segundo lugar, así sea necesaria, esto contraviene Normas Nacionales e Internacionales que exigen la adopción de Sistemas de Información que apoyen la gestión de las instituciones y procuren la eficiencia de las mismas.

En Colombia solo el 30% de las clínicas y hospitales tiene historia clínica electrónica [17], a pesar de ser un requisito obligatorio, de acuerdo con la Ley 1438 de 2011 en su parágrafo “transitorio” del Artículo 112, “La historia clínica única electrónica será de obligatoria aplicación antes del 31 de diciembre del año 2013…”. El universo de IPS que todavía no cuenta con historia clínica electrónica se convierte en una oportunidad para los proveedores de TI.

Tomando en consideración que algunos aspectos de la historia clínica están normados por organismos Internacionales como la Organización Mundial de la Salud (OMS) o la Organización Panamericana de la Salud (OPS), como las Historias para el control del Embarazo o la Historias de Alteraciones del Joven, por mencionar algunas, permite pensar que las historias Clínicas, al menos en la Región Interamericana, serían similares debido a que el acto clínico y las Guías de atención de los pacientes en la mayoría de los casos obedecen a patrones definidos, esto sería una ventaja para las empresa de desarrollo, pero la facturación y los requisitos de la Ley 100 y los propios exigidos por las entidades gubernamentales hacen que los empresarios colombianos puedan responder de mejor manera a los cambios requeridos, mientras las firmas extranjeras que desean hacer presencia en el país no pueden atenderlos con prontitud.

Como lo documenta el estudio de Demanda Por TI En El Sector Salud 2011-2015, realizado en 2015 por el observatorio de TI, hoy día se reconocen en los proveedores locales, fortalezas como el cumplimiento de los requerimientos que impone la regulación y su adaptación al cambio, la calidad de la mano de obra, su experiencia en el sector salud, la calidad de sus productos y servicios, su capacidad de respuesta y el precio, en el caso de los productores extranjeros a su favor tienen la capacidad de investigación, una cultura innovadora, la integración con otras aplicaciones, los niveles de cumplimiento y el músculo financiero, aunque sus debilidades se encuentran en el costo de sus servicios y la dificultad en el soporte, además de no tener soluciones “tropicalizadas” [17].

Otro punto a tener en cuenta es que, en este sector, hay entidades que cuentan con grandes departamentos de tecnología que se encargan del diseño y gestión de desarrollos propios. Sin embargo, se ve una tendencia a cambiar este modelo por uno de outsourcing, las entidades están pasando de un sistema de adquisición por licenciamiento a uno de software como servicio (Software As A Service, SaaS) con el fin de concentrar los esfuerzos en el CORE del negocio, que es la prestación de servicios de salud o de aseguramiento.

En el estudio de Demanda Por TI también se destacan las oportunidades que se generan con las distintas tendencias que están impactando la salud, tales como la automatización de la historia clínica, la interoperabilidad, la movilidad, el internet de las cosas, el big data, la seguridad de la información y el desarrollo de aplicaciones digitales para usos en salud. En los últimos 15 años la prioridad para el sector era la facturación, pero una vez solucionada esta necesidad, se le empezó a dar prioridad a la automatización de la historia clínica [17]; mediante la Resolución 0429 de 2016, el Ministerio de Salud presentó como parte de la Política de Atención Integral en Salud (PAIS), el Modelo de Atención Integral en Salud (MIAS,) este modelo determina las prioridades del sector salud a largo plazo siendo uno de los diez componentes básicos, la consolidación de las Redes Integradas de Servicios de Salud y la creación de un sistema único de información que permita la gestión de un conjunto mínimo de datos, centrado en el ciudadano, la familia y la comunidad con estándares (semánticos y sintácticos), integrados con interoperabilidad, bajo arquitecturas modulares con interfaces estandarizadas y otras tecnologías disponibles.

De otro lado, considerando que la adopción de tecnologías de la información por parte de la población en Colombia sigue aumentando a un ritmo acelerado según lo descrito por el Informe Global de Tecnología de la Información 2016 del Foro Económico Mundial [9], el país enfrenta nuevos retos orientados a generar soluciones innovadoras que involucren al paciente en el manejo de enfermedades crónicas, el monitoreo remoto de los pacientes y el autocuidado, el desarrollo en aplicaciones que promuevan la atención no presencial, y que permitan facilitarle la vida al paciente con procesos de pre admisión y la entrega en línea de las autorizaciones médicas para una población que está acostumbrada cada día más a hacer todo en línea, y una creciente tendencia al uso de dispositivos Wearables para el autocuidado, el uso de redes sociales para que el paciente tenga información oportuna y de primera mano sobre su salud, la implementación de servicios de consulta remota (Telefónica, Correo, Virtual) para tener contacto con un médico sin salir de casa.

Finalmente, el estudio presenta a la tele salud o tele medicina como una tendencia que abre la posibilidad de nuevos desarrollos. En el caso de Colombia, está tecnología fue reglamentada por la Ley 1419 de 2010 [20], que establece los criterios de implementación de este modelo que no es más que un conjunto de servicios y métodos de atención en salud a distancia con el uso de aparatos tecnológicos y el acceso a Internet

4. Sistemas de información como herramientas para alcanzar la eficacia, eficiencia, equidad y sostenibilidad

Conocidos los Riesgos que conlleva la implementación de sistemas de Información, tan grandes como los requeridos por el sector Salud, y observando las oportunidades que se presentan para las empresas orientadas a ofrecer Desarrollos y servicios para las IPS llega el momento de ver el carácter misional, y porque no social, de estos desarrollos para plantear de nuevo la pregunta ¿Por qué desarrollar Software para el sector salud?

Garantizar el derecho a la salud en igualdad de condiciones para todos es una meta hacia la que toda sociedad quiere avanzar, máxime en una región tan desigual como América Latina y el Caribe. La cobertura universal es un objetivo importante para la mayoría de los países; sin embargo, el contexto para lograr una cobertura universal es difícil: cada día aumenta la presión sobre el gasto en salud. El rápido desarrollo de la tecnología médica, los cambios epidemiológicos y el envejecimiento de la población son algunos de los factores que llevan a los países a incrementar su gasto en salud. Además, como resultado de mejores condiciones de vida y más acceso a información médica, la población tiene expectativas cada vez mayores de lo que debiera ofrecerle el sistema de salud. Al mismo tiempo, los recursos para la salud no han crecido a la par de la demanda, lo que ha generado una brecha creciente. “Ningún país del mundo tiene los recursos suficientes para proveer a todos sus ciudadanos la totalidad de los servicios con los máximos estándares de calidad posibles; cualquiera que crea lo contrario vive en un mundo de fantasía”, dice en un artículo reciente Sir Michael Rawlins, presidente del National Institute for Clinical Excellence [11].

En el 2010, la OMS presentó El informe sobre sobre la financiación de los sistemas de salud en el Mundo, este informe sugiere que entre un 20 y un 40% del dinero invertido en salud se desperdicia [10], y teniendo en cuenta que los recursos del Sistema de salud son finitos y la sostenibilidad de las instituciones que prestan servicios de salud se hace cada día con mayor dificultad, se requieren Sistemas de Información que apoyen administrativa y clínicamente la gestión de las Instituciones de Salud para alcanzar la eficacia, eficiencia, equidad y sostenibilidad en aras de conseguir su objeto social.

En la actualidad, cumplir con el Derecho Universal a la Salud es una tarea que no sólo involucra al área médica, sino también al área tecnológica, ya que a través de las tecnologías de información se pueden mejorar los procesos de atención en salud, como lo mencionó la directora de la Organización Panamericana en 2013, Carissa Etienne: “Las Tecnologías de la Información y la Comunicación (TIC) aplicadas a la salud mejoran el acceso a estos servicios, así como su eficiencia y calidad.”

Con el desarrollo y adopción de las tecnologías de información, por parte de las IPS, las Historias clínicas han evolucionado desde el registro tradicional en papel a robustos Sistemas de Información en Salud, considerados de misión crítica y de alta disponibilidad, que permiten atender las necesidades actuales en materia de salud no solo al mejorar los procedimientos de atención a los paciente y sus procesos de referencia, sino también al proporcionar datos estadísticos veraces y a tiempo para la evaluación de las condiciones de salud y por ende, permitan la toma de decisiones oportunas como la distribución de los recursos humanos, infraestructura y materiales.

A nivel mundial, se espera que solo la implementación de Sistemas de Información en Salud como los Expedientes Médicos Electrónicos (EHR, Electronic Health Records) represente un ahorro para el sector global de la salud de US$78.000 millones entre 2014 y 2019, según Juniper Research. La implementación de los EHR tiende a mejorar la atención y la seguridad del paciente: Las organizaciones informan aumentos en la colaboración de los médicos y reducciones en los errores médicos. Una encuesta de Healthcare Information and Management Systems Society en 2016 reveló que 83% de las organizaciones con entornos de EHR avanzados informan mejoras en la calidad del desempeño del personal clínico.

Al mismo tiempo que los pacientes se sienten más cómodos con las nuevas tecnologías y las organizaciones buscan controlar los costos, los gastos en TI están aumentando y los proyectos se están multiplicando. Se espera que el mercado mundial de salud digital, valorado en 76.723,8 millones de dólares en 2015, crezca calculando una tasa anual compuesta de crecimiento (CAGR) de 21.0% durante 2016-2022 [19]. Se espera que el segmento mHealth del mercado mundial de la salud digital sea el más rápido crecimiento, un CAGR de 34.0% durante el período de pronóstico, ya que las organizaciones buscan el beneficio para los pacientes y los resultados finales, esto supondrá un mercado de salud digital global de US$233.300 Millones proyectado del para 2020, en comparación con US$60.800 millones en 2013 y US$6.000 Millones Ahorros anuales estimados en Estados Unidos debido a la amplia adopción de la tecnología de tele salud [18].

El mercado mundial de la salud digital está creciendo a un ritmo significativo, debido a la creciente demanda de sistemas avanzados de información de salud, y la creciente inversión por parte de los profesionales de la tecnología de la información de salud. La creciente necesidad de servicios de monitoreo remoto de pacientes, el aumento del apoyo de las organizaciones gubernamentales y la creciente demanda de tecnologías de mHealth también están impulsando el crecimiento del mercado digital de salud digital.

Greg Maudsley, Director de Proyecto Senior en BreastScreen Victoria (BSV), con sede en Carlton, Australia, comentaba que su institución patrocinó un proyecto de gestión de expedientes electrónicos de cinco años, que se lanzó en 2013. Su objetivo era simple: lograr que BSV dejara de utilizar papel para 2018. Para mayo de 2016, 30% de los pacientes reservaban citas en línea y 40% recibía documentos por correo electrónico, como consentimientos informados o resultados de biopsias, lo que se tradujo en un ahorro anual por concepto de franqueo de más de U$75.000 [18].

5. Que Debemos Considerar Al Desarrollar Sistemas De Información En Salud

Desde que en 1973, la OMS definiera los Sistema de Información en Salud como “una estructura para la recogida, procesamiento, análisis y transmisión de la información necesaria para la organización y funcionamiento de los servicios de salud, así como para la investigación y la docencia” su definición, contexto y requerimientos han venido evolucionando; organizaciones como el Instituto de Medicina (IOM) de EE.UU, la Health Information Management System Society (HIMSS) o la organización Health Level 7 (HL7) han presentado periódicamente reportes sobre los componentes o subsistemas necesarios para los sistemas de información en Salud. Por ejemplo HIMSS provee una clara definición, atributos y requerimientos esenciales de una EHR (Handler y otros, 2003) [21].

Por su parte HL7 público en noviembre de 2009 la Norma ISO/HL7 10781:2009 Electronic Health Record- System Functional Model, Release 1.1 (EHR-S FM) que provee un listado exhaustivo de funciones que pueden estar presentes en un sistema de EHR (Dickinson, Fischetti y Heard, 2004). El listado está organizado con base en la perspectiva de los usuarios (profesionales de la salud) y a través de la creación de Perfiles Funcionales (PF). El EHR-S FM permite una descripción estandarizada de las funciones por nivel de atención (internación, ambulatorio, emergencia), por usuario y por dominio, entre otros. Los PF posibilitan crear un perfil de funcionalidades del EHR-S FM para un objetivo concreto y decidir, con base en dicho perfil, qué funcionalidades debe brindar.

Como veíamos, los últimos años la necesidad de los EHR ha pasado de ser la simple digitalización del registro médico para convertirse en un sistema integrado de información diseñado para gestionar todos los aspectos clínicos, administrativos y financieros de un hospital integrando múltiples sistemas existentes (o componentes) compartiendo información en un repositorio centralizado, como resultado se espera un sistema de información que permita la Gestión de Información de los eventos clínicos, el Manejo de Órdenes médicas y de sus Resultados [12], se requieren Sistemas de Soporte para la toma de decisiones apoyados en Procesos Administrativos [13], Sistemas de Comunicación Electrónica y Soporte al Paciente [14] con el fin de mejorar la prestación de servicios, optimizar el flujo de trabajo, reducir la ambigüedad y mejorar la transferencia de conocimientos entre todas las partes interesadas, incluidos los proveedores de salud, los organismos gubernamentales, la comunidad de proveedores, y pacientes. Además, permita obtener estadísticas generales de pacientes, datos epidemiológicos, de salud laboral y salud pública, entre otros [15].

Desde el punto de vista clínico debe ser posible: el continuo asistencial de la atención, aportando orden y uniformidad de los documentos; información legible, inalterable y disponible y, por lo tanto, accesible; La integralidad de información respecto a la atención, la integración de actividades preventivas, La toma de decisiones según problemas, La evaluación de calidad del servicio y la gestión del conocimiento para actividades como la docencia y la investigación, respetando la intimidad de las personas y garantizando la confidencialidad de su información, finalmente sirviendo como instrumento único y transversal del equipo de salud.

Teniendo en cuenta lo anterior, si deseamos implementar un sistema de información debemos considerar que existe una gran cantidad de estándares a utilizar, entre los que se puede citar aquellos orientados al intercambio de datos y mensajería electrónica, de terminología, de documentos, conceptuales, de aplicaciones y, por último, de arquitectura (Kim, 2005) [22]., y se hace necesario, desde el punto de vista técnico, conocer los Estándares publicados por el Comité Técnico de ISO sobre informática médica (Technical Committee : ISO/TC 215 Health informatics) como el Modelo Funcional para Sistema de Registro de Salud Electrónico (ISO/HL7 10781:2009 Electronic Health Record - System Functional Model) [3], el Estándares de intercambio de datos (ISO/HL7 27932:2009 Data Exchange Standards - HL7 Clinical Document Architecture, Release 2) [4], los Requisitos para una arquitectura de registro de salud electrónica (ISO 18308:2011 Health informatics - Requirements for an electronic health record architecture) [2], los perfiles propuestos por la Integrating the Healthcare Enterprise (IHE) [24], incorporar servidores de terminología como SNOMED-CT es el más completo y preciso del mundo, propiedad y distribuido por SNOMED International.

Ya que el propósito primario de la EHR es proveer un registro documentado de la atención médica que apoya las decisiones médicas presentes y futuras de los mismos u otros médicos. Cualquier otro propósito para el que el EHR es utilizada es considerado secundario, como ser: facturación, políticas y planeamiento, análisis estadístico, autorizaciones, etc. el equipo de desarrollo siempre deberá estar acompañado por personal asistencial que sienta que el sistema está desarrollado para ellos, La complejidad del desarrollo para salud y el dominio del mismo trae como consecuencia que los requisitos sean documentados de forma incompleta o incorrecta, debido a que la especificación de requisitos se realiza en base a lo que el personal de ingeniería entendió conforme lo que el equipo clínico le explicó. Esta “interpretación” aumenta los errores en los requerimientos y potencialmente el tiempo de retrabajo en etapas posteriores para corregir estos problemas. Además, se debe dedicar mucho tiempo para entender lo que quiere o necesita el profesional de la salud, lo que puede causar molestia en los profesionales sanitarios, o incluso llega a desanimarlos por que el equipo de desarrollo está lejos de mostrar los resultados que esperan. Al mismo tiempo hay que considerar que estos profesionales tienen un tiempo muy limitado para dedicarle al proceso de análisis y en general no perciben ningún retorno a cambio de su tiempo. [25]

Como sostiene el Dr. Suresh Sarojani, Director de Tecnología, HCL Avitas, Noida, India, La integración de personal clínicos en el núcleo de los proyectos hace más que solo atender las necesidades de los usuarios. También ayuda con la gestión general de los interesados (pacientes, personal clínico y administración). “Con frecuencia en proyectos de TI, las personas sienten que un proyecto se está haciendo para ellas, pero cuando tienen a alguien en el proyecto que representa sus intereses, los interesados tienen la sensación de que el proyecto se está haciendo con ellos. Eso hace que sea más probable que adopten la tecnología una vez que se haya implementado”. Además, permitirá que el alcance del desarrollo de estos sistemas no se corrompa por necesidades puntales de un médico o especialidad en particular, pues el mayor desafío es asegurar que una vez que se implemente el EHR, realmente se utilice [18].

6. Consideraciones a tener en cuenta basadas en la experiencia.

Sea cual fuere la metodología de desarrollo que se emplee en la implementación del software hay algunas consideraciones a tener en cuenta

6.1 El comité de Producto

El desarrollo de un Expedientes Médicos Electrónicos, indiferente al nivel de complejidad de la unidad de salud donde se pondrá en operación, tiene como origen de sus requerimientos el entorno normativo del país para el cual se desarrolla, las expectativas del mercado y los procesos de innovación resultantes de la apropiación de estándares tanto de fabricación como del entorno en que se empleara el sistema; en menor medida están los requerimientos detectados durante la fase de implementación del sistema.

Por tal motivo las empresas deberán constituir un organismo de gobierno del producto, el comité de producto, integrado por un grupo interdisciplinario de interesados (Stakeholders) formalmente constituido que se reúne periódicamente para analizar, evaluar, aprobar, priorizar o rechazar los requerimientos que se quieren implementar en las próximas versiones o Releases del producto. En este comité deberían tener presencia los representantes comerciales y de operación de la empresa pues ellos presentan las necesidades recogidas directamente desde el cliente o resultantes de procesos de benchmarking, deberá tener representación el equipo de producto encargado de observar y proponer nuevas funciones o adaptaciones para cumplir con los requerimientos normativos así como las necesidades que la aplicación de nuevas tecnologías o estándares de la industria debe tenerse en cuenta, la alta gerencia de la empresa presentando la visión de hacia donde deberá llevarse o donde interesa posicionar el producto y finalmente un grupo de representantes de los clientes, pues involucrarles en el desarrollo garantizara una visión más próxima al usuario final, de esta manera el comité de producto conjuga las diferentes visiones que pudieran tenerse sobre el producto.

6.2 Equipo de Producto

El desarrollo de un Expediente Electrónico, por su complejidad y tamaño, deberá ser responsabilidad de un equipo Integrado por analistas funcionales y técnicos y expertos del dominio (usuarios finales), encabezado por el Gerente o líder de producto (Product Owner, si hablamos de SCRUM), pues una única persona no podrá contemplar todos los requerimientos que el proceso de atención asistencial y administrativo de las unidades de salud contempla, ni considerar las necesidades de capacitación requiere la implantación del sistema. El equipo de producto deberá registrar todas las decisiones y recomendaciones que se generan al interior del comité de producto, y a partir de estas construir la hoja de ruta (Roadmap) del producto con los objetivos a corto y largo plazo, proyectando las fechas aproximadas en las cuales se espera finalizar cada paquete de nuevas funcionalidades, estas necesidades a su vez se traducen en Historias de Usuario que el equipo de producto incorpora al lista de requerimientos (Product backlog), este listado se revisa periódicamente, para Clasificar los requerimientos según el tipo de mantenimiento y Priorizarlos de acuerdo a la importancia de implementación.

6.3 Hoja de ruta e iteraciones

La hoja de ruta, Roadmap en inglés, es quizá uno de los elementos de planeación más importante y que toda empresa deberá construir para proyectar el producto que desea implementar, esta hoja de ruta alinea la visión tanto de la empresa y sus objetivos estratégicos, y permite aterrizar estos objetivos a través de sus planes tácticos, que definen un conjunto de metas más pequeñas (hitos), y sus fechas de consecución conocidas generalmente como milestone, por su nombre en inglés. El roadmap deberá estar versionado, de forma se describa el conjunto de funciones que deberán incluirse para cada hito, ya que permite al equipo de desarrollo y a la empresa en general tener una idea entre el estado actual del producto y el futuro, permitiendo una mejor interpretación visual de nuestro producto y sus diferentes versiones a liberar.

Este roadmap deberá revisarse periódicamente quizá de manera trimestral o semestral, y tener un alcance de al menos un par de años, pues esta proyección permite la planeación futura de la empresa respecto a la necesidad de personal, recursos financieros y en general de los proyectos de desarrollo que emprenda la empresa, además de ser una herramienta efectiva de ventas. El roadmap permite al equipo de producto definir que requerimientos deberán ser entregados al equipo de desarrollo (Development Team) para su revisión y a partir de allí construir su listado de requerimientos de la iteración (Sprint Backlog) y a su vez informar a los interesados para que versión del producto se espera tener liberados los requerimientos recibidos.

Un equipo de desarrollo o una empresa de tecnología sin un roadmap pueden perderse en el día a día y fácilmente olvidar su visión de futuro, es como tener un mapa sin una brújula y peor aún sin un azimut.

6.4 Comité de control de Cambio

La experiencia ha indicado que a pesar de hacer las reuniones diarias (Daily Scrum) con el equipo de desarrollo y una comunicación directa y frecuente con los líderes de los diferentes procesos comprometidos con la implementación de los requerimientos, y a pesar de conocer la velocidad de tus diferentes equipos (producto, desarrollo, pruebas) la planeación de las iteraciones se ve de una u otra manera afectada por imponderables que impactan en el progreso de la misma, por esta razón se hace necesario que al menos una vez por semana el gerente del proyecto convoque una reunión de revisión del avance de las iteraciones y evaluar el progreso en cada una de ellas, la medición del trabajo realizado (burndown) permite por ejemplo hacer el seguimiento a los acuerdos alcanzados durante la reunión de planeación del sprint, identificar posibles riesgos en el cumplimiento de las fechas de entrega, identificar que tan grande es la desviación de la ejecución respecto a la planeación, identificar posible riesgos y en algunos casos tomar la decisión de reducir el tamaño del listado de requerimientos incluidos en la iteración o incluso cancelar la iteración. Esta reunión por la general será cita y liderada por el gerente del proyecto (project manager).

6.5 Células de Desarrollo

Si bien las metodologías como Scrum proponen que el equipo de desarrollo no deberá tener menos de 3 integrantes y máximo 9, la experiencia indica que el mejor resultado lo alcanzamos implementando células de desarrollo integradas por 2 desarrolladores y 1 tester, pues a medida que se va haciendo la integración continua de los requerimientos liberados, el tester podrá ir adelantando las pruebas individuales de estos, una vez todos las células entregan sus requerimientos y se da por terminada la iteración el equipo de pruebas en pleno podrá realizar pruebas de regresión sobre toda la versión liberada. En la planeación y ejecución de la iteración podrán participar entre 1 y 3 células de desarrollo, tener más de 3 requiere demasiada coordinación, incrementa el riesgo de incumplimiento y aumenta el porcentaje de errores debido a la integración de las fuentes que realizan las células al proyecto de desarrollo.

7. Conclusiones

El CORE de las instituciones de Salud es la prestación de servicios para el cuidado, recuperación o promoción de la salud o aseguramiento de la población, por tanto la primera necesidad de un EHR es el registro de documentado de la Atención médica, en consecuencia el desarrollo del sistema de información debe considerar al personal clínico asistencial como un factor muy importante y clave del éxito del proyecto pues los médicos, enfermeras, técnicos son quienes poseen el conocimiento, son los expertos del dominio.

El componente humano de los proyectos de desarrollo, tanto en salud como en otros sectores, es un factor muy importante, determina si el proyecto será exitoso o si por el contrario fracasa, un equipo emocionalmente maduro, que se siente apoyado e implicado en la toma de decisiones o en el proceso de toma de información resulta clave para estimular al equipo y lograr el éxito del proyecto.

Los proyectos que adoptan y aplican metodologías agiles en sus procesos de desarrollo tiene una mayor probabilidad de ser exitosos, independientemente de su tamaño, y culminar los proyectos cumpliendo las metas inicialmente establecidas además satisfaciendo las necesidades empresariales para los que son desarrollados, a la vez que se finalizan dentro del presupuesto y tiempo estimados.

Una comunicación deficiente, o la falta de información, genera corrupción del alcance afectando directamente la gestión de los requisitos, confluyendo en el fracaso de la mitad de los proyectos; además si las organizaciones no utilizan un proceso formal o no disponen de los recursos necesarios para desarrollar las tareas necesarias que aseguren la validación de los requerimientos el porcentaje de probabilidad de fracaso se incrementa.

Un solo estándar no será suficiente para el desarrollo del sistema de sistema de información, quizá sea necesario tomar lo mejor de cada uno y amalgamarlos de tal manera que cumplan la necesidad especifica que queremos atender, ya sea para representar la información clínica o compartirla a través de la interoperabilidad, de esta manera la tecnología actúa como un soporte transversal a toda organización, diseñando, construyendo y operando sistemas que facilitan la interacción paciente - institución, estamos contribuyendo a salvar vidas.

Referencias

Ministerio de Salud de Colombia, http://www.hospitalfernandotroconis.com,[En línea]. Available: http://www.hospitalfernandotroconis.com/wp- content/uploads/2015/03/RESOLUCI%C3%93N-3374-DE- 2000.pdf. [Último acceso: 9 Abril 2017].

International Organization for Standardization, «ISO 18308:2011 Health informatics -- Requirements for an electronic health record architecture,» 2011.

International Organization for Standardization, «I 10781:2009 Electronic Health Record-System Functional 2009.

International Organization for Standardization, «I 27932:2009 Data Exchange Standards -- HL7 Clinical D Architecture,» 2009.

Project Management Institute, «Pulse of the Profession T Cost of Low Performance,» 2014.Ministerio de Salud de Colombia, «Secretaria del Diciembre 1993. [En línea]. A http://www.secretariasenado.gov.co/senado/basedoc/ley_01.html. [Último acceso: 8 Abril 2017].

S. Hastie y S. Wojewoda, «https://www.infoq.com,» 4 2015. [En línea]. A https://www.infoq.com/articles/standish-chaos-2015. acceso: 18 Abril 2017].

M. A. Hernandez, «El tiempo.com,» 10 Febrero 2014. [E Available: http://www.eltiempo.com/archivo/documen 13480380. [Último acceso: 8 Abril 2017].

World Economic Forum, «The Global Information Tec Report,» 2016.

Organización Mundial de la Salud, «Informe sobre la sal mundo: LA FINANCIACIÓN DE LOS SISTEMAS DE S 2010.

Banco Interamericano de Desarrollo BID, «Planes de bene salud de América Latina: Una comparación regional,» 2014.

Health Level 7, «ANSI. HL7 EHR-System Functional Release 1.1 July 18, 2012. Chapter 3: Direct Care Functions

Health Level Seven Internacional, «ANSI. HL7 EHR Functional Model, Release 1.1 Chapter 4: Supportive Fu 2012.

Health Level Seven Internacional, «ANSI. HL7 EHR Functional Model, Release 1.1. Chapter 5: Inf Infrastructure Functions,» 2012.

Health Level Seven Internacional., Health Level Seve Internacional., [En línea]. A http://www.hl7.org/about/index.cfm?ref=common. [Último 21 Abril 2017].

Observatorio TI, «http://observatorioti.co,» 2016. [En Available: http://observatorioti.co/k_course/deficit-de-profe en-el-sector-ti-proyectado-a-10-anos/. [Último acceso: 1 2017].

Observatorio TI, «Informe De Caracterización Del Se Software Y Tecnologías De La Información En Colombia,»

M. Alderton, «Receta para el Futuro,» PM Network, Agosto

psmarketresearch, «Global Digital Health Market Size Development, Growth and Demand Forecast to 2022,» 2016

Ministerio de Salud de Colombia, «www.secretariasenado.30 Marzo 2017. [En línea]. A www.secretariasenado.gov.co/senado/basedoc/ley_1438_20 [Último acceso: 8 Abril 2017].

T. Handler y y. otros, «HIMSS Electronic Health Definitional Model Version 1.1:,» HIMSS, 2003.

K. Kim, «Clinical Data Standards in Health Care: Fi Studies.,» Oakland, CA:, 2005.

D. G, F. L y H. S, «HL7 EHR System Functional Model 2004.Integrating the Healthcare Enterprise (IHE), «https://www. Integrating the Healthcare Enterprise (IHE), [En línea]. A https://www.ihe.net/Profiles/. [Último acceso: 21 Abril 2017

P. P. Gutiérrez, «Curso de openEHR en español,» 2016.

The Standish Group, «Chaos Report,» 1995. [En línea]. A https://www4.in.tum.de/lehre/vorlesungen/sw/SS2004/files/ andish_Chaos.pdf. [Último acceso: 10 04 2017].