PatientIQ: Creación de un perfil integral del paciente en Couchbase

¿Qué es PatientIQ y por qué se creó?

PatientIQ es una plataforma de visión integral del paciente (Patient 360) desarrollada con Couchbase Capella AI Services. Es un ejemplo de solución a un problema que estamos tratando de resolver. En el caso de PatientIQ, todo comenzó con una simple pregunta: ¿cuántos de nosotros hemos tenido un ser querido que haya tenido una mala experiencia con la atención médica? 

La respuesta a esta pregunta, cuando se planteó en una sala llena de gente, fue aterradora. La mayoría levantó la mano. Las conversaciones posteriores confirmaron que, en el caso de quienes no levantaron la mano, por lo general les faltaba solo un amigo cercano para haber vivido una experiencia negativa similar. Sin embargo, los médicos de Estados Unidos son excepcionales, y muchos de los mejores del mundo ejercen aquí. Esto nos ayudó a replantear la pregunta. Si no hay un problema de calidad profesional, ¿por qué son tan comunes las malas experiencias?

La atención al paciente es un problema de gestión de datos

Nuestras experiencias personales y nuestras investigaciones nos han llevado a pensar que los médicos de hoy en día están desbordados. Cuando ya van por su tercer café y su quinto paciente antes del almuerzo, puede resultar difícil brindar una atención personalizada y de calidad de manera constante. A medida que profundizamos en el problema, nuestra investigación reveló que los médicos de hoy en día dedican el doble de tiempo a los registros médicos electrónicos (EHR) que a la atención de los pacientes. También se estima que entre el 30 % y el 40 % de los EHR carecen de la mitad de los valores de datos esperados. 

Los médicos dedican demasiado tiempo a revisar datos que, a menudo, están incompletos. Eso no es un problema de calidad de los médicos. Es un problema de gestión de datos. Los médicos son inteligentes, pero no se puede esperar que recuerden cada detalle de todos sus pacientes. Sin embargo, para lograr una medicina verdaderamente personalizada, todos estos datos son esenciales. Los datos merecen tanto cuidado como los pacientes y, al igual que un médico excelente, Couchbase está especialmente preparado para resolver este problema específico de gestión de datos.

El estado actual de la IA requiere una capa de datos sólida. Los modelos de uso general no se entrenan con datos sanitarios, lo que aumenta la probabilidad de que se produzcan «alucinaciones» inaceptables en un entorno sanitario. El ajuste fino de un modelo puede ayudar a entrenarlo con datos relevantes para tareas específicas, pero el proceso de entrenamiento puede llevar tiempo y los resultados pueden variar. Proporcionar el contexto adecuado desde nuestro almacén de datos operativos a nuestros modelos y agentes es de vital importancia para reducir el riesgo de alucinaciones y desarrollar una capa de inteligencia eficaz. A continuación, analizaremos nuestras consideraciones sobre la creación de la base de datos adecuada para hacer esto posible.

Partir de los datos. Crear una base de datos sólida

Los datos sobre médicos y pacientes utilizados en esta demostración son ficticios. Se han diseñado para que sean lo más realistas posible, evitando al mismo tiempo cualquier problema relacionado con el uso de información confidencial. La investigación médica es real y se han utilizado artículos de PubMed. En la práctica, los datos sanitarios se presentan principalmente en formato FHIR, similar a los modelos de datos JSON que hemos creado, y no requieren ningún procesamiento especial para su importación y suministro a nuestros agentes.

El conjunto de datos completo y el esquema, con la división en ámbitos y colecciones para la organización de los datos, se pueden consultar en GitHub. Aunque se trataba de una aplicación de demostración, tras una revisión independiente, Capella puede ejecutarse de conformidad con la HIPAA, y nuestro objetivo es hacerlo así en el entorno de producción.

En PatientIQ, nuestra sencilla estructura de datos utiliza tres categorías:

