El primer modelo predictivo en atención sanitaria parecía un jonrón.
Respondió a la pregunta empresarial. Las métricas de desempeño fueron sólidas. La lógica era clara.
También habría fracasado espectacularmente en producción.
Esa lección cambió mi forma de pensar sobre la ciencia de datos y lo que se necesita para tener éxito en la atención médica en la era de la IA.
Mirando hacia atrás, ese fracaso se repetiría a lo largo de mi carrera, pero fue crucial para mi crecimiento y éxito como científico de datos: un modelo complejo en un cuaderno no vale nada si no comprendes el entorno al que está destinado tu modelo.
Analista de datos
Después de tres meses agotadores buscando mi primer trabajo en el mundo real, en un mercado con un nuevo apetito por los datos pero que también rebosaba talento, finalmente tuve mi primera gran oportunidad. Conseguí un puesto de analista de datos de nivel básico en el equipo de inteligencia empresarial de un gran sistema hospitalario. Había mucho que aprender. Un obstáculo enorme, que muchas personas que quieran ingresar al ámbito de los datos de atención médica también tendrán que superar, fue familiarizarme con los entresijos de Epic, el mayor proveedor de EHR (registros médicos electrónicos) por participación de mercado. Estirar mis piernas en SQL con datos extremadamente complejos en un EHR no fue tarea fácil. Durante los primeros meses, dependí de mis compañeros de trabajo superiores para escribir el SQL que necesitaría para el análisis. Esto me frustró; ¿Cómo podría haber terminado una maestría en estadística y todavía estar luchando por adoptar la mentalidad SQL?
Bueno, con práctica (mucha práctica) y paciencia de mis compañeros de trabajo (mucha paciencia), finalmente todo empezó a tener sentido en mi cabeza. A medida que mi comodidad fue creciendo, me sumergí en el mundo de Tableau y los paneles. Me fascinó el proceso de crear paneles estéticamente agradables que contaran historias de datos que necesitaban desesperadamente ser contadas.
Durante mi primer año, mi gerente me brindó un gran apoyo, me contactó periódicamente y me preguntó cuáles eran mis objetivos profesionales y cómo podía ayudarme a alcanzarlos. Sabía que mi experiencia en la escuela era más técnica que los análisis ad hoc que estaba haciendo como analista de datos de nivel básico, y que quería crear modelos predictivos. En un final agridulce de mi primer capítulo, ella se ofreció a transferirme a otro equipo para brindarme esta experiencia. Ese equipo era el equipo de Análisis Avanzado. Y yo iba a ser científico de datos.
Científico de datos I
Desde el primer día, trabajé estrechamente con un gurú de la ciencia de datos que tenía un profundo conocimiento de la atención médica y las capacidades técnicas correspondientes, lo que le permitía ofrecer productos increíbles y allanar el camino para nuestro pequeño equipo. Fue el primero en nuestro sistema en desarrollar un modelo predictivo personalizado y ponerlo en funcionamiento en el entorno de producción, generando puntuaciones de los pacientes en tiempo real. Estas puntuaciones se utilizaban en flujos de trabajo clínicos. Cuando mi gerente me preguntó cuáles eran mis objetivos profesionales para el próximo año, tuve una respuesta inmediata y segura: quería poner en producción un modelo predictivo personalizado.
Comencé con algunas POC (pruebas de concepto). Mi primer modelo fue un modelo de regresión logística lineal que intentaba predecir la probabilidad de complicaciones de la diabetes. Si bien fue un buen primer intento, mi enfoque de muestreo de datos estuvo completamente equivocado y, en la revisión por pares, mi colega lo señaló. Una de las lecciones clave que aprendí de mi primer intento de crear un modelo predictivo en atención médica fue
Al recopilar datos para entrenar un modelo predictivo, es fundamental imitar las condiciones, el contexto del paciente y el flujo de trabajo en el que se utilizará el modelo dentro del entorno de producción.
Un ejemplo de esto: no puede simplemente recopilar los valores de laboratorio actuales de cada paciente y usarlos como características en su modelo. Si espera que el modelo haga predicciones, digamos 15 minutos después de llegar al servicio de urgencias, debe tenerlo en cuenta. Por lo tanto, al recopilar dos años de datos históricos para entrenar un modelo, es necesario recopilar los valores de laboratorio de cada paciente tal como existían 15 minutos después de su llegada, es decir, en el momento de la fecha y hora de predicción simulada, no cuáles son esos valores de laboratorio hoy/actualmente. No hacerlo crea un modelo que puede funcionar mejor en POC que en entornos de producción en tiempo real, porque le está dando al modelo acceso a datos que no tendría disponibles en el momento de la predicción, un concepto conocido como fuga de datos.
Lección aprendida, estaba listo para intentarlo de nuevo. Pasé las siguientes semanas desarrollando un modelo para predecir las ausencias a las citas. Fui muy intencional en la forma en que recopilé datos, utilicé un algoritmo más robusto y poderoso, XGBoost, y una vez más llegué a la etapa de revisión por pares. El AUC (área bajo la curva característica operativa del receptor) del modelo fue asombroso, se situó en los bajos 0,9 segundos y superó las expectativas de todos sobre un modelo que no se presentó fuera del agua. Me sentí imparable. Entonces todo se vino abajo. Durante una inmersión profunda en el desempeño sorprendentemente sólido, noté que la característica más importante era la hora programada para la cita. Si se elimina esa característica, el AUC cayó a mediados de 0,5, lo que significa que las predicciones del modelo prácticamente no fueron mejores que las conjeturas aleatorias. Para investigar este extraño comportamiento, salté a SQL. Ahí estaba. Dentro de la base de datos, cada paciente que no se presentó a su cita también tenía una cita programada para la medianoche. Algunos procesos de datos cambiaron retrospectivamente la hora de la cita de todos los pacientes que nunca completaron su cita. Esto le dio al modelo una característica casi perfecta para predecir las ausencias. Cada vez que un paciente tenía una cita a medianoche, la modelo sabía que ese paciente no se presentaba. Si este modelo llegara a producción, estaría haciendo predicciones semanas antes de las próximas citas y no tendría esta característica mágica para mejorar su rendimiento. La filtración de datos, mi archienemigo, volvió a perseguirme. Intentamos durante semanas salvar el rendimiento utilizando ingeniería de funciones creativas, un conjunto de datos más grande para la capacitación, procesos de capacitación más intensivos, pero nada ayudó. Este modelo no iba a sobrevivir y estaba desconsolada.
Finalmente acerté. Mi primer gran éxito con un modelo predictivo también tuvo un nombre divertido: el modelo DIVA. DIVA significa Acceso Intravenoso Difícil. El modelo fue diseñado para notificar a las enfermeras cuando pueden tener dificultades para colocar vías intravenosas en ciertos pacientes y, en su lugar, deben comunicarse con el equipo de vías intravenosas para su colocación. El objetivo era reducir los intentos fallidos de vía intravenosa, con la esperanza de aumentar la satisfacción del paciente y reducir las complicaciones que podrían surgir de dichos fracasos. El modelo funcionó bien, pero no sospechosamente bien. Pasó la revisión por pares y desarrollé el guión para implementarlo en producción, un proceso mucho más difícil de lo que podría haber imaginado. Al equipo IV le encantó su nueva herramienta y el modelo se estaba utilizando en los flujos de trabajo clínicos de toda la organización. Logré mi objetivo de poner un modelo en producción y quedé encantado.
Científico de datos II
Tras la implementación exitosa de algunos otros modelos, me ascendieron a Científico de datos II. Continué desarrollando modelos predictivos, pero también dediqué tiempo a aprender sobre el mundo en constante crecimiento de la IA. Pronto, aumentó la demanda de soluciones de IA. Nuestro primer proyecto oficial de IA fue un desafío interno del departamento en el que emplearíamos modelos de lenguaje para resumir las publicaciones financieras de empresas que cotizan en bolsa de forma automatizada. Este proyecto, como la mayoría de los otros proyectos relacionados con la IA, era bastante diferente al típico desarrollo de modelos de ML al que estaba acostumbrado, pero la variedad fue bienvenida. Me divertí mucho sumergiéndome en el mundo de los procesos ETL, las indicaciones efectivas y la automatización. Si bien apenas nos estamos iniciando en las iniciativas de IA, estoy entusiasmado con los nuevos tipos de problemas comerciales para los que ahora podemos crear soluciones.
Mi papel como científico de datos ha evolucionado a medida que los sistemas de inteligencia artificial han mejorado. El desarrollo de soluciones DS/ML e IA requiere mucho menos esfuerzo de trabajo técnico ahora, y casi me considero en parte científico de datos y en parte gerente de proyectos de IA durante el proceso. Los sistemas de inteligencia artificial a los que tenemos acceso ahora pueden escribir código, realizar pruebas de errores y realizar ediciones de manera muy efectiva con indicaciones tácticas de nuestra parte. Dicho esto, existe una preocupación creciente sobre el impacto y la viabilidad de las iniciativas de IA, y varios informes sugieren que la mayoría de los proyectos de IA fracasan antes de entrar en producción. Yo creo
Un científico de datos con una sólida base técnica y experiencia en la materia puede ser el mayor activo para combatir la alta tasa de fracaso de los proyectos de IA.
Nuestra comprensión de los fundamentos de los modelos predictivos, junto con el conocimiento del dominio dentro de nuestras industrias (atención médica, en mi caso), sigue siendo muy necesaria para crear soluciones que sean efectivas y puedan proporcionar valor. Atrás quedaron los días en los que podíamos confiar únicamente en nuestra perspicacia técnica para aportar valor. La codificación ahora está a cargo de los LLM. La automatización es mucho más accesible con los proveedores de la nube. Lo que se necesita ahora es un experto que pueda traducir las necesidades del negocio en un plan estratégico que guíe a la IA hacia una solución eficaz. El científico de datos moderno es el candidato perfecto para ser ese traductor.
Concluyendo
La ciencia de datos, como ocurre con cualquier carrera profesional en tecnología, siempre está cambiando y evolucionando. Como puede ver arriba, mi rol ha cambiado mucho en los años transcurridos desde la universidad. He ascendido algunos peldaños en la escala corporativa, pasando de un analista de datos de nivel básico a un científico de datos II, y puedo decir con confianza que las habilidades necesarias para tener éxito han cambiado a medida que han pasado los años y se han logrado avances tecnológicos, pero es importante recordar las lecciones aprendidas a lo largo del camino.
Mis modelos fallaron.
Esos fracasos dieron forma a mi carrera.
En el sector sanitario, especialmente con la magia de la IA a nuestro alcance, un científico de datos exitoso no es aquel que puede construir los modelos más complejos.
Un científico de datos exitoso es aquel que comprende el entorno al que está destinado el modelo.