Presentado por MongoDB
Crear una IA precisa, segura y confiable es una gran hazaña de ingeniería para las organizaciones sujetas a obligaciones de cumplimiento que rigen la atención médica, los servicios financieros y el transporte. El desafío de ofrecer productos basados en IA se ve agravado por el hecho de que la tecnología en estos sectores tiende a quedar rezagada con respecto a otros sectores a medida que la regulación obliga a las organizaciones a actuar con cautela y lentitud. Hoy en día, muchos también se enfrentan a proyectos de modernización de la infraestructura de datos mientras intentan ponerse al día con la demanda actual de IA.
Heidi, un socio de AI Care fundado en Australia, ofrece un ejemplo de modernización exitosa. Su producto estrella, Heidi Scribe, ahora automatiza gran parte del trabajo administrativo que llena los días de los médicos en más de 190 países, respaldando aproximadamente 2,7 millones de interacciones con pacientes cada semana. Esta expansión se basa en decisiones de infraestructura tomadas años antes de que la empresa alcanzara escala global, afirma Yu Liu, cofundador y director de tecnología de Heidi.
«En la mayoría de las industrias, una característica de IA que es incorrecta el dos por ciento de las veces se considera un inconveniente, mientras que en la atención médica, esa misma tasa de error se convierte en un problema de seguridad clínica», dice Liu. «La arquitectura debe basarse en el supuesto de que cada resultado puede revisarse, auditarse y confiar en la atención del paciente».
Por qué la implementación de la IA de producción en el sector sanitario es arquitectónicamente diferente
Para Heidi, la residencia de datos es un requisito previo más que una característica. Un médico en Sydney, Londres, Tokio o Denver opera bajo diferentes regímenes regulatorios, incluidos los Principios de Privacidad de Australia, GDPR, APPI e HIPAA, y los datos de sus pacientes deben residir en la región.
Heidi gestiona implementaciones de producción totalmente aisladas de forma lógica en todo el mundo, por lo que la residencia es un mandato arquitectónico. La auditabilidad también debe incorporarse desde el primer día, porque una organización debe poder responder a lo que vio el modelo, lo que produjo y lo que el médico cambió, para cualquier sesión, meses después cuando se le solicite.
“Es necesario reducir el alcance del cambio”, afirma Liu. «En industrias menos reguladas, se pueden realizar envíos rápidos y repararlos, pero en el sector de la salud invertimos mucho en hacer que los cambios sean seguros de forma predeterminada, con puertas de integración continua en clases de edición riesgosas, lanzamientos canary y tratando incluso los cambios de índice y esquema de base de datos como código que pasa por revisión. Nuestra velocidad es producto de esa seguridad y no algo que logremos a pesar de ella».
Elija una base de datos para conectarse a los flujos de trabajo de IA
Heidi gestiona un conjunto diverso de datos médicos recopilados de múltiples fuentes, incluidos formularios, referencias y notas médicas, todos los cuales debían reunirse en un formato coherente y una única ubicación para conectarse sin problemas a los flujos de trabajo de IA. Las filas y columnas rígidas no habrían sido adecuadas para esta carga de trabajo.
Para Heidi, estos requisitos hicieron que una base de datos de documentos fuera la elección natural. MongoDB le dio al equipo la flexibilidad de adaptarse a los datos de IA que cambian rápidamente sin tener que remodelar constantemente la base de datos subyacente.
«El modelo representa quizás el 20% del sistema, y la arquitectura de datos es lo que determina si el 80% restante resiste la carga clínica real», afirma Liu.
Una sesión de AI Scribe no es un solo dato. Es una colección de transcripciones, notas estructuradas, plantillas, documentos, contexto del paciente, estado de integración del EHR y docenas de otros artefactos relacionados que cambian de una semana a otra. MongoDB permite que los datos de una sesión coexistan en formularios que coincidan con la forma en que los médicos realmente trabajan, y permite a Heidi evolucionar estos formularios sin congelar la migración cada vez que el producto se mueve.
Suscríbete y recibe las historias más importantes del día.
Al suscribirte aceptas nuestros términos y condiciones y política de privacidad.
«MongoDB Atlas se destacó porque combina el poder del modelo de documento, que permite escalabilidad, flexibilidad y alto rendimiento, con funciones integradas listas para IA, como MongoDB Vector Search», dice Liu. «Esto significa que Heidi no necesita otra base de datos de vectores complementaria para aumentar su plataforma existente».
Con más de 130 regiones de nube en todo el mundo, así como opciones locales e híbridas, MongoDB Atlas es la plataforma de base de datos distribuida globalmente más ampliamente disponible, y su API de consulta unificada permite a los desarrolladores crear búsquedas de texto completo, análisis en tiempo real y experiencias basadas en eventos sin complicar su arquitectura.
«Heidi Scribe convierte grandes volúmenes de documentos médicos en incrustaciones de vectores a través de LangChain en Atlas, lo que permite una búsqueda semántica que vincula directamente los términos médicos transcritos con el conocimiento externo correspondiente», añade Liu. «La migración a Atlas redujo la latencia de la API clave en casi un 33 %. »
Lo que requiere un sistema RAG clínico confiable
“La recuperación es un problema de arquitectura de datos antes que un problema de IA”, afirma Liu. «En Consumer RAG, se recupera de la web abierta y se tiene esperanza, mientras que en la atención sanitaria, lo que se recupera es la superficie de cumplimiento».
Heidi Evidence se basa en bases de conocimiento clínico acreditadas, incluidos socios como BMJ Best Practice, NICE CKS y MIMS, y tiene en cuenta las jurisdicciones, por lo que un médico del Reino Unido obtiene orientación del Reino Unido y un médico australiano obtiene formularios australianos, porque la respuesta correcta en un país puede ser la respuesta incorrecta en otro.
Las integraciones y los índices vectoriales de Heidi residen dentro de MongoDB Vector Search, dentro de las mismas implementaciones aisladas regionalmente que el resto de sus datos, lo que significa que la recuperación no puede cruzar físicamente un límite de residencia, ni operar una base de datos vectorial separada con su propio historial de seguridad y cumplimiento. Las citas son un contrato firme más que una sugerencia rápida porque el modelo sólo ve fragmentos recuperados que ya están vinculados a los registros fuente.
El aislamiento regional permite el cumplimiento y la escala global
«Cada región es una implementación de producción completa y aislada con sus propios clústeres MongoDB Atlas, su propia computación y su propia clave», afirma Liu.
«Esto es lo que nos permite acudir a un sistema sanitario estadounidense, a un fondo del NHS o a un grupo hospitalario australiano y dar una respuesta clara sobre la residencia, porque viene impuesta por la infraestructura y no prometida por contrato», explica. «La gestión de varias regiones aisladas con un equipo pequeño solo funciona porque la capa de base de datos está gestionada y es coherente. También somos multinube, lo que significa que una nueva región puede admitir otra implementación sobre los rieles que ya hemos creado. »
Esta arquitectura ha sido más visible en los Estados Unidos, donde Beth Israel Lahey Health, uno de los sistemas de salud más grandes de Nueva Inglaterra, implementó el escriba de IA de Heidi después de que un piloto revelara que el 74% de los médicos informaron una documentación reducida fuera del horario regular («tiempo de pijama»), y donde el sistema sin fines de lucro MaineGeneral Health eligió a Heidi como socio estratégico en su trabajo de atención médica rural.
“Ingresar al mercado estadounidense significó construir otra región sobre los rieles que ya habíamos construido en lugar de reajustarnos a HIPAA después del hecho”, dice Liu.
Lecciones aprendidas y hoja de ruta por delante
«Reparticionar una colección grande, activa y siempre activa es un programa de ingeniería serio, mientras que elegir una clave de partición el primer día es una reunión de diseño», afirma Liu. «Actualmente estamos haciendo este trabajo en asociación con MongoDB, pero la lección para cualquiera que cree un producto de IA con uso intensivo de datos es que el escalado horizontal para sus datos de más rápido crecimiento es una decisión fundamental, al igual que la residencia».
Heidi ahora va más allá de la nota de consulta para respaldar todo el flujo de trabajo clínico, desde el contexto previo a la visita hasta los documentos posteriores a la visita, las derivaciones y la automatización del flujo de trabajo. La compañía también está explorando cómo MongoDB, grandes modelos de lenguaje y sus propias herramientas pueden impulsar un ecosistema de agentes para flujos de trabajo clínicos.
«En la IA sanitaria, la ingeniería de confiabilidad es ingeniería de confianza», dice Liu. «La confianza de un médico se pierde tan rápidamente debido al tiempo de inactividad, la latencia o la inconsistencia de los datos como si fuera una calificación baja, y parte de nuestro trabajo más efectivo es invisible, incluidos los canarios de reversión, las puertas de CI en cambios de bases de datos y las comprobaciones de coherencia entre regiones. La confianza del médico es el producto, y la confianza es arquitectónica».
Los artículos patrocinados son contenidos producidos por una empresa que paga por la publicación o tiene una relación comercial con VentureBeat y siempre están claramente marcados. Para más información, póngase en contacto ventas@venturebeat.com.