1. Scripps: Nombre de nuestro hospital, incluyendo todos los datos de médicos y pacientes.
2. Investigación: Contiene todos los datos de investigación médica.
3. Catálogo de agentes: Todos los datos sobre nuestros agentes, herramientas, indicaciones y registros.

En cuanto a nuestros datos operativos, la arquitectura exclusiva «memory-first» de Couchbase y su caché integrada nos permitieron alcanzar tiempos de respuesta inferiores a un milisegundo al realizar operaciones de creación, lectura, actualización y eliminación gestionadas por el SDK de Python de Couchbase que elegimos. También utilizamos índices a nivel de colección, por ejemplo Scripps.Personas.De los pacientes, para evitar escaneos completos de los buckets y aprovechar los rápidos tiempos de respuesta de las consultas. Para PatientIQ era importante que los datos operativos de un paciente se mostraran tanto en el panel de control como a nuestros agentes. Esto permitió que un médico con poco tiempo para prepararse para una consulta recibiera información oportuna con una latencia imperceptible.

Para que nuestra demostración sea concisa, el conjunto de datos se limita a un hospital, un médico (el Dr. Mitchell) y cinco pacientes. A continuación se muestra un ejemplo de un documento JSON de médico:

Cada paciente presenta una afección pulmonar específica para garantizar una base de investigación médica específica: asma, EPOC, fibrosis pulmonar, fibrosis quística y bronquiectasias. A continuación se muestra un ejemplo de un documento JSON de paciente:

Ya tenemos nuestro hospital (Scripps), nuestro médico (el Dr. Mitchell) y nuestros pacientes (por ejemplo, James Smith). A continuación se enumeran otras fuentes valiosas de datos de pacientes:

• Dispositivos portátiles
• Notas de la consulta tomadas por un médico
• Notas personales tomadas por un paciente sobre su visita
• Cuestionarios previos a la visita rellenados por los pacientes
• Detalles de la cita y próximas visitas de pacientes

En la actualidad, estos datos se encuentran aislados en un único dispositivo o sistema y están en diferentes formatos. Como consecuencia, puede resultar muy difícil trasladarlos o extraer información útil de ellos. Sin embargo, cuando se integran, pueden crear un perfil de datos único del paciente que el médico puede utilizar para comprender su estado de salud y su experiencia en el hospital.

Con Couchbase, podemos almacenar y recuperar nuestros datos operativos de manera óptima sin necesidad de introducir una capa de almacenamiento en caché independiente ni aumentar la complejidad del sistema. Esto permite a nuestro equipo centrarse en el desarrollo de funcionalidades, que depende de la recepción rápida de estos datos operativos.

Añadir inteligencia a una sólida base de datos con los servicios de IA de Capella

Hoy en día, para dotar de inteligencia a una aplicación es necesario contar con una base de datos vectorial independiente y enviar datos fuera de los límites de confianza a modelos de lenguaje y de incrustación a través de API externas. Esto supone un obstáculo para los datos que se pueden utilizar y un riesgo para el rendimiento y la seguridad de la aplicación existente.

Couchbase Capella y los servicios de IA permiten a los desarrolladores superar esas barreras, gracias a la compatibilidad optimizada con bases de datos vectoriales integrada en la plataforma y a la posibilidad de implementar y ejecutar modelos optimizados por NVIDIA dentro de una red privada compartida con sus datos, sin que el tráfico pase por la red pública de Internet. En el caso de PatientIQ, pudimos utilizar dos modelos seguros implementados en el servicio Capella Model Service.

Decidimos utilizar los siguientes datos operativos para enviarlos a nuestro modelo de incrustación de texto nvidia/llama-3.2-nv-embedqa-1b-v2:

1. Notas de la visita: Tomada por un médico con motivo de la visita de un paciente.
2. Investigación médica: Artículos centrados en afecciones pulmonares.

