Medicina de precisión basada en los datos

Desde hace unos años se promueve el concepto de medicina de precisión o, también, medicina personalizada para referirse a la adaptación de los tratamientos médicos a las características individuales de cada paciente. El modelo requiere el desarrollo de capacidades para clasificar a la población en subconjuntos de individuos susceptibles de padecer una determinada enfermedad o de su reacción a un determinado tratamiento y en el diseño de actuaciones preventivas, de diagnóstico o de curación enfocadas a estos grupos. «Se trata de proporcionar el tratamiento adecuado al paciente adecuado en el momento adecuado» (the right treatment to the right patient at the right time»,  como dice Larry Chu, un asesor del presidente Obama en la iniciativa de Medicina de Precisión, anunciada en 2015,  que ahora comienza a dar sus primeros frutos y a la que nos referíamos en la entrada anterior.  El proyecto incluye la recogida de datos de un millón de americanos voluntarios de diferentes características y su seguimiento a lo largo de diez años. Estas características no son sólo genéticas, sino también ambientales o de estilo de vida, además de su historial de salud. De igual forma, medicina de precisión no sólo quiere decir la robótica, la automatización o el diseño de nuevas drogas (aunque el instituto de innovación fundado por Clayton Christensen considera que el gasto en tratamientos equivocados es equivalente al gasto en investigación farmacéutica). Otros datos señalan la enorme variabilidad de las actuaciones médicas y de su adecuación en procesos muy comunes, como la depresión, la gripe, la neumonía, la hepatitis, las enfermedades respiratorias crónicas o los problemas coronarios. No se trata sólo ni principalmente de gasto...

Usos avanzados de la Inteligencia Analítica en Sanidad

En su introducción al compendio Analytics in Healthcare and the Life Sciences, Dwight McNeill, llama la atención sobre la ironía que representa que, en un sector fundado en la investigación masiva sobre el origen y el tratamiento de las enfermedades y donde los profesionales son gente bien formada y entrenada, la cultura de los datos no está bastante extendida ni entre los clínicos ni entre los gestores. Hace unos años, el famoso estudio de McKinsey sobre Big Data en Sanidad también mostraba la disparidad entre el potencial y la realidad. En la adaptación del modelo Delta de madurez analítica que ha hecho Tom Davenport con el HIMSS, la mayoría de los hospitales se sitúa en el estadio 2 de 5, o sea el de la inteligencia de negocio localizada en los informes financieros y de actividad. [gview file=»http://informatica.blogs.uoc.edu/wp-content/uploads/2018/12/Usos-avanzados-BI-en-sanidad.pdf»] Fuente: Cortesía de Althaia Xarxa Assistencial de Manresa, a partir de Jason Burke (2013) He trabajado en los últimos años con varios grupos sanitarios y nos ha costado casi siempre encontrar ideas, proyectos y liderazgos que vayan más allá del reporting tradicional, de la epidemiología clásica o de problemas operativos que se resuelven mejor con los sistemas de gestión transaccionales (los ERP, ciertamente, no son muy inteligentes y entonces es lo que pasa). Nos referimos a todo ésto en un post anterior. Es verdad que las cosas van mejorando. Quizá el modelo teórico basado en «estadios», que conduce a la melancolía, deba superarse. Por ejemplo, a partir del marco de trabajo formulado por Jason Burke, que fue el líder de SAS para el sector sanitario y uno de los mayores expertos en esta materia,...

Modelos de agilidad en escala

Scrum es probablemente la aplicación más conocida de los principios de agilidad en la construcción de software y en otros ámbitos de conocimiento y de práctica. De hecho, scrum nació a finales de los 80 en el mundo del marketing y del desarrollo de producto. En TI, algunos de los fundadores de scrum fueron parte del grupo que publicó el Manifiesto Ágil. La idea es conocida: cada incremento o mejora de producto (product increment) se puede descomponer en ciclos de desarrollo menores (sprints) de los que se ocupa un equipo pequeño de participantes de diferentes procedencias, incluido el cliente, situados en el mismo espacio físico y dedicados de forma intensa y entusiasta. El despliegue es incremental e iterativo y el resultado siempre es imperfecto, pero se puede poner en producción rápidamente. Algun0s otros artefactos y roles de scrum, como el product owner, el backlog, las reuniones cortas diarias, el scrum master, las retrospectivas y los papelitos pegados en una pizarra forman parte ya del instrumental de la producción de sotware en cualquier parte. Presentación a alto nivel de los artefactos de SAfe Scrum funciona bien en esfuerzos donde el alcance es abierto y los requerimientos pueden cambiar frecuentemente. Va mejor con equipos y proyectos no muy grandes y que no requieran un gran número de interdependencias o integración con otros proyectos o con aplicaciones heredadas (legacy). Funciona mejor con perfiles relativamente homogéneos de desarrolladores acostumbrados a trabajar así. Es una organización muy plana, sin jerarquías ni grandes especialidades. Requiere  una cultura organizativa propicia y tiene una curva de aprendizaje, pero no es dramático. Puede ser bonito, excitante, divertido y los resultados, en general y bajo las condiciones anteriores, pagan. En las circunstancias que hemos descrito, scrum se...

Los productos de TI en la era digital (y II)

El proyecto no ha muerto. Ágil lo ha cambiado todo. La combinación de Ágil y Lean permite potencialmente escalar la agilidad desde proyectos pequeños y auto-contenidos al nivel de la organización de los departamentos de informática y de toda la empresa. A introducir estas ideas dedicamos la primera parte de este post. Seguimos ahora.     7. Los departamentos de TI construyen y mantienen productos y servicios, que sirven a las necesidades de grupos de clientes internos o externos. Esos chismes son flujos de creación de valor para diferentes negocios o procesos empresariales. La creación de un nuevo producto o la sustitución por entero de uno existente tiende a ser un proyecto, pero eso pasa sólo algunas veces. Se podría decir que un proyecto es una parte de un flujo de producción o, a veces, un flujo de producción en sí mismo. El flujo de creación de valor representa la transformación de unas necesidades, convenientemente priorizadas, en unos productos para unos clientes. El flujo de producción tiene que asegurar: 1) el conocimiento y la comprensión profunda de las necesidades muy variadas de un cliente (qué hay que hacer), 2) su valoración y cualificación estratégica y económica (por qué hay que hacerlo y por qué haremos ésto en vez de otra cosa), 3) el diseño, construcción y aprobación del producto de acuerdo con las capacidades existentes (cómo y cuándo lo haremos), 4) la entrega y puesta en producción en todo o en partes y 5) el mantenimiento y protección de los activos creados. 8. Desde un punto de vista, este proceso se puede ver como una máquina, una fábrica, una cadena de...