Tradicionalmente, convertir estos datos en representaciones de texto que puedan utilizarse para la búsqueda de similitudes semánticas requeriría crear un flujo de datos personalizado. Un proceso de limpieza para normalizar el texto y darle un formato coherente. Una estrategia de fragmentación para gestionar contenidos extensos, como los artículos de investigación. Código para invocar un modelo de representación y almacenar los vectores resultantes. Esto puede alargar el ciclo de desarrollo varias semanas antes de que se pueda ofrecer cualquier funcionalidad significativa de IA.

Con los servicios de IA, se utilizó el servicio de procesamiento de datos para simplificar el proceso. Existen opciones de preprocesamiento de datos que permiten controlar cómo se vectorizan los datos. Vectorizamos campos JSON específicos y devolvimos un nuevo campo dentro de nuestro documento JSON que contenía nuestras incrustaciones de texto. A modo de ejemplo, se extrajeron datos de investigación médica de PubMed utilizando BigQuery con la siguiente consulta SQL:

La consulta arrojó 50 artículos de investigación sobre neumología, que luego se exportaron a formato JSON. El texto en el texto del artículo El campo que contenía 50 documentos se vectorizó y se almacenó en un nuevo campo texto_del_artículo_vectorizado. Podemos recuperar cinco trabajos de ejemplo utilizando Capella iQ para escribir nuestra consulta SQL++. 

El flujo de trabajo automatiza el proceso de la cadena de trabajo de incrustación y almacena los resultados en el Investigación.PubMed.Pulmonar colección. De forma opcional, se crea un índice a hiperescala al configurar un flujo de trabajo. Los índices a hiperescala se configuran para PatientIQ porque la aplicación realiza búsquedas vectoriales puras y se beneficia de las optimizaciones para la indexación de una sola columna vectorial. 

A menudo, los datos sanitarios no se archivan con rapidez porque el historial médico puede remontarse a varios años atrás y existe una gran probabilidad de que el índice crezca hasta alcanzar cientos o incluso miles de millones de documentos en el caso de los grandes sistemas de salud. El índice a hiperescala es una excelente opción para garantizar la viabilidad futura de un sistema de recuperación a gran escala.

El índice a hiperescala tiene una sola réplica, gestiona 2048 dimensiones generadas por el modelo de incrustación de texto NVIDIA llama-3.2-nv-embedqa-1b-v2 y utiliza el algoritmo de búsqueda de similitud L2 (cuadrado euclidiano). Existen cuatro algoritmos de similitud en función del caso de uso, y consideraríamos cambiar de L2 a Coseno en producción, ya que nos interesa principalmente el significado semántico, mientras que la magnitud no es tan importante.

Se pueden ver referencias al Índice de Archivos Invertido (IVF) y a la cuantificación SQ8. Se trata de parámetros de configuración importantes que se pueden ajustar para lograr un rendimiento óptimo en las búsquedas vectoriales. El IVF acelera las búsquedas vectoriales al limitar el número de comparaciones a los vectores cercanos a los centroides relevantes. La cuantificación escalar (SQ) reduce las dimensiones a enteros de 8 bits, lo que disminuye la memoria necesaria para la búsqueda y mejora la velocidad, ya que las operaciones con enteros son computacionalmente menos costosas que las operaciones de punto flotante.

Un aspecto importante para PatientIQ es que los datos vectoriales se crean, almacenan y consultan de manera óptima junto con nuestros datos operativos, sin necesidad de procesos complejos, configuraciones ni una base de datos vectorial independiente.

Además de un modelo de incrustación, implementamos un modelo de lenguaje a gran escala mistralai/mistral-7b-instruct-v0.3. El modelo se ejecuta en un entorno optimizado para NVIDIA con opciones de configuración adicionales para el almacenamiento en caché, los controles de seguridad y la protección contra el jailbreak. En producción, habilitaríamos todas estas opciones y utilizaríamos el almacenamiento en caché para reducir el número de llamadas al modelo de lenguaje grande (LLM), los tokens utilizados y los costos. 

En el ámbito sanitario, el envío de datos a través de Internet a puntos finales de modelos públicos aumenta el riesgo de violaciones de la privacidad de los datos. La posibilidad de utilizar el Servicio de Modelos, en el que los datos y la inferencia se encuentran en el mismo lugar, ofrece una mayor confianza a la hora de crear funciones inteligentes, al tiempo que protege los datos subyacentes.

PatientIQ utilizó el modelo de lenguaje grande (LLM) de dos maneras:

1. Resuma la información del paciente en el panel de control.

Mediante la API de Model Service y nuestro punto final para /v1/chat/completions, el resumen de los datos generales del paciente y sus respuestas al cuestionario previo a la consulta se convierten en párrafos concisos y fáciles de entender, que el médico puede revisar rápidamente antes de que el paciente llegue a la consulta.

Este es un ejemplo de generación aumentada por recuperación (RAG) que aprovecha nuestros datos operativos almacenados en la plataforma Capella, utilizada como base de conocimiento para proporcionar contexto a una solicitud. Este tipo de RAG se utilizó para impulsar la síntesis inteligente en toda la plataforma PatientIQ, y el modelo de lenguaje grande (LLM) que interactúa con los datos operativos puede hacerlo en la misma región de AWS del Este de EE. UU., lo que permite ofrecer respuestas rápidas en el panel de control.

2. Vincular una función de IA para realizar un análisis de sentimiento en las notas confidenciales de las consultas de los pacientes.

Las notas de comentarios de los pacientes se refieren a las visitas tras haber visto a su médico. El contenido de las notas está destinado a ser privado y no se comparte directamente con el médico. En su lugar, se utiliza una función de IA de Capella vinculada al modelo de lenguaje grande (LLM) Mistral con el siguiente código SQL++ consulta para realizar un análisis de opinión sobre el contenido de las notas. 

Aquí también existe la opción de utilizar un modelo especializado en AWS Bedrock que ha sido entrenado con datos del sector de la salud. Esto puede ser una forma importante de garantizar una mayor precisión mediante la asociación de un modelo personalizado al ejecutar funciones de IA.

Las funciones de IA te permiten realizar operaciones de IA predefinidas, como el análisis de opiniones, directamente mediante una consulta SQL++ y con menos código manual. Aquí está nuestra consulta SQL++:

Véase, por ejemplo, este resultado de sentimiento negativo:

La impresión general que tiene el paciente sobre su médico se muestra a continuación en la interfaz de PatientIQ.

Esta implementación proporcionó información sobre la última visita del paciente para que su médico tuviera una idea de cómo podría sentirse de cara a su próxima cita. Los médicos pueden atender con especial atención a los pacientes que muestran sentimientos negativos y adaptar la próxima visita en consecuencia.

Actuar basándose en la inteligencia. Crear una visión integral del paciente basada en la acción

La próxima era del software será «agente». El software será capaz de realizar acciones sobre los datos antes de que los resultados nos lleguen a nosotros, los usuarios. Esto significa que nuestro software podrá llevar a cabo acciones inteligentes con los datos, lo que dará lugar a resultados más útiles que podremos emplear para actuar en el mundo físico. 

Una salvedad importante que hay que tener en cuenta en nuestra demostración es que utilizamos un LLM externo, pero en un entorno de producción este se sustituiría por un LLM compatible con la invocación de herramientas en el Model Service de Capella. No queríamos enviar datos de pacientes fuera de nuestro entorno de confianza y observamos problemas de latencia al interactuar con una API externa. 

Si logramos liberar a los médicos de pequeñas tareas administrativas mediante la intervención de agentes, el resultado será que dispondrán de más tiempo para dedicarse a atender a sus pacientes. Hemos seleccionado cuatro agentes para mostrar ejemplos de acciones útiles:

1. Investigador en neumología

Este agente recupera el diagnóstico de un paciente, por ejemplo, asma, y realiza una búsqueda de similitud semántica para mostrar artículos de investigación relevantes relacionados con ese diagnóstico. La solicitud utiliza nuestro modelo de lenguaje grande (LLM) del Servicio de Modelos para resumir la investigación y mostrarla en el panel de control. A continuación, el médico puede formular una pregunta más específica. La pregunta se vectoriza, lo que permite que la búsqueda de similitud semántica devuelva las respuestas más relevantes a la pregunta clínica del médico. Las respuestas se devuelven junto con las fuentes utilizadas para generarlas.