Los productos de TI en la era digital (I)

Mis posts veraniegos sobre el ocaso de la gestión de proyectos, deliberadamente provocadores, se leyeron bastante y se copiaron en las redes. Lectores y colegas no mostraron desacuerdo, pero me pidieron aclaraciones y avenidas de solución: then, what? Como Hamlet, vivo en las preguntas y tengo más dudas que respuestas. Pero voy a intentar en este y otros posts compartir lo poco que sé o que sabemos, a partir de la experiencia y la literatura profesional y científica. Los proyectos siguen teniendo sentido. Son la mejor, probablemente la única, manera de hacer cosas diferentes de las que hacemos cada día, de poner en tensión la organización para construir cosas nuevas, únicas y transformadoras, que tengan sentido estratégico y económico, rompiendo los silos organizativos. Necesitamos organizaciones orientadas, apasionadas por los proyectos. Necesitamos también modelos, herramientas y profesionales expertos en proyectos. Podemos pasar de cofradías, burocracias y certificaciones, pero no podemos prescindir de gente con la mano rota de reunir personas y capacidades diferentes y hacer que trabajen juntas para construir puentes, fábricas de coches o productos de software. Ni podemos prescindir de lo que hemos aprendido en casi un siglo de práctica profesional. Ágil lo cambió casi todo. Ágil, que pronto cumplirá treinta años, ni es ni se pensó como un modelo integrador y sistemático para construir programas y mucho menos para gestionar proyectos, sino como un repositorio de ideas, principios y prácticas inventados por los propios desarrolladores para hacer su trabajo (¡desarrollar software!) más efectivo, valioso y divertido. Los valores y principios de ágil han impregnado (para bien) la gestión de proyectos, en la informática y en la empresa....