Utilizamos una herramienta de búsqueda en la web para encontrar nuevas investigaciones médicas y seleccionar los artículos relevantes de entre los tres primeros resultados. Un médico puede verificar la fuente y, a continuación, decidir si la añade a su base de datos de investigaciones médicas de confianza. Cuando se añade un artículo, este se digitaliza. El nuevo artículo se almacena en Capella y queda disponible para ayudar a responder consultas futuras.

Las preguntas, las respuestas y la puntuación se guardan en Capella para utilizarlas en la evaluación y la mejora del rendimiento futuro de esta funcionalidad.

El asistente le ahorra tiempo al médico a la hora de buscar bibliografía relevante sobre la afección de un paciente, ya que le ofrece un resumen rápido y respuestas a sus preguntas a partir de su base de datos de confianza.

2. DocNotes Searcher

Este agente revisa las notas tomadas por un médico durante y después de las consultas con los pacientes. El médico puede formular preguntas en la búsqueda para recuperar información de consultas anteriores y así tomar decisiones más fundamentadas. Las notas se redactan en PatientIQ, se digitalizan y se guardan en Capella. Cuando un médico formula una pregunta, se devuelven resultados semánticamente similares como contexto al modelo de lenguaje grande (LLM) en el Servicio de Modelos, que luego se presenta como respuesta.

Este asistente ahorra tiempo al médico, ya que le evita tener que buscar notas y leer información irrelevante al formular una pregunta importante y ofrecer una respuesta concreta justo antes de la consulta con el paciente.

3. Resumen previo a la visita

Este agente revisa el cuestionario previo a la consulta del paciente y permite a los médicos ver un resumen antes de la próxima cita con el paciente.

La gran cantidad de detalles que contiene el cuestionario sirve como contexto que Capella proporciona al modelo de lenguaje grande (LLM) en el Servicio de Modelos, y los datos esenciales se facilitan al médico para su fácil consulta. Por ejemplo, se proporcionan las cinco preguntas más frecuentes de los pacientes para una próxima cita, junto con los medicamentos que el paciente está tomando actualmente. Leer todo el cuestionario antes de cada visita de un paciente llevaría mucho tiempo, sobre todo a medida que aumenta el número de visitas de pacientes al día.

4. Alerta portátil

Este agente analiza los datos registrados durante 30 días por un dispositivo portátil, como un Apple Watch, y avisa al médico si detecta alguna tendencia preocupante. Se basa en la afección diagnosticada del paciente y ofrece orientación sobre los aspectos a tener en cuenta al realizar el análisis; por ejemplo, en el caso de un paciente asmático.

Arriba se muestra una ilustración de una alerta crítica por una caída de la saturación de oxígeno del paciente por debajo del 90 %%. El médico puede establecer los umbrales a los que debe prestar atención, y el agente puede llevar a cabo un monitoreo constante de los datos. Los datos de los dispositivos portátiles ofrecen una visión actualizada del estado de salud del paciente que los médicos pueden utilizar para ofrecer un tratamiento personalizado.

Agentes LangGraph ReAct. Indicaciones, herramientas y trazas en el catálogo de agentes de Couchbase

Todos los agentes utilizan LangGraph como marco de orquestación y son simples agentes ReAct que se comportan de esta manera.

Una diferencia clave es que las herramientas, las indicaciones y los rastros son gestionados por el Catálogo de agentes de Couchbase. Las indicaciones y las herramientas se pueden crear utilizando agente añadir desde la CLI. Agent Catalog convierte las consultas SQL++, las búsquedas semánticas y las solicitudes HTTP en funciones de Python que pueden ser recuperadas por nuestros agentes. 

Para PatientIQ, creamos 28 herramientas y cinco indicaciones que se almacenan tanto localmente como en Capella. Se utilizaron transformadores de oraciones, así como el ll-MiniLM-L12-v2 modelo de incrustación local para convertir las indicaciones y las herramientas en incrustaciones de texto. 

Con Agent Catalog, nuestros agentes pueden encontrar herramientas y plantillas relevantes mediante la similitud semántica. Esto puede reducir la confusión de los agentes cuando se enfrentan a una gran cantidad de plantillas y herramientas y no logran encontrarlas solo con una palabra clave. 

El personal administrativo supervisa las indicaciones y las herramientas que utilizan nuestros agentes, lo que reduce el riesgo de que se utilicen herramientas sin autorización y garantiza que no se realicen acciones que no sean visibles. También existe la opción de añadir una aprobación manual. 

Gracias a las herramientas y las indicaciones creadas e integradas con nuestros agentes, el catálogo se puede indexar y publicar en Capella. Podemos visualizarlo, consultar Git y revisar el historial de versiones.

El almacenamiento, el control de versiones y la recuperación de indicaciones y herramientas de Capella simplifican el proceso de desarrollo en todos los proyectos, equipos y agentes. 

Aunque los agentes nunca sustituirán la labor de un médico, sí permiten que PatientIQ actúe basándose en nuestra base de datos. El resultado es que los médicos disponen de más tiempo para centrarse en las acciones que realmente importan para los pacientes.

Trabajar con el no determinismo. Solución de problemas y evaluación de agentes

Uno de los retos que plantea la funcionalidad de los agentes es la introducción del no determinismo, es decir, que una misma entrada puede generar diferentes resultados o seguir diferentes caminos para llegar a ellos. Esto puede resultar beneficioso para la experiencia del usuario, ya que hace que el software se parezca más a un ser humano, pero también puede dar lugar a resultados inesperados. Además de utilizar la generación aumentada por recuperación (RAG) para proporcionar contexto a nuestras indicaciones, intentamos abordar las desventajas de los agentes no deterministas de otras dos maneras. 

1. Uso de Agent Tracer y consultas SQL++ para solucionar problemas relacionados con un comportamiento inesperado del agente.

Un ejemplo que vivió nuestro equipo fue el caso del investigador pulmonar que devolvía artículos de investigación como referencias que no existían. Al principio, no entendíamos por qué ocurría esto desde el código de nuestra aplicación. Luego pudimos revisar el Agent Tracer de este agente específico y reducir el problema a las llamadas a la herramienta.

Nos dimos cuenta de que nuestra herramienta de búsqueda de artículos no arrojaba ningún resultado. Revisamos el código de la aplicación y vimos que, al realizar una búsqueda por palabra clave, habíamos utilizado una palabra clave incorrecta para identificarla. Nuestro agente no estaba utilizando la herramienta que habíamos creado y estaba «alucinando» con artículos de investigación que no existían. 

Llevamos a cabo una investigación más exhaustiva mediante consultas SQL++, revisando nuestros registros y las sesiones de los agentes en el momento en que se produjo el incidente. De este modo, pudimos diagnosticar y resolver rápidamente el problema del agente que presentaba un comportamiento anómalo.

2. Crear nuestras propias evaluaciones de agentes utilizando ragas para desarrollar un sistema de puntuación.

En PatientIQ, realizamos evaluaciones de cada agente utilizando indicaciones de ejemplo a través de los mismos flujos de agente, y luego empleamos RAGAS y métricas calificadas por modelos de lenguaje grande (LLM) para puntuar los resultados en función de las expectativas. Creamos nuestras propias dimensiones de puntuación, como la calidad de la respuesta, la solidez y la relevancia, para comparar los cambios a lo largo del tiempo a medida que evolucionaban las indicaciones, las herramientas y nuestra lógica de recuperación. Este es un ejemplo de las métricas para nuestro Investigador Pulmonar:

• Relevancia clínica: En qué medida la respuesta es clínicamente relevante y se adapta a la pregunta y al contexto del paciente.
• Aplicabilidad: En qué medida los siguientes pasos y el razonamiento clínico resultan prácticos para un profesional de la salud.
• Fundamento de las pruebas: En qué medida la respuesta se basa en pruebas y evita afirmaciones sin fundamento. Sanción por citas inventadas.

La relevancia clínica se introdujo tras detectarse un problema por el que el agente presentaba un artículo de investigación inventado como evidencia para responder a una pregunta clínica. Una vez solucionado el problema, observamos una mejora en la puntuación de fundamentación de la evidencia.

Hacia la implementación de PatientIQ en producción y a gran escala. ¿Por qué desarrollarlo en Couchbase?

PatientIQ demuestra lo que se puede lograr cuando los datos operativos, la búsqueda vectorial, los modelos y las herramientas de los agentes conviven en una única plataforma. No es necesario combinar múltiples bases de datos, almacenes vectoriales externos y llamadas a API públicas que envían datos privados fuera de los límites de seguridad. Los modelos y los datos pueden funcionar dentro de la misma red privada. Las consultas se ejecutan a la velocidad de la memoria. Las indicaciones y las herramientas se versionan de forma centralizada. El sistema puede escalar horizontalmente a miles de millones de documentos y vectores, al tiempo que mantiene un acceso de baja latencia y opera con un costo total de propiedad (TCO) reducido.

Las implicaciones para las empresas son significativas. Los médicos ahorran el tiempo que antes perdían navegando por sistemas de historias clínicas electrónicas (HCE) fragmentados. Los pacientes reciben una atención más atenta y adaptada a su contexto. Los hospitales reducen los gastos administrativos y el riesgo potencial de negligencia. La satisfacción mejora para ambas partes de la interacción. Y lo más importante: los médicos dedican más tiempo a lo que solo los seres humanos pueden hacer: establecer diagnósticos, mostrar empatía y ofrecer tratamiento.

El sector de la salud actual no adolece de una falta de profesionales competentes. Lo que le afecta es la fragmentación de los datos. La IA no soluciona una infraestructura defectuosa si simplemente se le añade como un complemento. Cuando se construye sobre una base sólida de datos, puede potenciar la experiencia humana de maneras muy eficaces. El futuro del software es autónomo. El futuro de la salud se basa en los datos. PatientIQ es el resultado de la unión de esas dos ideas con Couchbase, la plataforma de datos operativos para la IA.

Mientras que los nuevos participantes en el mercado aún están experimentando con la persistencia de datos, Couchbase ya es la base de datos probada en la práctica para la IA en el sector de la salud, donde hay mucho en juego. Con la confianza de líderes del sector como Arthrex, BD y Maccabi Healthcare Services, nuestra plataforma gestiona todo, desde tiempos de respuesta inferiores a 1 ms hasta aplicaciones para pacientes con capacidad de funcionamiento sin conexión y datos quirúrgicos en tiempo real. Al cerrar la brecha entre los datos fragmentados y la atención médica que salva vidas, Couchbase ofrece la confiabilidad y el rendimiento probados que requiere la próxima generación de innovación médica.

Referencias

Couchbase

• Servicios de IA
• SDK de Python
• Catálogo de agentes
• API de servicio de modelos 
• Centro de confianza en la nube – HIPAA
• Ventajas arquitectónicas únicas
• Conexión de AWS PrivateLink
• NVIDIA AI Enterprise
• Índice de archivos invertido
• Cuantificación SQ8
• Datos de proceso para Capella
• Cómo elegir el índice vectorial adecuado
• Empieza a usar Capella iQ
• Herramientas y indicaciones para llamadas
• Elección del algoritmo de búsqueda
• Integrar LangGraph Agent
• Utilizar las funciones de Capella AI

LangGraph

• Crear agentes de ReAct

PatientIQ

• PatientIQ GitHub
• PatientIQ DeepWiki
• Artículos de investigación de PubMed
• Incompletitud de los registros médicos electrónicos
• Demostración en YouTube